2026年5月24日

Route 53でホストゾーンを作成する手順｜レコード移行からネームサーバー切り替えまで

DNS・名前解決

Route 53 で独自ドメインの DNS を運用するには、まず「ホストゾーン」を作り、必要なレコードを登録してから、レジストラ側のネームサーバーを Route 53 に向けます。順番を間違えなければサイトやメールを止めずに切り替えられます。この記事では、パブリックホストゾーンの作成、既存レコードの移し替え、切り替え前の検証、ネームサーバー変更までを、つまずきやすい点と確認方法つきで説明します。

ホストゾーンとは何か

ホストゾーンは「あるドメイン（example.com）とそのサブドメインのレコードをまとめて保持する入れ物」です。Route 53 には2種類あります。

パブリックホストゾーン: インターネット全体に向けて名前解決を返します。WordPress サイトを公開するならこちらです。
プライベートホストゾーン: 関連付けた VPC の中からだけ解決できます。社内向けの名前や、EC2 と RDS の間で使う内部名に向きます。

ホストゾーンを作ると、NS レコードと SOA レコードが自動で作られます。NS レコードには、そのゾーンに割り当てられた4台のネームサーバー（ns-xxx.awsdns-xx.com のように .com / .net / .org / .co.uk のドメインが混在したもの）が入っています。この4台がレジストラに登録すべき値です。ゾーンごとに組み合わせが異なるため、他のゾーンの値を流用することはできません。

なお、ホストゾーンにはゾーン単位の月額料金とクエリ量に応じた料金がかかります。料金体系は改定されることがあるため、AWS の料金ページで最新の内容を確認してください。コンソールの画面構成も変わることがあります（2026年10月現在）。

作業前に準備すること

切り替えで一番多い事故は「移し忘れたレコードがあって、メールや認証だけが止まる」ことです。作業前に次の3点を済ませておきます。

現在の DNS のレコードを一覧にする: A / AAAA / CNAME だけでなく、MX、TXT（SPF・DKIM・DMARC、各種サービスの所有権確認）、CAA、SRV まで書き出します。今の DNS サービスにエクスポート機能があれば使い、無ければ管理画面を見ながら転記します。dig で外から見えるのは問い合わせた名前だけなので、ゾーン全体の一覧は管理画面側で取るのが確実性の高い方法です。
今の DNS で TTL を短くしておく: 切り替え直後に問題が見つかったとき戻しやすくするため、主要レコードの TTL を前日までに 300 秒程度へ下げておきます。
DNSSEC の有無を確認する: 現在の DNS で DNSSEC を有効にしている場合、レジストラに DS レコードが登録されています。この状態でネームサーバーだけを Route 53 に変えると、署名の検証に失敗して名前解決ができなくなります。先に DS レコードを外し、その TTL が切れるのを待ってから切り替えます。

コンソールでホストゾーンを作成する

AWS マネジメントコンソールで Route 53 を開き、ホストゾーンの一覧から作成画面に進みます。画面の表記は更新で変わることがありますが、入力する内容は次のとおりです。

ドメイン名: example.com のように、www を付けないルートのドメインを入力します。
説明: 任意です。用途や担当者を書いておくと、複数アカウントで管理するときに役立ちます。
タイプ: 公開サイトならパブリックホストゾーンを選びます。

作成すると、NS と SOA の2レコードだけが入ったゾーンができます。ここで NS レコードの値（4台のネームサーバー名）を控えておきます。

注意したいのは、同じドメイン名のホストゾーンを複数作れてしまうことです。作り直しを繰り返すと、名前は同じでもネームサーバーの組み合わせが違うゾーンがいくつも並びます。レジストラが指しているのはそのうち1つだけなので、別のゾーンにレコードを足しても反映されません。「Route 53 で設定したのに効かない」という相談の多くはこれが原因です。不要なゾーンは中身を確認したうえで削除しておきます。

AWS CLI で作成する場合

手順を記録に残したい場合や、複数ドメインをまとめて扱う場合は CLI が便利です。--caller-reference は重複実行を防ぐための一意な文字列で、毎回違う値を渡します。

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "example-com-$(date +%Y%m%d%H%M%S)" \
  --hosted-zone-config Comment="WordPress production"

# 作成済みゾーンの ID とネームサーバーを確認する
aws route53 list-hosted-zones-by-name --dns-name example.com
aws route53 get-hosted-zone --id Z0123456789EXAMPLE

get-hosted-zone の出力にある DelegationSet の NameServers が、レジストラに登録する4台です。Terraform を使っている場合は aws_route53_zone リソースで同じことができ、name_servers 属性からこの値を参照できます。

レコードを登録する

控えておいた一覧をもとにレコードを作ります。WordPress サイトでよく使う構成の考え方は次のとおりです。

ルートドメイン（example.com）: サーバーの IP アドレスへ A レコードを向けます。ロードバランサー（ALB）や CloudFront の後ろに置く場合、ルートには CNAME を置けないため、Route 53 独自のエイリアスレコードを使います。エイリアスは AWS のリソースを名前で指定でき、IP アドレスが変わっても追従します。
www: ルートへの CNAME、またはルートと同じエイリアスにします。どちらを正規の URL にするかは WordPress の「サイトアドレス」と揃えます。
メール: MX と、SPF・DKIM・DMARC の TXT を移します。DKIM の値は長いため、転記ミスが起きやすい箇所です。

CLI でまとめて登録する場合は、変更内容を JSON に書いて渡します。UPSERT は「無ければ作成、あれば上書き」です。

{
  "Comment": "Initial records for WordPress",
  "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" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "MX",
        "TTL": 3600,
        "ResourceRecords": [{ "Value": "10 mail.example.net." }]
      }
    }
  ]
}

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

TXT レコードの値はダブルクォートで囲んだ文字列として渡す必要があり、JSON の中では "\"v=spf1 include:_spf.example.net ~all\"" のようにエスケープします。ここで引用符が抜けると、登録エラーになったり意図しない値になったりします。

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

ネームサーバーを変える前でも、Route 53 のネームサーバーを指定して問い合わせれば、登録内容が正しいかを確認できます。この確認を挟むだけで、移し忘れの多くは切り替え前に見つかります。

# Route 53 側（ゾーンの NS レコードにある1台を指定）
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 側と比べる
dig example.com MX +short
dig example.com TXT +short

両者の結果が一致していれば準備完了です。差があれば、どちらが正しいかを確認してから Route 53 側を直します。

レジストラのネームサーバーを Route 53 に変更する

ドメインを登録しているレジストラの管理画面で、ネームサーバーを Route 53 の4台に置き換えます。末尾のドットは付けても付けなくても受け付けるレジストラが多いですが、入力欄の説明に従ってください。

4台すべてを登録します。1〜2台だけだと、障害時の冗長性が下がります。
古いネームサーバーと混在させません。混在させると、問い合わせ先によって違う答えが返る状態になります。
Route 53 でドメインを登録している場合は、Route 53 の登録済みドメインの画面でネームサーバーを確認します。ドメイン登録時に自動で作られたホストゾーンを削除して作り直すと、ネームサーバーの組み合わせが変わるため、登録済みドメイン側も更新が必要です。

変更後は、親ゾーン（.com など）の NS 情報が更新されるまで時間がかかります。親ゾーンの NS レコードの TTL は長めに設定されていることが多く、キャッシュが残っている間は古い DNS に問い合わせが届きます。そのため、切り替え後もしばらくは古い DNS のレコードを消さずに残しておきます。

# 委任の状況をルートからたどって確認する
dig example.com NS +trace

+trace の最後のほうで Route 53 のネームサーバーが応答していれば、委任は切り替わっています。

つまずきやすいポイント

レコードを変えたのに反映されない: 同名の別ゾーンを編集していないか、レジストラの NS とゾーンの NS が一致しているかを確認します。
メールだけ届かない: MX と SPF・DKIM の TXT を見直します。旧 DNS 側でメール関連の CNAME（自動設定用など）を使っていた場合も移します。
サブドメインだけ別管理にしたい: blog.example.com のホストゾーンを作り、その NS の値を親ゾーン（example.com）に NS レコードとして登録すれば、サブドメインだけを委任できます。
プライベートホストゾーンが VPC 内で解決されない: VPC の DNS 解決と DNS ホスト名の設定が有効か、ゾーンが正しい VPC に関連付けられているかを確認します。

作業の前後には、旧 DNS のレコード一覧と Route 53 の内容を保存しておくと、問題が起きたときに比較して戻せます。

まとめ

Route 53 のホストゾーンは、作成時に割り当てられた4台のネームサーバーをレジストラに登録して初めて有効になります。
切り替え前に旧 DNS のレコードを全件書き出し、TTL を下げ、DNSSEC の DS レコードを外しておきます。
同名のホストゾーンが複数あると、編集しても反映されない原因になります。
ネームサーバー変更の前に、Route 53 のネームサーバーへ dig で直接問い合わせて内容を検証します。
切り替え後もしばらくは旧 DNS のレコードを残し、dig +trace で委任先を確認します。