Когда и как очищать кэш DNS-сервера: проверенные сценарии для системных администраторов | AdminWiki
AdminWiki

Когда и как очищать кэш DNS-сервера: проверенные сценарии для системных администраторов

31 мая 2026 10 мин. чтения
Содержание статьи

Очистка кэша DNS-сервера — это не профилактическая процедура, а конкретное действие для решения проблем. Выполняйте её, когда изменение DNS-записи должно вступить в силу немедленно, не дожидаясь истечения TTL. Кэш существует на нескольких уровнях, и чистить нужно именно тот, где застряли старые данные: авторитативный сервер зоны, рекурсивный резолвер (BIND, Windows DNS Server), клиентская ОС (Windows, Linux, macOS) и роутер или файрвол с DNS-прокси. Это критически важно при миграции сервисов, смене хостинга, отладке SSL-сертификатов или устранении последствий атак. В этой статье вы найдёте проверенные сценарии, пошаговые инструкции и конкретные команды для очистки кэша (flush DNS) на всех уровнях инфраструктуры.

Быстрые команды

Если нужно очистить DNS-кэш прямо сейчас, возьмите команду для своего уровня. Развёрнутые пояснения — в разделе Конкретные команды для очистки кэша на всех уровнях.

  • BIND (Linux): sudo rndc flush — когда нужно сбросить кэш рекурсивного резолвера целиком; точечно — rndc flushname example.com, по дереву имён — rndc flushtree example.com.
  • Windows DNS Server: dnscmd /clearcache (или «Очистить кэш» в оснастке DNS) — когда внутренние клиенты должны получить обновлённый ответ от внешней зоны.
  • Windows-клиент: ipconfig /flushdns — когда запись закэширована на рабочей станции или сервере.
  • Linux (systemd-resolved): sudo systemd-resolve --flush-caches — когда локальный резолвер отдаёт устаревший ответ.
  • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
  • MikroTik: /ip dns cache flush — когда кэш держит роутер или шлюз на периметре сети.

Краткое содержание

Зачем и когда кэш DNS становится проблемой

DNS-кэш ускоряет разрешение имён, сохраняя ответы на предыдущие запросы. Проблема возникает, когда данные в кэше устаревают, но не обновляются. Это происходит после изменений DNS-записей: A, CNAME, NS или CAA. Основное правило: очистка кэша нужна всегда, когда вы изменили DNS-запись и хотите, чтобы изменение применилось сразу, а не через время, указанное в TTL. Ключевые сценарии: миграция сервисов на новые IP-адреса, смена доменных имён или хостинг-провайдера, отладка проблем с SSL-сертификатами, устранение последствий DNS-спуфинга.

Как работает DNS-кэш и почему он «застревает»

Кэширование происходит на нескольких уровнях. Авторитативный DNS-сервер хранит канонические записи зоны. Рекурсивный резолвер (например, корпоративный BIND или публичный 8.8.8.8) кэширует ответы от авторитативных серверов для своих клиентов. Клиентская операционная система также имеет собственный кэш (как служба DNS Client в Windows или systemd-resolved в Linux).

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

Практические сценарии: диагностика и пошаговые действия

Каждый сценарий требует своего подхода. Диагностика начинается с проверки: даёт ли публичный DNS (например, dig @8.8.8.8 example.com) другой ответ, чем локальный резолвер (dig @внутренний-dns example.com)? Если ответы различаются, проблема в кэшировании.

Сценарий 1: Миграция сервиса на новый IP-адрес

Вы меняете A-запись, указывающую домен на новый IPv4-адрес сервера. Симптом: часть пользователей продолжает обращаться на старый адрес. Диагностируйте командой dig с разных точек сети.

Порядок действий:

  1. Обновите A-запись в зоне на авторитативном DNS-сервере.
  2. Очистите кэш авторитативного сервера, если он его поддерживает.
  3. Очистите кэш всех внутренних рекурсивных DNS-резолверов.
  4. Запустите очистку кэша на критически важных шлюзах или файрволах.

Влияние на инфраструктуру: после очистки резолверы начнут массово запрашивать обновлённую A-запись у авторитативных серверов. Это создаст временную вспышку нагрузки. Чтобы минимизировать простои, заранее, за несколько дней до миграции, снизьте TTL записи до минимального значения (например, 60 секунд). Это ускорит естественное обновление кэшей.

Сценарий 2: Смена доменного имени или хостинг-провайдера

При переносе сайта вы работаете с CNAME-алиасами или меняете NS-записи (делегирование домена новому хостинг-провайдеру). Особенность: кэшируются не только конечные A-записи, но и записи о делегировании (NS).

Порядок действий при переходе к новому хостинг-провайдеру:

  1. Обновите NS-записи у регистратора домена, указав серверы имен нового провайдера.
  2. Убедитесь, что на новом хостинге настроена и корректно работает ваша DNS-зона.
  3. Ожидайте распространения изменений NS-записей по всему миру. Этот процесс может занимать до 48 часов из-за кэширования на корневых и TLD-серверах.
  4. После подтверждения работы новой зоны очистите кэш внутренних корпоративных DNS-серверов, чтобы ускорить переход для локальных пользователей.

Проверьте glue-записи (IP-адреса NS-серверов) у регистратора. Их отсутствие или ошибка приведут к проблемам с разрешением домена.

Сценарий 3: Отладка проблем с SSL-сертификатами и CAA-записями

CAA-запись (Certificate Authority Authorization) определяет, какие центры сертификации могут выпускать SSL-сертификаты для домена. Если вы изменили CAA-запись, чтобы разрешить выпуск новому CA, а старые кэшированные данные блокируют процесс, потребуется очистка.

Симптом: центр сертификации (Let's Encrypt, DigiCert) сообщает об ошибке валидации, не находя новую CAA-запись.

Диагностика: проверьте актуальную CAA-запись через публичный DNS: dig example.com CAA. Сравните с ответом от вашего внутреннего резолвера.

Действия:

  1. Обновите TXT или CAA-запись в DNS-зоне.
  2. Принудительно очистите кэш рекурсивных резолверов, которые использует центр сертификации. Часто CA используют публичные DNS (Google, Cloudflare). Вы не можете очистить их кэш, поэтому важно заранее снизить TTL для CAA-записи.
  3. Очистите кэш ваших внутренних DNS-серверов, через которые может проходить запрос от CA.

Для комплексного понимания работы с кэшем в веб-инфраструктуре, включая прокси-серверы, изучите статью Полная настройка кэширования Nginx.

Сценарий 4: Устранение последствий атаки DNS-спуфинг

При DNS-спуфинге злоумышленник подменяет ответы DNS, направляя пользователей на фишинговые сайты. После восстановления корректных записей в авторитативной зоне ложные данные остаются в кэшах скомпрометированных резолверов.

Алгоритм действий в инциденте:

  1. Локализация. Определите, какие внутренние DNS-резолверы или сетевые шлюзы могли получить сфальсифицированные ответы. Анализируйте их логи.
  2. Очистка. Немедленно очистите DNS-кэш на всех идентифицированных внутренних серверах, маршрутизаторах и файрволах.
  3. Принудительное обновление. На критически важных серверах-клиентах (например, на почтовых шлюзах, серверах CI/CD) выполните очистку кэша ОС.

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

Конкретные команды для очистки кэша на всех уровнях

DNS-серверы: BIND (Linux) и Windows DNS Server

BIND (named):

  • rndc flush — очищает весь кэш рекурсивного резолвера. Когда применять: после массовых изменений в зоне, когда нужно сбросить всё сразу. Выполняйте на серверах, которые выполняют рекурсивные запросы для клиентов.
  • rndc flushname example.com — удаляет из кэша все записи, связанные с указанным доменным именем. Когда применять: точечно, когда нужно обновить одну зону, не трогая остальной кэш.
  • rndc flushtree example.com — удаляет из кэша имя и все записи под ним (например, mail.example.com). Когда применять: при смене сразу нескольких поддоменов.

Windows DNS Server:

  • Через консоль управления DNS: щёлкните правой кнопкой мыши по серверу и выберите «Очистить кэш». Когда применять: разовая ручная операция на одном сервере.
  • Через командную строку с утилитой dnscmd: dnscmd /clearcache. Когда применять: при очистке на нескольких серверах, в том числе через PowerShell-скрипты.

В среде Active Directory с интегрированными зонами изменения записей распространяются через репликацию AD. Очистка кэша сервера не затрагивает эту реплицированную данные, но очищает кэшированные ответы от внешних доменов.

Клиентские операционные системы: Windows, Linux, macOS

Windows:

  • Откройте командную строку от имени администратора и выполните: ipconfig /flushdns. Когда применять: запись закэширована на конечной рабочей станции или сервере.
  • Службу DNS Client можно перезапустить: net stop dnscache && net start dnscache (в некоторых версиях Windows служба называется «DNS Client»). Когда применять: если одной команды ipconfig /flushdns недостаточно.

Linux (варианты в зависимости от резолвера):

  • systemd-resolved: sudo systemd-resolve --flush-caches (в свежих версиях systemd та же операция выполняется командой sudo resolvectl flush-caches). Когда применять: локальный резолвер отдаёт устаревшие ответы.
  • NetworkManager: Перезапуск службы сбросит кэш: sudo systemctl restart NetworkManager. Когда применять: кэш обслуживает сам NetworkManager.
  • nscd (Name Service Cache Daemon): sudo nscd -i hosts. Когда применять: в системе работает nscd и кэширует ответы для getent и приложений.

macOS:

  • Версии до macOS Monterey: sudo killall -HUP mDNSResponder.
  • Новые версии: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.

Используйте команды для клиентских ОС, когда очистка на серверах не дала результата и есть подозрение, что запись закэширована на конечной рабочей станции. Для мобильных устройств порядок действий отличается: он разобран отдельно в статье Как очистить DNS-кэш на Android и iPhone.

Сетевое оборудование (роутеры, маршрутизаторы)

Многие офисные и домашние маршрутизаторы (Cisco Small Business, MikroTik, потребительские роутеры от TP-Link, ASUS) имеют встроенный DNS-кэш или DNS-прокси.

Общий принцип:

  1. Войдите в веб-интерфейс или CLI роутера.
  2. Найдите раздел, связанный с DNS, LAN или DHCP-сервером.
  3. Ищите опцию «Очистить DNS-кэш», «Сбросить DNS» или аналогичную.

Пример для MikroTik CLI: /ip dns cache flush

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

Планирование, влияние на инфраструктуру и минимизация рисков

Что происходит в сети после очистки кэша

Мгновенная очистка кэша на рекурсивных резолверах приводит к волновому эффекту. Все клиентские запросы, которые ранее обслуживались из кэша, теперь будут вызывать новые рекурсивные запросы к авторитативным DNS-серверам. Это создаёт всплеск трафика и нагрузки на авторитативные серверы, что в крайнем случае может привести к отказу в обслуживании (DoS). Время полного распространения изменений зависит от иерархии: очистка корпоративного резолвера обновит данные для внутренних пользователей, но пользователи за пределами сети продолжат видеть старые данные, пока не истечёт TTL в кэшах их интернет-провайдеров или публичных DNS.

Чек-лист и автоматизация для масштабных изменений

Для плановой миграции используйте этот чек-лист:

  1. За 72-24 часа до изменений: Снизьте TTL изменяемых DNS-записей до 60-300 секунд.
  2. В момент изменений: Обновите записи в авторитативной зоне.
  3. Сразу после обновления: Запустите скрипты очистки кэша в порядке от центра к периферии: авторитативные серверы -> внутренние рекурсивные резолверы -> кэширующие шлюзы.
  4. Мониторинг: Наблюдайте за нагрузкой на авторитативные серверы и количеством DNS-запросов.

Пример Bash-скрипта для очистки кэша BIND на нескольких серверах:

#!/bin/bash
SERVERS=("dns1.example.com" "dns2.example.com")
for server in "${SERVERS[@]}"; do
    ssh admin@$server "sudo rndc flush"
    echo "Кэш очищен на $server"
done

Пример PowerShell для Windows DNS:

$Servers = @("dc01", "dc02")
foreach ($srv in $Servers) {
    Invoke-Command -ComputerName $srv -ScriptBlock { dnscmd /clearcache }
}

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

Типичные ошибки и как их избежать

  • Очистка только на одном уровне. Очистили кэш на BIND, но забыли про кэш на файрволе или в Windows DNS на филиале. Решение: составьте карту всех устройств в сети, которые могут кэшировать DNS.
  • Игнорирование кэша CDN или обратных прокси. Сервисы вроде Cloudflare или Nginx в роли обратного прокси также могут кэшировать DNS-записи. Решение: используйте механизмы инвалидации, предоставляемые этими сервисами, или очищайте их кэш через панель управления/API. Стратегии инверсного кэширования для разгрузки бэкенда рассмотрены в статье Инверсное кэширование: стратегия разгрузки бэкенда.
  • Очистка в час пик. Это вызовет всплеск запросов и может замедлить работу. Решение: планируйте работы на время наименьшей нагрузки.
  • Забывание про кэш браузеров. Браузеры (Chrome, Firefox) имеют собственный DNS-кэш. Решение: сообщите пользователям о необходимости перезапуска браузера или используйте функцию сброса сетевых настроек в браузере.

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

Поделиться: