摘要

  • draft-kaizer-dnsop-ml-dsa-mtl-dnssec-02 用一份 ML-DSA 签名保护 Merkle 阶梯，再让多个 RRset 通过各自的认证路径共享这次昂贵的签名。
  • 单次响应可以完成验证，但它无法证明权威签名集群保存了同一套节点历史；当前草案明确把区域更新、传送、缓存和运行指引留给后续工作。

第 02 版发布于 2026 年 9 月 28 日。它把预期状态改为 Standards Track，并加入建立 MTL 类型 IANA 注册表的请求。它仍是个人 Internet-Draft，不是 DNSOP 工作组采纳稿，不代表 IETF 共识，也不是 RFC；算法编号仍为 TBD。文中列出的 LDNS、NSD、Unbound 与 C 参考库只说明测试实现存在。草案同时声明，这些信息由贡献者提供、未经核验，也不构成 IETF 背书。

设计所面对的约束很具体。NIST 已将 ML-DSA 标准化为后量子数字签名，但完整签名远大于今天常见的 ECDSA DNSSEC 签名。若每个 RRset 都重复携带一份，区域文件、权威响应与递归缓存都会膨胀。Merkle Tree Ladder 的目标，是把完整签名成本摊到多个消息上。

DNSKEY 发布 ML-DSA 公钥。签名者为每条消息采样 randomizer，计算叶节点，并从零开始连续分配索引。叶节点进入一个不断增长的 node set；每个实例由 32 字节 SID 标识。若干 rung 共同认证当前全部节点，ML-DSA 则对 flags、SID、rung 数量与 rung 数据组成的阶梯签名。

完整 RRSIG 还带有叶索引、randomizer 和 sibling hash 路径。解析器先用 DNSKEY 检查阶梯签名，再从 RRset 重算叶值，沿路径抵达相容的 rung，之后继续普通 DNSSEC 信任链验证。一个响应可以带齐所需材料，一份完整签名也确实能覆盖许多 RRset。

节省没有消除状态，只是改变了状态所在。叶索引记录消息在系列中的位置，SID 界定系列，randomizer 参与叶哈希，rung 则随叶节点追加而变化。新消息进入后，旧消息可能需要针对当前阶梯重新计算认证路径。所谓“同一座阶梯”，本质上是一段有顺序的签名历史。

草案对此给出一条明确安全边界：不同 MTL 实例不得复用同一个 SID，并特别举出 KSK node set 与 ZSK node set 必须使用不同 SID。原因不难理解。验证材料只有在角色、签名者与系列都没有被混淆时才有意义。复制私钥不等于复制这层身份。

现实中的签名服务往往不止一个进程。它可能有隐藏主节点、HSM、热备、灾备、离线 KSK、在线 ZSK 和区域传送链。若两个节点都从旧快照恢复，它们是否会分配相同的下一个索引？若一个节点已经发布新阶梯，另一个能否回退？若切换时选择新 SID，旧响应和缓存如何过渡？第 02 版没有规定这些动作。

这不是说恢复一定做不到。实现可以复制内部状态，也可能依据保存材料重建，或干脆启动新系列。问题在于这些方法尚未被写成公共的互操作合同。草案只聚焦 DNSKEY、RRSIG、code point 与密码运算，并明确说区域签名、组成、更新、传送、权威处理、解析器处理和缓存要由后续版本或文件说明。

批量签名把状态问题与时间问题连在一起。一个批次内追加多条消息，可以减少平均 ML-DSA 运算与 HSM 负载；但批次未封口之前，新 RRset 还没有对应的新阶梯。批次大小由运营者决定是合理的，生产系统仍需给出最大等待时间、提升哪一代阶梯以及集群落后时的拒绝规则。

在线签名也不是自动答案。草案举例说，可以为每次动态响应新建 node set。这样或许缩短共享历史，却可能把摊销收益限制在一次查询之内。“支持在线签名”不能代替对 CPU、HSM、延迟和恢复成本的实测。

传输约束同样没有消失。第 01 版删除初稿中的 EDNS(0) 优化，并规定每个 RRset 只发送完整 MTL 类型。第 02 版直接说明，这种响应总会超过 DNS over UDP；它预期 TCP 流量增加，并建议担心截断后重试的客户端在遇到该算法时直接使用 TCP。

TCP 只能把字节送达。它不能证明权威节点持有同一代阶梯，不能证明解析器接受新算法，也不能证明 DS 与 DNSKEY 一直验证到本地信任锚，更不能证明应用真的获得服务结果。每一层都需要自己的回执。

BTW 已发布的 SigTag 文章处理另一个环节：客户端如何声称缓存了哪些阶梯，服务器何时发送 condensed response，以及隐私与回退。本文不重写那条论点。这里的对象是更靠前的签名者状态：在复用阶梯之前，运营者必须先能一致地生成、保存、迁移和恢复它。

这正是 running-code primacy 的检验。标准轨道意向、拟议编号与测试代码都很有价值，却不是生产事实。真正的采用，需要独立实现穿过更新、传送、KSK/ZSK 分离、快照回退、节点故障与 TCP 压力，且结果可以由解析器从真实信任锚验证。

一份可审计的 ladder receipt 应至少记录密钥角色、SID、索引区间、rung 集合、SOA serial、签名节点、软件版本、生成时间与前一代。恢复演练应故意让备机落后一代，再证明它要么准确续写，要么通过可见迁移开启新系列。仅验证一条旧响应，并不能证明明天还能安全签名。

来源