Resumo

  • DFINFRA e AS210860 formam uma associação registral pública que justifica verificação adicional, mas não estabelece, sozinha, propriedade legal, autoridade de manutenção, operação de rede ou origem atual de rotas.
  • A investigação identificou oito camadas públicas relevantes — objeto aut-num da RIPE, buscas de objetos de rota, prefixos anunciados, estado de roteamento, estado BGP, histórico RPKI, BGP.Tools e Hurricane Electric — mas a recuperação atual não expôs os campos vivos necessários para confirmar seus valores.

O registro é um sinal, não uma cadeia de controle

Registros de recursos numéricos da Internet são úteis porque deixam visíveis relações administrativas e técnicas que podem orientar uma investigação. Um nome associado a um número de sistema autônomo pode indicar onde procurar mudanças de contato, manutenção ou atribuição. Ele não responde automaticamente a perguntas diferentes: quem é o titular jurídico, quem possui autoridade para alterar os objetos, quem opera a rede e quem está originando tráfego neste momento.

Essa distinção é especialmente importante quando uma descrição registral é tratada como se fosse uma prova operacional. O objeto aut-num pode conter um nome, contatos e referências de manutenção. Isso é evidência sobre a representação administrativa do recurso, sujeita ao que o registro efetivamente mostra em determinado momento. Não é, sem documentação adicional, prova de que a entidade nomeada controla uma organização, presta serviço a clientes ou toma decisões de roteamento.

A página localizada do diretório identifica o objeto acompanhado nesta investigação: DFINFRA no diretório do BTW. Essa referência é um vínculo editorial para o objeto investigado, não uma evidência independente de operação.

Quatro perguntas que não devem ser misturadas

A primeira pergunta é cadastral: qual registro público associa um nome ao AS210860 e quais atributos aparecem nesse registro? A fonte primária apropriada para essa camada é o objeto aut-num da RIPE Database (objeto aut-num consultado). Mesmo quando o campo de nome ou contato está disponível, ele descreve o estado do registro, não necessariamente a identidade econômica ou a capacidade operacional atual.

A segunda pergunta é de autorização: existem objetos route ou route6 que declaram origens para o AS210860, e quais mantenedores podem alterá-los? A busca inversa por origem na base da RIPE (consulta de objetos route e route6) pode ajudar a separar uma relação registral de uma autorização formal para anunciar determinados prefixos. A existência de um objeto de rota também não prova, isoladamente, que o anúncio esteja ocorrendo agora nem que a entidade cujo nome aparece no registro seja quem executa a mudança.

A terceira pergunta é observacional: quais prefixos o AS210860 anunciou, durante qual intervalo e com que visibilidade? A consulta de prefixos anunciados do RIPEstat (prefixos anunciados associados ao AS210860) e os dados de estado de roteamento (estado de roteamento no RIPEstat) tratam de atividade observada. O estado BGP (estado BGP no RIPEstat) acrescenta outra perspectiva sobre visibilidade e coletores. Essas fontes respondem a perguntas técnicas sobre anúncios e observação; não transformam automaticamente a atividade em prova de titularidade legal ou de controle institucional.

A quarta pergunta é criptográfica e de segurança de roteamento: algum par prefixo-origem tem uma autorização RPKI válida, inválida ou ausente, em qual momento? O histórico RPKI do RIPEstat (histórico RPKI consultado) pode contextualizar alterações nas autorizações. Mas um resultado RPKI é uma afirmação sobre a validade de uma origem para um prefixo sob o sistema de certificados e ROAs; não é um certificado de que uma empresa específica opera toda a rede nem de que um anúncio observado continua ativo.

O que a apuração conseguiu estabelecer

A pesquisa atual identificou oito candidatos públicos para uma verificação em camadas: o objeto aut-num da RIPE, uma busca inversa por objetos route e route6, consultas do RIPEstat para prefixos anunciados, estado de roteamento, estado BGP e histórico RPKI, além das visões do BGP.Tools (visão do AS210860 no BGP.Tools) e do Hurricane Electric (visão do AS210860 no Hurricane Electric). A seleção dessas fontes é verificável no recibo de pesquisa da apuração; ela mostra quais camadas devem ser comparadas, não quais valores atuais cada camada contém.

O resultado factual mais importante é também uma limitação: o recibo mais recente classificou a verificação como incompleta, sem recuperação web ao vivo, e não apresentou fatos verificados sobre os campos atuais. Por isso, este artigo não afirma que o objeto atual contém “DFINFRA” no atributo as-name, não lista organizações ou contatos como se estivessem confirmados, não declara a existência de objetos route, não informa prefixos correntes, não atribui visibilidade a coletores BGP e não classifica nenhum par prefixo-origem como Valid, Invalid ou NotFound.

Essa cautela não torna a investigação vazia. Ela impede que a ausência de acesso aos valores seja substituída por uma inferência. Há uma diferença operacional entre “a fonte foi identificada” e “o campo foi lido e confirmado”. Há também uma diferença entre “o registro pode conter uma associação” e “a associação prova que a entidade controla a infraestrutura”. O valor desta apuração está em tornar essas fronteiras explícitas.

Por que a combinação das camadas importa

Nenhuma camada responde sozinha a todo o problema. O registro administrativo pode mostrar uma associação nominal. Os objetos de rota podem mostrar uma forma de autorização. As observações BGP podem mostrar que algum coletor viu anúncios. O RPKI pode mostrar se uma origem está autorizada para um prefixo segundo uma política criptográfica. A convergência entre as camadas seria mais informativa do que qualquer registro isolado, mas ainda exigiria interpretar datas, escopo e identidade dos atores.

Uma cadeia de evidência mais forte teria de conectar, pelo menos, quatro elementos: a identificação registral; a autoridade para manter ou alterar os objetos; os recursos efetivamente anunciados; e uma ligação independente entre essa capacidade técnica e a entidade que se pretende descrever. Mesmo essa cadeia responderia a perguntas delimitadas. Ela poderia demonstrar uma relação de manutenção ou operação de determinados recursos sem, por si só, resolver toda a estrutura societária, contratual ou econômica por trás deles.

O intervalo de observação também é decisivo. Um prefixo anunciado em uma janela anterior não prova atividade presente. Um objeto de rota preservado no registro não demonstra que o tráfego está sendo encaminhado hoje. Uma ROA histórica não estabelece a configuração atual. E uma visão agregada de um site de monitoramento pode ter cobertura, atraso ou critérios próprios. Datas e estados devem acompanhar cada afirmação.

O que ainda precisa ser verificado

A próxima verificação deve começar pelo objeto aut-num atual: nome, organização, contatos e mantenedores, com o momento de consulta registrado. Em seguida, deve confrontar esses dados com objetos route e route6 encontrados pela busca inversa, observando os mantenedores e os prefixos associados. O terceiro passo é comparar esses prefixos com anúncios e visibilidade nos dados do RIPEstat, BGP.Tools e Hurricane Electric, sem tratar divergências entre coletores como simples erro.

Por fim, cada par prefixo-origem relevante deve ser comparado às autorizações RPKI no mesmo contexto temporal. A pergunta não é apenas se existe uma ROA, mas se ela cobre o prefixo e a origem observados, qual estado resulta e em que janela esse estado foi medido. Se as camadas não convergirem, a conclusão deve permanecer limitada: há um sinal ou uma relação parcial, não uma prova completa de controle.

O pacote atual conserva essas perguntas como questões não resolvidas. Entre elas estão: se o objeto RIPE atual usa DFINFRA como as-name; quais organizações, contatos e mantenedores estão ligados ao AS210860; se existem objetos route ou route6 atuais; quais prefixos são observados como originados; qual é a visibilidade nos coletores; e qual estado RPKI se aplica a cada par. Nenhuma dessas perguntas deve ser respondida por extrapolação a partir do nome do diretório.

A consequência prática para clientes, pares e investigadores

Para um operador de rede, confundir registro com controle pode levar a uma atribuição errada de incidentes ou a uma notificação dirigida à parte inadequada. Para um cliente ou parceiro, pode criar uma falsa impressão de capacidade, cobertura ou continuidade de serviço. Para um investigador, pode transformar um indicador de busca em uma acusação sobre uma empresa ou pessoa sem a documentação necessária.

A abordagem mais segura é manter quatro estados separados: associação registral, autorização declarada, atividade observada e validade criptográfica. Cada estado deve ter uma fonte, uma data e um escopo. Quando um estado não está disponível, ele deve ser marcado como não verificado. Essa disciplina é mais lenta do que repetir uma descrição registral, mas produz um resultado que pode ser atualizado sem reescrever a lógica da investigação.

DFINFRA e AS210860 continuam sendo um caso útil justamente porque a pergunta está aberta. A evidência pública identificada permite mapear o caminho de verificação, mas a execução atual não autoriza concluir que DFINFRA seja proprietária legal, mantenedora, operadora ou originadora atual de rotas. A próxima atualização terá valor se preencher campos específicos com leituras atuais e comparáveis — não se apenas repetir a associação inicial.