Zusammenfassung

  • RFC 10037 definiert das optionale Element ttl0_data für Domain- und Nameserver-Objekte in RDAP.
  • Angezeigt wird der in der Registry konfigurierte TTL, nicht die bei einer DNS-Abfrage beobachtete Restlaufzeit.

Dieselbe Zahl kann zwei verschiedene Fragen beantworten

RDAP konnte bereits Nameserver, Glue-Adressen und DS-Einträge einer Domain zeigen. Die TTLs dieser RRsets fehlten. Dabei drückt ein TTL betriebliche Absicht aus: Wie lange darf ein Resolver denselben Satz wiederverwenden, bevor er erneut fragt?

ttl0_data enthält dafür eine Zuordnung values von DNS-Typkürzeln zu TTL-Werten und kann RDAP-Anmerkungen aufnehmen. Die Veröffentlichung bleibt freiwillig. Nutzt eine Antwort die Erweiterung, muss sie ttl0 in rdapConformance ankündigen.

Die wichtigste Regel betrifft die Herkunft. Der Wert muss aus der Provisionierung in der Registry-Datenbank stammen; er darf nicht die herunterzählende Restzeit einer Live-DNS-Antwort darstellen. 3.600 bedeutet, dass für das RRset eine Stunde hinterlegt ist. Die Zahl beweist nicht, dass jeder autoritative Server sie bereits ausliefert, jeder Cache die Änderung kennt oder ein bestimmter Cache noch genau 3.600 Sekunden hält.

Diese Trennung schafft diagnostischen Wert. In einer Störung lassen sich Registry-Zustand, autoritative Antworten und rekursive Caches vergleichen. Unterschiede grenzen die Suche auf Provisionierung, Veröffentlichung, Verteilung oder Cache ein. RDAP liefert einen unabhängigen Bezugspunkt, kein Echtzeitmonitoring.

Freiwillige Offenlegung, verbindliche Bedeutung

Die Registry entscheidet, ob ttl0_data erscheint. Bei Veröffentlichung gelten jedoch feste Regeln. Typkürzel müssen bei der IANA registriert und großgeschrieben sein. Der TTL gehört zum RRset, nicht zum einzelnen Datensatz. Der JSON-Wert ist eine ganze Zahl ohne Bruch oder Exponent zwischen null und 2.147.483.647.

Der Standard beherrscht Vokabular, Format und Konformitätssignal. Die Registry beherrscht Offenlegung und repräsentierten Datenbankzustand. Der Client entscheidet über die Nutzung. Das Teilen der Konfiguration überträgt keiner Seite Kontrolle über das laufende DNS.

Registrare, Domaininhaber, DNS-Anbieter und Einsatzteams erhalten eine gemeinsame Referenz ohne internen Registry-Zugang. RFC 10037 bestätigt aber weder die Aktualität der Datenbank noch die Berechtigung einer Änderung oder die Übereinstimmung mit dem veröffentlichten DNS.

Ein offenes Schema verlangt bewegliche Clients

Clients müssen jeden gültigen DNS-Typ in values akzeptieren, auch künftige Typen. Frameworks, die JSON in starre Klassen umwandeln, können eine gültige Antwort verwerfen. Implementierungen sollen die dynamische Tabelle deshalb gesondert behandeln und das IANA-Verzeichnis verfolgen.

RDAP-Offenlegung und EPP-Provisionierung nach RFC 9803 sind getrennte Entscheidungen. Eine Registry kann die eine Erweiterung ohne die andere einsetzen. Die sichtbare TTL sagt nicht, wer sie gewählt hat, welche Richtlinie sie begrenzt oder wer sie ändern darf. RFC 10037 nimmt diese Autorisierungsfragen ausdrücklich aus seinem Umfang.

Belege, Gegenfaktum und Unbekanntes

Ohne die Erweiterung könnte RDAP weiterhin verwandte DNS-Datensätze zeigen, aber nicht die von der Registry konfigurierten TTLs. Betreiber wären auf das laufende DNS oder eigene Registry-Kanäle angewiesen und hätten keinen standardisierten unabhängigen Bezugspunkt. Das ist ein aus den Spezifikationen abgeleitetes Gegenfaktum, kein gemessenes Ergebnis.

Die Primärquellen nennen weder die Zahl produktiver ttl0_data-Einführungen noch eine verkürzte Störungsdauer, eine einheitliche Offenlegung über Objekte oder verändertes Kundenverhalten. Auch die Genauigkeit einer konkreten Implementierung zu einem bestimmten Zeitpunkt bleibt unbekannt und muss gesondert geprüft werden.

Quellen