DNSSEC, 11 ottobre: quando il server è sano ma il dominio non risponde

Un sito può rispondere perfettamente ai controlli del server, avere certificati validi, database operativo e applicazione in salute. Eppure, per alcuni utenti, risultare irraggiungibile. Non perché il server abbia smesso di funzionare, ma perché il resolver DNS incaricato di trovare il suo indirizzo non riesce più a validare la catena di fiducia. È una distinzione che sembra accademica finché non diventa un incidente operativo.

L’11 ottobre 2026 è programmato un passaggio importante per DNSSEC: la zona root inizierà a essere firmata con la nuova Key Signing Key, KSK-2024. Non cambia il dominio del tuo sito, non viene sostituito il suo certificato TLS e non c’è un aggiornamento da installare su ogni WordPress. Cambia una chiave nella radice della fiducia DNS. Il problema riguarda soprattutto i resolver ricorsivi che validano DNSSEC e non hanno acquisito il nuovo trust anchor.

È il genere di manutenzione che si prepara con largo anticipo, si verifica con strumenti appropriati e che, quando viene ignorata, finisce per essere raccontata come un misterioso problema di rete. Misterioso solo perché nessuno aveva deciso di misurarlo.

Una chiave alla radice, non una password da cambiare

DNSSEC permette a un resolver validante di verificare crittograficamente che le risposte DNS firmate appartengano alla catena di fiducia attesa. La root è il punto iniziale di questa catena. La Key Signing Key della root firma il set DNSKEY che comprende le chiavi usate nel processo di validazione. Il resolver deve quindi conoscere un trust anchor attendibile da cui partire.

Fino al passaggio programmato, la chiave storica KSK-2017, identificata dal key tag 20326, è quella che firma il set DNSKEY della root. Dall’11 ottobre la firma è prevista con KSK-2024, key tag 38696. Chi continua a fidarsi esclusivamente della vecchia chiave rischia di non poter convalidare la risposta, anche quando i record DNS e i server di destinazione sono corretti.

La timeline ufficiale IANA chiarisce un dettaglio essenziale: non è un cambio improvvisato per domenica. La nuova chiave è stata pubblicata nella zona root l’11 gennaio 2025, così da poter essere appresa in anticipo dai resolver compatibili. L’11 ottobre 2026 è la data programmata per il cambio della firma; la revoca della vecchia KSK-2017 è prevista per l’11 gennaio 2027 e la sua rimozione per il 22 marzo 2027. Sono fasi distinte, non un unico interruttore.

La differenza tra essere online ed essere raggiungibili

La prima reazione, davanti a un’applicazione irraggiungibile, è controllare web server, database, CDN, firewall e certificato HTTPS. Sono controlli sensati, ma osservano solo alcuni pezzi della catena. Se il resolver ricorsivo di una rete fallisce la validazione DNSSEC, la richiesta può fermarsi prima ancora di raggiungere il server web.

Per questo il sintomo può essere selettivo: un utente raggiunge il sito e un altro no; una rete aziendale fallisce mentre una connessione mobile funziona; un test HTTP eseguito da un provider esterno è verde mentre le postazioni che usano un resolver interno non riescono a risolvere i nomi. Il risultato può essere SERVFAIL, ma non ogni SERVFAIL significa necessariamente trust anchor obsoleto: il codice segnala una mancata risoluzione che richiede diagnosi.

La lezione architetturale è che il monitoraggio di un servizio non coincide con il monitoraggio delle sue dipendenze. Un check applicativo fatto da un solo punto della rete non descrive lo stato di tutti i percorsi DNS. Lo stesso ragionamento vale per l’identità digitale: in un precedente articolo ho distinto certificato valido e identità DNS, due controlli che spesso vengono trattati come se fossero la stessa cosa. Non lo sono, e il rollover lo rende molto concreto.

Un sistema non è affidabile perché ogni componente risponde al proprio health check. È affidabile quando sappiamo verificare anche le condizioni che permettono ai componenti di trovarsi e fidarsi l’uno dell’altro.

RFC 5011: l’automatismo funziona soltanto se conserva lo stato

Per evitare di aggiornare manualmente ogni resolver a ogni cambio di chiave, RFC 5011 definisce un meccanismo di aggiornamento automatico dei trust anchor. Un resolver che lo implementa osserva la nuova chiave pubblicata e firmata attraverso quella già fidata; dopo il periodo minimo di accettazione, pari a 30 giorni, può aggiungerla al proprio insieme di ancore attendibili.

Il punto non è soltanto che l’opzione sia attiva in configurazione. Conta anche che il resolver abbia visto la nuova chiave, abbia potuto verificare le risposte nel tempo e conservi correttamente lo stato appreso. Installazioni datate, configurazioni manuali, file non scrivibili, snapshot ripristinati e ambienti che non persistono lo stato meritano controlli specifici. Non sono automaticamente guasti, ma sono condizioni in cui l’aggiornamento automatico non va dato per scontato.

L’indicazione operativa ICANN è chiara: chi gestisce resolver DNSSEC validanti deve verificare la presenza della chiave con key tag 38696 e lo stato dell’aggiornamento automatico. Le installazioni moderne ben configurate dovrebbero essere già pronte; questo non autorizza a dedurre che ogni installazione lo sia.

RFC 8509: interrogare il resolver, non indovinare

Il trust anchor è uno stato interno del resolver. Guardare un file può aiutare, ma non sempre dimostra quale istanza stia realmente rispondendo alle query degli utenti. Per questo è utile un’altra specifica: RFC 8509 definisce i root key trust anchor sentinel, nomi DNS speciali con cui un resolver compatibile può indicare se riconosce una determinata chiave.

Per KSK-2024, il key tag da testare è 38696. Su un resolver che supporta i sentinel e valida correttamente DNSSEC, una query con etichetta root-key-sentinel-is-ta-38696 dovrebbe ottenere una risposta valida quando la nuova chiave è fidata; la query speculare root-key-sentinel-not-ta-38696 dovrebbe invece produrre SERVFAIL. Qui il fallimento della seconda query è voluto: significa che il resolver ha riconosciuto la chiave che la domanda dichiara assente.

Cloudflare ha documentato un test pratico con il dominio firmato dnstest.dev e i controlli necessari a interpretarlo. È importante non saltare quella seconda metà: se il resolver non implementa RFC 8509, oppure non valida DNSSEC, un risultato ambiguo non dimostra affatto che KSK-2024 manchi. E una query diretta a 1.1.1.1 descrive quel resolver, non necessariamente il DNS usato dalla tua rete.

C’è poi il browser: DNS-over-HTTPS, VPN, configurazioni di sistema e policy aziendali possono instradare le richieste verso resolver diversi. Un test nel browser e un dig da terminale non devono per forza osservare lo stesso percorso. Prima di interpretare il risultato bisogna sapere quale resolver si sta misurando. Altrimenti si sta facendo diagnostica su una rete immaginaria.

Il controllo utile prima dell’11 ottobre

Non serve trasformare un rollover programmato in un’emergenza generalizzata. Serve un inventario ragionato. Chi non gestisce resolver DNSSEC validanti di norma non deve intervenire sulla propria applicazione web per questa rotazione; chi gestisce DNS aziendali, ISP, infrastrutture ricorsive o appliance con validazione deve verificare i sistemi sotto la propria responsabilità.

• Identifica i resolver effettivi usati da utenti, uffici, VPN, container e servizi interni. Non limitarti al DNS configurato sul tuo portatile.
• Verifica il trust anchor con key tag 38696 nello stato del software in esecuzione, non soltanto in un file di esempio. Per BIND, Unbound e altri resolver segui le istruzioni specifiche della versione.
• Controlla l’aggiornamento RFC 5011, la persistenza dello stato e gli eventuali errori nei log. Un processo configurato per aggiornarsi ma impossibilitato a scrivere non è un processo aggiornato.
• Esegui test dal percorso reale, distinguendo DNSSEC funzionante, supporto sentinel e presenza del nuovo anchor. Ripeti da reti differenti se hai utenze distribuite.
• Prepara un piano di diagnosi per eventuali SERVFAIL: confronto tra resolver, log di validazione, chiavi fidate, cambi recenti e rollback documentato. Evita di disabilitare DNSSEC alla cieca come prima risposta.

Netnod ha pubblicato indicazioni concrete per controllare BIND e Unbound. È un buon punto di partenza per verifiche specifiche, non un sostituto della documentazione del resolver installato. Se un sistema risulta non pronto, la correzione va pianificata e validata prima della data di cambio, senza introdurre modifiche avventate nell’ultima ora.

L’affidabilità è anche conoscere ciò che non controlli

Questa rotazione è stata annunciata con molto anticipo e accompagnata da una lunga fase di convivenza delle chiavi. È esattamente come dovrebbe funzionare la manutenzione di una dipendenza globale. Il problema interessante non è la sostituzione crittografica in sé, ma la differenza tra una procedura progettata per essere sicura e la capacità dei sistemi reali di attraversarla senza perdere stato.

L’11 ottobre non è previsto che Internet smetta di funzionare. È previsto che la root DNSSEC cambi la chiave con cui firma il proprio set DNSKEY. Il rischio concreto è circoscritto ai resolver validanti rimasti ancorati alla chiave vecchia; per chi li usa, però, il sintomo può sembrare un’interruzione totale.

Un cruscotto tutto verde non è una prova di affidabilità se misura soltanto ciò che controlliamo direttamente. Il DNS, le chiavi di fiducia, il resolver scelto dalla rete e i meccanismi di aggiornamento automatico fanno parte del servizio anche quando non compaiono nella dashboard. Il costo di non guardarli si presenta sempre nello stesso modo: si cerca il guasto nel posto sbagliato, mentre il sistema che stiamo controllando continua a funzionare benissimo.