- 公開日
- 最終更新日
DNS Firewall で許可済みのドメインへ通信できない場合の対処法
この記事を共有する
目次
はじめに
こんにちは！パーソル＆サーバーワークスの野間です。
先日 Route 53 Resolver DNS Firewall (以下、DNS Firewall) で許可済みのドメインへ通信ができない事象に遭遇しました。
本記事では、DNS Firewall の「信頼ドメインリダイレクト」機能を中心に、許可済みのドメインへ通信ができない場合の対処法をご紹介します。
なにが起きた？
DNS Firewall で「record-a」と「record-b」というドメインを許可リストに登録し、それ以外のドメインは全てブロックという設定をしていました。
ところが、「record-b」のみ DNS Firewall によってブロックされて通信が行えませんでした。
調査すると、許可されているドメインの片方は A レコードで直接解決される一方、もう片方は CNAME で別名にリダイレクトされていました。
そのリダイレクト先が許可リストに含まれていなかったことが原因で、DNS Firewall によりブロックされていたようです。
DNS Firewall と信頼ドメインリダイレクトについて
DNS Firewallは、Amazon Route 53 Resolverと連携してVPCからのDNSクエリを検査・制御できるサービスです。
詳しくは過去記事「DNS Firewallを活用してVPCのDNSアクセス制御を強化する」をご参照ください。
DNS Firewall のドメインリダイレクト設定は、以下 2 通りが存在します。
- すべて検査（デフォルト）：DNS リダイレクトチェーン内のすべてのドメインを検査する
- 信頼ドメインリダイレクト：最初に問い合わせたドメインのみ検査し、後続は信頼する
後者を使うと、許可リストは起点ドメインの登録だけで運用でき、チェーン先（CNAME/DNAME の解決先）まで個別に許可をする必要がなくなります。
試してみる
DNS レコードの設定
以下 4 つのDNS レコードを設定しました。
「record-c」は名前解決先が許可リストに含まれていないため、信頼ドメインリダイレクト設定を有効にしないと名前解決できない想定です。
DNS Firewall の準備
以下 CloudFormation テンプレートを使ってDNS Firewall を構築しました。
DomainListAllow:
Type: AWS::Route53Resolver::FirewallDomainList
Properties:
Domains:
- !Ref AllowList01 # 許可するFQDN
- !Ref AllowList02
- !Ref AllowList03
Name: AllowList
DomainListBlock:
Type: AWS::Route53Resolver::FirewallDomainList
Properties:
Domains:
- "*" # AllowList以外はすべてブロック
Name: BlockAll
RuleGroup:
Type: AWS::Route53Resolver::FirewallRuleGroup
Properties:
Name: AllowOnlySpecificDomain
FirewallRules:
- Action: ALLOW
FirewallDomainListId: !Ref DomainListAllow
Priority: 1
# FirewallDomainRedirectionAction: TRUST_REDIRECTION_DOMAIN
# 信頼ドメインリダイレクト設定(初回はコメントアウト状態でテスト実施)
- Action: BLOCK
FirewallDomainListId: !Ref DomainListBlock
Priority: 2
BlockResponse: NODATA
RuleGroupAssociation:
Type: AWS::Route53Resolver::FirewallRuleGroupAssociation
Properties:
FirewallRuleGroupId: !Ref RuleGroup
Priority: 200
VpcId: !Ref VpcId # DNS Firewallを紐づけるVPC
Name: associatewithvpcテスト結果
ドメインリダイレクト設定：すべて検査
record-a：許可
$ nslookup record-a.test-pswtraining.click
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: record-a.test-pswtraining.click
Address: 46.51.246.122
record-b：許可（record-b → CNAME → record-a。どちらも許可のため通過）
$ nslookup record-b.test-pswtraining.click
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
record-b.test-pswtraining.click canonical name = record-a.test-pswtraining.click.
Name: record-a.test-pswtraining.click
Address: 46.51.246.122
record-c：拒否（CNAME 先の record-d が未許可のためブロック）
$ nslookup record-c.test-pswtraining.click
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
record-c.test-pswtraining.click canonical name = record-d.test-pswtraining.click.
record-c：拒否（想定通り）
$ nslookup record-d.test-pswtraining.click
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
* Can't find record-d.test-pswtraining.click: No answer
ドメインリダイレクト設定：信頼ドメインリダイレクト
record-c：許可（起点の record-c を許可すれば、CNAME 先は信頼される）
$ nslookup record-c.test-pswtraining.click
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
record-c.test-pswtraining.click canonical name = record-d.test-pswtraining.click.
Name: record-d.test-pswtraining.click
Address: 46.51.246.122
record-d：拒否
許可リストに含めていませんが、record-c を名前解決した直後は DNS キャッシュの影響で一時的に応答がありました。
一定時間後に再確認すると、想定どおりブロックされます。
$ nslookup record-d.test-pswtraining.click
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: record-d.test-pswtraining.click
Address: 46.51.246.122
<<時間をあけて再度実行>>
$ nslookup record-d.test-pswtraining.click
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
* Can't find record-d.test-pswtraining.click: No answer
おわりに
信頼ドメインリダイレクト設定を行うことで、DNS Firewall の許可リストがより簡潔になるため、積極的に利用したいと感じました。
また、DNS リダイレクトチェーン先の CNAME レコードが変更された場合でも、許可リストの変更をせずに運用が可能です。
同じような事象に遭遇した方の参考になれば幸いです！
この記事は私が書きました
野間 太一
記事一覧猫とCloudFormationが好きです。
