Zusammenfassung

  • Domaindelegation, AS-Registrierung, Routing-Policy, beobachtete Präfixe und Peering-Daten beschreiben unterschiedliche Ebenen der Infrastruktur und dürfen nicht zu einem einzigen Kontrollnachweis zusammengezogen werden.
  • Die für diese Untersuchung verfügbaren aktuellen Snapshots konnten keine konkreten Werte zu Registrierung, Nameservern, SOA, AS209045, Präfixbeobachtungen oder PeeringDB-Profilen verifizieren. Das ist keine Aussage, dass die zugrunde liegenden Datensätze oder Routen nicht existieren.

Die relevante Frage ist nicht, ob ein Register existiert

Bei einem Cloud-Anbieter wirkt die technische Kontrollkette auf den ersten Blick einfach: Ein Unternehmen kontrolliert eine Domain, die Domain verweist auf autoritative Nameserver, ein autonomes System kündigt Netze an, und Peering- oder Transitbeziehungen machen diese Netze erreichbar. Für eine belastbare Aussage über Verfügbarkeit müssen diese Ebenen jedoch zeitlich und sachlich zusammenpassen.

Eine Domain ist zunächst eine Identitäts- und Delegationsebene. Ein Eintrag im Domain Name System kann zeigen, welche Nameserver für eine Zone vorgesehen sind oder welche Antwort ein Resolver zu einem bestimmten Zeitpunkt erhält. Daraus folgt noch nicht, wer den darauf liegenden Dienst betreibt, ob die Anwendung antwortet oder ob Nutzer aus unterschiedlichen Netzen denselben Pfad erhalten.

Ein autonomes System ist eine Registrierungsebene mit einer Nummer und administrativen Attributen. Ein AS-Objekt ist nicht selbst der Beweis, dass es aktuell BGP-Sitzungen unterhält, Präfixe weltweit ankündigt oder eine bestimmte Anwendung erreicht. Ebenso kann eine Routing-Policy erklären, wie ein Betreiber seine Netze zu behandeln beabsichtigt, ohne zu beweisen, dass diese Policy überall umgesetzt oder beobachtbar ist.

PeeringDB ergänzt diese Perspektive um selbst gemeldete Angaben zu Netzwerken, Einrichtungen, Austauschpunkten, Verkehr und Policies. Solche Angaben können für die Untersuchung von Interconnection-Plänen nützlich sein. Sie beweisen allein aber weder eine aktive BGP-Session noch die Weiterleitung eines bestimmten Präfixes oder die Erreichbarkeit einer Anwendung.

Was die Untersuchung tatsächlich verifizieren konnte

Die Untersuchung stützte sich auf sieben öffentliche Endpunkte und die zugehörigen aktuellen Abruf-Snapshots. Die verfügbaren Snapshots enthielten keine verifizierten aktuellen Antwortwerte. Deshalb werden im Folgenden keine positiven oder negativen Zustandsbehauptungen über Genesis Cloud, die Domain oder AS209045 daraus abgeleitet.

Der Verisign-RDAP-Endpunkt für genesiscloud.com konnte in dem verfügbaren Snapshot keine aktuellen Registrierungs-, Status-, Nameserver- oder Ereignisdaten verifizieren. Das bedeutet nicht, dass die Domain nicht registriert ist. Es bedeutet nur, dass dieser Abruf als Beleg für einen aktuellen konkreten Datensatz nicht ausreicht.

Der Google-Public-DNS-NS-Endpunkt für genesiscloud.com konnte keine autoritative Nameserverdelegation und keine belastbaren DNS-Antwortmetadaten verifizieren. Für eine technische Prüfung wäre eine konkrete, zeitgestempelte Antwort nötig, einschließlich der beobachteten Nameserver und des Kontexts der Abfrage.

Auch der Google-Public-DNS-SOA-Endpunkt lieferte in dem verfügbaren Snapshot keine verifizierten Angaben zu primärem Server, verantwortlicher Mailbox, Seriennummer, Timern, TTL oder Antwortmetadaten. Eine SOA-Antwort wäre für die Beurteilung der Zonenkontrolle relevant, würde aber auch dann allein keine Anwendungserreichbarkeit beweisen.

Auf der Routing- und Registerebene konnte der RIPE-RDAP-Endpunkt für AS209045 keine aktuellen verifizierten Angaben zu Registry-Identität, Status, Kontakten, Bemerkungen oder Ereignisdaten liefern. Der RIPE-Database-aut-num-Endpunkt verifizierte ebenfalls keine aktuellen Routing-Policy-Attribute, Maintainer-, Source- oder Änderungsmetadaten.

Der RIPEstat-Endpunkt für angekündigte Präfixe von AS209045 verifizierte keine aktuell beobachteten IPv4- oder IPv6-Präfixe, kein Beobachtungsfenster und keine API-Statusmetadaten. Eine solche Beobachtung wäre ohnehin an Zeitpunkt, Messperspektive und Datenquelle gebunden. Sie würde nicht automatisch globale Route-Propagation, Ende-zu-Ende-Erreichbarkeit oder Dienstverfügbarkeit beweisen.

Schließlich konnte der PeeringDB-Endpunkt für AS209045 keine aktuellen verifizierten Angaben zu selbst gemeldeter Netzwerkidentität, Traffic-Profil, Policy, Einrichtungen, Austauschpunkten, Sessions oder Aktualisierungszeitpunkt liefern. PeeringDB-Daten sind Teilnehmerangaben. Selbst ein vollständig ausgefülltes Profil wäre deshalb eine deklarierte Interconnection-Ebene und kein unabhängiger Nachweis aktiver Weiterleitung.

Die Evidenzkette statt der Registerliste

Eine belastbare Untersuchung müsste die Ebenen synchronisieren. Zuerst wäre zu klären, welche juristische oder organisatorische Identität die Domain beansprucht. Danach müsste die tatsächlich beobachtete DNS-Delegation mit den Nameservern, den autoritativen Antworten und gegebenenfalls den Zertifikats- oder Anwendungsendpunkten abgeglichen werden. Parallel dazu müssten AS-Registrierung, aut-num-Objekt, angekündigte Präfixe und Messpunkte zeitlich zusammenpassen.

Die Interconnection-Ebene verlangt eine weitere Trennung. Eine Organisation kann eine Präsenz in einem Internet Exchange oder eine Peering-Policy angeben, ohne dass für jedes Präfix, jeden Transitpfad und jeden Zeitpunkt eine aktive Sitzung nachgewiesen ist. Umgekehrt kann ein Präfix über Transit erreichbar sein, ohne dass PeeringDB die vollständige operative Realität abbildet.

Erst eine Anwendungskontrolle würde die letzte Ebene erreichen: eine reproduzierbare Anfrage an einen konkreten Dienst, aus mehreren Netzen und Regionen, mit dokumentiertem DNS-Ergebnis, TLS-Handshake, HTTP-Status, Latenz und gegebenenfalls einer fachlichen Antwort. Auch das wäre eine Beobachtung zu bestimmten Zeitpunkten, nicht der Beweis dauerhafter globaler Verfügbarkeit.

Warum negative Befunde vorsichtig formuliert werden müssen

Infrastrukturdaten sind zeitabhängig. Ein leerer, unvollständiger oder nicht zugänglicher Snapshot kann viele Ursachen haben: ein fehlgeschlagener Abruf, eine veränderte API-Antwort, ein nicht gespeicherter historischen Inhalt, ein anderer Datenstand oder eine fehlende Beobachtung an der gewählten Messstelle. Aus „nicht verifiziert“ darf deshalb nicht „existiert nicht“ werden.

Diese Grenze ist im Fall von Genesis Cloud besonders wichtig. Die verfügbaren Snapshots erlauben keine aktuelle Aussage darüber, ob die Domain registriert ist, welche Nameserver autoritativ sind, ob AS209045 Präfixe ankündigt, welche Peering-Beziehungen aktiv sind oder ob eine Anwendung erreichbar ist. Sie erlauben nur die Aussage, dass diese Werte in der vorliegenden Abrufrunde nicht belastbar verifiziert wurden.

Die zentrale Schlussfolgerung ist damit methodisch: Öffentliche Register liefern Bausteine für eine Kontrollprüfung. Sie sind aber keine einheitliche Kontrollprüfung. DNS, Registry, Routing, Interconnection und Anwendung müssen als getrennte Schichten mit eigener Beweisgrenze behandelt werden.

Konsequenz für Betreiber und Prüfer

Betreiber sollten für eine belastbare öffentliche Darstellung unterscheiden zwischen registrierter Identität, deklarierter Policy, gemeldeter Interconnection, beobachteter Route und gemessener Anwendung. Diese Begriffe sind nicht austauschbar. Eine Statusseite, eine Registry-Angabe oder ein Peering-Profil kann jeweils einen Teil der Geschichte erklären, aber nicht die komplette technische Kette ersetzen.

Prüfer sollten jede Aussage mit drei Fragen testen: Was wurde konkret beobachtet? Zu welchem Zeitpunkt und aus welcher Perspektive? Welche weitere Ebene bleibt ungetestet? Diese Fragen verhindern, dass eine scheinbar präzise ASN-, DNS- oder Peering-Angabe als Beweis für die gesamte Cloud-Erreichbarkeit interpretiert wird.

Für Genesis Cloud bleibt die öffentliche Schlussfolgerung daher begrenzt. Die Untersuchung konnte die vorgesehenen Beweisflächen identifizieren, aber aus den verfügbaren Snapshots keine aktuellen positiven oder negativen Zustände ableiten. Ob ein Dienst operativ kontrolliert, geroutet und erreichbar ist, müsste durch eine neue, synchronisierte Erhebung mit tatsächlichen Antwortwerten und Anwendungstests geprüft werden.