数字安全观察

1.1.1.1 现已验证使用 ML-DSA-44 生成的 DNSSEC 签名，ML-DSA-44 是美国国家标准与技术研究院（NIST）标准化的后量子签名算法。这是为 DNSSEC 做好准备、迎接当今签名算法不再安全的未来所迈出的第一步。

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

我们于 2019 年开始在 TLS 中试验后量子密钥协商，并于 2022 年为所有客户启用支持，但后量子签名在 DNSSEC 中尚未获得同等规模的测试。这件事也有一定的紧迫性。后量子 TLS 在客户端被广泛采用花了数年时间，部分原因是更大的消息暴露了现有网络软件中的假设和缺陷。这段经历说明了为什么早期大规模测试至关重要。我们不能等到量子计算机成为迫在眉睫的威胁时才行动。

问题在于后量子签名很大。每个 ML-DSA-44 签名有 2,420 字节，在响应还未包含任何其他内容之前，就已超出常见的 DNS-over-UDP 限制。与此同时，各区域将需要在未来数年内为较旧的解析器发布传统签名，如果验证不当，就会形成一条潜在的降级路径。挑战在于可靠地传输这些大得多的响应，同时不让与旧解析器的兼容性削弱对新解析器的保护。

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

后量子 DNSSEC 为何重要

DNS 响应默认不经过身份验证。能够伪造响应的攻击者或许可以将用户重定向到他们选择的地址。DNSSEC 通过对 DNS 记录进行签名来防止这种情况。像 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 签名有 2,420 字节，几乎大了 38 倍。

RSA-2048/SHA-256

260 字节

256 字节

ECDSA P-256

64 字节

64 字节

ML-DSA-44

1,312 字节

2,420 字节

这一差异之所以重要，是因为许多发送、承载和接收 DNS 消息的系统对消息大小很敏感。DNS 最初将通过 UDP 发送的消息限制在 512 字节。EDNS(0) 后来允许解析器声明它愿意从名称服务器接受的最大 UDP 响应。许多 DNS 实现使用 1,232 字节的保守 UDP 载荷限制，这一数值是为了适配 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 字节的签名。在 DNS 生态系统广泛支持 ML-DSA-44 之前，它无法完全取代传统签名算法，而这一过程可能需要数年。在此之前，DNSKEY 响应可能同时包含传统和后量子的密钥与签名，以保持与较旧验证器的兼容性。密钥轮换还可能增加更多密钥，使这些响应再次变大。

通过 UDP 以外的传输方式处理 DNS 本身并不罕见。Cloudflare Radar 显示，发往 1.1.1.1 的查询中约 85% 通过 UDP 到达。支撑 1.1.1.1 的平台 Big Pineapple 也为其他 DNS 服务提供支持，包括 Gateway 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 会有意应用更严格的本地验证策略。它要求至少有一条有效的后量子验证路径；仅有传统路径不再足够。如果没有 ML-DSA-44 路径通过验证，验证就会失败。这（目前）还不是正常的 DNSSEC 验证行为，但 RFC 4035 允许本地解析器策略决定是否必须检查额外签名，以及如何处理相互冲突的结果。

传统签名可以继续为较旧的解析器提供，同时不允许具备后量子能力的解析器回退到它们。只有当 ML-DSA-44 部署和降级保护从信任锚贯穿每一次委派时，降级信号才是后量子安全的。更频繁地轮换区域密钥并不能解决问题：攻击者可以针对链中更高位置的任何易受攻击的密钥，并伪造其下的每一次委派。

通往后量子 DNSSEC 之路

为 DNSSEC 添加后量子算法，不仅仅是将密码学标准化。它需要在密码学库中实现、由 IANA 分配 DNSSEC 算法编号、获得权威服务器和验证解析器的支持，并在整个 DNS 委派链中被采用。ML-DSA-44 现在已具备部署的初步前提条件。NIST 已将其标准化，常见的密码学库也已实现它。其在 DNSSEC 中的使用在 ML-DSA for DNSSEC 互联网草案中有所描述，IANA 最近也为其分配了 DNSSEC 算法编号 18。

在解析器中添加 ML-DSA-44 验证是首批部署步骤之一，但它并不会创建完整的后量子信任链。权威服务器必须使用 ML-DSA-44 对区域进行签名，注册商必须接受并提交相应的 DS 记录，注册局必须将其发布在父区域中。

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

如果没有解析器验证其签名，用 ML-DSA-44 对区域进行签名就几乎没有价值。因此，在 1.1.1.1 上默认启用 ML-DSA-44 验证是重要的早期步骤。它让我们能够衡量签名验证的运营成本、额外带宽，以及解析器与权威服务器之间 TCP 使用量的增加。

与以往的迁移一样，我们还将使用 Cloudflare Challenge Pages 中一小部分上的后台探测来测试真实世界的可部署性。这些探测将测试客户端能否在真实网络中解析并访问一个由 ML-DSA-44 签名的测试域名。我们邀请其他 DNS 运营商和实现者开始大规模测试 ML-DSA-44。这些测量结果将共同表明，随着采用规模扩大，需要进行哪些调整。

这对你意味着什么

如果你使用 1.1.1.1，你无需做任何更改。当一个区域发布必要的 DNSSEC 记录时，ML-DSA-44 验证会自动进行，而现有的 DNSSEC 区域仍像以前一样通过验证。

这项工作涵盖 DNS 的解析器侧。我们的下一步是为 Cloudflare Authoritative DNS 添加 ML-DSA-44 签名支持，并为 Cloudflare Registrar 添加相应的 DS 记录支持，这些将免费提供给所有客户。这将让我们能够测试完整路径，从生成签名和发布 DNSKEY 记录，到通过 1.1.1.1 传输和验证它们。

想看看后量子 DNSSEC 的实际运行……全部 2,420 字节？使用 1.1.1.1 查询我们的 dnstest.dev 区域：

你也可以使用 Is your DNS resolver post-quantum ready? 来测试你当前的解析器。社区正在 GitHub 上跟踪 ML-DSA-44 的软件支持情况。

来源：Cloudflare安全技术；原文日期：2026-09-10。内容经中文翻译改写，请以原文为准。

(责任编辑：数字安全观察)