{"id":34295,"date":"2026-07-22T20:44:12","date_gmt":"2026-07-22T20:44:12","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/resolves-dns-in-every-check\/"},"modified":"2026-07-24T21:05:33","modified_gmt":"2026-07-24T21:05:33","slug":"resolves-dns-in-every-check","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/resolves-dns-in-every-check\/","title":{"rendered":"Como o Dotcom-Monitor resolve DNS em cada verifica\u00e7\u00e3o"},"content":{"rendered":"

\"Resolu\u00e7\u00e3o<\/p>\n

Cada verifica\u00e7\u00e3o de monitoramento come\u00e7a da mesma forma. Antes que um \u00fanico byte da sua p\u00e1gina inicial, resposta da API ou banner SMTP volte, o agente de monitoramento precisa transformar um nome de host em um endere\u00e7o IP. Esse primeiro passo \u00e9 a resolu\u00e7\u00e3o de DNS, e como voc\u00ea a configura muda o que seus n\u00fameros de uptime realmente significam.<\/p>\n

A maioria das equipes nunca altera a configura\u00e7\u00e3o de DNS em um monitor. Elas apontam uma verifica\u00e7\u00e3o para api.example.com<\/code>, escolhem um intervalo e seguem em frente. Mas o comportamento do resolvedor por tr\u00e1s dessa verifica\u00e7\u00e3o decide se voc\u00ea est\u00e1 medindo a experi\u00eancia de um usu\u00e1rio real, capturando falhas de DNS em segundos ou produzindo tempos de resposta limpos que voc\u00ea pode comparar entre execu\u00e7\u00f5es. Voc\u00ea n\u00e3o pode otimizar para os tr\u00eas ao mesmo tempo.<\/p>\n

Dotcom-Monitor oferece quatro modos de resolu\u00e7\u00e3o de DNS exatamente por esse motivo. Este guia percorre cada um deles, com foco mais agu\u00e7ado na escolha que a maioria das pessoas erra: cache versus n\u00e3o cache versus cache tempor\u00e1rio (baseado em TTL).<\/p>\n

Por que a Resolu\u00e7\u00e3o de DNS Roda Primeiro em Cada Verifica\u00e7\u00e3o<\/h2>\n

DNS \u00e9 o primeiro salto de quase todo protocolo que voc\u00ea monitora. Uma verifica\u00e7\u00e3o de site, uma chamada de monitoramento de API<\/a>, uma sondagem de monitoramento de servidor de e-mail<\/a>, um teste de monitoramento de ping ICMP<\/a> \u2014 cada um precisa de um endere\u00e7o IP antes de abrir uma conex\u00e3o. Ent\u00e3o o agente resolve o nome do host primeiro, depois executa TCP, TLS e a requisi\u00e7\u00e3o da camada de aplica\u00e7\u00e3o por cima disso.<\/p>\n

Essa ordem \u00e9 importante por duas raz\u00f5es. Primeiro, o tempo da consulta DNS \u00e9 parte do seu tempo total de resposta, ent\u00e3o um resolvedor lento inflaciona todos os n\u00fameros subsequentes. E segundo, uma falha no DNS impede que a verifica\u00e7\u00e3o comece. Se a resolu\u00e7\u00e3o falhar, n\u00e3o h\u00e1 conex\u00e3o para testar, nem certificado para validar, nem c\u00f3digo de status para ler. O monitor reporta uma falha cr\u00edtica, e a causa raiz est\u00e1 uma camada abaixo do que voc\u00ea achava que estava monitorando.<\/p>\n

\"Ciclo
A resolu\u00e7\u00e3o de DNS ocorre antes da conex\u00e3o, handshake e requisi\u00e7\u00e3o em cada verifica\u00e7\u00e3o.<\/figcaption><\/figure>\n

Como o DNS fica na frente de tudo, a forma como um agente trata essa consulta \u00e9 uma decis\u00e3o real de design, n\u00e3o um detalhe. Resolver fresco a cada requisi\u00e7\u00e3o captura problemas no resolvedor r\u00e1pido, mas adiciona carga e tempo de consulta a cada execu\u00e7\u00e3o. Armazenar no cache torna seus n\u00fameros mais r\u00e1pidos e est\u00e1veis, mas um registro de DNS quebrado pode ficar escondido atr\u00e1s do cache por horas. Os modos da Dotcom-Monitor existem para voc\u00ea escolher qual compromisso se encaixa no que voc\u00ea est\u00e1 realmente monitorando. Para um olhar mais profundo sobre como reduzir esse primeiro salto, veja nosso guia para melhorar o tempo de resolu\u00e7\u00e3o de DNS<\/a>.<\/p>\n

Os Quatro Modos de DNS no Dotcom-Monitor<\/h2>\n

Dotcom-Monitor exp\u00f5e quatro modos de resolu\u00e7\u00e3o de DNS em uma tarefa de monitoramento. Cada um muda de onde o endere\u00e7o IP vem e quanto tempo ele permanece.<\/p>\n

Cache do Dispositivo<\/h3>\n

Cache do Dispositivo \u00e9 o padr\u00e3o. Dentro de uma \u00fanica verifica\u00e7\u00e3o 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\u00e7\u00e3o. Se uma tarefa anterior na mesma verifica\u00e7\u00e3o j\u00e1 resolveu o host, a tarefa posterior reutiliza o IP em cache. Caso contr\u00e1rio, o agente faz uma consulta completa e armazena o resultado em cache pelo tempo da verifica\u00e7\u00e3o.<\/p>\n

A vantagem \u00e9 efici\u00eancia. A maioria das verifica\u00e7\u00f5es termina em menos de um minuto, ent\u00e3o n\u00e3o h\u00e1 raz\u00e3o 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\u00e3o a segunda parece mais r\u00e1pida mesmo que nada tenha mudado. Isso \u00e9 um comportamento esperado, n\u00e3o um bug, mas surpreende quem l\u00ea um waterfall pela primeira vez.<\/p>\n

Sem Cache<\/h3>\n

Sem Cache ignora completamente o cache do dispositivo. Cada execu\u00e7\u00e3o da tarefa realiza sua pr\u00f3pria consulta DNS completa, ent\u00e3o nenhuma execu\u00e7\u00e3o usa a resposta de uma execu\u00e7\u00e3o anterior. Isso d\u00e1 um tempo uniforme e compar\u00e1vel porque cada verifica\u00e7\u00e3o paga o mesmo custo de resolu\u00e7\u00e3o completa.<\/p>\n

O custo \u00e9 carga e lat\u00eancia. Uma consulta fresca a cada execu\u00e7\u00e3o adiciona tempo a cada tarefa e gera mais tr\u00e1fego na infraestrutura de DNS. Sem Cache tamb\u00e9m n\u00e3o est\u00e1 dispon\u00edvel para as plataformas baseadas em navegador BrowserView ou UserView. Uma p\u00e1gina real pode carregar dezenas de elementos do mesmo host, e resolver esse nome de host centenas de vezes em poucos segundos n\u00e3o \u00e9 como um navegador funciona, ent\u00e3o resolver uma vez por execu\u00e7\u00e3o \u00e9 o modelo realista ali.<\/p>\n

Cache com TTL<\/h3>\n

Cache com TTL se comporta como um resolvedor real na m\u00e1quina de um usu\u00e1rio. Ele respeita o tempo de vida do registro (TTL): o agente armazena o endere\u00e7o resolvido e continua usando-o at\u00e9 o TTL expirar, ent\u00e3o faz uma nova resolu\u00e7\u00e3o pelo servidor DNS local. Esse \u00e9 o modo que mais se aproxima do que um visitante real experimenta, pois o navegador e o SO cacheiam da mesma forma.<\/p>\n

O risco est\u00e1 nesse mesmo comportamento. Se o servidor DNS respons\u00e1vel pelo registro falha enquanto uma resposta v\u00e1lida ainda est\u00e1 em cache, o monitor pode s\u00f3 perceber quando o TTL expirar, e o TTL pode ser configurado para horas, dias ou mais. Ent\u00e3o Cache com TTL \u00e9 a escolha certa quando voc\u00ea quer um tempo realista da experi\u00eancia do usu\u00e1rio, e a escolha errada quando capturar uma falha de DNS rapidamente \u00e9 o objetivo principal da verifica\u00e7\u00e3o.<\/p>\n

Servidor DNS Externo<\/h3>\n

Servidor DNS Externo direciona a consulta para um IP de resolvedor espec\u00edfico que voc\u00ea escolher. Se voc\u00ea sabe que a maioria dos seus usu\u00e1rios usa um resolvedor p\u00fablico como Google (8.8.8.8, 8.8.4.4) ou Cloudflare (1.1.1.1), pode testar a resolu\u00e7\u00e3o atrav\u00e9s desse servi\u00e7o exato. Tamb\u00e9m pode direcionar para um resolvedor que voc\u00ea sabe ser autoritativo para a zona, para pular a consulta recursiva e obter consultas mais r\u00e1pidas e diretas.<\/p>\n

O limite \u00e9 a cobertura. Enquanto seu resolvedor escolhido responder com uma resposta v\u00e1lida, o monitor v\u00ea sucesso, mesmo que o servidor DNS realmente respons\u00e1vel pelo dom\u00ednio esteja com problemas. Ent\u00e3o esse modo testa a vis\u00e3o de um resolvedor espec\u00edfico, n\u00e3o da cadeia completa. Mais um detalhe importante: cada IP de resolvedor distinto tem seu pr\u00f3prio cache, ent\u00e3o duas tarefas apontadas para servidores externos diferentes mant\u00eam caches separadas.<\/p>\n

Cache vs Sem Cache vs Cache Tempor\u00e1rio<\/h2>\n

Essa \u00e9 a decis\u00e3o que confunde as pessoas, ent\u00e3o vale colocar os tr\u00eas lado a lado. Cache (Cache do Dispositivo) otimiza para efici\u00eancia. Sem cache (Sem Cache) otimiza para tempo compar\u00e1vel e repet\u00edvel e detec\u00e7\u00e3o r\u00e1pida de falha. Cache tempor\u00e1rio (Cache com TTL) otimiza para realismo, envelhecendo registros como um navegador faz.<\/p>\n

\n\n\n\n\n\n\n\n\n
Modo<\/th>\nComo resolve<\/th>\nMelhor para<\/th>\nCompromisso principal<\/th>\n<\/tr>\n<\/thead>\n
Cache do Dispositivo<\/strong> (cache)<\/td>\nUma vez por verifica\u00e7\u00e3o do dispositivo, compartilhado entre suas tarefas<\/td>\nVerifica\u00e7\u00f5es eficientes; m\u00faltiplas tarefas no mesmo host<\/td>\nA primeira tarefa carrega o tempo da consulta; tarefas posteriores parecem mais r\u00e1pidas<\/td>\n<\/tr>\n
Sem Cache<\/strong> (sem cache)<\/td>\nConsulta completa fresca a cada execu\u00e7\u00e3o<\/td>\nTempo uniforme; detec\u00e7\u00e3o r\u00e1pida de problemas de DNS<\/td>\nMaior carga de DNS e lat\u00eancia; n\u00e3o para BrowserView\/UserView<\/td>\n<\/tr>\n
Cache com TTL<\/strong> (cache tempor\u00e1rio)<\/td>\nRespeita o TTL do registro e depois resolve novamente<\/td>\nExperi\u00eancia real do usu\u00e1rio<\/td>\nUm servidor DNS falho pode ficar oculto at\u00e9 o TTL expirar<\/td>\n<\/tr>\n
Servidor DNS Externo<\/strong><\/td>\nConsulta um IP de resolvedor que voc\u00ea especifica<\/td>\nTestes de um resolvedor p\u00fablico ou autoritativo espec\u00edfico<\/td>\nV\u00ea apenas a resposta desse resolvedor, n\u00e3o a cadeia completa<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Resumo r\u00e1pido: use cache para velocidade, pule o cache para detectar falhas r\u00e1pido, respeite o TTL para ver o que os usu\u00e1rios veem. Escolha o que combina com o motivo da verifica\u00e7\u00e3o.<\/p><\/blockquote>\n

Por que a Maioria das Ferramentas de Monitoramento Perdem Problemas de DNS<\/h2>\n

Aqui est\u00e1 o que torna isso importante para configurar: a maioria das ferramentas de monitoramento n\u00e3o te d\u00e1 essa escolha. Elas resolvem um nome uma vez, armazenam no cache e reutilizam essa resposta enquanto o registro durar. Isso funciona at\u00e9 aparecer um problema de DNS em produ\u00e7\u00e3o \u2014 um registro errado, um servidor autoritativo ca\u00eddo, um resolvedor retornando o IP errado \u2014 porque um monitor com cache continua reportando verde contra uma resposta obsoleta enquanto usu\u00e1rios reais enfrentam a falha.<\/p>\n

O controle granular sobre o modo de resolu\u00e7\u00e3o \u00e9 raro no espa\u00e7o de monitoramento. For\u00e7ar uma consulta nova a cada verifica\u00e7\u00e3o, expirar registros pelo TTL, ou direcionar um resolvedor espec\u00edfico s\u00e3o quase uma assinatura da Dotcom-Monitor, e \u00e9 a linha que separa um monitor que assume que o DNS est\u00e1 ok de um que realmente o testa. Se detectar problemas de DNS em produ\u00e7\u00e3o \u00e9 o motivo da verifica\u00e7\u00e3o, o comportamento padr\u00e3o de cachear tudo que a maioria das ferramentas usa \u00e9 exatamente o que os esconde.<\/p>\n

Como Escolher o Modo Certo de DNS<\/h2>\n

O modo que voc\u00ea quer depende da pergunta que o monitor responde. Aqui est\u00e3o os padr\u00f5es que aparecem com mais frequ\u00eancia para equipes DevOps e SRE.<\/p>\n

Voc\u00ea quer capturar falhas de DNS o mais r\u00e1pido poss\u00edvel.<\/strong> Use Sem Cache. Quando a verifica\u00e7\u00e3o existe para alertar voc\u00ea no momento em que a resolu\u00e7\u00e3o quebra \u2014 uma mudan\u00e7a errada no registrador, uma zona expirada, um registro sequestrado \u2014 voc\u00ea n\u00e3o quer uma resposta desatualizada no cache. Resolu\u00e7\u00e3o fresca a cada execu\u00e7\u00e3o significa que a falha aparece na pr\u00f3xima verifica\u00e7\u00e3o, n\u00e3o ap\u00f3s um TTL de v\u00e1rias horas. Combine isso com um alerta<\/a> rigoroso para garantir que a notifica\u00e7\u00e3o alcance algu\u00e9m de plant\u00e3o.<\/p>\n

Voc\u00ea quer tempo que corresponda a um visitante real.<\/strong> Use Cache com TTL. Se a verifica\u00e7\u00e3o suporta um SLA de monitoramento de uptime<\/a> ou alimenta um dashboard de experi\u00eancia real do usu\u00e1rio, resolver do jeito que um navegador resolve mant\u00e9m seus n\u00fameros honestos. Apenas aceite que a detec\u00e7\u00e3o de falha DNS tem um atraso de at\u00e9 um TTL, e adicione uma verifica\u00e7\u00e3o separada Sem Cache caso essa diferen\u00e7a importe.<\/p>\n

Voc\u00ea executa v\u00e1rias tarefas contra o mesmo host.<\/strong> O padr\u00e3o Cache do Dispositivo geralmente \u00e9 o correto. Ele mant\u00e9m a carga DNS razo\u00e1vel e resolve o host uma vez por execu\u00e7\u00e3o. Leia o waterfall por tarefa entendendo o cache: a primeira tarefa carrega o tempo da consulta.<\/p>\n

Voc\u00ea se importa com um resolvedor espec\u00edfico.<\/strong> Use Servidor DNS Externo. Isso serve para equipes que validam que os resolvedores p\u00fablicos do Google ou Cloudflare retornam o registro correto, ou que checam um servidor autoritativo diretamente. \u00c9 um teste direcionado, ent\u00e3o mantenha uma verifica\u00e7\u00e3o mais ampla rodando junto. Para a estrat\u00e9gia geral, nossa lista de ferramentas de monitoramento de DNS<\/a> cobre como as verifica\u00e7\u00f5es se encaixam.<\/p>\n

Quais Erros de DNS Cada Modo Detecta<\/h2>\n

DNS \u00e9 um ponto comum de falha, e falha de mais de uma forma. Registros mudam durante uma migra\u00e7\u00e3o. Uma zona expira. Um servidor autoritativo cai. E no pior caso, um atacante envenena um cache para apontar seu dom\u00ednio a um servidor que ele controla. Seu modo de resolu\u00e7\u00e3o decide qu\u00e3o r\u00e1pido essas falhas aparecem.<\/p>\n

Sem Cache \u00e9 o mais r\u00e1pido para revelar problemas de resolu\u00e7\u00e3o porque nunca confia numa resposta anterior. Cache com TTL \u00e9 o mais lento, pois um registro v\u00e1lido em cache pode sobreviver \u00e0 falha por tr\u00e1s dele. Servidor DNS Externo captura problemas no resolvedor espec\u00edfico que voc\u00ea direciona, mas pode n\u00e3o ver problemas em outras partes da cadeia. Se voc\u00ea quer o panorama completo de como uma verifica\u00e7\u00e3o falha em cada camada, nosso guia de erros de DNS, TCP, TLS e HTTP<\/a> mapeia cada etapa. E se a preocupa\u00e7\u00e3o for quedas, o manual sobre como evitar quedas de DNS<\/a> combina bem com uma verifica\u00e7\u00e3o Sem Cache.<\/p>\n

Qualquer que seja o modo que voc\u00ea use, o objetivo do monitoramento DNS \u00e9 ser o primeiro a saber quando um registro muda para algo que voc\u00ea n\u00e3o configurou. Dotcom-Monitor gera um erro e envia um alerta quando um nome de host resolve para um IP inesperado, para que voc\u00ea possa reagir antes que os usu\u00e1rios cheguem ao servidor errado.<\/p>\n

Como Configurar o Modo DNS no Dotcom-Monitor<\/h2>\n

Mudar o modo de resolu\u00e7\u00e3o leva poucos cliques na tarefa de monitoramento. Os r\u00f3tulos exatos variam um pouco conforme o tipo de dispositivo, mas o fluxo \u00e9 o mesmo.<\/p>\n

    \n
  1. Passo 1:<\/strong> Abra o dispositivo ou tarefa que deseja configurar na plataforma Dotcom-Monitor.<\/li>\n
  2. Passo 2:<\/strong> Edite as configura\u00e7\u00f5es da tarefa e encontre a se\u00e7\u00e3o Modo de Resolu\u00e7\u00e3o DNS (ou Op\u00e7\u00f5es de DNS).<\/li>\n
  3. Passo 3:<\/strong> Escolha um dos quatro modos: Cache do Dispositivo, Sem Cache, Cache com TTL ou Servidor DNS Externo.<\/li>\n
  4. Passo 4:<\/strong> Se escolheu Servidor DNS Externo, insira o endere\u00e7o IP do resolvedor para consulta, como 8.8.8.8 ou 1.1.1.1.<\/li>\n
  5. Passo 5:<\/strong> Salve a tarefa e deixe rodar alguns intervalos; depois confira a divis\u00e3o do tempo de resposta para confirmar se o tempo de DNS est\u00e1 conforme o esperado.<\/li>\n<\/ol>\n

    Como cada dispositivo executa a partir da rede global de monitoramento<\/a> da Dotcom-Monitor, voc\u00ea pode comparar como a resolu\u00e7\u00e3o se comporta em locais diferentes depois de definir o modo.<\/p>\n

    A Conclus\u00e3o<\/h2>\n

    A resolu\u00e7\u00e3o DNS \u00e9 a primeira coisa que toda verifica\u00e7\u00e3o faz, ent\u00e3o o modo de resolu\u00e7\u00e3o n\u00e3o \u00e9 uma configura\u00e7\u00e3o para deixar no piloto autom\u00e1tico. Use cache quando quiser verifica\u00e7\u00f5es eficientes contra um host compartilhado. Pule o cache quando capturar uma falha de DNS r\u00e1pido \u00e9 a tarefa. Respeite o TTL quando quiser o tempo que corresponde a um usu\u00e1rio real. E direcione a um resolvedor externo quando precisar testar a vis\u00e3o de um servi\u00e7o espec\u00edfico.<\/p>\n

    A maioria das equipes acaba rodando mais de um modo em suas verifica\u00e7\u00f5es, porque um \u00fanico monitor raramente responde a todas as perguntas. Combine o modo com o motivo da verifica\u00e7\u00e3o, e seus n\u00fameros come\u00e7am a contar a verdade sobre DNS.<\/p>\n

    \n

    Monitore o DNS Antes que Ele Quebre Seu Uptime<\/h2>\n

    Configure o modo de resolu\u00e7\u00e3o que cabe a cada verifica\u00e7\u00e3o 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.<\/p>\n

    Explore o monitoramento DNS<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    Os modos de resolu\u00e7\u00e3o DNS do Dotcom-Monitor controlam o cache, a velocidade de detec\u00e7\u00e3o de falhas e a precis\u00e3o do tempo do usu\u00e1rio real\u2014saiba qual modo se encaixa nas suas verifica\u00e7\u00f5es de monitoramento.<\/p>\n","protected":false},"author":39,"featured_media":34281,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-34295","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/34295","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/comments?post=34295"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/34295\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media\/34281"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media?parent=34295"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/categories?post=34295"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/tags?post=34295"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}