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-кэш

1. Клиент запрашивает A-запись.
2. Резолвер обращается к авторитативным и получает ответ с TTL = 3600.
3. Резолвер отдаёт ответ клиенту и кладёт в кэш на 3600 сек.
4. В течение часа все следующие запросы получают кэшированный ответ без обращения к авторитативным.
5. По истечении 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 заранее, повышайте после.

1. T-48ч: снизить TTL до 300. Ждём, пока старый высокий TTL истечёт на резолверах.
2. T-0: меняем запись на новое значение.
3. T+2ч: проверка propagation через DNS Propagation.
4. 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 или значений записей.