ネームサーバー（NS）を変更した後に反映されないときは、「親ゾーン（.com や .jp）のNSが新しくなっているか」「新しいネームサーバーがゾーンを持っているか」「キャッシュの残り時間はどれだけか」の3点を順に確かめると、待てば直る状態なのか、手を入れるべき設定ミスなのかを見分けられます。この記事では、反映待ちの間に行う確認を、コマンドと読み方つきで説明します。
NSの変更は「親」と「キャッシュ」の2段階で伝わる
ネームサーバーの変更は、レジストラ（ドメインを買ったサービス）の管理画面で行います。レジストラはこの情報をレジストリ（TLDの管理者）に送り、TLDのネームサーバーが返すNS（委任情報）が書き換わります。ここまでが1段階目で、多くの場合は短時間で済みますが、TLDや事業者によって差があります。
2段階目はキャッシュです。プロバイダーや公開DNSなどのキャッシュDNSは、以前に受け取った古いNSを、そのTTLの間は使い続けます。TLDが返すNSのTTLは長めに設定されていることが多く（例えば .com は2日に当たる172800秒が一般的です）、変更から最大でその時間ほど、古いネームサーバーに問い合わせる利用者が残ります。
このため、反映待ちの確認は「1段階目が終わっているか」から始めます。
確認1: 親ゾーンのNSが新しくなっているか
TLDのネームサーバーに直接問い合わせると、キャッシュの影響を受けずに現在の委任情報が見えます。
# .com の場合（.jp なら a.dns.jp など）
dig @a.gtld-servers.net example.com NS +norec
# ルートから順にたどって確かめる
dig example.com NS +trace+norec の結果の AUTHORITY SECTION に、新しいネームサーバー名が並んでいれば1段階目は完了です。古いままなら、まだレジストリに届いていないか、変更が受け付けられていません。WHOIS（whois example.com）やレジストラの管理画面でも、登録されているネームサーバーを確かめます。
古いままの場合に考えられる原因は、可能性の高い順に次のとおりです。
- レジストラでの変更が保存されていない、または処理待ち: 管理画面で状態を確認する。メールでの承認が必要な事業者もある
- ネームサーバー名の入力ミス: 綴りや末尾の違いを、DNSサービスが指定した名前と1文字ずつ照合する
- ドメインのロックや契約状態: 更新ロックや支払いの未処理、登録者情報の確認待ちで変更が止まることがある。レジストラのサポートに問い合わせる
確認2: 新しいネームサーバーがゾーンを持っているか
親のNSが新しくなっても、新しいネームサーバー側にゾーンが無い、またはレコードが足りないと、サイトは引けません。新しいネームサーバーに直接問い合わせます。
dig @ns1.new-dns.example example.com SOA
dig @ns1.new-dns.example example.com A +noall +answer
dig @ns1.new-dns.example example.com MX +noall +answer応答のヘッダーの flags に aa（権威ある応答）が付き、SOAとレコードが返れば正常です。REFUSED や SERVFAIL が返る場合は、DNSサービス側でゾーンが作られていないか、有効化の手続きが終わっていません。DNSサービスによっては、親のNSが向いたことを確認してからゾーンを有効にするものもあり、その間は待つしかありません。
新しいゾーン自身のNSレコードも確かめます。古いネームサーバー名が残っていると、子側のNSを優先するキャッシュDNSでは、古いサーバーに問い合わせ続けることがあります。
dig @ns1.new-dns.example example.com NS +noall +answer確認3: DNSSECのDSが残っていないか
ネームサーバーを移す前にDNSSECを有効にしていた場合、親に登録したDSが古い鍵のまま残っていると、検証するキャッシュDNSではSERVFAILになります。これは待っても直りません。
dig example.com DS +short
dig @8.8.8.8 example.com A # SERVFAIL になるか
dig @8.8.8.8 example.com A +cd # 検証を外すと引けるか+cd を付けると引けて、付けないとSERVFAILになるなら、DSと新しいDNSの鍵が合っていません。レジストラでDSを削除するか、新しいDNSサービスの鍵に合わせて登録し直します。
確認4: 残りは待ち時間か
確認1〜3に問題が無ければ、残りはキャッシュの待ち時間です。公開DNSでNSを引くと、TTLの列に残り秒数が表示されます。
dig @8.8.8.8 example.com NS +noall +answer
dig @1.1.1.1 example.com NS +noall +answer待ち時間の上限は、TLDが返すNSのTTLと、旧DNSのゾーンに書かれていたNSのTTLの長いほうを目安に見積もります。どちらも dig の結果のTTL列で分かるので、変更した時刻から数えて「いつまでに古い答えが消えるはずか」を書き留めておくと、その時刻を過ぎても古い答えが返る場合に、待ち時間ではなく別の原因を疑う判断ができます。
公開DNSによって新旧の答えが混ざるのは、この段階では普通のことです。自分のパソコンだけ古い場合は、OSやブラウザのキャッシュを消すと、早く新しい答えに切り替わることがあります。携帯回線など別の経路から見るのも、判断の助けになります。
反映待ちの間にやってはいけないこと
- 旧DNSのゾーンを消す: 古いNSを持つキャッシュDNSは、しばらく旧DNSに問い合わせる。TLDのNSのTTLが切れるまで、旧DNSに同じ内容のレコードを残しておく
- 待ちきれずにNSを何度も変更する: そのたびにキャッシュの状態が混ざり、切り分けが難しくなる
- 新旧のDNSで違うレコードを編集する: 移行中にレコードを変える必要があれば、両方に同じ変更を入れる
WordPressサイトの移転を兼ねている場合は、旧サーバーも反映が終わるまで動かしておきます。旧サーバーに届いたコメントや注文が、移行後に失われないようにするためです。期間の目安や画面の表記は事業者ごとに異なり、変わることもあります（2026年10月現在）。
まとめ
- まず
dig @TLDのネームサーバー +norecで、親ゾーンのNSが新しくなっているかを確かめる - 次に新しいネームサーバーに直接問い合わせ、
aa付きでゾーンが返るかを見る - DNSSECを使っていたなら、DSと鍵の不一致を
+cdの有無で確かめる。これは待っても直らない - ここまで問題が無ければ残りはキャッシュの待ち時間。旧DNSと旧サーバーは残しておく