TTL= 24時間から5分に変更しました。レコードを変更する前に24時間待つ必要がありますか？
専用サーバーであるRackspaceのクラウドサーバーからアプリを移行しています。
アプリケーションを約5分間停止して、クラウドサーバーから専用サーバーにデータをコピーしたいので、データをコピーした後に要求が古いサーバーに送信されないようにします。
DNSレコードを新しいサーバーに向けたいのですが、TTLが24時間に設定されています。これを300秒に変更しました。IPを更新する前に24時間待つ必要がありますか？そのドメインはデータをポイント/コピーしていますか？
ドメインレコードのキャッシュされたコピーを持っている人は誰でもそれを24時間更新することはありません。そのため、もしあなたの意図が最大で5分の利用できない時間帯を持つことである場合は、すべての未処理のキャッシュが更新されて生きてなくなるまで待つ必要があります5分より。
それは（潜在的に）それよりもさらに悪いです-権威サーバーのallが更新されてから24時間待つ必要があります。更新が行われる通常の方法は、プライマリサーバーのゾーンに変更を加え、次にセカンダリがプライマリにチェックインしたときに、それぞれのセカンダリが新しいゾーンデータを転送することです。チェックインの頻度は、ゾーンのSOAレコードの更新間隔によって制御されます。したがって、最悪の場合、ゾーンの更新間隔+レコードのTTLを待つ必要があります。
または実際のレコードが変更されるまでこれだけ待つ必要があるかもしれません。 5分TTLセカンダリが6時間ごとにのみ更新する場合、あまり効果がありません。したがって、ゾーンの更新間隔も必要な期間だけ短くする必要があるでしょう。すばやく変更できるようにします。
注意してください、これはあなたの設定には適用されないかもしれません。すべての権限のあるサーバーを一緒に更新するシステムがある場合、これは問題ではありません（私はRackspaceのDNS設定に詳しくありません）。ただし、権威サーバーのallを個別にクエリすることをお勧めします（Dig server.example.com @secondaryserver.example.com）24時間のカウントダウンを開始する前に、新しいTTL=であることを確認してください。
はい、お待ちください。もちろんそれでも、誰もがTTLを尊重するとは限りません。
他の回答に加えて、 https://www.whatsmydns.net/ を使用して、DNSレコードがほぼリアルタイムでどのように伝播しているかを確認できます。 
さまざまなコメントをまとめて、完全な手順に答えると、次のようになります。
- 権限のあるサーバーをタイムリーに更新できることを確認してください。
- TTLを減らします。
- すべての権限のあるサーバーに新しいttlがあることを確認します。
- 古いTTLを待って、古いTTLのキャッシュされた値が（ほとんど）キャッシュから削除されるようにします（すべてのキャッシュから削除されることを保証することはできません）一部のキャッシュは標準を無視する可能性があるためです）。
- 古いサーバーのサイトを読み取り専用モードにします（または、それができない場合は、「メンテナンスのため停止中」ページに置き換えます）。
- 古いサーバーから新しいサーバーへの最終的なコピーを実行します（結果として、新しいサーバーで読み取り専用サイトになります）。
- DNSレコードを変更します。
- すべての権限のあるサーバーに新しいDNSレコードがあることを確認します。
- 新しいttlを待ちます（一部のユーザーがサイトに投稿でき、他のユーザーがそれらの投稿の結果を表示しないことを気にしない場合は、この手順をスキップできます）。
- 新しいサーバーのサイトを読み取り/書き込みモードにします。
- 古いサーバーに、それが古い読み取り専用コピーであり、ユーザーがDNSを破損している可能性があることを通知します。
- 準拠していないDNSキャッシュからレコードが削除されるまでしばらく待ちます。
- 古いサーバーを廃止します。