Como liberar o cache DNS local no CentOS

Estou procurando uma maneira de liberar o cache DNS local em um CentOS 6.

O sistema não está executando nenhum servidor DNS nem nada, e desejo permitir que todas as consultas DNS sejam enviadas para o servidor de nomes configurado, mesmo para os duplicados.

A maior parte do que encontrei on-line me diz para fazer service nscd restart, recarregar ou fazer nscd -i hosts. No entanto, nenhum parece liberar o cache.

Então, eu estou querendo saber se alguém tem uma idéia de como eu poderia fazer isso. Existe algum tipo de opção no kernel que eu preciso ativar? Qualquer tipo de trabalho é bom também.

— zee
fonte

O que você está fazendo para verificar se o cache foi liberado ou não?

— João

ok, é um pouco complicado, eu tenho um programa no meu sistema escutando na porta 53 e encaminhar as consultas DNS de certa maneira, e também um proxy http usando localhost como 'servidor DNS'; na primeira consulta (digamos wget -e 'http_proxy=localhost:3128' xxx.com), posso ver que a consulta está sendo encaminhada corretamente, mas todas as subsequentes não. Se eu esperar o tempo suficiente (o cache expira), ele funcionará novamente.

— zee

E também eu tenho configurado o proxy (squid) para não armazenar em cache qualquer objeto, então eu suponho que é o sistema ainda cache a resposta de alguma forma

— zee

nscd -i hosts -> funciona sempre. Reiniciei o nscd 3 vezes seguidas e ele não queria limpar o cache.

— Danie

O nscd não parece ser algo mínimo no CentOS 7. Eu sei que a pergunta chama CentOS 6, mas o título chama CentOS em geral. Qual é o caminho do CentOS 7?

— duct_tape_coder 22/02

Respostas:

Não é sua caixa local que está armazenando em cache as solicitações de DNS, mas é o resolvedor de DNS que você está usando em /etc/resolv.confquem está armazenando em cache.

Para impedir que essas consultas em cache respondam:

Mude o resolvedor.

$ dig @<resolve-ip> www.google.com
Lave o cache DNS no resolvedor, se você puder acessar o servidor DNS.

$ sudo /etc/init.d/bind restart

— pradeepchhetri
fonte

Hmm, mas eu configurei dns_nameservers 127.0.0.1no arquivo de configuração do proxy, e o ouvinte encaminha apenas as consultas para o servidor de nomes pré-configurado, não deve ser o caso de que resolv.conf nem seja consultado?

— zee

"bash: /etc/init.d/bind: esse arquivo ou diretório não existe" E o método do OP é "Falha ao reiniciar o nscd.service: Falha ao carregar a unidade nscd.service: esse arquivo ou diretório não existe." Eu acho que estes foram movidos / alterados. Por que eles não podem simplesmente deixar as coisas que funcionam, ou pelo menos manter aliases? Já é ruim o suficiente ter que se tornar um especialista em SO para simplesmente usar uma caixa Linux. Pior quando você precisa reaprender o sistema operacional a cada versão.

— JosephK

Mesmo após a atualização ou liberação do cache DNS na máquina cliente, se ela não funcionar, verifique se o servidor ou a máquina cliente está vinculado a qualquer servidor NIS. Se sim, altere "hosts: files nis dns" para "hosts: files dns nis" entrada no arquivo /etc/nsswitch.conf e também é necessário alterar o endereço IP na lista de hosts do servidor principal do NIS.

— Vilas Addagatla
fonte

Isso levou à minha solução. Dentro de / etc / hosts estava o endereço IP antigo configurado estaticamente anteriormente. Algo que eu tinha feito há um tempo. A exclusão dessa linha (ou a substituição pelo novo ip) resolveu o problema e me permitiu executar ping na minha máquina usando o nome do host.

— Paul

Estou quase certo de que não é o sistema que está armazenando a resposta em cache - essa parte (armazenamento em cache do sistema) é tratada apenas pelo nscddaemon. Reiniciar (ou parar completamente) esse daemon redefine ou elimina o cache do SO das respostas de solicitação de serviço de nome.

Oferecerei duas possibilidades, embora o ouvinte personalizado que você configurou na porta 53 atrapalhe consideravelmente as águas:

A) Seu sistema está emitindo consultas a montante, mas o resolvedor de nomes a montante imediato está armazenando em cache a resposta com base nas configurações ou no TTL do registro.
B) O seu ouvinte personalizado está armazenando em cache as respostas internamente e apenas entregando essa resposta de volta ao sistema quando for solicitada novamente antes que o tempo do cache expire.

— John
fonte

Obrigado pela entrada, mas o ouvinte não faz nada além de encaminhar a consulta e a resposta, são apenas 200 linhas de código depois de tudo. Portanto, não deveria ser o segundo caso; Além disso, o ouvinte está imprimindo tudo o que recebe, por isso tenho certeza de que realmente não está recebendo nada: |

— zee