ネームサーバの仕組み
ネームサーバとDNSの違い
ほぼ同じ文脈で使われますが、厳密には異なります。
| DNS | ネームサーバ | |
|---|---|---|
| 何か | 仕組み・ルール全体の名前 | その仕組みの中で動く実際のサーバ |
| 例えるなら | 「電話帳のシステム」 | 「電話帳を持っている窓口の人」 |
DNS（Domain Name System） は、ドメイン名からIPアドレスを調べるための仕組み全体を指します。プロトコル、ルール、レコードの形式などを含む概念です。
ネームサーバ は、DNSという仕組みの中で実際に問い合わせに回答するサーバのことです。DNSサーバとも呼ばれますが、同じものです。
「ネームサーバ」=「DNSサーバ」（呼び方が違うだけ）
紛らわしいのは「DNS」が2つの意味で使われること：
- DNS = 仕組み全体（Domain Name System）
- DNSサーバ = その仕組みの中で動くサーバ = ネームサーバ
DNS = 仕組み全体
├── ネームサーバ = 問い合わせに答えるサーバ（例: kellen.ns.cloudflare.com）
├── DNSレコード = サーバが持っている対応表（A, CNAME, MX, NS, TXT...）
├── リゾルバ = ユーザー側で問い合わせを行うプログラム
└── プロトコル = 問い合わせのルール（UDP 53番ポートなど）
日常的には「DNS変更した」「ネームサーバ変更した」はほぼ同じ意味で使われます。厳密に言い分けるなら：
- 「ネームサーバを変更した」= 問い合わせ先のサーバを変えた
- 「DNSレコードを変更した」= 対応表の中身を変えた
DNSサーバはどれだけの情報を持っているのか
Cloudflareのような大手DNSプロバイダは、全ユーザーのDNSレコードを自社サーバに保持しています。
【CloudflareのDNSサーバ】
├── example.jp の対応表
├── someone-else.com の対応表
├── big-company.io の対応表
└── ... 数千万ドメイン分
これは膨大な数ですが、1つのDNSレコードは数十〜数百バイト程度の小さなデータです。仮に1億レコードあっても数十GB程度で、現代のサーバであれば全てメモリに載る量です。
レコード更新の仕組み
Cloudflareは世界300以上の拠点にサーバを持っていますが、レコードを1つ変更するとどうなるか：
管理者がCloudflareの管理画面でレコードを変更
│
▼
Cloudflareの中央データベースが更新される
│
▼
世界300以上の拠点に数秒以内で伝播される
この「数秒で世界中に反映」がCloudflareの強みです。
ただし、変更が速くても、古い情報をキャッシュしているリゾルバ（ユーザー側のDNS問い合わせプログラム）がいるため、利用者全員に届くにはTTL（キャッシュ有効期限）分の時間がかかります。
ドメインとネームサーバは別物
ドメインの管理には、2つの異なる役割があります。
| ドメインの所有（レジストラ） | ネームサーバ（DNS） | |
|---|---|---|
| 役割 | ドメイン名の「権利証」を管理 | ドメイン名と接続先の「対応表」を管理 |
| 例えるなら | 土地の登記所 | 住所から家への道案内人 |
ドメインの所有者を変えなくても、ネームサーバだけ別の会社に変更できます。
つまり、「土地の所有権はレジストラに預けたまま、道案内だけ別の会社にお願いする」ということが可能です。
ブラウザでWebサイトにアクセスすると何が起きるか
ユーザーが「app.example.jp」にアクセス
│
▼
① ブラウザ → リゾルバ（再帰リゾルバ）
「app.example.jp のIPアドレスを教えて」
※ リゾルバはISPやOS、1.1.1.1等が提供する「問い合わせ代行人」
│
▼
② リゾルバ → ルートDNS
「.jp を管理しているのは誰？」
│
▼
③ リゾルバ → .jp のレジストリ（JPRS）
「example.jp のネームサーバは誰？」
│
▼
④ JPRS の回答:
「kellen.ns.cloudflare.com に聞いて」
│
▼
⑤ リゾルバ → Cloudflare のネームサーバ
「app.example.jp のIPアドレスは？」
│
▼
⑥ Cloudflare の回答:
「xxxxx.cloudfront.net だよ」（CNAMEレコード）
│
▼
⑦ リゾルバ → ブラウザに結果を返す → CloudFront → Webサイト表示
ブラウザが直接ルートDNSやレジストリに問い合わせることはありません。全てリゾルバが代行します。
NS委任（サブドメインを別のDNSに任せる）
一部のサブドメインを別のDNSサービスに委任することができます。
example.jp（Cloudflare が管理）
├── app.example.jp → CloudFront（Cloudflareが直接回答）
├── www.example.jp → Vercel（Cloudflareが直接回答）
├── blog.example.jp → GitHub Pages（Cloudflareが直接回答）
│
├── aws.example.jp → 「Route53に聞いて」（NS委任）
└── azure.example.jp → 「Azure DNSに聞いて」（NS委任）
NS委任されたサブドメインは、Cloudflareは自分では回答せず、「あっちに聞いて」と別のDNSサーバを紹介します。これにより、サブドメインごとに異なるクラウドサービスで独立して管理できます。
ネームサーバ変更はどうやってレジストリに伝わるのか
ネームサーバを変更するとき、登場人物は3者います。
| 登場人物 | 役割 | 例 |
|---|---|---|
| レジストリ | TLD（.jp, .comなど）全体の台帳を管理 | JPRS（.jp）、Verisign（.com） |
| レジストラ | ドメインの販売・手続きの窓口 | お名前.com、Google Domains など |
| ユーザー | ドメインの所有者 | 自分 |
ユーザーが直接レジストリに連絡することはできません。必ずレジストラを通します。
① ユーザーがレジストラの管理画面でNS変更を申請
「example.jp のNSを kellen.ns.cloudflare.com にしてください」
│
▼
② レジストラがレジストリに通知
「example.jp のNSレコードを更新してください」
│
▼
③ レジストリがゾーンファイルを更新
example.jp の NS → kellen.ns.cloudflare.com / nora.ns.cloudflare.com
│
▼
④ 世界中のDNSキャッシュが順次更新される（数時間〜最大72時間）
ユーザーはレジストラに指示を出すだけで、レジストラがレジストリへの登録を代行してくれるという仕組みです。
移行中のアクセスはどうなるのか
ネームサーバ変更を申請してから、レジストリのゾーンファイルに反映されるまでには時間がかかります。この間、アクセスが途切れることはありません。
【移行の過渡期】
レジストラへの申請完了
│
▼
レジストリ（JPRS等）のゾーンファイル更新待ち ← ここに時間がかかる
この間、レジストリはまだ旧ネームサーバを返す
→ 旧ネームサーバにレコードが残っているのでアクセスは正常
│
▼
レジストリが新ネームサーバに切り替え
→ 新ネームサーバに同じレコードを登録済みなのでアクセスは正常
│
▼
世界中のリゾルバのキャッシュが順次更新される
つまり、旧ネームサーバのレコードを消さず、新ネームサーバに同じレコードを事前登録しておけば、移行中もアクセスが途切れることはないという仕組みです。
レジストリの更新にはどれくらいかかるか
レジストリ（JPRS等）のゾーンファイルは常時更新されているわけではなく、一定間隔でまとめて更新されます。
レジストラが申請
│
▼
レジストリのゾーンファイル更新（数時間〜24時間）
│ ※ JPRSは1日に数回ゾーンファイルを更新する
▼
各リゾルバのキャッシュが期限切れで更新（最大24時間）
│ ※ TTL（キャッシュ有効期限）に依存。一般的に86400秒 = 24時間
▼
全世界に反映完了
レジストラのメール等で「反映まで24〜72時間」と案内されるのは、この2段階（レジストリ更新＋キャッシュ伝播）の合計を保守的に見積もった数字です。実際には数時間で切り替わることが多いです。
ネームサーバ変更の全体像
【変更前】
レジストラ ──所有──→ example.jp
レジストラ ──DNS───→ example.jp のレコード管理
【変更後】
レジストラ ──所有──→ example.jp（変わらず）
Cloudflare ──DNS───→ example.jp のレコード管理（ここだけ変わった）
ドメインの契約・更新・支払いは引き続きレジストラで行い、DNSレコードの追加・変更・削除はCloudflareで行う、という分担になります。