Subject: [dnsext] Building structured extensibility into EDNS0(bis)

From: Alfred Hönes <[email-masked]>
Date: Thu, 12 Nov 2009 21:33:14 +0100 (MEZ)

The recent discussion on my "RR Group Query" proposal (*) has lead me
back to another proposal I had made last year during the FR debate,
but which had not attracted much response since.  I have been called
for submitting it in enough detail for discussion and subsequent
inclusion in the rfc2671bis draft.

  (*)  work on draft has been started; please be patient,
       more input in unicast welcome!)

As the name says, EDNS0 is an Extension mechanism for DNS, and
its hook for extensibility is with the {attribute,value} pairs
(aka EDNS0 Options) grouped in the RDATA portion of the OPT RR
placed in the Additional section of both Queries and Responses.

Good protocol extension design (cf. draft-iab-extension-recs)
ensures provisions for mechanisms allowing seemless gradual
deployment of protocol extensions making use of the fundamental
extension mechanisms built into a base protocol.

Many successful protocols have built-in clever hooks to signal
intended behavior wrt subordinate protocol elements in case the
recipient of a message does not "understand" (or "support" or
"has enabled the use of") a particular protocol object.
This gives the designer of the extension object the choice of
some default processing implemented by all speakers of the
protocol, independent of their support for a specific extension
object, and thus allows to achieve clever deployment strategies.
Examples include Class-Types in RSVP, LSA types in OSPF (in
particular in OSPFv3) and similar constructs in various routing
protocols, "Mandatory/Optional" discriminators in PKIX structures,
etc.

The identifier for EDNS0 options is the 16-bit OPTION-CODE,
so far an unstructured value subject to IANA assignment.
In the 10 years since the publication of the EDNS0 specification,
RFC 2671, only a handful OPTION-CODE values have been assigned
by IANA (or "came into use") :

IANA:
    Value    Name         Status    Reference
    -------  -----------  --------  -----------
    0                     reserved  [RFC2671]
    1        LLQ          On-hold   [draft-sekar-dns-llq]
    2        UL           On-hold   [draft-sekar-dns-ul]
    3        NSID         Standard  [RFC5001]
    4                     reserved  [draft-cheshire-edns0-owner-option]
    5-65535  -unassigned-           [RFC2671]

"known to the list":
    5                     "used"    [draft-hubert-ulevitch-edns-ping]

Note: I could not find record of RFC 2671 having reserved value 0;
++++  instead, RFC 2671 has reserved value 65535 for future
      extensions, as does the current rfc2671bis-edns0 draft.

      I suggest that rfc2671bis-edns0 also registers value 0
      as  -reserved- .

RFC 2671 is silent about server behavior in face of unknown options.
Currently, Section 6.2 of draft-ietf-dnsext-rfc2671bis-edns0-02
says:

|  Any OPTION-CODE values not understood by a responder or requestor
|  MUST be ignored.  Specifications of such options might wish to
|  include some kind of signalled acknowledgement.  For example, an
|  option specification might say that if a responder sees option XYZ,
|  it SHOULD include option XYZ in its response.

This is still unsatisfactory, since it unnecessarily restricts the
design choices for new EDNS0 options.

To further the design of EDNS0 options, I suggest to reclaim the
four most significant bits of the EDNS0 OPTION-CODE as functional
bits directing the recipient of the option what to do with it
in case it does not "support" the option.
This seems to be a still conservative and responsible action, with
regard to the low demand for EDNS0 Option-Code assignments so far.

The following tasks have to be performed to properly design
the details:
 a)  propose and achieve consensus on the needed
     groups of behavioral patterns to be encoded
 b)  assessment of existing use
 c)  based on b): do we need a "legacy" group ?
 d)  fix encoding of groups
 e)  perhaps subdivide groups into
     assigned by IANA / experimental / private use
     and decide on IANA policy for the former

To give a starting point, here are my provisional contributions

(NB: That does not mean I insists on the analysis results and
     proposals; I simply want to give a reasonable starting point
     for collecting more input and rapid consensus-building.)

a)  Classification of default behavior of recipient of query.

    Observation #1: EDNS0, i.e. the OPT RR, essentially is a
      hop-by-hop protocol.  (RFC 5001 says "not transitive".)
      Hence no functionality related to "forwarding" needs to be
      considered.

    Remaining categories:
     o  "ignore"           -- do not send same option in response
     o  "echo"             -- copy option unchanged into response
     o  "must understand"  -- refuse entire query
                              (extended RCODE: t.b.d.)
     o  "unspecified"      -- implementation specific
                              (to be used for legacy code points)

    [[ DISCUSS:  Other valid options? ]]

    The single change in protocol behavior needed by the introduction
    of this proposal would be for DNS responders (servers, resolvers)
    to honor the "must understand" and "echo" semantics if they do
    not understand the particular option received in these groups,
    thus making the introduction and gradual deployment of new options
    much more easier subsequently.

b)  (Provisional) Analysis by code point for existing definitions/use:

    0/65535  : since this code point is reserved as an anchor point
         for future extensibility, arguably it could be placed in
         any of the groups given above; maybe: exceptional
         processing needed anyway, should code point become
         used some day, so decision does not matter.

    1  : The DNS-LLQ service model has been found incompatible with
         the standard DNS service model and has not been standardized;
         however, reportedly it is used in specific environments, and
         notably with mDNS.
         DNS-LLQ Challenge is underspecified for the case of lack
         of server support.  A non-EDNS0 aware server might respond
         with RCODE FormErr(1) or NotImp(4), which the draft takes
         as "non-LLQ capable", but it is silent of the possible case
         of an EDNS0-aware, yet "non-LLQ capable" server.
         Assuming the behavior specified in rfc2671bis-edns0-02 would
         mean "ignore" was a server behavior allowing graceful fallback
         to standard DNS operation with minimal extra traffic; arguably
         classification as "must understand" or "unspecified" could
         also be regarded as appropriate.

    2  : DNS-UL also has not been adopted by the IETF, but reportedly
         it is used in specific environments.
         Again, the defining draft underspecifies expected server and
         client behavior in the case of a "non-UL capable" server, but
         again "ignore" server behavior would allow graceful fallback
         to standard DNS operation with minimal extra traffic; arguably
         classification as "must understand" or "unspecified" could
         also be regarded as appropriate.

    3  : RFC 5001 specifies the NSID option as a diagnostics tool.
         "ignore" seems to be the best default strategy as well.

    4  : The EDNS Owner Option is used in specific environments.
         The specification is silent on deployment/interoperability
         considerations, but that seems rather irrelevant due to the
         specific context where the option is used and consenting
         universal support is assumed.  The seems to be tolerant to
         the "ignore" default behavior, but the mDNS folks might be
         able to teach us otherwise.

    5  : "echo" would be most useful default behavior, but "ignore"
         is acceptable, and upon potential approvement of the draft
         a different code point could be assigned.

c)  (Provisional) Evaluation

   It looks like there is no need for a "legacy" / "unspecified"
   group; all existing use cases seem to be compatible with
   "ignore" behavior as currently specified in rfc2671bis-edns0-02
   for *all* EDNS0 options.

   Thus, it should make sense to include option# 1..5 in the "ignore"
   group.

d)  As a result of c), I suggest to assign two functional bits from
    the most significant nibble of the EDNS OPTION-CODE for
    "must understand" (M) and "echo" (E); two bits remain reserved
    (res) for future sepcification and are set to zero currently.
    For instance:

                  +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |                          OPTION-CODE                          |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    is subdivided as:

         0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: | M : E :  res  :               Code                            |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    In generalization of the reservations mentioned above, I suggest
    that all OPTION-CODEs with Code 0x000 or 0xFFF be RESERVED for
    future updates to the EDNS0 RFC, i.e. all OPTION-CODE values of
    the form 0xy000 and 0xyFFF for y=0..F .

    Under this regime,

    - registrations must specify the setting of M and E, and IANA
      assigns the Code in a manner that a unique, flat 16-bit
      OPTION-CODE namespace is maintained;

    - existing registrations and use cases would be interpreted as
      having M=0 and E=0;

    - as long as no updating Standards track RFC has been issues,
      IANA will only assign OPTION-CODE values in the ranges
      (i)        1- 4094  ... for M=0 and E=0
      (ii)   16385-20478  ... for M=0 and E=1
      (ii)   32769-36862  ... for M=1 and E=0
      (iii)  49153-53246  ... for M=1 and E=1  [ does that make sense? ]

    - The RESERVED OPTION-CODE  65535 = 0xFFFF  remains exempt from
      the interpretation of M and E for backwards compatibility.

e)  Currently, the IANA Registry for EDNS Option Codes follows the
    RFC 5226 "Specification Required" policy, based on RFC 2671,
    and draft-ietf-dnsext-rfc2671bis-edns0-02 does not alter that.
    To allow room for protocol experiments, I propose to subdivide
    the 16 ranges in a uniform manner, reserving one subrange
    for Experimental use, in the spirit of BCP 82 (RFC 3692),
    and to allow other SDOs (for instance) make use of specific
    EDNS0 options, a Private Use range might also make sense.

    For instance, including the RESERVED code points mentioned above:

           CODE    0      (0x000      ) ... -RESERVED-
           Code    1-3839 (0x000-0xEFF) ... Spec. Required
           Code 3849-4063 (0xF00-0xFDF) ... Private Use
           Code 4064-4094 (0xFE0-0xFFE) ... Experimental
           CODE      4095 (      0xFFF) ... -RESERVED-

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Nov 2009 13:21:28 +0900

On Thu, Nov 12, 2009 at 09:33:14PM +0100,
 Alfred Hönes <[email-masked]> wrote 

>     (res) for future sepcification and are set to zero currently.

It seems a very good plan to me.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 13 Nov 2009 08:58:44 +0100

> It seems a very good plan to me.

I wonder how a resolver would detect that the other end supports M and E
bits.

Best regards,
   Wouter

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 13 Nov 2009 12:05:08 +0100 (MEZ)

> I wonder how a resolver would detect that the other end supports M and E

Admittedly, that's a dilemma.

RFC 2671 was entirely silent.
The community has learned that built-in extension paths must
be specified in sufficient detail to make them usable, and
RFC 2671 was suboptimal in this respect.
The current rfc2671bis-edns0-02 already contains a clarification
that might result in the need to change some implementations.
The same question hence already applies to that change.

This proposal adds to this change in a manner that is unlikely
to be a burden or major issue for implementers.

Currently, the starting deployment at large of DNSSEC will likely
cause many resolvers and servers receive software updates anyway,
and DNSSEC required making use of EDNS0.   Therefore, I confess
that the likelyhood of achieving rather quick adoption of
rfc2671bis-edns0 (with or without this addition) is very good.
So this might be the last good chance to introduce this mechanism
that is hoped to pay us back much effort in the future.

It should be noted that doing this step _now_ gives us a lead in
time before the first EDNS Option becomes defined and deployed
that wants to leverage this mechanism.  Anyhow, prudent design
and implementation of new EDNS options will have to deal with
backwards compatibility issues.

But what would be the options for introducing explicit signaling?

There would be two potential mechanisms to signal support of
the new semantics: adding a new EDNS flag, and increasing the
EDNS version number.

The latter would perhaps entail much more deployment problems and
I cannot imagine that anyone seriously suggests it.

The former procedure has been rejected by this WG recently for
the 'Understand DNAME' bit, where the impact might have been more
significant because of the existing use of DNAME, and thus I did
not propose such bit so far.  However, if the community supports
adding an "Understand M&E" flag bit, I would be fine with it.
In this case I'd suggest that this bit only be set (or considered
to be relevant) in _responses_ -- thus allowing to measure in the
wild the deployment rate of this function without the need for lots
of resolvers supporting it and making use of new EDNS options, i.e.,
doing so would give us the ability to quantify the 'readiness' of
the Internet for the deployment of new EDNS options.

However, if the M&E bit mechanism is introduced in rfc2671bis-edns0,
this bit would effectively become a "support of rfc2671bis-edns0"
flag, which someone could challenge as a minor EDNS version bumping,
say "EDNS 0.7".  :-)

Kind regards,
  Alfred.

--

---

From: Mark Andrews <[email-masked]>
Date: Sat, 14 Nov 2009 06:52:38 +1100

Bump the EDNS version and add a error option for when the "M" option
is not supported.  This allows for clean signaling of "M" bit
knowledge (BADVERSION) and a "M" bit error (option contains the
option codes that are not known in case there are two "M" options
in use).  "M" bit use requires EDNS1 or later.

EDNS1 can also add NXRRSET as a QUERY response code so we can clean
up this defect in QUERY as well.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bob Halley <[email-masked]>
Date: Fri, 13 Nov 2009 12:35:30 -0800

On 13 Nov 2009, at 20:05, Alfred HÎnes wrote:

>>> Alfred HÎnes <[email-masked]> wrote

It's a real problem.  If the M bit is to to be useful, you have to know that an implementation supports it.  Many implementations today will simply ignore unknown options.  So you're going to have to do one of:

	1) probe for M support somehow (maybe using an option that the server has to echo back if it understands)

	2) require that any "M" option always causes an option to be added to the response in an aware implementation

	3) increment the EDNS version number

IMO, #1 adds yet more latency and complexity and is best avoided.  #2 is equivalent to what the -bis draft recommends ("signaled acknowledgement"), but adds noise M and E bits to the option type.  #3 could work, but I'd rather we didn't try EDNS1 until EDNS0 was nearly universally understood.

I favor the approach taken in the -bis draft over the idea of M & E bits.

/Bob

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Nov 2009 15:50:35 -0500

On Sat, Nov 14, 2009 at 06:52:38AM +1100, Mark Andrews wrote:

> Bump the EDNS version 

Really?  You're offering to do the work to make EDNS1 happen, and make
it work for every mistake in EDNS0 implemations, and so on?

No-hat, I say, "I worry very much about the implications."

Chair-hat, I say, "Tell me a great deal about interoperability,
failure cases, and the draft you've written."  Where "you" denotes,
"Everyone who wants to follow this idea," of course.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 13 Nov 2009 22:37:01 +0100 (MEZ)

>
> On 13 Nov 2009, at 20:05, Alfred Hönes wrote:
>
> It's a real problem.  If the M bit is to to be useful, you have to
> know that an implementation supports it.  Many implementations today
> will simply ignore unknown options.  ...

If that can be consolidated/quantified, that rather good news!

>                           ...  So you're going to have to do one of:
>
>       1) probe for M support somehow (maybe using an option that
>          the server has to echo back if it understands)
>
>       2) require that any "M" option always causes an option to
>          be added to the response in an aware implementation
>
> IMO, #1 adds yet more latency and complexity and is best avoided.
> #2 is equivalent to what the -bis draft recommends ("signaled
> acknowledgement"), but adds noise M and E bits to the option type.
> #3 could work, but I'd rather we didn't try EDNS1 until EDNS0 was
> nearly universally understood.
>

#2 is a good design principle anyway, and I would expect it to be used
universally for future mandatory-to-understand (M=1) options.

The benefits of the M bit should be twofold:
-  allow to more clearly signal what's wrong, from the responder side.
-  allow much more graceful treatment of cases with multiple options,
   in particular with mixed M=1 and M=0 options, where I see no
   means to achieve sensical server behavior otherwise, and probing
   indeed might become necessary otherwise if the querier wants to
   insist on at least some of the options as a fallback mechanism.

The important detail I already pointed out, and which is relevant for
the judgement of #3, is that the currently ramping up deployment phase
for IPv6 and DNSSEC will push DNS software updates out, and fast
action _now_ to enable flexibility for the future wrt ENDS will have
a good chance to see rapid deployment -- independent on the specific
details.

BTW:
I'd be particularly interested in the opinions of those who have
drafts with an EDNS option in the pipeline (independent of the
particular state).

  Alfred.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 16 Nov 2009 08:19:35 +1100

> it work for every mistake in EDNS0 implemations, and so on?

I know that we check the EDNS version number and return BADVERS.
That is all that you required of a EDNS0 server and it is part of
the EDNS0 spec so it should have been implemented.  Modern versions
of dig can be used to check this.

e.g.
% dig +edns=1

; <<>> DiG 9.7.0b2 <<>> +edns=1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 29489
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; Query time: 18 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 16 07:57:59 2009
;; MSG SIZE  rcvd: 28

% 
 
ATLAS does the right thing.

% dig +edns=1 @a.gtld-servers.net ftp.uu.net +norec

; <<>> DiG 9.7.0b2 <<>> +edns=1 @a.gtld-servers.net ftp.uu.net +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 37488
;; flags: qr cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ftp.uu.net.                    IN      A

;; Query time: 358 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Mon Nov 16 08:10:29 2009
;; MSG SIZE  rcvd: 39

% 

Some of ORG's servers don't do the correct thing.  I've Bcc
[email-masked] so they can take steps to make their nameservers
compliant.

% dig +edns=1 isc.org @a2.org.afilias-nst.info.
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.7.0b2 <<>> +edns=1 isc.org @a2.org.afilias-nst.info.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 60171
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; WARNING: Messages has 8 extra bytes at end

;; Query time: 179 msec
;; SERVER: 2001:500:40::1#53(2001:500:40::1)
;; WHEN: Mon Nov 16 08:12:31 2009
;; MSG SIZE  rcvd: 21

%

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Nov 2009 10:14:52 -0500

> of dig can be used to check this.

But that's not the issue I was trying to raise.  It has taken more
than 10 years to get reasonably wide but not complete deployment of
EDNS0, and as you've pointed out some of the deployments don't seem to
know what to do with EDNSn, n>0.  Therefore, planning on EDNS1 as the
quick answer to a problem is probably unwise, and to do it we need
people who will in fact write the documents, figure out what all the
corner cases are, and so on.  

Another way to put this, with my Chair/nag hat on, is that we need to
become better at getting work through this working group if we think
we can do things like promulgate EDNS1.  RFC 5702 is a good example of
this: it took us years to complete that "short", "quick and easy"
document (the -00's date is 5 July, 2006).  I'm not trying to point
fingers.  I am trying to be realistic about how easy it is to do
something like "just" bump the EDNS version number.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Nov 2009 09:48:21 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> EDNS0,

And if people want the functionality in E or M options they will
deploy EDNS1.  Just have EDNS1 servers reject E and M options if
the EDNS version is 0.  We are talking about incremental feature
deployment here.

> and as you've pointed out some of the deployments don't seem to
> know what to do with EDNSn, n>0.

Which is more a lack of having a formal conformance program than
anything else.  I'm pretty sure that once the offending vendor is
notified that there will be a fix in the pipeline.

> Therefore, planning on EDNS1 as the

It doesn't have to be quick.  It just has to be correct.

> something like "just" bump the EDNS version number.

RFC 5702 had the underlying protocol change under it with the
introduction of NSEC3 and unfortunately RFC 5155 didn't state how
to manage future algorithms clearly enough that we had to have a
large debate over whether there should pairs of algorithm numbers
allocated or not.

Mark