Hosting SC ITNS.NET SRL sells hosted capacity that still depends on racks, transit and repair windows

Summary

• The public case for treating Hosting SC ITNS.NET SRL as a hosted-capacity dependency is real but bounded: ITNS itself describes cloud applications and managed hosting among application-layer services, PeeringDB lists a second SC ITNS.NET SRL network named IPV4-HOSTING, and RIPE ties both AS35346 and AS202511 to the same Moldovan organisation.
• The stronger evidence is network evidence rather than product evidence. AS35346 is active, visible in RIPEstat, present at MD-IX and KIVIX in PeeringDB, and tied to named upstream and peering policy in the RIPE Database. AS202511 is assigned to the same organisation but was not currently announced in RIPEstat on 12 July 2026.
• The main operational risk is not a mystery cloud control plane. It is the ordinary physical stack behind a regional hosting provider: Chisinau facilities, power, upstream diversity, IPv4 inventory, router configuration, hardware replacement, support hours, customer data export and the ability to move a workload before a repair window becomes a customer outage.
• The evidence grade is Medium. There is enough public routing, regulator and operator information to identify dependencies and failure paths, but not enough public facility, inventory, status-page, contract or restore-test evidence to verify multi-site resilience or customer portability.

The useful question is not whether ITNS is "in the cloud"

Hosting is often sold as abstraction. Customers buy a virtual server, a private VLAN, a managed firewall, a web portal, a backup target or an application environment and are encouraged to think in terms of service names rather than physical constraints. Hosting SC ITNS.NET SRL is a useful reminder that regional hosted capacity is still a stack of ordinary assets. Somewhere a server has to boot. Somewhere a switch has to pass frames. Somewhere a route has to leave Moldova. Somewhere a technician has to replace a power supply, swap optics, recover a configuration or tell a customer whether a migration will take minutes, hours or a weekend.

The public record does not support an extravagant reading of ITNS as a hyperscale cloud platform. It does support a narrower and more important reading: ITNS is a Moldovan communications operator with public claims that reach into application-layer and managed hosting services, and with visible autonomous-system infrastructure that would matter to any customer relying on it for hosted capacity. Its own Who We Are page describes IT and Network Solution, or ITNS.NET SRL, as a Moldovan optical-network and telecommunications partner with more than two decades of experience. Its What We Do page describes work from physical network design through Internet, TV and cloud systems. Its Layer 7 page goes further into application services, naming cloud applications, managed hosting, portals, DevOps systems, video surveillance, television, telephony and custom digital services.

That matters because hosted capacity is not only a product category. It is also a dependency category. If an ISP, enterprise, public institution or smaller service provider runs services on ITNS infrastructure, the customer is exposed to the same operating questions that shape any regional cloud or hosting supplier. Are there multiple usable sites, or only multiple routes into one metro footprint? Are customer workloads easy to export, or are they entangled with provider-specific addressing and management tools? Does IPv4 supply come from owned allocations, leased address space, customer-provided space or reannounced downstream networks?

Does the provider keep spare hardware nearby, or must failed servers and optics wait for procurement? If a single upstream, route server, power feed, billing system or support desk falters, how far does the failure spread?

The public evidence gives partial answers. The ANRCETI public register of electronic communications network and service providers lists ITNS. NET S.C. S.R.L. at Miron Costin 3/1 in Chisinau, authorized for public fixed terrestrial networks and services including telephony, call transport, leased lines, data transmission and Internet access. The RIPE organisation record ORG-SIS76-RIPE identifies SC ITNS.NET SRL in Moldova, gives a registration number, marks the organisation as a local Internet registry, and records a Muncesti 121A Chisinau address. The RIPE aut-num record for AS35346 names EUROTELECOM, ties the AS to that organisation, and lists import and export policy for upstreams, exchange points and peers. A second RIPE aut-num record for AS202511 uses the AS name HOSTING and the same organisation, while PeeringDB lists a corresponding IPV4-HOSTING network entry under SC ITNS.NET SRL.

The public record also leaves major gaps. PeeringDB's main ITNS.NET network entry reports two exchange connections and zero facility records. The absence of facility rows in PeeringDB is not proof that ITNS lacks racks, cages or data-center leases. It simply means a reader cannot use that public record to verify where the servers sit or whether two customer workloads can be placed in physically independent sites. The official site speaks in broad claims about redundancy, monitoring and service continuity; it does not publish a detailed status page, facility topology, spare-parts policy, backup architecture, restoration times, customer export procedure or managed-hosting product catalogue. A buyer therefore has to treat the public material as an evidence starting point, not as a resilience certification.

Legal and local identity: the Moldovan operator behind the services

The identity trail is stronger than the retail product trail. ANRCETI's public register names ITNS. NET S.C. S.R.L., gives the Chisinau address at Miron Costin 3/1, and lists the service classes associated with the operator, including public Internet access, data transmission and leased-line services. That regulator record is important because it anchors ITNS in the Moldovan electronic-communications market rather than leaving it as a web-only hosting brand.

It also frames the company as an operator whose hosted services, if sold to customers, sit next to traditional telecom duties: access networks, transmission, interconnection, support and service continuity.

RIPE gives the complementary Internet-number-resource view. The organisation entity uses the name SC ITNS.NET SRL, country code MD, registration number 1005600004190 and local Internet registry status. The address fields point to Muncesti 121A, MD-2002, Chisinau. The same record points to ITNS-NET-MNT and RIPE-NCC-HM-MNT as maintainers, and the ITNS-NET-MNT maintainer entity describes an ITNS network operations center with a Chisinau address. These records do not prove which legal entity owns each rack or server. They do prove that the public routing resources discussed in this article are not detached from the Moldovan company identity.

PeeringDB reinforces the link from a network-operator perspective. The SC ITNS.NET SRL organisation entry uses the same organisation name, marks EUROTELECOM as an alternative name, lists the websites itns.md and itns.net, gives Chisinau address details, and connects the organisation to two networks: ITNS.NET for AS35346 and IPV4-HOSTING for AS202511. PeeringDB is self-maintained by network operators and should not be treated like a regulator record, but it is still useful because it reflects how the operator presents itself to peers. In that forum, ITNS presents not only a general network but also a hosting-labelled AS.

The identity picture therefore has three layers. The regulator sees a Moldovan electronic-communications provider. RIPE sees a Moldovan local Internet registry with AS35346 and AS202511 tied to SC ITNS.NET SRL. PeeringDB sees a network operator with an ITNS.NET network and a second hosting-labelled network. That is enough to treat Hosting SC ITNS.NET SRL as a real infrastructure dependency. It is not enough to infer ownership links, customer relationships or facility contracts beyond what those public records state.

What the company says it provides

ITNS's own site is broad and somewhat marketing-heavy, but it provides several relevant claims. The Who We Are page describes ITNS.NET SRL as a Moldovan optical-network player with more than twenty years of growth, expertise across the Internet service provider business, and work in design, implementation and operation of fiber-optic networks. The language is self-promotional, yet it supports a baseline conclusion: ITNS wants to be understood as an infrastructure engineering and operations company, not merely as a reseller page.

The What We Do page is more concrete. It says ITNS provides complete telecommunications infrastructure solutions from physical fiber design to Internet, TV and cloud systems. It divides the stack from Layer 1 to Layer 7. Layer 1 covers requirement verification, field analysis, optical infrastructure design, coordination with authorities and construction. Layer 2 covers active-equipment design using vendors such as Juniper, Cisco, Huawei, Arista, Mikrotik, D-Link and TP-Link. Layer 3 covers installation, configuration, Internet service provisioning, upstream connectivity, peering, IP transit, monitoring and maintenance. Layer 7 names television, video surveillance, fixed telephony, portals, DevOps systems and cloud-based applications.

The Layer 1 page is useful because it explains the physical orientation behind the company claim. It describes design and construction of electronic-communications networks, field surveys, route tracing, documentation, duct and cable installation, splicing, termination and OTDR testing. For hosted capacity, this matters indirectly. A hosting service that is vertically close to a fiber and network operator may have advantages in local access, customer circuits and private connectivity. It also inherits field-operations constraints: permits, route damage, technician availability and the time it takes to repair or reroute physical infrastructure.

The Layer 3 page is closer to the hosting dependency. It describes routing, BGP, OSPF, MPLS, VLANs, network segmentation, upstream connectivity, peering, IP transit, high-availability design, monitoring and maintenance. A customer buying hosted capacity from ITNS is not only buying compute or storage. The customer is relying on those Layer 3 practices to keep the workload reachable. If routing policy changes, if a transit contract is suspended, if a misconfiguration propagates, or if customer IP space must move during an outage, the service boundary becomes the network boundary.

The Layer 7 page is the main public service evidence for this slot. It says ITNS delivers application-layer services and explicitly includes cloud applications, managed hosting, IoT integration and enterprise service orchestration among custom solutions. That is not a full managed-hosting catalogue. It does not publish server sizes, prices, virtualization platform, backup retention, storage tiers, service levels, accepted payment terms or data-export commitments. Still, it is a direct official statement that hosted and application services are within the company's commercial surface.

The Why You Need Us page raises the bar and the uncertainty at the same time. It claims end-to-end solutions from fiber optics to cloud applications, 24/7 support and monitoring, redundant routes, proactive maintenance and 99.99 percent uptime. Those statements are valuable as customer-facing commitments, but they are not independently verified by the page itself. In the absence of public incident history, status pages, site maps and restore exercises, the claims should be read as assertions that buyers must test through contracts and technical due diligence.

AS35346 is the visible production network

The clearest hard asset in the public record is AS35346. The RIPE Database aut-num entity records the AS as EUROTELECOM, tied to ORG-SIS76-RIPE, with status ASSIGNED, creation date 20 July 2005 and a last modified date of 24 June 2026. The same entity names upstreams and interconnection policy. It lists Cogent via AS174, RENAM via AS9199, NGN via AS60514 and Rapid Link via AS50084. It also lists MD-IX with Moldtelecom IXP references, KIVIX with TRABIA IXP references, and peering lines for Google Global Cache, Arax-impex and Rapid Link. The details are technical, but the strategic meaning is simple: AS35346 has an interconnection surface that is broader than a single transit feed.

RIPEstat confirms that AS35346 is not only assigned but visible. The RIPEstat AS overview showed the holder as EUROTELECOM SC ITNS.NET SRL and marked the AS as announced on 12 July 2026. The RIPEstat routing-status view reported full IPv4 visibility across its RIS peer sample, high IPv6 visibility, 19 IPv4 announced prefixes, 6,400 IPv4 addresses, 148 IPv6 prefixes and 13 observed neighbours. It also showed the first observed origin for this AS in December 2005 and current observations in July 2026. For a hosted-service customer, this is stronger evidence than a service brochure. Reachability is being seen by independent route collectors.

The RIPEstat announced-prefixes call shows how broad the IPv6 surface is. It lists many /29 IPv6 announcements along with IPv4 prefixes such as 91.242.112.0/20, several 91.242.x.0/24s, 195.138.108.0/24 and 194.114.144.0/24. The exact mix should be treated as time-sensitive, but the current snapshot shows that AS35346 is not a dormant shell. It is actively originating address space at scale for a regional operator.

The RIPEstat AS routing consistency view adds nuance. It shows many prefixes that are both in BGP and in the RIPE routing registry, but it also shows a long list of IPv6 prefixes that are visible in BGP and not matched in the whois side of the consistency output. That does not automatically mean the routing is wrong. It does mean a customer or peer should not assume every announcement has the same published routing-registry posture. For hosted capacity, especially when customer prefixes or delegated IPv6 ranges are involved, the quality of routing documentation can affect filtering, acceptance by upstreams and the speed of incident diagnosis.

RPKI evidence is partial but helpful. A RIPEstat RPKI validation call for 91.242.112.0/20 returned valid status for origin AS35346. A second RPKI validation call for 195.138.108.0/24 also returned valid status for AS35346, while showing that a broader AS8474 route would be invalid for the same exact origin question. For customers, valid ROAs do not guarantee service uptime, but they reduce one class of route-origin risk for those specific prefixes.

The hosting-labelled AS is a clue, not current proof of live capacity

AS202511 is the most explicit hosting clue in the public records. The RIPE aut-num entity uses the AS name HOSTING, links the AS to ORG-SIS76-RIPE, and lists import/export policy with AS41221 and AS42881. It was created in 2018 and last modified in March 2025. PeeringDB's IPV4-HOSTING entry lists AS202511 under SC ITNS.NET SRL, with the website itns.md and the alternative name SC ITNS.NET SRL.

But the live-routing evidence is weaker. The RIPEstat AS overview for AS202511 showed the holder as HOSTING SC ITNS.NET SRL but marked the AS as not announced on 12 July 2026. The RIPEstat routing-status call for AS202511 showed no current IPv4 or IPv6 visibility in its RIS peer sample, although it recorded historical first and last observations. PeeringDB likewise shows no IX count, no facility count and no public traffic profile for the IPV4-HOSTING entry.

That distinction matters. A dormant or currently unannounced hosting-labelled AS can still be operationally relevant. It might be reserved for future hosting growth, private arrangements, customer migrations, a traffic-engineering plan or address management. It might also simply be an old resource that is not in current production. Public evidence cannot decide between those interpretations.

The safer conclusion is that ITNS has a hosting-labelled number-resource footprint, but the live service dependency visible today is better analyzed through AS35346 unless a customer contract, looking glass, route collector or service order proves otherwise.

This also shapes the hosting economics. IPv4 addresses are scarce and costly, particularly for smaller regional providers that need to support virtual servers, dedicated boxes, customer appliances, mail servers, name servers and legacy applications. The presence of a network called IPV4-HOSTING suggests that IPv4 supply and assignment may be central to the service, but the current absence of public BGP visibility makes it harder to determine how that supply is used.

A buyer should ask whether hosted services receive provider IPv4, customer-owned IPv4, shared IPv4 with port forwarding, IPv6-first addressing, or a migration path if a block changes.

Peering and exchange presence reduce some risks and leave others

PeeringDB reports AS35346 as ITNS.NET, with the network name IT & Network Solutions, a regional scope, mostly inbound traffic ratio, 50-100 Gbps traffic, open peering policy, IPv6 enabled, two exchange connections and no public facility records. The PeeringDB netixlan view for network 29822 gives the two connections: MD-IX and KIVIX, both shown at 10 Gbps, both operational, both with IPv4 and IPv6 addresses, and both configured as route-server peers. This is significant. A hosted workload does not only need upstream transit. It benefits when local and regional traffic can stay near the customer, avoid congested long-haul paths and preserve reachability if one transit path is impaired.

The MD-IX PeeringDB entry identifies MD-IX as Moldova Internet Exchange in Chisinau, operated by Moldtelecom SA, with two facility records in PeeringDB: COLO-54 Moldtelecom and Data City - Moldtelecom. The KIVIX PeeringDB entry identifies KIVIX as Chisinau Internet Exchange, connected to Trabia's Chisinau facility context. These exchange records do not prove that ITNS customer servers sit inside those facilities. They prove that the exchange fabric itself is physically associated with Chisinau data-center or carrier locations, and that ITNS has at least the exchange connections listed by PeeringDB.

There is a subtle risk here. Exchange presence can improve local routing, but it can also create an illusion of multi-site resilience. Two exchange ports do not necessarily mean two independent compute sites. A provider can peer at multiple exchanges while running customer servers in one room. Conversely, a provider can operate servers in multiple leased locations but disclose none of them in PeeringDB. The record as it stands supports interconnection diversity more strongly than site diversity.

The RIPE aut-num entity broadens the picture by listing named transit and peering relationships. Cogent and RENAM are visible in both RIPE policy and the RIPEstat routing-consistency imports/exports section as present in BGP. Other listed relationships such as NGN, Rapid Link, MD-IX, KIVIX and certain peers are visible in the policy entity even where the consistency view does not show matching current BGP visibility. That mix is not unusual. Routing policy records can lag reality, include planned relationships, omit live relationships or preserve old arrangements.

For due diligence, the important point is not to count every relationship as guaranteed capacity. It is to ask which upstreams carry production hosting traffic today, what capacity each link has, which routes are accepted, and how fast a customer prefix can be rerouted if one path fails.

Facilities are the largest public blind spot

The strongest facility-related facts are addresses and exchange context, not rack maps. RIPE gives Muncesti 121A for the organisation. The ITNS maintainer entity gives Miron Costin 3/1 for a network operations center. ANRCETI's register also lists Miron Costin 3/1. PeeringDB's organisation entry lists both Muncesti 121A and Miron Costin 3/1. These public addresses identify Chisinau operating points, but they do not show where customer servers, storage systems or edge routers are housed.

The distinction between an office, an operations center, a network node, a data hall and a leased rack matters. Hosted capacity fails differently depending on which one is involved. If customer servers are in an owned or leased data hall with redundant power, cooling, access control, spare parts and carrier meet-me capability, the provider can make a stronger reliability claim. If servers sit in a smaller office-adjacent equipment room, the provider may still operate competently, but risk shifts toward power quality, access limits, fire suppression, cooling headroom and hardware stock.

If capacity is resold from another data-center operator, the customer needs to understand who controls hands-on access during incidents.

PeeringDB's netfac view for ITNS.NET returns no facility rows. That is one of the most important negative facts in this analysis. It does not justify a conclusion that ITNS has no facility presence. Many networks choose not to list facilities. It does mean the public PeeringDB record does not let a buyer verify that AS35346 is present in Data City, Trabia, Moldtelecom, an owned location or any other named site. The burden of proof therefore moves to contract documents, customer references, facility tours, provider diagrams or signed service descriptions.

The company site gives physical-plant confidence in another direction. The Layer 1 material describes construction and engineering practices around fiber routes and documentation. That supports the idea that ITNS understands outside plant and physical network deployment. It does not directly support claims about data-center maturity. A fiber operator can be good at trenches, ducts, splicing and access routes while relying on third-party colocation for servers. A hosting buyer should separate those questions.

Fiber capability can improve local access and private backhaul; data-center capability determines server survival during power, cooling and access events.

For this reason, the featured operational dependency is not "which cloud platform" but "which room." The question a customer should ask is concrete: where is the primary rack, where is the secondary rack, which power feeds serve them, which facility operator controls access, which carriers enter the room, how long does remote hands take, which spare disks and power supplies are stocked, and how are backups separated from the primary fault domain?

Installed capacity is not the same as usable capacity

Public sources show a meaningful network footprint. RIPEstat reports full current IPv4 visibility and substantial IPv6 visibility for AS35346. PeeringDB reports 50-100 Gbps traffic and two 10 Gbps exchange ports. The official site describes end-to-end infrastructure and application services. Those facts indicate installed capability. They do not tell a customer how much usable capacity remains after existing customers, oversubscription, maintenance reserves, DDoS headroom and port limits are considered.

This distinction is especially important for hosting economics. A provider can announce many IPv6 prefixes while still being constrained by IPv4 assignment, physical server count, storage performance, support staff or upstream commit. It can have 10 Gbps exchange ports while a particular hosted service is limited by a 1 Gbps uplink, a firewall, a shared storage array or a customer VLAN design. It can advertise 99.99 percent uptime while maintenance windows, restoration obligations and compensation terms remain private. Customers should not confuse address-space size with compute inventory, or exchange presence with spare server capacity.

The AS35346 address profile is still useful. IPv4 visibility of 6,400 addresses, if current and accurately attributed, is a material resource for a regional operator. It can support access customers, infrastructure, mail, hosting, NAT pools, monitoring and customer assignments. IPv6 announcements are also broad enough that an IPv6-capable hosting design is plausible.

But the business value depends on operational policy: whether customers can receive routed subnets, whether reverse DNS is delegated, whether provider firewalls sit in the path, whether abuse handling affects hosted customers, and whether address assignments are portable if the customer leaves.

AS202511 adds an unresolved capacity signal. A hosting-labelled AS can be useful if ITNS wants to isolate hosting routes from the general access network, apply separate upstream policy, accept customer prefixes or move workloads during maintenance. But because the AS was not currently announced in RIPEstat on 12 July 2026, it cannot be counted as live recovery capacity without additional evidence. A dormant AS can be an option; it is not a tested failover route until observed in operation.

The failure paths are ordinary, and that is why they matter

The most likely failure paths for a customer-facing hosted service are not exotic. They are rack, upstream, hardware-stock, support, billing, migration and provider-contract failures.

A rack or room failure is the simplest to understand. If the servers, storage and top-of-rack switching that host customer workloads lose power or cooling, customers experience downtime unless workloads fail over to a physically separate site. The public material mentions redundancy and high availability, but it does not publish a multi-site architecture. The correct buyer assumption is therefore cautious: redundancy is a claim to verify, not a fact to inherit from the existence of multiple exchange connections.

An upstream or routing failure is easier to see publicly. AS35346 has named upstreams and exchange peers, and RIPEstat sees current neighbours. That reduces single-upstream risk, but it does not eliminate routing failure. A misconfigured route filter, expired route object, invalid ROA, upstream dispute, route-server incident or DDoS blackhole policy can still affect hosted workloads. RPKI validity for some prefixes helps, but the routing-consistency output shows that registry and BGP views are not uniform across all announcements.

Customers with strict reachability needs should ask which prefixes their services use and whether those exact prefixes have valid RPKI, complete route objects and tested upstream acceptance.

Hardware-stock failure is harder to observe but often decisive. Hosted capacity becomes fragile when a provider has no spare drives, power supplies, optics, RAM, servers or switches on hand. ITNS's official pages emphasize engineering, vendors, monitoring and maintenance. They do not disclose spare-parts policy. A regional provider can still be resilient if it stocks common parts and has strong supplier relationships. But the public evidence does not let customers assume that a failed storage controller or server motherboard can be replaced the same day.

Support failure is another hidden dependency. The official site lists support and monitoring concepts, and PeeringDB lists a public NOC contact in the main network entry. That is a useful signal. The remaining questions are practical: who answers after hours, how incidents are escalated, whether the support desk can make network changes, whether remote hands are internal or facility-provided, whether billing issues can suspend service automatically, and whether customer backups are accessible during account disputes.

Migration failure is the quietest risk. The moment a customer needs to leave, hosted capacity stops being abstract. Can disk images be exported? Can DNS changes be coordinated? Can IP addresses move? Are backups in a standard format? Is there an out-of-band copy path if the provider network is impaired? Does the contract allow data retrieval after termination or non-payment? ITNS's public pages do not answer those questions. That is normal for many providers, but it is exactly why customers should address portability before an outage.

Data locality is plausible; data sovereignty is not automatic

The region in this assignment is MD, and the public evidence supports Moldova as the operating context. ANRCETI lists ITNS as a Moldovan provider. RIPE and PeeringDB list Moldovan addresses. The exchange presence is in Chisinau. The company's official site emphasizes Moldova's digital future, Moldovan fiber infrastructure and local engineering. Those facts make local hosting or local network dependency plausible.

Plausible locality is not the same as guaranteed data sovereignty. The public record does not show where customer disks sit. It does not show where backups are stored. It does not show whether managed applications use third-party platforms outside Moldova. It does not show whether administrative access, monitoring, email, DNS, ticketing, storage replication or security services depend on external vendors. A customer seeking Moldovan data residency needs a contract and architecture diagram, not only a Moldovan AS.

The network record also points beyond Moldova. Cogent is a global transit provider. RENAM is a local academic and research network context. MD-IX and KIVIX keep local traffic local where peers participate, but upstream transit by definition leaves the local exchange fabric. A hosted workload can be physically in Chisinau while depending on external transit, foreign DNS services, foreign payment processors or overseas backup targets. That is not a problem by itself. It simply means "hosted by a Moldovan operator" should not be translated automatically into "all dependencies stay in Moldova."

Data sovereignty due diligence should therefore be precise. Ask where primary data is stored, where backups are stored, who can access the environment, which jurisdictions cover subcontractors, which logs leave the country, and which emergency-recovery copy would be used after a site failure. The public ITNS evidence supports a local-operator thesis. It does not settle the data-location question for any individual customer.

Who is affected when ITNS-hosted capacity fails

The affected parties depend on which part of the ITNS stack the customer buys. For an ISP or smaller access provider buying network integration, a failure may affect last-mile customers, CPE provisioning, television headends, VoIP service or monitoring. For an enterprise buying managed hosting or cloud applications, the affected surface is customer portals, internal systems, surveillance storage, remote access, email, line-of-business applications or public websites. For a public institution, impact may include citizen-facing portals, local service delivery, fixed telephony or data exchange with other agencies.

The official ITNS pages repeatedly position the company as a partner for businesses, service providers, community infrastructure and public institutions. That broad target market makes the failure surface broader than a single hosting page would suggest. If ITNS is designing fiber, managing routing, operating application platforms and supporting portals, the same provider can sit in several dependency layers for one customer. That can simplify accountability in normal times, because one operator understands the whole path. It can also concentrate risk if the same operator controls access, routing, hosting and support.

The impact mechanism is latency first, reachability second, data access third and customer trust last. A partial routing impairment can make hosted services slow or regionally unreachable. A rack or storage failure can make them unavailable. A support failure can turn a short incident into a long one. A portability failure can trap customers during a provider dispute or extended outage.

Because ITNS has visible routing diversity but opaque facility and recovery evidence, the highest-priority due diligence is not "does the AS appear alive?" It is "can customer service survive the specific room, upstream, server and support failures that matter?"

What a customer should verify before relying on ITNS for hosted capacity

A customer does not need every private operational detail to use a regional hosting provider. It does need enough to understand its own risk. The first verification is site independence. Ask ITNS to identify the primary and recovery locations for the specific service, explain whether the locations share power, cooling, fiber entry, facility operator, upstream routers or storage, and show how failover is triggered.

The second verification is network independence. Ask which AS and which prefixes will carry the service, whether the service uses AS35346 or AS202511, whether the exact prefixes are covered by valid ROAs, which upstreams receive them, whether route objects exist, and how long a routing change takes during an incident. Public sources show that AS35346 is live and that AS202511 is assigned but not currently announced in RIPEstat. A customer should not accept a generic statement about "multiple providers" without prefix-level detail.

The third verification is hardware and storage recovery. Ask what components are stocked locally, what replacement time applies to disks and power supplies, whether storage is replicated, whether backups are immutable, how restores are tested, and how customer data can be exported without provider tooling. The public site speaks about monitoring and maintenance, but only customer-specific evidence can show restore maturity.

The fourth verification is support authority. Ask who can reboot a server, replace optics, edit BGP policy, release a backup, approve a migration or pause billing action outside office hours. A public NOC contact is valuable, but a hosted-service incident often crosses network, systems, storage and commercial boundaries. The person who answers the phone must have a path to someone who can actually change the state of the service.

The fifth verification is exit. Hosted capacity is least portable when the customer thinks about portability last. Before production cutover, the customer should know how to export data, how DNS and reverse DNS will move, whether IPs are portable, how long backups remain available after cancellation, and whether ITNS will provide emergency assistance if the customer migrates during an outage. These terms are not visible in public records, and that makes them contract work.

Evidence grade and bottom line

The evidence grade is Medium. The identity evidence is strong: ANRCETI, RIPE and PeeringDB all connect the subject to a Moldovan telecommunications operator. The network evidence for AS35346 is strong enough for dependency analysis: current announcements, broad visibility, valid RPKI examples, named upstream policy and exchange presence are public. The service evidence is moderate: ITNS itself mentions cloud applications and managed hosting, and a PeeringDB network named IPV4-HOSTING exists under the same organisation.

The facility and recovery evidence is weak: no public PeeringDB facility rows for the main network, no published rack map, no public restore tests, no status history, no backup policy and no customer portability terms.

That mix does not make ITNS a bad hosting dependency. It makes it a dependency that should be bought with eyes open. The public evidence supports a company that can plausibly deliver local network-integrated hosted services in Moldova. It does not support treating the service as a fully transparent multi-site cloud. For customers, the right posture is neither dismissal nor blind trust. It is technical verification: confirm the room, confirm the route, confirm the backup, confirm the spare parts, confirm the support escalation, and confirm how to leave if the dependency stops serving the business.