Resolução de DNS, do Início ao Fim

Toda vez que você digita um domínio no navegador, uma série de buscas acontece antes de um único pacote chegar ao site que você quer. A maior parte dessa série é invisível, e a maioria das explicações sobre ela para no "é como uma agenda telefônica." Aqui está o que realmente acontece, passo a passo, incluindo as partes que as pessoas geralmente pulam.

O stub resolver não é inteligente

Seu sistema operacional não faz resolução de DNS de verdade por si só. Ele executa um stub resolver, um pequeno pedaço de código que apenas encaminha sua consulta para qualquer servidor DNS configurado em /etc/resolv.conf no Linux ou nas configurações do seu adaptador de rede no Windows. Verifique o seu com:

cat /etc/resolv.conf

Esse arquivo geralmente aponta para seu roteador (como 192.168.1.1), o resolver do seu ISP, ou um público como 1.1.1.1 ou 8.8.8.8. O stub resolver não tem lógica de cache própria além do que o sistema operacional ou um daemon local como systemd-resolved fornece.

O resolver recursivo faz o trabalho real

Uma vez que sua consulta chega a um resolver recursivo, esse servidor assume o trabalho de encontrar a resposta, mesmo que tenha de perguntar a múltiplos outros servidores para chegar lá. Se a resposta já está em cache de uma busca anterior, você a recebe imediatamente. Verifique o TTL com:

dig example.com

Olhe para ANSWER SECTION — o número antes do tipo de registro (como 300 antes de A) é o TTL em segundos. É quanto tempo resolvers são permitidos armazenar o registro em cache antes de perguntar novamente.

Se nada está em cache, o resolver recursivo começa uma travessia pela hierarquia de DNS a partir da raiz.

Servidores raiz, TLD e autoritativos

Existem 13 endereços de servidores raiz (a.root-servers.net até m.root-servers.net), cada um apoiado por muitas máquinas físicas através de roteamento anycast. O servidor raiz não sabe onde example.com fica, mas sabe quais servidores lidam com .com, então ele retorna um encaminhamento.

O resolver então pergunta a um servidor TLD .com, que novamente não sabe a resposta final mas conhece quais nameservers são autoritativos para example.com especificamente. Você pode ver essa delegação você mesmo:

dig +trace example.com

Esse comando mostra cada salto: raiz, depois TLD, depois os nameservers autoritativos do domínio, terminando com o registro A ou AAAA real. É o melhor comando único para entender DNS visualmente em vez de teoricamente.

O nameserver autoritativo é a parada final. É o servidor que o dono do domínio realmente configurou, frequentemente através de um painel DNS de registrador ou um serviço como Route 53 ou Cloudflare DNS. Este é o único servidor em toda a cadeia que tem a resposta real e canônica em vez de uma cópia em cache ou um encaminhamento.

Tipos de registro que você realmente vai encontrar

Um registro A mapeia um nome para um endereço IPv4, AAAA faz o mesmo para IPv6. CNAME aponta um nome para outro nome em vez de um IP, que é como CDNs como Cloudflare ou Fastly roteiam tráfego sem expor IPs brutos. Registros MX lidam com roteamento de mail, e registros TXT carregam texto arbitrário, mais comumente usado agora para SPF, DKIM e strings de verificação de domínio. Registros NS dizem ao mundo quais servidores são autoritativos para uma zona, e esse é o tipo de registro que torna a delegação possível em primeiro lugar.

Onde o cache realmente fica

Armazenamento em cache acontece em múltiplas camadas simultaneamente: o navegador em si (Chrome tem seu próprio cache de DNS visível em chrome://net-internals/#dns), o cache do resolver do sistema operacional, o roteador local, e o resolver recursivo a montante. É por isso que uma mudança de DNS pode parecer funcionar instantaneamente em um dispositivo e levar horas para aparecer em outro — você não está acessando o mesmo cache.

Quando você abaixa o TTL de um registro antes de uma migração planejada, você não está acelerando nada imediatamente. Você está apenas encolhendo a janela durante a qual dados antigos podem persistir uma vez que a mudança realmente acontece. Faça isso pelo menos um ciclo de TTL antes, não cinco minutos antes da transição.

Por que isso importa para troubleshooting

Quando um site é inacessível, dig +trace diz exatamente qual camada está quebrada: um problema de raiz/TLD parece completamente diferente de um servidor autoritativo mal configurado ou um cache antigo na sua própria máquina. Comparar dig example.com contra um resolver conhecido como bom, como dig example.com @1.1.1.1, isola se o problema é seu resolver local ou a configuração real de DNS do domínio.

DNS parece simples de fora porque geralmente se resolve em menos de 100ms e ninguém pensa sobre isso. Por baixo, é um sistema de consulta distribuído, em cache e hierárquico que está rodando praticamente inalterado em estrutura desde os anos 1980, o que é um argumento bem interessante para o quão bem o design original se manteve.

Se você quer ir mais longe com isso, Korra Studio tem segmentos relacionados no DEFENSE_GRID cobrindo extensões de segurança de DNS, tunelamento de DNS como técnica de exfiltração, e construir seu próprio resolver do zero em Python.