Re: [dnsext] draft-vandergaast-edns-client-ip-00.txt

[Nicholas Weaver <[e-mail]>]

On Feb 2, 2010, at 10:46 AM, Matthew Dempsky wrote:

> On Tue, Feb 2, 2010 at 10:27 AM, Nicholas Weaver
> <[e-mail]> wrote:
>> Authority doesn't know the option but follows RFC 2671 5.3:  The server replies with NOTIMPL, FORMERR, or SERVFAIL.
> 
> I don't understand RFC 2671 5.3 as requiring a server to reply with
> one of those codes (otherwise it would have made more sense to specify
> which one).  Instead, I read it as a warning/reminder to the reader
> that a server might not gracefully handle new extensions, and clients
> should be prepared to deal with that possibility when making use of
> them.

To me it sounds like it should:

5.3. Responders who do not understand these protocol extensions are
     expected to send a response with RCODE NOTIMPL, FORMERR, or
     SERVFAIL.  Therefore use of extensions should be "probed" such that
     a responder who isn't known to support them be allowed a retry with
     no extensions if it responds with such an RCODE.  If a responder's
     capability level is cached by a requestor, a new probe should be
     sent periodically to test for changes to responder capability.


Protocol extensions would IMO, include an unknown options.

But in any case, there are graceful failure mechanisms no matter what the authority does: ignore it, reply with any sort of failure, or silently not reply: all can be handled easily.