DNS-Checks vom Johannesburger Knoten fragen autoritative Nameserver direkt von AS396982 (Google LLC, Johannesburg) ab und geben die aufgelösten Records mit Abfragezeit zurück. Google betreibt seinen eigenen Anycast-DNS-Resolver (8.8.8.8) mit einem JHB-Knoten, und Cloudflare (1.1.1.1) hat ebenfalls südafrikanische Anycast-Präsenz. DNS-Abfragen zu diesen Providern vom JHB-Knoten schließen in unter 5 ms ab. Für autoritative Server ohne afrikanischen Anycast-Knoten routen Abfragen zum nächsten verfügbaren Standort – typischerweise London oder Amsterdam –, was 160–170 ms zu jedem DNS-Lookup hinzufügt. Im Maßstab ist dieser DNS-Lookup-Overhead das wirkungsvollste Latenzelement für afrikanische Nutzer, die global verteilte Dienste aufrufen.

Der Johannesburger Google-Knoten ist der korrekte Standort zur Validierung von GeoDNS-Regeln, die Südafrika oder das subsaharische Afrika anvisieren. AS396982 Johannesburg-Präfixe sind in AWS Route 53 Geolocation-Routing-Policies, Cloudflare Load Balancer Geo-Regeln und NS1 Filter-Chains korrekt zu Südafrika geolokalisiert. Ein DNS-Check von diesem Knoten bestätigt, dass Ihre ZA- oder Afrika-angesteuerte Routing-Policy den beabsichtigten Record zurückgibt – idealerweise eine JHB- oder europäische IP, abhängig von Ihrer nächstgelegenen-Ursprung-Strategie. Wenn der südafrikanische Knoten eine US-IP von Ihrem GeoDNS erhält, wenn Sie beabsichtigt haben, afrikanische Nutzer von einem europäischen Ursprung zu bedienen, ist die Policy-Grenze für den AFRINIC-IP-Raum nicht korrekt gesetzt.

TTL-Management ist für afrikanische Nutzer wichtiger als für europäische. Ein afrikanischer Nutzer, dessen ISP-Resolver einen veralteten Record gecacht hat, muss warten bis das vollständige TTL abgelaufen ist, bevor er die aktualisierte Antwort erhält – und da viele afrikanische ISPs eigene Resolver mit begrenzter Kapazität betreiben, können sie auch aggressives negatives Caching anwenden. DNS-Checks vom südafrikanischen Knoten nach einer Record-Änderung bestätigen, dass der autoritative Server den neuen Record zurückgibt. Wenn der JHB-Knoten den alten Record sieht, europäische Knoten aber den neuen, liegt das Problem wahrscheinlich an der Propagationsverzögerung zu einem Johannesburg-nahen Anycast-Knoten, kein Problem mit dem autoritativen Server selbst.

Johannesburg ist der Internet-Hub des subsaharischen Afrikas. Die Stadt beherbergt NAP Africa in Teracos JHB1-Einrichtung – dem größten carrierneutralen Colocation- und Peering-Punkt auf dem Kontinent. Teraco JHB1 beherbergt über 200 Netze, darunter MTN (AS37457), Vodacom (AS36874), Telkom SA (AS10474) sowie wichtige Content-Netze wie Google, Meta und Akamai. Unser Probe-Knoten läuft auf AS396982 (Google LLC) in einem Google-Rechenzentrum in Johannesburg und spiegelt Googles direkte Investition in afrikanische Netzwerkinfrastruktur als Teil ihrer regionalen Expansionsstrategie wider. Google betreibt eigene Glasfaser- und Peering-Vereinbarungen in JHB und verbindet sich über Teraco und NAP Africa mit dem breiteren südafrikanischen Internet-Ökosystem.

Südafrikas internationale Konnektivität basiert auf Seekabelsystemen, die an mehreren Punkten entlang der östlichen und westlichen Küstenlinien anlanden. SEACOM (seit 2009 in Betrieb) verbindet die ostafrikanische Küste über den Nahen Osten mit Europa. WACS (West Africa Cable System) verläuft entlang der Westküste und verbindet Südafrika über Westafrika mit Europa. Das EAST AFRICA MARINE SYSTEM (EASSy) bietet zusätzliche Ostküstenkapazität. Die Kombination mehrerer in Südafrika anlandender Kabelsysteme gibt JHB eine bessere Pfaddiversität nach Europa als die meisten anderen afrikanischen Städte, obwohl die insgesamt verfügbare Bandbreite im Vergleich zu europäischen oder nordamerikanischen Interconnect-Punkten begrenzt bleibt.

Referenz-RTTs vom Johannesburger Google-Knoten: JHB nach London beträgt ungefähr 160 ms, JHB nach Amsterdam 165 ms, JHB nach Frankfurt 170 ms, JHB nach New York 200–210 ms, JHB nach Singapur 200–210 ms, JHB nach Nairobi 30–40 ms, JHB nach Lagos 90–100 ms. Die Latenzwerte nach London und Amsterdam sind niedriger als viele erwarten – SEACOM und WACS bieten vernünftig direkte Pfade nach Europa ohne das Mehrhop-Routing älterer satellitenabhängiger Verbindungen. Diese Seekabelpfade haben Südafrika zu einem der am besten vernetzten Länder Afrikas für internationale Latenz gemacht.

Googles Präsenz in Johannesburg über AS396982 ist Teil von Googles breiterer afrikanischer Strategie, die Google Cache (GGC)-Knoten umfasst, die bei südafrikanischen ISPs eingesetzt werden, sowie das Equiano-Seekabel (das Südafrika mit Portugal verbindet). Das AS396982-Präfix in JHB wird von allen wichtigen GeoIP-Datenbanken korrekt als Google-Infrastruktur-ASN identifiziert. Traffic von diesem Knoten wird als von der südafrikanischen Infrastruktur eines großen Cloud-Providers stammend erkannt – relevant für Dienste, die auf Cloud-Provider-Quell-IPs im Vergleich zu privaten ISP-IPs unterschiedliche Routing- oder Rate-Limiting-Regeln anwenden. DE-CIX Johannesburg, im Rahmen von DE-CIXs afrikanischer Expansion eingeführt, bietet zusätzliche Interconnection-Optionen jenseits von NAP Africa und JINX.

Südafrikas inländisches Backbone verbindet Johannesburg über Langstreckenglasfaser mit Kapstadt, Durban und Pretoria, betrieben von Telkom SA und einer wachsenden Anzahl privater Betreiber. JHB nach Kapstadt beträgt ungefähr 30 ms, JHB nach Durban 15–20 ms. Der Johannesburger Knoten ist bei weitem der relevanteste Teststandort für subsaharische afrikanische Netzwerkbedingungen – er sitzt am wichtigsten Peering-Hub des Kontinents mit direktem Zugang zu allen wichtigen afrikanischen und internationalen Carrier-Pfaden. Für jeden Dienst, der auf afrikanische Zielgruppen ausgerichtet ist, ist ein HTTP- oder Ping-Test von diesem Knoten der erste Schritt zum Verständnis des kontinentalen Konnektivitätsbilds.