DNS-кэширование¶

DNS-кэширование — это механизм временного хранения результатов DNS-запросов (соответствий между доменными именами и IP-адресами) на различных уровнях инфраструктуры сети, предназначенный для ускорения разрешения имён и снижения нагрузки на авторитетные DNS-серверы. Процесс регламентирован стандартами RFC 1034 и RFC 1035, а также более поздними дополнениями (RFC 2181, RFC 8767).

¶Принцип работы

При обращении клиента к доменному имени (например, example.com) его DNS-резолвер проверяет локальный кэш. Если запись отсутствует или её срок жизни истёк, запрос передаётся вышестоящему серверу. Ответ, полученный от авторитетного сервера, сохраняется в кэше с указанием времени жизни записи (TTL, Time to Live). Последующие запросы к тому же имени обслуживаются из кэша без обращения к внешней сети.

¶Ключевые параметры

• TTL (Time to Live) — время в секундах, в течение которого запись считается актуальной. Задаётся авторитетным сервером для каждой записи. Стандартные значения варьируются от 60 секунд (для записей, подверженных частым изменениям) до 86400 секунд (24 часа) для стабильных ресурсов.
• Отрицательное кэширование — хранение информации об отсутствии записи (NXDOMAIN). Регламентируется RFC 2308. Позволяет не повторять безуспешные запросы в течение заданного периода (обычно 5–15 минут).
• Приоритет записей — при наличии нескольких ресурсных записей (например, A и AAAA) кэшируются все, выборка происходит при формировании ответа клиенту.

¶Уровни кэширования

¶Локальный кэш операционной системы

Каждая ОС (Windows, Linux, macOS) имеет собственный кэш DNS-резолвера. Обычно хранит небольшое количество записей (до нескольких тысяч) с коротким сроком жизни (по умолчанию 5–60 секунд). Управляется командами ipconfig /flushdns (Windows) или systemd-resolve --flush-caches (Linux).

¶Кэш промежуточных резолверов

Рекурсивные DNS-серверы (например, BIND, Unbound, системные резолверы интернет-провайдеров) кэшируют ответы для всех своих клиентов. Объём кэша может достигать десятков миллионов записей. Именно этот уровень обеспечивает основное снижение нагрузки на корневые и авторитетные серверы.

¶Кэш браузеров и приложений

Современные браузеры (Chrome, Firefox, Safari) имеют встроенный DNS-кэш с ограниченным сроком хранения (обычно 60 секунд), что позволяет ускорить повторные посещения сайтов без обращения к ОС.

¶Преимущества

• Снижение задержек — ответ из кэша занимает 1–10 миллисекунд против 20–100 миллисекунд при полном рекурсивном запросе.
• Уменьшение сетевого трафика — по оценкам, кэширование позволяет сократить количество DNS-запросов к корневым серверам на 80–95%.
• Отказоустойчивость — при недоступности авторитетного сервера клиенты продолжают получать ответы из кэша до истечения TTL.

¶Проблемы и ограничения

• Устаревание данных — если TTL задан слишком большим, клиенты могут получать IP-адреса, которые уже не используются (например, после смены хостинг-провайдера). Это приводит к ошибкам соединения.
• DNS-отравление (cache poisoning) — атака, при которой в кэш резолвера внедряются ложные записи. Методы защиты включают DNSSEC (RFC 4033–4035) и рандомизацию портов (RFC 5452).
• Несоответствие TTL — некоторые провайдеры игнорируют TTL, заданный авторитетным сервером, и устанавливают собственные значения (обычно 300–600 секунд), что может нарушать работу сервисов с динамическим обновлением записей.
• Приватность — кэш резолвера провайдера хранит историю запросов всех пользователей, что создаёт риски для конфиденциальности. Решением выступают протоколы DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT).

¶Очистка и управление

Администраторы могут принудительно очищать кэш при изменении инфраструктуры (смена IP-адреса сервера) или при подозрении на отравление. Для этого используются команды rndc flush (BIND), unbound-control flush_zone (Unbound) или перезапуск службы резолвера. В операционных системах Windows очистка выполняется командой ipconfig /flushdns, в Linux — перезапуском службы systemd-resolved.

¶Источники

• RFC 1034, RFC 1035 — Domain Names: Concepts and Facilities.
• RFC 2181 — Clarifications to the DNS Specification.
• RFC 2308 — Negative Caching of DNS Queries.
• RFC 8767 — Serving Stale Data to Improve DNS Resiliency.
• Документация BIND 9 и Unbound.