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

[Ted Hardie <[e-mail]>]

Howdy,

The draft currently says:

   Authoritative Nameservers of most major web sites today return
   different replies based on the perceived vicinity of the user to a
   particular location and knowledge of available resources.  This
   significantly reduces the overall latency of connections established
   by the end user and optimizes network resource usage.

   To find the best reply for a given query, most nameservers use the IP
   address of the incoming query to attempt to establish the location of
   the end user.

This seems to mix two different motivations, based on two different
ideas about locality.  In the first, you want to provide data from the HTTP
server to the end user along the path with the lowest possibly latency,
so you want to do some lookup of the relationship between the client's
network location and the list of available servers' locations before providing
the DNS response.  The first 24 bits of the client's IP address are used
to determine this network location.

The second motivation is to return different content based on geographic
location and the likely implications for default language, character sets, and
so on.  For that motivation, you want to associate the client with a server
having that data as quickly as possible--without, for example, doing a
3xx redirect after reading the client's language preferences in their first
request.

I would be personally surprised to find that the first 24 bits of an IP address
of the client are actually better at the association needed for your
first motivation
than the full IP address of the querying resolver, but I've been
surprised before.
Minimally, you'd seem to me to need to do something to figure out what
an "external" value of an IP address for that host was when the
resolver populated
that field for hosts behind NATs.  If the client did not have one (yet), a
heuristic population of the first 24 bits of the field seems possible
but mighty
unlikely to be terribly accurate (beyond the accuracy of the querying resolver's
IP anyway).  If you're going to simply population it with the first 24
bits of the
NATted address, this seems to be of pretty low utility.

The second motivation actually takes you straight into GEOPRIV territory, and
it's not clear to me at all how a client would opt-in to revealing geolocation
in some DNS queries and not all, given how applications typically interact
with DNS libraries.  There's some serious fun on the privacy legal fronts
in front of you there, should you decide to take up the idea of actually having
the geolocation directly disclosed, rather than inferred.  If you
leave it inferred,
you still seem to me to have the NAT problem to noted above.

Can you clarify which motivation is driving this draft?

regards,

Ted Hardie