DNS TTLとは何を決める時間か
TTLは、Time To Liveの略で、DNSの答えをどれくらいの時間覚えてよいかを示す値です。単位は秒で、300なら5分、3600なら1時間です。キャッシュDNSは受け取った答えを期限まで再利用し、期限を過ぎたら必要に応じて問い合わせ直します。
DNSの基本は、ドメイン名をIPアドレスなどの宛先へ案内する仕組みです。全体の流れは DNSの仕組み とつなげて読むと見えやすくなります。
TTLが短いほど再確認されやすく、長いほど同じ答えが残りやすくなります。ただし、短ければ何でも良いわけではありません。問い合わせが増えたり、サービス側の推奨値があったりするため、目的に合わせて決めます。
ユイ
DNSを変えたのに、私の画面だけ古い住所へ行ってしまいます
ピコ
DNS TTLの砂時計がまだ残っているのかもしれないね
マコト
答えを覚えてよい時間を見れば、反映待ちの理由を整理できそうだ
DNS案内所の砂時計で見るTTL
ピコルート・ラボのDNS案内所では、答えカードの横に砂時計が置かれています。砂が落ちきるまでは、案内係が同じカードを使い続けます。砂が落ちきったあとは、次に答えが必要になったときに改めて調べます。

ユイ
古い住所へ行く端末は、前の答えカードをまだ持っているんですね
ピコ
そう。DNS案内所の砂時計を見ると、待ち時間がただの謎ではなくなるよ
たとえでは砂時計ですが、実際にはキャッシュDNS、端末、ブラウザ、アプリなど複数の場所が関わる場合があります。TTLは重要な手がかりですが、表示の違いを一つで全部説明できるとは限りません。
DNS TTLをdigで確認する方法
DNS管理画面のTTL欄は、運用者がレコードへ設定する値です。一方、普段使うキャッシュDNSへ問い合わせた結果には、そのキャッシュに残っている有効時間が表示されることがあります。値が違っても、すぐに設定ミスとは判断できません。
macOSやLinuxなど、digが使える環境では、ターミナルで次のように問い合わせます。これはDNSの答えを読む操作で、設定は変更しません。
dig example.com A +noall +answer
example.comを調べたいドメイン名に置き換えます。AはIPv4アドレスの問い合わせです。次は読み方を示す架空の出力例で、実際に返る値ではありません。
example.com. 240 IN A 192.0.2.10
| 出力の部分 | 読み方 |
|---|---|
| example.com. | 答えの対象となる名前 |
| 240 | 返されたTTL。単位は秒なので、この例では4分 |
| IN / A | インターネットのAレコード |
| 192.0.2.10 | 対応するIPv4アドレス(説明用の例) |
+noall +answerは、返答のうち答えの部分を絞って表示する指定です。何も出ない場合は、TTLが0という意味ではありません。dig example.com Aのように表示を省略せず実行し、応答の状態も確認します。digが見つからない環境では、この方法は使えません。
管理画面の設定が3600秒でも、あるキャッシュDNSが答えを受け取ってから10分ほど経っていれば、残り約3000秒で返す場合があります。この数値は、すべての利用者が切り替わるまでのカウントダウンではありません。 問い合わせ先やキャッシュの更新によって値は変わります。
確認メモには、ドメイン名・レコードの種類・確認時刻・返った値を残します。通常のdig出力にあるSERVER欄では、今回どのDNSサーバーへ問い合わせたかも確認できます。
TTLの推奨値は短ければよい?
TTLが長いと、同じ答えを長く使えるため問い合わせ回数は減りやすくなります。一方で、DNSを変更したときに古い答えが残る時間も長く見えることがあります。
TTLが短いと、変更後に再確認されやすくなります。ただし、常に短くしすぎるとDNS問い合わせが増えたり、管理上の意図と合わなかったりします。
| TTLの傾向 | 見え方 | 注意点 |
|---|---|---|
| 長い | 答えが安定して残りやすい | 変更時に古い答えが残りやすい |
| 短い | 再確認されやすい | 問い合わせ増加や設定ミスに注意 |
一律の正解はありません。まず利用中のDNSサービスの推奨値や制約を確認し、変更頻度と問い合わせ負荷を考えて決めます。サイト移転などで短くする場合も、変更直前ではなく前もって行うことに意味があります。
DNS変更前後でTTLを見る流れ
DNSを変更する前後では、次の順にメモを作ると焦りにくくなります。
- 変更するレコードの種類を確認する
- 現在のTTLを確認する
- 短縮する運用なら、変更前のTTLを考慮して事前に行う
- レコードを変更する
- 権威DNSと、利用する回線から返る答えを確認する
- 安定後にTTLを戻すか検討する

TTLを3600秒から300秒へ変更しても、すでに3600秒で覚えられた答えの期限を、あとから一斉に縮めることはできません。変更前のTTL、短縮した時刻、レコードを切り替えた時刻は別々に記録します。
DNSが新しい宛先を返していても、ページのキャッシュなど別の理由で表示が古い場合があります。環境ごとの反映差と確認の順番はDNS変更の反映に時間差が出る理由で扱います。
ミニワーク:DNS変更前のメモを作る
次の形で、変更前メモを作ってみましょう。
- 変更するドメイン: ______
- 変更するレコード: A / CNAME / MX / TXT / その他
- 現在のTTL: ____秒
- 変更予定時刻: ____
- 確認する回線: 自宅 / モバイル回線 / 社内 / 外部ツール
実際に変更する予定がなければ、読み取ったTTLを秒から分へ直すだけでも構いません。設定値と返答の値を別の欄に書くと、何を確認した数字なのかが明確になります。
ミニクイズでTTLの扱いを確かめる
Q1. DNS TTLは何を示しますか?
A. DNSの答えをキャッシュとして覚えてよい時間を示します。
Q2. TTLを短くすると、世界中で同時に切り替わりますか?
A. 同時とは限りません。複数のキャッシュや確認タイミングが関係します。
Q3. DNS変更前にTTLを見る理由は何ですか?
A. 古い答えがどれくらい残りやすいかを見積もり、変更後の確認を落ち着いて進めるためです。
次は、表示が人によって違う現象を運用目線で見る DNS浸透とは へ進むと、TTLとの関係がさらに整理できます。
この記事について
LAB WHITEBOARD
自分の言葉で説明してみよう
「設定TTLと応答中の残りTTLを区別し、digの出力から秒数を読めるようになる。」を、いまの自分の言葉で一文にしてみてください。途中の説明でも大丈夫です。




