📌 まず押さえるべき3つのポイント
VPC内のリソースが外部ドメインへDNSクエリを行う際、ルールに基づいて許可・ブロック・アラートを行う「DNS版セキュリティゲート」です。
Firewallが障害で応答できないとき、DNSクエリをそのまま通す設定。可用性を優先し、サービスを止めない方針です。
Firewallが障害で応答できないとき、DNSクエリをブロックする設定。セキュリティを優先し、未検査の通信を許さない方針です。
🌐 セクション1：DNS Firewallとは？
🏢 たとえ話：オフィスビルの受付カウンター
あなたのオフィスビル（VPC）の受付カウンター（DNS Firewall）を想像してください。 社員（EC2やLambda）が外部の会社（インターネット上のドメイン）に電話をかけたいとき、 まず受付に「○○社に電話したい」と申し出ます。受付は許可リストを確認し、 許可された相手には電話をつなぎ、拒否リストにある怪しい相手への電話はブロックします。 これがDNS Firewallの仕組みです。
(EC2, Lambda等) DNSクエリ送信
(ルール評価) ルールに基づき判定
Resolver
(名前解決) 許可されたクエリのみ
(インターネット) 名前解決実行
DNS Firewallの主な機能
📋 ドメインフィルタリング
特定のドメインに対するDNSクエリを許可またはブロックするルールを作成。悪意あるドメインやデータ流出先へのアクセスを防止します。
📁 ルールグループ
複数のルールをグループ化して一貫したポリシーを適用。ルールグループは複数のVPCに関連付けでき、組織全体で統一したDNSセキュリティポリシーを展開できます。
⚡ アクション設定
マッチしたクエリに対して「ALLOW（許可）」「BLOCK（ブロック）」「ALERT（アラート）」のアクションを設定。BLOCKではカスタム応答（NODATA/NXDOMAIN/OVERRIDE）も選択可能です。
📊 ログ記録と監視
DNSクエリのログをCloudWatch Logs、S3、Kinesis Data Firehoseに記録して分析。ブロック・アラートされたクエリを可視化し、セキュリティ運用に活用できます。
📁 セクション2：ルールグループの仕組み
📖 たとえ話：受付の「チェックリストファイル」
ルールグループは、受付カウンターに置かれたチェックリストファイルのようなものです。 1つのファイルに「許可する会社リスト」「拒否する会社リスト」が書かれており、 受付はこのファイルを上から順番に確認します。最初にマッチしたルールが適用され、 どのルールにもマッチしなければ、次のファイル（次の優先度のルールグループ）を確認します。
🔴 ルールグループ①（優先度: 100）
🟢 ルールグループ②（優先度: 200）
🔀 セクション3：フェイルオープン vs フェイルクローズ
🚪 たとえ話：オフィスの自動ドアが故障したら？
オフィスの入口にはセキュリティゲート（自動ドア）があります。
このゲートが停電で動かなくなったとき、2つの選択肢があります。
フェイルオープン＝ドアを開けっ放しにして、全員が通れるようにする（業務が止まらない）
フェイルクローズ＝ドアをロックして、誰も通れないようにする（不審者の侵入を防ぐ）
どちらが正しいかは、「可用性」と「セキュリティ」どちらを優先するかで決まります。
🟢 フェイルオープン
Fail OpenDNS Firewallが応答しない場合、DNSクエリはフィルタリングなしで通常通り処理されます。 Firewallの障害によってサービス全体が停止することを防ぎます。
📡 可用性を優先🔴 フェイルクローズ
Fail CloseDNS Firewallが応答しない場合、DNSクエリはブロックされ名前解決が失敗します。 Firewallが未検査のまま通信が行われるリスクを排除します。
🔒 セキュリティを優先🟢 フェイルオープン
メリット：業務が止まらない
リスク：セキュリティチェックなしで通過してしまう可能性がある
🔴 フェイルクローズ
メリット：未チェックの人が入れない
リスク：正規の社員も入れず業務が停止する可能性がある
🟢 フェイルオープンの動作フロー
🔴 フェイルクローズの動作フロー
| 比較項目 | 🟢 フェイルオープン | 🔴 フェイルクローズ |
|---|---|---|
| 障害時の動作 | DNSクエリをそのまま通過させる | DNSクエリをブロック（SERVFAIL） |
| 優先する価値 | 可用性（Availability） | セキュリティ（Security） |
| サービス影響 | なし（通信は継続） | あり（DNS依存のサービスが停止） |
| セキュリティリスク | 未検査のDNSクエリが通過する可能性 | 最小（フィルタ未通過の通信なし） |
| 適切な場面 | 一般的なWebサービス、可用性重視の環境 | 金融、医療、政府機関など高セキュリティ環境 |
| AWSデフォルト | ✅ デフォルト設定 | 明示的に設定が必要 |
🎯 セクション4：ユースケースと選択基準
未検査トラフィックは許容不可
ビジネスに重大な影響を与えるか？
可用性を確保
安全側に倒す
業界別おすすめ設定
🛒 ECサイト・一般Webサービス
ユーザー体験とサービスの継続性が最優先。DNS障害でカート機能や商品ページが表示されなくなると、直接的な売上損失につながります。
🟢 フェイルオープン推奨🏦 金融サービス・決済システム
PCI-DSSなどの厳格なコンプライアンスが求められ、未検査のDNSクエリがデータ漏洩のリスクとなります。セキュリティが可用性に優先します。
🔴 フェイルクローズ推奨🏥 医療・ヘルスケア
HIPAA等の規制により患者データの保護が最優先。ただし生命に関わるシステムでは可用性も重要なため、システムごとに使い分けが必要です。
🔴 フェイルクローズ推奨（要件次第）🎮 ゲーム・メディア配信
リアルタイム性が求められるサービスでは、DNS障害によるサービス停止がユーザー離脱に直結。可用性を確保しつつ、ログ監視で補完します。
🟢 フェイルオープン推奨🏗️ セクション5：アーキテクチャと設定
AWS CLIでの設定例
# ドメインリストの作成（ブロック対象ドメイン） aws route53resolver create-firewall-domain-list \ --name "blocked-domains" \ --domains "malware-site.com" "phishing.example.com" # ルールグループの作成 aws route53resolver create-firewall-rule-group \ --name "my-security-rules" # ルールの追加（ブロックルール） aws route53resolver create-firewall-rule \ --firewall-rule-group-id "rslvr-frg-xxxxx" \ --firewall-domain-list-id "rslvr-fdl-xxxxx" \ --priority 100 \ --action "BLOCK" \ --block-response "NXDOMAIN" \ --name "block-malware"
# VPCとルールグループの関連付け（フェイルオープン） aws route53resolver associate-firewall-rule-group \ --firewall-rule-group-id "rslvr-frg-xxxxx" \ --vpc-id "vpc-xxxxx" \ --priority 100 \ --name "my-vpc-association" # フェイルオープン設定（デフォルト） aws route53resolver update-firewall-config \ --resource-id "vpc-xxxxx" \ --firewall-fail-open ENABLED # フェイルクローズ設定 aws route53resolver update-firewall-config \ --resource-id "vpc-xxxxx" \ --firewall-fail-open DISABLED
✅ セクション6：ベストプラクティス
📝 段階的なルール導入
最初はALERT（監視のみ）でルールを作成し、ログを分析してから本番BLOCKに切り替えましょう。いきなりブロックすると、正常な通信まで止めてしまうリスクがあります。
🔗 AWSマネージドドメインリスト活用
AWSが提供するマネージドドメインリスト（マルウェア、ボットネット C&C など）を活用すると、自分でリストを管理する手間を大幅に削減できます。
📊 CloudWatchアラーム設定
ブロックされたDNSクエリのメトリクスを監視し、異常増加を検知するアラームを設定しましょう。攻撃の兆候を早期に発見できます。
🏢 RAM で組織全体に共有
AWS RAM（Resource Access Manager）を使って、ルールグループを AWS Organizations 全体で共有できます。セキュリティポリシーの一元管理に有効です。