Fundamentos do Protocolo DNS

1. Definição e Contexto

O DNS (Domain Name System) é o sistema distribuído e hierárquico de resolução de nomes da Internet. Sua função é traduzir nomes amigáveis a humanos (ex.: www.exemplo.com.br) em endereços numéricos usados pela rede (IPv4/IPv6). Sem DNS, a Internet moderna seria inutilizável — usuários teriam que memorizar bilhões de endereços IP. O DNS foi definido originalmente em 1983 (RFC 882 e 883), sendo substituído em 1987 pelas RFCs 1034 (conceitos) e 1035 (implementação), que continuam vigentes. É um dos protocolos mais antigos ainda em uso e também um dos mais atacados.

Características Fundamentais

• Modelo: Cliente-servidor distribuído e hierárquico.
• Porta: 53/UDP (consultas) e 53/TCP (transferência de zona e respostas > 512 bytes).
• Caching: Obrigatório em todos os níveis (resolvedor, SO, aplicação).
• TTL: Controla tempo de vida da informação em cache (segundos).
• Escalabilidade: ~360 milhões de domínios registados, trilhões de consultas/dia.

2. Arquitetura Hierárquica

O DNS é organizado como uma árvore invertida com a raiz no topo. Cada nó é um domínio.

                  . (root)
                  │
        ┌─────────┼─────────┐
       com       br        fr
        │         │
      exemplo  exemplo    exemple
        │         │
       www      www

Componentes da Hierarquia

3. Tipos de Servidores DNS

4. Tipos de Registros DNS (Resource Records)

5. Processo de Resolução (Forward Lookup)

Quando um usuário digita www.exemplo.com.br no navegador:

1. Cache local do browser: Verifica cache interno (Chrome mantém por ~60s).
2. SO resolver: Sistema operacional consulta resolver configurado (ex.: 8.8.8.8 ou do ISP).
3. Cache do resolver: Se resolver tem resposta em cache, devolve em ~1ms.
4. Root server: Se não tem cache, pergunta à raiz: "Quem é autoritativo para .br?"
5. TLD .br: Resolvedor pergunta ao .br: "Quem é autoritativo para exemplo.com.br?"
6. Authoritative final: Resolvedor pergunta: "Qual o IP de www.exemplo.com.br?"
7. Resposta: A 203.0.113.10 com TTL 3600s.
8. Cache: Resolver e SO cacheiam pelo TTL; cliente recebe resposta final.

Exemplo de Trace

dig +trace www.exemplo.com.br

# Passo 1: consulta root servers
# Passo 2: referral para .br
# Passo 3: referral para exemplo.com.br
# Passo 4: resposta A final

6. UDP vs TCP

Por padrão, consultas DNS usam UDP na porta 53 (rápido, sem handshake). TCP é usado quando:

• Resposta excede 512 bytes (resposta DNSSEC tipicamente).
• Transferência de zona (AXFR/IXFR).
• UDP truncado (flag TC=1 na resposta; cliente refaz em TCP).

7. Caching e TTL

O caching é o que torna o DNS viável em escala global. Sem cache, cada consulta percorreria toda a hierarquia, e os root servers colapsariam sob carga.

Anatomia do TTL

Decisão de TTL por Cenário

• Site estável: 3600s (1h) — baixa carga na raiz e TLD.
• Migração iminente: 300s (5 min) — permite propagar IP novo em minutos.
• Anti-DDoS (CDN failover): 30-60s — failover rápido entre datacenters.
• Geo-DNS: 60-120s — responde conforme origem do cliente.

8. Resolução Reversa (IP → Nome)

A resolução reversa converte IP em nome de domínio. Usa o domínio especial in-addr.arpa (IPv4) e ip6.arpa (IPv6), com registros PTR.

Exemplo

Para o IP 203.0.113.10, a consulta é 10.113.0.203.in-addr.arpa. IN PTR. O IPv4 é invertido byte a byte. Resolução reversa é usada por:

• Servidores SMTP (anti-spam, verificação HELO).
• Logs de firewall/web (tradução de IP para nome legível).
• Serviços de autenticação (rlogin, NFS, sshd com UseDNS yes).

9. DNSSEC — Cadeia de Confiança

DNSSEC (RFC 4033-4035) adiciona assinaturas criptográficas aos registros, permitindo ao cliente validar autenticidade da resposta. Sem DNSSEC, DNS é vulnerável a cache poisoning (ataque Kaminsky, 2008).

Tipos de Chave

• KSK (Key Signing Key): Assina a ZSK, publicada como DNSKEY.
• ZSK (Zone Signing Key): Assina registros individuais (RRSIG).
• DS (Delegation Signer): Hash da KSK, publicado na zona pai.

Cadeia de Confiança

Root KSK (Trust Anchor configurado no resolvedor)
  └─ DS para .com (assinado pela Root)
      └─ DS para exemplo.com (assinado pela .com)
          └─ RRSIG do registro A (assinado por ZSK do exemplo.com)

Se qualquer passo falhar na validação, a resposta é marcada como SERVFAIL (DNSSEC validation failure).

10. Ferramentas de Diagnóstico

dig www.exemplo.com.br                          # consulta A
dig +short www.exemplo.com.br                    # apenas resposta
dig @8.8.8.8 www.exemplo.com.br                  # servidor específico
dig +trace www.exemplo.com.br                    # trace completo
dig +dnssec www.exemplo.com.br                   # validar DNSSEC
delv www.exemplo.com.br                          # cadeia de confiança
nslookup www.exemplo.com.br                      # legado
host www.exemplo.com.br                          # legado alternativo
dig -x 203.0.113.10                             # reverso

11. Vulnerabilidades e Mitigações

12. Resumo Técnico

13. Conclusão

O DNS é o sistema de nomes que tornou a Internet usável por humanos. Sua arquitetura hierárquica e distribuída, combinada com caching agressivo e o protocolo leve UDP, permite escalar a trilhões de consultas diárias com latência de milissegundos. A evolução para DNSSEC resolveu as principais vulnerabilidades de integridade, mas novos desafios surgiram com o DNS-over-HTTPS (DoH, RFC 8484) e DNS-over-TLS (DoT, RFC 7858), que cifram consultas mas dificultam a visibilidade corporativa. Para administradores e analistas de segurança, dominar DNS é pré-requisito para qualquer tarefa de infraestrutura, desde configurar domínios próprios até investigar vazamentos de dados via DNS tunneling.