Cache DNS: como funciona, TTL e como monitorar em produção

Toda 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. Essas camadas explicam tanto a velocidade que você percebe quanto os problemas misteriosos de mudanças 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. A internet derreteria em segundos. Por isso, resolvers 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 fundamental do desenho do protocolo, ao lado dos diferentes tipos de servidores DNS envolvidos na resolução.

Na prática, o tempo médio de uma resolução completa sem cache passa de 100 ms em ambientes corporativos. Com cache local, esse valor cai para frações de milissegundo. Esse impacto se multiplica por dezenas de domínios em uma página web, afetando direto a latência percebida pelo usuário.

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. Ou seja, quando uma resposta volta para o cliente, ela pode ter vindo de qualquer ponto dessa cadeia. Raramente vem do servidor autoritativo original.

A consulta começa no cache do navegador, segue para o cache do sistema operacional, depois para o resolver recursivo configurado na rede e enfim para os servidores autoritativos. Cada camada que entrega a resposta encerra a consulta antes que ela continue subindo. Vale destacar: esse desenho é o que torna o DNS escalável, mas também é o que torna problemas de propagação tão difíceis de diagnosticar.

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. Ele é definido pelo dono do domínio no servidor autoritativo. Cada resposta DNS carrega seu próprio TTL. Cada camada de cache respeita esse valor, ao menos em teoria.

Vale destacar um ponto importante: o TTL é um teto, não uma promessa. Ele indica o tempo máximo que a resposta pode ser considerada válida. Resolvers e clientes podem descartar antes, por pressão de memória ou política interna. Ou seja, uma mudança DNS pode propagar mais rápido que o TTL sugere. No entanto, também pode demorar mais, porque cada camada conta o tempo a partir do momento em que recebeu a resposta.

Em produção, isso tem consequência direta. Imagine que você publica uma mudança ao meio-dia em um registro com TTL de 1 hora. Alguns resolvers vão atualizar em segundos. Outros vão segurar a versão antiga por até 1 hora inteira, contada a partir da primeira vez que cachearam o registro. Por fim, o usuário no fim da cadeia pode ver a resposta antiga por horas, dependendo de quando cada camada acima dele atualizou.

Positive caching e negative caching

Existem dois tipos distintos de cache no DNS. O positive caching guarda respostas afirmativas. O negative caching guarda respostas negativas. A diferença entre os dois muda totalmente o comportamento percebido em produção.

O positive caching é o comportamento intuitivo. Quando uma consulta retorna um registro válido, o resolver armazena essa resposta pelo TTL definido. Em consultas seguintes ao mesmo nome e tipo, ele entrega a resposta direto do cache. Esse é o mecanismo que dá performance ao DNS.

O negative caching é menos óbvio mas igualmente importante. Quando uma consulta retorna um erro do tipo NXDOMAIN (domínio não existe) ou NODATA (domínio existe mas não tem o registro pedido), o resolver também guarda esse erro em cache. A duração é controlada pelo campo SOA da zona, conforme descrito na RFC 2308. Isso evita que um domínio quebrado seja 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

Diagnosticar um problema de DNS sem inspecionar o cache é como debugar uma aplicação sem ver os logs. 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

O comando dig é o padrão de fato para investigar respostas DNS. Ele mostra o registro, o TTL restante e a fonte da resposta. Em seguida, basta repetir a consulta para ver o contador decrescendo até zero, quando o resolver vai buscar uma nova cópia no autoritativo.

# Consulta direta ao autoritativo, ignorando cache local
dig +noall +answer exemplo.com @1.1.1.1

# Ver o TTL restante decrescendo no resolver recursivo
dig exemplo.com +noall +answer
dig exemplo.com +noall +answer

# Forçar trace completo da raiz até o autoritativo
dig +trace exemplo.com

Limpando o cache por sistema operacional

Cada sistema tem seu comando próprio. Em ambientes corporativos é comum precisar limpar o cache em todas as camadas: na estação do usuário, no resolver recursivo e às vezes no próprio navegador. Antes de tudo, vale aplicar o flush local, que resolve a maioria dos casos.

# Windows (PowerShell ou cmd como admin)
ipconfig /flushdns

# Linux com systemd-resolved
sudo resolvectl flush-caches

# macOS (Big Sur ou superior)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# BIND como resolver recursivo
rndc flush
rndc flushname exemplo.com

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 resolver vai segurar a resposta antiga será o TTL reduzido. Depois que a propagação completar, eleva-se o TTL de volta ao normal.

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 resolver, 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, permitindo que um atacante “adivinhasse” a resposta certa antes do servidor autoritativo legítimo responder. A correção emergencial foi implementar source port randomization em todos os resolvers do mundo em poucas semanas.

Hoje, as defesas modernas combinam três camadas. A primeira é source port randomization, que aumenta 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 criptograficamente as respostas. O guia SP 800-81 do NIST traz as recomendações oficiais para implantação dessas defesas em ambientes corporativos.

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 versus consultas que precisaram subir até o autoritativo. Em resolvers internos saudáveis, esse número fica entre 80% e 95%. Valores abaixo disso indicam TTL mal calibrado, cache subdimensionado ou um padrão de consulta anormal. Frequentemente, é o primeiro indício de problema antes que vire incidente.

A latência de lookup mede quanto tempo o resolver demora para responder. Em cache hit, esse valor deve ficar abaixo de 5 ms. Em cache miss, varia entre 20 ms e 200 ms dependendo da localização do autoritativo. Picos repentinos sinalizam problemas de rede, falha de upstream ou ataque em curso. Aprofundar essas métricas exige a mesma disciplina aplicada no monitoramento do tráfego de redes da empresa.

Por fim, a taxa de NXDOMAIN e SERVFAIL é o termômetro mais rápido de problemas. Subidas súbitas indicam erros de configuração, ataques de DNS tunneling ou aplicações tentando resolver domínios que não existem. 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.

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 camadas (browser, OS, resolver, autoritativo), o comportamento real do TTL e a diferença entre positive e negative caching transforma horas de troubleshooting em minutos de diagnóstico objetivo.

Em operações maduras, o cache DNS deixa de ser um detalhe técnico e vira métrica de primeira classe ao lado de uptime e latência. Ajustar TTL por cenário, monitorar hit ratio e proteger contra cache poisoning são práticas que afetam direto a disponibilidade de aplicações críticas e a experiência do usuário final, tanto em redes internas quanto na camada de transporte que sustenta as consultas.

Se sua equipe ainda trata DNS como caixa preta e precisa de uma visão integrada com o resto da operação de rede, vale conversar com quem já implantou esse modelo em ambientes complexos. Fale com um especialista da OpServices e veja como integrar o monitoramento de DNS ao seu projeto de tráfego de rede.