O processo completo de resolução DNS — quantos saltos do navegador ao servidor raiz?

1. O fluxo completo em 8 etapas

┌─────────────────────────────────────────────────────────────┐
│  Navegador (Chrome / Firefox) — digita google.com           │
└────────────────┬────────────────────────────────────────────┘
                 │ ① Cache DNS do navegador (Chrome ~60s)
                 ↓ miss
┌─────────────────────────────────────────────────────────────┐
│  Stub resolver do SO + cache DNS do sistema                 │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Miss no cache do sistema → envia consulta UDP ao roteador
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Encaminhamento DNS + cache do roteador doméstico           │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Miss no cache do roteador → encaminha ao resolvedor recursivo do ISP
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Resolvedor recursivo do ISP / público                      │
│  (1.1.1.1 / 8.8.8.8 / 223.5.5.5)                            │
│  Acerto no cache: responde direto, tudo leva 1-5ms          │
│  Miss no cache: segue o fluxo de "consulta completa" abaixo │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Pergunta ao NS raiz "onde fica google.com?"
                 ↓
        13 clusters de servidores raiz (a~m.root-servers.net)
                 │ ⑤ Responde "não sei, pergunte ao NS de .com: a.gtld-servers.net"
                 ↓
        Servidores autoritativos do TLD .com (Verisign)
                 │ ⑥ Responde "também não tenho tudo, pergunte ao NS de google.com: ns1.google.com"
                 ↓
        Servidores autoritativos de google.com (operados pelo próprio Google)
                 │ ⑦ Responde "registro A de google.com = 142.250.x.x"
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ O resolvedor recursivo guarda a resposta em cache        │
│     (conforme o TTL) e a devolve ao cliente — cada camada   │
│     no caminho também guarda sua própria cópia              │
└─────────────────────────────────────────────────────────────┘

Ponto-chave: em cenários reais, o fluxo completo de 8 etapas quase nunca acontece. Os endereços IP dos grandes sites quase sempre já estão no cache do resolvedor recursivo, então o usuário comum só chega até a etapa ④ antes de receber a resposta. Só domínios pouco conhecidos, sites raramente acessados, TTLs expirados ou domínios recém-registrados disparam o fluxo completo.

2. As 5 camadas de cache DNS explicadas

Quando o DNS foi projetado em 1983, já se levava em conta um fato: as consultas superam as alterações em 100.000 vezes. Por isso há cache em todo lugar, e cada camada guarda os dados por um período de TTL (Time To Live).

3. Consultas recursivas vs. iterativas — conceitos-chave

3.1 Recursiva

O cliente (navegador / stub do SO) diz ao resolvedor recursivo do ISP: "Encontre o IP de google.com para mim — não importa como." O resolvedor recursivo precisa concluir toda a busca e retornar o resultado final.

3.2 Iterativa

Quando o resolvedor recursivo conversa com os servidores raiz, de TLD e autoritativos, essa troca é iterativa — ele pergunta à raiz, a raiz diz "pergunte ao .com", ele vai e pergunta ao .com, o .com diz "pergunte ao google", ele vai e pergunta ao google. Cada etapa avança só um salto — não é o caso de "eu pergunto à raiz e a raiz resolve tudo para mim".

4. Teste você mesmo — dig +trace

dig +trace força uma busca iterativa completa e mostra cada etapa:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Salto 1 — consulta a raiz (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 registros NS raiz)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Salto 2 — consulta o TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (os 4 NS do .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Salto 3 — consulta os servidores autoritativos de cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Por fim, recebe a resposta
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Analisando:

• O processo todo levou 5 + 121 + 53 + 12 = 191 ms — a primeira consulta a frio é mesmo lenta
• Mas consultar o mesmo domínio um segundo depois leva só 1-2 ms, porque o cache recursivo do ISP já tem a resposta (TTL de 300 segundos)
• 104.21.x.x / 172.67.x.x são endereços da CDN da Cloudflare — o IP real de origem do nosso site fica oculto atrás da CDN

5. TTL explicado — quanto tempo o cache dura de fato

TTL (Time To Live) é o campo em que o servidor autoritativo diz a todo resolvedor recursivo "você pode guardar isto em cache por no máximo este tempo", medido em segundos.

Observação: o TTL é o "tempo máximo de cache" — cada resolvedor pode limpar o cache antes, mas nunca estendê-lo. Então, mesmo que o TTL autoritativo seja de 1 hora, alguns resolvedores podem consultar de novo após apenas 10 minutos.

Armadilha: antes de trocar de IP, reduza o TTL primeiro (1-5 minutos) e espere o TTL antigo expirar por completo antes de migrar — caso contrário, alguns usuários continuarão acessando o IP antigo por mais de uma hora.

6. Guia rápido de tipos de registro DNS

7. Otimização de DNS — como deixar a resolução mais rápida

7.1 Escolha um resolvedor recursivo próximo

China continental: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) resolvem sites chineses mais rápido. Fora de lá: 1.1.1.1 (Cloudflare, a maior presença anycast) / 8.8.8.8 (Google). Veja odiretório de resolvedores DNS públicos.

7.2 Ative o DoH (DNS-over-HTTPS)

Criptografar as consultas DNS via HTTPS impede que o ISP as veja ou adultere (bloqueando o sequestro de NXDOMAIN). Chrome, Firefox e Edge oferecem suporte — basta ativar nas configurações.

7.3 Aqueça com antecedência (DNS Prefetch)

Adicione <link rel="dns-prefetch" href="//api.example.com"> ao <head> do seu site para que o navegador resolva o nome enquanto está ocioso — quando a requisição real acontecer, já será um acerto de cache.

7.4 Use CDN + NS anycast

Coloque seu NS autoritativo em anycast (Cloudflare / Route 53) para que usuários do mundo todo cheguem à instância mais próxima — reduzindo a latência da etapa ③ de 100ms para 10ms.

7.5 Defina o TTL com critério

Use TTL longo (1-7 dias) para registros que raramente mudam (NS / MX); use TTL curto (5-60 minutos) para registros A que podem precisar ser trocados.

8. Perguntas frequentes

8.1 Mudei o DNS e nada aconteceu — por quê?

Primeiro, verifique o TTL atual. Depois de alterar o DNS, todos os resolvedores recursivos continuam devolvendo o IP antigo até o TTL antigo expirar. A "propagação global" costuma levar cerca de 2× o TTL (considerando que os resolvedores não estão sincronizados entre si).

• Cliente: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Esperando o cache de um resolvedor recursivo público expirar: 1.1.1.1 / 8.8.8.8 oferecem cada um sua própria ferramenta de "purge" para limpá-lo manualmente

8.2 Alguns usuários conseguem acessar, outros não — poluição de DNS

Comum ao acessar sites estrangeiros a partir da China continental — o GFW injeta respostas DNS falsas / ISPs sequestram consultas. Mudar para DoH (DNS criptografado no navegador) contorna a maior parte da poluição de DNS.

8.3 Quanto tempo depois de registrar um domínio posso usá-lo?

Após o registro, o registro do TLD envia seus registros NS aos servidores autoritativos de nível superior de .com / .net etc. — geralmente de 15 minutos a 24 horas. Domínios .cn / .com.cn podem exigir registro ICP antes de resolverem na China continental.