这是一个关于DNS地理冗余的典型问题 。
在提供弹性networking服务时，位于不同物理位置的地理冗余DNS服务器是非常需要的。 文件BCP 16深入介绍了这一点，但是最常提到的一些原因包括：
防范数据中心灾难。 地震发生。 火灾发生在机架上，拿出附近的服务器和networking设备。 如果数据中心的物理问题一次性销毁两台DNS服务器，即使它们不在同一行，多个DNS服务器也不会有太大的帮助。
防止上游同行问题。 如果一个共享的上游networking对等体发生故障，多个DNS服务器将不会阻止问题。 无论上游问题是否完全让您脱机，还是仅仅将您的所有DNS服务器与您的用户群分离开来，最终的结果是，即使服务本身位于完全不同的数据中心，人们也无法访问您的域。
这一切都很好，但是如果我将所有的服务都运行在同一个IP地址上，那么真的需要多余的DNS服务器呢？ 如果没有人能够得到我的域提供的任何东西，我不知道如何有第二个DNS服务器将提供任何好处。
我明白，这被认为是最好的做法，但这似乎毫无意义！
注：有争议的内容，请参阅两个答案的评论。 错误已经被发现，这个问题需要进行彻底的检查。
我暂时不接受这个答案，直到这个规范问答的状态得到妥善处理。 （删除这个答案也会删除附加的注释，这不是走向IMO的方法，可能会在经过大量编辑后变成社区维基答案）。
我可以在这里引用RFC，并使用技术术语，但是这是一个被知识谱两端的许多人所忽略的概念，我将试图为更广泛的读者回答这个问题。
我明白，这被认为是最好的做法，但这似乎毫无意义！
这似乎毫无意义…但实际上并不是！
recursion服务器非常善于记住远程服务器对查询没有响应的时间，特别是当他们重试时，仍然不会看到回复。 许多人对这些通信失败实施负面caching ，并暂时将不响应的名称服务器放置在禁区内一段不超过五分钟的时间。 最终这个“惩罚”期限届满，他们将恢复交stream。 如果错误的查询再次失败，他们会马上回到盒子里，否则就像往常一样恢复正常工作。
这是我们遇到单个域名服务器的问题：
长话短说，如果你使用单个DNS服务器（这包括在NSlogging中多次使用相同的IP地址），这将会发生。 这个问题也会比你意识到的要多得多，但是问题将会是如此的零散，以至于失败的可能性被报告给你，2）被复制，3）被绑定到这个特定的问题，是非常接近零。 如果你不了解这个过程如何工作，那么他们几乎是零，但是幸好现在不应该这样！
这应该打扰你吗？ 这不是我真正想说的地方。 有些人根本不会在乎这个五分钟的中断问题，我不是在这里说服你的。 我在这里说服你的是，事实上你只是运行一个DNS服务器，而且在所有情况下都牺牲了一些东西。
OP问：
这一切都很好，但是如果我将所有的服务都运行在同一个IP地址上，那么真的需要多余的DNS服务器呢？ 如果没有人能够得到我的域提供的任何东西，我无法看到第二个DNS服务器如何为我提供任何好处。
好问题！
最好的答案是丹尼尔·伯恩斯坦（Daniel J. Bernstein）博士 ，他不仅是世界知名的研究人员，科学家和密码学家，而且还撰写了一个非常受欢迎且深受欢迎的DNS套件，称为DJBDNS （ 最新发布的2001- 02-11 ，至今仍然很受欢迎）。
http://cr.yp.to/djbdns/third-party.html（2003-01-11 ）
第三方DNS服务的成本和收益
注意这个简短而简洁的部分：
第三方DNS服务的错误论据
…
第二种策略是声称广泛的DNS客户端无法访问所有的DNS服务器时会做特别的事情。 这个论点的问题是，这种说法是错误的。 任何这样的客户端显然是越野车，并且将无法在市场中生存：考虑如果客户端的路由器短暂停机，或者客户端的networking暂时被淹没，会发生什么情况。
因此，这个问题的原始答案不可能是更错误的。
是的，短暂的暂时性networking中断会持续几秒钟。 不，在这样的停电期间不能解决名称的问题不会在任何时间内被caching（否则，即使世界上最好的可用权威域名服务器的最佳设置也不会有帮助）。
任何软件自由地实施从1998 – 2003年的RFC到caching失败最多5分钟的保守准则，都是由devise破坏的，并且有一个额外的地理冗余服务器也不会有任何影响。
实际上，按照DNS超时caching多长时间？ 在BIND中， SERVFAIL条件在2014年之前一直不被caching，而且自2015年以来， 仅默认caching了1秒 ，比普通用户达到parsing器超时所需的时间要less，并且按下了“刷新”button再次。
（甚至在我们谈到应该caching解决scheme尝试的上述点之前，即使第一个SERVFAIL首先发生，也需要多于几个丢弃的分组。
此外，BIND开发者甚至已经实现了仅30秒的function的上限 ，即使是作为上限（例如，该function将接受的最大值），已经比5分钟（300s）build议低10倍从RFC，确保即使是最善意的pipe理员（眼球用户）也不能够在自己的脚下拍摄自己的用户。
另外，有很多原因可能导致你不想运行第三方DNS服务 – 阅读整个djbdns/third-party.html的所有细节 ，并租用一个微小的额外的服务器，只为DNSpipe理在没有其他需要BCP 16的情况下，自己几乎不需要担保。
从我至less从2002年起开始拥有和build立域名的个人“轶事”经验来说，我可以完全肯定和诚实地告诉你， 由于专业运营 ，我实际上总共确实有很多领域的停工我的注册服务商和托pipe服务提供商的第三方服务器 ，这些服务提供商一次又一次都发生了他们的事件，无法使用，使我的域名不必要地被占用，同时我自己的IP地址（在那里给定域名的HTTP和SMTP是托pipe的），否则是完全可达的。 请注意，这些中断是由多个独立的，受尊重的和专业运营的提供商发生的，决不是孤立的事件，每年都会发生，作为第三方服务， 完全不受您的控制 。 只是很less有人长期谈论这个问题。
简而言之：
如果您使用相同的IP地址运行所有服务，则添加第二个DNS很可能会导致额外的故障点，并且不利于域的持续可用性。 在任何可以想象的情况下总是必须这样做的“智慧”是一个非常stream行的神话， 捣毁。
当然，如果域名的某些服务（HTTP / HTTPS），邮件（SMTP / IMAP）或者语音/文本（SIP / XMPP）已经由第三方提供服务，那么build议将会完全不同在这种情况下，将自己的知识产权作为一个单一的失败点取消，确实是一个非常明智的做法，而地理冗余确实是非常有用的。
同样，如果您拥有数百万访问者的特别受欢迎的网站，并且明知地要求按照BCP 16的要求提供额外的灵活性和对地理冗余DNS的保护，那么…您可能不会使用单个服务器/站点进行networking/邮件/声音/文字，所以这个问题和答案显然不适用。 祝你好运！