DNS キャッシュ

Q: DNS キャッシュ とは？

リゾルバーまたはクライアントによる DNS クエリ結果の一時的な保存により、繰り返しの検索が高速化されます。

DNSキャッシュとは?

DNSキャッシュとは、リゾルバー、オペレーティングシステム、ブラウザ、およびアプリケーションがDNSクエリ結果を一時保存する機能です。DNSルックアップが実行されると、結果は記録のTTL（Time To Live）で定義された期間キャッシュされ、後続の同じドメインへのリクエストは、権威サーバーに問い合わせることなくキャッシュから即座に応答を得られます。

DNSキャッシュが重要な理由

キャッシュなしでは、すべてのウェブリクエストが完全なDNSルックアップを必要とし、レイテンシーが増加し、膨大なDNSトラフィックが発生します。DNSキャッシュは以下を提供します:

応答速度の向上: キャッシュされた応答はマイクロ秒単位で返され、完全なルックアップはミリ秒単位です
ネットワークトラフィック削減: 権威サーバーへのクエリが少なくなります
改善された耐性: DNSサーバーが一時的に利用不可の場合でも、ローカルキャッシュが応答を提供します
サーバー負荷低減: 権威サーバーがより少ないクエリを処理します

DNSキャッシュの仕組み

キャッシング階層

DNSキャッシュは複数のレベルで行われます:

ブラウザキャッシュ（秒～分単位） ↓ OSキャッシュ（秒～分単位） ↓ ローカルリゾルバーキャッシュ（分～時間単位） ↓ ISPリゾルバーキャッシュ（分～時間単位） ↓

権威ネームサーバー（信頼できる情報源）

キャッシュルックアッププロセス

1. ユーザーがリクエスト example.com

2. ブラウザがキャッシュをチェック

3. ミスの場合、OSがキャッシュをチェック

4. ミスの場合、リゾルバーがキャッシュをチェック

5. ミスの場合、権威サーバーへの再帰クエリ

6. 各レベルでTTLに基づいて結果がキャッシュされます

7. ユーザーに応答が返されます

TTLベースの有効期限

各DNSレコードにはTTL値が含まれます:

example.com.    300    IN    A    203.0.113.50
                ^^^
                TTL（秒単位）（5分）

キャッシュは300秒間このレコードを保存した後、破棄します。次のクエリで新しいルックアップがトリガーされます。

DNSキャッシュレイヤー

ブラウザキャッシュ

モダンブラウザはDNS結果を独立してキャッシュします:

Chrome: 独自のDNSキャッシュを使用（chrome://net-internals/#dns） Firefox: 内部キャッシュを保持（about:networking#dns） Safari: システムリゾルバーを使用

通常のブラウザキャッシュTTL: 60秒（DNSのTTLに関わらず）

オペレーティングシステムキャッシュ

Windows: DNSクライアントサービスがキャッシュを保存 macOS: mDNSResponderがキャッシュを処理 Linux: 通常systemd-resolvedです

リゾルバーキャッシュ

再帰DNSリゾルバー（ISP DNS、8.8.8.8、1.1.1.1）は数百万ユーザーに対応する大規模キャッシュを保有しています。

キャッシュ動作の例

通常の動作

クエリ1: example.com → 完全なルックアップ: 50ms → 300秒間キャッシュされます（TTL）クエリ2: example.com（1分後） → キャッシュヒット: 1ms クエリ3: example.com（10分後） → キャッシュ有効期限切れ、完全なルックアップ: 50ms

→ 300秒間再度キャッシュされます

DNSレコード更新

元のレコード: example.com → 203.0.113.50（TTL: 300秒）時刻: 10:00 - DNSが203.0.113.51に更新されますクライアントが10:02時点でクエリ → まだキャッシュ中: 203.0.113.50（10:05で有効期限切れ）クライアントが10:06時点でクエリ → キャッシュ有効期限切れ、新しいルックアップ: 203.0.113.51

→ 10:11までキャッシュされます

TTL戦略とキャッシング

TTL値の選択

ユースケース	推奨TTL	理由
静的インフラ	3600～86400秒（1～24時間）	ほぼ変わらず、DNS負荷を軽減
本番Webサイト	300～1800秒（5～30分）	パフォーマンスと柔軟性のバランス
アクティブな移行	60～300秒（1～5分）	変更時の伝播が速い
ロードバランシング	60～120秒	サーバー変更時の高速フェイルオーバー

移行前のTTL削減

DNS変更を計画する際のベストプラクティス:

7日前: example.com TTL 3600秒（1時間） 2日前: 300秒（5分）に削減変更日: DNS変更を実施 → 最大キャッシュ保持は5分

1日後: TTLを3600秒に戻す

キャッシュポイズニングとセキュリティ

DNSキャッシュポイズニング攻撃

攻撃者は偽のDNSレコードをキャッシュに注入しようとします:

1. 攻撃者がリゾルバーに偽の応答を送信

2. 保留中のクエリに一致した場合、キャッシュに保存

3. ユーザーは正当なドメイン用の悪意あるIPを受け取ります

4. キャッシュされた毒が多くのユーザーに提供されます

セキュリティ対策

DNSSEC: 暗号化署名されたレコードで毒を防止 送信元ポートランダム化: 応答を偽造しづらくします 0x20エンコーディング: クエリのランダムなケースで検証を支援 リゾルバーセキュリティ: Cloudflare、Google、Quad9などの信頼できるリゾルバーを使用

DNSキャッシュのチェック

キャッシュ内容の表示

Windows:

ipconfig /displaydns | more

macOS（情報限定）:

sudo killall -INFO mDNSResponder

# Console.appでログをチェック

Linux (systemd-resolved):

sudo systemd-resolve --statistics

キャッシュ動作のテスト

# 最初のクエリ（キャッシュミス） time dig example.com # 即座に繰り返し（キャッシュヒット） time dig example.com

# 時間を比較

キャッシュ関連の問題

DNS変更後のスタイルキャッシュ

問題: 更新されたDNSレコードがユーザーに反映されない 解決策:

1. TTLの有効期限が切れるまで待機

2. 将来の変更前にTTLを削減

3. ユーザーにローカルキャッシュをクリアするよう依頼

過度にアグレッシブなキャッシング

一部のISPはTTLを無視して長期間キャッシュします:

問題: DNS変更が数時間～数日かかって伝播 解決策:

より低いTTLを使用（ISPは通常300秒の最小値を尊重）
クリティカルサービス用にanycast DNSを検討
問題のあるISPを文書化

DNSキャッシュのクリア

クリアの時期

DNS変更をすぐにテストする
解決の問題をトラブルシューティング
DNS プロバイダーの移行後
疑わしいキャッシュポイズニング

クリアの方法

Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Chrome:

Navigate to: chrome://net-internals/#dns

Click: "Clear host cache"

Firefox:

Toggle network.dnsCacheExpiration in about:config

またはブラウザを再起動

ベストプラクティス

1. 適切なTTLを設定: パフォーマンスと変更速度のバランス

2. 変更前にTTLを削減: DNS更新の24～48時間前にTTLを低下

3. 伝播を監視: グローバルなDNS解決チェック用ツール

4. キャッシュ動作を文書化: インフラのキャッシング層を理解

5. DNSSECを使用: キャッシュポイズニングから保護

6. 徹底的にテスト: DNS変更が期待通り動作することを確認

7. ユーザーに説明: キャッシュクリアが必要な場合に指示を提供

DNSキャッシュはインターネットパフォーマンスの基本です。TTLを適切に理解し、設定することで、DNS変更が効率的に伝播し、最小限の中断で高速解決時間が保たれます。