プロンプト
何万もの署名済みゾーンをホストするプラットフォーム向けに、DNSSEC鍵ロールオーバーのコントロールプレーンを設計してください。検証リゾルバを壊れた信頼チェーンにさらすことなく、レジストラのDSレコード、権威DNSのDNSKEY/RRSIGレコード、テナントの承認を調整します。
シナリオと制約
KSKとZSKの有効期間は異なり、レジストラAPIには遅延がありリトライ可能で、権威ノードは複数リージョンにまたがります。コントロールプレーンには、冪等なリトライ、テナントごとの一時停止、監査可能な状態遷移、および1つのステップが不確実な場合のフェイルクローズ（安全側への停止）動作が必要です。
この設問でテストされること
核心となるのは、ステートマシン、時間不変条件、外部副作用のオーケストレーション、および可観測性です。優れた回答は、DNSKEYの事前公開、DSの公開、旧鍵の廃止、署名の重複期間を明確に区別します。鍵を生成するだけではロールオーバーとは言えません。
リファレンスアプローチ
ゾーンごとのステートマシンを永続化します：observe、prepublish、ds-submit、ds-visible、sign-with-both、retire-old、およびverify。すべての遷移において、目標バージョン、オケーショントークン、TTLバジェット、およびエビデンススナップショットを記録します。新しいDNSKEYをすべての権威ノードに公開してそのTTLを待機し、その後レジストラを通じてDSを送信します。複数の再帰リゾルバを通じて親DSが確認できるようになったら、安全マージンとして両方の鍵で署名し、その後に初めて古いDSとDNSKEYを削除します。
リース制御のもとでゾーンを1つずつ実行します。外部呼び出しには冪等性キーと指数バックオフを使用します。SERVFAIL、DS/DNSKEYの不一致、または期限切れのRRSIGが発生した場合はゾーンをフリーズし、古い鍵素材を保持して人間の承認を要求します。
重要な詳細
データベースは目標状態を保存しますが、DNSクエリとレジストラの読み戻しが信頼できる唯一の情報源（Sources of Truth）です。競合を盲目的に上書きしてはなりません。タイミングには、権威および再帰リゾルバのTTL、署名の有効期間、伝播マージンが含まれます。秘密鍵は制御されたKMSストレージに保持し、秘密情報そのものではなくフィンガープリント、鍵タグ、バージョン、および実行者をログに記録します。
よくある落とし穴
テナント間で同一のレジストラオブジェクトを同時に変更すること、親DSではなく権威ノードのみをチェックすること、失敗したステップの直後に古い鍵を削除すること、キューのリトライを冪等性と同一視すること、一時停止や人間による介入パスを省略することなどが挙げられます。
評価基準
優れた回答は、コントロールプレーン、権威DNS、レジストラ、検証リゾルバ、監査ストレージ間の境界を明確に定義し、少なくとも3つの安全不変条件を述べ、各状態の進入、退出、ロールバック条件を指定します。また、成功率、SERVFAIL、伝播レイテンシ、スタックしたリースのメトリクスを挙げます。
フォローアップ質問
なぜDSの公開は通常、DNSKEYの事前公開の後に行われるのですか？
事前公開により、権威ノードとキャッシュが新しいDNSKEYを最初に取得できます。これにより、親DSが検証リゾルバが取得可能な鍵を指すようになり、「DSは存在するがDNSKEYが見つからない」という期間を短縮できます。
レジストラの呼び出しがタイムアウトしたが成功した可能性がある場合、どのようにリトライしますか？
ゾーンバージョンと冪等性トークンを使用してレジストラの現在のDSを読み取り、リトライするかどうかを決定します。1回のタイムアウトのみに基づいて、2回目の不明な変更を送信しないでください。
システムが古いDSを自動的に削除できるのはいつですか？
新しいDSがターゲットの再帰リゾルバセット全体で可視のままであり、RRSIG検証に合格し、TTLおよび署名ウィンドウがポリシーを満たしている場合のみです。それ以外の場合、ゾーンはフリーズされたままになります。