RAC DATACENTER AND CLOUD SERVICES OPC PRIVATE LIMITED has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• RAC has concrete registry evidence: APNIC's AS150652 RDAP record and 103.84.196.0/23 RDAP record identify RAC DATACENTER AND CLOUD SERVICES OPC PRIVATE LIMITED, RACDCSOPL-AS-IN and a Tamil Nadu contact address.
• The current network evidence is negative rather than merely thin. RIPEstat's AS overview marked AS150652 as not announced on July 12, 2026, and its routing-status view showed zero visible IPv4 prefixes, zero visible IPv6 prefixes and zero observed neighbours.
• The IPv4 block has route-security preparation at the /24 level: RIPEstat returned valid RPKI status for 103.84.196.0/24 and 103.84.197.0/24, but the broader /23 query returned unknown and none of the checked prefixes was globally routed.
• RAC's public web surface does not close the operating gap. The racdcs.com HTTP page displayed a "coming soon" domain page served through Yuva Networks, while certificate-transparency records show domain certificates but not a customer portal, status page, facility specification or service catalogue.
• RAC-branded data-centre rental marketing should be treated as a separate market signal unless contracts or disclosures tie it to this OPC entity. Buyers need proof of facility ownership or colocation rights, power and cooling design, carrier diversity, support hours, maintenance process and customer failover before relying on any marketed data-centre capacity.

The public record starts with assigned resources, not a working edge

RAC is not a name invented by a reseller page. It appears in APNIC registry data as a holder of Internet number resources. The APNIC RDAP record for AS150652 lists the AS name as RACDCSOPL-AS-IN, gives the country as India, marks the status active, records initial registration in February 2023, and describes the resource holder as RAC DATACENTER AND CLOUD SERVICES OPC PRIVATE LIMITED. The APNIC RDAP record for 103.84.196.0 shows a 103.84.196.0/23 allocation, also under RACDCSOPL, with the same company description.

That is the strongest floor under the profile. A company that holds an autonomous-system number and a /23 IPv4 block can build a public network edge, originate customer addresses, operate a small hosting environment, or prepare for a future data-centre or colocation service. The APNIC data also ties the record to a Rajapalayam, Tamil Nadu address, which gives the company a more specific geography than many low-information infrastructure names. Public corporate-data services such as Tofler and InstaFinancials likewise identify the company as an Indian OPC registered in Tamil Nadu, though those aggregators should be treated as secondary context rather than registry authority for routing.

The problem is that number-resource ownership is not the same as routed capacity. On July 12, 2026, RIPEstat's AS overview identified the holder as RACDCSOPL-AS-IN but marked the AS as not announced. RIPEstat routing status showed zero RIS peers seeing IPv4 or IPv6 routes, zero announced space and zero observed neighbours. RIPEstat announced prefixes returned an empty prefix list for the recent observation window. BGP.tools reached the same public conclusion in plainer language: AS150652 was not currently in the global routing table and originated zero IPv4 and zero IPv6 prefixes.

That changes the grade immediately. RAC is not comparable to a small data-centre ASN with one prefix, one upstream and an incomplete facility story. It is earlier, or quieter, than that. The company has assigned resources and route-origin authorization for the two component /24s, but the public edge is not visible. If RAC is operating customer workloads today, the public evidence does not show them behind AS150652. They may be behind another provider's addresses, in a leased facility, in a private lab, in a non-public environment, or not yet live. Each of those possibilities has a different risk model.

None allows a buyer to treat the company name as proof of resilient data-centre service.

A dormant AS is not a small footnote

In data-centre research, a dormant AS is more than a missing statistic. It is a sign that the public control plane is either not yet active or not being used for the services under review. A data centre can exist without its own AS if it sells space, power and remote hands while customers bring their own transit. A cloud or hosting provider can operate on upstream-provider address space without originating its own routes. But a company that holds an AS and a /23 while publishing no visible route through that AS has to explain where the customer-facing edge actually is.

The direct route tests are blunt. RIPEstat prefix overview for 103.84.196.0/23 returned not announced, with no originating ASN. The same was true for 103.84.196.0/24 and 103.84.197.0/24. RIPEstat routing history returned no origin history for AS150652 in its view, and RIPEstat prefix count showed zero IPv4 and zero IPv6 address space in the sampled history.

That does not mean RAC is inactive as a legal company or that it cannot become an operator. It means the public Internet has not seen the network behave like one in the checked sources. If the AS is reserved for launch, the operating question becomes launch readiness: carrier contracts, route filters, RPKI, router configuration, DDoS plan, customer migration and monitoring. If the company uses upstream space instead, the question becomes transparency: who owns the customer IPs, who handles abuse reports, how failover works, and whether RAC can move customers during a provider outage.

If the resources are held for a future facility, the question becomes whether the announced capacity is sold before the network is ready.

A dormant AS can be harmless when a company is honest about it. It becomes risky when marketing, procurement language or customer assumptions make it sound like a live data-centre network. The customer does not suffer because an ASN is dormant in the abstract. The customer suffers when a sales claim suggests resilient capacity but the actual path depends on one unnamed upstream, a not-yet-commissioned rack row, or a provider block that RAC cannot control during a dispute or outage.

The Rajapalayam address is useful but not facility proof

The APNIC RDAP records give RAC a concrete address in Rajapalayam, Tamil Nadu. Third-party IP intelligence also points the block toward that geography: IPinfo's lookup for 103.84.196.90 and 103.84.196.241 placed those test addresses in Rajapalayam, Tamil Nadu. RIPEstat geolocation placed the prefix in India at the country level. Those are useful hints, especially because they line up with the APNIC contact geography.

They do not identify a data-centre facility. Registered office, billing contact, NOC contact, director address and actual server room can all be different. A company in Rajapalayam could run equipment in Rajapalayam, lease space in Chennai, buy managed hosting in Mumbai, rent a cabinet in another Indian metro, or use a partner's servers while owning the customer relationship. The public record reviewed here does not name a building, a rack room, a colocation provider, a power contract, a fibre entrance or a carrier meet-me location for RAC.

That distinction matters because data-centre risk is local. If production equipment is in Rajapalayam, the resilience review has to ask about local utility feeds, generator fuel logistics, summer heat, remote hands, spare-parts access and fibre backhaul from a smaller city. If equipment is in Chennai, the review has to ask which Chennai facility, whether RAC controls the cabinet, which carriers are present, and how RAC customers are separated from the facility operator's own obligations. If equipment is in another provider's cloud, the review has to ask why the company name and number resources imply a data-centre business at all.

Tamil Nadu is a serious data-centre market, but that does not make every Tamil Nadu data-centre name an operating site. The state's Data Centre Policy 2021 treats data centres as investment infrastructure and discusses issues such as power, land, incentives and connectivity. That policy context is relevant because it explains why companies would pursue data-centre positioning in the state. It does not establish RAC's installed capacity or location. A policy can make the market attractive; only site-specific evidence can make a customer workload safe.

Tamil Nadu policy support is not the same as RAC capacity

The Tamil Nadu policy environment is useful background because data centres consume power, land, fibre and operational labour at a scale that ordinary software companies do not. The state policy discusses data-centre facilitation, electricity access, connectivity and incentives. Investment-promotion material from Investing in Tamil Nadu points to the same policy framework. The state is trying to make data-centre investment administratively legible.

That helps explain the opportunity but not the operating status. A data-centre company can be incorporated in a state with favourable policy and still face site-specific barriers: last-mile power availability, transformer upgrades, fuel storage, building approvals, fire clearance, cooling design, customer fit-out, carrier entry and staffing. The more a project sits outside established metro colocation clusters, the more those questions matter. Rajapalayam may be a valid operating base for a local or regional provider, but public sources do not show whether RAC has built or leased the plant required for resilient hosting there.

National context points in the same direction. The Ministry of Electronics and Information Technology's draft Data Centre Policy framed data centres around reliable power, fibre connectivity, environmental clearances, security and economic infrastructure. The CEEW study on India's data-centre ecosystem treats power and water use as central questions for the sector. These sources support the method of analysis: the article is not judging RAC by whether it has a website slogan, but by whether it can show the physical inputs that make data-centre promises credible.

For RAC, the policy conclusion is conservative. A Tamil Nadu registration and APNIC allocation place the company in a real market, with real demand and a plausible development path. They do not prove an energized rack, a cooled hall, a carrier-neutral meet-me room, a second utility feed or a tested failover plan. Customers should treat policy support as macro context and require facility evidence before treating any RAC capacity as production-grade.

The public web front door is weak evidence

RAC's own domain is another reason to downgrade operating confidence. The APNIC contact record uses racdcs.com email addresses, which makes the domain relevant to the company identity. But the public HTTP site at racdcs.com displayed a generic "coming soon" domain page with a link to Yuva Networks' server control panel. DNS checks also resolved racdcs.com and www.racdcs.com to the same A record and used Yuva Networks name servers. Certificate Transparency records at crt.sh show GoDaddy certificates issued for racdcs.com and www.racdcs.com in 2024 and 2025, so the domain is not simply abandoned. Still, the visible site does not present a service catalogue, data-centre location, support desk, status page, customer portal, incident history or SLA.

A small infrastructure company can sell by relationship and still operate well. Absence of a polished site is not proof of absence of equipment. But a data-centre buyer has to interpret the web surface alongside the route surface. Here, both are quiet. The AS is not globally announced; the prefix is not globally routed; PeeringDB has no network entity for the ASN; and the company domain is a default page rather than an operating manual. Those facts stack in the same direction.

The missing web details are not marketing decoration. A customer needs to know which services are offered: bare metal, colocation, VPS, managed hosting, disaster recovery, backup, private cloud, rack rental or only equipment rental. It needs access policies, maintenance windows, abuse contacts, escalation path, accepted-use rules, backup and export procedures, and clarity on who controls the IP addresses. Without those, the customer is left to infer a data-centre business from the company name and registry records. That is too thin for production trust.

There is also a security and recovery reason to care. During an outage, a domain that hosts a status page, contact route and customer documentation becomes part of the recovery system. A default landing page cannot carry that burden. If RAC serves customers through private channels, the company should make sure those channels are documented before failure, not improvised after a rack, route or utility event.

The /23 is capacity only after it is routed, monitored and supported

The IPv4 allocation is real and useful. A /23 is 512 IPv4 addresses before network reservations, routers, management interfaces, NAT pools, monitoring, DNS, hypervisors, customer subnets and abuse isolation. For a small data-centre or hosting provider, that can support a meaningful first platform. It can be enough for customer VPNs, small VPS pools, management services, leased servers, firewalls or a local cloud edge.

But the allocation does not become customer capacity by existing in APNIC. First, it has to be originated by an AS or carried by a provider under a design the customer can understand. Second, the route has to be monitored across collectors and customer geographies. Third, route-origin authorization, IRR data, filters and DDoS handling have to be in place. Fourth, the address plan has to map to physical equipment that can be powered, cooled and repaired. Fifth, abuse and reverse-DNS processes have to work well enough that one customer's problem does not damage other customers' reachability.

RAC has some preparation on the route-security side. RIPEstat's RPKI validation returned valid status for 103.84.196.0/24 and 103.84.197.0/24, both with AS150652 as the origin. That is better than an address block with no visible route-origin hygiene. It suggests someone prepared ROAs for the two routable /24 components that the Internet is most likely to accept. However, the 103.84.196.0/23 RPKI query returned unknown, and the checked route collectors still saw no route.

That split is important. RPKI says the planned origin is authorized for the tested /24s. It does not say the routers are configured, the upstream accepts the routes, the links are installed, the facility is live, or customers are reachable. A buyer should read the valid ROAs as a positive readiness sign, not as operating proof. The next proof is boring and public: the /24s should appear in BGP, under AS150652 or a clearly disclosed provider arrangement, with stable visibility and named upstreams.

Carrier diversity has to be shown, not guessed

Carrier evidence is currently absent from public routing. RIPEstat ASN neighbours returned zero observed neighbours for AS150652 in the checked view. RIPEstat looking glass for 103.84.196.0/23 returned no route collectors for the prefix. PeeringDB's query for AS150652 returned no network entity. Again, PeeringDB is voluntary and route collectors have limits, but the direction is consistent: no public carrier map is available.

This is the central difference between assigned resources and data-centre resilience. A data centre can run servers all day on local networks, but customer-facing service depends on carrier entry, cross-connects, routers, DDoS handling, route policy and operations contacts. If a single provider carries all traffic, the data centre inherits that provider's maintenance windows, filtering decisions, contract risk and outage path. If multiple providers are present but they enter through the same duct, terminate in the same rack, or share one power path, apparent diversity can collapse under one physical fault.

For RAC, the first carrier question is basic: which provider will carry 103.84.196.0/24 and 103.84.197.0/24 when they are announced? The second is physical: where do those fibres enter, and are they diverse? The third is commercial: who is responsible for route filters, abuse complaints, DDoS scrubbing and emergency escalation? The fourth is operational: has failover been tested under realistic load, or is a second path only a contract line?

India's exchange and resource environment gives RAC options. IRINN lists current affiliate entities, and the company appears there in public-resource context. IRINN's affiliate guidance describes local internet registry functions and references ISPs and data-centre operators among the types of organisations that may require resources. NIXI and Indian exchange infrastructure can support domestic interconnection. But being in that ecosystem is not the same as being directly interconnected. RAC still has to show the route and the carrier meet.

Power and cooling are the real capacity gates

The assignment's hardest test is the correct one: not whether RAC can register numbers, but whether marketed data-centre capacity can survive power and carrier constraints. Data-centre capacity is usually lost at the narrowest physical dependency. A company can have a legal entity, an AS, IP space and demand, yet still fail to deliver reliable service because the facility does not have enough protected power, cooling redundancy, carrier diversity, spare hardware or operating staff.

Power comes first. A rack's usable load depends on utility supply, transformer capacity, UPS design, generator runtime, fuel contracts, breaker coordination, power distribution, monitoring and maintenance procedure. A small provider may start with modest loads and still be viable, but it must not let customers believe a server room is a fully redundant data centre. If RAC operates in Rajapalayam, local distribution, fuel logistics and field access become part of the service promise. If it leases space in a metro facility, the relevant evidence is the lease boundary and the facility operator's power design.

Tamil Nadu's policy language is useful because it treats power as a data-centre issue rather than a generic office utility. The state data-centre policy discusses power-related facilitation and large-load arrangements. The question for RAC is much narrower: does the company have a current utility path, UPS, generator runtime, fuel plan and maintenance record for the capacity it markets? If the answer is "the facility provider handles it," then customers need the facility provider named, the contract boundary explained and the responsibilities documented.

Cooling is the second gate. The public record contains no rack density, installed IT load, cooling topology, water source, airflow design or environmental monitoring for RAC. That absence does not mean a facility is unsafe; it means there is no public basis for a capacity claim. A buyer should ask how many racks are installed, how many are powered, how many can run at intended load during a cooling-unit failure, how temperature is monitored, and whether the company has authority to shed non-critical load before equipment is damaged.

The CEEW data-centre ecosystem study is a useful reminder that India's data-centre buildout is also an energy and resource story. The study does not evaluate RAC. It does support the broader point that power and cooling are not back-office details. They decide whether "data centre" is an operating asset or only a company description.

Fire, access and remote hands decide how failures end

A data-centre failure does not end when the first alarm sounds. It ends when someone can diagnose the fault, reach the equipment, isolate the blast radius, replace the failed part, keep unaffected customers online, communicate clearly and restore service without causing a second incident. Public RAC evidence does not show those capabilities.

The fire and access questions are straightforward. What suppression system protects the equipment room? Is detection zoned by room or rack row? Are battery areas separated? Are cable trays managed? Who has physical access? Are visitor logs kept? Are remote-hands staff available at night, on weekends and during local disruptions? Does the company stock replacement drives, power supplies, optics, RAM and switches locally? Can one failed top-of-rack switch be replaced without taking down unrelated customers?

Those details sound mundane until a small hosting provider fails. A route can be reannounced in minutes if the routers, optics and upstreams are ready. A burned power distribution unit, flooded cable path or overheated storage shelf can take far longer. Without published or customer-provided operating evidence, RAC should be treated as a candidate provider whose recovery capability must be inspected before workloads arrive.

The same applies to customer communication. If RAC has no public status page and no visible support process, buyers should ask for the actual outage path. Who sends maintenance notices? Which channel remains available if racdcs.com is down? How are customers notified if an upstream filters the block, if a generator transfer fails, or if a cooling event requires controlled shutdown? A quiet public web surface makes those questions more urgent, not less.

RAC-branded market signals need a boundary

There are RAC-branded market signals around data-centre equipment rental and IT infrastructure, but they should not be merged casually with the assigned directory entity. RAC IT Solutions presents itself as an IT rental and services provider, with data-centre-adjacent offerings such as servers, storage, networking equipment and managed rental capability. Public LinkedIn activity from RAC IT Solutions has promoted data-centre solutions on rent. That material may explain why a buyer encountering the RAC name expects data-centre capacity.

It does not prove that RAC DATACENTER AND CLOUD SERVICES OPC PRIVATE LIMITED owns or operates a data-centre facility. The public RAC IT Solutions material identifies a different corporate branding surface and a different customer proposition: rental and IT services. It may be affiliated, related by people, brand, customer channel or supplier network; it may also be separate for the purposes that matter to a buyer. The public evidence reviewed here does not settle that boundary.

The right way to use the signal is as a warning about ambiguity. If a buyer is offered RAC-branded data-centre capacity, the contract should identify the legal counterparty, the facility operator, the IP-resource holder, the equipment owner, the support provider and the party responsible for outage notices. If RAC IT Solutions rents the equipment while RAC DATACENTER AND CLOUD SERVICES OPC PRIVATE LIMITED holds IP resources, the customer needs to know which entity is responsible for route activation, remote hands, spares and data return. If the two are unrelated in the deal, the customer needs that stated too.

Unofficial IP-intelligence signals also stay limited. AbuseIPDB's page for 103.84.196.90 and 103.84.196.241 associated sample addresses with RAC Datacenter and a data-centre or hosting usage type, while showing low abuse-confidence context. Those labels can reflect database classification from registry data. They cannot prove that a route is live, that customers are hosted, or that a facility exists. The public BGP evidence remains the stronger arbiter of whether the block is actually reachable.

Who is affected if RAC fails

The affected parties are hard to name because public evidence does not show live customers. That uncertainty should not make the risk smaller. It changes the wording: the article can identify plausible affected groups, not confirmed tenants. If RAC begins selling data-centre, hosting or cloud services, failures could affect local businesses, web agencies, resellers, software vendors, backup customers, small e-commerce sites, remote-office systems and any downstream users who only know the end service, not the infrastructure provider.

The first failure path is route activation or route loss. If customers are placed on 103.84.196.0/24 or 103.84.197.0/24 after launch and the route disappears, services become unreachable even if servers are still powered. If customers are instead placed on another provider's addresses, a dispute or outage at that provider can strand RAC customers without RAC controlling the underlying route. In either case, customers need to know how addresses are assigned, who can move them and how DNS changes are handled during migration.

The second failure path is utility or power-transfer failure. If the facility loses grid power and the UPS or generator plan is weak, customer workloads can shut down abruptly. That can corrupt databases, interrupt backups, break payment flows and damage trust for small businesses that may not have multi-site architecture. A serious provider can answer which loads are protected, how long generators run, how fuel is replenished and how customers are prioritized during prolonged failure.

The third failure path is cooling. Cooling failure rarely looks dramatic from outside the building. Customers may see latency, hardware faults, emergency shutdowns or unexplained maintenance. A small facility without clear cooling redundancy can be forced to choose between keeping every customer online and protecting equipment from damage. Customers should know whether RAC has tested reduced-cooling operation and whether service contracts allow controlled load shedding.

The fourth failure path is carrier meet interruption. A cable cut, router failure, transceiver shortage, maintenance mistake or upstream filter can isolate an otherwise healthy rack. Because public neighbour evidence is absent, buyers cannot currently judge whether RAC would have one route, two routes or no direct route under its own AS. That is a commissioning question, not an academic one.

The fifth failure path is commercial continuity. Small infrastructure businesses can be competent but capital constrained. If capacity is sold before the power path, carrier path or support path is mature, the first customer incident becomes a finance and trust problem as much as a technical one. Customers should ask whether their data can be exported, whether backups are off-site, whether invoices survive a service interruption, and whether the company can assist migration if it stops operating a platform.

What customers should ask before treating RAC as production infrastructure

The first question is legal and contractual: which entity signs the contract? If it is RAC DATACENTER AND CLOUD SERVICES OPC PRIVATE LIMITED, the contract should say whether the company is the facility operator, IP-resource holder, reseller, managed-service provider or equipment-rental counterparty. If another RAC-branded company is involved, the customer should insist that responsibilities are separated in writing. The name on an invoice matters when an outage becomes a claim.

The second question is physical: where is the production equipment? A registered address is not enough. Customers should ask for the facility location at city and facility-operator level, even if the exact room or cabinet number is controlled. They should ask whether RAC owns the room, leases racks, rents equipment into another facility, or uses another provider's cloud. They should also ask who controls physical access, remote hands, spares and emergency change approval.

The third question is network: when will AS150652 originate routes, and through whom? Customers should ask for a looking-glass test, a route-monitoring link, current upstream names, RPKI status, route-object maintenance, DDoS process and abuse-contact procedure. If the answer is that customer workloads use another AS, the provider should disclose which AS and what rights RAC has during failover or migration.

The fourth question is power and cooling: what is the current usable load, not the aspirational rack count? Customers should ask for UPS topology, generator runtime, fuel arrangements, maintenance records, temperature monitoring, redundancy assumptions and most recent failover test. A small provider does not need hyperscale scale to be useful. It does need honesty about its limits.

The fifth question is recovery: how does a customer leave? Before production use, customers should test data export, backup restoration, DNS cutover, IP reassignment, ticket response and invoice access. A provider that cannot explain exit during normal operations will be much harder to rely on during failure.

What would change the grade

RAC can improve its evidence grade with specific disclosures and public signals. The easiest network signal would be stable announcement of 103.84.196.0/24 and 103.84.197.0/24 from AS150652, visible across RIPEstat, BGP.tools, Hurricane Electric, RouteViews-derived services and customer test locations. The next signal would be named upstreams, a clear peering policy, a PeeringDB profile, and consistent RPKI coverage for the production route plan.

The facility signal would be a concise service page that distinguishes hosted capacity from equipment rental. It should name the service categories, city or facility region, power design, support window, maintenance notice process, backup and export policy, and responsibilities of any partner facility. It does not need to reveal sensitive diagrams. It does need to stop asking customers to infer a data-centre business from a corporate name.

The recovery signal would be a status and incident process. Even a basic public status page with historical maintenance notices, contact paths and clear outage language would improve trust. Buyers do not need perfection. They need to know that the operator can see, explain and repair faults without discovering the procedure in real time.

The most persuasive private evidence would be a controlled customer pack: facility certificate or lease confirmation, power and cooling commissioning summary, carrier contracts or letters, recent generator test, backup restore test, support escalation tree and route-monitoring screenshots from independent collectors after launch. Those documents would not make RAC a large data-centre operator, but they would turn the profile from negative public network evidence to inspectable operating evidence.

The first routed month would be the real test

If AS150652 begins announcing 103.84.196.0/24 or 103.84.197.0/24, the first routed month should be treated as a commissioning period rather than instant proof of resilience. New small-provider announcements often reveal their real shape gradually: one upstream appears, then a backup path is added, then route objects and reverse DNS are cleaned up, then customer traffic starts to show through reputation and measurement services. That sequence can be normal. It becomes risky only when customers are asked to treat a first announcement as if it were a mature, tested platform.

The first thing to monitor would be stability. A new route should remain visible across a broad set of collectors, not appear for a few hours and disappear without explanation. Route flapping in a launch window may be understandable during configuration, but repeated unexplained withdrawals would be a warning that the upstream, router, filtering or commercial arrangement is not settled. Customers should also watch whether both /24s appear, whether they are originated by AS150652 as authorized by the current ROAs, and whether any unexpected origin AS appears.

An unexpected origin is not automatically hostile, but it must be explained before customers place production traffic on the block.

The second thing to monitor would be the neighbour set. One visible upstream can be enough for a pilot service, but not for a strong data-centre resilience claim. If only one neighbour appears, RAC should say whether a second carrier is planned, whether the current provider is transit or managed hosting, and what outage path customers should expect. If two or more neighbours appear, customers should still ask whether those routes are physically diverse. BGP can show logical adjacency; it cannot show whether two circuits enter through the same duct or depend on the same powered equipment.

The third thing to monitor would be the support surface around the route. Does racdcs.com change from a default page into a service page? Does a status page appear? Are abuse contacts current? Are reverse-DNS delegations created? Are customer terms published? Does a PeeringDB entry appear with NOC details, facilities, traffic policy and exchange information? None of these signals alone proves a reliable facility. Together, they show whether the operator understands that an Internet-facing data-centre service is also a communications and governance obligation.

The fourth thing to monitor would be early customer evidence. The healthiest early signals are not large claims; they are small, verifiable operating details. A looking-glass endpoint, a public maintenance notice, an incident-free pilot period, a documented backup restore, or a customer reference that names the service boundary would be more useful than a broad capacity slogan. Conversely, sudden abuse-listing activity, inaccessible support channels, unclear invoices or conflicting claims about facility ownership would deserve caution even if the route stays up.

The fifth thing to monitor would be whether the company keeps the evidence proportional. A first /24 announcement and a small rack footprint can be a legitimate regional service. It should be sold as that. The danger comes when a compact launch is described in language that implies carrier-neutral, multi-site, highly redundant capacity before the public and private evidence support it. RAC's fastest path to trust is not to sound bigger. It is to describe exactly what is live, what is planned, what fails over, and what customers must protect themselves.

Evidence grade

RAC DATACENTER AND CLOUD SERVICES OPC PRIVATE LIMITED earns a Negative public network evidence grade for current operating capacity. The positive evidence is real: APNIC identifies the company, AS150652 and 103.84.196.0/23; IRINN affiliate context supports its resource-holder position; valid ROAs exist for the two likely /24 route components; and Tamil Nadu is a plausible market for data-centre infrastructure.

The downgrade is stronger. AS150652 was not globally announced in the current RIPEstat and BGP.tools views checked for this article. The /23 and both /24s were not visible as routed prefixes. RIPEstat showed no current neighbours, no announced IPv4 or IPv6 space and no routing history in its view. PeeringDB had no AS150652 network entry. The racdcs.com web surface displayed a generic default page rather than an operating data-centre service. Public records did not disclose racks, facility location, power design, cooling redundancy, carrier diversity, service terms, support hours, status history or customer failover evidence.

That does not mean RAC cannot become a provider. It means the burden of proof is still ahead of it. Until customers can see a live route, a named facility boundary, a carrier model, a power and cooling design, and a recovery procedure, RAC should be treated as a company with assigned infrastructure resources rather than a proven data-centre capacity operator. In infrastructure, the name can create interest. The route, the rack and the recovery test create trust.