摘要

  • RFC 3655 将 AD 位从宽泛的服务器策略标记，改为对相关 DNS RRset 是否按新规则通过认证的较窄说明。
  • AD 是解析器作出的状态报告，不是 DNS 报文签名，也不能证明解析器、网络路径或用户的信任策略可靠。

分析

想象一个普通应用把域名查询交给本机 stub，再由它转发给递归解析器。递归解析器能够沿密钥链验证记录、取回签名并复用缓存。响应返回时，DNS 头部里的一个比特可以把上游处理结果带回来。关键问题并非头部中有多少比特，而是谁有权作出这项判断，以及这项判断概括了什么证据。

RFC 2535 曾把 Authenticated Data（AD）位定义为服务器按自身策略认证了 Answer 和 Authority 区段中的数据。2003 年 11 月发布的 RFC 3655 认为，这样的信号在实践中并不有用：合规服务器本就不应返回违反自身安全策略的数据。于是，AD 主要描述了服务器整体的处理立场，而不容易让应用判断眼前这条响应的安全状态。

修订后的信号更具体。递归服务器只有在响应 Answer 和 Authority 区段中的相关 RRset 满足认证条件时，才可以设置 AD。答案记录以及支撑否定答案的相关记录都要经过认证。这里并不是说每个 DNS 响应包都获得了签名；DNSSEC 签的是资源记录集，AD 则汇总解析器对这条响应作出的本地判断。

这也说明 DO、CD 和 AD 不能混为一谈。DO 请求返回 DNSSEC 记录；RFC 3655 要求先请求这些记录并返回相关 SIG 记录，才能设置 AD。CD 表示此次查询禁用检查，但不会自动抹掉 AD：服务器仍可标记此前已验证、或符合本地策略的数据。它们分别描述请求证据、控制检查和报告结果。

由此，递归解析器成为信任链中的中介。应用无需各自实现完整验证器，也可以共享缓存结果；但 stub 不能把 AD 当作会自我认证的证明。它必须明确配置为信任该递归解析器，并保护通信，例如使用安全信道、TSIG 或 SIG(0)。否则，路径上的响应者设置的 AD 只是“数据已验证”的声明，不是安全送达的验证证据。

权威服务器规则揭示了另一条边界。安全区的主服务器可以被显式配置为设置 AD，但这一行为默认应关闭。RFC 3655 承认，权威服务器没有义务验证自己托管区的数据；在装载时或每次查询时验证签名，也会增加运行成本。因此，直接从权威服务器收到 AD=1，不会默认证明它做过递归解析器式的验证。

AD=0 也很容易被过度解释。RFC 3655 禁止对不安全答案设置 AD，但一个清零的比特并不能单独说明原因：数据可能是不安全的，解析器可能没有检查，所请求的 DNSSEC 记录可能没有返回，服务器也可能选择不对状态作出保证。AD=1 只在信任关系明确时才有意义；AD=0 不是完整诊断。

两年后，RFC 4033、RFC 4034 和 RFC 4035 重构 DNSSEC 框架并取代 RFC 3655。AD 仍用于传递验证状态，但进入了关于验证器、stub、权威服务器和认证路径的更完整说明。RFC 3655 的历史意义，在于修补一个狭窄接口：如何转达递归解析器的判断，同时不假装头部比特本身就是密码学证明。

证据链必须分层看待。RRSIG 可以在密钥链和信任锚的基础上支持对 RRset 的认证；验证器据此形成自己的判断；AD 可以报告该判断；与受信递归解析器之间的安全信道，又可将响应绑定到客户端选择的服务。这些事实都不能单独证明域名持有人诚实、信息对应用仍然新鲜，或应用采取了安全行动。

来源