1.1.1.1 starts testing post-quantum DNSSEC
Cloudflare's public resolver can now validate ML-DSA-44 signatures, an early infrastructure step whose 2,420-byte signatures expose the harder problem: moving much larger DNS answers reliably.
The 60-second version
Cloudflare says 1.1.1.1 now validates ML-DSA-44 DNSSEC signatures, giving the Internet a large-scale resolver test bed for post-quantum migration.
Key points
- NIST standardized ML-DSA and IANA lists ML-DSA-44 as DNSSEC algorithm number 18, currently optional for signing and validation.
- A 2,420-byte ML-DSA-44 signature is almost 38 times larger than ECDSA P-256 and exceeds common DNS-over-UDP response targets by itself.
- Oversized answers can trigger a retry over TCP, making bandwidth, latency and middlebox compatibility central deployment questions.
- A complete chain still requires authoritative servers, registrars, registries and the DNS root to adopt post-quantum signing and downgrade protection.
Verdict. A meaningful resolver-side milestone and a useful stress test, but not evidence that DNSSEC as a whole is quantum-safe.
Cloudflare says its 1.1.1.1 public resolver now validates ML-DSA-44 signatures in DNSSEC. The algorithm is standardized by NIST and listed by IANA as DNSSEC algorithm 18. This is a real resolver upgrade, not a completed quantum-safe DNS migration.
The changeWhat the resolver can do now
DNSSEC signs DNS records so a resolver can verify that an answer belongs to an authenticated chain from the DNS root to the requested domain. Common deployed algorithms rely on RSA or elliptic-curve cryptography, which a sufficiently powerful future quantum computer could threaten.
ML-DSA uses a different, lattice-based design. NIST finalized it in FIPS 204 in 2024, and IANA's registry now assigns the ML-DSA-44 variant algorithm number 18. Cloudflare has added the validation side to 1.1.1.1: when a zone publishes the necessary records, the resolver can check them automatically.
Packet pressureWhy 2,420 bytes changes the transport
An ML-DSA-44 signature is almost 38 times the size of an ECDSA P-256 signature. It also exceeds RFC 9715's general 1,400-byte recommendation for DNS-over-UDP responses before the response contains domain names, headers, keys or other DNSSEC records.
| Small UDP answer | Usually travels in one datagram with low overhead. |
|---|---|
| Oversized signed answer | The server can mark the UDP reply truncated, prompting the resolver to retry over TCP. |
| Operational cost | More bytes, more state and potentially more latency must be tested across middleboxes and DNS implementations. |
TCP fallback is normal DNS behavior, not a failure. The concern is frequency and reliability at scale. Cloudflare says enabling validation lets it measure signature-verification cost, bandwidth and additional TCP use before adoption becomes widespread.
Migration trapOld and new signatures must coexist
A zone cannot simply remove its conventional signature while many resolvers do not understand ML-DSA-44. Publishing both preserves compatibility, but it can create a future downgrade path: a post-quantum-capable resolver might accept a forged conventional path after that older algorithm becomes breakable.
Cloudflare says 1.1.1.1 uses an authenticated DS record in the parent zone as a signal to require at least one valid post-quantum path. That is useful only where the chain itself is protected. Any unprotected parent, registry or root remains a place where downgrade resistance can break.
Reality checkWhat is still missing
- Resolver support: 1.1.1.1 can validate algorithm 18, but other resolvers and software need their own implementations.
- Authoritative signing: DNS operators must be able to publish ML-DSA-44 keys and signatures reliably.
- Delegation support: registrars and registries must accept and publish the corresponding DS records.
- Root adoption: complete protection requires a post-quantum trust anchor and protected delegations from the root downward.
- Operational evidence: operators still need measurements for response size, fallback rates, latency, failure modes and rollover behavior.
One resolver learning a new signature is the start of the migration, not the finish line.
For usersNo setting needs to change
People already using 1.1.1.1 do not need to enable anything. Existing DNSSEC zones continue to validate as before, and ML-DSA-44 validation applies when a zone publishes the new records. The practical takeaway is to watch adoption across authoritative DNS, registrars, registries and the root rather than treating a resolver announcement as proof that the whole system is quantum-safe.
Primary sourcesCloudflare: 1.1.1.1 now supports post-quantum DNSSEC·NIST FIPS 204: Module-Lattice-Based Digital Signature Standard·IANA DNS Security Algorithm Numbers registry·IETF Datatracker: ML-DSA for DNSSEC Internet-Draft·RFC 9715: DNS Transport over TCP implementation requirements·PPC Land: independent technical coverage