Zusammenfassung

  • Im RFC-9664-Request stehen Wunschwerte; erst LEASE und KEY-LEASE in der erfolgreichen Antwort bestimmen die vom autoritativen Server gewährte Dauer.
  • Der Ablauf beendet autoritative Veröffentlichung, beweist aber weder einen funktionierenden Dienst noch Flottenkonvergenz oder das sofortige Verschwinden bereits gecachter Antworten.

Ein Gerät beantragt in einem illustrativen Beispiel 30 Minuten für seine Dienst-RRs. Authentisierung und RFC-2136-Prüfbedingungen sind erfolgreich. Der Server antwortet ohne Fehler, gewährt jedoch vier Stunden. Nach zwanzig Minuten fällt das Gerät aus, ohne zu löschen oder zu erneuern.

Die autoritative Antwort kann für die Restzeit protokollgemäß sein, obwohl am Ziel kein Dienst mehr läuft. Das ist kein berichteter Vorfall und keine Produktvorgabe. Der Fall macht sichtbar, dass RFC 9664 eine kürzere, gleiche oder längere Gewährung erlaubt. Der Request bittet; die Response entscheidet.

Drei Urteile, die nicht zusammenfallen

Update Lease wird als EDNS(0)-Option in einem gewöhnlichen DNS UPDATE nach RFC 2136 transportiert. Zone, Prerequisite, Update und Additional Data bleiben erhalten. Die Voraussetzungen werden gegen den aktuellen Zonenstand geprüft; die Änderung wird atomar angenommen oder abgelehnt.

Diese Entscheidung betrifft die Schreibbefugnis. Die Lease-Antwort betrifft die Veröffentlichungsdauer ohne weitere Erneuerung. Ob Adresse, Port und Anwendung funktionieren, kann nur eine unabhängige Dienstprüfung zeigen.

TSIG oder SIG(0) können die Transaktion und ihren Absender authentisieren. Eine Update-Policy kann Schlüssel auf Namen und RR-Typen begrenzen. Sie prüft weder Prozesszustand noch Netzwerkpfad oder eine vollständige Anwendungstransaktion. Authentischer DNS-Zustand ist nicht automatisch wahrer Dienstzustand.

Die Beweiskette braucht deshalb alle Nachrichtenabschnitte, TSIG-Schlüsselnamen oder SIG(0)-Identität, Policy-Ergebnis, Optionslänge, gewünschte Werte, RCODE und zurückgegebene Werte. „Lease erfolgreich“ verschweigt die entscheidende Zeitentscheidung.

Vier oder acht Byte: Dienst und Namensanspruch

Die Vier-Byte-Variante enthält ein 32-Bit-LEASE für sämtliche RRs im Update-Abschnitt, einschließlich KEY. Die Acht-Byte-Variante ergänzt KEY-LEASE; normale RRs folgen der ersten, KEY-RRs der zweiten Dauer.

Im Service Registration Protocol nach RFC 9665 kann dadurch die Dienstankündigung ablaufen, während der KEY den Namen länger für denselben kryptographischen Inhaber reserviert. Der Namensanspruch bleibt, der Dienst nicht.

Kompatibilität kann die Trennung aufheben. Eine Vier-Byte-Anfrage gilt für beide Klassen. Erhält ein Requester auf acht gesendete Byte nur vier zurück, muss auch er den einen Wert für beide verwenden. Maßgeblich ist die beobachtete Antwort, nicht die beabsichtigte Konfiguration.

Explizit entfernte RRs werden dauerhaft entfernt. Die Lease verwandelt eine Löschung nicht in eine Pause.

Die Antwort setzt die operative Uhr

Ein unterstützender Server muss die Option bei erfolgreicher Verarbeitung zurückgeben. Der Requester plant die Erneuerung bei 80 Prozent der gewährten Dauer plus einem Zufallsanteil von null bis fünf Prozent. Das verteilt gleichzeitige Geräte und lässt 15 bis 20 Prozent für Wiederholungen.

Ein berechneter Termin ist keine Verlängerung. Nachweisbar sind erst Zufallswert, Sendezeit, Versuche, authentisierte Antwort und neue Gewährung.

Fehlt die Option in der Antwort, deutet dies auf einen nicht unterstützenden Server. Der Requester soll aus Kompatibilitätsgründen dennoch so erneuern, als sei sein Wunsch zurückgegeben worden. Damit ist serverseitige Garbage Collection nicht bewiesen. Der Status muss diese Unsicherheit ausdrücklich tragen.

Registration und Refresh unterscheiden sich ebenfalls. Eine Registration fügt vermeintlich neue Information hinzu; ein Refresh verlängert bestehenden Zustand ohne Inhaltsänderung. Nach einem Neustart mit Zustandsverlust kann ein Refresh die RRs wieder eintragen. Ändert er dadurch die Zone, muss die Seriennummer steigen. Bei unverändertem Inhalt darf die reine Verlängerung sie nicht erhöhen.

Autoritativ abgelaufen, im Cache noch sichtbar

Nach Ablauf ohne Erneuerung darf der Server das RR nicht mehr beantworten. Er kann die gespeicherten Daten löschen, muss es aber nicht. Antwortzustand und Speicherzustand sind getrennt.

Die TTL steuert eine zweite Zeitachse. Ein Resolver, der kurz vor Ablauf eine Antwort erhalten hat, darf sie bis zum Ende seiner Rest-TTL wiederverwenden. Der autoritative Server kann diese Kopie nicht zurückrufen. Umgekehrt beendet eine kleine TTL keine längere Lease auf dem Server.

Die Untersuchung trennt daher Gewährungsende, Refresh und Retransmits, Signierung/Journale/Secondaries sowie die beobachtete Rest-TTL. Ist der Registrar ein Hidden Primary, beweist seine Tabelle nicht die Antworten aller öffentlichen oder Anycast-Instanzen. Zusätzlich ist eine echte Verbindung zum angekündigten Dienst nötig.

Lokale Grenzen statt universeller Zahl

Eine zu lange Lease ähnelt dauerhaftem Zustand; eine zu kurze erzeugt Last und vorzeitige Löschung bei Verzögerung. RFC 9664 empfiehlt standardmäßig höchstens 24 Stunden für LEASE, sieben Tage für KEY-LEASE und mindestens 30 Sekunden; in den meisten Fällen sollen deutlich längere Werte wie eine Stunde verwendet werden. Betreiber dürfen die Grenzen ändern.

Das sind keine Ansprüche des Requesters. Entscheidend sind eine sichtbare, versionierte Serverpolicy und eng begrenzte Schlüssel. Ablauf begrenzt die Lebensdauer eingetragener Daten, heilt aber keine Berechtigung, die eine ganze Zone verändern kann.

Quellen