Migración de DNS a Cloudflare: la lista de control que evita tres horas de apagones

La migración de DNS a Cloudflare tiene fama de ser trivial: importe la zona, señale los servidores de nombres y espere a que se propague. Los equipos que estuvieron bloqueados durante tres horas siguieron exactamente este guión. El problema es que "trivial" describe el caso perfecto y la producción rara vez es perfecta.

Lo que la importación automática no hace por ti

Cuando agrega un dominio a Cloudflare, la plataforma consulta los servidores autorizados del proveedor actual e intenta importar todos los registros en la zona. El resultado es una lista de registros que parece completa (y casi siempre lo está). El "casi" es donde reside el riesgo.

Los registros de tipo TLSA, utilizados para DANE (autenticación de entidad con nombre DNS), a menudo no se importan. Lo mismo sucede con algunos registros SRV con configuraciones no estándar, registros CAA con múltiples indicadores o valores inusuales y cualquier registro que el proveedor anterior proporcione a través de una respuesta no estándar. La importación de Cloudflare es un punto de partida, no una garantía de lealtad.

El protocolo correcto es: después de la importación, exporte la zona del proveedor actual en formato BIND (la mayoría de los proveedores ofrecen esto) y compare manualmente los dos conjuntos de registros. Herramientas como diff contra el archivo de zona exportado revelan lo que omitió la importación. Este paso lleva veinte minutos y evita descubrir, después de activar los servidores de nombres, que el certificado de correo electrónico ha dejado de validarse porque falta un registro TLSA.

Servicios proxy y no HTTP de Cloudflare

Cloudflare opera en dos modos para cada registro A o AAAA: proxy (el tráfico pasa a través de la red de Cloudflare, la IP real está oculta) y solo DNS (resolución pura, sin intermediación). Los registros MX importados son solo DNS de forma predeterminada, lo cual es correcto porque SMTP no pasa por el proxy de Cloudflare.

El problema aparece con los registros A que apuntan a servidores de correo electrónico o cualquier servicio que no sea HTTP/HTTPS. Un registro A llamado mail.exemplo.com que apunta al servidor SMTP puede ser proxy por accidente durante la configuración, especialmente si alguien está revisando los registros y habilitando el proxy por lotes. El resultado es que el servidor de correo electrónico ahora expone las IP de Cloudflare en lugar de la IP real, y las conexiones SMTP externas llegan a un proxy que no sabe qué hacer con ellas. El error no es inmediato: algunos clientes de correo electrónico vuelven a intentarlo, el tiempo de espera tarda unos minutos y el problema parece intermitente antes de volverse consistente.

Lo mismo ocurre con las bases de datos expuestas vía DNS. Un registro A que se resuelve en un servidor MySQL o PostgreSQL detrás del proxy devuelve la IP de Cloudflare. La aplicación intenta conectarse al puerto 3306 o 5432, el proxy se niega (no admite estos puertos de forma predeterminada) y la conexión falla con un tiempo de espera. El servicio parece estar inactivo, pero el DNS está "funcionando": simplemente apunta al lugar equivocado.

Antes de invertir los servidores de nombres, revise cada registro A y AAAA y confirme el modo correcto. La regla es sencilla: si el servicio en esa dirección no responde exclusivamente en HTTP/HTTPS en los puertos 80 y 443, el modo debe ser solo DNS.

TTL y ventana de propagación

La propagación del servidor de nombres no es instantánea y el TTL de los registros en el proveedor actual determina cuánto tiempo les toma a los solucionadores de todo el mundo descartar el caché antiguo. Si sus registros tienen un TTL de 86400 segundos (24 horas), el estándar para muchos proveedores, y enciende los servidores de nombres ahora, algunos de los solucionadores continuarán entregando los registros antiguos por hasta 24 horas, independientemente de lo que Cloudflare ya diga.

La estrategia correcta comienza dos días antes de la migración. Reduzca el TTL de todos los registros críticos a 300 segundos (cinco minutos) en el proveedor actual. Esperar el tiempo equivalente al TTL original: si los registros estaban a 3600 segundos esperar una hora; si estuvieran en 86400 esperar 24 horas. Sólo entonces enciende los servidores de nombres. Por lo tanto, cuando se produce el cambio, los cachés de todo el mundo caducan en un máximo de cinco minutos y cualquier problema que surja durante la migración se resuelve rápidamente: no tendrá que esperar a que caduquen los cachés de 24 horas mientras se produce el incidente.

Este paso es el que con mayor frecuencia se ignora porque requiere una planificación anticipada. Quienes llegan el día anterior a la migración y notan que los TTL están en 86400 tienen dos opciones: bajar el TTL y esperar 24 horas antes de continuar, o aceptar el riesgo de una ventana de propagación larga. La segunda opción es el camino más común hacia un apagón que dura más de lo que debería.

DNSSEC: el detalle que convierte la propagación en un fallo de validación

Si el dominio tiene DNSSEC activo en el proveedor actual, migrar los servidores de nombres sin manejar los registros DS en el registrador provoca una falla de validación en todos los solucionadores que verifican DNSSEC. El solucionador recibe una notificación de que el dominio usa DNSSEC (a través del registro DS en el registrador), consulta Cloudflare, recibe firmas firmadas con claves de Cloudflare y rechaza la respuesta porque las claves no coinciden con el DS que todavía apunta al proveedor anterior.

La secuencia correcta tiene cuatro pasos con ventanas de espera en el medio. Primero, elimine los registros DS del registrador (no del proveedor de DNS, sino del registrador donde está registrado el dominio). En segundo lugar, espere a que caduque el TTL de los registros DS (normalmente entre una y cuatro horas, según la grabadora). En tercer lugar, cambie los servidores de nombres a Cloudflare. Cuarto, habilite DNSSEC dentro del panel de Cloudflare y agregue los nuevos registros DS que la plataforma proporciona al registrador. Saltarse el periodo de espera entre el primer y tercer paso es la causa más común de incidencias DNSSEC en las migraciones.

Cómo estructurar la migración para no improvisar bajo presión

La diferencia entre una migración que finaliza en treinta minutos y otra que se convierte en un incidente de tres horas es casi siempre organizativa. Los equipos que se desempeñan bien definen de antemano quién valida cada paso, qué configura la reversión y cuáles son los criterios de éxito antes de declarar completa la migración.

La secuencia operativa que funciona comienza con la comparación de zonas entre el proveedor actual y Cloudflare, realizada antes de cualquier pivote. Los dominios con SPF, DKIM y DMARC requieren atención especial: los registros TXT pueden tener comillas o concatenaciones que importan automáticamente el formato, rompiendo la validación incluso si el contenido parece correcto. Los registros SRV para servicios como SIP, XMPP o Minecraft necesitan prioridad manual y verificación del campo de peso.

Una vez que se entregan los servidores de nombres, el protocolo de verificación tiene tres comandos que deben ejecutarse en secuencia. El comando dig @1.1.1.1 +short exemplo.com NS confirma que Cloudflare ya tiene autoridad para el dominio en ese solucionador. El comando dig @8.8.8.8 +short mail.exemplo.com A verifica que el registro de correo electrónico devuelva la IP real del servidor, no una IP de Cloudflare. Una prueba de envío de correo electrónico desde una dirección externa dentro de los primeros treinta minutos después del envío cierra el ciclo de verificación básico.