Cómo monitorizar la propagación de DNS tras un cambio de registrador

Las migraciones de DNS parecen simples sobre el papel y generan incidentes reales en la práctica. Los registros se actualizan en el registrador, los TTL expiran, el mundo refresca su caché de DNS y todo funciona. O eso dice la teoría. En realidad, la propagación parcial ocurre con frecuencia: algunos resolutores sirven el nuevo registro, otros sirven el antiguo, y el comportamiento del usuario final se divide por líneas regionales o de ISP. Esta guía cubre cómo monitorizar una migración de DNS, qué comprobar y cómo detectar los fallos que un DNS silencioso no revela.

Cómo funciona realmente la propagación de DNS

Cuando cambias un registro DNS en el registrador, el registro antiguo permanece en las cachés de los resolutores de todo el mundo hasta que expira su TTL. Distintos resolutores se actualizan en distintos momentos; algunos respetan el TTL estrictamente y otros lo redondean hacia arriba. El resultado es una ventana (normalmente un TTL más unos minutos, pero a veces horas) durante la cual distintos usuarios ven distintos registros.

Tu propio resolutor puede ser el último en actualizarse, porque los sistemas operativos y las aplicaciones cachean DNS de forma agresiva por encima del resolutor del sistema. El error clásico es hacer ping al nuevo endpoint desde tu portátil, ver que funciona, declarar la propagación completa y descubrir a la mañana siguiente que los clientes de la UE siguen llegando a la IP antigua.

Qué monitorizar durante una migración

Cuatro tipos de registros DNS cubren los casos habituales de migración. Cada uno necesita su propio monitor durante el cambio.

• Registros A y AAAA para el nombre de host que estás migrando. La comprobación principal: ¿se está sirviendo la nueva IP?
• Registros CNAME para cualquier subdominio que use uno. Las cadenas de CNAME pueden romperse silenciosamente si un eslabón apunta a un host inexistente.
• Registros MX si hay correo de por medio. Una migración MX defectuosa produce rechazo silencioso de correo sin un síntoma obvio de cara al cliente.
• Registros NS si estás cambiando de proveedor de DNS. El registro NS es la base; si está mal, lo demás no importa.

Comprobación multirregional

Un monitor de DNS que se ejecuta desde un único resolutor en una única región pierde todo el sentido. La pregunta interesante es si el nuevo registro se ha propagado por todas partes, no si el resolutor local de tu monitor se ha refrescado.

Herramientas como dnschecker.org te permiten comprobar puntualmente la propagación en varias regiones de forma interactiva. Para la monitorización automatizada, quieres una herramienta que consulte varios resolutores y alerte ante cualquier discrepancia. Si tu herramienta de monitorización solo comprueba desde una ubicación, ejecuta una comprobación manual adicional desde otra región (tu móvil con datos móviles suele bastar) antes de dar por completada la migración.

Reducir los TTL antes de la migración

La preparación más útil con diferencia es reducir el TTL de los registros afectados entre 24 y 48 horas antes del cambio. El nuevo TTL tiene que propagarse primero, por eso importa la antelación.

• Antes de la migración: baja el TTL del valor por defecto de 3600 (1 hora) a 60 (1 minuto). Espera a que la bajada del TTL se propague, lo que lleva un ciclo del TTL antiguo más un margen.
• Durante la migración: actualiza el registro. Los resolutores se refrescan en 60 segundos.
• Después de la migración: monitoriza durante 24 horas para detectar cualquier caché atascada. Restaura el TTL a 3600 cuando estés seguro de que la propagación se ha completado.

Detectar el fallo silencioso de propagación parcial

La propagación parcial es el modo de fallo que más duele. La mitad de tus clientes ven el nuevo endpoint, la otra mitad ve el antiguo, y el estado medio roto es invisible para tu propia monitorización si solo comprueba desde un punto.

Tres señales lo detectan. Un pico en los tickets de soporte que mencionan el comportamiento antiguo o el nombre de host antiguo. Una divergencia en las métricas de usuario entre regiones (la conversión en EE. UU. cae mientras la de la UE se mantiene estable). Un monitor que comprueba explícitamente el resolutor de cada región por separado y alerta ante la discrepancia. Mantén las tres durante al menos 24 horas después de una migración.

Una lista de comprobación previa a la migración

Dos días antes de la migración, baja el TTL de todos los registros afectados a 60 segundos. El día anterior, añade monitores de DNS para los nuevos valores de los registros; se espera que se disparen porque los registros aún no han cambiado. El día de la migración, actualiza los registros. Los monitores pasan a verde. Vigila durante 24 horas, prestando atención a las discrepancias multirregionales y al volumen de tickets de soporte. Una vez que ambos estén limpios durante 24 horas, restaura los TTL y elimina los monitores temporales. La migración está completa cuando las métricas están limpias, no cuando los registros se han actualizado.