Testy DNS z węzła johannesburskiego zapytują autorytatywne serwery nazw bezpośrednio z AS396982 (Google LLC, Johannesburg) i zwracają rozwiązane rekordy z czasem zapytania. Google operuje własnym anycastowym resolverem DNS (8.8.8.8) z węzłem JHB, a Cloudflare (1.1.1.1) też ma południowoafrykańską obecność Anycast. Zapytania DNS do tych dostawców z węzła JHB ukończą się w poniżej 5 ms. Dla autorytatywnych serwerów bez węzła Anycast w Afryce, zapytania trasują do najbliższej dostępnej lokalizacji — typowo Londynu lub Amsterdamu, dodając 160–170 ms do każdego wyszukiwania DNS. W skali, ten narzut wyszukiwania DNS to najbardziej impaktujący element opóźnienia dla afrykańskich użytkowników trafiających na globalnie dystrybuowane usługi.

Węzeł Google w Johannesburgu to właściwa lokalizacja do walidacji reguł GeoDNS kierowanych do Afryki Południowej lub Afryki Subsaharyjskiej. Prefiksy AS396982 Johannesburg są poprawnie geolokalizowane do Afryki Południowej w politykach routingu geolokalizacji AWS Route 53, regułach geo load balancera Cloudflare i łańcuchach filtrów NS1. Test DNS z tego węzła potwierdza, że twoja polityka routingu skierowana do ZA lub Afryki zwraca zamierzony rekord — idealnie JHB lub europejskie IP zależnie od strategii najbliższego originu. Jeśli węzeł z Afryki Południowej otrzymuje US IP z twojego GeoDNS, gdy zamierzałeś obsługiwać afrykańskich użytkowników z europejskiego originu, granica polityki nie jest poprawnie ustawiona dla przestrzeni IP AFRINIC.

Zarządzanie TTL ma większe znaczenie dla afrykańskich użytkowników niż dla europejskich. Afrykański użytkownik, którego resolver ISP buforuje przestarzały rekord, musi poczekać na pełne wygaśnięcie TTL przed uzyskaniem zaktualizowanej odpowiedzi — i ponieważ wielu afrykańskich ISP uruchamia własne resolvery z ograniczoną przepustowością, mogą też stosować agresywne negatywne buforowanie. Testy DNS z węzła Afryki Południowej po zmianie rekordu potwierdzają, że autorytatywny serwer zwraca nowy rekord. Jeśli węzeł JHB widzi stary rekord, gdy europejskie węzły widzą nowy, problem to prawdopodobnie opóźnienie propagacji do węzła Anycast bliskiego Johannesburgowi, a nie problem z samym autorytatywnym serwerem.

Johannesburg jest hubem internetowym Afryki Subsaharyjskiej. Miasto gości NAP Africa w obiekcie JHB1 Teraco — największym neutralnym dla operatorów obiekcie kolokacyjnym i peeringowym na kontynencie. Teraco JHB1 gości ponad 200 sieci, w tym MTN (AS37457), Vodacom (AS36874), Telkom SA (AS10474) i główne sieci content, w tym Google, Meta i Akamai. Nasz węzeł sondujący działa na AS396982 (Google LLC) w centrum danych Google w Johannesburgu, odzwierciedlając bezpośrednią inwestycję Google w afrykańską infrastrukturę sieciową jako część ich regionalnej strategii ekspansji. Google operuje własnym światłowodem i umowami peeringowymi w JHB, łącząc się z szerszym południowoafrykańskim ekosystemem internetowym przez Teraco i NAP Africa.

Łączność międzynarodowa Republiki Południowej Afryki opiera się na systemach kabli podmorskich lądujących w wielu punktach wzdłuż wschodnich i zachodnich wybrzeży. SEACOM (operacyjny od 2009) łączy wybrzeże wschodniej Afryki z Europą przez Bliski Wschód. WACS (West Africa Cable System) biegnie wzdłuż zachodniego wybrzeża łącząc RPA z Europą przez Afrykę Zachodnią. EASSy (East Africa Marine System) zapewnia dodatkową przepustowość wschodniego wybrzeża. Kombinacja wielu systemów kablowych lądujących w RPA daje JHB lepszą różnorodność ścieżek do Europy niż większość innych miast afrykańskich, choć całkowita dostępna przepustowość pozostaje ograniczona w porównaniu z europejskimi lub północnoamerykańskimi punktami interconnect.

Referencyjne RTT z węzła Google w Johannesburgu: JHB do Londynu to około 160 ms, JHB do Amsterdamu 165 ms, JHB do Frankfurtu 170 ms, JHB do Nowego Jorku 200–210 ms, JHB do Singapuru 200–210 ms, JHB do Nairobi 30–40 ms, JHB do Lagos 90–100 ms, JHB do Kapsztadu 30 ms. Wartości opóźnienia do Londynu i Amsterdamu są niższe niż wielu oczekuje — SEACOM i WACS zapewniają stosunkowo bezpośrednie ścieżki do Europy bez wieloskokowego routingu starszych łączy satelitarnych. Te ścieżki kabli podmorskich uczyniły RPA jednym z najlepiej połączonych krajów w Afryce dla opóźnienia międzynarodowego.

Obecność Google w Johannesburgu przez AS396982 jest częścią szerszej afrykańskiej strategii Google, obejmującej węzły Google Cache (GGC) wdrożone u południowoafrykańskich ISP i kabel podmorski Equiano (łączący RPA z Portugalią). Prefiks AS396982 w JHB jest poprawnie identyfikowany jako Google infrastructure ASN przez wszystkie główne bazy GeoIP. Ruch z tego węzła będzie rozpoznawany jako wywodzący się z afrykańskiej infrastruktury głównego dostawcy chmury — istotne dla usług stosujących różne reguły routingu lub limitowania dla IP chmurowych dostawców źródłowych w stosunku do rezydencjalnych IP ISP. DE-CIX Johannesburg, uruchomiony jako część afrykańskiej ekspansji DE-CIX, zapewnia dodatkowe opcje interconnect poza NAP Africa i JINX.

Krajowy szkielet RPA łączy Johannesburg z Kapsztadem, Durbanem i Pretorią przez dalekodystansowe światłowody operowane przez Telkom SA i rosnącą liczbę prywatnych operatorów. JHB do Kapsztadu to około 30 ms, JHB do Durbanu 15–20 ms. Węzeł johannesburski jest zdecydowanie najbardziej istotną lokalizacją testową dla warunków sieciowych Afryki Subsaharyjskiej — siedzi na głównym hubem peeringowym kontynentu z bezpośrednim dostępem do wszystkich głównych afrykańskich i międzynarodowych ścieżek operatorów. Dla każdej usługi kierowanej do afrykańskiej publiczności, test HTTP lub pingu z tego węzła to pierwszy krok w rozumieniu kontynentalnego obrazu łączności.