ドメインのDNSレコードを更新し、変更を保存しても、新しいウェブサイトやメールサービスがすぐに機能するとは限りません。しかし、同僚はまだ古いウェブサイトを見ていたり、オンラインチェッカーが異なるアドレスを示したり、メール配送が一貫しないことがあります。この遅延は一般的に次のように呼ばれます DNS伝播.
この表現は、1回の更新が中央のインターネットシステムを通過しているかのように聞こえる可能性があります。しかし、DNSは分散型です。ドメイン情報は、権威ネームサーバー、再帰的リゾルバー、ルーター、オペレーティングシステム、およびアプリケーションにわたって保存およびキャッシュされます。各システムは異なるタイミングで情報を更新する可能性があります。
DNSの変更は、キャッシュの有効期限が切れてリゾルバが新しいレコードを取得すると反映されます。これにかかる時間は、レコードの以前のTTL（Time to Live）、リゾルバの動作、および権威あるDNS設定が正しいかどうかによって異なります。すべてのユーザーに新しい回答が表示されることを保証する普遍的な時間はありません。
このガイドでは、DNSプロパゲーションとは何か、DNSの変更が異なるタイミングで表示される理由、ドメインの現在の応答を確認する方法、そして更新がまだ完了していないように見える場合の対処法について説明します。
DNSの伝播とは何を意味するのか？
DNSの伝播は、DNSレコードが変更された後、異なるユーザーやDNSリゾルバーが異なる応答を受け取る可能性がある期間を指す一般的な用語です。あるネットワークのユーザーはすでに新しいIPアドレスを表示している一方で、別のユーザーのリゾルバーはキャッシュされた古いアドレスを引き続き返しています。
根本的なDNS変更は、ドメインの権威ネームサーバーに対して行われます。その後、再帰型リゾルバはレコードを取得し、ユーザーのためにキャッシュします。これらのリゾルバは、誰かがドメインにアクセスするたびに必ずしも権威サーバーに再度問い合わせる必要はありません。有効期限内であれば、キャッシュされた回答を再利用することができます。
これが「伝播」をよりよく理解するための理由です キャッシュの有効期限と更新. 同時にすべてのインターネット接続デバイスで更新する必要のある中央のコピーは存在しません。権威あるレコードは、一部のレスolverが古いキャッシュデータを引き続き提供している間でも、すでに正しい場合があります。
DNSキャッシュの仕組み
ブラウザがドメインのIPアドレスを検索する必要がある場合、オペレーティングシステムに名前解決を依頼します。オペレーティングシステムにはキャッシュされた回答がある場合があります。もしない場合は、インターネットプロバイダや企業、またはパブリックDNSサービスによって運用されている設定済みの再帰型リゾルバに問い合わせます。
再帰解決器はキャッシュされた回答を持っている場合もあります。その回答がまだキャッシュの有効期間内であれば、権威ネームサーバーに問い合わせることなくそれを返すことができます。キャッシュレコードの有効期限が切れると、解決器は権威DNSシステムにクエリを送信し、更新された回答を保存します。
キャッシュは参照時間を短縮し、DNSインフラストラクチャへの負荷を軽減します。また、レコードの変更がすべてのリゾルバーに同時に反映されるとは限らないことを意味します。古い回答は、キャッシュの有効期限が切れるか、リゾルバーがそれ以外で更新するまで、リゾルバーによって引き続き使用可能です。
異なるユーザーは異なる再帰型DNSサーバーを使用することがあります。同じ世帯の人々でも、デバイスが異なるDNSサービス、VPN、モバイルネットワーク、またはローカルキャッシュを利用している場合、異なる回答を表示することがあります。
DNSにおけるTTLとは何ですか？
TTLはTime To Liveの略です。 有効期間. これは通常秒単位で測定される値であり、再帰型リゾルバが更新された回答を確認する前にDNSレコードをキャッシュできる期間を示します。
例えば、TTLが 3600 1時間を意味します。リゾルバがそのTTLを持つレコードを取得した場合、更新する必要があるまで通常は最大1時間まで回答を使い続けることができます。TTLが 300 5分を意味します。
変更後に重要になるTTLは、通常、リゾルバーがすでにキャッシュしている古いレコードのTTLです。レコードを変更する直前にTTLを下げても、以前のより高いTTLをキャッシュしていたリゾルバーの待ち時間を短縮できない場合があります。これらのリゾルバーは、元のキャッシュ期間が期限切れになるまで、古い応答を使い続ける可能性があります。
計画された移行では、管理者は事前にTTLを短く設定し、以前のTTLが期限切れになるまで十分な時間を待ってからDNS変更を行います。変更が安定した後、繰り返しクエリを減らすためにTTLを再び長くすることがあります。適切な値は、サービス内容や運用者の変更プロセスによって異なります。
なぜDNSの変更には異なる時間がかかるのか？
最も一般的な理由は、リゾルバーが異なるキャッシュコピーを持っていることです。一部のシステムはすでにレコードを更新している一方で、他のシステムは有効期限の切れていない回答を使用し続けています。また、リゾルバーは独自の更新動作を適用したり、レコードが存在しないことを示す応答（ネガティブアンサー）をキャッシュしたりすることもあります。
ローカルキャッシュはもう1つの層を追加する可能性があります。コンピュータ、ルーター、ブラウザ、またはセキュリティアプリケーションがDNS情報を一時的に保持することがあります。ブラウザを再起動するか、オペレーティングシステムのDNSキャッシュをクリアすることで状況が改善される場合もありますが、再帰型リゾルバがまだキャッシュしている内容は変更されません。
DNSプロバイダーの変更は、追加のタイミング要因をもたらす可能性があります。レジストラでドメインの権威ネームサーバーを変更した場合、リゾルバーは委任情報の更新だけでなく、それらのネームサーバーが提供するレコードも更新する必要があります。これは、同じDNSホスティングサービス内でAレコードまたはAAAAレコードを編集する場合とは異なる変更です。
最後に、更新が権威あるソースで正しくない場合があります。誤ったレコードが編集された場合、変更が保存されなかった場合、ドメインが異なる権威ネームサーバーを使用している場合、またはレコードに構文エラーが含まれている場合、待機しても根本的な設定は修正されません。
DNS伝播と権威DNS更新
権威DNSサーバーは、ドメインまたはゾーンに対する公式レコードを提供します。DNSプロバイダーのコントロールパネルでレコードを編集すると、プロバイダーは提供している権威データを更新する必要があります。
再帰解決サーバーは、クライアントデバイスに対してDNS応答を提供します。変更前のキャッシュデータを保持している可能性があります。そのため、権威サーバーが新しいアドレスを返す一方で、再帰解決サーバーは古いアドレスを引き続き返すことがあります。
この区別はトラブルシューティングの際に有用です。まず、権威ネームサーバーが何を返すかを確認します。もし既に期待されるレコードを返している場合、変更はソース側で公開されており、残りの差異はキャッシュまたはリゾルバーの動作によるものと考えられます。権威サーバーがまだ古い値や値そのものを返していない場合は、DNSプロバイダーの設定とレコード自体を調査してください。
ネームサーバーの変更はもう一つの層を追加します。親DNSゾーンは意図した権威ネームサーバーを指し示す必要があり、それらのサーバーが正しいゾーンを提供する必要があります。ドメインが別のプロバイダーのネームサーバーに委任されている場合、DNSプロバイダー上の正しいレコードは有用ではありません。
一般的なDNSの変更とその影響
変更する 記録 changes the IPv4 address returned for a hostname. Changing an AAAAレコード IPv6アドレスを変更する。両方が存在する場合、クライアントはネットワークおよび接続動作に応じてどちらのアドレスファミリでも使用できる。
変更する CNAMEレコード エイリアスが指すホスト名を変更します。これにより、リゾルバはターゲットの名前とそのアドレスを参照する必要が生じる場合があります。CNAME自体が変更されていない場合でも、ターゲットのレコードへの変更が最終結果に影響を与える可能性があります。
変更する MXレコード ドメイン宛てのメールを受信するメールサーバーに影響を与えます。メールシステムはこれらのレコードをキャッシュすることがあり、メールルーティングの変更が反映されるまで時間がかかる場合があります。メールプロバイダーを変更する際には、管理者はMXレコードおよびSPF、DKIM、DMARCなどの関連するメール認証レコードを別途確認する必要があります。
変更中 ネームサーバー DNSプロバイダがドメインに対して権威を持つように変更します。これには、レジストラでの正しい委任と新しいプロバイダでの正しいゾーン設定が必要です。ネームサーバーの移行は慎重に計画する必要があります。新しいプロバイダでレコードが欠けている場合、ウェブサイト、メール、またはその他のサービスが利用不可になる可能性があるためです。
DNSの変更が反映されたかどうかを確認する方法
使用しているコンピュータからドメインをクエリすることから始めます。Windows、macOS、およびLinuxでは、 nslookup 一般的に入手可能である：
nslookup example.comIPv4アドレスレコードを確認するには、以下を使用します：
nslookup -type=A example.comIPv6の場合：
nslookup -type=AAAA example.comメールサーバーレコードの場合：
nslookup -type=MX example.commacOSおよびLinuxでは、 ディグ より詳細な出力を提供します：
dig example.com A回答セクションのみを表示する：
dig example.com A +noall +answer特定の再帰DNSサーバーをクエリして、回答を比較することができます。例えば：
dig @1.1.1.1 example.com AWindowsでは、DNSサーバーを以下のように指定できます：
nslookup example.com 1.1.1.1置き換える example.com あなたのドメインに関連して。これらの例におけるリゾルバアドレスは、単に利用可能なパブリックリゾルバの一つに過ぎません。組織やプロバイダが使用するDNSサービスもクエリすることができます。
クエリしたリゾルバー、そのレスポンス、および時間を記録します。複数のリゾルバーからの結果を比較することで、差異が特定のリゾルバーに限定されているのか、より広範囲で発生しているのかを判断できます。
権威ネームサーバーをクエリする方法
ドメインの権威ネームサーバーを見つけるには、以下を使用します：
dig example.com NSその後、変更したレコードについて、これらのネームサーバーの1つに直接クエリを実行します。
dig @ns1.example-dns.com example.com A置き換える ns1.example-dns.com ドメインに対して権威サーバーがリストされている場合。直接クエリで期待されるアドレスが返されるが、再帰型リゾルバーが古いアドレスを返す場合、権威データは更新されており、リゾルバーはまだキャッシュされた応答を使用している可能性があります。
他にも質問できます ディグ 委任プロセスを追跡する：
dig +trace example.comこれは、ルートからドメインの権威サーバーに向かってDNS階層をたどるものです。委任の問題を特定するのに役立ちますが、その出力は基本的なチェックで必要とされるものよりも詳細です。
DNSプロバイダーのコントロールパネルを使用している場合は、ドメインが実際にそこに記載されているネームサーバーに委任されていることを確認してください。あるプロバイダーのダッシュボードではレコードが正しく設定されていても、公開されているドメインは別のプロバイダーを指している可能性があります。
もし一部のユーザーが古いウェブサイトを見たらどうなるでしょうか？
まず、権威あるAまたはAAAAレコードが意図した値を持っていることを確認します。次に、複数の再帰型DNSサーバーをクエリし、それらが同じ応答を返すかどうかを確認します。権威データが正しいにもかかわらず、一部のサーバーが古いアドレスを返す場合、キャッシュが原因である可能性が高いです。
次に、ユーザーのローカル設定を確認します。VPN、企業のDNSリゾルバー、セキュリティ製品、ブラウザキャッシュ、またはローカルのhostsファイルは、返されるアドレスに影響を与える可能性があります。モバイル接続などの他のネットワークから結果を比較し、動作が変化するかどうかを確認してください。
また、旧サーバーと新サーバーの両方が応答しているかどうかを確認することも考慮してください。移行が不整合に見える場合、古いホストがキャッシュされたコピーを提供しているか、異なるリダイレクトを行っている可能性があります。DNSレコードは正しいにもかかわらず、リゾルバーが更新していないユーザーに対しては、古いサーバーが引き続きアクセス可能である場合があります。
問題がIPv4のみ、またはIPv6のみに影響している場合は、AレコードとAAAAレコードを個別に比較してください。あるデバイスはIPv6経由で接続する一方で、別のデバイスはIPv4を使用することがあります。一方のアドレスファミリーは新しいサーバーを指しているが、もう一方はまだ古いサーバーを指している可能性があります。
DNS変更後にウェブサイトが利用できない場合、どうすればよいでしょうか？
ドメインの権威ネームサーバーが正しく設定され、到達可能であることを確認してください。その後、それらのサーバーに関連するレコードが存在するか検証してください。最近ネームサーバーを変更した場合は、新しいDNSプロバイダーにウェブサイト、メール、認証、およびサービス用のすべての必須レコードが含まれていることを確認してください。
ドメインへの接続を受け入れるために、宛先サーバーの準備が整っていることを確認してください。DNSを更新するだけでは、クライアントがどこにアクセスするかを変更するだけであり、Webサーバーの設定、証明書のインストール、ファイアウォールのポート開放、またはウェブサイトファイルのコピーは行われません。
DNSが期待されるIPアドレスを返しているにもかかわらずウェブサイトが失敗する場合は、サーバーとアプリケーションを個別にテストしてください。問題はWebサーバー、ファイアウォール、TLS証明書、ホスティング設定、またはアプリケーションにある可能性があります。DNSルックアップは名前解決を確認しますが、サービスが正常であることを確認するものではありません。
デバイスと目的地間の一般的なパスチェックについては、私たちのガイドをご覧ください。 ネットワーク接続の問題を診断するためにtracerouteを使用する. TracerouteとDNSの参照は接続の異なる部分をテストするため、問題を絞り込む際にはこれらを組み合わせて使用すると有用です。
ネガティブキャッシュと「レコードが見つかりません」の結果
リゾルバは、レコードが存在しないという事実をキャッシュすることができます。これをネガティブキャッシングと呼びます。リゾルバがレコード作成前に名前をクエリした場合、レコードが追加された後でも一時的に「見つかりません」という応答を返し続けることがあります。
ネガティブキャッシュにもTTLがあり、これはゾーン内のSOAレコードとリゾルバーのルールに基づいて設定されます。具体的な動作は環境によって異なる場合があります。新しく作成したサブドメインがすぐに解決されない場合は、まず権威ネームサーバーを確認してください。新しいレコードを返す場合、ネガティブキャッシュの有効期限が切れるまで待ってから、他のリゾルバーと比較します。
「レコードが見つかりません」という応答は、レコードが誤ったゾーンに追加されたこと、ホスト名が入力ミスであったこと、またはドメインが異なる権威ネームサーバーを使用していることを示す場合もあります。問題が単なる伝播遅延であると仮定する前に、完全なホスト名、レコードタイプ、DNSプロバイダーを確認してください。
DNS移行を計画する方法
プロダクションサービスのレコードを変更する前に、そのサービスが依存するすべてのホスト名をリストアップし、記録してください。ウェブサイトはAレコードとAAAAレコードを使用することがありますが、メールはMX、SPF、DKIM、DMARCレコードに依存します。アプリケーションも検証やサービスディスカバリのレコードに依存することがあります。
変更が計画されている場合は、関連するTTLを事前に短縮し、宛先を変更する前に少なくとも以前のTTL期間待機してください。DNSを更新する前に、新しいサーバーまたはプロバイダーの準備を行ってください。可能であれば直接テストし、証明書、ファイアウォールルール、アプリケーション設定、メールサービスが準備できていることを確認してください。
変更後、権威ある回答と複数の再帰的解決を確認してください。ウェブサイトの可用性、メール配信、アプリケーションのエラーを監視します。キャッシュされた回答の有効期限が切れる間に一部のユーザーが古いサービスにアクセスし続ける可能性があるため、可能であれば移行中は古いサービスを維持してください。
新しい設定が安定したら、適切なTTLを復元してください。非常に低いTTLを無期限に維持すると、ほとんど変更されないサービスにおいてDNSクエリ量を増加させるだけで、大きなメリットは得られません。
一般的なDNS伝播に関する誤解
よくある誤解の一つは、DNSの変更には必ず24時間または48時間がかかるというものです。固定された普遍的な期間はありません。実際の遅延は、以前のTTL値、リゾルバーのキャッシュ、委任の変更、および権威サーバーの設定の正確さに依存します。
もう一つの誤解は、ブラウザのキャッシュをクリアするとDNSが世界中で更新されるというものです。これはそのデバイスに保存された情報をクリアする可能性がありますが、リモート再帰リゾルバーのキャッシュをクリアすることはできません。同様に、ルーターを再起動するとローカルキャッシュがクリアされることはありますが、権威レコードは変更されません。
3つ目の誤解は、DNSチェッカーが異なる回答を表示することでドメインが壊れていると証明されるというものです。異なる回答は、計画された移行中に発生することがあり、特にリゾルバーが異なるタイミングでキャッシュデータを保持している場合に起こります。重要なのは、権威あるレコードが正しいかどうか、そして残りの相違点が以前のTTLと整合性があるかどうかです。
最終的に、DNSの伝播は宛先サービスの構成を行いません。サーバー、ファイアウォール、TLS証明書、またはアプリケーションが準備されていない場合、正しいIPアドレスでもウェブサイトが利用できないことがあります。
DNS伝播に関するよくある質問
DNSの伝播にはどのくらい時間がかかりますか？
保証された単一の期間はありません。変更はすぐに現れることもあれば、キャッシュレコードの有効期限が切れるまで一貫しない状態が続くこともあります。以前のTTL、リゾルバーの動作、ネームサーバーの変更の有無などが、タイミングに影響を与えます。
TTLを下げると、変更は即時に反映されますか？
いいえ。TTLを下げると、リゾルバが新しいTTLを取得した後の将来のキャッシュに影響します。すでに古いレコードをキャッシュしているリゾルバは、以前のTTLが期限切れになるまでそれを使い続ける可能性があります。
なぜDNSチェッカーは異なる結果を表示するのか？
異なる場所から異なる再帰型DNSリゾルバを照会する場合があります。これらのリゾルバは、異なるキャッシュされた回答を持っている場合や、異なるタイミングで更新される場合、あるいは地理的なDNSポリシーにより異なる回答を受け取る場合があります。
コンピュータのDNSキャッシュをフラッシュ（クリア）する必要がありますか？
自分のデバイスが古い回答をキャッシュしている場合に役立ちます。ただし、インターネットプロバイダー、会社のリゾルバー、またはパブリックDNSサービスによって保持されているキャッシュはクリアされません。
なぜ私のウェブサイトは解決されるが、まだ読み込みに失敗するのですか？
DNSは正しいアドレスを返している可能性がありますが、宛先サーバーまたはアプリケーションに問題がある場合があります。Webサーバー、ファイアウォール、TLS証明書、およびホスティング構成を個別に確認してください。
ネームサーバーの変更は、レコードの変更よりも時間がかかることがありますか？
これには、レジストラおよび親DNSゾーンにおける追加の委任情報が含まれる場合があります。新しいプロバイダもまた、完全かつ正確なゾーンを提供する必要があります。新しい権威ネームサーバーにおける委任とレコードの両方を検証してください。
DNSの変更は、権威ネームサーバーと再帰型リゾルバーが異なる役割を担っており、リゾルバーがTTL値に基づいて回答をキャッシュするため、異なるタイミングで反映されることがあります。あるユーザーは古いアドレスを表示している一方で、別のユーザーはすでに新しいアドレスを受け取っている可能性があります。
調査するには、まず権威ネームサーバーを確認し、その後複数の再帰型リゾルバーからの応答を比較します。レコードの種類、ホスト名、TTL、およびネームサーバーの委任を確認してください。DNSが期待されるアドレスを返しているにもかかわらずサービスが利用できない場合は、問題の原因として宛先サーバーとアプリケーションを別の要素として確認してください。
キャッシングを理解することで、DNSの変更をより容易に計画し、トラブルシューティングを行うことができます。さらにネットワークの基礎知識を深めるために、以下のガイドをご覧ください。 IPアドレス, デフォルトゲートウェイ、 トレースルート.