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

[Alex Bligh <[e-mail]>]

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.

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?

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

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

> 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
b) run one on your own subnet; or
c) accept that if you use someone else's local resolver you will
   suffer

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.

-- 
Alex Bligh