Zusammenfassung

  • Die aktuelle Karte lädt 27 CSV-Zeilen und erklärt jede davon für gehostet; nur 24 Delegationen führen afrinic in einem Servernamen.
  • Die drei übrigen Zonen .so, .ng und .ml besitzen jeweils IPv4- und IPv6-Adressen in AFRINICs veröffentlichten NS2-Präfixen. Auf Adressebene ist die Summe damit nachvollziehbar.
  • Ein datierter Hosting-Beleg sollte Hostname, Adresse und Dienstpräfix verbinden, ohne daraus Vertrag, Standort, Verfügbarkeit oder Kontrolle über Zoneninhalte abzuleiten.

Eine gute Übersicht nimmt Komplexität weg. Eine belastbare Übersicht lässt sie bei Bedarf wieder sichtbar werden. AFRINICs DNS-Programm erklärt, autoritatives DNS für mehr als 25 afrikanische Länderendungen zu hosten. Die verlinkte Karte nennt faktisch 27: So viele eindeutige Länder- und ccTLD-Zeilen enthält ihre derzeitige CSV-Datei.

Der Browsercode macht daraus unmittelbar einen Zustand. Jede eingelesene Zeile erhält isHosted: true; die Länge der Liste wird zur Länderzahl. Das ist ein verständliches Darstellungsmodell. Als Nachweis fehlt ihm jedoch die Verbindung zur aktuellen Delegation.

Eine Suche nach afrinic in den delegierten Nameservern bestätigt 24 Fälle. Bei Namen wie ns-ci.afrinic.net ist die Zuordnung offensichtlich. Für Somalia, Nigeria und Mali funktioniert diese Abkürzung nicht. Kein delegierter Servername von .so, .ng oder .ml enthält afrinic. Wer nur Etiketten prüft, hält drei Einträge irrtümlich für unbelegt.

Drei Verbindungen unterhalb des Namens

Bei .so führt d.nic.so weiter. Im eingefrorenen DNS-Schnappschuss vom 12. September löste der Name zu 196.216.168.54 und 2001:43f8:120::54 auf. Der aktuelle IANA-Delegationseintrag nennt dasselbe Paar.

Bei .ng liegt die Verbindung in ns5.nic.net.ng mit 196.216.168.41 und 2001:43f8:120::41. Bei .ml ist es d.nic.ml mit 196.216.168.37 und 2001:43f8:120::37. Auch hier stimmen die aktuellen IANA-Angaben mit der DNS-Beobachtung überein.

AFRINICs Bereitstellungsleitfaden schließt die Kette. Er ordnet NS2 dem AS37177 zu und veröffentlicht 196.216.168.0/24 sowie 2001:43f8:120::/48 als Anycast-Präfixe des Dienstes. Alle sechs Adressen liegen im jeweils passenden Bereich. Über die gesamte CSV hinweg fand die Prüfung für jede der 27 Zonen mindestens eine Serveradresse in beiden Präfixen.

Die Zahl ist somit nicht widerlegt, sondern gestützt. Unsichtbar bleibt lediglich die Rechenarbeit, die sie stützt.

Ein Hostname ist kein Betreiberregister

Ein ccTLD-Betreiber kann einen lokalen Servernamen behalten und zugleich einen gemeinsamen Sekundärdienst nutzen. Das ist eine saubere Trennung. Ein Zwang, den Dienstleister im Hostnamen zu nennen, würde die Zuordnung optisch vereinfachen, aber weder Verfügbarkeit noch Sicherheit erhöhen.

Die Adresse liefert den technisch stärkeren Zusammenhang. Auch sie hat Grenzen. Ein Treffer im Anycast-Präfix zeigt nicht, welche physische Instanz eine Anfrage beantwortet hat. Er misst keine Latenz, belegt keine Uptime und veröffentlicht keinen Vertrag. Selbst der BGP-Ursprung zu einem bestimmten Zeitpunkt wäre ein eigener Beleg.

Vor allem darf aus der Infrastruktur keine inhaltliche Zuständigkeit entstehen. AFRINIC beschreibt das Programm als Slave- beziehungsweise Sekundär-DNS. Die Zonendaten werden vom Master- oder Primärserver des Betreibers repliziert; AFRINIC verwaltet weder die Zone noch ihren Inhalt. Antworten auszuliefern ist nicht dasselbe wie eine Länderendung zu regieren.

Der öffentlichen Liste fehlt die Zeitachse

Die CSV enthält Land, ccTLD und Flagge. Pro Zeile fehlen Beobachtungszeit, delegierter Name, IPv4- und IPv6-Adresse, zugeordnetes Präfix und Statusverlauf. Der Code unterscheidet auch nicht zwischen aktiv, geplant, beendet oder vorübergehend nicht verfügbar.

Für eine Karte ist das bequem. Bei Veränderungen wird es problematisch. Eine bloße Umbenennung kann in einer Wortsuche wie ein Dienstaustritt wirken. Verlässt eine Adresse das Präfix, ist nicht erkennbar, ob die Beziehung beendet, migriert oder nur noch nicht aktualisiert wurde.

Ein kurzer, ausklappbarer Hosting-Beleg würde reichen. Er nennt die ccTLD, den für AFRINICs Dienst verwendeten delegierten Hostnamen, beobachtete v4- und v6-Adressen, das passende Dienstpräfix, Quelle, Zeitpunkt und Status. Erstbeobachtung, letzte Bestätigung und Statuswechsel bilden eine knappe Historie.

Hinzu gehören ein Korrekturweg und klare Aussagegrenzen. Vertrauliche Verträge, interne Kontakte oder Knotenkoordinaten müssen nicht veröffentlicht werden. Der Beleg ist auch kein SLA. Er beantwortet nur, warum eine Zone zu einem bestimmten Zeitpunkt in die öffentliche Summe eingeht.

Die stärkste Verteidigung der heutigen Karte lautet: Sie ist einfach, und ihre 27 Einträge bestanden den eingefrorenen Test. Niemand sollte vor dem Lesen einer Übersicht Root-Delegationen und Adressräume studieren müssen. Doch eine einfache Oberfläche kann auf überprüfbaren Details ruhen. Ein zweiter, ausklappbarer Layer genügt.

.so, .ng und .ml sind deshalb keine peinlichen Ausnahmen. Sie erklären die Architektur besser als ein Markenname: lokale Benennung, gemeinsame Adressinfrastruktur und eine zusammenfassende Registry-Liste. Vertrauen entsteht nicht durch einheitliche Etiketten, sondern durch eine wiederholbare Zuordnung.

Quellen