Re: [dnsext] Signaling ENDS option understanding in draft-bellis-dnsext-multi-qtypes-01

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