O nslookup funciona com /etc/resolv.conf, ping e ssh não

12

Em nossa rede universitária local, tenho (obtido pelo DHCP) a seguinte configuração no /etc/resolv.conf:

search a.domain.com b.domain.com domain.com
nameserver x.x.x.x
nameserver y.y.y.y

As configurações também são iguais nas Preferências do sistema. O seguinte problema ocorre:

nslookup server

funciona e está usando um dos servidores de nomes para solicitar corretamente server.a.domain.com. Se eu tentar executar ping, no entanto,

ping server

falha com host inacessível.

ping server.a.domain.com

trabalho. A adição manual de servidor com o endereço IP obtido pelo nslookup em / etc / hosts também faz com que o ping funcione, mas essa "solução" contorna os servidores de nomes e, portanto, não é o ideal (e eu também teria que adicionar outras 20 entradas). Alguma ideia do que esta causando isso? Por que o ping não usa os resultados do nslookup / the searchdomains?

ssh server

também falha, que é o verdadeiro problema / inconveniente.

Eu já adicionei o AlwaysUseSearchDomains ao mDNSResponder, mas essa correção só ajuda no problema ao usar o server.foo.

Estou usando o OS X Lion 10.7.3.

lion macos network

— tholu
fonte

Pacotes de ping podem ser bloqueados pelo equipamento de rede. A mesma coisa com os pacotes ssh - eles podem não querer que você faça o que faz.

— Thorbjørn Ravn Andersen

Veja a solução abaixo, esse não foi o problema.

— tholu

"Host inacessível" significa um problema de conectividade de rede (ou ICMP bloqueado), não DNS problema de resolução

— Daniel Serodio

2

Bem, você leu os comentários no topo /etc/resolv.conf?

# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.

A solução correta é adicionar os domínios de pesquisa por meio do painel Rede nas Preferências do sistema, conforme descrito aqui .

— Old Pro
fonte

Eu fiz. Os domínios de pesquisa são inseridos automaticamente no painel Rede em Preferências do sistema por configuração de DHCP (e, portanto, estão acinzentados e não são alteráveis). Os mesmos valores / configurações exatos são / são encontrados em /etc/resolv.conf.

— tholu

Eu não sei o que te dizer, então. Recebo minhas configurações de Ethernet e WiFi via DHCP e posso alterar meus domínios de pesquisa no painel Preferências do sistema.

— Old Pro

Os domínios de pesquisa estão corretos nas Preferências do Sistema e /etc/resolv.conf - o problema é que ping e ssh não estão usando. Se eles usassem a saída do nslookup, tudo funcionaria bem, mas de alguma forma, eles não. Eles pesquisam / etc / hosts, no entanto.

— tholu

Adicionei manualmente os domínios de pesquisa (embora eles estivessem acinzentados) um por um através das Preferências do Sistema e agora ele funciona. Obrigado!

— tholu

4

Eu tive o mesmo problema. A solução que usei foi criar um diretório / etc / resolver. Dentro desse diretório, crie um arquivo nomeado para cada domínio que você deseja resolver. Dentro de cada arquivo deve haver duas linhas

nameserver 10.0.100.2
domain  home.cainmanor.com

O arquivo acima seria nomeado / etc / resolv / home. Pode precisar ser nomeado como home.cainmanor.com, mas não posso testá-lo agora.

Boa sorte!

— Greg Cain
fonte

Eu trabalhei definindo os domínios de pesquisa por meio das Preferências do Sistema, um por um, substituindo as configurações de DHCP que o OS X não conseguiu analisar corretamente, obviamente. Não pude tentar sua solução, mas obrigado!

— Tholu 9/05/12

Essa abordagem funciona bem quando o cliente VPN corporativo faz a coisa errada com relação às preferências transitórias do sistema.

— Peter

1

Acredito que o problema esteja na configuração dos domínios de pesquisa: o ping / ssh está tentando usar o gethostbyname2()que falha porque o nome não está mais sendo executado (pelo menos no Lion) e, /etc/resolv.confcom os domínios de pesquisa configurados, é ignorado. /etc/hostsé o último recurso gethostbyname2()e, portanto, o ssh trabalha novamente com as entradas apropriadas no /etc/hosts. Deve ser corrigido pela Apple imho.

Adicionando manualmente os domínios de pesquisa, um por um, foi corrigido, veja a solução acima.

— tholu
fonte

Quando adiciono um domínio de pesquisa à minha conexão WiFi (que é configurada via DNS) no OS 10.7.3, no painel Preferências do sistema -> Rede, ele é usado por ping e ssh exatamente como eu esperava. Não toco em /etc/resolv.conf ou / etc / hosts manualmente / diretamente, mas as alterações nas Preferências do Sistema são refletidas no /etc/resolv.conf automaticamente. O OS X faz muitas coisas de maneira diferente dos outros sistemas Unix e esse é um deles.

— Old Pro

1

Obrigado, isso deu certo, adicionando os domínios de pesquisa manualmente, um por um. Veja meu comentário sobre a solução sugerida acima.

— Tholu 9/05/12

Adicionar domínios de pesquisa não resolveu os problemas ... Mais alguém conseguiu outra solução?

Como você os adicionou?

— tholu

1

Eu sempre recebo esse problema quando meu Mac Book Pro (OS X versão 10.10.1) está em sono. Acorde e não posso usar o ssh usando o nome do host das máquinas na minha rede (e o ping também não funciona). O nslookup funciona bem. Não é possível ver nenhuma mensagem relevante em / var / log. Apenas deixe alguns minutos e pronto, ele funciona novamente ...

— Ian Ellis
fonte

0

Eu respondi isso em outro lugar, porque era uma solução simples para mim e não consegui encontrar a resposta que funcionava para mim em nenhum outro lugar.

Após reiniciar o mDNSResolver dezenas de vezes, conforme recomendado em outros threads:

sudo killall -HUP mDNSResponder

Finalmente tentei outra coisa. Desativei o Wi-Fi e excluí todas as minhas redes preferidas. Restabeleci a conexão Wi-Fi e tudo funcionou bem:

Menu Apple -> Preferências do sistema -> Wi-Fi (à esquerda)
"Desligue o Wi-Fi" e selecione "Avançado"
Exclua a conexão Wi-Fi com a qual está tendo problemas (ou todas, se desejar). Faça isso selecionando a rede Wi-Fi que deseja excluir e pressionando "-"
Clique em 'Aplicar' e 'OK'
Ligue o Wi-Fi novamente.
Selecione sua rede Wi-Fi e efetue login novamente.

Isto é o que finalmente funcionou para mim. Provavelmente deveria ter sido a primeira coisa que tentei, mas sou do Linux e olho primeiro para as correções de console.

— Joel Griffiths
fonte