低いTTL）を使用して、長期間のダウンタイムを防止します
ドメインのTTLを非常に低い値（数分）に設定して、メインホストが長期間ダウンした場合に、DNSレコードを更新できるようにすることは可能ですか？メインホストでセカンダリホストのIPをポイントし、DNS伝播が終了すると、新しい訪問者をセカンダリホストのサーバーに誘導しますか？それとも、これは不可能で、おそらくばかげていますか？ダウンタイムを防ぐための安価な方法を提供します。
可能であれば、TTLにはどのくらいの低さが低すぎますか？
一部のDNSリゾルバは、特定の完全に任意のレベル未満のTTLを尊重しないため、低TTLはこれまでのところしか機能しません。 TTLを5分に設定した場合でも、変更がインターネット上のDNSキャッシュから完全にフラッシュされるまでに最大48時間かかる場合があります。この問題をさらに悪化させるのは、マルウェアの作成者がこのトリックを使用して、コマンドアンドコントロールサーバーが保持される場所を変更することです（これは「高速フラックスDNS」と呼ばれます リンク ）。したがって、これに対する対策は次のとおりです。特定のレベル未満のTTLを尊重しないようにします。
あなたがやりたいことをすることは可能であり、基準によればそれは完全に機能するはずですが、それは信頼できません。
ホストの信頼性が低く、ホストを操作する方法を見つけようとしている場合は、新しいホストを見つけることをお勧めします。そうは言っても、より低いTTLを使用して変更をより速く行うことができますが、すでに述べたように、最小のTTLを課し、設定したものをオーバーライドするリゾルバーがたくさんあります。内部最小値を下回っています。
低いTTL）の他のことは、すべてのDNSサーバーに障害が発生した場合（またはリゾルバーがいずれの場合でも少なくとも1つのサーバーに到達できない場合）、低い= TTLは、サイトが他の場合よりも早く消えます。また、より高いTTLよりも多くのルックアップが発生し、場合によっては、 DNS情報を継続的に更新する必要があるため、サイトの速度が低下します。これは、TTLをWebサイトの平均セッション長よりも長く設定することで軽減できます。
A TTL 20〜30分は不合理ではありませんが、本番環境では、一時的に必要な既知の保留中の変更が行われる予定がない限り、1時間もかかりません。低い値。
[私が言及しているいくつかの商用サービス]には、あなたが説明した正確なフェイルオーバーシナリオを採用しているクライアントがいます。
違いは、システムが完全に自動化されていることです。サーバーを監視し、DNSレコードをその場で変更します。管理者がページを取得し、ベッドから這い出し、コーヒーポットを置き、レコードを手動で変更するよりも、かなり速く反応します。また、「目が覚めたばかりの、太った指のレコード」効果の影響を受けません：D
実際の観察では、現在のクライアントの動作は、ライブサーバー上で非常に迅速にフラッディングすることです。
混乱が生じる可能性があるという事実にもかかわらず、他の唯一のオプションが完全にダウンすることである場合、クライアントの大多数が利用できることはかなり良いオプションです。
上記の48時間は、想定される使用法には存在しません。これは、レジストラレベルでの登録ネームサーバーの変更に関連するDNS伝搬時間です。これは、変更されていないネームサーバーでレコードを変更することと同じではありません。