正确设置DNS主/从/ …以实现冗余和延迟降低的方法？

有一个非常好的，虽然技术性很强的“最佳实践”文档，可能会有助于打击您的系统pipe理员。 http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

如果他/她不认可思科撰写的文章的有效性，那么您最好不要再与系统pipe理员争论 – 进行一定程度的pipe理。

许多其他“最佳实践”文档build议不仅通过IP块，而且通过物理位置来分隔主要和次要名称服务器。 实际上，RFC 2182build议辅助DNS服务在地理上是分开的。 对于许多公司来说，这意味着在另一个数据中心租用服务器，或者订阅托pipe的DNS提供商，如ZoneEdit或UltraDNS 。

不幸的是，Linux DNSparsing器似乎没有直接支持DNS服务器的检测和故障转移。 它保持喂食请求你的主要parsing域名服务器，等待configuration的超时，再次尝试，等等。

这通常意味着长达30秒的任何请求延迟。 没有首先尝试中学，只要主要是下来。

我想解决这个问题，因为我们的许多员工无法访问我们的Amazon EC2parsing名称服务器。 这会导致我们的stream程出现严重延迟，甚至在某些情况下会导致停机，因为我们依靠解决scheme。 如果亚马逊再次倒台，我想要一个很好的故障转移到Google / Level3域名服务器。 然后尽快回落，因为亚马逊会在适当的情况下将主机名parsing为本地地址，以较低的延迟解决例如实例通信。

但无论使用哪种用例，都需要更好的故障转移。 我想解决这个问题。 我想远离代理守护进程，服务等，因为这只会引入更多的单点故障。 我想尽可能使用古老而坚固的技术。

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

但是，我们的系统pipe理员声称，如果其他数据中心不如主数据中心那么可靠 ，这一点就没有什么帮助。 他们声称，当主数据中心停机时，大多数客户仍然无法正确查找，或者时间太长。

啊，重点是可靠的 。 这听起来像是他们正在对外部链接进行刺探，而不是设置辅助DNS。 同样，设置辅助DNS并从那里继续。 这将有助于负载，并将支撑在一个捏…但要询问为什么他们认为其他位置是不可靠的 。

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

你不是唯一的公司，而且这个公司在世界各地已经被重新修改了一百万次。

但是，我无法find很好的在线文档来解释失败情况（例如，客户端超时）以及如何解决这些问题。

我可以用什么理由来打破我们的系统pipe理员的推理漏洞？ 任何在线资源，我可以咨询，以更好地了解他们声称存在的问题？

• 我在谈论外部人员的权威DNS来寻找我们的服务器，而不是我们本地客户端的recursionDNS服务器。

您可以做各种事情，包括设置一个外部DNS服务，该服务被注册为您所在区域的权限，但是秘密地将（外部）权威服务器作为您自己（内部）DNS服务器的辅助。 这种configuration是可怕的，错误的，表明我真的是一个邪恶的系统pipe理员，每当我推荐它，一只小猫死亡。 但它有两件事情：

• 你得到你的DNS服务来处理负载的首当其冲的问题，使你自己的（内部）的DNS的能力作为模拟。
• 当你的内部DNS服务器可能closures时，你的DNS服务会保持不变，所以不pipe你的链路有多可靠，重要的是你的DNS服务提供商是多么的可靠。

原因是这是错误的事情：

• 你将要build立一个叫做“隐形域名服务器”的地方，因为虽然它会出现在你的区域logging中，你可以查询IP作为服务器的名字，但它永远不会被外界触及。 客户端查询将永远达不到它。
• 虽然你的DNS可以继续正常运行（因为你的托pipe服务可以解决这个问题），但是这并不意味着你的任何网站在你的互联网连接中断的情况下都能正常工作，也就是说， 它只能解决一半的问题 。 这确实听起来像pipe理员担心的其他问题。

听起来问题是， 客户端（可能是任何人，任何地点的客户端）都会看到两台DNS服务器，如果出现故障，它们要么不会故障切换到备用服务器，要么在执行之前有很长的超时时间。

我同意，主要和辅助DNS服务器应该位于不同的设施作为一个最佳实践，但我不明白这将如何解决这个特定的问题。

如果客户端要坚持查询一个特定的IP地址，忽略该IP地址（或者需要一段时间超时），那么你只需要提出一个解决scheme来保持IP地址的工作，即使主服务器已closures。

探索的一些方向是负载均衡器，可以将单个IP地址的stream量redirect到不同数据中心的多个服务器; 或者也许选播路由。

只要每个数据中心位于不同的电路上（理想情况下，不同的上游提供商远在云端），只需两个数据中心即可设置相当可靠的DNS。 您只需确保您select的注册服务商将合适的粘合logging填充到天空中的大型服务器。

我们的设置是：

• 2个物理数据中心（独立电路，ISP和上游提供商）
• 在每个设施的SLB后面的2个物理查询服务器
• 2负载平衡设备来服务特定的logging，我们要pipe理两个数据中心之间的平衡
• 隐藏的主控内部可以通过这两个服务器集群（我相信非常强烈的隐藏的主安全设置）

这种设置已经足够有效，在过去的6到7年里，即使有偶尔的服务器停机时间，也能给我们大约5 9的正常运行时间。如果你愿意花更多的钱，你可以看看外包与ultradns之类的东道主区域举办…

对于KPWINC提到的负载对话，这是100％正确的。 如果最小的数据中心无法处理100％的负载，那么无论如何，因为在最不需要的时候就会发生中断，所以您可能已经骨折了）

我从所有边缘路由器中获取最大负载，将它们全部相加，然后除以0.65 …这是每个数据中心必须具有的最小带宽。 大约五年前，我制定了这条规则，有一些文件certificate我是从CCO和互联网收集来的，从来没有让我们失望。 但是，您必须至less每季度检查一次这些统计信息。 去年十一月至二月期间，我们的stream量增长了近3倍，我没有做好准备。 那么好的一面是，这种情况确实使我能够产生一些非常明确的硬数据，说我们的WAN电路负载为72％时，我们开始丢包。 从来没有额外的理由需要我更多的带宽。

我从阅读您的描述中意识到，您是否意味着外部人员寻找您的服务器的权威DNS，或您本地客户端的recursionDNS服务器，这并不清楚。 这两者的行为是非常不同的。

对于权威的DNS服务器来说，“客户端”将是具有caching和大量智能的其他DNS服务器。 他们会倾向于一次尝试多个服务器，如果第一个服务器一直很慢，并倾向于更喜欢给予他们更快的答复。 在这种情况下，一个数据中心的停机时间会对性能造成很小的影响。

对于recursionDNS服务器，客户端是可能具有DHCP中列出的DNS服务器的本地客户端。 他们会按照列出的顺序尝试他们的服务器，在从第一台服务器移动到第二台服务器之前，需要花费很长的时间（几秒钟）。

如果您的主数据中心发生故障，那么无论如何都无法到达这些服务器，但通常这些错误比来自不可达DNS服务器的错误更容易理解。 “无法联系服务器”或“连接超时”而不是“无法find服务器”或“没有这样的服务器”。 例如，如果大多数SMTP服务器在DNS中看到服务器但却无法达到它，则它们会将邮件排队一周。 如果他们根本无法在DNS中find它们，他们可能会立即拒绝甚至尝试将其交付到您的域名。

次要DNS在地理上和networking上是分开的。 你可能能够与一家友好的公司交换二级域名服务器，而且有很多DNS服务提供商可以为你付钱。 一些注册商也有辅助DNS服务。

托马斯，

在阅读你的更新之后，我修改了我的文章（以前的文章引用了Windows软件）。

这几乎听起来像你的系统pipe理员（S）告诉你，你的次要位置没有必要的硬件来处理满载？

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

如果是这样，那么我build议你看看你的基础设施，并尝试提出一个更好的devise。 说起来容易做起来难，特别是现在你生活在一个生产环境中。

所有这一切，在一个完美的世界里，COLO1和COLO2将能够独立站立并处理您的负载。

一旦到了这个地步，DNS实际上只不过是有足够的DNS服务器进行足够快的刷新，如果一方失败了，你可以重写你的DNS来指向已经启动的服务器。

我已经在小到合理大小的环境中使用这种方法，并且效果很好。 故障转移通常不到10分钟。

你只需要确保你的DNS服务器能够处理短TTL（生存时间）的额外负载。

希望这可以帮助。

你的系统pipe理员（大部分）是错误的。

查询您的授权服务器的recursion服务器将非常迅速地注意到，如果任一站点没有响应。

是的，当客户端出现中断时，客户端可能会遇到非常温和的DNSparsing延迟，但是他们只有一两秒钟的时间，一旦客户端自己的DNS服务器知道其中一台服务器出现故障，他们就会使用其余的服务器优先于失败的服务器。

如有必要（为了安抚系统pipe理员）继续在主要数据中心运行两台服务器，但至less要在外部再安装一台服务器。

一个辅助DNS服务器从来不会伤害，取决于它在哪里托pipe它会给你或多或less的function。

如果您的主要主机出现故障，则无论是位于其旁边还是远程位置，辅助服务器都可以接pipe。 但是，如果您的数据中心上行链路出现故障，您仍然可能会从另一个数据中心的服务器获得DNS答复，但无法以任何方式访问您的服务器。 因此，您的最终用户不会直接受益于远程位置的辅助DNS。

不同的客户以其他方式反应DNS服务器不可用，所以对客户端超时有一些事实，但不是全部。

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