Come proteggere il DNS del sito con DANE

Proteggere il DNS del sito con DANE vuol dire usare il DNS come punto di verifica crittografica per il TLS, invece di affidarsi solo alla PKI pubblica. In pratica pubblichi un record TLSA che descrive come deve apparire il certificato o la chiave del servizio, e lo rendi affidabile con DNSSEC. Il vantaggio è concreto: se qualcuno altera la risposta DNS o prova a sostituire il certificato sul server, il client che valida DANE vede la discrepanza e rifiuta la connessione.

Il punto chiave è questo: DANE non sostituisce TLS, non sostituisce DNSSEC e non “migliora” automaticamente la sicurezza del sito. Fa una cosa molto specifica, ma utile: lega il nome del servizio alla sua chiave TLS tramite il DNS autenticato. Se la tua infrastruttura ha già una gestione disciplinata di DNS e certificati, DANE aggiunge un livello di controllo che riduce il rischio di CA compromise, installazioni errate e sostituzioni silenziose del certificato.

Quando DANE ha senso davvero

DANE ha senso quando controlli la zona DNS del dominio e puoi firmarla con DNSSEC in modo stabile. È particolarmente interessante per servizi dove il client può validare DANE in modo esplicito: mail server, servizi interni, API controllate, ambienti in cui hai client configurabili. Per il web pubblico, il supporto lato browser è sostanzialmente assente, quindi DANE per HTTPS non è la leva principale per il traffico browser-to-site. Può però avere valore per i client non browser, per endpoint amministrativi, per proxy controllati e per integrazioni machine-to-machine.

Se l’obiettivo è “proteggere il DNS del sito”, la distinzione va tenuta netta: DANE non protegge la risoluzione DNS in sé, ma protegge l’uso del DNS come fonte autorevole per la verifica del certificato. Per la protezione del DNS in senso stretto, il primo piano resta DNSSEC, igiene operativa sui registrar, MFA, lock del dominio, separazione dei ruoli e monitoraggio dei cambi di zona. DANE è il livello che sfrutta quella base per vincolare il TLS.

Architettura minima: DNSSEC prima, TLSA poi

La sequenza corretta è semplice: prima firmi la zona con DNSSEC, poi pubblichi i record TLSA per il servizio che vuoi vincolare. Se inverti l’ordine, il record TLSA non ha una catena di fiducia verificabile e il vantaggio operativo svanisce. In produzione, la qualità di questa catena dipende da quattro punti: zona firmata, DS registrato al parent, resolver che valida, client che supporta DANE. Se uno dei quattro manca, il sistema degrada o non funziona.

Un errore classico è trattare il TLSA come un record “decorativo”. Non lo è: definisce come il client deve confrontare il certificato o la chiave presentati dal server. Per questo il valore scelto deve essere coerente con il modo in cui gestisci i rinnovi dei certificati. Se fai rotate frequenti con certificati pubblici standard, la strategia TLSA deve essere pensata per non rompere il rinnovo automatico.

Capire i parametri TLSA senza confonderli

Un record TLSA ha quattro campi logici: service port, protocol, selector, matching type e il dato associato. Il nome tipico segue questo schema: _porta._protocollo.nomehost. Per HTTPS, il servizio è di fatto associato a _443._tcp, anche se il supporto lato client non è universale. Per altri servizi, come SMTP, il pattern è lo stesso ma il supporto operativo è molto più maturo.

I parametri importanti sono selector e matching type. Il selector decide se confrontare il certificato completo o solo la chiave pubblica. Il matching type decide se salvare il dato in forma esatta o hashata. In pratica, le combinazioni più usate sono quelle che riducono il rischio di mismatch durante i rinnovi senza abbassare troppo il livello di vincolo. Per chi gestisce ambienti reali, la scelta va fatta in funzione del ciclo di vita del certificato, non in base a una preferenza teorica.

Un approccio prudente è partire da un record che vincoli la chiave pubblica o l’hash della chiave, non l’intero certificato, se prevedi rinnovi frequenti con certificati emessi dalla stessa chiave. Se invece ruoti anche la chiave a ogni rinnovo, devi pianificare con più attenzione la pubblicazione del nuovo TLSA prima del cambio effettivo sul server. Qui il dettaglio operativo conta più della teoria.

Flusso operativo consigliato

La procedura sensata non parte dal file di zona, ma dalla verifica dello stato attuale. Prima controlli DNSSEC, poi il certificato in uso, poi la possibilità di derivare il TLSA corretto. Solo dopo scrivi la modifica. È il modo più semplice per evitare di pubblicare un record che rende il servizio irraggiungibile per i client validanti.

Per leggere il certificato presentato dal server puoi usare openssl s_client. Per esempio:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

Questo ti mostra la catena reale. Se il sito è dietro reverse proxy, CDN o bilanciatori, devi verificare il punto esatto che termina TLS, non solo l’origin. È lì che il TLSA deve riflettere la chiave o il certificato effettivamente presentato ai client.

Generare un TLSA in modo coerente

Per generare il dato del TLSA, prima identifica il certificato o la chiave pubblica da vincolare. Se vuoi lavorare sulla chiave pubblica del certificato, puoi estrarla in questo modo:

openssl x509 -in cert.pem -pubkey -noout > pubkey.pem

Se poi devi trasformare il contenuto in un record TLSA con hash, la logica varia in base alla combinazione scelta. In molti casi conviene usare strumenti dedicati, perché riducono gli errori di formattazione. Un esempio comune è hash-slinger con il comando hash-slinger o strumenti equivalenti disponibili nella tua distribuzione. L’obiettivo non è il tool in sé, ma ottenere un valore che corrisponda esattamente al materiale presentato dal server.

Se gestisci la zona con file testuale, il record avrà una forma simile a questa:

_443._tcp.www.example.com. IN TLSA 3 1 1 abcd1234...

Qui i numeri indicano l’uso del certificato, il selector e il matching type. Non fissarti sul valore “giusto” in astratto: il record corretto è quello che corrisponde alla tua strategia di deployment e al tuo ciclo di rinnovo. Se cambi chiave spesso, una combinazione troppo rigida può trasformarsi in outage al primo rinnovo eseguito male.

DNSSEC: il vero punto di fiducia

Senza DNSSEC, un record TLSA è solo un dato DNS come gli altri. Con DNSSEC, diventa una dichiarazione autenticata. Questo significa che il lavoro di protezione non termina alla pubblicazione del record: devi anche sorvegliare la salute della firma della zona, la catena DS, le scadenze delle chiavi e la correttezza dei rollover. Se la firma cade, DANE perde il suo valore operativo.

Controlli minimi da fare regolarmente:

Per una verifica rapida puoi usare dig con validazione esplicita su un resolver che la supporta. Esempio:

dig +dnssec TLSA _443._tcp.www.example.com

Se il resolver non valida, il record può arrivare comunque, ma non hai la garanzia crittografica che DANE richiede. In altre parole: il dato esiste, ma non è affidabile per lo scopo.

Integrazione con Apache, Nginx e reverse proxy

Su un sito web classico, DANE si intreccia con il punto in cui termini TLS. Se usi Apache o Nginx direttamente sul server, il record TLSA deve seguire il certificato configurato lì. Se invece hai un reverse proxy davanti, il TLSA va allineato al proxy, non all’origin. È un dettaglio che molti sbagliano, perché guardano il filesystem del backend invece del certificato effettivamente esposto all’esterno.

Per questo, prima di pubblicare o aggiornare un TLSA, conviene verificare il certificato presentato dal front-end:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -subject -issuer -fingerprint -sha256

Se il fingerprint non coincide con quello usato per il TLSA, stai vincolando il materiale sbagliato. In ambienti con bilanciatori, CDN o WAF, questa verifica va fatta sul nodo che conclude la sessione TLS verso il client, non sul server applicativo finale.

Rinnovo dei certificati senza rompere il servizio

Il rinnovo è il punto in cui DANE fallisce più facilmente se la procedura è improvvisata. La regola pratica è semplice: pubblica il nuovo TLSA prima di mettere in produzione il nuovo certificato, lascia un overlap temporale sufficiente e solo dopo esegui il cambio sul server. Se il tuo meccanismo di issuance è automatico, il processo va automatizzato in modo speculare anche lato DNS.

Un flusso sicuro può essere questo:

Se usi ACME, il problema non è ottenere il certificato, ma allineare i tempi di pubblicazione del record DNS con il deploy del certificato. Qui serve disciplina operativa o automazione vera, non promesse di “si aggiorna da solo”.

Errori tipici che vedo in produzione

Il primo errore è firmare la zona ma non monitorare il rollover delle chiavi. La firma scade, il resolver validante rifiuta, e il sito sembra “rotto” solo da alcune reti o alcuni client. Il secondo errore è pubblicare un TLSA per il nome sbagliato: spesso succede con www, apex, servizi delegati o host dietro CDN. Il terzo errore è usare il certificato sbagliato come riferimento, ad esempio quello dell’origin interno invece di quello esposto all’esterno.

Un altro punto sottovalutato è il TTL. TTL troppo alto rallenta i rollback; TTL troppo basso aumenta la frequenza di query e rende più difficile capire se la propagazione è davvero completa. Per una zona gestita bene, il TTL del TLSA va scelto insieme al piano di cambiamento, non a caso. Se prevedi rotazioni frequenti, non mettere valori lunghi per abitudine.

Infine, attenzione al monitoraggio. Non basta controllare che il sito risponda in HTTP 200: devi verificare la validazione DNSSEC, la presenza del TLSA atteso e la corrispondenza con la chiave in uso. Una check-list minima può essere automatizzata con dig, openssl e un controllo del record nella zona autoritativa.

Check operativi da mettere in agenda

Se vuoi usare DANE in modo serio, la manutenzione ricorrente conta quanto la configurazione iniziale. Una cadenza ragionevole include questi controlli:

Se hai un pannello DNS che supporta DNSSEC, usa il pannello solo se ti consente di vedere chiaramente stato della firma, DS e record pubblicati. Se non hai visibilità sufficiente, meglio il file di zona versionato e il deploy controllato. Qui il rischio non è fare il record, ma farlo male e accorgersene quando il client validante smette di connettersi.

Vale la pena per un sito web pubblico?

Per un sito web pubblico raggiunto da browser, DANE non è la priorità assoluta perché il supporto lato client è limitato. Se il tuo obiettivo è proteggere il traffico web standard, investi prima in DNSSEC, HSTS, hardening del TLS, gestione corretta dei certificati, monitoraggio delle scadenze e protezione del registrar. DANE diventa interessante quando hai un ecosistema controllato, client compatibili e bisogno di aggiungere una verifica indipendente dalla CA pubblica.

Detto questo, come strato di fiducia aggiuntivo è robusto. Infrastrutture ben gestite lo usano per ridurre il rischio operativo e per vincolare in modo più stretto il certificato esposto dal servizio. Se lo adotti, fallo con ordine: DNSSEC stabile, TLSA coerente, automazione del rinnovo, monitoraggio della validazione. Senza questi quattro elementi, DANE non è una protezione; è solo un altro record da mantenere.

In sintesi operativa: firma la zona, controlla il punto esatto che termina TLS, pubblica il TLSA giusto, automatizza il rinnovo e verifica sempre la validazione da un resolver che fa davvero DNSSEC. È lì che DANE smette di essere teoria e diventa una barriera utile contro alterazioni e errori di configurazione.