Was ist ein DNS-Cache, und wie lange bleiben Einträge darin?

Wo wird eine DNS-Antwort tatsächlich zwischengespeichert?

Eine einzelne Abfrage durchläuft mehrere Caches, bevor Sie überhaupt etwas bemerken, und jeder hält seine eigene Kopie für seine eigene Dauer:

• Der Browser. Chrome, Edge und Firefox führen jeweils einen eigenen kleinen DNS-Cache, getrennt vom Betriebssystem. Chromes ist unter chrome://net-internals/#dns sichtbar, und ihn zu leeren betrifft nur diesen Browser, nicht den Rest der Maschine.
• Der Stub-Resolver des Betriebssystems. Windows betreibt den DNS-Client-Dienst und cacht Antworten, die Sie mit ipconfig /displaydns auflisten können; macOS cacht über mDNSResponder; die meisten Linux-Desktops betreiben systemd-resolved, einen lokalen zwischenspeichernden Stub-Resolver, den Sie mit resolvectl abfragen. Das ist ein echter Cache mit eigenem TTL-Countdown, nicht nur eine Kopie dessen, was der Browser hat.
• Der Router. Die meisten Heimrouter betreiben einen kleinen DNS-Forwarder, der aus dem eigenen Cache antwortet, bevor er eine Abfrage stromaufwärts weiterreicht, weshalb ein Router-Neustart manchmal ein DNS-Problem behebt, das eigentlich woanders lag.
• Der rekursive Resolver. Der Resolver Ihres Internetanbieters oder ein öffentlicher, bearbeitet die meisten Abfragen im Internet und hält den größten und am meisten geteilten Cache. Hat er einmal eine Antwort, bekommt jedes Gerät, das ihn fragt, die zwischengespeicherte Kopie, bis sie abläuft.

Jede Schicht ist unabhängig. Den Cache auf Ihrem Laptop zu leeren, ändert nichts an dem Cache, den Ihr Router oder Ihr Internetanbieter noch hält, und es ändert nichts für irgendjemandes andere Maschine.

Was ist eine TTL, und wer hält sich tatsächlich daran?

Jeder DNS-Eintrag trägt eine Time to Live: eine Zahl in Sekunden, festgelegt von der Person, die die Zone verwaltet, die einem Resolver sagt, wie lange er die Antwort wiederverwenden darf, bevor er erneut fragt. RFC 1035 definiert sie als das Intervall, in dem ein Eintrag „zwischengespeichert werden darf, bevor die Quelle der Information erneut konsultiert werden sollte", und eine TTL von null bedeutet, dass die Antwort überhaupt nicht zwischengespeichert werden darf.

Jeder Cache in der Kette, Browser, Stub-Resolver, Router, rekursiver Resolver, soll diese Zahl beachten und ab dem Moment herunterzählen, in dem er den Eintrag erstmals abgerufen hat. In der Praxis wenden manche Resolver von Internetanbietern eine eigene Untergrenze an, üblicherweise eine Stunde oder mehr, unabhängig davon, was die Zone als TTL vorgibt. Deshalb hilft das Senken einer TTL, um eine künftige Änderung zu beschleunigen, den meisten Resolvern, ist aber keine Garantie für jeden Einzelnen.

Was ist negatives Caching, und warum kann ein brandneuer Eintrag verschwunden bleiben?

Ein Resolver cacht nicht nur existierende Einträge. Kommt eine Abfrage mit „kein solcher Name" (NXDOMAIN) oder ohne Eintrag des angefragten Typs zurück, wird auch dieser Fehlschlag zwischengespeichert, ein Verhalten namens negatives Caching. RFC 2308 legt die Lebensdauer des negativen Caches über das Minimum-Feld des SOA-Eintrags fest, und RFC 9520 macht das Cachen dieses Fehlschlags inzwischen für einen konformen Resolver verpflichtend statt optional.

Das ist der Mechanismus hinter einem bekannten Problem: Sie legen eine neue Subdomain an, fragen sie eine Sekunde zu früh ab, bekommen NXDOMAIN, und der Resolver merkt sich „existiert nicht" für die Dauer der negativen TTL der Zone, obwohl der Eintrag inzwischen existiert. Windows macht die beiden Arten von Eintrag getrennt sichtbar: ipconfig /displaydns listet sowohl die positiven Antworten als auch die negativen, und ipconfig /flushdns verwirft negative Cache-Einträge ausdrücklich als Teil des Leerens.

Warum löst sich eine Website für Sie auf und für jemand anderen nicht?

Weil es keinen einzigen gemeinsamen Cache gibt. Zwei Personen, die zwei verschiedene Resolver fragen, oder denselben Resolver zu zwei verschiedenen Momenten, können zwei verschiedene Antworten für denselben Namen bekommen. Die Kopie des einen Resolvers ist vielleicht noch frisch von einer Abfrage vor einer Stunde; ein anderer hat den Namen vielleicht nie gesehen und holt den aktuellen Wert. Keiner der beiden liegt falsch, sie haben nur unterschiedliche Uhren. Passiert das kurz nachdem Sie einen Eintrag geändert haben, geht so prüfen Sie die DNS-Propagation durch, wie Sie mehrere Resolver nebeneinander vergleichen und ablesen, wie viel Zeit jedem noch bleibt.

Wie lesen Sie die TTL eines noch zwischengespeicherten Eintrags?

Fragen Sie den Namen direkt ab und behalten Sie die vollständige Ausgabe statt der kurzen Form:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

Die Zahl vor dem Eintragstyp, 847 in diesem Beispiel, sind die verbleibenden Sekunden, bevor die Kopie genau dieses Resolvers abläuft; es ist nicht die ursprüngliche TTL des Eintrags, die nur der autoritative Server mit Sicherheit nennen kann. Führen Sie dieselbe Abfrage ein paar Sekunden später erneut aus, und die Zahl ist um ungefähr so viele Sekunden gesunken, was bestätigt, dass Sie einen laufenden Countdown lesen und keine statische Einstellung. Löst sich ein Name gar nicht erst auf, statt mit einer niedrigen Zahl zu antworten, ist das ein anderer Fehler: so leeren Sie DNS behandelt zunächst das Leeren Ihres eigenen Caches, und was ein DNS-Resolver tatsächlich tut behandelt, was als Nächstes in der Kette passiert, wenn Ihr eigener Cache nicht das Problem ist.

Ein Cache erklärt, warum ein Besucher eine Änderung sofort sieht und ein anderer nicht; er erklärt keinen Eintrag, der sich nirgendwo je aktualisiert. Führen Sie mit dem DNS-Abfragewerkzeug eine Live-Abfrage aus, um die aktuelle Antwort von außerhalb des eigenen Netzwerks zu sehen, und muss die Website nach Zeitplan erreichbar bleiben statt nur einmal geprüft zu werden, ist dafür verteiltes Monitoring von vielen Prüfpunkten da. HostTracker überwacht Websites seit 2004, beobachtet inzwischen über 500.000 Websites von mehr als 300 Prüfpunkten in 158 Städten und alarmiert per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr, wenn eine Prüfung fehlschlägt, einschließlich einer Prüfung, die eine bestimmte IP-Adresse erwartet und in dem Moment Alarm schlägt, in dem sich die Antwort ändert.

Häufig gestellte Fragen

Verlangsamt ein voller DNS-Cache meinen Computer?

Nein. Ein DNS-Cache ist eine kleine Tabelle aus Namen und Adressen, typischerweise höchstens ein paar Hundert Einträge, und ein Nachschlagen kostet nichts Messbares. Fühlen sich Abfragen langsam an, liegt es nicht am Cache selbst; ein entfernter oder überlasteter Resolver ist die übliche Ursache.

Behebt das Leeren meines Caches auch etwas für andere?

Nein. ipconfig /flushdns, dscacheutil -flushcache und resolvectl flush-caches leeren nur den Cache auf der Maschine, auf der Sie sie ausführen. Alle anderen lesen weiterhin aus ihrem eigenen Browser, ihrem eigenen Router und ihrem eigenen Resolver, jeder nach seiner eigenen Uhr.

Ist ein DNS-Cache dasselbe wie ein CDN-Cache?

Nein, auch wenn die beiden verwechselt werden. Ein DNS-Cache speichert die Antwort auf „welche IP-Adresse gehört zu diesem Namen". Ein CDN-Cache speichert den eigentlichen Seiten- oder Dateiinhalt auf einem Server nahe am Besucher. Das eine zu leeren, hat keine Wirkung auf das andere.

Kann ich meine eigene TTL setzen, wenn ich die Domain nicht verwalte?

Nein. Die TTL ist eine Eigenschaft des Eintrags, festgelegt in der autoritativen Zone von der Person, die die DNS der Domain verwaltet. Als Besucher haben Sie nur den Hebel, sich für einen Resolver zu entscheiden, der eine kurze TTL respektiert, statt für einen, der seine eigene Untergrenze erzwingt.

Warum ändert sich die TTL, die ich sehe, bei jeder Abfrage?

Weil Sie einen anderen Resolver fragen oder denselben zu einem anderen Moment seines Countdowns. Fragen Sie den autoritativen Nameserver direkt ab mit dig example.com @ns1.yourdns.example, um die TTL so zu sehen, wie sie ursprünglich gesetzt wurde, ohne dass bereits etwas heruntergezählt wurde.