🛡️ AWS Route 53 × DNSSEC 実装ガイド

DNSを偽装から守る
DNSSEC完全ガイド

DNS Security Extensions（DNSSEC）をRoute 53の4つのパブリックホストゾーンに実装し、 キャッシュポイズニング・DNSスプーフィングを防ぐ方法を、図解とたとえ話で徹底解説します。

🔐 データ認証 🔗 整合性検証 🗝️ KMS連携 📊 CloudWatch監視 4 ホストゾーン対応
🌍 🔑 ✅ 🗝️ 📋
SECTION 01 なぜDNSSECが必要か

DNSは「電話帳」— でも改ざんされる

DNSは人間が読めるドメイン名をIPアドレスに変換する仕組みです。この仕組みに脆弱性があると、攻撃者に悪用されます。

💡

このセクションのポイント：DNSSECがない場合、攻撃者は偽のDNS応答を注入してユーザーを悪意あるサーバーへ誘導できます。DNSSECはデジタル署名によって「この応答は本物だ」と証明します。

攻撃シナリオ vs DNSSECによる防御
⚠️ DNSSECなし — キャッシュポイズニング攻撃 👤 ユーザー 🔄 DNSリゾルバ 💀 攻撃者 💀 偽サーバー ①要求 ②偽応答注入 ③悪意あるIPを返却 ④ユーザーが偽サーバーへ誘導 → フィッシング被害 ✅ DNSSECあり — 署名検証で防御 👤 ユーザー 🔄🛡️ DNSリゾルバ(検証) 💀 攻撃者 ✅ 正規サーバー ①要求 偽応答 🚫 ②署名検証OK ③正規IPを返却 → 安全に接続
SECTION 02 信頼チェーン

Chain of Trust — パスポートと同じ階層的認証

DNSSECは「上位が下位を保証する」連鎖構造で成立します。ちょうどパスポートが国家によって保証されるように。

💡

結論：あなたのゾーンは親ゾーンから認証され、最終的にはIANAが管理するルートゾーンまで遡ります。チェーンの一部が壊れると検証失敗となります。

📜 たとえ話
パスポートの
国家認証チェーン
パスポートは あなた → 自国政府 → ICAO（国際機関） の順で信頼が保証されます。 DNSSECも同様に、あなたのゾーン → 親ゾーン → ルートゾーンまで遡って認証します。
🌍
ICAO = DNSSECのルートゾーン
🏛️
自国政府 = TLDゾーン（.com / .jp）
🪪
パスポート = あなたのDNSゾーン
🌍 ルートゾーン（.） IANA管理 — 信頼のアンカー DS レコードで保証 🏷️ TLD ゾーン（.com / .jp） 各レジストリ管理 — DSレコードを保持 DS レコードで保証 🌐 example.com ゾーン Route 53 ホストゾーン — KSK/ZSKで署名 RRSIG署名付きで応答 ✅ クライアント（DNSリゾルバ） ルートから順に検証 → Authentic Data確認
SECTION 03 キーの種類

2種類の鍵 — KSK と ZSK

DNSSECは役割の異なる2つの鍵を使い分けます。上位の鍵（KSK）が下位の鍵（ZSK）を保証する二重構造です。

💡

結論：KSKは「金庫のマスターキー」で滅多に使わない高セキュリティな鍵。ZSKは「日常のカードキー」で実際のDNSレコードに署名し、Route 53が自動ローテーションします。

KSK — Key-Signing Key

鍵署名鍵

ZSK（ゾーン署名鍵）に署名するための上位の鍵。AWS KMSに保存され、より強固なセキュリティが適用されます。ローテーションは手動で実施。

管理 AWS KMS（us-east-1）
有効期間 最大2年（設定可）
ローテーション ⚠️ 手動（要監視）
署名対象 DNSKEY RRset（ZSKを含む）
🏦
たとえ話 銀行の金庫マスターキー。普段は使わないが、カードキー（ZSK）の権限を発行・管理する最重要鍵。有効期限切れは重大障害を招く。
ZSK — Zone-Signing Key

ゾーン署名鍵

実際のDNSレコード（A/MX/CNAME等）に署名する鍵。Route 53が自動的に管理・ローテーションするため、お客様の作業は不要。

管理 Route 53が自動管理
有効期間 Route 53が自動設定
ローテーション ✅ 自動（作業不要）
署名対象 各DNSレコード（RRSIG生成）
🪪
たとえ話 オフィスのICカードキー。毎日使う実用的な鍵で定期的に自動更新される。マスターキー（KSK）によってその正当性が保証される。
KSK / ZSK 署名フロー
🗝️ AWS KMS 非対称キー 生成 🔐 KSK 鍵署名鍵 署名 DNSKEY RRset 🔐 KSK 公開鍵 🔑 ZSK 公開鍵 署名 🔑 ZSK ゾーン署名鍵 署名 DNSレコード + RRSIG A record: 93.184.216.34 MX record: mail.example.com ✍️ RRSIG（署名）
SECTION 04 アーキテクチャ

4ホストゾーン実装アーキテクチャ全体図

KMS・Route 53・CloudWatchの3層で構成されるDNSSEC実装の全体像です。

💡

結論：KMSキー（us-east-1）→ Route 53 KSK → 4ホストゾーンDNSSEC有効化 → DSレコード登録 → CloudWatch監視、の流れで実装します。

🗝️ キー管理レイヤー — AWS KMS（us-east-1 必須） 🗝️ KMS 非対称キー ECC_NIST_P256 / SIGN_VERIFY 生成 🔐 KSK（Route 53管理） 手動ローテーション 管理 🔑 ZSK（自動） ✅ 自動ローテーション 🌐 DNSゾーンレイヤー — Route 53（4 パブリックホストゾーン） 📁 ホストゾーン A example.com ✅ DNSSEC有効 📁 ホストゾーン B example.net ✅ DNSSEC有効 📁 ホストゾーン C example.org ✅ DNSSEC有効 📁 ホストゾーン D example.io ✅ DNSSEC有効 メトリクス送信 📊 監視レイヤー — Amazon CloudWatch + SNS ⏰ KSK期限アラーム NeedingAction ≥ 1 📧 SNS Topic 👤 運用チーム通知
SECTION 05 実装手順

4ステップ実装手順（AWS CLI）

KMSキー作成からCloudWatchアラート設定まで、実際のCLIコマンドで解説します。

💡

重要：ステップ3のDSレコード登録はレジストラ側での手動作業が必要です。この手順を省略すると信頼チェーンが形成されず、DNSSECが機能しません。

1

🗝️ KMSキーの作成

us-east-1必須。Route 53 DNSSECはus-east-1のKMSキーのみ対応。他リージョンでは動作しません。

# KMS非対称キーを作成（us-east-1） aws kms create-key \ --key-spec ECC_NIST_P256 \ --key-usage SIGN_VERIFY \ --region us-east-1 \ --description "Route53 DNSSEC KSK" # Route 53に署名権限を付与 aws kms put-key-policy \ --key-id <KEY_ID> \ --policy-name default \ --policy file://r53-kms-policy.json
2

📝 KSK作成 & DNSSEC有効化

4ホストゾーンそれぞれにKSKを作成し、DNSSECを有効化します。

# 4ゾーン一括処理 for ZONE_ID in Z1AAA Z2BBB Z3CCC Z4DDD; do # KSK作成 aws route53 create-key-signing-key \ --hosted-zone-id $ZONE_ID \ --kms-arn arn:aws:kms:us-east-1:... \ --name "ksk-$ZONE_ID" \ --status ACTIVE # DNSSEC有効化 aws route53 enable-hosted-zone-dnssec \ --hosted-zone-id $ZONE_ID done
3

🔗 DSレコードをレジストラへ登録

親ゾーン（レジストラ）にDSレコードを登録して信頼チェーンを確立します。手動作業が必要。

# DSレコード情報を取得 aws route53 get-dnssec \ --hosted-zone-id Z1AAABBBCCC \ --query 'KeySigningKeys[*].DSRecord' # 出力例（レジストラの管理画面に入力） example.com. 3600 IN DS 12345 13 2 abc123def456... # 検証コマンド dig +dnssec example.com A # → ADフラグが付いていれば成功
4

🔔 CloudWatchアラート設定

KSK有効期限切れを事前検知するアラームを設定します。

# KSK期限切れアラート aws cloudwatch put-metric-alarm \ --alarm-name "DNSSEC-KSK-Action-Needed" \ --namespace AWS/Route53 \ --metric-name \ DNSSECKeySigningKeysNeedingAction \ --statistic Sum \ --period 86400 \ --threshold 1 \ --comparison-operator \ GreaterThanOrEqualToThreshold \ --alarm-actions arn:aws:sns:...
SECTION 06 KSKローテーション

KSKローテーション — 順序を守らないと障害になる

KSKは自動ローテーションされません。手順を誤るとDNS解決が停止する重大障害を招きます。

⚠️

必ず守る順序：旧DSレコードを削除する前に新DSレコードを親ゾーンへ登録してください。逆順で実施すると信頼チェーンが断絶し、DNSSECを有効にしているドメインにアクセスできなくなります。

🗝️

① 新KSKをADD状態で作成

新しいKMSキーを使って新KSKを作成。まだACTIVEにしない。

aws route53 create-key-signing-key \ --name ksk-v2 --status ACTIVE
📋

② 新DSレコードをレジストラへ登録

新KSKのDSレコードを取得し、レジストラの管理画面で登録します。TTL分の伝播を待つ（通常24〜48時間）。

⏳ TTL伝播待ち必須
🗑️
③ 旧DSレコードをレジストラから削除

新DSが伝播したことを確認してから旧DSを削除します。

⚠️ 新DS確認後のみ実施
🔕
④ 旧KSKをINACTIVE化

旧KSKのステータスをINACTIVEに変更します。

aws route53 deactivate-key-signing-key \ --hosted-zone-id Z1AAA \ --name ksk-v1
✅
⑤ 旧KSKを削除（オプション）

不要になった旧KSKとKMSキーを削除します。完了。

✅ ローテーション完了
💀 やってはいけない順序（DNS障害）
❌ 旧DSを先に削除
↓ 信頼チェーン断絶
❌ 新DSを後から登録
↓ DNSSEC検証失敗
💀 ドメインにアクセス不能
📅 監視アラートのタイミング
90日前 📧 メール通知
30日前 ⚠️ Slackアラート
7日前 🚨 PagerDuty緊急
期限当日 💀 DNS障害リスク
SECTION 07 アラート設計

CloudWatch アラート — 3段階の監視設計

重大度に応じた3段階のアラートで、KSK期限切れによる障害を事前に防ぎます。

🚨 CRITICAL

緊急対応が必要

KSKが期限切れ、またはDNSSEC署名が無効な状態。DNS解決が停止する直前。即時対応が必要。

メトリクス: NeedingAction ≥ 1
通知先: PagerDuty / オンコール
対応: KSK即時ローテーション
⚠️ WARNING

計画的な対応が必要

KSKの有効期限が近づいている。まだ余裕があるため、計画的にローテーションを実施できる段階。

タイミング: 90日前・30日前
通知先: メール / Slack
対応: ローテーション計画作成
ℹ️ INFO

監査ログ・変更記録

DNSSEC設定変更のCloudTrailログ。コンプライアンス・監査目的で記録。障害時のトレーサビリティに使用。

ソース: CloudTrail Events
対象: CreateKSK / UpdateStatus
保存: S3アーカイブ（長期保存）
SECTION 08 コンポーネント一覧

DNSSECコンポーネント全体まとめ

KMSキーからRRSIGレコードまで、全コンポーネントの役割・管理主体・自動化状況を一覧で確認できます。

コンポーネント 役割 管理主体 ローテーション 注意点
🗝️ KMS非対称キー KSKの暗号化基盤。実際の電子署名演算を実行する。 お客様（IAM制御） ⚠️ 手動 us-east-1 必須
🔐 KSK ZSKへの署名。DNSKEY RRsetを保護する上位の鍵。 お客様 × Route 53 ⚠️ 手動 期限切れ = DNS障害
🔑 ZSK Aレコード・MXレコード等への実際の署名（RRSIG生成）。 Route 53が完全管理 ✅ 自動 作業不要
📋 DNSKEY KSK・ZSKの公開鍵を公開するレコード。 Route 53が自動生成 KSK/ZSKに連動 自動管理
🔗 DS レコード 親ゾーン（レジストラ）に登録。信頼チェーンの起点。 お客様（レジストラ側） ⚠️ 手動登録 KSKローテーション時に更新必須
✍️ RRSIG 各DNSレコードに付与されるデジタル署名レコード。 Route 53が自動生成 ✅ 自動 透過的に処理
🚫 NSEC/NSEC3 「このレコードは存在しない」ことを証明する否定応答レコード。 Route 53が自動管理 ✅ 自動 ゾーン列挙リスクに注意

🎯 まとめ — DNSSECを正しく実装するための3原則

🔐 セキュリティ原則

DNSSECはキャッシュポイズニングとDNSスプーフィングをデジタル署名で防ぐ。Route 53ではZSK自動ローテーションとKMS統合KSKで管理負荷を最小化できる。

⚙️ 実装の鉄則

KMSキーはus-east-1に作成。DSレコードのレジストラ登録は必ず手動で実施。KSKローテーション時は新DSの伝播確認後に旧DSを削除すること。

📊 監視の要点

CloudWatchの「DNSSECKeySigningKeysNeedingAction」メトリクスで期限切れを検知。90日前・30日前・7日前のアラートを設定し、障害を事前防止する。

📚 AWS Route 53 Developer Guide — Configuring DNSSEC signing  |  作成: Claude × AWS 初心者学習プロジェクト

Created by SSuzuki1063

AWS SAP Learning Resources