DNS（Domain Name System）は、example.com のような名前を、通信に使うIPアドレスなどの情報に変換するための、世界規模の分散データベースです。この記事では、DNSが生まれる前の「1つのファイルで全部を管理していた時代」から、現在の暗号化DNSまでの流れをたどりながら、なぜ今の仕組みになっているのかを説明します。歴史を知っておくと、TTLやネームサーバー変更の「反映待ち」がなぜ起きるのかが理解しやすくなります。
なお、DNSの基本と拡張仕様EDNSの関係は別の記事で扱っているため、この記事では歴史と全体像に絞ります。
DNSが何をしているのか
ブラウザに www.example.com と入力すると、パソコンはまず「この名前のIPアドレスは何か」をDNSに問い合わせます。答えが返ってきて初めて、Webサーバーに接続できます。WordPressのサイトを公開する、サーバーを移転する、SSL証明書を取る、メールを届ける、といった作業の裏側では、ほぼ毎回この名前解決が動いています。
名前解決には、主に次の3つの役割が関わります。
- スタブリゾルバ: パソコンやサーバーのOSに組み込まれた問い合わせ役です。自分では探し回らず、決められたDNSサーバーに丸ごと尋ねます。
- フルサービスリゾルバ（キャッシュDNSサーバー）: プロバイダーや公開DNS（Google Public DNS、Cloudflare の 1.1.1.1 など）が運用しています。ルートから順にたどって答えを探し、結果を一定時間キャッシュします。
- 権威DNSサーバー: そのドメインの正しい情報を持っているサーバーです。お名前.comやCloudflare、Route 53などの「DNS設定画面」で登録した内容は、ここから配られます。
キャッシュDNSは、ルートサーバー（.）→ TLDのサーバー（.com や .jp）→ そのドメインの権威DNS、と階層を下りながら答えにたどり着きます。この階層構造と委任の考え方が、DNSの設計の中心です。
DNS以前：HOSTS.TXT の時代
インターネットの前身であるARPANETでは、ホスト名とアドレスの対応表を1つのテキストファイル（HOSTS.TXT）にまとめ、スタンフォード研究所のネットワーク情報センター（SRI-NIC）が一元管理していました。各組織は変更を申請し、各ホストは定期的にこのファイルをダウンロードして使っていました。
いまのOSにある hosts ファイル（Linuxの /etc/hosts、Windowsの C:\Windows\System32\drivers\etc\hosts）は、この時代の名残です。
接続するホストが増えるにつれて、この方式には限界が見えてきました。
- ファイルが大きくなり、配布の負荷と更新の遅れが問題になった
- 名前の重複を1か所で調整し続けるのが難しくなった
- 組織が自分のホスト名を自分で管理できなかった
「1か所で全部を持つ」やり方をやめ、「名前を階層に分け、それぞれの部分を担当者に任せる」方式が求められるようになりました。
DNSの誕生と基本仕様
1983年、ポール・モカペトリス（Paul Mockapetris）がDNSの最初の仕様をRFC 882・RFC 883として発表しました。その後、1987年に改訂版のRFC 1034・RFC 1035が出され、これが現在まで続く基本仕様になっています。レコードの形式、問い合わせと応答のメッセージ形式、ゾーンと委任の考え方は、ほぼこのときの設計のままです。
同じ1980年代には、カリフォルニア大学バークレー校でDNSサーバーソフトウェアのBINDが作られました。BINDは現在もISC（Internet Systems Consortium）によって開発が続けられており、ゾーンファイルの書き方はBINDの書式が事実上の共通語になっています。
TTLとキャッシュは最初からの設計
RFC 1034・1035の時点で、各レコードにTTL（キャッシュしてよい秒数）を持たせる仕組みが組み込まれていました。問い合わせのたびに権威DNSまでたどると負荷も遅延も大きいため、途中のキャッシュDNSが答えを一定時間覚えておく設計です。
「レコードを変えたのに反映されない」という現象は、この設計の裏返しです。変更前の答えをキャッシュしたサーバーは、TTLが切れるまで古い答えを返し続けます。DNSの変更前にTTLを短くしておく、という定番の段取りは、この仕組みを踏まえたものです。
管理体制の変化：ルートサーバーとICANN
DNSの頂点にあるルートゾーンは、AからMまでの13の名前を持つルートサーバー群が配信しています。「13」という数は、初期のDNSが1つのUDPパケット（512バイト）に収まる応答を前提としていたことに由来すると説明されることが多いです。現在は各ルートサーバーがエニーキャストで世界中に多数の拠点を持っており、物理的なサーバーは13台よりはるかに多く存在します。日本では、WIDEプロジェクトがMルートサーバーの運用を担っています。
1998年には、ドメイン名やIPアドレスの割り当てを国際的に調整する組織としてICANNが設立されました。.jp については、日本の登録管理業務が2000年代の初めにJPNICからJPRSへ移っています。2010年代には新しいgTLD（.shop や .tokyo など）が大量に追加され、選べるドメインの種類が一気に増えました。
安全性と拡張の歴史
DNSは当初、信頼できる研究者どうしのネットワークを前提に作られたため、応答が本物かどうかを確かめる仕組みを持っていませんでした。インターネットが広がるにつれ、その弱点を補う技術が順に追加されています。
- EDNS(0)（1999年にRFC 2671、2013年にRFC 6891で改訂）: 512バイトの制限を超える応答などを扱えるようにした拡張です。後に出てくるDNSSECの前提にもなっています。
- DNSSEC（2005年にRFC 4033〜4035）: 応答に電子署名を付け、改ざんされていないかを検証できるようにする仕組みです。ルートゾーンには2010年に署名が導入されました。
- キャッシュポイズニング対策（2008年前後）: 偽の応答をキャッシュDNSに覚えさせる攻撃の手法が広く知られるようになり、問い合わせの送信元ポートをランダムにするなどの対策が多くの実装に入りました。
- 国際化ドメイン名（2003年にRFC 3490、のちにIDNA2008へ改訂）:
日本語.jpのような名前を、xn--で始まるASCII文字列に変換して扱う仕組みです。
暗号化DNSとプライバシー
2010年代後半からは、問い合わせの内容そのものを盗み見られないようにする取り組みが進みました。
- DNS over TLS（DoT）: 2016年にRFC 7858
- DNS over HTTPS（DoH）: 2018年にRFC 8484
- DNS over QUIC（DoQ）: 2022年にRFC 9250
あわせて、キャッシュDNSが上位のサーバーに必要以上の名前を伝えないようにする「QNAMEミニマイゼーション」も標準化されています。主要なブラウザやOSにはDoHやDoTを使う設定がありますが、既定の動作や設定画面の名前はブラウザやOSのバージョンによって異なります（2026年10月現在）。
歴史から見えるDNSの性質
ここまでの流れを踏まえると、日々のサイト運用で出会うDNSの挙動は、次のように整理できます。
- 分散しているから、どこを見ているかで答えが変わる: 権威DNSに問い合わせた結果と、キャッシュDNSが返す結果は一致するとは限りません。調査のときは、どのサーバーに尋ねたかを意識します。
- キャッシュ前提だから、変更は「時間差」で伝わる: TTLが切れるまでは古い答えが残ります。急ぎの変更ほど、前もってTTLを下げておく意味があります。
- 委任の仕組みだから、親と子の両方を見る必要がある: ネームサーバーの変更は、レジストリ（親）に登録された情報と、自分のゾーン（子）の両方がそろって初めて正しく動きます。
- 後付けの安全機能は、設定を誤ると止まる側に働く: DNSSECを有効にしたままネームサーバーを移すと、署名の検証に失敗して名前解決ができなくなることがあります。
自分の環境で名前解決の流れを見てみる
dig コマンドの +trace オプションを使うと、ルートから順に委任をたどる様子を自分の目で確認できます。Linux や macOS では標準または追加パッケージで使えます。
# ルートサーバーから順にたどって www.example.com を解決する
dig +trace www.example.com A
# 権威DNSサーバーに直接尋ねる（+norec は再帰を求めない指定）
# ns1.example-dns.net は、+trace の最後に表示されたネームサーバー名に置き換える
dig @ns1.example-dns.net www.example.com A +norec+trace の出力では、最初にルートサーバーの一覧、次に .com のサーバー、最後に example.com の権威DNSが返す答えが順に表示されます。各行の2列目の数字がTTLです。HOSTS.TXT からDNSへ移った理由である「階層と委任」が、そのまま出力の形に表れているのが分かります。
まとめ
- DNSは、名前とIPアドレスなどを結びつける世界規模の分散データベースです。
- 1つのファイル（HOSTS.TXT）を中央で配る方式が限界を迎え、1983年に階層と委任を軸にしたDNSが生まれ、1987年のRFC 1034・1035が今も基本仕様になっています。
- TTLとキャッシュは最初からの設計で、「反映待ち」はその性質によるものです。
- EDNS(0)、DNSSEC、国際化ドメイン名、暗号化DNS（DoT・DoH・DoQ）など、安全性と使い勝手を補う仕組みが順に加わってきました。
- 調査では、どのサーバーに尋ねたか、TTLがどれだけ残っているか、親と子の情報がそろっているかを意識すると、原因を絞り込みやすくなります。