はじめに
ミツカリインターンの井上です。今回、DNS誕生までの歴史について、IT初心者の方にもわかりやすいように、このブログ記事にまとめました。
現代のインターネットでは、Webサイトのアドレス（例：www.example.jp）を入力するだけで、目的のページにアクセスできます。
しかし、私たちが普段目にするURLやメールアドレスは、実際にはIPアドレスという数字の列に変換されて通信が行われています。
この変換を担うのがDNS（Domain Name System）です。
DNSは、人間にとって覚えやすいホスト名と、コンピュータが通信に使うIPアドレスを対応させることで、インターネット上の名前解決を支えています。
本記事では、DNSがどのように生まれたのか、当時のエンジニアたちが直面した課題、そしてそれをどう解決してきたのかという歴史の流れを振り返ります。
ARPANETとHOSTS.TXTの時代
インターネットの前身である ARPANET は、1969年にアメリカ国防総省の高等研究計画局（ARPA）によって運用が始まりました。
最初に接続されたのは、わずか4ノード（UCLA、SRI、UCSB、ユタ大学）だけでした。
この時、各コンピュータには「ホスト名（＝ネットワーク上のコンピュータの名前）」が付けられていましたが、それをIPアドレスに対応付ける方法が課題となっていました。
そこで登場したのが、SRI-NIC（Network Information Center）が管理していた 「HOSTS.TXT」 というファイルです。
以下は、1985年頃のHOSTS.TXTと思われるファイルを抜粋したものです。
NET : 4.0.0.0 : SATNET-NETWORK : NET : 6.0.0.0 : YPG-NET-TEMP : NET : 7.0.0.0 : EDN-TEMP : NET : 8.0.0.0 : BBN-NET-TEMP : NET : 10.0.0.0 : ARPANET : ・ ・ ・ HOST : 192.5.89.71 : BUN : SUN-2/120 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,ICMP,UDP : HOST : 192.5.89.72 : FUN : SUN-2/120 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,ICMP,UDP : HOST : 192.5.89.73 : NUN : SUN-2/120 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,ICMP,UDP : HOST : 192.5.89.74 : RUN : SUN-2/120 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,ICMP,UDP : ・ ・ ・
新しいホストがネットワークに追加されるたびに、SRI-NICがファイルを手作業で編集し、最新のものを各組織に配布していました。
当時はホスト数も少なかったため、この方法でも特に問題はありませんでした。
集中管理の限界：「HOSTS.TXT」はなぜ破綻したのか
1970年代後半から1980年代にかけて、ARPANETに参加する大学や研究機関が急速に増加しました。
その結果、HOSTS.TXTによる中央管理方式は、管理負荷や更新遅延の面で次第に限界を迎えるようになりました。
1. ファイルサイズと更新負荷の増大
ホスト数の増加に伴い、HOSTS.TXTのサイズも大きくなり、更新のたびに全てのホストが新しいファイルを取得する必要がありました。
1981年にはホスト数が200台を超え、ファイル更新の遅れや内容の不一致、さらには各組織間での同期ズレが頻繁に発生するようになっていました。
2. 管理の集中によるリスク
当時、ホスト名の管理は SRI-NIC という1つの組織に集中していました。 そのため、SRI-NICの運用に問題が生じた場合、新しいホストの追加や名前の修正が一時的に行えなくなる可能性がありました。
このように、特定の場所や仕組みに全体が依存している構造は、「単一障害点（Single Point of Failure）」と呼ばれ、 現在のシステム設計では避けるべき構造とされています。
3. 名前の一意性管理の非現実性
ホスト名は重複してはいけないため、新規登録のたびにSRI-NICが既存の名前との重複を手作業で確認していました。
しかし、ネットワーク規模の拡大とともに、この方式は非現実的かつ管理負荷の高いものとなっていきました。
DNSの誕生 ― 分散・階層型の設計思想
1983年になると、ARPANET上のホストは500台を超え、中央集権的な管理方式では対応できないことが明確になりました。
この問題に取り組んだのが、USCの情報科学研究所（ISI）に所属していたPaul Mockapetris（ポール・モカペトリス）です。
彼は、名前解決の仕組みを根本から作り直すことを提案しました。
RFC 882 / RFC 883で示された基本設計（1983年）
1983年11月にRFC 882とRFC 883として提案されたこれらの文書は、DNSの基本設計を示しています。
階層構造（ドメインツリー）
名前を階層的に整理し、各組織が自分の領域（ゾーン）を管理できるようにする。 たとえば「www.example.com」なら、「com」→「example」→「www」といったように階層的に名前を分けて管理します。問い合わせの委譲（Delegation）
上位サーバが下位サーバに問い合わせを引き渡す「ゾーン委譲」という仕組みにより、全体を一箇所で管理する必要をなくす。 たとえば「com」は「example.com」の情報を知らなくても、その管理サーバを知っているため、「example.com」に関する問い合わせはそこに引き継ぐことができます。キャッシュによる効率化
一度問い合わせて得た結果は、しばらく保存しておくことで、同じ質問を何度もしなくて済むようにする。
RFC（Request for Comments） とは、インターネット技術の仕様や標準をまとめた公開文書です。
RFCは提案文書として公開され、内容によってはインターネット標準として採用されます。
DNSやHTTP、メールなど、多くのインターネット技術の基盤はRFCで定められています。
📄 関連RFC：
- RFC 882 - Domain Names - Concepts and Facilities
- RFC 883 - Domain Names - Implementation and Specification
実装と運用へ：BINDの登場とRFCの洗練
RFC 1034 / 1035（1987年）：仕様の確立
RFC 882/883は実験的な仕様として提案されましたが、その後の検証や議論を経て、
1987年により詳しく安定した仕様である RFC 1034 と RFC 1035 が策定されました。
これにより、DNSの仕組みが標準化され、広く普及していきました。
📄 関連RFC
- RFC 1034 - Domain Names - Concepts and Facilities
- RFC 1035 - Domain Names - Implementation and Specification
BINDの登場（1984年〜）
DNSの仕組みはRFCで決められましたが、実際に名前解決を行うためには、それを動かすソフトウェアが必要でした。 そこで登場したのが、カリフォルニア大学バークレー校で1984年に開発されたBIND（Berkeley Internet Name Domain）というDNSサーバソフトです。
BINDはUNIXという当時広く使われていたOS向け作られました。 これにより、さまざまな組織や企業が自分たちのDNSサーバを持ち、ドメイン名の管理や名前解決を行えるようになりました。
BINDの登場は、DNSが実際に動く仕組みとして広まり、インターネットの利用が急速に拡大するきっかけとなりました。
おわりに
こうして、DNSは考え方だけでなく、実際に使える技術として形になりました。RFCによって仕組みが定められ、BINDによってその仕組みが実際に動くものとなりました。
DNSは、その後のインターネットの成長を支える大事なしくみとなり、今でも使われ続けています。
