Кэширование DNS: почему сайт «то открывается, то нет» и как сбросить кэш

У вас сайт открывается, у клиента — нет. После переезда на новый сервер половина посетителей ещё сутки ходит на старый. Домен давно продлили, а браузер упорно пишет «сайт не найден». За всеми этими странностями стоит один механизм — DNS-кэш. Разбираем, где он живёт, почему «врёт» и как его сбросить на каждом уровне.

DNS-кэш — это временное хранение ответов DNS: узнав IP-адрес сайта один раз, система запоминает его и не переспрашивает, пока не истечёт срок жизни записи (TTL). Без кэша каждый клик порождал бы цепочку запросов через пол-интернета; с кэшем подавляющее большинство обращений решается мгновенно и локально. Плата за скорость — инерция: когда запись меняется, мир узнаёт об этом не сразу, а по мере истечения TTL в тысячах независимых кэшей.

Четыре этажа кэша

Между вами и авторитативным DNS-сервером сайта — целая лестница кэшей, и каждый может помнить своё:

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

Отрицательный кэш: когда запоминают «сайта нет»

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

Как сбросить DNS-кэш

Сброс имеет смысл, когда вы знаете, что записи изменились, а ваша машина держит старьё. Идём снизу вверх:

# Windows (командная строка от администратора):
ipconfig /flushdns

# macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd):
sudo resolvectl flush-caches

# Chrome (кэш самого браузера):
chrome://net-internals/#dns → Clear host cache

Роутер сбрасывается перезагрузкой. А вот на кэш провайдера повлиять нельзя — можно только обойти его, временно прописав публичный резолвер (Яндекс 77.88.8.8, Google 8.8.8.8) в настройках сети: свежие записи он, скорее всего, уже видит. Если после сброса всех доступных кэшей сайт так и не открывается — дело не в кэше; пройдитесь по нашей инструкции «Интернет работает, а сайт не открывается».

Как заглянуть в кэш и проверить, что он держит

Прежде чем сбрасывать — полезно посмотреть, что именно закэшировано и надолго ли. Команда dig показывает оставшийся TTL прямо в ответе:

$ dig prufen.ru A

;; ANSWER SECTION:
prufen.ru. 247 IN A 93.184.216.34
# ^^^
# это остаток TTL в секундах: через 247 секунд
# резолвер переспросит авторитативный сервер

Повторите команду через несколько секунд — число уменьшится: вы наблюдаете обратный отсчёт кэша вашего резолвера. Если после смены записей dig показывает старый IP с остатком TTL в тысячи секунд — вот и ответ, сколько ещё ждать этому конкретному резолверу. В Windows содержимое системного кэша можно посмотреть командой ipconfig /displaydns — заодно увидите, сколько мусора там накапливается.

Сравнение нескольких резолверов даёт карту распространения изменений: спросите свой, Яндекс (77.88.8.8), Google (8.8.8.8) — совпадающие свежие ответы означают, что изменение долетело до крупных кэшей, а отстающий резолвер вашего провайдера — это просто вопрос времени. Расшифровка полей ответа и типовые сценарии — в инструкции по проверке DNS-записей.

Стоит ли переходить на публичный резолвер насовсем

Раз уж публичные DNS помогают обойти залипший кэш провайдера — может, прописать их навсегда? Аргументы за: крупные резолверы быстро обновляются, стабильно работают и не подменяют ответы (некоторые провайдеры грешат перехватом NXDOMAIN под собственную страницу с рекламой). Аргументы против: чуть большее время отклика, если узел резолвера далеко; возможные тонкости с CDN — некоторые сети подбирают ближайший к резолверу, а не к вам, сервер раздачи. Для большинства пользователей разница неощутима; правило простое — если родной резолвер провайдера не создаёт проблем, менять его незачем, а если сайты периодически «не находятся» без причины, публичный DNS — первое, что стоит попробовать.

Владельцу сайта: как не воевать с чужими кэшами

Чужие кэши не сбросить — ими можно только управлять заранее, через TTL. Главное правило переезда: за сутки-двое до смены записей снизьте TTL до 300–600 секунд, дождитесь, пока старый длинный TTL истечёт во всех кэшах, потом меняйте IP — переходный период сожмётся с суток до минут. После стабилизации TTL возвращают к обычным значениям. Подробно про выбор значений — в статье о TTL в DNS, а полный чек-лист переезда — в руководстве по смене хостинга.

И последнее: расползание изменений по кэшам — процесс невидимый, и именно поэтому ошибки в DNS живут так долго. Проверка DNS-записей по расписанию сверяет фактические ответы с эталоном и сигналит при любом расхождении, а проверка доступности (GET) из разных городов показывает, где сайт уже отвечает по-новому, а где ещё нет.