摘要

  • 从 2026 年 9 月 10 日起，Cloudflare 的 1.1.1.1 已能为测试区验证 ML-DSA-44。Joe Abley 在 RIPE 93 展示了一个由浏览器发起的 DNSSEC 测试。
  • 在验证型解析器中，双签名路径相对经典算法控制组，中位数多 1 毫秒、p99 多 1,405 毫秒。幻灯片把总体结果称为 6.0% 净故障；这是一轮早期且噪声很大的测试，不能写成全网故障率。

中位数负责安抚，长尾负责叫醒值班员

升级公告最爱印在大字上的数字，往往是中位数：多 1 毫秒，几乎听不见。Joe Abley 在 RIPE 93 展示了另一行数字：p99 多 1,405 毫秒。它落在最慢的那一端——绝大多数请求替平均数撑场面时，少数用户仍在等。

RIPE 93 原始幻灯片中的图，比较验证型解析器上“双签名耗时减去算法 13 控制组”的差值。中位数 +1 毫秒，p90 +147 毫秒，p95 +618 毫秒，p99 +1,405 毫秒。这是浏览器挑战记录的总耗时差，不是单独给密码学验证计时。作为非验证基线，Abley 还比较了经典算法 13 故意签坏的路径与控制组；四个百分位的差值分别为 0、+73、+215 和 +1,132 毫秒。

测试展示给每千名用户中的一名，累计约 14 万个数据点。每次挑战并行发起四个 HTTPS 请求，DNS 名称由 Cloudflare 提供：算法 13 控制组、故意损坏的算法 13 签名、使用算法 18 的 ML-DSA-44 路径，以及同时带有两种签名的名称。第 19 页把验证型解析器的总体结果标为 6.0%“净故障”。Abley 说，约 20 个自治系统出现显著更高的故障，多数被观察到的 AS 则没有差异。报告没有逐条说明每次失败的原因。

新签名可能封死旧签名的退路

这项测试得以开展，是因为 1.1.1.1 从 9 月 10 日起已对所有客户端开放 ML-DSA-44 验证，但使用的是测试区。这是验证能力，不是面向客户开放后量子签名。IANA 的算法注册表把编号 18 列为 ML-DSA-44，签名和验证栏都标为 MAY；编号 13 的 ECDSA P-256/SHA-256 则标为 RECOMMENDED。

常规 DNSSEC 下，只要覆盖该记录集的任一 RRSIG 有效，解析器就可以接受它。RFC 6840规定解析器应接受任一有效签名，只有全部失败时才把记录集判为 bogus；RFC 4035把冲突处理留给本地安全策略。Cloudflare 更严格的后量子规则关上了这条退路：只要算法 18 的签名出现，它就必须通过验证。经典算法 13 的有效签名不能替损坏的 ML-DSA-44 签名补考。目的，是防止攻击者把后量子升级悄悄降回经典签名。

代价是，新签名也成了可用性的门槛。它一旦格式错误，经典签名原本足以认证的响应也可能被拒绝。这是解析器的本地策略选择，不是 DNSSEC 基础协议变了。

浏览器不是无菌实验室

Abley 把结果称为很早期、噪声很大。测试反复使用相同 DNS 名称，缓存可能影响对照；挑战没有绕过缓存。HTTPS 重定向会增加耗时；很快完成挑战的用户可以提前离开；两秒超时会截断慢请求。家庭网络和浏览器环境又叠了一层噪声。因此幻灯片给出的是值得追查的信号，而不是每次失败都由 ML-DSA 验证导致的因果清单。

部署选择当时仍未定。Cloudflare 还在试验在线 ML-DSA-44 签名，也没有公布客户可用日期。合规需求可能带来用户主动选择的需求；若要默认双签名，就需要对不破坏服务有很高把握。Joe Abley 的个人互联网草案提出用 Extended DNS Error 告诉客户端：解析器拒答是因为采用了更严格的本地策略，而不是一个莫名其妙的否定答案。

如果重新做一轮随机化、缓存隔离并带解析器级追踪的测试，部署判断可能改变：它可以把 DNS 验证错误与重定向、浏览器提前退出和超时分开。眼下可确定的是结果形状：中间近乎平坦，长尾陡起来；而策略规定，后量子签名必须算数。

来源