Propagación de DNS: por qué tarda y cómo verificarla

Cambiaste la IP del dominio, guardaste, y el sitio sigue mostrando la versión vieja (o nada). Un compañero lo abre sin problema, tú no. La explicación popular es "el DNS se está propagando", como si el cambio viajara de servidor en servidor. En la práctica, nada viaja: lo que existe es una colección de cachés, cada una con su cronómetro.

Entender esto cambia lo que haces. En lugar de esperar sin saber qué, descubres qué caché todavía guarda el valor antiguo, cuánto le falta para expirar y si vale la pena limpiarla a mano.

¿Qué es, en realidad, la propagación de DNS?#

Cuando cambias un registro en el panel de tu proveedor de DNS, el cambio vale al instante en el servidor autoritativo, el que guarda la verdad sobre el dominio. El resto de internet solo se entera cuando necesita volver a preguntar.

Nadie avisa a los otros servidores. Los resolvedores (el de tu proveedor de internet, 8.8.8.8, 1.1.1.1) guardan cada respuesta en caché durante un tiempo y solo vuelven al autoritativo cuando ese tiempo se acaba. "Propagación" es el nombre informal de la ventana entre el cambio y la expiración de la última caché relevante.

Por eso el resultado varía según la persona. Dos personas en redes distintas consultan resolvedores distintos, que buscaron el registro en momentos distintos.

¿Qué es el TTL y por qué manda en el plazo?#

El TTL (time to live) es un número de segundos que acompaña a cada registro e indica durante cuánto tiempo un resolvedor puede reutilizar la respuesta sin volver a preguntar. La documentación de Cloudflare resume el equilibrio: un TTL largo genera más aciertos de caché y consultas más rápidas, pero retrasa la propagación de los cambios.

Ejemplo: el registro A de ejemplo.com tiene TTL 3600. Un resolvedor lo consultó a las 10:00. Si cambias la IP a las 10:05, ese resolvedor sigue entregando la IP antigua hasta las 11:00. Otro, que consultó a las 10:50, solo se actualiza a las 11:50. El peor caso es, por lo tanto, el TTL antiguo completo contado desde el cambio.

Dos consecuencias prácticas:

• El TTL que cuenta es el del registro antiguo. Bajar el TTL después de cambiar la IP no ayuda a quien ya guardó la respuesta.
• 300 segundos (5 minutos) es un valor por defecto común. Los proveedores suelen imponer un mínimo, que puede variar según el plan; revisa la documentación del tuyo.

¿En qué lugares queda guardado el registro antiguo?#

Una consulta pasa por varias capas, y cualquiera puede retener el valor viejo:

1. Navegador. Mantiene una caché de DNS propia durante unos instantes.
2. Sistema operativo. Windows, macOS y muchas distribuciones Linux tienen una caché local.
3. Router de casa o de la empresa. Muchos actúan como proxy DNS y guardan respuestas.
4. Resolvedor recursivo. El del proveedor de internet, o uno público como 8.8.8.8 (Google) y 1.1.1.1 (Cloudflare). Es la caché más importante, compartida por miles de usuarios.
5. Servidores autoritativos. No son caché: responden con la verdad actual.

Hay un caso más lento: el cambio de nameservers (los servidores NS que el registrador informa a la zona padre, como .com). Esa delegación tiene su propio TTL, definido por quien opera el TLD, y suele ser bastante mayor que el de un registro A. En los cambios de proveedor de DNS, reserva horas, en algunos casos hasta dos días, y mantén los registros idénticos en los dos proveedores durante la transición.

¿Y si el nombre todavía no existía (caché negativa)?#

Si alguien consultó el nombre antes de que crearas el registro, el resolvedor puede haber guardado la respuesta "no existe" (NXDOMAIN). Esto se llama caché negativa y está en la RFC 2308: el tiempo es el menor valor entre el TTL del registro SOA de la zona y el campo MINIMUM de ese mismo SOA.

Por eso, a veces, un nombre recién creado sigue dando error durante algunos minutos u horas, aunque el registro ya esté correcto en el autoritativo. Si viste ese error en el navegador, mira DNS_PROBE_FINISHED_NXDOMAIN.

¿Cómo verificar el estado de la propagación?#

El método fiable es preguntar a cada capa y comparar. Usa dig (Linux, macOS, Windows con BIND o WSL) o nslookup (ya viene en Windows).

1. Descubre el autoritativo y consúltalo directamente. Es la referencia:

dig NS ejemplo.com +short
ns1.proveedor-dns.example.
ns2.proveedor-dns.example.

dig @ns1.proveedor-dns.example ejemplo.com A +short
203.0.113.10

Si aquí ya aparece el valor nuevo (203.0.113.10 en el ejemplo), tu configuración está bien y el resto es caché. Si aparece el antiguo, el cambio no se guardó, o editaste el DNS en un proveedor que no es el de los nameservers actuales (la causa más común de "nunca se propaga").

2. Consulta resolvedores públicos. Cada uno tiene su caché:

dig @8.8.8.8 ejemplo.com A
dig @1.1.1.1 ejemplo.com A

En la sección ANSWER, el número entre el nombre y el tipo es el TTL restante de esa caché. Ejecútalo dos veces: el valor baja. Cuando llega a cero, el resolvedor busca el registro nuevo.

ejemplo.com.    1742    IN    A    198.51.100.7

Aquí, ese resolvedor todavía entrega la IP antigua durante 1742 segundos más (unos 29 minutos).

3. En Windows sin dig:

nslookup ejemplo.com 8.8.8.8
nslookup -type=NS ejemplo.com

4. Mira el camino completo. dig +trace ejemplo.com parte de los servidores raíz y muestra cada delegación hasta el autoritativo, ignorando las cachés intermedias.

Los sitios de "comprobación global de DNS" hacen esta misma comparación en varios países a la vez. Sirven para tener una visión amplia, pero el resultado vale solo para los resolvedores que consultan, no para el proveedor de internet de una persona concreta.

¿Cómo acelerar o esquivar la espera cuando tarda?#

Limpia la caché local. Esto resuelve tu computadora, no el mundo:

En Windows:

ipconfig /flushdns

En macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

En Linux con systemd-resolved:

sudo resolvectl flush-caches

Reinicia el navegador después, o prueba en una ventana de incógnito. ipconfig /flushdns descarta incluso las entradas de caché negativa, según la documentación de Microsoft.

Pide al resolvedor público que olvide el nombre. Google tiene una herramienta Flush Cache para Google Public DNS, y Cloudflare tiene Purge Cache para 1.1.1.1. Indicas el dominio (en Cloudflare, también el tipo de registro). Esto afecta solo a ese resolvedor, pero ayuda mucho a quien usa 8.8.8.8 o 1.1.1.1.

Prueba por otro camino. Los datos móviles del celular usan otro resolvedor, y una VPN también. Si funciona por ahí, la culpable es tu caché.

Esquiva la espera. Para probar el hosting antes de que el DNS valga, fuerza la IP en tu computadora solo en esa solicitud:

curl --resolve ejemplo.com:443:203.0.113.10 https://ejemplo.com/

¿Cómo planificar un cambio sin quedarte fuera de línea?#

El truco es actuar antes, porque lo que manda es el TTL antiguo:

1. Con una antelación igual al TTL actual (un día, si es 86400), reduce el TTL del registro a 300 segundos.
2. Espera a que pase el TTL antiguo, para que todas las cachés ya estén en el régimen corto.
3. Cambia el valor del registro.
4. Confírmalo con dig en el autoritativo y en 8.8.8.8 y 1.1.1.1.
5. Cuando todo esté estable, sube el TTL de nuevo para reducir consultas.

Si puedes, deja el servidor antiguo en línea, respondiendo con normalidad, hasta el final de la ventana. Así, quien todavía ve la IP vieja se encuentra con el sitio funcionando.

Para saber más sobre los tipos de registro que vas a editar, mira qué son los registros DNS y cómo apuntar un dominio a tu hosting.

Cómo hacerlo en Square Cloud#

El dominio personalizado en Square Cloud está disponible a partir del plan Standard. El panel te muestra los registros DNS que tienes que crear, y tú los creas en tu registrador. El dominio sigue registrado a tu nombre en el registrador, y Square Cloud no es registrador ni proveedor de DNS: el TTL y la caché que viste arriba son los de tu proveedor de DNS.

La validación aparece en tiempo real: después de que creas los registros, el panel indica cuándo los encontró, así que no necesitas ejecutar dig a ciegas, aunque el comando sigue siendo la mejor forma de ver qué responde cada resolvedor. El TLS se emite automáticamente, y el panel también permite hacer una purga de caché.

Mientras el dominio no esté validado, la aplicación web sigue accesible por el subdominio *.squareweb.app con HTTPS, disponible en todos los planes. Mira cómo configurarlo en dominios en Square Cloud.