DNS の階層と解決手順

学習目標

本講を終えると、以下の問いに答えられるようになります。

• DNS の名前空間が「ルート(.) → TLD → 第二レベル → サブドメイン」の 木構造 になっていることを説明できる
• 主要なレコード型(A / AAAA / NS / MX / CNAME / TXT / SOA)の役割をそれぞれ一言で言える
• スタブリゾルバ・キャッシュリゾルバ(フルサービスリゾルバ)・権威サーバの分担を区別できる
• 再帰問い合わせと反復問い合わせの違いを、誰が誰に行うのかとあわせて説明できる
• TTL がキャッシュの有効期間であること、ネガティブキャッシュの意味が分かる
• DNS が ポート 53 / UDP を主に使い、大きい応答では TCP も使うことを述べられる
• ゾーン転送 が権威サーバ同士の同期であり、DNSSEC・DoT/DoH とは守る対象が違うことを位置づけられる

このレッスンの目次

DNS の名前空間 ── 木のような階層

名前空間の樹形図

図の見方:DNS の名前空間は ルート(.) を頂点とした木構造。FQDN(完全修飾ドメイン名)は右(ルート) から左(ホスト) へ向かって読みます。各ノードの管理は別組織に 委任(delegation) されており、上位サーバは下位サーバの所在(NS レコード)だけを覚えています。

ゾーンと委任

1 つの組織が責任を持って管理する範囲を ゾーン(zone) と呼びます。たとえば example.co.jp ゾーンの管理者は、自分の配下の www.example.co.jp や mail.example.co.jp の対応を全部知っています。さらに下に cs.example.co.jp という子ゾーンを作って別チームに任せれば、それは 委任。親は 「子ゾーンを管理しているサーバはここですよ」 という案内(NS レコード)だけを持ちます。

もっと詳しく:ルート DNS サーバはどこに?

ルートサーバは「A から M まで 13 個の ホスト名」(a.root-servers.net 〜 m.root-servers.net)で運用されています。ただし実体は 13 台 ではなく、同じ IP アドレスを世界中に複製した Anycast クラスタ として動いており、多数のサーバが各地に配置されています。問い合わせは ネットワーク的に最寄り のものに自動的に届きます。日本にも M ルートのインスタンスがあります。13 という数字の上限は、当時の DNS パケット(UDP・512 バイト) に応答を収めるための歴史的制約に由来します。

ただし、普段の名前解決で 毎回ルートサーバへ聞きに行くわけではありません。ブラウザ・OS・キャッシュリゾルバに答えや次の問い合わせ先が残っていれば、そこで解決が止まります。ルートへ問い合わせるのは、主に キャッシュリゾルバ側に手がかりがない初回 や TTL が切れた後 です。

図の見方:A〜M は「13台の機械」ではなく、13個のルートサーバ識別子です。この地図は Wikipedia 等の外部画像を使わず、この教材用に作った模式図です。それぞれの識別子を担当する組織があり、同じ識別子のサーバ実体は Anycast によって世界中に複製されています。そのため、ルートへ問い合わせが必要になった場合は、世界のどこかにあるネットワーク的に近いインスタンスへ届きます。実際の利用では、キャッシュが効けばルートまで行かずに済むことも多いです。

考えてみよう: ファイルシステムの「ディレクトリ」も似た木構造ですね。/home/alice/docs/report.txt は左(ルート) から右へたどる順序ですが、DNS は 右から左。DNS が逆向きなのは、もともと UNIX のメール経路指定の慣例(user@dept.example.org)を踏襲したものと言われています。

DNS の中身 ── レコード型

レコードの基本書式

標準的なゾーンファイルでは、1 行 1 レコードで次のように書きます。

クラスはほぼ常に IN(Internet) です。TTL はキャッシュの有効期間(秒) で、後ろのセクションで詳しく扱います。

主要レコード型のはたらき

図の見方:同じ 名前 に対して複数の型のレコードを並列に登録できますが、すべての型が必ずあるわけではありません。「メールはどこへ送る?」と聞きたいときは MX を、「IPv6 アドレスは?」と聞きたいときは AAAA を、それぞれ 型を指定して 問い合わせます。PTR は逆引き用の別ツリーで管理され、特に未登録のことも多いレコードです。SOA はゾーンに必ず 1 つあり、そのゾーンの「自己紹介カード」のような存在です。

名前解決の手順 ── ステップで追う

• スタブリゾルバ(stub resolver):アプリ(ブラウザ等) の中、または OS の名前解決ライブラリ(getaddrinfo 等)。「答えを丸投げで欲しい」係。
• キャッシュリゾルバ(フルサービスリゾルバ):ISP や組織内、または 8.8.8.8(Google) 1.1.1.1(Cloudflare) のような公開リゾルバ。本当に階層を辿って答えを集めてくる 主役。
• ルート / TLD / 中間ゾーン / 権威サーバ:階層の各層を担当する権威サーバ。それぞれ「下位の場所だけ知っている」もしくは「自分のゾーンの答えを持っている」。

完全な再帰解決を 8 ステップで体験

図の見方:スタブ ↔ キャッシュリゾルバの間は 「答えだけ欲しい」(再帰)、キャッシュリゾルバ ↔ ルート/TLD/中間ゾーン/権威の間は 「次の場所を案内してもらう」(反復)。www.example.co.jp では、co という別TLDへ行くのではなく、jp の下にある co.jp の委任をたどります。

実際によくある動き: キャッシュで止まる

実際の名前解決では、直前に見たサイトや有名なサイトほど ブラウザ/OS のキャッシュ や キャッシュリゾルバの共有キャッシュ で答えが見つかりやすい。上の 8 ステップは、キャッシュがない、または TTL が切れているときの基本形です。

再帰問い合わせ と 反復問い合わせ

再帰問い合わせ(Recursive Query)

クライアントは 1 回だけ問い合わせて、最終的な答え を受け取ります。聞かれた側は 「分からない」とは言わず、必要なら自分が他のサーバに連鎖的に問い合わせて答えを集めて来る義務を負います。

• 使われる区間:スタブリゾルバ → キャッシュリゾルバ
• クライアントの実装:超シンプル(getaddrinfo 1 回呼ぶだけ)
• サーバの負担:重い(階層を辿る・キャッシュを保持する)
• 原則として 権威サーバ自身は再帰を提供しない(オープンリゾルバ問題を避けるため)

反復問い合わせ(Iterative Query)

聞かれた側は 「自分が知っていること」だけ を返します。最終答えに至っていなくても OK。それを受けたクライアントが 次の問い合わせ先を選んで 自分でもう一度問い合わせる、を繰り返します。

• 使われる区間:キャッシュリゾルバ → ルート / TLD / 権威
• 各権威サーバは「自分のゾーン外」については案内のみ(NS / グルー) を返す
• 権威サーバの実装はシンプルで、負荷も予測しやすい
• キャッシュを得やすい(途中の答えも全部キャッシュ可能)

ステップで見る:外側は再帰、内側は反復

図の見方:左側の スタブ → キャッシュリゾルバ は再帰問い合わせ、右側の キャッシュリゾルバ → ルート/TLD/権威 は反復問い合わせです。「誰が最後まで調べる責任を持つか」が違いの中心です。

並べて比較

つながる知識: 「重労働を中継地点に集約し、エンドポイントは軽くする」設計は、HTTP の キャッシュ / プロキシ / CDN とも共通。標準編(HTTP 詳細) や発展編(CDN) で再登場します。

キャッシュと TTL ── 速さの秘密

TTL の役割

• 権威サーバが答えを返すとき、各レコードに TTL(秒) が付いている(例: 3600 = 1 時間)
• キャッシュ側は 受け取った時刻 + TTL まで保持し、その間は外に問い合わせない
• TTL を短くすると 変更が早く反映 されるが、問い合わせ回数が増える(負荷とトレードオフ)
• TTL を長くすると パフォーマンスは良いが、IP 変更が世界に行き渡るのに時間がかかる
• サーバ移行を予定するときは、事前に TTL を短く(例:60〜300 秒) しておくのが定石

ネガティブキャッシュ

「そのレコードは存在しない」という応答(NXDOMAIN) も、SOA レコードの最後の値(minimum TTL) で短時間キャッシュされます。これを ネガティブキャッシュ(RFC 2308) といいます。タイポしたドメインを連打しても、毎回権威に届かずに済む仕組みです。

図の見方:ボタンで進めると、初回の MISS、答えと TTL の保存、TTL 内の HIT、TTL 切れ後の再確認を順番に確認できます。同じ動きがブラウザ・OS・キャッシュリゾルバなど複数の場所で起こるため、更新の見え方に時間差が出ます。

考えてみよう: もし TTL を 1 秒に設定すれば変更は瞬時に伝わるが、ルートから権威までの往復が常時発生して全体が遅くなり、権威サーバの負荷も跳ね上がる。逆に 1 週間にすれば速いが間違いを直せない。「変更頻度 × 負荷」のトレードオフ をどう取るかが運用設計の腕の見せどころ。

トランスポート ── まず UDP/53

なぜ最初は UDP なのか

• DNS 1 往復は クエリ 1 個 + 応答 1 個。再送・順序保証は不要(失敗したらクライアントがタイマで再送)
• TCP のように 3 ウェイハンドシェイク をすると、それだけで 1〜2 RTT 余分にかかる
• 権威サーバは秒間数万クエリをさばく。UDP の方が 状態を持たない ぶんスケールしやすい

TCP も使うが、ここでは軽く押さえる

応答が大きすぎて UDP だけでは返しきれない場合、DNS サーバは TC ビット(truncated:切り捨て) を立てて返すことがあります。そのとき問い合わせ側は TCP/53 で同じ内容を聞き直す ことがあります。

運用とDNSセキュリティ ── ゾーン転送・改ざん対策・暗号化

安全な運用としてのゾーン転送(AXFR / IXFR)

権威サーバは プライマリ 1 台と セカンダリ(複数) で冗長化されるのが標準です。プライマリが正本のゾーンファイルを編集し、セカンダリに ゾーン転送 で同期します。

• AXFR(Authoritative Full Transfer):ゾーン全体をまるごと転送する。シンプルだが大きいゾーンでは重い
• IXFR(Incremental Transfer):差分(直近のシリアル番号以降の変更) だけを転送する。効率的
• 転送のトリガは SOA レコードの「シリアル番号」。セカンダリは NOTIFY を受けたり、定期的(SOA の refresh 値) にプライマリの SOA を見に行ったりして、シリアルが上がっていれば転送を要求
• ゾーン転送は管理用の通信。インターネット全体に晒すと情報漏えいになるため、ACL や TSIG で許可した相手だけ に制限する

図で見る:ゾーン転送の流れ

図の見方:ゾーン転送は「利用者が名前解決する流れ」ではなく、権威サーバ同士が裏側で同期する流れです。SOA シリアル番号で更新有無を判断し、必要なときだけ IXFR / AXFR でセカンダリを最新化します。

DNSセキュリティの守備範囲

つながる知識: ゾーン転送は 運用者どうしの裏側の同期、DNSSEC は 返ってきた答えが改ざんされていないか、DoT/DoH は 問い合わせの通信路を暗号化する 技術です。同じ「DNSの安全」でも、守っている場所が違います。

まとめと用語チェック

用語チェック

確認問題