Tiempo de propagación DNS: cuánto tarda de verdad y cómo acelerarlo
Los cambios DNS no se envían a ninguna parte: las respuestas antiguas simplemente caducan en las cachés. Descubre qué controla el tiempo de propagación DNS y cómo hacer que tu próximo cambio se aplique en minutos.

El tiempo de propagación DNS es el retraso entre guardar un cambio DNS y que todos los resolvedores de internet devuelvan la nueva respuesta. Para una edición normal de un registro suele ir de unos minutos hasta el TTL antiguo del registro; para un cambio de nameservers puede llegar a 24–48 horas, porque los registros de delegación de la zona padre se guardan en caché más tiempo.
La palabra "propagación" engaña un poco. No se difunde nada por internet. Tu servidor DNS autoritativo conoce el nuevo valor en cuanto haces clic en guardar. Lo que esperas es que miles de cachés independientes, en ISP, resolvedores públicos, routers y sistemas operativos, tiren la respuesta que guardaron antes y vuelvan a preguntar.
Por qué los cambios DNS no son instantáneos
Cada respuesta DNS lleva un TTL (time to live), un número de segundos que indica al resolvedor cuánto tiempo puede reutilizar la respuesta sin volver a preguntar. Si tu registro A tenía un TTL de 3600 cuando el resolvedor del ISP de un visitante lo consultó, ese resolvedor puede seguir sirviendo la IP antigua hasta una hora después de tu cambio, por muy rápido que sea tu proveedor DNS.
Ese es todo el mecanismo. Cada resolvedor obtuvo tu registro en un momento distinto, así que sus copias caducan en momentos distintos. Por eso un amigo ve la web nueva mientras otro sigue viendo la antigua, y por eso los "comprobadores de propagación" online muestran durante un rato un mosaico de ubicaciones en verde y en rojo.
¿Cuánto tarda en propagarse un DNS? Tiempos típicos
La respuesta depende de qué hayas cambiado. La tabla muestra rangos realistas, suponiendo que las cachés respetan el TTL (la mayoría de los grandes resolvedores lo hacen).
| Cambio | Qué controla el retraso | Tiempo típico |
|---|---|---|
| Editar un registro A, AAAA o CNAME | TTL antiguo de ese registro | 1 minuto – TTL antiguo (a menudo de 5 min a 1 hora) |
| Añadir un registro totalmente nuevo | Caché negativa (mínimo del SOA) | Instantáneo si nadie lo consultó; si no, de minutos a una hora aproximadamente |
| Cambiar MX o TXT (SPF, DKIM, verificación) | TTL antiguo del conjunto de registros | De minutos a unas horas |
| Cambiar los nameservers en el registrador | TTL de los registros NS en la zona del TLD | Unas horas, hasta 24–48 horas |
| Registrar un dominio nuevo | Publicación de la delegación por el registro | Normalmente minutos |
La fila del "registro nuevo" sorprende a muchos. Si tú, o alguna herramienta, consultasteis app.example.com antes de que existiera, los resolvedores guardaron la respuesta "no existe". Esa respuesta negativa también se cachea, durante un periodo derivado del registro SOA de la zona, tal como define el RFC 2308. Evita probar un nombre de host antes de crearlo.
Cambios de registros vs cambios de nameservers
Cambios de registros dentro de la misma zona
Cuando solo editas registros, por ejemplo para mover tu web a un servidor nuevo actualizando el registro A, tratas con una sola capa de caché y un solo TTL. Si el TTL era de 300 segundos, prácticamente todo el mundo ve la nueva IP en unos cinco minutos. Es el caso rápido y predecible, y es lo que ocurre si sigues nuestra guía sobre cómo apuntar un dominio a un VPS.
Cambios de nameservers
Cambiar los nameservers traslada toda la zona a otro proveedor DNS. Los resolvedores saben qué nameservers son autoritativos gracias a los servidores del propio TLD, y en los TLD grandes esos registros de delegación suelen tener TTL de uno o dos días. No puedes bajar ese TTL; lo fija el registro. De ahí viene el famoso "hasta 48 horas".
Durante ese periodo, algunos resolvedores siguen preguntando al proveedor antiguo y otros al nuevo. Si las dos zonas no son idénticas, los visitantes reciben respuestas distintas. Lo seguro es recrear primero todos los registros en el nuevo proveedor, comprobarlos directamente y solo entonces cambiar los nameservers. Si aún dudas sobre mover el DNS, lee antes DNS de Cloudflare vs DNS del registrador.
Cómo acelerar la propagación DNS (de forma práctica)
No puedes obligar a los resolvedores ajenos a vaciar su caché, pero sí asegurarte de que haya muy poco en caché que esperar. Planifica el cambio así:
- Baja el TTL con antelación — al menos un periodo completo del TTL antiguo antes del cambio (con un TTL de 1 hora, unas horas antes), pon los registros que vayas a tocar en 60–300 segundos.
- Prepara el destino — asegúrate de que el nuevo servidor, buzón o servicio ya responde correctamente, para atender el tráfico que llegue pronto.
- Haz el cambio — actualiza el registro. Como las cachés ahora lo guardan uno o cinco minutos, el cambio se extiende casi de inmediato.
- Verifica desde fuera — consulta varios resolvedores públicos y el servidor autoritativo directamente (ver la siguiente sección).
- Mantén vivo un tiempo el destino antiguo — deja el servidor antiguo funcionando al menos durante el TTL antiguo más un margen de seguridad, para que los rezagados no acaben en una IP muerta.
- Vuelve a subir el TTL — una vez estable, vuelve a un valor más largo como 3600 para reducir consultas y ganar resiliencia.
Cómo comprobar la propagación DNS
Empieza por la fuente de verdad: pregunta directamente a tu nameserver autoritativo. Si devuelve el nuevo valor, tu parte está hecha y el resto es caché. Comandos típicos:
dig +short example.com A @ns1.yourprovider.com— la respuesta autoritativa.dig +short example.com A @1.1.1.1y@8.8.8.8— lo que devuelven ahora dos grandes resolvedores públicos. El TTL que aparece en la salida completa dedigva en cuenta atrás; cuando llega a cero, la siguiente consulta obtiene el nuevo valor.nslookup example.com— disponible en Windows cuando no tienes dig.dig NS example.com +trace— sigue la delegación desde la raíz; útil para confirmar un cambio de nameservers a nivel del TLD.
Las webs globales para "comprobar la propagación DNS" lanzan las mismas consultas desde muchos países. Son prácticas para tener una visión general, pero recuerda que reflejan un puñado de resolvedores, no todos los ISP.
Limpiar tus propias cachés
Muchas veces la respuesta antigua está en tu propio equipo. Vacía la caché del sistema (ipconfig /flushdns en Windows, sudo resolvectl flush-caches en muchos sistemas Linux, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder en macOS), reinicia el navegador o prueba con datos móviles para saltarte el router de casa.
Ejemplo: mover una web a un servidor nuevo
Supón que trasladas una web de un hosting compartido antiguo a un VPS nuevo y que tu registro A tiene ahora un TTL de 3600 segundos. Un calendario sin caídas podría ser así:
- Lunes por la mañana: baja el TTL de los registros A y www a 300 segundos. Espera al menos una hora a que se vacíen las cachés de una hora, o haz el cambio al día siguiente para ir sobre seguro.
- Antes del cambio: copia los archivos y la base de datos al nuevo servidor y prueba la web en la nueva IP usando el archivo hosts de tu ordenador.
- Cambio: actualiza el registro A. Como las cachés lo guardan cinco minutos como mucho, el tráfico empieza a llegar al nuevo servidor en minutos.
- Al día siguiente: cuando los logs del servidor antiguo ya no muestren visitas, apágalo y vuelve a subir el TTL a 3600.
En webs con base de datos, pausa brevemente las escrituras, como comentarios o pedidos, durante el cambio; si no, las últimas entradas que lleguen al servidor antiguo podrían no pasar nunca al nuevo. Si mueves el correo, aplica la misma lógica a los registros MX y mantén abierto el buzón antiguo unos días.
Problemas comunes de propagación y soluciones
- Funciona para ti pero no para otros — comprueba el servidor autoritativo; si está bien, estás esperando a las cachés. Si no, el registro se guardó en la zona o el proveedor equivocados.
- Sigue igual tras 48 horas — normalmente el dominio usa nameservers distintos de los que editaste. Compara los registros NS del registrador con el sitio donde hiciste el cambio.
- El correo rebota tras la mudanza — los registros MX, SPF y DKIM no se copiaron a la nueva zona antes de cambiar los nameservers.
- No se emite el certificado SSL — la validación de la autoridad de certificación llegó a la IP antigua, o un registro CAA la bloquea. Espera al TTL y reintenta.
Tiempo de propagación DNS en mistREG
Los dominios registrados en mistREG tienen su zona DNS alojada en la red autoritativa de Cloudflare y se gestionan desde el panel de mistREG, así que los cambios están activos en los servidores autoritativos casi al instante. Puedes elegir cualquier TTL entre 60 y 86.400 segundos o dejarlo en "auto", lo que facilita seguir la rutina de bajar el TTL primero descrita arriba.
Los registros se sirven en modo solo DNS, es decir, la IP que introduces es exactamente la que reciben los visitantes. Si prefieres tus propios nameservers puedes poner unos personalizados cuando quieras; el dominio sale entonces de la zona alojada en Cloudflare y se aplica la ventana habitual de propagación de nameservers. Puedes buscar un dominio entre más de 200 TLD, leer las preguntas frecuentes o contactar con soporte por Telegram en @mistnetwork o mediante el sistema de tickets del panel. Como siempre, el uso del servicio está sujeto a los términos del proveedor.


