Resumen

  • El mapa actual toma 27 filas de un CSV y el código declara alojada cada una; solo 24 delegaciones muestran “afrinic” en el nombre de un servidor.
  • .so, .ng y .ml completan el total porque uno de sus servidores usa direcciones dentro de 196.216.168.0/24 y 2001:43f8:120::/48, los prefijos NS2 publicados por AFRINIC.
  • Un recibo de zona alojada debería hacer visible ese cruce con fecha y fuente, sin confundirlo con un contrato, una ubicación, un nivel de servicio o el control del contenido.

La diferencia entre 24 y 27 cabe en tres consultas de dirección. También contiene una lección sobre cómo se presenta la infraestructura compartida.

AFRINIC dice en su portal DNS que presta DNS autoritativo a más de 25 dominios nacionales africanos. El mapa enlazado concreta la afirmación: descarga un CSV de 27 países y ccTLD distintos. Después, el programa que dibuja la interfaz asigna isHosted: true a cada fila y usa la cantidad de elementos como estadística.

Quien busque la palabra afrinic en los nombres delegados solo encontrará 24 coincidencias. Esa prueba textual funciona cuando el servidor se llama, por ejemplo, ns-bj.afrinic.net. No funciona en Somalia, Nigeria ni Mali. Ningún nombre de servidor delegado para .so, .ng o .ml contiene la marca del registro. Eso no convierte las tres filas en falsas; obliga a mirar la siguiente capa.

De la etiqueta a la red

La delegación de .so incluye d.nic.so. En la captura congelada del 12 de septiembre, ese nombre resolvía a 196.216.168.54 y 2001:43f8:120::54. La ficha vigente de IANA publica esas dos direcciones.

En .ng, el servidor relevante es ns5.nic.net.ng, con 196.216.168.41 y 2001:43f8:120::41. En .ml, d.nic.ml utiliza 196.216.168.37 y 2001:43f8:120::37. Las páginas de delegación de IANA confirman ambos pares.

El manual de despliegue anycast de AFRINIC identifica AS37177 como el origen de NS2 y reserva para ese servicio 196.216.168.0/24 y 2001:43f8:120::/48. Las tres parejas caen dentro de esos prefijos. El mismo examen, extendido a las 27 filas, encontró al menos una dirección IPv4 y una IPv6 de cada zona dentro de las dos redes publicadas.

La suma, por tanto, cierra. El problema de transparencia está en que la interfaz no enseña la operación que permite cerrarla.

Hospedar no significa gobernar la zona

Un nombre de servidor puede representar al ccTLD y, al mismo tiempo, usar infraestructura secundaria de un tercero. Esa separación es normal. Permite que el gestor mantenga su convención local y que el proveedor distribuya respuestas mediante anycast. Exigir que todo hostname lleve la palabra AFRINIC sería una solución visual a un problema probatorio.

La dirección ofrece mejor evidencia técnica, pero tampoco responde a todas las preguntas. No revela qué instancia física del anycast atendió una consulta, dónde estaba, cuánto tardó ni cuál fue su disponibilidad. No permite leer el acuerdo entre las organizaciones. Ni siquiera demuestra por sí sola quién originaba la ruta en cada instante; para eso haría falta otra observación.

La autoridad sobre el contenido queda aún más lejos. AFRINIC describe este programa como DNS esclavo o secundario: replica los datos enviados por el servidor maestro o primario y no administra la zona ni lo que contiene. Vincular una IP con el servicio confirma una superficie técnica, no transfiere la política del dominio nacional.

El dato mínimo que falta

El CSV contiene país, ccTLD y bandera. No adjunta fecha por fila, hostname delegado, direcciones, prefijo coincidente ni historia de cambios. El código no distingue activo, pendiente o retirado: toda fila cargada queda alojada.

Para un mapa divulgativo, esa sencillez tiene sentido. Pero impide contestar una pregunta básica cuando algo cambia: ¿por qué esta zona entra hoy en el total? Una cifra sin rastro obliga a reconstruir desde cero la delegación y las direcciones, precisamente el trabajo que las tres excepciones hacen visible.

AFRINIC podría añadir un recibo desplegable por zona. Bastan el ccTLD, el nombre delegado, las direcciones observadas, el prefijo de servicio asociado, la fuente, la hora de consulta y el estado de la relación. Las fechas de primera detección, última confirmación y último cambio preservarían continuidad cuando se renombra un servidor o se sustituye una dirección.

El recibo debería incluir una vía de corrección y límites expresos. No prometería disponibilidad, no señalaría una instalación física y no expondría contactos o contratos. Solo explicaría la evidencia pública que sostiene la inclusión.

La defensa más sólida del mapa actual es que su número resultó correcto bajo la prueba congelada. Además, nadie necesita recibir una clase de DNS antes de entender una visualización regional. Pero una interfaz simple puede apoyarse en un registro verificable. Ocultar la unión no es requisito de diseño.

.so, .ng y .ml son los mejores casos del conjunto porque evitan una conclusión fácil y equivocada. La ausencia de una marca en el hostname no equivale a ausencia del proveedor. Hace falta pasar por la dirección, el prefijo y una observación fechada. El mapa debería permitir ese recorrido sin pedir que el lector lo descubra por su cuenta.

Fuentes