Résumé

  • Les registres de domaine, les objets de registre Internet, les annonces BGP et les fiches PeeringDB décrivent des couches différentes de l’infrastructure ; aucune ne constitue à elle seule une preuve de contrôle opérationnel ou de disponibilité applicative.
  • Les instantanés actuels examinés dans cette enquête ne vérifient aucune valeur de réponse pour ces couches. Il faut donc distinguer l’absence de donnée vérifiée de l’absence de ressource ou de route.

Le problème de la chaîne de contrôle

Lorsqu’un service cloud devient difficile à joindre, les explications rapides confondent souvent plusieurs niveaux. Le domaine est-il enregistré ? Qui contrôle les serveurs de noms ? L’autonomous system est-il attribué à l’opérateur annoncé ? Des préfixes sont-ils effectivement visibles dans le routage ? Une fiche d’interconnexion décrit-elle une relation active ? Enfin, l’application répond-elle depuis plusieurs réseaux et plusieurs régions ?

Ces questions sont liées, mais elles ne sont pas interchangeables. Le domaine appartient à la couche de nommage. L’autonomous system appartient à la couche d’adressage et de routage. Un objet aut-num décrit des données de registre ou de politique déclarée. Une observation de préfixes décrit une mesure effectuée depuis une perspective donnée. PeeringDB rassemble principalement des informations déclarées par les participants. La disponibilité de l’application se situe encore plus loin dans la chaîne.

L’enjeu est important pour l’analyse d’un fournisseur cloud : une identité de marque peut être cohérente avec un domaine, un numéro de système autonome et une présence annoncée, sans que les sources publiques établissent qui contrôle chaque couche à un moment donné. À l’inverse, une réponse manquante dans un instantané ne prouve pas que la ressource n’existe pas. La bonne conclusion doit suivre la granularité de la preuve.

Ce que les sources de domaine ne permettent pas d’établir ici

L’instantané RDAP de Verisign pour genesiscloud.com ne vérifie actuellement aucune donnée d’enregistrement, de statut, de serveur de noms ou d’événement. Le résultat ne permet donc pas d’identifier, à partir de cette collecte, le titulaire actuel, le statut du domaine ou la chronologie des modifications. Le point RDAP consulté pour le domaine reste néanmoins la bonne couche documentaire pour rechercher ces éléments lorsqu’une réponse complète et datée est disponible.

Les deux requêtes Google Public DNS examinées avaient une fonction plus précise. La requête NS devait permettre de vérifier la délégation vers les serveurs faisant autorité. La requête SOA devait permettre d’examiner le serveur primaire, la boîte aux lettres responsable, le numéro de série, les temporisations et les métadonnées de réponse. Les instantanés disponibles ne vérifient aucune de ces valeurs. La réponse NS de Google Public DNS et la réponse SOA correspondante constituent donc des points de contrôle identifiés, mais pas des preuves positives ou négatives sur l’opérateur DNS actuel.

Cette distinction est centrale. Une délégation DNS est un mécanisme de contrôle potentiel : celui qui peut modifier la délégation ou la zone peut influencer la résolution du nom. Mais le simple fait de savoir qu’un domaine utilise un fournisseur DNS ne démontre pas qui peut modifier la configuration, quels contrôles internes s’appliquent, ni si l’application située derrière le nom répond correctement. Le DNS peut orienter un client vers une adresse sans garantir que cette adresse est joignable ou que le service est sain.

Trois objets différents autour de l’AS209045

La seconde partie de la chaîne concerne l’AS209045. Là encore, trois types d’information doivent rester séparés.

Le premier est l’enregistrement de l’autonomous system. L’instantané RDAP de la RIPE NCC ne vérifie pas l’identité du registre, le statut, les contacts, les remarques ou les dates d’événement associés à l’AS209045. La réponse RDAP de l’AS indique donc où chercher l’identité administrative et les événements, mais elle ne confirme pas ces champs dans la collecte actuelle.

Le deuxième est l’objet aut-num de la base RIPE. Cet objet peut contenir des attributs de politique de routage, des mainteneurs, la source de la donnée et des métadonnées de modification. L’instantané de la base RIPE pour l’objet aut-num ne vérifie aucune de ces informations. Même lorsqu’un objet est présent dans une base, sa présence ne suffit pas à prouver que la politique déclarée est appliquée partout ni que les sessions correspondantes sont actives.

Le troisième est l’observation des préfixes annoncés. L’instantané RIPEstat ne vérifie aucun préfixe IPv4 ou IPv6 actuellement observé, aucune fenêtre d’observation et aucune métadonnée d’état de l’API. La requête RIPEstat sur les préfixes annoncés doit donc être lue comme un instrument de mesure identifié, non comme une preuve d’absence de route. Une mesure de routage dépend du moment, de la requête et des points de collecte. Elle ne suffit pas à établir une propagation mondiale, une accessibilité de bout en bout ou la disponibilité du service.

Cette architecture de preuve explique pourquoi l’expression « le réseau appartient à l’entreprise » est trop vague. Un registre peut associer une ressource à une organisation. Un objet de politique peut déclarer des intentions de routage. Des collecteurs peuvent observer une annonce. Aucune de ces couches ne répond seule à la question opérationnelle : le trafic d’un client donné atteint-il aujourd’hui le bon service, par un chemin fonctionnel, depuis son réseau et sa région ?

PeeringDB : déclaration utile, preuve incomplète

PeeringDB est particulièrement utile pour cartographier les déclarations d’interconnexion : identité réseau, profils de trafic, politique, installations, points d’échange et sessions peuvent aider à comprendre comment un opérateur se présente à ses pairs. Mais ces informations ne démontrent pas nécessairement qu’une session BGP est active au moment de l’analyse, qu’un préfixe est effectivement propagé, qu’un accord contractuel est toujours en vigueur ou qu’une application est accessible.

L’instantané PeeringDB examiné ici ne vérifie aucune identité réseau auto-déclarée, aucun profil de trafic, aucune politique, aucune installation, aucun échange, aucune session ni date de mise à jour. La réponse PeeringDB associée à l’AS209045 identifie la source et la structure de contrôle à utiliser, mais n’autorise pas une conclusion actuelle sur les interconnexions de Genesis Cloud.

La différence entre « déclaré » et « observé » n’est pas une nuance académique. Une fiche peut rester inchangée après le retrait d’un équipement. Une session peut être configurée mais inactive. Un opérateur peut annoncer un préfixe depuis un point et rester inaccessible depuis un autre à cause d’un incident, d’un filtrage, d’une panne de transit ou d’un problème applicatif. À l’inverse, l’absence d’une fiche complète ne prouve pas qu’aucune interconnexion n’existe.

Pourquoi les couches doivent être synchronisées

Une évaluation du contrôle réseau devrait synchroniser au moins cinq familles d’indices :

  1. l’identité de l’organisation et du domaine ;
  2. la délégation DNS et les réponses de zone ;
  3. l’enregistrement de l’AS et l’objet de politique ;
  4. les annonces et chemins observés depuis plusieurs collecteurs ;
  5. la réponse applicative depuis plusieurs réseaux et régions.

Chaque famille répond à une question différente. L’identité donne un contexte administratif. Le DNS relie un nom à une configuration de résolution. Le registre Internet décrit une attribution ou une relation déclarée. Le routage montre une visibilité mesurée. Les tests applicatifs montrent si le service répond effectivement à l’utilisateur.

Une conclusion robuste doit également être datée. Les instantanés examinés dans cette enquête ont été collectés dans un contexte où la récupération HTTP en direct n’était pas disponible. Ils ne vérifient donc pas les valeurs actuelles des réponses. Le fait vérifiable est plus limité : les points de terminaison ont été identifiés, mais leur contenu courant n’a pas été confirmé. Toute formulation plus forte transformerait une lacune de collecte en affirmation sur le monde.

Ce que cette enquête permet malgré tout de conclure

L’enquête ne permet pas de conclure qui contrôle aujourd’hui le domaine, les serveurs de noms, l’AS209045, les routes ou les interconnexions de Genesis Cloud. Elle montre en revanche comment éviter une erreur fréquente : agréger des enregistrements de nature différente pour produire une impression de contrôle unifié.

La chaîne de preuve est conditionnelle. Une identité de marque peut orienter la recherche vers un domaine. La délégation peut orienter vers une infrastructure DNS. L’AS peut relier une organisation à une ressource de routage. L’observation de préfixes peut montrer une visibilité depuis certains points. PeeringDB peut fournir une déclaration sur les relations d’interconnexion. Mais seule la convergence temporelle de ces indices, complétée par des tests applicatifs, permettrait de discuter sérieusement de continuité opérationnelle.

Pour les clients cloud, la conséquence pratique est de ne pas traiter un seul registre comme un indicateur de disponibilité. Un audit de dépendance devrait conserver les dates d’observation, les perspectives de mesure, les résolveurs utilisés, les collecteurs de routage, les chemins et les résultats applicatifs. Il devrait aussi conserver les valeurs négatives avec leur portée exacte : « non vérifié dans cet instantané » n’est pas synonyme de « inexistant ».

Le résultat le plus honnête de cette collecte est donc une carte des questions restantes. Il faut récupérer des réponses publiques complètes et datées, comparer plusieurs observateurs de routage, vérifier les changements DNS, examiner les annonces effectives et tester l’application depuis les régions pertinentes. Sans cette synchronisation, les documents publics décrivent des couches séparées ; ils ne prouvent pas une capacité opérationnelle unique.

Conclusion : une limite de preuve, pas une preuve d’absence

Les registres publics sont indispensables pour étudier l’infrastructure cloud, mais leur valeur dépend de ce qu’ils mesurent réellement. RDAP et les bases de registre décrivent l’identité ou l’administration. Le DNS décrit la délégation et la résolution. RIPEstat décrit une observation de routage située dans le temps et l’espace. PeeringDB décrit des informations d’interconnexion déclarées. La disponibilité applicative exige encore une mesure distincte.

Dans le cas examiné ici, les instantanés actuels ne vérifient pas les valeurs nécessaires pour relier ces couches. Cette limite interdit les affirmations catégoriques sur le contrôle actuel de Genesis Cloud, sans démontrer pour autant l’absence d’un domaine, d’une route ou d’une interconnexion. La conclusion utile est méthodologique : pour comprendre la dépendance à un fournisseur cloud, il faut suivre la chaîne complète et conserver séparément chaque niveau de preuve.