Я изменил свой TTL с 24 часов до 5 минут. Нужно ли ждать 24 часа, прежде чем менять записи?

Я переношу наше приложение с облачного сервера на выделенный сервер Rackspace.

Я хочу остановить приложение на ~ 5 минут, чтобы скопировать данные с облачного сервера на выделенный сервер, поэтому я не хочу, чтобы запросы отправлялись на старый сервер после того, как я скопировал данные.

Я хочу указать нашу запись DNS на новом сервере, но TTL был установлен на 24 часа. Я изменил его до 300 секунд. Нужно ли ждать 24 часа перед обновлением ip, на который домен указывает / копирует данные?

Любой, у кого есть кэшированная копия записи домена, не будет обновлять ее в течение 24 часов, так что да, если ваше намерение состоит в том, чтобы иметь максимум 5-минутное окно недоступности, вам следует подождать, пока все оставшиеся кэши не обновятся, чтобы они перестали жить чем 5 минут.

Это (потенциально) даже хуже - вам нужно подождать 24 часа после обновления всех ваших авторитетных серверов. Обычный способ получения обновлений заключается в том, что вы вносите изменения в зону на первичном сервере, а затем каждый из вторичных серверов передает данные новой зоны в следующий раз, когда им приходится регистрироваться на первичном сервере. Частота регистрации контролируется интервалом обновления в записи SOA зоны. Таким образом, в худшем случае вам придется ждать интервал обновления зоны + TTL записи.

Возможно, вам также придется так долго ждать фактических изменений записи. 5-минутный TTL не принесет много пользы, если вторичные серверы обновляются только каждые 6 часов. Таким образом, вы, вероятно, хотите уменьшить интервал обновления в зоне, а также на период, который вы хотите иметь возможность быстро вносить изменения.

Имейте в виду, это может не относиться к вашей настройке. Если у вас есть система, которая обновляет все официальные серверы вместе, это не проблема (и я не знаком с настройкой DNS в Rackspace). Но я бы порекомендовал запросить все ваши авторитетные серверы по отдельности ( dig server.example.com @secondaryserver.example.com), чтобы убедиться, что у них есть новый TTL, прежде чем начать 24-часовой отсчет.

Да, ты должен подождать. Даже тогда, конечно, не гарантируется, что все будут уважать 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-запись распространяется почти в реальном времени.