Por que o dig + trace às vezes falha no DNS do Windows Server?

Question

Minha equipe tem um servidor apontando para o DNS fornecido pelo Active Directory para garantir que ele seja capaz de alcançar qualquer host gerenciado pelo domínio. Infelizmente, minha equipe também precisa executar dig +trace com frequência e, esporadicamente, obtemos resultados estranhos. Eu sou um administrador de DNS, mas não um administrador de domínio, mas a equipe responsável por esses servidores também não sabe o que está acontecendo aqui.

O problema parece ter mudado entre as atualizações do sistema operacional, mas é difícil dizer se essa é uma característica da versão do SO ou de outras configurações que estão sendo alteradas durante o processo de atualização.

• Quando os servidores upstream eram o Windows Server 2003, a primeira etapa de dig +trace (solicitação . IN NS da primeira entrada em /etc/resolv.conf ) ocasionalmente retornava respostas de 0 byte.
• Quando os servidores upstream foram atualizados para o Windows Server 2012, o problema de resposta de zero bytes desapareceu, mas foi substituído por um problema em que esporadicamente obteríamos a lista de encaminhadores configurados no servidor DNS.

Exemplo do segundo problema:

$ dig +trace -x 1.2.3.4      

; <<>> DiG 9.8.2 <<>> +trace -x 1.2.3.4
;; global options: +cmd
.                       3600    IN      NS      dns2.ad.example.com.
.                       3600    IN      NS      dns1.ad.example.com.
;; Received 102 bytes from 192.0.2.11#53(192.0.2.11) in 22 ms

1.in-addr.arpa.         84981   IN      NS      ns1.apnic.net.
1.in-addr.arpa.         84981   IN      NS      tinnie.arin.net.
1.in-addr.arpa.         84981   IN      NS      sec1.authdns.ripe.net.
1.in-addr.arpa.         84981   IN      NS      ns2.lacnic.net.
1.in-addr.arpa.         84981   IN      NS      ns3.apnic.net.
1.in-addr.arpa.         84981   IN      NS      apnic1.dnsnode.net.
1.in-addr.arpa.         84981   IN      NS      ns4.apnic.net.
;; Received 507 bytes from 192.0.2.228#53(192.0.2.228) in 45 ms

1.in-addr.arpa.         172800  IN      SOA     ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net.
4827 7200 1800 604800 172800
;; Received 127 bytes from 202.12.28.131#53(202.12.28.131) in 167 ms

Na maioria dos casos, isso não é um problema, mas fará o dig +trace seguir o caminho errado se estivermos rastreando dentro de um domínio para o qual o AD tenha uma visão interna.

Por que dig +trace está perdendo a cabeça? E por que parece que somos os únicos reclamando?

    

Answer 1

Você está sendo controlado por dicas de raiz. Este é um truque para solucionar problemas, e depende da compreensão de que a consulta . IN NS enviada no início de um rastreio não define o sinalizador RD (recursão desejada) no pacote.

Quando o servidor DNS da Microsoft recebe uma solicitação não recursiva para os servidores de nomes raiz, é possível que eles retornem as dicas de raiz configuradas. Contanto que você não adicione o sinalizador RD à solicitação, o servidor continuará feliz em retornar a mesma resposta com um TTL fixo durante todo o dia.

$ dig @192.0.2.11 +norecurse . NS

; <<>> DiG 9.8.2 <<>> @192.0.2.11 +norecurse . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12586
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       3600    IN      NS      dns2.ad.example.com.
.                       3600    IN      NS      dns1.ad.example.com.

;; ADDITIONAL SECTION:
dns2.ad.example.com.    3600    IN      A       192.0.2.228
dns1.ad.example.com.    3600    IN      A       192.0.2.229

É aí que a maioria dos esforços de resolução de problemas se desintegra, porque a suposição simples de saltar para é que dig @whatever . NS reproduzirá o problema, o que na verdade o mascara completamente. Quando o servidor obtém uma solicitação de servidores de nomes raiz com o conjunto de sinalizadores RD , ele acessa e obtém uma cópia dos servidores de nomes raiz real . NS sem a bandeira RD magicamente começará a funcionar como esperado. Isso deixa dig +trace feliz novamente, e todos podem voltar a coçar suas cabeças até que o problema reapareça.

Suas opções são negociar uma configuração diferente com seus administradores de domínio ou solucionar o problema. Contanto que as dicas de raiz envenenadas sejam boas o suficiente na maioria das circunstâncias (e você está ciente das circunstâncias em que elas não estão: visões conflitantes, etc.), isso não é um grande inconveniente.

Algumas soluções alternativas sem alterar as dicas de raiz são:

• Execute seus rastreamentos em uma máquina que tenha um conjunto de resolvedores padrão menos louco.
• Inicie seu rastreio a partir de um servidor de nomes que retorne servidores de nomes raiz para a Internet em resposta a . NS . Você também pode hardwire este nameserver em ${HOME}/.digrc , mas isso pode confundir os outros em uma conta compartilhada ou ser esquecido por você em algum momento. %código%
• Proponha as dicas de raiz para você mesmo antes de executar o rastreamento.
  dig @somethingelse +trace example.com
dig . NS