Was macht DNS und wie funktioniert es?

DNS (Domain Name System) ist die verteilte Namensinfrastruktur des Internets, die menschenlesbare Domainnamen — wie example.com — in maschinenlesbare IP-Adressen wie 93.184.216.34 übersetzt. Ohne DNS würde jede Browseranfrage, jeder API-Aufruf und jede E-Mail-Zustellung erfordern, dass Benutzer und Anwendungen die genaue numerische Adresse jedes Remote-Hosts kennen, was das moderne Internet im großen Maßstab betrieblich unmöglich machen würde.

Im Kern ist DNS eine global verteilte, hierarchische Datenbank. Es handelt sich nicht um einen einzelnen Server oder eine zentralisierte Registry — es ist ein Delegationsbaum, der sich über Hunderttausende von autoritativen Nameservern weltweit erstreckt, koordiniert durch eine kleine Gruppe von Root-Servern und geregelt durch Standards, die in RFC 1034 und RFC 1035 definiert sind.

Warum DNS mehr als nur ein „Telefonbuch” ist

Die Telefonbuch-Analogie ist für Anfänger nützlich, unterschätzt jedoch dramatisch, was DNS tatsächlich leistet. DNS ist ein Echtzeit-, fehlertolerantes, global repliziertes Nachschlagesystem, das auch folgendes verwaltet:

• Mail-Routing über MX-Einträge, die E-Mails an die richtigen Mailserver weiterleiten
• Service-Discovery über SRV-Einträge, die von Protokollen wie SIP, XMPP und Kubernetes-internem Networking verwendet werden
• Domain-Eigentumsverifizierung über TXT-Einträge, die für SPF, DKIM, DMARC und die Google Search Console verwendet werden
• Kanonische Benennung über CNAME-Einträge, die CDN-Integration und Load Balancing ermöglichen
• IPv6-Adressierung über AAAA-Einträge
• Reverse-Lookups über PTR-Einträge in der in-addr.arpa-Zone, die für die Reputation von Mailservern und Sicherheitsaudits entscheidend sind
• DNSSEC-Validierung, die kryptografische Signaturen zu DNS-Antworten hinzufügt, um Cache-Poisoning zu verhindern

Jedes Mal, wenn Sie eine E-Mail senden, sich mit einem VPN verbinden oder eine Webanwendung laden, löst DNS im Hintergrund mehrere Eintragstypen auf — oft Dutzende von Abfragen pro Seitenaufruf.

Die DNS-Hierarchie: Wie der Namensraum strukturiert ist

DNS ist als umgekehrter Baum organisiert. Das Verständnis dieser Struktur ist wesentlich dafür, warum die Auflösung so funktioniert, wie sie es tut.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Root-Zone (.): Verwaltet von IANA. Es gibt 13 logische Root-Server-Adressen (A bis M), die von Organisationen wie Verisign, NASA und ICANN betrieben werden. In der Praxis werden diese von Hunderten physischer Maschinen über Anycast-Routing bereitgestellt.
• Top-Level-Domains (TLDs): Generische TLDs wie .com, .net, .org, und Ländercode-TLDs wie .uk, .de, .md. Jede TLD verfügt über eigene autoritative Nameserver.
• Second-Level-Domains (SLDs): Die Domain, die Sie registrieren — example.com. Das autoritative DNS für diese Zone wird von demjenigen kontrolliert, der die Domain registriert hat.
• Subdomains: www, mail, api, staging — diese sind Einträge innerhalb der SLD-Zone und werden vollständig vom Domain-Inhaber kontrolliert.

Schritt für Schritt: Wie eine DNS-Abfrage aufgelöst wird

Eine vollständige rekursive DNS-Auflösung umfasst bis zu sieben verschiedene Netzwerkaustausche. Hier ist die genaue Abfolge:

Schritt 1 — Browser-Cache-Prüfung

Wenn Sie www.example.com in Ihren Browser eingeben, prüft das Betriebssystem zunächst seinen lokalen DNS-Cache. Unter Linux kann dies von systemd-resolved verwaltet werden; unter Windows vom DNS-Client-Dienst. Wenn ein gültiger gecachter Eintrag vorhanden ist und seine TTL (Time to Live) nicht abgelaufen ist, endet die Auflösung hier.

Sie können den lokalen DNS-Cache unter Linux mit folgendem Befehl einsehen:

resolvectl statistics

Oder ihn leeren mit:

sudo resolvectl flush-caches

Unter Windows:

ipconfig /displaydns
ipconfig /flushdns

Schritt 2 — Rekursive Resolver-Abfrage

Wenn keine gecachte Antwort vorhanden ist, leitet das Betriebssystem die Abfrage an den konfigurierten rekursiven Resolver weiter (auch als rekursiver DNS-Server oder Full-Service-Resolver bezeichnet). Dies ist typischerweise:

• Der Resolver Ihres ISP (per DHCP zugewiesen)
• Ein öffentlicher Resolver: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Ein selbst gehosteter Resolver wie Unbound oder BIND auf Ihrer eigenen VPS Hosting-Infrastruktur

Der rekursive Resolver übernimmt die Hauptarbeit. Er durchläuft die DNS-Hierarchie in Ihrem Namen und cached Ergebnisse, um zukünftige Abfragen schneller zu bedienen.

Schritt 3 — Root-Server-Verweis

Der rekursive Resolver fragt einen der 13 Root-Server-Cluster ab. Der Root-Server kennt die IP-Adresse von www.example.com nicht. Stattdessen gibt er einen Verweis zurück — eine Liste autoritativer Nameserver für die .com-TLD-Zone, zusammen mit ihren IP-Adressen (sogenannte Glue Records).

Schritt 4 — TLD-Nameserver-Abfrage

Der Resolver fragt die .com-TLD-Nameserver ab (betrieben von Verisign). Diese Server haben ebenfalls nicht die endgültige Antwort. Sie geben einen weiteren Verweis zurück — die autoritativen Nameserver speziell für example.com (z. B. ns1.example.com, ns2.example.com).

Schritt 5 — Autoritativer Nameserver-Abfrage

Der Resolver fragt den autoritativen Nameserver für example.com ab. Dieser Server hält die eigentliche Zonendatei und gibt die definitive Antwort zurück — den A-Eintrag mit der IPv4-Adresse (oder AAAA für IPv6).

Schritt 6 — Antwort-Caching und Zustellung

Der rekursive Resolver cached die Antwort gemäß dem TTL-Wert des Eintrags (z. B. 300 Sekunden = 5 Minuten, 86400 Sekunden = 24 Stunden). Anschließend gibt er die IP-Adresse an das Betriebssystem des Clients zurück, das sie an den Browser weiterleitet.

Schritt 7 — TCP/IP-Verbindung

Der Browser verwendet die aufgelöste IP-Adresse, um eine TCP-Verbindung herzustellen (typischerweise auf Port 443 für HTTPS). Die Aufgabe von DNS ist nun abgeschlossen. Der Webserver antwortet und die Seite wird geladen.

Dieser gesamte Prozess — Schritte 2 bis 6 — wird typischerweise in 20–120 Millisekunden bei einem warmen Resolver-Cache abgeschlossen, und in unter 500 Millisekunden für eine vollständig kalte, ungecachte Auflösung, die alle Hierarchieebenen durchläuft.

DNS-Eintragstypen: Eine technische Referenz

CAA-Einträge verdienen besondere Erwähnung: Sie weisen Certificate Authorities an, welche Organisationen berechtigt sind, SSL-Zertifikate für Ihre Domain auszustellen — eine kritische Sicherheitskontrolle, die häufig übersehen wird.

DNS-Abfragetypen: Rekursiv vs. Iterativ vs. Nicht-Rekursiv

Die meisten Endbenutzergeräte senden rekursive Abfragen an ihren konfigurierten Resolver. Der Resolver selbst verwendet iterative Abfragen beim Durchlaufen der Hierarchie.

TTL: Der am häufigsten missverstandene DNS-Parameter

TTL (Time to Live) ist die Anzahl der Sekunden, die ein DNS-Eintrag von Resolvern und Clients gecacht werden darf. Er wird vom Domain-Inhaber in der Zonendatei festgelegt.

• Niedrige TTL (60–300 Sekunden): Schnellere Weitergabe von Änderungen. Unerlässlich vor geplanten Migrationen, IP-Änderungen oder Failover-Ereignissen. Erhöht die Abfragelast auf autoritativen Servern.
• Hohe TTL (3600–86400 Sekunden): Reduziert die Resolver-Last und beschleunigt wiederholte Abfragen. Änderungen benötigen länger, um sich global zu verbreiten.

Kritische operative Erkenntnis: Wenn Sie eine Server-Migration oder IP-Änderung planen, reduzieren Sie Ihre TTL mindestens 48 Stunden vor der Änderung auf 300 Sekunden. Dadurch wird sichergestellt, dass zum Zeitpunkt der Aktualisierung des A-Eintrags kein Resolver den alten Wert länger als 5 Minuten cached. Dies zu versäumen ist eine der häufigsten Ursachen für längere Ausfallzeiten bei Migrationen.

Wenn Sie eine Domain über Domain-Registrierung registrieren und auf einen neuen Server verweisen, wird das Propagationsfenster direkt durch den vorherigen TTL-Wert bestimmt — nicht durch eine willkürliche „24–48-Stunden”-Regel, die oft fälschlicherweise zitiert wird.

DNS-Transportprotokolle: UDP, TCP, DoH und DoT

Traditionelles DNS arbeitet über UDP-Port 53 für Abfragen unter 512 Byte. Antworten, die diese Größe überschreiten, lösen einen Fallback auf TCP-Port 53 aus. DNSSEC-Antworten, Zonenübertragungen (AXFR) und große TXT-Einträge erfordern häufig TCP.

Moderne DNS-Datenschutzprotokolle haben diese Landschaft erheblich verändert:

DoH vs. DoT — der eigentliche operative Unterschied: DoH tunnelt DNS innerhalb von HTTPS-Traffic auf Port 443, wodurch er von regulärem Web-Traffic nicht zu unterscheiden ist. Dies ist nützlich für den Datenschutz, macht jedoch die Netzwerküberwachung und -filterung in Unternehmen erheblich schwieriger. DoT verwendet einen dedizierten Port (853), den Netzwerkadministratoren unabhängig überwachen, blockieren oder inspizieren können. Für selbstverwaltete Infrastruktur auf einem Dedicated Server bietet das Betreiben eines lokalen DoT- oder DoH-Resolvers sowohl Datenschutz als auch vollständige Kontrolle über die Auflösungsrichtlinie.

DNSSEC: Kryptografische Integrität für DNS

DNSSEC (DNS Security Extensions) fügt DNS-Antworten eine Kette kryptografischer Signaturen hinzu, die es Resolvern ermöglicht zu überprüfen, dass eine Antwort authentisch ist und während der Übertragung nicht manipuliert wurde. Es schützt vor DNS-Cache-Poisoning (Kaminsky-Angriff) und Man-in-the-Middle-DNS-Spoofing.

DNSSEC verschlüsselt DNS-Traffic nicht — es signiert ihn nur. Die Signaturkette funktioniert wie folgt:

1. Der Zoneninhaber generiert einen Zone Signing Key (ZSK) und einen Key Signing Key (KSK)
2. Jeder DNS-Eintragssatz wird mit dem ZSK signiert und erzeugt RRSIG-Einträge
3. Der KSK signiert den DNSKEY-Eintragssatz
4. Ein DS (Delegation Signer)-Eintrag wird in der übergeordneten Zone veröffentlicht (z. B. .com), wodurch die Vertrauenskette zurück zur Root hergestellt wird

Die Aktivierung von DNSSEC wird dringend für jede Domain empfohlen, die Finanztransaktionen, Authentifizierung oder E-Mail verarbeitet. Falsch konfiguriertes DNSSEC — insbesondere eine abgelaufene Signatur oder ein nicht übereinstimmender DS-Eintrag — führt bei validierenden Resolvern zu einem vollständigen Auflösungsfehler, was ein schwerwiegenderer Fehlermodus ist als kein DNSSEC.

Häufige DNS-Fehler und wie man sie diagnostiziert

NXDOMAIN — Nicht existierende Domain

Der autoritative Server hat bestätigt, dass die Domain nicht existiert. Häufige Ursachen: Tippfehler im Domainnamen, abgelaufene Domain-Registrierung, gelöschter DNS-Eintrag.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — Serverfehler

Der Resolver konnte die Abfrage nicht abschließen. Häufige Ursachen: DNSSEC-Validierungsfehler, nicht erreichbarer autoritativer Server, falsch konfigurierte Zonendatei.

dig +dnssec example.com
# Look for: status: SERVFAIL

Um die DNSSEC-Validierung zu umgehen und das Problem zu isolieren:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Veralteter Cache / Propagationsverzögerung

Nach der Aktualisierung eines DNS-Eintrags bleiben alte Werte in Resolver-Caches bestehen, bis die TTL abläuft. Um den autoritativen Server direkt abzufragen und den Resolver-Cache zu umgehen:

dig @ns1.example.com www.example.com

DNS-Propagation global prüfen

Verwenden Sie dig mit spezifischen öffentlichen Resolvern, um den Propagationsstatus zu prüfen:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS in Hosting-Umgebungen: Praktische Konfigurationen

Wenn Sie eine Website oder Anwendung auf einem VPS mit cPanel bereitstellen, wird die DNS-Verwaltung typischerweise über WHMs DNS-Cluster oder cPanels Zone-Editor abgewickelt. Das Verständnis der zugrunde liegenden Zonendateistruktur ermöglicht es Ihnen, Änderungen vorzunehmen, die die GUI nicht zugänglich macht.

Eine minimale Zonendatei für example.com sieht wie folgt aus:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Damit E-Mail-Hosting korrekt funktioniert, muss der MX-Eintrag auf einen Hostnamen zeigen (nicht direkt auf eine IP-Adresse), und dieser Hostname muss selbst über einen A-Eintrag auflösbar sein. Eine häufige Fehlkonfiguration ist das direkte Verweisen von MX auf eine IP — dies verstößt gegen RFC 2821 und verursacht Zustellungsfehler bei strengen Mailservern.

DNS-Performance: Was die Auflösungsgeschwindigkeit tatsächlich beeinflusst

• Resolver-Nähe: Ein Resolver, der geografisch nah am Client (oder im selben Netzwerk) ist, reduziert die Round-Trip-Zeit erheblich.
• Cache-Trefferrate: Stark frequentierte Domains mit angemessenen TTLs werden fast immer aus dem Cache bedient. Kalte Cache-Auflösung ist 5–20-mal langsamer.
• Anycast-Routing: Root-Server und große öffentliche Resolver verwenden Anycast und leiten Abfragen automatisch zum nächstgelegenen physischen Knoten weiter.
• Anzahl der DNS-Lookups pro Seite: Eine einzelne Webseite kann 20–50 DNS-Abfragen auslösen (CDN-Assets, Analytics, Schriftarten, Werbenetzwerke). Browser parallelisieren diese, aber jeder eindeutige Hostname erfordert seinen eigenen Lookup.
• DNS-Prefetching: Moderne Browser unterstützen <link rel="dns-prefetch" href="//cdn.example.com">, um Hostnamen von Drittanbietern aufzulösen, bevor sie benötigt werden, was die wahrgenommene Latenz reduziert.

DNS vs. alternative Auflösungsmechanismen

Die /etc/hosts-Datei wird auf praktisch jedem Betriebssystem vor DNS ausgewertet. Dies macht sie für die lokale Entwicklung unschätzbar wertvoll — Sie können myapp.local auf 127.0.0.1 abbilden, ohne DNS-Infrastruktur zu berühren.

Wichtige Erkenntnisse und Entscheidungs-Checkliste

Verwenden Sie diese Checkliste beim Konfigurieren oder Troubleshooting von DNS für jede Produktionsumgebung:

• Vor jeder Server-Migration: TTL mindestens 48 Stunden im Voraus auf 300 Sekunden senken
• Für E-Mail-Zustellbarkeit: Überprüfen Sie, ob MX, SPF (TXT), DKIM (TXT), DMARC (TXT) und PTR-Einträge alle korrekt konfiguriert sind
• Für Sicherheit: DNSSEC für Ihre Domain aktivieren und CAA-Einträge hinzufügen, um die Zertifikatsausstellung einzuschränken
• Für Datenschutz: DoT oder DoH auf Client-Geräten und Servern verwenden; Vermeiden Sie das Senden von Klartext-DNS über nicht vertrauenswürdige Netzwerke
• Für Performance: TTL für stabile Einträge auf 3600–86400 setzen; 300 nur für Einträge verwenden, die sich häufig ändern
• Für Diagnosen: Den autoritativen Server immer direkt mit dig @ns1.yourdomain.com abfragen, um Propagationsverzögerungen von echten Fehlkonfigurationen zu unterscheiden
• Für Zonenverwaltung: Die SOA-Seriennummer bei jeder Änderung einer Zonendatei erhöhen — Resolver verwenden sie zur Erkennung von Änderungen
• Für Hosting: Bestätigen Sie, dass die Nameserver-Delegation Ihres Registrars mit den NS-Einträgen in Ihrer Zonendatei übereinstimmt — eine Diskrepanz ist die häufigste Ursache für „DNS funktioniert nicht” nach einem Domain-Transfer

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem DNS-Resolver und einem autoritativen DNS-Server?

Ein rekursiver Resolver (z. B. 8.8.8.8) ist ein Vermittler, der die DNS-Hierarchie im Namen Ihres Geräts abfragt und Ergebnisse cached. Ein autoritativer Nameserver hält die eigentlichen Zoneneinträge für eine bestimmte Domain und liefert definitive Antworten. Ihr Resolver fragt viele autoritative Server ab; der autoritative Server Ihrer Domain antwortet nur für die Zonen, die er hostet.

Warum dauert die DNS-Propagation nach der Aktualisierung eines Eintrags Zeit?

Propagationsverzögerungen werden durch TTL-basiertes Caching verursacht. Jeder Resolver, der Ihren alten Eintrag zuvor gecacht hat, wird ihn weiterhin bereitstellen, bis die TTL abläuft. Wenn Ihre TTL 86400 (24 Stunden) betrug, können Resolver den alten Eintrag bis zu 24 Stunden nach Ihrer Aktualisierung bereitstellen. Dies ist kein Fehler — es ist der beabsichtigte Caching-Mechanismus, der DNS skalierbar macht.

Was ist ein DNS-Leak und warum ist er wichtig?

Ein DNS-Leak tritt auf, wenn Ihr Gerät DNS-Abfragen außerhalb Ihres beabsichtigten Resolvers sendet — typischerweise den Resolver Ihres ISP — auch wenn Sie ein VPN oder ein Datenschutztool verwenden. Dies legt Ihre Browsing-Aktivität gegenüber Ihrem ISP offen. Sie können auf Leaks unter dnsleaktest.com testen und diese beheben, indem Sie Ihren VPN-Client so konfigurieren, dass DNS-Routing durch seinen eigenen Resolver erzwungen wird.

Kann DNS als Angriffsvektor verwendet werden?

Ja. Häufige DNS-basierte Angriffe umfassen Cache-Poisoning (Einschleusen falscher Einträge in den Cache eines Resolvers), DNS-Amplifikations-DDoS (Verwendung offener Resolver, um ein Ziel mit großen DNS-Antworten zu überfluten), DNS-Hijacking (Umleitung von Abfragen auf bösartige Server) und DNS-Tunneling (Exfiltration von Daten durch Kodierung in DNS-Abfragezeichenfolgen). DNSSEC mindert Cache-Poisoning; Rate-Limiting und Response-Rate-Limiting (RRL) auf autoritativen Servern mindern Amplifikation.

Wie finde ich die autoritativen Nameserver für eine beliebige Domain?

Verwenden Sie dig mit dem NS-Eintragstyp und dem +short-Flag für eine übersichtliche Ausgabe:

dig NS example.com +short

Um den vollständigen Delegationspfad von Root zu autoritativ zu verfolgen, verwenden Sie:

dig +trace example.com

Dies zeigt jeden Verweis-Hop — Root → TLD → Autoritativ — was die zuverlässigste Methode zur Diagnose von Delegations-Fehlkonfigurationen ist.