Che cos'è Unbound DNS? Perche dovrebbe essere installato?

Unbound è un resolver DNS ricorsivo e validante che risolve i nomi interrogando direttamente la gerarchia DNS, invece di appoggiarsi sempre a un resolver upstream del provider. In pratica può diventare il punto locale di risoluzione per server, reti domestiche, firewall e infrastrutture hosting dove contano controllo, latenza prevedibile e verifica delle risposte.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Che cosa fa davvero Unbound

Il DNS tradizionale viene spesso usato in modo passivo: il sistema operativo inoltra la query a un resolver esterno e si fida della risposta. Unbound cambia il modello. Mantiene una cache, interroga i server autoritativi quando serve, applica validazione DNSSEC e può limitare il comportamento a seconda delle policy che gli imponi. Il risultato è un componente che non si limita a “girare le richieste”, ma decide come e quanto fidarsi delle risposte DNS.

Questo lo rende interessante in tre scenari tipici: un server Linux che non vuoi dipenda dal DNS del provider, una rete dove vuoi ridurre il leak di query verso terzi, oppure un ambiente in cui la validazione DNSSEC è utile per intercettare risposte manipolate o incoerenti.

Perché installarlo su Linux

La domanda vera non è “serve sempre?”, ma “quale problema risolve nel tuo caso?”. Unbound ha senso quando vuoi almeno uno di questi obiettivi:

• ridurre la dipendenza dai resolver del provider o da infrastrutture esterne poco controllabili;
• avere cache DNS locale con latenza più stabile per lookup ripetuti;
• validare DNSSEC senza delegare la verifica a un resolver remoto;
• separare il traffico DNS interno da quello Internet, ad esempio in una LAN o in un cluster;
• costruire una base affidabile per altri servizi Linux che fanno molte risoluzioni: web server, mail server, monitoraggi, agenti di backup, orchestratori.

In ambienti piccoli il vantaggio più percepibile è la cache. In ambienti più seri, il vantaggio vero è l’architettura: sai chi risolve, come risolve, cosa logga e quale politica applica quando una risposta sembra sospetta.

Quando Unbound non è la scelta giusta

Non va scelto per moda. Se ti serve solo un DNS forwarder minimale per una rete minuscola, o se hai già un resolver centralizzato ben gestito e monitorato, aggiungere Unbound su ogni host può essere ridondante. Inoltre, se non hai alcuna esigenza di validazione o cache locale, il beneficio può essere marginale rispetto alla complessità operativa introdotta.

Altro punto pratico: Unbound non sostituisce il DNS autoritativo. Non pubblica zone verso Internet come farebbe BIND in modalità authoritative. È un resolver, non un nameserver autoritativo. Se il problema è ospitare record pubblici, stai guardando il componente sbagliato.

Architettura mentale: resolver, cache e validazione

Per capire perché installarlo, conviene separare tre funzioni che spesso vengono confuse.

• Ricorsione: Unbound segue il percorso DNS fino agli autoritativi, invece di chiedere a un resolver upstream di farlo al posto suo.
• Cache: memorizza risposte e referral per ridurre traffico e tempi di risposta.
• Validazione: verifica la catena di fiducia DNSSEC quando i domini la supportano.

Queste tre funzioni si combinano bene, ma hanno implicazioni operative. La cache migliora la velocità ma può trattenere risposte vecchie fino alla loro scadenza TTL. La validazione aumenta l’affidabilità ma può far emergere problemi di firma, clock sballato, configurazioni errate o domini non coerenti. La ricorsione diretta aumenta l’autonomia ma rende più importante il controllo di rete verso Internet e verso le porte UDP/TCP 53.

Installazione base su Linux

Su molte distribuzioni Unbound è nei repository ufficiali. L’installazione tipica è lineare.

sudo apt update
sudo apt install unbound

Su sistemi RHEL-like il nome del pacchetto resta spesso identico.

sudo dnf install unbound

Dopo l’installazione, il punto non è avviarlo e basta. Prima conviene verificare dove si trova la configurazione attiva e quali unità systemd sono presenti.

systemctl status unbound
unbound-checkconf
unbound -V

Cosa aspettarsi: `systemctl status unbound` deve mostrare il servizio attivo o almeno installato; `unbound-checkconf` deve chiudersi senza errori; `unbound -V` ti dice se il binario è compilato con DNSSEC, libevent, Python module o altre opzioni utili.

Configurazione minima sensata

Una configurazione base non dovrebbe essere un collage di opzioni prese a caso. Il minimo sensato è: ascolto locale o su interfacce controllate, cache attiva, validazione DNSSEC, logging essenziale e, se serve, forwarding verso upstream fidati solo per alcuni domini o in scenari particolari.

server:
  interface: 127.0.0.1
  interface: ::1
  access-control: 127.0.0.0/8 allow
  access-control: ::1 allow
  verbosity: 1
  hide-identity: yes
  hide-version: yes
  prefetch: yes
  auto-trust-anchor-file: "/var/lib/unbound/root.key"

Questa base serve soprattutto per uso locale sul server. Se vuoi che altri host della LAN usino Unbound, devi cambiare l’interfaccia di ascolto e i controlli di accesso. Qui va fatta attenzione: esporre un resolver ricorsivo su Internet è una pessima idea. Su rete interna, invece, può essere perfettamente corretto se limiti le sorgenti autorizzate.

Un file come `root.key` è il punto di ancoraggio per DNSSEC. Se manca o è corrotto, la validazione può fallire. Non è un dettaglio cosmetico: è il cuore della fiducia.

Test pratici dopo l’avvio

Dopo aver avviato il servizio, la prima verifica concreta è capire se risponde e se la cache funziona.

dig @127.0.0.1 example.com
dig @127.0.0.1 example.com +dnssec
unbound-control stats_noreset

Se il resolver è attivo, `dig` deve restituire una risposta valida con tempi ragionevoli. Con `+dnssec` puoi vedere se il dominio pubblica dati DNSSEC e se la catena viene gestita correttamente. `unbound-control stats_noreset` è utile per leggere cache hit, miss e altre metriche senza resettare i contatori.

Su sistemi ben configurati, un secondo `dig` sullo stesso nome tende a essere più rapido del primo. Non è una prova assoluta, ma è un buon segnale che cache e ricorsione stanno lavorando come previsto.

Perché un resolver locale migliora spesso l’esperienza reale

Molti guardano solo alla latenza media del DNS, ma il dato più utile è la variabilità. Un resolver locale ben configurato tende a ridurre il jitter nelle risoluzioni ripetute. Questo pesa in modo concreto su applicazioni che aprono molte connessioni brevi o fanno lookup frequenti: web stack PHP, processi di posta, agenti di monitoraggio, container che si avviano e parlano con servizi esterni, script di deploy che devono risolvere endpoint API.

In pratica, anche se il singolo lookup DNS sembra una cosa piccola, accumulato su centinaia o migliaia di richieste al minuto diventa un fattore di performance. Unbound serve proprio a togliere rumore da questo pezzo della catena.

DNSSEC: utile, ma non magico

La validazione DNSSEC è una delle ragioni più solide per usare Unbound, ma va capita bene. Non ti protegge da tutto: non blocca phishing, non rende sicuri i contenuti web e non sostituisce TLS. Ti protegge però da una classe precisa di manipolazioni DNS, cioè risposte che non sono coerenti con la catena di firme attesa.

Il punto operativo è che DNSSEC introduce anche nuovi motivi di guasto apparente. Se l’orologio di sistema è fuori sync, se una zona è firmata male, se la trust anchor non è aggiornata o se la rete intercetta male le risposte, puoi vedere errori di validazione. Per questo, in ambiente serio, un resolver validante va sempre accompagnato da log e controlli minimi sul tempo di sistema.

Unbound come componente di rete interna

In una LAN o in un’infrastruttura server, Unbound può diventare un servizio condiviso. La configurazione cambia un po’: ascolto su IP di management o su interfaccia interna, ACL strette, magari forwarding selettivo per domini aziendali, e integrazione con DHCP o con i profili dei client.

Questa scelta è utile quando vuoi centralizzare la risoluzione per host che non possono o non devono parlare direttamente con resolver esterni. È anche comoda se vuoi avere un punto unico da monitorare. Il rovescio della medaglia è evidente: se quel nodo cade, la rete sente il problema. Quindi in ambienti seri conviene prevedere ridondanza, almeno due resolver interni e una gestione chiara del failover lato client o lato DHCP.

Monitoraggio essenziale

Installare Unbound senza osservabilità è metà lavoro. I controlli minimi da tenere d’occhio sono semplici:

• stato del servizio con `systemctl status unbound`;
• errori di startup in journal con `journalctl -u unbound -b`;
• cache hit/miss e query rate con `unbound-control stats_noreset`;
• latenza percepita dai client con `dig` o metriche del tuo sistema di monitoring;
• errori DNSSEC, timeout e risposte servfail nei log.

Se vuoi una metrica concreta, guarda almeno il tasso di errori e il tempo medio di risposta dei lookup ricorrenti. Non basta sapere che il processo è “up”: un resolver che risponde male è quasi peggio di un resolver fermo, perché introduce guasti intermittenti e difficili da leggere.

Errori tipici e come leggerli

Tre errori ricorrenti meritano attenzione. Primo: Unbound parte ma non risponde, spesso per ACL o interface sbagliate. Secondo: le query vanno in timeout, di solito per firewall, routing o problemi verso gli autoritativi. Terzo: DNSSEC fallisce, spesso per trust anchor, ora di sistema o problemi di firma di una zona specifica.

Quando qualcosa non torna, non partire dalla config “a intuito”. Parti da quello che vede il sistema. Un set rapido di verifiche è questo:

ss -lntup | grep ':53'
journalctl -u unbound -b --no-pager | tail -n 50
dig @127.0.0.1 cloudflare.com
unbound-control status

Se la porta 53 non ascolta, il problema è a monte del DNS. Se il servizio ascolta ma `dig` fallisce, guarda ACL, firewall e log. Se `unbound-control` non risponde, manca spesso il socket di controllo o la relativa configurazione.

Perché conviene in hosting e sysadmin

Nel lavoro quotidiano da sysadmin, Unbound ha un vantaggio poco glamour ma molto reale: riduce la dispersione. Invece di lasciare che ogni macchina si affidi a resolver diversi e poco tracciabili, puoi costruire un punto di risoluzione coerente. Questo semplifica troubleshooting, analisi dei tempi di risposta, verifica dei record, gestione di split DNS e diagnosi di problemi intermittenti.

Nel contesto hosting, poi, la differenza si nota quando un’applicazione fa molte chiamate esterne: se il DNS è instabile, l’intero stack sembra più lento o più fragile di quanto sia in realtà. Unbound non cura l’applicazione, ma toglie un fattore di disturbo dalla catena.

Conclusione pratica: quando installarlo

Installa Unbound quando vuoi un resolver locale affidabile, quando ti interessa la validazione DNSSEC, quando hai bisogno di controllo sulla risoluzione o quando vuoi centralizzare e osservare meglio il traffico DNS. Evitalo invece se stai cercando solo un componente in più senza un obiettivo operativo chiaro.

La regola buona è semplice: se il DNS per te è solo un dettaglio invisibile, Unbound può sembrarti superfluo; se invece il DNS è una dipendenza che vuoi governare, allora Unbound è uno dei pezzi più utili da mettere su Linux.