Summary

  • RIPE registry records name csoft Cloud Software - FZCO, a Dubai Silicon Oasis free-zone company at IFZA Business Park with registration number 45644, as the organisation behind autonomous system AS211273, whose aut-num object carries the as-name "csoft" and was created on 2026-01-21.
  • The ASN originates approximately 50 IPv4 prefixes covering 12,800 addresses and zero IPv6, with transit and peering relationships that include Hurricane Electric, Cogent, GTT, RETN, Versija SIA, WholeSale Internet, FBW Networks and ADCDATA.COM.
  • Registry-declared fields — the hostvds.com website and its abuse mailbox in the RIPE objects, a support mailbox at the same domain, and a named technical contact Sergei Chekanov attached to a team mailbox at hostvds.com — tie the network entity to the HostVDS hosting brand, whose own terms name CGI Global Limited of Hong Kong as the contracting entity.
  • Third-party profiles describe a Hong Kong head office under CGI Global Limited and a Dubai branch under Cloud Software - FZCO; PeeringDB independently lists CGI Global Limited with the hostvds.com website. The same RIPE organisation also holds a second autonomous system, AS218764, registered as "finland_cloud".
  • The aut-num object was edited repeatedly during 2026: a July 2026 snapshot shows a Hong Kong LIR maintainer with placeholder contacts; by September 2026 the contact objects had been replaced. Address space announced by the ASN is attributed in routing datasets to several third-party infrastructure providers, indicating leased and sourced prefixes rather than owned allocations.

Anyone tracing the operator behind AS211273 starts with the same sparse footprint: an autonomous system allocated in January 2026, a name that reads like an abbreviation, and no corporate website of its own. The registry fills in most of the picture. The RIPE aut-num object for AS211273 carries the as-name "csoft" under organisation ORG-CSF5-RIPE, whose org-name is "Cloud Software - FZCO", with the sponsoring organisation recorded as ORG-CGL23-RIPE and the object status ASSIGNED, created 2026-01-21 (3, 6). A separate RIPE organisation object gives the postal reality: IFZA Business Park, DDP, Dubai Silicon Oasis, Dubai, country AE, registration number 45644, organisation type OTHER, created 2026-01-15 (4, 7). IFZA — the International Free Zone Authority — is one of Dubai's free-zone registries, and a free-zone establishment (FZCO is the two-to-five-shareholder variant) is a common vehicle for internationally trading companies that want Dubai domicile with light domestic footprint. Nothing here contradicts that reading; nothing independently confirms it either, because no corporate registry page outside the RIPE mirrors has been verified.

The organisation's declared contact points are the first thread that ties the network to a brand. The org contact e-mail recorded in RIPE mirrors is a support mailbox at hostvds.com, and the abuse contact is an abuse mailbox at the same domain (4). Third-party ASN directories attribute hostvds.com as the AS211273 website and classify the ASN as hosting-type (5). HostVDS, for its part, describes itself on its about page as an "international cloud provider" renting server capacity on OpenStack-based Cloud VDS infrastructure with Elastic Volumes, with data centres listed in the United States, France, Finland, Latvia, Hong Kong and the Netherlands (0). Notably, that self-description does not name Cloud Software - FZCO at all. The linkage runs the other way: through registry fields, through a named person, and through third-party aggregation.

The named person is Sergei Chekanov, listed in the RIPE person object SC28114-RIPE with a team mailbox at hostvds.com, attached to the netblock 46.8.100.0 - 46.8.103.255, netname CLOUD-SOFTWARE, an ASSIGNED PA block held by ORG-CSF5-RIPE and created on 2026-05-20 (2). That block is the smallest of the ASN's announced ranges — four /24s inside a /22 — but it is the one whose documentation most directly ties a human contact, a hostvds.com mailbox, and the Dubai entity's address space into a single object. Chekanov's role beyond this contact record is not established by public evidence; the name appears in registry objects, not in any published executive listing, and this article treats it accordingly.

The HostVDS terms of service complete the corporate picture from the brand side. They define "HostVDS", "us", "we" and "our" as collectively referring to CGI Global Limited, a corporation organised under the laws of the Hong Kong Special Administrative Region, located at Unit 2A, 17/F, Glenealy Tower, No.1 Glenealy Central, Hong Kong (6). PeeringDB independently records organisation 24048 as "CGI GLOBAL LIMITED" with the website hostvds.com and the same Glenealy Tower address (9). WHTop's review of the host goes further, describing an international structure with a Hong Kong head office under CGI GLOBAL LIMITED and a Dubai branch under CLOUD SOFTWARE - FZCO at the IFZA Business Park address (5). WHTop is an aggregator and its structural claims are not independently verified, but the pattern it describes is exactly what the primary records show: two entities, one in Hong Kong appearing as the service's contracting party and PeeringDB identity, one in Dubai appearing as the RIPE network organisation — with the same hostvds.com contact mailboxes running through both.

The scale of the network is modest by routing-table standards but not trivial. AS211273 originates approximately 50 IPv4 prefixes totalling 12,800 IPv4 addresses, with zero IPv6 announced; enumerations include /24s in 45.38.x.x and 45.39.x.x, the 46.8.100.0 through 46.8.103.255 blocks, and 95.182.80-87.0/24 ranges (6, 4). WhisperGraph counts 48 routed prefixes; Qrator, ipapi and IPGeolocation count around 50 IPv4 routes; CIDR-Report attributes roughly 6,400 originated addresses to the ASN. Any description of the network as announcing no prefixes would be flatly wrong, and indeed one third-party profile that made that claim is contradicted by every BGP dataset examined here.

Transit is multi-homed. The registered routing policy in the aut-num object imports from AS6939 (Hurricane Electric), AS174 (Cogent) and AS3257 (GTT) with accept ANY, and exports AS211273 to the same three (0). Peer and upstream listings across directories additionally include AS286 (GTT), AS8285 (Versija SIA), AS9002 (RETN Limited), AS32097 (WholeSale Internet), AS49434 (FBW Networks) and AS135330 (ADCDATA.COM), with IPinfo counting 8 peers and 7 upstreams (5). This is the standard play for a hosting network of this size: buy transit from at least one tier-1 (GTT and Cogent appear in the registered policy), reach a large slice of the table cheaply through a tier-2 like Hurricane Electric, and fill in regional connectivity through smaller providers.

The composition of the announced prefixes is the more interesting structural fact. Routing datasets attribute several prefixes announced under AS211273 to third-party infrastructure operators: 104.252.30.0/24 and 45.38.198.0/24 to Subnet Digital LLC, 104.253.175.0/24 to EGIHosting, 104.253.25.0/24 to Wei Pu Website Services Ltd (0). That pattern — /24s whose whois lineage points at American hosting and address brokers, announced by a Dubai entity — is the signature of leased address space. IPv4 has been scarce enough for years that leasing blocks through brokers is a mature market, and hosting companies that grew into the address shortage routinely assemble their footprint this way. The 12,800-address total for a company that claims thousands of hosted domains is consistent with a network built from leased /24s rather than legacy allocations.

IPinfo's scan data suggests the space is in use: the directory reports 2,028 hosted domains across 1,089 IP addresses in AS211273 space, and live responding addresses including 95.182.84.111, 45.38.198.1, 104.253.134.1 and 46.8.100.1 (5). A ratio of roughly two domains per live responding address is typical of small hosting footnotes — shared hosting on /24s, virtualisation customers, and infrastructure addresses that respond to probes. The same directory lists the ASN type as Hosting, which is the classification a network operator would choose for itself in that ecosystem.

The record trail through 2026 shows an operation assembling itself in stages. The organisation object was created 2026-01-15; the aut-num followed on 2026-01-21. The 46.8.100.0/22 inetnum appeared on 2026-05-20. A July 2026 snapshot of the aut-num preserved by Qrator shows the object still carrying the maintainer lir-hk-cgiglobal-1-MNT — a maintainer handle naming CGI Global, the Hong Kong company, in a LIR-context role — with placeholder DUMY-RIPE admin and technical contacts (0). By the 2026-09-02 revision mirrored elsewhere, the contact objects had been replaced with TA9941-RIPE (a role object named "team" using the abuse mailbox at hostvds.com) and maintained under CS-TEAM-MNT (4, 0). Read together, the snapshots show a resource administered through a Hong Kong LIR relationship in mid-2026 migrating to self-managed contact objects by September — precisely the sequence an operator would follow after taking over administration of its resources from a sponsoring LIR or restructuring its registry representation.

The sponsoring-organisation lineage itself deserves attention. The aut-num names ORG-CGL23-RIPE as sponsoring org — the same CGL initialism that appears in the Hong Kong LIR maintainer handle. In RIPE's model, an end-user organisation without LIR membership obtains resources through a sponsoring LIR, which is a common and legitimate route for small operators that do not want the overhead of direct membership.

What the trail here shows is how that arrangement works in practice: a Hong Kong contracting company sits in the LIR position, a Dubai free-zone entity is the resource-holding organisation, and the two are joined by shared mailboxes and shared branding rather than by any published ownership statement. The public record establishes the linkage; it does not establish the corporate hierarchy behind it.

One genuine cross-source contradiction remains unresolved. A Check-Host page citing CAIDA's AS-Relationships dataset claims AS211273 has no upstream transit provider; Qrator, IPinfo and BigDataCloud all list multiple transit providers, and the aut-num's own registered policy names three. CAIDA's AS-relationship inference is a model-derived dataset, not a direct observation, and it is known to under-detect transit for small networks with limited visibility.

The correct editorial treatment is attribution, not adjudication: one inference dataset says one thing, direct routing observations and the operator's own declared policy say another, and the discrepancy is itself informative about the limits of inferred topology data.

The same organisation also holds a second autonomous system. AS218764 carries the as-name "finland_cloud" and is registered under ORG-CSF5-RIPE with a support mailbox at hostvds.com as the contact (3, 4). The NERD entity record, added 2026-02-20, associates ORG-CSF5-RIPE with AS211273 (7); the second ASN's allocation is newer. A "finland_cloud" as-name under a Dubai organisation whose brand lists data centres in Finland and Latvia is consistent with a second regional presence being assembled — the same playbook, another country, another ASN.

What does this all add up to? Not a scandal and not a mystery, but a clear illustration of how the small end of the hosting market operates. A company serving customers worldwide does not need offices in the countries it serves; it needs a legal entity that gives it a credible domicile (Dubai free zone), a registry identity that lets it obtain routing resources (RIPE via a sponsoring LIR), enough leased IPv4 to host its customers (assembled from brokers' blocks), and transit contracts with a handful of upstreams (GTT, Cogent, Hurricane Electric).

Every piece of that assembly is visible in public records if someone reads them together — and in this case, the pieces connect with unusual cleanliness: the same mailboxes, the same addresses, the same initialisms recur across RIPE objects, HostVDS's own terms, PeeringDB and third-party profiles.

The evidence boundary is equally clear. No published record states that CGI Global Limited owns Cloud Software - FZCO, or vice versa; the relationship is established by shared contact points, a shared maintainer lineage and a third-party structural description. No verified customer numbers, revenue figures or staffing exist. Sergei Chekanov is a registry contact, not a confirmed executive. And the company's own about page — the one place a reader might expect the corporate identity to be spelled out — names none of it.

The registry trail is the only authoritative account of who runs AS211273, which is precisely why it is worth reading closely.