2026年7月16日

AWS Route 53でDNSを設定する方法｜ホストゾーン作成・ネームサーバー切り替え・WordPress向けレコード

VPS・クラウド

Route 53でWordPressサイトのDNSを管理するには、ホストゾーンを作ってレコードを登録し、ドメインのレジストラ側でネームサーバーをRoute 53のものに切り替えます。いちばん大事なのは、ネームサーバーを切り替える前に、今のDNSにあるレコード（特にメール関連）をすべてRoute 53に写しておくことです。この記事では、ホストゾーンの作成から、WordPressでよく使うレコードの登録、ネームサーバーの切り替え、反映の確認、つまずきやすい点までを順番に説明します。

作業の全体像

Route 53へのDNS移行は、次の順に進めます。

今のDNSのレコードを洗い出し、TTLを短くしておく
Route 53にパブリックホストゾーンを作る
レコードを登録し、Route 53のネームサーバーに直接問い合わせて確認する
レジストラでネームサーバーをRoute 53のものに切り替える
反映を確認し、しばらく旧DNSも残しておく

ドメインをRoute 53で登録している場合は、登録時にホストゾーンが自動で作られ、ネームサーバーも設定済みのことがあります。その場合は手順3から読んでください。

ステップ1：今のレコードを洗い出してTTLを短くする

今のDNS（レジストラやレンタルサーバーのDNS）の管理画面で、登録されているレコードをすべて書き出します。見落としやすいのは次のものです。

MXレコード：メールの受信先。写し忘れるとメールが届かなくなります
TXTレコード：SPF、DMARC、Google Search Consoleなどの所有権確認
DKIM用のCNAMEやTXTレコード：メール送信サービスの署名用
サブドメインのレコード：www、ステージング用、メール配信用など

管理画面に表示されないレコードがある場合もあるので、dig で実際の応答も確認しておきます。

dig +short example.com A
dig +short www.example.com
dig +short example.com MX
dig +short example.com TXT

あわせて、切り替えで値を変える予定のレコード（AやCNAME）のTTLを、作業の1〜2日前に300秒程度まで下げておきます。TTLは「この応答を何秒間キャッシュしてよいか」を表す値で、元の値が長いと、切り替え後もしばらく古い応答が使われ続けます。

ステップ2：ホストゾーンを作る

Route 53のコンソールでホストゾーンの作成を選び、ドメイン名（例: example.com）を入力し、種類は「パブリックホストゾーン」を選びます。VPCの中だけで使う名前解決用の「プライベートホストゾーン」とは別物なので注意します。

CLIでは次のように作ります。--caller-reference は同じリクエストの重複を防ぐための一意な文字列で、毎回違う値にします。

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "example-com-$(date +%s)"

作成すると、NSレコード（ネームサーバー4つ）とSOAレコードが自動で登録されます。NSレコードの4つの値は、あとでレジストラに設定するので控えておきます。この2つのレコードは削除や書き換えをしないでください。

同じドメイン名でホストゾーンを2回作ると、ネームサーバーの組み合わせが違う別のゾーンができます。レジストラに設定したのと違うゾーンを編集していて「変更が反映されない」という事故がよくあるので、不要なゾーンは整理しておきます。

ステップ3：WordPress向けのレコードを登録する

Aレコード（EC2やVPSに直接向ける場合）

WordPressをEC2やVPSで動かしている場合は、サーバーの固定IPアドレス（EC2ならElastic IP）をAレコードに登録します。EC2のパブリックIPアドレスは、Elastic IPを付けていないと停止・起動で変わるため、DNSに登録する前にElastic IPを付けておきます。

エイリアスレコード（CloudFrontやALBに向ける場合）

CloudFrontやロードバランサー（ALB）の前にWordPressを置いている場合は、Route 53独自の「エイリアスレコード」を使います。DNSの仕様上、ドメインの頂点（example.com そのもの）にはCNAMEを置けませんが、エイリアスレコードなら頂点でもCloudFrontやALBのドメイン名を指定できます。レコードの種類はAのままで、エイリアスを有効にして対象のリソースを選びます。

wwwの扱い

www.example.com も使う場合は、頂点と同じ先に向けるAレコード（またはエイリアス）か、頂点を指すCNAMEを登録します。DNSを設定したうえで、WordPressの「サイトアドレス」と同じ方にリダイレクトする設定をWebサーバー側で行うと、URLが1つにまとまります。

CLIでまとめて登録する

レコードの登録や変更は、変更内容をJSONで書いて渡します。UPSERT は「無ければ作成、あれば上書き」です。

{
  "Comment": "WordPress records",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [ { "Value": "203.0.113.10" } ]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [ { "Value": "example.com" } ]
      }
    }
  ]
}

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

# 返ってきた変更IDで状態を確認（INSYNC になれば反映済み）
aws route53 get-change --id /change/C0123456789EXAMPLE

ホストゾーンIDや変更ID、IPアドレスは自分の環境の値に置き換えてください。TXTレコードの値は、JSONの中でダブルクォートをエスケープして "\"v=spf1 include:example.net ~all\"" のように書く必要があり、ここでつまずく人が多いです。コンソールで登録する場合も、TXTの値はダブルクォートで囲みます。

切り替え前にRoute 53へ直接問い合わせる

ネームサーバーを切り替える前に、Route 53のネームサーバーを指定して問い合わせ、登録内容が正しいかを確認します。ネームサーバー名はステップ2で控えた値を使います。

dig @ns-123.awsdns-45.com example.com A +short
dig @ns-123.awsdns-45.com example.com MX +short
dig @ns-123.awsdns-45.com example.com TXT +short

旧DNSの応答と見比べて、すべてのレコードが一致していれば切り替えの準備ができています。

ステップ4：レジストラでネームサーバーを切り替える

ドメインを登録しているレジストラの管理画面で、ネームサーバーの設定を「独自のネームサーバー」などに変え、Route 53の4つの値を入力します。項目名はレジストラごとに違うため、各社のヘルプで確認してください。

現在のDNSでDNSSECを有効にしている場合は、先にレジストラ側のDSレコードを外してから切り替えます。DSレコードが残ったままネームサーバーを変えると、DNSSECを検証するリゾルバーで名前解決に失敗し、サイトが見られなくなることがあります。Route 53でもDNSSEC署名は使えますが、移行が終わって落ち着いてから改めて設定するほうが安全です。

ステップ5：反映を確認する

ネームサーバーの変更は、上位のDNS（.com や .jp など）でキャッシュされているNSレコードのTTLが切れるまで、反映に時間がかかります。数時間から、長いと2日程度を見込んでおきます。

# 委任先がRoute 53に変わったか
dig +short example.com NS

# 上位から順にたどって確認
dig +trace example.com A

切り替え直後は、利用者によって旧DNSと新DNSのどちらかに問い合わせが届く状態が続きます。そのため、旧DNSのレコードはすぐに消さず、少なくとも数日は残しておきます。両方の内容が一致していれば、どちらに届いても同じサーバーに案内されます。反映が落ち着いたら、ステップ1で下げたTTLを元の値に戻します。

よくあるつまずき

メールが届かなくなった：MXレコードやSPF・DKIMのTXTレコードの写し忘れが最も多い原因です。dig MX と dig TXT で確認します
変更が反映されない：レジストラに設定したネームサーバーと、編集しているホストゾーンのNSレコードが一致しているかを確認します
サイトは表示されるがSSL証明書のエラーが出る：DNSの切り替えで接続先のサーバーが変わった場合、新しいサーバーで証明書を発行し直す必要があります。Let's Encryptで発行する場合は、DNSが新しいサーバーを指してから行います
WordPressのURLを変えていないのに表示が崩れる：多くはキャッシュや証明書の問題です。DNSの切り替えだけならWordPressの設定を変える必要はありません

Route 53には、ヘルスチェックと組み合わせて障害時に別のサーバーへ切り替える「フェイルオーバー」などのルーティングポリシーもあります。まずは単純なルーティングで移行を終え、必要になってから検討すれば十分です。料金や機能の詳細は変わることがあるため、AWSの公式ページで確認してください（2026年10月現在）。

まとめ

切り替え前に、今のDNSのレコード（MX・TXT・DKIM・サブドメイン）をすべて洗い出し、TTLを下げておく
パブリックホストゾーンを作り、自動で入るNSとSOAは触らない。重複したゾーンに注意する
EC2はElastic IPをAレコードに、CloudFrontやALBはエイリアスレコードで頂点にも向けられる
切り替え前に dig @Route53のネームサーバー で登録内容を確かめ、DNSSECのDSレコードは先に外す
反映には時間がかかるので、旧DNSは数日残し、落ち着いたらTTLを戻す