[dnsext] opt-in and draft-vandergaast-edns-client-ip-00.txt

[Jim Reid <[e-mail]>]

On 2 Feb 2010, at 11:55, Carlo Contavalli wrote:

> If you don't enable the option, you keep the SAME level of privacy as
> of today (eg, no client-ip information is forwarded to other name
> servers).

Define "you". You as a stub resolver may well decide not use the  
option. But you as their resolving server might do so without the  
knowledge or consent of your clients. [That's probably illegal in some  
countries.] Or you as the resolving server changes whatever address  
info your clients have chosen to disclose before firing their queries  
at the CDN's name servers.

The stub resolver and resolving server will in all likelihood be  
operated by discrete entities with different privacy expectations and  
requirements. The draft ignores that.

> If, as someone running a recursive resolver, you have a contract with
> your users that allows you to do so and decide the "reduced privacy"
> is worth the benefit for your users, you CAN enable the option if you
> WANT to.

This is far too vague. It's very unsatisfactory for a protocol  
specification. The current draft says nothing about a number of  
protocol/operational considerations for the three entities involved.

For instance, what should a resolving server do if it doesn't support  
this EDNS option and gets such a query from a stub resolver? What does  
it do if the resolver server does support the option but the client- 
provided data is syntactically incorrect or semantically incorrect?  
What does a resolving server do when it does support the option but  
has disabled it for local policy reasons? How will these conditions be  
signalled to the stub resolver? When the resolving server does support  
this option, is it permitted (or not) to modify the data before  
sending a query to an authoritative server? If it does mangle that  
outbound query, how will the stub resolver know that? Or should it?  
Likewise, what does an authoritative server do if (a) it doesn't  
support this EDNS0 option (FORMERR? NOTIMP? REFUSED? or just ignore  
it?); (b) chooses for some reason not to supply an "optimised"  
response. Can the resolving server mangle the optimised response from  
the authoritative server (say for local policy reasons) before giving  
a reply to the stub resolver?

> And again, this is more of a policy discussion.

Not necessarily. See above.