"Optimistic DNS is evil": IETF 126 reopens the fight over serving stale answers fast
Published July 31, 2026 · DNS Benchmark Pro Editorial · Reading time: 4 minutes
In short — At IETF 126 in Vienna, the DNSOP working group revisited Optimistic DNS — serving an expired cache entry immediately while refreshing it in the background. It is a real latency win and a real erosion of the TTL contract, and nobody has proposed a limit on how stale is too stale.
The 126th IETF meeting was held in Vienna at the end of July 2026. Among the DNS sessions, one old argument came back with its usual heat: whether a resolver should be allowed to hand you an answer it knows has expired.
Gautam Akiwate presented on Optimistic DNS to the DNSOP working group. Geoff Huston's write-up on the APNIC blog on 29 July ends with a sentence that is unusually blunt even by his standards: "Mine is that optimistic DNS is evil!"
The mechanism
Every DNS record carries a TTL. The contract is simple: a resolver may retain and reuse the record for that period, and should not use it thereafter. The TTL is the domain operator's only lever over how fast a change propagates.
Two techniques chip at that. Prefetch, long available in resolvers like BIND, re-queries a popular cached record shortly before it expires, in the background, so the cache is renewed without any client waiting. The cost is queries issued for records nobody asked for. Prefetch is uncontroversial because it never serves anything past its TTL.
Optimistic DNS, borrowed from multicast DNS, does the opposite. The resolver keeps the entry after expiry. When a query arrives it answers immediately from the stale copy and fires off a refresh in parallel. The client gets a cache-hit response time — sub-millisecond — instead of waiting out a full recursive resolution. The next query almost certainly gets fresh data.
Stated that way it sounds harmless. The expired copy is used once, the window is momentary, and the payoff is a visible cut in tail latency on exactly the queries that are slowest today.
The objection
The counterargument, as Huston frames it, is that the TTL was set by the domain operator. If they had been happy for their data to be cached longer, they would have set a longer TTL.
The sharper problem is that the proposal has no staleness threshold. There is no specified limit on how far past its TTL an entry may be before optimistic reuse becomes unacceptable. An answer served this way may be hours old. It may be days old. Control over freshness has moved from the authoritative source to whichever resolver happens to be in front of the user, and the user cannot tell the difference — a stale answer and a fresh one are byte-identical.
There have been conversations about adding a second timer to bound the staleness window. The rebuttal from the other side is circular but not wrong: if you want the resolver to cache longer, use a longer TTL.
Why this matters for anyone measuring resolvers
Here is the trade-off stated plainly, because it rarely is. A resolver that serves stale answers benchmarks faster than one that does the work, and the difference does not show up in the timing. If two resolvers return the same record and one of them quietly skipped the recursion because it had an expired copy on hand, the faster number is not measuring a better network. It is measuring a different policy.
Who pays? Anyone who just changed a record and expected the short TTL they set to be honoured — which in practice means DNS-based failover, CDN steering, and incident response. Short TTLs exist precisely so that a change lands fast in an emergency. Optimistic DNS is a resolver deciding that its latency budget outranks your failover.
This is worth knowing when you read any resolver comparison, ours included. Our benchmark measures real DoH round-trip latency from your own browser, which is the number that determines how fast a page starts loading. It cannot tell you whether a given answer was fresh, and neither can anything else on the client side. Cache policy is a thing you have to read the operator's documentation for.
One more figure from the same week, from ISC's Ondřej Surý at the IEPG session, that puts the latency pressure in context: starting from a completely cold cache, BIND needed 329 queries to resolve a single IPv6 reverse PTR name. Out-of-bailiwick nameservers, long CNAME chains and DNSSEC chain-walking all compound. His practical advice for domain operators is worth repeating: prefer in-domain nameservers, use at most two managed DNS providers, avoid long CNAME chains, and stop setting short TTLs when you have no reason to. Caching is the only reason the DNS works at all — and it is a good deal less contentious than arguing about how to break it.
Sources: APNIC Blog, Geoff Huston, "DNS topics at IETF 126" (29 July 2026); Gautam Akiwate, "Optimistic DNS", DNSOP, IETF 126; Ondřej Surý, "DNS, Transitive Trust and How Many is Too Many", IEPG, IETF 126.
Published by Genext Information Systems · July 31, 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.