DNS・名前解決 / DNS
TTLとは
Time To Live。DNS結果をキャッシュしてよい時間です。短いほど切替反映を待ちやすくなります。
用語集内のカードを見るこの記事で学べること
TTLを、定義だけで終わらせず、現場で出てくる場面、確認材料、見落としやすい点、関連語とのつながりまで順に確認できます。
- TTLを読むときの前提
- 切替前に短縮する
- 残りTTLで反映待ちを判断する
- 障害時の戻しを過信しない
- 変更証跡と引き継ぎ
実務メモ
残りTTLで反映待ちと設定ミスを分ける
どこで効くか
TTLはDNS切替、障害時の戻し、キャッシュ残りの説明で効きます。変更前に短縮したか、再帰DNSで旧値がどれだけ残っているか、復旧後に通常値へ戻したかを確認します。
残す証跡
証跡には対象FQDN、レコード種別、旧TTL、新TTL、回答値、問い合わせ先DNS、残りTTL、短縮日時、切替日時、戻し日時を残します。
避けたい誤解
権威DNSで新値が見えても、利用者側に旧回答がTTL分残ることがあります。逆に残りTTLが毎回初期値へ戻る場合は、単なる反映待ちではなく委任先違いや社内DNS上書きの可能性があります。
まず確認すること
- 切替前に旧TTL分の余裕を持って短縮する
- 旧値が返る場所と残りTTLを保存する
- 作業後にTTLを通常値へ戻したか確認する
TTLを読むときの前提
TTL（Time To Live）は、DNS回答を再帰DNSや端末がキャッシュしてよい秒数です。DNS切替の速さだけでなく、問い合わせ量、障害時の戻しやすさ、利用者側で旧値が残る時間に影響します。
実務では、権威DNSに設定したTTL、再帰DNSが返す残りTTL、端末やブラウザのキャッシュを分けます。権威DNSでTTLを変えても、すでに配られた旧回答の残り時間はすぐには消えません。
証跡には、対象FQDN、レコード種別、旧TTL、新TTL、回答値、問い合わせ先DNS、残りTTL、問い合わせ時刻を残します。
切替前に短縮する
DNS切替を計画する場合、変更直前ではなく、旧TTLが十分に失効する前からTTLを短くします。たとえばTTLが86400秒なら、少なくとも1日前には短縮しておかないと、利用者側に旧値が残り続けます。
TTL短縮は便利ですが、短すぎる値を長期間置くと問い合わせ数が増えます。障害時の一時対応と恒久運用値を分けて設計します。
- 旧TTL分の時間を見込んで短縮する。
- 切替日時、短縮日時、戻し日時を分けて記録する。
- 恒久TTLへ戻す手順を作業後確認に入れる。
残りTTLで反映待ちを判断する
利用者側DNSで旧値が返る場合、残りTTLを見ると反映待ちか異常かを判断しやすくなります。残りTTLが減っている旧回答ならキャッシュ残りの可能性が高く、残りTTLが毎回初期値に戻るなら別の権威DNSや社内DNS設定を疑います。
複数の再帰DNSで回答を比べると、地域差や社内DNSだけの上書きを確認できます。DNSの反映確認では「どこに聞いたか」を必ず残します。
- 旧値の残りTTLを保存する。
- 再帰DNSごとの回答差を確認する。
- 残りTTLが不自然に戻る場合は委任や転送を疑う。
障害時の戻しを過信しない
DNSを戻しても、利用者側に新値がキャッシュされている間は旧環境へ戻らないことがあります。戻しを成立させるには、旧環境も新環境も一定時間受けられる設計にしておく方が安全です。
CNAMEを使う構成では、元FQDNのTTLだけでなくCNAME先や最終A/AAAAのTTLも影響します。CDNやSaaS側のTTLを利用者が直接制御できない場合もあります。
- 戻し後も新旧両方の受け口を維持する。
- CNAME先と最終回答のTTLも確認する。
- DNS戻しだけで復旧と判断しない。
変更証跡と引き継ぎ
TTL変更では、短縮の理由、対象レコード、旧値、新値、戻し予定、実際に戻した時刻を残します。障害対応で短くしたTTLは、復旧後の棚卸し対象にします。
引き継ぎでは、通常時の標準TTL、切替時の一時TTL、確認に使うDNSサーバー、関連語としてDNS、FQDN、CNAME、権威DNS、再帰DNSを残すと運用しやすくなります。
- 一時TTLの戻し漏れをレビューする。
- 問い合わせ先ごとの残りTTLを残す。
- TTLとサービス側切替手順を同じ作業計画に入れる。
関連語
同じ主要カテゴリの用語
DNS・名前解決の学習順
同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。