VPC の .2 リゾルバの正体 - AWS 内部 DNS と Route 53 Resolver の関係
VPC 内の DNS リゾルバ (CIDR+2 アドレス) が何者なのか、プライベートホストゾーンとの連携、Route 53 Resolver エンドポイントによるハイブリッド DNS、DNS クエリログの活用方法を解説します。
VPC の CIDR+2 アドレスに何がいるのか
VPC を作成すると、CIDR ブロックの 2 番目のアドレス (10.0.0.0/16 なら 10.0.0.2) が DNS リゾルバとして予約されます。EC2 インスタンスの /etc/resolv.conf を確認すると、nameserver にこのアドレスが設定されています。この .2 リゾルバは、Route 53 Resolver と呼ばれる AWS のマネージド DNS サービスです。インスタンスからの DNS クエリは、この .2 リゾルバに送信され、Route 53 Resolver が名前解決を行います。Route 53 Resolver は、クエリの内容に応じて異なる処理を行います。VPC に関連付けられたプライベートホストゾーンのドメインであれば、プライベートホストゾーンのレコードを返します。AWS 内部のサービスエンドポイント (ec2.ap-northeast-1.amazonaws.com など) であれば、AWS の内部 DNS で解決します。それ以外のドメインであれば、パブリック DNS (Route 53 のパブリックホストゾーンまたはインターネットの DNS) で解決します。この振り分けは自動的に行われ、ユーザーが設定する必要はありません。
プライベートホストゾーン - VPC 内だけで有効な DNS
Route 53 のプライベートホストゾーンは、VPC 内からのみ解決可能な DNS ゾーンです。たとえば、internal.example.com というプライベートホストゾーンを作成し、api.internal.example.com を 10.0.1.100 に解決するレコードを設定すると、VPC 内のインスタンスからは api.internal.example.com で内部サービスにアクセスできますが、インターネットからは解決できません。プライベートホストゾーンは複数の VPC に関連付けることができます。開発 VPC、ステージング VPC、本番 VPC のすべてに同じプライベートホストゾーンを関連付ければ、環境間で統一された内部 DNS 名を使用できます。ただし、各環境で異なる IP アドレスに解決したい場合は、環境ごとに別のプライベートホストゾーンを作成する必要があります。プライベートホストゾーンの興味深い特性は、パブリックホストゾーンと同じドメイン名を使用できることです。example.com のパブリックホストゾーンとプライベートホストゾーンが両方存在する場合、VPC 内からのクエリはプライベートホストゾーンが優先されます。これを「スプリットホライズン DNS」と呼びます。
Route 53 Resolver エンドポイント - ハイブリッド DNS の実現
オンプレミスネットワークと VPC を Direct Connect や VPN で接続している場合、DNS の名前解決が課題になります。オンプレミスのサーバーから VPC 内のプライベートホストゾーンのドメインを解決したい、逆に VPC 内のインスタンスからオンプレミスの Active Directory ドメインを解決したい、というニーズです。Route 53 Resolver エンドポイントは、この課題を解決します。インバウンドエンドポイントは、オンプレミスの DNS サーバーからのクエリを受け付け、VPC の .2 リゾルバに転送します。オンプレミスの DNS サーバーに、VPC のプライベートドメインの条件付きフォワーダーを設定し、転送先をインバウンドエンドポイントの IP アドレスにします。アウトバウンドエンドポイントは、VPC 内からのクエリをオンプレミスの DNS サーバーに転送します。Route 53 Resolver ルールで、特定のドメイン (例: corp.internal) のクエリをオンプレミスの DNS サーバーに転送するよう設定します。エンドポイントは各 AZ に ENI を作成するため、マルチ AZ の冗長性が確保されます。料金は ENI 1 つあたり 1 時間 0.125 USD + DNS クエリ 100 万件あたり 0.40 USD です。
DNS クエリログ - VPC 内の DNS 活動を可視化する
Route 53 Resolver の DNS クエリログは、VPC 内のすべての DNS クエリを記録する機能です。どのインスタンスが、いつ、どのドメインを解決しようとしたかが記録されます。セキュリティの観点で、DNS クエリログは極めて有用です。マルウェアは C2 (Command and Control) サーバーとの通信に DNS を使用することがあります (DNS トンネリング)。DNS クエリログを分析すれば、不審なドメインへのクエリを検出できます。たとえば、ランダムな文字列のサブドメイン (a1b2c3d4.evil.com) への大量のクエリは、DNS トンネリングの兆候です。クエリログの送信先は、CloudWatch Logs、S3、Kinesis Data Firehose の 3 つから選択できます。リアルタイムの分析には CloudWatch Logs、長期保存と大規模分析には S3 + Athena、ストリーミング分析には Kinesis が適しています。GuardDuty は DNS クエリログを自動的に分析し、暗号通貨マイニング、C2 通信、データ流出などの脅威を検出します。GuardDuty を有効にしていれば、DNS クエリログを手動で分析する必要はほとんどありません。
DNS の落とし穴 - enableDnsSupport と enableDnsHostnames
VPC には DNS に関する 2 つの設定があり、これらの設定を誤ると DNS 解決が機能しません。enableDnsSupport (デフォルト: true) は、VPC の .2 リゾルバを有効にする設定です。false にすると、VPC 内のインスタンスは .2 リゾルバを使用できなくなり、カスタム DNS サーバーを設定しない限り名前解決ができません。enableDnsHostnames (デフォルト: false、デフォルト VPC では true) は、パブリック IP アドレスを持つインスタンスに自動的に DNS ホスト名 (ec2-1-2-3-4.compute-1.amazonaws.com) を割り当てる設定です。この設定が false の場合、プライベートホストゾーンの関連付けが機能しません。プライベートホストゾーンを使用するには、enableDnsSupport と enableDnsHostnames の両方が true である必要があります。もう一つの落とし穴は、DHCP オプションセットです。VPC のインスタンスに配布される DNS サーバーのアドレスは、DHCP オプションセットで制御されます。カスタム DHCP オプションセットで DNS サーバーをオンプレミスの DNS に変更すると、.2 リゾルバが使用されなくなり、プライベートホストゾーンが解決できなくなります。VPC の DNS 設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。