Dia 8: DNS em Profundidade — Zonas, Forward/Reverse, DNSSEC e Caching

O DNS (Domain Name System) é a espinha dorsal da Internet moderna. Sem ele, em vez de escrever kbase.pt no navegador, teríamos de memorizar endereços IP como 192.168.1.100 para cada site. Neste oitavo dia do curso de redes, exploramos o DNS em profundidade — desde a hierarquia global até à configuração prática de zonas, DNSSEC e caching.

Neste artigo

ℹ O DNS traduz nomes em endereços IP. Sem DNS, a Internet não funciona — cada pedido web, email ou API começa com uma resolução DNS.

⚠️ Uma configuração DNS incorrecta pode deixar serviços inacessíveis durante horas — o TTL define quanto tempo os resolvers guardam em cache registos errados.

1. Introdução ao DNS

O Domain Name System é uma base de dados distribuída e hierárquica que traduz nomes de domínio legíveis por humanos (como exemplo.pt) em endereços IP legíveis por máquinas (como 93.184.216.34). Foi desenhado em 1983 e formalizado no RFC 1035, substituindo o antigo ficheiro HOSTS.TXT que o SRI mantinha manualmente.

Antes de cada ligação HTTP, envio de email ou chamada VoIP, ocorre pelo menos uma consulta DNS. Em sistemas Linux, o resolver stub (normalmente systemd-resolved ou glibc) envia o pedido a um servidor DNS configurado, que por sua vez contacta outros servidores até obter a resposta. Esta hierarquia é o que torna o DNS escalável a mil milhões de dispositivos.

Existem três actores principais numa resolução DNS: o cliente (stub resolver), o resolver recursivo (faz o trabalho pesado de navegar a hierarquia) e o servidor autoritativo (detém a resposta oficial). Na prática, quando escrevemos um URL, o nosso sistema confia no resolver recursivo do ISP, do Google (8.8.8.8) ou do Cloudflare (1.1.1.1) para encontrar a resposta.

O DNS usa o protocolo UDP na porta 53 para consultas normais (rápidas, sem conexão), e TCP na porta 53 para transferências de zona e respostas maiores que 512 bytes. Com o DNS-over-TLS (DoT, porta 853) e DNS-over-HTTPS (DoH, porta 443), a consulta pode ser cifrada para privacidade.

2. Hierarquia e Tipos de Servidores

O espaço de nomes DNS é uma árvore invertida. No topo estão os 13 grupos de root servers (A a M), geridos pela ICANN. Logo abaixo estão os TLD (Top-Level Domains) — .pt, .com, .org. Cada TLD é gerido por um registo (a .PT, Nominet, Verisign). Abaixo dos TLDs estão os domínios de segundo nível — kbase.pt, example.com — e opcionalmente subdomínios.

Tipo de Servidor Função Exemplo
Root Server Aponta para os servidores dos TLDs a.root-servers.net
TLD Authoritative Autoritativo do TLD (.pt, .com) a.gtld-servers.net
Authoritative Autoritativo do domínio — tem a resposta oficial ns1.kbase.pt
Recursive Resolver Faz a consulta iterativa pelo cliente 8.8.8.8, 1.1.1.1
Stub Resolver No cliente — envia ao recursivo systemd-resolved

Uma consulta DNS completa funciona assim: o stub resolver envia o pedido ao recursivo. Se o recursivo não tem a resposta em cache, pergunta a um root server, que devolve a referência ao TLD. O recursivo pergunta ao TLD, que devolve a referência ao servidor autoritativo do domínio. O recursivo pergunta ao autoritativo, recebe a resposta final e entrega ao cliente.

O dig +trace mostra este caminho completo, do root até ao registo final. É a ferramenta ideal para diagnosticar problemas de delegação. Neste curso já vimos fundamentos de rede no Dia 1 e comandos de rede no Linux no Dia 8 do curso Linux.

3. Zonas e Registos DNS

Uma zona DNS é uma porção do espaço de nomes que um servidor autoritativo gere. O ficheiro de zona contém os registos (registos de recursos) que definem o mapeamento. Existem dois tipos principais: forward zone, que traduz nomes em IPs (exemplo.pt → 192.168.1.10), e reverse zone, que traduz IPs em nomes (192.168.1.10 → exemplo.pt) usando o domínio especial in-addr.arpa.

Cada zona começa com o registo SOA (Start of Authority), que define o servidor primário, o contacto, número de série e temporizadores de sincronização. Os registos NS indicam os servidores autoritativos. A seguir vêm os registos individuais.

Tipo Nome Função
A Address IPv4 do nome
AAAA IPv6 Address IPv6 do nome
CNAME Canonical Name Alias para outro nome
MX Mail Exchange Servidor de email do domínio
TXT Text SPF, DKIM, verificação de domínio
SRV Service Localiza serviços (SIP, LDAP, XMPP)
NS Name Server Servidores autoritativos da zona
SOA Start of Authority Metadados da zona

O registo MX tem uma prioridade — valores mais baixos indicam servidores preferenciais. Por exemplo, 10 mail1.exemplo.pt e 20 mail2.exemplo.pt — o mail1 é tentado primeiro. O TXT tornou-se essencial para segurança: SPF define quais IPs podem enviar email pelo domínio, e DKIM publica a chave pública para verificação de assinaturas.

O registo SRV é usado por serviços que precisam de descobrir dinamicamente o servidor. O Active Directory usa SRV extensivamente para localizar controladores de domínio — o formato é _ldap._tcp.domínio.com com prioridade, peso, porta e alvo.

4. Configurar um Servidor DNS (BIND/Unbound)

O BIND (Berkeley Internet Name Domain) é o servidor DNS autoritativo mais usado em sistemas Unix. O Unbound é um resolver recursivo moderno, focado em validação DNSSEC e performance. Num ambiente típico, pode-se ter BIND como autoritativo e Unbound como recursivo para clientes internos.

No BIND, as zonas são definidas no ficheiro named.conf.local. A zona forward declara o domínio e aponta para o ficheiro de zona. A zona reverse usa o domínio in-addr.arpa com o IP invertido — para a rede 192.168.1.0/24, a zona é 1.168.192.in-addr.arpa.

# BIND — zona forward
zone "exemplo.pt" IN {
    type master;
    file "/etc/bind/zones/exemplo.pt";
};
# BIND — zona reverse
zone "1.168.192.in-addr.arpa" IN {
    type master;
    file "/etc/bind/zones/192.168.1.rev";
};

O ficheiro de zona forward contém os registos. O SOA define o servidor primário e o email do administrador (com ponto em vez de @). O número de série deve ser incrementado a cada alteração — os secundários usam-no para saber se precisam de sincronizar (transferência de zona AXFR).

$ORIGIN exemplo.pt.
$TTL 3600
@   IN  SOA ns1.exemplo.pt. admin.exemplo.pt. (
        2026080901 ; serial
        3600       ; refresh
        1800       ; retry
        604800     ; expire
        86400      ; minimum TTL
    )
@       IN  NS      ns1.exemplo.pt.
@       IN  NS      ns2.exemplo.pt.
@       IN  MX  10  mail.exemplo.pt.
@       IN  A       192.168.1.10
www     IN  CNAME   exemplo.pt.
mail    IN  A       192.168.1.20
ns1     IN  A       192.168.1.53
ns2     IN  A       192.168.1.54

O ficheiro de zona reverse mapeia IPs a nomes. O último octeto do IP torna-se no nome do registo PTR — 192.168.1.10 corresponde a 10 IN PTR exemplo.pt.. O reverse DNS é crucial para email — muitos servidores rejeitam mensagens cujo IP não tem PTR válido.

$ORIGIN 1.168.192.in-addr.arpa.
$TTL 3600
@   IN  SOA ns1.exemplo.pt. admin.exemplo.pt. (
        2026080901 ; serial
        3600       ; refresh
        1800       ; retry
        604800     ; expire
        86400      ; minimum TTL
    )
@     IN  NS   ns1.exemplo.pt.
@     IN  NS   ns2.exemplo.pt.
10    IN  PTR  exemplo.pt.
20    IN  PTR  mail.exemplo.pt.
53    IN  PTR  ns1.exemplo.pt.
54    IN  PTR  ns2.exemplo.pt.

O Unbound, por outro lado, configura-se em /etc/unbound/unbound.conf. Define as interfaces de escuta, as redes autorizadas a consultar, e opcionalmente zonas locais (local-zone) para resolver nomes internos sem expor ao público. O Unbound valida DNSSEC por defeito.

# Unbound — /etc/unbound/unbound.conf
server:
    interface: 127.0.0.1
    interface: 192.168.1.53
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.1.0/24 allow
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    local-zone: "intern.exemplo.pt." static
    local-data: "host1.intern.exemplo.pt. IN A 192.168.1.100"
    local-data: "host2.intern.exemplo.pt. IN A 192.168.1.101"

Para testar se o servidor DNS está a responder correctamente, usamos nslookup, host e dig apontando para o servidor local.

# Testar servidor DNS
nslookup kbase.pt 127.0.0.1
host -t MX kbase.pt

5. DNSSEC — Assinatura Criptográfica

O DNS original não tem autenticidade — qualquer servidor pode injectar respostas falsas (DNS spoofing ou cache poisoning). O DNSSEC, formalizado no RFC 4033, adiciona assinaturas criptográficas aos registos, permitindo que o resolver verifique que a resposta veio realmente do servidor autoritativo e não foi modificada em trânsito.

O DNSSEC não cifra o conteúdo — as respostas continuam legíveis. O que faz é assinar cada conjunto de registos com chaves privadas e publicar as chaves públicas na própria zona. O validador percorre a cadeia de confiança desde a root key até ao domínio, verificando assinaturas em cada nível.

Existem quatro tipos de registos DNSSEC: DNSKEY (chave pública), RRSIG (assinatura dos registos), DS (Delegation Signer — liga o domínio ao progenitor) e NSEC/NSEC3 (prova de não-existência). A cadeia de confiança começa na root zone, que é assinada pela ICANN. Cada TLD publica o registo DS dos seus domínios, e cada domínio publica as suas DNSKEY.

Registo Função
DNSKEY Chave pública do domínio
RRSIG Assinatura criptográfica dos registos
DS Hash da DNSKEY — liga à zona progenitora
NSEC / NSEC3 Prova que um nome não existe

Para activar DNSSEC no BIND, usa-se dnssec-keygen para gerar as chaves KSK (Key Signing Key) e ZSK (Zone Signing Key). A KSK assina a DNSKEY; a ZSK assina os restantes registos. Depois de assinada a zona, o registo DS tem de ser enviado ao registo do TLD (a .PT para domínios .pt). Sem o DS no progenitor, a cadeia de confiança está partida e o DNSSEC não valida.

Para verificar se um domínio tem DNSSEC activo e a validar, usamos dig +dnssec. O flag ad (Authentic Data) na resposta indica que o resolver validou a cadeia com sucesso.

# Verificar DNSSEC
dig +dnssec kbase.pt
dig +trace kbase.pt

O dig +trace segue a resolução desde a root. Se o domínio tiver DNSSEC, veremos os registos DS e DNSKEY em cada nível. É a forma mais completa de auditar a cadeia de confiança de um domínio.

6. Colocação em Cache e Desempenho

A colocação em cache é o que torna o DNS rápido. Sem cache, cada visita a um site exigiria uma viagem completa à root, TLD e autoritativo — centenas de milissegundos. O TTL (Time To Live) em cada registo diz aos resolvers durante quanto tempo podem manter a resposta em cache antes de a considerar obsoleta.

O TTL é um compromisso entre performance e flexibilidade. TTL alto (86400s = 24h) reduz carga e acelera resolução, mas torna mudanças lentas — se mudar o IP, alguns clientes continuarão a aceder ao IP antigo durante horas. TTL baixo (300s = 5min) permite mudanças rápidas, ideal para migrações, mas aumenta a carga no autoritativo. A prática comum é reduzir o TTL 24-48h antes de uma mudança prevista, e restaurar depois.

TTL Cenário Impacto
60s — 300s Migração iminente, failover Mudança rápida, mais carga
3600s (1h) Equilíbrio geral Bom compromisso
86400s (24h) Domínio estável Máxima cache, mudanças lentas

O split-horizon DNS é uma técnica onde o mesmo domínio resolve para IPs diferentes conforme a origem da consulta. Uma empresa pode ter intranet.empresa.pt a resolver para um IP interno quando consultado da LAN, e para um IP público quando consultado da Internet. Isto permite expor serviços internos sem os tornar públicos.

No BIND, o split-horizon configura-se com view — declara-se uma vista “interna” com match-clients para a rede local, e outra “externa” para o resto. Cada vista tem o seu ficheiro de zona com registos diferentes. No Unbound, usa-se local-zone para resolver nomes internos.

Para diagnosticar problemas de caching, o dig mostra o TTL restante na resposta. Se o TTL descer rapidamente, o cache está a expirar. O dig +trace ajuda a perceber onde a resolução para. No Dia 24 deste curso abordaremos DNS avançado em profundidade.

7. Erros Comuns e Lista de Verificação

Os problemas de DNS são dos mais frustrantes porque os efeitos surgem horas depois, quando o cache propaga o erro. Aqui estão os mais comuns e como os evitar.

Erro Causa Solução
Domínio não resolve NS mal delegado ou zona não carregada Verificar NS com dig NS
Email rejeitado Reverse DNS (PTR) ausente Configurar zona reverse no ISP
Mudança não propaga TTL alto — cache antigo Reduzir TTL antes de mudar
DNSSEC falha DS não publicado no TLD Enviar DS ao registo do TLD
Serial não incrementa Esquecer de actualizar SOA Usar formato data+rev (AAAAMMDDnn)

Um erro particularmente insidioso é o ponto final omitido. Em ficheiros de zona BIND, ns1.exemplo.pt (sem ponto) é interpretado como ns1.exemplo.pt.exemplo.pt — o BIND acrescenta o $ORIGIN. Sempre que um nome for absoluto, deve terminar com ponto.

Os comandos abaixo cobrem as verificações essenciais para diagnosticar qualquer problema de DNS.

# Verificar resolução DNS
dig kbase.pt
dig -x 192.168.1.1
dig MX kbase.pt
dig AAAA kbase.pt
# Verificar DNSSEC
dig +dnssec kbase.pt
dig +trace kbase.pt
# Consultar NS autoritativos
dig NS kbase.pt @a.gtld-servers.net

O dig -x faz consulta reverse (PTR), dig MX consulta o registo de email, dig AAAA o IPv6, e dig NS @a.gtld-servers.net consulta directamente os servidores autoritativos do TLD .com, ignorando o cache do recursivo.

✓ Lista de verificação DNS: Serial do SOA incrementado · Pontos finais nos nomes absolutos · NS delegados no registo · PTR configurado no ISP · TTL baixado antes de mudanças · DNSSEC com DS publicado · Split-horizon testado de ambas as redes · named-checkconf e named-checkzone sem erros.

No próximo dia abordaremos o DHCP — o protocolo que atribui automaticamente os IPs que o DNS depois resolve. A integração entre DNS e DHCP (DNS dinâmico ou DDNS) é o que permite que dispositivos recebam nome e endereço automaticamente numa rede.

Artigos relacionados: