DNSでサーバーのバックアップIPを設定できますか？

DNSプロトコルがバックアップネームサーバーやメールサーバーのレコードのようなバックアップAレコードサーバーアドレスを自然に保持できる方法はありますか？これを検索したところ、バックアップネームサーバー（NSレコード）の結果のみが表示されました。

DNSがバックアップAレコードをサポートする方法がない場合、プライマリサーバーが応答しない場合に、ユーザーが稼働中のサーバーに転送されるように結果をシミュレートする最良の方法は何ですか？

はい...ちょっと。

ここでできることは2つあります。ある名前のDNSサーバーに複数のAレコードを置くと、それらはすべてクライアントに提供され、それらのクライアントはセットから1つを選択して接続します。つまり、トラフィックはすべてのサイトに同時に「公平に」均等に分配されます。これは実際にあなたが説明しているようではありませんが、それは一般的な状況です（さまざまな理由で、私はそれを信頼していません）。

もう1つのオプションは、DNSサーバーにAレコードを1つだけ配置し、DNSサーバー（または監視スクリプトなどのそれに付随するもの）がサイトのメインアドレスを監視し、失敗した場合はDNSサーバーのAレコードは他のサイトに変更されます。これは、一度に1つのサイトだけがトラフィックを受け取ることを意味します。

この2番目の戦略の欠点は、DNSキャッシングです。古いサイトアドレスを取得したユーザーは、古いアドレスを含むDNSキャッシュエントリが削除されるまでSOLになります。これは、TTLを低く保つ必要があることを意味します（DNSインフラストラクチャの負荷が増加しますが、実際には問題になることはめったにありません）が、TTLを尊重しない「悪意のある」DNSキャッシュの問題がまだあります。これらは誰にとっても大きな痛みです DNSエントリを変更する必要がある人はいますが、DNSエントリを「頻繁に」変更する必要がある人にとっては、100万倍も悪いものです（おそらく、サイトが1日に数回ダウンしていないことを願っていますが、それでも...）基本的に、誰もがこれらの不正なDNSキャッシュの1つの背後にあると、サイトが極端に長い期間「ダウン」していると見なされ、DNSキャッシュに問題があることを説明してみます。

要するに、あなたが考えているリスクを軽減するより良い方法があるので、私はサイトに対してそれをしませんが、それを軽減する方法についての提案が必要な場合はそのリスクを説明する必要があります。

あなたが明示的に書いたにもかかわらず、誰もがあなたがWWWサーバーについて話していると思っているようです

バックアップネームサーバーやメールサーバーのように

SRVリソースレコードは、クライアントが優先順位と重みで、サーバーのリストを言われると、優先順位の順序でサーバを試すために必要とされている、重量に応じて同じ優先順位を持つサーバー間で摘み、より頻繁に低い加重よりも、加重のサーバーを選択しますもの。したがってSRV、サーバー管理者はリソースレコードを使用して、フォールバックサーバーとは何か、および優先順位が等しい一連のサーバー間で負荷を分散する方法をクライアントに伝えることができます。

現在、コンテンツDNSサーバーは、独自のリソースレコードの特別なタイプのリソースレコードによって配置されています。リソースレコードには、NS優先度と重みの情報はありません。同様に、SMTPリレーサーバーは、独自の特別な種類のリソースレコードによって配置されますMX。これには、優先度情報はありますが、重み付け情報はありません。したがって、コンテンツDNSサーバーの場合、フォールバックおよび負荷分散情報を公開するためのプロビジョニングはありません。MXリソースレコードを使用している場合、SMTPリレーサーバーの場合、負荷分散情報を公開するための準備はありません。

ただし、にSRV対応したMTSは現在存在しています。（第一号だったeximとなっていた、SRV2005年以来-capable）とのために他の荷物と邪魔されないサービスプロトコル、MXおよびNSリソースレコード、SRV採用ははるかに徹底的かつ広範囲に及んでいます。たとえば、Microsoft Windowsドメインを使用している場合、一連のサービス全体SRVがDNSでのルックアップによって検索されます。この時点で、それは10年以上の間当てはまります。

問題は、誰もがHTTPを考えているということです。HTTPが断然、今日の2011年には例外であり、ここでのルールではありません。

動的コンテンツを提供していて、2つのサーバーが同時にコンテンツを提供するだけでは実用的でない場合は、とにかくDNSに複数のレコードを用意し、バックアップサーバーを設定して、接続しようとするクライアントに到達できないICMPポートをスローするようにします。 ; いずれかの時点でメインサーバーがダウンした場合は、バックアップのポート80ブロックを削除するだけで、トラフィックが入り始めます。

他にできる唯一の（予算）方法は、リクエストでNATを実行するために別のマシン（または2つ）をセットアップすることです。したがって、Webサーバーが停止した場合でも、NATルールを削除できます。

バックアップAレコードはありませんが、ランダムな順序で与えられる複数のAレコードが存在する可能性があります。

ほとんどのブラウザは、1つのサーバーに障害が発生した場合に別のサーバーを試すことができます。（参照：ラウンドロビンDNSによるWebの回復力）

VRRPまたはCARPを備えた複数のサーバーによってバックアップされた1つのクラスターIPアドレスを持つことができます。プライマリサーバーに障害が発生すると、バックアップサーバーがアドレスを引き継ぎます。

はい、しかしあなたはそれを自分でしなければなりません;-)

なぜ「バックアップAレコード」が必要なのか、またどのようにしてどのような状況でバックアップに行きたいのかについて、詳しい情報を教えてください。

また、プライマリホストとバックアップホスト間のネットワークの観点から関係を理解し​​ておくと役立ちます。

これはかなり古い質問ですが、2つのかなり重要なテクノロジー、つまり動的DNSとCDNは回答に含まれていません。

動的DNSは、DNSレコードをほぼリアルタイムで変更できるように設定されているため、監視クライアントは、サービスの可用性に応じてパブリックDNS Aレコードへの変更をトリガーできます。（もちろん、DNSホスティングサービスは動的DNSをサポートしている必要があります。）

CDNはDNSを配信するためにも使用できます。たとえば、Cloudflareは（2010年にローンチしたと思います）のように。