Was ist dig +trace?

Dig +trace verfolgt die Delegierungskette für die betreffende Domain vollständig. Das reicht von Root-Nameservern über Top-Level-Domain-Server (TLD) bis hin zu autoritativen Nameservern. Dig +trace hilft Teams bei der Fehlerbehebung von DNS-Auflösungsproblemen.

Das auf den ersten Blick erkennbare Problem wäre, dass keine Verbindung zu einer bestimmten Domain oder Subdomain hergestellt werden kann, was durch eine Störungsmeldung auf dem Bildschirm angezeigt wird. Eine andere Art von DNS-Auflösungsproblem ist die Latenz, die die Abfragezeiten über die normale menschliche Geduld hinaus verlängern kann.

Die durchschnittliche DNS-Nachschlagzeit wird in Millisekunden (ms) gemessen und liegt meist im Bereich zwischen 20 ms und 120 ms. Durch Optimierungsmaßnahmen wird versucht, diese Abfragezeiten weiter zu reduzieren.

Bei einem normalen dig-Befehl sendet Ihr DNS-Server, der als Resolver Ihres Internetdienstanbieters (ISP) fungiert, eine rekursive Anfrage und überprüft seine lokalen Caches auf einen aktuellen, noch gültigen DNS-Eintrag. Aber das passiert nur in einer idealen Situation, wenn alles nach Plan läuft. 

Administratoren greifen auf dig +trace zurück, wenn sie „unter der Oberfläche“ schauen müssen. Normalerweise müssen Sie den üblichen Abfrageprozess umgehen, weil etwas schief gelaufen ist. Es gibt einen Teil der Routing-Kette, der nicht richtig funktioniert. Daher müssen Administratoren in der Lage sein, Teile dieser Kette und ihre verschiedenen Verbindungen zu analysieren und zu untersuchen, um herauszufinden, was nicht ordnungsgemäß funktioniert.

Wenn Teams dig +trace verwenden, ignorieren sie effektiv die zuvor zwischengespeicherten Daten, sodass sie eine neue und iterative Abfrage ausführen können, ohne über alte und veraltete Pfade geleitet zu werden.

Dig +trace ist nützlich für die Fehlerbehebung, da es Ihnen ermöglicht zu sehen, wo die DNS-Auflösung fehlschlägt. Das Problem könnte auf der Root-, TLD- oder autoritativen Ebene liegen. Das Tool kann auch überprüfen, ob die Nameserver-Einträge Ihrer Domain korrekt sind, und die DNS-Propagierung nach Änderungen verifizieren.

Der dig +trace-Prozess lässt sich im Grunde auf vier Schritte reduzieren.

Wenn der Benutzer diesen Domainnamen zuvor eingegeben hat und der Computer seine IP-Adresse zwischengespeichert hat, ruft der Prompt (CMD) sofort die benötigte IP-Adresse ab. Das System greift auf die angeforderten Inhalte zu, lädt sie herunter und der Abfragevorgang ist damit beendet. 

Wenn der Domainname jedoch neu und diesem Gerät unbekannt ist, werden die restlichen Schritte ausgeführt.

Der dig-Befehl sucht die Root-Nameserver für die Nameserver-(NS)-Datensätze, die mit der Top-Level-Domain (TLD) der untersuchten Zieldomain verbunden sind.

Der dig-Befehl untersucht TLD-Nameserver, um die autoritativen Nameserver für eine bestimmte Domain zu ermitteln.

Der dig-Befehl fragt dann die autoritativen Nameserver ab, um auf die angeforderten DNS-Einträge zuzugreifen. Zum Beispiel ist der „A-Eintrag“ ein Ressourceneintrag, der eine menschenfreundliche Domain mit einer IPv4- oder IPv6-Adresse verknüpft. In der Zwischenzeit enthalten SOA-Einträge (Start of Authority) die notwendigen Verwaltungsdaten für eine DNS-Zone.

Die angegebene DNS-Antwort beinhaltet den „Antwortabschnitt“, das sind Ressourceneinträge, die erfolgreich auf die ursprüngliche Anfrage antworten können (auch bekannt als „Fragenabschnitt“).

Darüber hinaus könnte die Antwort auch einen Abschnitt mit Autoritätsinformationen enthalten, in dem die maßgeblichen Nameserver aufgelistet sind, sowie gegebenenfalls einen „zusätzlichen Abschnitt“ mit weiteren Informationen. Administratoren können genau auswählen, welche Arten von Datensätzen sie benötigen, sei es für Mailserver (MX-Einträge) oder Nameserver (NS-Einträge). 

Bei jedem Untersuchungsschritt auf diesem Weg erhalten die Administratoren Ausgabemeldungen, die sie über den Status jeder Phase informieren und darüber, ob der Fortschritt wie vorgesehen verläuft.

Beispielsweise sieht der Administrator die Meldung „NOERROR“, um ihn darüber zu informieren, dass in dieser Testphase keine Vorfälle aufgetreten sind. (Hinweis: Diese Meldung gibt keinen Aufschluss über den allgemeinen Erfolg oder Misserfolg der Operation und sollte nicht falsch interpretiert werden. Sie ist zwar nützlich, aber nur begrenzt aussagekräftig.)

Es ist interessant zu beobachten, dass die DNS-Infrastruktur die DNS-Hierarchie unterstützt und ein ausgeklügeltes System von Verweisen verwendet, um den Suchvorgang zu erleichtern. Wenn ein Server die Anfrage nicht vollständig bearbeiten kann, leitet er sie im Wesentlichen an einen anderen Server weiter, der ihren Fortschritt unterstützt und ihre Bearbeitung verlängert. 

Das vom Internet verwendete Domainnamensystem besteht aus verschiedenen Root-Nameservern, die auf unterschiedlichen Ebenen arbeiten. Von besonderer Bedeutung sind die 13 logischen Root-Nameserver, die auf oberster Ebene arbeiten und nach den ersten 13 Buchstaben des Alphabets benannt sind.

Jeder dieser 13 logischen Root-Nameserver bezieht sich nicht auf einzelne Computer oder Betriebssysteme, sondern repräsentiert eine benannte Behörde, die ein Dreizehntel des gesamten DNS-Abfrageverkehrs im Internet regelt. Wenn wir also von „Server A“ sprechen, meinen wir die Bezeichnung Server A, die eine unbegrenzte Anzahl einzelner DNS-Server abdecken kann.

Es ist außerdem erwähnenswert, dass die 13 Root-Nameserver an eine Vielzahl von Organisationen delegiert sind – verschiedene gewinnorientierte Unternehmen, Universitäten und Militärorganisationen. Und obwohl es wahr ist, dass sich der Standort der meisten physischen Server ursprünglich stark auf die Vereinigten Staaten konzentrierte, hat sich diese Gleichung im Laufe der Zeit neu ausbalanciert. Die physischen Server befinden sich jetzt überall auf der Welt.

Hier sind die Gruppen, die für den Betrieb der 13 verschiedenen root-servers.net-Bezeichnungen verantwortlich sind:

• Server A (a.root-servers.net): Betreiber: VeriSign, Inc., ein Anbieter von Internetinfrastruktur- und Domainnamenregistrierungsdiensten weltweit.

• Server B (b.root-servers.net): Betreiber: University of Southern California (ISI). Das Information Sciences Institute (ISI) der USC erforscht fortschrittliche Computer- und Kommunikationstechnologie.

• Server C (c.root-servers.net): Betreiber: Cogent Communications, ein internationaler ISP, der ein umfangreiches Glasfasernetzwerk verwaltet und Colocation-Dienstleistungen anbietet.

• Server D (d.root-servers.net): Betreiber: Die Universität Maryland, verwaltet durch ihre Gruppe „Advanced Cyberinfrastructure and Internet Global Services“ (ACIGS).

• Server E (e.root-servers.net): Betreiber: NASA, genauer gesagt die Serviceabteilung Network and Telecommunication Services (NaTS) der US-amerikanischen Raumfahrtbehörde. 

• Server F (f.root-servers.net): Betreiber: Internet Systems Consortium, Inc., eine gemeinnützige Organisation, die das Internet durch verschiedene Software und Protokolle unterstützt. 

• Server G (g.root-servers.net): Betreiber: US Department of Defense Network Information Center (NIC), das auch für die Verwaltung des IPv6-Adressplans des DoD verantwortlich ist.

• Server H (h.root-servers.net): Betreiber: US Army Research Laboratory (ARL), früher bekannt als Ballistics Research Laboratory (BRL). 

• Server I (i.root-servers.net): Betreiber: Netnod, eine schwedische gemeinnützige Internetinfrastrukturorganisation, die vor allem für Interkonnektivitätsdienste in nordischen Regionen bekannt ist. 

• Server J (j.root-servers.net): Betreiber: VeriSign, Inc. (siehe Server A). 

• Server K (k.root-servers.net): Betreiber: Reseaux IP Europeens Network Coordination Centre (RIPE NCC), eine gemeinnützige regionale Internet-Registry (RIR) für Europa, den Nahen Osten und Asien. 

• Server L (l.root-servers.net): Betreiber: Internet Corporation for Assigned Names and Numbers (ICANN), ein Unternehmen, das durch einen Vertrag mit der Regierung entstand, aber jetzt als eigenständige, global ausgerichtete Einheit existiert.

• Server M (m.root-servers.net): Betreiber: Das WIDE-Projekt, was für Widely Integrated Distributed Environment steht, ist ein Internetprojekt, das durch die Zusammenarbeit dreier japanischer Universitäten begann. 

Der Anfrageverkehr wird gleichmäßig auf die 13 Server verteilt, wobei kein Server mehr Anfragen bearbeitet als ein anderer. Regionale Faktoren können Einfluss darauf haben, auf welche Server die Benutzer am häufigsten zugreifen, aber insgesamt ist der Datenverkehr ähnlich und besteht hauptsächlich aus Anfragen an ISP-Adressen.

Der Grund dafür, dass 13 Instanzen erforderlich sind, um den DNS-Abfrageverkehr zu verwalten, liegt darin, dass jedes Jahr Billionen von DNS-Abfragen generiert werden. Einige Schätzungen gehen davon aus, dass die Gesamtsumme über 100 Billionen steigen wird, aber diese Zahlen sind fundierte Vermutungen. Es ist eine so große Zahl, dass sie wirklich nicht berechnet werden kann.

Es gibt eine Handvoll tangential verwandter Themen, die ebenfalls angesprochen werden sollten:

• Eine Möglichkeit, den Nutzen von DNS noch zu steigern, besteht in der Verwendung von Erweiterungsmechanismen für DNS (EDNS). EDNS ist eine Sammlung von Erweiterungen für DNS-Protokolle. Wenn Administratoren auf größere DNS-Nachrichten-Payloads stoßen, passt sich EDNS an, um diese übergroßen Datenpakete zu transportieren. Neben der Möglichkeit, größere Nachrichten zu übertragen, bietet EDNS auch Optionen wie EDNS Client Subnet (ECS), das die Leistungsfähigkeit von Anwendungen verbessert, die häufig von Latenzproblemen betroffen sind. 

• Die OPT-Pseudosektion ist ein einzigartiger Typ von DNS-Eintrag, der von EDNS eingeführt wurde. Sie enthält nützliche Transaktionsinformationen, jedoch keine Standard-DNS-Daten. Der OPT-Pseudosektion ist im Abschnitt „Zusatzdaten“ der DNS-Nachrichten enthalten. Es enthält Details wie EDNS-Versionen, Flags und die maximale Paketgröße für das User Datagram Protocol (UDP), ein häufig verwendetes Abfrageformat. 

• Linux-Betriebssysteme und bestimmte Unix-ähnliche Systeme verwenden die Konfigurationsdatei etc/resolv.conf, um das System anzuweisen, seine Resolver-Routinen zu aktivieren, um IP-Adressen für entsprechende Hostnamen zu finden. Der Inhalt dieser Datei umfasst die IP-Adressen von DNS-Servern, Listen mit zu durchsuchenden Domains, lokale Domainnamen und Optionen, mit denen Sie die Aktionen des Resolvers festlegen können. Diese Aktionen können globale Optionen umfassen, also Einstellungen, die Administratoren einseitig anwenden können. 

• Unix-ähnliche Systeme, die eigentlich kein DNS verwenden, enthalten oft eine Handbuchseite (oder „Manpage“). Diese Seite dient als Dokumentation, die definierte Daten zu einer bestimmten Befehlsdatei, einem Systemaufruf oder einer Konfigurationsdatei enthält. Manpages vermitteln einen allgemeinen Überblick über Systemdateien und -werkzeuge und konzentrieren sich dabei auf Informationen wie Befehls- oder Programmnamen, Zusammenfassungen, Beschreibungen und Optionen.