TTL (Time To Live) в DNS обычно вспоминают при переезде на новый сервер, смене IP, добавлении SPF/DKIM или выпуске сертификата, когда внезапно получаем разные ответы от разных сетей. В обиходе это называют propagation («распространение DNS»), но в реальности основная магия происходит не в «распространении», а в кэшах: у рекурсивных резолверов, у ОС, у приложений и иногда у корпоративных прокси.
Ниже — практичная памятка: что означает TTL, почему вы видите «разный DNS», как работает negative caching (NXDOMAIN, NODATA), при чём тут SOA minimum, как смотреть цепочку запросов через dig +trace и когда flush dns действительно помогает.
Что такое TTL в DNS и где он «живёт»
TTL — это число в секундах, которое говорит кэширующим системам: «Этот ответ можно хранить столько-то времени и не ходить за ним снова». TTL относится к конкретному набору записей одного типа для имени (RRset) и публикуется авторитативными DNS-серверами зоны.
Ключевой момент: TTL не означает, что изменения «появятся через TTL». Он означает, что ранее полученный старый ответ может сохраняться в кэшах до окончания TTL. Если запись поменялась на авторитативном сервере, часть клиентов увидит новое значение сразу (если спросит без кэша), а часть — только после истечения «старого» TTL в их рекурсивном резолвере.
Кто кэширует ответы и почему вы видите «разные DNS»
Чаще всего цепочка такая:
- Рекурсивный резолвер (у провайдера, в офисе, у публичных DNS) — главный кэш. Обычно именно он определяет, что увидят пользователи в конкретной сети.
- Локальный кэш ОС (systemd-resolved, nscd, dnsmasq и т.п.).
- Кэш приложений (например, браузер, Java/Runtimes, некоторые прокси).
Поэтому один и тот же домен может резолвиться по-разному: вы сравниваете ответы из разных кэшей и видите разные «остатки TTL».
Если в ответе TTL «не как в панели», это часто не ошибка: рекурсивный резолвер возвращает remaining TTL — остаток времени до истечения кэша.
Почему «propagation» — это не распространение, а истечение кэша
DNS не «рассылает обновления по интернету». Он работает по запросу: кто спросил — тот получил ответ. Поэтому «propagation» — это сленговое название процесса, когда разные кэши постепенно обновляются по мере истечения TTL.
Практическое правило: если вы хотите предсказуемо переключить запись (IP, CNAME, MX, TXT), заранее уменьшайте TTL, ждите, пока старый высокий TTL «доживёт» в кэшах, и только затем меняйте значение.
План безопасной смены IP с учётом TTL
- За 24–48 часов (или хотя бы за срок текущего TTL) снизьте TTL у нужных записей (A/AAAA/CNAME/MX — по задаче).
- Дождитесь, пока «старый» высокий TTL гарантированно истечёт в кэшах (иначе часть клиентов продолжит жить с прежним TTL).
- Смените запись на новое значение.
- После стабилизации верните TTL на более высокий, чтобы снизить нагрузку на авторитативные DNS и ускорить резолвинг для клиентов.
Если вы параллельно делаете делегирование/поддомены, полезно держать под рукой отдельный гайд: делегирование поддомена на свои NS без поломки резолвинга.
Когда миграция затрагивает веб-сервер (смена IP, переезд приложения, новый стек), удобнее делать переключение на тестовом сервере и только затем переводить DNS. Для таких задач обычно берут VDS, чтобы не мешать продакшену и спокойно отладить конфигурацию.
Negative caching: почему NXDOMAIN может «липнуть»
Negative caching — кэширование отрицательных ответов: «такого имени нет» (NXDOMAIN) или «нет таких данных» (NODATA). Это особенно заметно, когда вы:
- создаёте новую запись, а до этого поддомен не существовал;
- временно удаляли запись и вернули обратно;
- проверяете валидацию домена для сертификата, а резолвер продолжает отвечать NXDOMAIN.
SOA minimum: что это такое и как связано с отрицательным кэшированием
В SOA-записи зоны есть несколько таймеров. Исторически поле minimum использовалось как «минимальный TTL» для записей зоны, но в современных реализациях чаще связано с тем, как долго кэшируются отрицательные ответы (в связке с TTL SOA, которую резолвер видит в отрицательном ответе).
Практический вывод: время, на которое кэшируется NXDOMAIN/NODATA, может отличаться от TTL ваших A/AAAA. Поэтому ситуация «A-запись поставили с TTL 60, а поддомен всё равно не находится» часто объясняется именно negative caching.
Типичная ловушка: вы снизили TTL у будущей A-записи, но забыли, что поддомен до этого не существовал. В итоге часть резолверов ещё некоторое время возвращает NXDOMAIN из отрицательного кэша.
Как посмотреть реальный TTL и откуда пришёл ответ
Для диагностики важно различать:
- ответ авторитативного сервера (источник правды);
- ответ рекурсивного резолвера (то, что реально видит пользователь в конкретной сети).
Быстрые команды dig: TTL, recursion, trace
dig example.com AСмотрите секцию ANSWER SECTION и число TTL перед типом записи. Если это ответ из кэша рекурсивного резолвера, TTL будет уменьшаться при повторных запросах.
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com AСравнение популярных рекурсивных резолверов помогает понять, где ещё «сидит» старое значение и какой остаток TTL у конкретного кэша.
dig +trace example.com Adig +trace показывает маршрут от корневых серверов до NS вашей зоны и дальше — авторитативный ответ. Это один из лучших способов понять, где именно проблема: делегирование, glue-записи, авторитативные NS, DNSSEC.
Проверка отрицательных ответов (negative caching)
dig nonexistent-sub.example.com A
dig example.com SOAЕсли видите NXDOMAIN, а запись «точно добавили», проверьте:
- запись добавлена в правильной зоне и с правильным именем (частая ошибка — лишний суффикс зоны в панели);
- вы смотрите на те авторитативные NS, которые реально обслуживают домен (проверьте через
dig +trace); - не мешает ли отрицательный кэш у используемого резолвера.
Если вы выпускаете или перевыпускаете сертификаты и упираетесь в проверки по DNS (например, TXT для валидации), удобно держать под рукой быстрый вариант: заранее подготовить записи и контролировать их TTL/negative caching. Сертификат потом можно оформить через SSL-сертификаты — это снижает риск «простоя» из‑за затянувшейся проверки.
Flush DNS: когда помогает, а когда нет
Запрос «как сделать flush dns» обычно возникает, когда изменения «не применились». Важно понимать: локальный flush очищает только локальный кэш вашей машины (и иногда кэш локального stub-resolver). Он не очищает кэш провайдера, корпоративного резолвера или публичного DNS, которым пользуются другие люди.
Команды для Linux, macOS, Windows
Linux с systemd-resolved:
resolvectl flush-caches
resolvectl statisticsЕсли у вас не systemd-resolved, а, например, nscd или dnsmasq, команды будут другими; иногда проще перезапустить сервис.
macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderWindows:
ipconfig /flushdnsЕсли после локального flush «всё стало правильно», это означает лишь то, что проблема была в локальном кэше. Для пользователей в других сетях это ничего не гарантирует.
Как выбирать TTL: практичные значения для разных записей
TTL — компромисс между скоростью изменений и стабильностью/скоростью резолвинга. Меньше TTL — проще и быстрее переключаться, но выше нагрузка на авторитативные DNS и больше запросов у рекурсивных резолверов.
Рабочие ориентиры
- Для большинства сайтов: 3600–14400 секунд (1–4 часа) для A/AAAA/CNAME.
- Перед миграцией: 60–300 секунд на период работ (важно снижать заранее и выждать старый TTL).
- MX: часто держат выше (3600–14400), но перед миграцией почты тоже имеет смысл снижать TTL, помня, что доставка почты зависит ещё и от ретраев MTA.
- TXT (SPF/DMARC/DKIM): обычно 3600–14400; при плановых изменениях и ротации ключей временно снижайте.
Тонкость: высокий TTL не гарантирует отсутствия запросов
Даже при высоком TTL запросы всё равно будут: кэши у разных резолверов независимы, часть резолверов может очищать кэш агрессивнее, а отдельные клиенты могут использовать несколько DNS-серверов. TTL задаёт ожидаемое поведение, но не является абсолютной гарантией.
Типовые проблемы с TTL и кэшем: короткий чеклист
1) «Сменил A-запись, а часть пользователей видит старый IP»
- По возможности узнайте, каким DNS-резолвером пользуется клиент (часто это кэш провайдера).
- Сравните с авторитативным ответом через
dig +trace. - Проверьте, снижали ли вы TTL заранее и выждали ли срок старого TTL до переключения.
2) «Создал поддомен, но он не резолвится (NXDOMAIN)»
- Проверьте negative caching (NXDOMAIN мог закэшироваться).
- Убедитесь, что запись создана в нужной зоне и без ошибок в имени.
- Проверьте делегирование и NS через
dig +trace.
3) «TTL в ответе не тот, что я выставил»
- Вы смотрите на «остаток TTL» у рекурсивного резолвера; сравните с авторитативным ответом.
- Если вы используете внешнюю DNS-панель, проверьте, не задан ли TTL по умолчанию/шаблону зоны.
Если вы диагностируете проблемы «на стыке» DNS и кэшей в приложении (например, когда смена адресов не подхватывается в веб-слое), может пригодиться разбор: Cache-Control и ETag: почему обновления могут не доходить из-за кэширования.
Мини-ранбук: набор команд для быстрой диагностики
Когда нужно быстро понять, где «застряло», начните с этого:
dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com SOA
dig +trace example.com A
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com AЛогика простая: сравниваем то, что отдают рекурсивные резолверы, с тем, что реально опубликовано на авторитативных NS, и смотрим на TTL и его остаток.
Итоги: что помнить про DNS TTL
- TTL — срок хранения ответа в кэше, а не «время распространения».
- Эффект «propagation» создают кэши: рекурсивные резолверы провайдеров/публичных DNS и локальные кэши.
- Negative caching может удерживать NXDOMAIN даже после создания записи; роль играет SOA (в том числе связка с
minimum) и TTL SOA в отрицательных ответах. flush dnsпомогает локально, но не «очищает интернет».- Для уверенной диагностики используйте
dig +traceи сравнение ответов нескольких резолверов.
Если вы часто переключаете инфраструктуру, вынесите TTL в отдельный чеклист: заранее снижать TTL, фиксировать время изменения, проверять авторитативные ответы и помнить про negative caching. Так DNS становится предсказуемым инструментом, а не лотереей.
Доменные изменения почти всегда идут рядом с задачами делегирования и продления. Чтобы меньше ловить сюрпризов в самый неподходящий момент, держите домен под контролем и вовремя обновляйте записи через регистрацию доменов.
