Verifica dei record DANE/TLSA

Interroga più risolutori DNS pubblici per i record TLSA pubblicati dai server di posta di un dominio e verifica se sia configurata la validazione dei certificati tramite DANE.

Ultimo aggiornamento: 2026-10-18

Diagnosticare la validazione dei certificati tramite DANE (record TLSA)

DANE è l'assetto per cui il certificato che un server di posta presenta viene validato contro un record TLSA posto nel DNS. Questo strumento interroga i record TLSA pubblicati dagli host MX di un dominio presso più risolutori pubblici e riferisce se siano configurati.

La premessa che qui non si può mai omettere è che DANE regge soltanto su DNSSEC. A garantire che un record TLSA non sia stato manomesso è DNSSEC stesso, sicché porre record TLSA su un dominio privo di DNSSEC non equivale ad alcuna protezione. È questa la differenza capitale rispetto a MTA-STS: dove MTA-STS ripone la fiducia nei certificati web, DANE la ripone in DNSSEC. L'altro punto che nell'esercizio richiede cautela è il rinnovo dei certificati, poiché sostituire il certificato di un server senza aggiornare al contempo il record TLSA fa fallire la validazione e ferma l'arrivo della posta. L'ordine necessario è aggiungere dapprima la nuova impronta, commutare, e solo in seguito togliere la vecchia.

Come si usa

Inserite il dominio Indicate il solo dominio, nella forma example.com.
Guardate l'esito per ciascun host MX I record TLSA risiedono in _25._tcp.nomehost di ogni host MX.
Accertate se DNSSEC sia al suo posto Senza DNSSEC un record TLSA non offre protezione alcuna.
Pianificate la procedura di rinnovo Lasciate convivere per un tempo la vecchia e la nuova impronta prima di commutare.

Consigli per sfruttarlo al meglio

I record TLSA non stanno sul nome di dominio ordinario, ma su un nome particolare del server di posta, nella forma «_25._tcp.{nome host}»: ecco perché cercandoli sul solo dominio non si trovano.
La mancata configurazione di DANE non è un'anomalia: si tratta di un ulteriore livello di protezione della cifratura della posta e molti server ancora non lo adottano.
DANE diventa un'informazione affidabile solo grazie alla catena di firme DNSSEC. Se trovate i record TLSA ma il dominio non adotta DNSSEC, verificate anche con il nostro strumento gemello per la validazione DNSSEC.
Se i server di posta sono più d'uno, la verifica riguarda fino a tre host, a partire da quello con la priorità più alta, cioè con il valore numerico più basso.
Se i risolutori danno esiti discordi, può darsi che i record TLSA siano stati aggiornati da poco e che le cache siano ancora disallineate: attendete e ripetete la verifica.

Quando torna utile

Nell'ispezionare i propri server di posta

Potete scovare lo scarto in cui un TLSA si credeva posto mentre manca sull'host MX.

Nel verificare prima di rinnovare un certificato

Sbagliare l'ordine ferma la posta, il che rende la verifica preventiva ampiamente conveniente.

Nel soppesare DANE rispetto a MTA-STS

Scegliete secondo dove preferiate riporre la fiducia, in DNSSEC o nei certificati web; entrambi si possono adottare insieme.

Nel sapere a che punto sia un corrispondente

Potete vedere se usi DANE affatto.

Termini di DANE

Record TLSA: Il record che pone nel DNS l'impronta di un certificato o di una chiave pubblica. Risiede in un nome quale _25._tcp.mail.example.com.
DNSSEC: La premessa di DANE. Senza di esso il record TLSA stesso potrebbe essere manomesso e nessuna protezione regge.
Campo d'uso: Il primo numero di un record TLSA, che dichiara se si riferisca al certificato stesso o a un'autorità di certificazione.
DANE-EE: L'approccio che registra l'impronta del certificato del server stesso. Consente di validare senza dipendere da alcuna autorità.
Ricambio: Il lavoro di sostituire un certificato e il suo record TLSA. Aggiungete dapprima la nuova impronta e togliete la vecchia in seguito.
TLS opportunistico: L'approccio più antico e facoltativo di cifrare là dove l'altra parte lo sostenga. DANE e MTA-STS lo elevano a requisito.

Domande frequenti

La mancata configurazione non è di per sé pericolosa: ancora oggi la grande maggioranza dei server di posta opera senza DANE. Come difesa contro gli attacchi che si frappongono alla negoziazione della cifratura, però, vale la pena valutarne l'adozione.

Entrambi perseguono lo stesso obiettivo, imporre la cifratura nel trasferimento della posta, ma poggiano su fondamenti di fiducia diversi: MTA-STS sulla catena di certificazione di un'autorità, DANE sulla catena di firme DNSSEC. Se avete già adottato DNSSEC conviene DANE, altrimenti è più realistico cominciare da MTA-STS. Si possono anche usare insieme.

Il primo indica il metodo di verifica, cioè se si richieda comunque la validazione presso un'autorità oppure si fissi direttamente il certificato; il secondo se a essere sottoposto a impronta sia l'intero certificato o la sola chiave pubblica; il terzo l'algoritmo di impronta. Le combinazioni coprono più modalità operative.

Per una protezione affidabile si raccomanda di configurarli su tutti i server che possano essere scelti come destinazione. Se sono presenti solo su alcuni, i messaggi indirizzati agli altri restano privi di protezione.

Lo strumento verifica soltanto un aspetto superficiale, cioè la presenza dei record TLSA. Poiché non controlla che i dati di associazione del certificato corrispondano a quello effettivamente presentato dal server, per una verifica rigorosa affiancate strumenti specialistici.

A proposito — proteggere la cifratura della posta con i certificati invece che con la sola riservatezza

La cifratura nel protocollo di trasferimento della posta ha avuto a lungo un punto debole. Molti server adottano una cifratura opportunistica, che invia in chiaro se l'interlocutore non supporta la cifratura: un attaccante che si frapponga alla comunicazione può cancellare il comando di avvio della cifratura e intercettare il traffico senza che nessuno se ne accorga.

DANE, definito dalla RFC 6698, risponde al problema pubblicando nel DNS i record TLSA. Fissando in anticipo nel DNS il certificato del server di posta, o l'impronta della sua chiave pubblica, si può verificare che l'interlocutore presenti davvero il certificato previsto. La differenza sostanziale rispetto alla normale verifica dei certificati SSL/TLS è che non ci si affida alla catena di certificazione di un'autorità, ma unicamente alla catena di firme DNSSEC.

Il limite di DANE è che, per funzionare, il dominio deve essere firmato con DNSSEC. Su un dominio che non lo adotta non si può escludere la manomissione degli stessi record TLSA e la garanzia offerta da DANE perde ogni valore. La diffusione di DANE dipende quindi strettamente da quella di DNSSEC, e alcuni registri europei ne hanno anticipato l'adozione.

Vedi tutte le curiosità