DNSラウンドロビン：ブラウザーは、オンラインである限り1つのIPに固執しますか？

DNSサーバーから複数のAレコードを取得した場合、ほとんどのブラウザーはどのように動作しますか？到達可能な限り、1つのIPにスティックします（IPがダウンしている場合にのみ別のIPを使用します）。それとも、彼らは理由もなく常に切り替えますか？

現在のブラウザの大部分が1つのIPに固執している場合、DNS-RRは単純なフェイルオーバーソリューションとして十分です。

ブラウザーごとにラウンドロビンDNSを処理する独自の方法があります。今日、この問題の調査に時間を費やし、実装の証拠を見つけてその応答を更新し続けます。

グーグルクローム

Google Chrome（v58を使用）は、アドレス（A、AAAA、CNAME）のすべてのホストエントリを要求し、それらを配列（address_list）に入れます。その後、Chromeは最初から最後まで順番に各IPアドレスでソケットを開こうとします。Chromeは最速または最も近いIPを試みず、最初のIP（上流のDNSリゾルバによって与えられた）が最適なIPであると想定します。私のテストでは、バインドとWindows DNSサーバーはルックアップごとに異なるIP順序を与え、各IPに帯域幅が50/50に分割されているように見えます。この機能はchrome://net-internals/#events&q=type:SOCKET%20is:active

カール（libcurl / 7.54.0）

Curlにもこのフェイルオーバー機能がありますが、これ--connect-timeoutはChromeのデフォルトよりもはるかに長く、Chromeにはありません。libcurlを使用し、1つのIPが失敗するラウンドロビンdnsインスタンスを存続させたい場合（クロムでは動作しますが、コードでは動作しません）、この値を低く指定してください。

DEFAULT_CONNECT_TIMEOUT：0は、curlではこれが不可能だと思いました。

* After 149990ms connect time, move on!

両方のブラウザーで、IPはスティッキーではなく、DNSで指定されたTTLに従い、そのttlが期限切れになると（クロムは内部でこれを維持し、各要求でcurlが要求します）、上記のように毎回IP選択が実行されます。

これは何を意味するのでしょうか？DNS-RRは一部のシステムでは問題ありませんが、フェイルオーバー用には設計されていません。DNSルックアップのすべての結果が（真実のソース）有効であり、トラフィックを処理するために利用可能であることを期待する必要があります。仮想フロートIP、BGP /ルーティングトリックなど、IPの可用性を確保する方法は多数あります。それらを使用します。

IPv4のみの環境で実行されるすべてのテストは、テストするのに十分なインフラストラクチャが利用可能になると、デュアルスタックの結果で戻ります。

これらの変更はIPv6-Fallback RFC Happy Eyeballsの副作用であると推測します

更新 有用な考慮事項として、RR DNSは、ノードの1つに503がある場合、トラフィック503の場合に40〜60％を提供する場合、アプリケーション障害ではなく負荷分散のみを支援できます。到達可能であれば、リストされているすべてのIPが有効な作業エンドポイントであると仮定されます。

edit：HiPerFreakが教えてくれたので、答えを編集します。

DNSサーバーは、指定されたホスト名に対して持っているすべてのAレコードのリストを返します。ラウンドロビンの出番は、リストの順序を回転させることです。投稿されたリンクは、Webブラウザーがそのリストをどのように利用するかの良い例です。

ラウンドロビンは、非常に原始的な形式のロードバランシングに使用できますが、ラウンドロビンローテーションのホストの1つがダウンした場合、DNSサーバーは賢くならず、まだ実際のロードバランシングの代替としては非常に貧弱です。ダウンしたノードのIPアドレスをリストに追加します。

これを参照してください私の質問（および回答）：ブラウザが複数のIPを処理する方法。

まもなく-ラウンドロビンDNSは可用性をまったく改善しません。ブラウザは、応答しない場合でも1つのIPを選択し、それに固定します。（FFおよびクロムでチェック）。

ブラウザのDNSキャッシュの有効期限が切れると、IPが応答したかどうかに関係なく、ホスト名が再び解決され、プロセスが繰り返されます。

基本的なHAの場合、動的DNSまたはさまざまなIPベースのアプローチを使用できます。

編集：この動作は、アクセスできないホストが「ブラックホール」として機能する場合に発生します。代わりにホストが着信接続を実際に拒否する場合、ブラウザは1つのIPを試行し、拒否を取得し、すぐに別のIPを使用するため、非常にうまくフェールオーバーします。

IPを切り替えますが、これはフェールオーバーソリューションではありません。

ブラウザはOSに名前解決を行わせます。たとえば、Linuxでは常にIPアドレスがランダム化されるため、google.comを数回ホストしてみてください。IPはランダムな順序で到着します。

DNSはリスト内のすべてのIPを返しますが、リストの順序を変更します。この順序はランダムではなく、1が失敗したときに変更されますが、ロードバランシングの理由で常に同じ順序でIPを返します。ブラウザーがリストを受信するとき、非稼働として知られていない場合、リストの1番目を選択すると思います。