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

[Mukund Sivaraman <[e-mail]>]

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