Zusammenfassung

  • UIXP listet zwei direkt an sein Peering-LAN angeschlossene AFRINIC-DNS-Netze: AFDSP/NS2 unter AS37177 und DotARPA unter AS37181. AFRINIC weist beiden unterschiedliche IPv4- und IPv6-Dienstpräfixe zu.
  • NS2 ist ein sekundärer DNS-Dienst und entscheidet nicht über den Zoneninhalt. DotARPA gehört zu einer getrennten Reverse-DNS-Kette. Ein Nachweis für den einen Dienst gilt nicht automatisch für den anderen.
  • UIXP-, RDAP- und PeeringDB-Daten belegen Identität und Anschlussfläche. Sie belegen weder aktuelle BGP-Ankündigungen noch Route-Server-Nutzung, lokale Anfragezustellung, Latenz, Verfügbarkeit oder Resilienz.
  • Ein belastbarer Uganda-Nachweis muss je Dienst geführt werden: ASN, angekündigte Präfixe, Peering-Art, Aktivierungs- und Gesundheitszustand, bediente Namensräume, Beobachtungspunkt, antwortende Instanz und Zeit.

Zwei Einträge an derselben Austauschfläche

UIXP beschreibt die aufgeführten Netze als direkt mit seinem Peering-LAN verbunden. „AFRINIC - DNS - AFDSP“ erscheint mit ASN 37177, offener Peering-Policy und dem Mitgliedsjahr 2025. „AFRINIC - DNS - DotARPA“ erscheint als eigene Zeile mit ASN 37181, ebenfalls offener Policy und demselben Jahr. Die Organisation ist dieselbe, Netzkennung und Dienstname sind es nicht.

Auf derselben Seite zieht UIXP eine wichtige Beweisgrenze. Wer wissen will, ob ein Netz die Route Server nutzt und welche Präfixe es ankündigt, soll das Looking Glass heranziehen. Der Verzeichniseintrag ist also keine BGP-Aufnahme. Er zeigt eine Schnittstelle, an der Peering möglich ist. Er zeigt nicht den augenblicklichen Sitzungszustand, angewandte Filter, akzeptierende Nachbarn oder den Pfad, den ein bestimmter Resolver erhält.

Die öffentliche PeeringDB-API ergänzt eine zweite Verzeichnisperspektive. In den eingefrorenen Antworten sind AS37177 und AS37181 beide dem UIXP-Eintrag ix_id 422 zugeordnet. Die Peering-LAN-Adressen von AS37177 enden in IPv4 auf .5 und in IPv6 auf ::5; jene von AS37181 auf .6 und ::6. Das sind Adressen für den Routenaustausch am IXP, nicht die Anycast-Präfixe des DNS-Dienstes.

Beide Adresstypen beantworten verschiedene Fragen. Die Peering-Adresse sagt, wo Router miteinander sprechen können. Das Dienstpräfix sagt, welches Ziel durch diese Beziehung erreichbar werden kann. Wer beides vermischt, macht aus einer registrierten Schnittstelle eine Aussage über Ankündigung, Anwendungszustand und Antwortverhalten.

Eine öffentliche Karte kann den institutionellen Standort mit einem Punkt in Kampala darstellen. Ein Betriebsjournal muss zwei Zeilen bewahren. Nur dann wird sichtbar, wenn ein Dienst oder eine Adressfamilie vom gemeinsamen Bild abweicht.

AS37177 trägt die NS2-Kette

AFRINICs Bereitstellungsleitfaden ordnet NS2 dem AS37177 zu. Als IPv4-Dienstpräfix nennt er 196.216.168.0/24, als IPv6-Präfix 2001:43f8:120::/48. Die Programmseite beschreibt NS2 als Anycast-Infrastruktur für sekundäre Dienste afrikanischer länderspezifischer Top-Level-Domains und weitere regionale DNS-Aufgaben.

„Sekundär“ markiert eine Autoritätsgrenze. AFRINIC erklärt AfDSP als Secondary- beziehungsweise historisch Slave-DNS. Die Zonendaten werden vom primären Server übertragen. AFRINIC verwaltet den Zoneninhalt nicht. Der Dienst kann eine zusätzliche autoritative Kopie und einen verteilten Antwortpfad bereitstellen, ohne dadurch zu entscheiden, welche Namen und Resource Records in die Zone gehören.

Diese Trennung macht den Dienst nicht unbedeutend. Eine gut betriebene sekundäre Kopie kann zusätzliche Erreichbarkeit und Fehlerisolierung schaffen. Sie verhindert nur, dass Inhaltshoheit und Auslieferungshoheit verwechselt werden. Bei falschen Zonendaten beginnt die Prüfung an der Primärquelle und am Transfer; bei ausbleibenden Antworten an Anwendung, Route und Hosting-Umgebung.

Deshalb wiederholt dieser Beitrag keine Zählung gehosteter ccTLDs. Ein Zoneninventar fragt, welche Delegationen oder Adressen mit den NS2-Präfixen zusammenfallen. Die UIXP-Frage lautet, ob die AS37177-Dienstpräfixe über die ugandische Austauschfläche sichtbar sind, welche Netze sie lernen und welche Anfragen tatsächlich die dortige Instanz erreichen. Zugehörigkeit zum Dienst und Zustand eines Standorts sind unterschiedliche Nachweisobjekte.

AFRINICs RDAP ordnet AS37177 und die veröffentlichten Blöcke dem Organisationsdatensatz von AFRINIC zu. Das ist belastbare Registrierungsidentität, aber keine Live-Routing-Telemetrie. RDAP verrät nicht, ob 196.216.168.0/24 oder 2001:43f8:120::/48 zum Erfassungszeitpunkt im UIXP-Looking-Glass sichtbar waren. Es nennt weder Route Server noch bilaterale Sitzung noch die Instanz, die eine Anfrage beantwortete.

Zwischen Kennung und DNS-Antwort liegen mehrere Übergänge: Das Präfix wird angekündigt, ein Nachbar akzeptiert es, die Auswahl bevorzugt einen Pfad, Anycast führt zu einer Instanz, die Anwendung ist gesund und die angefragte Zone geladen. Die öffentlichen Quellen erklären die Kennungen. Sie ersetzen nicht die unbeobachteten Übergänge.

AS37181 trägt die DotARPA-Kette

Für DotARPA veröffentlicht der Leitfaden ein anderes Set: AS37181, 196.216.169.0/24 für IPv4 und 2001:43f8:110::/48 für IPv6. Die Werte ähneln jenen von NS2, sind aber nicht identisch. Ihre Nähe erleichtert eine kompakte Tabelle und erhöht zugleich das Risiko eines Übertragungsfehlers. Sie begründet keine betriebliche Einheit.

Auch die Funktion ist eine andere. AFRINIC verbindet AS37181 mit der Reverse-DNS-Infrastruktur aus RFC 5855. Dieser Standard schuf eigene Nameserver-Identitäten für IN-ADDR.ARPA und IP6.ARPA. Die Trennung soll unnötig gemeinsame Abhängigkeiten mit anderen DNS-Funktionen vermeiden, damit ein fremder Fehler nicht zum Kollateralausfall des Reverse-Baums wird. Ein eigenes ASN und eigene Präfixe machen diese Grenze in der Routing-Schicht sichtbar.

Daraus folgt nicht, dass jede afrikanische PTR-Anfrage diese Instanz erreicht. DNS folgt Delegationen, Verweisen und Caches. Anycast ergänzt die Auswahl der Instanz anhand der vom Ursprung sichtbaren Routen. Entscheidend sind der angefragte Name, der Cache-Zustand des Resolvers, seine Routing-Sicht und die Gesundheit der ausgewählten Anwendung.

DotARPA ist auch nicht mit einer Root-Server-Kopie gleichzusetzen. AFRINIC bezeichnet sein separates Root-Server-Copy-Programm als Vermittlung und erklärt ausdrücklich, nicht selbst Betreiber der Kopie zu sein. Die jeweilige Root-Server-Organisation bleibt Betreiberin. Mehrere Programme können DNS-Infrastruktur regional verteilen wollen, ohne Autorität und Betrieb zu teilen.

RDAP und PeeringDB belegen auch für AS37181 die veröffentlichte Ressourcen- und Anschlussidentität. Eine Route oder DNS-Antwort belegen sie nicht. Daraus folgt eine einfache Regel: Ein erfolgreicher NS2-Test unter AS37177 füllt kein DotARPA-Gesundheitsfeld, und eine AS37181-Route sagt nichts über NS2 aus.

Bei Anycast ist „lokal“ eine datierte Beobachtung

Anycast erlaubt mehreren Dienstinstanzen, dieselbe Dienstadresse anzukündigen. Das Routing bestimmt für jeden Ursprung, welche Instanz erreicht wird. So lässt sich ein Dienst verteilen, ohne dass der Client einen Standort auswählt. Gleichzeitig bekommt der Satz „Der Dienst ist in Uganda“ mehrere mögliche Bedeutungen.

Eine physische oder virtuelle Maschine kann im Land stehen. Das Dienst-ASN kann eine UIXP-Schnittstelle besitzen. Ein ugandisches Netz kann die Dienstpräfixe lernen. Eine konkrete Anfrage aus diesem Netz kann von der ugandischen Instanz beantwortet werden. Die vier Aussagen hängen zusammen, sind aber nicht austauschbar. Eine Maschine kann ohne Ankündigung existieren; eine Route kann trotz ausgefallener Anwendung bleiben; eine gesunde Anwendung kann durch die Policy eines Netzes umgangen werden; ein Cache kann verhindern, dass die Anfrage überhaupt zum autoritativen Dienst gelangt.

RFC 4786 trennt BGP-Erreichbarkeit und Anwendungsgesundheit ausdrücklich. Fällt der DNS-Prozess aus, während das Präfix sichtbar bleibt, liefert das Routing den Verkehr effizient an eine unbrauchbare Instanz. Der Betrieb braucht daher eine Verbindung zwischen Gesundheitsprüfung und Routenrückzug oder einer anderen Sperre. Eine grüne BGP-Anzeige ist kein DNS-Test.

Auch die umgekehrte Abweichung ist möglich. Der Dienst ist gesund, doch ein lokales Netz lernt die Route nicht: Es nutzt vielleicht keinen Route Server, hat keine bilaterale Sitzung, verwirft das Präfix oder bevorzugt einen anderen Pfad. Anycast garantiert nicht geografische Nähe. Es wählt nach der Topologie und den Policies, die BGP sichtbar macht.

RFC 7094 behandelt Instanzauswahl und Leistung deshalb als verteiltes Messproblem. Ein Looking Glass zeigt die Sicht eines Sammlers. Eine DNS-Abfrage zeigt die Erfahrung eines Ursprungs zu einer Zeit. Für eine regionale Aussage braucht es mehrere Messpunkte, Wiederholung und ein Verfahren zur Identifikation der antwortenden Instanz. Ohne Instanzkennung beweist niedrige Latenz keinen Uganda-Standort; ohne Zeitreihe beweist ein Erfolg keine Verfügbarkeit.

AFRINIC nennt Leistung und Resilienz als Ziele seines Programms. Die Architektur macht solche Vorteile plausibel. Das hier eingefrorene Quellenpaket enthält jedoch keinen Vorher-Nachher-Vergleich für UIXP, keinen Failover-Test, keine Uptime-Reihe und keine Verteilung von Anfragen auf Standorte. Es beweist nicht, dass kein Nutzen besteht. Es beweist ebenso wenig, dass ein Nutzen gemessen wurde. Ziel, Anschluss und Ergebnis gehören in getrennte Felder.

Auch die Verantwortung ist geteilt

Der Leitfaden verlangt BGP-Fähigkeit sowie getrennte Management- und Peering-Netze. Für die OVA nennt er als veröffentlichte Basis zwei virtuelle CPUs, vier Gigabyte Arbeitsspeicher und zehn Gigabyte Speicher. Das sind Anforderungen an einen Host, keine Topologieaufnahme der UIXP-Bereitstellung. Die Quellen sagen nicht, ob ein oder zwei virtuelle Systeme, ein gemeinsamer physischer Host oder Redundanz eingesetzt werden.

Der Host stellt Infrastruktur, Strom und Netzverbindung bereit, arbeitet an der Verfügbarkeit und meldet Ausfälle an AFRINIC. AFRINIC wartet Software und Konfiguration, behandelt Sicherheitsfragen, koordiniert BGP, überwacht die Dienstgesundheit und arbeitet bei der Fehlersuche mit. Die Aufteilung ist für einen gemeinschaftlichen Dienst normal. Sie verlangt aber einen feineren Nachweis als „AFRINIC-Knoten ausgefallen“.

Bleibt die Route bei einem DNS-Ausfall bestehen, sind Gesundheitssignal und Rückzugslogik zu prüfen, wobei die Ursache in Software, Virtualisierung, Strom oder Verbindung liegen kann. Ist DNS gesund, aber ein Mitglied lernt die Route nicht, rücken Sitzung, Route Server, Filter und Policy in den Mittelpunkt. Antwortet NS2, aber DotARPA nicht, verbirgt ein gemeinsamer Online-Status die Hälfte des Vorfalls. Funktioniert IPv4, IPv6 aber nicht, ist selbst die ASN-Ebene noch zu grob.

Die Lösung besteht nicht darin, vorschnell einen Alleinverantwortlichen zu bestimmen. Sie besteht darin, Dienst, ASN, Adressfamilie, Peering-Art, Gesundheitssignal, beobachtete Instanz und den kontrollierenden Akteur an jedem Übergang zu bewahren.

Fünf Evidenzschichten dürfen sich nicht vertreten

Die öffentlichen Angaben lassen sich in fünf Schichten ordnen. Programmdokumente beschreiben Zweck und Konstruktion. RDAP beschreibt die Registrierung von Kennungen. UIXP und PeeringDB beschreiben die erklärte Austausch-Schnittstelle. Looking Glass und Teilnehmer-RIBs würden beobachtete Routen beschreiben. DNS-Messungen würden Anfrage, Antwort und Instanz beschreiben.

Die ersten drei Schichten liegen vor, die letzten beiden wurden nicht erfasst. Ihr Fehlen widerlegt die Verbindung nicht. Das Vorliegen von Verbindung und Registrierung erfindet keine Route und keine Antwort. Diese Ordnung schützt sowohl vor der Behauptung, ohne öffentliche Messung gebe es keinen Knoten, als auch vor der Behauptung, ein vollständiger Verzeichniseintrag belege den Nutzen.

Eine „offene“ Peering-Policy drückt Bereitschaft aus, nicht die Menge aller bestehenden Sitzungen. „Direkt verbunden“ beschreibt eine Schnittstelle am Fabric, nicht die aktuell sichtbaren Präfixe. Das Jahr 2025 ist eine Verzeichniseigenschaft, nicht automatisch Installationsdatum, Aktivierungsdatum, erste Ankündigung oder erste erfolgreiche Anfrage. Jeder Zeitwert muss beim Ereignis bleiben, das er bezeichnet.

Die Routing-Schicht muss Präfix und Adressfamilie nennen. Für AS37177 sind die beiden NS2-Blöcke zu suchen, für AS37181 die beiden DotARPA-Blöcke. Nur IPv4 zu sehen belegt keinen vollständigen Dual-Stack-Betrieb. Nur die Route-Server-Sicht zu sehen belegt nicht die Auswahl aller Teilnehmer. Die DNS-Schicht braucht Name und Typ der Anfrage, rekursiven oder autoritativen Modus, Antwortcode, Instanzmethode und Zeitpunkt. Latenz allein ist keine Identität.

Sind die Schichten getrennt, werden Abweichungen zu konkreten Fragen: Hat sich die Registrierung geändert, ist die Sitzung gefallen, wurde das Präfix gefiltert, ist die Anwendung krank, fehlt die Zone oder hat der Resolver einen anderen Standort gewählt?

Zwei Belege für einen öffentlichen Standort

Der NS2-Beleg beginnt mit AS37177 und 196.216.168.0/24 sowie 2001:43f8:120::/48. Der DotARPA-Beleg beginnt mit AS37181 und 196.216.169.0/24 sowie 2001:43f8:110::/48. Die UIXP-Adressen .5/::5 und .6/::6 bleiben als Peering-Schnittstellen in einem eigenen Feld.

Der Routing-Teil trennt IPv4 und IPv6 und notiert erwartetes Präfix, Sichtbarkeit, Sammler, Nachbar oder Route Server und Zeit. Der Anwendungsteil nennt Dienstklasse oder Namensraum, Gesundheitszustand und Verbindung zum Rückzug. Der Beobachtungsteil enthält Messpunkt, Resolver-Modus, Abfragename und -typ, Antwortcode, Latenz, Instanzkennung und Zeit. Ein Hash der Messserie bindet die Zusammenfassung an die Daten.

Kein Feld ist eine Abkürzung. „Aktiviert“ belegt keine aktuelle Route. Eine Route belegt kein gesundes DNS. Eine richtige Antwort belegt nicht alle erwarteten Zonen. Eine niedrige Latenz an einem Punkt belegt keine regionale Verbesserung. Der Wert des Belegs liegt darin, die Übergänge zu bewahren.

Heute ist eine begrenzte Aussage belastbar: Zwei verschieden adressierte AFRINIC-DNS-Dienste sind als direkte UIXP-Verbindungen aufgeführt und besitzen getrennte veröffentlichte Ressourcenketten. Die Quellen belegen nicht, dass alle einschlägigen Anfragen in Uganda landen oder Latenz und Resilienz messbar verbessert wurden. Wenn dieser Nachweis entsteht, sollte er als zwei Betriebsbelege erscheinen, nicht als Leuchten eines einzelnen Kartenpunkts.

Quellen

  1. AFRINIC-Leitfaden für DNS-Anycast-Bereitstellung: https://dns.afrinic.net/deployment-guide/
  2. AFRINIC-DNS-Programm: https://dns.afrinic.net/
  3. Verbundene UIXP-Netze: https://www.uixp.co.ug/networks
  4. UIXP-Dienste und Route Server: https://www.uixp.co.ug/services
  5. AFRINIC AfDSP: https://afrinic.net/dns-support.html
  6. AFRINIC Root-Server-Copy-Programm: https://afrinic.net/root-server-copy.html
  7. RFC 5855: https://www.rfc-editor.org/rfc/rfc5855.html
  8. RFC 4786: https://www.rfc-editor.org/rfc/rfc4786.html
  9. RFC 7094: https://www.rfc-editor.org/rfc/rfc7094.html
  10. RFC 1034: https://www.rfc-editor.org/rfc/rfc1034.html
  11. AFRINIC RDAP, AS37177: https://rdap.afrinic.net/rdap/autnum/37177
  12. AFRINIC RDAP, AS37181: https://rdap.afrinic.net/rdap/autnum/37181
  13. RDAP, 196.216.168.0/24: https://rdap.afrinic.net/rdap/ip/196.216.168.0
  14. RDAP, 196.216.169.0/24: https://rdap.afrinic.net/rdap/ip/196.216.169.0
  15. RDAP, 2001:43f8:120::/48: https://rdap.afrinic.net/rdap/ip/2001:43f8:120::
  16. RDAP, 2001:43f8:110::/48: https://rdap.afrinic.net/rdap/ip/2001:43f8:110::
  17. PeeringDB-API, AS37177: https://www.peeringdb.com/api/netixlan?asn=37177
  18. PeeringDB-API, AS37181: https://www.peeringdb.com/api/netixlan?asn=37181