DNSSEC (DNS Security Extensions)

1. Definição e Motivação

O DNSSEC (DNS Security Extensions) é um conjunto de extensões ao DNS que adiciona assinaturas digitais aos registros, permitindo que resolvedores verifiquem a autenticidade e integridade das respostas. Sem DNSSEC, o DNS é vulnerável a envenenamento de cache (cache poisoning) e ataques man-in-the-middle: qualquer atacante que consiga interceptar uma resposta DNS pode forjar dados e redirecionar tráfego.

O DNSSEC foi especificado nas RFCs 4033, 4034 e 4035 (2005), com atualizações posteriores (RFCs 5155, 6840, 8078, 8901). Ele não criptografa o tráfego DNS — para isso existe DoT (DNS over TLS, RFC 7858) e DoH (DNS over HTTPS, RFC 8484). DNSSEC é sobre autenticidade e integridade, não confidencialidade.

O que o DNSSEC previne

• Cache poisoning (ex: ataque Kaminsky de 2008, que motivou a adoção acelerada).
• Substituição de registros por atacantes on-path.
• Respostas forjadas que redirecionam usuários para sites falsos.

O que o DNSSEC NÃO previne

• Espionagem do conteúdo consultado (use DoT/DoH/DoQ).
• Ataques DDoS volumétricos (mitigado por anycast e rate limiting).
• Comprometimento do servidor autoritativo (se o atacante tem a chave de assinatura, pode assinar registros falsos válidos).

2. Conceitos Fundamentais

2.1 RRsets (Resource Record Sets)

O DNSSEC assina conjuntos de registros do mesmo tipo + nome, chamados RRsets. Por exemplo, todos os registros A de exemplo.com formam um RRset e são assinados juntos. Não há como assinar individualmente um único registro A.

2.2 Tipos de Registros DNSSEC

Tipo	Função
DNSKEY	Chave pública do domínio (KSK e ZSK)
RRSIG	Assinatura digital de um RRset
DS	Delegation Signer — hash da KSK filha publicado no pai
NSEC	Prova de não-existência de um nome (denial of existence)
NSEC3	NSEC com hashing salgado para evitar zone walking
CDNSKEY / CDS	Sinais para automatizar rolamento de KSK (RFC 8078)

2.3 Chaves KSK e ZSK

Cada zona assinada usa dois pares de chaves:

• KSK (Key Signing Key): assina apenas o RRset DNSKEY da própria zona. É a chave de longo prazo e âncora de confiança.
• ZSK (Zone Signing Key): assina todos os demais RRsets (A, AAAA, MX, etc.). É rotacionada com mais frequência (típico: a cada 3-12 meses) por estar mais exposta.

Essa separação equilibra segurança e desempenho: a KSK fica offline (em HSM ou armazenamento seguro) e apenas assina o conjunto DNSKEY periodicamente; a ZSK fica online e assina registros comuns.

3. Cadeia de Confiança (Chain of Trust)

A validação DNSSEC é hierárquica. A confiança parte da root trust anchor (chave pública da KSK raiz, configurada no resolvedor validador) e desce pela cadeia:

Root (trust anchor) → TLD (.com, .br) → domínio (exemplo.com.br)

Como funciona a validação

1. O resolvedor recebe uma resposta para www.exemplo.com.br A.
2. Junto com o registro A, recebe um RRSIG(A) — a assinatura.
3. Para validar, precisa da ZSK de exemplo.com.br, que está no RRset DNSKEY da própria zona, assinado pela KSK.
4. Para validar a KSK, busca o registro DS em .br, que é o hash da KSK filho. Se coincidir, a KSK é confiável.
5. O RRset DS de .br é assinado pela ZSK de .br, que é validada pela KSK de .br.
6. A KSK de .br é validada pelo DS na raiz, assinado pela KSK raiz.
7. A KSK raiz é a trust anchor — confiável por configuração local.

Trust Anchor da Raiz

A KSK da raiz é publicada no formato de arquivo de trust anchor e atualizada em todos os resolvedores validadores. A primeira troca de KSK (KSK rollover) ocorreu em 2018, após 8 anos de operação.

# /etc/unbound/root.key (exemplo, formato abreviado)
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

4. NSEC e NSEC3: Prova de Não-Existência

NSEC

Quando você consulta um nome que não existe, o DNS clássico simplesmente retorna NXDOMAIN sem prova. Com DNSSEC, o servidor autoritativo retorna um NSEC que cobre o intervalo onde o nome estaria, provando que aquele nome não existe.

Por exemplo, em uma zona com a.example, m.example, z.example:

• Consulta por b.example → retorna NSEC a.example → m.example, provando que não há nomes entre a e m.

Problema: NSEC permite zone walking — um atacante pode consultar nomes sintéticos e enumerar todos os registros da zona.

NSEC3

NSEC3 aplica um hash saltado (SHA-1 com salt) aos nomes antes de ordená-los. Em vez de a.example → m.example, o servidor retorna hashes. Zone walking ainda é tecnicamente possível (dicionário de hashes), mas significativamente mais custoso.

Característica	NSEC	NSEC3
Zone walking	Trivial	Difícil (dicionário)
CPU no servidor	Mínima	Maior (SHA-1 por nome)
Tamanho da resposta	Menor	Maior
Adotado em	Maioria das zonas novas	Zonas sensíveis

5. RRSIG: Estrutura da Assinatura

www.exemplo.com. 3600 IN RRSIG A 8 3 3600 20250131235959 20250101000000 12345 exemplo.com.
base64-da-assinatura...

Campos:
- A — tipo coberto.
- 8 — algoritmo (8 = RSASHA256; 13 = ECDSAP256SHA256; 15 = ED25519).
- 3 — número de labels no nome.
- 3600 — TTL original (deve ser preservado).
- Timestamps — validade da assinatura.
- 12345 — key tag da chave que assinou.
- exemplo.com. — signatário.

Algoritmos Suportados

Código	Algoritmo	Status
5	RSASHA1	Obsoleto (RFC 8624)
7	RSASHA1-NSEC3-SHA1	Obsoleto
8	RSASHA256	Recomendado
10	RSASHA512	Aceito
13	ECDSAP256SHA256	Recomendado (mais leve)
14	ECDSAP384SHA384	Aceito
15	Ed25519	Recomendado (RFC 8080)
16	Ed448	Aceito

Chaves ECDSA e Ed25519 são mais eficientes que RSA para o mesmo nível de segurança, mas RSA ainda é o mais adotado por compatibilidade histórica.

6. Operação e Diagnóstico

Verificar se um domínio está assinado

dig +dnssec www.exemplo.com.br A

# Saída incluirá registros RRSIG e flag "ad" (Authentic Data)
# se a validação for bem-sucedida pelo resolvedor recursivo.

dig +dnssec google.com A +short
# 142.250.74.46
# A 8 3 300 20250131235959 20250101000000 34906 google.com. base64...

A flag ad na resposta (set AD bit) indica que o resolvedor validou a assinatura. Se o bit ad não estiver setado em uma consulta +dnssec, ou o domínio não é assinado, ou a validação falhou.

Validar manualmente a cadeia

# Validar a partir da raiz
dig +dnssec +trace www.exemplo.com.br

# Ferramenta específica para checagem de cadeia
delv @8.8.8.8 www.exemplo.com.br A

# Validadores online:
# https://dnssec-analyzer.verisignlabs.com/
# https://dnsviz.net/

Verificar rolamento de KSK (CDS/CDNSKEY)

dig exemplo.com. CDNSKEY +short
dig exemplo.com. CDS +short
# CDS contém o DS que o operador pai deve publicar.
# Permite automação da atualização do DS na zona pai.

7. Implantação e Adoção

Em zona autoritativa (BIND)

# Gerar chaves KSK e ZSK
dnssec-keygen -a ECDSAP256SHA256 -b 256 -f KSK exemplo.com
dnssec-keygen -a ECDSAP256SHA256 -b 256 exemplo.com

# Assinar a zona
dnssec-signzone -o exemplo.com -k Kexemplo.com.+013+12345.key db.exemplo.com Kexemplo.com.+013+67890.key
# Gera db.exemplo.com.signed

# Configurar BIND para servir a zona assinada
# Em named.conf:
zone "exemplo.com" {
    type master;
    file "db.exemplo.com.signed";
};

Modernamente, ferramentas como ldns-signzone, knotc (Knot DNS) e pdnsutil (PowerDNS) automatizam o processo. Em clouds (Route 53, Cloudflare), DNSSEC é habilitado por um toggle no console.

Em resolvedor recursivo (Unbound)

# /etc/unbound/unbound.conf
auto-trust-anchor-file: "/var/lib/unbound/root.key"
harden-dnssec-stripped: yes
val-clean-additional: yes

# Atualizar trust anchor
unbound-anchor -a /var/lib/unbound/root.key

Adoção Atual (2024)

• Root zone: assinada desde 2010.
• TLDs: ~90% dos TLDs suportam DNSSEC (incluindo .com, .org, .net, .br).
• Domínios individuais: ~35-40% globalmente (variável por TLD; .gov, .bank têm adoção alta).
• Validação recursiva: principais resolvedores públicos (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9) validam por padrão.

8. Armadilhas e Problemas Comuns

Tamanho das Respostas

Respostas DNSSEC são significativamente maiores (RRSIG, DNSKEY, NSEC). Sem EDNS0 (limite 512 bytes), o cliente cairia para TCP frequentemente. Hoje todos os resolvedores suportam EDNS0, mas firewalls mal configurados podem bloquear respostas UDP > 512, quebrando DNSSEC silenciosamente.

Falta de Sincronia de Tempo

As assinaturas têm timestamps de validade. Se o relógio do resolvedor estiver errado (mais de horas), a validação falha. Por isso é essencial rodar NTP em servidores que validam DNSSEC.

Rolamento de Chaves Malfeito

Trocar a KSK sem atualizar o DS na zona pai quebra a cadeia. Em 2017, o Brazilian NIC.br teve um incidente que tirou centenas de milhares de domínios .br do ar por algumas horas por uma falha no rolamento.

NXDOMAIN Flood

Ataques que consultam nomes aleatórios forçam o servidor autoritativo a assinar dinamicamente NSEC3 (ou retornar NSEC pré-calculado). Em NSEC3 com salt aleatório, a CPU do servidor pode saturar.

9. Tabela Resumo

Conceito	Detalhe
RFCs	4033, 4034, 4035
Trust anchor raiz	KSK-2017 (atual)
Tipos de chave	KSK (assina DNSKEY), ZSK (assina dados)
Tipos novos	DNSKEY, RRSIG, DS, NSEC, NSEC3, CDNSKEY, CDS
Algoritmos recomendados	8 (RSA), 13 (ECDSA), 15 (Ed25519)
Prova de não-existência	NSEC (direto) ou NSEC3 (hash saltado)
Não provê	Confidencialidade (use DoT/DoH)

10. Conclusão

O DNSSEC é a infraestrutura que torna o DNS confiável. Sem ele, qualquer roteador comprometido pode forjar respostas e sequestrar sessões de e-mail, web e qualquer serviço que dependa de nomes. Embora a complexidade operacional (rolamento de chaves, cadeia de confiança, sincronia de tempo) tenha desacelerado a adoção histórica, hoje o ecossistema está maduro: TLDs suportam por padrão, clouds habilitam com um clique, e resolvedores validam automaticamente. Para engenheiros, publicar DNSSEC é parte da boa higiene de segurança — tão importante quanto TLS para web ou SPF/DKIM/DMARC para email.