Cloudflare’s 1.1.1.1 Now Validates Post-Quantum DNSSEC Signatures – And Shows Why PQC Migration Is a Systems Problem

Table of Contents

10 Sep 2026 – Cloudflare enabled ML-DSA-44 signature validation on its 1.1.1.1 public DNS resolver on September 10, 2026, the company announced in an engineering blog post. The resolver now checks post-quantum DNSSEC signatures when a zone publishes the necessary records. Google Public DNS, Quad9, and Cisco OpenDNS do not yet validate ML-DSA-44.

ML-DSA-44 is the smallest parameter set of the Module-Lattice-Based Digital Signature Algorithm standardized by NIST in FIPS 204. IANA assigned it DNSSEC algorithm number 18 in August 2026, with a status of MAY for both signing and validation. Its use in DNSSEC is described in an Internet-Draft co-authored by Cloudflare’s Bas Westerbaan and Google’s Sophie Schmieg. The draft remains an active individual submission and has not been adopted as an IETF standard.

An ML-DSA-44 signature is 2,420 bytes; the public key is 1,312 bytes. ECDSA P-256, widely used in DNSSEC-signed zones today, produces 64-byte signatures and 64-byte keys. A single ML-DSA-44 signature exceeds both the 1,232-byte conservative UDP payload limit that many DNS implementations advertise and the 1,400-byte maximum that RFC 9715 recommends, forcing the authoritative server to truncate the UDP response and the resolver to retry over TCP.

Cloudflare also implemented a stricter local validation policy to address the downgrade risk created during the transition period when zones publish both conventional and post-quantum signatures. Under RFC 6840, a resolver should accept any single valid signature path. Cloudflare’s resolver instead requires a valid ML-DSA-44 path when the parent zone’s authenticated DS record set includes a post-quantum algorithm, Westerbaan and Sebastiaan Neuteboom wrote. Conventional paths alone no longer satisfy validation for those zones.

The company said it plans to add ML-DSA-44 signing support to Cloudflare Authoritative DNS and corresponding DS record support to Cloudflare Registrar, which will be available to all customers at no charge. Cloudflare published a test zone at dnstest.dev for operators who want to verify their own resolvers.

Cloudflare has stated a target of full post-quantum security by 2029 across its products. The company began experimenting with post-quantum key agreement in TLS in 2019 and enabled it for all customers in 2022.

My Analysis

Why DNSSEC Is the Strongest PQC Migration Case Study This Month

The cryptography in Cloudflare’s post is the least of it. ML-DSA-44 is a known quantity. The engineering around it exposed a 2,420-byte signature colliding with a protocol stack designed around 512-byte UDP packets, a multi-year coexistence period that introduces the kind of downgrade path attackers exploit, and a chain of trust that must extend from a single resolver all the way up to the DNS root zone before the protection means anything.

A single resolver deployment surfaced transport breaks, downgrade paths, and a trust chain that runs through five independent layers of DNS governance.

2,420 Bytes Against a 1,232-Byte Ceiling

DNS was built for small messages. The original 1987 specification capped UDP responses at 512 bytes. EDNS(0) extended that limit. Many implementations still advertise a 1,232-byte payload limit – IPv6’s 1,280-byte minimum MTU minus 48 for the IPv6 and UDP headers. RFC 9715, published in January 2025, recommended a 1,400-byte DNS-over-UDP maximum to reduce fragmentation. Both figures are generous by 1987 standards and impossibly small for post-quantum signatures.

A single ML-DSA-44 signature blows past both limits on its own, before any DNS record, domain name, or header is counted. In the DNSKEY response, which a resolver fetches to obtain the keys it needs for validation, the response must include both the 1,312-byte public key and a 2,420-byte signature covering the key set. That is 3,732 bytes of post-quantum cryptographic material alone, before the domain name, DNS headers, or any other records in the response.

The consequence is forced TCP fallback. The authoritative server returns a truncated UDP response with the TC bit set, the resolver retries over TCP, and the query completes.

TCP retry is routine in DNS; Cloudflare reports that roughly 85% of queries to 1.1.1.1 still arrive over UDP, with the remainder using TCP, DNS over TLS, and DNS over HTTPS. Across Cloudflare’s full resolver fleet (which includes Gateway DNS and other services beyond 1.1.1.1), roughly 40% of queries arrive over non-UDP transports. Those figures describe how clients reach Cloudflare’s resolvers. They do not describe the resolver-to-authoritative hop, which is where the post-quantum TCP retry overhead increases latency. Handling TCP on that hop is standard, but every post-quantum DNSKEY fetch adds a retry that would not have occurred under ECDSA.

The overhead also pressures authoritative servers with weak TCP support. RFC 7766 made TCP mandatory for general-purpose DNS implementations in 2016, and RFC 9210 reinforced it as a best current practice in 2022. In practice, compliance lags the standard. A 2020 measurement by Müller et al. at SIDN, TNO, and the University of Twente, cited in a post-quantum DNSSEC study by Goertzen and Stebila at the University of Waterloo, found non-trivial numbers of nameservers still failing TCP queries. That measurement predates the BCP reinforcement, and compliance has improved since, but servers without TCP support cannot participate in post-quantum DNS at all. They will serve truncated responses that post-quantum resolvers cannot complete.

TLS showed the same cliff. Two years ago I covered Cloudflare’s measurement of the size cliff in TLS handshakes. Extra data below about nine kilobytes slowed connections by roughly fifteen percent; crossing the ten-kilobyte mark produced a sharp rise in client and middlebox failures. [EDITOR: Verify these specific figures against the PostQuantum.com infrastructure-challenges article and the original Cloudflare “Sizing Up Post-Quantum Signatures” post – reviewers flagged that the 9 KB/15% and 10 KB/60% figures may conflate measured results at Cloudflare’s 30-packet initial congestion window with projected results for typical 10-packet windows.]

The mechanisms differ in DNS – truncation and TCP retry rather than congestion-window overflows – but the structural pattern is the same. Post-quantum sizes cross thresholds that protocols enforce, and the breaks cascade through infrastructure that was never designed for cryptographic objects this large.

The problem compounds during the transition. Zones that need to remain compatible with older resolvers must publish both conventional and post-quantum keys and signatures in the same DNSKEY response. That means ECDSA keys and signatures alongside ML-DSA-44 keys and signatures, roughly doubling the cryptographic material and pushing responses further past the UDP ceiling.

Key rollovers, which temporarily add a second key of each type, make them larger again. During a key rollover, the cryptographic material in a dual-algorithm DNSKEY response would reach roughly 7,720 bytes (256 for two ECDSA key-and-signature sets, 7,464 for two ML-DSA-44 key-and-signature sets) approaching 8 kilobytes before DNS headers and domain names.

The Downgrade Problem Is the Hard One

DNSSEC’s current validation rule, specified in RFC 6840, says that a resolver should accept any single valid signature path. If a zone publishes both ECDSA and ML-DSA-44 signatures, a compliant resolver that supports both algorithms can validate the response using either one. That rule exists for good reason: it allowed DNSSEC to accommodate new algorithms without requiring every resolver to support every algorithm simultaneously.

Once ECDSA is no longer secure, the same rule creates a downgrade path. An attacker who has recovered the zone’s ECDSA signing key, using a quantum computer running Shor’s algorithm against the P-256 curve, could strip the ML-DSA-44 signatures from a legitimate response and substitute a forged ECDSA-only answer. A resolver following standard RFC 6840 guidance would accept the forged response, because the ECDSA path validates. The resolver supports ML-DSA-44, the zone publishes ML-DSA-44 signatures, and neither fact prevents the downgrade.

Cloudflare’s solution is a local policy override permitted by RFC 4035. When the authenticated DS record set in the parent zone includes an ML-DSA-44 entry, 1.1.1.1 requires a valid ML-DSA-44 validation path. A conventional path alone no longer satisfies. The parent zone’s DS records act as the authenticated signal that post-quantum validation is expected, and the resolver enforces it.

That is a reasonable engineering choice, but it depends on a condition that Cloudflare’s own post correctly identifies: the downgrade protection is only post-quantum secure if ML-DSA-44 deployment extends through every delegation in the chain, from the queried zone through every parent up to the root. An attacker who can forge signatures at any level above the target zone can forge the entire delegation path below it. Cloudflare calls this “break once, forge everywhere,” and the label is accurate. A compromised root zone signing key, which today protects every zone in the DNS hierarchy, would let an attacker construct a valid-looking delegation chain to any domain.

This is a Trust Now, Forge Later problem applied to DNS infrastructure. DNSSEC protects authenticity, it does not protect confidentiality, so it is not subject to harvest-now-decrypt-later attacks in the usual sense. An attacker does not need to have intercepted traffic in advance. They need to recover one signing key, and every delegation below that key is forgeable from that moment forward. A key higher in the hierarchy lets the attacker forge more domains below it. A compromised TLD key covers every domain in that TLD. A compromised root key covers everything.

One Link in a Chain That Does Not Yet Exist

Resolver validation is a necessary first step, and it enables nothing on its own. For the post-quantum chain of trust to protect a zone, every layer above it must participate.

Authoritative servers must sign zones with ML-DSA-44. Cloudflare has announced plans for its own authoritative DNS, but the long tail of DNS infrastructure runs on BIND, NSD, Knot, PowerDNS, and custom implementations. Each needs ML-DSA-44 support in its signing toolchain. The IETF draft describing ML-DSA-44 for DNSSEC remains an active individual submission. IANA’s algorithm-18 status is MAY for both signing and validation, which permits experimentation but does not endorse universal deployment.

Registrars must accept algorithm-18 DS records from zone operators and submit them to the parent zone. DS records contain a hash of the DNSKEY, so the 1,312-byte public key never reaches the registrar. The problem is tooling: EPP extensions, web-based DNSSEC dashboards, and automated provisioning workflows were all built around RSA and ECDSA algorithm identifiers. Supporting a new algorithm number requires changes throughout that stack, and most registrars have no incentive to prioritize it until zones actually demand it.

Registries must publish those DS records in the parent zone. The .com, .net, .org, and ccTLD registries each maintain their own DNSSEC signing infrastructure, and each will need to validate and publish algorithm-18 DS records. The registry-side changes are narrower in scope than the registrar-side changes. A TLD registry that adds algorithm-18 DS support enables every domain under it to publish post-quantum delegations. Conversely, a TLD registry that does not blocks every domain beneath it from completing its post-quantum chain.

The root zone must adopt ML-DSA-44. ICANN operates the root zone’s key-signing key (KSK) across two key management facilities. Verisign operates the zone-signing key (ZSK). A post-quantum KSK must eventually become a trust anchor distributed to every validating resolver worldwide, through the same RFC 5011 automated rollover mechanism that delivered the 2018 KSK rollover. Any level in the hierarchy without post-quantum signing remains a downgrade point, and a quantum-capable attacker who compromises the root key can forge delegation chains to any domain.

Cloudflare’s resolver can validate ML-DSA-44 signatures today because the company built a test zone signed with the algorithm. The test zone proves the software works. The zones that matter – the root and the major TLDs – are years away from ML-DSA-44 deployment. Neither ICANN nor Verisign has announced a post-quantum root signing timeline. The chain of trust is as strong as its weakest delegation, and today that weakness is everywhere above the leaf zone.

What This Means for Migration Planning

Organizations planning or executing PQC migration should draw three conclusions from Cloudflare’s deployment.

First, it confirms that post-quantum signature sizes create protocol-level engineering challenges that cannot be solved by swapping a cryptographic library. DNS, TLS, X.509, IKEv2 – each protocol has its own size assumptions, and each breaks differently when signatures grow by a factor of 38. DNS hits the 1,232-byte UDP ceiling. TLS hits the initial congestion window. X.509 hits certificate-chain sizes that overflow middlebox buffers. IKEv2 hits initiator packet sizes that require the RFC 7383 fragmentation extension. The organizations that treat PQC migration as a library upgrade will discover these constraints one protocol at a time, usually in production.

Second, the downgrade problem during dual-algorithm coexistence is not unique to DNSSEC. Every system that publishes both conventional and post-quantum signatures during the transition period faces the same question: how does a relying party know to require the post-quantum path? In TLS 1.3, the answer involves negotiation and downgrade-detection mechanisms built into the protocol’s transcript signing. In DNSSEC, the answer is a DS record in the parent zone plus a local resolver policy. In your own infrastructure – your internal PKI, your code-signing chains, your firmware-update verification – the answer may not exist yet.

Designing the downgrade-protection mechanism is part of the migration work, and it must happen before you need it. Retrofitting under pressure is how gaps stay open.

Third, PQC migration sequences across trust hierarchies. In DNSSEC, the resolver came first, then authoritative servers, then registrars, then registries, then the root. Each layer depends on the one below it for software support and the one above it for the authenticated signal. Skip a layer and the protection is incomplete.

The same sequencing logic applies to any certificate hierarchy, any code-signing chain, any trust infrastructure where a parent vouches for a child. I keep arguing that PQC migration is the largest and most complex infrastructure program most organizations will face, and DNSSEC is a good illustration of why. The coordination across independent organizations – each with its own software, its own upgrade cycles, its own incentives – is the hard part. The cryptography has been solved since FIPS 204 shipped.

The Bottom Line

Cloudflare’s move is good engineering. Enabling ML-DSA-44 validation on 1.1.1.1 gives the entire DNS community operational data on transport overhead, verification cost, and TCP fallback rates.

But resolver support is one link. The chain of trust that makes DNSSEC work runs from root to leaf, and today only the bottom link is post-quantum ready. The root zone, the TLD registries, the registrars, and most authoritative DNS software have not adopted ML-DSA-44. Until they do, “post-quantum DNSSEC” describes a capability, not a protection.

Every protocol that relies on digital signatures will face its own version of this: new sizes that break old transport, coexistence periods that create downgrade paths, and trust chains that must migrate end to end. DNSSEC is the protocol that made all three visible in a single announcement.

The post appeared first on PostQuantum - Quantum Computing, Quantum Security, PQC.