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

37

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

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

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

domain-name-system rackspace ttl

— wobbily_col
источник

9

Кстати, даже если вы ждете TTL, я настоятельно рекомендую вам отредактировать конфигурацию на старом сервере, чтобы убедиться, что там больше не будут приниматься обновления. Не все распознаватели DNS на самом деле соответствуют стандартам.

— Питер Грин

5

При переносе веб-приложения от одного хостинг-провайдера к другому я использовал переадресацию порта ssh, чтобы все посетители использовали старый IP-адрес, направленный на новый сервер.

— Касперд

58

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

— Джефф Меден
источник

23

... это на 24 часа since they last cached it. Это может быть что угодно от 1 до 86399 секунд.

— user9517 поддерживает GoFundMonica

6

@ Iain Вы должны предположить худшее, поскольку любой или все из них могли просто кэшировать его непосредственно перед изменением.

— Бармар

6

@ Бармар Ничего не думай. Множество провайдеров просто игнорируют TTL.

— user9517 поддерживает GoFundMonica

13

@ Iain Я работал на Akamai, CDN, который интенсивно использует короткие TTL (например, 60 секунд) для балансировки нагрузки. Я помню, что мы провели исследование и обнаружили, что большинство интернет-провайдеров подчиняются нашим TTL.

— Бармар

1

Я работаю в компании, занимающейся веб-хостингом, наш опыт показывает, что низкие TTL скорее игнорируются, чем выше.

— Хенрик - перестань причинять боль Монике

39

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

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

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

— Гордон Дэвиссон
источник

1

Это должен быть принятый ответ.

— Dotancohen

4

Похоже, вы игнорируете протокол DNS Notify, который сообщает подчиненным серверам обновляться вскоре после обновления мастера. Большинство DNS-серверов используют эту функцию.

— Бармар

@ Бармар: Это правда, но в то же время мастер может занять некоторое время для обновления в зависимости от провайдера. (Например, некоторые провайдеры перестраивают зоны только из базы данных каждые 5 или 15 минут, хотя современные делают это мгновенно.)

— grawity

1

Мой комментарий касался только вопроса ожидания интервала обновления, который в основном устарел в наши дни. Ожидание обновления мастера - это правда, если только вы не управляете своим собственным мастером. Но я думаю, что вряд ли им придется иметь дело с точным временем, когда все станет безопасным для обновления; Дополнительные 5-15 минут не должны иметь большого значения. Смысл исходного вопроса заключается в том, нужно ли им ждать целый день.

— Бармар

1

@GordonDavisson: Если не доверяешь - проверяй. dig +nssearch example.comполезный инструмент для быстрого сравнения SOA на всех серверах; nsdiff показывает фактические различия.

— Гравитация

23

Да, ты должен подождать. Даже тогда, конечно, не гарантируется, что все будут уважать TTL.

— Свен
источник

6

+1 потому что не все подчиняются TTL, я видел отставших через неделю после внесения изменений в DNS. Один из способов, которыми я занимался в прошлом, состоял в том, чтобы установить новое уникальное имя в качестве псевдонима на новом сайте и использовать перенаправление со старого сайта, чтобы перенаправить пользователей из старого домена в новый, например, из www.mycompany. .com -> newsite.mycompany.com

— Джонни

Да, но многие люди по праву презирают идею использования нового имени. Названия брендов. Кроме того, это работает только для HTTP и почти ничего.

— Свен

8

Другой вариант - настроить старый сервер в качестве обратного прокси для нового сервера. Затем вы можете оставить это на неделю или около того после коммутатора и отключить его, когда через него не проходит трафик.

— BDSL

1

Люди с хорошими DNS-серверами, которые подчиняются TTL, никогда не увидят новый домен. И хотя это «только» работает с HTTP (S), я думаю, вы обнаружите, что HTTP является довольно распространенным протоколом в Интернете. Предложение bdsl о настройке обратного прокси-сервера еще лучше, но это больше работы

— Джонни

@Johnny Проблема с новым доменом заключается в том, что вы рискуете, если люди добавят этот домен в закладки. Если вы не планируете оставить указанный новый домен доступным навсегда.

— Боб

5

Собрав воедино различные комментарии и ответы, вся процедура будет выглядеть примерно так.

Убедитесь, что вы можете своевременно обновлять свои авторизационные серверы.
Уменьшите TTL.
Проверьте, все ли авторизированные серверы имеют новый ttl.
Дождитесь старого TTL, чтобы кэшированные значения со старым TTL были (в основном) удалены из кэшей (вы не можете гарантировать, что они будут удалены из каждого кэша, поскольку некоторые кэши могут игнорировать стандарты).
Переведите сайт на старом сервере в режим «только для чтения» (или, если вы не можете этого сделать, замените его страницей «Мы не обслуживаемся»).
Выполните окончательное копирование со старого сервера на новый (в результате сайт на новом сервере будет доступен только для чтения).
Измените записи DNS.
Убедитесь, что все авторизационные серверы имеют новые записи DNS.
Дождитесь нового ttl (вы можете пропустить этот шаг, если вас не волнует, что некоторые пользователи могут вносить свой вклад в сайт, а другие не видят результатов этих вкладов).
Переведите сайт на новом сервере в режим чтения / записи.
Поместите на старый сервер уведомление о том, что это устаревшая копия только для чтения и что пользователь, вероятно, сломал DNS.
Подождите, пока записи выпадут из несовместимых кешей DNS.
Вывести из эксплуатации старый сервер.

— Питер Грин
источник

5

В дополнение к другим ответам вы можете использовать https://www.whatsmydns.net/, чтобы проверить, как ваша DNS-запись распространяется почти в реальном времени.

— Мадис Нымме
источник