DNS TTL: как управлять временем жизни записей и не ждать propagation вслепую

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

TTL расшифровывается как Time To Live — время жизни DNS-ответа в кэше. Обычно задаётся в секундах для конкретной записи: A record, AAAA, CNAME, MX record, TXT и других. Если у записи TTL равен 3600, корректный кэширующий резолвер может хранить ответ до одного часа и не спрашивать авторитативные DNS-серверы домена повторно.

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

В этой статье разберём, как TTL влияет на propagation, какие значения выбирать для разных записей, как подготовить смену IP или MX без долгого ожидания и как проверить реальную картину через dig.

Как DNS TTL работает в реальной цепочке запроса

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

Например, для домена example.com опубликована запись:

example.com. 300 IN A 203.0.113.10

Резолвер получил этот ответ и запомнил его на 300 секунд. Через минуту другой пользователь, который использует тот же резолвер, получит ответ из кэша. В выводе диагностических утилит TTL уже будет уменьшенным: не 300, а примерно 240 секунд. Это нормально: резолвер показывает, сколько времени осталось жить кэшированному ответу.

Если вы через минуту поменяете A record на новый IP, авторитативные серверы будут отдавать новый ответ сразу после применения зоны. Но резолверы, которые уже закэшировали старый IP, могут продолжать отдавать его до истечения старого TTL. Именно это обычно называют propagation, хотя точнее говорить «схождение кэшей DNS».

Важно различать несколько уровней:

• Авторитативный DNS — источник правды для зоны. Если запись изменилась и зона применена, он отдаёт новое значение.
• Рекурсивный резолвер — кэширующий посредник. Он может держать старый ответ до окончания TTL.
• Локальный кэш ОС или приложения — дополнительный слой, который иногда мешает тестам: браузер, systemd-resolved, nscd, корпоративный агент безопасности.
• Негативный кэш — кэширование ответа «записи нет», о нём часто забывают при создании новых поддоменов.

TTL и propagation: почему нельзя «сбросить DNS у всех»

Распространённый миф: если изменить запись в панели DNS, можно нажать какую-то кнопку и принудительно обновить её во всём интернете. На практике владелец зоны управляет только авторитативной стороной и новым TTL для будущих ответов. Старые ответы уже разошлись по кэшам, и удалённые резолверы не обязаны спрашивать вашу зону повторно раньше времени.

Допустим, у A record стоял TTL 86400, то есть сутки. В 12:00 резолвер получил старый IP. В 12:10 вы снизили TTL до 300 и поменяли IP. Для этого резолвера старый ответ всё равно может жить до 12:00 следующего дня, потому что на момент кэширования ему разрешили хранить запись сутки. Снижение TTL начинает помогать только тем резолверам, которые запросят запись после снижения.

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

Иногда propagation выглядит ещё страннее: у одного администратора уже новый IP, у второго старый, мониторинг показывает смешанные результаты. Это не обязательно ошибка DNS-провайдера. Скорее всего, разные тесты используют разные резолверы с разным состоянием кэша.

Какие TTL ставить для A, MX, TXT, NS и других записей

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

Для типовых веб-проектов разумные ориентиры такие:

• A record и AAAA для сайта: 300–600 секунд перед миграциями и переключениями, 1800–3600 секунд в спокойном режиме. Если IP меняется редко, можно ставить больше.
• CNAME: 300–3600 секунд. Учитывайте, что итоговое время зависит не только от CNAME, но и от TTL целевой записи.
• MX record: 1800–3600 секунд обычно достаточно. Перед переносом почты лучше временно снизить до 300–600 секунд, но заранее.
• TXT для SPF, DKIM, DMARC: 600–3600 секунд. Для стабильных политик можно больше, для внедрения и отладки — меньше.
• CAA: 3600 секунд и выше для стабильной политики выпуска сертификатов, меньше — если вы меняете CA или автоматизацию выпуска.
• NS на уровне зоны: часто 3600–86400 секунд. Перенос авторитативных DNS требует отдельного плана, потому что участвует ещё и делегирование у регистратора.
• SOA: важен не только для серийного номера зоны, но и для негативного кэширования. Параметр minimum или отдельный TTL SOA может влиять на то, как долго резолверы помнят NXDOMAIN.

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

Для production-инфраструктуры обычно используют подход «низкий TTL на управляемых точках переключения, нормальный TTL на стабильных записях». Например, корневой домен и www держат 300–600 секунд, если ожидаются регулярные релизы с blue-green или failover, а DKIM-ключи и служебные записи держат 3600–86400 секунд.

Негативный TTL: почему новый поддомен «не появляется»

Негативное кэширование — частая причина загадочных ситуаций. Вы проверили new.example.com, пока записи ещё не было, получили NXDOMAIN, затем создали A record, но ваш резолвер продолжает говорить, что имени нет. Он не упрямится: он закэшировал отрицательный ответ.

В DNS-зоне негативное кэширование связано с SOA. В современных зонах поведение определяется TTL записи SOA и полем, которое исторически называли minimum. Реальная реализация зависит от DNS-сервера и формата зоны, но практический вывод простой: если вы планируете массово создавать поддомены, wildcard-записи или записи для ACME DNS-01, следите не только за TTL самой будущей записи, но и за отрицательным TTL зоны.

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

Пример фрагмента зоны:

$TTL 3600
@ IN SOA ns1.example.net. hostmaster.example.net. (
  2026011501
  3600
  900
  1209600
  300
)

www 300 IN A 203.0.113.10
mail 3600 IN A 203.0.113.20
@ 3600 IN MX 10 mail.example.com.

Здесь общий TTL зоны — 3600 секунд, но для www явно задано 300. Последнее число в SOA — 300 — часто используют как ориентир для негативного кэша. Если оно слишком большое, только что созданные имена могут «проявляться» дольше у тех, кто уже успел получить NXDOMAIN.

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

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

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

Как подготовить смену IP без долгого простоя

Самый надёжный способ управлять DNS TTL — готовить изменения заранее. Сценарий смены IP для сайта можно разложить на несколько этапов.

1. Проверить текущий TTL. Узнайте TTL у текущих A record, AAAA и связанных CNAME.
2. Снизить TTL заранее. Если сейчас 86400, поставьте 300 или 600 минимум за сутки до переключения. Если сейчас 3600, достаточно сделать это за час-два с запасом.
3. Подготовить новый сервер. Веб-сервер должен отвечать на нужные имена, сертификаты должны быть готовы, приложение и база — синхронизированы.
4. Переключить запись. Измените A record или AAAA на новый IP.
5. Держать старый сервер живым. Не выключайте его сразу. Часть клиентов и резолверов ещё придёт на старый IP.
6. Проверить логи обоих серверов. Когда трафик на старом почти исчез, можно завершать миграцию.
7. Вернуть рабочий TTL. После стабилизации поставьте 1800–3600 или другое значение, принятое в вашей инфраструктуре.

Если сайт принимает заказы, платежи, формы или пользовательский контент, одного DNS TTL недостаточно. Нужно продумать синхронизацию данных: временный read-only режим, репликацию базы, двустороннюю синхронизацию uploads, очередь событий или короткое окно обслуживания. DNS помогает направить пользователей, но не решает конфликт записей в приложении.

При переезде на новый сервер удобно заранее поднять окружение на VDS, проверить виртуальные хосты, SSL, версии PHP или Node.js, доступ к базе и только после этого переключать DNS. Тогда TTL становится инструментом аккуратного переключения, а не последней надеждой на «быстрое обновление».

Особенности MX record: почта обычно терпимее, но план всё равно нужен

Для почты TTL работает так же, но последствия отличаются. Если часть отправителей видит старый MX record, письма пойдут на старый почтовый сервер. Если он продолжает принимать почту и пересылает её на новый сервер, пользователь может вообще не заметить миграцию. Если старый сервер выключен, отправители обычно будут повторять доставку, но задержки станут видимыми.

Безопасный перенос MX выглядит так:

• за старый TTL снизить TTL у MX record и связанных A/AAAA записей почтовых хостов;
• настроить новый почтовый сервер и проверить приём, SPF, DKIM, DMARC, TLS и лимиты;
• переключить MX на новый хост;
• оставить старый сервер принимать или пересылать почту минимум на время старого TTL, а лучше на несколько дней;
• следить за очередями, логами SMTP и ошибками доставки.

Отдельная ошибка — поменять только MX record, но забыть, что он указывает на имя, у которого тоже есть TTL. Например, example.com MX 10 mail.example.com, а mail.example.com A 203.0.113.20 имеет TTL 86400. В таком случае смена адреса почтового хоста может тянуться дольше, чем ожидали.

Как проверить TTL и propagation через dig

Для диагностики удобнее всего использовать dig. Он показывает TTL, позволяет спрашивать конкретный резолвер и обращаться напрямую к авторитативным серверам. Если утилиты нет, установите пакет с DNS-инструментами.

Установка dig

Debian и Ubuntu:

sudo apt update
sudo apt install dnsutils

RHEL-based дистрибутивы: AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux, а также Fedora:

sudo dnf install bind-utils

FreeBSD:

sudo pkg install bind-tools

Базовые проверки

Посмотреть A record и текущий TTL через системный резолвер:

dig example.com A

Короткий вывод:

dig +short example.com A

Но короткий вывод не покажет TTL. Для TTL лучше так:

dig example.com A +noall +answer

Пример результата:

example.com. 287 IN A 203.0.113.10

Число 287 — не «настройка в панели», а оставшееся время жизни ответа в кэше конкретного резолвера. Повторите команду через несколько секунд, и значение уменьшится.

Спросить конкретный публичный или корпоративный резолвер можно так:

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

Для MX record:

dig example.com MX +noall +answer

Для TXT-записей, например SPF или DMARC:

dig example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Найти авторитативные NS домена:

dig example.com NS +short

Спросить авторитативный сервер напрямую:

dig @ns1.example.net example.com A +noall +answer

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

Почему в панели TTL один, а dig показывает другой

Это нормальная ситуация в нескольких случаях. Во-первых, dig через рекурсивный резолвер показывает оставшийся TTL, а не исходное значение. Если в панели стоит 300, вы можете увидеть 298, 124 или 3.

Во-вторых, вы можете смотреть не туда. У домена бывают разные авторитативные NS: старые после переноса, новые после смены делегирования, вторичные DNS с задержкой обновления зоны. Проверяйте, какие NS реально делегированы у родительской зоны, и какие NS отвечают за саму зону.

В-третьих, запись может наследовать общий $TTL зоны или иметь индивидуальный TTL. В панели это иногда скрыто интерфейсом: вы видите «TTL по умолчанию», но конкретная запись могла быть создана с отдельным значением.

В-четвёртых, некоторые резолверы применяют минимальный или максимальный TTL по своей политике. Обычно крупные резолверы ведут себя предсказуемо, но в корпоративных сетях или у провайдеров могут быть локальные правила кэширования. Поэтому для критичных переключений не стоит ориентироваться на один тест из одной сети.

TTL для failover и балансировки: не магическая кнопка

Иногда DNS TTL используют для аварийного переключения: есть две записи A, мониторинг меняет IP при падении сервера, TTL 60 секунд — кажется, что отказоустойчивость готова. На практике DNS failover полезен, но у него есть ограничения.

Во-первых, клиенты и резолверы не обязаны моментально забывать старый IP. Во-вторых, приложения могут держать соединения, пул DNS-ответов или собственный кэш. В-третьих, если IP уже отдан клиенту, низкий TTL не разорвёт существующее TCP-соединение и не заставит браузер перейти на другой адрес.

Для простого сайта TTL 60–300 секунд может быть приемлемой частью плана аварийного переключения. Для API, интернет-магазина, почты или stateful-приложений лучше комбинировать DNS с балансировщиком, репликацией, health checks, понятной схемой возврата и наблюдаемостью. TTL задаёт верхнюю границу жизни ответа в кэше, но не гарантирует SLA сам по себе.

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

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Практические значения TTL для разных сценариев

Ниже — рабочие ориентиры, которые можно брать как стартовую точку и адаптировать под проект.

Обычный сайт без частых миграций

• A/AAAA: 1800 или 3600 секунд.
• www CNAME: 1800 или 3600 секунд.
• MX: 3600 секунд.
• TXT SPF/DMARC: 3600 секунд или больше.

Перед переносом сайта на новый сервер

• за старый TTL снизить A/AAAA до 300 секунд;
• если используется CNAME, проверить TTL и у CNAME, и у конечной записи;
• после переключения держать старый сервер доступным хотя бы несколько часов, а при старом TTL 86400 — сутки;
• после стабилизации вернуть TTL на 1800–3600 секунд.

Перед переносом почты

• снизить TTL у MX record до 300–600 секунд заранее;
• снизить TTL у имён почтовых серверов, на которые ссылается MX;
• не выключать старый почтовый сервер сразу после изменения;
• проверить SPF, DKIM, DMARC и обратные DNS-записи там, где они важны для доставки.

Для ACME DNS-01 и временных TXT

• ставить TTL 60–300 секунд, если DNS-провайдер и политика зоны позволяют;
• учитывать негативный кэш: не проверять имя до создания TXT, если SOA negative TTL большой;
• после выпуска сертификата удалять временные записи или автоматизировать их жизненный цикл.

Если вы автоматизируете выпуск сертификатов через DNS-01, пригодится отдельный разбор про wildcard SSL и автоматизацию DNS-01: там TTL влияет не только на пользователей, но и на скорость прохождения проверки у центра сертификации.

Частые ошибки с DNS TTL

Снизили TTL одновременно с изменением IP. Это помогает только новым запросам. Те, кто уже закэшировал старый ответ с большим TTL, будут ждать.

Проверяют только свой ноутбук. Локальная сеть, VPN, корпоративный DNS или кэш ОС могут показывать картину, не совпадающую с внешним миром. Проверяйте несколько резолверов и авторитативный сервер.

Забывают про IPv6. Если у домена есть AAAA, а вы меняете только A record, часть клиентов продолжит ходить по IPv6. Это особенно заметно на современных сетях с приоритетом IPv6.

Меняют MX, но не проверяют A почтового хоста. MX указывает на имя, а не на IP. TTL и актуальность этого имени так же важны.

Слишком низкий TTL используют как замену архитектуре. TTL 30 секунд не превращает один сервер в отказоустойчивый кластер. Он только уменьшает время кэширования DNS-ответа там, где резолверы соблюдают это значение.

Не обновляют serial зоны при ручном управлении. В классических DNS-серверах вторичные NS ориентируются на serial в SOA. Если запись изменили, а serial не увеличили, вторичные серверы могут не забрать новую зону.

Мини-чеклист перед изменением важной DNS-записи

• Вы знаете текущий TTL записи и снизили его заранее за старое значение TTL.
• Проверены все связанные записи: A, AAAA, CNAME, MX, TXT, где они участвуют в сценарии.
• Новый сервер или сервис уже отвечает корректно на нужное имя.
• Старый сервер не будет выключен сразу после переключения.
• Есть способ проверить авторитативные NS напрямую.
• Мониторинг смотрит не только на DNS, но и на HTTP, SMTP или другой целевой протокол.
• План отката учитывает, что обратное изменение тоже будет кэшироваться.

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