Зачем думать про DNS TTL перед миграцией
Почти любая миграция (смена IP, переезд в другой датацентр, новый балансировщик, разделение фронта и API, вынос части сервисов на отдельные поддомены) упирается не в копирование данных, а в то, как разные резолверы и кэши принимают изменения в DNS.
Вы меняете запись, а часть пользователей продолжает ходить на старый адрес. Отсюда типовые симптомы: «DNS не обновился», «у меня всё работает, а у клиента нет», «половина трафика ещё улетает на старый сервер».
В этой точке важны три термина: DNS TTL, DNS propagation и cutover. TTL задаёт время жизни ответа в кэше. Propagation на практике — это сумма задержек из-за кэширования на разных уровнях. Cutover — управляемый момент переключения, который вы хотите сделать предсказуемым и обратимым.
Плохой сценарий выглядит так: TTL оставили 86400, запись поменяли «в день Х», а затем сутки ловят смесь трафика на старом и новом окружениях. Хороший сценарий: заранее управлять TTL, подготовить совместимость двух площадок и сделать переключение контролируемым.
Как реально работает TTL и почему «propagation» — это про кэши
TTL — число секунд, которое авторитетный DNS сообщает кэширующим резолверам: «можешь хранить мой ответ столько-то». Важно понимать, что цепочка резолвинга длиннее, чем кажется, и кэширование происходит в нескольких местах.
Где кэшируется DNS
- Рекурсивные резолверы провайдеров/корпоративных сетей: основной источник ситуации «часть аудитории видит старое».
- Локальные резолверы на хостах и в контейнерной инфраструктуре (systemd-resolved, dnsmasq и аналоги): особенно заметно в CI/CD и при долгоживущих сервисах.
- Кэши приложений: некоторые рантаймы и библиотеки кэшируют резолвинг дольше ожидаемого.
- ОС/клиенты: локальные DNS-кэши встречаются, но чаще это не главный фактор.
Поэтому DNS propagation лучше воспринимать как вопрос: «когда конкретный резолвер перестанет отдавать закэшированный ответ и пойдёт за новым». TTL задаёт ориентир, но не гарантирует идеального поведения во всех сетях, особенно при ошибках и нестандартных настройках.
Negative caching: почему «удалил — добавил» может дать простой
Отдельная ловушка — negative caching: кэширование отсутствия записи (NXDOMAIN или NOERROR/NODATA). Длительность такого кэша задаётся параметрами SOA зоны и настройками резолвера. Типичный анти-паттерн во время миграции: «сначала удалим запись, потом добавим» — а в результате часть пользователей продолжает получать “записи нет” даже после добавления.
Если нужно «переопределить» запись, обычно безопаснее менять значение существующей записи, чем удалять её и создавать заново: так вы уменьшаете риск отрицательного кэша и непредсказуемых пауз.
TTL как инструмент: что снижать, когда и до каких значений
TTL — не кнопка «поставь 60 и будет счастье». Низкий TTL увеличивает частоту запросов к авторитетным серверам и может сделать инфраструктуру чувствительнее к проблемам DNS. Но на время миграции управляемый TTL сильно повышает предсказуемость cutover.
Практичная стратегия TTL перед cutover
- За 24–48 часов снизить TTL на целевых записях (обычно A/AAAA/CNAME) до 300–600 секунд. Если текущий TTL высокий (например, 86400), снижение нужно делать заранее: иначе «старый высокий TTL» уже закэширован, и ускорения не будет.
- За 1–2 часа до переключения убедиться, что большинство проверяемых резолверов уже видят короткий TTL (то есть обновление TTL «вымыто»).
- После успешного переключения вернуть TTL к рабочему (например, 3600–14400), когда уверены, что откат не потребуется.
Комфортный компромисс на время миграции — TTL 300. Для небольших проектов можно опускаться до 60–120, но смысл появляется только если вы реально готовы быстро откатывать и внимательно мониторите метрики/логи.
Снижение TTL сработает только после истечения предыдущего TTL в кэше. Поэтому «снизили TTL за 10 минут до переезда» в большинстве случаев равно «не снизили».
Записи A/AAAA/CNAME и ловушки миграции
В миграциях чаще всего меняют A и AAAA (IPv4/IPv6), иногда CNAME. Важно понимать, как эти записи ведут себя в период смешанного трафика.
A и AAAA: двойной стек и неожиданные маршруты
Если домен доступен по IPv6, у него есть AAAA. Ошибка «переехали только A» встречается постоянно: часть клиентов предпочитает IPv6 (механики вроде Happy Eyeballs), и они продолжают ходить на старый IPv6-адрес, даже если IPv4 уже обновлён.
Практика: в день миграции воспринимайте A/AAAA как единый комплект. На старом и новом окружении временно держите одинаковую версию сайта/API, чтобы смешанный трафик не ломал сессии и не приводил к расхождению данных.
CNAME: цепочки и кэш на разных звеньях
CNAME удобен для маршрутизации, но резолвер кэширует не только конечный A/AAAA, но и сам CNAME. В итоге вы ожидаете «TTL 300», а один элемент цепочки живёт дольше. Чем больше звеньев, тем меньше предсказуемость.
Если миграция делается через смену CNAME на другой таргет, уменьшайте TTL и на CNAME, и на целевых A/AAAA (если они под вашим контролем). Параллельно проверьте, что новая цель корректно обслуживает все нужные имена: SNI/сертификаты, виртуальные хосты, редиректы.
Если в процессе вы трогаете доменную инфраструктуру целиком (смена NS, перенос зоны), полезно заранее пройтись по рискам и регламенту: перенос домена и DNS: EPP-код, сроки и что проверить.
Split-brain при DNS cutover: что это и почему случается
Split-brain в контексте DNS-миграции — ситуация, когда разные пользователи (или один пользователь в разное время) попадают то на старую, то на новую инфраструктуру, а системы при этом работают как независимые. Самое опасное — когда оба окружения принимают запись данных: заказы, платежи, письма, изменения профиля.
Причины обычно приземлённые:
- Длинный TTL и неизбежный период смешанного трафика.
- Несогласованность A и AAAA (или забытый IPv6).
- Старый сервер продолжает обслуживать «боевую» запись в свою локальную БД.
- Сессии/кэш привязаны к конкретному узлу, нет общей точки истины.
- Непредсказуемый кэш в приложении (особенно у long-running процессов).
Как безопасно пережить период смешанного трафика
Полностью избежать смешанного трафика в интернете обычно нельзя. Задача — сделать так, чтобы смешанный трафик не был опасен.
- Один источник истины для данных на время cutover: общая БД, репликация, режим read-only на старой стороне или проксирование записи.
- Сессии и кэш вынести из локального узла (общий стор), либо включить липкие сессии на балансировщике, если архитектура это допускает.
- Старый фронтенд в режиме «ограждения»: можно отдавать информ-страницу или редирект, но помните, что редирект не «лечит» DNS сам по себе: клиент всё равно резолвит старый IP, пока жив кэш.
- Фича-флаг на опасные операции: временно ограничить редкие, но критичные изменения состояния, если вы не уверены в консистентности.
Если вы не умеете синхронизировать состояние между старым и новым окружением, планируйте миграцию так, будто split-brain неизбежен: и заранее закладывайте read-only или единый backend для записи.
Пошаговый план cutover: от подготовки до стабилизации
Ниже сценарий, который обычно работает для сайтов и API и помогает провести переключение с понятным уровнем риска.
1) Подготовка за 2–7 дней
- Соберите инвентарь DNS: A/AAAA/CNAME, поддомены, записи для API/админки, служебные записи для верификаций.
- Определите, что именно переключаете: A/AAAA, CNAME или NS (перенос зоны).
- Проверьте готовность нового окружения: все имена обслуживаются, верные редиректы, health checks, корректные виртуальные хосты, сертификаты.
- Подготовьте мониторинг: коды ответов, latency, 4xx/5xx, ошибки приложения, метрики БД и очередей.
2) Снижение TTL (обычно за 24–48 часов)
Снизьте TTL на записях, которые будете менять. Если меняются и A и AAAA — снижайте обе. Если миграция через CNAME — снижайте TTL и на CNAME, и на цели, если контролируете.
Дальше ключевое — дождаться, пока старый высокий TTL реально истечёт в кэшах.
3) Проверка «как видят мир» разные резолверы
Проверяйте не только «у себя», а через несколько сетей. Для диагностики чаще всего достаточно dig. Смотрите TTL прямо в ответе.
dig A example.com +noall +answer
dig AAAA example.com +noall +answer
dig CNAME www.example.com +noall +answer
Если вы ожидаете TTL 300, а видите тысячи, значит, либо кэш ещё не вымыт, либо вы смотрите через резолвер, который недавно закэшировал старое значение.
4) Момент переключения
Делайте cutover в заранее выбранное окно, когда команда на связи и есть план отката.
- Обновите DNS записи (A/AAAA/CNAME) на новые значения.
- Если состояние синхронизировать нельзя: переведите старую систему в read-only до переключения, чтобы не плодить расхождения.
- Держите старую инфраструктуру живой минимум 1–2 TTL-окна после переключения (часто это несколько часов), чтобы клиенты со старым кэшем не получали ошибку подключения.
5) Стабилизация и возврат TTL
Когда трафик стабильно пришёл на новую площадку, ошибки не растут, данные консистентны — возвращайте TTL к рабочему значению. Старую площадку не выключайте «в ноль» мгновенно: она полезна как страховка и как источник логов для понимания, кто ещё «сидит» на старом резолве.
DNS migration checklist: что проверить, чтобы DNS не стал точкой отказа
Перед снижением TTL
- Зафиксировали текущие значения A/AAAA/CNAME и TTL (для быстрого отката).
- Проверили, есть ли IPv6, и что будет с AAAA.
- Нашли забытые зависимости: отдельные поддомены под API, callback-адреса, интеграции.
Перед cutover
- TTL на нужных записях уже короткий и «вымытый» из большинства проверяемых кэшей.
- Новая площадка корректно отвечает по всем хостнеймам (включая www/без www, API, админку).
- HTTPS готов: сертификаты, SNI, цепочка, редиректы.
- Есть план против split-brain: где запись данных, что с сессиями, как ограничиваем старую сторону.
После cutover
- Проверили A/AAAA на нескольких резолверах и в разных сетях.
- Смотрим логи старого сервера: есть ли ещё запросы, какие сети «застряли».
- Вернули TTL к норме только после уверенности, что откат не нужен.
Типовые вопросы и быстрые ответы
Почему у меня TTL 300, а «обновляется» дольше?
Потому что 300 — это максимум времени хранения ответа после последнего запроса на конкретном резолвере. Если резолвер получил ответ час назад с TTL 3600, он будет держать его до истечения 3600. Плюс возможны дополнительные кэши на стороне приложений.
Можно ли сделать мгновенный cutover только DNS-ом?
Для широкой аудитории — практически нет. DNS даёт «постепенное переключение» через кэши. Почти мгновенный cutover достигают архитектурой (балансировщики, Anycast, глобальные прокси/CDN, L7-маршрутизация), но это отдельная тема.
Как минимизировать split-brain, если часть трафика всё равно пойдёт на старое?
Сведите к нулю расхождения состояния: общий стор для данных/сессий, read-only на старом, совместимые версии приложения по обе стороны и понятный план отката.
Итоги
DNS TTL — управляемый рычаг, который помогает сделать миграцию предсказуемой. Но сам по себе TTL не отменяет кэширование на разных уровнях и не гарантирует мгновенного переключения. Планируйте снижение TTL заранее, учитывайте A/AAAA, не усложняйте CNAME-цепочки и относитесь к периоду смешанного трафика как к норме.
Если воспринимать DNS как часть релиза (с проверками, окном, откатом и мониторингом), то даже сложный cutover превращается в понятную операцию, а «DNS propagation» перестаёт быть лотереей.
