DNS: l'anello che nessuno rafforza

Audit di rete di una PMI industriale, una mattinata. Collego una sonda passiva alla porta mirror dello switch principale e guardo passare il traffico. Tutto è in HTTPS, il direttore HR è fiero del suo firewall nuovo da 18.000 €. Solo che sulla porta 53, in chiaro, scorre la navigazione completa dell’azienda: il dominio dello studio legale consultato il giorno prima, il sito dell’acquirente potenziale, la banca, il medico del lavoro, il concorrente. In venti minuti, ho ricostruito una pratica M&A confidenziale senza decifrare una sola connessione. Il DNS mi ha dato tutto.

La trappola di sempre

Tutti hanno assimilato che HTTPSVersione sicura di HTTP, che cifra la comunicazione tra browser e server tramite TLS.Vedi il glossario protegge. Il lucchetto verde, la «s» nella barra degli indirizzi, il corso interno che ripete «verifichi che il sito sia in HTTPS»: il riflesso è acquisito. Ed è giusto — il contenuto dei Suoi scambi è effettivamente cifrato tra il Suo browser e il server. Il problema è che questo riflesso si ferma esattamente là dove dovrebbe cominciare a porsi delle domande. Nessuno si chiede cosa accade prima della connessione HTTPS. E prima, c’è il DNSSistema che risolve i nomi di dominio in indirizzi IP. Vettore di sorveglianza e censura molto sottovalutato.Vedi il glossario.

Prima che il Suo browser apra una connessione cifrata verso posta-banca.it, deve tradurre quel nome in indirizzo IP. Questa traduzione, nella configurazione predefinita di praticamente tutti i dispositivi del pianeta, parte in chiaro, sulla porta 53, verso il resolver del Suo ISPSistema che risolve i nomi di dominio in indirizzi IP. Vettore di sorveglianza e censura molto sottovalutato.Vedi il glossario o del Suo operatore mobile. Nessuna cifratura, nessuna autenticazione, nessuna riservatezza. È il protocollo del 1987, ed è ancora l’impostazione predefinita nel 2026. Il contenuto del Suo scambio con la banca è protetto. Il fatto che parli con quella banca, a che ora, quante volte, da quale dispositivo: visibile a chiunque sul percorso.

Il discorso dominante sulla «sicurezza di rete» alimenta questo buco. Si vendono firewall di nuova generazione, gateway web, soluzioni di ispezione del traffico a cinque cifre, mentre il canale di fuga più elementare resta spalancato. Peggio: molti di questi apparati forzano il DNS a passare attraverso di loro in chiaro, con il pretesto della «visibilità». Il riflesso «ho HTTPS, sono tranquillo» è diventato un punto cieco collettivo. Il DNS è l’anello che nessuno rafforza perché nessuno lo guarda — ed è precisamente ciò che ne fa un vettore di sorveglianza così redditizio per chi sa ascoltare.

Modello di minaccia reale: cosa rivela il DNS, e a chi

Pensi al DNS come all’elenco di internet. Ogni volta che un dispositivo vuole raggiungere un servizio, interroga un resolver: «qual è l’indirizzo di questo dominio?». Questa domanda, ripetuta migliaia di volte al giorno e per dispositivo, disegna un ritratto di una precisione temibile. Non il contenuto — l’intenzione. E l’intenzione basta ampiamente.

In DNS non cifrato, ecco cosa è leggibile da chiunque ascolti: ogni dominio che visita, l’orario esatto, la frequenza. Non sono solo i siti che apre a mano nel browser. Le Sue applicazioni mobili fanno richieste DNS in permanenza — il Suo client mail interroga il server ogni minuto, la Sua messaggistica cifrata risolve il suo dominio di relay, i Suoi oggetti connessi chiamano il loro cloud, i Suoi aggiornamenti automatici contattano i loro server. Il DNS tradisce la lista delle Sue applicazioni, le Sue abitudini di sonno (l’ora della prima richiesta al mattino), i Suoi ritmi di lavoro, i servizi bancari e medici che usa, a volte la Sua localizzazione implicita tramite la scelta dei resolver regionali e dei CDNSistema che risolve i nomi di dominio in indirizzi IP. Vettore di sorveglianza e censura molto sottovalutato.Vedi il glossario.

Chi vede questi dati? Tre attori, come minimo. Il Suo ISP o operatore mobile anzitutto, che gestisce il resolver predefinito — in Italia e in tutta l’Unione, i metadati di connessione sono conservati legalmente a lungo, e diversi ISP sfruttano commercialmente questi dati o reindirizzano i domini inesistenti verso le proprie pagine pubblicitarie. Poi, chiunque ascolti sulla rete locale: il Wi-Fi dell’hotel, il caffè, l’aeroporto, la sala conferenze, là dove non controlla nulla e dove la porta 53 passa in chiaro sotto il naso di tutti gli altri client. Infine, il Suo resolver stesso, qualunque esso sia — scegliere un resolver significa scegliere a chi affida l’intera Sua cronologia di navigazione.

C’è una sottigliezza che la gente dimentica. Anche quando cifra il DNS, l’handshake TLSProtocollo di cifratura del trasporto, base di HTTPS e della sicurezza web moderna.Vedi il glossario contiene ancora il Server Name Indication (SNI) in chiaro — il nome del dominio, visibile a ogni osservatore di rete. Il meccanismo Encrypted Client Hello (ECH), standardizzato tramite la RFC 9460, cifra questo SNI, ma il suo dispiegamento resta parziale nel 2026 e dipende dal fatto che il sito bersaglio lo supporti lato server. In altri termini: rafforzare il DNS è necessario, ma è solo una parte del quadro. Il DNS resta comunque il vettore di fuga più ampio, il più sistematico e il più semplice da tappare.

Un altro punto che devo martellare in audit, perché torna di continuo: il DNS in chiaro non è solo un problema di riservatezza, è anche un problema di integrità. Sulla porta 53 non autenticata, qualsiasi attore sul percorso di rete può rispondere al posto Suo — è il DNS spoofing. Chiede l’indirizzo della Sua banca, un attaccante sul Wi-Fi dell’hotel risponde con l’IP del suo server di phishing, e il Suo browser andrà docilmente da lui. HTTPS e la validazione del certificato recuperano una parte del colpo (il sito falso non avrà il certificato giusto), ma non sempre, e non per i numerosi flussi che non validano rigorosamente il certificato. Cifrare e autenticare il DNS chiude questa porta nello stesso momento in cui chiude l’ascolto. Due problemi, una sola misura.

E bisogna uscire dall’idea che «non mi riguarda, non ho nulla da nascondere». Il modello di minaccia reale non è «qualcuno legge le mie ricerche su Google». È un aggregato: il Suo operatore rivende un profilo comportamentale, un broker di dati lo incrocia con altre fonti, un assicuratore o un datore di lavoro potenziale lo acquista, uno Stato lo richiede, o un attaccante mirato ricostruisce le Sue abitudini per preparare uno spear phishingPhishing mirato a una persona specifica, costruito a partire dal suo profilo OSINT.Vedi il glossario credibile. La richiesta DNS isolata è innocua. Il flusso DNS completo su sei mesi è un dossier.

L’approccio giusto: Do53, DoT, DoH, e il resolver giusto

Lo spostamento è uno dei più redditizi di tutta la sicurezza operativa: poco sforzo, effetto immediato, gratuito nella maggior parte dei casi. Ma bisogna comprendere le tre modalità per non sbagliare battaglia.

Do53 — il DNS classico, porta 53, in chiaro. È l’impostazione predefinita su tutti i Suoi dispositivi. Nessuna cifratura, nessuna autenticazione della risposta. Il Suo resolver vede le Sue richieste in chiaro, e qualsiasi apparato sul percorso di rete anche. È ciò da cui vuole andarsene.

DoTVariante di DoH che utilizza TLS diretto anziché HTTPS.Vedi il glossario — DNS over TLS, porta 853. Le richieste sono cifrate in un tunnel TLS dedicato, definito dalla RFC 7858. Nessuno può più leggerle in transito. L’inconveniente: la porta 853 è identificabile come «traffico DNS cifrato». Un apparato di rete ostile può bloccarla, il che costringe certi sistemi a ricadere in chiaro sulla porta 53. È la modalità nativa e la più pulita su mobile (il «DNS privato» di Android), perché si applica all’intero sistema.

DoHProtocollo che cifra le query DNS in HTTPS, nascondendole all'ISP.Vedi il glossario — DNS over HTTPS, porta 443. Le richieste sono incapsulate in traffico HTTPS standard, secondo la RFC 8484. Doppio vantaggio: la cifratura, e soprattutto l’indistinguibilità — le Sue richieste DNS somigliano a qualsiasi connessione web. Bloccare DoH senza rompere tutto il traffico HTTPS è estremamente difficile, il che ne fa l’arma di elezione contro la sorveglianza di rete attiva. È la modalità privilegiata nel browser e nei contesti in cui la rete locale è ostile.

Non confonda tutto questo con DNSSEC, che torna spesso nella discussione. DNSSEC firma crittograficamente le risposte DNS — garantisce l’integrità (la risposta non è stata falsificata in transito), ma non cifra nulla. DNSSEC e DoH/DoT sono complementari, non concorrenti: l’uno protegge dalla falsificazione, gli altri dall’ascolto.

Una volta scelta la modalità, resta la vera decisione: il resolver. È l’entità che fa le richieste reali per Lei, quindi quella che vede tutto. Cambiarlo è l’azione più d’impatto per il minimo sforzo.

• Quad9Sistema che risolve i nomi di dominio in indirizzi IP. Vettore di sorveglianza e censura molto sottovalutato.Vedi il glossario (9.9.9.9) — gestito da una fondazione svizzera senza scopo di lucro, policy no-logs documentata, filtraggio dei domini malevoli attivo di default (base di minacce aggregata), supporto DoH e DoT. La mia scelta predefinita per chi vuole sicurezza senza configurazione. Se dovessi raccomandare un solo resolver a qualcuno che non vuole regolare nulla, è questo.
• Mullvad DNS — orientato alla riservatezza pura. Se usa già Mullvad VPN, il DNS passa nel tunnel. Mullvad propone anche resolver pubblici utilizzabili da soli, con varianti che filtrano pubblicità e tracking. Nessun filtraggio di sicurezza di default: scelta di privacy, non di sicurezza.
• NextDNSSistema che risolve i nomi di dominio in indirizzi IP. Vettore di sorveglianza e censura molto sottovalutato.Vedi il glossario — il configurabile. Crea un profilo: blocco pubblicità, tracking, malware, categorie. Log opzionali — attivabili per fare audit del Suo traffico, disattivabili completamente. Freemium: 300.000 richieste/mese gratuite, poi circa 2 €/mese. Eccellente per le famiglie e le PMI che vogliono una visibilità controllata.
• CloudflareSistema che risolve i nomi di dominio in indirizzi IP. Vettore di sorveglianza e censura molto sottovalutato.Vedi il glossario (1.1.1.1) — il più rapido in latenza, claim no-logs parzialmente sottoposto ad audit. Riserva: Cloudflare è una megacorp americana che ospita già una frazione massiccia del web. La loro visibilità sui flussi è colossale. Accettabile per il grande pubblico, meno per chi vuole evitare la concentrazione di rischio presso un unico attore soggetto al diritto statunitense.
• ISP predefinito — da fuggire. Profilazione commerciale, reindirizzamenti pubblicitari, conservazione legale. È esattamente il resolver da cui vuole andarsene.
• Self-hosted (Unbound + Pi-hole) — controllo totale. Unbound risolve in modo ricorsivo direttamente presso i server radice, senza terzi. Pi-hole filtra localmente pubblicità e tracking per tutta la rete. Si fa carico della manutenzione, e non La segue in mobilità (salvo VPN di ritorno). La scelta giusta per il domicilio rafforzato, non per il viaggio.

Una parola sul self-hosted, perché è qui che la gente si fa più illusioni. Pi-hole è un resolver locale che consulta liste di blocco: quando un dispositivo chiede l’IP di doubleclick.net o di un dominio di telemetria, Pi-hole risponde «NXDOMAIN» e la connessione non avviene mai. È potente — blocca pubblicità e tracking a livello di rete per tutti i dispositivi, inclusi la SmartTV, la console e gli oggetti connessi che non si possono configurare individualmente, e Le dà una visibilità completa su ciò che ogni dispositivo chiama. Ma Pi-hole, da solo, non cifra nulla. Tutto ciò che non blocca parte in chiaro verso il Suo ISP. La combinazione che sta in piedi è Pi-hole per il filtraggio, Unbound dietro per la risoluzione ricorsiva diretta, e un upstream cifrato (DoT) per le richieste che escono comunque. Più complessa da montare, ma è l’unico montaggio che Le dà al contempo filtraggio, riservatezza e controllo. E tenga a mente che certe app in DoH hardcoded (Firefox, certi servizi Google) aggirano puramente e semplicemente Pi-hole — il filtraggio di rete ha i suoi limiti di fronte alle applicazioni che decidono il proprio resolver.

Cosa comporta concretamente

Errori che si vedono di continuo

• Configurare DoH solo nel browser. Parziale per costruzione. Il client mail, le app mobili, i servizi di sistema e gli oggetti connessi continuano con il resolver in chiaro predefinito. Si spunta una casella e ci si crede coperti per il 100% del traffico mentre se ne copre una frazione.
• Credere che Pi-hole cifri le richieste. Pi-hole filtra, non cifra. Senza upstream DoHProtocollo che cifra le query DNS in HTTPS, nascondendole all'ISP.Vedi il glossario o DoTVariante di DoH che utilizza TLS diretto anziché HTTPS.Vedi il glossario configurato, tutto ciò che Pi-hole non blocca — cioè la grande maggioranza — parte in chiaro verso il Suo ISP. Pi-hole senza upstream cifrato è filtraggio pubblicitario, non riservatezza.
• Dimenticare il DNS in viaggio. Una configurazione DoH posata a casa non si applica sulla 4G o sul Wi-Fi d’hotel se vive solo nel browser. All’estero, è il resolver dell’operatore locale a riprendere il controllo. Solo il DNS a livello di sistema (profilo iOS, DNS privato Android) viaggia con Lei.
• Lasciare l’ISP come resolver «perché funziona». Funziona, sì, ed è esattamente il problema: funziona esponendo al contempo la Sua navigazione completa a un attore che la conserva e la sfrutta commercialmente.
• Non testare mai. Molti pensano di essere in DoH e in realtà fanno trapelare verso il resolver dell’ISP. dnsleaktest.com(opens in a new tab) e ipleak.net(opens in a new tab) risolvono la questione in dieci secondi. Una configurazione DNS non verificata è un’ipotesi, non una protezione.

Checklist azionabile

• N1 Attivare DoH o DoT a livello di sistema su tutti i dispositivi, non solo nel browser
• N1 Scegliere Quad9 (9.9.9.9) per la sicurezza, o Mullvad/NextDNS a seconda del bisogno di riservatezza o di visibilità
• N1 Verificare l'assenza di DNS leak con dnsleaktest.com dopo ogni modifica
• N2 Su iOS 14+: installare il profilo DNS NextDNS o Cloudflare (Impostazioni > Profilo DNS)
• N2 Su Android 9+: attivare il DNS privato (DoT) in Impostazioni > Rete e Internet
• N2 Verificare che il DNS del viaggio tenga a livello di sistema, non solo nel browser
• N2 A casa: Pi-hole per il filtraggio + Unbound in risoluzione ricorsiva + upstream cifrato
• N3 In azienda: resolver DNS interno con logging (Umbrella, NextDNS Business, Infoblox) collegato al SIEM
• N3 In azienda: disattivare il DoH applicativo selvaggio tramite GPO/MDM, imporre il resolver padroneggiato come unico punto di cifratura
• N3 Seguire il tasso di richieste che passano per il resolver padroneggiato (> 98%) e il tempo di rilevamento dei domini malevoli

Per approfondire

I riferimenti normativi sono nel frontmatter: la RFC 8484 specifica DoH, la RFC 7858 specifica DoT, e la RFC 9460 descrive la cifratura del SNI tramite ECH che completa il quadro. Sul fronte resolver, le policy di riservatezza di Quad9 e NextDNS dettagliano esattamente cosa viene registrato — le legga prima di affidare la Sua cronologia a chicchessia.

Il DNS è solo un pezzo del rafforzamento di rete. Per capire cosa protegge davvero una VPN e cosa non tocca — incluso il tranello del DNS leak fuori dal tunnel —, veda VPN: il 95% del marketing è falso. Per le reti non padroneggiate in cui il DNS in chiaro è più esposto, legga Wi-Fi pubblico: il rischio reale. E per applicare questo rafforzamento a livello di sistema operativo invece che applicazione per applicazione, veda Rafforzare il proprio OS.