Guía para decidir mejor
Cómo cambiar DNS sin dejar la web fuera de servicio
El cambio seguro empieza antes de editar DNS: prepara destino y SSL, conserva el origen y comprueba lo que resolverá cada nombre.
Cambiar DNS sin dejar la web fuera de servicio exige tener el destino listo antes de publicar registros nuevos. DNS no copia archivos ni base de datos y tampoco instala SSL: solo indica adónde se conectará cada usuario. Durante un tiempo, distintos resolutores pueden mostrar respuestas diferentes. Por eso conviene mantener operativos origen y destino mientras se verifica la transición, sin prometer una ausencia absoluta de interrupciones.
Si el corte ya ocurrió y la página no abre, sigue el diagnóstico de web caída tras cambiar DNS para separar resolución, servidor y certificado antes de revertir.
Si aún no sabes qué valor modificar, identifica primero A, CNAME, MX y TXT y después sigue el procedimiento para apuntar el dominio al hosting. El MX del correo no debe desaparecer al mover solo la web.
Identifica qué vas a cambiar
No es lo mismo modificar el registro A o AAAA en la zona actual que cambiar los nameservers en el registrador. En el segundo caso, la nueva zona debe contener también MX, TXT, CNAME y otros registros que usan correo, verificaciones o subdominios. Revisa si hay DNSSEC activo y coordina su configuración con el proveedor DNS antes de cambiar la delegación. Nuestra guía sobre dominio y hosting separa estos servicios.
Secuencia de cambio con menos riesgo
- Documenta el estado actual. Exporta o captura la zona DNS y registra quién la administra. Anota A, AAAA, CNAME, MX, SPF, DKIM, DMARC y subdominios usados por aplicaciones.
- Prepara el destino. Copia archivos y base de datos, configura el dominio en el servidor, comprueba PHP y el certificado TLS. Prueba páginas, formularios y acceso administrativo por un método temporal acordado con el proveedor, sin depender todavía del DNS público.
- Planifica el TTL. Si controlas la zona, reduce con antelación el TTL de los registros que cambiarán y espera a que expire el valor anterior. Reducirlo justo en el momento del cambio no borra cachés que ya recibieron una respuesta antigua.
- Publica el cambio preciso. Actualiza los registros web o cambia la delegación solo cuando la nueva zona esté completa. No cambies el MX si el correo no se traslada; si se traslada, sigue el plan específico de correo.
- Comprueba desde varios puntos. Consulta servidores autoritativos y resolutores distintos, verifica HTTP y HTTPS, www y dominio raíz, formularios y correo. Mantén el origen durante el periodo de observación acordado.
Ejemplo: si solo cambia la IP de www.empresa.es y el correo continúa con un proveedor externo, replica y comprueba primero la web nueva; luego cambia el registro web que corresponda. No es necesario mover el dominio al mismo registrador que vende el hosting.
Lo que DNS no puede garantizar
Una caché local o de un resolutor puede seguir entregando la dirección anterior. Cloudflare describe por qué la propagación parece desigual. Para una web dinámica, dos servidores que aceptan escrituras durante la transición pueden divergir: publicaciones, formularios o pedidos entrarían en lugares distintos. Coordina una ventana de congelación, sincronización o arquitectura específica; una tienda necesita además el checklist WooCommerce.
Si el nuevo servidor responde directamente pero el dominio aún muestra la versión anterior, no edites registros repetidamente: sigue el diagnóstico de web antigua tras migración. Al terminar, usa la revisión posterior de WordPress y conserva un plan de vuelta atrás.
Preparación DNS antes del día del corte
Exporta la zona activa y confirma qué nameservers la publican. Marca qué registros cambian y cuáles deben mantenerse: A/AAAA o CNAME de web, MX y TXT de correo, subdominios, verificaciones y posibles entradas DNSSEC. Comprueba que la web de destino responde con el dominio real, HTTPS, rutas internas y formularios antes de editar DNS. Si el proveedor lo permite, reduce con antelación el TTL del registro que se modificará; bajarlo justo en el corte no borra las cachés anteriores.
Define quién ejecuta el cambio, qué métricas vigilará y qué condición activa la vuelta atrás. En una web con escrituras, evita que origen y destino acepten datos divergentes; pausa o sincroniza de forma probada. Después del corte compara resolutores, logs y transacciones, no solo la portada. Esta preparación amplía la guía existente sin abrir otra URL equivalente.