Hundreds of Queries for One Domain: The Hidden Work Behind a Cold Start DNS Lookup

Every time you type a web address, a quiet behind‑the‑scenes process called DNS resolution translates that name into a machine‑readable IP address. Normally, much of that work is invisible because your local resolver keeps a temporary memory, a cache, of recent lookups. But what happens when that cache is empty? This so‑called cold start state forces the resolver to rediscover the entire chain of information from scratch, and as new research presented at the RIPE 92 meeting by Internet Systems Consortium’s Ondřej Surý shows, the cost can vary dramatically from just a few queries to several hundred.

To appreciate the scale, consider a simple example: the domain www.potaroo.net. Using a BIND recursive resolver version 9.20.23 with no cached data, resolution takes only four queries. The resolver begins by asking a root server (its addresses are pre‑configured) for the nameservers of the root zone, a refresh that also returns current IP addresses for those root servers. Next it queries one of those servers for the nameservers of the .net top‑level domain. A third query goes to a .net server to learn the nameservers of potaroo.net, and the final query requests the IP address of www.potaroo.net itself. Because every label in the name corresponds to a delegation point, a hand‑off from one zone to the next, four queries is the theoretical minimum. The resolver uses a technique called query name minimisation, which asks only for the next piece of information needed, but even a more direct approach would yield the same number of steps.

Move to a more complex name like teams.microsoft.com and the picture changes drastically. Surý’s tests found that a BIND 9.16 resolver needed 247 queries to perform the same cold‑start resolution. Version 9.20 cut that to 94 queries, and version 9.21 brought it down further to just 29. The root cause lies in a chain of four CNAME records, aliases that tell the resolver “this name points to another name, go look that up instead.” Each CNAME effectively restarts the resolution process, and because the targets span different top‑level domains (office.com, then a .net domain), the resolver must repeatedly re‑traverse the DNS tree from the root. Long CNAME chains, especially those that jump between unrelated zones, multiply the work.

Another factor is the handling of nameserver addresses. When a parent zone delegates a subdomain, it provides the names of the authoritative servers, but not directly their IP addresses. To avoid a chicken‑and‑egg problem, the parent often includes glue records: IP addresses supplied in the additional section of the response. Glue is mandatory when the nameserver name falls within the delegated zone (in‑baliwick), because without it resolution would deadlock. For nameservers that are siblings, sharing the same parent domain but outside the delegated zone, providing glue is optional. Historically, resolvers might trust this sibling glue, but a cache poisoning vulnerability discovered in BIND (CVE‑2025‑40778) led to changes from version 9.20.14 onward: sibling glue is now ignored, forcing the resolver to independently look up those IP addresses. This adds extra queries but closes a security gap.

Beyond glue, resolver designers face a strategic choice. One approach is to resolve every nameserver name completely, loading the cache with all IP addresses for both IPv4 and IPv6. This builds resilience, if one server fails, alternatives are instantly available. However, with lengthy CNAME chains and many out‑of‑baliwick nameservers, the query count explodes. The opposite approach resolves only one nameserver, or even one address family, and falls back only on failure. This speeds up cold‑start performance and reduces overall query load but risks timeouts if the chosen server is slow or unreachable.

A related decision is whether to trust the parent’s delegation data or to verify it by querying the child zone itself. BIND 9.21.20 switched to a parent‑centric model, relying on the parent’s list of nameservers without performing an extra query to the child. The reasoning is pragmatic: if the parent’s data has been tampered with, the resolver is already misdirected before any child query can help. For stronger assurance, DNSSEC, a system that cryptographically signs DNS records, offers a more robust defence, though it adds its own overhead. In the potaroo.net example, DNSSEC validation required two additional queries for DNSKEY records; with CNAME chains, the extra work scales with each alias’s label count.

What can zone operators do to lighten the load? Surý’s presentation offered clear guidance. Whenever possible, use nameserver names that sit inside the domain they serve (in‑baliwick), so glue records are guaranteed and resolution is efficient. Google.com is a textbook case: all its nameservers end in google.com. Avoid spreading nameserver names across many top‑level domains, a practice that forces resolvers to chase IP addresses through multiple zones. Keeping the DNS infrastructure simple not only aids performance but also removes unnecessary failure points.

For everyday users, the complexity of cold‑start resolution is largely invisible because caches hide it. Yet the design principles matter: a resolver that is too aggressive may waste resources, while one that cuts corners can leave you with slow or failed lookups. Using a DNS service that combines intelligent caching with strong security practices helps both speed and safety. A privacy‑focused encrypted DNS resolver like AEU DNS encrypts your queries end‑to‑end, preventing eavesdroppers from seeing which sites you visit, while its no‑log policy ensures that even the resolver operator does not record your activity. By choosing a resolver that upholds modern standards, query minimisation, careful glue handling, and DNSSEC validation, you gain protection without sacrificing performance.