摘要

  • DNS 交换所使用的 IP 版本，不决定所查询地址记录的家族：AAAA 查询可以经 IPv4 传输，A 查询也可以经 IPv6 传输。
  • RFC 3596 加入 128 位 AAAA 记录，并调整 DNS 的若干响应规则；它扩展的是名称关联的数据，而不是把 DNS 查询绑定到某种网络传输。

“IPv6”指的是哪一层

设想解析器把 DNS 问题装进 IPv4 数据包发送：“这个名称有哪些 AAAA 记录？”IPv4 首部说明这条消息如何抵达。问题中的类型则要求 IPv6 地址数据。两者并不冲突。RFC 3596 明确规定，查询资源记录所用的 IP 版本，与记录所代表的协议版本相互独立。RFC 4472 把这一点写成操作含义：AAAA 可以通过 IPv4 查询，A 可以通过 IPv6 查询。

这种区别很容易被混为一谈，因为两层都叫 IPv4 或 IPv6。一层是请求的网络封装，另一层是 DNS 资源记录里的数据。如果服务器根据观察到的传输路径决定返回什么记录，DNS 中的事实就会受询问路径影响；而那条路径本身并不能说明哪些地址属于这个名称。

反过来也是如此。IPv6 传输并不迫使解析器查询 AAAA；它也能承载 A 查询。抵达服务器的数据包使用哪种地址家族，也不能证明查询者能够使用返回地址。标准定义的是这两层彼此独立，并不保证后续可达性或应用连接成功。

增加记录，不是更换道路

早期 DNS 模型用 A 记录保存 32 位 IPv4 地址。RFC 1886 加入 AAAA，用来保存 128 位 IPv6 地址，并定义反向查询机制。随后 RFC 3152 把反向树从 IP6.INT 改到 IP6.ARPA。RFC 3596 将这些变化合并，保留原有 IPv4 支持，并明确 AAAA 的类型码为 28，记录中存放一条完整 IPv6 地址。

这是扩展 DNS 内部的数据模型，不是为 DNS 消息另造一种 IPv6 传输。问题和响应仍然走既有的 DNS 交换机制。IP 传输可以是 IPv4 或 IPv6，与问题要求 A 还是 AAAA 无关。DNS 不需要因为可以保存两类地址，就拆成“IPv4 DNS”和“IPv6 DNS”两个互不相通的名称空间。

当时确实还有另一种设计。A6 记录可以把地址拆成若干部分，再通过 DNS 链接起来；在前缀变化时，这种做法有机会减少部分更新。不过，灵活性也意味着链式查询和额外依赖。RFC 3363 记录了保留 AAAA 的标准轨道地位、将 A6 和 Bit Labels 转为 Experimental 的决定；RFC 3364 则梳理了两种路线的取舍。因此 RFC 3596 选择的是容易直接读取的完整地址记录，不是对重编号或 IPv6 部署的万能解法。

响应规则也需要跟着调整

RFC 3596 还更新了 NS、SRV 和 MX 查询的附加区处理：本地可用的相关 A 与 AAAA 地址都可以作为附加数据返回。AAAA 查询本身则不会触发附加区处理。直接请求一个 RR，和在另一种响应中附带地址，是两种不同的协议行为。

“服务器可以附带”不等于响应证明所有地址都存在。本地数据可能缺失，缓存可能不完整，DNS 记录也不是探测包。RFC 4472 特别提醒，不应仅凭查询所走的传输家族来选择或过滤回答；这条路径常常与客户端需要哪类记录并无关系。若据此压掉一个家族，同一名称就可能因为查询路径不同而呈现不同事实。

AAAA 响应只能证明 DNS 为某个名称返回了 IPv6 地址数据。它不能证明当前解析器存在通往目标的 IPv6 路由、该地址上有服务监听、防火墙允许会话、DNSSEC 已验证记录，或应用已经连接。通过 IPv4 收到 AAAA 响应，也不能说明之后连接服务会使用哪种 IP 版本。

让共存关系保持清楚的边界

RFC 3596 的历史常被概括为“DNS 有了 AAAA”。它还有一项更基础的贡献：在互联网增加另一类地址的同时，保留了一个不变量——传输查询的数据包，与应答中记录的地址家族，是两个独立维度。过渡时期，IPv4 路径可以取回 IPv6 数据，IPv6 路径也仍可取回 IPv4 数据；名称空间不必因此分裂。

这些 RFC 规定了机制及预期边界，却没有说明实现遵守得多普遍、某个具体解析器表现如何，也没有证明同一名称的 A 和 AAAA 同时可用。回答那些问题，需要另行提供实现、配置、测量和可达性证据。

来源： RFC 1034；RFC 1035；RFC 1886；RFC 3152；RFC 3363；RFC 3364；RFC 3596；RFC 3597；RFC 4472。