Zusammenfassung

  • Der TTL-Ablauf beendet die normale Wiederverwendung und verpflichtet den Resolver, die Quelle erneut zu konsultieren. Erst wenn ein autoritativer Refresh nicht gelingt, darf eine aufbewahrte alte Antwort nach RFC 8767 in den Ausnahmeweg gelangen.
  • Client-Antwortzeit, gesamte Auflösungsarbeit, erneute Prüfung eines Fehlers und maximales Stale-Alter sind vier unabhängige Zeitbudgets. Ein aktiviertes Feature sagt nichts über ihre tatsächliche Ausführung.
  • RRset, Refresh-Fehler, RRSIG-Zeit, kurzer Antwort-TTL, EDE, weiterlaufender Refresh und Anwendungsergebnis müssen getrennt belegt werden. Sonst wird eine lokale Resilienzentscheidung zur vermeintlich aktuellen Aussage der Zone.

Das Krankenhaus erreichte noch den alten Dienst

Ein Krankenhaus verlegt eine Termin-API in ein neues Rechenzentrum. Der alte Endpoint bleibt für eine kontrollierte Übergangszeit erreichbar. Später fällt für einen Teil des Netzes der Weg zu allen autoritativen Nameservern aus. Der lokale Resolver besitzt noch die frühere A-Antwort; ihr TTL ist seit neunzig Minuten abgelaufen.

Ein Fehler unterbricht die Terminvergabe sofort. Eine alte Antwort kann sie erhalten, solange der vorige Endpoint unter der richtigen Kontrolle steht. Ist dessen Adresse aber inzwischen neu vergeben, verbindet die gleiche Resilienzentscheidung sensible Anfragen mit dem falschen System. Ein erfolgreicher TCP- oder TLS-Aufbau beweist nicht, dass die DNS-Aussage aktuell oder der Betreiber identisch ist.

Der Resolver kennt nur eine frühere Aussage und seinen erfolglosen Versuch, eine neue zu erhalten. Serve-stale ist deshalb keine Wahrheitsschätzung, sondern ein Vertrag über einen Fehlerzustand: Welche alte Aussage darf nach welcher gescheiterten Konsultation wie lange noch Pakete lenken?

TTL-Ablauf eröffnet nicht sofort die Hintertür

RFC 1035 verband den TTL mit der erneuten Konsultation der Quelle und dem Verwerfen eines Cache-Eintrags. RFC 2181 bezeichnete ihn als maximale Lebensdauer. RFC 8767 aktualisiert die Definition: Nach Ablauf muss die Quelle erneut konsultiert werden; kann die Information nicht autoritativ aktualisiert werden, darf der Eintrag unter den beschriebenen Bedingungen wie nicht abgelaufen verwendet werden.

Die Reihenfolge schützt die Befugnis des Herausgebers. Serve-stale ist kein Recht, kurze TTLs dauerhaft zu überschreiben. Wer alte Daten immer sofort liefert und erst danach fragt, macht aus dem Notfall einen Normalbetrieb und verschiebt die Kontrolle unbemerkt zum rekursiven Betreiber.

TTL 0 bleibt transaktionsgebunden. Was nie gecacht werden darf, kann nicht später als Stale-Reserve auftauchen. Ebenso sind der empfohlene Clamp empfangener TTLs von etwa sieben Tagen und das Maximum nach Ablauf getrennt. Das eine begrenzt die normale Eingabe; das andere die lokale Ausnahme.

Vier Uhren, vier Schadensarten

Der Client response timer begrenzt den Versuch einer frischen Antwort innerhalb der noch nützlichen Wartezeit. Rund 1,8 Sekunden sind das RFC-Beispiel. Zu kurz bedeutet alte Antworten trotz nur langsamer Autorität; zu lang bedeutet korrekte Absicht, aber wertlose Latenz.

Der Query resolution timer begrenzt die gesamte rekursive Arbeit, in der RFC-Diskussion häufig zehn bis dreißig Sekunden. Er läuft nach einer Stale-Antwort weiter. Client bedienen und Cache reparieren sind zwei getrennte Zusagen.

Der Failure recheck timer verhindert, dass jede neue Anfrage einen bekannten Ausfall erneut verstärkt. Das Beispiel empfiehlt mindestens etwa dreißig Sekunden Abstand und verweist auf fünf Minuten als Obergrenze. RFC 9520 verlangt, Resolution Failures mindestens eine Sekunde und höchstens fünf Minuten zu cachen; Backoff soll Dauerstörungen entlasten.

Der Maximum stale timer bestimmt die Aufbewahrung nach normalem Ablauf. Ein bis drei Tage sind vorgeschlagen. Mehr Zeit schützt gegen längere Ausfälle, verlängert aber auch alte Adressen, alte Delegationen, negative Aussagen und Speicherverbrauch.

Auditierbar wird der Mechanismus erst mit Start- und Endereignis jeder Uhr. Kam die Antwort nach einer neuen Prüfung oder wegen eines noch aktiven Failure Cache? Lief der Upstream-Fetch weiter? Wurde der alte Eintrag ersetzt, verdrängt oder nach Neustart wiederhergestellt? Gleiche Konfigurationstexte können verschiedene Ergebnisse erzeugen.

Nur bestimmte autoritative Antworten erneuern den Zustand

Eine Antwort mit AA und NOERROR oder NXDOMAIN muss nach RFC 8767 als Refresh gelten. Andere RCODEs sollten als fehlgeschlagener Refresh behandelt werden und den bisherigen Zustand nicht löschen.

Ein temporäres SERVFAIL vernichtet damit nicht die letzte brauchbare Information. Ein frisches autoritatives NXDOMAIN darf dagegen eine alte positive Antwort beenden. Der Resolver kann eine absichtliche Löschung nicht zuverlässig von einem Bedienfehler unterscheiden und besitzt kein Vetorecht gegen die aktuelle autoritative Negation.

Bei REFUSED ist die Semantik offen: bewusste Stilllegung, ACL-Fehler oder falscher Server. Implementierungen dürfen entscheiden, ob REFUSED von allen Authorities Stale unterbindet. Diese Entscheidung gehört in eine Release-Matrix.

Der durch RFC 9520 gecachte Resolution Failure ist ein eigenes Objekt. Er unterdrückt weitere Upstream-Anfragen, beweist aber weder Wert noch Existenz. Eine Oberfläche mit nur dem Label „cache hit“ verwechselt alte Daten mit der Tatsache, dass neue Daten nicht beschafft werden konnten.

Dreißig Sekunden gehören der Projektion

Stale-RRs müssen in der Antwort einen TTL größer null erhalten; dreißig Sekunden sind empfohlen. Der Zonenbetreiber hat diese Lebenszeit nicht erneuert. Der Resolver gibt seiner alten Projektion eine kurze Downstream-Wiederverwendung, die Anfragestürme reduziert.

Zum Beleg gehören ursprünglicher TTL, Insertion, normaler Ablauf, Stale-Alter, Antwort-TTL und Fallback-Grund. Ein isolierter Wert 30 kann frisch oder viele Stunden alt bedeuten.

RFC 8914 kennzeichnet Stale Answer mit EDE 3 und Stale NXDOMAIN mit EDE 19; EDE 7 bezeichnet abgelaufene Signaturen. EDE ändert die RCODE-Verarbeitung nicht und verpflichtet Clients zu keiner Reaktion. Ein Forwarder kann die Information verlieren. Deshalb muss jede Schicht dokumentieren, ob sie EDE erzeugt, erhalten oder entfernt hat.

Eine alte Abwesenheit kann eine Reparatur sperren

Positive Stale-Daten erhalten ein altes Ziel. Stale NXDOMAIN erhält Nicht-Existenz. Stale NSEC oder NSEC3 kann einen neu veröffentlichten Namen, DS oder TLSA weiter abdecken. Ein Sicherheitswechsel bleibt unsichtbar, obwohl der Resolver schnell und formal korrekt antwortet.

Eligibility muss daher den Zweck des RR berücksichtigen. Content-Adresse, Zertifikatskontrolle, Delegation und Notfall-Revocation tragen unterschiedliche Alterungskosten. Kann ein Produkt diese Klassen nicht kontrollieren, ist ein kleinerer Einsatzbereich ehrlicher als ein globales Einschalten.

Auch Monitoring trennt positive Antwort, NXDOMAIN und NODATA. Ein einziger Stale-Zähler zeigt nicht, ob Reachability bewahrt oder neue Reachability verhindert wurde.

RRSIG hat eine eigene Zeitachse

RFC 4035 verlangt aktuelle Validatorzeit zwischen Inception und Expiration. Cache-Aufbewahrung verschiebt diese Werte nicht. Ein signierter RRset kann stale und noch validierbar sein; später bleiben dieselben Bytes gespeichert, aber die Signatur ist abgelaufen.

Erforderlich sind getrennte Zustände für Stale mit gültiger Signatur, Stale mit abgelaufener Signatur, gecachten Validation Failure und lokale unsichere Ausnahme. „DNSSEC aktiv“ sagt nicht, was ausgeliefert wurde.

Ein Angreifer kann Authority-Unerreichbarkeit mit alten Bindings kombinieren. RFC 8767 beschreibt das Risiko aufgegebener Adressen für domain-validierte Zertifikate. Serve-stale erzeugt die alte Adresse nicht, verlängert aber im Fehlerfall ihre operative Wirkung.

Produktsemantik ist Teil der Freigabe

BIND dokumentiert Stale-Aufbewahrung, Auslieferung, Antwort-TTL, maximales Alter, Refresh-Intervall und rndc serve-stale separat. Aktuell sind dreißig Sekunden Antwort-TTL und ein Tag Maximum dokumentiert. Der Client-Timeout ist standardmäßig aus; die dokumentierte Version unterstützt bei Aktivierung nur null und damit sofortige Antwort.

Unbound trennt mit serve-expired-* Alter, Reply-TTL, Wartezeit und Reset. Die aktuelle Dokumentation unterscheidet Immediate- und RFC-orientiertes Warten. Versionsstände, nicht gemeinsame Begriffe, bestimmen die Ausführung.

Canaries umfassen schnelle, langsame, unerreichbare Authority, SERVFAIL, REFUSED, NXDOMAIN, positive und negative Daten, gültige und abgelaufene Signatur, TTL 0, Cache-Druck, Neustart und Runtime-Override. Beweis sind Cache-Zustand, Upstream-Paket, Antwort, EDE, fortgesetzter Refresh, Ersatz und Anwendung.

Quellen