Definir qué se traslada realmente
Transferir un dominio a otro registrador, cambiar servidores DNS autoritativos, mover la web y cambiar de proveedor de correo son trabajos distintos. Escriba cuáles están incluidos. Un cambio de alojamiento web no exige trasladar también el correo.
Nuestra propuesta de entrega empieza con cuatro líneas: administración del dominio, DNS, web y correo. Cada una indica proveedor anterior, proveedor futuro, responsable y accesos necesarios. Así, «trasladar el dominio» se convierte en un conjunto concreto de cambios.
Guardar el inventario
Documentar nombres, valores, TTL, servicios y responsables.
Cambiar los destinos
Aplicar los cambios acordados y verificar los servicios.
Cerrar el entorno anterior
Limpiar referencias y accesos antes de liberar los recursos.
Un estado nuevo verificable
Los destinos nuevos están confirmados, el correo necesario sigue intacto y no quedan referencias involuntarias a servicios retirados.
Modelo de trabajo para un cambio controlado. El inventario, la transición y la retirada se aprueban por separado.
Conservar expresamente las dependencias
Compare cualquier importación automática de DNS con el inventario existente. Cloudflare aconseja revisar los registros de los servicios utilizados y confirmar los valores de correo con su proveedor.
Guarde la zona anterior y asigne a alguien la investigación de los registros sin explicación. Una agencia nueva no debería adivinar si un valor TXT poco comprensible sigue siendo necesario. Pida una decisión documentada. «Desconocido» no es una justificación suficiente para eliminarlo. [1]
Deslice la tabla horizontalmente para leerla.
| Registro o área | Pregunta antes del cambio | Validación |
|---|---|---|
| A, AAAA y CNAME de la web | ¿Qué nombres apuntarán a la web nueva? | Comprobar dirección principal, www y subdominios acordados. |
| MX y destinos de correo | ¿Se mantiene el proveedor de correo? | Confirmar recepción y envío con pruebas autorizadas. |
| SPF, DKIM y DMARC | ¿Qué servicios activos necesitan estos valores? | Revisar autenticación por cada ruta de envío. |
| Valores de servicio y verificación | ¿A qué servicio y cuenta corresponden? | Conservar, sustituir o justificar la retirada. |
| DNSSEC y delegación | ¿Cambian los servidores DNS o las claves? | Comprobar resolución y cadena de confianza por separado. |
Una TTL corta no sustituye la planificación
La TTL indica cuánto tiempo puede almacenarse en caché una respuesta DNS. Reducirla después no borra retroactivamente las respuestas ya guardadas.
Ejemplo de planificación, no plazo universal: un registro pasa de 3.600 a 300 segundos. Reducir la TTL al cambiar el destino no elimina la hora de caché que antes era posible. Programe la reducción con antelación y mantenga el servicio anterior durante una transición acordada. Otras cachés, la delegación y DNSSEC pueden tener tiempos propios. [2]
No dejar subdominios apuntando a recursos liberados
Una referencia DNS a un recurso retirado que un tercero pueda reclamar puede permitir la toma de control de un subdominio. Que el destino no resuelva no demuestra, por sí solo, esa posibilidad.
Por cada servicio retirado, anote nombre, destino, cuenta anterior, responsable y decisión de cierre. Modifique o elimine la referencia de forma controlada, considere las cachés restantes y después libere el recurso. Revise los enlaces en aplicaciones y documentos. Evite desactivar por error un servicio nuevo que use legítimamente el mismo nombre. [3]
Incluir DNSSEC en el plan de cambio
Al cambiar servidores DNS, el registro DS de la zona superior debe ser coherente con las claves DNSSEC. Una cadena de confianza obsoleta puede causar SERVFAIL en los resolutores que validan.
El responsable DNS debe planificar la migración concreta. Algunos proveedores permiten una transición coordinada con firma activa. En otros casos, la desactivación temporal y la reactivación deben formar parte del mismo cambio. Dejar DNSSEC desactivado permanentemente no es un cierre adecuado. Si solo cambia el alojamiento web, compruebe primero si la cadena de confianza necesita modificarse. [4] [5]
Cerrar después de la aceptación
Una captura de la portada nueva es solo una parte de la validación. Acuerde responsable, fecha de revisión y vía de reversión. El registro debe distinguir lo comprobado de lo pendiente. Una prueba de correo no realizada sigue pendiente.
- Comparar el inventario DNS anterior y posterior.
- Abrir web, www, redirecciones y subdominios acordados.
- Documentar pruebas de correo autorizadas y autenticación del remitente.
- Revisar DNSSEC y delegación cuando estén afectados.
- Eliminar referencias antiguas y después liberar recursos sin uso.
- Revocar accesos de agencia y claves API innecesarios.
- Registrar nuevos responsables y una fecha de seguimiento.
Plantilla de traspaso de DNS
Documente la migración en un registro compartido. La plantilla CSV incluye el sitio web, el correo, los registros de verificación y DNSSEC. Añada una fila independiente por cada registro DNS realmente utilizado. La plantilla no contiene resultados de pruebas ni realiza consultas o cambios.
Obtenga los valores actuales y previstos de las cuentas de los proveedores correspondientes. Registre la autorización, el resultado esperado y la evidencia obtenida. Una prueba no realizada queda pendiente; una TTL corta o una página de inicio accesible no sustituyen la aceptación de todos los cambios.
Guarde el archivo completado en su propio almacenamiento protegido. No incluya contraseñas, claves API ni otras credenciales. No envíe detalles de la infraestructura mediante el formulario de contacto público. [1] [2] [3] [5]
Deslice la tabla horizontalmente para leerla.
| Área | Registrar antes del cambio | Acreditar después del cambio |
|---|---|---|
| Sitio web y www | Nombres, destinos anteriores y previstos, responsables | Disponibilidad y redirecciones acordadas |
| Correo | MX, SPF, DKIM y DMARC para cada vía de envío | Pruebas autorizadas de recepción y envío; autenticación del remitente |
| Otros servicios | Finalidad y cuenta responsable de cada valor de verificación | Decisión confirmada de conservar, cambiar o eliminar |
| DNSSEC y servicios retirados | Delegación, claves afectadas, plan de retirada y reversión | Resolución coherente; retirada controlada de referencias antiguas |
¿Dejó de llegar el correo tras cambiar los servidores de nombres?
Determine primero si falla la recepción, el envío o un único servicio emisor. Anote la hora y el error exacto. Compare la nueva zona DNS autoritativa con el inventario guardado y los requisitos del proveedor de correo.
No cambie varias protecciones por sospecha. Un fallo de entrega no justifica desactivar DMARC de forma general ni borrar registros sin explicar. Documente por separado la causa, la corrección concreta y el resultado observado. [1] [2] [4] [5]
Deslice la tabla horizontalmente para leerla.
| Observación | Primera comprobación | Verificación posterior |
|---|---|---|
| La web carga, pero no llega correo | ¿Son correctos los MX y sus destinos en la zona activa? | Compruebe una prueba autorizada de recepción y el estado del proveedor. |
| El mensaje llega, pero falla la autenticación | ¿SPF y DKIM corresponden al servicio emisor afectado? | Revise cabeceras originales y alineación DMARC. |
| DNS devuelve SERVFAIL | ¿Coinciden delegación, DS y firmas DNSSEC? | Revise la cadena de confianza; esperar a las cachés no basta. |
| Solo algunas redes ven valores antiguos | Distinga respuestas autoritativas y almacenadas en caché. | Anote TTL, hora de consulta y resolutor. |