Cloudflare has enabled validation of DNSSEC signatures created with ML-DSA-44 on its public DNS service, 1.1.1.1, one of the post-quantum signature algorithms standardized by the US National Institute of Standards and Technology (NIST). The change doesn’t encrypt DNS queries or make the Internet resistant to quantum computers, but it introduces a piece that DNSSEC needs to keep verifying the authenticity of records once today’s public-key algorithms are no longer considered secure.
The key facts about Cloudflare’s post-quantum DNS, in 30 seconds
- The 1.1.1.1 resolver can now validate DNSSEC signatures created with ML-DSA-44.
- ML-DSA-44 is designed to withstand known attacks from sufficiently powerful future quantum computers.
- A signature takes up 2,420 bytes, compared to 64 bytes for ECDSA P-256.
- That size alone exceeds DNS’s usual UDP limits and can force a fallback to TCP.
- A complete post-quantum DNSSEC chain from the root down to individual domains doesn’t exist yet.
There’s also an important nuance to this update. Cloudflare isn’t using 1.1.1.1 to sign the DNS responses it delivers to each user, as a simplified reading of the announcement might suggest. The recursive resolver has learned to validate ML-DSA-44 signatures published by DNS zones that use this new algorithm.
It’s an important technical distinction.
In DNSSEC, signatures belong to the zone’s records and are generated on the authoritative side. The resolver then checks the cryptographic chain to determine whether the response it received is authentic and hasn’t been tampered with.
Cloudflare has started with that second part: getting 1.1.1.1 to validate the new algorithm. The company plans to later add ML-DSA-44 signing support to Cloudflare Authoritative DNS, along with support for the corresponding DS records in Cloudflare Registrar.
DNSSEC Doesn’t Encrypt DNS — It Proves the Response Is Authentic
Traditional DNS was born without built-in cryptographic mechanisms to authenticate responses.
That gave rise to attacks that have been known for decades, such as DNS spoofing and cache poisoning, where an attacker tries to inject a fake response so that a legitimate domain ends up resolving to a different IP address.
DNS Security Extensions (DNSSEC) addresses that problem using digital signatures.
A signed zone publishes DNSKEY records containing its public keys and RRSIG records with the corresponding signatures. A resolver that validates DNSSEC can follow a chain of trust from the queried domain up through its parent zones.
The goal is to answer one question: is the data received really what the party responsible for this DNS zone published?
DNSSEC doesn’t answer a different question: can someone observe which domain the user is looking up?
Mechanisms like DNS over HTTPS (DoH) and DNS over TLS (DoT) exist to protect confidentiality, encrypting the communication between the client and the resolver.
The functions are different:
| Technology | What it provides |
|---|---|
| Traditional DNS | Name resolution |
| DNSSEC | Authenticity and integrity |
| DNS over HTTPS | Encryption between client and resolver via HTTPS |
| DNS over TLS | Encryption between client and resolver via TLS |
| DNSSEC + ML-DSA-44 | Authenticity prepared for future quantum attacks |
That’s why simply saying “DNS uses UDP and has no cryptography” falls short of describing DNS today. DNS can run over both UDP and TCP, plus encrypted transports like DoH and DoT. DNSSEC, for its part, has been providing cryptographic authentication for years.
What’s new is which cryptography DNSSEC uses to do it.
The Quantum Problem With RSA and ECDSA
Current DNSSEC implementations can use different algorithms. RSA and ECDSA are among those deployed.
Their security relies on mathematical problems that are extremely costly to solve using sufficiently large classical computers.
The problem is that a large-scale quantum computer capable of efficiently running Shor’s algorithm would change that.
A machine like that could compromise systems based on integer factorization or discrete logarithms, which affects RSA and elliptic-curve cryptography.
That cryptographically relevant quantum computer doesn’t currently exist.
The migration is being prepared before it exists, because changing algorithms deployed across the entire Internet takes years. Other operators are already treating that migration as urgent: Telefónica has started securing its data center connections with post-quantum cryptography, framing the question as no longer “if” but “when.”
Cloudflare points out that DNSSEC adds a particular difficulty: the chain of trust runs through several organizations and levels:
DNS root
│
▼
TLD (.com, .es, .org...)
│
▼
Domain
│
▼
Signed DNS records
│
▼
Validating resolverGetting a truly post-quantum chain takes more than just having one domain use ML-DSA-44.
Its parent zone has to be able to publish the necessary information, registries have to accept it, registrars have to support it, resolvers have to verify it, and, ultimately, the DNS root itself will need a post-quantum chain of trust.
Cloudflare isn’t announcing that scenario yet.
1.1.1.1 represents one of the first steps along that path.
ML-DSA-44 Brings an Unexpected Problem: The Signatures Are Huge
Post-quantum cryptography has a trade-off that’s especially relevant for DNS: size.
Cloudflare compares three configurations:
| Algorithm | Public key | Signature |
|---|---|---|
| RSA-2048/SHA-256 | 260 bytes | 256 bytes |
| ECDSA P-256 | 64 bytes | 64 bytes |
| ML-DSA-44 | 1,312 bytes | 2,420 bytes |
An ML-DSA-44 signature is almost 38 times bigger than an ECDSA P-256 signature.
The example provided by researcher Bill Buchanan makes this directly observable with dig. Querying the test domain valid.mldsa44.dnstest.dev, the DNSKEY record contains a 1,312-byte ML-DSA-44 public key.
A DNSSEC query to Cloudflare’s resolver can be run with:
dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssecThe response includes an RRSIG identified with DNSSEC algorithm 18, assigned to ML-DSA-44.
And that’s where the operational problem shows up.
DNS historically used UDP packets of up to 512 bytes. EDNS(0) later made it possible to negotiate larger responses, but many systems stick to a conservative 1,232-byte UDP payload to avoid fragmentation issues tied to IPv6’s minimum MTU.
RFC 9715 currently recommends not exceeding 1,400 bytes for DNS over UDP.
A single ML-DSA-44 signature takes up 2,420 bytes.
It doesn’t fit.
A Query That Used to Travel Over UDP Can End Up on TCP
The consequence can be seen directly using dig.
Buchanan’s test shows this:
;; Truncated, retrying in TCP mode.The server returns a truncated response, and the resolver retries using TCP.
This doesn’t mean DNS over TCP is unusual or wrong. It has been part of the protocol for a long time.
But it does change the operational characteristics once it starts happening more often.
With a post-quantum signature, the following can increase:
- traffic generated by certain lookups;
- the number of queries that require TCP;
- the memory used for caching;
- the computational cost of verification;
- and the load on authoritative servers and resolvers.
DNSKEY responses can grow even more, because during a migration it won’t be possible to immediately remove traditional keys.
A zone might need to publish simultaneously:
ECDSA DNSKEY
ML-DSA-44 DNSKEY
ECDSA RRSIG
ML-DSA-44 RRSIGThat keeps compatibility with older resolvers, but multiplies the size of certain responses.
Key rollovers, where multiple keys coexist for a period to allow for a safe changeover, can add even more information.
Keeping ECDSA Around Also Opens the Door to a Downgrade
The coexistence of classical and post-quantum cryptography creates another, less visible problem.
Suppose a zone publishes both ECDSA and ML-DSA-44.
An older resolver uses ECDSA because it doesn’t understand the new algorithm. A modern one could validate ML-DSA-44.
Both systems will have to coexist for years.
But if ECDSA could someday be broken by a quantum computer, an attacker could try to strip the post-quantum elements out of the response and present only a forged ECDSA chain.
The modern resolver might simply interpret this as a zone that still uses the old algorithm.
It’s a downgrade attack.
Cloudflare has introduced a specific policy in 1.1.1.1 to prevent this.
When an authenticated set of DS records indicates the presence of a supported post-quantum algorithm, the resolver requires at least one valid post-quantum verification path to exist. A correct conventional signature is no longer enough on its own.
The policy is deliberately stricter than DNSSEC’s traditional behavior.
The problem resurfaces, however, if some higher level of the chain still relies exclusively on classical cryptography. That’s why the full migration eventually has to reach the DNS root.
ML-DSA-44 Has Already Been Assigned DNSSEC Algorithm Number 18
ML-DSA comes from the algorithm family previously known as CRYSTALS-Dilithium, and it was standardized by NIST as part of its transition toward post-quantum cryptography.
Using it within DNSSEC also required defining how to represent its keys and signatures in DNS records.
ML-DSA-44 now has DNSSEC algorithm number 18, one of the requirements for starting its interoperable rollout.
At the same time, work continues within the Internet Engineering Task Force (IETF). There are drafts on the use of ML-DSA in DNSSEC and proposals such as ML-DSA-MTL, which combines lattice-based signatures with Merkle tree structures to explore alternatives suited to DNS’s particular characteristics.
These documents remain works in progress and shouldn’t be read as final standards.
1.1.1.1 Users Don’t Have to Change Anything
For anyone already using 1.1.1.1 as their resolver, the change is transparent.
Once a zone publishes the necessary records, Cloudflare will be able to validate ML-DSA-44. Conventional DNSSEC zones will keep working exactly as before.
The company will also use test domains to measure what happens when these much larger responses pass through real-world networks, routers, firewalls, and resolvers.
That work can be just as important as the cryptography itself.
The transition to post-quantum algorithms in TLS already showed that increasing the size of certain messages can expose hidden limits and assumptions in software and network equipment. DNS is even more sensitive to size, because much of its traffic still runs over UDP.
Cloudflare estimates that roughly 85% of the queries reaching 1.1.1.1 use UDP. That figure refers to the transport between clients and Cloudflare’s resolution service, not necessarily to what’s used afterward between the resolver and the authoritative servers.
The company has set 2029 as its target for achieving post-quantum protection across its systems. DNSSEC is one of the pieces that still has to travel that road.
This update to 1.1.1.1 also doesn’t mean there’s an immediate quantum threat against DNS. Unlike encrypted traffic that can be stored today in hopes of decrypting it years later, DNSSEC protects authenticity, not confidentiality, so it doesn’t carry exactly the same “harvest now, decrypt later” problem.
There’s time, but the infrastructure that needs to change is enormous.
And the ML-DSA-44 experiment already shows one of the practical challenges: replacing a 64-byte ECDSA signature with one built for a post-quantum future means jumping to 2,420 bytes.
On paper, a cryptographic algorithm can change in a few lines. On the Internet, those extra 2,356 bytes have to pass through millions of servers, resolvers, firewalls, and network devices without breaking anything.
Sources:
- Cloudflare, 1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it, September 10, 2026.
