DNS verstehen: Wie aus Namen IP-Adressen werden

Du tippst www.example.com in den Browser, und die Seite erscheint. Dabei weiß dein Rechner mit diesem Namen nichts anzufangen. Für das Senden von Paketen braucht er eine IP-Adresse, wie sie im Beitrag MAC-Adresse und IP-Adresse beschrieben ist. Irgendwer muss also den Namen in eine Zahl übersetzen.

Das erledigt das Domain Name System, kurz DNS. Man vergleicht es gern mit einem Telefonbuch: Du suchst einen Namen und bekommst eine Nummer. Nur dass dieses Telefonbuch weltweit verteilt ist, sehr viele Einträge hat und in Bruchteilen einer Sekunde antwortet. Ohne DNS müsstest du dir für jede Webseite eine Zahlenfolge merken.

Was ist DNS?

DNS ist ein hierarchisches, verteiltes Namenssystem. „Verteilt“ heißt: Es gibt keine einzelne große Liste, sondern viele Server, von denen jeder nur einen Teil der Einträge kennt. „Hierarchisch“ heißt: Die Namen sind wie ein Baum aufgebaut, und jede Ebene weiß, an wen sie weiterverweisen kann.

DNS arbeitet auf der Anwendungsschicht und nutzt meist UDP Port 53. Für größere Antworten und für den Abgleich zwischen Servern kommt TCP auf Port 53 zum Einsatz. Das Prinzip kennst du aus dem Beitrag TCP/IP-Modell erklärt. Seine Hauptaufgabe: Namen in IP-Adressen übersetzen. Zusätzlich lässt sich auch die Gegenrichtung abfragen, von der IP-Adresse zum Namen.

Wie ein Domainname aufgebaut ist

Ein Name besteht aus mehreren Teilen, den Labels, die durch Punkte getrennt sind. Von rechts nach links wird er spezifischer:

www . example . com .
 ↑       ↑       ↑   ↑
 |       |       |   Root (steht meist unsichtbar am Ende)
 |       |       Top-Level-Domain (TLD)
 |       Second-Level-Domain
 Subdomain (Hostname)

Teil	Beispiel	Bedeutung
Root	(leer, ein Punkt am Ende)	Die Wurzel des Baums
Top-Level-Domain (TLD)	com, de, org	Oberste Ebene, etwa nach Land oder Art
Second-Level-Domain	example	Der Name, den du registrierst
Subdomain	www, mail	Unterbereich, vom Domaininhaber frei wählbar

Der vollständige Name inklusive Punkt am Ende heißt FQDN (Fully Qualified Domain Name): www.example.com. Ein einzelnes Label darf bis zu 63 Zeichen lang sein, der gesamte Name höchstens 253 Zeichen. Groß- und Kleinschreibung spielt keine Rolle.

Die Server im DNS

An einer Abfrage sind mehrere Arten von Servern beteiligt:

• Resolver (rekursiver Resolver): Der Server, den dein Rechner fragt. Meist ist es der DNS-Server deines Providers, der Heimrouter oder ein öffentlicher Dienst. Er sucht die Antwort für dich zusammen und merkt sie sich.
• Root-Server: Sie kennen die Server für jede Top-Level-Domain. Es gibt 13 Adressgruppen (A bis M), die weltweit von sehr vielen Standorten aus bedient werden.
• TLD-Server: Sie kennen die Server für alle Domains unterhalb ihrer Endung, etwa die für alle .de-Domains.
• Autoritative Server: Sie halten die eigentlichen Einträge einer Domain und geben die verbindliche Antwort. Der Inhaber der Domain legt fest, wo sie stehen.

Der Bereich, für den ein autoritativer Server zuständig ist, heißt Zone.

Ablauf einer Abfrage

Dein Rechner fragt den Resolver nur einmal und wartet auf die fertige Antwort. Das ist eine rekursive Anfrage. Der Resolver dagegen fragt die anderen Server nacheinander, jeweils mit „Wer kennt den Weg?“. Das ist iterativ. Beispiel für www.example.com, wenn der Resolver noch nichts im Cache hat:

1. Dein Rechner fragt den Resolver: „Welche Adresse hat www.example.com?“
2. Der Resolver fragt einen Root-Server. Der kennt die Adresse nicht, nennt aber die Server für die Endung .com.
3. Der Resolver fragt einen TLD-Server für .com. Der nennt die autoritativen Server für example.com.
4. Der Resolver fragt den autoritativen Server von example.com. Der antwortet mit der IP-Adresse von www.example.com.
5. Der Resolver speichert die Antwort im Cache und gibt sie an deinen Rechner zurück.
6. Dein Rechner speichert sie ebenfalls und verbindet sich mit der Adresse.

Caching und TTL

Wenn jede Abfrage diese Kette durchlaufen müsste, wäre das Internet langsam und die Root-Server überlastet. Deshalb merken sich Resolver und Rechner jede Antwort für eine bestimmte Zeit. Der Inhaber der Domain legt sie fest, die TTL (Time to Live) in Sekunden. Bei einer TTL von 3.600 Sekunden gilt die Antwort eine Stunde lang als gültig.

Das hat eine praktische Konsequenz: Änderst du die IP-Adresse hinter einem Namen, sehen manche Nutzer die Änderung sofort, andere erst, wenn ihr Cache abgelaufen ist. Wer einen Umzug plant, senkt die TTL deshalb vorher, damit der Wechsel schnell überall ankommt.

Auf dem eigenen Rechner kannst du den Cache ansehen und leeren. Unter Windows:

ipconfig /displaydns
ipconfig /flushdns

Der erste Befehl zeigt die gespeicherten Einträge an, der zweite löscht sie. Unter Linux mit systemd-resolved leert dieser Befehl den Cache:

resolvectl flush-caches

Das Vorgehen kann sich bei anderen Distributionen unterscheiden.

Die wichtigsten Record-Typen

Die Einträge in einer Zone heißen Resource Records. Es gibt verschiedene Typen für verschiedene Aufgaben:

Typ	Aufgabe	Beispiel
A	Name → IPv4-Adresse	www.example.com → 203.0.113.50
AAAA	Name → IPv6-Adresse	www.example.com → 2001:db8::50
CNAME	Alias, verweist auf einen anderen Namen	shop.example.com → www.example.com
MX	Mailserver der Domain, mit Priorität	example.com → mail.example.com (Priorität 10)
NS	Zuständige Nameserver der Zone	example.com → ns1.example.com
PTR	IP-Adresse → Name (Rückwärtsauflösung)	203.0.113.50 → www.example.com
TXT	Freitext, etwa für Mail-Absenderprüfung oder Domainbestätigung	Prüftexte für SPF oder DKIM
SOA	Verwaltungsangaben der Zone (Hauptserver, Seriennummer, Zeiten)	Eintrag am Anfang jeder Zone

Beim CNAME gelten Einschränkungen: Ein Name mit CNAME darf keine anderen Einträge haben, und für die Domain selbst (ohne Subdomain) ist er meist nicht erlaubt. Auf einen CNAME dürfen auch keine MX-Einträge zeigen. Das sind klassische Fehlerquellen in der Praxis.

Die hosts-Datei: Lokaler Vorrang

Bevor dein Rechner das DNS fragt, schaut er in eine lokale Datei. In ihr kannst du Namen fest einer Adresse zuordnen. Sie liegt unter Windows in C:\Windows\System32\drivers\etc\hosts und unter Linux in /etc/hosts. Ein Eintrag sieht so aus:

192.168.10.140   dateiserver

Die Zeile ordnet dem Namen „dateiserver“ die Adresse 192.168.10.140 zu. Das ist praktisch für Tests oder kleine Setups. In größeren Netzen ist es unhandlich, weil jede Datei von Hand gepflegt werden muss. Gleichzeitig ist es eine häufige Fehlerquelle: Vergessene Einträge in der hosts-Datei überschreiben DNS, sodass Namen auf einem Rechner anders aufgelöst werden als auf allen anderen.

Die Reihenfolge ist also: hosts-Datei, dann lokaler Cache, dann der DNS-Server.

Welchen DNS-Server nutzt dein Rechner?

Der DNS-Server wird, wie im Beitrag DHCP verstehen beschrieben, meist per DHCP mitgeteilt. Im Heimnetz ist das häufig der Router selbst, der die Anfragen an den Server des Providers oder einen öffentlichen Dienst weiterreicht (Forwarder). In einem Firmennetz steht oft ein eigener DNS-Server, der interne Namen kennt und für alle anderen Namen an einen externen Resolver weiterleitet. Unter Windows siehst du ihn mit ipconfig /all bei „DNS-Server“.

Mit nslookup und dig abfragen

Du kannst DNS-Abfragen selbst auslösen. Der Befehl nslookup funktioniert unter Windows und Linux. Mit diesem Aufruf fragst du die Adresse von example.com ab:

nslookup example.com

Die Ausgabe zeigt zuerst, welchen DNS-Server du benutzt hast, und danach die Antwort. Du kannst auch gezielt nach dem Mailserver fragen oder einen bestimmten DNS-Server verwenden:

nslookup -type=MX example.com
nslookup example.com 8.8.8.8

Die erste Zeile fragt nach dem MX-Eintrag. Die zweite stellt dieselbe Frage direkt an den öffentlichen Server 8.8.8.8. Dass sich die Antworten manchmal unterscheiden, ist ein wichtiges Diagnoseergebnis, dazu gleich mehr. Unter Linux gibt es das ausführlichere Programm dig, das manchmal nachinstalliert werden muss:

dig +short example.com
dig -x 203.0.113.50
dig +trace example.com

Die erste Zeile gibt nur die Antwort aus. Die zweite macht eine Rückwärtsauflösung (PTR). Die dritte zeigt den gesamten Weg von der Root über die TLD bis zum autoritativen Server, so wie in der Grafik oben. In der PowerShell liefert Resolve-DnsName example.com -Type A eine ähnliche Ausgabe.

Fehlersuche: Wenn Namen nicht aufgelöst werden

Ein klassisches Fehlerbild: Der Browser meldet, dass die Seite nicht gefunden wird, aber Pings auf IP-Adressen funktionieren. Im Beitrag OSI-Modell erklärt haben wir gesehen, wie man so etwas Schicht für Schicht eingrenzt. Bei DNS hilft diese Tabelle:

Test	Ergebnis	Folgerung
ping 8.8.8.8	Antwort	Internetverbindung steht
nslookup example.com	Fehler oder keine Antwort	Dein DNS-Server antwortet nicht oder ist falsch eingetragen
nslookup example.com 8.8.8.8	Antwort	Der eigene DNS-Server ist schuld, nicht das Internet
ipconfig /flushdns und neu testen	Jetzt geht es	Ein veralteter oder fehlerhafter Cache-Eintrag war die Ursache
Eintrag in der hosts-Datei?	Ja, mit falscher Adresse	Lokaler Eintrag überschreibt DNS

Wenn ping 8.8.8.8 funktioniert, aber der Name nicht, liegt das Problem fast immer bei DNS. Das ist ein Fehler auf der Anwendungsschicht, auch wenn Anwender sagen: „Das Internet geht nicht.“

Sicherheit und Datenschutz

Klassische DNS-Anfragen laufen unverschlüsselt. Jeder auf dem Weg kann mitlesen, welche Namen du auflöst. Angreifer können außerdem versuchen, Resolvern falsche Antworten unterzuschieben (Cache Poisoning), um Nutzer auf gefälschte Seiten zu lenken. Dagegen gibt es zwei Ansätze:

• DNSSEC: Die Antworten werden digital signiert, damit der Resolver ihre Echtheit prüfen kann. Es schützt die Echtheit, nicht die Vertraulichkeit.
• DNS über TLS (DoT) und DNS über HTTPS (DoH): Die Anfragen werden verschlüsselt übertragen. Das schützt vor Mitlesen auf dem Weg zum Resolver. Der Resolver selbst sieht die Anfragen weiterhin.

Unternehmen nutzen DNS auch als Werkzeug: Ein DNS-Filter blockiert bekannte schädliche Domains, indem er für sie keine oder eine falsche Antwort liefert.

Praxisbeispiel: Interner Name für den Dateiserver

In der Firma sollen Mitarbeiter den Dateiserver unter einem Namen erreichen, nicht unter 192.168.10.140. Der Administrator betreibt einen DNS-Server im Server-VLAN, auf demselben Rechner wie den DHCP-Dienst unter 192.168.10.130. Per DHCP bekommen alle Clients diese Adresse als DNS-Server. Auf dem Server legt er einen Eintrag an. Mit dem Dienst dnsmasq sieht das so aus:

host-record=dateiserver.intern.beispiel.de,192.168.10.140
server=8.8.8.8

Die erste Zeile ordnet dem Namen die Adresse zu, entspricht also einem A-Record. Die zweite sagt dem Server, an welchen externen Resolver er alle anderen Fragen weiterleiten soll. Der Name beispiel.de ist hier nur ein Platzhalter für die eigene Domain.

Ein Mitarbeiter tippt jetzt \\dateiserver.intern.beispiel.de ein. Sein Rechner fragt den internen DNS-Server, bekommt 192.168.10.140 und verbindet sich. Zieht der Server eines Tages auf eine andere Adresse um, ändert der Administrator einen einzigen Eintrag, und alle Clients folgen nach Ablauf der TTL automatisch.

Typische Fehler und Missverständnisse

• DNS und DHCP verwechseln. DHCP verteilt Adressen, DNS übersetzt Namen. Der DNS-Server wird aber per DHCP bekannt gemacht.
• „Das Internet geht nicht“, dabei ist es DNS. Teste mit einer IP-Adresse, um beides zu trennen.
• Änderungen erscheinen sofort. Wegen der TTL und der Caches dauert es oft Stunden, bis ein Wechsel überall sichtbar ist.
• Falscher DNS-Server per DHCP. Ein falscher Eintrag im Pool legt die Namensauflösung für das ganze Netz lahm.
• Vergessene hosts-Einträge. Sie überlagern DNS und führen zu Fehlern, die nur auf einem Rechner auftreten.
• CNAME an der falschen Stelle. Neben einem CNAME sind keine weiteren Einträge erlaubt, und MX darf nicht darauf zeigen.
• Unverschlüsselte Abfragen für privat halten. Klassisches DNS ist im Klartext sichtbar.

Zum Üben

1. Zerlege den Namen www.mail.example.com in seine Labels und benenne die Ebenen.
2. Welcher Record-Typ ordnet einem Namen eine IPv6-Adresse zu?
3. Bringe die Schritte in die richtige Reihenfolge: autoritativer Server, Resolver, Client, Root-Server, TLD-Server.
4. Eine TTL beträgt 1.800 Sekunden. Wie lange gilt die Antwort im Cache?
5. Eine Webseite lässt sich per IP-Adresse öffnen, aber nicht per Namen. Was liegt nahe, und welchen Test machst du?
6. Welcher Record-Typ gibt den Mailserver einer Domain an?
7. Wozu dient ein PTR-Record?
8. Mit welchem Befehl leerst du unter Windows den DNS-Cache?

Lösungen: (1) Labels: www (Subdomain), mail (Subdomain), example (Second-Level-Domain), com (Top-Level-Domain), dazu die unsichtbare Root. (2) AAAA. (3) Client, Resolver, Root-Server, TLD-Server, autoritativer Server, dann die Antwort zurück über den Resolver zum Client. (4) 1.800 ÷ 60 = 30 Minuten. (5) Ein DNS-Problem. Test: nslookup example.com und zum Vergleich nslookup example.com 8.8.8.8. Antwortet nur der öffentliche Server, liegt der Fehler am eigenen DNS-Server. (6) MX. (7) Er löst eine IP-Adresse in einen Namen auf (Rückwärtsauflösung). (8) ipconfig /flushdns.

Das solltest du dir merken

• DNS übersetzt Namen in IP-Adressen und umgekehrt. Es ist hierarchisch und verteilt.
• Namen werden von rechts nach links gelesen: Root, TLD, Second-Level-Domain, Subdomain.
• Der Resolver löst den Namen für dich auf: Root, TLD, autoritativer Server.
• Antworten werden gemäß der TTL zwischengespeichert. Änderungen brauchen deshalb Zeit.
• Wichtige Records: A, AAAA, CNAME, MX, NS, PTR, TXT, SOA.
• Reihenfolge am Rechner: hosts-Datei, Cache, DNS-Server.
• Bei Problemen testest du mit ping auf eine IP-Adresse und mit nslookup.

Jetzt weißt du, wie Geräte Adressen bekommen und Namen auflösen. Was noch fehlt: Wie finden Pakete ihren Weg durch viele Netze bis zum Ziel? Das behandelt der nächste Beitrag: Routing verstehen.