ネームサーバーの変更は、レジストラの管理画面で値を書き換えるだけなら数分で終わります。しかし、新しい DNS にレコードを移し忘れると、サイトやメールが止まります。安全に切り替えるには、「新しい DNS を先に完成させ、正しく応答することを確認してから NS を切り替え、古い DNS はしばらく残す」という順番を守ることが大切です。この記事では、その手順を確認コマンドとともに説明し、DNSSEC を使っている場合の注意点も扱います。
ネームサーバーの変更で何が変わるのか
ネームサーバー（NS）は、そのドメインの DNS レコードを答える権威サーバーの指定です。NS を変えると、「example.com の情報はどこに聞けばよいか」という案内が、上位のレジストリ（.com なら Verisign、.jp なら JPRS）で書き換わります。
ここで押さえておきたいのは、NS の変更はレコードの中身を移すものではない、という点です。旧 DNS に登録されていた A レコードや MX レコードは、新しい DNS には自動で引き継がれません。新しい DNS に同じレコードを用意しておかなければ、切り替えた時点でそのレコードは「存在しない」状態になります。
手順1: 現在のレコードを洗い出す
まず、旧 DNS に登録されているレコードを漏れなく控えます。DNS 事業者の管理画面にゾーンのエクスポート機能があれば、それを使うのが手早い方法です。ない場合は、管理画面の一覧を写し取ります。
dig で主要なレコードを確認することもできますが、外部からの問い合わせでは名前を知らないレコードを列挙できない点に注意が必要です。
# 主なレコードを確認する（すべてを列挙できるわけではない）
dig example.com A +short
dig www.example.com A +short
dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig example.com CAA +short見落としやすいのは次のレコードです。
- DKIM:
セレクター名._domainkey.example.comという名前で登録されており、セレクター名が分からないとdigで探せません。利用中のメールサービスの管理画面で、使っているセレクターを確認します。 - サービスの所有確認用 TXT: Google Search Console、メール配信サービス、証明書の発行などのために置いた TXT レコードです。消えると後で再確認を求められることがあります。
- サブドメイン:
mail、shop、api、stagingなど、普段意識していない名前に設定されたレコードです。 - SRV や CNAME: 外部サービスとの連携に使われていることがあります。
手順2: 新しい DNS にレコードを登録する
洗い出したレコードを、新しい DNS 事業者（または移転先のサーバー会社）の管理画面に登録します。ゾーンファイルのインポートに対応していれば、エクスポートしたファイルを読み込めます。インポートした場合も、内容が正しく取り込まれたかを一覧で確認します。
あわせて、サーバーの引っ越しも同時に行う場合は、IP アドレスを新しいサーバーのものにするのか、しばらく旧サーバーのままにするのかを決めておきます。NS の切り替えとサーバーの切り替えを同時に行うと、問題が起きたときに原因を切り分けにくくなるため、可能なら別々の日に分けるのがおすすめです。
手順3: 切り替え前に新しい DNS を検証する
NS を切り替える前でも、新しい DNS に直接問い合わせれば応答を確認できます。ここで旧 DNS と同じ結果が返ることを確かめるのが、この作業でもっとも大事な工程です。
# 新しい権威DNSに直接問い合わせる
dig @ns1.new-dns.example.net example.com A +short
dig @ns1.new-dns.example.net example.com MX +short
dig @ns1.new-dns.example.net example.com TXT +short
# 旧DNSの応答と比べる
dig @ns1.old-dns.example.net example.com A +short手順1で控えた名前とレコード種別のすべてについて、新旧で同じ値が返るかを確認します。差分がなくなってから、次に進みます。
手順4: DNSSEC を使っているか確認する
DNSSEC を有効にしている場合は、ここで特に注意が必要です。上位のレジストリに DS レコードが登録されたまま、署名の鍵を持たない新しい DNS に NS を切り替えると、DNSSEC を検証するリゾルバーでは名前解決に失敗します（SERVFAIL）。
# DSレコードが登録されているか確認する
dig example.com DS +short何か返ってくる場合は、一般的には次の順で進めます。
- レジストラの管理画面で DS レコードを削除する（DNSSEC を無効にする）
- DS レコードのキャッシュが消えるまで待つ（DS の TTL を目安に、余裕を持って1〜2日程度）
- NS を切り替える
- 新しい DNS 事業者で DNSSEC を有効にし、新しい DS レコードをレジストラに登録する
事業者によっては、DNSSEC を維持したまま移行する方法を案内している場合もあります。その場合は移行先の手順に従ってください。
手順5: レジストラで NS を変更する
準備が整ったら、ドメインを契約しているレジストラの管理画面でネームサーバーを書き換えます。新しい DNS 事業者から指定されたホスト名を、すべて入力します。1台だけ入れて残りを空欄にしたり、旧 DNS と新 DNS を混ぜて登録したりしないようにします。混在させると、問い合わせ先によって異なる応答が返り、原因の分かりにくい不具合になります。
作業は、問題が起きても対応しやすい時間帯に行います。
手順6: 反映を確認する
上位のレジストリに直接問い合わせると、NS の変更が登録されたかを確認できます。
# .com の場合（.jp なら @a.dns.jp）
dig example.com NS @a.gtld-servers.net +norec
# 経路をたどって確認する
dig example.com +traceレジストリ側の変更は比較的早く反映されますが、各地のリゾルバーは古い NS の情報をキャッシュしています。.com の NS レコードの TTL は 2日（172800秒）に設定されているため、すべてのリゾルバーで新しい DNS が使われるまで、最大でそのくらいの時間がかかります。この期間の長さは利用者側では短縮できません。
手順7: 旧 DNS はしばらく残す
反映の途中は、新旧どちらの DNS にも問い合わせが来ます。旧 DNS のゾーンをすぐに削除すると、古いキャッシュを持つ利用者からはサイトが見えなくなります。少なくとも数日、できれば1週間ほどは旧 DNS の設定を残し、その間はレコードの変更が必要になったら新旧両方に反映します。
旧 DNS がレンタルサーバーやレジストラの付帯サービスの場合、解約や移管でゾーンが消えることがあります。解約の手続きは、切り替えが落ち着いてから行います。解約や移管でゾーンがいつ消えるかは事業者によって異なり、変更されることもあるため、各社の案内で確認してください（2026年10月現在）。
まとめ
- NS の変更はレコードの中身を移す作業ではありません。新しい DNS に、すべてのレコードを先に登録します。
- 切り替え前に、新しい DNS へ直接
digで問い合わせ、旧 DNS と同じ応答が返ることを確認します。 - DKIM や所有確認用 TXT など、外から列挙できないレコードの見落としに注意します。
- DNSSEC を使っている場合は、DS レコードの扱いを決めてから切り替えます。
- 反映には最大で NS の TTL 分の時間がかかります。旧 DNS はしばらく残しておきます。