Was ist DNS und wie funktioniert es wirklich?

Jedes Gerät im Internet ist über eine numerische Adresse erreichbar – eine IP-Adresse. Niemand möchte sich 172.64.80.1 merken, also nutzen wir Namen: example.com. DNS, das Domain Name System, ist der Verzeichnisdienst, der den eingegebenen Namen in die Adresse übersetzt, die ein Computer tatsächlich braucht. Man nimmt es leicht als selbstverständlich hin, gerade weil es im Hintergrund fast jeder Netzwerkanfrage so zuverlässig arbeitet.

Der Lookup, Schritt für Schritt

Besuchen Sie eine Domain zum ersten Mal, kennt Ihr Gerät ihre IP-Adresse noch nicht. Es bittet einen Resolver – meist den Ihres Internetanbieters oder eines öffentlichen Dienstes wie Cloudflare oder Google – um die Auskunft. Auch dieser Resolver kennt die Antwort nicht zwingend, also arbeitet er sich durch eine Autoritätskette:

1. Ein Root-Server verweist ihn an die Server, die für die Top-Level-Domain der Domain zuständig sind (.com, .org, .io und so weiter).
2. Der TLD-Server verweist ihn an die autoritativen Nameserver der konkreten Domain – die Server, die der Inhaber der Domain tatsächlich konfiguriert hat.
3. Der autoritative Nameserver liefert den eigentlichen Record: die IP-Adresse (oder Adressen), auf die die Domain aktuell zeigt.

Diese ganze Kette ist meist in weit unter einer Sekunde abgeschlossen, und das Ergebnis wird anschließend gecacht, damit es nicht bei jeder einzelnen Anfrage wiederholt werden muss – mehr dazu im Abschnitt zur TTL weiter unten.

Ein konkreter Ablauf von Anfang bis Ende

Angenommen, ein Resolver mit leerem Cache soll blog.example.com auflösen. Zuerst fragt er einen Root-Server, der die Antwort nicht kennt, aber weiß, wer .com betreut, und den Resolver dorthin verweist. Auch der .com-TLD-Server kennt die endgültige Antwort nicht, weiß aber, an welche Nameserver example.com selbst delegiert – sagen wir ns1.dnshost.com und ns2.dnshost.com –, und verweist den Resolver stattdessen dorthin. Erst jetzt fragt der Resolver einen Server, der die Records von example.com tatsächlich hält, und dieser – der autoritative – antwortet mit der echten Antwort: einem A-Record oder einem CNAME, dem noch ein weiterer Hop folgt. Jeder Schritt dieser Kette ist selbst ein DNS-Lookup, weshalb der allererste (kalte) Lookup einer Domain messbar langsamer ist als jeder folgende, sobald die Zwischenantworten gecacht sind.

Caching geschieht auf mehr Ebenen als nur im Resolver

Der rekursive Resolver ist nicht der einzige Ort, an dem eine Antwort gecacht wird. Die meisten Betriebssysteme führen einen eigenen, kurzlebigen DNS-Cache, und manche Browser haben zusätzlich noch einen separaten. Das ist ein zweiter, häufiger Grund, warum zwei Lookups derselben Domain scheinbar nicht übereinstimmen: Nicht immer liefert ein anderer Resolver eine andere Antwort – manchmal liefert Ihr eigener Rechner eine leicht veraltete lokale Kopie, während eine frische, direkte Abfrage bereits die aktuelle zeigen würde.

Die Record-Typen, denen Sie tatsächlich begegnen

„DNS-Record“ ist nicht ein einzelnes Ding – eine Domain hält mehrere verschiedene Record-Typen nebeneinander, die jeweils eine andere Art von Frage beantworten. Ein Lookup der IP-Adresse einer Domain berührt nur zwei davon; die übrigen dienen ganz anderen Zwecken.

Warum das wichtig ist, auch wenn Sie nie selbst DNS-Records anfassen

Wer diesen Ablauf versteht, versteht viel sonst verwirrendes Verhalten: warum eine DNS-Änderung nicht sofort wirkt, warum eine Domain aus einem Netzwerk einwandfrei und aus einem anderen gar nicht auflöst und warum sich „Die Website ist down“ manchmal als DNS-Problem statt als Serverproblem entpuppt. Tools wie dieses springen direkt zum letzten Schritt – sie fragen einen autoritätsnahen öffentlichen Resolver direkt ab und zeigen Ihnen genau, was er zurückgibt –, sodass Sie den tatsächlichen aktuellen DNS-Zustand einer Domain sehen, ohne zu raten.

Es erklärt auch, warum „DNS“ und „das Internet“ in der alltäglichen Fehlersuche so oft vermischt werden. DNS transportiert Ihren Traffic nicht, hostet Ihre Inhalte nicht und betreibt Ihre Anwendung nicht – es beantwortet immer nur eine Frage: „Auf welche Adresse zeigt dieser Name gerade?“ Alles, was danach geschieht (die eigentliche Verbindung, das Laden der Seite, die API-Antwort), ist ein völlig separates System – und genau deshalb lohnt es sich, DNS als eigenen, unabhängig prüfbaren Schritt zu isolieren, bevor man ein viel größeres Problem vermutet.