ANSネットワークのセキュリティ、コンプライアンス、ガバナンス
ある金融サービス企業は、DNSキャッシュポイズニング攻撃（攻撃者が偽のDNS応答をキャッシュサーバーに注入してユーザーを不正サイトへ誘導する攻撃）を防ぐため、Route 53パブリックホストゾーンにDNSSEC署名を有効化することにしました。以下の要件があります。
・example.com のパブリックホストゾーンにDNSSECを有効化する
・ルートゾーンからexample.comまでの信頼チェーン（Chain of Trust）を確立する
・鍵管理はAWSマネージドで行い、運用負荷を最小化する
DNSSEC有効化後に必ず実施すべき手順として正しいものはどれですか？
ARoute 53コンソールでDNSSEC署名を有効化した後、生成されたDS（Delegation Signer）レコードをドメインレジストラ（親ゾーン）に登録して信頼チェーンを確立する
✓ 正解
Route 53でDNSSEC署名を有効化すると、KSK（Key Signing Key）から派生したDS（Delegation Signer）レコードが生成されます。このDSレコードをドメインレジストラ（TLD親ゾーン）に登録することで、「ルートゾーン → TLD → example.com」という信頼チェーンが完成し、DNSSEC検証が機能します。この手順を省略すると、DNSSEC署名は有効でも信頼チェーンが断絶し、DNSSEC検証を行うリゾルバーがDNS解決に失敗します。
BAWS KMSでECC_NIST_P256アルゴリズムの非対称キーを手動作成し、キーポリシーにRoute 53サービスプリンシパル（dnssec-route53.amazonaws.com）への署名権限を付与してからDNSSECを有効化する
AWS KMSは、Route 53のDNSSEC有効化ウィザードがキーの作成とキーポリシー設定を自動的に行うため、手動での非対称キー作成は不要です。手動設定は誤りの原因となります。
CDNSSEC有効化後、Route 53のDNSKEYリソースレコードセットにZSK（Zone Signing Key）とKSK（Key Signing Key）のパブリックキー値を手動で追加する
Route 53マネージドDNSSECは、ZSKおよびKSKのDNSKEYレコードをRoute 53が自動的に管理・公開するため、手動での追加は不要です。
DRoute 53ヘルスチェックをDNSSEC検証対応エンドポイントに切り替え、DNSSEC検証失敗時に別ホストゾーンへ自動フェイルオーバーするフェイルオーバールーティングポリシーを設定する
Route 53ヘルスチェックはDNSSEC検証エラーを検知してフェイルオーバーする機能を持たず、DNSSEC有効化後の必須作業ではありません。
解説
Route 53でDNSSEC署名を有効化すると、KSK（Key Signing Key）から派生したDS（Delegation Signer）レコードが生成されます。このDSレコードをドメインレジストラ（TLD親ゾーン）に登録することで、「ルートゾーン → TLD → example.com」という信頼チェーンが完成し、DNSSEC検証が機能します。この手順を省略すると、DNSSEC署名は有効でも信頼チェーンが断絶し、DNSSEC検証を行うリゾルバーがDNS解決に失敗します。
選択肢BのAWS KMSは、Route 53のDNSSEC有効化ウィザードがキーの作成とキーポリシー設定を自動的に行うため、手動での非対称キー作成は不要です。手動設定は誤りの原因となります。
選択肢CのRoute 53マネージドDNSSECは、ZSKおよびKSKのDNSKEYレコードをRoute 53が自動的に管理・公開するため、手動での追加は不要です。
選択肢DのRoute 53ヘルスチェックはDNSSEC検証エラーを検知してフェイルオーバーする機能を持たず、DNSSEC有効化後の必須作業ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでANSを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →