杉村です。 Amazon Route 53 Resolver DNS Firewall for Amazon VPC (以下、 DNS Firewall )について詳細な解説と、検証作業を行いました。なお 2021/04/01時点で東京リージョンには未リリースのためご注意ください。 → 2021/04/07 に東京リージョンを含む他の商用リージョン等で利用可能になりました。
関連記事 aws.amazon.com
1. 概要
何ができるの?
Route 53 Resolver (別名 Amazon Provided DNS )に対するDNSクエリを精査 して、特定のドメイン名に対するクエリをブロックすることなどができます。
ユーザが独自にドメイン名のリストを定義できるほか、AWSが提供するマネージドなリストも利用できます。現在のところAWSからは以下が提供されています(2021/04/01時点)。
- AWSManagedDomainsMalwareDomainList (既知のマルウェアの通信先ドメインのリスト)
- AWSManagedDomainsBotnetCommandandControl (既知のボットネットの Command & Control サーバのドメインのリスト)
Route 53 Resolver って?
ここで言う Route 53 Resolver とは VPC の CIDR の第4オクテット .2
に存在する仮想的な DNS サーバ(リゾルバ)のことです。「 Amazon Provided DNS 」や「 .2 resolver 」のように呼ばれることもあります(前者の方が耳なじみがある人も多いかもしれません)。 EC2 インスタンスは、デフォルトでこの Route 53 Resolver を使うように設定されています。
何が嬉しいの?
EC2 インスタンスや WorkSpaces (※1) からの DNS リクエストを精査することで「意図しない通信先への通信」「マルウェアによるデータ漏洩」「ボットネットによる悪さ」などのリスクを低減できることが期待できます。
従来はこういった機能を実装するには、DNSサーバ(リゾルバ)を独自で構築したり、インラインの仮想アプライアンスを利用する必要がありました。これが AWS のマネージドな Route 53 Resolver で実現できることになります。
※1 WorkSpaces の DNS クエリを精査するには WorkSpaces が所属する AD の DNS に条件付きフォワーダーを設定して Route 53 Resolver に向けるなどの工夫が必要です
AWS Firewall Manager との統合
AWS Firewall Manager と統合して Organization 内の AWS アカウントに跨って設定を管理することができます。
2. 詳説
構成図
当機能を利用した場合の構成図です。

192.168.0.0/16 という VPC があるとして、この中に EC2 インスタンスを構築すると、デフォルトで DNS の向き先は DNS Resolver (192.168.0.2)になっています。
DNS Firewall を設定して VPC に紐づけると、図のように DNS リクエストを精査し、設定に応じて許可/ブロック/アラートのいずれかの動作を取ってくれます。
許可の動作は、通常通りレスポンスを返します。
ブロックは、以下のいずれかの挙動の中から選択して設定できます。
- NODATA を返す (ドメインが存在しないことを表す)
- NXDOMAIN を返す (Non-existent domain 。そのドメインに指定のタイプのレコードが存在しないことを表す)
- OVERRIDE する (上書き。任意のレスポンスを返せます。ただし返せるのは CNAME レコードに限ります)
アラートは許可と同様にレスポンスを返したうえで Route 53 Resolver log 機能により CloudWatch Logs / S3 / Kinesis Data Firehose のいずれかにアラートを記録します。
参考: Rule actions in DNS Firewall - Amazon Route 53
DNS Firewall の設定の構成要素
DNS Firewall の設定は、以下の図のような構成となっています。

まずは Domain list から作成するのがよいでしょう。 許可あるいはブロックしたいドメイン名のリストを作ります。
そして Rule group を作ります。その後 Rule group に Rule を追加していきます。 Rule では「どのドメインリストを使うか」「そのドメインリストに該当した場合、Allow/Block/Alertのどの挙動を行うか」を設定します。 AWS Managed の Domain list を使うこともできます。
3. 検証
検証内容
以下のような検証をしてみます。
- VPC 内の EC2 インスタンスからの DNS クエリを対象とする
- www.google.com への DNS クエリはシンクホール(※2)へ転送するよう DNS Firewall で設定する
※2 いわゆる "シンクホール" とはマルウェア等の活動を監視する目的で設置するダミーホストとお考え下さい

下準備
- us-east-1 リージョンで VPC を作成し Amazon Linux 2 のインスタンスを構築(図の
クライアント
の役割) - もう1台、同じように EC2 インスタンスを構築(図の
シンクホール
の役割)。 Apache をインストールして警告文を表示する index.html を配置 - Route 53 で Private Hosted Zone を作成。 www.swx.example という A レコードを登録。このレコードは先ほどの2台目の EC2 インスタンスの Private IP アドレスを返すようにします。この Private Hosted Zone を VPC に紐づけます
DNS Firewall 設定
まず、ドメインリストを作成します。
マネジメントコンソールで Route 53 の画面に遷移します。左側メニューから ▼DNS ファイアウォール
の下の ドメインリスト
を選択します。ボタン Add domain list を押下してドメインリストを作ります。
以下のように www.google.com. だけを登録したリストを作成しました(末尾のドットは自動的に付与されます)。

次にルールグループを作成します。
左部メニューから Rule groups を選択します。ボタン Add rule group
を押下します。ルールグループ名を入力したり、ルールを定義したりしていきます。今回、以下のようなルールを定義しました。

対象のドメインリストは test-domain-list
です。これには先ほど作った通り www.google.com.
だけが登録されています。
このドメインリストに対して Action は BLOCK を選択しています。 BLOCK の挙動として OVERRIDE が選択されており、このリストのドメインへのクエリがあった場合は www.swx.example.
(CNAMEレコード) に書き換えてレスポンスするように設定しました。
なお、ルールグループには今回、上記の1ルールだけを登録します。ルールグループ内に複数ルールを登録する際の優先順位付けは、よくあるファイヤウォールのルール設定に似ています。ルールには優先順位(以下画像の Priority
)をつけることができ、ルールに該当するとそこで評価が終了します。

次に、このルールグループを VPC と紐づけます。
VPCs associated タブを選択し、ボタン Associate VPC を押下します。紐づける対象VPCを選択して紐づけます。紐づけには数分かかります。 Status が UPDATING から COMPLETED になれば完了です。

動作確認
クライアントの役割の EC2 インスタンスにログインして、 curl を打ってみます。 www.google.com にリクエストしたはずなのに、シンクホールから警告文のレスポンスが返ってきました。

nslookup コマンドでも確認してみます。 他のドメイン名に対する nslookup は普段通りに行われていますが www.google.com に対するクエリには www.swx.example の Private IP が返ってきています。


4. 利用料金
DNS Firewall の利用には料金がかかります。「ユーザー定義のドメインリストに登録したドメインの数」と「精査したクエリの数」に対する従量課金です。
参考: Amazon Route 53 pricing - Amazon Web Services
※ 2021/04/01 現在で英語版にしないと Route 53 Resolver DNS Firewall の料金が表示されません
杉村 勇馬 (記事一覧)
サーバーワークス → 株式会社G-gen 執行役員CTO
2021 Japan APN Ambassadors / 2021 APN All AWS Certifications Engineers
マルチAWSアカウント管理運用やネットワーク関係のAWSサービスに関するブログ記事を過去に執筆。
2021年09月から株式会社G-genに出向、Google Cloud(GCP)が専門に。G-genでもGoogle Cloud (GCP) の技術ブログを執筆中。