DNS キャッシュと TTL｜基礎を学ぶ

DNS キャッシュと TTL

このレッスンで分かること

DNS は階層的にキャッシュされ、TTL で「何秒間キャッシュしてよいか」を制御します

「DNS の浸透」は実体としては「世界中のリゾルバのキャッシュが TTL 切れで更新される」現象

キャッシュ汚染対策には DNSSEC、DoT / DoH、ソースポートランダム化が組み合わされます

DNS キャッシュと TTL とは

TTL と DNS キャッシュの仕組み、運用上の注意点を理解します。本レッスンでは、DNS キャッシュと TTL の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

TTL 値の使い分け早見表

TTL	秒数	典型用途	切り替え反映
60	1 分	CDN の動的振り分け、リリース直前	最速
300	5 分	一般的なデフォルト	標準
3600	1 時間	安定運用中のレコード	やや遅
86400	24 時間	TXT 認証など長期固定	遅

DNS 切り替えの定番運用: 計画変更の数日前に TTL を 60 秒へ → 当日切替 → 安定後に TTL を元に戻す。

このレッスンで学ぶこと

DNS の効率と信頼性を支えるキャッシュと TTL の仕組みを学びます。「DNS の浸透」と呼ばれる現象の正体もここで理解しましょう。

なぜキャッシュが必要か

DNS は世界中で毎秒数億クエリ飛ぶシステムです。すべてのクエリをルートサーバーまで遡って解決していたら、ルートはすぐにパンクします。

そこで各層でキャッシュを使い、同じ問い合わせは TTL の間ローカルで応答します。

ブラウザキャッシュ — 数分
OS キャッシュ — TTL ベース
リゾルバキャッシュ — TTL ベース
権威サーバー — キャッシュではないが応答は最終回答

TTL の役割

TTL (Time To Live) は、レコードを何秒間キャッシュしてよいかをサーバーが指定する値です。秒単位です。

TTL	用途
60 (1 分)	頻繁に変更するレコード (CDN の負荷分散など)
300 (5 分)	一般的なデフォルト
3600 (1 時間)	あまり変えないレコード
86400 (24 時間)	長期固定 (TXT 認証など)

TTL が長いほどキャッシュ効率は高くなりますが、レコード変更時に「古い値が世界中に残る」時間も長くなります。

DNS の「浸透」という誤解

「DNS を変えたけど浸透していない」という言い方をよく聞きますが、これは正確には誤解を含みます。

実体は「世界中のリゾルバが古い値をキャッシュしている。TTL が切れるまで反映されない」だけで、波のように広がる現象ではありません。TTL を 5 分にしていれば、最大でも 5 分で全リゾルバが新値を引き直します。

この章のポイント

計画的な DNS 切り替え

DNS 変更を予定しているときは、事前に TTL を 60 秒に下げておきます。実際の切り替え時には、最大でも 1 分で新しいレコードに切り替わります。切り替え完了後は TTL を元の長い値に戻すのが定番運用です。

ネガティブキャッシュ

「存在しない」という応答もキャッシュされます。NXDOMAIN 応答はネガティブキャッシュとして保持され、SOA レコードの MINIMUM TTL の値だけ持続します。

タイポしたドメインを引いた結果が残り、サーバー側でレコードを後から作っても、しばらく「ない」が返り続けることがあります。

キャッシュ汚染対策

過去には DNS キャッシュポイズニング (Kaminsky 攻撃) という、悪意のあるサーバーが嘘の応答を返してキャッシュを汚染する攻撃が話題になりました。

対策としては下記が広まっています。

ソースポートランダム化 — 問い合わせの送信元ポートを毎回ランダム化
DNSSEC — DNS 応答に署名を付けて改ざんを検知
DoT / DoH — 経路自体を暗号化

DNSSEC は技術としては優秀ですが、運用負荷の高さから普及はゆっくりしています。

ブラウザの DNS キャッシュを覗く

開発中に DNS を変えたのに反映されない場合、ブラウザや OS のキャッシュをクリアします。

Chrome — chrome://net-internals/#dns で Clear host cache
macOS — sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux (systemd-resolved) — sudo resolvectl flush-caches
Windows — ipconfig /flushdns

TTL のトレードオフ

短い TTL のメリット・デメリットを整理しておきましょう。

メリット — 変更の反映が速い、トラフィック振り分けを柔軟にできる (Geo DNS など)
デメリット — 問い合わせ回数が増え、リゾルバや権威サーバーに負荷がかかる

実運用では「普段は 1 時間、リリース直前だけ 60 秒」のように動的に切り替える運用がよく取られます。

この章のポイント

CDN の TTL は短いほうが普通

Cloudflare や CloudFront などの CDN を使うと、A レコードの TTL は 60 秒〜数分にされていることが多いです。これは CDN 側で配信エッジの IP を動的に切り替えるためで、ユーザー側からはアクセスごとに最適なエッジ IP に振られています。

まとめ

このレッスンの要点は、多層キャッシュと TTL / DNS の浸透の正体 / キャッシュ汚染対策 の 3 点です。実務でこれらを切り分けて説明できるようになると、設計レビューや障害対応の精度が一段上がります。

理解度チェック

Q. DNS レコードを変更する 1 時間前に行うべき準備として最適なのは？

TTL を 24 時間に伸ばす
TTL を 60 秒など短く下げておく
DNSSEC を無効にする
DNS プロバイダを切り替える

答えを見る

正解は 2。切替前に TTL を短くしておけば、世界中のリゾルバのキャッシュが短時間で期限切れになり、変更後の反映が最大でも TTL 秒以内に済みます。安定したら TTL を元に戻すのが定番。

出典 (References)

最終更新: 2026-05-28

よくある質問

Q. DNS のキャッシュ TTL は何分が適切？

A. 通常は 3600 秒（1 時間）程度が一般的です。IP を頻繁に変えるサービスは 60 秒など短く、安定したサービスは 86400 秒（1 日）でも問題ありません。ドメイン移行直前は数分まで下げ、切替後に戻すという運用が定番です。

Q. A レコードと CNAME の違いは？

A. A は直接 IP アドレスを返し、CNAME は別のドメイン名にエイリアスします。ALIAS / ANAME と呼ぶ DNS 業者は CNAME の制限（ZONE apex で使えない）を緩和してくれます。インフラ移行のしやすさを考えるなら CNAME を活用しましょう。

Q. 名前解決が遅いとき何を疑うべきですか？

A. DNS サーバーへの到達遅延、再帰問い合わせの段数、TTL 切れによるリクエスト集中などが原因です。dig や nslookup でクエリ時間を計測し、必要なら Cloudflare DNS や Google Public DNS など低遅延のレゾルバに切り替えると改善します。

次のレッスン

次は CDN の仕組みと Anycast で、TTL と DNS キャッシュの仕組み、運用上の注意点を理解しますを学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

DNS キャッシュ/TTL の要点を自分の言葉で説明できる
このレッスンの最小コード (または操作手順) を見ずに書ける
練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. DNS キャッシュ/TTL とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン