Resumo

  • O RDAP da APNIC cobre exatamente o AS136022 e associa seu objeto administrativo à Janani Technology. O estado active pertence ao cadastro; não comprova rota visível, sessão BGP, equipamento em funcionamento ou disponibilidade de serviço.
  • A resposta da PeeringDB contém uma linha para o ASN, mas nenhuma linha netixlan, e deixa sem valor vários campos de coordenação. São declarações ausentes no perfil capturado, não evidência de que não existam interconexões, recursos ou atividade operacional.
  • Em uma resposta do RIPE RIS com query_time de 7 de agosto de 2026, 00:00 UTC, rotas qualificadas apareceram para 326 de 327 peers IPv4 listados e 320 de 320 peers IPv6 listados. Os números preservam horário, denominadores e limiar; não demonstram alcance universal, autorização, capacidade, resiliência ou resultado de serviço.

O ASN é uma chave, não uma conclusão

Um sistema autônomo é uma rede, ou um conjunto de redes, que apresenta uma política comum de roteamento ao restante da internet. Seu número, o ASN, oferece uma identidade pública única. No Border Gateway Protocol, o BGP, redes trocam informações sobre quais blocos de endereços podem ser alcançados por quais domínios de roteamento.

O AS136022 é a chave que permite alinhar a página de diretório, o objeto administrativo, o perfil de coordenação e a observação de rotas. Isso reduz o risco de atribuir um registro a uma organização de nome parecido ou a outro domínio de roteamento. Mas o identificador compartilhado não amplia o poder probatório de cada campo.

O diretório da BTW confirma qual entidade pública está em pauta e oferece uma rota de navegação. O RDAP responde quem o registro associa ao recurso numérico. A PeeringDB mostra o que um participante publicou para facilitar coordenação. O RIS responde o que coletores determinados observaram sob um método e em um instante. A investigação melhora quando cada fonte responde apenas à pergunta para a qual foi construída.

A APNIC mantém o livro administrativo

O Registration Data Access Protocol, ou RDAP, fornece dados estruturados sobre registros de recursos da internet. A resposta da APNIC examinada aqui abrange exatamente o número 136022: os campos inicial e final são ambos 136022, o identificador é AS136022 e o nome do objeto é JANANITECHNOLOGY-AS-AP. Janani Technology aparece entre os nomes de entidades da resposta.

O histórico registra um evento de cadastro em 3 de fevereiro de 2019, às 08:31:56 UTC, e um evento de última alteração em 18 de janeiro de 2021, às 03:52:25 UTC. O objeto também traz o estado administrativo active. Esses elementos tornam a identidade e a manutenção do registro verificáveis.

Nenhum deles é telemetria da rede em execução. Active não informa se um roteador está ligado, se um prefixo está visível, se uma sessão BGP está estabelecida ou se uma aplicação responde. Tampouco a associação de um nome ao ASN prova, por si só, autorização para cada anúncio de origem. Perguntas sobre autorização exigem os registros de segurança e origem adequados; perguntas operacionais exigem observações do sistema vivo.

O valor do RDAP está justamente em funcionar como um livro de recursos: preservar unicidade, identidade, eventos e referências para coordenação. Ele fornece um ponto inicial confiável sem pretender controlar ou descrever a operação a cada instante.

Um perfil esparso descreve o que não foi declarado

A PeeringDB é um diretório de coordenação mantido por seus participantes. A resposta capturada para o ASN 136022 contém uma linha de rede, de id 40097, chamada Janani Technology. O registro tem estado de perfil ok e informa atualização em 4 de abril de 2026, às 16:50:22 UTC.

O conteúdo é esparso. Não há linhas netixlan, usadas pela PeeringDB para representar conexões de redes em LANs de pontos de troca. Também estão vazios ou nulos os campos de site, tipo de rede, política geral de peering, conjunto IRR e quantidades de prefixos IPv4 e IPv6.

Esses vazios têm significado limitado e preciso: o perfil capturado não publicou aquelas declarações. Eles não provam que a Janani Technology esteja ausente de pontos de troca, não tenha ligação bilateral ou privada, nem que deixe de manter interconexões em outro contexto. Um campo de política vazio não permite classificá-la como aberta, seletiva ou restritiva. Campos de prefixos sem valor não demonstram que o ASN não origine espaço de endereços.

O mesmo cuidado vale para ok. É o estado de uma linha no diretório, e não um monitor de sessão, equipamento ou serviço. Para um peer em potencial, o perfil esparso funciona como uma lista de perguntas: quais contatos e políticas são válidos, onde existe interconexão e qual sessão pode ser verificada por uma parte autorizada? A resposta precisa vir de dados operacionais ou contratuais apropriados, não de uma inferência sobre campos vazios.

A observação do RIS tem relógio e método

O RIPE Routing Information Service, ou RIS, coleta informações BGP em pontos de observação participantes. A resposta de routing-status usada nesta análise é uma captura datada, com query_time de 7 de agosto de 2026, 00:00 UTC. Os valores abaixo descrevem essa resposta e não devem ser apresentados como estado atual ou mais recente depois do horário registrado.

Na captura, rotas qualificadas para o recurso 136022 estavam visíveis para 326 de 327 peers RIS full-feed listados para IPv4 e para 320 de 320 peers listados para IPv6. Os campos de espaço anunciado registraram um prefixo IPv4, correspondente a 256 endereços, e dois prefixos IPv6, correspondentes a duas redes /48.

Esses denominadores dão contexto à observação. O produto também informa que exclui rotas vistas por menos de dez peers RIS full-feed. Assim, a resposta descreve rotas que atenderam ao limiar dentro daquele conjunto de coletores. Uma rota abaixo do limiar pode não aparecer, mesmo que tenha sido vista em algum ponto; uma rota vista por todos os peers listados de uma família continua sendo uma afirmação sobre esse conjunto, não sobre toda a internet.

A resposta registra ainda um vizinho observado. Esse número deriva do modelo do coletor. Não equivale automaticamente a um peer comercial direto, contrato, sessão em exchange, instalação ou caminho físico independente. Também não mede tráfego, capacidade ou preferência de rota.

A formulação defensável é simples: no horário consultado, rotas qualificadas apareceram amplamente nos denominadores de observação informados. Para saber se o anúncio era autorizado, se um serviço estava acessível, se havia capacidade disponível ou se a arquitetura suportaria uma falha, seriam necessários outros dados.

326/327 e 320/320 não medem experiência do usuário

Uma razão de visibilidade pode parecer um indicador de disponibilidade, mas as duas ideias pertencem a camadas diferentes. Um coletor BGP observa anúncios de alcance entre sistemas autônomos. Ele não executa a aplicação do cliente, não mede todas as políticas de filtragem e não conhece cada dependência física ou lógica ao longo do caminho.

Portanto, 326/327 para IPv4 não garante que todos os usuários alcançassem todos os endereços associados. Da mesma forma, 320/320 para IPv6 não prova alcance universal. Uma aplicação pode falhar apesar de seu prefixo continuar visível, e um cliente pode enfrentar um problema local que não altera o anúncio observado pelos coletores.

As quantidades anunciadas também não são medições de capacidade. Um prefixo IPv4 representando 256 endereços e dois prefixos IPv6 representando duas redes /48 descrevem o campo de espaço retornado pelo produto. Não informam volume de tráfego, uso, velocidade, redundância ou qualidade de serviço.

Cada campo temporal conserva seu papel

O campo de última observação menciona 103.134.41.0/24, com origem 136022, em 7 de agosto de 2026, 00:00 UTC. O valor temporal coincide com o query_time, mas os campos não se tornam um só. O primeiro dá contexto à resposta; o segundo pertence a um prefixo selecionado pelo produto.

Já o campo de primeira observação menciona 103.134.42.0/24, também com origem 136022, em 13 de fevereiro de 2019, 16:00 UTC. São prefixos e funções diferentes. Sem um histórico de rotas construído para análise de continuidade, não é correto transformar essas datas em uma narrativa sobre quando a rede começou, parou ou mudou anúncios.

Também não se deve converter uma origem observada em prova automática de autorização. A visão do coletor mostra o que apareceu no BGP segundo seu método. A validade de uma autorização de origem é outra pergunta, dependente de evidência própria.

Uma sequência de verificação útil

Para um operador, pesquisador ou profissional de resposta a incidentes, o primeiro passo é confirmar que AS136022 e Janani Technology identificam o objeto pretendido. O diretório e o RDAP ajudam a evitar colisões de nome. Em seguida, o registro administrativo oferece o intervalo exato, o nome do objeto, o estado e os eventos que devem ser preservados como fatos de cadastro.

A PeeringDB pode então ser lida como superfície de declarações. Campos preenchidos orientam perguntas; campos vazios abrem perguntas. Um operador autorizado pode comparar o perfil com configuração, contratos e estado de sessões. Um observador público deve deixar o que não foi declarado como desconhecido.

Quando a pergunta é de roteamento, a análise deve guardar produto, instante da consulta, família de endereços, denominador de peers, limiar de exclusão e prefixos relevantes. Uma decisão sensível pode pedir comparação com outros pontos de observação compatíveis no tempo. Perguntas sobre serviço exigem testes ponta a ponta; perguntas sobre capacidade exigem medidas definidas em uma janela clara.

Essa ordem evita que uma fonte substitua outra. A APNIC identifica o recurso, mas não comprova rota. A PeeringDB publica coordenação, mas não comprova sessão. O RIS observa rotas, mas não comprova resultado para o cliente.

O que permanece fora do registro público

As fontes sustentam uma descrição limitada da identidade administrativa do AS136022, de um perfil de coordenação esparso e de uma observação de rotas com escopo temporal e metodológico. Não sustentam afirmações sobre serviços da Janani Technology, área geográfica de operação, clientes, instalações, equipamentos, provedores upstream, escala comercial ou posição de mercado.

Também não demonstram presença em exchange, relação com route server, sessão ao vivo, topologia física, volume de tráfego, throughput, latência, capacidade, diversidade, isolamento de falhas, resiliência, disponibilidade ou desempenho. Não há base para inferir interrupção a partir de um campo vazio, nem para inferir alcance universal a partir de uma proporção de visibilidade.

O registro da APNIC, o perfil da PeeringDB e a captura datada do RIPE RIS são camadas distintas de evidência; nenhuma delas, isoladamente, comprova sessão de peering ao vivo, alcance universal, autorização de rota, capacidade, resiliência ou serviço ao cliente.

O que acompanhar

  • mudanças documentadas na identidade, no estado administrativo ou nos eventos do objeto AS136022 no RDAP da APNIC;
  • preenchimento ou revisão dos campos de identidade, política, conjunto IRR, quantidades de prefixos ou linhas de exchange na PeeringDB;
  • observações posteriores que conservem horário da consulta, família de endereços, denominador de peers e limiar de baixa visibilidade;
  • evidência apropriada de origem quando a pergunta for autorização de rota;
  • telemetria autorizada de sessão ou teste de aplicação compatível no tempo quando a pergunta envolver operação ou impacto ao cliente.

Fontes