TTL в DNS: почему изменения не применяются часами
Вы поменяли IP-адрес сайта, у вас всё открывается, а клиент из другого города по-прежнему видит старую версию. Дело почти всегда в TTL — числе, которое управляет тем, как долго провайдеры помнят прежний ответ.
Что такое TTL
TTL (time to live) — это срок жизни DNS-записи в кэше, заданный в секундах. Он идёт вместе с ответом: сервер имён сообщает не только «домен указывает на такой-то IP», но и «считай этот ответ верным столько-то секунд».
Смысл механизма в экономии. Если бы каждый браузер спрашивал адрес заново при каждом переходе, корневые серверы DNS утонули бы в запросах, а страницы открывались бы заметно медленнее. Вместо этого ответ кэшируют все по цепочке: браузер, операционная система, резолвер интернет-провайдера.
Обратная сторона в том, что кэш нельзя очистить снаружи. Резолвер провайдера в другом городе не подчиняется вам: он выбросит устаревшую запись ровно тогда, когда истечёт TTL, который вы указали заранее.
Почему «у меня открывается, а у клиента нет»
Это самый частый вопрос после смены сервера, и ответ на него один: вы и клиент спрашиваете адрес у разных резолверов, и кэши у них независимые.
Ваш путь короче: вы, скорее всего, уже чистили кэш, перезагружали браузер или ходите через публичный DNS вроде 8.8.8.8, который обновляется быстро. У клиента запрос уходит к резолверу его провайдера, где старая запись лежит со своим отсчётом. Пока этот отсчёт идёт, человек попадает на прежний сервер — и никакие действия на вашей стороне это не ускорят.
Отсчёт TTL начинается не с момента, когда вы поменяли запись, а с момента, когда конкретный резолвер получил старый ответ. Если он закэшировал его за минуту до вашей правки при TTL в сутки, этот резолвер будет отдавать устаревший адрес почти сутки. Поэтому TTL снижают заранее, а не в день переключения.
Какой TTL ставить
Универсального значения нет: короткий TTL даёт гибкость, длинный — устойчивость и меньше запросов. Разумный подход — держать длинный в обычном режиме и временно снижать перед плановыми изменениями.
| Ситуация | TTL | Почему так |
|---|---|---|
| Обычный режим | 3600–86400 с (час–сутки) | Меньше нагрузки, быстрее отклик, устойчивость к сбоям DNS-провайдера |
| За 1–2 суток до переезда | 300 с (5 минут) | Старые записи успевают вымыться из кэшей до переключения |
| Через 2–3 суток после | Вернуть к обычному | Гибкость больше не нужна, а нагрузка на резолверы лишняя |
| MX и TXT-записи | Длинный, от часа | Меняются редко, а сбой в них ломает почту целиком |
Как посмотреть текущий TTL
В ответе утилиты dig TTL стоит вторым столбцом — это оставшееся время жизни записи в кэше того резолвера, к которому вы обратились:
dig example.ru A +noall +answer
Чтобы увидеть значение, которое вы прописали, а не остаток в чужом кэше, спрашивайте напрямую у авторитетного сервера домена:
dig @ns1.example-dns.ru example.ru A +noall +answer
Полезный приём при переезде: запросить адрес через несколько публичных резолверов подряд. Если один уже отдаёт новый IP, а другой ещё старый, распространение записи идёт — нужно просто дождаться истечения TTL.
Когда виноват не TTL
Если после смены записи прошло заметно больше указанного срока, а старый адрес всё ещё отдаётся, дело обычно не в кэше.
Проверьте, у тех ли NS-серверов вы правите зону: домен может быть делегирован одному провайдеру, а вы редактируете записи в панели другого — тогда правки просто никуда не попадают. Второй частый случай — конфликт записей: осталась старая A-запись рядом с новой или CNAME соседствует с A на том же имени. Третий — записи с одинаковым именем на поддомене www и на голом домене, которые правят по отдельности и забывают про вторую.
Пруфен ежедневно сверяет DNS-записи домена с ожидаемыми значениями и сообщает, если A, MX или TXT изменились — это ловит и чужое вмешательство, и собственную ошибку в панели. Отдельная проверка следит за сроком регистрации домена, чтобы он не закончился тихо. Уведомления приходят на Email, в Telegram, в Макс или звонком; бесплатно доступны 5 проверок без ограничения по времени.
Частые вопросы
Можно ли поставить TTL в 60 секунд навсегда? Технически да, но это ухудшает жизнь: резолверы чаще ходят за ответом, а при недоступности вашего DNS-провайдера сайт перестанет открываться почти сразу — длинный TTL в такой ситуации служит подушкой безопасности.
Помогает ли очистка кэша DNS на компьютере? Она чинит только вашу машину. Кэш резолвера провайдера и промежуточных серверов останется прежним, поэтому клиенты будут видеть старый адрес независимо от того, сколько раз вы выполните команду сброса.
Соблюдают ли провайдеры TTL? В основном да, но не все: некоторые резолверы устанавливают собственный минимум и держат записи дольше указанного. Поэтому при переезде закладывайте запас и не выключайте старый сервер сразу.
Влияет ли TTL на скорость сайта? Косвенно. Само разрешение имени занимает десятки миллисекунд, и при коротком TTL эта задержка возникает чаще. На фоне общего времени загрузки эффект небольшой, но при очень коротких значениях он становится заметен.