DNS Desde os Primeiros Princípios

Nota: Este é um conteúdo de exemplo criado para demonstrar o blog. Substitua pelo seu próprio texto.

Durante boa parte da minha carreira tratei o DNS como a maioria dos engenheiros trata: como uma caixa preta que "simplesmente funciona" até o momento em que deixa de funcionar. Foi só quando precisei depurar uma configuração split-horizon na rede de um cliente que eu realmente diminuí o ritmo e li as RFCs relevantes. Este post é a explicação que eu gostaria de ter lido antes — curta, fundamentada e focada no que importa para quem trabalha com segurança.

O Problema Que o DNS Resolve#

O Domain Name System é, na essência, um banco de dados distribuído e eventualmente consistente que mapeia nomes legíveis para humanos em dados utilizáveis por máquinas. O mapeamento mais famoso é nome → endereço IP, mas o sistema carrega muito mais do que isso (servidores de e-mail, delegações de servidores de nomes, registros de texto, dicas de descoberta de serviços, provas criptográficas).

Duas pressões de design moldam tudo no DNS:

1. O espaço de nomes é enorme e muda o tempo todo. Nenhum servidor único daria conta.
2. Consultas acontecem no caminho crítico de quase toda conexão. Latência importa.

O resultado é um sistema hierárquico e fortemente armazenado em cache, no qual a autoridade é delegada de cima para baixo a partir da raiz, e cada participante tem permissão para lembrar por um tempo do que aprendeu.

O Fluxo de Resolução#

Quando você digita https://example.com no navegador, a parte que importa para o DNS é example.com. Antes de qualquer handshake TLS, antes de qualquer conexão TCP, o navegador precisa de um endereço IP. Esse é o caminho que a requisição costuma percorrer.

O Stub Resolver#

Sua aplicação não fala DNS diretamente. Ela repassa o nome para um stub resolver dentro do sistema operacional (getaddrinfo da glibc, resolver da musl, a API getaddrinfo do Win32). O stub resolver lê /etc/resolver.conf ou a configuração de rede do sistema para encontrar um resolvedor recursivo — normalmente o anunciado via DHCP, ou um definido manualmente, como 1.1.1.1 ou 8.8.8.8.

O Resolvedor Recursivo#

O resolvedor recursivo (também chamado de caching resolver ou recursor) é a parte que realmente percorre a árvore. Se já tem a resposta em cache, devolve imediatamente. Caso contrário, executa uma consulta iterativa começando pela raiz:

1. Pergunta a um servidor da raiz: "onde fica .com?"
2. Pergunta a um servidor de TLD .com: "onde fica example.com?"
3. Pergunta ao servidor autoritativo de example.com: "qual é o endereço de example.com?"

Cada passo devolve uma referência — um apontamento para o próximo servidor mais próximo da resposta — em vez da resposta em si. O recursor armazena em cache cada referência e cada resposta, com um TTL.

Servidores Autoritativos#

Servidores autoritativos são a fonte da verdade para uma zona. Eles não fazem recursão; respondem a partir dos próprios dados ou recusam. Uma única zona costuma ser servida por vários servidores autoritativos, por redundância, e em setups modernos eles ficam escondidos atrás de serviços como Cloudflare, Route 53 ou NS1.

Um atalho mental útil: o resolvedor recursivo faz perguntas em nome dos clientes; o servidor autoritativo responde perguntas sobre zonas que ele possui. Um mesmo software (BIND, Unbound, Knot) consegue fazer ambos os papéis, mas em produção quase sempre são implantados como funções separadas.

Tipos de Registro#

Registros DNS são tipados. O tipo informa que tipo de dado o registro carrega. Estes são os que mais uso no dia a dia:

Tipo	Finalidade	Exemplo
A	Endereço IPv4 para um nome	93.184.216.34
AAAA	Endereço IPv6 para um nome	2606:2800:220:1:248:1893:25c8:1946
CNAME	Nome canônico — um apelido para outro nome	www.example.com → example.com
MX	Mail exchanger (com prioridade)	10 mail.example.com
TXT	Texto arbitrário (SPF, DKIM, verificação de domínio)	"v=spf1 -all"
NS	Servidores autoritativos de uma zona	a.iana-servers.net
SOA	Start of authority — metadados da zona	serial, refresh, retry, expire, minimum
PTR	Busca reversa — IP → nome	34.216.184.93.in-addr.arpa → example.com

CNAME merece uma nota: um nome com um registro CNAME não pode ter nenhum outro tipo de registro. É por isso que, sob a leitura estrita das RFCs originais, não dá para colocar um CNAME no ápice de uma zona (o example.com puro) — embora provedores ofereçam "flattening" ou pseudo-registros ALIAS/ANAME para contornar isso.

Consultando o DNS Você Mesmo#

dig é a ferramenta que eu pego primeiro quando algo parece estranho. É verboso, previsível e vem na maioria dos sistemas macOS / Linux. Algumas receitas que uso toda semana:

# Consulta padrão de registro A no resolvedor do sistema.
dig example.com

# Consulta um resolvedor específico (aqui: o 1.1.1.1 da Cloudflare).
dig @1.1.1.1 example.com

# Apenas a resposta curta — ótimo para scripts.
dig +short example.com AAAA

# Segue a cadeia de delegação manualmente. Mostra cada
# referência da raiz até a resposta autoritativa.
dig +trace example.com

# Puxa registros TXT — útil para verificar SPF / DKIM.
dig +short TXT example.com

Uma resposta típica de +short é só o dado:

$ dig +short example.com
93.184.216.34

Uma resposta completa do dig inclui o cabeçalho, a seção de pergunta, a resposta, autoridade e registros adicionais, além de uma linha de status. Preste atenção a status: NOERROR versus status: NXDOMAIN — o primeiro significa "o nome existe, aqui está a resposta (ou a ausência dela)"; o segundo significa "o nome não existe em nenhuma parte sob a autoridade desta zona".

Considerações de Segurança#

O DNS foi projetado em um mundo onde a rede era assumida como cooperativa de forma ampla. Essa premissa não se sustenta há décadas, e a história de segurança do DNS é, em grande parte, a história de retrofitar autenticidade e confidencialidade em um protocolo que originalmente não tinha nenhuma das duas.

Spoofing de DNS e Envenenamento de Cache#

Um ataque de spoofing ocorre quando um atacante engana a vítima para que ela aceite uma resposta DNS forjada. O clássico ataque de Kaminsky (2008) demonstrou como um atacante off-path poderia envenenar o cache de um resolvedor recursivo disputando respostas forjadas contra legítimas, explorando a previsibilidade dos IDs de transação e das portas de origem. Resolvedores modernos randomizam ambos, o que eleva o custo, mas não elimina o problema de fundo.

A correção estrutural é o DNSSEC (RFC 9364), que assina registros criptograficamente, de modo que o resolvedor possa verificar que a resposta veio genuinamente do operador da zona e não foi adulterada no caminho. A adoção do DNSSEC é desigual — muitos TLDs suportam, muitas zonas individuais não — mas vale entender porque a cadeia de confiança (raiz → TLD → zona) é um exemplo limpo de como fazer assinatura hierárquica.

DoH e DoT#

Mesmo com DNSSEC, o DNS puro não é criptografado. Qualquer um no caminho entre você e o seu resolvedor consegue ver quais nomes você está consultando. Dois protocolos tratam disso:

• DNS-over-TLS (DoT) (RFC 7858) roda DNS sobre TLS na porta 853.
• DNS-over-HTTPS (DoH) (RFC 8484) roda DNS sobre HTTPS, tipicamente na porta 443.

DoT é a escolha mais limpa para configuração no nível do sistema — porta dedicada, fácil de filtrar, fácil de monitorar. DoH é a melhor escolha quando você precisa que o DNS se pareça com tráfego web comum para atravessar uma rede restritiva, e é por isso que navegadores o adotam como padrão para a própria resolução interna.

Nem DoT nem DoH autenticam o conteúdo da resposta — eles autenticam o transporte. Para o conteúdo você ainda precisa do DNSSEC. Os dois são complementares, não substitutos.

Um Checklist Prático de Hardening#

Quando audito a postura de DNS de uma rede, as perguntas que percorro são mais ou menos:

1. Os resolvedores recursivos em uso suportam validação DNSSEC, e ela está habilitada?
2. Os stub resolvers estão usando DoT ou DoH onde a rede permite?
3. As zonas autoritativas estão assinadas com DNSSEC, e o registro DS está publicado no pai?
4. Há registros TXT de SPF, DKIM e DMARC presentes e alinhados para domínios que enviam e-mail?
5. Existem registros PTR para os servidores de e-mail de saída? (Muitos destinatários rejeitam e-mail sem um.)
6. Os TTLs estão razoáveis? TTLs muito longos tornam mudanças de emergência dolorosas; muito curtos transformam o DNS em um plano de controle oculto.

Notas Finais#

DNS é um daqueles sistemas em que os fundamentos — hierarquia, delegação, cache, TTLs — explicam quase tudo o que você vai encontrar na prática. Quando isso faz sentido, depurar comportamentos estranhos de resolução deixa de ser "estou chutando" e passa a ser "estou seguindo a cadeia". As extensões de segurança (DNSSEC, DoT, DoH) fazem muito mais sentido quando você consegue separar integridade do transporte de autenticidade dos dados de confidencialidade no fio.

Para se aprofundar, as referências canônicas são a RFC 1034 e a RFC 1035 para o protocolo original, o conjunto de RFCs de DNSSEC para assinatura, e a documentação do PowerDNS para uma visão operacional bem escrita vinda de uma stack real autoritativa + recursiva.