Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00

[Wilmer van der Gaast <[e-mail]>]

Hello Jaidev,

2011/8/31 Jaidev Sridhar <[e-mail]>:
>
> Reading through the draft, I have a question about the NAT section which
> says:
> [..]

I just realised, after looking through our revision history, that we
haven't made any changes to the NAT section since edns-client-ip-00
(i.e. January 2010). Since then we have made some changes to
transitive behaviour so there are definitely some contradictions to be
found here.

The original purpose of the section was to sum up some things that may
seem clever but should not be done.

> I understand why one wouldn't want NAT devices to change a client subnet
> address (testing, anonymizer, etc.) but why does the draft say a NAT
> device _MUST_ not add a client subnet option?
>
I think the original idea here was "the recursive resolver will, if it
wants, add an edns-client-subnet option using the source IP it sees"
-=> there should be no need for a NAT device to do it, and generally I
do still think a NAT device shouldn't try to be smarter than
necessary.

>   Note that Authoritative Nameservers or Recursive Resolvers can still
>   provide an optimized reply by looking at the source IP of the query.
>
> When the recursive resolver is behind NAT, the authoritative nameserver
> will only know the address of the NAT device, which will not be useful
> for geo-location at all with big-bad-NATs.
>
> Any reason for NAT being excluded this way?
>
See the explanation above. Thank you for your reminder here, not
updating the NAt section at all was definitely an oversight, we'll
rewrite it for edns-client-subnet-01.

The big-bad-NAT use case is also not a scenario we thought of so far.
It's also a pretty hard one to support without putting a lot of
additional intelligence into resolvers (i.e. a mapping of internal IP
addresses to their external equivalents). I'd like to know if any
implementor is actually willing to implement that.


Cheers,

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