# DANE e DNSSEC per la posta: la cifratura SMTP garantita dal DNS
Table of Contents
Nell'articolo sullo STARTTLS stripping abbiamo visto che tra server di posta la cifratura resta opportunistica e un attaccante può farla sparire. MTA-STS risponde con un file su HTTPS e i certificati delle CA pubbliche. DANE (DNS-based Authentication of Named Entities) risponde in un altro modo: il DNS, firmato con DNSSEC, dichiara quale certificato deve presentare il server di posta, e con la sua stessa presenza segnala che la cifratura è obbligatoria.
Per la posta DANE è definito nella RFC 7672 (SMTP Security via Opportunistic DANE TLS). Non si basa sulla fiducia alla prima connessione, ma richiede DNSSEC.
Due ingredienti: DNSSEC e TLSA
DNSSEC aggiunge al DNS delle firme crittografiche: chi interroga può verificare che una risposta sia autentica. La RFC 7672 è netta su questo punto: senza DNSSEC la ricerca dell'MX è vulnerabile ad attacchi man-in-the-middle e di cache poisoning, e senza DNSSEC non si può verificare in modo sicuro il certificato del server.
Un record TLSA associa a un servizio (host e porta) un certificato o una chiave pubblica. Per un server di posta ricevente il nome del record è formato dalla porta e dal nome dell'host MX:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <impronta SHA-256 della chiave pubblica>I tre numeri sono (RFC 7671):
- 3 (DANE-EE): il certificato del server stesso è confrontato direttamente con il record, senza passare da una CA.
- 1 (SPKI): l'impronta riguarda la sola chiave pubblica (SubjectPublicKeyInfo), non l'intero certificato.
- 1 (SHA-256): l'algoritmo dell'impronta.
La RFC 7672 raccomanda proprio la combinazione 3 1 1 per la posta, e sconsiglia i record con uso del certificato 0 e 1 (PKIX-TA e PKIX-EE). La RFC 7671 aggiunge che l'impronta della sola chiave non cambia quando un certificato viene rinnovato con la stessa chiave, e che con DANE-EE la data di scadenza del certificato è ignorata: la validità deriva dalle firme DNSSEC del record.
L'impronta si calcola dal certificato in uso (comando provato su un certificato di test):
openssl x509 -in cert.pem -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256 -binary | xxd -p -c 64Il risultato, 64 caratteri esadecimali, va nel campo finale del record.
Un esempio reale
Il server mx.ietf.org pubblica due record TLSA firmati (verificato il 31 ottobre 2026 con dig +dnssec TLSA _25._tcp.mx.ietf.org):
_25._tcp.mx.ietf.org. 295 IN TLSA 3 1 1 E3008A5C0BC1E088..._25._tcp.mx.ietf.org. 295 IN TLSA 3 1 1 292481EEE04F9F5C..._25._tcp.mx.ietf.org. 295 IN RRSIG TLSA 13 5 300 ...Il record RRSIG è la firma DNSSEC. I valori sono troncati qui per leggibilità.
Come protegge dallo stripping
Un mittente che supporta DANE, prima di consegnare, cerca il TLSA dell'host MX validando DNSSEC:
- Se esiste un TLSA firmato correttamente, la RFC 7672 impone che il mittente non consegni mai se non è stata negoziata una sessione TLS con STARTTLS. Un attaccante che cancella
STARTTLSdalle capacità del server ottiene quindi un rifiuto, non un invio in chiaro: lo stesso record firmato prova che il server supporta TLS. - Se il risultato DNS è "insicuro" (la zona non è firmata), DANE non si applica e si resta alla cifratura opportunistica di prima.
- Se la validazione DNSSEC fallisce, la RFC dice che la consegna deve essere rimandata.
L'ultimo punto è anche il rischio principale, come vediamo più avanti.
Come si pubblica DANE per la posta in arrivo
- Firmare con DNSSEC la zona che contiene il nome dell'host MX.
- Pubblicare il TLSA
3 1 1per ogni host MX. - Verificare che il record sia firmato:
dig +dnssec TLSA _25._tcp.mail.example.comSe la zona è firmata, nella risposta compare anche il record RRSIG dei TLSA. Per vedere cosa succede dal lato di un mittente, Postfix include posttls-finger: la sua documentazione indica -l dane per usare il livello DANE, -c per mostrare solo le informazioni TLS e -L summary per un riepilogo in una riga:
posttls-finger -c -l dane -Lsummary mail.example.comSe la tua posta è ospitata da un fornitore, i record sono quelli del nome host MX del fornitore. Exchange Online, per esempio, supporta DANE in ricezione con DNSSEC: dalla documentazione Microsoft, il dominio richiede DNSSEC abilitato e un nuovo record MX verso un host che termina in mx.microsoft, mentre il record TLSA è fornito da Exchange Online.
La regola d'oro: la rotazione delle chiavi
Il TLSA contiene l'impronta della chiave. Se il certificato viene rinnovato con una chiave nuova e il record non è aggiornato, il tuo server non corrisponde più a quanto pubblicato e i mittenti DANE non consegnano. La documentazione di Certbot è chiara: per impostazione predefinita Certbot genera una chiave privata nuova a ogni rinnovo.
Le strade corrette sono due:
- Riusare la stessa chiave a ogni rinnovo. Certbot ha l'opzione
--reuse-key("When renewing, use the same private key as the existing certificate"). L'impronta3 1 1resta valida. - Pubblicare il record della chiave nuova prima di usarla. La RFC 7672 impone di pubblicare due record TLSA (quello della chiave attuale e quello della nuova) prima di usare la chiave nuova; la RFC 7671 precisa di farlo almeno due TTL prima di installarla. Quando la chiave nuova è in uso, si toglie il record vecchio.
Con certificati in scadenza sempre più ravvicinata, fino a 47 giorni, questo passaggio va automatizzato.
I rischi operativi
- DNSSEC non valido. Se per qualsiasi motivo la validazione DNSSEC non riesce, la RFC 7672 impone ai mittenti di rimandare la consegna. Serve monitoraggio sulla validità delle firme.
- TLSA pubblicato per un host che non offre STARTTLS. La RFC vieta la consegna senza una sessione TLS negoziata: la posta non arriva.
- Nome host MX in una zona non firmata (per esempio di un fornitore): DANE non si applica.
- TTL troppo alti sui TLSA. La RFC 7671 raccomanda TTL abbastanza brevi da limitare disservizi imprevisti, perché i resolver con record vecchi in cache possono far fallire le consegne dopo un cambio di chiave non pianificato.
DANE o MTA-STS?
| MTA-STS | DANE | |
|---|---|---|
| Richiede DNSSEC | No | Sì |
| Come si verifica il server | certificato firmato da una CA fidata, nome corrispondente | impronta pubblicata nel DNS firmato (con 3 1 1 senza CA) |
| Prima connessione | non protetta (la policy va prima ottenuta) | protetta, perché DNSSEC può provare che un record non esiste |
| Cosa pubblicare | due record DNS e un file su HTTPS | zona firmata e record TLSA |
Non si escludono: Exchange Online, per esempio, documenta il supporto sia a DANE sia a MTA-STS. Approfondimento: MTA-STS.
In sintesi
DANE usa DNSSEC per far dichiarare al DNS quale chiave deve presentare il server di posta; la presenza del record firmato rende la cifratura obbligatoria per i mittenti che lo supportano, senza passare dalle CA pubbliche e senza il limite della prima connessione. Il prezzo è la gestione di DNSSEC e delle chiavi: una rotazione fatta male o firme non valide fanno rimandare la consegna della posta.
