![[プレビュー] Route 53 Global Resolverが登場し、インターネットからRoute 53 Private Hosted Zoneの名前解決ができるようになりました #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/33a7q65plkoztFWVfWxPWl/a718447bea0d93a2d461000926d65428/reinvent2025_devio_update_w1200h630.png?w=3840&fm=webp)
[プレビュー] Route 53 Global Resolverが登場し、インターネットからRoute 53 Private Hosted Zoneの名前解決ができるようになりました #AWSreInvent
VPC外からRoute 53 Private Hosted Zoneで管理されているゾーンの名前解決を簡単に行いたい
こんにちは、のんピ(@non____97)です。
皆さんはVPC外からRoute 53 Private Hosted Zoneで管理されているゾーンの名前解決を簡単に行いたいなと思ったことはありますか? 私はあります。
VPC外からRoute 53 Private Hosted Zoneで管理されているゾーンの名前解決を行う場合は、Route 53 Resolver Inbound Endpointを用意して、DNSクライアントが参照するフルサービスリゾルバー上で条件付きフォワーダーを設定したり、名前解決可能な親ゾーンのDNSサーバーで委任をしたりする必要があります。
具体的な構成は以下記事に記載しています。
ただし、Route 53 Resolver Endpointは中々の料金がしますし、構成的にも複雑になりがちです。
今回、プレビューですが、Route 53 Global Resolverが登場しました。
AWS Blogsにも記事が投稿されていますね。
これにより、インターネットからPrivate Hosted Zoneの名前解決を簡単に行うことが可能になります。
その他にも特徴があるので、以降詳細を説明します。
いきなりまとめ
- Route 53 Global Resolverとはインターネットから利用可能なマルチリージョン展開されているエニーキャストのDNSフルサービスリゾルバー
- DNSクエリの裏側でネットワークトポロジとレイテンシーに基づいて、事前に指定した最も近いAWSリージョンにルーティングをしてくれる
- プライマリのリージョンが利用できなくなった場合でも、別リージョンへ自動フェイルオーバーにしてくれる
- DNSクライアントが名前解決時に参照するフルサービスリゾルバーのIPアドレスは変更せずに利用可能
- 利用をする際はRoute 53 Global Resolverに少なくともDNSビューとアクセスソースを指定する必要がある
- DNSビューとはアクセスソースやDNSファイアウォール、Private Hosted Zone、アクセストークンの設定をまとめたもの
- アクセスソースとは承認されたDNSクライアントを指定するもの
- 未指定の場合はそのDNSビューに基づいた名前解決はできない
- いずれのDNSビュー上にマッチするアクセスソースの定義がない場合、Global Resolverで名前解決できない
- アクセスソースを送信元のCIDRブロックで定義している場合、適用されるDNSビューの優先度は定義されているCIDRブロックと送信元IPアドレスのロンゲストマッチとなる
- VPC外のDNSクライアントを含めて簡単にスプリットホライズンDNS(スプリットビューDNS)の実装が可能
ドキュメントから仕様を確認
概要
まず、以下ドキュメントから仕様を確認します。
Route 53 Global Resolverとはインターネットから利用可能なマルチリージョン展開されているエニーキャストのDNSフルサービスリゾルバーです。
マルチリージョン展開されているエニーキャストのDNSフルサービスリゾルバーということで、単一のIPアドレスを指定して名前解決をした場合でも、DNSクエリの裏側でネットワークトポロジとレイテンシーに基づいて、事前に指定した最も近いAWSリージョンにルーティングをしてくれます。
エニーキャストDNSとは? という方は以下Cloudflare公式ドキュメントが分かりやすいです。
プライマリのリージョンが利用できなくなった場合でも、別リージョンへ自動フェイルオーバーにしてくれるため、DNSクライアントが名前解決時に参照するフルサービスリゾルバーのIPアドレスは変更せずに利用可能です。
Route 53 Global Resolverはインターネットから利用可能ではあるのですが、1.1.1.1や8.8.8.8のパブリックDNSおよび、オープンリゾルバーのように、誰でも使用できるフルサービスリゾルバーではありません。
以下のように送信元を制御して利用する形となります。
- アクセスソースベースの認証
- 送信元IPアドレスとプロトコルが事前に許可されているCIDR形式とDNSプロトコル(DNS-over-port-53/DNS-over-TLS/DNS-over-HTTPS)がマッチしているか
- トークンベースの認証
- 事前に発行したDoHとDoT用の暗号化トークンを使用しているか
これらはRoute 53 Global Resolver内に作成するDNSビューというコンテナ内に定義をします。
アクセスソースベースの認証として、IPアドレスベースで名前解決結果を変更することは以下記事で紹介されているとおり以前から可能でしたが、/24よりも具体的なプレフィックスは指定できませんでした。
Route 53 Global Resolverでは/32とホストアドレスまで指定可能なので、かなり柔軟な定義が可能です。
また、DNSビューごとに関連付けるPrivate Hosted Zoneを選択することが可能です。これにより
「この送信元からこの名前解決のクエリを受け取った場合は、このゾーンに登録されているレコードを返す」
といった、スプリットホライズンDNS(スプリットビューDNS)を実現することが可能です。
Route 53 ResolverにおけるスプリットホライズンDNSについては以下記事で紹介されています。
同一ドメインの名前解決においても、内部ユーザーと外部ユーザーのどちらかの名前解決かで、Public Hosted Zoneから返すとか、Private Hosted Zoneから返すかを選択することが可能です。
セキュリティ
セキュリティの機能として以下がサポートされています。
- DNSSEC検証
- DNSフィルタリング
- DNSトンネリング検出
- ドメイン生成アルゴリズム（DGA）検出
- クエリログのS3/Data Firehose/ClodWatch Logsへの記録
DNSフィルタリングやDNSトンネリング検出、DGA検出については既存のRoute 53 Resolver DNS Firewallとほぼ同一の機能です。
カスタムドメインリストおよびAWSマネージドのドメインリストで名前解決可能なドメインの制限をかけることが可能です。
料金
プレビュー期間中は料金は請求されません。
プレビュー期間終了後に以下の料金が適用されます。
- 有効化したリージョン時間料金
- 最初の2つ : 1リージョンあたり 5.00 USD/h (DNSフィルタリングを使用しない場合は 4.50 USD/h)
- 追加リージョン : 1リージョンあたり 1.50 USD/h (DNSフィルタリングを使用しない場合は 0.75 USD/h)
- クエリ料金
- 最初の10億クエリを超過した分 : 1.50 USD/100万クエリ
参考 : Amazon Route 53 pricing - Amazon Web Services
Route 53 Resolver Endpointを用意しなければならなかったシチュエーションと比べるとかなりコストは減るのではないでしょうか。
ユースケース
ユースケースとしては以下が想定されています。
- スプリットホライズンDNSの実現
- 複雑なネットワーク設定なしに、社内リソースのプライベートIPアドレスを解決可能
- DNSに関する攻撃からの保護
- DoHやDoTを用いたDNSトラフィックの暗号化によるプライバシー強化
- DNSフィルタリングによる不審なリソースアクセスの防止
- DNSSECによるDNSスプーフィングやキャッシュポイズニング攻撃からの保護
- 高可用性の実現
- リージョンレベルでの障害が発生した場合でも継続して名前解決が可能
- 統一的な設定
- グローバルで割り振られた2つのエニーキャストのIPアドレスをクライアントに設定するだけで、以下を実現
- クエリを最も近い利用可能なリージョンにルーティング
- クエリ元のIPアドレスベースでの応答するDNSゾーンの調整
- グローバルで割り振られた2つのエニーキャストのIPアドレスをクライアントに設定するだけで、以下を実現
Route 53 VPC Resolverから乗り換える必要があるのか
Route 53 VPC Resolverから乗り換える必要があるのか気になるとことですが、無理に乗り換える必要はないと考えます。
ユースケースにマッチするような場合においては乗り換えを検討しましょう。
なお、EC2インスタンスなどVPC内のリソースが名前解決をする際に使用するDNSサーバーをRoute 53 VPC ResolverからRoute 53 Global Resolverに変更する場合においては、フルサービスリゾルバーへ到達するまでのホップ数が増えることになります。
Route 53 Global Resolverへ到達するにはパブリックIPアドレスを保持している。もしくはパブリックIPアドレスにNATする必要があります。そのため、その過程で不具合が発生した場合など通信経路に異常が発生した際には名前解決を行うことができなくなります。
使用可能なリージョン
2025/12/3時点で使用可能なリージョンは以下のとおりです。
- バージニア北部
- オハイオ
- 北カリフォルニア
- オレゴン
- フランクフルト
- アイルランド
- ロンドン
- ムンバイ
- シンガポール
- 東京
- シドニー
クォータ
クォータは以下のとおりです。
| リソース | デフォルトの割り当て | 調整可能 |
|---|---|---|
| アカウントあたりのGlobal Resolver | 2 | はい |
| グローバルリゾルバあたりの DNS ビュー | 5 | はい |
| アカウントあたりの DNS ビュー | 50 | はい |
| アカウントごとのドメインリスト | 1,000 | はい |
| ドメインリストごとのドメイン | 100,000 | はい |
| S3からインポートされたファイル内のドメイン | 10,000 | はい |
| すべてのファイアウォールルールのドメイン数 | 1,000,000 | はい |
| DNS ビューごとのファイアウォール ルール | 100 | はい |
| Global Resolverごとのアクセストークン | 5,000 | はい |
| Global Resolverあたりのアクセスソース | 1,000 | はい |
| Global ResolverごとのアクセスソースCIDRサイズ | 65,000 | いいえ |
| DNS ビューごとのPrivate Hosted Zoneの関連付け | 1,000 | はい |
| ログ配信構成（Global Resolver / 宛先タイプ / リージョンごと） | 1 | いいえ |
Route 53 Resolverの名前が変わります
Route 53 Global Resolverが発表されたことにより、従来のRoute 53 Resolver(より昔はAmazonProvidedDNS)の名前が Route 53 VPC Resolver に変わります。
そのまま「無印の方のRoute 53 Resolver」とは表現しづらいので、大歓迎です。
やってみた
Route 53 Global Resolverの作成
実際に試してみましょう。
まず、Route 53 Global Resolverの作成です。
この時マネジメントコンソールに表示されている構成イメージが非常に分かりやすいです。
Global Resolverの名前とリージョンを指定します。
リゾルバーはこれらのリージョンでミューテーションでき、後でこのリゾルバーのリージョンを変更することはできません。
とあるようにリージョンを追加することはできないため注意しましょう。
作成が開始されました。
グローバルリゾルバーを使用すると、インターネットや Route 53 プライベートホストゾーンのパブリックアプリケーションのドメインをどこからでも安全に解決できます。
という説明文にテンションが上がる人は多いのではないでしょうか。ロマンがあります。
また、IPv4アドレスが2つ払い出されていました。これはリージョンを2つ選択したためではありません。常に2つです。
Anycast IP addresses
Two unique IPv4 or IPv6 addresses assigned to your global resolver that you configure on client devices and network equipment. These anycast IP addresses are the same globally, which simplifies DNS configuration across all your locations. Anycast IP addressing enables automatic routing of DNS requests to the nearest global resolver, optimizing response times and improving service reliability.
Key concepts and components for Route 53 Global Resolver - Amazon Route 53
数分待つと実行中にステータスが変わりました。
なお、この状態で名前解決をしようとしてもできません。
> dig www.non-97.net @52.223.8.240
; <<>> DiG 9.10.6 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; connection timed out; no servers could be reached
これはDNSビューおよびアクセスソースを作成、定義していないためです。
1.1.1.1を指定した場合は正常に名前解決できました。
> dig www.non-97.net @1.1.1.1
; <<>> DiG 9.10.6 <<>> www.non-97.net @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63738
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 17 5b 32 36 30 30 3a 39 30 30 30 3a 35 33 30 30 3a 38 63 30 30 3a 3a 31 5d 3a 35 33 20 72 65 74 75 72 6e 65 64 20 52 45 46 55 53 45 44 20 66 6f 72 20 77 77 77 2e 6e 6f 6e 2d 39 37 2e 6e 65 74 20 41 ("..[2600:9000:5300:8c00::1]:53 returned REFUSED for www.non-97.net A")
;; QUESTION SECTION:
;www.non-97.net. IN A
;; ANSWER SECTION:
www.non-97.net. 60 IN A 13.32.230.77
www.non-97.net. 60 IN A 13.32.230.65
www.non-97.net. 60 IN A 13.32.230.85
www.non-97.net. 60 IN A 13.32.230.97
;; Query time: 121 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Dec 01 12:01:07 PST 2025
;; MSG SIZE rcvd: 178
DNSビューの作成
DNSビューの作成を行います。
DNSビュー名を指定します。他パラメーターは今回はデフォルトのままにしておきます。
作成開始されました。
なお、1分後には作成が完了しました。
アクセスソースの作成
まだ名前解決はできません。
> dig www.non-97.net @52.223.8.240
; <<>> DiG 9.10.6 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; connection timed out; no servers could be reached
アクセスソースの作成をして、名前解決できるようにしてあげましょう。
CIDRブロックには自端末に割り当てられたIPアドレスを指定します。一つのアクセスソースに指定できるCIDRブロックは一つです。大量のCIDRブロックを追加する場合は、都度アクセスソースを作成することになります。
アクセスソースの作成を開始して2分ほどで作成完了しました。
作成完了後には名前解決をトライすると、正常に名前解決できるようになっていました、
> curl http://checkip.amazonaws.com
104.28.235.55
> dig www.non-97.net @52.223.8.240
; <<>> DiG 9.10.6 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29600
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.non-97.net. IN A
;; ANSWER SECTION:
www.non-97.net. 60 IN A 143.204.160.48
www.non-97.net. 60 IN A 143.204.160.99
www.non-97.net. 60 IN A 143.204.160.123
www.non-97.net. 60 IN A 143.204.160.76
;; Query time: 217 msec
;; SERVER: 52.223.8.240#53(52.223.8.240)
;; WHEN: Mon Dec 01 13:24:04 PST 2025
;; MSG SIZE rcvd: 107
他クライアントからの場合はアクセスソースで定義されていないため名前解決は失敗しています。
$ curl http://checkip.amazonaws.com
44.197.117.247
$ dig www.non-97.net @52.223.8.240
;; communications error to 52.223.8.240#53: timed out
;; communications error to 52.223.8.240#53: timed out
;; communications error to 52.223.8.240#53: timed out
; <<>> DiG 9.18.33 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; no servers could be reached
めでたしめでたし。
ちなみにアクセスソースを編集しようとすると以下のようになります。CIDRブロックもプロトコルも自由に変更できそうです。
アクセスソースの更新
ということで実際にアクセスソースの更新を行います。
先ほど名前解決できなかったクライアントのIPアドレスをアクセスソースのCIDRブロックに指定します。
更新完了後に名前解決をすると、正常に名前解決できました。
$ dig www.non-97.net @52.223.8.240
; <<>> DiG 9.18.33 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29583
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.non-97.net. IN A
;; ANSWER SECTION:
www.non-97.net. 60 IN A 108.138.85.82
www.non-97.net. 60 IN A 108.138.85.24
www.non-97.net. 60 IN A 108.138.85.20
www.non-97.net. 60 IN A 108.138.85.44
;; Query time: 99 msec
;; SERVER: 52.223.8.240#53(52.223.8.240) (UDP)
;; WHEN: Tue Dec 02 09:13:56 UTC 2025
;; MSG SIZE rcvd: 107
更新完了までの時間は一分ほどでした。
Private Hosted Zoneの名前解決
続いて、Private Hosted Zoneで管理されているDNSレコードの名前解決です。
phz.test.corp.non-97.netというPrivate Hosted Zoneがあります。
Route 53 VPC ResolverおよびRoute 53 Global Resolverで名前解決できないことを確認します。
$ dig host.phz.test.corp.non-97.net
; <<>> DiG 9.18.33 <<>> host.phz.test.corp.non-97.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39863
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;host.phz.test.corp.non-97.net. IN A
;; Query time: 49 msec
;; SERVER: 172.31.0.2#53(172.31.0.2) (UDP)
;; WHEN: Tue Dec 02 09:17:06 UTC 2025
;; MSG SIZE rcvd: 58
$ dig host.phz.test.corp.non-97.net @52.223.8.240
; <<>> DiG 9.18.33 <<>> host.phz.test.corp.non-97.net @52.223.8.240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65477
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;host.phz.test.corp.non-97.net. IN A
;; Query time: 29 msec
;; SERVER: 52.223.8.240#53(52.223.8.240) (UDP)
;; WHEN: Tue Dec 02 09:17:15 UTC 2025
;; MSG SIZE rcvd: 58
この状態でPrivate Hosted ZoneをDNSビューに関連付けます。
関連付け完了後、再度トライするとRoute 53 VPC Resolverの場合は継続して名前解決できないところ、Route 53 Global Resolverは名前解決できることを確認できました。
$ dig host.phz.test.corp.non-97.net
; <<>> DiG 9.18.33 <<>> host.phz.test.corp.non-97.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15077
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;host.phz.test.corp.non-97.net. IN A
;; Query time: 39 msec
;; SERVER: 172.31.0.2#53(172.31.0.2) (UDP)
;; WHEN: Tue Dec 02 09:18:59 UTC 2025
;; MSG SIZE rcvd: 58
$ dig host.phz.test.corp.non-97.net @52.223.8.240
; <<>> DiG 9.18.33 <<>> host.phz.test.corp.non-97.net @52.223.8.240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32492
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;host.phz.test.corp.non-97.net. IN A
;; ANSWER SECTION:
host.phz.test.corp.non-97.net. 300 IN A 10.10.10.10
;; Query time: 9 msec
;; SERVER: 52.223.8.240#53(52.223.8.240) (UDP)
;; WHEN: Tue Dec 02 09:19:01 UTC 2025
;; MSG SIZE rcvd: 74
スプリットホライズンDNS
スプリットホライズンDNS(スプリットビューDNS)として動作するのか確認します。
wwww.non-97.netというPublic Hosted Zoneがあるのですが、さらにwwww.non-97.netのPrivate Hosted Zoneを作成します。
まだPrivate Hosted Zoneの関連付けを行なっていないため、Public Hosted Zoneに登録されているレコードが返ってきます。
$ dig www.non-97.net @52.223.8.240
; <<>> DiG 9.18.33 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23860
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.non-97.net. IN A
;; ANSWER SECTION:
www.non-97.net. 60 IN A 108.138.85.20
www.non-97.net. 60 IN A 108.138.85.24
www.non-97.net. 60 IN A 108.138.85.44
www.non-97.net. 60 IN A 108.138.85.82
;; Query time: 59 msec
;; SERVER: 52.223.8.240#53(52.223.8.240) (UDP)
;; WHEN: Tue Dec 02 09:28:35 UTC 2025
;; MSG SIZE rcvd: 107
wwww.non-97.netのPrivate Hosted ZoneをDNSビューに追加します。
この状態で名前解決すると、先ほどはPublic Hosted Zone上のレコードを返してきたところ、Private Hosted Zoneのレコードを返すようになりました。
$ dig www.non-97.net @52.223.8.240
; <<>> DiG 9.18.33 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46781
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.non-97.net. IN A
;; ANSWER SECTION:
www.non-97.net. 300 IN A 10.20.30.40
;; Query time: 9 msec
;; SERVER: 52.223.8.240#53(52.223.8.240) (UDP)
;; WHEN: Tue Dec 02 09:29:36 UTC 2025
;; MSG SIZE rcvd: 59
スプリットホライゾンDNSが上手く聞いていますね。
DNSビューの優先度の確認
DNSビューが複数ある場合は優先度はあるのでしょうか?
アクセスソースをCIDRブロックで指定しているのであるのであれば、CIDRブロックのロンゲストマッチなのでしょうか。
パッと見ではDNSビューの優先度を指定することはできませんでした。
DNSビュー間の優先度を指定する方法は見つからなかったので実際に確認します。
新しくPrivate Hosted Zoneを関連づけていないDNSビューを作成し、別のDNSクライアントのホストアドレスをアクセスソースのCIDRブロックに定義します。
この状態で名前解決をするとPublic Hosted ZoneのDNSレコードが返ってきました。
$ dig www.non-97.net @52.223.8.240
; <<>> DiG 9.18.33 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15192
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.non-97.net. IN A
;; ANSWER SECTION:
www.non-97.net. 60 IN A 108.138.85.24
www.non-97.net. 60 IN A 108.138.85.44
www.non-97.net. 60 IN A 108.138.85.20
www.non-97.net. 60 IN A 108.138.85.82
;; Query time: 170 msec
;; SERVER: 52.223.8.240#53(52.223.8.240) (UDP)
;; WHEN: Tue Dec 02 09:36:28 UTC 2025
;; MSG SIZE rcvd: 107
ロンゲストマッチか否かを判断するために最初に作成したPrivate Hosted Zoneが関連付けられているDNSビューにて、DNSクライアントのIPアドレスの/30のCIDRブロックを指定します。
アクセスソースの追加が完了するまで待って名前解決をしたところ、Public Hosted Zoneのレコードが返ってきました。
$ dig www.non-97.net @52.223.8.240
; <<>> DiG 9.18.33 <<>> www.non-97.net @52.223.8.240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61170
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.non-97.net. IN A
;; ANSWER SECTION:
www.non-97.net. 60 IN A 108.138.85.82
www.non-97.net. 60 IN A 108.138.85.20
www.non-97.net. 60 IN A 108.138.85.44
www.non-97.net. 60 IN A 108.138.85.24
;; Query time: 170 msec
;; SERVER: 52.223.8.240#53(52.223.8.240) (UDP)
;; WHEN: Tue Dec 02 09:48:56 UTC 2025
;; MSG SIZE rcvd: 107
おそらくロンゲストマッチで判定しているのでしょう。
なお、DNSビュー間であってもアクセスソースのCIDRブロックが重複している場合はConflictException [GR-ERR06200] An Access Source with the same cidr and protocol already exists in the global resolver.とエラーになります。
![20.ConflictException [GR-ERR06200] An Access Source with the same cidr and protocol already exists in the global resolver.png](https://devio2024-2-media.developers.io/upload/0RqxpJ2Gm3nEdxVLGKLWmq/2025-12-03/twJCct4FNPk3.png)
コストと手間なくPrivate Hosted Zoneの名前解決をしたい場合に
Route 53 Global Resolverの紹介をしました。
個人的にはコストと手間なくPrivate Hosted Zoneの名前解決をしたい場合に役立ちそうだと感じています。
オンプレミスリソースが参照しているDNSサーバーで条件付きフォワーダーでPrivate Hosted Zoneの名前解決をする際のフォワーダーとしてRoute 53 Global Resolverを指定してあげれば、Route 53 Resolver Inbound Endpointを作成する必要がなくなります。
もしかすると、EFSファイルシステムやVPCエンドポイントなどカスタマーマネージドのRoute 53 Private Hosted Zoneではない、Private Hosted Zoneで管理されているゾーンの名前解決する以外はRoute 53 Resolver Inbound Endpointは不要になるかもしれません。
GAが待ち遠しいですね。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
