APNIC on IETF 126 DNS Topics: Resolvers, Post-Quantum DNSSEC, Optimistic DNS

At IETF 126 in Vienna in late July 2026, DNS working groups covered a wide range of topics. APNIC chief scientist Geoff Huston summarized the most interesting directions: how recursive resolvers actually behave, practical post-quantum DNSSEC experiments, the Optimistic DNS debate, and local root deployment. For teams doing DNS, website, or network operations, these discussions directly shape architecture and configuration decisions.

How Many Queries Does One Resolution Really Need

ISC's Ondřej Surý demonstrated a cold-cache experiment: starting with an empty cache, BIND 2.18 needed a staggering 329 queries to resolve a single IPv6 reverse PTR record. Contributing factors include the number of delegation levels in a name, out-of-bailiwick nameserver names, CNAME chains, and the extra queries DNSSEC validation adds.

More fundamental is transitive trust: resolving www.example.com looks like four queries, but implicitly trusts all thirteen root nameservers, the thirteen .com nameservers, and even the .net zone where root nameservers live. Glue records were historically abused for DNS cache poisoning, which is why resolvers now enforce strict in-bailiwick validation.

Operational guidance is straightforward:

  • Prefer in-domain nameservers for delegations when possible.
  • Use at most two managed DNS providers; more adds cost without benefit.
  • Avoid long CNAME chains, as every CNAME is a new resolution operation.
  • Enable aggressive NSEC caching where available.
  • Use longer TTLs unless there is a real reason not to, maximizing local cache utility.

Translating 329 queries into experience makes it concrete: a cold-cache resolution can inflate from tens of milliseconds to a few hundred, and if it lands on a first-paint request path, it directly hurts LCP. That is why public resolvers such as Google Public DNS and Cloudflare 1.1.1.1 invest heavily in prefetching and cache warming — they solve the "slow first query" problem up front so most users only pay for a warm cache hit.

Post-Quantum DNSSEC: Three Pragmatic Experiments

Unlike transport encryption, DNS keys are basically useless once rolled over, so the real question is whether a key's lifetime falls inside the window of a quantum-capable computer. Johan Stenstam presented three PQ-DNSSEC experiments:

  1. High-frequency KSK rotation: use DSYNC to roll an ED25519 KSK every ten minutes for three months, publishing only the DS hash in advance. If breaking the key takes far longer than its lifetime, the attacker gains nothing from an old discarded key.
  2. Split KSK/ZSK algorithms: a "strong" post-quantum KSK protects the DNSKEY while a smaller-signature ZSK serves daily responses, keeping large payloads on the validation path only.
  3. Gargantuan CSK: a single 23,843-byte DNSKEY response still fits in a TCP response (< 64K), and works once DNS implementations are patched for large buffers.

Put side by side, the three experiments show different roll-out timelines:

Experiment Key rotation Signature mix Main cost Stage
High-frequency KSK Every 10 min via DSYNC ED25519 Publish DS hash only Technical validation
Split KSK/ZSK Regular Large post-quantum KSK + small-signature ZSK Larger validation responses Pilot
Gargantuan CSK Regular Single post-quantum algorithm 20KB+ responses, TCP and large buffers Long term

The takeaway: rather than cramming large data into UDP, resolvers that recognize large-signature algorithms can go straight to streaming transports such as DoT, DoQ, or DoH.

Optimistic DNS and Local Root

Optimistic DNS lets a resolver briefly serve an expired cached entry while refreshing it in the background. Supporters see lower latency; critics, including the author, argue it bypasses the TTL semantics set by domain owners and lacks a clear staleness threshold. On the root side, local root (RFC 7706/8806) loads a full copy of the root zone into the local resolver and is being proposed as the default behavior for the public Internet.

What It Means for Websites and Operations

DNS is the foundation of website reachability. Whether you run your own authoritative DNS or use a managed provider, adopt the delegation and TTL best practices above. To add integrity validation to your domains, see the DNSSEC setup guide; for troubleshooting, read DNS resolution troubleshooting. More networking and CDN content is in the CDN/Network category.

If you want to start today, work through this sequence: first consolidate delegation nameservers in your managed DNS panel to in-domain (or at most two providers), then enable DNSSEC (one click in most control panels), then raise the TTL of key records from 300 seconds to 86400 seconds — provided no migration is planned soon — and finally confirm whether your recursive resolver has aggressive NSEC caching enabled. Each step can be verified and rolled back independently; none of it requires waiting for a protocol standard or a specific vendor.

Reference: IETF 126 meeting agenda https://datatracker.ietf.org/meeting/126/proceedings/
Reference: RFC 8806 local root deployment https://www.rfc-editor.org/rfc/rfc8806

Source: https://blog.apnic.net/2026/07/29/dns-topics-at-ietf-126/