Resumo

  • A Bangladesh Telecommunication Regulatory Commission e a ISP Association of Bangladesh identificam a Planet Information Technology Solution Limited como ISP em Dhaka.[8][9] A APNIC relaciona a organização ao AS136903 ativo, à alocação IPv4 103.98.106.0/23 e à atribuição IPv6 2001:df1:1780::/48.[10][11][13][14] Esses registros estabelecem identidade e responsabilidade, não uma nota de desempenho.
  • Na captura analisada, a RIPE NCC observava o AS136903 anunciando 103.98.107.0/24 e 2001:df1:1780::/48.[15][16] É uma visão limitada de coletores BGP. Ela não mede disponibilidade, capacidade, latência nem a experiência de todos os clientes.
  • O AS137491 aparecia como único ASN vizinho na resposta pública consultada.[17] Isso não demonstra que a Planet tenha apenas um fornecedor, um caminho físico ou nenhuma conexão privada ou de contingência. A observação transforma diversidade em uma pergunta que precisa de prova direta.
  • As duas rotas observadas estavam valid no validador RPKI da RIPE NCC.[18][19] O resultado confirma compatibilidade entre origem, comprimento e ROA naquele momento. Não garante caminho, filtragem, segurança completa, tempo de atividade ou cumprimento contratual.
  • O site da empresa descreve acesso residencial e corporativo, fibra, largura de banda dedicada, IP estático, apoio a VPN, BDIX ou CDN e objetivos de serviço.[1]-[7] São capacidades e compromissos publicados. O conjunto de evidências não traz medições independentes de velocidade, perda, latência, disponibilidade, recuperação ou resultado de cliente.
  • O domínio atual planet-itsolutions.com funcionava na observação, enquanto o domínio histórico preservado pelo diretório respondeu NXDOMAIN. Esse sinal mostra custo de sincronização da identidade pública; não comprova indisponibilidade, duração, causa ou impacto.
  • O custo duradouro está na supervisão de registros e rotas, integração de ROA, paridade IPv4/IPv6, manutenção de DNS e e-mail, contatos de abuso, coordenação de fornecedores, exceções, evidências e portabilidade.

Uma empresa exata por trás de nomes diferentes

O objeto do diretório fixa a entidade como Md. Abdus Salam T/A Planet Information Technology Solution Ltd. As páginas públicas usam com mais frequência Planet Information Technology Solution Ltd. ou Planet Information Technology Solution Limited. Não se deve apagar essas diferenças por conveniência. A ligação precisa ser sustentada por identificadores, endereços, funções e registros independentes.

O cadastro da ISPAB oferece uma primeira ponte. Ele associa à Planet a inscrição G-351, uma licença divisional de ISP, endereço em Dhaka e o site atual.[8] Uma lista da BTRC datada de 23 de dezembro de 2024 inclui a empresa na linha 127, com a licença 14.32.0000.702.45.591.24.292.[9] A APNIC denomina o AS136903 como PITSL-AS-AP e o vincula à organização ORG-PITS1-AP.[10][11] As três famílias convergem para a mesma empresa do diretório.

Essa convergência é limitada. A BTRC registra uma posição regulatória em documento datado. A ISPAB mantém uma relação associativa. A APNIC mantém recursos numéricos e contatos. Nenhuma delas mede todos os circuitos, valida cada contrato ou certifica cada promessa do site. Uma análise responsável preserva a função, a data e o alcance de cada fonte.

A superfície de controle pública inclui ASN, recursos IPv4 e IPv6, anúncios BGP, ROA, contatos administrativos, técnicos e de abuso, domínio, nameservers, e-mail, site, ofertas e canais de suporte. Esses elementos podem divergir. Uma rota pode continuar visível enquanto um contato envelhece. O site pode ser atual, mas um diretório ainda carregar um domínio antigo. Continuidade depende da reconciliação dessas camadas.

As fontes não descrevem um modelo próprio de inteligência artificial da Planet. Não há documento sobre treinamento, benchmark, arquitetura privada ou implantação de IA em cliente. A capacidade observável é a de um operador de rede. Confiabilidade de produto exige medição repetida. Resultado de produção do cliente exige evidência atribuível. Misturar essas três categorias criaria uma narrativa simples, porém falsa.

APNIC como livro operacional de registros

O objeto RDAP do AS136903 está ativo e relaciona o identificador à Planet.[10] O objeto ORG-PITS1-AP mantém o nome e os vínculos públicos da organização.[11] O IRT-PITSL-BD publica um caminho para comunicações de abuso e datas de validação de caixas funcionais.[12] A separação importa: quem administra uma conta pode não ser quem altera uma rota ou trata um incidente.

O estado active não quer dizer que todos os serviços estejam saudáveis. Validar uma caixa postal não mede velocidade de resposta nem autoridade de reparo. O registro funciona como livro: preserva unicidade, delegação, papéis e histórico. Não encaminha pacotes e não observa a aplicação do cliente. Por isso, funções publicadas precisam de testes e recuperação que sobrevivam a mudanças de pessoal.

A APNIC registra 103.98.106.0/23 como alocação IPv4 ativa.[13] Ela contém dois /24. A visão BGP observada mostrava 103.98.107.0/24, um desses blocos, como anúncio originado pelo AS136903.[15] Registro e rota são compatíveis, mas respondem perguntas distintas. O primeiro mostra a delegação registrada; a segunda mostra o estado visto por coletores. Não há base para inferir o uso de cada endereço nem a situação do outro /24.

A atribuição IPv6 2001:df1:1780::/48 também está ativa.[14] O mesmo prefixo apareceu no BGP.[15][16] É um sinal técnico positivo de operação dual stack. Não prova que todo cliente receba IPv6, que cada aplicação tenha paridade funcional ou que o suporte teste as duas famílias de forma equivalente.

O custo dos recursos está no ciclo de vida. Conta da APNIC, pessoas autorizadas, recuperação, contatos, inventário de prefixos, filtros, ROA, DNS reverso e dependências de clientes precisam permanecer coerentes. A portabilidade só é real quando esses componentes podem mudar em uma sequência conhecida, com validação e retorno.

O contato de abuso acrescenta uma cadeia específica. Publicar um endereço cria uma porta de entrada. Ainda é necessário autenticar a denúncia, ligar endereço e horário ao serviço correto, proteger terceiros, coordenar correção, manter prova e fechar o caso. O registro ajuda na atribuição; não garante o resultado da investigação.

O que o roteamento observado realmente mostra

Os dados de prefixos anunciados da RIPE NCC apresentavam 103.98.107.0/24 e 2001:df1:1780::/48 na janela congelada.[15] O estado de roteamento indicava visibilidade junto aos peers RIS consultados para uma rota de cada família.[16] É a contraparte em execução dos recursos registrados: os identificadores não ficaram apenas no papel.

Essa visão não é uma tabela global completa nem um relatório de disponibilidade. Uma rota visível pode conduzir a serviço congestionado ou indisponível. Coletores podem divergir sem que usuários enfrentem falha. O diagnóstico deve separar visibilidade BGP, alcance de pacotes, saúde do DNS, circuito de acesso e disponibilidade da aplicação.

O AS137491 foi o único vizinho visível na resposta usada.[17] Seria incorreto chamá-lo automaticamente de único upstream da Planet. Caminhos privados, pontos de troca, links de contingência não preferidos, servidores de rota e contratos não aparecem integralmente num coletor. O fato defensável é mais estreito: a diversidade comprada precisa ser demonstrada diretamente.

Verificar diversidade significa examinar fibras, dutos, prédios, energia, equipamentos, fornecedores, políticas e procedimento de mudança. Dois contratos podem compartilhar a mesma falha física. Ao contrário, uma relação visível pode ocultar contingência inativa. A medição deve corresponder ao serviço contratado.

O anúncio IPv4 mais específico dentro do /23 cria uma obrigação de integração. Filtros, maxLength do ROA, ferramentas de segurança, monitoramento e documentação precisam aceitar o mesmo plano. Uma regra que só admita o agregado rejeitaria um /24 intencional; uma regra larga demais poderia autorizar um anúncio não planejado.

Dual stack cria dois caminhos de controle. IPv4 e IPv6 podem divergir em roteamento, firewall, DNS, equipamento e aplicação. Um teste IPv4 bem-sucedido não encerra uma falha IPv6. Painéis e procedimentos devem nomear a família afetada e verificar o serviço de ponta a ponta.

RPKI: autorização de origem, não garantia do serviço

O validador da RIPE NCC classificou como valid a combinação AS136903 e 103.98.107.0/24.[18] O ROA cobrindo 103.98.106.0/23 permitia comprimento máximo /24. O par AS136903 e 2001:df1:1780::/48 também estava válido.[19] Os resultados reduzem a incerteza sobre a origem autorizada.

O alcance é estreito. A validação de origem não autentica o caminho inteiro, não verifica se todos os operadores filtram inválidos e não mede criptografia, perda, latência ou velocidade. Uma rota válida pode entregar um serviço com falha. Um vazamento de rota pode conservar a origem correta e ainda produzir propagação indesejada.

O ciclo de mudança concentra o custo. Nova origem, prefixo mais específico ou ASN de contingência precisa ser coordenado com o ROA. Ativar a rota antes da autorização pode torná-la invalid. Manter maxLength desnecessariamente amplo aumenta o espaço autorizado. A mudança deve incluir intenção, sequência, verificação, retorno e dono do encerramento.

O acesso à administração RPKI precisa sobreviver à emergência. Um caminho de contingência não está pronto se ninguém consegue ajustar sua autorização. Contas, funções, recuperação e aprovações devem ser testadas. Resultados de validadores precisam ser retidos com horário, prefixo, origem e ROA para explicar divergências futuras.

Capacidade, confiabilidade e resultado do cliente

O site da Planet apresenta acesso residencial e empresarial, fibra, banda dedicada, opções de IP estático e suporte relacionado a VPN.[1][2][3] A página de pacotes publica níveis e referências a BDIX, CDN ou contenção.[4] Páginas de serviço e contato expressam objetivos de restauração, resposta, instalação ou nível de serviço.[3][5][7]

Essas páginas mostram o que a empresa afirma ser capaz de fornecer. Registros e rotas tornam a capacidade de rede plausível e observável. Eles não verificam a qualidade de cada produto. Prova de confiabilidade exigiria disponibilidade, perda, latência, jitter, capacidade, congestionamento, restauração e resposta medidos em período e escopo definidos.

Não há série independente desse tipo nas fontes. Um número no site continua sendo compromisso, objetivo ou mensagem comercial. Para virar conclusão, exige ponto de medição, exclusões, janela, dono dos dados, distribuição de incidentes e remédio contratual. Uma média mensal pode esconder interrupções repetidas numa hora crítica.

O resultado do cliente é outra categoria. Uma organização pode querer sustentar filiais, voz, pagamentos, nuvem ou cópias de segurança. Não há caso de cliente atribuível neste conjunto. A ausência não prova sucesso nem fracasso. Ela apenas impede a criação de depoimento ou benefício de produção.

Testes de aceitação devem ser definidos antes do serviço: IPv4 e IPv6, DNS, caminhos de aplicação, velocidade nos períodos acordados, contingência, segurança, contatos e evidências. Este artigo não executou teste privado nem comparação de fornecedores. Ele descreve os controles necessários para avançar de capacidade visível a uma conclusão de confiabilidade.

O custo de uma identidade pública em transição

O site e o cadastro da ISPAB usam planet-itsolutions.com.[1][8] Na observação, o domínio resolvia e publicava registros de web, nomes, e-mail e SPF. O domínio antigo mantido no diretório respondeu NXDOMAIN. Isso quer dizer que o nome consultado não existia naquele instante; não informa duração, causa ou impacto.

Uma mudança de domínio alcança registrar, DNS, site, e-mail, certificados, contas, contratos, faturas, diretórios, contatos APNIC, suporte e monitoramento. Um site novo não corrige uma caixa funcional antiga. Redirecionamento web não redireciona e-mail. Encerrar a transição exige inventário, responsáveis e teste externo.

A perda do domínio antigo pode atrasar denúncias de abuso, fornecedores e clientes que ainda usam referência histórica. Também pode criar risco se o nome abandonado voltar a ser registrável. A estratégia precisa decidir quais serviços preservar, quem notificar e como encontrar ligações residuais.

O domínio atual também tem fronteiras independentes: registrar, delegação, nameservers autoritativos, origem web, MX e SPF. A perda da conta de registrar pode impedir correções enquanto o site ainda funciona. Um erro DNS pode afetar web e correio sem retirar as rotas do AS136903. O monitoramento deve distinguir essas camadas.

Supervisão, integração, manutenção e exceções

Supervisão

A supervisão começa com inventário controlado: ASN, prefixos, anúncios previstos, ROA, filtros, contatos, DNS, e-mail, licença, fornecedores, compromissos e testes. Cada item tem frequência distinta. Rotas podem exigir alerta rápido; contato ou licença, revisão periódica. Uma única cor não representa todos os estados.

A qualidade da evidência também deve ser acompanhada. RIPE RIS descreve uma visão datada. APNIC descreve autoridade registrada. Uma página empresarial descreve uma afirmação. A lista da BTRC é um documento datado. A equipe precisa registrar fonte, horário, valor e pergunta respondida.

Integração

Integração conecta inventário a roteadores, ROA, filtros, segurança, DNS reverso, monitoramento, chamados e contratos. Fornecedores introduzem contas, escaladas, faturas e saídas. Clientes introduzem IP estático, VPN, firewalls, equipamentos e aplicações. Uma mudança correta de um lado pode quebrar a suposição do outro.

As responsabilidades no ponto de demarcação precisam ser explícitas. Quem mede? Quem altera o roteador? Quem controla DNS? Quem autoriza anúncio emergencial? Quem informa o cliente? Sem esse mapa, cada equipe pode concluir sua parte e o serviço completo continuar indisponível.

Manutenção

Rotas, filtros, ROA, contatos, contas, certificados, DNS, ofertas e painéis mudam. IPv4 e IPv6 duplicam parte dos controles. Identidade atual e domínio histórico precisam ser revistos em cadastros e diretórios. Mudanças e exceções devem preservar evidência suficiente para reconstruir intenção, aprovação, efeito e retorno.

Tratamento de exceções

Uma origem emergencial pode aguardar acesso RPKI. Uma denúncia pode chegar incompleta. A conta DNS pode ficar bloqueada durante migração. IPv4 pode voltar antes de IPv6. Cada exceção precisa de classificação, autoridade, expiração, retorno e prova de fechamento. Uma solução temporária sem data final vira dependência oculta.

Modos de falha que precisam de teste

  1. Contato obsoleto: o objeto APNIC está ativo, mas a caixa ou a função não responde. Testar periodicamente e manter recuperação fora da mesma falha.
  2. Divergência entre rota e ROA: nova origem ou comprimento fica inválido. Comparar intenção, BGP e ROA antes e depois da mudança.
  3. Retirada de rota: um coletor deixa de ver IPv4, IPv6 ou ambos. Consultar múltiplas vistas e o serviço antes de classificar a causa.
  4. Concentração oculta: só uma adjacência está visível. Verificar fornecedores, caminhos físicos, energia e contingência para o serviço comprado.
  5. Divergência IPv4/IPv6: uma família funciona e outra falha. Testar separadamente rota, DNS, firewall e aplicação.
  6. Perda de autoridade DNS: valores permanecem corretos, mas a conta não é recuperável. Testar funções, autenticação e exportação.
  7. Domínio antigo: parceiros usam um nome que retorna NXDOMAIN. Inventariar referências e oferecer caminhos substitutos.
  8. Escalada de suporte: o primeiro contato responde, mas não pode autorizar reparo. Manter papéis, alcance e substituição verificados.
  9. Promessa sem medida: um objetivo vira alegação universal. Exigir método, escopo, período e exclusões.
  10. Exceção permanente: rota manual, ROA amplo ou contato alternativo permanece sem dono. Associar expiração e evidência de fechamento.

Compra, governança e saída

Um comprador deve usar a evidência pública como ponto de partida, não como veredicto. Convém verificar identidade e licença, prefixos previstos, origem, RPKI, suporte IPv4/IPv6, diversidade de fornecedor e física, responsabilidade por DNS e e-mail, monitoramento, incidente, medição, escalada e saída.

O contrato deve separar capacidade de serviço medido. IP estático, suporte a VPN, BDIX/CDN e objetivos de restauração precisam de definição. Quem mede, a partir de onde, em qual janela e com qual remédio? Uma taxa de disponibilidade sem perímetro transfere ao cliente o custo de interpretar a promessa.

A saída deve ser desenhada na entrada. Endereços do cliente, configurações, DNS, e-mail, certificados, contas e evidências precisam ser transferíveis. Endereço preso ao provedor pode exigir renumeração. Domínio em transição requer coexistência e desligamento comprovado. Contingência só conta depois de autorização, roteamento, DNS, segurança e aplicação passarem juntos.

A conclusão defensável não é elogio nem denúncia de falha. A Planet apresenta uma superfície real e auditável: AS136903 e recursos ativos no registro, IPv4 e IPv6 observados e pares de origem válidos em RPKI. Documentos datados e páginas próprias oferecem mais sinais de responsabilidade e capacidade. Nada disso prova confiabilidade contínua ou sucesso de cliente. A qualidade depende de alinhar autoridade, estado em execução, responsabilidade comercial e recuperação.

Fontes

  1. Página inicial da Planet.
  2. Página institucional da Planet.
  3. Página de serviços da Planet.
  4. Página de pacotes da Planet.
  5. Página de contato da Planet.
  6. Página do presidente da Planet.
  7. Documento tarifário da BTRC publicado pela Planet.
  8. Cadastro da Planet na ISPAB.
  9. Lista BTRC de licenças divisionais de ISP de 23 de dezembro de 2024.
  10. APNIC RDAP do AS136903.
  11. APNIC RDAP de ORG-PITS1-AP.
  12. APNIC RDAP de IRT-PITSL-BD.
  13. APNIC RDAP de 103.98.106.0/23.
  14. APNIC RDAP de 2001:df1:1780::/48.
  15. Prefixos anunciados observados pela RIPE NCC.
  16. Estado de roteamento da RIPE NCC.
  17. Observação de ASN vizinhos da RIPE NCC.
  18. Validação RPKI de 103.98.107.0/24.
  19. Validação RPKI de 2001:df1:1780::/48.

Nota da imagem: a fotografia de cabo de fibra óptica enrolado e conduíte é de Rubin Observatory / NSF / AURA, disponível no Wikimedia Commons sob CC BY 4.0. Ela fornece apenas contexto genérico de infraestrutura e não retrata a Planet, sua rede, instalações, pessoas, clientes, incidentes, confiabilidade ou resultados de produção.