Subject: Re: [dnsext] clarifications needed on draft-vandergaast-edns-client-ip-01

From: Wilmer van der Gaast <[email-masked]>
Date: Tue, 1 Jun 2010 12:28:36 +0100

Hello Jim, everyone,

On 31 May 2010 11:59, Jim Reid <[email-masked]> wrote:
> The draft's definition of Intermediate Nameservers includes Recursive
> Resolvers.
> Section 4.1 says Intermediate Nameservers MUST pass through the
> edns-client-subnet option as-is. Yet it later says a Recursive Resolver MAY
> drop this option. How is this contradiction going to be fixed?
>
Well spotted. Yes, there is this contradiction and I found some more
while thinking over the whole thing again. That's why this document is
merely a draft. :-)

In very specific language, this is how we intend the option to be used:

* A recursive resolver (often an open resolver, or possibly a resolver
run by an ISP with more peering points than DNS resolver pools) adds
the option to requests. It *can* add it to all requests, but
preferably it keeps track of authorities that support the option and
send it only to them, to improve performance and slightly improve
privacy.
Another option is that the resolver admin keeps a list of
edns-client-subnet-enabled authorities by him/herself. Since the
option will only benefit a small number of large CDNs, this list is
not likely to grow a lot.

* Users who for one reason or the other don't want any of their
address information to be added to requests, and know that their
resolver supports edns-client-subnet, can add the option with a 0/0
address. A compliant edns-client-subnet resolver will respect this. A
resolver that doesn't support edns-client-subnet will just ignore it.
If a resolver somewhere in between is ignorant of the option, it gets
stripped. The edns-client-subnet-enabled resolver later on will add it
again - but not with the user's address, since that address is already
invisible.

* Not really one of the goals of the option, but: if the user knows
the subsequent connection to the address received from the DNS will
use a different route than the DNS request itself, the option allows
for possibly better results from the CDN.

* For anyone else, this option does not and will never exist.

Regards,

-- 
Wilmer van der Gaast, Traffic SRE/Google Public DNS team.
Google Ireland.

---

From: Martin Barry <[email-masked]>
Date: Tue, 1 Jun 2010 16:01:24 +0200

$quoted_author = "Wilmer van der Gaast" ;
> not likely to grow a lot.

Regardless that's not a very scalable way of handling things.

An in-band method of automatically determining that "list" would be better.

Perhaps send EDNS-client-ip at random intervals to authorative servers
being queried and keep track of which respond to it? 

cheers
Marty

---

From: Jim Reid <[email-masked]>
Date: Tue, 1 Jun 2010 15:17:39 +0100

> being queried and keep track of which respond to it?

That's not scalable either.

---

From: Wilmer van der Gaast <[email-masked]>
Date: Tue, 1 Jun 2010 17:18:05 +0100

> being queried and keep track of which respond to it?
Yes, that's what I meant with "keeps track of authorities that support
the option". The option could be included once a day, and if the
respone doesn't have one, remember for another day or so that it's not
supported.

IMHO this is up the implementor though, and should only be mentioned
in a recommendations section.

Regards,

---

From: Martin Barry <[email-masked]>
Date: Tue, 1 Jun 2010 21:43:50 +0200

$quoted_author = "Jim Reid" ;
> That's not scalable either.

Resolvers already keep state (e.g. RTT) about queried servers.

You could add a binary flag for "uses EDNS-client-ip".

That appears to be minimal overhead with linear scalability to me.

cheers
Marty