Zusammenfassung

  • Die Zuordnung einer Organisation zu einer Autonomen Systemnummer ist ein administrativer Befund. Sie beweist weder, dass ein bestimmtes Netz aktuell angekündigt wird, noch dass eine Domain über dieses Netz erreichbar ist.
  • Ein belastbarer Nachweis eines Cloud-Dienstes benötigt eine getrennte Kette aus Registrierung, DNS-Delegation, adressiertem Endpunkt, abdeckendem Präfix, beobachtetem BGP-Ursprung, TLS- und HTTP-Verhalten, Anwendungsschnittstelle und einem funktionierenden Kundenablauf.
  • Für almazcloud.network und AS210328 bleibt diese Kette in der vorliegenden Untersuchung unvollständig: Die relevanten Quellen wurden identifiziert, ihre aktuellen Inhalte aber nicht live abgerufen. Aussagen über heutige Routen, DNS-Einträge, Zertifikate, Web-Erreichbarkeit oder Kundenendpunkte sind daher nicht festgestellt.

Die zentrale Verwechslung: Besitz, Betrieb und Nutzung

Bei kleinen oder wenig dokumentierten Cloud-Anbietern werden drei Fragen leicht vermischt. Erstens: Wer ist administrativ mit einer Ressource verbunden? Zweitens: Welche technische Infrastruktur ist zu einem bestimmten Zeitpunkt öffentlich beobachtbar? Drittens: Können Kunden eine konkrete Leistung tatsächlich nutzen?

Die erste Frage kann ein Register beantworten. Für AS210328 sind dafür unter anderem der RIPE-RDAP-Eintrag und die RIPE-Database-Abfrage geeignete Quellen. Sie können die Existenz eines administrativen Datensatzes, Attribute und Zuständigkeiten dokumentieren. Das ist wichtig, aber es ist kein Beleg für laufenden Betrieb. Ein Registereintrag ist weder eine Messung des Internets noch ein Service-Level-Nachweis.

Die zweite Frage betrifft die unabhängige Beobachtung. Dafür müssen Route-Objekte, angekündigte Präfixe, Routing-Status, BGP-Zustand, Nachbarschaften und historische Änderungen getrennt betrachtet werden. Die verfügbaren RIPEstat-Endpunkte für Route-Objekte, AS-Übersicht, angekündigte Präfixe, Routing-Status, BGP-Zustand, ASN-Nachbarschaften, Routing-Historie und BGP-Updates bilden dafür eine sinnvolle Prüfarchitektur. Ergänzende Perspektiven liefern BGP.Tools, Hurricane Electric BGP Toolkit und PeeringDB.

Doch auch ein positives Routing-Signal beantwortet nur eine begrenzte Frage: Wurde ein Präfix von bestimmten Messpunkten einem Ursprung zugeordnet? Es sagt nicht automatisch, dass almazcloud.network auf diesem Präfix liegt, dass ein Webdienst antwortet oder dass Kunden dort Rechenleistung, Speicher oder APIs erhalten.

Die dritte Frage ist die anspruchsvollste. Ein Cloud-Dienst ist nicht allein durch eine ASN, eine Domain oder ein Zertifikat nachgewiesen. Er benötigt eine nutzbare Funktion: etwa ein Kundenportal, eine API, eine dokumentierte Bereitstellung, einen erreichbaren Dienst oder einen nachvollziehbaren Workflow. Ohne diesen letzten Schritt bleibt die Behauptung eines Cloud-Angebots eine nicht bestätigte Interpretation.

Die Beweiskette beginnt nicht beim Webserver

Die technische Prüfung sollte an der Domain beginnen, aber nicht beim ersten sichtbaren HTML-Dokument enden. Für almazcloud.network umfasst der Pfad mindestens acht Übergänge.

Der erste Übergang ist die administrative Identität. Eine Domain-Registrierungsabfrage über ICANN Lookup kann Registerinformationen und deren Grenzen zeigen. Sie beantwortet nicht zwingend, welcher Betreiber DNS hostet, welcher Betreiber Netze ankündigt oder wer eine Anwendung betreibt. Registrant, Registrar, DNS-Anbieter, Transitprovider und Cloud-Service-Betreiber können verschiedene Akteure sein.

Der zweite Übergang ist die Delegation. Ein A-Record kann eine IPv4-Adresse liefern, ein AAAA-Record eine IPv6-Adresse, und NS-Einträge verweisen auf autoritative Nameserver. Für diese getrennten Fragen sind die A-Abfrage, AAAA-Abfrage und NS-Abfrage relevant. MX-, TXT- und CAA-Einträge können zusätzliche Hinweise geben, etwa zu Mailrouting, Verifikationsdaten oder Zertifikatsausstellern; sie sind über die MX-Abfrage, TXT-Abfrage und CAA-Abfrage prüfbar.

Der dritte Übergang ist die DNS-Kette. Delegation muss von der Zone über Nameserver bis zu einer auflösbaren Adresse verfolgt werden. Der RIPE-DNS-Chain-Datensatz und die DNSViz-Ansicht können dabei unterschiedliche Eigenschaften sichtbar machen. Ein gültiger DNS-Pfad belegt jedoch nur Namensauflösung oder Delegationskonsistenz zu einem bestimmten Zeitpunkt. Er beweist weder eine funktionierende Anwendung noch einen Kundenbetrieb.

Der vierte Übergang ist die Adresse. Sobald eine Domain auf eine IP-Adresse zeigt, muss geprüft werden, wem der Adressraum zugeordnet ist, welches Präfix ihn abdeckt und welcher Ursprung im BGP sichtbar ist. Eine Domainadresse und eine ASN dürfen nicht ohne diese Zwischenschritte gleichgesetzt werden. Ein Hostinganbieter kann Adressen bereitstellen, ein Transitprovider kann Routen originieren, und ein Betreiber kann Dienste über Infrastruktur Dritter veröffentlichen.

Der fünfte Übergang ist die Erreichbarkeit. Der Abruf der öffentlichen Website wäre nur dann ein aktueller Webbefund, wenn eine Antwort mit Zeitpunkt, Status und Inhalt tatsächlich vorläge. In diesem Lauf wurde keine aktuelle HTTP-Antwort abgerufen. Deshalb ist Web-Erreichbarkeit nicht festgestellt.

Der sechste Übergang ist die kryptografische und protokollarische Kontinuität. Zertifikatstransparenz über crt.sh und Cert Spotter kann historische oder neu ausgestellte Zertifikate sichtbar machen. SSL Labs kann, sofern ein aktueller Test vorliegt, TLS-Eigenschaften bewerten. Ein Zertifikat beweist aber nicht, dass eine Anwendung aktiv ist oder Kunden bedient. Es belegt zunächst nur eine Beziehung zwischen einem Namen, einem Zertifikatsvorgang und einem Zeitpunkt.

Der siebte Übergang ist die historische Kontinuität. urlscan und die Internet-Archive-Abfrage können frühere Scans oder archivierte URLs liefern. Historische Präsenz ist nicht dasselbe wie aktueller Betrieb. Umgekehrt beweist das Fehlen eines historischen Artefakts nicht, dass ein Dienst nie existierte. Jede Aussage muss deshalb mit einem Datum, einer Quelle und der jeweiligen Messmethode verbunden werden.

Der achte Übergang ist die unabhängige Außenperspektive. Censys und Shodan können exponierte Hosts, Dienste oder historische Beobachtungen erfassen. Ihre Ergebnisse hängen von Scanabdeckung, Zeitpunkt, Suchparametern und Sichtbarkeit ab. Sie sind keine vollständige Inventarliste und kein Ersatz für einen nachweisbaren Kundenworkflow.

Was in dieser Untersuchung bekannt ist — und was nicht

Die Untersuchung hat einen Korpus von 30 öffentlichen Quellen für AS210328 und almazcloud.network zusammengestellt. Dieser Korpus deckt administrative Register, Routing- und BGP-Daten, Peering-Informationen, Domain-Registrierung, DNS-Typen, DNS-Ketten, DNSSEC, Website, Zertifikatstransparenz, TLS, Scanverzeichnisse, historische Archive, Censys und Shodan ab.

Das Vorhandensein eines Quellenkandidaten ist aber nicht dasselbe wie das Vorliegen einer beobachteten Tatsache. Die Quellen wurden in diesem Lauf nicht live abgerufen; es liegen keine aktuellen HTTP-, DNS- oder allgemeinen Webantworten vor. Entsprechend sind aktuelle Präfixe, aktuelle Routen, DNS-Präsenz, die Zuordnung von Domainadressen zu AS210328, Zertifikatsaktivität und Web-Erreichbarkeit unbekannt. Auch Cloud-Service-Endpunkte und ein funktionierender Kundenworkflow wurden nicht beobachtet.

Diese Einschränkung ist keine formale Fußnote, sondern verändert die Schlussfolgerung. Ohne abgerufene Antworten kann man nicht sagen, dass die Domain heute auf AS210328 zeigt. Man kann nicht sagen, dass AS210328 aktuell Präfixe ankündigt. Man kann nicht sagen, dass ein TLS-Zertifikat gegenwärtig eingesetzt wird. Man kann auch nicht sagen, dass hinter der Domain ein nutzbarer Cloud-Service steht.

Die angemessene Aussage lautet enger: Es existiert ein öffentlich definierter Prüfpfad, mit dem diese Fragen untersucht werden können; der operative Fußabdruck wurde in diesem Lauf jedoch nicht unabhängig festgestellt.

Warum Kontinuität mehr als einen positiven Snapshot verlangt

Ein einzelner positiver Messpunkt stützt eine Aussage über Präsenz zu einem Zeitpunkt. Er stützt nicht automatisch eine Aussage über Kontinuität. Für einen belastbaren Betriebsnachweis wären wiederholte Beobachtungen erforderlich: DNS-Antworten mit Zeitstempeln, erreichbare Adressen aus mehreren Netzen, BGP-Sichtbarkeit über mehrere Messpunkte, TLS- und HTTP-Verhalten, stabile Anwendungspfade und eine nachvollziehbare Kundenfunktion.

Auch negative Ergebnisse müssen präzise formuliert werden. Wenn ein Probeversuch keine Antwort erhält, beweist das nicht, dass der Dienst nicht existiert. Es beweist nur, dass dieser Probeversuch zu diesem Zeitpunkt kein Ergebnis geliefert hat. Wenn ein Archiv keinen Treffer enthält, beweist das nicht die historische Nichtexistenz. Wenn ein Scanner keinen offenen Dienst meldet, kann der Dienst gefiltert, gehostet, zeitweise deaktiviert oder außerhalb des Scanfensters gelegen haben.

Die methodische Konsequenz lautet: Jede Ebene erhält ihren eigenen Status. Administrative Identität, Routing, DNS, Endpoint, TLS, HTTP, Anwendung und Kundenworkflow dürfen nicht zu einem einzigen positiven oder negativen Urteil verschmolzen werden.

Die Abhängigkeiten hinter einem Cloud-Versprechen

Ein Cloud-Service ist eine Kette voneinander abhängiger Betreiber. Der Domaininhaber kann von einem Registrar abhängen. Die Domain kann auf Nameserver eines weiteren Anbieters delegieren. Diese Nameserver können auf Adressen eines Hosting- oder Transitproviders verweisen. Das BGP kann von einem Origin- oder Upstream-Netz abhängen. TLS kann über eine Zertifizierungsstelle und automatische Erneuerung laufen. Die Anwendung kann wiederum auf Rechenzentren, Datenbanken, Identitätsdiensten und Zahlungsprozessen beruhen.

Diese Abhängigkeiten erzeugen unterschiedliche Ausfallmodi. Eine Domain kann registriert sein, während DNS ausfällt. DNS kann funktionieren, während kein Webserver antwortet. Ein Webserver kann antworten, während die API oder das Kundenportal nicht funktioniert. Ein Kundenportal kann erreichbar sein, während Bereitstellung, Abrechnung oder Support nicht verfügbar sind.

Deshalb ist die Formulierung „Cloud-Anbieter“ eine Behauptung über eine Betriebsfähigkeit und nicht nur über eine technische Kennung. Sie benötigt mindestens ein beobachtbares Dienstmerkmal und eine plausible Verbindung zu einem Kundenprozess. Öffentliche Infrastrukturbeobachtung kann diese Hypothese stützen, aber sie ersetzt keinen Nachweis der Nutzung.

Was als Nächstes gemessen werden sollte

Eine erneute Prüfung sollte nicht nur dieselbe Domainabfrage wiederholen. Sie sollte einen zeitgestempelten Prüfplan aus mehreren vantage points verwenden.

Erstens sollten A-, AAAA-, NS-, MX-, TXT- und CAA-Antworten gespeichert und verglichen werden. Dabei sollten TTL-Werte, autoritative Nameserver, Antwortcodes und Änderungen dokumentiert werden. Zweitens sollte die DNS-Kette einschließlich DNSSEC-Status geprüft werden. Drittens sollte jede aufgelöste Adresse gegen RPKI-, WHOIS- beziehungsweise RDAP- und BGP-Daten abgeglichen werden.

Viertens sollten Routingdaten über mehrere Messpunkte und mehrere Zeitfenster verglichen werden. Ein einzelner Ursprung ist weniger aussagekräftig als ein wiederkehrendes Muster mit konsistentem Präfix, Upstream und zeitlicher Stabilität. Fünftens sollten TLS-Zertifikate, SAN-Einträge, Aussteller und Gültigkeitszeiträume mit tatsächlichen HTTPS-Antworten verbunden werden. Sechstens sollte die HTTP- und Anwendungsebene auf Redirects, Login- oder Registrierungsfunktionen, API-Endpunkte, Dokumentation und nachvollziehbare Kundenaktionen geprüft werden.

Erst danach lässt sich eine begrenzte Aussage über Betriebsfähigkeit formulieren. Selbst dann bleibt die Frage offen, wie viele Kunden den Dienst nutzen und welche Servicequalität sie erhalten. Öffentliche Messungen können Erreichbarkeit und technische Kontinuität zeigen, nicht automatisch Umsatz, Kapazität, Vertragsbestand oder tatsächliche Kundenzahl.

Schlussfolgerung

AS210328 und almazcloud.network sollten nicht anhand eines einzigen Signals bewertet werden. Ein Registereintrag kann administrative Identität zeigen. Eine Route kann unabhängige Netzsichtbarkeit zeigen. DNS kann Delegation und Auflösung zeigen. TLS kann eine Zertifikatsbeziehung zeigen. HTTP kann eine Antwort zeigen. Eine Anwendung kann eine Funktion zeigen. Nur die Verbindung dieser Ebenen kann die These eines betriebenen, kundenfähigen Cloud-Dienstes stützen.

Für den vorliegenden Lauf ist diese Verbindung nicht hergestellt. Die Quellen für ihre Prüfung sind identifiziert, aber aktuelle Antworten wurden nicht abgerufen. Der unabhängig beobachtbare operative Fußabdruck bleibt deshalb unbestimmt. Die faire nächste Frage lautet nicht, ob eine ASN automatisch ein Cloud-Angebot beweist, sondern welche wiederholbaren Beobachtungen die einzelnen Übergänge belegen würden.