Subject: [dnsext] Comments on draft-vandergaast-edns-client-ip-00

From: John Kristoff <[email-masked]>
Date: Thu, 8 Apr 2010 12:16:52 -0500

First a bit of history...

In 2006 when draft-eastlake-dnsext-cookies-00.txt came out and while I
was at Neustar, I experimented with putting RRs in the additional
section of a query said as much on list.  What I didn't put on the
list, but did talk to at least a couple people at the time about (hi
Roy! :-) was to put the original querier address in there.  I think I
mentioned it to Paul or somebody at the Chicago dns-ops meeting and
that's when I realized I needed to learn more about EDNS0.

That idea was spawned even earlier while I was doing netops at
Northwestern.  We monitored queries at our resolvers and used that info
to help find problems with source hosts.  Often however, we got queries
from other recursive servers.  When those servers were passing on
something that was a problem, we really would have liked a DNS-based
information pathway to know the original querier.

The point is that there may be significant interest in this for
reasons other than synthesized answers.

Coincidentally, Roy then preceded to tell me about a traceroute idea he
had.  Roy, perhaps its time to dust that off?

A few comments about the draft now...

The draft allows for truncating the original querier address using an
"arbitrary" netmask, which might help alleviate some privacy concerns,
but the original querier has no control and likely no way to verify how
it is used to authoritative servers they do not control.  Not that it
matters, but the draft says the address SHOULD be truncated, but gives
no guidance on how to come up with a reasonable mask and I'm not sure
it even could.  The solution to end users in the 8.1 section is not
going to be sufficient either, since an implementation could completely
ignore it.  Maybe just make it optional and if its not used set the
mask to all zeros?  And I doubt the so

The draft calls itself "Client IP information", but only specifics
a source address and a netmask.  It could have specified additional
information that would have potentially provided additional insight
into the original querier, such as the id, source port or client-ip
path.  Maybe the undocumented implementations do?  What are the
drawbacks or advantages of other IP or IP protocol fields being
conveyed as well?

I have a sinking feeling there are new some attack vectors made
possible with this draft, and if I do a more rigorous analysis of the
draft and find any I'll be back.  One, which may be partially solved by
implementation is cache enumeration.  That is, knowing who is talking
to a cache and querying for what may be possible by forging client-ip
detail.

Regarding the privacy concerns, I think those are very legitimate
concerns and users should be at least aware that their DNS queries might
be seen by others than their recursive server operator.  However, from a
technical standpoint, I'm not sure this seem sufficient to prevent this
work from going forward.  It might warrant a "edns-client-ip is
harmful" response as Paul appears poised to do.  

John