Wie funktioniert dig + trace eigentlich?

35790
Doktor J

Wenn ich auf der Manpage nach dig schaue, bekomme ich Folgendes:

+[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup.

Wie funktioniert das in der Praxis? Was wäre die äquivalente digBefehlsfolge (ohne + trace), die funktional gleichwertig wäre?

12

2 Antworten auf die Frage

30
milli

dig +trace funktioniert, indem er vorgibt, dass es sich um einen Nameserver handelt, und der Namespace-Baum wird mit iterativen Abfragen heruntergefahren, beginnend am Stamm des Baums und folgt Verweisen auf dem Weg.

Als Erstes fragt der normale DNS-Server des Systems nach NS-Einträgen nach ".".

Nachdem er eine Antwort erhalten hat, die die aktuelle Liste der Stammnamenserver ist, wählt er einen aus und fragt nach dem A-Datensatz für diesen Namen, wenn er nicht beim ersten Eintrag im Abschnitt mit den zusätzlichen Datensätzen abgerufen wurde eine IP-Adresse, an die die nächste Abfrage gesendet werden soll. Nehmen wir an, es wählt f.root-servers.net mit der IP-Adresse 192.5.5.241.

An dieser Stelle verwenden wir dig +trace www.google.co.uk.als Befehl einen Domänennamen, für den wir den Auflösungspfad verfolgen möchten.

Die nächste Abfrage hinter den Kulissen lautet wie folgt:

$ dig +norecurse @192.5.5.241 www.google.co.uk  ; <<>> DiG 9.9.4 <<>> +norecurse @192.5.5.241 www.google.co.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8962 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 15  ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.co.uk. IN A  ;; AUTHORITY SECTION: uk. 172800 IN NS ns5.nic.uk. uk. 172800 IN NS ns6.nic.uk. uk. 172800 IN NS ns4.nic.uk. uk. 172800 IN NS nsc.nic.uk. uk. 172800 IN NS ns2.nic.uk. uk. 172800 IN NS ns3.nic.uk. uk. 172800 IN NS nsd.nic.uk. uk. 172800 IN NS nsa.nic.uk. uk. 172800 IN NS ns7.nic.uk. uk. 172800 IN NS nsb.nic.uk. uk. 172800 IN NS ns1.nic.uk.  ;; ADDITIONAL SECTION: ns1.nic.uk. 172800 IN A 195.66.240.130 ns2.nic.uk. 172800 IN A 217.79.164.131 ns3.nic.uk. 172800 IN A 213.219.13.131 ns4.nic.uk. 172800 IN A 194.83.244.131 ns5.nic.uk. 172800 IN A 213.246.167.131 ns6.nic.uk. 172800 IN A 213.248.254.130 ns7.nic.uk. 172800 IN A 212.121.40.130 nsa.nic.uk. 172800 IN A 156.154.100.3 nsb.nic.uk. 172800 IN A 156.154.101.3 nsc.nic.uk. 172800 IN A 156.154.102.3 nsd.nic.uk. 172800 IN A 156.154.103.3 ns1.nic.uk. 172800 IN AAAA 2a01:40:1001:35::2 ns4.nic.uk. 172800 IN AAAA 2001:630:181:35::83 nsa.nic.uk. 172800 IN AAAA 2001:502:ad09::3  ;; Query time: 45 msec ;; SERVER: 192.5.5.241#53(192.5.5.241) ;; WHEN: Tue Feb 11 19:19:14 MST 2014 ;; MSG SIZE rcvd: 507

Wow, also wissen wir jetzt, dass es Nameserver gibt ukund das ist das einzige, was der Root-Server weiß. Dies ist eine Überweisung, weil wir nicht um Rekursion gebeten haben ( +norecurseschaltet sie aus).

Toll, wir spülen und wiederholen. Dieses Mal wählen wir einen der ukNameserver aus und stellen ihm dieselbe Frage .

$ dig +norecurse @195.66.240.130 www.google.co.uk  ; <<>> DiG 9.9.4 <<>> +norecurse @195.66.240.130 www.google.co.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 618 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1  ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.co.uk. IN A  ;; AUTHORITY SECTION: google.co.uk. 172800 IN NS ns1.google.com. google.co.uk. 172800 IN NS ns3.google.com. google.co.uk. 172800 IN NS ns2.google.com. google.co.uk. 172800 IN NS ns4.google.com.  ;; Query time: 354 msec ;; SERVER: 195.66.240.130#53(195.66.240.130) ;; WHEN: Tue Feb 11 19:22:47 MST 2014 ;; MSG SIZE rcvd: 127

Toll, jetzt haben wir herausgefunden, dass der ukTop-Level-Nameserver weiß, dass es eine Zone gibt, die angerufen wird, google.co.ukund uns anweist, diesen Nameservern unsere Frage zu stellen. Dies ist eine weitere Überweisung.

Spülen, wiederholen.

Dieses Mal haben wir jedoch keine A-Datensätze im Abschnitt mit den zusätzlichen Datensätzen der Antwort erhalten. Daher wählen wir einen aus, beispielsweise ns2.google.com, und müssen die Adresse finden. Wir starten eine Abfrage erneut (im Stammverzeichnis erneut) und jagen den Baum nach der IP-Adresse für ns2.google.com. Ich werde diesen Teil der Kürze halber überspringen, aber wir erfahren, dass die IP dafür 216.239.34.10 ist.

Unsere nächste Frage lautet also:

$ dig +norecurse @216.239.34.10 www.google.co.uk  ; <<>> DiG 9.9.4 <<>> +norecurse @216.239.34.10 www.google.co.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33404 ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0  ;; QUESTION SECTION: ;www.google.co.uk. IN A  ;; ANSWER SECTION: www.google.co.uk. 300 IN A 74.125.225.216 www.google.co.uk. 300 IN A 74.125.225.223 www.google.co.uk. 300 IN A 74.125.225.215  ;; Query time: 207 msec ;; SERVER: 216.239.34.10#53(216.239.34.10) ;; WHEN: Tue Feb 11 19:26:43 MST 2014 ;; MSG SIZE rcvd: 82

Und wir sind fertig! (endlich) Woher wissen wir, dass wir fertig sind? Wir haben eine Antwort auf unsere Anfrage erhalten, nämlich die A-Datensätze für www.google.de. Sie können auch feststellen, dass es sich nicht mehr um einen Verweis handelt. Das aaBit wird in der letzten Antwort gesetzt. Dies bedeutet, dass dies die maßgebliche Antwort für Ihre Abfrage ist.

Das ist also, was bei jedem Schritt passiert, wenn Sie es verwenden dig +trace.

Wenn Sie über eine DNSSEC-fähige Version von dig verfügen und Sie +dnssecden Befehl hinzufügen, werden möglicherweise mehrere Datensätze angezeigt. Was diese zusätzlichen Datensätze sind, bleibt dem Leser als Übung überlassen dig +sigchase.

Ein Zweifel: In der Anfrage an @ 192.5.5.241, den Antworten in der ZUSÄTZLICHEN SECTION, handelt es sich um die sogenannten _glue-Records_? José Tomás Tocino vor 6 Jahren 0
Ja, da der Name der A-Datensätze innerhalb oder unterhalb der Zone vorhanden ist, auf die sich die NS-Datensätze im Abschnitt "Authority" beziehen, damit sie den Lösungsprozess fortsetzen können. milli vor 6 Jahren 0
1
Paul

Sagen wir, Sie haben nachgeschlagen

www.domain.co.uk

DNS ist eine Hierarchie, die mit Stammservern beginnt, die wissen, welche Server für die TLDs (den letzten Teil des Domänennamens) autorisierend sind. Also das Gleiche zu

dig subdomain.domain.co.uk

Schritt für Schritt wäre:

dig SOA @g.root-servers.net uk

(dh fragen Sie einen der Root-Server ab, um herauszufinden, wer für .uk autorisiert ist)

Dies antwortet mit einer Reihe autoritärer britischer Server, daher fragen wir sie, wer co.uk hat

dig SOA @ns6.nic.uk co.uk

Und wir erfahren, dass sich die SOA (Behörde) auf den gleichen Servern befindet

Lassen Sie uns also ns1.nic.uk abfragen, um zu sehen, wer domain.de hat

dig SOA @ns1.nic.uk domain.co.uk

Dies kommt zurück und sagt, dass die Berechtigung für Domain bei dns.dns1.de (plus Backups) liegt;

Jetzt können wir nach dem A-Datensatz fragen:

dig A @dns.dns2.de www.domain.co.uk  ;; QUESTION SECTION: ;www.domain.co.uk. IN A  ;; ANSWER SECTION: www.domain.co.uk. 86400 IN CNAME domain.co.uk. domain.co.uk. 86400 IN A 95.130.17.36
Wie gehe ich auf das Thema Delegation ein? Nehmen wir an, die Berechtigung für domain.co.uk ist dns.dns1.de, aber member.domain.co.uk wurde an dns.dns2.com delegiert, und ich schaue nach joe.members.domain.co.uk. Woher weiß ich, wann es "sicher" ist, das SOA-Karussell zu verlassen und die anderen Datensätze abzufragen? Doktor J vor 10 Jahren 0
Der eigentliche Prozess fragt immer nach dem A-Datensatz. Es gibt keine magische Umstellung auf `SOA`-Abfragen. (Das konnte nicht sein, da ein auflösender Proxy nicht wissen würde, wann er zurückgeschaltet werden sollte.) In der Frage gibt es auch keine magische Änderung des Domänennamens. Es ist `www.domain.co.uk.` den ganzen Weg hindurch. Dies ist wichtig zu beachten, da dies bedeutet, dass einige der abgefragten Inhaltsserver die vollständige Antwort liefern können. JdeBP vor 10 Jahren 0
@DoktorJ Ja, das ist mein Fehler, dass JdeBP recht hat. Ich habe versucht, einen Punkt mit der SOA zu erreichen, der sich jedoch in der Antwort verwickelt hat. Die andere Antwort ist genauer. Paul vor 10 Jahren 0
@Paul danke für das Followup; Ich habe die andere Antwort als die richtige Antwort markiert, um anderen zu helfen, die hier enden könnten (keine Beleidigung für Sie!) :) Doktor J vor 10 Jahren 0
@doktorj Überhaupt nicht, das ist genau so, wie es sein sollte :) Paul vor 10 Jahren 0

Verwandte Probleme