Cloudflare's 1.1.1.1 Resolver Now Validates ML-DSA-44 DNSSEC Signatures, Announced 10 September 2026, and Refuses the Classical Fallback That RFC 6840 Would Allow
In November 1987 Paul Mockapetris wrote into RFC 1035 that a DNS message carried over UDP is restricted to 512 bytes, and that anything longer is truncated with a flag set so the client can retry over TCP. The number was chosen for the networks of the time. It outlived them. Extension mechanisms in 1999 and again in 2013 let a resolver advertise a larger buffer, DNS operators converged on 1,232 bytes to fit inside the smallest packet IPv6 guarantees, and in January 2025 RFC 9715 recommended 1,400 bytes as the ceiling for DNS over UDP. Nearly forty years after Mockapetris, the size of a single answer is still the constraint that shapes what the domain name system can carry, and the first post-quantum signature to reach it does not fit.
On 10 September 2026 Sebastiaan Neuteboom and Bas Westerbaan of Cloudflare announced that the public resolver 1.1.1.1 validates DNSSEC signatures made with ML-DSA-44, the module-lattice signature NIST standardized as FIPS 204 in August 2024. Each ML-DSA-44 signature is 2,420 bytes. An ECDSA P-256 signature is 64. The public key is 1,312 bytes where ECDSA's is 64 and RSA-2048's is 260. Cloudflare's own table puts the ratio at almost 38 to one, and the post is candid about why it is doing this now: the company wants to test two things at Internet scale, carrying responses of that size reliably and preventing a resolver that supports the new algorithm from being talked back into the old one.
Practical takeaway. A post-quantum DNSSEC signature is too large for the UDP budget DNS operators actually use, so a signed response carrying one is truncated and retried over another transport, usually TCP, between the validating resolver and the authoritative server, and the anti-downgrade rule 1.1.1.1 applies is stricter than the published standard. For anyone who signs zones, runs resolvers or writes procurement language for either, the migration is a change in transport behavior and in validation policy as much as a change of algorithm.
What 1.1.1.1 does since 10 September 2026, and what it does not yet do
The resolver side is live. If a zone publishes an ML-DSA-44 DNSKEY and its parent publishes the
matching DS record, 1.1.1.1 validates the chain with the new algorithm and nobody using the
resolver has to change a setting. Cloudflare has published a test zone, and the dig +dnssec output
in its announcement shows a query for valid.mldsa44.dnstest.dev returning a 2,563-byte answer after
the expected warning that the UDP reply was truncated and the retry ran over TCP. The company says it will also send background probes from
a small fraction of its challenge pages to see whether real client networks can resolve and reach
an ML-DSA-44-signed name.
The signing side is a plan. The post states that ML-DSA-44 signing in Cloudflare's authoritative DNS and DS-record support in its registrar are the next step and will be free to all customers, with no date. That matters because DNSSEC authenticity is a chain: authoritative servers must sign with the new algorithm, registrars must accept and submit the corresponding DS records, registries must publish them in the parent zone, and the root must eventually carry a post-quantum key that resolvers hold as a trust anchor. Any level left on a classical algorithm remains a point where a future quantum computer could forge a delegation, which Cloudflare summarizes as break once, forge everywhere. The resolver announcement closes none of those levels. It makes the first one measurable.
Why 2,420 bytes collide with RFC 1035, RFC 6891 and RFC 9715
The arithmetic is simple and unforgiving. A DNSKEY response for a zone during migration carries at least one classical key, one classical signature, one 1,312-byte ML-DSA-44 key and one 2,420-byte ML-DSA-44 signature, before the owner name, the header and any additional records. Key rollovers add more keys. None of that fits in 1,232 or 1,400 bytes, and sending it as fragmented UDP is the failure mode the DNS Flag Day of 2020 and RFC 9715 were written to end, because fragments are dropped by middleboxes and can be used for cache poisoning. The correct behavior is the one Mockapetris specified in 1987: truncate, set the flag, let the resolver come back over another transport, usually TCP.
Cloudflare's numbers show why that is tolerable for a resolver of its size and a real change for smaller ones. Around 85 percent of queries reaching 1.1.1.1 arrive over UDP; across the platform behind it, which also serves its Gateway DNS product, about 60 percent do, with the rest on TCP, DNS over TLS and DNS over HTTPS. Those figures describe the client side. The post concedes that large ML-DSA-44 responses will still cause additional TCP retries on the other side, between the resolver and authoritative servers, which is the side every operator of a validating resolver will feel. Quentir's Defense Monitor made the same point about signing services in July, when Google's Cloud KMS shipped ML-DSA and the piece argued that post-quantum signing is a systems test of everything that has to carry a signature, and DNS is the system with the oldest and smallest packet.
Why RFC 6840's "any single valid path" becomes a downgrade path, and what 1.1.1.1 does instead
The second problem is a standards problem, and it predates lattice cryptography. Section 5.11 of RFC 6840, the DNSSEC implementation notes of February 2013, says a signed zone must be signed with every algorithm it advertises, and then adds that this requirement applies to servers. Validators, it says, "SHOULD accept any single valid path" and must not insist that every advertised algorithm work. The rule was written so that a zone could add a new algorithm without breaking resolvers that lacked it. During a post-quantum migration a zone will publish RSA or ECDSA and ML-DSA-44 side by side for years, and under RFC 6840 a resolver that supports ML-DSA-44 may still accept the classical path. Once a quantum computer can recover a classical key, an attacker forges an ECDSA-only answer, and the resolver that could have checked the lattice signature accepts it anyway. The compatibility rule becomes a downgrade path.
Cloudflare's answer is a local policy. Where the authenticated DS set in the parent zone contains a record for a supported post-quantum algorithm, 1.1.1.1 treats that as the signal and requires at least one valid post-quantum path; a classical path on its own fails validation. The post says plainly that this "is not (yet) normal DNSSEC validation behavior" and rests it on RFC 4035, which leaves it to local resolver security policy whether additional signatures must be tested and how conflicting results are resolved. The signal is only as strong as the chain above it: the downgrade protection holds from the trust anchor down only where every delegation carries a post-quantum DS, and rotating a zone key more often does nothing against an attacker who targets a weaker key higher up. The Internet-Draft discusses the same downgrade problem, which is the point at which a resolver operator's policy choice becomes a question for the standards body.
What IANA number 18 and the Westerbaan-Schmieg draft settle, and what they leave open
Three layers have to agree before a signature algorithm can be used in DNSSEC: a cryptographic standard, an algorithm number, and a specification of how keys and signatures are encoded in DNSKEY and RRSIG records. The first exists since August 2024. The second exists: the IANA DNSSEC algorithm registry lists number 18 as ML-DSA-44, with every column marked MAY rather than RECOMMENDED. The third is an individual Internet-Draft by Westerbaan of Cloudflare and Sophie Schmieg of Google, revision 04 of 11 August 2026, expiring 12 February 2027, intended for the standards track and discussed on the DNS operations list, with no working-group adoption shown on the datatracker as of this post. The registry entry cites revision 03. A production resolver on the public Internet is therefore validating an algorithm whose DNSSEC encoding is specified in a document the IETF describes as having no formal standing, which is how early deployment usually looks and is worth stating exactly.
The threat model deserves the same precision. DNSSEC authenticates DNS data and encrypts nothing, so harvest-now-decrypt-later, the attack that justifies moving key exchange first, is not the relevant threat; the migration concern is future forgery of classical signatures once a quantum computer can recover a classical key. Cloudflare's stated reason for starting now is coordination time. Its own experience with post-quantum key agreement in TLS, begun in 2019 and enabled for all customers in 2022, was that client adoption took years because larger messages exposed bugs in network software. The DNS chain has more parties and one shared root, and Cloudflare is preparing for the possibility that a cryptographically relevant quantum computer exists in 2030, the same year its 2029 network-wide target is meant to precede.
How Quentir Reads It
Three implications follow. The first is about who moves first. The resolver was the right place to start, because a signed zone nobody validates proves nothing, and Cloudflare now has the instrument to measure verification cost, bandwidth and TCP load before a single production zone signs with ML-DSA-44. The cost of that sequencing is that the next moves belong to registrars, registries and, eventually, the root zone's key holders, none of whom announced anything on 10 September. An early deployment step for post-quantum DNSSEC has been taken at the one layer a single company controls, and the chain's completion depends on institutions that move by consensus.
The second is about policy versus standard. 1.1.1.1's refusal of a classical-only path is stricter than RFC 6840 and permitted by RFC 4035, which means that for the same signed zone two compliant resolvers can now return different answers: one accepts the forged ECDSA path, the other refuses it. That gap is exactly what the Crypto-Agility as a Verifiable Duty Signature Brief was written for: it carries the published maturity criteria and the contract language that make an algorithm transition verifiable across a supplier boundary, which a public post does not attempt. The DNSSEC case adds one criterion the Brief's readers will want to write down, whether a resolver's anti-downgrade policy is documented at all.
The third is about the packet. The 512-byte limit of 1987, the 1,232-byte convention and the 1,400-byte recommendation of 2025 were engineering compromises made without lattice signatures in view, and ML-DSA-44 is the smallest parameter set NIST standardized. Every larger post-quantum signature makes the TCP fallback the normal case, and every middlebox that mishandles DNS over TCP becomes a migration blocker. Cloudflare has asked other DNS operators and implementers to start testing ML-DSA-44 at scale. The measurement that will decide the schedule is how many networks still cannot carry a 2,563-byte answer, and that number is not in the announcement.
Sources: Sebastiaan Neuteboom and Bas Westerbaan, "1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it", Cloudflare blog, 10 September 2026 (signature and key sizes, transport shares, downgrade policy, test zone output, next steps). Cloudflare, "Cloudflare targets 2029 for full post-quantum security", 7 April 2026. IANA, DNS Security Algorithm Numbers (entry 18, ML-DSA-44, reference draft-westerbaan-dnssec-mldsa-03), consulted 15 September 2026. Bas Westerbaan and Sophie Schmieg, "Module-Lattice Digital Signature Algorithm for DNSSEC", draft-westerbaan-dnssec-mldsa-04, Internet-Draft, 11 August 2026, expires 12 February 2027. P. Mockapetris, RFC 1035, Domain Names, Implementation and Specification, November 1987 (sections 2.3.4 and 4.2.1). S. Weiler and D. Blacka, RFC 6840, Clarifications and Implementation Notes for DNS Security, February 2013 (section 5.11). R. Arends et al., RFC 4035, Protocol Modifications for the DNS Security Extensions, March 2005 (section 5.3.3). K. Fujiwara and P. Vixie, RFC 9715, IP Fragmentation Avoidance in DNS over UDP, January 2025. NIST, "NIST Releases First 3 Finalized Post-Quantum Encryption Standards", 13 August 2024. All pages read on 15 September 2026.
Published intelligence, built to inform your own decisions. Published: September 15, 2026.