DNSのTTLとキャッシュは、変更後にどう働く？

TTLは、受け取った答えを再利用できる時間

TTL（Time to Live）は秒単位の値です。再帰リゾルバは受け取ったDNSデータをキャッシュし、通常は残りTTLの範囲で再利用します。権威DNSの設定を変えても、すでに配られたキャッシュを世界中から一斉に消す命令にはなりません。キャッシュは容量などの都合で早く破棄されることもあり、TTLいっぱい保存される保証でもありません。

同じ300秒でも起点が違う

単純化した例ですが、「変更時刻から必ず300秒」ではないことが分かります。RFC 9499 §5は、TTLの用語を整理しています。

TTLを下げても、取得済みの古いTTLは短くならない

移行に備えてTTLを3600から300へ変更しても、直前に3600で受け取ったリゾルバはその古い期限を持っています。短いTTLを使わせたいなら、アドレス切替より前に下げ、旧TTLのキャッシュが残る時間を見込みます。切替と同時に下げるだけでは、以前のキャッシュに効きません。

PCのキャッシュだけを消しても残るもの

PCのDNSキャッシュを消しても、問い合わせ先の再帰リゾルバに古い答えがあれば再び受け取ります。ブラウザやアプリが独自の名前解決・接続再利用を行う場合もあります。逆に、すべての閲覧者が同じリゾルバを使うわけでもありません。TTLだけで移行完了時刻を約束するのは難しい理由です。

「存在しない」という答えもキャッシュされる

新しい名前を作ったのに見つからない場合、作成前のNXDOMAINが残っていることがあります。NXDOMAINは名前が存在しない応答、NODATAは名前はあるが問い合わせた種類のデータがない応答です。「応答が空だから同じ」とは扱えません。

AレコードのTTLとは別の期限

RFC 2308 §3–5では、負の応答に含めるSOAのTTLを、SOAレコード自身のTTLとSOAのMINIMUM値の小さい方から求めます。例えば3600と600なら600秒が元の上限です。新設したAレコードのTTLを60にしても、先に保存された「ない」という答えが60秒へ変わるわけではありません。

期限切れデータと名前解決の失敗は別に読む

権威DNSへ到達できず更新に失敗したとき、対応するリゾルバが期限切れの情報を返すことがあります。serve-staleと呼ばれる仕組みで、RFC 8767 §5–7は可用性と情報の新しさを両立する方法を示しています。通常のTTLを、どんな状況でも古い答えが消える絶対期限とは読めません。

SERVFAILは「その名前は存在しない」ではない

タイムアウトやDNSSEC検証失敗などの解決失敗は、NXDOMAINと違ってデータの不存在を証明しません。RFC 9520 §3.2は失敗のキャッシュも要求します。修復直後に再試行しても、リゾルバが短時間の失敗キャッシュを返す場合があります。

DNS比較で分かることを絞る

Online ToolsのDNSルックアップでは、公開しているドメインとAなどの種類を選び、Google Public DNS、Cloudflare、Quad9、OpenDNSの答えを比較できます。入力した名前はサーバーへ送られ、そのサーバーから各リゾルバへ問い合わせます。未公開の社内名を調べる用途には向きません。

多数派と一致しても、世界全体の反映完了ではない

結果は問い合わせた時点・場所での観測です。このツールは残りTTLやSOA、NXDOMAINとNODATAの区別を表示せず、値の多数派を比較します。差があればキャッシュだけでなく、地域別応答やDNS設定の相違も候補になります。TTLや負の応答の詳細が必要なら、管理下の環境でdigの完全な応答を読み、権威DNSと普段使うリゾルバの答えを照合します。

仕様と、名前解決の流れ

RFC 1034 §4.3.4：キャッシュ、RFC 2308 §5：負の応答、RFC 8767 §4：TTLの更新された扱い、RFC 9520 §3：解決失敗のキャッシュ。問い合わせの経路はDNSの基礎とルートサーバー、別の種類のキャッシュはHTTPキャッシュへ。