HOSTING Eric Kelderman trading as Bodega ICT vend une capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de réparation

Résumé

• L'identité de registre public est réelle. L'aperçu AS de RIPEstat pour l'AS202019identifieBODEGA-HOSTING Eric Kelderman trading as Bodega ICT, et l'objet aut-numAS202019 dans la base de données RIPElisteBODEGA-HOSTING, l'organisation ORG-BH128-RIPE, l'organisation sponsor ORG-ABTA6-RIPE, la politique d'import/export avec AS44854 et AS56393, et une création le 23 janvier 2026.
• L'enregistrement de l'organisation est également précis. Une recherche dans la base de données RIPE pourBodega ICTrenvoie ORG-BH128-RIPE, avec le nom d'organisationEric Kelderman trading as Bodega ICT, adresseSakuralaan 13, Almere, pays NL, e-mail[email protected], contact abuse ACRO63211-RIPE et dernière modification le 13 mai 2026.
• Le routage public actuel est absent. L'état de routage RIPEstat pour l'AS202019n'affiche aucune annonce IPv4 ou IPv6 visible ni aucun voisin observé le 12 juillet 2026; lespréfixes annoncés par RIPEstatrenvoient zéro préfixe actuel. Il montre une visibilité IPv4 historique, avec une première apparition du 185.39.216.0/22 en 2015 et une dernière apparition du 95.181.220.0/22 en 2022, avant l'état actuel de l'objet de registre de 2026.
• Le seul objet de politique de routage actuel dans la vue de cohérence RIPEstat n'est pas actif.La cohérence de routage RIPEstat pour AS202019liste 2001:678:11b0::/48 comme présent dans le whois mais pas dans BGP, et liste la politique d'import/export AS44854 et AS56393 comme présente dans le whois mais pas dans BGP.
• La note de preuve est Négative pour l'exploitation réseau actuelle. Bodega ICT a une identité de registre réelle, mais aucune visibilité publique des routes de l'AS202019 actuelle, aucun préfixe client actuel visible, aucune observation de voisin actif, aucun site produit résolvant sur ses domaines d'identité probables, et aucune preuve publique d'installation, de support, de baie, de sauvegarde ou de migration qui soutiendrait le traitement comme une capacité hébergée opérationnelle.

Le nom dit hébergement, la table de routage dit pas encore

La manière utile de lire HOSTING Eric Kelderman trading as Bodega ICT est de séparer l'identité de l'opération. La couche d'identité est claire. Les enregistrements RIPE associent l'AS202019 avec BODEGA-HOSTING et avec Eric Kelderman trading as Bodega ICT aux Pays-Bas. L'enregistrement est récent. Il possède une structure de sponsor et de mainteneur. Il a une organisation et une adresse nommées. Il a une politique d'import et d'export. Il a un préfixe IPv6 enregistré dans le whois. Ces détails suffisent à rendre l'entité digne d'être suivie dans un répertoire d'infrastructure.

La couche opérationnelle est bien plus faible. RIPEstat ne voit l'AS202019 rien annoncer le 12 juillet 2026. Il ne voit pas de préfixe IPv4. Il ne voit pas de préfixe IPv6. Il ne voit pas de voisin. La vue des préfixes annoncés est vide. La vue de cohérence voit un /48 IPv6 dans le whois mais pas dans BGP. Cette combinaison n'est pas un réseau d'hébergement en direct dans la table de routage publique. C'est une empreinte de registre et de politique qui peut se préparer au service, préserver une identité ou attendre une activation.

Cette distinction est importante car les défaillances d'infrastructure sont réparées dans la couche opérationnelle, pas dans la couche de nommage. Un objet de registre peut lister un AS, mais une panne client dépend des sessions de routage, des ports amont, de l'accès aux routeurs, de l'alimentation, des baies, des serveurs, du support et des contrats. Si l'AS n'est pas visible, un client ne peut pas compter sur lui pour la connectivité. Si les domaines visibles sont hébergés ailleurs, la surface web publique ne prouve pas que Bodega ICT exploite une infrastructure client derrière l'AS202019.

La tentation dans un programme de couverture d'entreprises est de traiter chaque détenteur d'AS comme un fournisseur opérationnel. Cela exagèrerait ce cas. Bodega ICT peut devenir un réseau actif. Il peut avoir des clients privés ou une infrastructure non publique. Il peut utiliser un hébergement tiers tout en préparant son propre AS. Mais les preuves publiques disponibles actuellement ne permettent pas d'affirmer que l'AS202019 transporte une capacité hébergée de production.

La bonne conclusion est donc étroite: Bodega ICT a une identité de ressources numériques RIPE récente, mais l'Internet public ne montre actuellement pas cette identité fournissant un service routé. Les acheteurs devraient demander des preuves de route actuelles, des conditions de service et une preuve d'installation avant de traiter le nom comme un fournisseur d'hébergement opérationnel.

RIPE identifie l'entité, mais pas une plateforme opérationnelle

Lesdonnées whois de RIPEstat pour l'AS202019listent l'aut-num 202019, nom ASBODEGA-HOSTING, organisation ORG-BH128-RIPE, organisation sponsor ORG-ABTA6-RIPE, import depuis AS44854, export vers AS44854, import depuis AS56393, export vers AS56393, contacts admin et techniqueeric800etERIC800, statut ASSIGNED, et création le 23 janvier 2026. L'objetaut-num dans la base de données RIPEmontre la même structure.

Lerésultat de recherche RIPE pour Bodega ICTfournit l'enregistrement de l'organisation. Il nommeEric Kelderman trading as Bodega ICT, donne l'adresse Sakuralaan 13, Almere, pays NL, e-mail[email protected], contact abuse ACRO63211-RIPE, mainteneurnl-eritap-1-MNT, création le 20 janvier 2026 et dernière modification le 13 mai 2026. Ce n'est pas une entrée d'annuaire secondaire vague. C'est l'objet officiel de la base de données RIPE qui ancre l'identité des ressources numériques de l'entité.

Les objets de politique suggèrent des fournisseurs amont prévus. AS44854 et AS56393 sont listés dans la politique d'import et d'export.La vue de cohérence de routage RIPEstat pour AS202019liste ces pairs comme présents dans la politique whois mais pas dans BGP. C'est un signal utile d'état planifié. Ce n'est pas une preuve de connectivité opérationnelle au moment du contrôle. La politique peut exister avant que les circuits ne soient activés, après leur retrait, ou pendant que les sessions sont trop limitées pour apparaître dans la vue du collecteur public.

La même vue de cohérence liste 2001:678:11b0::/48 comme présent dans le whois mais pas dans BGP. En d'autres termes, il existe au moins un objet route IPv6 ou une allocation dans les données du registre, mais il n'est pas visible en tant que route annoncée par l'AS202019 dans la vue RIPEstat. Pour un client, la question pratique est de savoir si l'IPv6 est actif, planifié, inutilisé ou attribué uniquement pour un service futur. La réponse publique le 12 juillet 2026 est: pas visiblement routé.

Les données historiques de RIPEstat apportent une nuance. La vue d'état de routage indique que l'AS202019 a été vu pour la première fois avec 185.39.216.0/22 en 2015 et pour la dernière fois avec 95.181.220.0/22 en 2022. L'objet aut-num RIPE actuel a cependant été créé en janvier 2026. Les numéros d'AS peuvent être réattribués, réutilisés, sponsorisés différemment ou réenregistrés au fil du temps. Cela signifie que la visibilité historique des préfixes ne doit pas être considérée comme une preuve que l'entité Bodega ICT actuelle transporte ces anciennes routes.

Le contrôle opérationnel actuel doit se concentrer sur la visibilité présente, et cette visibilité est vide.

Les domaines pointent vers un hébergement tiers, pas vers l'AS202019

Les preuves de domaine renforcent la note opérationnelle faible. Le domainebodega.nlrésout, mais la page web est un espace réservé d'hébergement par défaut: « Welcome to the home of bodega.nl » et « To change this page, upload your website into the public_html directory », avec une date de création affichée sur la page. Les chemins tels que/hosting,/contact,/dienstenet/ictont renvoyé des réponses 404 lors des vérifications locales. Ce n'est pas un site produit opérationnel pour un fournisseur d'hébergement. C'est une page hébergée par défaut.

Le DNS pourbodega.nlpointe vers une infrastructure d'hébergement tierce. L'enregistrement A dans les vérifications locales était 185.104.29.66, l'enregistrement AAAA était 2a06:2ec0:1::111, les serveurs de noms étaientns.zxcs.eu,ns.zxcs.beetns.zxcs.nl, et la cible MX étaitmail.bodega.nl. L'enregistrement SPF incluait la plage 185.104.29.0/24, l'adresse 185.104.29.66, l'adresse web IPv6 et le filtrage de messagerie ZXCS. Ces preuves indiquent une infrastructure d'hébergement partagé de type ZXCS, et non une plateforme client visible sur l'AS202019.

Le domaine d'identité probablebodegaict.nlpointe également loin de l'AS202019. Les vérifications DNS locales ont montré un enregistrement A 2.57.91.91, un enregistrement AAAA 2a02:4780:84::32, des serveurs de nomsns1.dns-parking.cometns2.dns-parking.com, des enregistrements MX Google, et des inclusions SPF pour la messagerie Hostinger et Google. C'est un modèle courant de domaine garé ou hébergé par un tiers. Cela soutient l'existence d'une surface d'identité et de messagerie. Cela ne soutient pas l'affirmation que Bodega ICT héberge son propre site public ou les services clients sur son AS attribué.

Les variantes inactivesbodega-ict.nln'ont pas fourni de surface de site plus solide lors des vérifications DNS locales. Cela est important car le site web d'un petit fournisseur est souvent la première preuve publique des conditions de service, du contact de support, du menu produit, de la politique d'utilisation acceptable, du SLA, de la page d'état, du portail de tickets et du langage de migration client. Ici, les preuves de domaine public donnent des indices d'identité et d'hébergement tiers, mais pas une offre de capacité hébergée.

Cela ne signifie pas que Bodega ICT n'a pas de clients. De nombreux petits opérateurs servent des clients par référence, contrat direct, portail privé ou arrangement de revendeur. Certains gardent leur site public minimal tout en exploitant une infrastructure réelle. Mais une couverture publique ne peut pas présumer cela. Si le site visible est un espace réservé et que l'AS attribué n'annonce pas, la conclusion éditoriale doit être prudente.

Ce qui serait nécessaire pour une capacité hébergée

Pour que Bodega ICT soit un fournisseur de capacité hébergée opérationnelle au sens pertinent pour cette série de couverture, plusieurs éléments devraient être prouvés. Premièrement, l'AS202019 ou un autre AS clairement identifié devrait annoncer des préfixes pertinents pour le client. Deuxièmement, le fournisseur devrait montrer où les serveurs, le stockage ou l'infrastructure virtuelle fonctionnent réellement. Troisièmement, les clients auraient besoin de conditions de support, de sauvegarde, de facturation et de migration.

Quatrièmement, un acheteur devrait savoir si Bodega ICT contrôle la couche physique ou ne fait que revendre un service d'un autre hébergeur.

Les preuves publiques actuelles ne satisfont pas ces tests. L'AS202019 n'a pas de préfixes visibles. Les domaines Bodega utilisent des surfaces d'hébergement tierces. Les pages web publiques examinées ne décrivent pas les niveaux de produit, les emplacements des centres de données, les canaux de support, les conditions, l'historique d'état, les sauvegardes ou les droits d'exportation client. Les enregistrements du registre RIPE ne nomment pas d'installation. La vue de cohérence ne montre pas de sessions amont actives.

PeeringDB et les répertoires de routes publics ne fournissent pas de profil d'installation ou de peering qui puisse combler le vide.

Cela laisse une distinction étroite mais importante. Un AS dormant ou en préparation peut encore être une preuve utile pour la surveillance future, car il indique aux observateurs quelle ressource vérifier si un lancement de service apparaît. Il n'est pas utile comme preuve de dépendance client actuelle. Un client achetant de l'hébergement aujourd'hui a besoin d'une adresse qui route, d'un canal de support qui fonctionne, d'une installation ou d'une frontière fournisseur, et d'une réponse écrite sur ce qui arrive lorsque l'équipement, le transit, le DNS, la facturation ou la sauvegarde échouent.

L'objet RIPE peut aider à identifier l'interlocuteur. Il ne peut pas répondre seul aux questions opérationnelles.

Le moment est également important. Si l'AS202019 devient visible demain, une seule capture de route serait encore une preuve précoce, pas une preuve de maturité. Le client aurait besoin d'observations de route répétées, d'une liste de préfixes stable, d'une validation d'origine de route le cas échéant, d'une cohérence des voisins amont, d'une documentation de service et d'un test de restauration ou d'exportation hors production. Cette période d'attente n'est pas bureaucratique. Elle empêche que le premier client de production ne devienne la preuve que le fournisseur aurait dû rassembler avant de vendre une capacité critique.

La même norme devrait s'appliquer aux domaines. Une page publique fonctionnelle n'est pas requise pour chaque service d'infrastructure privée, mais un client critique a toujours besoin d'une adresse de support, d'un chemin d'abus, d'un chemin de facturation, d'un canal d'état et d'un chemin de retour des données qui ne dépendent pas de conjectures. Les preuves de domaine d'espace réservé et de domaine garé peuvent coexister avec un service privé sérieux; cela signifie simplement que le dossier de diligence raisonnable privé doit avoir plus de poids.

Les dépendances physiques restent les mêmes que pour tout service d'hébergement. Un serveur doit se trouver dans une pièce. La pièce a besoin d'électricité et de refroidissement. Le routeur a besoin d'une connectivité amont. Quelqu'un doit avoir accès à la baie. Quelqu'un doit remplacer le matériel défaillant. Quelqu'un doit répondre aux signalements d'abus. Quelqu'un doit préserver les données client pendant les litiges de facturation ou les événements de suspension. Si Bodega ICT vend de l'hébergement privé, ces responsabilités existent même si elles ne sont pas visibles.

Si elle ne fait que préparer une identité réseau, ces responsabilités peuvent ne pas encore exister.

L'absence de visibilité de route publique est particulièrement importante pour l'analyse des pannes. S'il n'y a pas de route AS202019 publique, un client ne peut pas surveiller l'AS202019 pour la connectivité. Si un domaine Bodega est hébergé sur une infrastructure de type ZXCS ou Hostinger, les incidents impliquant ce domaine peuvent être des incidents de l'hébergeur tiers, pas du réseau propre de Bodega. Si les futurs services client migrent vers l'AS202019, les clients auront besoin d'un examen actualisé des fournisseurs amont, de la validation d'origine de route, de la propriété des préfixes, du support et du basculement.

Les acheteurs devraient donc poser des questions simples avant de s'engager dans tout service hébergé sous le nom Bodega ICT. Quel AS transporte le service? Quels préfixes sont destinés aux clients? Quelle installation héberge l'équipement? Qui possède le matériel? Qui contrôle les sessions amont? Existe-t-il des ROA actuels? Les sauvegardes sont-elles testées? Comment les données sont-elles exportées? Que se passe-t-il si le fournisseur suspend le service? Le registre public ne répond pas à ces questions actuellement.

La politique de routage sans sessions actives n'est pas de la résilience

L'objet aut-num AS202019 liste AS44854 et AS56393 comme pairs de politique. Cela n'est utile qu'en tant que chemin prévu ou documenté. Ce n'est pas une preuve de résilience. RIPEstat a vu les deux dans la politique whois et aucun dans BGP pour AS202019 au moment de la requête. Un fournisseur peut garder des lignes de politique prêtes avant d'activer un circuit. Il peut conserver la politique après le retrait d'une route. Il peut prévoir d'utiliser ces fournisseurs amont plus tard. Aucun de ces cas ne donne au client une connectivité actuelle.

C'est pourquoi « deux numéros AS nommés dans le registre » ne doivent pas être décrits comme du multi-homing. Le multi-homing signifie une capacité en direct ou testée de continuer le service via plus d'un fournisseur amont. Cela nécessite des circuits, une configuration de routeur, des filtres amont, une autorisation d'origine de route, de la capacité et des procédures opérationnelles. Une ligne de politique statique ne peut pas transporter de trafic. Elle ne peut pas absorber une panne. Elle ne peut pas prouver qu'une baie a un deuxième chemin.

Le même principe s'applique au /48 IPv6. La présence de 2001:678:11b0::/48 dans le whois indique une préparation ou une allocation. Cela ne montre pas que les services client peuvent utiliser IPv6. Cela ne montre pas que le DNS, le DNS inverse, les pare-feu, la surveillance et le support client sont prêts pour les incidents IPv6. Si un fournisseur vend de l'IPv6, les clients devraient le tester depuis plusieurs réseaux et l'exiger dans les conditions de service.

La validation d'origine de route ne pourrait pas améliorer la note de preuve. Sans route visible dans BGP, la question pratique n'est pas de savoir si une route actuelle est valide ou invalide. La question pratique est de savoir si le fournisseur a une route tout court. Si l'AS202019 commence à annoncer le /48 ou un nouveau préfixe IPv4, les contrôles RPKI et de politique de routage devront être répétés à ce moment-là. La réponse actuelle est que les collecteurs publics ne voient pas de surface de service AS202019 active.

C'est le bon endroit pour être strict. Une entreprise d'hébergement dépend de la connectivité. Si la connectivité est absente de la table de routage publique, alors l'article ne doit pas noter le réseau comme moyen ou fort simplement parce que l'objet de registre est propre. L'objet de registre est un document de départ. La table de routage est la preuve opérationnelle. Ici, la preuve opérationnelle est négative.

Le risque client est principalement un risque d'incertitude

Le principal risque autour de Bodega ICT n'est pas que les preuves publiques montrent un mauvais réseau. C'est que les preuves publiques ne montrent pas de réseau actuel. Cela change la façon dont un client devrait penser au nom. Il se peut qu'il n'y ait pas de service d'hébergement client à acheter sous AS202019 aujourd'hui. Il se peut qu'il y ait un service privé non visible des collecteurs publics. Il se peut qu'il y ait un réseau en phase de démarrage qui deviendra actif plus tard. Chaque possibilité a des implications différentes.

Si le service n'est pas encore opérationnel, la diligence raisonnable correcte est la préparation au lancement: propriété des préfixes, activation des fournisseurs amont, autorisation d'origine de route, contacts de support, communications d'incident, conditions de facturation et conception de sauvegarde. Si le service est privé, la diligence raisonnable correcte est une preuve spécifique au client: une route de test, un traceroute, un contrat, une déclaration d'installation, un exercice de restauration et une procédure de sortie.

Si le service est une revente tierce, la diligence raisonnable correcte est la frontière du fournisseur: quel hébergeur, quel centre de données, quel compte, quel droit au support et qui préserve les données si la relation prend fin.

Les domaines rendent l'incertitude plus visible.bodega.nlétant une page d'espace réservé signifie qu'un client potentiel ne peut pas y inspecter les conditions du produit.bodegaict.nlutilisant le parking DNS et la messagerie Google/Hostinger signale une surface d'identité, mais pas une plateforme d'infrastructure. Il n'y a pas de portail de tickets public, de page d'état, de SLA de support, de catalogue de produits ou de guide de migration dans les pages vérifiées pour cet article. Sans cela, le client ne peut pas dire si le fournisseur est un opérateur pratique, un petit cabinet de conseil, un revendeur, une identité dormante ou un réseau en préparation.

Cette incertitude ne doit pas être comblée par des suppositions. Le rôle de l'article est d'identifier ce que les preuves publiques soutiennent. Elles soutiennent une identité RIPE nouvellement visible pour Bodega ICT et un AS actuellement non annoncé. Elles soutiennent des surfaces de domaine hébergées par des tiers. Elles ne soutiennent aucune route client AS202019 publique actuelle. Cela suffit pour une note de recherche liée à un répertoire, mais pas pour une notation d'infrastructure positive.

L'hébergement de domaine est une preuve de dépendance, pas une preuve de capacité

La preuve de domaine mérite son propre traitement car il est facile de mal l'interpréter. Un fournisseur peut gérer une entreprise d'infrastructure sérieuse tout en utilisant des fournisseurs externes pour son propre site web public, sa messagerie et son DNS. Ce n'est pas automatiquement faible. Un petit opérateur de réseau pourrait délibérément héberger son site public en dehors de son propre AS afin que les clients puissent toujours accéder aux avis de support pendant une panne.

Il pourrait utiliser la messagerie Google ou une autre pile de messagerie SaaS parce que la fiabilité de la messagerie est un problème opérationnel différent de l'hébergement de serveurs clients. Il pourrait garer un domaine pendant un changement de marque ou avant un lancement complet de service.

Le problème dans ce cas n'est pas que l'hébergement externe existe. Le problème est que l'hébergement externe est la seule surface publique visible. La page d'espace réservébodega.nl, les serveurs de noms ZXCS vus dans les vérifications DNS locales et les références SPF au filtrage ZXCS montrent un domaine qui est vivant mais ne fonctionne pas comme une vitrine d'hébergement public. Le modèle DNS debodegaict.nl, avec des serveurs de noms de parking DNS, des enregistrements MX Google et des inclusions SPF Hostinger/Google, montre un domaine d'identité et une configuration de messagerie plutôt qu'une plateforme auto-exploitée. Ce sont des indices utiles, mais ils ne répondent pas aux questions de service qu'un client poserait.

Cela est important car les surfaces de domaine public sont l'endroit où les petits fournisseurs publient généralement les contrôles qui rendent leur infrastructure intelligible: descriptions de produits, conditions, fenêtres de support, règles d'abus, politiques de sauvegarde, pages d'état et langage de migration. Si ceux-ci sont absents, le client doit les collecter en privé.

Un acheteur devrait demander si le domaine public d'espace réservé est intentionnellement inutilisé, si un autre domaine de service existe, si un portail client est privé, et si la communication de support dépend des mêmes fournisseurs externes utilisés pour les domaines publics.

Les liens DNS publics créent également une frontière de surveillance. Sibodega.nlest en panne, la panne peut impliquer l'hébergeur tiers derrière 185.104.29.66 ou la configuration DNS du domaine, pas AS202019. Si la messageriebodegaict.nlest retardée, le problème peut impliquer le routage de messagerie Google, l'autorisation de messagerie Hostinger ou le parking DNS plutôt qu'un réseau exploité par Bodega. Inversement, si AS202019 devient actif plus tard, un client pourrait voir des problèmes de route AS202019 alors que le site web public reste joignable via un hébergement externe. Un plan d'incident approprié doit séparer ces surfaces.

La demande de diligence raisonnable propre est donc une carte des responsabilités. Quels domaines sont pour le marketing public? Quels domaines sont pour le support? Quels domaines sont des panneaux de contrôle client? Quelles parties sont hébergées par des tiers? Quelles parties, le cas échéant, fonctionnent sur AS202019? Quel fournisseur est responsable de la livraison de la messagerie? Quel canal de contact survit si la route propre du fournisseur est en panne? Sans ces réponses, la disponibilité du domaine ne prouve pas la capacité d'infrastructure client.

Comment retester AS202019 s'il passe en ligne

La note devrait changer si l'image de routage publique change. Le premier retest est simple: vérifier lespréfixes annoncés par RIPEstat pour AS202019et l'état de routage RIPEstat pour AS202019. Si l'un ou l'autre commence à montrer des préfixes actuels, enregistrer la liste des préfixes, l'heure de première apparition, le nombre d'adresses visibles, le statut IPv4 par rapport à IPv6 et le nombre de pairs RIS voyant la route. Cela établit si l'AS est passé de l'état de registre à l'état opérationnel.

Le deuxième retest est la diversité amont. Vérifierles voisins ASN RIPEstat pour AS202019et comparer avec lacohérence de routage RIPEstat pour AS202019. Si AS44854 et AS56393 restent dans le whois mais qu'un seul ou aucun n'apparaît dans BGP, la preuve publique ne prouve toujours pas le multi-homing. Si les deux apparaissent dans BGP, la question suivante est la diversité physique: si les deux chemins entrent dans la même installation, dépendent du même sponsor, utilisent le même tissu d'échange ou partagent la même relation commerciale.

Le troisième retest est la sécurité de routage. Si 2001:678:11b0::/48 devient visible, vérifier lavalidation d'origine de route RIPEstat pour AS202019 et 2001:678:11b0::/48. Si un nouveau préfixe IPv4 apparaît, vérifier ce préfixe séparément. Un état RPKI valide ne prouverait pas les baies ou les sauvegardes, mais cela améliorerait l'assurance de routage. Inconnu serait une lacune d'hygiène. Invalide serait une préoccupation opérationnelle importante.

Le quatrième retest est l'alignement du registre. Comparer les préfixes en direct avec l'objetbase de données RIPE AS202019, l'enregistrement d'organisation RIPE pour Bodega ICT, et l'enregistrement RIPE pour 2001:678:11b0::/48. Le but n'est pas de punir les petites incohérences. Il est de comprendre si la route annoncée est liée à la même organisation, au même sponsor et aux mêmes contacts sur lesquels les clients s'appuieraient pendant les incidents.

Le cinquième retest est l'alignement du service public. Si l'AS passe en ligne mais quebodega.nlreste un espace réservé et quebodegaict.nlreste garé ou hébergé par un tiers, la route prouverait une activité réseau mais ne prouverait toujours pas une offre de service d'hébergement. Les clients auraient toujours besoin d'une page produit, d'un contrat, d'un chemin de support et d'un plan de migration. Si un nouveau site produit apparaît, ses affirmations devraient être confrontées aux données de routage plutôt qu'acceptées seules.

Ce qui changerait la note

Le moyen le plus rapide pour Bodega ICT d'améliorer la note de preuve publique serait d'annoncer un préfixe pertinent pour le client depuis AS202019 et de le garder visible dans le temps. Un seul préfixe visible ne prouverait pas la résilience, mais cela ferait passer le cas d'une empreinte de registre uniquement à une empreinte de réseau opérationnel. Si le 2001:678:11b0::/48 est censé être actif, un BGP visible, un DNS inverse, une validation d'origine de route et une documentation de service aideraient.

Une page de service public changerait également la note. Elle devrait dire si Bodega ICT vend de l'hébergement web, des VPS, des serveurs gérés, du conseil, des services de domaine, des services réseau ou une infrastructure client privée. Elle devrait lister les canaux de support, les règles d'utilisation acceptable, les conditions de sauvegarde, les droits d'annulation et d'exportation de données, et l'entité juridique contractante. Une page d'espace réservé par défaut ne peut pas faire ce travail.

La divulgation de l'installation et du fournisseur importerait le plus. Bodega ICT n'a pas besoin de publier des identifiants de baie sensibles, mais les clients devraient pouvoir savoir si les services fonctionnent aux Pays-Bas, quelle partie possède le matériel, si une société d'hébergement tierce fournit la plateforme physique, si Bodega ICT contrôle le routeur et si un chemin de secours existe. Pour un petit fournisseur, des frontières de fournisseur claires peuvent avoir plus de valeur que des affirmations vagues d'indépendance.

Une preuve opérationnelle complèterait le tableau. Un client devrait pouvoir voir une restauration de sauvegarde récente, un exemple d'avis d'incident, un chemin d'escalade de support, un processus de changement de route, un processus d'exportation de données et un processus d'annulation qui préserve les données client suffisamment longtemps pour partir en toute sécurité. Ce sont les détails qui transforment une petite identité d'hébergement en un partenaire d'infrastructure digne de confiance.

Jusqu'à ce que ces changements apparaissent, la note responsable est Négative pour l'exploitation réseau actuelle. Le registre est réel. L'exploitation n'est pas visible publiquement. Dans la couverture d'infrastructure, cette différence est le point essentiel.

Pourquoi Négative n'est pas un jugement de caractère

La note Négative ici est délibérément étroite. Elle ne dit pas qu'Eric Kelderman ou Bodega ICT est illégitime. Elle ne dit pas que l'entité ne peut pas exploiter un réseau plus tard. Elle ne dit pas qu'il n'y a pas de services privés. Elle dit que les preuves publiques actuelles ne montrent pas de capacité hébergée routée en direct. C'est une déclaration différente et plus utile pour les lecteurs d'infrastructure.

Cette distinction est importante car les petits fournisseurs vivent souvent dans des états transitoires. Ils peuvent enregistrer un AS avant que le premier circuit ne soit prêt. Ils peuvent demander de l'espace IPv6 avant que les services client ne soient activés. Ils peuvent tester une politique de routage avec un sponsor avant de déplacer le trafic de production. Ils peuvent servir des clients de conseil sans publier un catalogue d'hébergement complet. Ils peuvent garder leur propre site web sur un hébergeur tiers parce que c'est plus simple ou plus résilient. Aucun de ces choix n'est automatiquement mauvais.

Mais les clients achetant de l'infrastructure ont besoin de preuves opérationnelles, pas d'explications sympathiques. Si le service vendu dépend de baies, de transit et de fenêtres de réparation, l'acheteur doit voir la frontière de la baie, la frontière de transit et la frontière de réparation. Un AS dormant ne peut pas répondre à un ticket de support. Un site d'espace réservé ne peut pas expliquer l'exportation de données. Une ligne de politique whois ne peut pas remplacer un fournisseur amont défaillant. Un domaine garé ne peut pas prouver que les sauvegardes sont testées.

Ce ne sont pas des jugements moraux; ce sont des faits opérationnels.

Le meilleur résultat serait une réévaluation future avec de meilleures preuves. Si AS202019 commence à annoncer 2001:678:11b0::/48, si une autorisation d'origine de route est publiée, si AS44854 ou AS56393 deviennent des voisins visibles, si une page de service documente le support et les conditions client, et si les domaines sont intégrés dans un modèle opérationnel clair, la note devrait augmenter. D'ici là, le registre public est mieux traité comme une identité d'infrastructure précoce ou dormante.

Les questions de l'acheteur sont exceptionnellement concrètes

Si un acheteur rencontre Bodega ICT comme un éventuel fournisseur d'hébergement ou de services gérés, la première question ne devrait pas être le prix. Elle devrait être: qu'est-ce qui est exactement vendu sous ce nom aujourd'hui? Si la réponse est du conseil, l'acheteur a besoin de références, de périmètre et de documentation de transfert. Si la réponse est de la capacité hébergée, l'acheteur doit voir le domaine de service, le chemin de support, la frontière d'installation, la frontière amont et la frontière de route.

Si la réponse est de la revente, l'acheteur doit connaître le fournisseur sous-jacent et qui détient les données client pendant les litiges ou les annulations.

La question suivante est de savoir quel réseau transporte le service. Un client devrait demander si AS202019 est utilisé du tout, si 2001:678:11b0::/48 est actif, si un espace IPv4 est attribué, et si les routes apparaissent dans l'aperçu de préfixe RIPEstatou les collecteurs de routes publics. Si le service fonctionne sur un hébergeur tiers, le fournisseur doit le dire directement. Il n'y a rien d'intrinsèquement mauvais à la revente ou à l'hébergement géré au-dessus d'une autre plateforme, mais le risque du client est différent de l'achat de service sur un AS contrôlé par le fournisseur.

La question du support devrait être tout aussi explicite. Le rôle abuse RIPEACRO63211-RIPEet l'objet personneERIC800sont des contacts de registre, pas un service d'assistance client. Un client devrait demander les heures de support normales, le support d'urgence, le traitement des abus, l'escalade de facturation, les règles de préservation des données et les objectifs de réponse. Si le seul contact public est une adresse e-mail, cela ne suffit pas pour une infrastructure critique.

La question de l'installation devrait être formulée sans présumer de la propriété. Bodega ICT possède-t-il des serveurs, loue-t-il des serveurs, loue-t-il de la colocation, exécute-t-il des machines virtuelles sur un hébergeur tiers, ou fournit-il du conseil autour de l'infrastructure de quelqu'un d'autre? Si des serveurs physiques existent, où sont-ils, qui peut y accéder, qui remplace le matériel, et que se passe-t-il en dehors des heures de bureau? Si une infrastructure virtuelle existe, qui contrôle les instantanés, les sauvegardes, la politique de pare-feu et les identifiants client?

Ces questions déterminent si le fournisseur peut réparer le service ou seulement relayer une demande à un autre fournisseur.

La question du contrat devrait couvrir la sortie autant que la disponibilité. Un fournisseur qui est facile à rejoindre mais difficile à quitter crée un risque évitable. Les clients devraient exiger l'exportation de données, la remise de sauvegarde, le transfert DNS, le transfert de domaine, l'accès aux journaux et les conditions de fermeture de compte.NIST SP 800-146est utile ici car il traite l'approvisionnement cloud comme un problème de portabilité et de contrat, pas seulement un choix technologique.NIST SP 800-145est également un rappel que les services cloud dépendent toujours des réseaux, des serveurs, du stockage et des applications. Ces couches doivent être nommées avant de pouvoir leur faire confiance.

Enfin, l'acheteur devrait demander comment les preuves publiques seront maintenues à jour. Si AS202019 passe en ligne, qui met à jour les objets de route, qui publie les ROA et qui surveille la visibilité de la route?Le matériel RPKI du RIPE NCCexplique le mécanisme d'autorisation d'origine de route, etRFC 6811explique le modèle de validation. Un petit fournisseur n'a pas besoin de publier chaque détail de routeur, mais il devrait pouvoir expliquer qui possède les changements de route et comment les erreurs sont corrigées. Sans cela, même une future route en direct ne resterait qu'un signal d'assurance partiel.

Le dernier point pratique est le moment. Un AS nouveau ou réactivé peut passer rapidement de dormant à visible, et une page produit publique peut apparaître avant que les preuves de route ne rattrapent. Cela ne signifie pas que le premier client devrait devenir le cas test. Un acheteur devrait attendre une fenêtre d'observation stable, répéter les vérifications de route sur plus d'un jour, confirmer que le DNS, la messagerie et les canaux de support sont suffisamment séparés pour survivre à un incident d'infrastructure, et exiger un chemin de sortie écrit avant de stocker des données de production.

Dans un contexte de petit fournisseur, la patience est un contrôle. Elle permet au client de voir si le fournisseur construit une surface opérationnelle durable ou seulement une présence temporaire de registre. Un minimum raisonnable serait plusieurs jours consécutifs d'origine de route visible, de disponibilité de la page de contact, de joignabilité du support externe et d'un test réussi de restauration ou d'exportation hors production avant qu'un service critique ne soit déplacé.

Tout ce qui est moins laisse le client financer le premier point de preuve public du fournisseur, avec des données de production à risque avant que la responsabilité opérationnelle ne soit claire. Ce risque est évitable.

La lecture opérationnelle

HOSTING Eric Kelderman trading as Bodega ICT est mieux lu comme une identité d'infrastructure enregistrée au RIPE dont la surface réseau publique en direct ne s'est pas encore matérialisée. L'enregistrement AS202019 est spécifique et récent, l'enregistrement de l'organisation nomme Eric Kelderman trading as Bodega ICT, et les lignes de politique nomment des pairs prévus. Mais RIPEstat ne voit pas l'AS annoncé, ne voit pas de préfixes actuels, ne voit pas de voisins, et montre le /48 IPv6 dans le whois mais pas dans BGP.

La preuve de domaine visible est tout aussi prudente.bodega.nlest une page d'hébergement par défaut sur une infrastructure qui semble tierce.bodegaict.nlrésout via un hébergement garé/tiers et la messagerie Google. Ce sont des surfaces d'identité légitimes, mais elles ne prouvent pas une plateforme d'hébergement exploitée par Bodega. Elles ne donnent pas non plus aux clients les détails publics de contrat, de support ou de migration nécessaires pour les décisions d'infrastructure critiques.

Pour l'instant, Bodega ICT appartient à une liste de surveillance plutôt qu'à une liste restreinte de fournisseurs. Si AS202019 commence à annoncer des préfixes, si un site produit apparaît, ou si des preuves d'installation et de support deviennent publiques, l'évaluation devrait être revisitée. D'ici là, les acheteurs ne devraient pas déduire une capacité hébergée récupérable de la présence d'un objet RIPE propre. Les baies, le transit et les fenêtres de réparation ne deviennent une protection client que lorsqu'ils sont visibles, contractés et testés.