Mac OS X 10.9 tratando subdomínio como domínio de nível superior?

Eu pareço constantemente ter problemas para resolver hosts na minha rede a partir de sistemas OS X. Eu tenho um domínio (vamos chamá-lo mydomain.com) com um subdomínio lab.mydomain.com e o host que eu quero chegar, em host.lab.mydomain.com.

As entradas de pesquisa de DNS do meu Mac incluem:

1. mydomain.com
2. lab.mydomain.com
3. lab.otherdomain.com
4. outro subdomínio outro domínio

Eu posso resolver completamente o 'host.lab.mydomain.com' bem, e quando eu tenho 'lab.mydomain.com' na lista, eu posso usar apenas 'host', uma vez que resolve sob o 'lab.mydomain.com 'sufixo. Mas não consigo resolver (em certos casos - continue lendo) "host.lab".

O mais estranho é esse fracasso só acontece com certos comandos (ou seja, SSH e dig). Usando o 'nslookup' funciona bem e resolve o nome do host corretamente. No entanto, usando SSH ou cavar falha . Eu geralmente consigo, mas nem sempre, resolvo "host.lab" pelo Chrome.

Eu executei uma filtragem tcpdump na porta 53 para tentar diagnosticar isso sozinho, e os resultados foram interessantes: depois de executar "dscacheutil -flushcache; killall -HUP mDNSResponder" e tentar resolver usando os diferentes comandos, descobri que "nslookup" é claro estava fazendo uma pesquisa adequada para o meu servidor DNS configurado usando cada sufixo em ordem, que encontrou o host em pouco tempo. No entanto, ssh e dig parecem estar tratando "host.lab" como domínio de nível superior e ir direto ao root-servers.net para tentar resolver "host" como um nome de domínio sob o TLD ".lab" - sem sempre tocando meu servidor DNS configurado!

Qual é o negócio? Por que esses determinados esquemas de resolução de nomes em meu Mac estão causando curto-circuito e tratando .lab como um domínio de nível superior em vez de honrar meus sufixos de pesquisa de DNS? É claro que posso contornar isso dando um nome completo ao domínio, mas é muito, muito chato.

Tenha em mente que nslookup e dig são DNS depuração Ferramentas. Eles possuem seu próprio código de resolvedor integrado e não se comportam da mesma maneira que o resolvedor de sistema usado pelos aplicativos comuns. Por padrão, dig nunca acrescenta domínios da lista de pesquisa para tentar qualificar totalmente um nome, mesmo que você forneça apenas "host" (ele tratará isso como um domínio de nível superior), mas nslookup faz o oposto e sempre anexa domínios de lista de pesquisa (para tentar "ajudar" você). Essas ferramentas não poderiam ser mais justapostas do que as ferramentas de depuração.

A maioria dos aplicativos de linha de comando (como 'ssh') usa a biblioteca BSD para pesquisa de nome e o código de resolvedor vem de LIGAR que trata qualquer nome com um "." nele como um domínio totalmente qualificado e não anexará domínios de lista de pesquisa. Há uma história longa e sórdida a respeito de por que, mas funciona melhor desta forma para evitar conflitos e nomear "colisões" que acontecem com o apêndice da lista de pesquisa em um sentido geral. Você pode leia análises recentes sobre este tópico .

Agora que você entende isso, use "host" ou "host.lab.mydomain.com" com seus aplicativos. ;-)

De dig Manpage:

Mac OS X NOTICE
       The dig command does not use the host name and address resolution or
       the DNS query routing mechanisms used by other processes running on Mac
       OS X.  The results of name or address queries printed by dig may differ
       from those found by other processes that use the Mac OS X native name
       and address resolution mechanisms.  The results of DNS queries may also
       differ from queries that use the Mac OS X DNS routing library.

Ao assistir as transações do DNS via tcpdump como você fez, notei que o dig estava enviando uma consulta DNS totalmente qualificada (possui um rastreio), mesmo quando não estava incluída na linha de comando:

192.168.2.122.61036 > 142.166.166.166.53: 51329+ A? www. (21)

Isso, claro, falhará. Este é o comportamento padrão para esta compilação de dig; adicionando +search aos seus argumentos fará com que se comporte mais convencionalmente.

Para ssh e outros, eu encontrei Este artigo Isso sugere adicionar um argumento ao arquivo de lista de propriedades do mDNSresponder para obrigá-lo a usar os domínios de pesquisa. Isso também pode corrigir dig.