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

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

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.

(*)  Please see my initial "RRGQ" proposal and its variations,
as suggested in messages to the former namedroppers list and
archived at
  http://www.ietf.org/mail-archive/web/dnsext/current/msg05291.html
and
  http://www.ietf.org/mail-archive/web/dnsext/current/msg05305.html,
and the entire thread started by the former message.

The variant in the design choice mentioned in the 3rd-to-last para
of the latter message -- combining a query for a Data RRtype with
an EDNS option (there dubbed 'RGMASK') -- is now followed by this I-D.

Unfortunately, I've never found the time to write this up properly
as an I-D (as promised), and I thank Ray for eventually having done
this now (with a bare RRtype list instead of an NSEC-like bitmask
in the OPTION-DATA).

Best regards,
  Alfred.

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext