«Qual è il DNS migliore per la mia zona» è una delle ricerche che porta più lettori su questo sito, e la risposta onesta è che nessuno può dartela dall’esterno. Quello che possiamo fare è spiegarti perché e mostrarti come misurarlo da solo in due minuti.
Perché non c’è una risposta valida per tutti
Cloudflare, Google, Quad9 e gli altri grandi resolver funzionano in anycast: lo stesso indirizzo, per esempio 1.1.1.1, viene annunciato da centinaia di nodi nel mondo, e la tua richiesta arriva a quello che la rete del tuo operatore considera più vicino. «Più vicino» in termini di instradamento, non di chilometri. Due vicini di casa con operatori diversi possono parlare con nodi diversi, uno a 6 ms e l’altro a 40.
A questo si aggiunge la cache. Se il dominio che chiedi è stato risolto poco prima su quello stesso nodo, la risposta arriva subito. Altrimenti il resolver deve percorrere tutta la catena fino al server autoritativo, e lì conta più la qualità della rete del provider che la distanza. Per questo una buona misurazione separa le due cose: richieste in cache e richieste «a freddo».
Come misurare dalla tua connessione
L’opzione rapida è il test di velocità DNS. Fa cinque giri di richieste a sette resolver dal browser, con nomi casuali perché nessuno possa rispondere dalla cache, e li ordina per latenza media. Non installa niente e non salva niente.
Due consigli perché il risultato serva davvero:
- Fallo dalla rete che usi sul serio, non dal telefono in rete mobile se quello che vuoi configurare è il router di casa.
- Ripetilo a un’altra ora. Le reti degli operatori si congestionano di sera e l’ordine può cambiare.
Se preferisci il terminale, dig ti dà la stessa informazione senza intermediari:
dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"
dig @9.9.9.9 example.com | grep "Query time"
La prima richiesta a ogni resolver di solito richiede più tempo perché riempie la cache; ripeti ogni riga due o tre volte e tieni il valore stabile. Su Windows nslookup non mostra i tempi; usa il test del browser o Measure-Command in PowerShell.
Quali numeri sono buoni
- Meno di 20 ms: eccellente. È quello che vedi quando il resolver ha un nodo nella tua città o in quella accanto.
- Da 20 a 50 ms: perfettamente normale. Navigando non noti differenza rispetto alla fascia sopra.
- Da 50 a 100 ms: accettabile, ma comincia a farsi sentire nelle pagine che caricano risorse da molti domini.
- Più di 100 ms: quasi certamente ce n’è uno migliore per te.
E un numero che conta più della latenza: le perdite. Un resolver che risponde in 8 ms ma non risponde al 10% delle richieste è peggio di uno a 25 ms che risponde sempre, perché ogni richiesta persa è un secondo o due di attesa finché il sistema riprova. Nella nostra misurazione da Madrid, DNS.WATCH perdeva il 77% delle richieste e Comodo il 42%; nessuno dei due è un’opzione, per quanto veloce risponda quando risponde.
Cosa abbiamo misurato da Madrid, come esempio
Con la risposta in cache, Quad9 ha risposto in 5 ms e Cloudflare, CleanBrowsing, DNS4EU e xdp.es in 6, tutti dalla rete di Telefónica. Google in 7. A freddo, forzando la risoluzione completa, Cloudflare è sceso a 22 ms e gli altri si sono mossi tra 30 e 35, tranne i resolver piccoli o con filtri pesanti, che hanno superato i 100.
Quella tabella descrive una rete precisa in un giorno preciso. Se sei a Madrid con Telefónica ti servirà; se sei a Milano, Roma o Palermo, ti serve solo come riferimento di cosa sia un buon numero.
Cosa cambia da una regione all’altra
Italia ed Europa. I grandi hanno nodi a Milano e in quasi tutte le capitali, e le differenze tra loro sono di pochi millisecondi. DNS4EU è il resolver pubblico europeo e dalla Spagna risponde veloce quanto Cloudflare. Tra un operatore e l’altro il risultato può cambiare parecchio, soprattutto fuori dalle grandi città.
Medio Oriente e Nord Africa. È da lì che ci arriva più spesso questa domanda, e a ragione: la copertura dei nodi varia molto da paese a paese, e gli accordi di peering di ogni operatore cambiano il risultato anche dentro la stessa città. Qui misurare non è un consiglio, è l’unica strada.
America Latina. Simile: nodi nelle grandi capitali e molta variazione tra operatori. Spesso Cloudflare arriva primo, ma non dare nulla per scontato.
Russia e Asia. I resolver locali (Yandex DNS in Russia, AliDNS in Cina) di solito battono quelli occidentali in latenza per pura vicinanza di rete. Il test include AliDNS perché il confronto sia equo da lì.
Una trappola frequente: l’operatore intercetta il DNS
Se nel test tutti i resolver danno quasi lo stesso tempo e gli stessi risultati, insospettisciti. Alcuni operatori intercettano il traffico DNS sulla porta 53 e rispondono loro, qualunque indirizzo tu abbia impostato. Non stai misurando Cloudflare, stai misurando il tuo operatore con l’indirizzo di Cloudflare scritto nel campo.
Il test del browser usa DNS su HTTPS, che non si può intercettare in quel modo, quindi i suoi numeri sono quelli del resolver vero. Se ti capita, configurare DoH o DoT sul sistema è il modo per far sì che il DNS che scegli sia quello che ti serve davvero.
Primario e secondario
Una volta scoperto il più veloce, mettilo come primario. Il secondario si usa solo quando il primario non risponde: non è un bilanciamento, quindi combinare «il più veloce e il più sicuro» sperando nel meglio di entrambi serve a poco. Metti due dello stesso provider, oppure il più veloce e il secondo più veloce. Le guide di configurazione spiegano dove va ciascuno su Windows, macOS, Android, iOS e router.