DANE/TLSA: la guida completa per autenticare i certificati email via DNS
Di CaptainDNS
Pubblicato il 21 febbraio 2026
- DANE lega i certificati TLS ai nomi di dominio tramite record DNS TLSA firmati con DNSSEC, eliminando la dipendenza dalle autorità di certificazione
- L'uso DANE-EE con SPKI e SHA-256 (
3 1 1) è il gold standard per proteggere SMTP - DNSSEC è un prerequisito assoluto: senza una zona firmata, i record TLSA vengono ignorati
- DANE e MTA-STS sono complementari: DANE verifica il certificato via DNS, MTA-STS impone TLS via HTTPS
- TLS-RPT (RFC 8460) permette di monitorare i fallimenti DANE in produzione e anticipare i problemi di rotazione
Quando un server SMTP invia un'email, come fa a sapere che il server destinatario è quello giusto? Di default, non lo sa. STARTTLS cifra la connessione in modo opportunistico, ma non verifica né l'identità del server né l'autenticità del certificato. Un attaccante posizionato sulla rete può intercettare la connessione, presentare un certificato falso e leggere i tuoi messaggi.
DANE (DNS-based Authentication of Named Entities) risolve questo problema pubblicando direttamente nel DNS le informazioni di certificato attese. Il server mittente consulta il record TLSA, verifica che il certificato presentato corrisponda, e rifiuta la connessione in caso di discrepanza. Il punto chiave: DNSSEC firma queste informazioni, garantendo che non siano state falsificate.
Questa guida copre il funzionamento di DANE, l'anatomia di un record TLSA, gli utilizzi consigliati per l'email, il deploy passo dopo passo, la complementarità con MTA-STS e il monitoraggio tramite TLS-RPT. È rivolta ad amministratori email, ingegneri infrastruttura e DevOps che gestiscono server di posta.
Come funziona DANE?
Il problema del TLS opportunistico
SMTP è stato progettato senza crittografia. STARTTLS è stato aggiunto successivamente (RFC 3207) per permettere ai server di negoziare una connessione TLS. Ma questa negoziazione è opportunistica: se il server remoto non supporta TLS, il messaggio parte in chiaro. Peggio ancora, un attaccante può rimuovere il comando STARTTLS dalla risposta SMTP (attacco downgrade) e forzare l'invio senza crittografia.
Anche quando TLS viene negoziato, il server mittente non verifica il certificato di default. Accetta qualsiasi certificato, incluso un certificato auto-firmato presentato da un attaccante. La crittografia c'è, ma l'autenticazione manca.
DANE: il certificato nel DNS
DANE inverte la logica. Invece di affidarsi a un'autorità di certificazione (CA) esterna, il proprietario del dominio pubblica nel DNS l'impronta del certificato che il suo server deve presentare. Il server mittente:
- Risolve il MX del dominio destinatario
- Cerca il record TLSA associato al server MX
- Verifica la firma DNSSEC della risposta
- Stabilisce la connessione TLS e confronta il certificato presentato con l'impronta TLSA
- Rifiuta la connessione se il certificato non corrisponde
La catena di fiducia DNSSEC
DANE funziona solo se la zona DNS è firmata con DNSSEC. Senza DNSSEC, un attaccante potrebbe falsificare il record TLSA e presentare la propria impronta di certificato. La catena di fiducia va dalla root DNS fino al record TLSA:
. (root) → com. → captaindns.com. → _25._tcp.mail.captaindns.com. TLSA
Ogni anello è firmato dalla zona padre. Se un solo anello è rotto (zona non firmata, firma scaduta), la validazione DNSSEC fallisce e il record TLSA viene ignorato.
Anatomia di un record TLSA
Un record TLSA è composto da quattro campi:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...
Il nome segue la convenzione _porta._protocollo.hostname. Per un server SMTP sulla porta 25, è _25._tcp.mail.captaindns.com.
Usage (campo 1): cosa verificare?
| Valore | Nome | Descrizione |
|---|---|---|
| 0 | PKIX-TA | Verifica il certificato CA + la catena CA classica |
| 1 | PKIX-EE | Verifica il certificato server + la catena CA classica |
| 2 | DANE-TA | Verifica il certificato CA, senza richiedere la catena CA classica |
| 3 | DANE-EE | Verifica il certificato server direttamente, senza CA |
Selector (campo 2): quale parte del certificato?
| Valore | Nome | Descrizione |
|---|---|---|
| 0 | Cert | Certificato completo (DER) |
| 1 | SPKI | Solo la chiave pubblica (SubjectPublicKeyInfo) |
SPKI (1) è consigliato: la chiave pubblica non cambia quando rinnovi il certificato con la stessa coppia di chiavi. Questo semplifica la rotazione.
Matching type (campo 3): formato dei dati
| Valore | Nome | Descrizione |
|---|---|---|
| 0 | Full | Dati grezzi completi |
| 1 | SHA-256 | Hash SHA-256 (32 byte, 64 caratteri hex) |
| 2 | SHA-512 | Hash SHA-512 (64 byte, 128 caratteri hex) |
SHA-256 (1) è lo standard: compatto, resistente alle collisioni, supportato ovunque.
Quale usage TLSA scegliere?
DANE-EE (usage 3): la scelta consigliata per SMTP
La RFC 7672 (sezione 3.1) raccomanda DANE-EE per l'email. La combinazione 3 1 1 (DANE-EE + SPKI + SHA-256) è il gold standard:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...
Vantaggi di DANE-EE:
- Nessuna dipendenza dalle CA: controlli interamente la fiducia
- Certificati auto-firmati accettati: la CA non deve essere riconosciuta
- Rotazione semplificata: con SPKI, l'hash non cambia se conservi la stessa chiave
- Nessuna verifica della catena: conta solo il certificato end-entity
DANE-TA (usage 2): quando usare la CA?
DANE-TA (2 0 1 o 2 1 1) è utile quando gestisci diversi server firmati dalla stessa CA interna. Invece di pubblicare un TLSA per ogni server, pubblichi l'impronta della CA e tutti i certificati firmati da essa vengono accettati.
Svantaggio: se la CA viene compromessa, tutti i server sono compromessi.
PKIX-EE e PKIX-TA (usage 1 e 0): casi particolari
Questi usage combinano la verifica DANE con la validazione CA classica. Sono usati raramente per SMTP perché aggiungono complessità senza un beneficio chiaro rispetto a DANE-EE.
DANE per l'email: RFC 7672
La RFC 7672 adatta DANE al contesto SMTP. Alcune specificità:
STARTTLS e la porta 25
Per l'email, DANE si applica sulla porta 25 con STARTTLS (non sulla porta 465 con TLS implicito). Il server mittente avvia una connessione SMTP classica, invia EHLO, riceve il comando 250-STARTTLS, poi negozia TLS. È in quel momento che confronta il certificato presentato con il record TLSA.
Denominazione TLSA per i server MX
Il nome del record TLSA è costruito a partire dall'hostname MX, non dal dominio dell'email:
# Email destinata a user@captaindns.com
# MX di captaindns.com → mail.captaindns.com
# TLSA → _25._tcp.mail.captaindns.com
Se il dominio ha diversi MX, ogni MX deve avere il proprio record TLSA.
Risoluzione: dal dominio al certificato
Il flusso completo per un'email verso user@captaindns.com:
- Risolvere
captaindns.com→ MX →mail.captaindns.com(validare DNSSEC) - Risolvere
_25._tcp.mail.captaindns.com→ TLSA (validare DNSSEC) - Risolvere
mail.captaindns.com→ A/AAAA (validare DNSSEC) - Connessione TCP → SMTP → STARTTLS → Verificare il certificato rispetto al TLSA
- Se il certificato corrisponde: consegnare. Altrimenti: rifiutare.
Implementare DANE in 6 step
1. Attivare DNSSEC sulla tua zona
È il prerequisito assoluto. Contatta il tuo registrar o il tuo provider DNS per attivare DNSSEC. Verifica che la catena di fiducia sia completa con uno strumento come dig +dnssec o il verificatore DNSSEC CaptainDNS.
2. Generare il record TLSA
Genera il tuo record con uno strumento dedicato (vedi il CTA a fine articolo). Fornisci il tuo certificato PEM o lascia che lo strumento lo recuperi via STARTTLS. Scegli la combinazione 3 1 1 (DANE-EE, SPKI, SHA-256).
3. Pubblicare nel DNS
Aggiungi il record nella tua zona:
_25._tcp.mail.captaindns.com. 3600 IN TLSA 3 1 1 a0b1c2d3e4f5678901234567890abcdef0123456789abcdef0123456789abcdef
4. Verificare la configurazione
Dopo la propagazione (rispetta il TTL), verifica che tutto sia a posto: record TLSA risolto, DNSSEC valido, certificato corrispondente. L'ispettore a fine articolo permette questo controllo in pochi secondi.
5. Attivare TLS-RPT
Pubblica un record TLS-RPT per ricevere i report di fallimento:
_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
6. Pianificare la rotazione dei certificati
È il punto critico. Quando rinnovi il certificato:
- Con la stessa chiave (selector SPKI): l'hash non cambia, nulla da fare
- Con una nuova chiave: pubblica il nuovo TLSA prima di distribuire il nuovo certificato. Mantieni entrambi i record durante il periodo di transizione.
DANE e MTA-STS: complementarità, non concorrenza
DANE e MTA-STS proteggono entrambi contro gli attacchi al trasporto SMTP, ma con meccanismi diversi.
Cosa fa DANE che MTA-STS non fa
- Verifica il certificato via DNS: nessuna dipendenza dalle CA
- Accetta i certificati auto-firmati: il DNS fa autorità
- Resiste alla compromissione di una CA: conta solo il DNS del dominio
Cosa fa MTA-STS che DANE non fa
- Funziona senza DNSSEC: utilizza HTTPS come canale autenticato
- Deploy più semplice: un file di testo su un server web
- Modalità testing: permette di monitorare prima di imporre
La strategia ideale: entrambi
Implementare DANE e MTA-STS contemporaneamente copre entrambi i casi:
- I server che supportano DANE usano la verifica TLSA
- I server che supportano solo MTA-STS usano la policy HTTPS
- I server che supportano entrambi hanno una doppia protezione
Monitorare DANE con TLS-RPT
TLS-RPT (RFC 8460) è il compagno indispensabile di DANE in produzione. I report JSON giornalieri includono i fallimenti specifici di DANE:
dane-required: il server mittente richiede DANE ma non trova un TLSA validotlsa-invalid: il record TLSA è malformatodnssec-invalid: la validazione DNSSEC è fallitadane-policy-failure: il certificato non corrisponde al record TLSA
Senza TLS-RPT, non sapresti che un rinnovo di certificato ha rotto la corrispondenza TLSA. Consulta la nostra guida completa TLS-RPT per l'implementazione.
🎯 Piano d'azione consigliato
- Verifica il tuo DNSSEC: la tua zona deve essere firmata con una catena di fiducia completa
- Scegli l'usage
3 1 1: DANE-EE + SPKI + SHA-256, lo standard per SMTP - Genera e pubblica il TLSA: usa il generatore, pubblica, attendi la propagazione
- Valida con l'ispettore: verifica TLSA + DNSSEC + corrispondenza certificato
- Attiva TLS-RPT: ricevi i report di fallimento per anticipare i problemi
- Documenta la rotazione: procedura di rinnovo certificato con aggiornamento TLSA
Verifica la tua configurazione DANE adesso: usa il nostro ispettore DANE/TLSA per analizzare la configurazione DANE del tuo dominio in pochi secondi. Hai bisogno di creare un record? Il generatore DANE/TLSA produce un record TLSA pronto da pubblicare.
FAQ
Cos'è DANE e come funziona?
DANE (DNS-based Authentication of Named Entities) è uno standard internet (RFC 6698) che permette di pubblicare nel DNS le informazioni di certificato TLS attese per un server. Il server mittente consulta il record TLSA, verifica la firma DNSSEC, poi confronta il certificato presentato dal server con l'impronta pubblicata. Se il certificato non corrisponde, la connessione viene rifiutata.
Qual è la differenza tra DANE e MTA-STS?
DANE utilizza DNSSEC e i record TLSA per autenticare i certificati. MTA-STS utilizza HTTPS e le autorità di certificazione. DANE offre una sicurezza superiore (nessuna dipendenza dalle CA) ma richiede DNSSEC. MTA-STS è più semplice da implementare. I due meccanismi sono complementari e possono coesistere sullo stesso dominio.
DNSSEC è obbligatorio per DANE?
Sì, DNSSEC è un prerequisito assoluto. Senza una zona firmata, i record TLSA non sono affidabili perché un attaccante potrebbe falsificarli. I server mittenti conformi alla RFC 7672 ignorano i TLSA la cui catena DNSSEC non è valida.
Quale usage TLSA scegliere per l'email?
La RFC 7672 raccomanda DANE-EE (usage 3) con SPKI (selector 1) e SHA-256 (matching type 1), ovvero la combinazione 3 1 1. È il gold standard per SMTP: nessuna dipendenza dalle CA, rotazione semplificata con SPKI e massima compatibilità.
DANE funziona con Let's Encrypt?
Sì, DANE funziona con Let's Encrypt. Con DANE-EE e il selector SPKI (3 1 1), l'hash non cambia finché rinnovi il certificato con la stessa chiave privata. Let's Encrypt rinnova ogni 90 giorni, ma se conservi la chiave, il TLSA resta valido. Se rigeneri la chiave, pubblica il nuovo TLSA prima del deploy del certificato.
Quali provider email supportano DANE?
I principali provider che supportano DANE in uscita (verifica DANE in invio) includono Postfix, Gmail (verifica parziale) e diversi ISP europei. Microsoft ha annunciato il supporto DANE per Exchange Online. In ricezione, qualsiasi server con DNSSEC e un TLSA pubblicato è compatibile. L'adozione resta più forte in Europa (Germania, Paesi Bassi) che negli Stati Uniti.
Come monitorare i fallimenti DANE in produzione?
Attiva TLS-RPT (RFC 8460) pubblicando un record DNS _smtp._tls con un indirizzo di ricezione. I server mittenti invieranno report JSON giornalieri con i dettagli dei fallimenti DANE: certificato non corrispondente, DNSSEC non valido, TLSA mancante. Senza TLS-RPT, i fallimenti passano inosservati.
📚 Guide DANE/TLSA correlate
- Configurare DANE/TLSA con Postfix, Bind e Let's Encrypt (in arrivo)
- Risoluzione problemi DANE/TLSA: diagnosticare e correggere gli errori comuni (in arrivo)
- Implementare DANE per un server Exchange o Microsoft 365 (in arrivo)
Fonti
- RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
- RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
- RFC 8460 - SMTP TLS Reporting
- Microsoft - SMTP DNS-Based Authentication of Named Entities (DANE)
