Dies ist offensichtlich ein inszeniertes Q & A, aber das verwirrt die Leute oft und ich kann keine kanonische Frage zum Thema finden.
dig +traceist ein großartiges Diagnosetool, aber ein Aspekt des Designs wird häufig missverstanden: Die IP-Adresse jedes Servers, der abgefragt wird, wird von Ihrer Resolver-Bibliothek abgerufen . Dies wird sehr leicht übersehen und wird oft erst dann zum Problem, wenn Ihr lokaler Cache die falsche Antwort für einen zwischengespeicherten Nameserver hat.
Detaillierte Analyse
Dies ist leichter mit einem Beispiel der Ausgabe zu zerlegen; Ich werde alles nach der ersten NS-Delegation weglassen.
; <<>> 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
- Die anfängliche Abfrage für
. IN NS(Root-Nameserver) trifft auf den lokalen Resolver, in diesem Fall auf Comcast. ( 75.75.75.75) Dies ist leicht zu erkennen.
- Die nächste Abfrage ist für
serverfault.com. IN Aund läuft gegen e.root-servers.net., zufällig ausgewählt aus der Liste der Root-Nameserver, die wir gerade erhalten haben. Es hat eine IP-Adresse von 192.203.230.10, und seitdem wir es +additionalaktiviert haben, scheint es vom Kleber zu kommen.
- Da es für serverfault.com nicht maßgeblich ist, wird es an die
com.TLD-Nameserver delegiert .
- Was aus der Ausgabe hier nicht ersichtlich ist, ist, dass
digdie IP-Adresse nicht e.root-servers.net.aus dem Klebstoff abgeleitet wurde.
Im Hintergrund ist Folgendes passiert:
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)
+tracebetrogen und konsultierte den lokalen Resolver, um die IP-Adresse des Nameservers des nächsten Hops zu erhalten, anstatt den Klebstoff zu konsultieren. Hinterhältig!
Dies ist in der Regel "gut genug" und wird für die meisten Menschen kein Problem darstellen. Leider gibt es Randfälle. Wenn Ihr DNS-Cache auf dem Upstream-Server aus irgendeinem Grund die falsche Antwort für den Nameserver liefert, bricht dieses Modell vollständig zusammen.
Beispiel aus der Praxis:
- Domain läuft ab
- Der Kleber wird bei Nameservern mit Registrar-Umleitung neu eingesetzt
- Schein-IPs werden für ns1 und ns2.yourdomain.com zwischengespeichert
- Domain wird mit restauriertem Leim erneuert
- Caches mit gefälschten Nameserver-IPs senden weiterhin Personen zu einer Website, auf der angegeben ist, dass die Domain zum Verkauf steht
In dem oben genannten Fall +tracewird darauf hingewiesen, dass die Nameserver des Domaininhabers die Ursache des Problems sind und Sie nur einen Anruf davon entfernt sind, einem Kunden fälschlicherweise mitzuteilen, dass seine Server falsch konfiguriert sind. Ob es etwas ist, gegen das Sie etwas tun können (oder wollen), ist eine andere Geschichte, aber es ist wichtig, die richtigen Informationen zu haben.
dig +trace ist ein großartiges Tool, aber wie bei jedem Tool müssen Sie wissen, was es tut und was nicht und wie Sie das Problem manuell beheben, wenn es sich als unzureichend herausstellt.
Bearbeiten:
Es sollte auch beachtet werden, dass Sie dig +tracenicht vor NSDatensätzen gewarnt werden , die auf CNAMEAliase verweisen . Dies ist eine RFC-Verletzung, die ISC BIND (und möglicherweise auch andere) nicht zu korrigieren versucht. Gerne nimmt BIND +traceden ADatensatz an, den es von Ihrem lokal konfigurierten Nameserver erhält, während BIND bei einer vollständigen Rekursion die gesamte Zone mit einem SERVFAIL ablehnt.
Dies kann schwierig sein, wenn Klebstoff vorhanden ist. Dies funktioniert einwandfrei, bis die NS-Datensätze aktualisiert sind , und bricht dann plötzlich ab. Leimlose Delegationen unterbrechen immer die Rekursion von BIND, wenn ein NSDatensatz auf einen Alias verweist.
+nssearch?+nssearchführtNSfür den angeforderten Datensatz eine Datensatzsuche für Ihren lokalen Resolver durch, gefolgt von einer Reihe vonA/AAAA-Suchen für den lokalen Resolver für jeden der zurückgegebenen Nameserver. Es ist ebenfalls anfällig für gefälschte Nameserver-Einträge im Cache.Eine andere Möglichkeit, die DNS-Auflösung zu verfolgen, ohne den lokalen Auflöser für etwas anderes als das Auffinden der Stammnamenserver zu verwenden , ist die Verwendung von dnsgraph (vollständige Offenlegung: Ich habe dies geschrieben). Es verfügt über ein Befehlszeilentool und eine Webversion, von der Sie eine Instanz unter http://ip.seveas.net/dnsgraph/ finden.
Beispiel für serverfault.com, bei dem aktuell ein DNS-Problem vorliegt:
quelle
Sehr spät zu diesem Thread, aber ich denke, der Teil der Frage, warum ein dig + trace rekursive Abfragen an lokale Resolver verwendet, wurde nicht direkt erklärt, und diese Erklärung ist für die Genauigkeit der Ergebnisse von dig + trace relevant.
Nach der ersten rekursiven Abfrage nach den NS-Einträgen der Root-Zone kann dig unter den folgenden Bedingungen nachfolgende Abfragen an lokale Resolver senden:
Eine Verweisantwort wird abgeschnitten, da die Antwortgröße bei der nächsten iterativen Abfrage 512 Byte überschreitet
dig wählt einen NS-Datensatz aus dem Abschnitt AUTHORITY der Überweisungsantwort aus, für den der entsprechende A-Datensatz (Klebstoff) im Abschnitt ADDITIONAL fehlt
Da dig nur einen Domänennamen aus dem NS-Eintrag hat, muss dig den Namen durch Abfragen des lokalen DNS-Servers in eine IP-Adresse auflösen. Dies ist die Hauptursache (Wortspiel beabsichtigt, sorry).
AndrewB hat ein Beispiel, das nicht vollständig mit dem übereinstimmt, was ich gerade beschrieben habe:
. 121459 IN NS e.root-servers.net.hat einen entsprechenden A-Satz:
e.root-servers.net. 354907 IN A 192.203.230.10Beachten Sie jedoch, dass es keinen entsprechenden AAAA-Eintrag für E-Root sowie keinen AAAA-Eintrag für einige andere Root-Server gibt.
Beachten Sie auch die Größe der Antwort:
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms496 Bytes ist eine übliche Größe für Antworten, die abgeschnitten wurden (dh der nächste Klebesatz wäre> 16 Bytes, wobei die Antwort über 512 Bytes liegt). Mit anderen Worten, in einer Abfrage nach den NS-Einträgen von root überschreiten ein vollständiger AUTHORITY- und ein vollständiger ADDITIONAL-Eintrag (sowohl A- als auch AAAA-Einträge) 512 Byte. Daher wird jede UDP-basierte Abfrage, die über EDNS0-Optionen keine größere Abfragegröße angibt, ausgeführt eine Antwort erhalten, die irgendwo im Abschnitt ZUSÄTZLICH abgeschnitten ist, wie die obige Ablaufverfolgung zeigt (nur f, h, i, j und k haben A- und AAAA-Leimdatensätze).
Das Fehlen eines AAAA-Eintrags für e.root-servers.net und die Größe der Antwort an die "NS". Die Abfrage deutet nachdrücklich darauf hin, dass die nächste rekursive Abfrage aus dem von mir behaupteten Grund durchgeführt wurde. Möglicherweise ist das Client-Betriebssystem IPv6-fähig und bevorzugt AAAA-Datensätze - oder aus einem anderen Grund.
Aber auf jeden Fall habe ich mich nach dem Lesen dieses Threads mit dem Phänomen befasst, dass dig + trace rekursive Abfragen nach dem ersten für root ausführt. Die Entsprechung zwischen der Auswahl eines NS-Eintrags ohne entsprechenden A / AAAA-Eintrag und dem anschließenden Senden einer rekursiven Abfrage für diesen Eintrag an das lokale DNS beträgt nach meiner Erfahrung 100%. Und das Gegenteil ist der Fall - ich habe keine rekursiven Abfragen gesehen, wenn der aus der Überweisung ausgewählte NS-Datensatz einen entsprechenden Leimdatensatz enthält.
quelle