世界のルートネームサーバーはなぜ13組しかないのか？

1. プロトコル上の厳しい制約：512バイト

1.1 IPv4のMTUとフラグメント化されないUDP

初期のARPANET / IPv4ネットワークでは、最小MTUが576バイトと定められていました。すべてのホストはこのサイズのパケットを受信できなければならず、そうでなければ基本的な到達性すら保証できませんでした（RFC 791）。

Total Length is the length of the datagram, measured in octets,
including internet header and data.  This field allows the length of
a datagram to be up to 65,535 octets.  Such long datagrams are
impractical for most hosts and networks.  All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments).  It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

• 全長576バイト − 一般的なIPヘッダー20バイト − UDPヘッダー8バイト ≈ 548バイトが利用可能（オプション付きのIPヘッダーは最大60バイトになるため、余裕はさらに減ります）
• RFC 1035 § 4.2.1では、より保守的な2のべき乗である512バイトを、DNS over UDPの絶対的な上限と定めました — IPヘッダーにオプションが最大まで付いても安全に収まる値です
• UDPの応答が512バイトを超える場合は、切り詰めたうえでTCフラグを立てる必要があり、クライアントはTCPへのフォールバックを強いられます — TCPの3ウェイハンドシェイクにより、初回の名前解決の遅延は数倍に増えます

つまり、「ルートサーバーの完全な一覧は、512バイトのUDPパケット1つに収まらなければならない」ということです。そうでなければ、世界中のルートへの問い合わせがすべてTCP経由になり、1980年代のハードウェアではほぼ壊滅的な事態になっていたでしょう。

1.2 DNSメッセージのバイト構成

.のNSレコードを問い合わせたときの、応答全体の構造です（サーバーはすべてのルートNSレコードとグルーAレコードを返します）：

Header   (12バイト)

全長の計算式：

512バイトの制限を代入すると：

理論上は最大15組まで収まりますが、DNSSEC署名、EDNS0のOPT疑似レコード、フィールドのパディングのための余裕が必要なため、最終的に13組に落ち着きました — 1996年のRFC 2010でルートサーバーの運用基準が示され、翌年にM-rootが稼働して以降、その数は変わっていません。

1.3 自分で試す — <code>dig +noedns -t ns .</code>の応答は約490〜510バイト

ここまでは理論です。次に、digコマンドで実際にルートサーバーへ問い合わせ、応答のサイズを確かめてみましょう：

$ dig +noedns -t ns .

; <<>> DiG 9.10.6 <<>> +noedns -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35973
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                                IN      NS

;; ANSWER SECTION:
.                       430502  IN      NS      a.root-servers.net.
.                       430502  IN      NS      b.root-servers.net.
…  （NSは全13件、c〜lは省略）
.                       430502  IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     516909  IN      A       198.41.0.4
b.root-servers.net.     562547  IN      A       170.247.170.2
…  （13件のAグルーレコードがすべて収まる）
m.root-servers.net.     516941  IN      A       202.12.27.33
a.root-servers.net.     516930  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     562547  IN      AAAA    2801:1b8:10::b
↑ AAAAは2件しか入らない — パケットが上限に達している

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE  rcvd: 492

注目すべきは最後の行です — 応答の合計は約490〜510バイトで、512バイトを十分に下回っています（正確な値は、どのルートに問い合わせたか、IPv6のグルーレコードが何件返ってきたかによって変わります）。これは前述のバイト数の見積もりと一致します。+noednsフラグに注意してください：digはデフォルトでEDNS0を送信するため、その場合の応答は800バイトを大きく超えます。EDNS0が普及してから512バイトが絶対的な制限ではなくなったのはまさにこのためですが、その時点ですでに13という数は固定されていました。

2. 13組はどこから来たのか？その歴史

この数字は最初から決まっていたわけではありません。ルートサーバーの数は何度か増やされ、1997年にM-root（WIDE、日本）が稼働してからは一度も変わっていません：

13に固定されて以降、A〜Mの文字名は一切変わりません。変わるのはハードウェアのアップグレードとエニーキャストのミラーの追加だけです。インターネットのルートヒントファイル（named.root）は、数十億の再帰リゾルバーやスタブクライアントのコードにずっと前から組み込まれており、数字を1つ変えるだけでもインターネット全体のアップグレードが必要になります。

3. では、世界に本当に13台のマシンしかないのか？

いいえ。これは最もよくある誤解です。「13組のルートサーバー」とは13個のNS名（a〜m.root-servers.net）のことで、それぞれがIPv4アドレスとIPv6アドレスを1つずつ持っています — 13台の物理サーバーではありません。

各IPの背後にはエニーキャストのクラスターがあります。同じIPアドレスが世界中の数百のデータセンターから同時にBGPでアナウンスされ、ユーザーのDNSクエリはRTTが最も短いミラーへルーティングされます。ルートサーバーが「ダウンした」という場合、通常はある都市のミラーがメンテナンス中というだけで、世界全体の名前解決には影響しません。

2024年時点の13組のルートサーバーの状況

中国本土（北京、上海、深セン、広州、合肥など）には、F / I / J / K / Lを含む複数のルートサーバーのエニーキャストミラーノードが設置されており、中国国内からルートサーバーへのRTTの実測値は通常20ms未満です。

4. EDNS0の登場で、512バイトは実質的な制限ではなくなった

こんな疑問を持つかもしれません：今では4KB以上のDNSパケットも当たり前なのに、なぜ「13を突破」しないのか？

• EDNS0（1999年のRFC 2671、現行はRFC 6891） — より大きなUDPペイロード（一般的には4096バイト）をネゴシエーションでき、最新のリゾルバーはすべて対応しています
• DNSSECではEDNS0が必須です。署名データだけで512バイトを大きく超えるためです
• TCPフォールバック — 現在では、TCPの3ウェイハンドシェイクにTLS / Cookieを加えても、コストはすでに低くなっています

しかし、ルートサーバーの一覧は今やネットワーク全体の合意事項です。世界中のすべての再帰リゾルバーがヒントファイル（named.root）にこの13組をハードコードしており、その背後には数十億台の端末があります。変更する動機はゼロで、リスクは世界のインターネットの分断であるため、この数字はほぼ確実に今後も13のままでしょう。

ひとことで言えば：「13組」は物理的にはとうに時代遅れですが、エンジニアリング上は覆すことができません。

5. まとめ

1. 歴史的な理由：DNS over UDPの512バイト制限 → 数学的な上限は15組 → 余裕を持たせて13組を採用し、1997年にM-rootが稼働した時点で固定
2. プロトコルの慣性：数十億台の端末のヒントファイルを更新するのは現実的ではないため、変わることはない
3. 実際の規模：1395か所以上のエニーキャストミラーノードがあり、単一障害点のリスクはほぼゼロ
4. 中国からの到達性：F / I / J / K / Lを含む複数のルートサーバーが中国本土にミラーを置いており、RTTの実測値は20ms未満