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

[Nicholas Weaver <[e-mail]>]

On Feb 1, 2010, at 9:44 AM, Ted Hardie wrote:

> Howdy,
> 
> On Mon, Feb 1, 2010 at 8:39 AM, Nicholas Weaver
> <[e-mail]> wrote:
>> 
>> a)  Not everything is HTTP or HTTPS and supports such clean redirections.
>> 
> And this is one of the clearest point in this whole debate:  CDNs serve one
> sort of application, which has a host of other methods in play (redirects,
> content negotiation, an UPGRADE mechanism to change the security characteristics
> of the channel).   Many other applications do not have any of these or use
> fundamentally different approaches (store-and-forward protocols, for example,
> are pretty unlikely to use a redirect-style approach).

Here's a concrete example, lets take imap.google.com (latency matters for IMAP, bigtime...)

Do a query through a random open DNS proxy in Finland, you get:
;; ANSWER SECTION:
imap.gmail.com. 		A       74.125.43.109

Do it through a random open DNS proxy in australia you ge:
imap.gmail.com.			CNAME   gmail-imap.l.google.com.
gmail-imap.l.google.com. 	A       74.125.39.109

Do it through new zeland you get:
imap.gmail.com. 		CNAME   gmail-imap.l.google.com.
gmail-imap.l.google.com.	A       74.125.95.109


Do it through my local DNS settings you get:
imap.gmail.com.			CNAME   gmail-imap.l.google.com.
gmail-imap.l.google.com		A       72.14.221.111
gmail-imap.l.google.com		A       72.14.221.109

(Just from a couple of random DNS proxies)

So its clear that DNS-based network localization is being used for services beyond HTTP already.  Do we want such localizations to still work well when the user is using a 3rd party DNS resolver?

> Are we expecting the client's interaction with the DNS to be different on an
> application basis here?  Specifically, do we expect the DNS query to look
> different when the browser makes a request than when the mail stack does?
> How realistic is that, really, without the browser maintaining its own stack?
> Isn't it more likely that this will be turned on or off globally?  If
> it does vary, what
> does that mean for intermediate caching?  Does
> this create yet another pressure to reduce cache times?

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.

> On a slightly different point, I think Stephane's point on the prevalence of
> tunnels in Mobile IP situations is being lost here--we not only have the case
> of proxy/tunnels configured for specific applications, but the MIP tunnels which
> may be in play here--and that hits a lot of mobile clients that I fear are not
> captured in netalyzr data.

a:  We don't have web browsers in phones (no java support for iPhone, Blackberry etc), but we DO have plenty of data for web browsers on PCs through wide-area connections.

b:  The purpose is NETWORK identification, so "Customer is 'west coast verizon wireless' " is, in the end, what the authority is trying to infer.  The proxy is still going to be topologically close to the IP address in terms of network behavior and thats what you want.