Root-DNS-Server verweisen Resolver an die Server der Top-Level-Domains

Root-DNS-Server helfen einem Resolver, die zuständigen Server einer Top-Level-Domain wie .com oder .org zu finden. Die Root-Zone enthält hauptsächlich solche Delegierungen. Root-Server speichern nicht die Adressen aller Websites und erledigen nicht jede Namensauflösung für Besucher. IANA beschreibt den Umfang der Root-Zone.

Die bekannte Zahl dreizehn bezeichnet benannte Autoritäten von a.root-servers.net bis m.root-servers.net. Die Zahl bezeichnet keine dreizehn einzelnen Rechner. IANA führt die Namen, Adressen und Betreiber auf.

Für Domaininhaber ist die Zuständigkeit entscheidend. Ein Website-Eintrag gehört in die autoritative Zone der Domain. Eine Root-Server-Einstellung gehört zur Infrastruktur, die Delegierungsinformationen ermittelt. Wer die Aufgaben verwechselt, untersucht möglicherweise einen Dienst, der den betroffenen Eintrag gar nicht korrigieren kann.

Root-Server verweisen Resolver an die nächste zuständige Stelle

Das DNS verteilt Zuständigkeiten über eine Hierarchie. Die Root-Zone (Root-Server) bildet die höchste Ebene. Eine TLD liegt unmittelbar unter der Root-Zone. IANA dokumentiert technische Delegierungsinformationen für TLDs und nennt deren Verwalter. Die Übersicht zur Root-Zone erläutert die Zuständigkeiten.

Betrachten Sie eine hypothetische Abfrage für www.example.com.. Der abschließende Punkt kennzeichnet ausdrücklich die DNS-Wurzel. Ein DNS-Resolver (Rekursiver Resolver) beschafft die Informationen für die Antwort an den Client. Ein autoritativer Server antwortet anhand der Zonendaten, für die der Server zuständig ist. RFC 9499 unterscheidet die Rollen von Resolvern und Servern.

Ohne brauchbare zwischengespeicherte Delegierung kann der Resolver einen Root-Server nach dem nächsten Schritt zu .com fragen. Der Root-Server liefert einen Verweis mit den Namen der .com-Server. Anschließend fragt der Resolver einen .com-Server nach example.com, erhält eine weitere Delegierung und kontaktiert die autoritativen Server der Domain.

Ein Verweis enthält normalerweise die NS-Einträge der untergeordneten Zone im Abschnitt „Authority“. Die Antwort kann außerdem nützliche Serveradressen im Abschnitt „Additional“ enthalten. Bestimmte unterstützende Adresseinträge heißen im DNS „Glue“. RFC 1034 beschreibt den Aufbau eines Verweises in Abschnitt 4.3.2.

Der Resolver folgt dem Verweis. Der Root-Server leitet die Website-Anfrage des Besuchers nicht an den TLD-Server weiter. Auch die Website-Inhalte reisen getrennt von den DNS-Antworten. Ein funktionierender Root-Dienst beweist deshalb nicht, dass eine Anwendung funktioniert.

Die folgende Übersicht hilft bei der Wahl der Untersuchungsebene. Die Rollen beschreiben eine vereinfachte öffentliche Namensauflösung, nicht jede mögliche Bereitstellung.

Das Wort „Nameserver“ kann unterschiedliche Rollen bezeichnen. Notieren Sie vor einer Supportanfrage den abgefragten Namen, den Eintragstyp, den Server und die Antwort. Die Aussage „DNS funktioniert nicht“ benennt die fehlerhafte Ebene nicht.

Ein korrekter .com-Verweis bestätigt beispielsweise nicht den A-Eintrag für www.example.com. Der Verweis zeigt den nächsten Schritt. Die autoritative Antwort der Domain beantwortet die spätere Adressfrage. Bewahren Sie beide Beobachtungen auf, wenn Sie erfolgreiche und fehlgeschlagene Abfragen vergleichen.

Dreizehn Kennungen stehen für einen verteilten Dienst

Die Root-Server-Kennungen verwenden die Buchstaben A bis M. Jede Kennung hat eine IPv4-Adresse und eine IPv6-Adresse. Mehrere physische Instanzen können den Dienst hinter einer Kennung bereitstellen. Die FAQ der Betreiber unterscheidet ausdrücklich zwischen Kennungen, Betreibern und Instanzen. Lesen Sie die drei Fragen zur Anzahl.

Eine Kennung unterscheidet sich somit von einer Adresse, und eine Adresse unterscheidet sich von einem Rechner. Dreizehn Kennungen bedeuten nicht insgesamt dreizehn Adressen. Eine kopierte Adressliste zeigt auch nicht die physische Bereitstellung hinter jeder Adresse.

Anycast macht eine Dienstadresse an mehreren Standorten verfügbar. Das Routing lenkt ein Paket zu einem erreichbaren Standort. Der Client muss keine physische Instanz aus einer weltweiten Liste auswählen. RFC 9499 definiert Anycast und Instanzen.

Die Root-Server-Betreiber veröffentlichen Instanzstandorte und Betriebsinformationen auf ihrer gemeinsamen Website. Die Anzahl der Instanzen ändert sich mit der Bereitstellung. Eine feste Gesamtzahl wird schnell zu einer historischen Momentaufnahme. Aktuelle Betriebsfragen erfordern deshalb eine aktuelle Prüfung. Die Root-Server-Website veröffentlicht das aktuelle Verzeichnis.

Die Unterscheidung hilft bei Störungen. Eine Zeitüberschreitung bei einer Adresse aus einem Netz dokumentiert eine fehlgeschlagene Beobachtung. Die Zeitüberschreitung allein beweist nicht, dass jede Instanz der Kennung ausgefallen ist. Die Beobachtung sagt noch weniger über alle anderen Root-Kennungen aus.

Notieren Sie bei einer Untersuchung das Quellnetz und den Beobachtungszeitpunkt neben der Zieladresse. Vergleichen Sie Ergebnisse aus einem weiteren zugelassenen Netz, bevor Sie einen globalen Ausfall melden. Eine geänderte Antwortzeit braucht Kontext. Die Messung beweist keinen Wechsel des nächstgelegenen physischen Rechners.

Ein Büronetz könnte den freigegebenen rekursiven Resolver zulassen, aber direkten externen DNS-Verkehr sperren. In dieser hypothetischen Umgebung kann eine direkte Root-Abfrage scheitern, während die normale Namensauflösung funktioniert. Die nächste Untersuchung betrifft dann die Netzrichtlinie und den erlaubten Abfrageweg.

Das Root-System besitzt außerdem einen gemeinsamen Namensraum. Verteilte Instanzen erzeugen keine unabhängigen Versionen von .com, zwischen denen Kunden wählen. Die Betreiber verpflichten sich, den globalen IANA-Root-Namensraum mit vollständigen, unveränderten DNS-Daten bereitzustellen. Die FAQ nennt diese Verpflichtung.

Domaininhaber sollten Root-Kennungen deshalb nicht wie konkurrierende DNS-Hosting-Angebote behandeln. Die Auswahl eines autoritativen Anbieters für example.com verändert eine andere Hierarchieebene. Die Auswahl eines rekursiven Resolvers verändert den Dienst, der Abfragen für Clients ausführt.

Zwischenspeicher und minimierte Abfragen verändern den Abfrageweg

Ein Resolver beginnt nicht jede Namensauflösung an der Wurzel. Der Auflösungsalgorithmus prüft zuerst verfügbare lokale Informationen und kann zwischengespeicherte Delegierungen wiederverwenden. Zwischengespeicherte Einträge haben eine begrenzte Gültigkeitsdauer, die TTL. RFC 1034 beschreibt den Zwischenspeicher und den Resolver-Algorithmus.

Angenommen, ein Resolver kennt bereits die .com-Server, aber nicht die Antwort für www.example.com. Der Resolver kann mit der bekannten Delegierung beginnen. Hat der Resolver bereits eine brauchbare endgültige Antwort gespeichert, kann der Resolver die Antwort ohne erneute Delegierungsabfragen liefern.

Die logische Hierarchie unterscheidet sich deshalb von den Paketen einer einzelnen Anfrage. Ein Diagramm mit Root-, TLD- und Domainservern erklärt die Zuständigkeiten. Das Diagramm beweist nicht, dass jeder Besuch Pakete an jede Ebene sendet.

Ein Resolver braucht dennoch eine Startkonfiguration. Root Hints liefern Root-Server-Namen und -Adressen, oft zusammen mit der Resolver-Software. IANA bietet Root Hints, die Root-Zone und Vertrauensankerdateien als getrennte Ressourcen an. Die Seite „Root Files“ erklärt den jeweiligen Zweck.

Priming aktualisiert die Informationen des Resolvers über die Root-Server. Eine Priming-Abfrage fordert NS-Einträge für . an. Die Antwort liefert den Root-Server-Satz und Adressinformationen. Der Resolver führt Priming bei Bedarf aus, etwa beim Start mit leerem Zwischenspeicher oder nach Ablauf des Root-NS-Satzes. RFC 9609 legt das Priming-Verhalten fest.

Root Hints liefern somit Startinformationen. Root Hints ersetzen die Ermittlung aktueller Informationen nicht dauerhaft. Adressen können sich ändern. RFC 9609 erklärt, warum Resolver Änderungen verarbeiten und bei ausbleibender Priming-Antwort ein anderes konfiguriertes Ziel versuchen müssen. Betreiber sollten das Aktualisierungsverfahren ihrer Resolver-Software verwenden.

Die Minimierung von Abfragenamen begrenzt, wie viel des angefragten Namens ein vorgelagerter Server sieht. Ein minimierender Resolver kann die Root-Zone nach com. fragen, während der Resolver www.example.com. auflöst. Der Resolver muss an der Wurzel nicht den vollständigen ursprünglichen Namen offenlegen. RFC 9156 erläutert das Verfahren.

Die Minimierung begrenzt unnötige Offenlegung gegenüber autoritativen Servern. Der rekursive Resolver, der die Client-Anfrage bearbeitet, sieht weiterhin die vollständige Anfrage. Das Protokoll braucht außerdem Implementierungsgrenzen und Kompatibilitätsverhalten. Eine idealisierte Paketfolge beschreibt nicht jede Resolver-Konfiguration.

Diese Einzelheiten verändern Datenschutz- und Leistungsfragen. Prüfen Sie, welcher Resolver die ursprüngliche Anfrage erhält, welche Delegierungen der Resolver bereits kennt und ob der Resolver vorgelagerte Namen minimiert. Eine Root-Server-Verkehrszahl belegt keinen vollständigen Browserverlauf.

Bewahren Sie bei der Fehlersuche den Zustand des Zwischenspeichers möglichst auf. Das Leeren des Zwischenspeichers verändert die Untersuchungsbedingungen. Dokumentieren Sie den ersten Fehler vor einem Resolver-Neustart oder dem Löschen nützlicher Informationen. Eine spätere erfolgreiche Abfrage kann sonst verdecken, ob der ursprüngliche Fehler die Ermittlung, gespeicherte Daten oder eine andere Ebene betraf.

DNSSEC und Diagnose beantworten unterschiedliche Fragen

DNSSEC (Domain Name System Security Extensions) ergänzt Herkunftsauthentifizierung und Integritätsprüfungen für DNS-Daten. Ein validierender Resolver beginnt mit einem konfigurierten Vertrauensanker und baut eine Authentifizierungskette auf. DNSSEC verschlüsselt keine DNS-Fragen und garantiert keine Dienstverfügbarkeit. RFC 4033 erläutert die Dienste und Grenzen.

Der Root Key Signing Key liefert einen Vertrauensanker für die Root-Validierung. IANA veröffentlicht Vertrauensankerinformationen und Hinweise zum Schlüsselwechsel für Resolver-Betreiber. Betreiber sollten aktuelle Hinweise befolgen, statt einen alten Schlüsselwert aus einer Anleitung zu kopieren. IANA pflegt diese Betriebsinformationen.

Ein Root-Vertrauensanker betrifft die Echtheit von DNS-Daten. Der Vertrauensanker benennt nicht den rechtlichen Domaininhaber und gewährt keine Kontrolle über ein Registrarkonto. Eine erfolgreiche Validierung beantwortet eine engere technische Frage als ein Registrierungsdokument oder eine Kontoberechtigung.

Begrenzen Sie Diagnosefragen ebenso genau. Prüfen Sie zuerst die normale Namensauflösung über den freigegebenen Resolver. Untersuchen Sie anschließend die Delegierung getrennt, wenn die Befunde auf ein Ermittlungsproblem hinweisen. Betreiber mit installiertem dig können den Root-NS-Satz mit folgender rein lesenden Abfrage untersuchen:

dig . NS

Der Befehl fragt den konfigurierten Resolver. Die Antwort kann aus dem Zwischenspeicher des Resolvers stammen. Eine erfolgreiche Antwort beweist deshalb keinen neuen direkten Austausch mit einer Root-Instanz. Speichern Sie Antwortflags, TTLs, Serverinformationen und Zeitstempel vor einer Schlussfolgerung.

Direkte Abfragen unterscheiden Root-Antworten von TLD-Verweisen

Verwenden Sie direkte Abfragen nur, wenn die Netzrichtlinie externen DNS-Verkehr erlaubt. Die folgende Adresse gehört laut IANA-Root-Server-Liste zu A-root. Die Adresse wählt einen Dienstendpunkt, keinen einzelnen physischen Rechner.

Fragen Sie den Endpunkt zuerst nach den eigenen NS-Einträgen der Root-Zone:

dig @198.41.0.4 . NS +norecurse

Fragen Sie denselben Endpunkt anschließend nach der .com-Delegierung:

dig @198.41.0.4 com. NS +norecurse

Das Argument @ wählt den Server. Die Option +norecurse löscht das Flag für die gewünschte Rekursion. BIND dokumentiert die Option und die Abfragesyntax. Bewahren Sie die vollständige Ausgabe einschließlich Antwortabschnitten und Flags auf.

Die Tabelle beschreibt erwartetes Protokollverhalten, keine aufgezeichnete Befehlsausgabe. Tatsächliche Ergebnisse hängen von der Erreichbarkeit und dem antwortenden Dienst ab.

Das Flag aa bedeutet eine autoritative Antwort für den abgefragten Namen. Ein Root-Server kann für . autoritativ antworten und eine .com-Frage weiterverweisen. RFC 1035 definiert AA. Die Überschrift AUTHORITY benennt einen Antwortabschnitt. Die Überschrift beweist nicht, dass die Antwort das Flag aa enthält.

Lesen Sie neben den Abschnittszahlen auch den Antwortstatus. Ein erfolgreicher Verweis kann NOERROR und einen leeren ANSWER-Abschnitt haben. Der leere Abschnitt allein bedeutet nicht NXDOMAIN. RFC 1034 ordnet die NS-Einträge eines Verweises dem Authority-Abschnitt zu. RFC 1035 definiert den Antwortcode für einen Namensfehler.

Eine Zeitüberschreitung liefert keinen DNS-Antwortstatus. Vergleichen Sie die Zeitüberschreitung mit dem Ergebnis des freigegebenen Resolvers und der Netzrichtlinie, bevor Sie einen Root-Dienst-Ausfall melden.

Eine iterative Ablaufverfolgung folgt dem Delegierungsweg

Verwenden Sie für eine getrennte Delegierungsuntersuchung einen reservierten Beispielnamen:

dig +trace example.com. A

BIND dokumentiert +trace als iterative Ablaufverfolgung ab der Wurzel. Das Werkzeug folgt Verweisen und zeigt die Antworten entlang des Weges. Die Ablaufverfolgung zeigt den Austausch des Diagnosewerkzeugs, keine Wiederholung der früheren Browser-Abfrage. Lesen Sie das BIND-Handbuch zu dig.

Untersuchen Sie den Haltepunkt, bevor Sie die Konfiguration ändern. Eine Ablaufverfolgung bis zu den autoritativen Domainservern hat den Root-Verweis bereits passiert. Ein Fehler beim endgültigen Eintrag erfordert eine Untersuchung auf dieser Ebene. Wenn die Ablaufverfolgung nicht startet, vergleichen Sie Netzrichtlinie und normale rekursive Namensauflösung.

Ein hypothetischer Störungsbericht könnte lauten: „Der freigegebene Resolver antwortete, aber die direkte iterative Ablaufverfolgung aus dem Büronetz überschritt die Wartezeit.“ Die Aussage bewahrt die Befunde. „Die Root-Server sind ausgefallen“ behauptet mehr, als die beiden Beobachtungen belegen.

Ein hilfreicher Supportbericht enthält neben dem Fehler auch einen erfolgreichen Vergleich. Geben Sie an, ob derselbe Name über den freigegebenen Resolver auflösbar ist. Geben Sie außerdem an, ob andere Namen ebenfalls scheitern. Trennen Sie Beobachtungen aus unterschiedlichen Netzen, denn unterschiedliche Quellnetze können unterschiedliche Wege nehmen. Diese Angaben helfen dem Support, die Bedingungen ohne Annahme eines globalen Ausfalls nachzustellen.

Die Wiederherstellung sollte zum bestätigten Fehler passen. Korrigieren Sie einen Domain-Eintrag beim autoritativen DNS-Anbieter. Untersuchen Sie die übergeordnete Delegierung, wenn die übergeordnete Zone unerwartete Server nennt. Untersuchen Sie die Resolver-Konfiguration, wenn Priming oder Validierung trotz erreichbarer autoritativer Dienste scheitert. Bewahren Sie vor jeder Änderung die ursprünglichen Befunde auf.

Root-Server bilden eine wichtige gemeinsame Ermittlungsebene. Praktische Fehlersuche gelingt besser, wenn jede Beobachtung die geprüfte Zuständigkeit benennt. Ein Root-Verweis, eine zwischengespeicherte Antwort, eine validierte Signatur und eine funktionierende Website belegen jeweils ein anderes Ergebnis.

Die Quellen liefern weitere Informationen

• IANA, Root Zone Management, Einleitung und Delegierungszuständigkeiten. Abgerufen am 21.10.2026.
• IANA, Root Name Servers, Einleitung und Tabelle der benannten Autoritäten. Abgerufen am 21.10.2026.
• Root Server Technical Operations Association, FAQ, Fragen zu Kennungen, Instanzen, Zwischenspeicherung und Namensraum. Abgerufen am 21.10.2026.
• Root Server Technical Operations Association, Root-Server-Verzeichnis, Karte und Betreiberlisten. Abgerufen am 21.10.2026.
• IETF, RFC 9499, Abschnitt 6, Resolver, autoritative Server, Anycast und Instanzen. Abgerufen am 21.10.2026.
• IETF, RFC 1034, Abschnitte 4.3.2 und 5.3.2–5.3.3, Verweise und zwischengespeicherte Namensauflösung. Abgerufen am 21.10.2026.
• IANA, Root Files, Root-Zonendateien. Abgerufen am 21.10.2026.
• IETF, RFC 9609, Abschnitte 2–3, Root Hints und Priming-Abfragen. Abgerufen am 21.10.2026.
• IETF, RFC 9156, Abschnitte 1–3, Minimierung und Zwischenspeicherverhalten. Abgerufen am 21.10.2026.
• IETF, RFC 4033, Abschnitte 2–4, Vertrauensanker und DNSSEC-Grenzen. Abgerufen am 21.10.2026.
• IANA, Trust Anchors and Rollovers, Einleitung und Vertrauensanker der Root-Zone. Abgerufen am 21.10.2026.
• Internet Systems Consortium, BIND-Handbuch zu dig, Abfragesyntax und +trace. Abgerufen am 21.10.2026.
• IETF, RFC 1035, Abschnitt 4.1.1, AA-Flag und Antwortcodes. Abgerufen am 21.10.2026.
• Internet Systems Consortium, Stabiles BIND-Handbuch zu dig, Serverauswahl und +norecurse. Abgerufen am 21.10.2026.