プロトコル & 標準

DNS キャッシュ

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

DNSキャッシュとは

DNSキャッシュは、リゾルバー、OS、ブラウザー、アプリケーションがDNS問い合わせの結果を一時保存する仕組みです。DNS検索の結果はレコードのTTL(Time To Live)で定めた期間保存され、同じドメインへの後続リクエストには権威サーバーへ再問い合わせせず即座に応答できます。

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

キャッシュがなければ、すべてのウェブリクエストで完全なDNS検索が必要となり、遅延と大量のDNSトラフィックが発生します。DNSキャッシュには次の利点があります。

  • 応答が速い: キャッシュ済みの応答は、完全検索のミリ秒に対してマイクロ秒で返る
  • ネットワークトラフィックを減らす: 権威サーバーへの問い合わせが少なくなる
  • 耐障害性を高める: DNSサーバーに一時的に到達できなくてもローカルキャッシュが応答する
  • サーバー負荷を下げる: 権威サーバーが処理する問い合わせが減る

DNSキャッシュの仕組み

キャッシュ階層

DNSキャッシュは複数の層で行われます。

Browser Cache (seconds to minutes)

↓

OS Cache (seconds to minutes)

↓

Local Resolver Cache (minutes to hours)

↓

ISP Resolver Cache (minutes to hours)

↓

Authoritative Name Server (source of truth)

キャッシュ検索の流れ

1. 利用者が要求: example.com

2. ブラウザーが確認: 自分のキャッシュ

3. ミスならOSが確認: OSのキャッシュ

4. ミスならリゾルバーが確認: リゾルバーのキャッシュ

5. ミスなら再帰問い合わせ: 権威サーバーへ問い合わせる

6. 結果をキャッシュ: TTLに基づき各層に保存する

7. 応答を返す: 利用者へ返す

TTLによる有効期限

各DNSレコードにはTTL値があります。

example.com.    300    IN    A    203.0.113.50

^^^

TTL in seconds (5 minutes)

キャッシュはこのレコードを300秒保存してから破棄します。次の問い合わせで新しい検索が始まります。

DNSキャッシュの層

ブラウザーキャッシュ

現代のブラウザーはDNS結果を独自にキャッシュします。

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

一般的なブラウザーキャッシュTTLは60秒です(DNS TTLとは無関係)。

OSキャッシュ

Windows: DNS Clientサービスが結果をキャッシュします。
# View cache

ipconfig /displaydns

# Flush cache

ipconfig /flushdns

macOS: mDNSResponderがキャッシュを処理します。
# Flush cache (macOS 10.15+)

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux: システムによって異なり、systemd-resolvedがよく使われます。
# Flush systemd-resolved cache

sudo systemd-resolve --flush-caches

# Check statistics

sudo systemd-resolve --statistics

リゾルバーキャッシュ

再帰DNSリゾルバー(ISP DNS、8.8.8.8、1.1.1.1)は、多数の利用者に応答する大規模キャッシュを維持します。

リゾルバーキャッシュ戦略
Google (8.8.8.8)TTLを尊重、グローバルキャッシュ
Cloudflare (1.1.1.1)TTLを尊重、分散キャッシュ
ISP Resolvers短いTTLを無視する場合がある

キャッシュ動作の例

通常の動作

Query 1: example.com

→ Full lookup: 50ms

→ Cached for 300s (TTL)

Query 2: example.com (1 minute later)

→ Cache hit: 1ms

Query 3: example.com (10 minutes later)

→ Cache expired, full lookup: 50ms

→ Re-cached for 300s

DNSレコードの更新

Original: example.com → 203.0.113.50 (TTL: 300s)

Time: 10:00 - DNS updated to 203.0.113.51

Client queries at 10:02

→ Still cached: 203.0.113.50 (expires 10:05)

Client queries at 10:06

→ Cache expired, new lookup: 203.0.113.51

→ Cached until 10:11

TTL戦略とキャッシュ

TTL値を選ぶ

用途推奨TTL理由
静的基盤3600〜86400秒(1〜24時間)変更が少なくDNS負荷を減らせる
本番ウェブサイト300〜1800秒(5〜30分)性能と柔軟性のバランス
移行中60〜300秒(1〜5分)変更時の伝播を速める
負荷分散60〜120秒サーバー変更時に素早く切り替える

移行前のTTL低減

DNS変更を計画するときのベストプラクティスです。

Day -7: example.com TTL 3600s (1 hour)

Day -2: Reduce to 300s (5 minutes)

Day 0: Make DNS change

→ Max 5 minute cache retention

Day +1: Restore TTL to 3600s

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

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

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

1. 攻撃者が偽の応答でリゾルバーを大量に問い合わせる

2. 保留中の問い合わせと一致すればキャッシュされる

3. 利用者が正規ドメインの悪意あるIPを受け取る

4. 汚染されたキャッシュが多数の利用者に配信される

セキュリティ緩和策

DNSSEC: 暗号署名されたレコードで汚染を防ぎます。
example.com.    IN    A      203.0.113.50

IN RRSIG A 8 2 300 ...

送信元ポートのランダム化: 応答の偽造を難しくします。 0x20エンコード: 問い合わせの大文字・小文字をランダム化して検証を助けます。 リゾルバーのセキュリティ: Cloudflare、Google、Quad9など信頼できるリゾルバーを使います。

DNSキャッシュの確認

キャッシュ内容を表示する

Windows:
ipconfig /displaydns | more
macOS(限定的な情報):
sudo killall -INFO mDNSResponder

# Check Console.app for logs

Linux(systemd-resolved):
sudo systemd-resolve --statistics

キャッシュ動作をテストする

# First query (cache miss)

time dig example.com

# Immediate repeat (cache hit)

time dig example.com

# Compare times

キャッシュ関連の問題

DNS変更後の古いキャッシュ

問題: 更新したDNSレコードが利用者に反映されない 解決策:

1. TTLが切れるまで待つ

2. 今後の変更前にTTLを下げる

3. 利用者にローカルキャッシュの消去を依頼する

過度に強いキャッシュ

一部のISPはTTLを無視して長くキャッシュします。

問題: 変更の伝播に数時間から数日かかる 解決策:
  • TTLを下げる(ISPは通常300秒以上を尊重する)
  • 重要サービスではAnycast DNSを検討する
  • 問題のあるISPを記録する

ネガティブキャッシュ

失敗した検索(NXDOMAIN)もキャッシュされます。

Query: newsubdomain.example.com

Response: NXDOMAIN (does not exist)

Cached: 3600s (SOA minimum TTL)

Result: New subdomain won't resolve for 1 hour

解決策: 新しいレコードを追加する前にSOA最小TTLを下げます。

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

Or restart browser

ベストプラクティス

1. 適切なTTLを設定する: 性能と変更速度のバランスを取る

2. 変更前にTTLを下げる: DNS更新の24〜48時間前に下げる

3. 伝播を監視する: 世界各地のDNS解決を確認するツールを使う

4. キャッシュ動作を記録する: 基盤のキャッシュ層を理解する

5. DNSSECを使う: キャッシュポイズニングから守る

6. 十分にテストする: 成功と宣言する前にDNS変更を確認する

7. 利用者に知らせる: 必要時のキャッシュ消去方法を明確に案内する

高度なキャッシュ概念

プリフェッチ

ブラウザーやリゾルバーはページ内リンクのDNSを先読みすることがあります。

<!-- Hint to browser -->

<link rel="dns-prefetch" href="//cdn.example.com">

キャッシュウォーミング

ロードバランサーやCDNは重要レコードをあらかじめキャッシュすることがあります。

Anycastとキャッシュ

Anycast DNSは最寄りのサーバーへ問い合わせを送るため、性能に適した地理的分散キャッシュを作ります。

DNSキャッシュはインターネット性能の基盤です。TTLを理解して適切に設定することで、DNS変更を効率的に伝播させながら高速な名前解決を維持できます。

この知識を実践する

DomScan の API を使用してドメインの可用性、状態などを確認します。