Wie funktioniert DNS-Auflösung? Der Weg von den Root-Servern bis zum autoritativen Nameserver

DNS-Auflösung ist der Vorgang, bei dem ein Domainname wie example.com in eine IP-Adresse übersetzt wird, mit der sich ein Computer verbinden kann. Dabei wird eine Kette von Servern durchlaufen – dein rekursiver Resolver, der Root-Server, der TLD-Server und schließlich der autoritative Nameserver der Domain –, bis einer davon den tatsächlichen Eintrag zurückliefert. Wer diese Kette versteht, findet am schnellsten heraus, warum eine Website „nicht auflöst“ oder auf das falsche Ziel zeigt.

Rekursiver Resolver vs. autoritativer Nameserver

Diese beiden Rollen werden ständig verwechselt, doch für die Fehlersuche ist der Unterschied entscheidend.

• Rekursiver Resolver – der Server, mit dem dein Gerät tatsächlich kommuniziert (der Resolver deines Internetanbieters oder ein öffentlicher wie Googles 8.8.8.8 oder Cloudflares 1.1.1.1). Er übernimmt für dich die Arbeit, die Antwort zu finden, und speichert das Ergebnis im Cache.
• Autoritativer Nameserver – der Server, der die eigentlichen DNS-Einträge einer Zone vorhält (z. B. die A-, MX- und TXT-Einträge deiner Domain). Er ist die maßgebliche Quelle und fragt nie bei jemand anderem nach.

Dein Laptop oder Smartphone nutzt einen schlanken Stub-Resolver, der diesen Weg nicht selbst abläuft – er leitet die Anfrage lediglich an einen rekursiven Resolver weiter und wartet auf die Antwort.

Der Weg Root → TLD → autoritativer Nameserver

Hat ein rekursiver Resolver für einen Namen nichts im Cache, führt er eine iterative Abfrage durch und folgt dabei Verweisen (Referrals) die DNS-Hierarchie hinab:

1. Root-Server. Der Resolver fragt eine der 13 Root-Server-Kennungen (a.root-servers.net bis m.root-servers.net, jeweils per Anycast auf viele physische Standorte verteilt). Der Root-Server weiß nicht, wo example.com liegt, kennt aber die Server, die für .com zuständig sind, und gibt diesen Verweis zurück.
2. TLD-Server. Der Resolver fragt einen .com-TLD-Server. Auch der kennt die IP von example.com nicht, weiß aber, welche Nameserver für diese Domain autoritativ sind, und verweist den Resolver dorthin.
3. Autoritative Server. Der Resolver fragt direkt beim autoritativen Nameserver für example.com an. Dieser Server hält den tatsächlichen Eintrag vor und liefert ihn zurück – kein Raten mehr.

Der rekursive Resolver gibt diese Antwort anschließend an dein Gerät zurück und speichert sie im Cache für das nächste Mal – wie lange, bestimmt die TTL (Time to Live) des Eintrags.

Note„Iterativ“ (von Server zu Server, wobei jeder auf den nächsten verweist) und „rekursiv“ (der Client bittet einen Server, die gesamte Arbeit zu erledigen) beschreiben denselben Gesamtprozess aus zwei Blickwinkeln – dein Resolver erledigt die rekursive Arbeit für dich, indem er eine Reihe iterativer Abfragen stellt.

Warum Caching und TTL wichtig sind

Jeder DNS-Eintrag hat eine TTL, einen Wert in Sekunden, der Resolvern mitteilt, wie lange sie ihn zwischenspeichern dürfen, bevor sie erneut nachfragen. Eine niedrige TTL (z. B. 300 Sekunden) sorgt dafür, dass sich Änderungen schnell verbreiten, erzeugt aber mehr Abfrageverkehr; eine hohe TTL (z. B. 86400 Sekunden / 24 Stunden) reduziert die Last, bedeutet aber, dass ein veralteter Eintrag nach einer Änderung noch einen ganzen Tag in Caches verbleiben kann.

Deshalb scheint eine missglückte Migration auch nur „teilweise“ zu funktionieren – manche Resolver halten noch die alte Antwort im Cache, während andere bereits die neue übernommen haben. Wenn du mitten in einer Migration steckst oder die Propagation debuggst, frag verschiedene Resolver direkt ab und vergleiche die Antworten, statt dich auf den Cache deines Browsers zu verlassen.

Auch Antworten der Art „Eintrag existiert nicht“ werden zwischengespeichert – das nennt sich Negative Caching und richtet sich nach der TTL im SOA-Eintrag der Zone. Ein NXDOMAIN kann also ebenfalls eine Weile bestehen bleiben.

Was eine DNS-Abfrage tatsächlich enthält

DNS-Nachrichten haben eine feste Struktur: einen Header sowie die Abschnitte Question, Answer, Authority und Additional. Standardabfragen laufen über UDP-Port 53 und waren ursprünglich auf 512 Byte begrenzt; moderne Resolver nutzen EDNS0, um größere Puffergrößen anzukündigen und unnötige Fallbacks zu vermeiden. Ist eine Antwort zu groß oder geht es um Vorgänge wie Zonentransfers, weicht DNS auf TCP-Port 53 aus.

Eine typische dig-Ausgabe für einen aufgelösten A-Eintrag sieht so aus:

;; ANSWER SECTION:
example.com.		300	IN	A	93.184.216.34

Die 300 ist die TTL in Sekunden, IN die Klasse (Internet) und A der Eintragstyp. Dieselbe Abfrage kannst du direkt im Browser mit dem DNS-Lookup-Tool durchführen – praktisch, um genau zu prüfen, was ein autoritativer Server gerade ausliefert, unabhängig von deinem lokalen Cache.

Verschlüsseltes DNS: DoH und DoT

Standard-DNS-Abfragen werden im Klartext übertragen, sodass Netzwerke (und jeder auf dem Übertragungsweg) sehen können, welche Domains du auflöst. Zwei neuere Übertragungsverfahren setzen hier an:

• DNS over TLS (DoT) – DNS in TLS verpackt auf TCP-Port 853.
• DNS over HTTPS (DoH) – DNS getunnelt in einer HTTPS-Verbindung, meist auf Port 443, wodurch es schwerer von normalem Webverkehr zu unterscheiden ist.

Beide schützen die Abfrage auf dem Weg zwischen deinem Gerät und dem Resolver, ändern aber nichts am oben beschriebenen Weg Root→TLD→autoritativ – die Verschlüsselung findet auf der Transportschicht statt, nicht in der Auflösungslogik.

DNSSEC: Authentizität ohne Verschlüsselung

Die DNS Security Extensions (DNSSEC) fügen kryptografische Signaturen hinzu (RRSIG-, DNSKEY- und DS-Einträge), damit ein Resolver prüfen kann, ob eine Antwort tatsächlich von der autoritativen Quelle der Zone stammt und unterwegs nicht manipuliert wurde. Wichtig: DNSSEC sorgt für Authentizität, nicht für Vertraulichkeit – jeder kann die Abfrage weiterhin sehen; DNSSEC verhindert lediglich, dass jemand eine gefälschte Antwort unterschiebt.

Häufige DNS-Fehler und ihre Ursachen

Wenn du DNS über mehrere Registrare und Anbieter hinweg verwaltest, vervielfachen sich diese Symptome – eine Delegation, die bei einem Registrar korrekt, bei einem anderen aber veraltet ist, ist eine klassische Quelle für Support-Tickets nach dem Motto „bei mir funktioniert’s“.

Wenn du die DNS-Verwaltung für mehrere Domains bündeln möchtest, damit du Propagationsproblemen nicht über ein Dutzend Dashboards hinterherjagen musst, bietet dir die DNS-Funktion von InfraNest einen zentralen Ort, um Zonen, TTLs und Einträge bei allen Anbietern zu verwalten.

Probier es selbst aus

Führe mit dem DNS-Lookup-Tool eine Live-Abfrage gegen autoritative Server durch und sieh genau, was gerade ausgeliefert wird – ohne den Umweg über das, was dein lokaler Resolver im Cache hat.