Summary

  • Hoang Dieu Physical Server Company Limited is not an empty name. The APNIC RDAP record for AS153415 identifies HOANGDIEUVNCLOUD-VN and points to Hoang Dieu Physical Server Company Limited in Vietnam. APNIC also lists 160.191.242.0/23 and 2001:df4:9bc0::/48 under the same network name and contact domain.
  • The operating evidence is weaker than the registry evidence. RIPEstat's AS overview for AS153415 marks the Physical Server ASN as not announced, and RIPEstat's routing-status view shows no visible IPv4 or IPv6 announcements for that AS on 12 July 2026.
  • The company's IPv4 block is nevertheless visible on the public internet. APNIC's whois route object for 160.191.242.0/23 lists origin AS153416, while RIPEstat's AS153416 announced-prefixes view shows 160.191.242.0/23 and 160.191.244.0/23 currently visible from AS153416. That means the Physical Server address space is routed through the adjacent Hoang Dieu Cloud Computing network, not through AS153415 in the public view checked for this article.
  • The contact domains are also thin as public service surfaces. hoangdieuvps.pro and serverhoangdieu.pro have NS, MX and TXT records, including Zoho mail verification, but local DNS checks found no A or AAAA records. Mail and registry contact evidence exists; a public web-service catalogue did not resolve during this review.
  • The evidence grade is Weak. The entity has APNIC/VNNIC-backed resources, current route-origin validation for the AS153416 origin, and a concrete Hai Phong address in registry records. The downgrade is for the unannounced company ASN, the cross-origin route pattern, the lack of visible website endpoints, the absence of PeeringDB records, no published facility or support model, and no public proof of multi-site recovery, hardware stock or customer data portability.

The signal is real, but it points sideways

Hoang Dieu Physical Server Company Limited sits in a familiar corner of the hosting market: the public record says enough to prove that internet-number resources exist, but not enough to show how a customer-facing service is operated. The company name appears in APNIC and VNNIC-fed records. The resources have recent registration dates. There is an administrative and technical contact. There is an IPv4 /23. There is an IPv6 /48. There is an autonomous-system number. These are not marketing ornaments. They are the formal resource layer that lets a company place its own routes and hold addresses in the public internet registry system.

Yet the first surprise is that the obvious AS is not the AS doing the work in public route collectors. AS153415, the APNIC record that names Hoang Dieu Physical Server Company Limited, is visible in registry data but not in the RIPEstat route view checked on 12 July 2026. RIPEstat's announced-prefixes response for AS153415 returns no current prefixes. RIPEstat routing status for AS153415 shows zero visible IPv4 prefixes, zero visible IPv6 prefixes and zero observed neighbours.

The Physical Server address space is not necessarily idle. APNIC's whois data for 160.191.242.0/23 includes a route object with origin AS153416, and RIPEstat's announced-prefixes response for AS153416 shows two current IPv4 /23 announcements: 160.191.242.0/23 and 160.191.244.0/23. The first block is registered to Hoang Dieu Physical Server Company Limited. The second block is registered to Hoang Dieu Cloud Computing Company Limited. Both sit at the same stated address in Hai Phong in APNIC whois data, but they are different named registry entities. The public route view therefore points sideways: the Physical Server resource is being originated by the Cloud Computing AS.

That can be legitimate. A small hosting group can centralize routing in one AS while holding separate resource records for separate companies or service brands. A provider can prepare one AS for future use while announcing the addresses from a related operator's AS. A recently registered network can stage resources before moving routes. But the buyer cannot treat that as a solved problem.

When the registry owner, the route origin, the service brand and the support contact are not all the same in the public view, the buyer has to know who can actually make changes at 03:00, who pays the upstream, who can withdraw a route, who can restore a server and who can approve a customer migration.

The distinction is especially important because the company name says "Physical Server." That label implies a service whose promise is grounded in machines, not only in a control panel. A physical-server offer normally depends on cabinet space, power, cooling, switches, carrier ports, out-of-band access, spare drives, replacement nodes, abuse handling, reinstall procedures and remote-hands access. A public AS record cannot prove any of that. It tells the buyer where to begin the test.

What APNIC says the company controls

The strongest identity evidence is the APNIC RDAP autonomous-system record for AS153415. It lists the handle AS153415, the name HOANGDIEUVNCLOUD-VN, active status, country VN and a registration event dated 13 November 2024. The related APNIC whois output describes the holder as Hoang Dieu Physical Server Company Limited and gives an address at 162 Thuong Duc Street, Nguyen Hue Residential Group, Minh Duc Ward, Do Son District, Hai Phong City, Vietnam. The APNIC record also lists the contact handle NTH41-AP, a Vietnamese phone number and the email domain hoangdieuvps.pro.

The address-space evidence is similarly concrete. APNIC RDAP for 160.191.242.0 covers 160.191.242.0 through 160.191.243.255, names the block HOANGDIEUVNCLOUD-VN, marks it active, places it in Vietnam and lists the same contact domain. APNIC whois describes it as an assigned portable block for Hoang Dieu Physical Server Company Limited. A /23 is 512 IPv4 addresses before operational reservations. In a small dedicated-server or VPS business, that is meaningful enough to support public endpoints, management addresses, customer assignments, shared services or a transitional pool.

APNIC also lists 2001:df4:9bc0::/48 under the same network name and company record. An IPv6 /48 gives a provider enough address space to number many customer networks or internal segments. It is a useful modernity signal, but it is not a proof that IPv6 service is active. RIPEstat's route view for AS153415 saw no visible IPv6 announcements. RIPEstat's AS-routing-consistency view for AS153416 also lists the Physical Server IPv6 /48 as present in whois but not in BGP at the query time. The resource is registered; public use is not visible in that collector view.

Those facts are enough to reject a simple "no evidence" conclusion. Hoang Dieu Physical Server Company Limited has an assigned AS, an IPv4 block and an IPv6 block in public registry systems. The records are recent and coherent around a Vietnamese address and contact domain. A customer or competitor can use these records to identify the likely operator behind observed services if those addresses appear in logs, abuse reports or reverse-DNS data.

The same facts are not enough to conclude that the company has a fully operating hosting platform. Number resources can be assigned before a service launches. They can be routed by another AS. They can be reserved for future work. They can be used for internal management rather than customer hosting. They can be held by one company while a related company or supplier operates the network. Registry status is necessary evidence for this kind of provider, but it is not sufficient evidence of service resilience.

What the public BGP view shows instead

The public route view shifts attention from AS153415 to AS153416. APNIC RDAP names AS153416 as DTDMVNCLOUD-VN and APNIC whois describes it as Hoang Dieu Cloud Computing Company Limited at the same Hai Phong address. RIPEstat's AS overview for AS153416 marks that AS as announced. RIPEstat routing status for AS153416 shows two visible IPv4 prefixes, 1,024 IPv4 addresses, no visible IPv6 prefixes and one observed neighbour on 12 July 2026.

The two visible IPv4 prefixes are revealing. RIPEstat announced prefixes for AS153416 lists 160.191.242.0/23 and 160.191.244.0/23. APNIC whois ties 160.191.242.0/23 to Hoang Dieu Physical Server Company Limited, while APNIC RDAP for 160.191.244.0 ties 160.191.244.0/23 to Hoang Dieu Cloud Computing Company Limited. In other words, AS153416 is publicly originating both the Cloud Computing block and the Physical Server block.

That pattern may be administratively efficient. It might mean one operations team routes both blocks. It might mean the Cloud Computing entity operates the external edge while the Physical Server entity owns one address pool. It might be a temporary state around launch, migration or route-policy consolidation. Public data does not let an outsider choose among those explanations. What it does allow is a practical question: if a customer buys a physical server from the Physical Server company and the routed address sits behind AS153416, which legal and support entity is accountable for an outage?

The route-origin evidence is cleaner than the brand boundary. RIPEstat route-origin validation for AS153416 and 160.191.242.0/23 returned valid, with a validating ROA for origin AS153416. The same validation for 160.191.244.0/23 also returned valid. That is better than an unknown routing-security state. It means the visible origin for both /23s is authorized in the public validation view checked for this article.

The contrast is useful. RIPEstat validation for AS153415 as origin of 160.191.242.0/23 returned invalid_asn because the validating ROA authorizes AS153416, not AS153415. That does not mean the current route is wrong. It means the route is meant, in validation terms, to be originated by AS153416. For a buyer, that makes AS153416 the live network dependency even when the commercial conversation uses the Physical Server company name.

One observed neighbour is not the same as carrier diversity

RIPEstat's ASN-neighbours view for AS153416 observed one left-side neighbour: AS140810. RIPEstat AS-routing-consistency for AS153416 also lists AS140810 as present in BGP imports and exports but not in whois policy. In the same consistency view, the two IPv4 /23s are present in both BGP and APNIC whois, while the two IPv6 /48s are present in whois but not visible in BGP.

This is a narrow public transit picture. It does not prove there is only one supplier in the contract stack. Some backup links are silent until failure. Some sessions are not visible to RIPE RIS peers. Some small networks receive service through a reseller or an upstream that hides part of the physical delivery. Still, the public view does not demonstrate active multi-carrier routing. If a buyer wants to rely on hosted capacity here, that buyer should ask for evidence that the AS153416 edge can survive the loss of AS140810, the upstream path behind AS140810 and the facility path that carries it.

Looking-glass data for 160.191.242.0/23 and 160.191.244.0/23 shows longer global paths reaching AS153416 through networks such as AS18403, AS3491, AS2914 and others before AS140810 appears near the origin. Those intermediate AS paths show global propagation, not customer-facing redundancy at the Hoang Dieu edge. A route can be visible around the world and still depend on a single local handoff, a single remote port, a single router or a single commercial account near the origin.

Carrier diversity needs to be tested in physical and operational terms. Are there two upstream contracts? Are there two independent fibre entries? Are the cross-connects in separate ducts or simply separate logical circuits in the same room? Is one upstream sized to carry full traffic if the other fails? Are both maintained outside the same billing account? Does the team rehearse route withdrawal and failover? Can support reach the upstream after hours? None of those answers appears in the public record.

For a physical-server customer, the risk is not abstract. A dedicated server can be healthy while a single upstream problem makes it unreachable. A provider can have spare IPv4 addresses while a single switch or cross-connect limits recovery. A network can have valid RPKI while still losing reachability because the authorized origin depends on one upstream path. Public route visibility tells the buyer where to watch. It does not replace a failure exercise.

The service surface is thinner than the number-resource surface

The contact domains also support a cautious reading. Local DNS checks for hoangdieuvps.pro found Namecheap-style name servers, Zoho MX records and TXT records including Zoho mail verification and SPF. The checks did not find A or AAAA records. The same pattern appeared for serverhoangdieu.pro: NS records, Zoho mail records and TXT records, but no A or AAAA records. The contact email domains therefore look usable for administrative mail, but they do not expose a public service website in these checks.

This does not prove there is no customer portal. A provider can use a different domain, private portals, social channels, marketplace listings or direct sales. The service might be early, private, wholesale or focused on customers reached through a reseller. It might also be a resource holder rather than a public retail host. But the lack of resolving web endpoints is an evidence limit. A buyer cannot inspect current plan terms, acceptable-use rules, support channels, service credits, backup options, reinstallation terms, operating locations or customer exit rights from these domains.

The absence matters because the company name promises physical hosting. Dedicated-server and VPS providers normally publish some combination of server specifications, locations, bandwidth allowances, anti-abuse rules, service-level commitments, operating-system reload options, billing terms and support contacts. The public record reviewed here gives registry contact evidence, mail setup and route evidence. It does not provide a customer-facing contract surface.

That makes procurement harder but not impossible. Buyers can ask directly for the missing service documents. The key is to separate "the company has internet resources" from "the company has a recoverable hosting service." The first statement is supported by APNIC and RIPEstat. The second needs contract and operating evidence that is not visible in the public pages checked for this article.

PeeringDB does not fill the gap. Public PeeringDB API lookups for AS153415 and AS153416 returned no network record. That absence is not a verdict. Many small networks and private hosting operators do not maintain PeeringDB profiles. But it removes a common place to inspect facilities, exchanges, peering policy, traffic estimates and network contacts. Without that profile, the buyer has fewer independent ways to compare marketing claims with interconnection reality.

Physical hosting still starts with rooms, power and hands

If Hoang Dieu Physical Server is selling bare metal, VPS or server-hosting capacity, the product is ultimately physical. A machine has to sit somewhere. The building has to provide power and cooling. The router or switch has to connect to an upstream. Someone has to replace a failed disk, reboot a hung server, reinstall an operating system, release a blocked billing account or migrate a customer's data. None of that is visible in an AS record.

The APNIC address in Hai Phong is useful as an administrative anchor, but it should not be read as a data-centre location. Company and resource records often list offices, notice addresses or network-administration contacts rather than the room where servers run. The buyer should ask where production servers sit, who owns the racks, who controls access, whether any site is outside Hai Phong, and whether the provider uses leased data-centre space, a local facility, another Vietnamese network, offshore capacity or a mixed model.

Power design is the next question. Dedicated hosting customers often focus on CPU, RAM, disk size and bandwidth. Those are normal commercial features, but they are not the main outage controls. The customer needs to know whether the facility has redundant utility feeds, UPS and generator arrangements, separate power distribution to racks, tested maintenance procedures and an escalation path when remote power cycling or hardware access is required. If the provider is dependent on a third-party room, the customer should know what remote-hands rights and spare-parts terms exist.

Hardware stock is another practical constraint. A provider can sell physical servers faster than it can replace them if it lacks spare drives, memory, power supplies, optics or full nodes. Small hosts often rely on supplier delivery rather than stocked parts. That can be economical, but it changes the recovery clock. A customer buying critical capacity should ask which parts are on site, which parts are ordered as needed, and what happens when a replacement server has to be provisioned during a broader outage.

Support authority ties the physical layer to the commercial layer. The public contact records identify technical contacts, but they do not show after-hours coverage, escalation tiers, response commitments, billing controls, data-export rules or customer notification practices. In a server outage, the fastest engineer is not enough if that engineer lacks building access, account authority, upstream permission or customer approval to move data. The service has to be organised so that the person who receives the incident can reach the person who can fix the relevant layer.

The route-origin design changes the failure story

The most distinctive feature in this case is the route-origin split. Hoang Dieu Physical Server holds the 160.191.242.0/23 resource record, while AS153416 is the authorized and visible origin for that block. That arrangement can be sensible, but it creates a contract question. If the Physical Server company sells service on addresses in the 160.191.242.0/23 block, the customer should confirm whether AS153416 is operated by the same team, by a related entity, by a supplier or by a shared network platform.

The answer determines who can fix outages. If one team controls both companies and AS153416, the split may be mostly administrative. If the companies have different support teams, a customer issue might have to cross an internal boundary. If AS153416 is run by a third party, routing changes might depend on supplier support. If the Physical Server brand is a reseller, the customer's exit rights and incident communications may depend on reseller terms rather than the AS operator's terms.

The practical test is documentation, not reassurance. A buyer should ask for the current prefix announcement table, the route-origin authorization owner, the upstream handoff behind AS140810, and the person or team allowed to change those records during an incident. Those details can be shared privately without exposing router passwords or facility diagrams. They would show whether the Physical Server company can act directly on the live route, whether it has to request action from the Cloud Computing company, and whether the customer has any remedy if that internal handoff delays recovery.

RPKI makes the current design clearer. The valid ROAs for AS153416 and the invalid_asn result for AS153415 as origin mean the public routing-security configuration expects the Cloud Computing AS to originate the Physical Server block. That is useful evidence, but it also means a sudden move to AS153415 would require route-origin authorization changes to avoid validation problems. A buyer should ask how changes are approved, who can update ROAs, and how quickly route-origin records can be repaired if a migration or emergency reroute is needed.

This matters during provider failure. Suppose the physical server is reachable through 160.191.242.0/23 and the AS153416 edge fails. Can Hoang Dieu Physical Server originate the block from AS153415? The public validation answer is no, not without changing route-origin authorization. Can another upstream announce it? Only if the route policy and authorization are prepared. Can the customer move to a different provider with the same IPs? That depends on contract rights, routing agreements and whether the addresses are portable to the customer.

Most customers should assume provider-assigned addresses are not portable unless the contract says otherwise.

The same logic applies to IPv6. The Physical Server IPv6 /48 is registered, and APNIC whois lists a route6 object with origin AS153416. RIPEstat did not see visible IPv6 routing in the checked view. That may mean IPv6 is prepared but not active, or it may be visible in places the collector did not observe. Either way, customers needing IPv6 should ask for live IPv6 tests, reverse DNS policy, firewall behaviour and support commitments rather than relying on the presence of a registered /48.

Customer impact is bigger than a single server

Physical-server hosting can look simple because the unit of sale is concrete. A customer rents a server. The server has an IP address. The customer installs an application. But the impact of failure is broader. A single server can host an e-commerce site, game service, API endpoint, VPN concentrator, accounting database, customer portal, backup repository or mail system. When the server or route fails, the customer may lose revenue, access, audit trails or trust.

For small business customers, support is often the hidden dependency. If a server fails at night, the customer needs a response path. If a route is withdrawn, the customer needs communication. If an upstream filters traffic, the customer needs an operator who can speak to the upstream. If abuse complaints arrive, the customer needs a fair process rather than immediate suspension. If billing fails, the customer needs a grace period and a way to restore service. These details are often more important than the nominal hardware configuration.

Data portability is another issue. A dedicated server can feel portable because the customer controls the operating system. In practice, leaving a provider may require copying large data sets, updating DNS, rebuilding firewall policy, reissuing certificates, changing application secrets, testing backups and coordinating downtime. If the provider controls the IP space, the customer also loses address continuity. If the provider controls rescue access or remote media, migration can be slow under pressure.

That is why the weak evidence grade is not a claim that the service is bad. It is a claim that the public record does not let an outsider verify the recovery model. The company may have capable operators, responsive support and a working physical environment. Public registry and route data cannot show that. The buyer has to ask for proof: recent restore reports, failover tests, support contacts, incident notices, abuse procedures, export terms and a clear map of which company controls which layer.

Data locality is a promise only if the facility boundary is named

Vietnamese hosting can be attractive for customers who want local latency, local-language support, local billing, domestic compliance comfort or a non-hyperscale alternative. The APNIC records place the relevant entities in Vietnam and give a Hai Phong address. That is a starting point for a data-sovereignty conversation, but it is not enough to prove where customer data sits.

The buyer should ask whether production servers are physically in Vietnam, whether backups are also in Vietnam, whether support tools or monitoring data leave Vietnam, whether mail and ticketing use foreign services, and whether any disaster-recovery site is outside the country. The DNS checks already show Zoho mail records for the contact domains, which means at least part of the administrative communications surface depends on an external mail provider. That is normal, but it illustrates why "Vietnamese company" and "all operational data remains in Vietnam" are not the same statement.

Facility naming is the easiest way to improve assurance without exposing sensitive detail. A provider does not have to publish rack IDs or router names to tell customers whether servers run in a named data centre, whether the facility is third-party-operated, whether backups are in a second site, and whether support systems are independent of the hosted platform. If a provider cannot name the facility in a private due-diligence conversation, the customer should treat locality claims as unproven.

Data-locality risk also appears during migration. If a customer wants to leave, can the provider export disk images, snapshots or backup archives in a usable format? Can the customer get a full copy without waiting for a manual favour? Are there charges for large exports? Does the provider throttle transfer? Are backups encrypted under a customer-held key or a provider-held key? The answers determine whether local hosting remains a useful option after the relationship changes.

For Hoang Dieu Physical Server, the public evidence supports a Vietnam-based administrative identity and Vietnamese number resources. It does not prove the physical location of racks, backup repositories, management systems or customer data. That distinction should be explicit in any procurement or risk review.

What would raise the evidence grade

The path from Weak to Medium is straightforward. The company could publish a current service page on a resolving domain, identify whether it sells bare metal, VPS, colocation, managed hosting or wholesale capacity, and name the operating company behind customer support. It could clarify whether AS153415 is reserved, inactive, transitional or planned for future origin use. It could explain why 160.191.242.0/23 is originated by AS153416 and who controls that AS.

Network transparency would also help. A public network page could state current upstreams, whether AS140810 is the only active upstream, whether backup transit exists, whether IPv6 is live, and whether route-origin authorization is maintained for each prefix. A PeeringDB profile for AS153416 would not prove resilience, but it would give customers a stable place to inspect contacts, locations and policy. Publishing a basic abuse and NOC contact page would also improve confidence.

Operational evidence would matter even more. Customers should ask for a sample incident notice, a hardware replacement commitment, a remote-hands path, backup and restore terms, data-export options, acceptable-use rules, suspension rules, support hours and escalation contacts. The provider should be able to explain what happens when a server fails, when the upstream fails, when a customer needs emergency migration, when billing locks an account, and when abuse handling threatens service continuity.

The most useful test is a live recovery exercise. Pick a non-critical server. Restore it from backup. Move a service to a replacement machine. Confirm DNS changes. Confirm firewall policy. Confirm the support path. Confirm who can change route-origin authorization. Confirm that the customer can download data in a usable format. This kind of exercise reveals more than a polished plan page because it forces each layer of the service to act.

Until those facts are visible, the public record supports cautious monitoring rather than high-trust procurement. Hoang Dieu Physical Server Company Limited has real resource records and a routed IPv4 block through AS153416. It does not have enough public evidence to show that customer-facing physical hosting would survive rack failure, upstream failure, support overload, billing friction or migration pressure.

Contract evidence is the missing control plane

For a thinly documented physical-server provider, the contract is not an administrative afterthought. It is the place where the public route map becomes a customer right. If a customer receives an address from 160.191.242.0/23, the agreement should say whether that address is provider-assigned, whether it can be moved to a replacement server, whether it can be kept during a platform migration, and what happens if the AS153416 edge has to change route policy. Without that language, the customer may discover during an outage that the address is operationally important but not portable.

The same is true for data. A dedicated server may contain customer-managed disks, provider-managed snapshots, backup copies, rescue images and control-panel records. Each has a different owner in practice. A good agreement says which copy is authoritative, how often backups are made, whether restores are included, how long backup data is retained after cancellation, whether export bandwidth is limited, and whether a suspended account can still recover data. None of those terms is visible in the public record reviewed here.

Abuse and suspension terms matter as much as hardware terms. Physical-server hosts attract ordinary customers, experimental users and risky workloads. If the provider receives a spam, copyright, scanning, botnet or payment complaint, it needs a process that protects the network without destroying legitimate customer data. A blunt suspension rule can turn an abuse ticket into a business-continuity incident. A careful rule gives notice where possible, preserves customer data, separates compromised machines from unrelated services and explains how to regain access.

Billing is another hidden control plane. Small providers often work with upstreams, registrars, control-panel vendors, payment processors and mail providers. A billing dispute or failed renewal in any of those layers can interrupt service even when the server itself is healthy. Customers should ask whether non-payment produces immediate shutdown, whether there is a grace period, whether emergency payment can restore service outside office hours, and whether the provider's own upstream payments are separated from customer accounts.

This contract layer is not a substitute for network evidence. It is the way customers make network evidence usable. The public facts say the live route depends on AS153416. The contract should say who is responsible when AS153416 is the problem. The public facts say IPv6 is registered but not visible in the collector view. The contract should say whether IPv6 is sold as a live feature. The public facts say the contact domains have mail records but no resolving web endpoints in local checks. The contract should say how support is reached if mail or DNS is affected.

Until those terms are known, the company remains a real infrastructure subject with an unresolved customer-protection story.

The operating read

The cleanest reading is this: Hoang Dieu Physical Server Company Limited is a newly visible Vietnamese infrastructure-resource holder whose public number resources appear to be part of a broader Hoang Dieu network edge operated through AS153416. The current route configuration is not inherently alarming because route-origin validation is valid for AS153416. The caution comes from what is missing around it: AS153415 is not announced, the Physical Server contact domain has no resolving web endpoint in the local checks, PeeringDB has no profile, IPv6 is registered but not visibly routed, and no facility or support model is public.

That combination produces a weak but useful signal. It says the company belongs on an infrastructure watch list, especially if its addresses appear in customer logs, hosting offers, abuse reports or regional network data. It also says buyers should not treat the existence of AS and IP records as proof of recoverable capacity. The hard questions remain physical: where are the racks, who controls the upstream, who can replace hardware, who answers at night, who owns the route authorizations, and how does the customer leave without losing data?

For a small provider, those questions can feel heavier than the service being sold. They are still fair. Physical hosting turns quiet dependencies into customer risk. If Hoang Dieu Physical Server can show facility placement, support authority, transit resilience and customer portability, the evidence grade would improve. Without that proof, the company's public footprint is best described as real, route-visible through a neighbouring AS, and operationally thin.