Re: [DNSOP] Cache utilization review and suggestion for EDNS client-subnet

[Yuri Schaeffer <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a hard time understanding your need for DIRECTION and DEPTH,
and would argue you'd have enough information as is.

> 
> IPv4 root [A2(/0)**] /  \ 0b0.. /    \ 0b1.. /      \ A2(/1)    X /
> \ /   \ 0b10.. /     \  0b11.. /       \ A2(/2)      X / \ /   \ 
> 0b110..   /     \ 0b111.. /       \ A2(/3)    A1(/3)
> 
> 
> ** This is the global answer, but the auth server shouldn't send
> it.
> 
> (...)
> 
> I add that there is still confusion on what happens with the scheme
> in the current draft, if the resolver queries with 
> client-subnet=128.0.0.0/1. The authoritative server has two answers
> in this network. Does it send A1 or A2? If it sends A2, with scope 
> prefix-length=1, that'll be used from cache for future resolver
> queries where client-subnet=223.0.0.0/3.

That would be used yes. Therefore as a caching resolver I would not
expect the authority to reply with SCOPE=1. I would expect in this
case either
	(A2) 128.0.0.0/1/2  ("give me a bit more and I have it more specific")
or
	(A2) 128.0.0.0/1/3 ("Give me et least 3 bits and I'll have THE answer."
)

In any case it would answer with A2 because given the information
provided this is the most specific answer (it gets it from the root of
the tree).

Now as a caching resolver the next time I do a cache lookup for say
client 128.1.2.3 I would find the cache entry "128.0.0.0/1/3" thus
giving me two choices:

A) I'm willing to share more bits. So I query the authority with
SOURCE 3. (Or maybe lower if my policy says so)

B) My policy mandates SOURCE cannot exceed 1 and I'll use the cache
entry. The authority wants more but is not getting it from me.


> A1 may not be correct as the client behind the resolver (that is
> hidden by policy) may be in 224.0.0.0/3. The draft says:
> 
>> If an Intermediate Nameserver receives a response which has a
>> longer SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it
>> provided in its query, it SHOULD still provide the result as the
>> answer to the triggering client request even if the client is in
>> a different address range.
> 
> Operators who use this feature ought to be careful in designing
> their network. For example, there is a possibility that an address
> record may be sent to a client which has no route to it if the
> address is local to some other network.

You seem to imply that a SCOPE > SOURCE means an answer from further
down the tree. But I think it doesn't, or at least it shouldn't. The
SCOPE is not tied to an answer but rather used as an indicator how
many bits the authority needs/wants for the most/more specific answer.

//Yuri

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlazLTMACgkQI3PTR4mhavhk9QCfdYhtOiIkgzuPhRllFw2v1thu
kH4AoMC4XHOipkQxcP8A1I+wxzp1dPhT
=pb1/
-----END PGP SIGNATURE-----