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