Cloudflare 1.1.1.1 开始支持 ML-DSA-44 这种后量子 DNSSEC

为什么 DNSSEC 必须现在就开始换算法

绝大多数人对 DNSSEC 的认知停留在「防止 DNS 劫持」，但目前的 RSA 和 ECDSA 算法在量子计算机面前基本是透明的。如果 2030 年左右出现了足够强大的量子机，攻击者只要拿到根域的私钥，就能伪造任何子域的验证路径。

这种攻击是「一次突破，全域伪造」。虽然 DNSSEC 提供的是真实性验证而非机密性（不像 TLS 协议那样担心数据被提前截获以后解密），但由于 DNS 体系是层级结构的，从根域到顶级域再到具体域名，迁移周期极长，必须提前让 1.1.1.1 这种大规模解析器先跑起来，验证实操可行性。

升级到 ML-DSA-44 遇到的最大坑是数据包体积

这次升级最核心的痛点在于签名的大小。我对比了一下目前常用的算法，你会发现这简直是量级上的跨越：

• ECDSA P-256： 签名仅 64 字节。
• ML-DSA-44： 签名高达 2,420 字节。

这个数字意味着什么？传统的 DNS-over-UDP 响应包大小限制非常严格。一个 2KB 多的签名还没加上实际的 DNS 记录内容，就已经超过了大多数网络设备的 UDP 承载极限。

这种体量会导致两个具体问题：
1. 丢包与截断： 很多旧的路由器或防火墙在处理这种超大 UDP 包时会直接丢弃或截断，导致解析失败。
2. 回退攻击： 为了兼容旧解析器，域名所有者必须同时发布传统签名和后量子签名。如果验证逻辑没写好，攻击者可以通过强制让解析器回退到旧算法，从而绕过后量子加密的保护。

实操层面的影响和验证

目前 1.1.1.1 已经开启了对 ML-DSA-44 的验证，这意味着它现在可以处理那些已经部署了后量子签名的区域。对于普通用户来说，不需要修改任何配置，只要把 DNS 设为 1.1.1.1 即可。

如果你是运维或者对网络协议感兴趣，可以用 dig 命令观察响应包的大小。虽然目前绝大多数域名还没切到 ML-DSA-44，但你可以留意响应头中的 AD (Authenticated Data) 标志位。如果某个域名未来部署了该算法，你会发现响应包的字节数暴增。

这次更新的实际意义在于「压力测试」。Cloudflare 计划在 2029 年前实现全链路后量子安全，他们在 2019 年就试过 TLS 的后量子密钥交换，结果发现大包在网络中传输时会触发很多隐藏的 Bug。所以这次把 ML-DSA-44 放到 1.1.1.1 上，本质上是在利用全球规模的流量去探测哪些网络设备会在 2420 字节的签名面前崩溃。

总结我的判断

这次更新不是给普通用户提升网速的，而是一次极其重要的「基础设施排雷」。

• 值得关注的点： 2420 字节的签名量。这意味着未来的 DNS 流量会增加，且对 UDP 分片处理能力要求更高。
• 潜在风险： 迁移期间的「双签名」阶段会导致 DNS 响应时间增加，且增加了被中间设备拦截的概率。
• 结论： 除非你正在构建一个需要极高安全等级的域名体系，否则不需要手动配置任何东西，但建议尽快将解析器切换到支持后量子验证的现代服务，避免在未来的强制迁移中出现不可预知的丢包问题。