Subject: [dnsext] WGLC ENDS0-bis

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 May 2011 10:25:42 -0400

Dear Colleagues

This message starts a Working Group Last Call for
"Extension Mechanisms for DNS (EDNS0)" located at
http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-05
As the document is replacing a Standards Track document this document is 
on Standards Track.

This WGLC will conclude on midnight May 25'th 2011 EDT.

This document obsoletes RFC2671.  The big changes from RFC2671 are:
   - explicit usage of RFC2119 terms and labeling EDNS0 support as MUST;
   - discussion on payload sizes and selection;
   - closing of the extended label types registry and classifying 	
        bit-labels as Historic;
   - cleanup of IANA actions (that did not take place when RFC2671
       was issued).

Other than these there are no changes from RFC2671.

Please send statements that you have reviewed this document and if it 
raised any issues. Remember we need 5 a minimum of 5 reviewers to say 
they reviewed the document.

     Olafur & Andrew
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Brian Dickson <[email-masked]>
Date: Tue, 10 May 2011 11:57:55 -0400

I have reviewed the document, and support its publication.

Brian Dickson

On Tue, May 10, 2011 at 10:25 AM, Olafur Gudmundsson <[email-masked]> wrote:

> As the document is replacing a Standards Track document this document is on
> Standards Track.
>
> raised any issues. Remember we need 5 a minimum of 5 reviewers to say they
> reviewed the document.
>
>    Olafur & Andrew

---

From: Chris Thompson <[email-masked]>
Date: 10 May 2011 18:02:40 +0100

>As the document is replacing a Standards Track document this document is 

Niggle: in section 6.1

   The OPT RR MAY be placed anywhere within the additional data section.
   Only one OPT RR MAY be included within any DNS message.  If a message
                                                                 ^^^^^^^
   with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be
   returned.

Surely "request" is meant in that last sentence rather than "message"?
A reply containing multiple OPTs is malformed, certainly, but that's not
not to say it should itself recursively generate a reply!

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 May 2011 19:09:24 +0100

A few nits:

Section 1. "The maximum allowable size of a DNS Message is limited
to 512 bytes." Insert "transmitted over UDP without EDNS0".

"Many of DNS's protocol limits are too small for uses which are commom or
desired to become common." Is there more than just the UDP packet size?
Should it say "This limit is too small for uses which are commom or
desired to become common, and the cost of using TCP instead of UDP for
most requests is too high."

The last two sentences of paragraph 3 repeat paragraph 2.

Otherwise it looks OK to me.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 May 2011 15:14:29 -0400

>http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-05

Count me disgruntled.  I have a few comments on this document.

We need EDNS0 to be cleaned up.  We need this document.  The document 
is not a mess nor a total failure (hey, that's the good news) but 
there are a few items that need to be addressed before it is ready to 
go.

First items from the document:

Item 1

#3.  EDNS Support Requirement
#
#   EDNS support is practically mandatory in a modern world.  DNSSEC
#   requires EDNS support, and many other features are made possible only
#   by EDNS support to request or advertise them.  Many organizations are
#   requiring DNSSEC.  Without common interoperability, DNSSEC cannot be
#   as easily deployed.

Horse and cart placement.  Don't hinge EDNS0 on DNSSEC.  ENUM/DDDS 
needs it too, as well as IPv6's AAAA record answers.  Other future 
needs will likely come along.  I think that this section, if it is to 
highlight that DNSSEC needs it, should reference the existing 
documents that state why EDNS0 is needed.  BTW, I think that the 
requirement to use EDNS0 is more clearly stated for ENUM than DNSSEC.

Item 2

# 6.8.  Middleware Boxes

This section is a problem.  Middleware boxes aren't well defined 
(yes, there is the parenthetical list of examples), lacking 
references to documents that provide definitions here.  Going beyond 
that I don't know what this document is trying to impart.  Are these 
requirements on non-DNS processes that are acting as stateful proxies 
for DNS messages in dealing with EDNS0 records?

Item 3

# 7.  Transport Considerations
#
#...
#   Responders who do not implement these protocol extensions MUST
#   respond with FORMERR messages without any OPT record.

This requirement cannot appear here (as written).  No document can 
set a requirement on existing and deployed software and expect 
compliance.

Perhaps this can be substituted:

"A DNS message server electing not to support this definition of 
EDNS0 MUST respond with a return code (RCODE) of FORMERR when 
detecting an OPT RR in the additional section of a query message." 
Essentially, an implementation can say they are compliant with the 
document in saying "we don't play" EDNS0.  (But I don't think that is 
what the authors intended.)

Item 4

RFC 2119 language

There are a few instances of lower case "must" in the document. I ran 
across that looking for something else.  In general, make sure all 
RFC 2119 language stands out.  (I realize that some "must"s appear 
before 2119 is invoked - I'm not counting those.)

Item 5

#6.4.  Fallback
#...
#   If an implementation detects that some servers for the zone support
#   EDNS(0) while others would force the use of TCP to fetch all data,
#   preference SHOULD be given to those support EDNS(0).

I am no longer convinced that it is wise to state preferences like 
this.  It is backfiring in IPv6 transition (preferring IPv6 over IPv4 
for DNS traffic, for one).  I would urge this to become a 
consideration - an implementer ought to weigh that TCP requires more 
set up time.  In retrospect, I think this is just a bad idea to 
include.  Let implementors deal with this without a specification 
hanging over them.  (TCP is not proving to be *that* bad.  It works 
good for other protocols.)

Item 6

Tone of voice/perspective

I find that when text gets personal, the feeling changes.  In this 
document, the word "you" appears twice in one paragraph:

Item 7

#6.7.  Payload Size Selection
#
#   Due to transaction overhead, it is unwise to advertise an
#   architectural limit as a maximum UDP payload size.  Just because your
#   stack can reassemble 64KB datagrams, don't assume that you want to
#   spend more than about 4KB of state memory per ongoing transaction.

"Just because your $X can" do something makes it sound like a 
challenge is being made.

In total, the section here is needed, but I think it comes across 
poorly.  As someone eyeing this as something I would have to conform 
to, seeing "SHOULD...such as" makes it hard to write the formal 
requirement and test case.  In the old days we got away with "to 
simplify implementations" (RFC 1034, remember), why can't we do that 
here.  "To simplify implementations" start with 4K, then drop to 
something small enough for Ethernet (1280) before dropping EDNS0 
altogether.  I think this would go a long way to avoiding the "path 
MTU" discussions that go around.

Missing material

Item 8

I think the point that EDNS0 is a hop-by-hop marshaller of 
parameters, and not an end-to-end signalling mechanism is not clear 
enough.  I don't think the architectural placement of EDNS0 is clear 
described.  This should be in the introductory material.

Item 9

Section 6.3 needs more material.  It should say how a cache (server) 
would make use of EDNS0, besides saying that OPT RR's are not cached 
(or DNSSEC signed!).

This goes hand in hand with Item 8.  Perhaps "more material" is 
stronger than it should be.  Considering a cache may or may not mean 
the same thing as a caching server, the discussion would be different.

A caching server needs some instructions on how to deal with a client 
of it using one set of EDNS0 parameters and a server to it with 
different EDNS0 preferences.  What might a proposed EDNS0 option need 
to specify about the behavior at a caching server?

Item 10

What is the implication of an EDNS0 buffer size of less than 512 
bytes?  What if the size is smaller than what a header requires? 
(E.g., bufsize=4 in dig-speak?)  Can the server respond with FORMERR 
if that is bigger than the buffer advertised?  We ran across these 
questions when trying to do some testing, and found the specification 
to be missing on that.  Stating that sizes below 512 can be treated 
as 512 would be sufficient, but some lower limit ought to be 
mentioned.

In closing, thanks for...

Stating that implementations are expected to skip/ignore the options 
they do not implement and that if the requestor needs confirmation an 
option was used, the option has to define the "ack."  (Bottom of page 
6.)  This is a needed "feature" which I think wasn't in the original 
RFC.  (It it wasn't there, oops, and uh, then there's no thanks to 
give. ;))

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 May 2011 10:18:52 -0400

On 2011-05-10, at 10:25, Olafur Gudmundsson wrote:

> Please send statements that you have reviewed this document and if it raised any issues. Remember we need 5 a minimum of 5 reviewers to say they reviewed the document.

Summary

Lots of nits below, some (to me, at least) somewhat substantial. I would like to see some edits before the document is sent up the tree, since I think there is some low-level ambiguity in the text and if the goal is clarification then these seem worthy of fixing.

I'm happy to work with the authors on specific text where there is consensus to edit if that seems helpful.

Abstract

"based on 10 years of deployment experience" seems like an empty phrase in the absence of citations of any study of EDNS0 penetration. I would delete it.

Section 1 ("Introduction")

"The maximum allowable size of a DNS Message is limited to 512 bytes". This is not true in general (it's true for DNS messages sent using UDP transport without EDNS0).

"uses which are commom [typo, sic] or desired to become common" is grammatically inelegant and unsupported. Desired by whom? Perhaps better to cite specific examples and avoid expressing unsubstantiated desire.

"RFC 1035 does not define any way for implementations to advertise their capabilities". Since the DNS protocol is variously implemented for different purposes (resolver, authority-only server, update client, etc) it might be better to re-cast this as "[RFC 1035] does not provide any mechanism for capabilities negotiation between DNS clients and servers".

"[RFC2671]" seems to be bare ASCII rather than a reference (this is more obvious in the HTML rendering of the document).

"This document Obsoletes Extended Labels". Obsoletes, or deprecates?

Section 2 ("Terminology")

Various terms are capitalised as if they are defined phrases, but do not appear in Section 2 ("Terminology"). Examples include "Message Format", "DNS Message", "DNS Message Header", "Traditional DNS Messages", "Extended Label Types", "Option Codes", "(Un)extended agents", "(Un)extended DNS". As noted elsewhere, "Middleware Boxes" could do with a definition.

Section 3 ("EDNS Support Requirement")

"practically mandatory in a modern world" is subjective and ambiguous. The section would benefit from the normative language being spelt out in its own paragraph, and the justification/preamble being re-cast to avoid subjective phrases and instead call out specific examples (e.g. from DNSSEC and ENUM) for which EDNS is necessary or useful.

Section 4.3 ("UDP Message Size")

"Today"? "many organizations"? "special tricks"?

Given that DNSSEC requires an EDNS0 pseudo-header in a request in order to react to DO=1, is it a suitable example to justify the existence of EDNS0 at all? An unextended DNS message can't be used for secure answers anyway. I'm not explaining myself very well, but it seems like there's some avoidable chicken/egg juxtaposition here.

Section 5 ("Extended Label Types")

"obsoleted" or "deprecated"? What is the required action of DNS Requestors and Responders who receive messages that contain extended label types?

The direction to the IANA seems out of place in this section (perhaps replace with an xref to Section 9).

Section 6.1 ("OPT Record Definition")

Several aspects of the OPT RR are defined in later sub-sections of section 6, so 6.1's title seems not entirely appropriate.

Section 6.5 ("Requestor's Payload Size")

The second paragraph has me scratching my head, since it implies that a requestor has knowledge about the cleanliness of the UDP/IP path to a server without describing how it acquires that knowledge. Some guidance about how requestors might probe each path in order to establish a sensible payload size seems appropriate.

I appreciate there is some more detailed guidance in 6.7; perhaps that could be extended and an xref placed in 6.5, or perhaps this section could become a subsection of 6.7.

Section 6.6 ("Responder's Payload Size")

There is algorithmic guidance given in this section to allow an implementor to choose a suitable payload size, but it seems vague (e.g. "meaningless QUERY"). More specific guidance seems like it would be helpful.

I appreciate there is some more detailed guidance in 6.7; perhaps that could be extended and an xref placed in 6.6, or perhaps this section could become a subsection of 6.7.

Section 6.7 ("Payload Size Selection")

See above.

Section 6.8 ("Middleware Boxes")

See above regarding definition of "Middleware Boxes". (Incidentally, "Middleware" as a noun seems better to me, once defined, than "Middleware Boxes".)

Is the prohibition on limiting UDP-transport DNS messages to 512 bytes by middleware necessary in the case where middleware performing deep packet inspection knowns unequivocally that it is dealing with an unextended DNS message?

"MUST understand the OPT record" -- do you mean to say that such devices must support EDNS0? There's a difference between understanding and processing.

Section 6.11 ("OPT Options Code Allocation Procedure")

Shouldn't this direction be moved to the IANA Considerations section, since it describes an attribute of a registry?

Section 9 ("IANA Considerations")

"EDNS Extended Label Type", "EDNS Option Codes", "EDNS Version Numbers", and "Domain System Response Code" are not the names of the registries created by RFC 2671, at least not as seen at <https://www.iana.org/protocols/> (unless I'm reading it wrong). Since this section contains direction for the IANA, it seems appropriate to make sure the registries referred to are unambiguously-named. Worth checking, anyway.

"IANA is advised to re-parent these sub-registries to this document",
  "We request that this registry be closed" --

I don't know that "closed" or "re-parent" are sufficiently unambiguous when it comes to describing an action on a registry. Does "closed" mean that the registry should no longer accept additions, or that it should be deleted such that nobody can find it any more? Does "re-parent" imply that the requirements for changes to the registry (e.g. "RFC Required", "IESG Approval") are inherited, and that the existing contents of the registry should be preserved?

No doubt any ambiguity would be cleaned up during IANA review of the document, but it doesn't hurt to get it right first time.

"This document assigns EDNS Extended RCODE 16 to 'BADVERS'" -- it seems like a good idea to specify precisely which registry the document is requesting be updated, here.

In general a quick review of RFC 5226 might help clean up this section.

Joe

---

From: Alex Bligh <[email-masked]>
Date: Wed, 11 May 2011 15:28:19 +0100

--On 11 May 2011 10:18:52 -0400 Joe Abley <[email-masked]> wrote:

> See above regarding definition of "Middleware Boxes". (Incidentally,
> "Middleware" as a noun seems better to me, once defined, than "Middleware
> Boxes".)

Do we really mean "Middleware boxes" (which presumably means boxes that
run Middleware) or do we mean "Middleboxes" (boxes that sit between
client and server doing unspeakable things to packets, the software
on which is certainly not middleware). I think we mean "Middleboxes".

There is a taxonomy of Middleboxes/Middleboxen in
  http://tools.ietf.org/html/rfc3234

which might (or might not) help any definitional issue.

-- 
Alex Bligh

---

From: João Damas <[email-masked]>
Date: Wed, 11 May 2011 16:35:40 +0200

thanks all for the comments. I will be doing an extra pass on the doc beginning on Monday so all comments are welcome, particularly those that point to ambiguity or any mistakes that slipped through (style being a more personal matter)

Joao

---

From: Ray Bellis <[email-masked]>
Date: Thu, 12 May 2011 15:19:10 +0000

Ed,

Taking two of your paragraphs that I believe are related:

> 
> # 6.8.  Middleware Boxes
> 
> This section is a problem.  Middleware boxes aren't well defined (yes, there is the parenthetical list of examples), lacking references to documents that provide definitions here.  Going beyond that I don't know what this document is trying to impart.  Are these requirements on non-DNS processes that are acting as stateful proxies for DNS messages in dealing with EDNS0 records?

I believe the intent of 6.8 is to reflect 5625, where I put in text along the lines of "if you're trying to be transparent, make sure you don't strip the EDNS0 options".

Hence it's a "get out" for the generally accepted principle that EDNS0 is "hop by hop", for those cases where the middlebox is intended to be an "invisible" hop.

> Missing material
> 
> Item 8
> 
> I think the point that EDNS0 is a hop-by-hop marshaller of parameters, and not an end-to-end signalling mechanism is not clear enough.  I don't think the architectural placement of EDNS0 is clear described.  This should be in the introductory material.

However as you say I think the hop-by-hop principle does need more text - in fact I couldn't find any text in either this document or its predecessor that was explicit about this, despite it being well understood amongst DNS protocol geeks.

This came up when I was reviewing draft-kaplan-dnsext-enum-sip-source-ref-opt-code for the Independent Submissions Editor, and it's relevant to draft-crocker-dnssec-algo-signal too.

In both cases I wanted to cite the hop-by-hop principle but couldn't find relevant chapter and verse to back it up.

kind regards,

Ray

---

From: Edward Lewis <[email-masked]>
Date: Thu, 12 May 2011 16:38:52 -0400

At 15:19 +0000 5/12/11, Ray Bellis wrote:

>I believe the intent of 6.8 is to reflect 5625, where I put in text along
>the lines of "if you're trying to be transparent, make sure you don't strip
>the EDNS0 options".

I think that is a fine principle and well stated - what the section 
is trying to impart.  But I'm talking more basically about a lack of 
a definition of middle box in this document.  What I'm hinting at is 
including a reference where the term is already defined or a 
paragraph defining the term.

>In both cases I wanted to cite the hop-by-hop principle but couldn't find
>relevant chapter and verse to back it up.

More text is needed then.  Given some time I'll try to come up with something.

In 
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=56283&tid=1305232265 
I wrote this "the fact that the DNS is not a client-server  protocol, 
as it is usually treated in text, but a client-cache-server 
 protocol".  Beginning with that, there is a difference between 
hop-by-hop and end-to-end in most DNS messages supporting a 
transaction.  The data model, backed up by DNSSEC, is pretty much 
built to be end-to-end.  EDNS0 on the other hand is hop-by-hop, 
taking parameters governing the message exchange from one entity to 
the next, not along the entire end-to-end path that the data travels.

...That's a first scratch of what is needed.  Admittedly it is not 
fleshed out enough to be clear and come to the point.  But I'm just 
squeezed for time now.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 23 May 2011 23:00:01 +0200

>   - cleanup of IANA actions (that did not take place when RFC2671

I would like to see guidance to implementors how they can actually
detect EDNS0 support or the lack thereof.  Alternatively, a minimum
level of support could be made mandatory, eventually making the
existing detection logic obsolete.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 May 2011 17:08:19 -0400

>existing detection logic obsolete.

As far as declaring "a minimum level of support": an RFC cannot say 
"you must implement me, even if you were implemented last year." 
That just doesn't work.

For backwards compatibility, we are stuck with probing for 
functionality.  This is a weakness of the DNS architecture.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Joao Damas <[email-masked]>
Date: Tue, 24 May 2011 09:37:40 +0200

On 23 May 2011, at 23:08, Edward Lewis wrote:

> As far as declaring "a minimum level of support": an RFC cannot say "you must implement me, even if you were implemented last year." That just doesn't work.
> 

Yep.

> For backwards compatibility, we are stuck with probing for functionality.  This is a weakness of the DNS architecture.
> -- 

DNS transactions are meant to take a minimum of resources on either side. That is kind of contrary to a feature negotiation handshake ahead of the query (though one could cache a server's characteristics after the first exchange if the two messages, query and response, are able to transport that information. I think that's all that could be said here

Joao

---

From: Florian Weimer <[email-masked]>
Date: Wed, 25 May 2011 19:49:47 +0200

* Edward Lewis:

> "you must implement me, even if you were implemented last year." That
> just doesn't work.

A vendor which errors out or drops EDNS0-enabled queries would no
longer be able to claim to implement the current version of the DNS
protocol.  It worked for HTTP/0.9 and SSLv2.  It did not work for
extended label types or RIPv1.

> functionality.  This is a weakness of the DNS architecture.

It's not an architectural problem, I think.  You could implement
pretty reliable signaling, but EDNS0 doesn't do it.  (Basically, you
need two bits, the query contains 01, and the response 10, so that you
can detect stripping and dumb reflection.)

Anyway, what I'm asking for is documentation for the probing
algorithm.  Are there existing implementations which use the presence
of DNSSEC data as an indicator for EDNS0 support, as suggested in the
draft?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext