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

[Nicholas Weaver <[e-mail]>]

On Jan 28, 2010, at 12:49 PM, Alex Bligh wrote:

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

Agreed.  Perhaps the best way is something like the following rules:


The authority MUST NOT use an EDNS0 client-ip-option if the request did not include a client-ip-option [1]

The authority MAY specify a broader netmask in the returned value [2]


When the resolver's own address is a publically-routable address, it SHOULD use the request's source IP address as the basis for the client-ip-option value, if no client-ip-option value was specified in the request [3]

If the resolver's own address is a non-routable address, it MUST NOT generate a client-ip-option value, but may pass a client-ip-option value [3]

If the resolver receives a request with a client-ip-option value, it should either REMOVE this value or pass it unchanged, it must not modify this value [4]


The resolver which uses or creates client-ip-option values SHOULD keep track of any authority which ignores or responds with an error for a request containing a client-ip-option but responds properly for the same request without a client-ip-option.  After three such failures, the resolver should remove all client-ip-option values in communication with this authority [5]




[1] Ensures that authority changes will not affect non-compliant resolvers

[2] Ensures that the authority if it cares about load, can specify a broader netmask.

[3] Removes the need for client changes under most conditions.  Prevents the NAT from being an issue.

[4] ALLOWS clients to take advantage of this, but doesn't requires it.

[5] Ensures that resolver changes will not prevent names from resolving.


As a result, you get a system where:

a) Partial deployment works with just changes to the authorities and resolvers which care about this feature.

b) Authorities, resolvers, and clients which don't implement this feature won't see an effect.


As important, the number of servers which would need to implement this feature is low, but the number of USERS which would benefit is substantial.


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

Actually, the external address of the request is the right answer for all these NATs, so there is no problem.

> 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 ....").

Sounds good, and makes sense.  But in absence of a client-specified value, the default value should be derived from the request's SRC address.