Bei ARIN hängen NET-Berechtigungen vom Suchweg ab

Zusammenfassung

• Der Einreicher von ACSP 2026.4 berichtete, dass nach einer Detailed Reassignment an eine andere Org der API-Schlüssel des übergeordneten Registranten das Kind-NET nicht per Handle abrufen konnte. Der Schlüssel der Empfänger-Org konnte es; der Elternakteur konnte laut Bericht dennoch DELETE ausführen und per exaktem mostSpecificNet-Bereich lesen.
• ARIN schloss den Vorschlag am 30. März 2026. Nach Prüfung anderer Abrufwerkzeuge und künftiger Entwicklungspläne sei eine Änderung der Berechtigungsprüfung damals nicht erforderlich gewesen. Die Antwort bestätigt nicht jeden gemeldeten Schritt, und Closed ist kein Auslieferungsnachweis.
• Die Asymmetrie hat einen starken Zweck: Der Empfänger einer detaillierten Zuweisung verwaltet den Datensatz, während der direkte Registrant das Rückholrecht behält. Öffentliche Whois/RDAP-Daten sind nicht mit einem authentifizierten NET Payload gleichzusetzen.
• Eine angemessene Kontrolle wäre eine redigierte Reclaim-Vorschau mit stabiler Identität, direkter Beziehung, Kindstatus, Wirkung, Ticketweg und Versionstoken sowie eine versionierte Matrix für Akteur, Beziehung, Objektklasse, Identifikatorweg, Verb, Feldsatz, Vorbedingung und Ergebnis.

Zugriffskontrolle wird häufig als Tabelle aus Objekten und Verben beschrieben. Im Registerbetrieb fehlen dann genau die Angaben, die eine Entscheidung sicher machen: Wer handelt in welcher Beziehung, über welchen Identifikator und mit welchem Informationsumfang?

Die ARIN-Anleitung zur Ressourcenverwaltung zeigt, warum diese Koordinaten notwendig sind. Eine einfache Reassignment gibt einem Kunden keine direkte Verwaltungsbefugnis. Eine Detailed Reassignment geht an eine Org, die den Datensatz direkt verwaltet. Der direkte Registrant behält Reclaim-Befugnis; bei Reverse DNS und IRR gibt es teilweise geteilte Zuständigkeiten. Eine Reallocation erlaubt weitere nachgelagerte Zuteilungen.

Diese Rollen dürfen nicht aus Bequemlichkeit eingeebnet werden. Das Rückholrecht des Elternakteurs dient einem anderen Zweck als die laufende Verwaltung durch den Empfänger. Würde DELETE automatisch vollständiges GET und PUT eröffnen, könnte der direkte Registrant Felder und Beziehungen kontrollieren, die gerade an die Empfänger-Org übergeben wurden.

Auch die Datenoberfläche ist nicht einheitlich. Der NET Payload kann Version, Kommentar, Registrierungsdatum, Org- oder Customer-Handle, Adressblock, Parent-Handle, Namen, Origin-AS-Werte und POC-Verweise enthalten. Öffentliche Registerausgaben dürfen einen Teil der Identität zeigen, ohne denselben Provisionierungsumfang offenzulegen.

Das Prinzip der geringsten Rechte spricht daher gegen eine universelle Verb-Hierarchie. Es spricht aber nicht gegen die Beobachtbarkeit einer bereits erlaubten, irreversiblen Handlung.

Ein gemeldeter Widerspruch mit klaren Beweisgrenzen

ACSP 2026.4 wurde am 3. März 2026 eingereicht. Der Autor beschrieb eine Detailed Reassignment aus einem eigenen NET an eine andere Org. Beim GET des Kind-NETs über dessen Handle sei der Schlüssel der Ausgangsorganisation wegen fehlender Berechtigung abgewiesen worden. Nur die Empfänger-Org habe diesen Abruf durchführen können.

Gleichzeitig erklärte der Einreicher, der Elternakteur könne das Kind löschen, über mostSpecificNet mit exaktem Start und Ende abrufen und öffentliche Angaben per Handle oder IP in Whois finden. Daraus leitete er die Forderung nach GET und PUT ab: Wer löschen und neu erzeugen könne, solle auch ändern dürfen.

ARIN folgte diesem Schluss nicht. Am 30. März teilte die Organisation mit, dass andere Wege zur Informationsbeschaffung mit bestehenden Werkzeugen sowie zukünftige Entwicklungspläne erörtert worden seien. Änderungen an den aktuellen API-Berechtigungen seien zu diesem Zeitpunkt unnötig. Der Vorschlag wurde mit Zustimmung des Einreichers geschlossen.

Die Seite belegt den Bericht und die Antwort. Sie ist kein Schwachstellenhinweis, kein Vorfallbericht und kein unabhängiger Versuch. ARIN bestätigt nicht ausdrücklich jede Reproduktionsstufe. Weder eine Fehl-Löschung noch eine Offenlegung oder Störung ist dokumentiert. Ebenso wenig darf behauptet werden, dass jedes heutige Konto und Objekt dieselbe Entscheidung erhält.

Der Fall bleibt relevant, weil die aktuelle Dokumentation die Pfade und Payloads beschreibt. Damit lässt sich prüfen, ob der beabsichtigte Vertrag vollständig genug ist, ohne das berichtete Verhalten als universelle Tatsache auszugeben.

Exakte Bereiche sind keine allgemeine Objektsuche

Der Reg-RWS-Methodenkatalog enthält GET /rest/net/NETHANDLE, GET /rest/net/mostSpecificNet/STARTIP/ENDIP, DELETE per Handle und PUT per Handle. Beide GET-Methoden liefern einen NET Payload, DELETE eine Ticketed Request Payload, PUT nimmt einen NET Payload an und liefert den geänderten Zustand.

Die Eingaben tragen verschiedene Semantik. Ein Handle ist die stabile Registeridentität. Ein exakter Bereich setzt voraus, dass der Aufrufer Start und Ende bereits kennt. Whois/RDAP ist wiederum eine öffentliche Auffindbarkeitsoberfläche.

ACSP 2023.13 macht die Begrenzung von mostSpecificNet anschaulich. Der genaue Start und das genaue Ende sind kein bequemer Bootstrap von einer beliebigen enthaltenen Adresse. Der Aufrufer muss die Grenzen besitzen. Ein korrekter lokaler Bestand kann damit bestätigt werden; ein veralteter Bestand lässt sich nicht zuverlässig aus sich selbst heraus korrigieren.

Für Menschen kann ARIN Online als zusätzlicher Such- und Bestätigungsschritt genügen. Automatisierung benötigt jedoch eine maschinenlesbare Antwort darauf, ob Handle, Bereich und Elternbeziehung zum Ausführungszeitpunkt noch zusammengehören.

Eine Löschung hat je nach Kindstruktur ein anderes Gewicht

DELETE gilt laut ARIN nur für Reassignments und Reallocations. Gibt es keine darunterliegenden NETs, kann die Verarbeitung automatisch erfolgen und Informationen über das gelöschte Netz zurückgeben. Gibt es untergeordnete Zuweisungen, entsteht ein Ticket; der Adressraum darf erst nach erfolgreicher Bearbeitung erneut vergeben werden.

Die Anleitung zur Löschung lässt den Nutzer das Netz suchen, sein Net Handle wählen und eine nicht rückgängig zu machende Aktion bestätigen. Identität und Kindstruktur sind also bereits Teil der Sicherheitslogik. Sie sollten nicht erst im Ergebnis sichtbar werden.

Beim Ändern eines NET empfiehlt ARIN, den aktuellen Datensatz vor PUT abzurufen. Das ist eine Aktualitätsvorbedingung. Für einen Reclaim-Akteur, der den vollständigen Payload nicht erhalten soll, fehlt lediglich die schmalere Form desselben Prinzips.

Die Löschvorschau als getrennte Fähigkeit

Eine Reclaim-Vorschau könnte bewusst weniger liefern als GET:

1. stabiles Handle und normalisierten Adressbereich;
2. NET-Klasse und direkte Elternbeziehung;
3. Empfängertyp ohne private Kontaktdaten;
4. Vorhandensein untergeordneter NETs;
5. automatische oder ticketbasierte Verarbeitung;
6. zusammengefasste Wirkung auf DNS, IRR und Routingobjekte;
7. geplante Benachrichtigungen und Auditnachweise;
8. ein kurzlebiges Versionstoken.

DELETE müsste dieses Token vorlegen. Haben sich Bereich, Hierarchie oder wesentliche Abhängigkeiten verändert, schlägt die Anfrage geschlossen fehl. Der Elternakteur erhält keine allgemeine Empfängerverwaltung. Er erhält die Mindestbeobachtung, die sein bestehendes Reclaim-Recht sicher ausführbar macht.

Daneben gehört eine öffentliche Capability-Matrix, deren Einheit lautet:

Akteursrolle × Beziehung × NET-Klasse × Identifikatorweg × Verb × Feldsatz × Vorbedingung × Ergebnis

Sie trennt einfache und detaillierte Reassignment sowie Reallocation, direkte Kinder und tiefere Nachkommen, Handles und Bereiche, vollständige und redigierte Ansichten, automatische Antworten und Tickets. Bewusste Asymmetrien erhalten Begründung, Version und Gültigkeitsdatum.

Das Ziel ist nicht Gleichheit. Das Ziel ist Testbarkeit. Die Empfänger-Org bekommt ihre Verwaltungsansicht. Der direkte Registrant erhält die Reclaim-Vorschau. Der einfache Kunde erhält keine Verwaltung. Die Reallocation folgt ihrem eigenen Modell. Integrationen können diese Erwartungen prüfen, bevor sie produktiv löschen.

Closed ist ein Prozessstatus

ARIN durfte bestehende Werkzeuge als ausreichend ansehen und Entwicklungskapazität anders priorisieren. Die Zustimmung des Einreichers zur Schließung gehört zur Faktenlage.

Doch der Status bestätigt weder alle Tests noch eine Implementierung. Er erklärt auch nicht, dass die Automatisierungsfrage dauerhaft erledigt sei. „Zu diesem Zeitpunkt“ begrenzt die Entscheidung zutreffend.

Wenn die gewünschte Regel lautet, dass der direkte Registrant reclaimen, aber keinen vollständigen Handle-Payload lesen darf, sollte dies in der Matrix stehen. Wenn exakter Bereich oder ARIN Online der vorgesehene Preflight ist, müssen Inventarannahmen und nachweisbare Felder genannt werden.

Eine gute Ablehnung schützt Daten und ist verständlich. Eine gute Erlaubnis schützt Zustände und ist überprüfbar. Die Empfänger-Org muss ihre Autonomie behalten; der Elternakteur darf beim Reclaim nicht blind werden. Das verbindende Element ist kein breiteres Recht, sondern ein engerer Vertrag.