TTLとは？300秒・3600秒・86400秒の違いとおすすめの設定値

DNSの設定画面を開くと、AレコードやCNAMEレコードなどの入力欄の横に、「TTL」という項目があります。初期値として「300」「3600」「86400」といった数字が入っていることが多く、「これは何の数字なのか」「どれを選べばいいのか」と迷った経験がある方も多いのではないでしょうか。

TTLは、DNSの反映スピードや、サーバーへの負荷、サイトの安定性にも関わる大切な設定です。この記事では、TTLの基本的な意味から、300秒・3600秒・86400秒それぞれの違い、場面ごとのおすすめの設定値、変更方法、確認方法までを、初心者の方にもわかりやすく解説します。

TTLとは

TTL（Time To Live）とは、DNSの応答を、キャッシュサーバーが保存してよい時間の長さを表す設定値です。単位は「秒」で、DNSレコードごとに指定します。

DNSでは、一度調べたドメインの情報（IPアドレスなど）を、キャッシュサーバーが一定時間だけ手元に保存しておく仕組みがあります。同じ問い合わせが来たときに、毎回権威DNSサーバーまで確認しに行かなくて済むため、高速で効率的な動作が可能になります。

TTLは、その「保存してよい時間」を、ドメインの管理者が指定するための項目です。たとえばTTLが3600なら、「この情報は3600秒（1時間）は使い回してかまいません」という意味になります。

牛乳パックの「賞味期限」にたとえるとわかりやすいでしょう。TTLは、DNSの情報に付けられた賞味期限であり、期限が切れると、キャッシュサーバーは新しい情報を取りに行きます。

TTLの仕組み

TTLがどのように働くのか、具体例で見てみましょう。

1. ドメイン「example.com」のAレコードが、TTL 3600で登録されている
2. ユーザーの利用するキャッシュサーバーが、権威DNSサーバーから、Aレコードの情報を取得する
3. キャッシュサーバーは、その情報を保存し、TTLのカウントダウンを開始する（3600、3599、3598…）
4. カウントダウンの間に、同じドメインへの問い合わせがあれば、権威DNSサーバーに確認せず、保存した情報を返す
5. TTLが0になると、保存した情報を破棄する。次に問い合わせがあったときに、再び権威DNSサーバーから、最新の情報を取得する

この仕組みのため、DNSレコードを変更しても、キャッシュサーバーが古い情報を保存している間は、変更が反映されません。TTLの長さが、ほぼそのまま「反映に必要な最大の待ち時間」になります。

TTLの秒数の早見表

TTLは秒で指定するため、数字だけを見ても、どのくらいの長さなのかピンと来ないかもしれません。よく使われる値を、時間に換算して整理します。

TTL（秒）	時間	よく使われる場面
60	1分	頻繁に切り替える必要がある場合
300	5分	サーバー移転前後、変更が多い時期
1800	30分	比較的変更の可能性がある場合
3600	1時間	一般的な初期値として多い
14400	4時間	やや安定したレコード
86400	24時間（1日）	ほとんど変更しない安定したレコード

300秒・3600秒・86400秒の違い

TTL 300（5分）

TTLを300秒に設定すると、キャッシュの保存時間は最大5分になります。

メリット

• レコードを変更したとき、最短では5分程度で、新しい情報に切り替わる
• サーバー移転や、障害時の切り替えを、素早く行える

デメリット

• キャッシュが頻繁に期限切れになるため、権威DNSサーバーへの問い合わせが増える
• 問い合わせが増える分、名前解決に時間がかかる機会が増え、DNSサービスによっては、問い合わせ回数に応じた料金が増えることもある
• 権威DNSサーバーが一時的に停止した場合、キャッシュが早く切れるため、影響を受けやすい

向いている場面

• サーバーの移転や、DNSサービスの切り替えを予定している時期
• IPアドレスを頻繁に変更する必要がある場合
• 障害発生時に、素早く別のサーバーへ切り替えたい場合

TTL 3600（1時間）

TTLを3600秒に設定すると、キャッシュの保存時間は最大1時間になります。多くのDNSサービスで、初期値として採用されている、バランスのよい値です。

メリット

• 変更の反映が、最大でも1時間程度で済み、実用上の不便が少ない
• キャッシュが十分に働くため、問い合わせの数が抑えられ、負荷も軽くなる

デメリット

• 急な変更や、緊急の切り替えが必要な場合には、反映までに時間がかかる

向いている場面

• 通常の運用時（特に変更の予定がない期間）のAレコードやCNAMEレコード
• 「どの値にすべきか迷ったら、まず3600」という、標準的な選択肢

TTL 86400（24時間）

TTLを86400秒に設定すると、キャッシュの保存時間は最大24時間、つまり1日になります。

メリット

• キャッシュが長く保持されるため、DNSへの問い合わせが大幅に減り、負荷や費用を抑えられる
• 権威DNSサーバーが一時的に停止しても、キャッシュが残っている間は、名前解決を継続できる可能性が高い

デメリット

• レコードを変更しても、最大で丸1日、古い情報が使われ続ける可能性がある
• 移転や緊急対応が必要になったときに、対応が遅れる

向いている場面

• ほとんど変更しない、安定したレコード（NSレコードや、変更予定のないMX・TXTレコードなど）
• 変更の予定がなく、負荷や費用を抑えたい場合

3つの値の比較

項目	300（5分）	3600（1時間）	86400（24時間）
変更の反映	速い	標準	遅い
DNSへの問い合わせ数	多い	標準	少ない
障害時の切り替え	素早い	標準	遅い
DNS障害への耐性	低め	標準	高め
主な用途	移転・切り替え時	通常運用	安定したレコード

場面別のおすすめTTL

どの値が正解というものではなく、レコードの用途や、変更の頻度に応じて選ぶのがポイントです。

場面	おすすめのTTL
サーバー移転や、DNS切り替えの直前・直後	300
通常運用中のウェブサイト（A・CNAME）	3600
メール関連（MX・SPFなどのTXT）	3600〜86400
ほとんど変更しない安定したレコード	86400
ロードバランサーや、障害時の切り替えを想定した構成	60〜300

なお、Cloudflareなど、一部のDNSサービスでは、TTLの設定に「自動（Auto）」という選択肢があります。この場合、サービス側が適切な値を設定してくれるため、特にこだわりがなければ、そのままで問題ありません。

サーバー移転時のTTLの変更手順

TTLの設定が特に重要になるのが、サーバー移転など、IPアドレスを変更する場面です。ここでのポイントは、IPアドレスを変える「前」に、TTLを下げておくことです。

1. 現在のTTLの値を確認する（たとえば86400）
2. 移転の予定日の、現在のTTLの時間以上前に、TTLを300程度まで下げる（86400なら、24時間以上前）
3. 元のTTLの時間が経過するまで待つ（この間に、世界中のキャッシュが、短いTTLの情報に入れ替わる）
4. 新しいサーバーの準備を整えたうえで、IPアドレス（Aレコードの値）を変更する
5. 変更後は、短いTTLのおかげで、数分程度で新しいサーバーに切り替わる
6. 切り替えが完了し、問題がないことを確認できたら、TTLを3600などの通常の値に戻す

TTLを下げるのを、IPアドレスの変更「後」に行っても、すでに世界中に保存されている古いキャッシュには影響しません。この順序を間違えると、TTLを短くした意味がなくなってしまうため、注意しましょう。

TTLの確認方法

現在設定されているTTLは、コマンドやWebツールで確認できます。

digコマンドで確認する

dig example.com A

実行結果の「ANSWER SECTION」に、次のような行が表示されます。

example.com.    3600    IN    A    192.0.2.1

ここで、2列目の「3600」がTTLです。

キャッシュ経由と権威DNSサーバー直接の違い

キャッシュサーバー経由で問い合わせた場合、表示されるTTLは、「設定値」ではなく「残りの時間」です。同じ問い合わせを繰り返すと、3600、3540、3480…と、数字が減っていくことがあります。

設定されている本来のTTLを知りたい場合は、権威DNSサーバーを指定して問い合わせます。

dig @ns1.example-dns.com example.com A

ドメインチェッカーなどのWebツールで確認する

ブラウザ上でドメイン名を入力するだけで、DNSレコードとそのTTLを確認できるWebツールもあります。コマンドに慣れていない方や、複数のレコードのTTLをまとめて確認したい場合に便利です。

ほかの「TTL」との違い

「TTL」という言葉は、DNS以外の場面でも使われるため、混同しないように注意が必要です。

種類	意味	単位
DNSのTTL	DNSの応答をキャッシュしてよい時間	秒
IPパケットのTTL	パケットが通過できるルーターの数の上限（pingなどで表示される）	回数（ホップ数）
CDNやHTTPのキャッシュ期間	Webコンテンツをキャッシュする時間（Cache-Controlなどで指定）	秒

pingコマンドの結果に表示される「TTL=64」などの値は、DNSのTTLとは別のものです。また、CDNのキャッシュ期間も、DNSのTTLとは独立した設定であり、DNSのTTLを変えても、CDN上のコンテンツのキャッシュ期間は変わりません。

よくあるトラブルと注意点

TTLを短くしたのに、反映が遅い

TTLを下げた後に、すぐレコードを変更しても、すでに世界中に保存されている古いキャッシュは、以前のTTLの時間が経過するまで残ります。TTLの変更は、必ず余裕を持って、変更予定の前に行いましょう。

TTLが、設定した値どおりに動かない

キャッシュサーバーの中には、独自のルールで、TTLの下限や上限を設けているものがあります。そのため、極端に短い値や、極端に長い値を設定しても、想定どおりの時間にならない場合があります。

TTLを短くしすぎて、費用や負荷が増えた

TTLを極端に短く（たとえば数十秒に）したまま運用すると、DNSへの問い合わせが大幅に増えます。問い合わせ回数に応じて課金されるDNSサービスを使っている場合は、費用が増える原因になります。必要な期間が終わったら、通常の値に戻すことを忘れないようにしましょう。

DNSサービスによって設定できる値の範囲が異なる

DNSサービスによっては、設定できるTTLの最小値や最大値が決まっています。希望の値が入力できない場合は、サービスの仕様を確認してください。

よくある質問

TTLの初期値は、そのままでも問題ありませんか？

はい、多くの場合は問題ありません。特に変更の予定がなければ、3600前後の初期値のままで、実用上の支障はほとんどありません。

TTLは、短いほうがよいのでしょうか？

いいえ、短ければ短いほどよいというわけではありません。短いTTLは、反映が速い反面、DNSへの問い合わせが増え、負荷や費用、名前解決の遅延につながることがあります。用途に合わせて、バランスよく設定することが大切です。

TTLの単位は何ですか？

秒です。300なら5分、3600なら1時間、86400なら24時間（1日）になります。

TTLはレコードごとに違う値にできますか？

はい、できます。A、CNAME、MX、TXTなど、レコードごとに、別々のTTLを設定できます。ただし、同じホスト名・同じタイプの複数のレコード（たとえば、複数のAレコード）は、通常、同じTTLに揃えるのが一般的です。

まとめ

TTLについて、要点を整理します。

• TTLは、DNSの応答をキャッシュサーバーが保存してよい時間を、秒で表した設定値である
• 300秒は5分、3600秒は1時間、86400秒は24時間（1日）である
• 短いTTLは変更が速く反映される反面、DNSへの問い合わせが増える
• 長いTTLは負荷を抑えられ、安定しやすい反面、変更の反映が遅くなる
• 通常運用時は3600前後、移転や切り替えの前後は300程度が目安である
• IPアドレスを変更する前に、TTLを下げておくのが、最も重要なポイントである
• 設定後は、dig・ドメインチェッカーなどで、現在のTTLを確認する

TTLは、地味な項目ですが、サーバー移転やトラブル対応の場面で、その重要性を実感する設定です。普段は3600前後で運用し、変更の予定があるときだけ、事前に短くする、という使い分けを覚えておけば、慌てずに対処できるようになります。ドメインの現在の設定を確認したいときは、ドメインチェッカーなどのツールもぜひ活用してください。