ANAMEレコードを設定したのにルートドメインが新しいサーバーへ向かないときは、「どこまで届いていて、どこで止まっているか」を外側から順に確かめると原因の層が分かります。確かめる順番は、ネームサーバーの委任、権威サーバーの応答、向け先ホスト名の解決、キャッシュの4つです。この記事では、ANAMEが一般的なレコードと違う点を押さえたうえで、各段階の検証コマンドと結果の読み方を説明します。
検証の前に知っておきたいANAMEの性質
ANAMEは、ゾーンの頂点（example.com のようなルートドメイン）にCNAMEのような「別名」を置くために、DNSサービスが独自に用意している仕組みです。IETFで規格化が検討されたことはありますが、標準のレコードタイプにはなっていません（2026年10月現在）。サービスによって ANAME、ALIAS、CNAMEフラットニングなど呼び方と動きが違います。
検証で大事な性質は次の3つです。
- 外から見えるのはAレコードとAAAAレコード：DNSサービスが向け先のホスト名を自分で解決し、その結果のIPアドレスをAやAAAAとして返します。そのため、検証では
ANAMEではなくAとAAAAを問い合わせます。 - 権威サーバーの中で一度キャッシュされる：DNSサービスは向け先の解決結果を一定時間保持してから返すことがあります。保持時間の決まり方はサービスによって違います。
- そのDNSサービスでしか動かない：ゾーン転送でセカンダリDNSへ渡したり、別のDNSサービスへ移したりすると、ANAMEの意味が伝わらないことがあります。
この性質を踏まえ、以下の手順で例として example.com に ANAME を置き、向け先を site.example-cdn.net とします。
手順1：ネームサーバーの委任を確かめる
ANAMEを設定したDNSサービスが、実際にそのドメインの権威サーバーになっているかを最初に確かめます。ここがずれていると、ほかのどの確認も意味がありません。
# レジストリ側（親ゾーン）から見たネームサーバー
dig example.com NS +trace | tail -n 20
# 公開DNSから見たネームサーバー
dig example.com NS +short表示されたネームサーバーが、ANAMEを設定したサービスのものと一致しているかを見ます。以前使っていたDNSサービスや、ドメインを取得したレジストラの初期ネームサーバーが残っていれば、編集している場所が間違っています。ネームサーバーを切り替えた直後なら、親ゾーンのNSのTTLが切れるまで古い委任先が使われることもあります。
手順2：権威サーバーの応答を直接確かめる
委任先が正しければ、そのネームサーバーに直接問い合わせます。キャッシュを通さないので、DNSサービスが今返している値が分かります。
# 権威サーバーに直接（ネームサーバー名は手順1の結果に置き換える）
dig @ns1.example-dns.net example.com A +norecurse +noall +answer
dig @ns1.example-dns.net example.com AAAA +norecurse +noall +answer
# ネームサーバーが複数あるなら、すべてで同じか
for ns in $(dig example.com NS +short); do
echo "== $ns"
dig @"$ns" example.com A +norecurse +short
done読み方は次のとおりです。
- AもAAAAも何も返らない：ANAMEが保存されていない、名前欄の指定が頂点になっていない、または向け先の解決に失敗しています。手順3へ進みます。
- 古いIPアドレスが返る：同じ名前に古いAレコードが残っていないかを管理画面で確かめます。サービスによっては、同じ名前のAとANAMEを併存させると、どちらが優先されるかが分かりにくくなります。
- ネームサーバーによって答えが違う：同期の遅れか、複数のDNSサービスを併用していて片方だけ更新した可能性があります。
手順3：向け先ホスト名の解決を確かめる
ANAMEの答えは、向け先ホスト名を解決した結果です。向け先側に問題があれば、ANAMEの設定が正しくても期待した答えになりません。
# 向け先が今どのIPを返すか
dig site.example-cdn.net A +short
dig site.example-cdn.net AAAA +short
# 向け先がCNAMEを重ねているなら、たどった経路も見る
dig site.example-cdn.net A +noall +answerここで見るポイントは3つです。
- 向け先のスペル：ホスト名の打ち間違いや、末尾のドットの扱い（サービスによっては自動で補う）を確かめます。向け先が存在しなければ、ANAMEは何も返せません。
- IPv6の有無：向け先にAAAAが無ければ、頂点のAAAAも返りません。これは異常ではありません。
- 地域や時間で答えが変わる向け先：CDNやロードバランサーは、問い合わせ元の場所や時刻で違うIPアドレスを返します。頂点のAと向け先のAが一致しないからといって、設定ミスとは限りません。ANAMEを実装するDNSサービスがどの地点から向け先を解決しているかによって、利用者から遠い拠点のアドレスが返ることもあります。CDNの事業者がANAMEやALIASでの利用を推奨しているか、専用の設定方法を案内しているかを確かめておくと安心です。
手順4：キャッシュの残り時間を確かめる
権威サーバーが新しい値を返しているのに、手元のブラウザや一部の利用者だけ古いサーバーに届く場合は、キャッシュDNSが古い答えを持っています。
# 公開DNSでの答えと残りTTL（2列目）
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
# 権威サーバーが付けているTTL
dig @ns1.example-dns.net example.com A +norecurse +noall +answerキャッシュDNSの残りTTLが0になれば、次の問い合わせで新しい値を取りに行きます。ANAMEでは、利用者側のキャッシュに加えて、DNSサービスの中で向け先の解決結果を保持している時間もかかります。向け先のIPアドレスを変えた直後は、この2つを合わせた時間を見込みます。
TTLの値そのものが長すぎて切り替えが遅い場合は、次回の変更の前にTTLを短くしておくと、待ち時間を減らせます。
手順5：DNSSECとセカンダリDNSを確かめる
ここまでで原因が見つからないときは、構成側の問題を疑います。
DNSSECを有効にしている場合、ANAMEで作られたAレコードにも署名が必要です。署名をその場で行うサービスなら問題になりにくいですが、別の場所で署名したゾーンを配っている構成では、ANAMEの答えに署名が付かず検証エラーになることがあります。
# 検証付きで問い合わせ。SERVFAIL なら DNSSEC を疑う
dig @8.8.8.8 example.com A +dnssec
dig @8.8.8.8 example.com A +cd +short # 検証を止めると答えが返るか+cd を付けたときだけ答えが返るなら、DNSSECの検証で失敗しています。
セカンダリDNSを併用している場合、ゾーン転送で渡るのは、転送した時点のAレコードか、セカンダリ側が理解できない形のデータです。向け先のIPアドレスが変わっても、セカンダリ側は古いままになることがあります。手順2でネームサーバーごとに答えが違った場合は、この構成を確かめます。
検証結果から対処を決める
| 止まっている場所 | 主な対処 |
|---|---|
| 委任（手順1） | レジストラで正しいネームサーバーを設定し、親ゾーンのTTLが切れるのを待つ |
| 権威サーバー（手順2） | 頂点に置いたANAMEの保存状態と、古いAレコードの残りを見直す |
| 向け先（手順3） | ホスト名の誤りを直す。地域差がある向け先はCDN側の推奨方法を確かめる |
| キャッシュ（手順4） | 残りTTLが切れるのを待つ。次回に備えてTTLを見直す |
| 構成（手順5） | DNSSECの署名方式とセカンダリDNSの扱いをDNSサービスの案内で確かめる |
変更の前には、現在のレコードの一覧をエクスポートするか書き出しておき、元に戻せる状態にしてから作業します。
まとめ
- ANAMEは標準のレコードタイプではなく、外からはAとAAAAとして見えます。検証では A と AAAA を問い合わせます。
- 委任、権威サーバー、向け先、キャッシュの順に確かめると、止まっている層が分かります。
- 向け先がCDNの場合、頂点と向け先でIPアドレスが違っても異常とは限りません。
- 待ち時間には、利用者側のキャッシュと、DNSサービス内で向け先を保持する時間の両方が含まれます。
- DNSSECやセカンダリDNSを使う構成では、ANAMEの答えに署名が付くか、転送後も更新されるかを確かめます。