Résumé

  • Les dossiers APNIC relient Techno Asia Infotech Limited à l’organisation active ORG-TAIL1-AP et à l’AS135037.[2][3][4] Lors de l’observation, les données RIPE NCC montraient six annonces IPv4 en /24, onze annonces IPv6 en /48 et une visibilité complète auprès des pairs RIS interrogés.[7][8] Ce sont des constats bornés, pas une mesure de disponibilité ni un résultat client.
  • Trois des routes IPv4 observées se trouvent dans des allocations portables enregistrées au nom de Techno Asia, tandis que trois autres sont des ressources non portables dont les dossiers d’enregistrement désignent d’autres titulaires.[5][6][8][10] L’ASN d’origine n’est donc ni un titre de propriété ni une description de contrat.
  • Le validateur RPKI de RIPE NCC a renvoyé valid pour chacun des six couples origine-préfixe IPv4 examinés.[11][12][13][14][15][16] Cette preuve est utile mais étroite : elle ne prouve ni la sécurité du chemin, ni la disponibilité, ni la latence, ni l’absence d’incident.
  • Les réponses DNS séparent l’origine web, les serveurs de noms faisant autorité, la messagerie et la politique SPF.[23] La racine du site de l’entreprise a répondu HTTP 200 avec un index de répertoire vide au moment de la vérification.[21] C’est un signal de maintenance du web public, pas la preuve d’une panne de l’AS135037.
  • Une liste BTRC datée du 23 décembre 2024 et des dossiers de l’ISP Association of Bangladesh placent Techno Asia dans un contexte de FAI.[17][18][19] Leurs dates et leurs libellés doivent être conservés : ils ne certifient pas à eux seuls la conformité actuelle, la qualité du service ou le nombre de clients.
  • Le coût déterminant est opérationnel : supervision des registres et contacts, intégration des routes et ROA, maintien des plans IPv4 et IPv6, contrôle du DNS et du courrier, gestion des exceptions, conservation des preuves et préparation de la portabilité.

Une société exacte derrière plusieurs libellés publics

Le répertoire BTW désigne l’objet de société comme Mohammed Ismail Hossain T/A Techno Asia Infotech Limited.[1] Le répertoire des membres APNIC contient le même nom long, alors que l’objet organisation d’APNIC emploie Techno Asia Infotech Limited et que d’autres annuaires utilisent des formes légèrement différentes.[2][4][18][19] La bonne méthode n’est pas de choisir arbitrairement un libellé « plus simple ». Il faut conserver l’identité canonique pour l’association à l’entité, puis citer le nom exact utilisé par chaque source.

Cette discipline évite deux erreurs opposées. La première consisterait à fusionner des sociétés seulement parce que leurs marques se ressemblent. La seconde consisterait à traiter chaque variation typographique comme une entreprise indépendante. Ici, la continuité entre l’objet du répertoire, le membre APNIC, l’organisation ORG-TAIL1-AP et l’AS135037 est suffisamment documentée pour soutenir une analyse du même opérateur, mais elle ne permet pas d’attribuer à cette entité tout équipement ou toute adresse apparaissant sur Internet.

L’objet PeeringDB pour l’AS135037 ajoute une identité de réseau nommée Techno Asia Infotech.[20] Les champs publics facultatifs y sont peu nombreux. Une fiche courte n’est ni la preuve d’une défaillance ni celle d’une absence d’interconnexion. Elle indique seulement ce que l’opérateur a rendu public dans ce répertoire. Les contrats, capacités, emplacements et politiques qui ne figurent pas dans la fiche doivent rester inconnus.

Cette identité est aussi un problème de continuité. Les contacts administratifs, techniques et d’abus doivent rester utilisables lorsque des personnes changent de poste, qu’une boîte aux lettres expire ou qu’un fournisseur est remplacé. Un registre peut conserver un objet actif alors que le circuit humain d’escalade s’est dégradé. La vérification périodique des rôles importe donc autant que la présence de l’identifiant.

Le registre fournit un grand livre, pas le réseau en fonctionnement

L’objet RDAP de l’AS135037 est actif et porte le nom TECHNOASIA-AS-AP, avec ORG-TAIL1-AP comme organisation inscrite.[3] L’objet organisation confirme Techno Asia Infotech Limited et conserve des dates de modification.[4] Deux objets d’adressage couvrent 103.206.228.0/23 et 103.206.230.0/24; ils sont décrits comme des ressources portables liées à l’organisation.[5][6]

Ces données servent de grand livre. Elles préservent l’unicité des ressources, un statut, des contacts et une chaîne de responsabilité documentaire. Elles ne commandent pas chaque routeur et ne disent pas si une application répond. Le plan de registre et le plan d’exécution doivent être comparés, pas substitués l’un à l’autre.

Cette distinction rejoint un principe simple de réalité opérationnelle : le code et la configuration en cours d’exécution ont la priorité lorsqu’on cherche à savoir ce qui se passe maintenant, tandis que le registre reste essentiel pour savoir qui devrait pouvoir autoriser et corriger l’état. Si une annonce BGP diverge de l’intention enregistrée, la bonne réponse n’est pas de déclarer automatiquement le registre faux ou la route malveillante. Il faut retrouver l’autorisation, l’objet concerné, la politique, le propriétaire de l’action et la preuve après changement.

La qualité du contrôle se mesure donc à la réconciliation. Une organisation mature connaît l’ensemble attendu des préfixes, leurs origines, leurs ROA, leurs filtres, les détenteurs des ressources, les dépendances client et la date du dernier contrôle. Une capture ponctuelle n’offre pas cette gouvernance, mais elle permet de tester si le récit public demeure cohérent.

Six routes IPv4, onze routes IPv6 et des relations différentes

La vue RIPE NCC observée pour AS135037 présentait six préfixes IPv4 en /24, onze préfixes IPv6 en /48, 1 536 adresses IPv4 et trois ASN adjacents observés.[7][8][9] La visibilité indiquée était de 328 sur 328 pairs de table complète pour IPv4 et de 322 sur 322 pour IPv6 au moment de la requête.[7] Ces chiffres décrivent la vue du collecteur. Ils ne mesurent ni débit, ni congestion, ni perte, ni portée auprès de chaque utilisateur.

Les six routes IPv4 étaient 103.206.228.0/24, 103.206.229.0/24, 103.206.230.0/24, 103.251.244.0/24, 103.239.42.0/24 et 220.247.129.0/24.[8] Les trois premières sont cohérentes avec les allocations portables enregistrées pour Techno Asia.[5][6] Les trois dernières apparaissent dans d’autres relations d’enregistrement et doivent être décrites comme des ressources non portables observées derrière l’AS135037, pas comme des blocs appartenant à Techno Asia.[10]

Cette différence peut correspondre à des services clients, à une délégation autorisée ou à d’autres accords légitimes. Les sources publiques ne révèlent pas les contrats. L’analyse responsable s’arrête donc à trois faits : l’origine observée, le détenteur enregistré et l’existence ou non d’une autorisation RPKI compatible. Le lien commercial reste à vérifier.

Les trois ASN voisins observés, AS150178, AS58682 et AS58945, indiquent une proximité dans les chemins collectés.[9] Ils ne peuvent pas être étiquetés automatiquement comme transitaires, pairs ou clients. Une relation BGP peut être asymétrique, varier selon la famille d’adresses ou être visible différemment selon le collecteur. Une vraie évaluation de résilience demanderait les contrats, les capacités, les chemins physiques, les politiques locales et des mesures répétées.

IPv6 mérite une gouvernance distincte. Onze /48 visibles montrent une présence IPv6, mais pas la parité des applications ni celle des procédures de reprise. Les filtres, ROA, alertes, DNS, équipements clients et chemins d’escalade doivent être testés dans les deux familles. Un tableau de bord qui surveille uniquement IPv4 peut déclarer la plateforme saine pendant qu’une partie IPv6 échoue.

RPKI : une autorisation d’origine à portée limitée

Les six requêtes RPKI gelées ont toutes renvoyé valid pour AS135037 et le préfixe correspondant.[11][12][13][14][15][16] Ce résultat signifie qu’au moment de la vérification, une autorisation d’origine compatible couvrait le couple ASN-préfixe. Il s’agit d’un contrôle important contre certaines annonces non autorisées.

Le mot valid ne doit pourtant pas devenir un verdict général. RPKI ne montre pas le chemin complet, ne garantit pas que tous les réseaux appliquent le rejet des routes invalides et ne mesure pas la qualité du service. Une route validement autorisée peut subir congestion, perte, mauvaise ingénierie, coupure physique, erreur DNS ou panne applicative. Elle peut aussi être conforme au ROA tout en ne correspondant pas à l’intention commerciale d’un client si les dossiers n’ont pas été mis à jour.

Le coût d’exploitation comprend la création et la révision des ROA, le choix de l’origine et du maxLength, la coordination lors des migrations, la surveillance des validateurs et le retour arrière. Un changement d’origine d’urgence peut transformer une route visible en route invalide si l’autorisation n’est pas adaptée à temps. Une autorisation trop large augmente à l’inverse la surface permise. Le contrôle utile est une procédure synchronisée, pas la simple présence d’un voyant vert.

Les préfixes non portables renforcent cette exigence. L’opérateur de l’ASN n’est pas toujours l’autorité capable de modifier l’objet de ressource ou le ROA. Le détenteur enregistré, le client et Techno Asia doivent savoir qui agit, sous quel délai, avec quelle preuve et selon quel plan de sortie. Sans cette carte, une réparation de routage peut attendre une organisation qui ne participe pas à l’incident.

DNS, courrier et présence web : quatre plans de contrôle

Au moment de l’observation, technoasiabd.com pointait vers 103.210.56.130. Les serveurs faisant autorité utilisaient les noms de Cloudflare malcolm.ns.cloudflare.com et aleena.ns.cloudflare.com; l’échangeur de courrier pointait vers le domaine lui-même et la politique SPF autorisait 103.210.56.130 ainsi que 202.59.208.125.[23] Ces réponses distinguent le registrar et la délégation, l’autorité DNS, l’origine web, le transport du courrier et sa politique d’envoi.

La racine du site a renvoyé HTTP 200 avec un index de répertoire vide et une réponse de 482 octets lors de la capture.[21] Le fait est précis; l’explication ne l’est pas. Il peut s’agir d’une maintenance, d’un site minimal, d’un remplacement ou d’un choix de publication. Rien ne permet de sélectionner une cause. L’adresse du web ne fait d’ailleurs pas partie des six routes IPv4 gelées. Déduire une panne réseau de cette page vide serait donc incorrect.

Cette surface reste opérationnellement importante. Lors d’un incident, clients, pairs, chercheurs et signalants d’abus cherchent des informations publiques. Un site vide déplace l’effort vers APNIC, BTRC, ISPAB, PeeringDB, les courriels de rôle et les documents contractuels. Plus ces sources divergent, plus l’escalade prend du temps.

L’autorité DNS externalisée exige ses propres contrôles : propriété du compte, authentification forte, rôles, paiement, rotation des clés API, verrouillage du registrar, export de zone et procédure de reprise. Deux serveurs de noms sous le même fournisseur ne constituent pas nécessairement deux domaines de panne. Une erreur de compte ou de zone peut les affecter ensemble.

La messagerie doit également être testée comme service, pas seulement comme ensemble d’enregistrements. Le MX et le SPF ne prouvent ni réception, ni DKIM, ni DMARC, ni disponibilité des boîtes d’abus. Les contacts critiques doivent fonctionner hors de la panne qu’ils servent à signaler. Une procédure de récupération qui dépend exclusivement du domaine ou de la boîte indisponible est circulaire.

Documents réglementaires et associatifs : conserver la date

La liste BTRC intitulée comme liste des licences ISP divisionnelles au 23 décembre 2024 comprend M/s. Techno Asia Infotech à la ligne 123, avec une adresse à Dhaka et une référence de licence.[17] Les champs extraits affichent aussi des dates historiques de juin 2017. Ces éléments prouvent ce que le document daté enregistrait. Ils ne doivent pas être convertis silencieusement en affirmation de validité actuelle.

Le répertoire de l’ISP Association of Bangladesh mentionne Techno Asia Infotech Ltd., l’adhésion G-102 et une classification divisionnelle.[18] Un PDF public distinct de l’association relie une autre forme du nom à un identifiant de membre et à un rôle de direction.[19] Ces documents soutiennent l’identité sectorielle. Ils ne mesurent pas la performance, la conformité continue, la sécurité ou la satisfaction.

Les registres répondent à des questions différentes. BTRC traite de permissions et d’obligations réglementaires; ISPAB de l’appartenance associative; APNIC des ressources de numérotation et des contacts; PeeringDB de la découverte d’interconnexion; DNS des contrôles de noms. Leur accord sur un nom renforce l’identification, mais ne transforme pas ces sources en audit de service.

Une équipe de continuité devrait rapprocher nom, adresse, numéro de licence, ASN, ressources, domaine et contacts, tout en conservant la date de chaque source. Une divergence n’est pas nécessairement une panne. Une divergence sans propriétaire ni échéance augmente toutefois le coût de chaque incident et de chaque revue fournisseur.

Capacité observable, fiabilité et résultat client

Les preuves soutiennent une affirmation de capacité observable : Techno Asia est associée à un ASN actif, à des ressources portables, à des annonces IPv4 et IPv6 visibles, à des autorisations RPKI valides pour les six routes IPv4 examinées, à des contrôles DNS et à des inscriptions sectorielles datées.[3]-[23] Ce constat est plus solide qu’une formule commerciale, mais il reste limité à la surface publique.

La fiabilité du produit demanderait des séries temporelles et un périmètre : disponibilité externe, latence, perte, congestion, stabilité de route, succès des changements, délais de restauration, capacité disponible, incidents et tests de bascule. Les sources gelées ne fournissent pas cet ensemble. Une visibilité de 328/328 au moment d’une requête n’est pas un SLA.

Le résultat de production d’un client demanderait une charge identifiée, une période, une base de comparaison, un objectif métier et l’accord du client. La connectivité peut être disponible alors qu’un pare-feu local, un DNS, une application ou un fournisseur cloud empêche l’usage. À l’inverse, une procédure manuelle peut préserver l’activité pendant un incident réseau. Aucun résultat client nommé ne figure dans le corpus.

La page APNIC Labs place AS135037 dans un contexte de mesure au Bangladesh.[22] Une estimation issue d’une méthode de mesure ne doit pas devenir un nombre d’abonnés, un revenu, une part de marché ou une note de satisfaction. Le vocabulaire de la source doit être conservé.

Il n’existe pas non plus de preuve publique d’un modèle d’intelligence artificielle propre à l’entreprise. L’automatisation pourrait participer à la gestion d’un réseau, mais cette possibilité n’est pas un fait sur Techno Asia. Même lorsqu’elle existe, l’automatisation ne supprime pas l’approbation, la gestion des secrets, la validation, le retour arrière et le traitement des cas exceptionnels.

Les quatre blocs de coût opérationnel

Supervision

La supervision maintient l’accord entre l’état attendu et l’état observé. Elle couvre les objets APNIC, contacts d’abus, allocations, annonces, ROA, filtres, adjacences, DNS, courrier, certificats, dossiers réglementaires et informations publiques. Chaque signal doit avoir un propriétaire, une cadence et un seuil d’escalade. Un score composite ne doit pas masquer quel plan de contrôle a dérivé.

Intégration

Ajouter ou retirer un préfixe implique davantage qu’une commande BGP. Il faut vérifier l’autorité sur la ressource, adapter ROA et filtres, déployer la politique, contrôler IPv4 et IPv6, mettre à jour surveillance et DNS, coordonner le client et conserver la preuve d’acceptation. Un changement peut réussir chez Techno Asia et rester incomplet chez le détenteur de la ressource. Les reprises doivent être idempotentes et les états ambigus réconciliés.

Maintenance

La maintenance couvre logiciels et configurations réseau, certificats, comptes, authentification forte, clés API, sauvegardes, documents, filtres, ROA, DNS et boîtes de rôle. Elle comprend aussi la preuve : configurations approuvées, résultats de tests, chronologies d’incident et vérification des contacts. Sans historique, chaque désaccord devient une reconstruction coûteuse.

Traitement des exceptions

Les exceptions révèlent le vrai modèle de responsabilité. Une route peut devenir invalide après un changement d’origine, un client peut maintenir un ROA obsolète, une adjacence IPv6 peut disparaître, le compte DNS peut être inaccessible ou un dossier public peut contredire les documents internes. Chaque cas exige classification, autorité, confinement, communication, vérification et nettoyage. Le coût inclut les exercices, l’accès hors bande, la capacité de secours, l’escalade fournisseur et la revue juridique.

Modes de défaillance à tester explicitement

  1. Contact de registre obsolète : l’objet reste actif mais la boîte de rôle ne répond plus. Il faut un test périodique et un propriétaire de correction.
  2. Écart entre allocation et annonce : une ressource d’un tiers est originaire de l’AS135037 sans dossier d’autorisation disponible. Il faut relier détenteur, contrat, ROA et procédure de sortie.
  3. ROA incompatible : une migration ou un préfixe plus spécifique dépasse l’origine ou le maxLength autorisé. Le contrôle compare intention, BGP et validateurs avant et après le changement.
  4. Changement d’adjacence non documenté : le graphe public change sans que capacité et escalade soient réévaluées. L’équipe doit distinguer observation, relation commerciale et diversité physique.
  5. Parité IPv6 incomplète : l’annonce existe mais la surveillance, le DNS ou l’application ne suivent pas. Les tests doivent traverser le service de bout en bout.
  6. Perte d’autorité DNS : les enregistrements sont corrects, mais les identifiants du registrar ou du fournisseur DNS sont indisponibles. Un accès secondaire et un export approuvé sont nécessaires.
  7. Information publique vide ou périmée : la page web ou un annuaire ralentit l’escalade. La correction est une petite surface publique maintenue, pas une promesse marketing.
  8. Document réglementaire mal daté : une ancienne liste est présentée comme autorisation actuelle. Le contrôle exige le document primaire courant et conserve la date de consultation.
  9. Mesure transformée en résultat commercial : une estimation APNIC Labs devient un nombre de clients. La revue éditoriale doit préserver la méthode et l’incertitude.
  10. Handoff incomplet : réseau, DNS, sécurité, juridique et client terminent leurs tâches sans contrôle de bout en bout. Une porte de sortie doit vérifier routage, RPKI, DNS, monitoring, acceptation et retour arrière.
  11. Automatisation trop privilégiée : un outil propage une hypothèse incorrecte à plusieurs surfaces. Les actions sensibles nécessitent approbation, déploiement progressif et journal réversible.
  12. Portabilité non testée : domaine, ressources, autorisations et historique deviennent impossibles à séparer pendant un litige ou une panne. La sortie doit être répétée avant l’urgence.

Diligence, portabilité et conclusion bornée

Un acheteur devrait demander l’identité contractuelle exacte, les services couverts, les ressources utilisées, les détenteurs enregistrés, les origines prévues, les ROA, la politique de filtrage, la diversité IPv4/IPv6, les dépendances DNS, la méthode de mesure, le dernier test de bascule et la procédure d’incident. Les réponses doivent distinguer ce que Techno Asia contrôle, ce qu’un client contrôle et ce qui dépend d’un tiers.

La demande suivante concerne les preuves répétées : stabilité des routes, latence et perte par service, capacité, changements réussis et échoués, restauration, incidents et exercices. Les registres peuvent vérifier une identité et une autorisation. Ils ne remplacent pas ces mesures.

La portabilité doit couvrir préfixes, ROA, filtres, DNS, courrier, certificats, comptes, surveillance, contacts d’abus, configurations client et conservation des journaux. Une sortie techniquement possible peut rester impraticable si l’autorité ou la documentation appartient à une seule personne. Tester l’export et le transfert avant une crise réduit ce risque.

Le jugement défendable est précis. Techno Asia présente une surface de contrôle réseau réelle et inspectable. AS135037 est actif; les routes observées sont largement visibles; les six couples IPv4 examinés étaient RPKI-valides; les registres et annuaires datés fournissent des points de responsabilité. Ces éléments ne démontrent ni fiabilité continue ni réussite client. La valeur opérationnelle dépend de la constance avec laquelle l’entreprise supervise, intègre, maintient et répare les relations exposées par ces preuves.

Registre des sources

  1. Objet de société dans le répertoire BTW.
  2. Répertoire des membres APNIC.
  3. APNIC RDAP pour AS135037.
  4. APNIC RDAP pour ORG-TAIL1-AP.
  5. APNIC RDAP pour 103.206.228.0/23.
  6. APNIC RDAP pour 103.206.230.0/24.
  7. État de routage RIPE NCC.
  8. Préfixes annoncés, RIPE NCC.
  9. Voisins ASN observés, RIPE NCC.
  10. Cohérence routage-registre, RIPE NCC.
  11. Validation RPKI de 103.206.228.0/24.
  12. Validation RPKI de 103.206.229.0/24.
  13. Validation RPKI de 103.206.230.0/24.
  14. Validation RPKI de 103.251.244.0/24.
  15. Validation RPKI de 103.239.42.0/24.
  16. Validation RPKI de 220.247.129.0/24.
  17. Liste BTRC des licences ISP divisionnelles au 23 décembre 2024.
  18. Répertoire des membres ISPAB.
  19. Répertoire public PDF des membres ISPAB.
  20. Fiche PeeringDB pour AS135037.
  21. Racine web de Techno Asia.
  22. Mesure APNIC Labs pour le Bangladesh.
  23. Réponses DNS publiques pour technoasiabd.com, observées le 2 août 2026 pour A, NS, MX, TXT et SOA.

Note sur l’image : la photographie de panneaux et de baies réseau au LAAS-CNRS est due à Guillaume Paumier et publiée sur Wikimedia Commons sous licence CC BY 3.0. Elle fournit un contexte d’infrastructure générique; elle ne représente ni Techno Asia Infotech, ni AS135037, ni ses locaux, employés, routes, clients ou résultats.