クラス ぜんいんの 住所を 1まいの 紙に 書いて、みんなに くばる ところを 思い うかべて ください。だれかが 引っこしたら、書きなおして、また くばります。

むかしの ネットは、これに 近い やりかたでした。名前と 番号を 書いた 1つの ファイルを、あるところで 作り、ほかの コンピュータへ くばって いたのです［1］。

ただし 本当は、紙では なく コンピュータの ファイルです。名前は「HOSTS.TXT（ホスツ ティーエックスティー）」でした。

クラス全員の住所を1枚の紙に書いて配るところを想像してください。誰かが引っこすたびに書き直して、また全員に配ります。DNS以前のインターネットの名前は、これによく似た方法で管理されていました。

ホスト名（コンピュータにつけた名前）と数字の対応は、NIC（ネットワーク情報センター）が1つのファイル「HOSTS.TXT」にまとめていました［1］。この形式は1985年10月のRFC 952で公式に定められ、SRI Internationalの中にあるNICのコンピュータで公開されていたと書かれています［2］。

ただし、住所を書いた紙は比べやすいたとえにすぎません。実際のファイルは、コンピュータの名前と番号を1行ずつ並べた、ごく単純なものです。

DNSが登場する前、インターネットの前身であるネットワークでは、ホスト名とアドレスの対応表をどこが持っていたのか。RFC 1034によれば、それはNICが単一のファイルHOSTS.TXTとして維持していた［1］。

この表の形式は1985年10月のRFC 952が「インターネット・ホスト表」の公式な仕様として定めており、SRI International内のNIC（SRI-NIC）上のNETINFO:HOSTS.TXTとして公開されていた［2］。つまり、名前を知りたい各ホストは、1か所の表を手元に写して使う方式だった。

この方式が小さなネットワークでは十分に働いたことは、想像に難くない。問題は規模が変わったときに現れる。

クラスが 10人から 100人に なったら、どうでしょう。紙を くばる 人も、もらう 人も 10ばい です。だから 紙を くばる ための 手間は、10ばいより もっと ふえて、およそ 100ばいに なります。ネットでは、この 手間は「くばるのに つかう 通信つうしんの 量りょう」です。

もう 1つ こまる ことが ありました。名前を 1つ ふやしたい とき、かならず 表を 作る 人に たのみ、書きかえて もらう のを 待つ ひつようが ありました［1］。

ネットに つながる コンピュータが どんどん ふえる と、この やりかたは 追いつかなく なります。では、どう すれば よいのでしょう。

クラスが10人から100人に増えたら、紙を配る手間はどうなるでしょうか。配る側の人数も、受け取る側の人数も10倍になるので、全体の手間はおよそ10×10で100倍になります。実際のネットワークでは、この「手間」は配布に使う通信量にあたります。

RFC 1034は、この方式の困りごとを3つ挙げています。1つ目は、新しい版を全ホストに配るときに使う通信の量が、ホスト数の2乗に比例することです［1］。ホストが10倍になれば約100倍という計算で、これは実測値ではなく、配り方から出した見積もりです。

2つ目は、名前を1つ追加しても、NICの更新を待たないとインターネット全体に見えないことです。3つ目は、そもそもホストの数が急に増えていたことです［1］。

1か所で全部を持つやり方は、規模が大きくなるほど、持つ側も配る側も苦しくなります。では、表を1枚にしない設計とは、どんなものでしょうか。

HOSTS.TXT方式は、なぜ大きなネットワークで持たなかったのか。RFC 1034 2.1節は、理由として次の3点を挙げる［1］。

第一に、新しい版を各ホストに配る方式では、配布に使うネットワーク帯域の総量がホスト数の2乗に比例する。これは配布方式そのものから導かれた見積もりであり、実測値ではない。仮にホストが10倍になれば、配布量はおよそ100倍（10×10）に達する計算になる。

第二に、変更をインターネット全体に見せるには、NICが表を更新するのを待つしかなく、追加や変更がすぐに反映されない。第三に、ホスト数そのものが急増していた。以上の3点が重なった結果、1つの表を全員に配る設計は限界に近づいた。

すると設計者が目指したのは、表の中身を減らすことではなく、表の持ち方を変えることになる。RFC 1034は、目標として、特定のアプリケーションに限らない汎用性、経路やアドレスの情報を含まない一貫した名前空間、そして分散した管理とローカルなキャッシュによる性能向上を挙げている［1］。

そこで 名前を「木」の 形に ならべる ことに しました。大きな 木の 根っこの 下に、いくつかの 大きな なかまが ぶらさがります。「.com」や「.jp」のような、名前の いちばん 右の 部分です。

大きな なかまの 中は、それぞれ の まかされた 人に まかせます。日本の 中の ことは 日本の まかされた 人が、会社の 中の ことは 会社の 人が、きめる のです［4］。

1まいの 表を みんなで 書きかえる のでは なく、だれが どこまで 書くかを わけた のです。

「.com」「.jp」のような、サイト名の右端の部分を、トップレベルドメインと呼びます。DNSはこれを木の枝分かれのように使います。

名前の空間は木の形になっていて、いちばん上に名前のない「根（ルート）」があり、その下にトップレベルドメインが並びます［1］。1994年3月のRFC 1591では、COM・EDU・NET・ORG・INTのほか、アメリカ限定のGOVとMILがあり、国ごとのものにはISO 3166の2文字の国コードを使う、と書かれています［4］。これは1994年時点の一覧で、今はもっと増えています。

そして大事なのは、各ドメインの中身の管理を、それぞれの管理者に任せる（委任する）ことです［4］。日本の名前は日本の管理者が、会社の中の名前は会社が決められます。1つの表を全員で更新して待つ必要がなくなります。

こうして名前と管理が分かれても、疑問が残ります。名前を打った人のコンピュータは、どうやって目的の番号にたどりつくのでしょうか。

1つの表を全員に配る方式を捨てると、名前をどう整理し、誰が責任を持つのかが問題になる。RFC 1034は、ドメイン名空間を木構造とし、木の各節と葉に情報の集まりが対応するとしている［1］。DNSの構成要素は、この名前空間、情報を持つネームサーバ、利用者の要求に応じてネームサーバから情報を取り出すリゾルバの3つである［1］。

木の頂点にある名前のない根の下に、トップレベルドメイン（TLD）が並ぶ。1994年3月のRFC 1591は、当時のTLDとしてCOM・EDU・NET・ORG・INTと、米国限定のGOV・MILを挙げ、国別にはISO 3166の2文字コードを用いるとした［4］。これは1994年時点の記述であり、現在のTLDはより多い。

ここで決定的なのは、各ドメインの管理が、その管理者へ委任される点である［4］。だから、ある組織が自分のドメインの中に名前を足すとき、木の頂点にある機関へ頼む必要はない。HOSTS.TXTの「更新はNICを待つ」という制約は、この委任によって取り除かれた。

ただし、管理が分散すると、答えもあちこちに散らばる。利用者側のリゾルバは、その散らばった情報にどうやって到達するのか。

知らない 町で、ある 家を さがす ところを 考えて みましょう。まず 駅で「この 町は どちらですか」と 聞き、つぎに 町の あんない所で「この 通りは どこですか」と 聞き、さいごに 通りの 人に 家を 聞きます。

ネットの 名前も 同じです。まず いちばん 上の ルートに 聞きます。ルートは 番号は 答えず、「その 名前の 右の 部分は、こちらの 人が 知って います」と、つぎの まどぐちを おしえて くれます［5］。

つぎに その まどぐちに 聞き、また つぎの まどぐちを 教えて もらい、さいごに その 名前を まかされた ところから 番号が 返ってきます。

ただし 本当は、人では なく コンピュータ たちが 一しゅんで やりとり して います。

知らない町である家を探すとき、まず駅で町の方角を聞き、町の案内所で通りを聞き、最後に通りの人に家を聞く、という道のりを思い浮かべてください。DNSの名前調べも、これとよく似ています。

利用者のコンピュータの代わりに調べてくれるプログラム（フルリゾルバ）は、まず根にあたるルートサーバーにたずねます。ルートサーバーは、すべてのトップレベルドメインを担当する権威DNSサーバー（そのドメインの正式な情報を持つサーバー）の情報を管理していて、「この名前の右端の担当はここです」と教えます［5］。

次にそのトップレベルドメインの権威サーバーにたずね、そのドメインを担当する権威サーバーを教えてもらいます。最後にその権威サーバーが、目的のIPアドレスを答えます。このように、次の担当を教えてもらいながら順にたどるやり方を、反復問い合わせと呼びます［5］。

ここで大事なのは、ルートが最終的な番号を答えるわけではなく、次の窓口を教える役だということです。ただしこれは基本の道すじの説明で、実際には後で出てくる「覚えておく」仕組みのおかげで、毎回ここまでたどるわけではありません。

では、その最初の入口になるルートサーバーは、世界に何台あるのでしょうか。

利用者が名前を入力してから、実際のIPアドレスが返るまでの間に、何が起きているのか。JPRSの解説資料は、リゾルバ（フルリゾルバ）が、ルートサーバー、TLDの権威DNSサーバー、当該ドメインの権威DNSサーバーの順に問い合わせる反復問い合わせの流れを示している［5］。

ルートサーバーは、すべてのTLDの権威DNSサーバーの情報を管理していると説明される［5］。ここで注意したいのは、ルートが最終的なIPアドレスを答えるのではなく、次にたずねるべき先を教える点である。TLDの権威サーバーも同じく、下位のドメインの権威サーバーを教え、最後の権威サーバーが目的の情報を返す。

この設計により、1か所がすべての名前を知る必要がなくなった。各サーバーは、自分の担当の情報と、次に誰に聞けばよいかだけを持てばよい。

なお、この節の道すじはあくまで基本形であり、次に述べるキャッシュによって、実際の問い合わせはこの全経路を毎回たどるとは限らない。それでは、入口となるルートサーバーは、どのように運用されているのか。

ルートを 13だい だけ だと 思う 人も います。でも 13は、名前の 数です。「A」から「M」まで 13この 名前が あり、12の べつべつの ところ が 運用 して います［6］。

そして 1つの 名前の うしろには、世界の あちこちに おかれた たくさんの コンピュータが います。2026年9月30日の 時点で、はたらいている ばしょは 2000か所を こえています［6］。

ただし この 数は、日に よって かわります。

ルートサーバーは世界に13台しかない、という話を聞いたことがあるかもしれません。ところが、13は台数ではなく、名前の数です。

ルートサーバーは「A」から「M」まで13個の名前があり、12の独立した組織が運用しています。そして1つの名前の背後には、世界各地に置かれた多数の拠点（インスタンス）があります。root-servers.orgによると、2026年9月30日の時点で運用中の拠点は2,045でした［6］。この数は日々変わります。

なぜ13なのか、という問いに、よく聞く説明があります。DNSのメッセージをUDPで送るとき、大きさが512バイトまでと決められていて［3］、その中に収まる最大の数が13だった、というものです。ただし、RFC 1035にはこの理由は書かれていません。二次的な説明であり、ここでは断定しません。

名前を13に抑えつつ、拠点を世界中に増やすことで、遠くのサーバーへの距離を縮め、1つが止まっても他が答えられるようにしています。ところで、根から毎回たどるのは大変そうです。それを避ける工夫はあるのでしょうか。

ルートサーバーは世界に13台、という説明は正確か。運用主体の団体であるRoot Server Technical Operations Associationによれば、ルートネームサーバは「A」から「M」までの13個の名前で呼ばれ、12の独立した組織によって運用されている［6］。13は台数ではなく名前の数であり、各名前の背後に世界各地の拠点（インスタンス）が置かれている。同サイトの数値では、2026年9月30日時点の運用中の拠点は2,045である［6］。この値は日々変わるため、取得日を付して読む必要がある。

では、なぜ名前が13なのか。RFC 1035は、UDPで運ぶDNSメッセージを512バイトまで（IPとUDPのヘッダを除く）と定めている［3］。13は、この制約に収まる最大数だったからだと説明されることが多い。しかしRFC 1035自体には13という数字の理由の記述はなく、この説明は二次資料に基づく。本稿では理由を断定しない。

名前の数を抑えたまま拠点を増やす設計は、応答を返す側を地理的に分散させ、1か所の故障に耐えやすくする。ここまでの経路をそのまま毎回たどれば、根が問い合わせで埋まってしまう。その負担を減らす工夫が、次に述べるキャッシュである。

同じ 家に 何回も 行く なら、いちど 聞いた 道を メモして おけば、次からは 聞かずに すみます。DNSも 同じです。一度 分かった 答えを、しばらく おぼえて おきます［3］。

ただし メモは、いつまでも 正しい とは かぎりません。お店が 引っこすと、古い メモでは まちがった 場所へ 行って しまいます。だから 答えには「ここまで おぼえて よい」と いう 時間が ついて います。この 時間を TTL と いいます。

時間が おわったら、もういちど 聞きなおして、メモを 新しく します。

同じ家に何度も行くなら、いちど聞いた道順をメモしておけば、次からは人に聞かずに行けます。DNSのリゾルバも、一度調べた答えを保存して、同じ問い合わせをくり返さずにすませます［1］。

ただし、メモには賞味期限のようなものが必要です。お店が引っこしたのに古いメモを使い続ければ、まちがった場所へ行ってしまいます。そこで、DNSのデータには、キャッシュしてよい時間を示すTTLが付いています。RFC 1035では、TTLは32ビットの符号付き整数で、この間隔を過ぎたら、情報の元にもう一度確かめるべきだと定められています［3］。

1987年のRFC 1034は、ふつうのホストには日単位ほどのTTLを勧めていました［1］。今の運用値はサイトごとにまちまちで、この数字が現在も標準というわけではありません。

1枚の表を配る方式の「更新が遅い」という弱点と、分散した仕組みの「毎回聞くと重い」という弱点を、TTLという期限つきの記憶で折り合いをつけているわけです。ここまで来ると、最初の疑問に戻れます。名前を打つとサイトが開くのは、木・委任・キャッシュが支えているからでした。

階層と委任で管理を分散させても、毎回ルートから全経路をたどるのでは効率が悪い。そこでDNSは、各データにTTL（Time To Live）を付け、その間はリゾルバが答えを保存して、同じ問い合わせを繰り返さずにすむ設計にした［1］。

RFC 1035はTTLを、資源レコードがキャッシュされてよい時間間隔を示す32ビット符号付き整数と定義し、その時間が過ぎたら情報の元に再度問い合わせるべきだとする［3］。RFC 1034は、一般的なホストには日単位程度のTTLを勧めた［1］。この勧告は1987年のものであり、現在の運用値は用途により異なる。

TTLは、再利用による効率と、情報の鮮度のあいだの折り合いを表す値だといえる。TTLを長くすれば問い合わせは減るが、情報が変わったときに古い答えが残る時間が延びる。短くすれば新しさは保たれるが、問い合わせが増える。HOSTS.TXT方式の弱点であった更新の遅れと配布の重さを、DNSは一律の方式ではなく、データごとの期限という調整可能な形で扱うことにした。

今日 できること

すきな サイトの 名前を 見て、いちばん 右の ことばを さがして みましょう。「.jp」や「.com」のような ものです。つぎに 自分の 住所を、大きい ほうから 書き出して みて ください。日本の 住所は「県・市・町」と 大きい ほうから ならびますが、サイトの 名前は、左が 小さくて 右が 大きい ならびに なって います。

もっと 知りたい とき

おうちの 人と いっしょに、下の しりょうの うち JPRSの ものを 見て みましょう。むずかしい ところは とばして だいじょうぶ です。

今日できること

好きなサイトのアドレスを見て、いちばん右にある「.jp」「.com」などの部分を探してみましょう。次に、自分の家の住所を、大きい単位から小さい単位へ順に書き出します。住所は「県→市→町」と大きい順に並びますが、サイトの名前は左が小さく右が大きい、住所とは逆の並びです。右へ行くほど上の階層で、その先に名前のない根がある、と読めば、木の形が実感できます。

もっと調べたいとき

JPRSの解説資料は、日本語でDNSの仕組みを図つきで説明しています。まずはこの資料の図を見ながら、家にある紙に「.jp」「.com」の入ったサイト名を書き、左右のどちらが大きな区切りかを矢印で描いてみると、根から順にたどる道すじがつかめます。

今日できること

普段見るサイトのアドレスの右端（TLD）を書き出し、国別のもの（jpなど）と、そうでないものに分けてみる。名前は右へ行くほど上位という並びを、自分の住所（県→市→町と、左が上位）と紙に並べて比べると、向きが逆であることと、木の構造が理解しやすい。

資料を読むなら

まず日本語のJPRSの解説資料で、名前解決の全体像をつかむとよい。さらに詳しく知りたい人は、英語の原文が公開されているRFC 1034（2.1節が集中管理の問題、3節以降が構造）、RFC 1035（メッセージの形式とTTL）、RFC 1591（TLDの委任）へ進める。