Zusammenfassung

  • RFC 10037 wurde im August 2026 veröffentlicht und erlaubt ttl0_data in RDAP-Domain- und Nameserver-Objekten. Der Wert stammt aus der provisionierten Registry-Datenbank; er ist ausdrücklich nicht die verbleibende Zeit einer live abgefragten DNS-Kopie.
  • Die zusätzliche Sichtbarkeit verteilt keine neue Befugnis. Registry-Policy, angenommene Konfiguration, autoritative Zone, Resolver-Cache und Anwendungsergebnis bleiben getrennte Nachweise.

Die geplante NS-Umstellung soll um 12 Uhr stattfinden. Um 11:55 meldet RDAP den gewünschten TTL von 300 Sekunden. Für die Änderungskommission sieht der Wert sauber aus. Ein Resolver kann aber um 11:54 noch den alten RRset mit 86.400 Sekunden erhalten haben. Der neue Datenbankwert ändert diesen Speicher nicht rückwirkend.

Ein anderer Resolver hat seine Kopie vielleicht früher entfernt. Ein dritter kann nach einem fehlgeschlagenen Refresh alte Daten begrenzt weitergeben. Drei unterschiedliche Zeitlinien können gleichzeitig korrekt sein, weil keine davon durch die RDAP-Antwort gesteuert wird.

Der RFC 10037 ist ein IETF-Standards-Track-Dokument vom August 2026. Ein unterstützender Server darf in Domain- und Nameserver-Antworten ttl0_data liefern. Dessen values-Objekt ordnet großgeschriebene, bei der IANA registrierte DNS-RR-Typen ganzzahligen JSON-Werten zwischen null und 2^31−1 zu. Bei Nutzung steht ttl0 in rdapConformance.

Der normative Grenzsatz ist entscheidend: Die Werte müssen die Provisionierung in der Registry-Datenbank abbilden und nicht den verbleibenden TTL aus einer live beobachteten DNS-Abfrage. RDAP bezeugt eine administrative Stufe. Es besitzt keine Uhr in einem fremden Resolver.

Offenlegung und Änderungsrecht bleiben getrennt

ttl0_data ist optional. Unwissende Clients sollen das Mitglied nach RFC 9083 ignorieren. Unterstützende Clients müssen Werte für alle gültigen DNS-Typen akzeptieren und ihre Kenntnis der IANA DNS Parameters regelmäßig erneuern. Ein nach der Client-Version registrierter Typ darf nicht allein deshalb verschwinden.

Die IANA RDAP Extensions Registry gibt ttl0 einen gemeinsamen Bezeichner. Der Eintrag beweist keine Implementierung, Aktivierung oder heutige Nutzung bei einer bestimmten Registry.

Für das Schreiben existiert mit RFC 9803 eine eigene EPP-Abbildung. Der Server kann erlaubte Typen sowie Minimum, Standard und Maximum festlegen. Er darf einen Wert aus Sicherheits- oder Stabilitätsgründen übergehen, außerhalb eines Client-Kommandos ändern oder später automatisch auf den Standard zurücksetzen.

RFC 10037 ergänzt diese Möglichkeit, setzt sie aber nicht voraus. Eine Registry kann einen intern bestimmten Wert öffentlich machen, ohne dessen Wahl nach außen zu delegieren.

Fünf Zustände müssen zusammengeführt werden

Die Policy entscheidet, wer welchen Wert für welchen RRset anfordern darf. Die Registry-Datenbank enthält die angenommene Konfiguration. Zonenerzeugung und autoritative Server veröffentlichen den tatsächlich ausgelieferten RRset. Jeder rekursive Resolver verwaltet eine früher erhaltene Kopie. Die Anwendung prüft zuletzt, ob Ziel, DNSSEC und Dienst funktionieren.

RFC 2181 ordnet den TTL dem RRset zu und verlangt gleiche Werte innerhalb der Menge. RFC 1035 definiert den gewöhnlichen Cache-Zeitraum. RFC 9499 nennt ihn eine Höchstdauer: Ein Cache darf verkürzen oder den Eintrag früher entfernen. Nach der Entfernung gibt es keine Restzeit mehr.

Auch der Ablauf garantiert nicht überall sofortige Abwesenheit. RFC 8767 erlaubt unter begrenzten Bedingungen alte Daten, wenn ein gutgläubiger Aktualisierungsversuch scheitert. Das ist lokale Verfügbarkeitsbefugnis des Resolvers, keine Verlängerung der aktuellen Zonenbehauptung.

Gewartet wird ab nachgewiesener Veröffentlichung

RFC 9803 beschreibt den typischen Fehler, den TTL gleichzeitig mit oder erst nach dem eigentlichen Datensatz zu senken. Bereits mit dem alten Wert gespeicherte Kopien werden nicht verkürzt. Der niedrigere TTL sollte mindestens eine bisherige TTL-Dauer vor der Änderung wirksam sein; zusätzlich zählt die Latenz zwischen Registry-Kommando und DNS-Veröffentlichung.

Ein belastbarer Ablauf ermittelt zuerst alten Wert und Policy. Dann folgen autorisierte Anforderung, Registry-Bestätigung und Beobachtung auf allen autoritativen Servern. Erst ab dieser Veröffentlichung läuft die konservative Wartezeit. Danach werden NS, DS, Adresse oder andere Daten geändert. Mehrere rekursive Standorte, DNSSEC-Prüfung und Dienst-Canaries belegen das Ergebnis. Der normale TTL wird erst wiederhergestellt, wenn der neue Zustand stabil und der Rückweg noch verfügbar ist.

Die Transaktionszeit im Portal ist für die Zuständigkeit wichtig. Für den Cache-Abbau ist der erste belegte autoritative Zeitpunkt maßgeblich.

Der Policy-Inhaber trägt beide Extreme

Kurze TTLs erleichtern Wechsel und Rollback, erhöhen aber Abfragelast und können Fast-Flux-Beweglichkeit unterstützen. Lange TTLs sparen Routineverkehr, können jedoch eine nach Kontoübernahme manipulierte Delegation über die Entdeckung hinaus in Caches halten.

Darum behält die Registry Grenzen, Override und automatischen Reset. RDAP macht eine Wahl sichtbar, bewertet sie aber nicht. RFC 7481 stützt RDAP-Sicherheit auf andere Protokollschichten für Authentisierung, Autorisierung, Vertraulichkeit und Integrität. Geschützter Transport beweist nicht, dass Datenbank, Zone und Dienst übereinstimmen.

Ein gemeinsamer Änderungsnachweis verbindet die Uhren

Für jede Änderung gehören Akteur und Autorisierung, Policy-Version, vorheriger TTL, EPP-Transaktion oder gleichwertige Bestätigung, zeitgestempelte RDAP-Antwort, Zonenversion, alle autoritativen Antworten, rekursive Beobachtungen, DNSSEC-Ergebnis, Dienst-Canary und Rollback-Entscheidung zusammen. Jede Zeitangabe braucht RRset, Quelle und Phase.

Heng Lus Prinzip des laufenden Codes verlangt die Prüfung des ausgeführten Wegs. Seine Unterscheidung von formaler und praktischer Datenkontrolle erklärt, warum die Registry verteilte Cache-Kopien nicht beherrscht. Das Modell einer minimalen gemeinsamen Spezifikation mit lokalen Folgeentscheidungen passt genau: Gemeinsame Bedeutung, aber lokale Einführung, Grenzen, Reihenfolge und Haftung.

RFC 10037 stellt keine Weltuhr. Es beschriftet präzise die Uhr, die eine Registry zeigen kann.