Zusammenfassung

  • In ICANNs Vertragssprache prüft „validation“ das Datenformat; „verification“ holt eine bestätigende Reaktion eines Kontakts ein. Keines der Verfahren stellt allein die rechtliche Identität fest oder entscheidet Rechte an einer Domain.
  • Ein belastbares Beweismodell trennt vier Fragen: Ist der Datensatz verarbeitbar, ist der Kontakt erreichbar, wer kann das Konto bedienen und wer ist rechtlich befugt? Beweis, Entscheider und Abhilfe wechseln von Ebene zu Ebene.

Wenn „verifiziert“ zu viel verspricht

Ein RDAP- oder Whois-Datensatz wirkt amtlich: Er ist strukturiert, zeitlich erfasst und kommt aus Systemen, die den Betriebszustand einer Domain ändern können. Daraus entsteht ein bequemer Kurzschluss. Wurde die E-Mail des Inhabers „verifiziert“, müsse auch die genannte Person identifiziert und ihr Recht bewiesen sein.

ICANNs Instrumente tragen diesen Schluss nicht. Die geltende Fassung des Registrar Accreditation Agreement enthält weiterhin die RDDS Accuracy Program Specification. Bei Registrierung, eingehendem Transfer oder Inhaberwechsel muss der Registrar innerhalb bestimmter Fristen prüfen, ob Pflichtangaben vorhanden und richtig formatiert sind. E-Mail, Telefon und Postanschrift unterliegen jeweils strukturellen Anforderungen.

In einem getrennten Schritt kontaktiert der Registrar den Registered Name Holder oder Account Holder und verlangt eine bestätigende Antwort. Bleibt sie aus, folgt eine manuelle Prüfung oder, soweit vorgesehen, eine Sperre bis zum Abschluss.

Das ICANN-Advisory von 2015 zieht die Linie ausdrücklich: „Validation“ bestätigt ein normgerechtes Format. „Verification“ bedeutet, einen Kontakt zu erreichen und eine Antwort zu erhalten. Ein bloßer Formatfehler kann korrigiert werden, ohne den Inhaber erneut anzuschreiben. Das sind Vertragspflichten, kein umfassender Identitätsnachweis.

Damit ergeben sich zwei erste Ebenen:

  1. Formale Gültigkeit. Lässt sich der Wert nach der einschlägigen Regel verarbeiten? Ein positives Ergebnis sagt nicht, ob der Kanal existiert oder der genannten Person gehört.
  2. Erreichbarkeit. Hat jemand mit Zugriff auf E-Mail oder Telefon reagiert? Das verbindet einen aktiven Kanal zu einem Zeitpunkt mit der Registrierung. Es schließt Stellvertreter, Gemeinschaftskonten, gestohlene Zugangsdaten oder falsche Namen nicht aus.

Kontokontrolle ist die dritte Frage

Anmeldeprotokolle, Mehrfaktorereignisse, Zahlungen, Transferfreigaben, Änderungshistorie und Supportkontakte können zeigen, wer dem Registrar Anweisungen gab. Bei einem Domain-Hijacking erklären sie den Ablauf oft besser als die öffentliche Anzeige.

Doch Bedienungsmacht ist kein Anspruch. Ein ausgeschiedener Mitarbeiter kann Zugangsdaten behalten. Ein Beauftragter darf verwalten, ohne wirtschaftlich berechtigt zu sein. Ein Angreifer kann das Konto kurzzeitig übernehmen. Ein Privacy- oder Proxy-Dienst kann im veröffentlichten Feld stehen und die Kundendaten getrennt halten. Kontrollbeweise erklären den Mechanismus einer Änderung; sie dürfen nicht automatisch entscheiden, wem der Name zusteht.

Die seit 21. August 2025 verbindliche Registration Data Policy wahrt diese Grenze. Sie regelt Erhebung, Übermittlung, Escrow, Veröffentlichung, Schwärzung, Offenlegung und Aufbewahrung, einschließlich des Feldes „Registrant Organization“ und rechtmäßiger Offenlegungsersuchen. Sie macht den Datenlebenszyklus nachvollziehbarer. Sie macht ICANN, Registry oder Registrar aber nicht zum Gericht für wirtschaftliches Eigentum, Vertretungsmacht, Nachfolge, Betrug oder Vertragsrechte.

Rechtliche Identität gehört in ein viertes Verfahren

Der bessere Anspruch kann von Handelsregisterunterlagen, Vollmachten, Arbeitsverträgen, Kaufverträgen, Gerichtsentscheidungen, Schiedssprüchen, Erbunterlagen oder Betrugsnachweisen abhängen. Dafür können Zwang zur Vorlage und ein kontradiktorisches Verfahren nötig sein. Eine beantwortete E-Mail ist dafür nicht gebaut.

ICANN Contractual Compliance kann prüfen, ob ein Registrar den Vertrag eingehalten, eine Ungenauigkeitsbeschwerde untersucht und die verlangte Korrektur oder Sperre umgesetzt hat. In einer Board-Entscheidung vom März 2026 beschreibt der öffentliche Vorgang eine Untersuchung, nach der die Sperre der Domain mit RAA und Accuracy Specification vereinbar war. Das ist eine Aussage über Vertragsbefolgung, nicht die gerichtliche Zuweisung der Domain an Antwortenden, Beschwerdeführer oder angezeigten Namen.

Auch die Abhilfe muss zur Ebene passen: Formatfehler werden korrigiert. Bei einem nicht erreichbaren Kontaktkanal wird erneut geprüft oder die Domain nach den Vertragsregeln gesperrt. Ein kompromittiertes Konto erfordert Eindämmung, Wiederherstellung und Sicherung der Protokolle. Ein Rechtsstreit geht zum zuständigen Streitverfahren, Gericht oder Entscheidungsträger. Wer die Ebenen vermischt, kann die Domain an die falsche Partei übertragen oder Beweise vernichten.

Was die Audit-Zahlen wirklich messen

Der Bericht vom Oktober 2023 fasst Audits von 2016 bis 2022 zusammen: 80 Registrare mit rund 127,8 Millionen vertretenen Domains. Zehn hatten keinen Validierungsprozess für Kontaktdaten, sechs mangelhafte Methoden, vier Mängel bei der Aufbewahrung und einer einen mangelhaften Verification-Prozess.

Diese Werte sind kein Anteil von Domains mit „falschem Eigentümer“. Geprüft wurden Registrar-Kontrollen; die Domainzahlen zeigen deren Größenordnung. Die wirtschaftliche Identität jeder Registrierung wurde nicht entschieden, und „potenziell betroffen“ bedeutet nicht, dass jeder Datensatz falsch war. Die engere, belastbare Folgerung lautet: Prozessgestaltung, Beweissicherung und Nachweisbarkeit der Prüfung sind skalierbare Governance-Risiken.

Auch die Politikdebatte anerkennt die Messgrenze. ICANN erklärte 2023, die untersuchten Szenarien würden voraussichtlich keine Daten zur Identitätsprüfung oder dazu liefern, ob Kontaktdaten tatsächlich der betroffenen Person gehören. Das Accuracy Small Team des GNSO Council empfahl 2025, den bestehenden Prozess und Folgen möglicher Änderungen zu untersuchen.

Eine Studie zu weniger böswilligen Registrierungen nach frühen Kontaktchecks war dafür ein Signal, kein Identitätsbeweis. Im März 2026 arbeitete der Council weiter an Informationsmaterial; ein Teilnehmer betonte, Hinweise könnten einen Täter nicht daran hindern, Müllangaben zu machen und anschließend Missbrauch zu begehen.

Vier Spalten für jede Beweisbehauptung

Festzuhalten sind getrennt: Feld und Formatregel; getesteter Kanal und Antwort; Authentifizierungs- und Änderungsdaten zur Kontonutzung; Vertrag, Vollmacht oder Entscheidung als Rechtsgrund. Die Spalten können sich stützen, aber nicht ersetzen. Ein erreichbares Postfach beweist eine Reaktion, keinen Eigentumstitel.

Quellen