DNS TTL: best practices и оптимальные значения
DNS TTL best practices: оптимальные значения
TTL (Time To Live) — одно из важнейших значений в DNS. Оно определяет, сколько секунд резолверы и клиенты хранят запись в кэше. Слишком большой TTL — тяжёлые миграции. Слишком маленький — лишняя нагрузка на авторитативные DNS. В статье — рекомендуемые значения для каждого типа записи и сценарии, когда их стоит корректировать.
Что такое TTL
TTL указывается в секундах и прикреплён к каждой записи в зоне:
example.com. 3600 IN A 93.184.216.34
Здесь 3600 — TTL. Любой резолвер закэширует ответ на 1 час.
Как работает TTL-кэш
- Клиент запрашивает A-запись.
- Резолвер обращается к авторитативным и получает ответ с TTL = 3600.
- Резолвер отдаёт ответ клиенту и кладёт в кэш на 3600 сек.
- В течение часа все следующие запросы получают кэшированный ответ без обращения к авторитативным.
- По истечении TTL запись удаляется, и цикл повторяется.
Рекомендуемые значения
| Тип записи | Стабильное | Перед миграцией |
|---|---|---|
| A / AAAA | 3600 (1 час) | 300 (5 мин) |
| CNAME | 3600 | 300 |
| MX | 3600-86400 (1 час до 1 дня) | 300 |
| TXT (SPF/DKIM) | 3600 | 600 |
| NS | 86400 (1 день) | 86400 (редко меняется) |
| SOA minimum | 3600 | 3600 |
| PTR | 86400 | 86400 |
Trade-off высокого и низкого TTL
Высокий TTL (24ч+)
Плюсы:
- Меньше запросов к авторитативным серверам и ниже нагрузка и счета.
- Быстрые ответы клиентам из кэша.
- Устойчивость к временным проблемам с DNS-провайдером.
Минусы:
- Долгая миграция: 24 часа ожидания до полной смены.
- Медленный failover.
- Устаревшие записи у клиентов после инцидентов.
Низкий TTL (60-300 сек)
Плюсы:
- Быстрые миграции.
- Работает failover через DNS (GSLB).
- Гибкость при инцидентах.
Минусы:
- Высокая нагрузка на авторитативные серверы.
- Зависимость от их доступности.
- Некоторые резолверы игнорируют слишком низкий TTL (ставят минимум 30-300).
Стратегия миграции
Золотое правило: понижайте TTL заранее, повышайте после.
- T-48ч: снизить TTL до 300. Ждём, пока старый высокий TTL истечёт на резолверах.
- T-0: меняем запись на новое значение.
- T+2ч: проверка propagation через DNS Propagation.
- T+24ч: возвращаем TTL к 3600.
TTL для failover
При DNS failover — переключении записи на резервный IP — TTL определяет время восстановления (RTO). Если TTL = 300, клиенты получат новый IP максимум через 5 минут. Если 3600 — час. Для критичных систем TTL = 60.
Важно: некоторые резолверы (Chrome DNS-cache, ISP-сервисы) устанавливают минимум TTL в 30-60 секунд. Значения меньше 60 реально бесполезны.
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)
)
Как проверить TTL
dig A example.com
# ответ:
# example.com. 600 IN A 93.184.216.34
dig SOA example.com
Значение в секундах слева от IN — это TTL. Оно уменьшается с каждой секундой, пока ответ в кэше резолвера.
Типичные ошибки
TTL = 0
Отключает кэширование. Ваш авторитативный DNS уйдёт под нагрузкой. Ставьте минимум 30-60.
Миграция с TTL = 86400
Никогда не мигрируйте без предварительного снижения TTL. 24 часа клиенты будут видеть разные версии сайта.
Разный TTL на записях одного RRset
Согласно RFC 2181 все записи одного RRset (одинаковое имя и тип) должны иметь одинаковый TTL. Нарушение может привести к непредсказуемому поведению.
Слишком низкий TTL для NS
NS меняется редко, но имеет большое влияние на стабильность. Оставляйте 24+ часа.
FAQ
- Как быстро вступит в силу изменение TTL?
- Не сразу. Пока не истечёт старый кэш, новый TTL не применится.
- Можно ли выставить TTL = 10 секунд?
- Можно, но большинство резолверов округлят до 30-60. Практической пользы мало.
- Что такое Default TTL провайдера?
- Значение по умолчанию, если вы не указали явно. У Cloudflare — Auto (обычно 300), у Route 53 — 300.
- Как TTL влияет на SEO?
- Напрямую никак. Но долгий простой из-за неверного TTL во время миграции может повлиять на crawling.
Заключение
Принцип прост: стабильность — 3600-86400, миграция — 300, NS — 86400. Всегда планируйте миграции с buffer-окном 48 часов и проверяйте propagation через Propagation Checker. Для критичных сервисов подключайте мониторинг DNS — он оповестит о любых внеплановых изменениях TTL или значений записей.
Проверьте ваш сайт прямо сейчас
Проверить →