Zusammenfassung
- Hosting-27 Hosting-27 LTD ist kein Unternehmen, das nur in Routing-Aufzeichnungen sichtbar ist. Die Live-StartseiteHosting27.combewirbt bulgarische Hosting- und Cloud-Dienste, dieKontaktseitegibt eine Adresse in Sofia, Telefon und Support-E-Mail-Adressen, derKundenbereichzeigt ein Login- und Abrechnungsportal, und dieSupport-Ticket-Seitebeschreibt einen täglich arbeitenden Support-Dienst. Diese öffentliche Verkaufsoberfläche ist real, beweist aber nicht selbst, wo sich die Server befinden oder wie Störungen behoben werden.
- Die Netzwerkidentität ist konkret und kompakt. Die RIPE-DatenbankAS42347-Objektnennt Hosting-27, verbindet die AS mitORG-HA629-RIPE, listet Hosting-27 LTD als Organisation, gibt Land BG, Registernummer 204354361 und eine Adresse in Sofia, und registriert Imports und Exports mit AS57344 und AS31083. Dasinetnum 217.174.144.0 - 217.174.144.255und dasroute-Objekt 217.174.144.0/24verbinden den sichtbaren IPv4-Block mit Hosting-27 und AS42347.
- Die Live-Routing-Ansicht ist enger als das Marketing-Menü. DieAS-Übersichtvon RIPEstat zeigte AS42347 am 12. Juli 2026 angekündigt, und ihreRouting-Status-Ansicht zeigte ein sichtbares IPv4-Präfix, 256 IPv4-Adressen, kein sichtbares IPv6 und einen beobachteten Nachbarn. DieASN-Nachbarn-Ansicht von RIPEstat identifizierte diesen Nachbarn als AS57344, und dieAS57344-Übersichtvon RIPEstat identifiziert AS57344 als Telehouse EAD. Ein zweiter Peer, AS31083 Telepoint, erscheint in der Registerpolitik von AS42347, aber nicht in der aktuellen BGP-Konsistenzansicht.
- Die operative Ebene ist mittelmäßig, nicht stark. Die Produktseiten fürShared Hosting,Cloud VPS,Managed Cloud VPS,Private CloudundKuberneteszeigen ein breites Angebot an gehosteter Kapazität. Die öffentlichen Beweise zeigen keinen benannten Rechenzentrumsraum, keine Anzahl von Racks, kein elektrisches Design, keine Hardware-Lagerung, keine Bedingungen für die Aufbewahrung von Kunden-Backups, keinen doppelten aktiven Transit, keinen IPv6-Dienst oder einen portablen Ausstiegspfad.
Die Dienstoberfläche ist sichtbar, muss aber vom Rack nach außen gelesen werden
Hosting-27 Hosting-27 LTD sollte nicht mit einer leeren Internetnummernregistrierung verwechselt werden. Die öffentliche Website Hosting27.com ist live, datiert durch ihre eigenen Header-Metadaten und sichtbaren Seiten, und als operative Hosting-Vitrine aufgebaut. DieStartseitepräsentiert die Marke als Anbieter von Hosting- und Cloud-Diensten. Sie leitet Käufer zu WordPress-Hosting, Kubernetes-Clustern, Private Cloud, Cloud VPS, Managed Cloud VPS, Reseller-Hosting, Domains, einem Kundenbereich, Rechnungen und Support-Tickets. Die Navigation ist kein einseitiger verlassener Platzhalter; es ist eine Hosting-Verkaufsoberfläche mit Produktstufen, Bestellschaltflächen, einem WHMCS-artigen Kontobereich und einem Support-Portal.
Das macht die Untersuchung anspruchsvoller, nicht weniger. Wenn ein Unternehmen Webhosting oder Cloud-Server verkauft, ist die Abhängigkeit des Kunden nicht die Webseite. Die Abhängigkeit ist der unter der Rechnung verborgene Stapel: ein Host-Knoten, ein Speicher-Backend, Switches, Router, ein IPv4-Pool, Upstream-Transit, Strom, Kühlung, entfernte Hände, Abrechnungsstatus, Missbrauchsbehandlung und ein Support-Team mit Handlungsbefugnis. Das öffentliche Material von Hosting27 beschreibt mehrere kundenorientierte Produkte, identifiziert aber nicht die Einrichtung oder Einrichtungen dahinter.
Es sagt nicht, ob Hosting-27 eigene Racks betreibt, Rack-Platz mietet, von einem anderen bulgarischen Rechenzentrumsbetreiber abhängt oder Kapazität eines verbundenen Anbieters weiterverkauft.
Das Produktmenü ist wichtig, weil es den Kunden zeigt, welche Art von physischem System existieren sollte. DieShared-Hosting-Seitebietet drei Tarifgrößen mit 20 GB, 50 GB und 165 GB Speicher, cPanel, unbegrenzte Websites, unbegrenzte Mailboxen, kostenlose SSL-Zertifikate, CDN, Migrationshilfe, mehrere PHP-Versionen und Monats-Backups. DieWordPress-Hosting-Seitebietet ähnliche Stufen von 20 GB, 50 GB und 165 GB, fügt WordPress-Verwaltung hinzu und verspricht Hilfe beim Umzug von WordPress-Websites. DieReseller-Hosting-Seitebietet Tarife mit 40 GB, 75 GB und 130 GB, WHM-Zugriff, unbegrenzten Traffic und unbegrenzte Konten. Dies sind keine abstrakten Cloud-Slogans. Es sind Behauptungen, dass gemeinsame physische oder virtuelle Hosts existieren, dass darauf Konten erstellt werden können und dass Migrationen und Backups Teil des Serviceversprechens sind.
Das Cloud-Menü erhöht den Einsatz. DieCloud-VPS-Seitebietet Instanzen mit einem bis vier virtuellen CPUs, 1 GB bis 6 GB RAM, 30 GB bis 85 GB SSD-Speicher, tägliche Backups, Verwaltungsbereich, OpenStack, KVM und Ceph. Sie verkauft auch zusätzliche IP-Adressen, zusätzliche System-Backups und 30-minütige Systemadministrationsblöcke. DieManaged-Cloud-VPS-Seitebietet verwaltete Server mit Kontrollbereich, technischem Support, täglichen Backups, 24-Stunden-Überwachung und kostenloser Migration. DiePrivate-Cloud-Seitegeht weiter und beschreibt ein OpenStack-basiertes virtuelles Rechenzentrum mit softwaredefiniertem Speicher, einer Behauptung eines 99,99 % Servicelevels, doppelt gesichertem Netzwerk und API-Diensten wie Cinder, Nova, Heat, Glance, Magnum, Neutron und Keystone. DieKubernetes-Seitebeschreibt Hilfe bei der Installation, Konfiguration und Wartung einer hochverfügbaren Kubernetes-Umgebung und gibt an, dass der Dienst Infrastruktur, Netzwerk und Load Balancer als eine seiner Schichten abdeckt.
Diese Seiten geben Hosting27 eine stärkere öffentliche Verkaufsoberfläche als viele kleine Hosting-Netzwerke. Sie schaffen auch eine größere Beweislücke. Ein Ein-Knoten-VPS-Verkäufer kann stillschweigend scheitern. Ein Verkäufer von OpenStack, Ceph, Private Cloud und Kubernetes muss mehr Fragen beantworten: Wie viele physische Knoten sind verfügbar? Wie ist die Speicherreplikation isoliert? Haben die Steuerungsebenen-Komponenten unabhängige Ausfallbereiche? Wo befinden sich Backups? Welcher Adresspool bedient Kunden? Welcher Router trägt die Route? Und wer kann das System reparieren, wenn die physische Schicht ausfällt?
Der sicherste Ausgangspunkt ist daher weder Ablehnung noch blindes Vertrauen. Hosting-27 hat eine sichtbare Website und eine sichtbare AS. Die öffentliche Akte unterstützt die Existenz eines bulgarischen Hosting-Betriebs. Sie unterstützt keine starke Schlussfolgerung über installierte Cloud-Kapazität, Multi-Site-Wiederherstellung oder Anbieterunabhängigkeit.
Das RIPE-Register gibt Hosting-27 eine kleine, aber reale Netzwerkgrenze
Der klarste Infrastrukturnachweis findet sich in der RIPE-Datenbank und RIPEstat. Deraut-num-Eintrag für AS42347nennt die AS "Hosting-27", listet Hosting-27 LTD über ORG-HA629-RIPE, registriert den Status ASSIGNED, gibt Erstellung am 24. August 2017 und letzte Änderung am 7. April 2021 an, und registriert die Import- und Exportpolitik für AS57344 und AS31083. Der zugehörigeOrganisationseintragnennt Hosting-27 LTD, Land BG, Registernummer 204354361, Organisationstyp OTHER, eine Adresse in Sofia am Todor Aleksandrov 133, und einen Missbrauchskontakt bei GLAC2-RIPE. Er wurde im August 2017 erstellt und zuletzt im Mai 2026 geändert.
Die IPv4-Zuweisung ist ebenso explizit. DasRIPE-inetnum für 217.174.144.0 - 217.174.144.255verwendet netname Hosting-27, Land BG, Organisation ORG-HA629-RIPE und Status ASSIGNED PA. DasRIPE-route-Objekt für 217.174.144.0/24beschreibt Hosting27 und autorisiert den Ursprung AS42347. Dieannounced-prefixes-Ansicht von RIPEstat zeigte 217.174.144.0/24 sichtbar im Zweiwochenfenster bis zum 12. Juli 2026. Ihrerouting-status-Ansicht zeigte ein IPv4-Präfix, 256 IPv4-Adressen und vollständige IPv4-Sichtbarkeit bei 326 RIPE-RIS-Peers von 326 zum überprüften Zeitpunkt.
Dieses /24 ist nicht nur ein passiver Eintrag. Die Domain Hosting27.com selbst löst im selben Block auf. DieDNS-Chain-Ansicht von RIPEstat für hosting27.com löste hosting27.com in 217.174.144.181 auf, ordnete diese Adresse invers shared-11.cpaneler.com zu und listete autoritative Nameserver, darunter ns1-pns.hosting27.com und ns2-pns.hosting27.com. DerRDAP-Domaineintragfür hosting27.com zeigt die Domain registriert am 12. Juli 2013, ablaufend am 12. Juli 2027, mit PublicDomainRegistry.com als Registrar und Nameservern unter hosting27.com. Die sichtbare Website, DNS und das geroutete Präfix sind also um denselben öffentlichen Netzwerk-Footprint ausgerichtet.
Der Adresspool ist klein. Ein /24 enthält 256 IPv4-Adressen, bevor Router-Schnittstellen, Infrastruktur-Hosts, Nameserver, Shared-Hosting-IPs, Kunden-Zuweisungen, Reserveadressen und die reservierte Kapazität gezählt werden. Das reicht für ein echtes Hosting-Unternehmen, insbesondere wenn viele Shared-Hosting-Kunden hinter namensbasierten virtuellen Hosts sitzen und kleine VPS-Pläne sich Hosts teilen können, ohne jeweils mehrere öffentliche Adressen zu erhalten. Es reicht nicht aus, um eine große installierte Kapazität abzuleiten.
Ein Private-Cloud-Angebot, ein Kubernetes-Angebot, Reseller-Konten, Managed VPS und Shared Hosting können alle aus einem kompakten öffentlichen Adresspool verkauft werden, wenn interne Adressierung, NAT, virtuelles Hosting und sorgfältige Zuweisung verwendet werden. Sie können auch überverkauft werden, wenn die Planung locker ist. Die öffentliche Route unterscheidet diese Fälle nicht.
Es gibt auch ein zweites route-Objekt, das vorsichtig behandelt werden muss. DieAS-routing-consistency-Ansicht von RIPEstat listet 45.151.89.0/24 als im whois vorhanden, aber nicht im BGP für AS42347 zum Zeitpunkt der Anfrage. EineRIPE-Suche nach 45.151.89.0/24zeigt ein route-Objekt für AS42347, aber das inetnum gehört Geytit OOD, nicht Hosting-27 LTD, und die Route war nicht Teil des aktuell sichtbaren angekündigten Sets. Dies bedeutet, dass möglicherweise eine Routing-Politik für einen anderen Pool vorbereitet wurde oder dass die Route inaktiv, reserviert, historisch oder zum Zeitpunkt der Anfrage nicht sichtbar war. Sie sollte nicht als Hosting-27-Kapazität gezählt werden, die für Kunden verfügbar ist, es sei denn, aktuelle BGP- und kommerzielle Beweise stützen dies.
Die Netzwerkgrenze ist also real, aber eng definiert: eine sichtbare AS, ein sichtbares /24 IPv4, ein gültiges route-Objekt, eine Live-Website im Block und kein sichtbares IPv6-Präfix für AS42347 in der RIPEstat-Routing-Ansicht.
Büro, Website und Vertragsname sind nicht dasselbe wie ein verifizierter Rechenzentrumsraum
Die öffentliche Adressspur ist nützlich, identifiziert aber kein Rechenzentrum. DieKontaktseitevon Hosting27 gibt Sofia, Todor Aleksandrov Boulevard 133, Etage 2, plus Telefonnummer und Support- und Verkaufs-E-Mail-Adressen. Der RIPE-Organisationseintrag für Hosting-27 LTD gibt eine entsprechende Adresse Todor Aleksandrov 133. DerRIPE-Organisationseintragvon Geytit OOD verwendet ebenfalls Todor Aleksandrov 133 und erscheint als sponsernde Organisation im AS42347-Eintrag. Diese Einträge sind bedeutsam für Kontakt und Registerverwaltung. Sie beweisen nicht, dass sich die Kundenserver in diesem Gebäude befinden, dass Hosting-27 dort Racks besitzt oder dass das Unternehmen direkten Zugang zu Strom- und Cross-Connect-Infrastruktur hat.
Die öffentlichen rechtlichen Bedingungen fügen eine weitere Einschränkung hinzu. DieAllgemeine Geschäftsbedingungen-Seite von Hosting27 enthält ein PDF, und diePDF-Bedingungenlegen fest, dass die Servicebedingungen für Shared Hosting, SSL-Zertifikate, Domainregistrierung, virtuelle Server und verwaltete virtuelle Server über die Website Hosting27.com gelten. Das PDF nennt Cloud Systems OOD als Anbieter in den bulgarischen Bedingungen und gibt eine andere Unternehmensregistriernummer. Dieser Artikel behandelt dies nicht als Unternehmensbeziehungsschlussfolgerung. Er behandelt es als ein Problem der Käufer-Sorgfaltspflicht: Die Marke, die RIPE-Organisation, der sponsernde LIR, die Web-Bedingungen und der Rechnungsaussteller müssen übereinstimmen, bevor ein Kunde den Dienst als zuverlässigen Infrastrukturvertrag betrachtet.
Diese Einschränkung ist bei einem Ausfall wichtig, nicht nur beim Kauf. Wenn eine VM um 2:00 Uhr ausfällt, muss der Kunde wissen, welche Entität die Support-Warteschlange steuert, welche Entität die Hardware besitzt oder mietet, wer entfernte Hände autorisieren kann, wer eine Festplatte ersetzen kann, wer die Router-Sitzung steuert, wer den Dienst in Rechnung stellt und wer die Daten bei einem Abrechnungsstreit bewahren kann.
Eine Diskrepanz zwischen Marke, AS-Inhaber und Vertragsanbieter ist nicht grundsätzlich schlecht; viele Hosting-Gruppen verwenden separate juristische Personen für Adressressourcen, Kundenverträge, Einrichtungen und Betrieb. Aber die hier untersuchten öffentlichen Dokumente erklären diese Struktur nicht. Kunden sollten direkt nachfragen.
Die Bedingungen geben auch an, dass der gehostete Dienst ein begrenztes Angebot ist, keine Garantie dafür, dass jeder Kunde eine vollständig unabhängige Umgebung erhält. Das PDF gibt an, dass Shared Hosting beinhaltet, dass Kunden gemeinsame Serverressourcen wie Geschwindigkeit, RAM und Netzwerkkonnektivität mit anderen Benutzern teilen. Der Abschnitt über verwaltete virtuelle Server beschreibt die Verwaltung eines virtuell getrennten Servers mit Kontrollbereich, 24/7-Support, garantierten Ressourcen, die nicht mit anderen Kundenanwendungen geteilt werden, Überwachung, Reaktion auf Probleme und regelmäßige Backups.
Dies ist eine nützliche Sprache zum Verständnis der beabsichtigten Serviceklassen. Sie lässt dennoch die Wiederherstellungszeit, den Backup-Standort, die Aufbewahrungsdauer von Snapshots, die Offsite-Replikation, das Kundenexportformat und Ausfallgutschriften in der öffentlichen Ansicht unklar.
Die Rahmung des "virtuellen Rechenzentrums" auf der Private-Cloud-Seite ist besonders wichtig zu qualifizieren. Ein Kunde, der diesen Satz liest, mag sich einen dedizierten Rechenzentrumsbereich vorstellen. Die Seite selbst beschreibt eine OpenStack-Abstraktion: kundenerstellte Netzwerke, Router, Load Balancer und Speicherdienste. Dies sind virtuelle Funktionen der Steuerungsebene. Sie ruhen dennoch auf physischen Knoten, Festplatten, Netzwerkkarten, Top-of-Rack-Switches, Netzteilen und Transitverbindungen.
Ohne eine benannte Einrichtung oder Architekturerklärung muss die Behauptung als Cloud-Steuerungsebenen-Angebot behandelt werden, nicht als Nachweis eines separaten physischen Standorts.
Der sichtbare Upstream ist Telehouse, während Telepoint eine politische Möglichkeit ist
Das Routing-Bild ist am aktuellen Beobachtungspunkt einfach. DieASN-Nachbarn-Ansicht von RIPEstat für AS42347 meldete zum letzten verfügbaren Zeitpunkt einen einzelnen Nachbarn: AS57344. DieAS-Übersichtvon RIPEstat für AS57344 identifiziert AS57344 als TELEHOUSE-AS Telehouse EAD. DerRIPE aut-num AS57344zeigt Telehouse mit einer breiten Upstream- und Peering-Politik, einschließlich Arelion, Cogent, GTT, Level 3, Liberty Global, NTT, Orange, PCCW, RETN, Seabone, Tata, Telxius und mehreren Austausch-Fabrics. DerPeeringDB-Eintrag AS57344beschreibt Telehouse mit globaler Reichweite, IPv6-Unterstützung, vielen Austausch-Präsenzen und Einrichtungseinträgen.
Diese Breite von Telehouse hilft zu erklären, wie das /24 von Hosting-27 von globalen Sammlern sichtbar sein kann. Es macht Hosting-27 nicht automatisch Multihomed. Die sofort beobachtete Abhängigkeit für AS42347 ist immer noch ein einzelner Nachbar. Wenn die AS42347-Route nur von Telehouse an der aktiven Grenze getragen wird, dann kann ein Problem auf Telehouse-Seite, eine Sitzung, ein Routenfilter, ein Einrichtungsvorfall, ein Cross-Connect-Problem, ein kommerzielles Einfrieren oder ein Wartungsfenster alle Kunden betreffen, die das sichtbare Präfix von Hosting-27 verwenden.
Öffentliche Route-Collectoren können private Backup-Pfade, vorübergehend inaktive Sitzungen oder Arrangements verpassen, die erst bei Ausfall aktiv werden. Aber die Beweislast liegt beim Anbieter, eine solche Redundanz zu zeigen, da die aktuelle öffentliche BGP-Ansicht dies nicht tut.
AS31083 ist der zweite Name, der präzise behandelt werden muss. Der RIPE aut-num von AS42347 listet Import- und Exportpolitik mit AS31083, und dieAS31083-Übersichtvon RIPEstat identifiziert AS31083 als Telepoint Ltd. DerRIPE aut-num AS31083zeigt Telepoint mit mehreren Upstreams verbunden, und derPeeringDB-Eintrag Telepointmeldet ein Profil mit geringerer europäischer Reichweite. Aber die AS-routing-consistency-Ansicht von RIPEstat zeigt AS31083 als im whois vorhanden und nicht im BGP für AS42347 zum Zeitpunkt der Anfrage. Das bedeutet, dass die Registerpolitik allein nicht als aktive Diversität beschrieben werden sollte.
Das Fehlen von PeeringDB für Hosting-27 verstärkt die Notwendigkeit von Vorsicht. EinePeeringDB-Anfrage für AS42347gab kein öffentliches Netzwerkobjekt zurück. Viele kleine Netzwerke arbeiten ohne PeeringDB-Profil, daher ist das Fehlen kein Fehler. Es bedeutet, dass es keine öffentliche Liste von Hosting-27-Einrichtungen, Austauschliste, Looking-Glass-Seite, Verkehrsschätzung, Peering-Politik oder NOC-Profil in diesem Verzeichnis gibt. Die einzigen öffentlichen Interkonnektionsspuren sind die RIPE-Politik, die Route-Collectoren und die Identitäten der beobachteten oder registrierten Upstreams.
Das Ergebnis der Routenursprungssicherheit ist positiv. DieRPKI-Validierung für 217.174.144.0/24meldet eine gültige ROA für AS42347, die das exakte /24 mit maximaler Länge /24 originert. Dies hilft Netzwerken, die Routenursprungsvalidierung anwenden, die Route als autorisiert zu akzeptieren. Es schützt nicht vor Host-Ausfall, Speicherausfall, Router-Fehlkonfiguration, unbezahlten Upstream-Rechnungen, Kompromittierung des Kontrollbereichs oder Kundenkontosperrung. RPKI beantwortet, wer das Präfix ankündigen darf, nicht ob der Hosting-Dienst wiederhergestellt werden kann.
Für Käufer ist die Sorgfaltspflichtfrage zum Transit praktisch: Ist Telehouse der aktive Upstream für alle Hosting27-Dienste? Ist AS31083 ein Backup- oder historischer Politikeintrag? Kann einer der Pfade die Arbeitslast des Kunden während der Wartung transportieren? Und werden die Routen von physisch getrennten Übergabepunkten oder vom selben Raum und derselben Abhängigkeitskette angekündigt?
Angekündigte Cloud-Funktionen sind nicht gleich installierte, nutzbare oder wiederherstellbare Kapazität
Die Hosting-Ökonomie belohnt effizientes Teilen. Shared Hosting verkauft Speicher, E-Mail und Site-Verwaltung, indem viele Kundenkonten auf einem oder mehreren Servern gebündelt werden. VPS-Hosting verkauft Scheiben von virtueller CPU, RAM und Speicher von größeren Hosts. Managed VPS fügt Support-Arbeitskraft, Überwachung und Verwaltung hinzu. Private Cloud fügt eine Orchestrierungsschicht und ein stärkeres Versprechen der Kundenkontrolle hinzu. Kubernetes fügt eine weitere Orchestrierungsschicht hinzu. Jede Schicht kann real sein, während sie dennoch von einer kleinen Anzahl physischer Knoten abhängt.
Die Seiten von Hosting27 machen breite Behauptungen, die für einen kleinen bulgarischen Anbieter plausibel, aber von außen nicht dimensionierbar sind. Die Shared-Hosting-Tarife werben mit unbegrenzten Websites, Mailboxen und Traffic, aber dies sind Tarifregeln, keine unendliche Kapazität. Der Dienst hängt dennoch von CPU, RAM, Speicher-I/O, Inode-Grenzen, Fair-Use-Regeln, Spam-Kontrolle und Missbrauchsverwaltung ab.
Die Reseller-Tarife werben mit unbegrenztem Traffic und Konten, aber die Speichergrenzen betragen 40 GB, 75 GB und 130 GB; die eigentliche Einschränkung kann I/O, ausgehende E-Mail-Reputation, Kontendichte oder Leistung des gemeinsamen Hosts sein, bevor der Rohspeicher erschöpft ist.
Die VPS-Seiten sind konkreter, da sie Werte für virtuelle CPU, RAM und SSD auflisten. Ein Cloud-VPS-Tarif mit 1 vCPU, 1 GB RAM, 30 GB SSD und ein Tarif mit 4 vCPU, 6 GB RAM, 85 GB SSD können von einem bescheidenen OpenStack-Cluster bereitgestellt werden. Aber eine Tariftabelle zeigt nicht, wie viele Instanzen ohne Konflikt verkauft werden können, wie viele Knoten existieren, ob die CPU überbucht ist, wie die Speicherreplikation angepasst ist, ob Ceph sich über unabhängige Strombereiche erstreckt oder ob Backups auf demselben physischen System gespeichert sind, das sie schützen sollen.
Die Seite gibt an, dass Ceph Daten an mehreren Orten repliziert hält; ein Kunde muss dennoch wissen, ob diese Orte separate Festplatten, separate Gehäuse, separate Racks oder separate Einrichtungen sind.
Die 99,99 % Service-Level-Sprache der Private-Cloud-Seite muss als zu überprüfende Behauptung behandelt werden, nicht als Nachweis des erreichten Betriebszustands. Vier Neunen Verfügbarkeit erlauben nur eine kleine Menge Ausfallzeit pro Jahr, und dies erfordert sowohl Architektur als auch Betriebsdisziplin: redundante Stromversorgung, redundante Netzwerkpfade, sorgfältig verwalteter Speicher, getestete Wiederherstellung der Steuerungsebene, Änderungsmanagement, Überwachung und ein Support-Team, das schnell handeln kann.
Die öffentliche Website veröffentlicht nicht das SLA-Dokument, das Guthaben-System, die Messmethode, Ausschlüsse, die Behandlung geplanter Wartung oder den Vorfallverlauf, die es einem Käufer ermöglichen würden, dieses Versprechen zu bewerten.
Der Adressbestand schränkt einige Anwendungsfälle ein. Ein Kunde, der viele öffentliche IPv4-Adressen, Trennung von E-Mail-Diensten, alte IP-basierte SSL-Kompatibilität, Anti-Missbrauchsisolation oder VPN-Endpunkte benötigt, sollte fragen, wie viele IPv4 tatsächlich verfügbar sind. Die Zählung vonRIPEstat routing-statusvon 256 IPv4-Adressen ist nicht dasselbe wie 256 verkaufbare Kunden-IPs. Einige werden von Infrastruktur, DNS, Shared Hosting, Verwaltung, Reserven und Kundenzuweisungen verbraucht. Zusätzliche IPs werden auf der Cloud-VPS-Seite verkauft, was den Pool betrieblich wichtig macht. Wenn Missbrauchs- oder Blacklist-Probleme einen Teil des /24 betreffen, kann der kleine Adresspool die Wiederherstellung erschweren.
IPv6 ist eine weitere Lücke. Die untersuchten öffentlichen Produktseiten von Hosting27 machen kein starkes IPv6-Versprechen, und RIPEstat zeigt zum überprüften Zeitpunkt keinen sichtbaren angekündigten IPv6-Raum für AS42347. Ein Kunde, der IPv6-kompatibles Hosting benötigt, sollte dies nicht aus dem Wort Cloud ableiten. Er sollte eine IPv6-Testadresse, SLA-Abdeckung, Firewall-Verwaltung, reversen DNS, Routing-Nachweise anfordern und ob IPv6-Unterstützung auf Shared Hosting, VPS, Private Cloud und Kubernetes in gleicher Weise verfügbar ist wie IPv4.
Die Kapazitätsschlussfolgerung des Artikels ist daher konservativ: Hosting27 verkauft ein reales Set von Hosting- und Cloud-Produkten, und AS42347 gibt diesen Produkten eine echte öffentliche Netzwerkgrenze. Aber es gibt keine öffentlichen Beweise, die das Tarifmenü in installierte Knoten, verfügbare Reservekapazität, Multi-Site-Design oder vom Kunden wiederherstellbare Images übersetzen.
Support- und Backup-Behauptungen sind nützlich, aber die Reparaturautorität ist die zentrale Frage
Die Support-Nachweise sind besser als Stille. DieKontaktseitevon Hosting27 listet Support-Adressen auf, darunter Support- und DevOps-Mailboxen, und eine separate Verkaufsadresse. DieSupport-Ticket-Seitegibt an, dass Kunden, die ein Problem in der Dokumentation nicht lösen können, eine Anfrage an die entsprechende Abteilung senden können. Sie beschreibt den Support als täglich ohne Unterbrechung arbeitend und Verkaufsanfragen als von Montag bis Freitag von 09:00 bis 18:00 Uhr bearbeitet. DieWissensdatenbankhat Kategorien für cPanel, Virtualmin, VPS-Server, WordPress, Domains und Shared Hosting. DieAnkündigungsseiteenthält eine ältere Website-Ankündigung von 2018, was zumindest zeigt, dass das Kundenportal seit Jahren Teil der Dienstoberfläche ist.
Dies sind nützliche operative Anzeichen. Sie reichen nicht aus, um das Risiko des Reparaturfensters zu beantworten. Der wichtigste Unterschied ist zwischen einem Support-Kanal, der Tickets empfängt, und einem Betriebsteam mit Autorität über die ausgefallene Komponente. Wenn der Ausfall eine cPanel-Einstellung ist, kann der Support des Anbieters dies schnell beheben.
Wenn der Ausfall eine defekte Festplatte, ein ausgefallener Switch, ein Stromproblem, ein Speichercluster-Quorum-Problem, ein Upstream-Routenfilter oder ein gesperrtes Abrechnungskonto ist, hängt die Reparatur davon ab, wer die Hardware, den Einrichtungszugang, die Router-Sitzungen und die vertraglichen Berechtigungen kontrolliert.
Die Allgemeinen Geschäftsbedingungen sind ebenfalls nützlich, aber für die Vorfallplanung unvollständig. Das PDF gibt an, dass verwaltete virtuelle Server 24/7-technischen Support, Überwachung und Reaktion auf Probleme, regelmäßige Backups und die Möglichkeit zum Hosten von Kundenanwendungen umfassen. Es gibt an, dass Shared Hosting technischen Support beinhaltet und festlegt, dass Shared-Benutzer Ressourcen teilen. Die öffentlichen Seiten bewerben außerdem tägliche Backups auf Cloud VPS und Managed Cloud VPS, Monats-Backups auf Shared Hosting und kostenlose Migration für bestimmte Tarife. Dies ist wertvoll.
Es lässt dennoch praktische Fragen offen: Sind Backups auf demselben Cluster oder außerhalb? Wie viele Generationen existieren? Kann ein Kunde im Selbstbedienungsmodus wiederherstellen? Kann ein VM-Image exportiert werden? Was passiert nach Kontosperrung? Und was ist das angestrebte Wiederherstellungszeitfenster?
Das Migrationsversprechen ist ebenfalls enger, als es scheint. Hosting27 gibt an, dass es ein Hosting-Konto oder eine WordPress-Website kostenlos umziehen kann. Dies hilft beim Onboarding. Es schafft nicht unbedingt einen Ausstiegspfad. Ein Kunde, der später geht, benötigt möglicherweise ein vollständiges cPanel-Backup, einen Datenbank-Dump, DNS-Zonendateien, Mailboxen, ein VM-Festplatten-Image, einen Block-Speicher-Snapshot, Objektdaten, Kubernetes-Manifeste, Container-Images, Secrets und IP-Umnummerierung.
Die öffentliche Website beschreibt keine Exportformate, Aufbewahrungsfenster, Migrationsgebühren nach Kündigung oder ob Kunden OpenStack-Images extrahieren können.
Die Missbrauchsbehandlung ist wichtig, da Hosting-Anbieter vom gemeinsamen Ruf leben und sterben. Der RIPE-Organisationseintrag für Hosting-27 leitet Missbrauch anGLAC2-RIPE, einen GateIT-Missbrauchskontakt. Dies ist ein Register-Missbrauchspfad, nicht unbedingt derselbe wie ein Einzelhandels-Support-Schreibtisch. Ein Kunde, der E-Mail, E-Commerce oder öffentliche APIs betreibt, sollte fragen, wer das reverse DNS verwaltet, wer sich um die Blacklist-Bereinigung kümmert, wer entscheidet, ob ein kompromittiertes Konto eine breitere Sperrung verursacht, und ob IP-Reputationsprobleme innerhalb des /24 isoliert werden können.
Die öffentliche Support-Haltung ist also glaubwürdig genug, um zu zählen, aber nicht detailliert genug, um das Betriebsrisiko zu beseitigen. Käufer sollten das Ticket-System testen, bevor sie wichtige Arbeitslasten verlagern, einen Vorfall-Kontaktpfad anfordern und schriftliche Backup- und Exportbedingungen verlangen, anstatt sich auf die abgekürzte Sprache der Tarifseiten zu verlassen.
Der Datenstandort wird nicht durch eine bulgarische Adresse oder IP geregelt
Die bulgarische Oberfläche von Hosting27 ist relevant. Die Website ist in bulgarischer Sprache, die Kontaktseite gibt Details zu Sofia, die RIPE-Organisation und -Adresse sind bulgarisch, die SN ist in der RIPE-Region, und der sichtbare IPv4-Block ist mit Land BG registriert. Für Kunden mit bulgarischen Benutzern, einer bulgarischen Rechnung, lokalsprachlichem Support und Latenz zu Sofia oder regionalen Netzwerken können dies Gründe sein, den Dienst in Betracht zu ziehen. Für Kunden mit regulatorischen oder vertraglichen Anforderungen an den Datenstandort sind dies nur der Anfang.
Der EU- und Bulgarien-Kontext macht die Unterscheidung wichtig. Der Überblick der Europäischen Kommission über denrechtlichen Rahmen für den Datenschutz in der EUerklärt das EU-weite Datenschutzregime. Ihre Seite zuVerantwortlichen und Auftragsverarbeiternerklärt den Unterschied zwischen der Partei, die entscheidet, wie personenbezogene Daten verarbeitet werden, und einer Partei, die sie im Auftrag einer anderen verarbeitet. Die Seite der Kommission zuStandardvertragsklauselndeckt Datentransferinstrumente für Situationen außerhalb des Europäischen Wirtschaftsraums ab. Diebulgarische Kommission für den Schutz personenbezogener Datenist die nationale Aufsichtsbehörde. Dieser Artikel ist keine Rechtsberatung, aber diese öffentlichen Referenzen zeigen, warum der Standort der Infrastruktur, der Support-Zugang und die Geographie der Backups keine kosmetischen Details sind.
Eine bulgarische IP-Adresse beweist nicht, dass alle Daten in Bulgarien verbleiben. Shared-Hosting-Backups könnten in einer anderen Einrichtung gespeichert sein. Die Überwachung könnte von woanders aus erfolgen. Ein Support-Ticket könnte personenbezogene Daten enthalten. Ein Kontrollbereich könnte von Drittanbieter-Software oder externer Authentifizierung abhängen. Eine CDN-Funktion könnte statische Inhalte absichtlich in anderen Ländern platzieren. Ein Domainregistrierungsdienst interagiert notwendigerweise mit Registern und Registraren außerhalb des Hosting-Knotens.
Ein Private-Cloud-Kunde kann Netzwerke und Volumes in einer bulgarisch aussehenden Konsole erstellen, während sich einige Verwaltungs- oder Backup-Komponenten woanders befinden.
Die richtigen Sorgfaltspflichtfragen sind daher konkret. Wo befindet sich der primäre Rechenknoten? Wo werden Snapshots und Backups gespeichert? Sind Support-Mitarbeiter und entfernte Administratoren in der EU? Bietet der Anbieter eine Auftragsverarbeitungsvereinbarung an? Welche juristische Person ist der Auftragsverarbeiter für die Hosting-Dienste? Nennt der Vertrag dieselbe Partei, die dem Kunden die Rechnung stellt? Wenn Daten Bulgarien oder den EWR verlassen, welcher Transfermechanismus gilt? Was passiert, wenn der Kunde die Löschung oder den Export der Daten verlangt? Welche Protokolle werden aufbewahrt und wie lange?
Diese Fragen sind kein besonderer Verdacht gegenüber Hosting-27. Sie sind normal für jeden kleinen Cloud- oder Hosting-Anbieter, der mit Lokalität wirbt. Die öffentlichen Beweise hier unterstützen einen bulgarischen Dienstbereich und eine bulgarische geroutete Grenze. Sie beweisen keine vollständige Datenresidenz-Architektur in Bulgarien.
Zu testende Ausfallpfade sind Rack, Upstream, Hardware-Bestand, Support, Abrechnung und Migration
Der erste Ausfallpfad ist das Rack. Wenn ein Shared-Hosting-Server oder VPS-Host ausfällt, wer berührt die Maschine? Ein Kunde sollte fragen, wo sich das Rack befindet, wem die Host-Hardware gehört, wie der Strom geschützt ist, ob es Ersatzknoten gibt, ob der Speicher lokal oder verteilt ist und ob ein ausgefallener Knoten evakuiert werden kann, ohne die IP des Kunden zu ändern. Die öffentliche Website bewirbt Backups und Cloud-Funktionen, nennt aber nicht die physische Einrichtung, das Rack, den entfernten Hände-Anbieter oder den Ersatzhardwareplan.
Der zweite Pfad ist der Upstream-Transit. RIPEstat sieht derzeit AS42347 über AS57344. Der Anbieter sollte sagen können, ob die Route einen zweiten aktiven Upstream hat, ob Telepoint aktiv, Backup oder historisch ist, ob der Backup-Pfad getestet wird, ob die Routenursprungsvalidierung überwacht wird und ob Kunden vor Netzwartungen benachrichtigt werden. Ein gültiges RPKI-Ergebnis ist gut. Es ist nicht dasselbe wie ein zweiter Pfad.
Der dritte Pfad ist der Hardware- und Speicherbestand. Die VPS- und Private-Cloud-Angebote hängen vom Verhältnis zwischen verkauften Tarifen und verfügbarer Rechenleistung, RAM, Festplatten-I/O und Speicherreplikation ab. Ein Kunde sollte fragen, ob die angekündigten Ressourcen garantiert sind, ob die CPU überbucht ist, ob Ceph sich über separate Hosts oder separate Racks erstreckt, wie viele Ausfälle toleriert werden können und ob genügend Reservekapazität vorhanden ist, um einen Host während einer Auslastungsspitze wiederherzustellen.
Die öffentliche Seite nennt OpenStack, KVM und Ceph, aber diese Namen können alles von einem kleinen Cluster bis zu einer größeren Multi-Rack-Umgebung beschreiben.
Der vierte Pfad ist die Support-Eskalation. Hosting27 legt Support-, Verkaufs-, Wissensdatenbank- und Ticket-Seiten offen. Der Käufer sollte dennoch die Antwortqualität testen, fragen, wer Bereitschaft hat, den Notfallpfad für eine ausgefallene VM identifizieren und fragen, ob der Support direkt Netzwerk- und Einrichtungsbetreiber kontaktieren kann. Eine kommerzielle Antwort ist nicht dasselbe wie eine Vorfallbefugnis.
Der fünfte Pfad ist die Abrechnungs- und rechtliche Kontinuität. Die PDF-Bedingungen der Website nennen Cloud Systems OOD als Anbieter, während RIPE Hosting-27 LTD als Netzwerkorganisation nennt. Kunden sollten fragen, welche Partei den Vertrag unterzeichnet, welche Partei die Rechnung stellt, welche Partei die Dienstsperrung kontrolliert und welche Partei für Export und Löschung nach Kündigung verantwortlich ist. Wenn das Konto wegen Abrechnung oder Missbrauch gesperrt wird, sollte der Kunde wissen, wie lange die Daten wiederherstellbar bleiben.
Der sechste Pfad ist die Migration. Für Shared Hosting sollte der Ausstiegspfad ein cPanel-Backup, DNS, Mailboxen und Datenbanken umfassen. Für WordPress sollte er Dateien, Datenbank, Weiterleitungen und DNS-Timing umfassen. Für VPS sollte er Festplatten-Image-Export, Snapshot-Format, IP-Umnummerierung und Firewall-Updates umfassen. Für Private Cloud und Kubernetes sollte er Volumes, Netzwerke, Load Balancer, Manifeste, Secrets und Image-Registries umfassen. Hosting27 bewirbt eine kostenlose eingehende Migration, aber das öffentliche Material veröffentlicht kein vollständiges Versprechen der ausgehenden Portabilität.
Der siebte Pfad ist die Adressreputation. Ein kompaktes /24 kann effizient sein, gibt aber weniger Spielraum, um kompromittierte Kunden zu isolieren. E-Mail-, Proxy-, Scan- und Missbrauchsprobleme können zu Blacklists, Upstream-Filterung oder internen Sperrungen führen. Kunden mit E-Mail- oder Transaktionsarbeitslasten sollten die Kontrolle des reversen DNS, das Missbrauchsantwortverfahren, die Blacklist-Bereinigungspolitik anfragen und ob zusätzliche IP-Adressen aus demselben Pool 217.174.144.0/24 stammen.
Dies sind keine theoretischen Bedenken. Dies sind die gewöhnlichen Ausfallmodi, die unter kostengünstigem Hosting verborgen sind: ein unzugängliches Rack, eine verschwindende Upstream-Sitzung, ein Speichercluster, der das Quorum verliert, ein Backup, das existiert, aber nicht schnell wiederhergestellt werden kann, eine Ticket-Warteschlange, die die Einrichtung nicht erreicht, und ein Kunde, der zu spät entdeckt, dass ein Wechsel bedeutet, um neue IP-Adressen herum neu aufzubauen.
Was die Beweise solide machen würde
Hosting-27 Hosting-27 LTD hat genügend öffentliche Beweise für ein echtes Betriebsprofil: Die Website ist live, das Kundenportal ist live, die Produktseiten sind spezifisch, die Route ist sichtbar, die Domain löst innerhalb des sichtbaren IPv4-Blocks des Unternehmens auf, die RIPE-Organisation ist aktuell und die Routenursprungsautorisierung ist gültig. Dies ist materiell stärker als ein Unternehmen, dessen einzige Spur ein veralteter AS-Eintrag ist.
Die öffentlichen Beweise sind nicht stark genug für eine High-Confidence-Infrastrukturabhängigkeit ohne direkte Sorgfaltspflicht.
Ein stärkeres Profil würde eine aktuelle rechtliche Seite umfassen, die Marke, RIPE-Organisation und Vertragsanbieter in Einklang bringt; eine Einrichtungserklärung, die den Rechenzentrumsbetreiber nennt oder die Hosting-Vereinbarung erklärt; ein SLA mit Mess- und Gutschriftbedingungen; eine Statusseite oder Vorfallarchive; explizite Backup-Aufbewahrungs- und Wiederherstellungsziele; IPv6-Verfügbarkeit, falls angeboten; einen zweiten aktiven Upstream oder eine schriftliche Erklärung der Telepoint-Routing-Politik; Exportformate für VPS- und Private-Cloud-Daten; und ein klares Missbrauchs- und IP-Reputationsverfahren.
Der wahrscheinliche Kundenkreis sollte nach Risiko gestaffelt sein. Eine kleine bulgarische Website, ein Staging-Server, eine nicht kritische WordPress-Site oder ein experimenteller VPS kann Hosting27 durch gewöhnliche Servicetests bewerten: einen kleinen Tarif bestellen, den Support testen, die Latenz überprüfen, ein Backup wiederherstellen und die Kündigung überprüfen. Ein geschäftskritisches System sollte sich nicht allein auf die Tariftabelle verlassen. Es sollte schriftliche Antworten zu Einrichtung, Backups, Transit-Diversität, rechtlicher Vertragsgestaltung und Datenportabilität einholen, bevor es die Produktion verlagert.
Das abschließende Urteil ist ausgewogen. Hosting-27 Hosting-27 LTD ist als bulgarischer Verkäufer von gehosteter Kapazität mit AS42347 und einer Live-Plattform Hosting27.com sichtbar. Seine öffentliche Betriebsgeschichte ist nicht leer. Aber die entscheidenden Infrastrukturfakten bleiben hinter der Verkaufsschicht verborgen.
Bis diese Fakten offengelegt oder in einem Kundenvertrag verifiziert sind, sollte Hosting27 als ein kompakter bulgarischer Anbieter von Hosting- und Cloud-Diensten verstanden werden, dessen Kundenversprechen noch von unsichtbaren Racks, einem über Telehouse sichtbaren Transit, einem endlichen IPv4-Bestand, Support-Arbeitskräften, Anbieterverträgen und Reparaturfenstern abhängt.