Zusammenfassung

  • Im RIPE-Register existiert kein Role-, Person- oder Mailbox-Objekt mit dem Namen 'novacloud-admin'; die nächstliegende Entsprechung ist der Maintainer novacloud-mnt, der kein administrativer Kontakt ist.
  • Die Accountability für AS209874 läuft objektgebunden: Rolle NA8939-RIPE ('novacloud-hosting'), Abuse-Rolle NA8940-RIPE ('novacloud-abuse') mit der registrierten Abuse-Mailbox und Organisation ORG-MWUL2-RIPE (Tech Tide Portugal Unipessoal LDA, Registernummer 517354420).
  • Die Kontaktkanäle sind auf zwei Domains verteilt — eine NOC-Adresse auf der Mikroseiten-Domain, eine Abuse-Mailbox und ein DSA-Legal-Contact auf der Marken-Domain, der Meldungen über Missbrauch ausdrücklich nicht verarbeitet.
  • RPKI-Hygiene ist sichtbar (ROAs für viele Präfixe), während 5.83.150.0/24 trotz vollständiger Dokumentation laut bgp.tools nicht in der globalen Routing-Tabelle erscheint.

Das Handle 'novacloud-admin' ist der sichtbare Name dieses Betreibers in Verzeichnissen und Suchergebnissen. Im RIPE-Register existiert er nicht. Was stattdessen existiert, ist eine Kette maschinenlesbarer Objekte: zwei Role-Objekte, eine Organisation mit Handelsregisternummer und drei Maintainer-Einträge. Dazu kommen drei getrennte Kontaktkanäle auf zwei Domains, von denen einer — der DSA-Legal-Contact nach Artikel 11 — ausdrücklich erklärt, keine Abuse-Meldungen zu bearbeiten.

Dieser Artikel zerlegt, was jede dieser Ebenen tatsächlich benennt, wo die drei Schichten auseinanderlaufen, und was das für einen Kunden oder ein nachgelagertes Netz bedeutet, das eine verantwortliche Partei erreichen will.

Das Register benennt Objekte, keine Person

Die RIPE-Einträge zu AS209874 wurden am 24. April 2025 erstellt, tragen den as-name TECHTIDE und verbinden die Autonome Systemnummer mit der Organisation ORG-MWUL2-RIPE — Tech Tide Portugal Unipessoal LDA, Registernummer 517354420, zuletzt geändert am 26. Februar 2026 [5]. Als admin-c und tech-c dient das Role-Objekt NA8939-RIPE mit dem Namen 'novacloud-hosting', erstellt am 13. September 2024; als abuse-c das Role-Objekt NA8940-RIPE ('novacloud-abuse') mit der registrierten Abuse-Mailbox [5]. Die Objekte werden von RIPE-NCC-END-MNT, SBL-MNT und novacloud-mnt verwaltet [5].

Das ist der zentrale Befund: Jede Accountability läuft durch Objekte mit Postfächern und einer Organisation mit Registernummer. Kein erfasstes Quellwerk nennt eine Einzelperson hinter dem Betreiber [6]. Das ist im RIPE-System nicht ungewöhnlich — Role-Objekte existieren genau dafür, dass Responsibility nicht an einen Namen gebunden ist, der Urlaub nimmt. Aber es verschiebt die Frage: Wer haftet, entscheidet sich nicht am Handle, sondern an der Objektkette.

'novacloud-admin' löst in nichts auf

Das Handle 'novacloud-admin' — die Quelle der Verzeichnis-Bezeichnung dieses Objekts — matcht in RIPE kein Role-, Person- oder Mailbox-Objekt [6]. Der nächstliegende Treffer ist der Maintainer novacloud-mnt, und ein Maintainer ist kein administrativer Kontakt: Er autorisiert Objektänderungen, er ist keine Ansprechperson [6]. Das Handle ist damit ein rein darstellerischer Name, der zu nichts auflöst.

Die Konsequenz ist praktisch, nicht theoretisch. Wer 'novacloud-admin' als Kontakt sucht — über Verzeichnisse, WHOIS-Ableitungen oder das Branding — findet keine erreichbare Partei. Wer dagegen die Registrierungsobjekte liest, findet sofort die abuse-Mailbox, die Organisation und die Role-Objekte [5]. Die Information existiert; sie liegt nur nicht dort, wo das Branding sie verspricht.

Drei Postfächer, zwei Domains, eine Weigerung

Der Betreiber unterhält drei getrennte Kontaktkanäle für dasselbe Autonome System [2]. Die ASN-Mikroseite as209874.net nennt ein Network Operations Center auf der Mikroseiten-Domain [2]. Das Impressum auf novacloud-hosting.com leitet Abuse-Meldungen und Urheberrechtsbeschwerden an die registrierte Abuse-Mailbox — dieselbe, die auch als abuse-c im Register steht [5]. Und dasselbe Impressum benennt den DSA-Artikel-11-Legal-Contact, der ausdrücklich erklärt, keine Abuse-Meldungen zu verarbeiten [4].

Die Trennung ist funktional lesbar: NOC für technischen Betrieb, Abuse für Missbrauch, Trusted-Contact für regulatorische Anfragen. Die Auffälligkeit liegt in der Domain-Verteilung — der NOC sitzt auf der Mikroseite-Domain as209874.net, Abuse und Legal auf der Marken-Domain novacloud-hosting.com — und in der expliziten Weigerung des Legal-Contacts. Ein Kunde, der eine Störung oder einen Missbrauchsfall bei 'NovaCloud' meldet, landet je nach Wahl des Kanals bei einem anderen Empfangspunkt; ob diese Postfächer tatsächlich überwacht werden, sagt keine der erfassten Quellen [7].

RPKI-Hygiene: was sich zeigen lässt

Der Gegenkontrast kommt aus dem Routing. Die rpki-client-Konsolenspiegel zeigen für AS209874 ROAs zu zahlreichen IPv4-/24-Präfixen — darunter 5.83.142.0/24, 5.83.150.0/24, 94.249.197.0/24 und 194.62.122.0/24 — sowie IPv6-Blöcke wie 2a09:54c3:a000::/40 mit maxlen 128 [1]. Hygiene ist also performbar und wird hier auch praktiziert.

Aber dieselben Spiegel zeigen auch, wo Verwaltung und Routing auseinanderfallen: 5.83.150.0/24 ist mit RIPE-inetnum, Geofeed und Route-Objekt vollständig dokumentiert, wird aber laut bgp.tools nicht im globalen Routing Table geführt [8]. Ein präfixgenaues Papier-Set, das die zwarte Löcher der DFZ nicht erreicht. Hygiene im Register und Sichtbarkeit im Routing sind zwei getrennte Qualitäten; dieses AS erfüllt die eine sichtbar besser als die andere.

Vier Upstream-Listen, die sich widersprechen

Wer wissen will, über welche Upstreams AS209874 erreicht wird, bekommt je nach Quelle verschiedene Antworten. Der eigene Mikroseiten-Eintrag nennt PletX AS62403, Tube-Hosting AS49581 und IP-Projects AS48314 [2]. bgp.tools listet SMARTNET AS203446, Tube-Hosting AS49581 und TELE90 AS215787 [0]. ipregistry wiederholt das Betreiber-Trio [12]. Und die Incident-Erzählung zum FFM2-Ausfall im Juli 2026 benennt AS203446, AS215787 und PletX [9].

Drei der vier Listen teilen jeweils nur einen Eintrag mit den anderen. Ob das Übergangsphasen, Filterkonfigurationen oder einfache Aktualitätsverzögerungen widerspiegelt, lässt sich aus den Point-in-time-Spiegeln nicht entscheiden [7]. Was sich aber sagen lässt: Auch die transit-story dieses AS ist kein einzelner Fakt, sondern eine Menge sich überlappender, teils widersprüchlicher Aussagen — und die des Betreibers selbst stimmt mit der Gesamtliste der unabhängigen Beobachter am wenigsten überein.

FFM2: 19 Tage, ein Schuldzuweisungs-Statement

Der eigene Status des Betreibers klassifiziert FFM2 als Major outage, laufend vom 20. Juli bis 8. August 2026 — 19 Tage —, aufgelöst am 8. August. Als Ursache nennt der Eintrag 'false filtering of PletX', also fälschliches Filtern des angeblichen Upstreams [10]. Betroffen waren VPS Hypervisor FFM2, NBG Datacenter und RYZEN-01/04-VHOST-DE Gen-3 [10].

Zwei Details verdienen Beachtung. Erstens ist der Zeitraum ungewöhnlich lang für einen 'Filtering'-Zwischenfall auf Transportebene. Zweitens existiert der Incident-Datensatz doppelt — auf zwei Instatus-Subdomains mit widersprüchlich nebeneinander stehenden Status [10]. Ein Betreiber, dessen eigene Verlaufsdaten sich an derselben Stelle widersprechen, untergräbt gerade die Signalqualität, die ein Status-Page bieten soll.

Das Impressum: Portugal,Consultoria, breite Markenfamilie

Das Impressum von novacloud-hosting.com benennt Tech Tide Portugal Unipessoal LDA in Quarteira, Portugal — Faro-Registernummer 517354420, USt PT517354420 — und erklärt seine Reichweite über eine bemerkenswert lange Domänenliste: novacloud-hosting.com/.de/.eu/.net, nc-h.cloud, nc-h.com, novanetwork.net, as209874.net, freeminehost.com und glowberry.gg [4]. Frühere BTW-Berichterstattung zeichnete dazu: Die portugiesische Registerbehörde klassifizierte die Firma unter einem Business-Consultancy-Code, und eine LEI wurde erst im Mai 2026 erstmals ausgestellt [6].

Das Muster ist konsistent: juristische Substanz existiert, ist aber dünn und jung — eine Ein-Personen-Gesellschaft in Portugal, die Cloud-, Gaming- und Hosting-Marken unter einem Dach sammelt, mit einer Registrierungsklassifizierung, die eher Beratung als Betrieb nahelegt.

Was das für einen Kunden bedeutet

Der praktische Wert dieser Zerlegung liegt in der Handlungsanleitung, die aus dem Befund folgt. Wer mit diesem Betreiber zu tun hat, erreicht eine verantwortliche Partei nicht über das Brand-Handle, sondern über drei Maschinen-lesbare Kanäle: die abuse-c-Mailbox aus dem Register, die impressumsgemäße Legal-Contact-Adresse für DSA-Anliegen und die NOC-Adresse der Mikroseite [5]. Welche davon in welchem Fall zuständig und erreichbar ist, zeigt sich erst im Versuch — die erfassten Quellen geben darüber keine Auskunft [7].

Der zweite praktische Punkt betrifft die Nutzbarkeit des Präfixraums. Ein Kunde, der auf 5.83.150.0/24 oder den /40-Block setzt, sollte prüfen, ob die Präfixe tatsächlich im globalen Routing erscheinen — das Papier im Register garantiert die Sichtbarkeit nicht [8]. Und die FFM2-Erfahrung zeigt, dass auch ein Multi-week-Ausfall bei diesem Betreiber dokumentiert wurde, allerdings mit einer doppelten, widersprüchlichen Status-Verlaufsseite [10].

Die eigentliche Lektion ist die allgemeine: Accountability in Routing-Systemen ist objektgebunden. Sie lebt in Role-Objekten, Organisationsnummern und Maintainer-Ketten — nicht in dem Namen, den ein Verzeichnis anzeigt. 'novacloud-admin' ist genau der Fall, in dem diese Lektion anschaulich wird, weil das Handle auffällig viel mehr verspricht, als es auflöst [6].

Offene Fragen

  • Wird die im Register hinterlegte abuse-Mailbox tatsächlich überwacht und wie schnell reagiert der abuse-c? Keine der erfassten Quellen liefert Antwortzeiten oder Bearbeitungsdaten [7].
  • Warum ist ein vollständig dokumentiertes Präfix wie 5.83.150.0/24 nicht im globalen Routing Table? Bgp.tools meldet das Fehlen; die Ursache ist unklar [8].
  • Welche der vier Upstream-Listen ist die operative Realität, und wie aktuell sind die Point-in-time-Spiegel? Das kann nur eine direkte Abfrage der RIPE-Datenbank oder ein zeitnahes Re-Mirror klären [7].
  • Wer steht hinter Tech Tide Portugal Unipessoal LDA? Kein erfasstes Quellwerk nennt eine natürliche Person [6].

Methodik und Einschränkungen

Alle Registry- und Routing-Fakten dieses Artikels beruhen auf Drittspiegeln von RIPE- und BGP-Daten — bgp.tools, ip.sb, rpki-client-Konsolenspiegel, IRR Explorer, canon.whisper.security —, deren Abfrageverzögerung unbekannt ist; die maßgebliche RIPE-Datenbank wurde in diesem Lauf nicht live abgefragt [7]. Status- und Impressum-Seiten sind Punkt-in-time-Aufnahmen [7]. Ersteinstellungen wie Datacenter-Größen oder DDoS-Mitigation sind Marketingaussagen und wurden nicht verifiziert [7]. Prior BTW reporting ist als Quellenkontext, nicht als Primärbeweis behandelt [6].

Sources