Cómo rastrear la resolución DNS: depura búsquedas con dig y nslookup
Aprende cómo rastrear una resolución DNS paso a paso con dig +trace, nslookup y drill. Depura NXDOMAIN, búsquedas lentas y problemas de propagación con ejemplos prácticos.
Cuando un dominio no se resuelve, carga lentamente o devuelve una IP inesperada, la causa raíz casi siempre está en alguna parte de la cadena de resolución DNS. Una sola consulta a tu resolutor local oculta lo que realmente ocurrió — qué servidores de nombres fueron consultados, quién respondió y dónde se rompió la cadena. Para ver toda la historia, necesitas un rastreo DNS.
Esta guía te muestra cómo rastrear una resolución DNS de principio a fin usando herramientas estándar, leer la salida y diagnosticar los modos de fallo más comunes.
¿Qué es un rastreo DNS?
Un rastreo DNS es un recorrido paso a paso por la resolución recursiva de un nombre de dominio, comenzando desde los servidores de nombres raíz y siguiendo la cadena de delegación hasta el servidor de nombres autoritativo para el dominio. A diferencia de una consulta estándar que solo devuelve la respuesta final, un rastreo muestra cada consulta y respuesta intermedia, haciendo posible identificar exactamente dónde falla o se comporta mal una resolución.
Cómo funciona la resolución DNS (Resumen rápido)
Cada resolución de dominio sigue la misma jerarquía:
- Servidores de nombres raíz (
.) — 13 servidores lógicos que saben qué servidores de nombres manejan cada dominio de nivel superior (TLD). - Servidores de nombres TLD (
.com,.org,.fr, …) — delegan a los servidores de nombres autoritativos del dominio registrado. - Servidores de nombres autoritativos — contienen los registros reales (A, AAAA, MX, TXT, …) del dominio.
Un resolutor recursivo (el DNS de tu ISP, 1.1.1.1, 8.8.8.8, Pi-hole, etc.) recorre esta cadena en tu nombre y almacena en caché los resultados. Cuando tú rastreas la resolución tú mismo, evitas la caché y observas la ruta de delegación en bruto.
Ejecutando un rastreo DNS con dig
El comando dig (parte de bind-utils en Linux, bind9-dnsutils en Debian/Ubuntu, y incluido por defecto en macOS) es la herramienta estándar para depuración DNS. Su bandera +trace ejecuta un rastreo recursivo completo desde la raíz:
dig +trace ejemplo.com
La salida lista, para cada nivel, los servidores de nombres consultados y sus respuestas. Un rastreo típico para ejemplo.com se ve así:
;; opciones globales: +cmd
. 86400 IN NS a.root-servers.net.
. 86400 IN NS b.root-servers.net.
...
;; Recibido 811 bytes de 192.168.1.1#53(192.168.1.1) en 4 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...
;; Recibido 1174 bytes de 198.41.0.4#53(a.root-servers.net) en 12 ms
ejemplo.com. 172800 IN NS a.iana-servers.net.
ejemplo.com. 172800 IN NS b.iana-servers.net.
;; Recibido 289 bytes de 192.5.6.30#53(a.gtld-servers.net) en 24 ms
ejemplo.com. 86400 IN A 93.184.216.34
;; Recibido 56 bytes de 199.43.135.53#53(a.iana-servers.net) en 18 ms
Cada bloque muestra la delegación en ese nivel, el TTL, el servidor de nombres que respondió y el tiempo de consulta. El bloque final contiene la respuesta autoritativa.
Alternativas: nslookup y drill
nslookup (disponible en todas partes, incluyendo Windows) es más simple pero menos flexible. No soporta un rastreo recursivo, pero puedes consultar manualmente cada nivel:
nslookup -type=NS com.
nslookup -type=NS ejemplo.com. a.gtld-servers.net
nslookup ejemplo.com. a.iana-servers.net
drill (de ldns) es un reemplazo moderno para dig con una salida más limpia y mejor soporte para DNSSEC:
drill -T ejemplo.com
En Windows, Resolve-DnsName en PowerShell es el equivalente moderno, aunque no produce un rastreo por sí mismo.
Interpretando la salida del rastreo
Tres campos son importantes al interpretar un rastreo:
- TTL (primer número) — cuánto tiempo puede almacenarse en caché el registro. Un TTL muy bajo (menos de 60 s) suele indicar balanceo de carga o un cambio reciente; un TTL alto (24 h+) significa que los cambios se propagarán lentamente.
- Fuente del servidor de nombres (
from X.X.X.X#53(nombre del host)) — quién respondió en cada paso. Si el mismo servidor aparece en múltiples niveles, algo está mal configurado. - Tiempo de consulta (
en N ms) — latencia hacia cada servidor de nombres. Un solo salto lento puede añadir cientos de milisegundos a cada resolución sin caché.
Problemas comunes de DNS y cómo detectarlos
- NXDOMAIN — el servidor de nombres autoritativo devuelve "el nombre no existe". Verifica errores tipográficos, dominios caducados o delegación incorrecta en el nivel TLD.
- SERVFAIL — un servidor de nombres en la cadena no responde o devuelve respuestas malformadas. Ejecuta el rastreo dos veces: si el servidor que falla cambia, el problema es transitorio; si es constante, el problema está en ese servidor específico.
- Resolución lenta — observa los tiempos de consulta en cada nivel. Una consulta lenta en raíz o TLD es rara y sugiere problemas en la red local. Una consulta lenta en el servidor autoritativo apunta al operador del dominio.
- Datos obsoletos — si un rastreo muestra la IP correcta pero tu navegador usa una antigua, tu resolutor recursivo todavía está en caché. Limpia con
sudo resolvectl flush-caches(systemd-resolved),sudo dscacheutil -flushcache(macOS) oipconfig /flushdns(Windows). - Problemas de propagación — después de un cambio DNS, diferentes resolutores ven valores distintos hasta que expiran los TTLs. Consulta varios resolutores públicos (
1.1.1.1,8.8.8.8,9.9.9.9) para verificar la consistencia. - Delegación defectuosa — un TLD delega a servidores de nombres que no responden de forma autoritativa para la zona. Visible como un
SERVFAILde uno o más servidores mientras otros funcionan.
Rastreo DNS vs Búsqueda DNS: Conoce la diferencia
Un dig ejemplo.com simple consulta tu resolutor recursivo, devuelve la respuesta en caché y no te dice nada sobre el camino. Un rastreo evita la caché y recorre la cadena por sí mismo. Usa una búsqueda para verificar el resultado; usa un rastreo para depurar el proceso.
Cuando el rastreo no es suficiente
DNS es solo la mitad de una conexión. Una vez que un nombre se resuelve, tus paquetes aún deben encontrar el servidor a través de redes enrutadas por BGP. Si DNS devuelve la IP correcta pero el servicio no es alcanzable o es lento, ejecuta un traceroute a la dirección resuelta para ver dónde falla la ruta de red. Herramientas como TraceMapper combinan ambas perspectivas: resuelven el hostname y luego visualizan la ruta de red salto a salto, para que puedas descartar DNS y enfocarte en la ruta real.
Conclusiones clave
- Usa
dig +trace(odrill -T) para recorrer toda la cadena de delegación desde la raíz hasta el servidor de nombres autoritativo. - Verifica TTLs, servidores de nombres fuente y tiempos de consulta en cada nivel para identificar qué salto presenta problemas.
NXDOMAIN,SERVFAILy los saltos lentos apuntan a diferentes clases de problemas — delegación, salud del servidor de nombres o latencia.- Limpia las cachés locales y consulta varios resolutores públicos al diagnosticar problemas de propagación.
- Después de descartar problemas DNS, un traceroute a la IP resuelta completa el cuadro diagnóstico.