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

[Nicholas Weaver <[e-mail]>]

On Jan 28, 2010, at 8:13 AM, Paul Vixie wrote:
>> Rather than adding client identity, what we're trying to do is address
>> a concrete problem that affects CDNs, open resolvers, and many large
>> sites, that for whatever reason, use the source ip of the query to
>> determine which reply to return to the user.
> 
> i don't think that's a general enough solution to be worth standardizing.
> please investigate the larger context of client identity, beyond the needs
> of CDN's.

ANY system which desires that a request be routed to the "best" instance which is appropriate to handle the request, without the need to introduce divergent names (which impacts user experience), detailed protocol changes to HTTP and a host of other protocols, front-end redirection, or IP routing (multipathing), would greatly benefit from knowing the requesting client's IP address in the name lookup, and can ONLY route 

That may "only" be CDN, but CDN or CDN-like tricks are VERY important on the current Internet, and without the ability for CDN's to produce meaningful values, this limits the ability of third-party DNS resolver providers to do any good: one of the common complaints about OpenDNS is it "makes YouTube slow".




However, on this draft I'd recommend that resolvers implementing this should do a fallback model:


When initially querying any new authority, the resolver is advised that it should conduct both a query with this EDNS0 extension and, if no result is seen in a shortened timeout (1s) a second one without, using different transaction IDs and port numbers, and use a TRW-style count of success/failure to determine whether the authority accepts such records or not.  

If there are more than T such failures for an authority, it should be noted as not supporting this EDNS0 extension in a broken manner (causing failure), and this extension should not be used in subsequent communications with this authority.

Thus authorities which react badly to unknown EDNS0 extensions will still be reachable, and after only a few short timeouts, not experience any worse resolution latency.