摘要

  • RFC 2182 于 1997 年 7 月以 BCP 16 发布，把服务器布局视为运行可靠性问题。
  • 它建议多数组织域名配置三台服务器，但要求至少一台与其他服务器明显分隔。
  • 这是一项运行建议；NS 列表本身不能证明供电、路由、上游或实际可达性彼此独立。

一个区域可以公布三台名称服务器，却只有一条实际可用的应答路径。如果它们都依赖同一条接入链路、同一栋楼或同一套电源，一次故障就可能让整组服务器同时不可达。数字看起来有冗余，依赖关系却没有。

Robert Elz、Randy Bush、Scott Bradner 和 Michael Patton 在 RFC 2182《辅助 DNS 服务器的选择与运行》中处理的正是这个运行问题。IETF 于 1997 年 7 月将其发布为最佳当前实践 BCP 16。它不是一套新 DNS 协议，而是试图让既有系统写在区域文件之外的冗余在真实网络中成立。

DNS 原本就要求委派区域拥有多个权威服务器。RFC 2182 区分了两个容易混为一谈的角色：主服务器保存本地配置的区域数据，辅助服务器通过区域传送从主服务器取得数据。但递归解析器和父区域不会依据主辅关系给应答排序。对 DNS 其余部分而言，它们只是多台被列出的权威服务器。只有当其他服务器或其共享设施不可用时，客户端仍能到达辅助服务器，它才构成帮助。

作者从他们当时已观察到的运行问题出发：辅助服务器选得不好。服务器的地理位置和网络连接多样性会影响区域可靠性与访问表现。把所有服务器放在同一个本地站点被明确称为糟糕做法。一条链路、一个站点、一栋楼、一间机房或一套供电发生故障，都可能同时切断它们。要问的不是远处的机器是否天然安全，而是哪些故障会让多台服务器一起消失。

RFC 2182 建议多数组织级区域使用三台服务器，其中至少一台应与其余服务器“相距甚远”。需要更高可靠性的区域可以考虑四台或五台。数量无限增加也不是更好：更大的 NS 集合会扩大 DNS 数据包，并增加未被发现的配置错误机会。三台是布局讨论中的经验建议，不是普遍适用的合规线。

这项建议还暴露了现实依赖：谁来托管远端副本？RFC 描述了规模相近的组织互相提供辅助服务。由于交换的区域数据本就可以公开获取，这样做不会泄露机密。它把冗余分配给不同运营者，却也要求持续维护区域传送、序列号和可达性。

BCP 没有测量部署是否遵从建议，也没有证明某个三台服务器的设计经受过具体事故。公布一组 NS 记录，不能证明两家服务商拥有不同上游、机房电力互不依赖，或压力下路由仍然分离。“三台服务器”证明的只是数量，不是故障路径审计。

1997 年的文件还有一句后来过时的负面应答缓存说法：它笼统称 DNS 通常不缓存否定结果。RFC 2308 于次年规范了负缓存，RFC 编辑部的勘误 4631 后来指出这一概括并不准确。运行最佳实践也有发布日期和维护历史。

RFC 2182 留下的持久洞见比一个神奇数字更具体：冗余取决于依赖关系。第三台服务器只有在改变了哪些部件会一起故障时，才真正有意义。

来源