Zusammenfassung

  • RFC 5144 definiert DCHK als leichtgewichtigen IRIS-Registry-Typ und strikte Teilmenge von DREG.
  • active und inactive beziehen sich auf DNS-Veröffentlichung, nicht auf Registrierbarkeit.
  • reserved kann eine normale Registrierung ausschließen, obwohl der Name im DNS inaktiv ist.
  • Streit- und Karenzstatus bewahren Lebenszykluszustände jenseits eines Ja/Nein-Feldes.
  • Operationen können pending oder prohibited sein; ihr Name ist kein Abschlussbeleg.
  • Akteur, Geltungsbereich und Substatus-Autorität begrenzen die Aussage.
  • Das Aktualisierungsdatum der Quelldatenbank ist nicht Antwort- oder Entscheidungszeit.
  • Eine Registrierungsreferenz weist weiter, überträgt aber keine Befugnis.
  • Die IRIS-XML-Schicht besitzt selbst weder Authentisierung noch Vertraulichkeit.
  • IANA-Einträge belegen Zuweisungen, keine laufende DCHK-Infrastruktur.
  • Die alte Nameprep-Abhängigkeit verlangt eine gesonderte IDN-Kompatibilitätsprüfung.
  • Führung muss Transportbeleg, Policy-Entscheid und Registry-Mutation auseinanderhalten.

Sicherheit beantwortet nur ihre eigene Frage

RFC 3981 erklärt ausdrücklich, dass die XML-Schicht von IRIS keine eigene Authentisierung oder Privatsphäre bereitstellt. Diese Funktionen gehören zur Anwendungstransportschicht. Bei weiterführenden Referenzen warnt der Standard zudem vor wiederholbaren Zugangsdaten.

RFC 5144 verpflichtet DCHK-Clients und -Server zur Unterstützung von IRIS-LWZ; XPC und BEEP sind optional. Selbst wenn der gewählte Transport den Gegenpart zuverlässig authentisiert, folgt daraus lediglich: Diese Sitzung fand nach dem Sicherheitsmodell des Transports mit diesem Dienst statt. Es folgt nicht: Die Datenquelle war aktuell, der Status galt global, der Antragsteller war berechtigt oder die Registry hat ein Objekt verändert.

Die Verwechslung entsteht, weil Authentisierung wie eine starke Quittung aussieht. Stark ist sie aber nur innerhalb ihres Gegenstands. Ein gültiges Siegel auf einer Beobachtung vergrößert nicht die Zuständigkeit des Beobachters.

inactive ist keine Einladung

DCHK nennt einen Namen active, wenn er durch Delegation oder direkte Publikation im DNS verfügbar ist. inactive bedeutet, dass dies nicht der Fall ist. Die Achse heißt Veröffentlichung.

Für die Registrierung existiert der eigene Status reserved: Der Name steht im normalen Verfahren nicht zur Verfügung. Dazu kommen Streit, Policy-Konformität und mehrere Karenzperioden. RFC 3915 zeigt den Ablauf nach einer Löschung. Redemption, ausstehende Wiederherstellung und ausstehende endgültige Löschung liegen vor einer möglichen Neuregistrierung.

Auch Operationswörter dürfen nicht als Vergangenheit gelesen werden. Create, delete, renew, restore, transfer und update können pending oder prohibited sein. RFC 5731 beschreibt den EPP-Check als Hinweis auf einen möglichen Create-Erfolg, weil die tatsächlichen Anforderungen Server-Policy bleiben. Eine verarbeitete Transformation kann weiter ausstehen.

Provenienz ist Bestandteil des Status

Ein DCHK-Status kann ein Anwendungsdatum, Tickets und sprachlich markierte Beschreibungen enthalten. Ein frei definierbarer Substatus muss die Autorität nennen, die ihn definiert. actor unterscheidet Registry, Registrar und Registration Service Provider; scope begrenzt Kontext oder Herkunft.

Wer diese Felder bei der Normalisierung entfernt, erhebt eine lokale Aussage zur allgemeinen Regel. Eine Sperre des Registrars wird zur Sperre des Registers, eine ausstehende Übertragung zum Eigentumswechsel und eine Policy-Aussage zum universellen Recht.

lastDatabaseUpdateDateTime schützt eine weitere Grenze. Es datiert die letzte Aktualisierung der Quelldatenbank, nicht die schnelle API-Antwort. Quellzeit, Empfangszeit, Cachezeit und Entscheidungszeit müssen getrennt protokolliert werden.

Ein Verweis stellt die nächste Frage

Die registrationReference kann von einem Registry-Ergebnis zum Registrar oder Registrantendienst führen. IRIS-Referenzen und Suchfortsetzungen dürfen Registry-Typen und Instanzen überschreiten; Clients sollen sie nur einmal verfolgen, damit keine Endlosschleife entsteht.

Ein erreichbares Ziel ist keine Genehmigung. Der nachgelagerte Dienst kann andere Daten, Authentisierung, Preise und Regeln besitzen. Er entscheidet selbst. Ein vorgelagerter Informationsdienst kann diese Zuständigkeit nicht per URI übertragen.

Formeller Bestand und laufender Betrieb

RFC 5144 ist weiterhin Proposed Standard. IANA führt dchk1, DCHK1 und das BEEP-Profil. Das einzige verifizierte Erratum korrigiert die Schreibweise von „Straightforward-NAPTR“. Diese Fakten belegen Dokumentation und Zuweisung, nicht aktuelle Nutzung.

Der IDN-Verweis führt zu RFC 3491 Nameprep, der inzwischen obsolet ist. RFC 5891 definiert IDNA2008. Daraus folgt weder eine formelle Ablösung von RFC 5144 noch die Kompatibilität seiner alten Normalisierung mit heutiger Registry-Policy. RFC 9083 dient lediglich als späteres Beispiel eines JSON-basierten Registry-Antwortmodells.

Die notwendige Belegkette

Zuerst stehen normalisierte Anfrage, Zielautorität, Protokollversion, Rohantwort und Quellzeit. Dann folgen vollständige Statusmenge, Akteur, Scope, Disposition, Ticket und Substatus-Autorität. Referenzziel und tatsächlich erreichter Dienst bilden eine eigene Quittung.

Erst danach kommen Identität und Berechtigung, Policy-Version, Preis, Kommandoannahme, Prüfung, bestätigte Mutation, DNS-Publikation und beobachtete Nutzbarkeit. Jede Stufe erlaubt die nächste Prüfung. Keine beweist deren Ergebnis im Voraus.

Quellen

  1. RFC 5144, HTML
  2. RFC 5144, Text
  3. RFC-Editor-Eintrag
  4. IETF-Datatracker-Eintrag
  5. Dokumenthistorie
  6. Errata-Suche
  7. Fassung mit verifiziertem Erratum
  8. IANA XML Registry
  9. IANA S-NAPTR Parameters
  10. IANA BEEP Parameters
  11. RFC 3981: IRIS-Kern
  12. RFC 3982: IRIS-Domain-Registry-Typ
  13. RFC 3983: IRIS über BEEP
  14. RFC 4992: XML-Pipelining für IRIS
  15. RFC 4993: Leichter UDP-Transport für IRIS
  16. RFC 3915: EPP-Karenzperioden
  17. RFC 5731: EPP-Domain-Mapping
  18. RFC 3491: Nameprep
  19. RFC 5891: IDNA2008
  20. RFC 9083: RDAP-JSON-Antworten
  21. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  22. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  23. Running-Code Primacy