Unbound e Pi-hole: una soluzione DNS completa (Fix 15/06/2023)

unbound_image

Facendo uso del pi-hole, saprete che le vostre richieste effettuate dai vostri client (pc, smartphone, smart tv, etc) vengono inviate ai server DNS configurati (come ad esempio: Cloudflare, Quad9, Opendns etc), ma tutto questo come indicato da diversi utenti nei commenti di questo stesso sito web porta ad alcuni problemi anche gravi:

  • Problemi di privacy: Il server dns che hai scelto in fase di installazione e configurazione del pi-hole è veramente sicuro e mantiene realmente le sue promesse di non registrare e usare i dati di navigazione? Ah giusto… non puoi.
  • Problemi di hacking: Un utente malintenzionato (un hacker), potrebbe avvelenare un server DNS in modo che l’indirizzo IP di alcuni siti web come le banche, non corrispondano a quello reale, ma bensì otterrete un indirizzo ip fasullo (fake) e quindi verresti re-indirizzato a un sito di phishing. Questo scenario si è già verificato e non è improbabile che accada di nuovo…

Qual’è la soluzione?

Creare un server dns ricorsivo sul nostro raspberry pi o orange pi, o etc. dove è installato il Pi-hole a costo zero, le probabilità che venga attaccato sono veramente ridotte al minimo.

Per farlo quindi cosa installeremo?

Unbound (un software open source, sicuro e sviluppato principalmente da NLnet Labs, VeriSign Inc., Nominet e Kirei), che crea un server DNS ricorsivo. Esso cercherà l’ip del sito web, server, dominio etc. chiedendo direttamente ai server TLD (Top-level domain) in maniera ricorsiva. Nella risoluzione ricorsiva, la risposta avviane tramite name server che abbiano “l’autorità” nel rispondere.

Non mi è ancora chiaro, come si comporta un server dns ricorsivo?

Un servizio DNS ricorsivo come unbound, non è proprietario dei record DNS, e nel nostro caso solo i client (pc, smartphone etc,) che sono collegati al modem/router di casa (in lan o wi-fi), possono effettuare richieste.Unbound è un semplice intermediario da cui è possibile ottenere informazioni. Se il riferimento del sito web che vogliamo visitare è memorizzato nella cache, egli stesso risponderà alla query fornendo l’IP, in caso contrario, inoltrerà la query a uno o più server autorevoli fino a quando recupererà l’informazione richiesta.

Ok, ok! Bel discorso, ma quali svantaggi ci sono?

L’uso di un DNS ricorsivo può essere lento, soprattutto per la prima volta che visiti un sito web, rispetto ai provider DNS che hanno sempre le risposte per i domini di uso comune nella loro cache. La prima richiesta a un TLD precedentemente sconosciuto può richiedere fino a un secondo (o anche di più se utilizzi anche DNSSEC). Le richieste successive ai domini sotto lo stesso TLD di solito vengono completate in <0,1 secondi. Fortunatamente, sia il tuo Pi-hole che il tuo server ricorsivo possiedono una cache efficiente per memorizzare i dati necessari, e questo riduce al minimo il numero di query che dovranno essere effettivamente eseguite.

Installazione di unbound

AVVISO: Devo ovviamente segnalarvi per motivi legali (non si sà mai che qualcuno mi denunci per danni) che non sono assolutamente responsabile di qualsiasi danno e/o problema hardware e/o software causato al vostro sistema (qualsiasi esso sia, solo come esempio: raspberry/server/pc/etc.).

Faccio presente che l’installazione del software presente è stato testato personalmente, ed è anche in funzione sul mio raspberry, ma è sempre possibile incorrere in problemi.

Prima di installare il pacchetto di unbound, DOVETE effettuare questi comandi i quali sono realmente necessari per non incorrere in problemi durante l’installazione (cosa che a me è accaduta perché non avevo il sistema aggiornato, ed è stato un vero delirio uscirne):

sudo apt update

e poi:

sudo apt full-upgrade -y

Una volta che il vostro sistema operativo (come ad esempio raspbianOS per il raspberry) sarà aggiornato, possiamo procedere all’installazione del software effettuando il seguente comando:

sudo apt install unbound

come nello screenshot seguente:

screenshot comando: sudo apt install unbound

Potresti come nel mio caso, incorrere in alcuni errori (anche se hai effettuato update del sistema), non ti preoccupare, saranno risolti continuando a seguire questa guida/procedura (effettuando i relativi comandi segnalati).

Con questo comando verrà installato e compilato il file root.hints, questo file conterrà una lista dei server root primari, necessari per inizializzare la cache dei server dei nomi di dominio su Internet:

wget https://www.internic.net/domain/named.root -qO- | sudo tee /var/lib/unbound/root.hints

come nello screenshot seguente:

screenshot comando wget https://www.internic.net/domain/named.root -qO- | sudo tee /var/lib/unbound/root.hints

Ora è necessario impostare e creare il file di log per unbound, questo ci potrà tornare utile in caso di debug cioè, in caso di problemi, sarà possibile analizzare il file di log per capire cosa sia andato storto:

sudo mkdir -p /var/log/unbound
sudo touch /var/log/unbound/unbound.log
sudo chown unbound /var/log/unbound/unbound.log

Creare e impostare il file usr.sbin.unbound eseguendo il comando:

sudo nano /etc/apparmor.d/local/usr.sbin.unbound

e copiare il seguente testo

/var/log/unbound/unbound.log rw,

Salvare e uscire (premere i tasti Ctrl X e poi S per confermare).

Adesso è fondamentale creare e impostare il file di configurazione pi-hole.conf eseguendo il comando:

sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

Qui sarà essenziale copiare e incollare il seguente testo:

server:
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound/unbound.log"
    verbosity: 1

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

Salvare e uscire (premere i tasti Ctrl X e poi S per confermare).

Si segnala che il testo segnalato rappresenta la configurazione standard, è possibile effettuare alcune modifiche in base alle proprie esigenze (come ad esempio aumentare la cache, etc.), non inserire o modificare o aggiungere, parametri copiandoli da altri siti, se non capite cosa state facendo, in quanto potreste creare seri problemi di connessione, quindi vi prego leggete la relativa manualistica (come ad esempio: https://unbound.docs.nlnetlabs.nl/en/latest/ ).

Ora è indispensabile modificare il file presente nel percorso /etc/dnsmasq.d/99-edns.conf , quindi effettueremo il comando:

sudo nano /etc/dnsmasq.d/99-edns.conf

e copiare al suo interno il seguente testo:

edns-packet-max=1232

Salvare e uscire (premere i tasti Ctrl X e poi S per confermare).

Questa modifica eviterà un errore sul pihole con la seguente dicitura d’esempio: Warning in dnsmasq core: reducing DNS packet.

Se possedete come sistema operativo raspbian Os (su raspberry pi) oppure Debian e suoi derivati (con la versione Bullseye+ o superiore) è obbligatorio disattivare il servizio resolvconf (esso risulta integrato nel pacchetto d’installazione e/o aggiornamento), il quale può causare dei problemi, per farlo eseguire i seguenti comandi:

systemctl is-active unbound-resolvconf.service
sudo systemctl disable --now unbound-resolvconf.service
sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf
sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Effettuiamo un restart del servizio unbound, questo farà in modo che vengano implementate tutte le modifiche che abbiamo effettuato:

sudo service unbound restart

Ora è tempo di verificare che il servizio sia effettivamente attivo e funzionante con il seguente comando:

sudo service unbound status

L’output deve indicarci che lo stato è active (running) ed è di colore verde, in pratica come questo:

Screenshot comando: sudo service unbound status

Se non è in stato active è necessario effettuare delle verifiche sul sistema, inserite tranquillamente il vostro commento su questa guida, cercherò di aiutarvi come posso, inoltre è importante segnalare che non si stà effettuando nessun disservizio, il vostro pihole non è stato ancora configurato completamente per usare unbound (sta ancora funzionando alla vecchia maniera).

Effettuiamo quindi un primo test di funzionamento (si segnala che la configurazione non è ancora terminata).

dig pi-hole.net @127.0.0.1 -p 5335

La prima query impiegherà un po di tempo, ma non allarmatevi è del tutto normale.

Nell’output del comando dovete verificare che sulla voce “status:” ci sia il valore: NOERROR. Qui potete anche verificare il tempo in ms, nel campo “Query time”:

Screenshot comando: dig pi-hole.net @127.0.0.1 -p 533

Solo se riscontrare l’errore SERVFAIL, provate ad effettuate anche un altro comando dig edicolac64.com @127.0.0.1 -p 5335 se continuate a ricevere lo stesso messaggio, è necessario effettuare delle verifiche sul sistema, inserite tranquillamente il vostro commento su questa guida, cercherò di aiutarvi come posso.

E’ tutto ok? Allora ri-effettuare lo stesso comamndo, fino a che il campo Query Time non sia a 0, questo ci serve per capire che anche la cache di unbound (impostata di default dal software) sia correttamente funzionante.

Configurare Pihole per Unbound

Rechiamoci sulla pagina amministrativa del nostro pihole, dal menu scegliere la voce Setting e quindi poi nella finestra la voce DNS, qui sarà necessario eliminare qualsiasi tipo di visto sulla parte Upstream DNS server e in Custom (IPv4) inserire il seguente testo:

127.0.0.1#5335

In pratica dovete avere una situazione identica allo screenshot seguente:

Pi-hole: configurazione unbound

Clicchiamo sul tasto Save, in basso a destra, abbiamo terminato.


Nota finale: Ci sono molte discussioni in giro sul fatto che sia necessario disabilitare il DNSSEC sul pihole (se abilitato nella schermata precedente), visto che si sta usando unbound, la verità è che in passato esisteva un bug che poteva creare problemi ma è stato risolto; io ho effettuato dei test senza riscontrare effettivamente dei rallentamenti sui tempi di risposta in ms quindi ho lascio attiva tale opzione, fate anche voi dei test e lascio quindi a voi la scelta di tenerlo abilitato o meno.

Informazioni su Giovanni De Simone 35 articoli
Sono nato negli anni 80 e da sempre, ho coltivato la passione per informatica e per i videogiochi. Il mio lavoro mi ha spinto a inoltrarmi nell'argomento della sicurezza informatica e in modo "semplice", senza entrare troppo nei dettagli, ho costruito questo sito web per difendere la privacy di chi naviga sul web, quindi per evitare la profilazione. Sono pronto ad accettare critiche costruttive per accrescere la conoscenza e consigli su plug-in, programmi e software (da testare) per rendere questo sito web migliore.

13 commenti

  1. Ciao Giovanni,interessante questa guida,io se ricordi grazie alla tua disponibilità ho installato Dnscrypt sul raspberry os posso lasciare l’attuale configurazione o mi consigli di usare unbound? Buona Domenica.

  2. Ciao io arrivo ad un certo punto dell’installazione e ricevo l’errore:
    pi@Pi-Hole:~ $ sudo systemctl disable –now unbound-resolvconf.service
    Invalid unit name “–now” escaped as “\xe2\x80\x93now” (maybe you should use systemd-escape?).
    Failed to disable unit: Unit file \xe2\x80\x93now.service does not exist.
    pi@Pi-Hole:~ $ sudo sed -Ei ‘s/^unbound_conf=/#unbound_conf=/’ /etc/resolvconf.conf
    sed: espressione -e #1, carattere 1: comando sconosciuto: `?’
    pi@Pi-Hole:~ $

    • ciao, ho effettuato una correzione alla guida, il testo non era caratterizzato come codice di programmazione, i comandi da eseguire sono questi:
      sudo systemctl disable --now unbound-resolvconf.service
      sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf
      Fammi sapere se riscontri ancora anomalie.

  3. ora si presenta questa situazione
    sudo service unbound restart
    Job for unbound.service failed because the control process exited with error code.
    See “systemctl status unbound.service” and “journalctl -xe” for details.

    • Fai questi comandi
      sudo nano /etc/apparmor.d/local/usr.sbin.unbound
      e copiare il seguente testo
      /var/log/unbound/unbound.log rw,
      Salva e esci (tasti ctrl+x e poi S)
      Rifai il comando
      sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf
      cancella tutto il testo all’interno e copia il testo corretto (server: …) che è stato fixato e trovi nella guida sopra (ho notato che prima non prendeva gli spazi, ora con una modifica al codice della pagina ho risolto) e rifai il comando
      sudo service unbound restart
      ora non dovresti avere errori e puoi continuare da dove eri rimasto.

  4. Ciao, nel mio caso Pihole è su docker, mi consigli d’installare Unbound in un altro contenitore, o nello stesso di Pihole?

Lascia un commento

L'indirizzo email non sarà pubblicato.


*