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や値が食い違う原因になります。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲