Dig e il DNS Response Time: come verificare che i server OpenDNS rispondono più lentamente alle query DNS rispetto a quelli italiani di Alice di Telecom Italia

Sinora ho parlato spesso dei DNS e in particolare degli OpenDNS (un servizio che offre liberamente i propri DNS per uso pubblico), sia quando i server DNS di Telecom Italia furono messi in ginocchio, sia per l’annuncio di una vulnerabilità insita nel protocollo DNS stesso che potrebbe permettere ad un malintenzionato, tramite il DNS Cache Poising, di controllare il traffico internet e fare del Pishing (per controllare se i vostri DNS sono sicuri, potete verificare sul completo e chiaro dns-oarc.net o sul più sintetico doxpara.com), sia, per finire, per i test di velocità che feci tra i server DNS di Alice Telecom Italia e quelli OpenDNS in cui i primi risultarono, al ping, molto più veloci dei secondi.
Ed è proprio a proposito di quest’ultimo articolo che vorrei riprendere e, al contempo, ampliare, l’argomento della velocità dei server DNS, stimolato anche da un commento di un mio lettore nel suddetto articolo, che asserisce:

ICMP non è UDP (o TCP). Può darsi comunque che i server OpenDNS siano più veloci alle query DNS anche se sono più lenti al ping.

In effetti le sue affermazioni sono teoricamente ineccepibili, anche se, a parer mio, poco probabili. Infatti le mie analisi partivano dal presupposto che non vi esistessero filtri tra i vari protocolli usati. Per fugare ogni dubbio, ho deciso quindi di rendere più precise le mie valutazioni, misurando anche quanto impiegano i server DNS a rispondere alle query.

Ma prima di partire con queste analisi, è necessario rispolverare un po’ di teoria sul DNS.

Un po’ di teoria sul DNS

Il DNS (Domain Name Service) è un servizio che permette di tradurre nomi di dominio come www.levysoft.it in indirizzi IP come 64.57.102.34 (grazie ad un database distribuito di servers DNS). Infatti, i computer non sono in grado di instradare i pacchetti verso un nome di dominio ma solo verso il corrispondente indirizzo IP. L’adozione del DNS, quindi, ha il solo scopo di semplificare la vita a noi esseri umani, in quanto risulta molto più facile ricordare una stringa testuale mnemonica piuttosto che un anonimo indirizzo IP.
Se, quindi, assegnare nomi ai computer rende la memorizzazione molto più semplice, è evidente che a questo punto è necessario uno strumento, come quello del DNS, in grado di associare automaticamente i nomi agli indirizzi IP.

Per risolvere l’indirizzo IP esistono diversi comandi:

1. host: viene usato per associare nomi ad indirizzi IP. È una utility, per Linux e Mac OS X, molto rapida e semplice, con poche funzioni:
   host levysoft.it

   levysoft.it has address 69.71.248.10
   levysoft.it mail is handled by 0 levysoft.it.
   

   host è considerato insieme a dig il sostituto ufficiale di nslookup.

2. nslookup: (Name Server Lookup) è uno strumento consolidato presente in tutti i sistemi operativi che utilizzano il protocollo TCP/IP (Gnu/Linux, Unix, MAC OS X, Windows) ma che, essendo superato, potrebbe anche essere rimosso in molte future versioni delle distribuzioni Linux.
   Nslookup consente di effettuare delle query (richieste) ad un server DNS per la risoluzione di indirizzi IP o Hostname, per poter ottenere da un dominio il relativo indirizzo IP o nome host e viceversa.

   
nslookup levysoft.it

   Non-authoritative answer:
   Name: levysoft.it
   Address: 69.71.248.10
   

   Nonostante sia considerato obsoleto, in quanto è stato uno dei primi tool in grado di lavorare con il DNS, nslookup è un comando ancora molto potente. Per esempio, con due soli comandi, whois e nslookup, è possibile scovare i DNS Pubblici di un provider. Il primo serve a determinare chi ha registrato il nome di dominio, mentre il secondo interroga i DNS per risolvere l’indirizzo IP del server.

3. dig: (Domain Information Groper) è il comando più potente per recuperare informazioni relative al Domain Name Server indicato, inclusi reverse lookup, A, CNAME, MX, SP e record TXT. Dig è molto usato sia per la sua grande flessibilità che per i suoi output molto chiari. Contrariamente a nslookup, dig non contempla una modalità interattiva, ma è disponibile solamente in modalità non interattiva o batch che permette di fargli leggere le richieste da un file.
   Dig ha una tale infinità di opzioni (tanto che da molti viene considerato l’alternativa più verbosa e completa a nslookup), che nella sua pagina di manuale gli sviluppatori fanno dell’ironia su questo fatto tanto che, sotto la voce BUGS, si trova “There are probably too many query options“.

   La sua sintassi è la seguente:

   dig [@nameserver] [opzioni] [nome_risorsa] [tipo_di_richiesta] [ulteriori_opzioni])

   ma, di norma, si utilizza nel modo seguente:

   dig @server name type

   Se non specificato, dig utilizza come server per le richieste quello presente in /etc/resolv.conf.

   Dig, il cui nome deriva dal verbo inglese to dig (scavare, scoprire o investigare), è una utility presente in qualsiasi sistema operativo all’interno del quale è installato l’ambiente DNS BIND; pertanto essa è disponibile nativamente in ambiente Linux/Unix e Mac OS X, mentre è assente su Windows.
   Se volete usarlo anche sui sistemi Windows, allora dovrete scaricarvi la versione compilata per Windows, DIG, che permette la restituzione dei record DNS per un dominio specifico anche sulla piattaforma di casa Microsoft.

Calcolare il time response delle query DNS

Ora che abbiamo superato la parte più noiosa della teoria, passiamo alla pratica, basandosi sempre sui primi test di velocità effettuati con il classico ping che misurava il tempo, espresso in millisecondi, impiegato da uno o più pacchetti ICMP di echo request a raggiungere un server DNS.

Questa volta, però, sfruttando il potente comando DIG, ho inviato delle query dirette ai server DNS e calcolato il DNS Response Time, ovvero il tempo che il server impiegava a risolvere un nome di dominio che gli veniva passato. Questo valore ovviamente è direttamente proporzionale alla distanza geografica del server (come per il ping) e alla velocità di elaborazione del server, teoricamente molto bassa e che a sua volta dipende dal carico di sistema. In poche parole, con queste due componenti avremo la possibilità di effettuare test i più veritieri possibili, ponendosi proprio come se fosse il PC ad interrogare il server DNS.

In pratica, i comandi da lanciare dal proprio PC, per i vari server presi in esame saranno:

OpenDNS
dig http://www.levysoft.it @resolver1.opendns.com
;; Query time: 37 msec

DNS TIN
dig http://www.levysoft.it @212.216.112.112
;; Query time: 3 msec

Esistono, poi diversi tool online per calcolare il tempo di risposta di una query DNS. Tra questi, ne ho presi in esame 2 colocati all’estero: DIG: look up DNS domain IP address information e Dig DNS Check.

Ed ecco i risultati:

Ed ecco i risultati per i server OpenDNS:

Come vedete, i risultati sono molto simili a quelli ricavati con il PING ICMP. Qui in Italia, i tempi di risposta sono nettamente superiori per i server OpenDNS, a causa, appunto, della localizzazione geografica.
Discorso inverso, invece, si applica se la query viene lanciata da un server estero: gli OpenDns sono più veloci di quelli Alice.

Con questo articolo quindi ho dimostrato che le analisi effettuate con un PING ICMP assumono la stessa valenza statistica di quelle effettuate con i DNS Response Time delle query inviate direttamente al server DNS.

Ovviamente con questi test non voglio assolutamente affermare quale server DNS prediligere: i motivi per cui è vantaggioso scegliere gli OpenDNS sono innumerevoli, per cui sta a voi decidere cosa è meglio per il vostro sistema in base alle vostre esigenze ed aspettative.

Original article: Dig e il DNS Response Time: come verificare che i server OpenDNS rispondono più lentamente alle query DNS rispetto a quelli italiani di Alice di Telecom Italia

©2016 Levysoft. All Rights Reserved.