TTLを24時間から5分に変更しました。レコードを変更する前に24時間待つ必要がありますか？

Rackspace ta専用サーバーのクラウドサーバーからアプリを移行しています。

クラウドサーバーから専用サーバーにデータをコピーするために、アプリケーションを5分間停止させたいので、データをコピーした後、古いサーバーにリクエストが送信されることは望ましくありません。

DNSレコードを新しいサーバーに向けたいのですが、TTLは24時間に設定されていました。300秒に変更しました。ドメインがデータを指す/コピーするIPを更新する前に、24時間待つ必要がありますか？

キャッシュされたドメインレコードのコピーを持っている人は24時間更新する必要がないので、もしあなたが5分間の空き時間がないように意図しているなら、未処理のキャッシュがすべて更新されて生きなくなるまで待つべきです5分以上。

それは（潜在的に）さらに悪いことです- 権限のあるサーバーがすべて更新されてから24時間待つ必要があります。更新が発生する通常の方法は、プライマリサーバーのゾーンを変更し、次にセカンダリがそれぞれプライマリサーバーでチェックインするときに新しいゾーンデータを転送することです。チェックインの頻度は、ゾーンのSOAレコードの更新間隔によって制御されます。したがって、最悪の場合、ゾーンの更新間隔+レコードのTTLを待つ必要があります。

また、実際のレコードの変更を待つこともあります。セカンダリが6時間ごとにのみ更新される場合、5分間のTTLはあまり役に立ちません。そのため、ゾーンの更新間隔も、クイック変更を可能にしたい期間だけ短くする必要があります。

気を付けてください、これはあなたの設定に適用されないかもしれません。すべての権限のあるサーバーを一緒に更新するシステムを使用している場合、これは問題ではありません（また、RackspaceのDNSセットアップについてはよく知りません）。ただし、24時間のカウントダウンを開始する前に、すべての権限のあるサーバーに個別に照会して（dig server.example.com @secondaryserver.example.com）新しいTTLがあることを確認することをお勧めします。

はい、お待ちください。もちろん、だれもがTTLを尊重するという保証はありません。

さまざまなコメントと回答をまとめると、完全な手順は次のようになります。

1. 権限のあるサーバーをタイムリーに更新できることを確認してください。
2. TTLを減らします。
3. すべての権限のあるサーバーに新しいttlがあることを確認します。
4. 古いTTLでキャッシュされた値が（ほとんど）キャッシュから削除されるように、古いTTLを待ちます（一部のキャッシュは標準を無視する可能性があるため、すべてのキャッシュから削除されることを保証できません）。
5. 古いサーバー上のサイトを読み取り専用モードにします（または、それができない場合は、「メンテナンス中」ページに置き換えます）。
6. 古いサーバーから新しいサーバーへの最終コピーを実行します（新しいサーバーに読み取り専用サイトが作成されます）。
7. DNSレコードを変更します。
8. すべての権限のあるサーバーに新しいDNSレコードがあることを確認してください。
9. 新しいttlを待ちます（一部のユーザーがサイトに投稿できるようにし、他のユーザーがこれらの投稿の結果を表示しないようにする必要がない場合は、この手順をスキップできます）。
10. 新しいサーバー上のサイトを読み取り/書き込みモードにします。
11. 古いサーバーに、古い読み取り専用コピーであり、ユーザーがDNSを破損した可能性が高いことを通知します。
12. レコードが非準拠DNSキャッシュからドロップされるまでしばらく待ちます。
13. 古いサーバーを廃止します。

他の回答に加えて、https：//www.whatsmydns.net/を使用して、DNSレコードがほぼリアルタイムでどのように伝播しているかを確認できます。