[dns-operations] cache and subnet option

Kristopher Beevers kbeevers at ns1.com
Thu Apr 20 01:48:47 UTC 2017

I had this half typed when Mark responded so dropping it here anyway.

In message <m2shl36fq2.wl-randy at psg.com>, Randy Bush writes:
> > dear lazynet,
> >
> > caching resolver R serves clients on subnets S0 and S1.  a device on S0
> > queries for wanna.know.  R queries for the data using the subnet option.
> > a device on S1 then queries for wanna.know.  does R respond with the
> > cached data from the S0 query, or issue a new query with the S1 subnet
> > data?
> >
> > [ to my na=EFve eye, issuing a second query would seem to have, shall we
> >   say, interesting scaling properties ]
> >
> > randy
> It depends on the addresses and the answers.  Yes, ECS has scaling
> issues and it depends on the authoritative servers returning the
> shortest prefixes possible which in turn depends on ISPs using
> sensible addressing plans which keep topologically close clients
> under the same prefix.

Answer is as usual "it depends" -- but more or less, it's "the latter" --
it issues a new query with S1 as the subnet.  The most important caveats
are that it depends on the scope of the subnets and what R considers a
sufficiently specific but not too revealing scope -- usually in practice,
this is /24; and that it depends on the scope returned in the response from
the ECS-enabled authority.  For example if we receive a query scoped to but we know we will return the same response for all addresses
in, then we will respond with that scope in the hopes that the
resolver caches with that scope and is smart enough not to ask a different
question for

As Mark pointed out, there are indeed scaling challenges here -- especially
on the caching side.


Kristopher Beevers, CEO

kbeevers at ns1.com
mobile: +1-518-527-1109
desk: +1-855-438-6766 ext. 701
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170419/03989edc/attachment.html>

More information about the dns-operations mailing list