On Thu, Feb 04, 2016 at 08:13:39PM +0530, Mukund Sivaraman wrote: > Hi Yuri > > On Thu, Feb 04, 2016 at 02:50:48PM +0100, Yuri Schaeffer wrote: > > > I don't follow. Are you saying you are saving the SOURCE > > > PREFIX-LENGTH from the original query (responsible for the cache > > > entry) alongside the cache entry? > > > > Yes. > > > > > If so, I don't follow why this is required. Can you explain? > > > > Certainly! > > > > Suppose I query for 128.0.0.0/4 and get the response is 128.0.0.0/4/8. > > And suppose I would cache it like: > > > > A) 128.0.0.0/?/8 > > > > That is, discard the SOURCE PREFIX-LENGTH. > > > > Maybe I also ask for 129.0.0.0/8 for which the authority replies with > > the same SCOPE. My cache now contains: > > > > A) 128.0.0.0/?/8 > > B) 129.0.0.0/?/8 > > > > Suppose again I want to have an answer for 128.0.0.0/4. Which cache > > entry would be correct - if any? Do I need to requery the authority? > > Do I need to consider the bits from the client address that where > > masked? Or would I pretend the mask bits are 0? I can't decide, but I > > sure like to use my cache rather than asking the authority! > > > > If I had saved this in my cache: > > > > A) 128.0.0.0/4/8 > > B) 129.0.0.0/8/8 > > > > The answer should be obvious: "A". The server wants to receive 8 bits > > information but this is the answer I would have got when I would > > provide just 4. > > Is this example for considering that a 128.0.0.0/4/8 answer is different > from a 128.0.0.0/4/4 answer when both are available answers to be > returned by an auth for a 128.0.0.0/4/0 query? Other than that, I don't > see what saving SOURCE PREFIX-LENGTH seperately alongside > <address,address-prefix-length> would provide. If both answers were > treated identically, it can be cached at 128.0.0.0/4. > > If any one of these two different answers is found in cache, from the > description above, you'd use it and not fetch from authority (where you > might get the other answer for a 128.0.0.0/4 query). I.e., this is no > different from caching at /SOURCE when SCOPE > SOURCE.
I thought of one case where saving a longer *SCOPE* separately apart
from the caching address prefix length can be useful. This is in case
the resolver is a ECS option forwarder (intermediate) and wants to
provide the same syntax response /SOURCE/(>SOURCE) in its reply message
to the downstream resolver.
In practice, a resolver implementation wouldn't use a longer prefix when
it has a shorter source prefix configured as policy. This is why there's
the question of why the spec even talks about sending SCOPE > SOURCE
assuming the answer section is for ADDRESS/SOURCE/SOURCE.
> It would seem that in proper ECS operation, SCOPE need never be
> greater than SOURCE. Why have this specified at all? The description
> in the draft is short.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
