Dig + trace est-il toujours précis?

Lorsque la précision d'un cache DNS est remise en question, il est dig +tracegénéralement recommandé de déterminer la réponse faisant autorité pour un enregistrement DNS accessible sur Internet. Cela semble être particulièrement utile lorsqu'il est également associé à +additional, ce qui montre également les enregistrements de colle.

Parfois, il semble y avoir un désaccord sur ce point - certaines personnes disent qu'il s'appuie sur le résolveur local pour rechercher les adresses IP des serveurs de noms intermédiaires, mais la sortie de la commande n'indique pas que cela se produit au-delà de la liste initiale de racine serveurs de noms. Il semble logique de supposer que ce ne serait pas le cas si le but de +traceest de démarrer sur les serveurs racine et de remonter votre chemin. (au moins si vous avez la bonne liste de serveurs de noms racine)

Utilise dig +tracevraiment le résolveur local pour quoi que ce soit après les serveurs de noms racine?

C'est évidemment une Q&A mise en scène, mais cela a tendance à dérouter souvent les gens et je ne trouve pas de question canonique couvrant le sujet.

dig +traceest un excellent outil de diagnostic, mais un aspect de sa conception est largement mal compris: l'IP de chaque serveur qui sera interrogé est obtenue à partir de votre bibliothèque de résolveurs . Ceci est très facilement ignoré et finit souvent par devenir un problème lorsque votre cache local a la mauvaise réponse pour un serveur de noms mis en cache.

Analyse détaillée

C'est plus facile à décomposer avec un échantillon de la sortie; Je vais tout omettre après la première délégation NS.

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms

• La requête initiale pour . IN NS(serveurs de noms racine) atteint le résolveur local, qui dans ce cas est Comcast. ( 75.75.75.75) C'est facile à repérer.
• La requête suivante est pour serverfault.com. IN Aet s'exécute contre e.root-servers.net., sélectionnée au hasard dans la liste des serveurs de noms racine que nous venons de recevoir. Il a une adresse IP de 192.203.230.10, et puisque nous l'avons +additionalactivé, il semble provenir de la colle.
• Comme il ne fait pas autorité pour serverfault.com, cela est délégué aux com.serveurs de noms TLD.
• Ce qui n'est pas évident à partir de la sortie ici, c'est que dign'a pas dérivé l'adresse IP e.root-servers.net.de la colle.

En arrière-plan, c'est ce qui s'est réellement passé:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

+tracea triché et consulté le résolveur local pour obtenir l'adresse IP du serveur de noms de saut suivant au lieu de consulter la colle. Sournois!

Ceci est généralement «assez bon» et ne causera pas de problème à la plupart des gens. Malheureusement, il existe des cas marginaux. Si, pour une raison quelconque, votre cache DNS en amont fournit la mauvaise réponse pour le serveur de noms, ce modèle tombe complètement en panne.

Exemple du monde réel:

• le domaine expire
• la colle est repointée sur les serveurs de noms de redirection de bureau d'enregistrement
• les fausses adresses IP sont mises en cache pour ns1 et ns2.votredomaine.com
• le domaine est renouvelé avec de la colle restaurée
• tous les caches avec les adresses IP du serveur de noms bidon continuent d'envoyer des personnes vers un site Web qui dit que le domaine est à vendre

Dans le cas ci-dessus, +tracecela suggérera que les propres serveurs de noms du propriétaire du domaine sont la source du problème, et vous êtes à un appel de dire incorrectement à un client que ses serveurs sont mal configurés. Que ce soit quelque chose que vous pouvez (ou êtes disposé à faire) quelque chose est une autre histoire, mais il est important d'avoir les bonnes informations.

dig +trace est un excellent outil, mais comme tout outil, vous devez savoir ce qu'il fait et ne fait pas, et comment résoudre le problème manuellement lorsqu'il s'avère insuffisant.

Modifier:

Il convient également de noter que dig +tracene vous avertira pas des NSenregistrements qui pointent vers des CNAMEalias. Il s'agit d'une violation RFC que ISC BIND (et éventuellement d'autres) ne tentera pas de corriger. +tracesera complètement heureux d'accepter l' Aenregistrement qu'il obtient de votre serveur de noms configuré localement, alors que si BIND devait effectuer une récursivité complète, il rejetterait la zone entière avec un SERVFAIL.

Cela peut être difficile à dépanner si de la colle est présente; cela fonctionnera très bien jusqu'à ce que les enregistrements NS soient rafraîchis , puis brisera soudainement. Les délégations sans colle briseront toujours la récursivité de BIND lorsqu'un NSenregistrement pointe vers un alias.

Une autre façon de suivre la résolution DNS sans utiliser le résolveur local pour autre chose que pour trouver les serveurs de noms racine, utilise dnsgraph (Divulgation complète: j'ai écrit ceci). Il dispose d'un outil en ligne de commande et d'une version Web, dont vous pouvez trouver une instance sur http://ip.seveas.net/dnsgraph/

Exemple pour serverfault.com, qui a actuellement un problème DNS:

Très tard dans ce fil, mais je pense que la partie de la question de savoir pourquoi une dig + trace utilise des requêtes récursives pour les résolveurs locaux n'a pas été directement expliquée, et cette explication est pertinente pour la précision des résultats de dig + trace.

Après la requête récursive initiale pour les enregistrements NS de la zone racine, puis creuser peut émettre des requêtes ultérieures aux résolveurs locaux dans les conditions suivantes:

1. une réponse de référence est tronquée en raison de la taille de la réponse dépassant 512 octets pour la prochaine requête itérative

2. dig sélectionne un enregistrement NS dans la section AUTHORITY de la réponse de renvoi pour laquelle l'enregistrement A correspondant (colle) est manquant dans la section ADDITIONAL

Parce que dig n'a qu'un nom de domaine de l'enregistrement NS, dig doit résoudre le nom en une adresse IP en interrogeant le serveur DNS local. Ceci est la cause profonde (jeu de mots voulu, désolé).

AndrewB a un exemple qui ne correspond pas entièrement à ce que je viens de décrire, en ce que l'enregistrement NS de la zone racine choisi:

. 121459 IN NS e.root-servers.net.

a un enregistrement A correspondant:

e.root-servers.net. 354907 IN A 192.203.230.10

Notez cependant qu'il n'y a pas d'enregistrement AAAA correspondant pour e-root, ni d'enregistrement AAAA pour certains autres serveurs racine.

Notez également la taille de la réponse:

;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

496 octets est une taille courante pour les réponses qui ont été tronquées (c.-à-d. Que le prochain enregistrement de colle aurait été> 16 octets, plaçant la réponse sur 512 octets). En d'autres termes, dans une requête pour les enregistrements NS de root, une AUTHORITY complète et un ADDITIONAL complet (enregistrements A et AAAA) dépasseront 512 octets, donc toute requête basée sur UDP qui ne spécifie pas une taille de requête plus grande via les options EDNS0 sera obtenez une réponse qui est coupée quelque part dans la section ADDITIONNELLE, comme le montre la trace ci-dessus (seuls f, h, i, j et k ont ​​des enregistrements de colle A et AAAA).

L'absence d'enregistrement AAAA pour e.root-servers.net et la taille de la réponse à la "NS". suggère fortement que la prochaine requête récursive a été effectuée pour la raison que je réclame. Peut-être que le système d'exploitation client est compatible IPv6 et préfère les enregistrements AAAA - ou pour toute autre raison.

Mais en tout cas, après avoir lu ce fil, j'ai étudié le phénomène de dig + trace effectuant des requêtes récursives après la première pour root. D'après mon expérience, la correspondance entre la sélection d'un enregistrement NS sans enregistrement A / AAAA de colle correspondant et la fouille, puis l'envoi d'une requête récursive pour cet enregistrement au DNS local est de 100%. Et l'inverse est vrai - je n'ai pas vu de requêtes récursives lorsque l'enregistrement NS sélectionné dans la référence a un enregistrement de colle correspondant.