こんにちは、こんばんわ！クラウドインテグレーション事業部の魚介系エンジニア松尾です。

AWS で所有リソースに対し名前解決を行う場合、Route53 を利用されている方は多くいらっしゃると思います。
今回は私が Route53 を利用している中で、後述の構成で想定していなかった事象が発生したことと、よく忘れがちな Route53 の仕様について備忘の為にも投稿させていただきます。
私と同じような状況になった方の一助になれれば幸いです。

経緯

想定外の事象は既存の AWS 構成から NW 構成を変更する検証時に発生しました。

もともと単一 VPC 内に複数のサービスが混在していたのですが、セキュリティ強化を目的に一部サービスを別 VPC に移動させ、本来アクセスが必要なもののみ NW に到達できる構成へと変更を行うことが目的でした。
新旧の AWS の構成は以下の通りです。
※実際の構成よりもかなり簡素化しております。

旧構成
新構成

旧構成はパブリックな通信を行うものは Route53 で名前解決し、プライベート通信を行うものはサービスごとの Linux OS の hosts ファイルで名前解決を行いサービス間の連携を行っておりました。

新構成はサービス影響を抑えるため、試験的に一部サービスのみ VPC を分け、新しく作成した VPC 間のみ Trangit Gateway で接続した形となります。
NLB に TLS リスナーを設定し、その NLB にプライベートホストゾーンでドメインを割り当てることで、VPC 間でも HTTPS 通信が可能となっております。
なお、アプリケーションの極力リファクタリングが不要となるよう、パブリック/プライベートホストゾーンで同一のサブドメインを登録しておりました。

何が起こったのか

もうお気づきの方はいるかもしれませんが、本構成の場合 VPC A に対するパブリックアクセスができない状況となりました。
通信経路やセキュリティグループの設定などは問題無くできているにも関わらず通信が通らない・・・。

調べたところ VPC A 向けのリソースに対する名前解決ができていないことが発覚しました。
事前にしっかり AWS の名前解決の仕様を理解していれば本事象が起こることはなかったのですが。。。(思い込みはよくないですね・・・。)

ここで改めて AWS の名前解決の仕様について調べてみました。

AWS の名前解決の仕様について

前提として、全ての VPC は Route53 Resolver(旧 Amazon Provided DNS)と関連付けされており、Route53 Resolver を通してパブリック/プライベートの名前解決を開始します。
AWS内の名前解決の優先順位としては、

Route53 Resolver に登録されたドメイン名と一致するか
↓
Route53 プライベートホストゾーンに一致するドメイン名があるか
↓
Route53 パブリックホストゾーンに一致するドメイン名があるか

となります。

この仕様自体は私も理解しており、Resolver やプライベートホストゾーンに存在しないドメインは自動的にパブリックホストゾーンに検索にいくだろうと思っていたのですが、その認識が誤ってました。。。
私の理解が足りなかった点として、そもそもレコードがホストゾーンに登録があるか無いかではなく、ドメインがホストゾーンと一致しているどうかということろでした。

実際の動きとして構成図を例にすると、

①Route53で「taco.gyogyo.matsuo-john.com」などのドメインでリクエストを受信した場合、一致する親ドメインである「gyogyo.matsuo-john.com」のプライベートホストゾーンに問い合わせを行う
②プライベートホストゾーンが「taco.gyogyo.matsuo-john.com」と一致するレコードの登録がない場合、 NXDOMAIN (存在しないドメイン) を返す

という動きになります。

つまりリクエストのドメインがホストゾーンドメインと一致している時点で、そのホストゾーン内で解決を行うので、パブリックホストゾーンでレコードの登録があったとしても、そこまで到達することが無いということですね・・・。

今回の構成では内部向けの通信で必要なドメインのみプライベートホストゾーンに登録しておりますので当然の結果となりますが、次にこちらの解決方法についてご紹介させていただきます。

ちなみに、本 Route53 の構成のようなパブリック/プライベートホストゾーンで同一のサブドメインを利用する構成は「スプリットビュー DNS」と呼ばれ、AWS の公ドキュメントでも紹介されている構成となりますので、サポート外の構成ではありません。

解決策

①PrivateLink の利用

本構成で一番構成として望ましい形は「VPC B」、「VPC C」それぞれから「VPC A」に対し PrivateLink を行うことです。

PrivateLink は VPCエンドポイントの機能の一つで、VPC 外のサービスに対して VPC ピアリングや Trangit Gateway を利用することなく、プライベートアクセスを可能とする AWS サービスとなります。
PrivateLink で利用するエンドポイントサービスに対しプライベート DNS の割り当てが可能で、 Route53 Resolver 内での名前解決を行うことができるため、前述の事象が発生することはありません。
構成としては以下のようになります。

なお、PrivateLink でプライベート DNS を利用するにはドメイン保有者であるの証明を行う必要があり、パブリックホストゾーンで TXT レコードの登録が必要となりますので、プライベートホストゾーンのみで利用はできない点ご注意下さい。

PrivateLink に関する詳細は以下の AWS 公式ドキュメントをご確認下さい。

docs.aws.amazon.com

プライベートホストゾーンの利用

この文面だけだと意味不明に思われる方もいるかもしれませんが、実施することとしては文面の通りで、パブリックホストゾーンに登録しているレコードをそのままプライベートホストゾーンで登録する方法となります。

私も最近までこの方法を知らなかったのですが、プライベートホストゾーンでパブリック IP や ALB の FQDN などに対し A レコード、エイリアスレコードの登録が可能なため、今回のような構成であってもプライベートホストゾーンにパブリックドメインを登録することで前述の事象を回避することができます。

ただし、AWS の公式ドキュメントにはインターネット向けの通信にはパブリックホストゾーン、プライベート通信にはプライベートホストゾーンの利用が促されており、本利用方法について明記されているものが見当たらないため、一般的な利用方法であるか、サポートされているか否かが判断できません。

そのため、本方法に関しましては検証目的や一時利用にとどめていただき、PrivateLink の利用を検討することをお勧めします。

hosts ファイルの利用

こちらはクライアント OS で解決する古来からの方法です。

Route53 Resolver に到達する前に OS で名前解決を行うため、前述の事象は起きえない形となります。

ただし、ALB など IP が変動するものに対して hosts ファイルを設定すると都度メンテナンスが必要となったり、今回ようなスプリットビュー DNS を利用してホストゾーンを構成している場合はドメイン管理が複雑化する要因となりますのであまりお勧めできません。

プライベートホストゾーンの利用と同様に hosts ファイルの利用も検証目的や一時利用にとどめていただき、最終的には PrivateLink の利用を検討することをお勧めします。

VPC の設定で回避

スプリットビュー DNS を利用するケースとして、一般的に内部ユーザと外部ユーザに対して、異なるコンテンツを供給したり、異なる認証を要求したりするケースがあります。
プライベートホストゾーンを利用する場合は以下 VPC 設定を有効化する必要がありますので、プライベートホストゾーンに接続を行いたくない VPC は「enableDnsHostnames」を無効にすることで、スプリットビュー DNS であってもプライベートホストゾーン向けの名前解決とパブリックホストゾーン向けの名前解決を分けることが可能です。