Ist dig + trace immer korrekt?

Wenn die Genauigkeit eines DNS-Cache in Frage gestellt wird, ist dies in dig +traceder Regel die empfohlene Methode, um die maßgebliche Antwort für einen mit dem Internet verbundenen DNS-Eintrag zu ermitteln. Dies scheint besonders nützlich zu sein, wenn auch zusammen mit +additional, die auch die Leimaufzeichnungen zeigt.

Gelegentlich scheint es in diesem Punkt Unstimmigkeiten zu geben - einige Leute sagen, dass es auf dem lokalen Resolver beruht, die IP-Adressen der zwischengeschalteten Nameserver nachzuschlagen, aber die Befehlsausgabe bietet keinen Hinweis darauf, dass dies außerhalb der ursprünglichen Root-Liste geschieht Nameserver. Es scheint logisch anzunehmen, dass dies nicht der Fall ist, wenn der Zweck darin +tracebesteht, auf den Stammservern zu starten und Ihren Weg nach unten zu verfolgen. (Zumindest, wenn Sie die richtige Liste von Root-Nameservern haben)

Ist dig +tracewirklich die lokalen Resolver für alles vorbei an dem Root - Nameserver verwenden?

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.

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:

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:

1. Eine Verweisantwort wird abgeschnitten, da die Antwortgröße bei der nächsten iterativen Abfrage 512 Byte überschreitet

2. 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.10

Beachten 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 ms

496 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.