DNSのTTLはいつ下げる？サーバー切り替え前の準備と確認表

先に答え：TTLは変更前に見直す。切り替え完了の保証時間ではない

DNSのTTLは、DNSの応答をキャッシュして使う時間に関わる値です。RFC 1034では秒単位で定義されています。300は5分、3,600は1時間、86,400は24時間です。TTLを300にしたからといって、5分後に全員の表示が必ず切り替わるわけではありません。

この記事は、同じDNS管理先で既存のWeb向けレコードを変更する場面を中心に扱います。ネームサーバー自体の変更、ドメイン移管、メール移行は作業範囲が異なるため、この手順だけで完了させないでください。

画像を拡大 ↗

DNSの設定元からリゾルバーのキャッシュ、閲覧者のWeb表示へ進む流れ。閉じる ×

DNSのキャッシュと、Webコンテンツのキャッシュを分ける概念図。

DNSの保存と、閲覧者が見る結果を分ける

DNS管理画面の保存は、設定元の変更です。閲覧者が使うDNSリゾルバーなどに古い応答が残っている場合は、同じURLでも一時的に違う接続先へ進むことがあります。CloudflareのFAQも、以前のTTLに応じて旧データがキャッシュに残る点を説明しています。

ここで、ブラウザーに古いHTMLや画像が残る問題と混同しないことが大切です。DNSの接続先が新しくなっていても、Webコンテンツ側のキャッシュを別途確認する必要があります。逆に画像を再読み込みしても、DNSの設定値が誤っていれば直りません。

時刻の例：後から短くしても、受け取り済みの値は残る

次は仕組みを説明するための単純化した架空例です。実測値やサービスの保証ではありません。

1. 9:00に、あるDNSリゾルバーが旧接続先をTTL 3,600秒で取得します。
2. 管理者が9:10に、設定元のTTLを300秒へ短くします。
3. 9:20に、接続先を新サーバーへ変更します。
4. このリゾルバーが9:00の応答を有効期限まで使う場合、10:00まで旧接続先を返し得ます。

この例では、9:10の変更から5分待っただけでは足りません。以前の値で受け取られたキャッシュが残るためです。RFC 1034は、予定された変更の前にTTLを減らし、変更後に戻す考え方を示しています。

画像を拡大 ↗

9時に3600秒で旧応答を取得したリゾルバーは、9時10分にTTLを下げても10時まで旧接続先を返し得る架空例。閉じる ×

時刻入りの説明例。TTL短縮前に取得された応答が残る点を示します。

切り替え計画では、短縮前のTTLを記録し、その値を持つ既存キャッシュが残る期間を考慮します。「必ず24時間待つ」と一律に決めるのではなく、現在の設定、変更するレコード、DNSサービスの案内から日程を組みます。新しい値を間違えて登録した場合も、待っているだけでは正しい値にはなりません。

変更前に、戻すための表を作る

作業はTTLを下げるところから始めず、先に現在の設定と移行先の準備を記録します。次の表は編集部の作業用ひな形です。

画像を拡大 ↗

名前と種類、変更前の値とTTL、変更後の値と時刻、戻す条件と担当者を記録する表。閉じる ×

DNS変更の作業記録に含める項目。個人情報や秘密キーは記入しません。

メールを移さないなら、Web移行のためにMXやメール認証用TXTまでまとめて書き換えないよう対象を限定します。Aだけ直してAAAAを見落とす、といった不一致がないかも確認します。公開先から指定されたレコードと、実際に使っている名前を照合してください。

切り替えは「準備・変更・観測・復旧判断」の順番で進める

1. 新サーバー側で、公開予定の内容、独自ドメインの受け入れ、HTTPSの準備状況を確認します。
2. 既存設定を保存し、必要ならTTLを事前に短縮します。短縮できない場合は、その条件で計画します。
3. 旧TTLと事業上必要な確認時間を踏まえ、切り替え時刻を決めます。
4. 変更する名前・種類・値を照合し、対象レコードを保存します。
5. DNSの応答と、実際の本文・画像・フォームを分けて確認します。確認した回線と時刻も残します。
6. 新旧どちらにもデータが書き込まれる機能がある場合は、保存先や受付停止の扱いを確認します。
7. 問題があれば、記録した条件に従って戻します。戻すDNS変更にもキャッシュが関係するため、即時復旧を前提にしません。
8. 安定を確認してからTTLを通常運用の値へ戻し、旧環境の停止を判断します。

これは移行計画のひな形です。決済・会員・予約等があるサイトでは、データ同期や二重受付の扱いも含めて担当者と設計してください。トップが表示されたという確認だけで、旧サーバーを直ちに解約するのは避けます。

CloudflareのAutoはどの設定かを確認する

2026年10月12日に確認したCloudflareの資料では、プロキシ対象レコードのTTLはAuto（300秒）で編集できません。DNS onlyのAutoも300秒です。また、端末側などのキャッシュにより、実際に変更を認識するまで5分を超える場合があると説明されています。ネームサーバーのTTLは別項目です。

画像を拡大 ↗

DNS設定元、回線差、Web表示、フォームの失敗をそれぞれ異なる確認先へ分ける図。閉じる ×

反映待ちだけで片付けず、観測した状態から確認先を選びます。

このため、Autoのままで変更できない画面に遭遇しても、直ちに異常とは判断しません。まずレコードがプロキシ対象か、DNS onlyかを確認します。TTLを編集するためだけに、意味を確認せずプロキシ状態を切り替えないでください。

うまく切り替わらないときの記録

担当者へは「まだ反映しない」だけでなく、対象名、変更時刻、変更前後の値、TTL、確認回線、実際の症状を渡します。認証キーや管理パスワードを調査メモに貼る必要はありません。

SITE PORTを検討するときの確認ポイント

サイトの見た目だけでなく、公開時に必要な設定や担当範囲も整理して選びたい場合は、SITE PORTの完成例と編集デモを起点に検討できます。独自ドメインの接続や移行支援がどこまで含まれるかは、デモの見た目から判断せず、申込前に確認してください。

SITE PORTの完成例と編集デモを見ながら、普段の更新を自分で進められるか確認できます。契約前には、この記事で扱う設定を誰が担当するか、どの範囲まで対応するかを確認してください。

次に確認したいこと

[DNSレコードの種類](/articles/dns-record-types-practical)・[更新が反映されない場合](/articles/website-update-not-visible)・[HTTPSの警告](/articles/https-certificate-warning-check)