Filtro DNS della VPN: bloccare i nomi non blocca gli annunci

Una sola riga di dnsmasq può rispondere a un nome con NXDOMAIN, e questo è l’intero meccanismo. Non legge mai l’HTML, non ispeziona il percorso di una richiesta e non vede mai cosa fa un’applicazione con una connessione che ha già aperto. Confrontarlo con un’estensione del browser significa quindi confrontare due compiti diversi. Uno decide se un nome si risolve; l’altro decide cosa accade dopo.

Cosa controlla davvero un filtro di nomi

L’opzione address=/metrics.example/, senza nulla dopo l’ultima barra, fa restituire NXDOMAIN dal resolver per quel nome e i suoi sottodomini. Lasciare vuoto l’indirizzo è la parte importante: evita di mandare i client a un server sostitutivo estraneo o di far passare un indirizzo di loopback per la destinazione reale. Il manuale di dnsmasq descrive questa forma come risposta negativa e non come reindirizzamento.

Tutto ciò che la regola può fare deriva da quell’unica decisione. Un client che interroga questo resolver ottiene una risposta negativa; un client che interroga un altro resolver ottiene ciò che dice quel resolver. Il filtro non sa nulla del percorso, della stringa di query o dell’account che l’applicazione avrebbe usato.

Questa granularità conta perché un nome host serve spesso a più scopi. Gli endpoint di accesso, le immagini e il tracciamento possono condividere un dominio, e una regola che rimuove l’intero nome può rimuovere anche un flusso di lavoro. Una politica a livello di nome deve accettare questo compromesso o scegliere nomi più stretti.

In cosa differisce un blocco lato client

Un’estensione del browser vede la richiesta prima che parta, quindi può far corrispondere un percorso URL, annullare una richiesta specifica e nascondere l’elemento che avrebbe mostrato il risultato. Può consentire example.com/article rifiutando example.com/ads/, cosa che nessuna risposta DNS può esprimere. Questa vista a livello di percorso è la capacità che un resolver semplicemente non ha. È anche il motivo per cui un elenco di filtri costruito per uno strumento raramente si comporta allo stesso modo nell’altro.

Il prezzo è la portata. Quella protezione vive dentro un browser, in un profilo, su un dispositivo, e scompare quando l’utente passa a un’altra applicazione. Un filtro DNS configurato sul gateway copre ogni dispositivo che usa il resolver del gateway, compresi quelli su cui non è possibile installare alcuna estensione.

Nessuna delle due soluzioni è completa da sola. Un filtro DNS non può rimuovere un identificatore che una pagina ha già inviato, e un’estensione del browser non può proteggere un’applicazione che non la carica mai.

Il percorso del resolver decide se qualcosa di tutto questo si applica

Una VPN può annunciare un server DNS e comunque non ricevere ogni query. Un browser con DNS crittografato configurato, un’applicazione con un proprio resolver o un dispositivo su un percorso di rete che esclude il gateway guarderanno tutti altrove. Le piattaforme mobili offrono sempre più spesso un’impostazione di DNS privato che sovrascrive silenziosamente ciò che suggerisce il tunnel.

Provate quindi il percorso e non la politica. Interrogate il resolver previsto direttamente dal gateway, poi interrogatelo da un client e confrontate, quindi osservate se un nome che dovrebbe essere bloccato fallisce davvero nell’applicazione che l’utente esegue.

Le risposte in cache e i socket aperti rendono tutto questo rumoroso. Una pagina che ha già caricato le sue risorse continuerà a funzionare dopo il cambio di regola, quindi una connessione nuova è una prova migliore del ricaricamento di una vecchia scheda.

Provate entrambe le direzioni prima di dichiarare un risultato

Usate un nome di documentazione bloccato di proposito, un nome pubblico consentito e un nome privato di cui il servizio ha bisogno:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

Una risposta vuota per il nome bloccato, un indirizzo normale per quello pubblico e un indirizzo privato per quello interno mostrano insieme che il filtraggio, la risoluzione a monte e i record locali funzionano. Se tutti e tre falliscono, siete di fronte a un problema a monte o all’ascoltatore, non a un filtro.

Mantenete l’affermazione stretta in tutto ciò che pubblicate internamente. Si tratta di filtraggio di domini su un resolver, non di ispezione dei contenuti, non di filtraggio dei percorsi e non di una promessa che nessuno venga tracciato. Indicate il proprietario della politica, il percorso di eccezione e il periodo di conservazione delle query accanto alle regole, perché un filtro che registra ogni ricerca ha un suo costo per la privacy.