Centre of server systems Ltd sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Centre of server systems Ltd has a verifiable Internet identity: RIPE RDAP registers AS201009 as SUPPORTIT-AS for the company, RIPEstat shows the AS announced on 14 July 2026, and the visible announced space is the Russian IPv4 prefix 109.248.237.0/24.
• The company's own Support IT pages at https://supportit.ru/ and https://supportit.ru/%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3-%D0%B8-%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2.html describe server and network administration, database administration, hosting, server placement, own racks in a Tier III data centre, high-speed channels and 24-hour monitoring, but the static hosting page was last modified in 2015 and must be treated as an old public claim rather than a current capacity audit.
• Public routing evidence is stronger than the public commercial evidence. RIPEstat reported one IPv4 prefix, no IPv6 prefixes, 325 of 326 IPv4 RIS peers seeing the route, two observed neighbours, and an unknown RPKI status for 109.248.237.0/24, while PeeringDB listed no exchange or facility records for the AS.
• The evidence grade is Medium for network identity and current route visibility, but weak for hosting capacity, facility resilience, power, spare hardware, data locality beyond Moscow/Russia signals, and customer recovery. Any dependent operator should verify where its service sits, how it routes, how it is backed up, and what happens when a rack, upstream, support desk or repair window fails.

The company is visible, but the capacity is not visible in the same way

Centre of server systems Ltd appears in public infrastructure records as the organisation behind SUPPORTIT-AS. RIPE's RDAP record at https://rdap.db.ripe.net/autnum/201009 names AS201009 as SUPPORTIT-AS, marks it active, and connects it to Centre of server systems Ltd. The organisation record at https://rdap.db.ripe.net/entity/ORG-COSS2-RIPE gives the same company name and a Moscow address. The assigned IPv4 network record at https://rdap.db.ripe.net/ip/109.248.237.0/24 identifies 109.248.237.0 through 109.248.237.255 as SUPPORTIT-NET, country RU, with a remark naming Centre of server systems Ltd.

Those records do real work. They separate the company from the common class of hosting brands that are little more than reseller storefronts. A registered AS and a routed /24 mean the operator has at least a visible routing identity, a public address block and a relationship with upstream networks or route intermediaries. RIPEstat's AS overview at https://stat.ripe.net/data/as-overview/data.json?resource=AS201009 reported the AS as announced at the 14 July 2026 query time. Its announced-prefixes endpoint at https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201009 showed 109.248.237.0/24 as the visible prefix during the two-week window ending at the same time.

The public company site supplies the commercial story. The landing page at https://supportit.ru/ presents Support IT as a provider of system and network administration, database administration, hosting and server placement, and technical support. It describes servers and networks as the responsibility zone for its administration service, names hardware and software maintenance, fault diagnosis, selection and purchase of fault-tolerant equipment, security work and audits. The database section names Oracle, MS-SQL, MySQL and PostgreSQL. The support section says support works 24 hours a day and that incidents are handled through a continuing case record. The page links to a customer entrance at https://supportit.ru/otrs/customer.pl; its HTTP headers returned an OTRS customer login page during this review.

The hosting claim is more specific but also more dated. The one-page landing section says the company has own racks in a Tier III data centre, high-speed channels, 24-hour monitoring, an individual approach to placement and service, two 2015 communications licence numbers, a low monthly price for a virtual server and a low monthly price for a physical server. A separate static page at https://supportit.ru/%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3-%D0%B8-%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2.html repeats the theme in a more conventional site shell: server placement in own racks in a Tier III data centre, high-speed channels, resilient hosting organisation, 24-hour monitoring and two licence numbers dated 5 February 2015. Its HTTP headers showed a last-modified timestamp of 13 February 2015.

That timestamp changes the reading. The old hosting page is useful evidence of how the company wanted to position its infrastructure when the site was built. It is not current proof that the same racks, facility grade, monitoring coverage, licence status, pricing, spare hardware or customer stock exist in July 2026. The newer-looking index page at https://supportit.ru/index.html was last modified in March 2019 and continues to expose the same service menu, but it also leaves the reader without current product inventory, a public status page, a dated incident record, a data-centre name, a facility address, a network diagram, a backup policy or support coverage metrics.

That is the central distinction. The company is visible. The route is visible. The public site is reachable from its own address space. The customer entrance is visible. But sellable hosted capacity is not visible in the same way. There is no public plan grid with stock, no dated availability report, no facility certificate, no public maintenance archive, no statement of active customers, and no proof that the low prices from the old pages still apply.

A careful buyer should treat Centre of server systems Ltd as an operating infrastructure entity with incomplete public operating disclosure, not as a cloud platform whose capacity can be assessed from a product catalogue.

The asset is small, concrete and Moscow-centred

The most concrete asset in the public record is a single IPv4 /24. RIPEstat's prefix overview at https://stat.ripe.net/data/prefix-overview/data.json?resource=109.248.237.0/24 reported 109.248.237.0/24 as announced by AS201009, holder SUPPORTIT-AS Centre of server systems Ltd. RIPEstat's routing-status endpoint at https://stat.ripe.net/data/routing-status/data.json?resource=AS201009 reported one IPv4 prefix, 256 IPv4 addresses, zero IPv6 prefixes, zero IPv6 space, two observed neighbours, and visibility from 325 of 326 IPv4 RIS peers at the 14 July 2026 query time. That is a healthy route-visibility signal for one prefix. It is also a narrow footprint.

The narrow footprint matters. A /24 can host many services, but it is not a large cloud region. It can carry public websites, DNS, mail systems, customer servers, management hosts and support tools. It cannot by itself show rack count, physical diversity, backup isolation or whether customers are segmented from the provider's own operations. If the same /24 contains the provider website, DNS hosts, support systems and customer workloads, a customer must ask what happens when that address space, upstream path, border configuration or facility fabric has trouble.

The DNS evidence makes the footprint more tangible. RIPEstat's DNS-chain endpoint for https://stat.ripe.net/data/dns-chain/data.json?resource=supportit.ru showed supportit.ru resolving to 109.248.237.96, with authoritative nameservers cns1.supportit.ru, cns2.supportit.ru and cns3.supportit.ru. The cns1 query at https://stat.ripe.net/data/dns-chain/data.json?resource=cns1.supportit.ru showed cns1.supportit.ru resolving to 109.248.237.69. The OTRS support host query at https://stat.ripe.net/data/dns-chain/data.json?resource=otrs.supportit.ru showed otrs.supportit.ru resolving to 109.248.237.87. Local DNS checks also returned supportit.ru A record 109.248.237.96, no AAAA record, Support IT nameservers inside the same domain, and Google mail exchangers for email.

Those observations support two conclusions. First, the Support IT web and customer-support surfaces are not merely fronted by a third-party CDN in the observed path. They sit in the same routed address block associated with the company. That is stronger infrastructure evidence than a site that only resolves to a generic content-delivery provider. Second, the public-facing control surfaces appear concentrated inside the same /24.

That can be normal for a small provider, but it raises dependency questions: if the prefix is filtered, if the AS loses route visibility, if the provider's DNS hosts are unavailable, or if the customer ticket system becomes unreachable, customers may lose both service reachability and the easiest route to support.

The geolocation signal also points to Russia, specifically Moscow, but it is not a facility audit. RIPEstat's geolocation endpoint at https://stat.ripe.net/data/geoloc/data.json?resource=109.248.237.0/24 and MaxMind view at https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=109.248.237.0/24 both located the prefix in Moscow, Russia. IPinfo's unauthenticated page for https://ipinfo.io/109.248.237.96 likewise identified AS201009 Centre of server systems Ltd and Moscow. These are useful locality signals for where traffic and registered infrastructure appear to live. They do not prove the actual floor, cage, cabinet, power feed or backup location of any customer workload.

The company therefore sits in a specific category: an infrastructure-support and hosting provider with a small but real address and routing estate. That is not a weakness by itself. Many resilient niche providers operate compact networks. The issue is that compact networks demand explicit evidence for redundancy. A single IPv4 /24 can be well engineered or fragile; the difference is in physical diversity, route policy, monitoring, backups, staffing and customer exit options. The public record confirms the /24 and the Moscow signal. It does not confirm the rest.

The first-party hosting promise is old enough to require a downgrade

Support IT's public copy is unusually frank about physical dependency. The hosting section does not sell an abstract cloud. It says the company has own racks in a Tier III data centre, high-speed channels, 24-hour monitoring and an individual approach to server placement and service. That language maps directly onto the parts a hosted server actually needs: rack space, power, cooling, network access, remote hands, monitoring and support.

The old page is therefore useful, but it needs an evidence downgrade. The page at the encoded hosting URL showed a 2015 last-modified date. It was written in a style that looks like an early commercial brochure: a short service description, licence numbers, a phone number, Skype, email and a customer entrance link. The main page, last modified in 2019, keeps the same claims and adds more service categories. Neither page shows a current date, a current data-centre operator, a current price table, active order links, contract terms, SLA text, maintenance notices, a route policy page, a public service-status page or an uptime history.

Old provider pages can remain true, become partly true, or become historical without being removed. A company may still have the racks it advertised in 2015. It may have moved facilities. It may have changed upstreams. It may have stopped selling physical servers but kept support contracts. It may have moved from retail hosting to managed infrastructure for a smaller set of clients. It may have retained only internal or private customer workloads. Public evidence does not choose among those possibilities. The correct reading is not to discard the page; it is to mark each capacity claim as requiring present-tense confirmation.

The licence references need the same treatment. The Support IT pages list two 2015 Russian communications licence numbers. The public page can support the statement that the company displayed those numbers in its hosting copy. It cannot, by itself, support a statement that the licences remain active, cover the same services, cover every hosted workload, or are sufficient for every customer compliance requirement in 2026. A customer with regulated data or telecom exposure should request a current licence extract, scope, expiry status and the exact legal entity relationship behind the service contract.

The customer-logo pages require even more caution. The landing page and the "about us" page at https://supportit.ru/%D0%BE-%D0%BD%D0%B0%D1%81.html display client-logo galleries and state that the company's goal is to let partners focus on core business while professional staff handle IT infrastructure service. That is valuable public positioning. It is not a current customer list, not a service endorsement, not proof of live hosting, and not proof that any named organisation still uses Support IT infrastructure. The only safe inference is that Support IT has publicly marketed itself as an outsourced IT and hosting partner to business clients.

The contact page at https://supportit.ru/%D0%BA%D0%BE%D0%BD%D1%82%D0%B0%D0%BA%D1%82%D1%8B.html says contact is available 24 hours a day, seven days a week through several methods. The OTRS endpoint returned live login headers. That combination supports a current support-surface claim more strongly than the 2015 hosting copy. It still does not prove staffing levels, response times, escalation authority, hardware replacement stock, outage communications or whether the same support desk covers hosted servers, office IT, database administration and network incidents.

For a buyer, the practical effect is simple. Ask the provider to separate present facts from legacy brochure facts. Which data centre hosts current customer servers? Are the racks owned, leased or resold? Is the site still Tier III certified, and by whom? Which links are active? Which services are monitored 24 hours? What is the support objective for a failed physical server? Are virtual servers and physical servers still sold at the advertised prices? Does the company still accept new hosting customers? Public evidence can begin that conversation; it cannot finish it.

Route visibility is strong enough to prove reachability, not resilience

AS201009's current route visibility is better than many thin-footprint hosting names. RIPEstat shows it announced. The announced-prefixes endpoint shows 109.248.237.0/24 during the current two-week window. The routing-status endpoint shows near-total IPv4 RIS peer visibility at the query time. Hurricane Electric's BGP Toolkit network page at https://bgp.he.net/net/109.248.237.0/24 names AS201009 as the origin and Centre of server systems Ltd as the registrant, and it lists many DNS records inside the range. BGP.tools at https://bgp.tools/as/201009 identifies the network as active, with one IPv4 prefix, no IPv6 prefixes, two upstreams and three peers in its view.

Those are useful confirmations. They show the network is not just registered; it is being seen in public routing data. The strongest current path in RIPEstat shows the /24 visible from almost all IPv4 RIS peers. The route history at https://stat.ripe.net/data/routing-history/data.json?resource=AS201009 shows 109.248.237.0/24 as a long-running origin route from 2015 through July 2026, with a short-lived history of more-specifics in earlier years and one unrelated-looking 46.8.152.0/24 timeline in 2020. Long route history is not the same as service quality, but it makes the network less ephemeral than a newly created or sporadically visible AS.

The limits matter just as much. RIPEstat's asn-neighbours endpoint at https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201009 reported two observed neighbours at the latest available 14 July 2026 observation: AS12695 and AS9002. The RIPE whois view at https://stat.ripe.net/data/whois/data.json?resource=AS201009 showed import and export entries for AS12695 and AS57304, while the as-routing-consistency endpoint at https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201009 found AS12695 in both BGP and whois, AS57304 in whois but not BGP, and AS9002 in BGP but not whois. That mismatch is not necessarily dangerous, but it tells the reader not to infer a perfectly documented transit design from one data source.

RPKI is another watchpoint. RIPEstat's RPKI validation endpoint at https://stat.ripe.net/data/rpki-validation/data.json?resource=201009&prefix=109.248.237.0/24 returned status unknown, with no validating ROAs. Unknown is not invalid. It means the route was not protected by a validating ROA in that view. For a small hosting network, an unknown RPKI state increases the importance of route-filtering discipline, IRR objects and upstream configuration. If a customer depends on stable address reachability, it should ask whether the provider plans to publish ROAs and how upstreams filter the prefix.

PeeringDB is also a constraint. The network API at https://www.peeringdb.com/api/net?asn=201009 contains a Centre of server systems network entity for AS201009, created in 2021 and updated in 2022, but it reports no traffic level, no disclosed scope, zero IX count, zero facility count, no website, no looking glass and no route server. The netixlan endpoint at https://www.peeringdb.com/api/netixlan?asn=201009 returned an empty data array. The netfac endpoint at https://www.peeringdb.com/api/netfac?net_id=26979 also returned an empty array. That does not mean the company has no facility or no interconnection; many operators do not maintain complete PeeringDB profiles. It does mean public interconnection/facility evidence is weak.

The result is a split grade. Route reachability is good for the one IPv4 prefix. Resilience evidence is thin. The public record does not show whether AS201009 has two physically independent routers, two independent cross-connects, two upstreams in separate meet-me rooms, diverse fibre paths, spare line cards, tested failover, DDoS scrubbing, route monitoring, 24-hour NOC staffing, or customer-facing status communications. Two observed BGP neighbours can improve reachability, but they do not automatically prove facility diversity or operational independence.

For a dependent operator, the route questions should be specific. Which upstreams carry the customer prefix today? Are AS12695 and AS9002 both actively used for the customer's traffic, or does one appear only in some observed paths? Is AS57304 still a contracted path, a historical whois entry or an indirect relationship? Is there a route object for every announced prefix? Will the provider publish RPKI ROAs? Are DNS, support and customer services reachable if the main facility or one upstream fails? Those are not academic questions.

They determine whether a routed /24 is a resilient platform or simply a small address block with public reachability.

Facility and power claims sit behind the thinnest public evidence

The strongest facility statement is still the first-party one: own racks in a Tier III data centre. It appears on the Support IT pages, and it is exactly the kind of claim that matters for hosting. A hosted server lives or dies by power, cooling, physical access, rack design, upstream handoff, switch fabric and spare-part logistics. If the company really operates its own racks in a properly resilient data-centre environment, that is material.

The problem is that the public record does not identify the facility. It does not name the data-centre operator, campus, certification body, room, city, power topology, cooling design, generator arrangement, UPS design, cross-connect carriers or remote-hands contract. Geolocation points to Moscow. The organisation address is in Moscow. The route paths include Russian upstream evidence. The DNS and customer-support hosts sit in 109.248.237.0/24. All of that makes a Moscow-centred reading reasonable. It does not prove the rack is in a specific Moscow facility, that the facility is currently Tier III, or that all customer workloads are there.

Power is the hidden failure path. A provider can have an announced prefix and working DNS while still depending on one electrical room, one rack PDU chain, one generator maintenance window, or a single on-site intervention path. A customer watching only HTTP reachability will see the failure only after the service goes dark. The old Support IT hosting copy uses "fault tolerance" language around racks, high-speed channels and monitoring. That is useful as a design aspiration.

The current public evidence does not show failure tests, measured availability, power incidents, maintenance notices, battery autonomy, generator test results or any service-credit terms.

Hardware is the second hidden path. Support IT's pages advertise virtual and physical server pricing, but they do not show current server types, storage design, RAID policy, hypervisor platform, backup system, spare hosts, physical stock or replacement timing. A physical server offer depends on chassis, disks, RAM, power supplies, network interfaces and remote-management access. A virtual server offer depends on host oversubscription, storage redundancy, snapshot policy, migration capability, and staff who can restore service when a host fails.

A cheap physical-server or VPS plan can be perfectly adequate for many workloads; the risk is assuming enterprise spare capacity from a brochure that does not show it.

Monitoring is the third path. The site says 24-hour monitoring. The customer-support pages show OTRS. But monitoring without public status, incident history or escalation policy leaves outsiders unable to distinguish between a well-run NOC and a small support team watching alerts. The right question is not whether monitoring exists. It is what is monitored, where monitoring lives, who receives alerts, what response time applies to network failure versus customer OS failure, and whether customers receive proactive notices when the provider detects facility or route degradation.

Support IT may have strong answers to those questions. The public record simply does not publish them. That is why the article should not call the company unreliable. It should call the public capacity evidence incomplete. A small provider can be resilient if it knows its limits, communicates clearly and keeps customer recovery paths honest. A small provider becomes risky when customers mistake a working /24 and an old hosting page for proof of current redundant infrastructure.

Data locality is clearer than data portability

The manifest classifies this article in a global cloud-service category because hosted capacity is globally reachable. The evidence, however, is Russia-centred. The company record is Russian. The site is Russian-language. The address and geolocation signals point to Moscow. The visible announced prefix is in RIPE space and country RU. DNS and support hosts resolve inside the company's Russian /24. There is no public evidence of servers in the European Union, North America, Asia-Pacific or any other non-Russian location.

That matters for data sovereignty. A user outside Russia can technically host or reach services on this network, but global reachability is not the same as global locality. A customer with regulated data should not infer multi-region options or foreign data residency from the fact that the website is reachable worldwide. It should ask for the physical location of production servers, backup storage, logs, monitoring systems and administrative access. It should also ask whether support staff, contractors or third-party mail/helpdesk providers can access customer data.

Google MX records for supportit.ru do not mean customer data is stored in Google, but they do show that at least the provider's domain mail path uses Google-hosted mail exchangers. The OTRS customer entrance sits on the provider's own address range. DNS nameservers are under supportit.ru and resolve into the same /24. This mix is ordinary, but it shows why data locality is not one entity. Email, tickets, backups, DNS, monitoring and hosted servers can each have a different location and legal exposure.

Data portability is even less visible. The public site does not explain whether virtual servers can be exported, whether physical server customers receive disk images, whether backups are provider-managed, whether snapshots are self-service, how long data is retained after cancellation, or whether customers can receive a clean restore archive during a dispute. The old service language emphasizes individual approach, but individual approach is not a portability guarantee. When a small provider is involved, the safest assumption is that customers must own their own backups and test restores outside the provider.

DNS concentration creates a related portability risk. If customer domains use Support IT-hosted DNS inside 109.248.237.0/24, a prefix or nameserver failure can make it harder to redirect traffic elsewhere. If application servers, support tickets and DNS are all tied to the same network, the customer needs out-of-band control: registrar credentials, external monitoring, off-network DNS options, off-network backup storage and documentation that is not locked behind the provider's customer portal.

The broader point is that cloud-service dependency is not only compute dependency. It is identity, DNS, mail, ticketing, backups, credentials, invoices, licences and support. Centre of server systems Ltd exposes enough public infrastructure to make those dependencies visible. It does not expose enough public policy to make them safe by default.

Hosting economics explain both the appeal and the risk

Support IT's public pricing language is very low-cost: the landing page names a monthly virtual-server price and a monthly physical-server price in rubles, while the 2015 static hosting page frames affordability as part of the offer. Low-cost hosting is valuable. It gives small businesses, agencies, local services and internal tools a place to run without paying hyperscale prices or hiring full-time infrastructure staff. A provider with database expertise, network administration and local support can be attractive to organisations that need practical help more than global abstraction.

The same economics also narrow the margin for slack. When a provider sells inexpensive hosted capacity, every reserve costs money: spare servers, unused rack space, additional power feeds, second upstreams, remote-hands contracts, backup storage, extra staff and after-hours coverage. The cheaper the advertised server, the more explicitly the customer should ask which reserve layers are included and which are not. Low price is not a flaw; unpriced assumptions are the flaw.

The current evidence suggests Centre of server systems Ltd may be closer to a managed-infrastructure and local-support provider than to a modern retail cloud. The site emphasizes system administration, network administration, database administration, support and individual server placement. It does not show an automated cloud control panel, API-driven provisioning, public object storage, multi-zone architecture, published machine types, live stock, or self-service migration tooling. That does not reduce the company's value. It changes the diligence model.

Customers should evaluate it as a hands-on infrastructure partner, not as a commodity cloud with interchangeable zones.

The public route estate also fits that model. One /24 is enough for a focused provider that hosts selected customers, DNS, mail relays, gateways, PBX systems, websites and management hosts. Hurricane Electric's DNS tab for https://bgp.he.net/net/109.248.237.0/24 showed many PTR and A-record associations across the range, including provider hostnames and third-party-looking domains. Those DNS records suggest lived-in address space, not an empty allocation. They do not prove which hosts are current customers, which are legacy records, which are internal services, or which still carry traffic. DNS is a signal, not a customer roster.

The economic due diligence should therefore be plain. If a customer needs a single inexpensive server for a non-critical workload, the key questions are backup, support and exit. If a customer needs production infrastructure, the questions expand to power, upstreams, monitoring, incident communication, legal entity, data location, spare capacity and recovery objectives. If a reseller wants to build on the provider, it must verify stock, provisioning speed, contract rights and abuse handling. The same provider can be suitable for one use case and unsuitable for another.

Who is affected when the system fails

The affected party is not only the direct hosting customer. The DNS records and site claims point to a wider support role: nameservers, customer ticketing, hosted websites, mail-related names, PBX-looking names, gateways and application hosts. If a small provider's rack, upstream, DNS or support stack fails, the impact can travel through several layers at once. End users may see websites go down. Employees may lose internal tools. Mail delivery may queue. Customers may be unable to open support tickets. Administrators may lose remote access to the systems needed to restore service.

That combined failure path is common in small infrastructure environments. The same competence that makes a provider useful - it handles everything from servers to networks to database operations - can also create a shared operational surface. A customer may outsource too much of its recovery path to the same provider. The application runs there, backups sit there, DNS points there, monitoring alerts there, and the helpdesk is there. When the provider has a route or facility issue, the customer discovers that its escape route is inside the affected system.

The remedy is not to avoid every small provider. It is to design for independence where the cost matters. Keep authoritative DNS or secondary DNS outside the provider if the domain is critical. Store backups in a separate account and test restores. Keep registrar access outside provider email. Keep deployment instructions outside the hosted server. Monitor from outside the provider's network. Know which IP addresses are provider-assigned and will have to change during migration. Keep a direct support escalation path that does not rely only on the customer portal.

For Centre of server systems Ltd, the public record makes several specific tests sensible. A customer should trace the assigned IP and confirm the current origin AS. It should test whether cns1, cns2 and cns3 remain reachable during simulated DNS changes. It should ask whether its workload is on a virtual host or physical server, and whether the replacement path differs. It should request the current data-centre name at least under NDA if public disclosure is not possible. It should ask how support is staffed outside business hours and how incidents are communicated if the OTRS host is unreachable.

The provider's own 24-hour support language is useful, but support language must be operationalised. Who is on call? What triggers a wake-up? What failure domains are the provider's responsibility and what are the customer's? Does a managed database contract include backup verification? Does a physical-server contract include disk replacement by a fixed time? Does server placement include power-cycle support? Does network administration include DDoS response? Those distinctions determine whether a failure becomes a short repair window or a long outage.

What would raise or lower the evidence grade

The current evidence grade is Medium for network identity because multiple independent public sources agree on the AS, organisation, prefix and current route visibility. It is weak for hosted capacity because the public site is old, facility detail is not disclosed, PeeringDB has no facility or IX entries, and no public source shows active sellable inventory or resilience tests.

The grade would improve if the company published a dated infrastructure page explaining current services, data-centre region, whether the Tier III rack claim still applies, current upstreams, support hours, service-status visibility, backup options, customer export options and incident communication. It would improve if AS201009 had current RPKI ROAs for 109.248.237.0/24. It would improve if PeeringDB or another public interconnection record showed current facility and exchange participation. It would improve if the company published a customer-facing status page outside the same failure domain as the hosted services.

The grade would fall if AS201009 lost route visibility, if supportit.ru stopped resolving inside the assigned range without explanation, if DNS and OTRS became unreachable for extended periods, if the company removed current contact paths, or if public records showed licence, legal or abuse handling problems that directly affected hosted services. It would also fall if the provider continued to rely on 2015-era hosting pages while refusing to confirm current facility and recovery facts to customers.

The most important watchpoint is not the existence of the AS. That is visible. It is the operating boundary behind the AS. One routed /24 can be an efficient, carefully managed small hosting environment. It can also be a single point of dependence for DNS, support and customer workloads. Public data does not decide which. Current operating proof does.

Bottom line for dependent operators

Centre of server systems Ltd should be read as a real, small infrastructure company with an active Moscow-centred public route and a Support IT service surface that has remained online. Its evidence is stronger than a directory stub and weaker than a fully documented hosting platform. The company has an observable AS, a visible /24, working first-party web and support endpoints, and old but specific claims about racks, hosting and monitoring. It does not have public proof of current capacity, rack count, power design, route diversity, RPKI protection, backup policy, live customer stock or tested recovery.

For a current customer, the immediate task is verification. Identify the assigned IP range, the route origin, the physical or virtual placement, the backup location, the DNS dependency, the support escalation path and the restore procedure. Confirm whether the customer can recover if the provider's /24, DNS or support portal is unreachable. Ask whether data can be exported quickly and whether provider-side backups are separate from the hosting environment.

For a new buyer, the public record is not enough for an unqualified production dependency. It supports a conversation, not a purchase decision by itself. Ask for a current statement of service availability, facility location, upstream diversity, support coverage, licence status, contract terms, backup options, incident notices and migration rights. If the provider gives precise answers, the small footprint may be perfectly acceptable for some workloads. If the provider cannot separate current facts from old site copy, treat the hosting offer as a risk until proven otherwise.

The lesson is broader than one company. Hosted capacity always comes back to physical systems: racks, power, cables, routers, addresses, DNS, support staff, spare parts and repair windows. Centre of server systems Ltd shows those layers in miniature. The route is real. The old hosting claim is specific. The missing part is current proof that the physical and operational layers behind the claim are still sized, staffed and redundant enough for the dependency a customer wants to place on them.