摘要

  • 2026 年 9 月 1 日，DNSOP 主席认定工作组明确支持收养 draft-huque-dnsop-multi-alg-rules-08，但同时要求在后续工作中处理机制过于复杂的担忧。
  • 草案拟设 UNIVERSAL 与 FORMERLY-UNIVERSAL 状态；在特定组合下，签名方只需提供一种“通用”算法的签名。
  • 该状态还会决定本地禁用某种算法的验证器把区域视为未签名还是错误，因此并非说明性标签。
  • Daniel Kade 建议：今后每一次算法状态变更都应附带独立的部署证据收据；草案收养记录不能替代 Standards Action 的授权记录。

主席没有把保留意见删掉

收养征询的结案邮件非常简短。主席先说，回复显示对收养文件有明确支持；紧接着又说，社区对拟议机制复杂度的担忧，应在工作组后续处理中解决。这不是先批准、再附加一句客套话，而是同一项程序判断的两个组成部分。

征询从 8 月 13 日开始，到 31 日结束。当前 Datatracker 记录把文件列为 DNSOP 的活跃 Internet-Draft，工作组状态是 Adopted by a WG；IESG 一侧仍是 I-D Exists，没有列出 shepherd、负责 Area Director 或 telechat 日期。第 08 版由此进入工作组的变更控制，却没有变成 RFC，更没有获得 IETF 最终批准。

收养是选择“由谁继续改”，不是选择“哪一版已经正确”。这篇草案尤其如此，因为结案记录亲自把复杂度留作下一阶段的任务。

现行规则用完整签名换取确定性

RFC 4035要求，区域顶点 DNSKEY 集合中每一种算法，都至少要为每个 RRset 产生一份 RRSIG；顶点 DNSKEY 集合还要由父区 DS 集合出现的每种算法签名。RFC 6840再次说明签名方的完整性义务，同时要求验证器接受任意一条有效验证路径。

这种不对称有成本，也有理由。签名方通常不知道世界各处验证器究竟支持哪些算法，因此把已公布的算法签名全部提供出来，可以避免“支持的签名被删掉”与正常缺省状态混在一起。代价则落在多供应商协作上。RFC 8901明确指出，现有多签名方模型要求各供应商使用共同算法。两个算法集合没有交集的供应商，不能只把各自的密钥并列起来就完成安全迁移。

第 08 版草案正要放松这一约束。它列出的应用场景包括长期多签名方运行、在算法不相交的供应商之间转移区域、把 KSK 与 ZSK 的算法迁移分开、提前发布信任锚，以及让一家供应商先试验新算法而不强迫所有伙伴同步升级。DNSOP 已确认这些问题值得由工作组承担；具体解法仍可改变。

注册表里的一个词会改变线上行为

草案要求 IANA 新增 Validation support status 一栏，允许填写 UNIVERSAL、FORMERLY-UNIVERSAL 或留空。初始方案把算法 8 和 13 标为 UNIVERSAL，没有任何算法进入 FORMERLY-UNIVERSAL。当前 IANA DNSSEC 算法注册表还没有这一栏；它现在记录的是使用建议与实现要求，其中算法 8、13 的验证实现要求为 MUST。

新状态会产生直接后果。如果 DS 或信任锚集合至少包含一种 UNIVERSAL 算法，同时没有 FORMERLY-UNIVERSAL，签名方只需用其中一种“通用”算法提供签名，其他已公布算法的签名可以省略。若组合不满足这一条件，则仍须提供全部算法的签名。

验证器一侧也会变化。按草案规定，若验证器不支持集合中某种 UNIVERSAL 或 FORMERLY-UNIVERSAL 算法，即便它支持集合里的另一种算法，也要把该区域视为未签名；其他情况下则接受任意有效路径。验证器若因本地政策禁用算法，还必须记得它现在或过去是否属于“通用”。

因此，这个标签不是对算法声誉的评价。它决定签名方能省掉什么，也决定验证器在特定不兼容情况下输出 Insecure 还是 Bogus。分类过早或过期，都会以可用性和安全状态的形式进入运行网络。

RFC 9904提供了可比较但不同的制度。它把 DNSSEC 算法的实现要求和使用建议移到 IANA 注册表，并明确区分“实现为了互操作性必须具备什么”与“运营者应部署什么”。这些值会随时间调整，退役通常应渐进进行。拟议的新状态有另一套作用，不能因为与旧栏目放在同一张表里，就继承旧栏目的证据。

赞成继续工作，不等于赞成现有设计

公开邮件解释了主席为何留下复杂度条件。Mark Andrews反对草案，并质疑其对全球验证器支持状况的假设。Paul Hoffman赞成放松“每种算法都签”的旧约束，却反对当前两种生命周期标签。Paul Wouters支持收养，同时要求大幅简化并把不同场景拆清楚。

这些只是个人意见，不能由本文重新计票，更不能当作 DNSOP 共识。它们的价值是把结案邮件所保留的异议具体化：争论的不是问题是否存在，而是抽象层次、生命周期记忆、本地偏好和旧验证器应承担什么后果。

草案自己承认最难的一步无法由协议完成。某算法是否得到普遍支持，必须由社区判断；只有在“不支持的验证器群体可忽略”时，才应把它提升为 UNIVERSAL。这句话把经验事实与治理决定连接起来，却没有自动给出样本、日期或阈值。

给分类变化单独开一张收据

今后每一次通过 Standards Action 增减状态，都应随附一份短而可核验的证据收据：算法编号与注册表版本、测量日期、观察到的验证器群体、已知遗漏和旧实现、判断“不支持者可忽略”的规则。

收据还应列出典型多签名方与供应商迁移状态下预期的 Secure、Insecure、Bogus 结果，说明本地算法偏好如何相交，标明生效窗口、签名方依赖、紧急迁移或回退责任人。解析器身份和商业机群数据可以保护；支撑全球互操作判断的边界不能隐去。

Heng Lu 的最小共同层原则在这里给出清楚界线：只有独立运营者为保持互操作而必须共享的事实，才需要统一分类。对数种可接受算法的本地取舍，应继续留在本地，除非后续标准程序明确决定并解释为何需要收紧。

DNSOP 这次收养的是问题，也是继续修改该问题的责任。它没有提前收养注册表中的强标签。把收养收据与分类收据分开，才能让编辑状态不冒充网络状态。

来源