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

[Wilmer van der Gaast <[e-mail]>]

Let me clarify a few more things.

* Fallback mechanism:
Good idea. In fact I have noticed that not only cheap home routers can
choke on DNS packets with EDNS0 options, even Netscalers (with some
versions + configs at least) can intercept them and return a FORMERR
response.

This isn't so much a problem specific to edns-client-ip, but I agree
we should describe a fallback mechanism in this I-D (and for now in
every I-D describing an EDNS0 option, it seems. :-( )

* RFC1918 IP space, NAT, etc.
Nicholas Weaver's e-mail
<[e-mail]> /
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00105.html>
explains the behaviour we intended perfectly. We'll make sure to make
this behaviour much clearer in -01 since clearly it's currently
lacking.

* DNS/HTTP coming from different IP addresses:
I believe this is not so much related to our draft, or if anything,
our draft will make it possible to solve this problem by letting the
resolver include the external IP address from where HTTP traffic will
exit. If the resolver can't know this information (i.e. if it's not
predictable) then there isn't *any* way for CDNs to fix this problem;
even when using something like a 302 it's entirely possible that
another exit point will be used for the new connection.

* The requirement to include the option in responses only if the
request contained one.
Obviously our intent is to require edns-client-ip options only in
responses to queries that contained one. We'll clarify that in the
doc.

* Allowing to use the option without returning it in the response:
There's one problem with that. Without getting back the option a
caching resolver doesn't know how reusable the response is and will
assume it's suitable for everyone. Allowing that behaviour would allow
one to trick a resolver in Europe to cache the result of
www.example.com for Asia. Although this isn't cache poisoning in the
strictly malicious sense, it's definitely undesirable.

* Making larger netmasks (i.e. lowering the number) optional:
Although I'm not against making this a weak recommendation, doing this
affects not only the auth. resolver with generating more traffic, it
does also increase cache pressure on the resolver. Needs more
discussion.


Regards,

-- 
Wilmer van der Gaast, Dublin Traffic SRE.
Google Ireland.