TLD ネームサーバー（TLD Name Server）

概要

TLD ネームサーバー（TLD Name Server） は、.com、.net、.jp などのトップレベルドメイン（TLD）を管理する権威ネームサーバーです。再帰リゾルバーがルートネームサーバーから TLD の参照を受け取った後、次に問い合わせる先がこの TLD ネームサーバーです。RFC 1034 および RFC 1035（1987年）で定義された DNS 階層構造において、ルートゾーンと個別ドメインゾーンの間に位置します。

TLD ネームサーバーの役割は、個別ドメインの権威ネームサーバーへのリファラルを返すことです。.com の TLD ネームサーバーに example.com を問い合わせると、「example.com の権威ネームサーバーは ns1.example.com にある」というリファラルを返します。ドメインの A レコードや MX レコードを直接返すことはありません。

2024 年時点で IANA に登録されている TLD は 1,400 以上あり、gTLD（.com、.org、.net など）、ccTLD（.jp、.uk、.de など）、新 gTLD（.app、.dev、.tokyo など）に分類されます。

仕組み

TLD ネームサーバーは、再帰リゾルバーからの問い合わせに対して個別ドメインの権威ネームサーバーへのリファラルを返します。

DNS 階層における位置づけ

DNS の名前解決は階層を順に辿ります。

1. 再帰リゾルバーがルートネームサーバーに問い合わせる
2. ルートネームサーバーが .com TLD ネームサーバーの NS レコードを返す
3. 再帰リゾルバーが .com TLD ネームサーバーに example.com を問い合わせる
4. TLD ネームサーバーが example.com の権威ネームサーバーの NS レコードを返す
5. 再帰リゾルバーが権威ネームサーバーに問い合わせて最終回答を得る

TLD ネームサーバーはステップ 3〜4 を担当します。保持しているのは、各ドメインの NS レコード（委任情報）とグルーレコード（NS ホストの IP アドレス）です。

TLD の種類

分類	例	管理者
gTLD（汎用）	.com、.net、.org	Verisign（.com/.net）、PIR（.org）
ccTLD（国コード）	.jp、.uk、.de、.us	各国の NIC（JPRS が .jp を管理）
新 gTLD	.app、.dev、.tokyo、.blog	Google Registry、GMO など各レジストリ
インフラ	.arpa	IANA / IETF

.com と .net は Verisign が運用する a.gtld-servers.net から m.gtld-servers.net の 13 台の TLD ネームサーバーで管理されています。.jp は JPRS（Japan Registry Services）が運用しています。

委任情報の登録フロー

ドメイン登録から TLD ネームサーバーへの反映は次の流れで進みます。

1. ユーザーがレジストラ（お名前.com、Cloudflare Registrar など）でドメインを登録する
2. レジストラがレジストリ（.com なら Verisign）に NS レコードを登録する
3. レジストリが TLD ネームサーバーのゾーンデータを更新する
4. 再帰リゾルバーが TLD ネームサーバーに問い合わせた際に、新しい委任情報が返る

ネームサーバーの変更も同じフローです。レジストラの管理画面で NS を変更すると、レジストリを経由して TLD ネームサーバーに反映されます。反映までの時間はレジストリによって異なり、.com では通常数分〜十数分です。

グルーレコード

権威ネームサーバーが ns1.example.com のように自身のドメイン配下にある場合、循環参照が発生します。example.com を解決するには ns1.example.com の IP が必要ですが、ns1.example.com を解決するには example.com の権威サーバーの IP が必要です。

この循環を解消するのがグルーレコードです。TLD ネームサーバーが NS レコードを返す際、追加情報セクション（Additional Section）に NS ホストの A レコードも含めて返します。

;; AUTHORITY SECTION:
example.com.	172800	IN	NS	ns1.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.	172800	IN	A	192.0.2.1

権威ネームサーバーが ns1.cloudflare.com のように別のドメイン配下にある場合、グルーレコードは不要です。cloudflare.com の権威サーバーは別途解決できるためです。

確認方法

TLD ネームサーバーの動作を確認するには、dig で TLD サーバーに直接問い合わせます。

# .com TLD ネームサーバーに example.com の NS を問い合わせる
dig NS example.com @a.gtld-servers.net

;; AUTHORITY SECTION:
example.com.		172800	IN	NS	ns1.example.com.
example.com.		172800	IN	NS	ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.	172800	IN	A	192.0.2.1

+trace オプションを使うと、ルートから権威サーバーまでの委任経路を一括で確認できます。

dig A example.com +trace

外部の視点からも確認したい場合は、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 }
}

よくある問題

TLD ネームサーバーに関するトラブルの大半は、委任情報の反映タイミングやグルーレコードの更新漏れが原因です。

ネームサーバー変更が反映されない

レジストラでネームサーバーを変更しても、TLD ネームサーバーへの反映にはレジストリの処理時間が必要です。.com では通常数分ですが、一部の ccTLD では数時間かかることがあります。再帰リゾルバーが旧 NS レコードをキャッシュしている場合、NS レコードの TTL（標準的な値は 172800 秒 = 48 時間）が切れるまで旧ネームサーバーに問い合わせが続きます。

グルーレコードの更新漏れ

権威ネームサーバーが自ドメイン配下（ns1.example.com）にある状態でサーバーの IP アドレスを変更した場合、レジストラの管理画面でグルーレコード（ホスト情報）も更新する必要があります。権威サーバー側の A レコードだけを変更しても、TLD ネームサーバーが返すグルーレコードは旧 IP のままとなり、名前解決に失敗します。

TLD ネームサーバーの障害

特定の TLD ネームサーバーに障害が発生すると、その TLD 配下の全ドメインの名前解決に影響します。ただし、TLD ネームサーバーは複数台で冗長化されており、Anycast で分散配置されています。.com は 13 台の TLD ネームサーバーで運用されているため、数台が障害になっても残りのサーバーが処理を継続します。