🧭 El viaje de una consulta DNS
Escribes example.com y pulsas Enter. Antes de que llegue el primer byte de la web, hay que traducir ese nombre a una IP — y eso desata un viaje por la jerarquía del DNS: raíz → TLD → autoritativo. Recórrelo paso a paso.
La resolución, paso a paso
-
01 www.example.com? local
Tu navegador pregunta
Antes de conectar a nada, tu equipo necesita la IP de www.example.com. Se lo pide al resolver recursivo (el de tu ISP, o 1.1.1.1 / 8.8.8.8). Pero primero mira su caché.
La mayoría de las consultas ni salen de tu red: se responden desde caché en microsegundos. -
02 ¿ .com ? → raíz (.) consulta
Consulta a un servidor raíz (.)
Si no está en caché, el resolver empieza por arriba: pregunta a un servidor raíz por www.example.com.
Hay 13 identidades raíz (A–M), replicadas por anycast en cientos de servidores por todo el mundo. -
03 NS de .com respuesta
La raíz delega en .com
La raíz no conoce la IP, pero sabe quién gestiona .com: responde con los servidores de nombres (NS) del TLD.
La raíz solo delega. Nunca ve tu dominio final ni tu contenido: solo el «.com». -
04 ¿ example.com ? → TLD .com consulta
Consulta al servidor de .com
El resolver repite la pregunta, ahora a un servidor TLD de .com.
Cada nivel acerca un paso a la respuesta: es una jerarquía de delegación. -
05 NS de example.com respuesta
El TLD delega en el dominio
El servidor de .com refiere a los servidores autoritativos de example.com (los que fijó su dueño).
Quien controla los NS autoritativos controla las respuestas del dominio: por eso su seguridad importa tanto. -
06 ¿ www.example.com ? → autoritativo consulta
Consulta al servidor autoritativo
Última pregunta: el resolver interroga al servidor autoritativo de example.com, el que sí tiene la respuesta.
«Autoritativo» = la fuente de la verdad para ese dominio, no una copia en caché. -
07 A 93.184.216.34 · TTL 3600 respuesta
Registro A + TTL
El autoritativo devuelve el registro A (la IPv4; sería AAAA para IPv6) y un TTL: cuántos segundos se puede cachear.
El TTL es un equilibrio: alto = menos consultas pero cambios más lentos; bajo = al revés. -
08 cache + respuesta local
Cachea y te responde 🔗
El resolver guarda la respuesta (durante el TTL) y le da la IP a tu navegador. Ahora sí empieza la conexión (TCP y, si es HTTPS, el handshake TLS).
La próxima vez que alguien de tu red pida ese nombre, sale directo de la caché del resolver.
Sin JavaScript verás la resolución completa como artículo. Con JS, recórrela paso a paso (también con las flechas ← →).
🗄️ Caché y TTL
El viaje completo (raíz → TLD → autoritativo) ocurre una vez; luego la respuesta vive en la caché del resolver durante su TTL. Por eso la mayoría de consultas se responden al instante y sin salir de tu red.
🪜 Jerarquía y delegación
Nadie tiene «toda» la guía: la raíz delega en el TLD, y el TLD en el autoritativo, mediante registros NS. El resolver es el único que hace el trabajo recursivo; los demás solo refieren o responden.
🔒 Privacidad y autenticidad
El DNS clásico viaja en claro (UDP/53): tu ISP —y quien escuche— ve qué dominios pides. DoH/DoT lo cifran; DNSSEC firma las respuestas para que nadie te cuele una IP falsa (envenenamiento de caché).
Fuentes: RFC 1034/1035 · root-servers.org. Ya tienes la IP: lo siguiente es el handshake TLS. Y consulta los tipos de registro DNS.