Was ist DNS? Namensauflösung einfach erklärt

Wenn du beispiel.de in den Browser tippst, kann dein Rechner mit dem Namen nichts anfangen. Er braucht eine IP-Adresse, um eine Verbindung aufzubauen. Die Übersetzung liefert das Domain Name System, kurz DNS. Es wurde 1987 in RFC 1034 und RFC 1035 beschrieben, und diese beiden Dokumente sind bis heute die Grundlage ^{[1, 2]}. Das DNS ist auf viele Nameserver verteilt, und jeder ist nur für einen kleinen Teil der Namen zuständig ^[1].

Warum Namen und Adressen getrennt sind

Namen sind für Menschen gemacht, Adressen für Netze. Ein Server kann umziehen und eine neue IP-Adresse bekommen, ohne dass sich seine Domain ändert. Du änderst dann nur den Eintrag im DNS, und die Besucher landen nach Ablauf der TTL am neuen Ort. Umgekehrt können viele Namen auf denselben Server zeigen. Auch E-Mail hängt am DNS: Wohin eine Nachricht an info@beispiel.de geht, steht in einem eigenen Eintrag der Domain ^[2].

RFC 1034 beschreibt das System mit drei Bausteinen: einem baumförmigen Namensraum mit den Daten zu jedem Namen, Nameservern, die Teile dieses Baums verwalten, und Resolvern, die im Auftrag von Programmen nachfragen ^[1].

Der Namensbaum: von der Wurzel bis zur Subdomain

Ein Domainname wird von rechts nach links gelesen. Ganz oben steht die Wurzel (Root), die im Namen meist unsichtbar bleibt. Darunter folgen die Endungen wie .de, .com oder .org, darunter die einzelnen Domains wie beispiel.de und darunter Subdomains wie www.beispiel.de oder shop.beispiel.de. Jeder Teil zwischen zwei Punkten heißt Label. Ein Label darf höchstens 63 Zeichen lang sein, der ganze Name höchstens 255 Bytes ^[2].

Die Rootzone enthält nur Verweise auf die Nameserver der Endungen. Die IANA trägt dort die technischen Delegationsdaten ein, legt fest, wer eine Endung verwaltet, und führt die Root Zone Database als verbindliches Verzeichnis aller Top-Level-Domains ^[4]. Ausgeliefert wird die Rootzone von 13 Rootserver-Identitäten mit den Buchstaben A bis M, die 12 unabhängige Organisationen betreiben. Hinter diesen 13 Namen standen am 29.10.2026 laut root-servers.org 2.049 Serverinstanzen weltweit ^[3]. Wie sich Domain und Subdomain unterscheiden, erklärt Was ist eine Domain?.

Wer bei einer Abfrage mitspielt

An einer Namensauflösung sind drei Arten von Programmen beteiligt. Auf deinem Gerät läuft ein sogenannter Stub-Resolver. Er kann selbst kaum etwas und braucht nur eine Liste von Servern, die für ihn die eigentliche Suche übernehmen ^[1]. Diese Server heißen rekursive Resolver. Meist ist das der Resolver deines Internetanbieters oder ein öffentlicher Dienst, den du im Gerät oder Router einträgst. Wie das geht, steht unter DNS-Server am Gerät oder Router ändern.

Die dritte Gruppe sind die autoritativen Nameserver. Sie halten die Daten einer Zone und geben verbindlich Auskunft, etwa die Nameserver der Rootzone, die der Endung .de und die Nameserver, die du für deine eigene Domain eingetragen hast. RFC 1034 unterscheidet zwei Arbeitsweisen: Ein Server kann den Fragenden an einen anderen Server verweisen und ihn selbst weitersuchen lassen, oder er übernimmt die Suche und liefert am Ende eine Antwort oder einen Fehler, aber keine Verweise ^[1]. Autoritative Server arbeiten in der Regel mit Verweisen, der rekursive Resolver sammelt die Antwort zusammen.

Eine Abfrage Schritt für Schritt

Angenommen, dein Browser will www.beispiel.de öffnen und nichts davon liegt schon im Zwischenspeicher. Dann läuft die Suche ungefähr so ab:

1. Der Browser fragt den Stub-Resolver des Betriebssystems nach der Adresse von www.beispiel.de.
2. Der Stub-Resolver schickt die Frage an den eingetragenen rekursiven Resolver.
3. Der Resolver fragt einen Rootserver. Der kennt beispiel.de nicht, nennt aber die Nameserver der Endung .de.
4. Der Resolver fragt einen Nameserver von .de. Dieser verweist auf die Nameserver, die für beispiel.de eingetragen sind.
5. Der Resolver fragt einen dieser Nameserver und erhält die IP-Adresse von www.beispiel.de.
6. Er gibt die Adresse an dein Gerät zurück und legt alle Zwischenergebnisse in seinen Cache.

Die Anfragen laufen standardmäßig über Port 53, per UDP oder TCP ^[2]. Steht unter www.beispiel.de ein CNAME, also ein Aliasname, beginnt die Suche für den Zielnamen von vorn. Was das in der Praxis bedeutet, erklärt der Beitrag CNAME-Eintrag: wann er passt und wann nicht.

Zwischenspeicher und TTL

Würde jeder Resolver bei jedem Seitenaufruf bis zur Wurzel hinaufsteigen, wären die Rootserver und die Server der Endungen ständig überlastet. Deshalb speichern Resolver jede Antwort zwischen. Wie lange, bestimmt die TTL (Time to Live) eines Eintrags: RFC 1034 beschreibt sie als Zeitgrenze, wie lange ein Eintrag im Cache gehalten werden darf ^[1]. Die Nameserver von .de muss ein Resolver deshalb nur selten erfragen, die Adresse einer beliebten Website liegt meist schon bereit.

Der Cache erklärt auch, warum eine Änderung im DNS nicht sofort überall sichtbar ist. Resolver, die den alten Wert noch gespeichert haben, liefern ihn bis zum Ablauf seiner TTL weiter aus. Wie du die TTL vor einem Umzug geschickt herabsetzt, steht unter TTL bei DNS: wie lange Einträge gelten.

Was in einer Zone steht

Die Daten einer Domain liegen in ihrer Zone auf den autoritativen Nameservern. Jeder Eintrag hat einen Namen, einen Typ, eine TTL und einen Wert. RFC 1035 legt unter anderem diese Typen fest ^[2]:

• A für eine IPv4-Adresse
• NS für die zuständigen Nameserver
• CNAME für einen Aliasnamen
• SOA für die Verwaltungsdaten der Zone
• MX für die Mailserver einer Domain
• TXT für freien Text, heute vor allem für SPF und Bestätigungen bei Diensten
• PTR für die Rückwärtsauflösung von Adresse zu Name

Für IPv6-Adressen kam später der Typ AAAA hinzu. Einen Überblick mit Beispielen gibt DNS-Einträge im Überblick. Mit dem DNS-Check kannst du dir die Einträge einer beliebigen Domain im Browser anzeigen lassen.

Wenn die Auflösung scheitert

Nicht jede Anfrage endet mit einer Adresse. Jede DNS-Antwort trägt einen Antwortcode, den RFC 1035 festlegt ^[2]. Zwei Fehler begegnen dir am häufigsten:

• Name Error, in Werkzeugen oft als NXDOMAIN angezeigt: Der zuständige Nameserver sagt verbindlich, dass es den Namen nicht gibt ^[2]. Das passiert bei Tippfehlern, bei Subdomains, die nie angelegt wurden, und bei Domains, die nicht mehr registriert sind.
• Server Failure, oft als SERVFAIL angezeigt: Der Server konnte die Anfrage wegen eines eigenen Problems nicht bearbeiten ^[2]. Eine mögliche Ursache sind nicht erreichbare oder falsch eingerichtete Nameserver der Domain.

Eine leere Antwort ohne Fehler ist etwas anderes. Der Name existiert dann, hat aber keinen Eintrag des gefragten Typs, etwa eine Domain mit IPv4-Adresse, aber ohne AAAA-Eintrag.

Registrar, DNS-Anbieter und Nameserver

Bei einer eigenen Domain sind oft zwei Rollen im Spiel, die leicht verwechselt werden. Der Registrar meldet die Domain bei der Registry an und trägt dort ein, welche Nameserver für sie zuständig sind. Der DNS-Anbieter betreibt diese Nameserver und verwaltet die Einträge der Zone. Häufig ist beides derselbe Hoster. Du kannst die Zone aber auch bei einem anderen Dienst führen, etwa bei einem CDN. Dann trägst du beim Registrar dessen Nameserver ein. Wie das funktioniert, steht unter Nameserver ändern.

Wo das klassische DNS an Grenzen stößt

Das DNS von 1987 kannte weder Verschlüsselung noch Signaturen. Eine Anfrage über Port 53 kann jeder mitlesen, der den Netzverkehr sieht, und ein Resolver kann nicht erkennen, ob eine Antwort unterwegs verändert wurde. Für beides gibt es heute Erweiterungen:

• DNSSEC versieht die Einträge einer Zone mit Signaturen, die ein Resolver prüfen kann. Mehr dazu unter DNSSEC: signierte DNS-Antworten.
• DNS over HTTPS und DNS over TLS verschlüsseln den Weg zwischen deinem Gerät und dem Resolver. Die Unterschiede erklärt DNS over HTTPS und DNS over TLS.

Beide lösen verschiedene Probleme. DNSSEC schützt vor gefälschten Antworten, verbirgt aber nicht, welche Namen du abfragst. Verschlüsseltes DNS verbirgt die Anfrage vor Mitlesern im Netz, der Resolver selbst sieht sie trotzdem.

Die Fehlersuche bei einer nicht erreichbaren Seite beschreibt Website nicht erreichbar: Fehlersuche Schritt für Schritt. Alle Ratgeber zum Thema findest du im Bereich DNS: Namensauflösung und Einträge.

1. Gesetz RFC 1034: Domain Names, Concepts and Facilities. IETF, P. Mockapetris. Stand November 1987. abgerufen am 29.10.2026
2. Gesetz RFC 1035: Domain Names, Implementation and Specification. IETF, P. Mockapetris. Stand November 1987. abgerufen am 29.10.2026
3. Organisation Root Server Technical Operations. Root Server Operators. Stand 29.10.2026. abgerufen am 29.10.2026
4. Organisation Root Zone Management und Root Zone Database. IANA. Stand 2026. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.