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

* Alfred Hönes:

> 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.

> 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