Migras un sitio web, todo parece ir bien por tu parte, y entonces empiezan a llegar los mensajes. Algunos visitantes ven el sitio nuevo, otros siguen accediendo al antiguo y algunos informan de errores que no consigues reproducir en absoluto.
Cuando eso ocurre, es fácil culpar al proveedor de alojamiento o a la propia migración. Sin embargo, la mayoría de las veces, la causa real son los DNS (no porque estén fallando, sino porque están haciendo exactamente lo que se supone que deben hacer).
No todas las actualizaciones de los DNS se producen a la vez. Dependen de varias capas de caché y de resolutores externos a tu entorno de alojamiento, por lo que las migraciones parecen impredecibles incluso cuando el sitio ya está listo.
Esta guía explica qué es lo que controlan realmente los DNS, por qué la propagación se comporta de forma diferente según cada persona y cómo planificar una migración para que los DNS sean un paso final controlado, en lugar de una fuente de interrupciones del servicio o de confusión.
Qué hacen realmente los DNS
Los DNS responden a una pregunta muy concreta: ¿A dónde debe apuntar este dominio?
Cuando alguien escribe tu dominio en un navegador, los DNS traducen ese nombre a una dirección IP. Esa dirección IP le indica al navegador a qué servidor debe conectarse. Los DNS no cargan páginas ni se preocupan por lo que se esté ejecutando en el servidor. Solo se encargan de la búsqueda.
Para que esa búsqueda funcione de forma fiable, los DNS se dividen en varias partes independientes, cada una con una función clara.
- Registrador de dominios: Tu registrador es donde se compra y renueva el dominio. No aloja tu sitio ni controla el tráfico. Desde el punto de vista de los DNS, su principal responsabilidad es dirigir el dominio a los servidores de nombres correctos.
- Proveedor de DNS autoritativo: Es el servicio que almacena tus registros DNS y da la respuesta definitiva cuando Internet pregunta dónde debe resolverse tu dominio. Proveedores como Cloudflare o tu plataforma de alojamiento suelen desempeñar esta función.
- Servidores de nombres: Los servidores de nombres le indican a Internet qué proveedor de DNS es el autoritativo para tu dominio. No contienen datos ni configuración del sitio web en sí. Simplemente redirigen las consultas de DNS al lugar correcto.
- Registros DNS (A, AAAA, CNAME): Estos registros definen adónde va el tráfico. Los registros A dirigen un dominio a una dirección IPv4, los registros AAAA a una dirección IPv6 y los registros CNAME asignan un alias de un dominio a otro.
En conjunto, estos registros determinan a qué servidor llegan los visitantes cuando cargan tu sitio.
Igual de importante es lo que los DNS no hacen. Los DNS no sirven archivos, no trasladan bases de datos, no sincronizan contenidos ni gestionan certificados SSL. Nunca interfieren en tu entorno de alojamiento.
Una vez que queda claro ese límite, el resto del proceso de migración se vuelve mucho más fácil de entender.
Qué cambia durante la migración de un sitio y qué permanece igual
Una de las razones por las que los DNS causa tanta confusión durante las migraciones es que, en realidad, solo cambia una pequeña parte de la configuración. El resto permanece exactamente igual que antes, aunque el sitio en sí se traslade a un entorno completamente nuevo.
Durante una migración típica de un sitio, suelen cambiar algunas cosas.
- La dirección IP casi siempre cambia porque el sitio ahora está alojado en un servidor diferente. Esta es la actualización relacionada con los DNS más habitual y la que, en última instancia, indica a dónde debe dirigirse el tráfico.
- El entorno de alojamiento también cambia. Esto incluye el servidor, la infraestructura y la plataforma en la que se ejecuta tu sitio. Aunque esto afecta al rendimiento y a la estabilidad, es independiente de los DNS y debe estar totalmente listo antes de que se realicen cualquier actualización de los DNS.
- En muchos casos, cambian los registros DNS específicos. Se actualizan los registros A o AAAA para que apunten a la nueva dirección IP. A veces, en cambio, se modifican los registros CNAME, dependiendo de cómo esté configurado el sitio.
Al mismo tiempo, hay varias cosas que suelen seguir igual.
- El nombre de dominio no cambia. Los visitantes siguen escribiendo la misma URL y no hay que actualizar nada en la dirección pública.
- Los servidores de nombres también se mantienen igual, a menos que cambies de proveedor de DNS a propósito. La mayoría de las migraciones no requieren ningún cambio de servidor de nombres, ni siquiera cuando cambia el proveedor de alojamiento.
Por eso casi siempre los DNS son el último paso en una migración. Primero se crea y se comprueba el nuevo entorno, y luego se actualizan los DNS cuando todo está listo para recibir tráfico.
Si tratas los DNS como un paso final en lugar de una tarea inicial, reduces la incertidumbre, minimizas los riesgos y te resulta mucho más fácil evitar los tiempos de inactividad.
La propagación de los DNS y por qué es impredecible
La propagación del DNS no significa que Internet esté «actualizando» tu dominio de golpe. Se refiere al tiempo que tardan los cambios de los DNS en ser detectados, almacenados en la caché y reutilizados en muchos sistemas independientes.
Cuando alguien visita tu sitio, su solicitud no va directamente a tu proveedor de DNS cada vez. Normalmente pasa por un resolutor recursivo, a menudo gestionado por un ISP, una red corporativa o un servicio público como Google o Cloudflare. Ese resolutor pide una respuesta al proveedor de DNS autoritativo y luego almacena el resultado para usarlo más adelante.
Una vez que un resolutor almacena en caché una respuesta de DNS, sigue usando esa respuesta hasta que la caché caduque. Aquí es donde entra en juego la imprevisibilidad. Los distintos resolutores almacenan en caché los datos DNS durante periodos de tiempo diferentes. Algunos respetan los valores de TTL con precisión. Otros aplican sus propios límites o reutilizan los datos almacenados en caché durante más tiempo del esperado.
Además, las cachés del navegador y del sistema operativo pueden almacenar los resultados de los DNS de forma local. Si se ha actualizado el registro DNS global, el dispositivo de un usuario puede seguir utilizando una respuesta anterior hasta que se borre la caché local o caduque.
Este sistema de caché por capas explica por qué dos personas que se encuentran en lugares distintos pueden ver versiones diferentes de la misma página web a la vez. Un servidor de resolución tiene la nueva dirección IP, mientras que otro sigue apuntando al servidor antiguo.
La regla habitual de «24-48 horas» simplifica demasiado lo que realmente ocurre. Muchos usuarios ven las actualizaciones en cuestión de minutos. Otros pueden tardar mucho más en verlas, dependiendo de cómo se comporten su resolutor y las cachés locales.
El TTL y cómo ayuda a evitar el tiempo de inactividad
El TTL, o Time to Live, controla cuánto tiempo se almacenan en la caché las respuestas de los DNS antes de que un resolutor solicite información actualizada. No acelera las actualizaciones, pero limita el tiempo durante el cual se puede reutilizar la información obsoleta.
Cada registro DNS tiene su propio valor de TTL, que se mide en segundos. Si un registro tiene un TTL de 300, los resolutores pueden reutilizar esa respuesta hasta cinco minutos antes de volver a comprobarla. Un TTL de 86.400 permite el almacenamiento en la caché durante un día entero.
Por eso es importante reducir el TTL antes de una migración. Si los resolutores ya tienen respuestas DNS de corta duración, se actualizan con más frecuencia cuando cambias los registros. Eso reduce el margen de tiempo en el que los visitantes podrían ser redirigidos al servidor antiguo tras el cambio.
Para la mayoría de las migraciones, un TTL de entre 300 y 600 segundos ofrece un buen equilibrio. Es lo suficientemente corto como para limitar los retrasos de propagación sin sobrecargar innecesariamente la infraestructura DNS.
Establecer un valor demasiado bajo puede causar problemas. Los TTL extremadamente cortos no garantizan actualizaciones instantáneas, y algunos resolutores ignoran los valores inusualmente bajos. Otros pueden limitar la frecuencia de las solicitudes o recurrir a los datos almacenados en las cachés de todos modos. Reducir el TTL en el último momento es otro error habitual. Si las cachés ya contienen registros de larga duración, cambiar el TTL no les afectará hasta que caduquen.
Lo más seguro es planificarlo bien. Reduce el TTL al menos 24 horas antes de la migración, confirma que el nuevo valor está activo y solo entonces programa el cambio de DNS.
Un calendario seguro para la migración del DNS (paso a paso)
Una migración de DNS fluida da prioridad a la secuencia sobre la velocidad. Cuando cada paso se realiza en el orden correcto, los DNS se convierten en un cambio controlado en lugar de un juego de adivinanzas. Así es como puedes llevarlo a cabo con éxito:
1. Prepara el nuevo entorno de alojamiento
Configura el nuevo sitio por completo antes de tocar los DNS. Eso incluye instalar las dependencias, configurar la caché, establecer redireccionamientos y comprobar el rendimiento.
Prueba el sitio utilizando una URL temporal o un archivo de hosts local para que puedas verlo como si los DNS ya apuntaran al nuevo servidor. Asegúrate de que los certificados SSL estén listos y sean válidos, especialmente si se exige HTTPS. Los DNS nunca deben ser el paso en el que descubras problemas de configuración.
Puedes ajustar la información de los DNS fácilmente en MyKinsta: ve a tu panel de control, haz clic en DNS y luego Añadir tu primer nombre de dominio.
2. Reduce el TTL con antelación
Reduce los valores de TTL en los registros DNS pertinentes con bastante antelación a la migración. Lo ideal es hacerlo al menos 24 horas antes del cambio previsto.
Después de cambiar el TTL, confirma que el nuevo valor está activo usando herramientas de búsqueda de DNS. Esto garantiza que los resolutores empiecen a almacenar en caché respuestas de menor duración antes de que se produzca cualquier cambio de IP.
3. Congela los cambios que puedan suponer un riesgo
Detén las modificaciones de contenido, los pedidos de comercio electrónico y el envío de formularios si el sitio web utiliza una sola base de datos. Los DNS no transfieren datos, por lo que los cambios realizados en el sitio antiguo después de la captura de la migración podrían perderse.
La mayoría de los problemas con los datos de migración provienen de escrituras superpuestas, no de retrasos de los DNS. Congelar los cambios elimina ese riesgo.
4. Actualiza los registros DNS
Modifica solo los registros que necesiten actualizarse, normalmente registros A, AAAA o CNAME que apunten al sitio. Evita modificar registros que no tengan relación durante el mismo proceso. También puedes ajustar esta información desde MyKinsta. En la misma página de DNS que antes, desplázate hacia abajo hasta Registros DNS y selecciona Añadir un registro DNS para añadir esta información manualmente.
Comprueba dos veces las direcciones IP, los tipos de registro y los nombres de host para evitar conflictos. Una vez actualizados, verifica los cambios mediante consultas DNS directas en lugar de limitarte a probarlo en el navegador.
También puedes realizar un escaneo automático de los registros DNS haciendo clic en Iniciar escaneo en la sección Escaneo automático.
5. Monitoriza la propagación en tiempo real
Realiza un seguimiento de la resolución de DNS desde varias regiones para confirmar que el tráfico llega al nuevo servidor. Es normal que los resultados sean dispares durante la implementación.
El éxito no quiere decir que todo el mundo reciba las actualizaciones al instante. Significa que el nuevo tráfico se redirige constantemente al destino correcto, sin errores ni interrupciones.
Seguir esta secuencia garantiza la previsibilidad de los DNS. Cada paso reduce el riesgo, minimiza la incertidumbre y evita el tiempo de inactividad causado por cambios apresurados o que se solapan.
De dónde suele venir el tiempo de inactividad y cómo evitarlo
Cuando se produce un tiempo de inactividad durante una migración, a menudo se culpa a los DNS. En la práctica, la causa principal suele estar en otra parte.
Los problemas de DNS suelen ser sencillos y binarios: un registro apunta al lugar correcto o no. La mayoría de las interrupciones del servicio se deben a desajustes entre los DNS, el alojamiento web y la propia aplicación.
- Un error muy común es una dirección IP incorrecta. Un simple error tipográfico o un valor desactualizado hace que el tráfico se dirija al servidor equivocado, lo que parece un fallo del servicio aunque los DNS funcionen correctamente.
- Los registros DNS que faltan o están incompletos provocan síntomas similares. A veces se pasan por alto los registros de correo, los subdominios www o los registros de verificación durante los cambios, lo que provoca interrupciones parciales o fallos en el funcionamiento.
- La descoordinación de SSL es otra causa frecuente. Puede que los DNS apunten al nuevo servidor, pero el certificado aún no está instalado o no es válido para el dominio correcto. Los navegadores bloquean entonces el acceso, lo que los usuarios perciben como un periodo de inactividad.
- El almacenamiento en caché también puede jugar en tu contra. El contenido almacenado en caché o las redirecciones pueden seguir apuntando al servidor antiguo tras las actualizaciones de los DNS, especialmente si los proxies inversos o las capas de CDN no están alineados con el nuevo entorno.
La forma más segura de evitar estos problemas es la superposición. Mantén los entornos antiguo y nuevo activos al mismo tiempo, y totalmente operativos, hasta que el tráfico se haya desviado claramente. Cuando ambos servidores pueden atender las solicitudes de forma segura, la propagación de los DNS se vuelve mucho menos arriesgada.
Cómo el alojamiento administrado reduce el riesgo relacionado con los DNS
El alojamiento administrado puede reducir el riesgo de la migración al garantizar que el nuevo entorno esté totalmente preparado antes de los cambios de DNS. La mayoría de las plataformas administradas ofrecen entornos de staging o URL temporales, stacks de servidores preconfiguradas y comprobaciones de compatibilidad con SSL, de modo que el nuevo sitio se pueda probar de principio a fin mientras el antiguo sigue atendiendo a los visitantes.
El soporte para la migración también juega un papel importante. Equipos con experiencia validan los registros DNS, confirman las asignaciones de IP y detectan errores de configuración habituales que provocan interrupciones del servicio. En lugar de tener que adivinar si un problema está relacionado con DNS, SSL o la aplicación, los problemas se identifican y resuelven en una fase más temprana del proceso.
Kinsta organiza las migraciones de tal forma que los entornos superpuestos sean la opción predeterminada. El sitio antiguo sigue atendiendo el tráfico mientras se prepara y verifica el nuevo. Cuando se actualizan los DNS, ambos están listos para gestionar las solicitudes.
Mitos sobre los DNS que provocan pánico innecesario
Gran parte del estrés que genera la migración viene de ideas sobre los DNS que parecen lógicas, pero que no son del todo correctas. Aclarar estas dudas te ayuda a mantener la calma cuando las cosas no se actualizan al instante.
«Los cambios en el DNS son instantáneos».
Las actualizaciones de DNS no se propagan a Internet en tiempo real. Se aplican a medida que caducan las cachés y los resolutores actualizan sus datos. Incluso un cambio perfectamente configurado se implementa de forma gradual.
«Si el sitio no funciona, los DNS están fallando».
La mayor parte del tiempo de inactividad durante la migración no se debe en absoluto a los DNS. Los errores de SSL, las configuraciones erróneas del servidor o los problemas de las aplicaciones suelen parecer fallos de los DNS porque los usuarios no pueden cargar el sitio.
«Borrar la caché soluciona la propagación».
Borrar la caché del navegador puede ayudar a un solo usuario a ver el nuevo sitio, pero no cambia lo que los resolutores o los proveedores de Internet tienen almacenado en caché. La propagación se produce según sus plazos, no los tuyos.
«Es necesario cambiar los servidores de nombres en cada migración».
Los cambios de servidores de nombres solo son necesarios al cambiar de proveedor de DNS. La mayoría de las migraciones de sitios funcionan perfectamente sin tocar los servidores de nombres en absoluto.
Si necesitas hacer cambios, puedes acceder a los servidores de nombres de Kinsta en MyKinsta, en DNS > Cambiar servidores de nombres en tu registrador.
Los DNS rara vez se comporta de forma impredecible porque estén dañados. Se comporta de forma predecible según unas reglas que son fáciles de malinterpretar. Conocer esas reglas elimina gran parte del pánico que rodea a las migraciones.
Lista de comprobación tras la migración: qué hacer una vez que los DNS están activos
Una vez que los cambios de DNS están en marcha, el trabajo no ha terminado. El objetivo ahora es confirmar que el tráfico llega de forma constante al nuevo entorno y que nada está fallando silenciosamente en segundo plano.
- Empieza por confirmar que el tráfico llega al nuevo servidor: revisa los registros del servidor, las estadísticas o los paneles de control del alojamiento para verificar que las solicitudes llegan a la IP y al entorno correctos. Es normal que haya tráfico mixto al principio, pero debería ir derivándose por completo hacia el nuevo sitio.
- Verifica el SSL y las redirecciones: Asegúrate de que los certificados sean válidos para todos los dominios previstos y de que las redirecciones de HTTP a HTTPS y las redirecciones heredadas funcionen como se espera. Los errores de certificado o los bucles de redirección suelen aparecer solo después de que llega el tráfico real.
- Monitoriza los registros y las tasas de error: presta atención a los picos de errores 404, 500 o solicitudes bloqueadas. Estas señales suelen revelar problemas de configuración que se pasaron por alto y que no eran visibles durante las pruebas.
- Una vez que el tráfico se haya estabilizado, restaura los valores normales de TTL: unos TTL más largos reducen el volumen de consultas DNS y mejoran la eficiencia del resolutor. Este paso suele olvidarse, pero es importante para la estabilidad a largo plazo.
- Elimina los entornos heredados de forma segura: no apagues el servidor antiguo hasta que estés seguro de que ya no recibe tráfico significativo. Un breve periodo de solapamiento evita que los fallos en casos extremos se conviertan en interrupciones del servicio.
Este paso final convierte una actualización de DNS exitosa en una migración limpia y estable.
El tiempo de inactividad durante la migración suele ser evitable
El tiempo de inactividad durante la migración de un sitio web suele deberse a cambios realizados con prisas, a la superposición de responsabilidades o a considerar los DNS como algo que hay que «arreglar» bajo presión.
Las migraciones más seguras priorizan la preparación sobre la velocidad. Primero se validan el alojamiento, la configuración de la aplicación y el SSL. Los DNS se actualizan en último lugar, con expectativas realistas sobre la propagación y el almacenamiento en caché.
Con el flujo de trabajo y el soporte adecuados, las migraciones de sitios web no tienen por qué ser estresantes ni arriesgadas. Y cuando los cambios de DNS se producen sobre un entorno estable y administrado, como los servicios de alojamiento administrado que ofrece Kinsta, el tiempo de inactividad pasa a ser cosa del pasado.
