Ir para o conteudo principal

SERVFAIL após ativar DNSSEC: diagnóstico e correção

Por CaptainDNS
Publicado em 25 de fevereiro de 2026

Diagnóstico SERVFAIL DNSSEC: árvore de decisão para identificar e corrigir a causa de um SERVFAIL após ativar DNSSEC
TL;DR
  • Um SERVFAIL relacionado a DNSSEC significa que o resolvedor rejeitou a resposta DNS porque um elo da cadeia de confiança é inválido
  • Cinco causas cobrem a quase totalidade dos casos: DS ausente, DS incorreto, RRSIG expirada, algoritmo incompatível, cache contaminado
  • Três comandos dig são suficientes para isolar o problema (veja a árvore de decisão no final do artigo)
  • Verifique se sua cadeia está intacta com nosso DNSSEC Checker (veja o plano de ação no final do artigo)

Você acabou de ativar o DNSSEC no seu registrar. Os primeiros testes passam. Algumas horas depois, seus usuários relatam que o site está inacessível. O diagnóstico: SERVFAIL.

O SERVFAIL não é um problema de servidor. É o resolvedor DNS que se recusa a retornar a resposta porque a validação DNSSEC falhou. Seu servidor funciona, mas o resolvedor o bloqueia.

Este guia cobre os cinco cenários de SERVFAIL relacionados a DNSSEC, com o comando de diagnóstico e a correção exata para cada um.

SERVFAIL e DNSSEC: o mecanismo

Quando um resolvedor validante (1.1.1.1, 8.8.8.8, 9.9.9.9) recebe uma resposta DNS para um domínio assinado com DNSSEC, ele verifica a cadeia de confiança completa: âncora de confiança, DS record, DNSKEY, RRSIG.

Se uma verificação falha, o resolvedor marca a resposta como BOGUS e retorna SERVFAIL ao cliente. O site fica inacessível para todos os usuários cujo resolvedor valida DNSSEC (cerca de 38% das consultas DNS mundiais, segundo a APNIC).

A dificuldade: um SERVFAIL não diz por que a validação falhou. É preciso diagnosticar manualmente.

Diagnóstico rápido: três comandos

Antes de analisar cada cenário, veja os três comandos que resolvem a maioria dos casos.

Comando 1: verificar o DS record

dig DS captaindns.com +short

Se o comando não retornar nada, não existe DS record no TLD. A cadeia não foi estabelecida.

Comando 2: comparar DS e DNSKEY

dig DNSKEY captaindns.com +short

O DS record contém um hash da KSK (flag 257). Se o hash não corresponder a nenhuma DNSKEY publicada, o DS está incorreto.

Comando 3: verificar as assinaturas

dig A captaindns.com +dnssec +cd

O flag +cd (Checking Disabled) pede ao resolvedor que retorne a resposta sem validar DNSSEC. Se a resposta chega com +cd mas não sem ele, o problema é mesmo DNSSEC.

As cinco causas de SERVFAIL após DNSSEC

Causa 1: DS record ausente

Sintoma: dig DS captaindns.com +short não retorna nada.

Explicação: você assinou sua zona (as DNSKEY e RRSIG existem), mas o DS record não foi publicado no TLD. O resolvedor não consegue vincular sua zona à zona pai.

Status DNSSEC: INSECURE (não BOGUS). O resolvedor não valida, mas também não bloqueia. Este caso só provoca SERVFAIL se o resolvedor tiver um DS em cache de uma configuração anterior.

Correção:

  1. Obtenha o DS record do seu provedor DNS (Cloudflare, Route 53, OVHcloud)
  2. Adicione-o na interface do seu registrar (seção DNSSEC)
  3. Aguarde a propagação (TTL do DS no TLD, geralmente 24-48h)

Verificação:

dig DS captaindns.com +short
# Deve retornar o DS record com Key Tag, Algorithm, Digest Type, Digest

Causa 2: DS record incorreto

Sintoma: o DS record existe, mas o hash não corresponde a nenhuma KSK publicada.

Explicação: o DS no TLD contém um hash que não corresponde à KSK da sua zona. Causas frequentes:

  • Erro de cópia ao inserir manualmente
  • Rotação da KSK sem atualização do DS
  • DS gerado com algoritmo de hash errado (SHA-1 em vez de SHA-256)

Status DNSSEC: BOGUS. O resolvedor retorna SERVFAIL.

Diagnóstico:

# Récupérer le DS au TLD
dig DS captaindns.com +short
# Exemple : 12345 13 2 ABC123...

# Récupérer les DNSKEY
dig DNSKEY captaindns.com +short
# Chercher la KSK (flag 257)
# Vérifier que le Key Tag (12345) correspond

Correção:

  1. No seu provedor DNS, gere o DS record correto
  2. Na interface do registrar, remova o DS antigo e adicione o novo
  3. Se o seu registrar suporta CDS/CDNSKEY (RFC 7344), a atualização pode ser automática

Verificação:

dig captaindns.com +dnssec | grep flags
# Le flag "ad" doit être présent

Causa 3: assinaturas RRSIG expiradas

Sintoma: a resposta DNS contém RRSIG cuja data de expiração já passou.

Explicação: cada assinatura RRSIG tem um período de validade (normalmente 7 a 30 dias). Se o seu provedor DNS não renovar as assinaturas antes da expiração, os resolvedores as rejeitam.

Status DNSSEC: BOGUS. SERVFAIL em todos os registros cuja assinatura expirou.

Diagnóstico:

dig A captaindns.com +dnssec +cd
# Examiner le champ RRSIG : inception et expiration
# Format : RRSIG A 13 2 300 20260315120000 20260301120000 12345 captaindns.com. ABC...
#                                ^^^^^^^^^^^^^^^^ expiration
#                                                 ^^^^^^^^^^^^^^^^ inception

Causas frequentes:

  • BIND ou PowerDNS autogerenciado sem renovação automática configurada
  • Erro no cron de reassinatura
  • Migração DNS sem transferir as chaves de assinatura

Correção:

  1. Se DNS gerenciado: entre em contato com o suporte do provedor
  2. Se BIND autogerenciado: execute a reassinatura com rndc sign captaindns.com
  3. Se PowerDNS: execute pdnsutil rectify-zone captaindns.com

Causa 4: algoritmo incompatível

Sintoma: o DS record especifica um algoritmo diferente do usado pela DNSKEY.

Explicação: o DS record indica, por exemplo, o algoritmo 8 (RSA/SHA-256) enquanto a DNSKEY usa o algoritmo 13 (ECDSA P-256). O resolvedor não consegue verificar a correspondência.

Status DNSSEC: BOGUS. SERVFAIL.

Diagnóstico:

# Vérifier l'algorithme du DS
dig DS captaindns.com +short
# Format : KeyTag Algorithm DigestType Digest
# Exemple : 12345 8 2 ABC...  (algorithme 8 = RSA/SHA-256)

# Vérifier l'algorithme de la DNSKEY
dig DNSKEY captaindns.com +short
# Format : Flags Protocol Algorithm PublicKey
# Exemple : 257 3 13 ABC...  (algorithme 13 = ECDSA P-256)

Se os números de algoritmo forem diferentes entre DS e DNSKEY (flag 257), essa é a causa.

Correção:

  1. Gere novamente o DS record no seu provedor DNS (ele usará o algoritmo correto)
  2. Atualize o DS no registrar
  3. Aguarde a propagação

Causa 5: cache do resolvedor (falso SERVFAIL)

Sintoma: SERVFAIL intermitente. Alguns resolvedores retornam SERVFAIL, outros não.

Explicação: o resolvedor armazenou em cache uma resposta antiga ou um DS record antigo. Após uma modificação DNSSEC (ativação, rotação de chave, troca de provedor DNS), o cache do resolvedor pode conter dados inconsistentes.

Diagnóstico:

# Tester avec un résolveur différent
dig A captaindns.com @1.1.1.1 +dnssec
dig A captaindns.com @8.8.8.8 +dnssec
dig A captaindns.com @9.9.9.9 +dnssec

Se alguns resolvedores funcionam e outros não, é um problema de cache.

Correção:

  1. Aguarde a expiração do TTL (verifique o TTL do DS record no TLD)
  2. Limpe o cache se possível:

Prevenção: antes de qualquer modificação DNSSEC, reduza o TTL do DS record 24h antes (se o seu registrar permitir).

Árvore de decisão SERVFAIL DNSSEC: identificar a causa em três comandos dig

Prevenir os SERVFAIL DNSSEC

Três práticas reduzem o risco de quebra:

DNS gerenciado em vez de autogerenciado

Os provedores de DNS gerenciado (Cloudflare, Route 53, OVHcloud, Google Cloud DNS) cuidam da assinatura automaticamente: rotação de chaves, renovação das RRSIG, publicação do DS via CDS/CDNSKEY. O risco de SERVFAIL é quase nulo com DNS gerenciado.

DS duplo durante as transições

Durante uma rotação de KSK, publique os dois DS records (antigo + novo) no registrar. Aguarde a propagação completa do novo DS antes de remover o antigo. Nunca remova o DS antigo antes de verificar que o novo está propagado.

Monitoramento contínuo

Verifique regularmente a propagação DNS da sua configuração DNSSEC. Um DS incorreto ou uma assinatura expirada podem ocorrer silenciosamente. Um alerta automático sobre o status DNSSEC do seu domínio permite detectar um problema antes que seus usuários o relatem.

Processo de correção SERVFAIL DNSSEC: da detecção à verificação pós-correção

Plano de ação em caso de SERVFAIL

  1. Confirmar que DNSSEC é a causa: execute dig captaindns.com +cd; se a resposta chega com +cd mas não sem ele, DNSSEC é a causa
  2. Identificar o elo quebrado: verifique DS, DNSKEY e RRSIG com os três comandos de diagnóstico
  3. Aplicar a correção: siga o cenário correspondente (DS ausente, DS incorreto, RRSIG expirada, algoritmo, cache)
  4. Verificar o reparo: aguarde o TTL e confirme que o flag ad está presente com dig captaindns.com +dnssec
  5. Documentar o incidente: registre a causa, a correção e o tempo de resolução para agilizar diagnósticos futuros

Faça um diagnóstico DNSSEC completo do seu domínio para verificar se cada elo está no lugar.

Guias de DNSSEC relacionados

FAQ

O que é um SERVFAIL DNS?

SERVFAIL (Server Failure) é um código de resposta DNS (RCODE 2) que indica que o resolvedor não conseguiu obter uma resposta válida. No contexto DNSSEC, um SERVFAIL significa que a validação criptográfica falhou: o resolvedor rejeitou a resposta porque um elo da cadeia de confiança é inválido.

Qual é a diferença entre SERVFAIL e NXDOMAIN?

NXDOMAIN significa que o domínio não existe. SERVFAIL significa que o domínio provavelmente existe, mas o resolvedor não conseguiu validar a resposta. Com DNSSEC, um SERVFAIL indica um problema de validação (DS incorreto, assinatura expirada), não um domínio inexistente.

Como saber se um SERVFAIL é causado por DNSSEC?

Use o flag +cd (Checking Disabled) no seu comando dig: dig captaindns.com +cd. Se a resposta chega com +cd mas não sem ele, DNSSEC é a causa do SERVFAIL. Sem +cd, o resolvedor valida DNSSEC e bloqueia a resposta.

Quanto tempo leva para corrigir um SERVFAIL DNSSEC?

A correção em si leva alguns minutos (adição ou modificação do DS record). A propagação pode levar de 1 a 48 horas dependendo do TTL do DS record no TLD. Durante esse período, os resolvedores que tiverem o valor antigo em cache continuarão retornando SERVFAIL.

É necessário desativar o DNSSEC em emergência se houver SERVFAIL?

Não. Desativar o DNSSEC em emergência (remover o DS record sem desativar a assinatura da zona) pode piorar o problema. Identifique primeiro a causa exata. Se o DS record estiver incorreto, corrija-o. Só desative o DNSSEC se não conseguir identificar a causa e o site for crítico.

Por que o SERVFAIL não afeta todos os usuários?

Somente os resolvedores validantes (que verificam DNSSEC) retornam SERVFAIL. Os resolvedores não validantes ignoram as assinaturas e retornam a resposta normalmente. Além disso, os resolvedores que ainda têm a resposta antiga em cache podem continuar funcionando até a expiração do TTL.

Como verificar se a correção DNSSEC funcionou?

Execute dig captaindns.com +dnssec | grep flags. Se o flag ad (Authenticated Data) estiver presente, a cadeia de confiança está validada. Teste com vários resolvedores (1.1.1.1, 8.8.8.8, 9.9.9.9) para confirmar que a propagação está completa.

O DNS gerenciado elimina o risco de SERVFAIL DNSSEC?

Quase totalmente. Os provedores de DNS gerenciado (Cloudflare, Route 53, OVHcloud) cuidam automaticamente da assinatura, da rotação de chaves e da renovação das RRSIG. O único risco restante é um DS record incorreto no registrar, o que pode ocorrer durante a configuração inicial ou uma transferência de domínio.

Glossário

  • SERVFAIL: código de resposta DNS (RCODE 2) indicando que o resolvedor não conseguiu completar a consulta. No contexto DNSSEC, sinaliza uma falha de validação.
  • BOGUS: estado interno do resolvedor quando a validação DNSSEC falha. O resolvedor retorna SERVFAIL ao cliente.
  • INSECURE: estado de um domínio cuja zona é assinada, mas sem DS record no TLD. O resolvedor não valida, mas também não bloqueia.
  • DS record: registro no TLD contendo um hash da KSK. Elo entre a zona e a zona pai.
  • RRSIG: assinatura criptográfica de um registro DNS com um período de validade definido.
  • +cd (Checking Disabled): flag dig que pede ao resolvedor para não validar DNSSEC, útil para diagnosticar se DNSSEC está causando SERVFAIL.

Fontes

Artigos relacionados