Adding root servers as local secondary zone to local caching server

[Chriztoffer Hansen]

On Thu, 2 Sept 2021 at 13:23, Joe Abley wrote:
> Both of these aspects are known to suffer from operational problems from time to time.
>
> Filesystems can fill up, permissions can be changed accidentally, and other things can cause files not to be able to written to disk in a way that is not always obvious to notice, since DNS resolver software is often capable of running just fine without write access to filesystems.

Agreed. Monitoring is always essential.

> The ability to perform a zone transfer from a particular destination can also fail in ways that will not be obvious for long periods of time. There are no sources of the root zone by AXFR that are specified by the IETF and those that are available are often attached to anycast addresses that are not the best architectural choice for stateful transactions. The use of other protocols to transfer the root zone is also somewhat operationally novel.

The availability is there, and never likely to get included in a BCP /
RFC document. (Maybe into a draft, thou not likely a draft adopted by
a WG?)

> Note that in many cases this is an insignificant optimisation. The round-trip penalty to obtain a referral to the NL servers (your example) is often amortised over many billions of subsequent queries and quickly trends towards zero. The ability to avoid looking up names which result in NXDOMAIN responses from the root zone can be optimised using aggressive NSEC caching in a way that avoids the operational risks alluded to above.
>
> To me, even though the risks of failure through caching a local copy of the root zone are low, the benefits are lower, and it is not something I would choose to do. This risk assessment belongs in the hands of the operator, though, and it's certainly legitimate for other people to find a different balance.

It the operators choice, indeed.

If ones resolver is recently well connected to well-connected
upstreams/transit/ixp's. The benefits are indeed very very low. And
the benefits are negligible down to non-existent.

If one is hanging on a single upstream which is not well connected or
ones upstreams are of varying consistency/quality resulting in poor
user experience due to "significant" load time consumed by DNS
lookups. "Some" improvement could be gained by caching zone
information locally.
Thou, likely a DNS resolver which does speculative lookups on the most
popular DNS names ahead of the resolvers internal cache entry expering
might be a better choice. [0]

[0]: https://knot-resolver.readthedocs.io/en/stable/modules-predict.html