Résumé

  • Le dossier de recherche ne contient pas les réponses actuelles des registres, résolveurs DNS, collecteurs BGP, services web ou bases de certificats examinés. Les résultats opérationnels doivent donc rester inconnus, et non être transformés en affirmations positives ou négatives.
  • Une démonstration solide devrait relier séparément l’enregistrement d’AS210328, les préfixes observés, l’adresse réellement utilisée par le domaine, l’origine BGP, la terminaison TLS, le comportement HTTP, l’application et un parcours client vérifiable.

Le problème n’est pas l’existence d’un nom, mais la chaîne entre les couches

Une identité réseau peut être réelle sans devenir une infrastructure observable. Un numéro de système autonome peut être enregistré dans une base de données sans annoncer de préfixe. Un domaine peut être délégué sans exposer un service web. Une page accessible peut être hébergée par un tiers. Et une interface web, même fonctionnelle, ne suffit pas à prouver qu’un fournisseur exploite lui-même la capacité de calcul, de stockage ou de réseau vendue à ses clients.

C’est cette chaîne que l’enquête devait examiner pour almazcloud.network et AS210328. Le dossier contient 30 sources publiques candidates couvrant les registres RIPE, les objets de routes, les données RIPEstat, plusieurs observateurs BGP indépendants, PeeringDB, l’enregistrement du domaine, les réponses DNS, les certificats, les scans web et des archives historiques. Mais la recherche exécutée n’a pas récupéré les réponses actuelles de ces points de contrôle.

Le paquet de faits classe donc comme inconnus le routage actuel, les préfixes actuels, la présence DNS, la correspondance entre les adresses du domaine et AS210328, l’activité récente des certificats, l’accessibilité web et l’existence d’un point d’accès cloud vérifiable.

Cette limite est déterminante. Une source sélectionnée n’est pas une observation. Une URL canonique indique où un fait pourrait être vérifié ; elle ne constitue pas, à elle seule, la preuve que ce fait existe. Le registre RDAP d’AS210328 et la recherche RIPE peuvent établir une identité administrative, un titulaire déclaré, des contacts ou des remarques si leurs réponses sont obtenues et lues. Ils ne démontrent pas automatiquement une activité BGP actuelle. Les objets route ou route6 peuvent exprimer une intention enregistrée sans prouver une annonce effective. Les données RIPEstat pourraient indiquer une visibilité actuelle ou historique, mais leurs valeurs n’ont pas été récupérées dans ce run.

Une identité administrative ne remplace pas une observation de routage

Le premier niveau de la chaîne est administratif. Le point de départ est le dossier RDAP d’AS210328, complété par la base RIPE et la recherche inverse des objets de route. Ces documents peuvent répondre à plusieurs questions distinctes : le numéro est-il toujours enregistré ? Sous quel nom ? Avec quelle organisation, quels mainteneurs, quels contacts ou quelle politique déclarée ? Des références à AlmazCloud ou à almazcloud.network établiraient une association administrative si elles apparaissaient dans les réponses réelles.

Cette association resterait toutefois limitée. Un nom identique dans un registre et sur un domaine ne prouve ni le contrôle actuel des deux ressources, ni leur exploitation conjointe. Des contacts peuvent être anciens, masqués ou gérés par un tiers. Une politique de routage déclarée n’est pas une table de routage observée. Un objet de route enregistré n’est pas un paquet annoncé sur Internet.

Le niveau suivant exige une observation indépendante. Les endpoints RIPEstat consacrés à la vue d’ensemble, aux préfixes annoncés, à l’état du routage, aux états BGP, aux voisins, à l’historique et aux mises à jour peuvent tester si AS210328 apparaît effectivement dans les données de collecte. BGP.Tools et le BGP Toolkit de Hurricane Electric offrent des points de comparaison différents. Une convergence entre plusieurs collecteurs, avec des horodatages et des préfixes identifiables, serait plus probante qu’une simple mention dans un registre.

Même une annonce confirmée ne suffirait pas à elle seule. Elle établirait une empreinte de routage, pas la fourniture d’un service cloud. Il faudrait déterminer quels préfixes sont annoncés, quelle est leur origine, quels voisins ou transitaires apparaissent, et si ces préfixes correspondent aux adresses effectivement utilisées par le domaine ou par d’autres endpoints de service. La présence d’AS210328 dans un chemin BGP ne doit pas être confondue avec le fait qu’il en soit l’origine du préfixe observé.

Le domaine ajoute une dépendance, pas une preuve de propriété d’infrastructure

Le domaine forme une deuxième chaîne technique. L’outil de recherche ICANN peut fournir le registrar, les statuts, les dates et les serveurs de noms. Les requêtes Google Public DNS pour les types A, AAAA, NS, MX, TXT et CAA peuvent ensuite montrer comment le domaine est délégué, quelles adresses ou chaînes d’alias sont publiées, quels services de messagerie apparaissent et quelles autorités de certification sont autorisées.

Ces signaux ont des significations différentes. Une réponse A peut relier le domaine à une adresse IPv4 à un moment donné ; une réponse AAAA peut faire de même pour IPv6. Une adresse située dans un préfixe actuellement annoncé par AS210328 renforcerait une liaison directe entre le domaine et le système autonome. Une adresse appartenant à un autre opérateur affaiblirait cette liaison directe, sans exclure une relation de back-end, un proxy inverse, un CDN ou un hébergeur tiers.

Les serveurs de noms peuvent appartenir à un fournisseur spécialisé. Les enregistrements MX peuvent pointer vers une plateforme de messagerie externe. Les enregistrements TXT peuvent révéler des dépendances SaaS, une validation de domaine ou une politique SPF, mais ils peuvent aussi rester après la fin d’une relation. Une politique CAA limite les autorités habilitées à émettre des certificats ; elle ne prouve pas qu’un certificat est actuellement déployé ni qu’un service répond.

La délégation DNS est donc un mécanisme de continuité à documenter, non une conclusion. Il faudrait comparer les résultats de Google Public DNS avec la chaîne DNS de RIPEstat et l’analyse DNSViz, en tenant compte des caches, des points de vue géographiques et des différences de résolution. Une chaîne DNS valide ne démontre encore ni une connexion TCP, ni une négociation TLS réussie, ni une application disponible.

TLS, web et historique : trois indices qui doivent rester séparés

Les sources de transparence des certificats, Cert Spotter, SSL Labs, urlscan, l’Internet Archive, Censys et Shodan peuvent apporter des éléments supplémentaires. Elles ne mesurent pas toutes la même chose. Un certificat récent peut indiquer qu’une autorité a émis un certificat pour le domaine ; il ne prouve pas que le certificat est installé sur un endpoint accessible, ni qu’un service commercial est exploité. Une analyse SSL peut décrire une configuration observée, mais seulement si l’analyse a effectivement été exécutée et son contenu lu.

Une capture urlscan ou une entrée dans une base de recherche peut montrer qu’un domaine a été vu par un instrument à un moment donné. Une archive peut établir une présence historique ou un changement de contenu. Censys et Shodan peuvent exposer des hôtes ou des ports observés par leurs propres sondes. Dans tous les cas, l’horodatage, le point de vue, l’adresse, le certificat et le contenu doivent être reliés avec prudence. Une observation historique ne devient pas une preuve de continuité actuelle.

Le mécanisme probant serait une séquence répétée : le domaine est résolu depuis plusieurs points de vue ; ses adresses sont identifiées ; ces adresses sont rattachées à des préfixes ; les préfixes sont observés avec une origine BGP cohérente ; le service accepte une connexion TLS correspondant au domaine ; la réponse HTTP expose une application stable ; puis l’application permet de suivre un parcours qui correspond à une offre cloud réelle. Chaque étape dépend potentiellement d’un opérateur différent. L’échec d’une étape ne permet pas de déduire automatiquement l’absence des autres.

Ce que l’on peut conclure maintenant

La conclusion défendable est étroite : le dossier identifie un ensemble de sources publiques capables de tester l’identité, le routage, le DNS, le web, les certificats et la présence historique d’almazcloud.network et d’AS210328, mais il ne contient pas les réponses actuelles nécessaires pour qualifier leur empreinte opérationnelle indépendante. Le lien entre le domaine et l’ASN n’est pas établi dans ce run. La présence de préfixes actuels, la visibilité BGP actuelle, la résolution DNS actuelle, la portée web, l’activité récente des certificats et les endpoints cloud sont également inconnues.

Cela ne prouve ni l’inactivité, ni l’absence de service, ni la fraude. Cela signifie que le seuil de preuve n’est pas atteint. Les couvertures antérieures ont déjà montré pourquoi l’enregistrement, la présence DNS et l’existence d’un site ne peuvent pas être agrégés en une seule affirmation sur un opérateur cloud. L’apport de cette enquête est de préciser le mécanisme manquant : il faut suivre la continuité d’une couche à l’autre et attribuer chaque lien séparément.

Pour les lecteurs qui surveillent ce dossier, les changements les plus informatifs seraient une annonce BGP confirmée par plusieurs collecteurs, une correspondance reproductible entre les adresses du domaine et les préfixes d’AS210328, une délégation DNS stable, un certificat et une réponse HTTP cohérents, puis des preuves d’un parcours client. Un seul signal positif serait utile, mais il ne suffirait pas à transformer une identité enregistrée en service cloud démontré. La continuité exige des observations répétées, horodatées et indépendantes.

Sources et méthode

Les points de contrôle canoniques retenus pour cette enquête sont les suivants : le dossier RDAP d’AS210328 https://rdap.db.ripe.net/autnum/210328, la recherche RIPE https://apps.db.ripe.net/db-web-ui/query?searchtext=AS210328, les objets de route inverse https://rest.db.ripe.net/search.json?query-string=AS210328&inverse-attribute=origin&type-filter=route&type-filter=route6&flags=no-filtering, la vue d’ensemble RIPEstat https://stat.ripe.net/data/as-overview/data.json?resource=AS210328, les préfixes annoncés https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS210328, l’état du routage https://stat.ripe.net/data/routing-status/data.json?resource=AS210328, l’état BGP https://stat.ripe.net/data/bgp-state/data.json?resource=AS210328, les voisins ASN https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS210328, l’historique du routage https://stat.ripe.net/data/routing-history/data.json?resource=AS210328 et les mises à jour BGP https://stat.ripe.net/data/bgp-updates/data.json?resource=AS210328.

Les comparaisons de routage comprennent BGP.Tools https://bgp.tools/as/210328, le BGP Toolkit de Hurricane Electric https://bgp.he.net/AS210328 et l’API PeeringDB https://www.peeringdb.com/api/net?asn=210328. Les sources relatives au domaine comprennent la recherche ICANN https://lookup.icann.org/en/lookup?name=almazcloud.network, les réponses A https://dns.google/resolve?name=almazcloud.network&type=A, AAAA https://dns.google/resolve?name=almazcloud.network&type=AAAA, NS https://dns.google/resolve?name=almazcloud.network&type=NS, MX https://dns.google/resolve?name=almazcloud.network&type=MX, TXT https://dns.google/resolve?name=almazcloud.network&type=TXT et CAA https://dns.google/resolve?name=almazcloud.network&type=CAA de Google Public DNS, ainsi que la chaîne DNS de RIPEstat https://stat.ripe.net/data/dns-chain/data.json?resource=almazcloud.network et DNSViz https://dnsviz.net/d/almazcloud.network/dnssec/.

Les points de contrôle web et historiques comprennent le site du domaine https://almazcloud.network/, Certificate Transparency via crt.sh https://crt.sh/?q=%25.almazcloud.network&output=json, Cert Spotter https://api.certspotter.com/v1/issuances?domain=almazcloud.network&include_subdomains=true&expand=dns_names&expand=issuer&match_wildcards=true, urlscan https://urlscan.io/api/v1/search/?q=domain%3Aalmazcloud.network, SSL Labs https://www.ssllabs.com/ssltest/analyze.html?d=almazcloud.network&hideResults=on, l’Internet Archive https://web.archive.org/cdx/search/cdx?url=almazcloud.network%2F*&output=json&filter=statuscode%3A200&collapse=digest, Censys https://search.censys.io/search?resource=hosts&q=almazcloud.network et Shodan https://www.shodan.io/domain/almazcloud.network. La fiche de répertoire associée est accessible ici : https://btw.media/fr/directory/almazcloud-network.

La recherche utilisée pour cet article n’a pas récupéré les réponses HTTP, DNS ou web actuelles. Les liens ci-dessus sont donc des points de vérification et non des observations actuelles. Les formulations de cet article conservent cette distinction.