DNSのTTL（Time To Live）とは、DNSの回答をリゾルバーなどがキャッシュとして再利用できる期間を秒単位で示す設定値です。例えば TTL 300 は5分、TTL 3600 は1時間に相当します。短いTTLは接続先の変更を比較的早く反映させやすくしますが、問い合わせ回数が増えやすくなります。長いTTLはキャッシュの再利用を増やせますが、変更前の古い情報が残る時間も長くなります。
特にサイト移転やメールサービス切替では、DNSレコードを書き換える直前にTTLを短くしても、すでにリゾルバーに保存された古いTTLはすぐには短くならないことが重要です。変更を計画する際は、もともとのTTLが十分に経過する時間を確保し、切替後にどの情報がいつまで残り得るかを考える必要があります。
この記事ではTTLの読み方、60秒・300秒・600秒・3600秒・86400秒などの値の違い、短くする場面と長くする場面、切替前後の時系列に限定して解説します。DNS自体の仕組みはDNSの基礎記事、A・AAAA・CNAME・MX・TXTの種類はDNSレコード比較記事、権威DNSとリゾルバーの違いはネームサーバーの記事を参照してください。変更後に反映されない原因の診断・復旧操作は別記事に分離します。
DNSのTTLとは？キャッシュの保持時間を指定する値
TTLはDNSレコードの情報をキャッシュとして再利用できる期間を示します。まず「何の時間なのか」「どこで時間が進むのか」を理解すると、管理画面に表示される数字の意味が分かります。
TTLはTime To Liveの略で単位は秒
DNSのTTLは Time To Live の略です。一般的なDNS管理画面では 300、3600、86400 のような整数で表示され、単位は秒です。300 秒は5分、3600 秒は60分、86400 秒は24時間に相当します。
IETFのRFC 1035ではDNSレコードのTTLを、リゾルバーが回答をキャッシュできる時間として定義しています。現在の標準にはRFC 8767による補足もあるため、「TTLを過ぎた回答は例外なく必ず破棄される」とまでは言い切れません。
権威DNSとリゾルバーでTTLの見え方が違う
権威DNSはDNSゾーンに設定されたレコードとTTLを提供します。利用者が問い合わせる再帰リゾルバーは、その回答を受け取ると、設定されたTTLの範囲で一時保存できます。
例えば権威DNSが TTL 3600 の情報を返し、リゾルバーがそれを保存して30分後に回答する場合、リゾルバーが返す残りTTLは1800秒程度になることがあります。DNS管理画面のTTLが変わったわけではなく、キャッシュ側で保持時間が減っているためです。
TTLはWebページの保存期限やサーバーの稼働時間ではない
TTLはDNSの回答に付く値です。ブラウザがHTMLや画像を保存するHTTPキャッシュの期限、ログイン状態の有効期間、ドメイン契約の更新期限、SSL証明書の有効期限とは別のものです。
DNSのTTLを短くしても、Webサーバーのプログラムが速くなるわけではありません。またSSL証明書の期限も延長されません。異なる機能の「期限」「キャッシュ」を一つの設定で制御できるとは考えないようにします。
TTLの値を一覧で比較。60秒・300秒・3600秒・86400秒
TTLは数値が変わると、キャッシュを再利用できる時間の長さが変わります。代表的な値を秒・分・時間に換算し、運用上の特徴を比較しましょう。
代表的なTTLの秒数とキャッシュ期間の比較表
次の表は指定値を時間に換算したものです。どの値も「必ずその時間ちょうどで全端末が切り替わる」という保証ではありません。DNS事業者によって選べる値の範囲が異なる点にも注意してください。
| TTL設定値 | 時間換算 | 管理上の特徴 | 考え方の例 |
|---|---|---|---|
60 |
1分 | 非常に短いキャッシュ期間 | 短時間の切替を計画するときの候補 |
300 |
5分 | 比較的短く、変更に備えやすい | 切替前の一時的な短縮例 |
600 |
10分 | 短めの保持と問い合わせ数の折衷 | 変更の可能性があるレコード |
1800 |
30分 | 中間的な保持期間 | 通常運用で検討する候補 |
3600 |
1時間 | 一定時間キャッシュを再利用 | 安定したレコードの運用例 |
14400 |
4時間 | 切替前の古い情報も長く残り得る | 変更頻度の低いレコード |
86400 |
24時間 | 変更前に長めの準備期間が必要 | 長期に安定した管理対象 |
上記の「考え方」は比較のための運用例です。すべてのDNSに共通する推奨値やエンリンクの初期設定ではありません。実際の選択はホスティング・DNS事業者の制約と切替の必要性を合わせて判断してください。
TTL 300は5分だが、反映完了の保証時間ではない
TTLが300秒なら、TTLを尊重するリゾルバーは通常、取得した回答を最大5分程度キャッシュできます。しかし「変更して5分後には全利用者が必ず新しい接続先になる」とは言えません。
理由は、古いTTLで保存済みの回答、権威DNS側の情報の配布、ブラウザやOSのキャッシュ、リゾルバーの個別動作などが関係するためです。CloudflareやGoogle Cloudの公式資料も、TTLと実際の切替時間が一致するとは限らないと説明しています。
短いTTLほど常に優れているわけではない
TTLを60秒などに設定すると、回答の再利用時間は短くなります。その分、同じ名前への問い合わせが権威DNSや関連するリゾルバーへ届く機会が増える可能性があります。DNS事業者の仕様や料金、想定トラフィックを確認せず、すべてのレコードを最短値にすることは推奨できません。
一方で変更の多い接続先や、計画的な切替を行うレコードは短いTTLが適している場面もあります。短期の変更と平常運用を分けて考えることが重要です。
DNSのTTLはどのようにカウントされる？
TTLの時間を理解するため、キャッシュを取得した時点からの経過を考えます。同じレコードでも、別のDNSリゾルバーが異なる時刻に取得していれば、残りTTLが異なる場合があります。
リゾルバーが回答を取得した時点から残り時間が減る
例として、あるリゾルバーが12時00分に TTL 300 のAレコードを初めて取得したとします。一般的なキャッシュ動作では、12時02分には残り約180秒、12時04分には残り約60秒となり、期限到達後に新しい問い合わせが必要になれば権威DNSなどから再取得します。
これは説明用の理想化した例です。リゾルバーは実際には内部の最小・最大TTL、先読み、キャッシュ削除、フェイルオーバーなどの仕組みを持つ場合があります。
利用者ごとに見える内容が違う理由
リゾルバーAが12時00分にレコードを取得し、リゾルバーBが12時03分に同じレコードを取得した場合、12時04分時点の残りTTLはAとBで異なります。両方とも適切にキャッシュしていても、保存開始時刻が違うからです。
そのため、ドメイン管理者が一度設定を変更しただけで、世界中の全リゾルバーが同じ瞬間に新しい回答へ切り替わることは、DNSのTTLだけからは保証できません。
TTLが0ならキャッシュされないが即時切替保証ではない
標準では TTL 0 はその処理中だけ利用し、通常のキャッシュへ保存しないことを意味します。ただしDNS事業者がTTL 0を許可するとは限りません。端末やアプリの独自キャッシュ、ネットワーク経路などが残るため、設定できたとしても「全利用者に即時反映される」とは言えません。
通常はDNSサービスが提供する現実的な設定値を選び、変更時刻と切替後の確認を別に計画する方が適切です。
TTLを短くする場合と長くする場合の判断基準
TTLに唯一の正解はありません。レコードを変更する予定があるか、キャッシュの再利用による効率を重視するか、DNSサービスがどの値を許可するかで判断します。
TTLを短くするのは予定された変更があるとき
Webサーバーの移転、CDNの導入、メールサービス切替など、接続先を変える予定があるときは、対象レコードのTTLを一時的に短くする運用が検討できます。切替後に古いDNS回答が残る期間を短くするためです。
ただし、切替対象がAだけでなくAAAA、CNAME、MXなどにまたがる場合、どのレコードに変更が必要かを確認します。レコード種類の用途はDNSレコードの種類と役割で説明しています。
長いTTLは安定したレコードのキャッシュに向く
長期間変更しないレコードでは、キャッシュを長めに保持することで権威DNSなどへの問い合わせを減らせる可能性があります。DNSリゾルバーもキャッシュを使って効率的に回答できます。
一方で予期せず接続先を変更する必要が生じると、古い値が長く残り得ます。運用の安定性と変更への柔軟性はトレードオフです。
DNS事業者の最小・最大TTLと自動設定に従う
DNS管理画面で指定できるTTLは、サービスによって異なります。Cloudflareの公式資料では、2026年10月確認時点で、プロキシ有効のレコードは Auto（300秒）で変更できず、DNS-onlyではプランに応じて選択可能な範囲が定められています。
したがって、あるDNS事業者で設定できた60秒が、別の事業者でも設定できるとは限りません。Auto も普遍的に300秒を意味するDNS規格ではなく、事業者固有の取り扱いです。管理画面の説明を確認して判断します。
高頻度の切替をTTLだけで実現しようとしない
障害時に自動で別サーバーへ接続させたい場合、TTLを短くすれば必ず短時間で切り替わるという設計は危険です。リゾルバーの動作、利用者の接続、別経路、サーバー側の負荷分散などが関係します。
DNSは名前解決の仕組みであり、サービスが正常に応答するかを確認する仕組みではありません。HTTP監視などの基本は死活監視の解説で扱っています。
DNS変更前にTTLを短くする理由
DNSの切替計画で最も間違えやすいのは、変更の直前にTTLを下げれば、それまでに保存されたキャッシュもすぐ短くなると思ってしまうことです。実際には古い情報は、取得時のTTLに従って残る可能性があります。
すでにキャッシュされた古いTTLは後から書き換わらない
例えば元のTTLが86400秒（24時間）で、切替直前に300秒へ変更した場合、前日から古い回答を保持しているリゾルバーが存在する可能性があります。権威DNSのTTLを300秒に変更しても、各リゾルバーに残る古いキャッシュを一斉に短縮する信号にはなりません。
この点はGoogle Cloud DNSの公式資料にも記載されています。短くした新しいTTLが利用されるのは、以前のTTLが期限切れになり、リゾルバーが更新後の情報を取得した後です。
目安は変更前のTTLを把握してから準備時間を取る
切替前の準備期間を決めるには、対象レコードの現在のTTLを確認することが先です。例えばTTLが1時間なら、1時間を上回る準備期間を置くという考え方ができます。24時間なら、短縮前のキャッシュが残らないよう少なくともその時間を考慮します。
ただし、権威DNS側の更新の配布時間や、リゾルバー・端末の独自動作も関係します。そのため「元TTLと同じ時間を待てば全利用者について必ず完了」と保証するものではありません。実務では余裕を持って準備し、旧接続先も必要な期間維持します。
Cloudflareは切替の24～48時間前などの準備を例示
CloudflareはDNS切替の準備ガイドで、重要なDNSレコードのTTLを切替の24～48時間前、元のTTLがそれより長ければさらに前から短縮する運用を紹介しています。これはDNS移行を計画する際の事業者による実務例であり、すべてのドメインに24～48時間の待機が法令・規格上義務付けられているという意味ではありません。
実際の計画では、対象のTTL、DNS事業者が設定変更を反映する時間、切替先サービスの準備、旧サービスを維持できる時間を合わせて決めます。
TTL 3600秒から300秒へ下げる切替時系列の例
具体的な例で確認します。元のAレコードのTTLを3600秒（1時間）、切替前に設定するTTLを300秒（5分）とし、12時に接続先IPアドレスを変更する想定です。実際の利用環境にある値ではなく、動きを理解するための模式例です。
午前10時にTTLを300秒へ変更する
朝10時の時点では旧接続先 192.0.2.10 のまま、TTLだけを3600秒から300秒へ短縮します。もともと3600秒でキャッシュされていたリゾルバーが、順次更新後のTTLを受け取れるようにするためです。
この例では、準備時間を2時間としており、元の3600秒より長く取っています。切替前の旧IPはそのまま維持し、TTLの値だけを先に変える点が重要です。
午前11時までに旧TTLのキャッシュが順次期限を迎える
通常のキャッシュ動作を仮定すると、10時以前に保存された3600秒の回答は、最も遅くても10時から約1時間後までに期限を迎えます。その後、新たに回答を取得したリゾルバーは、TTL 300秒の旧IP情報を保存することがあります。
ただしこれは各リゾルバーがTTLを標準的に扱い、元の回答取得や権威DNSの配布が想定どおりである場合の説明です。TTLの下限処理、端末の独自キャッシュや例外的な古い回答の提供などを含めた、全利用者の保証ではありません。
正午にIPアドレスを切り替える
12時になったら、Aレコードの値を説明用の新しいIP 192.0.2.20 へ変更します。この時点で一部のリゾルバーには、最大300秒程度の旧IPのキャッシュが残り得ます。TTLを下げた効果は、元の3600秒のキャッシュではなく、切替前に再取得された300秒のキャッシュになっている点です。
旧IPアドレスのサーバーを12時ちょうどに停止すると、まだ旧情報を利用する接続が失敗する可能性があります。切替計画では、旧環境の停止時刻を別に決める必要があります。
12時05分以降も完全切替を保証するわけではない
標準的なTTLの取り扱いでは、12時直前に保存された300秒の旧回答はおおむね5分で期限を迎えます。ただし、権威DNS側の配布やリゾルバー固有のキャッシュ、ブラウザの継続接続、例外的な古い回答などによって、見える結果には差が生じ得ます。
したがって「12時05分で必ず全員切替完了」という運用上の保証にはせず、旧接続先の維持、確認体制、切り戻し条件を整えておきます。次の図解は通常のキャッシュの概念を理解するための時系列です。
TTLを短くしたのに古い情報が残るケースを整理
TTLを短くする目的は、切替後の古い情報が残り得る時間を小さくすることです。しかし実際のDNSキャッシュには例外や別の条件があるため、「TTLだけですべてを制御できる」と考えないようにしましょう。
リゾルバーによってTTLの上限・下限が異なることがある
RFC 2181ではTTLが最大保持期間であり、必ずその長さだけ保持しなければならない時間ではないと説明されています。実際のリゾルバーには、長すぎるTTLや短すぎるTTLに独自の制限を適用する実装があります。
そのため設定値が同じでも、異なるリゾルバーでキャッシュの扱いが一律であるとは限りません。TTLを設定する側と、回答を保存して使う側が別の管理主体であることを押さえてください。
権威DNSへの反映とキャッシュの期限は別工程
DNS事業者の管理画面でレコードを保存したあと、権威DNSサーバー側へその内容が配布されるまでの時間があります。さらに、リゾルバーが以前の回答を保存していれば、そのTTLが期限を迎えるまで古い情報を返す可能性があります。
Google Cloud DNSの公式資料は、変更を「権威DNS側への配布」と「リゾルバーのキャッシュ更新」という二つの段階で整理しています。権威DNSの変更が完了した時点と、利用者から新しい接続先が見える時点は区別して考えましょう。
ブラウザやアプリのキャッシュ・接続は別に残る場合がある
OS、ブラウザ、アプリケーションは、DNSリゾルバーとは別に名前解決結果を保持したり、すでに確立したネットワーク接続を継続したりする場合があります。DNSのTTLだけで、それらのすべてを強制的に切り替えることはできません。
実際の調査では、リゾルバーの回答、端末側の状態、接続先のWebサービスを分けて確認する必要があります。詳しい「DNS変更後に反映されない原因」の診断は別記事に分離します。
例外的に期限切れのキャッシュを利用する仕組みもある
RFC 8767では、権威DNSへ再問い合わせできない場合などに古いキャッシュを一時的に利用する serve-stale が説明されています。これはDNSサービスの耐障害性を高めるための例外的な動作です。
そのため「TTLが切れれば、あらゆる状況で古い情報は存在しなくなる」という説明は正確ではありません。ただしすべてのリゾルバーが常に古い情報を使うわけでもなく、通常時に意図的に切替を遅延させるという意味でもありません。
A・AAAA・CNAME・MX・TXTとTTLの関係
TTLはAレコードだけの仕組みではありません。DNSレコードの種類ごとに関連付けられるため、Webサイトやメール、外部サービスの管理でも役割が変わります。ここではTTLがどの情報に付くのかを把握します。
A・AAAAでは接続先IPアドレスのキャッシュに関わる
AはIPv4、AAAAはIPv6アドレスの情報です。サイト移転でIPアドレスを変える場合、これらのレコードのTTLがリゾルバーのキャッシュ保持期間に関係します。IPv4だけ短くし、IPv6側の古い接続先を見落とすことがないよう、変更対象を整理します。
ただし実際にサイトへ接続できるかは、IPアドレス先のサーバー稼働やネットワーク条件にも左右されます。DNSレコードのTTLとWebサイトの正常性は別の確認項目です。
CNAMEでは別名とその先のレコードのTTLを区別
CNAMEは別の名前を指すレコードです。名前解決ではCNAMEの回答と、その参照先のA・AAAAなどをたどる場合があり、それぞれ異なるTTLを持つことがあります。
例えばCNAMEを300秒にしていても、参照先のAレコードが3600秒なら、すべての関連情報が同じ300秒で再取得されるとは限りません。変更対象のDNS名と関係するレコードを分けて整理することが重要です。
MXではメール配送先の情報のキャッシュに関わる
MXは、そのドメイン宛てのメールをどこへ配送するかに関係するレコードです。メールサービスの切替時には、MXのTTLと、MXが指すメールサーバー名のアドレス情報などを考慮する必要があります。
MXの値を変えれば、その瞬間にすべての送信側メールサーバーが新しい配送先を使うと断定することはできません。DNSキャッシュに加えて、メール送信側の配送・再試行などの挙動も関係するため、移行手順はメールサービスの公式案内に従います。
TXTでは所有確認・メール認証情報のキャッシュに関わる
TXTはSPF・DKIM・DMARCなどのメール認証情報や、ドメイン所有確認の文字列を公開する用途があります。TXTレコードにもTTLが付くため、値の変更直後に以前の内容がキャッシュから返る場合があります。
ただしTXTの用途によって変更の影響は異なります。認証用の値を変更するときには、依頼元サービスの正式手順と現在の運用を確認してください。TTLの調整だけでは、値の誤りやサービス側の認証失敗を解決できません。
DNSの「存在しない」という回答にもキャッシュ期間がある
TTLの話は、存在するDNSレコードのキャッシュだけでは終わりません。存在しない名前や種類を問い合わせた場合の「該当情報なし」という結果にも、キャッシュの扱いがあります。
NXDOMAINやNODATAはネガティブキャッシュの対象
名前が存在しないという NXDOMAIN や、名前は存在するが問い合わせた種類のデータがない場合の NODATA は、DNSの「否定的な回答」です。RFC 2308では、これらをキャッシュする仕組みを定義しています。
例えば新しいサブドメインを作成する前に一部のリゾルバーが「存在しない」という回答を受け取り、保持していた場合、後からレコードを追加しても一時的に古い否定的な回答が利用される可能性があります。
否定的な回答の保持時間は通常のAレコードTTLと別
ネガティブキャッシュのTTLは、DNSゾーンのSOAレコードなどの情報に基づき計算されます。RFC 2308では、SOAのMINIMUMフィールドとSOA自身のTTLの小さい方が否定的な回答のTTLとして使われます。
したがって、Aレコードを300秒にしたからといって、存在しない名前への回答のキャッシュも必ず300秒になるとは限りません。今回の記事ではTTLの種類が異なる点を説明するにとどめ、NXDOMAINなどの具体的な障害診断は別記事で扱います。
新規ドメイン・サブドメインの公開計画で注意する
事前に存在しないホスト名への確認が行われている場合、否定的な回答のキャッシュが切替の見え方へ影響することがあります。新規のホスト名を公開するときは、レコードを追加した後の権威DNS側の情報と、利用者側の結果を区別して考えましょう。
またネームサーバーの委任情報のTTLはAレコードのTTLと同じではありません。ネームサーバーを変更する計画ではネームサーバーの役割も理解したうえで、管理対象を確認してください。
DNS管理画面でTTLを確認するときの注意点
DNSレコードのTTLは管理画面やDNSコマンドで確認できます。ただし、権威DNSの設定値と、リゾルバーが返す「残りTTL」を混同しないことが重要です。変更操作ではなく、読み取りと値の解釈に絞って説明します。
管理画面の「TTL」「キャッシュ時間」「Auto」は意味を確認
DNS管理画面には、レコードの名前、種類、値、TTLが並ぶことがあります。表示が 300 なら通常は秒数、Auto ならDNS事業者が定める値を適用する方式です。入力可能な範囲と単位は画面の説明で確認します。
Autoの時間はDNS規格で統一されていません。例えばCloudflareでは対象となるレコードのAutoが300秒ですが、別の事業者で同じ表示があっても同じ時間とは限りません。必ず利用中サービスの案内を確認してください。
digで返るTTLはキャッシュの残り時間の場合がある
macOS・Linuxなど dig を利用できる環境では、次のコマンドでDNSの回答に含まれるTTLを確認できます。これはレコードの参照だけを行い、DNS設定を変更しません。example.com は説明用のドメインです。
dig example.com A +noall +answer次は出力形式を説明するための架空の出力例です。192.0.2.10 は文書用の予約アドレスであり、現在の example.com の実際の回答ではありません。
example.com. 300 IN A 192.0.2.10左から名前、TTL、クラス、種類、値が示されています。通常の dig はリゾルバーを通して問い合わせるため、TTLの欄には設定した元の秒数ではなく、すでに減った残り時間が表示される場合があります。権威DNSの設定値を知りたいときはDNS管理画面で確認する方が明確です。
Windows PowerShellでもDNSの応答を確認できる
WindowsでDNSClientモジュールが利用できる環境では、PowerShellの Resolve-DnsName でDNSレコードを問い合わせられます。次のコマンドは対象のAレコードを読み取る例です。
Resolve-DnsName -Name example.com -Type A出力の TTL 項目や取得したアドレスを確認します。表示形式は環境によって異なり、これもリゾルバーのキャッシュの残り時間を示す場合があります。変更値を決めるための参考情報として扱い、管理画面の設定と区別してください。
変更後の診断に必要なコマンドは別記事で説明する
この記事のコマンドはTTLの意味を読むための例です。リゾルバーごとの結果を詳しく比べる手順や、TTLを短くしたのに旧IPが残る場合の診断、キャッシュ削除、ネームサーバー委任の検証は、変更後の反映確認を扱う個別記事に分けます。
「DNSのTTLが何を意味するか」と「変更が反映されない原因を突き止める手順」を同一記事に混ぜず、必要な場面に合わせて参照してください。
サイト移転時にTTL以外で準備すること
DNSの切替でTTLを短くすることは重要ですが、DNS情報が変わった後に正しいサービスを提供できることも必要です。具体的な変更手順や復旧ではなく、移転の準備として確認したい運用項目を整理します。
旧サーバーをすぐ停止しない運用を検討する
切替時刻を過ぎても旧IPアドレスのキャッシュを使う利用者がいる可能性があります。そのため、新しいWebサーバーへの切替直後に旧サーバーを停止せず、必要な期間を維持する計画が必要になる場合があります。
旧環境と新環境でデータを書き込むサービスは、更新の不整合を防ぐ設計も必要です。DNSのTTLを調整するだけでは、データベースの同期やユーザー操作の整合性を保証できません。
HTTPS証明書とサービスの動作も準備する
新しい接続先にDNSを切り替えても、TLS証明書がドメイン名に対応していなければブラウザに警告が出る場合があります。新環境に適切な証明書が用意されているかを切替計画に含めます。
証明書の基礎はSSL証明書とHTTPSの解説、期限切れの確認・対応はSSLカテゴリーの各記事で取り上げています。
担当者・作業時刻・元に戻す判断を決めておく
DNSの変更はWebサイトやメールなどのサービスへ影響する場合があります。変更対象の名前、元のレコード値、元のTTL、新しい値、作業者、確認者、旧環境の維持期間を記録しておきます。
想定と異なる状態になったときに誰が判断するか、変更を元に戻す場合の影響を誰が確認するかも決めましょう。ただし元の値へ戻したとしても、その変更自体にDNSキャッシュの時間が関係するため、即座に全利用者が戻るとは限りません。
DNS TTLの設定を考えるときのチェックリスト
TTLの値を決める前に、対象レコードと変更予定、古いキャッシュが残る可能性を確認します。サイト移転やサービス切替の計画では、設定した数字だけでなく担当者や維持する旧環境も併せて管理すると判断しやすくなります。
- 対象ドメインとレコードの種類（A・AAAA・CNAME・MX・TXTなど）を特定したか。
- 現在のTTLを秒単位で確認したか。
- 設定値が権威DNSのTTLか、リゾルバーの残りTTLか区別したか。
- DNS事業者が許可する最小・最大TTLとAutoの仕様を確認したか。
- 変更後も古いTTLがキャッシュに残ることを考慮したか。
- 短縮してからの準備時間が元のTTLより短すぎないか。
- 変更対象のA・AAAAだけでなく、必要なCNAME・MXなども整理したか。
- 変更先のWeb・メールサービスを事前に準備したか。
- 旧環境を切替直後に停止しない計画を検討したか。
- 権威DNS側への反映とリゾルバー側の更新を別工程で考えたか。
- 想定外の遅延や一部利用者だけの旧回答を想定したか。
- 関係する担当者と変更前の記録を残したか。
短縮前に、元のTTLを確認することから始める
最初に現在の設定値を把握しないと、いつ短くするのが適切か判断できません。元のTTLが300秒のレコードと86400秒のレコードでは、必要な準備期間の考え方が異なります。
TTLを短くしてからIPアドレスを切り替えるまでの時間を確保し、変更後も利用者の接続が一斉には切り替わらない可能性を考えます。
平常運用へ戻すタイミングも計画する
一時的にTTLを短縮した場合、切替後に元の長さへ戻すことを検討できます。ただし、今後も接続先の変更が頻繁に予想されるなら、短い値を維持する運用が適することもあります。
長いTTLへ戻すと、その後の変更が必要になったときに準備期間も長くなり得ます。次の変更予定があるか、キャッシュ効率をどの程度重視するかを確認して決めてください。
エンリンクでドメイン管理と監視を整理する場合
DNSのTTLが分かっても、複数サイトの契約先・DNS管理先・監視状況が分散していると、変更時の担当者を探すのが難しい場合があります。エンリンクの現在公開されている機能でできることと、TTLの変更作業を区別します。
ドメイン管理会社と管理画面の場所を整理できる
エンリンクの機能一覧には、登録サイトのドメイン管理会社や管理画面URLを記録して整理できることが案内されています。複数サイトのDNS管理先を把握する際の参考になります。
ただし、DNSレコードのTTLをエンリンクから一括変更する機能が提供されているとは、現在の公開機能一覧では確認できません。TTLの変更には、利用中のDNS事業者の正式な管理手段が必要です。
HTTP・SSL監視はDNSキャッシュとは別の確認
エンリンクではHTTP/HTTPSの定期監視、SSL証明書の期限確認、DNS診断・セキュリティ確認などが機能一覧に記載されています。これらはWebサイトの運用状況を把握するための機能ですが、世界中のDNSリゾルバーのキャッシュがすべて切り替わったことを保証するものではありません。
「TTLを300秒へ変更した」と「サイトが正常に応答している」と「利用者のDNSキャッシュが更新された」は別々の確認事項です。DNSの切替計画ではそれぞれの責任範囲を区別してください。
無料プランは最大5サイトで定期監視1日2回
2026年10月26日時点の料金プランには、無料プランが最大5サイトまで登録でき、定期監視は1日2回と記載されています。DNSキャッシュのTTLを制御する頻度や即時検知を保証する条件ではありません。
複数のWebサイトの管理情報を整理し、監視を始めたい場合は無料アカウント登録から利用できます。DNSレコードの変更・移転操作とは別の役割であることをご確認ください。
DNSのTTLについてよくある質問
TTLの値を初めて見る方や、切替計画を考えている方が迷いやすい点をまとめます。具体的な変更後トラブルの診断や復旧操作は別記事として扱うため、ここではTTLの意味と設定判断に絞ります。
Q．DNSのTTL 300は何分ですか？
300秒なので5分です。リゾルバーがその回答を再利用できる期間の目安を示します。ただし、管理画面でTTLを300へ変更してから5分で、すべての利用者が必ず新しいDNS情報を使うという保証ではありません。
Q．TTL 3600は何時間ですか？
3600秒なので1時間です。24時間は86400秒、30分は1800秒に相当します。秒数を時間に換算して確認すると、切替前の準備期間も考えやすくなります。
Q．TTLは短い方がよいですか？
変更が予定されている場合は短いTTLが役立つことがありますが、短いほどDNS問い合わせが増えやすくなるため、すべてのレコードで最短値が最適とは限りません。DNS事業者の設定範囲、変更予定、運用上の負担から判断してください。
Q．TTLを300秒にすると5分後に全員切り替わりますか？
いいえ。変更前の長いTTLで保存済みのキャッシュ、権威DNSへの変更配布、OSやブラウザの状態などが関係します。TTL 300はキャッシュ保持時間の設定であり、利用者ごとの切替完了時刻を保証するものではありません。
Q．TTLを変更した直後に、古いキャッシュのTTLも変わりますか？
通常は変わりません。以前のTTLで保存されたキャッシュは、その保存時の条件に従って残る可能性があります。予定した切替より前にTTLだけを短くしておく理由はここにあります。
Q．DNSのTTLとブラウザキャッシュの有効期限は同じですか？
異なります。DNS TTLは名前解決の回答、HTTPキャッシュはHTML・画像などのリソースを保持する時間に関係します。DNSのTTLを変更しても、Webサイトの画像キャッシュやアプリケーションの保存状態まで一括変更できません。
Q．TTLを0にすると即時反映されますか？
いいえ。TTL 0は標準上キャッシュを保持しない扱いですが、事業者が設定を許可するとは限らず、端末・アプリケーションや独自のリゾルバーの動作まで制御できません。即時反映を保証する方法とは考えないでください。
Q．CNAMEとAレコードに異なるTTLを設定できますか？
別の名前や種類のレコードであれば、それぞれ異なるTTLが設定される構成があります。名前解決では複数のレコードを参照する場合があるため、CNAMEだけ短くすれば関連するすべての情報が同時に更新されるわけではありません。
Q．MXレコードのTTLはWebサイトの表示に影響しますか？
MXのTTLは主にメール配送先のDNS情報に関係します。Webサイトへの接続で通常使うA・AAAAやCNAMEとは用途が異なります。ただし複数サービスの切替が同時にある場合、どのレコードを変更するか整理する必要があります。
Q．ネームサーバー変更の反映時間もAレコードのTTLと同じですか？
必ずしも同じではありません。ネームサーバー委任に関わるNSや関連する情報は、それぞれTTLやキャッシュを持ちます。Aレコードだけを短くしても、委任先変更を同じ時間で切り替えられるとは限りません。
Q．設定を短くしたのに古いIPが残る場合、どうすればよいですか？
古いIPが残る原因の診断は、キャッシュの残り時間、権威DNSの回答、問い合わせ先の違いなどを分けて確認する必要があります。本記事はTTLの設定判断までに限定し、変更後の反映問題を調べる詳細な手順は個別の記事で扱います。
まとめ：TTLは「変更時の反映速度」と「キャッシュ効率」の調整値
DNSのTTLは、リゾルバーなどがDNSの回答をキャッシュとして再利用できる時間を秒単位で示す値です。300秒なら5分、3600秒なら1時間、86400秒なら24時間です。短いTTLは接続先を変更する場合に使いやすい一方、問い合わせが増える可能性があります。長いTTLはキャッシュの再利用に有利ですが、切替時に古い情報が残る時間も長くなり得ます。
特にDNS切替の直前にTTLだけ短くしても、すでに古いTTLで保存されたキャッシュが即座に消えるわけではありません。元のTTLを確認し、切替前に短縮して十分な準備期間を取り、旧環境の維持や確認体制も計画することが重要です。TTLは全利用者の切替時刻を保証する値ではないため、実際の運用ではDNS事業者と利用サービスの条件に基づいて判断してください。
DNSの全体像はDNSとは？、レコードの種類はDNSレコードの比較、ネームサーバーと委任の役割はネームサーバーの基礎で説明しています。複数サイトの管理先や稼働状況を整理したい方は、エンリンクの機能一覧と料金プランをご覧いただき、無料登録から利用を開始できます。
参考資料と確認日
本文のTTL・キャッシュ・切替準備・ネガティブキャッシュなどの技術的説明は、以下の標準文書と事業者公式資料に基づいています（確認日：2026年10月26日）。時系列図と比較表の秒数・IPアドレス・時刻は説明用の例であり、個々の環境に対する反映保証ではありません。
- IETF RFC 1035：Domain Names — Implementation and Specification — DNSレコードのTTLの基本定義。
- IETF RFC 2181：Clarifications to the DNS Specification — TTLは最大保持期間であり強制的な保持期間ではないこと。
- IETF RFC 2308：Negative Caching of DNS Queries — NXDOMAIN・NODATAなど否定的な回答のキャッシュ。
- IETF RFC 8767：Serving Stale Data to Improve DNS Resiliency — 例外的な古いDNS情報の提供。
- Google Cloud DNS：Overview — 権威DNSの変更配布とTTLキャッシュの更新、切替前にTTLを下げる考え方。
- Cloudflare DNS：Time to Live（TTL） — 設定範囲、Auto、プロキシ有効時のTTL。
- Cloudflare DNS Best Practices：Phase 2 Preparation — 切替前のTTL短縮の実務例。
