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

[Ted Hardie <[e-mail]>]

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?


>> 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.

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?

>
>> 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.
>

And those tend to be nomadic, rather than using Mobile IP to deal with
visited network issues.  Any phone afflicted by (er, using) IMS or the
"visitied network" approach will have two IPs--the one associated with
MIP tunnel
and a local IP in the actual serving network.  It's not uncommon to source
some or all DNS queries from the tunnel interface, because of the joys of
split DNS needed to reach home network resources.  This ID would prefer
them to come from the local IP address for this localization to work--but that
means somehow passing a lot of data to the client on which queries should
go where using what source.

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.

Regards,

Ted Hardie