TTL DNS-записей: как выбрать значение и не сломать переезд

TTL в DNS — это не «скорость обновления записи у регистратора», а время жизни ответа в кэше резолверов. От него зависит, как быстро пользователи попадут на новый IP после переезда сайта, смены балансировщика, подключения CDN или миграции DNS-кластера.

Ошибка с TTL редко ломает сайт мгновенно — чаще она делает хуже: часть пользователей уже на новом сервере, часть — на старом, мониторинг показывает нестабильную картину, почта доставляется непредсказуемо, а команда не понимает, можно ли выключать старую инфраструктуру. Особенно неприятно, если высокий TTL забыли снизить заранее.

Разберём, как работает TTL DNS-записей, какие значения выбирать для обычной эксплуатации и миграций, как подготовить переезд без простоя и что проверить в DNS-кластере, чтобы изменения разошлись по всем авторитетным серверам.

Что такое TTL DNS-записи

TTL — Time To Live, время жизни DNS-ответа в кэше. Значение указывается в секундах: 300, 900, 3600, 86400 и так далее.

Когда клиенту нужен IP-адрес домена, запрос обычно идёт не к авторитетному серверу напрямую, а через рекурсивный резолвер: провайдера, корпоративный DNS, публичный резолвер вроде 1.1.1.1, 8.8.8.8, 9.9.9.9 или локальный кэширующий сервис. Получив ответ, резолвер хранит его в кэше ровно столько, сколько разрешает TTL.

example.com. 300 IN A 203.0.113.10

Это значит, что резолвер может кэшировать ответ A для example.com 300 секунд. Если через минуту вы поменяете IP, пользователи с уже закэшированным старым ответом могут ещё несколько минут ходить на старый адрес.

TTL есть не только у A и AAAA — он применяется и к CNAME, MX, TXT, SRV, NS, CAA. Разбор типов записей — в статье DNS-записи простыми словами.

TTL задаёт верхнюю границу кэширования для корректно работающего резолвера, но не гарантирует обновление у всех сразу: есть локальные кэши ОС и браузеров, корпоративные DNS, лимиты некоторых резолверов, отрицательное кэширование для NXDOMAIN.

Чем ниже TTL, тем быстрее можно переключать трафик; чем выше — тем меньше лишних DNS-запросов и стабильнее кэширование.

Где именно срабатывает TTL

Чтобы правильно выбрать значение, нужно понимать путь DNS-запроса:

1) Клиентское приложение — браузер, мобильное приложение, curl, почтовый сервер или другой клиент запрашивает адрес домена; иногда у него есть собственный DNS-кэш.

2) Операционная система — может кэшировать ответы локально: в Linux это зависит от systemd-resolved, nscd, dnsmasq, в Windows и macOS есть свои системные кэши.

3) Рекурсивный резолвер — DNS-сервер провайдера, корпоративной сети или публичный резолвер. Именно здесь TTL играет ключевую роль: ответ хранится до истечения времени жизни.

4) Авторитетные DNS-серверы — серверы, которые реально обслуживают зону домена и отдают актуальные данные, а не кэш.

Если у домена несколько NS, это уже DNS-кластер: набор авторитетных серверов, которые должны отдавать одинаковую зону. Обычно один сервер или панель считается источником данных, а остальные получают изменения через репликацию, API провайдера или AXFR/IXFR.

Корректность ответа зависит от авторитетного уровня: если один NS уже отдаёт новый IP, а другой — старый, резолверы закэшируют разные версии, и проблема будет выглядеть как «DNS ещё не распространился», хотя причина — несогласованность кластера.

Путь запроса подробно разобран в статье как работает DNS, а про кэши и задержки — в материале как работает DNS caching.

Какие значения TTL выбирать

Универсального TTL нет: значение зависит от того, как часто меняется запись, насколько критичен быстрый откат и какой объём DNS-трафика вы готовы обслуживать.

Ориентиры для большинства сайтов:

1) 60 секунд — аварийное значение для короткого окна миграции или failover. Держать его постоянно не стоит: растёт число запросов к авторитетным DNS и чувствительность к сбоям.

2) 300 секунд — рабочий TTL для записей, которые могут меняться: A, AAAA, иногда CNAME на балансировщик или CDN. Даёт быстрый откат без лишней нагрузки.

3) 900–1800 секунд — компромисс для стабильных сайтов, если инфраструктура меняется редко, но нужна возможность переключиться за 15–30 минут.

4) 3600 секунд — классика для стабильных записей: MX, TXT, CAA, части CNAME.

5) 86400 секунд и выше — для очень стабильных служебных записей, но с осторожностью: при внезапном изменении старое значение может жить в кэшах долго.

Для основного сайта часто разумно держать:

• A / AAAA для example.com и www.example.com: 300–1800;
• CNAME на CDN или балансировщик: 300–3600, если провайдер не рекомендует иначе;
• MX: 3600–14400 при стабильной почтовой инфраструктуре;
• TXT для SPF, DKIM, DMARC: 3600–14400, кроме периода настройки;
• CAA: 3600–86400, если редко меняете центры сертификации;
• NS: обычно 3600–86400, но перед сменой DNS-провайдера TTL нужно снижать заранее.

Низкий TTL не ускоряет сам DNS-запрос — он лишь сокращает срок хранения ответа. Если сайт медленно открывается, причина обычно в сети, TLS, сервере, базе или CDN. См. почему сайт долго грузится и почему не работает сайт.

TTL и DNS-кластер: что проверить до изменений

DNS-кластер нужен для отказоустойчивости и географической близости: несколько авторитетных NS отвечают за одну зону. При переезде это добавляет требование — все узлы должны отдавать одинаковые записи. Перед изменением TTL или IP проверьте не только панель DNS, но и фактические ответы каждого сервера.

1) Список авторитетных серверов:

dig NS example.com +short

ns1.dns-provider.net.
ns2.dns-provider.net.
ns3.dns-provider.net.

2) Ответ каждого NS напрямую, минуя рекурсивные кэши:

dig @ns1.dns-provider.net example.com A +noall +answer
dig @ns2.dns-provider.net example.com A +noall +answer
dig @ns3.dns-provider.net example.com A +noall +answer

Все серверы должны вернуть одинаковый IP и TTL.

3) Серийный номер зоны — смотрим SOA:

dig @ns1.dns-provider.net example.com SOA +noall +answer
dig @ns2.dns-provider.net example.com SOA +noall +answer

Если на одном сервере serial новый, а на другом старый — репликация ещё не завершилась или сломалась.

4) Минимальный TTL и отрицательное кэширование — поле в SOA, отвечающее за то, сколько резолвер помнит отрицательный ответ (NXDOMAIN). Если вы удалили запись, а потом быстро вернули её, часть клиентов может ещё видеть «имя не найдено».

5) Ограничения провайдера DNS — некоторые панели округляют TTL до допустимых значений (например, не меньше 300). План миграции должен учитывать реальное, а не желаемое значение.

Для отладки удобен dig — см. утилиту dig. На Windows часто используют nslookup — см. nslookup: проверка DNS.

Как подготовить переезд сайта без простоя

Ключевое правило: снижать TTL нужно заранее, а не в момент переключения. Если сейчас TTL 86400, а вы поставите 300 за пять минут до переезда, это не поможет тем, чьи резолверы уже закэшировали старую запись на сутки, — они узнают о новом TTL только после истечения старого.

Практический план:

1) Узнайте текущий TTL — через несколько резолверов и напрямую через NS:

dig example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @ns1.dns-provider.net example.com A +noall +answer

В кэширующем ответе TTL уменьшается — это остаток жизни записи в конкретном кэше; у авторитетного сервера видно исходное значение.

2) Снизьте TTL заранее — минимум за срок, равный текущему TTL: если было 86400, снижайте за сутки, если 3600 — за несколько часов, с запасом.

3) Поставьте миграционный TTL, обычно 300; для критичных переключений — 60, если провайдер позволяет.

4) Дождитесь вымывания старого TTL — проверьте публичные резолверы и несколько сетей, а не только панель DNS.

5) Подготовьте новый сервер — reverse proxy настроен, сертификаты выпущены, приложение запущено, firewall открыт, health checks проходят. DNS не должен быть первым тестом инфраструктуры.

6) Не выключайте старый сервер сразу — держите его минимум период старого TTL плюс запас, а при агрессивном кэшировании корпоративных резолверов — дольше.

Если переносите сайт на другой reverse proxy или балансировщик, заранее проверьте HTTP-уровень: при Nginx часто всплывают ошибки upstream, редиректов и сертификатов — см. про Nginx reverse proxy.

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

Допустим, example.com сейчас указывает на 198.51.100.10, а нужно переключить его на 203.0.113.20.

1) Снизьте TTL текущей записи, IP пока не трогаем:

example.com. 300 IN A 198.51.100.10
www.example.com. 300 IN A 198.51.100.10

Если www сделан через CNAME, снижайте TTL и у CNAME, и у целевой записи, если она в вашей зоне.

2) Проверьте DNS-кластер — все NS должны отдавать новый TTL и старый IP; если кто-то отстаёт, сначала разберитесь с репликацией.

3) Разверните новый сервер и проверьте его по IP, не меняя DNS:

curl -I --resolve example.com:443:203.0.113.20 https://example.com/
curl -I --resolve www.example.com:443:203.0.113.20 https://www.example.com/

Флаг --resolve подставляет нужный IP для домена без изменения DNS. Подробнее — в статье что такое curl и как им пользоваться.

4) Переключите запись, TTL оставляем низким:

example.com. 300 IN A 203.0.113.20
www.example.com. 300 IN A 203.0.113.20

5) Проверьте авторитетные NS — важнее, чем смотреть только публичные DNS-чекеры.

6) Проверьте рекурсивные резолверы:

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

7) Следите за логами обеих площадок — старый сервер ещё получает часть трафика, пока у кого-то не истёк старый TTL.

8) После стабилизации верните рабочий TTL — 900, 1800 или 3600, по вашей политике.

Удобно вести чеклист с отметками времени: когда снизили TTL, когда обновились авторитетные серверы, когда переключили запись, когда трафик на старый IP сошёл на нет — это упрощает постмортем.

Типичные ошибки с TTL DNS-записей

Ошибки почти всегда связаны не с самим числом, а с ожиданием, что DNS изменится «сразу у всех».

1) Снизили TTL слишком поздно — старый TTL уже разошёлся по кэшам, и новый низкий TTL не влияет на тех, кто получил старый ответ раньше.

2) Поменяли не ту запись — например, обновили A для example.com, а пользователи ходят на www.example.com, который является CNAME на другой хост, или наоборот. Перед работой нарисуйте цепочку www → CNAME → A/AAAA.

3) Забыли про IPv6 — A поменяли, а AAAA осталась на старый сервер, и часть пользователей продолжает попадать на старую площадку.

4) Не проверили все NS — один сервер кластера отдаёт новую зону, другой старую, резолверы кэшируют разные ответы, и снаружи это выглядит как хаотичное распространение DNS.

5) Слишком рано выключили старый сервер — даже при TTL 300 часть клиентов придёт позже из-за локального кэша, корпоративного DNS или долгоживущих соединений.

6) Не учли почту — для MX, SPF, DKIM, DMARC тоже есть TTL; если снизить только веб-записи, сайт переедет, а письма продолжат идти по старым маршрутам.

7) Путают TTL записи и TTL зоны — в zone-файле есть директива $TTL по умолчанию, но у конкретной записи может быть свой TTL, и в панели провайдера это часто скрыто.

8) Ждут «полного распространения DNS» без критерия — лучше опираться на проверки: NS отдают одинаковые данные, резолверы видят новый ответ, старый сервер почти не получает трафик, мониторинг не фиксирует ошибки.

Как проверять результат после переключения

После изменения DNS важно убедиться не только, что домен резолвится в новый IP, но и что сайт работает для пользователей из разных сетей и не ломается на HTTP/TLS-уровне.

1) Авторитетный уровень — запросы напрямую к NS подтверждают, что DNS-кластер отдаёт верную запись:

dig @ns1.dns-provider.net example.com A +noall +answer
dig @ns2.dns-provider.net example.com A +noall +answer

2) Рекурсивные резолверы:

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

Если резолвер ещё показывает старый IP, посмотрите TTL в ответе — возможно, он просто досчитывает старый кэш.

3) HTTP-ответ:

curl -I https://example.com/

Ожидаемы 200, 301 или 302, если редирект настроен осознанно. 502, 503, 504, ошибки TLS или бесконечные редиректы означают, что DNS уже привёл пользователя на новую площадку, но она не готова.

4) Логи старого и нового серверов — на старом трафик должен снижаться, на новом расти. Если старый сервер ещё получает много запросов спустя много часов, проверьте скрытые записи, CDN, корпоративные DNS, IPv6 и hardcoded IP у клиентов.

5) Мониторинг доступности — внешняя проверка помогает заметить момент, когда DNS переключился, но сайт начал отдавать ошибки. Например, Statuser может проверять сайт с заданным интервалом и присылать уведомление о сбоях. Важна и география проверок: маршрутизация может отличаться по регионам.

Для базового контроля см. что такое uptime monitoring, а для выбора частоты проверок — как выбрать интервал проверки сайта: при миграции интервал обычно временно уменьшают.

Когда TTL не спасает

Низкий TTL — полезный инструмент, но не механизм высокой доступности сам по себе. Если сервер умер, а A-запись меняется вручную, даже TTL 60 не даст мгновенного failover: нужно обнаружить сбой, принять решение, изменить DNS, дождаться обновления кэшей. Пользователи с уже закэшированным ответом какое-то время будут идти на недоступный IP.

Для отказоустойчивости лучше комбинировать подходы:

1) Балансировщик перед приложением — домен указывает на стабильный адрес балансировщика, backend-серверы меняются без DNS.

2) CDN или DNS-провайдер с health checks — умеют исключать неработающие origin-серверы, но и здесь важны TTL и поведение клиентов.

3) Blue-green deployment — новая версия выкатывается рядом со старой, переключение происходит на уровне балансировщика, а DNS остаётся стабильным.

4) Готовый откат — если новый сервер ломается, низкий TTL позволяет быстрее вернуть старый IP, но откат должен быть заранее проверен, а старый сервер — жив.

5) Наблюдаемость — логи, метрики, алерты и внешние проверки нужны до начала миграции, а не после жалоб пользователей.

TTL стоит рассматривать как часть эксплуатационной политики: он должен соответствовать архитектуре — одно дело лендинг на одном VPS, другое — сайт за CDN, третье — кластер с несколькими регионами и автоматическим failover.

Практические рекомендации

Коротко — что стоит зафиксировать как правило для большинства проектов:

• держите обычный TTL умеренным: для основных веб-записей чаще всего достаточно 300–1800;
• снижайте TTL до миграции минимум за срок, равный текущему значению TTL;
• не переключайте DNS вслепую — сначала проверьте новый сервер через curl --resolve, сертификаты, редиректы, firewall и health endpoints;
• всегда проверяйте все авторитетные NS через dig @ns..., а не только панель провайдера;
• учитывайте AAAA наравне с A — неправильная IPv6-запись создаёт «частичный» сбой, который сложно воспроизвести;
• не выключайте старую площадку сразу — держите её минимум период старого TTL плюс запас;
• после переезда верните TTL в норму и зафиксируйте стандартные значения в документации или IaC;
• документируйте DNS-зоны: кто владеет доменом, где NS, какие записи критичны, какой TTL штатный, как выполняется откат.

Хороший TTL — не самое маленькое число, а значение, которое соответствует вашему процессу изменений. Если переезды планируются заранее, 300 на время работ и 1800–3600 в обычном режиме часто закрывают потребности. Если нужен быстрый failover, одной настройки TTL мало: нужны мониторинг, автоматизация переключения и архитектура без единой точки отказа.

FAQ

Что означает TTL DNS-записи?
TTL показывает, сколько секунд рекурсивный резолвер может хранить DNS-ответ в кэше. Пока TTL не истёк, резолвер может отдавать старое значение без запроса к авторитетному DNS.

Какой TTL поставить для сайта?
Для A и AAAA основного сайта часто выбирают 300–1800 секунд. Перед переездом временно снижают до 300 или 60, после стабилизации возвращают рабочее значение.

Почему DNS не обновился сразу после смены IP?
Скорее всего, старый ответ ещё живёт в кэше резолверов. Также возможны локальный DNS-кэш, отстающий сервер в DNS-кластере, забытая AAAA-запись или цепочка CNAME, где поменяли не тот узел.

Нужно ли всегда ставить TTL 60 секунд?
Нет. Низкий TTL удобен для миграций и failover-сценариев, но увеличивает число DNS-запросов и не заменяет балансировщик, мониторинг и нормальный план отката.