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 registros 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 autogerenciado que não a tem entre suas âncoras pode retornar 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 você instala em um servidor. É um sistema distribuído. A confiança se propaga 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.
Por que 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 é gerenciada pela IANA (Internet Assigned Numbers Authority) e distribuída em 13 clusters de servidores raiz. A raiz assina os registros DS de cada TLD.
A âncora de confiança (trust anchor) da raiz se baseia na sua KSK. O resolvedor validante a mantém na configuração e deve atualizar essa âncora quando as chaves mudam. Ela é 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 sua legitimidade da raiz por meio de um DS record. O registro do TLD (Verisign para .com, AFNIC para .fr) gerencia a assinatura da sua zona. O TLD, por sua vez, assina os DS records de cada domínio registrado.
Nível 3: o seu domínio (captaindns.com)
O seu domínio é o último elo. O seu provedor DNS assina os registros 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. Sua separação permite uma rotação independente e limita o impacto de um comprometimento.
ZSK (Zone Signing Key)
A ZSK assina os registros DNS da sua zona. Cada tipo de registro (A, MX, TXT, AAAA) recebe 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: registro 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). 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: registro 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 registros DNSSEC explicados
Quatro tipos de registros DNS garantem o funcionamento da cadeia.
DNSKEY: as chaves públicas
O registro DNSKEY contém a chave pública usada para verificar as assinaturas. 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 registros da sua zona.
RRSIG: as assinaturas
Cada registro 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 registro 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 registro solicitado não existe, de forma autenticada. Sem esses registros, 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. Essa confiança inicial não vem de uma zona pai; a âncora precisa ser mantida atualizada, especialmente pelo RFC 5011 quando esse mecanismo é suportado e funciona.
Atualização de 12 de outubro de 2026: o rollover da KSK da raiz aconteceu em 11 de outubro. A seção sobre o rollover da raiz, mais abaixo, explica o que muda para um resolvedor autogerenciado.
Etapa 2: validar da raiz até o TLD
- O resolvedor solicita o DS record de
.comà raiz - A raiz retorna o DS record e 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 autenticada dessa forma
- 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 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 registro A e verifica 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: situação em 12 de outubro de 2026
Desde 11 de outubro de 2026, a KSK-2024 (key tag 38696) assina o conjunto DNSKEY da zona raiz no lugar da KSK-2017 (20326): ela é a única KSK a assiná-lo. Verificado em 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 com status Active, "Signing since 2026-10-11". Esse rollover não altera o algoritmo. Os DS dos TLD continuam sendo assinados pela ZSK.
Publicada em 11 de janeiro de 2025, a nova chave deveria ser reconhecida como âncora pelo RFC 5011 já a partir de 10 de fevereiro de 2025. Esse calendário não comprova que a atualização funcionou no seu resolvedor.
A chave antiga 20326 continua publicada na zona raiz. Em 12 de outubro de 2026, a IANA a classifica com status Post-Publication e indica que ela continua sendo uma âncora de confiança válida: não a remova do seu resolvedor por conta própria. Para a remoção dela, consulte o calendário atualizado da IANA.
A orientação da ICANN é verificar, sem presumir, se 38696 é uma âncora de confiança utilizável localmente. Ver essa chave em uma resposta DNS não basta.
Um resolvedor autogerenciado que não tem 38696 entre suas âncoras deixa de validar o conjunto DNSKEY da raiz. Os SERVFAIL aparecem em domínios corretamente configurados à medida que o conjunto DNSKEY da raiz em cache expira (TTL de 2 dias). Se uma consulta retornar SERVFAIL nesse resolvedor, mas obtiver uma resposta normal com dig +cd (validação desativada só para esse teste), é a validação que está falhando: 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, você não precisa fazer nada nas âncoras deles.
Quando a cadeia se rompe?
Uma quebra pode ter origem na zona ou no resolvedor que a valida. Veja 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 registrar (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 registros cuja assinatura tenha expirado.
Prevenção: provedores DNS gerenciados (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 autogerenciado que não confia em 38696 pode retornar 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 essa âncora antes de alterar a zona ou a configuração no registrar.
Verificar 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 registros DNSKEY, DS e RRSIG.
Plano de ação recomendado
- Entender sua configuração: identifique quem gerencia a assinatura de zona (provedor DNS) e quem gerencia o DS record (registrar)
- Verificar a cadeia: confirme que o DS record no TLD corresponde à sua KSK com
dig DS captaindns.com +short - Monitorar as expirações: acompanhe a validade das assinaturas RRSIG e planeje as rotações de chaves
- Documentar o procedimento: registre 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 autogerenciado: verifique se 38696 é de fato uma âncora de confiança do seu resolvedor; se uma consulta retornar SERVFAIL nesse resolvedor, mas uma resposta normal com
dig +cd, é a validação que está falhando; se você usa apenas 1.1.1.1, 8.8.8.8 ou 9.9.9.9, não precisa fazer nenhuma alteração nas âncoras deles
Faça um diagnóstico DNSSEC completo do seu domínio para verificar 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 confiável para iniciar a validação. Para a raiz DNS, ela se baseia na KSK da raiz e deve ser mantida atualizada, especialmente durante um rollover. O RFC 5011 prevê essa atualização automática, cujo funcionamento precisa ser verificado.
Meu resolvedor autogerenciado é afetado pelo rollover da KSK da raiz?
Sim, se ele valida DNSSEC. Desde 11 de outubro de 2026, a KSK 38696 assina o conjunto DNSKEY da raiz: um resolvedor autogerenciado que não a tem entre suas âncoras pode retornar SERVFAIL em domínios corretamente configurados. Verifique se 38696 é reconhecida como âncora de confiança, sem presumir que o RFC 5011 funcionou. Com 1.1.1.1, 8.8.8.8 ou 9.9.9.9, você não precisa fazer nenhuma alteração nas âncoras deles.
Qual é a diferença entre ZSK e KSK?
A ZSK (Zone Signing Key) assina os registros DNS da sua zona (A, MX, TXT). A KSK (Key Signing Key) assina apenas os DNSKEY. 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. Seus visitantes não conseguem acessar o seu site até que o problema seja corrigido.
Como o DNSSEC funciona?
O DNSSEC adiciona assinaturas criptográficas a cada registro DNS. Seu provedor DNS assina os registros 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. Você também pode usar uma ferramenta online que verifica o DS record, os DNSKEY e as assinaturas RRSIG.
Por que 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 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 confiável para iniciar a validação DNSSEC; a âncora da raiz deve ser mantida atualizada quando a KSK muda.
- DS record (Delegation Signer): registro publicado na zona pai contendo um hash da KSK. Vínculo entre dois níveis da hierarquia.
- DNSKEY: registro contendo a chave pública de assinatura. Flag 256 para a ZSK, flag 257 para a KSK.
- RRSIG: assinatura criptográfica de um registro DNS. Contém o algoritmo, o período de validade e o Key Tag.
- NSEC/NSEC3: registros 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.
