dig +trace fonctionne en prétendant qu'il s'agit d'un serveur de noms et en descendant dans l'arborescence de l'espace de noms à l'aide de requêtes itératives commençant à la racine de l'arborescence, en suivant les références en cours de route.
La première chose qu'il fait est de demander au serveur DNS du système normal des enregistrements NS pour "."
Après avoir obtenu une réponse, qui sera la liste actuelle des serveurs de noms racine, il en choisira un puis demandera l'enregistrement A pour ce nom s'il ne l'a pas obtenu dans la section des enregistrements supplémentaires la première fois, donc il a une adresse IP à laquelle envoyer la prochaine requête. Disons qu'il choisit f.root-servers.net dont l'adresse IP est 192.5.5.241.
À ce stade, utilisons dig +trace www.google.co.uk.notre commande avec un nom de domaine pour lequel nous voulons tracer le chemin de résolution.
La prochaine requête en arrière-plan sera la suivante:
$ 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, alors maintenant nous savons qu'il existe des serveurs de noms uket c'est la seule chose que le serveur racine connaît. Ceci est une référence , car nous n'avons pas demandé de récursivité (la +norecursedésactive).
Génial, nous rincons et répétons. Cette fois, nous choisissons l'un des ukserveurs de noms et lui posons la même question .
$ 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
Génial, maintenant nous avons découvert que le ukserveur de noms de niveau supérieur sait qu'il y a une zone appelée google.co.uket nous dit d'aller poser cette question à ces serveurs de noms. Ceci est un autre renvoi.
Rincez, répétez.
Cette fois, cependant, nous n'avons pas obtenu d'enregistrements A dans la section des enregistrements supplémentaires de la réponse, nous en choisissons donc un, par exemple ns2.google.com, et nous devons rechercher son adresse. Nous redémarrons une requête (à la racine à nouveau) et poursuivons l'arborescence pour trouver l'adresse IP de ns2.google.com. Je vais sauter cette partie par souci de concision, mais nous apprenons que l'IP correspondant est 216.239.34.10.
Notre prochaine requête est donc:
$ 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
Et nous avons terminé! (enfin) Comment savons-nous que nous avons fini? Nous avons obtenu une réponse à notre requête, à savoir les enregistrements A pour www.google.co.uk. Vous pouvez également le dire car ce n'est plus une référence, le aabit est défini dans la dernière réponse, ce qui signifie que c'est la réponse faisant autorité pour votre requête.
C'est donc ce qui se passe à chaque étape de votre utilisation dig +trace.
Notez que si vous avez une version de dig prise en charge par DNSSEC et que vous ajoutez +dnssecà la commande, vous pouvez voir un tas d'autres enregistrements. Quels sont ces enregistrements supplémentaires est laissé comme un exercice pour le lecteur ... mais explique comment cela dig +sigchasefonctionne.