Imagine que cambia la dirección del servidor de un dominio: en casa se abre el sitio nuevo, pero el teléfono sigue conectándose al servidor anterior. Aunque ambos dispositivos utilicen el mismo nombre, sus resultados pueden diferir temporalmente si pasan por distintas cachés DNS. La caché HTTP que reutiliza páginas descargadas y la caché DNS que ayuda a encontrar una dirección de conexión requieren comprobaciones distintas.
Este artículo sigue al servidor ficticio de biblioteca www.library.example para explicar la resolución de nombres y la caché. Los nombres y el horario son ejemplos didácticos; no se han medido respuestas de un servicio real. El objetivo es distinguir cómo DNS proporciona direcciones, por qué los cambios pueden tardar en verse y qué fallos ocurren después de resolver el nombre.
1. DNS ofrece distintos tipos de respuesta para cada nombre
DNS proporciona información asociada a nombres de dominio mediante registros de distintos tipos. A representa una dirección IPv4 y AAAA una dirección IPv6; un nombre puede tener varias direcciones. CNAME es un alias hacia otro nombre, MX identifica un servidor que recibe correo y NS un servidor de nombres autoritativo para la zona. Por tanto, consultar el mismo nombre puede dar respuestas diferentes según el tipo de registro solicitado.
Como explica la documentación de registros DNS de Cloudflare, el valor de CNAME es otro nombre, no una dirección IP. Obtener una dirección puede exigir resolver también ese nombre. En https://www.library.example/books, el nombre de host que trata DNS es www.library.example. Ni la ruta /books ni el contenido de la página se registran en DNS. Configurar un CNAME no crea automáticamente una redirección HTTP que cambie la barra de direcciones del navegador.
2. Cómo encuentra un resolvedor recursivo los servidores autoritativos
La función de resolución de nombres del dispositivo suele consultar al resolvedor recursivo configurado. Este utiliza la información disponible en caché; si falta, consulta otros servidores DNS y devuelve la respuesta final o un error. El estándar de terminología DNS RFC 9499 distingue esa resolución por cuenta del cliente del papel del servidor autoritativo, que dispone de la información de su propia zona. El origen de una respuesta debe interpretarse según el papel del servidor.
En un recorrido simplificado sin caché ni intermediarios, el resolvedor recibe de la raíz una referencia a los servidores del dominio de nivel superior y, de estos, otra a los servidores autoritativos de la zona de destino. Del servidor autoritativo final obtiene el registro o alias buscado. Un único servidor raíz no almacena las direcciones IP de todos los sitios. En la práctica se puede partir de una delegación ya guardada o reenviar la consulta a otro resolvedor, por lo que no es obligatorio repetir toda la secuencia en cada visita.
3. El TTL es vida restante en caché, no un reloj mundial
El TTL de un registro comunica su tiempo de vida en caché en segundos. En una respuesta normal desde caché, el tiempo restante disminuye mientras el registro permanece almacenado. Si un resolvedor guarda una dirección a las 10:00 con TTL de 300 segundos, al responder desde esa misma copia a las 10:02 quedarán aproximadamente 180 segundos. La tabla supone un solo resolvedor sin nuevas consultas, actualización anticipada ni entrega de respuestas caducadas.
| Hora ficticia | Dirección en el servidor autoritativo | Acción de este resolvedor |
|---|---|---|
| 10:00 | Dirección anterior | Guarda la dirección anterior con TTL de 300 segundos |
| 10:01 | Cambiada a la nueva dirección | A la copia almacenada le quedan 240 segundos |
| 10:03 | Dirección nueva | Puede reutilizar la anterior durante los 120 segundos restantes |
| Primera consulta después de 10:05 | Dirección nueva | Se supone que consulta de nuevo y obtiene la nueva dirección en lugar de usar la copia caducada |
Otros resolvedores pueden haber guardado ese registro más tarde o no haberlo visto nunca. Como sus actualizaciones ocurren en momentos diferentes, un solo TTL no determina cuándo cambiarán simultáneamente todos los usuarios del mundo. La caché puede desechar datos antes de caducar, y actualizar una página no borra la copia de un resolvedor compartido. El TTL ayuda a entender la reutilización de respuestas DNS; no limita la duración de toda la conexión web ni de la actualización de pantalla.
4. Cuándo reducir el TTL y cómo se guarda una respuesta de ausencia
Una caché que recibió la dirección anterior con TTL de 3 600 segundos no se entera inmediatamente de que el operador lo ha reducido a 60 segundos. Para un cambio previsto, ajuste el TTL con antelación y considere las respuestas aún guardadas con la duración anterior más larga. Un TTL corto puede aumentar la frecuencia de comprobación de cambios, pero también la carga de consultas y la dependencia del servidor autoritativo. Revise el cambio y la respuesta ante fallos en conjunto, en vez de imponer el mismo valor corto a todos los servicios.
NXDOMAIN, que indica que un nombre no existe, y NODATA, que indica que existe pero no tiene registros del tipo solicitado, también pueden almacenarse en caché. El estándar de caché negativa RFC 2308 define esa duración con el menor valor entre el TTL del registro SOA del servidor autoritativo y el campo MINIMUM del SOA. Por eso, justo después de añadir un host puede persistir una respuesta anterior de ausencia. Suponer que dura lo mismo que el TTL del nuevo registro A puede ocultar la causa.
5. Compruebe manteniendo el mismo nombre, tipo y servidor
Anote el nombre exacto consultado, el tipo, como A o AAAA, el servidor DNS interrogado y la hora. Si dispone de dig, puede indicar el nombre y el tipo con dig example.com A. Al investigar un problema real, sustituya example.com por el host que desea comprobar. El comando ilustra un procedimiento; no se ha ejecutado ni se han medido con él tiempos de respuesta para este artículo.
Lea el estado de la respuesta junto con los nombres, tipos, valores y TTL de ANSWER. Al repetir la misma consulta al mismo resolvedor, compruebe si disminuye el TTL, pero no considere inmediatamente un aumento como un error. Puede haberse actualizado anticipadamente o haber respondido otro nodo de caché. Registrar por separado A y AAAA permite distinguir qué familia de direcciones presenta diferencias.
Si administra la zona, compare las respuestas del resolvedor recursivo y del servidor autoritativo para el mismo nombre y tipo. Si difieren, revise sucesivamente el tiempo restante de caché, la coherencia entre servidores autoritativos y la delegación. No generalice la respuesta de un resolvedor público a todos los usuarios. El DNS interno de una empresa o la configuración DNS propia del navegador pueden cambiar la ruta de consulta: anote también el entorno de conexión.
6. Distinga errores DNS, errores de conexión y excepciones
NXDOMAIN responde que el nombre no existe y NODATA que falta el tipo de registro solicitado. En cambio, SERVFAIL indica que el servidor no pudo procesar la consulta, mientras que un tiempo de espera agotado significa que no llegó una respuesta en el plazo previsto. No interprete todos estos casos como «se ha eliminado el dominio». Primero conserve si hubo código de respuesta y a qué servidor se consultó, para decidir la siguiente comprobación.
Una respuesta anterior después de caducar el TTL no siempre incumple las reglas. El método serve-stale de RFC 8767 permite utilizar información caducada para mejorar la disponibilidad cuando excepcionalmente no puede actualizarse desde los servidores autoritativos. Esto no significa que todos los resolvedores lo usen con la misma configuración. Compruebe el comportamiento del resolvedor utilizado en lugar de deducir de un solo TTL un plazo seguro de aplicación del cambio.
Por último, resolver correctamente una dirección no garantiza acceder al sitio. La red hacia esa dirección, el certificado TLS, el servidor web y la aplicación son etapas distintas. Si DNS devuelve la dirección esperada pero la página no se abre, continúe investigando la conexión posterior. Registrar por separado la resolución y la respuesta web ayuda a localizar el fallo antes de borrar cachés de páginas o cambiar DNS sin criterio.