ガバメントクラウドでよく見る閉域オンプレミスと AWS のハイブリッド構成における Route 53 インバウンド・アウトバウンドエンドポイントの名前解決パターンを構築してみる

ガバメントクラウドでは、閉域でオンプレミスの庁舎内ネットワークとマルチアカウントで構成された AWS 環境と連携するハイブリッド構成のネットワークが多く見られます。

閉域オンプレミスと AWS のハイブリッド構成のネットワークを考える時に、Route 53 インバウンド / アウトバウンドエンドポイントとオンプレミスの DNS サーバーを連携させることが効率的ですが、AWS がマルチアカウント構成の場合、集約アカウント（ネットワークアカウント）にエンドポイントをまとめて、他のアカウントに共有すると更に効率化が図れます。

そこで、自宅に閉域オンプレミスに見立てた DNS の検証環境を構築し、VPN で AWS に接続した上で、実際に Route 53 インバウンドエンドポイント・アウトバウンドエンドポイントとオンプレミスの DNS サーバーと連携させて動作を確認してみました。

本記事は、以前に書いた以下の記事に、オンプレミスの DNS サーバーからの連携を加筆して再構成したものとなります。

検証環境の構成

オンプレミスには intra.morori.jp というドメインを管理する権威 DNS サーバーがあるとします。AWS 環境では、アカウントごとに異なる、オンプレミスのドメインのサブドメインを使うこととします。

環境	ドメイン	サブネット
オンプレミス	intra.morori.jp	10.1.0.0/16
ネットワークアカウント VPC	test01.intra.morori.jp	10.128.0.0/16
ASP アカウント VPC	test02.intra.morori.jp	10.129.0.0/16

各 DNS サーバー等の IP アドレスなどは次のとおり。

DNS サーバー	IP アドレス
オンプレミスリゾルバ DNS サーバー	10.1.1.3
オンプレミス権威 DNS サーバー	10.1.1.2
Route 53 インバウンドエンドポイント	10.128.130.26

オンプレミスと AWS 環境は、ネットワークアカウント VPC のパブリックサブネットにある EC2 インスタンスとオンプレミスのルーターで IPSec トンネルで接続して相互にルーティングできるようにしています。ガバメントクラウドでは実際には Direct Connect での接続となります。オンプレミスのルーターと EC2 インスタンスで VPN を張る手順は別記事にまとめています。

ネットワークアカウント VPC と ASP アカウント VPC は Transit Gateway で相互にルーティングできるようにしています。Transit Gateway ルートテーブル、VPC のルートテーブルに互いのサブネットへの経路情報を静的に追加し、オンプレミスを含めて相互にルーティングできるようにしています。複数アカウントの VPC を Transit Gateway で接続する手順は以前書きましたので参考になるかもです。

AWS 環境と連携する前の閉域オンプレミス DNS サーバー（BIND）の設定

仮想環境に 2 台 Alma Linux 9.5 でそれぞれオンプレミスの閉域環境内で管理するドメイン（intra.morori.jp）の権威 DNS サーバーと、リゾルバ DNS サーバーに BIND をインストールして立てます。クライアントはリゾルバ DNS サーバーを向いているとします。リゾルバ DNS サーバーに intra.morori.jp の名前解決要求が来たら、条件付きフォワーダで権威 DNS サーバーへ名前解決要求を転送し、閉域の中で名前解決が完結できるようにしています。

リゾルバ DNS サーバーの設定

以下は AWS 環境と連携する前の設定で、この後、AWS 側の Route 53 インバウンドエンドポイント・アウトバウンドエンドポイントの設定に合わせてリゾルバ DNS サーバーの設定を追加していくことになります。

/etc/named.conf

acl "intranets" {
  10.1.0.0/16; # オンプレミスのサブネット
  10.128.0.0/16; # ネットワークアカウント VPC のサブネット
  10.129.0.0/16; # ASP アカウントの VPC サブネット
};

options {
        listen-on port 53 { 10.1.1.3; }; # リゾルバ DNS サーバーの IP アドレス
        allow-query     { localhost; intranets; };
        forwarders { 10.1.15.254; };
        recursion yes;
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/intra.morori.jp.zones";

/etc/intra.morori.jp.zones

zone "intra.morori.jp" IN {
        type forward;
        forward only;
        forwarders { 10.1.1.2; }; # オンプレミスのドメインの権威 DNS サーバーの IP アドレス
};

権威 DNS サーバーの設定

/etc/named.conf

acl "cache-server" {
  10.1.1.3/32;
};

options {
        listen-on port 53 { 10.1.1.2; };
        allow-query     { localhost; cache-server; };
        allow-recursion { none; };
        allow-query-cache { none; };
        recursion no;
};

include "/etc/intra.morori.jp.zones";

/etc/intra.morori.jp.zones

zone "intra.morori.jp" {
        type master;
        file "intra.morori.jp.db";
};

/var/named/intra.morori.jp.db

$TTL 86400
@       IN      SOA     ns1.intra.morori.jp.    root.morori.jp. (
        2025022201
        28800
        14400
        3600000
        86400
)
        IN      NS      ns1.intra.morori.jp.
        IN      MX      10      smtp.intra.morori.jp.

ns1     IN      A       10.1.1.2
ns2     IN      A       10.1.1.3
smtp    IN      A       10.1.1.4

オンプレミスから AWS 環境の名前解決ができるようにする

AWS 環境の設定

ネットワークアカウント VPC の名前解決のオプションを有効化

Route 53 インバウンドエンドポイント作るネットワークアカウント VPC の DNS 設定を変更し、「DNS 解決を有効化」「DNS ホスト名を有効化」を有効にしておきます。

ネットワークアカウント VPC に Route 53 インバウンドエンドポイントの作成

オンプレミスから AWS 環境の名前解決をするためのインバウンドエンドポイントをネットワークアカウント VPC に作成します。

事前にオンプレミス、AWS 環境のサブネットから UDP 53 番ポートと TCP 53 番ポートのアクセスを許可するセキュリティグループを作成しておいてください。

Route 53 インバウンドエンドポイントの IP アドレスが AZ を跨いで 2 つ作られました。Route 53 インバウンドエンドポイントは仕様上 2 つ以上の AZ に跨って作成するので必ず 2 個以上 IP アドレスがありますが、今回は検証目的なので、IP アドレスはこのうち 10.128.130.26 の方の 1 つだけ使用することにします。

ASP アカウントでのプライベートホストゾーンの作成

インバウンドエンドポイントの集約をする場合、プライベートホストゾーンをネットワークアカウントで作成するか、各 ASP アカウントで作成するかの二通りのプライベートホストゾーンの管理方法があると思います。

今回は ASP アカウントで自分達のリソースのプライベートホストゾーンを管理する方法を選択しようと思います。この ASP アカウントでは test02.intra.morori.jp というオンプレミスのドメインのサブドメインを運用することとし、ASP アカウントで test02.intra.morori.jp ドメインの Route 53 のプライベートホストゾーンを作成します。

ASP アカウントのプライベートホストゾーンをネットワークアカウント VPC への関連付け

次に Route 53 インバウンドエンドポイントを作成したネットワークアカウント VPC にこの ASP アカウントプライベートホストゾーンを関連付けます。

別アカウントの VPC にプライベートホストゾーンを関連付ける作業はマネージメントコンソールでは行えないため、AWS CLI などから実施する必要があります。AWS CLI から以下のようにコマンドを実行します。VPC は東京リージョンにあるものとします。

$ aws route53 create-vpc-association-authorization --hosted-zone-id （プライベートホストゾーンの ID） --vpc VPCRegion=ap-northeast-1,VPCId=（VPC ID） --region ap-northeast-1

コマンドの詳細はリファレンスを参照。

ASP アカウント VPC の DHCP オプションセットの DNS 設定を変更する

ASP アカウントの VPC のリソースがネットワークアカウント VPC の Route 53 インバウンドエンドポイントで名前解決をするようにしたいので、ASP アカウントの VPC の DHCP オプションセットを変更します。

以下のとおり DNS サーバーの IP アドレスに Route 53 インバウンドエンドポイントの IP アドレスを設定します（今回は検証目的のため、1 つの IP アドレスのみで設定しています）。

これにより、ASP アカウントの VPC のリソースは、ネットワークアカウント VPC の Route 53 インバウンドエンドポイントの IP アドレスに名前解決する要求することで、自分のプライベートホストゾーンのレコードを含めた AWS 環境の名前解決できるようになります。

以降、他のアカウントがプライベートホストゾーンをネットワークアカウント VPC に関連付けるとそのプライベートホストゾーンのレコードも名前解決できるようになっている仕組みです。

オンプレミスのリゾルバ DNS サーバーの設定

このままでは AWS 環境の中では ASP アカウントの Route 53 プライベートホストゾーンの名前解決ができますが、オンプレミスからはできないため、オンプレミスからも AWS 環境側の名前解決ができるようにしていきます。

オンプレミスのリゾルバ DNS サーバーに、test02.intra.morori.jp ドメインへの名前解決要求が来たら、条件付きフォワーダでネットワークアカウントの VPC の Route 53 インバウンドエンドポイントに転送するよう設定します。

ここで注意点ですが、オンプレミスのサブドメインを AWS 環境で使うならオンプレミスの権威 DNS サーバーにサブドメインの委任ルールを設定すればいいのでは？と思うかもしれません。しかし、Route 53 インバウンドエンドポイントの仕様で、インバウンドエンドポイントをサブドメインの委任先 DNS として設定することはできません。そのため、サブドメインだとしても条件付きフォワーダを使う必要があるのです。

この制約があるため、オンプレミスの DNS サーバーが権威とリゾルバを分けずに同一のサーバーで構成している場合、問題が起きる可能性がありますので、この機に権威とリゾルバは分けた方がよいと思います。

話を戻して、BIND に以下のとおり設定を追加します（前述のとおり検証目的のため、フォワーダを 1 つの IP アドレスのみで設定しています）。

/etc/intra.morori.jp.zones

zone "intra.morori.jp" IN {
        type forward;
        forward only;
        forwarders { 10.1.1.2; };
};
zone "test02.intra.morori.jp" IN { # ASP アカウントプライベートホストゾーンのドメイン
        type forward;
        forward only;
        forwarders { 10.128.130.26; }; # インバウンドエンドポイントの IP アドレス
};

オンプレミスから名前解決の動作確認

オンプレミスのクライアントから、オンプレミスのリゾルバ DNS サーバーで ASP アカウントのプライベートホストゾーンのドメインのレコードを名前解決してみます。

ASP アカウントのプライベートホストゾーンのドメインのレコードの IP アドレスが返ってくることが確認できました。

AWS 環境からオンプレミスの名前解決ができるようにする

次は逆に AWS 環境からオンプレミスのドメインの名前解決ができるようにしていきます。

ネットワークアカウント VPC に Route 53 アウトバウンドエンドポイントの作成

ネットワークアカウント VPC に Route 53 アウトバウンドエンドポイントを作成します。事前に AWS 環境のサブネットから UDP 53 番ポートと TCP 53 番ポートのアクセスを許可するセキュリティグループを作成しておいてください（アウトバウンドエンドポイントに対するセキュリティグループですが、セキュリティグループのルールはインバウンドのルールが必要なので注意してください）。

Route 53 リゾルバールールの作成と Resource Access Manager でのリソース共有

ネットワークアカウントでリゾルバールールを作成

オンプレミスのドメイン（intra.morori.jp）に対する Route 53 の転送ルールを作成します。作成した Route 53 アウトバウンドエンドポイントを指定します。また、アウトバウンドする先の DNS サーバーの IP アドレスとしてオンプレミスのリゾルバ DNS サーバーの IP アドレスを指定します。

ASP アカウントへのリゾルバールールのリソース共有を作成

Resource Access Manager（RAM）で作成したリゾルバールールを ASP アカウントへ共有します。Organizations で共有もできるのですが、ガバメントクラウドではメンバーアカウントとなるため使えないので、ASP アカウントのアカウント ID を指定して個別に共有します。

ASP アカウント側のマネージメントコンソールでリソース共有を承認します。

AWS 環境から名前解決の動作確認

オンプレミスのドメインへの名前解決要求は Route 53 アウトバウンドエンドポイントに転送するというリゾルバールールを設定したことにより、ASP アカウントの VPC にある EC2 から、Route 53 インバウンドエンドポイント→Route 53 アウトバウンドエンドポイント→オンプレミスのリゾルバ DNS サーバーへオンプレミスのドメインへの名前解決要求が転送されていくようになり、レコードを名前解決できるようになりました。

（おまけ）S3 のインターフェイスエンドポイントの名前解決を試す

S3 のインターフェイスエンドポイントを作成してプライベート DNS 名を有効にした時の動作を見てみます。

先に閉域オンプレミスで amazonaws.com の名前解決をした際に Route 53 インバウンドエンドポイントに向くようにオンプレミスのリゾルバ DNS サーバーに条件付きフォワーダを追加します。

/etc/intra.morori.jp.zones

zone "intra.morori.jp" IN {
        type forward;
        forward only;
        forwarders { 10.1.1.2; };
};
zone "test02.intra.morori.jp" IN { # ASP アカウントプライベートホストゾーンのドメイン
        type forward;
        forward only;
        forwarders { 10.128.130.26; }; # インバウンドエンドポイントの IP アドレス
};
zone "amazonaws.com" IN { # VPC エンドポイントの名前解決もインバウンドエンドポイントにむｋ
        type forward;
        forward only;
        forwarders { 10.128.130.26; }; # インバウンドエンドポイントの IP アドレス
};

インターフェイスエンドポイントを作ります。

インターフェイスエンドポイントの DNS 名をオンプレミスのリゾルバ DNS サーバーで名前解決してみます。

ホスト名を閉域のオンプレミスから名前解決しても、VPC のプライベート IP アドレスが返るようになりました。

実は同じホスト名をインターネット環境で名前解決してもできてしまいます。ただし、返ってくるのはプライベート IP アドレスのため、セキュリティ上問題はありません。

これで、閉域内からでも名前解決できることで、インターフェイスエンドポイントを作成できる AWS のサービスには閉域内からアクセスできることが分かりました。

参考サイト