Что такое DNS-кэш и как долго в нем хранятся записи?

2026-09-22

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

Где на самом деле кэшируется DNS-ответ?

Один запрос проходит через несколько кэшей, прежде чем вы что-либо заметите, и каждый из них держит собственную копию свой собственный срок:

Браузер. Chrome, Edge и Firefox держат собственный небольшой DNS-кэш, отдельный от системного. Кэш Chrome виден на chrome://net-internals/#dns, и его очистка затрагивает только этот браузер, а не всю машину.
Стаб-резолвер ОС. Windows запускает службу DNS-клиента и кэширует ответы, которые можно посмотреть командой ipconfig /displaydns; macOS кэширует через mDNSResponder; на большинстве Linux-окружений работает systemd-resolved, локальный кэширующий стаб-резолвер, который опрашивают командой resolvectl. Это настоящий кэш с собственным отсчетом TTL, а не просто копия того, что держит браузер.
Роутер. Большинство домашних роутеров держат небольшой DNS-форвардер, который отвечает из собственного кэша, прежде чем передать запрос дальше, и именно поэтому перезагрузка роутера иногда чинит проблему с DNS, которая на самом деле была где-то в другом месте.
Рекурсивный резолвер. Резолвер вашего провайдера или публичный сервис обрабатывает большинство запросов в интернете и держит самый большой и самый общий кэш. Как только у него появляется ответ, каждое устройство, которое его спрашивает, получает кэшированную копию до истечения срока.

Каждый слой независим. Очистка кэша на вашем ноутбуке никак не влияет на кэш, который все еще держит ваш роутер или провайдер, и никак не влияет на чужие машины.

Что такое TTL и кто на самом деле его соблюдает?

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

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

Что такое отрицательное кэширование и почему только что созданная запись может оставаться недоступной?

Резолвер кэширует не только существующие записи. Если запрос возвращается с ответом «такого имени не существует» (NXDOMAIN) или без записи запрошенного типа, этот отказ тоже кэшируется, и это называется отрицательным кэшированием. RFC 2308 задает срок жизни отрицательного кэша по полю minimum из SOA-записи, а RFC 9520 теперь делает кэширование такого отказа обязательным для соответствующего стандарту резолвера, а не опциональным.

Это механизм, стоящий за знакомой проблемой: вы создаете новый поддомен, запрашиваете его на секунду раньше времени, получаете NXDOMAIN, и резолвер запоминает «не существует» на весь срок отрицательного TTL зоны, даже когда запись уже существует. Windows показывает оба вида записей отдельно: ipconfig /displaydns выводит и положительные ответы, и отрицательные, а ipconfig /flushdns явно отбрасывает записи отрицательного кэша как часть очистки.

Почему сайт разрешается у вас и не разрешается у кого-то другого?

Потому что единого общего кэша не существует. Двое людей, спрашивающих двух разных резолверов, или один и тот же резолвер в два разных момента, могут получить два разных ответа на одно и то же имя. Копия одного резолвера может быть еще свежей после запроса час назад, а другой мог никогда раньше не видеть это имя и пойдет получать текущее значение. Ни один из них не ошибается, они просто живут по разным часам. Если это произошло сразу после того, как вы изменили запись, руководство как проверить распространение DNS разбирает, как сравнить несколько резолверов рядом и прочитать, сколько времени осталось у каждого.

Как прочитать TTL записи, которая еще в кэше?

Запросите имя напрямую и посмотрите полный вывод вместо короткой формы:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

Число перед типом записи, 847 в этом примере, это секунды, оставшиеся до истечения именно этой копии у именно этого резолвера; это не исходный TTL записи, который может назвать наверняка только авторитативный сервер. Выполните тот же запрос через несколько секунд, и число уменьшится примерно на столько же секунд, подтверждая, что вы читаете живой обратный отсчет, а не статическую настройку. Если имя вообще не разрешается, а не разрешается с маленьким числом, это уже другой отказ: как очистить DNS разбирает, как сначала очистить собственный кэш, а что на самом деле делает DNS-резолвер разбирает, что происходит дальше по цепочке, если проблема не в вашем собственном кэше.

Кэш объясняет, почему один посетитель видит изменение сразу, а другой нет; он не объясняет запись, которая нигде не обновляется никогда. Запустите живой запрос инструментом проверка DNS-запроса, чтобы увидеть текущий ответ из-за пределов вашей собственной сети, а если сайт должен оставаться доступным по расписанию, а не проверяться разово, для этого существует распределенный мониторинг из множества точек проверки. HostTracker следит за сайтами с 2004 года, сейчас наблюдает более 500 000 сайтов из более чем 300 точек проверки в 158 городах и оповещает по email, SMS, голосовым звонком, в Slack, Telegram и другими способами, когда проверка проваливается, включая проверку, которая ожидает конкретный IP-адрес и отмечает момент, когда ответ меняется.

Часто задаваемые вопросы

Замедляет ли переполненный DNS-кэш компьютер?

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

Помогает ли очистка моего кэша другим людям?

Нет. ipconfig /flushdns, dscacheutil -flushcache и resolvectl flush-caches очищают кэш только на той машине, где вы их выполняете. Все остальные по-прежнему читают из своего собственного браузера, своего роутера и своего резолвера, каждый по своему собственному таймеру.

DNS-кэш это то же самое, что кэш CDN?

Нет, хотя их часто путают. DNS-кэш хранит ответ на вопрос «какой IP-адрес у этого имени». Кэш CDN хранит само содержимое страницы или файла на сервере, ближнем к посетителю. Очистка одного никак не влияет на другой.

Могу ли я сам задать TTL, если не управляю доменом?

Нет. TTL это свойство записи, заданное в авторитативной зоне тем, кто управляет DNS домена. Как посетитель, единственное, что вы можете сделать, это выбрать резолвер, который соблюдает короткий TTL, а не применяет собственный минимум.

Почему TTL, который я вижу, меняется при каждом запросе?

Потому что вы спрашиваете другой резолвер или тот же самый, но в другой момент его обратного отсчета. Запросите авторитативный сервер имен напрямую командой dig example.com @ns1.yourdns.example, чтобы увидеть TTL таким, каким он был изначально задан, без какого-либо отсчета.