O dig + trace é sempre preciso?

Question

Quando a precisão de um cache DNS está em questão, dig +trace tende a ser a maneira recomendada de determinar a resposta autoritativa para um registro DNS voltado para a Internet. Isso parece ser particularmente útil quando também emparelhado com +additional , que também mostra os registros de cola.

Ocasionalmente parece haver algum desacordo sobre este ponto - algumas pessoas dizem que depende do resolvedor local para procurar os endereços IP dos servidores de nomes intermediários, mas a saída do comando não oferece nenhuma indicação de que isso está acontecendo além do inicial lista de servidores de nomes raiz. Parece lógico supor que esse não seria o caso se a finalidade de +trace fosse iniciar nos servidores raiz e rastrear seu caminho. (pelo menos se você tiver a lista certa de servidores de nomes raiz)

O dig +trace realmente usa o resolvedor local para qualquer coisa além dos servidores de nomes raiz?

    

Answer 1

Este é obviamente um Q & A encenado, mas isso tende a confundir as pessoas com frequência e eu não posso encontrar uma pergunta canônica sobre o assunto.

dig +trace é uma ótima ferramenta de diagnóstico, mas um aspecto de seu design é amplamente mal entendido: o IP de cada servidor que será consultado é obtido da sua biblioteca de resolução . Isso é facilmente ignorado e, muitas vezes, acaba se tornando um problema quando o cache local tem a resposta errada para um servidor de nomes armazenado em cache.

Análise detalhada

Isso é mais fácil de quebrar com uma amostra da saída; Vou omitir tudo após a primeira delegação do NS.

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms

• A consulta inicial de . IN NS (servidores de nomes raiz) atinge o resolvedor local, que neste caso é Comcast. ( 75.75.75.75 ) Isso é fácil de detectar.
• A próxima consulta é de serverfault.com. IN A e é executada com e.root-servers.net. , selecionada aleatoriamente na lista de servidores de nomes raiz que acabamos de obter. Ele tem um endereço IP de 192.203.230.10 e, como temos +additional ativado, aparece vindo da cola.
• Como não é autoritativo para serverfault.com, isso é delegado aos servidores de nomes com. TLD.
• O que não é óbvio da saída aqui é que dig não derivou o endereço IP de e.root-servers.net. da cola.

No fundo, isso é o que realmente aconteceu:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

+trace enganou e consultou o resolvedor local para obter o endereço IP do servidor de nomes next hop em vez de consultar a cola. Sneaky!

Isso geralmente é "bom o suficiente" e não causará problemas para a maioria das pessoas. Infelizmente, existem casos extremos. Se, por qualquer motivo, o seu cache DNS upstream estiver fornecendo a resposta errada para o servidor de nomes, esse modelo será totalmente quebrado.

Exemplo do mundo real:

• o domínio expira
• cola é indicada nos servidores de nomes de redirecionamento de registradores
• IPs falsos são armazenados em cache para ns1 e ns2.yourdomain.com
• o domínio é renovado com cola restaurada
• todos os caches com os falsos IPs do servidor de nomes continuam a enviar pessoas para um site que diz que o domínio está à venda

No caso acima, +trace sugerirá que os próprios servidores de nome do proprietário do domínio são a origem do problema, e você está a uma ligação de informar incorretamente a um cliente que os servidores estão configurados incorretamente. Se é algo que você pode (ou está disposto a fazer) sobre algo é outra história, mas é importante ter a informação correta.

dig +trace é uma ótima ferramenta, mas, como qualquer ferramenta, você precisa saber o que ela faz e o que não faz e como solucionar o problema manualmente quando for insuficiente.

Editar:

Também deve ser observado que dig +trace não avisará você sobre NS registros que apontam para CNAME aliases. Esta é uma violação da RFC que o ISC BIND (e possivelmente outros) não tentará corrigir. +trace terá todo o prazer em aceitar o registro A que recebe de seu servidor de nomes configurado localmente, ao passo que se o BIND estiver executando uma recursão completa, estará rejeitando a zona inteira com um SERVFAIL.

Isso pode ser complicado para solucionar problemas se a cola estiver presente; isso funcionará bem até que os registros NS sejam atualizados e, de repente, quebras. As delegações sem cola irão sempre interromper a recursão do BIND quando um NS registrar pontos em um alias.

    

Answer 2

Outra forma de rastrear a resolução de DNS sem usar o resolvedor local para nada, exceto encontrar os servidores de nomes raiz, é usar dnsgraph (Divulgação completa : Eu escrevi isto). Ele tem uma ferramenta de linha de comando e uma versão da web, da qual você pode encontrar uma instância no link

Exemplo para serverfault.com, que atualmente tem um problema de DNS:

    

Answer 3

Muito atrasado para este tópico, mas acho que a parte da questão de porque um dig + trace usa consultas recursivas para resolvedores locais não foi diretamente explicada, e essa explicação é relevante para a precisão dos resultados do dig + trace .

Após a consulta recursiva inicial para os registros NS da zona raiz, o dig pode emitir consultas subsequentes para resolvedores locais nas seguintes condições:

1. uma resposta de referência é truncada devido ao tamanho da resposta excedendo 512 bytes para a próxima consulta iterativa

2. dig seleciona um registro NS da seção AUTORIDADE da resposta de referência para o qual o registro A correspondente (cola) está faltando no Seção ADICIONAL

Como o dig tem apenas um nome de domínio do registro NS, dig precisa resolver o nome para um endereço IP consultando o servidor DNS local. Esta é a causa raiz (trocadilho, desculpe).

AndrewB tem um exemplo que não está totalmente em consonância com o que acabei de descrever, em que o registro NS da zona raiz escolhido:

. 121459 IN NS e.root-servers.net.

tem um registro A correspondente:

e.root-servers.net. 354907 IN A 192.203.230.10

Observe, entretanto, que não há um registro AAAA correspondente para o e-root, assim como nenhum registro AAAA para alguns outros servidores raiz.

Além disso, observe o tamanho da resposta:

;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

496 bytes é um tamanho comum para respostas que foram truncadas (ou seja, o próximo registro de cola teria sido > 16 bytes, colocando a resposta em 512 bytes). Em outras palavras, em uma consulta para os registros NS de raiz, uma AUTORIDADE completa e ADICIONAL completa (registros A e AAAA) excederão 512 bytes, portanto, qualquer consulta baseada em UDP que não especifique um tamanho de consulta maior por meio de opções EDNS0 obtenha uma resposta que esteja cortada em algum lugar na seção ADICIONAL, como mostra o rastreamento acima (somente f, h, i, jek possuem registros de cola A e AAAA).

A falta de um registro AAAA para e.root-servers.net e o tamanho da resposta ao "NS". consulta sugere strongmente que a próxima consulta recursiva foi feita pela razão que estou reivindicando. Talvez o cliente O / S seja compatível com IPv6 e prefira registros AAAA - ou algum outro motivo.

Mas, em qualquer caso, depois de ler este tópico, examinei o fenômeno de dig + trace executando consultas recursivas subseqüentes à inicial do root. A correspondência entre selecionar um registro NS sem um registro A / AAAA correspondente e cavar e enviar uma consulta recursiva para esse registro para o DNS local é 100%, na minha experiência. E o inverso é verdadeiro - eu não vi consultas recursivas quando o registro NS selecionado da referência tem um registro de cola correspondente.