Resumen

  • La ficha de PeeringDB para el ASN 33764 de AFRINIC todavía expone AS-AFRINIC sin prefijo de fuente, aunque el cambio del producto busca que las referencias IRR ambiguas sean más fáciles de resolver.
  • El prefijo puede indicar dónde consultar un conjunto. No prueba sus miembros, su autorización, su vigencia ni que sirva para construir un filtro de rutas seguro.

Un campo puede orientar sin certificar

La ficha de red 3803 de AFRINIC en PeeringDB muestra el ASN 33764 y el AS-SET IRR AS-AFRINIC. La API pública devuelve el mismo valor en el campo escalar irr_as_set. La página también presenta la etiqueta «IRR AS-SET Verified». Eso confirma lo que PeeringDB muestra en su interfaz, pero en la información pública consultada no aparece un rastro de auditoría con la base interrogada, la hora de verificación, el método aplicado o los miembros recuperados.

Las fechas tampoco se deben mezclar. El registro principal indica que se actualizó el 2 de mayo de 2025; los datos de peering LAN tienen otro campo y otra fecha: 26 de marzo de 2026. Esa fecha posterior no demuestra que el valor del AS-SET cambiara entonces. La fecha general anterior tampoco permite declarar obsoleta toda la ficha. El historial específico del campo IRR no está expuesto.

La modificación de PeeringDB aborda una cuestión más acotada. La incidencia #1973 describió nombres imposibles de atribuir, nombres repetidos en distintos IRR y el trabajo manual que los operadores hacían antes de automatizar. Las notas de la versión 2.82.0, publicada el 19 de agosto, anuncian un editor inteligente, cambios proactivos en los nombres con fuente inequívoca y contacto con los responsables de los casos ambiguos. El resumen de septiembre usa AFRINIC::AS-AFRINIC como ejemplo del formato con fuente y explica que se contactaría a las redes cuando no estuviera clara. Esto documenta una función y un proceso de limpieza; no explica por qué esta ficha concreta aún conserva el nombre sin prefijo.

El prefijo cambia la consulta, no el conjunto

Un nombre AS-SET identifica una entrada del IRR; no contiene una copia de sus miembros. RFC 2622 define un as-set cuyos miembros pueden ser números de AS u otros nombres AS-SET. Un consumidor de PeeringDB puede leer el campo, elegir una base IRR, recuperar el registro, expandir referencias anidadas y, a continuación, generar un filtro. Si varias bases contienen el mismo nombre, el prefijo puede eliminar una ambigüedad en la primera consulta.

Esa mejora en el punto de descubrimiento es concreta. No valida toda la cadena. El prefijo no demuestra que el registro siga existiendo, que sus mantenedores estén autorizados, que sus miembros reflejen la política que pretende el operador o que la expansión recursiva haya terminado sin omisiones. Tampoco define cómo tratar referencias, réplicas atrasadas o copias en conflicto. El nombre por sí solo no prueba que el filtro final represente la intención del operador.

La diferencia tiene consecuencias posibles. Si un proceso automático consulta el IRR equivocado o recibe un conjunto vacío o parcial, podría generar un filtro que excluya rutas esperadas o admita otras no deseadas. La propia incidencia de PeeringDB menciona errores en políticas de filtrado como un riesgo. Esta investigación no encuentra pruebas de que haya ocurrido en el ASN 33764, de que el IRR de AFRINIC sea defectuoso o de que la ficha alimente un filtro activo. Un mecanismo plausible no equivale a un incidente documentado.

La cadena de evidencia que falta

Un proceso más seguro conservaría la ficha y su versión, la fuente IRR elegida, la hora de consulta, el identificador del registro devuelto, el número de miembros tras la expansión y una huella del resultado; después, registraría la prueba de la política generada. La etiqueta «verificado» puede ser útil, pero para tratarla como una afirmación decisiva hace falta conocer su alcance y fecha. La página y la API revisadas exponen la etiqueta y la cadena, no ese historial.

Por tanto, AFRINIC::AS-AFRINIC, cuando aparece, solo responde una pregunta limitada: en qué fuente buscar. No certifica la respuesta. El valor sin prefijo de la ficha de AFRINIC recuerda que el directorio, la entrada del IRR y la decisión de enrutamiento pertenecen a superficies de control diferentes. El espacio de nombres aclara el relevo; el consumidor aún debe probar lo que recibió.

Fuentes primarias: incidencia PeeringDB #1973, notas de la versión 2.82.0, actualización de septiembre de PeeringDB, ficha de red de AFRINIC, API pública, especificaciones de la API y RFC 2622.