Como o DNS funciona: resolução recursiva, cache e TTLs em diagrama

Você muda um registro A, roda dig e vê o endereço novo. Uma colega em outro escritório continua recebendo o antigo uma hora depois. Um subdomínio novo funciona para você e devolve NXDOMAIN para um cliente. Nada disso é aleatório: decorre de como a resolução DNS e o cache funcionam, e quando você consegue desenhar o caminho que uma consulta percorre, consegue prever tudo isso.

Este post acompanha uma consulta do navegador até o servidor autoritativo e de volta, com um diagrama, e depois cobre TTLs, cache negativo, delegação, transporte e os modos de falha que aparecem em produção.

Os quatro papéis em toda consulta

Uma consulta passa por até quatro tipos de servidor. Cada um conhece uma parte diferente da resposta.

A raiz não é uma máquina só. Existem 13 identidades de servidores raiz, de a a m.root-servers.net, operadas por 12 organizações independentes, e o anycast as espalha por mais de 2.000 instâncias no mundo, segundo o root-servers.org em novembro de 2026.

Uma consulta, passo a passo

Digamos que o seu navegador precise de app.example.com e que nada esteja em cache em lugar nenhum:

1. O navegador verifica o próprio cache e depois pergunta ao resolvedor stub do sistema operacional.
2. O stub envia uma consulta com a flag “recursion desired” para o resolvedor recursivo configurado: qual é o registro A de app.example.com?
3. O resolvedor não tem nada em cache, então pergunta a um servidor raiz. A raiz não sabe a resposta, mas sabe quem administra com, então devolve uma referência: os registros NS de com e os endereços deles (glue).
4. O resolvedor pergunta a um servidor TLD de com, que devolve outra referência: os servidores de nomes de example.com.
5. O resolvedor pergunta a um desses servidores autoritativos, que devolve a resposta: app.example.com. 300 IN A 203.0.113.10.
6. O resolvedor guarda em cache cada registro que aprendeu pelo TTL dele e devolve a resposta ao stub, que a repassa ao navegador.

O stub faz uma consulta recursiva: ele quer uma resposta final. O resolvedor faz consultas iterativas: cada servidor devolve ou a resposta ou um ponteiro para alguém mais perto dela. Servidores raiz e TLD nunca vão atrás das respostas por você.

Você pode ver a parte iterativa com dig +trace, que começa na raiz em vez de usar o cache do seu resolvedor (saída resumida):

$ dig +trace app.example.com
.                  518400  IN  NS  a.root-servers.net.
com.               172800  IN  NS  a.gtld-servers.net.
example.com.       172800  IN  NS  ns1.example.net.
app.example.com.   300     IN  A   203.0.113.10

Resolvedores modernos também aplicam a minimização de QNAME (RFC 9156): perguntam à raiz só sobre com e ao TLD só sobre example.com, de modo que os servidores mais acima nunca veem o nome completo que você consultou.

Cache e TTLs

Todo registro carrega um tempo de vida (TTL) em segundos. Um resolvedor que guarda app.example.com em cache com TTL de 300 responde do cache pelos cinco minutos seguintes, em contagem regressiva, e só então pergunta de novo ao servidor autoritativo. Navegadores e sistemas operacionais mantêm os próprios caches curtos por cima disso.

É isso que as pessoas chamam de propagação. Nada é enviado para lugar nenhum quando você muda um registro. Cada resolvedor que guardou o valor antigo continua servindo esse valor até a cópia expirar, então o pior caso é aproximadamente o TTL antigo, e não o novo. Os resolvedores também cortam TTLs muito longos: o Unbound, por exemplo, limita por padrão os registros em cache a um dia.

Regras práticas para mudanças:

• Baixe o TTL antes de uma mudança planejada. Se um registro tem TTL de 86400, mude para 300 pelo menos um dia antes da migração, espere o TTL antigo passar, faça a mudança e depois suba de novo.
• Use TTLs curtos só onde você precisa de failover rápido. Um TTL de 60 segundos significa mais consultas ao seu provedor e mais cache misses para os usuários, cada um custando uma resolução completa.
• Trocar os servidores de nomes é mais lento. Os registros NS de example.com na zona pai têm o próprio TTL, 172800 segundos (dois dias) em com, e você não consegue encurtá-lo.

O failover baseado em DNS depende desses números. O diagrama de arquitetura multirregião da AWS e o diagrama de arquitetura de recuperação de desastres mostram onde entra um registro DNS com health check e por que o TTL dele limita o seu tempo de recuperação.

Cache negativo: a armadilha do NXDOMAIN

Os resolvedores também guardam em cache o “não existe”. Quando um nome não existe, o servidor autoritativo devolve NXDOMAIN junto com o registro SOA da zona, e o resolvedor guarda essa resposta negativa pelo menor valor entre o TTL do SOA e o campo MINIMUM dele (RFC 2308).

A falha clássica: alguém consulta api.example.com antes de o registro existir, um resolvedor guarda NXDOMAIN por uma hora, você cria o registro e esse resolvedor continua dizendo que ele não existe até a hora acabar. Confira o TTL negativo com dig example.com SOA antes de anunciar um hostname novo, e crie os registros antes que alguém os teste.

Delegação, glue e servidores mancos

Uma zona existe no DNS porque a zona pai delega para ela. A zona com guarda registros NS dizendo quais servidores são autoritativos para example.com. Se esses servidores de nomes ficam dentro da zona que atendem, como ns1.example.com, a zona pai também guarda os endereços deles como registros glue; caso contrário, os resolvedores não conseguiriam encontrá-los.

A delegação quebra de duas formas comuns. Uma delegação manca (lame delegation) é uma zona pai apontando para um servidor que não atende mais a zona, muitas vezes depois de uma troca de provedor, e ela causa timeouts ou SERVFAIL para alguns usuários. Uma divergência entre os registros NS da zona pai e os da própria zona faz o comportamento depender de qual conjunto um resolvedor guardou em cache.

Transporte e privacidade

A maior parte do tráfego DNS é UDP na porta 53. Respostas que não cabem ligam a flag de truncamento, e o cliente tenta de novo por TCP, então a porta TCP 53 também precisa estar aberta. Desde o DNS Flag Day 2020, os principais softwares de DNS usam por padrão um buffer EDNS de 1.232 bytes para evitar fragmentação IP, o que torna mais comum a volta para TCP em respostas grandes, como registros assinados com DNSSEC.

O DNS clássico não é criptografado. DNS over TLS (porta 853), DNS over HTTPS e DNS over QUIC criptografam o trecho entre o stub e o resolvedor recursivo; os trechos do resolvedor até os servidores raiz, TLD e autoritativos continuam, em sua maioria, em texto puro.

O DNSSEC resolve outro problema: autenticidade, não privacidade. Cada zona assina os próprios registros, e a zona pai garante a chave da zona filha, até chegar à chave raiz em que os resolvedores que validam confiam. Em 11 de outubro de 2026, a zona raiz concluiu a troca para uma nova chave de assinatura de chaves, a KSK-2024. Um resolvedor que valida e que nunca adotou a nova âncora de confiança falha em toda consulta com SERVFAIL.

Quando as consultas falham

Perguntar diretamente ao servidor autoritativo com dig @ns1.example.net app.example.com mostra qual é a verdade; perguntar a um resolvedor mostra o que os usuários veem.

O diagrama de resolução DNS

Como ler:

• Comece pelo notebook. O resolvedor stub dele envia uma consulta recursiva ao resolvedor (passo 1) e recebe uma resposta de volta (passo 8).
• Quem percorre o caminho é o resolvedor. Os passos 2 a 7 são consultas iterativas: a raiz e os servidores de com devolvem referências, e o servidor autoritativo de example.com devolve o registro.
• Os TTLs ficam nas respostas. O registro A volta com TTL de 300 segundos; é por esse tempo que o resolvedor vai reutilizá-lo sem perguntar de novo.
• A moldura agrupa a hierarquia que você não opera, exceto o servidor autoritativo, que é seu ou do seu provedor de DNS.
• O bloco Markdown lista as camadas de cache e os TTLs que decidem a rapidez com que uma mudança chega aos usuários.

Desenhar diagramas de DNS que respondem perguntas reais

• Numere os passos. Perguntas sobre DNS são sobre ordem: quem pergunta a quem e quando o cache responde no lugar.
• Separe o tráfego recursivo do iterativo. Uma consulta do cliente, várias do resolvedor. Se os dois parecerem iguais, o diagrama esconde a ideia mais importante.
• Escreva os TTLs nas respostas. Eles explicam a propagação melhor do que um parágrafo.
• Mostre quem é dono do quê. Marque os servidores que você controla. Durante um incidente, isso decide para quem você liga.
• Desenhe a mudança de registro em um diagrama separado. Uma linha do tempo da migração com o TTL reduzido, a virada e o TTL aumentado de novo é mais clara do que anotações no diagrama de resolução.

Se a ordem das mensagens for o ponto principal, um diagrama de sequência também funciona, com o resolvedor e cada servidor como linhas de vida. Para o lado físico, onde os resolvedores ficam na sua rede, veja o guia do diagrama de topologia de rede.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione um nó Dispositivo do pack Rede para o notebook e um nó DNS para o resolvedor recursivo.
3. Adicione uma Moldura do pack Básico com o nome da hierarquia DNS e coloque dentro dela mais três nós DNS: a raiz, o TLD com e o servidor autoritativo de example.com.
4. Adicione um nó Servidor do pack Rede para app.example.com, o host ao qual o navegador se conecta depois da consulta.
5. Desenhe as arestas em ordem e numere os rótulos: a consulta do cliente e a resposta, depois uma consulta e uma resposta entre o resolvedor e cada servidor. Coloque o TTL na resposta final.
6. Adicione um bloco Markdown do pack Básico com as camadas de cache e as regras de TTL.

O exemplo usa 8 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Quanto tempo leva a propagação do DNS? Até o TTL do registro antigo, em cada resolvedor que o guardou em cache. Nada é enviado; os caches expiram. Trocas de servidores de nomes demoram mais, porque os registros NS da zona pai têm o próprio TTL, dois dias em com.

Qual é a diferença entre um servidor DNS recursivo e um autoritativo? Um resolvedor recursivo encontra respostas em nome dos clientes e as guarda em cache. Um servidor autoritativo guarda os registros de uma zona e responde só por essa zona.

Por que ainda vejo o IP antigo depois de mudar um registro? Um cache entre você e o servidor autoritativo ainda guarda o registro antigo: o seu navegador, o seu sistema operacional ou o seu resolvedor. Consulte o servidor autoritativo diretamente para confirmar a mudança e depois espere o TTL acabar.

Um TTL muito baixo é um problema? Ele custa mais consultas ao seu provedor de DNS e mais resoluções completas para os usuários, o que adiciona latência nos cache misses. Use TTLs baixos em registros que talvez precisem de failover e mais longos em registros estáveis.

O tráfego DNS é criptografado? Não por padrão. DNS over TLS, HTTPS ou QUIC criptografa o trecho entre o seu dispositivo e o resolvedor. O DNSSEC adiciona assinaturas que provam que os registros são autênticos, mas não criptografa nada.

Comece grátis — um assento, sem cartão de crédito.