ドメインのAレコードのDNSを変更する(あるIPから別のIPに変更する)場合、人々が新しい情報に移動するまでにどれくらいの時間がかかりますか?それは単に<= TTLですか?以前は時間がかかっていたことがわかっていますが、2009年にはどれくらいの期間を期待できますか?
ドメインのAレコードのDNSを変更する(あるIPから別のIPに変更する)場合、人々が新しい情報に移動するまでにどれくらいの時間がかかりますか?それは単に<= TTLですか?以前は時間がかかっていたことがわかっていますが、2009年にはどれくらいの期間を期待できますか?
回答:
理論的には、誰もが瞬時と関連するTTL値の間のどこかで更新されたAレコードを見る必要があります。ほとんどのレジストラはTTLを24時間IIRCに設定しているため、24時間の間、一部のユーザーは古いアドレスを表示し、一部は新しいアドレスを表示し、変更後24時間までに全員が新しいアドレスを取得する必要があります。 4時間。
TTL値を変更するアクセス権がある場合(つまり、私と同じようにDNSサーバーを実行している場合)、変更を行う前に、TTLを1日程度の小さな値に減らして、伝播期間を大幅に短縮できます。
常にいくつかのバグ、グリッチ、および不適切に構成されたキャッシュが存在するため、一部のユーザーが変更を長く見ないことを意味するため、私は上記の「理論的に」と言います。これは、非常に小さなTTLを使用する場合に特に当てはまります。特定の値以下のTTLを無視するDNSキャッシュを備えたISPがまだいくつか存在するためです。
もう1つの注意点は、レジストラのDNSコントロールパネルとDNSサーバーの間の遅延です。たとえば、123-reg.co.ukによって管理されているドメインに加えられた変更がDNSサーバーに表示されるまでに最大1時間かかることに気づきました。これは、考慮する必要があるTTL値に加えて、さらに1時間です。
これは、クライアントがDNS情報をキャッシュする時間に依存しますが、TTL値に従っている必要があります。ただし、クライアントが情報をキャッシュする期間を決定するので、本当に確信が持てません(すべてのクライアントが手動で解決してTTLを完全に無視できるようになった後)。
IPアドレスの変更が近づいていることを知っているときは、数日前に、通常はTTL値を通常よりも低い値に下げます。そうすれば、変更を加えたときに、変更がより速く伝播します。次に、TTLを再度キックアップします。
マイクに同意した。私たちは通常、クライアントに24〜48時間、世界中のすべてのISPに普及するように伝えます。ほとんどの主要なISPはTTLを尊重し、迅速に更新します。離れた場所のいくつかは時間がかかります。幸運を!
実用上、すべてのDNSサーバーは、Aレコードの瞬時値とAレコードのTTL値の間のどこかで変更を認識します。Wikipediaの記事は、このテーマに関する優れた過去記事があります。
ルーター、ファイアウォール、オペレーティングシステム、アプリケーション内のローカルDNSキャッシュが原因で、個々のアプリケーションがTTL内の変更を認識しない場合があります。Wikipediaの記事で述べたように、「これらのキャッシュは通常、1分程度の非常に短いキャッシング時間を使用します。InternetExplorerには注目すべき例外があります。最近のバージョンではDNSレコードを30分キャッシュします」
再起動(またはルーターの電源再投入)は通常、すべてのローカルDNSキャッシュをフラッシュしますが、Aレコードを変更した後、そこにいるすべてのユーザーがすべてのデバイスを再起動することは期待できません。
Aレコードを直接変更できない場合、変更を加えるアプリケーション(たとえば、コントロールパネルソフトウェア)によって、独自の遅延が発生する可能性があります。
デフォルトのTTLは4時間です。Aレコードの変更を計画している場合は、AレコードのTTLを5分に下げます(変更が適用されるには、4時間以上前に実行する必要があります)。変更後、TTLを4時間に戻します。ほとんどのアプリケーションはすぐに変更を認識しますが、問題を抱えて再起動する必要があるユーザーもいます。
ウィキペディアの記事にも「伝播」についての良い議論があります:「多くの人々は、DNSの変更を行うと、神秘的な48時間または72時間の伝播時間を誤って参照します。ルートサーバー(レジストラーではない)は、ドメインのNSレコードのTTLを制御します。nslookupコマンドを使用すると、これらのTTL値を確認できます。現在、「F」ルートサーバー上のNSレコードのTTLは2日に設定されています。
TTL(ユーザーが制御するもの、Brian Clapperの優れたアドバイスを参照)、および一部のアプリケーション内のキャッシュ時間が長くなる可能性があるほか、権威ネームサーバー間の同期時間もあります。すべてのネームサーバーがNOTIFYを受信する場合はゼロに近くなる可能性があり、(SOAレコードの設定によっては)NOTIFYが欠落した場合(場合によっては何か)に数時間かかる可能性があります。
したがって、ブライアンクラッパーのアドバイスを強調するために、事前に計画を立てます。
Windowsと内部で話をしている場合、それは元のTTLに依存します。変更を行うことを事前に知っていた場合、AレコードのTTLを5分に設定します。次に、変更が行われた後、TTLを通常の量に戻しました。
あなたがインターネットで話しているなら、すべての賭けはオフです。すでに述べたように、TTLを完全に無視しているキャッシュドメインコントローラーがいくつかあります。それらのケースでは、48時間という一般的なルールを適用しました。ただし、ドメインが以前に別のプロバイダーによってホストされていて、ドメイン上のSOAを取り除かれていない場合、DNSサーバーを使用するクライアントは引き続き正しく指定されません。BellSouth(現在はAT&T)でこの問題が発生しました。
(置き換えられた)レコードのTTLより大きくなる可能性があります。多くのクライアントは、TTLが低すぎる場合は無視するか、TTLを他の値(1時間など)にバインドします。他のキャッシュがあります。Firefox(たとえば)はDNSを(TTLを無視して)1分間キャッシュしますが、一部のパッチ/構成ではこれを1時間に引き上げます。
悲しい(しかし本当の)答えは、あなたの(DNS)答えを誰が求めているかによる。