Troubleshooting DANE/TLSA: diagnosticare e correggere gli errori comuni

Hai distribuito DANE/TLSA sul tuo server email seguendo le best practice, tutto funzionava, poi un giorno le email iniziano a essere rifiutate da certi destinatari. Il messaggio d'errore menziona "failed DANE validation" o "TLSA record not found", ma i log non ti dicono esattamente cosa è cambiato.

Questo scenario è il quotidiano degli amministratori DANE. La difficoltà non sta nella complessità del protocollo, ma nel numero di componenti coinvolti: DNSSEC, certificato TLS, record TLSA, configurazione MTA. Un solo anello debole basta per rompere tutta la catena.

Questa guida copre i 5 errori DANE/TLSA più frequenti con, per ciascuno, il sintomo, i comandi di diagnosi e la correzione. Si rivolge agli amministratori di sistema e DevOps che hanno già una configurazione DANE attiva. Se non hai ancora distribuito DANE, inizia dal primo articolo di questa serie (vedi "Guide correlate" in fondo alla pagina).

I 5 errori DANE più comuni

I problemi DANE si suddividono in 5 categorie. Ogni sezione qui sotto descrive il sintomo osservabile, il comando di diagnosi e la correzione.

Errore 1: DNSSEC non firmato o firma scaduta

Sintomo: i server mittenti segnalano "DANE required but not available" o "no DNSSEC" nei report TLS-RPT. Le email vengono consegnate in modalità opportunistica (senza verifica DANE) o rifiutate.

Diagnosi:

# Verificare il flag AD (Authenticated Data)
dig +dnssec MX captaindns.com | grep flags
# Risultato atteso: flags: qr rd ra ad

# Verificare la validità delle firme RRSIG
dig +dnssec SOA captaindns.com | grep RRSIG
# La data di scadenza è nel campo RRSIG

Cause frequenti:

• Il registrar ha disattivato DNSSEC dopo un trasferimento di dominio
• Le chiavi DNSSEC (KSK/ZSK) sono scadute senza rotazione automatica
• Il DS record presso il registrar non corrisponde più alla DNSKEY attiva

Correzione: verifica che il DS record presso il tuo registrar corrisponda alla tua DNSKEY. Se usi Bind9, controlla le date di scadenza delle chiavi con dnssec-settime e configura la rotazione automatica.

Errore 2: hash TLSA obsoleto dopo il rinnovo del certificato

Sintomo: "TLSA validation failed" o "certificate mismatch" nei log. Questo errore si verifica tipicamente 60-90 giorni dopo il deployment iniziale, al primo rinnovo Let's Encrypt.

Diagnosi:

# Hash del certificato attivo (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 pubblicato nel DNS
dig TLSA _25._tcp.mail.captaindns.com +short
# Confrontare i 64 caratteri esadecimali

Cause frequenti:

• L'hook di rinnovo Certbot non aggiorna il TLSA
• Il selector è Full (0) invece di SPKI (1): ogni rinnovo cambia l'hash
• L'usage è DANE-EE (3) senza --reuse-key in Certbot

Correzione:

• Soluzione rapida: genera il nuovo hash con il nostro DANE TLSA Generator e aggiorna il DNS
• Soluzione duratura: usa SPKI selector (1) con --reuse-key in Certbot, o passa a DANE-TA (2) con il certificato CA Let's Encrypt. Consulta il nostro tutorial Postfix/Bind/Let's Encrypt (articolo 2 di questa serie) per la configurazione dell'hook di rinnovo automatico

Errore 3: TLSA pubblicato con il nome DNS sbagliato

Sintomo: "no TLSA records found" anche se hai creato il record. È l'errore più comune tra i principianti DANE.

Diagnosi:

# Trovare l'hostname MX
dig MX captaindns.com +short
# Risultato: 10 mail.captaindns.com.

# Verificare il TLSA nel posto giusto (hostname MX)
dig TLSA _25._tcp.mail.captaindns.com +short

# Errore tipico: TLSA pubblicato sul dominio invece che sul MX
dig TLSA _25._tcp.captaindns.com +short
# Questo TLSA viene IGNORATO dai server mittenti

Causa: confusione tra il dominio (captaindns.com) e l'hostname MX (mail.captaindns.com). Il TLSA deve essere pubblicato su _25._tcp.<hostname-MX>, conformemente alla RFC 7672 sezione 2.1.1.

Correzione: pubblica il TLSA su _25._tcp.mail.captaindns.com (o l'hostname restituito dal tuo record MX). Se il tuo dominio ha più MX, ogni hostname deve avere il proprio TLSA.

Errore 4: STARTTLS non disponibile o mal configurato

Sintomo: DANE è configurato lato DNS ma il server non propone STARTTLS, o il certificato presentato non corrisponde all'hostname. I log mostrano "TLS handshake failed" o "certificate hostname mismatch".

Diagnosi:

# Testare se STARTTLS è offerto
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp -verify 5

# Verificare il Common Name e i SAN del certificato
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Cause frequenti:

• smtpd_tls_cert_file punta a un file sbagliato in Postfix
• Il certificato non contiene l'hostname MX nei Subject Alternative Names
• Il firewall blocca STARTTLS o la porta 25 non è accessibile in TLS

Correzione: in Postfix, verifica che smtpd_tls_security_level sia almeno may e che i percorsi dei certificati siano corretti:

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

Errore 5: propagazione DNS incompleta

Sintomo: DANE funziona in modo intermittente. Alcuni server mittenti validano il TLSA, altri segnalano un errore. Il problema compare spesso dopo un aggiornamento DNS recente.

Diagnosi:

# Confrontare le risposte tra server NS
dig TLSA _25._tcp.mail.captaindns.com @ns1.captaindns.com +short
dig TLSA _25._tcp.mail.captaindns.com @ns2.captaindns.com +short

# Verificare il TTL restante
dig TLSA _25._tcp.mail.captaindns.com +noall +answer

Cause frequenti:

• Trasferimento di zona incompleto tra server DNS primario e secondario
• TTL elevato sul vecchio record (le cache DNS mantengono il valore precedente)
• Un server NS non risponde o restituisce una versione obsoleta della zona

Correzione: verifica che tutti i tuoi server NS restituiscano lo stesso valore TLSA. Se hai appena aggiornato il TLSA, attendi la scadenza del TTL precedente prima di eliminare il vecchio record. Per le rotazioni di certificato, pubblica il nuovo TLSA 2x TTL prima della rotazione effettiva.

Monitorare DANE in produzione

Correggere un errore puntuale non basta. I 3 meccanismi di sorveglianza seguenti prevengono gli incidenti ricorrenti.

TLS-RPT: attiva i report TLS-RPT (RFC 8460) per ricevere le segnalazioni di fallimento DANE da parte dei server mittenti. Il campo failure-type nel report JSON indica con precisione il tipo di errore:

Monitoraggio certificato: configura un avviso 14 giorni prima della scadenza del certificato TLS. Il rinnovo Let's Encrypt avviene automaticamente, ma l'hook TLSA può fallire silenziosamente.

Verifica automatica: pianifica una verifica quotidiana con il nostro DANE TLSA Syntax Checker o uno script cron che confronta l'hash pubblicato con il certificato attivo:

#!/bin/bash
# Verifica quotidiana 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 "AVVISO: l'hash TLSA diverge dal certificato attivo" | \
    mail -s "DANE TLSA mismatch" admin@captaindns.com
fi

Piano d'azione consigliato

1. Diagnosticare: usa la metodologia in 5 passaggi qui sopra o il nostro DANE TLSA Checker per identificare il problema
2. Identificare: classifica l'errore in una delle 5 categorie (DNSSEC, hash, nome DNS, STARTTLS, propagazione)
3. Correggere: applica la soluzione corrispondente con i comandi forniti
4. Verificare: testa la correzione con dig +dnssec e openssl s_client prima di considerare il problema risolto
5. Prevenire: implementa TLS-RPT, il monitoraggio certificato e la verifica automatica

📚 Guide DANE/TLSA correlate

• DANE/TLSA: la guida completa per autenticare i certificati email via DNS: funzionamento, anatomia TLSA, usi consigliati e confronto con MTA-STS
• Configurare DANE/TLSA con Postfix, Bind e Let's Encrypt: tutorial passo passo con comandi copiabili, automazione del rinnovo e verifica
• Implementare DANE per Exchange Online e Microsoft 365

Fonti

• 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