摘要

  • 执行验证的递归解析器只有在认为 Answer 与 Authority 部分的相关 RRset 都真实可信时，才设置 DNSSEC AD 位；这个位报告的是该解析器的结论，并非数据包自证。
  • 不自行验证的 stub 只有同时信任递归解析器，并对通往它的信道实施保护或认证，才可依赖这个结论；具备验证能力的 stub 应当自行验证。
  • DNSSEC 验证、解析器结论的安全交付和应用最终决策分属三道证据边界；没有 AD 位，不能单独证明数据属于 Bogus。

大量验证工作最后压缩成一个比特

一台终端向配置好的递归解析器询问域名。解析器在给出答案前，可能已经逐级跟随委派，取得 DNSKEY 和 DS 记录，沿信任锚构造验证链，核验签名，并处理经过认证的不存在证明。返回终端的 DNS 报文装不下这段过程，只能在头部带回一个 Authenticated Data 标志，也就是 AD。

这种压缩有实际价值。轻量客户端不一定要重复能力完善的解析器已经做过的工作。但上下文也会随压缩消失。界面若把 AD=1 直接画成“安全”，读者很容易以为网络路径、目标系统乃至请求动作都已得到认证。RFC 实际给出的结论要窄得多。

RFC 4035 规定，具备安全能力的递归域名服务器，只有在它认为响应 Answer 与 Authority 部分的全部 RRset 均为真实数据时，才设置 AD。句子的判断主体是解析器。它按照自身的信任锚、验证政策和当时看到的响应得出结论。这个位是计算结果的摘要，既不是覆盖 DNS 头部的签名，也没有携带足以让陌生客户端独立复算的完整证据。

Scott Rose 与 Roy Arends、Rob Austein、Matt Larson、Dan Massey 共同署名 RFC 4033、4034 和 4035。五位作者及标准化共同体没有要求一个小字段承担普遍证明的角色，而是分别界定验证在哪里发生、结果怎样交给下一方，以及下一方仍需具备什么信任条件。

四种验证状态无法塞进一个开关

RFC 4033 将安全感知解析的总体结果分为 Secure、Insecure、Bogus 与 Indeterminate。Secure 意味着数据能沿有效链路连接到接受的信任锚；Insecure 是可被证明未签名的状态；Bogus 指本应通过验证却未能通过检查的数据；Indeterminate 则是现有信息或政策无法归入前三者。

AD 并没有编码这四个值。它被设置时，传递的是解析器规则要求的正面认证结果；它未被设置时，原因可能不止一个。数据可能正确地处于 Insecure，解析器可能根本不验证，查询也可能没有以要求返回该标志的方式发送，还可能存在其他状态或本地政策。把 AD=0 一律翻译成“DNSSEC 失败”，反而抹掉了协议刻意保留的分类。

RFC 6840 又补充了查询端的语义。请求方可以在查询中设置 AD，表明自己理解并希望获得这一标志，即使它没有通过 DO 位要求同时返回 DNSSEC 记录。验证解析器应当只在验证条件满足、且查询带有 DO 或 AD 时，于响应中设置 AD。因此，同一份已经验证的数据，对没有声明这两种能力的客户端可能不带该位。缺失本身不能还原解析器内部的状态。

正面的 AD 也不表示所有解析器一定得出相同答案。信任锚和本地政策可能不同，时间、缓存以及所见响应也会变化。DNSSEC 提供验证机制；这个位只报告某一解析器如何把机制应用于这一次响应。

这个位保护不了承载它的数据包

假设攻击者能够修改 stub 与递归解析器之间的流量。要欺骗盲信 AD 的客户端，攻击者不必伪造任何 DNSSEC 签名，只要改动没有签名保护的头部位、替换响应或干预传输信道即可。客户端随后信任的，是一项从未验证过传输来源和完整性的声明。

RFC 3655 在 DNSSEC 核心规范完成前就指出了这条边界：不理解安全机制的 stub 不得盲目信任 AD，除非它与可信、具备安全能力的递归解析器通过安全传输通信，或者采用消息认证。RFC 4033 延续了相同架构。把验证委托出去，意味着既要信任递归服务器，也要信任两者之间的信道。对于这一属性，关键是完整性和认证；保密并不是让结论可信的必要条件。

这两项要求不能互相替代。通往不可信解析器的认证信道，只能证明可疑答案确实出自那台解析器；一台值得信赖的解析器若经由可篡改信道抵达终端，也无法担保终端最终看到的内容。只有两者组合，委托验证才成立。

会自行验证的 stub 走的是另一条路。RFC 4035 要求它忽略收到的 AD，执行自身验证。它可以利用响应中的 DNSSEC 记录，但结论来自按自己的信任配置核验整条链。外部的 AD 可以作为观察值，却不能成为判定权威。

“可信解析器”是一种可核查的运营关系

这个词不应只是产品标签。客户端需要知道自己意图连接哪一台解析服务，用合适机制认证交换过程，并确认该解析器采用的是自己可接受的验证政策。仅仅配置了一个地址，不足以证明中途各环节完整保存了结论。

因此，把验证集中到递归服务不只是转移计算，也是在转移治理。解析器运营方决定信任锚、软件版本、例外处置、失败策略与缓存时限。客户端只消费摘要时，也继承了这些决定。集中式验证完全可能是合理架构，但 AD 不会消除依赖，只会把依赖压缩得更小。

Rose 的职业脉络说明这条边界为何仍然重要。NIST 个人资料将他的工作定位于互联网基础设施保护和安全协议。2026 年 3 月，NIST 发布新版《安全域名系统部署指南》，作者为 Scott Rose、Cricket Liu 与 Ross Gibson。这里的 DNSSEC 是一个需要持续运营的系统：区域签名只是起点，解析器配置、验证结论的安全使用和监测共同决定证据能否完整进入业务判断。

人物归因也需守住边界。Rose 是三份核心 RFC 的五位共同作者之一，不是 DNSSEC 的唯一发明者，也不控制各家实现。RFC 3655 和 RFC 6840 的作者群体另有其人。他在本文中的意义，是参与确立了一套长期有效的结构：认证有明确作用域，消费者必须知道自己收到的是谁的结论。

DNS 结论不是应用结论

即便 AD 计算正确，又经认证信道完整送达，它仍只抵达 DNS 数据边界。它能够支持“这些 RRset 在该解析器的 DNSSEC 信任链下得到认证”这一判断，却不证明 Web 服务器没有失陷、IP 地址没有恶意、证书符合政策、邮件收件人获得授权，更不批准某笔交易。

应用还会组合 TLS 身份认证、证书与名称核验、账户授权、时效要求、内容政策、业务规则和用户意图。有些协议刻意把 DNSSEC 认证记录作为更大决策的一部分，这是有价值的组合，但不能把证据边界合并。应用应能说明使用了哪项记录、哪个解析器结论、什么信道属性和哪一道后续检查。

审计日志若只保存 AD=true，就会把所有依赖抹平。更好的记录至少分三项：解析器的验证状态与政策、该状态向客户端的认证交付，以及应用如何采用或拒绝返回数据。最终动作出错时，调查者才能分辨是验证本身错误、结论在传输中被改动，还是应用给了 DNS 结果超出其范围的权力。

所以，Authenticated Data 位既不是装饰，也不是魔法。它是特定验证方针对特定 DNS 数据作出的一条紧凑陈述。严谨使用它，可以保留解析器已经完成的工作，而不把借来的信任伪装成端到端证明。

资料来源