Cambiaste el registro A de un dominio a un servidor nuevo, pero horas después algunos usuarios siguen llegando al viejo. ¿Por qué y qué hacés? — pregunta de entrevista

Por qué pasa

El DNS no tiene un mecanismo de "propagación" activa: lo que hay es caché. Cada respuesta lleva un TTL. Los resolvers recursivos (el del ISP, 8.8.8.8, el DNS corporativo), el sistema operativo y el navegador guardan la respuesta vieja hasta que ese TTL vence. Si el registro tenía TTL de 86400, puede tardar hasta un día. A eso se suman otras causas:

Entradas en /etc/hosts o en el archivo hosts de Windows.
Aplicaciones que cachean el DNS por su cuenta, como la JVM o algunos clientes HTTP con pools de conexiones persistentes.
Un CDN o proxy que todavía apunta al origen viejo.
Registros que no se tocaron: AAAA (IPv6), un CNAME o un subdominio distinto.

Cómo lo verifico

Código: bash

dig +short ejemplo.com @ns1.proveedor.com   # autoritativo
dig ejemplo.com @8.8.8.8                     # resolver público, mirar TTL restante
dig AAAA ejemplo.com

Si el autoritativo ya responde la IP nueva, el cambio está bien hecho y es caché. Si no, el error está en la zona o en los NS delegados.

Qué hago ahora

Mantengo el servidor viejo funcionando, o como proxy hacia el nuevo, hasta que venza el TTL anterior.
A los usuarios afectados les indico vaciar la caché local (
Código: text
```
ipconfig /flushdns
```
,
Código: text
```
resolvectl flush-caches
```
) y revisar su archivo hosts.

Cómo lo planifico la próxima vez

Bajo el TTL a 300 segundos uno o dos días antes del cambio, espero que expire el TTL viejo y recién ahí migro. Cuando todo está estable, lo vuelvo a subir.

Errores comunes

Decir que hay que "esperar la propagación" sin explicar TTL y caché. Apagar el servidor viejo inmediatamente después del cambio. Olvidar el registro AAAA o el archivo hosts, o no consultar directamente al servidor autoritativo.

Redactado con el asistente Underc0de IA. Actualizado el 15/11/2026. ¿Ves un error? Contanos en el foro.