Der komplette Ablauf der DNS-Auflösung – wie viele Schritte vom Browser bis zum Root-Server?

1. Der vollständige Ablauf in 8 Schritten

┌─────────────────────────────────────────────────────────────┐
│  Browser (Chrome / Firefox) – Eingabe google.com            │
└────────────────┬────────────────────────────────────────────┘
                 │ ① DNS-Cache des Browsers (Chrome ~60s)
                 ↓ kein Treffer
┌─────────────────────────────────────────────────────────────┐
│  Stub-Resolver des Betriebssystems + System-DNS-Cache       │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Kein Treffer im System-Cache → UDP-Anfrage an den Router
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  DNS-Weiterleitung des Heimrouters + Router-Cache           │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Kein Treffer im Router-Cache → weiter an den rekursiven Resolver des ISP
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Rekursiver Resolver des ISP / öffentlicher Resolver        │
│  (1.1.1.1 / 8.8.8.8 / 223.5.5.5)                            │
│  Cache-Treffer: direkte Antwort, Dauer insgesamt 1-5ms      │
│  Kein Treffer: weiter mit der „vollständigen Abfrage“ unten │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Fragt den Root-NS: „Wo ist google.com?“
                 ↓
        13 Gruppen von Root-Nameservern (a~m.root-servers.net)
                 │ ⑤ Antwort: „Weiß ich nicht, frag den NS von .com: a.gtld-servers.net“
                 ↓
        Autoritative Server der TLD .com (Verisign)
                 │ ⑥ Antwort: „Habe ich auch nicht komplett, frag den NS von google.com: ns1.google.com“
                 ↓
        Autoritative Server von google.com (von Google selbst betrieben)
                 │ ⑦ Antwort: „A-Record von google.com = 142.250.x.x“
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ Der rekursive Resolver speichert die Antwort (gemäß TTL) │
│     und gibt sie an den Client zurück – auch jede Ebene     │
│     auf dem Weg speichert eine eigene Kopie                 │
└─────────────────────────────────────────────────────────────┘

Wichtige Erkenntnis: In der Praxis wird der vollständige Ablauf mit 8 Schritten fast nie durchlaufen. Die IP-Adressen großer Websites liegen fast immer bereits im Cache des rekursiven Resolvers, sodass normale Nutzer schon bei Schritt ④ eine Antwort erhalten. Nur wenig bekannte Domains, selten besuchte Websites, abgelaufene TTLs oder neu registrierte Domains lösen den kompletten Ablauf aus.

2. Die 5 Ebenen des DNS-Cachings im Detail

Schon beim Entwurf von DNS im Jahr 1983 wurde eine Tatsache berücksichtigt: Es gibt rund 100.000-mal mehr Abfragen als Änderungen. Deshalb wird überall gecacht, und jede Ebene hält Daten für die Dauer einer TTL (Time To Live) vor.

3. Rekursive vs. iterative Abfragen – die Schlüsselkonzepte

3.1 Rekursiv

Der Client (Browser / Stub des Betriebssystems) sagt dem rekursiven Resolver des ISP: „Finde die IP von google.com für mich – wie, ist mir egal.“ Der rekursive Resolver muss die gesamte Abfrage erledigen und das Endergebnis zurückgeben.

3.2 Iterativ

Spricht der rekursive Resolver mit Root-, TLD- und autoritativen Servern, läuft dieser Austausch iterativ ab: Er fragt die Root-Server, die antworten „frag .com“. Er fragt .com, .com antwortet „frag google“. Dann fragt er google. Jeder Schritt überbrückt nur eine Ebene – es ist also nicht so, dass die Root-Server nach einer Anfrage alles Weitere selbst erledigen.

4. Selbst testen – dig +trace

dig +trace erzwingt eine vollständige iterative Abfrage und zeigt jeden Schritt:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Hop 1 – Anfrage an die Root-Zone (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 Root-NS-Records)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Hop 2 – Anfrage an die TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (die 4 NS für .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Hop 3 – Anfrage an die autoritativen Server von cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Endlich die Antwort
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Aufgeschlüsselt:

• Der gesamte Vorgang dauerte 5 + 121 + 53 + 12 = 191 ms – die erste kalte Abfrage ist tatsächlich langsam
• Eine erneute Abfrage derselben Domain eine Sekunde später dauert dagegen nur 1-2 ms, weil der rekursive Cache des ISP sie bereits enthält (TTL 300 Sekunden)
• 104.21.x.x / 172.67.x.x sind CDN-Adressen von Cloudflare – die echte Origin-IP unserer Website ist hinter dem CDN verborgen

5. TTL erklärt – wie lange wird eigentlich gecacht?

TTL (Time To Live) ist das Feld, mit dem der autoritative Server jedem rekursiven Resolver mitteilt: „Du darfst das höchstens so lange cachen“ – angegeben in Sekunden.

Hinweis: Die TTL ist die „maximale Cache-Dauer“ – einzelne Resolver können ihren Cache früher leeren, ihn aber nie verlängern. Selbst wenn die autoritative TTL 1 Stunde beträgt, fragen manche Resolver also schon nach 10 Minuten erneut an.

Stolperfalle: Verkürzen Sie vor einem IP-Wechsel zuerst die TTL (1-5 Minuten) und stellen Sie erst um, wenn die alte TTL vollständig abgelaufen ist – sonst landen manche Nutzer noch über eine Stunde lang bei der alten IP.

6. DNS-Record-Typen im Überblick

7. DNS-Optimierung – so wird die Auflösung schneller

7.1 Einen nahe gelegenen rekursiven Resolver wählen

Festlandchina: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) lösen chinesische Websites am schnellsten auf. Außerhalb Chinas: 1.1.1.1 (Cloudflare, größte Anycast-Abdeckung) / 8.8.8.8 (Google). Mehr dazu imVerzeichnis öffentlicher DNS-Resolver.

7.2 DoH (DNS-over-HTTPS) aktivieren

Werden DNS-Anfragen per HTTPS verschlüsselt, kann der ISP sie weder einsehen noch manipulieren (das verhindert NXDOMAIN-Hijacking). Chrome, Firefox und Edge unterstützen das – einfach in den Einstellungen aktivieren.

7.3 Vorab auflösen (DNS-Prefetch)

Fügen Sie <link rel="dns-prefetch" href="//api.example.com"> in den <head> Ihrer Website ein, damit der Browser die Domain im Leerlauf auflöst – bei der eigentlichen Anfrage gibt es dann einen Cache-Treffer.

7.4 CDN + Anycast-NS nutzen

Betreiben Sie Ihre autoritativen NS per Anycast (Cloudflare / Route 53), damit Nutzer weltweit die nächstgelegene Instanz erreichen. So sinkt die Latenz von Schritt ③ von 100ms auf 10ms.

7.5 TTL sinnvoll setzen

Für Records, die sich selten ändern (NS / MX), eine lange TTL (1-7 Tage) setzen; für A-Records, die eventuell umgestellt werden müssen, eine kurze TTL (5-60 Minuten).

8. Häufige Fragen

8.1 DNS geändert, aber nichts passiert – warum?

Denken Sie zuerst an die aktuelle TTL. Nach einer DNS-Änderung liefert jeder rekursive Resolver weiterhin die alte IP, bis die alte TTL abgelaufen ist. Bis eine Änderung „weltweit propagiert“ ist, vergeht in der Regel etwa die doppelte TTL, weil die einzelnen Resolver nicht synchron laufen.

• Client: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Warten, bis der Cache des öffentlichen rekursiven Resolvers abläuft: 1.1.1.1 / 8.8.8.8 bieten jeweils ein eigenes „Purge“-Tool, mit dem Sie ihn manuell leeren können

8.2 Manche Nutzer erreichen die Seite, andere nicht – DNS-Manipulation

Tritt häufig auf, wenn aus Festlandchina ausländische Websites aufgerufen werden: Die Great Firewall (GFW) schleust gefälschte DNS-Antworten ein, oder der ISP leitet Anfragen per Hijacking um. Mit DoH (verschlüsseltes DNS im Browser) lässt sich der Großteil dieser DNS-Manipulation umgehen.

8.3 Wie lange nach der Registrierung ist eine Domain nutzbar?

Nach der Registrierung überträgt die TLD-Registry Ihre NS-Records an die autoritativen Server der Top-Level-Domain (.com, .net usw.) – das dauert meist 15 Minuten bis 24 Stunden. Domains unter .cn / .com.cn benötigen unter Umständen eine ICP-Registrierung, bevor sie in Festlandchina aufgelöst werden.