Qué hacer cuando los cambios de DNS no surten efecto

Un cambio de DNS que parece no surtir efecto es una de las fuentes de frustración más habituales en el trabajo diario con infraestructura, sobre todo porque el sistema subyacente (una caché distribuida con caducidad por registro) es invisible hasta que te pones a buscarlo.

Repasa esto antes de dar algo por roto

1. Confirma que el cambio se guardó realmente en el lado autoritativo: consulta directamente los servidores de nombres autoritativos del dominio en lugar de un resolvedor público general, para descartar que el guardado fallara en silencio o que aún no se haya sincronizado en la propia infraestructura del proveedor.
2. Comprueba el TTL anterior del registro: si estaba fijado, por ejemplo, en 86400 segundos (24 horas), un resolvedor que almacenó la respuesta antigua minutos antes de tu cambio no volverá a preguntar hasta pasado un día entero.
3. Descarta una caché DNS a nivel de navegador o de sistema operativo: están incluso más cerca de ti que tu resolvedor configurado y pueden conservar una respuesta con independencia de este.
4. Verifica que modificaste el registro que crees haber modificado: un error sorprendentemente habitual es actualizar por accidente una zona DNS de preproducción o ajena a producción.
5. Comprueba desde más de un punto de observación: que un solo resolvedor muestre la respuesta antigua no te dice si el cambio se ha propagado en el resto.

Una causa menos evidente: un servidor de nombres secundario o esclavo con retraso

Las configuraciones DNS más grandes suelen tener un servidor de nombres primario (o «maestro») donde realmente se hacen los cambios, y uno o más servidores secundarios («esclavos») que copian la zona de este periódicamente mediante una transferencia de zona. Si un secundario aún no ha recibido la última transferencia (por un calendario de transferencias mal configurado, un problema de red entre primario y secundario o simplemente porque no ha transcurrido el intervalo de transferencia), los resolvedores que consulten justo ese secundario seguirán recibiendo la respuesta antigua aunque el primario esté totalmente actualizado y la caché basada en TTL de todos los resolvedores haya caducado. Es una causa menos común que la simple caché, pero conviene descartarla expresamente cuando distintos servidores de nombres autoritativos del mismo dominio discrepan entre sí, y no solo cuando discrepan los resolvedores públicos.

Planificar con antelación evita la mayoría de estos problemas

Para un cambio planificado (una migración, un cambio de proveedor, un traspaso), reducir el TTL uno o dos días antes es lo que más rendimiento da con menos esfuerzo. Cuesta un pequeño volumen extra de consultas a cambio de que el cambio se propague en minutos en lugar de, potencialmente, un día entero. Fíjalo, espera a que pase por completo la ventana del TTL antiguo, haz el cambio y vuelve a subir el TTL cuando hayas confirmado que todo está bien.

Borrar tu propia caché local, cuando realmente es la culpable

Si los servidores de nombres autoritativos y todos los resolvedores públicos que compruebas ya coinciden en la respuesta nueva, pero una máquina concreta sigue mostrando la antigua, la caché local de esa máquina es la única sospechosa que queda.

Conviene probar esto solo después de confirmar que el lado autoritativo ya es correcto: vaciar una caché local cuando el registro real todavía no se ha actualizado solo te devuelve una copia nueva de la misma respuesta antigua, y se ve idéntico a que el vaciado haya fallado.