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

[Colm MacCárthaigh <[e-mail]>]

On Wed, Jan 27, 2010 at 11:56 PM, Wilmer van der Gaast
<[e-mail]> wrote:
> I spoke to Olafur about this idea in Hiroshima last year. I'm afraid
> the deadline for Anaheim already passed, but we hope we can discuss it
> on-line in the meantime and decide if it should become a WG item in
> Maastricht later this year.

+1 - As someone with an interest in writing an implementation, it
would be great to know at what stage an EDNS option code may be
assigned, if appropriate.

> Comments are more than welcome.

Section 1; Instead of "most nameservers" maybe "most such nameservers" ?
                "at best sub-optimal" -> "sub-optimal" but it's just a nit.

Section 2; The term "VLSM" (variable lengh subnet mask) may be more
technically correct than the use of the term "CIDR" - though I don't
think it matters much, the meaning is clear.

Section 4.1; The question naturally arises as to what happens when
there is a mismatch between the address-family used for the DNS query,
and the eventual address family of the client request. However as
these addresses may be considered to be located in similar topologies,
I don't think this is a hindrance and endorse the simplicty chosen in
the I-D.

On the subject of security;

"   A Recursive Resolver set up to serve clients in private address space
  (as defined in [RFC1918] and [RFC4193]) MUST NOT add edns-client-ip
  options containing a non-public address to its queries.  An edns-
  client-ip option MUST never contain a non-public address."

I think more general advice may be useful, rather than wording it as
"non-public" maybe come at it the other way and say;

 "A Recursive Resolver SHOULD add edns-client-ip options corresponding to
  publically routeable IP addresses only".

additionally, for better caching efficiency, it may be worth adding
text along the lines of;

 "Where the operators of a recursive resolver are aware of a client's
network routing policy, adopters are encouraged to ensure that a
NETMASK value corresponding to the largest network subject to a common
internet routing policy
should be used".

In other words, if it's a large ISP, and they know that an entire /20
is routed identically, then advertising the /20 makes the most sense
and results in more cache hits. This would pressure auth servers to
correctly aggregate their datasets, rather than the back-and-forth
negotiation of NETMASK which the I-D permits, but I think this might
be a positive thing :)

Sections 4.1/4.2:

 I think more detail is needed on how the system works when the
netmask returned is higher.  For example;

   client 192.0.2.53 makes query
   resolver sets option as 192.0.0.0/16
   auth server responds with 192.0.0.0/24

what should the resolver do in this case? 192.0.0.0/24 doesn't
correspond to a network 192.0.2.53 is in, but should it use the answer
anyway? What goes in the cache? The I-D says;

" A Recursive Resolver MUST return this entry from cache only to
queries that do not allow a higher NETMASK to be forwarded."

but does that mean this response should be cached for 192.0.2.53 too,
if it doesn't allow a higher netmask to be forwarded.

Section 8;

I would be more stern about one thing;

   "Authoritative nameservers MUST NOT use the contents of the
edns-clientip option as a means of access-control."

experience from HTTP and X-Forwarded-For has shown that people will do this :)

>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>       Title           : Client IP information in DNS requests
>>       Author(s)       : C. Contavalli, W. van der Gaast, S. Leach, D. Rodden
>>       Filename        : draft-vandergaast-edns-client-ip-00.txt
>>       Pages           : 20
>>       Date            : 2010-1-26
>>
>>    This draft defines an EDNS0 extension to allow Authoritative
>>    Nameservers to return varying replies based upon the network address
>>    of the client that initiated the query rather than of the client's
>>    Recursive Resolver.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-vandergaast-edns-client-ip-00.txt
>
>

--
Colm