Zusammenfassung

  • Der erste Bericht des PDP 1 sieht einen Associated Domain Check vor, sobald ein Registrar belastbare Hinweise auf definierten DNS-Missbrauch einer nicht kompromittierten Domain hat. Der Bericht steht zur Kommentierung; er ist keine geltende Policy.
  • Empfehlung 8 verlangt nachweisbare Erfüllung, lässt ihre sechs Belegarten aber optional und verbietet ein einheitliches Format. Eine geschützte gemeinsame Zustandsgrammatik würde lokale Ermittlungen bewahren und spätere Prüfung vergleichbar machen.

Ein Registrar kann einen gemeldeten Phishing-Namen sperren und trotzdem die übrige Kampagne unangetastet lassen. Der am 18. August veröffentlichte Erstbericht der GNSO-Arbeitsgruppe will deshalb nach dem ersten belegten Namen eine zweite Pflicht auslösen.

Wenn die Empfehlungen alle späteren Stufen durchlaufen, muss der Registrar einen Associated Domain Check, kurz ADC, durchführen. Voraussetzung ist actionable evidence, dass eine registrierte Domain für die im RAA definierten Missbrauchsarten genutzt wird. Erst danach sucht der Registrar innerhalb seines eigenen Bestands nach vernünftig verbundenen Namen.

Der Entwurf zieht mehrere Grenzen. Er erfasst keine Domain, die ursprünglich rechtmäßig registriert und später ohne Wissen des Inhabers kompromittiert wurde. Er verlangt keine registrarübergreifende Suche und keine routinemäßige Prüfung des ganzen Portfolios. Ein gemeinsamer Nameserver, Reseller oder Privacy-Dienst ist allein kein Beweis gemeinsamer böswilliger Kontrolle.

Auch die Ermittlungslogik bleibt offen. Kontodaten, Inhaberinformationen, Namensmuster, Infrastruktur, abgestimmte Registrierungen, interne Auswertung und externe Hinweise können relevant sein. Benötigt werden nur Informationen, die im normalen Betrieb vernünftig zugänglich sind. Ein Reseller darf Schritte übernehmen; die vertragliche Verantwortung bleibt beim Registrar.

Diese Offenheit schützt vor Scheingenauigkeit. Starre Signale können harmlose Kunden auf geteilter Infrastruktur zusammenziehen. Eine feste Frist kann bei akutem Phishing zu lang und bei einem komplexen Fall mit hohem Kollateralrisiko zu kurz sein. Der Bericht hält daher am kontextabhängigen „promptly“ sowie an Verhältnismäßigkeit und Datenminimierung fest.

Offen bleibt, wie aus unterschiedlichen Ermittlungen eine gemeinsame, auswertbare Verpflichtung wird.

Eigene Akten reichen für einen Fall, nicht automatisch für eine Policy

Die vorläufige Empfehlung 8 verpflichtet Registrare, die Einhaltung mit Unterlagen aus dem normalen Geschäftsbetrieb belegen zu können. Als möglicherweise ausreichend nennt sie Auslöser und Zeitpunkt, Durchführung und Zeitpunkt des ADC, geprüfte Informationen, Zahl festgestellter Verbindungen, anschließende Maßnahmen sowie die Begründung von Angemessenheit und Verhältnismäßigkeit.

Zugleich darf die Policy kein Dokumentationsformat vorschreiben. Jeder Registrar muss eine interne Prozessbeschreibung führen und ICANN auf Anfrage bereitstellen.

Damit ist eine Einzelfallprüfung möglich. Contractual Compliance kann native Protokolle lesen, Unterlagen nachfordern und den Kontext bewerten. Formatfreiheit bedeutet weder Beweisfreiheit noch Unvollziehbarkeit.

Die Schwierigkeit entsteht beim Vergleich. Bei einem Registrar beginnt die Uhr mit Eingang der Meldung, beim anderen mit der Bestätigung des Beweisniveaus. Ein leeres Feld kann null verbundene Domains, rechtlich unzugängliche Daten, einen abgebrochenen Check oder fehlende Dokumentation bedeuten. Überschreibt die spätere Sperrung den Verbindungsbefund, verschmelzen Untersuchung und Abhilfe.

Empfehlung 7 plant zwei Jahre nach Implementierung eine Wirksamkeitsprüfung. ICANN org und das spätere IRT sollen wenige aggregierte Datenpunkte und eine Ausgangslinie festlegen. Der Bericht warnt selbst davor, aus dem gesamten Missbrauchsvolumen direkte Kausalität abzuleiten. Ohne gemeinsame Zustände kann die Auswertung nicht einmal sicher sagen, welchen Mechanismus sie zählt.

Gemeinsamer Empfangsbeleg statt gemeinsamer Suchmaschine

Ein schmaler Nachweis kann zweistufig aufgebaut sein.

Die geschützte Fallakte enthält eine pseudonyme Fallkennung, Policy-Version, Auslöserklasse und -zeit, Status der Kompromittierungs-Ausnahme, Beginn und Ende, Grenze zwischen Registrar und Reseller, geprüfte oder nicht verfügbare Signalklassen, Umfang und Ergebniszahlen, Maßnahme oder Nichtmaßnahme, Datenschutz- und Kollateralschutz, Fingerabdruck des Beweissatzes, verantwortliche Rolle, Überprüfung, Korrektur und Abschluss.

Domains, Inhaber, Hinweisgeber, Erkennungslogik und Schwellenwerte gehören nicht in die Öffentlichkeit. Das gemeinsame Vokabular sagt auch nicht, welches Signal wie zu gewichten ist. Es bindet lediglich Auslöser, Untersuchung, Ergebnis, Maßnahme und spätere Änderung aneinander.

Öffentlich werden nur datenschutzfeste Aggregate: Anteil gültiger Auslöser mit eröffnetem ADC, definierte Abschlussklassen, fehlende rechtmäßig zugängliche Daten, grobe Zeitspannen und Korrekturen. Kleine Zellen müssen unterdrückt werden. Ranglisten ohne Nenner und Fallmix wären irreführend.

Die Detailakte dient Contractual Compliance. Die Aggregate dienen der Zweijahresprüfung. Keine Ebene darf zu einem öffentlichen Anschuldigungsregister oder einer personenbezogenen Datenbank über mehrere Registrare werden.

Der heutige Berichtspfad ist nur eine Grundlage

Seit April 2024 gelten bereits Pflichten zu angemessenen, zeitnahen Maßnahmen gegen gut belegten DNS-Missbrauch. ICANNs Advisory beschreibt die fallbezogene Anforderung von Unterlagen. Monatsberichte aggregieren Beschwerden, Mitteilungen und Abschlussgründe.

Der Bericht für Juni 2026 enthält keine ADC-Ergebnisse, weil die vorgeschlagene Pflicht noch nicht existiert. Er beweist weder Erfolg noch Versagen des neuen Konzepts. Er zeigt nur eine vorhandene öffentliche Oberfläche für spätere, klar definierte Aggregate.

Auch der Erstbericht selbst ändert keinen Vertrag. Die Kommentierung endet am 28. September. Danach folgen Schlussbericht, GNSO Council, mögliche Board-Annahme und Implementierung. Die Full-Consensus-Einstufung der Empfehlung 8 beschreibt den Stand der Arbeitsgruppe, nicht geltendes Recht.

Gerade jetzt lässt sich ein kleines Beweisinterface noch günstig definieren. Sind hunderte Systeme erst mit unterschiedlichen Bedeutungen von „ADC abgeschlossen“ gebaut, kann eine spätere Zuordnung keine nie erfassten Zeiten, Ausschlüsse oder überschriebenen Entscheidungen wiederherstellen.

Verteilte Arbeit braucht lesbare Übergänge

ICANN muss weder Werkzeuge noch Ermittler zentralisieren. Gemeinsam sein müssen nur die Übergänge: welcher Auslöser führte zu welcher Prüfung, welche Prüfung zu welchem Befund, welcher Befund zu welcher Maßnahme und welche Korrektur zu welcher früheren Entscheidung.

So bleibt operative Autonomie erhalten, während die gemeinsame Pflicht zurechenbar wird. Es fehlt keine große Plattform. Es fehlt eine kleine, portable Beweisgrammatik, die auch nach einem System- oder Anbieterwechsel dieselbe Bedeutung behält.

Quellen

  1. ICANN-Public-Comment-Verfahren
  2. ICANN-Ankündigung
  3. Erstbericht des DNSAM PDP 1 vom 18. August 2026
  4. Projektseite DNS Abuse Mitigation PDP 1
  5. Charta des DNS Abuse Mitigation PDP 1
  6. ICANN-Seite zu den globalen Änderungen 2024
  7. ICANN-Advisory zu DNS-Missbrauchspflichten
  8. ICANN-Dashboard zur Durchsetzung im Juni 2026
  9. ICANN-Programm zur Eindämmung von DNS-Missbrauch
  10. Überblick zum GNSO-Policy-Entwicklungsprozess
  11. Aktuelle Verfahren des GNSO Council