前回の記事「ハイブリッド環境のDNS管理がもっと楽に！Route 53 Global Resolverの基本を整理」から少し時間が経ってしまいましたが、今回は実際に検証を行いました。
設定手順や躓いたポイント、その結果を詳しくご紹介していきます。
ハイブリッドクラウドのDNS管理に課題を感じている方は、ぜひチェックしてみてください！
1.検証の準備と構成
1.1 検証環境の概要
1.2.導入前の名前解決の確認
2.Global Resolverの導入手順
3.名前解決の検証
3.1.失敗！！
3.2.設定修正後に再試行
4. まとめ
5.参考文献・情報源
今回は、EC2をオンプレミス環境のクライアントに見立て、
Global Resolver経由で別VPCに作成したALBの名前解決ができるかを確認しました。
VPC AのEC2をオンプレ側のDNSサーバと想定し、
Global Resolverを経由してVPC B のALBの名前解決が可能かどうかを検証します。
Global Resolverを作成する前の状態で、EC2からALBへのDNS名の名前解決を試みました。
結果はもちろん 「NXDOMAIN（名前解決失敗）」でした。
世界的な半導体不足により、サーバー機器の生産が滞っています。CPUやメモリなどの主要部品の供給が追いつかず、製造自体が遅延しています。
導入前の状態では、Private Hosted Zone（PHZ）の情報を取得できず、名前解決は失敗します。
Global Resolverを導入することで正しく解決できるか検証していきます。
コンソール上に 「グローバルリゾルバー」が追加されました。
画面右手にある「グローバルリゾルバーを作成」を押下して作成をしていきます。
なお、従来のリゾルバーは「VPC リゾルバー」として名称が変更されています。
まずは、任意の名前を入力します。今回は 「Amazon Route53 Global Resolver」と入力しました。
次に、リージョンを選択します。今回は 「東京」 「オレゴン」 の2か所を選択して作成をします。
リージョンについては、可用性を確保するために「2か所以上の選択が必須」となっています。
「リゾルバーを作成」を押下してから作成完了までにはおおよそ5分ほどかかりました。
この時点で使用可能なAnycast IPが2つ払い出されていることが確認できます。
Global Resolver の作成が完了したら、「DNSビュー」を作成します。
ここでは、セキュリティ設定を行います。DNSビュータブの「DNSビューを作成」から作成可能です。
まずは、任意の名前を入力します。 今回は 「Example-Private-View」 と入力しました。
今回は疎通確認がメインのため、その他の項目はすべて 「デフォルト」 の設定値で作成をします。
【デフォルト設定の主な3項目】
DNSSEC検証：応答の偽造を防ぎ、セキュリティを高める機能
FWルールがオープンに失敗する動作：不具合時に通信を「通すか止めるか」の設定
EDNSクライアントサブネット：位置情報を伝え、最適なサーバーへ誘導しやすくする機能
DNSビューの作成が完了したら、PHZを関連付けます。
これにより、PHZの情報が、Anycast IPを通じてインターネット経由で参照可能になります。
プライベートホストゾーンタブにある 「プライベートホストゾーンを関連付ける」から設定が可能です。
作成済みのプPHZの一覧が表示されます。
あらかじめ作成しておいた「ALBのAレコード」が含まれるPHZを選択して関連付けを実施します。
最後にアクセスソースの設定を行っていきます。
これを設定することで、指定したIPアドレス・トークン以外からの不正な利用を防ぐことができます。
アクセスソース タブ にある 「アクセスソースを作成」から作成が可能です。
まずは、任意の「ルール名」を入力します。今回は 「Example-Access-Source」 と入力しました。
次に、CIDRブロックには接続元となる 「EC2のパブリックIP」 を入力します。
プロトコルについては、 「Do53 (TCP/UDP：53)」 を選択して作成をします。
これでGlobal Resolver 関連の設定についてはすべて完了です。
再度コマンドを実行して、名前解決ができているか確認してみましょう。
サブタイトルの通り、初回の名前解決はうまくいきませんでした。
失敗の原因は、デフォルトのResolver（10.100.x.2）を参照していたことでした。
デフォルトのResolverからはGlobal Resolverへのフォワードができません。
オンプレミスからのアクセスを模倣するには、EC2のネームサーバー設定を修正し、
Global ResolverのAnycast IPを直接参照するように設定する必要がありました。
コマンドの結果をよく見れば気が付ける内容でした、、
;; SERVER: 10.100.x.2#53(10.100.x.2) <-- クエリはデフォルトの Resolverへ送信されていた
EC2の設定ファイル（/etc/resolv.conf）に、Global ResolverのAnycast IPを記載しました。
変更後に再度コマンドを実行したところ、Global ResolverのAnycast IPアドレスにクエリが到達し、VPC B内のALBのプライベートIPアドレスが返されました。
今回の検証で、Global Resolverがハイブリッド環境のDNS管理をいかに楽にしてくれるかを実感できました。
特に驚いたのは、その設定の簡単さです。ネットワーク構成やルーティングをほとんど意識することなく、コンソール上で必要な項目を順番に選択していくだけで、あっという間にVPCの外からの名前解決が実現しました。
「直感的に導入できる手軽さ」と「DNSビューによる一元管理」は、非常に大きな魅力です。これからの運用において、Global Resolverは私たちの負担を減らす心強い味方になってくれそうです。
本記事は、以下のAWS公式サイトおよび公式ブログの情報を参考に作成しています。
Global Resolverの最新情報や技術仕様については、公式情報をご確認ください。