DNSの浸透という表現はおかしいのか

「DNSの浸透」という表現は、Web制作やサーバー移転の現場ではよく使われます。

たとえば、ドメインの向き先を変更したときに、

DNSの浸透に時間がかかります

と説明されることがあります。

この表現は、実務上は多くの人に通じます。

しかし、DNSの仕組みを厳密に見ると、やや不正確な表現です。

なぜなら、DNSの変更情報がインターネット全体へじわじわ広がっていくわけではないからです。

実際には、各DNSリゾルバーや端末に残っている古いDNSキャッシュが、TTLの期限切れやキャッシュ更新によって順次切り替わっていく、という仕組みに近いです。

そのため、「DNSの浸透」というよりも、正確には「DNSキャッシュの更新待ち」と表現したほうが適切です。

DNSの浸透とは何を指しているのか

DNS設定後にすぐ反映されないように見える現象

一般的に「DNSの浸透」と呼ばれるのは、DNSレコードを変更したあと、すべての利用環境で新しい情報が見えるようになるまでに時間差が生じる現象です。

たとえば、以下のような作業を行ったとします。

• サーバー移転に伴ってAレコードを変更した
• www のCNAMEレコードを変更した
• メールサーバー変更のためにMXレコードを変更した
• ドメインのネームサーバーを変更した
• CDNやWAFを導入してDNSの向き先を変更した

このような変更を行った直後、あるユーザーには新しいサーバーが表示される一方で、別のユーザーには古いサーバーが表示されることがあります。

この状態を、現場では「DNSがまだ浸透していない」と表現することがあります。

実際には「情報が広がっている」のではない

「浸透」という言葉を使うと、新しいDNS情報が世界中のDNSサーバーへ順番に広がっていくようなイメージを持ちやすくなります。

しかし、DNSはそのような一方通行の配信システムではありません。

DNSでは、ユーザーがドメインにアクセスすると、利用しているDNSリゾルバーが必要に応じて権威DNSサーバーへ問い合わせます。

そして、取得したDNS情報を一定時間キャッシュします。

そのため、DNS変更後に時間差が生じる主な理由は、新しい情報の配信に時間がかかっているからではありません。

多くの場合、古いDNS情報をキャッシュしているリゾルバーや端末が、キャッシュの有効期限が切れるまで古い情報を返していることが原因です。

DNSの仕組みを簡単に整理

権威DNSサーバーとは

権威DNSサーバーとは、特定のドメインについて正式なDNS情報を持っているサーバーです。

たとえば、example.com のAレコード、MXレコード、CNAMEレコードなどを管理しているDNSサーバーが、example.com にとっての権威DNSサーバーです。

DNS設定を変更した場合、まず確認すべきなのは、この権威DNSサーバーが正しい情報を返しているかどうかです。

権威DNSサーバーが新しい情報を返していれば、DNS設定そのものは基本的に反映されています。

ただし、DNS管理画面で変更したからといって、必ずしも即座にすべての権威DNSサーバーへ反映されるとは限りません。

DNS事業者の内部処理や複数のDNSサーバー間の同期により、短時間の遅れが発生することもあります。

DNSリゾルバーとは

DNSリゾルバーとは、ユーザーの代わりにDNS情報を問い合わせるサーバーです。

多くの場合、ユーザーは以下のようなDNSリゾルバーを利用しています。

• 契約しているインターネットプロバイダのDNS
• Google Public DNS
• Cloudflare DNS
• Quad9
• 会社や学校の社内DNS
• ルーターやVPNで指定されたDNS

ユーザーがWebサイトにアクセスすると、端末はまずDNSリゾルバーに問い合わせます。

DNSリゾルバーがすでにそのドメインの情報をキャッシュしていれば、権威DNSサーバーへ問い合わせずに、キャッシュ済みの情報を返すことがあります。

このキャッシュが残っていることにより、DNS変更後もしばらく古いサーバーへアクセスされる場合があります。

「DNSの浸透」が不正確とされる理由

新しい情報が世界中へ配信されるわけではない

「DNSが浸透する」という表現には、新しいDNS情報が世界中のDNSサーバーへ広がっていく印象があります。

しかし、実際のDNSは、必要に応じて問い合わせが行われる分散型の仕組みです。

各DNSリゾルバーが、必要なタイミングで権威DNSサーバーへ問い合わせ、その結果を一定時間キャッシュします。

そのため、DNS変更後の時間差は「新しい情報が届いていない」というより、「古い情報のキャッシュがまだ残っている」と考えるほうが正確です。

すべての環境で同時に切り替わるわけではない

DNSの見え方は、利用しているDNSリゾルバーによって異なります。

同じドメインでも、あるリゾルバーでは新しいIPアドレスが返り、別のリゾルバーでは古いIPアドレスが返ることがあります。

たとえば、次のような状況です。

• Google Public DNSでは新しいIPが返る
• Cloudflare DNSでは新しいIPが返る
• プロバイダのDNSでは古いIPが返る
• 社内DNSでは古い情報が残っている
• 自分のPCやブラウザのキャッシュが古い情報を持っている

このように、DNS変更後の反映状況は一律ではありません。

そのため、「DNSが浸透した」「まだ浸透していない」と単純に表現するよりも、「どのDNSリゾルバーで、どの情報が返っているか」を確認するほうが正確です。

DNS変更で重要なTTLとは

TTLはDNSキャッシュの有効期間

DNS変更を理解するうえで重要なのが、TTLです。

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

たとえば、AレコードのTTLが3600秒に設定されている場合、DNSリゾルバーはそのレコードを最大3600秒、つまり最大1時間程度キャッシュする可能性があります。

example.com. 3600 IN A 203.0.113.10

この例では、3600 がTTLです。

DNSリゾルバーがこの情報を取得すると、原則としてそのTTLの範囲内でキャッシュを利用します。

その後、Aレコードを新しいIPアドレスへ変更しても、古い情報をすでにキャッシュしているリゾルバーは、TTLが切れるまで古いIPアドレスを返すことがあります。

TTLは「必ず保持される時間」ではない

TTLについて注意したいのは、TTLは「必ずその時間キャッシュされる」という意味ではないことです。

TTLは、あくまでキャッシュしてよい最大時間です。

たとえばTTLが3600秒であれば、リゾルバーは最大3600秒までその情報をキャッシュできます。

ただし、実装や運用ポリシーによって、それより早くキャッシュが破棄される場合もあります。

逆に、環境によってはOS、ブラウザ、ルーター、社内DNS、セキュリティ製品などが独自にキャッシュを持っていることもあります。

そのため、TTLを300秒に設定したからといって、必ず5分後にすべての環境で新しい情報に切り替わるとは限りません。

変更前のTTLにも注意が必要

DNS変更時に重要なのは、変更後のTTLだけではありません。

むしろ、変更前にどのTTLでキャッシュされていたかが大きく影響します。

たとえば、変更前のAレコードのTTLが86400秒、つまり24時間だったとします。

その状態でレコードを変更した場合、変更直前に古い情報を取得したリゾルバーは、最大24時間程度、古い情報を保持する可能性があります。

そのため、サーバー移転などを行う場合は、切り替えの数日前からTTLを短くしておくのが安全です。

たとえば、次のように事前にTTLを下げます。

86400秒 → 300秒

ただし、切り替え直前にTTLを短くしても、すでに長いTTLでキャッシュされている古い情報にはすぐ効きません。

TTLを下げる作業は、余裕をもって事前に行う必要があります。

DNS変更の種類ごとの注意点

Aレコードを変更する場合

Aレコードは、ドメイン名をIPv4アドレスに対応させるレコードです。

たとえば、サーバー移転で次のように変更するケースがあります。

変更前: example.com → 203.0.113.10
変更後: example.com → 203.0.113.20

この場合、権威DNSサーバーが新しいAレコードを返していても、一部のDNSリゾルバーが旧IPアドレスをキャッシュしていると、しばらく旧サーバーへアクセスされることがあります。

Webサイトの移転では、この状態を想定して、旧サーバーと新サーバーを一定期間並行稼働させるのが安全です。

AAAAレコードを変更する場合

AAAAレコードは、ドメイン名をIPv6アドレスに対応させるレコードです。

実務ではAレコードだけを確認して、AAAAレコードを見落とすことがあります。

Aレコードは新サーバーを指しているのに、AAAAレコードが旧サーバーや別の環境を指していると、IPv6を優先する環境では意図しないサーバーへアクセスされる可能性があります。

そのため、DNS変更後に表示が不安定な場合は、AレコードだけでなくAAAAレコードも確認する必要があります。

CNAMEレコードを変更する場合

CNAMEレコードは、あるドメイン名を別のドメイン名に向けるためのレコードです。

たとえば、次のような設定です。

www.example.com → old.example.net

これを以下のように変更するケースがあります。

www.example.com → new.example.net

CNAMEの場合も、キャッシュの影響を受けます。

さらに、CNAMEの参照先である old.example.net や new.example.net 側にもAレコードやAAAAレコードがあるため、CNAME自体のTTLだけでなく、参照先レコードのTTLも関係します。

そのため、CNAMEを使っている場合は、どの段階のレコードが古い情報を返しているのかを分けて確認することが重要です。

MXレコードを変更する場合

MXレコードは、メールの配送先サーバーを指定するレコードです。

メールサーバーを切り替える場合、MXレコードの変更が必要になります。

ただし、MXレコードの変更直後は、送信元メールサーバーやDNSリゾルバーのキャッシュ状況によって、しばらく旧メールサーバーへメールが配送される可能性があります。

そのため、メール移行では以下のような対策が必要です。

• 旧メールサーバーもしばらく受信可能にしておく
• MXレコードのTTLを事前に短くしておく
• SPF、DKIM、DMARCの設定も確認する
• 旧サーバーと新サーバーの両方にメールが届いていないか確認する
• 移行期間中のメールロスを防ぐ運用を行う

Webサイトの表示以上に、メール移行は慎重に行う必要があります。

ネームサーバーを変更する場合

ネームサーバー変更は、AレコードやCNAMEレコードの変更より複雑です。

たとえば、ドメインの管理会社で次のようにネームサーバーを変更したとします。

変更前: ns1.old-dns.example
変更後: ns1.new-dns.example

この場合、関係するのは個別のDNSレコードだけではありません。

ネームサーバー変更では、以下のような要素が関係します。

• レジストリ側の委任情報
• TLDネームサーバーのNSレコード
• 旧ネームサーバーのキャッシュ
• 新ネームサーバーの設定内容
• リゾルバー側のNSレコードキャッシュ
• glueレコード
• DNSSECの設定

そのため、ネームサーバー変更は通常のAレコード変更よりも時間差が大きく見えることがあります。

「DNSの反映に24〜72時間かかる」と説明されることが多いのも、特にネームサーバー変更のように委任情報が絡むケースです。

「最大72時間かかる」は正しいのか

保守的な案内としては使われる

DNS変更時によく聞く説明に、

DNSの反映には最大72時間かかります

というものがあります。

これは完全に間違いではありません。

特に、ネームサーバー変更やレジストリ・TLD側のキャッシュが関係する場合、反映に時間がかかることがあります。

そのため、ユーザー向けの保守的な案内として「最大24〜72時間」と説明されることはあります。

すべてのDNS変更に当てはまるわけではない

ただし、すべてのDNS変更に対して一律に「72時間かかる」と考えるのは大雑把です。

AレコードやCNAMEレコードの変更で、事前にTTLを短くしていた場合は、数分から数十分、長くても数時間程度で多くの環境が切り替わることもあります。

一方で、変更前のTTLが長かった場合や、ネームサーバー変更、社内DNS、プロキシ、CDN、DNSSECなどが絡む場合は、より長く見えることもあります。

つまり、「72時間」は絶対的なルールではなく、トラブルを避けるための余裕を持った目安です。

「浸透待ち」で片付けると危険なケース

権威DNSサーバーでも古い情報が返っている

DNS変更後にまず確認すべきなのは、権威DNSサーバーが正しい情報を返しているかどうかです。

権威DNSサーバーでも古い情報が返っている場合、それは単なるキャッシュ待ちではありません。

DNS管理画面の設定が間違っている、変更がまだ権威DNSに反映されていない、別のDNSゾーンを編集している、といった可能性があります。

ネームサーバーの委任先が間違っている

ドメインのネームサーバー変更では、そもそも委任先が正しいかを確認する必要があります。

ドメイン管理会社側では新しいネームサーバーを設定したつもりでも、実際には旧ネームサーバーのままになっていることがあります。

この場合、いくら新しいDNSサーバー側でレコードを設定しても、外部からは参照されません。

wwwあり・なしの片方だけ設定されていない

Webサイトでは、以下の2つを別々に確認する必要があります。

example.com
www.example.com

example.com は正しく表示されるのに、www.example.com が表示されない場合、www 側のCNAMEレコードやAレコードが未設定の可能性があります。

逆に、www は表示されるのに、ルートドメインが表示されないケースもあります。

これはDNSの浸透ではなく、単純なレコード設定漏れの可能性があります。

SSL証明書やWebサーバー設定の問題

DNSが正しく新サーバーを指していても、Webサイトが正しく表示されないことがあります。

その場合、原因はDNSではなく、SSL証明書やWebサーバー設定にあるかもしれません。

たとえば、以下のようなケースです。

• 新サーバーにSSL証明書が設定されていない
• 証明書の対象ドメインに www が含まれていない
• Webサーバー側で対象ドメインを受け付けていない
• バーチャルホスト設定が間違っている
• HTTPSリダイレクト設定が誤っている

このような場合に「DNSの浸透待ち」と判断してしまうと、問題の発見が遅れます。

メール設定の問題

メールが届かない場合も、DNSのキャッシュだけが原因とは限りません。

MXレコードが正しくても、SPF、DKIM、DMARC、メールサーバー側の受信設定に問題がある場合があります。

また、旧メールサーバーと新メールサーバーの両方を確認しないと、一部のメールが旧サーバーに届いていることに気づけない場合もあります。

メール移行では、「DNSが浸透すれば大丈夫」と考えるのではなく、送受信テストとログ確認を行うことが重要です。

DNS変更後の確認方法

権威DNSサーバーを確認する

まずは、権威DNSサーバーが正しいレコードを返しているか確認します。

dig コマンドを使う場合は、次のように確認できます。

dig example.com A @権威DNSサーバー名

ネームサーバー自体を確認したい場合は、以下のようにします。

dig example.com NS

権威DNSサーバーが正しい情報を返していれば、DNS設定そのものは基本的に反映されています。

パブリックDNSで確認する

次に、主要なパブリックDNSでどの情報が返るか確認します。

dig example.com A @8.8.8.8
dig example.com A @1.1.1.1
dig example.com A @9.9.9.9

それぞれのDNSリゾルバーで結果が異なる場合は、キャッシュ状況に差がある可能性があります。

代表的なパブリックDNSには以下があります。

Google Public DNS: 8.8.8.8
Cloudflare DNS: 1.1.1.1
Quad9: 9.9.9.9

AレコードとAAAAレコードを両方確認する

Webサイトの表示確認では、AレコードだけでなくAAAAレコードも確認しましょう。

dig example.com A
dig example.com AAAA

IPv6環境ではAAAAレコードが優先的に使われる場合があります。

そのため、Aレコードが正しくても、AAAAレコードが古い向き先を指していると、一部の環境で表示がおかしくなることがあります。

CNAMEの参照先も確認する

CNAMEを使っている場合は、CNAME自体だけでなく、その参照先のAレコードやAAAAレコードも確認します。

dig www.example.com CNAME
dig new.example.net A
dig new.example.net AAAA

CNAMEは複数段階の名前解決になることがあるため、どの段階で古い情報が返っているのかを切り分けることが重要です。

ローカル環境のキャッシュも確認する

パブリックDNSでは新しい情報が返っているのに、自分のPCだけ古いサイトが表示される場合は、ローカル環境のキャッシュが原因かもしれません。

確認すべきものには、以下があります。

• OSのDNSキャッシュ
• ブラウザキャッシュ
• ルーターのDNSキャッシュ
• VPNのDNS設定
• 社内DNS
• プロキシ
• セキュリティソフト
• CDNキャッシュ
• WordPressのキャッシュプラグイン
• サーバー側キャッシュ

この場合、DNSレコード自体は正しくても、表示確認の環境側に古い情報が残っている可能性があります。

DNS変更前に行うべき対策

事前にTTLを短くしておく

サーバー移転やメール移行を行う場合は、切り替え前にTTLを短くしておくのが基本です。

たとえば、現在のTTLが86400秒なら、数日前に300秒や600秒へ下げておきます。

86400秒 → 300秒

これにより、切り替え時に古い情報がキャッシュされ続ける時間を短くしやすくなります。

ただし、すでに長いTTLでキャッシュされている情報は、そのTTLが切れるまで残る可能性があります。

そのため、TTL変更は切り替え直前ではなく、余裕を持って行う必要があります。

旧サーバーと新サーバーを並行稼働させる

DNS変更直後は、ユーザーによって旧サーバーにアクセスする人と新サーバーにアクセスする人が混在することがあります。

そのため、サーバー移転では旧サーバーをすぐに停止しないほうが安全です。

特に以下のようなサイトでは注意が必要です。

• ECサイト
• 会員サイト
• 予約サイト
• 問い合わせフォームがあるサイト
• WordPressのコメント機能を使っているサイト
• ユーザー投稿機能があるサイト
• 決済機能があるサイト

静的なコーポレートサイトであれば影響は比較的小さいですが、データ更新が発生するサイトでは、旧サーバーと新サーバーのデータ差分が問題になることがあります。

メール移行では旧サーバーも確認する

メールサーバーを移行する場合は、DNS変更後もしばらく旧メールサーバーを確認する必要があります。

MXレコードのキャッシュ状況によっては、一部の送信元から旧メールサーバーへ配送されることがあるためです。

移行期間中は、旧サーバーと新サーバーの両方でメールを確認し、メールの取りこぼしがないように運用する必要があります。

クライアントへ説明する場合の言い換え例

一般向けの説明

クライアントや非技術者向けには、専門用語を使いすぎない説明が適しています。

たとえば、次のように説明できます。

DNS設定の変更後、設定自体は反映されていても、利用している通信環境やDNSサーバーのキャッシュ状況によって、一時的に旧サーバーが表示される場合があります。一般的に「DNSの浸透」と呼ばれる現象ですが、正確には古いDNS情報のキャッシュが残っている状態です。

この説明であれば、「浸透」という現場で通じる言葉を使いつつ、正確な意味も補足できます。

短く説明する場合

メールやチャットで簡潔に説明するなら、次のような表現が使いやすいです。

DNS変更後は、各環境のキャッシュ状況により、一時的に旧サイトが表示されることがあります。設定ミスではなく、DNSキャッシュが更新されるまでの時間差によるものです。

技術者向けの説明

技術者やサーバー会社に説明する場合は、「浸透」という表現よりも、具体的にキャッシュやTTLに触れたほうがよいです。

権威DNSでは新しいAレコードが返っていますが、一部のリゾルバーで旧レコードのキャッシュが残っている可能性があります。TTL経過後に順次解消される見込みです。

また、ネームサーバー変更の場合は、次のように説明できます。

権威DNSの委任先変更に伴い、TLD側のNSレコードや各リゾルバーのキャッシュ状況によって、一部環境では旧ネームサーバーを参照する可能性があります。

「DNSの浸透」は使ってもよいのか

非技術者向けには使っても問題ない

「DNSの浸透」という表現は、厳密には曖昧ですが、Web制作やサーバー移転の現場では広く使われています。

そのため、クライアントや一般ユーザー向けの説明で使うこと自体は問題ありません。

ただし、誤解を避けるためには、次のように補足するのがおすすめです。

一般的に「DNSの浸透」と呼ばれますが、正確にはDNSキャッシュの更新待ちです。

この一文を添えるだけで、説明の正確性が大きく上がります。

技術者向けには避けたほうがよい

インフラエンジニアやDNSに詳しい相手に対しては、「DNSの浸透」という表現は避けたほうが無難です。

代わりに、以下のような表現を使うと正確です。

• DNSキャッシュが残っている
• TTLがまだ切れていない
• 一部リゾルバーで旧レコードが返っている
• 権威DNSでは新レコードが返っている
• TLD側のNSキャッシュが残っている
• ネームサーバーの委任情報が更新途中
• ローカルDNSキャッシュの影響がある
• CDN側のキャッシュが残っている

技術者向けには、「浸透」という曖昧な表現よりも、どのレイヤーで何が起きているのかを具体的に伝えることが重要です。

まとめ

「DNSの浸透」という表現は、実務ではよく使われるため、完全に間違いとは言えません。

しかし、DNSの仕組みを厳密に見ると、やや不正確な表現です。

DNS変更後に時間差が生じる主な理由は、新しいDNS情報が世界中に順番に広がっていくからではありません。

実際には、各DNSリゾルバーや端末に残っている古いDNSキャッシュが、TTLの期限切れやキャッシュ更新によって順次切り替わるため、利用環境によって見え方に差が出ます。

そのため、より正確には次のように説明するとよいでしょう。

一般的に「DNSの浸透」と呼ばれますが、正確には、各DNSリゾルバーや端末に残っているキャッシュが更新されるまで、環境によって古いDNS情報が返ることがある状態です。

また、ネームサーバー変更では、単なるレコードのTTLだけでなく、TLD側の委任情報、NSレコードのキャッシュ、glueレコード、DNSSECなども関係するため、通常のAレコード変更より時間差が大きくなる場合があります。

記事やクライアント説明では「DNSの浸透」という言葉を使っても問題ありませんが、信頼性を高めるなら、

「DNSの浸透」と呼ばれることがありますが、正確にはDNSキャッシュの更新待ちです。

と補足するのがおすすめです。

以上、DNSの浸透という表現はおかしいのかについてでした。

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