ANAMEレコードのTTLを誤設定したときは、まず「利用者に返っているTTL」と「向け先ホスト名のTTL」を dig で並べて確かめ、ANAME側の値を向け先の変化に追いつける長さ（多くの場合は数分〜1時間程度）に直します。そのうえで、直す前に配られていた古いTTLが切れるまで待つ必要があります。この記事では、ANAMEに特有の「TTLが二重になる仕組み」を押さえ、誤設定の見分け方、直し方、直した後の確認までを順に説明します。
ANAMEのTTLは二段構えになっている
ANAME（サービスによってはALIAS、CNAMEフラットニングとも呼ばれます）は、ゾーンの頂点（example.com）にCNAMEのような「別名」を置くための仕組みです。DNSの標準規格ではCNAMEを頂点に置けないため、DNSサービスが向け先のホスト名を裏で引き、その結果をAレコード・AAAAレコードとして返します。IETFで標準化が議論された時期もありましたが、正式な規格にはなっておらず、動きはDNSサービスごとに異なります（2026年10月現在）。
この仕組みのため、TTLが2か所に関わります。
- 向け先のTTL: CDNやホスティング会社が
xxx.cdn.example.netなどに付けている値です。DNSサービスはこのTTLを目安に、向け先を引き直します - 利用者に返すTTL: DNSサービスが合成したA・AAAAレコードに付けて返す値です。キャッシュDNS（プロバイダーや公開DNS）はこの値の間、答えを使い回します
サービスによって、ANAMEに入力したTTLをそのまま返すもの、向け先のTTLと入力値の短いほうを返すもの、利用者がTTLを選べず固定値になるものがあります。Route 53のエイリアスレコードのように、AWSのリソースを向け先にした場合はTTLを入力する欄自体が無く、向け先側の値が使われる例もあります。自分のサービスがどの方式かを、まずドキュメントで確かめてください。
誤設定の症状を読み分ける
TTLの誤設定は、レコードの値自体は正しいため気づきにくいのが特徴です。よくある症状と、その裏にある設定は次のとおりです。
- CDNやホスティングのIPが変わった後、一部の利用者だけ古いサーバーに届く: 返すTTLが向け先より極端に長く（86400秒など）、キャッシュDNSが古いIPを持ち続けている
- **頂点（
example.com）だけ表示が遅れて切り替わり、wwwは先に切り替わる**:wwwのCNAMEとANAMEでTTLが大きく違う - DNSの問い合わせ件数や従量課金が急に増えた: 返すTTLを数十秒など短くしすぎている
- TTLを直したのに、しばらく何も変わらない: 直す前の長いTTLがキャッシュに残っている（誤設定ではなく、待ち時間）
「一部の人だけ」「頂点だけ」という偏りがあるときは、まずTTLを疑うと切り分けが早く進みます。
現在の値を確かめる
最初に、権威DNS（ドメインのネームサーバー）が何秒のTTLを返しているかを確かめます。ネームサーバー名は dig example.com NS +short で分かります。
# 権威DNSに直接問い合わせる（キャッシュを通さない値が見える）
dig @ns1.example-dns.net example.com A +noall +answer
dig @ns1.example-dns.net example.com AAAA +noall +answer
# 向け先ホスト名のTTLと比べる
dig xxx.cdn.example.net A +noall +answer出力の2列目の数字がTTL（秒）です。権威DNSから返った値が、管理画面で入れた値と同じか、向け先の値に合わせて変わっているかを見ます。
次に、公開DNS経由でも問い合わせます。
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answerキャッシュDNSが返すTTLは残り時間なので、問い合わせのたびに減っていきます。TTLを直した直後に、権威DNSの新しい値より大きい残り時間が見える場合は、直す前の答えがまだキャッシュに残っている印です。減り方を見ると「あと何秒で古い答えが消えるか」の見当がつきます。権威DNSが複数あるときは、すべてに同じ問い合わせをして値がそろっているかも確かめます。サーバーごとに答えが違う場合は、セカンダリDNSがANAMEに対応しておらず、古い固定のAレコードを返していることがあります。
TTLを直す手順
1. 変更前にバックアップを取る
管理画面の表示か、ゾーンのエクスポート機能で、頂点のレコード一式（ANAME、MX、TXT、CAAなど）を控えます。ANAMEを一度削除して作り直す画面では、同じ名前の他のレコードに触れてしまう事故が起きやすいためです。
2. 値を決める
決め方の目安は次のとおりです。
- 通常運用: 300〜3600秒程度。向け先がCDNでIPがよく変わるなら短め、ホスティングの固定IPに近いなら長めにします
- 向け先より長くしない: 向け先が60秒なら、ANAMEを1日にすると、向け先の切り替えに追いつけません。向け先と同じか、それより少し長い程度にとどめます
- 短くしすぎない: 30秒未満などにしても、キャッシュDNSによっては下限を設けているため期待どおりに効かず、問い合わせ量だけが増えます
TTLを入力できず「自動」などの選択肢しか無いサービスでは、その既定値で運用し、変えられない旨を運用メモに残しておくのが現実的です。
3. ANAMEのTTLを変更する
管理画面で頂点のANAME（ALIAS）を開き、TTLの欄を変えて保存します。表記や項目の位置はサービスによって違い、更新で変わることもあるため、画面上の名前ではなく「頂点の別名レコードのTTL」を探してください。同じ名前に古いA・AAAAレコードが残っていると、それが優先されたり混ざって返ったりするため、この機会に整理します。
4. 古いTTLが切れるのを待つ
ここが見落とされやすい点です。たとえば86400秒のTTLを300秒に直しても、直す前に問い合わせたキャッシュDNSは、最大で86400秒（1日）古い値を持ち続けます。新しいTTLが広く効くのは、古いTTLが切れた後です。
キャッシュDNSの中には、TTLの上限を独自に設けているものもあります（BINDやUnboundには上限を決める設定があり、既定値も版によって違います）。実際の待ち時間は、古いTTLを上限の目安として考えるとよいでしょう。
5. 自分の環境のキャッシュを消す
確認する端末のキャッシュが残っていると、直ったかどうかを判断できません。OSのDNSキャッシュを消し、ブラウザも再起動します。
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux（systemd-resolved を使っている場合）
sudo resolvectl flush-cachesサーバー移転やCDN切り替えの前にやること
TTLの誤設定が問題になるのは、ほとんどが向け先を変える場面です。移転を予定しているなら、作業の1〜2日前（直前のTTL以上の時間）にANAMEのTTLを300秒程度へ下げ、古いTTLが切れてから向け先を切り替えます。切り替え後に問題が無ければ、TTLを通常の値に戻します。
WordPressサイトの場合、頂点だけでなく www のCNAMEも同じ計画に含めてください。サイトアドレス（WordPressの設定にあるURL）が www 付きか無しかで、利用者が最初に解決する名前が変わります。どちらか片方だけTTLが長いと、リダイレクトの前後で別々のサーバーに届き、ログイン状態やキャッシュの不整合のように見える症状が出ることがあります。
直ったことを確かめる
最後に、次の3点をそろえて確認します。
- 権威DNSのすべてで、新しいTTLが返っている
- 公開DNS経由のTTLが、新しい値以下で減っていく
- 向け先を引いた結果と、頂点のA・AAAAの値が一致している
外部の伝播確認サービスを使うと、地域ごとのキャッシュDNSでの見え方をまとめて確かめられます。ただし表示はキャッシュの残り具合を映しているだけなので、権威DNSの値が正しいことを先に確かめてから使うと迷いません。
まとめ
- ANAMEのTTLは、向け先のTTLと、利用者に返すTTLの二段構えになっている
- 返すTTLの扱いはDNSサービスごとに違うため、まずドキュメントと
digで実際の値を確かめる - 返すTTLは向け先より極端に長くせず、短くしすぎもしない
- TTLを直しても、直す前の古いTTLが切れるまでは古い答えが残る
- 移転やCDN切り替えの前にTTLを下げ、
wwwのCNAMEも同じ計画で扱う