出題の概要と適用場面
21:00 UTCに、example.com はDNSSECの鍵ロールオーバーを実施し、api.example.com のAレコードを 192.0.2.20 から 192.0.2.40 へ変更します。10分後、一部の検証を行う再帰リゾルバを 使用しているクライアントが SERVFAIL を受信します。同じリゾルバへのクエリに +cd を追加すると、 新しいアドレスと RRSIG が返され、権威サーバーへの直接クエリも応答を受信します。他のクライアントは 引き続き古いアドレスを使用しています。親ゾーンは現在 key tag 18200 のDSを公開しており、子ゾーンは key tag 51900 のDNSKEYのみを公開しています。DNSSECの検証境界を破棄したり、信頼できない応答をユーザーに 配布したりすることなく、このインシデントを診断、復旧、および検証してください。
ドメイン、アドレス、key tag、時刻、および変更内容は面接用の前提条件です。192.0.2.0/24 は ドキュメント用のアドレスブロックです。主なタスクは、観測可能な兆候から各DNS解決レイヤーの状態と DNSSECのトラストチェーンを導き出すことです。SERVFAIL だけからアプリケーションの障害を推測すべきでは ありません。この設問はSRE、インフラ、ネットワーク、セキュリティ、バックエンド、および一般的なソフトウェア エンジニアリングの役割に適しているため、カテゴリは一般（general）です。
シニア職の面接に関する2025年の公開ディスカッションでは、DNSおよびDNSSECの知識が依然として適切な面接内容 として扱われています。その事実は現在の面接コンテキストを示すものであり、出題頻度や特定の企業による固定の設問 を定めるものではありません。.de のDNS障害に関するDENICの2026年レポートでは、大部分の署名が 検証不能になり、検証リゾルバが影響を受ける委任を拒否する原因となったロールオーバーの欠陥が文書化されています。 したがって、鍵、署名、および検証の失敗は運用上依然として現実的な問題です。
既存の「URLを入力したときに何が起こるか」という記事では、クライアントが再帰的な処理を委任し、キャッシュが 経路を短縮する通常ケースを扱っています。SSRFの記事は、解決されたアドレスの認可とDNSリバインディングの脆弱性の 解消に焦点を当てています。本設問は、親のDSレコード、子のDNSKEY/RRSIGレコード、検証状態、安全な復旧順序、 および複数リゾルバ間での検証に焦点を当てています。その障害レイヤーとセキュリティ不変条件は異なります。
面接官が評価するポイント
第一のシグナルはレイヤーごとの診断です。名前解決の失敗は、ローカルスタブ、企業内またはパブリックの再帰リゾルバ、 親の委任、権威サーバー、DNSSEC検証、あるいは最終的なA、AAAA、CNAMEデータに起因する可能性があります。優れた 回答では、クエリ名、タイプ、時刻、リゾルバを固定し、各レイヤーでRCODE、回答、TTL、権威データ、およびDNSSEC レコードを収集し、観測結果が乖離する最初のポイントを特定します。
第二のシグナルは正確なレスポンスコードの解釈です。NXDOMAIN は、権威チェーンが対象の名前が存在しないと 主張していることを意味します。空の回答を伴う NOERROR は、名前は存在するもののそのタイプのレコードが 存在しないことを意味する場合があります。タイムアウトは、制限時間内に使用可能な応答が届かなかったことを意味します。 REFUSED はサーバーがクエリを拒否したことを意味します。SERVFAIL は汎用的なサーバーエラーです。 DNSSEC検証の失敗によって SERVFAIL が生成されることがありますが、1つのステータスコードだけでその原因を 証明することはできません。
第三のシグナルはトラストチェーンの理解です。DSレコードは親側の委任ポイントに存在し、親の信頼されたチェーンを 子のDNSKEYに接続します。RRSIGレコードは子ゾーン内のRRsetに署名し、バリデータはアルゴリズム、ダイジェスト、 署名の有効期間、およびトラストアンカーもチェックします。key tagは候補となる鍵を見つけるのに役立ちますが、 暗号学的な証明ではありません。回答では、DSのダイジェストが実際のDNSKEYに対応していること、および公開された 鍵が関連する署名を検証できることを確認する必要があります。
第四のシグナルは対照比較です。同じ再帰リゾルバに対して、通常の +dnssec クエリが失敗する一方で、 +cd クエリが生のレコードを返す場合、検証パスに原因がある可能性が極めて高くなります。CDはリゾルバに そのクエリのチェックを無効化するよう要求するものであり、診断に役立ちます。返されたデータを信頼できるものにする わけではなく、本番環境でのバイパス手段ではありません。信頼できる検証リゾルバからのADビットは、認証済みデータを 主張できます。ADの欠如は、クライアントのリクエスト、リゾルバのポリシー、または信頼境界を反映している場合も あるため、他の証拠と合わせて解釈する必要があります。
最後に、面接官は復旧手順の規律を評価します。現在の親DSによって参照されている古い鍵が早期に退役しすぎた場合、 最も迅速で安全な経路は、多くの場合、現在のDSが認証できるDNSKEYと有効な署名を復元し、重複期間を設けて ロールオーバーを再開することです。検証をグローバルに無効化したり、任意のキャッシュをフラッシュしたり、Aレコードを 繰り返し編集したりすることはリスクを拡大させます。復旧後も既存のTTLが収束する必要があり、独立したバリデータが 健全なチェーンと正常に動作するアプリケーションの両方を証明しなければなりません。
回答前に確認すべき質問
- 影響は単一の名前に限定されているか、ゾーン全体か、それとも1つのTLD下の多数のゾーンに及んでいるか？ 影響範囲によって、子ゾーンの変更、権威プロバイダ、または親/レジストリのインシデントのどこから調査を開始すべきかが決まります。
- 失敗しているクライアントは実際にどの再帰リゾルバを使用しているか？ ブラウザの暗号化DNS、企業内フォワーダー、VPN、およびOS設定により、同じネットワークからでもクライアントが異なる経路をたどる場合があります。
- 各失敗のRCODE、EDE、クエリタイプ、および時刻は何か？ Aの成功とAAAAの失敗、壊れたCNAMEホップ、または検証リゾルバのみに限定された失敗では、分岐する調査手順が異なります。
- 変更前後のNS、DS、DNSKEY、RRSIG、およびTTLの値はどうだったか？ ロールオーバーの順序、最大キャッシュ生存期間、および復旧可能な古い鍵によって緩和策が決まります。
- すべての権威サーバーが同じSOAシリアルと署名済みRRsetを返しているか？ 権威サーバー間のバージョン不一致は断続的な結果を生む可能性があり、1台のサーバーがゾーン全体を代表しているとは限りません。
- リゾルバとサイナー（署名サーバー）の時計は正確か？ RRSIGレコードには開始時刻（inception）と有効期限（expiration）があるため、大幅な時刻のずれは検証失敗の原因になります。
- 古いIPは引き続きトラフィックを安全に処理できるか？ 可能な場合は、TTL収束の間互換性を維持します。不可能な場合は、DNSがキャッシュされた回答を強制的に失効させることができないため、その接続リスクを個別に管理します。
- 親DSと緊急変更を制御しているのは誰か？ レジストラ、レジストリ、DNSプロバイダ、および社内のオンコールチームは、それぞれ権限と応答時間が異なります。
30秒の回答フレームワーク
「失敗しているクライアントの再帰リゾルバを特定し、RCODE、EDE、A/AAAA/CNAMEデータ、TTL、およびタイムスタンプを 記録します。同じリゾルバに対して、通常時の SERVFAIL と +cd によるデータ取得を 比較することで、DNSSEC検証パスに焦点を絞ります。親からDSを取得し、すべての権威サーバーからDNSKEY、RRSIG、 SOAを取得して、ダイジェスト、アルゴリズム、署名時刻、およびノード間の一致を確認します。ここでは、親のDSに 一致する子DNSKEYが存在せず、古い鍵の退役が早すぎた状況と一致しています。まずは、現在のDSと一致する正常であることが わかっている鍵と署名を復元します。複数のバリデータが認証済みの回答を返すようになった後、TTLの収束を監視し、 重複期間を伴うロールオーバー、事前公開検証、署名期限切れアラート、および複数拠点からの外形監視チェックを追加します。」
ステップごとの詳細な回答
ステップ1: 障害の境界と対照群を確立する
1つの失敗について、時刻、クライアントネットワーク、実際の再帰リゾルバ、クエリ名、およびクエリタイプを記録します。 アプリケーションやブラウザのキャッシュをバイパスし、クライアントが使用しているリゾルバに直接クエリを投げます。 次に、対照群として独立した検証再帰リゾルバを選択します。名前、タイプ、リゾルバを同時に変更しないでください。 違いが生じた際に変数を切り分けられなくなるためです。
dig @<affected-resolver> api.example.com A +dnssec
dig @<affected-resolver> api.example.com AAAA +dnssec
dig @<control-resolver> api.example.com A +dnssec完全な応答から status、フラグ、Answer、Authority、Additional、TTL、およびEDNS Extended DNS Error（EDE）を 保持します。Aが検証されAAAAが失敗する場合は、AAAAとそのCNAMEチェーンを検査します。すべてのタイプがタイムアウトする 場合は、まずネットワークの到達性、ポート53、権威サーバーの可用性、およびパケットサイズの処理を検査します。 単一の再帰リゾルバのみが失敗する場合、そのキャッシュ、ポリシー、クロック、またはフォワーディングチェーンが候補に残ります。
古いIPにまだ到達できているクライアントが存在することは、矛盾する証拠ではありません。古いA RRsetはTTLが切れるまで 再利用可能であり、それに付随する署名もまだ有効である可能性があります。TTLは公開後に遡って短縮することはできないため、 既知のキャッシュ期間中は古いエンドポイントの安全性と互換性を維持してください。
ステップ2: CD比較を使用してDNSSECブランチに入る
障害が発生している同じリゾルバに対して、CDをセットして同じ名前とタイプを再試行します：
dig @<affected-resolver> api.example.com A +dnssec
dig @<affected-resolver> api.example.com A +dnssec +cd通常のクエリが SERVFAIL を返し、+cd がA、DNSKEY、またはRRSIGレコードを返す場合、 検証の失敗が有力な仮説となります。Google Public DNSのドメイン別トラブルシューティングでも同様の対比（検証無効時の Status 2と成功）を使用してDNSSECの問題の可能性を特定しており、Extended DNS Errorsによってより具体的な理由を 把握できます。権威サーバーのタイムアウト、委任ループ、その他のサーバー障害でも SERVFAIL が発生する 可能性があるため、生の経路の検査も継続します。
+cd は、リゾルバが通常なら拒否するデータを露出させます。アプリケーションの参照先を非検証リゾルバに 向けたり、DNSSECをグローバルに無効化したりすると、可用性のインシデントが完全性のリスクに変わります。インシデント コマンダーが広範な上流障害時に検証例外を使用する場合でも、狭いドメイン範囲、時間制限、記録されたリスク、および明確な 終了基準が必要です。
ステップ3: 委任、権威データ、および署名を個別に検査する
まずトレースを使用して、ルート、親、および子の委任を通過する実際の経路を列挙します。トレースはクエリ経路の観測 であり、完全な暗号検証結果ではありません。親の権威サーバーから直接DSをクエリし、すべての子の権威サーバーから DNSKEY、SOA、および業務RRsetをクエリします。
dig +trace example.com DS +dnssec
dig @<parent-authoritative> example.com DS +dnssec
dig @<child-authoritative-1> example.com DNSKEY +dnssec
dig @<child-authoritative-1> api.example.com A +dnssec
dig @<child-authoritative-1> example.com SOA +dnssecすべての権威サーバーに対してクエリを繰り返し、NSセット、glue、SOAシリアル、DNSKEY RRset、およびRRSIGレコードを 比較します。権威サーバーがAとRRSIGを返すことは、データを配信していることの証明になります。権威サーバーは通常、 要求者に代わって親のトラストアンカーからの完全なチェーンを検証しません。したがって、権威への直接クエリの成功と 再帰検証の失敗は共存し得ます。
親DSのオーナー、アルゴリズム、ダイジェストタイプ、およびダイジェストが子のDNSKEYに対応していること、DNSKEY RRsetが 現在有効な署名を持っていること、業務A RRsetのRRSIGが妥当なkey tag、アルゴリズム、開始時刻、有効期限を持っていること、 およびCNAMEチェーン内の署名されたすべてのゾーンがチェーンを確立できることを確認します。独立したバリデータが障害の あるノードを特定でき、その後生のレコードでそれを確認できます。
このシナリオでは、親のDS key tag 18200に対応する候補が子DNSKEY RRsetに存在せず、そのダイジェストは現在の鍵51900と 一致しません。変更時刻との相関から、親DSが安全な移行を完了する前に古いKSK/DNSKEYが削除されたことがわかります。 タグの不一致は手がかりであり、ダイジェストの比較と署名検証によって証明が完了します。
ステップ4: セキュリティ境界内で復旧する
自動ロールオーバーおよび無関係なDNS変更を凍結します。変更ログ、ゾーングランドスナップショット、鍵識別子、および 失敗した応答を保存します。以前の秘密鍵が管理対象の鍵システムに残っている場合は、そのDNSKEYを復元し、現在の親DSを 通じたチェーンを確立する正常な署名を生成します。これは多くの場合、親の変更を待つよりも迅速です。すべての権威サーバー から同じ状態を公開する前に、完全なチェーンを隔離環境で検証します。
古い鍵が復元不可能な場合、DNSおよびセキュリティ担当者はレジストラと連携して親DSの修正を調整し、伝播時間を考慮 する必要があります。DSを削除すると子は未署名状態に戻り、認証の保証が弱まり、依然としてキャッシュと親の変更レイテンシが 発生します。これは承認され、文書化された、範囲を絞った復旧オプションであり、安易な近道ではありません。同じkey tag のみを持つ新しい鍵を生成しても機能しません（ダイジェストが一致しないため）。
古いAエンドポイントが安全なままである場合は、古いRRsetのTTL期間中それを提供し続けます。古いエンドポイントと新しい エンドポイントは、互換性のある重要な設定と認証ポリシーを使用する必要があります。キャッシュのフラッシュはオペレータが 制御できるリゾルバにのみ影響するため、復旧を存在しないグローバルなフラッシュに依存させることはできません。
ステップ5: DNSとアプリケーションが復旧したことを証明する
独立した検証再帰リゾルバおよび複数の地域から修正後の名前をクエリします。SERVFAIL が解消され、期待される 回答が得られ、信頼できる検証結果が存在することを確認します。次に、成功した古いキャッシュによって欠陥が隠蔽されないよう、 フレッシュなキャッシュを持つリゾルバまたは独立した検証ツールを使用して完全な名前解決を実行します。すべての権威サーバーで SOAシリアル、DNSKEYレコード、および署名を比較し、残りの署名有効期間を記録します。
次にアプリケーションを検証します。古いアドレスと新しいアドレスの両方で、ヘルスチェック、TLS証明書、認証済みリクエスト、 およびクリティカルなAPIが機能しなければなりません。DNSが成功しても新しいエンドポイントの設定に不備があれば不完全な 復旧です。古いキャッシュのトラフィックが収束するまで、元のTTLおよび署名ウィンドウの間、失敗率、古いアドレスへの トラフィック、RCODE、名前解決レイテンシ、およびビジネスエラーを監視します。サービスで使用されるA、AAAA、CNAME、 その他のレコードタイプを対象に含めます。
公開、最初のバリデータ障害、根本原因の証拠、セキュリティ判断、親/子の復旧、およびTTL収束のタイムラインを保持します。 独立した検証とユーザーの利用結果の両方が復旧した後にのみ、インシデントをクローズします。
ステップ6: ロールオーバーを検証可能なリリースプロセスにする
権威サーバーやキャッシュが観測できるように、新しいDNSKEYを事前に公開（prepublish）します。古いチェーンが有効な間に 親DSを更新し、関連するTTLおよびレジストリのワークフローを待ち、許容される古いチェーンと新しいチェーンを継続的に 検証し、その後に初めて古いDS、署名、および鍵を退役させます。正確な手順はプロバイダおよびレジストリがサポートする 手順に従う必要があり、固定された待機分数といった画一的なルールは存在しません。
リリースゲートでは、本番のすべてのサイナーが相互に有効でサポートされたDNSKEYおよび署名データを公開していること、 親DSが意図した鍵に到達していること、RRSIGレコードに十分な残り有効期間があること、抽出サンプルの業務RRsetが検証されること、 およびアラートが担当者に届くことを証明する必要があります。DENICの2026年レポートでも、複数のHSMを必要とし単一HSMの テストをすり抜けた欠陥や、既存の検証アラートが適切に処理されなかった事例が示されています。したがって、再発防止には 本番トポロジのカバーと訓練されたアラートループが必要です。
質の高い模範解答
「まず、失敗しているクライアントが使用している再帰リゾルバ、クエリタイプ、およびタイムスタンプを特定し、完全な 応答を保存します。同じリゾルバに対して、api.example.com A +dnssec は SERVFAIL を返す一方で、 +cd を追加するとAとRRSIGが返されます。この対照比較により、DNSSEC検証に優先順位を置きます。 CDによる応答は依然として信頼できないため、本番アプリケーションに渡すことはできません。
+trace を使用して実際の委任を観測し、親から直接DSをクエリし、すべての子権威サーバーからDNSKEY、 SOA、A、およびRRSIGをクエリします。親DSのアルゴリズムとダイジェストがDNSKEYと一致するか、すべての権威サーバーが同じ シリアルを共有しているか、各RRSIGのkey tagと有効期間が妥当か、そして独立したバリデータがどの時点でチェーンをbogusと 判定しているかをテストします。権威サーバーからの直接の回答はチェーンを証明しません。そのサーバーはレコードを提供する だけであり、再帰バリデータは子鍵を親DSおよびトラストアンカーに接続する必要があるためです。
このシナリオのDS 18200には一致するDNSKEYがなく、そのダイジェストは鍵51900と一致しないため、古い鍵が早期に退役された ことを示しています。変更を凍結し、管理対象の鍵システムから現在のDSと一致する古いDNSKEYと有効な署名を復元し、隔離環境で 検証した上で、すべての権威サーバーから一貫した状態を公開します。古い鍵を復元できない場合は、セキュリティ担当者と レジストラがDS修正を調整する必要があります。グローバルに検証を無効化したり、グローバルなキャッシュフラッシュが存在すると 仮定したりはしません。
復旧後、複数の地域および独立した検証リゾルバからコールドおよびウォームクエリを実行し、RCODE、認証状態、A/AAAA/CNAME、 TTL、および権威のシリアルをチェックします。また、古いアドレスと新しいアドレスの両方でTLSと重要なAPIをテストします。 クライアントはTTLの間正当に古いIPを使用する可能性があるため、トラフィックが収束するまでそのエンドポイントの互換性を 維持します。最後に、鍵の事前公開、チェーンの重複、親DSのリリースゲート、署名期限切れの監視、複数権威間の一致確認、 本番トポロジでのテスト、および検証済みのアラート配信をロールオーバープロセスに追加します。」
よくある間違い
SERVFAILを確認した直後にアプリサーバーを変更する → DNSが信頼できるアドレスを生成していないため、アプリにトラフィックが届かない可能性があります → まずリゾルバを固定し、RCODE、EDE、および委任を検査してください。+cdの成功を信頼できるデータとして扱う → CDは検証をスキップするため、破損したデータを返す可能性があります → 対照群としてのみ使用し、その後DS、DNSKEY、およびRRSIGを検証してください。- 権威サーバーへの直接クエリが成功したためDNSSECを除外する → 権威サーバーは親チェーンを通じて検証できないデータを配信する場合があります → データの可用性と暗号検証を個別にテストしてください。
- key tagのみを比較する → key tagは候補を選択するだけで、アルゴリズムとダイジェストの検証の代わりにはなりません → DSからDNSKEYへの完全な関係を計算または独立して検証してください。
- 古いIPと
SERVFAILを単一のキャッシュバグと見なす → 有効な古いキャッシュと失敗した新しい検証は共存し得ます → リゾルバ、キャッシュ経過時間、およびTTLごとに観測をセグメント化してください。 - ロールオーバー中に古い鍵を直ちに削除する → 親のDSレコードと再帰キャッシュは依然として古いチェーンに依存している可能性があります → 検証およびTTLゲートを通過するまで重複チェーンを維持してください。
- 緩和策としてDNSSECをグローバルに無効化する → 解決は復旧しますが認証が犠牲になります → まず既知の正常なチェーンを復元してください。例外を設ける場合は範囲を絞り、期限を定め、承認を得て元に戻してください。
- 公開後にTTLを下げる → キャッシュされた回答は受信した時点のTTLを引き続き使用します → 移行前にTTLを計画し、インシデント中は古いエンドポイントの互換性を維持してください。
- プロダクトではなく
digのみをテストする → 新しいIPで証明書、ルーティング、または設定の障害が発生している可能性があります → 名前解決、TLS、クリティカルAPI、およびユーザーエラー率を検証してください。 - 1台のサイナーのみをテストする → 複数ノードまたは複数HSMの本番パスでは異なる結果が生成される場合があります → 実際のトポロジでテストし、すべての署名ノードを比較してください。
フォローアップ質問と回答例
フォローアップ1: NXDOMAIN、空の回答、および SERVFAIL を迅速に見分けるにはどうすればよいですか？
RCODEとAuthorityセクションを検査します。NXDOMAIN は照会された名前が存在しないことを主張します。 Answerが空の NOERROR は、通常SOAを伴い、名前は存在するものの要求されたタイプが存在しないことを 意味する場合があります。SERVFAIL はサーバーが受け入れ可能な結果を生成できなかったことを意味し、 DNSSECのbogusデータ、上流のタイムアウト、委任の失敗、および内部エラーのすべてが原因となり得ます。ブラウザの メッセージに依存するのではなく、どのレイヤーが応答を生成したか、および否定応答に認証された不在証明（authenticated denial） があるかどうかを判断します。
フォローアップ2: 一部のリゾルバが成功し、他のリゾルバが失敗するのはなぜですか？
DNSSECを検証しているか、どのRRsetをキャッシュしているか、いつ期限切れになるか、上流サーバー、時計、および ローカルポリシーを比較します。成功しているリゾルバは、ロールオーバー前の有効なキャッシュをまだ提供しているか、 あるいは検証を行っていない可能性があります。失敗しているリゾルバは、キャッシュを更新して壊れたチェーンを検出した 可能性があります。リゾルバの挙動の差異は手がかりであり、CD/ADの動作、生のレコード、およびキャッシュの経過時間によって 最終的な要因を特定します。
フォローアップ3: キャッシュのフラッシュによってすべてのユーザーを直ちに復旧できますか？
オペレータがフラッシュできるのは、自身が制御しているブラウザ、OS、または再帰リゾルバのみです。外部のリゾルバや エンドポイントはすでに受信したTTLに従い、ドメイン所有者にはグローバルなフラッシュAPIはありません。既知の正常な 署名チェーンを復元しながら古いエンドポイントの互換性を維持することで、コールドクエリと古い回答を持つクライアントの 両方をカバーできます。移行前のTTL短縮は、以前のTTLが期限切れになる十分前に実施された場合にのみ機能します。
フォローアップ4: KSKとZSKのロールオーバー境界はどのように異なりますか？
一般的な構成では、DNSKEY RRsetの署名にKSKを使用し、AやAAAAなどの業務RRsetの署名にZSKを使用します。KSKロールオーバーは 親DSの境界を越えるため、組織やキャッシュをまたぎます。ZSKロールオーバーは通常子ゾーン内で完結しますが、依然として DNSKEYとRRSIGの有効性の重複が必要です。プロバイダによって異なる鍵モデルを使用する場合があるため、機械的にラベルを 当てはめるのではなく、実際のDNSKEYフラグ、サイナー、およびサポートされている手順から回答を導き出してください。
フォローアップ5: DNSSECロールオーバーにどのようなリリースゲートを追加しますか？
本番と同等のトポロジを持つステージング環境でロールオーバーを実行し、すべてのサイナーが相互に有効な出力を生成することを 証明します。リリース前に、親DS、子DNSKEY、サポートされるアルゴリズム、RRSIGの開始/有効期限、SOAシリアル、および 権威の一致を確認し、少なくとも2つの独立したバリデータを通じてコールドクエリを実行します。アラートには担当者の指定、 エスカレーションパス、およびリハーサルされたロールバック手順が必要です。期限切れの署名、欠落した鍵、およびノード間の 不一致を擬似的に発生させ、インシデントが確実に検出され対処されることを証明します。