Zusammenfassung

  • RFC 8334 trennt Launch-Registrierung und Launch-Anwendung. Im Anwendungsmodell kann ein gültiges Create EPP-Ergebnis 1001, applicationID und pendingCreate liefern, obwohl die Registry die Domain noch nicht zugeteilt hat.
  • Der Erfolg belegt Annahme des Befehls und Erzeugung eines Anwendungsobjekts. Markenpriorität, Zuteilung, Registerveröffentlichung, DNS-Delegation und Dienstbetrieb bleiben eigene Behauptungen.
  • Eine prüfbare Kette verbindet Transaktionskennungen, Phase und Richtlinienversion, geordnete Zustands- und poll-Meldungen sowie abschließende domain:panData. Danach werden Domainobjekt und Betriebsebenen getrennt gelesen.

Das Wort „erfolgreich“ ist in einem Protokoll kein Eigentumsnachweis. Es beschreibt zunächst, wie ein Befehl verarbeitet wurde. Erst wenn das Objekt des Verbs erhalten bleibt, lässt sich daraus eine korrekte geschäftliche Aussage bauen.

Im Beispiel von RFC 8334 lautet die Antwort Command completed successfully; action pending. Code 1001 kommt zusammen mit Phase und applicationID. Der Befehl ist abgeschlossen. Die Entscheidung über die Anwendung steht aus.

RFC 8334 erschien im März 2018 auf dem IETF Standards Track. Die Autoren sind J. Gould, W. Tan und G. Brown. Das IANA-Register der EPP-Erweiterungen verweist für das Launch-Phase-Mapping auf diese RFC. Gavin Brown steht hier für die gemeinsame Standardarbeit, nicht als Alleinautor, Registry-Betreiber, Markenprüfer oder persönlicher Zuteiler.

Das am 31. August 2026 gesicherte IETF-Profil nennt 25 Jahre Erfahrung mit DNS und Domainnamen, 22 Jahre bei Team Internet PLC, früher CentralNic, davon 14 als CTO, und eine heutige Tätigkeit bei ICANN. Es führt vier RFCs einschließlich RFC 8334 sowie öffentliche Aufgaben wie den Vorsitz bei RESTful Provisioning Protocol und ARTART-Reviews auf. Das erklärt Expertise, nicht die Autorität einer Registry.

Was beim Create tatsächlich entsteht

Eine Launch-Registrierung ist eine einzelne Registrierung in einer Startphase nach dem Prinzip der Eingangsreihenfolge. Eine Launch-Anwendung ist eine Absichtserklärung. Der Server kann mehrere Anwendungen für denselben Domainnamen halten und später eine für die Registrierung auswählen.

Mehrere Anwendungen sind eine Möglichkeit dieses Modells, keine universelle Startregel. Server können das Modell ablehnen. Phasen können andere Verfahren verwenden. Der Standard definiert die interoperable Form; die Serverrichtlinie entscheidet über Einsatz und Auswahl.

Bei einem gültigen Anwendungs-Create muss der Server ein Anwendungsobjekt erzeugen, eine Kennung vergeben, den RFC-5731-Status pendingCreate setzen und die applicationID zurückgeben. Sie macht eine Anwendung adressierbar, auch wenn andere denselben Namen betreffen.

Das ist ein echter Erfolg: Zustand wurde geschaffen und ist korrelierbar. Doch der Zustand gehört zur Anwendung. Die ID ist keine Domainberechtigung. pendingCreate bewahrt ausdrücklich, dass die angeforderte Aktion nicht abgeschlossen ist.

Ein Feld domain_create_success vernichtet diese Unterscheidung. Kunden lesen Registrierung, Buchhaltung beginnt, DNS-Teams suchen eine Delegation. Ein belastbares Ereignismodell nennt deshalb stets das Objekt: Anwendung angenommen, validiert, zugeteilt oder abgelehnt; Domainobjekt erzeugt; Veröffentlichung, Delegation und Dienst beobachtet.

Die enge Aussage von 1001

RFC 5730 definiert EPP und Ergebnis 1001 als erfolgreich abgeschlossenen Befehl mit ausstehender Aktion. Die Antwort kann die Client-Transaktionskennung wiederholen und muss eine Server-Transaktionskennung enthalten. Beide verbinden die Protokolle der Beteiligten.

Der Beleg einer Launch-Anwendung hält Zeit, Sponsorclient, Domain, Endpunkt, beide IDs, Phase, Unterphase, Create-Form, geltende Richtlinie, Ergebnis, applicationID, RFC-5731-Status und Launch-Status fest.

Damit ist belegt: Dieser Server nahm diese Anwendungsoperation in diesem Kontext zu diesem Zeitpunkt an. Nicht belegt sind Markenrecht, Abschluss der Validierung, Auswahl gegenüber Konkurrenten, Existenz eines stabilen Domainobjekts, RDAP-Veröffentlichung, Eintrag in der Elternzone oder Erreichbarkeit eines Dienstes.

Die Zuständigkeiten folgen den Verben. Der Registrarclient reicht ein. Ein Validator bewertet bei Bedarf Material. Die Registry wendet Richtlinien an. Ein Projektionssystem veröffentlicht. Der Zonenbetreiber delegiert. Autoritative Server antworten. Der Dienstbetreiber konfiguriert. Der erste Erfolg erbt nicht die Mandate der nächsten Stellen.

Phasenbezeichnung und Richtlinie trennen

RFC 8334 nennt sunrise, landrush, claims, open und custom. Die Phase muss im Befehl stehen; der Server sollte sie prüfen und kann eine Unterphase prüfen. Phasen können überlappen, ein Namensattribut kann sie verfeinern.

Das liefert Kontext, aber keine vollständige Richtlinie. Zwei Registries können sunrise mit verschiedenen Fenstern, Validatoren, Gebühren, Nachweisen und Auswahlmethoden verwenden. Die konkrete Entscheidung bleibt teilweise außerhalb des Protokolls.

Darum gehören Richtlinienversion und Geltungszeit zum Beleg. Die Bezeichnung allein erklärt nicht, welches Markenmaterial nötig war, ob mehrere Anwendungen möglich waren, welche Zustände übersprungen werden durften oder wie die Auswahl erfolgte.

RFC 7848 definiert Marken- und signierte Markenobjekte für verwandte Mechanismen. RFC 8334 kann je nach Form Marken, signierte Objekte, Codes oder Hinweise tragen. Sie belegen Herkunft und einzelne Prüfungen, nicht automatisch die Zuteilung. Ebenso darf ein Prüfer keinen fehlenden Beleg rügen, bevor feststeht, dass die damalige Form und Richtlinie ihn verlangte.

Pending ist eine Sequenz

Zu den Launch-Zuständen gehören pendingValidation, validated, invalid, pendingAllocation, allocated, rejected und custom. Solange ein verwendeter Launch-Zustand nicht final ist, bleibt pendingCreate. Richtlinien dürfen Zwischenzustände überspringen.

Nur den letzten Status zu speichern reicht nicht. Es muss nachvollziehbar bleiben, welche Prüfung stattfand, was regulär übersprungen wurde, wann eine Meldung ankam und wer handeln musste.

Die poll-Warteschlange aus RFC 5730 transportiert asynchrone Änderungen. Meldungen haben IDs, werden abgerufen und bestätigt. RFC 8334 empfiehlt sie für Zwischenstände und verlangt für allocated und rejected die abschließende RFC-5731-Meldung domain:panData.

Eine Prüfung erhält Reihenfolge, Meldungs-ID, Einreihung, Abruf, Bestätigung, Zustand, Anwendung und Transaktionen. Allocated belegt die Auswahl und den Übergang zum Domainobjekt. Rejected belegt, dass diese Anwendung nicht zur Registrierung wurde. Schweigen oder eine leere öffentliche Suche belegt keines von beidem.

Anwendungen und schon ihre Existenz können vertraulich sein. Unbefugte Operationen erhalten 2201; Ausgaben können gefiltert werden. Öffentliche Unsichtbarkeit ist eine Aussage über Zugriffsrechte, nicht zwingend über Nichtexistenz.

Nach der Zuteilung folgen weitere Wahrheiten

Nach allocated ist das RFC-5731-Domainobjekt zu lesen. Danach werden Registry- oder RDAP-Veröffentlichung, Delegation in der Elternzone, autoritative DNS-Antwort und Dienstbetrieb getrennt geprüft.

Zuteilung ohne Objekt weist auf Registry-Provisionierung. Objekt ohne Delegation weist auf Zonenveröffentlichung oder Registrantenkonfiguration. Delegation ohne autoritative Antwort betrifft DNS-Betrieb. Korrektes DNS ohne Dienst betrifft Anwendung, Netz oder Hosting.

Running-Code Primacy heißt: Jede Ebene belegt nur ihre Beobachtung. EPP belegt EPP-Zustand, Registry-Readback das Objekt, RDAP seine Projektion, DNS eine zeit- und ortsgebundene Antwort, eine Verbindung den Dienstversuch. Der erste Beleg darf nicht für alle Ebenen sprechen.

Der erforderliche Belegverbund

Für eine belastbare Aussage braucht es:

  1. Client- und Server-Transaktions-ID, Zeit, Sponsor, Domain, Endpunkt und Ergebnis;
  2. Phase, Unterphase, Form, Richtlinienversion, Geltung und Auswahlverfahren;
  3. applicationID, anfängliches pendingCreate, Launch-Zustand und Zugriffsberechtigte;
  4. Validator, Marke, Signatur, Code und Hinweis nur, soweit die Richtlinie sie verlangt;
  5. geordnete Zustände und poll-Meldungen mit Abruf, Bestätigung, Sprüngen und Ausnahmen;
  6. abschließende domain:panData für allocated oder rejected;
  7. resultierendes RFC-5731-Domainobjekt;
  8. Registry/RDAP, Zone, autoritatives DNS und Dienst als getrennte Beobachtungen;
  9. Vertraulichkeitsgrund, Filter, Aufbewahrung und Prüfverantwortung.

So lässt sich Annahme beweisen, ohne Zuteilung vorzutäuschen. Antragsteller, Registry, Validator und Betrieb behalten jeweils ihren Beleg und ihre Grenze. Vertrauliche Inhalte müssen nicht öffentlich werden, damit der Ablauf nachweisbar ist.

RFC 8334 gibt dem Unfertigen eine ID, einen Verlauf und einen Abschluss. Die applicationID identifiziert das Warten, Zustände und poll erhalten die Geschichte, panData beendet sie. Governance scheitert, wenn daraus nur ein grünes „erfolgreich“ wird.

Quellen