dig +trace funziona fingendo di essere un server dei nomi e funziona lungo l'albero dello spazio dei nomi utilizzando query iterative che iniziano dalla radice dell'albero, seguendo i riferimenti lungo il percorso.
La prima cosa da fare è chiedere al normale server DNS di sistema i record NS per "."
Dopo aver ottenuto una risposta, che sarà l'elenco corrente dei server dei nomi di root, ne sceglierà uno e quindi chiederà il record A per quel nome se non lo ha ottenuto nella sezione dei record aggiuntivi la prima volta, quindi ha ottenuto un indirizzo IP a cui inviare la query successiva. Diciamo che sceglie f.root-servers.net il cui indirizzo IP è 192.5.5.241.
A questo punto, usiamo dig +trace www.google.co.uk.come nostro comando con un nome di dominio per cui vogliamo tracciare il percorso di risoluzione.
La prossima query dietro le quinte sarà questa:
$ dig +norecurse @192.5.5.241 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @192.5.5.241 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8962
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 15
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; AUTHORITY SECTION:
uk. 172800 IN NS ns5.nic.uk.
uk. 172800 IN NS ns6.nic.uk.
uk. 172800 IN NS ns4.nic.uk.
uk. 172800 IN NS nsc.nic.uk.
uk. 172800 IN NS ns2.nic.uk.
uk. 172800 IN NS ns3.nic.uk.
uk. 172800 IN NS nsd.nic.uk.
uk. 172800 IN NS nsa.nic.uk.
uk. 172800 IN NS ns7.nic.uk.
uk. 172800 IN NS nsb.nic.uk.
uk. 172800 IN NS ns1.nic.uk.
;; ADDITIONAL SECTION:
ns1.nic.uk. 172800 IN A 195.66.240.130
ns2.nic.uk. 172800 IN A 217.79.164.131
ns3.nic.uk. 172800 IN A 213.219.13.131
ns4.nic.uk. 172800 IN A 194.83.244.131
ns5.nic.uk. 172800 IN A 213.246.167.131
ns6.nic.uk. 172800 IN A 213.248.254.130
ns7.nic.uk. 172800 IN A 212.121.40.130
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
nsc.nic.uk. 172800 IN A 156.154.102.3
nsd.nic.uk. 172800 IN A 156.154.103.3
ns1.nic.uk. 172800 IN AAAA 2a01:40:1001:35::2
ns4.nic.uk. 172800 IN AAAA 2001:630:181:35::83
nsa.nic.uk. 172800 IN AAAA 2001:502:ad09::3
;; Query time: 45 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Tue Feb 11 19:19:14 MST 2014
;; MSG SIZE rcvd: 507
Wow, quindi ora sappiamo che ci sono nameserver per uke questa è l'unica cosa che il root server conosce. Questo è un rinvio , perché non abbiamo chiesto la ricorsione ( +norecursela disattiva).
Ottimo, risciacquiamo e ripetiamo. Questa volta scegliamo uno dei uknameserver e facciamo la stessa domanda .
$ dig +norecurse @195.66.240.130 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @195.66.240.130 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 618
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; AUTHORITY SECTION:
google.co.uk. 172800 IN NS ns1.google.com.
google.co.uk. 172800 IN NS ns3.google.com.
google.co.uk. 172800 IN NS ns2.google.com.
google.co.uk. 172800 IN NS ns4.google.com.
;; Query time: 354 msec
;; SERVER: 195.66.240.130#53(195.66.240.130)
;; WHEN: Tue Feb 11 19:22:47 MST 2014
;; MSG SIZE rcvd: 127
Fantastico, ora abbiamo scoperto che il uknameserver di livello superiore sa che c'è una zona chiamata google.co.uke ci dice di andare a fare la nostra domanda a quei nameserver. Questo è un altro riferimento.
Risciacqua, ripeti.
Questa volta, tuttavia, non abbiamo ottenuto i record A nella sezione dei record aggiuntivi della risposta, quindi scegliamo uno, diciamo ns2.google.com, e dobbiamo andare a trovare il suo indirizzo. Abbiamo Ripartiamo una query (alla radice di nuovo) e inseguire l'albero per trovare l'indirizzo IP per ns2.google.com. Salterò quella parte per brevità, ma apprendiamo che l'IP per esso è 216.239.34.10.
Quindi la nostra prossima query è:
$ dig +norecurse @216.239.34.10 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @216.239.34.10 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33404
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; ANSWER SECTION:
www.google.co.uk. 300 IN A 74.125.225.216
www.google.co.uk. 300 IN A 74.125.225.223
www.google.co.uk. 300 IN A 74.125.225.215
;; Query time: 207 msec
;; SERVER: 216.239.34.10#53(216.239.34.10)
;; WHEN: Tue Feb 11 19:26:43 MST 2014
;; MSG SIZE rcvd: 82
E abbiamo finito! (finalmente) Come facciamo a sapere che abbiamo finito? Abbiamo ricevuto una risposta alla nostra domanda, che era il record A per www.google.co.uk. Puoi anche dirlo perché non è più un riferimento, il aabit è impostato nell'ultima risposta, il che significa che questa è la risposta autorevole per la tua query.
Quindi è quello che sta succedendo ad ogni passo lungo la strada quando lo usi dig +trace.
Si noti che se si dispone di una versione di dig compatibile con DNSSEC e si aggiunge +dnssecal comando, è possibile che vengano visualizzati più record. Ciò che quei record extra sono lasciati come esercizio per il lettore ... ma entra nel modo in cui dig +sigchasefunziona.