AWS Route 53 Resolver には、BIND のような「セカンダリゾーン（ゾーン転送で複製を持つ設定）」はありません。Resolver で「セカンダリ」に相当するのは、転送先の DNS を2台以上登録すること、エンドポイントの IP を複数のアベイラビリティーゾーンに置くこと、オンプレミス側から複数のインバウンド IP へ転送させることの3つです。この記事では、ハイブリッド構成の名前解決を1台の故障で止めないための設定と、その確かめ方を説明します。
同じシリーズの「Route 53 Resolver で複数ドメインを管理する方法」が「どのドメインをどこへ振り分けるか」を扱うのに対し、この記事は「振り分けた先が落ちても解決を続けるにはどうするか」に絞っています。AWS の仕様は更新が多いため（2026年10月現在）、コマンドは例として扱い、実行前に公式ドキュメントで引数と制約を確認してください。
「セカンダリ」を探している人が本当に必要なもの
検索してこの記事にたどり着く人の目的は、おおむね次のどれかです。
- AWS からオンプレミスの DNS を引くとき、プライマリ DNS が落ちてもセカンダリ DNS で答えてほしい
- オンプレミスから AWS のプライベートホストゾーンを引くとき、受け口を冗長化したい
- Route 53 を既存の DNS サーバーのセカンダリ（またはその逆）にしたい
1と2は Resolver の設定で実現できます。3は Resolver の機能ではなく、しかも Route 53 はゾーン転送（AXFR・IXFR）による複製に対応していないため、別の方法が必要です。以下で順に説明します。
前提：Resolver のエンドポイントとは
Route 53 Resolver は、VPC 内からの問い合わせに答える VPC 用のキャッシュ DNS です。VPC の外と名前解決をつなぐために、2種類のエンドポイントを作ります。
- アウトバウンドエンドポイント: VPC からの問い合わせを、転送ルールに従ってオンプレミスなどの DNS へ送り出す出口です。
- インバウンドエンドポイント: オンプレミスなどからの問い合わせを VPC の Resolver で受ける入口です。
どちらのエンドポイントも、作成時に2つ以上の IP アドレスを指定する必要があります。それぞれの IP は、指定したサブネットにネットワークインターフェースとして作られます。
冗長化1：エンドポイントの IP を別々の AZ に置く
エンドポイントの IP を同じアベイラビリティーゾーン（AZ）のサブネットに集めると、その AZ の障害でエンドポイント全体が使えなくなります。最低でも2つの AZ に分けて配置します。
# アウトバウンドエンドポイントの例（2つのAZのサブネットに1つずつ）
aws route53resolver create-resolver-endpoint \
--name outbound-hybrid \
--creator-request-id outbound-hybrid-001 \
--direction OUTBOUND \
--security-group-ids sg-0123456789abcdef0 \
--ip-addresses SubnetId=subnet-az-a-1111 SubnetId=subnet-az-c-2222問い合わせ量が多い環境では、IP の数を増やして処理能力に余裕を持たせます。1つの IP あたりで処理できる問い合わせ量の目安や、追加できる IP の上限は公式ドキュメントのクォータの項目に記載されているので、それを基に見積もります。
既存のエンドポイントに IP を足す場合は、作り直さずに追加できます。
aws route53resolver associate-resolver-endpoint-ip-address \
--resolver-endpoint-id rslvr-out-0123456789abcdef0 \
--ip-address SubnetId=subnet-az-d-3333冗長化2：転送先にプライマリとセカンダリの両方を登録する
AWS から社内ドメインを引く構成で、オンプレミスにプライマリ DNS とセカンダリ DNS がある場合は、転送ルールのターゲットに両方の IP を登録します。これが「Resolver のセカンダリ設定」として最もよく求められるものです。
aws route53resolver create-resolver-rule \
--name fwd-corp-example-com \
--creator-request-id fwd-corp-ha-001 \
--rule-type FORWARD \
--domain-name corp.example.com \
--resolver-endpoint-id rslvr-out-0123456789abcdef0 \
--target-ips "Ip=10.10.0.10,Port=53" "Ip=10.20.0.10,Port=53"既存のルールに転送先を足す場合は、ルールの更新で全体のターゲット一覧を指定し直します。
aws route53resolver update-resolver-rule \
--resolver-rule-id rslvr-rr-0123456789abcdef0 \
--config '{"TargetIps":[{"Ip":"10.10.0.10","Port":53},{"Ip":"10.20.0.10","Port":53}]}'ここで注意したい点が二つあります。
一つ目は、Resolver はターゲットを「1番目が正、2番目が予備」という厳密な順番では扱わないことです。応答しないターゲットを避けて別のターゲットへ問い合わせる動きはありますが、平常時にどの割合でどれへ送るかは公開情報からは細かく決められません。プライマリとセカンダリの DNS が、同じゾーンについて同じ答えを返す状態を保っておくことが前提になります。
二つ目は、2台の DNS を同じ拠点・同じ回線の先に置くと、回線障害で両方に届かなくなることです。可能であれば、別拠点や別経路の DNS をターゲットに含めます。
冗長化3：オンプレミス側から複数のインバウンド IP へ転送する
オンプレミスから AWS のプライベートホストゾーンを引く場合は、社内 DNS サーバーに「このドメインはインバウンドエンドポイントへ転送する」という条件付きフォワーダーを設定します。このとき、インバウンドエンドポイントの IP を2つ以上すべて登録します。
# BIND の例（named.conf）
zone "aws.example.internal" {
type forward;
forward only;
forwarders { 10.0.1.53; 10.0.2.53; };
};IP は自分のインバウンドエンドポイントのものに置き換えます。Windows Server の DNS でも、条件付きフォワーダーに複数の IP を登録できます。1つしか登録しないと、その IP がある AZ の障害で社内から AWS の名前が引けなくなります。
リージョン障害まで考える場合
エンドポイントとルールはリージョン単位のリソースです。一つのリージョン全体に問題が起きた場合まで備えるなら、別のリージョンの VPC にもエンドポイントとルールを用意し、オンプレミス側の転送先にも両リージョンのインバウンド IP を含める、といった設計になります。構成が複雑になるため、どの程度の障害まで備えるかを先に決めてから検討します。
Route 53 を「セカンダリ DNS」にしたい場合
公開ドメインの権威 DNS を2つの事業者で冗長化したい、既存の BIND をプライマリにして Route 53 をセカンダリにしたい、という目的なら、Resolver ではなくホストゾーンの話になります。Route 53 はゾーン転送を受け付けないため、次のような方法をとります。
- Terraform や API を使い、同じレコード定義から Route 53 と別の DNS の両方へ反映する
- レジストラに両方の事業者のネームサーバーを登録する
この構成では、片方だけを変更して答えが食い違うことが最大のリスクです。また、DNSSEC を使う場合は、複数の事業者で署名を整合させる必要があり、難度が上がります。
冗長化が効いているかを確かめる
設定しただけでは、片方が落ちたときの動きは分かりません。メンテナンス時間などに、次の点を確認しておきます。
# VPC 内の EC2 から、Resolver 経由で社内ドメインを引く
dig app.corp.example.com @169.254.169.253 +noall +answer +stats
# オンプレミスから、インバウンドエンドポイントの各IPへ個別に問い合わせる
dig db.aws.example.internal @10.0.1.53 +noall +answer
dig db.aws.example.internal @10.0.2.53 +noall +answer- 転送先の DNS を1台ずつ止め（または通信を一時的に遮断し）、Resolver 経由の問い合わせが応答し続けるか、応答時間がどの程度延びるかを見ます。
- インバウンドエンドポイントの各 IP へ個別に問い合わせ、どちらからも答えが返るかを確認します。
- Resolver のクエリログと、エンドポイントの CloudWatch メトリクスで、問い合わせが偏っていないか、エラーが出ていないかを定期的に確認します。
本番環境で遮断を試すと影響が出るため、検証用の VPC で同じ構成を作って試すか、影響の少ない時間帯を選び、関係者に周知してから行ってください。
まとめ
- Route 53 Resolver にはゾーン転送によるセカンダリゾーンの機能はありません。冗長化は複数の IP と転送先で行います。
- エンドポイントの IP は2つ以上を別々の AZ に置き、転送ルールのターゲットにはプライマリとセカンダリの DNS を両方登録します。
- オンプレミスの条件付きフォワーダーには、インバウンドエンドポイントの IP をすべて登録します。
- 公開ドメインの権威 DNS を Route 53 と別の DNS で冗長化する場合は、ゾーン転送ではなく IaC や API で両方へ同じレコードを反映します。
- 1台ずつ止めて応答が続くかを、検証環境や影響の少ない時間に確かめておきます。