Um SERVFAIL é uma parada brusca. Significa que o resolver recursivo protegendo seus usuários determinou que sua zona autoritativa está quebrada ou não é confiável criptograficamente. Quando isso acontece, o tráfego cai a zero instantaneamente.

Se você está enfrentando um incidente de SERVFAIL ativo, use o seguinte manual de triagem.

Manual de Triagem de Emergência

Fase 1: Verifique a Criptografia

A grande maioria dos SERVFAILs são feridas auto-infligidas causadas por chaves DNSSEC expiradas. Para checar se a sua criptografia está rejeitando usuários, force uma consulta diagnóstica que pergunte especificamente pelas assinaturas:

delv @8.8.8.8 seudominio.com

Procure por linhas reportando 'resolution failed'. Para confirmar que o DNSSEC é o culpado, rode o comando com o modo Checking Disabled:

dig +cd seudominio.com A

Se a consulta `+cd` retornar um IP válido mas a normal der SERVFAIL, sua configuração DNSSEC está quebrada. A mitigação imediata é logar no Registrador (ex: Namecheap) e remover todos os registros DS. Não mexa nos servers ainda. Removendo DS resolve a quebra de confiança e o tráfego voltará assim que o TLD propagar.

Fase 2: Verifique a Delegação

Se o DNSSEC não está ativado, o segundo culpado mais comum é delegar para servidores que se recusam a responder pelo seu domínio.

Verifique os registros NS listados no nível do TLD:

dig +trace seudominio.com

Olhe o passo final antes da falha. Anote os nomes de host. Consulte um deles especificamente:

dig @ns1.the-server-from-trace.com seudominio.com A

Se retornar 'REFUSED', você tem um mapped mismatch. Seu registrador aponta para uma zona deletada ou suspensa.

Prevenindo Futuros Treinos de Combate

Triar manualmente um SERVFAIL é estressante porque cada minuto conta contra seu SLA.

Ao implantar monitoramento proativo com o Heimdall Observer, você automatiza essas checagens. O sistema alerta direto no Slack se um registro DS desvia, permitindo corrigir semanas antes de incomodar usuários.