Perché usare un validatore offline
Un record TLSA mal formato viene ignorato senza preavviso dagli MTA conformi. Credi che il tuo deployment DANE protegga il tuo flusso SMTP in entrata; in pratica, nessun server mittente verifica nulla. Il guasto è silenzioso fino al prossimo audit, o fino a un incidente di consegna che rivela la falla.
Il validatore di sintassi DANE TLSA analizza il tuo record senza pubblicare né interrogare il DNS. Nessun dato lascia il tuo browser, nessun segnale trapela verso un resolver esterno. Questo approccio offline copre quattro casi d'uso che l'audit in tempo reale non può trattare.
Casi d'uso tipici:
- Prima del deployment: validare una bozza prima della pubblicazione DNS, per evitare un record silenziosamente ignorato.
- Output di generatore: verificare la sintassi di un record prodotto da uno strumento di terze parti, un wiki interno o un modello condiviso.
- Debug offline: riprodurre e correggere un errore senza toccare il DNS pubblico, per esempio in pre-produzione.
- Revisione di configurazione: esaminare un record ricevuto da un partner o esportato da un'infrastruttura cliente prima di applicarlo.
Il validatore applica la specifica RFC 6698 sulla struttura e la RFC 7671 sui vincoli operativi. Nessuna query DNS, nessuna connessione esterna.
Come usare questo validatore in 3 passi
Passo 1: incollare il record TLSA
Copia il valore del tuo record nel campo previsto:
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
Puoi anche incollare la riga completa con l'owner name:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
Il validatore estrae i quattro campi e analizza ciascuno in modo indipendente. In questo passo non viene effettuata alcuna connessione di rete.
Passo 2: leggere il verdetto
I risultati sono classificati per gravità:
- Errore: problema bloccante, il record verrà ignorato o rifiutato dagli MTA conformi
- Avvertimento: combinazione non raccomandata, funzionale ma che ti espone a rischi operativi
- Valido: sintassi conforme alle RFC 6698 e 7671
Ogni messaggio include il campo interessato, il valore non valido e la correzione attesa.
Passo 3: correggere prima della pubblicazione
Adegua il tuo record alle raccomandazioni. Una volta che la sintassi è pulita, pubblica il TXT su _25._tcp.<host-mx> nella zona firmata DNSSEC dell'host MX, attendi la propagazione e conferma in tempo reale con il DANE TLSA Checker.
Validatore o verificatore: quando usare ciascuno strumento
I due strumenti sono complementari. Intervengono in momenti diversi del ciclo di vita di un record TLSA.
| Dimensione | Validatore (questo strumento) | Verificatore |
|---|---|---|
| Momento d'uso | Prima della pubblicazione DNS | Dopo la pubblicazione |
| Risoluzione DNS | Nessuna | Risoluzione _25._tcp.<mx> in tempo reale |
| Verifica DNSSEC | No | Sì, catena completa |
| Confronto del certificato in tempo reale | No | Sì, tramite STARTTLS sulla porta 25 |
| Origine del record | Manuale (incollato) | DNS pubblico |
| Dati inviati al server | Nessuno | Dominio analizzato |
Flusso di lavoro raccomandato:
- Progetta o genera il record, poi usa il validatore per verificare la sintassi
- Pubblica il TXT nella zona DNSSEC dell'host MX, poi attendi la propagazione
- Lancia il verificatore per confermare DNSSEC e la corrispondenza del certificato in tempo reale
Il validatore rileva gli errori di immissione prima della pubblicazione. Il verificatore rileva le derive e conferma che il DNS pubblico servito corrisponde al certificato attualmente presentato tramite STARTTLS.
Anatomia di un record TLSA
Il record TLSA contiene quattro campi rigorosamente specificati.
Struttura generale
_25._tcp.mail.captaindns.com. IN TLSA <usage> <selector> <matching> <dati>
| Campo | Valori | Descrizione |
|---|---|---|
| Usage | 0-3 | Ancoraggio di fiducia |
| Selector | 0-1 | Parte del certificato hashata |
| Matching type | 0-2 | Algoritmo di confronto |
| Dati | hex | Hash o blocco binario |
Usage (campo 1)
| Valore | Nome | Descrizione |
|---|---|---|
| 0 | PKIX-TA | Vincolo CA: il certificato deve essere firmato da questa CA E superare la validazione PKIX |
| 1 | PKIX-EE | Vincolo certificato: corrispondenza esatta + validazione PKIX |
| 2 | DANE-TA | Ancoraggio di fiducia: qualsiasi certificato firmato da questa CA è accettato |
| 3 | DANE-EE | Certificato di dominio: corrispondenza esatta, senza validazione PKIX |
Raccomandazione per SMTP: DANE-EE (3). L'ancoraggio è nella tua chiave, indipendentemente da qualsiasi autorità esterna.
Selector (campo 2)
| Valore | Nome | Descrizione |
|---|---|---|
| 0 | Cert | Certificato completo (DER) |
| 1 | SPKI | SubjectPublicKeyInfo (solo chiave pubblica) |
Raccomandazione: SPKI (1). Il record resta valido finché la chiave pubblica viene conservata, indipendentemente dai rinnovi di certificato.
Matching type (campo 3)
| Valore | Nome | Lunghezza hex attesa |
|---|---|---|
| 0 | Full | Variabile (certificato o chiave grezzi) |
| 1 | SHA-256 | 64 caratteri (32 byte) |
| 2 | SHA-512 | 128 caratteri (64 byte) |
Raccomandazione: SHA-256 (1). Supportato universalmente, sufficientemente robusto, compatto.
La combinazione raccomandata per SMTP
3 1 1 è lo standard di fatto per SMTP DANE.
3 1 1 <sha256-della-spki>
- Usage 3 (DANE-EE): nessuna dipendenza da una CA, ancoraggio diretto nella tua chiave
- Selector 1 (SPKI): invariante rispetto al rinnovo di certificato finché la chiave viene conservata
- Matching type 1 (SHA-256): 32 byte, perfettamente adatto
Le altre combinazioni sono possibili ma sconsigliate:
| Combinazione | Stato | Perché |
|---|---|---|
| 3 1 1 | Raccomandata | Standard SMTP, robusta, invariante ai rinnovi |
| 3 0 1 | Tollerata | Hash sul certificato completo, cambia a ogni rinnovo |
| 2 0 1 | Accettabile | DANE-TA su CA, nessun aggiornamento DNS al rinnovo |
| 2 1 1 | Accettabile | DANE-TA sulla SPKI della CA |
| 3 1 0 | Rifiutata | Matching type 0 espone il certificato grezzo, dimensione DNS enorme |
| 1 x x | Rifiutata in SMTP | PKIX-EE raramente distribuibile lato MTA |
| 0 x x | Rifiutata in SMTP | PKIX-TA inadatta a SMTP |
Il validatore segnala esplicitamente le combinazioni fuori raccomandazione e propone la combinazione standard.
Errori di sintassi comuni e correzioni
Usage fuori intervallo
Causa: valore di usage superiore a 3.
Correzione:
- 4 1 1 2bb183af...
+ 3 1 1 2bb183af...
Selector non valido
Causa: selector diverso da 0 o 1.
Correzione:
- 3 2 1 2bb183af...
+ 3 1 1 2bb183af...
Matching type fuori intervallo
Causa: matching type superiore a 2.
Correzione:
- 3 1 3 2bb183af...
+ 3 1 1 2bb183af...
Dati esadecimali non validi
Causa: caratteri fuori dall'intervallo esadecimale (0-9, a-f, A-F).
Correzione:
- 3 1 1 2bg183zf...
+ 3 1 1 2bb183af...
Lunghezza di hash errata
Causa: la lunghezza dei dati non corrisponde al matching type.
Correzione SHA-256:
- 3 1 1 2bb183
+ 3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
SHA-256 (matching type 1) richiede esattamente 64 caratteri esadecimali. SHA-512 (matching type 2) richiede esattamente 128 caratteri.
Combinazione usage/selector fragile
Causa: DANE-EE (3) + Cert completo (0) comporta un hash che cambia a ogni rinnovo di certificato.
Correzione raccomandata: passare a SPKI (1) per rendere il record invariante ai rinnovi (con l'opzione --reuse-key lato ACME).
- 3 0 1 <hash-del-certificato-completo>
+ 3 1 1 <hash-della-chiave-pubblica>
Owner name errato
Causa: record pubblicato sull'apex del dominio anziché sull'host MX, o sulla porta sbagliata.
Correzione: _25._tcp.<host-mx> esattamente. Per un MX mail.captaindns.com, è _25._tcp.mail.captaindns.com.
Preparare una rotazione di chiave
Più record TLSA nella stessa zona non sono un errore: è anzi lo schema raccomandato per una rotazione di chiave senza interruzione.
Procedura di rotazione pulita
- D-7: genera la chiave successiva, calcola il suo hash SPKI, pubblicalo in doppio:
_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>
-
D-0: esegui la rotazione di certificato con la nuova chiave. Gli MTA conformi accettano la connessione se almeno uno dei due record corrisponde al certificato presentato.
-
D+7 (o il doppio del TTL): rimuovi il record vecchio. La rotazione è terminata.
Cosa verifica il validatore
Il validatore tratta ogni record in modo indipendente e conferma che:
- Ogni hash rispetta la lunghezza attesa dal suo matching type
- Nessun campo esce dagli intervalli validi
- Le combinazioni restano nelle raccomandazioni
Un record doppio non viene mai segnalato come errore quando entrambi sono sintatticamente corretti.
DANE e MTA-STS: approcci complementari
| 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 / Google Workspace | Parziale o inesistente | Completo |
| Deployment | Complesso (DNSSEC) | Più semplice |
Raccomandazione: non scegliere, distribuisci entrambi. Valida qui il tuo record TLSA e pubblica anche una policy MTA-STS. La copertura massima impone la combinazione.
Strumenti complementari e risorse
| Strumento | Quando usarlo |
|---|---|
| DANE TLSA Checker | Audit in tempo reale del record pubblicato nel DNS, con validazione DNSSEC e corrispondenza del certificato |
| Generatore DANE TLSA | Creare un record TLSA a partire da un certificato o una chiave pubblica |
| Validatore sintassi MTA-STS | Validare la policy MTA-STS associata offline |
| Validatore sintassi TLS-RPT | Validare il record TLS-RPT associato offline |
| 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, risoluzione: 12 casi pratici - 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)