DNS TTLキャッシュ

計算式と考え方

TTL（Time To Live）は、DNSの応答をリゾルバがキャッシュしてよい秒数です。TTLが3600秒なら、レコードを変更しても最大1時間は古い情報が使われます。切替時のダウンタイムを短くするには、事前にTTLを下げておく必要があります。ただしTTLの変更自体が全体に行き渡るまでには、変更前のTTLの時間（この例では1時間）がかかるため、切替の少なくとも旧TTLの時間より前に下げておく必要があります。権威サーバーへの問い合わせ数は「リゾルバ数 × (86,400 ÷ TTL)」が上限で、リゾルバ2万件ならTTL3600秒で48万回、60秒で2,880万回にあたります。ただし実際の問い合わせは、キャッシュがまったく効かない場合の問い合わせ数を超えることはありません。1日500万回のアクセスなら、TTL3600秒では48万回（キャッシュヒット率90.4%）、TTL60秒では500万回（ヒット率0%）まで増える、という頭打ちのある増え方になります。

TTLの設定の目安

DNS TTLキャッシュの詳しい解説

DNSのTTLは、名前解決の結果をどれだけの時間キャッシュしてよいかを指定する値です。長く設定すれば問い合わせ回数が減り、権威サーバーの負荷とコストが下がり、応答も速くなります。短く設定すれば変更の反映が速くなる一方、問い合わせ回数が増えます。このトレードオフを、運用の状況に応じて使い分けるのが実務の基本です。サーバーの移行やIPアドレスの変更を予定している場合、事前にTTLを下げておく手順が定石です。ここで見落とされやすいのが、TTLの変更自体もDNSレコードの変更であり、それが全体に行き渡るまでには変更前のTTLの時間がかかるという点です。TTLが86400秒（1日）に設定されている状態で切替の直前にTTLを60秒に変更しても、既にキャッシュしているリゾルバには最大1日間その変更が伝わりません。したがって、少なくとも旧TTLの時間よりも前に、余裕を持ってTTLを下げておく必要があります。実務上は切替の2〜3日前に下げることが推奨されます。TTLを短くする期間のコストにも注意が必要です。マネージドDNSサービスは問い合わせ数に応じた従量課金であることが多く、TTLを60分の1にすれば問い合わせ数は理論上60倍になります。大規模なサービスでは無視できない金額になるため、短いTTLの期間は必要最小限にとどめ、切替後の安定を確認したら元に戻すという運用が合理的です。TTLが必ず守られるとは限らない点も理解しておくべきです。一部のリゾルバやクライアントは独自のキャッシュ方針を持ち、指定より長く保持することがあります。ブラウザやOSにも独立したキャッシュがあり、これらはTTLを短くしても即座には切り替わりません。このため、切替時には旧環境をしばらく稼働させたまま並行運用し、アクセスが完全に新環境へ移ったことを確認してから旧環境を停止するという手順が安全です。ネガティブキャッシュ（存在しないという応答のキャッシュ）にも別のTTLが適用され、SOAレコードの設定に依存する点も、設定漏れが起きやすい箇所です。

業界・現場での使い方

よくある間違い・注意点

• 切替直前にTTLを下げる — 変更が行き渡るまで旧TTLの時間がかかります。2〜3日前に下げてください。
• 短いTTLのまま運用を続ける — 問い合わせ数が増え費用がかさみます。切替後は元に戻してください。
• TTLが必ず守られると考える — 独自のキャッシュ方針を持つリゾルバがあります。旧環境の並行稼働が安全です。

関連する規格・法規

• 電気通信事業法
• IETF規格

※本ツールは公的基準に基づく参考計算です。実際の設計・施工・法令適用は最新の告示・規格および所轄官庁の判断に従ってください。

よくある質問（FAQ）

関連計算ツール