摘要

  • A6 可以从分别维护的 DNS 片段拼装 IPv6 地址，减少某些重编号修改；每一环也会增加查询、缓存状态、失败机会与管理依赖。
  • RFC 3363 把 A6 与二进制标签从 Proposed Standard 调为 Experimental，并让 AAAA 留在生产标准路径；文档状态变化不等于部署即时改变。

A6 的出发点并不荒谬。IPv6 地址的本地部分与供应商前缀可能按不同时间表变化。RFC 2874 允许叶区保存相对稳定的后缀，由上游区维护前缀，解析器在查询时把它们合成。前缀变化时，不必逐条改写所有叶记录。

可组合性同时制造串行依赖。解析器读取一个 A6 记录后，可能还要追踪前缀名称，再询问另一权威服务器，甚至继续下一环。每份回答都有自己的 TTL、缓存、运营者与失效方式。前三段正确，不能弥补第四段超时。

2002 年 8 月发布的 RFC 3363 把这种代价转成标准行动。它是信息类文档，更新 RFC 2673 与 RFC 2874，并把两者从 Proposed Standard 调为 Experimental。文档记录 DNSEXT 与 NGTRANS 讨论所形成的判断：AAAA 当时更适合生产；A6 仍有值得理解的性质；其收益是否高于成本和风险尚不清楚。

RFC 3364 保存了 A6 最强的论据。A6 能在查询时表达可能突然变化的前缀，静态 AAAA 无法以同样方式组合。自动生成 AAAA 可以实现部分效果，但只是把依赖移到配置与发布系统，并未让重编号免费。

RFC 3363 关注查询实际要走多远。它推断，在回答未被缓存时，N 环 A6 链的耗时大致随 N 增长；失败概率也会随子查询数量大致增加。这是架构推断，不是全球实测，也没有给出普遍适用的倍数。

跨组织边界使风险更难收敛。一些有吸引力的 A6 方案会指向区外、甚至另一机构管理的前缀。每一方都可能维护好自己的局部记录，整体仍会因为一个离职的联系人、过期委派或无人负责的链接失败。不同缓存还可能用不同时间切片拼出不同地址。

AAAA 选择另一种成本。128 位地址完整放在一条记录里，重编号时需要改更多记录，但解析依赖更清楚、更有边界。RFC 3363 建议让 RFC 1886 留在标准轨，后来的 RFC 3596 则规范了成为常用路径的 AAAA 与 IP6.ARPA。

反向树里的二进制标签也经历回撤。RFC 2673 定义了 RFC 1035 之后第一种新标签类型。部署发现，不支持它的 DNS 服务器可能把查询视为畸形。十六进制文本标签已能表达预期委派结构，因此二进制标签也转为实验状态。反向树根由 RFC 3152 另行处理。

这是标准化的减法，而不是抹除。实验状态保留了设计与研究空间，同时不再要求生产兼容集合承担尚未证明的复杂度。

必须把各层凭证分开。文档降级不能删除解析器代码，代码支持不能证明区域发布，单个片段发布不能证明整链解析，解析出地址也不能证明服务可达。RFC 4472 后来继续记录 AAAA 路径上的 IPv6 DNS 运维问题；简化只减少一类依赖。

RFC 3597 还说明，通用搬运未知资源记录与理解新标签语法是不同能力。服务器可能保存不理解的数据，却仍无法解析陌生名称结构。

今天的 IANA DNS 参数表证明标识与状态的保管，不提供历史部署普查。本文公开使用 Lu Heng 的两篇文章作为镜头：“Minimum Initial Specification”帮助比较最小共同层与动态组合；“On Reality Layers”要求把标准状态、代码、区域、缓存与结果分别记账。

历史教训不是反对优雅，而是承认可组合性会消耗可靠性。每个可以独立替换的片段，也会成为必须在正确时刻可用的一方。RFC 3363 的退让保留实验，却不再假定额外片段没有成本。

来源