PeeringDB-recorded 10G DE-CIX ports, zero RIS-visible prefixes: reading Genesis Cloud AS209045

Summary

• Genesis Cloud Routing, Peering and DNS is the name of a RIPE technical role, not a stand-alone company or a seller of hosted capacity; Genesis Cloud Limited, Genesis Cloud GmbH, AS209045 and other named organisations must be assessed separately.
• The strongest current routing observation is RIPEstat's 2026-07-20 reading of zero IPv4 and IPv6 RIS visibility, zero announced prefixes and zero observed neighbours for AS209045, but that collector result does not establish an outage across websites, APIs, accounts or customer workloads.
• Buyers should treat documented regions, capacity flags, snapshots, volumes, security groups, DNS names and exchange records as testable control surfaces, then demand dated proof of replacement capacity, state recovery, endpoint resolution and network continuity before assigning resilience value.

One name sits across several different kinds of evidence

The first discipline in reading Genesis Cloud's public footprint is to resist turning every appearance of the name into one corporate or technical identity. The exact phrase Genesis Cloud Routing, Peering and DNS belongs to the RIPE role GCRP3-RIPE. The record gives it a Munich address, a creation date of 29 April 2019 and a last-modified date of 25 July 2024. In an Internet registry, a role of this kind identifies a contact function. It can help a network operator or investigator find an administrative or technical point of contact. It is not, by itself, a legal person, a commercial offer or proof of who signs a customer's agreement.

That distinction matters because the surrounding records refer to other identities with different functions. AS209045 is an autonomous-system number registered as GENESIS-CLOUD-AS. RIPE RDAP and database material associate it with ORG-GCL19-RIPE, whose organisation record names Genesis Cloud Limited. The organisation record gives Malta as the country, registration number C 88032 and an LIR organisation type, and Genesis Cloud Limited also appears in RIPE NCC's Malta member list. Those facts connect a registered organisation to number-resource administration.

They do not establish which affiliate operates a particular machine, owns a rack, controls a campus or stands behind every service agreement.

Genesis Cloud GmbH is another distinct legal name. The reviewed GLEIF record identifies a German entity whose registration status is LAPSED. The record was last updated on 26 June 2026 and includes a LIQUIDATION event marked IN_PROGRESS, with a recorded date of 2 September 2025. That is material legal-entity evidence about Genesis Cloud GmbH. It is not evidence that Genesis Cloud Limited, Genesis Cloud Norway AS, AS209045 or every service carrying Genesis Cloud branding shares the same legal status. The public material considered here does not justify extending the GmbH record beyond the entity it names.

The same separation applies to infrastructure partners. Bulk Infrastructure is named in connection with a Norwegian data-centre campus. DE-CIX operates exchange surfaces and publishes route-server observations. Google Cloud appears in the network identity behind the reviewed public API address. Cloudflare appears in domain-registration and authoritative-nameserver records for genesiscloud.com. None of those organisations is the RIPE role, and none should be treated as a synonym for Genesis Cloud Limited or Genesis Cloud GmbH. Their appearances describe dependencies, locations or technical relationships at specific layers.

This identity map also prevents a subtle but consequential mistake: writing as if the RIPE role sells compute, storage or network capacity. The role does not disclose a product catalogue, inventory, price, service commitment or contracting party. Hosted capacity appears in service documentation and commercial material associated with the Genesis Cloud name, while the role remains a registry contact. A buyer therefore needs a named legal counterparty, a named service surface and a named technical dependency for each claim under consideration.

The evidence is strongest when each record is allowed to answer only its own question. A registry role answers who is listed for contact. An organisation object answers which entity is associated with registered resources. A legal-entity record answers what has been recorded for that specific legal entity. An autonomous-system record answers how a network identity is registered. Exchange and routing observations answer what particular measurement points saw at particular times. Conflating these layers may produce a simple story, but it would not produce a reliable one.

Registered resources describe authority, not current reachability

The RIPE resource records establish that Genesis Cloud Limited's organisation identifier is linked to a meaningful block of Internet number resources. The inverse search associates ORG-GCL19-RIPE with the IPv4 ranges 147.189.192.0 through 147.189.207.255 and 194.61.20.0 through 194.61.23.255, the IPv6 allocation 2a09:7000::/29 and AS209045. These entries are useful for attribution and for defining what addresses may be relevant to further technical checks. They are not a live map of packets crossing the public Internet.

That limitation becomes clearer in the route-object records. RIPE currently returns six route or route6 objects with AS209045 as origin. They include 147.189.200.0/22, 147.189.207.0/24, 2a09:7000::/29, 2a09:7000::/31, 2a09:7007::/36 and 2a09:7000:1000:200::/56. The most specific IPv6 object in that set carries the remark "Test for traffic redirection." The records demonstrate that route authorisations or policy descriptions exist for those prefixes. They do not demonstrate that an edge router was announcing them when a customer attempted to connect.

The AS209045 aut-num record adds another policy layer. It contains statements accepting ANY from AS13237, AS50304, AS60259, AS44735, AS200781 and AS212175, alongside numerous route-server and peer statements. That is evidence of declared routing intent. It can help explain how the network expected to exchange reachability under a configured state. It cannot be upgraded into a claim that all six networks were current upstreams, that contracts remained active, or that packets traversed those paths on 20 July 2026.

RPKI records offer yet another kind of authority. The latest rows available on 18 July 2026 showed two IPv4 validated ROA payloads and three IPv6 payloads associated with AS209045. Their presence supports the proposition that route-origin authorisation context remained recorded. It does not say that a matching route was being announced, that a route collector received it, or that a service behind it was responsive. A route can be authorised but absent; it can also be visible while a particular application is unhealthy.

These distinctions are not semantic niceties. They change how a buyer should interpret a network inventory. Registered address space can remain assigned during a maintenance period, a network redesign, a withdrawal or a long interval with no globally observed announcement. Route objects can remain in a registry after operational state changes. RPKI authorisations can remain valid even when no route is emitted. Conversely, an application can be reachable through addresses originated by another autonomous system while the organisation's own ASN is absent from a collector view.

The correct reading is therefore layered. Registration demonstrates resource association. IRR data demonstrates declared policy or authorisation. RPKI demonstrates route-origin authorisation context. BGP collectors demonstrate observed control-plane reachability from their vantage points. DNS demonstrates how a name resolved at a moment. An application test demonstrates whether a specific service responded. No single layer silently substitutes for the others.

For Genesis Cloud, the resource records are still valuable. They make AS209045 and the listed prefixes concrete objects of inquiry rather than vague branding. They also provide historical continuity against which current observations can be compared. But a procurement team should not count registered prefixes as active paths in a resilience model. It should ask for dated announcements, path observations and service tests that correspond to the region and workload it expects to use.

Zero RIS visibility is the strongest dated routing finding

The clearest current routing observation in the reviewed material comes from RIPEstat at a query time of 2026-07-20T00:00:00. For AS209045, the routing-status response reported IPv4 visibility of 0 out of 323 RIS peers and IPv6 visibility of 0 out of 318 RIS peers. It also reported zero announced IPv4 prefixes, zero announced IPv6 prefixes and zero observed neighbours. The announced-prefixes view for the 6 July to 20 July 2026 window was empty.

Those numbers warrant direct language. From the RIPE RIS measurement surface represented by that response, AS209045 had no current globally visible prefixes in either address family at the stated time. The observation is stronger than a stale registry entry because it concerns what collectors saw. It is also stronger than an undated screenshot because the response supplies a query time and peer counts. For anyone evaluating the autonomous system as an independently visible public routing surface, zero out of hundreds of peers is a consequential result.

It would nevertheless be wrong to turn the finding into "Genesis Cloud was down." RIS is a route-collection system. Its result does not test a login page, a compute API call, an existing virtual machine, a private circuit, an address originated by another ASN, an account console or every path available to a customer. A cloud service can expose public control points through a third party's network. A workload can use private connectivity or addresses outside the ASN under study. A website can respond even when the branded autonomous system has no RIS-visible route.

Nor does the observation reveal why the prefixes were absent. The records do not establish whether the state resulted from planned withdrawal, network redesign, contract change, equipment state, business reorganisation, filtering, a collector blind spot or another cause. The broad peer counts make a simple local visibility gap less persuasive, but they do not supply causation. Responsible analysis stops at observed absence unless another source documents the reason.

BGP.tools offers a second entry point for viewing AS209045, but the numeric claims here remain anchored to the dated RIPEstat response. Combining route views collected at different moments can create a synthetic inventory that never existed at one time. A route seen in one historical window, a configured exchange port and an authorisation object may all be true while saying different things. The relevant question is not which page looks most current; it is which measurement answers the buyer's question at a stated time.

For a network-resilience assessment, this finding changes the burden of proof. A buyer should not assume that the registered ASN supplies a currently active, independently routed public edge merely because number resources and exchange entries remain documented. If that edge is part of the proposed architecture, the seller should be able to demonstrate live origin visibility, expected upstream or peering paths and the addresses actually used by the buyer's service. If the service no longer depends on AS209045, the architecture should say what replaced that dependency.

The finding is therefore a test trigger, not a verdict on every service. It justifies asking where public API traffic enters, how workload ingress is originated, whether private and public paths differ, and what routing state should be visible during normal operation. It also justifies repeating the measurement from more than one vantage point while preserving timestamps. What it does not justify is claiming a general outage without application-level evidence.

The historical record shows change without explaining its cause

Historical RIPEstat data gives the current zero-visibility result context. In the window from 1 November to 3 December 2025, the announced-prefixes response shows 2a09:7000::/31 visible from 3 November at 16:00 until 2 December at 00:00. It also shows 147.189.200.0/22 visible from 3 November at 16:00 until 2 December at 08:00. The exact intervals matter: they establish that at least these two aggregates had been observed, then were no longer present in that historical response by the stated December times.

A separate ASN-neighbours query for 1 December 2025 shows one left neighbour, AS50304. By contrast, the 20 July 2026 routing-status response reports zero observed neighbours. Read together, these results support a changed observed-routing picture. They do not give a complete history of every session, and they do not prove that AS50304 was the only commercial transit relationship. The "left" direction is a collector-derived relationship label, not a copy of a customer agreement.

The chronology also prevents two opposite errors. One error would be to assume AS209045 never carried visible routes because the current response is empty. The November record refutes that. The other would be to assume that past visibility continues because registry and exchange entries remain. The July response refutes that inference. A robust assessment must allow technical state to change while administrative records persist.

No reviewed record identifies the cause or exact decision behind the December withdrawals. A route may disappear because of an intentional migration, a session loss, a change in origin, a policy action or another event. Even the timing correspondence between withdrawn prefixes and later exchange observations cannot establish a single cause. Temporal proximity can guide questions; it cannot manufacture an explanation.

The historical evidence is most useful as a baseline for requested proof. A buyer can ask whether 147.189.200.0/22 and 2a09:7000::/31 were expected to remain part of the service, whether equivalent addresses moved elsewhere, and whether any contractually relevant endpoint changed origin. The answer should include dates and specific prefixes. A general statement that "networking is available" would not resolve the discrepancy between past and current observations.

History also matters for recovery claims. If an architecture once depended on AS209045 and now reaches public services through another network, that may represent successful redesign, reduced control, or merely a different boundary. The public records alone do not choose among those interpretations. The buyer needs a current dependency map tied to its own service: DNS names, addresses, origin ASNs, exchange or transit paths, and failover behaviour.

This is why current absence should neither be dismissed nor dramatised. It is a material change in a measurable network layer. It lowers confidence in assumptions based solely on older case studies or configured records. At the same time, it leaves application health, private connectivity and the reason for the change unresolved. That combination calls for evidence, not a categorical claim.

Two 10G records can coexist with down route-server observations

PeeringDB records Genesis Cloud under AS209045 as an enterprise network with a European scope. Its data includes two operational 10G IX LAN connections at DE-CIX Frankfurt and DE-CIX Kristiansand. Both entries are recorded as using route servers and BFD. At first glance, the word "operational" may appear incompatible with zero RIS-visible prefixes or with an exchange looking glass showing a session down. The records are compatible once their provenance and meaning are separated.

PeeringDB is maintained by participating networks and exchange communities. An operational flag describes the published configuration state of the IX LAN entry. It is valuable evidence that a 10G attachment was recorded, that route-server use was expected, and that BFD was indicated. It is not a continuous packet test. It does not independently confirm that BGP was established at the moment of review, that routes were accepted, or that a customer's GPU workload could be reached through the port.

The DE-CIX looking-glass neighbour data supplies a different observation. In the entries reviewed on 20 July 2026, the Frankfurt IPv4 and IPv6 neighbours for AS209045 were down after hold-timer expiry on 22 October 2025. The Kristiansand IPv4 and IPv6 entries were down or passive, with state changes on 24 June 2026. The reviewed entries showed zero routes. These are exchange-side, point-in-time session observations with their own timestamps and scope.

The exchange result is more direct for the state of those named route-server adjacencies. It does not prove that the physical cross-connect was absent, that a port had been decommissioned, or that every bilateral session was down. A member can have a live physical attachment while a route-server session is idle. It can also have bilateral peers not represented by a selected route-server neighbour view, separate transit, private network paths or another service edge. Zero routes on four reviewed route-server entries is therefore meaningful but bounded.

The PeeringDB and DE-CIX records should be read as a configuration-to-observation gap. The former says two 10G route-server-enabled connections were recorded as operational. The latter says the selected route-server sessions were not established and carried no routes in the reviewed state. Neither needs to be discarded. Instead, the gap becomes a precise diligence question: which part of the recorded attachment remained active, what traffic was expected to traverse it, and when was the last successful route exchange?

Public material from DE-CIX and Genesis Cloud describes a 10G GlobePEER Remote arrangement, a bridge from Bulk's Kristiansand location and a rationale for moving AI and high-performance-computing traffic from transit toward peering. Those materials help explain the intended design and commercial motivation. Their performance and load benefits remain attributed claims. They are not buyer-observed latency measurements, traffic graphs or proof that the described arrangement remained active in July 2026.

This distinction has financial consequences. Peering can reduce transit dependence and improve path control when sessions, routes and traffic are present. A recorded 10G port has no equivalent resilience value if the relevant session is down or no service prefix is exchanged. Buyers assessing network value should ask for current session state, accepted and advertised route counts, traffic levels, path diversity and the relationship between the exchange attachment and their actual endpoints.

The correct conclusion is neither "PeeringDB proves connectivity" nor "the looking glass proves the entire service is gone." The defensible conclusion is narrower: the administrative configuration records and the dated operational observations diverge. That divergence is exactly the kind of public signal that should move a claim from assumed capability to tested capability.

Facility listings locate dependencies without proving ownership

PeeringDB also places the AS209045 network at EMC Home of Data MUC I/II - MuCon-X in Munich and at Bulk Norway Data Center Campus - N01 in Øvrebø. Bulk's own public material describes the N01 campus and its connectivity, while DE-CIX documents an exchange surface in Kristiansand. Together, these sources establish a plausible geographic and interconnection context for a European cloud network. They do not establish that Genesis Cloud owns the campuses or the infrastructure inside them.

A facility listing can mean many things: a network may have equipment, a port, a cross-connect, a reseller arrangement or another recognised presence. The reviewed records do not state that Genesis Cloud controls the buildings, power systems, cooling plant, long-haul fibre, meet-me rooms or exchange operations. Those assets belong to separate operational domains unless evidence says otherwise. Bulk Infrastructure and DE-CIX must therefore remain distinct from the Genesis Cloud identities and from AS209045.

This matters because ownership language can inflate resilience claims. Saying that a cloud operator is "in" a campus is not the same as saying it can control utility restoration, allocate an additional hall, repair a long-haul path or guarantee spare racks. A service may benefit from a well-connected site while remaining dependent on the site operator, carriers, exchange equipment and contractual access. The dependency can be entirely reasonable; the analytical error is to erase it.

The regional evidence is nonetheless useful. The documented Norway-KRS1 service region, the N01 facility listing, the Kristiansand exchange presence and the Munich records support a Europe-centred classification. They help explain why the article belongs under the Europe and Middle East cloud-service category. The classification does not claim that every customer, affiliate, dependency or traffic path is located there. It is a navigation choice based on where the reviewed legal, facility, interconnection and service evidence is concentrated.

For a buyer, facility diligence should focus on the service boundary rather than on branding. Which legal entity contracts for space and power? Which organisation owns the servers? Which party can authorise physical access? Are the two apparent network paths physically diverse beyond the first meet-me room? Does a second region use a different failure domain? Public pages do not answer those buyer-specific questions.

The same caution applies to capacity. An empty rack bay, a listed campus or a catalogue of instance types does not prove that replacement GPUs are installed, powered, allocatable and compatible with a customer's workload. Physical capacity is a dated inventory question. It must be demonstrated by an allocation or test, not inferred from a site description.

The public evidence therefore earns medium confidence for named locations and recorded interconnection context, but weak confidence for asset ownership, spare capacity and failure-domain independence. That is not a negative judgment about the facilities. It is a statement about what the records prove. A buyer can use the locations to frame questions, but should not book resilience value that the documents do not substantiate.

The public API follows an external DNS and network path

The public API gives a useful example of why AS-level and service-level reachability must be tested separately. Google Public DNS resolved api.genesiscloud.com through the canonical name gws-loadbalancer-prd.genesiscloud.com to 34.76.254.30. RIPEstat network information associated that address with AS396982, and ARIN identifies AS396982 as GOOGLE-CLOUD-PLATFORM. At the time of the query, the public API name therefore pointed toward an address originated in Google Cloud's network rather than an address visibly originated by AS209045.

This finding helps explain how a public control point may remain addressable even while AS209045 has no prefixes visible to RIPE RIS. It does not prove that the API was fully functional, that authenticated operations succeeded, or that all control functions were hosted in Google Cloud. DNS and origin-AS evidence reveal one edge of a path. They do not reveal every service behind the load balancer, the databases it uses, its failover design or the location of customer compute.

The domain record adds another external layer. Cloudflare RDAP records genesiscloud.com with the nameservers ara.ns.cloudflare.com and zeus.ns.cloudflare.com. The domain was registered on 5 August 2008, was last changed on 11 July 2026 and had an expiration date of 5 August 2027 in the reviewed response. That establishes domain-registration and authoritative-nameserver facts. It does not establish that Cloudflare carries all application traffic or that every Genesis Cloud service uses the same DNS design.

Google Cloud and Cloudflare should therefore be named as distinct dependencies visible at distinct points. Google Cloud is evidenced by the origin identity for the API address. Cloudflare is evidenced by the parent domain's nameserver records. Neither organisation is AS209045, Genesis Cloud Limited, Genesis Cloud GmbH, Bulk Infrastructure, DE-CIX or the RIPE contact role. The records do not establish that either one controls the customer's compute data plane.

For a buyer, the architectural question is not whether using external services is good or bad. It is whether those dependencies are understood and tested. If account access or orchestration depends on the public API name, the buyer should know what happens when its DNS answer changes, when the load-balancer address is unreachable, or when the API responds but the target region cannot allocate capacity. Control-plane reachability and data-plane availability need separate checks.

The Compute API documentation describes a rate limit averaging 10 requests per second. That defines a public automation constraint, but it does not prove that a recovery sequence will finish within a required time. Rebuilding a fleet can involve many calls, retries and dependent operations. The usable rate under stress, account quota, error behaviour and regional inventory all affect elapsed recovery. A documented rate is an input to a test, not the result of one.

The API DNS path also shows why a buyer should record dependencies by name and ASN rather than assume that branded resources form a closed network. A recovery plan that monitors only AS209045 could miss the health of the public control point. Conversely, a successful API health check could miss a withdrawn workload prefix or unavailable instance type. The two signals are complementary.

The defensible statement is precise: at review time, the public API name resolved through a Genesis Cloud load-balancer name to an address associated with Google Cloud's ASN, while the parent domain used Cloudflare nameservers. That is evidence of external control-plane dependencies. It is not a complete topology, a claim of wholesale outsourcing or proof of service health.

A documented object-storage name failed a basic resolution test

The regions documentation lists s3.nord-no-krs-1.genesiscloudusercontent.com as the object-storage endpoint for the Norway-KRS1 context. At review time, a Google Public DNS A query for that host returned status 3, an NXDOMAIN-style response. A separate NS query for genesiscloudusercontent.com also returned status 3. Unlike a broad inference from an ASN, this test addresses a name that the service documentation itself tells a customer to use.

That makes the result a strong buyer-test signal. A client cannot open a new connection to a hostname that does not resolve through the tested recursive resolver. An unresolved documented endpoint should prompt immediate verification of the current endpoint name, zone delegation, regional service status and any replacement instructions. It also raises a documentation-control question: is the published region page current for the object-storage service it describes?

The result still has strict limits. NXDOMAIN does not prove that stored objects were deleted, corrupted or inaccessible through every possible route. It does not establish that all object storage had failed, that an authenticated customer saw the same answer from every resolver, or that the overall cloud service had ended. Data may remain on media even when a public name is absent. A different endpoint, private name, cached answer or revised service path may exist, though none is established by the reviewed public material.

The test also does not disclose the storage design. The documentation and DNS response do not reveal physical replica placement, erasure coding, backup media, region independence, restore bandwidth or recovery-point history. Those are precisely the facts a buyer would need before treating object storage as a recovery anchor for compute workloads. The existence of an endpoint in documentation is not evidence that copies exist in a separate failure domain.

There is a useful contrast with api.genesiscloud.com. The API name resolved through an external load-balancer path, while the documented object-storage name did not resolve in the tested Google Public DNS response. This is not evidence that one entire service was healthy and the other had lost data. It demonstrates why control surfaces must be tested individually. A green result for one public name cannot stand in for every regional endpoint.

A buyer should repeat the storage test from its own network and account context, preserving the time, resolver, response code and endpoint supplied by the seller. If the endpoint has changed, the buyer should update automation and verify that credentials, bucket names, access policies and data copies work through the current path. If the endpoint is intentionally private, the architecture should identify the required resolver and network boundary.

Recovery planning should go further than name resolution. A meaningful object-storage test would write a known object, record its checksum and time, retrieve it through the expected recovery path, and measure both metadata and payload integrity. It would also establish which region holds each copy and whether the test remains valid when the primary compute environment is unavailable. No reviewed public source supplies such a dated, buyer-specific result.

The right conclusion is therefore neither to ignore the NXDOMAIN response nor to use it as proof of data loss. It is a high-priority discrepancy between documentation and a public DNS observation. Until resolved by a successful, dated test, buyers should not assume that the documented hostname can support an emergency restore.

Documented cloud controls are not executed recovery

Genesis Cloud's developer material exposes a recognisable set of cloud controls. The regions page lists Norway-KRS1, also identified as NORD-NO-KRS-1, and presents private networking, volumes and security groups as regional resources. Other pages describe instances, instance types, availability, images, snapshots and volumes. These documents show that customers have named mechanisms for creating and managing infrastructure. They do not show what happened in a real recovery event.

The instance documentation describes lifecycle operations, startup scripts and attached-volume handling. It also describes the consequence of terminating an instance with its boot disk. That is actionable operational information: a customer can understand that a destructive lifecycle action may remove state associated with the boot disk. Yet lifecycle control does not guarantee that an equivalent GPU can be allocated after termination, that a replacement region accepts the same image, or that attached data is complete.

The volume, image and snapshot pages expose fields for region, attachment, storage, image class, compatibility, cloning and snapshot operations. Current instance and snapshot material includes replicated_region or clone-to-region parameters. Those parameters form a documented portability surface. They indicate that a customer can ask the service to perform region-related copy or clone operations under stated interfaces. They do not establish universal cross-region replication, successful execution for every image class or a measured recovery point.

Security groups add another regional control. Their documentation presents firewall rules and traffic-control mechanics scoped by region. A buyer can use those controls to describe intended ingress and egress. The mere existence of rules does not prove that network paths are diverse, that east-west traffic is isolated as expected, or that equivalent rules can be recreated correctly during an incident. Configuration must be exported, reapplied and tested.

The region boundary itself requires caution. A label such as Norway-KRS1 tells the customer where a resource is logically placed. It does not disclose which building holds each copy, whether storage and compute share power or network dependencies, or how much spare capacity exists elsewhere. A second region name is not automatically a second independent failure domain. Independence has to be established through architecture and testing.

This is a common gap in cloud due diligence. Feature documentation is often treated as evidence of resilience because the controls needed for recovery appear to exist. But recoverability is a property of the customer's state, permissions, automation, capacity and tested sequence. A snapshot control has little value if the target region lacks compatible GPUs. A volume record has limited value if restore throughput misses the business deadline. A startup script may fail if its dependencies are unavailable.

The buyer should therefore translate each documented capability into an executable question. Can the current image be cloned to the intended target region? Can a volume be restored and attached to the selected instance type? Are security-group rules reproducible without access to the original instance? Does the startup sequence rely on the unresolved storage endpoint? Can all of this be done within account quota and the API's stated request-rate boundary?

No public document in the reviewed set answers those questions for a particular customer at a particular date. The documentation is still useful because it defines what to test and what evidence to request. Its proper role is to frame the recovery exercise, not to substitute for it.

Availability flags and catalogues do not reserve substitute capacity

The availability endpoint returns a Boolean availability state by region and instance type. The instance-type documentation lists CPU and GPU shapes for Norway-KRS1. Together, these controls can tell a customer what products are described and whether the service reports a type as available when queried. They do not constitute a reservation, a stock disclosure or a commitment that an equivalent machine will be allocatable during a regional disruption.

A Boolean necessarily compresses operational reality. It does not reveal how many units are free, whether several customers are competing for them, how long the state remains valid, or whether quota permits the requester to allocate the reported type. It may answer a narrow question at query time while leaving capacity depth unknown. For small experiments, that may be enough. For a large GPU fleet, it is not.

Substitution is also more demanding than matching a catalogue label. A recovery target may require the same accelerator class, memory, CPU ratio, local storage, image compatibility, network placement and software assumptions. A different shape may technically boot while failing performance, licensing or scheduling requirements. Public instance-type pages cannot prove workload equivalence without a representative test.

Capacity risk connects directly to regional state. A snapshot or image may be portable in the documented interface, but portability has no business value if the destination cannot allocate enough compatible compute. Conversely, spare compute has limited value if the customer's volumes, credentials or network rules cannot be reconstructed there. Recovery is the conjunction of capacity and state, not the presence of either one alone.

The facility records cannot fill this gap. A large campus and an exchange connection describe the environment around a service, not the allocatable inventory in a customer's account. Nor can a PeeringDB port speed be converted into GPU availability or storage throughput. Each metric belongs to a separate layer. Treating them as interchangeable would exaggerate what public infrastructure signals can prove.

A serious buyer should ask for a timed allocation exercise. The test should query the intended region and instance type, create enough representative capacity to expose quota and stock constraints, attach or restore the required state, apply network controls and run a workload check. If a second region is part of the claim, the exercise should begin without relying on the primary region's control artifacts unless those artifacts are demonstrably copied.

The result should be recorded as a dated measurement rather than a timeless assurance. Capacity changes, and a successful small allocation does not guarantee a fleet-scale recovery. For critical demand, contractual reservation or another explicit capacity arrangement may be necessary. The reviewed sources do not establish that such an arrangement exists, so no claim of spare or substitute GPU capacity is warranted.

Current price and service-credit claims are similarly unsupported here. Pages that might have supplied up-to-date pricing, legal terms or service-level remedies were unavailable in the latest access pass and were excluded as evidence. It would be unsafe to infer a current price, credit formula or remedy from older material. Buyers need the applicable commercial documents from their named counterparty and should tie those documents to the service and region actually being purchased.

Network controls must be tested as part of state recovery

Recovery discussions often separate compute state from network state, but a restored machine is not a restored service if clients cannot reach it safely. Genesis Cloud's documentation presents private networking and security groups as regional resources. That means a recovery design must account for network identities, firewall rules, address changes and dependencies that may not move with an image or snapshot.

The public routing evidence makes this especially relevant. If a workload expects ingress through addresses associated with AS209045, the buyer needs to know whether those addresses are currently announced and how they would be originated after recovery. If the workload instead uses an externally originated address or load balancer, then DNS, certificates and that external network become part of the recovery boundary. Neither model can be inferred from the API name alone.

Security-group recreation should be tested from a clean state. A ruleset may refer to old subnets, peer groups or service addresses that differ in the target region. A successful API response creating the rules is not enough; the buyer should verify allowed and denied flows from representative clients. It should also confirm that management access does not depend on a path lost with the original region.

Private networking requires similar scrutiny. A region-scoped private network can isolate traffic, but its existence does not prove path diversity or cross-region extension. If recovery depends on data copied to another region, the buyer should identify how that copy moves, which network carries it and whether the path remains available during the failure being planned for. Public documentation does not disclose that physical or logical topology.

DNS is part of network state as well. The contrast between the resolving API name and the non-resolving documented object-storage name shows that names must be checked individually. A recovery exercise should lower assumptions about cached answers, confirm authoritative delegation, validate current records and test from the networks customers actually use. It should not assume that a parent domain's healthy registration means every child name exists.

Exchange connectivity is another separate control point. The recorded 10G DE-CIX connections may be relevant to traffic performance when their sessions and routes are active. The reviewed down or passive route-server entries show why a buyer should verify present state rather than rely on configuration records. If bilateral peering or transit supplies an alternative, the operator should demonstrate that path and identify the prefixes it carries.

The practical recovery object is therefore larger than a virtual machine. It includes the image, attached data, credentials, quota, instance stock, network rules, DNS records, public origin path, private dependencies and monitoring. Any one of these can make an otherwise successful restore unusable. The public materials expose several controls, but they do not demonstrate the whole sequence under failure conditions.

This is also why the absence of AS209045 from RIS cannot alone settle workload health. A workload may use a different public origin. But the reverse is equally true: a resolving API name does not prove that workload ingress, storage or exchange paths are healthy. Buyers need an end-to-end test that crosses every layer relevant to their own service.

A buyer test should be dated, executable and service-specific

The public evidence is sufficient to design a focused diligence exercise. It is not sufficient to declare a buyer's environment recoverable. The distinction lies in execution. A useful test starts with the exact legal counterparty, account, region, instance type, data set and recovery target. It records commands, times and outcomes so that a later reviewer can distinguish observed results from statements of capability.

Account quota should be checked first because it can stop recovery before capacity is even tested. The buyer should query the target instance type in the intended region, record the Boolean availability response and attempt a representative allocation. The number of machines should be large enough to expose meaningful constraints. A single successful instance cannot validate replacement for a fleet.

State testing should then cover images, snapshots and volumes separately. The buyer should identify the image class and compatibility rules, invoke the documented region-related clone controls where applicable, and verify that the destination artifact can actually boot. A volume restore should be attached to a replacement instance, mounted, checked for expected data and timed. Snapshot metadata should be compared with known application checkpoints rather than treated as proof of completeness.

The object-storage endpoint deserves an explicit branch in the exercise. The buyer should obtain the currently supported endpoint, test DNS resolution from its normal and recovery networks, authenticate, write a known object and retrieve it with checksum verification. If the documented s3.nord-no-krs-1.genesiscloudusercontent.com name remains current, the status 3 responses need an explanation. If it has been replaced, the documentation and customer configuration need to reflect the replacement.

Network controls should be reconstructed rather than copied by assumption. Security groups should be recreated in the target region and tested for both permitted and blocked traffic. Private-network dependencies should be identified, and any public address or load-balancer change should be reflected in DNS and certificate tests. The exercise should verify client reachability, not merely show that the instance reports a running state.

The public API path should be monitored independently. A test can resolve api.genesiscloud.com, record the returned canonical name and address, identify the observed origin ASN, authenticate and perform the required lifecycle operations. It should account for the documented average limit of 10 requests per second. If the exercise needs more calls than the allowed pace supports, elapsed recovery time should include that constraint.

Routing evidence should be captured at the same time. For services expected to use AS209045, the buyer should record current announced prefixes, RIS visibility and observed neighbours. It should also inspect the relevant DE-CIX route-server sessions and route counts if peering is part of the architecture. A seller may demonstrate bilateral or transit paths outside those views, but those alternatives should be named and measured rather than asserted.

Commercial evidence belongs in the same file of results, but it must come from current documents supplied for the actual transaction. The reviewed public material does not support a current price, service-credit formula or remedy. The buyer should identify the legal entity, service description, region, capacity commitment, recovery objective and remedy language that apply to its account. A technical success and a contractual remedy answer different risk questions.

The exercise should end with measured recovery time and recovery point, plus unresolved dependencies. It should say how much capacity was restored, which data checkpoint was recovered, what network path clients used and which manual actions remained. No reviewed public source supplies this complete, dated result. Until a buyer performs or receives it, the controls remain plausible capabilities rather than demonstrated resilience.

Evidence grades should follow the layer, not the brand

The public record supports a medium evidence grade for several factual layers. RIPE and RDAP records support the identity of the role, ASN, organisation and registered resources. RIPEstat supports dated route-visibility observations. PeeringDB and DE-CIX support recorded exchange configuration and selected session states. Google Public DNS, RIPEstat network information, ARIN and Cloudflare RDAP support the observed DNS and network-identity facts. Developer documentation supports the existence of named API controls.

Medium does not mean complete. Registry records can be authoritative for registration while remaining silent on live traffic. An exchange looking glass can be direct for a selected route-server session while remaining silent on bilateral peering. DNS can be direct for a response from a tested resolver while remaining silent on stored data. Documentation can accurately describe controls while remaining silent on successful execution for a customer's account.

The evidence is weak for buyer-specific physical capacity, storage replication, substitute GPU inventory, topology redundancy and executed recovery. No reviewed source discloses enough physical placement to prove independent failure domains. No source supplies a dated inventory commitment for replacement accelerators. No source gives a buyer's measured restore throughput, complete recovery point or fleet recovery time.

The evidence is also insufficient for broad legal inference. The GLEIF record is specific to Genesis Cloud GmbH. Extending its LAPSED status or liquidation event to Genesis Cloud Limited, Genesis Cloud Norway AS, AS209045 or all customer services would exceed the record. Likewise, LIR membership for Genesis Cloud Limited does not identify every contracting entity or establish equipment ownership.

Current routing absence has medium confidence within its measurement boundary. The RIPEstat response is dated and numerically explicit, and the empty current-prefix window aligns with zero observed neighbours. What remains weak is the causal explanation and the effect on any named customer service. Those require other evidence.

The PeeringDB-to-DE-CIX discrepancy also receives a bounded reading. There is medium confidence that two 10G entries were recorded as operational and that the reviewed route-server neighbours were down or passive with zero routes. There is weak evidence about physical port state, bilateral sessions, transit alternatives and total customer traffic because the sources do not resolve those points.

The API and storage DNS observations follow the same pattern. There is medium confidence in the answers returned by Google Public DNS at review time and in the network identity associated with 34.76.254.30. There is weak evidence about full control-plane topology, redundancy, storage health or data loss. The right grade changes as the question moves outward from the observed response.

This layered grading is more useful than a single score for the company. It tells buyers where public evidence can support a working assumption and where direct testing is necessary. It also makes updates easier: a new route announcement changes the routing layer, not the historical legal record; a successful storage restore strengthens recovery evidence without changing who owns the ASN.

The commercial reading is conditional, not categorical

Taken together, the records describe a cloud-branded service with registered Internet resources, documented compute controls, recorded European interconnection and externally visible control dependencies. They also show that AS209045 had no RIPE RIS-visible IPv4 or IPv6 prefixes at the strongest current timestamp, that selected DE-CIX route-server sessions were down or passive, and that a documented regional object-storage hostname did not resolve in the tested public DNS responses.

That combination should increase diligence, not produce a shortcut conclusion. Registered resources and route authorisations show continuity of administrative objects. They do not offset the current absence of observed announcements. The API's external network path shows that some public control reachability can be separate from AS209045. It does not establish that customer workloads or storage are healthy. The object-storage DNS result identifies a concrete discrepancy. It does not prove data loss.

For a buyer, the decisive issue is whether the service can demonstrate the exact capacity and state transition the buyer needs. A small research workload may tolerate manual recovery and uncertain replacement timing. A large GPU workload with data gravity may require reserved substitute capacity, tested cross-region copies and a measured network change. Public feature pages cannot close that gap.

The legal identity of the seller must also be explicit. Genesis Cloud Routing, Peering and DNS is a RIPE role and should remain exactly that in the record. Genesis Cloud Limited is the organisation associated with AS209045 and the reviewed RIPE resources. Genesis Cloud GmbH has its own GLEIF status and event. Any customer agreement should name the actual counterparty and should not rely on a registry role or brand shorthand.

Infrastructure dependencies should be similarly explicit. Bulk Infrastructure supplies context for the N01 site, not proof of Genesis Cloud facility ownership. DE-CIX supplies exchange services and observations, not proof of all routing paths. Google Cloud appears behind the reviewed API address, and Cloudflare appears in nameserver records; neither fact maps the entire service. Treating these dependencies as named boundaries makes continuity planning more realistic.

The current public record therefore supports a conditional assessment. There is enough evidence to identify technical controls and to frame precise tests. There is not enough evidence to assign high confidence to independent routing, substitute GPU capacity, cross-region state portability, object-storage continuity or recovery time. Buyers should withhold resilience credit for those claims until dated exercises close them.

This conclusion does not require assuming bad faith or permanent failure. Configuration records often lag operational state, architectures change, and public documentation can fall behind a service. The remedy is current evidence: live routes if AS209045 is meant to carry traffic, current endpoint information, successful capacity allocation, restored state, recreated network policy and reachable applications.

Genesis Cloud's public footprint is most informative when read as a set of boundaries. The RIPE role is a contact, not a seller. Registered resources are authority, not traffic. PeeringDB entries are configured presence, not continuous measurements. DE-CIX route-server states are selected observations, not a total network verdict. DNS responses are endpoint facts, not complete architecture. API controls are capabilities, not recovery results. Once those boundaries are kept intact, the apparent contradiction becomes a practical diligence plan.

Sources

1. RIPE REST — role GCRP3-RIPE - https://rest.db.ripe.net/ripe/role/GCRP3-RIPE.json
2. RIPE RDAP — AS209045 - https://rdap.db.ripe.net/autnum/209045
3. RIPE REST — organisation ORG-GCL19-RIPE - https://rest.db.ripe.net/ripe/organisation/ORG-GCL19-RIPE.json
4. RIPE NCC — Local Internet Registries in Malta - https://www.ripe.net/membership/member-support/list-of-members/mt/
5. GLEIF — LEI 894500D5RP23ET9F9O40 - https://api.gleif.org/api/v1/lei-records/894500D5RP23ET9F9O40
6. RIPE REST — resources linked to ORG-GCL19-RIPE - https://rest.db.ripe.net/search.json?query-string=ORG-GCL19-RIPE&type-filter=inetnum&type-filter=inet6num&type-filter=aut-num&inverse-attribute=org&flags=no-referenced&flags=no-filtering
7. RIPE REST — route and route6 objects for AS209045 - https://rest.db.ripe.net/search.json?query-string=AS209045&type-filter=route&type-filter=route6&inverse-attribute=origin&flags=no-referenced&flags=no-filtering
8. RIPE REST — aut-num AS209045 policy - https://rest.db.ripe.net/ripe/aut-num/AS209045.json
9. PeeringDB — AS209045 public page - https://www.peeringdb.com/asn/209045
10. PeeringDB API — AS209045 depth 2 - https://www.peeringdb.com/api/net?asn=209045&depth=2
11. RIPEstat routing status — AS209045 - https://stat.ripe.net/data/routing-status/data.json?resource=AS209045
12. RIPEstat announced prefixes — current AS209045 - https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS209045
13. RIPEstat announced prefixes — AS209045 2025-11 to 2025-12 - https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS209045&starttime=2025-11-01T00:00:00&endtime=2025-12-03T00:00:00
14. RIPEstat ASN neighbours — AS209045 at 2025-12-01 - https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS209045&query_time=2025-12-01T00:00:00&lod=1
15. RIPEstat RPKI history — AS209045 IPv4 - https://stat.ripe.net/data/rpki-history/data.json?resource=AS209045&family=4&resolution=d
16. RIPEstat RPKI history — AS209045 IPv6 - https://stat.ripe.net/data/rpki-history/data.json?resource=AS209045&family=6&resolution=d
17. BGP.tools — AS209045 - https://bgp.tools/as/209045
18. DE-CIX looking glass API — Frankfurt IPv4 neighbours - https://lg.de-cix.net/api/v1/routeservers/rs1_fra_ipv4/neighbors
19. DE-CIX looking glass API — Frankfurt IPv6 neighbours - https://lg.de-cix.net/api/v1/routeservers/rs1_fra_ipv6/neighbors
20. DE-CIX looking glass API — Kristiansand IPv4 neighbours - https://lg.de-cix.net/api/v1/routeservers/rs1_krs_ipv4/neighbors
21. DE-CIX looking glass API — Kristiansand IPv6 neighbours - https://lg.de-cix.net/api/v1/routeservers/rs1_krs_ipv6/neighbors
22. DE-CIX — Genesis Cloud peering news - https://www.de-cix.net/en/about-de-cix/news/genesis-cloud-enhances-ai-and-hpc-capabilities-with-de-cix-peering
23. DE-CIX — Genesis Cloud peering PDF case study - https://www.de-cix.net/_Resources/Persistent/7/0/6/4/70646d11ea3d9beea4d676de422368b2bf1ab4e9/AI%20and%20HPC%20in%20the%20Nordics_Genesis%20Cloud%20benefits%20from%20peering%20in%20Frankfurt.pdf
24. DE-CIX — Kristiansand location - https://www.de-cix.net/en/locations/kristiansand
25. Bulk Infrastructure — N01 data centre campus - https://bulkinfrastructure.com/data-centers/locations/n01/p3
26. Bulk Infrastructure — data-centre connectivity - https://bulkinfrastructure.com/data-centers/connectivity
27. Genesis Cloud Developers — Compute API - https://developers.genesiscloud.com/compute-api/
28. Genesis Cloud Developers — Regions - https://developers.genesiscloud.com/compute-api/regions/
29. Genesis Cloud Developers — Availability - https://developers.genesiscloud.com/compute-api/availability/
30. Genesis Cloud Developers — Instance types - https://developers.genesiscloud.com/compute-api/instance-types/
31. Genesis Cloud Developers — Instances - https://developers.genesiscloud.com/compute-api/instances/
32. Genesis Cloud Developers — Volumes - https://developers.genesiscloud.com/compute-api/volumes/
33. Genesis Cloud Developers — Images - https://developers.genesiscloud.com/compute-api/images/
34. Genesis Cloud Developers — Snapshots - https://developers.genesiscloud.com/compute-api/snapshots/
35. Genesis Cloud Developers — Security groups - https://developers.genesiscloud.com/compute-api/security-groups/
36. Cloudflare RDAP — genesiscloud.com - https://rdap.cloudflare.com/rdap/v1/domain/genesiscloud.com
37. Google Public DNS — api.genesiscloud.com CNAME - https://dns.google/resolve?name=api.genesiscloud.com&type=CNAME
38. Google Public DNS — api.genesiscloud.com A - https://dns.google/resolve?name=api.genesiscloud.com&type=A
39. RIPEstat network-info — 34.76.254.30 - https://stat.ripe.net/data/network-info/data.json?resource=34.76.254.30
40. ARIN RDAP — AS396982 - https://rdap.arin.net/registry/autnum/396982
41. Google Public DNS — s3.nord-no-krs-1.genesiscloudusercontent.com A - https://dns.google/resolve?name=s3.nord-no-krs-1.genesiscloudusercontent.com&type=A
42. Google Public DNS — genesiscloudusercontent.com NS - https://dns.google/resolve?name=genesiscloudusercontent.com&type=NS