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

[Nicholas Weaver <[e-mail]>]

On Feb 2, 2010, at 10:06 AM, Jim Reid wrote:

> On 2 Feb 2010, at 17:13, Nicholas Weaver wrote:
> 
>> You can easily do fallbacks for those who don't speak this EDNS0 option:  If you don't get a response on the first query, retry without this option.  If that works, have your next 2-3 queries be both (with and without).  If those two or three also fail, record that authority as not supporting, and don't use the query in any subsequnet responses
>> 
>> Voila, you have fallback: only ever hits a timeout the first time for authorities which can NOT respond to a request with an unknown EDNS option, and even for those, its only 1 timeout latency and 2-3 extra queries from each recursive resolver which bothers with this option.
>> 
>> 
>> This is why the basic scheme is so beautiful: it does NOT require changes to anyone who doesn't actually care about this option.  This is the kind of thing EDNS options should be designed for: optional behavior amongst a subset of the system.
> 
> So, your idea of optional behaviour in some circumstances is to increase DNS latency and generate extra queries. I see...

No.  There are 4 cases, all of them harmless, two which add no latency or additional queries, one which adds one RTT latency on the first query, and one which adds one timeout of latency on the first query and 2-3 additional queries.


Authority knows what the option is:  No added latency, no nothing.

Authority doesn't know the option but follows RFC 2671 5.3:  The server replies with NOTIMPL, FORMERR, or SERVFAIL.  So setry without and cache the behavior of the authority.  Result?  One RTT of added latency on the first query to the authority to learn the state.  No other effect.

Authority doesn't know the option and just ignores it in violation of RFC 2671:  No effect.

Authority doesn't know the option and does a silent failure in violation of RFC 2671 (aka, BUGGY!): Retry after timout, so 1 timeout of added latency on the first query and 2-3 doubled queries subsequently to learn the state of the authority.


This is the whole point of EDNS0 options: there is graceful failure when the authorities don't understand them, both when they follow the RFC and even when they don't!  

Harm to non-compliant authorities is effectively nonexistant: one RTT latency if you follow RFC 2671 for unknown options, one timeout RTT if you don't.