-----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-----
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
