摘要

  • RFC 2182 建议多数机构级区域配置三个列名服务器，但前提是至少一个在地理和网络拓扑上与其他服务器充分分离；“三个”不是独立性的证书。
  • 如果被公布的地址对大量解析器不可达，它不会增加可靠性，反而会让分散在各处的解析器重复探测、重传和等待超时。
  • 冗余还取决于持续维护的状态。NS 记录、权威响应、相同 SOA 序列号和完成的区域传输分别证明不同环节，任何一个都不能单独证明所有副本新鲜一致或业务最终可用。

区域文件里有三台，机房里只有一个故障

委派里列出三个名称服务器，看起来已经有了冗余。可三台机器放在同一个房间，接同一段局域网、同一路供电和同一条外链。一次局部故障就能把整个集合一起带走。

RFC 2182 正是为这种错位而写。它在 1997 年 7 月成为 BCP 16，从一开始就没有把 secondary 当作装饰性副本。多个权威服务器的意义，是在其中一个不可用或不可达时，仍让世界各处的客户端取得区域信息。只有当这些服务器不会同时消失，数量才有意义。

文件要求同时考虑两种分离。地理分离防范建筑、房间和区域性供电事件；拓扑分离防范链路、路由区段或服务商故障。两地机房如果仍依赖同一条上游路径，远并不等于独立。两个网络品牌如果落在同一供电和控制面，也不构成两个故障域。

因此，文中最常被引用的数字带有明确条件。两台经过谨慎布置的服务器有时足够，但任何一台长期离线都会让区域只剩单点。RFC 建议多数机构级区域使用三个列名服务器，至少一个要与其他服务器相距甚远；要求更高时可以使用四个或五个。它从未说过，三个 NS 名称本身就能证明韧性。

不可达的备份，把失败交给所有解析器重演

接着，BCP 把问题从位置推进到广告。NS 名称所解析出的地址，应当能被收到这些记录的解析器群体访问。藏在防火墙后、依赖间歇连接或只在内部可用的接口，不会因为出现在 DNS 中就变成全球备份。

代价会扩散。解析器事先不知道一个地址是永久不可达，只能发出请求、等待，并因为沉默也可能只是丢包而重复尝试。应用或用户可能在探测结束前就放弃，于是一条坏地址制造出整个区域不可用的外观。其他网络的解析器随后还会重新付出同样成本。

1997 年原文写道，未得到结果通常不会被缓存。编辑性勘误 4631 已将这句话收窄：RFC 2308 之后，负面结果可能依据服务器行为和本地配置被缓存。历史细节需要修正，但运维结论没有消失。公布不可用的权威地址，仍会把探测、等待和重试成本转嫁给无权修复拓扑的解析器。

可达性还必须经受 referral 被继续转发。最初收到 NS 信息的解析器可能把它交给另一个解析器，因此只对第一处观察点可用并不够。依据 RFC 2181，地址 RRset 要整体返回；运维方不能悄悄删除其中一个坏地址，也不能只给它一个较低 TTL 来伪装差异。内外网络具有不同可达性时，需要明确设计不同视图和名称，而不是发布一份误导性的全球清单。

服务器越多，也可能越难知道哪里坏了

既然两台可能不够，为何不列二十台？RFC 2182 同样否定这种捷径。每增加一台服务器，响应报文会更大，带宽需求会上升，也更接近 DNS 报文大小边界。更重要的是，每个 secondary 都多出一份配置、传输关系、软件实例和维护责任，也多一个失配后无人发现的机会。

文档区分列名服务器与 stealth server。一个站点可以让多台本地机器都保持权威副本，使外部通信中断时内部查询仍有答案，但只把其中一两台公布到全球。若把所有本地副本都列入 NS，站点共同链路一旦断开，全世界就会无意义地轮流探测它们。本地价值不自动构成全球广告的理由。

合适的数量因此是一个运维优化，不是配额。太少的独立副本使服务脆弱；太多被广告的副本扩大协调和检测成本。数量应当由故障域及其可维护性决定。

副本只有在版本可信时才算冗余

RFC 2182 最后讨论了一个把冗余拉进时间维度的问题。secondary 依靠区域 SOA 记录里的序列号判断是否需要更新。primary 每次修改后都必须增加序列号。如果运维人员误把序列号设得过大，直接改回较小数字可能让已经见过大值的 secondary 把修正当成旧数据。

正确修复是分阶段前进。运维人员选择符合 RFC 1982 序列号算法的递增值，等待所有相关 secondary 采用当前阶段，再跨越回绕边界到达目标小值。示例里的具体数字并不是核心；核心是逐阶段核验，绝不假设。

这条流程把多个收据分开。NS 记录只能证明一个名称被公布；查询响应证明一个进程在某个时刻回答；SOA 查询证明某个观察点看到的序列号；区域传输完成证明传输步骤结束。它们都不能独自证明新区域已经被完整装载、所有工作进程同时切换、服务器位于独立故障域，或最终应用可访问。

安全章节也保持同样边界。BCP 没有声称减少或增加既有 DNS 安全问题，但提醒 secondary 一旦被攻陷，在某些情形下可能危及该域内主机。运维独立性只有在新增机器和运维方也足够可信时，才会增加可用性。

RFC 2182 的持久贡献，是把 DNS 冗余从资产清单改写为证据问题。可以数服务器，但还要画出哪些因素会同时失败；可以发布地址，但要从真实使用它们的网络去测试；可以复制区域，但要在变更后观察版本推进与实际服务状态。区域文件描述权威，运行中的系统必须另外证明可用。

来源

  1. RFC 2182：Secondary DNS 服务器的选择与运行
  2. RFC 2182 信息页
  3. RFC 1982：序列号算法
  4. RFC 2181：DNS 规范澄清
  5. RFC 2308：DNS 查询的负缓存
  6. RFC 2182 勘误