Resumo

  • As fontes consultadas descrevem camadas diferentes — registro, política de roteamento, observação de rotas e diretório autodeclarado — e não permitem, isoladamente, concluir propriedade legal, autorização exclusiva ou operação ininterrupta.
  • A principal conclusão verificável é metodológica: a continuidade de um recurso de Internet exige correlação temporal entre identidade registral, autorização de origem, anúncios observados e capacidade operacional, não apenas a existência de um objeto público.

A pergunta correta

A página de diretório da DATAMATIX associa o alvo ao AS210973 e fornece o contexto público usado nesta investigação: https://btw.media/pt-br/directory/datamatix. Isso define o objeto de cobertura, mas não resolve a pergunta central. A questão é se a evidência pública permite reconstruir, de forma defensável, quem controla o sistema, quais anúncios estão autorizados e quão durável seria a continuidade caso um registro, uma relação comercial ou uma rota desaparecesse.

A resposta disponível neste pacote de pesquisa é limitada. Foram preservados pontos de entrada para o objeto aut-num no RIPE Database, registros IRR de origem inversa, agregações RIPEstat, observações BGP, dados de vizinhança, PeeringDB e três sumários independentes de BGP ou IRR. O conjunto é suficientemente amplo para separar tipos de evidência. Não é, porém, suficiente para preencher as lacunas de identidade, autorização e operação que normalmente sustentariam uma conclusão forte.

Camadas que não devem ser confundidas

O registro primário do RIPE NCC é uma declaração administrativa sobre um número de sistema autônomo. Ele pode conter nome, organização, contatos e estado, mas o pacote de pesquisa não verificou o nome registrado, o status, a organização ou as funções de contato. A existência de um objeto no banco de dados demonstra que há uma representação registral consultável; não demonstra, sozinha, que a entidade mencionada controla atualmente o ASN ou que o uso técnico observado é autorizado.

Os registros IRR acrescentam uma camada de intenção ou política declarada. Uma rota ou route6 associada ao origin AS210973 pode ajudar operadores a filtrar anúncios e comparar a configuração esperada com a observada. Ainda assim, uma declaração IRR não equivale automaticamente a uma autorização legal, a uma prova de titularidade ou a uma garantia de que a política continua correta. O resultado precisa ser comparado com outras fontes e com o momento em que o anúncio foi observado.

A RIPEstat fornece observações agregadas de prefixos anunciados, estado de roteamento e vizinhos ASN. Essas observações respondem a perguntas técnicas diferentes: um prefixo foi visto? O sistema parecia roteável em determinado momento? Quais caminhos apareceram nos dados disponíveis? A observação de uma rota não identifica necessariamente o beneficiário econômico, o administrador real ou a duração futura da operação. Também não substitui registros de autorização de origem, contratos de trânsito ou documentação de incidentes.

O PeeringDB funciona como diretório autodeclarado da comunidade de interconexão. Uma presença ali pode indicar que informações de rede foram fornecidas por um participante, mas não transforma a declaração em auditoria independente. Os sumários de bgp.tools, BGPView, BGP.he.net e IRR Explorer são úteis para comparação e descoberta de divergências. Como camadas derivadas ou de terceiros, devem ser tratados como observações auxiliares, não como autoridade isolada sobre identidade ou controle.

O que está estabelecido

O conjunto de fontes preservado inclui o registro RIPE do AS210973, sua busca inversa de objetos IRR, dados RIPEstat de WHOIS, visão geral do ASN, prefixos anunciados, estado de roteamento e vizinhos, além da consulta correspondente ao PeeringDB e a três serviços de comparação. A cobertura documental, portanto, não depende de uma única interface ou de uma única forma de publicação: https://rest.db.ripe.net/ripe/aut-num/AS210973, https://rest.db.ripe.net/search.json?source=ripe&inverse-attribute=origin&query-string=AS210973&type-filter=route&type-filter=route6, https://stat.ripe.net/data/whois/data.json?resource=AS210973, https://stat.ripe.net/data/as-overview/data.json?resource=AS210973, https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS210973, https://stat.ripe.net/data/routing-status/data.json?resource=AS210973, https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS210973, https://www.peeringdb.com/api/net?asn=210973, https://bgp.tools/as/210973, https://bgp.he.net/AS210973, https://irrexplorer.nlnog.net/asn/AS210973 e https://api.bgpview.io/asn/210973.

Esse inventário sustenta uma conclusão precisa, mas deliberadamente estreita. Há endpoints públicos relevantes para investigar a relação entre DATAMATIX e AS210973. As fontes permitem formular uma trilha de verificação que cruza identidade registral, objetos de roteamento, atividade observada e presença de interconexão. O pacote não sustenta, sem novas verificações, a afirmação de que a DATAMATIX é a proprietária legal do ASN, de que controla exclusivamente os prefixos associados, de que todos os anúncios são autorizados ou de que a operação foi contínua.

Também não foi verificado, a partir da pesquisa recebida, o nome exato registrado, o estado administrativo, a organização, os papéis de contato, os objetos route e route6, a lista de prefixos observados, o estado de roteamento, os vizinhos, a presença no PeeringDB ou os respectivos timestamps. Essa ausência não prova que os dados não existam; indica que eles não foram confirmados na evidência disponível para esta publicação. A diferença entre “não verificado” e “inexistente” é essencial para uma reportagem de accountability.

O mecanismo de falha

O risco nasce quando camadas que deveriam ser correlacionadas são tratadas como equivalentes. Um registro pode permanecer atualizado depois que uma relação operacional mudou. Uma política IRR pode continuar publicada enquanto um anúncio real é feito por outro caminho. Um anúncio BGP pode ser tecnicamente visível sem resolver a autorização ou o controle econômico. Um diretório comercial pode conter dados úteis, mas não necessariamente a prova independente de quem tem poder de decisão.

Esse desacoplamento cria uma superfície de falha institucional. Operadores podem tomar decisões de filtragem com base em dados incompletos; investigadores podem atribuir um recurso à organização errada; clientes ou parceiros podem interpretar presença técnica como garantia de continuidade. Em incidentes, a falta de timestamps, contatos verificáveis e trilhas de autorização prolonga a fase de detecção e torna mais difícil distinguir erro administrativo, mudança legítima, sequestro de rota ou simples obsolescência documental.

A prevenção exige que cada camada responda à sua própria pergunta. O registro deve identificar o responsável administrativo e os contatos verificáveis. A política de roteamento deve mostrar quais origens são esperadas. A observação BGP deve ser datada e comparada com essa política. Os diretórios devem indicar quando a informação foi autodeclarada e quando foi confirmada por terceiros. Nenhuma camada deve carregar mais significado do que sua proveniência permite.

Como testar a continuidade

Uma avaliação robusta começaria por uma fotografia temporal: o objeto registral, os objetos IRR, os prefixos anunciados, o estado de roteamento e os vizinhos devem ser coletados no mesmo intervalo e preservados com seus horários. Em seguida, seria necessário comparar mudanças: alterações no registro, criação ou remoção de rotas, surgimento ou desaparecimento de anúncios e mudanças nos caminhos observados.

O segundo teste é de autorização. A presença de um prefixo em um anúncio não basta; é necessário verificar se a origem observada corresponde à autorização publicada e, quando aplicável, a mecanismos de validação como RPKI. O terceiro é operacional: contatos e relações de trânsito ou peering precisam ser confirmados por canais independentes. O quarto é de recuperação: se o contato principal, o provedor de trânsito ou o registro administrativo falhar, existe uma rota verificável para corrigir dados, retirar anúncios indevidos e preservar o serviço?

A durabilidade da reparação também precisa ser observada. Corrigir um nome no registro é uma mudança documental; provar que a correção permanece alinhada com IRR, RPKI, BGP e os contatos operacionais é outra. A medida de sucesso não é apenas a publicação de uma alteração, mas a redução sustentada da divergência entre as camadas.

Limites e próximos passos

Este artigo não atribui irregularidade à DATAMATIX nem ao AS210973. Os dados disponíveis não estabelecem, por si só, uma falha, um abuso ou uma interrupção. Eles mostram por que a linguagem pública sobre controle de recursos de Internet precisa distinguir registro, declaração, observação e confirmação.

A próxima etapa verificável seria obter os conteúdos atuais das fontes com seus timestamps, registrar os campos de identidade e status, comparar os objetos route e route6 com anúncios observados e documentar qualquer divergência. Também seria necessário confirmar a relação entre o nome DATAMATIX e o responsável administrativo ou operacional pelo AS210973 por uma fonte primária ou por declarações independentes convergentes.

Até que essa correlação exista, a conclusão mais forte que os registros públicos permitem é a seguinte: eles oferecem uma base para investigar controle e continuidade, mas não uma prova completa desses atributos. A legitimidade institucional depende de tornar as transições, autorizações e correções verificáveis ao longo do tempo — especialmente quando diferentes sistemas públicos contam partes diferentes da mesma história.