摘要

  • RFC 2065 把可验证证据附着在 DNS 资源记录上：区域负责签名，解析器负责验证，缓存或转发服务器不因占据传输位置而自动获得信任权。
  • 旧服务器可以保存并返回 KEY、SIG 和 NXT，但自动附送签名、CNAME 处理、委派边界以及 AD、CD 语义仍需要更完整的实现。
  • 该方案坚持 DNS 数据公开且对询问者一视同仁，因此不提供访问控制或查询保密；已验证的地址也不等于已验证的最终主机。

设想一条 DNS 答案由缓存服务器送达。服务器的确控制了这一次递送，却未必控制答案所宣称的事实。RFC 2065 的突破，是让这两个角色不再天然重合：服务器可以只是载体，解析器则检查由区域密钥产生的签名。

文件直接说明，数据来源认证所用的密钥属于区域，而非保存区域副本的服务器。这意味着服务器遭入侵会造成拒绝服务、遗漏、回放或旧数据污染，却不必然使攻击者获得产生新鲜有效签名的能力。控制信封，并不等于拥有在信中落款的权力。

三种服务各有自己的证据

RFC 2065 将安全扩展拆成公钥分发、数据来源认证与完整性、可选的事务和请求认证。拆分防止“安全 DNS”成为一个无法核验的总标签。

KEY 记录把公钥与 DNS 名称关联。解析器仍须通过可信方式预先配置至少一个起始密钥，再从这个锚点验证其他区域的签名密钥。协议没有消灭信任，而是把信任的起点和延伸路径显式化。

SIG 是资源记录集的核心证据，包含覆盖的记录类型、签名者、算法、原始 TTL、签名开始与到期时间以及签名字节。验证成功支持的是一个有边界的结论：在指定时间窗内，这组记录可追溯到某个已认证密钥，且未被改动。它不会因为与其他数据处于同一报文，就顺带认证其他数据。

NXT 用于证明名称不存在，或某个既有名称下不存在某种类型。后来的 DNSSEC 改变了具体机制，但问题边界在 1997 年已经清楚：沉默不是经过签名的否定答案。

事务签名处理的又是另一层。RFC 特别提醒，认证一条 DNS 事务，并不认证报文中的全部资源记录。事务来源与区域数据来源必须分别留下收据。

兼容性把工作留给了真正作决定的一端

RFC 2065 没有为了来源认证另造传输协议，而是在既有 DNS 报文中加入新的资源记录类型。一个只会妥善保存和返回未知类型的服务器，就能帮助安全数据穿过尚未升级的基础设施。

代价是额外查询。安全感知服务器会尽力在答复中自动附上覆盖目标记录集的签名；普通服务器可能只返回明确请求的类型。解析器于是要再查询该名称下的所有 SIG，自行挑出覆盖所需记录集的签名。迁移没有免费午餐，但额外成本落在愿意验证的一端，而不是以虚假的中央信任换取便利。

CNAME 是明确例外。传统服务器会跟随别名，导致解析器拿不到原名称上的安全记录。RFC 因而区分最低与完整服务器符合性。最低符合性是能保存、区域传送并按请求返回 KEY、SIG、NXT；完整符合性还包括签名构造、自动附送、安全类型的别名处理、委派点逻辑，以及 AD、CD 两个头部位。

AD 表示答复服务器已经验证所含数据；CD 表示查询方愿意接收尚未由上游完成检查的数据，因为它准备自己做密码验证。旧实现把两位都留为零。零保证旧软件不立刻破坏协议，却绝不是“已经认证”的肯定判断。

缓存寿命与签名寿命不能混成一个时钟

DNS 缓存中的 TTL 会递减，签名字节却要求被签内容保持稳定。RFC 2065 在 SIG 中保存原始 TTL，并另设签名生效与到期时间。解析器可以缩短缓存使用时间，不能把它延长到原始签名 TTL 之外；签名到期后，即使记录仍在缓存，也不再构成认证证据。

解析器的时钟本身因此成为依赖。如果时钟被倒拨，旧签名可能重新显得有效。安全时间、密钥保管、缓存策略和本地接受规则共同决定结果，单次成功传输无法证明其中任何一项。

“公开且可信”不等于“私密且获准”

RFC 2065 的非目标写得十分明确。DNS 被视为公开数据系统，并向所有询问者给出相同答案；文件不增加访问控制列表，也不区分谁有资格提问。查询和答复同样没有保密性，需要隐私时应由 IPsec 等独立信道机制承担。

验证边界还停在 DNS 记录本身。解析器确认某个名称对应的地址，并不能确认此刻占用该地址的主机确实获得授权，也不能阻止 DNS 之外的截包和伪造。签名只缩小特定不确定性，不会把整条应用通信链包装成可信状态。

被取代不等于没有留下设计价值

IETF Datatracker 保存了 1994 至 1996 年间的草案修订，并记录 RFC 于 1997 年 1 月发布，但这些材料不构成部署数量证明。1999 年 3 月，RFC 2535 取代 RFC 2065，并明确表示吸收了早期实现经验和潜在用户需求。2005 年，RFC 4033、4034、4035 又取代这一代设计。

后续文件的名称、记录格式和委派机制不能原样倒灌到 1997 年。不过，责任分离仍可辨认：签名者制作来源与完整性证据，服务器负责可用与运输，解析器依据本地锚点和时间验证，应用层继续保护端点与内容。

用 Lu Heng 后来提出的“最小初始规范”观察，RFC 2065 的价值在于把必要共同规则浓缩成可以本地检查的对象，同时容许中间服务器分阶段升级。这是后见的编辑解释，不是对 Eastlake、Kaufman 或 DNSSEC 工作组意图的历史证明。它提醒我们：共同协议可以规定什么叫有效，而不必让每个转运者获得决定所有人该相信什么的权力。

来源