ジオDNS の設定方法｜Route 53 の位置情報ルーティングで地域ごとに応答を分ける手順と注意点

ジオDNS は、問い合わせてきた側の地域に応じて、同じホスト名に別の IP アドレスを返す仕組みです。マネージド DNS を使えば自分で DNS サーバーを組まなくても設定でき、この記事では Amazon Route 53 の位置情報ルーティング（Geolocation）を例に、地域の割り当ての決め方、レコードの作成、既定のレコードとヘルスチェック、地域ごとの応答の確かめ方までを説明します。WordPress を複数の拠点で動かす場合に先に決めておくことも合わせて整理します。

ジオDNS で何ができて、何ができないか

権威 DNS サーバーは、問い合わせの送信元 IP アドレス（多くの場合は利用者が使っているリゾルバーのアドレス）を位置情報データベースで国や大陸に当てはめ、その地域用のレコードを返します。リゾルバーが EDNS Client Subnet（ECS）で利用者側のネットワークの一部を伝えてくる場合は、その情報で判定されます。

できることは、次のような振り分けです。

• 日本からのアクセスは東京の拠点、欧州からはフランクフルトの拠点へ向ける
• 特定の国向けに、別のサーバーや別の CDN の入口を返す

一方で、次の用途には向きません。

• アクセス制限：DNS で別の IP を返しても、IP アドレスを直接指定したり別のリゾルバーを使ったりすれば回避できます。国単位で制限したい場合は、WAF やサーバー側の設定で行います。
• 正確な位置の判定：位置はリゾルバーの場所で決まることが多く、利用者が海外の公開リゾルバーや VPN を使っていると、別の地域と判定されます。

Route 53 には似た方式として、遅延の小さいリージョンを選ぶ「レイテンシー」や、地理的な距離と偏りの設定で選ぶ「地理的近接性（Geoproximity）」もあります。「最も速い拠点へ」が目的ならレイテンシーのほうが合うことが多く、「この国はこの拠点」と決めたい場合に位置情報ルーティングを使う、という使い分けが基本です。

WordPress を複数の拠点で動かす前に決めること

ジオDNS の設定自体は数分で終わりますが、WordPress の場合は振り分け先の準備のほうが大きな作業になります。

• データベースの扱い：投稿やコメント、ログイン情報の書き込みをどの拠点で受けるかを決めます。拠点ごとに別のデータベースを持つと内容が食い違います。書き込みは一か所に集め、他の拠点は複製を読む構成が一般的ですが、複製の遅れで「保存したのに表示されない」ことが起こります。
• アップロードファイル：wp-content/uploads を拠点間で同期するか、オブジェクトストレージに置いて共有します。
• 証明書：どの拠点も同じホスト名で応答するため、それぞれに同じ名前の証明書が必要です。
• URL：サイトアドレス（home と siteurl）はすべての拠点で同じにします。拠点ごとに変えると、リダイレクトの繰り返しやログインの失敗の原因になります。

表示速度の改善が主な目的なら、拠点を増やす前に CDN でキャッシュを各地に置く方法も検討してください。多くの WordPress サイトでは、オリジンは一か所のまま CDN を使うほうが構成も運用も単純です。

手順1: 割り当て表を作り、TTL を下げておく

設定に入る前に、地域と返すレコードの対応表を作ります。

いま同じ名前に通常のレコードがある場合は、作業の前日までに TTL を 60〜300 秒程度に下げておきます。切り替えた直後に問題が見つかっても、古いキャッシュが早く消えるので戻しやすくなります。また、ホストゾーンのレコードを書き出して保存しておいてください。

aws route53 list-resource-record-sets --hosted-zone-id Z0123456789EXAMPLE > zone-backup.json

手順2: 位置情報ルーティングのレコードを作る

コンソールでは、レコード作成の画面でルーティングポリシーに「位置情報」を選び、場所と「レコード ID」を指定します（画面の表記は変わることがあります）。レコード ID は同じ名前の行を区別するための名前で、jp-tokyo のように分かりやすく付けます。

同じ内容を AWS CLI で作る場合の例です。

{
  "Comment": "www をジオDNSで振り分ける（例）",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "jp-tokyo",
        "GeoLocation": { "CountryCode": "JP" },
        "TTL": 60,
        "ResourceRecords": [ { "Value": "192.0.2.10" } ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "europe-frankfurt",
        "GeoLocation": { "ContinentCode": "EU" },
        "TTL": 60,
        "ResourceRecords": [ { "Value": "198.51.100.20" } ]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "default",
        "GeoLocation": { "CountryCode": "*" },
        "TTL": 60,
        "ResourceRecords": [ { "Value": "192.0.2.10" } ]
      }
    }
  ]
}

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch file://geo.json

同じ名前・同じタイプに、通常の（ルーティングポリシーなしの）レコードが残っていると作成できません。既存のレコードを削除してから作ることになり、削除と作成を別々に行うと、その間は応答が無くなります。DELETE と CREATE を同じ変更バッチに入れて一度に反映させ、念のためアクセスの少ない時間に作業してください。

手順3: 既定のレコードを忘れない

位置情報ルーティングで最もつまずきやすいのが、既定のレコード（CountryCode に * を指定した行）を作り忘れることです。どの地域にも当てはまらない問い合わせや、位置を判定できない IP アドレスからの問い合わせに対して、Route 53 は応答を返さなくなります。利用者からは「一部の人だけサイトが開けない」という分かりにくい症状になります。

国と大陸の両方に行がある場合は、より狭い国の行が優先されます。割り当て表で「大陸で大まかに分け、特定の国だけ例外にする」形にしておくと、行の数を抑えられます。

手順4: ヘルスチェックを付ける

各行にはヘルスチェックを関連付けられます。拠点が応答しなくなったとき、その行を返さないようにするためです。ヘルスチェックが失敗した行の代わりに、より広い地域の行や既定の行が使われる動作が AWS の説明に記載されています。動作の詳細は版や設定で変わる可能性があるため、本番の前に一つの拠点を止めて実際の切り替わりを確認してください。

ヘルスチェックの対象は、トップページよりも、データベースへの接続まで確かめる軽い専用の URL にすると、表面だけ動いている状態を見逃しにくくなります。ヘルスチェックの送信元からのアクセスを、WAF やセキュリティ系プラグインが遮断していないかも確認が必要です。

手順5: 地域ごとの応答を確かめる

手元から普通に問い合わせると、自分の地域の結果しか見えません。Route 53 には、送信元を指定して応答を試すコマンドがあります。

# 欧州のアドレスから問い合わせた場合の応答を試す（アドレスは例）
aws route53 test-dns-answer \
  --hosted-zone-id Z0123456789EXAMPLE \
  --record-name www.example.com \
  --record-type A \
  --resolver-ip 203.0.113.1

Route 53 の権威サーバーは ECS に対応しているため、dig の +subnet で利用者側のネットワークを指定して直接確かめる方法もあります。ネームサーバー名はホストゾーンに表示されているものに置き換えてください。

dig @ns-123.awsdns-45.com www.example.com A +subnet=203.0.113.0/24

あわせて、Google Public DNS と Cloudflare の 1.1.1.1 のように ECS の扱いが異なる公開リゾルバーでは、同じ利用者でも違う拠点に振り分けられることがあります。1.1.1.1 はプライバシーの方針として ECS を送らないと案内しているため、リゾルバーの場所で判定されます（2026年10月現在）。

検索エンジンとの関係

ジオDNS で拠点を分けても、すべての拠点が同じ内容を返すなら検索への影響はほとんどありません。注意が必要なのは、拠点ごとに言語や内容を変える場合です。Google のクローラーは主に米国のアドレスから巡回するとされており、IP アドレスで内容を変えると、他の地域向けの内容が見つけてもらえない可能性があります。言語や地域で内容を変えるなら、Google 検索セントラルの案内に沿って URL を分け、hreflang で対応関係を示す方法が推奨されています。

まとめ

• ジオDNS はリゾルバー（または ECS の情報）の地域で応答を変える仕組みで、アクセス制限の手段にはなりません。
• WordPress を複数の拠点で動かすなら、データベースの書き込み先、アップロードファイル、証明書、サイトアドレスを先に決めます。速度目的なら CDN も比較します。
• Route 53 では国・大陸ごとの行に加え、既定の行（*）を作ります。忘れると一部の利用者に応答が返りません。
• ヘルスチェックを付け、test-dns-answer や dig +subnet で地域ごとの応答と障害時の切り替わりを確かめてから本番にします。

• AWS Route 53でDNSを設定する方法
• DNSのTTLの意味と適切な設定方法