Resumen

Este comprobador de propagación DNS estima cuánto tiempo puede seguir invisible un cambio DNS para algunos resolutores. La propagación es caducidad de caché: un resolutor conserva la respuesta antigua hasta que se agota su TTL, así que el peor caso equivale al TTL anterior. Los registros nuevos pueden quedar en caché como inexistentes durante el TTL negativo del SOA, y los cambios de servidores de nombres siguen el TTL NS del registry. Introduce el tipo de cambio, el TTL y el tiempo desde tu edición para ver la espera restante. Funciona en tu navegador y no consulta DNS en vivo.

Comprobador de propagación DNS: cuánto falta para que tu cambio esté activo

Introduce el TTL y el tiempo desde tu edición. Este comprobador de propagación DNS muestra la espera del peor caso para un cambio de registro, una clave DKIM nueva o un cambio de servidores de nombres.

Calcula tu ventana de espera

Comprobador de propagación DNS

Elige el tipo de cambio, introduce el TTL que corresponde y el tiempo desde que lo guardaste. El resultado se actualiza mientras escribes y nada sale de tu navegador.

El TTL que tenía el registro antes de editarlo, no el nuevo.

Cómo funciona

Lo que mide realmente la calculadora

La propagación es la caducidad de la caché

El DNS no envía los cambios a ningún sitio. Cada resolutor guarda la respuesta que obtuvo hasta que se agota el TTL y luego vuelve a preguntar. El resolutor más lento es el que obtuvo la respuesta antigua justo antes de tu edición, así que el peor caso equivale al TTL anterior.

Los registros nuevos tienen su propio reloj

Un registro que no existía también puede quedar guardado en caché como inexistente. Esa respuesta negativa dura lo que dure el menor entre el TTL del SOA y el campo minimum del SOA. Si nadie consultó el nombre antes, el registro nuevo es visible de inmediato.

Los cambios de servidores de nombres dependen del registry

Cambiar los servidores de nombres modifica los registros NS en la zona padre, y ese TTL no lo fijas tú. La calculadora lo toma como dato de entrada, con dos días como valor habitual para TLD grandes como .com.

Antes de un cambio DNS de email

Cuatro pasos que acortan la espera

Este es el orden que usamos para editar SPF, DKIM, DMARC y MX en un dominio de envío.

  1. 1

    Lee el TTL actual

    Ejecuta dig sobre el registro y lee el número de la sección de respuesta. Ese es el TTL que tu cambio tendrá que superar.

  2. 2

    Bájalo con antelación

    Pon el TTL en 300 segundos y espera al menos lo que dure el TTL anterior antes de editar el registro. Los resolutores tienen que caducar primero la copia de larga duración.

  3. 3

    Haz el cambio y anota la hora

    Guarda la edición, apunta la hora exacta e introduce el tiempo transcurrido en la calculadora de arriba.

  4. 4

    Verifica en el origen y luego en un resolutor

    Consulta primero tu servidor de nombres autoritativo y después un resolutor público. Sube el TTL de nuevo cuando ambos coincidan y la ventana haya pasado.

Preguntas frecuentes

¿Este comprobador de propagación DNS es gratuito?
Sí. Sin registro ni límite de peticiones. El cálculo es aritmética con tres números que escribes, así que se ejecuta en tu navegador y no se envía nada a nuestros servidores.
¿Consulta servidores DNS en tiempo real?
No. No busca tu registro en resolutores de todo el mundo. Calcula el tiempo máximo que puede sobrevivir una respuesta en caché, a partir del TTL que introduces. Para ver qué devuelve un resolutor concreto ahora mismo, ejecuta dig contra ese resolutor y compáralo con la ventana que se muestra aquí.
¿Por qué la estimación usa el TTL antiguo y no el nuevo?
Los resolutores guardan la respuesta que obtuvieron antes de tu edición, junto con el TTL que traía. Bajar el TTL en la misma edición no sirve de nada a los resolutores que ya tienen la respuesta antigua. El TTL nuevo solo se aplica a las respuestas obtenidas después del cambio.
¿Qué es el TTL de caché negativa y cuándo se aplica?
Cuando un resolutor pregunta por un nombre sin registro, puede guardar en caché la respuesta de «no existe» (RFC 2308). Dura lo que dure el menor entre el TTL del propio registro SOA y su campo minimum. Solo afecta a los resolutores que consultaron el nombre antes de que crearas el registro, por ejemplo un selector DKIM que alguien probó demasiado pronto.
¿Por qué un cambio de servidores de nombres tarda tanto?
Los registros NS que apuntan a tus servidores de nombres están en el registry, con un TTL que tú no controlas. En TLD grandes como .com ese TTL suele ser de dos días. Hasta que caduque, algunos resolutores siguen consultando tus servidores antiguos.
He pasado la ventana y sigo viendo el valor antiguo. ¿Qué hago?
Deja de culpar a las cachés. Consulta directamente tu servidor de nombres autoritativo y confirma que sirve el valor nuevo. Si no lo sirve, la edición se hizo en la zona equivocada, en el nombre de host equivocado o nunca se guardó. Si sí lo sirve, prueba desde un resolutor que no hayas usado antes y revisa si hay una caché local en tu equipo o en tu red.
¿Esto aplica a los registros SPF, DKIM y DMARC?
Sí. Son registros TXT y se guardan en caché como cualquier otro. Un servidor receptor que tenga en caché tu SPF antiguo seguirá evaluándolo hasta que caduque el TTL, así que un envío justo después de una edición puede juzgarse con la política anterior.

Controla la infraestructura detrás de tus propios envíos

Esta herramienta estima una espera. Notification Harbor cubre los envíos que tú controlas: calentamiento del dominio, observabilidad a nivel de traza y SPF, DKIM y DMARC bien configurados antes del primer envío en producción.

Mira cómo funciona Notification Harbor
notificationharbor
Empieza gratis