DNSSEC

1. O problema — DNS cache poisoning

O protocolo DNS original (RFCs 1034/1035, anos 1980) não possui nenhum mecanismo de autenticação — qualquer resposta que aparente vir do servidor correto é aceita. Isso viabiliza o DNS cache poisoning: um atacante forja uma resposta falsa (ex: "banco.com aponta para o IP do atacante") e, se conseguir injetá‑la no cache de um resolvedor antes da resposta legítima chegar, todos os clientes desse resolvedor são redirecionados para o destino errado, sem nenhum aviso visual. A vulnerabilidade foi tornada pública de forma contundente por Dan Kaminsky em 2008, o que acelerou a adoção do DNSSEC. O DNSSEC resolve isso adicionando assinatura criptográfica a cada resposta, permitindo ao resolvedor verificar a autenticidade e integridade da resposta.

2. Novos registros — RRSIG, DNSKEY, DS, NSEC/NSEC3

O DNSSEC introduz quatro novos tipos de registro (RFC 4034):

3. KSK, ZSK e algoritmos

3.1 Por que duas chaves?

A separação resolve um problema operacional: a KSK (Key Signing Key) assina apenas o conjunto DNSKEY e é referenciada pelo DS no domínio pai — sua troca exige coordenação com o registrador (ex.: registro.br). A ZSK (Zone Signing Key) assina todos os outros registros da zona e pode ser trocada com mais frequência sem envolver o registrador, pois quem confia nela é a própria KSK, dentro da mesma zona. Essa divisão permite rollover ágil da chave operacional, mantendo estabilidade na chave que "fala com o mundo externo".

3.2 Algoritmos recomendados

O registro.br aceita atualmente algoritmos 8 (RSASHA256) e 13 (ECDSAP256SHA256). Escolha ECDSA para novas implantações.

4. NSEC e NSEC3 — prova de inexistência

Tão importante quanto provar que um registro existe é provar que ele não existe. O NSEC (Next SECure) faz isso listando o próximo nome existente na zona, criando um intervalo — mas isso permite zone walking (percorrer toda a zona obtendo os nomes válidos). O NSEC3 (RFC 5155) resolve isso com hash dos nomes e um salt, impedindo a enumeração trivial. Além disso, o NSEC3 oferece o modo Opt‑Out, que permite não assinar delegações não‑DNSSEC, reduzindo o tamanho da zona em TLDs grandes como o .br.

5. Cadeia de confiança

Qualquer elo quebrado (DS desatualizado, chave expirada, assinatura inválida) faz com que resolvedores validadores retornem SERVFAIL para o domínio.

6. Brasil — referência mundial em adoção

O domínio .br é um dos ccTLDs mais antigos do mundo (desde 1989), administrado pelo registro.br (CGI.br/NIC.br). O Brasil é consistentemente citado como um dos países com maior taxa de adoção de DNSSEC em domínios de segundo nível — a infraestrutura do próprio .br é totalmente assinada e o registro.br oferece suporte completo, incluindo tutoriais detalhados e ferramentas para envio de DS. Para um ISP brasileiro, habilitar DNSSEC em um domínio sob .br é significativamente mais simples do que em TLDs sem esse nível de documentação e suporte local.

7. Operação — assinatura, rollover e registro.br

7.1 Fluxo de ativação

1. Gerar KSK e ZSK no servidor autoritativo (BIND, PowerDNS).
2. Assinar a zona (gerar RRSIG para cada RRset).
3. Calcular o registro DS a partir da KSK (hash SHA‑256 da chave pública).
4. Enviar o DS ao registro.br (painel web ou API).
5. Aguardar a propagação antes de considerar a cadeia "fechada" (TTL do DS no .br).

7.2 Rollover — troca de chaves sem derrubar o domínio

Chaves DNSSEC têm prazo de validade e devem ser trocadas periodicamente. O rollover deve respeitar os TTLs para evitar que resolvedores fiquem com chaves órfãs:

• ZSK rollover — trocar a cada 6‑12 meses. Pode ser feito de forma automática (pré‑publicação: publicar a nova ZSK ao lado da antiga, esperar o TTL, depois remover a antiga).
• KSK rollover — trocar a cada 2‑5 anos. Exige atualização do DS no registrador. O método recomendado é Double‑DS: publicar o novo DS enquanto o antigo ainda está ativo, esperar TTL, depois remover o antigo.
• Algoritmo rollover — trocar o algoritmo (ex.: RSA → ECDSA). Requer planejamento cuidadoso, pois resolvedores antigos podem não suportar o novo algoritmo.

8. Validação no resolvedor

Assinar sua zona só protege os clientes que usam um resolvedor validador. O Unbound é o resolvedor validador mais comum — por padrão, com auto‑trust‑anchor‑file, ele já valida DNSSEC para qualquer domínio. Você pode verificar a validação com:

dig +dnssec exemplo-isp.com.br @::1   # consulta com flag DNSSEC
# Resposta inclui RRSIG e flag "ad" (authenticated data) se validou

9. DANE — DNSSEC aplicado a TLS

O DANE (DNS‑based Authentication of Named Entities), definido na RFC 6698, usa registros TLSA para vincular um certificado TLS ao domínio via DNSSEC. Em vez de confiar em todas as Autoridades Certificadoras (CA) do mundo, o proprietário do domínio publica qual certificado (ou CA) é válido para seu serviço.

Para ISPs, isso é especialmente relevante em servidores de e‑mail (SMTP com DANE) e portais de autoatendimento — elimina a dependência de CAs externas e mitiga ataques de certificados fraudulentos.

10. O que o DNSSEC NÃO resolve

• Não criptografa a consulta — a pergunta e a resposta trafegam em texto claro. Criptografia de transporte é papel do DNS‑over‑TLS (DoT) / DNS‑over‑HTTPS (DoH).
• Não garante a "boa índole" do destino — DNSSEC prova que a resposta é autêntica, não que o conteúdo hospedado no IP é confiável.
• Não protege contra typosquatting — um domínio parecido registrado por golpista com DNSSEC ativo seria tão "autêntico" quanto o original.
• Não impede DDoS — assinar uma zona não reduz ataques volumétricos contra o servidor autoritativo.

11. Monitoramento e expiração

RRSIGs têm prazo de validade — sem re‑assinatura periódica automatizada, a zona para de validar quando a última assinatura expira, mesmo que nenhum registro tenha mudado. Ferramentas como dnssec‑verify (BIND) e o serviço DNSViz (dnsviz.net) ajudam a monitorar. Script de check de expiração para Zabbix/PRTG:

#!/bin/bash
# check_dnssec_expiry.sh
DOMINIO="exemplo-isp.com.br"
EXPIRA=$(dig +dnssec +short SOA $DOMINIO @localhost | head -1)
# Simplificado: verificar RRSIG mais próximo de vencer
dnssec-verify -o $DOMINIO /var/cache/bind/db.$DOMINIO.signed
if [ $? -eq 0 ]; then
  echo "OK: DNSSEC válido"
  exit 0
else
  echo "CRITICAL: falha na validação DNSSEC"
  exit 2
fi

12. Troubleshooting

13. Glossário

14. Referências

• RFC 4033, 4034, 4035 — DNSSEC core (introdução, registros, validação).
• RFC 5155 — NSEC3 (prova de inexistência com hash).
• RFC 6698 — DANE (TLSA records).
• RFC 8624 — Algoritmo Implementation Requirements (recomendação de algoritmos).
• registro.br / CGI.br / NIC.br — documentação oficial e infraestrutura DNSSEC do .br.
• DNSViz (dnsviz.net) — ferramenta de visualização da cadeia DNSSEC.
• Páginas relacionadas: BIND9, PowerDNS, Unbound.

Conteúdo técnico independente. Nenhum trecho é cópia literal de fonte de terceiro.