Cloudflare 已在公共 DNS 解析器 1.1.1.1 上启用使用 ML-DSA-44 算法验证 DNSSEC 签名，此举旨在测试域名系统为这样一个阶段做好准备的程度：届时，现有签名算法可能会被强大的量子计算机破解。该公司表示，这一步是更长期迁移过程的开始，而不是后量子 DNSSEC 安全的完整实施。
美国国家标准与技术研究院（NIST）已将 ML-DSA-44 发布为标准化算法之一，该算法获得了 IANA 分配的 DNSSEC 算法编号 18。Cloudflare 计划在 2029 年前实现完整的后量子安全，其此前的大部分工作重点放在 TLS 密钥协商上。
一个签名就比常规 DNS 数据包更大
最突出的实际障碍在于签名大小。ML-DSA-44 签名大小为 2,420 字节，而 ECDSA P-256 签名为 64 字节；其公钥大小也达到 1,312 字节。因此，仅签名本身就超过了 DNS 经 UDP 传输时常见的响应限制，之后还要加上记录、域名、协议头以及其他 DNSSEC 记录。
DNS 实现通常对 UDP 数据包采用 1,232 字节这一较为保守的限制，该限制与 IPv6 的最小传输单元有关。当数据包容量不足时，权威服务器应返回截断响应，促使解析器改用其他协议重试，通常是 TCP，而不是依赖不可靠的 UDP 分片。这个问题在携带验证区域所需密钥的 DNSKEY 响应中尤为明显；当传统密钥与后量子密钥同时发布，或在密钥轮换期间，问题可能进一步加剧。
防止回退到传统签名
传统算法无法立即停用，因为旧版解析器将无法验证只发布 ML-DSA-44 的区域。但同时保留两条路径可能造成降级攻击路径：当某种传统算法（例如 ECDSA）在量子环境下变得不安全后，攻击者可以伪造依赖该算法的响应，即使解析器具备使用 ML-DSA-44 的能力。
为应对这一问题，1.1.1.1 依赖父区中发布的 DS 记录。如果经验证的 DS 集合包含受支持的后量子算法记录，Cloudflare 就会执行更严格的本地验证策略，要求存在使用 ML-DSA-44 的有效验证路径；仅有传统路径并不足够。该公司说明，这目前还不是 DNSSEC 中通常采用的验证机制，但它基于 RFC 4035 所提供的本地策略权限。
实际会发生什么变化？
对于 1.1.1.1 用户而言，无需进行任何更改；当区域发布所需的 DNSSEC 记录时，验证会自动进行，而现有区域仍按通常方式运行。Cloudflare 表示，约 85% 发往 1.1.1.1 的查询通过 UDP 到达，因此测量更大响应以及通过 TCP 重试，是运行测试的重要组成部分。
但是，在解析器上启用验证并不会建立完整的后量子信任链。权威服务器必须支持区域签名，注册机构必须接受相应的 DS 记录，注册表还必须将其发布到父区，并一直延伸至 DNS 根区。任何缺乏后量子保护的层级，仍可能成为降级攻击的潜在切入点。
certi.news 的解读
这项公告的核心价值并不是为终端用户增加一个选项，而是将 ML-DSA-44 从加密标准带入大规模运行测试。Cloudflare 揭示的问题具有双重性：一方面，需要传输远大于常规大小的消息；另一方面，在旧算法仍将持续存在多年的情况下，必须保持验证的严格性。尚待回答的问题与该算法在整个 DNS 链中的采用速度，以及带宽成本和 TCP 使用增加的测量有关。Cloudflare 计划随后为 Cloudflare Authoritative DNS 增加 ML-DSA-44 签名支持，并为其客户免费支持 Cloudflare Registrar 中的 DS 记录，从而能够测试完整路径。