Il tuo filtro DNS non basta: come i dispositivi bypassano AdGuard, Pi-hole e resolver locali

Configurare un filtro DNS locale, basato su soluzioni come AdGuard Home o Pi-hole, è una pratica diffusa tra gli utenti avanzati che vogliono limitare tracciamento, pubblicità e domini malevoli. L’idea di avere il pieno controllo della risoluzione dei nomi di dominio all’interno della rete domestica è però spesso solo apparente. L’architettura moderna del Domain Name System (DNS), evoluta con protocolli cifrati e client sempre più autonomi, consente ai dispositivi di aggirare facilmente i resolver locali. Il risultato è che una quota significativa delle richieste DNS sfugge ai filtri e viene inoltrata verso DNS pubblici come quelli di Google o Cloudflare, riducendo drasticamente l’efficacia delle policy di sicurezza.

Perché non è semplice obbligare i dispositivi all’uso del DNS locale

In una rete domestica o aziendale che utilizza un resolver DNS locale, gran parte del traffico di risoluzione dei nomi può eludere completamente i filtri configurati, senza alcun segnale evidente per l’amministratore.

La diffusione di protocolli DNS cifrati, l’uso di indirizzi DNS hardcoded nei dispositivi IoT e le implementazioni aggressive lato browser hanno modificato il comportamento del traffico di rete rispetto al modello tradizionale su porta 53.

Configurazioni diffuse come AdGuard Home o Pi-hole si basano su un modello centralizzato: i dispositivi ricevono tramite DHCP l’indirizzo del resolver locale e tutte le richieste DNS sono automaticamente gestite e filtrate.

Tuttavia, il comportamento reale dei client moderni è molto più eterogeneo. Alcuni dispositivi ignorano il DNS assegnato, altri incapsulano le query in HTTPS o TLS, mentre diverse applicazioni utilizzano indirizzi IP di resolver pubblici codificati direttamente nel software. Il risultato è che query relative a tracker, pubblicità o domini di telemetria possono essere risolte fuori dal perimetro controllato, bypassando completamente le blocklist configurate.

Come i dispositivi aggirano il DNS locale

Abbiamo parlato in precedenza di DNS hardcoded. Dispositivi come Google Home, Chromecast e Android TV prevedono l’uso di indirizzi come 8.8.8.8 e 8.8.4.4 (DNS Google) direttamente nel firmware. Anche se il DHCP indica l’utilizzo di un resolver locale, questi dispositivi inviano le query direttamente ai resolver pubblici, aggirando ogni filtro.

Stessa cosa può essere fatta personalizzando le impostazioni dell’interfaccia di rete in qualunque sistema operativo: gli utenti in possesso dei diritti necessari (di solito possono farlo solo gli account dotati di privilegi amministrativi…) possono bypassare il DNS impostato in locale. Semplicissimo farlo dalle impostazioni di Android e iOS, sui dispositivi mobili.

In un altro articolo abbiamo visto come cambiare DNS in Windows, Linux, macOS e Android.

Un secondo metodo sempre più diffuso è l’utilizzo di DNS-over-HTTPS (DoH). In questo caso le query DNS sono incapsulate all’interno di pacchetti dati HTTPS sulla porta 443, rendendole indistinguibili da una normale navigazione Web. Firewall e sistemi di ispezione superficiale non possono discriminare tra una richiesta Web e una risoluzione DNS, rendendo inefficace il filtraggio basato sulle porte.

Accanto a DoH si trova DNS-over-TLS (DoT), che utilizza una connessione TLS dedicata sulla porta 853. Pur essendo più semplice da bloccare rispetto a DoH, invia comunque le query verso resolver esterni senza passare dal sistema locale. Infine, DNS-over-QUIC (DoQ) sfrutta il protocollo QUIC sulle porte UDP 853 o 443, eliminando l’overhead proprio dell’handshake TLS e migliorando la latenza, ma rendendo ancora più complesso il controllo del traffico.

Architettura di un resolver locale con OPNsense, AdGuard Home e Unbound

Una configurazione robusta per il controllo DNS prevede più livelli. Il primo è il resolver locale, che riceve le query sulla porta 53 e applica le blocklist. Se una query non è bloccata o non è presente in cache, può essere inoltrata a un resolver ricorsivo come Unbound, eseguito su firewall come OPNsense.

Unbound opera in modalità ricorsiva completa: interroga i root server DNS, poi i server TLD e infine i server autorevoli del dominio richiesto. In questo modo non si appoggia a provider esterni come Cloudflare o Google, eliminando la dipendenza da resolver pubblici e migliorando la privacy. Il firewall OPNsense diventa lo strato di enforcement che applica NAT, blocchi di porta e filtri IP.

Anche chi non volesse mettere in piedi una configurazione del genere ma preferisse, ad esempio, impostare OpenDNS come server DNS sul router permette di stabilire, grazie a una dashboard personale, quali siti permettere e quali bloccare.

NextDNS è un resolver DNS cloud-based altamente personalizzabile che consente di applicare regole di filtraggio e sicurezza direttamente al livello DNS, cioè prima ancora che il browser o l’app stabiliscano la connessione verso il server remoto. In termini tecnici, si colloca tra il client e l’infrastruttura DNS pubblica, intercettando e gestendo le query.

A differenza dei DNS pubblici “statici” (Google, Cloudflare, Quad9), che restituiscono semplicemente l’IP associato a un dominio, NextDNS consente di definire policy granulari su cosa risolvere e cosa bloccare.

In tutti i casi, se si imposta un server DNS in locale, state sicuri che parte dei dispositivi collegati in LAN non lo utilizzerà eludendo così qualunque regola impostata.

Come contrastare l’uso di DNS alternativi

Per evitare che i dispositivi utilizzino server DNS hardcoded, è possibile intercettare tutte le richieste DNS in uscita.

Una regola di port forwarding sul firewall reindirizza qualsiasi traffico TCP/UDP sulla porta 53 verso il resolver locale. In questo modo, anche se un dispositivo tenta di contattare 8.8.8.8, la richiesta viene silenziosamente deviata verso il resolver interno senza che il client se ne accorga.

Il blocco di DoT è relativamente semplice: in generale basta filtrare la porta 853 in uscita. Questo impedisce a qualsiasi dispositivo di stabilire connessioni DNS su TLS verso resolver esterni.

Tuttavia, l’evoluzione verso QUIC e HTTP/3 renderebbe necessario bloccare anche il traffico UDP sulla porta 443, che può essere utilizzato sia per DNS-over-QUIC sia per versioni avanzate di DoH. Il risultato è che il protocollo HTTP/3, la versione più recente e veloce del protocollo Web basata su QUIC, viene disattivata e i browser tornano automaticamente a utilizzare HTTP/2 come alternativa compatibile.

Bloccare i resolver DoH tramite DNS e firewall

Molti client DoH risolvono inizialmente il nome del resolver tramite DNS tradizionale. Inserire nelle blocklist domini come cloudflare-dns.com, dns.google e dns.quad9.net impedisce ai client di individuare i server DoH. Liste curate come DNS Blocklists includono migliaia di domini associati a servizi DNS cifrati.

Quando invece un’applicazione utilizza direttamente indirizzi IP hardcoded, è necessario intervenire a livello firewall. Alias dinamici basati su URL Table consentono di importare elenchi aggiornati di IP appartenenti a resolver pubblici. Una regola di blocco verso tali indirizzi impedisce sia il traffico DNS sia eventuali connessioni HTTPS dirette ai servizi DoH.

Utilizzare Unbound in modalità ricorsiva consente di bloccare completamente l’accesso ai resolver pubblici senza interrompere la risoluzione DNS. Il resolver locale interroga direttamente i server autorevoli, evitando di inoltrare le query a servizi terzi. Ciò garantisce maggiore controllo e riduce l’esposizione dei dati di navigazione a provider esterni.

Limiti strutturali delle difese DNS: perché spesso non funzionano

Nonostante l’approccio multilivello che abbiamo finora descritto, alcune limitazioni rimangono inevitabili.

Le applicazioni dei grandi provider possono integrare DNS cifrato nei propri domini principali, rendendo impossibile bloccarlo senza compromettere il funzionamento del servizio. Inoltre, la creazione di resolver DoH privati su VPS o su altri sistemi server rende inefficaci le blocklist statiche.

Un’altra criticità è rappresentata dalle VPN: quando un dispositivo stabilisce un tunnel cifrato, l’intero traffico DNS è incapsulato al suo interno e il firewall locale non ha visibilità sulle query di risoluzione dei nomi di dominio.

A questo punto si arriva alla domanda più pragmatica: ha davvero senso ostinarsi a bloccare ogni forma di DNS alternativo all’interno della rete locale?

La risposta, per quanto possa sembrare controintuitiva per chi ha investito tempo nella costruzione di un’infrastruttura di filtraggio sofisticata, è che il blocco totale è difficilmente sostenibile nel lungo periodo e, in molti contesti domestici, nemmeno particolarmente utile. L’architettura del traffico moderno è progettata per essere resiliente a interferenze locali: browser, sistemi operativi e applicazioni si muovono sempre più verso modelli di comunicazione cifrata e autonomi, nei quali il DNS è solo uno dei tanti canali attraverso cui passa l’informazione.

Bloccare i DNS alternativi in LAN è complesso, spesso inefficace e raramente conveniente

Forzare rigidamente tutti i dispositivi a utilizzare un resolver interno richiede un livello di controllo tipico di ambienti enterprise: segmentazione della rete, gestione centralizzata dei dispositivi, policy di sicurezza coerenti e capacità di monitoraggio continuo. In una rete domestica o in una piccola LAN eterogenea, dove convivono smartphone personali, smart TV, IoT e dispositivi ospiti, il costo operativo e la complessità della manutenzione tendono a superare i benefici reali.

C’è anche un aspetto funzionale da considerare. Bloccare aggressivamente DoH, DoT e QUIC può introdurre effetti collaterali: peggioramento delle prestazioni percepite, fallback forzati su protocolli meno efficienti, malfunzionamenti di alcune app e perdita di funzionalità legate alla privacy lato client. In altre parole, nel tentativo di esercitare un controllo assoluto sul DNS si rischia di degradare l’esperienza d’uso complessiva.

Un approccio più realistico consiste nel considerare il DNS filtering locale come uno strumento di mitigazione, non come un meccanismo di enforcement assoluto. Il resolver locale continua a svolgere un ruolo utile per la maggior parte del traffico “standard”, soprattutto per bloccare domini noti legati a pubblicità, tracciamento e malware, ma deve essere integrato con altri livelli di difesa: segmentazione della rete, isolamento dei dispositivi IoT, utilizzo di browser e sistemi operativi aggiornati e, dove possibile, controlli a livello applicativo.