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

[Nicholas Weaver <[e-mail]>]

On Jan 28, 2010, at 11:51 AM, Alex Bligh wrote:

> Nicholas,
> 
>>> * I am concerned that the IP included is the transport layer IP
>>> visible to the client/resolver. That might have little to do
>>> with the IP address from which a subsequent (e.g.) http connection
>>> appears to originate.
>> 
>> Only VERY rarely.  Very few users in our observations with Netalyzr are
>> behind manually or automatically configured proxies which route traffic
>> through a different address from the remainder of their network traffic
>> (<3%), with 1/4 of those having the proxy in the same /24 subnet.
> 
> I am surprised if that is the case and wonder whether you are reading
> my sentence in another way. So, e.g. take this set up
> 
>                                192.168.0.2
>           192.0.2.0/24       |------------ Resolver
> Internet <-----------[NAT]---|
>                              |------------ Client
>                                192.100.0.3
> 
> Now, the client IP address in the DNS query is going to 192.100.0.3.
> The resolver has no (reliable) way for finding out its external
> IP address. It may heuristically determine it is 192.0.2.1 (say)
> but that presumes that it doesn't have (e.g.) a forwarder configured.
> However, the current draft says it should use 192.168.0.2, but
> for the fact that is RFC1918 space, and it should thus discard
> it. Best case, the subsequent http connection (or whatever) appears
> to come from 192.0.2.0/24.

No, in that case, the resolver just reports NO IP address, and the internet relies on the external IP address being valid.  So there is no problem in that case.

> If you think my using NAT is cheating, then consider the example
> of (say) the university with no NAT, but a squid proxy. What's
> to say their internal resolvers are on the same /24 as the
> squid proxy?

They are, however, in the same closeness of network, so heck, the other side is quite happy.



I thought in particular you were referring to a case more like this

Client -> Non HTTP has an external IP of W.X.Y.Z
     \
      \-> HTTP proxy, HTTP traffic has an external IP at A.B.C.D

THIS is the case where the client's IP address, as externally viewed, differs for HTTP vs non-HTTP traffic.  That does occur, but its rare (~3% in measurements).  And when it does occur, the client could just as easily (and may very well already for the web browser) issue the DNS requests through the proxy as well.



> 
>>> * I am concerned about section 4.3 causing algorithmic
>>> complexity, and an explosion in cache size. If NETMASK
>>> is set small, you will get a ton of records for
>>> www.google.com cached. That's going to be unworkable,
>>> which will encourage large settings for NETMASK.
>> 
>> Memory is cheap.  Seriously, who should worry when any resolver big
>> enough to have this issue is going to be a cluster:  Lets say I have a
>> open recursive resolver for EVERYONE, and 1000 names uses this and are
>> queried by EVERYONE, and I have netmask set to /24.
>> 
>> The total caching space required is 16 Giga-entries.
> 
> Fair point re memory, but cache misses cost more than memory. They result
> in higher load upstream.

Thus what you want is the authority to be able to specify a broader netmask, if the upstream authority cares about load.  Do that, and the few upsteam authorities which would care about this could be able to prevent it.



> 
>>> I have to wonder whether the simpler solution to fix this is
>>> not just to deploy more resolvers closer to the edge.
>> 
>> Actually, that IS the fix:  Use the ISP's recursive resolver.
>> 
>> This is necessary if you want to use something OTHER than the ISP's
>> recursive resolver to work well on today's Internet.
> 
> I was presuming one problem is that the ISP's recursive resolver
> is not topologically close to the source, given the draft authors
> say:
> :    When the Recursive Resolver does not use an IP address that appears
> :    to be topologically close to the end user, the results returned by
> :    those Authoritative Nameservers will be at best sub-optimal.
> 
> but if the whole problem is people using a DNS provider other than
> the one they are "intended to" ...

It isn't as close as one would LIKE, eg, comcast's list:
http://dns.comcast.net/dns-ip-addresses2.php

But its 'good enuf for CDN work'.  Better would be better, but the ISP resolvers are already giving out ENOUGH information for the CDN-like tricks to largely work.

> 
>> Do you want third-party DNS providers to not suck for youtube, akamai,
>> Google, and a good fraction of the net people use every day?  If so, you
>> need this.
> 
> ... my answer would be "don't do that then". Either:
> a) run your own recursive resolver on your local box (which is easy
>  enough to do); or

5% of the rather tech savvy Netalyzr users.  And that probably counts a lot of businesses behind single IP NATs.

> b) run one on your own subnet; or
> c) accept that if you use someone else's local resolver you will
>  suffer

So your advice to my mom is "Tough", basically.  Using a good third-party resolver is a minor change, your recommendations are much harder to instruct my mom to do.

> I suspect the reasons for using third party DNS providers are:
> 
> 1. DHCP results in a dysfunctional resolver (e.g. the middlebox
>  broken resolver). See draft-bellis-dns-recursive-discovery for
>  a better way around that.
> 
> 2. Their ISP's nameserver is broken/evil. I'm happy to leave that
>  for the market to fix, rather than standardize a behavioural
>  change in every caching resolver.


3:  The third party resolver offers a significant value add, such as programmable blocking, automatic blocking of malicious sites, and far more agressive prefetching of common names and related information to speed up results.

People are NOT using OpenDNS, UltraDNS, or Google's public DNS because their ISP's resolver is broken/evil, they are using it because they offer real perceived benefits.

And this ISNT'T a behavioral change for every caching resolver.  One of the beauties of this scheme is ONLY the third-party resolvers and authorities which desire this behavior will need to implement this at all.  In fact, the Bind developers could say "No way in hell will WE implement this", but a few big recursive resolver providers and CDNs do, and it becomes a success and the problem is solved.