難しい設定は不要？Route 53 Global ResolverでハイブリッドクラウドのDNS問題を解消してみた

前回の記事「ハイブリッド環境のDNS管理がもっと楽に！Route 53 Global Resolverの基本を整理」から少し時間が経ってしまいましたが、今回は実際に検証を行いました。

設定手順や躓いたポイント、その結果を詳しくご紹介していきます。

ハイブリッドクラウドのDNS管理に課題を感じている方は、ぜひチェックしてみてください！

■ 目次 

1.検証の準備と構成

1.1 検証環境の概要

1.2.導入前の名前解決の確認

2.Global Resolverの導入手順

3.名前解決の検証

3.1.失敗！！

3.2.設定修正後に再試行

4. まとめ

5.参考文献・情報源

■ 1.検証の準備と構成  

1.1.検証環境の概要 

今回は、EC2をオンプレミス環境のクライアントに見立て、
Global Resolver経由で別VPCに作成したALBの名前解決ができるかを確認しました。

● Global Resolver 検証構成図

VPC AのEC2をオンプレ側のDNSサーバと想定し、
Global Resolverを経由してVPC B のALBの名前解決が可能かどうかを検証します。

1.2.導入前の名前解決の確認

Global Resolverを作成する前の状態で、EC2からALBへのDNS名の名前解決を試みました。

結果はもちろん 「NXDOMAIN（名前解決失敗）」でした。

● 実行コマンドと結果

世界的な半導体不足により、サーバー機器の生産が滞っています。CPUやメモリなどの主要部品の供給が追いつかず、製造自体が遅延しています。

導入前の状態では、Private Hosted Zone（PHZ）の情報を取得できず、名前解決は失敗します。

Global Resolverを導入することで正しく解決できるか検証していきます。

■ 2.Global Resolverの導入手順    

①Global Resolver の作成

コンソール上に 「グローバルリゾルバー」が追加されました。

画面右手にある「グローバルリゾルバーを作成」を押下して作成をしていきます。

なお、従来のリゾルバーは「VPC リゾルバー」として名称が変更されています。

②Global Resolver の設定値

まずは、任意の名前を入力します。今回は 「Amazon Route53 Global Resolver」と入力しました。

次に、リージョンを選択します。今回は 「東京」 「オレゴン」 の2か所を選択して作成をします。

リージョンについては、可用性を確保するために「2か所以上の選択が必須」となっています。

「リゾルバーを作成」を押下してから作成完了までにはおおよそ5分ほどかかりました。

この時点で使用可能なAnycast IPが2つ払い出されていることが確認できます。

③DNSビューの設定

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 関連の設定についてはすべて完了です。
再度コマンドを実行して、名前解決ができているか確認してみましょう。

■ 3.名前解決の検証    

3.1.失敗！！

サブタイトルの通り、初回の名前解決はうまくいきませんでした。

● 実行コマンドと結果

失敗の原因は、デフォルトのResolver（10.100.x.2）を参照していたことでした。
デフォルトのResolverからはGlobal Resolverへのフォワードができません。

オンプレミスからのアクセスを模倣するには、EC2のネームサーバー設定を修正し、
Global ResolverのAnycast IPを直接参照するように設定する必要がありました。

コマンドの結果をよく見れば気が付ける内容でした、、
;; SERVER: 10.100.x.2#53(10.100.x.2)  <-- クエリはデフォルトの Resolverへ送信されていた

3.2.設定修正後に再試行

EC2の設定ファイル（/etc/resolv.conf）に、Global ResolverのAnycast IPを記載しました。

変更後に再度コマンドを実行したところ、Global ResolverのAnycast IPアドレスにクエリが到達し、VPC B内のALBのプライベートIPアドレスが返されました。

■ まとめ  

今回の検証で、Global Resolverがハイブリッド環境のDNS管理をいかに楽にしてくれるかを実感できました。

特に驚いたのは、その設定の簡単さです。ネットワーク構成やルーティングをほとんど意識することなく、コンソール上で必要な項目を順番に選択していくだけで、あっという間にVPCの外からの名前解決が実現しました。

「直感的に導入できる手軽さ」と「DNSビューによる一元管理」は、非常に大きな魅力です。これからの運用において、Global Resolverは私たちの負担を減らす心強い味方になってくれそうです。

■ 5.参考文献・情報源

本記事は、以下のAWS公式サイトおよび公式ブログの情報を参考に作成しています。

Global Resolverの最新情報や技術仕様については、公式情報をご確認ください。

https://aws.amazon.com/jp/route53/global-resolver/

https://aws.amazon.com/jp/blogs/news/introducing-amazon-route-53-global-resolver-for-secure-anycast-dns-resolution-preview/