Zusammenfassung

  • RFC 8767 hebt den TTL nicht auf. Sie gestattet alte DNS-Daten nur als befristeten Rückfall, nachdem ein ernsthafter jüngerer Aktualisierungsversuch keine nutzbaren autoritativen Daten erbracht hat.
  • Ursprünglicher TTL, maximale Stale-Frist, Wartezeit des Clients, ausgegebener TTL, DNSSEC-Gültigkeit, EDE-Signal und erneute Abfragen sind getrennte Uhren.
  • David C. Lawrence ist einer von drei Autoren. Die gemeinsame Urheberschaft begründet weder Alleinerfindung noch Verfügungsgewalt über Zonen, Resolver, Implementierungen oder ICANN-Entscheidungen.

Die Anfrage trifft in einem schmalen Zwischenzustand ein. Der gespeicherte RRset war bis eben aktuell. Jetzt ist sein TTL null, während die autoritativen Server innerhalb des Clientbudgets nichts Brauchbares liefern. Der Resolver kann scheitern oder den bisherigen Wert ausgeben.

Für den Client sieht die zweite Variante wie eine normale Antwort aus. Für den Betrieb ist sie eine Ausnahme: Die Quelle bleibt gestört und könnte den Wert bereits geändert haben. Wenn diese Ausnahme nur als Erfolg gezählt wird, verschwindet der Autoritätswechsel aus der Beobachtung.

RFC 8767 wurde im März 2020 von David C. Lawrence, Warren Kumari und Puneet Sood veröffentlicht. Sie verleiht abgelaufenen Daten keinen neuen Frischestatus. Sie beschreibt einen nachprüfbaren Übergang, in dem Kontinuität der Herkunft untergeordnet bleibt.

Gespeichert ist nicht gleich aussagefähig

RFC 1035 setzt den TTL als Nutzungsdauer im Cache. RFC 2181 verdeutlicht, dass ein Resolver Daten nach dieser Grenze nicht weiter als aktuell behandeln darf. Die Zeitangabe gehört zur veröffentlichten Absicht der Zone und ist nicht bloß eine Speicherbereinigung.

Eine Implementierung darf die Bytes dennoch behalten. Diagnose, Vergleich und begrenzte Notfallnutzung profitieren davon. Aufbewahrung und Antwortberechtigung müssen aber unterschiedliche Zustände sein. RFC 8767 regelt den zweiten.

Für Daten, die mit TTL null empfangen wurden, gibt es keinen Rückfall. Die Quelle hat die Wiederverwendung ausdrücklich ausgeschlossen. Ein Resolver darf nachträglich keine Stale-Frist erfinden.

Der Beleg beginnt deshalb beim Einfügen: Name, Typ, Klasse, Antwortquelle, Inhalts-Hash, empfangener TTL, Einfügezeit, normale Ablaufzeit und DNSSEC-Ergebnis. „Letzte gute Antwort“ ist ohne dieses Objekt weder zeitlich noch inhaltlich prüfbar.

Die Quelle bekommt den ersten Versuch

RFC 8767 verlangt einen jüngeren Aktualisierungsversuch in gutem Glauben. Der Resolver fragt den autoritativen Pfad und wartet bis zu seiner Clientgrenze. Erst bei Fehlschlag oder Zeitüberschreitung darf er den alten Wert wählen. Hat eine unmittelbar vorherige Anfrage den Ausfall bereits gezeigt, können folgende Clients die gleiche Wartezeit vermeiden.

Diese Reihenfolge schützt das Änderungsrecht der Zone. Eine Notfalladresse, eine Abschaltung oder eine DNS-Änderung für eine Zertifikatsprüfung muss sichtbar werden, sobald die Quelle erreichbar ist. Würde der Cache aus Bequemlichkeit immer zuerst antworten, verlängerte der Vermittler den alten Zustand eigenmächtig.

„Guter Glaube“ braucht Felder: Zielserver, Transport, Beginn, Ende, Antwort oder Fehlerklasse, Validierung und gegebenenfalls der verwendete jüngste Ausfallstatus. Timeout, SERVFAIL, autoritatives NXDOMAIN und DNSSEC-Fehler sind keine Synonyme.

Die Ausgabe einer alten Antwort ist auch keine Erholung. RFC 8767 fordert fortgesetzte Aktualisierung. Erst eine neue, nutzbare, geprüfte und installierte autoritative Antwort beendet den Ausnahmezustand.

Sechs Zeitgrenzen dürfen nicht zu einer verschmelzen

Der ursprüngliche TTL bestimmt die normale Frische. RFC 8767 schlägt außerdem vor, den für Stale-Berechnungen herangezogenen empfangenen TTL auf etwa sieben Tage zu begrenzen. Ein ungewöhnlich großer Wert soll keine unbegrenzte Reserve schaffen.

Die maximale Stale-Frist ist lokale Resolverpolitik. Sie sollte konfigurierbar sein; als Ausgangsgröße nennt der Text ein bis drei Tage. Danach ist die Antwort nicht mehr berechtigt, selbst wenn sie noch gespeichert ist.

Das Clientbudget ist meist nur Sekunden lang. Ein kurzer Wert verringert die Wartezeit, lässt aber auch lediglich langsame autoritative Antworten häufiger verlieren.

Der ausgegebene TTL gilt für die Ausnahmeantwort. Er muss positiv sein; empfohlen sind 30 Sekunden. Er begrenzt die Wiederverwendung im nächsten Cache und setzt das Alter des RRsets nicht zurück.

DNSSEC-Signaturen besitzen eigene Anfangs- und Endzeiten. Ein RRset kann cachetechnisch ablaufen, während RRSIG noch gilt, oder die Signatur kann vor der lokalen Stale-Grenze enden. Cachepolitik verlängert keine Kryptografie.

Schließlich steuert die Wiederholungsfrist die Rückkehr. Zu schnelle Versuche belasten ein beschädigtes Autoritätssystem, zu langsame machen den alten Wert länger zur praktischen Wahrheit. Alle sechs Zeiten gehören getrennt in den Beleg.

DNSSEC beglaubigt Vergangenheit, nicht Aktualität

RFC 4035 verpflichtet validierende Resolver, Kette und Signaturzeitraum zu prüfen. Ein abgelaufener RRset kann noch Secure sein, wenn die Signatur gültig bleibt. Das belegt eine Signatur des Eigentümers zu einem früheren Zeitpunkt, nicht dessen heutigen Veröffentlichungswillen.

RFC 8767 warnt vor steigender Fehlerwahrscheinlichkeit mit zunehmendem Alter. Sie nennt außerdem einen Angriff ohne Signaturfälschung: Wer die Autorität unerreichbar hält, kann die Verwendung älterer Daten verlängern. Ausgenutzt wird die Lücke zwischen „einst authentifiziert“ und „derzeit beabsichtigt“.

Die vertretbare Grenze hängt vom Verbraucher ab. Eine Webseite während einer kurzen Störung zu erreichen ist etwas anderes als ein Zertifikat anhand einer DNS-Challenge auszustellen. Die RFC rät Zertifizierungsstellen, für diese Prüfung keinen Stale-Resolver zu verwenden.

Auch Nichtexistenz altert. Eine alte positive Antwort hält Verkehr auf einem abgeschalteten Ziel; ein altes NXDOMAIN verbirgt einen neu angelegten Namen. RFC 8914 führt Stale NXDOMAIN Answer getrennt, weil Abwesenheit ebenfalls aktuelle Evidenz verlangt.

EDE macht den Ausnahmefall sichtbar

Lawrence war auch Mitautor von RFC 8914 zu Extended DNS Errors. Code 3 bedeutet Stale Answer, Code 19 Stale NXDOMAIN Answer. Ein fähiger Client kann erkennen, dass der Resolver keine gewöhnlich aktuellen Daten lieferte.

EDE ändert allein keinen RCODE, authentifiziert den RRset nicht, belegt keinen Ausfallgrund, verlängert keine Signatur und garantiert nicht, dass die Anwendung den Hinweis gelesen hat. Viele Programme verwenden nur die Adresse oder die negative Antwort.

Das Signal ist daher Zeuge, nicht Rechtfertigung. Es ermöglicht Messung nach Grund und Alter sowie strengere Regeln für riskante Vorgänge. Den vollständigen Resolverbeleg ersetzt es nicht.

Ein Code-3-Zähler muss mit Cacheobjekt, Aktualisierung, Alter, AusgabetTL, DNSSEC und späterer Erholung verbunden sein, um eine richtige Entscheidung zu zeigen.

Laufender Code legt die örtliche Politik offen

RFC 8767 erwähnt einen frühen Patch für BIND 9.7.0, von Akamai berichteten Produktionseinsatz seit 2011 und spätere Unterstützung in BIND 9.12, Unbound und Knot Resolver. Der Mechanismus beruht damit auf gemeinsamer Betriebserfahrung.

Einheitliche Werte folgten daraus nicht. Die aktuelle Unbound-Dokumentation beschreibt RFC-8767-Verhalten seit Version 1.23.0 als Standard. Sie nennt 1,8 Sekunden Clientwartezeit oder Ersatz für SERVFAIL, einen Tag maximale Stale-Dauer, 30 Sekunden Antwort-TTL und fortgesetzte Auflösung.

Das sind heutige Entscheidungen einer Implementierung, keine universellen IETF-Vorgaben. Betreiber können sie ändern, andere Produkte handeln anders.

Der Nachweis kommt aus dem laufenden System: Software, Version, wirksame Werte, Zustandswechsel und gesendetes Paket. Tests brauchen gesunde Autorität, Schweigen, SERVFAIL, DNSSEC-Fehler, Erholung vor und nach der Grenze, geänderte Daten und TTL null. Dokumentation zeigt Möglichkeiten; die Spur zeigt Tatsachen.

Lawrence steht für Beitrag, nicht für Betriebshoheit

Der IETF Datatracker führt David C. Lawrence als „tale“ und nennt RFC 3425, 7871, 8767 und 8914. Der aktuelle Eintrag nennt ihn Ko-Vorsitzenden von Adaptive DNS Discovery, IETF-Verbindungsmann zum ICANN Board und technischen Reviewer.

Die heutige ICANN-Seite bezeichnet David Lawrence seit 14. November 2024 als nicht stimmberechtigten IETF-Vertreter. Seine Biografie nennt RPI und Usenet, UUNET, die BIND-Neuentwicklung bei ISC, Nominum, dreizehn Jahre bei Akamai, die Wahl zum DNSSEC Root Key Trusted Community Representative 2010 sowie DNS-OARC und CVFiber.

Das belegt lange Beteiligung an DNS-Code, Standardisierung und institutioneller Verbindung. Es belegt weder Alleinerfindung noch Kontrolle über Resolver oder ICANN. RFC 8767 hat drei Autoren und verarbeitet breitere Erfahrung und Konsens.

Die personelle Grenze entspricht der technischen: Beitrag überträgt keine Betriebsgewalt; eine Kopie übernimmt nicht die Autorität des Namens.

Der Beleg endet erst mit frischen autoritativen Daten

Zuerst stehen RRset, Herkunft, TTL, Einfüge- und Ablaufzeit, Inhalts-Hash und DNSSEC. Danach folgen Ziele, Transport, Zeiten, Ergebnis und verwendete Ausfallerinnerung des Aktualisierungsversuchs.

Die Entscheidung enthält maximale Frist, berechnete Grenze, Alter, Clientbudget, Antwort-TTL, EDE, Ausnahme und nächste Wiederholung. Ein Ausschluss für irreversible Verbraucher ist ebenfalls zu erfassen.

Den Abschluss bilden die erste nutzbare frische Antwort, Validierung, neuer Hash, Installation, Ende des Stale-Zustands und Anwendungsergebnis. Hat sich der Wert geändert, darf die alte Ausgabehistorie nicht überschrieben werden.

So wird das Entscheidungsbuch geschützt, nicht der vorübergehende Torwächter zur Quelle erhoben. Der Resolver erhält Funktion, während Autorität und Herkunft sichtbar bleiben. Nur dann ist die Ausnahme begrenzt.

Quellen