Zusammenfassung

  • Der erste und der letzte Wert der veröffentlichten Bestandsreihe liegen um rund 95,1 Prozent auseinander. Das passt zur gerundeten Anzeige im Portal, belegt aber weder deren Berechnungsgrundlage noch die Reparatur einer unveränderten Gruppe von Delegationen.
  • Im Datenstand vom 3. September 2026 sind rund 1,1 Prozent der Delegationseinträge als fehlerhaft erfasst, während die gesonderte Halterstatistik rund 10,9 Prozent ausweist. Die Nenner beschreiben unterschiedliche Populationen.
  • Die Historie zählt 27.726 Entfernungsvorgänge für Delegationen und 9.036 für Domainobjekte. Das sind aufsummierte Ereignisse, keine nachgewiesenen Zahlen verschiedener Betroffener oder wiederhergestellter Dienste.

Eine überzeugende Zahl mit begrenzter Aussage

95 Prozent weniger: Auf dem Statistikportal von AFRINIC lässt sich die Entwicklung fehlerhafter Reverse-DNS-Delegationen auf eine eindrucksvolle Kennzahl verdichten. In der am 3. September 2026 gesicherten Ansicht stehen noch 1.936 sogenannte lame delegations. Wer eine Wartungsaufgabe verantwortet, kann darin zunächst eine erfreuliche Bewegung sehen. Weniger Einträge, die auf ungeeignete Nameserver verweisen, bedeuten einen kleineren sichtbaren Fehlerbestand.

Schon der nächste Satz verlangt jedoch Sorgfalt. Die Beschriftung der Anzeige nennt keine genaue Vergleichsformel. Die veröffentlichte Zeitreihe beginnt am 28. September 2018 mit 39.814 Einträgen und endet am 2. September 2026 mit 1.936. Aus diesen beiden Werten ergibt sich ein Rückgang um 37.878 beziehungsweise 95,1374 Prozent. Die Rechnung passt zur gerundeten Portalzahl. Sie beweist nicht, dass das Portal genau diese Ausgangsbasis verwendet. Ebenso wenig zeigt sie, dass über den gesamten Zeitraum dieselbe Grundgesamtheit beobachtet wurde. Das ist eine Berechnung aus zwei Beständen, keine Erfolgsquote für eine feste Reparaturkohorte. Die Daten stammen aus der offiziellen Bestandsreihe.

Diese Unterscheidung schmälert den möglichen Nutzen der Bereinigung nicht. Sie bestimmt, welchen Nutzen die Zahl überhaupt nachweisen kann. Ein Verzeichnis kann genauer werden, weil ein Server wieder richtige Antworten liefert. Es kann auch genauer werden, weil ein Verweis auf einen weiterhin defekten Server verschwindet. Beide Veränderungen können sinnvoll sein; nur eine davon belegt die Wiederherstellung dieses Servers.

Was hier als Fehler gilt

Beim Reverse-DNS wird zu einer IP-Adresse nach einem zugehörigen Namen gesucht. Eine Delegation verweist die Anfrage an den zuständigen Nameserver. Zeigt sie auf einen Server, der die erwartete Zone nicht autoritativ beantwortet, entsteht ein technisches Problem an dieser Verweisstelle. Damit ist noch nicht gesagt, dass die IP-Adresse nicht mehr erreichbar wäre oder die Vorwärtsauflösung eines Namens ausfiele.

Der Begriff „lame“ ist dabei weniger eindeutig, als ein einzelnes Zahlenfeld vermuten lässt. RFC 9499 erläutert, dass er im Lauf der Zeit verschiedene Bedeutungen angenommen hat, und empfiehlt präzisere Beschreibungen. Deshalb ist für diese Statistik die von AFRINIC beschriebene Prüfung entscheidend, nicht eine unterstellte universelle Definition.

Die Implementierungserläuterung vom April 2021 nennt mehrere Fehlerfälle: keine Antwort, die falsche Zone oder eine Antwort ohne gesetztes Kennzeichen für eine autoritative Auskunft. Alle registrierten nserver-Einträge sollen monatlich geprüft, festgestellte Fehler täglich erneut getestet werden. Die Tests erfolgen laut dieser Beschreibung von mindestens drei geografisch verschiedenen Standorten. Eine einzige autoritative Erfolgsmeldung von irgendeinem dieser Standorte genügt, damit der Nameserver nicht als lame gilt.

Das ist eine wichtige Asymmetrie. Eine erfolgreiche Antwort wird auch dann anerkannt, wenn die Prüfungen von anderen Standorten aus scheitern. Eine breitere betriebliche Definition ist für sich genommen auch kein Beleg für einen Verstoß gegen einen RFC. Allerdings dokumentiert die Seite ein Verfahren von 2021. Sie ist kein aktueller Prüfbericht darüber, wie jeder einzelne Durchlauf im September 2026 tatsächlich ausgeführt wurde.

Drei Nenner, drei verschiedene Fragen

Das Dashboard zur Bereinigung stellt den Zustand von Delegationen und Ressourcenhaltern getrennt dar. In der zugehörigen Zusammenfassungsdatei finden sich drei Paare aus als fehlerhaft und als nicht fehlerhaft bezeichneten Werten. Die folgenden Anteile sind jeweils aus der Summe dieses Paares berechnet.

Erfasste Einheit Als fehlerhaft erfasst / Summe beider Zustände
Delegationseinträge 1.936 / 172.702; rund 1,1 Prozent
Domainobjekte 1.358 / 52.450; rund 2,6 Prozent
Ressourcenhalter 194 / 1.774; rund 10,9 Prozent

Die Tabelle ist kein Widerspruch. Die Eintragsquote beschreibt, wie groß der erfasste Fehlerbestand relativ zu den Delegationseinträgen ist. Die Halterquote beantwortet eine andere Frage: Bei wie vielen der in dieser Aufstellung geführten Halter gibt es lame delegations? Ihr Nenner darf nicht ohne Weiteres zur Gesamtzahl aller Mitglieder von AFRINIC umgedeutet werden.

Ein geringer Anteil fehlerhafter Einträge kann also mit einem merklichen Anteil betroffener Halter zusammenfallen. Daraus folgt eine mögliche Arbeitsbelastung, aber noch keine Messung ihrer Verteilung. Ohne Verknüpfung der einzelnen Datensätze ist unbekannt, ob sich die Probleme auf wenige große Bestände konzentrieren oder viele Halter jeweils wenige Einträge bearbeiten müssen.

Auch die 1.358 Domainobjekte sind mit Zurückhaltung zu lesen. Die veröffentlichte Zusammenfassung legt weder die genaue Gruppierungsabfrage für ihren Zustand noch die Zuordnung jedes Nameservereintrags offen. Sie beweist nicht, dass all diese Domains vollständig unauflösbar sind. Sie zeigt auch nicht im Einzelnen, wie sich die 1.936 Delegationseinträge auf sie verteilen. Einen Zustandszähler als Zahl vollständig ausgefallener Dienste auszugeben, wäre deshalb ein zusätzlicher, unbelegter Schritt.

Bereinigung ist nicht nur ein Vorgang

Die technische Begründung für Wartung ist handfest. Ein Resolver, der wiederholt einen ungeeigneten Server befragt, erledigt unnütze Arbeit. RFC 4697 beschreibt solche ineffizienten Wiederholungen und unterscheidet zwischen Problemen mit einem Teil der zuständigen Server und dem Ausfall aller Server. Das erklärt einen möglichen Nutzen der Bereinigung; es liefert keine Messung des Verkehrs oder der Wartezeiten bei AFRINIC.

Nach der Beschreibung von 2021 sind Benachrichtigungen an den Tagen 3, 10, 17 und 24 vorgesehen, ein Vermerk am Tag 11 und die Entfernung am Tag 30, falls das Problem fortbesteht. Entfernt wird das betreffende Nameserverattribut. Bleibt kein Nameservereintrag übrig, wird das Domainobjekt entfernt. Die Erläuterung beschreibt für eine anschließend abgefragte entfernte Domain NXDOMAIN als Ergebnis.

Damit ergeben sich mindestens drei betrieblich unterschiedliche Endzustände. Ein reparierter Server kann wieder eine autoritative Antwort liefern. Ein weiterhin defekter Verweis kann entfernt werden, während andere funktionierende Nameserver bestehen bleiben. Oder die letzte Delegation verschwindet, ohne dass damit eine brauchbare Reverse-DNS-Antwort wiederhergestellt wäre. Diese Unterscheidung ist analytisch; die aggregierten Tabellen weisen die Einzelfälle nicht entsprechend zu.

Ein gezielt entfernter toter Verweis kann das Verzeichnis verlässlicher machen. Die letzte Verweisung zu entfernen ist dennoch etwas anderes, als einen Dienst zu reparieren. Keine dieser Feststellungen rechtfertigt es, aus den Tabellen einen Entzug von IP-Ressourcen, eine Rücknahme von Routen, eine Strafe oder ein Fehlverhalten abzuleiten.

Warum die Löschhistorie keine Reparaturrechnung ergibt

Die gesonderte Entfernungshistorie umfasst 996 datierte Zeilen vom 30. Mai 2021 bis zum 31. August 2026. Die Addition ihrer beiden Ereignisspalten ergibt 27.726 entfernte Delegationen und 9.036 entfernte Domainobjekte. Schon die erste Zeile enthält 9.665 beziehungsweise 3.101 Vorgänge; die letzte enthält vier und null.

Die Summe beschreibt die in dieser Datei erfassten Ereignisse. Ohne dauerhafte Objektidentitäten lässt sich daraus nicht ablesen, wie viele verschiedene Objekte oder Halter beteiligt waren. Ein wiederkehrender Eintrag könnte die Zählung beeinflussen; ob und wo das geschah, ist aus den Aggregaten gerade nicht nachweisbar. Die Zahlen dürfen deshalb nicht als Zahl einzigartiger Betroffener ausgegeben werden.

Vor allem beginnen die beiden Historien nicht gleichzeitig. Der Fehlerbestand reicht bis 2018 zurück, die Entfernungstabelle nur bis 2021. Wer die 27.726 Entfernungsvorgänge von der Bestandsabnahme um 37.878 abzieht und den Rest als Reparaturen verbucht, verbindet unterschiedliche Zeitfenster und unbekannte Populationen. Die scheinbar saubere Restgröße hätte keine belegte betriebliche Bedeutung.

Ein Bestand kann durch neue Fehler wachsen und durch Reparaturen, geänderte Serverlisten oder Entfernungen sinken. Wiederauftauchen und Änderungen der Beobachtungsabdeckung sind weitere denkbare Einflüsse. Das sind Möglichkeiten zur Erklärung einer Bestandsbewegung, keine in den vorliegenden Zeilen beobachteten Ursachen.

Die letzten Beobachtungen machen die Grenze anschaulich. Am 30. August stehen 2.016 Fehler im Bestand, am 31. August 3.354 und am 2. September 1.936. Für den 1. September fehlt eine Zeile. Der Rückgang zwischen den letzten beiden datierten Beobachtungen beträgt 1.418. Daraus werden weder 1.418 nachgewiesene Reparaturen noch das Resultat eines einzigen Prüflaufs. Den Rückgang den vier zuletzt ausgewiesenen Entfernungen zuzurechnen, wäre ebenfalls unbegründet.

In der gesamten Bestandsdatei gibt es 14 Abstände von mehr als einem Tag, darunter den Zeitraum vom 24. Dezember 2025 bis zum 29. April 2026. Fehlende veröffentlichte Beobachtungen sind kein Nachweis eines Dienstausfalls oder einer unterbliebenen internen Prüfung. Ebenso wenig bedeuten die aktuellen Nullwerte bei „Removed“ und „Deleted“ in der Zusammenfassung, dass nie etwas entfernt wurde: Dafür gibt es eine eigene datierte Historie.

Konsistente Dateien, offene Wirkungsfrage

Ein Abgleich des offiziellen CSV-Archivs mit den JSON-Dateien ergibt für die fünf gemeinsam enthaltenen Tabellen Übereinstimmung in allen Zeilen und Feldern. Dazu gehören Zusammenfassung, Bestandsverlauf, Entfernungen sowie Länder- und Haltertypaufschlüsselung. Die zwei zusätzlichen CSV-Tabellen enthalten aggregierte Präfixangaben nach Adressfamilie, keine Zuordnung einzelner wiederhergestellter Dienste.

Das ist ein belastbarer Ausgangspunkt. Die Zahlen lassen sich zwischen den veröffentlichten Darstellungen nachvollziehen. Konsistente Dateien beantworten jedoch nicht automatisch eine Frage, für die ihnen die Verknüpfung fehlt. Der sichtbare Fehlerbestand ist deutlich kleiner als am Anfang der Reihe. Wie viel davon auf wieder funktionierende Server, entfernte Verweise oder andere Veränderungen entfällt, bleibt offen. Eine faire Bewertung hält beides fest: den Wert eines genaueren Verzeichnisses und die Eigenständigkeit der Frage, ob Nutzer wieder brauchbare Antworten erhalten.