DorsaCloud and the Iranian record behind a cloud name

Summary

• DorsaCloud's strongest public identity anchors are its Persian cloud-service site, its terms naming Dorsa Expert System as the contracting entity, an Iranian e-commerce union listing for dorsacloud.com, and RIPE records for Dorsa Expert System PJS.
• The network evidence is specific and current: AS205134 is assigned as DorsaCloud, RIPE Stat showed it announced on July 14, 2026, 91.216.171.0/24 was visible with 256 IPv4 addresses, and the upstream relationship was recorded through Mobin Net's AS47330.
• The assurance gap sits around accountability, not mere existence: the public record shows service pages, documentation, tickets, phone support, a NOC hiring signal, and an active small network, but addresses, contact trails, SLA proof, facility control, certification evidence, IPv6 use, and support responsibility still need reconciliation before the brand is treated as a complete operating guarantee.

The first thing to take seriously about DorsaCloud is the name's speed. A cloud name moves faster than evidence. It invites a reader to imagine elastic compute, managed storage, edge delivery, security controls, local support, facility capacity, reliable routes, and a contract party that can be held to account when something fails. In mature infrastructure markets, that imagination is sometimes justified because the provider publishes the documentation, certification, routing, status, support, legal and abuse surfaces that make the claim testable. In quieter or younger markets, the same name can outrun the public proof.

DorsaCloud sits in the middle. It has more than a decorative brand. It also has less than the kind of public assurance package that would let a buyer stop asking questions.

The public face is clear enough to begin with. DorsaCloud presents itself through a Persian-language site at dorsa.cloud and through dorsacloud.com, which returned a Dorsa Cloud page in a July 2026 HTTP check. The site describes Abr Dorsa, or Dorsa Cloud, as a provider of cloud services. Its home page leads with cloud servers, CDN/DNS, cloud storage, Kubernetes clusters, and cloud Kubernetes. The message is not a single-product hosting page. It is a cloud platform pitch: compute, storage, networking, Kubernetes, edge services, documentation, a pricing calculator, and a login portal.

That matters because a public service surface is the first difference between a bare registry entry and a company asking users to depend on a platform.

The about page adds a legal and historical claim. It says DorsaCloud is active in cloud computing, was founded in Iranian year 1398, and provides cloud services and solutions for companies and organisations in areas such as cloud computing, cloud storage, network and cloud security. It also says the company is registered under the trade name Dorsa Expert System and is known as DorsaCloud. The site's terms sharpen that point by saying that the legal entity with which the user contracts is Dorsa Expert System, as defined in the DorsaCloud membership agreement. That sentence is more valuable than most of the marketing language around it.

It points from the brand to a counterparty.

RIPE records point to the same counterparty family. The organisation entity ORG-DESP1-RIPE names Dorsa Expert System PJS, country IR, with registration number 14010124962 // 580016, organisation type LIR, a Tehran address on Mina Boulevard near Nelson Mandela Boulevard, phone +982182804810, and an abuse contact through AR68208-RIPE. The AS entity for AS205134 carries the as-name DorsaCloud and the organisation ORG-DESP1-RIPE. In other words, the public internet registry trail does not leave the cloud name floating by itself. It ties DorsaCloud to Dorsa Expert System PJS and to a network resource holder in Iran.

That is the positive reading. The caution starts when the identity trail is compared across sources. DorsaCloud's own contact page gives a different public contact package from the RIPE organisation entity: it lists ticket submission inside the platform, phone contact at 021-91096338, an SMS short code, a contact form, info at dorsa.cloud, and an address in Tehran on Valiasr near Mirdamad, Alireza Daman Afshar street, No. 61, Capital Complex, Tower B, floor 14, unit 1402. The CDN product page footer, by contrast, gives the Mina Boulevard address and +98-21-82804810, matching the RIPE flavour more closely.

The Iranian e-commerce union listing for dorsacloud.com gives Abr Dorsa, the domain dorsacloud.com, owner Sasan Rasouli, a Tehran listing, a different phone number, and a Davoodiyeh address. None of that proves anything wrong. It does prove that the public identity file is not perfectly flat.

For infrastructure buyers, address variation is not clerical trivia. It affects who can be served, who can be sued, who can receive a notice, who controls a support escalation, and which record should be used when a platform is down. Companies move offices. Product pages are refreshed unevenly. Business-license pages lag behind operational reality. RIPE contact data may be maintained for network administration rather than customer service. All of that is normal.

But when a cloud brand asks users to trust compute, storage, content delivery and managed Kubernetes, the identity layer should be tidy enough that a contract reviewer can map the brand, the legal entity, the domain, the phone number, the network holder, and the support desk without guessing.

The Iranian e-commerce union listing is useful precisely because it is not a cloud marketing page. It records Abr Dorsa, business type design of websites, domain dorsacloud.com, owner Sasan Rasouli, a licence-validity date in the Iranian calendar, Tehran as province and city, an address, and a fixed phone number. The category is narrower and less infrastructure-heavy than DorsaCloud's own product catalogue. That does not cancel the cloud site. It shows a public licensing frame that may have started from a web-business classification rather than from a detailed cloud-provider taxonomy.

The right inference is modest: there is an Iranian public business listing connected to dorsacloud.com, but it should not be treated as a complete description of the platform's technical scope.

The site itself is much stronger on product breadth than on externally verifiable assurance. The cloud-server page describes an elastic compute service, installation of a preferred operating system, resource adjustment, direct control of infrastructure resources, cost management, and 24-hour support. It also claims information-security certification such as ISO27001 and gives availability figures of 99.975 percent for certain cases and 99.995 percent across different areas. Those are consequential claims. They belong in a buyer's checklist.

They also need documents behind them: certificate scope, issuing body, validity, covered service, service-credit terms, maintenance exclusions, incident reporting, and the exact architecture that makes the availability promise meaningful.

Without those documents, the cloud-server page should be read as a service claim, not as proof of service performance. That distinction is not hostile to DorsaCloud. It is the same standard that should be applied to any small or regional cloud. A vendor can write "24-hour support" on a page; assurance begins when the support process is clear enough that a customer knows whether that means a phone queue, ticket response, incident bridge, on-call engineer, network operations centre, remote hands, or best-effort messaging.

A vendor can write an availability percentage; assurance begins when the customer can see what is measured, what is excluded, who reports outages, and what happens when the service misses the target.

The CDN/DNS product page widens the ambition. It describes dynamic CDN, cloud DNS, load balancing, traffic management, SSL/TLS, edge security, DDoS mitigation, WAF, HTTP/2, HSTS, origin monitoring, failover, cache refresh, and shared IP behaviour based on SNI. It says the platform uses Anycast architecture and routes users to nearer or better nodes. This is the kind of language that demands network proof because CDN claims are not just software claims. They imply distributed serving, routing policy, edge placement, upstream quality, capacity planning, attack-handling, certificate handling and operational monitoring.

The public record does show an active network. It does not, by itself, show a global edge mesh.

That difference should shape the reading of every edge-service phrase on the site. DorsaCloud may well run domestic CDN nodes, partner-backed capacity, or a smaller anycast deployment appropriate to its market. The public evidence reviewed here does not map node locations, facility relationships, route collectors by node, DNS anycast sites, scrubbing capacity, WAF rules, or customer adoption. It shows a provider presenting CDN/DNS features and an autonomous system with one visible IPv4 prefix.

That is enough to support "there is service-proof material to examine." It is not enough to support "the CDN has the same footprint as the language might lead a hurried reader to imagine."

The Kubernetes and documentation trail is a second kind of proof. DorsaCloud's product pages discuss Kubernetes clusters and cloud Kubernetes, and the documentation site is organised around platform guides, cloud servers, Kubernetes clusters, object storage, VPC, CDN-DNS, cloud Kubernetes, login, account management, financial management and access management. Documentation does not prove customer scale. It does prove that the public product surface is not limited to a brochure. There is a user-guide structure for a platform with billing, access control, and technical products. For enterprise software automation, that matters.

A cloud without documentation is a slogan. A cloud with account, billing, access and product docs is at least presenting a self-service operating model.

The documentation still leaves a quality question. Some of the product copy on the public site reads broad, generic and at times awkwardly translated or borrowed from common cloud vocabulary. That is not unusual in regional cloud markets, where providers build product pages by adapting known service categories into local language and local support. But it means the analyst should give more weight to records that are hard to fake: the login portal, the support channels, the RIPE entities, the route object, the allocated prefix, the observed BGP announcement, and the business listing.

Marketing copy describes what the company wants to be understood as. Operational records show where the company is actually visible.

The strongest technical evidence is AS205134. RIPE's aut-num record shows AS205134, as-name DorsaCloud, organisation ORG-DESP1-RIPE, import from AS47330 accepting any, export to AS47330 announcing AS205134, status assigned, maintained by DorsaCloud-MNT and RIPE-NCC-END-MNT, created on May 11, 2022, and last modified on January 1, 2025. AS47330 is Mobin Net Communication Company. That means DorsaCloud's public routing entity is not an isolated label. It identifies a specific autonomous system and a specific upstream relationship in the Iranian network environment.

RIPE Stat makes the route current. Its AS overview for the July 14, 2026 query window showed the holder as DorsaCloud Dorsa Expert System PJS and marked the AS as announced. Its announced-prefixes data showed 91.216.171.0/24 visible from June 30 to July 14, 2026. Its routing-status data showed one IPv4 prefix, 256 IPv4 addresses, zero visible IPv6 announced space, 324 of 326 IPv4 RIS peers seeing the route, and one observed neighbour. The last-seen entry at the query time was 91.216.171.0/24 originated by AS205134. That is concrete present-tense network evidence.

The RIPE database also explains the resources behind that view. A search for 91.216.171.0/24 returns an inetnum allocation from 91.216.171.0 to 91.216.171.255, netname IR-DORSAEXPERTSYSTEM-20230517, country IR, organisation ORG-DESP1-RIPE, status allocated PA, created May 17, 2023. The route object for 91.216.171.0/24 originated by AS205134 was created the same day and maintained by DorsaCloud-MNT. A separate RIPE search for 2a12:d9c0::/29 returns an IPv6 allocation, netname IR-DORSAEXPERTSYSTEM-20220428, country IR, organisation ORG-DESP1-RIPE, status allocated by RIR, created April 28, 2022.

In the July 2026 routing-status view, however, IPv6 announced space was not visible.

That mix is important. DorsaCloud has a live IPv4 route and an IPv6 allocation, but the visible network at the July 2026 query point was small: one announced IPv4 /24 and no announced IPv6 /48s. BGP.he and BGP.tools both corroborated a compact picture: AS205134 as Dorsa Expert System PJS or DorsaCloud, one originated IPv4 prefix, no originated IPv6 prefix, one observed IPv4 peer or upstream, and a valid RPKI-originated IPv4 route. IP2Location and IPinfo added secondary corroboration that the AS is associated with Dorsa Expert System PJS, Iran, and the Dorsa domains, with the visible IPv4 range at 91.216.171.0/24.

These sources do not all measure the internet in the same way, but they point in the same direction.

The direction is neither empty nor large. A single /24 is a real routable operating surface. It can support authoritative services, control-plane endpoints, a login portal, customer workloads, DNS, CDN front doors, management systems, or a small hosting environment. It is also only 256 IPv4 addresses. It does not, by itself, evidence a large public-cloud footprint. The single observed upstream relationship through Mobin Net also matters.

It may be perfectly reasonable for a domestic provider, but it means outside observers should ask how DorsaCloud handles upstream failure, route diversity, DDoS events, customer isolation and traffic engineering. One route can be visible and still leave resilience questions open.

No PeeringDB network record was visible for AS205134 in the July 2026 record set, and that should also restrain the profile. PeeringDB is not mandatory for an operating network, especially for a regional or domestic provider that peers privately or relies on upstream transit. But if a cloud or CDN brand wants to present itself as a major interconnection actor, PeeringDB is often one place where facility presence, IX participation and peering policy become visible. For DorsaCloud, the public internet evidence is RIPE-led rather than PeeringDB-led: assigned AS, allocated resources, current route, upstream, and route visibility.

That is a solid registry and BGP trail. It is not a public interconnection map.

There is one more service-proof clue in the HTTP surface. The dorsacloud.com response in the July 2026 check returned Dorsa Cloud server and CDN-related headers, including Dorsa Cloud as server and CDN provider. This is self-referential evidence, not third-party capacity proof. It shows the DorsaCloud web property being served through a Dorsa Cloud-branded edge or server layer. It does not show that customers receive the same service, how many nodes exist, or what the edge architecture looks like. Still, it is more concrete than a product paragraph.

A cloud that uses its own platform for its public property is at least leaving a technical fingerprint to inspect.

The labour surface is more visible than the staff surface. DorsaCloud's contact page presents tickets, phone, SMS, form and email. The cloud-server page claims 24-hour support. A public LinkedIn company page included a Persian hiring post for a NOC specialist, including day and night shifts, familiarity with data-centre structure, hardware troubleshooting, continuous monitoring of network, infrastructure and services, incident analysis, documentation, Zabbix or PRTG, ELK or Prometheus and Grafana, dashboards, Network+ level concepts, Linux, internet services, shift work and on-call experience.

That is unusually specific support-labour evidence for a small cloud profile.

It should still be read as a hiring signal, not a staff audit. A job post can show what capabilities the company seeks. It does not show whether the role was filled, how many engineers are on duty, whether there is always an escalation path, or whether the same team handles cloud servers, CDN, DNS, Kubernetes, hardware, billing and abuse. The value of the post is that it connects the public support claim to a plausible operational role. It uses the vocabulary of real infrastructure monitoring and incident response. The limit is that it does not publish the actual NOC roster, coverage schedule, incident metrics or escalation tree.

Support accountability is where DorsaCloud looks most real and most unfinished at the same time. Real, because the company publishes a contact page, a platform ticket mechanism, a phone number, an email address, customer documentation, and evidence of NOC hiring. Unfinished, because the public contact record is split across addresses and phone numbers, the terms are broad, the certificate and SLA claims are not accompanied by the kind of public evidence a regulated buyer would expect, and the network trail shows a compact dependency surface. The company may have all the private documentation a customer needs.

The public record does not let an outside reader verify it without asking.

That distinction matters especially for data sovereignty and locality. DorsaCloud is an Iranian cloud brand with Iranian contact points, Iranian business listing evidence, RIPE organisation country IR, Iranian IP resources, and a domestic upstream relationship. For customers whose first question is "is there a local Iranian cloud provider behind this name?", the answer is yes, on the public evidence.

For customers whose question is "does this prove where my data is stored, who can access it, how it is replicated, what law governs it, how incidents are handled, and whether there is independent certification?", the answer is no. Locality is the start of the inquiry, not the end.

An Iranian local-cloud profile has its own reasons to matter. Domestic businesses may need local-language support, local billing, lower domestic latency, alignment with national connectivity realities, and a provider that understands the Iranian hosting and access environment. DorsaCloud's product catalogue is built around exactly the services such customers might seek: elastic compute, object storage, private cloud or VPC, DNS, CDN, load balancing, Kubernetes, SSL/TLS and platform management.

A small domestic network can be economically rational if the intended market is local and the operating model uses carefully chosen upstreams and partner infrastructure. The problem is not that the footprint is small. The problem is that the assurance should be scaled to the footprint.

The CDN claim is a good example. If DorsaCloud's CDN is primarily domestic, a single visible AS with one /24 does not necessarily disqualify it. The architecture could include origin shielding, partner nodes, DNS steering, reverse proxies, or addresses not obvious from AS205134 alone. But the public claim should then be evaluated against specific customer proof: anycast announcements, DNS test points, traceroutes from Iranian networks, route collectors, node lists, cache behaviour, WAF logs, DDoS runbooks and support response.

Without that, the safe public statement is that DorsaCloud advertises CDN/DNS services and has a live DorsaCloud AS, not that its advertised edge capacity has been independently mapped.

The same caution applies to Kubernetes and cloud automation. Product pages can describe automatic scaling, cluster creation, managed namespaces and self-service resources. Those are product promises. The documentation site's sections on platform login, account, financial management and access management are better evidence that a platform workflow exists. But managed Kubernetes assurance needs more: supported versions, control-plane ownership, upgrade policy, network plugin, storage classes, backup model, isolation, vulnerability response, logging, audit access, and how the provider handles a failed node or compromised workload.

DorsaCloud's public material gives enough to know what questions to ask. It does not answer all of them.

The terms of use are revealing in a quieter way. They define the relationship around the DorsaCloud platform, product services and membership agreement; they say users must register to access product services; they reserve DorsaCloud's right to restrict or suspend access in certain circumstances; and they state that services or features may differ by area and country, with no guarantee that a specific service, feature or level is available everywhere or for all users. That is standard platform-lawyer language, but in a cloud context it reinforces the need to separate website feature lists from contracted service commitments.

The public product menu is not the contract.

There is also a difference between platform existence and platform maturity. DorsaCloud's docs, login portal, product pages and contact routes make the platform real enough to inspect. They do not show operational maturity by themselves. Maturity would be visible through status history, maintenance notices, security advisories, abuse handling, API documentation, change logs, product limits, backup-retention rules, incident-review habits and a clear line from support contact to technical authority. Some of those materials may sit behind the customer portal. Public readers cannot assume they exist merely because the product menu does.

A cloud platform's strongest proof often appears in the dull places where customers learn what breaks, what is limited and how the provider behaves when normal service is interrupted.

The IPv6 allocation is a useful example of why that maturity layer matters. RIPE shows 2a12:d9c0::/29 allocated to the Dorsa Expert System organisation. That is a significant resource marker. Yet RIPE Stat's July 2026 routing-status view showed no IPv6 announced space for AS205134. There may be a reasonable explanation: the provider may be preparing IPv6, may route it elsewhere, may reserve it for future expansion, may use only IPv4 for public services, or may have customer products that do not need public IPv6. The point is not to score the absence as a failure. It is to prevent resource possession from turning into deployment proof.

In cloud diligence, "allocated" and "announced" are different verbs.

The same verb discipline applies to the IPv4 route. DorsaCloud originates 91.216.171.0/24, and that route was widely visible in RIPE's RIS peer view. That supports a present-tense network claim. It does not tell the reader what sits behind each address. It does not reveal whether cloud customers receive addresses from that block, whether the block serves DorsaCloud's own control plane, whether CDN front doors live there, or whether other unexamined resources support the platform.

The safest statement is that DorsaCloud has a visible AS205134 IPv4 surface and that the surface is small enough that capacity, resilience and segmentation should be confirmed directly before high-dependence use.

An abuse and security reader would ask a slightly different set of questions. RIPE gives an abuse contact entity for the organisation, while the customer-facing site gives general support contact routes. That is a useful split, but public documentation should ideally explain where to send abuse complaints, vulnerability reports, law-enforcement requests, data-access concerns and customer incidents. The more a provider advertises CDN, DNS, load balancing and WAF services, the more likely it is to receive complaints about hosted content, phishing, malware, traffic floods and misconfigured origins.

A visible route and a cloud product menu make the abuse surface real. Public contact clarity determines how quickly an outside party can act on it.

There is a commercial version of the same issue. DorsaCloud's documentation includes account, financial and access-management topics, which suggests an ordinary platform relationship: register, charge an account, manage users, buy or operate services. But a company buying infrastructure needs to know more than how to log in. It needs to know whether invoices come from Dorsa Expert System, what currency and tax treatment apply, what happens to prepaid balances if service is suspended, whether support is bundled or tiered, whether the provider can change regions or features, and what export or deletion process exists if the customer leaves.

Public cloud trust is built from these administrative details as much as from routers.

The product catalogue also mixes commodity cloud labels with local-market expectations. Cloud server, object storage, VPC, CDN, DNS and Kubernetes are globally familiar names. In a domestic Iranian context, the value proposition may be very different from the global hyperscale meaning of those labels. Local latency, Farsi support, local payment, domestic connectivity and familiarity with Iranian network conditions may matter more than region count or global interconnects. That is a legitimate market position. It should be named as such. A local cloud can be useful because it is local, not because it imitates a global cloud word for word.

That framing protects both DorsaCloud and the reader. It protects DorsaCloud from being judged only against the scale assumptions of hyperscale providers. A small Iranian cloud with one public /24 may still serve a real customer segment if its services are reliable, support is responsive and contracts are clear. It protects the reader from assuming that familiar product names carry familiar global assurances. "Cloud server" does not automatically mean the same redundancy model everywhere. "CDN" does not automatically mean a global edge.

"Kubernetes" does not automatically mean the same upgrade, isolation or control-plane guarantees. The local record must be allowed to speak in its own size.

The public record would become much stronger if DorsaCloud published a compact trust page. It would not need to reveal sensitive architecture. It could state the legal entity, registration number, current registered address, customer support address, network operations contact, abuse and security contacts, certificate scope, service-status page, broad data-location policy, upstream or facility dependency at a high level, SLA document, and a statement about IPv6 availability.

That kind of page is often more valuable than another product paragraph because it connects the public identity, service claim and network resource into one accountable surface. DorsaCloud already has many of the ingredients scattered across pages and registries. The gap is consolidation.

For a buyer, the contract should resolve six public uncertainties. The first is the legal counterparty: Dorsa Expert System, Dorsa Expert System PJS, the brand Abr Dorsa, and the domain dorsacloud.com should be tied into one signed agreement. The second is the current address and notice channel: the RIPE address, website address, CDN-page address and e-commerce union address should be reconciled. The third is the support model: ticket, phone, SMS, NOC, incident bridge, response time and escalation authority.

The fourth is the infrastructure model: where the workloads run, which facilities and upstreams are used, whether AS205134 is customer-facing, and how DDoS or routing incidents are handled. The fifth is data handling: residency, backups, subcontractors, access logs, encryption and deletion. The sixth is proof: certificates, SLA terms, status records, and audit documents.

Those questions are not a disguised accusation. They are what a cloud name should expect. DorsaCloud has enough public proof to deserve a serious profile. It has an operating website, product pages, documentation, published contact points, an Iranian public business listing, RIPE organisation and AS records, an active IPv4 announcement, and visible support-labour language. It is not a scraped orphan name or a directory-only placeholder. The danger is the opposite: because the evidence is real, a reader may promote it too quickly into a broad assurance statement. Real evidence still has a scope.

The scope should be written carefully. DorsaCloud can be described as an Iranian cloud-service brand associated with Dorsa Expert System PJS, presenting compute, storage, CDN/DNS and Kubernetes services, with public documentation and customer-contact paths. Its network-resource evidence supports a live, small AS205134 footprint with one announced IPv4 /24 through Mobin Net and an allocated IPv6 /29 not visible as announced in the July 2026 query. Its support surface supports the existence of ticket, phone, email and NOC-oriented labour signals.

Its public record does not support claims that it operates a large independent cloud network, a fully mapped CDN edge, or a verified certification/SLA programme without further documentation.

That distinction is what the DorsaCloud directory entry needs most. Directory evidence should anchor the entity, not inflate it. If a directory reader sees the name and the cloud category, the profile should not let the word cloud do the work. It should show the legal trail, the service pages, the network resources, the contact surface, the support signals and the unresolved gaps. It should also preserve the temporal state: AS205134 was visible on July 14, 2026 with 91.216.171.0/24; that is stronger than an old allocation, and narrower than a multi-prefix network. Good directory intelligence is not shy about either half.

The public network record also changes the way risk should be framed. With some cloud names, the question is whether there is any infrastructure signal at all. With DorsaCloud, the question is how much can be inferred from a compact but real signal. One announced /24, one upstream, one route object and a route visible to hundreds of RIS peers demonstrate reachability. They do not demonstrate redundancy. They do not demonstrate customer density. They do not demonstrate that all advertised services sit on that AS. They do not demonstrate ownership of the physical facility. They do not demonstrate a mature abuse desk.

Those are separate surfaces.

The address trail is similar. Multiple public addresses can reflect growth, office moves, legal administration, separate product templates, stale footer data, or different roles for business licensing and network records. The public record does not say which. The diligence point is that a service buyer should not wait for an outage to discover which address and phone number count. A clean supplier pack would state the brand, legal entity, registration number, tax or licence identifier, current registered address, support address, network-administration contact, abuse contact, and contractual notice address in one place.

DorsaCloud's public pages move in that direction but do not fully finish the map.

The support evidence deserves the same balanced treatment. The job language around NOC work sounds operationally serious: hardware troubleshooting, continuous monitoring, incident analysis, regular documentation, monitoring platforms, dashboards, Linux, network concepts, shift and on-call work. That is not decorative. It shows the company is thinking in the categories of real infrastructure operation. But hiring for a NOC role is also a sign that the organisation may be building or expanding the very capacity that buyers need.

The public reader should value the signal and still ask for the current roster, duty hours, escalation time and incident examples.

The service pages' security language is the other place where buyers should slow down. A claim of ISO27001, DDoS mitigation, WAF, end-to-end encryption, access control and automatic backup is meaningful only when attached to scope. Does the certificate cover the legal entity or only a parent or partner? Does it cover the cloud platform, a data centre, a support process, or a broader management system? Does DDoS mitigation occur on AS205134, through Mobin Net, through a third party, or at an application layer? Are backups in the same facility, same country, or another jurisdiction?

Security words can be accurate and still incomplete unless their boundaries are public.

For an Iranian customer comparing local providers, DorsaCloud's public record may be enough to justify a sales conversation. It shows a platform, not just a name. It shows network resources, not just a product list. It shows contact routes, not just a logo. It shows documentation, not just a landing page. It shows a local business listing and a named legal entity, not just a social media profile. That is a meaningful baseline. The next step is private evidence: account trial, contract, invoice, support test, route test, data-location answer, SLA, certificate, and incident process.

For an international analyst, the record should be handled with even more care. The fact that the AS and resources are in Iran is central, not incidental. It affects routing paths, sanctions exposure, payment practicalities, legal remedies, latency, data governance, and resilience assumptions. A domestic Iranian service can be exactly what a local business needs and still be unsuitable for another buyer's compliance environment. The public profile should not moralise the geography. It should make the geography explicit so users understand which assurances are local, which are technical, and which require legal review.

The most useful final label is therefore neither sceptical nor promotional. DorsaCloud is a publicly visible Iranian cloud platform brand with a real Dorsa Expert System identity trail and an active AS205134 network-resource footprint. Its product surface is broad: compute, storage, CDN/DNS, Kubernetes, private-cloud-style networking, documentation, billing and access-management workflows. Its public support surface includes tickets, phone, SMS, email and a NOC-hiring signal.

Its assurance surface remains incomplete: public address consistency, legal counterparty mapping, SLA detail, certification scope, facility responsibility, route diversity, IPv6 deployment and incident accountability all need direct confirmation.

That is enough to keep the name from being dismissed. It is not enough to let the name become the evidence. DorsaCloud's record is strongest when it is read as a set of anchored facts: Dorsa Expert System PJS in RIPE, AS205134 assigned as DorsaCloud, 91.216.171.0/24 announced in July 2026, one observed upstream through Mobin Net, dorsa.cloud product and documentation pages, dorsacloud.com business listing evidence, and public support channels. The record becomes weaker when those facts are stretched into claims about platform scale, CDN reach, certification, or always-on support without the documents that would prove them.

The responsible reading is a disciplined middle. There is an Iranian record behind the cloud name. There is service-proof material beyond a logo. There is a live network clue that deserves real weight. There is also a boundary around what the public record can prove. Before DorsaCloud is treated as operating assurance, the buyer or directory reader should reconcile the legal entity, verify the support and notice channels, test the route and platform, request the SLA and certificate scope, and ask where the data actually resides. A cloud name is allowed to invite trust. It earns assurance only when those answers line up.