Frage Ist Dig + Trace immer genau?


Wenn die Genauigkeit eines DNS-Cache in Frage steht, dig +trace tendiert dazu, die empfohlene Methode zur Bestimmung der maßgeblichen Antwort für einen DNS-Eintrag im Internet zu sein. Dies scheint besonders nützlich zu sein, wenn auch gepaart mit +additional, die auch die Kleberaufzeichnungen zeigt.

Gelegentlich scheint es in diesem Punkt Meinungsverschiedenheiten zu geben - einige Leute sagen, dass es auf den lokalen Resolver angewiesen ist, die IP-Adressen der intermediären Nameserver nachzuschlagen, aber die Befehlsausgabe bietet keinen Hinweis darauf, dass dies über die ursprüngliche Liste von root hinaus geschieht Nameserver. Es erscheint logisch anzunehmen, dass dies nicht der Fall wäre, wenn der Zweck von +trace ist es, bei den Root-Servern zu beginnen und Ihren Weg nach unten zu verfolgen. (zumindest wenn Sie die richtige Liste von Root Nameservern haben)

Tut dig +trace Verwenden Sie den lokalen Resolver wirklich für alles nach dem Root Nameserver?


29
2018-02-27 07:51


Ursprung




Antworten:


Dies ist offensichtlich eine inszenierte Frage und Antwort, aber Das verwirrt die Menschen oft und ich kann keine kanonische Frage zum Thema finden.

dig +trace ist ein großartiges Diagnosewerkzeug, aber ein Aspekt seines Designs wird weitgehend missverstanden: Die IP jedes Servers, der abgefragt wird, erhalten Sie von Ihrer Resolver-Bibliothek. Dies wird sehr leicht übersehen und oft wird nur ein Problem, wenn Ihr lokaler Cache hat falsch Antwort für einen zwischengespeicherten Nameserver.


Detaillierte Analyse

Dies ist leichter mit einem Beispiel der Ausgabe zu brechen; Ich werde alles über die erste NS-Delegation hinauslassen.

; <<>> 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 erste Abfrage nach . IN NS (root nameservers) trifft den lokalen Resolver, in diesem Fall Comcast. (75.75.75.75) Das ist leicht zu erkennen.
  • Die nächste Abfrage ist für serverfault.com. IN A und läuft dagegen e.root-servers.net., zufällig aus der Liste der Root Nameserver ausgewählt, die wir gerade erhalten haben. Es hat eine IP-Adresse von 192.203.230.10und seit wir haben +additional aktiviert es erscheint aus dem Leim kommen.
  • Da es für serverfault.com nicht autorisierend ist, wird dieses an die com. TLD-Nameserver.
  • Was aus der Ausgabe hier nicht offensichtlich ist, ist dass dig habe die IP-Adresse von nicht abgeleitet e.root-servers.net. aus dem Leim.

Im Hintergrund ist das wirklich 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)

+trace betrogen und konsultierte den lokalen Resolver, um die IP-Adresse des Nameservers des nächsten Hops zu erhalten, anstatt den Kleber zu konsultieren. Hinterhältig!

Dies ist normalerweise "gut genug" und wird für die meisten Leute kein Problem verursachen. Leider gibt es Randfälle. Wenn Ihr Upstream-DNS-Cache aus irgendeinem Grund die falsche Antwort für den Nameserver liefert, bricht dieses Modell vollständig zusammen.

Beispiel aus der realen Welt:

  • Domain läuft ab
  • Leim wird bei Registrar Redirection Nameservern neu definiert
  • gefälschte IPs werden für ns1 und ns2.yourdomain.com zwischengespeichert
  • Domäne wird mit wieder hergestelltem Kleber erneuert
  • Alle Caches mit den falschen Nameserver-IPs senden weiterhin Personen an eine Website, auf der steht, dass die Domain zum Verkauf steht

Im obigen Fall +tracewird vorschlagen, dass die eigenen Nameserver des Domaininhabers die Ursache des Problems sind, und Sie sind nur einen Anruf davon entfernt, einem Kunden zu sagen, dass seine Server falsch konfiguriert sind. Ob 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 jedes Tool müssen Sie wissen, was es tut und was nicht, und wie Sie das Problem manuell beheben können, wenn es nicht ausreicht.


Bearbeiten:

Es sollte auch beachtet werden, dass dig +trace Ich werde dich nicht warnen NS Datensätze, die auf zeigen CNAMEAliase. Dies ist eine RFC-Verletzung, die ISC BIND (und möglicherweise andere) nicht versuchen zu korrigieren. +trace werde ganz glücklich sein, das zu akzeptieren A notieren sie es von Ihrem lokal konfigurierten Nameserver, wohingegen wenn BIND eine vollständige Rekursion durchführen würde, würde es die gesamte Zone mit einem SERVFAIL ablehnen.

Dies kann schwierig zu beheben sein, wenn Klebstoff vorhanden ist. Das wird gut funktionieren bis die NS-Datensätze aktualisiert werden, dann plötzlich brechen. Glueless Delegationen werden immer BINDs Rekursion unterbrechen, wenn a NS Punkte bei einem Alias ​​aufzeichnen.


26
2018-02-27 07:51



Wie wäre es mit +nssearch? - vonbrand
@vonbrand +nssearch führt ein NS Aufzeichnen der Suche nach dem lokalen Resolver für den angeforderten Datensatz, gefolgt von einer Reihe von A/AAAA Suche nach dem lokalen Resolver für jeden der zurückgegebenen Nameserver. Es ist auch anfällig für falsche Nameserver-Datensätze im Cache. - Andrew B
Also, was ist die Lösung? Benutze "dig ... @server" und folge der Delegation manuell? - Raman
@Raman Ja, entweder ist es das, oder Sie müssen den Cache eines rekursiven Servers leeren, den Sie praktisch haben, die Abfrage erstellen und den Cache ausgeben. (was die Idee eines leichtgewichtigen Clients vereitelt) dig macht dies, um die Anzahl der erforderlichen Abfragen exponentiell zu reduzieren. - Andrew B


Eine andere Möglichkeit, die DNS-Auflösung zu verfolgen, ohne den lokalen Resolver für irgendetwas zu verwenden, außer den Wurzel-Nameserver zu finden, benutzt Dnsgraph (Vollständige Offenlegung: Ich schrieb dies). Es hat ein Kommandozeilen-Tool und eine Web-Version, unter der Sie eine Instanz finden können http://ip.seveas.net/dnsgraph/

Beispiel für serverfault.com, das gerade ein DNS-Problem hat:

enter image description here


11
2018-04-27 10:02



Der stickige Pedant in mir will sagen, dass das technisch keine Antwort ist. Der DNS-Administrator in mir denkt, dass es großartig ist und ist mir völlig egal. - Andrew B
Ich wollte es als Kommentar posten, wollte aber das Bild einfügen. Fühlen Sie sich frei, es in Ihre Antwort zu verschmelzen, wenn Sie denken, dass das besser ist. - Dennis Kaarsemaker
Mir geht es gut mit den Dingen, wie sie sind. Wenn eine Mod sich anders fühlt, werde ich das zwar konsolidieren, aber sicher. - Andrew B