Blocchi di Rete FTL: Diagnostica e Risoluzione

Quando l’infrastruttura DNS domestica o aziendale smette improvvisamente di rispondere alle richieste dei client, individuare la causa primaria richiede un approccio metodico e rigoroso. In molti scenari operativi basati su Pi-hole, i disservizi non derivano da guasti hardware ma da parametri di sicurezza troppo stringenti o dall’esaurimento delle risorse di sistema, situazioni che sfociano in veri e propri blocchi di rete FTL capaci di paralizzare l’intera connettività locale.

Nel nostro precedente articolo dedicato al crash di Pi-hole FTL abbiamo analizzato i fattori sistemici che provocano l’arresto improvviso del demone di risoluzione. In questo approfondimento tecnico facciamo un passo ulteriore: esaminiamo il comportamento del motore Faster Than Light quando rimane in esecuzione ma cessa di erogare risposte a causa del rate-limiting aggressivo o della saturazione della memoria condivisa (SHM). Questa condizione ibrida è spesso più insidiosa di un semplice crash, poiché i test di connettività di base possono indicare che il server è attivo, mentre i client rimangono completamente isolati dal web.

Anatomia del Rate-Limiting in pihole-FTL

Il motore FTL integra fin dalle versioni moderne un meccanismo automatico di protezione contro i loop DNS e gli attacchi di tipo Denial of Service interni. Tale sistema monitora costantemente il volume di query generate da ciascun indirizzo IP client all’interno di una finestra temporale definita. Per impostazione predefinita, la soglia è fissata a 1000 richieste nell’arco di 60 secondi per singolo client. Superato questo valore, il demone smette temporaneamente di elaborare le richieste provenienti da quell’indirizzo IP, scartandole silenziosamente o restituendo risposte di rifiuto.

Sebbene questa misura sia pensata per salvaguardare la stabilità del servizio, nelle reti contemporanee si verificano frequentemente falsi positivi che vengono percepiti come blocchi di rete FTL dagli utenti finali. Dispositivi IoT mal programmati, client con telemetria aggressiva, sincronizzazioni massive di file in cloud, browser moderni con prefetching DNS aggressivo o l’abilitazione di funzionalità come Apple Private Relay possono generare raffiche transitorie di centinaia di query in pochi secondi. Se il router inoltra tutte le richieste dei client usando il proprio indirizzo IP come sorgente (ad esempio quando il DNS di Pi-hole è impostato solo sulla WAN del router invece che distribuito via DHCP), l’intera rete domestica viene vista come un unico client: in questo scenario catastrofico, basta che un solo dispositivo superi la soglia per bloccare la navigazione di tutti gli altri nodi.

Un’errata configurazione del forwarding condizionale (Conditional Forwarding) unita all’inoltro WAN del router è la prima causa di tempeste DNS che attivano istantaneamente il blocco dell’intero segmento di rete.

Saturazione della Memoria Condivisa e Architettura IPC

A differenza dei tradizionali resolver DNS basati esclusivamente su disco o su allocazione dinamica heap convenzionale, l’architettura di FTL sfrutta massicciamente segmenti di memoria condivisa POSIX (allocati nel filesystem virtuale /dev/shm). Questa scelta garantisce prestazioni straordinarie con tempi di risposta inferiori al millisecondo, consentendo una comunicazione interprocesso (IPC) estremamente efficiente tra il motore DNS e l’interfaccia web o le API di monitoraggio.

Tuttavia, questa architettura introduce un punto di vulnerabilità se il volume dei dati storici o transitori supera lo spazio disponibile in RAM. Su dispositivi a risorse limitate, come ad esempio un Raspberry Pi Zero o schede con 512 MB di memoria, la cartella /dev/shm può esaurire rapidamente i byte allocabili. Quando le tabelle delle query in memoria non possono più espandersi, FTL entra in uno stato di stallo operativo. Il demone tenta ripetutamente di riallocare i puntatori di memoria condivisa senza successo, determinando deadlock nei thread di ricezione dei pacchetti UDP e provocando improvvisi blocchi di rete FTL che non rilasciano log di errore standard ma si manifestano con il congelamento del socket DNS sulla porta 53.

Diagnostica da Riga di Comando: Individuare l’Origine del Blocco

Per diagnosticare la causa del malfunzionamento, è necessario accedere alla shell SSH dell’host Pi-hole e interrogare direttamente i log e lo stato delle risorse. Non affidarti esclusivamente alla dashboard web, poiché durante una crisi di memoria essa potrebbe non aggiornarsi o restituire errori di timeout HTTP.

1. Ispezione dei Log del Demone FTL

Il file principale da analizzare è /var/log/pihole/FTL.log. Utilizza il comando seguente per filtrare i messaggi di rate-limiting:

grep -E "Rate-limiting|rate limit" /var/log/pihole/FTL.log

Se il meccanismo è intervenuto, troverai righe simili a: “Rate-limiting 192.168.1.50 is active for 60 seconds (already processed 1000 queries)”. Se l’IP indicato corrisponde al gateway predefinito della rete, significa che il router agisce da collo di bottiglia e maschera i singoli client, amplificando il problema all’intero ambiente domestico.

2. Analisi dello Spazio in Memoria Condivisa

Verifica immediatamente l’utilizzo del filesystem /dev/shm eseguendo:

df -h /dev/shm
ls -lh /dev/shm

I file denominati FTL-strings, FTL-queries, FTL-clients e FTL-domains non dovrebbero mai occupare la quasi totalità dello spazio assegnato alla partizione virtuale. Se l’output evidenzia un utilizzo del 100%, FTL non sarà in grado di processare nuovi flussi socket, generando i sintomi descritti.

3. Verifica dei Thread e delle Connessioni Socket

Per confermare che il resolver stia effettivamente ascoltando sulle interfacce di rete e non sia rimasto bloccato in una syscall di memoria, digita:

sudo ss -tulpn | grep pihole-FTL
sudo journalctl -u pihole-FTL -e --no-pager

Questo comando permette di verificare se la porta 53 è aperta sia per UDP che per TCP e consente di escludere crash dovuti a SIGSEGV o Out-Of-Memory (OOM Killer) del kernel Linux.

Tuning della Configurazione e Strategie Risolutive

Una volta identificata la natura del collo di bottiglia, è possibile agire sui file di configurazione per mitigare o eliminare definitivamente il disservizio.

Ottimizzare i Limiti di Rate-Limiting

La configurazione avanzata di FTL viene gestita all’interno del file /etc/pihole/pihole-FTL.conf. Per modificare o disattivare temporaneamente la protezione, modifica il file con i privilegi di root:

sudo nano /etc/pihole/pihole-FTL.conf

Aggiungi o modifica la direttiva RATE_LIMIT. I valori indicano rispettivamente il numero massimo di query e l’intervallo in secondi. Per una rete densa di dispositivi IoT, una configurazione equilibrata è:

RATE_LIMIT=3000/60

Se invece la rete presenta un router configurato come unico client verso Pi-hole e non puoi modificare la distribuzione DHCP, puoi disattivare il controllo impostando:

RATE_LIMIT=0/0

Nota tecnica: Disattivare completamente il controllo espone la rete a rischi di loop infiniti nel caso in cui una macchina locale entri in errore di risoluzione ciclica.

Gestione della Memoria e Retention del Database

Se il problema principale risiede nella memoria SHM, puoi ridurre la quantità di dati storici conservati in memoria limitando l’intervallo temporale caricato al riavvio del servizio:

MAXDBDAYS=7
DBINTERVAL=60.0

Impostando MAXDBDAYS=7, FTL caricherà in memoria solo l’ultima settimana di log anziché i consueti 365 giorni, riducendo drasticamente l’impronta sui segmenti di /dev/shm ed evitando il degrado delle prestazioni su macchine con poca RAM.

Risolvere i Loop di Rete (Conditional Forwarding)

Se nei log noti query ricorsive verso il router per domini locali come .local o .lan, verifica le impostazioni in Settings > DNS > Conditional Forwarding. Assicurati che l’indirizzo IP del router e il dominio locale siano corretti e che il router non utilizzi a sua volta Pi-hole come DNS a monte (upstream DNS), altrimenti si creerà un anello chiuso in cui una sola query genera migliaia di pacchetti al secondo.

Manutenzione Preventiva per Prevenire Nuovi Blocchi

Per garantire stabilità continuativa nel lungo termine, adotta queste buone pratiche operative:

• Distribuisci il DNS via DHCP: Configura il server DHCP del router affinché fornisca direttamente ai client l’IP di Pi-hole, permettendo al demone di tracciare ciascun dispositivo individualmente.
• Monitora la dimensione del database: Esegui periodicamente una compattazione del database SQLite situato in /etc/pihole/pihole-FTL.db con il comando sudo pihole -f o via script SQLite VACUUM.
• Crea alert di monitoraggio: Configura un piccolo script cron che verifichi periodicamente la risposta di FTL su porta 53 mediante dig @127.0.0.1 healthcheck.test, riavviando il servizio solo in caso di stallo prolungato.

Adottando queste misure e calibrando attentamente i parametri di sistema, potrai eliminare in radice i blocchi di rete FTL, garantendo una risoluzione dei nomi veloce, protetta e costantemente affidabile su tutta l’infrastruttura locale.

💡 Approfondimento consigliato: https://nicolacasalini.it/debug-pi-hole-e-unbound/