Cómo funciona el DNS: resolución recursiva, caché y TTL en un diagrama

Cambias un registro A, ejecutas dig y ves la dirección nueva. Una compañera en otra oficina sigue obteniendo la antigua una hora después. Un subdominio nuevo te funciona a ti y le devuelve NXDOMAIN a un cliente. Nada de esto es aleatorio: se deriva de cómo funcionan la resolución DNS y la caché, y en cuanto sabes dibujar el camino que sigue una consulta, puedes predecirlo.

Este artículo sigue una consulta desde el navegador hasta el servidor autoritativo y de vuelta, con un diagrama, y después trata los TTL, la caché negativa, la delegación, el transporte y los fallos que te encontrarás en producción.

Los cuatro roles de cada consulta

Una consulta pasa por hasta cuatro tipos de servidores. Cada uno conoce una parte distinta de la respuesta.

La raíz no es una sola máquina. Hay 13 identidades de servidores raíz, de a a m.root-servers.net, operadas por 12 organizaciones independientes, y el anycast las reparte en más de 2000 instancias por todo el mundo, según root-servers.org en noviembre de 2026.

Una consulta, paso a paso

Supongamos que tu navegador necesita app.example.com y que no hay nada en caché en ningún sitio:

1. El navegador revisa su propia caché y después pregunta al resolvedor stub del sistema operativo.
2. El stub envía una consulta con el indicador «recursion desired» al resolvedor recursivo configurado: ¿cuál es el registro A de app.example.com?
3. El resolvedor no tiene nada en caché, así que pregunta a un servidor raíz. La raíz no sabe la respuesta, pero sabe quién gestiona com, así que devuelve una referencia: los registros NS de com y sus direcciones (glue).
4. El resolvedor pregunta a un servidor TLD de com, que devuelve otra referencia: los servidores de nombres de example.com.
5. El resolvedor pregunta a uno de esos servidores autoritativos, que devuelve la respuesta: app.example.com. 300 IN A 203.0.113.10.
6. El resolvedor guarda en caché cada registro que ha aprendido durante su TTL y devuelve la respuesta al stub, que se la pasa al navegador.

El stub hace una consulta recursiva: quiere una respuesta final. El resolvedor hace consultas iterativas: cada servidor devuelve o la respuesta o un puntero a alguien más cercano a ella. Los servidores raíz y TLD nunca persiguen respuestas por ti.

Puedes ver la parte iterativa con dig +trace, que empieza en la raíz en lugar de usar la caché de tu resolvedor (salida recortada):

$ dig +trace app.example.com
.                  518400  IN  NS  a.root-servers.net.
com.               172800  IN  NS  a.gtld-servers.net.
example.com.       172800  IN  NS  ns1.example.net.
app.example.com.   300     IN  A   203.0.113.10

Los resolvedores modernos también aplican la minimización de QNAME (RFC 9156): preguntan a la raíz solo por com y al TLD solo por example.com, de modo que los servidores de más arriba nunca ven el nombre completo que consultaste.

Caché y TTL

Cada registro lleva un tiempo de vida (TTL) en segundos. Un resolvedor que guarda app.example.com en caché con un TTL de 300 responde desde la caché durante los cinco minutos siguientes, en cuenta atrás, y solo entonces vuelve a preguntar al servidor autoritativo. Los navegadores y los sistemas operativos mantienen además sus propias cachés cortas.

Esto es lo que la gente llama propagación. Cuando cambias un registro, no se envía nada a ninguna parte. Cada resolvedor que guardó el valor antiguo lo sigue sirviendo hasta que su copia caduca, así que el peor caso es aproximadamente el TTL antiguo, no el nuevo. Los resolvedores también recortan los TTL muy largos: Unbound, por ejemplo, limita por defecto los registros en caché a un día.

Reglas prácticas para los cambios:

• Baja el TTL antes de un cambio planificado. Si un registro tiene un TTL de 86400, ponlo en 300 al menos un día antes de la migración, espera a que pase el TTL antiguo, haz el cambio y después vuelve a subirlo.
• Usa TTL cortos solo donde necesites un failover rápido. Un TTL de 60 segundos significa más consultas a tu proveedor y más fallos de caché para los usuarios, y cada uno cuesta una resolución completa.
• Cambiar de servidores de nombres es más lento. Los registros NS de example.com en la zona padre tienen su propio TTL, 172800 segundos (dos días) en com, y no puedes acortarlo.

El failover basado en DNS depende de estas cifras. El diagrama de arquitectura multirregión de AWS y el diagrama de arquitectura de recuperación ante desastres muestran dónde encaja un registro DNS con health check y por qué su TTL limita tu tiempo de recuperación.

Caché negativa: la trampa del NXDOMAIN

Los resolvedores también guardan en caché el «no existe». Cuando falta un nombre, el servidor autoritativo devuelve NXDOMAIN con el registro SOA de la zona, y el resolvedor guarda esa respuesta negativa durante el menor de dos valores: el TTL del SOA y su campo MINIMUM (RFC 2308).

El fallo clásico: alguien consulta api.example.com antes de que exista el registro, un resolvedor guarda NXDOMAIN durante una hora, creas el registro y ese resolvedor sigue diciendo que no existe hasta que pasa la hora. Comprueba el TTL negativo con dig example.com SOA antes de anunciar un nombre de host nuevo, y crea los registros antes de que nadie los pruebe.

Delegación, glue y servidores cojos

Una zona existe en el DNS porque su zona padre se la delega. La zona com contiene registros NS que indican qué servidores son autoritativos para example.com. Si esos servidores de nombres viven dentro de la zona que sirven, como ns1.example.com, la zona padre también guarda sus direcciones como registros glue; si no, los resolvedores no podrían encontrarlos.

La delegación se rompe de dos formas habituales. Una delegación coja (lame delegation) es una zona padre que apunta a un servidor que ya no sirve la zona, a menudo tras un cambio de proveedor, y provoca timeouts o SERVFAIL a algunos usuarios. Una discrepancia entre los registros NS de la zona padre y los de la propia zona hace que el comportamiento dependa del conjunto que un resolvedor haya guardado en caché.

Transporte y privacidad

La mayor parte del tráfico DNS es UDP por el puerto 53. Las respuestas que no caben activan el indicador de truncamiento y el cliente reintenta por TCP, así que el puerto TCP 53 también debe estar abierto. Desde el DNS Flag Day 2020, el software DNS principal usa por defecto un tamaño de búfer EDNS de 1232 bytes para evitar la fragmentación IP, lo que hace más frecuente el paso a TCP en respuestas grandes como los registros firmados con DNSSEC.

El DNS clásico no va cifrado. DNS over TLS (puerto 853), DNS over HTTPS y DNS over QUIC cifran el tramo entre el stub y el resolvedor recursivo; los tramos del resolvedor a los servidores raíz, TLD y autoritativos siguen siendo, en su mayoría, texto plano.

DNSSEC resuelve otro problema: la autenticidad, no la privacidad. Cada zona firma sus registros, y la zona padre avala la clave de la zona hija, hasta llegar a la clave raíz en la que confían los resolvedores que validan. El 11 de octubre de 2026, la zona raíz completó la renovación a una nueva clave de firma de claves, KSK-2024. Un resolvedor que valida y que nunca incorporó el nuevo ancla de confianza falla en cada consulta con SERVFAIL.

Cuando fallan las consultas

Preguntar directamente al servidor autoritativo con dig @ns1.example.net app.example.com te dice cuál es la verdad; preguntar a un resolvedor te dice lo que ven los usuarios.

El diagrama de resolución DNS

Cómo leerlo:

• Empieza por el portátil. Su resolvedor stub envía una consulta recursiva al resolvedor (paso 1) y recibe una respuesta (paso 8).
• El resolvedor hace el recorrido. Los pasos 2 a 7 son consultas iterativas: la raíz y los servidores de com devuelven referencias, y el servidor autoritativo de example.com devuelve el registro.
• Los TTL van en las respuestas. El registro A vuelve con un TTL de 300 segundos; es el tiempo que el resolvedor lo reutilizará sin volver a preguntar.
• El marco agrupa la jerarquía que no operas tú, salvo el servidor autoritativo, que es tuyo o de tu proveedor de DNS.
• El bloque Markdown enumera las capas de caché y los TTL que deciden lo rápido que un cambio llega a los usuarios.

Dibujar diagramas de DNS que respondan preguntas reales

• Numera los pasos. Las preguntas sobre DNS tratan del orden: quién pregunta a quién y cuándo responde la caché en su lugar.
• Separa el tráfico recursivo del iterativo. Una consulta del cliente, varias del resolvedor. Si se ven iguales, el diagrama esconde la idea más importante.
• Escribe los TTL en las respuestas. Explican la propagación mejor que un párrafo.
• Muestra a quién pertenece cada cosa. Marca los servidores que controlas. Durante un incidente, eso decide a quién llamas.
• Dibuja el cambio de registro como un diagrama aparte. Una línea temporal de migración con el TTL rebajado, el corte y el TTL subido de nuevo es más clara que unas anotaciones sobre el diagrama de resolución.

Si lo importante es el orden de los mensajes, también sirve un diagrama de secuencia, con el resolvedor y cada servidor como líneas de vida. Para la parte física, dónde se sitúan los resolvedores en tu red, consulta la guía del diagrama de topología de red.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade un nodo Dispositivo del pack Red para el portátil y un nodo DNS para el resolvedor recursivo.
3. Añade un Marco del pack Básico con el nombre de la jerarquía DNS y coloca dentro tres nodos DNS más: la raíz, el TLD com y el servidor autoritativo de example.com.
4. Añade un nodo Servidor del pack Red para app.example.com, el host al que se conecta el navegador después de la consulta.
5. Dibuja las aristas en orden y numera sus etiquetas: la consulta del cliente y su respuesta, y luego una consulta y una respuesta entre el resolvedor y cada servidor. Pon el TTL en la respuesta final.
6. Añade un bloque Markdown del pack Básico con las capas de caché y las reglas de TTL.

El ejemplo usa 8 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Cuánto tarda la propagación DNS? Hasta el TTL del registro antiguo, en cada resolvedor que lo guardó en caché. No se envía nada; las cachés caducan. Los cambios de servidores de nombres tardan más porque los registros NS de la zona padre tienen su propio TTL, dos días en com.

¿Qué diferencia hay entre un servidor DNS recursivo y uno autoritativo? Un resolvedor recursivo encuentra respuestas en nombre de los clientes y las guarda en caché. Un servidor autoritativo tiene los registros de una zona y solo responde por esa zona.

¿Por qué sigo viendo la IP antigua después de cambiar un registro? Una caché entre tú y el servidor autoritativo todavía tiene el registro antiguo: tu navegador, tu sistema operativo o tu resolvedor. Consulta directamente el servidor autoritativo para confirmar el cambio y después espera a que se agote el TTL.

¿Un TTL muy bajo es un problema? Cuesta más consultas a tu proveedor de DNS y más resoluciones completas para los usuarios, lo que añade latencia en los fallos de caché. Usa TTL bajos en los registros que quizá tengas que conmutar y más largos en los registros estables.

¿El tráfico DNS va cifrado? No por defecto. DNS over TLS, HTTPS o QUIC cifra el tramo entre tu dispositivo y el resolvedor. DNSSEC añade firmas que demuestran que los registros son auténticos, pero no cifra nada.

Empieza gratis — un puesto, sin tarjeta de crédito.