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

[Carlo Contavalli <[e-mail]>]

Ok, trying to respond to Olafur, and to many of the concerns that have
been raised on this thread.

On Thu, Jan 28, 2010 at 10:06 PM, Olafur Gudmundsson <[e-mail]> wrote:
> In the introduction the term "sub-optimal" is used with out defining
> for who and in what context, traffic delay or content.
The context is traffic delay, not content.

> Just because a
> computer happens to have an IP address that is registered to be in
> Austria does not mean that I'm interested in any Austrian content
> when I visit a news site like Reuters.com.
200% agreed.

> Some people made the not-always-correct assumption that addresses on
> DNS questions are an good/decent/reasonable indicator of location.
I don't disagree. However, it is more than just a few corporations
that are applying this misconception. Even sites like debian.org,
kernel.org or wikipedia are doing this today, and most major web sites
either rely on content providers or are doing similar tricks. Many DNS
softwares either support this directly or though external patches
(powerdns, even bind)..

We don't want to enter the debate of this being a good or bad idea.
People are doing it, regardless of what we think and what the DNS
protocol was meant for, or regardless of other alternatives being
available.

And as people are doing it, owner of recursive resolvers, CDNs, or
anyone who has to deal with a large user base need to take this into
account and work on the assumption that this is what the world looks
like now.

> The proposal in the draft moves almost all the cost of fixing the
> "problem" to the Recursive resolvers. Both by adding the option to the
> queries, and by the onerous requirement to fragment their internal cache
> based on source address of the stub-resolvers.
> This moves the cost of solving the "problem" from the CDN providers to the
> recursive resolvers operators, and I question if that is fair or justified.
So, if you're running a recursive resolver for a few networks that are
topologically close to each other, you probably don't care about this
draft, and will not enable edns-client-ip at all.

If you run an open resolvers, or run a resolver for several,
distributed, networks, chances are that you or your users are already
paying the cost of this.

Either by ignoring the problem and giving your users bad latency in
many cases, or by deploying multiple servers in many different
locations, each one duplicating some of the same entries in the
cache, or by using heuristics to determine what can globally be
cached and what cannot.

This draft, on one side asks recursive resolvers to forward more
information to the authoritative nameservers. But on the other side,
it allows to detect which servers are employing those techniques.
Eg, instead of having heuristics to determine what
can safely be shared in a distributed cache, you can simply look at
the edns-client-ip option. Instead of having to deploy multiple servers
sending queries from different IPs, you now have the choice of using
edns-client-ip to fetch result for different networks.

My point being: if you run a recursive resolver, and care about the
latency of your users, this draft might help you reduce costs and
build better infrastructures. If you run an authoritative name server
that returns different results based on the source ip, you now have
better input data (note: not the best, not exact every time, just
slightly better), can serve better result, and you have a mechanism
to say "yes! I'm pulling dns tricks, please be smart about caching
my data", rather than hope for not-written-anywhere "best practices".

This also helps debugging issues: rather than having to query from
different locations or check what's cached where to determine what's
going on, you can check with the option, or send different options and
verify what's going on directly.

> As Ed Lewis keeps saying "We need problem statements, before proposed
> solutions" and this draft fails to convince me there is a problem that
> is worth the working groups time or the mailing list bandwidth.
Agreed, the discussion would probably be much more focused if we had a
clear problem statement and some numbers to look at. We can't
promise anything at this time, but if we had a slot at the next IETF
meeting or at the following one, we could probably put together a
presentation with some concrete data to look at, and discuss this in
person, which would probably help a lot.

For what is worth, this is an important problem to solve for us, and
for most of the industries we talked to. We also know that in some
cases it's being solved with proprietary or non standard approaches.
We pretty much believe that many would benefit by publishing a
standardized way to handle those cases. (an experimental extension
is fine, or whichever form IETF deems more suitable)

In any case, we've seen lot of useful feedback in this thread, we hope
to upload a -01 version soon.

Carlo