Was AFRINIC-Suballokationen unter dem öffentlichen Register hinterlassen

Das Missbrauchsticket sah gewöhnlich aus, bis jeder versuchte, die verantwortliche Partei zu benennen. Ein regionaler ISP hatte Beschwerden über Credential-Stuffing-Traffic von einem kleinen /27 erhalten, das von einem seiner Geschäftskunden genutzt wurde. Der eingetragene Halter des übergeordneten IPv4-Blocks war im AFRINIC-Eintrag sichtbar. Die Ursprungs-AS war im BGP sichtbar. Ein Reseller saß irgendwo in der kommerziellen Kette. Ein Managed-Firewall-Anbieter betrieb das Edge-Gerät.

Der Kunde, dessen Server den Traffic erzeugten, wünschte Privatsphäre, teils weil die Maschinen möglicherweise kompromittiert waren, teils weil er seine Hosting-Vereinbarungen nicht gegenüber Wettbewerbern offenlegen wollte. Der Upstream wollte Rechenschaft. Die Bank, die die Beschwerde einreichte, wollte eine Person, die den Angriff stoppen konnte. Das Register nannte den Halter, nicht den kleinen operativen Nutzer.

Diese Lücke ist Gegenstand der Suballokations-Sichtbarkeit. Das Wort „Suballokation“ hat eine formale Bedeutung in der AFRINIC-Politik: Ein LIR kann Raum an nachgelagerte ISPs zur weiteren Verteilung vergeben, vorbehaltlich Größen-, Dokumentations- und Registrierungsregeln. Das wirtschaftliche Problem ist weiter gefasst als die formale Bezeichnung. Knapper IPv4 wird heute durch Halter, LIRs, nachgelagerte ISPs, Reseller, Hosting-Anbieter, Managed-Service-Anbieter, Cloud-Plattformen, Makler, Leasing-Vereinbarungen, Unternehmenskunden und manchmal weiter delegierte Nutzer genutzt. Ein Teil dieser Nutzung ist legitim und normal.

Ein Teil ist datenschutzsensitiv. Ein Teil ist geschäftlich vertraulich. Ein Teil ist der Ort, an dem Missbrauch, Betrug, Sanktionsprüfungen, Strafverfolgungsanfragen, Geolokalisierungsfehler, Routing-Fehler und Reputationsschäden tatsächlich auftreten.

Der öffentliche Eintrag sieht oft nur die erste Ebene. Das Internet operiert durch viele weitere Ebenen. Ein Präfix kann bei einer Partei registriert, von einer anderen ursprünglich, in Reverse-DNS an eine dritte delegiert, in einem IRR-Objekt gelistet sein, das von einem Maklerkontakt gepflegt wird, durch eine ROA des formalen Halters abgedeckt sein und von Kunden genutzt werden, deren Namen nie in RDAP oder WHOIS erscheinen. Nichts davon ist automatisch verdächtig. Arbeitsteilung ist im Netzwerkbetrieb normal.

Das Problem beginnt, wenn jeder Außenstehende die Kosten tragen muss, den verantwortlichen Betreiber zu ermitteln, nachdem bereits etwas schiefgegangen ist.

AFRINIC ist ein nützlicher Testfall, weil die nachgelagerte Ebene bereits in den Betriebsregeln verankert ist, mit denen Netzwerke leben müssen, während seine jüngste institutionelle Geschichte zeigt, warum Sichtbarkeit unterhalb des Halters wichtig ist. Das African Network Information Centre (AFRINIC) dient Afrika und einem Teil des Indischen Ozeans als regionales Internet-Register. Es verwaltet die Dienste, die Ressourcennutzung in öffentliche Nachweise verwandeln: WHOIS, RDAP, Reverse-DNS, ein Internet Routing Registry und RPKI.

Die relevanten Betriebsregeln verlangen, dass Allokationen, Zuweisungen und Suballokationen in der AFRINIC-Datenbank registriert werden, und dass Registrierungsdaten wie Namen, Blöcke, Kontakte und Status korrekt bleiben. Sie knüpfen auch die Reverse-Delegation an registrierte Zuweisungen oder Suballokationen. Diese Regeln sind nicht ornamental. Sie sind die engen Punkte, an denen die nachgelagerte Betriebsrealität lesbar werden soll.

Der Druck auf diese Punkte ist gestiegen. AFRINIC trat am 13. Januar 2020 in die IPv4 Soft Landing Phase 2 ein, wobei gewöhnliche neue IPv4-Allokationen und -Zuweisungen auf kleine Blöcke beschränkt wurden, einschließlich eines /24-Minimums und /22-Maximums.

Öffentliche Berichterstattung hat Behauptungen über Adressbuch-Manipulationen im Zusammenhang mit ruhendem afrikanischen IPv4-Raum, den hochkarätigen Streit zwischen AFRINIC und Cloud Innovation über Ressourcennutzung und Kommerzialisierung, eine gerichtliche Einfrierung von AFRINIC-Geldern im Jahr 2021, eine Insolvenzverwaltung ab 2023, Vorstands- und Wahlkontinuitätsbrüche, einen annullierten Wahlversuch 2025, spätere Vorstandsrestauration und anhaltende Wiederherstellungsfragen im Jahr 2026 beschrieben. Diese Ereignisse sollten nicht zu einer generischen Governance-Moralgeschichte gemacht werden.

Für die Suballokations-Sichtbarkeit ist ihre Bedeutung enger: Wenn das Register selbst unter Stress steht, verlassen sich Märkte noch stärker auf klare Nachweise darüber, wer knappe Adressen nutzt, wer kontaktiert werden kann und welche Unsicherheit real und nicht nur Gerücht ist.

Die richtige Frage ist nicht, ob jeder Kunde öffentlich genannt werden sollte. Das wäre gefährlich und wirtschaftlich töricht. Die richtige Frage ist, wie viel nachgelagertes Detail sichtbar sein sollte, für wen, mit welchem Sicherheitsgrad und mit welcher Auswirkung auf die Kosten von Routing, Missbrauchsreaktion, Übertragungen, Leasing, öffentlicher Beschaffung und Register-Rechenschaftspflicht. Ein öffentliches Hauptbuch ist keine private Kundenliste. Aber wenn es nur den formalen Halter offenlegt, während der praktische Nutzer drei Verträge entfernt sitzt, überlässt es dem Markt, die Intransparenz zu bepreisen.

Der unsichtbare Kunde ist jetzt die teure Tatsache

Im Überflusszeitalter war ein verborgener nachgelagerter Kunde oft eine Belästigung, kein Preisproblem. Wenn Missbrauch von einem Kundensubnetz kam, konnte der Anbieter es in seinen eigenen Systemen zurückverfolgen. Wenn ein Kontakt veraltet war, stand möglicherweise eine andere Allokation zur Verfügung. Wenn ein kleiner Bereich falsch konfiguriert war, war die Umnumerierung schmerzhaft, aber kein Kapitalereignis. Die IPv4-Knappheit hat diese Arithmetik verändert. Ein kleiner Block kann Hosting-Umsatz, Zahlungsinfrastruktur, Regierungsportale, SaaS-Kunden, VPN-Zugang, Anti-Betrugs-Systeme, Mail-Reputation und Netzwerkkontinuität unterstützen.

Der Kunde hinter der Adresse ist nicht länger ein operatives Detail. Er ist eine Quelle von Risiko, Wert und Haftung.

Intransparenz hat einen messbaren wirtschaftlichen Pfad. Sie erhöht die Suchkosten, weil ein Beschwerdeführer, Upstream, Käufer, Bank, Versicherer oder Ermittler Zeit aufwenden muss, um festzustellen, ob der aufgeführte Halter, die Ursprungs-AS, der Reseller, der Managed-Service-Anbieter oder der Endkunde das Problem beheben kann. Sie erhöht die Irrtumskosten, weil, wenn das verantwortliche /27 nicht schnell identifiziert werden kann, Gegenparteien ein /24, ein /22 oder die gesamte Halterreputation überblocken.

Sie erhöht die Vertragskosten, weil Kunden und Gegenparteien Garantien, Entschädigungen, Treuhand, Notfallkontakte, Servicegutschriften und zusätzliche Sorgfalt verlangen, wenn der öffentliche Eintrag ihnen nicht genug sagt. Sie erhöht die Kapitalkosten, weil ein Kreditgeber oder Käufer Einnahmen abschlägt, die auf Adressen beruhen, deren Betriebsverantwortung nicht unabhängig rekonstruiert werden kann.

Der unsichtbare Kunde verändert auch die Anreize innerhalb der Kette. Ein Halter, der Einnahmen erzielen kann, während der nachgelagerte Nutzer nicht registriert ist, kann in die Missbrauchsbekämpfung und Kundenüberprüfung unterinvestieren. Ein Reseller, der die Verantwortung nach oben weitergeben kann, kann an risikoreichere Kunden verkaufen. Ein Managed-Service-Anbieter, der nicht im Eintrag erscheint, kann Reputationsschäden vermeiden, wenn seine Konfiguration versagt.

Ein Kunde, der aus legitimen Datenschutzgründen nicht öffentlich genannt werden kann, muss dennoch eine authentifizierte Verantwortung gegenüber dem Halter, dem Register oder einem rechtmäßigen Antragsteller unter definierten Bedingungen bereitstellen können. Wenn niemand weiß, welche Schicht welche Pflicht trägt, hat jeder einen Anreiz, den profitablen Teil sichtbar und den riskanten Teil privat zu halten.

AFRINICs politische Sprache weist auf die richtige Unterscheidung hin. Suballokationen und Zuweisungen sollen registriert werden, weil Eindeutigkeit, Fehlerbehebung und Kontinuität mehr als den Namen des Halters erfordern. Gleichzeitig verlangt das Handbuch kein öffentliches Dossier über jeden nachgelagerten Nutzer. Der nützliche Mittelweg ist die Verantwortungssichtbarkeit: genügend öffentliche und authentifizierte Informationen, um die verantwortliche Betriebsschicht zu identifizieren, ohne jede Kundenidentität dem gesamten Internet auszusetzen.

Die Kosten, dies falsch zu machen, sind für kleinere Netzwerke am höchsten. Große Plattformen können private Vertrauenskanäle mit großen Banken, Transit-Anbietern, Sicherheitsanbietern und öffentlichen Behörden aufbauen. Kleine ISPs und regionale Hosting-Firmen können das nicht. Sie sind auf öffentliche und halböffentliche Einträge angewiesen, um von Fremden geglaubt zu werden. Wenn die öffentlichen Nachweise dünn sind, zahlen sie durch Verzögerungen, strengere Filterung, verlorene Kunden und schwächere Verhandlungsmacht.

Suballokations-Intransparenz wird daher zu einer regressiven Steuer auf die Netzwerke, die sie am wenigsten absorbieren können.

Die nachgelagerte Ebene ist bereits Teil der Allokationsökonomie

AFRINICs Policy Manual beschreibt die Adressverteilung nicht als einstufige Transaktion zwischen Register und Endnutzer. Es definiert eine Hierarchie. Ein LIR erhält Allokationen von einem regionalen Register und weist Adressraum in erster Linie Endnutzern zu. Eine Suballokation ist die Verteilung durch einen LIR an einen ISP zur weiteren Verteilung. Eine Zuweisung ist ein Block, den ein LIR einem ISP oder Endnutzer zur spezifischen Nutzung innerhalb der von dieser Partei betriebenen Infrastruktur gibt.

Provider-aggragierbarer Raum kann als nicht-portabler Raum an nachgelagerte Netzwerke vergeben oder suballokiert werden, während Provider-unabhängige Zuweisungen nicht zur weiteren Suballokation bestimmt sind. Dies ist bereits ein geschichtetes System.

Das Handbuch knüpft dann Verantwortlichkeiten an diese Schichtung. Es sagt, dass jede Allokation, PI-Zuweisung, PA-Zuweisung, Suballokation und andere Ressourcenzuweisung in der AFRINIC-Datenbank registriert werden muss, und dass nicht registrierte Ressourcen als ungültig betrachtet werden. Es verlangt, dass Registrierungsdaten jederzeit korrekt sind. Es legt die formale Mindestgröße für IPv4-Suballokationen auf /24 fest. Es verlangt, dass LIRs Suballokationen innerhalb ihrer Suballokationsfenster vornehmen oder bei Überschreitung dieser Fenster die AFRINIC-Zustimmung einholen.

Es macht LIRs dafür verantwortlich, dass der ihnen zugewiesene und anschließend suballokierte Raum gemäß den Gemeinschaftsrichtlinien und -leitlinien genutzt wird. Es empfiehlt einen langsamen Start für nachgelagerte ISPs. Es behandelt den Raum nachgelagerter ISPs als nicht-portabel innerhalb des aggregierbaren Blocks des LIR.

Diese Regeln offenbaren die institutionelle Logik. AFRINIC muss nicht jeden Paketnutzer kennen, aber es kann nicht gleichgültig gegenüber der nachgelagerten Struktur bleiben. Wenn ein nachgelagerter ISP ein /24 erhält, sollte die Datenbank des Registers nicht blind bleiben. Wenn der öffentliche Adressraum eines Endnutzers nicht nur Punkt-zu-Punkt-Infrastruktur ist, sagt das Handbuch, dass er mit Endnutzerkontakten registriert werden sollte, mit einer Datenschutzregelung für Einzelpersonen.

Wenn Reverse-DNS für ein /24 beantragt wird, sagt das Handbuch, dass mindestens eine Zuweisung oder Suballokation für dieses spezifische /24 registriert sein muss. Die Registerdienste selbst setzen registrierte nachgelagerte Fakten voraus.

Die moderne Schwierigkeit besteht darin, dass die kommerzielle Realität Schichten schafft, die nicht immer den alten Kategorien entsprechen. Ein Hosting-Unternehmen kann /29s, /28s oder /27s innerhalb eines registrierten /24 zuweisen. Ein Firewall-Anbieter kann Sicherheitsappliances für viele Kunden innerhalb des Aggregats eines Anbieters betreiben. Ein Reseller kann virtuelle private Server verkaufen, ohne eine formale /24-Suballokation zu erhalten. Ein Makler kann bei der Arrangierung der Nutzung helfen, ohne als technischer Betreiber zu erscheinen.

Eine Leasing-Plattform kann den Kunden zugang koordinieren, während der eingetragene Halter unverändert bleibt. Ein Managed-Service-Anbieter kann die Missbrauchsbehebung kontrollieren, aber nicht die Routenursprünge. Die nachgelagerte Ebene ist granularer als die politische Einheit.

Diese Diskrepanz sollte nicht zu zwei schlechten Antworten führen. Die erste ist so zu tun, als ob das öffentliche Register alles unterhalb des eingetragenen Halters ignorieren könnte. Das macht Fehlerbehebung, Missbrauchsreaktion, Sorgfaltspflicht und Strafverfolgungsrouting zu teuer. Die zweite ist, jeden kleinen Kundenbereich und jeden Kundennamen öffentlich zu machen. Das schafft Datenschutz- und Sicherheitsrisiken und könnte legitime Betreiber in private Vereinbarungen treiben, die weniger, nicht mehr, offenbaren.

Eine bessere Antwort beginnt mit funktionaler Sichtbarkeit. Der Eintrag sollte zwischen halterbetriebenem Raum, Kunden­zuweisung, nachgelagerter ISP-Suballokation, resellerverwaltetem Raum, Managed-Service-Betrieb, leas­inggestütztem Betrieb, datenschutzgeschütztem Endnutzergebrauch und strittigem oder veraltetem Status unterscheiden. Er muss nicht immer den rechtlichen Namen des Kunden veröffentlichen. Er sollte genug veröffentlichen, um zu zeigen, welche Schicht für die operative Reaktion verantwortlich ist und wie viel Gewicht dieser Aussage zukommt. Der Halter bleibt für die Registerbeziehung rechenschaftspflichtig.

Der nachgelagerte Betreiber wird für operative Angelegenheiten auffindbar. Der Kunde kann abgeschirmt bleiben, wo Gesetz, Sicherheit oder gewerbliche Vertraulichkeit dies rechtfertigen.

Diese Registrierungslogik unterstützt bereits eine Verantwortungskarte. Die Registrierung dient der Eindeutigkeit und der Bereitstellung von Informationen für die Fehlerbehebung. In einem IPv4-Knappheitsmarkt umfasst die Fehlerbehebung heute die Erreichbarkeit von Missbrauchskontakten, die Erklärung von Routenursprüngen, die Konsistenz von Reverse-DNS, den Nachweis von Unterdelegationen, die Sorgfalt bei Übertragungen, die öffentliche Beschaffung und die Fähigkeit von Fremden, einen verborgenen Kunden von einem verlassenen Eintrag zu unterscheiden.

Ein öffentliches Hauptbuch ist keine private Kundenliste

Die institutionelle Grenze ist einfach zu formulieren und schwer umzusetzen. Ein öffentliches Registerhauptbuch sollte keine Kundenliste werden. Es sollte eine Verantwortungskarte werden. Der Unterschied ist wichtig. Eine Kundenliste legt offen, wer Dienstleistungen von wem kauft. Eine Verantwortungskarte legt offen, welche Rolle für ein Ressourcensegment zuständig ist, welcher Kontaktkanal aktiv ist, welche Nachweise die Rolle stützen und wie viel Vertrauen Außenstehende ihr beimessen sollten.

Für öffentliche Nutzer ist der minimale nützliche Eintrag nicht die vollständige Kundenidentität. Es ist Rolle und Erreichbarkeit. Ein öffentlicher Eintrag kann zeigen, dass ein /24 halterbetrieben, einer Organisation zugewiesen, an einen nachgelagerten ISP suballokiert, über einen Managed-Service genutzt, an einen datenschutzgeschützten Endnutzer delegiert, unter Halterverantwortung verleast oder kommerziell delegiert oder Gegenstand eines Streits oder einer veralteten Bestätigung ist. Er kann Rollenkontakte veröffentlichen: Halterkontakt, technischer Kontakt, Missbrauchskontakt, Routing-Kontakt und Reverse-DNS-Kontakt.

Er kann Zeitstempel offenlegen: Erstregistrierung, letzte Validierung, letzte wesentliche Aktualisierung und Validierungsablauf. Er kann zeigen, ob die nachgelagerte Rolle vom Halter selbst bestätigt, von AFRINIC validiert, aus Routing-Nachweisen abgeleitet, durch Reverse-DNS-Delegation bestätigt oder aus Datenschutzgründen redigiert wurde.

Für authentifizierte Gegenparteien kann mehr Detail angemessen sein. Ein Transit-Anbieter, der eine Route bewertet, ein Käufer, der eine Übertragungsprüfung durchführt, ein Register, das eine Überprüfung bearbeitet, oder eine öffentliche Stelle mit einer rechtmäßigen Anfrage benötigen möglicherweise die rechtliche Identität des nachgelagerten Betreibers, ein Autorisierungsschreiben, Vertragsnachweise, Notfallkontakte, Betriebsgeografie, Kundenkategorie, Eskalationszeitfenster und den Nachweis, dass der Halter die Zusammenarbeit erzwingen kann. Diese Details müssen nicht weltlesbar sein.

Sie können vom Halter gehalten, in begrenzter Form beim Register hinterlegt, unter Geheimhaltung geteilt oder durch Gerichtsbeschluss oder gesetzliche Anforderung offengelegt werden.

Für Gerichte und Strafverfolgungsbehörden sollte die Schwelle höher, die Information aber tiefer sein. Wenn eine rechtmäßige Anfrage die Identität hinter einem datenschutzgeschützten Eintrag sucht, sollte das System nicht von Ermittlern verlangen, über fünf Zwischenhändler zu raten. Der Halter sollte in der Lage sein, die Kette zurückzuverfolgen. Das Register sollte wissen, ob der Halter eine solche Rückverfolgbarkeit beansprucht. Der öffentliche Eintrag sollte zeigen, dass ein datenschutzgeschützter nachgelagerter Nutzer existiert und dass die rechtliche Eskalation einen definierten Pfad hat, nicht dass der Kunde für alle unsichtbar ist.

Nachweise sind unerlässlich, sollten aber sparsam und klar verwendet werden. Derselbe sichtbare Fakt hat je nachdem, wie er gewonnen wurde, unterschiedlichen Wert. Ein vom Halter bestätigter nachgelagerter ISP ist nicht dasselbe wie ein registervalidierter. Ein routingbeobachteter Ursprung ist nicht dasselbe wie ein registrierter operativer Nutzer. Eine Reverse-DNS-Delegation ist kein Beweis für Missbrauchsverantwortung. Ein aus Datenschutzgründen redigierter Nutzer ist nicht dasselbe wie ein unbekannter Nutzer. Ein letzten Monat aktualisierter Eintrag ist nicht dasselbe wie einer, der zuletzt 2014 bearbeitet wurde.

Ein Register, das diese Unterschiede offenlegt, senkt die Interpretationskosten, ohne vorzugeben, mehr zu wissen, als es weiß.

Dieselbe Struktur schützt das Register vor Übergriffen. Durch die Veröffentlichung von Rolle, Erreichbarkeit, Nachweisstatus und Unsicherheit kann AFRINIC die öffentliche Vertrauenswürdigkeit verbessern, ohne ein Recht zu beanspruchen, jeden Kunden auf Richtlinienkonformität zu überprüfen. Es kann sagen: Dies ist der anerkannte Halter; dieser Block wird nachgelagert betrieben; der verantwortliche Betriebskanal ist hier; die rechtliche Identität wird der Öffentlichkeit vorenthalten, ist aber unter definierten Bedingungen rückverfolgbar; das letzte Validierungsdatum ist aktuell oder veraltet.

Ein solches Hauptbuch ist dünner als eine Kundendatenbank und dicker als ein bloßer Haltereintrag. Das ist die wirtschaftlich nützliche Mitte.

Knappe IPv4 verwandelt Intransparenz in einen Marktabschlag

Suballokations-Intransparenz ist nicht nur ein Sicherheitsproblem. Sie ist ein Marktabschlag. Wenn eine knappe Ressource nicht vom Halter zur tatsächlichen Betriebsverantwortung zurückverfolgt werden kann, bepreist jede Gegenpartei die Lücke. Der Käufer eines Blocks möchte wissen, ob nicht offengelegte nachgelagerte Nutzer einer Migration widerstehen werden. Der Leasingnehmer möchte wissen, ob der Leasinggeber Route, Reverse-DNS und Missbrauchsänderungen durch jeden Zwischenhändler unterstützen kann. Die Bank möchte wissen, ob adressgestützte Einnahmen von Kunden abhängen, deren Verträge nicht überprüft werden können.

Der öffentliche Käufer möchte wissen, ob ein kritischer Dienst auf Adressen sitzt, deren Autoritätskette mehrdeutig ist. Der Upstream möchte wissen, ob er die Route akzeptieren kann, ohne die erste erreichbare Partei für jede Beschwerde zu werden.

AFRINICs Knappheitsfakten machen den Abschlag konkret. Seine Erschöpfungsmitteilung besagte, dass Phase 2 begann, als nicht mehr als ein /11 an nicht reserviertem Raum im letzten /8 verblieb. In Phase 2 ist der gewöhnliche Allokations- oder Zuweisungsbereich klein, mit einem /24-Minimum und /22-Maximum. Solche Grenzen beseitigen die Nachfrage nicht; sie verschieben die Nachfrage in Wiederverwendung, Übertragungen, Leasing, Hosting-Angebot, Kundenumwidmung und Betriebsdelegation. Je mehr sich die Nachfrage durch bestehende Halter bewegt, desto wichtiger wird es zu wissen, was unterhalb dieser Halter geschieht.

Intransparenz macht auch alte Einträge gefährlicher. KrebsOnSecurity berichtete 2019 über Behauptungen, dass wertvoller afrikanischer IPv4-Raum, der mit ruhenden oder aufgelösten Organisationen verbunden war, über Unternehmen, die mit einer ehemaligen hochrangigen AFRINIC-Figur verbunden sind, umgeleitet oder verkauft wurde; der Forscher Ron Guilmette schätzte den betroffenen Raum auf einen Marktwert von über 50 Millionen US-Dollar. Die Bedeutung für die Suballokations-Sichtbarkeit liegt nicht nur im angeblichen Betrug. Es liegt darin, dass ruhende Einträge und schwache Autoritätsspuren wertvoll werden, wenn IPv4 einen Preis hat.

Ein Eintrag, der nicht klar offenbart, wer für die nachgelagerte Nutzung sprechen kann, lädt sowohl zu Betrug als auch zu defensiven Abschlägen ein.

Der Cloud-Innovation-Streit zeigt die andere Seite desselben Problems. Öffentliche Analysen beschrieben einen Konflikt über Millionen von IPv4-Adressen, kommerzielles Leasing, tatsächliche Nutzung im Vergleich zu registrierter oder erwarteter Nutzung und AFRINICs behauptete Fähigkeit, die Ressourcenanerkennung zu überprüfen oder zu beenden. Cloud Innovation bestritt AFRINICs Theorie und der Rechtsstreit eskalierte. Für die Suballokations-Sichtbarkeit ist die Lehre nicht, dass jedes Leasing schlecht oder jede Registeranfrage legitim ist.

Die Lehre ist, dass, wenn die tatsächliche nachgelagerte Nutzung intransparent ist, das Register versucht sein könnte, umfassende Kundeninformationen zu verlangen, während der Halter sich unter Berufung auf gewerbliche Vertraulichkeit widersetzen könnte. Beide Seiten können teilweise recht haben und dennoch ein schlechtes Gleichgewicht erzeugen.

In einem guten Gleichgewicht legen Halter strukturierte Verantwortung offen, ohne rohe Kundenlisten preiszugeben. In einem schlechten Gleichgewicht geben sie wenig preis, das Register verlangt zu viel, Rechtsstreitigkeiten beginnen, und der Markt diskontiert das gesamte Portfolio. Knappe IPv4 macht diesen Abschlag groß genug, um das Verhalten zu ändern. Ein Halter mit schlechter nachgelagerter Sichtbarkeit hat geringeres Käufervertrauen, höhere Rechtskosten, schlechtere Reputation nach Missbrauch und schwächere Akzeptanz im öffentlichen Sektor.

Ein Register mit schlechter Sichtbarkeit steht unter Druck, umfassende Überprüfungen durchzuführen, weil engere Nachweise nicht verfügbar sind. Das Fehlen von Sichtbarkeit schafft somit das Argument für Ermessensspielraum.

Das wirtschaftliche Ziel sollte sein, verantwortungsvolle Nutzung billiger zu machen als verborgene Nutzung. Ein Halter, der validierte nachgelagerte Rolleneinträge, Live-Kontakte, rückverfolgbare datenschutzgeschützte Kunden und klare Unsicherheitsetiketten pflegt, sollte bei Transaktionen und Vorfällen mit geringeren Reibungen konfrontiert sein. Ein Halter, der nicht erklären kann, wer seinen Raum nutzt, sollte durch Abschläge, langsamere Genehmigungen und strengere Prüfungen zahlen. Das ist keine Bestrafung. Es ist die Bepreisung von Informationsqualität.

Der Nachweisstapel ist plural, und jede Oberfläche hat Grenzen

Keine einzelne Datenquelle kann die Frage der nachgelagerten Verantwortung beantworten. RDAP und WHOIS liefern eingetragene Halter- und Kontaktdaten. BGP zeigt, welches autonome System eine Route ursprünglich ankündigt. IRR-Objekte drücken Routing-Richtlinien und Routenautorisierungskonventionen aus. RPKI und ROAs können die Ursprungsautorität validieren. Reverse-DNS kann Benennungsmuster, Kunden­delegationen und Betriebsgeschichte offenbaren.

Geolokalisierungsdatenbanken, Traceroute, Latenz, TLS-Zertifikate, Missbrauchshistorien, DNS-Zonen, Mail-Reputation, Hosting-Banner, Unternehmensregister und Kundenverträge können jeweils Hinweise liefern. Keines ist für sich genommen schlüssig.

Dieser pluralistische Nachweisstapel ist sowohl nützlich als auch gefährlich. Er ist nützlich, weil nachgelagerte Verantwortung oft nur sichtbar wird, wenn Signale kombiniert werden. Ein /24, das bei einem Halter registriert ist, von einer Hosting-ASN ursprünglich angekündigt wird, durch eine ROA für diese ASN abgedeckt ist, mit einem Reseller-Reverse-DNS-Muster benannt ist, in einem von einem Dritten gepflegten IRR-Objekt gelistet ist und eine Missbrauchshistorie im Zusammenhang mit VPS-Kunden trägt, wird wahrscheinlich nicht im einfachen Sinne halterbetrieben sein. Aber es ist gefährlich, weil Schlussfolgerungen den Beweis überholen können.

Ein Reverse-DNS-Label kann veraltet sein. Ein IRR-Objekt kann nicht autorisiert sein. Eine Geolokalisierungsdatenbank kann falsch sein. Eine ROA kann die Routenursprungsautorität beweisen, nicht die Kundenidentität. Eine Ursprungs-AS kann ein Transit- oder Managed-Service-Betreiber sein, nicht der endgültige Nutzer.

AFRINICs öffentliche Dienste erstrecken sich über weite Teile dieses Stapels. Das Register stellt WHOIS, RDAP, Reverse-DNS, IRR und RPKI-bezogene Dienste bereit. Sein Policy Manual verknüpft die Reverse-Delegation mit registrierten Zuweisungen oder Suballokationen. Seine Missbrauchskontaktrichtlinie schafft einen Platz für Missbrauchsinformationen, erkennt aber an, dass das Objekt, wie andere Objekte auch, mit dem Problem der Datengenauigkeit konfrontiert ist. Die Offenheit ist wichtig. Ein Feld kann einen Kanal schaffen, ohne zu beweisen, dass der Kanal korrekt ist.

Eine ROA kann einen Ursprung autorisieren, ohne den nachgelagerten Kunden zu beweisen. Eine Zuweisung kann einen Endnutzerbereich identifizieren, ohne jedes spätere Betriebsdetail zu beweisen.

Der öffentliche Eintrag sollte daher den Nachweistyp offenlegen. Eine nachgelagerte Rolle kann registriert, halterbestätigt, registervalidiert, routingbeobachtet, reverse-DNS-konsistent, vertragshinterlegt, durch rechtliche Eskalation rückverfolgbar, veraltet, strittig oder aus Datenschutzgründen redigiert sein. Diese Etiketten können bürokratisch klingen, wenn sie übermäßig verwendet werden. Gut eingesetzt, sind sie wirtschaftlich wertvoll. Sie verhindern, dass ein schwaches Signal als starkes Signal behandelt wird und dass das Fehlen einer öffentlichen Identität als Fehlen von Verantwortung behandelt wird.

Nachweisetiketten reduzieren auch den Anreiz für private Mythenbildung. In intransparenten Märkten füllen Makler und Gegenparteien Lücken mit Behauptungen: sauberer Block, gerichtlich gestützt, Erstanbieter, Afrika-konform, kein Missbrauch, voll autorisiert, sicher für die Nutzung im öffentlichen Sektor. Einige Behauptungen mögen wahr sein. Einige mögen Marketing sein. Ein Registereintrag, der strukturierte Nachweise offenlegt, gibt Käufern und Betreibern eine Möglichkeit, Behauptungen zu überprüfen, ohne AFRINIC zu einem kommerziellen Schiedsrichter zu machen. Das Register kann sagen, was es validiert hat und was nicht.

Der Markt kann den Rest bepreisen.

Dies ist besonders unter institutionellem Stress wichtig. Während der Insolvenzverwaltung, von Wahlstreitigkeiten oder Rechtsstreitigkeiten werden Gerüchte zu Ersatz für Einträge. Wenn die öffentliche Datenbank nicht zwischen gewöhnlichem nachgelagertem Betrieb und umstrittener Delegation oder zwischen Datenschutzschutz und unbekannter Nutzung unterscheiden kann, werden Gegenparteien aus Schlagzeilen schließen. Ein dünnes Nachweisetikett kann eine teure Überreaktion verhindern. Das Register muss nicht jede nachgelagerte Tatsache garantieren. Es muss den Status der Tatsachen, die es führt, offenlegen.

Der Nachweisstapel sollte als Wahrscheinlichkeitskarte gelesen werden. Je stärker die Kombination aus registrierter Suballokation, validiertem Kontakt, passendem Routenursprung, aktueller ROA, kohärentem Reverse-DNS und aktueller Bestätigung, desto niedriger die Mehrdeutigkeitssteuer. Je schwächer die Kombination, desto mehr Vorsicht ist gerechtfertigt. So verhalten sich Märkte bereits informell. AFRINIC kann den Markt verbessern, indem es die informelle Wahrscheinlichkeitskarte expliziter macht.

Missbrauchserreichbarkeit ist eine Folge, nicht die ganze Geschichte

Missbrauchsbeschwerden sind oft der Ort, an dem Suballokations-Intransparenz sichtbar wird. Eine Bank sieht Angriffe. Ein Sicherheitsanbieter sieht Malware-Rückrufe. Ein Mail-Betreiber sieht Spam. Ein Urheberrechtskläger sieht Hosting. Eine öffentliche Stelle sieht Scanning gegen einen Regierungsdienst. Der Beschwerdeführer fragt das Register ab und sendet eine E-Mail an den aufgeführten Kontakt. Wenn der aufgeführte Halter nicht der tatsächliche Betreiber ist, beginnt das Ticket sich seitwärts zu bewegen: Halter zu Reseller, Reseller zu Hosting-Anbieter, Hosting-Anbieter zu Managed-Firewall-Anbieter, Anbieter zu Kunde.

Jeder Sprung fügt Verzögerung und Fehler hinzu.

Es ist verlockend, den Missbrauchskontakt zum ganzen Thema zu machen. Das wäre zu eng. Missbrauchserreichbarkeit ist ein Output der nachgelagerten Sichtbarkeit, nicht die gesamte Ökonomie. Dieselbe Sichtbarkeit betrifft die Routing-Akzeptanz, die Transaktions-Sorgfalt, die Kundenkontinuität, die öffentliche Beschaffung, die Sanktionsprüfung, die Strafverfolgungsreaktion, die Geolokalisierung, Reverse-DNS, die RPKI-Wartung und das Reputationsmanagement. Ein Missbrauchsticket ist einfach der Moment, in dem die verborgene Struktur teuer genug wird, um bemerkt zu werden.

AFRINICs Missbrauchskontaktrichtlinie ist ein nützlicher Beweis für diese begrenzte Rolle. Sie spezifiziert ein dediziertes Objekt als bevorzugten Ort zur Veröffentlichung öffentlicher Missbrauchskontaktinformationen, auf das in inetnum-, inet6num- und aut-num-Objekten verwiesen wird. Sie zielt darauf ab, Missbrauchsberichte an den richtigen Netzwerkkontakt zu leiten. Sie erkennt auch einen Nachteil an: Das Objekt steht vor demselben Problem der Datengenauigkeit wie andere Objekte und verbessert nicht von sich aus die Datenbankgenauigkeit. Das ist genau der Punkt.

Ein Postfach löst keine nachgelagerte Intransparenz, wenn das Postfach zur falschen Schicht gehört oder wenn der Halter den nachgelagerten Betreiber nicht zum Handeln zwingen kann.

Eine bessere Struktur knüpft die Missbrauchserreichbarkeit an die Rollensichtbarkeit. Wenn ein Block halterbetrieben ist, sollte die Missbrauchsstelle des Halters der primäre öffentliche Kanal sein. Wenn er an einen nachgelagerten ISP suballokiert ist, sollte der validierte Missbrauchskanal des nachgelagerten ISP sichtbar sein, wobei die Eskalation des Halters erhalten bleibt. Wenn er einem Unternehmenskunden zugewiesen ist, dessen Identität aus Datenschutzgründen geschützt ist, sollte der öffentliche Eintrag einen verantwortlichen Betriebsschalter oder Proxy sowie einen rechtlichen Eskalationsweg veröffentlichen.

Wenn er von einem Firewall- oder Hosting-Anbieter verwaltet wird, sollte der öffentliche Eintrag zeigen, welche Betriebsschicht Missbrauch zuerst erhält. Wenn die Verantwortung strittig oder veraltet ist, sollte der Eintrag dies sagen.

Dies vermeidet zwei häufige Fehler. Das erste ist das Problem der falschen Stelle, bei dem Beschwerden den rechtlichen Halter erreichen, aber nicht den Betreiber, der Abhilfe schaffen kann. Das zweite ist das Problem des nicht rechenschaftspflichtigen Kunden, bei dem der Halter Datenschutz oder Reseller-Distanz geltend macht und keine erreichbare Partei handelt. In beiden Fällen verlagern sich die Kosten auf Außenstehende. Banken überblocken. Upstreams drohen mit Suspendierung. Reputationsdienste markieren benachbarten Raum. Strafverfolgungsbehörden eskalieren über langsamere Kanäle. Unschuldige Nutzer teilen die Strafe.

Missbrauchssichtbarkeit schützt auch die Halter. Ein Halter, der validierte nachgelagerte Verantwortung nachweisen kann, kann seine eigene Gefährdung eingrenzen. Er kann einem Beschwerdeführer sagen: Dieser Bereich wird von dieser nachgelagerten Rolle betrieben; hier ist der Missbrauchskanal; der Halter bleibt für Eskalationen verfügbar, falls der nachgelagerte Schreibtisch versagt. Das ist besser, als jedes Ticket zu erhalten, einige zu verpassen und als fahrlässig behandelt zu werden. Es ist auch besser, als rohe Kundenidentitäten in einer Weise zu veröffentlichen, die Datenschutz- oder Sicherheitsrisiken schafft.

Die Ökonomie besteht daher nicht darin, jeden Halter zu veranlassen, eine große Missbrauchsabteilung zu betreiben. Sie besteht darin, den Weg zur Verantwortung kurz genug zu machen, dass feste Vorfallkosten nicht auf zufällige Außenstehende fallen. Suballokations-Sichtbarkeit ist die breitere Infrastruktur, die die Missbrauchskontaktrichtlinie zum Funktionieren bringt.

Rechenschaftspflichtige Redaktion ist der Datenschutz-Kompromiss

Der stärkste Einwand gegen nachgelagerte Sichtbarkeit ist der Datenschutz. Er verdient ernst genommen zu werden. Ein öffentliches Register, das jeden nachgelagerten Kunden nennt, könnte gefährdete Organisationen, Sicherheitsoperationen, Whistleblower-Infrastrukturen, politische Gruppen, Auftragnehmer des öffentlichen Sektors, Finanzinstitute, Gesundheitsdienstleister und gewöhnliche Unternehmen offenlegen. Es könnte das Register auch zu einem Aufklärungsinstrument machen.

Angreifer könnten Kunden kartieren, Beschaffungsbeziehungen ableiten, Managed-Security-Anbieter identifizieren, Migrationsfenster ins Visier nehmen oder Dienstleister unter Druck setzen. Gewerbliche Wettbewerber könnten erfahren, wer wen hostet. Eine Sichtbarkeitspolitik, die diese Schäden ignoriert, würde sich selbst besiegen.

Datenschutz rechtfertigt jedoch keine vollständige Intransparenz. Das Internet erlegt Fremden bereits externe Effekte auf. Pakete aus einem Bereich können eine Bank angreifen, ein Krankenhaus scannen, Phishing-Seiten hosten, die Mail-Reputation verschmutzen, eine Sanktionsprüfung auslösen oder einen öffentlichen Dienst beeinträchtigen. Wenn die verantwortliche Partei hinter Datenschutzsprache verborgen ist und kein rückverfolgbarer Kanal existiert, wird Datenschutz zu einer Möglichkeit, Kosten zu exportieren. Das Designproblem besteht darin, Vertraulichkeit zu bewahren, während Rechenschaftspflicht erhalten bleibt.

Die praktische Antwort ist die abgestufte Offenlegung. Öffentliche Einträge sollten Rolle, Erreichbarkeit, Status, Validierungsdatum und Nachweisstärke tragen. Sie sollten nicht unbedingt jeden rechtlichen Kundennamen veröffentlichen. Authentifizierte Gegenparteien können unter Vertrag oder betrieblichem Bedarf mehr Details erhalten. Das Register kann begrenzte Nachweise halten oder überprüfen, ohne sie öffentlich offenzulegen. Strafverfolgungsbehörden und Gerichte können tiefere Identitätsinformationen durch rechtmäßige Anfragen erhalten.

Notfallkanäle können für unmittelbare Schäden existieren, ohne die Notfalloffenlegung zur Routine zu machen. Einzelpersonen können stärkere Redaktion erhalten als unternehmerische nachgelagerte ISPs. Öffentliche Stellen können designierte Sicherheitskontakte verwenden, anstatt jeden Auftragnehmer offenzulegen.

Redaktion sollte gekennzeichnet sein, nicht still. „Kundenidentität aus Datenschutzgründen zurückgehalten; Halter unterhält rückverfolgbaren Kontakt; Missbrauchsproxy validiert“ ist wirtschaftlich etwas anderes als „keine nachgelagerten Informationen“. Es teilt Außenstehenden mit, dass es eine verantwortliche Struktur gibt, auch wenn der Name nicht öffentlich ist. Es schafft auch Rechenschaftspflicht für den Halter: Wenn der Halter datenschutzgeschützte Rückverfolgbarkeit beansprucht, muss er in der Lage sein, zurückzuverfolgen.

Das Versäumnis, unter definierten Bedingungen zurückzuverfolgen, sollte Konsequenzen haben, da sonst Datenschutz zu einem falschen Status wird.

Das Etikett sollte auch Datenschutz von gewerblichem Geheimnis trennen. Die sensible Infrastruktur einer Bank, eine Menschenrechtsgruppe und die Kundenliste eines Resellers mögen alle Schutz verdienen, aber aus unterschiedlichen Gründen und gegenüber unterschiedlichen Offenlegungsstufen. Ein nachgelagerter ISP, der eine formale /24-Suballokation erhält, befindet sich nicht in derselben Position wie ein einzelner Kunde, der eine kleine Zuweisung erhält. Das öffentliche Interesse an der Identifizierung eines operativen Netzwerks ist höher als das öffentliche Interesse an der Benennung jedes Endnutzers.

AFRINICs Policy Manual enthält bereits eine begrenzte Datenschutzregelung, wenn ein Endnutzer eine Einzelperson ist: Der Raum kann mit den Kontaktinformationen des Anbieters registriert werden, während der Endnutzer im Datenbankobjekt referenziert wird. Diese Logik kann vorsichtig erweitert werden.

Der institutionelle Test ist, ob das System eine enge Frage beantworten kann: Wenn ein Schaden, Streit oder eine rechtmäßige Anfrage auftritt, wer kann handeln? Es muss nicht jede Neugier befriedigen. Es muss nicht jeden Kunden veröffentlichen. Es darf nicht zulassen, dass Datenschutz die Verantwortung auslöscht. In einem knappen IPv4-Markt ist das Datenschutzdesign, das funktioniert, nicht Geheimhaltung. Es ist rechenschaftspflichtige Redaktion.

Routing, IRR und RPKI beweisen Autorität, nicht Nutzung

Routing-Nachweise sind mächtig, weil sie beobachtbar sind. Wenn ein Präfix von einer bestimmten AS ursprünglich angekündigt wird, kann das operative Internet es sehen. Wenn ein IRR-Routenobjekt existiert, können Netzwerke auf eine behauptete Routing-Richtlinie schließen. Wenn eine ROA eine Ursprungs-AS autorisiert, können abhängige Parteien die Routenursprungsautorität validieren. Diese Signale sind wichtig für die nachgelagerte Sichtbarkeit, aber sie sollten nicht mit einem vollständigen Konto der Nutzung verwechselt werden.

BGP identifiziert das Netzwerk, das die Route ankündigt, nicht unbedingt den Kunden, der die Adressen nutzt. Ein Hosting-Anbieter kann Raum für viele Kunden ursprünglich ankündigen. Ein Managed-Service-Anbieter kann ein Präfix im Namen eines Unternehmens ankündigen. Ein Vermieter kann die AS eines Mieters autorisieren, während der Mieter Tausende kleiner Nutzer bedient. Ein Transit-Anbieter kann aufgrund der Routenbehandlung und nicht aufgrund der Kundenverantwortung in den Nachweisen erscheinen. Die Ursprungs-AS ist ein Hinweis auf die betriebliche Kontrolle, nicht eine rechtliche Identität für jeden nachgelagerten Nutzer.

IRR-Objekte haben ähnliche Grenzen. Sie können Upstreams und Peers helfen, Filter zu erstellen. Sie können zeigen, dass jemand ein Routen- oder Routen-Set-Objekt erstellt hat, das mit einem behaupteten Ursprung konsistent ist. Aber IRR-Daten können veraltet, dupliziert, in verschiedenen Datenbanken mit unterschiedlichen Authentifizierungsstandards erstellt oder von einer Partei gepflegt sein, die nicht mehr betrieblich verantwortlich ist. Ein IRR-Objekt, das von einem technischen Kontakt eines Maklers gepflegt wird, kann erklären, wie die Route akzeptiert wurde, beweist aber nicht, wer Missbrauch oder Kundenverträge bearbeitet.

RPKI und ROAs sind stärker für die Ursprungsautorität, aber enger für die Verantwortung. Eine gültige ROA kann sagen, dass eine bestimmte AS autorisiert ist, ein Präfix ursprünglich anzukündigen. Sie kann nicht sagen, warum die AS den Raum nutzt, wer der nachgelagerte Kunde ist, ob die Nutzung regional ist, ob ein Reseller beteiligt ist, ob Missbrauchsberichte den richtigen Schreibtisch erreichen oder ob eine Kunden­zuweisung unterhalb des abgedeckten Präfix existiert. RPKI ist ein Werkzeug zur Sicherung des Routenursprungs, kein Kundenidentitätssystem.

Diese Unterscheidung ist für AFRINIC wichtig, weil RPKI- und IRR-Dienste in der Nähe der Registeranerkennung liegen. Ein Halter kann möglicherweise eine ROA für die AS eines Mieters erstellen. Das lässt die Route im Sicherheitssinne legitim erscheinen. Es macht die nachgelagerte Kette nicht sichtbar. Umgekehrt kann das Fehlen einer ROA auf Betriebsverzögerung oder geringe Akzeptanz und nicht auf nicht autorisierte Nutzung zurückzuführen sein. Wenn der öffentliche Eintrag RPKI als den einzigen Beweis behandelt, wird er das tatsächliche Verantwortungsproblem übersehen.

Die korrekte Verwendung von Routing-Nachweisen ist die Triangulation. Ein nachgelagerter Rolleneintrag kann sagen, dass der eingetragene Halter AS X autorisiert hat, Präfix Y ursprünglich anzukündigen; dass eine ROA existiert oder nicht existiert; dass ein IRR-Objekt existiert und aktuell oder veraltet ist; dass der Missbrauchskontakt für die operative Rolle erreichbar ist; und dass die Kundenidentität öffentlich, nur für Authentifizierte oder aus Datenschutzgründen redigiert ist. Dies kombiniert Routing-Autorität mit Verantwortungssichtbarkeit.

Es überlastet kein kryptografisches oder routing-politisches Artefakt mit Tatsachen, die es nicht beweisen kann.

AFRINICs institutionelle Erholung würde von dieser Präzision profitieren. Das Register muss nicht zu einem allwissenden Richter über die nachgelagerte Nutzung werden. Es muss aufhören zu erlauben, dass eine Nachweisoberfläche eine andere imitiert. Routing sagt Erreichbarkeit. RPKI sagt Ursprungsautorität. IRR sagt Richtlinienbehauptung. RDAP und WHOIS sagen registrierte Anerkennung und Kontakte. Reverse-DNS sagt Benennungsdelegation. Nachgelagerte Sichtbarkeit sagt, wer unterhalb des Halters verantwortlich ist und wie sicher jemand sein kann.

Reverse-DNS ist ein Hinweis, kein Beweis

Reverse-DNS wird oft als sekundärer technischer Dienst behandelt, aber in der nachgelagerten Sichtbarkeit trägt es ein unverhältnismäßiges praktisches Gewicht. Ein PTR-Eintrag kann eine Hosting-Marke, ein Reseller-Muster, ein Kundenlabel, einen Länderhinweis, eine Mail-Dienst-Identität oder eine alte Nutzung offenbaren, die vor Jahren hätte entfernt werden sollen. Mail-Systeme, Sicherheitswerkzeuge, Kundensupport-Teams und Ermittler sehen sich regelmäßig Reverse-DNS an, weil es einen menschenlesbaren Hinweis bietet, wenn der Registereintrag zu abstrakt ist.

AFRINICs Policy Manual gibt Reverse-DNS eine formale Verbindung zur nachgelagerten Registrierung. Es sagt, dass AFRINIC Reverse-Delegationsanfragen von aktiven LIRs akzeptiert und dass keine Reverse-Delegation von verwaltetem oder zugewiesenem IP-Adressraum erlaubt ist, es sei denn, eine Zuweisung oder Suballokation aus der spezifischen Allokation ist ordnungsgemäß in der AFRINIC-Datenbank registriert. Für eine /24-Reverse-Delegation muss mindestens eine Zuweisung oder Suballokation für dieses spezifische /24 registriert sein.

Diese Regel ist eine leise Anerkennung, dass Reverse-DNS nicht frei von registrierten nachgelagerten Fakten schweben sollte.

Der Hinweis kann dennoch in die Irre führen. Reverse-DNS ist oft veraltet, nachdem ein Kunde gegangen ist. Benennungskonventionen können generische Etiketten verwenden, die den tatsächlichen Betreiber verbergen. Ein Halter kann Reverse-DNS an einen Reseller delegieren, dessen Kunde den Dienst kontrolliert. Ein Sicherheitsanbieter kann neutrale Namen verwenden, um Kunden nicht offenzulegen. Ein Mail-Betreiber kann Namen für die Zustellbarkeit und nicht für die Identität setzen. Ein böswilliger Nutzer kann irreführende Namen erstellen. Reverse-DNS kann daher nicht als Beweis für die nachgelagerte Identität behandelt werden.

Dennoch hat veraltetes oder intransparentes Reverse-DNS wirtschaftliche Folgen. Mail-Reputationssysteme können einen Bereich misstrauen. Kunden können fragen, warum Namen auf einen vorherigen Anbieter verweisen. Sicherheitsteams können Beschwerden an die falsche Organisation senden. Geolokalisierungs- und Hosting-Intelligence-Anbieter können alte Etiketten in Risikosysteme aufnehmen. Ein Kunde des öffentlichen Sektors kann eine Beschaffungs- oder Sicherheitsprüfung nicht bestehen, weil die Adressbenennung nicht mit dem deklarierten Dienst übereinstimmt. Ein Käufer kann Preisnachlässe verlangen, wenn die Reverse-DNS-Kontrolle unklar erscheint.

Ein Mieter kann entdecken, dass der Vermieter Namen nicht schnell aktualisieren kann, weil die registrierte Zuweisungsspur unvollständig ist.

Die Antwort ist nicht, in jeden PTR-Eintrag aussagekräftige Namen zu erzwingen. Die operative Benennung hat Sicherheits- und Datenschutzkompromisse. Die Antwort ist, Reverse-DNS als eine Nachweisoberfläche zu behandeln. Eine öffentliche Verantwortungskarte kann sagen, ob Reverse-DNS halterkontrolliert, nachgelagert delegiert, kundenverwaltet, veraltet, datenschutzneutral oder inkonsistent mit der registrierten Rolle ist. Das ist nützlicher, als zu versuchen, alles aus den Namen selbst abzuleiten.

Reverse-DNS veranschaulicht auch, warum Suballokations-Sichtbarkeit nicht nur in RDAP oder WHOIS gelöst werden kann. Die Registerdatenbank kann einen Halter und eine Suballokation zeigen. Der Reverse-Baum kann eine andere Betriebsgeschichte zeigen. Die Route kann eine dritte zeigen. Der Missbrauchskontakt kann eine vierte zeigen. Ein ernsthaftes Sichtbarkeitsregime gleicht diese Oberflächen aus. Es kennzeichnet Inkonsistenzen, ohne jede Inkonsistenz als Fehlverhalten anzunehmen. Es fragt, ob die Inkonsistenz für Erreichbarkeit, Reputation, rechtliche Eskalation oder Marktvertrauen relevant ist.

Für AFRINIC wäre eine enge Verbesserung wertvoll: Wenn eine Reverse-Delegation an eine registrierte Zuweisung oder Suballokation gebunden ist, sollte der öffentliche Eintrag die Verknüpfung lesbar machen. Wenn ein /24 Reverse-DNS delegiert hat, weil eine nachgelagerte ISP-Zuweisung existiert, sollten Außenstehende sehen können, dass die Reverse-Delegation nicht zufällig ist. Wenn Reverse-DNS unter dem Halter bleibt, während die operative Nutzung nachgelagert ist, sollte der Eintrag sagen, wer für Namensänderungen und Missbrauchseskalation verantwortlich ist. Dies legt keine Kunden offen.

Es legt Verantwortung für einen Dienst offen, der sie bereits betrifft.

Regionale Nutzungsbehauptungen erfordern Demut

AFRINICs Region verleiht der Suballokations-Sichtbarkeit eine besondere politische Ladung. Das Register dient Afrika und einem Teil des Indischen Ozeans. Seine Erschöpfungsmaterialien und sein Policy Manual rahmen Ressourcen um die AFRINIC-Dienstregion. Seine Soft-Landing-Richtlinie enthält regionale Nutzungssprache für Ressourcen während der Erschöpfungsperiode. Öffentliche Analysen des Cloud-Innovation-Streits beschrieben AFRINICs Bedenken hinsichtlich Diskrepanzen zwischen registrierten Nutzungsbeschreibungen und tatsächlichen Nutzungsländern sowie hinsichtlich Diensten, die innerhalb der Region ihren Ursprung haben.

Cloud Innovation und verbündete Kritiker bestritten diese Interpretation und argumentierten, dass der globale Netzwerkbetrieb nicht auf eine einfache Geografieregel reduziert werden könne.

Für die nachgelagerte Sichtbarkeit ist der entscheidende Punkt, dass die regionale Nutzung nicht immer direkt sichtbar ist. Die Routing-Geografie ist nicht die Kundengeografie. Ein Präfix, das von einer AS in Europa ursprünglich angekündigt wird, kann afrikanische Nutzer über eine Content- oder Sicherheitsplattform bedienen. Ein Server in Johannesburg kann Kunden weltweit unterstützen. Ein auf den Seychellen registrierter Halter kann Adressen an ein Netzwerk mit Kunden in China, Nigeria und Südafrika verleasen.

Eine Geolokalisierungsdatenbank kann einen Block aufgrund von Registerdaten in einem Land, aufgrund von Routing in einem anderen und aufgrund von Nutzerberichten in einem dritten platzieren. Reverse-DNS kann Ländercodes aus betrieblichen Gründen verwenden. Latenz kann anzeigen, wo der Datenverkehr in das Netzwerk eintritt, nicht wo der wirtschaftliche Dienst erbracht wird.

Dies bedeutet nicht, dass regionale Nutzungsnachweise nutzlos sind. Es bedeutet, dass sie als Vertrauen, nicht als Gewissheit ausgedrückt werden sollten. Ein Verantwortungseintrag kann deklarierte Dienstregion, beobachteten Routenursprung, Geolokalisierungskonsens, Kundenkategorie, afrikanische Abhängigkeit, außerregionale Operation und unbekannten Status unterscheiden. Er kann sagen, ob ein Halter selbst bestätigt hat, dass die Nutzung die Konnektivität zur AFRINIC-Region unterstützt, ob das Register eine spezifische regionale Nutzungsbehauptung validiert hat, ob die Nachweise nur routingbeobachtet sind oder ob die Frage strittig ist.

Das ist ehrlicher, als so zu tun, als ob ein einzelnes Länderfeld die Angelegenheit klärt.

Demut ist auch wirtschaftlich effizient. Wenn das Register schwache Schlussfolgerungen als Beweis behandelt, werden Halter sich der Offenlegung widersetzen und klagen. Wenn Halter Geografie als unerkennbar behandeln, werden das Register und die öffentlichen Interessenträger Ausweichmanöver vermuten. Ein vertrauensbasierter Eintrag gibt beiden Seiten ein weniger explosives Vokabular. Es ermöglicht AFRINIC, Muster zu sehen, ohne rohe Kundenlisten für jeden Block zu verlangen. Es ermöglicht Haltern, regionale Relevanz offenzulegen, ohne jeden Kunden offenzulegen.

Es ermöglicht Märkten, Unsicherheit zu bepreisen, anstatt eine Binärität von konform und nicht konform zu erfinden.

Regionale Nutzungsableitung ist auch für Entwicklungsansprüche relevant. Einige argumentieren, dass in Afrika ausgegebene IPv4 die afrikanische Konnektivität unterstützen sollte. Andere argumentieren, dass globale Märkte und nachfrageübergreifende Regionen wichtiger sein werden als die Bewachung des Restbestands regionaler Vorräte. Das öffentliche Hauptbuch sollte diese Debatte nicht durch obskure Felder entscheiden. Es sollte Nachweise liefern: wo die nachgelagerte Verantwortung sitzt, welche Nutzung deklariert ist, was beobachtet wird, was validiert ist und was unsicher bleibt. Gute Nachweise können die Politik informieren.

Schlechte Schlussfolgerungen werden zu Kapitalkontrolle durch Raten.

Der Standard sollte kalt und praktisch sein. Veröffentlichen Sie die deklarierte Rolle und Region auf der richtigen Detailebene. Kennzeichnen Sie beobachtete Signale. Bewahren Sie die Privatsphäre, wo gerechtfertigt. Eskalieren Sie nur, wenn die Nachweise materiell mit der Politik oder dem öffentlichen Vertrauen in Konflikt geraten. In einer Region, in der das Register bereits Rechtsstreitigkeiten über Nutzung und Kontrolle erlebt hat, ist diese Demut keine Schwäche. Sie ist Risikomanagement.

Zwischenhändler benötigen Verantwortungs-Tags

Die moderne nachgelagerte Kette ist selten eine gerade Linie. Ein Halter kann mit einem Makler zusammenarbeiten. Der Makler kann einen Reseller einführen. Der Reseller kann Adressen in VPS, Mail, VPN oder Managed-Firewall-Produkte verpacken. Ein Hosting-Anbieter kann die Ursprungs-AS betreiben. Ein Kunde kann den Server kontrollieren. Ein Drittanbieter-Missbrauchsdienst kann Beschwerden triagieren. Ein Managed-DNS-Anbieter kann die Reverse-Zonen kontrollieren. Der öffentliche Eintrag kann nur den Halter und vielleicht die Ursprungs-AS zeigen. Wenn Probleme auftreten, kann jede Schicht sagen, dass eine andere Schicht die operativen Fakten hat.

Makler und Reseller sind nicht inhärent schlecht. Sie senken die Suchkosten, bringen ungenutzte Kapazität mit der Nachfrage zusammen, bieten technisches Onboarding, stellen Dokumentation zusammen und helfen kleineren Netzwerken, Adressen zu erhalten, die sie sonst nicht finden könnten. Managed-Service-Anbieter lösen ebenfalls echte Probleme. Viele Kunden möchten kein Routing, Reverse-DNS, Missbrauchsstellen oder RPKI betreiben. Outsourcing kann die Qualität verbessern. Das Sichtbarkeitsproblem ist nicht die Intermediation. Es ist die nicht gekennzeichnete Intermediation.

Ein Verantwortungs-Tag ist eine enge Offenlegung der Rolle. Es sagt nicht, dass der Makler den Block besitzt oder dass der Reseller der Endkunde ist. Es kann sagen, dass ein gewerblicher Zwischenhändler beteiligt ist, aber nicht der operative Kontakt ist. Es kann sagen, dass ein Reseller für die Kundenüberprüfung verantwortlich ist. Es kann sagen, dass ein Managed-Service-Betreiber Missbrauch zuerst erhält. Es kann sagen, dass der Halter für Registeränderungen verantwortlich bleibt. Es kann sagen, dass ein nachgelagerter ISP die Kunden­zuweisungen kontrolliert.

Es kann sagen, dass die Kundenidentität aus Datenschutzgründen redigiert, aber über den Betreiber rückverfolgbar ist. Tags sagen Außenstehenden, wohin sie die falsche Anfrage nicht senden sollen.

Solche Tags würden häufige Fehler reduzieren. Ein Upstream, der eine Route bewertet, würde wissen, ob die Ursprungs-AS als Mieter, Managed-Betreiber oder Halternetzwerk fungiert. Ein Beschwerdeführer würde wissen, ob das öffentliche Missbrauchspostfach den Betreiber erreicht, der dem Kunden am nächsten ist. Ein Käufer würde wissen, ob nicht offengelegte Reseller Kundenkontinuitätsansprüche haben könnten. Ein öffentlicher Käufer würde wissen, ob die Adressversorgung eines Auftragnehmers von einer vermittelten Kette abhängt.

Das Register würde wissen, ob ein Halter, der Datenschutz geltend macht, zumindest seine Verantwortungskette kartiert hat.

Verantwortungs-Tags helfen auch, Leasing von Suballokations-Sichtbarkeit zu unterscheiden, ohne Leasing zum Hauptrahmen zu machen. Leasing ist ein Kanal, durch den Intransparenz auftritt. Die relevante Frage hier ist nicht die privatrechtlichen Abhilfen oder der kommerzielle Preis des Leasings. Es ist, ob das Leasing oder eine andere kommerzielle Delegation ändert, wer den Raum nutzt und wer kontaktiert werden kann. Ein Leasing mit klaren Verantwortungs-Tags kann weniger riskant sein als eine gewöhnliche Hosting-Zuweisung ohne Rückverfolgbarkeit.

Ein Verkauf mit verborgenen nachgelagerten Kunden kann problematischer sein als eine transparente zeitlich begrenzte Delegation.

Dieselbe Logik gilt für den Kundendatenschutz. Ein Tag kann „datenschutzgeschützter Endnutzer, rückverfolgbar durch Halter“ sagen, ohne den Endnutzer zu nennen. Es kann sagen: „Kontakt für Strafverfolgungsbehörden über Haltereskalation verfügbar“, ohne sensible Kanäle zu veröffentlichen. Es kann sagen: „Reseller-kontrollierte Kundenliste“, damit Gegenparteien wissen, dass der Halter möglicherweise keine unmittelbaren Protokolle hat. Dies ist keine Kundenliste. Es ist eine Karte, wer welche betriebliche Pflicht hat.

Zwischenhändler werden wirtschaftlich sicherer, wenn ihre Rollen lesbar sind. Wenn sie sich jeder Offenlegung der Rolle widersetzen, werden Märkte das Schlimmste annehmen. Wenn das Register die vollständige Offenlegung der Kunden verlangt, werden legitime Zwischenhändler Widerstand leisten. Tags bieten eine kostengünstigere Alternative: sichtbare Verantwortung, geschützte Identität und bepreiste Unsicherheit.

Abhängigkeit des öffentlichen Sektors verwandelt Intransparenz in ein staatliches Kapazitätsrisiko

Suballokations-Intransparenz wird ernster, wenn Systeme des öffentlichen Sektors von der Adresskette abhängen. Ein Ministerium kann Bürgerservices mit einem lokalen Anbieter hosten, der Adressen von einem regionalen Halter verwendet. Ein öffentliches Krankenhaus kann verwaltete Sicherheit von einem Anbieter kaufen, dessen Firewall-Knoten innerhalb eines geleasten oder suballokierten Blocks sitzen. Eine polizeiliche Cybercrime-Einheit kann nach einem Vorfall Teilnehmer- oder Kundeninformationen benötigen. Ein nationales Bildungsnetzwerk kann sich auf nachgelagerte Anbieter für Campusse verlassen.

Ein Gericht kann Beweise sichern müssen, während ein Dienst online bleibt. In jedem Fall weiß die öffentliche Stelle möglicherweise nicht, dass ihre Kontinuität von einer mehrere Ebenen tiefen Adresskette abhängt.

Für gewöhnliche kommerzielle Kunden ist Intransparenz ein Problem der Risikoverteilung. Für Kunden des öffentlichen Sektors kann es zu einem Problem der staatlichen Kapazität werden. Ein Steuerportal, das die Mail-Zustellbarkeit verliert, weil Reverse-DNS veraltet ist, eine Beschaffungsplattform, die blockiert wird, weil benachbarte Adressen missbräuchlich sind, oder ein Notdienst-Anbieter, der die Routenautorität nicht nachweisen kann, steht nicht nur vor einer IT-Unannehmlichkeit. Die Kosten werden von Bürgern und öffentlichen Einrichtungen getragen, die die verborgene Adressstruktur nicht gewählt haben.

Die Bedürfnisse der Strafverfolgung sind ebenfalls spezifisch. Ermittler beginnen oft mit einer IP-Adresse, einem Zeitstempel und einem Port. Wenn der öffentliche Eintrag nur den Halter nennt, muss der Ermittler die Kette durchlaufen: Halter, Reseller, Managed-Anbieter, Kunde, Endnutzer. NAT, CGNAT, VPS-Mietverhältnisse und kurzfristiges Hosting machen die Zeit kritisch. Wenn der Halter keine Rückverfolgbarkeit aufrechterhält oder der Reseller nicht aufgezeichnet ist, können rechtmäßige Anfragen zu spät oder bei der falschen Partei eintreffen.

Eine übermäßig breite öffentliche Offenlegung ist nicht die Antwort, aber ein strukturierter Eskalationspfad ist es.

AFRINICs Krisengeschichte erhöht den Einsatz, weil öffentliche Behörden das Register möglicherweise bereits als Institution betrachten. Die Berichterstattung über die mauritische Insolvenzverwaltung beschrieb ein Mandat zur Aufrechterhaltung des Betriebs und zur Wiederherstellung der Governance, während spätere Berichterstattung anhaltenden gerichtlichen Druck, gescheiterte Wahlmechanismen, Fragen der Vorstandsrestauration, Klagen und Streitigkeiten über die Behandlung von Nummernressourcen beschrieb.

In einem solchen Umfeld benötigen Nutzer des öffentlichen Sektors den Nachweis, dass die Adresskontinuität nicht von nicht aufgezeichneten privaten Vereinbarungen abhängt, die unter Rechtsstreitigkeiten oder Governance-Änderungen zusammenbrechen.

Ein Beschaffungsstandard für den öffentlichen Sektor könnte einfach sein. Anbieter, die AFRINIC-verwaltete IPv4 für öffentliche Dienste nutzen, sollten in der Lage sein, den eingetragenen Halter, das betreibende Netzwerk, die Routenursprungsautorität, die Reverse-DNS-Kontrolle, die Missbrauchs- und Sicherheitskontakte, die nachgelagerten Verantwortungs-Tags, die Datenschutzvereinbarungen, die Eskalation rechtmäßiger Anfragen und alle Streitigkeiten, die den Raum betreffen, nachzuweisen. Die öffentliche Version muss nicht jeden Kunden offenlegen.

Die käufergerichtete Datei sollte vollständig genug sein, um Kontinuität und Rechenschaftspflicht zu unterstützen.

Die Abhängigkeit des öffentlichen Sektors ändert daher die Datenschutzbilanz. Die Öffentlichkeit benötigt nicht jeden Kundennamen. Sie benötigt die Zusicherung, dass kritische Dienste eine rückverfolgbare Adressverantwortung haben. Ein Register, das zur Schaffung dieser Zusicherung beiträgt, wird nicht zu einer Überwachungsbehörde. Es reduziert das öffentliche Beschaffungsrisiko in einem Markt, in dem Adressknappheit und institutionelle Instabilität die Adressebene sichtbar gemacht haben.

Die Erholung wird unterhalb der Halterlinie beurteilt

AFRINIC benötigt kein maximales Transparenzregime. Es benötigt einen Sichtbarkeitspakt, der festlegt, wofür nachgelagerte Sichtbarkeit da ist: Eindeutigkeit, Fehlerbehebung, Missbrauchserreichbarkeit, Routenautoritätsprüfung, Reverse-DNS-Konsistenz, rechtliche Eskalation, Transaktionsvertrauen und Kontinuität für Kunden, die auf knappe IPv4 angewiesen sind. Es sollte auch festlegen, wofür Sichtbarkeit nicht da ist: Veröffentlichung roher Kundenlisten, Beurteilung jeder kommerziellen Vereinbarung, Offenlegung sensibler Nutzer oder Verwendung von Registrierungsfeldern als Hebel in nicht zusammenhängenden Streitigkeiten.

Der Pakt könnte mit einigen wenigen Eintragstypen beginnen. Formale Suballokationen auf oder über dem politischen Minimum sollten öffentlich sichtbar sein mit der Identität des nachgelagerten ISP, Kontakten, Status, Validierungsdatum und Haltereskalation. Endnutzer­zuweisungen, die eine öffentliche operative Rechenschaftspflicht erfordern, sollten den Endnutzer oder einen datenschutzgeschützten Proxy mit klaren Rollenetiketten identifizieren.

Kleinere Kundenbereiche unterhalb der öffentlichen Suballokationsschwellen müssen nicht öffentlich genannt werden, aber Halter sollten die Rückverfolgbarkeit aufrechterhalten und Verantwortungs-Tags veröffentlichen, wo Missbrauch, Routing, Reverse-DNS oder rechtmäßige Anfragen die Rolle materiell machen.

Jeder Eintrag sollte einen Nachweisstatus tragen: registervalidiert, halterbestätigt, gegenparteibestätigt, routingbeobachtet, datenschutzredigiert aber rückverfolgbar, veraltet, strittig oder gerichtlich eingeschränkt. Diese Etiketten würden verhindern, dass ein öffentliches Feld so tut, als sei es sicherer, als es ist. Sie würden es auch Märkten ermöglichen, bessere Nachweise zu belohnen. Ein Block mit aktueller nachgelagerter Verantwortung sollte billiger zu routen, übertragen, leasen, finanzieren und beschaffen sein als ein Block mit nur veralteten Halterdaten.

Der Pakt sollte Validierungszyklen enthalten. Kontakte und Rollen-Tags sollten ablaufen, es sei denn, sie werden aktualisiert. Wesentliche Änderungen, wie ein neuer nachgelagerter ISP, eine neue Ursprungs-AS, eine Übernahme durch einen Managed-Service, eine Änderung der Reverse-DNS-Delegation oder eine große Kundenmigration, sollten Aktualisierungspflichten auslösen. Die Nichtaktualisierung sollte zunächst sichtbare Unsicherheit und Heilungsverfahren erzeugen, nicht sofortige Ressourcenbeeinträchtigung.

Strenge Abhilfen sollten falschen Aussagen, nicht rückverfolgbarer Hochrisikonutzung, Betrug, gerichtlichen Anordnungen oder wiederholter Weigerung, die Mindestverantwortung aufrechtzuerhalten, vorbehalten sein.

Es sollte auch eine private Nachweisebene geben. Halter sollten Aufzeichnungen über Kunden­zuweisungen, Autorisierungen, Reseller-Verträge, Missbrauchseskalation, Routing-Berechtigungen und Datenschutzbegründungen führen. AFRINIC sollte nicht standardmäßig jedes Dokument benötigen. Es sollte in der Lage sein, verhältnismäßige Nachweise anzufordern, wenn eine formale Suballokation, eine Abhängigkeit des öffentlichen Sektors, eine Übertragung, ein Streit, ein großes Missbrauchsmuster oder ein Reverse-DNS/RPKI-Konflikt die nachgelagerte Rolle materiell macht.

Die Anfrage sollte spezifisch, zeitlich begrenzt und enger als eine Prüfung aller Kunden sein, es sei denn, die Nachweise rechtfertigen mehr.

Der Pakt sollte Korrektur belohnen. Wenn ein Halter freiwillig veraltete nachgelagerte Verantwortung aktualisiert, sollte die Standardreaktion die Korrektur des Eintrags sein, nicht eine umfassende Durchsetzung. Sonst werden rationale Halter verbergen. Betrug und vorsätzliche Falschheit erfordern eine andere Behandlung, aber gewöhnliche Korrektur sollte gefördert werden. Ein Register, das sich von einer Geschichte der Eintragsmanipulation erholt, muss fest gegen Falschheit und sicher für die Wahrheit sein.

AFRINICs öffentliche Erholung wird oft durch Vorstände, Budgets, Insolvenzverwaltung, Gerichtsbeschlüsse, ICANN-Intervention und institutionelle Legitimität diskutiert. Diese Angelegenheiten sind real. Aber für viele Betreiber wird der praktische Test unterhalb der Halterlinie stattfinden. Kann ein Kunde, Upstream, Käufer, eine öffentliche Stelle, eine Strafverfolgungsstelle oder ein Missbrauchsberichterstatter verstehen, wer für eine spezifische Nutzung knapper IPv4 verantwortlich ist, wenn diese Nutzung nicht durch den eingetragenen Halter erfolgt? Wenn nicht, bleibt die Governance-Erholung zu abstrakt.

Das Register kann rechtlich erhalten bleiben und dennoch die nachgelagerte Verantwortung intransparent lassen. Es kann einen Vorstand wählen und dennoch nur Halterebenen-Einträge offenlegen. Es kann RDAP, WHOIS, Reverse-DNS, IRR und RPKI betreiben und dennoch diese Oberflächen nicht zu einer Verantwortungskarte verbinden. Es kann Richtlinien ankündigen und dennoch Märkte raten lassen, ob ein geroutetes Präfix halterbetrieben, resellerbetrieben, geleast, suballokiert, zugewiesen, datenschutzgeschützt oder strittig ist. In einem Knappheitsmarkt ist dieses Raten teuer.

AFRINICs jüngste Geschichte gibt ihm sowohl Grund als auch Verpflichtung, es besser zu machen. Die Berichterstattung über Adressdiebstahl zeigt die Gefahr schwacher Eintragsautorität. Der Cloud-Innovation-Streit zeigt die Gefahr, dass intransparente kommerzielle Delegation und breites Registerermessen aufeinanderprallen. Die Insolvenzverwaltung zeigt die Notwendigkeit von Kontinuität, wenn die Unternehmensführung versagt. Die Wahlkontinuitätsbrüche zeigen, dass Mitgliederautorität und institutionelle Legitimität selbst zu Markttatsachen werden können.

Fortgesetzte Rechtsstreitigkeiten zeigen, dass öffentliche Behauptungen über Leasing, Kommerzialisierung und gerichtliche Anerkennung das Vertrauen bewegen können. Suballokations-Sichtbarkeit wird nicht alles davon lösen. Sie wird eine wichtige Unsicherheit verringern, die andernfalls den Rest anheizt.

Die korrekte institutionelle Haltung ist bescheiden. AFRINIC sollte nicht behaupten, jeden Kunden zu kennen. Es sollte nicht der wirtschaftliche Regulierer jedes nachgelagerten Dienstes werden. Es sollte keine Kundenlisten als Ersatz für klare Politik verlangen. Es sollte Sichtbarkeit nicht nutzen, um unpopuläre Geschäftsvereinbarungen ohne angemessene Sicherungen zu bestrafen. Aber es sollte darauf bestehen, dass eingetragene Halter die nachgelagerte Verantwortung auf der Ebene erklären und nachweisen können, auf der Außenstehende auf den Adresseintrag angewiesen sind.

Das ist der Unterschied zwischen einem Hauptbuch und einem privaten Nebel.

Der Nutzen ist praktisch: engere Missbrauchsberichte, weniger grobe Filterung, sauberere Reverse-DNS- und RPKI-Änderungen, weniger maklerabhängige Sorgfalt, stärkere öffentliche Beschaffung und geschützte Kunden mit rechenschaftspflichtiger Rückverfolgbarkeit. Märkte würden verifizierte Verantwortung eher bepreisen als Gerüchte.

Der Pakt würde auch Halter disziplinieren. Ein Halter, der knappe IPv4-Kapazität vermietet, zuweist, suballokiert oder delegiert, sollte nicht nur sagen können: Das öffentliche Hauptbuch nennt mich, also müssen alle anderen mir vertrauen. Der Halter ist der Anker, nicht die ganze Geschichte. Wenn er von der nachgelagerten Nutzung profitiert, Kunden abschirmt oder Zwischenhändler einsetzt, muss er wissen, wer handeln kann. Wenn er es nicht kann, hat der Markt recht, den Block abzuwerten.

AFRINIC ist ein Testfall, weil Afrikas Register die volle Kollision von Knappheit, Eintragsintegrität, kommerzieller Delegation, Rechtsstreitigkeiten und institutioneller Erholung erlebt hat. Die Lehre ist nicht, dass jeder nachgelagerte Nutzer öffentlich sein sollte. Es ist, dass Verantwortung nicht privat bleiben kann, wenn die Kosten ihres Fehlens öffentlich sind. Ein nützliches Registerhauptbuch legt nicht die Kundenliste offen. Es legt genug von der Verantwortungskette offen, damit Fremde handeln können, ohne sich dem Kampf anzuschließen.