El proceso completo de resolución DNS: ¿cuántos saltos hay del navegador al servidor raíz?

1. El flujo completo en 8 pasos

┌─────────────────────────────────────────────────────────────┐
│  Navegador (Chrome / Firefox): escribes google.com          │
└────────────────┬────────────────────────────────────────────┘
                 │ ① Caché DNS del navegador (Chrome ~60s)
                 ↓ fallo
┌─────────────────────────────────────────────────────────────┐
│  Resolutor stub del SO + caché DNS del sistema              │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Fallo en la caché del sistema → envía una consulta UDP al router
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Reenvío DNS del router doméstico + caché del router        │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Fallo en la caché del router → reenvía al resolutor recursivo del ISP
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ISP / recursivo público (1.1.1.1 / 8.8.8.8 / 223.5.5.5)    │
│  Acierto de caché: responde directamente; todo tarda 1-5ms  │
│  Fallo de caché: pasa a la "consulta completa" de abajo     │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Pregunta al NS raíz "¿dónde está google.com?"
                 ↓
        13 grupos de servidores raíz (a~m.root-servers.net)
                 │ ⑤ Responde "No lo sé, pregunta al NS de .com: a.gtld-servers.net"
                 ↓
        Servidores autoritativos del TLD .com (Verisign)
                 │ ⑥ Responde "Yo tampoco lo tengo todo, pregunta al NS de google.com: ns1.google.com"
                 ↓
        Servidores autoritativos de google.com (operados por la propia Google)
                 │ ⑦ Responde "El registro A de google.com = 142.250.x.x"
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ El resolutor recursivo guarda la respuesta en caché      │
│     (según el TTL) y la devuelve al cliente; cada capa del  │
│     camino también guarda su propia copia                   │
└─────────────────────────────────────────────────────────────┘

Idea clave: en la práctica, el flujo completo de 8 pasos casi nunca se produce. Las direcciones IP de los grandes sitios casi siempre están en la caché del resolutor recursivo, así que a un usuario normal la respuesta le llega en el paso ④. Solo los dominios poco conocidos, los sitios que se visitan rara vez, los TTL caducados o los dominios recién registrados activan el flujo completo.

2. Las 5 capas de caché DNS, explicadas

Cuando se diseñó DNS en 1983, ya se tuvo en cuenta un hecho: las consultas superan a los cambios en un factor de 100 000. Por eso hay cachés por todas partes, y cada capa conserva los datos durante un periodo TTL (Time To Live).

3. Consultas recursivas frente a iterativas: conceptos clave

3.1 Recursiva

El cliente (navegador / stub del SO) le dice al resolutor recursivo del ISP: "Encuéntrame la IP de google.com; no me importa cómo lo hagas". El resolutor recursivo tiene que completar toda la consulta y devolver el resultado final.

3.2 Iterativa

Cuando el resolutor recursivo habla con los servidores raíz, del TLD y autoritativos, ese intercambio es iterativo: pregunta a la raíz, la raíz responde "pregunta a .com", va y pregunta a .com, .com responde "pregunta a google", y va y pregunta a google. Cada paso solo avanza un nivel; no se trata de "pregunto a la raíz y la raíz se encarga de todo por mí".

4. Pruébalo tú mismo: dig +trace

dig +trace fuerza una consulta iterativa completa y muestra cada paso:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Salto 1: consulta a la raíz (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 registros NS raíz)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Salto 2: consulta al TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (los 4 NS de .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Salto 3: consulta a los servidores autoritativos de cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Por fin se obtiene la respuesta
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Desglose:

• Todo el proceso tardó 5 + 121 + 53 + 12 = 191 ms: la primera consulta en frío es realmente lenta
• Pero consultar el mismo dominio un segundo después solo tarda 1-2 ms, porque la caché recursiva del ISP ya lo tiene (TTL de 300 segundos)
• 104.21.x.x / 172.67.x.x son direcciones de la CDN de Cloudflare: la IP de origen real de nuestro sitio queda oculta tras la CDN

5. El TTL explicado: cuánto dura realmente la caché

El TTL (Time To Live) es el campo con el que el servidor autoritativo indica a cada resolutor recursivo "puedes guardarlo en caché como máximo este tiempo", medido en segundos.

Atención: el TTL es el "tiempo máximo de caché": cada resolutor puede vaciar su caché antes, pero nunca alargarlo. Así que, aunque el TTL autoritativo sea de 1 hora, algunos resolutores pueden volver a consultar al cabo de solo 10 minutos.

Trampa: antes de cambiar de IP, acorta primero el TTL (1-5 minutos) y espera a que caduque por completo el TTL anterior antes de hacer el cambio; si no, algunos usuarios seguirán llegando a la IP antigua durante más de una hora.

6. Referencia rápida de tipos de registro DNS

7. Optimización de DNS: cómo acelerar la resolución

7.1 Elige un resolutor recursivo cercano

China continental: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) son los que más rápido resuelven los sitios chinos. En otros lugares: 1.1.1.1 (Cloudflare, con la mayor cobertura anycast) / 8.8.8.8 (Google). Consulta eldirectorio de resolutores de DNS público.

7.2 Activa DoH (DNS-over-HTTPS)

Cifrar las consultas DNS mediante HTTPS impide que los ISP las vean o las manipulen (bloquea el secuestro de NXDOMAIN). Chrome, Firefox y Edge lo admiten: basta con activarlo en la configuración.

7.3 Resuelve por adelantado (DNS Prefetch)

Añade <link rel="dns-prefetch" href="//api.example.com"> al <head> de tu sitio para que el navegador lo resuelva mientras está inactivo: cuando llegue la solicitud real, será un acierto de caché.

7.4 Usa una CDN + NS Anycast

Pon tus NS autoritativos en Anycast (Cloudflare / Route 53) para que los usuarios de todo el mundo lleguen a la instancia más cercana: la latencia del paso ③ baja de 100ms a 10ms.

7.5 Configura el TTL con criterio

Usa un TTL largo (1-7 días) para los registros que cambian poco (NS / MX) y uno corto (5-60 minutos) para los registros A que puedan tener que cambiar.

8. Preguntas frecuentes

8.1 Cambié el DNS, pero no surte efecto: ¿por qué?

Primero, piensa en el TTL actual. Después de cambiar el DNS, todos los resolutores recursivos seguirán devolviendo la IP antigua hasta que caduque el TTL anterior. La "propagación global" suele tardar unas 2 veces el TTL (porque los resolutores no están sincronizados entre sí).

• Cliente: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Esperar a que caduque la caché de un resolutor recursivo público: 1.1.1.1 / 8.8.8.8 ofrecen cada uno su propia herramienta de "purge" para vaciarla manualmente

8.2 Algunos usuarios pueden acceder y otros no: contaminación de DNS

Es habitual al acceder a sitios extranjeros desde China continental: el GFW inyecta respuestas DNS falsas o los ISP secuestran las consultas. Cambiar a DoH (DNS cifrado en el navegador) permite eludir la mayor parte de la contaminación de DNS.

8.3 ¿Cuánto tarda un dominio en poder usarse después de registrarlo?

Tras registrar el dominio, el registro del TLD (registry) publica tus registros NS en los servidores autoritativos de nivel superior de .com / .net, etc.; normalmente tarda entre 15 minutos y 24 horas. Los dominios .cn / .com.cn pueden requerir la inscripción ICP (ICP filing) antes de resolverse dentro de China continental.