ルートネームサーバー（Root Name Server）
概要
ルートネームサーバー（Root Name Server） は、DNS 階層の最上位に位置し、TLD（トップレベルドメイン）ネームサーバーへの参照（リファラル）を返すサーバー群です。RFC 1035（1987年）で DNS の階層構造が定義され、ルートネームサーバーはその頂点として機能します。
再帰リゾルバーがキャッシュを持たない状態でドメインを解決するとき、最初に問い合わせるのがルートネームサーバーです。ルートネームサーバーは example.com の IP アドレスを直接返すことはしません。「.com の TLD ネームサーバーはここにある」というリファラルを返し、再帰リゾルバーに次の問い合わせ先を教えます。
ルートネームサーバーは 13 の識別名（a.root-servers.net から m.root-servers.net）で運用されています。13 という数は、DNS 応答が 1 つの UDP パケット（512 バイト、EDNS0 以前の制限）に収まるように設計された結果です。ただし、各識別名の背後には Anycast 技術を使った数百のサーバーインスタンスが世界中に分散しています。ICANN の報告では、2024 年時点でルートサーバーのインスタンス総数は 1,700 以上です。
仕組み
ルートネームサーバーはルートゾーンファイルを配信し、Anycast で世界中に分散配置されています。
ルートゾーンとその内容
ルートネームサーバーが配信するのは「ルートゾーンファイル」と呼ばれるデータです。ルートゾーンファイルには、すべての TLD（.com、.net、.org、.jp など）の NS レコードとそのグルーレコード（IP アドレス）が記録されています。
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30IANA（Internet Assigned Numbers Authority）がルートゾーンの管理を担当し、Verisign がルートゾーンの配布を運用しています。TLD の追加や NS レコードの変更は、IANA を通じて行われます。
名前解決におけるルートサーバーの役割
再帰リゾルバーが www.example.com を解決する際のフローです。
- 再帰リゾルバーがルートネームサーバーに
.への問い合わせを送る - ルートネームサーバーは
.comTLD ネームサーバーの NS レコードとグルーレコードを返す（リファラル） - 再帰リゾルバーは
.comTLD ネームサーバーに問い合わせる - 以降、TLD ネームサーバー → 権威ネームサーバーへと問い合わせが連鎖する
ルートネームサーバーが返すのはリファラルのみです。最終的なドメインの A レコードや MX レコードを返すことはありません。
13 の識別名とオペレーター
| 識別名 | オペレーター | Anycast サイト数（参考） |
|---|---|---|
| A | Verisign | 多数 |
| B | USC-ISI | 少数 |
| C | Cogent | 多数 |
| D | University of Maryland | 多数 |
| E | NASA | 多数 |
| F | ISC（Internet Systems Consortium） | 多数 |
| G | US DoD NIC | 少数 |
| H | US Army Research Lab | 少数 |
| I | Netnod（スウェーデン） | 多数 |
| J | Verisign | 多数 |
| K | RIPE NCC（ヨーロッパ） | 多数 |
| L | ICANN | 多数 |
| M | WIDE Project（日本） | 多数 |
M ルートサーバーは日本の WIDE Project が運用しており、日本国内にも Anycast サイトが配置されています。
Anycast による分散
13 の識別名はそれぞれ 1 つの IP アドレスを持ちますが、Anycast により同じ IP アドレスが世界中の複数の拠点で応答します。クライアントからのクエリは、BGP ルーティングによって最も近い Anycast サイトに到達します。この仕組みにより、ルートネームサーバーへのアクセスは地理的に分散され、レイテンシの低減と DDoS 耐性の向上を実現しています。
ルートサーバーの DNSSEC
2010 年 7 月 15 日、ルートゾーンへの DNSSEC 署名が完了しました。ルートゾーンの KSK（Key Signing Key）は ICANN が管理し、DNSSEC の信頼の連鎖（Chain of Trust）のトラストアンカーとなっています。DNSSEC 対応リゾルバーは、ルートゾーンの KSK を起点にすべてのゾーンの署名を検証します。
2018 年 10 月 11 日には、初めてのルート KSK ロールオーバーが実施されました。
ルートヒンツ
再帰リゾルバーは起動時に「ルートヒンツ（root hints）」ファイルを読み込みます。ルートヒンツにはルートネームサーバー 13 個の名前と IP アドレスが記載されています。IANA が公開するルートヒンツファイル（named.root）は、BIND、Unbound、PowerDNS Recursor などの主要な再帰リゾルバーソフトウェアに同梱されています。
RFC 8109（2017年）は、再帰リゾルバーがルートヒンツを「プライミングクエリ」によって自動的に最新化する仕組みを規定しています。起動時にルートネームサーバーに NS クエリを送信し、最新のルートサーバーリストを取得します。
確認方法
ルートネームサーバーに直接問い合わせるには、dig の @ オプションでルートサーバーを指定します。
# ルートネームサーバーに .com の NS レコードを問い合わせる
dig NS com. @a.root-servers.net;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...ルートからドメインまでの委任経路を全てトレースするには +trace を使います。
dig A example.com +traceルートネームサーバー → TLD ネームサーバー → 権威ネームサーバーの順に各ステップの応答が表示されます。
外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/dns?domain=example.com&type=NS"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"NS": [
"ns1.example.com",
"ns2.example.com"
]
}
},
"error": null,
"meta": { "responseTime": 45 }
}records.NS に権威ネームサーバーのホスト名が返ります。この結果は再帰リゾルバーがルートネームサーバーから権威ネームサーバーまでを辿った最終結果です。
よくある問題
ルートネームサーバーに関するトラブルは、ネットワーク到達性、ルートヒンツの陳腐化、DDoS 攻撃の 3 つに集約されます。
ルートサーバーへの到達性がない
ファイアウォールが UDP/TCP ポート 53 をブロックしている環境では、再帰リゾルバーがルートサーバーに到達できず名前解決が全面的に停止します。企業ネットワークでは、再帰リゾルバーからのアウトバウンド DNS トラフィックが許可されていることを確認してください。
ルートヒンツが古い
ルートサーバーの IP アドレスは稀に変更されます。2015 年に B ルートサーバーの IPv4 アドレスが 199.9.14.201 に変更され、2017 年に D ルートサーバーが 199.7.91.13 に変更されました。古いルートヒンツを使い続けると到達できないサーバーが生じます。RFC 8109 のプライミングクエリに対応したリゾルバーは自動で最新化しますが、対応していない古いリゾルバーではルートヒンツファイルの手動更新が必要です。
DDoS 攻撃への耐性
ルートネームサーバーは DDoS 攻撃の標的になることがあります。2015 年 11 月と 2016 年 6 月に大規模な DDoS 攻撃が確認されていますが、Anycast の分散配置により全面的なサービス停止には至りませんでした。再帰リゾルバーは複数のルートサーバーにクエリを分散するため、一部のルートサーバーが応答しなくても名前解決に影響が出にくい設計です。