DNSSEC & Post-Quantum Signatures

DNSSEC (DNS Security Extensions, RFC 4034, consolidated in RFC 9364/BCP 237) adds cryptographic signatures to DNS answers. A resolver that validates DNSSEC can prove a DNS record came from the zone's real owner and was not altered or forged in transit — it chains trust from the DNS root, through each delegated zone's DS record, down to the DNSKEY/RRSIG pair that signs the actual answer.

Today's most widely deployed DNSSEC signature algorithms are RSA and ECDSA (RFC 6605). Both rely on integer factorization or elliptic-curve discrete logarithm hardness — exactly the problems Shor's algorithm breaks.

draft-westerbaan-dnssec-mldsa (Westerbaan/Cloudflare, Schmieg/Google) specifies DNSSEC's DS, DNSKEY, and RRSIG resource records for ML-DSA-44 — the smallest of FIPS 204's three parameter sets (44 / 65 / 87), chosen specifically to minimize DNS message size. IANA has assigned it DNSSEC algorithm number 18 (mnemonic MLDSA44).

An RRSIG carrying a 2,420-byte ML-DSA-44 signature dwarfs 1,232 bytes— a common conservative UDP payload limit (RFC 9715 recommends up to 1,400 bytes). Responses over that limit need another transport, normally TCP — a real operational cost, not just a theoretical one. Signature size is one of several open migration challenges alongside compatibility and downgrade protection; the specification remains an individual draft rather than a working-group-adopted standard.

On 2026-09-10, Cloudflare announced that ML-DSA-44 (algorithm 18) DNSSEC validation is enabled by default on the 1.1.1.1 public resolver, alongside dnstest.dev, a live ML-DSA-44-signed test zone resolvers can validate against. This is a real production deployment of ML-DSA-44 validation on Cloudflare's resolver — not just a draft.

See the Protocol Support matrix's DNSSEC row for the full, continuously-tracked deployment record behind this claim.

Cloudflare's own roadmap names two concrete steps still ahead before PQ DNSSEC can run end-to-end in production:

Cloudflare's own company-wide post-quantum security target is ~2029 — the blog post doesn't give a separate, DNSSEC-specific completion date, and delivering Cloudflare's own two features above is not the same as full end-to-end PQ DNSSEC: that also needs the root to become a trusted PQ anchor and other registries/registrars to adopt algorithm 18. Keep that distinct from the DNS root zone's own algorithm rollover, which Verisign estimates at the mid-2030s — every level of the chain needs PQ support before the downgrade-safety design above is fully post-quantum-secure, though the order in which levels migrate isn't prescribed. Keep the two numbers separate: one vendor's roadmap, one global infrastructure migration.

Two parallel efforts attack the same signature-size problem differently: draft-sheth-pqc-dnssec-strategy surveys SLH-DSA-MTL, Falcon, XMSS, and LMS as DNSSEC candidates, while draft-fregly-dnsop-slh-dsa-mtl-dnssec and draft-kaizer-dnsop-ml-dsa-mtl-dnssec both apply Merkle Tree Ladder mode — to SLH-DSA and ML-DSA respectively — to shrink the per-query signature cost. None of these has IETF working-group status yet.