ANAMEレコードの誤設定の修正手順｜症状から原因を絞り込む確認コマンドと直し方

ANAMEレコードの誤設定は、権威サーバーがドメインの頂点（example.com）に返しているA・AAAAレコードと、向け先のホスト名が実際に持つA・AAAAレコードを dig で並べて比べると、たいてい原因が見えてきます。よくあるのは、値にIPアドレスを入れている、古いAやAAAAが残っている、向け先のホスト名を書き間違えている、の3つです。この記事では、ANAMEの動きを押さえたうえで、症状の読み方と、よくある順の原因・確認方法・直し方を説明します。

ANAMEの動きを先に押さえる

ANAMEは、ドメインの頂点のようにCNAMEを置けない名前で、CNAMEのように別のホスト名を指すための仕組みです。DNSサービスが向け先のホスト名を自分で名前解決し、その結果のIPアドレスを、頂点のA・AAAAレコードとして返します。利用者のキャッシュDNSにはCNAMEは見えず、ふつうのAレコードが届きます。

押さえておきたい点は次の3つです。

• 標準のレコード型ではない: ANAMEはDNSサービスが独自に提供する機能です。IETFで標準化が検討されたことはありますが、RFCにはなっていません。同じ考え方の機能が、サービスによってALIAS、CNAMEフラット化（Cloudflare）、エイリアスレコード（Amazon Route 53）など別の名前で提供されています
• サービスごとに動きが違う: 向け先を解決し直す間隔、返すTTL、AAAAの扱い、同じ名前の別レコードとの共存の可否は、サービスによって異なります
• Route 53 のエイリアスは向け先が限られる: Route 53 のエイリアスは、CloudFront やロードバランサーなどAWSのリソースや、同じホストゾーン内のレコードを向け先にする機能で、外部の任意のホスト名には向けられません

設定画面の項目名や、対応するレコード型の名前は変わることがあるため、使っているサービスの資料を手元に置いて作業します（2026年10月現在）。

症状を読む

最初に、権威サーバーが返している内容と、向け先が持つ内容を比べます。権威サーバーの名前は dig +short NS example.com で調べます。

# 権威サーバーが頂点に返している内容
dig @ns1.dns-provider.example example.com A +norecurse
dig @ns1.dns-provider.example example.com AAAA +norecurse

# 向け先のホスト名が実際に持つ内容
dig +short site.hosting.example A
dig +short site.hosting.example AAAA

比べた結果から、次のように見当を付けます。

• 頂点のAが空、またはエラー: ANAMEが作られていない、値の書き間違い、向け先が解決できない
• 頂点のAが向け先と違うIPを返す: 古いAレコードが残っている、別のサービスにNSが向いている
• Aは正しいがAAAAが違う: 古いAAAAが残っている、向け先のIPv6対応が変わった
• 権威サーバーでは正しいのに利用者の環境で違う: キャッシュが残っている

原因と直し方（よくある順）

1. 値にIPアドレスを入れている

ANAMEの値はホスト名です。ホスティング会社から「このIPアドレスを指定してください」と案内された場合は、ANAMEではなくAレコード（IPv6ならAAAA）を使います。逆に「このホスト名にCNAMEを向けてください」と案内されたときに、頂点の代わりとしてANAMEを使います。サービスによってはIPアドレスを入れると保存時にエラーになりますが、保存できてしまうものもあるので、値の欄を見直します。

2. 古いA・AAAAレコードが残っている

サーバー移転やCDNの導入でANAMEに切り替えたとき、以前のAやAAAAを消し忘れることがあります。同じ名前にANAMEとAが並ぶと、登録を拒否するサービス、Aを優先するサービス、両方を混ぜて返すサービスがあり、結果がそろいません。

特に見落としやすいのがAAAAです。IPv4のAだけを消して以前のAAAAが残っていると、IPv6で接続できる利用者だけが旧サーバーに案内されます。「一部の利用者だけ古いサイトが表示される」という症状になったら、まずAAAAを確かめます。削除する前に、管理画面のエクスポートなどで内容を控えておきます。

3. 向け先のホスト名を書き間違えている

綴りの誤りのほか、管理画面がゾーン名を自動で付け足す方式で末尾のドットを付けずに入力し、site.hosting.example.example.com のような名前になっている場合があります。向け先を dig で引いて何も返らなければ、名前が違うか、ホスティング側でまだ独自ドメインの受け付けが完了していません。ホスティングの管理画面で案内されているホスト名と、1文字ずつ照らし合わせます。

4. ANAMEに対応しないDNSで頂点にCNAMEを置いた

使っているDNSサービスがANAMEに対応していないとき、代わりに頂点へCNAMEを置こうとするケースがあります。CNAMEは同じ名前に他のレコードを置けないという決まりがあり、頂点に必須のSOA・NSや、メールに使うMX・TXTと共存できません。登録できたとしても、メールの受信やドメイン認証が壊れる原因になります。

直し方は、ANAMEに対応したDNSサービスに移す、ホスティング会社が案内するIPアドレスをAレコードで設定する、www 付きを正規のURLにして頂点はリダイレクトだけにする、のいずれかです。

5. 向け先が地域ごとにIPを変えるCDNになっている

CDNのホスト名は、問い合わせてきた場所に応じて近い拠点のIPアドレスを返すことがあります。ANAMEでは、向け先を解決するのはDNSサービス側なので、利用者から見て近い拠点が返るとは限りません。サービスによっては、利用者の位置を考慮して解決する仕組みを持つものもあります。表示が遅い地域がある場合は、CDNの資料で頂点ドメインの推奨設定を確認します。

6. TTLとキャッシュ

ANAMEで返るAレコードのTTLは、ANAMEに設定したTTLと向け先のTTLのどちらを使うか、サービスによって決め方が異なります。修正後もしばらく古い結果が見えるときは、権威サーバーの答えが正しいことを確認したうえで、TTLの間待ちます。

修正作業の進め方

修正は次の順で行うと、途中で状態が分からなくなりにくくなります。

1. 現在のレコードをエクスポートや画面の控えで保存する
2. 頂点のA・AAAA・ANAMEのTTLを短め（300秒程度）にして、元のTTLの時間だけ待つ
3. 不要なA・AAAAを削除し、ANAMEの値を正しいホスト名にする
4. 権威サーバーに +norecurse で問い合わせ、向け先と同じIPが返るかを確かめる
5. 新しいIPに対して、DNSを介さずにWebサーバーの応答を確認する

5は curl の --resolve を使うと、DNSの反映を待たずに確認できます。

curl -sI https://example.com/ --resolve example.com:443:203.0.113.10

HTTPの応答コードと、証明書のエラーが出ないことを見ます。証明書エラーになる場合は、ホスティングやCDN側で頂点ドメインの証明書が発行されているかを確認します。

WordPress側で合わせて確認すること

頂点ドメインの向け先を変えたら、WordPressの「WordPress アドレス（URL）」と「サイトアドレス（URL）」が www 付きと無しのどちらになっているかと、もう一方からのリダイレクトが効いているかを確かめます。頂点を新しいサーバーに向けた直後は、証明書の自動発行がDNSの反映を待って失敗することもあるため、反映後に発行状況を確認します。

まとめ

• ANAMEはDNSサービス独自の機能で、名前も動きもサービスごとに違う
• 権威サーバーが頂点に返すA・AAAAと、向け先が持つA・AAAAを並べて比べる
• 値にIPアドレスを入れていないか、古いA・AAAAが残っていないか、向け先の綴りが正しいかを順に確かめる
• 頂点へのCNAMEはMXやTXTを壊すので、ANAME対応のDNSかAレコードに置き換える
• 修正後は curl --resolve で新しい向け先の応答と証明書を確かめる

• CDN導入時のDNS設定：ルートドメインのCNAME問題とCNAMEフラット化・ALIASの使い方
• CNAMEとAレコードを混在させてはいけない理由