ANAMEレコードは各DNSサービスが独自に提供する機能のため、DNSサービスの乗り換え、ゾーンのエクスポートと取り込み、セカンダリDNSの追加、DNSSECの有効化といった作業のときに、気付かないうちに別の形に変わったり、消えたりします。この記事では、こうした移行や構成変更をきっかけに起きるANAMEの誤設定を取り上げ、作業前の棚卸し、場面ごとの確認と直し方、切り戻しの準備までを順に説明します。
日々の運用の中で起きる設定ミス（値にIPアドレスを入れた、古いAが残っている、など）の切り分けではなく、「移行や構成変更の後からおかしくなった」場合を対象にしています。
ANAMEが移行で壊れやすい理由
ANAMEは、ドメインの頂点（example.com）のようにCNAMEを置けない名前で、別のホスト名を向け先として指定し、DNSサービスがその向け先を解決した結果をA・AAAAレコードとして返す仕組みです。IETFで標準化が検討されたことはありますが、RFCにはなっていません。同じ考え方の機能が、サービスによってALIAS、CNAMEフラット化、エイリアスレコードなどの名前で提供されています（2026年10月現在）。
標準のレコード型ではないため、次のような制約があります。
- BIND形式のゾーンファイルには、ANAMEを表す共通の書き方がない
- ゾーン転送（AXFR）で他のサーバーへ渡すとき、ANAMEそのものは渡せない
- 向け先を解決する間隔、返すTTL、AAAAの扱いがサービスごとに違う
そのため、エクスポートしたゾーンでANAMEが「その時点で解決したAレコード」に置き換わっていたり、コメントとして残っているだけだったり、出力から抜け落ちていたりします。どう扱われるかはサービスによって異なるので、エクスポートしたファイルの頂点の部分は目で確かめる必要があります。
作業前の棚卸し
移行の前でも後でも、まず頂点の名前に今どのレコードがあるかを一覧にしておきます。これが修正の基準にも、切り戻しの資料にもなります。
# 現在の権威サーバーを確認
dig +short NS example.com
# 権威サーバーに頂点のレコードを型ごとに問い合わせる
for t in SOA NS A AAAA MX TXT CAA; do
echo "== $t"
dig @ns1.old-provider.example example.com $t +norecurse +noall +answer
done
# ANAMEの向け先が持つアドレス
dig +short site.hosting.example A
dig +short site.hosting.example AAAAあわせて、移行元の管理画面でANAMEの向け先のホスト名とTTLを控えます。DNSの応答からはANAMEの向け先は見えない（結果のAしか返らない）ため、向け先の名前は管理画面かホスティング会社の案内で確かめるしかありません。
場面ごとの誤設定と直し方
1. 移行先でANAMEが固定のAレコードになった
もっとも多いのがこのケースです。エクスポートしたゾーンを移行先に取り込むと、ANAMEがその時点のIPアドレスを持つAレコードとして登録されます。移行直後は正常に表示されるため気付きにくく、数週間後にCDNやホスティング側でIPアドレスが変わった時点でサイトに接続できなくなります。
確認は、移行先の管理画面で頂点のレコードがAになっているか、ANAMEに相当する機能（ALIAS、CNAMEフラット化など）になっているかを見ます。固定のAになっていた場合は、次のどちらかに直します。
- 移行先のDNSサービスにANAMEに相当する機能があれば、それを使って向け先のホスト名を指定し、固定のAとAAAAは削除する
- 機能がなければ、ホスティング会社やCDNが頂点ドメイン用に案内している固定のIPアドレスをAレコードで設定する。案内がなく、IPアドレスが変わりうる向け先の場合は、ANAMEに対応したDNSサービスを使うか、
www付きのURLを正規にして頂点はリダイレクトだけにする構成を検討する
2. 移行先で頂点にCNAMEとして登録された
取り込みの過程でANAMEがCNAMEに変換されることがあります。頂点のCNAMEは、同じ名前にSOA・NS・MX・TXTを置けないという決まりに反するため、登録を拒否されるか、登録できてもメールの受信やドメイン認証が止まる原因になります。上の棚卸しでMXやTXTが返らなくなっていたら、まずこれを疑います。CNAMEを削除し、1の方法で置き換えます。
3. セカンダリDNSを追加したらサーバーごとに答えが違う
プライマリのDNSサービスでANAMEを使い、別のサービスや自前のサーバーをセカンダリにした構成では、ゾーン転送でANAMEがどう渡るかはプライマリ側の実装しだいです。解決済みのAとして渡す実装では、プライマリが向け先を解決し直すたびに転送が必要になり、セカンダリだけ古いアドレスを返すことがあります。何も渡らない実装では、セカンダリは頂点のAを持ちません。
権威サーバーごとに答えを比べて確かめます。
for ns in $(dig +short NS example.com); do
echo "== $ns"
dig @$ns example.com A +norecurse +short
doneサーバーによって答えが違う場合は、プライマリのサービスがセカンダリ構成でANAMEをどう扱うかを資料で確かめます。安定して同じ答えを返せない場合は、頂点を固定のAにする、ANAMEを使わない構成にする、セカンダリを外す、のいずれかを選びます。
4. DNSSECを有効にしたら頂点だけ引けない
ANAMEの答えは、DNSサービスが問い合わせのたびに作り出すため、DNSSECで署名する場合はそのサービスが応答時に署名する方式に対応している必要があります。また、DNSサービスを乗り換えたのに、レジストラに移行元の鍵の情報（DSレコード）が残っていると、検証を行うキャッシュDNSでは名前解決に失敗します（SERVFAIL）。
# 検証を行う公開DNSでの結果（status が SERVFAIL になっていないか）
dig @8.8.8.8 example.com A
# 検証を行わない問い合わせと比べる
dig @8.8.8.8 example.com A +cd+cd を付けたときだけ答えが返るなら、DNSSECの検証で失敗しています。DNSVizのような可視化ツールでも、どこで検証が切れているかを確かめられます。直し方は、移行先のサービスの手順に従って、レジストラのDSレコードを移行先のものに差し替えるか、いったんDNSSECを無効にしてから移行し直すことです。DSの差し替えは反映に時間がかかるため、作業の順番を資料で確かめてから進めます。
5. CAAで頂点の証明書が発行できない
ANAMEの向け先を新しいCDNやホスティングに変えると、頂点ドメインの証明書を向け先側で発行し直すことがあります。このとき、頂点にCAAレコードがあり、向け先が使う認証局が許可されていないと発行に失敗します。棚卸しで確かめたCAAの内容と、向け先が案内する認証局を見比べ、必要なら許可する認証局を追加します。
切り戻しの準備と作業の順番
移行や修正は、次の順で進めると、途中で状態が分からなくなりにくくなります。
- 棚卸しの結果と、移行元のエクスポートを保存しておく
- 頂点のレコードのTTLを短め（300秒程度）にし、元のTTLの時間だけ待つ
- 移行先で頂点の設定を作り、移行先の権威サーバーに直接問い合わせて、棚卸しと同じ型・同じ値が返るかを確かめる
- 新しい向け先のWebサーバーを、DNSを介さずに確かめる
- ネームサーバーを切り替え、すべての権威サーバーの答えをもう一度比べる
4は curl の --resolve で、名前解決の結果を一時的に指定して確かめられます。
curl -sI https://example.com/ --resolve example.com:443:203.0.113.10問題が出たときは、レジストラのネームサーバーを移行元に戻せば元の状態に近づきますが、NSの変更は反映に時間がかかります。移行元の設定は、切り替え後もしばらく消さずに残しておきます。
WordPress側の確認
頂点の向け先を変えた後は、WordPressの「WordPress アドレス（URL）」と「サイトアドレス（URL）」が、www 付きと無しのどちらになっているかと、もう一方からのリダイレクトが効いているかを確かめます。サーバーを移した場合は、移行前にデータベースとファイルのバックアップを取り、移行後に管理画面へログインできること、メールの送信が止まっていないことも確認します。
まとめ
- ANAMEは標準のレコード型ではなく、エクスポート・取り込み・ゾーン転送で別の形に変わったり消えたりする
- 作業前に頂点のレコードを型ごとに棚卸しし、ANAMEの向け先は管理画面で控える
- 移行後に固定のAやCNAMEになっていたら、移行先の同等機能か、案内された固定IPのAに置き換える
- セカンダリ構成では権威サーバーごとに答えを比べ、DNSSECではDSレコードの差し替えとSERVFAILを確かめる
- 移行元の設定は切り替え後もしばらく残し、切り戻せるようにしておく