DNSSEC: verifica e correzione delle zone firmate male

Perché DNSSEC crea problemi quando è configurato male

DNSSEC è uno di quei componenti che funzionano in silenzio finché tutto è allineato, ma appena un record, una chiave o una firma non combaciano la conseguenza può essere molto visibile: il dominio diventa irraggiungibile per una parte degli utenti, i resolver restituiscono errori di validazione, le email possono subire ritardi e alcuni servizi sembrano “andare e venire” senza una causa evidente.

Il punto critico è semplice: DNSSEC non cambia il contenuto del DNS, aggiunge una catena di fiducia. Se la catena si spezza, i resolver validanti non si fidano più della risposta. In produzione questo si traduce spesso in timeout apparenti, SERVFAIL, problemi intermittenti dopo un cambio DNS o dopo una rotazione di chiavi fatta in modo incompleto.

La buona notizia è che i casi più comuni si diagnosticano in modo abbastanza lineare. Serve però procedere con metodo: prima capire se il problema è davvero DNSSEC, poi identificare dove si rompe la catena di validazione, infine correggere la zona o il DS nel registrar con il minimo rischio possibile.

Quando sospettare un errore DNSSEC

DNSSEC va sospettato soprattutto quando il dominio funziona da alcuni resolver ma fallisce da altri, oppure quando dopo una modifica DNS tutto sembrava corretto ma gli utenti hanno iniziato a vedere errori casuali. Un altro segnale tipico è la presenza di SERVFAIL su query che prima rispondevano normalmente.

In pratica, i sintomi più frequenti sono questi:

• il dominio risolve in alcune reti ma non in altre;
• il browser mostra errore di connessione anche se il web server è online;
• le email verso domini con validazione DNSSEC risultano ritardate o respinte;
• un controllo con strumenti DNS mostra bogus, insecure inatteso o validation failure;
• dopo il rinnovo di una chiave o il cambio provider DNS il problema compare subito o entro poche ore.

La distinzione importante è tra errore DNS classico e errore DNSSEC. Se il record manca davvero, la query restituisce NXDOMAIN o nessuna risposta utile. Se il record esiste ma la firma non torna, il resolver validante spesso risponde con SERVFAIL. Questa differenza è il primo indizio utile per non perdere tempo su ipotesi sbagliate.

Controlli iniziali: capire dove si rompe la fiducia

Il primo controllo da fare è verificare se il dominio è firmato e se il DS al registrar corrisponde alla chiave pubblicata nella zona. Se questi due elementi non si allineano, la validazione fallisce quasi sempre.

Con strumenti comuni come dig puoi leggere sia i record DNS sia i dati DNSSEC. Un controllo base utile è questo:

dig +dnssec example.com A

Se la risposta include record firmati e flag coerenti, è un buon segno; se invece il resolver restituisce errori o la firma non viene considerata valida, il problema è probabilmente nella catena DNSSEC e non nel solo record A.

Per un controllo più mirato, conviene interrogare anche i record DNSKEY e DS:

dig +dnssec example.com DNSKEY

dig DS example.com

Il risultato atteso è che il DS pubblicato dal registrar corrisponda a una chiave DNSKEY della zona. Se il DS punta a una chiave vecchia, o se la zona è stata rifirmata ma il registrar non è stato aggiornato, la validazione si rompe.

Un secondo controllo molto utile è testare il dominio da un resolver validante noto, ad esempio quelli pubblici, e confrontare il comportamento con un resolver locale. Se il locale risponde e il validante no, la zona potrebbe sembrare “a posto” solo perché il resolver locale non sta validando davvero oppure perché la cache nasconde il problema.

Le cause tecniche più frequenti

Le cause reali, nei casi che si vedono più spesso, sono poche ma ricorrenti. La prima è il disallineamento tra DS e DNSKEY: il registro del dominio conserva un DS vecchio mentre la zona ha già una nuova chiave. La seconda è la firma scaduta o non ancora valida, spesso dopo un cambio manuale di orari, un clock del server sfasato o una procedura di rollover interrotta.

Un altro caso comune è la zona firmata con parametri corretti ma pubblicata in modo incompleto. Per esempio, il file di zona viene aggiornato sul server primario ma non propagato correttamente ai secondari, oppure i secondari servono una versione non firmata o con NSEC/NSEC3 incoerenti.

Ci sono poi errori meno evidenti:

• chiavi KSK/ZSK ruotate senza completare la fase di doppia pubblicazione;
• DS generato con algoritmo o digest errato;
• time skew del server DNS che fa risultare le firme fuori finestra;
• rollback del provider DNS senza aggiornare il registrar;
• migrazione di zona completata ma DNSSEC lasciato attivo sul vecchio setup.

In ambienti gestiti via pannello, il rischio aumenta perché alcuni passaggi sono distribuiti tra provider DNS e registrar. La zona può essere “firmata” nel pannello hosting, ma il dominio resta non validabile finché il DS non viene pubblicato correttamente nel registrar.

Come verificare in modo sicuro senza peggiorare il guasto

Prima di cambiare qualsiasi cosa, bisogna verificare se il dominio è effettivamente in produzione e quanto impatto sta avendo. Se il sito è online ma con problemi intermittenti, la priorità è evitare modifiche che possano azzerare la validazione su tutti i resolver. Se invece il dominio è completamente irraggiungibile a causa del DNSSEC, la priorità può diventare il ripristino della risoluzione, anche con una disattivazione temporanea della validazione.

Una verifica prudente è confrontare la risposta da un resolver che valida e da uno che non valida. Se il resolver non validante risponde correttamente, il contenuto DNS è probabilmente sano; se il validante fallisce, il problema è nella firma o nel DS.

Un altro controllo molto utile è verificare la data e l’ora del server DNS. Se il server ha l’orologio fuori sincronizzazione, le firme possono risultare non ancora valide o già scadute. In ambienti Linux, un controllo base è vedere se il servizio di sincronizzazione temporale è attivo e coerente. Questo non risolve da solo un DNSSEC rotto, ma evita di inseguire un falso problema.

Soluzione consigliata: partire dal fix più reversibile

La soluzione più sicura dipende dal punto di rottura, ma l’ordine corretto è quasi sempre questo: prima identificare se il DS nel registrar è sbagliato, poi verificare la validità delle firme nella zona, infine correggere la pubblicazione sui server autorevoli.

1. Se il DS non corrisponde, correggi il registrar

Se hai appena cambiato provider DNS, rigenerato le chiavi o rifirmato la zona, il DS al registrar potrebbe essere vecchio. In questo caso non va toccata subito la zona: la correzione più pulita è aggiornare il DS con quello nuovo fornito dal server DNS o dal pannello del provider.

Nel pannello del registrar cerca la sezione DNSSEC del dominio e confronta il record DS con il valore attuale della zona. Se il provider DNS mostra un DS diverso, sostituisci il vecchio con il nuovo. Dopo la modifica, considera che la propagazione può richiedere tempo in base ai TTL e ai cache dei resolver.

Controllo atteso: una volta aggiornato il DS, le query verso resolver validanti devono tornare a rispondere senza SERVFAIL entro il tempo di propagazione.

2. Se la zona è firmata male, rifirma in modo coerente

Se il DS è corretto ma la firma della zona è rotta, bisogna rifirmare la zona con i parametri giusti. La procedura esatta dipende dal software DNS, ma il principio è sempre lo stesso: usare chiavi coerenti, generare firme valide, pubblicare i nuovi record e verificare la catena completa.

In ambienti controllati da pannello, la via migliore è usare la funzione DNSSEC nativa del provider, se disponibile, invece di manipolare manualmente file e chiavi. Questo riduce il rischio di errori di formato e di pubblicazione incompleta.

Controllo atteso: dopo la rifirma, i record DNSKEY e i record firmati devono essere visibili e coerenti, senza errori di validazione da resolver pubblici.

3. Se il problema è un rollover interrotto, completa la transizione

Il rollover delle chiavi è un caso classico: per un periodo la vecchia e la nuova chiave devono convivere, poi si rimuove la precedente solo quando i resolver hanno avuto tempo di aggiornarsi. Se la procedura si interrompe a metà, alcuni resolver vedono ancora la vecchia chiave mentre altri si aspettano già la nuova.

La soluzione non è “pulire tutto” alla cieca, ma ripristinare lo stato di transizione corretto. Se hai i log o la documentazione del provider DNS, ricostruisci quale fase del rollover è stata completata e quale no. Se non hai evidenza chiara, è più sicuro riallineare la zona a una sola configurazione stabile e poi rifirmare con calma.

Controllo atteso: durante il periodo di transizione, entrambi i set di chiavi devono essere accettabili finché la cache dei resolver non si allinea; alla fine, la zona deve presentare solo la chiave definitiva.

4. Se serve ripristino rapido, disattiva temporaneamente DNSSEC

Quando il dominio è completamente bloccato e la priorità è ripristinare il servizio, la misura più reversibile è disattivare temporaneamente DNSSEC. Questo va fatto con cautela, perché interrompe la validazione, ma in molti incidenti è preferibile a lasciare il dominio irraggiungibile.

Questa opzione è adatta solo se hai la certezza che il guasto derivi da DNSSEC e non da un problema più ampio del DNS. Dopo la disattivazione, il dominio torna generalmente raggiungibile anche dai resolver validanti, ma va trattato come misura provvisoria fino alla correzione definitiva.

Controllo atteso: dopo la disattivazione, il dominio deve tornare risolvibile senza SERVFAIL; appena stabilizzato, pianifica la riattivazione con una nuova verifica completa.

Verifiche post-fix che non andrebbero saltate

Dopo ogni correzione, il controllo non deve fermarsi alla singola query positiva. Serve verificare almeno tre aspetti: risoluzione del record principale, validazione DNSSEC e coerenza della propagazione.

Un set minimo di verifiche pratiche è questo:

1. controlla il record principale del dominio da più resolver, per confermare che la risposta sia stabile;
2. esegui una query con +dnssec per confermare che la firma sia accettata;
3. verifica il comportamento da rete diversa o da un resolver pubblico, per intercettare cache residue o problemi di propagazione;
4. se il dominio gestisce mail, testa anche i record MX e la risoluzione del nome host di posta, perché un DNSSEC rotto può impattare anche la consegna email.

Se il sito usa CDN, bilanciatori o servizi esterni, va controllato anche che i record CNAME e gli eventuali target siano coerenti. Una zona DNSSEC corretta ma un target sbagliato può creare sintomi simili, e il rischio è attribuire tutto alla firma quando il problema è altrove.

Buone pratiche per evitare il problema in futuro

Il modo migliore per non ritrovarsi con DNSSEC rotto è trattarlo come una procedura, non come un pulsante da attivare una volta per sempre. Ogni cambio di provider DNS, ogni migrazione, ogni rotazione di chiavi e ogni modifica al registrar dovrebbe avere un controllo finale documentato.

Le pratiche più utili sono queste:

• tenere un registro delle chiavi attive e delle date di rollover;
• verificare sempre DS e DNSKEY dopo una migrazione;
• sincronizzare l’orologio dei server autorevoli;
• usare TTL ragionevoli prima di modifiche importanti;
• non rimuovere la vecchia chiave finché la nuova non è realmente propagata;
• testare il dominio con almeno un resolver validante prima di dichiarare chiusa la manutenzione.

Se il dominio è critico, vale la pena includere il controllo DNSSEC nella checklist di deploy insieme a web server, certificati TLS e posta. In molti incidenti il problema non è la tecnologia in sé, ma il fatto che viene modificata senza un passaggio di verifica finale.

Conclusione operativa

Quando DNSSEC si rompe, la tentazione è disattivarlo subito o rifare tutto da zero. In realtà il metodo più sicuro è quasi sempre più semplice: capire se il DS e la DNSKEY sono allineati, verificare la firma della zona, correggere il punto esatto di rottura e solo in ultima istanza usare la disattivazione temporanea come misura di recupero.

Il principio pratico è questo: un problema DNSSEC non si risolve “a sensazione”, si risolve con una catena di controlli brevi ma precisi. Se la catena torna coerente, il dominio smette di comportarsi in modo intermittente e la validazione riprende a funzionare senza effetti collaterali.

Per chi gestisce hosting, VPS o domini in produzione, DNSSEC va trattato come una parte viva dell’infrastruttura: monitorato, documentato e testato dopo ogni modifica critica. Così diventa un vantaggio di sicurezza, non una fonte di incidenti difficili da leggere.

Se una zona DNS sembra corretta ma i resolver validanti rispondono con errore, la domanda giusta non è “cosa non funziona?”, ma “dove si è spezzata la fiducia?”.