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

[Paul Hoffman <[e-mail]>]

At 1:49 PM +1300 1/29/10, Joe Abley wrote:
>On 2010-01-28, at 12:56, Wilmer van der Gaast wrote:
>
>> To summarize the I-D: It specifies an EDNS0 option that carries IP
>> address information (by default only the first 24 bits to preserve
>> privacy) of the user that triggered a DNS resolution.
>
>My initial reading of the proposal suggests that the client that originates the DNS request is the one that MAY populate a client-address option, and that any other resolver or proxy in the chain between the client and a server (cache or authority) which supplies an answer MAY NOT change the client-address option data.
>
>Suppose most clients are numbered using RFC 1918 addresses behind a NAT, and have no trivial way of discovering a non-RFC1918 address that the world might see them as. In that case isn't the address information that ultimately arrives at cache or authority nameservers useless for any purpose other than identifying that RFC 1918 addresses are in use?

Section 4.1 says "An edns-client-ip option MUST never contain a non-public address." To me, that means two things:

- If I'm an end client and I know my address is non-public, I cannot include an edns-client-ip option in my request upstream.

- If I'm a recursive resolver and I get a query that erroneously includes an edns-client-ip option with a non-public address in it, I strip off that option before sending that request upstream.

If I have understood the draft correctly, then the concerns about private addresses their effects on authoritative resolvers are moot.

The biggest stumbling block here is the assumption that developers will know the correct list of non-public addresses. Given lots of deployed counter-examples, that seems like a bad assumption. Specific pointers to specific IANA registries are needed in this draft.

--Paul Hoffman, Director
--VPN Consortium