Summary

  • AS2042's APNIC registration carries self-asserted description lines marketing "HK Global Cloud DataCenter," "multimedia pacific limited," and a service catalogue spanning dedicated servers, VPN, CDN, MPLS, IPL, disaster recovery, and "Cloud, OpenStack, Vmware" under organisation ORG-ZL4-AP (zhelet limited); the object was last modified on 2020-05-12. https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS2042
  • Observable routing shows a very different footprint: 12 IPv4 prefixes and zero IPv6, roughly 4,096 IPv4 addresses, and only two BGP neighbours — AS3491 (PCCW Global) and AS18186 (Nebula Global LLC) — both classified as providers, with zero customers and zero settlement-free peers. https://bgp.he.net/AS2042
  • Multiple independent views agree on the shape: bgp.tools lists a single upstream (AS3491) and classifies the network type as "Content"; the CIDR Report's AS6447 view shows one upstream, no downstream customers, and heavy self-prepending in observed AS paths. https://bgp.tools/as/2042
  • Routing hygiene is weak on the evidence available: Hurricane Electric classifies 7 of AS2042's originated prefixes as RPKI invalid and only 2 as valid, and flags bogon-prefix announcements; bgpthingy shows ROAs published for 103.235.172.0/22 and 150.242.216.0/22 under the APNIC trust anchor. https://bgp.he.net/AS2042
  • The concrete hosting footprint is small but real: IPinfo classifies AS2042 as a Hosting-type network, reports roughly 540 domain names hosted across about 57 IP addresses, and shows in-region Hong Kong latency around 1.5 ms on 150.242.216.0/22 — whose APNIC inetnum names the Kwai Chung address of record. https://ipinfo.io/AS2042
  • The honest evidentiary line: everything reproducible from BGP, RPKI, peering records and DNS/hosting footprint is deployed evidence; the cloud, CDN and disaster-recovery capability advertised in registry text remains a claim that no public document examined here verifies.

Two Registers, One Network

Network operators leave two kinds of public records, and they are not equivalent. The first is a registry object: free-form text that the registrant writes about itself, held in a regional internet registry database. The second is operational state: the prefixes a network originates, the neighbours it exchanges routes with, the cryptographic attestations it publishes, and the hosts that answer on its address space. The first is a claim. The second is evidence.

For AS2042, the registry record is unusually explicit about ambition. The APNIC whois aut-num object lists as-name "GCT-HK" and description lines that read like a full-service infrastructure brochure: "HK Global Cloud DataCenter," "Global Cloud DataCenter," "Dedicated Server, Virtual Private Server VPN, CDN, MPLS, IPL," "Disaster Recovery," and "Cloud, OpenStack, Vmware." The same object also carries the line "multimedia pacific limited" — a second company name in the same description set, with no public document examined here explaining the relationship between the two names. The organisation handle is ORG-ZL4-AP, registered to zhelet limited; the maintainer and IRT objects are MAINT-ZHELETLIMITED-HK and IRT-ZHELETLIMITED-HK. The record was last modified on 2020-05-12T16:52:58Z — more than six years before this analysis, meaning the marketed positioning has persisted, unedited, for over six years. https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS2042 The same registration is also retrievable in machine-readable form via https://rdap.org/autnum/2042, an access method documented by APNIC at https://whois.ipip.net/AS2042, and it is mirrored in third-party whois views such as https://ipinfo.io/AS2042 and https://whois.ipip.net/AS2042.

None of that text is verified by anyone. Registry description fields have no deployment audit. They cost nothing to write, they persist until someone edits them, and readers who encounter them in whois output have no way to distinguish a brochure from a build-out. That is not a flaw in APNIC's data model — the registry records authorisation to operate number resources, not product capabilities — but it does mean the description is the weakest form of evidence a network offers about itself.

The operational record is stronger precisely because the operator cannot edit it directly. What the routing system shows for AS2042 is small, single-homed and IPv4-only.

What the Routing System Actually Shows

Start with scale. Hurricane Electric's AS view reports AS2042 originating 12 IPv4 prefixes and zero IPv6 prefixes, totalling roughly 4,096 IPv4 addresses, with two observed BGP peers: AS3491 (PCCW Global) and AS18186 (Nebula Global LLC). https://bgp.he.net/AS2042 A 4,096-address footprint is roughly sixteen /24s. For comparison, a mid-sized regional hosting provider typically originates hundreds of times that space, and a genuine cloud platform announces gigabytes of address space across dozens of points of presence. Nothing in the observable footprint resembles the latter.

Independent vantage points agree on the topology even where they disagree on counts. bgp.tools lists seven visible originated prefixes — 14 /24-equivalents — with a single upstream, AS3491 PCCW Global (HK) Ltd., and classifies the network type as "Content" rather than datacenter, cloud or hosting. It dates the current registration to 13 October 2016, assigned to zhelet limited under APNIC, and ranks the network around #119 in Hong Kong for originated IPv4 space — a regional ranking consistent with a small operator. https://bgp.tools/as/2042

The CIDR Report's view from the AS6447 collection point is blunter still. It shows an adjacency of exactly one: a single upstream adjacent AS, no downstream customers, roughly 3,584 addresses across seven currently announced prefixes, and observed AS paths of the form "7018 3491 2042 2042 2042 2042" — a single-homed network prepending its own ASN four times, a configuration pattern usually associated with either traffic engineering on one link or simply with very small operators that never tuned their announcements. https://www.cidr-report.org/cgi-bin/as-report?as=AS2042&view=6447

The neighbour structure is the most decisive datapoint. bgpthingy classifies both of AS2042's IPv4 neighbours as providers: zero customers, zero settlement-free peers, zero IPv6 neighbours. It also states the network does not participate in any known internet exchange point. https://bgpthingy.xindi.eu/asn/2042 This matters because interconnection is the one thing a datacenter or cloud operator cannot fake in registry text and cannot avoid building in the real world. A cloud platform's value proposition — low-latency delivery, redundancy, geographic distribution — is physically expressed as peering sessions, IXP ports and customer ASNs. AS2042's public interconnection estate consists of two provider relationships and, on current aggregator views, nothing else.

Routing Hygiene: The Weakest Signal

If the scale is small, the hygiene is weaker. Hurricane Electric classifies seven of AS2042's originated prefixes as RPKI invalid and only two as valid, and flags that the network announces bogon prefixes — address space that should never appear in the global routing table. https://bgp.he.net/AS2042 RPKI invalid means the origin claim on the route contradicts a published Route Origin Authorisation: either the prefix lacks a ROA covering its current origin, or a stale or wrong ROA exists. For a network marketing itself as a cloud and CDN provider, seven of twelve prefixes failing origin validation is not a rounding error; it is a signal that the operator's routing-security practice has not kept pace with even its own announcements.

bgpthingy's view partially corroborates intent: it shows ROAs published under the APNIC trust anchor for 103.235.172.0/22 and 150.242.216.0/22, so the operator has engaged with RPKI — but the validity window shown in that capture (late August to early September 2026) and the seven-invalid count together suggest partial, uneven coverage rather than a maintained attestation estate. https://bgpthingy.xindi.eu/asn/2042 Whisper Security's reputation page reports roughly 14 of the announced 4,096 IPv4 addresses appearing on threat feeds, but presents two different reputation scores (16.2 and 57.5) in the same capture — internally inconsistent vendor scoring that should be treated as weak signal at best. https://canon.whisper.security/asn/2042

One further complication deserves its own paragraph. Several prefixes AS2042 originates carry registration descriptions naming third parties: CNISP-Union Technology (Beijing) Co., Ltd, Dongguan JUXUN Network Technology Co., Ltd, and QY NETWORK MAOMING CO.LTD. And ipgeolocation.io attributes 103.30.200.0/23 to AS133115 (HK Kwaifong Group Limited) rather than AS2042. https://ipgeolocation.io/browse/asn/AS2042 Aggregator prefix-origin attribution is inconsistent and time-varying — Hurricane Electric's own counters drifted between captures (756 versus 759 observed AS paths) — so none of these attributions is individually conclusive. The primary-source check they call for is at least reproducible in one step: the captured APNIC whois query for AS133549 https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS133549 shows how the registry objects behind such attributions can be pulled and compared directly. But the pattern raises the question of what AS2042 actually controls: whether the third-party-named space reflects sub-allocation, route leasing — a known market in post-exhaustion IPv4 — or simple misattribution by aggregators. Public evidence examined here cannot settle that, and the article does not pretend otherwise.

The Hosting Footprint That Does Exist

Strip away the cloud brochure and something real remains. IPinfo classifies AS2042 as a Hosting-type network, and its prefix pages reproduce the APNIC inetnum for 150.242.216.0–150.242.219.255: netname ZHELETLIMITED-HK, status ALLOCATED PORTABLE, descriptive address "UNIT 2 7/F TRANS ASIA CTR 18 KIN HONG ST KWAI CHUNG NT" — Unit 2, 7th Floor, Trans Asia Centre, 18 Kin Hong Street, Kwai Chung, New Territories, Hong Kong. The route object for 150.242.216.0/22 with origin AS2042 was last modified 2024-08-15, so this block is actively maintained. IPinfo reports roughly 540 domain names hosted across about 57 IP addresses on the ASN, with hosts in 150.242.216.0/22 answering from Hong Kong at approximately 1.4–1.6 ms in-region latency. https://ipinfo.io/AS2042

That is a coherent picture of a small Hong Kong hosting operation: one suite in a Kwai Chung commercial building, a couple of /22s of address space, a few dozen IPs serving a few hundred domains, latency consistent with in-region hosting. As a hosting business, it may be perfectly adequate for its customers. As evidence for a "Global Cloud DataCenter" with OpenStack, VMware, CDN, MPLS and disaster-recovery capability, it is not remotely sufficient — and the gap between those two readings is the article's finding.

Even the address counts disagree in ways that matter for precision. Hurricane Electric reports roughly 4,096 originated IPv4 addresses; IPinfo's truncated figures suggest 3,072; the CIDR Report's AS6447 view shows about 3,584 across seven prefixes. These are different observation points with different visibility, and the variance itself is informative: a network whose visible footprint shifts by a /21 depending on where you look is not running the kind of anycast, multi-PoP estate that makes such variance disappear. https://bgp.he.net/AS2042

Registry Chronology, Properly Read

Two dates circulate for AS2042 and they mean different things. ARIN's registry shows the number as "APNIC-2042," registered 2002-07-31 and last updated 2009-10-08, with an explicit comment that AS2042 is not registered in the ARIN database and that queries belong in APNIC whois. https://whois.arin.net/rest/asn/AS2042 That 2002 date is the IANA/ARIN-era allocation of the number block — a fact about the resource, not the operator. Aggregators date the current assignment to zhelet limited to 2016-10-13. https://bgp.tools/as/2042 Conflating the two would make the network look two decades older and more established than its observable footprint supports. The correct reading: the number is old, the operator's use of it is about a decade old, and the description text advertising a cloud platform has been sitting unmodified since May 2020. https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS2042

The contact layer reinforces how thin the public identity is. Admin and technical contact is "zhelet limited administrator" with a Gmail abuse mailbox and a Hong Kong mobile number; abuse handling routes through IRT-ZHELETLIMITED-HK, whose address APNIC remarks as validated on 2026-08-11. https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS2042 A PeeringDB-sourced row supplies a public interconnection record — including a placeholder-looking phone number, 1458 1458 1458 — which suggests the interconnection listing exists to satisfy a data requirement rather than to conduct peering business. None of this is proof of anything improper; it is proof that the public identity of this network is registry-shaped, not operations-shaped.

What Would Change the Assessment

The finding here is bounded, and the boundary is testable. If HK Global Cloud DataCenter were what its registry description claims, four things would be observable, and none currently is:

  1. Multi-homing or IXP presence. A cloud or CDN provider announces from multiple locations and typically peers settlement-free at exchanges. AS2042 shows one upstream, two provider-classified neighbours, zero customers, zero settlement-free peers and no known IXP participation. https://bgpthingy.xindi.eu/asn/2042
  2. IPv6. Every credible cloud platform is dual-stack. AS2042 originates zero IPv6 prefixes across every source examined. https://bgp.he.net/AS2042
  3. Routing hygiene. Seven of twelve prefixes RPKI-invalid plus a bogon-announcement flag is incompatible with the operational discipline that CDN and disaster-recovery services require. https://bgp.he.net/AS2042
  4. Facility evidence. No public document examined here — registry records, aggregator pages, or the directory dossier — names an owned or leased datacenter facility, an OpenStack or VMware deployment, or a tested DR capability beyond the description line asserting them.

Conversely, the counterfactual is easy to state: if the operator published ROAs covering all originated space, added a second upstream, joined an IXP, deployed IPv6 and documented a physical facility, the marketed catalogue would become substantially corroborated and this article's gap would narrow to documentation quality. The assessment tracks evidence, not the operator.

Source notes

The APNIC whois object for the related resource AS133549, captured for this analysis, is retrievable at https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS133549; APNIC documents machine-readable registry access via RDAP at https://whois.ipip.net/AS2042. The direct APNIC whois query for the associated resource AS133549 is reproduced at https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS133549, and APNIC documents RDAP-based registry access at https://www.apnic.net/about-apnic/whois_search/about/rdap/.