2026年6月6日

Route 53 でセカンダリDNSを設定する手順｜ゾーン転送が使えない前提での他社DNS併用と、フェイルオーバーとの違い

DNS・名前解決

Route 53 を「セカンダリDNS」として使う、または Route 53 をプライマリにして他社 DNS をセカンダリにする構成は作れます。ただし Route 53 はゾーン転送（AXFR・IXFR）による複製に対応していないため、BIND のように「プライマリを指定すれば自動で同期される」形にはなりません。両方の DNS を権威サーバーとして並べ、同じレコードを API やツールで両方に書き込む「マルチプロバイダー構成」が現実的な方法です。

この記事では、その構成の組み立て方、同期ツールの使い方、レジストラでのネームサーバー登録、同期ずれの確かめ方を順に説明します。あわせて、Route 53 の画面で「セカンダリ」と表示されるフェイルオーバールーティングとの違いも整理します。AWS の仕様は更新が多いため（2026年10月現在）、コマンドは例として扱い、実行前に公式ドキュメントで確認してください。

まず「セカンダリ」の意味を切り分ける

Route 53 で「セカンダリ」を調べる人の目的は、だいたい次の2つに分かれます。

DNS サービスそのものの冗長化: Route 53 が止まっても、別事業者の DNS が同じ答えを返してほしい（またはその逆）。
Web サーバーの冗長化: 本番サーバーが落ちたら、DNS の回答を予備サーバーに切り替えたい。

1が本来の意味のセカンダリDNSで、この記事の中心です。2は Route 53 のフェイルオーバールーティングで実現するもので、レコードの設定画面に「プライマリ」「セカンダリ」という選択肢が出てくるため混同されがちです。2については後半で簡単に触れます。

Route 53 がゾーン転送に対応しないことの意味

従来のセカンダリDNSは、プライマリサーバーのゾーンをゾーン転送で丸ごと複製し、SOA のシリアル番号が上がるたびに追従する仕組みです。Route 53 はこの方式でゾーンを受け取ることも、他社へ送り出すこともできません（2026年10月現在、公式ドキュメント上の扱い）。

そのため、次の2点を前提に設計します。

両方が「プライマリ」として独立して動く: Route 53 のホストゾーンと他社 DNS のゾーンは、それぞれ別々に管理されます。片方を変更しても、もう片方には反映されません。
同期は自分で用意する: 変更を両方に適用する仕組み（同期ツール、Terraform、自作スクリプト）が必要です。手作業で両方を編集する運用は、いずれ片方の更新漏れが起きます。

他社側がゾーン転送でのセカンダリ受け入れに対応していても、送り出し元が Route 53 では使えません。逆に、自社の BIND などをプライマリにして Route 53 へゾーン転送することもできません。この点を確認せずに「Route 53 のセカンダリ設定画面」を探して時間を使う人が多いので、最初に押さえておいてください。

構成の全体像

マルチプロバイダー構成は、次の3つで成り立ちます。

Route 53 にホストゾーンを作り、他社 DNS にも同じドメインのゾーンを作る。
レコードの正本を1か所（設定ファイルなど）に置き、同期ツールで両方へ反映する。
レジストラ（ドメインの登録事業者）に、両方のネームサーバーを並べて登録する。

リゾルバ（利用者側のキャッシュ DNS）は登録されたネームサーバーの中から応答の良いものを選んで問い合わせるので、片方の事業者が応答しなくなっても、もう片方から答えを得られます。

使えないレコード・機能を先に洗い出す

両方の DNS が同じ答えを返すことが前提なので、どちらか一方にしかない機能は使えないか、使い方を工夫する必要があります。

Route 53 のエイリアスレコード: CloudFront や ALB を指すエイリアスは Route 53 独自の機能です。他社側では同じ形で表現できないため、サブドメインなら CNAME に置き換える、ゾーン頂点なら他社側の CNAME フラットニングや ALIAS 相当の機能で代用するなど、個別の検討が要ります。
加重・レイテンシー・フェイルオーバーなどのルーティングポリシー: これも事業者ごとの機能で、両方で同じ挙動にそろえるのは困難です。マルチプロバイダー構成では、基本的に単純なレコードだけにするのが安全です。
DNSSEC: 2事業者で署名する場合は鍵の扱いが複雑になります（マルチサイナー構成）。両事業者が対応していることを確認できない場合、最初は DNSSEC を有効にしない構成で始め、別途検討してください。

既存のホストゾーンにエイリアスやルーティングポリシーが多いと、移行の負担が大きくなります。まず現状を書き出して確認します。

# 既存ホストゾーンのレコードを書き出す（Z0123456789EXAMPLE は自分のゾーンIDに置き換え）
aws route53 list-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --output json > route53-records-backup.json

# エイリアスやルーティングポリシー付きのレコードを確認する
aws route53 list-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --query "ResourceRecordSets[?AliasTarget || SetIdentifier].[Name,Type]" \
  --output table

書き出した JSON はバックアップとしても保管しておきます。以降の作業で誤ってレコードを消したときの戻し先になります。

手順1: 同期ツールでレコードを両方に反映する

複数の DNS 事業者へ同じ内容を書き込むツールとしては、DNSControl や OctoDNS がよく使われています。どちらもオープンソースで、Route 53 を含む多くの事業者に対応しています（対応事業者とレコード種別は各プロジェクトのドキュメントで確認してください）。Terraform で両事業者のプロバイダーを並べて管理する方法もあります。

DNSControl の場合は、レコードを JavaScript 形式の設定ファイルに書き、preview で差分を確認してから push で反映します。

// dnsconfig.js の例（DNSControl）
var REG_NONE = NewRegistrar("none");
var DNS_R53 = NewDnsProvider("r53");      // creds.json で Route 53 の認証情報を定義
var DNS_OTHER = NewDnsProvider("other");  // 併用する他社DNSの認証情報

D("example.com", REG_NONE,
  DnsProvider(DNS_R53),
  DnsProvider(DNS_OTHER),
  DefaultTTL(300),
  A("@", "203.0.113.10"),
  CNAME("www", "example.com."),
  MX("@", 10, "mail.example.com."),
  TXT("@", "v=spf1 include:_spf.example.net ~all")
);

# 変更内容の確認（ここでは何も書き込まれない）
dnscontrol preview

# 確認した差分を両方の事業者へ反映
dnscontrol push

認証情報は creds.json などの別ファイルに置き、Git には含めないでください。Route 53 側の IAM ユーザー（またはロール）には、対象ホストゾーンのレコード参照と変更だけを許可し、ほかのゾーンやドメイン登録の操作は許可しない権限にしておくと、ツールの設定ミスの影響を抑えられます。

初回の preview では、ツールが「正本にないレコードを削除する」差分を出すことがあります。既存のゾーンに設定ファイルへ書いていないレコードがある場合、そのまま push すると消えてしまいます。初回は差分を1行ずつ読み、削除が含まれていないことを確認してから反映してください。

手順2: ネームサーバーを並べて登録する

両方のゾーンが同じ内容になったら、レジストラ側でネームサーバーを登録します。Route 53 のホストゾーンには4つのネームサーバーが割り当てられているので、それに他社 DNS のネームサーバーを加えて登録します。

# Route 53 に割り当てられたネームサーバーの確認
aws route53 get-hosted-zone --id Z0123456789EXAMPLE \
  --query "DelegationSet.NameServers"

あわせて、各ゾーンの頂点（ドメイン名そのもの）にある NS レコードも、両事業者のネームサーバーを含む内容にそろえておくと、どちらに問い合わせても同じ NS が返るようになります。Route 53 では頂点の NS レコードの値を編集できますが、自動で割り当てられた4つの値を削除しないように注意してください。SOA レコードは事業者ごとに異なっていて問題ありません。

登録できるネームサーバーの数や入力方法はレジストラによって異なります。また、既存のネームサーバーを一度に入れ替えるのではなく、まず片方を追加して様子を見る、という段階的な進め方ができると安全です。切り替えの前に、現在の NS レコードの TTL（親ゾーン側は事業者が決めているため変えられないことが多い）を確認し、反映に1〜2日かかる前提で計画します。

手順3: 両方の答えが一致しているか確かめる

同期ずれの確認には、各事業者のネームサーバーへ直接問い合わせて結果を比べるのが確かな方法です。キャッシュ DNS を経由すると古い答えが返ることがあるため、@ で権威サーバーを指定します。

#!/bin/bash
# 2事業者のネームサーバーに同じ問い合わせをして結果を比べる
NAME="www.example.com"
TYPE="A"
for NS in ns-123.awsdns-15.com ns1.other-dns.example; do
  echo "== $NS"
  dig +short "@$NS" "$NAME" "$TYPE" | sort
done

主要なレコード（Web の A/AAAA、MX、SPF・DKIM・DMARC の TXT、証明書発行用の CAA）について定期的に比較し、差があれば通知する仕組みにしておくと、同期の失敗に早く気づけます。同期ツールを CI で定期実行し、preview に差分が出たら知らせる、という運用も有効です。

フェイルオーバールーティングの「セカンダリ」とは別物

Route 53 のレコード作成画面で、ルーティングポリシーに「フェイルオーバー」を選ぶと、レコードの種類として「プライマリ」「セカンダリ」を選べます。これはヘルスチェックの結果に応じて、正常時はプライマリの値、異常時はセカンダリの値を返す仕組みで、Web サーバーの切り替えに使います。DNS サービス自体の冗長化ではありません。

使う際のポイントは次のとおりです。

プライマリのレコードには、ヘルスチェックを関連付けます。ヘルスチェックは AWS の複数拠点からインターネット経由で対象を確認します。
切り替わりの速さは、ヘルスチェックの間隔・失敗判定の回数と、レコードの TTL で決まります。TTL を長くすると、利用者側のキャッシュが残って切り替えが遅れます。
前述のとおり、この機能は他社 DNS では再現できないため、マルチプロバイダー構成とは基本的に両立しません。DNS の冗長化と Web の冗長化のどちらを優先するかを決めてから設計してください。

WordPress サイトを障害時にメンテナンス画面へ切り替える具体的な手順は、下のリンク先の記事で扱っています。

つまずきやすい点

片方だけ手作業で変更してしまう: 管理画面で直接直すと、次の同期で上書きされるか、差分のまま残ります。変更は正本の設定ファイルからだけ行う、とチームで決めておきます。
メール認証のレコードがずれる: DKIM の TXT は長く、事業者によって分割の扱いが違うことがあります。反映後に両事業者へ問い合わせ、値が一致しているか確認してください。
証明書の自動発行: Let's Encrypt などの DNS-01 認証で TXT レコードを自動追加している場合、片方の事業者にしか書き込まれないと認証が失敗することがあります。発行ツールが両方に書き込めるか、対象サブドメインだけ委任を分けるなどの対応を検討します。

まとめ

Route 53 はゾーン転送に対応していないため、セカンダリDNSは「両方を権威サーバーとして並べ、同じレコードを書き込む」マルチプロバイダー構成で作ります。
エイリアスレコードやルーティングポリシーなど、片方にしかない機能は使えないか置き換えが必要です。最初に既存レコードを書き出して確認します。
同期は DNSControl・OctoDNS・Terraform などで正本から行い、初回は削除の差分に注意します。
レジストラに両方のネームサーバーを登録し、各権威サーバーへ直接問い合わせて答えの一致を定期的に確かめます。
レコード画面の「プライマリ／セカンダリ」はフェイルオーバールーティングで、Web サーバーの切り替え用です。DNS サービスの冗長化とは別の仕組みです。