Как очистить локальный DNS-кеш в CentOS

Я ищу способ очистить локальный кеш DNS на CentOS 6.

Система не работает ни с одним DNS-сервером, ни с чем-либо, и я хочу, чтобы каждый DNS-запрос отправлялся на настроенный сервер имен, даже для дублированных.

Большая часть того, что я нашел в Интернете, говорит мне делать service nscd restart, перезагружать или делать nscd -i hosts. Тем не менее, похоже, что никто не очищает кэш.

Поэтому мне интересно, есть ли у кого-нибудь идея о том, как я могу это сделать. В ядре есть какой-то переключатель, который мне нужно перевернуть? Любой способ обойти это тоже хорошо.

— зет
источник

Что вы делаете, чтобы проверить, очищен ли кеш или нет?

— Джон

хорошо, это немного сложно, у меня в системе есть программа, которая прослушивает порт 53 и пересылает запросы DNS определенным образом, а также прокси-сервер http, использующий localhost в качестве «DNS-сервера»; по первому запросу (скажем wget -e 'http_proxy=localhost:3128' xxx.com) я вижу, что запрос перенаправляется правильно, но все последующие - нет. Если я подожду достаточно долго (срок действия кэша истечет), он снова заработает.

— Zee

А также я настроил прокси (squid) так, чтобы он не кэшировал никаких объектов, поэтому я предполагаю, что система все еще как-то

— кэширует

nscd -i hosts -> работает каждый раз. Я перезагружал nscd 3 раза подряд, и он не хотел очищать кеш.

— Дани

NSCD, кажется, не вещь в CentOS 7 минимальной. Я знаю, что в этом вопросе упоминается CentOS 6, но в целом название называется CentOS. Что такое CentOS 7?

— duct_tape_coder

Ответы:

Это не ваш локальный ящик, который кэширует DNS-запросы, но это DNS-распознаватель, который вы используете в своем, /etc/resolv.confкто кэширует.

Чтобы предотвратить получение этих кэшированных запросов, ответьте:

Сменить распознаватель.

$ dig @<resolve-ip> www.google.com
Очистите кэш DNS на распознавателе, если вы можете получить доступ к DNS-серверу.

$ sudo /etc/init.d/bind restart

— pradeepchhetri
источник

Хм, но я установил dns_nameservers 127.0.0.1в конфигурационном файле прокси, и слушатель только перенаправляет запросы на предварительно сконфигурированный сервер имен, не должно ли быть так, что с resolv.conf даже не консультируются?

— Zee

"bash: /etc/init.d/bind: нет такого файла или каталога", и метод OP получает "Не удалось перезапустить nscd.service: Не удалось загрузить модуль nscd.service: такого файла или каталога нет". Я думаю, что они были перемещены / изменены. Почему они не могут просто оставить вещи, которые работают, или, по крайней мере, поддерживать псевдонимы? Достаточно плохо, чтобы стать специалистом по ОС, чтобы просто использовать Linux-бокс. Хуже, когда вам приходится заново изучать ОС с каждым выпуском.

— JosephK

Даже после обновления или очистки кэша DNS на клиентском компьютере, если он не работает, посмотрите, что ваш сервер или клиентский компьютер привязан к любому серверу NIS, если да, тогда измените «hosts: files nis dns» на «hosts: files dns nis» запись в файле /etc/nsswitch.conf, а также вам нужно изменить IP-адрес в списке хостов главного сервера NIS.

— Вилас Аддагатла
источник

Это привело к моему решению. Внутри / etc / hosts был ранее статически настроенный старый IP-адрес. Что-то, что я сделал некоторое время назад. Удаление этой строки (или замена на новый ip) решило проблему и позволило мне пропинговать мой компьютер, используя его имя хоста.

— Пол

Я почти уверен, что это не система, кэширующая ответ - эта часть (системное кэширование) обрабатывается только nscdдемоном. Перезапуск (или полная остановка) этого демона сбрасывает или исключает кэширование ОС ответов на запросы службы имен.

Я предложу две возможности, хотя пользовательский слушатель, который вы настроили на порту 53, значительно запутывает воду:

A) Ваша система выдает запросы в восходящем направлении, но непосредственный обратный преобразователь имен кэширует ответ на основе своих настроек или TTL записи.
Б) Ваш пользовательский слушатель кэширует ответы внутри и просто передает этот ответ обратно в систему, когда его снова спрашивают до истечения времени кеширования.

— Джон
источник

Спасибо за ввод, но слушатель ничего не делает, кроме пересылки запроса и ответа, это всего лишь 200 строк кода. Так не должно быть второго случая; также слушатель распечатывает все, что получает, так что я уверен, что он действительно ничего не получает: |

— Zee