Cosa verifica questo ispettore DANE TLSA?
Un record TLSA desincronizzato dal certificato blocca la posta in arrivo. Questo strumento rileva il problema prima che i tuoi mittenti lo facciano.
L'analisi copre cinque livelli della configurazione DANE:
- Risoluzione MX: Identifica i server mail del dominio
- Ricerca TLSA: Interroga
_25._tcp.hostnameper i record TLSA - Verifica DNSSEC: Controlla che la catena di firme sia completa fino alla root
- Validazione sintassi: Verifica la conformità RFC 6698/7672
- Corrispondenza certificato: Confronta i dati TLSA con il certificato server attuale
Comprendere i record DANE TLSA
Posizione DNS
Il posizionamento DNS è la causa più frequente di errore DANE. I record TLSA vanno pubblicati sull'hostname del server MX, non sul dominio:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af2e2b295b...
Importante: L'hostname deve essere quello del server MX, non il dominio. Se captaindns.com ha come MX mail.captaindns.com, il TLSA va a _25._tcp.mail.captaindns.com.
Struttura del record
| Campo | Valori | Significato |
|---|---|---|
| Certificate Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Tipo di vincolo |
| Selector | 0 (Cert), 1 (SPKI) | Parte del certificato confrontata |
| Matching Type | 0 (Full), 1 (SHA-256), 2 (SHA-512) | Metodo di confronto |
| Certificate Data | Esadecimale | Hash o dati completi |
Configurazione consigliata per SMTP
3 1 1 <sha256-hash>
- Usage 3 (DANE-EE): Non serve la validazione PKIX
- Selector 1 (SPKI): Sopravvive ai rinnovi con la stessa chiave
- Matching Type 1 (SHA-256): Compatto e sicuro
Il ruolo di DNSSEC
Senza DNSSEC, DANE non esiste. I record TLSA non firmati vengono ignorati da qualsiasi MTA conforme alla RFC 7672.
Catena di fiducia
Root DNS (.) → TLD (.com) → Dominio (captaindns.com) → TLSA record
DNSSEC DNSSEC DNSSEC Firmato
Ogni livello della gerarchia DNS deve essere firmato. Se un anello manca, i record TLSA vengono considerati non autenticati e ignorati.
Cosa verifica il nostro strumento
| Verifica | Descrizione | Impatto in caso di fallimento |
|---|---|---|
| Zona firmata | Il dominio ha chiavi DNSSEC | Record TLSA ignorati |
| Catena valida | Le firme sono verificabili | Record TLSA ignorati |
| Firma non scaduta | Le RRSIG sono ancora valide | Record TLSA ignorati temporaneamente |
Problemi comuni rilevati
Ecco i quattro problemi che il nostro checker rileva più frequentemente e come correggerli.
Nessun record TLSA trovato
Causa: Il dominio non ha configurato DANE Impatto: Nessuna protezione DANE per la posta in arrivo Correzione: Genera un record DANE TLSA e pubblicalo nel DNS
DNSSEC assente
Causa: Il dominio non è firmato DNSSEC Impatto: I record TLSA vengono ignorati anche se esistono Correzione: Attiva DNSSEC presso il tuo registrar e poi presso il tuo hosting DNS
Hash del certificato desincronizzato
Causa: Il certificato TLS è stato rinnovato senza aggiornamento del TLSA Impatto: I MTA DANE-aware rifiutano la connessione o tornano all'opportunistico Correzione: Aggiorna l'hash TLSA con il nuovo certificato. Usa DANE-TA (usage 2) o SPKI selector (1) con riutilizzo della chiave per evitare questo problema.
TLSA nella posizione sbagliata
Causa: Record pubblicato per il dominio anziché per il server MX
Impatto: I server mittenti non trovano il record
Correzione: Pubblica a _25._tcp.<hostname-mx>, non a _25._tcp.<dominio>
Strategia di rotazione del certificato con DANE
La scadenza del certificato è la causa numero 1 dei fallimenti DANE. Pianifica la rotazione fin dal primo deployment. Tre strategie possibili:
Strategia 1: DANE-TA (consigliata per Let's Encrypt)
Vincola il certificato CA anziché il certificato server:
2 0 1 <sha256-del-certificato-CA>
Vantaggio: Il TLSA resta valido finché la stessa CA firma i tuoi certificati. Svantaggio: Meno rigido di un vincolo diretto.
Strategia 2: DANE-EE con riutilizzo della chiave
Mantieni la stessa chiave privata tra i rinnovi:
3 1 1 <sha256-della-chiave-pubblica>
Vantaggio: Vincolo forte + sopravvive ai rinnovi.
Svantaggio: Richiede di configurare il riutilizzo della chiave (es: --reuse-key in Certbot).
Strategia 3: Doppio record (rollover)
Pubblica entrambi i TLSA prima della rotazione:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-certificato-attuale>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-certificato-futuro>
Dopo la rotazione, rimuovi il vecchio.
DANE e SMTP: protezione della posta in transito
Il TLS opportunistico non verifica il certificato del destinatario. DANE cambia questa situazione radicalmente.
Come funziona DANE per SMTP
- Il server mittente risolve il MX di
captaindns.com - Cerca i record TLSA per il server MX
- Verifica che la risposta TLSA sia firmata DNSSEC
- Si connette in STARTTLS e confronta il certificato con i dati TLSA
- Se il certificato corrisponde, la connessione sicura è confermata
- In caso contrario, rifiuta la consegna (a differenza del TLS opportunistico)
Differenza con il TLS opportunistico
| Aspetto | TLS opportunistico | DANE |
|---|---|---|
| Verifica certificato | Nessuna (accetta tutto) | Tramite record TLSA |
| Protezione MITM | No | Sì |
| Fallback non-TLS | Sì | No (di default) |
| Prerequisito | Nessuno | DNSSEC |
FAQ - Domande frequenti
D: Cosa verifica il DANE TLSA Checker?
R: Il nostro checker effettua un lookup DNS dei record TLSA sul tuo dominio, valida la sintassi, verifica lo stato della firma DNSSEC, controlla la corrispondenza con il certificato del server mail, e segnala i problemi di configurazione.
D: Perché il mio DANE TLSA check fallisce?
R: Cause comuni: DNSSEC assente sul dominio, record TLSA non pubblicati nella posizione corretta (_25._tcp.mail.captaindns.com), hash del certificato desincronizzato dopo il rinnovo, o combinazione usage/selector/matching type errata.
D: Qual è il nome DNS corretto per i record TLSA SMTP?
R: I record TLSA SMTP devono essere pubblicati a _porta._protocollo.hostname, tipicamente _25._tcp.mail.captaindns.com. L'hostname deve essere quello del server MX di destinazione, non il dominio stesso.
D: Come protegge DANE la posta in transito?
R: DANE impedisce gli attacchi man-in-the-middle sulle connessioni SMTP permettendo al server mittente di verificare il certificato TLS tramite DNS/DNSSEC anziché dipendere unicamente dalle autorità di certificazione.
D: Con quale frequenza verificare i miei record DANE TLSA?
R: Verifica dopo ogni rinnovo del certificato TLS, dopo qualsiasi modifica DNS, e mensilmente. La scadenza del certificato è la causa numero 1 dei fallimenti DANE.
D: DANE funziona con i certificati Let's Encrypt?
R: Sì, ma pianifica i rinnovi ogni 90 giorni. DANE-TA (usage 2) con il certificato CA di Let's Encrypt è più facile. DANE-EE (usage 3) con riutilizzo della chiave (--reuse-key in Certbot) funziona altrettanto bene.
Strumenti complementari
| Strumento | Utilità |
|---|---|
| DANE TLSA Validator | Validare la sintassi prima della pubblicazione |
| DANE TLSA Generator | Creare un record TLSA da un certificato |
| Ispettore MTA-STS | Verificare la policy MTA-STS (sicurezza TLS alternativa) |
| Ispettore TLS-RPT | Monitorare i fallimenti TLS tramite i report |
| SMTP Check | Verificare la connessione STARTTLS che DANE protegge |
| Audit dominio email | Audit completo dell'autenticazione email |
Risorse utili
- RFC 6698 - DANE TLSA (specifica originale)
- RFC 7671 - Updates to DANE (aggiornamenti operativi)
- RFC 7672 - SMTP Security via DANE (DANE per SMTP)
- Microsoft - DANE with DNSSEC (guida Exchange Online)
- Let's Encrypt - Using DANE (consigli DANE con LE)