Perché verificare il tuo DANE TLSA
Il trasporto SMTP in TLS opportunistico lascia la porta aperta a due scenari silenziosi: un attaccante in posizione intermedia che rimuove STARTTLS per forzare il testo in chiaro, o un certificato falso accettato da un MTA mittente che non sa distinguere quello vero dal falso. DANE chiude questa falla pubblicando un hash del certificato atteso nel DNS, firmato DNSSEC.
Ma DANE è esigente: un record TLSA mal posizionato, una zona non firmata DNSSEC o un hash disallineato dopo il rinnovo del certificato bastano a invalidare silenziosamente il tuo deployment. Nessun messaggio di errore arriva all'MTA mittente: la connessione torna a TLS opportunistico senza rumore e il tuo flusso SMTP perde la protezione che credevi di avere.
Verificare il tuo DANE TLSA in tempo reale diventa indispensabile:
- Dopo la pubblicazione iniziale: confermare che il record si risolve, è firmato DNSSEC e l'hash corrisponde al certificato servito
- Dopo ogni rinnovo di certificato: la causa numero 1 dei guasti DANE è il disallineamento hash/certificato
- Audit di sicurezza email: validare che DANE copra tutti gli MX e che nessun bordo resti in TLS opportunistico
- Prima della migrazione del fornitore di posta: Microsoft 365, Google Workspace e i provider tradizionali non offrono lo stesso livello di supporto di DANE
Come usare questo checker in 3 passi
Passo 1: inserire il dominio da analizzare
Inserisci il dominio di posta così come appare nei tuoi indirizzi email:
captaindns.com(dominio principale)marketing.captaindns.com(sottodominio se gestisci più zone)
Lo strumento enumera automaticamente gli MX, poi interroga _25._tcp.<host-mx> per ognuno. La validazione DNSSEC risale la catena completa fino alla radice.
Passo 2: leggere i risultati per MX
Il checker mostra, per ogni MX:
| Elemento | Descrizione |
|---|---|
| Stato DNSSEC | La zona dell'host MX è firmata e la catena di fiducia completa? |
| Record TLSA | Contenuto grezzo pubblicato su _25._tcp.<host> |
| Usage / selector / matching | Decomposizione dei tre primi campi con il loro significato |
| Hash pubblicato | Dati esadecimali da confrontare con il certificato servito |
| Certificato STARTTLS | Certificato servito sulla porta 25 e il suo hash calcolato |
| Corrispondenza | L'hash pubblicato corrisponde byte per byte al certificato presentato? |
Passo 3: applicare le correzioni
Le diagnosi sono classificate per gravità:
- Bloccante: DNSSEC assente, TLSA non trovato, hash disallineato. Il deployment DANE non protegge nessuno nello stato attuale.
- Avvertimento: combinazione non raccomandata (usage 0 o 1 senza CA controllata), matching type 0 che pubblica il certificato grezzo, TTL anormalmente lungo.
- Info: MX senza supporto DANE atteso (Google Workspace), record multipli compatibili con una rotazione di chiave in corso.
Correggi la zona DNS, attendi la propagazione (TTL), poi rilancia il checker per confermare.
Anatomia di un record TLSA
Il record TLSA viene pubblicato in una posizione precisa e contiene quattro campi rigorosamente specificati dalla RFC 6698.
Posizione DNS
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af2e2b295b...
L'owner name segue il modello _<porta>._<protocollo>.<host>. Per SMTP in entrata è invariabilmente _25._tcp.<host-mx>. Pubblicare il record sull'apex del dominio anziché sul nome dell'host MX è l'errore più frequente: nessun MTA lo trova.
I quattro campi
| Campo | Valori | Significato |
|---|---|---|
| Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Ancoraggio di fiducia |
| Selector | 0 (cert completo), 1 (SubjectPublicKeyInfo) | Parte hashata |
| Matching type | 0 (grezzo), 1 (SHA-256), 2 (SHA-512) | Algoritmo |
| Dato | esadecimale | Hash o blocco binario |
La combinazione raccomandata per SMTP
3 1 1 resta lo standard di fatto:
- Usage 3 (DANE-EE): la fiducia è ancorata nella tua chiave, indipendentemente da qualsiasi autorità di certificazione
- Selector 1 (SPKI): il record resta valido finché la chiave pubblica viene conservata, anche dopo il rinnovo del certificato
- Matching type 1 (SHA-256): 32 byte, supportato universalmente, sufficientemente robusto
DNSSEC: il prerequisito imprescindibile
Senza DNSSEC, un record TLSA viene ignorato da qualsiasi MTA conforme. Il checker impone esplicitamente un tetto al punteggio a 30/100 non appena la catena DNSSEC è rotta o assente.
Catena di fiducia da validare
Radice (.) -> TLD (.com) -> Dominio (captaindns.com) -> _25._tcp.mail.captaindns.com
DNSSEC DNSSEC DNSSEC Firmato
Ogni anello deve essere firmato. Una zona padre non firmata invalida tutto ciò che segue, indipendentemente dalla qualità del record TLSA a valle. Il checker risale la catena e identifica l'anello difettoso.
Trappole comuni legate a DNSSEC
- Zona del dominio firmata ma non la zona dell'host MX: se i tuoi MX puntano a un sottodominio su una zona separata, è quella zona a dover essere firmata.
- Record DS mancanti presso il registrar: la zona firmata localmente resta invisibile per i resolver esterni se il DS non è stato pubblicato presso il TLD.
- RRSIG scadute: le firme DNSSEC hanno una durata di validità. Un rinnovo fallito mette la zona in stato bogus.
Il checker indica quale di questi casi è in gioco.
Strategie di rotazione di chiave
La rotazione di certificato senza interruzione di servizio è la principale sfida operativa di DANE. Coesistono tre strategie.
Strategia 1: selector SPKI + riutilizzo della chiave
Con --reuse-key (Certbot) o un --key-type rsa condiviso, la chiave pubblica resta identica tra i rinnovi. L'hash SPKI non cambia e il record 3 1 1 <hash-spki> resta valido a tempo indeterminato. È la strategia più semplice.
Strategia 2: DANE-TA sull'autorità di certificazione
2 0 1 <sha256-del-certificato-CA>
Ancori il certificato radice della tua CA (per esempio Let's Encrypt ISRG Root X1) anziché il tuo certificato. Vantaggio: nessun aggiornamento DNS al rinnovo. Svantaggio: fiducia delegata alla CA, quindi meno rigoroso di DANE-EE.
Strategia 3: record doppio durante la transizione
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-chiave-attuale>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-chiave-successiva>
Pubblica l'hash della chiave successiva 7 giorni prima della rotazione (almeno il doppio del TTL massimo). Gli MTA conformi accettano una connessione se almeno un record corrisponde al certificato presentato. Dopo la rotazione, rimuovi l'hash vecchio.
Il checker riconosce la presenza di record multipli e li etichetta come rotazione di chiave in corso anziché come errore.
DANE e SMTP: cosa accade alla consegna
- Il server mittente risolve gli MX di
captaindns.com - Interroga
_25._tcp.<mx>per recuperare il record TLSA - Valida la catena DNSSEC fino alla radice
- Apre STARTTLS sulla porta 25 e recupera il certificato presentato
- Calcola l'hash del certificato secondo il matching type pubblicato
- Se l'hash corrisponde: connessione sicura confermata
- Altrimenti: rifiuto di consegna (differenza fondamentale rispetto al TLS opportunistico)
DANE vs TLS opportunistico
| Aspetto | TLS opportunistico | DANE |
|---|---|---|
| Verifica certificato | Nessuna (accetta tutto) | Hash firmato DNSSEC obbligatorio |
| Protezione MITM | No | Sì |
| Fallback non TLS | Sì (degrado silenzioso) | No |
| Prerequisito | Nessuno | DNSSEC sulla zona dell'MX |
Diagnosi comuni e soluzioni
Nessun record TLSA trovato
Causa: il dominio non ha configurato DANE, o il record è pubblicato nella posizione sbagliata.
Soluzione: genera e pubblica un record TLSA su _25._tcp.<host-mx>. La nostra guida di installazione DANE TLSA per Postfix, BIND e Let's Encrypt copre il deployment passo passo.
DNSSEC assente o rotto
Causa: la zona non è firmata, o i DS non sono stati pubblicati presso il registrar.
Soluzione: attiva DNSSEC presso il tuo provider DNS, esporta i DS e pubblicali presso il tuo registrar. Verifica la propagazione con uno strumento DNSSEC dedicato prima di rilanciare questo checker.
Hash di certificato disallineato
Causa: il certificato TLS è stato rinnovato e l'hash pubblicato non è più aggiornato.
Soluzione: usa il selector SPKI (1) con --reuse-key per rendere il record invariante rispetto ai rinnovi. In mancanza, aggiorna subito l'hash e adotta la strategia del record doppio per le prossime rotazioni.
TLSA nella posizione sbagliata
Causa: record pubblicato sul dominio radice anziché sul nome dell'host MX, o sulla porta sbagliata.
Soluzione: ripubblica esattamente su _25._tcp.<host-mx>. Per un MX mail.captaindns.com, è _25._tcp.mail.captaindns.com. Nient'altro.
Microsoft 365 / Google Workspace senza DANE in entrata
Causa: questi provider non firmano le loro zone DNS, quindi DANE non è applicabile sul lato in entrata.
Soluzione: distribuisci MTA-STS al posto di DANE per questi provider. MTA-STS si appoggia su HTTPS anziché DNSSEC ed è supportato da Google Workspace e Microsoft 365.
DANE e MTA-STS: approcci complementari
I due protocolli formano una difesa in profondità, non una scelta esclusiva.
| Criterio | DANE | MTA-STS |
|---|---|---|
| Meccanismo | DNSSEC + record TLSA | HTTPS + policy testuale |
| Dipendenza | DNSSEC richiesto | HTTPS richiesto |
| Fiducia | Crittografica (DNS firmato) | PKI (CA HTTPS) |
| Supporto Postfix / Exim | Eccellente | Buono |
| Supporto Microsoft 365 | Parziale (in uscita 2022, in entrata 2024) | Completo |
| Supporto Google Workspace | Nessuno (zone non firmate) | Completo |
| Deployment | Complesso (DNSSEC) | Più semplice |
Raccomandazione: distribuisci entrambi. DANE per i domini ospitati su Postfix o Exim, MTA-STS per i domini delegati a Microsoft 365 o Google Workspace. La copertura massima impone la combinazione.
Strumenti complementari e risorse
| Strumento | Utilità |
|---|---|
| Validatore DANE TLSA | Validare la sintassi di un record PRIMA della pubblicazione DNS |
| Generatore DANE TLSA | Creare un record TLSA a partire da un certificato o una chiave |
| MTA-STS Checker | Verificare la policy MTA-STS complementare |
| TLS-RPT Checker | Monitorare i fallimenti TLS tramite i report |
| Ispettore DMARC | Completare l'autenticazione email |
| Audit email-authentication | Panoramica degli strumenti di autenticazione email |
Guide collegate
- DANE TLSA: la guida completa - Comprendere DANE da estremo a estremo, da DNSSEC al deployment SMTP.
- DANE TLSA su Postfix, BIND e Let's Encrypt - Installazione passo passo con rotazione di chiave.
- DANE TLSA e Microsoft 365 Exchange Online - Supporto di DANE in entrata e in uscita su Exchange Online.
- DANE TLSA: 12 casi pratici di risoluzione - Diagnosi e risoluzione degli incidenti DANE.
- MTA-STS vs DANE: confronto dettagliato - Scegliere o combinare i due protocolli.
Specifiche
- RFC 6698 - DANE TLSA (specifica originale)
- RFC 7671 - Updates to DANE (chiarimenti operativi)
- RFC 7672 - SMTP Security via DANE (DANE per SMTP)