DNSSECのDSレコード更新監視｜鍵ロールオーバー時の検証失敗を防ぐ確認手順
DNSSECを有効にしたドメインで鍵を更新した後、一部の利用者だけがWebサイトやメールへ接続できなくなることがあります。権威DNSでは正しいIPアドレスを返していても、親ゾーンに登録されたDSと子ゾーンの鍵・署名がつながらなければ、検証するリゾルバーが応答を拒否するためです。
この確認は、DNS事業者を変えず、同じ委任関係のまま鍵を更新する企業ドメインが対象です。NSを変更する移行は、権威DNSの移行手順として別に計画します。DNSSECの鍵更新と、WebサーバーのTLS証明書更新も別の作業です。
DNSSECの鍵更新では、親ゾーンのDS、子ゾーンのDNSKEYと署名、検証リゾルバーの結果を同じ時刻帯で記録し、事業者が指定する重複期間とキャッシュの失効条件を満たしてから次へ進みます。管理画面の保存完了だけでは、親への反映や利用者側の検証成功まで確認できません。
本記事のポイント
- DS・DNSKEY・署名と通常の検証結果を照合し、管理画面の保存だけで鍵更新の完了を判断しません。
- KSKとZSK、更新方式、親DSと子のTTLを分け、変更前のキャッシュ保持時間を含む待機条件を守ります。
- 不一致では後続の削除を止め、CD付きの診断結果と通常照会での復旧成功を区別して証拠を残します。
1. DS・DNSKEY・署名のどの関係を確認するか
DNSSECはDNSの応答に電子署名を付け、応答の真正性と完全性を検証できるようにする仕組みです。DNS通信を暗号化する機能や、Webサイトの内容を保証する仕組みではありません。企業ドメインの運用では、ルートから親ゾーンを経て子ゾーンへ続く信頼の連鎖を保つことが重要です。
子ゾーンのDNSKEYには公開鍵が入り、親ゾーンのDSにはその鍵を参照する情報が入ります。DSの照合では、鍵タグ、アルゴリズム、ダイジェスト種別、ダイジェストを確認します。RFC 4034のDS仕様では、ダイジェストの計算に所有者名とDNSKEYのデータを使います。鍵タグが同じという理由だけで一致と判定せず、DNS事業者が提示する完全なDS値を照合してください。
また、DSと鍵が対応していても、DNSKEYの集合や目的のレコード集合に対する署名が検証できなければ不十分です。署名レコードであるRRSIGの有効期間、署名対象、署名鍵の対応も確認します。DNSKEYの表示だけを見て「DNSSECは正常」と判断すると、署名の期限切れや一部サーバーへの反映漏れを見落とします。
| 確認する場所 | 取得する証拠 | 次の作業へ進む条件 |
|---|---|---|
| 親ゾーンの権威DNS | DSの完全な値、応答元、TTL、取得時刻 | 計画したDSの状態が親のすべての権威サーバーで確認できる |
| 子ゾーンの権威DNS | DNSKEY、DNSKEYに対するRRSIG、必要な署名済みレコード、TTL | 計画した鍵・署名が揃い、更新方式で必要な旧鍵も保持されている |
| 検証リゾルバー | 通常問い合わせの応答コード、検証結果、問い合わせ名・種類 | 予定した信頼の連鎖を検証でき、重要な名前の解決が成功する |
| 運用記録 | 方式、反映開始・完了時刻、待機期限、承認者、戻す条件 | キャッシュと署名の条件を満たし、担当者が次段階を承認している |
鍵には、通常のレコード集合を署名するZSKと、DNSKEYの集合を署名するKSKという役割分担があります。KSKの更新では親のDSとの調整が必要です。一方、ZSKの更新を毎回DS変更と結び付ける必要はありません。単一の鍵で両方を担う方式もあるため、名前だけで判断せず、現行の署名方式と事業者の手順を確認します。
2. 更新前に担当範囲・待機時間・停止条件を決める
最初に、DNS事業者が管理する範囲と、レジストラを通じて利用者が更新する範囲を分けます。鍵や署名の自動更新に対応していても、親のDS登録まで同じ事業者が自動処理するとは限りません。申請が必要な場合は、担当者、認証権限、受付時間、反映の確認方法まで決めておきます。
2026年10月3日時点のCloud DNSの鍵管理ガイドは、ZSKの自動ローテーションに対応する一方、KSKの自動ローテーションには対応せず、レジストラとの手動の調整が必要と説明しています。Cloudflareの鍵・検証ガイドは、CDSとCDNSKEYの自動公開を説明していますが、レジストラが自動走査に対応しない場合はDSの手動登録が必要としています。「DNSSECが自動管理される」という説明だけで、自社の親DSも自動更新されると判断しないことが重要です。
RFC 6781のKSKロールオーバーには、二重署名と二重DSなど複数の方式があります。同じ鍵更新でも、親と子の変更順序や重複させる対象が異なります。複数の手順から都合のよい部分だけを組み合わせず、自社の事業者が採用する方式に対応した計画を一つ作ります。
例えばRFC 6781の二重署名によるKSK更新では、子に新しい鍵と署名を用意し、子のすべての権威サーバーへの公開と、更新方式が指定するDNSKEYキャッシュの待機条件を満たした後に親のDSを変更します。新しいDSが新鍵を参照しても、リゾルバーに新鍵が含まれない古いDNSKEY集合が残れば検証に失敗するためです。新しいDSが親のすべての権威サーバーで公開された後、古いDSのTTL以上の時間を待って、遠隔のキャッシュに残る旧DSを考慮してから旧鍵を取り除きます。これは特定方式の例であり、全事業者に共通する削除手順ではありません。
待機時間を決める際は、変更前に取得したTTLを残してください。変更した後で短くしたTTLだけを見ても、以前の長いTTLで保存されたキャッシュは直ちには消えません。DSのTTLは親側の運用で決まり、子のAレコードのTTLを下げただけではDSの失効条件は変わりません。新鍵・DNSKEYの伝播条件、DSの反映、旧鍵の保持条件を別々に記録します。
TTLは相対的なキャッシュ保持時間ですが、RRSIGの期限は絶対時刻です。時刻ずれや署名期限も検証に影響するため、監視の取得時刻をUTCなどの共通基準に揃えます。Cloud DNSのDNSSEC設定ガイドでも、この違いを説明し、DNSSECを有効にしたゾーンでは259,200秒（3日）を超えるTTLを避けるよう案内しています。さらに最小署名有効期間を超えるTTLは使わないとしています。この数値はCloud DNSの推奨であり、他の事業者に一律適用せず、自社の事業者の現行仕様に従ってください。
- 対象ドメイン、親・子の権威サーバー、重要な問い合わせ名と種類を固定する。
- 現行方式、新旧鍵の識別情報、DSの登録経路と操作担当を確認する。
- 変更前のDS・DNSKEY・署名・TTLと通常の検証結果を保存する。
- 親の全権威サーバーへの反映確認と、キャッシュの待機期限を計画する。
- 検証失敗、サーバー間の不一致、予定外の鍵消失を停止条件にする。
- 復旧時に保持・再公開できる鍵と署名、事業者への連絡経路を確認する。
自動更新でDSが変わらない期間がある場合も、何も記録しなくてよいわけではありません。変更予定の有無、事業者側で完結する範囲、利用者側の必要操作を確認し、通知が来た時点で判断できるようにします。権威サーバー間の状態確認は、セカンダリDNSの運用監視とも組み合わせられます。
3. 親・子・検証リゾルバーを別々に照会する
監視は管理画面、権威DNSへの直接照会、検証リゾルバー経由の照会を分けます。管理画面は依頼内容、直接照会は現在配信している内容、リゾルバー経由はキャッシュを含む利用者側の状態を見る証拠です。一つだけで他の二つを代用しないでください。
図の三つは照合する観測点であり、鍵更新の操作順ではありません。親のDSについて登録内容とTTL、子のDNSKEYについて鍵・署名とTTL、検証リゾルバーについて応答と検証結果を記録します。整合が確認できれば計画した次の段階へ進み、不一致なら後続操作を止めます。
次はBIND系のdigで使う、読み取り専用の照会例です。ドメインとサーバー名は説明用です。実際には現在の委任を確認し、親の権威サーバーと子の権威サーバーをそれぞれ指定してください。子側のDS照会だけでは、親へ登録されたDSの確認になりません。
# 親ゾーンの各権威サーバーへ、委任先ドメインのDSを照会
dig @PARENT_AUTH_NS example.com DS +dnssec +norecurse
# 子ゾーンの各権威サーバーへ、DNSKEYとその署名を照会
dig @CHILD_AUTH_NS example.com DNSKEY +dnssec +norecurse
# 検証リゾルバーで、重要な名前を通常照会
dig @VALIDATING_RESOLVER www.example.com A +dnssec +adflag
dig @VALIDATING_RESOLVER example.com MX +dnssec +adflag
# 同じ名前・種類をCD付きで照会し、失敗原因の切り分けに使う
dig @VALIDATING_RESOLVER www.example.com A +dnssec +cdflagdigの+dnssecはDNSSEC関連情報を応答へ求める指定であり、dig自身が信頼の連鎖を検証する指定ではありません。検証機能を有効にしたリゾルバーの結果を使い、必要に応じてDNSVizなどの診断ツールや検証用ツールで連鎖を確認します。DSとDNSKEYの照合は、正しい所有者名を使ってDSを計算できる事業者のツールなどで行ってください。
ADフラグはリゾルバーが認証済みと判断したことを示す情報です。信頼できるリゾルバーとの通信経路で確認し、フラグの有無だけで全体を合否判定しないようにします。問い合わせ条件、リゾルバー設定、対象の署名状態によってADが返らない場合があるためです。応答コード、検証の診断結果、親子の証拠を合わせて評価します。
複数の検証リゾルバーで確認する際は、外部の公開リゾルバーと、利用者が実際に使う社内・契約リゾルバーの経路を含めます。違いがあれば、問い合わせ名・種類・時刻・応答元・TTLを揃え直して比較します。異なる名前のAレコードとMXレコードを、同じ結果として比較しないでください。
業務確認ではWebだけでなくMX、認証用ホスト、外部サービスが参照する重要な名前も試します。DNSSECによる検証成功と、TLS証明書やアプリケーションの正常動作は別です。TLS側の発行監視については、Certificate Transparencyログの監視に分けて確認できます。
4. SERVFAILが出たら、追加変更より先に証拠を照合する
通常照会ではSERVFAILになり、同じ名前・種類をCD付きで照会するとデータが返る場合、DNSSEC検証を含む問題を調べる手掛かりになります。ただしSERVFAILには通信や権威DNS側の問題などもあり、この差だけで原因をDS不一致に確定してはいけません。CDはChecking Disabledを意味し、認証の責任を問い合わせ側が引き受ける指定です。
RFC 4035のCDビットの規定からも、CD付きの応答を通常の検証成功と同一視できないことが分かります。診断用のCD付きで答えが返っても、利用者が通常照会で安全に使える状態に戻ったとは報告しません。
| 観測した症状 | 先に照合する証拠 | 避ける判断 |
|---|---|---|
| 親のDSが旧値のまま | 申請状況、親の各権威応答、変更前TTL、反映確認時刻 | 管理画面の保存時刻から待機を数えて旧鍵を消す |
| 権威サーバーごとに鍵・署名が違う | 各子権威サーバーのDNSKEY、RRSIG、配信・同期状況 | 一台で成功したので全体も正常と判断する |
| DSと公開鍵が対応しない | 所有者名、完全なDS値、鍵アルゴリズム、事業者の生成値 | 鍵タグだけを比べて一致とする |
| 通常はSERVFAIL、CD付きは応答 | 署名期限、時刻、DS・DNSKEY、検証ツールの診断 | CD付きの結果を復旧完了の証拠にする |
| 一部経路でだけ検証失敗 | 経路ごとのキャッシュTTL、取得時刻、信頼アンカーと検証設定 | 直ちに全リゾルバーの検証を無効にする |
不一致を発見したら、旧鍵やDSの削除などの後続操作を止め、計画した状態と実際の状態を担当者同士で照合します。現在配信している鍵と署名、親の登録、残るキャッシュの組合せによって、安全に戻せる内容は異なります。古いDSへ戻すだけでは、対応する旧鍵が失われている場合に復旧できません。
旧鍵・署名を保持している場合は、事業者が対応する再公開や署名の手順を確認します。秘密鍵が流出した疑いがある場合は、同じ鍵の再利用を通常の切り戻しとして扱わず、緊急対応の手順へ移します。親のDS削除やDNSSEC停止は信頼の連鎖を解除する変更であり、単なる監視の修正ではありません。必要な場合も責任者の判断と事業者の手順に従い、公開済みキャッシュの影響を含めて計画してください。
復旧完了は、通常照会で検証できること、親と子の状態が計画に合うこと、必要なキャッシュ待機を終えたこと、重要な名前と業務経路が正常であることを確認して判断します。Webが一度表示されたことだけを終了条件にしません。DNSSECの鍵更新は、親子の公開状態とキャッシュを含む検証結果を再確認できて初めて完了します。
記録には、変更依頼番号、鍵の識別情報、DSの完全な値、各応答の取得時刻、反映を確認した時刻、計算した待機期限、異常の発生・復旧時刻、承認者を残します。秘密鍵は監視台帳や問い合わせの添付に含めません。後から担当者が変わっても、どの証拠で旧鍵を退役させたか説明できる状態にしておきます。
よくある質問
DSはDNSKEYと文字列をそのまま比較できますか？
そのままの文字列比較ではありません。DSには鍵タグ、アルゴリズム、ダイジェスト種別、所有者名とDNSKEYのデータから計算したダイジェストが入ります。事業者が生成した完全なDS値や対応する検証ツールを使い、鍵タグだけで一致を判断しないでください。
ZSKが変わるたびにレジストラのDSも変更しますか？
KSKとZSKを分ける一般的な方式では、ZSK更新だけで親のDSを毎回変更する必要はありません。単一鍵方式や事業者固有の運用もあるため、どの鍵がDSに対応するかと、現行の更新方式を確認します。
TTLを短く変更したら、すぐ旧鍵を消せますか？
消せるとは限りません。以前のTTLで保存されたキャッシュはその期間残り得ます。親DSのTTL、新DNSKEYの伝播、旧鍵の保持条件を分け、事業者の方式で指定された待機を満たしてから判断します。
CD付きで名前解決できたら復旧完了ですか？
復旧完了ではありません。CD付きは認証の責任を問い合わせ側へ移す診断用の照会です。通常照会で検証できること、親子の状態、待機条件、重要な名前の応答を改めて確認します。
自動ロールオーバーのサービスでも監視が必要ですか？
自動化される範囲を確認したうえで必要です。鍵と署名の更新、親のDS登録、通知と承認が同じ範囲で自動化されるとは限りません。利用者が行う操作と、実際の検証結果を確認する担当を決めてください。
サイト運用の確認作業を自動化したい場合は、現在の構成と人が判断すべき条件を整理したうえで、ファネルAiの超速AIパートナーの支援内容を確認し、対応範囲を相談してください。
