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

2

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. othersubdomain.otherdomain.com

Eu posso resolver completamente o 'host.lab.mydomain.com' completo e, quando eu tiver 'lab.mydomain.com' na lista, posso usar apenas 'host', pois ele é resolvido no 'laboratório'. sufixo mydomain.com. Mas eu não consigo resolver (em certos casos - continue lendo) "host.lab".

O mais estranho é que esta falha acontece com certos comandos (ou seja, SSH e dig). Usando 'nslookup' funciona bem e resolve o nome do host corretamente. No entanto, o uso de SSH ou dig falha . Eu normalmente posso, mas nem sempre, resolver "host.lab" através do 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 que estava fazendo uma pesquisa adequada para o meu servidor DNS configurado usando cada sufixo em ordem, o que encontrou o host em pouco tempo. No entanto, ssh e dig parecem estar tratando "host.lab" como um domínio de nível superior e indo direto para root-servers.net para tentar resolver "host" como um nome de domínio sob o " .lab "TLD - sem nunca tocando no meu servidor DNS configurado!

Qual é o problema? 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 digitando o nome completo do domínio, mas é muito, muito chato.

    
por Anthem 22.05.2014 / 19:17

2 respostas

2

Tenha em mente que nslookup e dig são ferramentas de depuração DNS . 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 de 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 busca (para tentar e "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 BIND 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 longa e sórdida história sobre o porquê, 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 ler análises recentes sobre este tópico .

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

    
por 31.05.2014 / 18:29
0

A partir da página de manual de dig :

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 escavador estava enviando uma consulta DNS totalmente qualificada (tem 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 ; adicionar +search aos seus argumentos fará com que ele se comporte de maneira mais convencional.

Para ssh e outros, eu encontrei este artigo que 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 .

    
por 24.05.2014 / 02:51