Сброс DNS-кэша на Linux-серверах: systemd-resolved, dnsmasq, BIND (Актуально в 2026)

Когда доменное имя не разрешается или показывает старый IP-адрес после его изменения, проблема часто лежит в устаревшем DNS-кэше на вашем сервере. Это практическое руководство содержит точные, проверенные команды для принудительной очистки кэша трех основных демонов: systemd-resolved, dnsmasq и BIND (через rndc flush). Инструкции адаптированы под современные дистрибутивы - Debian/Ubuntu и CentOS/RHEL - и актуальны в 2026 году. Вы получите алгоритм диагностики работающего демона, команды для сброса, методы проверки успешности и решения для автоматизации.

Операция безопасна для рабочего сервера и не приводит к сбоям служб. Кратковременное влияние - увеличение нагрузки на upstream DNS-серверы в момент первого запроса после очистки - минимально и быстро компенсируется новым кэшированием.

Зачем и когда нужен принудительный сброс DNS-кэша на сервере

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

После изменения DNS-записей домена, например, при миграции сервиса на новый IP-адрес или смене хостинг-провайдера, кэш может сохранять старый адрес до истечения TTL, которое иногда достигает нескольких часов. При обнаружении некорректного IP в кэше, что может быть следствием атаки cache poisoning или ошибки конфигурации, требуется немедленная очистка. После обновления настроек локального резолвера, например, добавления новых upstream серверов, сброс кэша гарантирует применение изменений.

Симптомы устаревшего или проблемного кэша:

Один сервер не может разрешить домен, в то время как другие машины в сети успешно это делают.
Запрос через публичный DNS-сервер работает, а через локальный резолвер - нет. Проверьте с помощью dig @8.8.8.8 example.com и dig example.com.
Недавно измененная DNS-запись, например, A-запись для веб-сервера, не обновилась на локальном сервере.
Ошибки типа «NXDOMAIN» для заведомо существующих и доступных доменов.

Для быстрой диагностики используйте сравнение результатов команд nslookup или dig с указанием локального и внешнего резолвера. Разница в ответах указывает на проблему с локальным кэшем.

Определяем, какой демон DNS-кэширования работает в вашей системе

Перед применением команд очистки необходимо точно определить активный демон кэширования. Используйте этот пошаговый алгоритм.

1. Проверка статуса служб с помощью systemctl:

systemctl status systemd-resolved
systemctl status dnsmasq
systemctl status named

Активная служба будет показана как «running». В Ubuntu 22.04 LTS, 24.04 LTS и Debian 12+ по умолчанию используется systemd-resolved. В CentOS/RHEL 8 и 9 он также может быть установлен, но часто встречается dnsmasq из репозитория EPEL. BIND (named) обычно используется как полноценный кэширующий резолвер в инфраструктуре, а не как клиентский демон.

2. Анализ процессов:

ps aux | grep -E '(resolved|dnsmasq|named)'

3. Проверка слушающих портов на 53 (стандартный DNS порт):

ss -tulpn | grep :53

Если служба слушает на 127.0.0.53, это systemd-resolved. Если на 127.0.0.1, вероятно, dnsmasq или другой локальный резолвер.

4. Анализ файла /etc/resolv.conf. Направление на nameserver 127.0.0.53 указывает на systemd-resolved. Направление на nameserver 127.0.0.1 часто указывает на dnsmasq.

Очистка кэша systemd-resolved (стандарт для современных Ubuntu/Debian)

Для систем, использующих systemd-resolved как локальный резолвер, команда принудительного сброса кэша:

sudo systemd-resolve --flush-caches

Альтернативная команда с использованием resolvectl:

sudo resolvectl flush-caches

Оба метода эффективны и не требуют перезапуска службы. Перезапуск (sudo systemctl restart systemd-resolved) также очищает кэш, но это более тяжелая операция, временно прерывающая разрешение имен.

Для проверки успешности сброса используйте команду просмотра статистики:

sudo systemd-resolve --statistics

После очистки счетчик кэшированных записей будет равен нулю. Старый метод с перезапуском службы nscd (Name Service Cache Daemon) устарел и не актуален для современных систем с systemd-resolved.

Интеграция в скрипты и автоматизация

Для автоматизации в CI/CD pipelines или скриптах мониторинга используйте компактный однострочник:

systemd-resolve --flush-caches && echo "[$(date)] DNS cache flushed" >> /var/log/dns_flush.log

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

Сброс кэша dnsmasq (легковесный кэширующий резолвер)

Dnsmasq - популярный легковесный резолвер, часто используемый в небольших сетях и на виртуальных машинах. Основной метод очистки кэша - отправка сигнала SIGHUP процессу.

sudo killall -HUP dnsmasq

Или с использованием systemctl:

sudo systemctl reload dnsmasq

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

Если в конфигурации dnsmasq (/etc/dnsmasq.conf) включена опция --enable-dbus или управление через сокет, можно использовать подключение к порту:

echo "flush" | sudo nc localhost 53

Для проверки успешности очистки наблюдайте за логами службы в реальном времени:

journalctl -u dnsmasq -f

После отправки сигнала или команды flush в логах появится соответствующее сообщение. Эти инструкции работают для dnsmasq, установленного из стандартных репозиториев Debian/Ubuntu или из EPEL в CentOS/RHEL 7 и 8.

Очистка кэша BIND (named) с помощью rndc flush

BIND (named) - мощный DNS-сервер, часто используемый как кэширующий резолвер в корпоративных сетях. Основной инструмент управления - rndc (Remote Name Daemon Control). Команда очистки кэша:

sudo rndc flush

Для очистки кэша конкретного view (если настроены):

sudo rndc flush localhost
sudo rndc flush <view-name>

Проверка успешности выполняется командой просмотра статистики:

sudo rndc stats

В выводе обратите внимание на счетчик «cache size». После выполнения flush он должен уменьшиться до нуля или базового уровня.

Критически важный момент - корректная конфигурация аутентификации между named и rndc. Требуется наличие и правильная настройка файлов rndc.key и соответствующих секций в named.conf. Частая ошибка «connection refused» возникает при отсутствии этой конфигурации или при остановленной службе named. Альтернативный, но не рекомендуемый для production-серверов метод - полный перезапуск службы: sudo systemctl restart named. Это очищает кэш, но вызывает кратковременный перерыв в обслуживании DNS-запросов.

Настройка доступа rndc для автоматизации

Для безопасной интеграции команды rndc flush в скрипты необходимо настроить аутентификацию.

1. Генерация ключа с помощью rndc-confgen. Команда создает ключ и пример конфигурации для named.conf и rndc.conf.

2. Добавление полученной секции контроля в файл конфигурации BIND (/etc/named.conf или /etc/bind/named.conf).

3. Создание файла /etc/rndc.conf с тем же ключом и указанием адреса сервера.

После настройки команда rndc flush будет выполняться без ошибок аутентификации. Пример скрипта для автоматического сброса кэша после обновления зоны:

#!/bin/bash
# Скрипт очистки кэша BIND после импорта новых зон
rndc flush
if [ $? -eq 0 ]; then
    logger "BIND DNS cache flushed successfully"
else
    logger "ERROR: Failed to flush BIND DNS cache"
fi

Ключ rndc должен храниться с ограниченными правами доступа (например, 600) для предотвращения несанкционированного использования.

Проверка успешности сброса и устранение частых ошибок

После выполнения команд очистки необходимо убедиться в их эффективности.

Прямой метод - запрос проблемного домена до и после операции с помощью dig. Обратите внимание на поле «Query time». Первый запрос после flush обычно выполняется медленнее (десятки или сотни миллисекунд), поскольку резолвер обращается к upstream-серверам. Последующие запросы будут быстреми благодаря новому кэшу.

Просмотр логов демона предоставляет техническое подтверждение:

journalctl -u systemd-resolved -n 20
journalctl -u dnsmasq -n 20
journalctl -u named -n 20

В логах могут появиться сообщения о очистке кэша или перезагрузке.

Распространенные ошибки и их решения:

«command not found»: необходимый пакет не установлен. Для systemd-resolved он часть базовой системы в Ubuntu/Debian. Для dnsmasq установите пакет dnsmasq. Для BIND установите пакет bind9 (Debian/Ubuntu) или bind (CentOS/RHEL).
«Connection refused» для rndc: проблема с настройкой аутентификации или служба named не запущена. Проверьте конфигурацию rndc.key и статус службы.
Отсутствие прав sudo: выполнение команд требует административных прав.

Если сброс кэша на сервере не устранил проблему, проверьте другие уровни кэширования:

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

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

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

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

Правильная настройка и обслуживание DNS-кэша - часть общей безопасности инфраструктуры. Для комплексного подхода к защите Linux-серверов используйте практическое руководство по hardening и аудиту, актуальное в 2026 году.

Если вы работаете с множеством моделей искусственного интеллекта и нуждаетесь в едином интерфейсе для управления API-ключами и бюджетом, рассмотрите сервис AiTunnel. Он предоставляет доступ к более чем 200 моделям, включая GPT, Gemini и Claude, без необходимости использования VPN и с оплатой в рублях.