TTL в DNS: оптимальные значения для каждого типа записи
Что такое DNS TTL?
TTL (Time to Live) — значение в DNS Lookup, указывающее резолверам, как долго кешировать ответ перед повторным запросом к авторитативному серверу имен. Измеряется в секундах и напрямую влияет на скорость распространения изменений DNS, нагрузку на серверы имен и устойчивость инфраструктуры к сбоям DNS.
Как работает DNS-кеширование
Когда пользователь посещает ваш сайт, его устройство отправляет запрос рекурсивному резолверу (обычно предоставляемому провайдером или публичным сервисом вроде 1.1.1.1 или 8.8.8.8). Резолвер сначала проверяет свой кеш. Если валидный кешированный ответ существует и TTL не истек, он возвращается без обращения к вашим серверам имен.
Цепочка кеширования
- Кеш браузера: современные браузеры кешируют DNS-ответы на короткий период (обычно 60 секунд в Chrome), игнорируя фактическое значение TTL.
- Кеш операционной системы: ОС поддерживает собственный DNS-кеш (systemd-resolved в Linux, mDNSResponder в macOS), учитывающий TTL от резолвера.
- Кеш рекурсивного резолвера: резолверы провайдеров или публичные кешируют ответы на полную длительность TTL. Это наиболее значимый уровень кеширования.
- Кеш 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 | Записи обнаружения сервисов могут требовать быстрого обновления для отказоустойчивости |
TTL и время распространения
Распространенное заблуждение — что распространение DNS занимает 24-48 часов. В реальности время распространения ограничено предыдущим значением TTL, а не фиксированной длительностью.
Как на самом деле работает распространение
Хронология изменения DNS с TTL=3600:
T+0: Вы обновляете DNS-запись
T+0: Новые посетители получают новый IP немедленно
T+1с: Посетители с только что закешированным ответом получают старый IP
T+3600: ВСЕ кеши резолверов истекли
T+3600: Каждый посетитель получает новую записьМаксимальная задержка распространения равна TTL, установленному до изменения, а не после. Именно поэтому снижение TTL перед миграцией критически важно.
Стратегии миграции
При планировании миграции серверов переключение DNS — часто самый деликатный этап. Грамотная стратегия DNS-миграции минимизирует простой и влияние на пользователей.
Пошаговый план миграции
- За 48 часов до миграции: снизьте TTL на всех затрагиваемых записях до 300 секунд (5 минут). Дождитесь полного истечения старого TTL.
- Предмиграционная проверка: используйте несколько инструментов DNS-проверки для подтверждения, что низкий TTL обслуживается глобально.
- Во время миграции: обновите DNS-записи для указания на новый сервер. При TTL=300с полное распространение займет 5 минут.
- мониторинг сайтов после миграции: мониторьте оба сервера. Оставьте старый сервер работающим минимум 24 часа для обслуживания устаревших кешированных запросов.
- После стабилизации: увеличьте 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 секунд для быстрого переключения.
Заключение
Настройка DNS TTL — баланс между эффективностью кеширования и операционной гибкостью. Используйте умеренные TTL (3600с) для стабильных записей, снижайте их временно для миграций и держите низкими для записей, участвующих в отказоустойчивости. Всегда планируйте изменения DNS минимум за 48 часов с учетом окна истечения текущего TTL.
Проверьте ваш сайт прямо сейчас
Проверить →