DNS Test from Sudafrica

Le verifiche DNS dal nodo di Johannesburg interrogano i nameserver autoritativi direttamente da AS396982 (Google LLC, Johannesburg) e restituiscono i record risolti con il tempo di query. Google opera il proprio resolver DNS anycast (8.8.8.8) con un nodo a JHB, e Cloudflare (1.1.1.1) ha anche presenza anycast sudafricana. Le query DNS verso questi provider dal nodo JHB completano in meno di 5 ms. Per i server autoritativi senza un nodo anycast africano, le query si instradano alla location disponibile più vicina — tipicamente Londra o Amsterdam, aggiungendo 160-170 ms a ogni lookup DNS. A scala, questo overhead di lookup DNS è l'elemento di latenza più impattante per gli utenti africani che colpiscono servizi globalmente distribuiti.

Il nodo Google di Johannesburg è la location corretta per validare le regole GeoDNS che prendono di mira il Sudafrica o l'Africa Subsahariana. I prefixi AS396982 di Johannesburg sono correttamente geolocalizzati nel Sudafrica nelle policy di routing di geolocalizzazione AWS Route 53, nelle regole geo dei load balancer Cloudflare e nelle catene di filtri NS1. Una verifica DNS da questo nodo conferma che la tua policy di routing rivolta al ZA o all'Africa restituisce il record previsto — idealmente un IP JHB o europeo a seconda della tua strategia di origine più vicina. Se il nodo del Sudafrica riceve un IP USA dal tuo GeoDNS quando intendevi servire gli utenti africani da un'origine europea, il confine della policy non è correttamente impostato per lo spazio IP AFRINIC.

La gestione dei TTL conta di più per gli utenti africani che per quelli europei. Un utente africano il cui resolver ISP cachea un record obsoleto deve aspettare che il TTL completo scada per ottenere la risposta aggiornata — e poiché molti ISP africani eseguono i propri resolver con capacità limitata, potrebbero anche applicare un negative caching aggressivo. Le verifiche DNS dal nodo sudafricano dopo una modifica dei record confermano che il server autoritativo sta restituendo il nuovo record. Se il nodo JHB vede il vecchio record ma i nodi europei vedono quello nuovo, il problema è probabilmente il delay di propagazione verso un nodo anycast nelle vicinanze di Johannesburg e non un problema del server autoritativo stesso.

Johannesburg è l'hub internet dell'Africa Subsahariana. La città hosta NAP Africa presso la struttura JHB1 di Teraco — il maggiore punto di colocation e peering carrier-neutral del continente. Teraco JHB1 alloggia oltre 200 reti incluse MTN (AS37457), Vodacom (AS36874), Telkom SA (AS10474) e le maggiori reti content incluse Google, Meta e Akamai. Il nostro nodo probe opera su AS396982 (Google LLC) in un data center Google a Johannesburg, riflettendo l'investimento diretto di Google nell'infrastruttura di rete africana come parte della loro strategia di espansione regionale. Google opera la propria fibra e gli accordi di peering a JHB, collegandosi all'ampio ecosistema internet sudafricano via Teraco e NAP Africa.

La connettività internazionale del Sudafrica si affida a sistemi di cavi sottomarini che attraccano in più punti lungo le coste orientale e occidentale. SEACOM (operativo dal 2009) collega la costa dell'Africa Orientale all'Europa via il Medio Oriente. WACS (West Africa Cable System) corre lungo la costa occidentale collegando il Sudafrica all'Europa via l'Africa Occidentale. EAST AFRICA MARINE SYSTEM (EASSy) fornisce capacità aggiuntiva sulla costa orientale. La combinazione di più sistemi di cavi che attraccano in Sudafrica dà a JHB una migliore diversità di percorsi verso l'Europa rispetto alla maggior parte delle altre città africane, anche se la banda totale disponibile rimane vincolata rispetto ai punti di interconnessione europei o nordamericani.

RTT di riferimento dal nodo Google di Johannesburg: JHB-Londra è approssimativamente 160 ms, JHB-Amsterdam 165 ms, JHB-Francoforte 170 ms, JHB-New York 200-210 ms, JHB-Singapore 200-210 ms, JHB-Nairobi 30-40 ms, JHB-Lagos 90-100 ms. Le cifre di latenza verso Londra e Amsterdam sono più basse di quanto molti si aspettino — SEACOM e WACS forniscono percorsi ragionevolmente diretti verso l'Europa senza il routing multi-hop dei vecchi link dipendenti dai satelliti. Questi percorsi in cavo sottomarino hanno reso il Sudafrica uno dei paesi meglio connessi dell'Africa per la latenza internazionale.

La presenza di Google a Johannesburg via AS396982 fa parte della più ampia strategia africana di Google, che include i nodi Google Cache (GGC) deployati con gli ISP sudafricani e il cavo sottomarino Equiano (che collega il Sudafrica al Portogallo). Il prefixi AS396982 a JHB è correttamente identificato come un ASN di infrastruttura Google da tutti i maggiori database GeoIP. Il traffico da questo nodo verrà riconosciuto come in origine dall'infrastruttura sudafricana di un maggiore provider cloud — rilevante per i servizi che applicano regole di routing o rate limiting diverse agli IP sorgente dei provider cloud rispetto agli IP degli ISP residenziali. DE-CIX Johannesburg, lanciato come parte dell'espansione africana di DE-CIX, fornisce opzioni di interconnessione aggiuntive oltre a NAP Africa e JINX.

Il backbone domestico del Sudafrica collega Johannesburg a Città del Capo, Durban e Pretoria via fibra long-haul operata da Telkom SA e un numero crescente di operatori privati. JHB-Città del Capo è approssimativamente 30 ms, JHB-Durban 15-20 ms. Il nodo di Johannesburg è di gran lunga la location di test più rilevante per le condizioni di rete dell'Africa Subsahariana — si trova al principale hub di peering del continente con accesso diretto a tutti i maggiori percorsi carrier africani e internazionali. Per qualsiasi servizio rivolto ad audience africane, un test HTTP o ping da questo nodo è il primo passo per capire il quadro della connettività continentale.