TTL в DNS — не просто число в секундах, а главный регулятор того, как быстро мир узнает об изменениях вашего домена. Слишком короткий TTL создаёт лишнюю нагрузку на резолверы и повышает риски из‑за частых запросов. Слишком длинный — растягивает «пропагацию», мешает миграциям и аварийным переключениям. В этой статье — практическая стратегия TTL для записей A/AAAA (веб), MX (почта) и TXT (SPF/DKIM/DMARC), чтобы обновления доходили вовремя, а кеш не мешал бизнесу.
Что такое TTL и где реально кешируется
TTL (time to live) — это время, в течение которого кэширующий DNS‑резолвер считает ответ актуальным и не обращается повторно к авторитетным серверам. Но на путь ответа влияет не один, а несколько слоёв кеша.
Слои кеша, которые могут затянуть обновление
- Рекурсивные резолверы провайдеров и организаций. Они уважают TTL, но часто имеют минимальные/максимальные пороги. Например, TTL ниже 30–60 секунд могут «поднять» до минимума, а слишком большой — «урезать».
- Локальные «стабы» на клиентах (systemd-resolved, nscd, DNS Client в Windows, mDNSResponder в macOS). Они тоже кешируют, иногда отдельно от рекурсивного резолвера.
- Приложения и библиотеки. Браузеры и рантаймы (Java, Go, Node.js) могут иметь свои таймеры DNS, а некоторые HTTP‑клиенты держат открытые соединения, которые связывают обновление IP с тайм-аутами TCP.
- CDN, балансировщики, прокси. Часто конфигурируются на собственные интервалы обновления upstream DNS.
Итоговый «эффект пропагации» — это максимум по всем слоям: пока самый «долго живущий» кеш не забудет старые данные, часть клиентов продолжит идти по старому пути.
Как работает изменение TTL на практике
TTL «прикреплён» к конкретному набору записей (RRset). Пока в кеше лежит старый RRset, новый TTL никто не увидит. Это означает, что изменение TTL «задним числом» не ускорит распространение уже кэшированных значений. Работает только стратегия «снизить TTL заранее, подождать, затем менять целевые значения».
Ещё нюанс: негативное кеширование (NXDOMAIN и NODATA) живёт по своему TTL — берётся из поля SOA (negative TTL по RFC 2308). Если вы добавляете новую запись там, где раньше её не было, клиенты, поймавшие NODATA/NXDOMAIN, могут «не видеть» её до конца негативного TTL.
Рекомендации TTL по типам записей
A/AAAA: веб и API
Для веб‑трафика главные факторы — устойчивость, скорость переключений при авариях и влияние на кэширующие уровни приложений. Универсальных цифр нет, но есть практические ориентиры:
- Статичный сайт на одном IP, без частых изменений: TTL 3600–14400 (1–4 часа). Это снижает лишний трафик к DNS и не мешает редким изменениям.
- Два IP с ручным аварийным переключением: TTL 900–1800 (15–30 минут). Достаточно быстрое схождение при инцидентах, без перегрузки резолверов.
- Частые релизы и/или смена IP, ручной failover: TTL 300–600 (5–10 минут). Баланс между «живостью» и стабильностью.
- Автоматическое переключение через внешний health‑check и динамический DNS: TTL 30–120 секунд. Помните про минимальные пороги у резолверов и дополнительную нагрузку на авторитетные NS.
Разделяйте зоны ответственности. Для апекса домена (например, @) выставляйте более консервативный TTL (например, 1800–3600), а для критичных субдоменов (www, api, static) — TTL короче. Так вы уменьшите удар на основную точку входа и оставите манёвр для быстрого обновления отдельных сервисов.
Отдельно учитывайте, что многие балансировщики/обратные прокси кешируют DNS upstream отдельно от системных настроек. Если Nginx/Envoy/HAProxy или SDK вашего приложения резолвит upstream с интервалом 5–10 минут, то снижение TTL до 60 секунд на авторитете ничего не даст, пока не скорректируете политику резолва на уровне приложения.
Если планируете переезд сайта на VDS или на виртуальный хостинг, снизьте TTL заранее, чтобы переключение A/AAAA прошло без даунтайма.
MX: надёжность почты важнее скорости переключения
Почтовая доставка должна работать предсказуемо. Подходящее правило — у MX консервативный TTL, у A/AAAA почтовых хостов умеренный.
- MX‑записи: TTL 3600–86400 (1–24 часа). MX меняются редко, а ретраи MTA при недоступности хоста обычно продолжаются часами. Длинный TTL разгружает DNS.
- A/AAAA для MX‑хостов: TTL 600–3600 (10–60 минут). Если перемещаете сам почтовый хост на новый IP, изменение сойдётся быстрее.
- Во время миграции: за 24–48 часов снизьте TTL у MX и у A/AAAA соответствующих хостов до 300–600. После стабилизации верните назад.
Помните, что при нескольких MX с разными приоритетами ретраи отправителей идут по списку. Если вы убираете старый MX, временно сохраняйте его запись, указывая на доступный хост с корректным приветствием SMTP, или оставьте сервис включённым до окончания окна миграции — иначе часть писем будет ретраиться дольше из‑за кеша.
TXT: SPF, DKIM, DMARC и операционные нюансы
TXT‑записи часто являются политиками. Их не хочется менять каждую неделю, но иногда нужно быстрое обновление:
- SPF: TTL 1800–7200 (30–120 минут). При плановой ротации отправителей снизьте до 300–600 за сутки до переключения. Если SPF «плоский» (без include), его стабильно кешируют; если есть цепочки include, итоговая «эффективная пропагация» определяется наихудшим звеном.
- DKIM: TTL 3600–86400 (1–24 часа). Публичный ключ меняется редко. На время ротации селектора — 600–1800, затем возврат к длинному.
- DMARC: TTL 3600–14400 (1–4 часа). При изменении политики (p=none/quarantine/reject) снижайте до 600–1800, затем повышайте.
Критично учитывать негативное кеширование: если проверяющий ранее получил NODATA по DKIM‑селектору, он может «не увидеть» новый ключ до истечения negative TTL. Это особенно заметно при включении нового селектора в «горячем» режиме. Подробнее про безопасную ротацию ключей — в материале «Ротация DKIM‑селекторов без простоев» (гайд по ротации DKIM‑селекторов).
Если выпускаете сертификаты по DNS‑01, учитывайте TTL TXT‑челленджа: короткий TTL ускоряет проверку. Для выпуска и автоматического продления подойдёт линейка наших SSL-сертификаты.
Аналитику доставки писем удобно строить на базе DMARC. Подробности — в статье «DMARC‑отчёты: разбор и повышение доставляемости» (как читать DMARC‑отчёты).
План-график снижения TTL перед изменениями
Рабочий алгоритм перед миграцией (смена IP сайта, переезд MX, обновление SPF/DMARC):
- T−72…48 часов. Снижайте TTL на целевых RRset до 300–600. Для MX — и на A/AAAA соответствующих узлов.
- Ждите полный интервал старого TTL. Пока старые ответы не «выгорят» из кешей, новый короткий TTL не поможет.
- T−2…0 часов. Вносите изменения в значения записей. Проверяйте точечно с разных резолверов.
- T+2…6 часов. Мониторьте. После стабилизации верните TTL на прежние консервативные уровни.
Всегда помните: «снижение TTL» — это отдельная операция, которая начинает работать только после истечения предыдущего, более длинного TTL в кешах.
Если домен делегирован через нашу регистрация доменов, проверьте допустимые минимумы/максимумы TTL в панели управления заранее.
Негативное кеширование: NXDOMAIN и NODATA
Отсутствие записи тоже кешируется. Параметр берётся из SOA (negative TTL). Если вы планируете добавить новый субдомен или селектор DKIM, заранее убедитесь, что negative TTL разумный (например, 300–900), иначе вы получите «призрачную пропагацию» — кто-то увидит запись сразу, а кто-то — через десятки минут или часы, в зависимости от предыдущего запроса, давшего NXDOMAIN.
Если вы управляете зоной вручную (BIND/NSD/Knot), настройте $TTL по умолчанию и разумный negative TTL в SOA. Для провайдерских панелей проверьте, можно ли отдельно менять TTL на RRset, и какой стоит системный минимум/максимум.
Частые ошибки и как их избежать
- Снижать TTL одновременно c изменением значений. Это не ускоряет схождение — снижать нужно заранее.
- Забывать про A/AAAA узлов из MX. Поменяли MX, но не тронули TTL адресов хостов — письма всё равно будут «зависать» на старых IP до конца кеша.
- Ставить TTL «0» в надежде на мгновенное обновление. Многие резолверы всё равно поднимут до минимума (30–60 секунд), а некоторые клиенты не уважают TTL 0.
- Путать DNS TTL и HTTP‑кеш. Обновили A/AAAA быстро, а пользователи всё ещё видят старый контент из CDN/браузера. Эти кеши управляются заголовками HTTP и настройками CDN, не DNS.
- Игнорировать негативный кеш. Добавили новую TXT, а часть проверяющих «не видит». Виноват NXDOMAIN‑кеш с SOA negative TTL.
- Оставлять низкий TTL навсегда. Лишняя нагрузка на DNS и большие риски при «шумных» резолверах клиентов.
Практическая проверка TTL и кеша
Проверяйте TTL и актуальные ответы как с «чистого» пути (через авторитетный trace), так и со стороны разных публичных и корпоративных резолверов. Это даёт реальную картину пропагации.
# Ответ авторитетных NS (видно текущий TTL на авторитете)
dig +trace example.com A +noall +answer
dig +trace example.com MX +noall +answer
dig +trace _dmarc.example.com TXT +noall +answer
# Ответ конкретного резолвера (с учетом его кеша)
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com MX +noall +answer
dig @9.9.9.9 _dmarc.example.com TXT +noall +answer
Смотрите на поле TTL в ответах. Если оно «сыпется» к нулю — это кеш; если держится на стабильно высоком значении — вы уже видите ответ с авторитета (или резолвер делает быструю рефреш‑валидацию).
Заметки по зонам и конфигам
Если управляете BIND‑зоной вручную:
$TTL 3600
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
2025010101 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
600 ; negative TTL (NXDOMAIN/NODATA)
)
; A/AAAA для веба
@ 1800 IN A 203.0.113.10
www 600 IN A 203.0.113.10
api 300 IN A 203.0.113.20
@ 1800 IN AAAA 2001:db8::10
; MX и почтовые хосты
@ 86400 IN MX 10 mx1.example.com.
@ 86400 IN MX 20 mx2.example.com.
mx1 1800 IN A 203.0.113.30
mx2 1800 IN A 203.0.113.31
; TXT политики
@ 3600 IN TXT "v=spf1 include:_spf.example.net -all"
_dmarc 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
selector1._domainkey 86400 IN TXT "v=DKIM1; k=rsa; p=MIIB..."
Серийный номер увеличивайте при каждом изменении. Перед миграцией временно уменьшайте $TTL и TTL нужных RRset, потом возвращайте значения. Negative TTL держите в диапазоне 300–900, чтобы ускорить появление новых записей.
Рекомендованные пресеты TTL
- Веб A/AAAA (стабильный): 3600–14400
- Веб A/AAAA (частые изменения): 300–900
- Failover с автоматикой: 30–120 (учитывая минимумы резолверов)
- MX: 3600–86400
- A/AAAA почтовых хостов: 600–3600
- SPF: 1800–7200 (на время смен — 300–600)
- DKIM: 3600–86400 (на время ротации — 600–1800)
- DMARC: 3600–14400 (на время смен — 600–1800)
- Negative TTL (SOA): 300–900
Это не догма — корректируйте под архитектуру, требования к RTO/RPO и ограничения DNS‑провайдера. Держите в голове ограничения минимальных/максимальных TTL и бюджет запросов к авторитетным NS.
Диагностика «лишнего кеша»
Если изменения «не доходят», разложите проблему по слоям:
- Авторитетный ответ: сразу ли виден новый RRset с ожидаемым TTL?
- Публичные резолверы: согласуются ли ответы между несколькими точками?
- Клиентский кеш: не забыли очистить локальные кеши тестовых машин? Для систем с долгоживущими демонами резолва дождитесь интервала их обновления.
- Приложение: пересоздаёт ли оно DNS‑резолв и соединения? Долгие keep‑alive могут тянуть трафик на старый IP даже после схода DNS.
# Примеры очистки локального кеша на тестовой машине
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
Итоги
Стратегия TTL — это баланс между скоростью изменений и устойчивостью. Для A/AAAA разумно держать короткий TTL лишь там, где требуется быстрый поворот (www, api), а в остальном — более длинные значения. Для MX приоритет — стабильность и предсказуемость доставки, поэтому сами MX — с длинными TTL, а адреса их хостов — умеренно короче. Для TXT‑политик (SPF/DKIM/DMARC) подбирайте средние значения и временно снижайте их на период изменений. Всегда учитывайте негативное кеширование и слой приложения: именно они чаще всего создают ощущение «лишнего кеша». Планируйте снижение TTL заранее, проверяйте с разных резолверов и возвращайте значения обратно после стабилизации — и ваши обновления DNS будут происходить без сюрпризов и даунтайма.
