摘要

  • AFRINIC 在 8 月 19 日的 ccTLD 更新说明中，把注册局服务器的 IPv6 测试推成了其下所有站点的 IPv6 可达性结论。DNS 查询采用的传输协议，不等于返回地址记录的协议版本。
  • 双栈递归解析器提供了一条明确的反例路径；只有上游迭代也完全依赖 IPv6、且没有可用替代路径时，仅能经 IPv4 访问的权威服务器才可能成为真实阻碍。本篇未执行实测解析或应用故障测试。

手机用 IPv6 问路，不代表替它问路的解析器也只能走 IPv6。中间这台机器可以先用 IPv4 查询父域，取得子域的委派信息，再经可用路径向子域权威服务器取回 AAAA 记录。它把结果通过 IPv6 交给手机；手机随后用 IPv6 连接另一个确实可达的应用端点。

这是一条有条件的协议路径，不是对某个非洲国家网络做出的实测结论。它足以说明，父域的 IPv6 DNS 能力与子域站点的 IPv6 访问能力之间，不能直接画等号。

AFRINIC 的 IPv6 与 DNSSEC 部署监测工具 增加了国家和地区代码顶级域名，即 ccTLD 的检查页。2.14.0 更新说明标注的日期是 2026 年 8 月 19 日。它分别检查注册局域名服务器是否有 IPv6 地址、能否经 IPv6 响应，以及能否实际回答 DNS 查询。这种拆分有价值：有地址、回应探测、完成 DNS 交换，并不是一回事。

说明文字却把下一步跨得太远。它称，如果注册局服务器不能通过 IPv6 到达，其下任何域名也就不能通过 IPv6 到达，不论单个域名配置得多好。即使把范围严格限定在真正委派于这个 ccTLD 之下的名字，这个普遍结论也不成立。DNS 层级规定的是沿哪条委派链寻找权威信息，不是要求整条链和最终应用连接采用同一版本的 IP。

AAAA 记录没有继承查询的道路

2003 年 10 月发布的 RFC 3596明确区分查询传输与记录内容。DNS 交换走 IPv4，仍然可以查询 IPv6 地址记录；走 IPv6，也可以查询 IPv4 地址记录。承载问题的数据包，不决定问题所问的地址类型。

这里也不能再添一个误解：ccTLD 服务器通常提供的是委派指引，并不必然直接返回网站最终的 AAAA。递归解析器继续访问子域的权威服务，才取得相应地址。在前述反例中，各个必要权威阶段都有可用路径，数据有效，应用端点又有独立可用的 IPv6 路径。父域这一段使用 IPv4，不会单独阻断手机最后的 IPv6 连接。论证不需要借助已经缓存的回答。

2006 年 4 月的说明性文件 RFC 4472再次强调传输与所查记录的独立性。向权威服务器提问的机器，往往不是最终使用地址的那台机器。解析器有自己的接口和上游连通条件，不能被当作客户端传输协议的一根延长线。

反方向同样不能偷换。拿到 AAAA，不等于网站已经能用 IPv6 访问。路由、过滤、服务监听以及到应用的路径仍可能出问题。父域成功回答 DNS，也没有替这些环节完成测试。

哪一种依赖确实值得担心

AFRINIC 的担忧有一个很强的成立场景：解析器进行迭代查询时，上游只使用 IPv6，而必要的某个权威服务器只在 IPv4 上可达。若没有可用的转发、转换或其他替代路径，解析确实可能在这一段停住。

2004 年 9 月的 RFC 3901讨论了直接解析与转发到双栈递归服务的区别。不能把其中的历史建议包装成 2026 年新出台的“禁止纯 IPv6 客户端”规则。面向客户端的服务使用 IPv6，与解析器向权威服务查询时只能使用 IPv6，是两个不同条件。

监测工具自身也写出了应当保留的边界：探测来自非洲的一个位置；实际 DNS 回答比 ping 更有说明力；后续 2.15.0 又增加了较大的签名回答和委派一致性检查。检查越来越细，并不让单个观察位置变成全球视角。

本篇在 9 月审视的是 8 月发布的说明，不是报道一项 9 月新功能。更新日志里的旧计数也不是本篇测出的当前数据。没有执行 DNS 查询、没有测试应用，更没有证实一国故障或服务器现在失效。应当保留有用的 ccTLD 检查，把结论收回到它实际测量的依赖上。