Key Takeaways
- Cloudflare’s 1.1.1.1 is the first public resolver to validate ML-DSA-44 post-quantum DNSSEC signatures, signaling the start of a 2029 hardening timeline.
- A single ML-DSA-44 signature is 2,420 bytes versus 64 bytes for ECDSA P-256, blowing past the 1,400-byte EDNS budget and forcing UDP truncation with TCP retries.
- Resolver policy must block downgrade attacks by requiring at least one valid ML-DSA-44 path whenever a post-quantum algorithm appears in the parent DS record set.
Table of Contents
The Quantum-Scale DNS Performance Breakpoint Arrives Early
Cloudflare reports that its public resolver 1.1.1.1 now validates DNSSEC signatures generated with ML-DSA-44, the post-quantum algorithm standardized by the National Institute of Standards and Technology.
That single operational change places a 2,420-byte signature in the middle of live DNS resolution.
It also forces performance teams to confront a transport and verification challenge before quantum computers become an active attack tool.
According to Cloudflare, the rollout is framed as a first step toward full post-quantum security by 2029.
Inside the 2,420-Byte Signature Problem
DNSSEC prevents response forgery by requiring resolvers to validate a chain of signed records from the DNS root to the requested domain.
Nearly all deployed DNSSEC signatures today use RSA or ECDSA, both of which are vulnerable to future quantum computation.
Quantum computers capable of breaking deployed RSA or ECDSA keys do not exist today.
The urgency comes from the long migration timeline, not an immediate attack.
ML-DSA-44 gives that migration a standardized starting point, but it immediately changes packet sizing.
An ECDSA P-256 signature consumes 64 bytes.
An ML-DSA-44 signature consumes 2,420 bytes.
The public key is also larger: 1,312 bytes for ML-DSA-44 versus 64 bytes for ECDSA P-256.
- RSA-2048/SHA-256: 260-byte public key, 256-byte signature.
- ECDSA P-256: 64-byte public key, 64-byte signature.
- ML-DSA-44: 1,312-byte public key, 2,420-byte signature.
DNS over UDP was originally restricted to 512 bytes, and even modern EDNS guidance such as RFC 9715 recommends a maximum of 1,400 bytes.
A single ML-DSA-44 signature exceeds that budget before the DNS response includes headers, names, or additional DNSSEC records.
Authoritative servers must therefore truncate oversized UDP responses, forcing resolvers to retry over TCP.
Operators can reproduce the behavior with a DNSSEC query to valid.mldsa44.dnstest.dev through 1.1.1.1.
The resolver flags a truncated UDP reply, retries over TCP, and returns a 2,563-byte response.
ML-DSA-44 has the minimum prerequisites for deployment: NIST standardization, cryptographic library support, IANA-assigned algorithm number 18, and a draft specification.
A complete post-quantum chain of trust still requires signing support at authoritative servers, registrars, registries, and the DNS root.
Downgrade Defenses and the TCP Fallback Reality
Publishing post-quantum signatures alongside conventional algorithms keeps older resolvers compatible, but it creates a downgrade risk.
RFC 6840 says validators should accept any single valid path, which means an attacker could forge an ECDSA-only answer even when a resolver supports ML-DSA-44.
To prevent that, 1.1.1.1 uses authenticated DS records from the parent zone as a signal.
When a supported post-quantum algorithm appears in the DS RRset, the resolver applies a stricter local policy and requires at least one valid ML-DSA-44 path.
If no ML-DSA-44 path validates, the resolver treats the response as validation failure.
This is not standard DNSSEC behavior yet, but RFC 4035 allows local resolver policy to demand additional signature checks.
An attacker who recovers a root zone signing key with a quantum computer could forge a validation path to any zone below it.
Break once, forge everywhere.
Resolver-level telemetry shows about 85 percent of queries to 1.1.1.1 arrive over UDP.
Across all services on the same resolver platform, roughly 60 percent of queries use UDP, with the rest already using TCP, DNS over TLS, or DNS over HTTPS.
Handling non-UDP transports is therefore a normal part of resolver operations, but each ML-DSA-44-triggered TCP retry still adds state, bandwidth, and CPU cost.
The performance challenge is not just moving bytes; it is keeping the fallback path reliable while preventing compatibility with older resolvers from weakening protection for newer ones.
What Post-Quantum DNSSEC Means for Performance Stacks
For performance engineers, this rollout turns a cryptographic migration into a measurable network stack problem.
Every extra 2,356 bytes of signature overhead pushes DNS responses past common UDP limits, producing more truncation events and more TCP handshakes.
That does not break resolvers, but it changes tail latency in ways that standard DNS benchmarks often miss.
The next phase targets signing support in Cloudflare Authoritative DNS and DS record support in Cloudflare Registrar, which will widen the test across the full resolution path.
Performance teams should watch three variables: UDP payload limits, TCP retry frequency, and the CPU cost of ML-DSA-44 signature verification.
- UDP payload limits: Keep EDNS buffer sizes aligned with current RFC guidance to avoid fragmentation.
- TCP retry frequency: Track truncation-triggered fallback as a tail latency indicator.
- Verification cost: Measure resolver CPU impact as post-quantum chains expand.
The 2029 target for full post-quantum security is not far away in infrastructure terms.
Zones that wait until quantum threats are imminent will face a bigger performance problem because migration requires coordination across resolvers, registrars, registries, and authoritative servers.
The 2029 Hardening Clock Has Started
Post-quantum DNSSEC has moved from specification debate into production resolver traffic, and the performance data from this shift will shape how the rest of the internet hardens. For teams optimizing DNS-dependent web performance, WordPress speed engineering is how Andres SEO Expert approaches network-critical speed — contact the team.
Frequently Asked Questions
What is post-quantum DNSSEC?
Post-quantum DNSSEC uses quantum-resistant digital signatures, such as ML-DSA-44, to protect DNS records from future quantum computers. Cloudflare’s 1.1.1.1 resolver now validates ML-DSA-44 signatures as a first step toward full post-quantum security by 2029.
Why is a 2,420-byte ML-DSA-44 signature a problem for DNS?
DNS over UDP traditionally fits within small payload limits, and RFC 9715 recommends a maximum of 1,400 bytes. An ML-DSA-44 signature alone is 2,420 bytes, so a signed response cannot fit in one UDP packet and must be truncated or retried over TCP.
What happens when a DNSSEC response is too large for UDP?
Authoritative servers truncate oversized UDP responses. The resolver then retries over TCP. In the Cloudflare test, a DNSSEC query to valid.mldsa44.dnstest.dev through 1.1.1.1 returned a truncated UDP reply, a TCP retry, and a 2,563-byte response.
What is the DNSSEC downgrade risk with post-quantum signatures?
Publishing post-quantum and conventional signatures together keeps older resolvers working, but RFC 6840 lets validators accept any single valid path. An attacker could forge an ECDSA-only answer even when the resolver supports ML-DSA-44, so resolvers need stricter local policy.
How does 1.1.1.1 defend against post-quantum DNSSEC downgrade attacks?
1.1.1.1 uses authenticated DS records from the parent zone. If a supported post-quantum algorithm appears in the DS RRset, the resolver requires at least one valid ML-DSA-44 path. If none validates, the response is treated as a validation failure.
What should performance teams monitor during post-quantum DNSSEC migration?
Teams should track UDP payload limits, TCP retry frequency, and CPU cost of ML-DSA-44 signature verification. Each ML-DSA-44-triggered TCP retry adds state, bandwidth, and CPU overhead, which can affect tail latency.
Why does 2029 matter for post-quantum DNSSEC?
Cloudflare frames its ML-DSA-44 validation as a first step toward full post-quantum security by 2029. Because migration requires coordination across resolvers, registrars, registries, and authoritative servers, waiting until quantum threats are imminent can create a larger performance and compatibility problem.
