Solución:
Solución 1:
Obviamente, esta es una sesión de preguntas y respuestas preparada, pero esto tiende a confundir a la gente a menudo y no puedo encontrar una pregunta canónica que cubra el tema.
dig +trace es una gran herramienta de diagnóstico, pero un aspecto de su diseño es ampliamente malinterpretado: la IP de cada servidor que se consultará se obtiene de su biblioteca de resolución. Esto se pasa por alto muy fácilmente y, a menudo, solo termina convirtiéndose en un problema cuando su caché local tiene la incorrecto respuesta para un servidor de nombres en caché.
Análisis detallado
Esto es más fácil de desglosar 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 corre contrae.root-servers.net., seleccionado al azar de la lista de servidores de nombres raíz que acabamos de obtener. Tiene una dirección IP de192.203.230.10, y como tenemos+additionallo habilitó aparece venir del pegamento. - Dado que no tiene autoridad para serverfault.com, esto se delega al
com.Servidores de nombres de TLD. - Lo que no es obvio del resultado aquí es que
digno derivó la dirección IP dee.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)
+trace engañó y consultó al solucionador local para obtener la dirección IP del servidor de nombres del siguiente salto en lugar de consultar el pegamento. ¡Furtivo!
Por lo general, esto es “suficientemente bueno” y no causará ningún problema a la mayoría de las personas. Desafortunadamente, hay casos extremos. Si por alguna razón su caché de DNS ascendente proporciona la respuesta incorrecta para el servidor de nombres, este modelo se descompone por completo.
Ejemplo del mundo real:
- el dominio expira
- el pegamento se reasigna a los servidores de nombres de redireccionamiento del registrador
- las direcciones IP falsas se almacenan en caché para ns1 y ns2.yourdomain.com
- el dominio se renueva con pegamento restaurado
- cualquier caché con direcciones IP de servidor de nombres falsas continúa enviando a las personas a un sitio web que dice que el dominio está a la venta
En el caso anterior, +trace sugerirá que los propios servidores de nombres del propietario del dominio son la fuente del problema, y que está a una llamada de decirle incorrectamente a un cliente que sus servidores están mal configurados. Si se trata de algo sobre lo que puedas (o estés dispuesto a) 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, y cómo solucionar el problema manualmente cuando resulta insuficiente.
Editar:
También debe tenerse en cuenta que dig +trace no te advertirá sobre NS registros que apuntan a CNAMEalias. Esta es una violación de RFC que ISC BIND (y posiblemente otros) no intentará corregir. +trace Estará completamente feliz de aceptar el A registro que obtiene de su servidor de nombres configurado localmente, mientras que si BIND realizara una recursividad completa, rechazaría toda la zona con un SERVFAIL.
Esto puede ser complicado de solucionar si hay pegamento; esto funcionará bien hasta que los registros NS se actualicen y luego se rompan repentinamente. Las delegaciones sin cola siempre romper la recursividad de BIND cuando un NS puntos de registro en un alias.
Solucion 2:
Otra forma de rastrear la resolución de DNS sin usar el solucionador local para nada excepto para encontrar los servidores de nombres raíz, es usando 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 de serverfault.com, que en realidad tiene un problema de DNS en este momento:
valoraciones y comentarios
Si para ti ha sido de utilidad nuestro post, te agradeceríamos que lo compartas con más juniors y nos ayudes a dar difusión a nuestro contenido.