Cómo se propaga el DNS en todo el mundo

Actualiza un registro A, recarga el navegador y sigue viendo el servidor antiguo. Un compañero en otra ciudad ya ve el nuevo. Alguien le dice que “espere a que se propague el DNS” y que puede tardar hasta 48 horas. La frase es tan habitual que la mayoría de la gente imagina los cambios de DNS extendiéndose lentamente por el planeta como una ola. La realidad es más sencilla y, una vez entendida, mucho más fácil de controlar.

Esta guía explica qué ocurre realmente cuando cambia el DNS, por qué distintas personas ven respuestas distintas en el mismo momento, en qué se diferencian los cambios de servidores de nombres de los cambios de registros normales y cómo comprobar y acelerar el proceso. Si antes necesita repasar los tipos de registro, lea nuestra guía de fundamentos de los registros DNS.

La propagación es en realidad caducidad de caché

Nada se “propaga” en el sentido de copiarse de servidor en servidor alrededor del globo. Cuando edita un registro en su proveedor DNS, el cambio llega a sus servidores de nombres autoritativos casi de inmediato (la mayoría de proveedores sincronizan sus propios servidores en cuestión de segundos o pocos minutos). A partir de ese momento, la respuesta correcta está disponible para cualquiera que pregunte.

El retraso lo provocan los resolutores recursivos: los servidores DNS que gestionan los proveedores de internet, las empresas y servicios públicos como Google Public DNS, Cloudflare 1.1.1.1 o Quad9. Cuando un resolutor consulta su dominio, guarda la respuesta en su caché durante el tiempo que permite el TTL (time to live) del registro. Hasta que ese temporizador se agota, sigue entregando la respuesta guardada sin volver a preguntar a sus servidores de nombres.

Así que, cuando se habla de propagación, en realidad se pregunta: “¿Cuánto falta para que todos los resolutores que guardaron la respuesta antigua la dejen caducar?”. Cada resolutor guardó su registro en un momento distinto, así que cada uno caduca en un momento distinto. Por eso los resultados parecen aleatorios e irregulares durante un cambio. Para profundizar en cómo elegir los valores de TTL, consulte el papel de la configuración del TTL en el DNS.

Las capas de caché entre usted y la respuesta

Una sola consulta puede pasar por varias cachés, y cualquiera de ellas puede conservar el valor antiguo:

• Caché del navegador: los navegadores mantienen su propia caché DNS de corta duración.
• Caché del sistema operativo: Windows, macOS y muchas configuraciones de Linux (por ejemplo, con systemd-resolved) guardan respuestas en local.
• Router o red local: los routers domésticos y los reenviadores DNS de oficina también suelen tener caché.
• Resolutor recursivo: el de su proveedor de internet o uno público, compartido por muchos usuarios.
• Caché negativa: si alguien consultó un nombre antes de que existiera, la respuesta “no existe” se guarda según la configuración del SOA de la zona.

Algunos resolutores aplican además sus propios TTL mínimos o máximos, y se sabe que unos pocos conservan los registros más tiempo del indicado. Es una de las razones por las que cualquier plazo que lea debe tomarse como un rango típico y no como una garantía.

Cambios de registros frente a cambios de servidores de nombres

No todos los cambios de DNS se comportan igual. La pregunta clave es dónde están los datos en caché.

Cambiar un registro dentro de su zona

Editar un registro A, AAAA, CNAME, MX o TXT solo afecta a los datos de sus propios servidores autoritativos. El tiempo de espera lo determina el TTL que tenía ese registro antes del cambio. Si el registro A antiguo tenía un TTL de 3600 segundos, los resolutores que lo guardaron justo antes de su edición pueden conservarlo hasta una hora.

Cambiar los servidores de nombres

Pasarse a un nuevo proveedor DNS implica cambiar los registros NS en su registrador, que envía la actualización al registro de su TLD (por ejemplo .com o .de). El registro publica entonces la nueva delegación en la zona padre. Aquí se suman dos retrasos:

1. El tiempo que tardan el registrador y el registro en procesar y publicar el cambio. Muchos registros lo publican en minutos, pero varía según el TLD.
2. El TTL de los registros NS de delegación en la zona padre, que usted no controla. En .com y .net suele ser de dos días (172800 segundos), y otros TLD usan sus propios valores.

Los resolutores también pueden guardar en caché los registros NS que servían los servidores de su proveedor antiguo. Por eso los cambios de servidores de nombres son el caso clásico de “hasta 48 horas”, mientras que un simple cambio de registro con un TTL bajo puede completarse en minutos. Durante una migración de proveedor, mantenga registros idénticos en los servidores antiguos y en los nuevos hasta que el tráfico se haya trasladado por completo.

Estos rangos son patrones generales, no promesas. El comportamiento de los resolutores, el procesamiento del registro y lo reciente que sea la última consulta de cada resolutor influyen en el resultado real.

Cómo planificar un cambio para que sea rápido

Como la espera la decide el TTL antiguo, el truco consiste en bajarlo antes de necesitar hacer el cambio:

1. Compruebe el TTL actual de los registros que va a cambiar.
2. Bájelo a un valor corto, como 300 segundos, con al menos un periodo completo del TTL antiguo de antelación (si el TTL era 86400, hágalo con más de un día de margen).
3. Haga el cambio cuando el TTL largo antiguo haya tenido tiempo de caducar en todas partes.
4. Verifique las nuevas respuestas desde varios resolutores.
5. Vuelva a subir el TTL cuando todo esté estable, para reducir la carga de consultas y mejorar la resiliencia.

En los cambios de servidores de nombres no puede acortar el TTL de la zona padre, pero sí evitar caídas manteniendo ambos proveedores en paralelo con registros idénticos.

Comprobar el avance desde varios resolutores

Una sola prueba desde su portátil solo le dice lo que cree su cadena local de cachés. Para hacerse una idea real, compare varias fuentes. Con dig puede consultar un resolutor concreto escribiendo su dirección tras la arroba:

dig example.com A +short @1.1.1.1
dig example.com A +short @8.8.8.8
dig example.com A +short @9.9.9.9

Para ver lo que dicen sus propios servidores, sin pasar por ninguna caché, pregunte directamente a un servidor de nombres autoritativo:

dig example.com NS +short
dig example.com A @ns1.your-dns-provider.net

La columna TTL de una respuesta normal de dig también indica cuántos segundos faltan para que un resolutor renueve su copia en caché, una forma práctica de estimar cuánto le queda por esperar. En los cambios de servidores de nombres, puede seguir la delegación desde la raíz con dig example.com +trace. También puede confirmar qué servidores de nombres figuran actualmente en el registro con la consulta WHOIS/RDAP de dominios de TLDix.

Los “comprobadores de propagación” en línea, que consultan resolutores de muchos países, pueden servir para hacerse una idea rápida, pero recuerde que solo muestran una muestra de resolutores en un momento dado.

Vaciar las cachés locales

Si los resolutores públicos ya devuelven la respuesta nueva pero su equipo no, lo más probable es que la copia obsoleta sea local. Formas habituales de borrarla:

• Windows: ejecute ipconfig /flushdns en una terminal.
• macOS: ejecute sudo dscacheutil -flushcache y después sudo killall -HUP mDNSResponder.
• Linux con systemd-resolved: ejecute resolvectl flush-caches.
• Chrome: abra chrome://net-internals/#dns y borre la caché de hosts.
• Router: reiniciarlo suele vaciar su caché.

No puede vaciar usted mismo el resolutor de su proveedor de internet. Algunos resolutores públicos, como los de Google y Cloudflare, ofrecen formularios web para purgar un nombre en caché, algo útil durante las pruebas.

Problemas habituales que parecen propagación lenta

Muchas quejas de “propagación” resultan ser errores de configuración. Antes de seguir esperando, descarte estos:

• Editar la zona equivocada: los cambios hechos en el panel DNS de un registrador no sirven de nada si el dominio usa otros servidores de nombres.
• Erratas en los registros: un punto que falta o una IP equivocada se parecen exactamente a una respuesta antigua en caché.
• Desajuste de DNSSEC: tras cambiar de proveedor, un registro DS desactualizado en el registro puede hacer que los resolutores validadores fallen por completo.
• Capas de CDN o proxy: si el tráfico pasa por una CDN, el DNS puede estar bien mientras la CDN sigue apuntando al origen antiguo.
• Caché de las aplicaciones: algunos programas y procesos de larga duración resuelven un nombre una vez y conservan el resultado hasta que se reinician.

Controlar los datos del dominio y del DNS

Los cambios de DNS suelen coincidir con otros acontecimientos: cambiar de alojamiento, renovar un dominio o sustituir un certificado SSL. Saber qué servidores de nombres usa un dominio, quién lo aloja y cuándo caduca ahorra tiempo cuando algo sale mal. TLDix le permite consultar los datos de registro y seguir las fechas de renovación, y la consulta de hosting le ayuda a ver desde dónde se sirve actualmente un sitio, algo muy útil justo después de una migración.

La lección principal es sencilla: los cambios de DNS llegan al mundo tan rápido como caducan las cachés antiguas. Planifique los TTL con antelación, verifique desde varios resolutores y rara vez tendrá que esperar las 48 horas completas.