Quantum Computing

Cloudflare Supports Post-Quantum DNSSEC Signature Verification on 1.1.1.1

Cloudflare enabled verification of DNSSEC signatures using the NIST-standardized ML-DSA-44 algorithm on its 1.1.1.1 resolver, in a step to test the impact of large signatures and the risks of falling back to weaker traditional algorithms. The update does not yet represent a complete post-quantum chain of trust, as that requires adoption of the algorithm across DNS servers, records, and delegations all the way to the root.

2026-09-10
4 min read
10 views
فريق تحرير certi.news
Cloudflare Supports Post-Quantum DNSSEC Signature Verification on 1.1.1.1

Cloudflare enabled verification of DNSSEC signatures using the ML-DSA-44 algorithm on the public DNS resolver 1.1.1.1, in a step aimed at testing the readiness of the domain name system for a stage in which current signature algorithms could become breakable by powerful quantum computers. The company says this step is the beginning of a longer transition, not a complete implementation of post-quantum DNSSEC security.

The National Institute of Standards and Technology (NIST) in the United States published the ML-DSA-44 algorithm among its standardized algorithms, and the algorithm received number 18 for DNSSEC algorithms from IANA. Cloudflare plans to achieve full post-quantum security by 2029, after much of its previous work focused on key agreements in TLS.

One Signature Larger Than a Typical DNS Packet

The most prominent practical obstacle is the signature’s size. An ML-DSA-44 signature is 2,420 bytes, compared with 64 bytes for an ECDSA P-256 signature, while its public key is 1,312 bytes. As a result, the signature alone exceeds common limits for DNS responses over UDP, before adding records, domain names, protocol headers, and the rest of the DNSSEC records.

DNS implementations often use a conservative limit of 1,232 bytes for UDP packets, a limit associated with the minimum IPv6 maximum transmission unit. When the packet is insufficient, the authoritative server should return a truncated response that prompts the resolver to retry over another protocol, usually TCP, rather than relying on unreliable UDP fragmentation. The issue is especially apparent in DNSKEY responses carrying the keys needed to validate the zone, and it could become greater when traditional and post-quantum keys are published together or during key rotation.

Preventing Fallback to Traditional Signatures

Traditional algorithms cannot be stopped immediately, because older resolvers will not be able to validate a zone that publishes only ML-DSA-44. But keeping both paths together could open a downgrade path: once a traditional algorithm such as ECDSA becomes quantum-unsafe, an attacker could forge a response relying on it even though the resolver is capable of using ML-DSA-44.

To address this, 1.1.1.1 relies on DS records published in the parent zone. If the authenticated DS set contains a record for a supported post-quantum algorithm, Cloudflare enforces a stricter local validation policy, requiring a valid validation path using ML-DSA-44; the traditional path alone is not sufficient. The company explains that this is not yet the standard DNSSEC validation mechanism, but that it is based on the local policy capabilities provided by RFC 4035.

What Changes in Practice?

For 1.1.1.1 users, no changes are required; validation occurs automatically when the zone publishes the required DNSSEC records, while existing zones continue to work as usual. Cloudflare says that approximately 85% of queries to 1.1.1.1 arrive over UDP, making the measurement of larger responses and retries over TCP an important part of the operational test.

However, enabling validation on the resolver does not create a complete post-quantum chain of trust. Authoritative servers must support signing zones, registrars must accept the appropriate DS records, and registries must publish them in parent zones, all the way to the DNS root. Any level that lacks post-quantum protection remains a potential downgrade point.

certi.news’s Reading

The core value of this announcement is not adding an option for the end user, but moving ML-DSA-44 from a cryptographic standard into a large-scale operational test. The problem Cloudflare reveals is twofold: transporting messages far larger than usual and maintaining strict validation while legacy algorithms remain in use for years. The open questions remain tied to how quickly the algorithm is adopted across the entire DNS chain, and to measuring bandwidth costs and increased TCP use. Cloudflare later intends to add ML-DSA-44 signing support to Cloudflare Authoritative DNS and support for DS records in Cloudflare Registrar free of charge for its customers, which will allow the full path to be tested.

News source
Cloudflare Blog
Open original source ↗
ف
Author

فريق تحرير certi.news

In the same category

You may also like

View all news