Когда после миграции сервера или смены IP-адреса внутреннего ресурса часть клиентов в сети продолжает обращаться по старому адресу, проблема часто связана не с их локальным кэшем, а с DNS-прокси на сетевом оборудовании. Маршрутизаторы, L3 коммутаторы и межсетевые экраны кэшируют DNS-ответы для ускорения работы, и устаревшие записи в этом централизованном кэше блокируют доступ для всех пользователей сети. В этой статье вы найдете проверенные команды для принудительного сброса DNS-кэша на MikroTik RouterOS, маршрутизаторах с OpenWrt (включая TP-Link), а также общие процедуры для L3 коммутаторов и межсетевых экранов. Инструкции актуальны для 2026 года и помогут быстро устранить проблему без риска нарушения работы связанных служб, таких как DHCP.
Почему DNS-кэш на оборудовании становится проблемой и когда его нужно очищать
Сетевые устройства с функцией маршрутизации часто выступают в роли DNS-прокси для клиентов локальной сети. Вместо того чтобы каждый клиент отправлял запросы на внешние DNS-серверы, устройство перехватывает эти запросы, кэширует полученные ответы и возвращает их другим клиентам. Это снижает нагрузку на канал и ускоряет разрешение имен.
Как работает DNS-прокси и кэширование на маршрутизаторах и L3 устройствах
Механизм прост: первый клиент, запрашивающий, например, адрес example.com, заставляет устройство обратиться к внешнему DNS-серверу. Полученный IP-адрес сохраняется в локальном кэше оборудования на время, указанное в TTL (Time to Live) записи. Все последующие запросы к example.com из сети в течение этого TTL будут обслуживаться из кэша устройства, без внешних запросов.
Проблема возникает, когда IP-адрес ресурса меняется быстрее, чем истекает TTL старой записи в кэше. Клиенты начинают получать устаревший, неверный адрес. Ситуация усугубляется, если на том же устройстве работает DHCP-сервер, который может динамически регистрировать имена локальных хостов в своем DNS. После изменения IP-адреса такого хоста старая запись также застревает в кэше.
Типичные сценарии, требующие очистки кэша на оборудовании:
- Миграция физического или виртуального сервера на новый IP-адрес.
- Изменение внешнего IP-адреса веб-сайта или облачного сервиса.
- Смена DNS-серверов, указанных в настройках маршрутизатора.
- Недоступность внутреннего ресурса после перезапуска с новым IP от DHCP.
Ключевое отличие от клиентского кэша в том, что проблема становится централизованной: она затрагивает всех пользователей, чьи запросы проходят через это сетевое устройство.
Диагностика: убедитесь, что проблема именно в кэше сетевого оборудования
Прежде чем сбрасывать кэш, важно подтвердить диагноз. Это исключит ненужные действия и сэкономит время. Основной метод - сравнить результаты DNS-запросов изнутри проблемной сети и извне.
Подключитесь по SSH к любому клиентскому компьютеру в сети и выполните запрос к проблемному домену, используя внешний DNS-сервер напрямую, минуя кэш маршрутизатора. Затем выполните стандартный запрос.
# Запрос через внешний DNS (например, 8.8.8.8)
nslookup example.com 8.8.8.8
# Стандартный запрос (через DNS маршрутизатора)
nslookup example.comЕсли первый запрос возвращает новый, правильный IP-адрес, а второй - старый, проблема почти наверняка в кэше вашего сетевого оборудования.
Команды и инструменты для проверки DNS-кэша на разных устройствах
Некоторые платформы позволяют просмотреть содержимое кэша.
На MikroTik RouterOS (v7) можно получить статистику и количество записей:
/ip dns cache print statsНа устройствах с OpenWrt, где работает dnsmasq, можно проверить логи DNS-запросов или посмотреть активные аренды DHCP, которые также влияют на разрешение имен:
logread | grep dnsmasq
cat /tmp/dhcp.leasesЭти проверки дают уверенность в том, что очистка кэша на оборудовании - это необходимое действие.
Очистка DNS-кэша на MikroTik RouterOS
В MikroTik процесс очистки кэша DNS-прокси выполняется одной командой. Это можно сделать через терминал (CLI) или в графических интерфейсах WinBox/WebFig.
Команда flush и ее особенности в разных версиях RouterOS
Основная команда для очистки кэша DNS универсальна для современных версий RouterOS v6 и v7:
/ip dns cache flushПосле выполнения команды система не выводит подтверждающего сообщения. Кэш очищается мгновенно. В очень старых версиях (до v6) механизм DNS мог отличаться, но для актуальных на 2026 год версий эта команда работает без изменений.
Если в конфигурации MikroTik также используется статический или динамический DNS, и устройство выступает в роли DNS-сервера для локальных имен, может потребоваться очистить и эти записи. Динамические записи от DHCP обновляются автоматически, но при необходимости их можно удалить из раздела /ip dns static.
Что делать после очистки: проверка и мониторинг
Сразу после выполнения flush выполните на клиенте команду nslookup для проблемного домена. Первый запрос может задержаться на несколько сотен миллисекунд, так как маршрутизатору нужно заново выполнить рекурсивный запрос к внешнему DNS-серверу. Последующие запросы должны возвращать новый, корректный IP-адрес.
Для проверки можно снова использовать команду просмотра статистики кэша. Поле «entries» будет показывать близкое к нулю значение, которое начнет быстро увеличиваться по мере новых запросов от клиентов.
Если проблема с доступом к внутреннему ресурсу не устранена, ознакомьтесь с подробным руководством по очистке кэша DNS в различных рабочих сценариях, чтобы исключить другие причины.
Сброс DNS-кэша dnsmasq на маршрутизаторах с OpenWrt (TP-Link и другие)
На платформе OpenWrt, которая часто установлена на маршрутизаторах TP-Link и других брендов, роль DNS-прокси и DHCP-сервера обычно выполняет служба dnsmasq. Ее кэш и является целевым объектом для очистки.
Команда killall -HUP dnsmasq: почему она предпочтительнее полного restart
Самый безопасный и рекомендуемый метод - отправить процессу dnsmasq сигнал SIGHUP (HUP). Этот сигнал заставляет dnsmasq перечитать свою конфигурацию и очистить DNS-кэш, не затрагивая текущие аренды DHCP (dhcp leases). Клиенты не теряют выданные IP-адреса.
Подключитесь к маршрутизатору по SSH и выполните:
killall -HUP dnsmasqАльтернативой является перезапуск службы, но это более инвазивная операция:
service dnsmasq restartКоманда restart на короткое время полностью останавливает dnsmasq, что приводит к прекращению работы как DNS, так и DHCP. Новые клиенты не смогут получить IP-адрес, пока служба не запустится снова. Поэтому в рабочее время всегда предпочтительнее использовать killall -HUP dnsmasq.
Метод с сигналом HUP остается актуальным для всех современных версий OpenWrt и dnsmasq в 2026 году.
Процедуры для L3 коммутаторов и межсетевых экранов
На корпоративных L3 коммутаторах и межсетевых экранах функция DNS-кэширования может быть реализована по-разному: как часть DNS-прокси, сервиса фильтрации URL или встроенного резолвера для системных нужд.
Общий принцип тот же: необходимо найти команду или опцию для очистки кэша DNS. Часто эта команда входит в набор средств диагностики.
- Cisco IOS/XE: Используйте команду
clear ip dns cacheв привилегированном режиме EXEC. Это очистит кэш DNS на устройстве. - Межсетевые экраны (Palo Alto, Fortinet, Check Point): Очистка обычно выполняется через веб-интерфейс или CLI путем перезапуска соответствующей службы DNS-прокси/фильтрации. Например, может потребоваться отключить и снова включить функцию DNS Filtering или DNS Signaturing.
Ключевой момент: из-за большого разнообразия моделей и версий ПО всегда сверяйтесь с официальной документацией производителя для вашего конкретного устройства. Понимание общего механизма (поиск службы, ответственной за DNS) поможет быстрее найти нужный раздел в документации или интерфейсе.
Для комплексного анализа состояния DNS-инфраструктуры после вмешательства полезно руководство по мониторингу и анализу кэша DNS-серверов.
Безопасность и риски: как очистить кэш без нарушения работы сети
Очистка DNS-кэша - операция с низким риском, но она имеет краткосрочные последствия. Основной риск - временная задержка при разрешении имен для всех клиентов сети на период от нескольких сотен миллисекунд до 2-3 секунд на каждый новый домен. В это время устройство выполняет рекурсивные запросы к внешним серверам.
Если на оборудовании интегрированы DNS и DHCP (как в dnsmasq), важно выбрать метод, который не нарушит работу DHCP, как было показано на примере сигнала HUP.
План действий для минимального воздействия на пользователей
Следуйте этому алгоритму для безопасного выполнения процедуры:
- Диагностика: Выполните проверки из раздела 2, чтобы убедиться в проблеме с кэшем оборудования.
- Выбор метода: Определите наименее инвазивную команду (например,
killall -HUPвместоservice restart). - Время выполнения: Запланируйте операцию на период низкой сетевой активности. Если это критично, предупредите пользователей о возможных кратковременных задержках при открытии новых сайтов.
- Выполнение и немедленная проверка: Выполните команду очистки и сразу протестируйте доступ к проблемному ресурсу с одного-двух клиентов.
- Мониторинг: В течение 5-10 минут убедитесь, что проблема не вернулась и что разрешение имен работает стабильно.
Если после очистки кэша проблема не устранена, ищите причину в другом месте: локальном кэше клиентов (особенно Windows), конфигурации hosts-файлов, или проблемах на стороне внешнего DNS-провайдера. Инструменты для дальнейшей диагностики можно найти в статье об ошибках кэширования и их диагностике.
Альтернативы и профилактика: чтобы не очищать кэш в будущем
Постоянный ручной сброс кэша - не решение. Внедрение лучших практик снизит частоту возникновения проблем.
- Корректный TTL: Для внутренних DNS-записей, IP-адреса которых могут меняться, устанавливайте короткое время жизни (TTL) - например, 300 секунд (5 минут). Это ускорит естественное обновление кэша после изменений. Подробнее о настройках TTL читайте в руководстве по оптимизации DNS-кэширования.
- Динамический DNS (DDNS): Для критичных внутренних серверов используйте DDNS-клиенты, которые автоматически обновляют DNS-записи при изменении IP-адреса.
- Отказ от кэширования: В небольших сетях с низким объемом DNS-трафика и частыми изменениями можно рассмотреть отключение DNS-кэширования на маршрутизаторе. Клиенты будут обращаться к внешним DNS-серверам напрямую, что исключит проблему централизованного устаревшего кэша ценой небольшого увеличения задержки и внешнего трафика.
- Плановое обслуживание: Включите перезапуск DNS-служб на сетевом оборудовании в регулярные процедуры планового техобслуживания (maintenance window).
Для автоматизации других рутинных задач сетевой безопасности, таких как блокировка нежелательных IP-адресов, может пригодиться агрегатор API AiTunnel, который предоставляет единый доступ к множеству моделей ИИ для создания скриптов и анализа логов. А для комплексной защиты инфраструктуры от угроз извне используйте готовые стратегии из руководства по блокировке IP-адресов в 2026 году.