我认为 DNS 主/辅冗余目的很简单。我的理解是，你应该有一个主 DNS 和至少一个辅 DNS，并且你应该将辅 DNS 设置在不同的地理位置，但也应设置在不同的路由器后面（例如，请参阅https://serverfault.com/questions/48087/why-are-there-several-nameservers-for-my-domain）
目前，我们的主数据中心有两个名称服务器。最近，由于各种原因，我们遭遇了一些中断，导致两个名称服务器都瘫痪，导致我们和我们的客户几个小时都无法使用 DNS。我已要求我的系统管理员团队在另一个数据中心完成 DNS 服务器的设置，并将其配置为辅助名称服务器。
然而，我们的系统管理员声称，如果其他数据中心的可靠性不如主数据中心，那么这种方法就没什么用。他们声称，当主数据中心瘫痪时，大多数客户端仍然无法正常查找，或者超时时间过长。
就我个人而言，我相信我们并不是唯一一家遇到此类问题的公司，而且这个问题很可能已经解决了。我无法想象所有这些互联网公司都会受到我们这种问题的影响。但是，我找不到好的在线文档来解释在发生故障的情况下会发生什么（例如，客户端超时）以及如何解决这些问题。
我可以使用什么论据来揭穿我们系统管理员的推理漏洞？我可以查阅哪些在线资源来更好地理解他们声称存在的问题？
读完回复后的一些补充说明：
- 我们在 Linux 上
- 我们还有其他复杂的 DNS 需求；我们的 DNS 条目由一些自定义软件管理，BIND 目前从 Twisted DNS 实现中获取资源，并且还有一些视图。但是，我们完全有能力在另一个数据中心设置自己的 DNS 服务器。
- 我说的是外部人员用来找到我们的服务器的权威 DNS，而不是我们本地客户端的递归 DNS 服务器。
答案1
有一份非常棒的、尽管技术性很强的“最佳实践”文档，在对抗系统管理员时可能会很有用。 http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
如果他/她不承认思科所写文章的有效性，那么您最好停止与系统管理员争论 - 上升一个管理层。
许多其他“最佳实践”文档建议不仅按 IP 块，而且按物理位置来区分主名称服务器和辅助名称服务器。事实上，RFC 2182 建议将辅助 DNS 服务在地理上分开。对于许多公司来说，这意味着在另一个数据中心租用服务器，或订阅托管 DNS 提供商，例如區域編輯或者超级DNS。
答案2
然而，我们的系统管理员声称，如果其他数据中心至少没有那么好，这没什么帮助可信 作为主数据中心。他们声称，当主数据中心关闭时，大多数客户端仍然无法正确查找，或者超时时间过长。
啊重点是可信。听起来他们正在攻击你与外部的链接，而不是设置辅助 DNS。尽管如此，还是要设置辅助 DNS 并从那里继续。这将有助于减轻负载，并在紧急情况下支撑一切……但一定要询问他们为什么认为其他位置不是可信。
就我个人而言，我相信我们并不是唯一一家面临此类问题的公司，而且这个问题很可能已经解决了。我无法想象所有这些互联网公司都会受到我们这种问题的影响。
你们不是唯一一家这样的公司，而且这个想法可能已经在全世界所有的公司中被重复了一百万次。
但是，我找不到好的在线文档来解释故障情况下发生的情况（例如，客户端超时）以及如何解决这些问题。
我可以使用什么论据来揭穿我们系统管理员的推理漏洞？我可以查阅哪些在线资源来更好地理解他们声称存在的问题？
- 我说的是外部人员用来找到我们的服务器的权威 DNS，而不是我们本地客户端的递归 DNS 服务器。
您可以做各种各样的事情，包括设置一个注册为您所在区域的权威机构的外部 DNS 服务，但秘密地将（外部）权威服务器设为您自己的（内部）DNS 服务器的辅助服务器。 这个配置太糟糕了，是错误的，表明我真的是一个邪恶的系统管理员，每次我推荐它时，都会有一只小猫死去。 但它有两个作用：
- 您可以让您的 DNS 服务来处理大部分负载，从而使有关您自己的（内部）DNS 容量的问题变得毫无意义。
- 当你的内部 DNS 服务器可能瘫痪时，你的 DNS 服务仍会保持运行，因此你的链接有多可靠并不重要 - 重要的是你的DNS 服务提供商是。
这是错误的要做的事：
- 您将设置所谓的“隐形名称服务器”，因为虽然它会显示在您的区域记录中，并且您可以查询 IP 以获取服务器的名称，但它永远不会被外部触及。客户端查询永远不会到达它。
- 虽然你的 DNS 可以继续正常运行（因为你的托管服务可以解决这个问题），但这并不意味着如果你的互联网连接中断，你拥有的任何网站都可以正常工作，也就是说，它只解决了一半的问题。这听起来确实像是管理员关心的其他问题。
答案3
不幸的是，Linux DNS 解析器似乎不直接支持检测和执行 DNS 服务器故障转移。它会不断向您的主解析名称服务器提供请求，等待配置的超时，然后再次尝试，等等。
这通常意味着任何请求都会延迟长达 30 秒。只要主服务器宕机，就不会先尝试辅助服务器。
我想解决这个问题，因为我们的许多工作人员无法访问我们的 Amazon EC2 解析名称服务器。由于我们依赖解析，这会导致我们的流程严重延迟，在某些情况下甚至会导致停机。如果 Amazon 再次出现故障，我希望能够很好地故障转移到 Google / Level3 名称服务器。并尽快恢复，因为这样 Amazon 就会在适用的情况下将主机名解析为本地地址，从而以较低的延迟解析实例到实例的通信。
但无论使用情况如何，都需要更好的故障转移。我想解决这个问题。我想远离代理守护进程、服务等。因为那只会引入更多的单点故障。我想尽可能使用古老而强大的技术。
我决定使用 crontab 和 bash，然后写道nsfailover 脚本。 希望这可以帮助。
答案4
只要您的每个数据中心都在不同的线路上（理想情况下，不同的上游提供商位于云端），您就可以仅使用两个数据中心设置相当可靠的 DNS。您只需确保您选择的注册商将适当的粘合记录填充到天空中的大型服务器即可。
我们的设置是：
- 2 个物理数据中心（独立电路、ISP 和上游提供商）
- 每个设施的 SLB 后面集群中有 2 个物理查询服务器
- 2 个负载平衡设备，用于服务特定记录，以便管理两个数据中心之间的平衡
- 隐藏主机可由两个服务器集群内部访问（我非常相信隐藏主机设置可以保证安全性）
这种设置非常有效，在过去的 6 到 7 年里，即使服务器偶尔因更新等原因停机，也能为我们带来大约 5 个 9 的正常运行时间。如果您愿意多花几美元，您可以考虑将区域外包给 ultradns 这样的公司托管...
至于 KPWINC 提到的负载对话，这是 100% 正确的。如果你最小的数据中心无法处理 100% 的负载，那么你很可能无论如何都会陷入困境，因为你的停机将在你最不希望的时候发生 =)
我从所有边缘路由器中获取最大负载，将它们全部加在一起，然后除以 0.65...这就是我们每个数据中心必须拥有的最小带宽。我大约在 5 年前制定了这条规则，并从 CCO 和互联网上收集了一些文件来证明这一点，它从未让我们失望过。但是，你必须检查这些统计数据至少每季度一次。去年 11 月至 2 月期间，我们的流量增长了近 3 倍，而我对此毫无准备。好的一面是，这种情况确实让我生成了一些非常明确的硬数据，表明当我们的 WAN 电路负载达到 72% 时，我们开始丢包。我从未被要求提供更多带宽的额外理由。