DNS consigliati: come scegliere il resolver migliore per privacy, sicurezza e velocità

Scegliere un resolver DNS pubblico sembra una decisione banale: si copiano due indirizzi IP nelle impostazioni del router, del sistema operativo o del browser e la navigazione funziona alla perfezione. In realtà, si tratta di un passaggio molto importante: ogni richiesta di risoluzione dei nomi, dal sito web aperto nel browser al servizio cloud contattato da un’app, passa da un soggetto che può raccogliere un ampio ventaglio di informazioni.

Il server DNS nasce per tradurre nomi mnemonici, come google.com o ilsoftware.it, in indirizzi IP raggiungibili dalle macchine. Per decenni la risoluzione DNS (traduzione del nome di dominio espresso in forma mnemonica in uno o più indirizzi IP) ha viaggiato soprattutto in chiaro su UDP e sulla porta 53; veloce, semplice, compatibile con tutto, ma esposta a osservazione, manipolazioni lungo il percorso e politiche di filtraggio non sempre trasparenti.

Ci siamo imbattuti nell’eccellente lavoro “DNS Resolver Guide“: oggi esistono decine di resolver pubblici globali, con caratteristiche molto diverse tra loro. La pagina confronta 30 servizi, distribuiti su 16 giurisdizioni, e considera trasporti cifrati come DNS-over-HTTPS, DNS-over-TLS e DNS-over-QUIC, oltre a DNSSEC, IPv6, politiche di logging, blocco malware, filtri famiglia, ad blocking, EDNS Client Subnet e tipo di operatore. È uno strumento che mette in evidenza i DNS consigliati e offre uno specchietto, di immediata consultazione, per selezionare il resolver migliore per le proprie necessità.

Il server o resolver DNS non è un dettaglio tecnico secondario

Quando un dispositivo deve raggiungere un dominio, di norma interroga uno stub resolver locale, cioè il componente del sistema operativo o dell’applicazione incaricato di inoltrare la richiesta. Lo stub si appoggia a un resolver ricorsivo, spesso quello del provider Internet, del router o di un servizio pubblico come Cloudflare, Google Public DNS, Quad9, OpenDNS, AdGuard DNS, NextDNS, Control D, Mullvad DNS e altri.

Il resolver ricorsivo necessariamente conosce la risposta finale, ovvero l’indirizzo IP corretto del dominio che l’utente intende raggiungere.

Se non ha il record in cache, consulta la gerarchia DNS: root server, server del TLD, poi server autoritativi del dominio. Svolge il lavoro in autonomia e conserva temporaneamente le risposte secondo il TTL (time-to-live), il tempo di validità indicato dai gestori del nome di dominio. Da qui derivano due effetti importanti: il server DNS remoto contribuisce a migliorare le prestazioni di risoluzione dei nomi di dominio grazie alla cache, ma concentra anche una visibilità notevole sulle abitudini di navigazione degli utenti.

Un resolver vede le richieste DNS provenienti da un indirizzo IP o da una rete domestica. Non conosce sempre la pagina specifica aperta dall’utente, ma spesso conosce il dominio contattato, il momento della richiesta e la frequenza. Su reti aziendali o domestiche può dedurre applicazioni usate, dispositivi IoT presenti, servizi di streaming, piattaforme cloud, strumenti di lavoro e, in certi casi, comportamenti ricorrenti.

DNS cifrato: cosa protegge davvero e cosa no

Abbiamo detto che il DNS classico opera sulla porta 53, privilegia compatibilità e latenza minima.

DNS-over-TLS, invece, incapsula le query DNS in una connessione TLS, di solito sulla porta 853. DNS-over-HTTPS trasporta i messaggi DNS dentro richieste HTTPS, tipicamente verso un endpoint come /dns-query. Ancora, DNS-over-QUIC usa il protocollo QUIC e beneficia di TLS 1.3 integrato ed è caratterizzato da un migliore comportamento in presenza di perdita di pacchetti.

Questi protocolli servono a impedire che qualcuno lungo il percorso, per esempio un operatore WiFi, un provider locale o un apparato intermedio, legga o alteri facilmente le query DNS. Non rendono anonimo l’utente nei confronti del resolver scelto: quest’ultimo continua a vedere le richieste, anche se il tragitto tra dispositivo e resolver risulta cifrato.

Ciò che si fa è trasferire la fiducia dal provider di accesso al resolver pubblico oppure al server DNS aziendale opportunamente configurato.

Le misurazioni su DoH e DoT indicano un overhead reale, specialmente all’avvio della connessione, ma spesso contenuto se si prende in considerazione il caricamento di una pagina web nel suo complesso. Il DNS classico resta molto competitivo su collegamenti instabili o ad alta latenza; al tempo stesso, nelle reti moderne, la differenza percepita può diventare modesta grazie a cache, connessioni persistenti e risoluzione parallela.

Che cos’è Evilbit DNS Resolver Guide e perché è utile nella scelta dei DNS consigliati

Il servizio citato in apertura, “DNS Resolver Guide“, si presenta come una guida interattiva e indipendente per la scelta dei DNS consigliati.

Non è una semplice lista di indirizzi IP: la piattaforma confronta 30 DNS globali e mette insieme tre strumenti utili. Il primo è uno strumento utile per filtrare i resolver in base ai requisiti dell’utente; il secondo è un test di latenza DNS-over-HTTPS eseguito direttamente dal browser; il terzo è una tabella completa, ordinabile e ricercabile, con caratteristiche tecniche, politiche di filtraggio, trasporti supportati e note sulla raccolta dei log.

DNS Resolver Guide non prova a indicare un vincitore assoluto. Chiede invece all’utente che cosa conti davvero per lui. Privacy? Blocco malware? Controlli parentali? Velocità? IPv6? DNSSEC? Operatore non commerciale? Giurisdizione europea o svizzera? Da queste risposte costruisce un elenco ragionato di resolver compatibili.

In pratica, chi vuole un resolver senza log, con DoH, DNSSEC e niente EDNS Client Subnet può arrivare rapidamente a una rosa di candidati.

EDNS Client Subnet, o ECS, è un’estensione del DNS che permette al resolver di comunicare al server autorevole una parte dell’indirizzo IP dell’utente, di solito solo il prefisso della rete e non l’IP completo. Serve soprattutto per aiutare CDN e grandi servizi online a scegliere il server più vicino o più adatto all’utente. Per esempio: se usi un resolver DNS pubblico situato lontano da te, ECS può dire al servizio: “questo utente arriva più o meno da questa rete/area“, così il sito può indirizzarti verso un nodo CDN migliore.

Il rovescio della medaglia riguarda la privacy: con ECS, una porzione dell’informazione sulla rete dell’utente non resta confinata nel resolver, ma può raggiungere anche i server autoritativi interrogati.

Chi preferisse invece la massima compatibilità con CDN e servizi streaming, può cercare resolver che inviano ECS. Chi amministra una rete domestica con bambini può selezionare Parental controls and adult-content blocking.

Il test di velocità: come misurare le prestazioni dei server DNS dalla rete dell’utente

La seconda funzione centrale, come accennato in precedenza, è il test di latenza. Premendo “Run speed test“, la pagina misura dal browser dell’utente il tempo di risposta dei resolver compatibili con DNS-over-HTTPS e mostra valori come latenza mediana e miglior risultato. Il test non riguarda i resolver che offrono solo DNS tradizionale o altri trasporti, non interrogabili attraverso la pagina.

Il dettaglio tecnico importante è che la misurazione include anche l’overhead di TLS e HTTP, perché il browser interroga direttamente gli endpoint DoH. Non misura quindi soltanto il tempo teorico di una query DNS, ma il costo reale di una richiesta DNS-over-HTTPS eseguita dalla posizione in cui si trova l’utente, con la sua connessione e il suo browser. È buona cosa ripetere la verifica più volte, perché i risultati possono cambiare in base a rete, orario, instradamento e carico dei server.

Un resolver eccellente su scala globale non sempre si dimostra il più rapido da una connessione italiana, da una rete mobile, da una FTTC congestionata o da una VPN.

La latenza del DNS non decide da sola la velocità di caricamento di una pagina, ma può incidere quando un sito richiama molti domini esterni, CDN, font, API, tracker e risorse di terze parti.

La tabella completa: 30 resolver confrontati voce per voce

La terza area del servizio è la tabella comparativa. Qui “DNS Resolver Guide” raccoglie tutti i 30 resolver pubblici e permette di ordinarli o cercarli per nome, operatore, giurisdizione e funzionalità.

Le colonne includono giurisdizione, tipo di operatore, indirizzi IPv4 e IPv6 principali, filtri disponibili, supporto DNSSEC, trasporti supportati, politica di logging ed EDNS Client Subnet.

Sono informazioni preziose perché molti resolver non offrono una sola modalità: alcuni hanno varianti diverse. C’è infatti un indirizzo per la versione del DNS non filtrato, uno per blocco malware, uno per filtro famiglia, uno per pubblicità e tracker. Alcuni servizi DNS permettono configurazioni personalizzate tramite l’attivazione di un account, come avviene con certe piattaforme orientate al filtraggio avanzato. La tabella aiuta a distinguere il servizio “base” dalle diverse varianti operative.

Il confronto non si limita ai nomi più noti. Accanto a Cloudflare, Google Public DNS, Quad9, OpenDNS, AdGuard DNS, NextDNS, Control D, Mullvad DNS e Yandex, la guida cita anche servizi regionali, comunitari o specializzati.

Il sito aggiunge una nota prudente: le caratteristiche dei provider DNS cambiano: indirizzi IP, endpoint DoH, politiche di logging e filtri possono evolvere. Per questo la tabella offre un punto di partenza molto comodo, ma prima di distribuire una configurazione su router, firewall o dispositivi aziendali conviene sempre verificare gli indirizzi aggiornati nella documentazione ufficiale dell’operatore.

Privacy e log: per non fermarsi allo slogan “no-log“

La privacy dei dati dell’utente, a livello di DNS, non dipende – come abbiamo visto – solo dalla cifratura del canale. Un resolver raggiunto tramite DoH o DoT non espone facilmente le query al provider di accesso o alla rete WiFi, ma vede ovviamente i domini richiesti e sa da quali indirizzi IP sono partite le richieste di risoluzione.

Il servizio che abbiamo scovato consente di privilegiare resolver con logging minimo o assente e operatori orientati alla privacy. Non è una garanzia matematica, ma un modo per separare servizi con politiche più conservative da operatori che raccolgono dati diagnostici, statistiche aggregate o informazioni temporanee per sicurezza e mitigazione degli abusi. D’altra parte, un resolver DNS riceve richieste molto rivelatrici: domini bancari, servizi sanitari, piattaforme di lavoro, dispositivi IoT, app di messaggistica, strumenti cloud: è facile fare due più due.

La guida richiama anche 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, trasparenza e possibilità di audit. Per l’utente domestico può sembrare un dettaglio distante; per aziende, professionisti e soggetti esposti è un criterio di primo piano.

DNSSEC, ECS e trasporti cifrati: criteri tecnici che cambiano il risultato

Il “selezionatore” di “DNS Resolver Guide” permette anche di impostare come requisito la validazione DNSSEC: DoH, DoT e DoQ proteggono la query (richiesta di risoluzione del nome di dominio) lungo il percorso tra client e resolver; DNSSEC, invece, serve a verificare che la risposta DNS non sia stata falsificata.

Un resolver che effettua validazione DNSSEC può rifiutare risposte manipolate o non coerenti con la catena di fiducia. Google Public DNS, Cloudflare e Quad9, ad esempio, validano DNSSEC.

DNSSEC è utile soprattutto perché riduce il rischio di attacchi come spoofing, cache poisoning e manipolazioni durante il percorso tra resolver e server autoritativi. Non tutti i domini lo adottano e alcune configurazioni possono essere incomplete o errate, ma quando l’integrità delle risposte DNS è una priorità, il supporto a DNSSEC dovrebbe essere considerato un requisito essenziale.

Attenzione però a un limite operativo: quando DNSSEC fallisce per un errore di configurazione del dominio, l’utente vede spesso un semplice problema di risoluzione. Da amministratori è sempre utile saper distinguere un dominio inesistente, un timeout, un blocco applicato dal resolver e una validazione DNSSEC fallita. Gli Extended DNS Errors, definiti per migliorare la diagnostica, aiutano a capire il motivo del problema, ma uno studio del 2023 citato da Evilbit segnala differenze marcate tra resolver nella qualità e precisione degli errori restituiti.

In un altro nostro articolo abbiamo ad esempio citato il caso dei domini .de resi irraggiungibili per via di un errore nella gestione di DNSSEC.

Note finali

Un resolver pubblico non va scelto solo perché “cifrato“, “veloce” o “no-log“. Bisogna decidere quale compromesso si accetta:

• Massima privacy: bisogna scegliere resolver che registrano il minimo indispensabile, non usano ECS, operano in una giurisdizione affidabile e, se possibile, supportano ODoH o modelli proxy che separano chi inoltra la richiesta da chi la risolve.
• Compatibilità con CDN e servizi globali: ECS e grandi reti anycast possono migliorare l’instradamento verso il server più vicino o più efficiente.
• Protezione degli utenti non esperti o fragili: un resolver con blocco malware già attivo può ridurre molti rischi comuni. In ambito aziendale, la scelta più solida resta un resolver interno con validazione DNSSEC, forwarder cifrato verso resolver upstream selezionati e policy di sicurezza documentate.

Una buona regola pratica è partire da tre domande. Di chi mi fido più del mio provider Internet? Quali controlli voglio applicare alle query DNS? Quali problemi sono disposto ad accettare in cambio di più privacy o più filtraggio? La risposta cambia da casa a ufficio, da smartphone a router, da utente singolo a rete aziendale. Il DNS resolver perfetto non esiste. Esiste una configurazione ragionata, misurata e coerente con ciò che si vuole proteggere.