Zusammenfassung

  • Richard Laager berichtete in ARIN-Vorschlag 2026.4: Nach einer detaillierten Neu-Zuweisung aus seinem NET an eine andere Organisation scheiterte der Handle-GET des Kind-NET mit seinem API-Schlüssel. Derselbe Elternteil konnte das Kind löschen und über mostSpecificNet anhand der Adressen abrufen; der Schlüssel der empfangenden Org schaffte den Handle-GET.
  • ARIN erklärte am 30. März 2026, vorhandene Abrufwerkzeuge und künftige Entwicklungspläne machten eine Änderung der aktuellen API-Berechtigungen unnötig. Mit Laagers Zustimmung wurde der Vorschlag geschlossen.

Der Datensatz hatte einen Namen. Ausgerechnet über diesen Namen durfte sein Erzeuger ihn nicht lesen. Richard Laager schilderte den Ablauf in ARIN-Vorschlag 2026.4: Er wies einen Teil seines NET detailliert einer anderen Organisation zu, nahm den API-Schlüssel des Mutter-Netzes und rief das entstandene Kind-NET anhand seines Handles ab. Die Antwort lautete „keine Berechtigung“. Nach seiner Darstellung konnte er den Eintrag mit demselben Mutter-Verhältnis löschen und über Start- und Endadresse mit mostSpecificNet finden. Im öffentlichen Whois standen die Informationen sogar ohne Anmeldung.

Eine detaillierte Neu-Zuweisung schafft zwei berechtigte Beteiligte. Laut ARINs Ressourcenführer erhält die empfangende Organisation mit eigener Org ID die Möglichkeit, die zugewiesenen Adressen zu verwalten. Der direkte Registrant behält das Recht, die Neu-Zuweisung zurückzuholen. Für IRR-Objekte und Reverse DNS beschreibt ARIN eine gemeinsame Verwaltung. Aus dieser Beziehung folgt jedoch kein einheitlicher Freibrief für jedes NET-Feld. Laagers Fall betrifft zunächst die schlichte Frage, ob der Mutter-Schlüssel das eigene Kind unter dessen Identifikator lesen darf.

Die vier von ihm beschriebenen Abrufwege trennen das Problem scharf. Der Schlüssel der empfangenden Org bekam das Kind per Handle. Der Mutter-Schlüssel wurde dort abgewiesen. Mit Start- und Endadresse fand der Mutter-Schlüssel über mostSpecificNet den Eintrag. Anonyme Whois-Nutzer sahen dieselben öffentlichen Daten per Handle oder Adresse. Das Objekt war nicht verborgen. Die Kombination aus Kontobeziehung und genauer API-Adresse entschied über den Erfolg.

Die Reg-RWS-Dokumentation führt dafür getrennte Methoden auf. GET /rest/net/NETHANDLE liefert einen NET-Datensatz. GET /rest/net/mostSpecificNet/STARTIP/ENDIP sucht für einen Bereich den spezifischsten NET-Eintrag. DELETE /rest/net/NETHANDLE stößt eine ticketbasierte Entfernung einer Neu-Zuweisung oder Weiterverteilung an; direkte Zuweisungen verschwinden nicht auf diesem Weg. PUT /rest/net/NETHANDLE verändert einen Eintrag mit übermittelten Daten. Eine Anwendung, die bei der Anlage ein Handle speichert, muss wissen, dass eine funktionierende Bereichssuche ihr den Handle-GET nicht ersetzt.

Der Mehraufwand ist leicht zu übersehen. Das Provisionierungssystem legt den Kind-Handle in seiner Datenbank ab. Beim nächsten Abgleich will es diesen Handle lesen und den Sollzustand mit dem ARIN-Eintrag vergleichen. Wird der direkte GET verweigert, braucht das System zusätzlich die Adressgrenzen, einen zweiten Aufruf und eine Prüfung, ob dessen Antwort wirklich Handle, Mutter-Netz, Bereich und empfangende Org des ursprünglichen Kindes enthält. Whois hilft dem Menschen, liefert aber einen anderen Beleg als der authentifizierte Reg-RWS-Aufruf.

Dass DELETE möglich sein soll, macht Löschen und Neuanlegen zu einer besonders schlechten Ausweichidee. Ein Lesefehler ist kein Grund, die Registrierung des Kunden umzubauen.

Laager beantragte eine breitere Freigabe des GET. Außerdem meinte er, wer ein direktes Kind löschen und neu anlegen könne, solle es per PUT ändern dürfen. Der zweite Schritt betrifft andere Risiken. Eine NET-Änderung kann Netzwerkname, POC-Handles und öffentliche Kommentare betreffen. Das Schreiben solcher Felder ist etwas anderes als das Abrufen öffentlich sichtbarer Daten. ARIN übernahm weder die GET- noch die PUT-Erweiterung in seiner Antwort.

Am 30. März teilte ARIN mit, andere bestehende Wege zum Abruf der Daten und zukünftige Pläne seien geprüft worden. Änderungen der derzeitigen API-Berechtigungen seien zu diesem Zeitpunkt nicht nötig. Laager stimmte der Schließung zu. Eine Reparatur des Handle-GET kündigte ARIN nicht an. Die Produktentscheidung lässt die Umleitung auf andere Abrufwege beim Nutzer.

Ein heutiger Produktionsmitschnitt mit beiden Organisationsschlüsseln und den dokumentierten Methoden würde zeigen, ob die von Laager gemeldete Ablehnung nach März fortbesteht. Der öffentliche Vorgang belegt seine Reproduktionsfolge und ARINs Entscheidung. Für Betreiber entsteht daraus bereits eine klare Pflicht: Ein abgewiesener Handle-GET ist ein Berechtigungszustand, kein Beweis dafür, dass das Kind-NET verschwunden ist.

Die Registry führt eine Identität für den Eintrag; ihre API legt mehrere Türen davor. ARIN hat die Türordnung beibehalten. Wer viele detaillierte Neu-Zuweisungen automatisiert, muss sich merken, welche Tür sich mit welchem Schlüssel öffnet, obwohl alle auf denselben Datensatz zeigen.

Vorschlag und ARIN-Antwort · Reg-RWS-Methoden · Ressourcenverwaltung · NET-Änderungen