DNS TTL値の理解
DNS TTL（Time to Live）の値がキャッシュ、伝播速度、パフォーマンスにどう影響するかを解説します。レコードタイプごとの推奨TTLを確認しましょう。
SOAService
Zone File Entry
example.com. 86400 IN SOA ns1.example.com. admin.example.com. (
2024010101 ; Serial
3600 ; Refresh
900 ; Retry
1209600 ; Expire
86400 ; Minimum TTL
)詳細な説明
DNS TTLとは？
TTL（Time to Live）は、DNSリゾルバが権威サーバーに再度問い合わせるまでレコードをキャッシュし続ける時間を秒単位で指定する値です。TTLはDNS変更の伝播速度と、ネームサーバーが受けるクエリ負荷に直接影響します。
ゾーンファイルレコードにおけるTTL
; TTLは2番目のフィールド（秒単位）
example.com. 3600 IN A 203.0.113.50 ; 1時間
example.com. 86400 IN NS ns1.example.com. ; 24時間
example.com. 300 IN TXT "v=spf1..." ; 5分
; ゾーンのデフォルトTTL（明示的なTTLのないレコードに適用）
$TTL 3600
TTLがDNS伝播に与える影響
DNSレコードを変更しても、古い値は以前に設定されたTTLの期間中、世界中のリゾルバにキャッシュされたままです。これがDNS変更が即座に反映されない理由です：
- TTL = 86400（24時間）：変更が完全に伝播するまで最大24時間かかる
- TTL = 3600（1時間）：変更は1時間以内に伝播
- TTL = 300（5分）：変更は5分以内に伝播
- TTL = 60（1分）：ほぼ即時の伝播だが、ネームサーバーへの負荷が増加
推奨TTL値
| レコードタイプ | 推奨TTL | 理由 |
|---|---|---|
| NS | 86400（24時間） | ネームサーバーはめったに変更されない |
| MX | 3600（1時間） | メールルーティングには適度な安定性が必要 |
| A / AAAA | 3600（1時間） | キャッシュと柔軟性の良いバランス |
| CNAME | 3600（1時間） | Aレコードと同様 |
| TXT（SPF/DKIM/DMARC） | 3600（1時間） | 変更頻度が低い |
| CAA | 3600（1時間） | 変更頻度が低い |
| SRV | 3600（1時間） | サービスエンドポイントは比較的安定 |
| SOA Minimum | 300〜3600 | ネガティブキャッシュ（NXDOMAIN）を制御 |
移行時のTTL戦略
DNS移行（例：新しいサーバーへの移行）を計画する場合：
- 48時間前：TTLを300秒に下げる
- 待機：古いTTLが期限切れになるのを待つ（すべてのキャッシュが新しい低TTLでリフレッシュされるように）
- 変更の実施：レコードを新しいIPに更新
- 変更後：5分以内にほとんどのリゾルバが新しい値を取得
- 確認後：TTLを3600以上に戻す
トレードオフ
低いTTL：
- 変更の伝播が速い
- フェイルオーバーシナリオに適している
- ネームサーバーへのクエリ量が増加
- 初回ルックアップのレイテンシがわずかに増加
高いTTL：
- クエリ量とネームサーバーの負荷が低い
- ユーザー体験が高速（キャッシュヒットが多い）
- 変更の伝播が遅い
- 設定ミスからの回復が困難
SOAレコードとネガティブTTL
SOA（Start of Authority）レコードのMinimum TTLフィールド（最後の数値）は、ネガティブキャッシュ、つまりリゾルバがレコードの不存在（NXDOMAIN）をキャッシュする期間を制御します。訪問者が存在しないサブドメインを問い合わせた場合、リゾルバはこの期間中ネガティブレスポンスをキャッシュします。
よくある間違い
- 移行前にTTLを高く設定したまま：86400から下げる場合、低いTTLが有効になる前にキャッシュが期限切れになるまで24時間待つ必要がある
- 本番環境で非常に低いTTL：60秒のTTLは、すべてのDNSクエリがネームサーバーにヒットすることを意味し、レイテンシとコストが増加
- 移行後のTTL引き上げ忘れ：TTLを300のまま永久に残すとリソースの無駄になる
ユースケース
DNSレコードに適切なTTL値を理解・設定して、変更の高速伝播と効率的なDNSキャッシュパフォーマンスのバランスを取ります。