Zusammenfassung

  • RFC 8767 erlaubt einem rekursiven Resolver, geeignete abgelaufene DNS-Daten zu verwenden, wenn die autoritative Aktualisierung scheitert; Daten mit einer ursprünglichen TTL von null bleiben davon ausgeschlossen.
  • Die gewonnene Verfügbarkeit verschiebt vorübergehend Kontrolle: Der Zonenbetreiber hat die TTL veröffentlicht, doch der Resolverbetreiber bestimmt Wartezeit, Fehlerklassifikation und maximale stale-Dauer.
  • EDE-Codes können eine Stale Answer sichtbar machen. Sie authentisieren die alten Daten jedoch nicht und erteilen keine geschäftliche oder sicherheitstechnische Freigabe.

Analyse

Nehmen wir an, ein Dienst zieht auf eine neue IP-Adresse um. Der Zonenbetreiber veröffentlicht den neuen Wert und lässt die TTL des alten Eintrags auslaufen. Die meisten Resolver lernen die Änderung rechtzeitig. Ein Resolver erreicht den Ablaufzeitpunkt jedoch während eines vollständigen Ausfalls der autoritativen Server. Ein Fehler unterbricht den Zugriff. Die alte Adresse kann den Dienst weitertragen, sie kann aber ebenso bereits abgeschaltet, neu vergeben oder aus einer Sicherheitsgrenze entfernt worden sein.

Die TTL bildet traditionell die Zeitgrenze dieser Unsicherheit. RFC 1035 beschreibt sie als Zeitraum, in dem ein Resource Record zwischengespeichert werden darf, bevor die Quelle erneut befragt und der Cache-Eintrag verworfen werden soll. RFC 2181 stellt klar, dass die TTL eine maximale Lebensdauer und keine Pflicht zur vollständigen Aufbewahrung ist. Im Normalfall veröffentlicht die Zone die Grenze, und der Resolver beendet die Wiederverwendung bei Ablauf.

RFC 8767 schafft eine Ausnahme für eine fehlgeschlagene Aktualisierung. Kann der Resolver abgelaufene Daten nicht autoritativ erneuern, darf er sie behalten und so verwenden, als seien sie noch gültig. Daraus folgt kein Dauerbetrieb nach dem Muster „zuerst alt antworten, später aktualisieren“. Eine jüngste, ernsthafte Aktualisierungsanfrage muss gescheitert sein. Auch nach der stale-Antwort soll der Resolver bis zum Ende seines gesamten Auflösungszeitraums weiter nach aktuellen Daten suchen.

Eine TTL von null bleibt eine harte Grenze. Ein solcher Eintrag darf nur in der laufenden Transaktion verwendet und nicht als späterer stale-Rückfall gespeichert werden. Gibt der Resolver tatsächlich abgelaufene Records zurück, muss er ihnen in der Antwort eine positive TTL geben. RFC 8767 empfiehlt 30 Sekunden. Das vermeidet bekannte Probleme mancher Implementierungen mit null und begrenzt unmittelbare Wiederholungsanfragen nachgelagerter Caches.

Vier Zeitgeber tragen unterschiedliche Entscheidungen. Der Client-Response-Timer legt fest, wie lange ein Nutzer auf eine frische Antwort wartet, bevor stale-Daten erwogen werden; das Beispiel nennt ungefähr 1,8 Sekunden. Der Query-Resolution-Timer begrenzt die gesamte Arbeit für eine aktuelle Antwort. Der Failure-Recheck-Timer steuert, wie häufig fehlerhafte autoritative Pfade erneut geprüft werden. Der Maximum-Stale-Timer bestimmt, wie lange ein abgelaufener Eintrag überhaupt Kandidat bleibt; als praktische Spanne werden ein bis drei Tage vorgeschlagen.

Diese Werte müssen nicht netzübergreifend übereinstimmen. RFC 8767 behandelt serve-stale als lokale Operation des rekursiven Resolvers und überlässt die Variablen Implementierung und Betreiber. Zwei standardkonforme Resolver können deshalb im selben Ausfall auf denselben Namen unterschiedlich antworten. Der eine bewahrt den alten Wert, der andere liefert einen Fehler. Darin zeigt sich eine Risikopolitik — Unterbrechung gegen Überalterung — und nicht zwingend ein Protokollfehler.

Die Bedeutung der autoritativen Antwort beendet die Ausnahme. Eine autoritative NOERROR- oder NXDOMAIN-Antwort mit gesetztem AA-Bit aktualisiert den Zustand und ersetzt die vorherigen Daten. Andere Antwortcodes sagen normalerweise nicht aus, was am Namen jetzt existiert. Sie gelten daher als fehlgeschlagene Aktualisierung und lassen den bisherigen Cache bestehen. SERVFAIL ist kein Nachweis, dass die alte Adresse weiterhin stimmt; es zeigt nur, dass keine brauchbare aktuelle Antwort vorliegt.

Davon zu trennen ist der Fehlercache aus RFC 9520. Resolver müssen Auflösungsfehler mindestens eine Sekunde und höchstens fünf Minuten speichern, damit übereinstimmende Anfragen während dieser Zeit keine wiederholte Arbeit nach oben auslösen. Dieser Cache hält das Scheitern eines Auflösungsversuchs fest. Serve-stale nutzt einen früheren Antwortwert. Das eine dämpft Wiederholungsstürme, das andere verändert die dem Client gelieferten Daten.

RFC 8914 macht die Entscheidung diagnostisch erkennbar. Extended DNS Error Code 3 steht für Stale Answer, Code 19 für Stale NXDOMAIN Answer. Diese Angaben sind für Telemetrie wertvoll, erzeugen aber keine zusätzliche Autorität. EDE-Informationen sind ohne geschützte DNS-Transaktion nicht authentisiert und dürfen die Protokollverarbeitung nicht verändern. Der Code erklärt den gewählten Pfad; er bestätigt nicht die Sicherheit des alten Werts.

Die Kosten unterscheiden sich je Record. Eine alte A- oder AAAA-Adresse kann einen unveränderten Dienst erhalten oder Verkehr zu einem ausgemusterten System zurückschicken. Ein alter CNAME kann eine bereits entfernte Abhängigkeit wiederherstellen. RFC 8767 weist außerdem darauf hin, dass Signaturen ablaufen können, dass stale NSEC- oder NSEC3-Daten neue TLSA- oder DS-Einträge verzögern können und dass ein Angreifer mit der Fähigkeit, autoritative Erreichbarkeit zu stören, die praktische Lebensdauer alter Informationen verlängern könnte.

Das sind durch die Standards belegte Risiken, keine Aussage über die Konfiguration oder Erfahrung eines benannten Resolverbetreibers. Das Faktenpaket belegt weder Einführung noch Nutzen oder Schaden für eine bestimmte Flotte. Es belegt die Kontrollkette: Der Zonenbetreiber veröffentlicht Daten und TTL, der rekursive Betreiber klassifiziert den Fehler und setzt die Zeitgeber, und der Client trägt das Ergebnis.

Quellen