Per Pi-hole su Ubuntu Server 24.04, instrada le sue richieste upstream attraverso dnscrypt-proxye configura Pi-hole in modo che punti al listener locale all'indirizzo 127.0.0.1#5053. In questo modo, il traffico DNS tra il tuo server e il resolver upstream selezionato viene crittografato con DNS-over-HTTPS (DoH), mentre Pi-hole continua a rispondere ai client della tua LAN e ad applicare le sue blacklist. Pi-hole di per sé non fornisce il trasporto DoH verso il suo upstream per impostazione predefinita; il proxy locale si occupa di questa connessione crittografata.
Prima di tutto, è importante sapere che Cloudflare ha rimosso il cloudflared proxy-dnscomando dalle nuove versioni a partire dal 2 febbraio 2026. I tutorial più vecchi che installano quel comando potrebbero non funzionare con la cloudflaredversione corrente. I passaggi seguenti utilizzano dnscrypt-proxy, seguendo la guida DoH corrente di Pi-hole. Questa configurazione è adatta quando Pi-hole e il proxy vengono eseguiti sullo stesso host Ubuntu. Una configurazione Docker o multi-host richiede un diverso indirizzamento del listener e regole del firewall.
Cosa fa e cosa non fa questa configurazione
Il DNS standard invia solitamente le query dal resolver a un provider DNS a monte senza crittografia del trasporto. DoH (Domain of Header) veicola le richieste DNS all'interno di HTTPS, rendendo più difficile per un osservatore di rete tra il server Pi-hole e il resolver leggere o modificare tali richieste. Pi-hole rimane il server DNS pubblicizzato ai dispositivi sulla rete locale; cambia solo il percorso a monte.
DoH non rende invisibile l'attività DNS al resolver scelto. Il provider upstream continua a ricevere le query dal server e Pi-hole potrebbe conservare la cronologia delle query del client in base alle proprie impostazioni di privacy e registrazione. Inoltre, HTTPS non crittografa il traffico web non correlato. Se l'obiettivo è utilizzare un resolver specifico, è necessario consultare la relativa informativa sulla privacy e selezionare la voce DoH corrispondente dall'elenco dei resolver supportati.
Prima di iniziare
- Verifica che Pi-hole sia già installato e funzionante su Ubuntu Server 24.04. Questa procedura illustra come configurare un'installazione di Pi-hole già esistente, anziché installarne una nuova.
- Assicurati che il server abbia un indirizzo LAN stabile. Se l'indirizzo cambia, i client DHCP del router potrebbero perdere la connessione al server DNS.
- Assicurati di avere accesso amministrativo e un modo per raggiungere l'host Pi-hole nel caso in cui il DNS smetta temporaneamente di funzionare. Evita di apportare questa modifica da remoto tramite una connessione che dipende dallo stesso Pi-hole per la risoluzione dei nomi.
- Annota le impostazioni correnti di Pi-hole in modo da poterle ripristinare in caso di rollback.
Il proxy si collegherà solo all'interfaccia di loopback sulla porta 5053, lasciando la porta 53 libera per Pi-hole. Questo evita conflitti con il servizio DNS di Pi-hole e con il resolver locale di Ubuntu. Non disabilitare questa opzione systemd-resolvedsolo per far funzionare questa configurazione; la porta di loopback separata del proxy evita proprio questo conflitto.
1. Installa dnscrypt-proxy dai repository di pacchetti di Ubuntu
Il progetto dnscrypt-proxy documenta un percorso di installazione del pacchetto Ubuntu. Prima di procedere con l'installazione, verifica che i repository Ubuntu configurati offrano un percorso alternativo:
sudo apt update
apt-cache policy dnscrypt-proxy
Se l'output mostra una versione candidata, installala:
sudo apt install dnscrypt-proxy
Se non viene visualizzato alcun candidato, non aggiungere un repository di terze parti non correlato solo per procedere. Utilizza il metodo di installazione indicato nella guida ufficiale per Linux del progetto dnscrypt-proxy, verifica la versione e l'architettura e adatta la configurazione del servizio a tale installazione. L'unità socket systemd e i percorsi di configurazione riportati di seguito si applicano alla configurazione del pacchetto Ubuntu documentata da Pi-hole.
2. Spostare il listener proxy sulla porta 5053 di localhost.
Pi-hole utilizza già la porta DNS standard 53. Configura il socket del proxy in modo che sia in ascolto sia su TCP che su UDP all'indirizzo 127.0.0.1:5053, raggiungibile solo dallo stesso host. Crea un drop-in di systemd:
sudo systemctl edit dnscrypt-proxy.socket
Inserisci queste righe nell'editor e salva:
[Socket]
ListenStream=
ListenDatagram=
ListenStream=127.0.0.1:5053
ListenDatagram=127.0.0.1:5053
Le righe vuote ListenStream=cancellano ListenDatagram=le impostazioni predefinite del pacchetto prima di impostare gli indirizzi di sostituzione. Non ometterle: altrimenti systemd può mantenere la porta predefinita oltre al listener personalizzato.
3. Selezionare un risolutore DoH
Aprire il file di configurazione del pacchetto:
sudoedit /etc/dnscrypt-proxy/dnscrypt-proxy.toml
Per attivare il socket systemd, utilizzare un elenco di listener vuoto nella configurazione del proxy. Scegliere un nome di resolver dall'elenco corrente di resolver pubblici firmati. Ad esempio, il seguente comando seleziona il resolver standard di Cloudflare; la guida di Pi-hole mostra anche cloudflare-securityun esempio di quando si desidera filtrare il malware a livello del resolver upstream:
listen_addresses = []
server_names = ['cloudflare']
Mantieni intatta la restante configurazione del pacchetto. I nomi server_namessono identificatori di registro, non nomi host o percorsi URL arbitrari. Se preferisci un altro provider, verifica che la sua voce di risoluzione corrente supporti DoH e copiane il nome esatto. Un resolver che filtra malware o altre categorie potrebbe produrre risultati diversi rispetto a un resolver non filtrato.
4. Configurare Pi-hole in modo che punti al proxy locale.
Imposta l'indirizzo DNS upstream di Pi-hole sul listener locale:
sudo pihole-FTL --config dns.upstreams '["127.0.0.1#5053"]'
Il #5053suffisso è la notazione di Pi-hole per la porta DNS non standard. Puoi anche controllare l'interfaccia di amministrazione di Pi-hole in Impostazioni > DNS . Cancella le selezioni predefinite per i server upstream pubblici e lascia il server personalizzato 127.0.0.1#5053come upstream. Mantenere un resolver pubblico selezionato come upstream aggiuntivo può consentire alle query di bypassare il proxy crittografato, quindi rimuovi tali voci se hai bisogno che tutte le query upstream di Pi-hole utilizzino DoH.
5. Riavvia i servizi e verifica la risoluzione del problema.
Riavvia il socket, il servizio proxy e il demone Pi-hole FTL in modo che carichino la nuova configurazione:
sudo systemctl restart dnscrypt-proxy.socket
sudo systemctl restart dnscrypt-proxy.service
sudo systemctl restart pihole-FTL.service
Verifica lo stato del servizio:
sudo systemctl status dnscrypt-proxy.socket
sudo systemctl status dnscrypt-proxy.service
sudo systemctl status pihole-FTL.service
Ciascuno dovrebbe essere attivo senza errori di binding o di avvio del resolver. Testa il proxy direttamente sul suo listener DNS locale:
dig @127.0.0.1 -p 5053 example.com
Una risposta DNS indica che il proxy locale sta rispondendo. Quindi, testa Pi-hole sulla porta 53:
dig @127.0.0.1 example.com
Controlla il registro delle query o la dashboard di Pi-hole per confermare che la richiesta abbia raggiunto Pi-hole e, se il test fallisce, esamina il registro del proxy:
sudo journalctl -u dnscrypt-proxy.service -b --no-pager
Per un controllo aggiuntivo, controlla l'output di avvio del proxy o del journal per il resolver selezionato e lo stato del protocollo DoH. Un risultato positivo digda solo dimostra che la risoluzione DNS funziona; non dimostra, di per sé, che la richiesta abbia utilizzato HTTPS.
Problemi comuni e recupero sicuro
- "Indirizzo già in uso": un altro processo potrebbe già occupare la porta 5053 oppure l'override del socket non è stato caricato. Controlla i listener con
sudo ss -lntup, rivedi il drop-in con systemctl cat dnscrypt-proxy.socket, e conferma che le righe di reset vuote precedano le voci 5053.
- Il proxy è attivo ma le ricerche vanno in timeout: verificare l'accesso HTTPS in uscita, il nome del resolver e i log del proxy. Alcune reti bloccano le connessioni DNS-over-HTTPS o limitano la porta TCP 443.
- Il test del proxy funziona ma Pi-hole non ha risposta upstream: verificare che Pi-hole sia impostato esattamente su
127.0.0.1#5053, quindi riavviare pihole-FTL. Assicurarsi che le caselle di controllo upstream standard non forniscano silenziosamente un percorso alternativo.
- Ubuntu stesso non è in grado di risolvere i nomi dopo la modifica: questa configurazione modifica il file upstream di Pi-hole, non quello dell'host
/etc/resolv.conf. Evita di sostituire quel file o di disabilitarlo systemd-resolvedcome scorciatoia per la risoluzione dei problemi.
Per ripristinare le impostazioni precedenti, ripristina l'impostazione DNS upstream che hai registrato in Pi-hole e riavvia il servizio pihole-FTL. Una volta che Pi-hole non punta più al proxy, puoi disabilitarlo o rimuoverlo dnscrypt-proxytramite il gestore pacchetti. Se questo server risolve anche il proprio DNS tramite Pi-hole, assicurati di avere un percorso di ripristino locale disponibile prima di modificare i servizi.
Quale opzione è più adatta alla tua rete?
Utilizzate questa configurazione proxy a host singolo quando desiderate un filtro DNS centralizzato in Pi-hole e traffico crittografato da Pi-hole a un resolver selezionato. È relativamente facile da ispezionare perché il proxy ha un solo indirizzo e porta locali. Se eseguite Pi-hole in Docker, su un altro server o su più reti, potrebbe essere necessario un indirizzo di rete container anziché un indirizzo di loopback e dovrete limitare l'ascolto del proxy in modo che non sia esposto come resolver aperto. Se avete bisogno di un filtro basato su policy, di un'identità per dispositivo o di DNS crittografato per i dispositivi in roaming al di fuori della rete domestica, configurate questi client o un gateway gestito separatamente; la connessione DoH upstream di Pi-hole non crittografa automaticamente il percorso di ciascun client verso Pi-hole.
Infine, ricordate che un router o un client può aggirare Pi-hole se pubblicizza un secondo server DNS. Per un filtraggio a livello di rete, assegnate ai client solo l'indirizzo di Pi-hole tramite DHCP e tenete conto degli annunci DNS IPv6 oltre a quelli IPv4. Verificate con più dispositivi dopo aver modificato le impostazioni del router, poiché una corretta configurazione del proxy sul server non può impedire a un client di utilizzare direttamente un altro resolver.
Riferimenti ufficiali