TTLの設定値による反映時間の違い｜変更前に下げるタイミングと値の決め方

DNSのTTLは「キャッシュDNSサーバーがその答えを何秒まで覚えておいてよいか」を示す値で、レコードを変更したときに古い値が残る最長時間の目安になります。この記事では、TTLの値ごとに反映時間がどう変わるか、サーバー移転などの前にいつTTLを下げればよいか、普段はどの程度の値にしておくのが扱いやすいかを、計算の考え方と確認コマンド付きで説明します。

TTLと反映時間の関係

キャッシュDNSサーバー（プロバイダのDNSや公開DNS）は、権威DNSから受け取った答えをTTLの秒数だけ保持し、その間に来た問い合わせにはキャッシュから答えます。TTLが切れると権威DNSへ聞き直し、そこで初めて新しい値を受け取ります。

このため、レコードを変更してから全員に新しい値が届くまでの時間は、おおむね「変更前のレコードに付いていたTTL」で決まります。キャッシュされたタイミングは利用者ごとにばらばらなので、変更直後に切り替わる人もいれば、TTLいっぱいまで古い値を見続ける人もいます。

表の時間は目安で、実際には後述するようにキャッシュDNS側の挙動やOS・ブラウザのキャッシュも加わります。

「新しいTTL」はすぐには効かない

よくある誤解が、「TTLを300に変えたから5分で反映される」というものです。TTLを短くする変更そのものもDNSの変更なので、すでに古い答えをキャッシュしているサーバーには、古いTTLが切れるまで届きません。

たとえばTTL 86400秒のAレコードを、移転当日にTTL 300秒と新IPへ同時に変更した場合、キャッシュDNSによっては最長で約1日、旧IPを返し続けます。新しいTTLが効くのは、古いキャッシュが切れて新しい答えを受け取った後からです。

サーバー移転前にTTLを下げる手順

反映待ちを短くしたい作業では、次の順序で進めます。

1. 現在のTTLを確認する

権威DNSに直接問い合わせると、設定されているTTLそのものが分かります。

dig +short example.com NS
dig @ns1.example.net example.com A +noall +answer

2列目の数字が設定値です（ns1.example.net は例なので、実際のネームサーバー名に置き換えてください）。

2. 作業の前にTTLを短くする

確認した現在のTTL以上の時間をあけてから作業できるよう、前もってTTLを300秒程度に下げます。現在値が86400秒なら、少なくとも1日以上前に下げておく計算です。余裕をみて、作業の前々日ごろに下げておくと安心です。対象はAレコードだけでなく、AAAA・wwwのCNAMEなど、変更予定のレコードすべてです。

3. 古いキャッシュが切れたことを確かめる

公開DNSに問い合わせて、TTLが300以下で返っていれば、そのキャッシュは新しいTTLに置き換わっています。

dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer

4. レコードの値を変更する

ここで新しいIPアドレスなどに変更します。古いキャッシュはすでに短いTTLになっているため、多くの利用者には数分程度で新しい値が届きます。万一問題が出て元に戻す場合も、同じく短時間で切り戻せます。

5. 落ち着いたらTTLを戻す

切り替えが安定し、切り戻しの可能性が低くなったら、TTLを普段の値（3600秒など）に戻します。

短いTTLを常用しない理由

「いつでもすぐ反映されるように、常に短くしておけばよい」と考えがちですが、次の点で不利になります。

• キャッシュが早く切れるため、権威DNSへの問い合わせ回数が増える。問い合わせ数に応じて課金されるDNSサービスでは費用にも影響する
• 名前解決のたびに権威DNSまで聞きに行く機会が増え、初回アクセスがわずかに遅くなることがある
• 権威DNSが一時的に応答しなくなったとき、キャッシュが早く切れる分、影響が出るまでの時間が短い

障害時に別のサーバーへ切り替える構成（DNSフェイルオーバー）のように、短いTTLそのものに意味がある場合を除けば、普段は1時間前後にしておき、作業の前だけ下げる運用が扱いやすいでしょう。

TTL以外で反映時間に影響するもの

ネームサーバーの変更は別扱い

ネームサーバー（NSレコード）を変更する場合、効いてくるのはドメインの上位（.com や .jp のレジストリ）側に登録されたNS情報のTTLです。この値はドメイン所有者が変更できず、.com では2日（172800秒）が一般的です。自分のゾーン内のTTLを下げても、この部分は短くなりません。上位のTTLは dig +trace example.com NS の途中経過で確認できます。

存在しない名前のキャッシュ

まだ作っていないサブドメインに問い合わせると、「存在しない」という答えがキャッシュされます（ネガティブキャッシュ）。この保持時間は、SOAレコードのTTLとSOAの最後の値（MINIMUM）のうち短いほうで決まります（RFC 2308）。新しいサブドメインを作る予定があるなら、作成前に問い合わせないようにするか、この値を確認しておきます。

キャッシュDNSやOSの事情

キャッシュDNSサーバーによっては、極端に短いTTLを一定の下限まで引き上げたり、長すぎるTTLを上限で打ち切ったりする運用をしている場合があります。また、OSやブラウザも独自に短時間のキャッシュを持っています。設定したTTLどおりにならない利用者が少数いるのは、こうした要因によるものです。

DNSサービスごとの設定単位

DNSサービスによって、設定できるTTLの最小値や選択肢は異なります。たとえば Cloudflare でプロキシを有効にしたレコードはTTLが自動設定になり、任意の値を指定できません（2026年10月現在）。仕様は変わることがあるため、利用中のサービスのドキュメントで確認してください。

残りTTLで反映状況を読む

公開DNSに問い合わせたときのTTLは「設定値」ではなく「そのキャッシュの残り時間」です。

dig @8.8.8.8 example.com A +noall +answer
# 数十秒おいてもう一度実行し、数字が減っているか見る

数字が減っていれば古いキャッシュから返っており、0に近づいた後に新しい値へ変わるはずです。設定値と同じ数字で返り続ける場合は、そのたびに権威DNSへ聞き直しているか、複数のキャッシュサーバーに振り分けられている可能性があります。

まとめ

• TTLは「古い値が残りうる最長時間」の目安で、効くのは変更前のTTL
• 移転などの作業では、現在のTTL以上前にTTLを300秒程度へ下げ、キャッシュが切れてから値を変更する
• 普段は1時間前後にしておき、作業後は元の値に戻すと負荷と柔軟性のバランスが取りやすい
• ネームサーバー変更は上位のTTL（.com では2日が一般的）に左右され、自分では短くできない
• 新しいサブドメインはネガティブキャッシュ、利用者側はOSやキャッシュDNSの事情でも差が出る

• DNSフェイルオーバーで冗長化する方法
• SOAレコードの設定と各項目の意味