DNS - インターネットの「電話帳」はどう動いているのか
ブラウザに example.com と入力すると、瞬時にそのサイトが表示されます。しかし、コンピューターが通信に使うのはドメイン名ではなく IP アドレス (例: 93.184.216.34) です。ドメイン名を IP アドレスに変換する仕組みが DNS (Domain Name System) です。
DNS は 1983 年に Paul Mockapetris が RFC 882/883 で提案し、それ以前の HOSTS.TXT ファイルによる手動管理を置き換えました。当時のインターネットは数百台のホストしかなく、SRI-NIC が管理する 1 つのテキストファイルで全ホスト名を管理していました。DNS はこの限界を分散型のシステムで解決した、インターネットの根幹技術です。
URL を入力してからページが表示されるまでの最初のステップが、この DNS による名前解決です。
名前解決の流れ - 4 段階の問い合わせ
ブラウザが www.example.com の IP アドレスを取得するまでに、最大 4 段階の問い合わせが行われます。
- ローカルキャッシュの確認: まず OS のキャッシュ、次にブラウザのキャッシュを確認する。過去にアクセスしたドメインなら、ここで解決する
- リゾルバ (フルリゾルバ) への問い合わせ: キャッシュになければ、ISP やパブリック DNS (Google の 8.8.8.8、Cloudflare の 1.1.1.1 など) のリゾルバに問い合わせる
- ルートサーバーへの問い合わせ: リゾルバのキャッシュにもなければ、ルートサーバーに「.com の権威サーバーはどこか」を問い合わせる
- 権威サーバーへの問い合わせ: .com の権威サーバーが「example.com の権威サーバーはここ」と回答し、最終的に example.com の権威サーバーが IP アドレスを返す
この一連の処理は通常 20〜120 ミリ秒で完了します。キャッシュがヒットすれば 1 ミリ秒未満です。
再帰クエリと反復クエリ
クライアント (ブラウザ) からリゾルバへの問い合わせは「再帰クエリ」です。クライアントは「最終的な答えをくれ」とリゾルバに依頼し、リゾルバが代わりに全ての問い合わせを行います。一方、リゾルバからルートサーバーや権威サーバーへの問い合わせは「反復クエリ」です。各サーバーは「自分は知らないが、次はここに聞け」と参照先を返すだけで、最終回答の責任を負いません。
DNS キャッシュ - 速度と鮮度のトレードオフ
DNS の問い合わせを毎回ルートサーバーから辿っていたら、インターネットは使い物になりません。キャッシュが DNS の性能を支えています。
各 DNS レコードには TTL (Time To Live) が設定されており、キャッシュの有効期間を秒単位で指定します。TTL が 3600 なら、1 時間はキャッシュを使い回し、期限が切れたら再度問い合わせます。
- TTL が短い (60〜300 秒): DNS の変更が素早く反映される。CDN やフェイルオーバー構成で使われる。ただしリゾルバへの問い合わせ頻度が増える
- TTL が長い (3600〜86400 秒): リゾルバの負荷が減り、名前解決が高速になる。ただし DNS レコードを変更しても、古いキャッシュが残っている間は反映されない
「DNS の浸透」という表現をよく見かけますが、これは技術的に不正確です。DNS の変更が「浸透」するのではなく、各リゾルバのキャッシュが TTL に従って期限切れになり、新しいレコードを取得するだけです。TTL を事前に短くしておけば、変更の反映を早められます。
ルートサーバー - インターネットの頂点
DNS の階層構造の頂点に位置するのが、13 のルートサーバー群 (A〜M) です。「13 台」と誤解されがちですが、実際には Anycast 技術により世界中に 1,700 以上のインスタンスが分散配置されています。
ルートサーバーは ICANN が統括し、各ルートサーバーは異なる組織が運用しています。A は Verisign、B は USC-ISI、J は Verisign、K は RIPE NCC、M は WIDE Project (日本の慶應義塾大学が中心) といった具合です。
ルートサーバーが保持する情報は実はシンプルで、「.com はこの権威サーバー」「.jp はこの権威サーバー」というトップレベルドメイン (TLD) の委任情報だけです。ルートゾーンファイルのサイズは約 2MB に過ぎません。
DNS レコードの種類
DNS にはさまざまなレコードタイプがあり、それぞれ異なる情報を格納します。
| レコード | 用途 | 例 |
|---|---|---|
| A | ドメイン → IPv4 アドレス | example.com → 93.184.216.34 |
| AAAA | ドメイン → IPv6 アドレス | example.com → 2606:2800:220:1:... |
| CNAME | ドメインの別名 (エイリアス) | www.example.com → example.com |
| MX | メールサーバーの指定 | example.com → mail.example.com (優先度 10) |
| TXT | テキスト情報 (SPF、DKIM、ドメイン検証) | "v=spf1 include:_spf.google.com ~all" |
| NS | 権威 DNS サーバーの指定 | example.com → ns1.example.com |
| SOA | ゾーンの管理情報 (シリアル番号、更新間隔) | プライマリ NS、管理者メール、シリアル番号 |
TXT レコードは本来テキスト情報を格納する汎用レコードですが、現在ではメール認証 (SPF、DKIM、DMARC) やドメイン所有権の検証に広く使われています。Google Search Console や Let's Encrypt の証明書発行でも TXT レコードによる検証が行われます。なお、CNAME レコードの例にある www.example.com のように、かつては URL に www を付けるのが一般的でしたが、現在は省略されるケースが増えています。なぜ www を入力しなくてもサイトが表示されるのかは、DNS の設定と深く関わっています。
DNS のセキュリティと今後
DNS は 1983 年の設計当初、セキュリティを考慮していませんでした。DNS クエリと応答は平文で送信されるため、ISP や同一ネットワーク上の第三者が「どのドメインにアクセスしているか」を傍受できます。
この問題に対処する技術として、DNS over HTTPS (DoH) と DNS over TLS (DoT) が登場しました。DoH は DNS クエリを HTTPS で暗号化し、通常の Web 通信と区別できなくします。DoT はポート 853 で TLS 暗号化を行います。
また、DNS 応答の改ざんを防ぐ DNSSEC (DNS Security Extensions) も重要です。DNSSEC は電子署名で DNS 応答の正当性を検証しますが、普及率は .com ドメインでも約 3% 程度にとどまっています。DNS の脆弱性は、インターネット全体のセキュリティに直結する課題です。
自分が使っている DNS サーバーが安全かどうか気になる方は、IP 確認さんの DNS 漏洩テストで確認できます。
DNS の仕組みを基礎から学びたい方には、ネットワーク入門書が参考になります。