TTL в DNS: оптимальные значения для каждого типа записи

Что такое DNS TTL?

TTL (Time to Live) — значение в DNS-записи, указывающее резолверам, как долго кешировать ответ перед повторным запросом к авторитативному серверу имен. Измеряется в секундах и напрямую влияет на скорость распространения изменений DNS, нагрузку на серверы имен и устойчивость инфраструктуры к сбоям DNS.

Как работает DNS-кеширование

Когда пользователь посещает ваш сайт, его устройство отправляет запрос рекурсивному резолверу (обычно предоставляемому провайдером или публичным сервисом вроде 1.1.1.1 или 8.8.8.8). Резолвер сначала проверяет свой кеш. Если валидный кешированный ответ существует и TTL не истек, он возвращается без обращения к вашим серверам имен.

Цепочка кеширования

1. Кеш браузера: современные браузеры кешируют DNS-ответы на короткий период (обычно 60 секунд в Chrome), игнорируя фактическое значение TTL.
2. Кеш операционной системы: ОС поддерживает собственный DNS-кеш (systemd-resolved в Linux, mDNSResponder в macOS), учитывающий TTL от резолвера.
3. Кеш рекурсивного резолвера: резолверы провайдеров или публичные кешируют ответы на полную длительность TTL. Это наиболее значимый уровень кеширования.
4. Кеш CDN: при использовании CDN пограничные узлы могут кешировать DNS-ответы независимо по собственным политикам.

Рекомендуемые значения TTL по типам записей

Тип записи	Обычный TTL	TTL перед миграцией	Обоснование
A / AAAA	3600 (1 час)	300 (5 мин)	Баланс между эффективностью кеша и скоростью обновления
CNAME	3600 (1 час)	300 (5 мин)	Аналогично A-записям; разрешение CNAME зависит и от TTL цели
MX	3600-14400	600 (10 мин)	Маршрутизация почты меняется редко; высокий TTL снижает нагрузку
TXT	3600 (1 час)	300 (5 мин)	Записи SPF, DKIM и верификации домена выигрывают от умеренного кеширования
NS	86400 (24 часа)	3600 (1 час)	Смена серверов имен — редкое событие; высокий TTL уместен
SOA	86400 (24 часа)	3600 (1 час)	Интервалы обновления SOA управляют передачей зон
SRV	300-3600	60-300	Записи обнаружения сервисов могут требовать быстрого обновления для отказоустойчивости

Trade-off высокого и низкого TTL

Высокий TTL (24ч+)

Плюсы:

• Меньше запросов к авторитативным серверам и ниже нагрузка и счета.
• Быстрые ответы клиентам из кэша.
• Устойчивость к временным проблемам с DNS-провайдером.

Минусы:

• Долгая миграция: 24 часа ожидания до полной смены.
• Медленный failover.
• Устаревшие записи у клиентов после инцидентов.

Низкий TTL (60-300 сек)

Плюсы:

• Быстрые миграции.
• Работает failover через DNS (GSLB).
• Гибкость при инцидентах.

Минусы:

• Высокая нагрузка на авторитативные серверы.
• Зависимость от их доступности.
• Некоторые резолверы игнорируют слишком низкий TTL (ставят минимум 30-300).

TTL и время распространения

Распространенное заблуждение — что распространение DNS занимает 24-48 часов. В реальности время распространения ограничено предыдущим значением TTL, а не фиксированной длительностью.

Как на самом деле работает распространение

Хронология изменения DNS с TTL=3600:

T+0:    Вы обновляете DNS-запись
T+0:    Новые посетители получают новый IP немедленно
T+1с:   Посетители с только что закешированным ответом получают старый IP
T+3600: ВСЕ кеши резолверов истекли
T+3600: Каждый посетитель получает новую запись

Максимальная задержка распространения равна TTL, установленному до изменения, а не после. Именно поэтому снижение TTL перед миграцией критически важно.

Negative TTL (SOA minimum)

SOA-запись содержит поле minimum — это TTL для negative responses (NXDOMAIN, NODATA) по RFC 2308. Рекомендуется: 300-3600.

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
    2026041401   ; Serial
    10800        ; Refresh
    3600         ; Retry
    604800       ; Expire
    3600         ; Minimum (negative TTL)
)

Стратегии миграции

При планировании миграции серверов переключение DNS — часто самый деликатный этап. Грамотная стратегия DNS-миграции минимизирует простой и влияние на пользователей.

Пошаговый план миграции

1. За 48 часов до миграции: снизьте TTL на всех затрагиваемых записях до 300 секунд (5 минут). Дождитесь полного истечения старого TTL.
2. Предмиграционная проверка: используйте несколько инструментов DNS-проверки для подтверждения, что низкий TTL обслуживается глобально.
3. Во время миграции: обновите DNS-записи для указания на новый сервер. При TTL=300с полное распространение займет 5 минут.
4. Мониторинг после миграции: мониторьте оба сервера. Оставьте старый сервер работающим минимум 24 часа для обслуживания устаревших кешированных запросов.
5. После стабилизации: увеличьте TTL обратно до нормальных значений (3600с или выше) после подтверждения стабильности нового сервера.

Команды для проверки

# Проверка текущего TTL от авторитативного сервера
dig +norecurse @ns1.example.com example.com A

# Проверка кешированного TTL от публичных резолверов
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

# Проверка оставшегося TTL (уменьшается со временем)
dig example.com A +noall +answer

# Трассировка полного пути разрешения
dig +trace example.com A

Типичные ошибки с TTL

• Постоянно низкий TTL: TTL менее 300 секунд увеличивает нагрузку запросов на серверы имен в 10-100 раз и добавляет задержку к каждому DNS-разрешению. Используйте низкий TTL только временно.
• Забыли снизить TTL перед миграцией: если ваш TTL — 86400 секунд, после изменения записи некоторые пользователи будут видеть старый IP до 24 часов.
• Игнорирование негативного кеширования: резолверы кешируют ответы NXDOMAIN на основе минимального TTL в SOA. Новые записи могут быть не видны сразу.
• Минимальный TTL резолверов: некоторые резолверы принудительно устанавливают минимальный TTL (часто 30-300 секунд) независимо от ваших DNS-ответов.
• Ожидание мгновенного распространения: даже при TTL=60 распространение не мгновенно из-за кешей браузеров, ОС и минимальных TTL резолверов.

TTL для высокой доступности

Для сервисов с высокой доступностью DNS-фейловер зависит от низких TTL. При TTL=3600 секунд и сбое основного сервера пользователи продолжают обращаться к недоступному серверу до часа. Сервисы DNS с проверкой состояния, такие как Route 53 или Cloudflare, используют TTL 60-300 секунд для быстрого переключения.

Как проверить TTL

dig A example.com
# ответ:
# example.com.  600  IN  A  93.184.216.34
dig SOA example.com

Значение в секундах слева от IN — это TTL. Оно уменьшается с каждой секундой, пока ответ в кэше резолвера.

FAQ

Как быстро вступит в силу изменение TTL?

Не сразу. Пока не истечёт старый кэш, новый TTL не применится.

Можно ли выставить TTL = 10 секунд?

Можно, но большинство резолверов округлят до 30-60. Практической пользы мало.

Что такое Default TTL провайдера?

Значение по умолчанию, если вы не указали явно. У Cloudflare — Auto (обычно 300), у Route 53 — 300.

Как TTL влияет на SEO?

Напрямую никак. Но долгий простой из-за неверного TTL во время миграции может повлиять на crawling.

Заключение

Настройка DNS TTL — баланс между эффективностью кеширования и операционной гибкостью. Используйте умеренные TTL (3600с) для стабильных записей, снижайте их временно для миграций и держите низкими для записей, участвующих в отказоустойчивости. Всегда планируйте изменения DNS минимум за 48 часов с учетом окна истечения текущего TTL.