Come Risolvere Conflitti Socket Unbound e Pi-hole-FTL

Configurare un’infrastruttura di risoluzione dei nomi di dominio locale e privata è uno dei passi più efficaci per proteggere la propria navigazione, ma è fondamentale saper risolvere conflitti socket unbound che possono emergere durante l’integrazione con Pi-hole-FTL. Quando si decide di affiancare alla nota interfaccia di filtraggio il demone ricorsivo Unbound sulla medesima macchina, capita frequentemente che i due servizi entrino in collisione per il controllo delle interfacce di rete e delle porte di ascolto standard.

L’origine del problema: la contesa della porta 53

Il protocollo DNS opera storicamente sulla porta 53, sia su trasporto UDP sia su TCP. In un’architettura integrata, Pi-hole (tramite il suo motore ottimizzato pihole-FTL) e il demone unbound hanno ruoli complementari ma distinti. Il primo deve fungere da punto di ingresso per tutti i dispositivi della LAN, applicando le liste di blocco e le metriche di telemetria, mentre il secondo deve agire come resolver a monte, dialogando direttamente con i root server e i server autoritativi della gerarchia Internet senza intermediari terzi.

Se entrambi i software vengono installati con le configurazioni di default fornite dai repository Linux (come Debian, Ubuntu o Raspberry Pi OS), entrambi cercheranno di legarsi all’indirizzo jolly 0.0.0.0:53. Il risultato immediato è un crash all’avvio di uno dei due demoni con il tipico errore di sistema EADDRINUSE (Address already in use). Durante l’analisi dei log di sistema, la necessità di risolvere conflitti socket unbound emerge quando entrambi i servizi tentano di ascoltare sull’indirizzo standard, impedendo al sistema operativo di instradare i pacchetti in ingresso.

Se riscontri blocchi anomali durante la risoluzione dei nomi, consulta anche la nostra guida dedicata a errori di connessione unbound per verificare preventivamente l’integrità del demone e delle chiavi DNSSEC.

Individuazione e diagnosi dei processi in ascolto

Prima di modificare qualsiasi parametro, è essenziale verificare lo stato corrente delle connessioni e dei socket aperti sul server. Attraverso la shell Linux, possiamo interrogare il kernel per capire quale demone si sia appropriato della porta contesa.

Il comando primario per questa verifica è ss, che ha sostituito il vecchio netstat nella maggior parte delle distribuzioni moderne:

sudo ss -tulpn | grep :53

Questo comando restituirà l’elenco dei processi che stanno impegnando la porta 53 sia in UDP (-u) che in TCP (-t). Tra i colpevoli più frequenti possiamo riscontrare:

  • systemd-resolved: il resolver locale integrato in systemd, spesso attivo per impostazione predefinita su Ubuntu, che riserva l’indirizzo 127.0.0.53:53.
  • pihole-FTL: il binario di Pi-hole che tenta di rispondere a tutte le query dei client di rete locale.
  • unbound: il demone ricorsivo che cerca di inizializzare la propria interfaccia di ascolto globale.
  • dnsmasq: presente talvolta come servizio autonomo legacy dimenticato attivo.

Una volta individuato quale processo ha occupato la risorsa, l’obiettivo per risolvere conflitti socket unbound consiste nel modificare la porta di ascolto predefinita di Unbound e confinarlo sull’indirizzo di loopback locale.

Disattivazione di systemd-resolved (se presente)

Nelle distribuzioni Linux moderne basate su Ubuntu o Debian recente, il gestore di sistema esegue uno stub resolver chiamato systemd-resolved. Questo componente occupa la porta 53 sul loopback, creando interferenze sia con FTL sia con Unbound.

Per neutralizzare questa interferenza senza rompere la risoluzione interna dell’host, è necessario modificare il file di configurazione di sistema:

sudo nano /etc/systemd/resolved.conf

Imposta le seguenti direttive all’interno della sezione [Resolve]:

[Resolve]
DNS=127.0.0.1
DNSStubListener=no

Successivamente, aggiorna il link simbolico del file resolv.conf ed esegui il riavvio del demone di sistema con i seguenti comandi:

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

Configurazione corretta del binding socket per Unbound

La soluzione architetturale corretta prevede che Unbound non ascolti mai sulla porta 53 pubblica della scheda di rete (es. eth0 o wlan0), ma esclusivamente sull’interfaccia interna di loopback (127.0.0.1 e ::1) e su una porta alternativa ad alto valore numerico non riservata dai servizi standard, tipicamente la porta 5335.

Crea o modifica il file di configurazione dedicato a Pi-hole per Unbound:

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

Inserisci un blocco di configurazione server ottimizzato come segue:

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

La direttiva port: 5335 insieme a interface: 127.0.0.1 garantisce che il demone non provi in alcun modo a registrare socket aperti su 0.0.0.0:53. Inoltre, l’abilitazione di so-reuseport: yes permette al kernel di bilanciare le richieste tra thread multipli riducendo il tempo di blocco dei socket sotto carico intenso.

Configurazione di Pi-hole-FTL verso il resolver locale

Dopo aver riconfigurato il backend ricorsivo, è fondamentale allineare Pi-hole-FTL affinché interroghi esclusivamente Unbound sulla porta non standard appena definita.

Apri l’interfaccia web di Pi-hole o il relativo file di configurazione testuale:

  1. Accedi alla dashboard e naviga su Settings > DNS.
  2. Deseleziona tutti i server DNS pubblici preimpostati (Google, Cloudflare, OpenDNS).
  3. Nella sezione Custom Upstream DNS Servers, inserisci: 127.0.0.1#5335.
  4. Se supporti IPv6, puoi aggiungere: ::1#5335.
  5. Salva le impostazioni facendo clic su Save in fondo alla schermata.

Applicando questa direttiva di reindirizzamento locale possiamo risolvere conflitti socket unbound senza compromettere la validazione DNSSEC, lasciando a Pi-hole il compito di bloccare i domini pubblicitari e a Unbound la validazione autoritativa delle risposte.

Verifica finale del flusso DNS e test funzionali

Completate le modifiche, riavvia entrambi i servizi in ordine sequenziale per consentire al sistema operativo di registrare le nuove tabelle di socket:

sudo systemctl restart unbound
sudo systemctl restart pihole-FTL

Per testare se Unbound sta rispondendo correttamente in autonomia sulla porta 5335 senza passare per Pi-hole, lancia il comando di test DNS con dig:

dig pi-hole.net @127.0.0.1 -p 5335

La risposta deve mostrare lo stato status: NOERROR e la presenza del flag ad (Authenticated Data) qualora la zona sia firmata con DNSSEC. Successivamente, esegui lo stesso comando puntando alla porta standard 53 servita da Pi-hole-FTL:

dig pi-hole.net @127.0.0.1 -p 53

Se entrambi i comandi restituiscono l’indirizzo IP corretto in pochi millisecondi, l’infrastruttura di rete è perfettamente allineata e priva di collisioni sui socket di sistema.

Considerazioni avanzate su buffer e permessi di sistema

In scenari ad alto traffico o in presenza di molti client IoT, il kernel Linux potrebbe scartare pacchetti UDP se i buffer di ricezione sono saturi. L’opzione so-rcvbuf: 4m inserita nella configurazione di Unbound previene l’overflow delle code di socket, ma richiede che il sistema operativo consenta l’allocazione di tale memoria.

Puoi verificare e regolare la dimensione massima del buffer del socket UDP nel file /etc/sysctl.conf aggiungendo:

net.core.rmem_max = 4194304
net.core.wmem_max = 4194304

In conclusione, seguire metodicamente queste verifiche è il modo migliore per risolvere conflitti socket unbound e ottenere una rete domestica veloce, privata e priva di disservizi.

Articoli simili