ネームサーバーの変更は、Webサイトの接続先を一つ書き換える作業ではありません。ドメインについて「どのDNSサーバーの回答を正しいものとして参照するか」を切り替える作業です。新しいDNS側へWeb・メール・認証用のレコードを先に揃えます。その後、ドメイン管理画面で委任先を変更します。

WebのAレコードだけを用意して切り替えると、サイトは開くのにメールが届かない状態になり得ます。変更前にDNSゾーン全体を引き継ぎ、新旧どちらのネームサーバーへ問い合わせても同じ用途が動く期間を作ることが大切です。

変更するのはDNSの回答者

DNSでは、ドメインに関する情報をゾーンという単位で管理します。RFC 1034で説明される権威ネームサーバーは、そのゾーンについて正式な回答を返す役割を持ちます。ドメインの上位側に登録されたNS情報が、どのネームサーバーへ問い合わせるかを示します。

たとえば、サーバー会社AのDNSからDNSサービスBへ変える場合、先にB側へゾーンを作っただけでは外部の参照先は変わりません。ドメインの管理画面で指定ネームサーバーをBへ変更すると、上位側の委任情報が更新されます。反対に、B側が空のまま委任だけを変えると、必要なレコードを答えられなくなります。

ドメイン登録・DNS管理・Webサーバー・メールサービスは、同じ会社が提供しているとは限りません。画面の名称ではなく、現在どのネームサーバーが権威を持つかを確認します。各レコードを必要とするサービスも整理してください。

新しいDNSゾーンを先に完成させる

切り替え前に、現在の権威ネームサーバーからレコードを取得します。管理画面のスクリーンショットだけでなく、名前・種類・値・TTLを文字として残してください。画面に表示されないレコードや、別の担当者が追加したサブドメインがある場合は、制作会社とメール管理者にも確認します。

確認対象はトップページのAレコードだけではありません。wwwなどのCNAMEとIPv6用のAAAAを含みます。メール用MXや認証用TXTも対象です。

必要に応じてCAA・SRV・サブドメインの委任も確認します。用途が分からないレコードは、不要と決めつけて削らず、値を発行したサービスを特定します。

新しいDNSへ同じ用途を再現したら、委任を変更する前に新ネームサーバーへ直接問い合わせます。example.jpを実際のドメインへ置き換え、提供元から指定されたネームサーバー名を使う場合の例は次のとおりです。

dig @ns1.example-dns.jp example.jp A
dig @ns1.example-dns.jp example.jp MX
dig @ns1.example-dns.jp example.jp TXT
dig @ns1.example-dns.jp www.example.jp CNAME

回答にaaフラグがあり、期待した値が返ることを確認します。ネームサーバーが複数指定されている場合は一台だけで済ませず、すべてへ問い合わせます。片方だけ古い状態なら、切り替え後にアクセス元によって結果が変わるためです。

TTLを下げても一斉には切り替わらない

TTLは、DNSの回答をキャッシュしてよい時間です。変更予定のレコードで事前にTTLを短くし、元のTTLが満了するまで待っておくと、値を変えた後に古い回答が残る時間を抑えられます。ただし、直前にTTLを下げても、すでに保存された回答の残り時間は消えません。

ネームサーバー変更では、ゾーン内のAやMXだけでなく、上位側のNS委任も関係します。各キャッシュの更新時刻が同じではないため、「指定時刻に全利用者が新DNSへ変わる」とは考えない方が良いです。よく使われる「反映に最大72時間」という表現も、個別環境の完了時刻を保証するものではありません。

切り替え中は、古いネームサーバーを見る利用者と新しいネームサーバーを見る利用者が共存します。そのため、新旧のDNSゾーンを同じ内容で動かし、旧DNSサービスをすぐに解約しないことが重要です。維持期間は変更前のTTLと上位側の委任情報を見て決めます。旧サービスの契約条件も確認してください。

DNSSECを利用している場合は別工程で確認する

DNSSECを有効にしているドメインは、ネームサーバー名だけを変えないでください。DNSSECでは、子ゾーンのDNSKEYと親ゾーンに置くDSレコードが信頼の連鎖を作ります。RFC 4035でも、DSは親子ゾーン間の調整が必要な情報として説明されています。

古いDSレコードが親側に残り、新DNS側の署名と一致しない状態になると、DNSSECを検証するリゾルバーは回答を正しくないものとして扱います。AやMXが新DNSへ正確に登録されていても、利用者側ではSERVFAILとなり、Webもメールも名前解決できない場合があります。

現在DNSSECを使っているか分からない場合は、ドメイン管理画面のDNSSECまたはDS設定と、現在のDSレコードを確認します。移行元と移行先が案内する鍵の引き継ぎ方法に従い、DSを更新する順番まで作業計画へ含めてください。手順が提供元ごとに異なるため、一般的なネームサーバー変更手順だけで進めない方が安全です。

変更時はWebサーバーの移転を重ねない

準備ができたら、ドメイン管理画面で指定されたネームサーバーへ変更します。この時点では、新DNS内のAレコードやWebサーバーの接続先を同時に変えません。一回の作業で委任先とWebの向き先を変えると、不具合がDNS移転とサーバー移転のどちらにあるか判断しにくくなります。

実務では次の順番で進めます。

  1. 現在のDNSレコードとDNSSECの利用状況を記録する
  2. 新DNSへゾーンを作り、すべてのネームサーバーへ直接問い合わせる
  3. 新旧の回答を揃えたまま、ドメイン管理画面でネームサーバーを変更する
  4. 権威NSとSOA、Web、メール、フォーム、外部サービス認証を確認する
  5. 旧DNSを維持し、利用状況とキャッシュ期間を見てから終了する

作業記録には変更前後のネームサーバー名と変更時刻を残します。担当者・DNSSECの処理・確認結果も記録してください。問題が起きたときにネームサーバーを元へ戻す操作も、新たな委任変更です。即時に全利用者が戻るとは限らないため、単一レコードの不足なら新DNS側を直す方が早い場合があります。

切り替え後は権威情報と業務機能を確認する

ブラウザでトップページが一度開いただけでは、ネームサーバー変更の確認になりません。外部から取得したNSとSOAが新しい提供元を示すことを確認し、A・AAAA・CNAME・MX・TXTを用途ごとに照合します。確認方法が分からないレコードは「Aレコード・CNAME・MX・TXTの違いと使い分け」で整理できます。

Webはトップページに加えてwwwの有無、代表的なサブドメイン、HTTPSを確認します。メールは外部アドレスとの送受信、問い合わせフォームは実送信まで行います。SPF・DKIM・DMARCは存在するだけでなく、新しいメール経路に合う値かをメールのヘッダーで確かめます。

新DNSの不足を修正した場合は、どのレコードをいつ追加したかを記録します。古い権威サーバーへの参照が落ち着くまで、旧DNSを維持します。必要な業務機能と旧サービスの契約終了条件を確認した後に終了してください。切り替え作業の完了日と旧DNSの解約日は、同じ日にしない方が戻しやすくなります。