# Un runbook de cambio de dominio, DNS y TLS para un nuevo servidor | SwissOctet Insights https://swissoctet.com/es/insights/dns-tls-cutover-runbook/ SwissOctet / Perspectivas / Web y onion Web y onion Aplicado · 4 min de lectura Un runbook de cambio de dominio, DNS y TLS para un nuevo servidor Prepare el enrutamiento de nombres de host, los certificados y la reversión en conjunto para que una migración cambie el servidor sin romper la identidad del sitio ni las conexiones seguras. Por SwissOctet Editorial Guardar guía Copiar enlace EN ESTA PÁGINA 01 Inventaríe los nombres y las dependencias 02 Prepare el enrutamiento de nombres de host en el nuevo servidor 03 Elija un método de validación de certificados 04 Planifique la ventana de caché antes de cambiar DNS 05 Verifique DNS y TLS por separado 06 Haga que la reversión también sea una decisión sobre datos 07 Observe el sitio después del cambio Su lista de verificación práctica Fuentes y lecturas adicionales Volver a la biblioteca LA RESPUESTA DIRECTA Prepare el servidor y el certificado para el nombre de host previsto, pruebe la aplicación antes de cambiar el DNS público y mantenga disponible el entorno antiguo durante la transición. Verifique los registros autoritativos, las respuestas en caché y TLS de forma independiente. Una actualización de DNS por sí sola no establece que se estén sirviendo la aplicación y el certificado correctos. 01 Inventaríe los nombres y las dependencias Enumere todos los nombres de host que usa el sitio, incluidos el dominio principal, los alias, los endpoints de API y las devoluciones de llamada de la aplicación. Registre quién controla el registro y el DNS autoritativo. Alojar una aplicación no registra automáticamente su dominio ni otorga al operador del servidor el control de sus registros. Mantenga el acceso al entorno existente hasta que se haya validado el nuevo. Identifique también los registros de correo y de verificación de terceros que el traslado debe preservar. Una migración de sitio web no debería reemplazar sin cuidado una zona DNS completa. Elabore un plan de cambios a nivel de registro con las direcciones previstas y un valor de reversión. Guarde las credenciales de forma privada; el runbook necesita responsables y procedimientos, no contraseñas reales ni tokens de API. 02 Prepare el enrutamiento de nombres de host en el nuevo servidor Una máquina que recibe una conexión debe servir la aplicación prevista para su nombre de host. Configure el servidor web o el panel de alojamiento en consecuencia, con la raíz pública de documentos separada de la configuración privada y las credenciales. Pruebe todos los nombres y redirecciones requeridos, no solo una página de bienvenida genérica a la que se llega mediante la dirección del servidor. Use un método de prueba controlado que envíe el nombre de host previsto al nuevo endpoint antes del cambio público. Compruebe el inicio de sesión, las cargas y los enlaces generados por la aplicación cuando corresponda. Desactive las tareas que podrían duplicar acciones de producción durante las pruebas. La prueba debe demostrar el comportamiento de la aplicación sin enviar correo real, procesar pagos ni modificar involuntariamente la base de datos activa antigua. 03 Elija un método de validación de certificados La emisión de certificados requiere prueba de control de los nombres solicitados. Let's Encrypt documenta HTTP-01 y DNS-01 entre sus métodos de validación. La validación HTTP depende de servir correctamente el desafío requerido; la validación DNS usa un registro DNS especificado y puede admitir la emisión de comodines. Seleccione un método que se ajuste al despliegue real y que pueda mantenerse de forma segura. Mantenga las credenciales de validación con el alcance más limitado posible. La automatización de DNS es especialmente sensible porque las credenciales amplias de DNS pueden afectar a más de un sitio web. Planifique la renovación del certificado y cómo llegan los archivos renovados al proceso que los sirve. La primera emisión exitosa es útil, pero un sitio también necesita un proceso de renovación funcional y monitorización del certificado que realmente presenta. 04 Planifique la ventana de caché antes de cambiar DNS Los registros DNS llevan un tiempo de vida que los resolutores usan al almacenar respuestas en caché. Un cambio de registro no reemplaza instantáneamente todos los resultados en caché. Si una transición se beneficia de un TTL más corto, planifique el ajuste con la suficiente antelación para que las respuestas previamente en caché puedan expirar. Mantenga los entornos antiguo y nuevo capaces de gestionar la transición que diseñó. Esta secuencia ilustrativa separa la preparación del cambio público. Su sincronización debe adaptarse al dominio, al comportamiento de los resolutores y a la aplicación. No es un calendario universal de propagación. Una migración con escrituras activas también necesita un cambio de datos específico de la aplicación, porque, de lo contrario, dos servidores web en funcionamiento pueden aceptar cambios en conjuntos de datos diferentes. Etapa Acción Condición antes de continuar Preparación Inventaríe los registros y configure el nuevo endpoint La aplicación funciona para los nombres previstos Certificado Emita e instale el certificado La cadena y el nombre de host correctos validan Transición Actualice solo los registros DNS planificados El cambio de datos y la reversión están definidos Observación Compruebe los resultados autoritativos y de los clientes Los recorridos de usuario tienen éxito a través del nuevo endpoint Finalización Retire el servicio antiguo después de la validación Se revisaron el tráfico residual y las necesidades de recuperación 05 Verifique DNS y TLS por separado Compruebe primero el registro autoritativo y luego compare las respuestas de los clientes o resolutores implicados en la transición. Un valor autoritativo correcto y un valor en caché más antiguo pueden coexistir. Inspeccione el endpoint al que llega el navegador en lugar de asumir que todas las conexiones ya usan la nueva dirección. Mantenga las observaciones con marca de tiempo para que la transición sea comprensible. Para TLS, valide el nombre de host previsto, la validez del certificado y la cadena mediante una conexión de cliente real. Inspeccione todos los alias y rutas de redirección requeridos. La documentación de TLS de Mozilla explica la autenticación del servidor y los problemas de contenido mixto: la página y sus subrecursos deben entregarse de forma segura. Un certificado en un nombre de host no cubre automáticamente otro endpoint de la aplicación. 06 Haga que la reversión también sea una decisión sobre datos Una reversión de DNS puede redirigir el tráfico, pero no revierte las escrituras realizadas en la nueva aplicación. Defina cómo gestionará esos datos antes del cambio. Para una publicación estática, la reversión puede ser sencilla; para un servicio que acepta cargas o pedidos, el estado de la aplicación necesita un responsable claro y un procedimiento de reconciliación. Imagine que migra un pequeño sitio de publicación con comentarios. Puede preparar un intervalo de mantenimiento o una transición controlada de solo lectura mientras se copian los datos finales. Pruebe el procedimiento de reapertura y mantenga listo el despliegue antiguo. Elija el enfoque que se ajuste a la aplicación en lugar de usar un cambio de DNS como sustituto de la planificación de la consistencia. 07 Observe el sitio después del cambio Verifique los recorridos reales de los usuarios, las tasas de error, la presentación del certificado y las tareas en segundo plano después de que el nuevo endpoint reciba tráfico. Confirme que las copias de seguridad ahora cubren la aplicación y los datos previstos. Revise el acceso al servidor antiguo antes de retirarlo y elimine las credenciales obsoletas cuando se hayan resuelto las necesidades de recuperación y reversión. Registre la configuración final de DNS y del certificado. Al seleccionar alojamiento web o computación SwissOctet, confirme las responsabilidades reales de dominio, certificado y administración para la configuración. El catálogo proporciona un destino de alojamiento y recursos; no establece que su dominio ya se haya conectado ni que se haya configurado la renovación del certificado. Mantenga esos pasos concretos y verificables en el plan de despliegue. CONVIÉRTALO EN ACCIÓN Su lista de verificación práctica. ✓ Inventaríe todos los nombres de host y preserve los registros DNS no relacionados. ✓ Pruebe el enrutamiento de nombres de host antes del cambio público. ✓ Elija y automatice un desafío de certificado adecuado. ✓ Planifique los cambios de TTL y la transición de datos. ✓ Verifique DNS y TLS mediante comprobaciones separadas. ✓ Conserve el acceso de reversión y resuelva las nuevas escrituras antes de revertir. Descargar lista de verificación PREGUNTAS FRECUENTES Los detalles que importan. ¿Cambiar un registro A activa HTTPS? + No. DNS elige un endpoint; ese endpoint aún necesita el enrutamiento de nombre de host correcto y un certificado válido e instalado. ¿Puedo revertir solo el registro DNS si algo se rompe? + El tráfico puede redirigirse, pero las escrituras de la aplicación necesitan un tratamiento aparte. Defina un plan de reversión o reconciliación de datos antes de la migración. ¿Es siempre necesario un certificado comodín? + No. Elija los nombres de certificado y la validación según los nombres de host reales. Un comodín tiene requisitos específicos de cobertura y validación; no es un atajo universal de migración. REFERENCIAS PRINCIPALES Vaya a la fuente. Estas referencias respaldan los conceptos técnicos de esta guía. Consulte la documentación actual antes de cambiar un sistema de producción. Let's Encrypt: Tipos de desafío letsencrypt.org IETF RFC 1034: Conceptos y facilidades de DNS datatracker.ietf.org Mozilla MDN: Seguridad de la capa de transporte developer.mozilla.org Orientación editorial de SwissOctet. Los ejemplos son ilustrativos. Las especificaciones del servicio, las opciones disponibles y las condiciones contractuales deben verificarse por separado. CONECTE EL CONOCIMIENTO Infraestructura relacionada. Canvas Web Suiza Vector VPS Suiza Pulse NVMe Suiza MANTENGA EL HILO Sus próximas notas de campo. Explore todas las guías NOTA DE CAMPO / 01 + Nube y VPS Fundamentos Cómo elegir un VPS sin adivinar Convierta una idea de aplicación en un presupuesto de recursos útil y luego compare CPU, memoria, almacenamiento y transferencia en conjunto. 4 min de lectura Lea la guía NOTA DE CAMPO / 02 + Web y onion Fundamentos Alojamiento web o una VPS: elija el trabajo que quiere asumir Compare los requisitos de la aplicación, el control y las responsabilidades de mantenimiento en lugar de tratar una VPS como el siguiente paso automático para cualquier sitio web. 6 min de lectura Lea la guía NOTA DE CAMPO / 03 + Web y onion Aplicado Publique un servicio onion sin pasar por alto la aplicación Planifique una publicación onion legítima con exposición controlada del backend, revisión cuidadosa del contenido, recuperación de claves del servicio y un modelo explícito de acceso de la audiencia. 4 min de lectura Lea la guía