Propagación DNS: ¿cuánto tiempo tarda realmente?
Por CaptainDNS
Publicado el 26 de marzo de 2026
- La «propagación DNS» no existe como mecanismo: el DNS no envía nada. Son las cachés de los resolutores las que expiran según el TTL (Time To Live) configurado por el administrador de zona.
- El plazo real depende del TTL del registro modificado: 1 minuto (TTL 60) a 24 horas (TTL 86400). Ninguna razón técnica justifica un plazo de 48 horas.
- Bajar el TTL a 300 segundos 48 horas antes de un cambio DNS elimina el mito de las «24 a 48 horas». Tras la modificación, el nuevo registro es visible en todas partes en 5 minutos.
- Verificar en tiempo real con una herramienta multi-resolutores permite confirmar que el cambio es efectivo, resolutor por resolutor.
«Cuenta con 24 a 48 horas para la propagación DNS.» Si alguna vez cambiaste un registro DNS, leíste esta frase. En la ayuda de tu registrador, en un ticket de soporte, en un tutorial cualquiera. Es el consejo técnico más repetido en Internet. También el más engañoso.
El DNS no «propaga» nada. No existe mecanismo de difusión en el protocolo. Lo que existe es un sistema de caché distribuido con un reloj de expiración: el TTL. Cuando modificas un registro, los resolutores siguen sirviendo el valor antiguo hasta que el TTL expira. Después, consultan al servidor autoritativo y obtienen el nuevo valor. Eso es todo.
El plazo percibido es totalmente controlable. TTL de 5 minutos = cambio visible en 5 minutos. TTL de 24 horas = espera de 24 horas. La cifra de «48 horas» no corresponde a ningún TTL estándar. Proviene de los inicios del DNS comercial, cuando los registradores imponían TTL de 86 400 segundos y los resolutores de ISP a veces sumaban sus propios retrasos.
Este artículo desglosa el mecanismo real, detalla los plazos exactos para cada valor de TTL y te ofrece un método de migración DNS que hace el plazo predecible y controlado.
Verifica tu propagación DNS
El mito de las «24 a 48 horas»
¿De dónde viene esta cifra?
Para entender el origen del mito, hay que remontarse a los años 2000. Registradores como Network Solutions, GoDaddy o Gandi configuraban TTL por defecto de 86 400 segundos (24 horas). Algunos registros de TLD (VeriSign para .com y .net) actualizaban los archivos de zona cada 12 horas. Combinando ambos factores, un cambio de servidor NS podía tardar hasta 36 horas en ser visible. Redondear a «48 horas» permitía cubrir los casos extremos.
El problema: esa estimación se quedó fijada en la documentación mientras la infraestructura cambió. Hoy, los registros principales actualizan sus zonas en pocos minutos. Los registradores modernos ofrecen TTL de 3 600 segundos (1 hora) por defecto, a veces 300. La realidad técnica de 2026 no tiene nada que ver con la de 2002. Entonces, ¿por qué seguimos repitiendo este consejo?
La palabra «propagación» es un uso incorrecto del lenguaje
El término «propagación» sugiere un proceso activo de difusión. Como si un cambio DNS fuera enviado de servidor en servidor, al estilo de una actualización de software que se despliega progresivamente. Esa imagen mental es falsa.
El DNS funciona con un modelo pull, no push. Ningún servidor envía una notificación a los resolutores para decirles «el valor ha cambiado». Cada resolutor recursivo decide por sí mismo cuándo consulta al servidor autoritativo, en función del TTL del registro que tiene en caché.
Esto es lo que ocurre realmente cuando un usuario escribe captaindns.com en su navegador:
- El stub resolver de la máquina local verifica su caché. Si tiene una respuesta válida (TTL no expirado), la devuelve inmediatamente.
- Si no tiene nada en caché, transmite la consulta al resolutor recursivo configurado (el del ISP, de Google, de Cloudflare, etc.).
- El resolutor recursivo verifica su propia caché. Si tiene una respuesta válida, la devuelve.
- Si no tiene nada o si el TTL ha expirado, lanza una resolución completa: consulta un servidor raíz, luego el servidor TLD (
.com), luego el servidor autoritativo del dominio. - El servidor autoritativo devuelve la respuesta actual (el nuevo registro si lo has modificado) con el TTL configurado.
- El resolutor almacena esta respuesta en caché durante la duración del TTL y la devuelve al usuario.
El «plazo de propagación» no es más que el tiempo restante antes de la expiración de la caché. Ejemplo: el resolutor almacenó el registro hace 30 minutos con un TTL de 3 600 segundos. Faltan 30 minutos antes de que vuelva a consultar al servidor autoritativo.
El TTL: el verdadero reloj de la propagación
Si la «propagación DNS» no existe como mecanismo, ¿qué determina el plazo real? Un solo campo en el registro DNS: el TTL.
¿Qué es el TTL?
El TTL (Time To Live) es un campo numérico asociado a cada registro DNS, expresado en segundos. Indica a los resolutores cuánto tiempo pueden conservar la respuesta en caché antes de volver a solicitarla al servidor autoritativo.
El TTL lo define el administrador de la zona DNS, no el protocolo. Es una decisión operativa. Cada registro en una zona puede tener su propio TTL. Puedes configurar un TTL de 60 segundos en un registro A que apunta a un servicio de alta disponibilidad, manteniendo un TTL de 86 400 segundos en un registro MX que nunca cambia.
La RFC 1035 (sección 3.2.1) define el TTL como un entero sin signo de 32 bits, es decir, un valor máximo teórico de 2 147 483 647 segundos (unos 68 años). En la práctica, la RFC 2181 (sección 8) recomienda tratar cualquier valor superior a 2 147 483 647 como 0. Los valores habituales van de 60 a 86 400 segundos.
Para verificar el TTL actual de un registro, usa dig:
dig captaindns.com A +noall +answer
La salida se ve así:
captaindns.com. 3600 IN A 76.76.21.21
El número 3600 es el TTL restante en segundos. Atención: este valor disminuye cada segundo. Si relanzas el comando 10 segundos después, verás 3590. Cuando llega a 0, el resolutor considera la entrada expirada y consulta de nuevo al servidor autoritativo.
Para obtener el TTL definido por el servidor autoritativo (y no el TTL restante en la caché del resolutor), consulta directamente al servidor autoritario:
dig captaindns.com A @ns1.captaindns.com +noall +answer
Tabla de plazos reales por TTL habitual
Esta tabla muestra el plazo máximo entre un cambio DNS y su visibilidad completa en todos los resolutores, suponiendo que el resolutor almacenó el registro antiguo en caché justo antes de la modificación (peor caso).
| TTL (segundos) | Duración legible | Plazo máx. de visibilidad | Uso típico |
|---|---|---|---|
| 60 | 1 minuto | 1 minuto | Conmutación automática, alta disponibilidad, servicios críticos |
| 300 | 5 minutos | 5 minutos | CDN, balanceo de carga, pre-migración |
| 900 | 15 minutos | 15 minutos | Servicios cloud (AWS, GCP, Azure) |
| 1800 | 30 minutos | 30 minutos | Aplicaciones SaaS |
| 3600 | 1 hora | 1 hora | Valor por defecto de registradores modernos (Cloudflare, Route 53) |
| 14400 | 4 horas | 4 horas | Valor por defecto histórico de OVH, Gandi, algunos paneles cPanel |
| 43200 | 12 horas | 12 horas | Registros estables que rara vez se modifican |
| 86400 | 24 horas | 24 horas | Registros NS, registros de zona estables, valor por defecto histórico |
El «24 a 48 horas» del mito corresponde al peor caso de un TTL de 86 400 combinado con un resolutor que hubiera almacenado el valor en caché un segundo antes de la modificación. En ese escenario, el plazo máximo es de 24 horas, no 48. Las 48 horas son un redondeo de precaución sin fundamento técnico.
¿Por qué algunos resolutores ignoran el TTL?
El protocolo DNS (RFC 1035) exige que los resolutores respeten el TTL. En la práctica, existen algunas desviaciones.
TTL mínimo impuesto. Google Public DNS impone un piso de 30 segundos. Si un servidor autoritativo devuelve un TTL de 0 o de 10 segundos, Google lo trata como 30 segundos. Este comportamiento está documentado en su FAQ técnica. Cloudflare aplica un piso similar. El impacto es insignificante para la mayoría de los casos de uso.
TTL máximo impuesto. Algunos resolutores de ISP aplican un techo de TTL para reducir la carga en sus servidores. Un ISP que procesa millones de consultas por segundo puede decidir no respetar un TTL de 60 segundos y tratarlo como 300 segundos. Este comportamiento es raro, no documentado y contrario a las RFC, pero existe.
Caché negativa. El TTL también se aplica a las respuestas NXDOMAIN (dominio inexistente) a través del campo SOA minimum TTL (RFC 2308). Si creas un nuevo registro para un nombre que no existía, el resolutor puede haber almacenado en caché la respuesta «no existe» con el TTL negativo de la zona SOA. Este plazo se olvida con frecuencia durante las migraciones.
Para verificar el TTL negativo de tu zona:
dig captaindns.com SOA +noall +answer
captaindns.com. 3600 IN SOA ns1.captaindns.com. admin.captaindns.com. 2026032601 7200 900 1209600 300
El último campo (300) es el TTL negativo. Las respuestas NXDOMAIN se almacenarán en caché durante 300 segundos (5 minutos).
Los resolutores DNS: todos diferentes frente a la caché
La caché jerárquica
La resolución DNS atraviesa varios niveles de caché antes de llegar al servidor autoritativo. Cada nivel puede devolver una respuesta sin ir más allá:
Nivel 1: la caché de la aplicación. Los navegadores y las aplicaciones mantienen su propia caché DNS. Chrome, por ejemplo, conserva las resoluciones durante 60 segundos por defecto. Esta caché es independiente del sistema operativo.
Nivel 2: el stub resolver (caché del SO). El sistema operativo mantiene una caché DNS local. En Windows, el servicio «Cliente DNS» gestiona esta caché. En macOS, es mDNSResponder. En Linux con systemd, es systemd-resolved. Esta caché generalmente respeta el TTL devuelto por el resolutor recursivo.
Nivel 3: el resolutor recursivo. Es el servidor DNS configurado en tu conexión de red (el del ISP, Google 8.8.8.8, Cloudflare 1.1.1.1, etc.). Es el que realiza la resolución completa consultando la jerarquía DNS y el que mantiene la caché más importante. El TTL en este nivel determina el plazo percibido de «propagación».
Nivel 4: los relés DNS intermedios. En las redes corporativas, un servidor DNS interno (Active Directory, Pi-hole, dnsmasq) puede servir de relé hacia el resolutor recursivo. Este relé añade un nivel de caché adicional, con sus propias reglas de retención.
Un cambio DNS solo es completamente visible para un usuario cuando todos los niveles de caché que atraviesa han expirado. En el peor caso (todas las cachés acaban de llenarse), el plazo es el del TTL más alto en la cadena. En la práctica, las cachés de aplicaciones y del SO tienen TTL cortos (60 segundos o menos), por lo que el cuello de botella es casi siempre el resolutor recursivo.
¿Por qué los resultados varían según el resolutor?
Cuando pruebas la propagación DNS, puedes obtener resultados diferentes según el resolutor consultado. Es normal, y hay tres razones para ello.
Razón 1: el momento de almacenamiento en caché difiere. Google DNS puede haber almacenado el registro antiguo en caché hace 2 minutos, mientras que Cloudflare lo hizo hace 55 minutos. Con un TTL de 3 600 segundos, Google servirá el valor antiguo durante 58 minutos más, mientras que Cloudflare lo servirá durante solo 5 minutos más. Mismo TTL, pero desfase temporal.
Razón 2: la infraestructura de caché está distribuida. Google DNS no es un solo servidor. Es una red de servidores anycast repartidos en cientos de centros de datos. Cada instancia mantiene su propia caché. Una consulta desde Madrid llega a un servidor Google diferente del de Tokio. Los dos pueden tener valores de caché diferentes. Por eso dos usuarios que consultan «8.8.8.8» al mismo tiempo pueden obtener respuestas diferentes.
Razón 3: EDNS Client Subnet (ECS). Algunos dominios utilizan respuestas geolocalizadas a través de EDNS Client Subnet. El servidor autoritativo devuelve direcciones IP diferentes según la ubicación del cliente. Un usuario en España obtiene la IP del centro de datos europeo, un usuario en Japón obtiene la IP del centro de datos asiático. No es un problema de propagación: es el comportamiento esperado de un CDN. Pero complica el diagnóstico porque los resolutores tienen respuestas legítimamente diferentes en caché.
Para verificar lo que cada resolutor tiene en caché, consúltalos directamente:
dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
Si los tres devuelven la misma IP con TTL restantes diferentes, es la prueba de que el cambio está en curso y de que las cachés expiran en momentos diferentes.
Guía práctica: migración DNS sin sorpresas
El método que sigue elimina la incertidumbre de una migración DNS. Se basa en un principio simple: reducir el TTL antes del cambio para que la caché expire rápidamente después de la modificación. Es la técnica estándar utilizada por los SRE (Site Reliability Engineers) durante las migraciones de infraestructura.
Antes del cambio: D-48
Paso 1: verificar el TTL actual.
Consulta al servidor autoritativo para conocer el TTL definido (no el TTL restante en una caché):
dig captaindns.com A @ns1.captaindns.com +noall +answer
Si el TTL es de 86 400 segundos (24 horas), hay que reducirlo y esperar a que la caché antigua expire.
Paso 2: bajar el TTL a 300 segundos (5 minutos).
En la interfaz de tu registrador o tu gestor de zona DNS, modifica el TTL del registro que piensas cambiar. No toques aún el valor del registro. Solo cambia el TTL.
captaindns.com. 300 IN A 76.76.21.21
Paso 3: esperar la expiración del TTL antiguo.
Este es el paso crucial. Tras reducir el TTL a 300, debes esperar a que el TTL antiguo expire en todas partes. Si el TTL anterior era de 86 400 segundos, espera 24 horas. Si era de 3 600 segundos, espera 1 hora.
¿Por qué? Porque los resolutores que tienen el registro en caché con el TTL antiguo de 86 400 no verán tu cambio de TTL hasta que su caché haya expirado. Una vez expirado el TTL antiguo, todos los resolutores consultarán de nuevo al servidor autoritativo y obtendrán el registro con el nuevo TTL de 300 segundos.
Por esta razón hay que empezar 48 horas antes: en el peor caso (TTL inicial de 86 400), necesitas 24 horas para la propagación del nuevo TTL, más un margen de seguridad.
Verifica el progreso consultando varios resolutores:
dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
Cuando los tres devuelvan un TTL restante inferior o igual a 300, el nuevo TTL está en su lugar.
El día del cambio: D
Paso 4: realizar el cambio DNS.
Modifica el valor del registro en tu registrador o proveedor DNS. Por ejemplo, para una migración de servidor:
captaindns.com. 300 IN A 185.199.108.153
El TTL se mantiene en 300 segundos. El cambio será visible en todos los resolutores en 5 minutos como máximo.
Paso 5: verificar la propagación.
Consulta los principales resolutores públicos para confirmar que el cambio es efectivo:
dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
dig captaindns.com A @208.67.222.222 +noall +answer
La herramienta de test de propagación CaptainDNS realiza esta verificación automáticamente consultando resolutores repartidos en varios continentes.
Paso 6: validar el servicio.
Verifica que el servicio funciona correctamente en la nueva dirección. Prueba los accesos HTTP/HTTPS, los envíos de correos electrónicos, las conexiones API. No pases al siguiente paso hasta que todo esté confirmado.
Después del cambio: D+1
Paso 7: subir el TTL.
Una vez confirmado el cambio y validado el servicio, sube el TTL a un valor estándar. Un TTL de 3 600 segundos (1 hora) es un buen equilibrio entre reactividad y reducción de carga DNS:
captaindns.com. 3600 IN A 185.199.108.153
Un TTL demasiado bajo (60 segundos) de forma permanente sobrecarga los servidores autoritativos. Un TTL demasiado alto (86 400 segundos) hace las migraciones futuras más lentas. Para los registros que rara vez cambian (NS, MX), un TTL de 3 600 a 14 400 es razonable.
Paso 8: monitorizar durante 24 a 48 horas.
Monitoriza las métricas del servicio (tiempo de respuesta, tasa de errores, entregabilidad de correo) durante las horas siguientes a la migración. Resolutores con comportamientos no estándar pueden tardar en actualizar su caché. Una herramienta de supervisión DNS resiliente permite detectar esas anomalías.
¿Cómo acelerar la «propagación»?
Ya hiciste el cambio, pero algunos resolutores todavía sirven el valor antiguo. ¿Se puede hacer algo? Sí. Hay acciones concretas para reducir el plazo. Ninguna reemplaza la reducción previa del TTL, pero son útiles como complemento.
Vaciar la caché DNS local
La caché de tu máquina local puede contener el valor antiguo. Vaciarla fuerza a tu sistema a consultar de nuevo al resolutor recursivo.
Windows (PowerShell como administrador):
ipconfig /flushdns
macOS (Terminal):
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
Linux (systemd-resolved):
sudo systemd-resolve --flush-caches
Chrome (barra de direcciones):
chrome://net-internals/#dns
Haz clic en «Clear host cache». Chrome mantiene su propia caché DNS independiente del SO.
Solicitar una purga a los resolutores públicos
Algunos resolutores públicos ofrecen una interfaz para purgar un registro específico de su caché. No es una garantía (el registro se volverá a almacenar en caché en cuanto haya la siguiente consulta), pero fuerza una re-resolución inmediata.
Google Public DNS: ve a la página Google Public DNS Flush Cache e ingresa el dominio y el tipo de registro a purgar.
Cloudflare: ve a la página Cloudflare Purge Cache e ingresa el dominio.
Estas herramientas purgan la caché de un solo nodo (el que procesa tu consulta). Los resolutores como Google y Cloudflare usan anycast: la caché está distribuida en cientos de servidores. Purgar desde Madrid no purga la caché del servidor que atiende a los usuarios de São Paulo.
Lo que NO funciona
Algunas «soluciones» circulan por los foros y las páginas de soporte. Son ineficaces, incluso contraproducentes.
Reiniciar el router. La caché DNS del router doméstico suele estar limitada a unas pocas decenas de entradas y expira rápidamente. Aunque el reinicio vacíe esa caché, el resolutor recursivo del ISP (el verdadero cuello de botella) conserva el valor antiguo.
Cambiar de resolutor DNS en el equipo cliente. Pasar de Google (8.8.8.8) a Cloudflare (1.1.1.1) puede dar la impresión de que el cambio está propagado, porque Cloudflare quizás no tenga la misma entrada en caché que Google. Pero eso no resuelve nada para los demás usuarios. Es un sesgo de observación, no una solución.
Esperar «un poco más». Si el cambio no es visible después del plazo del TTL, esperar más no resolverá nada. El problema está en otro lugar: TTL negativo en caché, error en la zona, servidor autoritativo mal configurado o resolutor que no respeta el TTL. Diagnostica, no tengas paciencia.
Casos de uso específicos
Cambio de alojamiento (A / AAAA)
Es el caso más frecuente: migras un sitio web a un nuevo servidor. El registro A (IPv4) o AAAA (IPv6) cambia de dirección IP.
El plan estándar funciona perfectamente aquí. Reduce el TTL 48 horas antes, cambia la IP, verifica. La particularidad: si tu servidor antiguo y el nuevo están configurados para responder al mismo nombre de dominio, los usuarios que obtienen la IP antigua ven el servidor antiguo, los que obtienen la nueva ven el nuevo. Durante la transición, ambos servidores deben funcionar en paralelo.
Para las migraciones con cambio simultáneo de dirección IPv4 e IPv6, no olvides modificar ambos registros. Un olvido en el registro AAAA deja a los clientes IPv6 apuntando al servidor antiguo.
CNAME y alias
Los registros CNAME tienen su propio TTL, pero el resolutor también debe resolver el destino del CNAME. El plazo total es el máximo entre el TTL del CNAME y el TTL del registro de destino. Si tu CNAME tiene un TTL de 300 pero apunta a un registro A con un TTL de 86 400, el cambio del valor A tardará hasta 24 horas aunque el CNAME en sí se resuelva en 5 minutos.
Email: MX, SPF, DKIM, DMARC
Los registros relacionados con el correo electrónico merecen una atención particular porque las consecuencias de un error son más graves que para un sitio web. Un sitio inaccesible durante 10 minutos es una molestia. Correos perdidos durante 10 minutos pueden tener consecuencias profesionales serias.
MX (Mail Exchanger). Los registros MX suelen tener un TTL alto (3 600 a 86 400). Durante una migración de proveedor de correo, la reducción del TTL es obligatoria. Durante la transición, ambos servidores MX deben aceptar el correo para tu dominio. Configura el antiguo proveedor para reenviar los mensajes al nuevo si es posible.
SPF (registro TXT). El cambio de un registro SPF tiene efecto en cuanto expira el TTL del TXT. El riesgo: si añades un nuevo proveedor de envío (como una herramienta de marketing) sin actualizar el SPF, sus correos serán rechazados por los servidores que tienen el SPF antiguo en caché. Solución: añade el mecanismo SPF antes de empezar a enviar a través del nuevo proveedor, y espera a que expire el TTL.
DKIM (registro TXT bajo _domainkey). La publicación de una nueva clave pública DKIM sigue las mismas reglas de TTL. Atención durante una rotación de clave: la clave antigua debe permanecer publicada en DNS mientras haya correos firmados con ella aún en tránsito (las colas de correo pueden retener mensajes durante varios días).
DMARC (registro TXT bajo _dmarc). Un cambio de política DMARC (paso de p=none a p=quarantine, por ejemplo) toma efecto progresivamente al ritmo de la expiración de las cachés. Se recomienda pasar por el modo p=quarantine antes de p=reject para limitar los falsos positivos durante la transición.
DNSSEC
La activación o modificación de DNSSEC añade una capa adicional de complejidad. Dos tipos de registros están implicados: los DNSKEY en la zona DNS y el registro DS (Delegation Signer) en el registrador.
El registro DS se publica en la zona del TLD padre (por ejemplo, en la zona .com para un dominio .com). Su actualización depende del registrador y del registro TLD. El plazo suele ser más largo que para un registro estándar porque implica una comunicación entre el registrador y el registro.
La regla al activar DNSSEC: publicar los DNSKEY primero, esperar la propagación completa (al menos 2 veces el TTL), luego añadir el registro DS. Si el DS se añade antes de que los DNSKEY sean visibles en todas partes, algunos resolutores validadores devolverán SERVFAIL, haciendo tu dominio inaccesible.
Cambio de servidores NS (delegación)
Cambiar los servidores autoritativos (registros NS) es el caso más delicado. Los registros NS a nivel del TLD tienen su propio TTL (a menudo 48 horas para .com). El resolutor debe respetar ese TTL antes de volver a consultar al registro TLD.
El procedimiento recomendado:
- Reproducir la zona DNS completa en los nuevos servidores NS
- Reducir el TTL de todos los registros importantes a 300 segundos
- Esperar la expiración del TTL antiguo
- Modificar la delegación NS en el registrador
- Mantener los servidores NS antiguos activos durante 48 a 72 horas (el tiempo que las cachés NS expiren)
- Verificar que ambos conjuntos de servidores NS devuelven las mismas respuestas durante todo el período de transición
Diagnóstico: ¿por qué mi cambio DNS no funciona?
Pasó el plazo previsto y el cambio sigue sin ser visible. ¿Qué falla? No asumas que es «lento»: diagnostica. Estas son las causas más frecuentes, clasificadas por probabilidad.
Causa 1: el cambio no se registró
Es la causa más habitual. La interfaz del registrador mostró «registrado» pero el servidor autoritativo aún no tiene el nuevo valor. Verifica directamente:
dig captaindns.com A @ns1.captaindns.com +noall +answer
Si aparece el registro antiguo, el problema está en el proveedor DNS, no en la propagación.
Causa 2: la caché negativa
Si creaste un nuevo registro (que no existía antes), el resolutor puede tener una respuesta NXDOMAIN en caché. Verifica el TTL negativo en el SOA:
dig captaindns.com SOA +noall +answer
El último campo del SOA es el TTL negativo. Espera ese plazo.
Causa 3: el tipo de registro equivocado
Cambiaste el registro A pero el DNS devuelve un CNAME que apunta al registro antiguo. O modificaste un TXT pero hay dos registros TXT y editaste el equivocado. Verifica pidiendo todos los tipos:
dig captaindns.com ANY @ns1.captaindns.com
Causa 4: DNSSEC roto
Si DNSSEC está activo y la cadena de confianza está rota (registro DS que ya no corresponde al DNSKEY), los resolutores validadores devuelven SERVFAIL en lugar de la respuesta. Prueba con y sin validación DNSSEC:
dig captaindns.com A @8.8.8.8 +dnssec
dig captaindns.com A @8.8.8.8 +cd
El flag +cd (Checking Disabled) desactiva la validación DNSSEC. Si la consulta funciona con +cd pero no sin él, el problema es DNSSEC.
Causa 5: relé DNS corporativo con caché agresiva
En una red corporativa, un servidor DNS interno (Active Directory, Pi-hole) puede almacenar las respuestas en caché con un TTL superior al devuelto por el resolutor recursivo. Contacta a tu administrador de red para vaciar la caché del servidor DNS interno.
Entender el rol de la zona SOA
El registro SOA (Start of Authority) contiene parámetros que influyen indirectamente en la «propagación». Sus campos suelen descuidarse al planificar una migración.
dig captaindns.com SOA +noall +answer
captaindns.com. 3600 IN SOA ns1.captaindns.com. admin.captaindns.com. (
2026032601 ; serial
7200 ; refresh (2 horas)
900 ; retry (15 minutos)
1209600 ; expire (14 días)
300 ; minimum / negative TTL (5 minutos)
)
Serial: número de versión de la zona. Los servidores secundarios comparan este número para detectar cambios. Un serial que no se incrementa después de una modificación impide la sincronización hacia los servidores secundarios.
Refresh: intervalo en el que los servidores secundarios verifican si la zona ha cambiado. Un refresh de 7 200 segundos (2 horas) significa que el servidor secundario puede servir una zona obsoleta durante 2 horas. Este parámetro impacta la coherencia entre servidores autoritativos, no la caché de los resolutores recursivos.
Minimum (TTL negativo): el TTL aplicado a las respuestas NXDOMAIN. Si creas un nuevo registro, los resolutores que tienen una respuesta NXDOMAIN en caché deberán esperar este plazo. Valor recomendado: 300 segundos (5 minutos).
Los resolutores públicos y sus particularidades
Cada resolutor público tiene comportamientos específicos que influyen en la percepción de la propagación. Conocer estas especificidades ayuda al diagnóstico. Una comparativa de resolutores DNS públicos permite profundizar en este tema.
Google Public DNS (8.8.8.8 / 8.8.4.4)
- TTL mínimo: 30 segundos
- Interfaz de purga disponible
- Infraestructura anycast masiva (cientos de PoP)
- Soporta EDNS Client Subnet para respuestas geolocalizadas
Cloudflare (1.1.1.1 / 1.0.0.1)
- TTL mínimo: 30 segundos
- Interfaz de purga disponible
- Arquitectura anycast en más de 310 centros de datos
- No transmite la subred del cliente por defecto (mejor privacidad)
Quad9 (9.9.9.9 / 149.112.112.112)
- Filtrado de malware integrado (puede bloquear ciertos dominios)
- TTL mínimo no documentado públicamente
- Sin interfaz de purga pública
- Validación DNSSEC activada por defecto
OpenDNS (208.67.222.222 / 208.67.220.220)
- Filtrado configurable (categorías de contenido)
- Caché que puede ser más persistente que el TTL en algunos casos
- Interfaz de purga a través del panel de control
Resolutores de ISP
- Comportamiento variable y a menudo no documentado
- Algunos imponen TTL mínimo o máximo
- Caché a veces compartida entre millones de suscriptores (efecto de mutualización)
- Raramente con interfaz de purga
Plan de acción recomendado
Este es el procedimiento completo, resumido en 5 pasos. Imprímelo o guárdalo para tu próxima migración DNS.
-
Verificar el TTL actual: consulta al servidor autoritativo con
digo usa la herramienta CaptainDNS para obtener el TTL de cada registro de tu zona. -
Bajar el TTL 48 horas antes: reduce a 300 segundos para todos los registros que piensas modificar. No olvides los registros asociados (AAAA si cambias A, TXT si migras el correo).
-
Realizar el cambio: modifica los registros DNS en tu registrador o proveedor. Verifica inmediatamente que el servidor autoritativo devuelve el nuevo valor.
-
Verificar la propagación: prueba desde varios resolutores públicos (Google, Cloudflare, Quad9, OpenDNS). Usa una herramienta de test de propagación para una vista global en todos los continentes.
-
Subir el TTL: una vez confirmado el cambio y validado el servicio, restaura un TTL estándar (3 600 segundos). Mantén la monitorización durante 24 horas.
FAQ
¿Cuánto tiempo dura la propagación DNS?
El plazo depende únicamente del TTL (Time To Live) del registro modificado. Con un TTL de 300 segundos, el cambio es visible en todas partes en 5 minutos. Con un TTL de 3 600 segundos, cuenta con 1 hora como máximo. Con un TTL de 86 400 segundos, el plazo máximo es de 24 horas. No hay ninguna razón técnica para un plazo de 48 horas. El mito de las «24 a 48 horas» viene de una época en la que los TTL por defecto eran de 86 400 segundos y los registros de TLD actualizaban sus zonas cada 12 horas.
¿Cómo acelerar la propagación DNS?
El método más eficaz es bajar el TTL a 300 segundos (5 minutos) al menos 48 horas antes del cambio previsto. Una vez propagado el TTL reducido, cualquier cambio posterior será visible en 5 minutos. Como complemento, puedes vaciar la caché de tu máquina local (ipconfig /flushdns en Windows, sudo dscacheutil -flushcache en macOS) y usar las interfaces de purga de Google Public DNS y Cloudflare para forzar una re-resolución en esos resolutores específicos.
¿Por qué mi cambio DNS no funciona?
Las causas más frecuentes son, por orden de probabilidad: (1) el cambio no se registró correctamente en el proveedor DNS, (2) la caché negativa (NXDOMAIN) retiene una antigua respuesta «no existe», (3) se modificó el tipo de registro equivocado, (4) la cadena DNSSEC está rota (el registro DS ya no corresponde al DNSKEY), (5) un relé DNS corporativo aplica una caché agresiva. Diagnostica consultando directamente al servidor autoritativo con dig captaindns.com A @ns1.captaindns.com para verificar que el cambio está en su lugar en el origen.
¿Qué es el TTL DNS?
El TTL (Time To Live) es un campo numérico asociado a cada registro DNS, expresado en segundos. Indica a los resolutores recursivos cuánto tiempo pueden conservar una respuesta en caché antes de tener que consultar de nuevo al servidor autoritativo. Por ejemplo, un TTL de 3 600 significa que el resolutor usará la respuesta en caché durante 1 hora. El TTL lo define el administrador de la zona DNS, no el protocolo. Cada registro puede tener su propio TTL.
¿Hay que esperar 24 a 48 horas después de un cambio DNS?
No. Ese plazo solo se impone si el TTL del registro modificado es de 86 400 segundos (24 horas), que corresponde al valor por defecto histórico de algunos registradores. Con un TTL de 3 600 segundos (1 hora, valor habitual en 2026), el plazo máximo es de 1 hora. Preparando la migración (reducción del TTL a 300 segundos 48 horas antes), el cambio es visible en 5 minutos. La recomendación de «24 a 48 horas» es un redondeo de precaución de los años 2000 que ya no refleja la realidad técnica actual.
¿Cómo vaciar la caché DNS?
La caché DNS existe en varios niveles. Para vaciar la caché de tu máquina: en Windows, ejecuta ipconfig /flushdns en PowerShell; en macOS, ejecuta sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder en el Terminal; en Linux con systemd, ejecuta sudo systemd-resolve --flush-caches. Para Chrome, accede a chrome://net-internals/#dns y haz clic en «Clear host cache». Para vaciar la caché de los resolutores públicos, usa las interfaces de Google Public DNS y Cloudflare 1.1.1.1. La caché del resolutor de tu ISP no se puede purgar manualmente.
¿Por qué los resolutores DNS dan resultados diferentes?
Tres razones explican este comportamiento. Primero, cada resolutor almacenó el registro en caché en un momento diferente, por lo que el TTL expira en instantes distintos. Segundo, los grandes resolutores (Google, Cloudflare) usan redes anycast con cientos de servidores independientes; el servidor que atiende a Madrid no tiene la misma caché que el que atiende a Tokio. Tercero, algunos dominios usan EDNS Client Subnet (ECS) para devolver direcciones IP geolocalizadas, lo que produce respuestas legítimamente diferentes según la ubicación del cliente.
¿Cambiar de resolutor DNS acelera la propagación?
No, no de manera fiable. Cambiar de resolutor en tu equipo (pasar de 8.8.8.8 a 1.1.1.1, por ejemplo) puede dar la impresión de que el cambio está propagado si el nuevo resolutor no tiene el registro antiguo en caché. Pero eso no acelera nada para los demás usuarios. El «plazo de propagación» está ligado al TTL de la caché de cada resolutor, y no puedes controlar la caché del resolutor que usan tus visitantes. El único método fiable para acelerar la propagación es reducir el TTL antes del cambio.
¿Cómo verificar si la propagación DNS ha terminado?
Consulta al menos cuatro resolutores públicos principales con dig: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) y OpenDNS (208.67.222.222). Si todos devuelven el nuevo valor, la propagación está completa para la gran mayoría de los usuarios. Para una verificación exhaustiva, usa una herramienta de test de propagación multi-resolutores que consulte servidores repartidos en varios continentes y muestre los resultados en tiempo real. Mientras al menos un resolutor devuelva el valor antiguo, la propagación no ha terminado.
Glosario
- TTL (Time To Live): duración en segundos durante la cual un resolutor DNS puede conservar un registro en caché antes de volver a solicitarlo al servidor autoritativo. Definido por el administrador de zona.
- Resolutor recursivo: servidor DNS que recibe las consultas de los clientes y realiza la resolución completa consultando la jerarquía DNS (raíz, TLD, autoritativo). Ejemplos: Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1).
- Servidor autoritativo: servidor DNS que posee los registros originales de una zona DNS. Es la fuente de verdad para los registros de un dominio.
- Caché DNS: memoria temporal donde un resolutor almacena las respuestas DNS ya obtenidas. La caché reduce la carga en los servidores autoritativos y acelera las respuestas.
- Zona DNS: conjunto de registros DNS para un dominio y sus subdominios, alojado en uno o varios servidores autoritativos.
- Registro NS (Name Server): registro que designa los servidores autoritativos para una zona DNS. Publicado tanto en la zona padre (delegación) como en la propia zona.
- Stub resolver: componente del sistema operativo que transmite las consultas DNS al resolutor recursivo configurado. Mantiene una caché local mínima.
- SOA (Start of Authority): registro obligatorio en cada zona DNS que contiene los metadatos de la zona (serial, refresh, retry, expire, TTL negativo).
- NXDOMAIN: respuesta DNS que indica que el nombre de dominio solicitado no existe. Esta respuesta se almacena en caché según el TTL negativo definido en el SOA.
- Anycast: técnica de enrutamiento de red en la que una misma dirección IP se anuncia desde múltiples ubicaciones geográficas. Los resolutores públicos usan anycast para dirigir las consultas hacia el servidor más cercano.
La herramienta de test de propagación CaptainDNS consulta resolutores repartidos en todos los continentes y muestra en tiempo real el estado de la caché para cada registro. Úsala para confirmar que un cambio DNS es visible en todas partes antes de considerar la migración terminada.
Fuentes
- RFC 1035: Domain Names - Implementation and Specification (IETF, sección 3.2.1 para la definición del TTL)
- RFC 2181: Clarifications to the DNS Specification (IETF, sección 8 para las reglas de TTL)
- RFC 2308: Negative Caching of DNS Queries (IETF, caché negativa y SOA minimum TTL)
- Google Public DNS: Flush Cache (documentación oficial de la interfaz de purga)
- Cloudflare 1.1.1.1: Purge Cache (documentación oficial de la interfaz de purga)
