DNSキャッシュとTTLの仕組みを理解する

前回の記事では、DNSの基本的な仕組みとして名前解決の流れやDNSレコードの種類について解説しました。本記事では、DNS通信の効率化に欠かせないDNSキャッシュとTTL（Time To Live）について詳しく解説します。

ドメインのDNS設定を変更した際に「反映されるまで時間がかかる」という経験をしたことがある方も多いでしょう。この現象はDNSキャッシュとTTLの仕組みを理解することで、その原因と対処法が明確になります。

本記事では、DNSキャッシュとTTLについて以下の内容を解説します。

• DNSキャッシュの仕組みと各階層でのキャッシュの役割
• TTL（Time To Live）の概念と設定値の考え方
• DNS伝播の仕組みと遅延が発生する理由
• 各OS・ブラウザでのDNSキャッシュクリア方法
• DNSキャッシュに関するトラブルシューティング

この記事を読むことで、DNSキャッシュの動作を正しく理解し、DNS関連のトラブルに適切に対処できるようになります。

前提条件

本記事を理解するために、以下の知識があることを前提としています。

• DNSの基本的な仕組みを理解している（前回記事参照）
• DNSレコードの種類（A、AAAA、CNAMEなど）を把握している
• コマンドプロンプトやターミナルの基本操作ができる

実行環境

DNSキャッシュの確認やクリア操作には以下の環境を使用します。

特別なソフトウェアのインストールは不要です。管理者権限でコマンドを実行する場面があります。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

1. DNSキャッシュが存在する各階層と役割を説明できる
2. TTLの概念を理解し、適切な設定値を判断できる
3. DNS伝播の遅延が発生する理由を説明できる
4. 各OS・ブラウザでDNSキャッシュをクリアできる
5. DNSキャッシュに起因するトラブルを診断・解決できる

DNSキャッシュとは

DNSキャッシュとは、過去に行ったDNS問い合わせの結果を一時的に保存しておく仕組みです。同じドメインに対する問い合わせを繰り返す際に、キャッシュから応答することで名前解決の高速化とDNSサーバーの負荷軽減を実現します。

graph LR
    subgraph "キャッシュなし"
        A1["クライアント"] -->|"毎回問い合わせ"| B1["DNSサーバー"]
    end
    
    subgraph "キャッシュあり"
        A2["クライアント"] -->|"1回目: 問い合わせ"| B2["DNSサーバー"]
        A2 -->|"2回目以降: キャッシュ参照"| C2["ローカルキャッシュ"]
    end
    
    style A1 fill:#e3f2fd
    style A2 fill:#e3f2fd
    style B1 fill:#fff3e0
    style B2 fill:#fff3e0
    style C2 fill:#e8f5e9

DNSキャッシュのメリット

DNSキャッシュによって得られる主なメリットは以下のとおりです。

DNSキャッシュのデメリット

一方で、DNSキャッシュには以下のようなデメリットも存在します。

DNSキャッシュの階層構造

DNSキャッシュは複数の階層に存在し、それぞれが独立して動作しています。名前解決の際には、より近い階層から順にキャッシュが参照されます。

graph TB
    subgraph "クライアント側"
        APP["アプリケーション<br/>（ブラウザ）"]
        OS["OS<br/>（スタブリゾルバ）"]
    end
    
    subgraph "ネットワーク側"
        ROUTER["ルーター/ゲートウェイ"]
        ISP["ISPのDNSサーバー<br/>（フルサービスリゾルバ）"]
    end
    
    subgraph "インターネット側"
        PUBLIC["パブリックDNS<br/>（8.8.8.8等）"]
        AUTH["権威DNSサーバー"]
    end
    
    APP -->|"1. ブラウザキャッシュ確認"| OS
    OS -->|"2. OSキャッシュ確認"| ROUTER
    ROUTER -->|"3. ルーターキャッシュ確認"| ISP
    ISP -->|"4. リゾルバキャッシュ確認"| PUBLIC
    PUBLIC -->|"5. キャッシュになければ"| AUTH
    
    style APP fill:#e3f2fd
    style OS fill:#e3f2fd
    style ROUTER fill:#fff3e0
    style ISP fill:#fff3e0
    style PUBLIC fill:#e8f5e9
    style AUTH fill:#e8f5e9

各階層のDNSキャッシュ

ブラウザのDNSキャッシュ

主要なブラウザは独自のDNSキャッシュを持っています。これはブラウザのパフォーマンス向上のためであり、OSのDNSキャッシュとは独立して動作します。

Chrome系ブラウザでは、内部ページにアクセスすることでDNSキャッシュの内容を確認し、クリアすることができます。

OSのDNSキャッシュ

OSレベルのDNSキャッシュは、システム全体のアプリケーションで共有されます。

Windows

Windowsでは、DNS Client サービスがDNSキャッシュを管理しています。

1
2
3
4
5

# キャッシュの内容を表示
ipconfig /displaydns

# キャッシュをクリア
ipconfig /flushdns

実行結果の例を示します。

Windows IP 構成

    www.example.com
    ----------------------------------------
    レコード名 . . . . . : www.example.com
    レコードの種類. . . . : 1
    Time To Live. . . . . : 86400
    データの長さ. . . . . : 4
    セクション. . . . . . : 応答
    A (ホスト) レコード . : 93.184.216.34

macOS

macOSでは、mDNSResponderがDNSキャッシュを管理しています。

1
2
3
4
5
6
7

# キャッシュをクリア（macOS 10.12以降）
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# キャッシュ統計を表示
sudo killall -INFO mDNSResponder
# 結果はコンソールアプリで確認

Linux（systemd-resolved）

systemd-resolvedを使用しているLinuxディストリビューションでは、以下のコマンドを使用します。

1
2
3
4
5
6
7
8

# キャッシュ統計を表示
resolvectl statistics

# キャッシュをクリア
resolvectl flush-caches

# または（古いバージョン）
sudo systemd-resolve --flush-caches

TTL（Time To Live）とは

TTL（Time To Live）は、DNSレコードがキャッシュに保持される時間を秒単位で指定する値です。権威DNSサーバーで各レコードに設定され、キャッシュDNSサーバーやクライアントはこの値に従ってキャッシュを管理します。

sequenceDiagram
    participant Client as クライアント
    participant Resolver as キャッシュDNS
    participant Auth as 権威DNS
    
    Client->>Resolver: www.example.comは？
    Resolver->>Auth: www.example.comは？
    Auth-->>Resolver: 93.184.216.34（TTL: 3600秒）
    
    Note over Resolver: キャッシュに保存<br/>有効期限: 3600秒
    
    Resolver-->>Client: 93.184.216.34
    
    Note over Client,Resolver: 3600秒以内の問い合わせ
    
    Client->>Resolver: www.example.comは？
    Resolver-->>Client: 93.184.216.34（キャッシュから応答）
    
    Note over Client,Resolver: 3600秒経過後
    
    Client->>Resolver: www.example.comは？
    Resolver->>Auth: www.example.comは？（再問い合わせ）

TTLの仕組み

TTLはカウントダウン形式で動作します。DNSレコードがキャッシュされた時点からTTLの値が減少していき、0になるとキャッシュが無効になります。

digコマンドを使用すると、残りのTTL値を確認できます。

1
2
3
4
5
6

dig www.example.com

# ANSWER SECTIONのTTL値（秒）を確認
# www.example.com.  3521  IN  A  93.184.216.34
#                   ^^^^
#                   残りTTL

TTL値の設定指針

TTLの設定値は、DNS変更の頻度とパフォーマンスのバランスを考慮して決定します。

TTL設定のトレードオフ

TTLの値を決める際には、以下のトレードオフを理解しておく必要があります。

一般的なTTL推奨値

多くのDNSホスティングサービスでは、以下のようなTTL値がデフォルトまたは推奨として設定されています。

DNS伝播（プロパゲーション）の仕組み

DNS伝播とは、権威DNSサーバーで変更されたDNSレコードが、世界中のキャッシュDNSサーバーに反映されていくプロセスを指します。

DNS伝播の流れ

graph TB
    subgraph "変更直後"
        AUTH1["権威DNS<br/>新IP: 203.0.113.10"]
        CACHE1["キャッシュDNS A<br/>旧IP: 93.184.216.34<br/>TTL残り: 1800秒"]
        CACHE2["キャッシュDNS B<br/>旧IP: 93.184.216.34<br/>TTL残り: 600秒"]
    end
    
    subgraph "10分後"
        AUTH2["権威DNS<br/>新IP: 203.0.113.10"]
        CACHE3["キャッシュDNS A<br/>旧IP: 93.184.216.34<br/>TTL残り: 1200秒"]
        CACHE4["キャッシュDNS B<br/>新IP: 203.0.113.10<br/>キャッシュ更新済み"]
    end
    
    style AUTH1 fill:#e8f5e9
    style AUTH2 fill:#e8f5e9
    style CACHE1 fill:#ffcdd2
    style CACHE2 fill:#fff3e0
    style CACHE3 fill:#ffcdd2
    style CACHE4 fill:#e8f5e9

DNS伝播に時間がかかる理由

DNS伝播が即座に完了しない理由は以下のとおりです。

DNS伝播の所要時間

一般的なDNS伝播の所要時間は、設定されているTTLに依存します。

実際には、ネガティブキャッシュやブラウザキャッシュの影響で、理論値より長くなることがあります。

DNS伝播を高速化するためのベストプラクティス

DNS設定の変更を計画している場合は、以下のプラクティスを実践することで伝播時間を短縮できます。

graph LR
    A["変更1週間前<br/>TTLを短縮<br/>（300秒）"] --> B["変更実施<br/>DNSレコード更新"]
    B --> C["確認完了後<br/>TTLを元に戻す"]
    
    style A fill:#fff3e0
    style B fill:#e8f5e9
    style C fill:#e3f2fd

1. 事前にTTLを短縮する: 変更予定の1-2週間前にTTLを300秒程度に短縮
2. DNSレコードを変更する: 短いTTLの状態でレコードを更新
3. 伝播を確認する: 複数の場所からDNSの解決結果を確認
4. TTLを元に戻す: 伝播完了後、TTLを適切な値に戻す

DNSキャッシュのクリア方法

DNSキャッシュに起因する問題を解決するため、各環境でのキャッシュクリア方法を解説します。

Windows

1
2
3
4
5
6
7
8

# 管理者権限でコマンドプロンプトを開く

# DNSキャッシュをクリア
ipconfig /flushdns

# 実行結果
# Windows IP 構成
# DNSリゾルバー キャッシュは正常にフラッシュされました。

macOS

1
2
3
4
5

# macOS Monterey (12) 以降
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# 実行結果を確認（コンソールアプリで確認可能）

Linux

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# systemd-resolved を使用している場合
sudo resolvectl flush-caches

# または
sudo systemd-resolve --flush-caches

# nscd を使用している場合
sudo systemctl restart nscd

# dnsmasq を使用している場合
sudo systemctl restart dnsmasq

ブラウザのDNSキャッシュクリア

Chromeでの操作例を示します。

1. アドレスバーに chrome://net-internals/#dns を入力
2. 「Clear host cache」ボタンをクリック
3. 必要に応じてソケットプールもクリア（chrome://net-internals/#sockets → 「Flush socket pools」）

DNSキャッシュのトラブルシューティング

DNSキャッシュに関連する問題と、その診断・解決方法を解説します。

よくある問題と対処法

診断手順

DNSキャッシュの問題を診断する際は、以下の手順で切り分けを行います。

graph TB
    START["問題発生"] --> Q1{"ブラウザキャッシュ<br/>クリアで解決？"}
    Q1 -->|"Yes"| A1["ブラウザキャッシュが原因"]
    Q1 -->|"No"| Q2{"OSキャッシュ<br/>クリアで解決？"}
    Q2 -->|"Yes"| A2["OSキャッシュが原因"]
    Q2 -->|"No"| Q3{"別のDNSサーバー<br/>で正しい結果？"}
    Q3 -->|"Yes"| A3["ISP/リゾルバの<br/>キャッシュが原因"]
    Q3 -->|"No"| A4["権威DNSの設定<br/>または伝播途中"]
    
    style START fill:#ffcdd2
    style A1 fill:#e8f5e9
    style A2 fill:#e8f5e9
    style A3 fill:#fff3e0
    style A4 fill:#fff3e0

複数のDNSサーバーで確認

異なるDNSサーバーを使用して問い合わせを行い、キャッシュの影響を切り分けます。

1
2
3
4
5
6
7
8

# Google Public DNS で確認
nslookup www.example.com 8.8.8.8

# Cloudflare DNS で確認
nslookup www.example.com 1.1.1.1

# 権威DNSサーバーに直接問い合わせ（digコマンド）
dig www.example.com @ns1.example.com

異なるDNSサーバーで異なる結果が返る場合、伝播途中であるか、キャッシュの状態が異なることを示しています。

オンラインツールでの確認

世界各地のDNSサーバーから問い合わせ結果を確認できるオンラインツールも活用できます。

ネガティブキャッシュ

ネガティブキャッシュとは、「DNSレコードが存在しない」という結果をキャッシュする仕組みです。存在しないドメインへの問い合わせを繰り返し行うことを防ぎ、DNSサーバーの負荷を軽減します。

ネガティブキャッシュの動作

sequenceDiagram
    participant Client as クライアント
    participant Resolver as キャッシュDNS
    participant Auth as 権威DNS
    
    Client->>Resolver: nonexistent.example.comは？
    Resolver->>Auth: nonexistent.example.comは？
    Auth-->>Resolver: NXDOMAIN（存在しない）
    
    Note over Resolver: ネガティブキャッシュに保存<br/>SOAのMinimum TTLを使用
    
    Resolver-->>Client: NXDOMAIN
    
    Note over Client,Resolver: TTL期間内
    
    Client->>Resolver: nonexistent.example.comは？
    Resolver-->>Client: NXDOMAIN（キャッシュから応答）

ネガティブキャッシュのTTL

ネガティブキャッシュのTTLは、SOAレコードのMinimum TTL（またはNegative Cache TTL）によって決定されます。

1
2
3
4
5
6
7
8

dig example.com SOA

# example.com.  86400  IN  SOA  ns1.example.com. admin.example.com. (
#                      2024010101  ; serial
#                      7200        ; refresh
#                      3600        ; retry
#                      1209600     ; expire
#                      3600 )      ; minimum (negative cache TTL)

上記の例では、ネガティブキャッシュのTTLは3600秒（1時間）です。

ネガティブキャッシュによる問題

新しいサブドメインを作成した直後にアクセスしようとした場合、ネガティブキャッシュによって「存在しない」という結果が返されることがあります。

hostsファイルによる名前解決

hostsファイルは、DNSを使用せずにローカルで名前解決を行うための設定ファイルです。DNSキャッシュよりも優先して参照されるため、テストや開発環境でよく使用されます。

hostsファイルの場所

hostsファイルの書式

# IPアドレス    ホスト名
127.0.0.1       localhost
::1             localhost

# 開発用の設定例
192.168.1.100   dev.example.com
192.168.1.100   api.dev.example.com

hostsファイルの活用例

hostsファイルを編集した後は、ブラウザのDNSキャッシュをクリアするか、ブラウザを再起動してください。

まとめ

本記事では、DNSキャッシュとTTLの仕組みについて解説しました。

• DNSキャッシュの階層: ブラウザ、OS、ルーター、ISPの各層にキャッシュが存在し、名前解決を高速化
• TTLの役割: DNSレコードのキャッシュ保持時間を制御し、短いほど変更反映が速く、長いほどパフォーマンスが向上
• DNS伝播: 権威DNSの変更が世界中のキャッシュに反映されるまで、TTLに応じた時間が必要
• キャッシュクリア: 各OS・ブラウザでコマンドや設定からクリア可能
• トラブルシューティング: 複数のDNSサーバーで確認し、キャッシュの影響を切り分ける
• ネガティブキャッシュ: 存在しないレコードもキャッシュされ、新規作成時に影響する可能性

DNSキャッシュとTTLの仕組みを正しく理解することで、DNS設定変更時のトラブルを予防し、問題発生時にも適切に対処できるようになります。

次回記事「TCPとUDPの違いを理解する」では、トランスポート層のプロトコルであるTCPとUDPの特性と使い分けについて解説します。

参考リンク

• RFC 1034 - Domain Names - Concepts and Facilities
• RFC 2308 - Negative Caching of DNS Queries
• Cloudflare - Time to Live (TTL)
• Google Public DNS - Flush Cache
• Microsoft - ipconfig
• Apple Developer - dscacheutil