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

[Alex Bligh <[e-mail]>]

--On 28 January 2010 12:16:57 -0800 Nicholas Weaver 
<[e-mail]> wrote:

> 3:  The third party resolver offers a significant value add, such as
> programmable blocking, automatic blocking of malicious sites, and far
> more agressive prefetching of common names and related information to
> speed up results.
>
> People are NOT using OpenDNS, UltraDNS, or Google's public DNS because
> their ISP's resolver is broken/evil, they are using it because they offer
> real perceived benefits.
>
> And this ISNT'T a behavioral change for every caching resolver.  One of
> the beauties of this scheme is ONLY the third-party resolvers and
> authorities which desire this behavior will need to implement this at
> all.  In fact, the Bind developers could say "No way in hell will WE
> implement this", but a few big recursive resolver providers and CDNs do,
> and it becomes a success and the problem is solved.

Hmmm... ok, part of my objection was to lines like (from 4.1)
 "In the reply, the server MUST include an edns-client-ip option."
On your reading, that MUST only means "where the incoming query
has the option set AND where the server is using the data in
some way". It doesn't, however, say that. I think it should be
clear that a server, whether or not it the software supports
the draft, and whether or not it is configured to return
answers with this option for some queries, is always free
to discard the edns client ip option (i.e. treat it as if
it isn't there). I don't see a particular problem with it using
the data silently then not returning a netmask. In which case
the MUST should simply read "MAY".

But if the idea of this is to institute a signaling mechanism between
caching resolvers that are non-local to their users (and you
say these are >= 97% third party resolvers) and certain authoritive
nameservers, why insist that the IP address passed is the IP
address of the client, which gets you into all these NAT problems.
Why not just allow the end user to specify an arbitrary IP address
which is the IP address he'd like authoritative nameserver to
treat as the source address for the query (possibly with a netmask
to indicate which bits are accurate), rather than saying he MUST
use the local IP address etc. etc.; so I could configure my
local (behind NAT) resolver with the external IP address.
And the privacy-paranoid could just pick any IP they know to
be in the same AS / network locality / whatever. Rather than
"client-ip-option" it is a sort of "source-hint-option".
This would also be useful in debugging problems to do with DNS
'cleverness' too (e.g. "dig +source-hint=x.x.x.x ....").

-- 
Alex Bligh