Re: [dnsext] Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01
Mark Andrews <marka@isc.org> Thu, 29 March 2012 23:36 UTC
Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA1D21E8026; Thu, 29 Mar 2012 16:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333064203; bh=bwmpZKyyGE/9EoVymaMH/fsQazocflTPNYKBB5le4po=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=hCMA4U56yv3pJ70XxLF1LESllfgOMG9FX5Kh9SXD0C2gJJEB2grTrEsvswjo9hNno A6R4rS+4M5VY6lZeybJQbXZTds8H7N6gdieErI3X896stjtHaJKibujN7SftnxZhsE iqkg6z41rJxagFi60AaHSPbDLdmTOsoOAfcE3IYA=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4847721F86B2 for <dnsext@ietfa.amsl.com>; Thu, 29 Mar 2012 16:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Level:
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbSkkPn-P-jW for <dnsext@ietfa.amsl.com>; Thu, 29 Mar 2012 16:36:40 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8121F86A5 for <dnsext@ietf.org>; Thu, 29 Mar 2012 16:36:40 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id B74B5C944A; Thu, 29 Mar 2012 23:36:20 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b9d2:d2a7:a07b:5597]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 602C1216C33; Thu, 29 Mar 2012 23:36:20 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C6CD21F3B95D; Fri, 30 Mar 2012 10:36:08 +1100 (EST)
To: Florian Weimer <fw@deneb.enyo.de>
From: Mark Andrews <marka@isc.org>
References: <201203292010.WAA20455@TR-Sys.de> <87bonfkvbm.fsf@mid.deneb.enyo.de>
In-reply-to: Your message of "Thu, 29 Mar 2012 22:26:21 +0200." <87bonfkvbm.fsf@mid.deneb.enyo.de>
Date: Fri, 30 Mar 2012 10:36:07 +1100
Message-Id: <20120329233608.C6CD21F3B95D@drugs.dv.isc.org>
Cc: Alfred Hönes <ah@TR-Sys.de>, dnsext@ietf.org
Subject: Re: [dnsext] Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org
In message <87bonfkvbm.fsf@mid.deneb.enyo.de>, Florian Weimer writes: > * Alfred H=F6nes: > > > To this end, IIRC the WG has decided that RFC 2671 contains enough > > specification, and the rfc2671bis draft again clarifies that DNS > > servers recieving an OPT RR in a query MUST ignore unknown options. > > I think this is rewriting history. BIND used to respond with RCODE=1 > to queries carrying the new NSID option, for example. And I'm sorry > to say that this obnoxious behavior is even suggested by the language > in RFC 2671. Which version of BIND? Not 9.1.0 nor 9.2.0 nor 9.3.0 nor 9.4.0 which are the early BIND 9 production releases. I don't believe BIND 8 returned FORMERR based on code inspection. > > Thus, according to my understanding, a conformant recipient of an > > OPT RR in a DNS query behaves as follows: > > > > a) no support for EDNS present > > (either not built-in or disabled by config): > > ignore entire OPT RR, do not include OPT RR into response; > > possible legacy alternative: return FormErr; > > RFC 2671bis requires the RCODE=1 response, see: > > From: Florian Weimer <fw@deneb.enyo.de> > Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt > To: Olafur Gudmundsson <ogud@ogud.com> > Cc: dnsext@ietf.org > Date: Mon, 13 Feb 2012 16:06:02 +0100 > Message-ID: <871upyept1.fsf@mid.deneb.enyo.de> > > > b) support for EDNS present, but no support present for a particular > > option received: ignore it, do not include it in response; > > c) support for particular EDNS option present: > > behave according to the specification of that option > > (which may be: echo the received option unchanged, or otherwise). > > b) and c) seem correct to me, with the caveat that reflecting the > query with the original OPT RR does not mean the server supports your > protocol extension. You need to bits to tell an active implementor > from a reflector. (Kind of what was done with ECN for TCP, > eventually.) > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
- Re: [dnsext] Signaling ENDS option understanding … Alfred Hönes
- Re: [dnsext] Signaling ENDS option understanding … Florian Weimer
- Re: [dnsext] Signaling ENDS option understanding … Mark Andrews
- Re: [dnsext] Signaling ENDS option understanding … Ray Bellis
- Re: [dnsext] Signaling ENDS option understanding … Dick Franks