摘要

  • DNS 的 Authoritative Answer 位对应查询名，或 Answer 区中第一个所有者名；同一应答里的别名目标、Authority 数据、胶水记录和其他 Additional 数据可以来自不同证据边界。
  • 可复核的解析收据要按 RRset 保存所有者、类型、分区、区域切点、缓存来源与 DNSSEC 状态，并串起后续查询，不能用一个报头位替整包数据证明权威性或真实性。

解析器查询 shop.example。应答服务器管理这个名字所在的区域，于是返回一个 CNAME；它又从缓存中带出目标地址，并在 Additional 区附上一条可以省去下一次查询的地址。报头中的 AA 为 1。

若观测平台只存一行“整包权威”，问题会在以后暴露。目标区域的直接应答给出了另一个地址，平台却无法说明差异来自区域更新、缓存时点还是先前的附加信息，因为三个 RRset 的来路早已被一个布尔值抹平。

这是用来检验证据模型的假设场景，不是现实事故指控。

一个比特只有一个锚点

Paul Mockapetris 撰写的 RFC 1035 把 AA 定义为应答中的 Authoritative Answer 位：服务器声明自己对 Question 区里的域名具有权威。标准随即处理了别名难题——Answer 区可能出现多个所有者名，因此 AA 对应与查询名匹配的名字，或 Answer 中第一个所有者名。

这句话没有说“报文里每个记录都由同一权威直接给出”。AA 不是贴在每个 RRset 旁边的位图，而是对回答路径起点的描述。把它扩展到所有名字、所有分区和所有来源，是数据库后来添加的推论。

RFC 1034 展示了应答为何天然会混合来源。权威区里若匹配到 CNAME，服务器把它放进 Answer，改写 QNAME 后重新处理；遇到委派，则把 NS 放入 Authority，再把可用地址放进 Additional，这些地址可能来自胶水、权威数据或缓存；发送前还可以加入本地已有的有用记录。

所以，“同一份报文”只是传输事实，并不自动构成“同一种证据”。

分区保留上下文，却不颁发信用等级

RFC 1035 让三个分区承担不同功能：Answer 回答问题，Authority 指向权威服务器，Additional 携带相关但并非严格答案的信息。记录分区可以阻止第一次失真，却仍需继续追问所有者、区域与来源。

在区域切点上，父区可能必须提供子区名字服务器的地址胶水，否则解析器会陷入先找服务器还是先找地址的循环。胶水很有用，有时还是继续解析的必要条件，但它不是子区自行发布的地址断言，也不会让父区取得切点以下名字的权威。

RFC 2181 把信任次序拆开：除胶水外的主区域文件与区域传送数据、权威 Answer、权威应答里的 Authority、胶水、非权威 Answer、Additional，各自处在不同层级。新取得的权威答案可以替换此前作为 Additional 缓存的 RRset，反过来却不能只因缓存里已经有值就压过更强来源。

丢掉这个等级，缓存就会无意中“漂白”出处。一条最初只是导航辅助的地址，后来从缓存作为 Answer 返回，看起来仿佛获得了权威资格；其实它在内存里停留的时间只改变 TTL，没有改变发布者。

别名链会跨越权威边界

RFC 2181 给出最强反例：对别名的权威应答中，只有描述别名的记录必然具有权威性，后续记录可能来自缓存。若客户端需要规范名的权威数据，应当重新查询那个名字。

RFC 6604 又针对 CNAME 与 DNAME 链重申：链中每段答案的权威状态可以不同，AA 仍由 Answer 的第一个所有者名决定。

因此，shop.example 的权威服务器可以正确声明它指向 service.vendor.test，也可以顺带提供缓存中的目标地址。前一个断言属于本区域，后一个地址却没有因此成为供应商区域的权威答案。真正跨过边界的是下一次查询，它应当拥有独立的服务器、时钟、报文和验证收据。

审计模型应把别名保留为边：输入名、CNAME 或 DNAME RRset、来源区域、来源应答、下一个名字和随后的查询。只存最终地址适合快速缓存，却无法回答“谁对哪个名字说了什么”。

权威性不是密码学真实性

“权威”一词还容易引出第二次越界。RFC 6604 明确指出，DNSSEC 并不保护 AA 报头位。TSIG 或 SIG(0) 可以保护查询者与服务器之间的事务；DNSSEC 则让验证者针对 RRset 构造信任链。这是两套不同收据。

RFC 4035 要求解析器逐个 RRset 判断 Secure、Insecure、Bogus 或 Indeterminate。结果取决于 RRSIG、DNSKEY、DS、信任锚、否定证明和本地策略，AA 不会直接生成其中任何一种状态。

AD 位也不是 AA 的加强版。支持 DNSSEC 的服务器只有在认为 Answer 与相关 Authority RRset 都真实时才能设置 AD；客户端仍需证明自己信任递归服务器与传输通道，或执行本地验证。Additional 不会因为报头里有 AD 就自动进入同一证明范围。

同一报文完全可能同时满足这些事实：第一个名字的 AA 正确；CNAME 为 Secure；目标地址为 Insecure；胶水位于 Additional；到中间解析器的通道没有认证。把五个维度压成一个绿色“权威”标签，不是摘要，而是证据丢失。

Mockapetris 的名字能证明什么

Internet Hall of Fame 的人物资料 记载，Paul Mockapetris 于 1983 年在南加州大学 Information Sciences Institute 提出 DNS。RFC 1034 与 RFC 1035 则保存了他的作者身份。资料页上的公开历史头像也是本文编辑肖像的身份依据。

这些证据不代表他经营任何当代权威服务器、拥有某个区域或批准某项部署。后续 RFC 是集体标准成果。把人物放回正确位置，正是本文论点的一部分：发明分布式命名体系的人留下了一项有边界的字段，而不是一枚覆盖未来所有 DNS 数据的私人印章。

建立 RRset 收据，而不是给包贴标签

记录从查询元组开始：QNAME、QTYPE、QCLASS、递归意图、DO 与 CD 选择、事务标识和发送时间。随后冻结应答原始字节、端点、传输方式、接收时间及事务认证证据。

再按 RRset 拆分：所有者、类型、类别、所在分区、观测 TTL、区域切点、bailiwick、已知的数据来源、缓存进入与过期时点。若客户端无法知道服务器内部究竟用了区域文件还是缓存，就保留“不明”，不能让 AA 替它补答案。

AA 自己单独记录：原始查询名、Answer 首个所有者、响应服务器及其权威区域。每次 CNAME、DNAME 或委派都生成一条通往后续查询的关系。父区 NS、胶水、子区直接应答互相连接，但不合并为一项。

最后按 RRset 保存 DNSSEC 状态、签名、DS/DNSKEY 路径、信任锚、验证时间和失败理由。收到的 AD 是上游陈述，不代替本地验证。应用真正使用结果时，还要记下所用 RRset 与缓存版本。

结论于是可以保持精确：这台服务器针对第一个名字设置了 AA；这个 RRset 来自这个分区与来源；验证器赋予它这一安全状态；后续查询才建立了下一个名字的权威来源；应用使用了这一版本。AA 仍然有价值，因为它终于不再替整包数据作证。

来源