DNS

DNS TTL設計の勘所でぃーえぬえすてぃーてぃーえるせっけいのかんどころ

TTLDNSキャッシュ名前解決障害対応切り替え

DNS TTL設計の勘所について教えて

簡単に言うとこんな感じ！

TTLは「この住所情報、何秒間は信じていいよ」という有効期限のことだよ。長すぎると変更がなかなか反映されないし、短すぎるとDNSサーバーへの問い合わせが激増して重くなる。切り替えの予定があるなら事前に短くしておくのがプロの技なんだ！

DNS TTL設計の勘所とは

TTL（Time to Live） とは、DNSのレコードがキャッシュ（一時保存）される時間を秒単位で指定する値のことです。DNSは「ドメイン名→IPアドレス」への変換を担う仕組みですが、毎回権威DNSサーバーに問い合わせるとネットワーク負荷が大きいため、各リゾルバー（問い合わせを中継するサーバー）は一定時間その答えをキャッシュしています。TTLはそのキャッシュの「鮮度期限」にあたります。

TTL設計は、「速さ・安定性・変更のしやすさ」のトレードオフ を意識することがポイントです。日常運用では長め（1時間〜1日）にしてDNSサーバーの負荷を下げつつ、サーバー移行やサービス切り替えの直前だけ短め（60〜300秒）に変更しておくというのが、現場で広く使われるアプローチです。設定を間違えると「IPを変えたのにユーザーが古いサーバーにアクセスし続ける」という事態が発生します。

TTL値の設計指針

TTL値は短すぎても長すぎても問題が起きます。以下の表を参考に、用途ごとの目安を押さえましょう。

用途・状況	推奨TTL	理由
通常運用（安定稼働中）	3600〜86400秒（1時間〜1日）	キャッシュ効果で負荷を下げる
切り替え・移行の直前	60〜300秒（1〜5分）	変更をすぐ反映できるようにする
切り替え・移行の直後（安定したら）	3600秒以上に戻す	負荷軽減のため通常値へ
CDNやロードバランサー配下	60〜300秒	フェイルオーバーに備えて短め
メールのMXレコード	3600秒前後	頻繁に変わらないが長すぎも危険
ネガティブキャッシュ（SOAのminimum）	300〜600秒	存在しないドメインのキャッシュ期間

TTL変更のタイミング設計（移行前後のサイクル）

サーバー移行やIP切り替えを行う場合、以下のサイクルで進めるのが定石です。

【移行前 1〜2日前】
  通常TTL（例: 86400秒）のまま運用中
       ↓
【移行 24〜48時間前】
  TTLを短く変更（例: 300秒）
  → 既存キャッシュが古いTTLで残るため、即時には効かない
  → 古いTTLが切れるまで待つ必要あり
       ↓
【移行当日】
  DNSレコード（Aレコードなど）のIPアドレスを新しい値に変更
  → TTLが300秒なら最大5分で全リゾルバーに反映
       ↓
【移行後・安定確認したら】
  TTLを通常値（例: 3600〜86400秒）に戻す

ネガティブキャッシュも忘れずに

「このドメインは存在しない（NXDOMAIN）」という否定応答も、SOAレコードのminimumフィールド で指定した時間だけキャッシュされます。これを「ネガティブキャッシュ」と呼び、RFC 2308 で定義されています。新しいサブドメインを追加した直後になかなか名前解決できないのは、このネガティブキャッシュが原因のことがあります。

歴史と背景

1983年 — DNSの原型がARPANETで設計される。当初は /etc/hosts を全サーバーで手動配布していた時代の課題解決として生まれた
1987年 — RFC 1034・RFC 1035 にてDNSの基本仕様が標準化され、TTLの概念も正式に定義された
1990年代〜2000年代 — インターネットの爆発的普及に伴い、DNSキャッシュの重要性が増大。TTL設計が運用の現場課題として意識され始める
1998年 — RFC 2308 でネガティブキャッシュが標準化。NXDOMAINのキャッシュ期間もTTLで制御できるように整備
2010年代〜 — クラウドサービスやCDNの普及により、IPアドレスが頻繁に変わる環境が一般化。短いTTLでの運用ニーズが急増
現在 — DNSSECや低TTL設計はセキュリティ・可用性の観点からも再評価されており、クラウドネイティブ環境では60秒以下のTTLが珍しくない

TTLと関連技術の関係

TTL設計はDNS単体の話にとどまらず、クラウド・CDN・メール配送など多くの周辺技術と絡み合っています。

TTL短縮のタイムラグに注意

TTLを短く変更しても、すでに長いTTLでキャッシュされている場合はその期限が切れるまで効果がありません。たとえばTTL=86400秒（24時間）で設定中にTTL=300秒へ変更しても、各リゾルバーが古いキャッシュを保持している間は最大24時間かかります。これが「移行の24〜48時間前にTTLを短縮すべき」とされる理由です。

TTLが短すぎるリスク

リスク	説明
DNSサーバーへの負荷増大	キャッシュがすぐ切れるため問い合わせが頻発する
応答遅延	毎回権威サーバーへ問い合わせるとレスポンスが遅くなる場合がある
コスト増加	クラウドDNS（Route 53など）は問い合わせ件数で課金されることが多い

規格・RFC番号	内容
RFC 1034	DNS概念と機能の定義。TTLの基本仕様を規定
RFC 1035	DNSの実装と仕様。レコードフォーマット・TTLフィールドの詳細
RFC 2308	DNSネガティブキャッシュの標準化。NXDOMAINのキャッシュ期間を規定
RFC 8767	TTL期限切れキャッシュの「使い続け（serve-stale）」動作の標準化
RFC 4035	DNSSECのリソースレコード署名とTTLの関係を規定