Wie das Domain Name System (DNS) funktioniert

Jedes Mal, wenn Sie eine Website öffnen, eine E-Mail senden oder eine API aufrufen, muss Ihr Gerät zuerst eine einfache Frage klären: Welche IP-Adresse gehört zu diesem Namen? Das Domain Name System (DNS) ist das weltweite, verteilte Verzeichnis, das diese Frage beantwortet. Es gehört zu den ältesten Bausteinen der Internet-Infrastruktur, die noch täglich im Einsatz sind, und weil es meist unsichtbar arbeitet, erfahren viele Website-Betreiber erst dann, wie es funktioniert, wenn etwas schiefgeht. Dieser Leitfaden verfolgt den Weg einer DNS-Abfrage von Anfang bis Ende in verständlicher Sprache, erklärt, warum Caching so wichtig ist, und zeigt die Befehle, mit denen Sie alles selbst nachvollziehen können.

Was DNS eigentlich leistet

Computer leiten Datenverkehr anhand numerischer Adressen wie 93.184.215.14 (IPv4) oder 2606:2800:21f:cb07:6820:80da:af6b:8b2c (IPv6). Menschen bevorzugen Namen. DNS übersetzt zwischen beiden, ist aber weit mehr als eine Nachschlagetabelle: Es ist eine hierarchische, delegierte Datenbank, in der kein einzelner Server alle Antworten kennt. Die Verantwortung ist in Zonen aufgeteilt, und jede Zone wird von demjenigen verwaltet, der sie kontrolliert.

Dieses Design hat drei praktische Folgen:

• Skalierbarkeit: Die Root-Server müssen nicht Milliarden von Hostnamen kennen, sondern nur wissen, wo jede Top-Level-Domain zu finden ist.
• Autonomie: Sobald eine Domain an Sie delegiert ist, entscheiden Sie selbst, welche Einträge sie enthält – ohne jemanden fragen zu müssen.
• Ausfallsicherheit: Jede Ebene wird von mehreren Servern bedient, oft per Anycast über mehrere Kontinente verteilt.

Die einzelnen Einträge einer Zone wie A, AAAA, CNAME und MX erklären wir ausführlich in unserem Beitrag zu den Grundlagen der DNS-Einträge. Hier geht es darum, wie ein Resolver diese Einträge überhaupt findet.

Die DNS-Hierarchie: Root, TLD und autoritative Server

Lesen Sie einen Domainnamen von rechts nach links, lesen Sie den DNS-Baum von oben nach unten. Der Name www.example.com. endet eigentlich mit einem unsichtbaren Punkt, der die Root darstellt.

Die Verbindung zwischen den Ebenen heißt Delegation. Wenn Sie eine Domain registrieren und beim Registrar die Nameserver eintragen, übermittelt der Registrar diese NS-Einträge an die Registry, die sie in der TLD-Zone veröffentlicht. Liegen die Nameserver innerhalb der Domain selbst (etwa ns1.example.com), veröffentlicht die Registry zusätzlich Glue-Records – die IP-Adressen dieser Server –, um ein Henne-Ei-Problem zu vermeiden.

Schritt für Schritt: Was passiert, wenn Sie eine URL eingeben?

Angenommen, Sie rufen www.example.com zum ersten Mal in einem neuen Netzwerk auf. Die Abfrage läuft ungefähr so ab:

1. Lokale Prüfungen. Der Browser prüft seinen eigenen Cache und fragt dann das Betriebssystem, das wiederum seinen Cache und die hosts-Datei konsultiert.
2. Vom Stub-Resolver zum rekursiven Resolver. Ist nichts zwischengespeichert, schickt der im Betriebssystem eingebaute Stub-Resolver die Anfrage an den konfigurierten rekursiven Resolver – meist den Ihres Providers, Ihres Routers oder einen öffentlichen Dienst wie 1.1.1.1, 8.8.8.8 oder 9.9.9.9.
3. Der Resolver fragt einen Root-Server. Der Resolver bringt eine Liste der Root-Server-Adressen mit (Root Hints) und fragt einen davon nach www.example.com. Die Root kennt die Antwort nicht, liefert aber einen Verweis (Referral): Hier sind die Nameserver für .com.
4. Der Resolver fragt die TLD-Server. Ein .com-Server antwortet mit einem weiteren Verweis: den autoritativen Nameservern für example.com, bei Bedarf samt Glue.
5. Der Resolver fragt den autoritativen Server. Dieser Server hält die Zone und liefert die eigentliche Antwort, etwa einen A-Eintrag mit einer IPv4-Adresse, und setzt das AA-Flag (Authoritative Answer).
6. Antwort zurück und in den Cache. Der Resolver gibt die Antwort an Ihr Gerät weiter und speichert sie zusammen mit den gesammelten Verweisen für die Dauer der jeweiligen TTL.

Der Resolver stellt iterative Anfragen an die Hierarchie, während er die rekursive Anfrage Ihres Geräts beantwortet. Ihr Laptop fragt einmal und wartet; den Weg geht der Resolver. In der Praxis sind die Schritte 3 und 4 selten nötig, weil Root- und .com-Verweise längst im Cache liegen.

Mit dig +trace zusehen

Das Werkzeug dig (Teil der BIND-Tools, unter Linux und macOS verfügbar) kann den Weg selbst gehen und jeden Verweis ausgeben. Die Ausgabe ist gekürzt:

$ dig +trace www.example.com A

.                 518400  IN  NS  a.root-servers.net.
.                 518400  IN  NS  b.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53

com.              172800  IN  NS  a.gtld-servers.net.
com.              172800  IN  NS  b.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net)

example.com.      172800  IN  NS  a.iana-servers.net.
example.com.      172800  IN  NS  b.iana-servers.net.
;; Received 361 bytes from 192.5.6.30#53(a.gtld-servers.net)

www.example.com.  300     IN  A   93.184.215.14
;; Received 60 bytes from 199.43.135.53#53(a.iana-servers.net)

Jeder Block ist ein Schritt: Root, TLD, autoritativer Server. Die Zahl hinter dem Namen ist die TTL in Sekunden.

Caching und TTL: Warum DNS so schnell ist

Würde jede Abfrage den gesamten Baum durchlaufen, wären Root- und TLD-Server überlastet und das Surfen wäre zäh. Caching verhindert das. Jeder Eintrag trägt eine vom Zoneninhaber festgelegte TTL (Time To Live), die Resolvern sagt, wie viele Sekunden sie eine Antwort wiederverwenden dürfen, bevor sie erneut fragen.

• Lange TTLs (Stunden oder ein Tag) senken die Abfragelast und machen Ihre Website robuster gegenüber kurzen Ausfällen der autoritativen Server, dafür erreichen Änderungen alle Nutzer langsamer.
• Kurze TTLs (60 bis 300 Sekunden) erlauben schnelle Serverwechsel, kosten aber mehr Abfragen.
• Negatives Caching: Auch die Antwort „Diesen Namen gibt es nicht“ (NXDOMAIN) wird zwischengespeichert, und zwar für eine aus dem SOA-Eintrag der Zone abgeleitete Dauer. Legen Sie einen Eintrag direkt an, nachdem jemand danach gefragt hat, scheint er deshalb eine Weile nicht zu funktionieren.

Eine bewährte Gewohnheit vor einem Umzug: Senken Sie die TTL der betroffenen Einträge ein bis zwei Tage vorher, führen Sie die Umstellung durch und erhöhen Sie die TTL wieder, sobald der Datenverkehr umgezogen ist.

Was „DNS-Propagation“ wirklich bedeutet

Wenn Sie einen Eintrag ändern, wird nichts aktiv durchs Internet verteilt. „Propagation“ ist schlicht die Zeit, bis zwischengespeicherte Kopien bei Tausenden von Resolvern ablaufen. Dabei spielen zwei verschiedene Zeitgeber eine Rolle:

• Änderungen an Einträgen innerhalb Ihrer Zone richten sich nach deren TTL.
• Änderungen an den Nameservern betreffen die in der TLD-Zone veröffentlichte Delegation. Deren NS-TTL legt die Registry fest; bei manchen TLDs liegt sie bei 48 Stunden oder mehr. Resolver, die die alte Delegation gespeichert haben, nutzen sie bis zum Ablauf weiter.

Lassen Sie den bisherigen DNS-Anbieter während eines Nameserver-Wechsels dieselben Einträge weiter ausliefern, dann bemerken Ihre Besucher von der Umstellung nichts.

Typische DNS-Probleme und wie Sie sie erkennen

Eine Lame Delegation liegt vor, wenn die TLD auf Nameserver verweist, die Ihre Zone gar nicht ausliefern – häufig nach der Kündigung eines Hosting-Pakets, ohne dass die NS-Einträge angepasst wurden. An welche Nameserver eine Domain delegiert ist, samt Registrar und Ablaufdatum, sehen Sie schnell mit der WHOIS-Abfrage von TLDix.

Rekursive Resolver, Datenschutz und Sicherheit

Klassisches DNS läuft unverschlüsselt über UDP-Port 53. Jeder auf dem Netzwerkpfad kann Abfragen also mitlesen und unter Umständen manipulieren. Mehrere Erweiterungen setzen hier an:

• DNS over TLS (DoT) und DNS over HTTPS (DoH) verschlüsseln die Verbindung zwischen Ihrem Gerät und dem rekursiven Resolver und schützen so die Privatsphäre auf dem ersten Abschnitt.
• QNAME-Minimierung sorgt dafür, dass Resolver jedem Server nur den Teil des Namens schicken, den er benötigt; die Root erfährt also nicht den vollständigen Hostnamen.
• DNSSEC ergänzt kryptografische Signaturen, damit Resolver prüfen können, ob Antworten wirklich vom Zoneninhaber stammen und unverändert sind. Verschlüsselung verbirgt Abfragen, DNSSEC belegt die Echtheit. Beide lösen unterschiedliche Probleme und ergänzen sich gut.

So bleibt das DNS Ihrer Domain gesund

Die meisten DNS-Ausfälle sind keine raffinierten Angriffe, sondern gewöhnliche Versäumnisse: eine abgelaufene Domain, ein vergessenes DNS-Hosting-Konto oder ein undokumentierter Nameserver-Wechsel. Eine einfache Routine hilft:

1. Nutzen Sie mindestens zwei autoritative Nameserver, idealerweise in getrennten Netzen.
2. Dokumentieren Sie, welcher Anbieter Ihre Zone hostet und wer Zugriff hat.
3. Halten Sie Domainregistrierung und DNS-Hosting verlängert, nach Möglichkeit mit automatischer Verlängerung.
4. Prüfen Sie die Delegation nach jedem Anbieterwechsel mit dig NS und dig +trace.
5. Behalten Sie Ablaufdaten zentral im Blick. Im TLDix-Domain-Panel verfolgen Sie Domains, SSL-Zertifikate und Hosting-Verlängerungen an einem Ort und werden erinnert, bevor etwas ausläuft.

Wer die Kette von der Root bis zum autoritativen Server verstanden hat, dem erscheinen die meisten DNS-Rätsel plötzlich einfach: Finden Sie heraus, welches Glied die unerwartete Antwort liefert, prüfen Sie dessen TTL und korrigieren Sie die Daten an der Quelle.