大家好，AWS事業本部の西野です。
VMware Cloud on AWSにおけるDNS戦略として、DNS Strategies for VMware Cloud on AWS では以下の3つのパターンが紹介されています。
- オンプレミスDNSパターン
- オンプレミス側にDNSサーバーを構築し、IPSec VPNやDirect Connect経由でSDDCから利用する。
- ローカルDNSパターン
- SDDCのコンピューティングセグメント内にDNSサーバーを構築し利用する。
- AWS DNSパターン
- EC2インスタンス上に構築したDNSサーバーやRoute 53を利用する。
DNSサーバーの運用から解放されたい思いのもと、これらのパターンのうち Route53 を利用する構成を試してみました。
構成図
本構成における名前解決は以下のステップで行われます。
- ドメイン vmc.example.com の名前解決のために、仮想マシンがNSX-TのDNSフォワーダサービスに対してDNSクエリを送信する
- 設定内容に基づき、DNSフォワーダサービスがConnected VPC内のRoute 53 Resolver Inbound EndpointにDNSクエリを転送する。
- Route 53 Resolverが vmc.example.com のDNSクエリを解決し、同一のパスを逆向きに経由してクライアントに回答する。
以下ではこの構成に必要なコンポーネントの設定について解説していきます。
※ SDDC / ワークロード用セグメント（192.168.0.0/24）/ 検証用仮想マシンなどの作成方法については詳述しません。
Route 53 Private Hosted Zoneとレコードの作成
SDDCから利用したいPrivate Hosted Zone vmc.example.com を作成し、Connected VPCと紐づけます。
また、検証用仮想マシン用のAレコードを登録しておきます。
Private Hosted Zoneやレコードの作成方法については以下のドキュメントなどをご残照ください。
プライベートホストゾーンの作成 - Amazon Route 53
Amazon Route 53 コンソールを使用したレコードの作成 - Amazon Route 53
Route 53 Resolver Inbound Endpointの作成
SDDCからの名前解決に必要な Inbound Endpoint を作成していきます。
セキュリティグループの作成
Route 53 Resolverにはセキュリティグループを設定する必要があります。事前に以下のルールのセキュリティグループを作成してください。
インバウンドルール
| タイプ | ポート番号 | 送信元IP | 備考 |
|---|---|---|---|
| TCP | 53 | < VMware Coud on AWS SDDC 管理セグメントのCIDR > | デフォルトでは10.2.0.0/16 |
| UDP | 53 | < VMware Coud on AWS SDDC 管理セグメントのCIDR > | デフォルトでは10.2.0.0/16 |
アウトバウンドルール
| タイプ | ポート番号 | 送信先IP | 備考 |
|---|---|---|---|
| TCP | All | 0.0.0.0/0 | |
| UDP | All | 0.0.0.0/0 |
Inbound Endpointの作成
続いて、エンドポイントを作成していきます。今回はSDDCから名前解決させたいので、「インバウンドのみ」にチェックをいれ次に進みます。
エンドポイント名 / VPC / セキュリティグループ / エンドポイントのタイプを設定します。
VPCとしてVMware Cloud on AWSのSDDCと接続しているVPC（Connected VPC）を指定してください。
セキュリティグループには先の手順で作成したものを指定します。
続いてIPアドレスを指定します。2つ以上のアベイラビリティゾーンでIPアドレスを指定することが推奨されています。
少なくとも1つのIPアドレスはSDDC作成時に指定したサブネット（SDDC専用のENIが作成されるサブネット）を選択すると良いでしょう。今回の検証用環境ではap-northeast-1aのサブネットを指定してSDDCを作成しています。
エンドポイント作成時にIPアドレスが割り当てられます。このIPアドレスを後ほどNSXの設定で用いるので控えておきましょう。
NSXにおけるDNSの設定
DNSゾーンの設定
NSXのDNSゾーンはクエリの転送先などの設定情報を管理する要素です。DNSレコードなどを管理するDNSゾーンとは異なる概念なのでご注意ください。
まずはドメイン vmc.example.com に関する転送先を管理するDNSゾーンを作成します。
NSXコンソール → DNS → DNSゾーン → DNSゾーンの追加 → [FQDNゾーンの追加] をクリックします。
名前 / ドメイン / DNSサーバーを指定して [保存] をクリックします。
ドメインにはRoute 53で作成したPrivate Hosted Zoneのドメイン（vmc.example.com）を、DNSサーバーにはインバウンドエンドポイントのIPを指定します。
DNSサービスの設定
続いて、NSXコンソール → DNS → DNSサービスに移動し、デフォルトで作成されているCompute Gateway DNS Forwarderの設定を編集します。FQDNゾーンとして、先の手順で作成した vmc.example.com を選択してください。
なお、DNSサービスIPの欄に記載されているIP（10.2.192.12）は仮想マシンからDNSクエリの送信先として用います。こちらも控えておきましょう。
分散ファイアウォールの設定（オプション）
分散ファイアウォールをホワイトリスト形式で設計している場合は仮想マシンからDNSサービス IPへの通信（TCP 53およびUDP 53）を許可するよう設定しましょう。
今回は検証用仮想マシンを含んだグループを作成し送信元として設定しています。宛先としては先の手順で控えておいたDNSサービスIP（10.2.192.12）を指定します。
動作確認
検証用仮想マシンにログインし以下のコマンドを実行します。
$ dig <Private Hosted Zoneに登録したレコード> @<DNSサービスIP>
# 例
$ dig cmvm.vmc.example.com @10.2.192.12
Route 53のPrivate Hosted Zoneに登録したレコードで名前解決できました。
おまけ（パブリックな名前解決について）
ここまで、Private Hosted Zone vmc.example.com の名前解決を検証してきました。同じ設定のままパブリックな名前解決を試してみましょう。
google.com を名前解決できました。これはなぜでしょうか。
再びDNSサービスに戻り、Compute Gateway DNS ForwarderのデフォルトDNSゾーンと呼ばれる項目を確認してみましょう。
ここにはDNSサーバーとして Google Public DNS（8.8.8.8, 8.8.4.4）が指定されています。指定したFQDNゾーン以外のクエリはすべてのこのデフォルトDNSゾーンで指定したDNSサーバーに転送されます。そのため、google.com へのクエリがGoogle Public DNSによって名前解決できたというわけです。
パブリックな名前解決のため、VMware Cloud on AWSではデフォルトでこの設定がなされています。
参考
Amazon Route 53 Resolver の概要 - Amazon Route 53
Choosing the Right DNS Architecture for VMware Cloud on AWS | AWS Partner Network (APN) Blog
にほんごVMware: 自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8
終わりに
このブログがほんの少しでも世界を良くできれば嬉しいです。 AWS事業本部の西野 (@xiyegen) がお送りしました。
10
