DNS：名前から接続先へ、紹介をたどる

URLを開くと、どうやって接続先のIPアドレスが分かるのか。再帰問い合わせ、紹介、権威サーバー、TTLとキャッシュを7ページで追う。

名前から、接続先を探す

ブラウザで https://shop.example.com/products を開きます。人には名前が読みやすくても、通信の相手を選ぶにはアドレスの情報が必要です。DNSは、名前に対応するレコードを調べる仕組みです。

この作品では、ホスト名 shop.example.com のAレコードからIPv4アドレスを得る流れを追います。/products はHTTPで扱うパスであり、DNSへの問い合わせには含めません。名前とアドレスは説明用です。

DNSにはAAAAやMXなどもあります。「どんな名前でも、IPアドレスを一つだけ返す仕組み」ではありません。RFC 1034

ブラウザやOS、利用しているリゾルバーに、使えるキャッシュがあれば近道できます。ここでは有効な答えがない場合を考えます。

利用側は、リゾルバーに「答えまで調べてほしい」と依頼します。これが再帰問い合わせです。リゾルバーは必要に応じて他のDNSサーバーを訪ね、結果を利用側へ返します。

どの層がどんなキャッシュを持つかは実装や設定によります。以降は、リゾルバーにも途中の情報がないと仮定した、基本的な経路です。

リゾルバーがルートサーバーに問い合わせると、この例では .com を担当するサーバーの情報が返ります。ルートが shop.example.com の最終的なアドレスを知っている必要はありません。

担当を紹介し、その紹介先へリゾルバーが問い合わせる。この分担によって、世界中の名前を一か所で管理せずに済みます。サーバー間を利用者のブラウザ自身が順番に移動する図ではありません。

紹介先をたどる流れは反復問い合わせの基本です。RFC 1034：名前解決

次にリゾルバーは .com のサーバーへ問い合わせます。ここでは example.com を担当する権威サーバーが紹介されます。

DNSの名前空間は木の形をしていますが、管理を委ねる境界であるゾーンと、名前のすべての区切りが常に一致するわけではありません。shop というラベルがあるからといって、必ずもう一段別のサーバーへ行くわけでもありません。

今回の設定では、example.com の権威サーバーが shop.example.com のAレコードを持っています。

権威サーバーが 203.0.113.8 とTTL 60秒を返すとします。権威サーバーは、そのゾーンのデータを提供する立場です。リゾルバーの一時的なキャッシュとは役割が違います。

TTLは、受け取ったデータをキャッシュしてよい時間の目安です。図では一つのAレコードだけを示しました。実際には複数のアドレス、CNAMEによる別名への解決などが加わることもあります。

DNSでアドレスが分かっても、ページ本文はまだ取得していません。この後に接続確立やHTTPのやり取りが続きます。RFC 1034：TTL

リゾルバーは答えを利用側へ返し、キャッシュします。通信時間などを省略すると、20秒後の再問い合わせでは残りTTLは40秒です。条件が合えば、この答えを使い、ルートからたどり直す必要はありません。

図の戻る矢印はDNSの応答です。Webページの本文がリゾルバーを通って届くという意味ではありません。ブラウザは得た接続先を、その後の通信に使います。

よく使われる名前ほど、名前解決の説明図に描かれた全行程を毎回実行するとは限らないのです。

答えはいいえです。各キャッシュはそれぞれの残りTTLを持ちます。権威サーバーの設定を変えても、既存のキャッシュへ一斉に新しい答えが押し込まれるわけではありません。

通常の流れでは、期限が切れた後の問い合わせで新しい答えを得ます。障害時に期限切れデータを使う拡張などは、この図の対象外です。TTLを下げる変更も、以前の長いTTLで保存されたキャッシュをさかのぼって消すことはできません。

名前を探す → 担当をたどる → 答えを期限つきで再利用する。この三つを分けると、DNSの変更に時間差が出る理由が分かります。