前置き
こんにちは。Google Pixel Fold に興味があるが、ポチるか迷い中のエンタープライズクラウド部技術２課の三好です。
さて、迷うと言えばVPCを設定するときに「VPC内のDNS属性」についてどう設定していいか迷ったことはないでしょうか？ 「VPC内のDNS属性」には「enableDnsHostnames」と「enableDnsSupport」の二つの属性があります。
それぞれの属性が何の設定であるのか、Amazon VPC ユーザーガイドの記載を以下に引用します。
| 属性 | 説明 |
|---|---|
| enableDnsHostnames | VPC がパブリック IP アドレスを持つインスタンスへのパブリック DNS ホスト名の割り当てをサポートするかどうかを決定します。 VPC がデフォルト VPC でない限り、この属性のデフォルトは false です。 |
| enableDnsSupport | VPC が Amazon 提供の DNS サーバーを介した DNS 解決策をサポートするかどうかを決定します。 この属性が true の場合、Amazon が提供した DNS サーバーへのクエリは成功します。詳細については、「Amazon DNS サーバー」を参照してください。 この属性のデフォルトは true です。 |
引用元： docs.aws.amazon.com
日本語のマネジメントコンソールでは「enableDNSHostnames」は「DNS ホスト名」、「enableDnsSupport」は「DNS 解決」という項目になっています。 本ブログでは以降、日本語マネジメントコンソールの表記でDNS属性を表記します。
「DNS 解決」の属性については、「VPC内のAWSリソースに対して、Route 53 Resolver *1によるフルサービスリゾルバー機能を提供する属性」であることは割とすんなり受け入れられました。 これは、この属性を無効化した時にVPC内のEC2インスタンスからRoute 53 Resolverに名前解決を実施しても、名前解決の回答が返ってこなくなるためです。
一方、「DNS ホスト名」という属性がいまいち腑に落ちませんでした。 この「DNS ホスト名」という属性は、ユーザーガイドの属性の説明通りに「パブリックIPアドレスを持つEC2インスタンスに対して、パブリックDNSホスト名を付与する」という属性であるとともに以下の設定の必須事項になっているからです。
- インターフェイス VPC エンドポイント (AWS PrivateLink) でプライベート DNS を使用する*2
- Amazon Route 53 のプライベートホストゾーンで定義されたカスタム DNS ドメイン名を使用する
上記の設定のためには、「DNS ホスト名」（と「DNS 解決」）を有効化しなければならないことが、Amazon VPC ユーザーガイドの「VPC 内の DNS 属性」 の 「ルールと考慮事項」に明記されています。
ECインスタンスへのパブリックDNSホスト名の付与設定の有効化がプライベートホストゾーンといったプライベートなAWSリソースの作成に影響を与えるというのはそう設定するものだと覚えてしまえばよいですが、違和感を拭えなかったので自分なりに納得するために色々と考察・実験してみた結果が本ブログを執筆した理由です。 実験している中で、自分なりにどのケースでどの設定の組み合わせを使用するかを整理しました。
DNSのフルサービスリゾルバーについて言及するので、フルサービスリゾルバーとはなんぞ？という方はJPRSの解説記事に目を通されるとよいかと思います。
利用ケース と DNS属性の組み合わせ
私が思う利用ケースとDNS属性の有効化・無効化の組み合わせを表にまとめました。
| No | 利用ケース | DNSホスト名 | DNS解決 |
|---|---|---|---|
| 1 | 自前のフルサービスリゾルバーやDNSフォワーダー（たとえばオンプレミスのBINDやActive Directory）を参照してVPC内のリソースに名前解決を行わせるため、VPCのRoute 53 Resolver による名前解決を明示的に無効化したい | 無効 | 無効 |
| 2 | オンプレや他のVPCのフルリゾルバーを利用せず、VPCに閉じた形でインターネットに公開されているドメイン名空間の名前解決をできるようにしたい かつ VPC固有のドメイン名空間の名前解決をさせたくない |
無効 | 有効 |
| 3 | 1の利用ケースと同じ？ 実質この組み合わせを使うことはないと思う。 | 有効 | 無効 |
| 4 | a. パブリックIPアドレスを持つEC2インスタンスに対して、パブリックDNSホスト名が必要である または b. VPC内で通信が閉じた形でサービスエンドポイントに対してアクセスする際に、インターフェースVPCエンドポイントに対して発行されたDNS名（*.vpce.amazonaws.com）を指定せず、元々のサービスエンドポイントのDNS名（たとえば東京リージョンのCloudWatch Logs ならlogs.ap-northeast-1.amazonaws.com）のみを使用してサービスエンドポイントにアクセスできるようにしたい または c. VPC内で一般のインターネットとは異なるユーザ独自のドメイン名空間を使いたい（Route 53 プライベートホストゾーンの利用） ※a,b,c のどのケースでも、 Route 53 Resolver によるインターネットに公開されたドメイン名空間の名前解決も可能となる。 |
有効 | 有効 |
それではそれぞれのケースについてRoute 53 Resolver の実際の挙動を見ていきます。 挙動を確認するのは以下の構成です。
VPCにはRoute 53 のプライベートホストゾーンの example.com を関連づけており 以下のAレコードを設定しています。
| レコード名 |
タイプ | 値 |
|---|---|---|
| www.example.com | A | 192.0.2.1 |
それではresolver-client のdigコマンドでRoute 53 Resolver とGoogle Public DNSに対し www.example.com に名前解決を行ってそれぞれの挙動を比較してみましょう。
Route 53 Resolver の名前解決の挙動を見てみよう
組み合わせ1. DNS ホスト名：無効、DNS 解決：無効 の場合
DNS解決を無効化しているのでRoute 53 Resolver への問い合わせはタイムアウトし、Google Public DNS への問い合わせは成功します。
この組み合わせではVPC内のリソースはVPC 内のRoute 53 Resolver を介しての名前解決できません。なので、AWSのサービスエンドポイント*3や他サイトへのアクセスはIPアドレスを直接指定しない限りにはできません。実際には名前解決できないままとするのではなく、自前で作ったBIND やActive Directory といったフルサービスリゾルバー・DNSフォワーダーや他のVPCのRoute 53 Resolver インバウンドエンドポイントをDHCPオプションやOS設定で指定して名前解決できるようにすると思います。むしろ、そのようなVPC外のフルサービスリゾルバー・DNSフォワーダーを利用する際に、誤ってVPC内のRoute 53 Resolver で名前解決してしまわないようにするのが、この組み合わせだと思います。
組み合わせ2. DNS ホスト名：無効、DNS 解決：有効 の場合
Route 53 Resolver への問い合わせも、Google Public DNS への問い合わせも成功し、どちらもパブリックIPアドレスを得ています。
VPCにプライベートホストゾーンを関連付けていますが、インターネットに公開されているドメイン名空間の通りにRoute 53 Resolver は名前解決をします。 なので、このケースは「普通にフルサービスリゾルバが使える」状態ではあるが、VPC固有のプライベートなドメイン名空間の名前解決はできません。 VPC固有のプライベートなドメイン名空間を利用しない場合には、意図しないプライベートなドメイン名空間の名前解決を防ぐためにも、この組み合わせにしておけばよいかと思います。
組み合わせ3. DNS ホスト名：有効、DNS 解決：無効 の場合
「DNS 解決」を無効化しているのでRoute 53 Resolver への問い合わせはタイムアウトし、Google Public DNS への問い合わせは成功します。
実質「 DNS ホスト名：無効、DNS 解決：無効 」と同じです。パブリックDNSホスト名は 「DNS解決」が有効でないと、ユーザーガイドにある通り、VPCのEC2インスタンスには付与されません。あと「DNS 解決：無効」なので、このVPCのRoute 53 Resolver では名前解決ができません。これは二つの属性を無効化した時と挙動的には結果同じです。
この組み合わせ固有でできることが思いつかないのが正直なところです。VPC内のRoute 53 Resolver による名前解決を完全に無効化するのであれば「DNSホスト名：無効、DNS解決：無効」とした方がいいと個人的には思います。なぜなら無効化している意図がわかりやすいからです。
組み合わせ4. DNS ホスト名：有効、DNS 解決：有効 の場合
Route 53 Resolver への問い合わせはプライベートホストゾーンで設定したIPアドレス、Google Public DNS への問い合わせはパブリックIPアドレスを得ています*4。
このケースではRoute 53 Resolver を利用して、VPC固有の名前解決ができるようなっています。インターネットに公開されているドメイン名空間の名前解決も引き続き可能ですが、やはりVPC固有の名前解決をさせたい時に利用するものかなと思います。例えば、社内のみで利用しているプライベートなドメイン名空間を、Route 53 プライベートホストゾーンに移行し、Route 53 Resolver インバウンドエンドポイントを使ってオンプレミスのクライアントに名前解決を提供するといった場合にはこのケースが合致すると思います。
EC2インスタンスのパブリックDNSホスト名の名前解決の挙動にみるRoute 53 Resolver の挙動
DNSホスト名：有効、DNS解決：有効 の場合で特筆するべきは、EC2インスタンスに付与されたパブリックDNSホスト名である ec2-x-x-x-x.ap-northeast-1.compute.amazonaws.com をRoute 53 Resolver で名前解決した時は プライベートIPアドレスで回答が返ってきて、Google Public DNS のようなフルサービスリゾルバーではパブリックIPアドレスが返ってくることです（マスクしてますが、付与されたパブリックIPアドレスが名前解決で取得されています。）。
これはプライベートホストゾーンの設定をしていなくてもこの挙動となります。
すなわちDNSホスト名を有効化することで このVPCのRoute 53 Resolver はドメイン ap-northeast-1.compute.amazonaws.com のFQDNに対して、インターネットに公開されているドメイン名空間と異なる、VPC固有の名前解決をするようになるということです*5。
上記のため「DNS ホスト名」の有効化は一見 EC2インスタンスにパブリックDNS ホスト名が付与されるだけの設定のように名称的には見えますが、同時にRoute 53 Resolver がVPC 固有の名前解決の回答を行なうようになる設定でもあると理解できます。
まとめ
「DNS ホスト名」を有効化するとはパブリックDNSホスト名をEC2インスタンスに付与することと合わせて、「Route 53 Resovler がプライベートなドメイン名空間の名前解決ができるようになる設定」と解釈できることがわかりました。
なので「DNS ホスト名」を有効化しないと、Route 53 Resolver がVPC固有のドメイン名空間の名前解決をすることができないため、インターフェースVPCエンドポイントのプライベートDNS名やプライベートホストゾーンの前提の設定になっているのではないかと理解しました。
こうなると個人的には、「DNSホスト名」を設定する時の利用目的の頻度から、属性名として「DNS ホスト名」より「Route 53 Resolverでプライベートなドメイン名空間の名前解決」などの方がしっくりきます。しかしそうすると、次はパブリックDNS名をEC2インスタンスに付与するという部分が抜け落ちてしまいますし、昔からある属性だと思うので歴史的な経緯やすでにデプロイした環境に対する影響を考えて、「DNS ホスト名」という名称を使っているのかなと個人的には考えています。
加えて「DNS 解決」を有効化しないとそもそもRoute 53 Resolver による名前解決ができません。 なので、VPCのDNS属性は以下の順序で必要性を考えるのがポイントかなと思います。
- 設定対象のVPCでVPC内のRoute 53 Resolver によるフルサービスリゾルバーが必要か否か？（YESなら「DNS 解決」を有効化して2を考える。NOなら両方の属性を無効化する。）
- Route 53 Resolver によるVPC固有のプライベートなドメイン名空間の名前解決が必要か？（YESなら「DNS ホスト名」を有効化する。NOなら無効化する。）
大前提としてAWS提供のユーザーガイドのとおりに属性の意味、制約事項を理解・解釈するというということが正しいです。ただ、実際の挙動を見て、属性に対して自分なりの解釈・理解を持つのも 覚えやすさやトラブル対応の時の切り分けに役に立つと思います。これからも疑問に持ったことは実際に触り、検証することでAWSへの理解を深めていきます。
*1:Route 53 Resolver は Amazon DNS Server もしくは AmazonProvidedDNS ともよばれます。Amazon VPC ユーザーガイドにその旨が記載されています。
*2:インターフェースVPCエンドポイントでプライベートDNS を使用するとは、例えばCloudWatch Logs の場合で言うとlogs.ap-northeast-1.amazonaws.com というサービスエンドポイントを名前解決した時に、デプロイされたENIのプライベートIPアドレスが回答されるようにすると言うことです。
*3:例えばSession Manager の利用には、AWS Systems Manager のサービスエンドポイントの名前解決が必要なので、この状態だとOS設定などでRouter 53 Resolver 以外のフルサービスリゾルバーを参照しないとSession Manager は使えません。
*4:Route 53 のプライベートホストゾーンでインターネットに公開されているのと同一のレコードを登録し、Route 53 Resolver でそれを名前解決する際、Route 53 Resolver が左記設定前の名前解決結果のキャッシュを持っていると、VPCの属性を変更しても、すぐにはプライベートホストゾーンで登録した値にはならないことに注意。
*5:このケースで仮にRoute 53 Resolver がパブリックIPアドレスを回答する挙動をすると、一度インターネットゲートウェイの方に向かって通信して戻ってきて・・・という無駄な通信や通信ポリシーの許可設定をすることになります。なのでRoute 53 ResolverがプライベートIPアドレスを返却するというのは、理にかなった挙動であると思います。
