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

From: Thomas Narten <[email-masked]>
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.  
> 
> And has at least one client implementation of EDNS0 been tested for 
> interoperability with a large number of the deployed DNS servers?
> 
> 
> 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. 

Thomas