Você digita google.com no navegador e a página abre em menos de um segundo. Parece simples. Não é.
Antes do primeiro byte de HTML chegar no seu navegador, acontece uma cadeia de consultas entre servidores espalhados pelo mundo. O nome do processo é resolução DNS. É invisível, é rápido, e cai na prova do CCNA.
O problema que o DNS resolve
Computadores se comunicam por endereços IP. google.com não é um endereço IP. É um nome criado para humanos, porque ninguém memoriza 142.250.219.142.
DNS é o sistema que traduz nomes em endereços. Sem ele, você precisaria saber o IP de cada site que quisesse acessar. A internet como existe hoje não funcionaria.
O caminho completo: do cache ao servidor autoritativo
Quando você digita google.com, o seu sistema percorre até cinco etapas antes de ter o IP. A maioria das consultas para na segunda ou terceira.
Etapa 1: cache local
O navegador verifica se já resolveu esse nome recentemente. Se tiver o IP em cache e o TTL (Time to Live) não tiver expirado, usa esse valor e encerra o processo ali. Sem consultar nenhum servidor externo.
Se não estiver no cache do navegador, o sistema operacional verifica o cache próprio. Windows, Linux e macOS mantêm um cache de DNS separado do navegador.
Etapa 2: resolver recursivo
Sem cache local, a consulta vai para o resolver recursivo. Esse é o servidor DNS configurado no seu dispositivo. Pode ser o da operadora, o 8.8.8.8 do Google ou o 1.1.1.1 da Cloudflare.
O resolver é quem faz o trabalho pesado. Ele recebe sua pergunta, sai consultando outros servidores, e te devolve a resposta final. Você pergunta uma vez, ele resolve tudo.
Se o resolver já tiver o IP em cache, responde na hora. Caso contrário, começa a consulta iterativa.
Etapa 3: root nameservers
O resolver pergunta a um root nameserver: "quem sabe sobre .com?"
Existem 13 conjuntos de root nameservers no mundo, identificados de A a M. Eles não sabem o IP de google.com. Mas sabem quem cuida do domínio .com. Devolvem uma referência para os servidores TLD de .com.
Etapa 4: servidor TLD
O resolver pergunta ao servidor TLD de .com: "quem é o autoritativo de google.com?"
O servidor TLD também não sabe o IP. Mas sabe quem tem essa informação. Devolve o endereço do servidor autoritativo de google.com.
Etapa 5: servidor autoritativo
O resolver pergunta ao servidor autoritativo: "qual é o IP de google.com?"
Esse servidor tem a resposta definitiva. Ele armazena os registros DNS do domínio, incluindo o registro A com o endereço IPv4. Devolve 142.250.219.142 para o resolver, que repassa para o seu navegador.
O navegador finalmente abre a conexão TCP com esse IP. A página começa a carregar.
O TTL: por que o cache tem prazo de validade
Cada resposta DNS vem com um TTL em segundos. É o tempo que o resolver pode guardar aquela resposta em cache antes de precisar consultar novamente.
$ nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 142.250.219.142
TTL curto significa que mudanças no DNS propagam rápido. TTL longo significa menos carga nos servidores, mas propagação mais lenta. Quando uma empresa troca de provedor de hospedagem, geralmente reduz o TTL antes da migração para minimizar o tempo com o IP antigo sendo resolvido.
Detalhes que caem na prova
DNS usa UDP na porta 53 para a maioria das consultas. Rápido, sem handshake. Se a resposta for grande demais para UDP, o protocolo muda para TCP na porta 53 automaticamente.
Transferência de zona entre servidores DNS primário e secundário usa TCP 53 também.
▌ Note que: a porta 53 cai em questões de firewall e ACL. Bloquear UDP 53 derruba a resolução DNS da rede inteira.
O que dá errado e como você diagnostica
Usuário reclama que não acessa um site mas outros funcionam. Primeiro teste:
C:\> nslookup packetpass.com.br
Server: 192.168.1.1
Address: 192.168.1.1#53
*** Can't find packetpass.com.br: No response from server
O resolver local (192.168.1.1) não respondeu. Pode ser o gateway sem DNS configurado, firewall bloqueando porta 53, ou o servidor DNS da operadora fora do ar. Troque para 8.8.8.8 e teste de novo. Se resolver, o problema é no DNS local.
C:\> nslookup packetpass.com.br 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Name: packetpass.com.br
Address: 185.220.101.45
Resolveu com o DNS externo. Problema confirmado no servidor local.
DNS parece mágica porque é invisível. Não tem mistério. É uma hierarquia de servidores com papéis bem definidos e cache em cada camada.