Re: [dnsext] Re: EDNS client IP should be opt-in (Was: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

[Nicholas Weaver <[e-mail]>]

On Feb 2, 2010, at 2:08 PM, Michael Graff wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2010-02-02 3:55 PM, Wilmer van der Gaast wrote:
>> Only clients of open resolvers and customers of ISPs with more peering
>> points than resolvers will benefit from this. Everybody else can
>> completely ignore this extension.
> 
> As a client that is likely true.  However, as the topic of this posting
> is opt-in, not default config, perhaps that's the important thing to
> discuss.
> 
> I see the huge benefit large hosting providers get from this extension.

> As a client, I'd benefit hugely from this perhaps, and my iPhone
> experience may be better than ever.

Actually, as a client, I hope you'd benefit relatively little if you are using your ISP's resolution infrastructure and the goal is to convey network location (rather than arbitrary location, which the resolver doesn't know anyway). 

The whole reason why all the CDN tricks work is the external IP where the DNS comes from tells the CDN what really counts: what network you are with, and what part of that network you are in, so the CDN-type transaction can know what set of machines are "best" to return to you (lowest latency, lowest cost, etc)...

And the ISP is best served by building a more distributed DNS architecture because that minimizes latency of lookups: having cached DNS go cross-country is a bad design.  Thus if, as a client, you'd benefit from this in your ISP's infrastructure, that implies your ISP's infrastructure is needlessly centralized and all your lookups are suffering higher latency.



Thus the client benefit is almost exclusively when you use third party resolution infrastructures, as the CDN-type operations can NOT identify your network provider and subpiece of that network provider when you use OpenDNS or Google Public DNS or Ultradns etc....

This is why I find client-opt-in a silly notion to insist on in the protocol:  The opt-in was made by using a third-party resolution infrastructure in the first place.  


This doesn't generally make sense for first-party infrastructure, yet putting opt-in into the protocol is a protocol killer: if we want to do changes to the stub resolver, I can think of a lot of better ones (like, say, bypassing the recursive resolver completely because its a lying SOB that may do such things as wildcard or even Man-in-the-Middle www.google.com, and instead generating direct requests.  And if I care about privacy, generate direct requests through multiple TOR paths)


> I also think this is more wide-spread than just the client side.  The
> servers will need to be modified to provide address information as well,
> and there is no way to do this in AXFR without special changes to group
> by address/netmask and add OPT records to AXFR.
> 
> I suspect this will affect interop, and no mention of how to tag this
> additional data, signal a slave can handle it, nor what happens when a
> slave does not handle it is mentioned in the draft.

Except that the authorities which would use this information have already solved this problem.  You don't see Akamai or Google fretting about master/slave coordination, interop, etc.  They just do it.  The code path-change on the CDN-using authority side is very small: where instead of using the resolver's IP in the lookup logic you use the EDNS0 client-ip value.