Resumen

  • UIXP enumera dos redes DNS de AFRINIC conectadas directamente a su LAN de peering: AFDSP bajo AS37177 y DotARPA bajo AS37181. La guía de despliegue de AFRINIC asigna a cada una un par diferente de prefijos IPv4 e IPv6.
  • NS2 presta DNS secundario y no decide el contenido de las zonas; DotARPA forma parte de una cadena separada para DNS inverso. Una observación de un servicio no demuestra el estado del otro.
  • Un registro del directorio, una asignación RDAP y una interfaz en PeeringDB prueban identidad y superficie de interconexión. No prueban anuncios BGP actuales, uso de servidores de rutas, aterrizaje local de consultas, latencia, disponibilidad ni resiliencia.
  • La unidad de verificación debe ser cada servicio: ASN, prefijos anunciados, modalidad de peering, estado de salud, espacios de nombres servidos, punto de observación, instancia que responde y hora.

La pista está en las dos filas

UIXP describe su página de redes con cuidado. Afirma que las organizaciones listadas están conectadas directamente a la red de peering del intercambio. En una fila aparece «AFRINIC - DNS - AFDSP», ASN 37177, política abierta y 2025 como año de incorporación. En la siguiente aparece «AFRINIC - DNS - DotARPA», ASN 37181, también con política abierta y el mismo año. La institución es común; el identificador de red y el nombre del servicio cambian.

La propia página marca el límite probatorio. Para saber si un miembro utiliza los servidores de rutas y qué prefijos anuncia, remite al looking glass. Ese aviso evita leer el directorio como si fuera una captura BGP. Una interfaz en el intercambio muestra que existe un lugar para intercambiar rutas. No informa por sí sola del estado de una sesión, del filtro aplicado, de qué vecinos aceptaron un anuncio ni de la trayectoria que verá un resolvedor.

La API pública de PeeringDB aporta otra vista del punto de contacto. En los datos capturados, ambos ASN figuran en el intercambio con ix_id 422. Para AS37177 aparecen direcciones del LAN de peering terminadas en .5 y ::5; para AS37181, direcciones terminadas en .6 y ::6. Son direcciones de interconexión, no los prefijos anycast que transportan el servicio DNS.

La diferencia es operativa. La dirección de peering responde a «¿dónde pueden hablar los routers?». El prefijo de servicio responde a «¿qué destino se puede aprender por esa conversación?». Si se confunden, la existencia de una interfaz se convierte indebidamente en prueba de que el DNS está anunciado, sano y contestando.

Por eso una representación pública puede mostrar un solo punto de Uganda sin mentir, pero un parte técnico necesita conservar dos cadenas. El mapa comunica ubicación institucional. El registro operativo debe conservar el mecanismo.

NS2: AS37177 y el papel de secundario

La guía de AFRINIC asigna el servicio NS2 a AS37177. Sus bloques publicados son 196.216.168.0/24 para IPv4 y 2001:43f8:120::/48 para IPv6. La página del programa lo presenta como una plataforma anycast que apoya a ccTLD africanos y otras necesidades de infraestructura DNS regional.

La documentación de AfDSP aclara qué significa ese apoyo. AFRINIC actúa como servidor secundario, también denominado esclavo en la terminología histórica. Recibe los datos de zona desde el primario. No administra el contenido ni adquiere la autoridad de decidir qué nombres o registros deben existir. Puede aportar una copia autoritativa adicional y una ruta distribuida, pero no sustituye al gestor de la zona.

Esta frontera importa porque «estar servido» y «estar gobernado» son verbos diferentes. También evita mezclar este análisis con un recuento de ccTLD. Un inventario de zonas pregunta qué delegaciones o direcciones apuntan al espacio NS2. La investigación de UIXP pregunta si los prefijos de AS37177 son visibles a través de la interconexión ugandesa y si consultas concretas llegan a esa instancia. El primer resultado no entrega automáticamente el segundo.

RDAP vincula AS37177 y los bloques publicados con el registro organizacional de AFRINIC. Es una prueba estable de identidad registral. No es una tabla de rutas en vivo. El registro no demuestra que 196.216.168.0/24 o 2001:43f8:120::/48 estuvieran anunciados en UIXP durante la captura, ni señala si la propagación ocurrió mediante los servidores de rutas o una sesión bilateral.

Entre el ASN y una respuesta DNS hay al menos cinco transiciones: el prefijo debe anunciarse, el vecino debe aceptarlo, la política debe seleccionar un camino, el anycast debe llevar el paquete a una instancia y la aplicación debe responder de forma autoritativa para el nombre consultado. La evidencia pública fija el primer conjunto de identificadores. No simula las transiciones que faltan.

DotARPA: AS37181 y una infraestructura distinta

La segunda fila sigue otra numeración. AFRINIC asigna DotARPA a AS37181, al bloque IPv4 196.216.169.0/24 y al bloque IPv6 2001:43f8:110::/48. Los prefijos se parecen visualmente a los de NS2, pero una parte cambia en cada familia. La similitud puede facilitar una tabla compacta; no autoriza a tratar los bloques como equivalentes.

La función también cambia. AFRINIC relaciona AS37181 con la infraestructura de DNS inverso descrita en RFC 5855. Ese documento creó nombres de servidor dedicados para las zonas inversas de IPv4 e IPv6. La separación evita que una dependencia compartida con otro servicio DNS convierta un fallo externo en un fallo colateral de IN-ADDR.ARPA o IP6.ARPA. Un ASN y unos prefijos propios hacen legible esa independencia en la capa de enrutamiento.

La palabra «inverso» no significa que todas las consultas PTR de África deban llegar a esta instancia. El DNS sigue la delegación de cada espacio, y los resolvedores utilizan referencias y cachés. El anycast añade la selección de instancia por rutas. Para una consulta determinada importan el nombre, la caché, los anuncios visibles desde el resolvedor y el estado del servidor seleccionado.

Tampoco conviene confundir DotARPA con una copia de servidor raíz. AFRINIC mantiene un programa separado para facilitar el alojamiento de copias operadas por organizaciones de servidores raíz. La propia documentación dice que AFRINIC no se convierte en operador de esas copias. Son iniciativas próximas dentro de la distribución de infraestructura DNS, pero no comparten automáticamente autoridad ni responsabilidad.

Los registros RDAP confirman AS37181 y sus bloques bajo AFRINIC. PeeringDB registra sus direcciones en UIXP. Estas piezas sostienen la identidad pública de la cadena DotARPA. No muestran un anuncio actual ni una respuesta. Sobre todo, no permiten tomar una prueba de AS37177 y aplicarla a AS37181.

En anycast, «local» necesita fecha y punto de vista

Anycast permite que varias instancias anuncien el mismo destino. El sistema de enrutamiento escoge, desde cada origen, la instancia alcanzada. Esta propiedad simplifica el uso del servicio, pero vuelve ambigua la geografía. Decir que existe un nodo en Uganda puede referirse a hechos diferentes.

Puede existir una máquina física o virtual en el país. El ASN puede tener una interfaz en UIXP. Los prefijos pueden ser visibles para determinados pares. Una consulta enviada por un resolvedor concreto puede recibir respuesta de la instancia ugandesa. Cada frase exige evidencia propia. Las cuatro no se deducen unas de otras.

RFC 4786 describe además una separación entre alcance de red y salud de aplicación. BGP puede mantener una ruta mientras el proceso DNS no responde. Un diseño operacional debe retirar o suprimir la ruta cuando la instancia deja de ser apta para recibir tráfico. Si el enlace entre salud y enrutamiento falla, la red puede conducir consultas con eficacia hacia un servicio inoperante.

El caso inverso también existe. La aplicación puede estar sana, pero una red local no recibe o no prefiere la ruta. Quizá no usa los servidores de rutas, quizá una sesión bilateral no está activa, quizá un filtro rechaza el prefijo o quizá la política prefiere otro sitio. El anycast no promete el servidor físicamente más cercano; elige según la topología y las políticas que BGP hace visibles.

RFC 7094 convierte esta incertidumbre en un requisito de observación distribuida. Un looking glass muestra la vista de su colector. Una sonda DNS muestra una respuesta desde un acceso y una hora. Para afirmar un patrón regional hacen falta varios puntos, repetición temporal y un método para reconocer qué instancia respondió. Sin esa combinación, «local», «más rápido» y «resiliente» son objetivos razonables, no mediciones.

AFRINIC menciona rendimiento y resiliencia entre los beneficios previstos de su programa. La arquitectura permite esos efectos. El paquete de fuentes de este artículo no contiene una serie antes/después de UIXP, una prueba de conmutación por fallo ni estadísticas de disponibilidad. El límite no reduce el valor potencial del despliegue; impide que una prueba de presencia se venda como una prueba de resultado.

La responsabilidad también está repartida

La guía de despliegue exige que el anfitrión pueda operar BGP y mantenga separadas las redes de gestión y peering. Para el entorno virtual publica una base de dos CPU virtuales, cuatro gigabytes de memoria y diez gigabytes de disco. Son requisitos de entrada para albergar el servicio, no una radiografía de la instalación concreta en UIXP. Las fuentes no revelan si hay una o varias máquinas, redundancia física o aislamiento por servicio.

El anfitrión se responsabiliza de la infraestructura, la electricidad y la conectividad, procura mantener la disponibilidad y avisa de interrupciones. AFRINIC conserva el software y la configuración, atiende la seguridad, coordina BGP, vigila la salud y participa en el diagnóstico. La división permite especialización, pero obliga a identificar en qué transición se produjo una anomalía.

Si la ruta continúa mientras DNS falla, hay que revisar la señal de salud, la lógica de retirada y la causa subyacente en software o infraestructura. Si DNS está sano pero la ruta no llega a un miembro, la sesión y la política de peering son centrales. Si NS2 funciona y DotARPA no, una luz verde para «el nodo AFRINIC» oculta la mitad del problema.

No se resuelve asignando toda la responsabilidad a una entidad. Se resuelve conservando la unión entre servicio, ASN, prefijo, método de peering, salud, instancia observada y actor que controla cada tramo.

El recibo mínimo es doble

Para NS2, un recibo debería fijar AS37177 y sus dos prefijos de servicio. Para DotARPA, AS37181 y los suyos. En otro campo guardaría las direcciones de peering de UIXP, evitando presentar .5 o .6 como destinos DNS públicos. Después registraría la visibilidad de IPv4 e IPv6, el colector, el vecino, la modalidad de peering y la hora.

La parte de aplicación indicaría la clase de servicio o los espacios de nombres examinados, el estado de salud que informa al enrutamiento y un identificador de instancia. La medición llevaría punto de observación, tipo de resolvedor, nombre y tipo de consulta, código de respuesta, tiempo y sello temporal. Un hash del lote conservaría la relación entre los datos y el resumen publicado.

Ningún campo sustituye al resto. «Activado» no prueba una ruta actual. Una ruta no prueba DNS saludable. Una respuesta válida no prueba cobertura completa de zonas. Un valor de latencia no prueba mejora regional. El recibo sirve porque conserva las diferencias y permite comparar momentos sin cambiar el significado de los campos.

Hoy puede sostenerse una conclusión acotada: dos identidades DNS de AFRINIC están registradas como conexiones directas en UIXP y cada una tiene una cadena pública de recursos y funciones. No puede sostenerse, con estas fuentes, que todas las consultas relevantes de Uganda aterricen localmente o que la conexión haya reducido la latencia y elevado la resiliencia. Si esos resultados se miden, deben publicarse como dos historias operativas, no como el brillo de un solo punto en el mapa.

Fuentes

  1. Guía de despliegue DNS anycast de AFRINIC: https://dns.afrinic.net/deployment-guide/
  2. Programa DNS de AFRINIC: https://dns.afrinic.net/
  3. Redes conectadas a UIXP: https://www.uixp.co.ug/networks
  4. Servicios y servidores de rutas de UIXP: https://www.uixp.co.ug/services
  5. Soporte DNS / AfDSP de AFRINIC: https://afrinic.net/dns-support.html
  6. Programa de copias de servidores raíz: 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. RDAP AFRINIC, AS37177: https://rdap.afrinic.net/rdap/autnum/37177
  12. RDAP AFRINIC, 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. API de PeeringDB, AS37177: https://www.peeringdb.com/api/netixlan?asn=37177
  18. API de PeeringDB, AS37181: https://www.peeringdb.com/api/netixlan?asn=37181