Post-quantum DNSSEC: a 23KB DNSKEY, a ten-minute key roll, and a good argument for doing nothing yet
Published August 3, 2026 · DNS Benchmark Pro Editorial · Reading time: 4 minutes
In short — A side meeting at IETF 126 produced three concrete post-quantum DNSSEC experiments, including a DNSKEY response of 23,843 bytes and a KSK rolled every ten minutes. The interesting conclusion is that DNS keys do not need post-quantum algorithms nearly as urgently as transport-layer encryption does — and that shorter key lifetimes are the cheaper fix today.
At IETF 126 in Vienna in late July 2026, a side meeting on post-quantum DNSSEC produced something more useful than the usual hand-waving: three working experiments from Johan Stenstam, and a clear-eyed argument about why the DNS case for post-quantum cryptography is weaker than the case elsewhere.
Start with the argument, because it is the part most coverage gets wrong.
DNS keys are not like TLS keys
The standard "harvest now, decrypt later" worry is about confidentiality with a long shelf life. If you want data to stay secret for twenty years, you need a cipher that survives twenty years of adversary capability. That is a real problem for transport encryption.
DNSSEC does not work that way. It signs; it does not encrypt. And because of the interlocking key structure, a key stops being useful the moment it is rolled — recovering an old, discarded DNSSEC key gets an attacker nothing. As Geoff Huston put it in his write-up, the time to worry about post-quantum DNSSEC is when the lifetime of your key material falls inside the horizon of a quantum-capable computer. If you are running twenty-year key lifetimes, worry now. Otherwise the cheapest and most effective mitigation available today is not a new algorithm. It is a shorter key lifetime.
Three experiments
Roll the key faster than it can be broken. Shor's algorithm runs in polynomial time; what gates it is the number of stable qubits, not the wall clock. On a hypothetical fault-tolerant machine, factoring a 2,048-bit RSA key would still take hours to days. So Stenstam rolled an ED25519 KSK every ten minutes for three months, signalling each roll with DSYNC (RFC 9859). He did not pre-publish the DNSKEY, but did pre-publish the quantum-opaque DS hash. By the time the key falls, the zone has moved on.
Split the profile. Use a large post-quantum algorithm for the KSK that signs the apex DNSKEY, and a ZSK with a far smaller signature for everything else. Ordinary signed responses — the ones resolvers actually fetch all day — stay inside UDP-sized payloads. Only the DNSKEY RRset is large, and it is only pulled during validation.
The gargantuan CSK. The brute-force version: a combined signing key producing a DNSKEY response of 23,843 bytes. Two of those still fit inside a 64KB DNS-over-TCP response, so rollover works. You have to patch your DNS implementation to use large buffers, and then, in Stenstam's phrase, it works like a charm.
The transport consequence
Here is the part that matters if you care about encrypted DNS. The size of a DNSKEY response is predictable from the parent's DS record, because the DS carries the algorithm. A resolver that notices a "large" algorithm can go straight to a streaming transport — TCP, DoT, DoQ or DoH — instead of firing a doomed UDP query, collecting a truncated response, and retrying. The wasted round trip disappears.
Splitting KSK and ZSK algorithms also quietly kills the worst operational problem in DNSSEC. Algorithm rollovers are painful today because RFC 4035's algorithm-completeness rule forces double-signing of the entire zone. Split the two and a ZSK algorithm roll becomes trivial — the signer just starts using the new algorithm — while a KSK algorithm roll only affects the one RRset you already knew would be big.
What this means for a resolver you actually use
Nothing, this year. No public resolver is about to start serving 23KB DNSKEY records, and Huston is openly sceptical about the economics: DNS queries are effectively free because their marginal cost is microscopic, and "DNS with large payloads" everywhere is technically fine and fiscally unaffordable.
The directional read is worth holding onto, though. Every credible post-quantum DNSSEC path pushes more validation traffic onto streaming transports. Resolvers that already do DoH, DoT and DoQ well — with warm connections, sensible connection reuse, and low handshake overhead — are the ones that will absorb that shift without the user noticing. That is measurable now, not in some quantum future, and it is what our benchmark tests: real DoH latency from your own network, not a vendor's claimed anycast footprint.
Expect, as Huston notes, more side meetings, research groups and working groups before any of this is settled.
Sources: Geoff Huston, "DNS topics at IETF 126", APNIC Blog (29 July 2026); Johan Stenstam, "PQ DNSSEC Experiments", PQ-DNSSEC side meeting at IETF 126; IETF 126 PQ-DNSSEC side meeting notes; RFC 9859 (DSYNC).
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.