Você encontrou o excessivamente zeloso cache DNS do OS X. Da próxima vez que você ver isso, você pode liberá-lo:
# sudo dscacheutil -flushcache
Isso deve corrigir o SSH, etc.
Eu estou tentando SSH para um laptop Eee PC rodando Debian em uma rede onde hostnames são automaticamente registrados com DNS através do servidor DHCP. O laptop Eee PC tinha ficado sem energia e foi dormir e agora, quando é inicializado novamente, o Mac não consegue vê-lo, exceto pelo programa nslookup .
gaz:~ jeff$ ssh epc
ssh: Could not resolve hostname epc: nodename nor servname provided, or not known
gaz:~ jeff$ nslookup epc
Server: 192.168.2.20
Address: 192.168.2.20#53
Name: epc.osnetwork
Address: 192.168.2.139
gaz:~ jeff$ ssh epc.osnetwork
ssh: Could not resolve hostname epc.osnetwork: nodename nor servname provided, or not known
Agora, ssh epc é como eu normalmente acesso o Eee PC, mas por alguma razão eu acho que alguma parte do OS X está armazenando em cache uma não resposta apesar da máquina estar on-line, mas eu não sei como. Eu não tenho certeza de como resolver isso com qualquer grau de certeza, eu suspeito que uma reinicialização vai fazer isso, mas por falta de uma solução sem tempo de inatividade eu só tenho usado o endereço IP (que ainda pode ser obtido no mac com nslookup epc , que é a parte mais desconcertante).
Se eu usar o SSH em outro Mac que não tentou entrar em contato com o Eee PC enquanto ele estava inoperante, o Mac pode usá-lo sem problemas, mas quando volto para o Mac original ele ainda não consegue acessar o hostname .
Outras máquinas que não são da Apple na rede não parecem sofrer desse comportamento.
Alguém sabe por que isso está acontecendo ou tem ideias sobre como corrigir esse comportamento?
[EDIT] Descobri que voltar meia hora depois para tentar novamente funcionou, mas ainda gostaria de saber por que isso está acontecendo e como corrigi-lo.
O comando em Mavericks e Yosemite (começando em 10.4) é:
sudo killall -HUP mDNSResponder
Fonte: link
Tags ssh networking hostname macos