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.
+nssearch?+nssearchrealiza unaNSbúsqueda de registros en su resolutor local para el registro solicitado, seguido de una serie deA/AAAAbúsquedas en el resolutor local para cada uno de los servidores de nombres devueltos. También es susceptible a registros falsos de servidores de nombres en caché.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:
fuente
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:
una respuesta de referencia se trunca debido a que el tamaño de la respuesta supera los 512 bytes para la siguiente consulta iterativa
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.10Sin 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 ms496 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.
fuente