Zusammenfassung

  • Draft 2 behielt den engen technischen Endzustand von Draft 1 bei, strich aber dessen sichtbare Verfahrenshülle. Aus konkreten Angaben zu wiederholten Prüfungen, mehreren Kontaktrollen, Benachrichtigungen, zonenbezogener Entfernung, Archiv und Wiederherstellung wurden offene Begriffe wie Feststellung der Lähmung, angemessene Kontaktversuche und angemessene Aufbewahrungsdauer.
  • Die späteren Abläufe von 2018 und 2021 zeigen, dass AFRINIC Schutzvorkehrungen technisch ausarbeiten konnte. Sie beweisen jedoch nicht, dass Monats- oder Tagestakte, mehrere Messorte, vier Hinweise oder eine Dreißigtagefrist bereits am 22. November 2017 Bestandteil des verbindlichen Draft 2 waren.
  • Ein privates, mitgliedschaftlich organisiertes technisches Register darf einen nachweislich unbrauchbaren Reverse-DNS-Verweis korrigieren. Es erhält dadurch keine hoheitliche, regulatorische oder strafende Gewalt. Beweise, Hinweis, Heilung, Überprüfung und schnelle Wiederherstellung müssen am konkreten Zonendefekt hängen und von Mitgliedsstatus, Abrechnung, Transfers, Leasing oder sonstigen Streitigkeiten getrennt bleiben.
  • Die richtige Antwort ist nicht, jede technische Einzelheit dauerhaft in Policy-Text einzufrieren. Erforderlich ist vielmehr ein veröffentlichter, versionierter und überprüfbarer Mindeststandard, innerhalb dessen das Personal Messverfahren weiterentwickeln kann, ohne die entscheidende Eingriffsschwelle unsichtbar zu verändern.

L3 — Was Draft 2 behielt und was er dem Personal überließ

Eine lahme Delegation ist kein abstrakter Schönheitsfehler in einer Datenbank. Der übergeordnete Reverse-DNS-Baum verweist einen anfragenden Resolver auf einen Server, der nicht erreichbar ist, nicht antwortet oder für die Zone keine autoritative Antwort geben kann. Der Resolver versucht es dennoch. Er wartet, wiederholt oder befragt weitere eingetragene Server. Das Ergebnis kann ebenso informationslos sein wie bei einer fehlenden Delegation, doch der Weg dorthin ist länger und arbeitsintensiver. Ein ehrlicher negativer Zustand im übergeordneten Datensatz kann deshalb besser sein als ein Versprechen, das technisch nicht eingelöst wird.

Diese Differenz trägt den stärksten sachlichen Fall für eine Bereinigung: Das Register soll die beobachtbare Betriebswirklichkeit abbilden, nicht eine kaputte Verweisung konservieren.

Draft 1, eingereicht am 11. April 2017, begegnete diesem Problem mit einem vergleichsweise ausführlichen Verfahren. Vorgesehen waren periodische automatisierte Prüfungen und mehrere fehlgeschlagene Kontrollen, bevor ein Nameserver als lahm markiert werden sollte. Die Verantwortlichen sollten nicht nur über einen einzigen, womöglich veralteten Kanal angesprochen werden. Der Text nannte die parallele Benachrichtigung von admin-c, tech-c und zone-c; auch Kontakte aus org- oder mnt-by-Zusammenhängen konnten einbezogen werden. Wiederholte unbeantwortete Mitteilungen, ein standardisiertes und öffentlich dokumentiertes Benachrichtigungsprotokoll, die Entfernung auf Ebene der einzelnen Zone, eine automatisierte Löschung, mögliche Bemerkungen, Wiederherstellung und für Mitglieder sichtbare Archive gehörten zur erkennbaren Verfahrensarchitektur.

Diese Einzelheiten waren keine bloße Bedienungsanleitung für Software. Sie bestimmten, wann eine technische Beobachtung ausreichend belastbar wurde, um den Registry-Zustand zu verändern. Eine Messung kann durch vorübergehende Erreichbarkeitsprobleme, Routingpfade, lokale Störungen oder eine ungünstige Perspektive geprägt sein. Mehrere Prüfungen senken dieses Risiko. Mehrere Kontaktrollen erhöhen die Chance, dass ein zuständiger Mensch den Hinweis rechtzeitig erhält. Eine zonenbezogene Entfernung begrenzt den Eingriff auf genau das festgestellte Problem. Ein Archiv macht später nachvollziehbar, welche Antwort wann von wo beobachtet wurde.

Eine ausdrückliche Wiederherstellung stellt klar, dass eine Korrektur der Datenbank kein endgültiges Urteil über den Betreiber ist. Indem Draft 1 diese Punkte sichtbar machte, band er das Ergebnis an eine überprüfbare Abfolge.

Die Größenordnung erklärte zugleich, warum AFRINIC nicht untätig bleiben wollte. In der Mitarbeiterbewertung vom 15. Mai 2017 wurde für den am 12. Mai untersuchten AFRINIC-Reverse-Bereich eine Lähmungsquote von ungefähr 44 Prozent angegeben. Das ist eine institutionelle Messung, kein unabhängiger Beweis dafür, dass jeder einzelne Datensatz falsch war. Als Problemindikator war sie dennoch erheblich. Eine große Zahl unbrauchbarer Verweise belastet Resolver und verschlechtert die Aussagekraft des übergeordneten Registers.

Das Personal bat damals unter anderem um Spielraum bei Benachrichtigungen, um klareren Geltungsbereich und um die Entfernung der ausdrücklichen Wiederherstellungsklausel. Schon hier lag die Kernspannung offen: Ein massenhaftes technisches Problem verlangt skalierbare Abläufe, doch der Wunsch nach betrieblicher Beweglichkeit betrifft genau jene Sicherungen, die Fehlentscheidungen begrenzen.

Am 22. November 2017 erschien AFPUB-2017-DNS-001-DRAFT-02. Die Autoren bezeichneten ihn als vollständige Neufassung zugunsten von Einfachheit und Klarheit. Zugleich erklärten sie, Absicht, Handlungen und Resultate seien unverändert. Beides kann gleichzeitig zutreffen, wenn man nur auf den gewünschten Endzustand schaut: einen lahmen Verweis erkennen, verantwortliche Kontakte erreichen, den unbrauchbaren nserver-Eintrag entfernen und das ganze Domain-Objekt nur dann löschen, wenn kein funktionsfähiger Nameserver darin übrig bleibt. Institutionell bleibt die Aussage über unveränderte Resultate jedoch unvollständig. Ein gleiches Ziel kann unter einem anders verteilten Ermessen verfolgt werden. Wer die Kriterien aus dem verbindlichen Text entfernt, verändert nicht zwingend die Absicht, wohl aber die Stelle, an der praktische Macht ausgeübt wird.

Draft 2 strich die ausführlichen Hintergründe, Begriffe, Erklärungen, Folgenabschätzungen, Motive und möglichen Umsetzungsdetails. Sein verpflichtender Kern wurde deutlich knapper. AFRINIC sollte Lähmung feststellen, angemessene Versuche zur Kontaktaufnahme unternehmen und den betroffenen Nameserver-Eintrag entfernen. Eine Bemerkungszeile konnte den Zustand kenntlich machen. Wenn alle Nameserver eines Domain-Objekts lahm waren, sollte dieses Objekt vollständig entfernt werden. Archivinformationen sollten für eine angemessene Zeit verfügbar bleiben. In dieser Sprache steckten weiterhin Begrenzungen, aber keine messbaren Schwellen.

Was galt als Feststellung? Wie viele Versuche waren angemessen? Welche Kontaktrollen mussten erreicht werden? Wann begann und endete die Heilungsfrist? Was bedeutete eine angemessene Archivdauer? Für diese Fragen lieferte die Policy selbst keine reproduzierbare Antwort mehr.

Der Geltungsbereich muss dabei präzise bleiben. Gegenstand waren .arpa-Domain-Objekte im AFRINIC-Register, also Delegationsdaten für Reverse DNS unter der technischen Verwaltung dieses Registers. Eingehende Datensätze von Minderheits-RIRs und Legacy-Ressourcen waren ausgeschlossen. Das Vorhaben griff nicht in Forward-DNS-Zonen allgemein ein. Es löschte keine IP-Adresszuteilung und nahm einem Betreiber nicht seine Adressen. Es entfernte auch nicht denselben Nameserver universell aus allen Zonen, nur weil er in einer bestimmten Zone versagte. Ein nserver-Attribut wurde aus dem jeweiligen Reverse-Zonenobjekt entfernt, wenn es dort als lahm bestimmt worden war. Blieb ein anderer Nameserver gesund, blieb das Domain-Objekt bestehen. Erst die Lähmung aller darin verzeichneten Server führte zur Entfernung des gesamten Objekts.

Diese Unterscheidung zwischen einem Attribut und dem ganzen Objekt ist die eingebaute Proportionalitätslinie. Ein Betreiber kann mehrere autoritative Server bereitstellen. Versagt einer dauerhaft, während andere korrekt antworten, wäre es sachwidrig, die gesamte Delegation zu beseitigen. Die Datenbankkorrektur darf nur den toten Ast abschneiden. Sind dagegen alle Äste unbrauchbar, bildet ein bestehen bleibendes Domain-Objekt eine Delegation ab, die technisch nichts liefert. Seine Entfernung kann dann den übergeordneten Datensatz wahrheitsgemäßer machen.

Selbst dieser Schritt ist jedoch keine Aussage über Mitgliedstreue, Geschäftspraxis oder Anspruch auf Adressressourcen. Er ist eine begrenzte Änderung an einem bestimmten Reverse-DNS-Koordinationsdatensatz.

Draft 2 verwies zwar auf eine beispielhafte Umsetzungsrichtlinie, zog aber selbst die entscheidende Grenze: Dieses Beispiel war kein Bestandteil der Policy und musste der späteren tatsächlichen Umsetzung nicht entsprechen. Damit konnte es die fehlenden Mindestwerte nicht verbindlich ersetzen. Ein Leser mochte dort plausible Prüf- oder Benachrichtigungsschritte finden, konnte daraus aber keinen dauerhaften Anspruch auf genau diese Schritte ableiten. Das Dokument war ein Hinweis darauf, wie Personal handeln könnte, nicht die Norm dafür, wie es handeln musste. Die Auslagerung lag somit nicht darin, dass technische Teams Software schrieben.

Sie lag darin, dass der unverbindliche Bereich die tatsächliche Schwelle zwischen Beobachtung und Entfernung definieren durfte.

Die Formulierung „unveränderte Handlungen“ beseitigt dieses Problem nicht. Auf hoher Abstraktion blieben die Handlungen gleich: prüfen, benachrichtigen, entfernen, archivieren und gegebenenfalls wieder einen korrekten Zustand herstellen. Auf operativer Ebene entscheidet jedoch die Ausgestaltung, ob dieselben Verben dieselbe Schutzwirkung haben. Ein Test von einem Ort ist nicht dasselbe wie wiederholte Tests aus mehreren Regionen. Eine Nachricht an einen alten Kontakt ist nicht dasselbe wie Hinweise an mehrere verifizierte Rollen. Eine offene Wartezeit ist nicht dasselbe wie eine veröffentlichte Heilungsfrist.

Ein nicht näher bestimmtes Archiv ist nicht dasselbe wie ein vollständiges Protokoll, das eine schnelle Überprüfung ermöglicht. Die Neufassung änderte also nicht notwendig das sprachlich erklärte Ziel, aber sie verschob die Zuweisung der Verfahrensentscheidung.

Auch die zeitliche Trennung ist wesentlich. Die Veröffentlichung am 22. November war weder Ratifikation noch Betriebseinsatz. Am 30. November präsentierten die Autoren Draft 2 aus der Ferne bei AFRINIC-27; die Zusammenfassung des Treffens verzeichnete den Übergang in Last Call. Dieser lief über 15 Kalendertage vom 1. bis zum 16. Dezember 2017. Listenbeiträge dokumentierten Unterstützung. Am 28. Dezember wurde dort zugleich darüber gestritten, ob der Bericht der Ko-Vorsitzenden die Diskussion und die Rückmeldungen aus Last Call ausreichend wiedergegeben habe. Ein Teilnehmer verteidigte das Verfahren.

Das geschlossene Material belegt das Vorhandensein dieses Streits, entscheidet aber nicht, welche Seite recht hatte oder ob ein formeller Verfahrensfehler vorlag.

Der Vorstand ratifizierte Draft 2 erst am 21. März 2018 mit der Resolution 201803.395. Im Protokoll ist eine Konfliktdiskussion und die Enthaltung beziehungsweise der Rückzug des CEO aus dem betreffenden Vorgang festgehalten. Das ist spätere institutionelle Chronologie, keine Rückwirkung auf den Veröffentlichungstag. Auch die Vorstandshandlung blieb die Handlung eines privaten, mitgliedschaftlich organisierten Unternehmens, nicht der Erlass eines öffentlichen Gesetzgebers. Am 22. August 2018 wurde die Regel als Abschnitt 10.7 in Version 1.2 des Consolidated Policy Manual aufgenommen.

Erst diese Stationen führen von der Neufassung über das private Verfahren zur formal integrierten Regel. Wer die spätere Umsetzung in den November 2017 zurückprojiziert, verwischt gerade die offene Schwelle, um die es geht.

Der Unterschied zwischen einer lahmen und einer nicht vorhandenen Delegation hilft, den begrenzten Regelungszweck zu verstehen. In beiden Fällen kann eine Reverse-Abfrage ohne gewünschte Daten enden. Bei der lahmen Delegation wird der Resolver jedoch zunächst zu einem angeblich zuständigen Server geschickt. Er verbraucht Zeit und Netzarbeit für einen Pfad, der nicht funktioniert. Ohne die Delegation ist das negative Ergebnis früher und ehrlicher. Die Entfernung kann deshalb eine Verbesserung sein, obwohl sie oberflächlich wie der Entzug einer Funktion wirkt.

Sie beseitigt kein funktionierendes Angebot, wenn die Lähmung zuverlässig nachgewiesen ist; sie entfernt eine unzutreffende Behauptung des Parent-Datensatzes. Genau das macht die Beweisqualität zum Drehpunkt.

Reverse DNS ist zugleich kein bedeutungsloser Nebenkanal. Mail-Systeme nutzen Rückwärtsauflösung als einen Baustein ihrer Reputations- und Plausibilitätsprüfung. Betriebsteams verwenden sie bei Diagnose, Abuse-Bearbeitung und Zuordnung. Kundenbeziehungen, Übergaben und Transaktionen können auf einer stabilen Verwaltung der betreffenden Delegation beruhen. Eine korrekte Entfernung eines dauerhaft kaputten Verweises kann Fehlerbilder klarer machen. Eine falsche positive Einstufung oder eine Entfernung nach Nachrichten an veraltete Kontakte kann dagegen zusätzliche Ausfälle, Reputationsschäden und langwierige Fehlersuche auslösen.

Weder Nutzen noch Risiko verwandeln AFRINIC in eine Behörde. Sie erklären vielmehr, warum eine private technische Buchführung begrenzte, nachvollziehbare Regeln braucht.

Der erste Befund lautet daher nicht, Draft 2 habe einen unzulässigen Zweck erfunden. Sein enger Endzustand war sachlich verteidigungsfähig und im erklärten Resultat gegenüber Draft 1 stabil. Der Befund lautet, dass die vollständige Neufassung die sichtbare prozedurale Hülle entfernte, durch die sich dieser Endzustand von einem zu frühen oder falsch begründeten Eingriff unterscheiden ließ. Klarheit auf der Ebene des Ergebnisses wurde mit Unbestimmtheit auf der Ebene der Schwelle erkauft.

Von diesem Moment an hing die Qualität der Regel weniger daran, was die Policy garantierte, und stärker daran, was das Personal in einem veränderbaren Betriebshandbuch tatsächlich vorsah.