DNSのTTL（Time to Live）は、DNSレコードをキャッシュして利用する時間を示す値です。IPアドレスを変更しても、利用者が参照するキャッシュに古い答えが残っていれば、すぐには新しい接続先へ向かいません。
TTLは「管理画面で変更してから全員の接続先が切り替わる時間」の保証ではありません。移行担当者は、設定値だけでなく、どこでどの答えを確認したかを分けて記録する必要があります。
TTLとキャッシュの関係
DNSでは、ドメイン名に対応する情報を持つ権威DNSと、その情報を問い合わせて利用者へ返すリゾルバーを区別します。リゾルバーは取得した答えを一定時間保持し、同じ問い合わせに再利用します。
AWSの公式説明では、TTLは秒単位で、再問い合わせをせずレコードをキャッシュできる時間を判断する値です。短くすると変更を認識しやすくなる一方、問い合わせが増えます。Amazon Route 53のTTLに関する説明
たとえばTTLが3,600秒なら1時間です。ただし、これは「毎時0分に全利用者が更新する」という意味ではありません。取得のタイミングが異なれば、古い答えが残る時間も異なります。
変更直前に短くしても古いキャッシュは別に考える
説明用に、あるリゾルバーが9時にTTL3,600秒の答えを取得したとします。9時10分に権威DNS側でTTLを300秒へ変更しても、そのリゾルバーが新しい設定をすぐ問い合わせるとは限りません。すでに持っている答えの扱いを考える必要があります。
このため、切替計画では次の順を検討します。実際の待機時間や設定可能な範囲は、利用サービスの仕様に合わせて決めてください。
- 変更対象のレコード名・種類・値・現在のTTLを控える。
- 必要なら、接続先変更より前にTTLを短くする。
- 旧TTLと変更時刻を踏まえて待機し、対象の答えを確認する。
- 接続先を変更し、名前解決とアプリケーションの両方を確認する。
- 安定後にTTLを見直す。
AWSも重要なDNS変更前の一時的なTTL短縮を説明しています。すべてのレコードを常に最短へ変えることが目的ではありません。
推奨値は変更頻度と運用条件から決める
一律に「300秒が正解」と決めると、サービス固有の制限や運用目的を見落とします。次のように条件を整理すると判断しやすくなります。
| 確認する条件 | 判断で考えること |
|---|---|
| 接続先を変える予定 | 変更と確認を行う時間帯、旧TTL |
| 問い合わせ量 | 短縮による問い合わせ増加と費用への影響 |
| レコードの種類 | A・AAAA・CNAMEなど、変更する情報の違い |
| DNSサービスの制約 | 設定可能な値、固定値、プロキシの有無 |
| 切り戻し | 戻した後もキャッシュが残る前提での確認 |
たとえばCloudflareのプロキシ対象レコードはTTLがAutoの300秒で、編集できないと説明されています。また、ローカルキャッシュの影響で変更の体感に5分を超える場合もあるとしています。これはCloudflareの仕様例です。Cloudflare「Time to Live」
確認結果には問い合わせ先と時刻を残す
「新しいIPが出た」だけでは、どこまで切り替わったか判断できません。権威DNSへの確認と、利用者が使うリゾルバー経由の確認を区別します。
確認記録には、対象名・レコード種類・問い合わせ先・回答値・確認時刻・観測したTTLを残すことを勧めます。キャッシュから返る残り時間と、管理画面に設定した値を混同しないようにします。
DNSが正しくても、接続先の証明書やアプリケーションが正しいとは限りません。名前解決の後に、実際のURLで必要な画面や機能を確認します。移行全体はクラウド移行の切替計画と合わせて整理してください。
まずは対象レコードの現在値と、誰がどの経路で確認するかをそろえるところから始めましょう。基盤の変更準備や運用体制については、インフラサポートをご覧ください。