NSレコードとTXTレコードを併用する設定｜NSに複数のDNSサービスが並ぶときTXTをそろえる方法

NSレコードに複数のDNSサービスのネームサーバーが並んでいるときは、すべてのサービスに同じTXTレコードを登録しておく必要があります。キャッシュDNSはNSのどれか1つに問い合わせるため、片方にしかないTXTは「見えたり見えなかったり」する状態になり、SPFや所有権確認、証明書のDNS認証が不定期に失敗します。この記事では、複数サービスにまたがるNSの状態を確認する方法、意図しない混在の直し方、冗長化のために複数のDNSサービスを使う場合のTXTのそろえ方を説明します。

1つのDNSサービスだけを使っている場合に、どの管理画面にTXTを書けばよいかを確かめる手順は、別の記事で扱っています。ここでは「NSの先が2つ以上のサービスに分かれている」状態に絞ります。

キャッシュDNSはNSのどれに聞くのか

example.com のNSが4つあると、キャッシュDNSはその中から1つを選んで問い合わせます。選び方は実装によって異なり、応答の速さなどを基準にすることが多く、NSの並び順どおりとは限りません。また、答えはTTLの間キャッシュされるので、利用者が使うキャッシュDNSごとに、違うネームサーバーから得た答えを覚えていることになります。

このため、NSの一部のサービスにだけTXTがある状態では、次のようなことが起こります。

• ある受信サーバーではSPFが通り、別の受信サーバーでは通らない
• 所有権の確認が、何度か試すと通ったり通らなかったりする
• 自分の環境で dig すると見えるのに、外部の検査ツールでは見えない

症状が不定期なほど、NSの先がそろっていない可能性を疑う価値があります。

まず状態を確かめる

NSを一覧し、それぞれに再帰なしで直接TXTを聞きます。サービスをまたいで同じ答えが返るかを比べるのが目的です。

for ns in $(dig +short NS example.com); do
  echo "== $ns"
  dig @"$ns" +norecurse +short example.com TXT | sort
  dig @"$ns" +norecurse +short _dmarc.example.com TXT | sort
done

DKIMの公開鍵（セレクター._domainkey.example.com）や、_acme-challenge.example.com など、TXTを使っている名前があればループに加えます。DNSには「ゾーン内のレコードを全部見せて」という問い合わせを一般には許していないため、調べる名前は自分で把握している必要があります。各サービスの管理画面からレコードの一覧やエクスポートを取り、名前の一覧を作っておくと確認が楽になります。

あわせてSOAも見ておきます。

for ns in $(dig +short NS example.com); do
  echo "== $ns"
  dig @"$ns" +norecurse +short example.com SOA
done

同じサービスのネームサーバー同士でシリアル番号が違えば、そのサービス内での反映が遅れています。別々のサービス同士では、シリアル番号の付け方が違うのが普通なので、シリアルではなくレコードの中身を比べます。

意図しない混在を直す

DNSサービスを移行している途中で、レジストラのNSを一部だけ書き換えた、あるいは以前のサービスのNSを消し忘れた、という理由で混在していることがあります。冗長化の意図が無いなら、1つのサービスに統一するのが確実な直し方です。

1. 使い続けるサービスを決め、もう一方にしかないレコードを洗い出して登録する
2. 使い続けるサービスのネームサーバーに直接問い合わせ、TXTを含む主要なレコードがそろっているかを確かめる
3. レジストラの画面で、NSを使い続けるサービスのものだけにする
4. 以前のサービスのゾーンは、すぐには消さずに残しておく

4は、TLDに登録されたNSの情報自体にもTTLがあり、多くのTLDで1〜2日程度に設定されているためです。その間は古いNSを覚えたキャッシュDNSが以前のサービスに問い合わせるので、以前の側も同じ内容で応答できるようにしておきます。作業の前には、両方のサービスのレコードをエクスポートなどで控えておきます。

冗長化のために複数のDNSサービスを使う場合

あるDNSサービスが障害で応答できなくなっても名前解決を続けられるよう、意図して2つのサービスをNSに並べる構成があります。この場合は、TXTを含むすべてのレコードを、両方のサービスで同じ内容に保つ仕組みが必要です。代表的な方法は2つです。

プライマリとセカンダリ（ゾーン転送）

一方をプライマリ、もう一方をセカンダリとし、ゾーン転送（AXFR・IXFR）でプライマリの内容をセカンダリへ写す方法です。TXTはふつうのレコードなので、プライマリで追加すれば自動で写ります。編集する場所が1か所で済むのが利点です。

注意点は、ALIASやCNAMEフラット化のような事業者独自の機能は、標準のゾーン転送で他社へ正しく渡らないことがある点と、マネージドDNSによってはセカンダリとしての利用やゾーン転送に対応していない点です。対応状況は各社の資料で確認します（2026年10月現在、対応範囲はサービスやプランによって異なります）。

両方をプライマリとして、同じ内容を書き込む

両方のサービスに、APIを通して同じレコードを書き込む方法です。手作業で2つの画面を更新するのは書き漏らしの元になるため、octoDNS や DNSControl のように、1つの定義ファイルから複数のDNSサービスへ反映するツールや、Terraform のような構成管理の仕組みを使うのが一般的です。定義ファイルをGitなどで管理しておけば、いつ誰がTXTを変えたかも追えます。

DNSSECを有効にしている場合、複数のサービスで署名をそろえるのは別の難しさがあります（複数署名者の方式は RFC 8901 にまとめられています）。DNSSECと複数のDNSサービスを組み合わせるかどうかは、各サービスの対応を確認してから決めます。

自動で書き込まれるTXTに注意する

手で追加するTXTより問題になりやすいのが、ツールが自動で書き込むTXTです。

代表例が Let's Encrypt などのACMEによるDNS認証（DNS-01）です。certbot のDNSプラグインなどは、多くの場合1つのDNSサービスのAPIにしか書き込みません。認証局は権威サーバーに問い合わせて検証するため、TXTが無い側のネームサーバーに当たると検証に失敗します。対策には次のような方法があります。

• _acme-challenge.example.com をCNAMEで、1つのサービスだけで管理する別の名前に向け、TXTはそこに書き込む
• 両方のサービスに書き込めるツールを使い、両方の権威サーバーで見えるまで待ってから検証させる

Google Search Console などの所有権確認用のTXTや、メール配信サービスを追加したときのSPF・DKIMも、片方にだけ登録しがちです。手順書に「すべてのDNSサービスに登録する」と書いておくと漏れを防げます。

WordPress運用での見落としやすい点

WordPressサイトでは、レンタルサーバーのDNSと外部のDNSサービスを併用しているうちに、気づかず混在していることがあります。サーバー移転のあとにメールの到達が不安定になった、SSL証明書の自動更新がときどき失敗する、といった場合は、前述のループでNSの先がそろっているかを確認すると、原因の切り分けが早くなります。

まとめ

• NSに複数のDNSサービスが並ぶと、キャッシュDNSはそのどれかに問い合わせる。TXTはすべてのサービスにそろえる
• 各NSに +norecurse で直接問い合わせ、TXTの中身を比べる。別サービス同士のシリアル番号は比べても意味がない
• 意図しない混在は1つのサービスに統一し、以前のゾーンはNSのTTLが過ぎるまで残す
• 冗長化するなら、ゾーン転送か、定義ファイルから両方へ反映するツールで同期する
• ACMEのDNS認証など、自動で書き込まれるTXTが片方にしか載らない点に注意する

• DNSフェイルオーバーでWebサイトを冗長化する構成と設定手順
• digコマンドでDNSレコードを調査する方法