Answers:
“ DNS故障转移”是指DNS Round Robin与一些监视功能结合在一起，即为DNS主机名发布多个IP地址，并在监视功能检测到服务器关闭时删除无效地址。这对于流量较小的小型网站可能是可行的。
根据设计，当您回答DNS请求时，您还将为发出的响应提供生存时间（TTL）。换句话说，您是在告诉其他DNS服务器和缓存“您可以存储此答案并使用x分钟，然后再与我联系”。缺点来自于此：
获得正常运行时间的更常见方法包括：
极少数网站使用多数据中心设置，并在数据中心之间进行“地域平衡”。
DNS故障转移无疑非常有效。多年来，我一直在使用它来手动在数据中心之间转移流量，或者在监视系统检测到中断，连接问题或服务器过载时自动转移流量。当您看到它的运行速度以及可以轻松转移的真实流量时，您将永远不会回头。我使用Zabbix监视我的所有系统，而直观的图形显示了DNS故障转移情况下发生的情况，这使我的所有疑虑都荡然无存。可能有一些ISP忽略了TTL，并且仍然有一些用户在使用旧的浏览器-但是当您每天在2个数据中心位置查看来自数百万次页面浏览的流量并且进行DNS流量转换时-忽略TTL的剩余流量可笑。
DNS并非专为故障转移而设计-但它与TTL一起设计，当与可靠的监控系统结合使用时，它们可以出色地满足故障转移需求。TTL可以设置得很短。我在生产中有效使用了5秒的TTL，以减轻基于DNS的快速故障转移解决方案的负担。您必须拥有能够处理额外负载的DNS服务器-并且名称不会减少。但是，当在冗余名称服务器上使用mysql复制的数据库作为备份时，powerdns符合要求。您还需要一个可靠的分布式监视系统，该系统可以信任自动故障转移集成。Zabbix为我工作-我可以几乎立即验证多个分布式Zabbix系统的中断-即时更新powerdns使用的mysql记录-并在中断和流量高峰期间提供几乎即时的故障转移。
但是，嘿-我建立了一家提供DNS故障转移服务的公司，经过多年的努力，该服务已为大型公司所用。因此，请多加盐分。如果您想在停机期间查看高容量站点的一些zabbix流量图-亲自了解DNS故障转移的工作原理-请给我发电子邮件，我很乐意分享。
DNS故障转移的问题是，在许多情况下，它是不可靠的。一些ISP会忽略您的TTL，即使他们确实尊重您的TTL也不会立即发生，并且当您的站点恢复正常运行时，当用户的DNS缓存超时时，会话可能会变得有些奇怪，并且最终导致转移到另一台服务器。
不幸的是，除非您足够大以进行自己的（外部）路由，否则这几乎是唯一的选择。
普遍认为，使用DNS RR，当IP断开时，某些客户端将继续使用损坏的IP数分钟。以前在该问题的某些答案中对此进行了说明，并且也将其写在Wikipedia上。
无论如何，
http://crypto.stanford.edu/dns/dns-rebinding.pdf解释说，对于大多数当前的HTML浏览器而言，它不是正确的。他们将在几秒钟内尝试下一个IP。
http://www.tenereillo.com/GSLBPageOfShame.htm似乎更强大：
多个A记录的使用不是交易技巧，也不是负载平衡设备供应商构想的功能。因此，DNS协议被设计为支持多个A记录。浏览器，代理和邮件服务器等应用程序利用了DNS协议的这一部分。
也许有些专家可以评论为什么DNS RR不利于高可用性。
谢谢，
华伦天奴
PS：对于链接断开，我们深表歉意，但是，作为新用户，我发布的内容不能超过1个
我在一个生产量中等但对业务至关重要的网站（跨两个地区）上运行DNS RR故障转移多年。
它可以正常工作，但是我至少通过努力学习了至少三个精妙之处。
1）如果在客户端可用的任何已缓存DNS中，这两种浏览器都处于活动状态，则浏览器将在30秒后（我上次检查）从非工作IP故障切换到工作IP。这基本上是一件好事。
但是让用户“半”等待30秒是不可接受的，因此您可能希望将TTL记录更新为几分钟（而不是几天或几周），以便在出现故障的情况下，可以快速删除停机的服务器从您的DNS。其他人在回应中提到了这一点。
2）如果您的一个域名服务器（或整个两个地理区域中的一个）出现故障，这正在为您的循环域名服务，并且如果其中一个主要的出现故障，我隐约记得您可能会遇到其他问题，试图删除该域名服务器如果您还没有将名称服务器的SOA TTL /有效期设置为足够低的值，则从DNS断开名称服务器。我在这里可能会讲错技术细节，但是要真正抵御单点故障，您需要的不仅仅是一个TTL设置。
3）如果发布Web API，REST服务等，通常浏览器不会调用它们，因此，我认为DNS故障转移开始显示出真正的缺陷。这就是为什么有人说“不建议”的原因。这就是为什么我这么说。首先，使用这些URL的应用程序通常不是浏览器，因此它们缺少常见浏览器的30秒故障转移属性/逻辑。其次，是否调用第二个DNS条目甚至重新轮询DNS很大程度上取决于这些API / REST客户端使用的编程语言中网络库的底层编程细节，以及它们如何被调用API / REST客户端应用。（在它们的介绍下，库是否调用get_addr，何时调用？如果套接字挂起或关闭，应用程序是否会重新打开新的套接字？是否存在某种超时逻辑？等等）
它价格便宜，经过了良好的测试，并且“大部分都可以使用”。因此，与大多数情况一样，您的行驶里程可能会有所不同。
有很多人使用我们（Dyn）进行故障转移。这与网站在停机时可以显示状态页的原因相同（想想Twitter的“失败的鲸鱼”之类的事情）……或者只是根据TTL重新路由流量即可。有些人可能认为DNS故障转移是贫民窟...但是我们从一开始就认真设计了具有故障转移功能的网络...以便它可以和硬件一样工作。我不确定DME的工作方式，但是我们有17个最近的任意播PoP中有3个从最近的位置监视您的服务器。当它从三个中的两个检测到故障时，我们只需将流量重新路由到另一个IP。唯一的停机时间是在该TTL间隔的剩余时间内达到要求的停机时间。
有些人喜欢同时使用两个服务器...在这种情况下，可以做一些事情，例如循环负载均衡...或基于地理位置的负载均衡。对于那些真正关心性能的人...我们的实时流量管理器将监视每台服务器...如果服务器速度较慢...则根据您在主机名中链接的IP将流量重新路由到最快的服务器。再次...这基于您在我们的UI / API /门户中设置的值而起作用。
我想我的意思是...我们故意设计了DNS故障转移。虽然最初创建DNS并不是为了故障转移而创建的，但我们的DNS网络旨在从一开始就实现它。它通常可以和硬件一样有效。而不会折旧或降低硬件成本。希望这不会让我因插入Dyn而感到la脚...还有很多其他公司正在这样做...我只是从我们团队的角度出发。希望这可以帮助...
另一种选择是在位置A设置名称服务器1，在位置B设置名称服务器2，但是将每个服务器都设置好，这样NS1上的所有A记录都将流量指向位置A的IP，而NS2上的所有A记录都将指向IP地址。位置B。然后将TTL设置为一个很小的数字，并确保已为NS1和NS2设置了在注册商处的域记录。这样，它将自动实现负载平衡，并在一台服务器或一个位置的链接断开时进行故障转移。
我使用这种方法的方式略有不同。我在一个位置拥有两个ISP，并使用此方法在每个链接上定向流量。现在，它可能比您愿意做的维护要多。。。但是我能够创建一个简单的软件，该软件可以自动提取NS1记录，更新所选区域的A记录IP地址，并将这些区域推送到NS2。
另一种选择是基于BGP的故障转移系统。设置起来并不简单，但是应该是防弹的。在一个位置设置站点A，在第二个站点B中都设置本地IP地址，然后获得C类或其他可移植的ip块，并设置从便携式IP到本地IP的重定向。
有陷阱，但是如果您需要这种控制级别，它比基于DNS的解决方案要好。
多数据中心故障转移的一种选择是训练用户。我们向客户宣传我们在多个城市和注册电子邮件中提供了多台服务器，其中包括直接指向每台“服务器”的链接，以便用户知道一台服务器是否停机，可以使用到另一台服务器的链接。
仅维护多个域名就完全绕过了DNS故障转移的问题。访问www.company.com或company.com并登录的用户将定向到server1.company.com或server2.company.com，如果他们发现使用一种或另一种可获得更好的性能，则可以选择对其中任何一个添加书签。 。如果一个服务器出现故障，将训练用户使用另一台服务器。
在过去的十年中，我一直在使用基于DNS的站点平衡和故障转移，虽然存在一些问题，但是可以缓解这些问题。BGP虽然在某些方面具有优势，但并不是100％解决方案，它要么具有增加的复杂性，可能会增加硬件成本，收敛时间等...
我发现结合本地（基于LAN的）负载平衡，GSLB和基于云的区域托管可以很好地解决通常与DNS负载平衡相关的一些问题。
所有这些答案对他们都有一定的道理，但我认为这实际上取决于您在做什么以及您的预算是多少。在CloudfloorDNS，我们业务的很大一部分是DNS，不仅提供快速DNS，而且提供低TTL选项和DNS故障转移。如果这不能正常工作，我们就不会做生意。
是的，如果您是一家运营时间预算不受限制的跨国公司，那么硬件GSLB负载平衡器和第1层数据中心是不错的选择，但您的DNS仍然需要快速且坚如磐石。众所周知，DNS是除域名本身之外的任何基础结构的关键方面，它是您在线状态的每个其他部分都可以使用的最低级别的服务。从可靠的域名注册商开始，DNS与不让您的域名过期同样重要。DNS发生故障，这意味着组织的整个在线方面也发生故障！
使用DNS故障转移时，其他关键方面是服务器监视（始终检查多个地理位置，并应始终检查多个（至少3个）以避免误报），并正确管理DNS记录以检测到故障。低TTL和故障转移的某些选项可以使此过程无缝进行，并且如果您是系统管理员，则可以避免在半夜醒来传呼机的麻烦。
总体而言，DNS故障转移确实可以正常工作并且可以负担得起。在大多数情况下，我们或大多数托管DNS提供商都会为您提供Anycast DNS，以及服务器监视和故障转移功能，而硬件选择成本只是其中的一小部分。
因此，真正的答案是肯定的，它可行，但是对所有人和每个预算都适用吗？也许不是，但是除非您尝试并自己进行测试，否则如果您是中小型企业且IT预算有限且希望获得最佳正常运行时间，则很难忽略它。
“以及为什么要抓住机会在大多数生产环境中使用它（尽管总比没有好）。”
实际上，当存在的地理位置不同时，“胜过一切”最好表示为“唯一的选择”。硬件负载平衡器非常适合单点存在，但是单点存在也是单点故障。
有很多大美元站点使用基于dns的流量操纵来取得良好效果。他们是每小时都会知道销售量是否减少的网站类型。看来他们是最后一次“抓住机会在大多数生产环境中使用它”。实际上，他们已经仔细审查了他们的选择，选择了该技术，并为此付出了高昂的代价。如果他们认为更好的话，他们会心跳加速。他们仍然选择留下的事实充分说明了现实生活中的使用情况。
基于Dns的故障转移确实会遭受一定程度的延迟。没有其他办法了。但是，它仍然是多流行方案中故障转移管理的唯一可行方法。作为唯一的选择，它远不止“胜于无”。
如今，良好的全局负载平衡器可以使用该技术运行并且运行良好。检查例如Azure Traffic Manager https://azure.microsoft.com/zh-cn/services/traffic-manager/
如果您想了解更多信息，请阅读以下应用笔记
它们涵盖：故障转移，全局负载平衡以及许多相关事项。
如果您的后端体系结构允许，更好的选择是使用故障转移选项进行全局负载平衡。这样，所有服务器和带宽都可以发挥最大作用。此安装程序不会在发生故障时插入其他可用服务器，而是从服务中撤出发生故障的服务器，直到恢复为止。
简短的答案：它可行，但是您必须了解局限性。
我建议您要么A，选择一个在其自己的AS上多宿主的数据中心，要么B，将您的名称服务器托管在公共云中。EC2，HP或IBM倒闭的可能性很小。只是一个想法。尽管DNS是一种修复程序，但在这种情况下，它仅是针对网络基础中不良设计的修复程序。
根据您的环境，另一种选择是结合使用IPSLA，PBR和FHRP来满足您的冗余需求。