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

[Nicholas Weaver <[e-mail]>]

On Feb 2, 2010, at 8:46 AM, Jim Reid wrote:

> On 1 Feb 2010, at 22:07, John Payne wrote:
> 
>> Yes, it adds complexity to the recursive nameservers _that want to send the information_.
>> 
>> Where else is it adding any complexity?
> 
> [1] Stub resolvers that don't want their address info disclosed. Or those who may want to send that info (how??) but are talking to resolving servers who don't. Or the resolving servers tamper with that data whenever they query the authoritative server(s). Or choose to mangle whatever is returned as the optimised response.

If the resolver doesn't support it, a) Who cares?  b)  Just run your own recursive resolver.

If you don't trust the resolver, thinking it may tamper with things, why are you using it at all?  Seriously, if the recursive resolver is in your threat model, bypass it and generate your own recursive requests: its not necessary for correct operation of DNS.

> [2] Authoritative servers who can't/won't speak this EDNS0 option. The draft does not specify how they should behave.

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.


> Another Bad Idea in this draft is the concept of not using these extended queries to root and TLD servers. [Ironically, this is one place where "optimised" addresses in responses could be useful by directing resolvers to the nearest server for a referral.] It's not a good idea IMO to constrain a particular protocol query format to certain parts of the name space or an arbitrary number of labels in the QNAME.

Except that provides the privacy protections that you and S Bortzmeyer want: limiting disclosure, when possible, to the authority of the site the user will be contacting.  If you ONLY include such queries in the queries to the final authority, the information leakage really IS trivial, its so that a host in that particular subnet can contact the authority's associated site!

And for your suggested usage, this isn't necessary, as you refer the RESOLVER's IP to the most appropriate one, not the client's IP, because it is the resolver that needs to contact the domain's authority.