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

[Alex Bligh <[e-mail]>]

I have read the draft.

Re Paul's comment:

--On 28 January 2010 17:18:07 +0000 Paul Vixie <[e-mail]> wrote:

> (also, many client-ip addresses will be nat'd, and in that sense, ip is no
> longer end to end, and so including a client-ip in the query is a layering
> violation beyond just its fealty to dns incoherency.)

I had thought your "also" would be the main justification. With carrier
grade NAT and so forth appearing as v4 address exhaust, it's going to
become less and less reliable to map IP address to a specific geography,
and more and more likely a client IP address is "192.168.0.2"
(where both recursive resolver and client are behind the same NAT,
e.g. office LAN with NAT), in which case per the draft you get
nothing (as opposed to a GPS coordinate).

I'm nervous about overloading transport identifiers as a source of
geographic information in the first place, particularly it's yet
another thing middleboxes will decide, rightly or wrongly, they
need to fiddle with. Not allowing something which is a better indicator
of geography (e.g. GPS coordinate) seems to compound the problem.


More generally:

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

* I am concerned that even if you put in (e.g.) GPS, that gives
  you geographic proximity data, which may not correlate well
  to best match in terms of network topology.

* I am concerned the privacy provision is neither sufficient
  nor harmless. It may be insufficient as even at a /24 level
  it is possible to identify a large organisations outbound
  NAPT external IP range. It may not be harmless as two /25s
  may be in different geographies. Given people make DNS
  queries in general so they can communicate with the (e.g.)
  A record given, and the (e.g.) http server on that IP address
  can log connections, what privacy is lost by transmitting
  the address given in full? Wouldn't it be simpler to say
  that the querying client MAY (if it wishes) include a net mask
  showing which bits are accurate, and bits outside that
  mask are to be ignored and are undefined? That way, if a
  client wants to give incomplete information, it may. You
  leave this choice to the recursive resolver, I think, not
  the client, and require that at least some bits are cleared.

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

I have to wonder whether the simpler solution to fix this is
not just to deploy more resolvers closer to the edge.


-- 
Alex Bligh