NSレコードの「重複」は、多くの場合、ネームサーバーの移行が途中で止まり、旧DNSと新DNSの両方がドメインの担当として登録されている状態です。この状態では、問い合わせのたびにどちらのDNSが答えるかが変わり、サイトが表示されたりされなかったり、SSL証明書の発行やメールの受信が不安定になったりします。この記事では、レジストリ側（親）とゾーン側（子）のNSを dig で読み比べて重複の場所を特定し、1つのDNSにそろえるまでの手順を説明します。
ネームサーバー変更そのものの段取りや、NSの反映待ちの見分け方は別の記事で扱っているため、ここでは「すでに混ざってしまったNSを調べて直す」ことに絞ります。
NSの重複とはどういう状態か
ドメインのNSは、2か所に登録されています。
- 親（レジストリ）側:
.comや.jpのサーバーが持っている委任情報です。レジストラ（お名前.com などのドメイン登録サービス）の管理画面で「ネームサーバー」として設定した値がここに入ります。 - 子（ゾーン）側: 自分のDNSサービスのゾーンの頂点（
example.comそのもの）にあるNSレコードです。
本来はこの2つが同じDNSサービスを指し、内容も一致しているのが正常です。重複として問題になるのは、主に次のパターンです。
- 親側に旧DNSと新DNSが並んでいる: 例として、レジストラで新しいDNSの2台を追加したが、古い2台を消し忘れて4台が登録されている状態です。
- 子側のNSに旧DNSが残っている: 親は新DNSだけを指しているが、新DNSのゾーンに旧DNSのNSレコードが残っている状態です。
- 親と子で内容が食い違う: 親は新DNS、旧DNSのゾーンは旧DNS自身を名乗っている、といった状態です。
- サブドメインの委任が二重になっている:
shop.example.comを別のDNSに委任しているのに、親ゾーン側にも同じ名前のAレコードなどが残っている状態です。
キャッシュDNSは、登録されたNSの中から1台を選んで問い合わせます。旧DNSと新DNSでレコードの内容が違えば、どれを選んだかによって答えが変わります。これが「ときどき古いサーバーが表示される」症状の正体です。
なお、2つのDNSサービスを意図的に併用する構成（セカンダリDNSやマルチプロバイダー構成）もあります。その場合は、ゾーン転送やAPIで両方の内容を常に同期させていることが前提です。同期の仕組みを用意していないなら、混在は解消する対象と考えます。
調査1: 親側のNSを確認する
まず、レジストリが実際にどのNSを委任しているかを確認します。キャッシュDNSを通すと古い答えが混ざるため、TLDのサーバーに直接問い合わせます。
# TLDの権威サーバーを調べる（.jp なら jp. NS）
dig com. NS +short
# 表示されたうちの1台に、再帰なしで問い合わせる
dig @a.gtld-servers.net example.com NS +norecTLDのサーバーは、委任先を ANSWER ではなく AUTHORITY セクションに表示します。ここに並んだネームサーバーが、親側に登録されている一覧です。ルートから順にたどる dig +trace example.com NS でも、途中の .com サーバーの応答として同じ情報が見えます。
レジストラの管理画面に表示されている値と、この結果が一致しているかも確かめます。管理画面で変更しても、レジストリへの反映に時間がかかったり、変更の申請が完了していなかったりすることがあります。whois example.com の出力にあるネームサーバーの項目も参考になりますが、表示形式はTLDごとに異なります。
調査2: 子側のNSを確認する
次に、親側に並んでいる各ネームサーバーに、それぞれ「このドメインのNSは何か」を直接尋ねます。
# 親側に登録されている各NSに直接問い合わせる
dig @ns1.new-dns.example example.com NS +norec +short
dig @ns1.old-dns.example example.com NS +norec +short応答に aa（権威ある応答）フラグが付いているか、status: REFUSED になっていないかも見ます。REFUSED や SERVFAIL が返るネームサーバーは、そのドメインのゾーンを持っていない可能性が高く、親側の登録だけが残っている状態（いわゆる委任の不備、lame delegation）です。
調査3: 全ネームサーバーの中身を比べる
重複の影響が出ているかどうかは、各ネームサーバーが返す内容を比べると分かります。+nssearch は、親側に登録された全NSのSOAを一度に表示します。
dig +nssearch example.com各行のSOAシリアル番号がそろっていれば、同じゾーンを配っている可能性が高いと言えます。シリアルが違う、あるいは一部のNSだけ応答しない場合は、内容がずれています。
主要なレコードも、ネームサーバーごとに比べておきます。
#!/bin/bash
# 親側に登録された各NSに対して、主要レコードを並べて表示する
domain="example.com"
for ns in $(dig @a.gtld-servers.net "$domain" NS +norec | awk '$4 == "NS" {print $5}' | sort -u); do
echo "== $ns"
for type in A AAAA MX TXT; do
echo "$type: $(dig @"$ns" "$domain" "$type" +norec +short | tr '\n' ' ')"
done
done.jp などほかのTLDの場合は、a.gtld-servers.net を調査1で調べたTLDのサーバーに置き換えてください。Aレコードが旧サーバーと新サーバーで違う、MXやTXT（SPF・DKIM・DMARC）が片方にしかない、といった差が見つかれば、それが症状の原因です。
解消手順
調査結果をもとに、1つのDNSサービスにそろえます。作業の前に、旧DNS・新DNSそれぞれのゾーンの内容を画面のスクリーンショットやエクスポート機能で保存しておくと、戻す必要が出たときに困りません。
1. 残すDNSを決め、ゾーンの内容を完成させる
親側の登録と実際の運用状況から、今後使うDNSを1つに決めます。そのDNSのゾーンに、旧DNSにしかなかったレコードを移します。見落としやすいのは、メール関係のTXTレコード、Google Search Console などの所有権確認用TXT、CAAレコード、サブドメインのCNAMEです。
2. DNSSECを使っているか確認する
親側にDSレコードが登録されている場合、残すDNSのゾーンがその鍵で署名されていないと、検証を行うキャッシュDNSでは名前解決に失敗します。
dig example.com DS +shortDSが返る場合は、残すDNSで署名を有効にしてDSを差し替えるか、いったんDSを外してから切り替えるかを先に決めます。手順はDNSサービスとレジストラのドキュメントに従ってください。
3. レジストラで親側のNSを整理する
レジストラの管理画面で、ネームサーバーを残すDNSの値だけにします。旧DNSのネームサーバーを削除し、新DNSのネームサーバーを過不足なく入力します。Cloudflare のように、ドメインごとに割り当てられたネームサーバー名を指定する方式のサービスでは、表示された値をそのまま使います。
ns1.example.com のように自分のドメイン内の名前をネームサーバーにしている場合は、そのIPアドレス（グルーレコード）もレジストラ側で登録・更新が必要になります。
4. 子側のNSレコードをそろえる
残すDNSのゾーンにある頂点のNSレコードが、親側と同じ一覧になっているかを確かめ、旧DNSのNSが残っていれば削除します。多くのDNSサービスでは頂点のNSは自動で管理され、編集できないようになっています。その場合は表示内容の確認だけで構いません。
5. 旧DNSのゾーンはすぐに消さない
親側のNSレコードにもTTLがあり、キャッシュDNSは古い委任情報をしばらく覚えています。TTLの値はTLDによって異なり、.com では48時間の値がよく見られます。この間は旧DNSに問い合わせが届く可能性があるため、旧DNSのゾーンは残しておき、内容も新DNSと同じにそろえておくと安全です。調査1の結果のTTLを見て、待つ期間の目安にしてください。
解消できたかの確認
親側の待ち時間が過ぎたら、調査1〜3をもう一度行います。
- 親側のNSが、残すDNSのものだけになっている
- 各NSが
aaフラグ付きで応答し、REFUSED を返すものがない dig +nssearchのSOAシリアルがそろっている- 公開DNS（
dig @8.8.8.8やdig @1.1.1.1）経由でも新しい値が返る
ここまで確認できたら、旧DNSのゾーンを削除し、旧DNSサービスの契約を整理します。WordPress側では、サイトの表示、管理画面へのログイン、問い合わせフォームのメール送受信、SSL証明書の自動更新が問題なく動いているかを確かめておきます。DNSサービスの画面構成や自動管理の範囲はサービスによって変わるため、操作に迷ったら各サービスのドキュメントを確認してください（2026年10月現在）。
まとめ
- NSの重複は、旧DNSと新DNSが親側・子側のどこかで混在している状態で、答えが問い合わせごとに変わる原因になります。
- 親側はTLDのサーバーに
+norecで直接尋ね、AUTHORITY セクションを読みます。 - 子側は各NSに直接尋ね、
aaフラグ・REFUSED の有無・SOAシリアル・主要レコードを比べます。 - 解消は、残すDNSのゾーンを完成させ、DNSSECを確認してから、親側と子側のNSを同じ一覧にそろえます。
- 旧DNSのゾーンは、親側のTTLが切れるまで残しておきます。