Cómo migrar DNS sin interrumpir la web ni el correo

Una migración DNS no mueve por sí sola la web, los buzones ni el dominio. Cambia qué servidores responden por la zona y, por tanto, qué registros encuentran los visitantes, proveedores de correo y servicios externos. El cambio puede ser breve y controlado si la nueva zona reproduce primero todo lo que debe seguir funcionando.

Distinguir dominio, DNS, web y correo

El registrador conserva la titularidad y permite delegar los nameservers. El proveedor DNS publica los registros. El hosting sirve la web y el proveedor de correo mantiene buzones y entrega. Pueden estar en cuatro empresas distintas. Antes de tocar nada conviene anotar quién controla cada capa y qué accesos existen.

1. Inventariar la zona completa

No basta con copiar el registro del dominio raíz y www. Hay que revisar A, AAAA y CNAME de web y subdominios; MX del correo; TXT de SPF, DKIM, DMARC y verificaciones; además de SRV, CAA u otros registros utilizados por aplicaciones. Una exportación de zona ayuda, pero debe compararse con el panel y con consultas DNS porque las importaciones automáticas pueden omitir nombres.

2. Preparar los destinos antes del cambio

La nueva web debe responder con el dominio previsto, certificado y redirecciones correctas. Las cuentas de correo, alias y políticas de autenticación deben existir en el proveedor que vaya a recibir mensajes. Si solo cambia el DNS, los destinos actuales se mantienen: no hay que modificar una dirección que ya es correcta por el simple hecho de cambiar nameservers.

3. Reducir TTL cuando todavía hay tiempo

Reducir con antelación el TTL de los registros que van a cambiar puede acortar cuánto tiempo conservan los resolvers una respuesta anterior. No elimina todas las cachés ni acelera una delegación de forma instantánea. Además, debe hacerse antes de la ventana: cambiar el TTL al mismo tiempo que la dirección no invalida respuestas que ya estaban almacenadas.

4. Revisar DNSSEC antes de cambiar nameservers

Si existe un registro DS en el registrador, la nueva zona debe coordinar correctamente DNSSEC. Una cadena de confianza que apunta a claves anteriores puede hacer que el dominio deje de resolver para usuarios que validan DNSSEC. La estrategia depende de las capacidades de ambos proveedores; no debe improvisarse durante el corte.

5. Cambiar una sola capa y registrar la hora

Cuando la zona nueva está completa se actualizan los nameservers en el registrador o, si solo cambian destinos, los registros correspondientes en el DNS autoritativo actual. Registrar hora, valores anteriores y persona responsable permite interpretar respuestas durante la transición y ejecutar una vuelta atrás sin reconstruir la configuración de memoria.

6. Verificar desde fuera del panel

El panel puede mostrar una configuración correcta antes de que sea la respuesta pública. Hay que consultar los nameservers autoritativos y varios resolvers, abrir web y subdominios, comprobar certificado y enviar mensajes en ambos sentidos. También se prueban formularios, SMTP y servicios que dependan de registros TXT o callbacks.

La propagación DNS no es un interruptor único: durante un periodo distintos resolvers pueden conservar respuestas diferentes.

7. Mantener origen y rollback durante la observación

Cerrar inmediatamente el hosting o correo anterior elimina una ruta de recuperación. Conviene conservarlo durante el periodo acordado, observar logs y comprobar que no recibe tráfico o mensajes relevantes. La vuelta atrás debe considerar datos nuevos: regresar un registro web es sencillo; reconciliar pedidos o correos creados en dos destinos puede no serlo.

Qué debería quedar documentado

La entrega útil incluye inventario de zona, proveedores y accesos, valores anteriores y nuevos, momento del cambio, pruebas realizadas y criterio para cerrar el origen. Así el siguiente ajuste de web, correo o dominio no vuelve a empezar con una investigación de emergencia.