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

[Nicholas Weaver <[e-mail]>]

On Feb 1, 2010, at 11:09 AM, Ted Hardie wrote:

> In-line below.
> 
> On Mon, Feb 1, 2010 at 10:45 AM, Nicholas Weaver
> <[e-mail]> wrote:
> 
>> Here's a concrete example, lets take imap.google.com (latency matters for IMAP, bigtime...)
>> 
> 
> IMAP is not one of the store-and-forward bits of the email architecture;
> SMTP would be.  But the core question comes back to:  how does the
> DNS stack know that this application is one for which localization will
> be desirable, given that this is a decision made by the authoritative
> server?  Do you expect this to be opted-into for every query, or only
> for some?

I would expect EVERY query from third party resolvers ONLY: network-provider and user-provided resolvers don't need this, they already export enough information for the authorities to decide based on resolver IP.


And thus the only systems which would need changing are third party resolvers and authorities which desire the ability to act on this information.  No other changes are needed.


ANd I chose IMAP rather than SMTP and IMAP is more important for this than SMTP for DNS games: its a user-interactive application (unlike SMTP which is bulk delivery so latency doesn't matter so much), thats not HTTP and does not support HTTP style redirects, showing how these DNS tricks are

a)  Used across more applications than just web traffic

b)  Used in ways where web-style redirects can't work

Thus the "do it in the app layer" crowd are, unfortunatly wrong, you can't do it in the app layer in important cases, even if you ARE willing to allow ugly URLs to escape into user-visibility for web traffic.


Oh, and you get this for SMTP too:
Me:
gmail-smtp-in.l.google.com. 	A       209.85.222.96

uk:
gmail-smtp-in.l.google.com. 	A       209.85.229.27

Australia:
gmail-smtp-in.l.google.com.	A       209.85.223.62

Singapore:
gmail-smtp-in.l.google.com. 	A       74.125.79.27


>> The net result would probably be the opposite:  If you know that an entry will only be cached for requests from a subrange, you can use a longer, rather than shorter TTL.
> 
> You don't actually know that--you're providing a response based on the subrange,
> but depending on the liveness of your load balancing and the caching
> implementation
> you could get a wide variety of results.  If I previously provided a
> single response
> based on the IP address of the querying server and now provide one based on
> the subrange being served, I might choose to lower the TTL to 0 in order to make
> sure that each subrange query is served "fresh", rather than from the cache.
> Otherwise, I have to trust that the cache is maintaining multiple entries on the
> subrange basis.  You want to set a bit for that too?

A cache which is requesting with this enabled has already said it caches per subrange, thats why the netmask is in there in both ways, it says from the resolver -> authority "The guy is somewhere in this part of the network", and authority -> resolver "you can cache it for this part of the network".  That the request was made at all states that the resolver understands not all cache entries are valid for all queriers.

> Coherence ain't just elegant, it's easier.  I recognize that there is value to
> the CDN approach, but the complications here (and the privacy implications)
> aren't trivial.  Doing this may be well past the 80/20 line for DNS-based
> localization.

Coherence is dead.  Opposing this draft won't bring it back.  The choices are either:

a)  Support incoherence for 3rd party resolvers in the protocol.

b)  Don't support incoherence for 3rd party resolvers and wonder why they continue to suck compared with first-party resolvers which will still have proper incoherence support.


Call me firmly in camp a:  I'm not a fan of OpenDNS or Google Public DNS, but for those who use it, I want the users to have the best user experience, and its clear that controlled incoherence in DNS has become a key part of "good user experience".


If you are in camp B, please explain why ensuring that OpenDNS, Google Public DNS, etc are at a significant disadvantage in terms of quality of results is a good thing, when there exists a proposed change which ONLY effects the third party resolvers and those authorities that want incoherent results.


And DNS privacy is a delusion:  DNS leaks so much information already in the current infrastructure that anyone who actually cares about DNS privacy has to take special measures: special measures which would not be affected by this proposal.  Special measures that, in particular, exclude the use of third party resolver services.