摘要

  • RFC 3445 把新发布的 KEY 记录限制为 DNSSEC 协议值 3；原因不是其他公钥不存在，而是查询无法选择内部子类型，签名又覆盖完整 RRset。
  • 迁移方向刻意不对称：权威端停止写入旧值，读取端验签时仍保留旧记录；提前丢掉一个成员会改变被签名集合，并可能让缓存彼此不一致。

通用抽屉没有查询隔板

RFC 2535 定义的 KEY RDATA 包含 Flags、Protocol Octet、Algorithm 和 Public Key。协议值 1 表示邮件，2 表示 IPsec，3 表示 DNSSEC，4 表示 TLS；5 到 254 尚可分配，255 表示任意协议。把 DNS 当成各种公钥的分布式目录，当时并非荒唐想法。

问题出在接口边界。DNS 请求可以指定 KEY 类型，却不能让服务器只返回其中一个协议值。同一所有者名称下，客户端必须接收整个 KEY RRset。DNSSEC 的签名同样不按用途拆分，而是覆盖整个集合。用途是复数，检索和证明单位却只有一个。

Donald Eastlake 与 Olafur Gudmundsson 撰写的 RFC 3445 于 2002 年 12 月发布，把有限实验部署暴露的问题变成规范边界。纯文本、RFC Editor 记录、Datatracker、历史、参考文献、后续引用和勘误证明文档轨迹，不证明部署规模或某个解析器行为。

六种差异，被一种格式遮住

文件逐项区分 DNSSEC 与应用密钥：用途不同、管理员不同、认证规则不同、权威服务器是否应返回它们的理由不同、解析器处理方式不同，发生故障或泄露后的后果也不同。DNSSEC 密钥是 DNS 数据完整性的基础设施；应用密钥对 DNS 本身没有特殊含义。

混合 RRset 会随无关应用不断增大，每次应答携带不相关材料，还把本来独立的轮换周期绑在一起。更危险的是，若代码只看到“公钥”而忽略协议字段，遭泄露的应用密钥可能被误当成区密钥。密码学只能回答软件提出的问题；它不能修正软件把错误主体当成权威。

RFC 3445 要求新权威 KEY 数据只能使用协议值 3，并把除了区密钥位——第 7 位——之外的 Flags 位全部保留。原有应用值 1、2、4、255 以及开放范围被关闭，新分配只允许 Standards Action。与 RFC 2930、RFC 2931和安全动态更新 RFC 3007有关的 DNSSEC 用途仍在边界内；旧的主机/用户区分则不再保留。

不再赋权，不等于验签前删除

读取规则却不能简单反向。非 3 值绝不能用于认证 DNS 数据，但解析器仍应把它作为 RRset 成员保留到签名验证完成。签名者覆盖的是原始完整集合。读取端若先删除一个应用密钥，再验证 SIG，计算的已经是另一个对象，签名自然失败；不同缓存若采用不同过滤，也会保存名义相同、内容却不同的集合。

因此，“拒绝它作为 DNS 权威”和“从待验证证据中抹掉它”是两件事。RFC 3445 给出的迁移次序是：先停止生产旧形式，继续具备读取和保全能力，撤销其语义权力，直到各层有证据地收敛后再删除。

后来 RFC 4033、RFC 4034、RFC 4035取代 RFC 2535 系列，并使用更明确的 DNSKEY。其他用途也有更专门的记录：SSHFP、CERT、TLSA。这些是后来分界更清楚的背景，不能倒推为 RFC 3445 单独造成的结果。IANA DNS 参数证明登记状态，不证明部署、正确性或安全结果。

共同编码不是共同信任域

Heng Lu 的现实层纪律要求把编号、签名有效、管理权、运行代码和真实结果分别记账。把它们塞进一个记录，只让界面看起来统一，并没有统一权力和责任。运行代码优先说明实验为何有纠偏资格：实际查询、签名、缓存与轮换把抽象图没有写出的成本显现出来；这不等于代码自动拥有治理权。

最小初始规范则给出正面准则：只标准化参与者真正共享用途、验证规则和失败后果的最小对象。DNS 可以定义自身的基础设施密钥，却不必成为所有应用公钥的总治理者。这是编辑分析，不是对 RFC 作者动机的声称。

RFC 3445 最耐用的结论很简单：相同线格式不代表相同信任域。当查询、签名和缓存迫使对象成组移动，集合边界就已经成为安全边界与治理边界。

来源