Cloudflare's 1.1.1.1 Validates ML-DSA-44 DNSSEC, and the Signature Is 2,420 Bytes

Cloudflare's public resolver now validates DNSSEC signatures made with ML-DSA-44, the post-quantum signature algorithm NIST standardized in 2024. It's the first production resolver to do so, and it's a deliberate stress test: the company wants to find the packet-size and downgrade bugs now, not in 2030.

The motivation is coordination, not immediate threat. No quantum computer can break RSA or ECDSA today. But DNSSEC changes require agreement across authoritative servers, registries, registrars, and validating resolvers — and the migration eventually has to reach the root zone, where a single recovered signing key would let an attacker forge a validation path to every zone beneath it. Cloudflare's framing is blunt: break once, forge everywhere.

Why the signature size is the whole story

ECDSA P-256 signs a DNSSEC record in 64 bytes. An ML-DSA-44 signature is 2,420 bytes — roughly 38 times larger. The public key is 1,312 bytes. Neither fits comfortably in a DNS-over-UDP response.

DNS originally capped UDP messages at 512 bytes. EDNS(0) let resolvers advertise larger buffers, and many implementations settled on a conservative 1,232-byte payload to stay inside IPv6's 1,280-byte minimum MTU. RFC 9715 later recommended a 1,400-byte ceiling. A single ML-DSA-44 signature blows past all of those before you add the signed RRset, domain names, headers, or other DNSSEC records.

Fragmented UDP is the wrong answer — Cloudflare has documented it as unreliable. The correct behavior is for the authoritative server to return a truncated response, forcing the resolver to retry over TCP, DoT, or DoH. Cloudflare says about 85% of queries to 1.1.1.1 arrive over UDP, and roughly 60% across all services on its Big Pineapple DNS platform. The rest already use connection-oriented transports, so the retry path isn't exotic — but it will get more traffic.

DNSKEY responses are the worst case. They carry the keys a resolver needs to validate the zone, so during the transition they may hold both conventional and post-quantum keys and signatures. Add a key rollover and the response grows again.

The downgrade problem nobody wants to talk about

Zones can't publish ML-DSA-44 alone; older resolvers would simply fail to validate them. The practical path is to publish both algorithms side by side. That preserves compatibility, but it does not deliver post-quantum security on its own.

RFC 6840 says validators SHOULD accept any single valid path. That rule is what lets a resolver pick whichever algorithm it supports. It is also, once ECDSA is broken, a downgrade vector: an attacker forges an ECDSA-only answer, and a post-quantum-capable resolver accepts it anyway.

Cloudflare's fix is a local policy stricter than the RFC requires. If the authenticated DS RRset from the parent zone contains a supported post-quantum algorithm, 1.1.1.1 requires at least one valid ML-DSA-44 path. A conventional path is no longer sufficient. If no post-quantum path validates, validation fails. RFC 4035 permits resolvers to set local policy on which signatures must be checked, so this is legal — but it is not normal DNSSEC behavior, and it only works if the downgrade signal extends from the trust anchor through every delegation in the chain.

Rotating zone keys more often does not help. An attacker can target a vulnerable key anywhere higher in the hierarchy and forge everything below it.

What this actually proves

Cloudflare's 2029 post-quantum roadmap has mostly been about TLS. DNSSEC is a harder target because the protocol's packet-size assumptions are baked into decades of network software, and because the compatibility story creates a security hole that has to be closed with policy rather than protocol. Running ML-DSA-44 validation at 1.1.1.1 scale is how the ecosystem finds out which resolvers, middleboxes, and authoritative servers break.