Comprobador de propagación de DNS

Cómo comprobar si un cambio de DNS se ha propagado

Tres pasos, todos en esta página. La comprobación lee el DNS público por HTTPS desde tu navegador: no toca tu cuenta en el proveedor, y no hay nada que instalar ni cuenta que crear.

1. Escribe el dominio. Escribe el dominio, el nombre de host o la URL y pulsa Comprobar. La página lee la ficha del propio registro por RDAP, si la extensión la publica, y a la vez pregunta a dns.google y a cloudflare-dns por NS, SOA, A, AAAA, MX y TXT: la respuesta actual del registro junto a dos cachés independientes.
2. Lee primero la línea de la delegación. Tiene tres estados. NOERROR con servidores DNS significa que la delegación está intacta y esperas a las cachés. NXDOMAIN significa que la zona superior no tiene ninguna delegación para ti, y esperar no ayuda. SERVFAIL significa que la delegación existe, pero los servidores DNS que hay detrás no están sirviendo la zona.
3. Después compara el registro con los resolutores. Si el registro ya tiene tus servidores DNS nuevos y un resolutor sigue devolviendo los antiguos, ese resolutor guarda una copia en caché: eso es la propagación, y acaba sola. Si el propio registro sigue teniendo los antiguos, no hay nada en camino: el cambio nunca llegó y esperar no sirve. En .es, que no publica RDAP, compara los dos resolutores y pregunta a la zona .es con el dig que explicamos abajo.

Tres respuestas, no dos: NOERROR, NXDOMAIN, SERVFAIL

Casi todas las páginas sobre este tema reparten el mundo en dos cajas: o funciona, o «está propagando». Ese corte es el equivocado, y por eso hay quien espera tres días algo que nunca se iba a arreglar solo. Una consulta NS a tu dominio tiene tres respuestas, no dos: NOERROR con registros NS = la delegación existe y estás esperando a que caduquen las cachés; NXDOMAIN = la zona superior no tiene ninguna delegación para tu dominio; SERVFAIL = la delegación existe, pero ningún servidor autoritativo ha respondido.

Después, la herramienta lee el SOA, que separa los dos primeros casos sin margen de duda. Una zona sana responde con su propio SOA: la cadena desde la raíz, pasando por el TLD, hasta tus servidores se ha recorrido entera. Un dominio sin delegación responde NXDOMAIN y deja en la sección authority el SOA de la zona superior, que es el registro diciéndote que no tiene nada para ti. En el navegador los dos casos se ven igual, una web que no carga; como problema, no se parecen en nada.

Qué es de verdad la «propagación»

No hay propagación: nada se copia de servidor en servidor ni recorre el mundo. Cuando el registro publica la delegación nueva, sus servidores la sirven desde ese momento; lo que tarda son los resolutores que ya habían preguntado y guardan la respuesta antigua hasta que se agota su TTL. Por eso el techo no son «24 a 48 horas» ni «3 o 4 días», sino el TTL de los registros antiguos más el de los NS en la zona superior: 172800 segundos en .com y 86400 en .es, donde además hay que esperar a que Red.es publique. Un mapa mundial de propagación te enseña qué cachés han caducado, no si tu cambio es correcto. La herramienta te da el número, el TTL que le queda a cada copia, y una regla: dos resolutores con servidores distintos son propagación; dos que coinciden en una respuesta que no configuraste significan que el cambio no ha llegado al registro.

La fila del registro, arriba del todo, lo zanja sin deducciones. RDAP, el sucesor de WHOIS, responde por HTTPS con los servidores DNS que el registro tiene ahora, y la RFC 7480 recomienda que los navegadores puedan leer sus datos públicos. Si el registro ya tiene tus servidores DNS nuevos, estás esperando a las cachés; si todavía tiene los antiguos, el cambio no ha llegado. Responden así Verisign (.com, .net), PIR (.org), AFNIC (.fr) y los registros de .cat, .gal, .eus, .madrid y .barcelona. .es no: Red.es no está en el fichero de arranque RDAP de IANA, como tampoco .it, .pt o .eu, y ahí la fila sale vacía en lugar de adivinar.

Cuánto tarda de verdad un cambio de DNS en un .es: los dos relojes

Pregunta cuánto tarda un .es y cada proveedor te dará una cifra: unas 8 horas como mínimo y de 12 a 16 lo normal (Raiola), hasta 24-48 horas (Arsys), hasta 48 (IONOS), hasta 3 o 4 días en las extensiones territoriales (dinahosting). Ninguna es un reloj que puedas leer. Estos dos sí:

1. Red.es publica por tandas, no al momento. Según DonDominio, que avisa de que no hay confirmación oficial, y GINERNET, los cambios de servidores DNS entran en la zona .es seis veces al día: a las 02:00, 06:00, 10:00, 14:00, 18:00 y 22:00, hora peninsular, y cada tanda puede tardar hasta una hora en aplicarse. Su ejemplo: un cambio hecho a las 10:05 espera a la tanda de las 14:00. Nosotros vimos la zona .es cambiar de versión el 26 de septiembre de 2026 a las 11:51, que no es ninguna de esas horas: tómalas como aproximadas.
2. Después, la zona sirve tu delegación con un TTL de 86400 segundos. Un resolutor que se trajo la delegación antigua justo antes de la tanda puede quedársela un día entero. Medido ese mismo día en el servidor autoritativo:

dig +norecurse NS tu-dominio.es @a.nic.es
      tu-dominio.es.   86400   IN   NS   ns1.tu-proveedor.com.

Ese comando es también la mejor forma de ver qué tiene Red.es sin RDAP. Con +norecurse contra a.nic.es (o c, g y h.nic.es) no pasas por ninguna caché: es la delegación que la zona .es publica ahora. Si salen tus servidores nuevos, Red.es ya los tiene y lo que queda son cachés: hasta un día por la delegación, más el TTL de tus registros antiguos. Si salen los antiguos y desde el cambio ya ha pasado al menos una tanda completa (medio día es margen de sobra), no estás esperando: el cambio no ha llegado a Red.es. La versión de la zona que lees está en su número de serie, con el formato AAAAMMDDXX (fecha y número de cambio del día) que recomienda la guía DNS de Red.es:

dig +short SOA es. @a.nic.es
      ns1.nic.es. hostmaster.nic.es. 2026092608 7200 7200 2592000 86400

Un aviso sobre la herramienta: como en .es no puede leer el registro, si rellenas el campo de servidores antes de la tanda te marcará en rojo que no están activos. En .es eso puede ser solo la espera; el dig contra a.nic.es te dice cuál de las dos cosas es.

Red.es sin RDAP: qué comprueba, qué no y dónde se cambian los DNS

• Sin RDAP y con el whois cerrado. El whois de .es por el puerto 43 solo responde a IPs autorizadas de antemano —una por persona u organización, pedida con certificado de la FNMT o DNIe, con 10 consultas por minuto y dos horas de bloqueo si te pasas— y devuelve disponibilidad y titular, no servidores DNS. Desde una IP sin autorizar no devuelve nada: lo hemos probado. El whois público de dominios.es solo dice si el nombre está libre o ya registrado. Para ver los DNS, el dig de arriba.
• No cuentes con que Red.es te frene. Su guía DNS dice que, antes de cambiar la delegación, «es aconsejable» que los servidores nuevos estén operativos y den respuestas autorizadas para el dominio. Es un consejo: ni la guía ni el manual del panel de Dominios.es describen una comprobación que rechace el cambio. Si el cambio entra y los servidores nuevos aún no tienen la zona, lo que verás es SERVFAIL. Eso sí, la guía prohíbe las lame delegations y avisa de que la negligencia técnica puede acabar en la baja del dominio. Crea la zona primero; cambia los servidores después.
• Un .es caducado se apaga el mismo día. Al cumplirse la fecha de caducidad, Red.es lo deja «desactivado temporalmente» y, si nadie lo renueva, a los 10 días lo da de baja y queda libre. cdmon lo resume así: deja de estar operativo durante esos 10 días. Si tu .es dejó de responder justo en la fecha de renovación, mira eso antes que cualquier propagación.
• Registrado no es delegado. Red.es permite dar de alta un .es sin servidores DNS, solo para reservar el nombre. Hasta que alguien los pone, la herramienta dará NXDOMAIN aunque el dominio sea tuyo.
• Dónde se cambian. En el panel del agente registrador con el que registraste el dominio o, si lo gestionas directamente con Dominios.es, en el de Red.es, donde pueden hacerlo el contacto administrativo (PCA) y el técnico (PCT). Cada panel lo llama a su manera —«Servidores DNS» en dinahosting e IONOS, «Modificar las DNS del dominio» en Arsys, «Gestionar Nameservers» en Raiola, «servidores de nombres» en Hostinger—, pero siempre es la delegación. Los registros A, MX o TXT viven en otra pantalla («Entradas DNS», «Zona DNS»), y escribir ahí los servidores nuevos como registros NS no cambia nada en Red.es.

Caché negativa: por qué una delegación reparada sigue dando NXDOMAIN

La peor versión de esto es la que arreglas y no pasa nada. Después de reparar una delegación, NXDOMAIN puede seguir volviendo durante el TTL de caché negativa (el minimum del SOA). Los resolutores recuerdan «este nombre no existe» igual que una dirección; la RFC 2308 fija ese recuerdo en el menor entre el minimum del SOA y el TTL del propio registro SOA, y la guía DNS de Red.es lo dice igual. Por eso la herramienta lo da como un solo número. En com. son 900 segundos. En es., el minimum vale 86400, pero el SOA se sirve con TTL 3600: la ventana real es una hora, no un día (medido el 26 de septiembre de 2026; la calculadora de TTL hace la cuenta con cualquier par de valores).

Lo vivimos en junio de 2026: cuatro dominios .app perdieron su delegación en el registro y dieron NXDOMAIN en todo el mundo durante unos cuatro días. El registrador la restauró el 30 de junio a las 17:30 UTC y, esa tarde, buena parte de internet seguía sin verlos: sus resolutores estaban dentro de la ventana negativa. Mientras tanto, la zona de Cloudflare decía active y el registrador, verified; solo el DNS autoritativo público, leído desde dos resolutores independientes, decía la verdad (la crónica completa, en inglés). Por eso el chequeo de salud de cuatro capas empieza por la capa del registro.

Consecuencia práctica en un .es: arregla la delegación y dale una hora, más lo que falte para la siguiente tanda de Red.es, antes de dar el arreglo por fallido. Y no lo «arregles» otra vez mientras tanto.

Qué se rompe de verdad después de cambiar los DNS

Ocho fallos lo cubren casi todo. El estado de la delegación te dice en qué familia estás; esto te dice dónde mirar.

1. El proveedor aceptó el cambio y nunca lo mandó al registro. El panel dice «guardado» e internet sigue devolviendo los servidores antiguos. Síntoma: la fila del registro sigue mostrando los antiguos. En .es, donde esa fila sale vacía, los dos resolutores coinciden en los antiguos y dig +norecurse NS tu-dominio.es @a.nic.es también, pasada una tanda completa.
2. La zona nunca se creó en los servidores nuevos. La delegación apunta a servidores que no conocen tu dominio y se niegan a responder por él. Síntoma: SERVFAIL en los dos resolutores. Primero se crea la zona y después se cambia la delegación: ese orden es todo el truco, y en .es no cuentes con que el registro lo compruebe por ti.
3. DNSSEC se quedó activado durante la mudanza. El DS sigue en la zona superior con las claves del proveedor antiguo, así que todo resolutor que valida rechaza las respuestas del nuevo. Síntoma: SERVFAIL en todas partes, aunque los servidores nuevos respondan bien si les preguntas directamente. Quita el DS en el registrador, espera a que caduque su TTL y vuelve a activar DNSSEC en el lado nuevo. En .es, el DS también espera a la tanda.
4. Los registros no se copiaron. Delegación perfecta, zona activa y ni un A ni un AAAA para el nombre que la gente escribe. Síntoma: la delegación en verde y la fila de direcciones vacía. Es el motivo más habitual de una web caída tras un cambio de DNS «que funcionó». IONOS lo avisa en su ayuda: los registros que sigas editando en su panel no se ven en internet mientras el dominio use servidores DNS de otro.
5. Te olvidaste de MX, SPF, DKIM y DMARC. El correo se rompe más callado y más tarde que la web, porque los servidores que envían reintentan durante días antes de que alguien vea un rebote. Mira las filas MX y TXT, no solo las de direcciones. Si el dominio tiene un buzón del que depende tu agente, la parte del correo (en inglés) se apaga en el mismo momento.
6. Simplemente estás dentro de un TTL antiguo y largo. No hay nada roto: algunas cachés siguen guardando registros que se publicaron con una vida larga. El TTL restante de cada respuesta es la cuenta atrás.
7. El dominio caducó, o salió de la zona, en plena mudanza. El que nadie busca, porque en el navegador no se distingue de los demás. Síntoma: NXDOMAIN con el SOA de la zona superior en la sección authority y, donde hay RDAP, un estado como client hold, server hold o redemption period en la fila del registro. En .es no verás estados: basta con que haya pasado la fecha de caducidad. Renueva, recupera o habla con el registrador; esperar no sirve.
8. Un bloqueo rechazó el cambio. client update prohibited le dice al registro que rechace cualquier cambio en el dominio, y server update prohibited es el mismo bloqueo puesto por el propio registro. Si la fila del registro muestra cualquiera de los dos junto a los servidores antiguos, el bloqueo es el primer sospechoso: uno client se quita en el registrador; uno server, solo a través del registro.

Las mismas comprobaciones desde un terminal

Aquí no hay nada propietario: la página envuelve dos resolutores públicos y el RDAP de cada registro, y la herramienta imprime los comandos exactos para tu dominio. Los que importan:

dig NS ejemplo.es +short                 # a qué resuelve la delegación
      dig @8.8.8.8 NS ejemplo.es +short        # la misma pregunta, a una caché concreta
      dig @1.1.1.1 NS ejemplo.es +short        # y a otra: dos respuestas distintas = propagación
      dig SOA ejemplo.es                       # con NXDOMAIN, la sección authority nombra la zona que lo niega
      dig +norecurse NS ejemplo.es @a.nic.es   # lo que publica ahora la zona .es, sin cachés de por medio
      curl -sL https://rdap.org/domain/ejemplo.com   # la ficha del registro: servidores DNS, estado, DNSSEC

El último no sirve para .es: rdap.org devuelve 404 porque no encuentra ningún RDAP de Red.es, y para eso está la línea de a.nic.es. dig +trace NS ejemplo.es recorre la cadena entera, de la raíz al TLD y a tus servidores, y te enseña en qué salto se rompe. Sin dig (Windows, un portátil de empresa, el móvil), los mismos resolutores responden por HTTPS:

curl -s -H 'accept: application/dns-json' \
        'https://dns.google/resolve?name=ejemplo.es&type=NS'

Es literalmente la petición que hace esta página. En el JSON, Status es el RCODE (0 NOERROR, 2 SERVFAIL, 3 NXDOMAIN), Answer trae los registros y, en una negación, Authority trae el SOA de la zona que la emite.

Lo que un navegador no ve, y lo que añade la comprobación completa

Un navegador habla por HTTPS con resolutores recursivos y, en la mayoría de extensiones, con el RDAP del registro: lee lo que tiene el registro, si la cadena de delegación resuelve y qué responde la zona. No puede preguntar a los servidores de tu TLD (eso lo hace el dig contra a.nic.es), no ve tu cuenta ni la cola de cambios del registrador, no ve el registro en extensiones sin RDAP legible —.es incluida— y no ve nada fuera del DNS público: un proxy delante de la web, un certificado sin emitir, un hosting sin vincular, un origen que devuelve 502. Todo eso se parece a «la web no carga desde que cambié los DNS» y nada de eso es DNS.

clize domain check <dominio> es esta misma primera capa con tres más encima: la misma sonda DoH con dos resolutores —dns.google primero, cloudflare-dns de respaldo, el RCODE leído en tres estados— y después la zona de Cloudflare, la vinculación del nombre de host al worker del sitio y si el contenido se sirve de verdad. Cuatro capas, un comando: una luz verde significa «accesible», no solo «delegado». Sin argumento repasa todos los dominios de la cuenta, y la plataforma lo repite con un cron cada 30 minutos y solo avisa por correo tras dos rondas seguidas con fallo. Nació de la caída de junio, junto con la verificación de la delegación después de cada despliegue. El resto está en Agent Domains, registrar dominios por programa y la referencia de comandos (en inglés); desplegar la web del dominio es otro comando y otra capa.

$ npm i -g @clize/clize && clize install
$ clize domain check tu-dominio.es