O que é DNS? Como nomes de domínio viram endereços IP

DNS (Domain Name System) associa nomes como example.com aos dados que o cliente precisa em seguida, quase sempre um endereço IP. As aplicações pedem um nome, e o DNS devolve registros. DNS não é um servidor web, um navegador nem uma camada de criptografia. Ele responde consultas de nomes e nada mais.

#A versão curta

Quando você digita um nome no navegador, o sistema operacional ou o próprio navegador verifica primeiro o cache local. Se não houver resposta utilizável, o cliente envia uma consulta a um resolvedor recursivo. Esse resolvedor costuma ser mantido pelo seu provedor de internet, pela sua empresa ou por um serviço público, como o 8.8.8.8.

O resolvedor responde do cache quando consegue. Se não consegue, percorre a hierarquia do DNS. Ele pergunta a um servidor raiz quais servidores cuidam do domínio de primeiro nível (como o .com), pergunta a esse servidor quais nameservers o domínio usa e, por fim, pergunta a um desses nameservers autoritativos pelo registro. O servidor autoritativo guarda os dados reais. O resolvedor armazena a resposta pelo tempo que o TTL do registro permitir e depois a devolve ao cliente.

O tráfego real acrescenta outras etapas: cadeias de CNAME, validação DNSSEC, entradas no arquivo hosts local, transportes de DNS criptografados e várias camadas de cache. Depois que o DNS termina, o navegador ainda precisa abrir uma conexão, negociar TLS e esperar a resposta do servidor.

#Registros que você vai encontrar primeiro

#Teste em um domínio que você pode documentar

Use um domínio que você possui ou administra. Se quiser só praticar, example.com é um dos nomes reservados para documentação (RFC 2606). Limite as consultas a nomes que você tem permissão para consultar e não varra hosts que você não tem permissão para testar.

No Linux ou no macOS, com o dig instalado:

dig example.com A
dig example.com AAAA
dig example.com MX

No Windows, o nslookup já vem com o sistema operacional:

nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com

A saída abaixo foi capturada em uma máquina Windows em 8 de novembro de 2026, com nslookup, usando o resolvedor padrão da máquina (dns.google, 8.8.8.8). A resposta veio desse resolvedor, não do servidor autoritativo do domínio. A máquina exibiu os rótulos em português. Aqui eles aparecem em inglês. Os valores são um retrato do momento e vão mudar na sua máquina e em execuções posteriores.

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

Name:    example.com
Addresses:  2606:4700:10::ac42:93f3
	  2606:4700:10::6814:179a
	  172.66.147.243
	  104.20.23.154

O mesmo resolvedor devolveu um registro MX para o domínio:

example.com	MX preference = 0, mail exchanger = (root)

Um mail exchanger (root) significa que o destino é um ponto único. É um MX nulo, que informa aos remetentes que o domínio não aceita e-mail (RFC 7505).

Por fim, uma consulta TXT para o mesmo nome:

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

example.com	text =

	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
example.com	text =

	"v=spf1 -all"

A segunda string é uma política SPF. O -all diz que nenhum servidor está autorizado a enviar e-mail por este domínio, o que combina com o MX nulo acima. A primeira string é um valor opaco; strings assim costumam servir para provar a um serviço que você controla o domínio. Como diz a tabela, um registro TXT mostra o que o dono publicou e não prova mais nada.

Dois detalhes desta execução. A linha Non-authoritative answer confirma que a resposta veio de um resolvedor (do cache ou de uma consulta dele), não do servidor do próprio domínio. E os endereços IPv6 vieram primeiro, mas não vale depender dessa ordem: uma execução posterior pode listá-los de outro jeito ou devolver endereços diferentes.

Para observar o cache, use o dig. Ele imprime um número de TTL antes de cada registro. Repita a mesma consulta dentro da janela do TTL. Se o resolvedor guardou a resposta, o segundo número será menor que o primeiro.

#Cache e por que as respostas mudam

Cada registro tem um TTL, um tempo em segundos que informa aos resolvedores por quanto tempo eles podem guardar a resposta. Um TTL curto permite ao dono mudar um serviço rapidamente, mas também faz mais consultas chegarem aos servidores autoritativos. Um TTL longo reduz a carga, mas significa que respostas antigas podem continuar circulando por algum tempo depois de uma mudança.

Portanto, uma resposta é um retrato do momento. Dois resolvedores podem divergir durante uma mudança, e ambos podem estar corretos para o próprio cache. Quando precisar saber o que o dono publicou, pergunte direto a um nameserver autoritativo, por exemplo com dig example.com A @<nameserver>, usando um servidor dos registros NS do domínio, ou siga a cadeia com dig +trace example.com A.

#DNS, OSINT e segurança

Consultar registros DNS públicos de um domínio é um primeiro passo comum em um inventário de ativos. Uma empresa pode revisar os próprios nomes, os próprios registros de e-mail e os endereços por trás deles. Pesquisadores costumam cruzar esses dados com logs de certificate transparency e informações de propriedade.

Duas coisas não decorrem de uma resposta DNS. Primeiro, um registro que aparece em um resultado de busca não é permissão para varrer o host para onde ele aponta. Segundo, um endereço IP não identifica quem opera a máquina. Provedores de hospedagem, CDNs e servidores compartilhados fazem um mesmo endereço atender muitos sites sem relação entre si.

Um registro suspeito também não é prova de ataque. Configurações erradas, serviços expirados e nomes abandonados são comuns. Verifique a resposta autoritativa, o histórico de alterações e o dono do domínio antes de tirar conclusões. Envenenamento de cache e spoofing são problemas diferentes, com evidências diferentes.

#Erros comuns

• Tratar uma única resposta como definitiva. Verifique o TTL e consulte de novo depois.
• Ler um CNAME como se fosse um endereço IP. Siga o alias até chegar a um registro A ou AAAA.
• Presumir que o resolvedor usado é o servidor autoritativo. A saída mostra qual servidor respondeu.
• Ler um registro TXT como prova de que um controle de segurança funciona.
• Varrer um host só porque o DNS apontou para ele. Consulta e varredura são ações diferentes, com permissões diferentes.

#O que estudar a seguir

O DNS é uma etapa de uma requisição web. Depois, estude como HTTP e TLS tratam o que acontece quando o nome vira endereço, usando as RFCs e a documentação listadas nas fontes. Em seguida, leia o próximo artigo desta trilha, sobre OSINT, antes de fazer qualquer consulta como parte de reconhecimento. Limite sua prática a domínios e sistemas que você possui ou para os quais tem permissão por escrito.