☰

ブラウザはどのようにして最も近い DNS ルート サーバーを見つけるのでしょうか?

tag-icon • tag-icon linux dns
ブラウザはどのようにして最も近い DNS ルート サーバーを見つけるのでしょうか?

DNS 名前解決において、ブラウザは多数の DNS サーバーの中から利用可能な最も近い DNS サーバーをどのように決定するのでしょうか?

ルート サーバーが 13 個あることはわかっていますが、ISP の DNS サーバーはどのルート DNS サーバーに接続するかをどのように知るのでしょうか?

答え1

ブラウザはそうしません。ブラウザはホスト名を解決するために標準のシステム コール (通常は だと思いますgetaddrinfo()) を使用し、通常は のコンテンツを調べて、/etc/resolv.conf設定されている解決ネームサーバーを探し、クエリを実行します。次に、デスクトップ OS のクエリを上流サーバーに転送するか (応答があればキャッシュする)、ブラウザ自体で再帰的な解決を実行します。上記のチェーンのほとんどのステップは設定可能であるため、ブラウザが実際に行うことはローカルで決定されることに注意してください。ただし、上記のシナリオは一般的なものです。

ルート サーバーの検索方法を知る必要があるのは、そのチェーン内の再帰解決ネーム サーバー (ローカルに構成された権威ネーム サーバーであっても、その先の ISP のサーバーであっても) であり、それらのサーバーは、事前に構成されたゾーン ファイル.(通常は、利用可能なルート ネーム サーバーを照会することによって定期的に更新されます) を介してそれを行います。

編集: そうではありません。実装に依存しますが、私の場合 (BIND) では、1 つを選択してクエリを実行するだけです。時間内に回答が得られれば、そこから再帰的に処理されます。何らかの範囲指定操作が行われていると考える根拠は何ですか?

答え2

DNS 名前解決において、ブラウザは多数の DNS サーバーの中から利用可能な最も近い DNS サーバーをどのように決定するのでしょうか?

他の回答が示すように、ブラウザや他のクライアント プログラムはこの選択を行いません。クライアント プログラムは、リゾルバと呼ばれるライブラリを呼び出して、ネーム サービスの解決を要求します。

リゾルバは、クエリを実行するためにどのサーバーに接続するかを決定します。これはリゾルバの実装に依存しますが、いつもの静的構成または DHCP などのメカニズムを介して受信することによって構成された再帰リゾルバのリストを順番に参照します。

要約すると、(ユーザーレベルの) プログラムはリゾルバに名前解決を要求し、リゾルバは何らかの構成メカニズムを介して提供されたネームサーバーに要求します。

ルート サーバーが 13 個あることはわかっていますが、ISP の DNS サーバーはどのルート DNS サーバーに接続するかをどのように知るのでしょうか?

これも実装に依存します。BINDでどのように動作するかを説明します。

  1. BINDは非常に人気のあるネームサーバーであり、ISPがそれを使用している可能性はかなり高いです。
  2. ISP が BIND を使用していない場合でも、いくつかの代替手段では、NS リソース レコード セットからネーム サーバーを選択するための同様のメカニズムを使用します。

まず最初に、再帰ネームサーバーが特定のドメインと通信するためにどのネームサーバーを選択すべきかをどのように認識するかについて説明します。ネームサーバーのルート (".") レベルからアクセス可能な各ドメインについて、そのドメインを管理する管理者は、そのドメインを含む親ドメインで、レコード タイプ 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 を次のように更新します。

  1. クエリされたばかりのサーバーの RTT は、実際のラウンドトリップ時間に設定されます。
  2. RRset 内の他のすべてのサーバーの RTT はわずかに削減されます (約 3 ～ 4% だと思います)。

例を一つずつ見ながら、これがどのように機能するかを見てみましょう。再帰リゾルバがドメイン 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.

次回は、当然、往復時間が最短のserveraを選択します。example.comドメインに数回クエリを実行しただけで、どのネームサーバーが最も速い応答を返すかがかなりわかるはずです。その後は、そのサーバーを優先します。ほとんど当時の。

なぜほとんど時間の全て時間の？そして、先ほど述べた「RRset内の他のすべてのサーバーのRTTはわずかに減少する」という部分はどういうことでしょうか？好む最速のサーバーを選択する場合、他のサーバーを永久に無視したくはありません。サーバー c はほとんどの場合最速のサーバーですが、最初に RTT を設定した時点では異常にビジー状態だった可能性があります。サーバーが一時的にサービス停止になり、RTT が非常に高くなった可能性があります (クエリの試行がタイムアウトした後)。ただし、サービスが再開されたら再度クエリを開始する必要があります。他のサーバーの値を毎回下方に調整すると、遅かれ早かれ、優先するサーバーの平均 RTT よりも低くなります。その場合、そのサーバーにクエリを送信し、時間が短縮されれば問題ありません。そうでない場合は、その RTT をリセットし、優先順位リストの一番下に戻りますが、再び先頭に戻ります。クエリの大部分は、セット内の最速のサーバーに送信されますが、外れ値も定期的に試行され、条件が変更された場合にテーブルが更新されてそれが反映され、平均して最適なサーバーが選択されていることを確認します。

答え3

13 個のルート ネーム サーバーは、実際には 13 個のサーバーではありません。各サーバーは、世界中のさまざまなサイトにある分散型サーバー クラスターであり、他のサーバーと同様に、標準の IP ルーティングを介してアクセスされます。

はどうかと言うとどれのISP の DNS サーバーが接続することを選択するルート ネーム サーバーは、DNS リゾルバーの詳細によって異なる可能性があります。完全にランダムである場合もあれば、重み付けされている場合もありますが、それはわかりません。

編集：もしあなたがおっしゃっているのであれば、ISPは探す13 個のネームサーバーのいずれか 1 つを指定すると、それらのネームサーバーと、基本的にすべてのコンピューターが持つ対応する IP アドレスの公開リストが存在します。そこから、1 つを選択して、インターネットのルーターに残りの処理を任せるだけです。

関連情報