Zusammenfassung

  • RDAP DELEG-05 entfernte priority und target, benannte die Struktur in DelegInfos um und richtete die Beispiele an DELEG-11 aus.
  • Der normativ referenzierte EPP-DELEG-Entwurf enthält beide Attribute weiterhin in einem XML-Schema, das er als vollständig und automatisch validierbar beschreibt.
  • Der RDAP-Text verlangt bereits den Bezeichner dnsDeleg, markiert die vollständige Definition seiner JSON-Schlüssel und -Werte aber noch als TBD.
  • Die Quellen zeigen keine laufende Implementierung und keinen Datenverlust. Sie zeigen, dass der Rundweg EPP–DNS–RDAP in den aktuellen Texten noch nicht eindeutig getestet werden kann.

Die Ausgabeseite ist weitergezogen

Die I-D-Ankündigung datiert draft-albanna-regext-rdap-deleg-05 auf den 4. September 2026. Der Entwurf soll DELEG- und DELEGPARAM-Werte in RDAP-Antworten für Domainobjekte aufnehmen. Er definiert also eine öffentliche Sicht auf einen neuen DNS-Delegationszustand.

Das Änderungsprotokoll nennt drei zentrale Anpassungen: priority und target wurden gestrichen, delegInfo wurde zu DelegInfos, und die Beispiele folgen nun DELEG-11. DELEG-11 sagt ausdrücklich, dass das Format zwar von SVCB inspiriert ist, aber weder SvcPriority noch TargetName enthält. Die Nutzlast ist eine Liste von DelegInfo-Schlüssel-Wert-Paaren.

Als anfängliche Namensserverinformationen definiert der Text server-ipv4, server-ipv6, server-name und include-delegparam, ergänzt um mandatory. Eine eigene IANA-Registry soll künftigen Schlüsseln Nummer, Namen, Bedeutung, stabile Referenz und Änderungsverantwortlichen zuordnen. Erweiterung soll damit möglich, aber öffentlich begrenzt sein.

RDAP-05 folgt dieser Modelländerung auf der Leseseite. Dort sind die zwei alten Mitglieder verschwunden.

Das Eingabeschema stammt noch aus dem vorherigen Stand

Der RDAP-Entwurf beruft sich nicht nur auf DELEG, sondern normativ auch auf die EPP-Abbildung für DELEG. EPP dient dazu, dass ein betreuender Client Domainobjekte bei einer Registry anlegt, ändert und abfragt. Die vorgeschlagene Erweiterung baut auf der Domainabbildung aus RFC 5731 auf.

In EPP DELEG-02 wird die formale Syntax als vollständiges Schema für die automatische Validierung von XML-Instanzen bezeichnet. delegType hat darin weiterhin ein vorzeichenloses Kurzinteger-Attribut priority und ein Attribut target. Der Parametertyp lässt über processContents="skip" weitere beliebige Attribute zu.

Die Zeitfolge ist eine plausible Erklärung: EPP-02 erschien am 21. Juli, DELEG-11 am 23. Juli und RDAP-05 im September. Doch zeitlicher Nachlauf ist keine normative Konvertierungsregel. Ein nach dem veröffentlichten EPP-Schema gültiger Schreibvorgang kann zwei Felder tragen, die das aktuelle DNS-Modell nicht kennt und der aktuelle RDAP-Text bewusst entfernt hat.

Ob eine Brücke sie ablehnen, ignorieren, privat erhalten oder anders abbilden soll, ist nicht festgelegt. Ebenso wenig belegen die Quellen, dass ein Registrar oder eine Registry diesen Fall bereits umsetzt. Die Lücke liegt in den Texten, nicht nachweislich in einem betriebenen System.

dnsDeleg verrät nicht, wie die Antwort entstand

RDAP-05 verlangt dnsDeleg in rdapConformance, sobald die neue Struktur ausgegeben wird. RFC 9083 beschreibt solche Kennungen als Hinweise auf die Spezifikationen, die beim Aufbau einer Antwort verwendet wurden. Sie helfen Clients, benutzerdefiniertes JSON einzuordnen. Sie belegen nicht die Herkunft jedes Werts oder die verlustfreie Verarbeitung eines EPP-Eingangs.

Gerade das ist relevant, weil die vollständige Festlegung der in DelegInfos zulässigen Paare in RDAP-05 noch mit TBD markiert ist. Der Text wartet auf die weitere Entwicklung von DELEG und EPP. Beispiele zeigen ein Zielbild, aber keine verbindliche Tabelle zwischen EPP-XML, DNS-Darstellung, DNS-Wireformat und RDAP-JSON.

Zum eingefrorenen Recherchezeitpunkt enthielt die IANA-Registry für RDAP Extensions keinen Eintrag dnsDeleg. Der Entwurf beantragt ihn für Betreiber vom Typ „Any“. Das ist keine Ablehnung durch IANA, sondern der gegenwärtige Stand eines noch vorgeschlagenen Identifikators.

Ein separater REGEXT-Entwurf behandelt die Versionierung von RDAP-Erweiterungen. Er schlägt maschinenlesbare Versionen, Vorgänger- und Nachfolgerbeziehungen, Hinweise zur Ablösung und Übergangsregeln vor. RDAP DELEG-05 nutzt dieses Verfahren derzeit nicht, um seine genaue Nutzlastfassung zu benennen.

Drei Texte, drei Verfahrensstände

Der Datatracker-Eintrag zu RDAP DELEG weist einen individuellen Internet-Draft ohne RFC-Stream und verantwortlichen Area Director aus. Die EPP-Abbildung ist ebenfalls ein individueller Entwurf. Veröffentlichung bedeutet keine IETF-Billigung.

DELEG-11 ist dagegen ein Dokument der DELEG Working Group in der Working Group Last Call. Es ist dennoch kein RFC; DNS-RR-Werte und die neue Schlüsselregistry sind teilweise noch beantragt oder offen. Der fortgeschrittenere Status des Basistexts überträgt sich nicht automatisch auf seine Begleitentwürfe.

Die angemessene Aussage lautet deshalb: Die Naht ist offen und vermutlich reparierbar. Für eine Schwachstelle, einen Ausfall oder eine tatsächliche Beschädigung fehlen Belege.

Gesucht ist eine nachprüfbare Bedeutungskette

Ein vollständiger Vertrag muss für jedes Feld die maßgebliche Fassung nennen, den Übergang von EPP zu autoritativem DNS und weiter zu RDAP festlegen und jeden beabsichtigten Informationsverlust benennen. Er sollte außerdem unterscheiden, ob der öffentliche Wert Registry-Absicht, beobachteten autoritativen DNS-Zustand oder eine andere deklarierte Projektion wiedergibt.

Ohne diese Angaben kann dnsDeleg bei zwei Servern zwei verschiedene Konvertierungsentscheidungen verbergen. Wer die Abbildung kontrolliert, kontrolliert, welche Version einer Absicht sichtbar wird. An dieser Stelle wird aus Schemaarbeit Governance.