DNS の TTL（Time To Live）は、キャッシュサーバー（プロバイダーや Google Public DNS などのフルリゾルバー）が、権威 DNS サーバーから受け取ったレコードを覚えておいてよい秒数です。TTL が 3600 なら、一度問い合わせた結果は最大1時間キャッシュされ、その間に権威 DNS サーバー側でレコードを書き換えても、そのキャッシュサーバーを使う人には古い値が返ります。
「DNS を変えたのに反映されない」の多くは、この TTL の間キャッシュが残っていることが原因です。この記事では、TTL の決め方、サーバー移転のときの下げ方、BIND での書き方、反映の確かめ方を説明します。
TTL が効く場所
DNS の問い合わせは、次の順に流れます。
- パソコンやスマートフォンが、設定されているキャッシュサーバーに名前を問い合わせる
- キャッシュサーバーは、キャッシュに無ければ権威 DNS サーバーに問い合わせる
- 権威 DNS サーバーは、レコードと TTL を返す
- キャッシュサーバーは、その TTL の秒数だけ結果を覚え、次からはキャッシュから返す
TTL を決めるのは権威 DNS サーバー側（ドメインの DNS を管理している人）で、守るのはキャッシュサーバー側です。TTL を短くしても、すでにキャッシュされている分は、そのとき受け取った TTL が切れるまで残ります。
TTL の決め方
| 状況 | TTL の目安 | 理由 |
|---|---|---|
| 普段の A・AAAA・CNAME レコード | 3600（1時間）〜86400（1日） | 問い合わせが減り、権威 DNS サーバーが止まったときもキャッシュで応答が続く |
| サーバー移転・IP アドレス変更の直前 | 300（5分）前後 | 切り替え後、古い IP に向かう人を短時間で減らす |
| MX・NS レコード | 3600 以上 | 頻繁に変えないため短くする理由が少ない |
TTL を短くすると変更はすぐ広まりますが、キャッシュの効きが悪くなり、権威 DNS サーバーへの問い合わせが増えます。普段は長め、変更の前だけ短くするのが基本です。
サーバー移転のときの TTL の下げ方
WordPress サイトを別のサーバーへ移すときは、次の順で進めます。
- 移転の前に TTL を下げる: 対象の A レコード（
wwwを含む）の TTL を 300 にします。 - 元の TTL の時間だけ待つ: 元の TTL が 86400 なら、下げてから1日以上待ちます。これで、古い長い TTL のキャッシュが消え、どのキャッシュサーバーも 300 秒で問い合わせ直す状態になります。
- IP アドレスを切り替える: A レコードを新しいサーバーの IP アドレスに変えます。多くの人は5分ほどで新しいサーバーに向かいます。
- しばらく両方のサーバーを動かす: TTL を守らないキャッシュサーバーもあるため、古いサーバーはすぐ止めず、アクセスログで流入が無くなったことを確かめてから止めます。
- TTL を元に戻す: 新しいサーバーで問題が無ければ、TTL を 3600 などに戻します。
手順2を飛ばすと、TTL を 300 に下げても、下げる前に配られた長い TTL のキャッシュが残っているため、切り替えがすぐ広まりません。
反映が遅いときの調べ方は「DNS の変更が反映されないときの確認と対処」も参照してください。
DNS サービスの管理画面で設定する
レンタルサーバーやドメイン会社の DNS を使っている場合は、レコードの編集画面に TTL の欄があります。選べる値の範囲はサービスによって違うので、各社のマニュアルを確認してください。
Cloudflare の場合（2026年11月時点の公式ドキュメント）は、次のとおりです。
- プロキシを通さないレコード（DNS only）: TTL は 60 秒（Enterprise プランは 30 秒）から 1 日まで選べる
- プロキシを通すレコード（Proxied、オレンジの雲）: TTL は「Auto」（300 秒）で固定。訪問者に返るのは Cloudflare の IP アドレスなので、元のサーバーの IP を変えても訪問者側のキャッシュには影響しない
BIND で TTL を設定する
自分で BIND を動かしている場合、TTL は named.conf ではなくゾーンファイルに書きます。named.conf の zone の中に ttl という設定はありません。
ゾーンファイルの例です（example.com の部分は自分のドメインに置き換えます）。
$TTL 3600
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2026111001 ; シリアル番号
12h ; refresh
15m ; retry
4d ; expire
1h ; ネガティブキャッシュの TTL
)
IN NS ns1.example.com.
IN NS ns2.example.net.
ns1 IN A 192.0.2.2
@ IN A 192.0.2.10
www 300 IN A 192.0.2.10$TTL 3600: TTL を書いていないレコードに使う標準の TTL です。2d（2日）や12hのように単位を付けても書けます。www 300 IN A ...: 名前の後ろに数字を書くと、そのレコードだけ TTL が 300 秒になります。移転前に一部のレコードだけ下げるときはこの書き方を使います。- SOA の最後の値: 存在しない名前（NXDOMAIN）の応答をキャッシュする時間です（RFC 2308）。レコードを新しく作る前に、その名前を誰かが問い合わせていると、この時間だけ「無い」という答えが残ります。
変更を反映する
ファイルの置き場所は配布物で違います。Debian・Ubuntu では /etc/bind/ 以下（ゾーンの指定は /etc/bind/named.conf.local）、RHEL・Rocky Linux・AlmaLinux では /etc/named.conf と /var/named/ が標準です。
- SOA のシリアル番号を増やします（上の例なら
2026111001を2026111002に）。セカンダリサーバーは、この番号が増えたときだけゾーンを取り直します。 - 書式を確かめてから、そのゾーンだけ読み込み直します。
# ゾーンファイルの書式チェック（ファイルのパスは環境に合わせる）
sudo named-checkzone example.com /etc/bind/db.example.com
# このゾーンだけ読み込み直す
sudo rndc reload example.comnamed.conf そのものを変えた場合は、sudo named-checkconf で確認してから sudo rndc reconfig（またはサービスの再起動）を行います。
dig で TTL を確かめる
dig の結果の2列目が TTL です。
# 権威 DNS サーバーに直接聞く（設定した TTL がそのまま出る）
dig @ns1.example.com www.example.com A +noall +answer
# キャッシュサーバーに聞く（残り秒数が出る）
dig @8.8.8.8 www.example.com A +noall +answer出力の例です。
www.example.com. 300 IN A 192.0.2.10権威 DNS サーバーに聞いたときは設定した値（ここでは 300）がいつも同じく出ます。キャッシュサーバーに聞くと、キャッシュの残り時間が出るので、繰り返すたびに数字が減っていきます。数字が大きいまま減らない場合は、まだ古い長い TTL のキャッシュが残っています。
dig が無い場合は、Debian・Ubuntu では bind9-dnsutils（dnsutils）、RHEL 系では bind-utils パッケージに入っています。
まとめ
- TTL は、キャッシュサーバーがレコードを覚えておく秒数で、権威 DNS サーバー側で決める
- 普段は 3600 秒以上、サーバー移転の前だけ 300 秒前後に下げ、元の TTL の時間だけ待ってから IP アドレスを切り替える
- BIND では TTL をゾーンファイルの
$TTLとレコードごとの数字で書き、シリアル番号を増やしてrndc reloadで反映する digの2列目で TTL を確かめ、権威 DNS サーバーとキャッシュサーバーの両方に聞いて比べる
DNS の名前解決の流れ全体は「DNS の名前解決の流れ」で説明しています。