Cada verificação de monitoramento começa da mesma forma. Antes que um único byte da sua página inicial, resposta da API ou banner SMTP volte, o agente de monitoramento precisa transformar um nome de host em um endereço IP. Esse primeiro passo é a resolução de DNS, e como você a configura muda o que seus números de uptime realmente significam.
A maioria das equipes nunca altera a configuração de DNS em um monitor. Elas apontam uma verificação para api.example.com, escolhem um intervalo e seguem em frente. Mas o comportamento do resolvedor por trás dessa verificação decide se você está medindo a experiência de um usuário real, capturando falhas de DNS em segundos ou produzindo tempos de resposta limpos que você pode comparar entre execuções. Você não pode otimizar para os três ao mesmo tempo.
Dotcom-Monitor oferece quatro modos de resolução de DNS exatamente por esse motivo. Este guia percorre cada um deles, com foco mais aguçado na escolha que a maioria das pessoas erra: cache versus não cache versus cache temporário (baseado em TTL).
Por que a Resolução de DNS Roda Primeiro em Cada Verificação
DNS é o primeiro salto de quase todo protocolo que você monitora. Uma verificação de site, uma chamada de monitoramento de API, uma sondagem de monitoramento de servidor de e-mail, um teste de monitoramento de ping ICMP — cada um precisa de um endereço IP antes de abrir uma conexão. Então o agente resolve o nome do host primeiro, depois executa TCP, TLS e a requisição da camada de aplicação por cima disso.
Essa ordem é importante por duas razões. Primeiro, o tempo da consulta DNS é parte do seu tempo total de resposta, então um resolvedor lento inflaciona todos os números subsequentes. E segundo, uma falha no DNS impede que a verificação comece. Se a resolução falhar, não há conexão para testar, nem certificado para validar, nem código de status para ler. O monitor reporta uma falha crítica, e a causa raiz está uma camada abaixo do que você achava que estava monitorando.
Como o DNS fica na frente de tudo, a forma como um agente trata essa consulta é uma decisão real de design, não um detalhe. Resolver fresco a cada requisição captura problemas no resolvedor rápido, mas adiciona carga e tempo de consulta a cada execução. Armazenar no cache torna seus números mais rápidos e estáveis, mas um registro de DNS quebrado pode ficar escondido atrás do cache por horas. Os modos da Dotcom-Monitor existem para você escolher qual compromisso se encaixa no que você está realmente monitorando. Para um olhar mais profundo sobre como reduzir esse primeiro salto, veja nosso guia para melhorar o tempo de resolução de DNS.
Os Quatro Modos de DNS no Dotcom-Monitor
Dotcom-Monitor expõe quatro modos de resolução de DNS em uma tarefa de monitoramento. Cada um muda de onde o endereço IP vem e quanto tempo ele permanece.
Cache do Dispositivo
Cache do Dispositivo é o padrão. Dentro de uma única verificação de dispositivo, o agente resolve cada nome de host uma vez e compartilha essa resposta entre todas as tarefas naquele dispositivo durante o restante da execução. Se uma tarefa anterior na mesma verificação já resolveu o host, a tarefa posterior reutiliza o IP em cache. Caso contrário, o agente faz uma consulta completa e armazena o resultado em cache pelo tempo da verificação.
A vantagem é eficiência. A maioria das verificações termina em menos de um minuto, então não há razão para resolver o mesmo host a cada poucos segundos. A pegadinha aparece no tempo por tarefa. Se um dispositivo monitora duas URLs no mesmo host, a primeira URL carrega o tempo da consulta DNS e a segunda usa o IP em cache, então a segunda parece mais rápida mesmo que nada tenha mudado. Isso é um comportamento esperado, não um bug, mas surpreende quem lê um waterfall pela primeira vez.
Sem Cache
Sem Cache ignora completamente o cache do dispositivo. Cada execução da tarefa realiza sua própria consulta DNS completa, então nenhuma execução usa a resposta de uma execução anterior. Isso dá um tempo uniforme e comparável porque cada verificação paga o mesmo custo de resolução completa.
O custo é carga e latência. Uma consulta fresca a cada execução adiciona tempo a cada tarefa e gera mais tráfego na infraestrutura de DNS. Sem Cache também não está disponível para as plataformas baseadas em navegador BrowserView ou UserView. Uma página real pode carregar dezenas de elementos do mesmo host, e resolver esse nome de host centenas de vezes em poucos segundos não é como um navegador funciona, então resolver uma vez por execução é o modelo realista ali.
Cache com TTL
Cache com TTL se comporta como um resolvedor real na máquina de um usuário. Ele respeita o tempo de vida do registro (TTL): o agente armazena o endereço resolvido e continua usando-o até o TTL expirar, então faz uma nova resolução pelo servidor DNS local. Esse é o modo que mais se aproxima do que um visitante real experimenta, pois o navegador e o SO cacheiam da mesma forma.
O risco está nesse mesmo comportamento. Se o servidor DNS responsável pelo registro falha enquanto uma resposta válida ainda está em cache, o monitor pode só perceber quando o TTL expirar, e o TTL pode ser configurado para horas, dias ou mais. Então Cache com TTL é a escolha certa quando você quer um tempo realista da experiência do usuário, e a escolha errada quando capturar uma falha de DNS rapidamente é o objetivo principal da verificação.
Servidor DNS Externo
Servidor DNS Externo direciona a consulta para um IP de resolvedor específico que você escolher. Se você sabe que a maioria dos seus usuários usa um resolvedor público como Google (8.8.8.8, 8.8.4.4) ou Cloudflare (1.1.1.1), pode testar a resolução através desse serviço exato. Também pode direcionar para um resolvedor que você sabe ser autoritativo para a zona, para pular a consulta recursiva e obter consultas mais rápidas e diretas.
O limite é a cobertura. Enquanto seu resolvedor escolhido responder com uma resposta válida, o monitor vê sucesso, mesmo que o servidor DNS realmente responsável pelo domínio esteja com problemas. Então esse modo testa a visão de um resolvedor específico, não da cadeia completa. Mais um detalhe importante: cada IP de resolvedor distinto tem seu próprio cache, então duas tarefas apontadas para servidores externos diferentes mantêm caches separadas.
Cache vs Sem Cache vs Cache Temporário
Essa é a decisão que confunde as pessoas, então vale colocar os três lado a lado. Cache (Cache do Dispositivo) otimiza para eficiência. Sem cache (Sem Cache) otimiza para tempo comparável e repetível e detecção rápida de falha. Cache temporário (Cache com TTL) otimiza para realismo, envelhecendo registros como um navegador faz.
| Modo | Como resolve | Melhor para | Compromisso principal |
|---|---|---|---|
| Cache do Dispositivo (cache) | Uma vez por verificação do dispositivo, compartilhado entre suas tarefas | Verificações eficientes; múltiplas tarefas no mesmo host | A primeira tarefa carrega o tempo da consulta; tarefas posteriores parecem mais rápidas |
| Sem Cache (sem cache) | Consulta completa fresca a cada execução | Tempo uniforme; detecção rápida de problemas de DNS | Maior carga de DNS e latência; não para BrowserView/UserView |
| Cache com TTL (cache temporário) | Respeita o TTL do registro e depois resolve novamente | Experiência real do usuário | Um servidor DNS falho pode ficar oculto até o TTL expirar |
| Servidor DNS Externo | Consulta um IP de resolvedor que você especifica | Testes de um resolvedor público ou autoritativo específico | Vê apenas a resposta desse resolvedor, não a cadeia completa |
Resumo rápido: use cache para velocidade, pule o cache para detectar falhas rápido, respeite o TTL para ver o que os usuários veem. Escolha o que combina com o motivo da verificação.
Por que a Maioria das Ferramentas de Monitoramento Perdem Problemas de DNS
Aqui está o que torna isso importante para configurar: a maioria das ferramentas de monitoramento não te dá essa escolha. Elas resolvem um nome uma vez, armazenam no cache e reutilizam essa resposta enquanto o registro durar. Isso funciona até aparecer um problema de DNS em produção — um registro errado, um servidor autoritativo caído, um resolvedor retornando o IP errado — porque um monitor com cache continua reportando verde contra uma resposta obsoleta enquanto usuários reais enfrentam a falha.
O controle granular sobre o modo de resolução é raro no espaço de monitoramento. Forçar uma consulta nova a cada verificação, expirar registros pelo TTL, ou direcionar um resolvedor específico são quase uma assinatura da Dotcom-Monitor, e é a linha que separa um monitor que assume que o DNS está ok de um que realmente o testa. Se detectar problemas de DNS em produção é o motivo da verificação, o comportamento padrão de cachear tudo que a maioria das ferramentas usa é exatamente o que os esconde.
Como Escolher o Modo Certo de DNS
O modo que você quer depende da pergunta que o monitor responde. Aqui estão os padrões que aparecem com mais frequência para equipes DevOps e SRE.
Você quer capturar falhas de DNS o mais rápido possível. Use Sem Cache. Quando a verificação existe para alertar você no momento em que a resolução quebra — uma mudança errada no registrador, uma zona expirada, um registro sequestrado — você não quer uma resposta desatualizada no cache. Resolução fresca a cada execução significa que a falha aparece na próxima verificação, não após um TTL de várias horas. Combine isso com um alerta rigoroso para garantir que a notificação alcance alguém de plantão.
Você quer tempo que corresponda a um visitante real. Use Cache com TTL. Se a verificação suporta um SLA de monitoramento de uptime ou alimenta um dashboard de experiência real do usuário, resolver do jeito que um navegador resolve mantém seus números honestos. Apenas aceite que a detecção de falha DNS tem um atraso de até um TTL, e adicione uma verificação separada Sem Cache caso essa diferença importe.
Você executa várias tarefas contra o mesmo host. O padrão Cache do Dispositivo geralmente é o correto. Ele mantém a carga DNS razoável e resolve o host uma vez por execução. Leia o waterfall por tarefa entendendo o cache: a primeira tarefa carrega o tempo da consulta.
Você se importa com um resolvedor específico. Use Servidor DNS Externo. Isso serve para equipes que validam que os resolvedores públicos do Google ou Cloudflare retornam o registro correto, ou que checam um servidor autoritativo diretamente. É um teste direcionado, então mantenha uma verificação mais ampla rodando junto. Para a estratégia geral, nossa lista de ferramentas de monitoramento de DNS cobre como as verificações se encaixam.
Quais Erros de DNS Cada Modo Detecta
DNS é um ponto comum de falha, e falha de mais de uma forma. Registros mudam durante uma migração. Uma zona expira. Um servidor autoritativo cai. E no pior caso, um atacante envenena um cache para apontar seu domínio a um servidor que ele controla. Seu modo de resolução decide quão rápido essas falhas aparecem.
Sem Cache é o mais rápido para revelar problemas de resolução porque nunca confia numa resposta anterior. Cache com TTL é o mais lento, pois um registro válido em cache pode sobreviver à falha por trás dele. Servidor DNS Externo captura problemas no resolvedor específico que você direciona, mas pode não ver problemas em outras partes da cadeia. Se você quer o panorama completo de como uma verificação falha em cada camada, nosso guia de erros de DNS, TCP, TLS e HTTP mapeia cada etapa. E se a preocupação for quedas, o manual sobre como evitar quedas de DNS combina bem com uma verificação Sem Cache.
Qualquer que seja o modo que você use, o objetivo do monitoramento DNS é ser o primeiro a saber quando um registro muda para algo que você não configurou. Dotcom-Monitor gera um erro e envia um alerta quando um nome de host resolve para um IP inesperado, para que você possa reagir antes que os usuários cheguem ao servidor errado.
Como Configurar o Modo DNS no Dotcom-Monitor
Mudar o modo de resolução leva poucos cliques na tarefa de monitoramento. Os rótulos exatos variam um pouco conforme o tipo de dispositivo, mas o fluxo é o mesmo.
- Passo 1: Abra o dispositivo ou tarefa que deseja configurar na plataforma Dotcom-Monitor.
- Passo 2: Edite as configurações da tarefa e encontre a seção Modo de Resolução DNS (ou Opções de DNS).
- Passo 3: Escolha um dos quatro modos: Cache do Dispositivo, Sem Cache, Cache com TTL ou Servidor DNS Externo.
- Passo 4: Se escolheu Servidor DNS Externo, insira o endereço IP do resolvedor para consulta, como 8.8.8.8 ou 1.1.1.1.
- Passo 5: Salve a tarefa e deixe rodar alguns intervalos; depois confira a divisão do tempo de resposta para confirmar se o tempo de DNS está conforme o esperado.
Como cada dispositivo executa a partir da rede global de monitoramento da Dotcom-Monitor, você pode comparar como a resolução se comporta em locais diferentes depois de definir o modo.
A Conclusão
A resolução DNS é a primeira coisa que toda verificação faz, então o modo de resolução não é uma configuração para deixar no piloto automático. Use cache quando quiser verificações eficientes contra um host compartilhado. Pule o cache quando capturar uma falha de DNS rápido é a tarefa. Respeite o TTL quando quiser o tempo que corresponde a um usuário real. E direcione a um resolvedor externo quando precisar testar a visão de um serviço específico.
A maioria das equipes acaba rodando mais de um modo em suas verificações, porque um único monitor raramente responde a todas as perguntas. Combine o modo com o motivo da verificação, e seus números começam a contar a verdade sobre DNS.
Monitore o DNS Antes que Ele Quebre Seu Uptime
Configure o modo de resolução que cabe a cada verificação e receba alertas no momento em que um registro mudar. Dotcom-Monitor roda monitoramento DNS a partir de uma rede global com o controle de cache que este guia explica.
