摘要

  • RFC 5855 为 IPv4 和 IPv6 反向区指定了不同的服务器名称空间，并在父区提供 glue 地址，使两棵反向 DNS 树可以交由不同的服务器组运营。
  • RFC 并未要求运营者必须分开。选择权属于 IANA 的职能范围；两个不同的名称本身不能证明路由、站点或故障域彼此独立。

人们通常把反向 DNS 想成“由 IP 地址查回名称”，但解析器在请求 PTR 记录之前，必须先沿着委派链找到相应反向区的权威服务器。服务器发现是查询路径的一部分。如果解析器无法获得名称服务器的地址，它会在接触 PTR 记录前就失败。

这正是 RFC 5855《IPv4 和 IPv6 反向区的名称服务器》所处理的路径问题。该文件于 2010 年 5 月以 Best Current Practice 发布，由 Joe Abley 与 Terry Manderson 共同署名。RFC 描述了当时的运行方式：IN-ADDR.ARPA 由一部分根服务器提供服务；IP6.ARPA 则由 APNIC、ARIN、ICANN、LACNIC 和 RIPE NCC 运营的系统提供服务。

提案为两棵反向树分别建立稳定的服务器名称空间：IPv4 名称位于 IN-ADDR-SERVERS.ARPA 之下，IPv6 名称位于 IP6-SERVERS.ARPA 之下。父级 ARPA 区保存相应的 IPv4 与 IPv6 glue 地址。这样，解析器拿到委派时就能继续访问服务器，而不必再发起一次递归查询，先去查明 IP6.ARPA 名称服务器的地址。

RFC 中的查询示例说明，少一段路径为何有实际意义。旧的 IP6.ARPA 委派可能没有在附加区段携带 glue。解析器于是要先解析其中一个名称服务器的名字，之后才有办法查询反向区。RFC 5855 把这项额外依赖放到委派设计上处理：使用专属名称，并由 ARPA 父区提供地址，使解析路径更直接、更容易检查。变化不显眼，却位于每次反向查询都必须经过的位置。

文件还把编码开销纳入设计讨论。附录比较了 IPv6 反向服务器名称在 DNS 线路格式中的长度：一个历史例子使用 74 字节，拟议的 IP6-SERVERS.ARPA 名称组使用 39 字节。这是名称编码长度，不是实测延迟，也没有证明查询失败率下降。它展示的是重复后缀可以在频繁传送的 NS 委派里压缩，同时让解析器接下来要找的服务器地址更明确。

分别命名也为更深一层的运营隔离留出了空间。RFC 5855 说，IPv4 与 IPv6 反向区可以委派给不同的名称服务器组，以降低一个地址族的故障影响另一个地址族查询的风险。但这只是许可，不是要求。文件没有规定两组必须属于不同公司、机房、转接服务商或路由路径。它甚至指出，在同一地址族内，服务器命名空间与对应反向区也可以同生共死。名称边界提供了选择，却不是物理或网络隔离的证据。

RFC 对剩下由谁决策也写得很直接。IANA 一节记录了新的委派和 glue，但把运营者选择排除在文件范围之外，并将其归于 IETF–ICANN 谅解备忘录下的 IANA 职能。RFC 5855 因而规定了一套技术接口，也明确了接口之外的责任移交。它既不证明今天每台服务器由谁运营，也不证明服务器组之间存在多大程度的独立性。

Manderson 的经历恰好能从两侧看见这条边界。他与 Joe Abley 共同署名 RFC；IETF Datatracker 也把该 RFC 列在他的作品中。后来的 RSSAC 历史记录显示，他于 2013 年接手 ICANN DNS Operations 部门的管理；2014 年，这支团队并入 ICANN IT，并改名为 DNS Engineering。ICANN 的访谈将他介绍为该部门负责人。这些资料证明他有 DNS 运营经验，但不能据此说他独自设计、选择或部署了 RFC 所涉及的运营者。

这种证据界限使 RFC 更有分析价值：它区分了协议能够命名的对象，以及运营安排必须作出的选择。若要判断 IPv4 与 IPv6 反向 DNS 是否真的能独立失效，工程师需要检查实际 NS 组、glue、托管位置、路由和响应行为。标准里的两个后缀并不能回答这些问题。

来源