Zusammenfassung

  • draft-brown-epp-deleg-03 schlägt EPP-Befehle zum Lesen, Erstellen, Hinzufügen, Entfernen und vollständigen Entfernen von DELEG-Datensätzen eines Domainsobjekts vor.
  • Der Entwurf erwartet eine längere Koexistenz von DELEG und herkömmlichem NS; ein korrektes Registry-Objekt kann deshalb zwei noch nicht abgeglichene öffentliche Delegationen speisen.
  • Ein belastbarer Abschlussbeleg reicht von der EPP-Transaktion über Zonenerzeugung, Parent-Veröffentlichung und DNSSEC bis zu Resolver-Fähigkeit, Cache und Anwendungstest.

Im Änderungsprotokoll steht ein erfolgreicher Server-Transaktionscode. Im DNS-Monitor steht ein erfolgreicher NS-Test. Dazwischen fehlt eine unbequeme Frage: Hat ein DELEG-fähiger Resolver denselben Parent-Zustand gesehen wie ein klassischer Resolver?

Revision 03 des EPP-DELEG-Entwurfs macht diese Frage dringlich. Sie führt benannte deleg:param-Elemente ein, hebt die XML-Namespace-Version an, ergänzt deleg:all für die Gesamtlöschung und verlangt operative Prüfungen. Der Datatracker-Eintrag und die Versionsgeschichte begrenzen die Aussagekraft: aktiver individueller Internet-Draft, kein RFC-Stream, kein verabschiedeter Standard und kein Einsatznachweis.

Der Befehl endet im Repository

info kann den gespeicherten DELEG-Zustand zeigen. create kann beim Anlegen einer Domain DELEG-Datensätze mitgeben. update kann Datensätze hinzufügen, gezielt entfernen oder mit deleg:all vollständig löschen. Damit lässt sich präzise dokumentieren, welche Mutation die Registry angenommen hat.

RFC 5730 definiert EPP-Kommando, Antwort und Transaktionskennungen. RFC 5731 beschreibt Domains, RFC 5732 Hosts. Eine positive Antwort schließt diesen Repository-Vorgang. Sie stammt nicht vom Zonengenerator, DNSSEC-Signer, autoritativen Server oder rekursiven Resolver.

Auch die Rolle des sponsoring client ist begrenzt. Der Server erkennt dessen Befugnis am Objekt an. Daraus entsteht keine Befugnis über Cache-Inhalte, Resolver-Versionen oder die spätere Dienstwirkung.

Zwei Projektionen sind zwei Fehlerflächen

Der EPP-Entwurf rechnet damit, dass die meisten Domains auf absehbare Zeit DELEG und NS im Parent benötigen. Server sollen daher DELEG zusammen mit klassischen Hostobjekten oder Hostattributen zulassen. Die Migration hält zwei Darstellungen für zwei Softwarepopulationen bereit.

Der WG-Entwurf Extensible Delegation for DNS soll die alte Unklarheit zwischen Parent- und Child-NS überwinden. DELEG wäre im Parent autoritativ, erweiterbar und DNSSEC-schützbar. Ein DELEG-RRset darf jedoch mit oder ohne NS vorkommen. Fehlt NS, kann DELEG-unfähige Software die delegierte Zone nicht auflösen.

Eine Gesamtlöschung kann deshalb ein geplanter Rückweg zu NS, der Abbruch eines Versuchs oder ein Fehler sein, der nur die neue Resolver-Gruppe trifft. Ein grüner NS-Check unterscheidet diese Fälle nicht. deleg:all braucht einen erklärten Sollzustand.

Der DNSOP-Entwurf zu Delegation Extensions behandelt Fähigkeitsaushandlung und Downgrade-Schutz. Die Registry kann deren Ausführung nicht durch das Speichern eines EPP-Objekts bezeugen.

Der Schlüsselbestand hat einen eigenen Stand

Revision 03 verlangt die Zurückweisung unbekannter Parameternamen und syntaktisch ungültiger Inhalte; Parameternamen innerhalb eines Datensatzes sind eindeutig. Client und Server müssen außerdem die registrierte DelegInfoKey-Liste regelmäßig aktualisieren.

Damit wird Erweiterbarkeit geordnet, aber nicht synchron. Ein neuer Client kann eine dem alten Server unbekannte Kennung senden. Später können beide sie akzeptieren, während der Zonengenerator sie nicht ausgeben kann. Danach kann ein Teil der Autoritäten beim Laden scheitern. Syntax, Komponentenunterstützung und öffentliche Wirkung brauchen getrennte Belege.

Der DELEG-Entwurf beantragt ein neues IANA-Informationsregister, der EPP-Entwurf Namespace- und Extension-Einträge. RFC 7451 liefert den Registrierungsrahmen; das aktuelle IANA-EPP-Register zeigt die tatsächlichen Zuweisungen. Im eingefrorenen Stand fehlt die vorgeschlagene DELEG-Erweiterung. Ein Antrag im Draft ist keine Zuweisung.

Ab der Parent-Zone beginnt ein zweites Protokoll

Der DELEG-Grundentwurf verbietet DELEG am Child-Apex, weil falsche Platzierung DNSSEC-Validierung scheitern lassen kann. RFC 4035 liefert den Validierungsrahmen. Erfolgreiche Validierung sagt etwas über die empfangenen, authentisierten Daten. Sie sagt nicht, ob diese Daten die jüngste EPP-Absicht abbilden oder mit NS übereinstimmen.

Der Nachweis beginnt mit Absicht, Genehmiger, Client-Identität, exakten Request-Bytes, Namespace, DelegInfoKey-Stand und beiden Transaktionskennungen. Danach folgen die commitete Objektversion und die Regel, nach der DELEG, Hosts und NS abgeglichen werden.

Anschließend werden Ein- und Ausgabe des Zonengenerators, Parent-Serial, Signatur und Ladeergebnis jeder Autorität festgehalten. Beobachtungen müssen DELEG-fähige und klassische Wege umfassen. Beim Resolver zählen Version, Fähigkeitssignal, Validierung, Cache-Epoche und Fallback. Den Abschluss bilden Anwendungstest und Rücknahmeentscheidung.

Die drei Heng-Lu-Texte sind offengelegte redaktionelle Perspektiven, keine Protokollnormen. Running-Code-Primat verlangt den Blick auf tatsächlich ausgelieferte Zustände. Minimale Anfangsspezifikation und lokale Entscheidung trennt Interoperabilität von Migrationspolitik. Realitätsschichten verhindern, dass ein administratives Zeichen als technisches Ergebnis gilt.

Offizieller Quellenstand

Der eingefrorene Satz umfasst Datatracker, Historie, Revision 03, die Entwürfe DELEG und DELEXT, EPP-Kern, Domain, Host, Extension-Register, DNSSEC und IANA. Sie belegen keine benannte Implementierung oder Wirkung.