DNS伝搬とはなんなのか

DNS伝搬とは、DNS設定を変更したあと、その変更がインターネット上で順次反映されていくように見える現象のことです。

たとえば、ドメインの向き先サーバーを変更した場合、設定を保存した瞬間に世界中のすべての利用者が一斉に新しい接続先を見るわけではありません。

ある利用者はすでに新しいサーバーへ接続されている一方で、別の利用者はまだ古いサーバーへ接続される、という時間差が発生します。これが一般に「DNS伝搬」と呼ばれています。

ただし、厳密には「変更情報が世界中へ順番に配信される」というより、各地のDNSキャッシュが期限切れになったタイミングで新しい情報へ切り替わっていくと考えるほうが実態に近いです。

まずDNSとは何か

DNSは、ドメイン名をIPアドレスに変換する仕組みです。

人間は example.com のようなドメイン名を使ってWebサイトを認識しますが、コンピュータは実際にはIPアドレスをもとに通信します。

そのため、ブラウザでサイトにアクセスすると、まずDNSに問い合わせて「このドメインはどのIPアドレスへ接続すべきか」を調べます。

なぜDNS伝搬が起こるのか

DNS伝搬が起こる主な理由は、DNS情報がさまざまな場所でキャッシュされるためです。

DNSでは、毎回すべての問い合わせを元の権威DNSサーバーまでたどると非効率なので、途中の再帰DNSサーバーやOS、アプリケーションなどが一定時間その情報を保存します。

この保存データがキャッシュです。

そのため、DNS設定を変更しても、

• まだ古い情報を保持している再帰DNSサーバー
• プロバイダ側のDNSキャッシュ
• OSやブラウザなどのローカルキャッシュ

が残っている間は、一部の利用者に古い情報が返ることがあります。

つまりDNS伝搬とは、新しい情報が“届く”というより、古い情報が順番に失効して新しい情報へ置き換わっていく過程です。

「伝搬」という言葉で理解してよいのか

実務では「DNS伝搬」という表現で問題ありません。

ただし技術的には、変更内容がインターネット全体へ自動的に放送されるわけではありません。

実際の流れは、概ね次のようになります。

1. 権威DNSサーバー上で設定が変更される
2. すでに古い情報を持っているキャッシュは、その有効期限が切れるまで古い値を返す
3. 期限切れ後、再度問い合わせが発生する
4. その時点で新しいDNS情報が取得される
5. 結果として、利用者ごとに反映タイミングがずれる

この意味で、DNS伝搬とはキャッシュ更新の時間差によって起こる見かけ上の段階的反映といえます

TTLがDNS伝搬の中心になる

DNS伝搬を理解するうえで特に重要なのが TTL です。

TTLは Time To Live の略で、そのDNS情報を「どれくらいの時間キャッシュしてよいか」を示す値です。

たとえばTTLが 86400 なら、これは通常 24時間 を意味します。

ある再帰DNSサーバーが古いレコードを取得していた場合、そのサーバーはTTLが切れるまで古い情報を返し続ける可能性があります。

例

• 10:00 にAレコードを新しいIPへ変更した
• 変更前レコードのTTLが24時間だった
• ある再帰DNSサーバーが9:59に古いレコードを取得していた

この場合、その再帰DNSサーバーではしばらく古いIPアドレスが使われ続ける可能性があります。

ただし、ここには補足もあります。

実際のリゾルバ実装では、TTLがそのまま使われることもあれば、独自ポリシーで短く扱われたり、例外的に期限切れの古い情報が一時的に返されたりする場合もあります。

そのため、TTLは最重要の目安ではあるが、絶対条件ではないと考えるのが正確です。

どのDNSレコードで伝搬が問題になるのか

DNS伝搬は、さまざまなレコード変更で発生します。

Aレコード

ドメイン名をIPv4アドレスへ向けるレコードです。

Webサーバー移転時によく使われます。

AAAAレコード

ドメイン名をIPv6アドレスへ向けるレコードです。

CNAMEレコード

あるドメイン名を別のドメイン名へ向けるレコードです。

CDN、SaaS、外部サービス連携でよく使われます。

MXレコード

メール受信サーバーを指定するレコードです。

メール移行時に重要です。

TXTレコード

文字列情報を持つレコードです。

SPF、DKIM、DMARC、ドメイン認証などでよく利用されます。

NSレコード

そのドメインをどのネームサーバーが管理するかを示すレコードです。

DNSホスティング移行やレジストラ変更時に関わります。

NS変更は少し特殊

AレコードやCNAMEレコードの変更と比べると、NS変更は少し複雑です。

NS変更では、単にゾーン内の1レコードを書き換えるだけではなく、

• 親ゾーン側の委任情報
• レジストラ側の設定
• 権威DNSサーバー間の同期
• DNSSECを使っている場合の整合性

なども関わる場合があります。

そのため、NS変更は一般的なAレコード変更よりも慎重に扱う必要があります。

実務上「ネームサーバー変更は24〜72時間程度見ておく」と案内されることが多いのは、この複雑さも関係しています。

DNS伝搬にどれくらい時間がかかるのか

DNS伝搬にかかる時間は一律ではありません。

一般には、数分から数時間で反映が進むこともあれば、24時間以上差が残ることもある、という理解が現実的です。

よく「24〜72時間かかる」といわれますが、これはDNS仕様上の固定ルールではなく、安全側の案内目安です。

実際の所要時間は、次のような要因で変わります。

• 変更前レコードのTTL
• 再帰DNSサーバーの実装や運用
• NS変更か、単純なA/CNAME変更か
• キャッシュ済みかどうか
• 一部のネットワークや地域ごとの差

つまり、DNS伝搬は「必ず72時間かかる」ものではありませんが、全利用者で完全に揃うまでには時間差が出ることがあると考えるのが安全です。

新規追加でも反映が遅れることがある

DNS伝搬というと、古いレコードが残るケースだけを想像しがちですが、新規レコード追加でも遅れが出ることがあります。

たとえば、もともと存在しなかった sub.example.com を新しく作成した場合でも、過去に「その名前は存在しない」という問い合わせ結果がキャッシュされていると、一部の環境ではしばらく見えないことがあります。

これは 負のキャッシュ と呼ばれるものです。

そのため、サブドメイン新設でも「設定したのに見えない」という現象は起こり得ます。

DNS伝搬中に起こりやすいこと

DNS伝搬中は、利用環境によって見える結果がばらつきます。たとえば次のような現象です。

• 自分のPCでは新サイトが見えるのに、別の人には旧サイトが見える
• スマホ回線では新しいが、会社のWi-Fiでは古い
• www は新しいが、ルートドメインはまだ古い
• Webサイトは切り替わったが、メールの配送先はまだ旧設定
• 一部の地域だけ反映が遅いように見える

これらは珍しい障害ではなく、DNSのキャッシュ差によって自然に起こり得る状態です。

ブラウザキャッシュとは別の問題

DNS伝搬は、HTMLやCSS、画像ファイルのキャッシュ問題とは別です。

• DNSキャッシュ
  ドメイン名と接続先情報のキャッシュ
• ブラウザキャッシュ
  HTML、CSS、JavaScript、画像などのファイルのキャッシュ

たとえばDNSはすでに新サーバーを向いていても、ブラウザに古いCSSが残っているせいで「サイトが古いまま」に見えることがあります。

逆に、見た目は新しくても、実際にはまだ古い接続先へ行っているケースもあります。

なお、実装上はブラウザやOSのネットワークスタックがDNSキャッシュに関与することもありますが、実務ではまず“接続先の問題” と “表示データの問題” を分けて考えることが大切です。

DNS伝搬を確認する方法

DNS伝搬の確認では、権威DNSに正しく登録されているか と、複数の再帰DNSサーバーでどう見えているか を分けて確認するのが基本です。

dig を使う例

dig example.com

特定の公開DNSに問い合わせる例です。

dig example.com @8.8.8.8
dig example.com @1.1.1.1

これにより、Google Public DNS や Cloudflare DNS がどの値を返しているかを比較できます。

必要に応じて、権威DNSに直接問い合わせて、元の設定自体が正しく更新されているか を確認することもあります。

DNS伝搬を完全に一瞬で終わらせることはできるか

基本的に、完全な意味で“全世界に一瞬で反映”させることはできません。

ただし、影響を最小限に抑える工夫はできます。

反映差を減らすための実務上の対策

事前にTTLを下げる

大きな切り替えの前には、数日前からTTLを短くしておくのが有効です。

たとえば通常 86400 なら、事前に 300 などへ下げておきます。

ただし重要なのは、変更直前にTTLを下げても、すでに配られている古い長TTLキャッシュには効かないことがある点です。

TTL短縮は、余裕を持って事前に行う必要があります。

旧サーバーをすぐ止めない

AレコードやCNAMEの切り替え後もしばらく旧サーバーを残しておくと、古いDNSキャッシュを持つ利用者にもサイトを表示できます。

これはダウンタイム回避の基本です。

メール移行では旧環境も確認する

MX変更後は、しばらく旧メールサーバーへ配送されるケースがあります。

そのため、移行期間中は旧環境も確認対象に含めるのが安全です。

本番前に新環境を確認しておく

hosts設定や検証用URLを使って、新サーバーや新サービスの動作を事前確認しておくと、DNS切り替え後のトラブルを減らせます。

Web実務で特に重要な考え方

Web運用やマーケティング実務では、DNS伝搬は単なる技術用語ではなく、機会損失や計測ズレに直結するテーマです。

サイト移行日に全員が同じサイトを見るとは限らない

キャンペーンLPや新サイト公開をDNS切り替えと同時に行う場合、一部ユーザーはまだ旧サイトを見る可能性があります。

計測タグの不一致に注意が必要

旧環境と新環境でGA4、GTM、コンバージョンタグなどの設定が一致していないと、伝搬中に計測漏れや重複計測が発生することがあります。

広告配信と切り替え時刻は慎重に設計する

大量流入の直前や配信開始時刻の直前にDNS変更を行うと、利用者によって表示内容がズレるリスクがあります。

TXT系認証は「設定済み」と「検証成功」がずれることがある

SPF、DKIM、DMARC、ドメイン認証用TXTは、設定直後にすぐ認証が通らないことがあります。これもDNS伝搬やキャッシュの影響を受けます。

よくある誤解

「変更したのに反映しない = 設定ミス」

必ずしもそうではありません。

まずは権威DNS側に正しく設定されているかと、キャッシュが残っていないかを確認すべきです。

「自分の環境で見えた = 全員に反映済み」

そうとは限りません。

自分の回線や端末だけ新しい情報を取得している可能性があります。

「TTLが5分なら、5分後には全員が新しい設定になる」

目安としては近いですが、現実にはリゾルバ実装やキャッシュの扱いに差があり、完全一致しないことがあります。

「伝搬中は必ずサイトが落ちる」

適切に切り替えれば、落とさずに移行できるケースも多いです。

特に旧環境を一定期間残す設計は有効です。

たとえで言うと

DNS伝搬は、住所録の更新に近いです。

• DNS = インターネットの住所録
• IPアドレス = 実際の住所
• TTL = 住所録を何日ごとに見直すかのルール

会社の住所が変わっても、全員の住所録が同時に更新されるわけではありません。

古い住所録を持っている人はしばらく旧住所へ向かい、新しい住所録を受け取った人から順に新住所へ向かいます。
DNS伝搬もこれとよく似ています。

まとめ

DNS伝搬とは、DNS設定を変更したあと、その変更がキャッシュや委任情報更新のタイミング差によって、利用者ごとに段階的に反映されるように見える現象です。

押さえるべきポイントは次の通りです。

• DNSはドメイン名を接続先情報へ変換する仕組み
• 変更は全世界に同時反映されるわけではない
• 主な原因はDNSキャッシュとTTL
• NS変更では委任情報や同期の影響も絡む
• 新規レコード追加でも負のキャッシュで遅れることがある
• 実務ではTTL調整、旧環境維持、事前検証が重要

以上、DNS伝搬とはなんなのかについてでした。

最後までお読みいただき、ありがとうございました。