13は、だいすうでは ありません。「A」から「M」まで、名前が 13こ ある、という 意味です。それぞれの 名前に、ネットの 番号（IPアドレス）が ついて います［2］。

その 番号の うしろに、世界の あちこちに おかれた 拠点きょてんが ならんで います。ぜんぶで 1500か所を こえます［1］。

おなじ 名前の コンビニが、町ごとに あるのと にて います。どこの 店に はいっても、同じ 名前の 店ですよね。この 「同じ 番号を、はなれた いくつもの 場所で 使う」 やり方を エニーキャストと いいます［6］。

ただし 本当は、店では なく コンピュータです。では、どうして 名前の 数は 13で とまったのでしょう。

ルートサーバーは「A」から「M」までの13個の名前（識別子）で呼ばれ、それぞれに IPv4 と IPv6 のアドレスが1つずつ割り当てられています［2］。「13台」と聞こえるのは、この名前の数が独り歩きしたからでしょう。

実際には、13個の名前に対応するアドレスの裏に世界各地の拠点（インスタンス）があり、全部あわせて1500をこえるものが動いています［1］。同じ名前のコンビニが町ごとにあって、どこでも同じ名前で通じるのに似ています。

この「1つのサービス用アドレスを、離れた複数の独立した場所で使えるようにする」やり方を、エニーキャストと呼びます［6］。ただし、コンビニは店ごとに住所がちがいます。エニーキャストでは、アドレスはまったく同じです。

そうなると、最初の疑問が戻ってきます。名前を13で止めたのは誰で、なぜだったのでしょうか。

ルートサーバーは世界に13台、という言い方はどこまで正確か。Root Server Technical Operations Associationの説明では、ルートサーバーの識別子（RSI）はAからMまでの13個で、各RSIはIPv4とIPv6のアドレスを1つずつ持つ［2］。13は台数ではなく識別子の数である。

RSSACのFAQは、識別子が13のままである一方、世界では1500を超えるエニーキャストのインスタンスが動いていると述べる［1］。つまり、利用者が見るアドレスは13組だが、その背後の実体はそれよりはるかに多い。これを可能にするのが、RFC 4786が「特定のサービス用アドレスを、複数の離れた自律的な場所で利用可能にする運用」と定義するエニーキャストである［6］。

この記事の数字は、運用者側の説明にある概数であり、拠点数は日々変わりうる。ここで押さえたいのは数の大小より、構造のほうだ。名前は13で止まっているのに、実体は増え続けている。この食いちがいは、なぜ生まれたのか。

1985年には、ルートサーバーは 4だい だけ でした［3］。そこから ふえて、1997年ごろ、13で 頭うちに なったと いわれて います［1］。

わけは、返事の 大きさです。ネットで よく 使う 小さな 手紙の 形では、文は 512バイトまで と きまって いました。名前が ふえると、返事を ぜんぶ 書いた 手紙が ふうとうに 入りきらなく なります［1］。

そのころは、名前を ふやすのは むずかしく、今も 名前は 13の ままです。でも、拠点きょてんの 数には、もともと かぎりが ありません［1］。ここが ぬけ道に なりました。

1985年の時点で、ルートサーバーは4台だけでした［3］。その後に増えましたが、1997年に識別子が13個で頭打ちになったと、RSSACは説明しています［1］。

理由は、返事の大きさでした。RFC 1035は、UDPで運ぶDNSメッセージを512バイトまでと決めています。ルートサーバーの名前を増やすと、「ルートサーバーの一覧」を伝える返事が512バイトを超えてしまうのです［1］。小さな封筒に、ちょうど入る数が13だった、と考えるとイメージしやすいでしょう。

ただし、封筒のたとえは大きさの感覚をつかむためのもので、実際の中身の書き方とは別の話です。

ここに抜け道がありました。当時は名前（アドレス）の数を増やしにくく、今も13個のままですが、エニーキャストの拠点の数には、本質的な上限がないとされています［1］。アドレスは13組のまま、同じアドレスを名乗る拠点を増やせばよいのです。では、同じアドレスの拠点がたくさんあるとき、どこが答えるのでしょうか。

識別子はなぜ13個で止まったのか。RSSACのFAQは、1997年にこの数で頭打ちになった理由を、RFC 1035の規定に結びつけて説明する。UDPで運ぶDNSメッセージは512バイトに制限されており、ルートネームサーバをさらに加えると、起動時に使う一覧の問い合わせ（プライミング）への応答が512バイトを超える、というものだ［1］。

初期の規模は小さく、1985年には4台しかなかった［3］。台数は4から13まで増えたが、その先は応答の大きさの制約に当たった。ここで拡張の方向は2つに分かれる。メッセージの大きさの規定を変えるか、識別子の数を13のまま、その背後の実体を増やすかである。現在も使われているのは後者で、RSSACは「エニーキャストのノード数に本質的な上限はない」としている［1］。

この設計が成り立つのは、利用者から見えるものがアドレスだからだ。アドレスが13組のままなら応答の大きさは変わらず、実体の数だけが自由に増える。では、同じアドレス宛てに送られたデータは、どの実体に届くのか。それを決めるのは何か。

ふつうは、番号は 1つの コンピュータに 1つです。エニーキャストでは、同じ 番号の コンピュータが 世界に たくさん あります。どの 拠点きょてんが 答えるかは、ネットの 経路けいろを きめる しくみが 決めます［6］。

この やり方を、ルートサーバーを 動かす 組織そしきの なかで 2002年に はじめて 取り入れたのは、ISCだと いわれて います［1］。ねらいは、ネットの 道が まだ 少ない 地いきにも サーバーを ふやして、返事が おそく なるのを へらす ことでした［5］。

ただし 「近い」と いっても、地図の 上の 近さとは かぎりません。ネットの 道すじで 「近い」と えらばれる 拠点きょてんが、返事も いちばん 早いとは かぎらないと されて います［6］。

ふつう、1つのIPアドレスは1台のコンピュータのものです。エニーキャストでは、同じアドレスを持つ拠点が世界に多数あり、どの拠点が各リクエストに応えるかは経路制御システムが決めます［6］。

ルートサーバーの運用者として初めてこの方式を入れたのは、2002年のISC（Internet Systems Consortium）だと、RSSACは書いています［1］。この技術が開発された主な理由は、ネットワークの形がまだ整っていない地域にもDNSサーバーを置くことと、遅延を減らすことでした［5］。

ここで1つ、気をつけたい点があります。経路制御で選ばれる「近さ」（ネットの道すじでの近さ）は、通信の往復時間の速さとは、一般には一致しません［6］。選ばれる拠点が、地理的にも、速さでも、いちばん近いとは限らないのです。地図の上で近い隣町の店より、高速道路がつながっている少し遠い店のほうが早く着くことがありますが、似た感覚です。

とはいえ、運用者は経路の出し方を調整します。たとえばRIPE NCCは、K-rootの各拠点から同じアドレスの経路情報を発信しています［7］。ところで、遅れを減らすのが目的だったなら、遅れは実際に利用者へ響いているのでしょうか。

同じアドレス宛てのパケットが、どの拠点に届くのか。RFC 4786は、各リクエストにどのノードが使われるかは経路制御システムが決める、と述べる［6］。運用者が個々の問い合わせを振り分けるのではなく、各拠点が同じアドレスの経路情報を発信し、ネットワーク側の経路選択が届け先を定める構造である。

RIPE NCCのK-rootの例では、各ノードがAS25152から193.0.14.0/23などのプレフィックスをアナウンスし、一部のノードは2001:7fd::/32も発信する［7］。ルートサーバーの運用者として最初にエニーキャストを導入したのは2002年のISCだとRSSACは記す［1］。RFC 3258によれば、この技術の主な動機は、ネットワークトポロジー上で十分にサービスされていなかった地域へDNSサーバーを分散させ、遅延を減らすことだった［5］。

ただし、この方式には前提のずれがある。RFC 4786は、経路制御上の近さは、一般にはネットワーク上の往復の性能とは相関しないと注意している［6］。したがって、選ばれる拠点は地理的にも性能的にも最寄りとは限らない。「近い拠点が答える」は設計の期待であって、保証ではない。

もう1つの注意は、長く続く通信である。経路が途中で変わると、TCPのような持続する通信は別の拠点へ送られて失敗しうる、と運用者に注意が促されている［6］。一回の問いと答えで終わる通信が多いルートへの問い合わせに向く一方、長い通信では慎重さが要る、という読み方ができる。では、遅延の短縮は、利用者の体感にどれほど効くのか。

ルートサーバーは、ふつうに ネットを 使う 人の 目に 見える おそさには、ほとんど かかわらない、と 運用して いる 人たちは 話して います［2］。

ひみつは、おぼえて おく ことです。ルートは、「この 名前の 右の 部分は、こちらの 人が 知って います」と 次の まどぐちを 案内あんない する 役です［4］。その 答えは、たいてい 2日間、おぼえて おいて よい ことに なって います［8］。

その 案内あんないを おぼえて いる あいだは、また ルートに 聞かなくて すみます。だから、遠い 拠点きょてんが 答えても、ふだんは 気づきません。

遅れを減らすために始まったエニーキャストですが、運用者の団体は、ルートサーバーまでの遅れが、ふつうのパソコン利用で目に見える遅れにはほとんど影響しないと説明しています［2］。

理由の1つはキャッシュです。ルートサーバーは、最終的な答えではなく、「この名前の担当はあちらのネームサーバー」という案内（リファラル）を返す役目です［4］。ルートゾーンにある各トップレベルドメインの案内は、有効期限（TTL）が2日に設定されており、リゾルバー（利用者の代わりに調べるプログラム）は、その案内をキャッシュに残している間は、ルートに聞き直さずにすみます（リゾルバーによっては、保存の上限を24時間などにしています）［8］。

そのため、「サイトを開くたびにルートへ聞いている」わけではありません。ルートが遠くても、聞く回数が少ないので、体感はあまり変わらないのです。

では、エニーキャストは意味がなかったのでしょうか。そうではありません。もう1つの大きな役目があります。

エニーキャストの動機が遅延の短縮だったなら、利用者はそれを実感できるのか。運用者側のFAQは、ルートサーバーまでの遅延が、一般的なコンピュータ利用でユーザーに見える遅延に与える影響はほぼゼロだと述べる［2］。

その理由は、ルートの役目と有効期限にある。ルートネームサーバは最終的な答えを返さず、より近い祖先ゾーンのネームサーバへの案内（RFC 1034のリファラル）を返す［4］。さらにRFC 9199によれば、ルートゾーン内の各TLDのNSレコードのTTLはすべて2日に設定されており、リゾルバーはその案内をキャッシュに残している間、ルートへ聞き直さない（実装によっては保存の上限を24時間などにする）［8］。結果として、ルートへの問い合わせ自体が相対的に少なく、1回あたりの遅れが多少変わっても、体感への影響は小さい。

ここから、エニーキャストの価値を遅延だけで測るのは不十分だとわかる。RFC 3258の動機は、遅延の削減と、ネットワークの手薄な地域への分散だった［5］。遅延が体感に響かないのなら、残るのは分散した構造そのものの価値、つまり攻撃や過負荷に対する強さである。実際はどうか。

ネットには、まちがって、あるいは わざと、とつぜん たくさんの 通信つうしんが おしよせる ことが あります。エニーキャストでは、おしよせた 通信つうしんは、それぞれの 拠点きょてんの まわりの 地いきに とどまりやすい、と いわれて います［6］。

2016年などの 大きな おしよせでも、ルートサーバー ぜんたいが 止まった ことは ない、と 運用して いる 人たちは まとめて います［2］。

また、ルートサーバーを 運用して いる 人たちは、どの国の 人にも、どの ネットにも、どの 名前にも、同じ ように 答える ことを やくそくして います［2］。ただし、エニーキャストは どこでも 使える まほうでは ありません。つかい方には 注意が いります。

エニーキャストの、もう1つの効果が、大量のアクセスの封じ込めです。RFC 4786は、分散型のサービス妨害攻撃や、急にアクセスが集まる現象を、各拠点の周辺の地域にとどめる効果があると述べています［6］。

運用者の団体は、2016年のような過去の大規模な攻撃でも、ルートサーバーシステムは設計どおりに働き、全体としての頑丈さが示された、とまとめています［2］。システム全体がダウンしたことはないとされていますが、これは運用者側の説明であり、個々の拠点に影響が出なかったという意味ではありません。

運用の方針も、この仕組みと並んで大切です。ルートサーバーの運用者は、特定の国やネットワークからの通信を止めたり、特定のトップレベルドメインを選んで締め出したりせず、すべての利用者・ネットワーク・ドメインに等しく応えることを約束しています［2］。

一方で、エニーキャストには向き不向きがあります。経路が途中で変わると、長く続く通信は別の拠点へ送られて失敗しうる、と運用者に注意が促されています［6］。同じ文書は、サービスの規模拡大に関する問題から、エニーキャストを世界的な一般手法として使うことには向かないとも述べます。ルートのように役割が限られたサービスだから、うまく使える面があるのでしょう。

遅延が体感に響かないなら、エニーキャストの実質的な価値はどこにあるか。1つは攻撃や過負荷の局所化である。RFC 4786は、エニーキャスト導入の利点の1つとして、分散型サービス妨害攻撃やフラッシュクラウドを、各ノード周辺の地域に封じ込めることを挙げる［6］。拠点ごとに受け持つ範囲が分かれているため、1か所に集中するはずの負荷が複数の拠点に割れる。

運用者側の記述でも、2016年を含む大規模なトラフィックの洪水に対して、ルートネームサーバシステムは設計どおりに機能し、全体として頑丈であることが示されたとされる［2］。ただし、これは運用者団体による自己評価であり、個々の拠点や特定の利用者への影響の有無を述べたものではない。

運用ポリシーも、構造と合わせて読む必要がある。ルートサーバー運用者は、特定の国やネットワークからの通信を遮断せず、特定のTLDをフィルタしないと表明し、すべての利用者、ネットワーク、TLDに等しくサービスを提供するとしている［2］。

限界も書かれている。RFC 4786は、経路変更が起きると、特に長時間続くフローでは失敗モードがありうるとし、TCPのような持続的な通信を行うサービスの運用者に注意を促す［6］。さらに同文書は、サービスの規模拡大に関する問題を理由に、エニーキャストを世界的な一般手法としては向かないとも述べる。つまりエニーキャストは、短い問いと答えが中心で、運用者が経路を細かく管理できるルートのような用途に、条件つきで適した方式だといえる。

今日 できること

ちかくの 道を 歩く とき、同じ 名前の お店を さがして みましょう。コンビニでも、パンやさんでも だいじょうぶ です。おうちの 人と いっしょに、道に 気を つけて ください。

そして 考えて みます。同じ 名前の お店が 町ごとに あるのは、どんな とき ありがたい でしょう。1つの お店が いっぱいに なっても、ほかの 町の 店は 空いて います。ルートサーバーの 拠点きょてんも、ちょっと にて います。

もっと 知りたい とき

もっと 知りたく なったら、下の 「しらべた もとの じょうほう」を おうちの 人と 見て みましょう。えいごの しりょうが 多いので、見なくても だいじょうぶ です。

今日できること

通学路や買い物の道で、同じ名前のお店を探して、「どの店に入るか」を何で決めるか考えてみましょう（いちばん近い、空いていそう、など）。それぞれの店は住所がちがいますが、エニーキャストは住所まで同じです。「同じ名前で、近い店が応える」場合と「同じアドレスで、経路がたまたま選んだ拠点が応える」場合のちがいを、頭の中で比べてみてください。

もっと調べたいとき

RSSAC（ICANNの助言組織）のFAQには、13の理由と拠点数が短くまとまっています。エニーキャストの考え方はRFC 4786、動機はRFC 3258が原典です（英語の原文です）。

おまけとして、パソコンに詳しい人が使うdigというコマンドには、どの拠点が答えたかを示す仕組み（NSID）があると、RSSACのFAQが紹介しています［1］。やらなくても、この記事の内容はつかめます。

今日できること

身近な同名チェーン店を例に、「同じ名前の複数の実体」の便利さと限界を書き出してみる。混雑の分散は利点だが、どの店が混んでいるかを客は選べない。エニーキャストでは、どの拠点に着くかを経路が決める点がこれに当たる。

資料を読むなら

RSSACのFAQ（13の理由と拠点数）、RFC 4786（運用の考え方と注意点）、RFC 3258（動機）、RFC 9199（TTL）が入口になる（英語の原文）。任意の発展として、応答した拠点の識別には、dig の NSID オプションを用い、出力の OPT Pseudosection の NSID 文字列を見る方法がRSSACのFAQに載っている［1］。資料やコマンドに触れなくても、上の観察だけで本文の要点は確かめられる。