Las comprobaciones DNS desde el nodo de Johannesburgo consultan los nameservers autoritativos directamente desde AS396982 (Google LLC, Johannesburgo) y devuelven los registros resueltos con el tiempo de consulta. Google opera su propio resolver DNS anycast (8.8.8.8) con un nodo JHB, y Cloudflare (1.1.1.1) también tiene presencia anycast en Sudáfrica. Las consultas DNS a estos proveedores desde el nodo JHB se completan en menos de 5 ms. Para los servidores autoritativos sin nodo anycast africano, las consultas enrutan a la ubicación disponible más cercana, típicamente Londres o Ámsterdam, añadiendo 160–170 ms a cada búsqueda DNS. A escala, este overhead de búsqueda DNS es el elemento de latencia más impactante para los usuarios africanos que acceden a servicios distribuidos globalmente.

El nodo de Google en Johannesburgo es la ubicación correcta para validar las reglas GeoDNS dirigidas a Sudáfrica o al África Subsahariana. Los prefijos AS396982 de Johannesburgo están correctamente geolocalizados en Sudáfrica en las políticas de routing de geolocalización de AWS Route 53, las reglas geo del balanceador de carga de Cloudflare y las cadenas de filtro de NS1. Una comprobación DNS desde este nodo confirma que tu política de routing dirigida a ZA o África devuelve el registro previsto: idealmente una IP de JHB o europea dependiendo de tu estrategia de origen más cercano. Si el nodo de Sudáfrica recibe una IP de EE. UU. de tu GeoDNS cuando pretendías servir a los usuarios africanos desde un origen europeo, el límite de la política no está correctamente configurado para el espacio de IP de AFRINIC.

La gestión del TTL importa más para los usuarios africanos que para los europeos. Un usuario africano cuyo resolver ISP cachea un registro obsoleto debe esperar a que expire el TTL completo antes de obtener la respuesta actualizada: y como muchos ISP africanos ejecutan sus propios resolvers con capacidad limitada, también pueden aplicar caché negativa agresiva. Las comprobaciones DNS desde el nodo de Sudáfrica tras un cambio de registro confirman que el servidor autoritativo está devolviendo el nuevo registro. Si el nodo JHB ve el registro antiguo pero los nodos europeos ven el nuevo, el problema es probablemente un retraso de propagación hacia un nodo anycast próximo a Johannesburgo, no un problema con el propio servidor autoritativo.

Johannesburgo es el hub de Internet del África Subsahariana. La ciudad alberga NAP Africa en la instalación JHB1 de Teraco: el mayor punto de colocation y peering neutral del continente. Teraco JHB1 aloja más de 200 redes, incluyendo MTN (AS37457), Vodacom (AS36874), Telkom SA (AS10474), y las principales redes de contenido como Google, Meta y Akamai. Nuestro nodo sonda corre en AS396982 (Google LLC) en un datacenter de Google en Johannesburgo, reflejando la inversión directa de Google en la infraestructura de red africana como parte de su estrategia de expansión regional. Google opera su propia fibra y acuerdos de peering en JHB, conectando al ecosistema de Internet sudafricano más amplio a través de Teraco y NAP Africa.

La conectividad internacional de Sudáfrica depende de los sistemas de cables submarinos que aterrizan en múltiples puntos a lo largo de las costas este y oeste. SEACOM (operativo desde 2009) conecta la costa este africana con Europa vía Oriente Medio. WACS (West Africa Cable System) discurre por la costa oeste conectando Sudáfrica con Europa a través de África Occidental. EAST AFRICA MARINE SYSTEM (EASSy) proporciona capacidad adicional en la costa este. La combinación de múltiples sistemas de cables que aterrizan en Sudáfrica da a JHB mejor diversidad de rutas hacia Europa que la mayoría de las demás ciudades africanas, aunque el ancho de banda total disponible sigue siendo limitado en comparación con los puntos de interconexión europeos o norteamericanos.

RTT de referencia desde el nodo de Google en Johannesburgo: JHB a Londres es aproximadamente 160 ms, JHB a Ámsterdam 165 ms, JHB a Fráncfort 170 ms, JHB a Nueva York 200–210 ms, JHB a Singapur 200–210 ms, JHB a Nairobi 30–40 ms, JHB a Lagos 90–100 ms. Las cifras de latencia a Londres y Ámsterdam son menores de lo que mucha gente espera: SEACOM y WACS proporcionan rutas razonablemente directas a Europa sin el routing multisalto de los antiguos enlaces dependientes de satélite. Estas rutas de cable submarino han convertido a Sudáfrica en uno de los países mejor conectados de África para la latencia internacional.

La presencia de Google en Johannesburgo vía AS396982 forma parte de la estrategia africana más amplia de Google, que incluye nodos Google Cache (GGC) desplegados con los ISP sudafricanos y el cable submarino Equiano (que conecta Sudáfrica con Portugal). El prefijo AS396982 en JHB está correctamente identificado como un ASN de infraestructura de Google por todas las principales bases de datos GeoIP. El tráfico desde este nodo será reconocido como originado desde la infraestructura sudafricana de un importante proveedor cloud: relevante para los servicios que aplican diferentes reglas de routing o limitación de tasa a las IPs de origen de proveedores cloud frente a las de ISP residenciales. DE-CIX Johannesburg, lanzado como parte de la expansión africana de DE-CIX, proporciona opciones de interconexión adicionales más allá de NAP Africa y JINX.

El backbone doméstico de Sudáfrica conecta Johannesburgo con Ciudad del Cabo, Durban y Pretoria sobre fibra de larga distancia operada por Telkom SA y un número creciente de operadores privados. JHB a Ciudad del Cabo es aproximadamente 30 ms, JHB a Durban 15–20 ms. El nodo de Johannesburgo es con diferencia la ubicación de prueba más relevante para las condiciones de red del África Subsahariana: se sitúa en el principal hub de peering del continente con acceso directo a todas las rutas importantes de operadores africanos e internacionales. Para cualquier servicio dirigido a audiencias africanas, una prueba HTTP o de ping desde este nodo es el primer paso para entender la conectividad continental.