Summary

  • ARIN identifies Datacenter on demand LLC as the registrant behind DCOD, DODL-1, AS35930, 23.149.8.0/24 and 2602:faa2::/36. Those records establish resource identity and administrative accountability, not a measure of platform scale, workload placement or customer capacity.
  • RIPEstat observed both address blocks during the 7-21 July 2026 window and showed AS35930 as announced on 21 July, while warning of low visibility. Its latest neighbour snapshot showed AS917, but that observation does not identify a commercial role, contract, exclusive upstream or complete interconnection design.
  • PeeringDB and the company's location page connect the public network identity to listings at Equinix NY2 in Secaucus and Telehouse FRA1 in Frankfurt. The facility operators corroborate the named sites, but the records do not prove building ownership, rack occupancy, installed equipment, equal service deployment or usable capacity.
  • The company's service catalogue describes managed infrastructure, cloud, automation, support, modernisation, migration and a product label called DoD Cloud. These are first-party descriptions of an intended service surface. A customer-ready multi-location cloud would still require service-specific evidence joining network paths, facility arrangements, platform control, support duties, capacity commitments and contractual responsibility.

A visible footprint is not the same thing as a cloud estate

The public case for Datacenter on demand LLC begins with unusually concrete identifiers. There is an autonomous system number, two address allocations, a named registry organization, recent route observations and two facility listings. None of those facts depends on interpreting a broad marketing adjective. They give a researcher stable strings to check: AS35930, DCOD, DODL-1, 23.149.8.0/24 and 2602:faa2::/36. They also connect, at least at the directory level, to Equinix NY2 and Telehouse FRA1.

That concreteness makes the evidence useful, but it also creates a familiar analytical trap. A network footprint can look like a miniature diagram of the whole business. An ASN becomes "the cloud network"; an allocation becomes capacity; a facility entry becomes a data centre; and two cities become a resilient multi-location platform. The records do not support that sequence. They show identifiers and disclosed points of presence in public systems whose purposes are narrower than a customer architecture document.

The better reading is a responsibility-boundary map. ARIN identifies the party accountable for internet number resources. RIPEstat records what its collectors could observe in a defined period. PeeringDB shows what a network profile discloses about facilities and interconnection policy. Equinix and Telehouse identify their own sites. Datacenter on demand's website describes the services the company says it offers. Each source illuminates a different layer, and the handoffs between those layers are precisely where the unanswered questions sit.

This distinction is not semantic. Managed cloud and infrastructure services are promises about continuing work: monitoring, incident handling, administration, changes, maintenance, automation, migration and support. A registry cannot show whether those activities are performed for a given customer. A route collector cannot show which application depends on a prefix. A facility directory cannot show a service schedule. A service page cannot independently prove that equipment, connectivity, staffing and authority are aligned at a named location.

AS35930 therefore matters as an anchor, not as a substitute for an estate inventory. It lets a customer or researcher begin with something observable and ask how it connects to the service being considered. The answer may be strong, limited or deployment-specific. What the public evidence does not permit is skipping that connection and treating the footprint itself as proof of a complete cloud.

ARIN fixes an accountable resource identity

ARIN's autonomous-system record identifies AS35930 under the name DCOD and names Datacenter on demand LLC as the registrant. The record is dated 8 February 2023. This establishes a public administrative association between the legal-style company name, the short registry name and the number used in interdomain routing. It is stronger evidence of network identity than an uncited logo or an unverified claim that a business is "connected."

The organization record adds depth. DODL-1 dates to 24 June 2021 and ties Datacenter on demand LLC to a Sheridan, Wyoming address and contacts using the dcondemand.net domain. The same organization record assigns contact roles spanning administration, technical matters, abuse, NOC, routing and DNS. That role coverage matters because it shows how the registry expects responsibility for the resources to be reached. It does not show how many distinct people fill those roles, when they are available, how requests are handled or whether the registry contacts are the same team that supports customers.

The Sheridan information also needs discipline. Datacenter on demand's own contact page presents 1309 Coffeen Avenue in Sheridan as a headquarters contact. ARIN uses the associated organization address in its records. Together, those facts support an administrative and company-contact anchor. They do not turn Sheridan into a data-centre location, establish where workloads run, or settle every legal and operational question that could matter to a customer. A mailing or headquarters address and a service-delivery site are different kinds of evidence.

Registry accountability is similarly distinct from asset control. Naming Datacenter on demand LLC as registrant does not show whether the company owns routers, leases equipment, uses a service provider, or combines several arrangements. It does not disclose who can make a production routing change, which person approves one, or which counterparty carries traffic. Those details might be documented elsewhere, but they are not encoded by the registrant field.

The practical value of DODL-1 and DCOD is that they prevent the network layer from becoming anonymous. A prospective customer can ask whether the entity named in a service contract is the same entity accountable for AS35930 and its addresses. If it is not, the provider can explain the relationship. A customer can also identify the appropriate administrative, routing or abuse path without assuming that a general sales contact owns every problem. The records make those questions possible; they do not predetermine the answers.

Address space proves control of identifiers, not the scale of service

ARIN assigns 23.149.8.0/24 and 2602:faa2::/36 to the registrant. The two records establish public IPv4 and IPv6 resource associations with Datacenter on demand LLC. They complement the ASN record: the company is not represented only by a number capable of originating routes, but also by address space that can be observed in relation to that routing identity.

The sizes of those blocks should not be converted into business metrics. An IPv4 /24 and an IPv6 /36 describe portions of address space. They do not reveal how many addresses are in active use, how they are assigned internally, whether they face customers, which services use them, or what traffic they carry. They cannot be translated into a server count, a rack count, a customer count, revenue, processing capacity or available headroom. Address abundance, especially in IPv6, has no simple relationship to compute or storage scale.

The records also do not place the resources in a building. A prefix may be announced through an autonomous system while the systems using its addresses depend on arrangements that are not visible in the registration. Nothing in an RDAP allocation attaches 23.149.8.0/24 to Equinix NY2, 2602:faa2::/36 to Telehouse FRA1, or either block to a particular workload. Assigning the prefixes to those sites would require evidence beyond the approved records.

Nor should registration be confused with continuous reachability. ARIN is authoritative for the registration facts represented in its records; it is not a live service monitor. The resource entries do not establish that a route was visible at every moment, that every address responded, or that a customer service met an availability objective. For observational routing evidence, a different source and a defined time window are required.

The useful conclusion is modest. Datacenter on demand LLC has identifiable number resources that can be matched across public systems. That gives technical diligence a concrete starting set. A customer can ask which, if any, of those resources will appear in its design; whether IPv4 and IPv6 are both included; who controls routing and filtering; and what other resources or providers are relevant. The allocation records support the questions without supplying deployment answers that they were never designed to contain.

RIPEstat turns registration into a dated routing observation

RIPEstat adds a different kind of evidence. Its AS overview reported AS35930 as announced on 21 July 2026. Its announced-prefixes data observed 23.149.8.0/24 and 2602:faa2::/36 during the 7-21 July window. That joins the registry identity to externally observed BGP activity: the ASN and both ARIN-associated address blocks were visible to the measurement system in the stated period.

The date and window are essential parts of the finding. Routing state changes, and an observation is not a perpetual warranty. The responsible formulation is that RIPEstat observed the prefixes in that window and described the ASN as announced on that date. It would be wrong to turn the snapshot into a claim that the routes have always been visible, will remain visible, or were reachable from every network. It would also be wrong to infer service health from route visibility alone.

RIPEstat included its own low-visibility warning. That warning should narrow interpretation rather than be waved away. A route collector's view depends on its observation points and available data. Low visibility does not prove that the routes were unimportant, unstable or unused; neither does it allow the observed view to stand in for every possible path. The evidence confirms visibility within the dataset while signalling that the dataset is not a complete map of the internet.

BGP visibility is also several steps removed from a managed cloud outcome. A prefix can be observed while an application behind it is unavailable or not configured for a particular customer. Conversely, a service associated with the company could use other addressing or delivery arrangements that are not evident from these two routes. The route data does not expose server state, storage, orchestration, access control, support activity or contractual entitlement. It answers a routing question, not an end-to-end service question.

Even within the network layer, the observation is limited. It does not show path performance, traffic volume, route-policy intent, filtering, convergence behaviour, private interconnection or the capacity of any link. It cannot assign either prefix to the Secaucus or Frankfurt listing. Those are separate records, and joining them into a physical topology would exceed the evidence.

The route observations nevertheless strengthen the public footprint. They show that AS35930 is more than a dormant registry string in the reviewed window and that both listed allocations appeared in the observed announcements. For diligence, that creates a useful baseline: a current private design can be compared with a dated public view. Any difference then becomes a question for explanation, not a reason to invent a topology from the outside.

AS917 is an observed neighbour, not a disclosed contract

RIPEstat's ASN-neighbours endpoint showed one currently observed neighbour, AS917, at its latest snapshot. This is a specific, testable statement about what the endpoint exposed at that time. It is not a complete commercial or technical description of AS35930's external connectivity.

The word "neighbour" in an observational dataset does not assign a business role. The record does not say that AS917 is a transit provider, customer, peer, backup path or exclusive upstream. It does not identify a contract, a service level, a port, a facility or a payment relationship. Calling AS917 the company's carrier or treating the relationship as contractual would add facts that the source does not provide.

One observed neighbour also does not prove that there is only one external dependency. Private sessions may not be visible to the dataset. Other relationships may exist outside the observation window or beyond the collectors' view. PeeringDB's separate directory disclosures do not close that gap: an open general peering policy indicates a stated posture, not a list of active sessions. Zero exchange-LAN records in the profile cannot be used to declare that no public exchange connection or private cross-connect exists.

The inverse inference is equally unsafe. The appearance of AS917 does not prove diverse connectivity, redundancy or automatic alternate routing. Diversity is a property of an actual design, including physical and logical dependencies, not a number obtained by counting one public endpoint. A customer would need current route, circuit and facility information relevant to its service, along with an explanation of failure handling, before drawing a resilience conclusion.

AS917 is therefore best treated as a lead in a responsibility map. It identifies an externally visible adjacency worth reconciling with the provider's network description. The next questions are who controls the relationship, what function it serves, where it is delivered, and whether the customer's path depends on it. Public observation makes the adjacency visible. Only service-specific evidence can make its role legible.

PeeringDB describes two facility handoffs and leaves many fields open

PeeringDB's network record identifies entry 38788 with local ASN 35930 and associates it with two facilities: the Equinix New York/Secaucus location and the Telehouse Frankfurt location. The associated facility data aligns with Datacenter on demand's own location page, which lists Equinix NY2 at 275 Hartz Way in Secaucus and Telehouse FRA1 at Kleyerstrasse in Frankfurt. This cross-source alignment supports a careful statement that the network is publicly listed at two third-party facilities.

That is a meaningful disclosure. It identifies named places where a handoff or operational presence can be investigated. It is more specific than a claim of broad global reach, and it gives a customer two facility names to reconcile with a proposed design. But a PeeringDB facility association is still a directory field. It does not disclose the form, scale or current use of the arrangement.

The network profile describes an open general peering policy. It does not disclose a traffic level or a status dashboard. The reviewed API records show zero exchange-LAN entries and zero self-declared IPv4 and IPv6 prefix counts in the PeeringDB profile. These zeros must be read as directory disclosures, not as proof of operational absence. ARIN and RIPEstat already show why: the company has registered address resources and both were observed in routing even though the PeeringDB prefix-count fields are zero.

The same logic applies to interconnection. A zero result from the exchange-LAN endpoint does not establish that AS35930 has no peering, no transit, no private cross-connects or no production path. It establishes that the queried PeeringDB record did not disclose exchange-LAN entries in the reviewed response. An open policy does not prove the opposite; it is not evidence that active public peering exists with any named network. The profile tells readers what has been entered, not the totality of arrangements that might exist.

The absence of a disclosed traffic level likewise cannot support a low-traffic or high-traffic conclusion. There is no public number in the profile from which to estimate customer demand, utilisation or network scale. The absence of a status dashboard link cannot be treated as proof that monitoring or customer communications do not exist elsewhere. Public completeness and operational completeness are different properties.

These gaps make the PeeringDB entry more useful when read conservatively. It establishes two disclosed facility associations and a stated policy while clearly leaving traffic, exchange and prefix-profile detail unfilled. A customer can ask the company to reconcile those fields with a current network diagram. The directory should start that conversation, not end it.

Equinix NY2 and Telehouse FRA1 are third-party site references

The site evidence can be checked from both sides of the handoff. Datacenter on demand's location page names Equinix NY2 and gives 275 Hartz Way, Secaucus. Equinix's own site page confirms 275 Hartz Way as NY2. The matching facility name and address establish that the company is referring to a real Equinix location and that PeeringDB's New York/Secaucus association points to the same named site.

The Frankfurt evidence has a similar shape. The company lists Telehouse FRA1 at Kleyerstrasse in Frankfurt, and PeeringDB associates network 38788 with the Telehouse Frankfurt facility. Telehouse states that it operates the Frankfurt campus. These records identify a Telehouse-operated site connected to the company's public facility disclosure.

Neither chain transfers ownership of the site to Datacenter on demand LLC. Equinix's confirmation identifies its NY2 property, and Telehouse's statement identifies its Frankfurt operation. The evidence therefore supports third-party facility context, not a claim that Datacenter on demand owns either building, its power or cooling systems, meet-me rooms, racks, customer equipment or the wider campus infrastructure.

The records also do not show what Datacenter on demand has inside either location. A directory listing cannot specify rack occupancy, hardware inventory, virtual capacity, cross-connect count, carrier contract or staff presence unless those facts are separately disclosed. It cannot establish whether the company's role is based on owned equipment, leased resources, a partner service or another arrangement. All of those possibilities must remain unresolved rather than being selected by inference.

Even the word "presence" needs context. Publicly listed at a facility is the defensible statement here. The records do not establish that every service described on the company website runs at both sites, that the same components are deployed in each, or that customer workloads are placed there. They do not say that the two entries are simultaneously active for a particular service or that a customer can order either location on demand.

This boundary protects the usefulness of the site information. Equinix NY2 and Telehouse FRA1 can still serve as concrete reference points in diligence. A provider can explain the commercial arrangement, equipment boundary, network handoff and available service scope at each. What it cannot reasonably be asked to do is correct an outside assumption that the public directory itself never made.

Two named facilities do not close a multi-location architecture

Once two facilities appear in the same profile, it is tempting to draw a line between them and call the result resilience. The approved evidence does not draw that line. It does not identify a circuit between Secaucus and Frankfurt, a replicated platform, common orchestration, synchronized data, shared monitoring, or an automatic recovery process. It does not even establish that the same product component is deployed at both sites.

Geographic separation is a location fact, not a service design. Two named sites can play different roles, support different customers or depend on arrangements that are not visible publicly. They may be part of one architecture, but that would need to be shown with current technical and contractual evidence. The public listings alone do not establish active-active service, primary and secondary roles, workload mobility or a recovery objective.

The route data cannot supply the missing join. RIPEstat observed both prefixes in relation to AS35930, but it does not geolocate them to the two facility entries. The neighbour observation does not say where the adjacency with AS917 occurs. PeeringDB does not publish exchange-LAN records for the profile. A diagram that places one prefix in Secaucus, another in Frankfurt and AS917 between them would be invented, not derived.

The company location page also cannot be read as a capacity schedule. Listing Equinix NY2 and Telehouse FRA1 does not state what a customer can buy at either site, how quickly service can be provisioned, whether capacity is reserved, or which dependencies are shared. It does not establish equal product availability or a common support model. Those are customer-readiness questions, and the brief provides no evidence that resolves them.

A multi-location claim becomes meaningful only when the unit of replication is named. Is the relevant object a route, a virtual machine, storage data, an application control plane, a monitoring system, a configuration repository or a support process? Who initiates movement or recovery, and what evidence shows it works? The public footprint gives two places from which those questions can begin. It does not answer them by the mere fact of plurality.

The service catalogue creates a wider chain of responsibility

Datacenter on demand's website describes Cloud & Infrastructure Managed Services and a broad set of associated activities. The catalogue includes around-the-clock alert and incident handling, infrastructure management, automation and DevOps, maintenance and support, public, private and hybrid cloud, SaaS, PaaS and IaaS, managed cloud and infrastructure, consulting, data-centre modernisation, network transformation, edge capabilities and migration. These are first-party descriptions of what the company presents to the market.

The breadth matters because it shows why AS35930 cannot stand for the whole offer. Routing is relevant to network reachability, but managed infrastructure extends into systems, software, operational processes and human authority. Automation and DevOps concern changes and repeatability. Maintenance and support concern continuing intervention. Migration concerns movement from one state to another. Consulting and modernisation concern design decisions. A route observation can intersect with all of these activities without proving any of them.

Around-the-clock alert and incident handling is a useful example. The website establishes that the company describes such a service. It does not publish the staffing model, response target, escalation path, monitoring coverage, customer eligibility or achieved performance. It does not show whether every service tier includes the same handling or whether every named location is covered in the same way. Those details would normally belong to a service description, order or support schedule for the customer in question.

The public, private and hybrid cloud language also spans different responsibility models. In a public-cloud engagement, the underlying provider may control physical infrastructure while Datacenter on demand manages selected layers. In a private or hosted arrangement, the boundaries may be different. A hybrid design necessarily joins environments. The website's list establishes that the company discusses these models, not that one standard estate or one allocation of duties applies to all of them.

SaaS, PaaS and IaaS labels widen the possible stack again. They indicate familiar service categories, but the page does not provide an inventory of live products, locations, dependencies or capacity under each label. It would be unsafe to infer that Datacenter on demand owns a full platform at Equinix NY2 and Telehouse FRA1 simply because all three acronyms appear in a catalogue. The service layer, facility layer and network layer must be joined with actual deployment evidence.

Network transformation and edge capabilities might involve AS35930, but the public records do not show the relationship. Data-centre modernisation might concern customer premises, a partner facility or another environment; the phrase itself does not assign work to the two listed sites. Migration likewise describes an activity, not a completed move or a current workload location. Each service description is best treated as a scope for questions rather than a record of achieved deployment.

This does not diminish the catalogue. It makes its operational implications clearer. A provider offering such a broad set of managed activities may cross many handoffs: customer to service desk, service desk to engineering, engineering to cloud platform, platform to network, network to facility and organization to third-party supplier. The relevant assurance question is who owns each decision and what evidence crosses the boundary. The ASN marks one part of that chain; it cannot collapse the chain into a single proved estate.

DoD Cloud is a product label, not government evidence

The website uses the product label DoD Cloud. Within the approved source set, that label must remain exactly what it is: a first-party name in the company's service presentation. The records do not expand it into United States Department of Defense work, a government programme, an accreditation, an authorization, a contract or evidence of government customers.

This is an important limit because the initials invite an association that the sources do not substantiate. Registry records for DCOD, DODL-1 and AS35930 contain resource and contact information, not procurement status. PeeringDB's facility data says nothing about certifications or customer sectors. RIPEstat observes routes, not compliance. Equinix and Telehouse identify facilities, not Datacenter on demand's authorization to serve a particular government workload.

The label also does not define the estate behind it. It does not prove that DoD Cloud uses 23.149.8.0/24, 2602:faa2::/36, Equinix NY2, Telehouse FRA1 or AS917. It does not disclose whether the product is public, private or hybrid for a specific deployment, which party operates each layer, or what capacity is available. Associating all visible infrastructure records with the label would be another unsupported join.

A customer evaluating the named product should therefore ask for the ordinary evidence appropriate to its requirements: the contracting entity, precise service scope, architecture, locations in scope, shared dependencies, controls, support model and contractual commitments. If a regulated or government use case is relevant, the necessary authorization evidence must be supplied directly. The name itself cannot carry that burden.

Customer readiness exists at the joins the public records cannot see

A network can be registered and announced without being ready to deliver a particular managed service. Readiness is specific to an order, a design and a moment. It requires more than an ASN: addresses must be assigned, routes and access configured, systems provisioned, monitoring connected, operating authority established, support paths tested and commercial terms made effective. The approved public records do not show that sequence for any customer.

The first join is legal and commercial. DODL-1 names Datacenter on demand LLC for registry purposes, and the company website presents the service catalogue. A customer still needs to know which entity signs the agreement, which services are included, which third parties are involved and where responsibility changes hands. Registry contact roles are not a service-level schedule. A general website description is not an order form or proof that capacity has been reserved.

The second join is between network and facility. PeeringDB lists the network at Equinix NY2 and Telehouse FRA1, while the facility operators confirm the named locations. A customer design would need to specify whether either site is actually in scope, what the provider controls there, how connectivity is delivered and which components depend on the site. It would also need to identify shared dependencies that might make two facility names less independent than they appear. None of that can be recovered from the public fields.

The third join is between connectivity and platform. RIPEstat shows route visibility, but route visibility does not establish that compute, storage, orchestration or management functions are available. If a managed cloud service uses AS35930, the design should explain which traffic uses it and what happens when a path or component is unavailable. If the service does not use the ASN directly, the provider should identify the relevant network boundary instead. Either answer is more informative than assuming all products inherit the public footprint.

The fourth join is operational. Around-the-clock alert and incident handling implies monitoring, triage and escalation, but the website does not disclose how those functions are organized. Customer readiness would require named contact channels, severity definitions, response obligations, change authority and a shared understanding of which events belong to Datacenter on demand, the facility operator, a carrier, a cloud platform or the customer. Otherwise, a technically working handoff can still become an organizational dead end.

The fifth join is evidence. Claims about resilience, recovery, capacity or control should be supported by records matched to the customer's service: current diagrams, configuration extracts, test results, service schedules or other appropriate materials. The sources reviewed here provide none of those customer-specific artifacts. That absence is not proof that they do not exist. It is the reason the public footprint cannot be called customer-ready evidence.

This framework avoids two opposite errors. It does not dismiss the company because public records are incomplete; public infrastructure directories are almost always partial. It also does not promote the public identifiers into proof of a service they cannot describe. The fair conclusion is that Datacenter on demand has an observable network and facility-disclosure surface, while the chain to a particular managed cloud remains to be demonstrated.

Diligence should preserve four separate evidence layers

The records become easier to use when sorted into four layers. The first is registered fact. ARIN establishes the association among Datacenter on demand LLC, DCOD, DODL-1, AS35930 and the two address blocks. Those facts answer who is publicly accountable for the identifiers. They do not answer how the service is built.

The second layer is observed network state. RIPEstat saw AS35930 announced and observed both prefixes during the stated July window, subject to its low-visibility warning. It also exposed AS917 as one currently observed neighbour in the latest snapshot. These facts answer what the measurement system could see at a time. They do not assign commercial roles or reveal a complete topology.

The third layer is directory disclosure. PeeringDB associates network 38788 and local ASN 35930 with two facilities and records an open general policy, while leaving traffic, status, exchange-LAN and self-declared prefix fields undisclosed or at zero. Datacenter on demand's location page gives corresponding site names and addresses. Equinix and Telehouse corroborate the facilities from the operator side. This layer identifies possible handoff locations, not ownership or deployment scope.

The fourth layer is first-party service description. The company lists managed cloud and infrastructure activities, operational support, automation, migration and other capabilities, including DoD Cloud. Those descriptions establish what the company says it offers. They do not independently verify availability, performance, certification, capacity or site-by-site implementation.

Good diligence asks for the documents that connect one layer to the next. Between registered fact and observed state, the provider can identify which resources support the proposed service and who controls routing. Between observed state and directory disclosure, it can explain where relevant interconnections are delivered without pretending that public collectors see every path. Between the facility layer and service description, it can identify what is deployed, who owns or leases it, what third parties supply and which services are available to the customer.

Several questions follow directly from the gaps. Does the proposed service use AS35930, 23.149.8.0/24 or 2602:faa2::/36? If so, for which traffic and under whose change control? What role, if any, does AS917 play, and what other external paths matter? Is the service listed for Equinix NY2, Telehouse FRA1, both or neither? What equipment and connectivity boundaries apply at each site? Which product components are duplicated, and which remain shared?

Operational questions are just as important. What does around-the-clock handling cover, who receives an alert, and when does responsibility pass to a facility, carrier, platform or customer team? How are planned changes authorized? What evidence demonstrates recovery for the specific components in scope? How is capacity committed and monitored without relying on prefix counts or facility names as proxies? Which service terms turn catalogue language into enforceable duties?

Answers may be confidential and deployment-specific. They do not all need to be published for the public records to retain value. The point is that the public footprint supplies a disciplined index for private verification. Each identifier, address and facility name can be reconciled with a current service document. Where the two disagree, the provider can explain whether the public data is partial, stale or simply describing a different layer.

The same layered method helps avoid false negatives. Zero exchange-LAN records do not prove no interconnection. Zero self-declared prefix counts do not erase the ARIN allocations or RIPEstat observations. No disclosed traffic level does not prove low traffic. No status dashboard in the PeeringDB profile does not prove that customers lack status communications. A gap in one public directory should become a verification item, not an operational verdict.

It also avoids false positives. Two facility entries do not prove geographic resilience. An observed neighbour does not prove carrier diversity. Two announced prefixes do not prove spare capacity. A headquarters contact does not prove a data-centre site. A broad service catalogue does not prove that every capability is live in every location. The four layers keep each fact strong by refusing to make it carry conclusions that belong elsewhere.

AS35930 is a useful boundary marker precisely because it is incomplete

Datacenter on demand LLC has a coherent public identity at the registry layer. ARIN connects DCOD and DODL-1 to AS35930, 23.149.8.0/24 and 2602:faa2::/36. RIPEstat observed the ASN and both prefixes in the cited July 2026 period, with an explicit warning about visibility, and exposed AS917 as one observed neighbour at the latest snapshot. These are real anchors for network diligence.

The facility evidence is also concrete within its limits. The company's disclosures and PeeringDB point to Equinix NY2 at 275 Hartz Way in Secaucus and Telehouse FRA1 at Kleyerstrasse in Frankfurt. Equinix confirms NY2 at that address, and Telehouse describes its operation of the Frankfurt campus. The resulting claim is that Datacenter on demand is publicly listed at third-party facilities. It is not that the company owns the sites or that a complete cloud platform occupies them.

The service catalogue then reveals why the gap matters. Managed infrastructure, cloud, support, automation, migration, modernisation and network transformation depend on more than public routing. They depend on arrangements and actions that sit across company, customer and supplier boundaries. DoD Cloud remains a product label inside that catalogue, not evidence of government work or a map of the visible network resources.

The most defensible conclusion is narrower than a cloud-estate claim and more useful than a list of caveats. AS35930 shows where public accountability and observable routing begin. The two facility entries show where named third-party handoffs may be investigated. The website shows the operating surface the company says it can manage. What remains unproved is the chain joining those facts into a customer-specific, multi-location service with defined capacity, control, recovery and contractual responsibility.

That chain can be demonstrated, but not by inference. It requires the provider and customer to identify the resources in scope, the role of each facility and external network, the platform components involved, the authority to change them, the support process and the evidence behind any resilience or capacity commitment. Until that work is done, the footprint should be read for what it is: a visible handoff, not a proved cloud estate.

Sources