由于当地的火灾，2009年7月，Authorize.Net的网站出现故障。 如果您在此期间访问了他们的网站，则会发出通知或redirect来查看其Twitter帐户的状态更新。 这似乎是一个很好的解决scheme。
这让我思考。 对于我pipe理的网站，在他们当前的设置中，如果我的主机丢失了全部的互联网连接，用户将在他们的浏览器中看到“服务器未find”错误。 我不想让访客认为公司已经不在了。 我希望让访问者看到某种“非计划停机”页面。
目前我必须：
这似乎是一个可怕的解决scheme。 我知道这样做有一个更好的方法。
问题1：什么是避免这种情况的解决scheme？
我有一个想法是将名称服务器1和2指向位于网站托pipe位置的名称服务器。 Nameserver 3＆4指向可以查看“计划外中断”页面的另一台主机。
问题2：这个解决scheme是否工作？
问题3：我可以依靠被查询的名称服务器（1,2,3,4）吗？
问题4：这是一个可怕的想法或皱眉？
您在“目前我必须”的假设是合理的 – 请注意，DNSlogging传播时间在名称服务器的SOAlogging中得到控制 – 您可以缩短它（查看任何知名站点的logging，您将看到他们通常是短TTL）
但是，您的解决scheme将无法正常工作，因为DNS服务器没有订购。 没有1,2,3,4。
过去我处理大型网站的一种方式与您所描述的类似 – 使用故障转移组件。 主数据中心内的DNS服务器，辅助热备用数据中心内的DNS服务器，当主数据中心出现故障时，更新DNS将WWW指向辅助数据中心。 有商业产品自动处理这个（BigIP 3DNS，哈），但它不难脚本。
你可以做便宜的东西非常相似。
获取一个便宜的VPS，并将其configuration为域名的辅助名称服务器，并与您的注册商更新logging，以确保每个人都知道该名称服务器。
在新的DNS服务器上托pipe一个站点中断页面。
调整您的DNS SOAlogging中的TTL / Retry / Refresh数字，以对应所需的故障转移窗口。
如果您的主站点发生故障，请手动更新您的DNS …（或者如果可以可靠地检测到故障并将其编写成脚本，则会自动更新…）
我相信其他人会对你能处理的（很多）方式有一些build议。
看看AutoFailover.com
从他们的产品中剪下来：
Autofailover
TZO-HA的主stream和高可用性选项的基础是保持非常低的caching时间的独特能力。 这允许接近实时的stream量redirect 。
当TZO-HA检测到故障时，它会自动更新您的域的DNSlogging，以便将服务器请求发送到备用服务器或服务器群集的IP地址 。
空前的故障转移时间
redirect服务器请求的最长时间为2-1 / 2分钟，包括故障检测，DNSlogging更改以及通过其他DNS服务器的DNS传播时间。 通常，这一切都在1分钟内发生。 竞争产品只能提供10到30分钟或更长的时间。 TZO-HA还包含多种故障切换模式。
这样做通过DNS是一个可怕的想法。 您的客户不仅需要永久性地获得您的IP已经改变的提示，而且他们还会caching您的问题，即使您回来了。
大家伙做的是有第二个站点可用（托pipe“我们失望”页面，或者也许只是另一个站点的副本），并且有一些路由器在他们前面执行BGP。 如果一个网站发生故障，包裹会神奇地转到另一个网站。 当它回来了，它有优先权，你去了。
这太贵了。 你可能不需要它。 如果你这样做，好吧…花费:)
另一种select是把你的主页从一个CDN上托pipe（大概不会掉下去）。 如果你的网站被洗脑，把它们翻到你的“嘿，事情是坏的，但他们会好起来的”页面，而你做的修复。