1.1.1.1试水后量子DNSSEC
Cloudflare公共解析器已能验证ML-DSA-44签名，但2420字节的大签名也把真正难题摆上台面：更大的DNS响应如何可靠传输。
60 秒版本
Cloudflare称1.1.1.1现已验证ML-DSA-44 DNSSEC签名，为后量子迁移提供互联网规模的解析器测试场。
要点
- NIST已经标准化ML-DSA，IANA把ML-DSA-44列为DNSSEC算法18，目前签名和验证均为可选实施。
- 2420字节的ML-DSA-44签名接近ECDSA P-256的38倍，单独就超过常见DNS UDP响应尺寸目标。
- 超大响应可能触发TCP重试，因此带宽、延迟和中间设备兼容性成为核心部署问题。
- 完整信任链仍需权威服务器、注册商、注册局和DNS根区采用后量子签名与降级保护。
结论. 这是有意义的解析器端里程碑和压力测试，但不能证明整个DNSSEC已经抗量子。
Cloudflare称，1.1.1.1公共解析器现已验证DNSSEC中的ML-DSA-44签名。NIST已经标准化该算法，IANA则把它登记为DNSSEC算法18。这是解析器真正完成的一次升级，但不是整个DNS已经完成抗量子迁移。
发生了什么解析器现在能做什么
DNSSEC为DNS记录添加数字签名，让解析器可以沿着从根区、父区到目标域名的信任链验证响应。当前常见算法依赖RSA或椭圆曲线密码，未来足够强的量子计算机可能威胁这些体系。
ML-DSA采用基于格结构的设计。NIST于2024年在FIPS 204中正式发布标准，IANA注册表现在把ML-DSA-44分配为算法18。Cloudflare为1.1.1.1加入了验证能力：域名发布相应记录后，解析器可自动检查。
数据包压力2420字节为何改变传输
ML-DSA-44签名接近ECDSA P-256的38倍，而且它单独就超过RFC 9715通常建议的1400字节DNS UDP响应上限；此时还没有计入域名、头部、公钥和其他DNSSEC记录。
| 小型UDP响应 | 通常用一个数据报完成传输，协议开销较低。 |
|---|---|
| 超大签名响应 | 服务器可把UDP响应标记为截断，要求解析器改用TCP重试。 |
| 运行成本 | 更多字节、更多连接状态和潜在延迟，需要在中间设备与DNS实现中实测。 |
TCP回退本来就是正常DNS行为，不等于故障。问题在于它会多频繁发生、在大规模流量下是否可靠。Cloudflare称，启用验证后可以测量签名验证成本、额外带宽和TCP使用量。
迁移陷阱新旧签名必须并存
大量解析器尚不理解ML-DSA-44时，域名不能直接删除传统签名。同时发布两套签名可以兼容旧解析器，却可能留下未来的降级路径：旧算法可被伪造后，新解析器仍可能错误接受一条传统路径。
Cloudflare称，1.1.1.1会把父区中经过认证的DS记录作为信号，要求至少一条后量子路径验证成功。这种策略只有在信任链本身得到保护时才有效；任何未升级的父区、注册局或根区仍可能成为薄弱点。
现实边界完整迁移还缺什么
- 解析器支持： 1.1.1.1能验证算法18，其他解析器与软件也需要各自实现。
- 权威签名： DNS运营者必须能够可靠发布ML-DSA-44公钥和签名。
- 委派支持： 注册商和注册局需要接受并发布对应DS记录。
- 根区采用： 完整保护需要后量子信任锚，以及从根向下受保护的每一级委派。
- 运行证据： 仍需测量响应大小、回退率、延迟、失败模式和密钥轮换表现。
一个解析器学会新签名，是迁移起点，不是终点。
普通用户无需修改任何设置
已经使用1.1.1.1的人不需要手动启用功能，现有DNSSEC域名也照常验证。真正值得跟踪的是权威DNS、注册商、注册局和根区的采用进度，不应把一次解析器公告误读成整个系统已经抗量子。
主源Cloudflare: 1.1.1.1 now supports post-quantum DNSSEC·NIST FIPS 204: Module-Lattice-Based Digital Signature Standard·IANA DNS Security Algorithm Numbers registry·IETF Datatracker: ML-DSA for DNSSEC Internet-Draft·RFC 9715: DNS Transport over TCP implementation requirements·PPC Land: independent technical coverage