Summary

  • Public identity, DNS delegation, autonomous-system registration, route observation and interconnection records describe different technical layers.
  • The current evidence set does not verify the live values behind the relevant Genesis Cloud, Verisign, Google Public DNS, RIPE and PeeringDB endpoints, so it cannot establish present control or global availability.

The attractive mistake in infrastructure reporting is to treat a chain of public records as if it were a single control panel. A company name appears on a website. A domain has a registration and a delegation. An autonomous system has a registry object and perhaps visible announcements. A network may list facilities or exchanges in PeeringDB. From there, it is tempting to conclude that the same organisation owns the whole path from brand identity to application reachability.

That conclusion is stronger than the records warrant.

The useful question for Genesis Cloud is not whether a public record exists somewhere in the chain. It is what each record can establish, what it cannot establish, and which missing observation would be needed to connect one layer to the next. This investigation therefore treats identity, DNS, routing, interconnection and application availability as separate control surfaces rather than as interchangeable evidence.

The evidence problem comes first

The current research set contains runtime-issued snapshots for the Verisign RDAP record for genesiscloud.com, Google Public DNS queries for its NS and SOA records, RIPE RDAP and RIPE Database records for AS209045, RIPEstat’s announced-prefixes endpoint, and PeeringDB’s network endpoint. The retrieval record says that live HTTP retrieval was unavailable and that no endpoint-derived current facts were asserted. The individual snapshots likewise report that the requested values were not verified.

That is a finding about the evidence state, not proof that the underlying records do not exist.

The Verisign snapshot does not verify the domain’s current registration, status, nameservers or event data. The Google Public DNS NS snapshot does not verify the authoritative delegation or response metadata. The SOA snapshot does not verify the primary server, responsible mailbox, serial, timers, TTL or response metadata. Those limitations are material because DNS is often the first public layer used to connect a brand to an operational service. Here, that connection remains unverified in the available evidence.

Verisign’s RDAP record, the Google Public DNS NS response and the Google Public DNS SOA response are therefore best read as evidence locations whose current contents were not established in this run, not as confirmation of a particular registrar, nameserver operator or DNS architecture.

Registration is not routing

The same separation applies to AS209045. An autonomous-system registry record identifies an administrative object. An aut-num object can contain declared routing-policy information and associated administrative data. A routing measurement can show what was observed from a particular measurement system and time. These are related, but they are not the same claim.

The current RIPE RDAP snapshot does not verify AS209045’s registry identity, status, contacts, remarks or event dates. The RIPE Database snapshot does not verify its routing-policy attributes, maintainers, source or modification metadata. The RIPEstat announced-prefixes snapshot does not verify currently observed IPv4 or IPv6 prefixes, its observation window or API status metadata.

Those three non-verifications should not be compressed into “AS209045 was absent from the Internet,” nor expanded into “Genesis Cloud controls all routes associated with the number.” They indicate that the available source material did not establish the relevant values.

The distinction matters operationally. Registration answers an administrative question: which object is recorded in a numbering database? A routing-policy object answers a declared-policy question: what statements or relationships are represented in the database? A route observation answers a measurement question: what did the selected system see at a particular time? None alone proves that traffic from every network can reach a service, that a route is globally propagated, or that the company named in a brand record operates every intermediary.

The RIPE RDAP record, RIPE Database aut-num object and RIPEstat announced-prefixes response belong in one evidence chain, but they should remain three different links in it.

PeeringDB is a declaration, not a packet path

PeeringDB adds another layer. It can provide participant-reported information about network identity, traffic profile, policy, facilities, exchanges and sessions. Such information can be valuable for understanding how a network presents its interconnection intentions and relationships. It is not equivalent to an independently verified packet path.

The current PeeringDB snapshot does not verify the network identity, traffic profile, policy, facilities, exchanges, sessions or update timestamp for ASN 209045. Even a fully populated record would still need careful interpretation. A participant-reported facility or exchange entry would not, by itself, prove an active BGP session at the moment of publication. A listed policy would not prove that every route is accepted or propagated. A declared presence would not prove application-level reachability.

The PeeringDB record should therefore be treated as a potential declaration about interconnection, not as a substitute for route collectors, multiple vantage points, packet-level tests or application checks.

This is not a criticism of the database. It is a category distinction. Public infrastructure records are often most useful when their evidentiary role is kept narrow. PeeringDB can help answer “what does the participant report?” It cannot alone answer “is traffic currently flowing from this user network to this service?”

The missing links are the story

A complete control assessment would have to connect at least five layers.

First is identity: which organisation publicly presents the service and which legal or operational entities are associated with it? Second is DNS: who controls delegation and authoritative answers for the relevant domain and service names? Third is numbering and routing: which autonomous-system and address objects are registered, what policy is declared, and what routes are observed from multiple locations? Fourth is interconnection: which facilities, exchanges, transit providers or peers are reported, and which of those relationships are active?

Fifth is the application layer: can independent users resolve the service, establish transport connections and complete an application transaction?

A break at any one layer changes the conclusion. A valid domain does not prove a reachable application. A route does not prove a responsive service. A PeeringDB listing does not prove an active BGP session. A registry object does not prove current operational control. Conversely, the absence of a verified value in one snapshot does not prove that the underlying resource is absent.

This layered model also clarifies why a cloud provider can appear healthy from one vantage point while a customer experiences failure elsewhere. DNS answers can vary by resolver and time. Routing can differ by upstream and geography. Interconnection can be available at one facility but not another. An application can fail after the network path succeeds. The public record is a map of distinct mechanisms, not a single uptime certificate.

What can be concluded now

The evidence supports a bounded conclusion. Public sources were selected to investigate Genesis Cloud’s identity and domain, AS209045’s registry and routing layers, and its reported interconnection position. The current retrieval run did not verify the live values required to connect those layers. It therefore cannot establish who currently controls the domain delegation, what AS209045 currently declares, which prefixes are currently observed, what PeeringDB reports today, or whether an application is reachable end to end.

That conclusion is narrower than a positive attribution and narrower than a failure claim. It preserves the difference between “not verified” and “does not exist.” It also identifies the next evidence needed: successful retrieval of the authoritative records, dated route observations from multiple measurement perspectives, an independently checked interconnection picture, and application-layer tests from relevant user networks.

For infrastructure operators and their customers, this is more than a wording preference. Control is a chain. An incident, migration or forced exit can break one link while leaving the others intact. A company may retain its domain while changing transit. A route may remain visible while the application is down. A DNS delegation may answer while the service behind it is unavailable. Public evidence becomes operationally useful only when each observation is assigned to the layer it actually measures.

Genesis Cloud’s public network story should therefore remain open at the points where the current evidence is open. The records can define an investigation plan. They cannot, on this evidence, collapse separate declarations and measurements into proof of present control or global availability.