Local copies of the DNS root zone can spike resolver traffic, researchers find

A research project discussed in the APNIC PING podcast on 3 September 2026 has found that locally serving the DNS root zone can, in some configurations, generate more network traffic than the ordinary queries it is meant to reduce. The work was carried out by Ilyas Rahimi, who recently completed a Master's in Security and Network Engineering at the University of Amsterdam (UvA), and Willem Toorop from NLnet Labs. Ilyas completed the OS3 Master's program at UvA, which takes its name from its focus on Open Standards, Open Software, and Open Security. NLnet Labs is based on the UvA campus, and Willem has worked closely with the program for many years, supervising student research into DNS and DNSSEC during the Master's thesis component. As part of the program, students undertake two month-long original research projects, with the second forming the basis of their Master's thesis.

The DNS root zone sits at the apex of the DNS hierarchy. In everyday terms, the DNS, or Domain Name System, is the internet's address book that turns human-friendly domain names into machine-readable addresses. The root zone is the top-level list of all domain name endings, such as .com, .org, and country code endings. A DNS resolver is the server or program that performs these lookups on behalf of your devices. Normally, a resolver queries the root servers for information about which top-level domain to ask next. Locally served root is a resolver model that pre-fetches and stores a copy of this root zone. Having a local copy allows resolvers to quickly terminate queries for non-existent top-level domains and can provide some privacy benefits by reducing the need to query the root servers for resolvable names. There is a current proposal in the IETF, the Internet Engineering Task Force, to make this a Best Current Practice, meaning a recommended way to do something on the internet.

Ilyas examined three public resolver codebases, BIND, Unbound, and Knot Resolver, across four different configurations. His research explored both in-band retrieval of the root zone, meaning the resolver fetches the zone through its own DNS mechanism, and fetching it over HTTPS, the encrypted version of the web protocol. These are the two main methods a resolver can use to obtain a copy of the root zone. The choice of resolver software and retrieval method matters because each implementation handles the zone differently, and those differences show up in real network traffic.

The measurements produced two notable findings. First, Ilyas identified a bug in Unbound that accounted for a spike in traffic. Unbound is a widely used open source DNS resolver, so a bug that causes extra traffic can affect many networks. Second, he found that the root zone update cycle can generate a surprisingly large amount of network traffic when fetching the zone. In some cases, this exceeded the traffic associated with the far more frequent, but much smaller, queries sent to root servers for uncached data. In other words, the periodic download of a complete root zone copy can outweigh the savings from no longer sending many small lookups. The trade-off depends on how often the resolver refreshes the zone and how it retrieves it.

There is still more work to be done in this area. With the OS3 Master's thesis component now allocated more time within the degree program, Willem hopes to continue collaborating with UvA students and extend the measurement work. He has also been exploring how the system behaves when using incremental zone updates, known as IXFR, rather than fetching the entire root zone each time. IXFR transfers only the changed parts of a DNS zone, which could reduce the amount of data transferred during each update. The source also points to further reading: Ilyas Rahimi's Master's thesis titled Local root serving by default: Quantifying the traffic trade-off, a presentation Ilyas made on his thesis at NLnet Labs, an IETF draft BCP proposal by Warren Kumari called Populating resolvers with the root zone, an example of incrementally signed root states in a git repository by Willem Toorop at codeberg, and the RSSAC 02 document Measurements of the Root Server System from ICANN.

For everyday internet users and businesses choosing a DNS resolver, this research shows that resolver behaviour is not neutral. Something that sounds efficient, like keeping a local copy of the root zone, can have unexpected traffic costs depending on how it is implemented and updated. It is a reminder that the software behind your DNS lookups should be kept up to date, because bugs can cause extra load even when the idea is sound. For readers who want a resolver that is private and secure by design, a privacy-first encrypted DNS service such as AEU DNS offers DNS over HTTPS, TLS and QUIC with a no-logs policy, so your queries stay confidential while the operator manages root zone updates behind the scenes. That gives you the benefit of a carefully operated resolver without having to tune zone update intervals or debug resolver software yourself.