329 queries to resolve one name: what a cold resolver cache actually costs
Published August 3, 2026 · DNS Benchmark Pro Editorial · Reading time: 3 minutes
In short — At IETF 126 in Vienna, ISC's Ondřej Surý showed a BIND resolver taking 329 queries to resolve a single IPv6 reverse-DNS name from a cold cache. The number is a useful reminder that DNS is fast because of caching, not because resolution is cheap — and that the shape of your zone matters as much as the resolver you pick.
The 126th IETF meeting was held in Vienna at the end of July 2026. Among the DNS sessions, the one with the most quotable number came from the IEPG session, where the Internet Systems Consortium's Ondřej Surý examined what a recursive resolver actually does when it starts with an empty cache and is handed a name.
His worked example was an IPv6 reverse name — a PTR lookup. Resolving it took BIND 329 queries.
Why one name costs so many queries
The textbook answer for www.example.com is four queries: prime the root, ask a root server for .com, ask a .com server for example.com, ask for the terminal name. Four delegation points, four trust decisions.
That answer is wrong in an interesting way. There are thirteen named root servers and you cannot know in advance which will be used, so you are trusting all thirteen. Same for the thirteen .com nameservers. And the root zone's nameservers live in .net, so you are trusting that set too. Surý's term for this is transitive trust, and Verisign Labs publishes a checker that draws the full picture for any name you give it.
Then it gets worse, for three ordinary reasons.
Glue records. If a resolver does not yet know the addresses for the .net nameservers, who does it ask to resolve a.gtld-servers.net? The circular dependency is broken by glue — addresses shipped in the additional section of the referral. Historically resolvers used glue as a shortcut everywhere, which is how cache poisoning got its foothold; today resolvers enforce a strict in-bailiwick rule before trusting it.
Out-of-bailiwick nameservers. microsoft.com delegates to ns1-39.azure-dns.com, ns2-39.azure-dns.net, ns3-39.azure-dns.org and ns4-39.azure-dns.info. Four nameservers across four different TLDs, none of them in-domain. Every one of those names is its own resolution problem.
CNAME chains. Resolving teams.microsoft.com walks five CNAMEs — through teams.office.com, tmc-g2.tm-4.office.com, and into s-0005.dual-s-msedge.net — before it lands on an A record. Each hop is effectively a fresh resolution in a new zone.
The resolver's choice, and yours
Resolver authors get two bad options. Resolve everything — chase every out-of-bailiwick nameserver name at every level — is thorough and exposes the resolver to enormous query loads that a hostile zone can deliberately manufacture. Selective resolution — pick one nameserver per level and go — is fast until the chosen server stops answering, at which point the fallback can force the whole walk again.
The honest framing is that this is a contrived scenario. A cold cache is not the normal state of a busy public resolver; a large anycast resolver serving millions of clients has .com, the root, and every popular CDN chain warm essentially all the time. That is the entire reason DNS feels instant. It is not that resolution is cheap. It is that you almost never pay for it.
Which is also why the number matters when you are choosing a resolver. What you are buying from a public resolver is largely somebody else's cache and somebody else's anycast footprint — the probability that your query is answered from memory in one round trip rather than triggering a walk. Our benchmark measures that end result over real DoH queries from where you sit, which is the only number that reflects both the cache hit rate and the network distance at the same time.
If you run zones rather than just query them, Surý's advice is dull and worth following: prefer in-domain nameservers for delegations; if you use managed DNS providers, use at most two, because more adds cost and no meaningful resilience; avoid long CNAME chains, since each one is a new resolution; enable aggressive NSEC caching on your resolvers; and stop setting short TTLs when you have no reason to. Short TTLs are a tax you levy on everyone resolving your name, collected in round trips.
Sources: Geoff Huston, "DNS topics at IETF 126", APNIC Blog (29 July 2026); Ondřej Surý, "DNS, Transitive Trust and How Many is Too Many", IEPG session at IETF 126; Verisign Labs Transitive Trust Checker.
Published by Genext Information Systems · August 3, 2026. DNS Benchmark Pro is an independent tool and is not affiliated with any vendor or organisation named in this article. This report summarises publicly available disclosures and is provided for informational purposes.