TTL DNS-записи (Time To Live, время жизни) — время в секундах, в течение которого DNS-ответ хранится в кэше рекурсивного резолвера и клиентских устройств. После истечения TTL резолвер обращается к авторитативному серверу за обновлёнными данными. TTL — главный инструмент управления скоростью распространения изменений DNS по миру.
Как работает TTL
Когда браузер запрашивает IP-адрес для example.com, рекурсивный резолвер (например, 8.8.8.8) получает ответ от авторитативного сервера и сохраняет его в кэш на время TTL. Если TTL = 3600, резолвер не будет повторно опрашивать авторитативный сервер в течение 1 часа — все клиенты, обращающиеся к этому резолверу, получат кэшированный ответ. При обновлении A-записи новое значение распространится только через время TTL, плюс время обхода всех кэшей в цепочке.
TTL задаётся отдельно для каждой DNS-записи. Типичные значения: SOA-запись (Minimum TTL для зоны) — 300–3600 секунд; A/AAAA-записи — 300–86400 секунд; MX-записи — 3600–14400 секунд; NS-записи — 86400 секунд (менять редко); TXT/SPF — 3600 секунд.
TTL передаётся в каждом DNS-ответе и декрементируется рекурсивными серверами: если авторитативный сервер вернул TTL=3600, а резолвер держит кэш уже 1800 секунд, клиент получит TTL=1800 в ответе. Это позволяет клиенту знать, насколько свежи данные.
История
TTL введён в DNS стандарте RFC 1034/1035 (1987) Полом Мокапетрисом как механизм управления кэшированием в распределённой базе данных. Значения TTL исторически были велики — 86400 секунд и выше: при медленном интернете и редких изменениях долгое кэширование снижало нагрузку на авторитативные серверы. С ростом динамичности инфраструктуры стандартные TTL снизились до 300–3600 секунд.
Появление CDN и облачных балансировщиков нагрузки в 2000-х привело к массовому использованию TTL 60–300 секунд для A-записей. В 2019 году Cloudflare зафиксировал попытки установить TTL=0 для «отключения кэша» — это ошибка. RFC 2181 §8 определяет, что TTL=0 означает «не кэшировать», но резолверы вправе его игнорировать и кэшировать на короткое время во избежание шторма запросов.
Управление TTL при миграции сервера
- За 24–48 часов до смены IP: снизить TTL с 86400 до 300–600 секунд. Дождаться, пока все кэши с высоким TTL истекут (1–2 суток).
- В момент смены: обновить A-запись с новым IP. Переключение для большинства клиентов произойдёт в течение 5–10 минут.
- После успешной миграции: поднять TTL обратно до 3600–86400 для снижения нагрузки на авторитативный сервер и ускорения ответов через кэш.
Инструменты проверки распространения: dig @8.8.8.8 example.com A, dig @1.1.1.1 example.com A — сравнить ответы разных резолверов; dnschecker.org показывает ответы из 20+ стран одновременно; dig +trace example.com — трассировка всей цепочки от корня до авторитативного сервера.
Отрицательный TTL (NXDOMAIN)
SOA-запись зоны содержит параметр Minimum TTL — время кэширования отрицательных ответов (NXDOMAIN — домен не существует). Если клиент получил NXDOMAIN для несуществующего поддомена, этот ответ кэшируется на время Minimum TTL. Слишком большой отрицательный TTL замедляет появление новых DNS-записей — клиент ещё долго получает NXDOMAIN из кэша. Рекомендация RFC 2308: отрицательный TTL не должен превышать 3 часов (10800 секунд).
На что обращать внимание
Очень низкий TTL (менее 60 секунд) резко увеличивает нагрузку на авторитативный DNS-сервер: каждый пользователь делает запрос каждую минуту. Cloudflare и Route 53 ограничивают минимальный TTL значением 60 секунд. Для Failover IP и CDN рекомендуемый TTL для A-записей — 300 секунд: компромисс между скоростью переключения и нагрузкой. Перед любым изменением инфраструктуры — проверьте текущий TTL командой dig example.com A и при необходимости снизьте заблаговременно.