resolver

Scegliere i DNS consigliati sembra una di quelle operazioni che si liquidano in pochi secondi: si incollano due indirizzi IP nelle impostazioni del router, del sistema operativo o del browser e tutto fila liscio. Eppure dietro questo gesto apparentemente innocuo si nasconde una decisione importante. Ogni richiesta di risoluzione dei nomi, dal sito aperto nel browser fino al servizio cloud che un'app contatta in background, passa attraverso un soggetto che può raccogliere parecchie informazioni sull'utente. Il server DNS nasce con uno scopo semplice: tradurre nomi facili da ricordare, come google.com o ilsoftware.it, in indirizzi IP che le macchine sanno raggiungere. Per decenni questa traduzione ha viaggiato quasi sempre in chiaro, su UDP e porta 53. Veloce, compatibile con tutto, ma anche esposta a osservazione, manipolazioni lungo il percorso e politiche di filtraggio non sempre trasparenti. Oggi i resolver pubblici globali sono decine, con caratteristiche molto diverse tra loro, e orientarsi non è banale. Perché il resolver DNS non è un dettaglio da trascurare Quando un dispositivo deve raggiungere un dominio, di solito interroga uno stub resolver locale, cioè il componente del sistema operativo o dell'applicazione che inoltra la richiesta. Lo stub si appoggia poi a un resolver ricorsivo, spesso quello del provider Internet, del router oppure di un servizio pubblico come Cloudflare, Google Public DNS, Quad9, OpenDNS, AdGuard DNS, NextDNS, Control D o Mullvad DNS. Il resolver ricorsivo conosce per forza la risposta finale, ovvero l'indirizzo IP corretto del dominio cercato. Se non ha il record in cache, scorre la gerarchia DNS: root server, server del TLD, poi server autoritativi del dominio. Lavora in autonomia e conserva le risposte secondo il TTL, il tempo di validità deciso da chi gestisce il nome di dominio. Da qui nascono due effetti. La cache migliora le prestazioni di risoluzione, ma allo stesso tempo concentra una visibilità notevole sulle abitudini di navigazione. Un resolver vede le richieste in arrivo da un indirizzo IP o da una rete domestica. Non sempre conosce la singola pagina aperta, ma spesso sa quale dominio è stato contattato, quando e con che frequenza. Su una rete aziendale o casalinga può dedurre applicazioni usate, dispositivi IoT presenti, servizi di streaming, piattaforme cloud e perfino abitudini ricorrenti. DNS cifrato: cosa protegge e cosa lascia comunque scoperto Il DNS classico, lo abbiamo detto, gira sulla porta 53 e punta tutto su compatibilità e latenza minima. Il DNS-over-TLS incapsula invece le query in una connessione TLS, di norma sulla porta 853. Il DNS-over-HTTPS infila i messaggi dentro richieste HTTPS, di solito verso un endpoint come /dns-query. C'è poi il DNS-over-QUIC, che sfrutta il protocollo QUIC con TLS 1.3 integrato e si comporta meglio quando i pacchetti si perdono per strada. Questi protocolli servono a impedire che qualcuno lungo il percorso, un operatore WiFi, un provider locale o un apparato intermedio, legga o alteri le query. Attenzione però: non rendono anonimo l'utente davanti al resolver scelto. Quest'ultimo continua a vedere tutto, anche se il tragitto tra dispositivo e resolver è cifrato. In pratica si sposta la fiducia dal provider di accesso al resolver pubblico o al server DNS aziendale configurato a dovere. Le misurazioni su DoH e DoT mostrano un overhead reale, soprattutto all'avvio della connessione, ma spesso contenuto se si guarda al caricamento di una pagina nel suo insieme. Il DNS classico resta competitivo su collegamenti instabili o ad alta latenza. Nelle reti moderne, invece, la differenza percepita diventa modesta grazie a cache, connessioni persistenti e risoluzione parallela. Privacy, log e criteri tecnici che fanno la differenza La privacy a livello di DNS non dipende solo dalla cifratura del canale. Un resolver raggiunto tramite DoH o DoT non espone facilmente le query alla rete WiFi, ma vede comunque i domini richiesti e sa da quali IP arrivano. Privilegiare resolver con logging minimo o assente non è una garanzia matematica, ma aiuta a separare i servizi più conservativi da quelli che raccolgono dati diagnostici o statistiche. Del resto un resolver riceve richieste molto rivelatrici: domini bancari, servizi sanitari, piattaforme di lavoro, app di messaggistica. Fare due più due è semplice. C'è poi il tema della giurisdizione. Un operatore risponde al quadro normativo del Paese in cui opera, e la localizzazione legale può incidere su richieste delle autorità, obblighi di conservazione e possibilità di audit. Per l'utente domestico sembra un dettaglio lontano, per aziende e professionisti esposti diventa un criterio di primo piano. Sul fronte tecnico contano anche DNSSEC ed EDNS Client Subnet. DoH, DoT e DoQ proteggono la query lungo il percorso, mentre DNSSEC verifica che la risposta non sia stata falsificata. Google Public DNS, Cloudflare e Quad9, per esempio, validano DNSSEC, riducendo il rischio di spoofing e cache poisoning. ECS, invece, comunica al server autoritativo una porzione della rete dell'utente: utile per indirizzare verso il nodo CDN più vicino, meno rassicurante sul piano della riservatezza, perché quell'informazione esce dal resolver. Un resolver pubblico non andrebbe scelto soltanto perché cifrato, veloce o senza log. La questione è quale compromesso si accetta. Chi punta alla massima privacy cerca resolver che registrano il minimo, evitano ECS e operano in giurisdizioni affidabili. Chi vuole compatibilità con CDN e servizi globali può preferire ECS e grandi reti anycast. Chi deve proteggere utenti poco esperti trova comodo un resolver con blocco malware già attivo, mentre in ambito aziendale la soluzione più solida resta un resolver interno con validazione DNSSEC e forwarder cifrato verso upstream selezionati. Una regola pratica utile parte da tre domande. Di chi ci si fida più del proprio provider Internet? Quali controlli applicare alle query? Quali rinunce si accettano in cambio di più privacy o più filtraggio? La risposta cambia da casa all'ufficio, dallo smartphone al router, dal singolo utente alla rete aziendale. Il resolver perfetto non esiste, esiste una configurazione ragionata e coerente con ciò che si vuole davvero proteggere.

resolver

DNS consigliati: quali scegliere e perché non sono un dettaglio