Resumo

  • O registro público do PeeringDB para o ASN 33764 da AFRINIC ainda apresenta AS-AFRINIC sem qualificar a fonte IRR, enquanto a mudança de 2026 pretende facilitar a resolução de referências ambíguas.
  • O prefixo pode indicar onde consultar um conjunto. Não comprova seus membros, sua autorização, sua atualidade nem sua adequação a um filtro de rotas.

Um campo pode apontar sem comprovar

A ficha de rede da AFRINIC no PeeringDB, identificada pelo número 3803, informa ASN 33764 e o AS-SET IRR AS-AFRINIC. A API pública retorna o mesmo texto no campo escalar irr_as_set. A página também exibe “IRR AS-SET Verified”. Isso registra o que o PeeringDB apresenta ao leitor; nos dados públicos consultados, não aparece uma trilha de auditoria que mostre qual IRR foi consultado, quando a consulta ocorreu, o que foi validado ou quais membros foram encontrados.

As datas também precisam ser lidas campo a campo. O registro principal da rede tem updated em 2 de maio de 2025. Já os dados de peering LAN têm o campo próprio netixlan_updated, datado de 26 de março de 2026. A data posterior da subestrutura não prova que o AS-SET mudou naquele dia; a data mais antiga do registro principal tampouco torna a ficha inteira obsoleta. O histórico específico da indicação IRR não está exposto.

A mudança do PeeringDB trata de uma questão mais estreita. A issue #1973 descreveu nomes sem fonte identificável, nomes repetidos em mais de um IRR e a revisão manual necessária antes de automatizar. As notas da versão 2.82.0, publicada em 19 de agosto, registram um editor inteligente para AS-SET, correções proativas quando a fonte era inequívoca e contato com os responsáveis quando não era. A atualização de setembro usa AFRINIC::AS-AFRINIC como exemplo qualificado e descreve o contato com redes nos casos incertos. Isso documenta uma funcionalidade e uma rotina de saneamento; não explica por que esta ficha específica ainda mostra o nome sem prefixo.

A referência não contém o conjunto

O nome de um AS-SET identifica uma definição de membros; não carrega uma cópia da lista. A RFC 2622 descreve um as-set cujos membros podem ser números AS ou outros nomes AS-SET. Um consumidor do campo do PeeringDB pode escolher um IRR, buscar o registro, expandir referências aninhadas e só então gerar um filtro. Quando nomes iguais aparecem em diferentes bases, o prefixo da fonte pode resolver uma ambiguidade na consulta inicial.

É uma melhora concreta nessa etapa, mas não uma validação de ponta a ponta. O prefixo não demonstra que o registro continua existindo, que seus mantenedores têm autoridade, que os membros representam os clientes previstos nem que a expansão recursiva ficou completa. Também não informa como lidar com referências, réplicas atrasadas ou cópias divergentes. O texto do nome, sozinho, não prova que a política final corresponde ao que o operador pretendia aceitar.

Há uma consequência operacional possível. Se o processo consultar a base errada ou receber um conjunto vazio ou parcial, pode gerar um filtro que descarte rotas esperadas ou permita rotas não pretendidas. A própria issue do PeeringDB cita erros de política de filtros como impacto potencial da ambiguidade. Esta apuração não encontrou evidência de que isso tenha ocorrido com o ASN 33764, de falha no IRR da AFRINIC ou de que esse registro alimente um filtro ativo. Uma hipótese de falha plausível não é um incidente verificado.

Registrar a passagem entre etapas

Um fluxo mais seguro guardaria a ficha e sua versão, a origem IRR escolhida, o horário da consulta, o identificador do registro retornado, a contagem de membros após a expansão e um resumo criptográfico do resultado; depois, registraria o teste da política gerada. A etiqueta “verificado” pode ajudar, mas é preciso conhecer seu escopo e sua data para usá-la como evidência de decisão. A página e a API examinadas expõem a etiqueta e o texto, não essa cadeia.

Assim, AFRINIC::AS-AFRINIC, quando aparece, responde a uma pergunta limitada: onde procurar. Não atesta a resposta. O valor sem qualificador na ficha da AFRINIC deixa visível que diretório, entrada IRR e decisão de roteamento são superfícies de controle distintas. O namespace pode tornar a passagem mais clara; quem consome o dado ainda precisa provar o que recebeu.

Fontes primárias: issue #1973 do PeeringDB, notas da versão 2.82.0, atualização de setembro do PeeringDB, registro de rede da AFRINIC, API pública, especificação da API e RFC 2622.