Zusammenfassung

  • AFRINICs öffentliche NS2-Messkonfiguration führt siebzehn Standorte. Sechs besitzen je eine vollständige Vorher-nachher-Kombination; elf enthalten keine der beiden Messungs-IDs und werden von der Oberfläche als ausstehend behandelt.
  • Sämtliche zwölf verknüpften DNS-Messungen sind einmalige RIPE-Atlas-Läufe mit dem Status Stopped. Sie können einen begrenzten Ausbauvergleich stützen, sind aber keine fortlaufende Zustandsüberwachung.

Der jüngste Messwert ist nicht automatisch gegenwärtig

Das folgenreichste Wort auf AFRINICs NS2-Messdashboard lautet nicht Anycast, sondern „Real-time“. Durchschnittliche Laufzeit, Vorher-nachher-Diagramme, Sondenansichten und eine Anzeige der letzten Aktualisierung verleihen der Seite die Grammatik eines Betriebsinstruments. Wer sie öffnet, darf annehmen, dass ein frischer Seitenaufruf auch eine frische Beobachtung der Infrastruktur liefert.

Die technische Kette erfüllt ein engeres Versprechen. Der Anwendungscode liest IDs aus einer öffentlich zugänglichen Knotenkonfiguration und ruft für jede davon den Endpunkt /measurements/{id}/latest/ ab. Dieser liefert das zuletzt gespeicherte Ergebnis der jeweiligen Messung. Er sagt weder, dass die Messung noch läuft, noch, dass das Ergebnis innerhalb einer aktuellen Frist entstanden ist, noch, dass der Standort weiterhin beobachtet wird.

„Zuletzt verfügbar“ beschreibt eine Position in einem Datensatz; „aktuell“ beschreibt eine Beziehung zur Gegenwart. Beides sieht in einem Zahlenfeld gleich aus. Ein Sensor, der am Montag abgeschaltet wurde, kann am Freitag zuverlässig seinen letzten Montagswert ausgeben. Die Abfrage ist aktuell, die Beobachtung nicht. Für DNS-Infrastruktur gehören deshalb Alter, Wiederholungsrhythmus und Messzweck zur Aussage, die eine Zahl tragen kann.

Der Lebenszyklus lässt sich in der RIPE-Atlas-API-Referenz und in den einzelnen Datensätzen überprüfen. Bei allen zwölf von AFRINIC eingebundenen Messungen ist is_oneoff wahr; alle stehen auf Stopped. Die beobachteten Zeitfenster reichen vom 8. Dezember 2025 bis zum 16. Februar 2026 und dauern überwiegend etwa fünf Minuten. Das sind kurze Versuche, keine kontinuierliche Zeitreihe.

Ein solcher Versuch kann genau das richtige Werkzeug sein, um eine begrenzte Frage zu beantworten: Wie unterschieden sich ausgewählte Sonden unmittelbar vor und nach einer Umstellung? Dafür müssen Ziel, Sondengruppe, Fenster und Auswertungsmethode vergleichbar sein. Ohne erneute Erhebung beantwortet er jedoch nicht die Frage, wie der Dienst heute arbeitet. Das Dashboard macht aus der ersten Frage stillschweigend die zweite.

Zwanzig Hosts, siebzehn Einträge, sechs Vergleiche

In der Konfigurationsdatei des Dashboards stehen siebzehn Standorte. Angola, Benin, Botswana, Kenia, Simbabwe und Mauritius verfügen über eine ID für „before“ und eine für „after“. Burkina Faso, Kap Verde, Kamerun, Ägypten, Gabun, Gambia, Ghana, Marokko, Nigeria, Sudan und Tunesien besitzen keine der beiden IDs. Die Oberfläche stuft diese elf Einträge als ausstehend ein.

Halbfertige Paare gibt es nicht: Kein Standort weist nur eine Seite auf. Die belastbare Zählung lautet daher sechs vollständige Standortvergleiche, elf Standorte ohne veröffentlichtes Paar und null partielle Paare. Die zwölf Messungen entstehen aus zwei Läufen pro verglichenem Standort. Sie sind nicht zwölf überwachte Standorte.

Daneben veröffentlicht AFRINIC ein anderes Inventar. Die DNS-Ausbaukarte lädt zwanzig CIP-Hostzeilen und zwanzig NS2-Hostzeilen, insgesamt also vierzig Hosting-Einträge. Dieses Verzeichnis kann einen Ausbau oder eine Partnerschaft belegen. Es ist nicht automatisch mit den siebzehn Positionen der Versuchskonfiguration oder den sechs gemessenen Paaren deckungsgleich.

Das öffentliche Kartenskript bestätigt, dass diese beiden Inventare die Darstellung speisen.

Alle drei Zahlen dürfen richtig sein, solange ihre Nenner sichtbar bleiben. Zwanzig NS2-Hostzeilen messen Inventarumfang. Siebzehn Konfigurationseinträge beschreiben den Arbeitsvorrat des Dashboards. Sechs Paare bezeichnen abgeschlossene Vorher-nachher-Zuordnungen. Die Sammelbezeichnung „Knoten“ macht daraus scheinbar eine einzige Population und lässt Präsenz, experimentelle Abdeckung und laufende Überwachung ineinanderlaufen.

Für die Steuerung eines regionalen Programms ist das keine pedantische Frage. Ein wachsendes Hostinventar würdigt Reichweite. Mehr sauber dokumentierte Paare würdigen Evaluation. Eine größere aktive Messabdeckung würdigt Betriebsfähigkeit. Werden die drei Größen getrennt, lässt sich erkennen, wo ein Ausbau stattgefunden hat, aber noch nicht bewertet wurde, oder wo ein historischer Nutzen belegt ist, aber keine aktuelle Zustandsaussage vorliegt.

Die zwölf Datensätze und ihre Aussagegrenze

Die öffentlichen RIPE-Atlas-Seiten zeigen für jede im Dashboard verwendete ID denselben grundlegenden Lebenszyklus:

Standort Vorher Nachher Vertretbare Einordnung
Angola 154055021 154055966 Zwei gestoppte Einmalmessungen
Benin 142730550 142730838 Zwei gestoppte Einmalmessungen
Botswana 155156750 155156902 Zwei gestoppte Einmalmessungen
Kenia 143072543 147523251 Zwei gestoppte Einmalmessungen
Simbabwe 142775401 142775907 Zwei Einmalmessungen; Metadaten sind erklärungsbedürftig
Mauritius 142741062 142740732 Zwei Einmalmessungen; Beschriftungen wirken vertauscht

Der Status Stopped entwertet die gespeicherten Antworten nicht. Er setzt ihnen eine zeitliche Grenze. Aus den Ergebnissen ließen sich möglicherweise sinnvolle Unterschiede in Laufzeit oder Antwortverhalten ableiten, wenn das Versuchsdesign dies trägt. Nicht zulässig ist allein der Wechsel ins Präsens, ohne die Beobachtung zu erneuern.

Zwei Zuordnungen zeigen zudem, weshalb ein Messungsname nicht als alleiniger Herkunftsnachweis genügt. Für Simbabwe steht die ID 142775401 im AFRINIC-Code unter „before“, ihre Beschreibung endet jedoch mit „After“. Die zugehörige ID 142775907 trägt eine allgemeinere Simbabwe-Beschreibung und verwendet eine andere Ziel-IP sowie ein anderes Ziel-ASN. Das kann einen legitimen Zielwechsel, eine alte Benennung oder eine falsche Zuordnung widerspiegeln. Die veröffentlichten Materialien entscheiden nicht zwischen diesen Möglichkeiten.

Bei Mauritius scheint die Kreuzung noch deutlicher. Die Konfiguration setzt 142741062 auf die Vorher-Seite, während die Atlas-Beschreibung „After“ sagt. 142740732 steht im Nachher-Feld, die Beschreibung enthält jedoch „before“. „Scheint“ bleibt wichtig: Ohne Korrekturprotokoll kann ein Außenstehender nicht wissen, welches Feld die ursprüngliche Absicht festhält. Eine saubere Analyse markiert diese Unsicherheit, statt sie durch eine Vermutung zu beseitigen.

Diese Metadatenprobleme sind kein Beweis für einen Ausfall der Infrastruktur. Sie betreffen die Beweiskette einer Gegenüberstellung. Ein belastbarer Vergleich müsste dokumentieren, wer die IDs zugeordnet hat, welches Ereignis die Fenster trennt, ob sich Ziel, ASN, Adresse oder Sondenkohorte änderten und ob später korrigiert wurde. Zwei Zahlen in einer JavaScript-Datei tragen diesen Kontext nicht dauerhaft.

Anycast verlangt mehr Kontext, nicht weniger

AFRINIC beschreibt sein DNS-Infrastrukturprogramm als Beitrag zu widerstandsfähigerer und leistungsfähigerer Namensauflösung in Afrika. Hinzu kommt ein Programm für Root-Server-Kopien. Lokale Instanzen können Wege verkürzen, Verkehr regional halten und Redundanz erhöhen. Ob und für wen sie dies tun, hängt allerdings nicht bloß von ihrem Punkt auf einer Karte ab.

RFC 4786 erläutert das Anycast-Prinzip: Dieselbe Adresse wird von mehreren Standorten angekündigt, und das Routing entscheidet, welche Instanz erreicht wird. Eine Sonde misst damit nicht den geografischen Namen einer Karte, sondern den Pfad, den BGP und lokale Richtlinien in diesem Augenblick auswählen. Eine fünfminütige Beobachtung ausgewählter Sonden kann weder alle Netze eines Landes noch eine ganze Region repräsentieren.

RFC 6304 behandelt lokale Instanzen des Root-Server-Systems und hilft, physische Präsenz von beobachteter Wirkung zu trennen. Eine Kopie kann Resilienz schaffen, ohne dass sich der mittlere Messwert stark ändert; nahe Nutzer können wegen ihrer Route eine andere Instanz erreichen; eine Instanz kann weit über ihren Standort hinaus dienen. Ein Hostdatensatz, eine NS2-Messung und ein Root-Server-Betriebspunkt sind deshalb miteinander verwandt, aber keine austauschbaren Betriebsobjekte.

Die Grenzen dieser Feststellung sind eng. Aus zwölf gestoppten Messungen folgt weder ein DNS-Ausfall noch eine Störung von NS2, ein zurückgezogenes Routing-Präfix, ein ccTLD-Problem oder eine regionale Verschlechterung. Diese Untersuchung hat keine aktuellen DNS-Anfragen, BGP-Pfade oder Hostsysteme geprüft. Sie bewertet die veröffentlichte Messgrundlage und die zeitliche Aussage, die das Dashboard daraus formt.

Ein Dashboard muss seinen Fragetyp offenlegen

Die aktuelle Seite verbindet drei legitime Produkte. Eine Ausbaukarte beantwortet: Wo existiert Infrastruktur? Ein Versuch beantwortet: Was änderte sich in einem bestimmten Übergang? Ein Zustandsmonitor beantwortet: Was geschieht jetzt? Die Ergebnisse können nebeneinanderstehen, brauchen aber jeweils eigenen Nenner, eigene Uhr und eigenen Verantwortlichen.

Beim Inventar zählen Dienstklasse, Betreiber, Inbetriebnahme und letzter Bestätigungstermin. Beim Versuch zählen Intervention, Ziel, Sonden, Zeitfenster und Vergleichbarkeit. Bei der aktuellen Gesundheit zählen Wiederholung, Verlust, Verzögerung und eine explizite Frischegrenze. Das letzte Ergebnis eines abgeschlossenen Einmaltests erfüllt die Anforderungen der dritten Kategorie nicht.

Die kurzfristige redaktionelle Korrektur wäre einfach. „Historische NS2-Ausbauvergleiche“ wäre ein genauer Titel. Jede Karte könnte Start, Ende, oneoff und Stopped ausweisen. Die elf Einträge ohne IDs sollten „kein veröffentlichter Vergleich“ heißen und nicht mit einem unbestimmten „pending“ eine andere Art von Warten andeuten. Falls eine laufende Quelle existiert, gehört sie in eine separate Zustandsansicht, die sichtbar veraltet, sobald ihr Frischefenster abläuft.

Die dauerhafte Governance-Lösung ist ein Beobachtungsbeleg pro Knoten. Er sollte nicht bloß eine weitere Erläuterungsseite sein, sondern eine kleine versionierte Akte, aus der hervorgeht, ob eine Aussage Ausbau, Übergang oder Gegenwart betrifft. Dann kann das Interface den Kontext nicht versehentlich wegformatieren.