A pesquisa de nome DNS (era SSH) não está funcionando após a atualização do Snow Leopard


14

Acho que isso começou com a atualização do Snow Leopard. Limpou o diretório .ssh, ainda com o problema.

~: uname -a
Darwin california-example-com.local 10.0.0 Darwin Kernel versão 10.0.0: sexta-feira, 31 de julho às 22:47:34 PDT 2009; raiz: xnu-1456.1.25 ~ 1 / RELEASE_I386 i386

~: ssh -V
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 de março de 2009

~: ls -l ~ / .ssh

~: nslookup nevada
Servidor: 10.94.62.3
Endereço: 10.94.62.3 # 53

Nome: nevada.example.com
Endereço: 10.94.62.3

~: ssh nevada
ssh: Não foi possível resolver o nome do host nevada: nome do nó nem nome do serviço fornecido ou desconhecido

Você pode enviar ssh para (a) nevada.example.com e (b) 10.94.62.3?
Sven

2
Você pode executar ping nevada? O que mostra "ssh -v nevada"?
markdrayton

Pergunta estranha; você usa Split DNS e / ou pode executar ping nevada?
Chealion 13/09/09

Obrigado pelos acompanhamentos ... respostas: ssh nevada.example.com = não ssh 10.94.62.3 = sim (e tive que confirmar a chave do host porque eu limpei os hosts conhecidos) ping nevada = problema de resolução de nome telnet nevada (tho ele não roda telnetd) = problema de resolução de nome Split DNS = não intencionalmente, não sei o que é :-) No painel de configurações de rede do OS X, tenho 10.94.62.3 como servidor DNS listado antes dos dois fornecidos pelo meu provedor de serviços de Internet e exemplo.com na lista de domínios de pesquisa. Outros sistemas na minha rede podem usar o DNS normalmente para ssh para nevada (e outros).
22613 Peter Cardona

desculpe a falta de quebras de linha no comentário acima ...
Peter Cardona

Respostas:


16

Encontrei exatamente o mesmo problema e achei extremamente útil um tópico sobre um Mac mini com problemas de DNS nas discussões da Apple.

O cerne da questão: o mDNSResponder parece ocasionalmente alterar a ordem dos servidores DNS consultados e, portanto, se consultar os servidores DNS do seu ISP primeiro, não obterá um registro adequado (ou, se você estiver usando DNS dividido, obterá seu IP público).

A melhor solução para isso é garantir (como você fez) que apenas os servidores DNS necessários estejam listados em suas configurações de DNS. Isso pode exigir a remoção dos servidores DNS do ISP do seu DHCP (como eu também fiz - todas as solicitações são encaminhadas pelo servidor DNS local).

A razão pela qual os utilitários gostam dige nslookupterão sucesso normalmente é que eles estão usando o BIND e /etc/resolv.confdiretamente ao contrário do resto do sistema operacional.

Para referência no Snow Leopard, o cache DNS agora é armazenado pelo mDNSResponder e, para limpá-lo, você precisa reiniciar o processo usando sudo killall -HUP mDNSResponder. Você pode obter mais informações (registro, despejo de estado interno etc.) usando sinalizadores diferentes no killallcomando.

"sudo killall -USR1 mDNSResponder" to enable operation logging.
"sudo killall -USR2 mDNSResponder" to enable packet logging.
"sudo killall -HUP mDNSResponder" to clear the DNS cache.
"sudo killall -INFO mDNSResponder" to dump mDNSRepsonder's internal state.

Fonte: Snoop Dogg no mesmo tópico.


Obrigado, o Google me levou aqui, isso corrigiu. "arp" reportou o IP errado, dig reportou o "ip" correto. Nenhuma quantidade de DNS corrigiu antes de eu tentar isso. Percebo que tive que executar o dscacheutil -flushcache também. Eu também apontaria que os roteadores locais podem se comportar de maneira estranha e os ISPs também não jogam limpo em termos de TTL às vezes.
Aitch

9

tivemos problemas como este:

host example.com     <<< WORKED
ping example.com     <<< FAILED

Resolvido com algo como isto:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Os aplicativos no Mac OS X não usam o mesmo mecanismo para o DNS que "host / dig / nslookup".

O uso de "host / dig / nslookup" foi útil para determinar que isso não era um problema de rede. Foi um problema com o sistema local resolvido com os comandos acima.


uau que funcionou !!! Eu tenho procurado por toda parte uma solução !!!! eu estava prestes a formatar e restaurar meu laptop, você me salvou uma tonelada de tempo! obrigado! desculpe, mas eu não poderia upvote :-( Nota: My DNS parou de funcionar depois que eu corria o Util ônix, não sei por que eu era capaz de usar dig / nslookup mas nada mais..

2

Eu experimentei o mesmo problema ... E ao reiniciar o mDNSResponder parece "funcionar", reiniciá-lo algumas vezes a cada hora é uma merda.

Então, por enquanto, "resolvi" o problema executando o dnsmasq localmente. Fazer isso:

  • Compile o dnsmasq (faça o download do tgz e makeou brew install dnsmasq)
  • Coloque isso em um dnsmasq.confarquivo:
resolv-file = resolv.conf
usuário = ninguém
group = ninguém
interface = lo0
tamanho do cache = 1024
  • Coloque isso em um resolv.confarquivo que esteja no mesmo diretório que o dnsmasq.confarquivo (nb: not /etc/resolv.conf ):
nameserver 8.8.8.8
nameserver 4.2.2.1
nameserver 4.2.2.2
  • Corra dnsmasqcom sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. A saída deve ser algo como:
...
dnsmasq: lendo resolv.conf
dnsmasq: using nameserver 4.2.2.1 # 53
dnsmasq: usando o servidor de nomes 4.2.2.2 # 53
dnsmasq: usando o servidor de nomes 8.8.8.8 # 53
dnsmasq: read / etc / hosts - 6 endereços
  • Abra Preferências de rede e verifique se esse 127.0.0.1é o único servidor DNS (preferências de rede -> avançadas -> DNS -> adicione 127.0.0.1)

As coisas devem começar a funcionar bem novamente.

Depois que as coisas estiverem funcionando, você poderá executar dnsmasqsem as opções --no-daemone --log-queries, para que seja iniciado em segundo plano e não seja necessário manter uma janela do Terminal aberta.


1

Percebi que tinha 10.94.62.3 na lista de servidores DNS (painel de prefs da rede), seguido por 2 do meu ISP. Eu removi os outros 2, forçando todas as pesquisas de nome até 10.94.62.3 para este local e agora posso resolver nomes na minha rede e fora dela.

Não faço ideia por que isso funcionou.


1

Acho que temos um problema semelhante, como descrevi aqui: /apple/50457/nslookup-works-ping-and-ssh-dont-os-x-lion-10-7-3

Acredito que o problema esteja na configuração dos domínios de pesquisa: o ping / ssh 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.


0

Você já experimentou nevada-example-com.local?


Não tinha tentado isso, mas conseguiu o mesmo problema de resolução. Começando a parecer que NADA (ssh, telnet, ping, http) resolve através do servidor que o nslookup está usando como padrão. Como poderia ser? Talvez um conflito entre as configurações de nível do OS X e algum arquivo / etc / seja qual for o assunto da implementação do BSD subjacente?
22613 Peter Cardona

Não, o OS X não usa níveis init - nem mesmo o sistema sys BSD.
Jeremy L

0
dscacheutil -flushcache

Esse comando atualiza seu cache DNS.

10.94.62.3 é um servidor DNS em que você confia? Se sim, por que existe apenas um? Você deve ter pelo menos 2 servidores DNS para referência para fins de failover. Se aquele cair, você é um pato sentado.


0

As pesquisas de pedidos do DNS parecem funcionar de maneira diferente no Snow Leopard. Se você não conseguir pesquisar um domínio, verifique se há algum servidor DNS inválido listado nas suas preferências de rede. Se você estiver usando uma configuração DHCP padrão, não deverá ter nenhum servidor DNS listado. Antes da atualização, eu tinha um servidor DNS antigo listado e não afetava nada. Uma vez que eu atualizei, perdi totalmente o DNS.

Abra Preferências de rede> Escolha Aeroporto> Avançado. Selecione a guia DNS e remova todos os servidores DNS inválidos.


0

Você já olhou para o Console? (Aplicativos -> Utilitários -> Console) Você pode descobrir que o mDNSResponder está aparecendo em: Informações de diagnóstico e uso -> Relatórios de diagnóstico do sistema

Se estiver travando devido a outro programa que está carregando módulos (como Little Snitch ou Hands Off), você poderá vê-lo lá.


-1

Eu tive o mesmo problema com o nslookup resolvendo minha caixa de janelas, mas o ping me deu um "host desconhecido". Eu tentei o que o Navdeep sugeriu e fui limpar os servidores de nomes na guia Preferências de rede-> Avançado-> DNS. Não me deixou subtraí-los, eles estavam acinzentados. Eu finalmente apertei o + e eles desapareceram. Cancelei a adição de um novo e apliquei as alterações, uma vez que nenhum servidor DNS estava aparecendo. Ping começou a trabalhar depois disso. O estranho é que meu roteador local / servidor DHCP foi o primeiro da lista e é o responsável por resolver a caixa do Windows. Deve ser algo estranho com a encomenda. O outro servidor de nomes listado é um trabalho NS e não seria capaz de resolver o host do Windows. OBRIGADO Navdeep!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.