In molte reti basate su pfSense, è comune utilizzare:
- pfSense come router/firewall e server DHCP
- Unbound come DNS Resolver con registrazione dinamica
- Pi‑hole come DNS primario per filtraggio e caching
Questa combinazione è potente, ma può generare problemi difficili da diagnosticare quando entrano in gioco:
- hostname duplicati
- lease DHCP scaduti ma non rimossi
- record DNS dinamici generati da lease “abandoned”
- cache DNS persistente di Pi‑hole
In questo articolo analizziamo un caso reale in cui un dispositivo IoT ha causato un conflitto DNS che ha portato a risoluzioni errate e incoerenti tra DHCP, DNS Resolver e Pi‑hole.
—
Sintomo del problema
Il comportamento osservato era il seguente:
- DHCP mostrava Mini4 → 192.168.8.101
- DNS Lookup mostrava Mini4 → 192.168.8.100
- Pi‑hole rispondeva sempre con 100
- pfSense rispondeva con 100 anche dopo reboot
Una situazione apparentemente impossibile: il lease attivo era corretto, ma il DNS continuava a servire un IP vecchio.
—
La causa reale: un lease DHCP “abbandonato” con hostname duplicato
Nel file reale dei lease di pfSense:
/var/dhcpd/var/db/dhcpd.leases
era presente questo blocco:
lease 192.168.8.100 {
binding state abandoned;
client-hostname “Mini4”;
}
Questo lease:
- era scaduto
- era “abandoned”
- non compariva nella GUI
- ma era ancora presente nel file
- e conteneva l’hostname “Mini4”
Perché è un problema?
Perché Unbound genera i record DNS dinamici leggendo tutti i lease, anche quelli:
- expired
- abandoned
- free
- rewind
Di conseguenza, Unbound continuava a generare:
A record: mini4.local.lan → 192.168.8.100
PTR record: 100 → mini4.local.lan
anche se il lease attivo era 101.
—
La causa originale: un dispositivo IoT che si è spacciato per “Mini4”
Il dispositivo incriminato era un Aubess (wlan0), che:
- non rispetta DHCP Option 12
- non invia un hostname coerente
- si presenta con nomi casuali
- in questo caso si è presentato come “Mini4”
pfSense ha quindi creato un lease per:
192.168.8.100 → Mini4
Quando il Mac mini ha richiesto un IP, ha ottenuto:
192.168.8.101 → Mini4
Risultato: hostname duplicato.
—
Il secondo problema: la cache DNS di Pi‑hole
Pi‑hole aveva memorizzato:
mini4.local.lan → 192.168.8.100
Quindi:
- anche dopo aver corretto pfSense
- anche dopo aver cancellato il lease fantasma
- anche dopo il reboot di pfSense
Pi‑hole continuava a rispondere con l’IP sbagliato.
Solo dopo:
pihole restartdns
la cache è stata svuotata e il DNS si è riallineato.
—
Perché il reboot di pfSense non ha risolto?
Perché pfSense non elimina i lease scaduti dal file.
Il file rimane identico.
E Unbound, al boot, ricostruisce i record DNS dinamici anche dai lease “abandoned”.
Quindi il record sbagliato veniva ricreato ogni volta.
—
Soluzione definitiva
1. Identificare il lease fantasma
cat /var/dhcpd/var/db/dhcpd.leases | grep -i mini4 -A5 -B5
2. Eliminare il blocco incriminato
vi /var/dhcpd/var/db/dhcpd.leases
Cancellare:
lease 192.168.8.100 { … }
3. Rigenerare i lease DHCP
GUI → DHCP Server → Save
4. Reload DNS Resolver
GUI → DNS Resolver → Save
5. Svuotare la cache di Pi‑hole
pihole restartdns
—
Risultato finale
- Il dispositivo IoT ha preso un nuovo IP (es. 187)
- Mini4 è rimasto correttamente su 101
- Nessun hostname duplicato
- Nessun record DNS sbagliato
- pfSense e Pi‑hole perfettamente allineati
—
Conclusioni
Questo caso dimostra come un semplice dispositivo IoT con hostname errato possa:
- generare un lease DHCP “abandoned”
- sporcare il DNS dinamico di pfSense
- creare record A/PTR sbagliati
- essere ulteriormente amplificato dalla cache di Pi‑hole
La diagnosi richiede:
- analisi del file reale dei lease
- comprensione del comportamento di Unbound
- gestione della cache DNS di Pi‑hole
È un problema raro, ma estremamente insidioso.