Cache DNS: como funciona, TTL e como monitorar em produção
Autor: Pedro Tebaldi PM do KeepGreen
Revisão técnica: Ednilson Correa SREToda vez que você abre uma página, o navegador precisa traduzir um nome de domínio em um endereço IP. Esse processo passa por várias camadas de cache antes de chegar a um servidor autoritativo. Ao mesmo tempo, essas camadas explicam tanto a velocidade que você percebe quanto os problemas de mudança que parecem não propagar.
O cache DNS existe por um motivo direto: escala. Sem cache, cada consulta a um domínio popular geraria tráfego para os servidores raiz, depois para os TLD e enfim para os autoritativos. Como resultado, a internet derreteria em segundos. Por isso, resolvedores em vários níveis guardam respostas e as servem localmente até que o TTL expire.
No entanto, o mesmo mecanismo que entrega performance também é a causa raiz de incidentes operacionais clássicos. “Mudei o registro mas o usuário ainda vê o IP antigo”, “o failover não disparou rápido o suficiente”, “a aplicação ficou lenta sem motivo aparente”. Entender o cache DNS é entender por que essas situações acontecem e como agir sobre elas.
O que é cache DNS e por que ele existe
O cache DNS é um armazenamento temporário de respostas a consultas de nome de domínio. Quando um cliente pergunta “qual o IP de exemplo.com?”, a resposta fica guardada em um ou mais pontos da cadeia de resolução. Nas consultas seguintes ao mesmo domínio, o sistema entrega a resposta direto da memória local em vez de refazer toda a hierarquia.
Esse modelo nasceu junto com o próprio DNS, descrito nas RFCs 1034 e 1035 dos anos 80. A lógica é simples: domínios populares são consultados bilhões de vezes ao dia. Se cada consulta batesse no servidor autoritativo, o sistema colapsaria. Por isso, o cache distribuído virou parte central do desenho do protocolo, ao lado dos diferentes tipos de servidores DNS envolvidos na resolução.
Na prática, o ganho aparece no relógio. Em 3 de setembro de 2026 medimos vinte domínios brasileiros de produção contra um resolvedor BIND 9.20.27 montado só para o teste. Com o cache vazio, a mediana de uma resolução completa ficou em 595 ms. Nesse estado, nenhum dos vinte domínios teve mediana abaixo de 224 ms.
Já com a resposta guardada, dezenove dos vinte tiveram mediana de 0 ms. Como uma página carrega dezenas de nomes diferentes, essa diferença muda a latência percebida pelo usuário. Portanto, o número que interessa à operação não é o de uma consulta isolada.
Quanto custa uma consulta sem cache, medido em laboratório
Por trás da expressão “cache vazio” existem dois cenários com custos bem diferentes. Um resolvedor recém-reiniciado não guarda nem a delegação da raiz nem a do TLD. Portanto, a primeira consulta paga a cadeia inteira. Já um resolvedor que roda há horas mantém essas duas etapas em cache e perde apenas o nome, quando o TTL dele expira.
No laboratório, separamos os dois casos. Para o estado frio, o comando rndc flush apaga o cache inteiro antes de cada consulta. No caso morno, o rndc flushname apaga só o nome consultado e preserva a delegação. Depois disso, uma terceira consulta repete o mesmo nome e mede o cache hit.
| Estado do cache | O que o resolvedor já tem guardado | Mediana | Faixa nos 20 domínios |
|---|---|---|---|
| Frio rndc flush | Nada. Paga raiz, TLD e autoritativo na mesma consulta | 595 ms | 224 a 1.522 ms |
| Morno flushname | A delegação da raiz e do TLD. Só falta o nome | 225 ms | 36 a 338 ms |
| Quente cache hit | A própria resposta, dentro do TTL | 0 ms | 0 ms em 19 dos 20 |
Na leitura operacional, o recado é direto. No dia a dia, a operação paga o custo do estado morno, perto de 225 ms, porque raiz e TLD ficam em cache por horas. Os 595 ms do estado frio só aparecem depois de reiniciar o resolvedor. Ou seja, a janela logo após uma manutenção é o pior momento para medir latência de DNS.
Vale uma nota sobre o vigésimo domínio. Ele publica TTL 0 no registro A, o valor que proíbe qualquer resolvedor de guardar a resposta. Logo, pagou 76 ms mesmo na terceira consulta seguida ao mesmo nome. TTL 0 não é cache curto: é cache nenhum.
Como funciona o cache DNS em camadas
A resolução de um nome não passa por uma única caixa preta. Ela atravessa uma cadeia hierárquica de caches. Cada camada tem seu próprio TTL e suas próprias regras de invalidação. Dessa forma, quando uma resposta volta para o cliente, ela pode ter vindo de qualquer ponto dessa cadeia. Ou seja, raramente vem do servidor autoritativo original.
Toda consulta começa no cache do navegador. Em seguida, ela passa pelo cache do sistema operacional, pelo resolvedor recursivo da rede e enfim pelos servidores autoritativos. Assim, cada camada que entrega a resposta encerra a consulta antes que ela continue subindo.
Esse desenho tem um efeito colateral. Ele torna o DNS escalável, porém também torna difícil diagnosticar problema de propagação.
| Camada | Onde mora o cache | Por que importa |
|---|---|---|
| Navegador | Cache interno do Chrome, Firefox ou Edge. Visível em chrome://net-internals/#dns |
Primeira parada da consulta; ignora o TTL do servidor em alguns casos |
| Sistema operacional | DNS Client Service no Windows, systemd-resolved no Linux, mDNSResponder no macOS |
Cache compartilhado entre apps do mesmo host |
| Resolver recursivo | DNS interno corporativo (BIND, Unbound, AD DNS) ou público (1.1.1.1, 8.8.8.8) | Maior volume de respostas servidas; concentra a maior parte do hit rate |
| Servidor autoritativo | Servidor oficial da zona, controlado pelo dono do domínio | Última fonte da verdade; só é consultado quando todas as outras camadas falham ou expiram |
TTL: o teto, não a promessa
O TTL (Time To Live) é o valor em segundos que define por quanto tempo um registro pode ficar em cache. Quem define é o dono do domínio, no servidor autoritativo. Além disso, cada resposta DNS carrega seu próprio TTL. Toda camada de cache respeita esse valor, ao menos em teoria.
Vale um aviso de nomenclatura antes de seguir. O TTL do DNS conta tempo em segundos, ao contrário do TTL que aparece na saída do ping, que conta saltos de roteador. As duas siglas são iguais e as grandezas não.
Aqui está o ponto que mais gera incidente: o TTL é um teto, não uma promessa. Isto é, ele indica o tempo máximo que a resposta pode ser considerada válida. Resolvedores e clientes podem descartar antes, por pressão de memória ou política interna.
Como resultado, uma mudança de DNS pode propagar mais rápido do que o TTL sugere. No entanto, também pode demorar mais. Cada camada conta o tempo a partir do momento em que recebeu a resposta, não a partir da hora em que você publicou a mudança.
Em produção, isso tem consequência direta. Imagine que você publica uma mudança ao meio-dia num registro com TTL de 1 hora. Alguns resolvedores vão atualizar em segundos. Já outros seguram a versão antiga por até 1 hora inteira, contada da primeira vez que guardaram o registro.
Por fim, o usuário no fim da cadeia pode ver a resposta antiga por horas. O tempo dele depende de quando cada camada acima atualizou, o que ninguém consegue prever de fora.
Positive caching e negative caching
Existem dois tipos distintos de cache no DNS. O positive caching guarda respostas afirmativas. Já o negative caching guarda respostas negativas. A diferença entre os dois muda totalmente o comportamento percebido em produção.
Positive caching é o comportamento intuitivo. Quando uma consulta retorna um registro válido, o resolvedor armazena essa resposta pelo TTL definido. A partir daí, nas consultas ao mesmo nome e tipo, ele entrega a resposta direto do cache. No final das contas, é esse o mecanismo que dá performance ao DNS.
Menos óbvio, o negative caching conta tanto quanto o outro. Ele guarda dois tipos de erro. O primeiro é o NXDOMAIN, quando o domínio não existe. O segundo é o NODATA, quando o domínio existe sem o registro pedido. Nesse sentido, a duração vem do campo SOA da zona, conforme descreve a RFC 2308. Dessa forma, um domínio quebrado deixa de ser consultado milhões de vezes seguidas.
Em síntese, esse comportamento explica um sintoma operacional comum: você cria um subdomínio novo, mas alguns clientes continuam recebendo NXDOMAIN por minutos. A resposta negativa anterior está cacheada e só vai expirar quando o TTL da SOA permitir.
Como verificar e limpar o cache DNS na prática
Assim como debugar uma aplicação sem ver os logs, diagnosticar DNS sem inspecionar o cache é trabalho às cegas. Felizmente, todos os sistemas operacionais oferecem comandos nativos para isso. Além disso, ferramentas como dig e nslookup permitem ver o TTL real de uma resposta.
Inspecionando o TTL com dig
Para investigar resposta DNS, o comando dig é o padrão de fato. Ele mostra o registro, o TTL restante e a fonte da resposta. Em seguida, basta repetir a consulta para ver o contador decrescer até zero. Nesse momento, o resolvedor busca uma cópia nova no autoritativo.
Limpando o cache por sistema operacional
Cada sistema tem seu comando próprio. Em ambiente corporativo, costuma ser preciso limpar o cache em todas as camadas. A lista inclui a estação do usuário, o resolvedor recursivo e às vezes o próprio navegador. Antes de tudo, aplique o flush local, que resolve a maioria dos casos.
Estratégias de TTL para produção
Não existe TTL ideal universal. O valor certo depende de quanto a equipe precisa balancear performance, custo e agilidade para mudanças. Em geral, registros estáveis aceitam TTL alto. Registros voláteis pedem TTL baixo. Cenários de migração exigem ajustes temporários planejados.
Antes de qualquer mudança crítica de DNS, a prática recomendada é reduzir o TTL com 24 a 48 horas de antecedência. Dessa forma, quando a alteração efetiva acontecer, o tempo máximo que qualquer resolvedor vai segurar a resposta antiga será o TTL reduzido. Depois que a propagação completar, eleva-se o TTL de volta ao normal.
| Cenário | TTL sugerido | Por que |
|---|---|---|
| CríticoFailover ativo / DNS dinâmico | 30 a 60 s | Permite reroteamento em segundos; aceita maior carga no autoritativo |
| AltoPré-migração planejada | 300 s | Janela curta para rollback; reduzir 48h antes da troca |
| MédioAplicação web em produção | 3600 s | Padrão equilibrado: 1 hora entre performance e agilidade |
| BaixoNS, MX, registros estáveis | 86400 s | 24h reduz carga no autoritativo; mudanças são raras |
TTL em segundos: tabela de conversão e o custo de cada valor
Todo painel de provedor mostra o TTL em segundos, assim como a saída do dig. Quem opera precisa converter de cabeça, principalmente na hora de decidir se uma janela de mudança cabe dentro do fim de semana. A tabela abaixo traz os valores mais comuns já convertidos.
Cada valor cobra um preço. A última coluna mostra quantas vezes um resolvedor volta ao servidor autoritativo em 24 horas, considerando um nome consultado sem parar. É a conta que explica por que TTL baixo custa carga: descer de 1 hora para 1 minuto multiplica por 60 o número de idas.
| TTL em segundos | Tempo legível | Uso típico | Idas ao autoritativo em 24 h |
|---|---|---|---|
| 30 | 30 segundos | Failover ativo. Aceita 2.880 idas por dia | 2.880 |
| 60 | 1 minuto | Registro que muda sozinho, como DNS dinâmico | 1.440 |
| 300 | 5 minutos | Janela de migração. O valor mais comum no registro A | 288 |
| 600 | 10 minutos | Meio-termo para quem migra sem pressa | 144 |
| 1800 | 30 minutos | Aplicação que muda de endereço poucas vezes ao ano | 48 |
| 3600 | 1 hora | Padrão de aplicação web em produção | 24 |
| 14400 | 4 horas | Registro estável de infraestrutura interna | 6 |
| 43200 | 12 horas | Nome que praticamente não muda | 2 |
| 86400 | 24 horas | MX e registros de e-mail | 1 |
| 172800 | 48 horas | NS e delegação. Mudar exige planejamento | 1 a cada 2 dias |
Cache poisoning: o ataque que mudou o DNS
O cache DNS resolve problemas de escala, mas também abre uma superfície de ataque. O cache poisoning consiste em injetar uma resposta falsa no cache de um resolvedor, fazendo com que ele entregue um IP malicioso aos clientes. Por consequência, vítimas acessam um servidor controlado pelo atacante achando que estão no domínio legítimo.
O ataque mais famoso é o de Dan Kaminsky, divulgado em 2008. Ele explorou a previsibilidade dos campos transaction ID e source port do DNS. Com isso, um atacante conseguia adivinhar a resposta certa antes de o servidor autoritativo legítimo responder. Em poucas semanas, os resolvedores do mundo inteiro receberam source port randomization como correção emergencial.
Hoje, as defesas modernas combinam três camadas. A primeira é source port randomization, que leva de 16 para 32 bits o espaço de adivinhação. A segunda é 0x20 encoding, que mistura maiúsculas e minúsculas no nome consultado. A terceira é DNSSEC, que assina as respostas.
Além disso, o guia SP 800-81 do NIST traz as recomendações oficiais para implantar essas defesas em ambiente corporativo.
Monitoramento de cache DNS em operação
Cache DNS bem desenhado é invisível quando funciona e desastroso quando falha. Por isso, monitorar o comportamento do cache é tão importante quanto monitorar o próprio servidor DNS. Três métricas concentram o sinal operacional: hit ratio, latência de lookup e taxa de respostas negativas.
O hit ratio mede o percentual de consultas servidas direto do cache contra as que precisaram subir até o autoritativo. Antes de virar alerta, porém, ele precisa de uma linha de base própria. O valor saudável de um resolvedor sai do TTL dos nomes que ele serve e da frequência com que os clientes perguntam.
Em seguida vem a latência de lookup, que mede quanto tempo o resolvedor demora para responder. No cache hit, dezenove dos vinte domínios do teste tiveram mediana de 0 ms. No cache miss, as medianas foram de 36 ms a 1.522 ms, conforme o estado em que o cache estava.
Ou seja, a faixa é larga demais para caber num limiar de manual. Portanto, calibre o alerta pela distribuição do seu próprio resolvedor. Pico repentino de latência sinaliza problema de rede, falha de upstream ou ataque em curso, a mesma disciplina do monitoramento do tráfego de redes.
Por fim, a taxa de NXDOMAIN e SERVFAIL é o termômetro mais rápido de problemas. Por exemplo, subidas súbitas indicam erro de configuração, ataque de DNS tunneling ou aplicação tentando resolver domínio que não existe. Ferramentas como blackbox_exporter, Zabbix e probes sintéticas integram esses sinais a pipelines de alertas, complementando o monitoramento de DNS que já roda na operação.
De onde vem o hit ratio, e por que 80% pode ser saudável
O hit ratio não é uma nota de saúde do cache. Ele é consequência aritmética de duas coisas que você já controla: o TTL do registro e a frequência das consultas. Um nome com TTL de 5 segundos, consultado uma vez por segundo, obriga o resolvedor a buscar de novo a cada cinco consultas.
Para medir, submetemos o mesmo resolvedor a noventa consultas ao mesmo nome, uma por segundo. O nome saiu de uma zona de teste nossa, o que permitiu mudar só o TTL entre uma rodada e outra. Os contadores vêm do próprio BIND, pelo canal de estatísticas.
Calcular o hit ratio é uma divisão: 1 menos a razão entre QryRecursion e o total de consultas recebidas. Como o BIND não zera contador, os dois números saem da diferença entre um snapshot antes da carga e outro depois.
| TTL do registro | Prefetch ligado | Prefetch desligado | Previsto pela conta | O que o número esconde |
|---|---|---|---|---|
| 5 s | 80,0% | 80,0% | 78,9% | Abaixo do limite de 9 s: o prefetch não vale |
| 30 s | 100,0% | 96,7% | 95,6% | O prefetch apagou 3 misses do painel |
| 60 s | 100,0% | 98,9% | 97,8% | O prefetch apagou 1 miss do painel |
| 300 s | 100,0% | 100,0% | 98,9% | Nada expira na janela de 90 s |
O teste trouxe uma armadilha que vale para qualquer painel de DNS. Com o prefetch ligado, que é o padrão do BIND, o hit ratio deu 100% em três dos quatro TTLs. O resolvedor renova o registro em segundo plano pouco antes de o TTL zerar, então o cliente nunca enxerga o miss.
Desligado o prefetch, os valores caíram para o que a aritmética previa. Ou seja, o painel de hit ratio mede o que o cliente sentiu, não o trabalho que o resolvedor fez. Para acompanhar carga no autoritativo, o contador certo é o de consultas de saída.
Por um motivo documentado, o TTL de 5 segundos ficou igual nos dois modos. O prefetch só aceita registro cujo TTL original chegue a 9 segundos. Além disso, ele dispara quando faltam 2 segundos para o vencimento. Os dois limites estão na referência de configuração do BIND 9.
Identificamos gargalos de rede antes que virem incidentes críticos.
Análise de tráfego com NetFlow, sFlow e SNMP para mapeamento completo de latência, perda de pacotes e capacidade de banda.
Conclusão
O cache DNS é uma das engrenagens mais silenciosas da infraestrutura de internet. Também é uma das que mais geram surpresa quando algo dá errado. Entender as quatro camadas, o comportamento real do TTL e a diferença entre positive e negative caching transforma horas de troubleshooting em minutos de diagnóstico.
Em operações maduras, o cache DNS deixa de ser detalhe técnico e vira métrica de primeira classe, ao lado de uptime e latência. Três práticas sustentam essa mudança. São elas: ajustar o TTL por cenário, medir o hit ratio contra a linha de base e blindar o resolvedor contra cache poisoning. Todas afetam direto a disponibilidade das aplicações críticas.
Isso vale tanto para a rede interna quanto para a camada de transporte que sustenta as consultas. Enquanto o cache entrega em 0 ms, ninguém percebe que o DNS existe.
Se a sua equipe ainda trata DNS como caixa preta, vale conversar com quem já integrou essa medição ao resto da operação de rede. Fale com um especialista da OpServices e veja como encaixar o monitoramento de DNS no seu projeto de tráfego de rede.
Perguntas Frequentes
O que é cache DNS e por que ele existe?
O que é TTL no DNS e como ele controla o cache?
TTL de 3600 segundos é quanto tempo em minutos?
Como limpar o cache DNS no Windows, Linux e macOS?
ipconfig /flushdns. No Linux com systemd-resolved, use sudo resolvectl flush-caches. No macOS a partir do Big Sur, combine sudo dscacheutil -flushcache e sudo killall -HUP mDNSResponder. Em ambientes corporativos com resolver recursivo BIND, use rndc flush para limpar tudo ou rndc flushname dominio.com para limpar apenas um nome específico. Lembre que o cache do navegador é independente e exige flush próprio quando o problema vem dele.Por que mudanças de DNS demoram para propagar mesmo após eu alterar o registro?
O que é cache poisoning e como me proteger?
