HOSTING Eric Kelderman trading as Bodega ICT vend de la capacité hébergée qui dépend toujours de racks, de transit et de fenêtres de maintenance

Résumé

• L'identité du registre public est réelle. L'aperçu AS pour AS202019de RIPEstat identifieBODEGA-HOSTING Eric Kelderman trading as Bodega ICT, et l'objet aut-num AS202019 de la base de données RIPEAS202019 aut-num entitélisteBODEGA-HOSTING, l'organisation ORG-BH128-RIPE, l'organisation sponsor ORG-ABTA6-RIPE, la politique d'import/export avec AS44854 et AS56393, et la création le 23 janvier 2026.
• L'enregistrement de l'organisation est également spécifique. Une recherche dans la base de données RIPE pourBodega ICTretourne ORG-BH128-RIPE, avec le nom d'organisationEric Kelderman trading as Bodega ICT, l'adresseSakuralaan 13, Almere, le pays NL, l'email[email protected], le contact abus ACRO63211-RIPE et la dernière modification le 13 mai 2026.
• Le routage public actuel est absent.Le statut de routage RIPEstat pour AS202019ne montre aucune annonce IPv4 ou IPv6 visible et aucun voisin observé le 12 juillet 2026;les préfixes annoncés RIPEstatrenvoient zéro préfixe actuel. Il montre une visibilité IPv4 historique, avec une première apparition de 185.39.216.0/22 en 2015 et une dernière apparition de 95.181.220.0/22 en 2022, avant l'état actuel de l'objet registre de 2026.
• Le seul objet de politique de route actuel dans la vue de cohérence RIPEstat n'est pas en service.La cohérence de routage AS RIPEstatliste 2001:678:11b0::/48 comme présent dans whois mais pas dans BGP, et liste la politique d'import/export AS44854 et AS56393 comme présente dans whois mais pas dans BGP.
• La note de preuve est Négative pour l'opération réseau actuelle. Bodega ICT a une identité de registre réelle, mais aucune visibilité de route publique actuelle AS202019, aucun préfixe client actuel visible, aucune observation de voisin active, aucun site produit résolvant sur ses domaines d'identité probables, et aucune preuve publique d'installation, de support, de rack, de sauvegarde ou de migration qui justifierait de la considérer comme une capacité hébergée en direct.

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 identité est claire. Les enregistrements RIPE associent AS202019 à BODEGA-HOSTING et à Eric Kelderman trading as Bodega ICT aux Pays-Bas. L'enregistrement est récent. Il a une structure de sponsor et de mainteneur. Il a une organisation nommée et une adresse. Il a une politique d'import et d'export. Il a un préfixe IPv6 enregistré dans whois. Ces détails suffisent à rendre l'entité digne d'être suivie dans un répertoire d'infrastructure.

La couche opérationnelle est beaucoup plus faible. RIPEstat ne voit pas AS202019 annoncer quoi que ce soit 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 IPv6 /48 dans 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 à un service, préserver une identité, ou attendre une activation.

Cette distinction est importante car les pannes d'infrastructure sont réparées dans la couche opérationnelle, pas dans la couche de dénomination. Un objet de registre peut lister un AS, mais une panne client dépend des sessions de route, des ports amont, de l'accès au routeur, 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 joignabilité. Si les domaines visibles sont hébergés ailleurs, la surface web publique ne prouve pas que Bodega ICT exploite l'infrastructure client derrière AS202019.

La tentation dans un programme de couverture d'entreprise est de traiter chaque détenteur d'AS comme un fournisseur en direct. Cela surestimerait 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 soutiennent pas une affirmation selon laquelle AS202019 transporte une capacité hébergée de production.

La conclusion correcte est donc étroite: Bodega ICT a une identité récente de ressource numérique RIPE, mais l'internet public ne montre actuellement pas cette identité délivrant 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 de travail

Lesdonnées whois de RIPEstat pour AS202019listent aut-num 202019, nom ASBODEGA-HOSTING, organisation ORG-BH128-RIPE, organisation sponsor ORG-ABTA6-RIPE, import de AS44854, export vers AS44854, import de AS56393, export vers AS56393, contacts admin et techniqueeric800etERIC800, statut ASSIGNED, et création le 23 janvier 2026. L'objet aut-num de 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, email[email protected], contact abus 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é de ressource numérique de l'entité.

Les objets de politique suggèrent des amonts prévus. AS44854 et AS56393 sont listés dans la politique d'import et d'export.La vue de cohérence de routage AS de RIPEstat pour AS202019liste ces pairs comme présents dans la politique whois mais pas dans BGP. C'est un signal d'état planifié utile. Ce n'est pas une preuve de connectivité en direct au moment vérifié. La politique peut exister avant l'activation des circuits, après le retrait des circuits, 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 whois mais pas dans BGP. En d'autres termes, il y a au moins un objet de route IPv6 ou une allocation dans les données du registre, mais il n'est pas visible en tant que route AS202019 annoncée dans la vue RIPEstat. Pour un client, la question pratique est de savoir si l'IPv6 est en direct, planifié, inutilisé ou attribué uniquement pour un futur service. La réponse publique le 12 juillet 2026 est: pas visiblement routé.

Les données historiques de RIPEstat ajoutent des nuances. La vue du statut de routage indique que 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, cependant, a été créé en janvier 2026. Les numéros 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 traitée comme une preuve que l'entité Bodega ICT d'aujourd'hui transporte ces anciennes routes.

La vérification opérationnelle actuelle doit se concentrer sur la visibilité présente, et cette visibilité est vide.

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

Les preuves de domaine renforcent la faible note opérationnelle. 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 dans la page. Les chemins tels que/hosting,/contact,/dienstenet/ictont retourné des réponses 404 lors des vérifications locales. Ce n'est pas un site produit en direct 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 tiers. L'enregistrement A lors des 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 courrier ZXCS. Ces preuves pointent vers une infrastructure d'hébergement partagé de type ZXCS, pas vers une plateforme client AS202019 visible.

Le domaine d'identité probablebodegaict.nlpointe également loin de 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 le courrier Hostinger et Google. C'est un motif courant de domaine parqué ou hébergé par un tiers. Il soutient l'existence d'une surface d'identité et de courrier. Il ne soutient pas une affirmation selon laquelle Bodega ICT héberge son propre site public ou ses services clients sur son AS attribué.

Les variantes inactives debodega-ict.nln'ont pas fourni de surface de site plus forte lors des vérifications DNS locales. Cela compte car le propre site web d'un petit fournisseur est souvent la première preuve publique des conditions de service, du contact support, du menu produit, de la politique d'utilisation acceptable, du SLA, de la page de statut, 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 recommandation, contrat direct, portail privé ou arrangement de revendeur. Certains maintiennent leur site public minimal tout en exploitant une infrastructure réelle. Mais la couverture publique ne peut pas le supposer. Si le site visible est un espace réservé et que l'AS attribué n'annonce pas, la conclusion éditoriale doit être conservatrice.

Ce qui devrait être vrai pour une capacité hébergée

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

Quatrièmement, un acheteur devrait savoir si Bodega ICT contrôle la couche physique ou seulement courtise un service depuis un autre hôte.

Les preuves publiques actuelles ne satisfont pas ces tests. 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 de gammes de produits, d'emplacements de centres de données, de canaux de support, de conditions, d'historique de statut, de sauvegardes ou de 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 d'installation ou de profil de peering qui peut combler le vide.

Cela laisse une distinction étroite mais importante. Un AS dormant ou en préparation peut encore être une preuve utile pour une surveillance future, car il indique aux observateurs quelle ressource vérifier si un lancement de service apparaît. Ce n'est pas une preuve utile pour la dépendance actuelle d'un client. 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 limite de fournisseur, et d'une réponse écrite sur ce qui se passe lorsque l'équipement, le transit, le DNS, la facturation ou la sauvegarde échouent.

L'objet RIPE peut aider à identifier la partie à qui demander. Il ne peut pas répondre aux questions opérationnelles par lui-même.

Le timing compte aussi. Si AS202019 devient visible demain, un instantané 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 non productif. Cette période d'attente n'est pas bureaucratique. Elle empêche le premier client de production de devenir 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é, 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 de statut et d'un chemin de retour de données qui ne dépendent pas de conjectures. Les preuves d'espace réservé et de domaine parqué peuvent coexister avec un service privé sérieux; cela signifie simplement que le paquet de diligence raisonnable privé doit peser plus lourd.

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

S'il prépare seulement 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 publique AS202019, un client ne peut pas surveiller AS202019 pour la joignabilité. 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ôte tiers, pas du réseau propre de Bodega. Si les futurs services clients migrent vers AS202019, les clients auront besoin d'un nouvel examen des amonts, 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 abrite l'équipement? Qui possède le matériel? Qui contrôle les sessions amont? Y a-t-il des ROA actuelles? 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 maintenant.

Une politique de route sans sessions actives n'est pas une résilience

L'objet aut-num AS202019 liste AS44854 et AS56393 comme pairs de politique. Ce 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 une politique après le retrait d'une route. Il peut prévoir d'utiliser ces amonts plus tard. Aucun de ces cas ne donne au client une joignabilité actuelle.

C'est pourquoi "deux ASN nommés dans le registre" ne devrait pas être décrit comme un multi-hébergement. Le multi-hébergement signifie une capacité en direct ou testée à continuer le service via plus d'un amont. Cela nécessite des circuits, une configuration de routeur, des filtres amont, une autorisation d'origine de route, une 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'un rack a un second chemin.

Le même principe s'applique au IPv6 /48. La présence de 2001:678:11b0::/48 dans whois indique une préparation ou une allocation. Elle ne montre pas que les services clients peuvent utiliser l'IPv6. Elle ne montre pas que le DNS, le DNS inversé, 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 sauver 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 du tout. Si AS202019 commence à annoncer le /48 ou un nouveau préfixe IPv4, les vérifications RPKI et de politique de route devraient être répétées à ce moment-là. La réponse actuelle est que les collecteurs publics ne voient pas de surface de service AS202019 en direct.

C'est le bon endroit pour être strict. Une entreprise d'hébergement dépend de la joignabilité. Si la joignabilité est absente de la table de routage publique, alors l'article ne devrait 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 surtout un risque d'incertitude

Le risque principal 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 considérer le nom. Il se peut qu'il n'y ait pas de service hébergé destiné aux clients à acheter sous AS202019 aujourd'hui. Il peut y avoir un service privé non visible pour les collecteurs publics. Il peut y avoir un réseau en phase précoce qui deviendra actif plus tard. Chaque possibilité a des implications différentes.

Si le service n'est pas encore en direct, alors la diligence raisonnable correcte est la préparation au lancement: propriété des préfixes, activation des amonts, autorisation d'origine de route, contacts de support, communications d'incident, conditions de facturation et conception de sauvegarde. Si le service est privé, alors 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, alors la diligence raisonnable correcte est la frontière du fournisseur: quel hôte, quel centre de données, quel compte, quel droit de support et quelle partie préserve les données si la relation se termine.

Les domaines rendent l'incertitude plus visible.bodega.nlétant une page placeholder signifie qu'un client potentiel ne peut pas inspecter les conditions de produit là-bas.bodegaict.nlutilisant le DNS-parking et le courrier 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 de statut, 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 devrait pas être comblée par des hypothèses. Le travail 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 publique actuelle AS202019. C'est suffisant pour une note de recherche liée à un annuaire, mais pas assez pour une évaluation 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 elle est facile à mal interpréter. Un fournisseur peut exploiter une entreprise d'infrastructure sérieuse tout en utilisant des fournisseurs externes pour son propre site web public, son courrier électronique et son DNS. Ce n'est pas automatiquement faible. Un petit opérateur réseau pourrait délibérément héberger son site public en dehors de son propre AS afin que les clients puissent toujours joindre les avis de support pendant une panne.

Il pourrait utiliser le courrier Google ou une autre pile de courrier SaaS car la fiabilité du courrier est un problème opérationnel différent de l'hébergement de serveurs clients. Il pourrait parquer un domaine lors d'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 placeholder debodega.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 qui ne fonctionne pas comme une vitrine d'hébergement public. Le modèle DNS debodegaict.nl, avec des serveurs de noms DNS-parking, des enregistrements MX Google et des inclusions SPF Hostinger/Google, montre un domaine d'identité et une configuration de courrier 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 compte car les surfaces de domaine public sont l'endroit où les petits fournisseurs publient généralement les contrôles qui rendent leur infrastructure compréhensible: descriptions de produits, conditions, fenêtres de support, règles d'abus, politiques de sauvegarde, pages de statut et langage de migration. Si ceux-ci sont absents, le client doit les recueillir en privé.

Un acheteur devrait demander si le domaine public placeholder 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ôte tiers derrière 185.104.29.66 ou la configuration DNS du domaine, pas AS202019. Si le courrier debodegaict.nlest retardé, le problème peut impliquer le routage du courrier Google, l'autorisation de courrier Hostinger ou le DNS-parking plutôt qu'un réseau exploité par Bodega. Inversement, si AS202019 devient plus tard actif, un client pourrait voir des problèmes de route AS202019 tandis 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 claire est donc une carte des responsabilités. Quels domaines sont du marketing public? Quels domaines sont du support? Quels domaines sont des panneaux de contrôle clients? 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 du courrier? Quel canal de contact survit si la propre route du fournisseur est en panne? Sans ces réponses, la disponibilité du domaine ne prouve pas la capacité de l'infrastructure client.

Comment retester AS202019 s'il devient en ligne

La note devrait changer si l'image de route publique change. Le premier retest est simple: vérifierles préfixes annoncés RIPEstat pour AS202019etle statut de routage RIPEstat pour AS202019. Si l'un ou l'autre commence à montrer des préfixes actuels, enregistrez la liste des préfixes, l'heure de première apparition, le nombre d'adresses visibles, le statut IPv4 versus 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é des amonts. Vérifierles voisins ASN RIPEstat pour AS202019et comparer avecla cohérence de routage AS RIPEstat. Si AS44854 et AS56393 restent dans whois mais seulement un ou aucun n'apparaît dans BGP, les preuves publiques ne prouvent toujours pas le multi-hébergement. 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 la même structure d'échange ou partagent la même relation commerciale.

Le troisième retest est la sécurité de route. Si 2001:678:11b0::/48 devient visible, vérifierla validation 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 racks ou les sauvegardes, mais améliorerait l'assurance de routage. Inconnu serait un écart d'hygiène. Invalide serait une préoccupation opérationnelle matérielle.

Le quatrième retest est l'alignement du registre. Comparer les préfixes en direct avecl'objet AS202019 de la base de données RIPE,l'enregistrement d'organisation de la base de données RIPE pour Bodega ICT, etl'enregistrement de la base de données RIPE pour 2001:678:11b0::/48. Le but n'est pas de punir les petites incohérences. C'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 compteraient lors des incidents.

Le cinquième retest est l'alignement du service public. Si l'AS devient en ligne mais quebodega.nlreste un placeholder et quebodegaict.nlreste parqué ou hébergé par un tiers, la route prouverait l'activité réseau mais ne prouverait toujours pas une offre de service hébergé. 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 route plutôt qu'acceptées par elles-mêmes.

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 les clients depuis AS202019 et de le maintenir visible dans le temps. Un seul préfixe visible ne prouverait pas la résilience, mais il ferait passer le cas d'une empreinte de seul registre à une empreinte de réseau opérationnel. Si le 2001:678:11b0::/48 est destiné à être actif, un BGP visible, un DNS inversé, une validation d'origine de route et une documentation de service aideraient.

Une page de service public changerait également la note. Elle devrait indiquer 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é contractuelle légale. Une page placeholder par défaut ne peut pas faire ce travail.

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

Une preuve opérationnelle compléterait le tableau. Un client devrait pouvoir voir une récente restauration de sauvegarde, 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 clients 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'opération réseau actuelle. Le registre est réel. L'opération n'est pas publiquement visible. Dans la couverture d'infrastructure, cette différence est le point.

Pourquoi Négatif 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 compte car les petits fournisseurs vivent souvent dans des états transitionnels. 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 clients ne soient activés. Ils peuvent tester une politique de route avec un sponsor avant de déplacer le trafic de production. Ils peuvent servir des clients de conseil sans publier de catalogue d'hébergement complet. Ils peuvent garder leur propre site web sur un hôte 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 racks, de transit et de fenêtres de réparation, l'acheteur doit voir la limite du rack, la limite du transit et la limite de réparation. Un AS dormant ne peut pas répondre à un ticket de support. Un site placeholder ne peut pas expliquer l'exportation de données. Une ligne de politique whois ne peut pas remplacer un amont défaillant. Un domaine parqué 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 future réévaluation avec de meilleures preuves. Si AS202019 commence à annoncer 2001:678:11b0::/48, si l'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 clients, et si les domaines sont amenés à un modèle opérationnel clair, la note devrait augmenter. Jusque-là, le registre public est mieux traité comme une identité d'infrastructure précoce ou dormante.

Les questions de l'acheteur sont inhabituellement concrètes

Si un acheteur rencontre Bodega ICT comme un possible 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 passation. Si la réponse est de la capacité hébergée, l'acheteur doit voir le domaine de service, le chemin de support, la limite d'installation, la limite amont et la limite 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 l'annulation.

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 en direct, si un espace IPv4 est attribué, et si les routes apparaissent dansl'aperçu des préfixes RIPEstatou les collecteurs de routes publics. Si le service fonctionne sur un hôte tiers, le fournisseur devrait le dire directement. Il n'y a rien d'intrinsèquement mal à 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 d'un service sur un AS contrôlé par le fournisseur.

La question de support devrait être tout aussi explicite. Le rôle d'abus RIPEACRO63211-RIPEet l'objet personneERIC800sont des contacts de registre, pas un service client. Un client devrait demander les heures de support normales, le support d'urgence, la gestion des abus, l'escalade de facturation, les règles de conservation des données et les objectifs de réponse. Si le seul contact public est une adresse email, ce n'est pas suffisant pour une infrastructure critique.

La question d'installation devrait être formulée sans supposer la propriété. Est-ce que Bodega ICT possède des serveurs, loue des serveurs, loue de la colocation, exécute des machines virtuelles sur un hôte tiers, ou fournit 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 clients?

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

La question contractuelle devrait couvrir la sortie ainsi que la disponibilité. Un fournisseur facile à rejoindre mais difficile à quitter crée un risque évitable. Les clients devraient exiger l'exportation de données, la passation de sauvegarde, le transfert DNS, le transfert de domaine, l'accès aux logs et les conditions de clôture 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-145rappelle aussi que les services cloud dépendent toujours des réseaux, serveurs, stockage et applications. Ces couches doivent être nommées avant de pouvoir être fiables.

Enfin, l'acheteur devrait demander comment les preuves publiques seront maintenues à jour. Si AS202019 devient en ligne, qui met à jour les objets de route, qui publie les ROA, et qui surveille la visibilité de 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 resterait un signal d'assurance seulement partiel.

Le dernier point pratique est le timing. Un AS nouveau ou réactivé peut passer de dormant à visible rapidement, 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 de 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, le courrier 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 page de contact, de joignabilité de support externe et un test réussi d'exportation ou de restauration non productif avant que tout service critique ne soit déplacé.

Moins que cela laisse le client financer le premier point de preuve publique du fournisseur, avec des données de production en 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 auprès de 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 d'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 IPv6 /48 dans whois mais pas dans BGP.

Les preuves de domaine visibles sont tout aussi prudentes.bodega.nlest une page d'hébergement par défaut sur une infrastructure d'apparence tierce.bodegaict.nlrésout via un hébergement parqué/tiers et le courrier 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 le contrat public, le support ou le détail de migration nécessaires pour des décisions d'infrastructure critique.

Pour l'instant, Bodega ICT appartient à une liste de surveillance plutôt qu'à une shortlist 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 revue. Jusque-là, les acheteurs ne devraient pas inférer une capacité hébergée récupérable de la présence d'un objet RIPE propre. Les racks, le transit et les fenêtres de réparation ne deviennent une protection client que lorsqu'ils sont visibles, contractés et testés.