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

[Mukund Sivaraman <[e-mail]>]

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.

A 128.0.0.0/4/0 query will only have the first 4 ADDRESS bits set.  So
if we consider that a SCOPE > SOURCE answer is an answer to the question
at all, the answer is only valid for those first 4 ADDRESS bits, i.e.,
SOURCE PREFIX-LENGTH bits. There are no more defined bits in
ADDRESS. The answer's ADDRESS field has to equal the query's ADDRESS
field.

It seems the scheme you are describing to save the SOURCE PREFIX-LENGTH
is used in distinguishing between /SOURCE/SOURCE and /SOURCE/(>SOURCE)
answers. It was in reply to this comment:

> The draft doesn't state that the answer is for the SOURCE
> PREFIX-LENGTH when SCOPE > SOURCE. At all other times, the answer is
> meant to be cached at the SCOPE PREFIX-LENGTH.

You are describing what you're doing in implementation. I hope you
understand my concern that none of the above is specified.

		Mukund