Entenda a cadeia de confiança DNSSEC em 5 minutos
Por CaptainDNS
Publicado em 22 de fevereiro de 2026
Atualizado em 12 de outubro de 2026
- A cadeia de confiança DNSSEC conecta a raiz DNS ao seu domínio por meio de assinaturas criptográficas encadeadas
- Três tipos de registos garantem a validação: DNSKEY (chaves públicas), RRSIG (assinaturas) e DS (vínculo com a zona pai)
- Cada elo verifica o seguinte: a raiz assina o TLD, o TLD assina o seu domínio
- Desde 11 de outubro de 2026, a KSK 38696 assina a raiz DNS: um resolvedor autogerido que não a tenha nas suas âncoras pode devolver SERVFAIL
- Verifique se a sua cadeia está intacta com o nosso DNSSEC Checker (veja o plano de ação no final)
O DNSSEC não funciona como um certificado TLS que instala em um servidor. É um sistema distribuído. A confiança propaga-se da raiz DNS até o seu domínio, elo por elo. Se um único elo se rompe, toda a cadeia desmorona e os seus visitantes recebem um erro SERVFAIL.
Entender essa cadeia é essencial para ativar o DNSSEC corretamente, diagnosticar erros e evitar interrupções de serviço. Este guia explica cada componente em 5 minutos, com diagramas e exemplos práticos.
Porque o DNS precisa de uma cadeia de confiança?
O DNS foi criado em 1983 (RFC 1034) como um diretório distribuído. Nenhum mecanismo permitia verificar se uma resposta vinha do servidor legítimo. Um atacante podia injetar uma resposta falsa (DNS spoofing) e redirecionar o tráfego para um servidor malicioso.
O DNSSEC (RFC 4033) resolve esse problema adicionando assinaturas criptográficas. Porém, uma assinatura sozinha não basta: é preciso um meio de verificar se a chave de assinatura é legítima. Esse é o papel da cadeia de confiança.
O princípio é simples: cada nível da hierarquia DNS garante a autenticidade do nível seguinte.
Os três níveis da hierarquia DNS
A resolução DNS segue uma estrutura em árvore com três níveis. O DNSSEC explora essa hierarquia para construir a cadeia de confiança.
Nível 1: a raiz DNS (root)
A raiz DNS é o ponto de partida de toda resolução. Ela é gerida pela IANA (Internet Assigned Numbers Authority) e distribuída em 13 clusters de servidores raiz. A raiz assina os registos DS de cada TLD.
A âncora de confiança (trust anchor) da raiz baseia-se na sua KSK. O resolvedor validante conserva-a na sua configuração e deve mantê-la atualizada quando as chaves mudam. É o ponto de partida da cadeia, não uma chave integrada de uma vez por todas.
Nível 2: o TLD (.com, .fr, .org)
O TLD recebe a sua legitimidade da raiz por meio de um DS record. O registo do TLD (Verisign para .com, AFNIC para .fr) gere a assinatura da sua zona. O TLD, por sua vez, assina os DS records de cada domínio registado.
Nível 3: o seu domínio (captaindns.com)
O seu domínio é o último elo. O seu fornecedor DNS assina os registos da sua zona (A, MX, TXT, etc.) e publica as chaves públicas. O DS record publicado no TLD vincula a sua zona à zona pai.
As chaves criptográficas: ZSK e KSK
Cada zona DNSSEC utiliza dois pares de chaves. A sua separação permite uma rotação independente e limita o impacto de um comprometimento.
ZSK (Zone Signing Key)
A ZSK assina os registos DNS da sua zona. Cada tipo de registo (A, MX, TXT, AAAA) recebe a sua própria assinatura RRSIG.
- Tamanho típico: 1024-2048 bits (RSA) ou 256 bits (ECDSA P-256)
- Rotação: a cada 1 a 3 meses
- Publicada no: registo DNSKEY da sua zona (flag 256)
A rotação frequente da ZSK limita os riscos. Se a chave for comprometida, a exposição é limitada no tempo. A rotação da ZSK não exige atualização do DS record no TLD.
KSK (Key Signing Key)
A KSK do seu domínio assina apenas o conjunto de DNSKEY (incluindo a ZSK). O seu hash é publicado no DS record no nível do TLD. É a ponte entre a sua zona e a zona pai.
- Tamanho típico: 2048-4096 bits (RSA) ou 384 bits (ECDSA P-384)
- Rotação: a cada 1 a 2 anos
- Publicada no: registo DNSKEY da sua zona (flag 257)
A rotação da KSK do seu domínio é mais delicada: ela exige a atualização do DS record no registrar. Uma coordenação mal feita quebra a cadeia de confiança.
Os registos DNSSEC explicados
Quatro tipos de registos DNS garantem o funcionamento da cadeia.
DNSKEY: as chaves públicas
O registo DNSKEY contém a chave pública usada para verificar as assinaturas. A sua zona publica no mínimo dois DNSKEY: um para a ZSK (flag 256) e um para a KSK (flag 257).
dig DNSKEY captaindns.com +short
O resolvedor usa essas chaves para verificar as assinaturas RRSIG dos registos da sua zona.
RRSIG: as assinaturas
Cada registo DNS assinado possui um RRSIG correspondente. O RRSIG contém a assinatura criptográfica, o algoritmo utilizado, o período de validade e o Key Tag da chave que realizou a assinatura.
dig A captaindns.com +dnssec
O resolvedor verifica se a assinatura RRSIG corresponde ao registo retornado e se a chave (DNSKEY) é válida.
DS: o vínculo com a zona pai
O DS record (Delegation Signer) é publicado na zona pai (o TLD). Ele contém um hash da KSK da sua zona. O resolvedor compara esse hash com a KSK publicada no seu DNSKEY para confirmar a legitimidade das suas chaves.
dig DS captaindns.com +short
O DS record é o elo crítico entre dois níveis da hierarquia. Sem DS record, a cadeia é rompida e o DNSSEC aparece como INSECURE.
NSEC/NSEC3: a prova de inexistência
NSEC e NSEC3 provam que um registo solicitado não existe, de forma autenticada. Sem esses registos, um atacante poderia forjar respostas "domínio inexistente" (NXDOMAIN) para desviar o tráfego.
O NSEC3 (RFC 5155) adiciona um hash dos nomes para evitar a enumeração de zona (zone walking).
Como o resolvedor valida uma resposta?
Veja o processo completo de validação quando um resolvedor recebe uma consulta para captaindns.com.
Etapa 1: recuperar a âncora de confiança
O resolvedor parte de uma âncora de confiança da raiz configurada localmente. Esta confiança inicial não vem de uma zona pai; a âncora deve depois ser mantida atualizada, nomeadamente através do RFC 5011 quando este mecanismo é suportado e funciona.
Atualização de 12 de outubro de 2026: o rollover da KSK da raiz ocorreu a 11 de outubro. A secção sobre o rollover da raiz, mais abaixo, indica o que muda para um resolvedor autogerido.
Etapa 2: validar da raiz até o TLD
- O resolvedor solicita o DS record de
.comà raiz - A raiz retorna o DS record e a sua assinatura RRSIG
- O resolvedor valida o conjunto DNSKEY da raiz com a KSK da raiz e, depois, a assinatura do DS com a ZSK assim autenticada
- O DS record de
.comagora está validado
Etapa 3: validar do TLD até o seu domínio
- O resolvedor solicita o DS record de
captaindns.comao TLD.com - O TLD retorna o DS record e a sua assinatura RRSIG
- O resolvedor verifica a assinatura com a DNSKEY do TLD (validada na etapa 2)
- O DS record de
captaindns.comagora está validado
Etapa 4: validar a sua zona
- O resolvedor solicita o DNSKEY de
captaindns.com - Ele compara o hash da KSK com o DS record validado na etapa 3
- Se o hash corresponder, os DNSKEY são legítimos
- O resolvedor solicita o registo A e verifica o seu RRSIG com a ZSK
Se todas as etapas forem bem-sucedidas, a resposta é marcada como SECURE (flag ad na resposta DNS). Se uma etapa falhar, a resposta é BOGUS e o resolvedor retorna SERVFAIL.
Rollover da KSK da raiz: ponto de situação a 12 de outubro de 2026
Desde 11 de outubro de 2026, a KSK-2024 (key tag 38696) assina o conjunto DNSKEY da zona raiz em vez da KSK-2017 (20326): é a única KSK a assiná-lo. Verificado a 12 de outubro de 2026: em k.root-servers.net e a.root-servers.net, o conjunto DNSKEY da raiz está assinado pela 38696, e a IANA classifica a KSK-2024 no estado Active, «Signing since 2026-10-11». Este rollover não altera o algoritmo. Os DS dos TLD continuam a ser assinados pela ZSK.
Publicada a 11 de janeiro de 2025, a nova chave deveria ser reconhecida como âncora através do RFC 5011 logo a partir de 10 de fevereiro de 2025. Este calendário não prova que a atualização tenha sido bem-sucedida no seu resolvedor.
A antiga chave 20326 continua publicada na zona raiz. A 12 de outubro de 2026, a IANA classifica-a no estado Post-Publication e indica que continua a ser uma âncora de confiança válida: não a retire do seu resolvedor por iniciativa própria. Para a sua remoção, consulte o calendário atualizado da IANA.
A recomendação da ICANN é verificar, sem o presumir, se 38696 é uma âncora de confiança utilizável localmente. Ver esta chave numa resposta DNS não basta.
Um resolvedor autogerido que não tenha 38696 nas suas âncoras deixa de validar o conjunto DNSKEY da raiz. Os SERVFAIL surgem em domínios corretamente configurados à medida que o conjunto DNSKEY da raiz em cache expira (TTL de 2 dias). Se uma consulta devolver SERVFAIL nesse resolvedor mas obtiver uma resposta normal com dig +cd (validação desativada apenas para este teste), é a validação que falha: verifique a âncora 38696 antes de mexer na zona ou no registrar. Com 1.1.1.1, 8.8.8.8 ou 9.9.9.9, não há nada a fazer nas respetivas âncoras.
Quando a cadeia se rompe?
Uma quebra pode ter origem na zona ou no resolvedor que a valida. Seguem-se quatro cenários.
DS record ausente ou incorreto
O DS record no TLD não corresponde à KSK publicada na sua zona. Causas:
- O DS record nunca foi adicionado ao registar (a zona está assinada, mas a cadeia não está estabelecida)
- A KSK foi renovada sem atualizar o DS record
- Um erro nos valores do DS record (Key Tag, Algorithm, Digest)
Resultado: INSECURE se não houver DS record. BOGUS se o DS record existir, mas não corresponder.
Assinaturas RRSIG expiradas
Cada assinatura RRSIG tem um período de validade. Se as assinaturas não forem renovadas antes da expiração, o resolvedor as rejeita.
Resultado: BOGUS em todos os registos cuja assinatura tenha expirado.
Prevenção: fornecedores DNS geridos (Cloudflare, Route 53, OVHcloud) renovam as assinaturas automaticamente. O risco existe principalmente com BIND ou PowerDNS autogerenciados.
Algoritmos incompatíveis
Se o DS record especificar um algoritmo diferente daquele usado pela DNSKEY, a validação falha.
Resultado: BOGUS.
Âncora da raiz desatualizada no resolvedor
Desde o rollover de 11 de outubro de 2026, um resolvedor autogerido que não confie em 38696 pode devolver SERVFAIL para muitos domínios que estão corretamente configurados. A falha está na âncora da raiz desse resolvedor, não no DS do seu domínio. Verifique esta âncora antes de alterar a zona ou a configuração no registrar.
Verificar a sua cadeia de confiança
Para confirmar que a sua cadeia está intacta, use o seguinte comando:
dig captaindns.com +dnssec +short
O flag ad (Authenticated Data) na resposta confirma que a cadeia completa foi validada:
dig captaindns.com +dnssec | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
Para uma análise completa de cada elo, use a nossa ferramenta DNS Lookup que detalha os registos DNSKEY, DS e RRSIG.
Plano de ação recomendado
- Entender a sua configuração: identifique quem gere a assinatura de zona (fornecedor DNS) e quem gere o DS record (registrar)
- Verificar a cadeia: confirme que o DS record no TLD corresponde à sua KSK com
dig DS captaindns.com +short - Monitorizar as expirações: acompanhe a validade das assinaturas RRSIG e planeie as rotações de chaves
- Documentar o procedimento: registe as etapas de rotação da KSK para o seu registrar específico
- Testar após cada alteração: verifique a propagação DNS após qualquer modificação DNSSEC
- Resolvedor autogerido: verifique se 38696 é de facto uma âncora de confiança do seu resolvedor; se uma consulta devolver SERVFAIL nesse resolvedor mas uma resposta normal com
dig +cd, é a validação que falha; se utilizar apenas 1.1.1.1, 8.8.8.8 ou 9.9.9.9, não precisa de intervir nas respetivas âncoras
Faça um diagnóstico DNSSEC completo do seu domínio para verificar os seus DS, DNSKEY e RRSIG. O DNSSEC Checker não testa a âncora local do seu resolvedor.
Guias de DNSSEC relacionados
- Ativar DNSSEC: guia passo a passo por registrar
- DANE/TLSA: o guia completo para autenticar certificados de email via DNS
- SERVFAIL após ativação do DNSSEC: diagnóstico e correção
FAQ
O que é a cadeia de confiança DNSSEC?
A cadeia de confiança DNSSEC é o mecanismo pelo qual cada nível da hierarquia DNS (raiz, TLD, domínio) garante a autenticidade do nível seguinte por meio de assinaturas criptográficas. O resolvedor percorre essa cadeia desde a âncora de confiança (KSK raiz) até o seu domínio.
O que é um trust anchor?
Um trust anchor (âncora de confiança) é uma chave ou uma referência a uma chave que o resolvedor considera fiável para iniciar a validação. Para a raiz DNS, baseia-se na KSK da raiz e deve ser mantida atualizada, nomeadamente durante um rollover. O RFC 5011 prevê esta atualização automática, cujo funcionamento deve ser verificado.
O meu resolvedor autogerido é afetado pelo rollover da KSK da raiz?
Sim, se validar DNSSEC. Desde 11 de outubro de 2026, a KSK 38696 assina o conjunto DNSKEY da raiz: um resolvedor autogerido que não a tenha nas suas âncoras pode devolver SERVFAIL em domínios corretamente configurados. Verifique se 38696 é reconhecida como âncora de confiança, sem presumir que o RFC 5011 tenha funcionado. Com 1.1.1.1, 8.8.8.8 ou 9.9.9.9, não precisa de intervir nas respetivas âncoras.
Qual é a diferença entre ZSK e KSK?
A ZSK (Zone Signing Key) assina os registos DNS da sua zona (A, MX, TXT). A KSK (Key Signing Key) assina apenas os DNSKEY. A sua separação permite renovar a ZSK com frequência sem precisar alterar o DS record do registrar.
O que acontece se a cadeia de confiança for quebrada?
Se um elo da cadeia for inválido (DS incorreto, assinatura expirada, chave incompatível), o resolvedor marca a resposta como BOGUS e retorna SERVFAIL ao cliente. Os seus visitantes não conseguem aceder ao seu site até que o problema seja corrigido.
Como o DNSSEC funciona?
O DNSSEC adiciona assinaturas criptográficas a cada registo DNS. O seu fornecedor DNS assina os registos com uma chave privada (ZSK). O resolvedor verifica as assinaturas com a chave pública (DNSKEY). A legitimidade das chaves é garantida por um DS record publicado no TLD, formando uma cadeia de confiança até a raiz.
Como verificar se o DNSSEC funciona no meu domínio?
Execute dig captaindns.com +dnssec | grep flags. Se o flag ad (Authenticated Data) estiver presente, a cadeia de confiança está validada. Também pode usar uma ferramenta online que verifica o DS record, os DNSKEY e as assinaturas RRSIG.
Porque a rotação da KSK é arriscada?
A rotação da KSK do seu domínio exige a atualização do DS record no registrar. Durante a transição, os dois DS records (antigo e novo) precisam de coexistir. Uma coordenação mal feita (DS antigo removido antes da propagação do novo) quebra a cadeia e provoca SERVFAIL.
O DNSSEC funciona com todos os resolvedores?
Não. Apenas os resolvedores validantes verificam as assinaturas DNSSEC. Os principais resolvedores públicos (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) validam DNSSEC. Alguns resolvedores de operadoras não fazem isso. Segundo a APNIC, cerca de 38% das consultas DNS mundiais são validadas com DNSSEC em 2026.
Glossário
- Trust anchor (âncora de confiança): chave ou referência a uma chave reconhecida como fiável para iniciar a validação DNSSEC; a âncora da raiz deve ser mantida atualizada quando a KSK muda.
- DS record (Delegation Signer): registo publicado na zona pai contendo um hash da KSK. Vínculo entre dois níveis da hierarquia.
- DNSKEY: registo contendo a chave pública de assinatura. Flag 256 para a ZSK, flag 257 para a KSK.
- RRSIG: assinatura criptográfica de um registo DNS. Contém o algoritmo, o período de validade e o Key Tag.
- NSEC/NSEC3: registos de prova de inexistência autenticada. O NSEC3 adiciona um hash para evitar a enumeração de zona.
- BOGUS: estado de uma resposta DNS cuja validação DNSSEC falhou. O resolvedor retorna SERVFAIL.
