Re: [dnsext] WGLC ENDS0-bis

[Edward Lewis <[e-mail]>]

At 10:25 -0400 5/10/11, Olafur Gudmundsson wrote:

>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 [phone]

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?