Summary

  • NIUZI DADA CLOUD LIMITED has a public network-resource footprint around AS213436, with RIPE records, BGP.Tools, Hurricane Electric, Ipregistry, and the BTW directory all tying the company name to the autonomous system.
  • The assurance gap is not the absence of a route. It is the gap between routing proof and operating proof: a young UK company record, a live strike-off process at Companies House, thin public support detail, and service claims that are broader than the evidence currently proves.
  • The company should be assessed as an identifiable network operator with limited public verification, not as a mature cloud provider whose name alone establishes resiliency, support depth, or data-locality guarantees.

NIUZI DADA CLOUD LIMITED enters the infrastructure record through a specific and checkable entity: AS213436. The BTW directory records the company as a private company associated with one ASN/IP network resource, naming AS213436 as the visible network identity and listing the alias DADA CLOUD LIMITED. RIPE's aut-num entity gives the same operational anchor. It names AS213436 as NIUZI_DADA_CLOUD, links it to ORG-NDCL2-RIPE, marks the aut-num as assigned, and records creation on February 12, 2025, with later modification on May 7, 2026.

That is the strongest part of the case. A routing identity is harder to fake than a marketing page because it must show up in registries and routing observers. BGP.Tools lists AS213436 as registered to ORG-NDCL2-RIPE, active and allocated under RIPE, with a company website at as213436.uk. Hurricane Electric's BGP Toolkit also identifies AS213436 as NIUZI DADA CLOUD LIMITED, with United Kingdom country-of-origin metadata, observed peer data, originated prefixes, and RPKI-valid origin observations at the time checked. Ipregistry describes the AS as hosting, under RIPE NCC, and shows a mix of IPv4 and IPv6 ranges.

The evidence therefore supports a narrow but useful conclusion: NIUZI DADA CLOUD LIMITED is not just a search-index artifact. It is attached to an ASN, registry entities, and observable routing data. For buyers, researchers, and network peers, that matters. It means the company has crossed at least the first public threshold of infrastructure identity.

The next threshold is higher. Cloud-service assurance depends on continuity, support, route control, abuse handling, and a credible explanation of where service is actually delivered. On those measures, the public record is less complete.

The Companies House record is the first caution. It lists NIUZI DADA CLOUD LIMITED, company number 16144768, as a private limited company incorporated on December 19, 2024. As of the record checked for this article, the status was active with an active proposal to strike off. The filing history shows an application to strike the company off the register filed on June 3, 2026, followed by a first Gazette notice for voluntary strike-off on June 16, 2026. Those entries do not erase the network record, but they make continuity a live due-diligence issue.

If a company is asking to be trusted as an infrastructure operator while its corporate register shows strike-off activity, customers need a direct explanation before treating the brand as stable.

There is also a mismatch between corporate classification and network presentation. Companies House lists the company's nature of business under wholesale clothing and footwear and retail sale via mail order houses or via Internet. RIPE and BGP records, by contrast, place the public technical identity in the hosting and routing world. UK SIC codes can be imprecise or lag behind actual activity, so the mismatch is not proof of misconduct. It is, however, a reason to ask for clearer documentation: what services are being sold, by which legal entity, under what terms, and with which support obligations?

The company's own website narrows that question but does not settle it. The as213436.uk site describes NIUZI DADA CLOUD LIMITED as an operator of AS213436 providing internet infrastructure services, enterprise-grade hosting, globally optimized BGP access, a user-friendly control panel, 24/7 support, and pay-as-you-go billing. Those are recognizable cloud-service claims. They also create an accountability burden. A public page that promises round-the-clock support should make it easy to see how a customer or network abuse desk reaches the operator.

The website did not, on review, display usable NOC, abuse, or technical-support details in its contact panel. RIPE RDAP does expose an abuse contact for the organisation's abuse role, and that is important because abuse reachability is a baseline expectation for routed infrastructure. But RDAP abuse contactability is not the same as a customer support model. It does not prove response times, escalation paths, service-level commitments, data handling controls, or local-language coverage. The public service story remains thin until the company publishes actual operating contacts and terms that match the promises made on the site.

The route data itself also needs careful reading. BGP.Tools shows one originated IPv4 prefix, 23.151.40.0/24, and lists upstreams including WJY Limited and Oracle Cloud in its observed view. Hurricane Electric reports one IPv4 and several IPv6 originated prefixes, all RPKI-originated valid in its view, and observed peers including WJY Limited, Oracle Corporation, FiberState, PebbleHost, and WebHorizon Internet Services. Ipregistry reports one IPv4 range and three IPv6 ranges, with AS62246 as an upstream and no downstream networks.

These views are not identical, which is normal across routing observers, but the shape is consistent: AS213436 is small, visible, and dependent on upstream or peer relationships rather than operating as a broad transit platform.

That has practical consequences. For a hosting customer, an ASN can support better routing control and identity, but it does not by itself guarantee resilience. A small AS with limited observed IPv4 space may still offer useful niche hosting, IPv6 service, lab environments, or region-specific connectivity. It should not be sold or interpreted as a multi-continent infrastructure platform unless the operator can show facilities, upstream diversity, service monitoring, incident history, and customer-facing contracts that support that claim.

The company's website uses broad language about multiple continents and minimal latency; the public routing pack does not yet prove that kind of operational footprint.

The locality question is equally unresolved. The legal entity is registered in the United Kingdom. RIPE organisation data gives a UK country field and a UK address. BGP observers show global routing visibility and, in some cases, prefix descriptions or assignment labels tied to places outside the UK. None of that establishes where customer data is stored, where virtual machines run, which data processors are used, or which jurisdiction governs support and incident handling.

For data-sovereignty buyers, the lesson is simple: country-of-registration, ASN country metadata, and BGP reachability are not a substitute for region commitments in a contract.

This is where NIUZI DADA CLOUD LIMITED is most interesting as a directory subject. The company shows how the internet infrastructure market can create legitimate but lightweight service identities quickly. A legal entity can be incorporated, a RIPE organisation entity can be created, an ASN can be assigned, a website can go live, and routes can appear in public BGP tools within months. That speed is useful for experimentation and specialist providers. It also means the assurance layer must be built deliberately, because the presence of an ASN can look more mature than the organisation behind it.

The name should therefore be treated as evidence of network-resource operation, not as a finished answer to trust. The credible part is the link between NIUZI DADA CLOUD LIMITED and AS213436. The weak part is the operating record around it: corporate continuity is clouded by strike-off filings, the official business classifications do not obviously match a cloud provider, the website's support presentation is incomplete, and public routing evidence shows a modest footprint.

That is still useful for monitoring. A small AS with current registry and BGP evidence can become more credible quickly if the company resolves the corporate-status question and publishes operational terms that match the network record. Until then, the right treatment is conditional: visible enough to track, narrow enough to verify, and not mature enough for the ASN to stand in for customer assurance.

For counterparties, the checklist is straightforward. Ask the company to confirm the status of the strike-off process and whether the entity will continue to contract for infrastructure services. Ask for current service terms, NOC and abuse escalation paths, support hours, data-location options, upstream arrangements, RPKI/IRR maintenance practices, and a clear map of which prefixes and regions are actually used for customer workloads. Ask whether Oracle Cloud or other named upstream and peer relationships are direct service dependencies, routing adjacencies, or observer-specific path evidence.

The answers matter more than the marketing nouns.

For the directory, the fair classification is narrower. NIUZI DADA CLOUD LIMITED is a visible network operator associated with AS213436 and a small public routing footprint. It may be building cloud or hosting services, and its own site says as much. But public assurance is still catching up with public identity. Until the company resolves the corporate-status question and publishes support, locality, and service-proof details commensurate with its claims, the safest reading is not "unproven" in the sense of invisible. It is "visible, but not yet fully accountable."