Cómo funciona el DNS

Escribes mitienda.com en el navegador y, en menos de 100 milisegundos, tu computadora ya sabe que tiene que conectarse a 203.0.113.10. ¿Quién le dijo? ¿Por qué a veces un cambio se ve al instante y otras tarda horas? ¿Qué es eso de "esperar a que propague"?

En esta lección vas a entender el viaje completo de una consulta DNS, paso a paso, con todos los personajes que intervienen. Cuando entiendas esto, dejarás de "esperar 48 horas porque sí" y empezarás a diagnosticar de verdad.

Concepto

La analogía: preguntar una dirección en una ciudad enorme

Imagina que llegas a una ciudad gigante y quieres ir a "la tienda de Ana en la calle Comercio". No sabes dónde está, así que:

1. Le preguntas al recepcionista de tu hotel (el resolver recursivo). Él se encarga de averiguarlo por ti.
2. El recepcionista no lo sabe, así que llama a la oficina central de la ciudad (los servidores raíz): "¿quién sabe de la zona Comercio?". Le responden: "pregunta en la oficina de la zona Comercio, este es su teléfono".
3. Llama a la oficina de zona (los servidores del TLD, por ejemplo .com): "¿quién sabe de la tienda de Ana?". Le responden: "eso lo lleva la administración del edificio de Ana, este es su teléfono".
4. Llama a la administración del edificio (los nameservers autoritativos, por ejemplo Cloudflare): "¿dónde está la tienda de Ana?". Respuesta definitiva: "local 203.0.113.10".
5. El recepcionista te da la dirección y la anota en su libreta (la caché) para la próxima vez que alguien pregunte, durante un tiempo limitado (el TTL).

Nadie en internet tiene "la lista completa" de todos los dominios. El sistema funciona delegando: cada nivel solo sabe a quién preguntarle en el siguiente.

Los personajes

Personaje	Qué hace	Ejemplos reales
Cliente / stub resolver	Tu sistema operativo; hace la pregunta y espera la respuesta	Windows, Android, el navegador
Resolver recursivo	Hace todo el trabajo de preguntar nivel por nivel y guarda caché	El de tu proveedor de internet, 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.9 (Quad9)
Servidores raíz	Saben quién administra cada TLD	13 nombres (a.root-servers.net a m.root-servers.net) con cientos de copias en el mundo
Servidores del TLD	Saben qué nameservers tiene cada dominio de su terminación	Para .com: a.gtld-servers.net...
Nameservers autoritativos	Tienen la zona con los registros reales del dominio	ana.ns.cloudflare.com, bob.ns.cloudflare.com

Autoritativo vs recursivo

• El autoritativo es la fuente de la verdad de un dominio: guarda los registros. No pregunta a nadie.
• El recursivo no es dueño de nada: pregunta en nombre tuyo y recuerda respuestas.

Cuando editas un registro en Cloudflare, cambias el autoritativo. Los recursivos del mundo se enteran cuando su caché expira.

La resolución paso a paso

Esto pasa cuando alguien en Guadalajara abre www.mitienda.com por primera vez (sin nada en caché):

 Navegador / Windows                Resolver recursivo (p. ej. 1.1.1.1)
 ───────────────────                ───────────────────────────────────
 1. "¿IP de www.mitienda.com?" ───►
                                    2. Pregunta a un servidor RAÍZ:
                                       "¿www.mitienda.com?"
                                    ◄─ "No sé, pero .com lo llevan
                                        a.gtld-servers.net y otros" (referencia)

                                    3. Pregunta al servidor de .COM:
                                       "¿www.mitienda.com?"
                                    ◄─ "No sé, pero mitienda.com lo llevan
                                        ana.ns.cloudflare.com y
                                        bob.ns.cloudflare.com" (referencia NS)

                                    4. Pregunta a ana.ns.cloudflare.com:
                                       "¿www.mitienda.com, tipo A?"
                                    ◄─ "203.0.113.10, TTL 300" (respuesta
                                        AUTORITATIVA)

                                    5. Guarda en caché 300 segundos
 6. ◄── "203.0.113.10" ─────────────
 7. El navegador abre conexión HTTPS con 203.0.113.10

Observa tres cosas:

1. Los servidores raíz y del TLD no saben la IP: solo dan referencias ("pregunta allá").
2. Los nameservers que aparecen en el paso 3 son los que configuraste en tu registrador. Por eso cambiar nameservers es tan poderoso: cambia a quién se le pregunta.
3. El resolver también guarda en caché las referencias de .com (por días), así que la mayoría de consultas reales se saltan los pasos 2 y 3.

Con caché (lo que pasa el 99% de las veces)

 Navegador ─► caché del navegador     ¿lo tengo? sí → listo
            └► caché de Windows       ¿lo tengo? sí → listo
               └► resolver 1.1.1.1    ¿lo tengo y no expiró? sí → responde al instante
                  └► (solo si no) pregunta a ana.ns.cloudflare.com

Hay varias capas de caché: navegador, sistema operativo, a veces el router de tu casa, el resolver de tu proveedor. Cada una respeta (más o menos) el TTL.

TTL: el tiempo de vida en caché

El TTL (Time To Live) es un número en segundos que va con cada registro y dice: "puedes recordar esta respuesta durante X segundos; después vuelve a preguntar".

TTL	Equivale a	Cuándo usarlo
60	1 minuto	Migraciones en curso, pruebas
300	5 minutos	Registros que podrías cambiar pronto
3600	1 hora	Valor estándar estable
86400	1 día	Registros que casi nunca cambian (NS en el TLD suelen tener 2 días)
Auto (Cloudflare)	300 s	Valor por defecto en Cloudflare

El TTL de los registros "naranja" en Cloudflare

Cuando un registro está proxied (nube naranja) en Cloudflare, el TTL siempre es Auto (300 s) y lo que se responde son IP de Cloudflare, no las tuyas. Esto lo verás en Cloudflare desde cero.

La trampa del TTL: se aplica al valor VIEJO

Si tu registro A tiene TTL 86400 (un día) y lo cambias hoy, los resolvers que ya lo tenían en caché seguirán usando la IP vieja hasta un día. Bajar el TTL en el momento del cambio no ayuda a los que ya guardaron la respuesta vieja.

Plan correcto para migrar mitienda.com a un hosting nuevo:

  Día -1   Baja el TTL del registro A de 86400 a 300
           (y espera a que pase el TTL viejo: 1 día)
  Día 0    Cambia la IP. En máximo ~5 minutos todos ven la nueva
  Día +1   Si todo va bien, sube el TTL otra vez (3600 o Auto)

"Propagación" explicada de verdad

Seguro has leído "los cambios de DNS tardan hasta 48 horas en propagarse". La frase es engañosa. El DNS no "se propaga": nadie empuja tu cambio por el mundo. Lo que ocurre es:

1. Tu cambio queda guardado al instante en los nameservers autoritativos (en Cloudflare, en segundos).
2. Cada resolver del mundo tiene (o no) una copia vieja en caché.
3. Cada copia vieja caduca cuando se acaba su TTL. Hasta entonces, ese resolver sigue dando el dato viejo.

Por eso dos personas ven cosas distintas al mismo tiempo: usan resolvers diferentes, con cachés de distinta antigüedad.

Tipo de cambio	Cuánto tarda realmente	Por qué
Crear un registro nuevo que nadie había consultado	Casi inmediato	No hay caché vieja (salvo caché "negativa", ver abajo)
Cambiar un registro existente	Hasta el TTL que tenía	Hay que esperar a que caduquen las copias
Cambiar nameservers en el registrador	Minutos a 24–48 h	El TLD (.com) entrega los NS con TTL de hasta 2 días
Consultar un nombre antes de crearlo	Hasta el TTL negativo del SOA	El resolver guardó "no existe" (NXDOMAIN)

Error común: la caché negativa

Si consultas tienda.mitienda.com antes de crearlo, el resolver guarda la respuesta "no existe" durante un tiempo (definido en el registro SOA, en Cloudflare suele ser corto, alrededor de 30 min). Si luego lo creas, puede parecer que "no propaga". Solución: no lo pruebes antes de crearlo o consulta directo al autoritativo.

Cómo saber si ya "propagó"

La clave: pregunta directamente al autoritativo. Si el autoritativo ya responde el valor nuevo, tu configuración está bien; lo demás es solo caché que caducará sola.

Linux / macOS

# 1) ¿Qué dice la fuente de la verdad?
dig @ana.ns.cloudflare.com mitienda.com A +short

# 2) ¿Qué dicen resolvers públicos?
dig @1.1.1.1 mitienda.com A +short
dig @8.8.8.8 mitienda.com A +short

# 3) Ver el TTL restante en caché (segunda columna numérica)
dig @8.8.8.8 mitienda.com A +noall +answer
# mitienda.com.  2841  IN  A  203.0.113.10
#                └─ quedan 2841 s para que este resolver vuelva a preguntar

Windows

# 1) Preguntar al autoritativo
nslookup mitienda.com ana.ns.cloudflare.com

# 2) Preguntar a resolvers públicos
nslookup mitienda.com 1.1.1.1
nslookup mitienda.com 8.8.8.8

# 3) Ver TTL con PowerShell
Resolve-DnsName mitienda.com -Type A -Server 8.8.8.8 | Format-Table Name,TTL,IPAddress

# Borrar la caché DNS de tu PC
ipconfig /flushdns

Herramientas visuales

• whatsmydns.net: muestra la respuesta desde decenas de países a la vez.
• La herramienta de consulta DNS del curso: consulta registros en vivo sin abrir la terminal.
• Cloudflare tiene una página para purgar la caché de 1.1.1.1: one.one.one.one/purge-cache. Google tiene una similar: dns.google/cache.

Jerarquía de nombres y FQDN

El DNS es un árbol invertido. Arriba está la raíz, que se escribe como un simple punto .:

                          . (raíz)
            ┌─────────────┼──────────────┐
           com            mx             org
       ┌────┴────┐     ┌──┴───┐           │
   mitienda   google  com    gob      wikipedia
   ┌──┴───┐            │
  www   tienda      mitienda      ← mitienda.com.mx
                    
  www.mitienda.com.  se lee: www → dentro de mitienda → dentro de com → dentro de la raíz

FQDN y el punto final

Un FQDN (Fully Qualified Domain Name, nombre de dominio completamente calificado) es el nombre completo hasta la raíz, y técnicamente termina en punto:

www.mitienda.com.      ← FQDN (el punto final es la raíz)
www.mitienda.com       ← así lo escribimos normalmente; el punto se sobreentiende

¿Por qué te importa ese punto? Porque en archivos de zona (BIND, algunos paneles de hosting como el Zone Editor de cPanel), un nombre sin punto final se considera relativo y se le agrega el dominio:

; En un archivo de zona de mitienda.com
www   CNAME  mitienda.com.     ; correcto → apunta a mitienda.com
www   CNAME  mitienda.com      ; ERROR → se interpreta como mitienda.com.mitienda.com

¿Y en Cloudflare?

El panel de Cloudflare es más amable: escribes www en el nombre y mitienda.com en el destino sin punto, y él lo completa correctamente. Pero en cPanel, en archivos de zona exportados o en servidores DNS propios, el punto final importa. Si ves en dig respuestas como mitienda.com.mitienda.com, alguien olvidó el punto.

Etiquetas y límites

• Cada parte entre puntos se llama etiqueta (www, mitienda, com).
• Cada etiqueta: máximo 63 caracteres; el nombre completo: máximo 253.
• Caracteres permitidos: letras a-z, números y guion (no al inicio ni al final).
• Las mayúsculas no importan: MiTienda.COM es lo mismo que mitienda.com.
• Los dominios con acentos o ñ (piñata.mx) se convierten internamente a Punycode: xn--piata-pta.mx.

Resolvers públicos

Por defecto usas el resolver de tu proveedor de internet (Telmex, Totalplay, Izzi...), que a veces es lento, guarda caché de más o bloquea sitios. Puedes cambiarlo por uno público:

Resolver	IPv4	IPv6	Característica
Cloudflare	1.1.1.1, 1.0.0.1	2606:4700:4700::1111	Muy rápido, enfocado en privacidad
Cloudflare for Families	1.1.1.3, 1.0.0.3	—	Bloquea malware y contenido adulto
Google	8.8.8.8, 8.8.4.4	2001:4860:4860::8888	Muy estable
Quad9	9.9.9.9	2620:fe::fe	Bloquea dominios maliciosos

DoH y DoT

Las consultas DNS tradicionales viajan sin cifrar por el puerto 53: tu proveedor puede ver qué sitios visitas. DNS over HTTPS (DoH) y DNS over TLS (DoT) las cifran. Chrome, Firefox, Windows 11 y Android ("DNS privado") ya lo soportan. Para administrar dominios no necesitas configurarlo, pero es bueno saber que existe.

Para cambiar el resolver en Windows 11: Configuración → Red e Internet → Wi-Fi (o Ethernet) → Propiedades del hardware → Asignación de servidor DNS → Editar → Manual, activa IPv4 y escribe 1.1.1.1 y 1.0.0.1 (el texto exacto de los menús puede variar según la versión).

Ver el camino completo con dig +trace

dig +trace hace lo mismo que un resolver recursivo pero mostrándote cada paso. Es la mejor forma de ver la teoría en acción:

dig +trace www.mitienda.com

Salida simplificada y comentada:

.                 518400  IN  NS  a.root-servers.net.      ← 1) servidores raíz
...
com.              172800  IN  NS  a.gtld-servers.net.      ← 2) la raíz delega .com
...
mitienda.com.     172800  IN  NS  ana.ns.cloudflare.com.   ← 3) .com delega mitienda.com
mitienda.com.     172800  IN  NS  bob.ns.cloudflare.com.      (TTL 2 días: por eso
                                                               cambiar NS tarda)
www.mitienda.com.    300  IN  A   203.0.113.10             ← 4) respuesta autoritativa
;; Received 61 bytes from 172.64.32.1#53(ana.ns.cloudflare.com)

En Windows no hay +trace en nslookup, pero puedes imitarlo preguntando nivel por nivel:

# 1) ¿Quién lleva .com? (preguntando a un servidor raíz)
nslookup -type=NS com a.root-servers.net

# 2) ¿Qué NS tiene mitienda.com según .com?
nslookup -type=NS mitienda.com a.gtld-servers.net

# 3) Pregunta final al autoritativo
nslookup -type=A www.mitienda.com ana.ns.cloudflare.com

Instala dig en Windows

Si quieres dig en Windows, usa WSL (Ubuntu) y ejecuta sudo apt install dnsutils, o instala BIND para Windows. Con Git Bash no viene incluido.

Casos reales

"A mí me abre el sitio nuevo y a mi cliente el viejo"

Cambiaste la IP del registro A de mitienda.com hace 20 minutos. Su TTL era 3600. Tú usas 1.1.1.1 (que justo no lo tenía en caché) y tu cliente usa el resolver de su proveedor, que lo guardó hace 10 minutos. Le quedan 50 minutos de dato viejo. Solución: esperar, o que tu cliente haga ipconfig /flushdns y cambie a 1.1.1.1. No hay nada roto.

"Cambié los nameservers hace 3 horas y sigue saliendo el hosting viejo"

Los NS en el TLD tienen TTL de hasta 48 h. Revisa:

# ¿Qué NS anuncia ya el registro de .com? (esto es lo que importa)
dig +short NS mitienda.com @a.gtld-servers.net

Si ya salen ana y bob de Cloudflare, el cambio está hecho; solo falta que caduquen cachés.

"Cloudflare dice que mi dominio está pendiente (Pending)"

Cloudflare revisa periódicamente si el TLD ya anuncia sus nameservers. Si en el comando anterior siguen saliendo los NS viejos, el problema está en el registrador (no guardaste el cambio o escribiste mal un nameserver). Lo verás en la lección 3.

Ejercicios

1. Explica con tus palabras la diferencia entre un resolver recursivo y un nameserver autoritativo.
2. Ejecuta dig +trace github.com (o la versión por pasos con nslookup en Windows) e identifica: la raíz, el TLD y los nameservers autoritativos.
3. El registro A de mitienda.com tiene TTL 86400. Mañana a las 10:00 migras a un hosting nuevo. Escribe el plan con horarios.
4. ¿Qué devuelve un archivo de zona de mitienda.com si escribes CNAME tienda shops.myshopify.com sin punto final?
5. Un amigo dice: "el DNS tarda 48 horas en propagarse siempre". Corrige la frase.

Ver solución

1. El recursivo (p. ej. 1.1.1.1) hace las preguntas por ti a raíz, TLD y autoritativo, y guarda caché. El autoritativo (p. ej. ana.ns.cloudflare.com) es la fuente de la verdad: tiene la zona del dominio y responde sin preguntar a nadie.
2. Raíz: líneas . con x.root-servers.net. TLD: líneas com. con x.gtld-servers.net. Autoritativos: las líneas github.com. NS ... (los nombres exactos cambian con el tiempo).
3. Plan:

Hoy 09:00      Bajar TTL del A de 86400 a 300.
Mañana 10:00   (ya pasaron más de 24 h: todas las cachés tienen TTL 300)
               Cambiar la IP del A al hosting nuevo.
Mañana 10:05   Comprobar: dig @ana.ns.cloudflare.com mitienda.com A +short
               y en whatsmydns.net.
Pasado mañana  Subir el TTL a 3600 (o Auto en Cloudflare).

4. Se interpreta como relativo: shops.myshopify.com.mitienda.com., un nombre que no existe. Lo correcto es shops.myshopify.com. con punto final.
5. "El DNS no se propaga: el cambio es inmediato en el autoritativo y cada resolver ve el valor nuevo cuando caduca su caché, es decir, según el TTL del registro. Las 24–48 h aplican sobre todo al cambio de nameservers, por el TTL alto que usan los TLD."

Resumen

• El DNS funciona por delegación: raíz → TLD → nameservers autoritativos.
• El resolver recursivo (1.1.1.1, 8.8.8.8, el de tu proveedor) pregunta por ti y guarda caché.
• El TTL dice cuántos segundos se recuerda una respuesta; bájalo antes de una migración.
• "Propagación" = caducidad de cachés. Pregunta al autoritativo para saber si tu cambio ya está bien.
• Un FQDN termina en punto; en archivos de zona, olvidar ese punto crea nombres absurdos.
• dig +trace y nslookup ... servidor son tus rayos X.
• Siguiente: Nameservers y zona DNS.