Cloudflare enables post-quantum DNSSEC validation with ML-DSA-44 on 1.1.1.1
The public resolver 1.1.1.1 now validates DNSSEC signatures made with ML-DSA-44, the NIST-standardized post-quantum algorithm whose every signature weighs 2,420 bytes. It is the first Internet-scale test of carrying oversized DNS responses and blocking downgrade to weakened algorithms.
September 10, 2026. Cloudflare announces that 1.1.1.1, its public DNS resolver, now validates DNSSEC signatures produced with ML-DSA-44, the post-quantum signature algorithm standardized by NIST. The difficulty comes down to one number: 2,420 bytes per signature, nearly 38 times the size of a 64-byte ECDSA P-256 signature. This is not just another algorithm being added — it is the first Internet-scale exercise of two problems the DNS community will have to solve together: carrying oversized responses, and blocking downgrade to weakened algorithms.
Why DNSSEC needs post-quantum now
Cloudflare is aiming for full post-quantum security by 2029. Most of the effort so far has gone to TLS, but DNSSEC also relies on public-key cryptography — RSA and ECDSA, both vulnerable to a sufficiently powerful quantum computer.
DNSSEC is not exposed to “harvest now, decrypt later” attacks: it provides authenticity, not confidentiality. The urgency lies elsewhere. Migrating DNSSEC requires coordination across authoritative servers, registries, registrars, and validating resolvers — and the migration must eventually reach the top of the DNS hierarchy, where a compromised key does the most damage. An attacker who recovers the root-zone signing key with a quantum computer could forge a validation path to any zone beneath it: “break once, forge everywhere.” ML-DSA-44 gives that migration a standardized starting point.
The 2,420-byte problem
Today’s DNSSEC algorithms produce small signatures. ML-DSA-44 produces a 2,420-byte signature and a 1,312-byte public key. DNS, meanwhile, is extremely sensitive to message size.
Historically, DNS restricted UDP responses to 512 bytes. EDNS(0) later let a resolver advertise the largest UDP response it accepts; many implementations use a conservative 1,232-byte limit, chosen to fit within IPv6’s minimum MTU of 1,280 bytes. More recently, RFC 9715 recommended a maximum of 1,400 bytes for DNS over UDP. A single ML-DSA-44 signature exceeds that budget on its own, before counting the signed RRset, domain names, headers, and other DNSSEC records.
Sending such a response as fragmented UDP is unreliable. The known workaround: the authoritative server returns a truncated response, prompting the resolver to retry over TCP. This is the behavior Cloudflare now measures in production: about 85% of queries to 1.1.1.1 arrive over UDP, and 60% across everything served by the Big Pineapple platform — the remaining 40% use TCP, DoT, or DoH.
Blocking downgrade, not just signing
The second problem is subtler. A zone cannot publish ML-DSA-44 alone without breaking validation for resolvers that do not support it yet. The practical migration path is to publish conventional and post-quantum keys and signatures together.
But RFC 6840 states that “validators SHOULD accept any single valid path.” Once ECDSA is weakened, that behavior creates a downgrade path: an attacker could forge an ECDSA-only answer that a resolver accepts even though it supports ML-DSA-44.
1.1.1.1 closes that path using the DS records published by the parent zone. If the authenticated DS RRset contains a record for a supported post-quantum algorithm, the resolver applies a stricter local validation policy: it requires at least one valid post-quantum path, and a conventional path is no longer sufficient. RFC 4035 allows such local policy. Conventional signatures remain available to older resolvers, without letting modern resolvers fall back to them.
What is still missing
ML-DSA-44 now has its initial prerequisites: NIST has standardized it, common cryptographic libraries implement it, an Internet-Draft describes its use in DNSSEC, and IANA assigned it algorithm number 18. But adding resolver-side validation is only a first step.
Authoritative servers must sign zones with ML-DSA-44, registrars must accept the corresponding DS records, and registries must publish them in parent zones — up to the root, whose post-quantum key must become a trust anchor. Any level without post-quantum protection remains a downgrade point.
Cloudflare says its next step is adding ML-DSA-44 signing to its Authoritative DNS and DS record support to its Registrar, free of charge. Together these will test the complete path, from signature generation to validation through 1.1.1.1. A test domain already exists: valid.mldsa44.dnstest.dev, queryable with dig @1.1.1.1.
Verdict
If you use 1.1.1.1, you have nothing to do: ML-DSA-44 validation activates automatically when a zone publishes the necessary records, and existing zones keep validating as before.
If you operate a resolver or a DNSSEC zone, this is the time to start testing: carrying 2,420-byte signatures will surface breakage in middleboxes, exactly as post-quantum TLS did in its day. If you run a signing chain (authoritative, registrar, registry), measure now whether you can publish ML-DSA-44 DS records and serve truncated responses over TCP — that is where the real pace of the migration will be decided.