ZEROSPACE Christian Wittenberg trading as Zerospace Cloud verkauft gehostete Kapazität, die noch von Racks, Transit und Reparaturfenstern abhängt

Resümee

• Das RIPE RDAP identifiziertAS201801als ZEROSPACE und verbindet es mit Christian Wittenberg trading as Zerospace Cloud in Veldhoven, Niederlande; die AS-Übersicht des RIPEstat gab an, dass das AS am 15. Juli 2026 angekündigt wurde.
• Der geroutete Raum ist klein, aber sichtbar: derRouting-Statuszeigte ein IPv4-Präfix, 256 IPv4-Adressen, acht /48 IPv6 und zwei beobachtete Nachbarn, während dieangekündigten Präfixe185.140.53.0/24 plus acht sichtbare /48 IPv6 auflisteten.
• Die Routenursprungshygiene ist ein Pluspunkt: RIPEstat gab gültiges RPKI für185.140.53.0/24und für2a07:1a84::/48zurück, wobei die IPv6-Validierung von einem ROA über 2a07:1a84::/44 und einer maximalen Länge /48 abhängt.
• Der operative Nachweis ist schwach: dasPeeringDBlistet Zerospace Cloud, zeigt aber null öffentliche IX und null Einrichtungen; derGeofeedbildet Adressblöcke auf zehn Metropolbezeichnungen ab, belegt aber keine lokalen Racks, Energie, Hardware, Support oder Kundenmigrationsfähigkeit in diesen Metropolen.

Das Unternehmen hat eine echte Netzidentität, aber die Identität ist neu

Die erste Tatsache, die es wert ist, vom Rauschen getrennt zu werden, ist, dass Zerospace Cloud nicht nur ein Marketing-Spruch ist. Das RIPE RDAP unterhttps://rdap.db.ripe.net/autnum/201801registriert AS201801 als ZEROSPACE, Status aktiv, mit einem Registrierungsereignis am 30. Januar 2026 und einem letzten Änderungsereignis am 13. März 2026. Die Organisationseinheit in derselben RDAP-Antwort ist Christian Wittenberg trading as Zerospace Cloud, mit Veldhoven, Niederlande, als öffentliche Adresse. Die RDAP-Antwort nennt auch Zerospace Cloud Network Operations als administrativen und technischen Kontakt und Zerospace Cloud Abuse Department als Missbrauchskontakt. Für einen kleinen Cloud- oder Hosting-Anbieter ist dies eine nützliche Basislinie: Es gibt eine benannte Organisation, ein benanntes Netzwerk und benannte operative Kontaktrollen.

Die Adressdatensätze entsprechen der AS-Identität. Das RIPE RDAP unterhttps://rdap.db.ripe.net/ip/185.140.53.0/24identifiziert 185.140.53.0 bis 185.140.53.255 als ZEROSPACE-CLOUD, zugewiesen PA, Land NL, Status aktiv, mit Hinweisen auf einen Geofeed unterhttp://download.zerospace.cloud/ipam/geofeed.csv. Das RIPE RDAP unterhttps://rdap.db.ripe.net/ip/2a07:1a84::/44identifiziert 2a07:1a84::/44 als ZEROCLOUD, aggregiert vom LIR, Land NL, Status aktiv, mit derselben Organisation und demselben Geofeed-Verweis. Die Präfixübersicht des RIPEstat fürhttps://stat.ripe.net/data/prefix-overview/data.json?resource=185.140.53.0/24identifiziert AS201801 als den Ursprungsinhaber für das IPv4 /24.

Diese Datensätze beweisen kein ausgereiftes Hosting-Vermögen. Sie beweisen einen aktuellen Routeninhaber mit aktiven registrierten Ressourcen. Das Alter spielt eine Rolle. Das autonome System und das IPv6-Aggregat wurden Ende Januar 2026 registriert, und das IPv4 /24 wurde im Februar 2026 registriert. Das ist neu genug, dass Kunden die öffentlichen operativen Nachweise als noch in der Entstehung betrachten sollten. Neue Infrastrukturanbieter können fähig sein; sie können sich auch in einem Stadium befinden, in dem Routing, Marke, Support-Prozesse und physische Lieferantenverträge noch konsolidiert werden.

Die richtige Frage ist nicht, ob AS201801 existiert. Es existiert. Die richtige Frage ist, welche Kundendienste sicher darauf platziert werden können.

Das öffentliche Routensignal ist aktiv. Die AS-Übersicht des RIPEstat unterhttps://stat.ripe.net/data/as-overview/data.json?resource=AS201801gab den Inhaber als ZEROSPACE Christian Wittenberg trading as Zerospace Cloud an und das AS als in der Abfrage vom 15. Juli 2026 angekündigt. Der Routing-Status des RIPEstat unterhttps://stat.ripe.net/data/routing-status/data.json?resource=AS201801meldete eine breite öffentliche Sichtbarkeit: 324 von 326 IPv4 RIS-Peers und 322 von 322 IPv6 RIS-Peers sahen den gerouteten Raum. Das ist nicht die Signatur einer ungenutzten Registrierung. Es ist die Signatur eines kleinen Netzwerks, das für das globale Routing-System sichtbar ist.

Für Infrastrukturkäufer ist die Live-Routen-Sichtbarkeit notwendig, aber nicht ausreichend. Ein Anbieter kann ein /24 und mehrere /48 IPv6 routen, während er immer noch von gemieteten virtuellen Servern, weiterverkauftem Colocation, einem einzigen Remote-Arbeitskraftanbieter oder einer kleinen Anzahl von Upstreams abhängt. Eine Route zeigt, dass Pakete die angekündigten Präfixe erreichen können.

Es zeigt nicht, dass ein Kunde nach einem Festplattenausfall Ersatzhardware erhalten, einen großen Datensatz unter Zeitdruck exportieren, sich von einem Speicherausfall erholen oder einen Menschen mit der Autorität erreichen kann, einen Stromvorfall zu beheben. Gehostete Kapazität verwandelt die Routensichtbarkeit nur dann in einen Dienst, wenn es Racks, Strom, Kühlung, Hardwarebestand, Zugangsverfahren, Support-Abdeckung und Ausgangspfade hinter den Präfixen gibt.

Der geroutete Raum ist klein, sichtbar und ungleich angekündigt

Das IPv4-Bild ist kompakt. Die Daten der angekündigten Präfixe des RIPEstat unterhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201801zeigten 185.140.53.0/24, das während des Fensters vom 1. bis 15. Juli 2026 kontinuierlich angekündigt wurde. Der Routing-Status zählte dies als ein IPv4-Präfix und 256 IPv4-Adressen. Für einen Hosting- oder Cloud-Dienst kann ein /24 betrieblich nützlich sein, ist aber klein. Es kann einen fokussierten Anycast-Dienst, NAT-Gateways, Kundenverwaltungsendpunkte, eine Reihe von VPS-Knoten oder eine begrenzte Anzahl direkt zugewiesener Kundenadressen unterstützen. Es ist für sich genommen kein Beweis für ein großes Rechenvermögen.

Das IPv6-Bild ist in der Adressmathematik expansiver und in der aktuellen Sichtbarkeit nuancierter. Der RDAP-Datensatz deckt 2a07:1a84::/44 ab, das sechzehn mögliche /48s enthält. Das PeeringDB-Netzobjekt unterhttps://www.peeringdb.com/api/net?asn=201801listet ein IPv4-Präfix und sechzehn IPv6-Präfixe im Profil. Der Endpunkt für angekündigte Präfixe des RIPEstat zeigte jedoch während des Überprüfungsfensters acht sichtbare /48 IPv6: 2a07:1a84::/48,:1::/48,:2::/48,:3::/48,:4::/48,:5::/48,:6::/48 und:9::/48. Die AS-Routing-Konsistenzansicht des RIPEstat unterhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201801fügte das nützliche Detail hinzu, dass 2a07:1a84::/44 im Whois, aber nicht im BGP war, während mehrere /48s sowohl im Whois als auch im BGP waren und mehrere andere /48s im Whois, aber nicht im BGP waren.

Dieser Unterschied ist wichtig für installierte Kapazität versus nutzbare Kapazität. Installierte Adresskapazität ist das registrierte IPv6 /44 und die PeeringDB-Erklärung von sechzehn IPv6-Präfixen. Nutzbare geroutete Kapazität ist die Teilmenge, die im relevanten Zeitraum tatsächlich im BGP sichtbar ist. Die nutzbare Kundenkapazität ist noch enger: die Präfixe, die ein Kunde vertraglich vereinbaren, über einen bekannten Standort routen, mit RPKI sichern, überwachen, unterstützen und verschieben kann, wenn ein Anbieter, eine Einrichtung oder ein Upstream ausfällt.

Ein /44 kann auf dem Papier riesig erscheinen, während nur ausgewählte /48s im öffentlichen Routing aktiv sind und nur eine kleinere Teilmenge an Produktionsdienste gebunden ist.

Das IPv6-Timing weist auch auf ein aktiv wechselndes Netzwerk hin. RIPEstat zeigte 2a07:1a84::/48 und 2a07:1a84:5::/48 ab Anfang Juli sichtbar, wobei:5::/48 eine kurze Lücke zwischen dem 3. und 5. Juli aufwies. Es zeigte mehrere andere /48s, die ab dem 12. Juli 2026 sichtbar wurden. Dies beweist keine Instabilität im Sinne einer Kundenbeeinträchtigung; neue IPv6-Standorte oder Dienstknoten kommen oft in Wellen online.

Es bedeutet, dass der Kunde fragen sollte, welche /48s als Produktion gelten, welche Test- oder Qualifizierungszuweisungen sind, welche an eine Stadtbezeichnung gebunden sind und welche über eine getestete Failover-Funktion verfügen.

Die Routenursprungsvalidierung ist einer der besten Teile der Zerospace-Registrierung. RIPEstat gab einen gültigen Status für 185.140.53.0/24 unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=185.140.53.0/24zurück, mit Ursprungs-AS 201801 und maximaler Länge /24. Es gab einen gültigen Status für 2a07:1a84::/48 unterhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=2a07:1a84::/48zurück, validiert gegen einen ROA über 2a07:1a84::/44 mit maximaler Länge /48. RPKI hält keine Server am Laufen, gibt aber Routenfiltern eine Möglichkeit, autorisierte Ursprungsankündigungen von nicht autorisierten zu unterscheiden. Für ein neues, kleines Netzwerk ist diese Hygiene wichtig.

Das Upstream-Bild ist sichtbar, das Einrichtungsbild jedoch nicht

Die Upstream-Registrierung ist klarer als die Einrichtungsregistrierung. Die ASN-Nachbarn des RIPEstat unterhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201801zeigten zwei beobachtete Nachbarn: AS57758 und AS63473. Die AS-Übersicht des RIPEstat identifiziert AS57758 als CBWS Holding B.V. und AS63473 als HostHatch, LLC. Die Whois-Ansicht unterhttps://stat.ripe.net/data/whois/data.json?resource=AS201801listet auch Import- und Exportrichtlinieneinträge für AS20473, AS63473 und AS57758 auf, während die öffentliche Beobachtung der Nachbarn zum überprüften Zeitpunkt AS57758 und AS63473 zeigte. AS20473 ist in der AS-Übersicht des RIPEstat The Constant Company, LLC, allgemein mit Vultr im AS-Namen assoziiert.

Dies reicht aus, um eine Abhängigkeitsoberfläche zu beschreiben, nicht aber, um Diversität zu bescheinigen. Zwei beobachtete Nachbarn sind besser als einer, wenn sie tatsächlich unabhängig im Kundendienstpfad sind, sich in getrennten Einrichtungen oder Fehlerdomänen befinden und beide für die Kundenpräfixe konfiguriert sind. Aber zwei ASNs können sich dasselbe Gebäude, denselben Meet-Me-Raum, dieselbe städtische Glasfaser, dasselbe Stromereignis oder dasselbe Remote-Wartungsfenster teilen. Die öffentlichen BGP-Daten können uns nicht sagen, ob die Zerospace-Router in einem Rack oder an mehreren Standorten sind.

Sie können uns nicht sagen, ob beide Nachbarn alle Produktionspräfixe tragen, ob das Failover automatisch ist, ob ein Nachbar nur Backup ist oder ob die Steuerungsebene des Kunden von derselben physischen Übergabe abhängt.

PeeringDB vertieft diese Vorsicht. Der PeeringDB-Netzwerkeintrag von Zerospace Cloud unterhttps://www.peeringdb.com/api/net?asn=201801listet AS201801, Websitehttps://zerospace.cloud, IRR as-set AS201801:AS-ZEROSPACE-CLOUD, ein IPv4-Präfix, sechzehn IPv6-Präfixe, policy_general Open, Status ok, einen Erstellungszeitstempel im Oktober 2022 und einen Aktualisierungszeitstempel am 8. Februar 2026. Aber der PeeringDB-Exchange-LAN-Endpunkt unterhttps://www.peeringdb.com/api/netixlan?asn=201801gab keine öffentlichen IX-Zeilen zurück, und sein Einrichtungsendpunkt unterhttps://www.peeringdb.com/api/netfac?net_id=31374gab keine öffentlichen Einrichtungszeilen zurück. PeeringDB wird vom Betreiber gepflegt und kann unvollständig sein, daher ist eine leere Einrichtungsliste kein Beweis für das Fehlen einer Einrichtungspräsenz. Es ist ein Beweis dafür, dass der öffentliche Einrichtungsnachweis fehlt.

Für einen Cloud-Käufer ist das Fehlen von Einrichtungsnachweisen kein kleines Detail. Einrichtungen sind der Ort, an dem Routenversprechen zu operativen Versprechen werden. Ein Kunde muss wissen, welches Rechenzentrum die Server beherbergt, welche Einheit das Rack mietet, welches Remote-Arbeitskräfteteam die Hardware berühren kann, ob es redundante Stromquellen gibt, ob die Gehäuse innerhalb der vertraglichen Leistungsgrenzen liegen, wie die Kühlung bereitgestellt wird und welche Cross-Connects zu welchen Upstreams führen.

Ohne eine öffentliche Einrichtungsliste oder eine Einrichtungserklärung eines Dritten müssen Kunden direkt fragen und vertraglich überprüfen.

Dies gilt insbesondere für Zerospace, da der Geofeed global ist, während der sichtbare öffentliche Einrichtungsnachweis leer ist. Ein Geofeed kann für Content-Lokalisierung, Betrugskontrollen, Latenz-Routing und Kundenerwartungen nützlich sein. Er kann eine Einrichtungserklärung nicht ersetzen. Ein Anbieter kann kleine Adressblöcke einer Stadt zuordnen, weil sich dort eine VM, ein Tunnelendpunkt, ein Reseller-Knoten, eine Cloud-Instanz oder eine Partnerbereitstellung befindet. Dies beweist keine eigenen Racks, Ersatzserver, Ersatzoptik, Out-of-Band-Management, Batteriezeit, Generatorabdeckung oder lokalen Support.

Der Geofeed beschreibt Stadtbezeichnungen, keine garantierte lokale Infrastruktur

Der Geofeed unterhttps://download.zerospace.cloud/ipam/geofeed.csvist eines der informativsten öffentlichen Artefakte in der Zerospace-Registrierung. Er bildet 185.140.53.0/29 auf Amsterdam, 185.140.53.8/29 auf London, 185.140.53.16/29 auf Stockholm, 185.140.53.24/29 auf Seoul, 185.140.53.32/29 auf Singapur, 185.140.53.40/29 auf Hongkong, ausgewählte /32s in 185.140.53.48 bis 185.140.53.55 auf Tokio, 185.140.53.56/29 auf Sydney, 185.140.53.64/29 auf New York und 185.140.53.72/29 auf Los Angeles ab. Er bildet IPv6-/48s auf dasselbe Stadtmuster ab: 2a07:1a84::/48 auf Amsterdam,:1::/48 auf London,:2::/48 auf Stockholm,:3::/48 auf Seoul,:4::/48 auf Singapur,:5::/48 auf Hongkong,:6::/48 auf Tokio,:7::/48 auf Sydney,:8::/48 auf New York und:9::/48 auf Los Angeles.

Dies ist ein Zeichen für ein globales Dienstgebiet, kein Beweis für globale Kapazität. Bei IPv4 sind die meisten Stadteinträge /29s, was jeweils acht Adressen bedeutet. Die IPv4-Einträge für Tokio sind einzelne /32s oder sehr kleine Gruppierungen, und der Geofeed deckt nicht jede Adresse im /24 mit einer expliziten benannten Stadt ab. Die RIPEstat-Geolokalisierung unterhttps://stat.ripe.net/data/geoloc/data.json?resource=185.140.53.0/24und die MaxMind GeoLite-Ansicht unterhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=185.140.53.0/24spiegelten eine ähnliche Verteilung wider, zeigten aber auch einen großen Teil des IPv4 /24 als Schweden ohne Stadt in der abgefragten Ansicht. Dies bedeutet, dass das öffentliche Geolokalisierungsbild gemischt ist: einige Adressblöcke haben genaue Stadtbezeichnungen; ein großer Teil des IPv4-Adressraums präsentiert sich nicht als detaillierte Stadt-für-Stadt-Computerkarte.

Die IPv6-Standortansicht erfordert ebenfalls eine sorgfältige Lesung. Die RIPEstat-Geolokalisierung fürhttps://stat.ripe.net/data/geoloc/data.json?resource=2a07:1a84::/44und die MaxMind GeoLite-Ansicht unterhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=2a07:1a84::/44zeigten das /44 aufgeteilt in mehrere nach Stadt bezeichnete /48s, wobei ein wesentlicher Teil des Aggregats als Schweden ohne Stadt erschien. Der Geofeed listet:7::/48 für Sydney und:8::/48 für New York, während der Endpunkt für angekündigte Präfixe diese /48s nicht unter den acht sichtbaren Präfixen während dieses Überprüfungsfensters zeigte. Dies ist nicht unbedingt ein Widerspruch; die Geofeed-Einträge können eine beabsichtigte oder registrierte Örtlichkeit beschreiben, während die Routensichtbarkeit im Laufe der Zeit variiert. Es ist eine Erinnerung daran, dass Standortbehauptungen mit dem aktuellen Routing-Status verknüpft sein sollten.

Kunden, die von dieser Unterscheidung betroffen sind, sind nicht nur Endnutzer in diesen Städten. Ein kleiner Cloud-Anbieter kann VPN-Gateways, Edge-Knoten, verwaltetes Hosting, Entwickler-Workloads, Backup-Ziele, Spieleinfrastruktur, Testumgebungen, kleine Unternehmensdienste oder regionale Zugangspunkte bedienen. Wenn ein als Amsterdam bezeichneter Block ausfällt, kümmert sich ein europäischer Kunde möglicherweise um Latenz und rechtlichen Standort. Wenn ein Block von Hongkong oder Singapur ausfällt, können Asien-Pazifik-Benutzer eine höhere Latenz oder ein Failover in eine andere Region erleben.

Wenn der Block von New York oder Los Angeles derzeit nicht geroutet wird, muss ein Kunde, der eine Bereitstellung in Nordamerika plant, wissen, ob dieser Standort aktiv, reserviert, pausiert oder ausstehend ist.

Die richtige Sorgfaltsfrage ist daher nicht "Erwähnt der Geofeed meine Stadt?", sondern "Welcher physische oder virtuelle Standort bedient meine stadtbezeichnete Adresse, wer betreibt diesen Standort, welche Upstreams tragen ihn, welche Strom- und Hardwareversorgung steckt dahinter, und wie wird er wiederhergestellt oder migriert?". Eine Stadtbezeichnung kann einem Kunden helfen, zu entscheiden, was er fragen soll. Sie sollte nicht als Beweis dafür verwendet werden, dass Zerospace in allen zehn Städten über eine eigene Infrastruktur verfügt.

Die Website und die DNS-Registrierung offenbaren eine separate Verfügbarkeitsabhängigkeit

Die Hauptwebsite muss ebenfalls von der Kundeninfrastruktur getrennt betrachtet werden. Der DNS-Chain-Endpunkt des RIPEstat unterhttps://stat.ripe.net/data/dns-chain/data.json?resource=zerospace.cloudzeigte, dass zerospace.cloud autoritative Nameserver von Cloudflare verwendet, ali.ns.cloudflare.com und rudy.ns.cloudflare.com, mit A-Einträgen 172.67.142.47 und 104.21.87.70 und AAAA-Einträgen 2606:4700:3035::ac43:8e2f und 2606:4700:3036::6815:5746 zum Zeitpunkt der Abfrage am 15. Juli 2026. Der DNS-Chain-Endpunkt fürhttps://stat.ripe.net/data/dns-chain/data.json?resource=download.zerospace.cloudzeigte dieselben Cloudflare-fronted Adressen für den Download-Host. Der Endpunkt fürhttps://stat.ripe.net/data/dns-chain/data.json?resource=www.zerospace.cloudgab die autoritativen Nameserver von Cloudflare zurück, aber keine Weiterleitungsdatensätze fürwww.zerospace.cloud.

Während einer direkten HTTPS-Überprüfung am 15. Juli 2026 gabhttps://zerospace.cloudinnerhalb eines 15-Sekunden-Curl-Timeouts dieser Umgebung keine nutzbare Seite zurück. Frühere Cloudflare-fronted Prüfungen können 522-Ursprungszugänglichkeitsfehler offenbaren, wenn der Ursprung nicht auf Cloudflare antwortet. Selbst ohne sich auf ein einzelnes vorübergehendes HTTP-Ergebnis zu verlassen, zeigt der DNS-Nachweis, dass der Pfad der öffentlichen Website durch Cloudflare vermittelt wird. Dies ist üblich und oft sinnvoll. Es bedeutet auch, dass die Website-Verfügbarkeit nicht dasselbe ist wie die Routenverfügbarkeit von AS201801.

Hier gibt es zwei getrennte Abhängigkeiten. Erstens hängt die Marketing- oder Steuerungs-Webpräsenz von Zerospace vom DNS und Proxy von Cloudflare sowie vom Ursprungsdienst ab, der hinter Cloudflare steht. Zweitens hängen die gerouteten Kundenpräfixe von Zerospace von AS201801, seinen Upstream-Nachbarn und den physischen oder virtuellen Standorten ab, die diese Präfixe tragen. Ein Käufer sollte nicht daraus schließen, dass, weil die Website hinter Cloudflare steht, der Kundenverkehr hinter Cloudflare steht.

Er sollte auch nicht daraus schließen, dass, weil AS201801 im BGP sichtbar ist, das Kundenportal, die Dokumentation, Statusmeldungen oder der Support-Pfad während eines Ausfalls des Website-Ursprungs erreichbar bleiben.

Der Download-Host ist interessant, weil er den Geofeed bediente, obwohl die Hauptwebsite während der Überprüfung keine lesbare öffentliche Dienstseite war. Dies deutet darauf hin, dass einige Cloudflare-fronted Pfade zugänglich sein können, während andere es nicht sind. Für den Kundenbetrieb stellt sich die Frage, ob kritische Portale, Support-Formulare, Steuerungspanels, Statusseiten, Geofeeds und API-Endpunkte unabhängig gehostet werden oder sich dieselbe Ursprungsabhängigkeit teilen.

Wenn der einzige Kunden-Support-Pfad ein Webformular hinter einem fragilen Ursprung ist, kann ein Netzwerk- oder Ursprungsausfall die Wiederherstellung verzögern, selbst wenn die BGP-Route aktiv bleibt.

Der Website-Nachweis reduziert auch die Menge an verfügbaren Dienstleistungsdetails von erster Hand für Außenstehende. Viele Anbieter veröffentlichen auf ihrer Website Einrichtungsseiten, Produktbedingungen, Service-Level-Ziele, Support-Verfahren, Datenexportbedingungen, Backup-Richtlinien und rechtliche Dokumente. Wenn die Hauptwebsite nicht zuverlässig lesbar ist, muss die öffentliche Due Diligence stärker auf Registrierungs- und Routing-Nachweise vertrauen. Dies reicht für einen Artikel über Netzidentität aus. Es reicht nicht für einen vertrauensvollen Kauf von gehosteter Kapazität aus.

Die physischen Abhängigkeiten sind größtenteils hinter der Netzwerkschicht verborgen

Die öffentliche Registrierung von Zerospace gibt uns Routenressourcen, aber kein vollständiges physisches Abbild. Es gibt keinen öffentlichen Einrichtungseintrag im PeeringDB für AS201801. Es gibt keine öffentliche Einrichtungsseite, die auf der Hauptwebsite bei dieser Überprüfung verfügbar ist. Es gibt keine veröffentlichte Liste von Gehäusen, keine Leistungsdichteerklärung, kein Kühlungsdesign, kein Remote-Arbeitskraftanbieter, keine Hardwarebestandsrichtlinie, keine Backup-Architektur, keine Statusseite und keinen Migrationsleitfaden in den hier verfügbaren Nachweisen. Dies bedeutet nicht, dass diese Dinge nicht existieren.

Es bedeutet, dass sie nicht öffentlich nachgewiesen sind.

Der physische Abhängigkeitsstapel für einen Kunden ist dennoch konkret. Wenn Zerospace gehostete Kapazität verkauft, muss sich ein Server oder eine virtuelle Instanz irgendwo befinden. Dieses Irgendwo hat ein Rack oder einen Host-Rechner, Stromversorgung, Kühlungspfad, Verwaltungsnetzwerk, Upstream-Port, Speicherabhängigkeit und Zugriffsverfahren. Wenn eine Festplatte ausfällt, muss jemand oder eine Automatisierung die Arbeitslast ersetzen oder verschieben. Wenn ein Router ausfällt, muss ein zweiter Pfad das Präfix tragen. Wenn ein Gehäuseleistungsschalter auslöst, muss es einen Plan für dieses Gehäuse geben.

Wenn eine Einrichtung ein Wartungsfenster hat, muss der Anbieter wissen, welche Kundendienste betroffen sind. Wenn eine stadtbezeichnete Adresse tatsächlich ein virtueller Endpunkt in einer größeren Cloud-Region ist, sollte der Kunde auch das wissen.

Strom und Kühlung sind die am wenigsten sichtbaren Teile der Zerospace-Registrierung. Ein /24 und ein /44 können von sehr wenig physischer Infrastruktur aus angekündigt werden, von gemieteten virtuellen Maschinen, Partner-Hosts oder einer kleinen Anzahl von Colocation-Servern. Die Anzahl der IP-Adressen sagt daher fast nichts über die Leistungsreserve aus. Kunden müssen die installierte Stromzuteilung, die nutzbare Leistung nach Redundanz, die Kühlungsdichte pro Rack, die USV- und Generatorannahmen der Einrichtung kennen und ob eine einzelne Hochdichte-Bereitstellung die lokale Reserve des Anbieters erschöpfen könnte.

Ohne diese Informationen kann ein Käufer einen Stadt-Edge-Knoten nicht von einer resilienten Hosting-Region unterscheiden.

Der Hardwarebestand ist ebenso undurchsichtig. Ein Anbieter kann Adressen global routen, aber immer noch von einem begrenzten Host-Pool abhängen. Wenn Zerospace VPS oder verwaltete Dienste anbietet, sollte der Käufer fragen, wie viele Produktions-Hosts hinter jedem Standort stehen, ob der Speicher lokal oder gemeinsam genutzt ist, wie Ausfälle evakuiert werden, ob es Ersatz-Knoten am selben Standort gibt und ob die Ersatzkapazität die Bestellung eines Drittanbieter-Hosts erfordert.

Die kleine IPv4-Zuteilung macht eine effiziente Adressnutzung wahrscheinlich; sie bedeutet auch, dass IP-Knappheit Migrations- und Expansionspläne beeinflussen kann.

Der Support ist nur auf der Ebene des Netzwerkkontakts sichtbar. Das RDAP nennt Netzwerkbetrieb und Missbrauchsfunktionen, was für den Routenbetrieb und die Missbrauchsbehandlung wichtig ist. Es zeigt keine Kundensupportzeiten, Eskalationsstufen, Reaktionsziele bei Vorfällen, bezahlte Support-Stufen, Sprachen, Ticketing-Tools oder Notfallbefugnisse. Ein Kunde, der Infrastrukturkapazität kauft, sollte die Existenz eines Netzwerkkontakts als Untergrenze betrachten, nicht als Support-Versprechen.

Die eigentliche Wiederherstellungsfrage ist, wer handeln kann, wenn eine Router-Sitzung ausfällt, ein Host ausfällt, ein Stadtendpunkt verschwindet oder ein Kunde Daten kurzfristig evakuieren muss.

Fehlerpfade: Route, Upstream, Einrichtung, Support und Migration

Der erste Fehlerpfad ist die Upstream-Erreichbarkeit. AS201801 hatte zwei beobachtete Nachbarn im RIPEstat, AS57758 und AS63473, und eine Whois-Richtlinienliste, die auch AS20473 nannte. Wenn AS57758 oder AS63473 eine Sitzung verlieren, hängt das Ergebnis davon ab, ob beide Nachbarn die betroffenen Präfixe tragen, ob das Traffic-Engineering für die Rückwege symmetrisch genug ist und ob der Ausfall auf einen Upstream isoliert ist. Wenn beide Sitzungen am selben Standort enden oder von derselben lokalen Übergabe abhängen, kann die Redundanz weniger nützlich sein als die AS-Anzahl vermuten lässt.

Kunden sollten ein Routendiagramm anfordern, das zeigt, welche Upstreams jedes Produktionspräfix tragen und wo diese Sitzungen lokalisiert sind.

Der zweite Fehlerpfad ist die Routenautorisierung oder -filterung. RPKI ist gültig für das IPv4 /24 und das IPv6-Muster /44 zu /48, was gut ist. Aber Kunden sollten dennoch fragen, ob Zerospace Routenlecks, ungültige Ankündigungen, Fehler bei der maximalen Länge und Geolokalisierungsabweichungen überwacht. Ein gültiger ROA kann operativ schmerzhaft werden, wenn ein Anbieter später eine spezifischere Route über die maximale Länge hinaus ankündigt, wenn ein Upstream unerwartet filtert oder wenn ein bestimmtes städtisches /48 ohne entsprechende Routenautorisierung hinzugefügt wird.

Der aktuelle RPKI-Status ist eine positive Kontrolle; er ist kein Ersatz für die Änderungskontrolle.

Der dritte Fehlerpfad ist der Verlust von Einrichtungen oder die versteckte Konzentration von Einrichtungen. Da PeeringDB null öffentliche Einrichtungszeilen listet, können Kunden nicht unabhängig feststellen, ob mehrere Städte mehrere Einrichtungen, eine Upstream-Überlagerung oder ein Wiederverkaufsvermögen darstellen. Wenn eine als Amsterdam bezeichnete Adresse und eine als London bezeichnete Adresse beide von einem einzigen Anbieterkonto, einer Abrechnungsbeziehung, einem Remote-Support-Team oder einem Tunnelkonzentrator abhängen, kann ein Ausfall dieser Anbieterbeziehung mehr als eine scheinbare Region betreffen.

Die Geofeed-Einträge für mehrere Städte sollten gegen unabhängige Nachweise für Einrichtung, Anbieter und Routing überprüft werden.

Der vierte Fehlerpfad ist die Steuerungsebene und der Support. Das Cloudflare-fronted DNS der Hauptdomäne, der leere www-Eintrag und die während der Überprüfung nicht verfügbare Hauptwebsite weisen auf die Bedeutung hin, zu wissen, wie Kunden während eines Ausfalls den Support erreichen. Wenn das Kundenportal, Statusmeldungen, Dokumentation und Support-Formulare einen fragilen Ursprung gemeinsam nutzen, kann der Anbieter die Kommunikation verlieren, während sich das Netzwerkproblem noch entfaltet. Die Wiederherstellung der Infrastruktur hängt sowohl von Kontaktwegen als auch von Paketen ab.

Käufer sollten einen Out-of-Band-Vorfallkontakt verlangen, nicht nur ein Webformular.

Der fünfte Fehlerpfad ist die Migration. Neue Netzwerke ändern sich. Die Registrierungsdaten von Zerospace aus dem Jahr 2026, die Änderungen der IPv6-Sichtbarkeit im Juli 2026 und das Stadt-Geofeed-Layout deuten auf eine Plattform hin, die noch erweitert oder angepasst wird. Dies kann vielversprechend sein, macht aber Ausstiegsrechte und Migrationspfade wesentlich.

Kunden müssen wissen, ob sie Datenträgerimages, Snapshots, Datenbank-Dumps, Protokolle und DNS-Einträge exportieren können; ob sie IPv4-Adressen während eines Wechsels behalten können; ob IPv6 /48-Zuweisungen innerhalb der Zerospace-Standorte portabel sind; wie lange der Datencxport dauert; und was passiert, wenn ein Standort stillgelegt oder umgeroutet wird.

Installierte Kapazität, nutzbare Kapazität und gekaufte Kapazität sind unterschiedliche Dinge

Der Zerospace-Nachweis ist ein nützliches Beispiel dafür, warum Cloud-Kapazität drei Schichten hat. Installierte Kapazität ist das, was der Anbieter plausibel besitzen oder kontrollieren kann: AS201801, 185.140.53.0/24, 2a07:1a84::/44, registrierte Routenrichtlinie und ein PeeringDB-Profil. Nutzbare Netzkapazität ist das, was im öffentlichen Routing erscheint und mit gültiger Ursprungsautorisierung erreicht werden kann: ein IPv4 /24, acht sichtbare IPv6 /48s im Überprüfungsfenster, zwei beobachtete Nachbarn und breite RIPE RIS-Sichtbarkeit.

Gekaufte Kapazität ist das, was ein Kunde tatsächlich vertraglich nutzen kann, mit Bedingungen für Rechenleistung, Speicher, Bandbreite, Support und Migration.

Die Distanz zwischen diesen Schichten ist der Ort, an dem sich das Risiko verbirgt. Ein Kunde kann zehn Geofeed-Städte sehen und zehn Produktionsregionen annehmen. Der Nachweis unterstützt diese Annahme nicht. Ein Kunde kann sechzehn IPv6-Präfixe im PeeringDB sehen und annehmen, dass alle sechzehn aktiv sind. RIPEstat zeigte während dieses Fensters acht sichtbare /48s, wobei einige im Whois aufgeführte /48s nicht im BGP vorhanden waren. Ein Kunde kann zwei beobachtete Upstream-Nachbarn sehen und Routenredundanz annehmen. Dies ist nur wahr, wenn die beiden Nachbarn für die Präfixe und die Fehlerdomäne des Kunden unabhängig sind.

Ein Kunde kann gültiges RPKI sehen und betriebliche Resilienz annehmen. RPKI hilft bei der Routenauthentizität, nicht bei der Serverreparatur.

Dies macht Zerospace nicht unbrauchbar. Es macht es zu einem Anbieter, der mit einem engen Nachweismodell gekauft werden sollte. Ein Entwickler, der einen kleinen gerouteten Dienst, ein IPv6-Labor, ein Edge-Experiment oder einen nicht kritischen gehosteten Endpunkt benötigt, mag den öffentlichen Fußabdruck als angemessen empfinden, solange die Geschäftsbedingungen dem Risiko entsprechen. Ein Unternehmen, das Produktions-Workloads, Kundendaten, zahlungsnahe Systeme, Gesundheitsdaten oder regulierte Aufzeichnungen verschiebt, sollte mehr als öffentliche Routing-Nachweise verlangen.

Es sollte Einrichtungsdetails, Support-Verpflichtungen, Backup-Trennung, Kundenausstiegsbedingungen und den Nachweis verlangen, dass die gekaufte Stadt oder Region tatsächlich aktiv ist.

Das Fehlen öffentlicher Einrichtungszeilen ändert auch die Art und Weise, wie man über Redundanznachweise denkt. Redundanz ist kein Zählen von Städtenamen. Es ist ein Nachweis, dass zwei Ausfälle nicht dieselbe Ursache haben. Für Zerospace müsste dieser Nachweis mindestens zeigen: Upstream-Unabhängigkeit, Einrichtungsunabhängigkeit, Stromunabhängigkeit, Speicher- oder Backup-Unabhängigkeit, Unabhängigkeit der Verwaltungsebene und Unabhängigkeit der Support-Eskalation. Wenn einer davon fehlt, kann eine zweite bezeichnete Region immer noch zusammen mit der ersten ausfallen.

Installierte Kapazität versus nutzbare Kapazität wirkt sich auch auf den Preis aus. Kleine Anbieter können attraktiv sein, weil sie flexibel, erschwinglich und technisch unkompliziert sind. Aber ein kostengünstiges Angebot kann die Ersatzteile, die Personalstunden, die Transitreserve oder die Backup-Aufbewahrung ausschließen, die große Cloud-Käufer als selbstverständlich ansehen. Kunden sollten die fehlenden Teile explizit bepreisen. Wenn eine Arbeitslast eine schnelle Wiederherstellung benötigt, sollte der Kunde diese Wiederherstellung bezahlen und testen.

Wenn eine Arbeitslast nur einen öffentlichen Endpunkt benötigt und woanders neu aufgebaut werden kann, kann der Kunde einen leichteren Dienst akzeptieren und seine eigene Portabilität aufrechterhalten.

Die Datenlokalität wird durch den Geofeed erklärt, aber die rechtliche und betriebliche Lokalität bleibt offen

Der Geofeed liefert ein Datenlokalitätssignal, ist aber kein Datenhoheitsvertrag. Er sagt Geolokalisierungskonsumenten, wie Zerospace möchte, dass Adressblöcke interpretiert werden. Er sagt nicht, wo die Festplatten sind, wo die Backups sind, welches Unternehmen den Host betreibt, wo das Support-Team sitzt, welches Gesetz für den Dienst gilt oder welche Subunternehmer auf Kundendaten zugreifen können. Diese Unterscheidung ist wesentlich für Kunden in Europa, Asien-Pazifik und Nordamerika, die Amsterdam, London, Hongkong, Tokio oder New York als Compliance- oder Latenzerklärung lesen könnten.

Für europäische Kunden sind der niederländische Organisationseintrag und der Ländercode Niederlande in den Adressdatensätzen nützlich, beweisen aber nicht, dass alle Kundendaten in den Niederlanden oder im Europäischen Wirtschaftsraum verbleiben. Der Geofeed selbst zeigt für mehrere Blöcke aus Europa heraus. Für Kunden im asiatisch-pazifischen Raum können die Bezeichnungen Seoul, Singapur, Hongkong, Tokio und Sydney für die Latenz nützlich sein, aber der Kunde muss dennoch wissen, ob die Daten lokal verarbeitet, durch ein anderes Land weitergeleitet, anderswo gesichert oder von einem Drittanbieter-Hosting betrieben werden.

Für US-Kunden erfordern die Bezeichnungen New York und Los Angeles dieselben Fragen.

Die sicherste Lesart ist, dass Zerospace Netzwerklokalität für Adressblöcke erklärt hat, keine Datenresidenzgarantien. Kunden sollten regionenspezifische Bedingungen verlangen, die den Hosting-Anbieter oder die Einrichtungsklasse nennen, definieren, wo Kundendaten und Backups ruhen, Support-Zugriffsstandorte identifizieren und beschreiben, wie Protokolle, Snapshots und Exporte behandelt werden. Wenn der Dienst nur eine Netzwerküberlagerung oder eine kleine Edge-Präsenz ist, sollte der Vertrag dies klar sagen. Wenn Zerospace über lokale physische Infrastruktur verfügt, sollte der Vertrag die betrieblichen Grenzen angeben.

Die Lokalität überschneidet sich auch mit der Fehlerbehebung. Wenn eine als Hongkong bezeichnete Adresse von einem Partner in Hongkong bedient wird, kann der Reparaturpfad von der Support-Warteschlange dieses Partners abhängen. Wenn sie von einem virtuellen Knoten eines globalen Cloud-Anbieters bedient wird, kann die Reparatur vom Konto dieses Anbieters und dem Regionsstatus abhängen. Wenn sie über einen Tunnel von einem anderen Standort aus bedient wird, kann die Geofeed-Bezeichnung für Anwendungen nützlich sein, aber nicht für die physische Unabhängigkeit. Keines dieser Modelle ist automatisch falsch. Was zählt, ist die Offenlegung.

Ein Kunde kann keine Resilienz um einen Stadtnamen herum entwerfen, wenn er nicht weiß, was der Stadtname tatsächlich bedeutet.

Wer ist betroffen, wenn der Dienst ausfällt

Die betroffenen Benutzer hängen davon ab, was Zerospace tatsächlich verkauft. Der öffentliche Nachweis unterstützt eine Netzidentität für Cloud oder Hosting, veröffentlicht aber kein Produktkatalog, der hier unabhängig gelesen werden kann. Dennoch sind die Abhängigkeitsklassen klar. Kunden, die Zerospace für gehostete Endpunkte, VPS-Instanzen, Edge-Knoten, VPN-Gateways, DNS-nahe Dienste, kleine Unternehmenswebsites oder Anwendungs-Backends nutzen, wären von einem Routenentzug, einem Upstream-Ausfall, einem Serverausfall, einem Speicherverlust, einer Support-Verzögerung oder einem Ausfall der Website-Steuerung betroffen.

Regionale Endbenutzer würden zuerst die Geofeed-Ebene bemerken. Wenn der für Amsterdam, London oder Stockholm bestimmte Verkehr zu einem weiter entfernten Standort umgeleitet wird, können latenzempfindliche Anwendungen beeinträchtigt werden. Wenn die Blöcke von Seoul, Singapur, Hongkong oder Tokio nicht verfügbar sind, können Asien-Pazifik-Benutzer längere Pfade oder einen Dienstausfall sehen. Wenn die Blöcke von New York oder Los Angeles nicht wie erwartet geroutet werden, erhalten nordamerikanische Benutzer möglicherweise nicht die in einem kommerziellen Design versprochene Lokalität.

Die Geofeed-Karte schafft daher Erwartungen, auch wenn sie keine Kapazität beweist.

Kunden wären auch von der Adressknappheit betroffen. Da nur ein IPv4 /24 sichtbar ist, sind IPv4-Zuweisungen eine begrenzte Ressource. Wenn ein Kunde mehr öffentliche IPv4-Adressen, eine schnelle Erweiterung oder eine saubere Migration zu einem anderen Anbieter benötigt, wird der begrenzte IPv4-Pool zu einer praktischen Einschränkung. IPv6 ist reichlich vorhanden, aber die IPv6-Einführung hängt immer noch von den Benutzern, Netzwerken und Anwendungen des Kunden ab. Ein Dienst, der gut über IPv6 funktioniert, benötigt möglicherweise dennoch IPv4 für Kunden, E-Mail, Legacy-Systeme oder Drittanbieter-Integrationen.

Der am stärksten gefährdete Kunde ist derjenige, der Zerospace als vollständige Cloud-Plattform behandelt, ohne die Wiederherstellung zu testen. Wenn der Dienst für nicht kritische Edge-Experimente verwendet wird, kann der Kunde woanders neu aufbauen. Wenn er primäre Datenbanken, kundenorientierte Produktionsdienste oder unersetzliche Backups enthält, benötigt der Kunde stärkere Nachweise. Die öffentliche Registrierung zeigt noch nicht genug, um AS201801 standardmäßig als ausgereifte Multi-Regionen-Plattform zu rechtfertigen.

Was den Evidenzgrad erhöhen würde

Zerospace könnte den Evidenzgrad schnell erhöhen, indem es eine datierte Infrastrukturerklärung veröffentlicht. Die nützlichste öffentliche Erklärung würde zwischen eigener Infrastruktur, gemietetem Colocation, virtualisierten Knoten und Partnerstandorten unterscheiden. Sie würde jede Stadt im Geofeed der Art der dortigen Bereitstellung zuordnen, benennen, ob Kunden-Computing an diesem Standort verfügbar ist, erklären, ob IPv4 und IPv6 beide produktiv sind, und erläutern, welche Upstreams jedes Präfix tragen. Sie müsste keine sensiblen Details preisgeben; sie müsste die Marketing-Geografie von der operativen Abhängigkeit trennen.

Die nächste Verbesserung wäre der Nachweis von Einrichtung und Support. Einrichtungszeilen im PeeringDB, eine öffentliche Statusseite, eine Kundensupport-Seite, Notfallkontakte außerhalb der Band, eine Backup- und Wiederherstellungsrichtlinie sowie ein Migrations- oder Datencxportleitfaden würden das Käufervertrauen wesentlich verbessern. Ein kleiner Anbieter kann glaubwürdig sein, ohne jeden Lieferantennamen zu veröffentlichen, aber er sollte zeigen, wie sich Kunden erholen, wenn ein Host, eine Route, eine Einrichtung oder ein Konto ausfällt. Die aktuelle öffentliche Registrierung ist stark auf Registrierungs- und BGP-Nachweise ausgerichtet.

RPKI sollte weiterhin eine Stärke bleiben. Zerospace hat bereits eine gültige Routenursprungsautorisierung für die überprüften IPv4- und IPv6-Routen. Zukünftige öffentliche Nachweise sollten diese Disziplin beibehalten, wenn neue /48s erscheinen. Wenn:7::/48 und:8::/48 aktive Stadtstandorte werden sollen, sollten Routensichtbarkeit und -validierung mit dem Geofeed übereinstimmen. Wenn einige Geofeed-Einträge reserviert oder geplant sind, sollte der Anbieter dies sagen, anstatt Kunden aus einer Adresslokalisierungsdatei auf Produktionsstandorte schließen zu lassen.

Der Evidenzgrad würde sinken, wenn AS201801 eine breite Routensichtbarkeit verlieren würde, wenn RPKI ungültig würde, wenn der Geofeed weiterhin Standorte ankündigt, die ohne Erklärung ungeroutet bleiben, wenn die Website ohne separaten Support-Pfad zeitweise unlesbar bliebe oder wenn Kunden keine Einrichtungs- und Wiederherstellungsdetails erhalten könnten. Er würde auch sinken, wenn der Anbieter Multi-Region-Resilienz verkauft, während er von einem einzigen Konto, einer einzigen Einrichtung, einer einzigen Support-Warteschlange oder einer einzigen Upstream-Fehlerdomäne abhängt.

Fazit für abhängige Betreiber

Zerospace Cloud hat genügend öffentliche Nachweise, um als echtes geroutetes Netzwerk behandelt zu werden, aber nicht genug, um als bewiesene globale Hosting-Plattform behandelt zu werden. Die RIPE-Registrierungen verbinden AS201801, 185.140.53.0/24 und 2a07:1a84::/44 mit Christian Wittenberg trading as Zerospace Cloud. RIPEstat zeigt das AS mit breiter IPv4- und IPv6-Sichtbarkeit angekündigt. RPKI ist gültig für die überprüften IPv4- und IPv6-Ursprünge. PeeringDB listet ein Zerospace Cloud-Netzobjekt auf. Der Geofeed ist detailliert und aktuell genug, um ernsthafte Fragen zum geografischen Design des Dienstes zu unterstützen.

Die Vorsicht ist ebenso klar. Das IPv4-Vermögen ist ein /24. Die IPv6-Sichtbarkeit deckt während des Überprüfungsfensters acht /48s ab, nicht alle /48s, die vom /44 und Profil impliziert werden. PeeringDB zeigt keine öffentlichen Einrichtungs- oder IX-Zeilen. Die Hauptwebsite war während der Überprüfung keine zuverlässige Quelle für Servicedetails. Der Geofeed bildet Städte ab, belegt aber keine Racks, Strom, Kühlung, Hardware, Support oder Migrationsfähigkeit in diesen Städten. Das aktuelle Upstream-Bild zeigt zwei beobachtete Nachbarn, aber die öffentlichen Routing-Daten beweisen keine unabhängigen Fehlerdomänen.

Ein praktischer Käufer sollte Zerospace daher nur mit expliziten Nachweisen für den genau gekauften Dienst nutzen. Fragen Sie, wo die Arbeitslast läuft, wer die Einrichtung oder den Host betreibt, welche Upstreams die Präfixe tragen, ob IPv4 und IPv6 beide am angeforderten Standort aktiv sind, wie Strom- und Hardwareausfälle behandelt werden, wie der Support während eines Website-Ausfalls erreicht wird, wie Backups getrennt sind und wie Daten exportiert werden können. Behandeln Sie den Geofeed als Karte der beanspruchten Adresslokalität, nicht als Karte garantierter Cloud-Regionen.

Für nicht kritische Arbeitslasten kann der öffentliche Nachweis ausreichen, um Tests zu rechtfertigen. Für Produktionsdienste ist der fehlende Nachweis zu wichtig, um ignoriert zu werden. Gehostete Kapazität löst sich immer in physische Abhängigkeiten auf. Im Fall von Zerospace kann das öffentliche Internet die Routen sehen; die Kunden benötigen immer noch Nachweise für die Racks, die Upstream-Unabhängigkeit, die Support-Befugnis und die Migrationspfade dahinter.