DNS TTL: как работает кэш, negative caching и как сделать безопасный cutover при смене IP

Зачем вообще разбираться в DNS TTL

Когда вы меняете IP у сайта, переносите почту или переключаете трафик между двумя площадками, почти всегда всплывает вопрос: «Почему у меня уже обновилось, а у пользователей — нет?». В большинстве случаев ответ лежит в связке TTL + кэши резолверов + negative caching (кэширование отрицательных ответов).

TTL (Time To Live) — это время (в секундах), на которое DNS-ответ можно хранить в кэше. Важно: TTL живёт не «в браузере», а в цепочке резолверов: stub-резолвер ОС, корпоративный DNS, рекурсивный DNS провайдера или публичный резолвер, иногда — дополнительные кеширующие прослойки.

Ниже разберём, как TTL влияет на «propagation», почему «создали запись, а её всё равно нет», что на практике означает SOA MINIMUM, и как подготовить предсказуемый cutover при смене IP.

TTL в ответе DNS: где он на самом деле и что означает

TTL задаётся на уровне конкретной записи (точнее RRset). У A/AAAA, CNAME, MX, TXT может быть свой TTL. В DNS-панелях он обычно настраивается рядом с записью, но иногда есть общий TTL «по умолчанию» для всей зоны.

Пока TTL не истёк, кеширующий резолвер имеет право отвечать из кэша, даже если авторитативные DNS-серверы уже отдают новый IP. Это и есть основная причина, почему «propagation» ощущается как задержка.

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

Кто кэширует и почему ваши проверки иногда «врут»

Типичная цепочка выглядит так:

• Ваш сервер/ноутбук (stub resolver) спрашивает рекурсивный резолвер (часто это DNS провайдера или публичный резолвер).
• Рекурсивный резолвер при необходимости идёт к авторитативным NS вашей зоны.
• Рекурсивный резолвер сохраняет ответ в кэше на TTL секунд и раздаёт его клиентам.

Из-за этого два человека могут видеть разные ответы: они используют разные резолверы, у которых разное состояние кэша и разная политика.

Propagation: почему это не «одна магическая задержка»

Термин «propagation» часто понимают как «DNS обновится по всему миру за N минут/часов». На практике это сумма факторов, и их полезно разделять.

• TTL у конкретной записи: как быстро кэш «отпустит» старое значение.
• Negative caching TTL для NXDOMAIN/NOERROR NODATA: как долго кэшируется отсутствие записи.
• Время обновления зоны на авторитативных серверах (особенно если есть secondary/hidden master/несколько площадок).
• Политики резолверов: минимальный/максимальный TTL, prefetch, агрессивное кэширование и т.п.

Если управлять TTL заранее, propagation становится предсказуемой: вы понимаете верхнюю границу задержки в худшем случае и планируете окно переключения.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Negative caching: почему «я создал запись, а её всё равно нет»

Negative caching — это кэширование отрицательных DNS-ответов. Два самых частых сценария:

• NXDOMAIN: доменное имя/поддомен не существует (например, new.example.com ещё не создан).
• NODATA (NOERROR): имя существует, но записи нужного типа нет (например, имя есть, но нет AAAA).

Если резолвер получил отрицательный ответ, он может кэшировать его на время, указанное в SOA зоны (подробнее ниже). Поэтому ситуация «создали запись, но она не видна» часто связана не с propagation, а с тем, что резолвер честно держит закэшированный NXDOMAIN.

Практический вывод: если вы планируете новый поддомен под переключение, создайте записи заранее (пусть даже временно указывают на старую инфраструктуру), чтобы не упереться в negative caching в момент cutover.

SOA MINIMUM и negative TTL: что реально означает поле minimum сегодня

В SOA есть несколько чисел: serial, refresh, retry, expire и minimum. Исторически minimum трактовали как «минимальный TTL для записей», но в современной практике и по RFC это значение используется как negative caching TTL (его часто называют negative TTL).

Если minimum стоит, например, 86400 (сутки), то NXDOMAIN на поддомен может «прилипнуть» на сутки у кеширующих резолверов.

Что обычно работает на практике:

• Для активно управляемых зон держать minimum в разумных пределах (часто 300–900 секунд).
• Для «редко меняющихся» зон можно держать больше, но осознанно, понимая цену задержки при появлении новых имён/типов записей.

Нюанс: как и с обычным TTL, резолверы могут ограничивать экстремальные значения локальной политикой. Но корректный SOA заметно уменьшает «мистику» вокруг появления новых записей.

Switch IP и cutover без боли: стратегия TTL по шагам

Самая частая операция — switch IP для A/AAAA (или смена цели CNAME), чтобы переключить сайт на новый сервер. В идеале это превращается в контролируемый cutover с понятным окном.

Шаг 1. Определите текущие TTL и зависимые записи

Сначала зафиксируйте, что именно переключаете и что может повлиять на результат:

• A/AAAA у @ и www;
• CNAME (если используются алиасы);
• MX (если параллельно переносите почту);
• TXT (SPF/DKIM/DMARC обычно не трогают при switch IP сайта, но иногда меняют в одном окне работ).

Параллельно проверьте отрицательное кэширование: посмотрите SOA и значение minimum.

Шаг 2. Заранее снизьте TTL (и дождитесь, пока «вымывается» старый)

1. За 24–48 часов до cutover снизьте TTL у целевых записей до 300–600 секунд.
2. Подождите время, равное старому TTL, чтобы изменение TTL успело «дотечь» до большинства кэшей.
3. В момент переключения измените значение записи: теперь окно ожидания обычно укладывается в новый TTL.
4. После стабилизации верните TTL на более высокий (например, 3600–14400), чтобы снизить нагрузку на DNS.

Критичный момент: снижение TTL не действует мгновенно. Если раньше TTL был 86400, часть резолверов будет держать старый ответ до суток, даже если вы уже поставили 300. Поэтому снижать TTL «прямо перед переключением» чаще всего бесполезно.

Шаг 3. Не забудьте про AAAA и двойной стек

Если у домена есть AAAA, пользователи с IPv6 могут продолжать ходить на старую инфраструктуру, даже если A уже сменили. При cutover проверяйте оба типа записей и готовность маршрутизации/веб-сервера на IPv6.

Шаг 4. Планируйте откат с учётом кэшей

Откат — это тот же switch IP, только обратно. Если держите TTL 300, то «в худшем случае» возврат трафика будет происходить примерно так же быстро. Если же после переключения вы сразу подняли TTL до 14400, а затем через 10 минут решили откатываться — вы сами увеличили время «расклейки» проблемы.

Если вы делаете перенос на новый сервер, проще заранее поднять тестовую копию сайта на отдельном имени, а затем переключать A/AAAA. Для проектов на VDS это удобно тем, что вы можете параллельно держать старую и новую инфраструктуру, прогнать healthchecks и только потом делать cutover в DNS.

Как проверять DNS: dig и что именно в нём смотреть

Для диагностики полезнее не «онлайн-чекер», а понимание, что отвечает конкретный резолвер, и что отдают авторитативные серверы. Базовый инструмент — dig.

Проверяем авторитативный ответ

Смысл: минуем рекурсивный кэш и смотрим, что реально отдают NS зоны.

dig example.com SOA
dig example.com NS
dig example.com A
dig example.com AAAA

Дальше — запрос к конкретному NS (из списка NS):

dig @ns1.example-dns.tld example.com A
dig @ns1.example-dns.tld www.example.com CNAME

В выводе dig обычно смотрят:

• TTL у записи (левый столбец, секунды);
• секции ANSWER/AUTHORITY/ADDITIONAL;
• SOA и значение поля minimum (кандидат на negative caching TTL).

Проверяем, что видит конкретный рекурсивный резолвер

Это помогает, когда пользователи жалуются «у нас по-прежнему старый IP». Тогда проверяем у «их» резолвера (если известен) или у типовых публичных:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @9.9.9.9 example.com A

Если у рекурсивного резолвера ответ старый, а у авторитативного — новый, значит проблема именно в кэше и TTL: ждём, либо временно используем другой резолвер для проверки и мониторинга.

Диагностика negative caching (NXDOMAIN)

Если поддомен «не существует» у части пользователей, посмотрите, какой ответ приходит:

dig new.example.com A

Если там NXDOMAIN — затем посмотрите SOA в AUTHORITY и значение minimum. Часто именно оно объясняет, почему запись «появится не сразу», даже если вы её уже создали.

Если вы делегируете поддомены на отдельные NS (например, под инфраструктуру или отдельные проекты), держите под рукой инструкцию по делегированию: делегирование поддомена на свои NS без сюрпризов.

Типовые ошибки с TTL, которые стоят времени и денег

1) Снижать TTL в момент переключения

Почти всегда поздно: в кэшах уже сидит старое значение с длинным TTL. Планируйте заранее.

2) Забыть, что CNAME тоже имеет TTL

Если www — это CNAME на app, то кэширование происходит на двух уровнях: и CNAME, и A/AAAA цели. При cutover проверяйте TTL на обоих шагах цепочки.

3) Игнорировать negative caching при добавлении новых имён

Создание поддомена «в последний момент» — частая ловушка. Если до этого был NXDOMAIN, часть резолверов будет держать его согласно minimum в SOA (negative caching TTL).

4) Считать, что propagation — это одна цифра

Она разная для разных записей и разных резолверов. Контролируйте именно TTL и проверяйте фактические ответы через dig.

Практические TTL-профили: что ставить и когда

Универсальных значений нет, но есть рабочие ориентиры:

• Активный проект, частые cutover/switch IP: A/AAAA 300–600, CNAME 300–600, SOA minimum 300–900.
• Стабильный проект: A/AAAA 3600–14400, CNAME 3600, SOA minimum 900–3600.
• Почта: MX обычно 3600–14400; при миграции заранее снижайте до 300–900 на период переключения.

Главное — не цифры сами по себе, а дисциплина: снижение заранее, ожидание старого TTL, переключение, наблюдение, затем возврат к «экономичным» TTL.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Мини-чеклист перед cutover

1. Проверить текущие TTL у A/AAAA/CNAME/MX и SOA minimum.
2. За 24–48 часов снизить TTL у целевых записей (и при необходимости скорректировать negative TTL через SOA).
3. Выдержать старый TTL, чтобы кэши успели «перестроиться».
4. Подготовить новый сервер: нужные vhost, сертификаты, healthchecks и ответы на все имена.
5. В момент cutover сменить записи и проверить авторитативный ответ.
6. Проверить несколько рекурсивных резолверов через dig.
7. После стабилизации вернуть TTL на более высокий.

Итог

DNS TTL — это не «магическая задержка», а понятный механизм управления кэшем. Если учитывать кэши резолверов, особенности negative caching и роль SOA (minimum как negative TTL), то propagation становится прогнозируемой, а switch IP и cutover — рутинной процедурой.

Когда вы привыкаете проверять изменения через dig и разделять «авторитативно» и «из кэша», вы перестаёте гадать «обновилось или нет» и начинаете точно видеть, на каком участке цепочки застряло старое значение.