Falha temporária na resolução de nomes

Continuo recebendo uma mensagem de erro sempre que faço qualquer coisa que exija uma pesquisa de DNS no meu servidor CentOS. Por exemplo:

[root @ 15557 etc] # wget http://www.whitehouse.gov/sites/default/files/rss_viewer/birth-certificate-long-form.pdf
--2011-05-03 20: 55: 35-- http://www.whitehouse.gov/sites/default/files/rss_viewer/birth-certificate-long-form.pdf
Resolvendo www.whitehouse.gov ... falhou: falha temporária na resolução de nomes.
wget: incapaz de resolver o endereço do host `www.whitehouse.gov '

Se eu reiniciar o servidor, esse problema desaparecerá por um curto período de tempo, mas sempre volta depois de uma hora. Se eu alterar os IPs do servidor de nomes listados em resolv.conf, o problema não será corrigido, mesmo que eu os substitua por um servidor de nomes comum como o do Google 8.8.8.8. Se eu liberar o cache dos hosts após a alteração resolve.conf, ele também não solucionará o problema. Após a reinicialização do servidor, o valor resolv.confé alterado novamente para os valores padrão (acho que por algum DHCP).

— whitelines222
fonte

Alguma perda de pacotes de saída no seu servidor? Eu acionava um farejador de pacotes e via como o tráfego DNS se parece quando isso acontece.

— EEAA

Você pode recomendar um farejador de pacotes? Eu não instalei esse software antes. Obrigado.

— Whitelines222

tcpdumpestá prontamente disponível na maioria das distros através de seu repositório de pacotes. Eu recomendo procurar no Google um tutorial sobre o tcpdump antes de começar. Além disso, você pode usar o tcpdump para capturar os pacotes e gravá-los em um arquivo de log. Em seguida, é possível abrir esse arquivo de log em uma ferramenta da GUI chamada Wireshark, que é um pouco mais amigável do que usar a CLI.

— EEAA

tcpdump -Ani <your_interface> -s0 domínio da porta (-w My.Log &)

— 3molo

Respostas:

Isso pode ser um problema causado pelo servidor DHCP, na verdade, por um servidor não autorizado ou outro servidor DHCP configurado incorretamente na sua rede.

Provavelmente , é isso que acontece: quando o servidor é inicializado, ele consegue obter os parâmetros precisos ( endereço IP, gateway, servidores DNS, etc. ) do servidor DHCP legítimo e, como resultado, você não terá problemas até a concessão renovação. Após um período de tempo relativamente curto ( depende da configuração do cliente e servidor DHCP), o cliente DHCP tentará renovar a concessão entrando em contato com o servidor DHCP legítimo (via transmissão unicast). Se, por algum motivo, falhar ou se o cliente dhcp, por algum motivo, não receber uma resposta do servidor DHCP legítimo, ele entrará no estado de religação e transmitirá uma solicitação para estender o tempo de concessão. Se o servidor desonesto / outro servidor DHCP configurado incorretamente conseguir responder primeiro, ele poderá enviar ao seu cliente parâmetros incorretos - por exemplo, um endereço de servidor DNS "errado" e, como resultado, você não conseguirá resolver nomes de host.

Se minha especulação estiver correta, a reinicialização do servidor nem sempre resolve o problema, pois pode haver momentos em que o servidor DHCP não autorizado responde primeiro e, como resultado, você enfrenta o problema mencionado.

De qualquer forma, tente configurar endereços IP estáticos, desabilitar o DHCP e configurar manualmente os servidores DNS. Além disso, você provavelmente deve verificar se há outros servidores DHCP em execução na sua rede, além do que você está usando.

— dkaragasidis
fonte

Como localizo se há um servidor DHCP não autorizado na minha rede? serverfault.com/questions/8526/...

— Elias Lynn

No meu caso, eu configuraria as regras fw para a interface errada. Portanto, a porta 53 não estava aberta e o servidor não pôde fazer uma requisição de DNS

— grahamrhay
fonte