Resumo

  • A presença de DFINFRA em associação pública com o AS210860 constitui um ponto de partida registral, não uma prova de propriedade, operação, controle de rotas ou relação comercial.
  • A cadeia necessária para sustentar uma atribuição durável ainda não está fechada: faltam respostas atuais verificadas para os registros, observações de roteamento, autorizações RPKI, identidade jurídica e evidências de serviço.

O registro muda a pergunta, não responde a ela

O primeiro erro em análises de infraestrutura de internet é tratar a identidade registral como se fosse uma demonstração de capacidade operacional. O registro de um ASN é importante porque cria uma âncora pública: permite consultar um nome, uma organização referenciada, contatos, mantenedores, status e eventos de alteração. Para uma investigação empresarial, porém, essa âncora é apenas o primeiro elo.

A fonte primária candidata é o objeto aut-num do RIPE Database para o AS210860, acompanhado pelos dados WHOIS do RIPEstat e pelo registro RDAP correspondente. Esses registros podem mostrar como o ASN está nomeado, qual organização é referenciada, quais mantenedores aparecem associados e quando determinados atributos foram criados ou modificados (objeto aut-num no RIPE Database; dados WHOIS do RIPEstat; registro RDAP). Mas a própria natureza desses sistemas impõe um limite: uma associação administrativa não equivale automaticamente a propriedade beneficiária, controle cotidiano da rede, operação física ou contrato com um cliente.

Esse limite é decisivo no caso de DFINFRA. O alvo editorial desta investigação é a entidade existente no diretório público da BTW, com o slug dfinfra. A pesquisa anterior já havia estabelecido que registros públicos associam DFINFRA ao AS210860, mas não demonstram que DFINFRA seja dona dos recursos, opere a rede, controle anúncios, dependa de clientes específicos ou obtenha benefício comercial. O acréscimo desta reportagem é testar se diferentes camadas de evidência conseguem fechar essa lacuna.

A formulação correta, portanto, não é “DFINFRA controla o AS210860”. É mais restrita: “há uma associação pública que pode ser testada contra identidade registral, autorização administrativa, observação de BGP, validação criptográfica, interconexão e evidência operacional”. A diferença entre as duas frases é a diferença entre uma pista e uma conclusão.

A cadeia de controle tem elos diferentes

Para transformar uma associação em atribuição defensável, seria necessário observar uma sequência de estados que se reforçam mutuamente. Primeiro, a entidade identificável teria de aparecer de forma consistente no cadastro do ASN e nos registros relacionados. Segundo, seria preciso compreender quem tem autorização para alterar os objetos de roteamento. Terceiro, uma observação independente teria de mostrar o ASN originando ou participando de rotas em uma janela temporal definida. Quarto, quando aplicável, os anúncios teriam de ser compatíveis com autorizações RPKI.

Por fim, seria necessário conectar essa capacidade técnica a uma operação, serviço, contrato, cliente ou consequência econômica atribuível.

Cada camada responde a uma pergunta diferente. Misturá-las produz uma certeza que as fontes não sustentam.

Identidade registral

O aut-num, o WHOIS e o RDAP são capazes de mostrar o nome registrado do ASN, referências organizacionais, contatos, mantenedores, status e eventos de modificação. Eles podem revelar se DFINFRA aparece diretamente em um campo relevante ou se a associação depende de uma cadeia de referências. Também podem mostrar divergências: nomes diferentes entre o objeto direto e o RDAP, organizações que parecem intermediárias ou datas de alteração incompatíveis.

Essas divergências não são detalhes burocráticos. Se o nome, a organização e os mantenedores não convergirem, a hipótese de que um único ator controla todas as camadas fica mais fraca. Se convergirem, a hipótese fica mais plausível, mas ainda não provada. Um cadastro pode refletir uma função administrativa, um provedor de serviços de registro ou uma estrutura que não revela o operador econômico final.

Autorização administrativa de rotas

Os objetos route e route6 no RIPE Database podem registrar que determinado ASN é declarado como origem de um prefixo e indicar quem mantém o objeto. Consultas inversas por origem podem identificar os objetos associados ao AS210860; consultas inversas por membros podem mostrar a participação do ASN em conjuntos de política, os chamados AS-sets (objetos route e route6 por origem; AS-sets que mencionam o AS210860).

Isso é evidência de uma declaração ou de uma autorização administrativa dentro de uma base de roteamento. Não é prova de que a rota esteja sendo anunciada naquele momento. Também não prova que o mantenedor seja proprietário do espaço de endereços, que tenha controle dos roteadores ou que exista um contrato de trânsito, revenda ou atendimento ao cliente.

A manutenção de um objeto por uma parte diferente daquela que aparece no nome do ASN pode ser operacionalmente relevante, mas continua sendo ambígua. Pode indicar uma relação legítima de administração técnica; pode refletir delegação; pode ser um vestígio desatualizado. O significado econômico só emerge quando essa relação é ligada a uma operação identificável por evidências independentes.

O que o BGP realmente observa

As fontes baseadas em RIPE RIS, BGP.Tools e Hurricane Electric podem fornecer observações com carimbo temporal sobre prefixos anunciados, situação de roteamento, histórico e ASNs vizinhos (prefixos anunciados no RIPEstat; status de roteamento; histórico de roteamento; vizinhos do ASN; perfil do AS210860 no PeeringDB; perfil no BGP.Tools; perfil no BGP Toolkit da Hurricane Electric).

Uma observação de BGP pode sustentar a afirmação de que, em determinado momento e para determinados coletores, um prefixo foi visto com o AS210860 como origem. Essa é uma afirmação operacional importante. Ainda assim, ela não identifica automaticamente a empresa que opera a infraestrutura. O ASN pode ser usado por um provedor contratado, por um operador de trânsito, por um terceiro que administra a rede ou por uma entidade cuja relação econômica não está publicada.

A ausência de visibilidade também exige cuidado. Coletores não cobrem todos os caminhos da internet, e uma retirada recente pode coexistir com objetos de registro ainda ativos. Da mesma forma, um objeto route antigo pode permanecer depois de um anúncio ter desaparecido. A comparação precisa ser temporal: o objeto, o anúncio e o registro de alteração devem ser examinados dentro da mesma janela, não tratados como se fossem uma fotografia única.

Vizinhos observados tampouco devem ser convertidos diretamente em relações comerciais. Um ASN adjacente pode ser upstream, peer, downstream ou simplesmente aparecer em uma topologia influenciada por route servers e transformações de caminho. A topologia sugere perguntas sobre interconexão; ela não prova quem paga a quem.

O que o RPKI acrescenta — e o que não acrescenta

O RPKI introduz uma camada criptográfica que é diferente tanto do cadastro quanto da observação de BGP. Um ROA validado pode autorizar o AS210860 a originar determinado prefixo até um comprimento máximo específico. Os dados de validação da Cloudflare e a documentação do RIPE sobre objetos de autorização de origem ajudam a testar se existe correspondência entre a rota observada, o prefixo e o maxLength permitido (exportação de payloads RPKI validados; documentação do RIPE Database; RFC 6482 sobre ROAs).

Essa correspondência pode reduzir uma incerteza técnica: a origem observada está ou não autorizada criptograficamente para aquele prefixo e comprimento? Mas um ROA válido não prova que DFINFRA opere a rede subjacente, seja proprietária do endereço, anuncie o prefixo naquele instante ou obtenha receita com o anúncio. A autorização pode ser concedida por um titular de recursos a um operador contratado.

O teste correto também precisa respeitar o comprimento do prefixo. Uma autorização que cobre um bloco maior pode continuar produzindo um anúncio inválido se o comprimento máximo for excedido. Por isso, uma conclusão robusta teria de comparar o anúncio exato com o ROA exato, além de registrar a hora da validação. Sem esse conjunto, dizer apenas que “há RPKI” é insuficiente.

Onde a hipótese de controle pode quebrar

A hipótese de controle durável pode falhar em qualquer transição entre as camadas.

Ela pode quebrar na identidade: o nome de DFINFRA pode não aparecer no objeto aut-num atual, ou pode aparecer apenas por meio de uma referência administrativa que não identifica a entidade operacional. Pode quebrar na autorização: os mantenedores podem ser diferentes, os objetos route podem estar ausentes ou os AS-sets podem não oferecer uma relação direta. Pode quebrar na observação: o AS210860 pode não aparecer originando os prefixos atribuídos nos registros, ou a visibilidade pode estar limitada a uma janela passada. Pode quebrar na criptografia: os anúncios podem não ter ROAs correspondentes, ou podem exceder o maxLength.

E pode quebrar na economia: mesmo que todas as camadas técnicas coincidam, ainda pode não haver prova de serviço, clientes, contrato, receita ou dependência.

Cada quebra tem um significado diferente. Um conflito entre RDAP e o aut-num é um problema de identidade ou de modelo de dados. Um objeto IRR sem anúncio BGP é um descompasso entre declaração e operação observada. Um anúncio sem autorização RPKI pode representar uma configuração incompleta, uma política de segurança diferente ou um risco de origem — não uma prova de fraude ou de ausência de operador. Um perfil no PeeringDB que diverge do registro do RIPE pode ser metadata autodeclarada desatualizada, não necessariamente uma contradição final.

A investigação deve preservar essas distinções. Transformar cada inconsistência em acusação seria tão frágil quanto transformar cada coincidência em prova de propriedade.

Por que a consequência econômica continua não demonstrada

Para leitores empresariais, a questão final é menos “quem aparece no cadastro?” e mais “qual capacidade econômica muda de mãos?”. Um ASN pode habilitar uma estratégia de conectividade, dar acesso a uma política de roteamento, sustentar uma rede regional ou reduzir dependência de um fornecedor. Mas esses efeitos só podem ser atribuídos a DFINFRA se houver evidência do mecanismo que os produz.

Esse mecanismo poderia incluir um contrato de trânsito, uma oferta de conectividade, uma rede de clientes, um anúncio corporativo, termos de serviço, uma estrutura jurídica ou uma divulgação financeira. Também poderia incluir documentação operacional de um fornecedor identificável. Nada disso foi verificado nesta execução. Não foi recuperado um registro oficial de empresa que estabeleça o nome jurídico, a jurisdição e o identificador corporativo ligados a DFINFRA. Tampouco foi verificado um site de primeira parte, uma descrição de serviços, uma lista de clientes, um contrato, um estudo de caso ou um anúncio de cliente.

Consequentemente, não há base para afirmar que DFINFRA recebe receita do AS210860, controla uma relação de trânsito, atende clientes por meio dele ou obtém poder de barganha em um mercado de conectividade. Também não há base para afirmar o contrário. O estado correto é de hipótese não resolvida.

Essa conclusão não reduz a importância dos registros. Ela define seu valor informacional. A associação pública justifica uma investigação de controle; não substitui a evidência de controle. O BGP mostra estado observado; não mostra necessariamente o contrato. O RPKI mostra autorização de origem; não mostra necessariamente o operador. O PeeringDB mostra metadata operacional autodeclarada; não é registro societário. O caminho até fluxo de caixa permanece aberto.

A próxima verificação precisa ser temporal e convergente

A próxima condição observável deve conectar, dentro de uma janela temporal definida, cinco elementos: um operador identificável no cadastro do AS210860; autoridade de manutenção ou autorização compatível; um objeto route ou route6 correspondente; um anúncio BGP observado com prefixo e comprimento exatos; e uma autorização RPKI válida quando aplicável. Para fechar o elo econômico, esse conjunto ainda precisaria ser ligado a uma fonte independente sobre operação, serviço, contrato, cliente ou entidade jurídica.

A confirmação não exige que todas as fontes usem o mesmo nome textual. Exige que as relações sejam explicáveis e verificáveis. Um operador pode administrar recursos de outra organização; nesse caso, a distinção entre titular, administrador e provedor precisa ser explicitada. Um anúncio pode ser feito por um upstream; nesse caso, a relação técnica não deve ser descrita como controle comercial sem documentação adicional.

O resultado falsificador também é claro. Se o nome registral, os mantenedores, os objetos de rota, o originador observado, o ROA e a identidade operacional apontarem para atores incompatíveis, a hipótese de controle durável por DFINFRA perde força. Se os registros convergirem, mas não surgir evidência de serviço ou consequência econômica, a conclusão deve permanecer limitada a uma capacidade técnica ou administrativa plausível, não a um benefício empresarial comprovado.

A disciplina é especialmente importante porque dados de registro e roteamento mudam em ritmos diferentes. Uma alteração no aut-num pode anteceder a operação. Um anúncio pode desaparecer antes de um objeto ser removido. Um ROA pode permanecer válido sem que a rota esteja ativa. Um perfil independente pode usar uma janela de coleta diferente. O estado precisa ser datado, comparado e descrito com o grau de certeza que os dados permitem.

Conclusão: uma pista pública, uma cadeia ainda incompleta

A investigação atual não fecha a atribuição de controle entre DFINFRA e o AS210860. Ela estabelece algo mais modesto e mais útil: existe uma associação registral pública que pode ser testada por camadas independentes, mas os resultados necessários para ligar identidade, autorização, operação e consequência econômica não foram verificados nesta execução.

O próximo avanço não será encontrar mais uma página que repita o nome DFINFRA. Será obter um conjunto temporalmente coerente: registro direto, autorização de manutenção, objeto de rota, anúncio observado, validação RPKI e evidência independente de operação ou serviço. Uma convergência desse tipo fortaleceria a hipótese de controle atribuível. Uma divergência em qualquer elo apontaria precisamente para o limite da conclusão.

Até lá, a formulação responsável permanece: DFINFRA e AS210860 estão ligados por um sinal registral investigável, não por uma demonstração pública de controle operacional ou benefício econômico.

Fontes e limites da evidência

A pesquisa desta reportagem identificou as seguintes fontes públicas candidatas, mas não recuperou seus corpos de resposta atuais nesta execução. Por isso, valores exatos, datas, mantenedores, prefixos, vizinhos, ROAs, entidade jurídica e serviços permanecem não verificados:

As observações de BGP, os objetos IRR e os ROAs não provam isoladamente propriedade, operação física, relação provedor-cliente ou benefício comercial. Uma conclusão defensável exigirá triangulação entre registros de identidade, autorização de manutenção, roteamento observado, RPKI, material de primeira parte e registro societário oficial.