Cada verificación de monitoreo comienza de la misma manera. Antes de que regrese un solo byte de tu página de inicio, respuesta de API o banner SMTP, el agente de monitoreo debe convertir un nombre de host en una dirección IP. Ese primer paso es la resolución DNS, y cómo lo configures cambia lo que tus números de tiempo de actividad realmente significan.
La mayoría de los equipos nunca tocan la configuración DNS en un monitor. Apuntan una verificación a api.example.com, eligen un intervalo y continúan. Pero el comportamiento del resolvedor bajo esa verificación decide si estás midiendo la experiencia de un usuario real, detectando fallas DNS en segundos, o produciendo tiempos de respuesta limpios que puedes comparar entre ejecuciones. No puedes optimizar los tres a la vez.
Dotcom-Monitor te ofrece cuatro modos de resolución DNS por esta razón. Esta guía recorre cada uno, con el enfoque más claro en la elección que la mayoría de la gente se equivoca: caché versus no caché versus caché temporal (basado en TTL).
Por qué la resolución DNS se ejecuta primero en cada verificación
DNS es el primer salto de casi todos los protocolos que monitoreas. Una verificación de sitio web, una llamada de monitoreo de API, una sonda de monitoreo de servidor de correo electrónico, una prueba de monitoreo ICMP ping, cada una necesita una dirección IP antes de poder abrir una conexión. Así que el agente resuelve el nombre de host primero, luego ejecuta TCP, TLS y la solicitud de capa de aplicación sobre eso.
Ese orden importa por dos razones. Primero, el tiempo de búsqueda DNS es parte de tu tiempo total de respuesta, por lo que un resolvedor lento infla cada número río abajo. Y segundo, una falla DNS detiene la verificación antes de comenzar. Si la resolución falla, no hay conexión para probar, no hay certificado que validar, ni código de estado que leer. El monitor informa una falla grave, y la causa raíz está una capa por debajo de lo que pensabas que estabas observando.
Debido a que DNS está delante de todo, la forma en que un agente maneja esa búsqueda es una decisión de diseño real, no un detalle. Resolverlo fresco en cada solicitud te permite detectar problemas del resolvedor rápidamente, pero añades carga y tiempo de búsqueda a cada ejecución. Cachearlo hace que tus números sean más rápidos y estables, pero un registro DNS roto puede ocultarse detrás de la caché por horas. Los modos de Dotcom-Monitor existen para que elijas qué compensación se ajusta a lo que realmente estás monitoreando. Para una mirada más profunda sobre cómo optimizar ese primer salto, consulta nuestra guía para mejorar el tiempo de resolución DNS.
Los cuatro modos DNS en Dotcom-Monitor
Dotcom-Monitor expone cuatro modos de resolución DNS en una tarea de monitoreo. Cada uno cambia de dónde viene la dirección IP y cuánto tiempo permanece.
Caché de dispositivo
Caché de dispositivo es el modo predeterminado. Dentro de una única verificación de dispositivo, el agente resuelve cada nombre de host una vez y comparte esa respuesta entre todas las tareas en ese dispositivo durante el resto de la ejecución. Si una tarea anterior en la misma verificación ya resolvió el host, la tarea posterior reutiliza la IP almacenada en caché. Si no, el agente realiza una búsqueda completa y guarda el resultado en caché durante el chequeo.
La ventaja es eficiencia. La mayoría de las verificaciones terminan en menos de un minuto, así que no hay razón para resolver el mismo host cada pocos segundos. La trampa aparece en el tiempo por tarea. Si un dispositivo monitorea dos URLs en el mismo host, la primera URL carga el tiempo de búsqueda DNS y la segunda usa la IP en caché, de modo que la segunda parece más rápida aún cuando no lo es. Eso es un comportamiento esperado, no un error, pero sorprende a quienes leen un diagrama de cascada por primera vez.
Sin caché
Sin caché omite completamente la caché del dispositivo. Cada ejecución de tarea realiza una búsqueda completa de DNS, por lo que ninguna ejecución toma prestada la respuesta de una ejecución anterior. Eso te da un tiempo uniforme y comparable porque cada verificación paga el costo completo de resolución.
La compensación es carga y latencia. Una búsqueda fresca en cada ejecución añade tiempo a cada tarea y genera más tráfico en la infraestructura DNS. Sin caché tampoco está disponible para las plataformas basadas en navegador BrowserView o UserView. Una página real puede cargar docenas de elementos del mismo host, y resolver ese nombre de host cientos de veces en pocos segundos no es cómo funciona un navegador, por lo que resolver una vez por ejecución es el modelo realista allí.
Caché TTL
Caché TTL se comporta como un resolvedor real en la máquina de un usuario. Respeta el tiempo de vida del registro: el agente almacena la dirección resuelta y la sigue usando hasta que expira el TTL, luego vuelve a resolver a través del servidor DNS local. Este modo es el que más se parece a lo que experimenta un visitante real, porque su navegador y sistema operativo almacenan en caché del mismo modo.
El riesgo está en ese mismo comportamiento. Si el servidor DNS que respalda el registro falla mientras una respuesta válida aún está en caché, el monitor puede no notarlo hasta que expire el TTL, y el TTL puede establecerse en horas, días o más. Así que Caché TTL es la llamada correcta cuando quieres un tiempo realista de experiencia de usuario, y la llamada equivocada cuando detectar una falla DNS rápidamente es el objetivo de la verificación.
Servidor DNS externo
Servidor DNS externo apunta la búsqueda a una IP de resolvedor específico que tú elijas. Si sabes que la mayoría de tus usuarios están detrás de un resolvedor público como Google (8.8.8.8, 8.8.4.4) o Cloudflare (1.1.1.1), puedes probar la resolución a través de ese servicio exacto. También puedes apuntar a un resolvedor que sabes es autoritativo para la zona para evitar la búsqueda recursiva y obtener consultas más rápidas y directas.
El límite es la cobertura. Mientras tu resolvedor elegido devuelva una respuesta válida, el monitor verá éxito, incluso si el servidor DNS responsable del dominio está fallando. Por eso este modo prueba la vista del mundo de un solo resolvedor, no toda la cadena. Otro detalle que vale la pena saber: cada IP de resolvedor distinta tiene su propia caché, así que dos tareas apuntando a diferentes servidores externos mantienen cachés separadas.
Caché vs No caché vs Caché temporal
Esta es la decisión que confunde a la gente, por lo que vale la pena ver los tres modos lado a lado. Caché (Caché de dispositivo) optimiza para eficiencia. No caché (Sin caché) optimiza para tiempos comparables y detecta fallas rápidamente. Caché temporal (Caché TTL) optimiza para realismo al caducar registros como hace un navegador.
| Modo | Cómo resuelve | Mejor para | Principal compensación |
|---|---|---|---|
| Caché de dispositivo (caché) | Una vez por verificación de dispositivo, compartido entre sus tareas | Verificaciones eficientes; múltiples tareas en el mismo host | La primera tarea carga el tiempo de búsqueda; las siguientes parecen más rápidas |
| Sin caché (no caché) | Búsqueda completa fresca en cada ejecución | Tiempo uniforme; detección rápida de problemas DNS | Mayor carga DNS y latencia añadida; no disponible para BrowserView/UserView |
| Caché TTL (caché temporal) | Respeta el TTL del registro, luego vuelve a resolver | Coincidir con la experiencia del usuario real | Un servidor DNS fallido puede ocultarse hasta que expire el TTL |
| Servidor DNS externo | Consulta una IP de resolvedor que especificas | Probar un resolvedor público o autoritativo específico | Ve solo la respuesta de ese resolvedor, no toda la cadena |
La versión corta: usa caché para velocidad, omite la caché para detectar fallas rápido, respeta el TTL para ver lo que ven los usuarios. Elige el que se ajuste a por qué existe la verificación.
Por qué la mayoría de las herramientas de monitoreo pasan por alto problemas DNS
Aquí está lo que hace que esto valga la pena: la mayoría de las herramientas de monitoreo no te dan la opción. Resuelven un nombre de host una vez, lo almacenan en caché y reutilizan esa respuesta mientras dure el registro. Esto funciona hasta que aparece un problema DNS en producción — un registro erróneo, un servidor autoritativo fallido, un resolvedor que devuelve la IP incorrecta — porque un monitor con caché sigue reportando éxito contra una respuesta obsoleta mientras los usuarios reales experimentan la falla.
El control granular sobre el modo de resolución es poco común en el espacio de monitoreo. Forzar una búsqueda fresca en cada verificación, caducar registros con su TTL o apuntar a un resolvedor específico es casi una firma de Dotcom-Monitor, y es la línea entre un monitor que asume que DNS está bien y uno que realmente lo prueba. Si detectar problemas DNS en producción es por qué existe la verificación, el comportamiento predeterminado de almacenar todo en caché que la mayoría de las herramientas ofrecen es justo lo que los oculta.
Cómo elegir el modo DNS correcto
El modo que quieres depende de la pregunta que responde el monitor. Aquí están los patrones que más se ven en los equipos DevOps y SRE.
Quieres detectar fallas DNS tan rápido como sea posible. Usa Sin caché. Cuando la verificación existe para alertarte en el momento en que la resolución falla — un cambio erróneo de registrador, una zona expirada, un registro secuestrado — no quieres una respuesta obsoleta en caché. Resolver fresco en cada ejecución significa que la falla aparece en la siguiente verificación, no después de un TTL de varias horas. Combina esto con una alerta precisa para que la señal llegue a alguien en turno.
Quieres tiempos que coincidan con un visitante real. Usa Caché TTL. Si la verificación respalda un SLA de monitoreo de tiempo de actividad o alimenta un tablero de experiencia de usuario real, resolver como lo hace un navegador mantiene tus números honestos. Solo acepta que la detección de fallas DNS se demora hasta un TTL, y añade una verificación separada Sin caché si esa diferencia importa.
Ejecutas varias tareas contra el mismo host. El predeterminado Caché de dispositivo suele ser el correcto. Mantiene la carga DNS razonable y resuelve el host una vez por ejecución. Lee el diagrama de cascada por tarea teniendo en cuenta la caché: la primera tarea carga el tiempo de búsqueda.
Te importa un resolvedor específico. Usa Servidor DNS externo. Esto funciona para equipos que validan que los resolvedores públicos de Google o Cloudflare devuelven el registro correcto, o que verifican un servidor autoritativo específico directamente. Es una prueba dirigida, así que mantén una verificación más amplia ejecutándose junto a ella. Para una estrategia más amplia, nuestro resumen de herramientas de monitoreo DNS cubre cómo se integran estas verificaciones.
Qué errores DNS detecta cada modo
DNS es un punto común de falla, y falla de más de una manera. Los registros cambian durante una migración. Una zona expira. Un servidor autoritativo se cae. Y en el peor caso, un atacante envenena una caché para apuntar tu dominio a un servidor que controla. Tu modo de resolución decide qué tan rápido aparecen estos problemas.
Sin caché es el más rápido para mostrar problemas de resolución porque nunca confía en una respuesta anterior. Caché TTL es el más lento, ya que un registro en caché válido puede sobrevivir a la falla detrás de él. Servidor DNS externo detecta problemas con el resolvedor específico que apuntas pero puede pasar por alto problemas en otra parte de la cadena. Si quieres el panorama completo de cómo se desglosa una verificación a través de capas, nuestra guía de errores DNS, TCP, TLS y HTTP mapea cada etapa. Y si las interrupciones son la preocupación, el manual sobre cómo evitar interrupciones DNS complementa bien una verificación Sin caché.
Sea cual sea el modo que uses, el objetivo del monitoreo DNS es ser el primero en saber cuando un registro cambia a algo que no configuraste. Dotcom-Monitor genera un error y dispara una alerta cuando un nombre de host resuelve a una IP inesperada, para que puedas reaccionar antes de que los usuarios caigan en el servidor equivocado.
Cómo configurar el modo DNS en Dotcom-Monitor
Cambiar el modo de resolución toma unos pocos clics en la tarea de monitoreo. Las etiquetas exactas varían ligeramente según el tipo de dispositivo, pero el flujo es el mismo.
- Paso 1: Abre el dispositivo o tarea que quieres configurar en la plataforma Dotcom-Monitor.
- Paso 2: Edita la configuración de la tarea y encuentra la sección Modo de resolución DNS (o Opciones DNS).
- Paso 3: Elige uno de los cuatro modos: Caché de dispositivo, Sin caché, Caché TTL o Servidor DNS externo.
- Paso 4: Si elegiste Servidor DNS externo, ingresa la dirección IP del resolvedor a consultar, como 8.8.8.8 o 1.1.1.1.
- Paso 5: Guarda la tarea y deja que ejecute algunos intervalos, luego revisa el desglose del tiempo de respuesta para confirmar que el tiempo DNS está como esperas.
Porque cada dispositivo funciona desde la red global de monitoreo de Dotcom-Monitor, puedes comparar cómo se comporta la resolución desde diferentes ubicaciones una vez configurado el modo.
La conclusión
La resolución DNS es lo primero que hace cada verificación, así que el modo de resolución no es una configuración para dejar en piloto automático. Usa caché cuando quieras verificaciones eficientes contra un host compartido. Omite la caché cuando detectar rápidamente una falla DNS sea la tarea. Respeta el TTL cuando quieras tiempos que coincidan con un usuario real. Y apunta a un resolvedor externo cuando necesites probar la vista de un servicio específico.
La mayoría de los equipos terminan usando más de un modo en sus verificaciones, porque un solo monitor rara vez responde todas las preguntas. Ajusta el modo a la razón por la que existe la verificación, y tus números empezarán a contarte la verdad sobre DNS.
Monitorea DNS antes de que rompa tu tiempo de actividad
Configura el modo de resolución que se ajuste a cada verificación y recibe alertas en el momento en que cambia un registro. Dotcom-Monitor ejecuta monitoreo DNS desde una red global con el control de caché que esta guía explica.
