DNS の TTL（Time To Live）は、キャッシュ DNS がそのレコードを覚えておいてよい時間を秒数で示した値です。長くすると問い合わせが減って安定し、短くすると変更がすばやく行き渡る、という性質があるため、「普段は長め、変更の予定があるときだけ事前に短く」が基本の考え方になります。この記事では、TTL が実際にどう働くのか、レコードの用途別の目安、サーバー移行の前に TTL を下げる手順と確認方法を解説します。
TTLとは何か
ブラウザが www.example.com にアクセスするとき、多くの場合は権威 DNS サーバーに直接ではなく、プロバイダや Google Public DNS などのキャッシュ DNS（フルリゾルバー）に問い合わせます。キャッシュ DNS は一度調べた答えを保存し、次の問い合わせには保存した答えを返します。この保存期間の上限が TTL です。
ゾーンファイルでは、レコードごとに2列目へ秒数で書きます。
$TTL 3600
example.com. 3600 IN A 192.0.2.10
www.example.com. 300 IN A 192.0.2.10
example.com. 86400 IN MX 10 mail.example.com.$TTL はゾーン全体の既定値で、個別の値を書かなかったレコードに使われます。DNS サービスの管理画面では、レコードの編集欄に「TTL」という項目があり、秒数や「1時間」「自動」などの選択肢で指定します。
TTL について誤解されやすいのは次の2点です。
- TTL は「反映までの時間」ではなく「古い答えが残りうる最大の時間」：レコードを変更した瞬間に、各地のキャッシュ DNS が持っている古い答えは、それぞれの残り時間が切れるまで使われ続けます。キャッシュを持っていないリゾルバーには、すぐに新しい答えが返ります
- TTL を下げても、下げたこと自体が伝わるのは古い TTL が切れてから：TTL 86400（1日）のレコードを 300 に変えても、すでに1日分の TTL でキャッシュされた答えは最大1日残ります
長いTTLと短いTTLの違い
TTL をどう決めるかは、次のトレードオフで考えます。
長くした場合（例：3600〜86400秒）
- キャッシュがよく効き、名前解決の待ち時間が平均的に短くなる
- 権威 DNS への問い合わせが減る。問い合わせ数で課金される DNS サービスでは費用面でも有利
- 権威 DNS が一時的に応答しなくなっても、キャッシュが残っている間は名前解決が続く
- その反面、変更や障害時の切り替えに時間がかかる
短くした場合（例：60〜300秒）
- IP アドレスの変更やフェイルオーバーがすばやく行き渡る
- 問い合わせが増え、権威 DNS が止まったときの影響がすぐに出る
用途別の目安
あくまで目安ですが、次のように考えると決めやすくなります。
- 普段あまり変えない A / AAAA / CNAME：3600 秒（1時間）程度。安定していて当面変更予定がなければ、もっと長くしてもかまいません
- 移行や切り替えを近く予定しているレコード：300 秒（5分）程度まで事前に下げておく
- ヘルスチェック連動のフェイルオーバーやロードバランサー：60〜300 秒。サービス側が値を固定している場合もあります
- MX・TXT（SPF・DKIM・DMARC）：3600 秒以上。ただし、メールサービスの乗り換え前は A レコードと同じく事前に下げます
- NS レコード：86400 秒前後と長めにするのが一般的です
DNS サービスによっては、設定できる TTL の下限が決まっていたり、「自動」を選ぶとサービス側の既定値が使われたりします。たとえば Cloudflare でプロキシ（オレンジの雲）を有効にしたレコードは TTL が自動扱いになり、訪問者にはオリジンではなく Cloudflare の IP アドレスが返るため、オリジンの IP を変えても訪問者側の DNS キャッシュは関係しません（2026年10月現在）。細かな仕様はサービスのドキュメントで確認してください。
サーバー移行の前にTTLを下げる手順
WordPress を別のサーバーへ移すときは、次の流れで進めると切り替えの待ち時間を短くできます。
- 今の TTL を確認する：権威 DNS に直接問い合わせて、設定値を調べます（確認方法は後述）
- 移行の「今の TTL 以上」前に TTL を下げる：たとえば今の TTL が 86400 秒なら、少なくとも1日以上前に 300 秒へ下げます。余裕を見て2日前などにしておくと安心です
- 新しいサーバーの準備と動作確認を済ませる：hosts ファイルで新サーバーを向けるなどして、DNS を切り替える前に表示を確かめておきます
- レコードを新しい IP アドレスに書き換える：短い TTL のおかげで、古い答えが残るのは数分程度になります
- 移行が落ち着いたら TTL を元に戻す：数日問題がなければ、3600 秒などの普段の値に戻します
切り替え直後は、まだ古いサーバーにアクセスする人が残ります。WordPress ではその間に旧サーバーへ投稿・コメント・注文が入るとデータが分かれてしまうため、移行作業中は更新を止める、または旧サーバー側をメンテナンス表示にするなどの対策を取ってください。DB を書き換える作業の前には、両方のサーバーでバックアップを取っておきます。
設定したTTLの確認方法
dig コマンドを使うと、TTL を確認できます。
# いつも使っているリゾルバー経由で確認（2列目がキャッシュの残り秒数）
dig www.example.com A +noall +answer
# 権威DNSサーバーに直接聞く（2列目が設定値そのもの）
dig www.example.com A @ns1.example.net +norec +noall +answerキャッシュ DNS 経由の結果では、2列目の数字は「そのキャッシュに残っている秒数」なので、続けて実行すると少しずつ減っていきます。設定した値そのものを確かめたいときは、権威 DNS サーバーを @ で指定して問い合わせます。権威 DNS サーバーの名前は dig example.com NS +short で調べられます。
TTLのとおりにならない場合
TTL を短くしたのに、思ったより古い答えが長く残ることがあります。主な理由は次のとおりです。
- ネガティブキャッシュ：まだ存在しない名前を一度問い合わせると、「存在しない」という答えもキャッシュされます。この保存期間は SOA レコードの値（最後の項目と SOA 自体の TTL の小さい方）で決まります。新しいサブドメインを作る前に何度も確認すると、作成後もしばらく「存在しない」と返ることがあります
- リゾルバー側の上限・下限：キャッシュ DNS の中には、TTL に独自の上限や下限を設けているものがあります
- OS・ブラウザ・アプリのキャッシュ：OS やブラウザも独自に DNS の結果を保存します。アプリケーションによっては DNS の結果を長く保持するものもあります
- 親ゾーンの NS レコード：ネームサーバーの変更は、TLD 側が決める NS の TTL（長めのことが多い）に従います。この値は自分では変えられません
まとめ
- TTL はキャッシュ DNS がレコードを保存してよい最大秒数で、変更後に古い答えが残りうる時間を表す
- 長い TTL は安定と問い合わせ削減、短い TTL は切り替えの速さが利点
- 普段は 3600 秒程度、移行やフェイルオーバーの対象は 60〜300 秒が目安
- 移行時は「今の TTL 以上」前に下げ、作業後に戻す。下げた効果は古い TTL が切れてから効く
- 設定値の確認は権威 DNS に
+norecで直接問い合わせる - ネガティブキャッシュや OS・ブラウザのキャッシュで、TTL どおりにならないことがある