TTL（Time To Live）

概要

TTL（Time To Live） は、DNS リゾルバー（キャッシュサーバー）がレコードをキャッシュする有効期間を秒数で指定する値です。RFC 1035 でリソースレコードの必須フィールドとして定義されており、32 ビット符号なし整数で最大値は 2147483647 秒（約 68 年）。実用的な範囲は 60 秒〜86400 秒（24 時間）が大半を占めます。

TTL が 3600 に設定されている場合、リゾルバーはそのレコードを最大 1 時間キャッシュし、期間中は権威サーバーに問い合わせずキャッシュから応答します。TTL の選択は「変更の反映速度」と「権威サーバーへの問い合わせ回数」のトレードオフです。どちらを優先するかは、そのレコードの変更頻度と、サービスの可用性要件によって変わります。

仕組み

TTL は権威サーバーがレコードをリゾルバーに返すときに設定します。その後、リゾルバーがクライアントへ転送する際、TTL 値は受信してからの経過秒数だけデクリメントされて渡されます。

1. クライアントがリゾルバーに DNS 問い合わせを送る
2. リゾルバーにキャッシュがなければ、権威サーバーへ再帰問い合わせを行う
3. 権威サーバーがレコードと TTL を返す（例: TTL 3600）
4. リゾルバーは TTL の期間だけレコードをキャッシュし、クライアントには残りの TTL を付与して返す
5. TTL がゼロになるとキャッシュから削除され、次の問い合わせで権威サーバーへ再問い合わせが発生する

重要な点として、TTL はリゾルバーが権威サーバーを「再確認しなければならない最大期間」を定めるものであり、「キャッシュを更新するタイミング」を保証するものではありません。TTL が切れる前にメモリ容量や設定によってキャッシュが退避される場合もあります。

設定例

TTL を指定した DNS レコードの記述例です。

; 標準的な A レコード（TTL 1時間）
example.com.  3600  IN  A  93.184.216.34

; 変更予定がある場合の事前短縮（TTL 5分）
example.com.   300  IN  A  93.184.216.34

; TTL を省略するとゾーン定義の $TTL が適用される
$TTL 3600
example.com.  IN  A  93.184.216.34   ; 上の $TTL が使われ、3600 になる

確認方法

dig コマンドを使うと、ANSWER SECTION の 2 列目に TTL の残り秒数が表示されます。

# TTL の現在値を確認する（ANSWER SECTION に表示される数値が残り秒数）
dig A example.com

;; ANSWER SECTION:
example.com.		254	IN	A	93.184.216.34

ANSWER SECTION の 2 列目（この例では 254）が TTL の残り秒数です。

# 権威サーバーに直接問い合わせる（キャッシュをバイパス）
dig A example.com @ns1.example.com

権威サーバーに直接問い合わせると設定されている元の TTL 値が返ります。両者を比較すれば、問い合わせたリゾルバーがキャッシュをいつ取得したかを推測できます。

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=A"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [
        { "address": "93.184.216.34", "ttl": 3600 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 45 }
}

各レコードの ttl フィールドにキャッシュの残り秒数が含まれます。

よくある問題

TTL に起因するトラブルは、変更前の事前短縮を怠ったケースと、ISP 側のキャッシュ挙動に起因するケースに大別されます。

TTL を下げる前に変更した場合

旧 TTL が 86400（24 時間）のまま IP アドレスを変更すると、世界中のリゾルバーが最大 24 時間にわたって旧 IP にトラフィックを送り続ける可能性があります。特にメールサーバーの MX レコードを変更した場合、配送が旧サーバーに向き続けてメールが届かない状態が発生します。この状態は変更の取り消しでは解決できず、旧 TTL の時間が経過するまで待つしかありません。

ISP によるキャッシュ期間の無視

一部の ISP や企業内リゾルバーは TTL を尊重せず、独自の期間（多くは最短 300 秒）でキャッシュを保持します。TTL を 60 秒に設定しても、これらのリゾルバーからは数分から数十分間にわたり旧レコードが返される場合があります。TTL を 300 秒未満に設定しても実効的な意味がないケースが多いです。

短すぎる TTL による権威サーバー負荷

TTL を極端に短く設定すると（例: 60 秒）、世界中のリゾルバーからの問い合わせが頻繁に発生し、権威サーバーの負荷が増大します。変更作業時以外は 3600 秒以上に設定し、必要なときだけ下げる運用が望ましいです。

ネガティブキャッシュと SOA MINIMUM

存在しないドメインや存在しないレコードタイプへの問い合わせに対して、権威サーバーは NXDOMAIN（Non-Existent Domain）を返します。RFC 2308 は、このネガティブな応答のキャッシュ期間を SOA レコードの MINIMUM フィールドと SOA 自体の TTL の小さい方で決定すると定めています。

; SOA レコードのネガティブ TTL（MINIMUM フィールド）
example.com.  IN  SOA  ns1.example.com. admin.example.com. (
                        2024010101  3600  900  604800  300 )
;                                                         ^^^
;                                                    MINIMUM = 300秒

この仕組みにより、「ドメインが存在しない」という情報もキャッシュされ、存在しないドメインへの大量クエリがネームサーバーを圧迫することを防いでいます。

適切な値の目安

TTL の適正値はレコードの種類と変更頻度によって異なります。

レコードの用途	推奨 TTL	理由
変更作業前の事前設定	300（5 分）	変更が早く反映されるよう事前に短縮する
A レコード（動的環境）	300〜600	フェイルオーバーや IP 変更に素早く対応したい
A レコード（安定環境）	3600（1 時間）	標準的な運用値
CNAME レコード	3600〜86400	変更頻度が低く、キャッシュ効率を優先する
MX レコード	3600〜86400	メール配送に影響するため慎重に
NS レコード	86400（24 時間）	ゾーン委任の変更は稀
TXT レコード（SPF/DKIM）	3600〜86400	認証情報は頻繁に変わらない

多くの ISP は 300 秒未満の TTL を無視して独自の期間でキャッシュします。Cloudflare の調査では、実際に観測されたキャッシュ期間が設定 TTL を大幅に超えるケースが報告されています。このため、60 秒や 30 秒の TTL を設定しても実効的な効果が薄い場合があります。

DNS 変更前の TTL 短縮手順

DNS レコードを変更する際、事前に TTL を下げることで影響を最小化できます。

# Step 1: 変更の 24〜48 時間前に TTL を 300 秒に下げる
# （旧 TTL が 86400 なら、その期間が経過するまで短縮が反映されない）
example.com.   300  IN  A  93.184.216.34   ; 旧 IP、TTL を 5 分に

# Step 2: TTL 短縮が伝搬したことを確認してから IP を変更する
example.com.   300  IN  A  198.51.100.1    ; 新 IP

# Step 3: 新 IP への切り替えが確認できたら TTL を元に戻す
example.com.  3600  IN  A  198.51.100.1   ; 新 IP、TTL を 1 時間に

この手順の核心は「TTL を下げてから最低でも旧 TTL の時間だけ待つ」ことです。旧 TTL が 86400 秒なら、短縮前に 24 時間キャッシュしているリゾルバーが存在します。それが期限切れになる前に変更を行っても、リゾルバーは 24 時間経過後に旧 TTL でキャッシュされた古い値を参照し続けます。