Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

[神明達哉 <[e-mail]>]

At Mon, 23 Feb 2015 15:23:23 -0500,
Warren Kumari <[e-mail]> wrote:

> > - Section 6.1
> >
> >    A Stub Resolver MAY generate DNS queries with an edns-client-subnet
> >    option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that
> >
> >   I'd suggest: s/i.e./e.g./ since this may also be an IPv6 address (in
> >   which case FAMILY is set to 2)
>
> DONE.
> Good point, thank you.
>
> I updated this to be explicit ("(i.e. 0.0.0.0/0 for IPv4 or ::/0 for
> IPv6) "). This seemed cleaner than the example form.

I'm fine with this, but I remember we discussed whether hiding the
actual type (e.g. by always using an IPv6/IPv4 prefix) might be better
in terms of privacy.

> > - Section 6.3
> >
> >    fields, as detailed below.  Note that the additional and authority
> >    sections from a DNS response message are specifically excluded here.
> >    Any information cached from these sections MUST NOT be tied to a
> >    network.
> >
> >   What if the "optimized" reply is a negative one for some specific
> >   client addresses (while it's positive for some other addresses)?
[...]
> I think that we should just be excluding NXD - this fits in with my
> view of how ECS should work (and what NXD "means"). Noting that this
> explicitly.

I'm okay with this.

> > - Section 6.3
> >
> >    If the address of the client is within any of the networks in the
> >    cache, then the cached response MUST be returned as usual.  If the
> >    address of the client matches multiple networks in the cache, the
> >    entry with the longest SCOPE NETMASK value MUST be returned, as with
> >    most route-matching algorithms.
> >
> >   If I understand this (and Section 6.3 in general), the following
> >   "suboptimal" scenario could happen:
> >   - The Authoritative Server is configured with two prefixes for
> >     optimized responses: 2001:db8::/32 and 2001:db8:2::/48
> >   - The Recursive Server sends a query with SOURCE of 2001:db8:1::/48
> >   - The Authoritative Server finds the best matching prefix for the
> >     SOURCE is 2001:db8::/32 and returns a response corresponding to
> >     it, setting SCOPE NETMASK to 32
> >   - The Recursive Server receives the response and caches it
> >   - The Recursive Server receives a query from 2001:db8:2::1, and
> >     finds it has a matching cache (with prefix being 2001:db8::/32)
> >     and uses the cached response to answer the query, even if it could
> >     get the specifically optimized response for 2001:db8:2::/48 from
> >     the Authoritative Server.
> >
> >   Is my understanding correct?  If so, is this a problem to resolve or
> >   something we need to accept?
>
> Yup, very good point.
>
> A "good" implementation of the server could note that 2001:db8:2::/48
> is a subnet of 2001:db8::/32 and warn the user that the /32 may elide
> the /48. It could even break the /32 into shorter prexies (all with
> the same answer as the /32, apart from the more specific /48). I do
> not think that it is our place to specify which the implementation
> chooses, but I've noted that implementations MUST document what they
> do.

Hmm, according to the previous discussion in January, I was told that
it was my misunderstanding:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13095.html
and this is my response to that:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13099.html
http://www.ietf.org/mail-archive/web/dnsop/current/msg13101.html

In short, if the original intent was that explained in msg13095.html
I see it doesn't have the suboptimal case I described, but then I
believe the documentation should be much more clearer about the
intent.  I also had a concern about on complexity and cost.

--
JINMEI, Tatuya