Cómo verificar que una migración de DNS salió bien

Migrar el DNS (cambiar de proveedor, pasar a una nueva configuración de servidores de nombres o reestructurar un gran conjunto de registros) conlleva más riesgo que la mayoría de los cambios de infraestructura, precisamente porque un error no falla de forma ruidosa. Un registro roto simplemente deja de resolverse sin avisar, o se resuelve a lo que no debe, y la primera señal suele ser un ticket de soporte y no una alerta.

Antes de la migración

• Exporta todos los registros existentes del proveedor actual: un archivo de zona completo o equivalente, no solo los que recuerdas haber configurado.
• Baja los TTL de los registros que van a cambiar, con al menos un ciclo completo de TTL de antelación.
• Anota los valores actuales de todo: A/AAAA, CNAME, MX, TXT (incluidos SPF/DKIM/DMARC) y cualquier tipo de registro menos habitual que esté en uso.

Después de la migración

1. Consulta directamente los nuevos servidores de nombres autoritativos por cada registro migrado y compara cada respuesta con tu exportación previa a la migración.
2. Comprueba A y AAAA de forma independiente en cada nombre de host que tuviera alguno de los dos: es fácil migrar una familia de direcciones y olvidar la otra.
3. Verifica específicamente MX y los registros de autenticación de correo asociados: las averías de correo por una migración de DNS son desproporcionadamente frecuentes y desproporcionadamente perjudiciales.
4. Vuelve a comprobar desde más de un resolvedor y, a ser posible, desde más de una ubicación de red antes de dar la migración por completada.
5. Espera a que pase la ventana del TTL antiguo y vuelve a comprobar: un resultado limpio justo después del cambio no garantiza que todos los resolvedores con caché del mundo se hayan puesto al día.

Una consulta masiva que cubra la lista completa de nombres de host, ejecutada una vez justo después del cambio y otra cuando haya pasado la ventana del TTL antiguo, convierte esto de una comprobación manual registro por registro en un único paso repetible, y te deja un registro exportable de exactamente qué se verificó y cuándo.

No desmontes demasiado pronto el lado antiguo

Lo que más suele lamentarse tras una migración no es un registro omitido, sino que la cuenta o los servidores de nombres del proveedor antiguo se cancelen o se den de baja el mismo día en que entran en servicio los nuevos. Como una parte de los resolvedores del mundo sigue trabajando con respuestas en caché que apuntan a la configuración antigua hasta que caduca su TTL, mantener activo al proveedor anterior (aunque nada nuevo apunte a él) durante al menos una ventana completa del TTL antiguo tras el cambio es un seguro barato. Si hace falta una reversión rápida, que el lado antiguo siga respondiendo marca la diferencia entre devolver los servidores de nombres a su sitio en minutos y reconstruir de memoria un archivo de zona bajo presión.

Un ensayo detecta la mayoría de los problemas antes de que sean reales

Cuando el nuevo proveedor de DNS lo permite, montar con antelación la zona nueva completa (totalmente configurada, pero sin delegar todavía hacia ella) y consultarla directamente (saltándote la delegación normal, ya sea apuntando una herramienta de prueba a sus servidores de nombres de forma explícita o usando la función de vista previa del propio proveedor) convierte la verificación de la migración de una carrera apresurada posterior al cambio en una comprobación previa al cambio, sin ningún impacto para los usuarios si algo va mal. Cualquier registro que falte, esté mal configurado o sea simplemente distinto de lo previsto aparece antes de que un solo resolvedor real lo haya visto, y ese es un lugar mucho menos estresante para detectar un error que después de que el cambio ya esté en producción.