¿Es dig + trace siempre preciso?

Cuando la precisión de un caché de DNS está en duda, dig +tracetiende a ser la forma recomendada de determinar la respuesta autorizada para un registro DNS de Internet. Esto parece ser particularmente útil cuando también se combina con +additional, que también muestra los registros de pegamento.

Ocasionalmente parece haber algún desacuerdo sobre este punto: algunas personas dicen que depende del resolutor local para buscar las direcciones IP de los servidores de nombres intermedios, pero la salida del comando no ofrece ninguna indicación de que esto esté sucediendo más allá de la lista inicial de root servidores de nombres. Parece lógico suponer que este no sería el caso si el propósito +tracees comenzar en los servidores raíz y rastrear su camino hacia abajo. (al menos si tiene la lista correcta de servidores de nombres raíz)

¿ dig +traceRealmente utiliza el solucionador local para algo más allá de los servidores de nombres raíz?

Obviamente, esto es un Q&A organizado, pero tiende a confundir a las personas con frecuencia y no puedo encontrar una pregunta canónica que cubra el tema.

dig +tracees una gran herramienta de diagnóstico, pero un aspecto de su diseño es ampliamente malentendido: la IP de cada servidor que se consultará se obtiene de su biblioteca de resolución . Esto se pasa por alto fácilmente y, a menudo, solo se convierte en un problema cuando su caché local tiene la respuesta incorrecta para un servidor de nombres en caché.

Análisis detallado

Esto es más fácil de descomponer con una muestra de la salida; Omitiré todo más allá de la primera delegación de 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

• La consulta inicial para . IN NS(servidores de nombres raíz) llega al solucionador local, que en este caso es Comcast. ( 75.75.75.75) Esto es fácil de detectar.
• La siguiente consulta es para serverfault.com. IN Ay se ejecuta en contra e.root-servers.net., seleccionada al azar de la lista de servidores de nombres raíz que acabamos de recibir. Tiene una dirección IP de 192.203.230.10, y dado que lo hemos +additionalhabilitado, parece provenir del pegamento.
• Como no tiene autoridad para serverfault.com, esto se delega a los com.servidores de nombres de TLD.
• Lo que no es obvio de la salida aquí es que digno derivó la dirección IP e.root-servers.net.del pegamento.

En el fondo, esto es lo que realmente sucedió:

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)

+traceengañó y consultó al solucionador local para obtener la dirección IP del servidor de nombres del próximo salto en lugar de consultar el pegamento. ¡Furtivo!

Esto suele ser "lo suficientemente bueno" y no causará problemas a la mayoría de las personas. Desafortunadamente, hay casos extremos. Si, por alguna razón, su caché DNS ascendente proporciona una respuesta incorrecta para el servidor de nombres, este modelo se descompone por completo.

Ejemplo del mundo real:

• el dominio expira
• se pega pegamento en los servidores de nombres de redirección de registradores
• Las IP falsas se almacenan en caché para ns1 y ns2.yourdomain.com
• el dominio se renueva con pegamento restaurado
• cualquier caché con direcciones IP falsas del servidor de nombres continúa enviando personas a un sitio web que dice que el dominio está a la venta

En el caso anterior, +tracesugerirá que los propios servidores de nombres del propietario del dominio son la fuente del problema, y ​​está a una llamada de decirle incorrectamente a un cliente que sus servidores están mal configurados. Si es algo que puede (o está dispuesto a hacer) hacer algo es otra historia, pero es importante tener la información correcta.

dig +trace es una gran herramienta, pero como cualquier herramienta, necesita saber qué hace y qué no hace, y cómo solucionar el problema manualmente cuando resulta insuficiente.

Editar:

También debe tenerse en cuenta que dig +traceno le advertirá sobre los NSregistros que apuntan a CNAMEalias. Esta es una violación de RFC que ISC BIND (y posiblemente otros) no intentará corregir. +traceestará completamente feliz de aceptar el Aregistro que obtiene de su servidor de nombres configurado localmente, mientras que si BIND realizara una recursión completa, rechazaría toda la zona con un SERVFAIL.

Esto puede ser difícil de solucionar si hay pegamento presente; esto funcionará bien hasta que los registros NS se actualicen y luego se rompan de repente. Las delegaciones sin cola siempre romperán la recursividad de BIND cuando un NSregistro apunte a un alias.

Otra forma de rastrear la resolución DNS sin usar el solucionador local para nada, excepto encontrar los servidores de nombres raíz, es mediante dnsgraph ( Divulgación completa: escribí esto). Tiene una herramienta de línea de comandos y una versión web, de la cual puede encontrar una instancia en http://ip.seveas.net/dnsgraph/

Ejemplo para serverfault.com, que actualmente tiene un problema de DNS en este momento:

Muy tarde a este hilo, pero creo que la parte de la pregunta de por qué un rastreo de dig + usa consultas recursivas a los resolutivos locales no se ha explicado directamente, y esta explicación es relevante para la precisión de los resultados de dig + trace.

Después de la consulta recursiva inicial para los registros NS de la zona raíz, luego dig puede emitir consultas posteriores a los solucionadores locales en las siguientes condiciones:

1. una respuesta de referencia se trunca debido a que el tamaño de la respuesta supera los 512 bytes para la siguiente consulta iterativa

2. dig selecciona un registro NS de la sección AUTORIDAD de la respuesta de referencia para la que falta el registro A correspondiente (pegamento) en la sección ADICIONAL

Debido a que dig solo tiene un nombre de dominio del registro NS, dig debe resolver el nombre a una dirección IP consultando el servidor DNS local. Esta es la causa raíz (juego de palabras, lo siento).

AndrewB tiene un ejemplo que no está totalmente en consonancia con lo que acabo de describir, ya que el registro NS de la zona raíz elegido:

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

tiene un registro A correspondiente:

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

Sin embargo, tenga en cuenta que no hay un registro AAAA correspondiente para e-root, ni tampoco un registro AAAA para algunos otros servidores raíz.

Además, tenga en cuenta el tamaño de la respuesta:

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

496 bytes es un tamaño común para las respuestas que se han truncado (es decir, el siguiente registro de pegamento habría sido> 16 bytes, poniendo la respuesta por encima de 512 bytes). En otras palabras, en una consulta para los registros NS de raíz, una AUTORIDAD completa y ADICIONAL completa (tanto registros A como AAAA) excederá los 512 bytes, por lo que cualquier consulta basada en UDP que no especifique un tamaño de consulta mayor a través de las opciones EDNS0 obtenga una respuesta que se corta en algún lugar de la sección ADICIONAL, como lo muestra la traza anterior (solo f, h, i, j y k tienen registros de cola A y AAAA).

La falta de un registro AAAA para e.root-servers.net y el tamaño de la respuesta al "NS". query sugiere que la próxima consulta recursiva se realizó por el motivo que estoy reclamando Quizás el cliente O / S es compatible con IPv6 y prefiere registros AAAA, o alguna otra razón.

Pero en cualquier caso, después de leer este hilo, analicé el fenómeno de dig + trace realizando consultas recursivas posteriores a la inicial para root. La correspondencia entre seleccionar un registro NS sin un registro A / AAAA de pegamento correspondiente y excavar luego enviar una consulta recursiva para ese registro al DNS local es 100%, en mi experiencia. Y lo contrario es cierto: no he visto consultas recursivas cuando el registro NS seleccionado de la referencia tiene un registro de pegamento correspondiente.