Почему изменения DNS видны не сразу

После замены IP-адреса в DNS новый ответ редко появляется у всех пользователей одновременно. Причина не в пересылке единой базы «по всему интернету». Авторитетные серверы публикуют данные зоны, а рекурсивные резолверы запрашивают их по мере необходимости и временно сохраняют. Каждый кеш мог получить старую запись в разный момент.

Популярное выражение «распространение DNS» удобно, но создаёт неверный образ волны обновления. Чаще происходит истечение множества независимых кешей. При этом изменение NS у регистратора, обновление записи внутри зоны и настройка CDN проходят по разным цепочкам и могут иметь разные сроки.

Роль TTL

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

Уменьшение TTL после изменения не сокращает срок копии, уже сохранённой с прежним большим TTL. Поэтому перед плановым переносом TTL обычно снижают заранее и ждут, пока прежнее значение успеет выйти из кешей. Подходящий интервал зависит от исходного TTL и процедуры поставщика.

TTL не является точным таймером, после которого все пользователи гарантированно обновятся. RFC допускают специальные режимы устойчивости, включая выдачу устаревших данных при проблемах с авторитетными серверами. Дополнительные кеши приложений и прокси также могут жить по своим правилам.

Положительный и отрицательный кеш

Кешируется не только найденный IP. Ответ о том, что имя не существует (NXDOMAIN) или что у существующего имени нет записи нужного типа, тоже может быть сохранён. Это называется отрицательным кешированием, а его срок связан с параметрами SOA по правилам DNS.

Практический эффект заметен при создании нового поддомена. Если клиент запросил new.example.com до публикации и получил NXDOMAIN, повторная проверка сразу после создания записи может всё ещё показывать отсутствие. Не следует многократно удалять и создавать запись: сначала сравните авторитетный и рекурсивный ответы.

Как определить источник задержки

Откройте проверку DNS-записей и зафиксируйте точное имя, тип и время. Затем в dig узнайте авторитетные серверы:

dig example.com NS +short

Запросите запись непосредственно у каждого из них:

dig @<authoritative-server> www.example.com A

Замените заполнитель именем реального NS. Если авторитетные серверы показывают разные значения или один не отвечает, проблема не сводится к пользовательскому кешу: нужно проверить публикацию зоны у DNS-провайдера.

После этого выполните обычный запрос через системный рекурсивный сервер:

dig www.example.com A

Сравните значение, TTL и цепочку CNAME. Если авторитетный ответ новый, а рекурсивный старый с уменьшающимся TTL, обычно достаточно дождаться истечения. Не используйте случайные открытые резолверы для внутренних имён: запрос может раскрыть имя внешнему оператору и не получит доступ к закрытой зоне.

Практический пример переноса сайта

Допустим, www.example.com меняет адрес со старого хостинга на новый.

1. За несколько исходных TTL до окна работ уменьшите TTL, если это допускает DNS-провайдер. Дождитесь, пока записи с прежним высоким значением перестанут быть актуальными.
2. Подготовьте новый сервер, сертификат и виртуальный хост до изменения DNS.
3. Измените A и, при наличии, AAAA. Проверьте, не ведёт ли имя через CNAME, который меняется в другом месте.
4. Убедитесь, что каждый авторитетный NS отвечает новым значением.
5. Оставьте старый сервер работоспособным на переходный период, если архитектура и требования безопасности это позволяют.
6. Наблюдайте за запросами и ошибками обоих узлов, а TTL верните к рабочему значению после стабилизации.

Такой подход уменьшает риск, но не создаёт атомарного переключения. Долгоживущие соединения, HTTP-кеш, CDN и фоновые задания способны продолжать обращаться к старой инфраструктуре уже после обновления DNS.

Когда дело не в DNS

Если A и AAAA уже правильные, проверьте другие уровни. Браузер может следовать закешированному HTTP-перенаправлению. CDN может хранить старую страницу. В файле hosts способна остаться ручная запись. Корпоративный прокси может обслуживать кешированный контент. Наконец, новый IP может вести на сервер, который по ошибке показывает прежний сайт из общего хранилища.

Сравните фактическое соединение с DNS-ответом и выполните проверку сайта. Не отключайте проверку TLS и не редактируйте системный hosts как постоянное исправление. Временная запись допустима для контролируемого теста, если команда понимает, что она обходит DNS и должна быть удалена после проверки.

Частые ошибки

• Снижать TTL одновременно с заменой адреса и ожидать мгновенного эффекта.
• Проверять только один рекурсивный сервер и объявлять всю зону обновлённой.
• Забывать про AAAA, CNAME или отдельный поддомен www.
• Путать TTL DNS с временем кеширования HTML в браузере или CDN.
• Считать любой SERVFAIL старым кешем, не проверяя DNSSEC и доступность NS.
• Перезапускать локальный компьютер в надежде очистить кеши провайдера.
• Удалять старый сервер сразу после изменения записи.
• Не фиксировать точное время изменения и прежние значения.

Корректная диагностика идёт от источника наружу: панель зоны, все авторитетные серверы, рекурсивный резолвер, системный кеш и приложение. Это позволяет назвать конкретный уровень задержки вместо неопределённого ожидания «распространения».

Частые вопросы

Сколько времени распространяются изменения DNS?

Единого срока нет. Он зависит от прежнего TTL, типа изменения, отрицательного кеша, согласованности авторитетных серверов и локальных уровней кеширования. Сначала подтвердите новое значение у авторитетного источника, затем учитывайте оставшийся срок старых ответов.

Можно ли очистить DNS-кеш сразу во всём интернете?

Нет. Рекурсивными серверами управляют независимые операторы, и централизованной кнопки очистки всех кешей не существует. Можно очистить свой локальный кеш или кеш контролируемого резолвера, но это не изменит уже сохранённые ответы у других сетей.

Почему авторитетный сервер уже показывает новую запись, а браузер ещё открывает старый сайт?

Браузер или системный резолвер может использовать старый DNS-ответ, полученный до изменения. Также результат могут кешировать приложение, прокси или CDN, а старый сервер способен отдавать перенаправление независимо от DNS.