Solução de problemas DANE/TLSA: diagnosticar e corrigir os erros mais comuns

Você implantou DANE/TLSA no seu servidor de email seguindo as boas práticas, tudo estava funcionando, e então um dia os emails começam a ser recusados por alguns destinatários. A mensagem de erro menciona "failed DANE validation" ou "TLSA record not found", mas os logs não informam exatamente o que mudou.

Esse cenário é o cotidiano dos administradores DANE. A dificuldade não está na complexidade do protocolo, mas no número de componentes envolvidos: DNSSEC, certificado TLS, registro TLSA, configuração MTA. Um único elo defeituoso é suficiente para quebrar toda a cadeia.

Este guia cobre os 5 erros DANE/TLSA mais frequentes com, para cada um, o sintoma, os comandos de diagnóstico e a correção. Ele é destinado a administradores de sistema e DevOps que já possuem uma configuração DANE em funcionamento. Se você ainda não implantou DANE, comece pelo primeiro artigo desta série (veja "Guias relacionados" no final da página).

Os 5 erros DANE mais comuns

Os problemas DANE se dividem em 5 categorias. Cada seção abaixo descreve o sintoma observável, o comando de diagnóstico e a correção.

Erro 1: DNSSEC não assinado ou assinatura expirada

Sintoma: os servidores de envio reportam "DANE required but not available" ou "no DNSSEC" nos relatórios TLS-RPT. Os emails são entregues em modo oportunístico (sem verificação DANE) ou recusados.

Diagnóstico:

# Verificar o flag AD (Authenticated Data)
dig +dnssec MX captaindns.com | grep flags
# Resultado esperado: flags: qr rd ra ad

# Verificar a validade das assinaturas RRSIG
dig +dnssec SOA captaindns.com | grep RRSIG
# A data de expiração está no campo RRSIG

Causas frequentes:

• O registrar desativou o DNSSEC após uma transferência de domínio
• As chaves DNSSEC (KSK/ZSK) expiraram sem rotação automática
• O DS record no registrar não corresponde mais à DNSKEY ativa

Correção: verifique se o DS record no seu registrar corresponde à sua DNSKEY. Se você usa Bind9, verifique as datas de expiração das chaves com dnssec-settime e configure a rotação automática.

Erro 2: hash TLSA desatualizado após renovação do certificado

Sintoma: "TLSA validation failed" ou "certificate mismatch" nos logs. Esse erro ocorre tipicamente 60 a 90 dias após a implantação inicial, na primeira renovação Let's Encrypt.

Diagnóstico:

# Hash do certificado ativo (selector 0 : Full cert)
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -outform DER \
  | openssl dgst -sha256

# Hash publicado no DNS
dig TLSA _25._tcp.mail.captaindns.com +short
# Comparar os 64 caracteres hexadecimais

Causas frequentes:

• O hook de renovação do Certbot não atualiza o TLSA
• O selector é Full (0) em vez de SPKI (1): cada renovação altera o hash
• O usage é DANE-EE (3) sem --reuse-key no Certbot

Correção:

• Solução rápida: gere o novo hash com nosso DANE TLSA Generator e atualize o DNS
• Solução durável: use SPKI selector (1) com --reuse-key no Certbot, ou mude para DANE-TA (2) com o certificado CA Let's Encrypt. Consulte nosso tutorial Postfix/Bind/Let's Encrypt (artigo 2 desta série) para a configuração do hook de renovação automática

Erro 3: TLSA publicado no nome DNS errado

Sintoma: "no TLSA records found" mesmo tendo criado o registro. Este é o erro mais comum entre iniciantes em DANE.

Diagnóstico:

# Encontrar o hostname MX
dig MX captaindns.com +short
# Resultado: 10 mail.captaindns.com.

# Verificar o TLSA no local correto (hostname MX)
dig TLSA _25._tcp.mail.captaindns.com +short

# Erro típico: TLSA publicado no domínio em vez do MX
dig TLSA _25._tcp.captaindns.com +short
# Esse TLSA é IGNORADO pelos servidores de envio

Causa: confusão entre o domínio (captaindns.com) e o hostname MX (mail.captaindns.com). O TLSA deve ser publicado em _25._tcp.<hostname-MX>, conforme a RFC 7672 seção 2.1.1.

Correção: publique o TLSA em _25._tcp.mail.captaindns.com (ou o hostname retornado pelo seu registro MX). Se o seu domínio tem vários MX, cada hostname deve ter seu próprio TLSA.

Erro 4: STARTTLS não disponível ou mal configurado

Sintoma: DANE está configurado no DNS, mas o servidor não oferece STARTTLS, ou o certificado apresentado não corresponde ao hostname. Os logs mostram "TLS handshake failed" ou "certificate hostname mismatch".

Diagnóstico:

# Testar se STARTTLS é oferecido
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp -verify 5

# Verificar o Common Name e os SAN do certificado
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Causas frequentes:

• smtpd_tls_cert_file aponta para um arquivo errado no Postfix
• O certificado não contém o hostname MX nos seus Subject Alternative Names
• O firewall bloqueia STARTTLS ou a porta 25 não está acessível em TLS

Correção: no Postfix, verifique se smtpd_tls_security_level está no mínimo em may e se os caminhos dos certificados estão corretos:

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may

Erro 5: propagação DNS incompleta

Sintoma: DANE funciona de forma intermitente. Alguns servidores de envio validam o TLSA, outros reportam um erro. O problema aparece frequentemente após uma atualização DNS recente.

Diagnóstico:

# Comparar as respostas entre servidores NS
dig TLSA _25._tcp.mail.captaindns.com @ns1.captaindns.com +short
dig TLSA _25._tcp.mail.captaindns.com @ns2.captaindns.com +short

# Verificar o TTL restante
dig TLSA _25._tcp.mail.captaindns.com +noall +answer

Causas frequentes:

• Transferência de zona incompleta entre servidores DNS primário e secundário
• TTL elevado no registro antigo (os caches DNS mantêm o valor anterior)
• Um servidor NS não responde ou retorna uma versão desatualizada da zona

Correção: verifique se todos os seus servidores NS retornam o mesmo valor TLSA. Se você acabou de atualizar o TLSA, aguarde a expiração do TTL anterior antes de remover o registro antigo. Para rotações de certificado, publique o novo TLSA 2x TTL antes da rotação efetiva.

Monitorar DANE em produção

Corrigir um erro pontual não é suficiente. Os 3 mecanismos de monitoramento a seguir previnem incidentes recorrentes.

TLS-RPT: ative os relatórios TLS-RPT (RFC 8460) para receber os avisos de falha DANE da parte dos servidores de envio. O campo failure-type no relatório JSON indica precisamente o tipo de erro:

Monitoramento de certificado: configure um alerta 14 dias antes da expiração do certificado TLS. A renovação Let's Encrypt é feita automaticamente, mas o hook TLSA pode falhar silenciosamente.

Verificação automática: agende uma verificação diária com nosso DANE TLSA Syntax Checker ou um script cron que compara o hash publicado ao certificado ativo:

#!/bin/bash
# Verificação diária DANE
TLSA_HASH=$(dig TLSA _25._tcp.mail.captaindns.com +short | awk '{print $4}')
CERT_HASH=$(openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 | awk '{print $2}')

if [ "$TLSA_HASH" != "$CERT_HASH" ]; then
  echo "ALERTA: hash TLSA diverge do certificado ativo" | \
    mail -s "DANE TLSA mismatch" admin@captaindns.com
fi

Plano de ação recomendado

1. Diagnosticar: use a metodologia em 5 passos acima ou nosso DANE TLSA Checker para identificar o problema
2. Identificar: classifique o erro em uma das 5 categorias (DNSSEC, hash, nome DNS, STARTTLS, propagação)
3. Corrigir: aplique a solução correspondente com os comandos fornecidos
4. Verificar: teste a correção com dig +dnssec e openssl s_client antes de considerar o problema resolvido
5. Prevenir: implemente TLS-RPT, o monitoramento de certificado e a verificação automática

📚 Guias de DANE/TLSA relacionados

• DANE/TLSA: o guia completo para autenticar certificados de email via DNS: funcionamento, anatomia TLSA, usos recomendados e comparação com MTA-STS
• Configurar DANE/TLSA com Postfix, Bind e Let's Encrypt: tutorial passo a passo com comandos copiáveis, automação de renovação e verificação
• Implementar DANE para Exchange Online e Microsoft 365

Fontes

• RFC 7672 - SMTP Security via Opportunistic DANE TLS
• RFC 7671 - The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• Postfix TLS README - DANE
• ISC BIND 9 DNSSEC Guide