
なぜTCP/IPは「名前」を知らないのか? /etc/hosts からNIS、DNSへ至る名前解決の歴史と美学
普段、私たちがWebサイトにアクセスするとき、google.com や社内サーバーのホスト名を意識して使っていますよね。でも実は、現代のインターネットを支える TCP/IP プロトコル自身は「名前」という概念を一切知りません。通信はあくまで「32ビットの数字(IPアドレス)」だけで行われています。では、一体どのようにして「数字」と「人間が読みやすい名前」が結びつけられてきたのでしょうか?
今回は、ローカルファイルの /etc/hosts から始まり、UNIX時代の画期的な一元管理システム NIS(YP)、そして現代の DNS へと続く「名前解決の歴史と仕組み」を分かりやすく紐解いていきます!
1.昔のTCP/IPは「名前」を知らなかった?
初期のパーソナルコンピュータにとって、TCP/IPはあまりに複雑で重いプロトコルでした。
TCP/IPはなぜ「初期のPC」にとって重すぎたのか?〜インターネットの王者が昔嫌われた理由〜
さらにTCP/IPは、「このIPアドレスがどのパソコン(ホスト)なのか」という名前の管理に関しては完全に “知らぬ存ぜぬ” というスタンスでした。そのため、TCP/IPが使われ始めた初期のワークステーション世界では、名前とIPアドレスを変換する「別の仕組み」を用意する必要があったのです。
2.最もシンプルな名前解決:/etc/hosts の時代
最初に行われたのが、各マシンの中に「名前とIPアドレスの対応表」をテキストファイルとして置いておく方法でした。これが現在でも使われている hosts ファイル(UNIX/Linuxでは /etc/hosts)です。
/etc/hosts の基本
/etc/hosts は、DNSサーバーに問い合わせに行く前に OSがローカル内で最優先で参照する設定ファイル です。
# 書式:IPアドレス 正式なホスト名 [別名...]
127.0.0.1 localhost
192.168.11.10 myserver.local myserver
198.51.100.5 example.com
現在でも、以下のような用途で活躍しています。
DNS構築前のテスト: ドメイン購入直後やレコード未反映時のWeb表示確認
ローカル開発環境: 自分のPC(127.0.0.1)に test.local などの名前をつけてテスト
小規模LAN: DNSサーバーを立てるほどではない小規模環境での名前解決
関連リンク:hosts (Wikipedia) / LMHOSTS (Windows系)
hosts ファイルの限界と運用の苦悩
hosts はあくまでローカルなファイルです。そのため、LAN内で同じ名前解決を行うには、すべてのホストに全く同じ hosts ファイルをコピーして配る 必要がありました。
しかし、ネットワーク内の機器が増えると以下のような問題が多発します。
構成変更のたびに全マシンへファイルを手動コピーするのが大変
たまたま電源が入っていないマシンの更新漏れが発生する
ユーザーアカウント情報などの共有でも同様の問題が起きる
「手作業でファイルを同期するのは限界だ!」ということで登場したのが、LAN内で設定情報を一元管理・共有するサービス NIS でした。
3.LAN全体で一元管理!「NIS(Yellow Pages)」の登場
NIS(Network Information Service) は、サン・マイクロシステムズが開発したディレクトリサービスです。
ネットワーク上の「NISマスターサーバー」が情報を一括管理し、クライアントへ共有する仕組みを作りました。
関連リンク:ネットワーク・インフォメーション・サービス (Wikipedia)
「Yellow Pages(YP)」と呼ばれる理由
NISは開発当初 「Yellow Pages(YP)」 と呼ばれていました。しかし、「Yellow Pages」が英国ブリティッシュ・テレコム社の登録商標だったため「NIS」へと名称変更された経緯があります。そのため、システム内部やコマンド名には現在もその名残があり、関連するプログラムはすべて yp から始まります。

NISにおけるホスト名検索の仕組み
NISサーバーは、テキストの /etc/hosts を読み込み、高速検索が可能なバイナリ形式の「マップ(Map)」(hosts.byname / hosts.byaddr)に変換して配信します。
[ クライアント上のアプリ ] (例: ping server01)
│
▼
1. /etc/nsswitch.conf の設定を参照(例: hosts: files nis dns)
│
├───> 2. まずローカルの 【/etc/hosts】 を探す(未発見)
│
▼
3. クライアントの 【ypbind】 デーモンが起動
│
▼ (RPC通信)
4. NISサーバーの 【ypserv】 へ問い合わせ
│
├───> 5. 【hosts.byname】 マップを検索
│
▼
6. IPアドレス(192.168.1.50)がクライアントに返る
NISの弱点と衰退
NISは非常に便利で普及しましたが、「通信が暗号化されない」「ドメイン名さえ分かれば誰でも情報を取得できる」 という致命的なセキュリティ脆弱性がありました(そうは言ってもパスワードには最低限の暗号化が施されていましたけどね)。そのため、現代ではアカウント管理の役割を LDAP や Active Directory に譲り、名前解決の役割は DNS へと引き継がれていきました。
4.NISとDNSは何が違うのか?徹底比較
「名前解決をする仕組み」として、NISとDNSの違いを表にまとめました。

💡 4つの決定的な違い
守備範囲(LANか、世界か)
NISは「身内のLAN内」前提。外部インターネットの名前解決はできません。
DNSは世界中のサーバーをバケツリレー式に辿って名前解決が可能です。
管理データの種類
NISはアカウント情報(/etc/passwd)なども丸ごと共有する思想。
DNSは「名前とIPアドレス等の紐付け」に特化しています。
データの持ち方(フラットか階層型か)
NISはフラット管理のため、同一ドメイン内で同じホスト名は1つしか持てません。
DNSは sales.example.com や dev.example.com のようにドメインを階層化・分割管理(委任)できるため、名前の衝突を防げます。
OSでの優先度設定
UNIX/Linuxでは /etc/nsswitch.conf に hosts: files nis dns と書くことで、「①ローカルファイル ➔ ②NIS ➔ ③DNS」の順で名前を探しに行く使い分けが行われていました。
5.名前と実体を分ける「UNIXの美学」
TCP/IPが通信において「アドレス(数字)」のみを利用し、「名前」は別の仕組み(hosts / NIS / DNS)に委ねる設計。これには、UNIXのファイルシステムが 「ファイルの実体をすべて i-node 番号で管理し、人間が使うファイル名はディレクトリによって後から結びつけている」 設計思想と非常によく似た美学を感じます。
あえて「通信の実体(IPアドレス)」と「人間用のラベル(名前)」の間にワンクッションを挟むことで、ネットワークの構成が変わっても柔軟に対応できる拡張性と柔軟性が生まれたのではないでしょうか。
💡 あわせて読みたいテーマ

NotebookLMによるスライド資料
NotebookLMによるまとめ記事
ショート動画
NotebookLMによる解説動画
NotebookLMによる音声解説
ヘッダ画像は、Gemini に記事を読み込ませて生成しました。
#IT #インフラ #ネットワーク #Linux #DNS #技術解説 #IT歴史 #エンジニア