DNS Firewall を使ったら Simple AD のステータスが「障害」に？

必要な DNS クエリまで DNS Firewall でブロックしないでね！

#AWS Directory Service

#Amazon Route 53

#AWS

まさを

2021.04.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさま Xin chao !

先日リリースされた、Amazon Route 53 Resolver DNS Firewall を試していたところ、いや、正確には試そうと準備していたところ、ちょっとした困った状況に遭遇しました。自分以外の方々が同じ苦労をしなくて済むよう、起こったことと、それを回避した方法を書き残しておきたいと思います。

Simple AD のステータスが「障害」になる

検証環境

試そうとしていたのは、以下のような環境です。本ブログ執筆時点においては、まだ DNS Firewall を東京リージョンで利用できなかったため、バージニア北部リージョン (us-east-1) を使用しています。

DNS Forewall を使って、指定したドメイン (*.classmethod.jp) に対してのみ WorkSpaces から Web 閲覧ができるようにしたかったので、以下のように DNS Firewall のルールグループ、および、ドメインリストを設定しました。

経緯

単純に、Amazon WorkSpaces ＋ DNS Firewall で簡易的な Web フィルタリングみたいなことを試してみようと思い、Simple AD と WorkSpace をデプロイしました。デプロイには多少時間を要するので、並行して DNS Firewall の設定もいろいろ試していました。

準備が整い、いざ WorkSpaces クライアントを使って WorkSpace に接続しようとしたところ、"サーバーエラー" に。

ユーザー名・パスワードが間違っている場合であれば "認証が失敗しました" と表示されるので、何が原因だろうと Simple AD の状況を確認すると、ステータスが「障害」に。

AWS CLI を使って Simple AD の状況を確認すると、直前に Simple AD のステータス変化があったことが分かりました。

$ aws ds describe-directories --directory-id "d-9XXXXXXXX6"
{
    "DirectoryDescriptions": [
        {
            "DirectoryId": "d-9XXXXXXXX6",
            "Name": "masawo.test",
            "ShortName": "MASAWO",
            "Size": "Small",
            "Alias": "d-9XXXXXXXX6",
            "AccessUrl": "d-9XXXXXXXX6.awsapps.com",
            "Description": "Simple AD",
            "DnsIpAddrs": [
                "10.0.12.60",
                "10.0.11.34"
            ],
            "Stage": "Impaired",
            "LaunchTime": "2021-04-01T14:30:29.770000+09:00",
            "StageLastUpdatedDateTime": "2021-04-07T11:27:47.751000+09:00",
            "Type": "SimpleAD",
            "VpcSettings": {
                "VpcId": "vpc-0XXXXXXXXXXXXXXXc",
                "SubnetIds": [
                    "subnet-0XXXXXXXXXXXXXXXe",
                    "subnet-0XXXXXXXXXXXXXXXd"
                ],
                "SecurityGroupId": "sg-0XXXXXXXXXXXXXXXb",
                "AvailabilityZones": [
                    "us-east-1a",
                    "us-east-1c"
                ]
            },
            "StageReason": "Issue(s) detected by instance 10.0.12.60. Issue(s) detected by instance 10.0.11.34. ",
            "SsoEnabled": false,
            "DesiredNumberOfDomainControllers": 0
        }
    ]
}

今回のように WorkSpaces に登録されているディレクトリの場合、AWS マネジメントコンソールでもステータスの最終更新日時を確認することができます。

サクッと試してみるだけの予定だったのに思わぬ事態に遭遇したことで慌ててしまい、無計画にいろいろ試行錯誤していると、Simple AD のステータスが「アクティブ」に戻っていることに気づきました (←悪いトラブルシューティングのやり方そのままですね...)。

この時点では以下のドキュメントにあるように、時間が解決してくれたのかな？と何の根拠もなく胸をなでおろしていました。

For normal maintenance related issues, AWS resolves these issues within 40 minutes. If after reviewing the troubleshooting topic, your directory is in an Impaired state longer than 40 minutes, we recommend that you contact the AWS Support Center.

(参考日本語訳)

問題に関する通常のメンテナンスにおいては、AWS は 40 分以内にこれらの問題を解決します。トラブルシューティングのトピックを確認した後、ディレクトリが 40 分以上にわたって障害状態にある場合は、AWS サポートセンターに問い合わせることをお勧めします。

(Understanding your directory status | AWS Directory Service Administration Guide より抜粋)

しかし平穏な状態は長くは続きませんでした。 Simple AD のステータスのことなど忘れて環境を整えていたところ、再度 Simple AD のステータスが「障害」に。いくらなんでも Simple AD がこんな簡単に「障害」になるはずがないと、この時になってようやくトラブルシューティングのトピックを確認したり、自分の胸に手を当てて Simple AD のステータスが「障害」になった際に与えた変化点を思い出してみました。

原因は DNS クエリのブロック

「障害」になるきっかけは DNS Firewall の関連付けだった

Simple AD がデプロイされている VPC に DNS Firewall のルールグループを関連付けると、その後少し (＝15～20 分ほど) 経って Simple AD のステータスが「障害」に変わることに気づきました。そして関連付けを解除すると、しばらくして (＝15～20 分ほど) ステータスが「アクティブ」に戻ります。再現性は 100% です。

DNS Firewall のルールグループを VPC に関連付けすると Simple AD のステータスが「障害」になるということは、DNS Firewall によって DNS クエリがブロックされていることが原因であることが濃厚です。

ブロックされている DNS クエリを確認

あらかじめ CloudWatch Logs に記録されるように設定しておいた Route 53 Resolver の DNS クエリログを確認してみます。 DNS クエリログについては、以下のブログをご参照ください。

WorkSpace は停止させているため、この時点で VPC 内で起動しているサービスは Simple AD のみの状態ですが、その Simple AD の IP アドレスからいくつかの DNS クエリが行われ、そして見事に (＝設定どおりに) DNS Firewall により DNS クエリがブロックされている (＝名前解決ができない) ことが分かりました。

確認した限りでは上記も含め、以下のような DNS クエリが Simple AD の IP アドレスより試みられ、そしてブロックされていました。見覚えのあるドメインがいくつか並んでいますね (参考 : Service endpoints and quotas | AWS General Reference Reference guide Version 1.0 (PDF))。

ec2messages.us-east-1.amazonaws.com.
monitoring.amazonaws.com.
monitoring.us-east-1.amazonaws.com.
monitor-api-public-iad.amazon.com.
ssm.us-east-1.amazonaws.com.
aatb.us-east-1.amazonaws.com.

回避策

DNS Firewall のドメインリスト "AWSDomains" を新規作成し、Simple AD から DNS クエリが行われていた前述のドメインを登録しました。そして、VPC に関連付けしている DNS Firewall のルールグループに Priority 1 のルール "AllowAWSDomains" として、ドメインリスト "AWSDomains" への DNS クエリを許可するように追加しました。

上記設定後、しばらくすると (＝15～20 分ほど) Simple AD のステータスが「アクティブ」に戻りました。

これでやっと DNS Firewall を試すことができるようになりました！ (ここまで長かった...)

おわりに

ちょっとだけ DNS Firewall を試すつもりが、その検証環境を整えるのに苦労してしまいました。

Web プロキシによるフィルタリングとは異なり、DNS Firewall では Route 53 Resolver (＝旧称・Amazon Provided DNS) に対する DNS クエリのすべてに対して作用してしまうため、安易に許可リスト運用を試みるとこのようなハマり方をする、という例になったのではないかと思います。

また、今回は新規に構築した検証環境だったため、最初から DNS Firewall のアクションを "BLOCK" にしていましたが、既存の環境、特に本番環境に後から DNS Firewall を適用する際は、まずは "ALERT" で始めて、ちゃんと Route 53 Resolver の DNS クエリログで該当する DNS クエリを確認することが大事だと、あらためて肝に銘じました。

なお、最近では「色の名前＋リスト」ではなく、「許可リスト」という呼び方をするということを、この記事を書き始めてから知りました。