Summary

  • IETF DNSOP 工作组第 00 版草案提出：若父区 DS 或信任锚集合含至少一种 UNIVERSAL 算法，且不含 FORMERLY-UNIVERSAL，区域可只用一种 UNIVERSAL 算法签名，其他签名可选。
  • 草案初定算法 8 与 13 为 UNIVERSAL。IANA 现行登记表已要求验证器实现二者，但尚无草案拟增设的“验证支持状态”列。
  • 解析器若按本地政策停用集合中出现的 UNIVERSAL 或 FORMERLY-UNIVERSAL 算法，就应把区域视作未签名；即使它还支持另一种算法，也不能把本地选择伪装成区域的坏签名。

同一个 DNS 区域列出两种算法，为什么每条记录都要背两份签名？RFC 4035和RFC 6840的现行规则让签名者照着算法清单逐一生产，验证器却只需找到一条有效链。这份不对称原本是在替未知解析器购买兼容性。如今 IETF 的新草案想缩减这张账单，但要求解析器把自己的算法政策写进安全结果。

两家独立 DNS 服务商共同托管区域时，账单尤其刺眼。RFC 8901允许各服务商持有自己的密钥。若各自采用不同算法，全算法签名规则会逼两家同步生产对方那套签名，削弱独立托管的好处。服务商交接会遇到同一难题。根区信任锚若要预先公布新算法，旧规则也可能拉出漫长的双重签名阶段。草案试图允许先铺设可信入口，再等新密钥与签名真正进入区域。

“通用”两个字值多少钱

草案要求 IANA 在 DNSSEC 算法登记表加一列 Validation support status，取值为 UNIVERSAL、FORMERLY-UNIVERSAL 或空白。初始 UNIVERSAL 指算法 8，即 RSA/SHA-256，及算法 13，即 ECDSA P-256/SHA-256；初始没有“曾经通用”算法。现行 IANA 表已把二者列为验证实现的 MUST。草案要把这种普遍支持预期转化成签名者可以依赖的规则。

规则并非随意少签。若父区 DS 或本地信任锚至少列出一种 UNIVERSAL，且没有任何 FORMERLY-UNIVERSAL，只需用一种 UNIVERSAL 签名，其余可选；DNSKEY 集合也可只保留实际签名算法对应的密钥。若集合里没有 UNIVERSAL，或出现一项 FORMERLY-UNIVERSAL，全部算法仍要签。判定依据是 DS 或信任锚集合的构成，而不是服务商今天想省多少算力。

这让采用算法 8 和 13 的两家服务商分别提供有效路径。新信任锚也可先公布，再把相应 DNSKEY 与 RRSIG 放进区域。某一家还可以试验后量子算法，而不用要求所有共签伙伴同日改造。若新算法尚未达到 UNIVERSAL，完成轮换仍可能要经过双签阶段。

本地禁用按钮，不能让区域背锅

假设区域宣布 8 和 13，其中一家服务商返回算法 8 的有效签名。某解析器管理员在本地关闭了 8，虽然软件还会处理 13。草案要求这个解析器把区域判成 insecure，即未签名，而非指责区域给出 bogus 结果并返回 SERVFAIL。对曾经 UNIVERSAL、后来被停用的算法，也适用同一方向。

责任边界由此变得尖锐。区域运营者使用 IANA 表要求验证器实现的主流算法。解析器运营者自己关掉它，因而丧失对该区域的 DNSSEC 认证。查询仍可能成功，网页仍能打开；“成功”二字不会告诉用户这次没有密码学证明。监控必须把 secure、insecure 与 bogus 分开，配置变更必须留下是谁按下了按钮。

旧的全算法规则并非官僚癖好。攻击者若剥掉解析器支持的签名，留下它不懂的签名，不能把原本安全的答案悄悄降为不安全。草案主张通过 UNIVERSAL 和 FORMERLY-UNIVERSAL 的历史标签维持防降级性质。验证器必须记得哪些算法曾被认定为通用，哪怕它后来被本地停用。这是一份软件状态账，也是一份运营责任账。

草案日期是 2026 年 10 月 31 日，目前只是工作组初稿。它没有给出受影响解析器数量，也没有宣布根区实际轮换。真正能改变某个运营者决定的，是其现网验证器互操作矩阵：不同签名子集送达时，各解析器分别判为安全、不安全还是坏签名？本地停用 8 或 13 后，状态又如何变化？没有这些结果，“支持 DNSSEC”太笼统。

IETF 草案把过去绑在一起的两项权力拆开了：签名者决定提供哪条合规证据，解析器运营者决定自己还承认哪些算法。前者可以少生产一份签名；后者若私自撤掉主流算法，就应清楚记录其放弃了哪份安全保证。方便的 DNS 答案，不能替代这个记录。

IETF 草案 · RFC 4035 · RFC 6840 · RFC 8901 · IANA 算法表