Comment fonctionne dig + trace?

Lorsque je regarde la page de manuel pour creuser, j'obtiens ce qui suit:

+[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 cela fonctionne-t-il dans la pratique? Quelle serait la série équivalente de digcommandes (sans + trace) qui serait fonctionnellement équivalente?

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.

Disons que vous cherchiez

www.domain.co.uk

DNS est une hiérarchie, à commencer par les serveurs racine qui savent quels serveurs font autorité pour les TLD (la dernière partie du nom de domaine). Donc, l'équivilent à

dig subdomain.domain.co.uk

Etape par étape serait:

dig SOA @g.root-servers.net uk

(c'est-à-dire, interrogez l'un des serveurs racine pour trouver 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 SOA (autorité) est sur les mêmes serveurs

Permet donc d'interroger ns1.nic.uk pour voir qui a domain.co.uk

dig SOA @ns1.nic.uk domain.co.uk

Cela revient et dit que l'autorité pour le domaine est à 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