セカンダリDNSの運用監視｜ゾーン転送・SOAシリアル・障害時の応答を確認する方法
セカンダリDNSを導入すると、同じドメインへ権威応答できる系統を増やせます。しかし、ネームサーバーを複数登録しただけでは、各系統が同じゾーン内容を返している保証にはなりません。ゾーン転送が止まったまま片方だけ古いレコードを返すと、利用者ごとにWeb、メール、外部SaaSの接続先が変わる不安定な障害になります。
安定運用の要点は、プライマリと各セカンダリのSOAシリアル、転送成功時刻、代表レコード、権威応答を継続して照合し、更新通知・認証・通信経路・転送方式を別々に観測することです。設定画面の「有効」や転送ジョブの成功だけで終えず、各NSを直接指定した外部照会まで確認します。
セカンダリDNSの運用が完了したと言えるのは、転送設定を保存した時ではなく、更新後のSOAシリアルと主要レコードが全権威NSでそろい、片系停止時も正しい応答を返せると確認できた時です。
本記事のポイント
- セカンダリDNSは権威応答の経路を増やしますが、プライマリの誤設定まで自動で正す仕組みではありません。
- SOAシリアル一致だけでなく、転送成功時刻、権威フラグ、主要レコード、応答遅延を各NSへ直接照会します。
- 更新直後の同期遅延と障害を分けるため、NOTIFY、ACL・TSIG、TCP 53、AXFR・IXFRの順で証拠を残します。
セカンダリDNSで冗長化できる範囲を先に決める
セカンダリDNSは、プライマリが管理するゾーンのコピーを受け取り、同じゾーンに対する権威応答を提供します。IETFのRFC 5936は、AXFRをゾーン全体の内容を転送する仕組みとして定義しています。RFC 1995のIXFRは、セカンダリが保持するSOAシリアルを起点に、変更された差分だけを受け取る方式です。IXFR用の履歴が残っていない場合や相手が対応しない場合は、全体転送へ戻ることがあります。
冗長化されるのは、主に「問い合わせへ答える権威DNSの経路」です。レジストラの管理権限、プライマリの編集画面、変更承認、誤ったレコード値、ドメイン更新期限まで自動で二重化されるわけではありません。プライマリへ誤った値を登録すれば、その誤りが速やかに全セカンダリへ複製されることもあります。ドメイン自体の管理は企業ドメインの更新期限・権限管理と分けて責任者を決めます。
また、複数のNS名が登録されていても、同じ事業者・同じ制御面・同じネットワークへ依存していれば、期待した障害分離にならない場合があります。事業者、ネットワーク、管理アカウント、請求、DNSSECの署名方式、障害連絡経路を一覧にし、「どの障害に耐えるための構成か」を明示します。単一サーバー故障を避けたいのか、DNS事業者全体の障害まで避けたいのかで必要な構成は変わります。
Cloudflareへ権威DNSを移す手順はNS切替とDNSSECを含む移行作業が主題です。セカンダリDNSの運用では、NSを移し切るのではなく、プライマリとセカンダリが継続して同じゾーンを返すことを監視します。移行作業と日常の同期監視を同じチェックリストに混ぜないことが重要です。
SOAシリアルだけに頼らず5つの証拠を照合する
監視の中心はSOAレコードのシリアルです。プライマリでゾーン内容を変えるたびにシリアルを進め、セカンダリはその値を使って更新の有無を判断します。ただし、RFC 1982が定めるSOAシリアルは32ビットの循環値です。最大値の次は0へ戻り得るため、監視ツールで通常の整数として「大きい方が新しい」とだけ判定すると、新旧を誤る可能性があります。
実務では、各NSのシリアルが一致しているかに加えて、既知の変更ID、変更時刻、転送完了時刻を結び付けます。更新を実施していない時間帯の一致だけでは、転送経路が本当に動くか分かりません。監視用の検証レコードを無断で増やすのではなく、承認されたDNS変更の直後に各系統が追随したかを記録します。
| 監視対象 | 確認方法 | 異常の判定 | 主な原因 |
|---|---|---|---|
| SOAシリアル | プライマリと全セカンダリを直接照会 | 既知の更新後、合意した転送時間を超えて不一致 | シリアル未更新、NOTIFY未達、refresh待ち、転送失敗 |
| 転送結果 | AXFR・IXFRの成功、開始・完了時刻、転送量 | 連続失敗、想定外のAXFR増加、完了時刻の欠落 | IXFR履歴不足、TCP 53遮断、相手側制限 |
| 権威応答 | 各NSへA・AAAA・MX・TXT・CAAなどを直接照会 | タイムアウト、SERVFAIL、AAフラグなし、値の差 | 片系停止、委任誤り、DNSSEC不整合、古いゾーン |
| ゾーン整合 | 許可された環境で件数・ダイジェスト・代表RRsetを比較 | シリアル一致なのに内容が異なる | 転送除外、変換、複数プライマリの不一致 |
| 外部到達性 | 複数ネットワーク・地域からUDP/TCPで照会 | 特定経路だけ遅延・欠損・応答なし | Anycast経路、ファイアウォール、到達性障害 |
SOAシリアルが一致しても、主要レコードの値、TTL、優先度、DNSSEC関連の応答が同じとは限りません。全ゾーンのAXFRを監視基盤へ常時保存すると機密性と保管負荷の問題が出るため、権限を限定した環境で件数やダイジェストを照合し、外部監視では事業影響の大きいRRsetを選びます。MX、DKIM、DMARC、CAA、外部SaaSの所有確認、主要なA・AAAA・CNAMEは、Web画面が開くだけでは発見できない差分を見つけやすい対象です。
CAAやDNSSECに起因するSERVFAILの確認は、CAAレコードと証明書発行制御の変更管理も参考になります。証明書発行エラーをCAA値だけの問題と決めつけず、全権威NSの応答差と署名検証まで確認します。
7ステップでゾーン転送と監視を組み立てる
- ゾーンと責任範囲を台帳化する。ゾーン名、レジストラ、プライマリ、セカンダリ、NS名、管理アカウント、連絡先、DNSSEC方式、障害時の判断者を記録します。セカンダリが単なる同一事業者内の別ノードか、別事業者かも明示します。
- 転送元と認証条件を固定する。転送先IP、port、AXFR・IXFRの利用方針、ACL、TSIG名・アルゴリズム、秘密情報の保管場所をそろえます。RFC 8945のTSIGは共有秘密を使うDNS取引の認証・完全性確認であり、秘密値自体を作業票や通常ログへ貼り付けません。
- 初回転送前の基準値を保存する。プライマリのSOA、NS、レコード件数、主要RRset、DNSSEC状態を記録します。全体転送を許可された管理経路から実行し、転送されたゾーンの先頭・末尾、件数、代表レコードを確認します。
- 初回AXFRを委任前に完了させる。Cloudflareの公式手順も、初回AXFR完了前にセカンダリNSへ委任すると、空の応答や否定応答がキャッシュされる可能性を注意しています。各セカンダリへ直接問い合わせ、期待するA、MX、TXTなどが返るまでレジストラのNSを追加しません。
- NOTIFYと定期確認を両方使う。RFC 1996のNOTIFYは、プライマリが変更を知らせ、セカンダリに新しいデータの照会を促す仕組みです。NOTIFY自体がゾーン内容を書き換えるわけではありません。通知未達に備え、SOAの定期確認やサービス固有のrefresh設定も有効にします。
- 承認済みの変更で追随を試験する。プライマリでレコードを変更し、SOAシリアル、NOTIFY、IXFRまたはAXFR、各NSの応答がどの時刻にそろったかを記録します。IXFRが失敗してAXFRへ戻った場合は、公開自体の成否と転送量・負荷の問題を分けて評価します。
- 片系停止と復旧を訓練する。プライマリへの転送経路停止、セカンダリ1系統の応答停止、TSIG不一致、更新シリアルの停滞を安全な検証環境で再現します。誰が委任を変更し、どの条件で旧構成へ戻し、復旧後に全NSの内容を再同期するかまで確認します。
Cloudflareをセカンダリとして使う場合、公式手順ではプライマリ側で転送元IP・port、ACL、NOTIFY送信先を許可し、Cloudflare側でpeer、TSIG、AXFR・IXFR、zone refreshを設定します。サービスによってSOAのREFRESH値をそのまま使わず、管理画面側の間隔を使うこともあるため、一般的なDNS仕様と利用事業者の実装条件を分けて作業票に残します。
監視間隔と通知閾値は、全ゾーンへ一律の分数を設定するより、「既知の変更から転送完了までのSLO」「SOAのrefresh・expire」「事業影響」で決めます。更新頻度が低いゾーンでも、月に一度の定期変更試験か、事業者が提供する転送失敗通知を使い、長期間まったく動作確認されない経路を残しません。
シリアル不一致と片系障害を順番に切り分ける
障害対応では、公開リゾルバーの回答だけを比べると、権威DNSの不整合とキャッシュ差を混同します。まず委任されているNS一覧を確認し、各権威NSを直接指定してSOAと代表レコードを照会します。権威側がそろっているのに公開リゾルバーだけ古い場合はTTLとキャッシュを確認し、権威側で差がある場合は転送経路へ進みます。
| 観測した症状 | 最初に見る証拠 | 次の確認 | 復旧の考え方 |
|---|---|---|---|
| セカンダリだけシリアルが古い | プライマリでのシリアル更新、最終転送時刻 | NOTIFY、refresh、ACL、TSIG、TCP 53 | 原因を直して再転送し、全NSを再照合 |
| シリアルは同じだが値が違う | 同じFQDN・type・classのRRset | 転送除外、プロバイダー変換、複数転送元 | 正本を一つに定め、内容を再同期 |
| IXFRだけ失敗する | IXFR履歴、要求した旧シリアル、応答 | AXFRへのフォールバック、転送量、負荷 | 公開継続と効率低下を分け、履歴保持を調整 |
| 一部NSがタイムアウトする | UDP/TCP 53、地域・ネットワーク別到達性 | 事業者障害、経路、ファイアウォール | 正常系を維持しつつ、障害NSの復旧または委任見直し |
| SERVFAILが混在する | DNSSEC検証、DNSKEY・DS・RRSIG | 署名方式、期限、親子のDS、全NSの応答 | 検証可能な署名状態へ戻し、キャッシュ後も再確認 |
| 転送が認証エラーになる | TSIG名、アルゴリズム、時刻、peer設定 | 秘密の世代、ACL、転送元IP | 双方を同じ世代へそろえ、秘密値を再配布せずローテーション |
切り分け中に公開ゾーンの値を何度も書き換えると、シリアルが進み、IXFR履歴とキャッシュが増えて原因を追いにくくなります。観測した時刻、問い合わせ先NS、query type、response code、AAフラグ、シリアル、応答値を保存し、一つずつ原因を除きます。Webアクセス障害が同時に起きている場合も、DNS応答が正しいことを確認してからCDN・オリジンへ進みます。Cloudflare利用時のアプリ層エラーは520・522・524・525・526の切り分けと分離すると、DNS調査を引き延ばしにくくなります。
復旧判定は「転送コマンドが成功した」ではなく、全権威NSのSOAと主要RRsetが一致し、複数の外部経路から正しい権威応答を得られ、次の承認済み更新でも追随した状態とします。障害期間中に誤った値がキャッシュされた場合は、TTLが切れるまでの影響も利用部門へ共有します。
よくある質問
セカンダリDNSは何を冗長化しますか？
同じゾーンへ権威応答できるDNSサーバーや事業者を増やし、片方が停止しても別系統が応答できる状態を作ります。ゾーン内容の作成元やレジストラ、変更承認まで自動で冗長化するわけではありません。
ゾーン転送が成功したことをどう確認しますか？
転送ジョブの成功だけでなく、プライマリと各セカンダリのSOAシリアル、代表的なA・AAAA・MX・TXT・CAA、レコード件数やダイジェスト、権威フラグを照合します。
SOAシリアルの不一致をどう検知しますか？
各権威NSを直接指定してSOAを定期照会し、既知の更新後も合意した転送時間内に一致しない状態を通知します。32ビットの循環値なので、単純な大小比較だけで新旧を決めません。
片系障害や転送停止が起きたらどう切り分けますか？
権威応答の可否、SOAシリアル、NOTIFY到達、ACL・TSIG、TCP 53、IXFR履歴、AXFRフォールバックを順に確認し、公開リゾルバーのキャッシュ差と権威側の不整合を分けます。
AXFRとIXFRはどちらを使えばよいですか？
通常更新は差分だけを送るIXFRが効率的ですが、履歴不足や非対応時にAXFRへ戻る設計が一般的です。どちらか一方の成功だけでなく、想定したフォールバックと転送量を監視します。
TSIGを設定すればIP許可リストは不要ですか？
役割が異なるため併用します。IP・ポートの制限で転送元と到達経路を絞り、TSIGでDNS取引の認証と完全性を確認します。秘密値は監視ログや台帳へ直接残しません。
