DNS 伝搬（DNS Propagation）
概要
DNS 伝搬（DNS Propagation） は、DNS レコードを変更した後、その変更が世界中のリゾルバー（キャッシュサーバー）に反映される過程を表す業界用語です。「DNS の浸透」という表現も広く使われますが、この言葉はしばしば誤解を生みます。実際には、DNS 変更が「世界中に広がっていく」ようなアクティブなプロセスは存在しません。
正確には、各リゾルバーがキャッシュしている旧レコードの TTL が期限切れになり、次回の問い合わせで権威サーバーから新しいレコードを取得する、という受動的なプロセスです。リゾルバーごとにキャッシュのタイミングが異なるため、同じドメインへの問い合わせでも、どのリゾルバーに当たるかによって結果が異なる時期が生じます。これが「DNS が浸透している途中」と呼ばれる状態の実態です。
仕組み
DNS 変更後に何が起きるかを正確に理解するには、キャッシュの動作を知る必要があります。
- 権威サーバー上の DNS レコードを変更する（例: IP アドレスを
93.184.216.34から198.51.100.1へ変更） - 世界中のリゾルバーは旧レコードをキャッシュしたまま応答を続ける
- 各リゾルバーがキャッシュした時点の TTL が期限切れになると、次の問い合わせで権威サーバーから新しいレコードを取得する
- リゾルバーごとにキャッシュした時刻が異なるため、期限切れのタイミングも分散する
リゾルバーは TTL を受け取った時点からカウントダウンを開始し、他のリゾルバーへ転送する際は経過時間を差し引いた残り秒数を付与します。この仕組みにより、キャッシュ期限は連鎖的に切れていきます。ただし、あるリゾルバーが TTL 3600 のレコードを 30 分前にキャッシュしていれば、そのリゾルバーのキャッシュはさらに 30 分後まで有効です。
確認方法
複数地点からの確認には dig コマンドで特定のリゾルバーを指定する方法が有効です。
# Google Public DNS（8.8.8.8）から確認
dig A example.com @8.8.8.8# Cloudflare DNS（1.1.1.1）から確認
dig A example.com @1.1.1.1# 権威サーバーに直接問い合わせる（キャッシュをバイパス）
dig A example.com @ns1.example.com# 返ってきた TTL 値を確認する（ANSWER SECTION の 2 列目）
dig A example.com +noall +answerexample.com. 254 IN A 93.184.216.34ANSWER SECTION の 2 列目（254）が TTL の残り秒数です。リゾルバーごとにこの値が異なる場合、キャッシュのタイミングが異なることを意味します。権威サーバーへの直接問い合わせで正しい IP が返るのに、8.8.8.8 や 1.1.1.1 では旧 IP が返る場合、それはキャッシュが残っているだけであり、変更は正しく行われています。
外部の視点からも確認したい場合は、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": 254 }
]
}
},
"error": null,
"meta": { "responseTime": 45 }
}手元の dig では旧レコードが返るのに、Labee の API では新しいレコードが返る場合、手元のリゾルバーにキャッシュが残っていることを意味します。逆に API でも旧レコードが返る場合は、権威サーバー側の変更がまだ反映されていないか、API が使うリゾルバーもまだ旧キャッシュを保持している可能性があります。
よくある問題
DNS 変更後のトラブルの大半は、変更前に TTL を短縮しなかったことに起因するキャッシュの残存です。
変更後に旧 IP へのトラフィックが続く
変更前に TTL を下げなかった場合に発生します。旧 TTL（例: 86400 秒）でキャッシュしたリゾルバーは、キャッシュが期限切れになるまで旧 IP へ向け続けます。特に CDN や WAF の IP を変更した場合、攻撃者がこのウィンドウを狙って旧サーバーに直接アクセスしようとするリスクもあります。変更後も旧サーバーを 24〜48 時間は維持しておく対策が有効です。
メール配送が旧サーバーへ向き続ける
MX レコードの変更後、旧サーバーへメールが届き続けるケースがあります。TTL を下げずに変更した場合、各メールサーバーが保持する MX キャッシュが期限切れになるまで旧サーバーに配送が向きます。この期間は旧サーバーでメールを受信できる状態を維持し、切り替え後に新サーバーへ転送する措置が必要になります。
dig と curl で結果が異なる
同一マシンでも dig と Web ブラウザーで異なる結果が返ることがあります。dig はシステムのリゾルバー（/etc/resolv.conf に設定）を使い、ブラウザーは独自のキャッシュを持ちます。OS レベルのキャッシュ（macOS の mDNSResponder、Linux の systemd-resolved）も関与します。真の状態を確認したい場合は dig +short @8.8.8.8 のように外部リゾルバーに直接問い合わせるのが確実です。
変更が反映されているのに SSL 証明書エラーが出る
DNS が正しく反映された後も、CDN やリバースプロキシのキャッシュに旧設定が残っている場合があります。DNS 伝搬の完了と、アプリケーション層のキャッシュ反映は別の問題です。Let’s Encrypt などで新しいドメインに対して証明書を再取得する操作が必要な場合もあります。
“伝搬”という表現の誤解
「DNS が浸透するまで 24〜72 時間待つ必要がある」という説明を見かけることがあります。この表現は技術的に不正確です。誤解を招く主な理由は 2 つあります。
一つ目は、最大の待ち時間は変更前の TTL で決まる点です。TTL が 300 秒ならば、変更から最大 5 分で世界中のリゾルバーが新しいレコードを取得します。「最大 72 時間」という数字は、変更前の TTL が 86400 秒（24 時間）だった場合に、さらに余裕を見た場合の目安に過ぎません。
二つ目は、一部の ISP はキャッシュ期間を自前で決める点です。設定した TTL を守らずに独自の期間（多くは数時間）キャッシュし続けるリゾルバーが存在します。特に古い企業内 DNS サーバーでこのような挙動が見られます。このケースでは TTL を短くしても効果が薄く、ISP 側のキャッシュ期間が事実上の「伝搬時間」になります。
技術的に正確な言葉を使うと、「DNS 伝搬」は「旧 TTL の最長キャッシュ期間に、TTL を守らないリゾルバーの不確実な期間を加えた時間」です。
TTL を短縮して影響を最小化する手順
DNS 変更を速やかに反映させるための標準的な手順を示します。
# Step 1: 変更の 24〜48 時間前に TTL を 300 秒に下げる
# （旧 TTL が 86400 の場合、この操作自体も 24 時間後まで反映されない）
example.com. 300 IN A 93.184.216.34 ; 旧 IP、TTL を 5 分に
# Step 2: 旧 TTL の時間が経過してから IP アドレスを変更する
example.com. 300 IN A 198.51.100.1 ; 新 IP
# Step 3: 新しいレコードが外部から確認できたら TTL を元に戻す
example.com. 3600 IN A 198.51.100.1 ; TTL を 1 時間に戻すステップ 1 とステップ 2 の間に「旧 TTL 分の待機時間」を設けることが核心です。TTL を 300 に下げた操作自体が世界中に反映されるには、旧 TTL（86400 秒）だけの時間が必要だからです。この待機なしに変更を行うと、旧 TTL でキャッシュしていたリゾルバーは変更後も長時間旧レコードを返し続けます。