At Mon, 23 Feb 2015 15:23:23 -0500,
Warren Kumari <war...@kumari.net> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
