SERVFAIL DNSSEC dopo il rollover della KSK di root

Perché ora ogni query DNSSEC va in SERVFAIL

Se dal pomeriggio dell'11 ottobre 2026 il tuo resolver risponde SERVFAIL a ogni domanda, la causa più probabile è il rollover della KSK di root. Da quel giorno la zona root del DNS firma solo con la nuova chiave KSK-2024, key tag 38696. Un resolver che valida DNSSEC ma non ha 38696 tra i suoi trust anchor non riesce più a verificare la root. Per questo fallisce tutto, anche i domini che non sono firmati.

La KSK (key signing key) è la chiave che firma l'insieme delle chiavi DNSKEY della root. Un trust anchor è una chiave, o il suo hash, che il resolver accetta senza altre prove: è il punto di partenza di tutta la catena di fiducia. Se vuoi ripassare come una query scende dalla root fino al record finale, parti da come funziona il DNS, dalla root al singolo record.

Secondo ICANN il cambio è avvenuto l'11 ottobre 2026 alle 14:00 UTC, cioè alle 16:00 ora italiana. La pagina di IANA elenca KSK-2024 come attiva, con la nota "Signing since 2026-10-11". Già a fine luglio ICANN avvertiva che un resolver senza la nuova chiave va incontro a un fallimento totale della risoluzione.

Questa guida copre i resolver che si trovano più spesso su un VPS o in una rete di casa: systemd-resolved, Unbound (anche in Docker), BIND, dnsmasq e Pi-hole. Per ognuno vedi dove vive il trust anchor, se si aggiorna da solo, come cercare 38696 e come correggere. Tutti i comandi li esegui tu, sul tuo sistema. Non trovi output di esempio: per ogni comando trovi invece cosa cercare.

Sei davvero coinvolto? Prima controlla se validi DNSSEC

Il problema colpisce solo chi valida. Un resolver che non controlla le firme non usa i trust anchor, quindi il cambio di chiave non lo tocca.

Su Ubuntu 24.04 la pagina di manuale di resolved.conf dice che DNSSEC= ha come default no. Un Ubuntu lasciato come è stato installato, quindi, non è colpito. Sei esposto se tu, o uno script di provisioning, avete impostato DNSSEC=yes oppure DNSSEC=allow-downgrade. In entrambi i casi systemd-resolved valida.

Attenzione a un dettaglio. Il default no è una scelta di Ubuntu, non di systemd. Il default upstream si decide al momento della compilazione e vale allow-downgrade, quindi su altre distribuzioni il valore può essere diverso. Non dare per scontato quello di Ubuntu.

Mostra la configurazione effettiva, compresi tutti i drop-in:

systemd-analyze cat-config systemd/resolved.conf | grep -i '^DNSSEC'

Se non esce nessuna riga, o esce DNSSEC=no, systemd-resolved non valida. In quel caso il SERVFAIL ha un'altra causa, oppure arriva da un resolver a monte che valida al posto tuo.

Su Pi-hole v6 l'impostazione dns.dnssec vale false di default. BIND invece valida di default, e Unbound valida appena la sua configurazione contiene un trust anchor. Questi due controllali sempre.

Il sintomo: come riconoscere il problema della chiave

Su systemd-resolved interroga un nome qualsiasi:

resolvectl query example.com

Cerca nel messaggio d'errore un riferimento a DNSSEC. Il bug Launchpad #2170538, aperto il 12 ottobre 2026 per Ubuntu 24.04, riporta questo errore:

DNSSEC validation failed: missing-key

Il bug riporta lo stesso errore anche per i nomi non firmati. Il motivo è la struttura della catena. Ogni risposta, anche la prova che un dominio non è firmato, si verifica partendo dalla root. Se la root non si verifica, nessuna risposta si può dimostrare, quindi il resolver le scarta tutte.

Su Unbound, BIND o dnsmasq usa dig. Su Ubuntu si trova nel pacchetto bind9-dnsutils. Confronta una query normale con una che porta il bit CD (checking disabled), che chiede al resolver di non validare:

sudo apt install -y bind9-dnsutils
dig @127.0.0.1 example.com A
dig @127.0.0.1 example.com A +cd

Guarda il campo status: nell'intestazione di ogni risposta. Se la prima query dà SERVFAIL e la seconda dà NOERROR, il guasto è nella validazione e non nella rete. Sostituisci 127.0.0.1 con l'indirizzo su cui ascolta il tuo resolver.

Un orologio sbagliato produce lo stesso sintomo, perché ogni firma DNSSEC ha una data di inizio e una data di scadenza. Un server indietro di qualche giorno vede firme che per lui non sono ancora valide, e le rifiuta. Prima di toccare i trust anchor controlla l'ora con timedatectl. Se è sbagliata, segui la guida alla sincronizzazione dell'orologio su un VPS e ripeti il test.

Se i client di una VPN usano il tuo resolver, il guasto sembra un problema della VPN: il tunnel sale ma nessun nome si risolve. Verifica prima il resolver con i comandi di questa sezione. Solo se il resolver risponde bene ha senso passare a come sistemare il DNS dentro un tunnel WireGuard.

Perché alcuni resolver hanno la chiave e altri no

KSK-2024 non è arrivata all'improvviso. IANA indica che è stata generata il 26 aprile 2024 e pubblicata nella zona root l'11 gennaio 2025. Da allora la root conteneva due KSK, ma firmava ancora con la vecchia KSK-2017, key tag 20326.

Un resolver può imparare una nuova chiave da solo con l'RFC 5011. Il meccanismo è prudente. Il resolver deve vedere la nuova chiave, pubblicata insieme a una chiave di cui già si fida, per un periodo di attesa (hold-down) di 30 giorni. Solo dopo la aggiunge ai suoi trust anchor. Per questo IANA indica il 10 febbraio 2025 come la data in cui un resolver RFC 5011 poteva fidarsi di 38696. Un resolver sempre acceso, con l'aggiornamento automatico attivo, ha avuto la chiave con molti mesi di anticipo.

Chi è rimasto fuori ricade quasi sempre in uno di questi casi:

• Il trust anchor è statico: un file scritto a mano, o una chiave compilata nel programma. Un anchor statico non cambia mai da solo.
• Il resolver usa l'RFC 5011 ma non può scrivere il suo file degli anchor, quindi non riesce a salvare la nuova chiave.
• Il resolver è rimasto spento a lungo. Unbound, per esempio, esegue le verifiche RFC 5011 alcune volte al mese, e la sua documentazione chiede che la macchina sia online spesso.
• Il servizio riparte ogni volta da uno stato vecchio, come un container ricreato da un'immagine di anni fa.

Anche la chiave precedente è passata da un rollover. Il file root-anchors.xml di IANA dà KSK-2010 (key tag 19036) valida dal 15 luglio 2010 all'11 gennaio 2019. Se ti interessa come si è arrivati a firmare la root, leggi la storia del DNS e delle sue scelte di progetto.

Le prossime date: revoca e rimozione di KSK-2017

Il rollover non è finito. Oggi la pagina di IANA mostra KSK-2017 in stato "Post-Publication" e dice che resta un trust anchor valido. I passi successivi hanno date previste, non definitive:

• Revoca, prevista per l'11 gennaio 2027. KSK-2017 verrà pubblicata nella root con il bit REVOKE attivo. L'RFC 5011 dice che un resolver che vede quel bit non deve più usare la chiave come trust anchor, né per altro.
• Rimozione, prevista per il 22 marzo 2027. La chiave 20326 sparisce dalla zona root.

In pratica: un resolver che conosce solo 20326 è già rotto oggi, e quelle date non cambiano nulla per lui. Un resolver che conosce sia 20326 sia 38696 continua a funzionare. Dopo la rimozione la riga 20326 nei file che scrivi a mano non serve più, e puoi toglierla. Ricontrolla la pagina di IANA a gennaio, perché le date previste possono spostarsi.

systemd-resolved: il file .positive in /etc/dnssec-trust-anchors.d/

Dove vive il trust anchor

systemd-resolved ha una chiave di root integrata nel programma. La pagina di manuale dnssec-trust-anchors.d(5) spiega che la usa solo se nessun file definisce un trust anchor positivo per la root. I file si chiamano *.positive e vengono letti da /etc/dnssec-trust-anchors.d/, /run/dnssec-trust-anchors.d/ e /usr/lib/dnssec-trust-anchors.d/. Un file con lo stesso nome in una cartella che viene prima nell'elenco sostituisce quello della cartella successiva.

La chiave 38696 è entrata nell'anchor integrato con il commit upstream 8113361, "resolved: pick up new DNSSEC KSC from 2024", unito il 4 marzo 2025. La modifica fa parte di systemd 258, uscito il 17 settembre 2025. Ubuntu 24.04 usa systemd 255 e Ubuntu 22.04 usa systemd 249.

Al 13 ottobre 2026, su Launchpad i pacchetti pubblicati più recenti sono 255.4-1ubuntu8.17 per 24.04 e 249.11-0ubuntu3.22 per 22.04, entrambi del 10 agosto 2026. I loro changelog elencano solo correzioni di sicurezza e non parlano della chiave di root. Il bug #2170538 è "In Progress". Contiene patch proposte per 255.4-1ubuntu8.18 e 249.11-0ubuntu3.23 che riportano il commit upstream, ma nessun pacchetto corretto è stato pubblicato. Secondo i commenti del bug, Ubuntu 26.04 e Debian 12 hanno già la correzione. Questo non risulta ancora dalle pagine dei pacchetti, quindi controlla tu sul tuo sistema.

Il test di efraingaray.com, eseguito il 7 ottobre e aggiornato il 12 ottobre 2026, ha misurato l'effetto dal vivo. Un Ubuntu 24.04 con systemd-resolved e DNSSEC attivo ha iniziato a fallire circa 20 minuti dopo il primo controllo con la nuova chiave in uso: 332 SERVFAIL su 334 controlli. Ubuntu 26.04 ha continuato a validare, con un solo controllo senza risposta. Lo stesso articolo indica che anche il systemd-resolved dei pacchetti di Rocky 9 e Amazon Linux 2023 non ha la chiave.

Controlla la versione e i file esistenti

systemctl --version | head -n 1
apt policy systemd
ls -l /etc/dnssec-trust-anchors.d/ /run/dnssec-trust-anchors.d/ /usr/lib/dnssec-trust-anchors.d/ 2>/dev/null

La prima riga mostra la versione di systemd. Da apt policy guarda la riga Installed: e confrontala con la pagina del bug #2170538, per sapere se nel frattempo è uscito un pacchetto corretto. L'ultimo comando elenca i file di trust anchor già presenti. Se una di queste cartelle contiene già un file .positive con un record per la root, l'anchor integrato è già disattivato, e quel file decide tutto.

Copia il record DS da IANA

Il record si prende dal file ufficiale di IANA. Non scriverlo mai a memoria e non copiarlo da un forum: con un solo carattere sbagliato la root non si verifica più.

mkdir -p ~/ksk && cd ~/ksk
curl -fsSO https://data.iana.org/root-anchors/root-anchors.xml
grep -A 4 '<KeyTag>20326</KeyTag>' root-anchors.xml
grep -A 4 '<KeyTag>38696</KeyTag>' root-anchors.xml

Per ogni chiave cerca quattro valori: KeyTag, Algorithm, DigestType e Digest. Per 38696 IANA indica algoritmo 8 (RSASHA256) e tipo di digest 2 (SHA-256). Il Digest è una lunga stringa esadecimale: copiala con il copia e incolla.

Scrivi il file e riavvia

Il file deve contenere entrambe le chiavi. Appena definisci un qualunque trust anchor per la root, systemd-resolved smette di usare quello integrato. Un file con la sola 38696 toglierebbe quindi anche la fiducia in 20326, che IANA considera ancora valida fino alla revoca.

sudo mkdir -p /etc/dnssec-trust-anchors.d
sudo nano /etc/dnssec-trust-anchors.d/root.positive

Il formato documentato è un record per riga. Le righe vuote e quelle che iniziano con ; o # sono commenti. Sostituisci i segnaposto con i digest copiati da root-anchors.xml:

; KSK-2017, valida fino alla revoca prevista da IANA
. IN DS 20326 8 2 <digest di 20326 da root-anchors.xml>
; KSK-2024, la chiave che firma la root dall'11 ottobre 2026
. IN DS 38696 8 2 <digest di 38696 da root-anchors.xml>

Poi riavvia il servizio, svuota la cache e ripeti la query:

sudo systemctl restart systemd-resolved
resolvectl flush-caches
resolvectl query example.com

L'errore DNSSEC validation failed deve sparire e la risposta deve arrivare. Nel bug #2170538 un utente conferma che aggiungere il DS di IANA per 38696 riporta la risoluzione autenticata. Se l'errore resta, leggi journalctl -u systemd-resolved -n 50 e cerca righe che citano il tuo file. Di solito c'è un errore di battitura nel digest.

Quando arriva l'aggiornamento del pacchetto

Il file in /etc/ resta valido anche dopo l'aggiornamento. Ricorda però che, finché esiste, l'anchor integrato del pacchetto non viene usato. Quando apt policy systemd mostra installata una versione corretta, puoi decidere se tenerlo o rimuoverlo. Se gli aggiornamenti di sicurezza si installano da soli con unattended-upgrades su Ubuntu, controlla nel log che il nuovo pacchetto sia davvero arrivato prima di cancellare il file. In ogni caso, dopo la rimozione di KSK-2017 togli la riga 20326.

Unbound installato da pacchetto

Dove vive il trust anchor

Unbound ha due modi per tenere la chiave di root. auto-trust-anchor-file indica un file che Unbound aggiorna da solo con l'RFC 5011. trust-anchor-file e trust-anchor sono invece statici: contengono record DS o DNSKEY che non cambiano mai. La documentazione indica /usr/local/etc/unbound/root.key come percorso predefinito, ma i pacchetti delle distribuzioni usano altri percorsi. Fidati della tua configurazione:

sudo grep -rn 'trust-anchor' /etc/unbound/

Cerca la riga auto-trust-anchor-file: (oppure una delle varianti statiche) e annota il percorso. Poi controlla se il file contiene la nuova chiave:

ANCHOR=/percorso/letto/nella/configurazione/root.key
sudo grep 38696 "$ANCHOR"

Una o più righe con 38696 significano che la chiave c'è. Nessuna riga significa che Unbound non la conosce.

Il test di efraingaray.com mostra che conta il pacchetto, non il numero di versione di Unbound. Dopo un avvio pulito si fidavano di 38696 Debian 12 (Unbound 1.17.1), Ubuntu 24.04 (1.19.2) e Alpine 3.22 (1.25.2). Non se ne fidavano Amazon Linux 2023 (1.17.1), Alpine 3.20 (1.20.0) e Fedora 42 (1.24.2).

Correggere un file RFC 5011

Il file deve essere scrivibile dall'utente con cui gira Unbound. Se usi un chroot, il file deve stare dentro il chroot. Se Unbound non può scrivere il file, non può salvare la nuova chiave. Trova l'utente mentre Unbound è ancora acceso, poi aggiorna il file con unbound-anchor:

ps -o user= -C unbound
sudo systemctl stop unbound
sudo -u unbound unbound-anchor -v -a "$ANCHOR"
sudo grep 38696 "$ANCHOR"
sudo systemctl start unbound

Sostituisci unbound dopo -u con l'utente mostrato dal primo comando. unbound-anchor prova prima a verificare il file attuale. Se il file non funziona, tenta l'aggiornamento via DNS con l'RFC 5011. Se anche questo fallisce, scarica root-anchors.xml da data.iana.org via HTTPS e ne controlla la firma come indica l'RFC 7958. Il file cambia solo se tutti i controlli passano.

Un dettaglio importante: unbound-anchor termina con codice 0 anche in caso di errore. Non fidarti del codice di uscita. Fidati del grep che segue. Se 38696 ancora manca, leggi i messaggi stampati da -v: ti dicono se il programma non raggiunge i server root o data.iana.org. Il manuale documenta anche l'opzione -F, pensata per il debug, che forza il download del file XML.

Correggere un anchor statico

Se la configurazione usa trust-anchor-file: o trust-anchor:, aggiungi il record DS di 38696 copiato da root-anchors.xml, nello stesso formato dei record già presenti. Poi controlla la sintassi e riavvia:

sudo unbound-checkconf
sudo systemctl restart unbound

unbound-checkconf deve terminare senza errori prima del riavvio. Un file con un errore impedisce a Unbound di partire, e a quel punto non hai più nessun resolver.

Unbound in Docker con l'immagine mvance/unbound

L'immagine mvance/unbound esegue all'avvio questo comando:

/opt/unbound/sbin/unbound-anchor -a /opt/unbound/etc/unbound/var/root.key

La sua configurazione usa auto-trust-anchor-file: "var/root.key". Il test di efraingaray.com riporta che le immagini 1.17.1 (del 2023) e 1.20.0 (del 2024) non si fidavano di 38696 all'avvio, mentre i tag latest provati sì. Con la 1.17.1 i SERVFAIL sono iniziati circa 13 ore e mezza dopo il primo controllo con la nuova chiave. Su GitHub e su Docker Hub i tag più recenti non coincidono, quindi verifica il tag che usi tu e non fidarti del nome latest.

docker ps --format '{{.Names}}\t{{.Image}}'
docker exec NOME_CONTAINER cat /opt/unbound/etc/unbound/var/root.key

Il primo comando mostra il nome del container e l'immagine con il suo tag. Nel secondo, cerca 38696 nel contenuto del file. Se manca e usi Docker Compose, scegli un tag più recente nel tuo compose.yaml, poi scarica l'immagine e ricrea il container:

docker compose pull
docker compose up -d
docker exec NOME_CONTAINER cat /opt/unbound/etc/unbound/var/root.key

Ricontrolla sempre il file dopo la ricreazione. Se la cartella var/ è montata da un volume, il container riparte dal file che c'è nel volume. Se 38696 continua a mancare, esegui unbound-anchor con -v dentro il container, leggi cosa riporta e riavvia:

docker exec NOME_CONTAINER /opt/unbound/sbin/unbound-anchor -v -a /opt/unbound/etc/unbound/var/root.key
docker restart NOME_CONTAINER

BIND: managed-keys e dnssec-validation auto

In BIND l'opzione dnssec-validation vale auto di default, tranne quando è compilato con --disable-auto-validation: in quel caso vale yes. Con auto BIND usa una chiave di root predefinita, fornita con il programma e tenuta aggiornata con la gestione dinamica dei trust anchor, cioè l'RFC 5011. Lo stato delle chiavi seguite sta nel file managed-keys.bind.

Per vedere quali chiavi conosce BIND:

sudo rndc managed-keys status

Cerca 38696 nell'output e leggi lo stato associato. Se la chiave non c'è, il tuo BIND è partito da una chiave predefinita vecchia e non ha mai imparato la nuova. ICANN indica bind.keys come il file da controllare. Se nella configurazione hai un blocco trust-anchors, o i vecchi managed-keys e trusted-keys ora deprecati, controlla anche lì.

La correzione più pulita è aggiornare il pacchetto di BIND, controllare la configurazione e chiedere un nuovo controllo delle chiavi:

sudo named-checkconf
sudo rndc managed-keys refresh
sudo rndc managed-keys status

Se usi un blocco trust-anchors scritto da te, aggiungi 38696 seguendo il manuale di riferimento della tua versione di BIND. Con initial-key o initial-ds BIND tiene la chiave aggiornata con l'RFC 5011. Con static-key o static-ds la chiave resta fissa finché non la cambi tu.

dnsmasq e Pi-hole

dnsmasq

dnsmasq valida solo con l'opzione --dnssec (dnssec nel file di configurazione), e il manuale chiede di fornire i trust anchor con --trust-anchor. La distribuzione di dnsmasq include un file trust-anchors.conf con le chiavi di root, e il changelog chiede all'amministratore di controllare che siano legittime e aggiornate. Cerca dove la tua installazione definisce gli anchor:

grep -rn 'trust-anchor\|conf-file\|dnssec' /etc/dnsmasq.conf /etc/dnsmasq.d/ 2>/dev/null

Se trovi una riga conf-file= che punta a un altro file, apri quel file. Cerca una riga trust-anchor= che contenga 38696. Se manca, aggiungila nella sintassi documentata, --trust-anchor=<dominio>,[<classe>,]<key-tag>,<algoritmo>,<tipo-digest>,<digest>, con i valori presi da root-anchors.xml:

trust-anchor=.,38696,8,2,<digest di 38696 da root-anchors.xml>

Poi verifica la sintassi e riavvia:

dnsmasq --test
sudo systemctl restart dnsmasq

Pi-hole

Pi-hole usa al suo interno una versione integrata di dnsmasq. In Pi-hole v6 la validazione si controlla con dns.dnssec, che di default vale false. Se non l'hai mai attivata, il cambio di chiave non ti tocca. Controlla (se Pi-hole gira in Docker, esegui gli stessi comandi con docker exec dentro il container):

pihole -v
grep -n 'dnssec' /etc/pihole/pihole.toml

Il primo comando mostra le versioni dei componenti. Nel secondo cerca la riga dnssec della sezione [dns] e il suo valore. Se è true, cerca gli anchor:

sudo grep -rn 'trust-anchor' /etc/pihole/ /etc/dnsmasq.d/ 2>/dev/null

Il test di efraingaray.com ha trovato che un Pi-hole v5 (2024.07.0, v5.18.3) aveva nella configurazione solo la chiave 20326. Eppure ha continuato a validare durante tutta l'osservazione, e l'autore non ha saputo spiegare il motivo. Pi-hole v6 conteneva entrambe le chiavi e ha validato senza problemi. Al 13 ottobre 2026 l'ultima release di FTL è la v6.7.1, uscita il 19 settembre 2026. Se ti manca 38696, aggiorna Pi-hole: pihole -up su un'installazione diretta, oppure un'immagine più recente se usi Docker.

Esiste anche misc.dnsmasq_lines, che aggiunge righe alla configurazione di dnsmasq generata da Pi-hole. La documentazione avverte che righe duplicate o in conflitto possono bloccare dnsmasq e fermare tutta la risoluzione. Usala solo se l'aggiornamento non basta.

Il test sentinel: il tuo resolver si fida di 38696?

L'RFC 8509 definisce un modo per chiedere a un resolver quali chiavi di root considera fidate. Si interrogano nomi che iniziano con etichette speciali: root-key-sentinel-is-ta-38696 e root-key-sentinel-not-ta-38696. Il resolver interpreta l'etichetta solo a certe condizioni: la risposta deve validare come sicura, la query non deve avere il bit CD, il tipo richiesto deve essere A o AAAA e l'opcode deve essere QUERY. Il nome deve quindi stare sotto una zona firmata.

Cloudflare gestisce una zona di prova firmata, dnstest.dev, e documenta il test così. Punta @ al tuo resolver invece che a 1.1.1.1:

dig @127.0.0.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
dig @127.0.0.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer

Leggi lo status: di entrambe le risposte. Secondo Cloudflare, un resolver che si fida di KSK-2024 risponde normalmente alla query is-ta e dà SERVFAIL alla not-ta. Un resolver che non se ne fida fa il contrario. Esiste anche una versione nel browser, su dnstest.dev/ksk-2024, che prova il resolver usato dal browser.

Il test ha due limiti. Funziona solo con resolver che implementano l'RFC 8509. Unbound lo documenta, con root-key-sentinel attivo di default. Per systemd-resolved i manuali non lo citano, quindi non contarci. Poi c'è il caso ambiguo: un resolver senza 38696 va già in SERVFAIL su tutto, e quindi anche su entrambe le query. Per questo confronta sempre con un nome normale, come example.com. Cloudflare precisa che un risultato "inconclusive" non significa che la chiave manchi.

Spegnere DNSSEC è un tappabuchi, non la soluzione

Disattivare la validazione fa tornare la risoluzione in pochi secondi. È anche l'unica cosa che fa: il resolver smette di controllare le firme, quindi non può più riconoscere una risposta falsificata. Per i domini firmati perdi proprio la protezione per cui DNSSEC esiste. La modalità allow-downgrade non è un compromesso sicuro: il manuale di resolved.conf dice che rende la validazione vulnerabile ad attacchi di "downgrade".

Se il servizio è fermo e ti serve tempo, su systemd-resolved puoi spegnere DNSSEC con un drop-in temporaneo:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nDNSSEC=no\n' | sudo tee /etc/systemd/resolved.conf.d/90-dnssec-temporaneo.conf
sudo systemctl restart systemd-resolved

Su Pi-hole il comando documentato è sudo pihole-FTL --config dns.dnssec false. Appena il file .positive è a posto, cancella il drop-in, riavvia e rifai il test con resolvectl query. Un drop-in temporaneo che nessuno rimuove è il modo più comune di restare per anni senza validazione senza saperlo.

FAQ

Perché anche i domini non firmati vanno in SERVFAIL dopo il rollover della KSK?

Perché la validazione DNSSEC parte sempre dalla root. Per accettare un dominio non firmato, il resolver deve dimostrare che quel dominio non ha firme, e quella prova si verifica a partire dalla chiave di root. Se il resolver non ha 38696 tra i trust anchor, non riesce a verificare la root e scarta ogni risposta. Su systemd-resolved l'errore riportato nel bug Launchpad #2170538 è DNSSEC validation failed: missing-key.

Ubuntu con le impostazioni di default è colpito?

Su Ubuntu 24.04 no: il manuale di resolved.conf indica DNSSEC=no come default, quindi systemd-resolved non valida e non usa i trust anchor. Sei colpito se hai impostato DNSSEC=yes o DNSSEC=allow-downgrade. Controlla con systemd-analyze cat-config systemd/resolved.conf | grep -i '^DNSSEC'. Al 13 ottobre 2026 i pacchetti systemd pubblicati per Ubuntu 22.04 e 24.04 non contengono la chiave 38696.

Come aggiungo la chiave 38696 a systemd-resolved?

Scarica root-anchors.xml da data.iana.org e copia da lì i valori delle chiavi 20326 e 38696, senza scriverli a memoria. Crea /etc/dnssec-trust-anchors.d/root.positive con una riga . IN DS per ciascuna chiave, poi riavvia systemd-resolved e ripeti resolvectl query. Metti entrambe le chiavi, perché un file con un anchor per la root disattiva l'anchor integrato.

Quando viene revocata KSK-2017 e devo fare qualcosa?

IANA prevede la revoca di KSK-2017 (key tag 20326) per l'11 gennaio 2027 e la sua rimozione dalla root per il 22 marzo 2027. Sono date previste e possono cambiare. Se il tuo resolver conosce già 38696, non devi fare nulla. Dopo la rimozione puoi togliere la riga 20326 dai file che hai scritto a mano.

Posso semplicemente disattivare DNSSEC?

Puoi farlo per qualche ora, per rimettere in piedi un servizio fermo. La risoluzione torna, ma il resolver non controlla più nessuna firma e non riconosce le risposte falsificate. È un tappabuchi. La soluzione è aggiungere 38696 ai trust anchor, poi riattivare la validazione e verificarla con un test.