DNS TTL: cuánto tarda de verdad un cambio de IP y cómo prepararlo
Publicado el 2026-10-26 por frfrand
Cambiar registros DNS sin romper una web ni perder tráfico
Cambiaste el registro A a la IP del VPS nuevo, pero algunos usuarios siguen llegando al anterior. No siempre es que «Internet tarda en enterarse»: el TTL define cuánto tiempo pueden conservar los resolvers una respuesta, y hay otras cachés por el camino.
Vamos a convertirlo en un procedimiento que puedas usar en un VPS real. El objetivo es entender por qué funciona, cómo probarlo y qué problema aparece si una parte queda mal configurada.
Qué significa DNS TTL y cuándo lo necesitás
TTL se expresa en segundos y acompaña la respuesta DNS. Los resolvers pueden conservar un valor hasta su vencimiento, pero el comportamiento varía con cachés y políticas. Reducir TTL justo antes de cambiar la IP no elimina un TTL anterior que ya fue cacheado.
Antes de cambiar nada en producción, anotá el estado actual: IP, dominio, puerto, servicio afectado y hora del último deploy. Una modificación aislada es fácil de comprobar; cinco cambios simultáneos hacen más difícil reconstruir lo ocurrido.
Configuración o comandos de ejemplo
dig ejemplo.com A +noall +answer
dig @1.1.1.1 ejemplo.com A +noall +answer
dig @8.8.8.8 ejemplo.com A +noall +answer
# Ver los servidores autoritativos
dig ejemplo.com NS +shortLos dominios, IP, rutas y nombres son ilustrativos. No copies una configuración entera encima de la actual sin comparar primero. En los ejemplos que incluyen puertos o firewall, asegurate de conservar el acceso administrativo.
Cómo lo haría paso a paso
- Preparación. Un día antes de una migración, baja el TTL del registro relevante y espera a que venza el TTL viejo.
- Paso 2. Prepara el VPS nuevo con HTTPS, API y datos restaurados antes de tocar DNS.
- Paso 3. Haz una sincronización final de datos o controla las escrituras durante el corte.
- Paso 4. Cambia el registro A/AAAA y verifica autoritativos y resolvers externos.
- Verificación. Mantén el entorno anterior disponible durante una ventana razonable y luego retíralo con cuidado.
Cuando termines, comprueba la operación real desde otra conexión. Por ejemplo, para una API no alcanza con abrir el navegador: ejecuta una petición de lectura, una escritura en una base de prueba y consulta los logs del proceso.
Ejemplo de un proyecto de verdad
Una tienda guarda pedidos en PostgreSQL. Si las dos IP apuntan temporalmente a bases distintas, algunos clientes podrían generar pedidos en el servidor viejo. El problema crítico no es solo DNS: es evitar divergencia de datos.
La lección es sencilla: una configuración de infraestructura no vive aislada de la aplicación. El frontend, el servidor, la base de datos y los workers se conectan, así que medir dónde empieza el fallo es más útil que reiniciar todo.
El error que evitaría
No prometas una propagación universal de «cinco minutos». TTL bajo ayuda, pero el comportamiento depende de resolvers y caches. Tampoco cambies solo el A si existe un AAAA antiguo apuntando a otro servidor.
Cuando trabajás con servidores de clientes, guardá un respaldo o procedimiento de reversión antes de cambios que afecten datos, red o certificados. Y si no sabés qué permisos necesita una operación, evitá ejecutarla como root sólo para que deje de mostrar errores.
¿Cómo se relaciona con ArduMaker?
Cuando migrás una web hacia ArduMaker, prepará VPS y servicios antes del DNS y probá por un dominio temporal o técnica controlada de resolución. No uses producción para descubrir variables faltantes.
En un caso típico podés crear un VPS para la aplicación, desplegar desde Git, asociar dominio HTTPS y administrar el backend y las bases necesarias. Las herramientas ayudan a centralizar operaciones, pero hay que entender qué puerto y proceso cumple cada función.
Preguntas que aparecen cuando lo probás
¿Cómo sé si el fallo es de DNS o del servicio? Consultá primero la resolución, después la conexión al puerto y finalmente la respuesta de aplicación. Ese orden evita confundir problemas diferentes.
¿Puedo exponer una base para que sea más fácil mantenerla? Mejor diseñá acceso privado o túneles autenticados cuando sea posible. Exponer un puerto no reemplaza los permisos del motor ni el firewall.
¿Qué debería documentar? La configuración esperada, cómo se comprueba y cómo volver al estado anterior. Ese documento te ayuda más que una lista de comandos sin contexto.
Referencias
En resumen: una buena configuración de red o servidor es la que puedes explicar, verificar y recuperar cuando algo falla.