Zusammenfassung

  • Eine eingefrorene Kopie des offiziellen öffentlichen AFRINIC-WHOIS-Dumps enthält 28.206 mntner-Objekte; 1.345 davon tragen mindestens ein MD5-PW- oder CRYPT-PW-Label.
  • 1.285 Objekte enthalten ausschließlich veraltete Methoden. Weitere 60 verbinden eine davon mit BCRYPT-PW, PGP oder X.509.
  • Gezählt werden gespeicherte Labels, nicht 1.345 gültige Zugangsdaten, Mitglieder, Organisationen, erfolgreiche Updates oder nachgewiesene Schwachstellen.
  • Die gegenwärtigen offiziellen Texte legen nicht operationsgenau fest, ob die Altmethoden wirkungslos, nur zur Migration oder noch für breitere Änderungen nutzbar sind.
  • Ein datensparsamer Fähigkeits- und Migrationsnachweis kann diese Grenze mit registry-eigenen Testobjekten belegen, ohne Identitäten oder Geheimnisse offenzulegen.

Die Zahl beginnt beim Objekt, nicht beim Konto

Am 5. September 2026 um 17:42 UTC wurde der offizielle öffentliche Datenbank-Dump von AFRINIC eingefroren. Die komprimierte Datei war 10.448.358 Byte groß. Nach dem Entpacken zählte die Auswertung 28.206 mntner-Objekte und 28.380 auth:-Zeilen. Sie übernahm lediglich die Methodenklasse; Namen, Kontakte, Schlüsselkennungen und Passwort-Hashes wurden weder ausgegeben noch in die Analyseartefakte aufgenommen.

In 1.345 Objekten, also 4,7685 Prozent, kam MD5-PW oder CRYPT-PW vor. 1.285 von ihnen enthielten weder BCRYPT-PW noch PGP oder X.509. Genau 60 kombinierten eine veraltete mit mindestens einer nicht veralteten Methode. Die 60 sind wichtig, weil eine frühe Exploration zunächst 100 ausgab. Jene 100 umfassten jedoch alle Mehrfachkombinationen starker beziehungsweise nicht veralteter Methoden. Sie sind kein Ergebnis für die gemischte Alt-neu-Gruppe.

Auch die Verteilung des großen Rests gehört zum Befund. 26.921 Objekte besitzen mindestens eine nicht veraltete Methode; 26.861 zeigen ausschließlich solche Methoden. BCRYPT-PW allein steht in 26.748 Objekten. PGP oder X.509 kommen in 172 vor. Das Bild ist daher nicht eine von MD5 dominierte Datenbank, sondern eine weit fortgeschrittene Umstellung mit einem Rest von knapp fünf Prozent.

Ein mntner ist weder ein Mitglied noch zwangsläufig eine Organisation. Ein Betreiber kann mehrere Maintainer führen; ein Maintainer kann zahlreiche Objekte schützen. Aus dem Label folgt weder, dass jemand das Geheimnis kennt, noch dass ein Schlüssel verfügbar ist oder jemals ein Update angenommen wurde. Der Nenner ist eine Menge öffentlich verteilter Datenbankobjekte.

Gleichwohl ist der Eintrag relevant. Er beschreibt den vorgesehenen Autorisierungspfad für geschützte WHOIS-Objekte. Hat die Implementierung diesen Pfad geändert, ohne dass der gespeicherte Zustand nachgezogen wurde, kann ein Leser die praktische Kontrollfläche nicht mehr aus dem Objekt ableiten. Das Label kann Historie, Arbeitsvorrat, Migrationsausgang oder echte Alternative bedeuten.

„Noch nutzbar“ braucht eine Operation

Die aktuelle AFRINIC-Seite zum Datenschutz in WHOIS nennt CRYPT-PW und MD5-PW veraltet. Sie sagt, dass beide Methoden in neuen Objekten oder künftigen Updates nicht verwendet werden dürfen, und empfiehlt den Wechsel zu BCRYPT-PW. Zugleich erklärt sie, bestehende, auf diese Weise geschützte Objekte könnten die Methoden „vorerst“ weiterhin zur Authentifizierung verwenden. Die aktuelle Seite zu WHOIS-Werkzeugen wiederholt diese Übergangsaussage.

Der Text sagt nicht, für welche Handlung die Authentifizierung gilt. Ein neues mntner-Objekt anzulegen, die eigene auth:-Zeile zu ersetzen und ein anderes geschütztes Objekt zu verändern sind getrennte Fähigkeiten. Web, Mail, API und ein unterstützter Wiederherstellungsweg können ebenfalls unterschiedliche Regeln besitzen. Ohne Operation und Kanal wird aus einem möglicherweise engen Ausgang ein allgemeines Versprechen.

Hinzu kommt die dokumentierte Verknüpfung mehrerer Methoden. Stimmen bei einem Maintainer mehrere auth:-Attribute, reicht laut AFRINIC die Erfüllung eines davon. Es gilt ein logisches ODER. Eine neue starke Zeile beseitigt daher eine alte Zeile nicht automatisch. Bei den 60 gemischten Objekten ist entscheidend, ob der alte Zweig ausführbar bleibt. Bei den 1.285 ausschließlich veralteten Objekten entsteht das umgekehrte Problem, falls er vollständig gesperrt ist: Wie kann ein rechtmäßiger Verwalter die Authentifizierung noch ersetzen?

Eine offizielle Mitteilung vom 2. Juli 2021 formulierte die Abschaltung entschiedener. Nach einem Vorfall mit massenhafter WHOIS-Datenextraktion berichtete AFRINIC, die Whois-Engine sei aktualisiert worden und schwache Authentifizierungsmechanismen würden nicht mehr unterstützt. Der gegenwärtige IRR-Leitfaden nennt in seinem Ablauf für Route-Objekte BCRYPT-PW und PGP. Dieser Ablauf ist ein nützlicher Beleg für seinen eigenen Kontext, aber keine vollständige Matrix für alle Whois-Operationen.

Die Aussagen können nebeneinander richtig sein. Die Mitteilung von 2021 könnte die Neuanlage schwacher Geheimnisse meinen. „Vorerst“ könnte ausschließlich einen Weg zur Selbstmigration bezeichnen. Das Update-Verbot könnte sich auf das Ändern des Maintainers beziehen, nicht auf jedes von ihm geschützte Objekt. Doch die öffentliche Dokumentation wählt keine dieser Lesarten und bindet sie an keine laufende Version.

Auch ein HTTP-Last-Modified-Header löst das Problem nicht. Er datiert Servermetadaten der erfassten Antwort, nicht verlässlich die redaktionelle Prüfung des Satzes oder die Deploymenteinheit, für die er gilt. Dokumentation und laufender Code bleiben verschiedene Evidenzobjekte.

Kontinuität ist ein ernstes Gegenargument

Ein erzwungener Schnitt kann legitime Kontrolle zerstören. Organisationen wechseln Personal, verlieren alte Schlüssel, geben Rollenpostfächer auf oder entdecken bei einer Rotation, dass die damalige Autoritätskette nicht mehr vollständig ist. Wird der letzte Weg vor einer Ersatzprüfung entfernt, kann der Inhaber seinen eigenen Datensatz nicht mehr korrigieren. Kryptografische Ordnung wird dann mit schlechterer Registry-Genauigkeit bezahlt.

Ein eng begrenzter Migrationsweg ist deshalb plausibel. Die alte Methode könnte nur noch ihren eigenen Ersatz freigeben. Ein Supportverfahren könnte zusätzliche Dokumente verlangen. Das Label könnte im Objekt bleiben, während die Engine es verweigert, damit der verbleibende Arbeitsbestand messbar bleibt. Oder der technische Weg könnte vollständig geschlossen sein, wobei nur eine administrative Wiederherstellung übrig bleibt.

Jede Variante balanciert Schutz, Verfügbarkeit und Nachvollziehbarkeit anders. Der Dump beweist keine davon. Die stärkste Verteidigung für AFRINIC lautet deshalb nicht, dass alte Passwörter weiterhin funktionieren müssten, sondern dass ein Übergang legitime Inhaber nicht aussperren darf.

Diese Verteidigung braucht jedoch eine überprüfbare Grenze. Welche Operation bleibt möglich? Über welchen Kanal? Unter welchem Whois-Release? Mit welcher Zusatzprüfung? Wer besitzt den Migrationsfall und wann endet die Ausnahme? „Vorerst“ ist ohne diese Felder kein kontrollierter Zustand.

Drei Zustände verlangen drei Reaktionen

Sind MD5-PW und CRYPT-PW vollständig wirkungslos, messen die 1.345 Objekte eine Darstellungs- und Abschlusslast. Dann sollten irreführende Zeilen sicher entfernt, Fälle ohne Alternative wiederhergestellt und sinkende Gesamtzahlen veröffentlicht werden. Eine Schwachstellenzahl wäre das nicht.

Sind die Methoden nur für die Migration aktiv, bilden sie eine Schleuse. Der zulässige Selbstwechsel, der Kanal, die zusätzliche Identitätsprüfung und die Endbedingung müssen dokumentiert werden. Ein enger Ausnahmeweg ist vertretbar, sofern nachweisbar ist, dass er sich nicht auf andere Änderungen erstreckt.

Sind breitere Updates weiter möglich, wird das ODER zur Sicherheitsfrage. In den 60 gemischten Objekten hebt eine neue Methode den alten Zweig nicht auf. Bei den 1.285 ausschließlich alten Objekten müssen stärkere Absicherung und Wiederherstellung koordiniert werden, damit die Abstellung nicht zum Kontrollverlust führt.

Das eingefrorene Material entscheidet nicht zwischen diesen Szenarien. Ein Datenbank-Dump zeigt gespeicherten Zustand; eine Hilfeseite beschreibt Semantik; keines von beiden ist ein Ergebnis für eine benannte Operation. Aus Szenario drei eine Tatsache zu machen wäre eine unbelegte Schwachstellenbehauptung. Szenario eins ohne Laufzeitbeleg festzuschreiben wäre derselbe Fehler in die andere Richtung.

Ein Nachweis ohne Mitgliederdaten

AFRINIC kann eigene Canary-Objekte verwenden. Pro Methodenklasse werden mindestens drei Vorgänge getrennt: mntner anlegen, dessen Authentifizierung ersetzen und ein anderes geschütztes Objekt ändern. Veröffentlicht werden Annahme oder Ablehnungsklasse, Kanal, Zeitpunkt und eingesetzte Whois-Version. Geheimnis, Testobjektname und verwertbare Angriffseinzelheiten bleiben intern.

Die kleinste brauchbare Zeile lautet somit: Speicherzustand, Operation, Kanal, Version, Ergebnis. Weichen Web, Mail oder API voneinander ab, ist die Abweichung Teil des Betriebsvertrags. Nach einer Änderung der Authentifizierungslogik werden die Canaries erneut ausgeführt und der alte Nachweis ausdrücklich ersetzt.

Daneben steht eine aggregierte Migrationsreihe. Der Ausgangspunkt dieser Aufnahme lautet 1.285 nur veraltet, 60 gemischt und 26.861 nur nicht veraltet. Jeder spätere Punkt trägt Zeit, Dump-Hash und Korrekturfolge. Eine Bestandsänderung bleibt so eine Aussage über gespeicherte Daten und wird nicht ungeprüft als Verringerung wirksamer Risiken ausgegeben.

Der institutionelle Teil nennt Migrationsverantwortung, Supportweg, Zielzustand sowie End- oder Prüftermin. Auch Statistikfehler werden nicht überschrieben, sondern mit altem Wert, Ursache und Ersatz erhalten. Die Erklärung von 2021 und die heutige Seite werden dadurch Stationen einer zeitlichen Folge, nicht zwei konkurrierende Gegenwarten.

Der Nachweis muss bewusst klein bleiben. Er bestätigt weder Ressourcenrechte noch Kontaktwahrheit oder die Rechtmäßigkeit eines konkreten Updates. Er bestätigt nur, welche operationale Fähigkeit heute zu einer gespeicherten Methodenklasse gehört.

Was aus den Daten nicht folgt

Es ist kein erfolgreicher Login, kein Updateversuch, keine bekannte Zugangsinformation und keine Ausnutzung nachgewiesen. Die Auswertung sagt auch nicht, warum ein einzelnes Objekt seine Zeile behält. Namen, Hashes oder Schlüsselkennungen zu veröffentlichen würde diese Erkenntnis nicht stärken, aber die Angriffsfläche vergrößern.

Der Befund ist ebenso wenig eine Gesamtbewertung von AFRINICs IRR, Routingdaten, Kontakten, Governance oder institutioneller Sicherheit. Veraltete Route-Objekte, rekursive Sets, Spiegelung und Ressourcenstreitigkeiten benötigen eigene Belege. Eine Sammelkategorie „Fragilität“ würde die hier reparierbare Entscheidung verdecken.

Die belastbare Aussage ist enger: Der öffentliche Datensatz zeigt Methodenlabels. Offizielle Texte beschreiben Rückzug und vorübergehende Nutzung. Der laufende Code entscheidet über die Handlung. Ein versionierter, aggregierter und datensparsamer Nachweis kann alle drei verbinden, ohne ein Objekt eines Mitglieds anzutasten.

Quellen

  1. AFRINIC, Datenschutz in der WHOIS-Datenbank
  2. AFRINIC, WHOIS-Werkzeuge
  3. AFRINIC-Ankündigungsliste, Update zum Vorfall der WHOIS-Massenextraktion vom 2. Juli 2021
  4. AFRINIC, Leitfaden zum Internet Routing Registry
  5. Offizieller öffentlicher AFRINIC-WHOIS-Datenbank-Dump