Zusammenfassung

  • draft-skoglund-epp-registry-lock-00 schlägt einen ausstehenden EPP-Ablauf vor: Ein oder mehrere Registry-Lock-Kontakte müssen Änderungen an einer geschützten Domain vor Ablauf einer Frist freigeben.
  • Die Richtlinie kann eine Zahl erforderlicher Freigaben nennen, und das Poll-Ergebnis kann die IDs der zustimmenden Kontakte aufführen. Identitätsniveau, Bindung der Challenge und Unabhängigkeit von Personen, Kanälen und Wiederherstellungswegen werden jedoch nicht standardisiert.
  • Betreiber brauchen zusätzlich ein Protokoll der Freigabezeremonie, das Vorher- und Nachher-Zustand, alte Richtlinie und Kontaktmenge, Kontrolldomänen, Challenges, Antworten, Ausnahmen, Zeitpunkte und Endergebnis miteinander verbindet. Das ist ein Governance-Vorschlag, keine IETF-Vorgabe.

Ein Quorum verspricht eine klare Zahl. Eine Freigabe gilt als einzelner Ausfallpunkt, zwei oder drei erscheinen robuster. Doch zwei Kontakte können unterschiedliche E-Mail-Adressen im selben Unternehmenstenant verwenden, ihre Konten über denselben Helpdesk wiederherstellen und Codes auf Geräten empfangen, die ein und derselbe Administrator verwaltet. Das Protokoll sieht zwei Zustimmungen. Ein Angreifer muss womöglich nur eine administrative Domäne beherrschen.

Gerade beim Registry Lock ist diese Unterscheidung wesentlich. Er schützt Domains, bei denen eine ungewollte Änderung weitreichendere Folgen hat als die Übernahme eines gewöhnlichen Benutzerkontos. Neue Nameserver können Verkehr und E-Mail umleiten. Ein Inhaberwechsel kann die rechtliche Kontrolle verschieben. Ein Transfer kann die operative Beziehung zu einem anderen Registrar verlagern. Die Registry-Sperre stellt eine Institution außerhalb des normalen Zugangspfads beim Registrar dazwischen. Automatisierung ist nur dann ein Gewinn, wenn sie die Unabhängigkeit dieser zweiten Institution nicht unbemerkt aufhebt.

Die Revision 00, draft-skoglund-epp-registry-lock-00, wurde am 30. Juni 2026 veröffentlicht. Im gerenderten Kopf steht „Standards Track“. Der Datatracker führt das Dokument dagegen als individuellen Internet-Draft ohne Stream, beabsichtigten RFC-Status oder formale Stellung im IETF-Standardisierungsprozess. Es handelt sich um einen Diskussionsvorschlag, nicht um einen RFC und nicht um festgestellten REGEXT-Konsens.

Aus einem Befehl wird ein Entscheidungsfall

Der Entwurf beschreibt Registry Lock als Schutz auf Ebene der Registry und nicht nur des Registrars. Solche Angebote existieren bereits mit unterschiedlichen, häufig manuellen Verfahren. Die Erweiterung soll es einem betreuenden EPP-Client ermöglichen, eine gesperrte Domain stärker automatisiert einzurichten und zu verwalten.

Nach der Einrichtung muss die Domain serverDeleteProhibited tragen. Solange eine Transformationsanfrage auf Freigabe wartet, muss serverPendingUpdate gesetzt sein. Das Einrichten des Locks oder eine Änderung an der gesperrten Domain liefert EPP-Ergebniscode 1001: Der Befehl wurde angenommen, wartet aber auf eine weitere Handlung. Rechtzeitige Freigabe führt später zu einer erfolgreichen Poll-Nachricht; Fristablauf ohne Freigabe zu einer Fehlermeldung.

Damit verändert sich die zeitliche Bedeutung des ursprünglichen Befehls. Sein Empfang ist nicht mehr gleichbedeutend mit einer vollzogenen Zustandsänderung. Er eröffnet einen Autorisierungsvorgang. Der Client muss später das Warteschlangenereignis dem früheren Auftrag zuordnen, und der Betrieb darf „angenommen und ausstehend“ nicht mit „umgesetzt“ verwechseln.

Die vorgesehenen Poll-Daten sind dafür hilfreich. Sie nennen Domain, Operation, eine frühere Server-Transaktions-ID und die als zustimmend vermerkten Kontakt-IDs. Die äußere Poll-Antwort enthält außerdem die üblichen Queue- und Transaktionskennungen aus RFC 5730. Protokollseitig lassen sich Anfang und Ende also verbinden. Der eigentliche Entscheidungsweg dazwischen bleibt jedoch unbeschrieben.

Mehrheit ist noch keine Gewaltenteilung

Die Policy kann eine optionale Frist und eine positive, von null verschiedene Zahl notwendiger Zustimmungen enthalten; in Revision 00 heißt das Feld quorom. Der Server darf zulässige Werte begrenzen. Einer Domain können mehrere Lock-Kontakte zugeordnet sein, und die Zahl bestimmt, wie viele von ihnen zustimmen müssen.

Diese Zahl ist nützlich: Server und Client sollen nicht unterschiedliche Vorstellungen davon haben, ob eine oder zwei Antworten reichen. Sie sagt aber nicht, ob verschiedene natürliche Personen, Arbeitgeber, Geräte oder Wiederherstellungswege beteiligt sind. Drei Kennungen können in ein gemeinsames Postfach münden. Zwei Tochtergesellschaften können denselben Identitätsanbieter nutzen. Ein Dienstleister kann sämtliche Telefone und Token verwalten.

Mehrzahl und Unabhängigkeit sind verschiedene Eigenschaften. Mehrzahl ist eine Eigenschaft der Datenbank: Es gibt mehrere Kontakteinträge. Unabhängigkeit ist eine Eigenschaft der Kontrollarchitektur: Ein einzelner Ausfall, Zwang oder Recovery-Prozess kann nicht alle nötigen Freigaben hervorbringen.

Ein Protokoll muss keine vollständige Unternehmensverfassung kodifizieren. Ein Betreiber sollte quorom=2 aber nicht als Vier-Augen-Integrität vermarkten, wenn sein Verfahren keine Trennung durchsetzt. Eine solche Zusage braucht wenigstens eine benannte Unabhängigkeitsregel und Belege, dass die konkreten Freigaben ihr entsprachen.

Kanalnamen sind keine Vertrauensstufen

Jeder Registry-Lock-Kontakt besitzt eine Kennung und kann eine Freigabemethode nennen. Der Entwurf führt die bekannten Zeichenketten E-Mail, Textnachricht, Brief, Telefon und Token auf; ein Server darf weitere Methoden zulassen.

Diese Namen bezeichnen Transportarten, keine Sicherheitsniveaus. „E-Mail“ verrät nicht, ob ein signierter Link, eine einfache Antwort, ein Portal-Login oder ein Helpdesk-Gespräch verwendet wurde. „Textnachricht“ sagt nichts über eine aktuelle Prüfung der Rufnummer, Schutz vor Neuvergabe oder die Verbindung zur bestellten Person. Ein „Token“ kann ein Hardware-Authentifikator sein oder ein weiterleitbarer Code. Ein Telefonanruf beweist nicht die Identität des Gesprächspartners, und auch ein Brief braucht einen dokumentierten Empfänger und eine gebundene Aufgabe.

Die Erweiterung normiert weder den Inhalt der Challenge noch ihre Bindung an die beantragte Änderung. Auch Replay-Schutz, Kanalregistrierung, Identitätsprüfung und Wiederherstellung bleiben offen. Für ein frühes EPP-Mapping kann das sinnvoll sein. Registries arbeiten mit verschiedenen Dienstmodellen; eine weltweit vorgeschriebene Zeremonie könnte die Einführung erschweren.

Die Offenheit begrenzt jedoch die Aussagekraft des Poll-Ergebnisses. Eine Kontakt-ID in approvedBy bedeutet, dass die Registry nach ihrem Verfahren eine Zustimmung verbucht hat. Sie macht nicht alle Verfahren gleichwertig und belegt nicht, dass der Registrar einer gemeinsamen Kompromittierung widerstehen konnte.

Eingefrorene Kontakte schließen nur einen Angriffsweg

Der Entwurf verlangt, Änderungen an einem Kontaktobjekt zurückzuweisen, solange es einer geschützten Domain als Lock-Kontakt zugeordnet ist. Auch eine Löschung muss scheitern. Das verhindert einen naheliegenden Angriff: zuerst E-Mail-Adresse oder Telefonnummer im Kontakt austauschen und anschließend über den neuen Endpunkt freigeben.

Gleichzeitig kann eine Registry-Lock-Aktualisierung Kontakte hinzufügen oder entfernen und Policy-Werte ändern. Änderungen an der gesperrten Domain sollen zwar in den ausstehenden Freigabeablauf gehen. Trotzdem bleibt die rekursive Governance-Frage: Welche bestehende Autorität darf den künftigen Kreis der Autoritäten verändern?

Ein dritter Zustimmer ist keine gewöhnliche Nameserver-Änderung. Wird der einzige Kontakt außerhalb des Identitätssystems eines Unternehmens entfernt, verschwindet die Trennung. Ein kleineres Quorum oder eine kürzere Frist kann die Zeremonie schwächen, bevor der nächste operative Eingriff erfolgt. Ein generisches Poll-Ergebnis „Update erfolgreich“ zeigt nicht zwingend, welche alte Regel die neue Regel legitimierte.

Deshalb muss der Ausgangszustand maßgeblich bleiben. Änderungen an Kontakten und Policy sind anhand der Regel und der Kontaktmenge zu beurteilen, die beim Start der Anfrage galten. Für ausgeschiedene, handlungsunfähige oder nicht erreichbare Personen braucht es explizite Regeln. Sonst kann sich das Verfahren genau in dem Augenblick selbst umschreiben, in dem Kontinuität am wichtigsten ist.

Ausnahmen markieren den wirklichen Schutzrand

Registry Lock bedeutet nicht, jede Handlung zu unterbinden. Verlängerungen bleiben laut Entwurf möglich. Eine Registry kann automatisierte DNSSEC-Bereitstellung von der Autorisierung ausnehmen, etwa einen Scanner für CDSS oder CSYNC. Die Entfernung des Locks bleibt ein manuelles Betriebsverfahren außerhalb der Spezifikation.

Für diese Grenzen gibt es gute Gründe. Würde eine Sperre die Verlängerung verhindern, könnte ein Schutzinstrument zum Ablaufdatum-Risiko werden. Automatisierte DNSSEC-Pflege kann Kontinuität sichern und Fehler beim Schlüsselwechsel reduzieren. Die Entfernung in einer frühen Automatisierung auszusparen, kann eine strengere Notfallzeremonie bewahren.

Jede Ausnahme gehört dennoch zur tatsächlichen Policy. Eine pauschal als „registry-gesperrt“ bezeichnete Domain kann sich durch einen automatischen Scanner verändern. Der stärkste Ausweg, die Aufhebung der Sperre, wird anderswo geregelt. Leser eines EPP-Status müssen wissen, dass sie eine Barriere mit benannten Öffnungen sehen, keinen absolut unveränderlichen Zustand.

Eine DNSSEC-Ausnahme sollte festhalten, welcher Scanner handelte, welche Records er sah, welche Regel die Umgehung erlaubte und wie die Delegation vorher und nachher aussah. Eine manuelle Entfernung sollte einen Nachweis erzeugen, der mit dem EPP-Verlauf korreliert werden kann. Sonst wird ausgerechnet der mächtigste Pfad der maschinell am schlechtesten prüfbare.

Bestehende Dienste zeigen die verborgene Vielfalt

Das IANA-Verzeichnis der EPP-Erweiterungen führt bereits die Swedish Internet Foundation Registry Lock Extension als aktive Nicht-RFC-Spezifikation für .se und .nu. Dieser Eintrag belegt eine bestehende Betreibererweiterung. Er belegt nicht, dass der neue individuelle Entwurf standardisiert wäre.

Internetstiftelsen erklärt öffentlich, der Registrar entscheide selbst, wie er den Domaininhaber verifiziert. Der Registrar entsperrt die Domain, nimmt die gewünschte Änderung vor und sperrt sie entweder sofort oder nach einer vom Registrar festgelegten Zeit erneut. Wichtige Fragen zu Prüfung und zeitlicher Exposition liegen damit beim Registrar.

DENIC beschreibt für .de eine andere Zeremonie. Der Inhaber benennt einen Lock-Kontakt. Geht über den Provider eine Änderung ein, sendet DENIC ein Token an die hinterlegte Mobilnummer und eine E-Mail an die registrierte Adresse. Ohne Bestätigung innerhalb von sieben Kalendertagen wird die Anfrage abgewiesen. Anträge auf Einrichtung, Änderung oder Entfernung des Locks sowie Änderungen an gesperrten Domaindaten prüft DENIC zusätzlich.

Beide Beschreibungen sind keine Implementierungsnachweise für Revision 00. Ihr Wert liegt im Vergleich. Hinter demselben Begriff Registry Lock stehen verschiedene Verfahren für Registrierung, Prüfung, Fristen, Entsperren und erneutes Sperren. Gemeinsame EPP-Syntax beseitigt diese Unterschiede nicht. Sie erhöht den Bedarf, sie offenzulegen.

Ein Protokoll der Freigabezeremonie bewahren

Ich schlage für jede ausstehende Registry-Lock-Transformation ein Protokoll der Freigabezeremonie vor. Das ist Daniel Kades Governance-Empfehlung, kein vom Entwurf verlangtes Datenmodell.

Das Protokoll beginnt mit der beantragten Änderung: Domain, betreuender Client, authentifizierte EPP-Sitzung, clTRID, svTRID, Zeitpunkt, Operation sowie eine kanonische Darstellung des Vorher- und Nachher-Zustands. Es hält die zuvor geltende Lock-Policy, Frist, Zahl nötiger Freigaben, Kontaktmenge und Policy-Version fest. Eine spätere Änderung darf diesen Ausgangspunkt nicht umschreiben.

Für jeden erforderlichen Zustimmer benennt es vertretene Autorität, Kontakt-ID, Registrierungszeit, Methode und die für Unabhängigkeit wichtigen Kontrolldomänen: Arbeitgeber oder wirtschaftlich Berechtigter, Identitätsanbieter, Mail-Tenant, Geräteverwaltung, Telefonkonto, Token-Herausgeber und Recovery-Stelle. Sensible Werte können als kontrollierte Referenzen oder stabile Pseudonyme erscheinen, ohne öffentlich offengelegt zu werden.

Die Challenge verbindet einen Nonce oder Digest mit der exakten Änderung, dem Zustellendpunkt, Ausgabe- und Ablaufzeit, Antwortzeit, Prüfergebnis und Replay-Zustand. Keine Antwort, ausdrückliche Ablehnung und gescheiterte Prüfung bleiben unterscheidbar. Die Endentscheidung nennt die geprüfte Unabhängigkeitsregel, gezählte und ausgeschlossene Freigaben, Ausnahme oder manuellen Eingriff und die Person, die eine Abweichung genehmigte.

Der Abschluss verbindet die ursprüngliche ausstehende Transaktion mit Poll-Nachricht, EPP-Endergebnis, angewandtem Zustand und Benachrichtigungen. Umgeht DNSSEC-Automatisierung die Freigabe, stehen Automationsidentität, Beobachtung und Policy im Datensatz. Wird der Lock außerhalb von EPP entfernt, gehört die Kennung dieser externen Zeremonie in dieselbe Chronologie.

Das soll kein öffentliches Dossier geschützter Domains werden. Es ist ein dauerhaftes, zugriffsgeschütztes Konto, mit dem Inhaber, Registrar und Registry mehr beweisen können als die Zahl einiger Kontakt-IDs. Das Quorum beantwortet, wie viele Freigaben der Server gezählt hat. Das Zeremonieprotokoll beantwortet, ob sie jene unabhängige Autorität verkörperten, die das Sicherheitsversprechen behauptet.

Quellen