DNSの「伝播が遅い」と感じるとき、多くは新しい設定がどこかへ届いていないのではなく、世界中のDNSキャッシュサーバーやあなたのPCが古い答えを覚えたままになっているだけです。この記事では、権威DNSサーバー・公開DNS・手元のPCの3か所を順に確かめて「どこで古い情報が残っているか」を特定し、待つべきか直すべきかを判断できるようにします。
「伝播」の正体はキャッシュの期限切れ待ち
DNSの変更は、設定した瞬間に世界中へ配られるわけではありません。実際には次のような流れで少しずつ置き換わります。
- 権威DNSサーバー（ドメインのレコードを管理している大元）には、保存した時点で新しい値が入る
- 利用者側のキャッシュDNSサーバー（プロバイダや Google Public DNS など）は、以前に問い合わせた答えをTTL（有効期限）の間だけ保持している
- TTLが切れたキャッシュDNSから順に、権威DNSへ問い合わせ直して新しい値を受け取る
つまり「伝播が遅い」の多くは、変更前のレコードに付いていたTTLが長かったことが原因です。ここで見落としやすいのは、変更時に新しいTTLを短くしても、すでにキャッシュされている古い答えには古いTTLが効き続ける点です。86400秒（1日）のTTLで配っていたレコードなら、最長で約1日は古い値が返る場合があります。
逆に言えば、権威DNSが正しい値を返していれば、原因が設定ミスでない限り時間とともに解消します。まずは「権威DNSの値は正しいか」を確かめることが切り分けの起点です。
まず3か所の答えを見比べる
確認には dig コマンドを使います（macOS・Linux には標準または追加パッケージで入っています。Windows の場合は後述の nslookup や PowerShell の Resolve-DnsName でも同じ考え方で確認できます）。
1. 権威DNSサーバーの答え
最初に、そのドメインのネームサーバーがどこかを調べ、そのサーバーに直接問い合わせます。
# ドメインのネームサーバーを調べる
dig +short example.com NS
# 表示されたネームサーバーに直接問い合わせる（ns1.example.net は例）
dig +norecurse @ns1.example.net example.com Aここで返る値が新しい値なら、設定は正しく保存されています。古い値や「NXDOMAIN」が返るなら、待っても直りません。管理画面の保存漏れや、別のDNSサービスを編集していないかを確認します。
2. 公開DNSの答え
次に、代表的な公開DNSに問い合わせて、キャッシュの状況を見ます。
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer+noall +answer を付けると回答部分だけが表示され、2列目の数字がそのキャッシュの残りTTL（秒）です。数秒おいて再実行すると数字が減っていくので、「あと何秒で古いキャッシュが切れるか」の目安になります。
3. 手元のPCの答え
最後に、ブラウザが実際に使う経路での名前解決を確認します。
# macOS / Linux
dig example.com A +short
# Windows（PowerShell）: hosts ファイルやOSのキャッシュも含めて解決する
Resolve-DnsName example.com -Type A権威DNSと公開DNSは新しいのに手元だけ古い場合は、PC・ルーター・社内DNSのキャッシュ、または hosts ファイルが原因です。
反映されない原因を可能性の高い順に確認する
原因1：変更前のTTLが長く、キャッシュが残っている
最も多い原因です。公開DNSで返る値が古く、残りTTLが大きい数字なら、基本的には切れるのを待ちます。急ぐ場合、Google Public DNS と Cloudflare の 1.1.1.1 はキャッシュ削除を依頼できるWebページを用意しています（2026年10月現在）。ページの場所や仕様は変わることがあるため、各サービスの公式ドキュメントで確認してください。ただし利用者が使っているプロバイダのDNSまでは消せないため、一部の訪問者には古い値が見え続ける期間が残ります。
次回以降は、変更の前日など余裕をもってTTLを300秒程度に下げておき、古いTTLが切れてから値を変えると、反映待ちを短くできます。
原因2：編集したDNSが実際には使われていない
サーバー会社の管理画面でレコードを変えたのに、ドメインのネームサーバーは別のサービス（Cloudflare やドメイン登録業者のDNSなど）を向いている、というケースです。手順1の dig NS で表示されたネームサーバーと、編集したサービスが一致しているかを見比べてください。一致していない場合は、実際に使われている側のDNSで同じ変更を行います。
原因3：ネームサーバー自体を変更した直後
ネームサーバーの変更は、ドメインの上位（.com や .jp のレジストリ）に登録された情報が書き換わり、そのキャッシュが切れるまで時間がかかります。この部分のTTLはドメイン所有者が変えられず、.com では2日（172800秒）が一般的です。移行期間中は新旧どちらのDNSにも同じレコードを入れておくと、どちらに問い合わせが行っても同じ結果になり、影響を抑えられます。
原因4：PCやブラウザのキャッシュ、hosts ファイル
公開DNSは新しいのに自分だけ古い場合はこちらです。OSのDNSキャッシュを消去し、ブラウザを再起動して確認します。
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux（systemd-resolved を使っている場合）
resolvectl flush-caches移行作業のために hosts ファイルへ一時的な行を書いていて、そのまま忘れているケースもよくあります。Windows は C:\Windows\System32\drivers\etc\hosts、macOS・Linux は /etc/hosts を開いて該当ドメインの行がないか確認してください。
原因5：存在しない状態がキャッシュされている
レコードを作る前に一度アクセスしていると、「その名前は存在しない」という答え（ネガティブキャッシュ）が保存されます。保持時間はSOAレコードの値で決まるため、新しく作ったサブドメインだけがしばらく見えない、という現象になります。dig example.com SOA の最後の数字がこの保持時間の上限の目安です。
原因6：IPv6（AAAA）レコードやCDNの影響
Aレコードだけ新しいサーバーに変えて、AAAAレコードが旧サーバーのまま残っていると、IPv6で接続できる環境だけ旧サイトが表示されます。dig example.com AAAA +short も併せて確認しましょう。また Cloudflare のプロキシ機能を有効にしている場合、dig には Cloudflare のIPアドレスが返るのが正常で、接続先の確認は Cloudflare の管理画面で行います。
WordPressサイトの移転で起きやすい勘違い
DNSが切り替わったのに旧サイトが表示される場合、DNS以外の要因も疑ってください。
- ページキャッシュ系プラグインやCDNが旧サーバーの内容を保持している
- 新サーバー側の WordPress アドレス（siteurl / home）が旧ドメインや旧URLのままで、リダイレクトされている
- 旧サーバーにも同じ内容が残っており、どちらを見ているのか区別できていない
判別には、新旧サーバーのどちらかに一時的な目印（テスト用の固定ページなど）を置く方法が手軽です。作業前には新旧どちらのサイトもバックアップを取っておき、旧サーバーの契約は切り替えが落ち着くまで解約しないでおくと安全です。
まとめ
- 「伝播」は主にキャッシュの期限切れ待ち。古い値は、変更前のTTLの長さだけ残ることがある
- 権威DNS → 公開DNS → 手元のPC の順に答えを見比べ、どこで古い値が残っているかを特定する
- 権威DNSが古い値なら設定ミス。編集したDNSが実際に使われているか、ネームサーバーを確認する
- 手元だけ古いならOSのDNSキャッシュ消去と hosts ファイルの確認、IPv6のAAAAレコードも見落とさない
- 次回の変更では、事前にTTLを短くしておくと反映待ちを短縮できる