1.1.1.1 现已支持后量子 DNSSEC：2,420 字节的签名

1.1.1.1 现在已验证DNSSEC签名ML-DSA-44，一种由美国国家标准与技术研究院（NIST）.这是为DNSSEC准备应对当今签名算法不再安全的未来迈出的第一步。

Cloudflare 计划实现2029年前实现全面的后量子安全.迄今为止，大部分工作集中在TLS，但公钥密码学也被许多其他系统使用，包括DNSSEC。

当我们开始时2019年在TLS中实验后量子密钥一致性并且在2022年支持所有客户，但后量子签名尚未在DNSSEC中获得类似测试。同时也存在一定的紧迫性。后量子TLS的广泛客户端采纳花费了数年时间，部分原因是更大的信息暴露了现有网络软件中的假设和漏洞。这次经历说明了早期大规模测试的重要性。我们迫不及待地看到量子计算机成为直接威胁。

问题在于后量子签名非常庞大。每个ML-DSA-44签名为2420字节，超过了常见的DNS-。UDP在响应包含其他内容之前，先先有限制。与此同时，区域需要为旧解析器发布传统签名多年，如果验证不当，可能会出现降级路径。挑战在于如何可靠地承载这些更大规模的响应，同时不允许与旧解析器的兼容性削弱对新解析器的保护。

启用ML-DSA-44验证后，1.1.1.1让我们能够在互联网规模上测试这两个挑战：承载更大规模的DNS响应，并防止回归传统签名。

为什么后量子DNSSEC如此重要

DNS 响应默认不经过认证。能够伪造响应的攻击者可能能够将用户重定向到他们选择的地址。DNSSEC 通过签署 DNS 记录来防止这一点。

像 1.1.1.1.1 这样的验证解析器会沿着从 DNS 根节点到请求域名的签名记录链，检查答案是否真实且未被修改。

DNSSEC支持多种签名算法，但目前几乎所有签名算法都容易被未来的量子计算机利用。RSA与ECDSA依赖于被认为在部署密钥大小下传统计算机无法解决的数学问题。

我们正在为2030年可能制造出足够强大的量子计算机来破解这些密钥做准备。攻击者随后可以恢复相应的私钥，并创建验证者接受的伪造签名。

攻击路径如下所示。

目前尚不存在能够执行这些攻击的量子计算机。DNSSEC提供的是真实性而非机密性，因此不会遭受“先采集，后解密”的攻击。现在开始的原因是，改变DNSSEC需要权威服务器、注册机构、注册商和验证解析器之间的协调。

迁移最终必须达到DNS层级的顶端，而被攻破的密钥影响最大。利用量子计算机恢复根区签名密钥的攻击者可以伪造一条验证路径，指向其下方的任何区域：“一旦破坏，处处伪造”。

ML-DSA-44为该迁移提供了标准化的起点，支持1.1.1.1使我们和整个DNS生态系统都能获得操作经验。

为什么替换算法如此困难

DNSSEC旨在支持新算法。原则上，支持ML-DSA-44意味着公开其公钥并教验证者验证其签名。实际上，有两个特性使过渡变得困难：签名体积庞大，旧算法无法总是安全移除。

2,420字节签名会改变数据包

如今常用的DNSSEC算法产生的签名相对较小。ECDSA P-256例如，产生64字节签名。ML-DSA-44签名为2420字节，几乎是其大38倍。

这一差异很重要，因为许多发送、携带和接收 DNS 消息的系统对消息大小非常敏感。DNS 最初通过UDP发送的限制消息为512字节.EDNS（0）后来允许解析器广播其愿意接受的最大UDP响应。

许多DNS实现使用保守的UDP有效载荷限制为1,232字节选择以适应IPv6最小MTU（最大传输单元）为1,280字节.最近，RFC 9715建议 DNS over UDP 最大为 1,400 字节。

ML-DSA-44 签名本身就超出预算，还未考虑已签名的 RRset、域名、DNS 头部及其他 DNSSEC 记录。发送此类响应如分片 UDP 是不可靠，应避免.相反，权威服务器应返回截断响应，提示解析器使用其他传输协议（通常是TCP）重试。

这种影响在DNSKEY响应中最为明显，响应包含解析器验证区域所需的密钥。ML-DSA-44的公钥为1,312字节，DNSKEY RRset还携带2,420字节签名。ML-DSA-44在DNS生态系统中广泛支持之前，无法完全取代传统签名算法，这一过程可能需要数年时间。在此之前，DNSKEY响应可能同时包含传统和后量子密钥和签名，以保持与较旧验证器的兼容性。密钥滚动转移还可能增加更多密钥，使响应再次变大。

通过非UDP传输处理DNS本身并不罕见。Cloudflare 雷达显示约85%的1.1.1.1查询通过UDP到达。1.1.1.1背后的平台，大菠萝也支持其他DNS服务，包括网关DNS.在Big Pineapple处理的所有服务中，约60%的查询通过UDP到达。

其余40%使用TCP、DNS over TLS（DoT）和DNS over HTTPS（DoH）等传输方式。

这些数据描述的是查询如何到达Cloudflare的解析器服务，而非1.1.1.1如何与权威服务器通信。大型ML-DSA-44响应仍可能导致该端额外的TCP重试，但通过UDP以外的传输处理DNS已是1.1.1.1大规模运行的正常部分。

支持两个算法会带来降级风险

无法一次性全部替换现有的DNSSEC算法。如果一个区域只发布ML-DSA-44，不支持该区域的解析器无法验证该区域。因此，实际迁移路径是将传统密钥和后量子密钥及签名一起发布。

这保持了兼容性，但本身并不能提供后量子安全。RFC 6840规定“验证者应接受任何单一有效路径”。该规则允许验证者使用他们支持的已发布算法。

然而，一旦传统算法如ECDSA不再安全，同样的行为就会产生降级路径。攻击者可能会伪造一个仅支持ECDSA的答案，尽管解析器支持ML-DSA-44，但该答案仍接受，如下图所示。

防止降级需要通过ML-DSA-44验证该区域的认证信号。1.1.1.1使用父区域发布的DS记录。如果认证DS RRset包含支持的后量子算法记录，则该信号存在。

1.1.1.1 然后故意应用 a限制性局部验证策略。它要求至少一条有效的量子后验证路径;常规路径已不再足够。如果没有ML-DSA-44路径验证，验证失败。

这（目前）还不是正常的DNSSEC验证行为，但RFC 4035 允许本地解析器策略以确定是否需要检查额外的签名，以及如何处理冲突的结果。

传统签名可以保留给老式解析器，而不允许具备后量子能力的解析器回退到它们。只有当ML-DSA-44部署和降级保护从信任锚点延伸到每个委派时，降级信号才是后量子安全的。

更频繁地轮换区域密钥并不能解决问题：攻击者可以针对链中更高级别的易受攻击密钥，并伪造其下方的每个委派。

通往后量子DNSSEC的道路

向DNSSEC添加后量子算法不仅仅需要标准化密码学。它需要在密码库中实现，获得IANA分配的DNSSEC算法编号，获得权威服务器和验证解析器的支持，并在DNS委派链中广泛采用。

ML-DSA-44现已具备部署的初始前提条件。NIST已将其标准化，通用密码库也实现了它。其在DNSSEC中的应用描述如下DNSSEC 互联网草案的 ML-DSAIANA最近也分配了它DNSSEC 算法编号 18.

在解析器中添加ML-DSA-44验证是部署的首要步骤之一，但这并未建立完整的量子后信任链。权威服务器必须用ML-DSA-44签署区域，注册商必须接受并提交相应的DS记录，注册机构必须在父区域发布这些记录。

这种采用必须贯穿每个父区域，直达DNS根。根节点必须采用ML-DSA-44，其后量子密钥必须成为验证解析器的信任锚点。任何没有后量子保护的层级仍然是降级点。

如果没有解析器验证ML-DSA-44的签名，签署区域的价值很小。因此，默认启用ML-DSA-44验证是重要的早期步骤。这使我们能够衡量签名验证的运营成本、额外带宽以及解析器与权威服务器之间TCP使用增加。

与以往迁移一样，我们还将利用背景探针测试在Cloudflare 挑战页面.这些探测将测试客户端是否能够在真实网络中解析并访问ML-DSA-44签名的测试域。

我们邀请其他DNS运营商和实现者开始大规模测试ML-DSA-44。这些测量将共同展示随着采用率增长需要做出哪些调整。

这对你意味着什么

如果你使用 1.1.1.1，则无需更改任何内容。ML-DSA-44 验证在区域发布必要的 DNSSEC 记录时自动进行，而现有 DNSSEC 区域则继续照旧进行验证。

这项工作涵盖了DNS的解析器部分。我们的下一步是为 增加ML-DSA-44签名支持Cloudflare 权威 DNS以及对应的DS记录支持Cloudflare 注册商该系统将免费向所有客户开放。这将使我们能够测试完整的路径，从生成签名、发布DNSKEY记录，到通过1.1.1.1传输和验证这些记录。

想看看后量子DNSSEC的实际应用......全部2420字节？查询我们的dnstest.dev区域使用 1.1.1.1：

你也可以使用你的DNS解析器后量子化准备就绪了吗？测试您当前的解析器。社区正在跟踪ML-DSA-44软件支持在GitHub上.