2026年6月12日

AAAAレコードのTTL誤設定を修正する方法｜長すぎ・短すぎ・Aレコードとのずれを直す手順

DNS・名前解決

AAAAレコードのTTLを誤って設定したときは、まず権威DNSで今のTTLを確かめ、キャッシュに残っている古い値がいつ消えるかを見積もってから直します。TTLを書き換えても、すでにキャッシュされている応答は元のTTLが切れるまで残るため、「値を直したのにまだ古い」は多くの場合正常な動きです。この記事では、AAAAレコードのTTLでよくある誤りのパターンと、それぞれの直し方、急いで影響を止めたいときの対処を説明します。

AAAAレコードのTTLで起きやすい誤り

TTL（Time To Live）は、キャッシュDNSがその応答を何秒間使い回してよいかを示す値です。AAAAレコードはIPv6アドレスを返すレコードで、IPv6で接続できる利用者は、多くの場合AAAAの宛先を優先して使います。そのため、AAAAのTTLの誤りは「一部の利用者だけ古いサーバーにつながる」という分かりにくい症状になりがちです。

よくあるのは次の4つです。

長すぎる: 86400秒（1日）などのまま、サーバー移転でアドレスを変えた。変更が行き渡るまで最大でその時間がかかります
短すぎる: 30秒などに下げたまま戻し忘れた。キャッシュが効きにくく、権威DNSへの問い合わせが増え、応答も遅くなりがちです
Aレコードとずれている: 移転前にAだけTTLを下げ、AAAAは下げ忘れた。IPv4の利用者は新サーバー、IPv6の利用者は旧サーバーにつながります
同じ名前のAAAAでTTLが不ぞろい: 複数のAAAAに別々のTTLを入れた。同じ名前・同じ型のレコードは1つの組（RRset）として扱われ、TTLは組全体で同じであるべきものです。DNSサーバーによっては警告を出し、どちらかの値にそろえて応答します

ステップ1：今のTTLと残り時間を確かめる

権威DNSが返している「設定値としてのTTL」と、キャッシュDNSに残っている「残り時間」は別物です。両方を見ます。

# 権威DNSに直接問い合わせる（設定値が分かる）
dig +short NS example.com
dig @ns1.example.net +norecurse +noall +answer www.example.com AAAA

# 公開DNS経由（キャッシュの残り秒数が分かる）
dig @8.8.8.8 +noall +answer www.example.com AAAA
dig @1.1.1.1 +noall +answer www.example.com AAAA

出力の2列目の数字がTTLです。

www.example.com. 86400 IN AAAA 2001:db8::10

権威DNSで86400と出ていれば設定値が1日、公開DNSで例えば41000と出ていれば、そのキャッシュではあと約11時間古い値が使われる見込みです。キャッシュDNSは世界中に多数あり、それぞれ別の時点で取得しているため、最悪の場合は元のTTLの分だけ待つと考えておきます。

あわせてAレコードも同じように問い合わせ、AとAAAAでTTLと宛先がそろっているかを確認します。

ステップ2：パターン別に直す

作業の前に、DNSの管理画面のエクスポートやゾーンファイルのコピーを取っておきます。

TTLが長すぎた場合

これから宛先を変える予定なら、次の順に進めます。

AAAA（とA）のTTLを300秒程度に下げる
元のTTLの時間だけ待つ（86400だったなら1日）
AAAAの宛先を新しいアドレスに変える
新しいサーバーで問題が無いことを確かめる
TTLを3600秒など平常時の値に戻す

2の待ち時間を飛ばすと、TTLを下げた効果が出る前に宛先を変えることになり、古い宛先が長く残ります。TTLの値そのものも、キャッシュが切れて初めて新しい値に置き換わるためです。

すでに宛先を変えてしまった後なら、TTLを下げても残っているキャッシュには効きません。後述の「急いで影響を止めたいとき」を参照してください。

TTLが短すぎた場合

宛先の変更予定が無ければ、平常時の値（3600秒前後が一つの目安）に戻します。短いTTLは障害時の切り替えを速くする目的で意図的に使うこともあるため、DNSフェイルオーバーなどの仕組みがあるかを確かめてから変えます。なお、キャッシュDNSによっては、極端に短いTTLを独自の下限まで引き上げて扱うことがあります。

Aレコードとずれていた場合

移転の途中なら、AAAAの宛先を新サーバーのIPv6アドレスにそろえます。新サーバーがIPv6に対応していない場合は、AAAAを削除する選択肢もあります。ただし、AAAAを削除すると「AAAAは存在しない」という応答もキャッシュされ、その保持時間はSOAレコードの値をもとに決まります。後でAAAAを追加し直すと、その間は反映が遅れて見えます。

dig +noall +answer example.com SOA

SOAの最後の数値（最小値）とSOA自体のTTLのうち小さいほうが、存在しない応答をキャッシュする時間の目安です。

同じ名前のAAAAでTTLが不ぞろいだった場合

すべてのAAAAに同じTTLを設定し直します。ゾーンファイルで管理しているなら、編集後にSOAのシリアルを上げ、named-checkzone で構文を確かめてから読み込みます。

named-checkzone example.com /var/named/example.com.zone
sudo rndc reload example.com

DNSサービスごとの注意

マネージドDNSでは、TTLを自由に選べない場合があります（2026年10月現在の仕様で、変わることがあります）。

Cloudflare でプロキシを有効にしたレコードは、TTLがサービス側の自動値になり、利用者が細かく指定できません。宛先は Cloudflare のアドレスとして返るため、元サーバーの移転はDNSのTTLではなく Cloudflare 側の設定変更で切り替わります
Route 53 のエイリアスレコードは、TTLを自分で設定できず、エイリアス先のリソースの値が使われます
レンタルサーバー付属のDNSでは、TTLの選択肢が決められていたり、変更自体ができなかったりします

管理画面で入れた値と、dig で権威DNSに問い合わせた値が一致しているかを最後に確かめる習慣をつけておくと、こうした違いに早く気づけます。

急いで影響を止めたいとき

TTLの長いAAAAが古い宛先を指したまま広まってしまった場合、DNS側だけで即座に消す方法はありません。現実的な手段は次のとおりです。

旧サーバー側で受け止める: 旧サーバーを止めずに残し、リバースプロキシで新サーバーへ転送する、または移転完了の案内を出す
公開DNSのキャッシュ消去を依頼する: Google Public DNS や Cloudflare の 1.1.1.1 には、特定の名前のキャッシュを消す依頼ページがあります。ただし、利用者が使っているキャッシュDNSのごく一部にしか効きません
自分の環境のキャッシュを消す: 確認作業用に、OSやブラウザのDNSキャッシュを消します

なお、IPv6でつながらないときに短時間でIPv4へ切り替える仕組み（Happy Eyeballs）を持つブラウザが多いため、IPv6の宛先が「応答しない」場合は影響が小さく見えることがあります。一方、旧サーバーが応答してしまう場合は切り替わらず、古いサイトが表示されます。Let's Encrypt のHTTP検証もIPv6を優先して使うため、AAAAが旧サーバーを指していると、証明書の発行や更新が失敗する原因になります。

最後に、IPv4とIPv6それぞれで新しいサーバーにつながるかを確かめます。

curl -4 -sI https://www.example.com/ | head -n 1
curl -6 -sI https://www.example.com/ | head -n 1

まとめ

権威DNSの設定値と、キャッシュDNSの残り時間を分けて確かめる
TTLの変更も、古いキャッシュが切れるまでは効かない
移転は「TTLを下げる、元のTTLだけ待つ、宛先を変える、TTLを戻す」の順で、AとAAAAの両方に行う
AAAAの削除は存在しない応答のキャッシュ（SOAで決まる）も考えておく
影響を早く止めたいときは旧サーバー側で受け止め、curl -4 と curl -6 で両方を確認する