Zusammenfassung

  • RFC 8767 gestattet einem rekursiven Resolver, nach einem ernsthaften, aber erfolglosen autoritativen Aktualisierungsversuch abgelaufene Cache-Daten zu liefern. Diese Kontinuität ist eine lokale Ausnahme des Resolver-Betreibers.
  • Nachprüfbar bleibt sie nur, wenn ursprüngliche TTL, Ablaufalter, maximale Stale-Frist, Antwort-TTL, DNSSEC-Zustand, Fehlerklasse, Resolver-Kohorte und Wiederherstellung getrennt dokumentiert werden.

Die Zone enthält die Adresse nicht mehr. Ein Sicherheitsteam hat sie nach einer Kompromittierung entfernt, und die vorher veröffentlichte TTL ist verstrichen. Trotzdem erhält ein Teil der Nutzer weiterhin das alte Ziel. Der Grund muss kein verspäteter autoritativer Knoten sein. Ein rekursiver Resolver kann die Behörden nicht erreichen und zieht seinen abgelaufenen Cache einem Fehler vor.

Das Szenario ist konstruiert. Es behauptet weder einen konkreten Vorfall noch eine verbreitete Produkteinstellung. Es macht sichtbar, welche Schuld eine Verfügbarkeitsentscheidung erzeugt: Der Resolver hält den Dienst erreichbar, muss dafür aber erklären, wie lange er eine Aussage verwendet, deren gewöhnliche Frischegarantie beendet ist.

Serve Stale nach RFC 8767 gestattet genau diese begrenzte Entscheidung. Nach TTL-Ablauf soll die Quelle erneut befragt werden. Scheitert die autoritative Aktualisierung, darf der Resolver gespeicherte Daten so verwenden, als wären sie nicht abgelaufen. Das „als wären“ ist keine neue Veröffentlichung.

Zwei Fristen gehören in zwei Bücher

Innerhalb der TTL stützt sich die Wiederverwendung auf die Zeitangabe des Zonenherausgebers. Danach stützt sie sich auf lokale Resolver-Politik. Dieselben Bytes wechseln damit ihren Entscheidungsträger.

Eine maximale Cache-TTL kann übermäßig große empfangene Werte begrenzen. RFC 8767 empfiehlt eine Größenordnung von Tagen bis Wochen und nennt sieben Tage. Der maximale Stale-Timer beginnt dagegen am regulären Ablauf und bestimmt, wie lange die abgelaufene Kopie noch als Kandidat erhalten bleibt. Das Dokument beschreibt ihn als konfigurierbar und erläutert, dass ein bis drei Tage viele Störungen überbrücken können. Daraus folgt keine allgemeine Pflicht.

Der Nachweis benötigt daher Einfügezeit, ursprüngliche TTL, berechneten Ablauf, aktuelles Alter, maximale Stale-Grenze und die TTL der Client-Antwort. Wer nur „TTL 30“ speichert, kann eine stundenalte Kopie für eine dreißig Sekunden alte Veröffentlichung halten. Die kurze sichtbare TTL ist meist ein Taktgeber für nachgelagerte Caches, nicht eine Bestätigung des Herausgebers.

Diese Trennung ist mehr als Buchhaltung. Sie verhindert, dass der Betreiber einer Zone für eine Verlängerung verantwortlich gemacht wird, die allein der rekursive Dienst beschlossen hat.

Vier Uhren schützen vier Interessen

RFC 8767 schreibt bewusst keinen einzigen Algorithmus vor. Das Beispiel trennt vier Timer.

Der Client-Response-Timer begrenzt die Wartezeit, bevor Stale-Daten erwogen werden; 1,8 Sekunden werden empfohlen. Der Query-Resolution-Timer begrenzt den gesamten iterativen Aufwand, häufig auf zehn bis dreißig Sekunden. Der Failure-Recheck-Timer verhindert übermäßige Wiederholungen gegenüber einer bereits fehlerhaften Quelle; das Beispiel empfiehlt dreißig Sekunden. Der maximale Stale-Timer zieht die endgültige Altersgrenze.

Ein Schalter mit der Beschriftung „Serve Stale aktiv“ sagt über diese Abwägungen fast nichts. Kurze Client-Zeit verbessert die Reaktion, kann aber eine lediglich langsame Autorität zu früh durch Altdaten ersetzen. Ein langer Recheck schützt ein bedrängtes System, erkennt die Rückkehr jedoch später. Eine lange Aufbewahrung übersteht große Ausfälle, hält aber verlassene Ziele und alte Sicherheitszustände fest.

Vor der Ausgabe muss ein aktueller, gutgläubiger Aktualisierungsversuch stehen. Die Regel ist keine Erlaubnis, stets zuerst den alten Cache zu liefern. Auch nach der Stale-Antwort sollte die Auflösung bis zu ihrer eigenen Grenze fortgesetzt werden. Die Ausnahme verschafft Zeit; sie ersetzt die Wiederherstellung nicht.

Ein Aktualisierungsfehler braucht eine genaue Bezeichnung

Eine autoritative Antwort mit NOERROR oder NXDOMAIN und gesetztem AA erneuert den Zustand nach RFC 8767. Gerade NXDOMAIN darf nicht als bloß unerwünschter Fehler behandelt werden. Hat der Herausgeber einen Namen absichtlich gelöscht, kann der Resolver die alte positive Antwort nicht im Namen der Kontinuität behalten. Eine allgemeine Unterscheidung zwischen beabsichtigter Löschung und Fehlkonfiguration existiert nicht.

Timeout, unerreichbares Netz, SERVFAIL, REFUSED, fehlerhafte Nachricht, DNSSEC-Fehler und lame delegation sind ebenfalls verschieden. Sie verweisen auf andere Ursachen und Verantwortliche. RFC 2308 begrenzt gespeicherte Serverfehler- und Unerreichbarkeitsindikationen auf fünf Minuten.

Ein Prüfpfad sollte jeden autoritativen Endpunkt, Adresse, Transport, Zeitpunkt, RCODE, AA, Validierung und Netzfehler enthalten. Hinzu kommen Delegationsaktualisierung, RD, CD und DO, Cache-Schlüssel sowie positive, NODATA- oder NXDOMAIN-Klasse. Unterschiedliche Resolver können dieselbe Frage aus unterschiedlichen Historien und Regeln anders beantworten.

Eine kurze Antwort-TTL ist keine Verjüngung

Für abgelaufene Datensätze muss der Resolver eine positive TTL in die Antwort schreiben; RFC 8767 empfiehlt dreißig Sekunden. Null hat Interoperabilitätsprobleme verursacht, während extrem kurze Werte Wiederholungsverkehr während einer Störung verstärken können. Die kleine TTL bremst nachgelagerte Anfragen.

Sie setzt das tatsächliche Alter nicht zurück. Speichert ein Forwarder die Antwort, sieht der nächste Client die kurze TTL, aber nicht den Ablauf der ursprünglichen Daten. Resolver-Identität, Cache-Zeit und letzter autoritativer Versuch müssen erhalten bleiben.

RFC 8914 liefert ergänzende Extended DNS Errors. Code 3 bezeichnet Stale Answer, Code 19 Stale NXDOMAIN Answer und Code 22 No Reachable Authority. Diese Hinweise können auch neben NOERROR stehen.

EDE ändert jedoch die RCODE-Verarbeitung nicht. Ein Zwischenknoten kann es entfernen oder neu erzeugen. Ohne geschützte Transaktion oder Verbindung ist es nicht authentisiert. Code 3 belegt, wie der Absender seine Antwort bezeichnet; er beweist nicht dessen interne Alters- und Versuchsprotokolle.

DNSSEC führt eine eigene Zeitrechnung

Ein beim Einfügen validiertes RRset kann später außerhalb seiner Signaturgültigkeit liegen. RRSIG-Beginn und -Ende sind unabhängig von TTL und Stale-Fenster. Längere Aufbewahrung erhöht die Wahrscheinlichkeit, die kryptographische Frist zu überschreiten.

Das AD-Bit muss den gegenwärtigen Validierungszustand ausdrücken. Benötigt werden RRSIG-Zeiten, Validierungszeitpunkt, Trust Anchors sowie CD/DO-Kontext. Selbst eine weiterhin gültig signierte alte Adresse kann auf Infrastruktur zeigen, die der Herausgeber nicht mehr kontrolliert. Authentizität der Aussage und aktuelle Sicherheit des Ziels sind getrennte Fragen.

Negative Daten haben andere Folgen. Ein altes NXDOMAIN kann einen neuen Namen verdecken. Überholte NSEC- oder NSEC3-Daten können neue DS- oder TLSA-Zustände verzögern. RFC 8198 synthetisiert Antworten aus noch zulässigem validiertem Negativmaterial. Serve Stale betrifft den zusätzlichen Schritt nach dessen gewöhnlichem Ablauf und gescheiterter Aktualisierung.

Quellen