## この記事でわかること

- ネームサーバー（NS）は「このドメインのDNSは誰が管理しているか」を答える存在であること
- ドメイン取得時にはレジストラのデフォルトNSが使われ、後から別事業者に変えられること
- ネームサーバーは最低2台必要で、変更後の伝播には最大48時間ほどかかること

## ネームサーバーとは｜DNSの管理場所を指し示す存在

ネームサーバー（NameServer、略してNS）は、ドメインのDNS（ディーエヌエス、Domain Name System）レコードを実際に保持しているサーバーのことです。「example.co.jp というドメインのDNSは、どこに聞けばわかるのか？」という問いに答える役割を持っています。

ここで混同しやすいのが、レジストラとネームサーバーの違いです。

- **レジストラ**: ドメインの所有権を管理する事業者。お名前.com、Xserver Domain、Google Domains など。年間料金を払う相手はここ
- **ネームサーバー**: そのドメインのDNSレコードを実際に持っているサーバー。レジストラが提供することもあれば、Cloudflareなど別事業者を指定することもある

つまり「ドメインを買うところ」と「DNSの中身を持つところ」は、同じでも別でも構いません。多くのサイト運営者では、レジストラが用意しているデフォルトのネームサーバーをそのまま使っていることがほとんどですが、後からCloudflareなどの別事業者に切り替えることもできます。

![ドメインからDNSレコードまでのチェーン](/blog/nameserver-basics-smb/ns-chain.svg)

## ネームサーバーが果たしている役割

世界中のDNSは、トップから順番に問い合わせをたどる仕組みになっています。ブラウザが `www.example.co.jp` を解決するとき、おおまかには次のような流れです。

1. ルートサーバーに「.jp はどこに聞けばいい？」と問い合わせる
2. .jpの管理サーバーが「`example.co.jp` のNSはこのサーバーです」と答える
3. その指定されたネームサーバーに、Aレコードなど中身を問い合わせる

この2番目で返ってくるのが、まさにネームサーバーの情報です。ドメインを取得した時点で、レジストラがこの「自分のドメインのNSはどこか」をレジストリ（.jpなど）に登録しています。

たとえばお名前.comでドメインを取った直後は、`01.dnsv.jp` `02.dnsv.jp` のようなお名前.com提供のネームサーバーが設定されています。Cloudflareに移すと、`xxx.ns.cloudflare.com` `yyy.ns.cloudflare.com` のようなCloudflare側のネームサーバーに切り替わります。

DNS全体の仕組みは[DNSとは｜Web 担当者向けに5分でわかる入門](/blog/dns-basics)で図解しています。

## なぜネームサーバーは複数台必要なのか

ネームサーバーは、原則として1つのドメインに対して最低2台を登録します。これはDNSの基本仕様（RFC 1035）でも推奨されており、JPドメインなどのレジストリ側でも複数台の登録が前提になっています。

理由はシンプルで、**冗長性の確保**です。

- 1台しかネームサーバーがない場合、その1台が障害で停止すると、ドメインのDNS解決が世界中でできなくなります
- DNSが止まると、サイトが見られないだけでなく、メールも届かなくなります
- メンテナンスや障害は事業者側でも避けられないため、複数台に分散させて、どれかが応答すれば良い状態にしておきます

ネームサーバーが1台しかない、あるいは同じデータセンターに集中しているような構成は、見えないリスクとして残り続けます。社内の構成を点検する観点は[DNSインフラの健全性を見る基本](/blog/dns-infra-health)で詳しく整理しています。

## ネームサーバーを変更する場面と、伝播の注意点

中小企業で実際にネームサーバーを変更する場面は、主に次の3つです。具体的な変更手順と、メールを止めないための注意点は [ネームサーバー変更の手順と注意点](/blog/nameserver-change-howto) にまとめています。

- **DNS事業者を移すとき**: 「お名前.comのDNSからCloudflareに乗り換える」「さくらインターネットからお名前.comのDNSに統一する」など、DNSの管理画面ごと変えるケース。新しい事業者でレコードを準備してから、レジストラの管理画面でNSの宛先を切り替えます
- **レジストラごと移管するとき**: ドメインを別のレジストラに移すと、初期状態では新しいレジストラのデフォルトNSに切り替わることがあります。どちらのNSで運用するかを事前に決めておかないと、レコードがすべて消えたように見える事故につながります
- **新規ドメインの運用を始めるとき**: 新規ドメインで「最初からCloudflareで管理したい」というケースでも、レジストラのデフォルトNSからCloudflareのNSに変更する作業が発生します

ネームサーバーを変更しても、すぐには世界中に反映されません。各レジストリやキャッシュサーバーが古い情報を持っている間は、古いネームサーバーに問い合わせが流れ続けます。一般的な目安として、変更が世界中に行き渡るまで数時間〜48時間ほどかかります。この期間中は次のような状況が起こります。

- 一部のユーザーには新しい設定が、一部のユーザーには古い設定が見える
- メールも、新旧のサーバーに届く可能性がある
- 「変えたはずなのに反映されない」と感じても、実際は伝播の途中にいることが多い

この時間差を受け入れた上で、**新旧どちらのネームサーバーにも同じレコードを揃えておく**のが安全な進め方です。新側だけにレコードを書き、旧側のレコードを先に消してしまうと、伝播中のユーザーがレコードを引けず、サイト・メールの一部が止まったように見える事故になります。とくにメールはMXレコードの引き直しに失敗すると、配送の遅延ではなく差出人エラーになるケースもあるため、移行前に旧側のレコードを一覧として控えておくことが欠かせません。

![ネームサーバー変更時のフローとよくあるトラブル](/blog/nameserver-basics-smb/ns-change-flow.svg)

現場では、ネームサーバーを意識せずに運用しているケースが多く、それ自体は問題ありません。ただし次のような場面では一度確認しておくと安全です。担当者が交代したときは、前任者がどの事業者のネームサーバーを使っていたか、レジストラとDNSの分担はどうなっているかを引き継ぎます。メールやサイトの不具合が出たときは、ネームサーバー側の障害でDNS自体が引けていない可能性も疑えます。更新通知メールが古い住所に届いていると、NS変更を伴う移管の連絡が届かず、気づかぬうちにドメインが失効するリスクもあります。

ネームサーバーの構成は、ドメイン・サイト・メール全体の土台です。年に1回は、登録されているNSが何台あるか、どの事業者か、レコードの内容を控えてあるかを確認しておくと、いざというときに慌てずに済みます。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSLの状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。