2009 年 7 月，由于当地发生火灾，Authorize.Net 网站一度瘫痪。如果您在那段时间访问他们的网站，就会看到通知或重定向，让您查看其 Twitter 帐户上的状态更新。这似乎是一个很好的解决方案。
这让我开始思考。对于我管理的网站，在目前的设置下，如果我的主机完全失去互联网连接，用户将在他们的浏览器中看到“找不到服务器”错误。我不希望访客认为公司不再营业。我更希望访客看到某种“计划外中断”页面。
目前我必须：
- 注意到该网站已关闭（IP 监控）
- 更新名称服务器的 DNS 记录以指向另一个主机（希望已经设置）
- 等待新的 DNS 记录传播（25 分钟 - 48 小时）
这看起来是个糟糕的解决方案。我知道一定有更好的方法。
问题 1：有什么解决方案可以避免这种情况？
我的一个想法是让名称服务器 1 和 2 指向网站托管的物理位置的名称服务器。让名称服务器 3 和 4 指向可以查看“计划外中断”页面的另一台主机。
问题#2：这个解决方案有效吗？
问题 3：我可以依赖按顺序（1,2,3,4）查询的名称服务器吗？
问题#4：这是一个糟糕的想法还是不被接受的？
答案1
您在“目前我必须”下的假设是正确的 - 请注意 DNS 记录传播时间由您名称服务器中的 SOA 记录控制 - 您可以使其更短（查看任何著名网站的记录，您会发现它们通常都是短 TTL）
但是，您的解决方案不起作用，因为 DNS 服务器没有排序。没有 1、2、3、4。
我过去为大型网站处理这个问题的方法与您描述的类似 - 使用故障转移组件。主数据中心中的 DNS 服务器，辅助热备用数据中心中的 DNS 服务器，当主数据中心发生故障时，更新 DNS 以将 WWW 指向辅助数据中心。有商业产品可以自动处理这个问题（BigIP 3DNS，哈哈），但编写脚本并不难。
你可以用低成本做一些非常类似的事情。
获取廉价的 VPS 并将其配置为您域名的辅助名称服务器，然后向您的注册商更新您的记录，以确保每个人都知道该名称服务器。
在新的 DNS 服务器上托管站点中断页面。
调整 DNS SOA 记录中的 TTL/重试/刷新数字以对应所需的故障转移窗口。
如果您的主站点出现故障，请手动更新您的 DNS...（或者自动更新，如果您可以可靠地检测故障并编写脚本...）
我相信其他人会对处理此问题的（多种）方法提出一些建议。
答案2
摘录自他们的产品：
自动故障转移
TZO-HA 的主要支柱和高可用性选项的基础是维持极低缓存时间的独特能力。这允许近乎实时的流量重定向。
当 TZO-HA 检测到故障时，它会自动更新您域的 DNS 记录，以便将服务器请求发送到备用服务器或服务器群集的 IP 地址。
前所未有的故障转移时间
重定向服务器请求的最大时间为 2-1/2 分钟，包括故障检测、DNS 记录更改和通过其他 DNS 服务器的 DNS 传播时间。通常，这一切都发生在 1 分钟内。竞争产品只能提供 10 到 30 分钟或更长的时间。TZO-HA 还包括多种故障转移模式。
答案3
通过 DNS 执行此操作是个糟糕的主意。不仅您的客户端需要很长时间才能收到您的 IP 已更改的提示，而且即使您恢复后，他们也会缓存您已关闭的信息。
大公司的做法是提供第二个站点（托管“我们宕机了”页面，或者只是站点的另一个副本），并在它们前面安装一些路由器执行 BGP。如果一个站点宕机，数据包会神奇地转到另一个站点。当它恢复时，它具有优先权，然后就可以了。
那太贵了。你可能不需要它。如果你需要，那么……开始花钱吧 :)
另一个选择是将您的主页托管在 CDN 之外（大概不会出现故障）。如果您的网站出现故障，请在您修复问题的同时，让客户转到您的“嘿，情况很糟糕，但会好起来的”页面。