Risolvere gli Errori di Connessione Unbound su Pi-hole

Configurare un resolver DNS ricorsivo locale garantisce la massima riservatezza e autonomia, ma non è raro imbattersi in errori di connessione unbound durante la comunicazione sulla porta dedicata con la propria istanza di Pi-hole. Quando l’architettura si blocca improvvisamente, i client della rete locale non riescono più a risolvere alcun dominio, lasciando gli utenti senza navigazione web. Per una visione d’insieme su tutta la configurazione e sul recupero del sistema, puoi sempre consultare la nostra guida completa al debug di Pi-hole e Unbound, mentre in questo articolo ci concentreremo in modo analitico e chirurgico sulle anomalie della porta 5335 e sulle risposte di tipo SERVFAIL.

Anatomia del problema: perché la porta 5335 smette di rispondere

Nella configurazione standard consigliata per l’accoppiata Pi-hole e Unbound, il primo agisce da sinkhole e server DNS forwarder per la rete locale sulla porta 53, mentre il secondo opera come resolver ricorsivo puro in ascolto sull’interfaccia di loopback alla porta 5335. Questa suddivisione consente di separare il filtraggio pubblicitario dall’interrogazione gerarchica dei root server DNS mondiali.

Quando si verificano interruzioni, Pi-hole registra solitamente tentativi falliti di inoltro con risposte pari a zero o flag di errore persistenti. Le cause primarie possono essere categorizzate in tre gruppi distinti:

• Mancata esecuzione del servizio Unbound: un crash del processo o un errore di sintassi nei file di configurazione impedisce al demone di avviarsi.
• Binding errato sull’interfaccia di rete: Unbound è in ascolto solo su indirizzi specifici (o esclusivamente su socket IPv6), rifiutando le chiamate IPv4 provenienti da Pi-hole.
• Blocco del firewall locale: regole restrittive iptables, nftables o UFW bloccano le trasmissioni sul socket di loopback.

Un test rapido per verificare se il socket locale è attivo consiste nell’interrogare direttamente Unbound bypassando Pi-hole con un comando terminale dedicato.

Diagnostica di base: verificare lo stato del demone e del socket

Quando si manifestano errori di connessione unbound, la prima verifica consiste nel verificare se il demone è effettivamente in esecuzione e vincolato all’indirizzo IP corretto. Apri il terminale del server Linux (ad esempio un Raspberry Pi o una macchina virtuale Debian/Ubuntu) ed esegui i controlli descritti di seguito.

Controllo dello stato con systemd

Verifica che il servizio sia attivo e non si trovi in stato di fallimento ciclico:

sudo systemctl status unbound

Se il servizio risulta active (running), il demone è operativo a livello di sistema operativo. Se invece risulta failed o inactive, il problema risiede quasi certamente in una direttiva malformata all’interno dei file inclusi nella directory /etc/unbound/unbound.conf.d/.

Verifica delle porte di ascolto

Accertati che Unbound sia realmente in ascolto sulla porta non standard 5335 attraverso l’utility ss:

sudo ss -tulpn | grep 5335

L’output corretto deve mostrare sia il protocollo UDP sia TCP associati all’indirizzo IP di loopback 127.0.0.1:5335 (e opzionalmente [::1]:5335). Se l’output è vuoto, Unbound è configurato sulla porta predefinita 53 (entrando in conflitto con Pi-hole) oppure è vincolato a un’interfaccia errata.

Risolvere il codice SERVFAIL con i test Dig

L’errore SERVFAIL (Server Failure) indica che Unbound è attivo e risponde sulla porta 5335, ma non è in grado di completare la risoluzione ricorsiva partendo dai root server fino ai server autoritativi del dominio richiesto.

Per diagnosticare la causa esatta, invia una query manuale tramite lo strumento dig specificando esplicitamente la porta e l’indirizzo locale:

dig @127.0.0.1 -p 5335 nic.it

Esamina la sezione flags: e il campo status: della risposta. Se lo status restituito è SERVFAIL, la radice del problema risiede generalmente in uno dei seguenti scenari tecnici:

• Mancata connettività verso l’esterno sulla porta 53 UDP/TCP: Unbound deve poter contattare liberamente qualsiasi server DNS nel mondo. Se il tuo router domestico o il provider applica politiche di DNS intercept o blocca le chiamate verso server DNS terzi, Unbound non riceverà risposta.
• Disallineamento dell’orologio di sistema (NTP): la validazione crittografica DNSSEC richiede un orario estremamente preciso. Se l’RTC del sistema è sfasato anche solo di poche ore, tutti i certificati DNSSEC risulteranno scaduti o non ancora validi.
• Trust Anchor DNSSEC non aggiornato: la chiave di validazione root locale è corrotta o assente.

Configurazione corretta del file pi-hole.conf

Spesso le discrepanze emergono dalla modifica errata dei parametri specifici necessari per far cooperare i due software. Il file principale di riferimento deve essere collocato in /etc/unbound/unbound.conf.d/pi-hole.conf.

Assicurati che i parametri chiave siano configurati esattamente come segue:

server:  verbosity: 1  interface: 127.0.0.1  port: 5335  do-ip4: yes  do-udp: yes  do-tcp: yes  do-ip6: no  prefer-ip6: no  harden-glue: yes  harden-dnssec-stripped: yes  use-caps-for-id: no  edns-buffer-size: 1232  prefetch: yes  num-threads: 1

Correggendo queste discrepanze nella configurazione locale si evitano la maggior parte dei timeout che generano errori di connessione unbound tra i due servizi. Presta particolare attenzione alla direttiva do-ip6: se la tua rete domestica o il tuo ISP non supportano pienamente IPv6, impostare questo valore su yes costringe Unbound a tentare query verso indirizzi irraggiungibili, causando timeout continui e stati SERVFAIL su moltissimi domini.

Aggiornamento del Trust Anchor DNSSEC e verifica dell’orario

Un database delle chiavi corrotto o una discrepanza temporale sull’host rappresentano una causa comune che innesca errori di connessione unbound sotto forma di rigetti crittografici. Molti dispositivi a scheda singola come Raspberry Pi non possiedono una batteria tampone hardware (RTC), pertanto al riavvio dipendono interamente dalla sincronizzazione NTP via rete.

Verifica della sincronizzazione NTP

Esegui il comando:

timedatectl status

Assicurati che la voce NTP service: active e System clock synchronized: yes siano presenti. In caso contrario, riavvia il servizio di sincronizzazione oraria con sudo systemctl restart systemd-timesyncd.

Ripristino manuale delle chiavi DNSSEC

Se l’orario è corretto ma la validazione fallisce, forza l’aggiornamento del file root.key eseguendo da terminale:

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

Riavvia poi Unbound per rendere effettive le modifiche:

sudo systemctl restart unbound

Analisi avanzata dei log congiunti

Qualora i test precedenti non abbiano individuato l’anomalia, l’ispezione dei registri eventi in tempo reale rappresenta la via maestra. Puoi visualizzare gli eventi registrati da Unbound filtrando i log di systemd:

sudo journalctl -u unbound.service -e --no-pager

Parallelamente, controlla se Pi-hole riceve o scarta i pacchetti esaminando il log DNS in ascolto continuo:

tail -f /var/log/pihole/pihole.log | grep 127.0.0.1#5335

Nei log potrai individuare se Pi-hole riporta stringhe come maximum number of concurrent DNS queries reached, il che suggerisce che Unbound è troppo lento a rispondere oppure che si è verificato un loop di risoluzione DNS causato dalla presenza di regole di conditional forwarding mal impostate nell’interfaccia grafica di Pi-hole.

Conclusioni e raccomandazioni

La configurazione combinata di Pi-hole e Unbound rappresenta uno dei baluardi più solidi per la tutela della privacy domestica, ma richiede un’architettura rigorosa e verificata. Seguendo questa sequenza metodica di analisi e monitoraggio potrai prevenire ed eliminare definitivamente gli errori di connessione unbound, assicurando una navigazione domestica fluida e sicura. Mantieni sempre aggiornato il sistema operativo ed evita modifiche manuali non documentate ai file di configurazione per preservare l’integrità del tuo resolver ricorsivo.