Propagación DNS: cuánto tarda y cómo saber si un cambio ya se actualizó

Cambias la IP de una web, migras el correo a otro proveedor, apuntas un subdominio a un servicio nuevo o sustituyes los nameservers. El panel DNS confirma que la modificación está guardada, pero desde una conexión aparece el destino nuevo y desde otra todavía se ve el anterior.

A esa situación se la suele llamar propagación DNS.

La pregunta útil no es simplemente “¿ya pasaron 24 horas?”, sino qué respuesta sigue guardada en caché, qué resolvedor la está utilizando y cuándo debería vencer.

En este artículo-guía vamos a ver qué ocurre realmente durante una propagación DNS, cómo influye el TTL, qué tipo de registro debes comprobar y cómo diferenciar una transición normal de un error de configuración.

Qué significa realmente la propagación DNS

La palabra “propagación” sugiere que un cambio viaja de servidor en servidor hasta llegar a toda Internet. El funcionamiento real es diferente.

Cuando un usuario consulta un dominio, normalmente interviene un resolvedor DNS recursivo. Ese resolvedor obtiene la respuesta de la infraestructura DNS correspondiente y puede guardarla temporalmente en caché.

Si modificas el registro autoritativo, el servidor DNS puede empezar a ofrecer el valor nuevo de inmediato. Sin embargo, un resolvedor que ya tenía guardada la respuesta anterior puede seguir utilizándola hasta que expire.

Por eso dos usuarios pueden consultar el mismo dominio a la misma hora y obtener resultados diferentes sin que ninguno tenga necesariamente una configuración incorrecta.

Cuánto tarda en actualizarse el DNS

No existe una regla universal de 24, 48 o 72 horas válida para cualquier modificación.

Algunos cambios empiezan a verse en pocos minutos. Otros permanecen de forma desigual durante varias horas.

El tiempo depende de factores como:

• el TTL que tenía el registro antes del cambio;
• el momento en que cada resolvedor almacenó la respuesta anterior;
• cachés del sistema operativo, navegador, router o red corporativa;
• el tipo de registro modificado;
• una posible sustitución de nameservers;
• el uso de CDN, balanceo global o DNS geográfico;
• cachés de respuestas negativas.

Imagina un registro A con TTL de 3600 segundos. Un resolvedor que haya guardado la IP antigua justo antes del cambio podría seguir utilizándola durante casi una hora. Otro cuyo caché estaba a punto de vencer puede recuperar la IP nueva pocos minutos después.

Por eso cada resolvedor puede recorrer la transición a un ritmo diferente.

TTL: la clave para entender los tiempos

TTL significa Time to Live. Indica durante cuánto tiempo puede mantenerse una respuesta DNS en caché antes de tener que renovarse.

Valores habituales:

• 300 segundos: 5 minutos;
• 1800 segundos: 30 minutos;
• 3600 segundos: 1 hora;
• 14400 segundos: 4 horas;
• 86400 segundos: 24 horas.

Un TTL corto facilita cambios planificados porque las respuestas antiguas caducan antes. Un TTL largo reduce consultas repetidas, pero también puede prolongar la coexistencia entre datos viejos y nuevos.

Si estás preparando una migración importante, suele ser más efectivo reducir el TTL con antelación, esperar a que venza el TTL anterior y después realizar la modificación principal.

Bajar el TTL en el mismo momento del cambio no obliga a los cachés existentes a olvidar una respuesta que guardaron con el valor anterior.

Qué registro DNS debes comprobar

Antes de diagnosticar “propagación lenta”, asegúrate de estar mirando el tipo de registro correcto.

A

El registro A relaciona un hostname con una dirección IPv4. Es el más habitual al cambiar un sitio web de servidor.

AAAA

El registro AAAA hace lo mismo con IPv6. Si el dominio publica A y AAAA, dejar el AAAA antiguo puede hacer que usuarios con IPv6 sigan llegando al servidor anterior.

CNAME

Un CNAME convierte un hostname en alias de otro. Es muy común en www, plataformas SaaS, verificaciones y servicios de CDN.

MX

Los registros MX indican qué servidores reciben el correo de un dominio. Son fundamentales al migrar el email a otro proveedor.

TXT

Los registros TXT se utilizan para SPF, validaciones de dominio y muchas integraciones con servicios externos.

NS

Los registros NS identifican los servidores autoritativos de una zona. Cambiar nameservers es una operación más amplia que modificar un A o un CNAME porque también interviene la delegación configurada en el registrador.

Cómo comprobar si un cambio DNS ya se actualizó

Actualizar repetidamente la página web no es una buena prueba porque mezcla varias capas: DNS, HTTPS, servidor web, CDN y aplicación.

Lo más útil es consultar directamente el registro modificado y comparar respuestas de distintos resolvedores.

Una comprobación de propagación DNS permite ver si varias perspectivas ya muestran la respuesta esperada, si aún existe divergencia y qué TTL aparece en cada resultado.

1. 1Identifica el hostname exacto y el tipo de registro que modificaste: A, AAAA, CNAME, MX, TXT o NS.
2. 2Consulta ese hostname concreto; no des por hecho que el dominio raíz y sus subdominios comparten la misma configuración.
3. 3Compara la respuesta obtenida con el valor nuevo que debería estar publicado.
4. 4Revisa varias perspectivas DNS en lugar de confiar únicamente en tu conexión doméstica, móvil o de oficina.
5. 5Observa el TTL y repite la consulta después de un intervalo razonable en lugar de hacerlo cada pocos segundos.
6. 6Si el DNS ya coincide pero el servicio sigue fallando, continúa el diagnóstico en HTTPS, HTTP, CDN o aplicación.

El comprobador de ProntoUso compara seis perspectivas: Brasil, Estados Unidos, Europa y Asia mediante consultas regionales, además de Google Public DNS y Cloudflare en vistas globales.

Las perspectivas regionales utilizan EDNS Client Subnet (ECS). No son servidores físicos de ProntoUso ubicados en cada país, sino consultas diseñadas para observar respuestas DNS sensibles a la ubicación.

Cómo interpretar el consenso

Si todas las consultas válidas devuelven la misma respuesta, es una buena señal de consistencia entre los resolvedores analizados.

Si unas muestran el valor antiguo y otras el nuevo, puede tratarse de una transición normal del caché.

Pero una diferencia tampoco demuestra por sí sola que la propagación esté incompleta.

Antes de buscar un único resultado “correcto” para todo el planeta, confirma si tu arquitectura utiliza distribución geográfica.

Por qué tu ordenador sigue viendo el servidor anterior

Puede ocurrir que las consultas públicas ya muestren el valor nuevo y, aun así, tu navegador siga llegando al destino viejo.

Las causas posibles incluyen:

• caché DNS del sistema operativo;
• caché del navegador;
• caché del router;
• resolvedor de tu proveedor de Internet o empresa;
• VPN;
• proxy;
• una entrada manual en el archivo hosts;
• un registro AAAA antiguo cuando solo has comprobado el A.

Probar desde otra red puede aportar información, pero no convierte esa segunda conexión en una visión completa de Internet.

Si el DNS ya apunta al destino correcto y la web devuelve un error, separa el problema. Una consulta del código de estado HTTP ayuda a saber si la resolución funciona pero el servidor web está respondiendo con un 404, 500, redirección u otro resultado.

El DNS está bien, pero HTTPS muestra un error

Este escenario es muy frecuente después de una migración de hosting.

El dominio ya llega al servidor nuevo, pero el navegador avisa de un certificado incorrecto o no válido.

Esperar más “propagación” puede no cambiar nada. El servidor nuevo necesita presentar un certificado válido para ese hostname.

Puedes revisar por separado el certificado SSL/TLS que está entregando el dominio. Si el DNS lleva al destino correcto pero el certificado pertenece a otro sitio, está vencido o no incluye el nombre consultado, el problema ya no está en DNS.

Una forma práctica de pensar el diagnóstico es:

DNS → conexión → TLS/HTTPS → HTTP → aplicación

Cada capa responde una pregunta distinta.

“Sin respuesta” no significa necesariamente que el dominio esté caído

Una consulta DNS puede ser válida y, aun así, no contener el tipo de registro solicitado.

Un subdominio pensado solo para una web puede tener A o CNAME, pero no MX. Consultar MX allí puede devolver “sin respuesta” y ser completamente normal.

Conviene distinguir entre:

• hostname válido sin ese tipo de registro;
• hostname inexistente;
• resolvedor que no respondió;
• registro presente pero con un valor inesperado.

Verifica siempre el nombre exacto y el tipo de registro antes de tratar un resultado vacío como una caída.

Cambiar nameservers requiere más cuidado

Modificar un registro dentro de la zona actual es una cosa. Cambiar los nameservers en el registrador significa cambiar quién es autoritativo para toda la zona.

La nueva zona debe estar preparada antes de cambiar la delegación.

• !Crea todos los registros necesarios en el nuevo proveedor DNS antes de modificar los nameservers.
• !Comprueba los registros A, AAAA, CNAME, MX y TXT importantes.
• !Copia los registros de autenticación de correo, como SPF, DKIM y DMARC, cuando correspondan.
• !Verifica que los nuevos servidores autoritativos responden correctamente antes del cambio.
• !Mantén disponible la zona anterior durante la transición siempre que sea posible.
• !Evita introducir cambios no relacionados en la misma ventana si después necesitas diagnosticar un problema.

Olvidar un MX o un TXT puede dejar la web funcionando y romper el correo. Eso se confunde fácilmente con propagación cuando en realidad la nueva zona está incompleta.

¿Se puede acelerar la propagación después del cambio?

No puedes obligar a todos los resolvedores públicos a borrar un caché válido.

Puedes controlar el TTL que publicas, pero no la memoria de cada resolvedor que ya consultó el registro.

Después de realizar el cambio, lo más útil es:

1. confirmar que el DNS autoritativo ofrece el valor nuevo;
2. comparar varios resolvedores públicos;
3. esperar de acuerdo con el TTL anterior;
4. no modificar el registro una y otra vez mientras investigas;
5. comprobar el servicio del destino de forma independiente.

Cambiar la IP varias veces durante la transición puede dejar distintos cachés con diferentes versiones y hacer el diagnóstico más confuso.

Caché negativo: cuando antes no existía el registro

DNS también puede almacenar temporalmente una respuesta de “no existe”.

Imagina que consultas api.example.com antes de crearlo. Un resolvedor puede guardar ese resultado negativo. Después creas el registro, pero durante un tiempo ese resolvedor todavía recuerda que el nombre no existía.

Por eso un hostname completamente nuevo también puede tardar en aparecer desde ciertas redes, incluso aunque no hubiera una IP anterior.

Cuándo dejar de esperar y empezar a investigar

Toma como referencia el TTL anterior al cambio, no una regla genérica de 48 horas.

Si el TTL era 300 segundos y muchas horas después varios resolvedores independientes siguen mostrando un valor antiguo inesperado, hay motivos para revisar la configuración.

Si el TTL era 86400 segundos, encontrar cachés antiguos durante parte del día siguiente puede ser razonable.

En cambios de NS también hay que considerar la delegación del dominio y el comportamiento del registrador.

Pregúntate:

• ¿el DNS autoritativo devuelve el valor nuevo?
• ¿qué resolvedores siguen mostrando el anterior?
• ¿el TTL observado encaja con el caché esperado?
• ¿hay CDN o DNS geográfico?
• ¿estoy consultando el registro y hostname correctos?
• ¿el fallo actual sigue siendo realmente DNS?

Errores comunes al cambiar DNS

Muchos incidentes atribuidos a “propagación” son errores de configuración.

Entre los más habituales:

• editar una zona que ya no es autoritativa;
• cambiar www y olvidar el dominio raíz, o al revés;
• actualizar A pero dejar AAAA en el servidor anterior;
• escribir una IP equivocada;
• crear un CNAME incompatible con otro registro existente;
• migrar correo sin copiar MX y TXT;
• cambiar NS antes de preparar la zona nueva;
• confundir un error HTTP o una redirección con un fallo DNS;
• interpretar las IP regionales de una CDN como un problema.

Una comprobación de propagación tiene mucho más valor cuando sabes qué respuesta esperas encontrar.

Preguntas frecuentes

¿La propagación DNS siempre tarda entre 24 y 48 horas?

No. Muchas modificaciones aparecen bastante antes. El TTL anterior, los cachés existentes, el tipo de registro y el comportamiento de los resolvedores son referencias más útiles.

¿Vaciar la caché DNS de mi equipo actualiza el dominio para todos?

No. Solo afecta al equipo o resolvedor cuya caché vacías. El resto mantiene su propio estado.

Si Google y Cloudflare ya muestran el nuevo valor, ¿terminó la propagación?

Es una señal positiva, pero no garantiza el estado de todos los resolvedores. Además, una CDN o GeoDNS puede devolver resultados diferentes de forma intencional.

¿Reducir el TTL después del cambio hace que los cachés viejos caduquen antes?

No necesariamente. Un resolvedor que guardó la respuesta anterior con el TTL viejo puede seguir respetando ese tiempo.

¿Por qué una región obtiene una IP diferente?

Las CDN, el balanceo global y el DNS geográfico pueden elegir destinos distintos según la ubicación. Es un comportamiento normal cuando está configurado así.

¿Debo comprobar A y AAAA?

Si tu dominio publica ambos, sí. Un dispositivo con IPv6 puede utilizar AAAA aunque el registro A ya esté actualizado.

Idea principal

La propagación DNS se entiende mejor como una transición de cachés que como un contador mundial de horas.

Empieza por identificar el registro que realmente cambiaste. Compara varias perspectivas. Usa el TTL como contexto y ten en cuenta si tu infraestructura entrega respuestas diferentes según la región.

Cuando el DNS ya devuelve de forma consistente el destino esperado, deja de esperar “más propagación” y avanza a la siguiente capa del diagnóstico. Así podrás detectar antes si el problema real está en HTTPS, el servidor web, la CDN o la propia aplicación.