DNS の TTL は「キャッシュ DNS がその答えを保存してよい最大の秒数」ですが、実際のキャッシュ DNS は上限・下限を設けたり、期限切れの答えを使い続けたりと、書いた値をそのまま守るとは限りません。適切な TTL は、「変更したときに古い答えが残ってよい時間」と「権威 DNS が止まったときにキャッシュで持ちこたえたい時間」の2つから逆算して決めるのが実用的です。この記事では、TTL がキャッシュ DNS やクライアントでどう扱われるか、レコードの種類ごとに気をつける点、設定値の決め方と、残り時間を実測して切り替えを見積もる方法を解説します。
TTLの数字が表すもの
TTL は秒単位の整数で、ゾーンファイルではレコードの2列目に書き、DNS サービスでは各レコードの TTL 欄で指定します。キャッシュ DNS は答えを受け取った時点の TTL から残り時間を数え始め、0 になると捨てて権威 DNS に問い合わせ直します。
このため、変更後に古い答えが残る時間の上限は「変更前の TTL」で決まります。新しい TTL ではありません。さらに、OS やアプリケーションのキャッシュがその上に重なるので、実際の待ち時間は「旧 TTL＋クライアント側の保持時間」と見積もるのが安全です。
キャッシュDNSはTTLをそのまま使うとは限らない
TTL は権威 DNS 側からの「上限の指示」で、キャッシュ DNS の運用者は独自の制限をかけられます。代表的なものは次のとおりです。
- 上限の切り詰め：BIND の
max-cache-ttl（既定は1週間）、Unbound のcache-max-ttl（既定は1日）のように、長すぎる TTL は短く切り詰められます。TTL を数日〜数週間にしても、その分キャッシュが長持ちするとは限りません - 下限の引き上げ：Unbound の
cache-min-ttlのように、短すぎる TTL を引き上げる設定もあります。既定では無効ですが、運用者が有効にしていることがあり、60秒にしたつもりでも、そのリゾルバーの利用者にはもっと長く古い答えが返る場合があります - 期限切れの答えを返す（serve-stale）：権威 DNS に到達できないとき、期限切れのキャッシュを一時的に返す仕組みが RFC 8767 で定められており、BIND や Unbound にも対応する設定があります。権威 DNS の障害時に被害を和らげる働きがある一方、「旧サーバーへの古い答えが TTL を過ぎても返ることがある」理由の一つにもなります
- ネガティブキャッシュの上限：「その名前は存在しない」という答え（NXDOMAIN）もキャッシュされ、保存時間は SOA レコードの TTL と SOA の最後の項目（MINIMUM）の小さい方で決まります（RFC 2308）。リゾルバー側にも上限があり、BIND は
max-ncache-ttl、Unbound はcache-max-negative-ttlで設定します
ここに挙げた既定値は各ソフトウェアのドキュメントによるもので、版によって変わることがあります（2026年10月現在）。Google Public DNS や Cloudflare の 1.1.1.1 のような公開リゾルバーの内部の扱いは公開されていない部分もあるため、「TTL どおりにならないことがある」前提で計画を立てます。
クライアント側のキャッシュ
キャッシュ DNS の外側にも、答えを覚えている層があります。
- OS：Windows の DNS クライアント、macOS の mDNSResponder、Linux の systemd-resolved などが独自にキャッシュします。通常は TTL を尊重しますが、手元で古い答えが残る原因になります
- ブラウザ：Chrome などは短時間のホストキャッシュを持ちます
- 長時間動くプログラム：起動時に一度だけ名前解決して、その IP アドレスを使い続けるものがあります。WordPress の前段に置いた nginx のリバースプロキシで
proxy_passにホスト名を書くと、設定の読み込み時に解決した IP アドレスを使い続け、TTL が切れても引き直さないのが代表例です。向き先が変わりうる場合は、resolverディレクティブと変数を組み合わせる方法などを nginx のドキュメントで確認してください
レコードの種類ごとに気をつける点
同じ名前・同じ種類のレコードは TTL をそろえる：www に A レコードを2つ置くなら、TTL は同じにします。異なる TTL の混在は RFC 2181 で非推奨とされており、多くの DNS サービスはレコードセット単位で1つの TTL しか持てません。
CNAME は段ごとに別々にキャッシュされる：www を CDN のホスト名に向ける CNAME では、自分が決められるのは CNAME の TTL だけで、向き先の A レコードの TTL は CDN 側が決めます。CDN を乗り換えるときに効くのは CNAME の TTL です。
DNS サービス独自の扱い：Cloudflare でプロキシを有効にしたレコードは TTL が自動扱いになり、訪問者には Cloudflare の IP アドレスが返ります。Amazon Route 53 のエイリアスレコードは TTL を自分で指定できず、向き先の AWS リソース側の値が使われます（どちらも2026年10月現在。詳細は各サービスのドキュメントを参照）。
SOA の値がネガティブキャッシュを決める：新しいサブドメインを作る前に名前を引いてしまうと、作成後も「存在しない」という答えが SOA の値の分だけ残ります。サブドメインを作る予定があるなら、作成前に引かないか、SOA の MINIMUM を数分〜1時間程度に抑えておくと待ち時間が短くなります。
NS と DS は親ゾーンの TTL が効く：ネームサーバーの変更や DNSSEC の DS レコードは、TLD のレジストリが決めた TTL に従い、自分では短くできません。
DNSSEC の署名とキーの TTL：DNSSEC を使うゾーンでは、レコードの TTL が署名（RRSIG）の有効期限を超えないようにする必要があり、鍵を更新するときは DNSKEY や DS の TTL を待ち時間として計画に組み込みます。
設定値の決め方
TTL は、次の3つの問いに答えると決めやすくなります。
- 変更や切り替えのとき、古い答えを何分まで許せるか：許せる時間から、クライアント側の保持分の余裕を差し引いた値が TTL の上限です。10分までなら300秒程度が目安になります
- 権威 DNS は冗長化されているか：権威 DNS が1社・1系統だけなら、短すぎる TTL は障害時にすぐ名前解決が止まることを意味します。長めの TTL にして、変更の前だけ下げる運用が向いています。複数の DNS 事業者に分散しているなら、短めの TTL でも耐えやすくなります
- 問い合わせ量と費用：問い合わせ数で課金される DNS サービスでは、アクセスの多いレコードの TTL を極端に短くすると、その分問い合わせが増えます
よく変える予定がなく、権威 DNS が1系統の WordPress サイトなら、A・AAAA・CNAME は1時間程度、変更の数日前に300秒程度まで下げ、作業後に戻す、という形が扱いやすい選択です。
残りTTLを測って切り替えを見積もる
計画どおりに古い答えが消えるかは、実際の残り時間を見ると分かります。まず権威 DNS に直接問い合わせて設定値を確認し、次に複数の公開リゾルバーで残り時間を比べます。
# 権威DNSに聞く（2列目が設定値そのもの）
dig @ns1.example.net www.example.com A +norec +noall +answer
# 公開リゾルバーごとの残り秒数と、返っているIPアドレス
for r in 8.8.8.8 1.1.1.1 9.9.9.9; do
printf '%-10s ' "$r"
dig @"$r" www.example.com A +noall +answer | awk '{print $2, $5}' | tr '\n' ' '
echo
done
# ネガティブキャッシュの長さ（AUTHORITY欄のSOAのTTLが残り時間）
dig @8.8.8.8 not-yet.example.com A +noall +authority公開リゾルバーは多数のサーバーで構成されているため、同じ IP アドレスに問い合わせても、毎回違うキャッシュに当たって数字がばらつくことがあります。何度か実行し、最も大きい残り時間を「この先まだ古い答えが返りうる時間」の目安にします。TTL を下げる作業の後は、ここで表示される数字がすべて新しい TTL 以下になったことを確かめてから、本番の切り替えに進みます。
まとめ
- TTL はキャッシュの上限の指示で、古い答えが残る時間は変更前の TTL とクライアント側のキャッシュで決まる
- キャッシュ DNS は TTL を切り詰めたり引き上げたりし、障害時には期限切れの答えを返すこともある
- 同じレコードセットの TTL はそろえ、CNAME は段ごと、NS・DS は親ゾーンの TTL が効くことを押さえる
- 設定値は「許せる古さ」「権威 DNS の冗長性」「問い合わせ量」から逆算する
- 切り替え前に、権威 DNS の設定値と公開リゾルバーの残り時間を実測して確かめる