Comment fonctionne réellement Dig + trace?
Lorsque je regarde la page de manuel de Dig, je reçois le texte suivant:
+[no]trace
Toggle tracing of the delegation path from the root name servers for the name
being looked up. Tracing is disabled by default. When tracing is enabled, Dig
makes iterative queries to resolve the name being looked up. It will follow
referrals from the root servers, showing the answer from each server that was
used to resolve the lookup.
Alors, comment ça marche, en pratique? Quelle serait la série équivalente de commandes Dig (sans + trace) qui serait fonctionnellement équivalente?
Dig +trace fonctionne en prétendant que c'est 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 renvois en cours de route.
La première chose à faire est de demander au serveur DNS normal du système pour NS enregistrements pour "."
Après avoir reçu 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 reçu dans la section des enregistrements supplémentaires la première fois. une adresse IP à laquelle envoyer la requête suivante. 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. comme commande avec un nom de domaine pour lequel nous souhaitons tracer le chemin de résolution.
La prochaine requête en coulisse 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, nous savons maintenant qu'il existe des serveurs de noms pour uk et c'est la seule chose que le serveur racine connaisse. Ceci est une référence , car nous n'avons pas demandé de récursivité (+norecurse le désactive).
Génial, on rince et répète. Cette fois, nous choisissons l’un des serveurs de noms uk 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, nous avons découvert que le serveur de noms uk de premier niveau savait qu'il existe une zone appelée google.co.uk et nous demandait d'aller poser notre question à ces serveurs de noms. Ceci est une autre référence.
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 avons donc choisi un, disons ns2.google.com, et nous devons aller chercher son adresse. Nous relançons une requête (à la racine à nouveau) et poursuivons l'arborescence pour rechercher l'adresse IP de ns2.google.com. Je vais sauter cette partie pour plus de brièveté, mais nous apprenons que l'adresse IP utilisée 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 fini! (enfin) Comment savons-nous que nous avons fini? Nous avons reçu une réponse à notre requête, à savoir les enregistrements A pour www.google.co.uk. Vous pouvez également savoir, car ce n’est plus une référence, le bit aa est défini dans la dernière réponse, ce qui signifie qu’il s’agit de la réponse faisant autorité pour votre requête.
C'est donc ce qui se passe à chaque étape du processus lorsque vous utilisez Dig +trace.
Notez que si vous avez une version de Dig compatible avec DNSSEC et que vous ajoutez +dnssec à la commande, vous risquez de voir apparaître plusieurs enregistrements. Ce que sont ces enregistrements supplémentaires reste un exercice pour le lecteur ... mais nous expliquons comment fonctionne Dig +sigchase.
Disons que vous leviez les yeux
www.domain.co.uk
Le DNS est une hiérarchie, commençant par les serveurs racine qui savent quels serveurs font autorité pour les TLD (la dernière partie du nom de domaine). Donc l'équivalent de
Dig subdomain.domain.co.uk
Pas à pas serait:
Dig SOA @g.root-servers.net uk
(c.-à-d. interrogez l'un des serveurs racine pour savoir qui fait autorité pour .uk)
Cela répond avec une série de serveurs britanniques faisant autorité, nous leur demandons donc qui a co.uk
Dig SOA @ns6.nic.uk co.uk
Et on nous dit que la SOA (autorité) se trouve sur les mêmes serveurs
Laisse donc la requête ns1.nic.uk pour voir qui a domain.co.uk
Dig SOA @ns1.nic.uk domain.co.uk
Cela revient et indique que l'autorité du domaine est située à l'adresse dns.dns1.de (plus les sauvegardes);
Alors maintenant, nous pouvons demander l'enregistrement A:
Dig A @dns.dns2.de www.domain.co.uk
;; QUESTION SECTION:
;www.domain.co.uk. IN A
;; ANSWER SECTION:
www.domain.co.uk. 86400 IN CNAME domain.co.uk.
domain.co.uk. 86400 IN A 95.130.17.36