Zusammenfassung

  • AFPUB-2012-DNS-001-DRAFT-01, eingereicht am 10. April 2012 von Tim McGinnis, wollte neue Reverse-DNS-Delegationen nur dann gewähren, wenn eine passende Zuweisung oder Unterzuteilung in der AFRINIC-Datenbank registriert war. Das war ein prospektiver Dienstleistungsfilter, keine Befugnis zur Bestrafung.
  • Abschnitt 3.3 begrenzte die unmittelbare Reichweite erheblich: Bereits vor einer möglichen Ratifizierung genehmigte Reverse-Delegationen sollten nicht entfernt werden. Entwurf 1 darf deshalb nicht mit späteren Fassungen oder einem rückwirkenden Entzugsmechanismus vermischt werden.
  • Der Entwurf erkannte den Wert genauer öffentlicher Zuständigkeitsdaten, definierte aber weder einen verlässlichen Test für falsche Negativbefunde noch eine begründete Ablehnung, eine feste Korrekturfrist, eine unabhängige Überprüfung oder einen schnellen Rollback bei einem Fehler auf Registerseite.
  • Reverse DNS kann für Adress-zu-Namen-Auflösung und für Systeme wichtig sein, die auf vorhandene oder konsistente PTR-Daten achten. Sein Fehlen stoppt jedoch nicht das IP-Routing und belegt weder einen Ausfall noch eine rechtswidrige, aufgegebene oder ungenutzte Adressnutzung.
  • AFRINIC darf als privater Registerführer und technischer Koordinator Einträge prüfen, Delegationsanträge authentifizieren, genaue Fehler benennen und Korrekturen koordinieren. Es ist aber kein Staat, Regulierer, Polizeiorgan, Strafkörper, Konfiskator oder Gericht. Technische Abhängigkeit erzeugt keine hoheitliche Gewalt.
  • Die belastbare Alternative wäre ein enges Validierungsverfahren: authentifizierte Mitteilung, Benennung des betroffenen Datenbankobjekts und der Reverse-Zone, nachvollziehbare Abgleichregeln, rasche Berichtigung, unabhängige Prüfung, Schutz des letzten verifizierten Betriebszustands und Verweisung echter Rechtsstreitigkeiten an ein zuständiges unabhängiges Forum.

Eine vernünftige Diagnose, ein unvollständiges Verfahren

Der Konflikt in „No Reverse Unless Assigned“ steckt nicht in der Einsicht, dass ein Register korrekt sein sollte. Wer eine öffentliche Datenbank über Internetnummern führt, muss damit rechnen, dass Netzbetreiber, Kunden und andere technische Akteure die darin enthaltenen Zuständigkeits- und Kontaktdaten verwenden. Eine Zuweisung, die operativ längst erfolgt ist, aber im Register nicht erscheint, verringert den Informationswert dieses Registers. Der erste Entwurf benannte deshalb kein eingebildetes Problem. Er fragte, wie Betreiber dazu bewegt werden könnten, nachgelagerte Zuweisungen und Unterzuteilungen zeitnah einzutragen.

Die Schwierigkeit lag in der gewählten Verbindung. Der Entwurf wollte einen neuen Reverse-DNS-Dienst nicht gewähren, wenn die entsprechende Registrierung fehlte. Damit wurde aus einer Lücke im Buch ein Kriterium für eine andere, operative Leistung. Dieser Schritt ist nicht automatisch unzulässig: Für eine Delegation, die AFRINIC auf seiner Seite der DNS-Hierarchie technisch konfigurieren muss, darf ein Registerdienst einen präzisen und überprüfbaren Nachweis verlangen. Wer eine Zone delegiert, muss wissen, welcher Bereich gemeint ist, ob der Antrag authentisch ist und wohin die Delegation zeigen soll.

Aber aus dieser engen Dienstleistungsprüfung folgt weder eine allgemeine Durchsetzungsgewalt noch das Recht, aus einem Datenbankbefund moralische, rechtliche oder eigentumsähnliche Schlüsse zu ziehen.

Genau an dieser Grenze blieb der Text dünn. Er sagte, wann die Dienstleistung verweigert werden sollte, aber nicht, wie AFRINIC zuverlässig feststellen sollte, dass der vorausgesetzte Eintrag wirklich fehlte. Er sagte nicht, welche Granularität ein passender Datensatz haben musste. Er bestimmte nicht, wie ein Betreiber nachweisen konnte, dass eine Aktualisierung bereits authentifiziert eingereicht worden war, aber noch verarbeitet wurde. Er sah keine begründete Entscheidung vor, in der der konkrete Datensatz und die konkrete Reverse-Zone genannt würden.

Und er schuf keinen unabhängigen Weg, um einen fehlerhaften Abgleich oder eine fehlerhafte Authentifizierung überprüfen zu lassen.

Diese Lücken sind mehr als juristische Zierde. Sie betreffen den Betrieb. Ein technischer Dienst, der von Daten aus einem anderen System abhängig gemacht wird, übernimmt dessen Fehler. Wenn die Datenbank verspätet ist, auf einer unerwarteten Ebene strukturiert wurde oder ein Antrag in Bearbeitung hängt, kann ein automatischer oder schematischer Negativbefund die Wirklichkeit falsch darstellen. Ohne einen definierten Korrekturweg wird die betroffene Organisation gezwungen, den Fehler selbst zu erraten, obwohl AFRINIC die Ablehnungslogik und die maßgeblichen Datensichten kontrolliert.

Ein guter Registerdienst muss diese Informationsasymmetrie verkleinern, nicht ausnutzen.

Was am 10. April 2012 tatsächlich vorgeschlagen wurde

Der historische Gegenstand ist eng. AFPUB-2012-DNS-001-DRAFT-01 wurde am 10. April 2012 von Tim McGinnis eingereicht und sollte AFPUB-2005-v4-001 ergänzen. Die bei AFRINIC-17 gezeigten Unterlagen bewahren Identität, Datum und die operativen Abschnitte 3.1 bis 3.3. Sie zeigen einen dreiteiligen Aufbau.

Erstens sah Abschnitt 3.1 vor, dass AFRINIC für von ihm verwalteten IP-Adressraum keine Reverse-Delegation mehr gewähren würde, wenn nicht eine Zuweisung oder Unterzuteilung dieses Adressraums angemessen in der AFRINIC-Datenbank registriert war. Entscheidend sind die Wörter „gewähren“ und die Voraussetzung eines Datenbankeintrags. Der Text zielte auf eine neue Delegationsanfrage. Er bewies weder, dass ein einzelner Betreiber Adressraum ungenutzt ließ, noch dass eine fehlende Registrierung eine illegale Nutzung darstellte.

Zweitens behandelte Abschnitt 3.2 bestehende Konstellationen anders. LIRs, für deren Allokationen Reverse DNS bereits bestand, aber keine Zuweisung oder Unterzuteilung registriert war, sollten kontaktiert werden. Als Kanäle waren MyAFRINIC und E-Mail vorgesehen; die konkrete Ausgestaltung blieb dem Sekretariat überlassen. Das ist eine Erinnerungskomponente, aber noch kein vollständiges Benachrichtigungsverfahren.

Ein Kanal sagt nichts darüber aus, welche Tatsachen eine Nachricht enthalten muss, wie der Empfang nachgewiesen wird, wann eine Antwort fällig ist, wie rasch eine Korrektur bearbeitet wird oder wer einen Streit über den Abgleich entscheidet.

Drittens setzte Abschnitt 3.3 eine wichtige Grenze. Reverse-Delegationen für LIR-Allokationen, die vor einer möglichen Ratifizierung genehmigt worden waren, sollten nicht entfernt werden. Betroffen sein sollten nur spätere Allokationen. Dieser Bestandsschutz reduzierte den unmittelbaren operativen Schadensradius. Er bewahrte den letzten funktionierenden Zustand der bereits bestehenden Delegationen und verhinderte, dass die vorgeschlagene Regel ohne Weiteres rückwärts in laufende Konfigurationen eingriff.

Diese drei Elemente müssen zusammen gelesen werden. Wer nur den Titel betrachtet, kann den Eindruck eines pauschalen Entzugs gewinnen. Wer nur Abschnitt 3.1 liest, übersieht die Schonung bestehender Delegationen. Wer Abschnitt 3.2 als vollwertiges Verfahren behandelt, verwechselt eine Erinnerung mit einem Recht auf nachvollziehbare Entscheidung und wirksame Korrektur. Der Entwurf war weder so umfassend wie eine allgemeine DNS-Sperrpolitik noch so abgesichert wie ein moderner, überprüfbarer Validierungsdienst.

Die spätere Fassung mit ihrem eigenen zeitlichen und verfahrensmäßigen Design ist ein gesonderter Gegenstand und darf nicht rückwirkend in Entwurf 1 hineingelesen werden. Ebenso wenig darf aus der Tatsache, dass das Dokument diskutiert und in offiziellen Unterlagen wiedergegeben wurde, auf Konsens, Ratifizierung oder Umsetzung geschlossen werden. Die dokumentierte Geschichte des Jahres 2012 sagt gerade etwas anderes: Die erfassten Beratungen endeten ohne Konsens.

Die Debatte in AFRINIC-16: Anreiz, Zweifel und offene Kosten

Am 18. Mai 2012 wurde Entwurf 1 bei AFRINIC-16 diskutiert. Der offizielle Bericht beschreibt McGinnis als Autor und als PDWG-Co-Vorsitzenden, der für diesen Tagesordnungspunkt die Co-Vorsitzendenrolle ablegte. Daraus lässt sich eine formale Rollenabgrenzung ablesen, nicht mehr. Sie belegt weder eine private Absicht noch Fehlverhalten und sollte nicht als Motivgeschichte überhöht werden.

Der Bericht schreibt dem Autor eine praktische Diagnose zu: Mehr als 60 Prozent der Internetdienstanbieter hätten Zuweisungen registriert, während annähernd 40 Prozent keine einzige Zuweisung registriert hätten. Diese Zahlen machten das Problem anschaulich. Doch sie sind keine veröffentlichte Messstudie. Der Bericht nennt weder Nenner noch Abfragezeitpunkt, Auswahlmethode, Datenbereinigung oder unabhängige Prüfung. Deshalb dürfen sie nur als zugeschriebene Größenordnung verwendet werden. Aus ihnen folgt nicht, dass vier von zehn beliebig ausgewählten Betreibern untätig, regelwidrig oder ohne legitime Nutzung waren.

Ebenso wenig lassen sie erkennen, ob ein fehlender Eintrag durch Arbeitsabläufe, Granularität, Verzögerung oder andere Registerfragen erklärt wurde.

Das vorgeschlagene Anreizproblem hatte einen nachvollziehbaren Hintergrund. In der Diskussion wurde eine bestehende Schwelle von 80 Prozent erwähnt: Ein Mitglied sollte bei einem späteren Antrag auf zusätzlichen Adressraum einen bestimmten Grad an Zuweisungs- beziehungsweise Registrierungsnachweisen zeigen. Der erste Entwurf wollte den Anreiz früher wirksam machen, nämlich dann, wenn ein Betreiber eine Reverse-Delegation benötigte, statt erst beim nächsten Ressourcenantrag.

Auch diese Logik ist zunächst institutionelle Ökonomie: Ein selten auftretender Prüfpunkt kann schwach wirken, während eine zeitnah benötigte Dienstleistung Verhalten schneller beeinflusst.

Aber gerade das Wort „Anreiz“ verlangt eine Grenzziehung. Ein Dienst kann eine sachlich notwendige Eingangsvoraussetzung haben. Wird er dagegen zurückgehalten, um eine getrennte Verwaltungspflicht zu erzwingen, obwohl die Leistung technisch sicher erbracht werden könnte, verwandelt er sich in Druck. Die Kernfrage lautet deshalb nicht, ob genaue Einträge wünschenswert sind. Sie lautet, ob der konkrete Eintrag für die konkrete Delegation erforderlich war und ob die Verweigerung auf einem verlässlichen, korrigierbaren Befund beruhte. Der Entwurf beantwortete diese Frage nicht mit der nötigen Präzision.

Teilnehmer stellten laut Bericht die Wirksamkeit der Maßnahme infrage. Sie merkten an, dass das Internet ohne Reverse DNS funktionieren könne, fragten nach der Durchsetzbarkeit und warfen die zusätzliche Arbeitsbelastung für AFRINIC-Mitarbeiter auf. Auch die Idee eines Port-Scannings und die Frage, ob hierfür die Einwilligung der Betreiber nötig wäre, kamen zur Sprache. Diese Wortmeldungen sind keine angenommenen Feststellungen. Sie zeigen aber, dass die Debatte bereits die richtige Trennlinie berührte: zwischen einem Registereintrag, einer technischen Abhängigkeit und einer weitergehenden Kontrolle über Netze.

Das dokumentierte Ergebnis war kein Konsens; der Vorschlag ging zurück an die Mailingliste. Ende November 2012 bezeichneten die AFRINIC-17-Unterlagen Entwurf 1 noch als aktuelle Fassung und reproduzierten seine Bestimmungen. Der Jahresbericht führte ihn unter den 2012 diskutierten Vorschlägen und hielt fest, dass die bei AFRINIC-17 behandelten Vorschläge keinen Konsens erreichten. Diese Quellen belegen den Ablauf innerhalb einer privaten Policy-Umgebung. Sie verwandeln das Verfahren nicht in Gesetzgebung und seine Teilnehmer nicht in eine souveräne Repräsentation aller betroffenen Betreiber.

Reverse DNS: bedeutsam, aber nicht gleich Routing

Für die Fehleranalyse reicht eine schmale technische Erklärung. Im IPv4-Reverse-DNS werden Bereiche unter IN-ADDR.ARPA delegiert. PTR-Einträge ermöglichen die Abbildung einer Adresse auf einen Namen. Damit verläuft die Anfrage in der entgegengesetzten Richtung zur geläufigen Namensauflösung: Nicht ein Name wird auf eine Adresse abgebildet, sondern für eine Adresse wird nach einem zugeordneten Namen gefragt. RFC 1035 beschreibt die PTR-Datensätze und den dafür vorgesehenen Namensraum.

Eine parent-seitige Delegation ist dabei eine reale betriebliche Abhängigkeit. Wenn eine Organisation die maßgebliche untergeordnete Zone betreiben will, muss die übergeordnete Seite die Delegation korrekt veröffentlichen. AFRINIC kann in dem von ihm koordinierten Bereich deshalb eine technische Handlung ausführen, die ein Antragsteller nicht einseitig ersetzen kann. Gerade diese Abhängigkeit macht Präzision nötig. Sie macht AFRINIC aber nicht zum Regulierer. Kontrolle über einen Koordinationspunkt ist eine technische Stellung, keine hoheitliche Kompetenz.

RFC 1912 beschreibt häufige DNS-Konfigurationsfehler, empfiehlt passende PTR- und A-Einträge für Hosts und warnt vor Zugangs- oder Dienstproblemen, wenn Reverse-Zuordnungen fehlen oder nicht konsistent sind. Daraus folgt ein legitimes Kontinuitätsinteresse. Systeme können PTR-Präsenz oder die Übereinstimmung von Vorwärts- und Rückwärtsdaten als Signal verwenden. Ein fehlender oder widersprüchlicher Eintrag kann deshalb einzelne Abläufe beeinträchtigen.

Was daraus ausdrücklich nicht folgt, ist ebenso wichtig. IP-Pakete benötigen keinen PTR-Eintrag, um geroutet zu werden. Fehlendes Reverse DNS stoppt das Routing nicht. Die versiegelte historische Überlieferung weist auch keinen konkreten Ausfall, keinen gescheiterten Mailfluss, keinen benannten Kundenverlust und keine tatsächlich unter Entwurf 1 abgelehnte Delegationsanfrage nach. Es wäre daher falsch, die operative Bedeutung mit einem universellen Ausfallrisiko gleichzusetzen oder einen nicht dokumentierten Schaden zu erfinden.

Die richtige Formulierung liegt zwischen Verharmlosung und Dramatisierung. Reverse DNS ist kein bloßes Schmuckfeld. Es kann für Verantwortungszuordnung, Diagnose und dienstspezifische Prüfungen wertvoll sein. Es ist zugleich nicht die Grundlage des Routings und kein allgemeiner Nachweis darüber, wer Adressraum rechtmäßig nutzt. Diese begrenzte Funktion muss auch die Reichweite jeder Registerprüfung begrenzen.

Ein Datenbankeintrag ist ein Befund, kein Urteil

Der Entwurf bezeichnete sich unter Bezug auf die damalige Policy als „enforcement mechanism“. Historisch ist diese Selbstbeschreibung relevant. Analytisch darf sie nicht als Beleg für eine Durchsetzungsgewalt übernommen werden. AFRINIC führt als private Organisation Register- und Koordinationsaufgaben aus. Es kann dokumentieren, welche Daten in seinem System vorhanden sind, und es kann für eine von ihm zu konfigurierende Dienstleistung technische Voraussetzungen prüfen. Es besitzt dadurch keine Befugnis, Regelverstöße hoheitlich festzustellen, Strafen zu verhängen, Ressourcen zu konfiszieren oder Rechtsansprüche endgültig zu entscheiden.

Diese Unterscheidung schützt zugleich die Genauigkeit des Registers. Wird ein Datenbankfeld als unanfechtbare Wahrheit behandelt, sinkt die Bereitschaft, seine Fehlerquellen offenzulegen. Ein seriöses Register muss Einträge als qualifizierte, überprüfbare Aufzeichnungen behandeln: wertvoll, aber korrigierbar. Ein fehlendes Objekt sagt zunächst nur, dass die erwartete Repräsentation an der erwarteten Stelle nicht gefunden wurde. Es sagt nicht, ob der operative Sachverhalt fehlt.

Mehrere falsche Negativzustände sind denkbar, ohne dass einer davon für einen konkreten Betreiber behauptet werden darf. Eine authentifizierte Aktualisierung könnte eingereicht, aber noch nicht verarbeitet sein. Ein Datensatz könnte auf einer anderen Granularität liegen, als die Prüflogik erwartet. Eine gültige Unterzuteilung könnte vorhanden sein, aber wegen eines Zuordnungsfehlers nicht mit der angefragten Reverse-Zone verknüpft werden. Oder ein Mitarbeiter könnte den falschen Bereich prüfen. Diese Möglichkeiten sind keine historischen Feststellungen über AFRINICs Betrieb 2012.

Sie sind die elementaren Fehlermodi, die ein Verfahren ausschließen oder beherrschen muss, bevor es aus einem Registerabgleich eine operative Folge zieht.

Der Begriff „angemessen registriert“ trägt die gesamte Last, ohne sie aufzulösen. Welche Felder mussten vorhanden sein? Welcher Zustand galt als vollständig? Wie wurde der Adressbereich gegen die Zone abgeglichen? Welche Ebene der Zuweisung oder Unterzuteilung genügte? Der erste Entwurf enthält keine spätere, spezifischere Schwelle, die ihm nachträglich zugeschrieben werden dürfte. Diese Unbestimmtheit ist besonders bedeutsam, weil die Konsequenz binär war: neue Delegation ja oder nein.

Eine datengetriebene Entscheidung braucht deshalb zwei getrennte Aussagen. Aussage eins lautet: „In der Datenbank wurde unter den veröffentlichten Abgleichregeln kein passendes Objekt gefunden.“ Aussage zwei lautet: „Darum kann die konkret beantragte Delegation derzeit nicht sicher eingerichtet werden.“ Zwischen beiden liegt der Begründungsweg. Nur wenn dieser Weg offengelegt wird, kann der Antragsteller zeigen, dass die Datenlage falsch, verspätet oder missverstanden ist. Wer beide Aussagen verschmilzt, macht aus einem veränderlichen Verwaltungsbefund eine scheinbar endgültige Entscheidung.

Der Bestandsschutz war die stärkste Bremse des Entwurfs

Abschnitt 3.3 verdient mehr Aufmerksamkeit, als der zugespitzte Titel gewöhnlich erhält. Der Entwurf schlug ausdrücklich nicht vor, bereits vor der Ratifizierung genehmigte Reverse-Delegationen zu entfernen. Nur spätere Allokationen sollten von der Regel betroffen sein. Diese Entscheidung schützte laufende DNS-Konfigurationen vor einem rückwirkenden Eingriff und hielt den unmittelbaren Wirkungsbereich klein.

Aus Sicht der Betriebskontinuität war das vernünftig. Ein vorhandener, verifizierter Zustand ist nicht unfehlbar, aber er hat einen wichtigen Vorteil: Er funktioniert bereits. Wer ihn verändert, führt ein neues Risiko ein. Wenn die zugrunde liegende Streitfrage nur lautet, ob ein nachgelagerter Registereintrag vollständig ist, besteht regelmäßig kein Grund, eine bestehende Delegation während der Korrektur dieses Eintrags anzutasten. Das Buch kann bereinigt werden, ohne den Namensdienst als Hebel einzusetzen.

Der Bestandsschutz beantwortete allerdings nur eine von zwei Risikofragen. Er verhinderte den Entzug alter Delegationen. Er half nicht dem Antragsteller, dessen neue Delegation aufgrund eines fehlerhaften Datenbankabgleichs abgelehnt worden wäre. Für diesen Fall fehlten weiterhin präzise Gründe, ein Dienstziel für die Korrektur, eine unabhängige Prüfung und ein Rollback. Ein prospektiver Fehler kann wirtschaftlich und betrieblich relevant sein, auch wenn er keinen bereits laufenden Dienst abschaltet.

Die richtige Bewertung ist deshalb weder Lob noch Verdammung im Ganzen. Abschnitt 3.3 war eine materielle Begrenzung und muss als solche anerkannt werden. Er zeigt, dass Entwurf 1 Kontinuität zumindest teilweise berücksichtigte. Doch gerade weil der Text bestehende Zustände schützen konnte, fällt auf, dass er den gleichen Gedanken nicht zu einer allgemeinen Fehlerbehebungsarchitektur ausbaute. Der Schutz des letzten verifizierten Zustands hätte zum Leitprinzip werden können: alte Delegationen bewahren, neue Anfragen mit transparenter Vorabvalidierung prüfen und jeden fehlerhaften Negativbefund rasch aufheben.

Warum offizielle Dokumentation keine Autorität erzeugt

Die zentralen historischen Tatsachen stammen aus offiziellen AFRINIC-Unterlagen: dem Bericht zu AFRINIC-16, den bei AFRINIC-17 verwendeten Policy-Folien und dem Jahresbericht 2012. Diese Dokumente sind die richtige Grundlage für Datum, Wortlaut, zugeschriebene Äußerungen und Prozessstand. Sie sagen, was die Institution veröffentlichte und wie sie ihre Sitzungen zusammenfasste.

Ihre Beweiskraft endet dort, wo die institutionelle Selbstdokumentation zur Quelle ihrer eigenen Legitimität gemacht würde. Ein Protokoll kann belegen, dass eine Diskussion stattfand. Es kann nicht allein beweisen, dass alle Betroffenen repräsentiert waren oder dass die private Gruppe öffentliche Gewalt besaß. Eine Folie kann den Text eines Vorschlags bewahren. Sie kann nicht durch ihre amtlich wirkende Form aus einem Vorschlag eine rechtmäßige Strafbefugnis machen. Ein Jahresbericht kann „kein Konsens“ festhalten. Auch ein behaupteter Konsens hätte jedoch keine Souveränität erzeugt.

Das ist keine Geringschätzung der Dokumente. Im Gegenteil: Klare Beweisgrenzen machen ihren historischen Wert erst belastbar. Die offizielle Überlieferung wird verwendet, um Handlungen und Worte zuzuschreiben, nicht um ihre Richtigkeit oder Weisheit automatisch zu bestätigen. Dasselbe gilt für die Prozentangaben: Der Bericht belegt, dass sie dem Autor zugeschrieben wurden. Ohne Rohabfrage und Methodik belegt er nicht, dass die Zahlen unabhängig verifiziert waren.

Ebenso muss das spätere analytische Material sauber eingeordnet werden. Die Arbeiten von Heng Lu, LARUS und BTW liefern die kontrollierende Lehre über private Registermacht, Kontinuität, begründete Mitteilung und überprüfbare Korrektur. Sie belegen nicht nachträglich, dass Entwurf 1 umgesetzt wurde oder einen konkreten Schaden verursachte. Historie und Normprüfung ergänzen einander, dürfen aber nicht ineinander kollabieren: Die Primärunterlagen sagen, was 2012 vorgeschlagen und diskutiert wurde; die Kontinuitäts- und Autoritätsanalyse zeigt, welche institutionellen Sicherungen ein solches Design benötigt.

Die schmale legitime Rolle eines Registers

Eine belastbare Kritik an Registerübergriff darf die Registerfunktion nicht leugnen. AFRINIC koordiniert und dokumentiert Internetnummernressourcen und bietet Dienste an, deren verlässlicher Betrieb genaue Datensätze verlangt. Für eine neue Reverse-Delegation kann eine private Registerstelle daher mehrere legitime Schritte ausführen.

Sie kann zunächst den Antrag authentifizieren. Das schützt vor unbefugten Änderungen und klärt, wer für den betreffenden Bereich handeln darf. Sie kann dann den konkreten Adressraum und die betroffene Reverse-Zone bestimmen. Sie kann prüfen, ob die für die Delegation benötigten Zuordnungs- und Kontaktdaten in ihrem Register vorhanden und intern konsistent sind. Findet sie eine Lücke, kann sie diese genau benennen, eine Korrektur anfordern, die eingereichten Belege verifizieren und die Änderungshistorie sichern.

Schließlich kann sie die technische Delegation einrichten oder eine vorläufige, sachlich begründete Entscheidung treffen, die innerhalb der Registerdienstleistung überprüfbar bleibt.

Diese Rolle ist „dünn“, weil sie funktional begrenzt ist. Sie reicht bis zur sicheren und genauen Erbringung der Register- und Delegationsleistung, nicht darüber hinaus. AFRINIC darf einen fehlenden Datensatz nicht als Urteil darüber behandeln, ob eine Organisation ihr Netz rechtmäßig betreibt. Es darf Schweigen nicht als Aufgabe von Rechten auslegen. Es darf eine Dienstanfrage nicht in ein Verfahren zur Konfiskation verwandeln. Und es darf einen Streit über den rechtlichen Anspruch auf Ressourcen nicht selbst endgültig entscheiden, wenn dieser Streit eine unabhängige zuständige Instanz verlangt.

Die technische Stellung ändert daran nichts. Wer einen übergeordneten DNS-Knoten koordiniert, kann faktisch großen Einfluss besitzen. Je größer diese Abhängigkeit, desto stärker müssen Nachvollziehbarkeit und Reversibilität sein. Macht als technische Tatsache ist ein Grund für Verfahrensschutz, kein Ersatz für rechtliche Autorität.

Diese Perspektive löst auch den scheinbaren Widerspruch zwischen Genauigkeit und Freiheit auf. Ein schwaches Register ist nicht das Ziel. Das Ziel ist ein starkes, genaues und belastbares Buch bei schmaler Macht des Buchführers. Die Daten sollen verlässlich genug sein, dass Betreiber sie nutzen können. Der Registerführer soll zugleich nicht über den Inhalt seiner Aufzeichnungen hinaus zum Richter über Rechte und Verhalten werden. Kontinuität des Ledgers und Begrenzung des Gatekeepers gehören zusammen.