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.
+nssearch?+nssearcheffectue uneNSrecherche d'enregistrement sur votre résolveur local pour l'enregistrement demandé, suivie d'une série deA/AAAArecherches sur le résolveur local pour chacun des serveurs de noms renvoyés. Il est également susceptible de faux enregistrements de serveurs de noms dans le cache.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:
la source
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:
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
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.10Notez 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 ms496 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.
la source