Das Internet-Lexikon

Wie funktioniert DNS?

Eine verständliche Erklärung, wie das Domain Name System Anfragen von der Domain bis zur IP-Adresse auflöst, welche Sonderfälle in der Praxis auftauchen und wie sich DNS-Probleme gezielt eingrenzen lassen.

Wenn eine Adresse wie das-internet-lexikon.de in den Browser eingegeben wird, läuft im Hintergrund eine Kette von Anfragen ab, die in der Regel binnen Millisekunden die passende IP-Adresse liefert. Dieser Artikel geht Schritt für Schritt durch den Ablauf, zeigt die Rolle von TTL und Caching im Detail und behandelt die Sonderfälle, an denen DNS in der Praxis am häufigsten für Verwirrung sorgt.

1. Lokaler Cache

Der Browser prüft zunächst seinen eigenen DNS-Cache sowie den des Betriebssystems. Wurde die Domain kürzlich bereits aufgelöst und ist die gespeicherte Antwort noch gültig, wird sie direkt verwendet - ohne weitere Netzwerkanfrage. Diese Ebene ist der Grund, warum ein und derselbe Rechner eine Domain manchmal noch mit einer alten IP-Adresse erreicht, obwohl der DNS-Eintrag längst geändert wurde: Der Cache kennt die Änderung schlicht noch nicht.

2. Rekursiver Resolver

Liegt keine gültige, zwischengespeicherte Antwort vor, wendet sich der Rechner an einen rekursiven DNS-Resolver, meist bereitgestellt vom Internetanbieter oder einem öffentlichen Dienst wie einem öffentlichen DNS-Anbieter. Dieser Resolver übernimmt die eigentliche Auflösungsarbeit stellvertretend für den anfragenden Rechner und führt dabei selbst mehrere Teilanfragen aus, bis er eine vollständige Antwort hat.

3. Root- und TLD-Server

Der Resolver fragt zunächst einen der Root-Server-Cluster, welcher Server für die Top-Level-Domain (z. B. .de) zuständig ist. Anschließend fragt er diesen TLD-Server, welcher Nameserver für die konkrete Domain zuständig ist. Dieser Weg von oben nach unten durch die Namenshierarchie ist der Grund, warum DNS als hierarchisches, verteiltes System funktioniert: Keine einzelne Stelle kennt alle Domains der Welt, jede Ebene kennt nur, wer für die nächste Ebene zuständig ist.

4. Autoritativer Nameserver

Der zuständige (autoritative) Nameserver der Domain liefert schließlich den passenden DNS-Record - etwa einen A-Record mit der IPv4-Adresse des Webservers, oder einen AAAA-Record für IPv6. Diese Records werden bei der Domain-Registrierung bzw. -Verwaltung gesetzt und sind genau die Einträge, die beim Domain-Umzug oder bei der Einrichtung eines neuen Mailservers angepasst werden müssen.

5. Antwort und Caching entlang der TTL

Der Resolver gibt die IP-Adresse an den anfragenden Rechner zurück und speichert sie entsprechend der TTL (Time to Live) für weitere Anfragen zwischen. Die TTL wird vom autoritativen Nameserver pro Record festgelegt und gibt in Sekunden an, wie lange ein Resolver die Antwort ungefragt wiederverwenden darf, bevor er erneut nachfragt. Eine niedrige TTL (z. B. 300 Sekunden) sorgt für schnellere Sichtbarkeit von Änderungen, erzeugt aber mehr Anfragelast; eine hohe TTL (z. B. 86400 Sekunden, ein Tag) entlastet die Infrastruktur, verzögert aber die Verbreitung von Änderungen entsprechend. Erst nachdem die IP-Adresse feststeht, kann der Browser eine HTTP-Verbindung zum Server aufbauen - DNS-Auflösung ist damit ein vorgelagerter Schritt, der bei jeder neuen Verbindung zu einem noch nicht gecachten Host erneut anfällt.

6. Warum “DNS-Propagation” kein globaler Schaltmoment ist

Ein verbreitetes Missverständnis ist, DNS-Änderungen würden nach einer festen Wartezeit “weltweit gleichzeitig” wirksam. Tatsächlich hält jeder Resolver, der einen Eintrag bereits abgefragt hat, seine eigene Kopie bis zum Ablauf der TTL, die er beim letzten Abruf erhalten hat. Das bedeutet: Ein Nutzer, dessen Resolver die alte Antwort erst kurz vor der Änderung abgerufen hat, sieht die neue IP-Adresse unter Umständen erst nach voller TTL-Dauer, während ein anderer Nutzer mit einem Resolver, der die Domain noch nie abgefragt hat, sofort die neue Adresse erhält. Es gibt keinen zentralen Zeitpunkt, zu dem “die Propagation abgeschlossen” ist - nur das schrittweise Ablaufen vieler unabhängiger Caches.

7. Warum ein TTL-Wert vor einer geplanten Änderung gesenkt werden sollte

Wer einen Domain-Umzug plant, sollte die TTL des betroffenen Records rechtzeitig vorher - mindestens für die Dauer der bisherigen TTL - auf einen niedrigen Wert senken. Grund: Eine TTL-Änderung selbst unterliegt derselben Cache-Logik wie der Record-Wert. Wird die TTL erst am Tag der eigentlichen Änderung von einem hohen auf einen niedrigen Wert gesetzt, haben viele Resolver zu diesem Zeitpunkt bereits die alte, hohe TTL zwischengespeichert und fragen entsprechend spät erneut nach.

8. Negative Caching

Auch das Fehlen eines Eintrags wird zwischengespeichert: Fragt ein Resolver einen Record ab, der (noch) nicht existiert, speichert er diese negative Antwort für eine gewisse Zeit. Das erklärt einen häufigen Praxisfall: Ein neu angelegter Subdomain-Eintrag ist auf dem autoritativen Nameserver längst vorhanden, wird von einem bestimmten Resolver aber trotzdem noch als “nicht gefunden” gemeldet, weil dieser Resolver die vorherige negative Antwort noch nicht verworfen hat.

9. Mehrere Record-Typen für eine Domain

Eine Domain hat üblicherweise nicht nur einen A-Record, sondern mehrere unterschiedliche Record-Typen gleichzeitig: A/AAAA für die Webserver-Adresse, MX für zuständige Mailserver, TXT für Verifizierungs- und Richtlinienzwecke (etwa SPF-Einträge), und CNAME, wenn eine Subdomain auf einen anderen Hostnamen statt auf eine eigene IP-Adresse verweist. Diese Records werden unabhängig voneinander abgefragt und gecacht - ein funktionierender A-Record sagt nichts darüber aus, ob der MX-Record korrekt konfiguriert ist, und umgekehrt.

10. Häufige Fehler

Ein wiederkehrender Fehler ist, nach einer DNS-Änderung sofort von einem globalen, einheitlichen Zustand auszugehen und bei abweichenden Testergebnissen von unterschiedlichen Standorten aus die eigene Konfiguration für fehlerhaft zu halten, obwohl lediglich unterschiedliche Resolver-Caches unterschiedlich weit fortgeschritten sind. Ein zweiter häufiger Fehler ist, beim Domain-Umzug die TTL erst am Umzugstag zu senken statt vorher, wodurch die eigentliche Umschaltung unnötig lange dauert. Ein dritter Fehler betrifft CNAME-Records: Ein CNAME darf laut Spezifikation nicht neben anderen Records desselben Namens existieren (z. B. kein gleichzeitiger MX-Record für denselben Namen), was bei unachtsamer Konfiguration zu unklaren Fehlern führt.

11. Wie prüfst du das

Klassische Kommandozeilenwerkzeuge wie dig oder nslookup fragen einen bestimmten DNS-Record direkt ab und zeigen dabei auch die aktuell gültige TTL an. Mit dig lässt sich zudem gezielt ein bestimmter Nameserver statt des Standard-Resolvers abfragen (z. B. dig @8.8.8.8 domain.de), um zu prüfen, ob eine Änderung auf dem autoritativen Server überhaupt schon angekommen ist, unabhängig vom eigenen, möglicherweise veralteten lokalen Cache. Zeigt eine solche direkte Abfrage bereits den neuen Wert, während der eigene Rechner weiterhin den alten liefert, ist die Ursache eindeutig ein noch nicht abgelaufener lokaler oder Resolver-seitiger Cache - keine fehlerhafte Konfiguration.

12. Entscheidungshilfe bei DNS-Problemen

  1. Liefert eine direkte Abfrage des autoritativen Nameservers den korrekten Wert? Wenn nein, liegt das Problem in der DNS-Konfiguration selbst, nicht im Caching.
  2. Liefert die direkte Abfrage den korrekten Wert, aber der eigene Rechner noch den alten? Dann handelt es sich um einen noch nicht abgelaufenen Cache - abwarten bis zum TTL-Ablauf oder den lokalen Cache manuell leeren.
  3. Funktioniert ein Record-Typ (z. B. A), ein anderer (z. B. MX) aber nicht? Records unabhängig voneinander prüfen, da sie separat konfiguriert und gecacht werden.
  4. Steht ein Umzug bevor? TTL rechtzeitig vorher senken, nicht erst am Tag der Umstellung.

Weiterführend