我正在devise一个业务连续性计划。 该公司的网站在两个不同的数据中心使用两台内部托pipe的服务器来提供名称parsing。 我被要求在UltraDNS或DynDNS上添加第三个WHOISlogging，用于“DR目的”。 即
ns1.company.com ns2.company.com NS1.ultradns.com
我的问题：如果我的内部托pipe的DNS服务器都失败，并且客户端尝试查找“company.com”，会发生什么情况？ 客户会挂断，超时，然后继续下一个？ 这完全是循环？ 还没有能够从谷歌search，并想要一些备份。
（我的答案是关于托pipe区 – 这是你似乎需要的，而不是WHOISlogging）
见＃312459 ，通过“服务器恐怖”寻找答案，我觉得它很好。
不久之后，有意发生的事情有时会拖延很久。 但是，在收到答案之前，客户端超时也可能会发生，因此用户将看到有关无法parsing主机名的消息。
TTL 越高 ，用户的影响就越小 – parsing器最终会得到答案，然后他们会caching更长的时间。
无论如何，拥有更多的服务器是个好主意（这也是RFC的build议），但拥有可靠的服务器仍然是一个不错的主意。
顺便说一句，为什么只是ns1.ultradns.com，为什么不是ns2，ns3等 – 他们不是很多？ 其实越多越好。 （根有13例如）。
您希望托pipeAlogging和NSlogging，而非最有可能的，不是WHOISlogging。 如果授权名称服务器列表中的一台服务器没有响应，则会查询列表中的另一台服务器。 这可能会使分辨率下降一点，但不会打破它。
这就是说，你似乎对某些基本的术语和function有一些误解。 在尝试执行任何操作之前，您应该先阅读相关的DNS RFC，然后从这里开始。
最初，查找将故障转移到您的ultra.com DNS。 根据logging的TTL，您的DNS最终会失败。 只要您的主DNS服务器停机时间过长，就会发生这种情况。
鉴于您的网站可能已经closures，除了指出电子邮件应该交付之外，DNS不太可能有用。 您可能有其他网站在DNS中列出，他们将可到达。 但是，如果您有三个站点，则将第三个站点添加为第三个DNS站点会更有意义。
使用您当前的configuration，如果一个站点closures，则所有的DNS将由另一个站点处理。 如果主DNS的站点closures，则需要重新configuration另一个站点以成为主站点。 正如@MarkM指出的那样，您应该查看DNS RFC。 他们提供了很多你正在寻找的答案。