Quando si ha a che fare con i DNS, specie con i server di risoluzione che non sono direttamente sotto il nostro controllo, alcune informazioni in più oltre a risolvere il nome in un indirizzo IP o viceversa, sono molto utili.
Nelle maggiori distribuzioni Linux è presente un comando non molto noto, si chiama DIG che tradotto dall’inglese significa scavare. Infatti questo tool a linea di comando scava all’interno delle richieste dns e ci prospetta interessanti dati tecnici.
Ad esempio con il comando in questione, seguita dall’opzione -t possiamo verificare oltre allo stato del dns quanto manca alla scadenza del TTL. Utile ad esempio quando abbiamo effettuato un cambio su un DNS remoto, e vogliamo capire quando nella nostra subnet aziendale (che magari usa un altro DNS con informazioni già presenti in cache) otterremo il ricambio delle informazioni. Qui sotto un esempio
dig -t mx tosolini.info
; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> -t mx tosolini.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41229
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 11
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;tosolini.info. IN MX
;; ANSWER SECTION:
tosolini.info. 86388 IN MX 40 aspmx2.googlemail.com.
tosolini.info. 86388 IN MX 50 aspmx3.googlemail.com.
tosolini.info. 86388 IN MX 20 alt1.aspmx.l.google.com.
tosolini.info. 86388 IN MX 10 aspmx.l.google.com.
tosolini.info. 86388 IN MX 30 alt2.aspmx.l.google.com.
;; ADDITIONAL SECTION:
aspmx2.googlemail.com. 286 IN A 74.125.143.27
aspmx2.googlemail.com. 286 IN AAAA 2a00:1450:4010:c03::1b
aspmx3.googlemail.com. 286 IN A 74.125.68.27
aspmx3.googlemail.com. 286 IN AAAA 2404:6800:4003:c02::1b
alt1.aspmx.l.google.com. 286 IN A 74.125.143.27
alt1.aspmx.l.google.com. 286 IN AAAA 2a00:1450:4010:c03::1b
aspmx.l.google.com. 286 IN A 173.194.67.27
aspmx.l.google.com. 286 IN AAAA 2a00:1450:400c:c05::1b
alt2.aspmx.l.google.com. 286 IN A 74.125.68.27
alt2.aspmx.l.google.com. 286 IN AAAA 2404:6800:4003:c02::1b
;; Query time: 1 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed Jul 08 16:05:04 CEST 2015
;; MSG SIZE rcvd: 395
In particolare nella Answer Section vediamo che mancano 86388 secondi ad una nuova richiesta.
Tutte le sezioni che vediamo qui sopra si possono ignorare con specifiche opzioni:
- +nocomments – non mostra i commenti
- +noauthority – non mostra la parte autoritativa
- +noadditional – non mostra di dati addizionali
- +nostats – non mostra le statistiche
- +noanswer – non mostra i dati di risposta, ad esempio le tempistiche
dig tosolini.info +nocomments +noquestion +noauthority +noadditional +nostats
Nell’esempio abbiamo visto che abbiamo chiesto la query dei server MX relativi alla posta, ma possiamo chiedere la stessa cosa per i server NS, TXT oppure ANY che significa tutte le informazioni che il server DNS sarà in grado di dare.
Abbiamo anche visto che con -t si ottiene il timing rimanente alla prossima richiesta per quello specifico parametro (MX in questo caso).
Con il comando -x invece otteniamo la risoluzione inversa partendo da un Indirizzo IP, ovvero l’equivalente dell’nslookup.
dig -x 216.58.210.195 +short
Ci ritornerà google.it. Con l’opzione +short, come si può intuire, tende ad essere meno verboso nelle risposte fornite.
Se necessitiamo di fare query multiple su molti nomi a domino è possibile fare un file di testo dove metteremo un target per ogni riga ed utilizzando l’opzione -f che richiede il nome del file con l’elenco.
vi domain.txt
google.it
google.com
e passarlo a dig
dig -f domain.txt
Interessante fra le opzioni, quella di dichiarare un server DNS di riferimento specifico, ovvero che sia diverso da quello che stiamo utilizzando. Infatti DIG utilizza per default quello dichiarato nel nostro sistema operativo, ma se vogliamo conoscere le informazioni contenute in un DNS server diverso dobbiamo dare il comando:
dig @dns-server-remoto tosolini.info
Il dns server remoto può essere come indirizzo IP o nome di dominio.
Ugualmente interessante l’opzione +trace che similarmente a un tracepath o traceroute, andrà mostrare tutta la sequela di richieste fino ad arrivare al server autoritativo per il nome ricercato. Quindi per un punto com partirà proprio da i server responsabili per il primo livello fino ad arrivare al dns primario dove è registrato il dominio. Davvero utile come troubleshooting in caso di attacco dovuto ad un dns cache poisoning.
Le opzioni non finisco qui e sono tantissime, vi invito a guardare il MAN page e scoprire questo tool sistemistico davvero prezioso.