DNSSEC e Registos de Protecção: O que Ter na Zona DNS do Domínio

O domínio é a identidade da organização na Internet: quem o controla controla o email, o site e a confiança que clientes depositam em ambos. Uma zona DNS mal protegida permite a terceiros redireccionar tráfego por envenenamento de cache, enviar email a fazer passar pela marca ou emitir certificados TLS em nome do domínio. A defesa divide-se em dois planos complementares: o DNSSEC assina a zona para impedir respostas falsificadas, e um conjunto de registos de política (SPF, DKIM, DMARC, CAA e afins) restringe o que terceiros podem fazer em nome do domínio. Este artigo mostra os registos a ter, como activar o DNSSEC sem partir a resolução, e como verificar cada camada com ferramentas de diagnóstico.

Neste artigo

• A Cadeia de Confiança do DNSSEC
• Os Registos que o DNSSEC Cria na Zona
• Passo 1 — Activar o DNSSEC na Zona
• Passo 2 — Publicar o DS no Registrador
• SPF: Quem Pode Enviar Email em Nome do Domínio
• DKIM: Assinatura Criptográfica das Mensagens
• DMARC: a Política que Diz o que Fazer com as Falhas
• CAA: Quem Pode Emitir Certificados TLS
• Outros Registos de Protecção Recomendados
• Como Verificar Tudo com dig e PowerShell
• Como Evitar Problemas

A Cadeia de Confiança do DNSSEC

O DNS original (RFC 1035) não autentica respostas: um resolver aceita o que o servidor lhe devolve, e um atacante que intercepte ou falsifique a resposta consegue redireccionar o tráfego do domínio. O DNSSEC (RFC 4034/4035) fecha este vector com assinatura criptográfica: cada conjunto de registos da zona (RRset) é assinado, e a chave pública que valida as assinaturas está publicada na própria zona.

A confiança forma uma cadeia: a chave da zona (KSK) é validada pelo registo DS publicado no TLD (.pt, .com), que por sua vez é assinado pelo TLD, cuja chave é validada pela raiz do DNS — cuja chave raiz actual (KSK-2017, key tag 20326) está publicada como trust anchor pela IANA. Um resolver com validação activa (Unbound, BIND com dnssec-validation, systemd-resolved, Google/Cloudflare públicos) percorre a cadeia e rejeita qualquer resposta cuja assinatura não valide ou cuja cadeia esteja partida (bogus). A cadeia de confiança não é estática: a raiz está em processo de rotação de chave. A chave raiz actual é a KSK-2017 (key tag 20326, a assinar desde Outubro de 2018), mas a sucessora KSK-2024 (key tag 38696, publicada na zona raiz em Janeiro de 2025) começa a assinar a zona a 11 de Outubro de 2026, no segundo rollover da história da raiz (IANA). Resolvers com actualização automática de trust anchors (RFC 5011) já aparam a nova chave — quem opera um validador on-premise (BIND, Unbound, Knot) deve confirmar nos ficheiros de confiança (bind.keys, root.key) que o key tag 38696 está presente antes dessa data: um validador sem a nova trust anchor deixa de validar a partir da rotação.

O que o DNSSEC garante: autenticidade e integridade das respostas — quem consulta tem a certeza de que o registo vem do dono da zona e não foi alterado no caminho. O que não garante: disponibilidade (uma zona assinada mal configurada fica indisponível para quem valida) nem confidencialidade (as consultas continuam visíveis — para isso serve DoH/DoT).

Os Registos que o DNSSEC Cria na Zona

Activar o DNSSEC acrescenta quatro tipos de registo à zona:

Dois detalhes que importam na operação: a assinatura das zonas tem de ser renovada antes de expirar (signatures com TTL e validade — quem assina on-premise com BIND precisa de re-signing automático) e o rollover de chaves (troca periódica da KSK/ZSK) exige coordenação entre a zona e o DS do TLD — o método documentado (RFC 6781) é duplo-KSK: publicar a nova chave, esperar o TTL, trocar o DS, remover a antiga.

Passo 1 — Activar o DNSSEC na Zona

Em fornecedores geridos (Cloudflare, OVH, Gandi e afins), a activação é um clique e o fornecedor trata da assinatura e do rollover: no dashboard, zona → DNSSEC → Enable. O fornecedor passa a publicar DNSKEY e RRSIG automaticamente e mostra o DS record para publicar no registrador.

Em BIND on-premise, o fluxo manual (resumido):

1. Gera os pares de chaves: dnssec-keygen -a RSASHA256 -f KSK omeudominio.pt (KSK) e dnssec-keygen -a RSASHA256 omeudominio.pt (ZSK).
2. Activa a assinatura automática na zona (auto-dnssec maintain; inline-signing yes; em versões modernas) e inclui as chaves.
3. O BIND assina os RRsets e mantém as assinaturas renovadas.

Passo 2 — Publicar o DS no Registrador

O DS é o elo que liga a zona ao TLD: sem ele, a cadeia de confiança parte no registrador e nada valida. No painel do registrador (cada um tem secção própria — OVH, Gandi, Namecheap e a lista na doc da Cloudflare), publica o DS que o fornecedor DNS gerou: key tag, algoritmo (8 = RSASHA256, 13 = ECDSAP256SHA256), digest type e digest.

Em .pt, o processo é suportado directamente pelo dns.pt e o ecossistema já amadureceu: o contador público da dns.pt mostra mais de 18.800 domínios .pt com DNSSEC activo (valor de 4 de Setembro de 2026, o contador é diário). Confirma a propagação com dig DS omeudominio.pt @a.dns.pt — quando o DS aparece, o DNSSEC está activo de ponta a ponta.

A verificação final: dig omeudominio.pt DNSKEY +dnssec deve devolver o DNSKEY com o RRSIG associado, e delv @8.8.8.8 omeudominio.pt (ou dig +sigchase em resolvers que suportem) valida a cadeia completa sem erros.

SPF: Quem Pode Enviar Email em Nome do Domínio

O SPF (RFC 7208) publica no TXT da zona a lista de servidores autorizados a enviar email do domínio. Quem recebe consulta o registo e rejeita (ou marca) mensagens de IPs fora da lista — a base do combate ao spoofing directo:

Regras de operação: um único registo SPF por domínio (dois dá PermError). include: para cada serviço legítimo (Microsoft 365, Google Workspace, Mailchimp e afins têm os seus include). Terminar com -all (hard fail) quando a lista está completa — ~all (soft fail) durante a fase de recolha de logs. Limite prático de 10 lookups DNS por consulta SPF: exceder dá PermError e invalida o registo — em domínios com muitos serviços, elimina includes redundantes ou usa flatten com cuidado (o valor achatado fica desactualizado quando o fornecedor muda IPs).

DKIM: Assinatura Criptográfica das Mensagens

O DKIM assina as mensagens enviadas com uma chave privada do servidor de email. A chave pública fica na zona num registo TXT no selector:

Cada serviço de envio tem o seu selector (Microsoft 365 publica selector1 e selector2, o Google usa google._domainkey, as newsletters têm os seus). A assinatura cobre cabeçalhos e corpo — alterações em trânsito quebram a validação. O DKIM complementa o SPF onde este falha: o SPF valida o caminho (IP de envio), o DKIM valida o conteúdo (a mensagem não foi alterada e a chave é do domínio). Ambos assinam o mesmo domínio em serviços bem configurados.

DMARC: a Política que Diz o que Fazer com as Falhas

O DMARC (RFC 7489) liga o SPF e o DKIM ao domínio visível no cabeçalho From e define a política quando ambos falham — mais os relatórios que dizem quem está a enviar em nome do domínio:

A política evolui em três passos documentados: p=none (monitorizar, com relatórios rua a chegar), depois p=quarantine (falhas para spam), depois p=reject (falhas rejeitadas). Alinhamento adkim=s/aspf=s (strict) exige que o SPF/DKIM valide exactamente o domínio From — o modo por omissão (relaxed) aceita subdomínios. A Meta, Google e Yahoo exigem DMARC com política activa para remetentes em volume desde 2024: quem envia newsletter sem DMARC p=quarantine ou superior arrisca rejeição directa.

CAA: Quem Pode Emitir Certificados TLS

O registo CAA (RFC 8659) restringe as autoridades de certificação autorizadas a emitir certificados para o domínio — desde Setembro de 2017 que os CAs são obrigados a respeitar o registo:

issue autoriza a CA para certificados normais. issuewild restringe certificados wildcard (por omissão, sem issuewild, o issue aplica-se a todos). iodef define o canal de reporte quando um CA recebe um pedido fora da política. Nota prática: sem registo CAA, qualquer CA pode emitir. Com CAA, um pedido de CA não listada é bloqueado e reportado. Em domínios que usam vários CAs (ex.: Let’s Encrypt para o site e DigiCert para dispositivos), publica uma linha issue por CA.

Outros Registos de Protecção Recomendados

• Null MX (RFC 7505) — se o domínio não recebe email, publica omeudominio.pt. IN MX 0 . para declarar explicitamente a não-recepção e evitar que spammers tentem. Complementa com SPF v=spf1 -all (nenhum servidor envia) e DMARC p=reject.
• Registos de verificação de serviços — Microsoft (ms=msXXXXXXX), Google (google-site-verification=...), Meta e outros publicam TXT para provar posse do domínio. São benignos, mas valem revisão periódica: um TXT de verificação de um serviço abandonado é uma porta aberta se a conta desse serviço for comprometida.
• Registos MX limpos — aponta apenas aos servidores de email reais. MX duplicados apontados a serviços antigos são vector de confusão em routing de email.
• TTLs de registos críticos — TTL baixo (300s) em A/AAAA/MX durante mudanças planeadas evita janelas longas de propagação. TTL alto (3600s+) em produção estável reduz consultas.
• Wildcard CNAME (⚠ revisar) — um *.omeudominio.pt genérico com DNSSEC activo exige NSEC3 (o NSEC permite zone walking — enumerar todos os nomes da zona). Sem NSEC3, evita wildcards em zonas que queiram esconder a estrutura interna.

Como Verificar Tudo com dig e PowerShell

Em Linux e macOS, a verificação completa com dig:

O equivalente nativo em Windows é o cmdlet Resolve-DnsName, disponível no Windows 10/11 e Windows Server sem módulos extra:

Duas notas sobre o cmdlet: o parâmetro -DnssecOk pede registos DNSSEC ao resolver (o bit DO no EDNS) e é o que revela RRSIG e DNSKEY na resposta, e o -Server força um resolver específico — a comparação entre um resolver interno e o público é a forma rápida de detectar envenenamento de cache ou respostas divergentes.

Testes externos que valem a execução: o Mail Tester para a cadeia de email, o DNSViz para a visualização gráfica da cadeia DNSSEC (incluindo erros de assinatura expirada), e os relatórios DMARC (rua) para ver quem envia sem autorização.

Como Evitar Problemas

• DS publicado mas zona não assinada (ou o inverso) — domínio inteiro inacessível para resolvers validantes. O erro mais grave e mais comum: nunca publishes DS sem a zona assinada e activa. Diagnóstico: DNSViz mostra a quebra exacta na cadeia.
• Assinaturas expiradas — zonas assinadas on-premise com BIND sem re-signing automático ficam bogus quando os RRSIG expiram. Em fornecimento gerido não acontece. Em BIND, confirma inline-signing e monitoriza dig +dnssec para validade futura.
• Dois registos SPF — PermError, validação falha. Um único TXT SPF por domínio, com merge de includes num registo só.
• DMARC com p=reject logo à partida — rejeita email legítimo de serviços que ainda não publicam SPF/DKIM alinhado. Passa por p=none com relatórios antes.
• CAA que bloqueia o CA em uso — se publicas CAA com um CA e depois mudas de fornecedor de certificados, a emissão nova falha. Actualiza o CAA antes de mudar de CA.
• DNSSEC activado no fornecedor antigo durante migração — valida só contra o antigo e parte a resolução com os novos nameservers. Desactiva primeiro, migra, reactiva.
• Zone walking com NSEC — se a privacidade dos nomes internos importa, usa NSEC3 (ou evita nomes sensíveis na zona pública).

Artigos Relacionados

• Dia 8: DNS em Profundidade — Zonas, Forward/Reverse, DNSSEC e Caching — os fundamentos de DNS e a cadeia de resolução que o DNSSEC assina
• SPF, DKIM e DMARC: Autenticação de Email em Produção — o aprofundamento da triologia de email deste artigo
• DNS: Guia Completo para Sysadmins — Registos, Zonas e Troubleshooting — a referência geral de registos e diagnóstico
• nslookup e dig: Diagnóstico e Validação de Registos DNS para Sysadmins — as ferramentas que este artigo usa na verificação
• Cloudflare DNS Grátis: O que Inclui e Como Aproveitar o Plano Free — o fornecedor que assina a zona sem custo, com DNSSEC a um clique