Dig + trace é sempre preciso?

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

Ocasionalmente, parece haver alguma discordância quanto a esse ponto - algumas pessoas dizem que ele 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 esteja acontecendo além da lista inicial de root servidores de nomes. Parece lógico supor que esse não seria o caso se o objetivo de +traceiniciar nos servidores raiz e rastrear o caminho. (pelo menos se você tiver a lista correta de servidores de nomes raiz)

Será que dig +tracerealmente usar o resolvedor local para nada passado os servidores de nomes de raiz?

Obviamente, essa é uma sessão de perguntas e respostas encenada, mas isso costuma confundir as pessoas e não consigo encontrar uma pergunta canônica que cubra o tópico.

dig +traceé uma ótima ferramenta de diagnóstico, mas um aspecto de seu design é amplamente mal compreendido: o IP de todos os servidores que serão consultados é obtido na sua biblioteca de resolvedores . Isso é facilmente ignorado e geralmente acaba se tornando um problema quando o cache local tem a resposta errada para um servidor de nomes em cache.

Análise detalhada

Isso é mais fácil de quebrar com uma amostra da saída; Vou omitir tudo o que passou na primeira delegação 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 para . IN NS(servidores de nomes raiz) atinge o resolvedor local, que neste caso é Comcast. ( 75.75.75.75) É fácil de identificar.
• A próxima consulta é serverfault.com. IN Acontra e é 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.10e, como +additionalativamos, ele parece vir da cola.
• Como não é autoritário para serverfault.com, isso é delegado nos com.servidores de nomes de TLDs.
• O que não é óbvio a partir da saída aqui é que dignão derivou o endereço IP da e.root-servers.net.cola.

Em segundo plano, foi 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)

+tracetrapaceou e consultou o resolvedor local para obter o endereço IP do servidor de nomes do próximo salto em vez de consultar a cola. Sorrateiro!

Isso geralmente é "bom o suficiente" e não causa problemas para a maioria das pessoas. Infelizmente, existem casos extremos. Se, por qualquer motivo, 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 é apontada nos servidores de nomes de redirecionamento de registradores
• IPs falsos são armazenados em cache para ns1 e ns2.seudominio.com
• domínio é renovado com cola restaurada
• quaisquer caches com os IPs falsos dos servidores de nomes continuam a enviar pessoas para um site que diz que o domínio está à venda

No caso acima, +tracesugerirá que os servidores de nomes do proprietário do domínio são a fonte do problema, e você está longe de informar incorretamente a um cliente que seus servidores estão configurados incorretamente. Se é algo que você pode (ou está disposto a) fazer é outra história, mas é importante ter as informações corretas.

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

Editar:

Observe também que dig +tracenão o alertará sobre NSregistros que apontam para CNAMEaliases. Esta é uma violação RFC que o ISC BIND (e possivelmente outros) não tentará corrigir. +traceterá todo o gosto em aceitar o Aregistro obtido do servidor de nomes configurado localmente, enquanto que se o BIND estivesse executando uma recursão completa, estaria rejeitando toda a zona com um SERVFAIL.

Isso pode ser complicado para solucionar problemas se houver cola; isso funcionará bem até que os registros do NS sejam atualizados e , de repente, quebre. Delegações sem cola sempre quebram a recursão do BIND quando um NSregistro aponta para um pseudônimo.

Outra maneira de rastrear a resolução do DNS sem usar o resolvedor local para qualquer coisa, exceto encontrar os servidores de nomes raiz, é usar o dnsgraph (divulgação completa: escrevi isso). Possui uma ferramenta de linha de comando e uma versão da Web, da qual você pode encontrar uma instância em http://ip.seveas.net/dnsgraph/

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

Muito tarde para este segmento, mas acho que a parte da pergunta sobre por que um dig + trace usa consultas recursivas para os 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 subseqüentes aos resolvedores locais nas seguintes condições:

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

2. dig seleciona um registro NS da seção AUTHORITY da resposta de referência para a qual o registro A correspondente (cola) está ausente na seção ADICIONAL

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

AndrewB tem um exemplo que não é totalmente compatível com o que acabei de descrever, em que o registro NS da zona raiz escolhido:

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

possui um registro A correspondente:

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

Observe, no entanto, que não há um registro AAAA correspondente para e-root, bem 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> 16 bytes, colocando a resposta acima de 512 bytes). Em outras palavras, em uma consulta para os registros NS da raiz, uma AUTHORITY completa e ADICIONAL completa (registros A e AAAA) excederão 512 bytes, portanto, qualquer consulta baseada em UDP que não especifique um tamanho maior de consulta via opções EDNS0 obtenha uma resposta cortada em algum lugar da seção ADICIONAL, como mostra o rastreamento acima (apenas f, h, i, j ek têm registros de cola A e AAAA).

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

Mas, de qualquer forma, depois de ler este tópico, analisei o fenômeno do dig + trace executando consultas recursivas subsequentes à raiz inicial. A correspondência entre selecionar um registro NS sem um registro A / AAAA de cola correspondente e cavar e enviar uma consulta recursiva para esse registro ao DNS local é 100%, na minha experiência. E o inverso é verdadeiro - não vi consultas recursivas quando o registro NS selecionado a partir da referência possui um registro de cola correspondente.