[アップデート]Route 53 Resolver DNS Firewallが再帰的な名前解決上のドメインを信頼し自動的に許可できる設定が追加されました

初めに

5/1と少し前のアップデートになりますがRoute 53 Rsolver DNS Firewall(以降DNS Firewall)がCNAMEレコード等で再帰的な名前解決を行う場合にそのチェーン上のドメインを自動的に信頼し許可する設定ができるようになりました。

従来DNS Firewallで全てのドメイン(*.)をBLOCKするルールを最後に構えるようなホワイトリスト形式を採用している場合、CNAMEやAliasを割り当てられているレコードの解決にはそれら全てのドメインに対して許可を与える必要がありました。

例えばhoge.example.comにCNAMEとしてxxx.cloudfront.netが割り当てられている場合これら2つのドメインに対する許可が必要となります。

CNAMEレコードはSaaS等のサービスではユーザ側の変更負荷を減らすためにサービスバックエンドのエンドポイントを直接ではなくそれをCNAMEで割り当てたドメインを渡すような場合もあります。 多くの場合バックエンドのエンドポイントの変更は影響のない場合が多いので稀に告知なく変更されるようなサービスもありますが、名前解決の制限をかけている環境では許可リストから外れてしまいIPが得られず通信ができなくなってしまう可能性があります。

今回のアップデートでは再帰的な名前解決の親となるドメインに対して「信頼リダイレクトドメイン」を設定することにより、名前解決の起点となるドメインへの許可のみでそれれ以降のチェーン上のドメインに対する個別の許可が必要なくなり自動的に許可を行うことが可能となりました。

試してみる

今回検証に利用するドメインとしてとして以下のようにCloudFrontのCNAMEを割り当てたものを用意しておきます。example.comは実際には私の保持する別のドメインを利用しています。

 % dig dns-firewall-test.example.com CNAME
...
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
dns-firewall-test.example.com. 300 IN	CNAME	d3lw504xxxxxx.cloudfront.net.

% dig dns-firewall-test.example.com
...
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
dns-firewall-test.example.com. 300 IN	CNAME	d3lw504xxxxxx.cloudfront.net.
d3lw504xxxxxx.cloudfront.net. 60 IN	A	18.65.141.179
d3lw504xxxxxx.cloudfront.net. 60 IN	A	18.65.141.16
d3lw504xxxxxx.cloudfront.net. 60 IN	A	18.65.141.109
d3lw504xxxxxx.cloudfront.net. 60 IN	A	18.65.141.99

従来の設定(全て検査)

これに対して以下相当となるようにルールグループを作成し割り当てます(実際にはドメインはドメインリストを経由で割り当てます)。BLOCKのレスポンスはNODATAとなるように設定してます。

この場合は.netドメイン(*.net)に対するTXTレコードの解決は許可されていないため以下のようにCloudFrontのCNAME名までは解決されますが、その先は取得することができません。

## 先ほどと違いCNAMEの取得までしか解決してくれない(厳密にはcloudfrontドメインもしてると思うがNODATAなので表示はない)
$ dig dns-firewall-test.example.com
...
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
dns-firewall-test.example.com. 300 IN CNAME   d3lw504xxxxxx.cloudfront.net.

## 単品で確認してもBLOCKしているため当然NODATAとなる
$ dig dd3lw504xxxxxx.cloudfront.net
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;d3lw504xxxxxx.cloudfront.net. IN      A

今回追加された設定を利用(信頼リダイレクトドメイン)

*.example.comの設定を信頼リダイレクトドメインにします。

設定はルールの設定から可能で作成後にも変更可能です。

CloudFrontドメインに対して直接名前解決を行うと拒否している*.netドメインの結果を得ることができており、再帰的な名前解決は暗黙的に許可されていることが確認できます。

$ dig dns-firewall-test.example.com
.....
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
dns-firewall-test.example.com. 176 IN CNAME   d3lw504xxxxxx.cloudfront.net.
d3lw504xxxxxx.cloudfront.net. 59 IN    A       18.65.199.166
d3lw504xxxxxx.cloudfront.net. 59 IN    A       18.65.199.193
d3lw504xxxxxx.cloudfront.net. 59 IN    A       18.65.199.129
d3lw504xxxxxx.cloudfront.net. 59 IN    A       18.65.199.98

上記の実行後キャッシュが残っている間にCloudFrontドメインに直接で名前解決を行うと先ほどのキャッシュが残っている間はデータを取得することが可能ですが、TTL経過でキャッシュを利用しなくなったタイミングで結果が得られなくなります。

$ dig d3lw504xxxxxx.cloudfront.net
...
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
d3lw504xxxxxx.cloudfront.net. 49 IN    A       18.65.199.129
d3lw504xxxxxx.cloudfront.net. 49 IN    A       18.65.199.98
d3lw504xxxxxx.cloudfront.net. 49 IN    A       18.65.199.166
d3lw504xxxxxx.cloudfront.net. 49 IN    A       18.65.199.193

## TTL経過後に再実行
$ dig d3lw504xxxxxx.cloudfront.net
...
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;d3lw504xxxxxx.cloudfront.net. IN      A

終わりに

再帰的な名前解決内であれば自動的に許可される(スキップされるが正確?)なのでCNAMEやAliasの指定先の値が変わっても都度許可が不要となり、うまく活用することでルール数の削減による見通しの良さ、追加・削除の手間の削減が狙えそうです。

従来通り再帰的に行われる名前解決の許可を自動的に許可せずに個別に許可する形をルール単位設定できますので、信頼度合(社内・外システム等)からこのドメインは再帰的な解決を信頼するけどこのドメインは従来通り全て指定するという形にするのも良いでしょう。

余談

再帰的な名前解決を行った場合のリゾルバからクライアントへのレスポンスどうなってるのか気にしたことなかったのですが、digのANSWER SECTIONの見た目通り1パケットで来ることを実は今更知りました(クエリ・レスポンス構造やUDPの特性を考えると分割すると連結処理が...というのもあるので冷静に考えると確かにとは)。