Solución de problemas DANE/TLSA: diagnosticar y corregir los errores comunes

Has desplegado DANE/TLSA en tu servidor de correo siguiendo las buenas prácticas, todo funcionaba, y un día los emails empiezan a ser rechazados por ciertos destinatarios. El mensaje de error menciona "failed DANE validation" o "TLSA record not found", pero los logs no te dicen exactamente qué ha cambiado.

Este escenario es el día a día de los administradores DANE. La dificultad no está en la complejidad del protocolo, sino en la cantidad de componentes implicados: DNSSEC, certificado TLS, registro TLSA, configuración MTA. Un solo eslabón defectuoso basta para romper toda la cadena.

Esta guía cubre los 5 errores DANE/TLSA más frecuentes con, para cada uno, el síntoma, los comandos de diagnóstico y la corrección. Está dirigida a administradores de sistemas y DevOps que ya tienen una configuración DANE operativa. Si aún no has desplegado DANE, empieza por el primer artículo de esta serie (consulta "Guías relacionadas" al final de la página).

Los 5 errores DANE más comunes

Los problemas DANE se clasifican en 5 categorías. Cada sección a continuación describe el síntoma observable, el comando de diagnóstico y la corrección.

Error 1: DNSSEC no firmado o firma expirada

Síntoma: los servidores emisores reportan "DANE required but not available" o "no DNSSEC" en los informes TLS-RPT. Los emails se entregan en modo oportunista (sin verificación DANE) o son rechazados.

Diagnóstico:

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

# Verificar la validez de las firmas RRSIG
dig +dnssec SOA captaindns.com | grep RRSIG
# La fecha de expiración está en el campo RRSIG

Causas frecuentes:

• El registrar desactivó DNSSEC tras una transferencia de dominio
• Las claves DNSSEC (KSK/ZSK) expiraron sin rotación automática
• El DS record en el registrar ya no corresponde a la DNSKEY activa

Corrección: verifica que el DS record en tu registrar corresponda a tu DNSKEY. Si usas Bind9, comprueba las fechas de expiración de las claves con dnssec-settime y configura la rotación automática.

Error 2: hash TLSA obsoleto tras la renovación del certificado

Síntoma: "TLSA validation failed" o "certificate mismatch" en los logs. Este error aparece típicamente entre 60 y 90 días después del despliegue inicial, en la primera renovación de Let's Encrypt.

Diagnóstico:

# Hash del certificado activo (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 en el DNS
dig TLSA _25._tcp.mail.captaindns.com +short
# Comparar los 64 caracteres hexadecimales

Causas frecuentes:

• El hook de renovación de Certbot no actualiza el TLSA
• El selector es Full (0) en vez de SPKI (1): cada renovación cambia el hash
• El usage es DANE-EE (3) sin --reuse-key en Certbot

Corrección:

• Solución rápida: genera el nuevo hash con nuestro DANE TLSA Generator y actualiza el DNS
• Solución duradera: usa SPKI selector (1) con --reuse-key en Certbot, o pasa a DANE-TA (2) con el certificado CA de Let's Encrypt. Consulta nuestro tutorial Postfix/Bind/Let's Encrypt (artículo 2 de esta serie) para la configuración del hook de renovación automática

Error 3: TLSA publicado con un nombre DNS incorrecto

Síntoma: "no TLSA records found" aunque hayas creado el registro. Es el error más común entre los principiantes de DANE.

Diagnóstico:

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

# Verificar el TLSA en el lugar correcto (hostname MX)
dig TLSA _25._tcp.mail.captaindns.com +short

# Error típico: TLSA publicado en el dominio en lugar del MX
dig TLSA _25._tcp.captaindns.com +short
# Este TLSA es IGNORADO por los servidores emisores

Causa: confusión entre el dominio (captaindns.com) y el hostname MX (mail.captaindns.com). El TLSA debe publicarse en _25._tcp.<hostname-MX>, conforme a la RFC 7672 sección 2.1.1.

Corrección: publica el TLSA en _25._tcp.mail.captaindns.com (o el hostname que devuelve tu registro MX). Si tu dominio tiene varios MX, cada hostname debe tener su propio TLSA.

Error 4: STARTTLS no disponible o mal configurado

Síntoma: DANE está configurado en el DNS pero el servidor no ofrece STARTTLS, o el certificado presentado no corresponde al hostname. Los logs muestran "TLS handshake failed" o "certificate hostname mismatch".

Diagnóstico:

# Probar si STARTTLS es ofrecido
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp -verify 5

# Verificar el Common Name y los SAN del certificado
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Causas frecuentes:

• smtpd_tls_cert_file apunta a un archivo incorrecto en Postfix
• El certificado no contiene el hostname MX en sus Subject Alternative Names
• El firewall bloquea STARTTLS o el puerto 25 no es accesible en TLS

Corrección: en Postfix, verifica que smtpd_tls_security_level esté como mínimo en may y que las rutas de los certificados sean correctas:

# /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

Error 5: propagación DNS incompleta

Síntoma: DANE funciona de forma intermitente. Algunos servidores emisores validan el TLSA, otros reportan un error. El problema suele aparecer tras una actualización DNS reciente.

Diagnóstico:

# Comparar las respuestas 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 el TTL restante
dig TLSA _25._tcp.mail.captaindns.com +noall +answer

Causas frecuentes:

• Transferencia de zona incompleta entre servidores DNS primario y secundario
• TTL elevado en el registro anterior (las cachés DNS conservan el valor antiguo)
• Un servidor NS no responde o devuelve una versión obsoleta de la zona

Corrección: verifica que todos tus servidores NS devuelvan el mismo valor TLSA. Si acabas de actualizar el TLSA, espera a que expire el TTL anterior antes de eliminar el registro antiguo. Para las rotaciones de certificado, publica el nuevo TLSA 2x TTL antes de la rotación efectiva.

Monitorizar DANE en producción

Corregir un error puntual no es suficiente. Los 3 mecanismos de monitorización siguientes previenen los incidentes recurrentes.

TLS-RPT: activa los informes TLS-RPT (RFC 8460) para recibir las notificaciones de fallos DANE por parte de los servidores emisores. El campo failure-type en el informe JSON indica con precisión el tipo de error:

Monitorización del certificado: configura una alerta 14 días antes de la expiración del certificado TLS. La renovación de Let's Encrypt se hace automáticamente, pero el hook TLSA puede fallar silenciosamente.

Verificación automática: programa una verificación diaria con nuestro DANE TLSA Syntax Checker o un script cron que compare el hash publicado con el certificado activo:

#!/bin/bash
# Verificación diaria 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: el hash TLSA diverge del certificado activo" | \
    mail -s "DANE TLSA mismatch" admin@captaindns.com
fi

Plan de acción recomendado

1. Diagnosticar: usa la metodología en 5 pasos anterior o nuestro DANE TLSA Checker para identificar el problema
2. Identificar: clasifica el error en una de las 5 categorías (DNSSEC, hash, nombre DNS, STARTTLS, propagación)
3. Corregir: aplica la solución correspondiente con los comandos proporcionados
4. Verificar: prueba la corrección con dig +dnssec y openssl s_client antes de dar el problema por resuelto
5. Prevenir: implementa TLS-RPT, la monitorización del certificado y la verificación automática

📚 Guías de DANE/TLSA relacionadas

• DANE/TLSA: la guía completa para autenticar certificados de correo electrónico mediante DNS: funcionamiento, anatomía TLSA, usos recomendados y comparación con MTA-STS
• Configurar DANE/TLSA con Postfix, Bind y Let's Encrypt: tutorial paso a paso con comandos copiables, automatización de renovación y verificación
• Desplegar DANE para Exchange Online y Microsoft 365

Fuentes

• 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