摘要

  • RFC 3008 把密码学正确性降为 DNSSEC 接受条件之一：数据签名还必须通过字段检查，并由匹配的区域钥匙产生，才是解析器应处理的实质证据。
  • 主机和用户钥匙仍可通过 SIG(0) 证明谁发起了交易，但区域钥匙负责为公开数据背书，把提出变更的能力与代表区域说话的权力分开。

有一种签名不会算错，却依然没有资格进入信任链。它可能与公钥完全匹配，也可能覆盖了正确的字节，问题只在于那把钥匙并不代表这个区域。RFC 3008 在 2000 年 11 月处理的，正是这类“数学正确、权力错误”的情形。

文件把签名分成 material 与 immaterial。前者是 DNSSEC 解析真正使用的证据，通常覆盖一个 RRset；后者可以服务于应用自己的规则，也可能根本不绑定 RRset，或者以 SIG(0) 的形式保护一条 DNS 消息。非实质签名未必伪造。它只是没有进入该解析器用来确认区域数据的公共证据链。

这道分类收紧了 RFC 2535 的早期模型。旧设计在某些情况下允许区域、主机和用户钥匙直接给数据签名。动态更新是其中一个理由：让主机签署自己带来的记录，看似可以让最敏感的区域私钥保持离线，同时又保留分散写入的能力。

然而，整条执行路径并没有兑现这个离线承诺。安全动态更新还要重签 SOA 和 NXT 集合，RFC 3007 所描述的更新流程因此仍需要在线区域签名能力。既然区域钥匙必须在线，而且能够重签新数据，再让主机或用户签名直接成为全网解析器认可的区域证据，便不再减少那项暴露，只会把“这把钥匙究竟能签什么”的复杂判断推给每一个解析器。

RFC 3008 选择缩小默认权力面。安全区域的数据应由区域钥匙签署；除非本地策略明确覆盖，解析器在处理数据签名时必须忽略非区域钥匙。灵活性因此减少，但验证链被限制在名称的标签深度之内，签名权也沿着可见的区域结构解释，不再需要解析器推测任意主机与 RRset 之间的授权关系。

“区域钥匙”并不是跳过其余步骤的徽章。RFC 3008 先检查签名本身的字段。数据 SIG 的 type covered 必须与所附 RRset 类型一致。算法必须被客户端识别，并有确定的 SIG 数据格式。labels 计数不能大于签名所有者名称的标签数。original TTL 不得低于当前 SIG 的 TTL，因为中间服务器无权把 TTL 增大。验证时刻还必须落在生效与到期之间。

随后，signer name、key tag 与算法要共同找到候选 KEY。找不到钥匙，签名就没有进一步处理的资格。若多个 KEY 共享这组三元标识，它们都会保持候选，直到密码学验证找出真正的签名者。解析器不能先看见“验证成功”，再倒推这把钥匙应该拥有什么身份。

KEY 自身还有门槛。类型标志必须允许 authentication。实质数据签名所对应的 name type 必须是 zone。protocol 字节必须声明 DNSSEC 或 ALL，而不是另一个协议用途。KEY 与 SIG 的算法也必须一致。于是，同一份公钥即使能给同一批字节算出正确签名，只要其声明角色或用途不对，结果仍不能成为 DNSSEC 的区域证据。

这些检查产生的是不同收据。密码学验证连接钥匙、签名与被覆盖字节；字段资格说明对象格式可处理；签名者角色说明谁可以代表区域；信任链说明解析器如何从已有信任抵达这把区域钥匙；时间窗说明这一证明何时有效。即使全部通过，它也只证明被签署的 DNS 断言没有在链路上被替换，并不证明地址后的服务仍在线，或记录描述的现实一定为真。

交易签名走另一条路。type covered 为零的 SIG 保护整条 DNS 消息，即 RFC 2931 进一步定义的 SIG(0)。这种消息由用户或主机发起，因此预期钥匙类型也是 user 或 host/entity。即使名称服务器产生 SIG(0)，它在这里代表主机，而非某个区域。区域钥匙通常不应给 SIG(0) 签名。

这不是把主机钥匙降为无用，而是给它一个更准确的证明对象。主机钥匙可以证明谁提交了更新请求，却不会因此让全网直接把主机签署的 RRset 当作区域真相。主服务器先依据 RFC 3007 的本地策略判断这个认证主体能否修改某个名称、某类记录以及执行哪种动作；默认权限是不允许修改。接受之后，再由区域钥匙为面向公众的状态签名。

提出、准入、公开背书因此是三种权力。解析器不需要取得主服务器内部的每条访问控制规则，也不必复演历史更新过程。它只需按照共同基线判断公开区域数据。主服务器则能改变本地授权政策，而不必把未来的每种组织规则塞进 DNS 报文格式。

早期 KEY 的 signatory 字段恰好说明这种选择。RFC 3008 没有给它分配任何值，也不要求它存在。用几位比特编码“谁能签什么”很诱人，却会把更新授权和公开验证锁在同一个僵硬枚举中。新规则宁愿保留两个清楚的决策面：写入入口用本地策略，公共解析用区域钥匙基线。

这仍是一段历史模型。RFC 3090 补充说明了当时如何判定区域安全状态；RFC 3658 后来用 DS 记录重构父区与子区之间的连接；RFC 4033、RFC 4034 与 RFC 4035 最终取代 RFC 2535 与 RFC 3008 那一代 KEY/SIG 框架。

因此不能把 RFC 3008 当成今天的配置手册，也不能把它的 KEY 标志不加解释地映射成现代 DNSKEY/RRSIG 语义。RFC 3130 记录了 2001 年的技术会议，当时 DNSSEC 被看成一组发展速度不同的工具。这可以证明设计仍在分化，却不能证明 RFC 3008 已被普遍部署，或它独自带来了可测量的安全收益。

它留下的历史价值，是把“证明”和“授权”重新接合而不混同。签名对象本身不会携带完整委任。接收它的运行代码必须检查签名者类型、协议用途、时间、覆盖对象与信任路径。否则，密码学的精确会让一把钥匙获得架构从未授予的公共话语权。

借用 Lu Heng 的 Running-Code Primacy 视角，权威并不驻留在签名字符串里，而在解析器完成整个分类和验证流程时才出现。最小共同层是区域钥匙规则；本地可以增加例外，但例外属于作出决定的解析器，不会自动改写所有人的基线。稳定性也不能压缩成一个绿色的“signature valid”状态，而要保留每一层收据。

RFC 3008 让签名不再像魔法，更像一份有边界的证词。签名证明钥匙参与，KEY 声明用途，区域位置赋予角色，信任链说明来源，时钟限定期限。只有这些证据在同一个对象上会合，密码学有效才成为 DNSSEC 权威。

Sources