Zusammenfassung

  • clientTransferProhibited und serverTransferProhibited haben nach RFC 5731 eine starke, eng begrenzte Wirkung: Transferanträge für das Domainobjekt müssen abgewiesen werden.
  • Das Präfix zeigt die kontrollierende Seite, nicht den politischen oder vertraglichen Grund, die menschliche Autorisierung, den Prüftermin oder die Sicherheit des Freigabewegs.
  • Eine belastbare Transferentscheidung verbindet einen zeitgebundenen Statusbeleg mit einem eigenen Entscheidungsbeleg; Konto-, Update-, Lösch-, Verlängerungs- und DNS-Kontrollen benötigen separate Nachweise.

Ein klares Nein ohne Begründung

Die Transfersperre ist kein bloßer Hinweis. RFC 5731 verlangt, dass der Server bei einem der beiden Transferverbote den Antrag ablehnt. Wer einen kohärenten Serverstatus beobachtet, weiß damit etwas Wichtiges über ein bestimmtes Kommando zu diesem Zeitpunkt.

Der Fehler entsteht erst bei der Erweiterung dieser Aussage. Eine Oberfläche macht daraus „vom Inhaber geschützt“, „Betrug erkannt“, „Registry Lock“ oder pauschal „sicher“. Nichts davon steht im Token. Das Protokoll beschreibt die Behandlung eines Transferkommandos, nicht die Entstehungsgeschichte der Entscheidung.

RFC 5731 erlaubt einen menschenlesbaren Begleittext zur Begründung des Status, schreibt ihn aber nicht vor. Ein konformes Objekt kann ohne Fallnummer, Inhaberweisung, Ablaufdatum oder aktuelle Prüfung auskommen. Das schwächt die Ablehnung nicht. Es zeigt, dass die Erklärung aus einem anderen Datensatz stammen muss.

Diese Beschränkung ist für Interoperabilität wertvoll. Ein enger Prädikatswert lässt sich zwischen Systemen vergleichen. Würde ein Code zugleich Einwilligung, Identität, Vertrag und Streitgeschichte tragen, wäre seine Bedeutung von unsichtbaren lokalen Regeln abhängig.

Das Präfix bezeichnet die Kontrollseite

Ein mit client beginnender Status wird vom sponsernden Client gesetzt oder entfernt, in der Registry-Registrar-Beziehung üblicherweise vom Registrar. Ein server-Status wird vom EPP-Server, gewöhnlich der Registry, verwaltet. Der Client darf einen serverseitigen Status nicht ändern; der Server kann einen clientseitigen Status nach lokaler Serverpolitik ändern oder übersteuern.

Damit ist die technische Tür benannt, nicht die Person oder Regel, die sie betätigt hat. Ein Registrar kann bei Registrierung automatisch sperren, einem Wunsch des Inhabers folgen, eine befristete Richtlinie abbilden oder auf ein Kontoproblem reagieren. Eine Registry kann wegen eines Streits, einer Redemption-Phase, eines beauftragten Dienstes oder einer anderen lokalen Voraussetzung sperren. Derselbe sichtbare Code kann also verschiedene Entscheidungen projizieren.

ICANNs Erklärung für Registranten übersetzt diese Trennung in einen Handlungsweg. Client-Codes setzt der Registrar, Server-Codes die Registry. Für die Aufhebung des ersten wendet sich der Inhaber an den Registrar. Beim zweiten muss der Registrar womöglich die Registry einschalten, was länger dauern kann. Das findet die zuständige Stelle, aber noch nicht den Grund.

Die Richtlinie besitzt den fehlenden Satzteil

In ihrem Geltungsbereich liefert die aktuelle ICANN Transfer Policy die Entscheidungsebene, die RFC 5731 nicht kodieren soll. Sie unterscheidet die Autorität des registrierten Namensinhabers, den Antrag des übernehmenden Registrars, die Pflichten des bisherigen Registrars sowie zulässige Ablehnungsgründe und Mitteilungen.

Diese Gründe sind nicht austauschbar. Betrugsbelege unterscheiden sich von einem begründeten Streit über die Identität des Inhabers. Ein genau definierter Zahlungsrückstand ist keine ausdrückliche Einwendung. Gerichtliche oder sonstige Streitverfahren, Fristen nach Registrierung oder Transfer und die 60-Tage-Sperre nach einem Inhaberwechsel besitzen jeweils eigene Grundlage und Laufzeit.

Die Richtlinie macht zudem deutlich, dass „Registrar Lock“ für sich keine ausreichende Erklärung ist. Wenn dem Inhaber vor dem Antrag keine angemessene Möglichkeit und Fähigkeit zur Entsperrung gegeben wurde, darf die Sperre nicht allein die Ablehnung tragen. Bei einer allgemeinen ausdrücklichen Einwendung gehören informierte Zustimmung und ein zugänglicher Aufhebungsweg zur Entscheidung.

Daher sind zwei Belege nötig. Der Statusbeleg enthält Domain, exakten Wert, Quelle, Beobachtungszeit und späteren Folgestatus. Der Entscheidungsbeleg enthält Richtlinien- oder Vertragsfassung, Antragsteller, verantwortliche Rolle, Autorisierungsnachweis, Beginn, Ablauf oder Prüfauslöser, Benachrichtigung und Freigabeverfahren.

Drei Uhren hinter einem grünen Symbol

Die Serveruhr datiert, wann die Sperre in den maßgeblichen EPP-Zustand gelangt ist. Die Richtlinienuhr bestimmt, wann der Grund wirksam wurde und wann Prüfung oder Ablauf anstehen. Die Beobachtungsuhr vermerkt nur, wann RDAP, Whois, ein Registrar-Portal oder ein Monitoringdienst den Zustand abgerufen und dargestellt hat.

Öffentliche Antworten können zwischengespeichert sein. Ein Portal kann sein freundliches Etikett nach einer internen Änderung behalten. Eine Entscheidungsgrundlage kann ablaufen, bevor der technische Status entfernt wird; umgekehrt kann der Server freigeben, bevor ein Aggregator aktualisiert. Ein Screenshot beweist eine Darstellung zu einem Zeitpunkt, nicht automatisch den aktuellen maßgeblichen Wert, den Setzer oder den Grund.

RFC 5731 bietet dafür einen nützlichen Konsistenztest: pendingTransfer darf mit keinem Transferverbot kombiniert werden. Pending bedeutet, dass eine Transferaktion verarbeitet, aber noch nicht abgeschlossen ist; das Verbot verlangt die Ablehnung des Antrags. Zeigt ein Datensatz beides, sind zunächst Zeitversatz, Cachealter, vermischte Quellen und Darstellung zu prüfen. Der Widerspruch verlangt Rekonstruktion, ist aber allein noch kein Beweis für Betrug oder Serververstoß.

„Gesperrt“ betrifft nicht jedes Verb

Im Alltag klingt eine Sperre allumfassend. EPP unterscheidet Transfer, Update, Löschung und Verlängerung mit eigenen Verboten; hold wirkt auf die Veröffentlichung der DNS-Delegation. Eine Transfersperre belegt weder unveränderliche Kontaktdaten noch Löschschutz oder ein sicheres Registrar-Konto.

Nach einer Kontoübernahme kann ein Angreifer versuchen, einen Client-Status zu entfernen. Umgekehrt kann ein kommerzieller Registry-Lock-Dienst Rückruf, unabhängige Zugangsdaten, zwei Freigaben oder eine Wartezeit verlangen. Solche Kontrollen sind wertvoll, wenn Vertrag und Betrieb sie belegen. Der ähnlich klingende EPP-Status garantiert sie nicht.

ICANN beschreibt den Transfer Lock in seinen Sicherheitshinweisen als zusätzliche, nicht ausfallsichere Schutzschicht. Kontoinformationen und mehrstufige Authentisierung werden gesondert behandelt. Eine vollständige Bewertung bewahrt deshalb getrennte Nachweise für Zugang, Berechtigungsänderung, authInfo, Update und Löschung, DNS, Verlängerung und Wiederherstellung.

Auch Hollenbecks Zuschreibung bleibt begrenzt

Scott Hollenbeck ist der genannte Autor von RFC 5730 und RFC 5731. Sein öffentliches IETF-Profil berichtet von aktiver Teilnahme seit Mitte der 1990er Jahre, mehreren Arbeitsgruppenvorsitzen und seiner Tätigkeit als Applications Area Director von 2004 bis 2006. Der aktuelle Stand listet 39 RFCs.

Das belegt einen umfangreichen Standardisierungsbeitrag. Es macht Hollenbeck nicht zum Registry-Betreiber, zum Urheber eines einzelnen Sperrgrundes oder zum Verwalter einer bestimmten Domain. Sein Name gehört zur Provenienz der Spezifikation. Registrar oder Registry gehören zur Provenienz der Statusänderung. Präzision schützt Beitrag und Verantwortlichkeit zugleich.

Ein prüfbares Dossier ohne unnötige Geheimnisse

Der technische Teil hält exakten Status, Quelle, Zeit, Folgezustand und verfügbare Abfrage- oder Transaktionskennungen fest. Getrennt, aber verknüpft, folgen Politikversion, Antragsteller, verantwortliche Funktion, Autorisierungsbeleg, Laufzeit, Prüfung, Mitteilung, Ausnahme und Aufhebungsweg. Bei einem tatsächlichen Transferantrag kommen Antragszeit, Autorisierungsbehandlung, Serverantwort, etwaiger Pending-Status, mitgeteilter Ablehnungsgrund und Ausgang hinzu.

Passwörter, Autorisierungscodes und unnötige personenbezogene Daten gehören nicht in die öffentliche Akte. Die Herkunftskette, mit der berechtigte Prüfer Schutzmaßnahme, Fehler, Streit und Übernahme unterscheiden können, muss jedoch erhalten bleiben.

Der stärkste Einwand stimmt: Das Transferverbot schützt wirklich. In einem konformen Zustand stoppt es den Antrag. Standardmäßige Registrar-Sperren und sorgfältige Registry-Lock-Dienste erhöhen die Hürde für Domain-Hijacking. Falsch ist nicht das Vertrauen ins Protokoll, sondern die Erwartung, es erkläre eine Entscheidung außerhalb seines Feldes.

Hollenbecks Mapping liefert einen kurzen, verbindlichen Satz: Dieses Kommando ist abzulehnen. Die Institution muss ergänzen, wer entschied, auf welcher Grundlage, bis wann und über welchen Ausgang. Die Sperre verhindert den Transfer; zurechenbare Evidenz erklärt ihren Grund.

Quellen