Qué es una caché DNS y cuánto duran los registros

¿Dónde se guarda realmente en caché una respuesta DNS?

Una sola consulta pasa por varias cachés antes de que notes nada, y cada una guarda su propia copia durante su propio tiempo:

• El navegador. Chrome, Edge y Firefox mantienen cada uno su propia caché DNS pequeña, separada de la del sistema operativo. La de Chrome es visible en chrome://net-internals/#dns, y vaciarla solo afecta a ese navegador, no al resto del equipo.
• El resolutor stub del sistema operativo. Windows ejecuta el servicio Cliente DNS y guarda en caché respuestas que puedes listar con ipconfig /displaydns; macOS lo hace a través de mDNSResponder; la mayoría de los escritorios Linux ejecutan systemd-resolved, un resolutor stub local con caché que consultas con resolvectl. Esta es una caché real con su propia cuenta atrás de TTL, no solo una copia de lo que tiene el navegador.
• El router. La mayoría de los routers domésticos ejecutan un pequeño reenviador de DNS que responde desde su propia caché antes de pasar la consulta hacia arriba, lo cual explica por qué reiniciar el router a veces arregla un problema de DNS que en realidad estaba en otro sitio.
• El resolutor recursivo. El resolutor de tu proveedor de internet, o uno público, gestiona la mayoría de las consultas de internet y mantiene la caché más grande y más compartida. En cuanto tiene una respuesta, cada dispositivo que le pregunta recibe la copia en caché hasta que caduca.

Cada capa es independiente. Vaciar la caché de tu portátil no hace nada a la caché que sigue guardando tu router o tu proveedor de internet, y no cambia nada para el equipo de nadie más.

¿Qué es un TTL, y quién lo respeta de verdad?

Todo registro DNS lleva un time to live: un número en segundos, fijado por quien administra la zona, que le dice a un resolutor durante cuánto tiempo puede reutilizar la respuesta antes de volver a preguntar. La RFC 1035 lo define como el intervalo durante el que un registro "puede guardarse en caché antes de que deba consultarse de nuevo la fuente de la información", y un TTL de cero significa que la respuesta nunca debe guardarse en caché.

Se supone que todas las cachés de la cadena, navegador, resolutor stub, router, resolutor recursivo, respetan ese número, contando desde el momento en que obtuvieron el registro por primera vez. En la práctica, algunos resolutores de proveedores de internet aplican su propio suelo por encima de eso, normalmente una hora o más, sin importar lo que diga la zona que debería ser el TTL. Por eso bajar un TTL para acelerar un cambio futuro ayuda a la mayoría de los resolutores, pero no es una garantía para todos ellos.

¿Qué es la caché negativa, y por qué un registro recién creado puede seguir sin aparecer?

Un resolutor no solo guarda en caché los registros que existen. Si una consulta devuelve que ese nombre no existe (NXDOMAIN) o que no hay ningún registro del tipo pedido, ese fallo también se guarda en caché, un comportamiento llamado caché negativa. La RFC 2308 fija la vida de la caché negativa a partir del campo mínimo del registro SOA, y la RFC 9520 hace ahora obligatorio, en lugar de opcional, que un resolutor conforme guarde en caché ese fallo.

Este es el mecanismo detrás de un problema conocido: creas un subdominio nuevo, lo consultas un segundo demasiado pronto, recibes NXDOMAIN, y el resolutor recuerda "no existe" durante el TTL negativo de la zona, aunque el registro ya exista. Windows muestra los dos tipos de entrada por separado: ipconfig /displaydns lista tanto las respuestas positivas como las negativas, y ipconfig /flushdns descarta explícitamente las entradas de caché negativas como parte del vaciado de la caché.

¿Por qué un sitio se resuelve para ti y no para otra persona?

Porque no existe una única caché compartida. Dos personas que preguntan a dos resolutores distintos, o que preguntan al mismo resolutor en dos momentos distintos, pueden obtener dos respuestas distintas para el mismo nombre. La copia de un resolutor puede seguir fresca de una consulta de hace una hora; otro puede no haber visto nunca ese nombre e ir a buscar el valor actual. Ninguno de los dos está equivocado, simplemente van a relojes distintos. Si esto ocurre justo después de que cambiaste un registro, cómo comprobar la propagación DNS explica cómo comparar varios resolutores uno al lado del otro y leer cuánto tiempo le queda a cada uno.

¿Cómo se lee el TTL de un registro que todavía está en caché?

Consulta el nombre directamente y conserva la salida completa en lugar de la forma corta:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

El número antes del tipo de registro, 847 en este ejemplo, son los segundos que faltan para que caduque la copia de ese resolutor en concreto; no es el TTL original del registro, que solo el servidor autoritativo puede decirte con certeza. Ejecuta la misma consulta otra vez unos segundos después y el número habrá bajado aproximadamente esa cantidad de segundos, lo que confirma que estás leyendo una cuenta atrás en vivo y no un ajuste estático. Si un nombre directamente no se resuelve, en lugar de resolverse con un número bajo, eso es un fallo distinto: cómo vaciar la caché DNS cubre cómo vaciar primero tu propia caché, y qué hace realmente un resolutor DNS cubre lo que ocurre a continuación en la cadena cuando tu propia caché no es el problema.

Una caché explica por qué un visitante ve un cambio de inmediato y otro no; no explica un registro que nunca se actualiza en ningún sitio. Ejecuta una consulta en vivo con la herramienta de consulta DNS para ver la respuesta actual desde fuera de tu propia red, y si el sitio necesita seguir accesible según un calendario en lugar de comprobarse una sola vez, para eso está la monitorización distribuida desde muchos puntos de verificación. HostTracker monitoriza sitios web desde 2004, hoy vigila más de 500.000 sitios desde más de 300 puntos de verificación en 158 ciudades, y avisa por correo electrónico, SMS, llamada de voz, Slack, Telegram y más cuando falla una verificación, incluida una que espera una dirección IP concreta y avisa en el momento en que la respuesta cambia.

Preguntas frecuentes

¿Una caché DNS llena ralentiza mi ordenador?

No. Una caché DNS es una tabla pequeña de nombres y direcciones, normalmente unos cientos de entradas como mucho, y buscar en ella no cuesta nada medible. Si las consultas parecen lentas, la caché en sí no es la causa; lo habitual es un resolutor lejano o sobrecargado.

¿Vaciar mi caché arregla las cosas para otras personas?

No. ipconfig /flushdns, dscacheutil -flushcache y resolvectl flush-caches solo vacían la caché del equipo en el que los ejecutas. Todos los demás siguen leyendo de su propio navegador, su propio router y su propio resolutor, cada uno con su propio reloj.

¿Una caché DNS es lo mismo que una caché de CDN?

No, aunque las dos se confunden. Una caché DNS guarda la respuesta a "cuál es la dirección IP de este nombre". Una caché de CDN guarda el contenido real de la página o del archivo en un servidor cercano al visitante. Vaciar una no tiene ningún efecto sobre la otra.

¿Puedo fijar mi propio TTL si no administro el dominio?

No. El TTL es una propiedad del registro, fijada en la zona autoritativa por quien administra el DNS del dominio. Como visitante, la única palanca que tienes es elegir consultar a un resolutor que respete un TTL corto en lugar de uno que imponga su propio suelo.

¿Por qué el TTL que veo cambia cada vez que consulto?

Porque estás preguntando a un resolutor distinto, o al mismo en un momento distinto de su cuenta atrás. Consulta el servidor de nombres autoritativo directamente con dig example.com @ns1.yourdns.example para ver el TTL tal como se fijó originalmente, sin nada ya descontado.