设置DNS主/辅助/…的冗余和减少延迟的正确方法？

我认为用于冗余目的的DNS主/辅助很简单。我的理解是，您应该拥有一个主节点，并且至少要有一个辅助节点，并且应该将辅助节点设置在地理位置不同的位置，而且还应位于其他路由器后面（例如，请参见/server/48087 /为什么我的域有多个名称服务器）

当前，我们在主数据中心中都有两个名称服务器。最近，由于各种原因，我们遭受了一些停机，导致两个名称服务器都被淘汰，使我们和我们的客户无法使用DNS了几个小时。我已要求系统管理员团队在另一个数据中心中完成DNS服务器的设置并将其配置为辅助名称服务器。

但是，我们的系统管理员声称，如果另一个数据中心的可靠性至少不如主数据中心那么大，这将无济于事。他们声称，当主数据中心发生故障时，大多数客户端仍将无法正常查找或超时。

就个人而言，我坚信我们不是唯一遇到此类问题的公司，而且很有可能已经解决了这一问题。我无法想象所有这些互联网公司都会受到我们这种问题的影响。但是，我找不到很好的在线文档来解释失败情况下的情况（例如，客户端超时）以及如何解决这些情况。

我可以使用哪些参数来戳破系统管理员的推理？我可以咨询任何在线资源以更好地了解他们声称存在的问题吗？

阅读回复后的一些附加说明：

• 我们在Linux上
• 我们还有其他复杂的DNS需求；我们的DNS条目由某些自定义软件管理，BIND当前从Twisted DNS实施中获取，并且还包含一些视图。但是，我们完全有能力在另一个数据中心设置我们自己的DNS服务器。
• 我说的是供外部人员查找我们的服务器的权威DNS，而不是针对本地客户端的递归DNS服务器。

有一个非常棒的，尽管技术性很强的“最佳实践”文档，在与系统管理员战斗时可能会很有用。 http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

如果他/她不认可Cisco撰写的文章的有效性，那么您不妨停止与sysadmin争论-提高管理水平。

许多其他的“最佳实践”文档建议不仅按IP块，而且按物理位置分隔主要和辅助名称服务器。实际上，RFC 2182建议将辅助DNS服务在地理位置上分开。对于许多公司而言，这意味着要在另一个数据中心租用服务器，或订阅托管的DNS提供程序（例如ZoneEdit或UltraDNS）。

但是，我们的系统管理员声称，如果另一个数据中心的可靠性至少不如 主数据中心那么大，这将无济于事。他们声称，当主数据中心发生故障时，大多数客户端仍将无法正常查找或超时。

嗯，重点很可靠。听起来他们在戳您的外部链接，而不是设置辅助DNS。都一样，请设置辅助DNS并从那里继续。这将有助于减轻负担，并能在紧急情况下支撑住东西……但是请询问他们为什么认为其他位置不可靠。

就个人而言，我坚信我们不是唯一遇到此类问题的公司，而且很有可能已经解决了这一问题。我无法想象所有这些互联网公司都会受到我们这种问题的影响。

您不是唯一的公司，在全球范围内，这可能已被重新组织了百万次。

但是，我找不到很好的在线文档来解释失败情况下的情况（例如，客户端超时）以及如何解决这些情况。

我可以使用哪些参数来戳破系统管理员的推理？我可以咨询任何在线资源以更好地了解他们声称存在的问题吗？

• 我说的是供外部人员查找我们的服务器的权威DNS，而不是针对本地客户端的递归DNS服务器。

您可以做各种事情，包括设置注册为您的区域授权的外部DNS服务，但要秘密地使（外部）权威服务器与您自己的（内部）DNS服务器成为辅助服务器。 这种配置是可怕的，错误的，表明我确实是一个邪恶的SysAdmin，每次我推荐它时，它都会死去。 但这有两件事：

• 您将获得DNS服务来应对最大的负载，从而使您对自己（内部）DNS的容量产生疑问。
• 当内部DNS服务器可能关闭时，您可以使DNS服务保持正常运行，因此，链接的可靠程度并不重要-重要的是DNS服务提供商的可靠程度。

这是做错事情的原因：

• 您将要设置所谓的“隐形名称服务器”，因为它会显示在您的区域记录中，并且您可以查询IP来获取服务器的名称，但外界永远不会碰它。客户查询将永远无法实现。
• 尽管您的DNS可以继续正常运行（因为您的托管服务可以解决问题），但这并不意味着您的任何网站都可以在互联网连接中断的情况下正常工作，也就是说，它只能解决一半的问题。听起来确实确实有管理员要关注的其他问题。

不幸的是，Linux DNS解析器似乎没有直接支持检测和执行DNS服务器的故障转移。它不断将请求提供给您的主解析名称服务器，等待配置的超时，然后再次尝试，等等。

对于任何请求，这通常意味着最多30秒的延迟。只要主服务器停机，就无需先尝试辅助服务器。

我想解决此问题，因为我们的许多工作人员无法访问我们的Amazon EC2解析名称服务器。在某些情况下，这会导致我们的流程出现较大的延迟，甚至导致停机，因为我们依赖解决方案。我希望对Google / Level3名称服务器进行良好的故障转移，以防亚马逊再次倒闭。并尽快回退，因为这样亚马逊将在适用的情况下将主机名解析为本地地址，从而降低了实例到实例通信的延迟。

但是，无论用例如何，都需要更好的故障转移。我想解决这个问题。我想远离代理守护进程，服务等。因为那样只会引入更多的单点故障。我想尽可能地使用过时且强大的技术。

我决定使用crontab＆bash，并编写了nsfailover.sh。希望这可以帮助。

听起来好像问题在于，客户端 -可以是任何地方的任何人-都可以看到两台DNS服务器，如果其中一台发生故障，则它们要么无法故障转移到辅助服务器，要么等待很长的时间。

我同意，作为最佳实践，主DNS服务器和辅助DNS服务器应位于不同的位置，但是我看不出如何解决此特定问题。

如果客户端要坚持查询特定的IP地址，而忽略辅助节点的IP地址（或花一些时间使其超时），则即使您的服务器需要保留一个解决方案，也可以保持该IP地址正常工作。主服务器已关闭。

一个可以探索的方向是负载均衡器，它可以将单个IP地址的流量重定向到不同数据中心的多个服务器。或选播路由。

只要您的每个数据中心位于不同的电路上（理想情况下，不同的上游提供商都位于云中），您就可以仅使用两个数据中心来设置非常可靠的DNS。您只需要确保您选择的注册商将适当的粘合记录填充到空中的大型服务器即可。

我们的设置是：

• 2个物理数据中心（独立的电路，ISP和上游提供商）
• 每个设施中位于SLB后面的群集中的2个物理查询服务器
• 2个负载平衡设备可为我们要管理两个数据中心之间的平衡的特定记录提供服务
• 两个服务器群集都可以从内部访问隐藏的主服务器（我坚信在安全性方面，隐藏主服务器设置非常重要）

在过去的6或7年中，这种设置已经足够有效，可以使我们大约有5 9个小时的正常运行时间，即使偶尔服务器停机进行更新等也是如此。如果您愿意多花一些钱，可以考虑外包与Ultradns之类的人一起托管区域...

对于KPWINC提到的负载对话，那是100％正确的。如果最小的数据中心无法处理100％的负载，那么无论如何您都可能会陷入困境，因为在您最不希望的时候将发生断电=）

我从所有边缘路由器获得最大负载，将它们全部加在一起，然后除以0.65 ...这是我们在每个数据中心必须拥有的最小带宽。我在大约5年前制定了该规则，并提供了一些文件证明我从CCO和互联网收集到的证据，并且它从未使我们失败。但是，您必须至少每季度检查一次这些统计信息。在去年11月到2月之间，我们的流量增长了将近3倍，而我对此并不准备。好的一面是，这种情况确实使我能够生成一些非常清晰的硬数据，这表示在WAN电路上负载达到72％时，我们开始丢弃数据包。不需要我提出更多理由来获得更多带宽。

通过阅读您的描述，我意识到不清楚是对外部人来说找到权威的DNS来找到您的服务器，还是对本地客户端来说是递归的DNS服务器。这两个的行为非常不同。

对于权威DNS服务器，“客户端”将是具有缓存和大量智能功能的其他DNS服务器。如果第一个服务器很慢，他们倾向于一次尝试多台服务器，并且倾向于使用那些响应速度更快的服务器。在这种情况下，一个数据中心的停机时间将对性能造成很小的影响。

对于递归DNS服务器，客户端是您的本地客户端，可能具有DHCP中列出的DNS服务器。在每次从第一台服务器移至第二台服务器之前，他们都将以列出的顺序尝试使用服务器，超时时间长（几秒钟），非常痛苦。

如果您的主数据中心已关闭，则无论如何都无法访问这些服务器，但是与无法访问的DNS服务器的错误相比，该错误通常更易于理解。“无法联系服务器”或“连接超时”，而不是“找不到服务器”或“没有此类服务器”。例如，如果大多数SMTP服务器在DNS中看到服务器但无法访问，则将使邮件排队一周。如果他们根本无法在DNS中找到它，他们可能会立即拒绝甚至尝试将其传递到您的域。

辅助DNS在地理位置和网络上隔离是一件好事。您也许可以与一家友好的公司进行二级DNS交易，并且有很多DNS提供商可以为您提供服务。一些注册商也将辅助DNS作为服务。

托马斯

阅读您的更新后，我已经修订了我的文章（以前的文章引用了Windows软件）。

在我看来，您的sysadmin告诉您您的辅助位置没有足够的硬件来处理FULL LOAD？

听起来好像他是在说：“嗨，伙计，如果我们的主要位置（包括主要DNS）发生故障，那么DNS就是我们最担心的问题，因为如果COLO1发生故障，那么COLO2仍然无法处理负载。”

如果是这种情况，那么我建议您检查一下您的基础结构并尝试提出更好的设计。说起来容易做起来难，尤其是现在您生活在生产环境中。

除此之外，在一个完美的世界中，COLO1和COLO2将能够独立运行并处理您的负载。

一旦到位，DNS实际上就是拥有足够的DNS服务器并具有足够快的刷新速度，如果一方发生故障，您可以重写DNS以指向UP服务器。

我已经在较小到合理的环境中使用了此方法，并且效果很好。故障转移通常需要不到10分钟的时间。

您只需要确保DNS服务器可以处理短TTL（有效时间）的额外负载即可。

希望这可以帮助。

您的系统管理员（大部分）是错误的。

如果任一站点无响应，查询您的权威服务器的递归服务器将很快注意到。

是的，当发生断电时，客户端很有可能会遇到非常适度的DNS解析延迟，但是它们只有一两秒钟，并且一旦客户端自己的DNS服务器得知其中一台服务器出现故障，便会使用其余服务器优先于发生故障的服务器。

如有必要（为了安抚系统管理员），请继续在您的主数据中心运行两台服务器，但至少要再放置一台。

辅助dns服务器永远不会受到伤害，具体取决于托管它的位置，它将为您提供更多或更少的功能。

如果您的主要主机发生故障，则无论次要主机位于它旁边还是在远程位置，它都可以接管。但是，如果您的数据中心上行链路失败，您仍然可能会从另一个数据中心中的服务器获得DNS答复，但是无论如何您将无法访问服务器。因此，您的最终用户将无法直接从远程位置的辅助DNS中受益。

不同的客户端以其他方式对DNS服务器不可用做出反应，因此客户端超时虽然有些事实，但并非全部。

但是，远程数据中心中的辅助DNS仍能够解析您要访问的服务器的IP地址，以便您可以调试路由并查看它们何时再次出现。如果正确设置了辅助MX服务器，您甚至都不会丢失任何邮件。