Was ist DNS? Funktionsweise des Domain Name Systems erklärt

Jedes Mal, wenn du eine Webadresse in den Browser tippst, passiert im Hintergrund eine Übersetzung: Aus dem Namen dns-pruefen.de wird eine numerische IP-Adresse, die ein Server tatsächlich versteht. Genau das ist die Aufgabe des Domain Name Systems. Dieser Artikel erklärt, wie DNS funktioniert, welche Server beteiligt sind und warum kein Dienst im Netz ohne diese Übersetzung auskommt.

DNS als Telefonbuch des Internets

Computer kommunizieren über IP-Adressen. Eine IPv4-Adresse sieht aus wie 93.184.216.34, eine IPv6-Adresse wie 2606:2800:220:1:248:1893:25c8:1946. Solche Zahlenketten kann sich niemand merken, und sie ändern sich auch von Zeit zu Zeit. Namen wie example.de bleiben dagegen stabil und sind leicht zu behalten.

Das DNS schiebt sich als Übersetzungsschicht dazwischen. Es funktioniert wie ein gigantisches, weltweit verteiltes Telefonbuch: Du nennst einen Namen, das System liefert die passende Adresse. Der entscheidende Unterschied zu einem echten Telefonbuch ist, dass dieses Verzeichnis nicht an einem Ort liegt, sondern auf Millionen Servern verteilt und hierarchisch organisiert ist.

Der Ablauf einer DNS-Auflösung

Wenn dein Gerät einen Namen auflösen will, läuft eine Kette von Anfragen ab. Die meisten Schritte bekommst du nie zu Gesicht, weil sie in Millisekunden passieren. Im Detail sieht der Weg so aus.

Zuerst meldet sich der Stub-Resolver. Das ist eine kleine Komponente im Betriebssystem deines Geräts. Sie nimmt die Anfrage der Anwendung entgegen und reicht sie an einen rekursiven Resolver weiter, meist den deines Internetanbieters oder einen öffentlichen wie 1.1.1.1 oder 8.8.8.8.

Der rekursive Resolver übernimmt die eigentliche Arbeit. Hat er die Antwort noch im Cache, liefert er sie sofort. Andernfalls beginnt er die Suche von oben. Er fragt zuerst einen Root-Server. Die Root-Server kennen nicht die Adresse der gesuchten Domain, aber sie wissen, welcher Server für die jeweilige Top-Level-Domain zuständig ist, also etwa für .de oder .com.

Mit dieser Information fragt der Resolver den TLD-Server. Dieser verwaltet alle Domains unter seiner Endung und verweist auf den autoritativen Nameserver der konkreten Domain. Im letzten Schritt fragt der Resolver den autoritativen Nameserver. Dieser hält die echten Daten der Zone und liefert die gesuchte IP-Adresse zurück.

Die folgende Tabelle fasst zusammen, wer in dieser Kette welche Aufgabe übernimmt.

Beteiligter	Aufgabe
Stub-Resolver	Liegt im Betriebssystem, nimmt die Anfrage der Anwendung entgegen und reicht sie weiter
Rekursiver Resolver	Führt die komplette Suche durch, fragt alle nötigen Server und cacht Ergebnisse
Root-Server	Verweist auf den zuständigen TLD-Server der gesuchten Endung
TLD-Server	Verwaltet eine Endung wie .de und verweist auf den autoritativen Nameserver der Domain
Autoritativer Nameserver	Hält die echten Zonendaten und liefert die endgültige Antwort, etwa die IP-Adresse

Caching und TTL: Warum nicht jede Anfrage durchläuft

Würde jede einzelne Namensauflösung die volle Kette durchlaufen, wäre das System langsam und die Root- und TLD-Server überlastet. Deshalb speichert jeder rekursive Resolver Antworten zwischen. Wie lange er das tun darf, legt die TTL (Time to Live) jedes Eintrags fest. Sie ist ein Wert in Sekunden, der zur Antwort mitgeliefert wird.

Ist die TTL etwa auf 3600 gesetzt, behält der Resolver die Antwort eine Stunde lang. Innerhalb dieser Zeit beantwortet er identische Anfragen direkt aus dem Cache, ohne den autoritativen Server erneut zu kontaktieren. Erst nach Ablauf der TTL fragt er wieder nach. Dieses Caching ist der Grund, warum die meisten Auflösungen in wenigen Millisekunden erledigt sind.

Die TTL ist der Kompromiss zwischen Geschwindigkeit und Aktualität: kurze Werte sorgen für schnelle Updates, lange Werte für weniger Last.

Die Kehrseite zeigt sich beim Umzug einer Domain. Änderst du eine IP-Adresse, sehen Resolver mit gecachter Antwort noch die alte Adresse, bis ihre TTL abläuft. Diesen Effekt nennt man Propagation. Wie du ihn planst, beschreibt der Beitrag zu DNS-Propagation und TTL im Detail.

Ein zweiter Caching-Ort, den viele übersehen, ist das eigene Gerät. Auch Betriebssystem und Browser halten Antworten kurz vor. Deshalb kann es vorkommen, dass eine Domain bei einem Kollegen schon funktioniert, bei dir aber noch nicht: Dein lokaler Cache zeigt eine ältere Antwort. Ein Neustart des Resolvers oder das Leeren des lokalen DNS-Caches löst solche Diskrepanzen meist sofort auf.

Wichtig ist auch die Unterscheidung zwischen autoritativen und nicht-autoritativen Antworten. Eine autoritative Antwort stammt direkt vom zuständigen Nameserver der Zone und gilt als verbindliche Quelle. Eine nicht-autoritative Antwort kommt aus dem Cache eines rekursiven Resolvers. Sie ist im Normalfall korrekt, kann aber kurz nach einer Änderung veraltet sein, solange die TTL noch läuft. Wer eine Änderung kontrollieren will, sollte das im Hinterkopf behalten.

DNS-over-HTTPS: Auflösung verschlüsselt

Klassisches DNS überträgt seine Anfragen unverschlüsselt über Port 53. Jeder im Netzwerkpfad kann mitlesen, welche Namen du auflöst, und im schlimmsten Fall sogar Antworten manipulieren. Genau hier setzt DNS-over-HTTPS (DoH) an. Es verpackt die DNS-Anfrage in eine normale HTTPS-Verbindung über Port 443. Damit ist der Inhalt verschlüsselt und für Außenstehende von gewöhnlichem Web-Verkehr kaum zu unterscheiden.

Warum DNS für Web und Mail zentral ist

DNS ist nicht nur für den Webseiten-Aufruf da. Für das Web liefert der A-Eintrag die IPv4-Adresse und der AAAA-Eintrag die IPv6-Adresse, unter der ein Server erreichbar ist. Funktioniert dieser Teil nicht, lädt keine Seite, selbst wenn der Server einwandfrei läuft. Wie du einen A-Eintrag prüfst, zeigt die Anleitung zum A-Record.

Mindestens genauso wichtig ist DNS für E-Mail. Welcher Server die Mails einer Domain annimmt, steht im MX-Eintrag. Ohne korrekten MX-Eintrag kommt keine Mail an. Darüber hinaus liegen die Sicherheitsmechanismen gegen Spam und Spoofing in TXT-Einträgen: SPF, DKIM und DMARC. Wie diese zusammenspielen, erklärt der Beitrag zu E-Mail-DNS mit SPF, DKIM und DMARC.

Genau dafür gibt es einen DNS-Lookup. Mit dem kostenlosen DNS-Check auf dieser Seite fragst du per DNS-over-HTTPS alle Record-Typen einer Domain ab, nach Typ sortiert und mit TTL. So siehst du in Sekunden, welche Einträge eine Domain wirklich liefert, ohne ein Kommandozeilenwerkzeug wie nslookup oder dig installieren zu müssen.

Vom Namen zur Adresse: Das Wichtigste im Rückblick

DNS übersetzt Namen in IP-Adressen und ist damit die unsichtbare Grundlage fast jeder Internetnutzung. Eine Anfrage wandert vom Stub-Resolver über den rekursiven Resolver zu Root-, TLD- und autoritativem Nameserver, und Caching mit TTL hält das System schnell. Welche Record-Typen dabei welche Aufgabe übernehmen, vertieft der nächste Beitrag zu den DNS-Record-Typen. Wenn du wissen willst, was eine konkrete Domain gerade liefert, starte einfach einen DNS-Lookup und sieh dir die Einträge direkt an.