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. La validazione gira sui nostri server: il record che incolli viene inviato a CaptainDNS per essere analizzato. Nulla viene però pubblicato, non parte alcuna query DNS e nessun resolver esterno vede mai la tua bozza. Questo approccio a monte 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, nessun file remoto scaricato.
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. L'analisi avviene lato server, senza alcuna query DNS.
Passo 2: leggere il verdetto
I risultati sono classificati per gravità:
- Errore: problema bloccante, il record verrà ignorato o rifiutato dagli MTA conformi
- Avviso: 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 record TLSA 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.
| Criterio | 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 | Il record incollato | Dominio analizzato |
Flusso di lavoro raccomandato:
- Progetta o genera il record, poi usa il validatore per verificare la sintassi
- Pubblica il record TLSA 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 record servito dal DNS pubblico 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; il certificato fissato deve comparire nella catena TLS servita, quindi fissa l'intermedio (R10/R11) e non la radice |
| 2 1 1 | Accettabile | DANE-TA sulla SPKI della CA; stesso vincolo di catena, fissa l'intermedio che viene davvero inviato |
| 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, calcolane l'hash SPKI e pubblica i due record insieme:
_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
Due record coesistenti non vengono mai segnalati 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)