Bei ARIN bestimmt der Ursprungsblock die Reverse-DNS-Verwaltung

Zusammenfassung

• ARIN richtet die Reverse-DNS-Delegationen nach den CIDR-Bestandteilen einer direkten Zuteilung aus. Das dokumentierte /23 ergibt zwei getrennt verwaltbare /24-Delegationen; ein /16 ergibt eine Delegation auf /16-Ebene.
• Die Ausnahme von der gemeinsamen Verwaltung hängt am vorgelagerten Adressblock des ISP. Sie ist kein Verbot, innerhalb des DNS eine untergeordnete Zone zu delegieren; diese Übergabe muss der Betreiber der Elternzone organisieren.

Die größere Zuteilung hat nicht mehr Schalter

Wer mehr Adressen erhält, bekommt bei ARIN nicht zwangsläufig mehr einzeln bearbeitbare Reverse-DNS-Delegationen. Die Dokumentation zum Reverse-DNS stellt zwei Fälle gegenüber: Für eine direkte /23-Zuteilung entstehen zwei /24-Delegationen. Deren Nameserver lassen sich getrennt verwalten. Eine /16-Zuteilung erhält dagegen eine /16-Delegation, deren Nameserver auf dieser Ebene verwaltet werden.

Das ist keine Rechenpanne. ARIN erzeugt für jeden CIDR-Bestandteil einer Direct Allocation, also einer direkten Zuteilung, die größtmöglichen unterstützten Delegationen. Bei IPv4 liegen die unterstützten Grenzen bei /8, /16 und /24; /24 ist die kleinste unterstützte Größe. Ein /23 liegt zwischen diesen Grenzen und wird deshalb durch zwei /24 abgedeckt. Ein /16 trifft eine Grenze genau.

Der Unterschied betrifft die Aufteilung der Verwaltungsobjekte, nicht einen pauschalen Verlust an Kontrolle für den Inhaber des größeren Blocks. Seine einzelne Delegation umfasst mehr Adressen. Ebenso wenig richtet sich die dokumentierte Regel nach jedem später eingetragenen Kundennetz oder nach irgendeinem darüberliegenden Aggregat. Entscheidend sind die Bestandteile der direkten Zuteilung. Diese Herkunft kann aus dem Präfix, das ein Kunde auf seiner Auftragsbestätigung sieht, allein nicht abgelesen werden.

Für IPv6 beschreibt ARIN Grenzen von jeweils vier Bit. Die im Folgenden relevante /16-Ausnahme gehört zum IPv4-Modell. Wer aus ihr eine allgemeine Aussage über die Rechte aller indirekten Ressourceninhaber macht, dehnt die Quelle über ihren Gegenstand hinaus aus.

Ein /24-Kunde innerhalb eines /16

Nehmen wir einen ausdrücklich hypothetischen Fall: Ein Unternehmen erhält von seinem Internetanbieter ein /24 aus dessen /16 und möchte die zugehörigen Reverse-DNS-Daten selbst betreiben. Der Wunsch ist eng begrenzt. Daraus folgt aber noch nicht, dass im Register eine ebenso eng begrenzte Delegation zur Bearbeitung bereitsteht.

ARIN sieht eine gemeinsame Verwaltung durch berechtigte direkte und indirekte Ressourceninhaber vor. Eine bei der betreffenden Zone angezeigte autorisierte Organisation kann an der Verwaltung für die ihr delegierten Adressen beteiligt sein. Die Reverse-DNS-Dokumentation nennt jedoch eine ausdrückliche Ausnahme: Bei einer Weiterzuweisung oder Weiterzuteilung aus dem /16- oder größeren Adressblock eines ISP steht diese gemeinsame Verwaltung nicht zur Verfügung.

Das Wort „aus“ trägt hier die Bedingung. Die Ausnahme betrifft nicht nur Kunden, die selbst ein vollständiges /16 erhalten. Im Beispiel bleibt das /24 Teil einer Weitergabe aus dem /16 des Anbieters. „Größer“ meint dabei mehr Adressen, also einen numerisch kürzeren Präfix, nicht eine höhere Zahl hinter dem Schrägstrich.

Damit trennen sich zwei Vorgänge, die in einer allgemeinen Zusage zur Netzverwaltung ähnlich klingen können. Die Anleitung zur Pflege von Ressourcenregistern erlaubt über eine Netzänderung die Bearbeitung von Name, Kontakten und öffentlichen Kommentaren, nicht jedoch die Änderung der Reverse-DNS-Delegation. Allgemeine Erläuterungen zur gemeinsamen Ressourcenverwaltung sind deshalb zusammen mit der spezielleren DNS-Bedingung zu lesen. Unterschiedliche Bearbeitungsgegenstände sind noch kein Widerspruch zwischen den Dokumenten.

Die Verbindung zwischen Registereintrag und Recht hat auch ein dokumentiertes Ende. ARIN weist ISP an, bei nicht mehr angeschlossenen Kunden den Weiterzuweisungs- oder Weiterzuteilungseintrag zu entfernen, um die gemeinsame Berechtigung zu entziehen. Das beschreibt einen Lebenszyklus. Es belegt weder verwaiste Rechte bei einem bestimmten Anbieter noch erlaubt es, die Einträge aktiver Kunden zu entfernen, nur um die Berechtigungsverwaltung zu vereinfachen.

Diese Untersuchung hat keinen Kundenaccount geprüft. Sie zeigt daher keinen konkret gescheiterten Änderungsversuch und keine Häufigkeit solcher Probleme. Sie zeigt eine Bedingung, die vor der Zusage eigenständiger Verwaltung geklärt werden sollte.

Der DNS-Betreiber kann feiner aufteilen

Fehlt die getrennte Bearbeitungsmöglichkeit im Register, folgt daraus nicht, dass das Kundennetz technisch ohne eigene DNS-Verwaltung bleiben muss. Die nächste Zuständigkeit kann beim Betreiber der tatsächlichen Elternzone liegen.

RFC 1034 beschreibt die hierarchische Aufteilung des DNS in Zonen. Ein Zonenbetreiber kann Unterzonen delegieren. Auf der Elternseite müssen die nötigen NS-Einträge und gegebenenfalls Glue-Daten stehen; die Angaben auf beiden Seiten der Zonengrenze müssen zusammenpassen. Der ISP oder sein DNS-Dienstleister kann so eine untergeordnete Zone an den Kunden übergeben, ohne dessen Zugriff auf den ARIN-Account oder auf die gesamte /16-Delegation auszuweiten.

Ein gewöhnliches /24 unter einem /16 benötigt dafür eine gewöhnliche DNS-Unterdelegation. Der Kunde kann dann die Daten innerhalb seiner Zone verwalten. Die Verbindung zur Elternzone bleibt trotzdem eine Aufgabe: Ändern sich die dafür maßgeblichen Nameserver, muss der zuständige Betreiber den Übergang pflegen können. Selbstverwaltung innerhalb einer Zone ist nicht gleichbedeutend mit völliger Unabhängigkeit von ihrem Elternbereich.

Auch die Verfügbarkeit des Dienstes ist eine eigene Frage. Aus dem Protokoll lässt sich nicht ableiten, dass ein bestimmter ISP diese Übergabe anbietet, automatisiert oder unterstützt. Eine fehlende Registerfunktion ist kein Protokollverbot; eine Protokollmöglichkeit ist kein Leistungsversprechen.

Für weniger als 256 IPv4-Adressen beschreibt RFC 2317 eine andere Konstruktion mit zusätzlichen delegierten Namen und CNAME-Verweisen. Der bestehende DNS-Abfragemechanismus bleibt erhalten, ebenso die Abhängigkeit vom Elternbereich. Daraus ergibt sich weder eine freie Erzeugung beliebiger /25-Delegationen bei ARIN noch die Notwendigkeit, diese Technik für jedes Kundennetz einzusetzen. Gerade das normale /24 unter einem /16 darf nicht mit dem kleineren, klassenlosen Fall vermischt werden.

Die institutionelle und die technische Grenze erfüllen damit verschiedene Aufgaben. ARIN verwaltet eine bestimmte Delegation. Der Betreiber dieser Zone kann darunter eine feinere Arbeitsteilung einrichten. Ob sie eingerichtet wurde und wer sie betreut, muss am konkreten Dienst geklärt werden; der Ressourcenregistereintrag erledigt das nicht stellvertretend.

Die Auswahl bestimmt die Reichweite

Auch die Reg-RWS-Methoden behandeln Netz und Delegation als unterschiedliche Gegenstände. Delegationsobjekte entstehen und verschwinden mit den zugehörigen Netzen, nicht durch eigenständiges Anlegen oder Löschen. Sie werden durch ihren Delegationsnamen identifiziert, nicht durch einen NET-Handle. Die Dokumentation sieht das Abrufen der zu einem NET gehörenden Delegationen und ihres aktuellen Zustands vor einer Änderung vor. Das ist ein dokumentierter Ablauf, kein Ergebnis eines hier ausgeführten Provisionierungsversuchs.

Im Portal zeigt die Anleitung zur DNS-Verwaltung die vorhandenen Reverse-Zonen, Nameserver, DS-Schlüsselkennungen und Organisationen mit gemeinsamer Berechtigung. Eine Nameserveränderung ersetzt die bisherigen Werte für sämtliche ausgewählten Delegationen. Die Bezeichnung „Änderung für Kunde /24“ verkleinert eine umfassendere Auswahl nicht.

Für ein leeres TTL-Feld nennt ARIN 86.400 Sekunden als Standard. Änderungen an der Datenbank erfolgen laut Anleitung unmittelbar, die Sichtbarkeit im DNS kann bis zu 24 Stunden benötigen. Das ist weder eine hier gemessene Unterbrechung noch eine universelle Zusage zum gleichzeitigen Ablauf aller Caches. Für diese Analyse ist entscheidend, dass Speichern, Reichweite und Überprüfung des Ergebnisses getrennte Fragen bleiben.

Die am 3. September 2026 vorliegenden Quellen erklären somit ein Verwaltungsmodell. Sie belegen keine Kundenmigration, keinen Ausfall, keine verweigerte Berechtigung und keine Kosten. Ein korrekter PTR-Eintrag beweist im Übrigen weder Routing noch Eigentum oder eine vollständige Identität. Die nützliche Frage ist enger: Welche Zone muss für diese Adressen geändert werden, und wer kann den dazugehörigen Übergang tatsächlich bedienen?