Что такое TTL в DNS

TTL, Time to Live, в DNS задаёт время в секундах, в течение которого получатель может кешировать ресурсную запись до повторного запроса. Если A-запись опубликована с TTL 3600, рекурсивный резолвер обычно вправе использовать полученный ответ до часа, уменьшая оставшееся значение по мере хранения.

TTL относится к данным DNS, а не к сроку регистрации домена, жизни TLS-сертификата или кешу страницы в браузере. Одинаковое сокращение используется в разных технологиях, но таймеры независимы.

Где увидеть TTL

Откройте проверку DNS, выберите точное имя и тип записи. В полном выводе dig TTL обычно стоит между именем и классом IN:

dig example.com A

Условная строка ответа выглядит так:

example.com.  3600  IN  A  192.0.2.10

Адрес здесь взят из диапазона для документации. Число 3600 означает секунды. Если запрос прошёл через рекурсивный сервер, вы можете увидеть уже оставшийся TTL, а не исходное значение зоны. При повторном запросе число обычно уменьшается, пока кеш не обновится.

Чтобы посмотреть значение у источника, узнайте NS зоны и запросите один из авторитетных серверов напрямую:

dig example.com NS +short
dig @<authoritative-server> example.com A

Вместо заполнителя используйте фактическое имя NS. Сравните все авторитетные серверы: несогласованный набор зон создаёт различия, которые ошибочно принимают за нормальный кеш.

TTL у набора записей и цепочки имён

В DNS кешируется набор записей одного имени и типа, RRset. Если у имени несколько A-адресов, они должны рассматриваться как единый набор с общим TTL. Разные типы, например A и TXT, могут иметь разные сроки.

При CNAME возникает цепочка. У записи CNAME есть собственный TTL, а у адресной записи конечного имени - свой. Клиенту может потребоваться обновить одну часть раньше другой. Поэтому при миграции внешнего сервиса смотрят весь ответ, а не только одно число в панели.

Делегирование тоже кешируется. Изменение NS у регистратора связано с данными родительской зоны и не равно редактированию A внутри дочерней. Параметры и процессы здесь могут отличаться.

Почему снижение не действует задним числом

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

Для планового переключения TTL снижают заранее. Общая последовательность такая:

1. Определить текущий максимальный TTL всех затрагиваемых записей и цепочек.
2. Установить временное меньшее значение за достаточное время до миграции.
3. Дождаться, пока копии со старым большим TTL естественно истекут.
4. Переключить адрес и проверить все авторитетные NS.
5. Поддерживать старую площадку в переходный период, если это допустимо.
6. После стабилизации вернуть рабочий TTL, чтобы не оставлять повышенную частоту запросов без причины.

Конкретные числа зависят от архитектуры и ограничений DNS-провайдера. Некоторые управляемые сервисы задают TTL сами или предлагают только фиксированный набор значений.

Отрицательный TTL

Резолверы кешируют и отрицательные ответы: например, NXDOMAIN для несуществующего имени или отсутствие нужного типа у существующего имени. RFC 2308 связывает срок такого кеширования с данными SOA. Поэтому новый поддомен может не появиться у клиента сразу, если незадолго до создания тот уже запросил его и сохранил отрицательный ответ.

Не следует считать поле MINIMUM в SOA универсальным TTL для всех положительных записей. Его историческое назначение менялось, а для отрицательного кеша действуют определённые правила. Ориентируйтесь на фактический ответ авторитетного сервера и документацию своей платформы.

Практический выбор TTL

Для стабильной записи, которая меняется редко, более длительный TTL снижает число повторных DNS-запросов и зависимость от кратких сбоев авторитетных серверов. Для управляемой точки переключения меньший TTL может сократить обычное время сохранения старого ответа. Это компромисс, а не шкала качества.

Например, команда планирует перенести api.example.com. Нужно учесть CNAME API, адрес конечного балансировщика, сертификат и клиентские пулы соединений. Уменьшение TTL только у api.example.com не поможет, если долгий TTL остался у управляемого конечного имени или клиенты часами держат открытые соединения.

После изменения фиксируйте ответы с временем и источником. Связанный материал о задержках DNS будет доступен в разделе руководств после ручной проверки и поможет отделить TTL от браузерного и CDN-кеша.

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

• Принимать оставшийся TTL рекурсивного ответа за настройку авторитетной зоны.
• Читать значение как минуты, хотя протокол использует секунды.
• Снижать TTL в момент переноса, а не заранее.
• Забывать про отдельные TTL у AAAA, CNAME и конечного имени.
• Оставлять минимально возможное значение навсегда без оценки нагрузки и устойчивости.
• Ожидать, что TTL очистит кеш браузера, HTTP-прокси или CDN.
• Менять запись повторно, пока старые кеши ещё законно живут, и усложнять диагностику.
• Игнорировать отрицательное кеширование при создании нового имени.

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

Частые вопросы

В каких единицах измеряется TTL DNS-записи?

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

Ускорит ли снижение TTL уже начавшееся обновление?

Не для копий, сохранённых раньше с прежним TTL. Они могут оставаться в независимых кешах до окончания исходного срока. Снижение помогает плановой миграции, если выполнить его заранее и дождаться вытеснения старого большого значения.

Чем меньше TTL, тем лучше?

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