摘要

  • RFC 10001 取代 RFC 3901 的单侧保护思路：每个区域必须至少配置两台 IPv4 可达、两台 IPv6 可达的权威服务器；每个地址族的委派路径不得依赖另一个地址族，两边还必须提供等价 DNS 数据。
  • “域名能解析”必须写明来源地址族、完整委派链、实际监听与网络路径。双栈回退会隐藏单族故障；只有分别运行的探测和逐跳证据，才能说明权威在两条路径上都存在。

最容易被忽略的 DNS 故障，不是所有人都打不开，而是只有一部分人看不见。监控解析器先尝试 IPv6，等待后改走 IPv4，最终拿到正确答案。仪表盘只保存成功，超时的那条路径没有进入管理报告。对 IPv6-only 用户而言，权威服务器从未出现。

问题可能不在区域数据本身。父区缺少某个 NS 名称的 AAAA 胶水；子区与父区记录不一致；NS 放在兄弟域名里，而兄弟域的 IPv6 委派先断了；地址已经发布，DNS 进程却没有监听；或者 DNSSEC 大响应超过有效路径 MTU，被网络静默丢弃。每种故障在高层都可能只留下一个 timeout。

RFC 10001 于 2026 年 8 月发布，成为 BCP 91，并废止 RFC 3901。它把上述结果定义为地址族支持不匹配造成的命名空间分裂：递归解析器从根开始追随委派，最后遇到一组只能通过自己不支持的地址族抵达的权威服务器，于是无法继续。

名称仍在。记录仍在。缺失的是从这个运行环境抵达权威的路径。

委派链的每一跳都有不同权力

DNS 不是一张从名称直达答案的表。父区决定委派和胶水；子区决定权威数据与监听；兄弟域的运营者可能控制 NS 名称的另一段依赖；网络控制路由、过滤与分片；递归解析器控制选择、重试、转发和缓存；终端解析器还会从有限的递归服务器列表中挑选。

对于域内 NS，父区需要提供对应的 A、AAAA 胶水，子区本身也应保持一致。如果 NS 名称属于兄弟域，只有这个名称带 AAAA 还不够；兄弟域从根到自身也必须能通过 IPv6 完整解析。任何父区在目标地址族上不可达，都会连带切断其全部子区。

记录存在也不等于服务存在。RFC 10001 明确指出，A 或 AAAA 可以指向一个根本没有在该地址族上回答 DNS 的服务器。配置审计只能证明数据库状态，不能证明运行状态。

RFC 引用的 2023 年研究 《DNS 为纯 IPv6 世界准备好了吗？》 用完整链条而不是单个 AAAA 判断可达性，并发现故障具有明显提供商集中度。那些比例属于研究时点，不能当成 2026 年 8 月的普查；但它揭示了稳定的控制结构：一个提供商修正胶水可以恢复大量下游区域，同一个错误也可以把大量区域一起隔离。

RFC 3901 的历史边界发生了变化

RFC 3901 发布于 2004 年。彼时的首要目标，是避免新出现的 IPv6-only 权威服务破坏 IPv4-only 主机已经拥有的命名空间。它要求至少一台 IPv4 可达权威服务器，并允许 IPv6-only 递归解析器把查询交给双栈解析器。

RFC 10001 不再把连续性只放在 IPv4 一侧。每个区域必须有至少两台 IPv4 可达权威服务器和两台 IPv6 可达权威服务器；同一台双栈服务器可以在两边各计一次。IPv4 委派不能依靠 IPv6 才能完成，IPv6 委派也不能借助 IPv4 才成立。两种传输必须给出等价数据。

“至少两台”不是“至少两个地址”。如果四个地址都落在同一平台、同一任播体系、同一变更流水线和同一路由策略上，故障域仍可能只有一个。RFC 2182 关于地理、拓扑与运营多样性的要求没有因为双栈而消失。

“等价数据”也要单独验证。两个端口都响应，但服务不同区域版本、不同 RRset 或不同签名状态，依然是分裂。可达性与内容一致性是两项控制，不能用一个探针合并。

正确记录也会败给路径 MTU

委派完全正确，报文仍可能在网络里消失。DNSSEC 响应较大，UDP 报文可能触发分片；路径上的设备如果静默丢弃，解析器只会等待。TCP 也不是天然安全：PMTU 通知被过滤或携带错误数值时，服务器可能发出超过实际路径承载能力的段。

RFC 10001 采用 RFC 9715 的方向，要求尽量避免分片。UDP 可把上限控制在 1400 八位组，或采用更保守的 1232 八位组；后者加上 IPv6 头部后仍不超过 1280 的最小 MTU。TCP 对应可以选择 1388 或 1220 的发送 MSS。RFC 9210 则要求权威 DNS 支持 TCP 回退，不能把可靠性押在 UDP 分片上。

代价不会消失，只会移动。缩小 UDP 会增加 TCP 回退。RFC 引用的观测范围是 3%–5%，同时明确要求运营者监测自身负载。不能把这个范围复制成容量预算。真正需要保存的是 EDNS 声明值、实际响应字节、分片或丢弃点、TCP 建连、MSS、延迟和服务器资源消耗。

NAT64 解决可达性，也新增依赖

RFC 10001 建议递归解析器使用双栈，但允许单栈架构通过翻译或转发补足另一族。IPv6-only 解析器可以使用 NAT64 接触 IPv4-only 权威，或把失败查询交给真正的双栈解析器；IPv4-only 解析器也可以做对称转发。

这不是把依赖抹掉。由 PREF64 合成的 IPv6 地址仍指向 IPv4 目标，依赖翻译器、前缀发现与路径状态。RFC 9872 给出安全发现合成前缀的建议。证据必须标明原生、翻译还是转发，不能把 NAT64 结果统计成独立的原生 IPv6 权威路径。

转发还有循环风险。一台只支持 IPv4 的解析器与一台只支持 IPv6 的解析器，如果把自己无法完成的查询互相转发，遇到两边都不可解析的区域就会无限循环。正确目标必须能够自己完成双族解析，而且不得把工作送回来源。

终端侧同样会压缩选择。一些实现只能配置很少的递归服务器地址，多余项还可能被不确定地忽略。网络发出了四个地址，不代表客户端真的保留了四个。运行证据需要读取客户端实际状态。

建立两套路径账，再建立一套业务账

对每个关键区域，从真实 IPv4-only 与 IPv6-only 网络分别执行迭代解析。保存时间、探测点、解析器版本、每次父区委派、NS、A、AAAA、胶水、兄弟域依赖、实际接触的权威地址、UDP 与 TCP 结果、EDNS 大小、收到的字节、超时阶段、DNSSEC 验证和 RRset 指纹。

随后保存应用结果：选了哪个地址、是否连接、是否完成业务动作。DNS 回答不能替应用证明连接，连接成功也不能反向证明两个 DNS 地址族都正常。三者的权威必须分开。

IANA 权威名称服务器技术要求 属于另一项运营程序。RFC 10001 没有 IANA 行动，只建议 IANA 依照自身审查流程考虑更新。标准建议、程序文本、实际执行必须作为三个状态记录。

Heng Lu 的运行代码优先提供了判断准则：RFC 发布和记录存在都不是路径完成的证据。他的最小初始规范、本地未来决策与自愿采用只允许把互操作、安全与本地可验证规则放入共同层，其余实现、成本和变更决定留给运行系统的参与者。

“域名能解析”不是结论，只是少写了地址族、链条、路径和时间的句子。