DNS Grundlagen — Wie das Telefonbuch des Internets funktioniert
Das Domain Name System von Grund auf verstehen: Auflösungsprozess, Hierarchie, Caching und warum DNS für alles Digitale essenziell ist.
Was ist DNS?
Das Domain Name System (DNS) ist eines der fundamentalsten Systeme des Internets. Es ist ein weltweit verteiltes, hierarchisches Verzeichnissystem, das menschenlesbare Domainnamen (wie provider.tools) in maschinenlesbare IP-Adressen (wie 185.199.108.153) übersetzt — und umgekehrt.
Warum brauchen wir DNS?
Computer kommunizieren über IP-Adressen — numerische Kennungen wie 93.184.216.34 (IPv4) oder 2606:2800:220:1:248:1893:25c8:1946 (IPv6). Menschen können sich solche Zahlen schlecht merken. DNS löst dieses Problem, indem es als Vermittler zwischen menschlicher und maschineller Sprache fungiert.
Analogie: Stellen Sie sich DNS wie das Telefonbuch des Internets vor. Statt sich die Telefonnummer (IP-Adresse) jeder Person (Webseite) zu merken, schauen Sie einfach unter dem Namen nach.
DNS in Zahlen
- ~370 Millionen registrierte Domainnamen weltweit (Stand 2025)
- Über 1 Billion DNS-Abfragen täglich
- 13 Root-Server-Cluster bilden die Basis des gesamten Systems
- < 100ms typische DNS-Auflösungszeit
- 48 Stunden maximale Propagationszeit bei Änderungen
Kernkonzepte
| Konzept | Beschreibung |
|---|---|
| Hierarchisch | DNS ist baumartig strukturiert: Root → TLD → Authoritative Server |
| Verteilt | Kein einzelner Server kennt alle Antworten — die Last wird weltweit verteilt |
| Redundant | Jede Ebene hat mehrere Server für Ausfallsicherheit |
| Gecacht | Antworten werden zwischengespeichert, um Geschwindigkeit und Last zu optimieren |
Die DNS-Hierarchie
DNS ist wie ein umgekehrter Baum aufgebaut. Jede Ebene hat eine spezifische Aufgabe:
1. Root-Zone (die Wurzel)
Die Root-Zone ist der Ausgangspunkt jeder DNS-Auflösung. Es gibt 13 Root-Server-Cluster (benannt A bis M), die über Anycast weltweit an über 1.500 Standorten gespiegelt werden. Sie kennen nicht die Antwort auf Ihre Anfrage, aber sie wissen, wo die TLD-Server zu finden sind.
Root Server (.) ├── .com (TLD) │ ├── google.com (SLD) │ ├── provider.tools (SLD) │ └── ... ├── .de (TLD) │ ├── example.de │ └── ... ├── .org (TLD) └── ...
2. Top-Level-Domains (TLDs)
TLDs sind die höchste Ebene unter dem Root. Es gibt mehrere Kategorien:
- Generic TLDs (gTLDs):
.com,.org,.net,.info,.tools - Country Code TLDs (ccTLDs):
.de(Deutschland),.at(Österreich),.ch(Schweiz),.uk - Sponsored TLDs:
.edu,.gov,.mil - New gTLDs (seit 2014):
.app,.dev,.cloud,.shop,.blog
3. Second-Level-Domains (SLDs)
Die Domain, die Sie bei einem Registrar kaufen: provider.tools, google.com.
4. Subdomains
Weitere Unterteilungen links vom SLD: mail.provider.tools, www.example.com, api.v2.example.com.
Der DNS-Auflösungsprozess
Wenn Sie https://provider.tools in Ihren Browser eingeben, passiert Folgendes:
Schritt 1: Browser-Cache
Der Browser prüft seinen eigenen DNS-Cache. Wurde diese Domain kürzlich aufgelöst? Wenn ja → fertig.
Schritt 2: Betriebssystem-Cache
Das OS prüft seinen lokalen DNS-Cache und die /etc/hosts-Datei (Linux/Mac) bzw. C:\Windows\System32\drivers\etc\hosts (Windows).
Schritt 3: Recursive Resolver (DNS-Resolver)
Der konfigurierte DNS-Resolver (meist vom ISP, oder z.B. 8.8.8.8 von Google, 1.1.1.1 von Cloudflare) wird befragt. Dieser hat seinen eigenen Cache. Wenn die Antwort nicht im Cache ist, beginnt die rekursive Auflösung:
Schritt 4: Root-Server
Der Resolver fragt einen Root-Server: "Wer ist zuständig für .tools?" → Antwort: IP-Adresse des .tools-TLD-Servers.
Schritt 5: TLD-Server
Der Resolver fragt den TLD-Server: "Wer ist zuständig für provider.tools?" → Antwort: IP-Adresse des autoritativen Nameservers.
Schritt 6: Autoritativer Nameserver
Der Resolver fragt den autoritativen Nameserver: "Welche IP hat provider.tools?" → Antwort: 185.199.108.153.
Schritt 7: Antwort an den Client
Der Resolver cacht die Antwort (für die im TTL definierte Dauer) und gibt sie an Ihren Browser zurück. Ihr Browser kann nun die Verbindung zum Webserver aufbauen.
Die 4 Beteiligten der DNS-Auflösung
| Server-Typ | Aufgabe | Beispiel |
|---|---|---|
| Recursive Resolver | Nimmt Anfrage entgegen, sucht die Antwort | 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) |
| Root-Server | Verweist auf den zuständigen TLD-Server | a.root-servers.net |
| TLD-Server | Verweist auf den autoritativen Nameserver | a.nic.tools |
| Autoritativer Server | Kennt die eigentlichen DNS-Records | ns1.provider.tools |
DNS Caching & TTL
DNS-Caching ist essenziell für die Performance des gesamten Internets. Ohne Caching müsste jede einzelne DNS-Anfrage den vollständigen Auflösungsprozess durchlaufen — das würde die Root-Server überlasten und die Ladezeiten massiv erhöhen.
Was ist TTL (Time to Live)?
Jeder DNS-Record hat einen TTL-Wert (in Sekunden), der angibt, wie lange die Antwort gecacht werden darf. Nach Ablauf des TTL wird die Information als veraltet betrachtet und muss neu abgefragt werden.
| TTL-Wert | Dauer | Verwendung |
|---|---|---|
300 | 5 Minuten | Häufig geänderte Records, Failover-Szenarien |
3600 | 1 Stunde | Standard für die meisten Records |
14400 | 4 Stunden | Stabile Records (z.B. MX bei festen Mailservern) |
86400 | 24 Stunden | Sehr stabile Records (z.B. NS-Records) |
604800 | 7 Tage | Praktisch unveränderliche Records |
Best Practices für TTL
- Vor geplanten Änderungen: TTL 2–4 Stunden vorher auf
300(5 Min) senken → Änderung durchführen → TTL wieder erhöhen - Für Mailserver (MX):
3600bis14400— zu niedrig kann Zustellprobleme bei Cache-Ablauf verursachen - Für Nameserver (NS):
86400oder höher — NS-Änderungen sind selten - Für Loadbalancing/Failover:
60bis300— schnelle Umschaltung nötig
Cache-Ebenen
- Browser-Cache: Chrome, Firefox etc. cachen DNS-Einträge (Chrome:
chrome://net-internals/#dns) - OS-Cache: Betriebssystem-Level (Windows:
ipconfig /flushdns, Linux:systemd-resolve --flush-caches, macOS:sudo dscacheutil -flushcache) - Router-Cache: Ihr Router cacht häufig DNS-Antworten
- ISP-Resolver-Cache: Ihr Internetanbieter cacht Antworten zentral
- Recursive-Resolver-Cache: Google DNS, Cloudflare etc. haben eigene Caches