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

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):

e poi:

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:

come nello screenshot seguente:

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:

come nello screenshot seguente:

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:

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

e copiare il seguente testo

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:

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:

e copiare al suo interno il seguente testo:

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:

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

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

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

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).

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”:

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:

In pratica dovete avere una situazione identica allo screenshot seguente:

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

Se il lavoro effettuato su questo sito web, ti piace e sono riuscito ad aiutarti, effettua una donazione, basta il costo di un caffe'. Grazie. (Non e' necessario avere un account paypal per effettuare la donazione).

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.