Почему универсальной команды нет
В Windows и macOS кэш имён один и управляется одной командой. В Linux всё иначе: за кэширование может отвечать systemd-resolved, служба nscd, локальный dnsmasq, unbound или вообще ничего. Многие минимальные установки не кэшируют DNS на уровне системы, и тогда очищать нечего: каждое обращение уходит на сервер.
Поэтому первая задача — определить, кто именно кэширует ответы у вас. Команда, которая сработает на одном дистрибутиве, на другом выдаст сообщение об отсутствии службы, и это не ошибка, а признак, что вы смотрите не туда.
Как определить, что кэширует ответы
Проверьте статус systemd-resolved командой systemctl status с именем службы. Если она активна, кэш есть. Посмотрите, куда ведёт файл /etc/resolv.conf: если в нём указан локальный адрес заглушки, запросы идут через локальный резолвер. Затем проверьте наличие nscd и dnsmasq в списке запущенных служб.
Иногда кэшированием занимается сам NetworkManager, запуская dnsmasq в своём составе. В этом случае имя процесса в списке будет содержать dnsmasq, хотя вы его не устанавливали. Если найдено несколько служб, очищать придётся каждую.
Сброс кэша в systemd-resolved
В системах, где работает systemd-resolved, используется команда resolvectl flush-caches. Она очищает записи и не требует перезапуска службы. Проверить состояние кэша можно командой resolvectl statistics: в выводе видны счётчики попаданий в кэш и текущий размер. После очистки размер должен уменьшиться до нуля или близко к нему.
Если такой команды нет, возможно, в системе более старая версия, где использовалась утилита с другим именем. Узнать нужный вариант можно в справке по установленной версии. Права администратора обычно нужны, поэтому команду запускают через sudo.
nscd, dnsmasq и другие резолверы
Если запущен nscd, сбросить его кэш имён хостов можно, вызвав его с ключом инвалидации таблицы hosts, либо просто перезапустив службу. Для dnsmasq достаточно перезапустить процесс: он держит кэш в памяти и при рестарте теряет его. Сигнал перезагрузки тоже очищает кэш, но перезапуск проще и надёжнее.
Для unbound существует собственная утилита управления, позволяющая сбросить отдельные записи или весь кэш. Для каждой службы команды свои, поэтому не пытайтесь угадывать: откройте справку установленного пакета.
Проверка и когда всё равно не помогает
Убедитесь, что сброс сработал: выполните dig для нужного имени и обратите внимание на время запроса. Первое обращение после очистки идёт к внешнему серверу и заметно дольше повторного. Значение «Query time» в выводе помогает отличить ответ из кэша от свежего.
Если проблема остаётся, проверьте файл hosts, кэш браузера и настройки прокси. Отдельно стоит учесть контейнеры и виртуальные машины: у них собственные настройки DNS и собственный кэш, не связанный с хост-системой. Сброс на хосте на контейнер не повлияет.
Ещё один нюанс касается серверов. На них кэширующий резолвер часто не ставят вовсе, чтобы не получать устаревшие ответы. Если вы работаете на сервере и видите неактуальный адрес, сначала проверьте, не настроен ли отдельный локальный кэш, и лишь потом ищите причину в удалённом DNS. Здесь помогает простой приём: временно указать запросу внешний сервер напрямую и посмотреть, изменится ли ответ. Если изменится, виноват локальный слой; если нет, запись действительно не обновилась там, где её хранят. Такой простой контрольный запрос экономит время и избавляет от лишних перезапусков служб на рабочей машине.
Пошаговый сценарий диагностики
Сформируйте порядок действий заранее. Сначала выясните, какая служба отвечает за разрешение имён, проверив её статус и содержимое resolv.conf. Затем очистите кэш этой службы соответствующей командой. После этого повторите запрос к проблемному имени и посмотрите время ответа. Если картина не изменилась, сравните ответ вашего сервера с внешним и проверьте файл hosts. Такой порядок избавляет от хаотичного перебора команд, которые в вашей системе просто не относятся к делу и создают ощущение, будто вы что-то делаете.