Zusammenfassung

  • draft-brown-epp-deleg-03 vom 29. September erlaubt innerhalb von <deleg:rem> das leere Element <deleg:all/>. Damit ließe sich die Entfernung aller DELEG-Einträge der genannten Domain beantragen, ohne jeden Eintrag aufzulisten. In Fassung 02 gab es diese Variante nicht.
  • Der Text ist ein aktiver individueller Internet-Draft, weder verabschiedeter RFC noch Nachweis eines Registry-Betriebs. Der Geltungsbereich von „alle“ ist auf DELEG dieser Domain begrenzt; die klassischen NS-Einträge und die Domainregistrierung sind nicht das Ziel.

Eine namentliche Liste macht die Reichweite einer Änderung sichtbar. Wer zwei zu entfernende Einträge genehmigt, kann prüfen, ob genau diese beiden gemeint sind. Bei einer Alles-Anweisung ergibt sich die endgültige Menge hingegen aus dem Zustand, den der Server im Ausführungszeitpunkt vorfindet. Darin liegt die neue Entscheidung, die der überarbeitete EPP-DELEG-Entwurf ermöglicht. Er dokumentiert keine tatsächlich erfolgte Löschung.

Abschnitt 5.2.2 beschreibt beide Wege für ein Domain-Update: einzelne deleg:deleg-Einträge in <deleg:rem> oder stattdessen <deleg:all/> für den gesamten DELEG-Bestand. Ein Beispiel entfernt alle DELEG-Einträge und fügt keine hinzu. Die vorangehende Fassung kannte nur die gezielte Entfernung. Sollte die neue Form später implementiert werden, braucht der Client die vorhandenen Einträge nicht vorab vollständig zu erfassen, um einen leeren DELEG-Satz anzufordern.

„Alle“ bezieht sich nicht auf alles im DNS. Die Anweisung gehört zur DELEG-Erweiterung eines EPP-Updates. Sie löscht weder die Domain als Objekt noch EPP-Hostobjekte oder sämtliche DNSSEC-Daten. Abschnitt 6 sieht vielmehr das Nebeneinander von DELEG und herkömmlichen NS vor. Selbst eine erfolgreiche Antwort des EPP-Servers würde nur einen Teil der Beweiskette abdecken: Ob autoritative Server denselben Zustand publizieren und was rekursive Resolver noch im Cache haben, muss separat beobachtet werden.

Zusätzlich ändert Fassung 03 das Datenformat. An die Stelle von Attributen in deleg:params treten deleg:param-Elemente; der vorgeschlagene XML-Namensraum wechselt von deleg-0.01 zu deleg-0.02. Die bisherigen Schemafelder priority und target entfallen. BTW hatte zuvor die Abweichung dieser Felder zwischen dem alten EPP-Entwurf und dem RDAP-Entwurf beschrieben. Die Streichung reduziert genau jene textliche Abweichung, beweist jedoch keinen produktiven und verlustfreien Weg von EPP über DNS nach RDAP. Hier geht es um die neue Möglichkeit, den gesamten Satz zu entfernen.

Der Sicherheitsabschnitt verlangt im Entwurf die Zurückweisung unbekannter Parameternamen und ungültiger Werte; Clients und Server sollen Listen registrierter Schlüssel regelmäßig aktualisieren. Ein gültiges Datenformat beantwortet aber nicht, wer zur vollständigen Entfernung ermächtigt ist. Ebenso wenig belegt die Erwähnung registrierter Schlüssel, dass die IANA die entsprechende Registrierung bereits betreibt. Die elfte Fassung des zentralen DELEG-Entwurfs beantragt die Einrichtung eines Delegation-Information-Registers noch ausdrücklich.

Der Datatracker führt den EPP-Text als aktiven individuellen Internet-Draft ohne RFC-Stream oder zuständigen Area Director, mit dem IESG-Status „I-D Exists“. Die Ankündigung vom 29. September belegt die Veröffentlichung einer Fassung, nicht IETF-Konsens, Verfügbarkeit bei Registries, einen Ausfall oder Schaden. Die Bedeutung liegt in einer künftigen Zugriffskontrolle: Eine Routinekennung für Einzeländerungen darf nicht stillschweigend zur Kennung für eine vollständige Entfernung werden.

Quellen