我们有一个小型的数据中心，有大约100个主机指向3个内部DNS服务器（绑定9）。 当其中一个内部DNS服务器变得不可用时，我们的问题就出现了。 那时，指向该服务器的所有客户端开始执行的速度非常缓慢。
问题似乎是股票的Linuxparsing器没有真正的“故障转移”到不同的DNS服务器的概念。 您可以调整它使用的重试的超时时间和次数（并且设置为旋转，以便它可以通过列表工作），但是如果主DNS服务器不可用，无论使用我们的服务的设置的执行速度要慢得多。 目前，这是我们服务中断的最大来源之一。
我的理想答案是像“RTFM：调整/etc/resolv.conf这样…”，但如果这是一个选项，我没有看到它。
我想知道其他人怎么处理这个问题？
我可以看到3种可能的解决scheme：
使用linux-ha / Pacemaker和故障切换ips（因此dns IP VIP“始终”可用）。 唉，我们没有一个好的击剑基础设施，没有击剑起搏器不能很好地工作（根据我的经验，Pacemaker降低了击剑的可用性）。
在每个节点上运行本地dns服务器，并将resolv.conf指向localhost。 这是可行的，但它会给我们更多的服务来监视和pipe理。
在每个节点上运行本地caching。 人们似乎认为nscd“破碎”，但dnrd似乎有正确的function设置：它将dns服务器标记为up或down，并且不会使用“down”dns服务器。
任何转换似乎只在ip路由级别工作，并依赖于路由更新服务器故障。 多播似乎是一个完美的答案，但绑定不支持广播或多播，我能find的文档似乎表明，多播DNS更多的目的在于服务发现和自动configuration，而不是常规的dnsparsing。
我错过了一个明显的解决scheme？
几个选项。 两者都将在您的DNS服务器上分配DNS负载。
options rotate 。 这将使主服务器closures的影响最小化。 如果其他服务器中有一台出现故障，则会降低操作速度。 这些选项可以结合options timeout:1 attempts:5 。 如果减less超时，则增加尝试次数，以便处理较慢的外部服务器。
根据您的路由器configuration，您可能能够configuration您的DNS服务器，以便在closures主DNS服务器的IP地址时closures它。 这可以结合上述技术。
注：我运行了几年，没有计划外的DNS中断。 正如其他人所指出的，我将努力解决导致DNS服务器失败的问题。 上述步骤还可以帮助configuration错误configuration的DNS服务器，并指定不可访问的名称服务器。
看看“man resolv.conf”。 您可以将一个超时选项添加到resolv.conf。 缺省值是5，但在resolv.conf中添加以下内容应该将其降低到1秒：
选项超时：1
群集软件，如心跳或起搏器/ corosync是你的朋友在这里。 作为一个例子，我们已经build立起搏器/ corosync如下：
生产时间是24×7，但我们坚信，每台服务器都应该能够在不影响客户的情况下发生故障。 select旋转只是一个解决方法，我不会这样做。
在每个节点上运行本地dns服务器，并将resolv.conf指向localhost。 这是可行的，但它会给我们更多的服务来监视和pipe理。
FWIW，这是我发现这个问题唯一可行的解决scheme。 您需要限制服务器只在本地主机上侦听，但它已经完全消除了用户注意到我们的环境中的DNS中断。
一个有趣的副作用是，如果localhost服务器由于某种原因而closures，那么标准parsing器库似乎比在标准情况下更快地处理到下一个服务器的故障转移。
我们已经这样做了大约3年了，我还没有看到一个问题可能与在本地主机上运行的dns服务器的故障/中断有关。
如果名称服务器正在维护，那么提前减lessSOA中的超时是一个正常的过程，所以当维护发生时，更改（如在维护之前删除NSlogging并在维护之后将其恢复）迅速传播。 请注意，这是一个服务器端的方法 – 更改parsing器是一种客户端方法，除非你可以与每一个客户交谈，让他们在他们的机器上进行调整…可能不会正确的做法。 那么，我猜你在数据中心里只使用内部DNS服务器只说了一百个客户端，但是当你只需要改变这个区域的时候，你真的想改变一百个客户端的configuration吗？
我会告诉你SOA中的哪些值需要调整，但是当我碰到这个问题时，我正在浏览网页以找出确切的信息。
也许你可以把你的DNS服务器放在负载均衡器后面？ 显然LVS可以平衡UDP。 显然，让你的LB高度可用，所以它不是一个单一的失败点。
我知道这可能听起来很古怪，但是如何build立一个更稳定，更耐用的DNS基础设施作为解决问题的永久性解决scheme。
更加以networking为中心的解决scheme将使用具有相同（专用）IP和任播路由的两台DNS服务器。 （到目前为止，我还没有在这个线程中注意到这个答案，但是这里就是这个用法。）
只要两者都启动，就使用最近的服务器。 如果发生故障，该IP的stream量将被路由到另一个节点，直到它再次出现。 如果您有两个或更多的位置或数据中心，这尤其有意义。