DNS キャッシュ

概要

DNS キャッシュ は、DNS リゾルバーが権威 DNS サーバーへの問い合わせ結果を TTL（Time to Live）に指定された時間だけ保存する仕組みです。RFC 1034（1987年）および RFC 1035（1987年）で基本仕様が定義されており、RFC 2308 でネガティブキャッシュが規定されています。

キャッシュがなければ、ページを開くたびにルートサーバーから権威 DNS サーバーまで何段階もの問い合わせが発生します。キャッシュによってこの往復を省略し、DNS 解決の応答時間をミリ秒単位まで短縮します。

キャッシュはインターネットのどこにでも存在します。OS のスタブリゾルバー、ブラウザー、ISP のフルサービスリゾルバー、CDN のエッジサーバーがそれぞれキャッシュを持ちます。DNS レコードを変更した後に変更が全ユーザーに届くまでに時間がかかる「DNS 伝搬」は、これらキャッシュの TTL が切れるまでの待ち時間です。

仕組み

TTL の管理、ネガティブキャッシュ、キャッシュが存在する各レイヤーを順に説明します。

TTL とキャッシュの寿命

各 DNS レコードには TTL が設定されています。TTL は秒単位で指定し、リゾルバーがそのレコードをキャッシュしておける時間を表します。TTL が 3600 であれば、リゾルバーはそのレコードを最大 1 時間キャッシュします。

TTL が切れると、リゾルバーは次の問い合わせが来たタイミングで権威 DNS サーバーに再問い合わせして最新の情報を取得します。TTL が 0 のレコードはキャッシュされません（ただし一部のリゾルバーは TTL 0 でも短時間キャッシュすることがあります）。

典型的な TTL の設定値です。

レコード種別	一般的な TTL
A / AAAA	300〜3600 秒
MX	3600〜86400 秒
TXT (SPF)	300〜3600 秒
NS	86400〜172800 秒
SOA	3600〜86400 秒

ネガティブキャッシュ

存在しないドメインやレコードへの問い合わせに対して NXDOMAIN（ドメイン自体が存在しない）や NOERROR（ドメインは存在するが要求したレコードタイプがない）が返った場合、そのレスポンスもキャッシュされます。これをネガティブキャッシュと呼びます。

ネガティブキャッシュの TTL は SOA レコードの minimum フィールドと、レスポンスの TTL の小さい方が採用されます（RFC 2308）。新しいドメインや新しいサブドメインを作成した直後に「見つからない」結果がキャッシュされると、TTL が切れるまで存在しないと判断され続けます。

キャッシュが存在する場所

権威 DNS サーバー（正本データ）
        ↓ TTL に従ってキャッシュ
フルサービスリゾルバー（ISP、8.8.8.8、1.1.1.1 など）
        ↓ TTL に従ってキャッシュ
OS のスタブリゾルバー（macOS、Windows のキャッシュ）
        ↓ ブラウザー独自のキャッシュも加わる
ブラウザー（Chrome は最大 60 秒）

CDN を使っている場合は、エッジサーバーが DNS を解決した結果をキャッシュすることもあります。Cloudflare などの CDN は独自の TTL ポリシーを持つことがあります。

確認方法

現在の DNS 解決結果を確認するには dig を使います。+ttl オプション（デフォルトで表示）で残り TTL が確認できます。

dig A example.com

;; ANSWER SECTION:
example.com.		254	IN	A	93.184.216.34

レスポンスの ANSWER SECTION に TTL が表示されます。0 に近い値であれば間もなくキャッシュが切れます。

特定のリゾルバーでの結果を確認するには @ でサーバーを指定します。

# Google のパブリック DNS でキャッシュを確認
dig A example.com @8.8.8.8

# Cloudflare のパブリック DNS で確認
dig A example.com @1.1.1.1

macOS の DNS キャッシュをフラッシュする場合は次のコマンドを使います。

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Windows の場合は次のコマンドです。

ipconfig /flushdns

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=A"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [
        { "address": "93.184.216.34", "ttl": 3600 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 45 }
}

data.records.A フィールドに現在の A レコードの値と TTL が返ります。自分のリゾルバーキャッシュの影響を受けずに、外部から見た最新の DNS レコードを確認できます。

よくある問題

DNS キャッシュの動作に起因するトラブルと対処法を整理します。

DNS を変更したのに古い IP が返る

最も多い問い合わせです。DNS を変更してもキャッシュを持つリゾルバーには TTL が切れるまで古い値が返り続けます。変更前の TTL が 86400 秒（24 時間）であれば、最大 24 時間かかります。

次の対処法があります。変更前に TTL を短く（300〜600 秒）設定しておき、TTL が伝搬してから本番の変更を行います。これが最も確実な方法です。変更後は dig @8.8.8.8 と dig @1.1.1.1 の両方で確認して、主要リゾルバーへの反映状況を把握します。

NXDOMAIN がキャッシュされて新しいサブドメインが見つからない

新しいサブドメインを作成した直後に確認した環境で NXDOMAIN が返った場合、その結果がキャッシュされます。SOA の minimum フィールドの TTL が 3600 秒であれば、1 時間は「存在しない」とキャッシュされます。

解決策としては、初回の問い合わせを dig @権威サーバー で行い、キャッシュに NXDOMAIN を記録させないことです。既にキャッシュされた場合は、OS や ブラウザーのキャッシュをフラッシュするか、TTL が切れるまで待ちます。

ISP のキャッシュが TTL より長く保持される

一部の ISP は TTL を無視して独自の長い時間（数時間〜数日）キャッシュするケースがあります。これは RFC 1035 の規定に反しますが、現実に発生します。影響を受けるユーザーには 1.1.1.1 や 8.8.8.8 などのパブリック DNS を使うよう案内します。

TTL を短くしすぎるとリゾルバーの負荷が増える

TTL を極端に短く（1〜10 秒）設定すると、毎回権威 DNS サーバーへの問い合わせが発生してサーバー負荷が増えます。CDN を使っている場合はオリジンの IP を頻繁に切り替える必要がある場合を除き、TTL は 300 秒以上 に設定します。Cloudflare DNS などのサービスは極端に短い TTL を制限することがあります（最小 60 秒）。