Как отслеживать распространение DNS после смены регистратора

Миграции DNS выглядят просто на бумаге, но создают реальные инциденты на практике. Записи обновляются в регистраторе, значения TTL истекают, весь интернет обновляет кеш DNS, и всё работает. Или это то, что должно было произойти. На самом деле, частичное распространение происходит регулярно: одни DNS резолверы отдают новую запись, другие отдают старую, и поведение пользователей разделяется по региональным и ISP линиям. Это руководство описывает, как отслеживать миграцию DNS, что проверить и как обнаружить сбои, которые остаются незаметными при распространении.

Как работает распространение DNS

Когда вы изменяете DNS запись в регистраторе, старая запись остаётся в кешах резолверов по всему миру до истечения её TTL. Различные резолверы обновляются в разные времена; некоторые строго соблюдают TTL, а некоторые округляют его. В результате получается временное окно (обычно один TTL плюс несколько минут, но иногда часы), в течение которого разные пользователи видят разные записи.

Ваш собственный резолвер может обновиться последним, потому что операционные системы и приложения агрессивно кешируют DNS на уровне выше OS-резолвера. Классическая ошибка — проверить новый эндпоинт пингом со своего ноутбука, убедиться что это работает, объявить распространение завершённым, и на следующее утро обнаружить что клиенты из ЕС всё ещё обращаются к старому IP.

Что отслеживать во время миграции

Четыре типа DNS записей охватывают обычные случаи миграции. Каждый требует отдельного мониторинга на время этих изменений.

• A и AAAA записи для хоста, который вы переносите. Главная проверка: новый IP адрес работает?
• CNAME записи для любых поддоменов, которые их используют. Цепочки CNAME могут молча разорваться, если одна ссылка указывает на несуществующий хост.
• MX записи, если задействована электронная почта. Плохой перенос MX приводит к молчаливому отклонению писем без очевидного симптома, видимого пользователю.
• NS записи, если вы переключаетесь на другого поставщика DNS. NS запись — это основа; если она неправильна, ничего другого не имеет значения.

Проверка в нескольких регионах

DNS монитор, работающий с одного резолвера в одном регионе, полностью теряет смысл. Интересный вопрос — распространилась ли новая запись везде, а не обновился ли локальный резолвер вашего монитора.

Такие инструменты как dnschecker.org позволяют вам интерактивно проверить распространение в нескольких регионах. Для автоматического мониторинга вам нужен инструмент, который проверяет несколько резолверов и предупреждает о расхождениях. Если ваш инструмент мониторинга проверяет только из одного местоположения, запустите дополнительную проверку вручную из другого региона (вашего телефона в мобильной сети обычно достаточно) перед тем как объявить миграцию завершённой.

Снижение TTL перед миграцией

Самая полезная подготовка — снизить TTL затронутых записей за 24–48 часов до изменения. Новый TTL должен сначала распространиться, поэтому период подготовки важен.

• Перед миграцией: снизьте TTL с значения по умолчанию 3600 (1 час) до 60 (1 минута). Дождитесь распространения изменения TTL, что займёт один цикл старого TTL плюс буфер.
• Во время миграции: обновите запись. Резолверы обновляют кэш в течение 60 секунд.
• После миграции: мониторьте в течение 24 часов, чтобы поймать застрявшие кэши. Восстановите TTL до 3600 после подтверждения завершения распространения.

Обнаружение молчаливого отказа при частичном распространении

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

Три сигнала его выявят. Всплеск тикетов поддержки, которые упоминают старое поведение или старый хостнейм. Расхождение в метриках пользователей между регионами (конверсия в США падает, а в ЕС остаётся плоской). Монитор, который явно проверяет резолвер каждого региона отдельно, предупреждает о расхождениях. Мониторьте все три как минимум 24 часа после миграции.

Контрольный список перед миграцией

За два дня до миграции снизьте TTL всех затронутых записей до 60 секунд. За день до миграции добавьте DNS мониторы для новых значений записей, ожидайте срабатывания, потому что записи ещё не изменились. В день миграции обновите записи. Мониторы станут зелёными. Наблюдайте 24 часа, обращая внимание на расхождения в нескольких регионах и объём тикетов поддержки. После того как оба показателя будут чистыми в течение 24 часов, восстановите TTL и удалите временные мониторы. Миграция завершена, когда метрики чистые, а не когда записи обновлены.