Что такое TTL в DNS: значения, кэш и когда его снижать
Что означает TTL в DNS, как резолверы ведут обратный отсчёт, какие значения разумны для разных записей, отрицательный кэш и план смены записи без сюрпризов.
Опубликовано: · 6 мин чтения
TTL, «time to live», — это число при каждой DNS-записи, которое говорит, сколько секунд резолвер вправе держать ответ в кэше, прежде чем спросить снова. Это единственный настоящий рычаг, которым вы управляете скоростью, с какой изменение в DNS доходит до пользователей, и именно из-за него «обновление DNS» занимает столько времени, сколько занимает.
Как работает TTL
TTL есть у каждой записи в зоне:
www.example.com. 3600 IN A 192.0.2.10
Когда рекурсивный резолвер (вашего провайдера, вашего офиса или публичный, например 1.1.1.1 или 8.8.8.8) получает эту запись от авторитетного сервера, он сохраняет её и начинает обратный отсчёт с 3600. Каждый, кто обратится к этому резолверу в ближайший час, получит копию из кэша с оставшимся TTL. Когда счётчик доходит до нуля, запись выбрасывается, и следующий запрос вызывает новое обращение к авторитетному серверу.
За этим можно понаблюдать:
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com. 3412 IN A 192.0.2.10
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com. 3397 IN A 192.0.2.10
Второе число уменьшилось. Если же спросить авторитетный сервер напрямую, вы всегда увидите полное, заданное в зоне значение:
$ dig +noall +answer www.example.com @ns1.dns.example
www.example.com. 3600 IN A 192.0.2.10
Эта разница удобна для диагностики: TTL меньше заданного означает, что перед вами кэш.
Из самого механизма следуют три вывода:
- Ничего никуда не рассылается. Изменение записи не уведомляет ни один резолвер. Каждый кэш хранит старый ответ, пока не закончится его собственный отсчёт.
- Кэши истекают в разное время, потому что каждый получил запись в свой момент. В течение одного TTL после изменения разные пользователи видят разные ответы. Это и есть всё «распространение DNS».
- Значение имеет старый TTL. Резолвер, закэшировавший запись вчера с TTL 86400, продержит её до конца этих 24 часов, что бы вы ни выставили сегодня.
Кэши, которые вам неподвластны
Рекурсивный резолвер — не единственный кэш. Свои кэши есть у операционных систем, браузеров и приложений, и не все они точно соблюдают TTL: браузеры держат адреса короткое фиксированное время, а долго работающие приложения (классический пример — старые среды выполнения Java) могут хранить результат запроса, пока жив процесс. Некоторые резолверы вдобавок применяют нижнюю или верхнюю границу: TTL в 5 секунд могут посчитать за 30 или 60, а очень длинные TTL обрезать примерно до суток. Кроме того, резолвер может какое-то время отдавать просроченные данные, если авторитетные серверы недоступны.
Так что TTL — это весомая подсказка, но не гарантия, и обещать, что изменение станет видно «везде» ровно через N секунд, нечестно.
Отрицательное кэширование: TTL для ответа «не существует»
Резолвер кэширует и ответ «такого имени не существует» (NXDOMAIN), и ответ «у этого имени нет записи такого типа». Срок берётся из записи SOA зоны: это меньшее из двух чисел, собственного TTL записи SOA и её последнего поля (исторически оно называется «minimum»).
$ dig +noall +authority nosuch.example.com
example.com. 300 IN SOA ns1.dns.example. hostmaster.example.com. 2026092001 7200 3600 1209600 300
Отсюда и обычное объяснение ситуации «запись я создал, авторитетный сервер её отдаёт, а мой резолвер всё ещё говорит, что её нет»: кто-то (часто вы сами, проверяя слишком рано) запросил имя до его создания, и отрицательный ответ попал в кэш. При отрицательном TTL 300 это пять минут досады, при 86400 — потерянный день. Держите его умеренным: значения от 300 до 3600 разумны.
Как выбирать TTL
Единственно верного числа нет. Это компромисс между гибкостью и устойчивостью:
| Низкий TTL (60–300) | Высокий TTL (3600–86400) | |
|---|---|---|
| Изменения вступают в силу | быстро | медленно |
| Ошибки | исправляются быстро | держатся часами |
| Нагрузка на авторитетные серверы | выше | ниже |
| Задержка разрешения имён у пользователей | больше промахов кэша | в основном из кэша |
| Если у DNS-провайдера авария | имена перестают разрешаться за минуты | закэшированные ответы выручают пользователей |
О последней строке часто забывают. Длинный TTL — бесплатная страховка от короткого сбоя DNS.
Разумные отправные точки:
| Запись | Типичный TTL | Обоснование |
|---|---|---|
A/AAAA стабильного сайта |
3600 | изменения редки и планируются заранее |
A/AAAA для отказоустойчивости или за балансировщиком |
60–300 | переключаться нужно быстро; часто значение задаёт провайдер |
CNAME на SaaS или CDN |
3600 | итоговый адрес определяется TTL целевой записи |
MX |
3600–86400 | почтовые серверы меняются редко, а отправители всё равно повторяют попытки |
TXT (SPF, DKIM, DMARC) |
3600 | снижайте перед плановой правкой |
NS и SOA |
86400 | стабильны; TTL делегирования в родительской зоне от вас не зависит |
CAA |
3600–86400 | УЦ учитывают её TTL при повторной проверке |
Если провайдер предлагает значение «Auto», обычно это 300 секунд, и большинству сайтов оно подходит.
Как спланировать изменение с учётом TTL
Порядок действий при переезде сайта, почтового сервера или чего угодно ещё, что стоит за DNS-именем:
- Узнайте текущий TTL у авторитетного сервера. Назовём его T.
- Снизьте его до 300 (не меньше: очень маленькие значения некоторые резолверы игнорируют) и подождите не меньше T. Только когда T пройдёт, можно быть уверенным, что во всех кэшах лежит версия с 300 секундами.
- Внесите изменение.
- Проверьте ответ авторитетного сервера и нескольких публичных резолверов.
- Не выключайте старый сервер как минимум в течение нового TTL, а на деле несколько часов: есть кэши, которые правил не соблюдают.
- Верните высокий TTL, когда будете уверены, что откатываться не придётся.
Снизить TTL и поменять запись одной правкой — классическая ошибка: у тех резолверов, которые вас интересуют, лежит старая запись со старым TTL, и ваш новый TTL они даже не увидят, пока старый не истечёт.
Учтите, что при смене NS-серверов участвует ещё один TTL: TTL делегирования в родительской зоне. Обычно он равен двум суткам, и изменить его вы не можете. Что такое делегирование и серверы имён, объяснено в глоссарии: NS-сервер.
TTL и цепочки CNAME
Если имя является CNAME, резолвер кэширует каждое звено отдельно, каждое со своим TTL:
www.example.com. 3600 IN CNAME site.cdn.example.
site.cdn.example. 60 IN A 203.0.113.20
CDN может поменять свою A-запись за минуту, но если вы хотите направить www на другой CDN, действует ваше собственное значение 3600. Фактическая задержка для конкретного изменения равна TTL той записи, которую вы меняете, а не наименьшему TTL в цепочке.
Можно ли сбросить кэш?
Свой — да.
# macOS
$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
> ipconfig /flushdns
# Linux с systemd-resolved
$ resolvectl flush-caches
У некоторых публичных резолверов есть веб-форма для удаления имени из их кэша; после ошибки это выручает. До всех остальных резолверов вам не дотянуться. Глобального сброса не существует, а любой сервис, обещающий «ускорить распространение», продаёт кнопку, которая ничего не делает.
Частые ошибки
- Снижать TTL одновременно с изменением или за пять минут до него.
- Навсегда оставить везде 60 секунд «ради гибкости», а потом упасть вместе со своим DNS-провайдером.
- Суточный TTL на записи, которая входит в план аварийного переключения.
- Забыть про отрицательное кэширование и запросить имя до того, как оно создано.
- Считать проверку с собственного ноутбука доказательством того, что видят пользователи.
- Верить, будто процент в «проверке распространения» описывает весь интернет. Он описывает только те точки, которые опросил этот инструмент.
Проверьте в OrbitProbe
Проверка DNS-записей в OrbitProbe показывает TTL рядом с каждой возвращённой записью: таким, каким его в этот момент видят публичные резолверы. Перед миграцией найдите с её помощью TTL, которые нужно снизить; после изменения запустите проверку снова, чтобы убедиться в новом значении и посмотреть на оставшийся TTL. Обзор того, какие записи вообще бывают, есть в статье типы DNS-записей, а если изменение связано с наладкой доставки почты, пригодится чек-лист DNS для писем, попадающих в спам.