Adding root servers as local secondary zone to local caching server

[Joe Abley]

Hi Chriztoffer,

On Sep 2, 2021, at 04:32, Chriztoffer Hansen via Unbound-users <unbound-users at lists.nlnetlabs.nl> wrote:

> Zones fetched using AXFR is cached locally on disk by your resolver daemon.
> 
> Your local resolver daemon will regularly check in with the upstream
> server to monitor if the serial number has changed. If the upstream
> number is higher than the locally cached one. Request a new copy of
> the upstream zone file.

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.

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.

I am not trying to cast doubt on the ability to retrieve a root zone and use it in this way, but I think it's important to mention that a failure to transfer can sometimes be difficult to notice, and can have operational effects that are often delayed (e.g. an RRSIG expiring days after some package was updated or some firewall was modified; a delegation change that might reduce the effective breadth of the NS set for some top-level domain; a newly-delegated and hence lightly-used TLD that works elsewhere but not through your resolver, etc).

> If you want to run your local resolver without relying on upstream
> forwarders doing the lookups for you (think e.g. 1.1.1.1 (CloudFlare),
> 8.8.8.8 (Google), 9.9.9.9 (Quad9)) configuring your local resolver to
> use a cached root.hints file fetched using HTTP/HTTPS/AXFR is almost
> your only option.

Note that this is not what you are doing. The root hints allow a resolver to execute a priming query. This is something that every resolver needs to do, regardless of whether it is configured to serve a local copy of the root zone.

> Caching the root.hints file locally *saves* your local resolver from
> needing to first contact a root server for a lookup of which NS is
> responsible e.g. the .NL-zone.

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.


Joe