HOSTING Eric Kelderman trading as Bodega ICT sells hosted capacity that still depends on racks, transit and repair windows

Summary

• The public registry identity is real. RIPEstat's AS overview for AS202019 identifies BODEGA-HOSTING Eric Kelderman trading as Bodega ICT, and the RIPE Database AS202019 aut-num entity lists BODEGA-HOSTING, organisation ORG-BH128-RIPE, sponsoring organisation ORG-ABTA6-RIPE, import/export policy with AS44854 and AS56393, and creation on 23 January 2026.
• The organisation record is also specific. A RIPE Database search for Bodega ICT returns ORG-BH128-RIPE, with the organisation name Eric Kelderman trading as Bodega ICT, address Sakuralaan 13, Almere, country NL, email [email protected], abuse contact ACRO63211-RIPE and last modification on 13 May 2026.
• Current public routing is absent. RIPEstat routing status for AS202019 shows no visible IPv4 or IPv6 announcements and no observed neighbours on 12 July 2026; RIPEstat announced prefixes returns zero current prefixes. It does show historical IPv4 visibility, with first-seen 185.39.216.0/22 in 2015 and last-seen 95.181.220.0/22 in 2022, before the current 2026 registry entity state.
• The only current route-policy entity in the RIPEstat consistency view is not live. RIPEstat AS-routing-consistency lists 2001:678:11b0::/48 as present in whois but not in BGP, and lists AS44854 and AS56393 import/export policy as present in whois but not in BGP.
• The evidence grade is Negative for current network operation. Bodega ICT has a real registry identity, but no current public AS202019 route visibility, no visible current customer prefix, no active neighbour observation, no resolving product site on its likely identity domains, and no public facility, support, rack, backup or migration evidence that would support treating it as live hosted capacity.

The name says hosting, the route table says not yet

The useful way to read HOSTING Eric Kelderman trading as Bodega ICT is to separate identity from operation. The identity layer is clear. RIPE records associate AS202019 with BODEGA-HOSTING and with Eric Kelderman trading as Bodega ICT in the Netherlands. The record is recent. It has sponsoring and maintainer structure. It has a named organisation and address. It has import and export policy. It has an IPv6 prefix recorded in whois. Those details are enough to make the entity worth tracking in an infrastructure directory.

The operating layer is much weaker. RIPEstat does not see AS202019 announcing anything on 12 July 2026. It does not see an IPv4 prefix. It does not see an IPv6 prefix. It does not see a neighbour. The announced-prefixes view is empty. The consistency view sees one IPv6 /48 in whois but not in BGP. That combination is not a live hosting network in the public route table. It is a registry and policy footprint that may be preparing for service, preserving an identity, or waiting for activation.

That distinction matters because infrastructure failures are repaired in the operating layer, not the naming layer. A registry entity can list an AS, but a customer outage depends on route sessions, upstream ports, router access, power, cabinets, servers, support and contracts. If the AS is not visible, a customer cannot rely on it for reachability. If the visible domains are hosted elsewhere, the public web surface does not prove that Bodega ICT operates customer infrastructure behind AS202019.

The temptation in a company coverage programme is to treat every AS holder as a live provider. That would overstate this case. Bodega ICT may become an active network. It may have private customers or non-public infrastructure. It may use third-party hosting while preparing its own AS. But the public evidence available now does not support a claim that AS202019 is carrying production hosted capacity.

The right conclusion is therefore narrow: Bodega ICT has a recent RIPE number-resource identity, but the public internet does not currently show that identity delivering routed service. Buyers should ask for current route evidence, service terms and facility proof before treating the name as an operational hosting provider.

RIPE identifies the entity, but not a working platform

RIPEstat's whois data for AS202019 lists aut-num 202019, AS name BODEGA-HOSTING, organisation ORG-BH128-RIPE, sponsoring organisation ORG-ABTA6-RIPE, import from AS44854, export to AS44854, import from AS56393, export to AS56393, admin and technical contacts eric800 and ERIC800, ASSIGNED status, and creation on 23 January 2026. The RIPE Database aut-num entity shows the same structure.

The RIPE search result for Bodega ICT provides the organisation record. It names Eric Kelderman trading as Bodega ICT, gives address Sakuralaan 13, Almere, country NL, email [email protected], abuse contact ACRO63211-RIPE, maintainer nl-eritap-1-MNT, creation on 20 January 2026 and last modification on 13 May 2026. This is not a vague secondary directory entry. It is the official RIPE Database entity that anchors the entity's number-resource identity.

The policy entities suggest intended upstreams. AS44854 and AS56393 are listed in import and export policy. RIPEstat's AS-routing-consistency view for AS202019 lists those peers as present in whois policy but not in BGP. That is a useful planned-state signal. It is not evidence of live connectivity at the checked time. Policy can exist before circuits are activated, after circuits are retired, or while sessions are too limited to appear in the public collector view.

The same consistency view lists 2001:678:11b0::/48 as present in whois but not in BGP. In other words, there is at least one IPv6 route object or allocation in registry data, but it is not visible as an announced AS202019 route in the RIPEstat view. For a customer, the practical question is whether IPv6 is live, planned, unused or assigned only for future service. The public answer on 12 July 2026 is: not visibly routed.

Historical RIPEstat data adds nuance. The routing-status view says AS202019 was first seen with 185.39.216.0/22 in 2015 and last seen with 95.181.220.0/22 in 2022. The current RIPE aut-num entity, however, was created in January 2026. AS numbers can be reassigned, repurposed, sponsored differently or re-registered over time. That means historical prefix visibility should not be treated as proof that today's Bodega ICT entity is carrying those old routes. The current operating check must focus on present visibility, and that visibility is empty.

The domains point to third-party hosting, not AS202019

Domain evidence reinforces the weak operating grade. The domain bodega.nl resolves, but the web page is a default hosting placeholder: "Welcome to the home of bodega.nl" and "To change this page, upload your website into the public_html directory," with a creation date shown in the page. Paths such as /hosting, /contact, /diensten and /ict returned 404 responses in the local checks. That is not a live product site for a hosting provider. It is a default hosted page.

DNS for bodega.nl points to third-party hosting infrastructure. The A record in local checks was 185.104.29.66, the AAAA record was 2a06:2ec0:1::111, the name servers were ns.zxcs.eu, ns.zxcs.be and ns.zxcs.nl, and the MX target was mail.bodega.nl. The SPF record included the 185.104.29.0/24 range, the 185.104.29.66 address, the IPv6 web address and ZXCS mail filtering. That evidence points to ZXCS-style shared hosting infrastructure, not to a visible AS202019 customer platform.

The likely identity domain bodegaict.nl also points away from AS202019. Local DNS checks showed A record 2.57.91.91, AAAA record 2a02:4780:84::32, name servers ns1.dns-parking.com and ns2.dns-parking.com, Google MX records, and SPF includes for Hostinger mail and Google. That is a common parked or third-party-hosted domain pattern. It supports the existence of an email and identity surface. It does not support a claim that Bodega ICT hosts its own public site or customer services on its assigned AS.

The inactive bodega-ict.nl variants did not provide a stronger site surface in local DNS checks. That matters because a small provider's own website is often the first public proof of service terms, support contact, product menu, acceptable-use policy, SLA, status page, ticket portal and customer migration language. Here, the public domain evidence gives identity and third-party hosting clues, but not a hosted-capacity offer.

This does not mean Bodega ICT has no customers. Many small operators serve customers by referral, direct contract, private portal or reseller arrangement. Some keep their public site minimal while operating real infrastructure. But public coverage cannot assume that. If the visible site is a placeholder and the assigned AS is not announcing, the editorial conclusion has to be conservative.

What would have to be true for hosted capacity

For Bodega ICT to be a live hosted-capacity provider in the sense relevant to this coverage series, several things would have to be proven. First, AS202019 or another clearly identified AS would need to originate customer-relevant prefixes. Second, the provider would need to show where servers, storage or virtual infrastructure actually run. Third, customers would need support, backup, billing and migration terms. Fourth, a buyer would need to know whether Bodega ICT controls the physical layer or only brokers service from another host.

The current public evidence does not satisfy those tests. AS202019 has no visible prefixes. The Bodega domains use third-party hosting surfaces. The public web pages reviewed do not describe product tiers, data-centre locations, support channels, terms, status history, backups or customer export rights. RIPE registry records do not name a facility. The consistency view does not show active upstream sessions. PeeringDB and public route directories do not provide a facility or peering profile that can fill the gap.

That leaves a narrow but important distinction. A dormant or preparing AS can still be useful evidence for future monitoring, because it tells observers which resource to check if a service launch appears. It is not useful evidence for present customer reliance. A customer buying hosting today needs an address that routes, a support channel that works, a facility or supplier boundary, and a written answer about what happens when equipment, transit, DNS, billing or backup fails. The RIPE entity can help identify the party to ask. It cannot answer the operating questions by itself.

The timing also matters. If AS202019 becomes visible tomorrow, one route snapshot would still be early evidence, not maturity evidence. The customer would need repeated route observations, a stable prefix list, route-origin validation where applicable, upstream-neighbour consistency, service documentation and a non-production restore or export test. That waiting period is not bureaucratic. It prevents the first production customer from becoming the proof that the provider should have gathered before selling critical capacity.

The same standard should apply to the domains. A working public page is not required for every private infrastructure service, but a critical customer still needs a support address, an abuse path, a billing path, a status channel and a data-return path that do not depend on guesswork. Placeholder and parked-domain evidence can coexist with a serious private service; it simply means the private due-diligence package has to carry more weight.

The physical dependencies remain the same as for any hosting service. A server has to sit in a room. The room needs power and cooling. The router needs upstream connectivity. Somebody needs access to the rack. Somebody has to replace failed hardware. Somebody has to answer abuse reports. Somebody has to preserve customer data during billing disputes or suspension events. If Bodega ICT sells hosting privately, these responsibilities exist even if they are not visible. If it is only preparing a network identity, those responsibilities may not yet exist.

The absence of public route visibility is especially important for failure analysis. If there is no public AS202019 route, a customer cannot monitor AS202019 for reachability. If a Bodega domain is hosted on ZXCS or Hostinger-style infrastructure, incidents involving that domain may be incidents of the third-party host, not Bodega's own network. If future customer services move to AS202019, customers will need a fresh review of upstreams, route-origin validation, prefix ownership, support and failover.

Buyers should therefore ask simple questions before committing to any hosted service under the Bodega ICT name. Which AS carries the service? Which prefixes are customer-facing? Which facility houses the equipment? Who owns the hardware? Who controls the upstream sessions? Are there current ROAs? Are backups tested? How is data exported? What happens if the provider suspends the service? The public record does not answer these questions now.

Route policy without active sessions is not resilience

The AS202019 aut-num entity lists AS44854 and AS56393 as policy peers. That is useful only as an intended or documented path. It is not a resilience proof. RIPEstat saw both in whois policy and neither in BGP for AS202019 at the query time. A provider may keep policy lines ready before turning up a circuit. It may retain policy after a route is withdrawn. It may plan to use those upstreams later. None of those cases gives a customer current reachability.

This is why "two named ASNs in the registry" should not be described as multi-homing. Multi-homing means live or tested ability to continue service through more than one upstream. It requires circuits, router configuration, upstream filters, route-origin authorization, capacity and operational procedures. A static policy line cannot carry traffic. It cannot absorb an outage. It cannot prove that a rack has a second path.

The same principle applies to the IPv6 /48. The presence of 2001:678:11b0::/48 in whois indicates preparation or allocation. It does not show that customer services can use IPv6. It does not show that DNS, reverse DNS, firewalls, monitoring and customer support are ready for IPv6 incidents. If a provider sells IPv6, customers should test it from multiple networks and require it in service terms.

Route-origin validation could not rescue the evidence grade. With no visible route in BGP, the practical question is not whether a current route is valid or invalid. The practical question is whether the provider has a route at all. If AS202019 begins announcing the /48 or a new IPv4 prefix, RPKI and route-policy checks should be repeated at that time. The current answer is that public collectors do not see a live AS202019 service surface.

This is the right place to be strict. A hosting business depends on reachability. If reachability is absent from the public route table, then the article should not score the network as medium or strong merely because the registry entity is clean. The registry entity is a starting document. The route table is the operating evidence. Here, the operating evidence is negative.

Customer risk is mostly uncertainty risk

The main risk around Bodega ICT is not that the public evidence shows a bad network. It is that the public evidence does not show a current network. That changes how a customer should think about the name. There may be no customer-facing hosted service to buy under AS202019 today. There may be private service not visible to public collectors. There may be an early-stage network that will become active later. Each possibility has different implications.

If the service is not yet live, then the correct due diligence is launch readiness: prefix ownership, upstream activation, route-origin authorization, support contacts, incident communications, billing terms and backup design. If the service is private, then the correct due diligence is customer-specific proof: a test route, traceroute, contract, facility statement, restore exercise and exit procedure. If the service is third-party resale, then the correct due diligence is supplier boundary: which host, which data centre, which account, which support entitlement and which party preserves data if the relationship ends.

The domains make uncertainty more visible. bodega.nl being a placeholder page means a prospective customer cannot inspect product terms there. bodegaict.nl using DNS-parking and Google/Hostinger mail signals an identity surface, but not an infrastructure platform. There is no public ticket portal, status page, support SLA, product catalogue or migration guide in the pages checked for this article. Without those, the customer cannot tell whether the provider is a hands-on operator, a small consultancy, a reseller, a dormant identity or a network in preparation.

That uncertainty should not be filled with assumptions. The article's job is to identify what the public evidence supports. It supports a newly visible RIPE identity for Bodega ICT and a currently non-announced AS. It supports third-party-hosted domain surfaces. It supports no current public AS202019 customer route. That is enough for a directory-linked research note, but not enough for a positive infrastructure rating.

Domain hosting is evidence of dependence, not evidence of capacity

The domain evidence deserves its own treatment because it is easy to misread. A provider can run a serious infrastructure business while using outside providers for its own public website, email and DNS. That is not automatically weak. A small network operator might deliberately host its public site outside its own AS so customers can still reach support notices during an outage. It might use Google mail or another SaaS mail stack because mail reliability is a different operational problem from customer server hosting. It might park a domain during a rebrand or before a full service launch.

The issue in this case is not that outside hosting exists. The issue is that outside hosting is the only visible public surface. The bodega.nl placeholder page, the ZXCS name servers seen in local DNS checks and the SPF references to ZXCS filtering show a domain that is alive but not operating as a public hosting storefront. The bodegaict.nl DNS pattern, with DNS-parking name servers, Google MX records and Hostinger/Google SPF includes, shows an identity domain and mail setup rather than a self-operated platform. Those are useful clues, but they do not answer the service questions a customer would ask.

That matters because public-domain surfaces are where small providers usually publish the controls that make their infrastructure intelligible: product descriptions, terms, support windows, abuse rules, backup policies, status pages and migration language. If those are absent, the customer must collect them privately. A buyer should ask whether the public placeholder domain is intentionally unused, whether another service domain exists, whether any customer portal is private, and whether support communication depends on the same outside providers used for the public domains.

The public DNS links also create a monitoring boundary. If bodega.nl is down, the outage may involve the third-party host behind 185.104.29.66 or the domain's DNS setup, not AS202019. If bodegaict.nl mail is delayed, the problem may involve Google mail routing, Hostinger mail authorization or DNS parking rather than a Bodega-operated network. Conversely, if AS202019 later becomes active, a customer could see AS202019 route trouble while the public website remains reachable through outside hosting. A proper incident plan has to separate those surfaces.

The clean due-diligence request is therefore a responsibility map. Which domains are public marketing? Which domains are support? Which domains are customer control panels? Which parts are hosted by third parties? Which parts, if any, run on AS202019? Which vendor is responsible for mail delivery? Which published contact points survives if the provider's own route is down? Without those answers, domain uptime does not prove customer infrastructure capacity.

How to re-test AS202019 if it comes online

The score should change if the public route picture changes. The first re-test is simple: check RIPEstat announced prefixes for AS202019 and RIPEstat routing status for AS202019. If either starts showing current prefixes, record the prefix list, the first-seen time, the visible address count, IPv4 versus IPv6 status and the number of RIS peers seeing the route. That establishes whether the AS has moved from registry state to operating state.

The second re-test is upstream diversity. Check RIPEstat ASN neighbours for AS202019 and compare it with RIPEstat AS-routing-consistency. If AS44854 and AS56393 remain in whois but only one or neither appears in BGP, the public evidence still does not prove multi-homing. If both appear in BGP, the next question is physical diversity: whether the two paths enter the same facility, depend on the same sponsor, use the same exchange fabric or share the same commercial relationship.

The third re-test is route security. If 2001:678:11b0::/48 becomes visible, check RIPEstat route-origin validation for AS202019 and 2001:678:11b0::/48. If a new IPv4 prefix appears, check that prefix separately. A valid RPKI state would not prove racks or backups, but it would improve routing assurance. Unknown would be a hygiene gap. Invalid would be a material operational concern.

The fourth re-test is registry alignment. Compare live prefixes with the RIPE Database AS202019 entity, the RIPE Database organisation record for Bodega ICT, and the RIPE Database record for 2001:678:11b0::/48. The purpose is not to punish small inconsistencies. It is to understand whether the announced route is tied to the same organisation, sponsor and contacts that customers would rely on during incidents.

The fifth re-test is public service alignment. If the AS comes online but bodega.nl remains a placeholder and bodegaict.nl remains parked or third-party-hosted, the route would prove network activity but still not prove a hosted service offer. Customers would still need a product page, contract, support path and migration plan. If a new product site appears, its claims should be matched against the route data rather than accepted by itself.

What would change the score

The fastest way for Bodega ICT to improve the public evidence grade would be to announce a customer-relevant prefix from AS202019 and keep it visible over time. A single visible prefix would not prove resilience, but it would move the case from a registry-only footprint to an operating network footprint. If the 2001:678:11b0::/48 is meant to be active, visible BGP, reverse DNS, route-origin validation and service documentation would help.

A public service page would also change the score. It should say whether Bodega ICT sells web hosting, VPS, managed servers, consultancy, domain services, network services or private customer infrastructure. It should list support channels, acceptable-use rules, backup terms, cancellation and data-export rights, and the legal contracting entity. A default placeholder page cannot do that work.

Facility and supplier disclosure would matter most. Bodega ICT does not need to publish sensitive rack identifiers, but customers should be able to learn whether services run in the Netherlands, which party owns the hardware, whether a third-party hosting company provides the physical platform, whether Bodega ICT controls the router and whether any backup path exists. For a small provider, clear supplier boundaries can be more valuable than vague claims of independence.

Operational proof would complete the picture. A customer should be able to see a recent backup restore, a sample incident notice, a support escalation path, a route-change process, a data-export process and a cancellation process that preserves customer data long enough to leave safely. These are the details that turn a small hosting identity into a trustworthy infrastructure partner.

Until those changes appear, the responsible score is Negative for current network operation. The registry is real. The operation is not publicly visible. In infrastructure coverage, that difference is the point.

Why Negative is not a character judgment

The Negative grade here is deliberately narrow. It does not say Eric Kelderman or Bodega ICT is illegitimate. It does not say the entity cannot operate a network later. It does not say there are no private services. It says that the current public evidence does not show live routed hosted capacity. That is a different and more useful statement for infrastructure readers.

This distinction matters because small providers often live in transitional states. They may register an AS before the first circuit is ready. They may request IPv6 space before customer services are enabled. They may test route policy with a sponsor before moving production traffic. They may serve consultancy customers without publishing a full hosting catalogue. They may keep their own website on a third-party host because it is simpler or more resilient. None of those choices is automatically wrong.

But customers buying infrastructure need operating proof, not sympathetic explanations. If the service being sold depends on racks, transit and repair windows, the buyer needs to see the rack boundary, the transit boundary and the repair boundary. A dormant AS cannot answer a support ticket. A placeholder site cannot explain data export. A whois policy line cannot replace a failed upstream. A parked domain cannot prove that backups are tested. Those are not moral judgments; they are operational facts.

The best outcome would be a future reassessment with better evidence. If AS202019 begins announcing 2001:678:11b0::/48, if route-origin authorization is published, if AS44854 or AS56393 become visible neighbours, if a service page documents support and customer terms, and if the domains are brought into a clear operating model, the grade should rise. Until then, the public record is best treated as an early or dormant infrastructure identity.

The buyer questions are unusually concrete

If a buyer encounters Bodega ICT as a possible hosting or managed-service supplier, the first question should not be price. It should be: what exactly is being sold under this name today? If the answer is consultancy, the buyer needs references, scope and handover documentation. If the answer is hosted capacity, the buyer needs to see the service domain, support path, facility boundary, upstream boundary and route boundary. If the answer is resale, the buyer needs to know the underlying provider and who holds the customer data during disputes or cancellation.

The next question is which network carries the service. A customer should ask whether AS202019 is used at all, whether 2001:678:11b0::/48 is live, whether any IPv4 space is assigned, and whether the routes appear in RIPEstat prefix overview or public route collectors. If the service runs on a third-party host, the provider should say so directly. There is nothing inherently wrong with resale or managed hosting above another platform, but the customer's risk is different from buying service on a provider-controlled AS.

The support question should be just as explicit. The RIPE abuse role ACRO63211-RIPE and the person entity ERIC800 are registry contacts, not a customer help desk. A customer should ask for normal support hours, emergency support, abuse handling, billing escalation, data-preservation rules and response targets. If the only public contact is an email address, that is not enough for critical infrastructure.

The facility question should be phrased without assuming ownership. Does Bodega ICT own servers, rent servers, lease colocation, run virtual machines on a third-party host, or provide consulting around someone else's infrastructure? If physical servers exist, where are they, who can access them, who replaces hardware, and what happens outside office hours? If virtual infrastructure exists, who controls snapshots, backups, firewall policy and customer credentials? These questions decide whether the provider can repair the service or only relay a request to another supplier.

The contract question should cover exit as well as uptime. A provider that is easy to join but hard to leave creates avoidable risk. Customers should require data export, backup handover, DNS transfer, domain transfer, log access and account closure terms. NIST SP 800-146 is useful here because it treats cloud procurement as a portability and contract problem, not only a technology choice. NIST SP 800-145 is also a reminder that cloud services still depend on networks, servers, storage and applications. Those layers have to be named before they can be trusted.

Finally, the buyer should ask how public evidence will be kept current. If AS202019 comes online, who updates route objects, who publishes ROAs, and who monitors route visibility? RIPE NCC's RPKI material explains the route-origin authorization mechanism, and RFC 6811 explains the validation model. A small provider does not need to publish every router detail, but it should be able to explain who owns route changes and how mistakes are corrected. Without that, even a future live route would remain only a partial assurance signal.

The final practical point is timing. A new or reactivated AS can move from dormant to visible quickly, and a public product page can appear before route evidence catches up. That does not mean the first customer should become the test case. A buyer should wait for a stable observation window, repeat route checks over more than one day, confirm that DNS, mail and support channels are separate enough to survive an infrastructure incident, and require a written exit path before storing production data. In a small-provider context, patience is a control.

It lets the customer see whether the provider is building a durable operating surface or only a temporary registry presence. A sensible minimum would be several consecutive days of visible route origin, contact-page availability, external support reachability and a successful non-production restore or export test before any critical service is moved. Anything less leaves the customer funding the provider's first public proof point, with production data at risk before operational responsibility is clear. That risk is avoidable.

The operating read

HOSTING Eric Kelderman trading as Bodega ICT is best read as a RIPE-registered infrastructure identity whose live public network surface has not yet tracked. The AS202019 record is specific and recent, the organisation record names Eric Kelderman trading as Bodega ICT, and the policy lines name intended peers. But RIPEstat does not see the AS announced, does not see current prefixes, does not see neighbours, and shows the IPv6 /48 in whois but not BGP.

The visible domain evidence is equally cautious. bodega.nl is a default hosting page on third-party-looking infrastructure. bodegaict.nl resolves through parked/third-party hosting and Google mail. Those are legitimate identity surfaces, but they do not prove a Bodega-operated hosting platform. They also do not give customers the public contract, support or migration detail needed for critical infrastructure decisions.

For now, Bodega ICT belongs on a monitoring list rather than a provider shortlist. If AS202019 starts announcing prefixes, if a product site appears, or if facility and support evidence becomes public, the assessment should be revisited. Until then, buyers should not infer recoverable hosted capacity from the presence of a clean RIPE entity. Racks, transit and repair windows only become customer protection when they are visible, contracted and tested.