Anycast DNS は「ネームサーバーが止まらない」ための仕組みで、DNSフェイルオーバーは「止まったWebサーバーを応答から外す」ための仕組みです。守っている層が違うため、組み合わせるとネームサーバーの障害とWebサーバーの障害の両方に備えられます。この記事では、それぞれが防げる障害と防げない障害を整理したうえで、規模別の構成例3つと、組み合わせたときに起きやすい落とし穴、確認方法を説明します。
2つの仕組みが守っているもの
Anycast DNS は、同じIPアドレスを世界の複数の拠点からBGPで広告し、利用者のリゾルバーからネットワーク的に近い拠点が応答する方式です。ある拠点が止まるとその拠点の経路が取り下げられ、問い合わせは自動的に別の拠点へ流れます。DNSの問い合わせは多くがUDPの1往復で終わるため、途中で経路が変わっても影響が小さく、Anycastと相性の良い用途です。
一方で、Anycastが守るのは「ネームサーバーに届くかどうか」だけです。ゾーンに登録した内容が間違っていれば、その間違いは全拠点に同じように配られます。誤ったIPアドレスやDNSSECの署名切れは、Anycastでは防げません。また、Webサーバーが止まっていても、ネームサーバーは登録されたIPを返し続けます。
DNSフェイルオーバー は、権威DNSがWebサーバーをヘルスチェックし、異常なら予備のIPを返すよう応答の中身を変える仕組みです。こちらはネームサーバー自体が落ちると働きません。
つまり、片方だけでは次のような穴が残ります。
- Anycast DNS だけ：Webサーバーが止まると、止まったサーバーのIPを返し続ける
- DNSフェイルオーバーだけ（単一拠点のDNS）：DNSサーバーの障害で名前解決ごと止まる
構成例1：マネージドのAnycast DNSでフェイルオーバー機能を使う
もっとも手軽で、多くのサイトに向いている構成です。Amazon Route 53、Cloudflare、Azure DNS、Google Cloud DNS などの主要なマネージドDNSは、ネームサーバーをAnycastで運用していると公表しています（2026年10月現在）。そのうえで、同じサービスのヘルスチェック付きの応答機能を使えば、2つの層をまとめて1社に任せられます。
利用者のリゾルバー
│（Anycast：最寄りのDNS拠点が応答）
▼
マネージドDNS ──ヘルスチェック──▶ メインのWebサーバー（正常ならこのIP）
└──────────────────────────▶ 予備のWebサーバー（メイン異常時のIP）設定の流れは、ネームサーバーをマネージドDNSに切り替え、ヘルスチェックを作り、対象レコードをフェイルオーバー型（またはそれに相当するルーティング）にする、の3段階です。ヘルスチェックの機能が有料のアドオンになっているサービスもあるので、使えるプランかを先に確認してください。
この構成の弱点は、1社に依存することです。サービス全体の障害や、アカウントの停止・誤操作が起きると両方の層が同時に失われます。Route 53 のように、割り当てるネームサーバーを異なるトップレベルドメインに分けているサービスもあり、単一の事業者の中でもある程度の分散は図られていますが、事業者そのもののリスクは残ります。
構成例2：2社のAnycast DNSを並べ、両方でフェイルオーバーを設定する
事業者のリスクまで減らしたい場合は、2社のマネージドDNSをネームサーバーとして並べます。レジストラに登録するNSレコードに、両社のネームサーバーを混ぜて登録する構成です。
ここで最大の落とし穴になるのが、フェイルオーバーのような「動的なレコード」はゾーン転送で同期できないことです。通常のDNSでは、プライマリからセカンダリへゾーン転送（AXFR/IXFR）で内容を複製します。しかしヘルスチェック連動のレコードは各社独自の機能で、転送されるのは固定の値か、そもそも転送に対応していません。Route 53 はゾーン転送に対応していないため、Route 53 を含む2社構成ではAPIでそろえることになります。
そのため、この構成では次のように運用します。
- 両社それぞれで、同じ監視URL・同じ判定回数のヘルスチェックとフェイルオーバーを設定する
- レコードの定義を Terraform や octoDNS などの設定ファイルで一元管理し、両社に同じ内容を反映する（動的なレコードをどこまで扱えるかはツールと各社のプロバイダー実装によるため、事前に確かめる）
- 両社の監視は別々に動くため、障害の瞬間には一方が予備のIP、もう一方がメインのIPを返す時間があることを前提にする
DNSSECを使っている場合は、2社がそれぞれ署名する構成（マルチサイナー）の調整が要ります。対応状況は事業者によって大きく異なるため、DNSSECとマルチプロバイダーを両立させるかどうかは、各社の対応を確認してから決めてください。
構成例3：自前のAnycastで、経路の取り下げをフェイルオーバーに使う
自社でASNとIPアドレスのプレフィックスを持ち、複数の拠点でDNSサーバーを運用している場合は、Anycastの経路そのものをフェイルオーバーに使えます。各拠点で「自分のDNSサーバーが正常なときだけ経路を広告する」ようにしておけば、拠点が壊れると経路が取り下げられ、問い合わせは残りの拠点へ移ります。
インターネットに広告する場合、一般に受け入れられる最小のプレフィックスはIPv4で/24、IPv6で/48とされることが多く、IRRへの登録やRPKIのROA作成も必要です。準備の詳細はBGPの広告手順の記事に譲り、ここでは監視の考え方だけを示します。
次は、BGPデーモンに ExaBGP を使い、そのプロセスとして起動される監視スクリプトの例です。ExaBGP は、スクリプトが標準出力に書いたコマンドに従って経路を広告・取り下げします。設定ファイルの書式はバージョンで異なるため、使っているバージョンのドキュメントに合わせてください。
#!/usr/bin/env bash
# ExaBGP の process から起動する監視スクリプトの例
# ローカルのDNSサーバーが応答する間だけ、Anycast用のプレフィックスを広告する
PREFIX="192.0.2.0/24"
announced=0
while true; do
# health.example.com は監視用にゾーンへ登録しておくレコード
# タイムアウト時に dig が出すメッセージを正常と誤認しないよう、IPv4の形の行だけを拾う
answer=$(dig +short +time=1 +tries=2 @127.0.0.1 health.example.com A 2>/dev/null \
| grep -E '^[0-9]+(\.[0-9]+){3}$')
if [ -n "$answer" ] && [ "$announced" -eq 0 ]; then
echo "announce route ${PREFIX} next-hop self"
announced=1
elif [ -z "$answer" ] && [ "$announced" -eq 1 ]; then
echo "withdraw route ${PREFIX} next-hop self"
announced=0
fi
sleep 5
doneここで注意したいのは、監視の対象を「その拠点の中だけで完結するもの」にすることです。全拠点が共通のデータベースや外部APIをチェックしていると、そこが落ちた瞬間に全拠点が一斉に経路を取り下げ、ネームサーバーがすべて消えてしまいます。また、応答の中身（Webサーバーのフェイルオーバー）は、この構成ではPowerDNSのLUAレコードなど、DNSサーバー側の機能で別に実現します。
組み合わせた構成の確認方法
設定後は、すべてのネームサーバーが同じ応答を返しているかを確かめます。
# 登録されているネームサーバーごとに、www の応答を並べる
for ns in $(dig +short example.com NS); do
printf '%s -> %s\n' "$ns" "$(dig +short www.example.com A @"$ns" | tr '\n' ' ')"
done構成例2では、ここで両社の応答がそろっていることが平常時の確認点になります。メインのヘルスチェックURLを意図的に503にする試験を行い、各ネームサーバーの応答が予備のIPに変わるまでの時間を、社ごとに記録しておくと、障害時の判断に役立ちます。
どの拠点が応答したかを知りたいときは、dig +nsid @ネームサーバー でNSID（サーバーの識別子）を表示できる場合があります。NSIDを返すかどうかは事業者やサーバーの設定によります。拠点ごとの到達性の確認には、異なる地域から問い合わせられる外部の計測サービスを併用すると全体像がつかめます。
まとめ
- Anycast DNS はネームサーバーへの到達を、DNSフェイルオーバーは応答の中身を守る仕組みで、組み合わせると2つの層の障害に備えられます。
- 多くのサイトは、マネージドのAnycast DNSが持つフェイルオーバー機能を使う構成1で十分です。
- 2社構成では、動的なレコードがゾーン転送で同期できないため、両社に同じ設定をAPIや設定ファイルで反映します。
- 自前のAnycastでは、拠点内で完結する監視で経路を取り下げ、全拠点が同時に消えない設計にします。
- 設定後は全ネームサーバーの応答をそろえて確認し、切り替え時間を実測します。