IETF 118 会议期间，DNSOPS 工作组讨论的《DNS IPv6 传输操作指南》草案提出，权威服务器与递归服务器均应支持 IPv6，并将 RFC 3901 中的建议从“应具备 IPv4 可达性”升级为“应至少部署一台 IPv6 可达的权威服务器”且“区域至少应有两台双栈 NS”。作者指出，这种措辞强度的提升缺乏相应的运营数据支撑，且可能忽视 Happy Eyeballs 机制在实际解析路径中的缓解作用。
RFC 3901 与 3901bis 的关键分歧：
RFC 3901（2004 年）规定：每台递归服务器应为 IPv4-only 或双栈，排除 IPv6-only 递归；每个 DNS 区域应至少由一台 IPv4 可达的权威服务器提供服务，区域验证过程需确保子授权的 NS 至少有一条 IPv4 地址记录。3901bis 草案则建议：区域至少应有两台双栈 NS，且每个权威区域应至少由一台 IPv6 可达的权威服务器服务。原文未给出具体部署比例或失败案例数据，仅以“强烈措辞”替代了原有的务实折中。
SHOULD 与 RECOMMEND 的规范分量：
RFC 2119（1997 年，Scott Bradner 著）定义 MUST、SHOULD、MAY 等关键词，并要求“仅在互操作性必需或限制潜在有害行为时使用”。草案将 IPv6 支持提升至 SHOULD 级别，实质上将其视为互操作性前提。作者质疑：自 2004 年以来，除 IPv6 部署率上升外，是否有协议层面的新证据证明 IPv6-only 权威或递归会导致解析失效？Happy Eyeballs 机制（RFC 8305）已在客户端侧通过并发连接、优先返回可用地址，隐含了对单栈故障的容忍，草案未论证为何必须在服务端强制双栈。
对运维与网络工程师的实际意义：
当前规范仍允许 IPv4-only 递归与权威共存，生产环境无需立即全栈改造。若草案定稿为标准，区域运营者需评估双栈 NS 的部署成本与 IPv6 解析失败的实际风险，而非盲目跟随“SHOULD”措辞。建议在部署前通过合成测试验证 Happy Eyeballs 在本地解析链路的表现，再决定是否满足新建议的双栈门槛。
原文: APNIC Blog（2023-11-17）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog