2025/07/05 委任の設定をしながら別ドメインへの条件付きフォワーダーの設定ができること、別アカウントのプライベートホストゾーンへの委任もできることを追記しました。
先日 AWS から Route 53 リゾルバーのエンドポイントを使ったプライベートホストゾーンへのサブドメインの委任がサポートされたとの発表がありました。
domain name system (DNS) delegation for private hosted zone subdomains can be used with Route 53 inbound and outbound Resolver endpoints. This allows you to delegate the authority for a subdomain from your on-premises infrastructure to the Route 53 Resolver cloud service and vice versa,
これまで Route 53 側へサブドメインを委任することはサポートされていませんでした。
そのため、例えば閉域のオンプレミスに独自ドメインの権威 DNS サーバーがあり AWS の VPC でも独自ドメインのサブドメインを使う場合は次の構成が必要でした。
まず、Route 53 プライベートホストゾーンでサブドメインを管理するところまではよいのですが、オンプレミスの権威 DNS サーバーから見ると Route 53 プライベートホストゾーンは委任関係になく、完全に独立したものでした。
そのため、オンプレミスのリゾルバー DNS サーバーにサブドメインに対する条件付きフォワーダーを設定し、このサブドメインを管理している Route 53 プライベートホストゾーンが関連付けられている VPC にある Route 53 インバウンドエンドポイントへオンプレミスからの名前解決クエリを転送する必要がありました。
しかし今回、Route 53 インバウンドエンドポイントを使って Route 53 プライベートホストゾーンへのサブドメインの委任ができるようになったため、従前どおりサブドメインは Route 53 プライベートホストゾーンで管理しつつ、オンプレミスの権威 DNS サーバーから Route 53 側へのサブドメインの委任の設定をするだけで、オンプレミスと AWS の VPC で一貫した名前解決ができるようになりました。
この構成は閉域で使う地方自治体の基幹システムのガバメントクラウド利用の場面でも使えると思い、早速自宅の環境で検証してみました。
Route 53 プライベートホストゾーンへの DNS 委任の概要
構成図は以下のとおりです。
おうち閉域オンプレミスと AWS を接続し、オンプレミスに独自ドメイン (intra.morori.jp) の権威 DNS サーバーと、クライアントが参照するリゾルバー DNS サーバーを Linux サーバー上の BIND で構築します。
Route 53 側は、今回新設された、委任を受けるオプションを使って VPC に Route 53 インバウンドエンドポイントを作成します。また、独自ドメインのサブドメイン (delegate-test.intra.morori.jp) で Route 53 プライベートホストゾーンを作成し、任意のホストのレコードを登録します。
オンプレミスの権威サーバーから Route 53 プライベートホストゾーンへサブドメインを委任できるよう、権威サーバーのゾーンを更新した後、オンプレミスのリゾルバー DNS サーバーから Route 53 プライベートホストゾーンで登録したホストのレコードが名前解決できればゴールです。
Route 53 の設定
先に Route 53 側の設定を行います。後でオンプレミスの DNS サーバーの設定をする際に、Route 53 インバウンドエンドポイントの IP アドレスが必要となるためです。
なお、Route 53 側の設定は難しくなく、AWS の Developer Guide によると、Route 53 インバウンドエンドポイントを作成し、オンプレミスの権威 DNS サーバーから委任の設定をする際に、Glue レコード（委任先の DNS サーバーを指定するレコード）にエンドポイントの IP アドレスを指定するだけでよく、Route 53 プライベートホストゾーンには特に細工は不要であることが分かります。
Route 53 インバウンドエンドポイントの作成
まずは Route 53 インバウンドエンドポイントを作るのですが、早速今回の新機能を選ぶオプションが現れます。
「Endpoint Category」は Default ではなく、「Delegation」を選びます。これによりオンプレミスなどからサブドメインの委任を受けられるようになります。
なお、Delegation を選んでも、委任の専用となるわけでなく、従前どおりの名前解決ができます。Developer Guide から引用します。
Creating an inbound endpoint doesn't change the behavior of Resolver, it just provides a path from a location outside the AWS network to Resolver.
ちなみに Delegation を選ぶと現時点では DoH (DNS over HTTPS) は使用できません。
Route 53 インバウンドエンドポイントが作成されました。エンドポイントの IP アドレスを控えておきましょう。
Route 53 プライベートホストゾーンの設定
オンプレミスの権威 DNS サーバーから委任されるサブドメイン (delegate-test.intra.morori.jp) の Route 53 プライベートホストゾーンを作成します。
作成方法は通常となんら変わることはありません。一般的な委任を受ける DNS サーバーの設定のように、NS レコードを自身の A レコードにしたり、この後オンプレミスの権威 DNS サーバーのゾーンに設定する、委任先 DNS サーバーの IP アドレス（Route 53 インバウンドエンドポイントの IP アドレス）を A レコードに登録したりする必要があるかと思ったのですが、そういった設定は全く不要でした。
ここで登録した hoge.delegate-test.intra.morori.jp というホストは、現在 オンプレミス側からは Route 53 インバウンドエンドポイントを直接参照するか、条件付きフォワーダーでクエリを転送しないと名前解決はできません。これをオンプレミス側で条件付きフォワーダーを使うことなく名前解決できるようにしていきたいと思います。
オンプレミスの DNS サーバーの設定
権威 DNS サーバー
権威 DNS サーバーのサブドメインの委任の設定は、特に従前からある設定と変わる部分はありません。今回は AlmaLinux 9.4 の BIND 9 で構築していますが、バージョンによって差異はないと思われます。ポイントの箇所のみ抜粋します。
/etc/named.conf
acl "cache-server" {
10.1.1.3/32; // リゾルバー DNS サーバーの IP アドレス
};
options {
listen-on port 53 { 10.1.1.2; }; // 権威 DNS サーバーの IP アドレス
directory "/var/named";
allow-query { cache-server; };
allow-recursion { cache-server; }; // 委任先への再帰問合せとなるようなので有効に
allow-query-cache { cache-server; }; // キャッシュ問合せも許可が必要だった
recursion yes; // 委任先への再帰問合せとなるようなので有効に
include "/etc/named.intra.morori.jp.zones";
// その他の設定は省略
};
/etc/named.intra.morori.jp.zones
zone "intra.morori.jp" {
type master;
file "intra.morori.jp.db";
};
/var/named/intra.morori.jp.db
このゾーンファイルが委任設定の肝となります。サブドメインの NS レコードは任意のホスト名で良いのですが、ポイントはこの NS レコードで指すホストの A レコードに、Route 53 インバウンドエンドポイントの IP アドレスを指定することです。
Developer Guide から引用します。
You configure resolvers on your network to delegate DNS queries for the applicable domain names to Route 53 Resolver. For the glue records you must enter the IP addresses for the inbound endpoints.
$TTL 86400
@ IN SOA ns1.intra.morori.jp. root.morori.jp. (
2025062801
28800
14400
3600000
86400
)
IN NS ns1
IN MX 10 smtp
ns1 IN A 10.1.1.2
ns2 IN A 10.1.1.3
smtp IN A 10.1.1.4
delegate-test IN NS ns1.delegate-test // 任意のホスト名で OK、Glue レコードを忘れないように
delegate-test IN NS ns2.delegate-test // 同上
ns1.delegate-test IN A 10.128.130.26 // Glue レコードは Route 53 インバウンドエンドポイントの IP アドレスにする
ns2.delegate-test IN A 10.128.28.1 // 同上
権威 DNS サーバー側はこれで完了です。次にリゾルバー DNS サーバーを設定します。
リゾルバー DNS サーバー
これから新規でリゾルバー DNS サーバーを構築する場合は、大元の独自ドメインに対する名前解決を権威 DNS サーバーへ転送するだけの設定で OK です。
以下の記事のように既に Route 53 インバウンドエンドポイントに条件付きフォワーダーを設定している場合、リゾルバー DNS サーバーには元のドメインの名前解決を権威 DNS サーバーへ転送し、サブドメインを Route 53 インバウンドエンドポイントへ転送していると思います。この場合はサブドメインへの転送設定を削除するだけで大丈夫です。
以下設定例です。
acl "intranets" {
10.1.0.0/16; # オンプレミスのサブネット
10.128.0.0/16; # VPC のサブネット
};
options {
listen-on port 53 { 10.1.1.3; }; # リゾルバー DNS サーバーの IP アドレス
allow-query { localhost; intranets; };
recursion yes;
dnssec-validation no; // yes だと転送に失敗するので注意
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/intra.morori.jp.zones";
zone "intra.morori.jp" IN {
type forward;
forward only;
forwarders { 10.1.1.2; }; # オンプレミスのドメインの権威 DNS サーバーの IP アドレス
};
これでサブドメインの委任に関する設定は全て完了です。
名前解決の確認
それではオンプレミスのクライアントからリゾルバー DNS サーバーに対し、サブドメインが委任されている Route 53 プライベートホストゾーンに登録しているホスト名を名前解決してみます。
ちゃんと名前解決ができました。これでリゾルバー DNS サーバーにサブドメインの条件付きフォワーダー設定を入れなくてもよくなりました。
委任の設定をしながら別ドメインへの条件付きフォワーダーは使えるか？
はい、大丈夫でした。確認してみます。
別ドメインのプライベートホストゾーンの作成
これまで委任設定したドメイン（intra.morori.jp のサブドメイン）と完全に別なドメイン（forward-test.morori.jp）のプライベートホストゾーンを作成し、fuga.forward-test.morori.jp というホストを登録します。
オンプレミスのリゾルバー DNS サーバーの設定
以下のとおり forward-test.morori.jp への条件付きフォワーダーの設定を追記します。
zone "intra.morori.jp" IN {
type forward;
forward only;
forwarders { 10.1.1.2; }; # オンプレミスのドメインの権威 DNS サーバーの IP アドレス
};
# 以下追記
zone "forward-test.morori.jp" IN {
type forward;
forward only;
forwarders { 10.128.130.26; 10.128.28.1; }; # インバウンドエンドポイントの IP アドレス
};
別ドメインへの条件付きフォワーダーの確認
この別ドメインのホスト fuga.forward-test.morori.jp を名前解決してみます。
正しく名前解決ができました。委任設定をした Route 53 インバウンドエンドポイントであっても、引き続き条件付きフォワーダーの転送先としても機能することが確認できました。
別アカウントの Route 53 プライベートホストゾーンにも委任はできる？
はい、大丈夫です。委任設定した Route 53 インバウンドエンドポイントのある VPC に別アカウントの Route 53 プライベートホストゾーンを関連づけてやれば委任できます。確認してみます。
別アカウントにサブドメインの Route 53 プライベートホストゾーンを作成
Route 53 インバウンドエンドポイントを作ったアカウントとは別のアカウントで Route 53 プライベートホストゾーンに、オンプレミスの権威 DNS のドメイン（intra.morori.jp）のサブドメインのホストゾーン（delegate-test02.intra.morori.jp）を作成します。また、gcas.delegate-test02.intra.morori.jp というホストを登録しておきます。
Route 53 インバウンドエンドポイントのある VPC への関連付け
この別アカウントから、以下のとおり作成した Route 53 プライベートホストゾーンを、Route 53 インバウンドエンドポイントのある元のアカウントの VPC へ AWS CLI で関連付けを要求します。
$ aws route53 create-vpc-association-authorization --hosted-zone-id （プライベートホストゾーンの ID） --vpc VPCRegion=ap-northeast-1,VPCId=（インバウンドエンドポイントのある VPC ID） --region ap-northeast-1
要求を受けた元のアカウントの方で、関連付けを承認します。
$ aws route53 associate-vpc-with-hosted-zone --hosted-zone-id （プライベートホストゾーンの ID） --vpc VPCRegion=ap-northeast-1,VPCId=（インバウンドエンドポイントのある VPC ID） --region ap-northeast-1
少し待つと、別アカウントの Route 53 プライベートホストゾーンが元のアカウントの VPC に関連づけられたことが確認できます。
元のアカウントの方で、念のため関連付けの承認を削除しておきます（関連付け自体を消すわけではありません。）
$ aws route53 delete-vpc-association-authorization --hosted-zone-id （プライベートホストゾーンの ID） --vpc VPCRegion=ap-northeast-1,VPCId=（インバウンドエンドポイントのある VPC ID） --region ap-northeast-1
オンプレミスの権威 DNS サーバーの設定
別アカウントの Route 53 プライベートホストゾーンに作成したサブドメインへ委任する設定を、権威 DNS サーバーへ追加します。
$TTL 86400
@ IN SOA ns1.intra.morori.jp. root.morori.jp. (
2025070501
28800
14400
3600000
86400
)
IN NS ns1
IN MX 10 smtp
ns1 IN A 10.1.1.2
ns2 IN A 10.1.1.3
smtp IN A 10.1.1.4
delegate-test IN NS ns1.delegate-test
delegate-test IN NS ns2.delegate-test
ns1.delegate-test IN A 10.128.130.26 // インバウンドエンドポイントの IP アドレス
ns2.delegate-test IN A 10.128.28.1 // 同上
// 以下追記
delegate-test02 IN NS ns1.delegate-test02
delegate-test02 IN NS ns2.delegate-test02
ns1.delegate-test02 IN A 10.128.130.26 // 同上
ns2.delegate-test02 IN A 10.128.28.1 // 同上
別アカウントの Route 53 プライベートホストゾーンへの委任の確認
この別アカウントの Route 53 プライベートホストゾーンのホスト gcas.delegate-test02.intra.morori.jp の名前解決をしてみます。
ちゃんと別アカウントの Route 53 プライベートホストゾーンであっても名前解決ができ、委任できていることが確認できました。
別アカウントの Route 53 プライベートホストゾーンへの条件付きフォワーダーも使える？
はい、大丈夫です。手順は省略しますが、Route 53 インバウンドエンドポイントのある VPC に関連付けさえすれば、別アカウントの Route 53 プライベートホストゾーンであってもちゃんと条件付きフォワーダーが機能します。
今後サブドメインの名前解決は条件付きフォワーダーではなく委任とすべきか？
実のところ小規模なドメイン管理であれば、条件付きフォワーダーでも手間の面で言えばあまり変わらないと思います。
しかし、サブドメインの委任を使う場合は、以下のメリットがあると思います。
- 必ず権威 DNS サーバーのゾーンにサブドメインと委任先を登録するので、勝手にサブドメインが増えることを防止し、統制がしやすくなる。
- 一部の DNS サーバーの実装で、自身が管理するドメインのサブドメインの条件付きフォワーダーに対応していないものがある（例・リゾルバー兼権威 DNS サーバーにした時の BIND など）ので、この場合でも委任なら可能である。
そのため、地方自治体の基幹システムのガバメントクラウド移行に関しては、これから構築するのであればサブドメインの名前解決は委任をお勧めかもしれません。
なお、Route 53 インバウンドエンドポイントで委任を使っても、費用は従前と変わりません。
Inbound and outbound delegation is provided at no additional cost to Resolver endpoints usage.
既に Route 53 インバウンドエンドポイントを構築済みの場合は、一度削除して作り直さなければ Delegation を選べないため、削除のタイミングでネットワークの停止が発生することから、運用管理補助者と相談になると思います。無理に移行することもないとは思います。
以上、ガバメントクラウドでも今後使われる設定になりそうだったので、いち早く検証してみました。誰かの役に立てると幸いです。ｼﾞｰｷｬｽ!!