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

On 29 Mar 2012, at 22:10, Alfred HÎnes wrote:

On 27 Mar 2012 12:29:06 +0100, Dick Franks
noted that the QTD bit proposed in Section 3.1 of
draft-bellis-dnsext-multi-qtypes-01 seems redundant.

That indeed is the case, and, after discussion on a side-track of
the seminal suggestions for this proposal I had made (*) before the
Hiroshima IETF, this WG has formed consensus that no additional
signaling of "understanding of EDNS options" is desired.

Is that documented anywhere?  2671bis (per your note below) appears to suggest otherwise.

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.

Yes, that's explicit.

The WG consensus in 2009 was that "ignore" also means to not copy
the option into the OPT RR in the response (if any), and
implementers had confirmed those days that this was the behavior
of state-of-the-art EDNS implementations.

Yes, that's right.  I'm worried about non state-of-the-art implementations ;-)

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

Since the QTCOUNT is redundant as well, the first octect of the
proposed option format is indeed redundant.

Note however, that rfc2671bis allows additional handshaking.
So it's a matter of simplicity vs. redundancy and actual gain.

Indeed - §6.1.2

"Specifications of such options might wish to

 include some kind of signaled acknowledgement"

I do think such signalled acknowledgement is sensible, given my experiences with various middleboxes that will blithely ignore many things written in the RFCs.  At least with a signalling bit you can have an _explicit_ confirmation that the far end knows what it's doing.

That said, I'm _kind of_ OK with Dick's proposal that the response use a different option code instead of using the QTD bit.  That's consistent with ICMP, although off the top of my head I'm not aware of any other part of DNS that does this.

kind regards,

Ray