Come risolvere errori DNSSEC Unbound e Root Hints

Quando si gestisce un resolver ricorsivo locale, è fondamentale saper risolvere errori DNSSEC Unbound per evitare il blocco totale della navigazione e garantire l’autenticità crittografica delle risposte ricevute. Unbound è uno dei server DNS più robusti e utilizzati, spesso implementato insieme a Pi-hole per blindare la rete domestica o aziendale. Tuttavia, discrepanze nell’orologio di sistema, trust anchor corrotti o elenchi root server obsoleti possono generare improvvisi errori SERVFAIL. Se stai cercando una panoramica più ampia sull’infrastruttura, consulta la nostra guida completa su debug Pi-hole e Unbound per comprendere a fondo le interazioni tra i due servizi.

Cosa sono DNSSEC e i Root Hints in Unbound

Unbound opera interrogando direttamente i server radice della gerarchia DNS mondiale, discendendo poi attraverso i domini di primo livello (TLD) fino ai server autoritativi del dominio richiesto. Questa architettura distribuita necessita di due componenti critici: i Root Hints e la convalida DNSSEC.

I Root Hints sono un elenco predefinito contenente gli indirizzi IPv4 e IPv6 dei 13 root server globali (da a.root-servers.net a m.root-servers.net). Se questo elenco non è raggiungibile, è corrotto o contiene puntatori obsoleti, Unbound non riesce a stabilire il contatto iniziale con la radice dell’albero DNS mondiale.

Dall’altro lato, DNSSEC (Domain Name System Security Extensions) introduce firme crittografiche (record RRSIG, DNSKEY, DS) per impedire attacchi di tipo DNS spoofing o cache poisoning. Se la catena di fiducia si interrompe o un record non supera la convalida, Unbound rifiuta categoricamente la risposta restituendo un errore di tipo SERVFAIL al client.

Diagnostica rapida: identificare la causa del fallimento

Prima di modificare i parametri di configurazione, è opportuno analizzare i registri di sistema per isolare il problema tra indisponibilità dei root server o un vero e proprio errore di firma crittografica. Utilizzando il comando seguente è possibile monitorare le anomalie in tempo reale:

sudo journalctl -u unbound -e –no-pager

Tra le righe del log potrebbero comparire messaggi inequivocabili come validation failure: no keys have been validated oppure iterator: failed to resolve . at root server. In queste circostanze, adottare le giuste strategie utili a risolvere errori DNSSEC Unbound evita di disattivare la sicurezza per disperazione.

Verifica manuale con l’utility dig

Per testare se il problema risiede esclusivamente nella validazione DNSSEC, si può inviare una query mirata utilizzando il flag +cd (Checking Disabled), che ordina a Unbound di ignorare il controllo crittografico:

dig @127.0.0.1 -p 5335 sigfail.verteiltesysteme.net +dnssec
dig @127.0.0.1 -p 5335 sigfail.verteiltesysteme.net +cd

Nel primo comando, progettato per fallire, Unbound deve restituire SERVFAIL con status NOERROR assente. Nel secondo comando con flag +cd, se il server risponde correttamente fornendo l’IP, significa che il trasporto di rete funziona e il problema è limitato alla validazione crittografica.

Sincronizzazione oraria: il principale colpevole dei fallimenti DNSSEC

Le firme digitali dei record DNSSEC possiedono finestre di validità temporale molto stringenti (not before e not after). Se l’orologio interno del server o del dispositivo Raspberry Pi differisce anche solo di pochi minuti rispetto all’ora UTC reale, tutte le firme crittografiche appariranno scadute o non ancora valide nel futuro.

I computer a scheda singola come Raspberry Pi spesso non dispongono di una batteria tampone (RTC). Al riavvio dopo un’interruzione di corrente, la data di sistema potrebbe resettarsi a valori passati, rendendo impossibile validare qualsiasi record e bloccando persino la sincronizzazione NTP se il pool orario viene cercato via DNS. Pertanto, verificare l’orario di sistema per risolvere errori DNSSEC Unbound rappresenta il primo controllo obbligatorio da effettuare.

  1. Verificare lo stato dell’orologio con il comando timedatectl status.
  2. Accertarsi che la voce NTP service risulti attiva e sincronizzata.
  3. Se l’orologio è bloccato, impostare provvisoriamente l’orario via IP o forzare la sincronizzazione NTP tramite un server esplicito: sudo date -s '2025-01-01 12:00:00'.

Rigenerazione dei Trust Anchor e del file root.key

Unbound memorizza la chiave pubblica del root anchor per iniziare la catena di fiducia. Se il file root.key si corrompe o perde i permessi di lettura e scrittura dell’utente di servizio, la convalida fallisce sistematicamente. Per ripristinare il file ufficiale mantenuto da IANA, si utilizza l’utility dedicata unbound-anchor.

sudo -u unbound unbound-anchor -a /var/lib/unbound/root.key -v

Se il file non esiste o l’eseguibile segnala errori di certificato, è possibile ricrearlo cancellando la vecchia istanza e rieseguendo l’aggiornamento. Assicurati che l’utente di sistema unbound mantenga la proprietà esclusiva sulla directory e sul file:

sudo chown unbound:unbound /var/lib/unbound/root.key
sudo chmod 644 /var/lib/unbound/root.key

Aggiornamento manuale del file Root Hints

Se Unbound non riesce a raggiungere i root server o se l’installazione locale include un file hints obsoleto, un passaggio essenziale per risolvere errori DNSSEC Unbound consiste nell’aggiornamento manuale del catalogo radice IANA. Questa operazione garantisce che gli indirizzi Anycast siano perfettamente allineati con l’attuale topologia internet mondiale.

Puoi scaricare l’elenco ufficiale aggiornato direttamente tramite curl o wget e posizionarlo nel percorso designato dalla configurazione:

sudo curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.root
sudo chown unbound:unbound /var/lib/unbound/root.hints

Controlla che all’interno del file di configurazione principale (solitamente /etc/unbound/unbound.conf.d/pi-hole.conf o /etc/unbound/unbound.conf) la direttiva punti correttamente alla posizione del file scaricato:

root-hints: “/var/lib/unbound/root.hints”

Ottimizzazione delle direttive DNSSEC nella configurazione

Alcuni firewall casalinghi, router forniti dagli ISP o filtri upstream alterano i pacchetti DNS troncando le risposte superiori a 512 byte (dimensione standard UDP senza estensioni EDNS0). DNSSEC richiede payload nettamente superiori a causa dell’inclusione delle chiavi crittografiche. Se il router blocca o frammenta i pacchetti EDNS0, Unbound non riuscirà mai a completare l’handshake di convalida.

Apri il file di configurazione di Unbound e assicurati di includere o verificare i seguenti parametri ottimizzati:

  • edns-buffer-size: 1232: previene la frammentazione dei pacchetti UDP e rispetta gli standard DNS moderni.
  • harden-dnssec-stripped: yes: blocca i tentativi di man-in-the-middle che cercano di rimuovere le estensioni DNSSEC.
  • auto-trust-anchor-file: "/var/lib/unbound/root.key": delega ad Unbound la gestione automatica e l’aggiornamento delle chiavi secondo RFC 5011.
  • val-clean-additional: yes: elimina i dati non firmati dalle risposte per impedire contaminazioni della memoria cache.

Dopo aver salvato le modifiche, esegui sempre la verifica della sintassi prima di riavviare il demone:

sudo unbound-checkconf
sudo systemctl restart unbound

Automazione della manutenzione con Cron

I server root cambiano indirizzi IP molto raramente, tuttavia è considerata una buona pratica rinnovare i Root Hints periodicamente (ad esempio ogni sei mesi). Puoi predisporre un semplice script in /etc/cron.monthly/update-root-hints:

#!/bin/bash
curl -s -S -o /var/lib/unbound/root.hints.new https://www.internic.net/domain/named.root
if [ -s /var/lib/unbound/root.hints.new ]; then
  mv /var/lib/unbound/root.hints.new /var/lib/unbound/root.hints
  chown unbound:unbound /var/lib/unbound/root.hints
  systemctl reload unbound
fi

Ricorda di assegnare i permessi di esecuzione allo script mediante sudo chmod +x /etc/cron.monthly/update-root-hints.

Riepilogo e buone pratiche

Mantenere un resolver autonomo permette di proteggere la propria privacy online e aggirare i filtri imposti dai fornitori commerciali. Tuttavia, la precisione crittografica di DNSSEC non tollera disallineamenti di orologio o dati di bootstrapping errati. Sapere esattamente come risolvere errori DNSSEC Unbound assicura la massima affidabilità dell’infrastruttura di rete senza mai dover sacrificare l’integrità dei record ricercati.

Articoli simili