DNSは、ウェブサイトをどう見つけるのか

私たちが普段ブラウザにURLを入力したりリンクをクリックしたりすると、一瞬で目的のWebページが表示されます。しかしインターネット通信において、コンピュータ同士は「example.jp」のような文字の名前を直接の宛先にして通信しているわけではありません。ルーターなどの通信機器がデータを届ける宛先を特定するには、固定長の数値である「IPアドレス」が必要です。

人間にとって分かりやすいドメイン名を入力するだけで目的のサーバーへ迷わず接続できるのは、裏側で「DNS（Domain Name System）」が働き、名前とIPアドレスを結びつけているからです。DNSは単一の巨大な電話帳ではなく、世界中に分散する管理者が協力し、キャッシュを巧みに活用しながら目的のWebサイトを見つけ出しています。

1. 人が読む「名前」と機械が扱う「IPアドレス」をつなぐ仕組み

ブラウザに入力する「https://www.example.jp/index.html」のようなURLの中で、接続相手のコンピュータを特定する名前が「www.example.jp」というドメイン名（ホスト名）です。インターネットのルーターなどの通信機器は、固定長の数値であるIPアドレス（IPv4の32ビットやIPv6の128ビット）をもとに高速な経路制御を行っています。文字のドメイン名からIPアドレスを調べる必要があるのはこのためです。また、名前とIPアドレスを切り離しておくことで、サーバーの移転などでIPアドレスが変わっても、DNSの設定を更新するだけで利用者は同じドメイン名のまま接続を継続できます（なお、物理的なサーバー移転でもネットワーク構成によっては同じIPアドレスを引き続き利用できる場合があり、物理移転とIP変更が常に1対1とは限りません）。

世界中に無数に存在するドメイン名を単一のサーバーで一元管理することはできません。そこでDNSは、名前空間を「ゾーン」という管理単位に分割し、それぞれのゾーンの管理権限を各地の管理者に委任（delegation）する「自律分散型データベース」として設計されています（RFC 1034、RFC 9499）。これにより、単一障害点を作ることなく世界規模の安定運用を実現しています。

さらに、DNSが扱う情報はIPアドレスだけではありません。DNSが保持するデータは「リソースレコード」と呼ばれ、用途に応じて以下のような多様な種類が存在します（RFC 1034、RFC 9499）。

• Aレコード / AAAAレコード：ドメイン名に対応するIPv4アドレス（A）やIPv6アドレス（AAAA）を定義します。
• CNAMEレコード（Canonical Name）：あるドメイン名を別のドメイン名に関連付ける別名レコードです。Webサーバーが別のURLへ誘導する「HTTPリダイレクト」とは異なり、DNSの名前解決の段階で別の名前を参照させる仕組みです。
• MXレコード：電子メールの配送先メールサーバーを指定します。
• NSレコード：そのゾーンの情報を管理する権威ネームサーバーを指定する委任レコードです。
• TXTレコード：送信ドメイン認証やドメイン所有権の確認などに使われる汎用的なテキスト情報です。
• PTRレコード：IPアドレスからドメイン名を調べる逆引き用のレコードです。
• SOAレコード（Start of Authority）：ゾーンの管理情報やシリアル番号、更新間隔、ネガティブキャッシュの有効期間などを定義します。

このようにDNSは、Webサイトへの接続だけでなく、メール配送や認証などインターネットの多様な基盤機能を支えています。

2. 名前解決の基本ステップ：分散された権威サーバーをたどる旅

DNSの名前空間は、右から左へと階層が深くなる木構造（ツリー構造）を形成しています。「www.example.jp」であれば、右端の目に見えないルート（.）を頂点として、「jp」（トップレベルドメイン：TLD）、「example.jp」（第2レベルドメイン）、「www」（ホスト名）という階層関係になっています。各階層には、自身の担当範囲（ゾーン）について正確なデータを持つ「権威ネームサーバー」が存在します。

ユーザーの端末内にある「スタブリゾルバー」は、プロバイダ（ISP）やパブリックDNSが提供する「フルサービスリゾルバー（キャッシュDNSサーバー）」に解決を依頼します。過去のキャッシュが手元にない基本状態を想定すると、フルサービスリゾルバーは以下のステップで世界中の権威サーバーを順にたどる「反復問い合わせ」を行います。

1. ルートサーバーへの問い合わせ：リゾルバーはまずルートサーバーに問い合わせます。ルートサーバーは「.jp のことなら jp 権威サーバーが知っている」として、jp 権威サーバーの場所（NSレコードと付随するIPアドレス）を案内します。
2. TLDサーバーへの問い合わせ：案内された jp 権威サーバーに問い合わせると、「example.jp のことなら example.jp 権威サーバーが管理している」として、その権威サーバーを案内されます。
3. 目的の権威サーバーへの問い合わせ：example.jp 権威サーバーに問い合わせると、正当な権威データから「www.example.jp のAレコードは 192.0.2.1」という確定的な最終回答が返されます。
4. クライアントへの回答：リゾルバーはこのIPアドレスを端末に返し、端末は目的のサーバーにアクセスできるようになります。

なお、権威サーバーから返る最終回答はAレコードだけでなく、別の名前を参照させるCNAMEレコードや、存在しないことを示すエラー（NXDOMAIN）の場合もあります。また、従来の問い合わせでは完全なドメイン名をルートサーバー等に送信していましたが、プライバシー保護のために必要な最小限の名前だけを上位に尋ねる「QNAME最小化（RFC 9156）」の導入も進んでいます。

DNSツリーの頂点に立つルートサーバーは、かつて「世界に13台しかない」と誤解されることがありましたが、実際には「a.root-servers.net」から「m.root-servers.net」までの「13の論理的な識別名（レター）」として管理されています（RFC 9499）。それぞれの論理識別名は単一のコンピュータではなく、「IPエニーキャスト」技術によって世界中の数百〜千カ所以上のデータセンターに分散配置されたサーバー設備群で協調運用されています。これにより高い耐障害性を確保しています。なお、エニーキャストの接続先はBGPの経路制御に基づいて決定されるため、地理的に最も近い拠点がネットワーク上で常に選ばれるとは限らない点も特徴です。

IPアドレスが端末に届いた時点で、DNSの名前解決は完全に終了します。その後にブラウザがWebサーバーと行う通信（TCP接続やTLSハンドシェイク、QUICによるHTTP通信など）は、DNSとは通信プロトコルも相手も異なる「独立したWeb通信」です。

3. キャッシュによる探索のショートカットと3つの分岐

もし世界中の端末がWebページを開くたびにルートサーバーから順に問い合わせていれば、上位サーバーは過負荷でパンクし、Webの表示も著しく遅くなります。DNSが世界規模で高速かつ安定して動作しているのは、一度得た結果を一時的に保存して再利用する「キャッシュ」が機能しているからです。毎回すべての階層を問い合わせる必要はありません（RFC 1034）。

キャッシュはブラウザ、OS、宅内ルーター、そしてISP等のフルサービスリゾルバーといった通信経路の各段に保持されます。リゾルバーに問い合わせが届いたとき、キャッシュの保持状況によって探索経路は大きく3つに分岐します。

1. 【分岐①：回答キャッシュからの即答】

探しているレコード（例: www.example.jp のAレコード）そのものが有効期限内のキャッシュにあれば、外部の権威サーバーに一切問い合わせることなく、手元のデータからクライアントへ即座に回答します。

1. 【分岐②：委任情報キャッシュを活用した途中階層からの直接問い合わせ】

目的のAレコード自体はなくても、「jp 権威サーバー」や「example.jp 権威サーバー」の委任情報（NSレコード等）がキャッシュにあれば、リゾルバーはルートやTLDへの問い合わせを省略し、該当する権威サーバーへ直接問い合わせます。これにより探索の手間が大幅に短縮されます。

1. 【分岐③：委任情報もない場合のルートからの完全探索】

回答も委任情報も手元にない（または期限切れの）場合にのみ、第2節で述べたルートサーバーからの反復問い合わせが実行されます。

上記の図は、端末からWebサーバーへアクセスする際の名前解決フローと通信構造を示したものです。重要なポイントは、DNSの探索が常に「ルート→TLD→権威サーバー」という一本道を強制されるのではなく、キャッシュの有無によって「①回答キャッシュからの即答」「②委任情報キャッシュによる途中階層からの直接問い合わせ」「③委任情報がない場合のルートからの探索」という3つのルートに分岐する点です。また、IPアドレス判明後に端末がWebサーバーと直接行うWeb通信（HTTPSなど）が、DNSの問い合わせとは明確に分離された独立系統の通信であることも示されています。

なお、この図は名前解決の論理的な概念モデルを提示したものであり、実際の通信のすべてを網羅しているわけではありません。端末側にあるブラウザやOS、宅内ルーターの多段キャッシュや、遅延・障害に伴う動的なサーバー選択、再送処理といった詳細な挙動までは表現されていない点に留意して読み解く必要があります。

4. キャッシュの寿命「TTL」と例外的な動作仕様

キャッシュは名前解決を高速化しますが、古い情報を永久に保持し続けるとサーバーの移転やIPアドレスの変更に追従できません。そのため、DNSレコードにはキャッシュの有効期限を秒単位で指定する「TTL（Time To Live）」が設定されています（RFC 1034、RFC 9499）。たとえばTTLが「3600」であれば、取得から3,600秒（1時間）の間だけキャッシュを再利用できます。

通常、TTLを経過したキャッシュデータは無効とみなされ、リゾルバーは権威サーバーへ再問い合わせを行って最新データを取得します。

しかし、もしドメインを管理する権威サーバーが障害や攻撃で停止していた場合、厳格に期限切れキャッシュを破棄するとWebサイトへのアクセスが途絶えてしまいます。この問題を緩和するために策定されたのが「RFC 8767（Serving Stale Data to Improve DNS Resiliency）」です。この仕様を実装したリゾルバーでは、権威サーバーへの問い合わせがタイムアウトやエラーになった非常時に限り、一時的に有効期限の切れたデータ（stale data）を取り出して回答することが例外的に認められています。最新性の確認を試みつつも、障害時には過去のデータを用いて名前解決を継続させ、インターネット全体の可用性を維持します。

また、DNSがキャッシュするのは成功結果だけではありません。「ドメイン名が存在しない（NXDOMAIN）」や「要求されたレコード種別が存在しない（NODATA）」という失敗結果も、権威サーバーへの無駄な負荷集中を防ぐために一定期間キャッシュされます。これを「ネガティブキャッシュ（RFC 2308）」と呼びます。

ネガティブキャッシュの有効期間は、通常のTTLとは異なるルールで決まります。該当ゾーンのSOAレコード自体の「TTL」と、SOAレコード内に設定された「MINIMUMフィールド」の数値を比較し、「小さい方の値」が保持期間として採用されます。ドメイン設定の反映前に誤って問い合わせてしまうと、このネガティブキャッシュがリゾルバーに記録され、サーバー側の設定を修正した後でも期限が切れるまで「存在しない」というエラーが返され続けることになります。

5. DNSの変更が「すぐには反映されない」本当の理由

DNS設定を変更した際、反映に時間がかかる現象を「世界中のサーバーに情報が浸透していく」と表現することがありますが、これは不正確です。実際には、以下の2つの全く異なる時間差要因によって発生しています。

• 要因①：権威サーバー間での公開・同期遅延（ゾーン転送とDNS NOTIFY）

耐障害性を高めるため、多くのゾーンではプライマリとセカンダリの複数の権威サーバーを運用しています。プライマリで設定を変更した後、その内容がセカンダリへ複製される必要があります。これには「ゾーン転送」が用いられ、変更を速やかに伝える「DNS NOTIFY（RFC 1996）」の仕組みがあっても、同期間隔や通信状況によって数秒から数十分程度のタイムラグが生じます。同期が完了するまでは、問い合わせ先となる権威サーバーによって新旧どちらの情報が返るかが定まりません。

• 要因②：世界中のリゾルバーに残るキャッシュのTTL

権威サーバー側の同期が完了しても、世界中のフルサービスリゾルバーや端末は、手元にある古いレコードをTTLが切れるまで保持し続けます。キャッシュを取得したタイミングはリゾルバーごとに異なるため、ある環境ではすぐに新サーバーへ切り替わり、別の環境では古いIPアドレスが返り続けるという時間差が生じます。

実務上の対策として、移転作業の数日前に対象レコードのTTLを短い値（例: 300秒＝5分）に変更しておく手法が広く用いられます。これにより、切り替え後は最長でも5分程度で古いキャッシュが破棄され、新サーバーへ移行しやすくなります。

ただし、これによって「確実に最大5分で全世界が切り替わる」という無条件の保証はありません。以下の重要条件に留意する必要があります。

• 対象のAレコードだけでなく、IPv6用のAAAAレコードやCNAMEレコード、親ゾーンの委任情報（NSレコード）のTTLなども漏れなく調整されているか。
• 一部のISPやリゾルバー製品において、極端に短いTTLを無視して独自の下限値（ミニマムTTL）でキャッシュを保持し続ける実装が存在する可能性。

そのため、実務ではDNS切り替え後も旧サーバーを即座に停止させず、数日から数週間程度は新旧両サーバーを並行稼働させておくのが安全設計の定石です。

6. DNSの安全性を支える技術とそれぞれの役割

従来のDNS通信は、暗号化されていないバイナリメッセージ（UDP/TCPの53番ポート）でやり取りされます。効率的である反面、通信途中で偽の回答を送り込む「DNSキャッシュポイズニング」や、通信内容の盗聴といったリスクを抱えていました。これらを防ぐために複数のセキュリティ技術が使われていますが、それぞれの保護範囲と限界を正しく区別することが重要です。

• DNSSEC（DNS Security Extensions: RFC 4033等）

電子署名を用いて、権威サーバーから届いたレコードの「出所」と「完全性（改ざんされていないこと）」を検証します。偽のIPアドレスをキャッシュに刷り込む攻撃を防ぎます。ただしレコードの正当性を証明するものであり、通信自体を暗号化するわけではないため盗聴は防げません。

• DoH（DNS over HTTPS）および DoT（DNS over TLS）

端末とフルサービスリゾルバーとの間の通信区間を暗号化します（RFC 8484、RFC 7858）。公衆Wi-Fiや通信事業者による問い合わせ内容の盗聴や改ざんを防ぎます。ただしこれは端末とリゾルバー間の「通信区間」を保護するものであり、権威サーバーにあるデータの正当性を保証するものではありません。

• HTTPS（Web通信の保護）

名前解決の完了後に、端末とWebサーバーの間で行われるWeb通信全体を保護します。サーバー証明書によって正規のドメインであることを確認し、送受信データを暗号化します。

ここで最も重要なのは、「これらのセキュリティ技術が完全に機能していても、そのWebサイトの内容や運営者が信用できることまでは保証されない」という点です。フィッシング詐欺サイトであっても、正当にドメインを取得してDNSSECやHTTPSを有効に設定することは容易です。DNSのセキュリティ技術はあくまで「名前解決の正確性と通信経路の安全性」を守る道具であり、サイトそのものの信用性を判断するのは利用者自身であるという境界を忘れてはなりません。

おわりに

私たちがブラウザにドメイン名を入力してからWebページが表示されるまでのわずかな間に、DNSは自律分散された権威サーバーの階層、世界に分散配置されたルートサーバー、そして多段のキャッシュを連携させながら目的のサーバーを見つけ出しています。

DNSは単に名前をIPアドレスに変換するだけでなく、キャッシュによる高速化や可用性を高める例外処理（RFC 8767）、寿命管理（TTL）、セキュリティ拡張によって支えられたインターネットの基盤です。その仕組みと前提条件、技術ごとの役割の境界を正しく把握することが、安定したWeb運用の土台となります。