お使いのブラウザはそうではありません。ブラウザは、ホスト名を解決するために標準のシステム コールを使用します (通常、getaddrinfo() だと思います)。 )、これらは通常 /etc/resolv.conf の内容を調べます。 設定された解決ネームサーバーを見つけてクエリを実行します。次に、デスクトップの OS のクエリを上流のサーバーに転送する (応答をキャッシュする) か、再帰的な解決を自分自身で実行します。上記のチェーンのほとんどのステップは構成可能であるため、ブラウザが実際に行うことはローカルで決定されることに注意してください。ただし、上記のシナリオは典型的なものです。
ルートサーバーを見つける方法を知る必要があるのは、そのチェーン内の再帰解決ネームサーバー (それらがローカルに構成された権限のあるネームサーバーであろうと、一部の ISP のサーバーであろうと) であり、事前に構成されたゾーンファイルを介してそれを行います。 . の場合 (これは通常、利用可能なルート ネームサーバーを照会することによって定期的に更新されます)。
編集 ：ありません。これは実装に依存しますが、私の場合 (BIND) では、1 つを選択してクエリを実行するだけです。時間内に答えが得られる限り、そこから再帰します。どんな種類の測距作戦が行われていると思いますか?
<ブロック引用>
DNS の名前解決では、ブラウザはどのようにして多くの DNS サーバーの中から利用可能な最も近い DNS サーバーを決定しますか?
他の回答が示すように、ブラウザまたは他のクライアント プログラムはこの選択を行いません。クライアント プログラムは、リゾルバーと呼ばれるライブラリを呼び出すことにより、ネーム サービスの解決を要求します。
リゾルバーは、クエリを行うためにどのサーバーに接続する必要があるかを決定します。リゾルバーの実装に依存しますが、通常 構成されている再帰リゾルバーのリストを順番に参照します (静的構成によって、または DHCP などのメカニズムを介してそれらを受信することによって)。
要約すると、(ユーザーレベルの) プログラムはリゾルバーに名前解決を要求し、リゾルバーは何らかの構成メカニズムを介して提供されたネームサーバーに要求します。
<ブロック引用>ルート サーバーが 13 あることは承知していますが、ISP の DNS サーバーはどのルート DNS サーバーに接続するかをどのように判断していますか?
これも実装依存です。 BIND でどのように動作するかを説明します。
<オール>まず、再帰ネームサーバーが、特定のドメインと通信するためにどのネームサーバーを選択するかを知っている方法について説明しましょう。ネームサーバーのルート (「.」) レベルから到達可能な各ドメインについて、そのドメインを管理する管理者は、それを含む親ドメインで、レコード タイプ NS (つまり、ネームサーバー) のリソース レコード セットを公開し、ネームサーバーにパブリックに委任します。リソース レコードで指定された、そのドメインに関係するクエリを解決する責任を設定します。
このシステムの優れた点の 1 つは、ドメイン ネーム システムと、再帰サーバーが アプリオリ を必要とする唯一のドメインの分散階層委任を可能にすることです。 knowledge は、サーバーが認識するように構成されているルート レベルです。以前は、BIND が開始時にロードした「ヒント」ファイルを介してルートの NS RRset を指定するのが最も一般的でしたが、しばらくの間、ルート サーバーによって使用される IP アドレスが BIND で事前に定義されています。 [余談:ルート ヒント ゾーンを指定することでビルトインをオーバーライドすることもできます。実際、d.root-servers.net のアドレスが最近変更されたため、新しい場所は新しい場所になるまでビルトイン リストに反映されません。新しい情報を含むバージョンの BIND がビルドされ、配布されます。現時点では、D ルート サーバーの新しい IP アドレスを含むバージョンはベータ版です。]
いずれにせよ、ここで重要なことは、各ドメインが、そのドメイン用に公表されたネームサーバーを含む NS レコード RRset に関連付けられているということです。自分でいくつか見てみるといいでしょう。ルートを見てみましょう:
$ dig . ns +edns=0 @f.root-servers.net.
回答セクションを切り取ります。これには、予測できない順序で返される NS RRset が含まれます (ここで少し詳しく説明します。順序は、一般に、話しているネームサーバーの構成によって決まります)。ルートが異なれば、異なる順序で応答する可能性がありますが、順序付けされる項目は同じである必要があります。)
;; ANSWER SECTION:
. 518400 IN NS h.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
これらはすべてルート (".") ドメインのネームサーバーであり、ルート ドメインについて質問することができます。ルート ドメインにないものについて質問すると、エラーが返されるか、別の一連のネームサーバーへの紹介が返される可能性が高くなります (たとえば、「example.com? example.com に関する質問にはお答えしません。 .com ドメイン ネームサーバーに問い合わせてみてください -- あそこにいます..")
では、BIND は NS RRset のどのネームサーバーが最速の応答を返すかをどのように知るのでしょうか?
答えは、最初はそうではありません。ただし、デフォルトの動作では、時間の経過とともに学習し、通常に落ち着きます 最短の往復時間でサーバーに問い合わせます。
往復時間と候補ネームサーバーの選択 BIND は、RRset 内のネームサーバーへのラウンド トリップ タイム (RTT) に基づいて、クエリを受信するネームサーバーを選択します。ドメインの NS RRset が初めてキャッシュに追加されると、セット内のすべてのレコードに数ミリ秒程度の小さなランダムな往復時間が割り当てられます。特定のドメインに委任されたネームサーバーに転送されると、BIND はそのキャッシュをチェックし、(うまくいけば) RRset を見つけます。セットから RTT 時間が最も短いサーバーを選択し、クエリを実行します。クエリが完了すると、BIND は NS RRset の RTT を次のように更新します。
<オール>例を見て、これがどのように機能するかを見てみましょう。再帰リゾルバーが初めてドメイン example.com に遭遇すると、example.com の NS RRset をキャッシュにロードします。 example.com の管理者が example.com の 3 つのネームサーバーを発表したとします。NS RRset は次のようになります:
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
また、この例のために、リゾルバーがこのセットの各サーバーから応答を受信するのに次の時間がかかると仮定しましょう:
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
これで、example.com NS RRset が初めて読み込まれるときに、RTT の重みが小さなランダム値でプライミングされます。したがって、example.com ネームサーバーに何かを要求する前に、RTT テーブルは次のようになります。
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
初めて example.com にクエリを実行するときは、serverc に移動して質問します。 Serverc の応答には 50 ミリ秒かかるため、クエリが完了したら、RTT テーブルを更新して次のようにします。
servera -- 7 ms // reduced by a small fraction
serverb -- 8 ms // reduced by a small fraction
serverc -- 50 ms // updated to reflect the actual round trip time.
次回は、往復時間が最も短いサーバーを選択することは明らかです。 example.com ドメインへのクエリを数回実行しただけで、どのネームサーバーが最速の応答を返すかがかなり適切にわかるはずです。
なぜ最も すべてではない 当時の？そして、「RRset 内の他のすべてのサーバーの RTT がわずかに減少している」ということについて、先ほど述べた部分はどうなっているのですか? 優先したいのですが、 最速のサーバーであるため、他のサーバーを永久に放棄したくありません。おそらく、サーバー c はほぼ常に最速のサーバーですが、最初に RTT を設定した時点では異常にビジー状態でした。サーバーが一時的にサービスを停止していて、(クエリの試行がタイムアウトした後) RTT が非常に高くなった可能性がありますが、サーバーがサービスに戻った後に再度要求を開始したいと考えています。他のサーバーの値を毎回下方に調整することで、遅かれ早かれ、私たちが好むサーバーの平均 RTT よりも低くなります。それが発生したら、彼らの方向にクエリを投げます。時間が良ければ、それは素晴らしいことです。それ以外の場合は、RTT をリセットし、優先順位リストの一番下に戻り、再び前に忍び寄ります。私たちのクエリの大部分は、セット内の最速のサーバーまたは複数のサーバーに送信されますが、異常値は定期的に試行され、条件が変更された場合、それを反映してテーブルが更新され、平均して最適なサーバーがまだ選択されていることを確認します.
13 のルート ネームサーバーは、実際には 13 のサーバーではありません。それぞれが世界中のさまざまなサイトにあるサーバーの分散クラスターであり、他のサーバーと同様に、標準の IP ルーティングを介してアクセスされます。
どれかは ISP の DNS サーバーが接続することを選択するルート ネームサーバー。これはおそらく DNS リゾルバーの詳細に依存します。完全にランダムかもしれませんし、加重されているのかもしれませんが、私にはわかりません.
編集:もしそうなら、ISP はどのように 見つける 13 のネームサーバーのいずれかである場合、それらの公開リストと、基本的にすべてのコンピューターが持つ対応する IP アドレスがあります。そこからは、1 つを選択して、インターネットのルーターに任せるだけです。