Como funciona uma consulta DNS

Na última vez que mudei o registro A de um domínio, o site novo apareceu pra mim na hora e ficou no servidor antigo pra metade da equipe por quase um dia inteiro. O suspeito de sempre apareceu no grupo: "deve ser a propagação do DNS". Só que não existe propagação no sentido mágico que as pessoas imaginam. O que aconteceu foi cache expirando em ritmos diferentes em resolvers diferentes, cada um respeitando o TTL que o registro tinha quando foi consultado.

Este artigo destrincha o caminho que uma consulta DNS percorre, do seu navegador até o servidor authoritative que tem a resposta, e por que o cache em cada camada explica quase tudo que parece misterioso.

O problema: um nome não serve pra rede

Quando você digita example.com, o navegador não faz a menor ideia de pra onde mandar os pacotes. A rede TCP/IP roteia por IP, não por nome. Então antes de qualquer requisição HTTP acontecer, alguém precisa traduzir o nome num endereço IP. Esse alguém é a cadeia de resolução DNS, e ela é mais movimentada do que parece.

A tradução termina sempre na mesma coisa: um IP (ou vários). É só isso que o DNS te devolve no fim. Tudo no meio existe pra descobrir esse IP de forma confiável sem que o mundo inteiro tenha que perguntar pro mesmo servidor central.

A cadeia de resolução, passo a passo

O caminho tem cinco atores principais. Vale conhecer cada um porque, quando algo dá errado, o problema mora em um deles.

Stub resolver é o cliente mínimo dentro do seu sistema operacional. Ele não sabe resolver nada sozinho; só sabe perguntar pra um resolver maior e aceitar a resposta. É o que está por trás das funções tipo getaddrinfo.

Recursive resolver é o cavalo de batalha. Normalmente é o do seu provedor, ou um público tipo 8.8.8.8 / 1.1.1.1. Ele assume a responsabilidade de ir atrás da resposta inteira por você, batendo nos servidores certos um por um. Por isso a consulta que você manda pra ele é chamada de recursive query: você pede a resposta final, completa, e ele que se vire.

Root servers são o topo da hierarquia. Eles não sabem o IP de example.com, mas sabem quem cuida de .com. Existem 13 endereços de root (de A a M), espalhados em centenas de instâncias via anycast.

TLD servers cuidam de cada top-level domain: .com, .org, .br, e por aí vai. O servidor de .com também não sabe o IP de example.com, mas sabe quais são os servidores authoritative daquele domínio.

Authoritative server é quem tem a verdade. É o servidor que hospeda a zona de example.com e devolve, finalmente, o registro A com o IP.

Recursive vs iterative: quem faz o trabalho pesado

Aqui está a parte que confunde muita gente. A consulta entre o stub e o recursive resolver é recursive: "me devolve a resposta pronta". Mas as consultas que o recursive resolver faz pra root, TLD e authoritative são iterative: cada um responde "eu não sei, mas pergunta pra fulano".

O fluxo, na prática, é mais ou menos assim:

1. Stub pergunta ao recursive resolver: qual o A de example.com?
2. Resolver pergunta ao root: cadê o .com? Root responde com os servidores de .com.
3. Resolver pergunta ao TLD .com: cadê o example.com? TLD responde com os authoritative do domínio.
4. Resolver pergunta ao authoritative: qual o A de example.com? Authoritative responde com o IP.
5. Resolver guarda a resposta em cache e devolve pro stub.

Dá pra ver essa cadeia inteira com um comando só:

dig example.com +trace

O +trace faz o dig simular o trabalho do recursive resolver, mostrando cada salto: root, depois TLD, depois authoritative. É a forma mais didática de ver a hierarquia funcionando ao vivo.

Pra uma consulta normal, sem o teatro todo, basta:

dig example.com A

E no Windows, ou quando você só quer uma resposta rápida:

nslookup example.com

Cache em toda camada: onde a "propagação" mora

Aqui está o ponto que desmonta o mito. Cada ator da cadeia guarda respostas em cache pelo tempo definido no TTL (time to live) do registro. Se example.com tem TTL de 3600, o recursive resolver guarda aquele IP por uma hora e nem cogita perguntar de novo nesse período.

Quando você muda um registro, o authoritative já tem o valor novo na hora. Mas os resolvers do mundo inteiro continuam servindo o valor velho até o TTL deles expirar. Como cada resolver consultou o registro num momento diferente, eles expiram em momentos diferentes. O resultado: parte das pessoas vê o novo, parte vê o antigo, e isso dura mais ou menos o tempo do TTL.

Isso não é propagação. Nada está se espalhando ativamente pela rede. É cache expirando. A diferença importa porque muda completamente o que você pode fazer a respeito.

A camada de cache não para no resolver. O seu próprio sistema operacional tem cache, o navegador tem cache, e até o stub resolver pode manter respostas. Por isso você, que limpou o cache local, vê o site novo, enquanto o colega que não limpou continua no antigo.

A opinião: baixe o TTL antes de migrar

Se "propagação" é na verdade cache expirando, a solução é óbvia e quase ninguém faz: reduza o TTL com antecedência. Uns dois ou três dias antes de uma migração planejada, baixe o TTL do registro pra algo curto, tipo 300 segundos. Espere o TTL antigo expirar (se ele era 86400, espere um dia). A partir daí, todo resolver vai estar segurando o registro por apenas 5 minutos.

Quando você fizer a troca de verdade, a janela de inconsistência cai de horas pra minutos. Depois que tudo estabilizar, volte o TTL pra um valor saudável pra aliviar a carga nos resolvers. Atrasos de "propagação" são quase sempre TTL alto que ninguém se lembrou de baixar antes. Não é magia, é planejamento.

O que o resolver devolve, e como conferir o destino

No fim da cadeia, o que volta pra você é um IP. Vale a pena olhar esse IP com atenção, porque ele confirma pra onde o domínio realmente aponta, independente do que o painel do registrador diz. Uma consulta DNS termina num endereço, e inspecionar o IP resultante ajuda a confirmar o destino: você pode jogar esse endereço numa ferramenta de informações de IP pra ver a quem ele pertence e onde fica hospedado.

Se você quer entender melhor o que cada tipo de registro faz (A, AAAA, CNAME, MX e companhia), o caminho é o artigo irmão sobre tipos de registros DNS, que entra no detalhe que aqui ficou de fora.

UDP, TCP e os transportes modernos

Por padrão, o DNS roda sobre UDP na porta 53. UDP é rápido e sem cerimônia: manda a pergunta, recebe a resposta, acabou. Funciona bem porque a maioria das respostas cabe num único pacote. Quando a resposta é grande demais (DNSSEC, muitos registros), o resolver cai pra TCP, que aguenta respostas maiores às custas de um handshake.

Mais recentemente surgiram DoH (DNS over HTTPS) e DoT (DNS over TLS). Os dois resolvem o mesmo problema: a consulta DNS tradicional viaja em texto puro, então qualquer um no caminho vê quais domínios você está acessando. DoH empacota a consulta dentro de HTTPS (porta 443, indistinguível de tráfego web normal) e DoT usa uma conexão TLS dedicada na porta 853. Pra resolução em si, nada muda: a cadeia root, TLD, authoritative continua igual. Só o trecho entre você e o recursive resolver fica criptografado.

Perguntas frequentes

Quanto tempo leva a "propagação" do DNS?

O tempo equivale ao maior TTL que estava ativo no momento da mudança. Se o registro tinha TTL de 86400 (um dia), alguns resolvers podem servir o valor antigo por até 24 horas. Não dá pra forçar o mundo a esquecer mais rápido; por isso a jogada é baixar o TTL antes de mexer.

Por que o site novo abre pra mim mas não pro meu colega?

Cache local. O seu sistema, navegador ou resolver já expirou e buscou o valor novo, enquanto o do seu colega ainda está dentro da janela de TTL. Limpar o cache de DNS da máquina (ou usar outro resolver temporariamente) costuma resolver pro lado de quem testa.

Qual a diferença entre recursive resolver e authoritative server?

O recursive resolver vai atrás da resposta pra você, perguntando pros servidores certos e guardando em cache. O authoritative server é o dono da verdade daquela zona: ele não pergunta pra ninguém, só responde com os dados que você configurou. Um busca, o outro responde em definitivo.

Mudar o servidor de DNS do meu PC acelera a navegação?

Às vezes. Um recursive resolver mais rápido ou mais perto de você responde mais cedo nas consultas que ainda não estão em cache. Mas, uma vez que o registro está cacheado, o ganho some. O efeito é mais perceptível em quem visita muitos domínios diferentes do que em quem fica nos mesmos sites o dia todo.

Pra levar pra casa

Uma consulta DNS é uma cadeia: stub resolver pergunta ao recursive resolver, que itera por root, TLD e authoritative até achar o IP, e cacheia tudo no caminho respeitando o TTL. O que chamam de "propagação" é só esse cache expirando em ritmos diferentes. Sabendo disso, a única preparação que importa antes de uma migração é baixar o TTL com antecedência. Faça isso e os tais atrasos misteriosos viram uma janela de minutos previsível, não uma loteria de um dia inteiro.