はじめに

Amazon Route 53 Global Resolver (Preview)が発表されたとのことで、簡易ではありますがお試しをしてみました。

今回試した内容は、2025年12月2日時点の内容、Amazon Route 53 Global Resolver (Preview)もGA前であることと、私の主観での結果となるため、本番利用や検証される際には、サービス仕様をご自身でも確認のうえで利用ください。

Amazon Route 53 Global Resolver (Preview)について

公式のBlog記事および技術ドキュメントは以下のようです。

・公式Blogでの発表記事
Introducing Amazon Route 53 Global Resolver for secure anycast DNS resolution (preview)
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/amazon-route-53-global-resolver-secure-anycast-dns-resolution-preview/

・サービスの説明ページ
Amazon Route 53 Global Resolver (Preview)
https://aws.amazon.com/jp/route53/global-resolver/

・技術ドキュメントページ(DeveloperGuide)
What is Route 53 Global Resolver?
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/gr-what-is-global-resolver.html

ドキュメントから確認した大まかな仕様

インターネットの世界から直接アクセス可能なResolver
IP Anycastを用いたエンドポイントの提供
インターネット向けのResolverとしてとAWS Route53のPrivate Hosted Zoneへの名前解決ができる
UDP/TCP 53(Do53)、DoH（DNS over HTTPS）、DoT（DNS over TLS）のサポート
Source IPに対してのアクセス制限ができる
DoHなど向けのTokenを生成できる
ドメイン名のフィルタリングが可能(マネージドルールやカスタムルール)
Domain Generation Algorithm(DGA)などのマルウエア通信の名前解決検出ができる
View機能(クライアントごとに異なる名前空間、フィルターなどのポリシーを設定できる)
DNSSEC Validationサポート(ネガティブトラストアンカーの設定はなさそう)
EDNS Client Subnet(ECS)サポート
Query logなどのログ取得ができる

結構な機能が盛りだくさんのマネージド型Full-service Resolverといったところでしょうか。
私は世のマネージド型のResolverは利用したことがないので、具体な製品名との比較はできませんが、Private Hosted Zoneのようなゾーン設定ができたり、View的な機能は良さそうかもしれません。

View機能については、最近の方はISC BINDなどで構築される方も少ないとは思いますが、昔は結構View機能は使われてるイメージもあったりしており、Viewを用いてRoute53のPrivate Hosted Zoneへの名前解決とかの振り分けができるのも、BINDなどでやっていた方にはイメージがつきやすいのではないでしょうか。

そして、気になる料金ですが、現時点では価格はまだ未掲載のようです。（どこかに載ってたら申し訳ないです）

ただし、現時点では以下のような記載とのこと。

Visit the service page for Global Resolver pricing and feature details. During the preview, Global Resolver will be available at no additional cost.

また、今現在利用ができるリージョン(Preview時点)

米国東部（バージニア北部）リージョン
米国東部（オハイオ）地域
米国西部（北カリフォルニア）地域
米国西部（オレゴン）地域
ヨーロッパ（フランクフルト）地域
ヨーロッパ（アイルランド）地域
ヨーロッパ（ロンドン）地域
アジア太平洋（ムンバイ）地域
アジア太平洋（シンガポール）地域
アジア太平洋（東京）地域
アジア太平洋（シドニー）地域

使ってみよう

リソースを作成する

今回の作業事例では、「AdministratorAccess」相当の権限を利用して操作しておりますので、適切なIAM権限を設定したユーザでの操作が必要です。

マネージドコンソール(日本語表示で操作)で Route53 と入れると、「Amazon Route 53 グローバルリゾルバー」がありますので、こちらを選択。

もしくは、Route53を選択して、左のメニューペインから「グローバルリゾルバー」でも辿れます。

グローバルリゾルバーについてのページが開きましたら、「グローバルリゾルバーを作成」を押します

「リゾルバー名」へ管理上の名前を入力。「リージョン」で「2つ以上のリージョン」を選択します。今回は、東京とオハイオを選択し作成をしました。

リージョン選択は、おそらくコントロールプレーンの指定先を指している様な気もしていますが、ドキュメントにも細かくは記載もなく、私自身がAWSについても大変詳しいわけでもなくよくわかっておりません。
リージョンを2つ指定していても、名前解決自体はIP Anycastとなるので、その点については関係はしていないと考えます。また、仮に3リージョンを選択した場合でも以後のResolverのIPアドレスの払い出しは2 IPと変わらずでした。

作成を押すとこのような画面になります。
画像ではステータスが作成中ですが、ここが「実行中」に変わるまで待ちます。（私は10分くらいかかりました）
作成が完了すると、エンドポイントとなる2つのIPv4アドレスが払い出されます。

払い出されたIPを直打ちでも利用可能ですが、2つのIPアドレスをAレコードとして設定したFQDNが作成されますので、「グローバルリゾルバー」の設定ページに戻り確認しましょう。確認しづらいのですが、右端にFQDNが表示されています。形式は「[グローバルリゾルバー作成次に振られるID].route53globalresolver.global.on.aws.」のような形です(以後、記事の中では[払い出されたDNS名]として表記)。

|

次に、「DNSビュー」を作成しましょう。DNSのQueryを受けるためには作成が必要になります。まずは、UDP/TCP 53での受付ができるものを作成してみましょう。

設定画面ですが、「DNSビュー名」に名前を入力。お好みで「DNSSEC検証(Validation)」、「ファイアウォールルールがオープンに失敗する動作」、「EDNS クライアントサブネット」についての有効・無効を選択します。
「ファイアウォールルールがオープンに失敗する動作」というのは、フィルタなどのルールで不具合があった際にDNSの応答を継続させるかどうかの設定のようです。(検証してないので不明)

DNSビューの作成が完了すると、作成したDNSビューの設定画面に遷移します。(これも作成に時間がかかる)

次に、DNS Queryを受付するためにQueryを投げる元となるネットワークのGlobal IP(Public IP)アドレスを許可する設定をします。「アクセスソース」タブの「アクセスソースを作成」から設定をします。

動作確認としては、一旦この時点でdigなどで払い出されたDNS名または払い出されたIPv4のどちらかにdigなどで名前解決が「できないこと」を確認しておくと許可したあとに操作がわかりやすいかもしれません。

❯ dig @[払い出されたDNS名] example.com

; <<>> DiG 9.10.6 <<>> @[払い出されたIPv4のどちらか] example.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

❯

設定画面の項目としては、「ルール名」を入力、「CIDRブロック」にはDNS Queryを投げる元のGlobal IP(Public IP)アドレスを入れます。CIDRを広く入れることができますが、検証などでの利用の際は、「/32」での設定をしたほうが良いでしょう。「プロトコル」については「Do53」(UDP/TCP Port 53受付)を選択。

これの設定後(これまた数分)後に、digなどで払い出されたIPアドレス向けにdigなどで名前解決が「できること」を確認できるようになります。

動作確認をしてみる

ここからdigではなくkdigコマンドを利用して確認します。kdigコマンドインストールについては説明を省いています。

名前解決の確認をしてみましょう。例では、UDPでの名前解決でNOERRORでANSWER SECTIONも取得できています。ちなみにQuery Timeは早くて30msecくらいで、150msec台が多かったです。これはネットワークの経路などに左右されるので各環境でかわります。また、例ではいわゆる正引きのみですが、逆引きもできました。(当然ですが。。)

❯ kdig @[払い出されたDNS名] example.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: XXXXX
;; Flags: qr rd ra; QUERY: 1; ANSWER: 6; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; example.com.        		IN	A

;; ANSWER SECTION:
example.com.        	255	IN	A	23.215.0.136
example.com.        	255	IN	A	23.215.0.138
example.com.        	255	IN	A	23.220.75.232
example.com.        	255	IN	A	23.220.75.245
example.com.        	255	IN	A	23.192.228.80
example.com.        	255	IN	A	23.192.228.84

;; Received 136 B
;; Time 2025-12-02 XX:XX:XX JST
;; From [払い出されたIPv4のどちらか]@53(UDP) in 140.1 ms

❯

TCPでの名前解決も確認してみましょう。

❯ kdig +noall +ans +stat @[払い出されたDNS名] example.com +tcp
example.com.        	32	IN	A	23.215.0.138
example.com.        	32	IN	A	23.220.75.232
example.com.        	32	IN	A	23.220.75.245
example.com.        	32	IN	A	23.192.228.80
example.com.        	32	IN	A	23.192.228.84
example.com.        	32	IN	A	23.215.0.136

;; Received 136 B
;; Time 2025-12-02 XX:XX:XX JST
;; From [払い出されたIPv4のどちらか]@53(TCP) in 145.7 ms

❯

TCPでの名前解決もできていそうです。

DNSファイアウォールルールを試す

特定のドメインの名前解決をフィルタしてみます。今回は自身で管理する「ドメイン名」リストを用いる手法で試します。

「ドメインリスト」を編集するには、「DNSビュー」の設定画面ではなく、「グローバルリゾルバー」の設定画面まで戻り、「ドメインリスト」タブから「ドメインリストを作成」を押します。

「ドメインリスト名」を入力して、リストを作成

作成後に、「ドメインリスト」の設定画面に遷移するので、「ドメインを追加」を押します。

ドメイン名リストについては、S3からのリスト読み込みまたは手入力での設定が可能なようです。今回は手入力で試しますので、「ドメインを手動で設定」を選択し、表示されるテキストフィールドに対象のドメイン名を入れます。

設定がされるとこの様になります。また、こちらも反映までに少し時間がかかります。

続いて、「DNSビュー」の設定画面に遷移し、「DNS ファイアウォールルール」にてルールを作成。

「ルール名」を入力。

ルールの設定で今回は先ほど作成した、「ドメインリスト」を使用してみますので、「ルール設定タイプ」で「顧客マネージドドメインリスト」を選び、「ドメインリスト」のプルダウンにて、先ほど作成した「ドメインリスト」のリスト名を選択します。
次に、フィルタする際のクエリタイプを必要に応じて選択。今回はレコードタイプ「A」で設定。

最後に「ルールアクション」を設定します。
今回はルールとして「ブロック」アクションとして、「NXDOMAIN」を返すルールにしてみます。

作成すると以下のようになります。こちらも作成後の反映に時間がかかります。(画像では作成中)

ステータスが「実行中」になりましたら、名前解決を確認してみましょう。
フィルターが適用されて、「NXDOMAIN」になりました。
この際に、フィルターに適用していないドメイン名の名前解決をして、フィルター設定した以外のドメイン名の名前解決はされることを確認しておく良いでしょう。

❯ kdig @[払い出されたDNS名] example.com
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: XXXXX
;; Flags: qr aa rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; example.com.        		IN	A

;; Received 29 B
;; Time 2025-12-02 XX:XX:XX JST
;; From [払い出されたIPv4のどちらか]@53(UDP) in 36.1 ms

❯

Private Hosted Zoneの関連付をする

Private Hosted Zoneの作成方法については今回は既に作成されている前提で進めます。

「DNSビュー」の設定画面から「プライベートホストゾーン」のタブから「プライベートホストゾーンの関連付ける」を選択します。

適用したいPrivate Hosted Zoneを選択します。
こちらも反映に少し時間がかかります。

名前解決を確認してみましょう。
以下の例では無事、Global IP(Public IP)のクライアントからAWS Route53 Private Hosted ZoneのFQDNの名前解決ができました。(設定したのは自分でしかわからないのでこの例ではわからないと思いますが)

ちなみに、Publicで利用しているドメイン名と同じものを利用している場合は注意が必要な場合がありそうです。
少なくとも設定反映前に名前解決をしてしまうと、Global Resolver上でPublicのネットワーク上からのネガティブキャッシュなのかNSなのかキャッシュが残ってしまい、名前解決に失敗することがあるように見受けられました。

なお、上記のようなキャッシュがされていない場合(検証操作をしなかったドメイン)は、Publicで利用しているドメイン名を用いたPrivate Hosted Zoneでも、Private Hosted Zoneで設定したリソースレコードの内容の応答が優先されるのを確認してます。

細かく調べられていませんが、単にPublic Hozted Zoneの反映が遅かっただけの可能性も大いにあります。

❯ kdig @[払い出されたDNS名] [Private Hosted Zoneで設定してるFQDN]
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: XXXXX
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; [Private Hosted Zoneで設定してるFQDN]		IN	A

;; ANSWER SECTION:
[Private Hosted Zoneで設定してるFQDN]		10	IN	A	192.0.2.100

;; Received 64 B
;; Time 2025-12-02 XX:XX:XX JST
;; From [払い出されたIPv4のどちらか]@53(UDP) in 36.7 ms

~
❯

DoHを試してみる

上記までは、「DNSビュー」設定画面での「アクセスソース」のプロトコルで「Do53」を選択した状態でした。
これを「Do53」から「DoH」に変更すると利用できます。

kdigの+httpsオプションを使って名前解決を確認してみます。

❯ kdig @[払い出されたDNS名] +https example.com
;; TLS session (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-128-GCM)
;; HTTP session (HTTP/2-POST)-([払い出されたDNS名]/dns-query)-(status: 200)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 0
;; Flags: qr rd ra; QUERY: 1; ANSWER: 6; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; example.com.        		IN	A

;; ANSWER SECTION:
example.com.        	92	IN	A	23.220.75.245
example.com.        	92	IN	A	23.192.228.80
example.com.        	92	IN	A	23.192.228.84
example.com.        	92	IN	A	23.215.0.136
example.com.        	92	IN	A	23.215.0.138
example.com.        	92	IN	A	23.220.75.232

;; Received 202 B
;; Time 2025-12-02 XX:XX:XX JST
;; From [払い出されたIPv4のどちらか]@443(HTTPS) in 225.4 ms

❯

名前解決ができたようです。この「DoH」に変更すると「Do53」でのUDP/TCP 53の受付はできなくなります。

トークンを用いたDoHを試してみる

トークンを用いた制御の場合は、「アクセスソース」設定で設定しているCIDRに制限されず、認証を用いて名前解決をできるようです。(アクセスソース側の設定とは別の制御になる)

「DNSビュー」設定画面から「アクセストークン」タブから「アクセストークンを作成」を押します。

「トークン名」を入力します。
「トークンの有効期限」は今回はデフォルトの「365日」のままにしています。

トークンの作成ができるとこのような形になります。

実際のトークンを取得するには、トークンIDをクリックし、以下のトークン項目の表示を押し確認します。

名前解決を確認してみましょう。
kdigの+httpsオプションからトークンを指定して名前解決してみます。

❯ kdig @[払い出されたDNS名] \
  +https="/dns-query?token=[生成したトークンを指定]" \
  example.com
  
;; TLS session (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-128-GCM)
;; HTTP session (HTTP/2-POST)-([払い出されたDNS名]/dns-query?token=[生成したトークン])-(status: 200)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 0
;; Flags: qr rd ra; QUERY: 1; ANSWER: 6; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; example.com.        		IN	A

;; ANSWER SECTION:
example.com.        	178	IN	A	23.192.228.84
example.com.        	178	IN	A	23.215.0.136
example.com.        	178	IN	A	23.215.0.138
example.com.        	178	IN	A	23.220.75.232
example.com.        	178	IN	A	23.220.75.245
example.com.        	178	IN	A	23.192.228.80

;; Received 202 B
;; Time 2025-12-02 XX:XX:XX JST
;; From [払い出されたIPv4のどちらか]@443(HTTPS) in 240.9 ms

❯

トークンを用いた制御での名前解決ができることの確認もできました。

まとめ

本記事の中で試したこと。

Amazon Route 53 Global Resolverの作成
Viewの作成
作成したAmazon Route 53 Global ResolverへGlobal IP(Public IP)クライアントからの名前解決
Private Hosted ZoneのリソースレコードのGlobal IP(Public IP)クライアントからの名前解決
UDP/TCP Port53向け、トークン無しでのDoHでの名前解決
DoHでのトークンを利用した名前解決
を実施してみました。

他にも、DNSSEC Validation、EDNS Client Subnet(ECS)の設定とQuery log周りのモニタリングやマネージドルールでのフィルタリングなど他にも機能確認や様々なリソースレコードの名前解決時の応答の仕方を調べてみるなど確認してみたい項目が色々とありますが、今回はここまでになります。何かのご参考になりましたら幸いです。

個人的にはキャッシュクリア操作ができたり、DNSSEC Validationは好きでないですがネガティブトラストアンカーの設定などができると良いのになと思ったりもしました。