摘要

  • RFC 3152 选择 IP6.ARPA，请求 IANA 依 IAB 指示完成委派，并要求下层名称沿 IPv6 地址分配层级继续委派；它没有替每个前缀建立反向区，也没有自动更新客户端。
  • 废弃 IP6.INT 的含义是“不适合新实现”并应有序退出，而非发布当天全球断开。2005 年后续文件另设停用节点，正说明标准决定与运行切换不是同一事件。
  • 完整证据必须区分 RFC 状态、父子委派、PTR、实际查询后缀、缓存、DNS 响应、验证状态与应用行为。反向名称不是主机身份凭证。

一棵树先成为正确答案，旧查询才逐步离场

IPv6 需要像 IPv4 的 IN-ADDR.ARPA 一样，从地址构造 DNS 查询键。早期文件把这项工作放在 IP6.INT。与此同时，IAB 正把 .ARPA 确立为互联网技术基础设施命名空间。RFC 3152 用极短的篇幅处理了两条历史线的交会。

它更新五份 RFC 中对 IP6.INT 的引用，请求 IANA 按 IAB 指示委派 IP6.ARPA，并规定区内层级要与 IPv6 地址空间的分配相称。区域互联网注册管理机构应取得与其地址资源相对应的名称空间。

但文件没有宣称运行世界已经同步。它特意解释“废弃”：旧用法不适合新实现，并可能以有序方式逐步退出。已经安装的库仍可能生成旧后缀，缓存仍可能保留旧答案，运营者也可能在过渡期同时维护两棵树。

这不是标准失效，而是分布式迁移的正常形态。共同方向可以先确定，执行者再按各自发布、委派和运维节奏收敛。

“完成委派”并不等于“已经有数据”

委派常被想象成一个总开关，实际却是一条控制链。IETF 确定技术约定，IAB 给出基础设施命名空间方向，IANA 负责高层委派，RIR 按地址分配接收子树，地址持有者和 DNS 运营者继续管理更低层区域与 PTR。

一个月后的 RFC 3172 把 .ARPA 定义为用途受限的基础设施域，并记录 IP6.ARPA 由 IANA 管理、再依 IPv6 分配向区域注册机构下放。名称层级映射数字资源的权责结构。

映射不等于证据互换。地址已经分配，不能证明反向委派存在；父区已有 referral，不能证明子区可用；子区权威回答，不能证明目标 PTR 已发布；PTR 存在，也不能证明其目标名称正向返回原地址。

因此，资源分配收据、DNS 委派收据、区域内容和查询轨迹必须分别保存。把它们压进 reverse_dns_ready=true，会抹掉系统真正的责任边界。

查询键正确，结果仍可能完全不同

RFC 3596 后来把稳定形式纳入 IPv6 DNS 标准：把 128 位地址拆成十六进制半字节，反序排列为逐级标签，并加上 IP6.ARPA。正确生成这个 QNAME，只能证明软件问对了命名空间。

查询仍可能遇到 referral、NXDOMAIN、SERVFAIL、超时、未验证答案、已验证答案或缓存值。每一种状态都对应不同环节，不能简化为“解析成功或失败”。

PTR 也是区域运营者发布的一条 DNS 数据。它不能证明设备所有权、连通性或访问资格；它也不保证 PTR 返回的名称再做 AAAA 查询时包含原地址。有的应用执行正反向一致性检查，有的只把字符串写进日志。RFC 3152 没有把任何一种应用政策变成身份认证。

迁移因而有两个正交方向：软件要学会查询新树，权威链要在新树中提供正确委派与数据。任一方向都可能先走一步。

共存降低切换成本，也会隐藏答案来源

让新旧树短期重叠，避免了要求全球同日升级。新客户端可以优先问 IP6.ARPA，旧客户端继续问 IP6.INT，运营者也可以暂时双写。

代价是可观察性变差。若解析器静默 fallback，用户看到一个名称，却不知道哪棵树提供了它。两棵树都返回结果，也不代表结果相同。父区刚增加委派后，客户端仍可能被旧的负缓存挡住。

迁移记录必须包含精确 QNAME、解析器与版本、缓存命中、fallback、逐级 referral、最终权威服务器、RCODE、RRset、TTL 和验证状态。缺少这些字段，“反向 DNS 正常”只是未经拆解的结论。

后续时间线说明这种重叠确实存在。RFC 3596 在 2003 年把 IP6.ARPA 吸收到标准轨 IPv6 DNS 规范，并取代 RFC 1886 与 RFC 3152。RFC 4159 又规定自 2005 年 9 月 1 日起，符合标准的 IPv6 实现不应再使用 IP6.INT，同时要求 RIR 与社群安排停止注册支持。2001 年决定了方向，运营退出仍需要后续协调。

文件被取代，选择的基础设施却留下来

“RFC 3152 被 RFC 3596 取代”很容易被误读成 IP6.ARPA 也被淘汰。事实相反：后者把 3152 的变更吸收进更完整的规范，新树由此成为稳定结果。

周边设计也在分开演化。RFC 3363 把 A6 与 Bitstring Label 移向实验状态并推荐 AAAA；RFC 5855 后来为 IPv4 与 IPv6 反向区的权威服务器建立稳定命名；RFC 9121 最终把已从 .INT 移除的 IP6.INT 记为历史基础设施域。

这些文件分别处理记录格式、命名空间根、权威服务和旧域退场。把所有变化压成一次“改名”，会丢失每个控制面的真实先后关系。

“没有新增威胁”绝不等于安全

RFC 3152 承认 IPv4 的地址到名称映射曾被欺骗利用，并说委派 IP6.ARPA 没有创造新的互联网安全威胁。这只是说换根没有新增威胁类别，不是为 PTR 背书。

RFC 3596 更明确地指出：若无适当安全技术，DNS 信息应被视为不安全；IPv6 扩展既没有制造新问题，也没有解决旧问题。DNSSEC 验证能证明数据处于一条 DNS 信任链中，却不能证明应用为名称赋予的社会含义、终端的当前控制者或授权关系。

安全判断必须分开记录：答案是否验证、由哪个区签名、是否检查正向对应、结果仅用于展示还是参与访问控制。一个看起来可信的反向名称，不能自动继承身份凭证的权力。

运行中的查询才测得到迁移状态

假设 IP6.ARPA 父子委派和 PTR 都正确。旧程序仍查询 IP6.INT，得到空结果；另一个程序查询新树，却持有建区前的负缓存；第三个程序取得新答案。三者面对同一标准，运行事实却不同。

运行代码优先不意味着 RFC 可有可无。RFC 3152 对应查询根和委派模型具有规范权威；运行轨迹回答这个客户端到底问了什么、走过哪些权威、收到了什么、应用据此做了什么。

最小初始规范的价值正在这里：选择共同根、发出委派请求、让层级跟随地址分配、宣布旧根退出，而不要求全世界原子升级。这种节制让迁移成为可能，也要求每个现实层只陈述自己能证明的部分。

互联网历史并不是一棵树瞬间替换另一棵树。IP6.ARPA 可以已经正确存在，而最后一批 IP6.INT 查询尚未消失；两句话可以同时为真。

来源