Résumé

  • Des dossiers de la BTRC et de l’ISP Association of Bangladesh identifient Planet Information Technology Solution Limited comme FAI à Dhaka.[8][9] APNIC relie séparément l’organisation à l’AS136903 actif, à l’allocation IPv4 103.98.106.0/23 et à l’attribution IPv6 2001:df1:1780::/48.[10][11][13][14] Ces registres établissent une identité et des responsabilités, pas une note de performance.
  • Lors de l’observation, RIPE NCC voyait l’AS136903 annoncer 103.98.107.0/24 et 2001:df1:1780::/48.[15][16] Il s’agit d’une vue bornée de collecteurs BGP. Elle ne mesure ni la disponibilité, ni la capacité, ni la latence, ni l’expérience de tous les clients.
  • Un seul ASN voisin, AS137491, apparaissait dans la vue publique interrogée.[17] Cette donnée ne permet pas d’affirmer que Planet ne dispose que d’un fournisseur, d’un chemin physique ou d’aucune liaison privée ou de secours. Elle transforme la diversité en question de vérification.
  • Les deux annonces observées étaient valid selon le validateur RPKI de RIPE NCC.[18][19] Cela signifie que l’origine et la longueur correspondaient à des ROA disponibles au moment de la requête. Cela ne garantit pas le chemin, le filtrage, la sécurité complète, le temps de fonctionnement ou le respect d’un engagement commercial.
  • Le site de Planet décrit l’accès résidentiel et professionnel, la fibre, la bande passante dédiée, l’adresse IP statique, l’assistance VPN, le BDIX ou CDN et des objectifs de service.[1][2][3][4][5][6][7] Ces déclarations montrent une capacité revendiquée. Aucune mesure indépendante de débit, perte, latence, disponibilité, rétablissement ou résultat client n’est fournie dans l’ensemble de preuves utilisé ici.
  • Le domaine actuel planet-itsolutions.com fonctionnait, tandis que l’ancien domaine conservé dans le répertoire répondait NXDOMAIN lors de l’observation DNS. Ce signal révèle un coût de synchronisation de l’identité publique; il ne prouve ni panne, ni durée, ni cause, ni impact client.
  • Le coût durable concerne la supervision des registres et des routes, l’intégration des ROA, la parité IPv4/IPv6, le maintien du DNS et du courrier, les contacts d’abus, la coordination des fournisseurs, les exceptions, les preuves et la portabilité.

Une société exacte derrière plusieurs écritures

L’objet du répertoire porte le nom Md. Abdus Salam T/A Planet Information Technology Solution Ltd. Les pages publiques utilisent plus souvent Planet Information Technology Solution Ltd. ou Planet Information Technology Solution Limited. Ces différences ne doivent pas être effacées par commodité. Elles doivent être rapprochées à l’aide d’identifiants, d’adresses, de rôles et de dossiers indépendants.

Le répertoire ISPAB fournit un premier pont. Il attribue à Planet l’adhésion G-351, un numéro de licence de FAI divisionnel, une adresse à Dhaka et le site actuel.[8] Une liste de la Bangladesh Telecommunication Regulatory Commission datée du 23 décembre 2024 contient Planet à la ligne 127 avec la licence 14.32.0000.702.45.591.24.292.[9] APNIC nomme l’AS136903 PITSL-AS-AP et le relie à l’organisation ORG-PITS1-AP.[10][11] Les trois familles de dossiers convergent donc vers la même société du répertoire.

Cette convergence reste limitée. La BTRC enregistre une situation réglementaire dans un document daté. ISPAB gère une relation d’association. APNIC maintient les ressources numériques et les contacts. Aucun de ces organismes ne mesure chaque circuit, ne valide chaque contrat ou ne certifie chaque promesse du site. Une bonne analyse conserve la fonction et la date de chaque source.

La surface de contrôle de Planet comprend l’ASN, les blocs IPv4 et IPv6, les annonces BGP, les ROA, les contacts administratifs, techniques et d’abus, le domaine, les serveurs de noms, le courrier, le site, les offres et les canaux de soutien. Ces éléments peuvent diverger. Une route peut rester visible alors qu’un contact est obsolète. Un site peut être à jour alors qu’un ancien domaine apparaît encore dans un annuaire. La continuité dépend de la réconciliation de ces plans.

Les preuves ne décrivent pas un modèle d’intelligence artificielle propre à Planet. Aucun document ne présente de modèle, de méthode d’entraînement, de résultat de référence ou de déploiement client. La capacité pertinente est celle d’un opérateur réseau. La fiabilité du produit exige des mesures répétées. Le résultat client exige une preuve attribuable. Mélanger ces trois catégories produirait un récit plus simple mais faux.

APNIC comme grand livre opérationnel

L’objet RDAP de l’AS136903 est actif et relie l’identifiant à Planet.[10] L’objet ORG-PITS1-AP conserve le nom et les contacts publics de l’organisation.[11] L’objet IRT-PITSL-BD expose une voie de signalement d’abus et des dates de validation de boîtes de rôle.[12] Cette séparation des fonctions est utile : la personne qui administre un compte n’est pas nécessairement celle qui déploie une route ou traite un incident.

Le statut actif d’un objet ne veut pas dire que tous les services sont sains. Une validation de courrier ne mesure pas la rapidité de réponse. Le registre est un grand livre : il conserve l’unicité, la délégation, les rôles et l’historique. Il ne pilote pas les routeurs et ne voit pas l’application du client. Les rôles publiés doivent donc être testés et associés à des moyens de reprise qui survivent aux départs de personnel.

APNIC enregistre 103.98.106.0/23 comme allocation IPv4 active.[13] Cette allocation couvre deux réseaux /24. La vue BGP observée montrait 103.98.107.0/24, l’un des deux, comme annonce de l’AS136903.[15] Le registre et la route sont compatibles, mais ils répondent à des questions distinctes. Le premier indique la délégation enregistrée; la seconde décrit l’état vu par des collecteurs. Rien ne permet d’en déduire l’usage de chaque adresse ou l’état de l’autre /24.

L’attribution IPv6 2001:df1:1780::/48 est également active.[14] Cette même plage apparaissait dans BGP.[15][16] Cela constitue un signal technique positif de double pile. Cela ne prouve pas que chaque client bénéficie d’IPv6, que toutes les applications ont une parité fonctionnelle ou que le soutien teste correctement les deux familles.

Le coût de ces ressources réside dans leur cycle de vie. Il faut contrôler le compte APNIC, les personnes autorisées, la récupération, les contacts, l’inventaire de préfixes, les filtres, les ROA, le DNS inverse et les dépendances client. La portabilité n’est réelle que si ces éléments peuvent changer dans un ordre connu, avec une validation et un retour arrière.

Le contact d’abus ajoute un travail particulier. Publier une adresse permet de trouver une porte. Il faut encore authentifier le signalement, relier l’adresse et l’heure au bon service, protéger les autres clients, coordonner la correction, conserver la preuve et clore le cas. Un registre facilite l’attribution; il ne garantit pas le résultat de l’enquête.

Ce que le routage observé montre réellement

Les données RIPE NCC sur les préfixes annoncés montraient 103.98.107.0/24 et 2001:df1:1780::/48 dans la fenêtre de requête.[15] L’état de routage indiquait une visibilité auprès des pairs RIS interrogés pour une route de chaque famille.[16] C’est le pendant en fonctionnement des ressources enregistrées : les identifiants ne restent pas uniquement sur le papier.

Cette vue n’est pas une table mondiale complète ni un relevé de disponibilité. Une route visible peut conduire à un service congestionné ou indisponible. Une différence entre collecteurs peut apparaître sans panne chez les utilisateurs. Pour interpréter une alerte, il faut séparer visibilité BGP, accessibilité des paquets, santé du DNS, état du circuit d’accès et disponibilité de l’application.

AS137491 était le seul voisin visible dans la réponse publique utilisée.[17] Il serait incorrect d’en faire automatiquement le fournisseur unique de Planet. Les chemins privés, les points d’échange, les liaisons de secours non préférées, les serveurs de routes et les contrats ne sont pas entièrement révélés par un collecteur. Le fait utile est plus modeste : la diversité du service acheté doit être démontrée directement.

Une vérification de diversité doit porter sur les chemins physiques, les conduits, l’énergie, les équipements, les bâtiments, les fournisseurs, les politiques et la procédure de bascule. Deux contrats peuvent partager le même domaine de panne. À l’inverse, une seule relation visible à un instant donné peut masquer une capacité de secours. La mesure doit correspondre au périmètre du client.

L’annonce IPv4 plus spécifique à l’intérieur du /23 crée une contrainte d’intégration. Les filtres, le maxLength du ROA, les systèmes de sécurité, la surveillance et la documentation doivent accepter le même plan. Une configuration qui n’autorise que l’agrégat rejetterait un /24 voulu; une règle trop large pourrait accepter une annonce non prévue.

La double pile impose deux chemins de contrôle. IPv4 et IPv6 peuvent diverger dans le routage, les pare-feu, le DNS, l’équipement client et les applications. Un test IPv4 réussi ne ferme pas un incident IPv6. Les tableaux de bord et les procédures doivent nommer la famille touchée et vérifier le service de bout en bout.

RPKI : autorisation d’origine, pas garantie de service

Le validateur RIPE NCC a classé comme valid l’origine AS136903 pour 103.98.107.0/24.[18] Le ROA couvrant 103.98.106.0/23 autorise une longueur maximale /24. Le couple IPv6 AS136903 et 2001:df1:1780::/48 était également valide.[19] Ces résultats réduisent l’ambiguïté sur l’origine autorisée.

La portée reste étroite. La validation d’origine n’authentifie pas tout le chemin, ne vérifie pas que tous les réseaux filtrent les routes invalides et ne mesure ni chiffrement, ni perte, ni latence, ni débit. Une route valide peut livrer un service défaillant. Elle peut aussi participer à une fuite de route tout en conservant la bonne origine.

Le cycle de changement est la principale dépense. Une nouvelle origine, un préfixe plus spécifique ou un ASN de secours doit être coordonné avec le ROA. Déployer la route avant l’autorisation peut créer un état invalide. Maintenir un maxLength inutilement large élargit l’espace autorisé. Le changement doit inclure intention, séquence, vérification, retour arrière et responsable de clôture.

L’accès au système RPKI doit survivre aux urgences. Une liaison de secours n’est pas prête si personne ne peut ajuster son autorisation. Les comptes, les rôles, la récupération et les approbations doivent être testés. Les résultats des validateurs doivent être conservés avec l’heure, le préfixe, l’origine et le ROA afin de comprendre une divergence ultérieure.

Capacité, fiabilité et résultat client

Le site de Planet présente des offres résidentielles et professionnelles, la fibre, la bande passante dédiée, des options d’adresse statique et une assistance liée aux VPN.[1][2][3] La page des forfaits publie des paliers et des mentions de BDIX, CDN ou contention.[4] Les pages de service et de contact emploient des objectifs de rétablissement, de réponse, d’installation ou de niveau de service.[3][5][7]

Ces pages montrent ce que l’entreprise dit pouvoir fournir. Les registres et routes rendent la capacité réseau plausible et observable. Ils ne vérifient pas la qualité de chaque produit. Une preuve de fiabilité demanderait des mesures de disponibilité, perte, latence, gigue, débit, congestion, rétablissement et réponse sur un périmètre et une période définis.

Aucune série indépendante de ce type ne figure dans les sources. Un chiffre affiché sur le site reste un engagement ou un message commercial. Pour le transformer en conclusion, il faut connaître le point de mesure, les exclusions, la période, la propriété des données, la distribution des incidents et le recours prévu. Une moyenne mensuelle peut masquer des coupures répétées à une heure critique.

Le résultat client est encore différent. Une entreprise peut vouloir maintenir ses succursales, sa voix, ses paiements, son cloud ou ses sauvegardes. Aucun cas client attribuable n’est fourni ici. Cette absence ne prouve ni réussite ni échec. Elle impose simplement de ne pas inventer de témoignage ou de bénéfice de production.

Les tests d’acceptation devraient être définis avant le service : IPv4 et IPv6, DNS, chemins applicatifs, débit aux périodes convenues, bascule, sécurité, contacts et preuves. Ce rapport n’a effectué aucun test privé ou référence comparative. Il décrit les éléments nécessaires pour passer d’une capacité visible à une conclusion de fiabilité.

Le coût d’une identité publique qui change

Le site et le dossier ISPAB utilisent planet-itsolutions.com.[1][8] Lors de l’observation, ce domaine résolvait et publiait des enregistrements web, de noms, de courrier et SPF. L’ancien domaine porté par le répertoire répondait NXDOMAIN. Cette réponse signifie que le nom interrogé n’existait pas à cet instant. Elle ne révèle ni la durée, ni la cause, ni l’impact.

Une transition de domaine touche le registrar, le DNS, le site, le courrier, les certificats, les comptes, les contrats, les factures, les annuaires, les contacts APNIC, le soutien et la surveillance. Un site nouveau ne corrige pas automatiquement une ancienne adresse de rôle. Un redirect web ne redirige pas le courrier. La fin de transition exige un inventaire, des propriétaires et des tests externes.

La perte d’un ancien domaine peut ralentir les signalements d’abus, les fournisseurs ou les clients qui utilisent une référence historique. Elle peut aussi créer un risque si un domaine abandonné devient disponible. La stratégie doit décider quels services maintenir, quels correspondants prévenir et comment vérifier les liens résiduels.

Le domaine actuel possède lui-même plusieurs frontières : enregistrement, délégation, serveurs de noms, origine web, MX et SPF. Une panne de compte registrar peut empêcher une correction alors que le site fonctionne encore. Une erreur DNS peut affecter web et courrier sans retirer les routes de l’AS136903. La surveillance doit distinguer ces couches.

Supervision, intégration, maintenance et exceptions

Supervision

La supervision commence par un inventaire contrôlé : ASN, préfixes, annonces prévues, ROA, filtres, contacts, DNS, courrier, licence, fournisseurs, engagements et tests client. Chaque élément a une fréquence différente. Le routage peut nécessiter une alerte rapide; un contact ou une licence nécessite une revue périodique. Une couleur unique ne peut pas représenter tous ces états.

La qualité des preuves doit aussi être surveillée. RIPE RIS décrit une vue datée. APNIC décrit une autorité enregistrée. Une page de l’entreprise décrit une promesse. Une liste BTRC est un document daté. L’équipe doit enregistrer la source, l’heure, la valeur et la question à laquelle elle répond.

Intégration

L’intégration relie l’inventaire aux routeurs, ROA, filtres, systèmes de sécurité, DNS inverse, surveillance, tickets et contrats. Les fournisseurs introduisent des comptes, des escalades, des factures et des sorties. Les clients introduisent des adresses statiques, VPN, pare-feu, équipements et dépendances applicatives. Une modification correcte d’un côté peut casser une hypothèse de l’autre.

Les responsabilités doivent être explicites au point de démarcation. Qui mesure? Qui change le routeur? Qui possède le DNS? Qui autorise une annonce d’urgence? Qui informe le client? Sans cette carte, plusieurs équipes peuvent terminer leur tâche alors que le service global reste indisponible.

Maintenance

Les routes, filtres, ROA, contacts, comptes, certificats, DNS, offres et tableaux de bord évoluent. IPv4 et IPv6 doublent certains contrôles. L’identité actuelle et l’ancien domaine doivent être revus dans les registres et annuaires. Les exceptions et changements doivent conserver assez de preuves pour reconstituer intention, approbation, effet et retour à un état accepté.

Traitement des exceptions

Une origine d’urgence peut attendre un accès RPKI. Un rapport d’abus peut être incomplet. Le compte DNS peut être verrouillé pendant une transition. IPv4 peut revenir avant IPv6. Chaque exception a besoin d’une classification, d’une autorité, d’une expiration, d’un retour arrière et d’une preuve de clôture. Une mesure temporaire sans date de fin devient une dépendance cachée.

Modes de défaillance à tester

  1. Contact obsolète : l’objet APNIC est actif, mais la boîte ou le rôle ne répond plus. Tester périodiquement et conserver une récupération hors bande.
  2. Divergence route-ROA : une nouvelle origine ou longueur devient invalide. Comparer intention, BGP et ROA avant et après changement.
  3. Retrait de route : un collecteur cesse de voir IPv4, IPv6 ou les deux. Vérifier plusieurs vues et le service client avant de classer la cause.
  4. Concentration cachée : une seule adjacency est visible. Vérifier fournisseurs, chemins physiques, énergie et bascule pour le service acheté.
  5. Divergence IPv4/IPv6 : une famille fonctionne et l’autre échoue. Tester séparément le routage, DNS, pare-feu et application.
  6. Perte d’autorité DNS : les valeurs sont correctes, mais le compte ne peut plus être récupéré. Tester rôles, authentification et export.
  7. Ancien domaine : des clients ou partenaires utilisent encore un nom NXDOMAIN. Inventorier les références et les voies de remplacement.
  8. Escalade de soutien : le premier contact répond sans pouvoir autoriser la réparation. Maintenir des niveaux de gravité et un chemin décisionnel.
  9. Rapport d’abus ambigu : l’heure, l’adresse ou la preuve sont incomplètes. Authentifier, préserver, agir proportionnellement et documenter.
  10. Confiance excessive dans le tableau de bord : BGP et RPKI sont verts tandis qu’un circuit ou une application échoue. Garder les signaux séparés.
  11. Dépendance de fournisseur : deux services apparemment distincts partagent un compte ou un domaine de panne. Tester la récupération et la sortie.
  12. Automatisation mal gouvernée : une mauvaise valeur est propagée rapidement. Exiger revue, déploiement progressif et retour arrière.

Ces scénarios ne sont pas présentés comme des incidents vécus par Planet. Ils découlent des frontières visibles et servent à formuler des tests vérifiables sans inventer l’architecture privée.

Diligence, portabilité et conclusion

Un acheteur devrait demander l’identité contractuelle, le périmètre, les routes attendues, les détenteurs de ressources, les ROA, la diversité, la méthode de mesure, les contacts, le dernier exercice et la procédure de sortie. Les réponses doivent séparer les contrôles de Planet, ceux du client et ceux d’un tiers.

La portabilité couvre bien plus que le circuit. Elle inclut ASN et adresses, filtres, ROA, DNS, courrier, certificats, configurations client, surveillance, journaux et coopération des fournisseurs. Une sortie doit être testée avant l’urgence. Une ressource portable sur le papier peut rester verrouillée par les accès ou la documentation.

Le jugement défendable est borné. Planet correspond à un objet de société réel, à une identité de FAI, à un ASN actif, à des ressources IPv4 et IPv6 visibles et à des autorisations d’origine valides. Le site expose une offre et des contacts substantiels. Ces éléments justifient une diligence approfondie; ils ne démontrent pas la fiabilité, la qualité du soutien ou la réussite d’un client. La valeur dépend de la discipline qui maintient autorité, état exécuté, promesse et résultat mesuré en accord.

Registre des sources

  1. Page d’accueil de Planet Information Technology Solution.
  2. Présentation de Planet Information Technology Solution.
  3. Services de Planet Information Technology Solution.
  4. Forfaits de Planet Information Technology Solution.
  5. Contacts de Planet Information Technology Solution.
  6. Page de la présidence de Planet Information Technology Solution.
  7. Document tarifaire hébergé par la société.
  8. Dossier de membre ISPAB.
  9. Liste BTRC des licences ISP divisionnelles datée du 23 décembre 2024.
  10. APNIC RDAP pour AS136903.
  11. APNIC RDAP pour ORG-PITS1-AP.
  12. APNIC RDAP pour IRT-PITSL-BD.
  13. APNIC RDAP pour 103.98.106.0/23.
  14. APNIC RDAP pour 2001:df1:1780::/48.
  15. Préfixes annoncés observés par RIPE NCC.
  16. État de routage RIPE NCC pour AS136903.
  17. Voisins ASN observés par RIPE NCC.
  18. Validation RPKI de 103.98.107.0/24.
  19. Validation RPKI de 2001:df1:1780::/48.

Observation complémentaire : les réponses DNS publiques des domaines actuel et historique ont été relevées le 2 août 2026; elles décrivent cet instant et non une disponibilité prolongée.

Note sur l’image : l’article utilise une photographie de câble de fibre optique et de conduit prise par Rubin Observatory / NSF / AURA, disponible sur Wikimedia Commons sous licence CC BY 4.0. Cette image fournit un contexte générique et ne représente ni Planet, ni son réseau, ni ses installations, ni ses clients, ni ses résultats.