なぜHOSTS.TXTからDNSへ移ったか
名前解決が1つのファイルの配布から階層分散へ移った理由を史実で追い、中央集権が破綻する規模の見極めと委任・キャッシュ設計の勘所を持ち帰れる。
- ARPANET初期は全ホストの名前とアドレスを1つのHOSTS.TXTに書き、SRIのNICが管理してFTPで各ホストへ配布した。ホスト数が増えると更新競合・配布帯域・名前衝突が同時に破綻した。
- 1983年、Paul MockapetrisがRFC 882/883でDNSを設計。名前空間を階層化し、権限を各組織へ委任し、TTL付きキャッシュで問い合わせを局所化することで、中央の単一台帳なしに全体をスケールさせた。
- 教訓は、単一の権威で全体を同期し続ける方式は規模に対して線形以上のコストで壊れること。分割・委任・キャッシュで境界を切ると各部分が独立に更新でき、hostsファイルは今も局所的な上書き手段として残る。
結論（なぜそうなったのか）
横にスクロール
DNS が生まれたのは、性能問題より先に運用の破綻が来たからです。ARPANET では全ホストの名前とアドレスの対応を HOSTS.TXT という1つのテキストファイルに書き、これを唯一の権威が管理して各ホストへ配っていました。ホストが数百規模になると、この「1ファイルを全員で共有する」方式は、更新の直列化・配布の帯域・名前の一意性という3つの壁に同時にぶつかります。DNS は台帳を階層に分割し、各部分の管理権を組織へ委任し、結果をキャッシュすることで、中央が全体を把握し続けなくてもスケールする構造に置き換えました。
当時の状況と競合
ARPANET のホスト名解決は当初、各ホストがローカルに持つ静的な対応表で行われていました。この表の正本が HOSTS.TXT で、スタンフォード研究所（SRI）の Network Information Center（NIC）が集中管理していました。各サイトの管理者は自ホストの登録・変更を NIC へ依頼し、NIC が更新した HOSTS.TXT を各ホストが定期的に FTP で取得して、自分のローカル表（Unix なら /etc/hosts）へ反映する運用です。名前は階層のないフラットな空間で、MIT-AI のように1つの平坦なラベルでした。
小さいネットワークでは、この単純さがむしろ美点でした。破綻は規模の増大が引き起こします。RFC 1034（1987）は当時の問題をこう総括しています。
- 配布コスト: ホストが増えるほどファイルが肥大し、全ホストへ配る帯域と、各ホストが最新版を取り直す負荷が増える。全員がほぼ同時に取りに来れば NIC 側が輻輳する
- 更新の直列化と鮮度: 変更はすべて1つの NIC を経由し、反映は各ホストの取得周期に律速される。世界のどこかは常に古い表で動く
- 名前の一意性: フラットな空間では新しい名前が既存と衝突しないことを中央が保証せねばならず、この調整コストがホスト数に対して増え続ける
有力な代替案は「同じ集中管理のまま、配布や更新を効率化する」延長線でした。しかしファイルを速く配っても、単一の権威が全名前を承認し全体を同期し続ける構造自体は変わりません。問題の本質は転送効率ではなく、1つの主体が全体の一貫性に責任を負う集中設計にあり、そこを崩さない限りコストは規模とともに増え続けます。
決定打・経緯
転機は 1983年、Paul Mockapetris が RFC 882（概念と機能）と RFC 883（実装と仕様）で Domain Name System を提案したことです。彼が変えたのは配布方法ではなく、問題の分割の仕方でした。設計の核は次の3点です。
| 設計要素 | HOSTS.TXT | DNS |
|---|---|---|
| 名前空間 | フラット（例 MIT-AI） | 階層的な木構造（例 ai.mit.edu）。ルートから葉へラベルを連ねる |
| 権限 | NICが全名前を集中承認 | 各ゾーンの管理をサブツリー単位で組織へ委任。上位は下位のサーバー位置だけを知る |
| 解決方法 | ローカルの静的表を全走査 | リゾルバがルート→TLD→権威サーバーと段階的に問い合わせ |
| 鮮度と負荷 | 取得周期に律速。全体を再配布 | 各レコードのTTLでキャッシュ。変更は該当ゾーンだけに閉じる |
勝敗を分けたのは、委任とキャッシュを組み合わせた点です。階層化だけなら単なる命名規則ですが、DNS は各階層の下位を管理する権限を切り出して組織へ渡しました。edu の下に誰を作るかは上位に問い合わせず各機関が決め、上位は「そのゾーンの権威サーバーはどこか」という委任情報（NS レコード）だけを保持します。これで NIC のような中央承認が不要になります。さらに問い合わせ結果を TTL の期間だけ各リゾルバがキャッシュするため、同じ名前への反復問い合わせは上位まで届かず、負荷が局所に留まります。委任が「誰が何を決めるか」を分散し、キャッシュが「問い合わせがどこまで伝播するか」を局所化する。この2つが揃って初めて、中央の単一台帳なしに全体が動くようになりました。
名前を 葉.組織.TLD の木にすると、一意性の保証を「同じ親の下で子の名前が重複しない」というローカルな条件に分解できます。全体で唯一の名前を中央が突き合わせる必要がなくなり、各ゾーンは他ゾーンと独立・並行に更新できます。集中承認という直列のボトルネックが、木の枝ごとの独立な操作に変わるのが本質です。
実装面では、権威サーバーと再帰リゾルバの役割分離、問い合わせを軽量な UDP に載せる設計（大きな応答や信頼が要る場面は TCP）が、単純な問い合わせを安く速く保ちました。DNS は 1980年代半ばに ARPANET へ本格導入され、後続の RFC 1034/1035（1987）で仕様が整理されて、現在まで続く標準になりました。
今への影響と教訓
DNS の階層委任は、いまも世界規模の名前解決を支える基盤そのものです。ルートサーバー、TLD、各組織の権威サーバーへ責任が分割され、各ゾーンは自分の領域を独立に運用します。TTL によるキャッシュは、権威への負荷軽減と、変更を意図的に伝播させる制御（切り替え前に TTL を短くしておく等）の両面で日常的に使われています。
同時に、HOSTS.TXT の子孫である hosts ファイル（Unix 系の /etc/hosts、Windows の C:\Windows\System32\drivers\etc\hosts）は今も現役です。理由は、DNS を介さずにそのホストだけへ即座に効く上書き手段だという点にあります。
- 開発・検証で特定ドメインを手元やステージング環境へ向ける（DNS変更の伝播を待たずに試せる）
localhostなど基本的な名前の固定的な解決- DNSが使えない・使いたくない局面での局所的な応急処置
多くの環境で hosts は DNS より先に参照されるため、意図しない登録は「そのホストだけ名前解決がおかしい」原因になります。切り分けでまず確認すべき箇所です。
この移行が残した最大の教訓は、単一の権威で全体を同期し続ける方式は、規模に対して破綻するという点です。参加者が増えるほど、中央が担う承認・配布・一貫性のコストは増え続けます。DNS の解法は「速く配る」ではなく「配らなくて済むように分割する」でした。責任を委任して各部分を独立させ、キャッシュで境界の外へ問い合わせを漏らさない。この分割・委任・キャッシュという型は、名前解決に限らず分散システム設計の基本パターンとして繰り返し現れます。
名前解決が実際にどう動くかの内部解説はネットワークを、ドメインが Web の入口としてどう使われるかはWebを、TTL やデプロイ時の切り替え運用はDevOpsを参照してください。
- HOSTS.TXT はSRIのNICが集中管理し、各ホストがFTPで取得してローカル表へ反映する方式。破綻要因は配布コスト・更新の直列化・名前の一意性の3点
- DNSは1983年にPaul MockapetrisがRFC 882/883で設計。核は階層的名前空間・権限の委任・TTLキャッシュ
- 委任情報（NSレコード）により上位は下位の権威サーバー位置だけを持ち、中央承認が不要になる
- hostsファイルは多くの環境でDNSより先に参照され、局所的な上書きに今も使われる
なぜ？の記事ガイド
なぜHOSTS.TXTからDNSへ移ったかを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
DNS
比較で見る軸
難易度: advanced / カテゴリ: なぜ？ / タグ数: 5
導入後に効く点
1983年、Paul MockapetrisがRFC 882/883でDNSを設計。名前空間を階層化し、権限を各組織へ委任し、TTL付きキャッシュで問い合わせを局所化することで、中央の単一台帳なしに全体をスケールさせた。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- advanced
- カテゴリ
- なぜ？
- タグ数
- 5
判断チェックリスト
- 自社の用途が「DNS / ネットワーク」に近いか確認する。
- 強みである「ARPANET初期は全ホストの名前とアドレスを1つのHOSTS.TXTに書き、SRIのNICが管理してFTPで各ホストへ配布した。ホスト数が増えると更新競合・配布帯域・名前衝突が同時に破綻した。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。