Subject: Re: draft-ietf-dnsind-edns0-01.txt

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 31 Mar 1999 22:40:35 -0500

Thomas,

From:  Thomas Narten <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
cc:  [email-masked] (Erik Nordmark)
Date:  Wed, 31 Mar 1999 15:04:53 -0500

>The IESG discussed this document during its last telechat, and the
>following issues were raised:
>
>> 1. Given that DNS is a "core Internet protocol" and that this is a
>> significant change, and the potential impact on the Internet if this 
>> thing fails to interoperate, I wonder if this specification should be 
>> approved as Experimental (per RFC 2026 section 4.1.1) until there are 
>> demonstrated interoperable implementations.  

The UDP size limit of DNS is also an increasingly critical problem.
It will be a barrier to DNSSEC (signatures and keys causing UDP
overflow), IPv6 (bigger address records leading to UDP overflow), more
root servers (more address records leading to UDP overflow), etc.
deployment.  The IESG should be yelling at the DNSIND working group to
get some way to expand DNS's limits out faster, not looking for ways
to delay putting it on the standards track.

This proposal is the clear consensus of the WG as to the best solution
for this problem.  I had an alternative proposal for the specific
problem of UPD size that I withdrew to strengthen the consensus and
speed getting edns0 on the standards track.  In fact, one reason for
splitting the original edns draft into edns0 and edns1 was to try to
get edns0 on standards track sooner.

>> And has at least one client implementation of EDNS0 been tested for 
>> interoperability with a large number of the deployed DNS servers?

There aren't a large number of DNS codebases.  Others can answser
better than I as to the exact state of implementation but persons
affiliated with most the organizations that I know of as doing curretn
DNS development were involved in the WG. I should think the authorship
by Paul Vixie and WG consensus should really be enough.  Don't the
current IESG members know who Paul Vixie is?

By the way, you refer to "demonstrated interoperable implementations".
That sounds like Draft Standard and isn't what section 4.1.1 of RFC
2026 says.  It says the IESG "may require implementation and/or
operational experience" which sure sounds like something at least a
bit less to me.

>> 2. In section 4.6:
>> 
>>    VERSION         Indicates the implementation level of whoever sets it.
>>                    Full conformance with this specification is indicated by
>>                    version ``0.''  Note that both requestors and responders
>>                    should set this to the highest level they implement,
>>                    that responders should send back RCODE=BADVERS and that
>>                    requestors should be prepared to probe using lower
>>                    version numbers if they receive an RCODE=BADVERS.
>> 
>> This doesn't sound right to me.   If the client sets the version number
>> on the request to the highest level it implements, and the server 
>> implements a higher version number, what's the point in having the
>> server return data that the client cannot use?  
>> 
>> I suggest that this should read:
>> 
>> Requestors should set VERSION to the highest level they implement.
>> Responders should, if possible, respond using the same EDNS
>> version as the requestor.   If the responder does not support
>> the version used by the requestor, the responder MAY return a
>> response with a lower version than supplied by the requestor,
>> setting RCODE=BADVERS in the response.  Since this still 
>> leaves open the possibility that the responder will return a 
>> version not supported by the requestor, a requestor which 
>> supports multiple EDNS versions should be prepared to reissue
>> the request with a lower version than the responder returned, 
>> if the responder returns RCODE=BADVERS.
>
>Actually, I wonder if the MAY is even desirable. Seems cleaner and
>simpler to just respond with an error and the version number that is
>supported. Attempting to respond to a query with a higher version than
>you support seems like it could lead to interesting (and undesirable)
>behavior. I.e., the responder might well process the query incorrectly
>because it doesn't properly understand the semantics. 

I agree that the wording isn't all that great here and could be clearer.

>Thomas

Thanks,
Donald

---

From: Jim Bound <[email-masked]>
Date: Thu, 01 Apr 1999 13:23:54 -0500

Thomas,

>to delay putting it on the standards track.

Donald raises a good point here.  DNSIND is made up of much experienced
implementors and architects.  I think the IESG second guessing this is
not right and should consider to the WG consensus in this case.

>current IESG members know who Paul Vixie is?

This is critical.  If Paul is behind it it means ISC is behind it and
also Microsoft is behind it and they too are building a code base.
BIND is a specical case as you stated.  But because it is truly tested
for interoperation on a wide basis by some very savy implementors and
the bindworkers mail list.

I for one would like to see much more stronger technical disagreement
from the IESG on this one before I as a DNSIND WG member can just agree
with the IESG.  Lets have some down and dirty technical discussion with
why the IESG thinks there is an issue here.

Sincerely,
/jim
DNSIND Internet "ENGINEERING" Task Force WG Member

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 01 Apr 1999 13:01:33 -0800

Hi,

> I should think the authorship

For the record:

I am not Paul Vixie, however I can speak authoritatively for ISC.

ISC has no plans to include support for EDNS0 in BIND version 8.  The
hackery on top of hacks necessary to implement EDNS0 in BIND 8 would
take more resources than we have available.  It is also not clear
whether the use of BIND 8 in situation in which EDNS0 is necessary
(e.g., production use of DNSSEC) is a good idea.

BIND version 9, however, will include EDNS0 support and since it is
multi-processor scalable, multi-threading, and has a full DNSSEC
implementation, it is likely to be much more widely deployed in
situations that require EDNS0.

For reference: BIND version 9 is scheduled to go into beta test in
October.  It would be very annoying if the protocol changes.

Regards,
-drc

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Apr 1999 10:33:28 -0500

Jim,

The issue that was discussed within the IESG is that the DNS is a
critical part of the Internet infrastructure. Consequently, anything
that has the potential for significantly impacting the overall health
of the DNS gets quite a lot of scrutiny.  The potential repercussions
of something going wrong here are immense. 

Having said that, the IESG does understand that DNS extensions are
needed (e.g., to allow for bigger payloads). The specific question
that is being asked is whether we should consider putting the EDNS0
extensions on an experimental track, in order to get more experience
before putting it on standards track. The rational for asking the
question comes from RFC 2026, where it says in 4.1.1:

>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation.
> 
>    The IESG may require implementation and/or operational experience
>    prior to granting Proposed Standard status to a specification that
>    materially affects the core Internet protocols or that specifies
>    behavior that may have significant operational impact on the
>    Internet.

Thus, the IESG is doing its duty in asking questions here.

Note that the IESG is asking the WG about this issue (not
dictating). During the telechat discussion, there were multiple
viewpoints on how to proceed. The IESG is seeking additional
input/comment.

>From the other responses to the following question:

> interoperability with a large number of the deployed DNS servers?

My conclusion at present is that the answer is no.

Thomas

---

From: Jim Bound <[email-masked]>
Date: Fri, 02 Apr 1999 09:15:05 -0500

> October.  It would be very annoying if the protocol changes.

As a user of what v9 will be as a vendor I agree.  Which is why I would
like to see a bit more technical discourse from the IESG on why they
believe this spec has an issue.  I simply don't trust "in this case"
(not all cases) high level statements like we got from the AD passed
down to this.  The IESG is not infallable and in this case I would like
to see hands on technical discussion regarding their issues either
second hand distributed by them and the authors, or better yet directly
with this WG.  One of my fears is that the IESG's "perception" of what
DNS is doing today and what it will do tomorrow is not a protocol issue
but a subjective speculative analysis on what "could happen".  This
should be discussed in depth on this list or privately with the authors.
But as this is an open standards organization and community doing it on
this WG mail list seems more appropriate.

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 02 Apr 1999 11:56:26 -0500

Thomas,

>of something going wrong here are immense. 

I can understand this clearly and well.  But your words here expound on

>to delay putting it on the standards track.

Is valid too that this does need to be on standards track.  This again
is the issue of "experimental" in 2026.  I guess we should just admit in
the IETF when something gets PS status it can be widely implemented?
Going to PS does not mean that the Internet will use it?  Or does the
IESG believe this is true (this is a tell-taling question for sure)?

>>    usually represent a strong argument in favor of a Proposed Standard

I would agree with this if for example we had a WG that was doing
something like dynamically renumbering addresses for TCP/UDP connections
as new numbers were provided or redirecting protocol control blocks for
anycast addresses for Mobile on the fly.  We really need to see some
implementation for such things IMO and then serious checks.

It appears EDNS0 in fact is the same but its not really because the
implementors of DNS do serious interoperability testing before they
unleash it on the community.  In addition the BIND code base anyway has
a network with all the vendors the minute a serious breech occurs to fix
very bad behavior quickly.  The spec uses options and except for MTU
issues I don't for one see any real danger.

I guess it would help me anyway if the IESG listed the technical dangers
in detail in the spec in addition to the fact that this affects the
protocol widely used on the Internet, which is completely valid for the
IESG to do a logic check on in all such cases.

I see the dangers but the way they have been architected I don't off the
top of my head see all the failure modes to the severity your reply
suggests could happen.

>Thus, the IESG is doing its duty in asking questions here.

Fully agree and glad they are really checking this out.

But I would like to see more than this is DNS and important, but also
what in EDNS0 technically is causing the risk in the IESG deliberations
so we can discuss it.  The WG and Chair believed it correct to suggest
PS.  I think the IESG owes us a bit more discussion.

>viewpoints on how to proceed. The IESG is seeking additional

I believe that and I am off the IESG is a dicator stuff per some mail
with a few of our Sr. IETF folks.  I too am trying to discuss it and not
saying the IESG is wrong?  I am asking what specifically and technically
is causing the pain with going to PS?

This idea is not new and has been floated around for over a year.  

>My conclusion at present is that the answer is no.

Correct.

But none of us who support ISC BIND code base and I doubt the other DNS
implementations are going to put EDNS0 into production on the root
servers, which my company has several as an OS, when the spec may change
yet again.  

So I would like to see what constitutes "interoperability" to be stated
differently above as that is unrealistic.  Possibly a bake-off where it
is used or at an IETF meeting.  

This is significant in the code base and to the architecture and not
believing this work is standards tracked is very scary to invest in.  

But after hearing more details of the fear here by the IESG and we still
can't convince you I would suggest a potential compromise is some
prototype interoperability that the change in fact does interoperate and
that some resemblance of scalability is simulated.  But like I said more
details from the IESG would help scope such a discussion.

I appreciate you asking for input too.  But right now I am biased I
agree that in this case the WG contains the experts and implementors and
the IESG does not for DNS.  The check for any error here is that it is
PS and not DS.  DNSSEC is a perfect example where these DNS folks had a
PS document began to implement it and said "whoaaa" and went back to the
drawing  board.  Same will happen here.

Lets have the nitty gritty technical discussion?

The first issue in the spec is? ???????????????

thanks for doing your job,
/jim

---

From: John Gilmore <[email-masked]>
Date: Sat, 03 Apr 1999 21:18:01 -0800

2c (or maybe 2 euros) from me on this.

I think EDNS0 should be standards track; it clearly is the intent of
the WG and developers that it become a standard.

I have put a small amount of design time into DNSSEC migration issues
and feel that we don't need EDNS0 to deploy DNSSEC.  It will make
DNSSEC more efficient, perhaps, but at this time I don't believe it is
*needed*.

IESG is right that MTU issues are a true pain in the ass.  My IPSEC
project has just spend more than a month working around major MTU
issues that result when people implementing poorly spec'd Path MTU
RFC's encounter IPSEC tunnels that are slightly smaller than the local
interface which the packet started on, firewalls which swallow ICMP
MTU updates (DF-and-too-big ICMP messages), RFC-compliant but broken
Microsoft UDP's that won't fragment and merely swallow oversize
outgoing UDP packets without reporting an error, etc.  The result was
that some web sites were simply inaccessible until we did some kludge
workarounds (fragmenting encapsulating packets that contain "Don't
Fragment" packets, and probably sending back ICMP too-big's even
though we *did* forward the datagram).  There is no real "fix",
without months or years of spec work and re-implementation all over
the Internet; it's just a reality of the Internet-as-it-is that we
have to work around.  (For those who want the gritty details, search
for MTU in the [email-masked] mail archives at
http://www.nexial.com/mailinglists/.)

DNS with a larger MTU *will* need serious operational testing on the
Internet, not just in a BIND lab, before we're sure it deals well with
operational problems like this.  edns0-01 is quite fuzzy about how
Path MTU interacts with EDNS.  It doesn't even mention whether DNS UDP
packets are to be sent with DF or without DF; doesn't say anything
about how the DNS application is supposed to tell just how big a UDP
packet its kernel is willing to reassemble (so it can advertise this
value), etc.  How to recover by backing down the advertised buffer
size when it gets no response and retries.  (Perhaps the large response
is being eaten somewhere along the way, and the ICMP error report is
also getting eaten; this is the missing part of the RFC 1191/1435 Path
MTU that makes some TCP sites inaccessible from behind <1500-byte MTU
tunnels).  The number that edns0-01 suggests advertising for Ethernet
(1280) is clearly pulled out of an unidentified hat, seeming to relate
more to the 1500-byte Ethernet packet size than to the size of any
reassembly buffer in any deployed systems.  (NFS tends to use 8K UDP
packets, so any site that supports NFS will have a max over 8K, not
1200 bytes).  This field is billed as being unrelated to the MTU, but
doesn't seem quite to be unrelated...

It should be possible to hack up something from BIND 8 that does
EDNS0's larger MTU's within a few days for messing around with.  I sent
Paul a patch years ago that would accept datagrams larger than 512
(and detect when they had been truncated by the incredibly poorly
spec'd BSD kernel interface to UDP).  He didn't want to put it in
until we had a real spec for larger DNS packets.  OK, now we do...it
shouldn't take til November.

	John