2026年6月6日
2026年6月6日
AAAAレコードのTTLが競合するときの解消方法|同じ名前で値やTTLが食い違う原因を突き止めて直す
AAAAレコードのTTLが「競合している」ように見えるときは、同じ名前に対して、複数のレコードや複数の設定元がそれぞれ別のTTLや値を返している状態です。解消の基本は、どこから答えが返っているかを突き止め、設定元を1か所にまとめ、同じ名前・同じタイプのレコードのTTLをそろえることです。この記事では、競合が起きる5つの原因を見分け方とあわせて説明し、直した後の確かめ方まで扱います。
「TTLの競合」で起きている症状
次のような症状があれば、TTLや値の競合を疑います。
- 同じ名前のAAAAを問い合わせるたびに、TTLの数字や返るアドレスが変わる
- DNSサービスの管理画面で設定したTTLと、
digで見えるTTLが違う - Aレコードとあわせて変更したのに、IPv6だけ切り替わりが遅い・早い
- 管理画面でAAAAを追加しようとすると、既存のレコードと衝突するという趣旨のエラーが出る
まず、権威DNSサーバーそれぞれに直接問い合わせ、どこで食い違っているかを確かめます。
# すべての権威サーバーに AAAA と SOA を問い合わせて見比べる
for ns in $(dig NS example.com +short); do
echo "== $ns"
dig @"$ns" www.example.com AAAA +norecurse +noall +answer
dig @"$ns" example.com SOA +short
done
権威サーバーの段階で食い違っていれば設定の問題、権威サーバーはそろっていてキャッシュDNSだけ違うなら、時間が経てば解消する反映待ちです。以下の原因1〜5は、前者を見分けるためのものです。
原因1:同じ名前の複数のAAAAでTTLが違う
1つの名前に複数のIPv6アドレスを登録すること自体は問題ありません。ただし、同じ名前・同じタイプのレコードの集まり(RRset)は、1つのまとまりとしてキャッシュされるため、TTLはそろえる決まりになっています(RFC 2181)。
; 好ましくない例:同じ名前の AAAA で TTL が違う
www 300 IN AAAA 2001:db8::10
www 3600 IN AAAA 2001:db8::11
; 直した例:TTL をそろえる
www 300 IN AAAA 2001:db8::10
www 300 IN AAAA 2001:db8::11
TTLがばらばらのとき、どの値が使われるかは、DNSサーバーの実装やキャッシュDNSの扱いによって変わります。一部の実装はゾーンの読み込み時に警告を出したり、どちらかのTTLにそろえて返したりします。結果として「設定と違うTTLが見える」「切り替わりが読めない」状態になります。管理画面型のDNSサービスでは、レコードごとにTTLを入力できる画面であっても、同じ名前のAAAAはすべて同じTTLに直しておきます。
BINDなど自前のDNSサーバーなら、ゾーンを読み込む前に named-checkzone example.com /path/to/zonefile で文法を確かめ、警告が出ていないかも見ておきます。
原因2:AとAAAAでTTLが違い、切り替えの時期がずれる
AレコードとAAAAレコードは別のRRsetなので、TTLが違っていても規則上は問題ありません。しかし、サーバー移転などで両方を同時に切り替える場面では、TTLの違いがそのまま切り替え時期のずれになります。たとえばAのTTLが300秒、AAAAが86400秒のままだと、IPv4の利用者は数分で新サーバーに移るのに、IPv6の利用者は最大1日、旧サーバーに届き続けます。
移転の予定があるなら、AとAAAAのTTLを同じ短い値にそろえ、古いTTLの時間が過ぎてから値を変えます。移転が終わったら、両方を同じ値に戻します。
原因3:CNAMEとAAAAが同じ名前にある
ある名前にCNAMEを置くと、その名前には他のタイプのレコードを置けません(RFC 1034、RFC 2181)。www にCNAMEとAAAAが両方あるように見える場合、DNSサービスによっては片方の登録を拒否し、拒否しない実装ではどちらが返るか分からない状態になります。キャッシュDNSにはCNAMEの先のAAAAが、CNAMEの先のTTLで保存されるため、自分で設定したAAAAのTTLとは無関係に見えます。
どちらか一方に決めて、もう一方を削除します。外部サービスに向けるならCNAMEだけ、自分のサーバーに直接向けるならAとAAAAだけにします。ルートドメイン(example.com)でCNAMEのような動きが必要な場合は、DNSサービスが用意しているALIASやCNAMEフラットニングの機能を使います。
原因4:DNSサービスやCDNが自動でAAAAを返している
自分で登録していないAAAAが返る、あるいは登録したAAAAのTTLが反映されないときは、DNSサービス側の機能が答えを作っていることがあります。
- CDNのプロキシ機能:CDN経由にしたレコードは、利用者にCDNのIPv4・IPv6アドレスが返り、TTLもCDN側の値になることが一般的です。自分で入力したTTLや、サーバーのIPv6アドレスは表に出ません。
- ALIASや別名の機能:参照先の値とTTLをDNSサービスが取りにいって返すため、TTLは参照先に従うことがあります。サービスによっては、そもそもTTLを指定できません。
- ホスティングやメールサービスの自動レコード:サービスの初期設定で作られたレコードが、手で追加したレコードと重複していることがあります。
これらはサービスごとに仕様が違い、変わることもあります(2026年10月現在)。使っているDNSサービスのヘルプで、プロキシや別名機能のときにTTLがどう扱われるかを確かめてください。競合を解消するには、プロキシや別名機能を使うか、自分でAAAAを直接書くか、どちらか一方に決めます。
原因5:権威サーバー同士で内容が違う
最初のループで、権威サーバーごとに違うAAAAやTTLが返った場合は、ゾーンが1つにまとまっていません。よくあるのは次の2つです。
- ネームサーバーに2つのDNSサービスが混ざっている:移管の途中などで、レジストラに登録したNSが旧DNSサービスと新DNSサービスの両方を指していると、問い合わせ先によって答えが変わります。NSを使う方だけにそろえるか、両方のゾーンを同じ内容に保ちます。
- プライマリとセカンダリの同期が止まっている:自前のDNSサーバーで、SOAのシリアル番号がサーバーごとに違う場合、セカンダリに変更が届いていません。シリアル番号を上げ忘れていないか、ゾーン転送が許可されているかを確かめます。
直した後の確かめ方
設定を直したら、もう一度すべての権威サーバーに問い合わせ、同じ名前のAAAAがすべて同じ値・同じTTLで返ることを確かめます。そのうえで、キャッシュDNSの古い答えが切れるのを待ちます。待つ時間の上限は、直す前に返っていた中で最も長いTTLです。
dig @1.1.1.1 www.example.com AAAA +noall +answer
dig @8.8.8.8 www.example.com AAAA +noall +answer
キャッシュDNSの残りTTLは問い合わせるたびに減っていきます。古い値がすべて消え、新しい値だけが返るようになれば解消です。作業の前にはゾーンの内容を控え、変更は1か所ずつ行うと、どの変更が効いたかが分かりやすくなります。
まとめ
- 「TTLの競合」は、同じ名前に対して複数のレコードや設定元が別々のTTL・値を返している状態です。まず権威サーバーごとの応答を見比べます。
- 同じ名前のAAAAが複数あるなら、TTLをそろえます。
- AとAAAAのTTLが違うと、移転時の切り替えがずれます。移転前に両方を同じ短い値にします。
- CNAMEとAAAAは同じ名前に置けません。どちらか一方にします。
- CDNのプロキシやALIAS機能、2つのDNSサービスの混在、同期の停止も、TTLや値が食い違う原因になります。