Cloudflare's 1.1.1.1 Resolver Enables Post-Quantum DNSSEC Validation with ML-DSA-44

Cloudflare's 1.1.1.1 Resolver Enables Post-Quantum DNSSEC Validation with ML-DSA-44 Cloudflare has enabled validation for DNSSEC signatures created with ML-DSA-44 on its 1.1.1.1 resolver, beginning real-world testing of post-quantum cryptography to prepare DNS infrastructure before quantum computers can break RSA and ECDSA keys. ML-DSA-44 produces 2,420-byte signatures and 1,312-byte public keys, substantially exceeding typical DNS-over-UDP payload limits and triggering TCP retries. To prevent downgrade attacks while zones dual-sign with legacy algorithms, 1.1.1.1 enforces a local policy requiring ML-DSA-44 validation when indicated by parent DS records. Complete post-quantum security requires end-to-end adoption across the entire DNS hierarchy up to the root zone to eliminate vulnerable downgrade points. Cloudflare plans to introduce free ML-DSA-44 signing support in Cloudflare Authoritative DNS and DS record support in Cloudflare Registrar. Message Size and Transport Challenges Unlike conventional ECDSA P-256 signatures that occupy 64 bytes, ML-DSA-44 signatures require 2,420 bytes and public keys take 1,312 bytes. This size exceeds standard DNS-over-UDP payload limits, such as the common 1,232-byte IPv6 MTU threshold and RFC 9715's 1,400-byte recommendation, before even accounting for headers and record sets. Because sending fragmented UDP responses is unreliable, authoritative servers must return truncated responses to force resolvers to retry over transports like TCP. While roughly 85% of queries to 1.1.1.1 currently arrive over UDP, Cloudflare already handles alternative transports routinely across its infrastructure. Dual Signing and Downgrade Prevention Because non-upgraded resolvers cannot validate ML-DSA-44, zones must publish conventional and post-quantum keys simultaneously for years. Under standard RFC 6840 rules, validators accept any single valid path, which creates a downgrade vulnerability if an attacker can forge a compromised legacy algorithm like ECDSA. To prevent this, 1.1.1.1 checks parent-zone DS records for post-quantum algorithms and enforces a restrictive local validation policy: if an ML-DSA-44 DS record is present, the resolver mandates a valid ML-DSA-44 path and treats conventional paths as insufficient. Ecosystem Adoption and Next Steps Achieving genuine post-quantum resilience requires adoption throughout the entire delegation hierarchy. If any parent zone up to the DNS root remains unmigrated, an attacker with a quantum computer could recover a legacy signing key and forge delegations beneath it. Enabling validation on 1.1.1.1 allows Cloudflare to measure the real-world operational costs of verification, bandwidth, and TCP overhead, while testing client reachability via background probes on Cloudflare Challenge Pages. Cloudflare's next step is implementing ML-DSA-44 signing on Cloudflare Authoritative DNS and DS management in Cloudflare Registrar.

Cloudflare 1.1.1.1 解析器上线支持后量子签名算法 ML-DSA-44 Cloudflare 宣布其公共 DNS 解析器 1.1.1.1 现已默认支持 ML-DSA-44 算法的 DNSSEC 签名验证。作为 2029 年全面后量子安全路线图的一部分，此举旨在提前应对未来量子计算对 RSA 和 ECDSA 等传统公钥算法的威胁，并在互联网规模下测试大报文传输与防降级机制。 ML-DSA-44 单个签名长达 2,420 字节（公钥 1,312 字节），远超常规 UDP 负载限制，迫使更多 DNS 查询回退至 TCP 传输。 为防止攻击者伪造弱算法响应发起降级攻击，1.1.1.1 采用更严格的本地策略：父区域 DS 记录声明支持后量子算法时，必须通过 ML-DSA-44 验证。 DNSSEC 迁移需要递归解析器、权威服务器、注册商、注册局乃至根域名全链条协同推进，下一阶段 Cloudflare 将支持权威 DNS 签名与注册商 DS 记录。 后量子签名的大报文挑战 传统 ECDSA P-256 签名仅需 64 字节，而 NIST 标准化的 ML-DSA-44 签名达 2,420 字节，是前者的近 38 倍。由于 DNS over UDP 常用负载限制通常为 1,232 字节或推荐的 1,400 字节，单独一个 ML-DSA-44 签名就已超出预算。权威服务器遇到超大响应时需返回截断响应，促使解析器改用 TCP。此外，过渡期内 DNSKEY 响应需同时包含传统与后量子密钥及签名，进一步放大了报文尺寸与传输开销。 防降级攻击的本地验证策略 DNSSEC 在过渡期需同时发布传统和后量子签名以保证兼容性，但标准规则允许解析器接受任意一条有效路径，这可能导致攻击者伪造传统 ECDSA 路径实施降级。针对该问题，1.1.1.1 利用父区域发布的 DS 记录作为认证信号：一旦检测到后量子算法记录，解析器即强制要求至少存在一条有效的 ML-DSA-44 验证路径，否则拒绝解析，从而切断回退攻击路径。 全链路推进与后续计划 仅在解析器端启用验证无法完成端到端的后量子信任链。抗量子保护必须从根域名信任锚点逐级延伸到各级委派。Cloudflare 表示，下一步将向所有客户免费开放 Cloudflare Authoritative DNS 的 ML-DSA-44 签名支持及 Cloudflare Registrar 的 DS 记录支持，并在部分 Challenge 页面发起小规模探测，全面评估网络环境下的部署表现。

1.1.1.1 now validates [DNSSEC](https://www.cloudflare.com/learning/dns/dnssec/how-dnssec-works/) signatures made with [ML-DSA-44](https://blog.cloudflare.com/ml-dsa-will-have-to-do/), a post-quantum signature algorithm standardized by the [National Institute of Standards and Technology (NIST)](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards). This is a first step toward preparing DNSSEC for a future in which today’s signature algorithms are no longer secure. Cloudflare plans to achieve [full post-quantum security by 2029](https://blog.cloudflare.com/post-quantum-roadmap/). Much of the work so far has focused on TLS, but public-key cryptography is used in many other systems, including DNSSEC. While we began [experimenting with post-quantum key agreement in TLS in 2019](https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/) and enabled support for all customers in 2022, post-quantum signatures have not yet received comparable testing in DNSSEC. There is also some urgency. Widespread client adoption of post-quantum TLS took years, partly because larger messages exposed assumptions and bugs in existing network software. That experience showed why early large-scale testing matters. We cannot wait until quantum computers become an immediate threat. The problem is that post-quantum signatures are large. Each ML-DSA-44 signature is 2,420 bytes, exceeding common DNS-over-[UDP](https://www.cloudflare.com/learning/ddos/glossary/user-datagram-protocol-udp/) limits before the response includes anything else. At the same time, zones will need to publish conventional signatures for older resolvers for years, creating a potential downgrade path if not validated correctly. The challenge is carrying these much larger responses reliably, without allowing compatibility with older resolvers to weaken protection for newer ones. With ML-DSA-44 validation enabled, 1.1.1.1 lets us test both challenges at Internet scale: carrying larger DNS responses and preventing fallback to conventional signatures. DNS responses are not authenticated by default. An attacker who can forge a response may be able to redirect users to an address of their choosing. DNSSEC prevents this by signing DNS records. A validating resolver such as 1.1.1.1 follows a chain of signed records from the DNS root to the requested domain, checking that the answer is authentic and has not been modified. DNSSEC supports multiple signature algorithms, but nearly all of those used today are vulnerable to future quantum computers. [RSA and ECDSA](https://blog.cloudflare.com/the-quantum-menace/) rely on mathematical problems that are believed to be infeasible for conventional computers to solve at deployed key sizes. We are preparing for the possibility that in 2030 a sufficiently powerful quantum computer could be built that breaks these keys. An attacker could then recover the corresponding private key and create forged signatures that validators would accept. The attack path is shown below. Quantum computers capable of carrying out these attacks do not exist today. DNSSEC provides authenticity rather than confidentiality, so it is not subject to “harvest now, decrypt later” attacks. The reason to begin now is that changing DNSSEC requires coordination across authoritative servers, registries, registrars, and validating resolvers. The migration must eventually reach the top of the DNS hierarchy, where a compromised key has the greatest impact. An attacker who recovers a root zone signing key using a quantum computer could forge a validation path to any zone below it: “break once, forge everywhere”. ML-DSA-44 gives that migration a standardized starting point, and supporting it in 1.1.1.1 lets us, and the DNS ecosystem at large, gain operational experience. DNSSEC was designed to support new algorithms. In principle, supporting ML-DSA-44 means publishing its public key and teaching validators to verify its signatures. In practice, two properties make the transition difficult: the signatures are large, and the old algorithm cannot always be removed safely. DNSSEC algorithms commonly used today produce relatively small signatures. [ECDSA P-256](https://www.cloudflare.com/learning/dns/dnssec/ecdsa-and-dnssec/), for example, produces a 64-byte signature. An ML-DSA-44 signature is 2,420 bytes, almost 38 times larger. | **Algorithm** | **Number** | **Public key size** | **Signature size** | | RSA-2048/SHA-256 | 8 | 260 bytes | 256 bytes | | ECDSA P-256 | 13 | 64 bytes | 64 bytes | | ML-DSA-44 | 18 | 1,312 bytes | 2,420 bytes | That difference matters because many of the systems that send, carry, and receive DNS messages are sensitive to message size. DNS originally [restricted messages sent over UDP to 512 bytes](https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.4). [EDNS(0)](https://datatracker.ietf.org/doc/html/rfc6891) later allowed a resolver to advertise the largest UDP response it is willing to accept from a nameserver. Many DNS implementations use a [conservative UDP payload limit of 1,232 bytes](https://datatracker.ietf.org/doc/html/rfc9715#appendix-A-2.3.1), chosen to fit within IPv6’s [minimum MTU (maximum transmission unit) of 1,280 bytes](https://datatracker.ietf.org/doc/html/rfc8200#section-5). More recently, [RFC 9715](https://datatracker.ietf.org/doc/html/rfc9715#section-3.2) recommended a maximum of 1,400 bytes for DNS over UDP. An ML-DSA-44 signature exceeds that budget on its own, before accounting for the signed RRset, domain names, DNS headers, and other DNSSEC records. Sending such a response as fragmented UDP is [unreliable and should be avoided](https://blog.cloudflare.com/dns-flag-day-2020/#dns-message-fragmentation). Instead, the authoritative server should return a truncated response, prompting the resolver to retry using another transport protocol, usually TCP. The effect is most visible in DNSKEY responses, which contain the keys a resolver needs to validate the zone. An ML-DSA-44 public key is 1,312 bytes, and the DNSKEY RRset also carries a 2,420-byte signature. ML-DSA-44 cannot fully replace conventional signing algorithms until it is widely supported across the DNS ecosystem, a process likely to take years. Until then, DNSKEY responses may contain both conventional and post-quantum keys and signatures to remain compatible with older validators. Key rollovers can add still more keys, making these responses larger again. Handling DNS over transports other than UDP is not itself unusual. [Cloudflare Radar](https://radar.cloudflare.com/dns#dns-transport-protocol) shows that around 85% of queries to 1.1.1.1 arrive over UDP. The platform behind 1.1.1.1, [Big Pineapple](https://blog.cloudflare.com/big-pineapple-intro/), also powers other DNS services, including [Gateway DNS](https://www.cloudflare.com/products/gateway/). Across all services handled by Big Pineapple, around 60% of queries arrive over UDP. The remaining 40% use transports such as TCP, DNS over TLS (DoT), and DNS over HTTPS (DoH). Those figures describe how queries reach Cloudflare’s resolver services, not how 1.1.1.1 communicates with authoritative servers. Large ML-DSA-44 responses can still cause additional TCP retries on that side, but handling DNS over transports other than UDP is already a normal part of operating 1.1.1.1 at scale. Replacing an existing DNSSEC algorithm cannot happen all at once. If a zone publishes only ML-DSA-44, resolvers that do not support it cannot validate the zone. The practical migration path is therefore to publish conventional and post-quantum keys and signatures together. That preserves compatibility, but it does not provide post-quantum security by itself. [RFC 6840](https://datatracker.ietf.org/doc/html/rfc6840#section-5.11) specifies that “validators SHOULD accept any single valid path.” This rule lets validators use whichever published algorithm they support. Once a conventional algorithm such as ECDSA is no longer secure, however, the same behavior creates a downgrade path. An attacker could forge an ECDSA-only answer that a resolver accepts despite supporting ML-DSA-44, as illustrated below. Preventing this downgrade requires an authenticated signal that a zone should be validated with ML-DSA-44. 1.1.1.1 uses DS records published by the parent zone for this purpose. If the authenticated DS RRset contains a record for a supported post-quantum algorithm, the signal is present. 1.1.1.1 then deliberately applies a more [restrictive](https://datatracker.ietf.org/doc/html/draft-westerbaan-dnssec-mldsa-04#name-downgrades) local validation policy. It requires at least one valid post-quantum validation path; a conventional path is no longer sufficient. If no ML-DSA-44 path validates, validation fails. This is not (yet) normal DNSSEC validation behavior, but [RFC 4035 allows local resolver policy](https://datatracker.ietf.org/doc/html/rfc4035#section-5.3.3) to determine whether additional signatures must be checked and how conflicting results are handled. Conventional signatures can remain available for older resolvers without allowing post-quantum-capable resolvers to fall back to them. The downgrade signal is only post-quantum secure if ML-DSA-44 deployment and downgrade protection extend from the trust anchor through every delegation. Rotating the zone key more frequently does not solve the problem: an attacker can target a vulnerable key anywhere higher in the chain and forge every delegation below it. Adding a post-quantum algorithm to DNSSEC requires more than standardizing the cryptography. It needs implementations in cryptographic libraries, an IANA-assigned DNSSEC algorithm number, support from authoritative servers and validating resolvers, and adoption throughout the DNS delegation chain. ML-DSA-44 now has the initial prerequisites for deployment. NIST has standardized it, and common cryptographic libraries implement it. Its use in DNSSEC is described in the [ML-DSA for DNSSEC Internet-Draft](https://datatracker.ietf.org/doc/draft-westerbaan-dnssec-mldsa/), and IANA recently assigned it [DNSSEC algorithm number 18](https://www.iana.org/assignments/dns-sec-alg-numbers#dns-sec-alg-numbers-1). Adding ML-DSA-44 validation to resolvers is one of the first deployment steps, but it does not create a complete post-quantum chain of trust. Authoritative servers must sign zones with ML-DSA-44, registrars must accept and submit the corresponding DS records, and registries must publish them in parent zones. This adoption must extend through every parent zone to the DNS root. The root must adopt ML-DSA-44, and its post-quantum key must become a trust anchor for validating resolvers. Any level without post-quantum protection remains a downgrade point. There is little value in signing a zone with ML-DSA-44 if no resolver validates its signatures. Enabling ML-DSA-44 validation by default on 1.1.1.1 is therefore an important early step. It lets us measure the operational cost of signature verification, additional bandwidth, and increased TCP use between resolvers and authoritative servers. As with previous migrations, we will also test real-world deployability using background probes on a small fraction of [Cloudflare Challenge Pages](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/). These probes will test whether clients can resolve and reach an ML-DSA-44-signed test domain across real networks. We invite other DNS operators and implementers to begin testing ML-DSA-44 at scale. Together, these measurements will show what adjustments are needed as adoption grows. If you use 1.1.1.1, you do not need to change anything. ML-DSA-44 validation happens automatically when a zone publishes the necessary DNSSEC records, while existing DNSSEC zones continue to validate as before. This work covers the resolver side of DNS. Our next step is adding ML-DSA-44 signing support to [Cloudflare Authoritative DNS](https://www.cloudflare.com/products/dns/) and corresponding DS record support to [Cloudflare Registrar](https://domains.cloudflare.com/), which will be available to all customers for free. That will let us test the complete path, from generating signatures and publishing DNSKEY records to transporting and validating them through 1.1.1.1. Want to see post-quantum DNSSEC in action… all 2,420 bytes of it? Query our [dnstest.dev](http://dnstest.dev) zone using 1.1.1.1: You can also use [Is your DNS resolver post-quantum ready?](https://dnstest.dev/post-quantum/) to test your current resolver. The community is tracking ML-DSA-44 software support [on GitHub](https://github.com/paulehoffman/ml-dsa-in-dnssec/).