DNSのTTLを短くしたのに変わらない？取得した時点からのキャッシュを考えよう

DNSの設定を変えたのに、まだ古い接続先へ進む。TTLを短くすれば、すぐ全員が切り替わるのかな。まず、すでに保存された応答と、新しく取得する応答を分けて考えよう。

TTLはTime to Liveの略で、DNSレコードをキャッシュする時間に関係する値。今回は架空の時刻だけを使い、実際のドメイン設定は変更しないよ。

TTLは、レコードごとの秒数

300秒なら5分、3600秒なら1時間。再帰リゾルバーなどは取得したDNS応答を一定期間保存し、毎回すべての問い合わせをやり直さずに使える。

長く保存できれば問い合わせを減らせるけれど、変更した値を見に行くまで時間が残る場合もある。どの応答を、いつ取得したかが大切になるんだ。

保存済みの応答へ、新しいTTLはさかのぼらない

次は、通常の有効期限だけを考えた単純な練習例だよ。

10:01に新しいTTLを60秒にしても、10:00に取得した応答の期限まで自動で短くなるとは考えないようにしよう。

10:05に世界中へ一斉に新しい値が配られるという意味でもない。利用者ごとに取得した時点が違い、必要になったときに問い合わせる経路も異なるよ。

5分なら、必ず5分後に全員切り替わる？

Cloudflareの公式資料でも、300秒のTTLがある設定について、ローカルDNSキャッシュなどにより実際の変更が見えるまで5分以上かかる場合があると説明している。

また、障害への耐性のため、有効期限を過ぎた応答を条件付きで提供するserve-staleの仕組みも標準化されている。単純なTTLの算数だけで、すべての環境の最大待ち時間を保証することはできないよ。

今回の時刻表は通常の期限を理解する例で、実際の変更が必ずその時刻に反映されるという測定結果ではないんだ。

TTLと、別の待ち時間も分ける

DNSサービス側へ変更が反映されたか、参照しているネームサーバーが正しいか、ブラウザやOSに保存があるかも関係する。Webのキャッシュや接続済みの通信も、DNSのTTLと同じものではない。

ブラウザの再読み込みを何度も押しただけで、DNSの保存がすべて消えるとは限らないよ。

変更を計画するときの確認案

1. 対象のレコード、変更前のTTL、変更先を記録する。
2. TTLを変える場合は、すでに取得済みの応答の期限も考える。
3. 元のDNS設定と、実際に利用者側で見えている応答を分けて調べる。
4. 接続先の切替を確認するまで、古い接続先の扱いを計画しておく。
5. 反映を確認した日時と経路を残す。

編集部では公式資料と、架空の300秒・60秒の時刻関係を確認した。実際のDNS伝播や各社の最大待ち時間を測った結果ではないよ。基本の種類はA・AAAA・CNAME、表示の問題はホームページが表示されないときも参考になるね。