2026年6月13日

AWS Route 53 Resolver でセカンダリ設定する手順｜クライアントの DNS 指定順と DHCP オプションセット、切り替わりの確かめ方

DNS・名前解決

EC2 などのクライアントで「プライマリは社内 DNS、セカンダリは Route 53 Resolver」（またはその逆）と指定するときは、2つの DNS が同じ名前に同じ答えを返す状態を先に作り、そのうえで DHCP オプションセットと OS の設定で順番とタイムアウトを決めます。順番だけ設定すると、「たまに社内の名前が引けない」という再現しにくい障害が起きやすくなります。この記事では、クライアント側から見たセカンダリ設定の手順と、切り替わりの確かめ方を説明します。

同じシリーズの「Route 53 Resolver のセカンダリ設定方法」は、エンドポイントの IP や転送先を複数にして Resolver 自体を冗長化する方法を扱っています。この記事はその手前、クライアントが2つの DNS をどう使い分けるかに絞っています。AWS の仕様や制限値は更新されることがあるため（2026年10月現在）、コマンドは例として扱い、実行前に公式ドキュメントで引数を確認してください。

前提：Route 53 Resolver のアドレス

VPC 内のクライアントから見た Route 53 Resolver（Amazon が提供する DNS）は、次のアドレスで使えます。

VPC のプライマリ CIDR の先頭に2を足したアドレス（例: 10.0.0.0/16 なら 10.0.0.2）
169.254.169.253（リンクローカルアドレス）
IPv6 の場合は fd00:ec2::253（Nitro ベースのインスタンス）

VPC の DNS サポート（enableDnsSupport）が無効だと、これらのアドレスは応答しません。また、ネットワークインターフェースごとに Resolver へ送れるパケット数には上限があり、問い合わせが多いサーバーでは上限に達して応答が欠けることがあります。上限値はドキュメントの制限の項目で確認してください。

「セカンダリ」はプライマリが落ちたときだけ使われるとは限らない

設定の前に理解しておきたいのは、クライアントの DNS 指定の順番は、多くの人が想像するほど厳密ではないことです。

Linux の glibc は、/etc/resolv.conf の上から順に問い合わせ、応答がない（タイムアウト）か、サーバーエラーが返ったときに次へ進みます。rotate オプションがあると順番に振り分けます。
systemd-resolved は、いま使っているサーバーが応答しなくなると次のサーバーへ切り替え、その後はしばらくそちらを使い続けることがあります。プライマリが復旧しても、すぐ戻るとは限りません。
Windows は、優先 DNS が一定時間応答しないと代替 DNS へ問い合わせます。

そして重要なのは、どの実装でも「その名前は存在しない」（NXDOMAIN）という答えは正常な応答として扱われ、セカンダリには問い合わせ直さないことです。

つまり、プライマリの社内 DNS だけが社内ドメインを知っていて、セカンダリの Resolver は知らない構成では、クライアントがセカンダリを使っている間だけ社内の名前が引けません。これを防ぐには、2つの DNS が同じ見え方をしている必要があります。

手順1：2つの DNS の見え方をそろえる

例として、EC2 上に Active Directory の DNS（10.0.1.10）があり、社内ドメイン corp.example.com を管理している構成を考えます。

Resolver をセカンダリにする場合は、Resolver が corp.example.com を AD の DNS へ転送するように、アウトバウンドエンドポイントと転送ルールを作り、VPC に関連付けます。これで、Resolver に聞いても社内の名前が返るようになります。

Resolver をプライマリにして AD の DNS をセカンダリにする場合は、AD の DNS のフォワーダーに Resolver（10.0.0.2）を設定し、AD の DNS に聞いてもインターネットの名前やプライベートホストゾーンが引けるようにします。

どちらの場合も、両方へ同じ質問をして答えを比べます。

# 社内ドメイン
dig +short dc01.corp.example.com @10.0.1.10
dig +short dc01.corp.example.com @169.254.169.253

# プライベートホストゾーン
dig +short db.aws.example.internal @10.0.1.10
dig +short db.aws.example.internal @169.254.169.253

# インターネットの名前
dig +short www.example.org @10.0.1.10
dig +short www.example.org @169.254.169.253

すべての組で同じ答えが返ることを確認してから、次の手順へ進みます。片方だけ空になる組があれば、転送ルールやフォワーダーを見直します。

手順2：DHCP オプションセットで順番を配る

VPC 内のインスタンスは、DHCP オプションセットで指定された DNS サーバーを使います。DHCP オプションセットは作成後に変更できないので、新しく作って VPC に関連付け直します。

# AD の DNS をプライマリ、Resolver をセカンダリにする例
aws ec2 create-dhcp-options \
  --dhcp-configurations \
    "Key=domain-name-servers,Values=10.0.1.10,10.0.0.2" \
    "Key=domain-name,Values=corp.example.com"

aws ec2 associate-dhcp-options \
  --dhcp-options-id dopt-0123456789abcdef0 \
  --vpc-id vpc-0123456789abcdef0

DNS サーバーは最大4つまで指定できます。値に AmazonProvidedDNS を使う構成と、上の例のように IP アドレスで指定する構成がありますが、組み合わせ方の可否はドキュメントで確認してください。

関連付けを変えても、既存のインスタンスにはすぐには反映されません。DHCP のリース更新や再起動のタイミングで新しい設定を受け取ります。元のオプションセットは切り戻し用に残しておき、まず検証用の VPC やインスタンスで動きを確かめます。

手順3：OS 側の受け取り方とタイムアウトを確認する

DHCP で配った順番が OS でどう使われているかを確認します。

# glibc が直接 resolv.conf を読む構成
cat /etc/resolv.conf

# systemd-resolved を使う構成（Amazon Linux 2023 など）
resolvectl status

glibc を使う構成では、既定のタイムアウトが長めのため、プライマリが落ちるとセカンダリへ移るまでの数秒間、アプリケーションが待たされます。options timeout:2 attempts:2 のように短くすると切り替わりは早くなりますが、一時的に遅いだけのサーバーも見限りやすくなります。resolv.conf は DHCP クライアントや systemd-resolved に上書きされることがあるため、ディストリビューションの設定方法に従って変更してください。

Windows では次のコマンドで確認し、必要に応じてリースを更新します。

Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /renew

手順4：DNS Firewall を使っている場合の動作を決める

Route 53 Resolver DNS Firewall を使っている場合は、Firewall が判定できない状態になったときに問い合わせを通すか止めるか（fail open／fail closed）を、VPC ごとに設定できます。Resolver をセカンダリとして使う目的が可用性なら、通す設定にするかを検討します。ただし、セキュリティ上の要件で止めるべき環境もあるため、方針を決めてから設定してください。

aws route53resolver update-firewall-config \
  --resource-id vpc-0123456789abcdef0 \
  --firewall-fail-open ENABLED

手順5：切り替わりを確かめる

設定しただけでは、プライマリが落ちたときの動きは分かりません。検証用のインスタンスで、プライマリへの通信だけを遮断して確かめます。セキュリティグループやネットワーク ACL で、検証用インスタンスから 10.0.1.10 への UDP/TCP 53 番を一時的に拒否するのが影響の小さい方法です。

# 遮断前後で、名前解決にかかる時間を比べる
time getent hosts dc01.corp.example.com
time getent hosts www.example.org

getent は OS の名前解決の仕組みを通るので、dig よりもアプリケーションに近い動きを確かめられます。遮断中も答えが返り、待ち時間が許容範囲に収まっていれば、セカンダリが機能しています。遮断を戻したあとに、プライマリへ戻るかどうかも確認しておきます。

オンプレミスの端末のセカンダリに Resolver を指定しない

オンプレミスの PC やサーバーの代替 DNS に、Resolver のインバウンドエンドポイントの IP を直接書く構成は避けたほうが無難です。インバウンドエンドポイントは AWS 側の名前を答えるための入口で、社内 DNS と同じ見え方になっていないと、手順1で説明した不整合がそのまま起きます。オンプレミスからは、社内 DNS サーバーの条件付きフォワーダーでインバウンドエンドポイントへ転送する構成が基本です。

まとめ

セカンダリ DNS は、プライマリが落ちたときだけ使われるとは限らず、NXDOMAIN ではセカンダリへ問い合わせ直しません。
そのため、プライマリとセカンダリが同じ名前に同じ答えを返すよう、転送ルールやフォワーダーで見え方をそろえることが最初の手順です。
順番は DHCP オプションセットで配ります。作成後は変更できないので、新しく作って関連付け直し、元のセットは切り戻し用に残します。
OS ごとの切り替わり方とタイムアウトを確認し、DNS Firewall を使う場合は fail open の方針を決めます。
検証用のインスタンスでプライマリへの通信を遮断し、名前解決が続くことと待ち時間を確かめます。