Das Netzwerk von Macrohosting ist sichtbar; die Serviceabsicherung ist noch nicht vollständig

Zusammenfassung

• Der Name Macrohosting lässt sich über LACNIC, CABASE und die Website des Anbieters mit Nicolas Lagunas Turczyn und einem argentinischen Hostingbetrieb verknüpfen. Die geprüften öffentlichen Seiten nennen weder einen gesonderten eingetragenen Rechtsträger als Vertragspartner noch eine Steuernummer; ein Käufer benötigt daher weiterhin die genaue Identität des Vertragspartners.
• Am 15. Juli 2026 war AS265694 als Ursprung einer IPv4-Zuweisung mit 1.024 Adressen in drei einander überlappenden Routenankündigungen sichtbar. Alle 326 einbezogenen IPv4-Kollektoren erfassten sie, und die beobachteten Routen waren RPKI-gültig; das ist ein aussagekräftiger Netzwerknachweis, aber kein Beleg für die Verfügbarkeit von Anwendungen, das Eigentum an Servern oder die Qualität von Backups.
• Ein Kunde kann über ein aktives Kundenportal Hosting, VPS, E-Mail, Domains und verwaltete Dienste auswählen. Allgemeine Sicherheitstexte, Beispieltexte für Kundenstimmen, eine leere öffentliche Wissensdatenbank und eine Statusseite, die zur Anmeldung führt, machen die öffentlich einsehbare Absicherungsebene jedoch schwächer als die Bestellebene.
• Die argentinische Registrierung, Kontaktstellen in Buenos Aires und die Präsenz am AR-IX belegen keinen Datenstandort. Die Beschaffung sollte für jeden Dienst einen Rechtsträger, eine Betriebsstätte, ein Ursprungsnetz, einen Backup-Standort, Supportzeiten, ein Wiederherstellungsziel und eine Abhilferegelung vertraglich festschreiben, bevor die Marke als Nachweis betrieblicher Absicherung gilt.

Der Name lässt sich über mehrere Einträge hinweg verknüpfen, aber noch nicht zu einem vollständigen Vertrag

DerBTW-Verzeichniseintragbeginnt mit einer ungewöhnlichen Identitätsangabe: dem vollständigen Namen einer Person, gefolgt von der Marke Macrohosting in Klammern. Diese Form ist nicht bloß eine Konvention des Verzeichnisses. DerLACNIC-Eintrag für AS265694führt Nicolas Lagunas Turczyn(MACROHOSTING) als Registranten, nennt Nicolas Lagunas Turczyn als administrativen und technischen Kontakt sowie als Kontakt für Missbrauchsmeldungen und verzeichnet die Zuweisung des autonomen Systems am 31. März 2017.

Außerhalb des Nummernregisters bestehen weitere nützliche Verknüpfungen. DieWebsite von Macrohostingveröffentlicht eine Kontaktadresse in Buenos Aires und eine Telefonnummer mit der Endung 3147-0978. Trotz unterschiedlicher Formatierung stimmt die Ziffernfolge im Kern mit derjenigen im LACNIC-Registrierungseintrag überein. CABASE, die argentinische Internetkammer,führt Lagunas Turczyn Nicolas (Macrohosting)unter ihren Mitgliedern in den Kategorien Hosting und Housing. Zusammengenommen stützen diese Einträge die begründete Schlussfolgerung, dass Person, Marke, Website und Netzwerkregistrierung zu derselben betrieblichen Präsenz gehören.

Die Grenzen dieser Belege sind ebenso wichtig. LACNIC hält die Verantwortung für Internetressourcen fest; es bestätigt weder ein eingetragenes Unternehmen noch einen wirtschaftlich Berechtigten, die finanzielle Lage oder die Befugnis, alle kommerziellen Zusagen auf der Website rechtsverbindlich abzugeben. Der Rechtshinweis der Website nennt den Namen Macrohosting, die Anschrift, die Telefonnummer und die Kontakt-E-Mail-Adresse; die geprüfte Seite nennt jedoch weder Rechtsform noch Steuerkennung oder Registrierungsnummer. Die Website nennt inzwischen eine Adresse an der Avenida de los Lagos, während der LACNIC-Eintrag die Avenida Gaona angibt.

Ein Adresswechsel, getrennte Geschäftsräume oder ein älterer Registereintrag könnten den Unterschied erklären. Die öffentlichen Belege erlauben keine Entscheidung zwischen diesen Erklärungen.

Damit ist die Marke nachvollziehbar, ohne dass der Vertrag bereits vollständig bestimmt wäre. Ein Geschäftskunde sollte darauf bestehen, dass Bestellformular und Rechnung den rechtlichen Namen, die Steuernummer, die Zustellanschrift und eine zur rechtsverbindlichen Vertretung des Lieferanten befugte Person ausweisen. Außerdem sollte angegeben werden, ob Nicolas Lagunas Turczyn als Privatperson, über ein Unternehmen oder im Namen einer anderen Entität den Vertrag schließt. Dieses Thema ist keine von der Zuverlässigkeit losgelöste Formalie.

Die Antwort bestimmt, wer Daten zurückgeben, Gutschriften erteilen, auf eine rechtliche Mitteilung reagieren und die Wiederherstellung nach einem schweren Vorfall finanzieren muss.

Ein bestellbarer Katalog belegt einen Dienst, aber nicht jedes Versprechen

Die Verkaufsseite von Macrohosting ist knapp gehalten. Sie bietet Hosting auf gemeinsam genutzter Infrastruktur mit 20 GB Speicher, cPanel, Imunify360 und inbegriffenem SSL sowie zwei größere Hostingkonfigurationen, die mit virtuellen Kernen, Arbeitsspeicher, Speicherplatz, CloudLinux und DirectAdmin beschrieben werden. Die Bestellschaltflächen führen in ein separatesPortal zur Kundenverwaltung, das Kategorien für Webhosting, VPS, Unternehmens-E-Mail, verwaltete Dienste, Domains, Website-Sicherheit und Support bereitstellt. Kunden können zwischen US-Dollar und argentinischen Pesos wählen, ein Konto anlegen, eine Bestellung aufgeben und einen Ticket-basierten Supportbereich aufrufen.

Das ist eine klar erkennbare Automatisierungsebene. Für ein kleines Unternehmen, das Webhosting kauft, kann sie vor Dienstbeginn mehrere manuelle Abstimmungen erübrigen. Sie schafft außerdem eine Aufzeichnung des gewählten Tarifs und einen Kanal für spätere Anfragen. Der Katalog ist daher ein stärkerer Beleg als eine statische Seite, die lediglich behauptet, Cloud-Dienste seien verfügbar.

Die Automatisierung klärt jedoch nicht, was nach dem Kaufabschluss geschieht. Die geprüften öffentlichen Seiten nennen keine Frist für die Bereitstellung, keine Regelung zur Ressourcenkonkurrenz, kein Wartungsfenster, keinen Backup-Zeitplan, kein Wiederherstellungsziel und kein numerisch bestimmtes Reaktionsziel des Supports. Die Zahl virtueller Kerne beschreibt die Paketierung eines Tarifs, nicht die Zuteilung von CPU-Zeit unter Last. Inbegriffenes SSL sagt wenig darüber aus, wie Fehler bei der Verlängerung behandelt werden.

Die Namen von Sicherheitsprodukten benennen Komponenten, belegen aber weder Konfiguration, Überwachung, Patch-Verantwortung noch Entschädigung nach einem Vorfall.

Das Portal liefert außerdem Gründe zur Vorsicht. Auf seiner Startseite heißt es, mehr als 35.000 Kunden vertrauten dem Dienst; außerdem wird eine Verfügbarkeitsgarantie von 100 Prozent angezeigt. Um diese Aussagen herum finden sich allgemeine SiteLock-Beschreibungen, Beispielnamen und wiederholte Lorem-ipsum-Texte für Kundenstimmen. Der öffentliche Bereich für Ankündigungen zeigt die Standardmeldung, die Nutzern für die Wahl von WHMCS dankt. Diese Elemente wirken wie noch nicht fertig angepasste Inhalte einer Anbietervorlage und nicht wie unternehmensspezifische Belege.

Sie belegen nicht, dass der Dienst schlecht ist; sie bedeuten, dass die betroffenen Aussagen nicht verantwortungsvoll als Beleg für seine Qualität verwendet werden können.

Diese Unterscheidung ist bei der Beschaffung von Unternehmenssoftware wichtig. Ein funktionierendes Abrechnungs- und Kontosystem belegt, dass Transaktionen automatisiert werden können. Es belegt nicht, dass die betrieblichen Richtlinien hinter den Schaltflächen vollständig sind.

Käufer sollten eine Leistungsbeschreibung verlangen, die jedes sichtbare Merkmal in eine prüfbare Verpflichtung überführt: wann die Ressource verfügbar wird, welche Grenze gilt, wie die Nutzung gemessen wird, welche Protokolle exportiert werden können, welche Änderungshistorie aufbewahrt wird und wie eine fehlgeschlagene automatisierte Aktion einen menschlichen Betreiber erreicht.

AS265694 liefert den stärksten Betriebsnachweis

Der Netzwerkregistereintrag ist konkreter als die Gewährleistungsformulierungen. LACNIC wies170.78.136.0/22am 28. September 2016 direkt Nicolas Lagunas Turczyn(MACROHOSTING) zu. Der Block reicht von 170.78.136.0 bis 170.78.139.255 und umfasst insgesamt 1.024 IPv4-Adressen. Dieselbe namentlich genannte Person ist als administrativer und technischer Kontakt sowie als Kontakt für Missbrauchsmeldungen verantwortlich aufgeführt.

Bis zum 15. Juli 2026 zeigte dieRouting-Ansicht von RIPEstat, dass AS265694 diesen Adressraum aktiv als Ursprung ankündigte. Das System war für alle 326 in der Antwort enthaltenen IPv4-Peers sichtbar. RIPEstat zählte drei IPv4-Ankündigungen, keine IPv6-Ankündigung und zwei beobachtete Nachbarn. Die Historie des aktuellen Ursprungs reichte bis zum 1. Juli 2017 zurück.

Die drei Routen müssen sorgfältig gelesen werden. Der Betreiber kündigte sowohl den überdeckenden Block 170.78.136.0/22 als auch die beiden spezifischeren Hälften 170.78.136.0/23 und 170.78.138.0/23 an. Diese Routen überlappen sich; sie ergeben nicht 2.048 verschiedene Adressen. Der zugewiesene und angekündigte Adressraum umfasst weiterhin 1.024 IPv4-Adressen. DiePräfixhistorie von RIPEstatzeigte, dass alle drei während des Beobachtungsfensters vom 1. bis 15. Juli 2026 durchgehend vorhanden waren. Die Validierung des Routenursprungs ergab für den überdeckenden Block und beide /23-Präfixe jeweils den Status gültig; zugrunde lag eine Routenautorisierung, die Präfixlängen bis /24 erlaubte.

Das sind wertvolle Belege. Das Netzwerk wird nicht nur durch eine inaktive Registrierung dargestellt. Seine Präfixe wurden weithin verbreitet, und eine Kontrolle zur Ursprungsautorisierung war vorhanden. Ein Kunde kann die ASN und die Routen unabhängig von der Marketingseite des Anbieters überwachen. Für Missbrauchsmeldungen besteht außerdem ein namentlich benannter Kontaktweg im maßgeblichen Registereintrag.

Die Belege haben dennoch eine Grenze. Eine sichtbare Route verrät nicht, ob eine bestimmte Website, ein Postfach oder ein VPS diese Adressen nutzt. Sie misst weder Paketverlust, Latenz, Kapazitätsreserve und Serververfügbarkeit noch die Reaktion auf Vorfälle. Die RPKI-Validierung autorisiert den Ursprung; sie authentifiziert nicht jeden Pfad und schützt eine Anwendung nicht vor Ausfällen.

Das Fehlen einer beobachteten IPv6-Ankündigung ist für einen Käufer mit Bedarf an nativem IPv6 relevant, sollte aber am bestellten Produkt bestätigt und nicht zu einer Aussage über jedes private Netz oder Partnernetz ausgeweitet werden, das der Anbieter möglicherweise nutzt.

Die Präsenz am AR-IX liefert einen Hinweis auf lokale Zusammenschaltung

Macrohosting unterhält außerdem ein öffentlichesNetzwerkprofil bei PeeringDB. Der Eintrag beschreibt AS265694 als Unternehmensnetz mit südamerikanischer Reichweite, überwiegend ausgehendem Verkehr und offener Peering-Richtlinie. Er wurde im März 2026 aktualisiert. Sein Eintrag zum Internetknoten nennt einen betriebsbereiten IPv4-Port bei AR-IX CABASE mit 10 Gbps sowie die Teilnahme am Route-Server.

Diese Präsenz am Internetknoten hilft, die lokale Rolle des Netzwerks zu erklären. Eine Verbindung am AR-IX kann einen direkten Pfad zu anderen Teilnehmern bieten, statt jedes Paket über Upstream-Transit zu senden. Zusammen mit der CABASE-Mitgliedschaft und den aktiven Routen ist sie ein überzeugendes Zeichen dafür, dass Macrohosting am argentinischen Internetökosystem teilnimmt und nicht lediglich einen ausländischen Webshop unter einem lokalen Namen weiterverkauft.

Die Angaben bei PeeringDB sind allerdings vom Betreiber und vom Internetknoten gepflegte Verzeichnisdaten und keine Verkehrsprüfung. Ein Port mit 10 Gbps bedeutet weder, dass jeder Kunde 10 Gbps erhält, noch dass der Port zu Spitzenzeiten frei von Überlastung ist oder alle Ziele über ihn erreicht werden. Auch zwei beobachtete Routing-Nachbarn belegen weder physisch getrennte Glasfaserwege noch getrennte Gebäude oder unabhängige Stromversorgung. Die Beschaffungsfrage lautet nicht nur, ob mehr als eine benannte Verbindung besteht.

Entscheidend ist, ob der bestellte Dienst Pfade besitzt, deren Fehlermodi hinreichend unabhängig und überwacht sind und durch eine Eskalationsvereinbarung abgedeckt werden.

Eine nützliche Netzwerk-Leistungsanlage würde das Dienstpräfix und die Ursprungs-ASN, den Kundenport oder die Traffic-Shaping-Grenze, die IPv6-Verfügbarkeit, primäre und alternative Upstreams, Abhängigkeiten von Internetknoten, die DDoS-Behandlung und die zur Messung der Verfügbarkeit verwendeten Nachweise benennen. Sie sollte außerdem festlegen, wer CABASE, einen Upstream oder den Betreiber einer Einrichtung kontaktiert, wenn die Störung außerhalb der eigenen Ausrüstung von Macrohosting liegt. Öffentliche Ressourcenregister identifizieren das Netzwerk. Die Anlage würde den Dienst identifizieren, den der Kunde tatsächlich daraus bezieht.

Argentinische Netzwerkbelege klären den Datenstandort nicht

Fast jeder öffentliche Identitätshinweis weist nach Argentinien: die Länderangabe bei LACNIC, die Kontakte in Buenos Aires, die CABASE-Mitgliedschaft, der südamerikanische Geltungsbereich im PeeringDB-Profil und die Verbindung zum AR-IX. Dennoch wäre es riskant, daraus abzuleiten, dass alle Kundendaten in Argentinien verbleiben.

Die geprüften öffentlichen Seiten nennen weder ein Rechenzentrum noch dessen Betreiber, eine Serverstadt, einen Backup-Standort oder einen Unterauftragsverarbeiter für Cloud-Dienste. Sie sagen nicht, ob gemeinsam genutztes Hosting, VPS, E-Mail und verwaltete Dienste dieselbe Infrastruktur nutzen. Eine Präsenz am Internetknoten beschreibt, wo sich Netzwerke zusammenschalten; sie lokalisiert keine Festplatte. Eine lokal angekündigte IP-Adresse kann einen Workload an einem Ort bedienen, während Kontodaten, Ticket-Anhänge, DNS, Sicherheitstelemetrie oder Backups andernorts verarbeitet werden.

Die inhaltsarme Datenschutzseite verschärft das Problem. Sie bietet keine öffentliche Erklärung zu Datenkategorien, Auftragsverarbeitern, Aufbewahrung, internationalen Übermittlungen oder Löschung. Für eine Privatperson, die eine Website mit geringem Risiko erwirbt, kann das ein Grund für eine kurze Nachfrage sein. Für ein Unternehmen, das Beschäftigten-, Kunden- oder regulierte Daten verarbeitet, fehlt damit ein Teil der Leistungsbeschreibung.

Der Standort sollte daher nach Datenkategorie abgebildet werden. Der Kunde benötigt den primären und den Wiederherstellungsstandort für gehostete Dateien, Datenbanken, Postfächer, Snapshots und Backups. Außerdem benötigt er Standorte und Aufbewahrungsregeln für Identitätsdaten des Kontos, Rechnungen, Supportnachrichten, Zugriffsprotokolle, Überwachung und Malware-Befunde. Wenn ein externer Sicherheits-, Verwaltungsoberflächen-, DNS- oder Zahlungsdienst Daten erhält, sollte seine Rolle benannt werden.

Erst dann lassen sich ein argentinischer Anbieter und ein argentinisches Netzwerk zu einer evidenzbasierten Aussage über den Datenstandort verbinden.

Support besteht als Kanal; Verantwortlichkeit benötigt Leistungsbedingungen

Macrohosting bietet mehrere Möglichkeiten zur Kontaktaufnahme. Die Hauptwebsite enthält ein Kontaktformular und eine Telefonnummer. Das Portal bietet ein öffentliches Kontaktformular, Registrierung und Anmeldung sowie Menüeinträge für Tickets, Ankündigungen, eine Wissensdatenbank und den Netzwerkstatus. Diese Elemente zeigen, dass Kundensupport als Teil des vorgesehenen Dienstes gedacht ist und nicht als vollständig fehlender Nachtrag.

Sie zeigen jedoch nicht den personellen Einsatz hinter der Benutzeroberfläche. Die Wissensdatenbank enthielt während der Prüfung keine öffentlichen Artikel. Die Route zum Netzwerkstatus führte zu einer Kundenanmeldung statt zu einem öffentlichen Komponentenverlauf. Die geprüften Seiten nannten keine Supportzeiten, Schweregrade, Bestätigungsfristen, Wiederherstellungsziele, Eskalationskontakte oder Abhilfen bei Ausfällen. Eine Ticket-Schaltfläche kann Anfragen ordnen, garantiert aber allein nicht, dass die richtige Fachkraft reagiert, bevor das Wiederherstellungsfenster des Kunden abläuft.

Hier kann ein kleinerer Anbieter gegenüber einer Hyperscaler-Alternative Wert schaffen oder verlieren. Ein lokaler Betreiber kann direkte Kommunikation, lokalen Kontext und Zugang zu einer Person bieten, die sowohl den Server als auch das Netzwerk versteht. Diese Vorteile sind nur dann operativ, wenn Personal, Zeiten und Befugnisse tatsächlich vorhanden sind. Der Kunde sollte wissen, wer die Plattform außerhalb der Geschäftszeiten überwacht, wer eine Route ändern, ein Backup wiederherstellen und Notfallzugang genehmigen kann und wer kommuniziert, wenn eine Abhängigkeit ausfällt.

Die Verantwortung für Backups verdient eine eigene Regelung. Kein geprüftes öffentliches Dokument belegt, dass jeder Tarif Backups umfasst, wie häufig Kopien erstellt werden, wie lange sie aufbewahrt werden oder ob die Wiederherstellung getestet wird. Speicherkapazität in einem Tarif ist kein Wiederherstellungsversprechen. Ein Käufer sollte davon ausgehen, dass die Verantwortung ungeklärt bleibt, bis eine Bestellung Wiederherstellungspunkt, Wiederherstellungszeit, Speicherort der Kopien, Verschlüsselungsregelung, Aufbewahrungsdauer und Turnus der Wiederherstellungstests festlegt.

Die öffentliche Präsenz in ein Absicherungspaket überführen

Macrohosting besitzt mehr betriebliche Substanz, als die karge Verkaufsseite zunächst vermuten lässt. Person und Marke tauchen wiederholt in maßgeblichen Ressourcenregistern auf. Der IPv4-Block ist direkt zugewiesen. Das autonome System verfügt über einen langjährig bestehenden, weltweit sichtbaren Routenursprung, eine gültige Ursprungsautorisierung, zwei beobachtete Nachbarn und einen betriebsbereiten AR-IX-Eintrag. Das sind nützliche und unabhängig überprüfbare Tatsachen.

Der nächste Schritt besteht nicht darin, eine umfangreichere Website zu verlangen. Die kommerziellen Unterlagen müssen ebenso präzise werden wie der Netzwerkregistereintrag. Vor dem Einsatz einer Produktiv-Workload sollte ein Käufer ein Dokument erhalten, das den Rechtsträger als Vertragspartner benennt und den gewählten Tarif mit Betriebsstätte, Adressbereich, Ursprungs-ASN, Upstream-Modell und Ressourcenlimits des Kunden verknüpft. Es sollte Wartung, Überwachung, Schweregrade von Vorfällen, Supportabdeckung, Eskalation, Wiederherstellung, Gutschriften und Unterstützung bei Vertragsbeendigung definieren.

Eine zweite Anlage sollte Daten und Wiederherstellung abbilden. Sie sollte die Speicherorte von Primärdaten, Backups, Kontodatensätzen, Tickets und Sicherheitstelemetrie nennen, Unterauftragsverarbeiter identifizieren, Aufbewahrungs- und Löschregeln festlegen und einen getesteten Export- und Wiederherstellungspfad dokumentieren. Eine dritte sollte die menschliche Arbeit zuweisen: wer das Betriebssystem patcht, Zertifikate verlängert, Ressourcenerschöpfung überwacht, auf Malware-Warnungen reagiert, Routen ändert und externe Anbieter kontaktiert.

Dieses Paket würde den Wert der öffentlichen Netzwerkbelege von Macrohosting nicht ersetzen. Es würde den Belegen ermöglichen, ihre eigentliche Funktion zu erfüllen. AS265694 belegt eine sichtbare betriebliche Rolle im Internet. Der Katalog belegt, dass Dienste bestellt werden können. Die Kontaktmöglichkeiten belegen, dass Anfragen eingereicht werden können. Betriebliche Absicherung beginnt, wenn diese Tatsachen mit durchsetzbaren, produktspezifischen Antworten zu Identität, Kontrolle, Standort, Wiederherstellung und menschlicher Reaktion verknüpft werden.