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

From: Alfred Hönes <[email-masked]>
Date: Thu, 29 Mar 2012 22:10:30 +0200 (MESZ)

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.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 29 Mar 2012 22:26:21 +0200

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

>    possible legacy alternative: return FormErr;

RFC 2671bis requires the RCODE=1 response, see:

From: Florian Weimer <[email-masked]>
Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt
To: Olafur Gudmundsson <[email-masked]>
Cc: [email-masked]
Date: Mon, 13 Feb 2012 16:06:02 +0100
Message-ID: <[email-masked]>

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Mar 2012 10:36:07 +1100

In message <[email-masked]>, Florian Weimer writes:
> * Alfred H=F6nes:

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.
 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Fri, 30 Mar 2012 09:27:17 +0000

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

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

Yes, that's explicit.

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

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

---

From: Dick Franks <[email-masked]>
Date: Fri, 30 Mar 2012 14:58:54 +0100

Ray,

On 30 March 2012 10:27, Ray Bellis <[email-masked]> wrote:

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

ICMP ECHO was indeed the model I had in mind.

Regards
--Dick