As pesquisas de DNS falham com, por exemplo, `ping`, mas funcionam com` host`

Estou usando o pfSense 2.0rc3 e o configurei como encaminhador de DNS e habilitei "Registrar concessões de DHCP no encaminhador de DNS" e o que entendo são todas as configurações apropriadas para obter o servidor DNS para pesquisas locais.

Funciona como esperado no Linux e, em particular, eu posso executar host abce ping abc(e outros aplicativos) e todos eles funcionam como esperado.

No entanto, no Mac OS X Lion 10.7, ele não funciona conforme o esperado. Em particular, apenas pesquisas com o hostcomando parecem funcionar, ou seja,

$ ping abc
ping: cannot resolve abc: Unknown host

$ host abc
abc.local has address 192.168.1.128

$ ping abc.local
ping: cannot resolve abc.local: Unknown host

$ host abc.local
abc.local has address 192.168.1.128

Por que a pesquisa de abctrabalho ao usar o hostcomando mas falha com ping(e outros aplicativos)?

Obrigado pela leitura.

Por que eles fizeram essa mudança, eu não sei, mas isso me deixou louco por um tempo.

Não sei por que as coisas funcionam para o host, mas não para o ping, mas acho que tem a ver com a natureza desses dois utilitários. O Ping é um utilitário de diagnóstico simples (embora muito útil) para a queda de pacotes no fio que deve ecoar para você. A funcionalidade de pesquisa de nome de host é apenas um efeito colateral do trabalho e entregue ao resolvedor recursivo do sistema (acredito - não verifiquei verificando bibliotecas vinculadas ou algo desse tipo). A principal tarefa do host é resolver o nome do DNS, para implementar seu próprio resolvedor recursivo.

O resolvedor recursivo da Apple é o mDNSResponder. Por alguma razão, a versão do mDNSResponder no Lion precisa da opção da linha de comando "-AlwaysAppendSearchDomains" para se comportar como no Snow Leopard (pelo menos).

Aqui está uma maneira rápida de corrigi-lo:

sudo sed -i .orig '/ProgramArguments/,/<\/array>/ {
s/\(<string>-launchd<\/string>\)/\1\
                <string>-AlwaysAppendSearchDomains<\/string>/
}' /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

(Deveria haver dois caracteres de tabulação no início da penúltima linha acima, mas não consegui descobrir como fazer esse pequeno editor inserir tabs, então adicionei 16 espaços. Eles devem funcionar, mas as tabs ajuste melhor o espaçamento do arquivo original.)

Isso adicionará o argumento "-AlwaysAppendSearchDomains" ao arquivo plist de inicialização do mDNSResponder (e salvará uma cópia de backup), mas como isso é controlado pelo launchd, é necessário informar ao sistema para reiniciar o mDNSResponder.

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

Agora, se você verificar seu processo mDNSResponder em execução, deverá vê-lo em execução com seu novo argumento:

ps auxww | grep mDNSResponder

(Adereços para http://www.makingitscale.com/2011/fix-for-broken-search-domain-resolution-in-osx-lion.html e http://kavassalis.com/2011/07/wtf-bug -in-os-x-10-7 / , onde encontrei minhas respostas para esse problema.)

Na página do manual host (1):

AVISO no Mac OS X

O comando host não usa a resolução de nome e endereço do host ou os mecanismos de roteamento de consulta DNS usados ​​por outros processos em execução no Mac OS X. Os resultados das consultas de nome ou endereço impressas pelo host podem diferir daqueles encontrados por outros processos que usam o Mac Mecanismos de resolução de nome e endereço nativos do OS X. Os resultados das consultas DNS também podem diferir das consultas que usam a biblioteca de roteamento DNS do Mac OS X.

Infelizmente, não há informações sobre como exatamente o comando host resolve os nomes de hosts. Esse comportamento o torna um pouco inútil para depuração, IMHO.

História básica ... nslookup era o comando, mas tinha sua própria implementação de todas as suas rotinas de resolução. O que começou a acontecer foi que os resolvedores de sistemas em plataformas diferentes funcionavam de maneira diferente do nslookup. Às vezes, isso produzia resultados bastante diferentes.

Os comandos host e dig foram criados como "reescritos" para o nslookup. Eles vinculam estaticamente nas funções de resolução do sistema. O resolvedor do sistema é uma coleção de funções na biblioteca C padrão de um sistema UNIX ou semelhante ao UNIX (no Mac OS X, essas funções fazem parte da biblioteca netdb). Ao fazer isso, os comandos host e dig sempre funcionam da mesma maneira que o resolvedor do sistema faz para qualquer sistema operacional para o qual foram criados, mas não confiam nele. Dessa forma, são excelentes ferramentas de diagnóstico nos casos em que o resolvedor do sistema está com defeito.

NOTA: O host e a escavação lêem a lista de servidores de nomes em /etc/resolv.conf, a menos que recebam um servidor de nomes específico para conversar. Somente o comando host usa a lista de pesquisa no arquivo /etc/resolv.conf; dig não, e é por isso que é sempre necessário digitar FQDN para resolver qualquer coisa. Caso contrário, ambos os comandos são totalmente auto-suficientes; por exemplo, o arquivo /etc/resolv.conf é a única coisa que não está no arquivo binário que eles usam.

mDNSresponder é Bonjour. Não investiguei muito profundamente, mas suspeito que essa configuração não está corrigindo isso ou, pelo menos, não diretamente. Acabei de experimentar esse mesmo problema no Mac OS X 10.9.1 e simplesmente reiniciar o mDNSresponder o corrigiu para mim. Eu nunca vi esse problema antes em 10.5 -> 10.8 / 10.9 em qualquer outro sistema. Além disso, os aplicativos da GUI não foram afetados por ele; foram apenas as ferramentas de linha de comando, como ping e ssh, que foram quebradas.

Se eu encontrar tempo para vasculhar um pouco mais a biblioteca, verei se consigo encontrar uma explicação mais completa.

Reunimos um script de shell para automatizar a correção (e um desinstalador, se você precisar mais tarde), aqui:

https://github.com/michthom/AlwaysAppendSearchDomains

Isso era para dar a usuários menos técnicos no trabalho que poderiam evitar a edição manual de arquivos do sistema.

.local é reservado para multicast. Os servidores mDNS e DNS na mesma rede usando .local podem ser problemáticos.

O host está anexando o sufixo .local dns. Ping não é. Se você achar isso desconcertante, poderá adicionar .local como sufixo padrão nas preferências do sistema de rede e o sistema o adicionará ao tentar resolver nomes de host.

Caso você tenha tentado todas as opções acima e nada funcionou, adicione seus servidores de nomes e caminhos de pesquisa aSystem Preferences>Network>Advance(bottom right of the window)>DNS tab

Isso atualiza o /etc/resolv.conf e o ping agora devem funcionar. Atualizar o caminho de pesquisa editando o arquivo /etc/resolv.conf realmente não funciona, mas por algum motivo.

ATUALIZAR:

A edição do /etc/resolv.conf não funciona porque o sistema operacional reescreve o arquivo com base na configuração do painel Preferências do Sistema.

Não tenho reputação suficiente para comentar o post de Lamont Peterson . Reiniciar o mDNSresponder funcionou para mim no Mac OS X 10.7 (Lion). Ao contrário de Lamont Peterson, esse problema causava problemas com um aplicativo GUI para mim - o Safari não conseguia resolver nomes de host públicos ou privados. Aqui estão as etapas específicas que eu fiz e que suspeito que Lamont Peterson também fez:

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

Ele unloaddesliga o mDNSresponder e o loadinicia novamente.

Isso resolveu o problema imediatamente; não é necessário reiniciar.

Você pode verificar se foi reiniciado com êxito usando o listcomando:

$ sudo launchctl list | grep '^PID\|mDNSResponder'
PID     Status  Label
708     -       com.apple.mDNSResponder
-       0       com.apple.mDNSResponderHelper

A presença de um ID do processo (PID) significa que ele está sendo executado. 708variará conforme é atribuído pelo sistema operacional. Se o status mostrar algo diferente de um hífen ou zero, algo deu errado.

Eu não sei como mDNSResponderHelperinterage com mDNSResponder; Eu só tive que reiniciar mDNSResponder.

Em uma linha:

sudo kill $(ps ax | grep mDNSResponder | grep -v grep | grep -v Helper | awk '{ print $1 }')

Por favor, note que os nomes do OSX podem não ser padrão, portanto, para ser completo:

• FQDN são pingáveis
• nomes nos arquivos "hosts" são passíveis de ping

Os nomes de Mac NÃO são geralmente: duas correções devem ser feitas: a) altere os espaços para "-" b) adicione .local

por exemplo, no meu Mac: o MacBook Pro da ingconti

será pingável em: ingcontis-MacBook-Pro.local

E prefs de abertura você pode ver: