Zusammenfassung
- AS30344 ist aktiv und nicht nur registriert. Am 15. Juli 2026 zeigte RIPEstat vier IPv4-/24-Ankündigungen und eine IPv6-/40; der neueste IPv4-Block, 23.26.1.0/24, wurde 365.hosting am 6. Mai zugewiesen und erschien am 7. Mai in den Routing-Daten. Alle vier IPv4-Ursprünge wurden im überprüften Schnappschuss unter RPKI validiert, während die IPv6-Route einen unbekannten Validierungsstatus aufwies.
- Öffentliche Routenbeobachtungen zeigten einen Nachbarn, MIRhosting AS52000. Das ist eine bedeutende Konzentration an der sichtbaren AS-Grenze, auch wenn MIRhosting selbst mehrere Upstreams, Exchange-Anschlüsse und Einrichtungen hat. Es gibt keine veröffentlichten Beweise für einen zweiten AS30344-Transit, physisch unterschiedliche Zugänge, getestetes Failover oder gleichwertige Ersatzkapazität.
- 365.hosting verkauft VPS und dedizierte Server in den Vereinigten Staaten und den Niederlanden und gibt an, eigene Racks in Tier-III-Rechenzentren zu nutzen. Die US-Seite bezeichnet den Standort Secaucus noch als vXchnge NJ01, obwohl H5 Data Centers nun die gleiche Anlage unter 200B Meadowlands Parkway führt. Die niederländische VPS-Seite enthält veralteten WebHOST1-Text, der besagt, dass WebHOST1 Geräte bei Serverius nutzt; Kolos Übergangsseite sagt, dass Serverius nun unter dem Namen Kolo firmiert, dessen aktuelles Portfolio vier niederländische Standorte umfasst. Keine der Oberflächen identifiziert das relevante Rack von 365.hosting oder den Kolo-Standort. Rack-Anzahl, installierte IT-Last, verfügbarer Bestand, Belegung, Stromzuteilung und standortübergreifende Wiederherstellungskapazität bleiben unveröffentlicht.
Eine 256-Adressen-Erweiterung macht das Netzwerk sichtbarer
Der nützlichste Zugang zu 365.hosting ist nicht das Homepage-Versprechen von Premium-Rechenzentren. Es ist eine kleine, datierte Änderung im öffentlichen Adressregister.ARINs Eintrag für 23.26.1.0/24besagt, dass der 256-Adressen-Block 365.hosting am 6. Mai 2026 zugewiesen wurde. EinRIPEstat-Verlaufsabfragezeigt, dass AS30344 ihn ab dem 7. Mai ankündigt. Die Abfolge ist ungewöhnlich sauber: Zuweisung an einem Tag, sichtbare Route am nächsten.
Dieser neue Block ist wichtig, weil er die aktuelle Netzwerkaktivität bestätigt, ohne dass ein Kundenreferenz oder eine Werbeankündigung erforderlich ist. Im Schnappschuss vom 15. Juli enthielt dieAnsicht der angekündigten Präfixevier IPv4-/24er: 23.26.1.0/24, 23.152.200.0/24, 77.91.126.0/24 und 138.124.187.0/24. Außerdem enthielt sie 2602:2d3::/40. Die IPv4-Gesamtzahl beträgt 1.024 Adressen. Das IPv6-/40 ist eine Routing-Zuteilung, keine Zählung von Servern, Kunden oder nutzbaren virtuellen Maschinen.
Der gleiche Schnappschuss setzt auch die erste Grenze für die Geschichte.RIPEstats AS-Nachbaransichtfand einen linken Nachbarn, AS52000.IPinfos AS30344-Seiteklassifizierte MIRhosting ebenfalls als einzigen Upstream und bezeichnete AS30344 als Stub-Netzwerk. Ein Stub ist ein AS, das eigene Routen ankündigt, aber nicht beobachtet wird, um Transit für nachgelagerte Netzwerke bereitzustellen. Das ist eine betrieblich kohärente Form für ein bescheidenes Hosting-Netzwerk. Es ist kein Beweis für Routendiversität.
Die korrekte Eingangsbewertung ist daher weder „Papiernetzwerk“ noch „erwiesenermaßen resiliente Cloud“. AS30344 ist aktiv, sein Adressraum ist erreichbar und neue Ressourcen wurden in das Routing aufgenommen. Aber sein öffentlich sichtbarer Ausgang aus dem AS bleibt konzentriert. Diese Unterscheidung wird immer dann wichtig, wenn die Verkaufsseite hohe Verfügbarkeit, mehrere Länder oder rund-um-die-Uhr-Service verspricht.
Die Marke verkauft mehr, als AS30344 beschreiben kann
DieStartseite von 365.hostingpräsentiert einen konventionellen, aber breiten Infrastrukturkatalog. Er listet VPS/VDS, dedizierte Server, Domains, SSL-Zertifikate, Serververwaltung und Sicherheits-Add-ons auf. Es heißt, das Unternehmen sei seit 2022 tätig, habe Standorte in den Vereinigten Staaten, Europa und Asien, nutze „eigene Racks“ in Tier-III-Einrichtungen plus Partnerstandorte, unterstütze mehr als 20.000 Projekte und gehöre zur internationalen 365.partners-Gruppe. Es zeigt auch größere Marketing-Zähler, darunter aktive Websites und eine Behauptung von 99,9-prozentiger Verfügbarkeit über fünf Jahre.
Diese Aussagen legen fest, was die Marke Kunden verkaufen möchte. Sie weisen keine physischen Assets AS30344 zu. Die Behauptung eigener Racks nennt keine Rack-IDs, Leasingverträge, Facility-Hallen, Stromversorgungen oder das Unternehmen, das Eigentümer der Server ist. Die Projekt- und Website-Zähler erklären nicht, ob sie nur 365.hosting, die ältere WebHOST1-Plattform, die 365.partners-Gruppe, Domain-Registrierungen, ruhende Konten oder bezahlte Rechenleistung abdecken. Die Verfügbarkeitszahl veröffentlicht keinen Messzeitraum, Service-Nenner, Wartungsausschlüsse oder ein Vorfallprotokoll.
Die Produktseiten sind greifbarer. DieUS-Seite für dedizierte Serverlistete Dual-Socket-Intel-Konfigurationen, eine IPv4-Adresse, 30 TB Traffic, einen nominalen 1-Gbit/s-Kanal für das Standardangebot, eine Einrichtungszeit von fünf bis zehn Tagen und eine kostenlose Erstverwaltung. Sie zeigte auch eine höherwertige Konfiguration mit einem 10-Gbit/s-Kanal. DieNiederlande-Seite für dedizierte Serverbot ebenfalls ein Dual-Xeon-System, NVMe-Speicher, eine IPv4-Adresse, 30 TB Traffic, einen 1-Gbit/s-Kanal und den gleichen Einrichtungszeitraum.
Dies ist ein Beleg für einen besetzten Shop und definierte Produkte. Es ist kein Live-Inventarbericht. Eine Produktkarte kann online bleiben, während ein Chassis bestellt ist, ein Rack voll ist, ein Preis veraltet ist oder ein Standort vorübergehend nicht verfügbar ist. Die Einrichtungszeit von fünf bis zehn Tagen ist besonders aufschlussreich: Dedizierte Kapazität ist nicht unbedingt ein sofort bereitstellbarer Pool. Sie kann von Technikern, Ersatzteilen, Remote-Hands, Server-Assemblierung, Einbrennen, Verkabelung und Adresszuweisung abhängen.
Das Produkt ist ein Versprechen, Hardware nach einem Zeitraum zu liefern, kein Beweis dafür, dass jede beworbene Konfiguration installiert und heute untätig ist.
Das Netzwerk und der Katalog müssen ebenfalls getrennt bleiben. Der Server eines Kunden könnte AS30344-Space, eine andere Gruppen-ASN, von der Einrichtung bereitgestellte Adressen oder eine Zuteilung des Upstreams nutzen. Umgekehrt kann eine AS30344-Adresse Infrastruktur hosten, die nicht unter der aktuellen US- oder niederländischen Produktkarte verkauft wird. Ohne eine veröffentlichte Zuordnung zwischen Dienst, Präfix, Einrichtung und Vertrag ist die ASN die klarste Netzwerkidentität, aber keine vollständige Bestandsaufnahme der kommerziellen Plattform.
Sheridan ist die Registrierungsadresse, nicht der Serverraum
DerARIN-Autonomen-System-Eintragnennt 365-HOSTING, markiert AS30344 als aktiv und verbindet es mit der Organisationskennung PARTN-46. Der zugehörigeARIN-Organisationseintraggibt 30 N Gould Street, Suite R, Sheridan, Wyoming, und die Support-Adresse von 365.hosting an. DieKontaktseitedes Unternehmens wiederholt die gleiche Wyoming-Adresse und Telefonnummer.
Dies macht Sheridan zu einem starken administrativen und Registrierungsstandort. Es macht es nicht zu einem Rechenzentrumsstandort. Es gibt keine Angabe zu Einrichtungen auf der Kontaktseite, keine Beschreibung von Strom oder Kühlung für Wyoming und keine öffentliche Routenmessung, die den Serverbestand in diesem Gebäude verortet. Die Behandlung einer Registrierungsadresse als Rack-Koordinate würde rechtliche Präsenz und physischen Betrieb zu einem einzigen unbelegten Punkt zusammenfallen lassen.
Der Domain-Eintrag fügt eine andere Zeitleiste hinzu. DieCentralNic-RDAP-Antwort für 365.hostingverzeichnet die Erstellung der Domain im Juli 2022 und nennt ns1.365.hosting und ns2.365.hosting. Das öffentliche DNS löste die Site am 15. Juli zu 23.152.200.43 auf, innerhalb eines AS30344-Präfix. Die Mail- und Namensdienst-Hostnamen befinden sich ebenfalls in Adressen, die mit demselben Netzwerk verbunden sind. Dies gibt der Marke eine direkte technische Beziehung zu AS30344, stärker als ein Aggregator, der einfach einen Namen zuordnet.
Doch selbst dies legt die Unternehmenskette nicht präzise fest. Die Startseite sagt, 365.hosting sei Teil von 365.partners. DieRIPE NCC-Mitgliederseite für 365.partners INCgibt dieselbe Sheridan-Adresse, Telefonnummer und eine365.hosting-E-Mail-Domain an und listet Servicebereiche in Deutschland, Großbritannien, Israel und den Niederlanden auf.IPinfos AS198178-Seiteverbindet dieses größere 365.partners-Netzwerk mit 365.hosting und zeigt einen wesentlich breiteren Adress-Fußabdruck als AS30344.
Diese gemeinsamen Identifikatoren unterstützen eine Betriebszugehörigkeit, wie sie von der Marke und den Registern öffentlich dargestellt wird. Sie rechtfertigen nicht die Verschmelzung von AS30344 und AS198178, die Zuweisung jedes Gruppenpräfix zu dieser Directory-Entität oder die Annahme, dass eine ASN automatisch eine Sicherung für die andere ist. Getrennte Routenursprünge können Kontakte und kommerzielle Kontrolle teilen, während sie unterschiedliche Upstreams, Einrichtungen und Betriebsrichtlinien verwenden. Eine Wiederherstellungsbehauptung benötigt ein angegebenes Failover-Design, nicht nur einen verwandten Namen.
Die vier IPv4-Blöcke teilen nicht dieselbe Registrierungshistorie
Die 1.024 von AS30344 ursprünglichen IPv4-Adressen sehen in einer Routingtabelle einheitlich aus: vier gleiche /24er. Ihre Registrierungshistorien sind nicht einheitlich. Dieser Unterschied ist eine nützliche Warnung davor, gerouteten Space als einen einzigen eigenen Pool zu behandeln.
ARIN hat 23.152.200.0/24im Mai 2023 direkt an 365.hosting zugewiesen. Der neuere 23.26.1.0/24 ist eine Zuweisung aus einem größeren Elternblock, registriert im Mai 2026. DerRIPE-Datenbankeintrag für 77.91.126.0/24nennt das NetzwerkWebhost_LLC, beschreibt 365.partners INC in den Bemerkungen und trägt denselben Sheridan-Kontakt. DerRIPE-Eintrag für 138.124.187.0/24nennt Webhost LLC in Moskau und besagt, dass das Subnetz zur Bereitstellung von virtuellen und dedizierten Servern verwendet wird, die von Kunden selbst verwaltet werden.
Diese Aufzeichnungen unterstützen ein Betriebsbild, in dem 365.hosting eine Mischung aus direkt zugewiesenen, zugeteilten und gruppenbezogenen Adressressourcen ursprüngt. Sie beweisen kein Eigentum an allen vier Blöcken im gewöhnlichen Sinne. Internet-Nummernressourcen werden unter Registerrichtlinien verwaltet und können neu zugewiesen, unterverteilt oder im Rahmen einer Vereinbarung geroutet werden. Die verschiedenen Organisationen und Bemerkungen sind Teil der Kontrollgrenze, kein bürokratisches Ärgernis, das beseitigt werden muss.
Reverse-DNS liefert begrenzte Hinweise auf die Nutzung.IPinfos Ansicht von 23.152.200.0/24zeigte die meisten Adressen mitwebhost1.net-statischen Namen und identifizierte ns1.365.hosting, ns2.365.hosting und den Haupt-Hostnamen von 365.hosting. SeineAnsicht von 77.91.126.0/24enthieltvm.365.hostingneben ähnlichenwebhost1.net-Namen. DieAnsicht von 138.124.187.0/24zeigtemail.365.hostingund weitere Reverse-Einträge im WebHOST1-Stil.
Dies ist ein starkes Indiz dafür, dass die Marke und die ältere WebHOST1-Betriebsumgebung eine gemeinsame Kontrolloberfläche teilen. Es ist ein schwaches Indiz für die Identität einzelner Kunden, die Serveranzahl oder den physischen Standort. Reverse-Namen können nach Umzügen bestehen bleiben, automatisch generiert werden oder auf eine Verwaltungskonvention statt auf ein Gebäude verweisen. Sie sollten nicht in ein Inventar von 1.024 aktiven Servern umgewandelt werden.
Routenautorisierung ist besser als Routenredundanz
Die vier IPv4-Ankündigungen hatten zum überprüften Zeitpunkt eine nützliche Sicherheitseigenschaft. RIPEstats RPKI-Validator gabvalidzurück für23.152.200.0/24,23.26.1.0/24,77.91.126.0/24und138.124.187.0/24, wenn sie von AS30344 ursprüngt wurden. Das bedeutet, dass vertrauende Netzwerke, die Routenursprungsvalidierung verwenden, kryptografische Autorität hatten, diese ASN-Präfix-Paarung zu akzeptieren.
Die IPv6-Route war anders. Der Validator gabunknownzurück für2602:2d3::/40, weil er keine validierende ROA in dieser Antwort fand. Unknown ist nicht invalid. Es bedeutet, dass die Routenursprungsvalidierung keine positive Autorisierung für dieses Paar lieferte. Die Unterscheidung ist für die Sicherheitslage wichtig, aber weder ein gültiger noch ein unbekannter Status sagt etwas über Bandbreite, Überlastung, Einrichtungsstrom oder Kunden-Failover aus.
RPKI ist daher eine Routing-Integritätskontrolle, kein Redundanzmechanismus. Eine perfekt autorisierte Route kann immer noch verschwinden, wenn ein Router ausfällt, ein Transitvertrag ausläuft, eine Glasfaser durchtrennt wird oder eine Wartungsänderung schiefgeht. Sie kann sichtbar bleiben und dennoch Paketverluste erleiden. Umgekehrt kann eine Route mit einem sichtbaren Nachbarn beträchtliche Reichweite vom globalen Netzwerk dieses Nachbarn erben, aber sie hängt dennoch von der kommerziellen und technischen Übergabe zwischen den beiden Systemen ab.
Die öffentliche Topologie unterstützt Vorsicht eher als Alarm. Routenkollektoren beobachten nicht jede private Verbindung, und eine Backup-Sitzung kann konfiguriert, aber inaktiv sein. Ein zweiter Carrier kann auch auf Layer 2 existieren, während AS52000 der einzige BGP-Nachbar bleibt. Die Beweise können nicht beweisen, dass es keinen versteckten oder kalten Standby gibt. Sie können beweisen, dass in der RIPEstat-Ansicht vom 15. Juli kein zweiter AS-Nachbar sichtbar war und dass das Unternehmen keinen Test veröffentlicht hatte, der einen solchen nachweist.
MIRhosting ist ein bedeutendes Netzwerk, bleibt aber das sichtbare Scharnier
AS52000 ist kein kleiner Ein-Carrier-Endpunkt.MIRhostings Unternehmensseitelistet mehr als zehn Rechenzentrumsstandorte in Europa, den USA und Asien auf, darunter Secaucus und 60 Hudson Street in New York, mehrere niederländische Standorte, Frankfurt und Mumbai.PeeringDBs AS52000-Eintragbeschreibt ein globales Netzwerk mit 1-5 Tbps Verkehr, einer offenen Peering-Politik, mehreren Exchanges und Einrichtungen sowie 24/7 NOC- und Missbrauchskontakten.BGP.toolslistet mehrere Upstreams auf, darunter Arelion, GTT, Cogent und Tata, sowie Exchange-Verbindungen.
Diese Breite reduziert die Versuchung, „ein AS-Nachbar“ mit „einem physischen Kabel zum gesamten Internet“ gleichzusetzen. MIRhosting kann AS30344 über ein Netzwerk mit eigenen redundanten Routern, Upstreams und Standorten transportieren. Das IPinfo-Traceroute-Beispiel erreichte eine AS30344-Adresse über einen in der Nähe von New York identifizierten MIRhosting-Router, konsistent mit einem US-Servicepfad. Doch dies legt nicht offen, wie viele Ports AS30344 mit AS52000 verbinden, ob diese Ports in verschiedene Gebäude führen oder ob niederländische und US-Dienste separate Übergaben nutzen.
Das Scharnier bleibt real. Wenn jeder extern sichtbare Pfad für AS30344 davon abhängt, dass AS52000 seine Routen akzeptiert und verbreitet, dann können ein Richtlinienfehler, eine kommerzielle Aussetzung, ein Route-Leak-Filter, eine DDoS-Reaktion oder ein gemeinsamer Steuerungsebenenausfall an dieser Grenze alle vier IPv4-Präfixe und das IPv6-Präfix gemeinsam betreffen. Die Upstream-Diversität von MIRhosting schützt nicht automatisch vor einem Ausfall, der spezifisch für die Beziehung AS30344-AS52000 ist.
Kunden benötigen eine präzisere Antwort als das Wort „redundant“. Nützliche Beweise würden einen zweiten aktiven Transit-AS, Routing-Kollektor-Verlauf, der beide Pfade zeigt, separate Standort-Querverbindungen, Portkapazität, Failover-Testdaten und den Nachweis umfassen, dass Service-Präfixe erreichbar bleiben, nachdem eine der Übergaben deaktiviert wurde. Nichts davon wurde in dem öffentlichen Material gefunden, das für dieses Profil überprüft wurde. Das Netzwerk sollte daher als aktiv und global erreichbar beschrieben werden, mit nur einer öffentlich beobachteten Upstream-Beziehung.
Das Secaucus-Label hat den Betreiber überlebt
Das US-Produkt ist in einer Hinsicht physisch spezifisch. Die365.hosting New Jersey Ankündigungvom 7. März 2026 besagt, dass sich seine NVMe-Cloud-Server in „vXchnge Secaucus“ befinden, und beschreibt eine 54.121 Quadratfuß große Einrichtung in der Nähe von New York City. Die Seite für dedizierte Server nennt den Standort vXchnge NJ01. Dies gibt Kunden mehr als eine generische „USA“-Region: Es verweist auf Secaucus, New Jersey.
Der Betreibername ist veraltet, aber das öffentliche Akquisitionsdatum selbst benötigt einen Vorbehalt.H5s Live-Übernahmeansageist vom 31. Januar 2021 datiert, währendRechenzentrum Dynamics‘ zeitgenössische Bestätigungvom 31. Januar 2022 datiert ist. Der einjährige Quellenkonflikt verhindert eine genauere Altersangabe; beide Daten liegen mindestens vier Jahre vor der 365.hosting-Startmitteilung vom 7. März 2026. Dieaktuelle H5-Einrichtungsseitelistet sein Rechenzentrum in New Jersey unter 200B Meadowlands Parkway, Secaucus, beschreibt es als Tier-III-Einrichtung mit mehr als 38.000 Quadratfuß und bewirbt es für die Geschäftskontinuität in New York.PeeringDBs Einrichtungseintragnennt es H5 Data Centers Secaucus (NJ01), gibt dieselbe Adresse an und führt „vXchnge Secaucus (NJ01)“ nur als alternativen historischen Namen.
Die Diskrepanz beweist nicht, dass die Server von 365.hosting das Gebäude verlassen haben oder der Dienst nicht verfügbar ist. Eine Kundenvereinbarung und ein Rack können eine Einrichtungsverkauf überstehen. Sie zeigt jedoch, dass die öffentliche Beschreibung des Unternehmens nicht auf den aktuellen Betreiber aktualisiert wurde. Das schwächt das Vertrauen in benachbarte Behauptungen, die schwerer zu überprüfen sind, wie z. B.
welche Partei Remote-Hands bereitstellt, welche Service-Level-Vereinbarung gilt, wer bei einem Einrichtungsvorfall eskaliert wird und ob die angegebenen 54.121 Quadratfuß die Grundfläche des Gebäudes, die ehemals vermarktete Fläche oder die aktuelle vermietbare Fläche beschreiben.
Es ändert auch die vertragliche Abhängigkeit. Wenn H5 nun den Standort kontrolliert, während 365.hosting Server oder Racks kontrolliert und MIRhosting den sichtbaren Netzwerkpfad bereitstellt, dann hängt ein Kunde von mindestens drei Betriebsebenen ab. H5 unterhält Gebäudezugang, Strom, Kühlung und Einrichtungsverfahren. 365.hosting stellt den Serverdienst bereit und unterstützt ihn. MIRhosting trägt die sichtbare BGP-Beziehung. Zusätzliche Hardware-Lieferanten, Zahlungsabwickler und Verwaltungsplattformen sitzen hinter diesen Ebenen.
Kein hier überprüfter öffentlicher Vertrag zeigt, welche Ebene dem Endkunden eine Abhilfe schuldet, wenn zwei Ebenen sich über die Ursache eines Ausfalls uneinig sind.
Die sicherste Standortaussage ist eng: 365.hosting vermarktet öffentlich US-Server in einer Secaucus-Einrichtung, die historisch als vXchnge NJ01 bekannt ist; H5 präsentiert derzeit den Standort 200B Meadowlands Parkway als sein New Jersey-Rechenzentrum. Öffentliche Beweise identifizieren nicht 365.hostings Rack, installierte Last, Käfig, aktuelle Querverbindungen oder verbleibende verkaufbare Kapazität darin.
Der niederländische Standort wird nur bis zur Facility-Gruppe genannt
Das Niederlande-Angebot ist ähnlich real, aber geografisch weniger präzise. Die365.hosting Niederlande-Startmitteilung, ebenfalls vom 7. März, besagt, dass virtuelle Server in einem Serverius-Rechenzentrum verfügbar wurden. DieNiederlande-VPS-Seiteenthält veralteten WebHOST1-Text: Sie sagt, dass WebHOST1 den Dienst anbietet und eigene Geräte in einem Serverius-Rechenzentrum nutzt. Das ist eine WebHOST1-Behauptung, die auf der 365.hosting-Oberfläche erscheint, kein Beweis dafür, dass 365.hosting die Geräte besitzt. Die Seite beschreibt auch KVM-Virtualisierung, SSD-Speicher mit RAID10, einen 100-Mbit/s-Plan-Kanal und eine 30-tägige Rückerstattung. Die Seite für dedizierte Server erhöht den beworbenen Kanal auf 1 Gbit/s für die aufgeführte Hardware.
Serverius ist auch nicht mehr das aktuelle eigenständige öffentliche Label.Kolos Übergangsseitesagt, dass Serverius und Fuzion nun unter dem Namen Kolo firmieren, mit denselben Standorten und Dienstleistungen, und dass die einheitliche Marke offiziell am 17. Juli live geht.Kolos Niederlande-Portfoliolistet vier Standorte: NL1 Dronten, NL2 Meppel, NL3 Apeldoorn und NL4 Amsterdam. Dies sind Behauptungen der Kolo-Plattform, keine Karte der Ausrüstung von 365.hosting. Die 365.hosting-Seite sagt nicht, welche Einrichtung, welcher Raum oder welches Rack den relevanten Dienst beherbergt, und kein öffentlicher Querverbindungseintrag verbindet AS30344 mit einem bestimmten Kolo-Standort.
Diese fehlende Standortkennung schränkt sowohl die Lokalität als auch die Wiederherstellungsanalyse ein. Ein Kunde, der sich für „Niederlande“ entscheidet, kann vernünftigerweise erwarten, dass die Datenverarbeitung im Land stattfindet, wenn der Dienst wie vermarktet betrieben wird. Die öffentliche Seite legt nicht offen, ob Backups im selben Gebäude, an einem anderen Serverius-Standort, in den USA oder auf einer Verwaltungsplattform an einem anderen Ort verbleiben.
Sie sagt nicht, ob ein ausgefallener niederländischer Host in Secaucus wiederhergestellt werden kann, ob eine Kunden Zustimmung für einen solchen Umzug erforderlich ist oder wie lange die Image- und Datenübertragung dauern würde.
DieNOC-Meldungen, die noch auf der Serverius-Domain bedient werden, veranschaulichen, warum diese Unterscheidungen wichtig sind, und verwenden bereits KoloDC-Labels. Im Jahr 2026 veröffentlichte die Site Kühlungswartung an NL1 Dronten und Dark-Fiber-Arbeiten zwischen NL1 Dronten und NL2 Meppel und erklärte, dass alternative Fasern übernehmen sollten, während vor möglichen Latenzen oder Paketverlusten während der Routenwiederkonvergenz gewarnt wurde. Das ist eine gesunde betriebliche Offenlegung durch das Facility-Netzwerk. Es beweist nicht, dass 365.hosting einen der betroffenen Standorte belegte oder am alternativen Pfad teilnahm. Es zeigt einfach die Art von physischer Wartung, die ein „Niederlande“-Label verbirgt.
Die Evidenzstufe für die Niederlande ist daher mittel für die landesweite Dienstverfügbarkeit und schwach für die genaue Asset-Platzierung. Die Produktseiten machen das Angebot glaubwürdig, während der Übergang von Serverius zu Kolo die aktuelle Facility-Plattform-Identität etabliert, ohne den Dienst zu lokalisieren. Die Quellen legen keine Straßenadresse, installierten Bestand, Stromzuteilung, Rack-Eigentum oder standortübergreifende Replikation für 365.hosting fest.
Kapazitätskarten sind keine Kapazitätsaussage
Der Shop veröffentlicht nützliche kommerzielle Einheiten: Prozessortyp, Speicher, Festplatte, Kanal, Traffic-Allowance, IPv4-Anzahl, Einrichtungszeit und Abrechnungszeitraum. Dies sind Kundenansprüche, wenn sie im Rahmen des geltenden Vertrags geliefert werden. Sie können nicht addiert werden, um die Kapazität des Anbieters zu berechnen, da die Website die Anzahl der verfügbaren Server oder Virtualisierungshosts hinter jeder Karte nicht veröffentlicht.
Ein niederländischer VPS-Plan wurde bei der Überprüfung als nicht auf Lager angezeigt. Das ist ein kleines, aber wertvolles Betriebssignal. Es deutet darauf hin, dass der Katalog einen Verfügbarkeitsstatus anzeigen kann, anstatt jede Konfiguration ohne Einschränkung zu akzeptieren. Es zeigt auch, warum eine Planspezifikation keine installierte Kapazität ist. Ein 20-GB-Festplattenanspruch und ein 100-Mbit/s-Port bei einem nicht verfügbaren Plan bieten einem Neukunden keinen nutzbaren Dienst.
Die Seiten für dedizierte Server geben eine Einrichtungszeit von fünf bis zehn Tagen an. Dies kann eine normale Bereitstellung darstellen, keinen Mangel, aber es offenbart die Rolle des Hardwarebestands und der Arbeitskraft. Wenn ein Produktionsserver ausfällt, ist die relevante Frage nicht, ob eine passende SKU auf der Website existiert. Es ist, ob ein gleichwertiges Chassis, Speichersatz, NVMe-Gerät, Stromzuteilung und Techniker am selben Standort unter einem vereinbarten Austauschziel verfügbar sind.
Keine überprüfte Seite legte Rack-Anzahl, Serveranzahl, Hypervisor-Anzahl, aggregierte CPU-Kerne, installierten Speicher, Ersatzlaufwerkbestand, versorgte Kapazität, gebuchte Bandbreite, Überbuchung, verkauften Prozentsatz oder reservierten Bestand offen. Die Homepage-Behauptung eigener Racks bleibt quantifiziert. Die Größe der H5-Einrichtung und der Maßstab der Kolo-Plattform gehören diesen Facility-Betreibern; sie können nicht 365.hosting zugeordnet werden. Ein Mieter kann einen einzigen Schrank in einem großen Rechenzentrum belegen, und die Größe des Gebäudes sagt nichts über die freie Kapazität des Mieters aus.
Sogar die 1.024 gerouteten IPv4-Adressen sind keine Servergrenze. Ein Host kann viele Adressen tragen; eine Adresse kann viele virtuelle Hosts bedienen; Adressen können reserviert, geroutet aber ungenutzt, für Netzwerkgeräte verwendet oder Kunden zugewiesen sein. DieIP2Location AS30344-Zusammenfassungbestätigt die vier /24er und den einzelnen MIRhosting-Upstream, aber ihre Adresssumme ist ein Netzwerkressourcenmaß, kein Rechenmaß.
Die Kapazitätsschlussfolgerung ist daher explizit: Aktuelle Angebote und geroutete Ressourcen demonstrieren einen betriebenen Dienst, aber installierte, verkaufte, Ersatz- und Ausfallkapazität sind nicht öffentlich quantifiziert. Jede stärkere Zahl wäre erfunden.
Eine 99,9-Prozent-Behauptung braucht einen Nenner
Die Startseite von 365.hosting sagt, dass es über fünf Jahre eine Verfügbarkeit von 99,9 Prozent erreicht hat, obwohl dieselbe Seite sagt, dass die Marke seit 2022 tätig ist. Bis Juli 2026 würde eine vollständige Fünf-Jahres-Messung unter dieser Marke vor das angegebene Betriebsdatum zurückreichen. Die Zahl kann eine ältere WebHOST1-Diensthistorie einschließen, gerundetes Marketing-Material sein oder einen anderen Startpunkt verwenden. Die Seite erklärt den Nenner nicht.
Bei 99,9 Prozent erlaubt die Arithmetik etwa 8 Stunden und 46 Minuten Ausfallzeit in einem 365-Tage-Jahr, wenn kontinuierlich gemessen. Diese Berechnung ist kein Beweis für tatsächliche Ausfallzeiten. Sie zeigt nur, warum der Umfang wichtig ist. Website-Verfügbarkeit, Control-Panel-Verfügbarkeit, Netzwerkerreichbarkeit, VM-Stromzustand und Anwendungsantwort können jeweils einen anderen Prozentsatz ergeben. Geplante Wartung, höhere Gewalt und kundenverursachte Vorfälle können von einer vertraglichen SLA ausgeschlossen sein, auch wenn sie für Benutzer sichtbar bleiben.
Die öffentlicheSeite für technische Arbeitenpräsentierte in der überprüften Ansicht kein klares englischsprachiges Vorfallarchiv. Die Kontaktseite sagt, dass Kunden die schnellste Antwort über das Billing-Panel-Anfragesystem erhalten, und erwähnt separat einen Online-Support-Chat von 9 bis 21 Uhr, während breitere Seiten 24/7-Support bewerben. Diese Aussagen können koexistieren, wenn Tickets rund um die Uhr überwacht werden, der Chat jedoch nicht. Sie veröffentlichen keine Reaktions- oder Wiederherstellungsziele.
Ohne eine Vorfallhistorie und dienstspezifische SLA sollte die Verfügbarkeitsbehauptung attribuiert bleiben. Sie kann nicht verwendet werden, um abzuleiten, dass beide Länder, jedes Produkt, AS30344 oder die Verwaltungsplattform das gleiche Ergebnis erzielt haben. Sie kann auch keine Erholung von den hier relevantesten Ausfallmodi demonstrieren: Verlust von AS52000, Verlust einer Rack-Stromversorgung, Austausch eines dedizierten Servers, Wiederherstellung eines Kunden-Images oder Verschieben einer Arbeitslast über Grenzen hinweg.
Nützliche Betriebsoffenlegung würde Dienstverfügbarkeit nach Region, Wartungsausschlüsse, Beginn- und Endzeiten von Vorfällen, betroffene Komponenten, Grundursache, Behebung und ob vertragliche Gutschriften ausgestellt wurden, veröffentlichen. Diese Beweise waren nicht verfügbar. Das Fehlen bedeutet nicht, dass Ausfälle aufgetreten sind. Es bedeutet, dass der beworbene Prozentsatz nicht das analytische Gewicht einer gemessenen Zuverlässigkeitsbilanz tragen kann.
Die Steuerungsebene reicht zurück zu WebHOST1
Die öffentliche Site legt eine zweite Konzentration offen, die leichter zu übersehen ist als BGP. IhreHomepage HTMLstellt eine Vorverbindung zuapi.webhost1.ruher, ihr Inhalt und ihre Navigation verwenden WebHOST1-Routen, und große Teile ihrer Produktdaten und Verwaltungsreferenzen tragen WebHOST1-Hostnamen. Das Reverse-DNS über AS30344 verwendet ebenfalls wiederholtwebhost1.net. Die365.hosting Sitemapverweist aufwebhost1.ru-Seiten anstatt auf einen sauberen, markenspezifischen Satz von URLs.
Dies unterstützt die Kontinuität mit einer etablierten Betriebsplattform. Es kann 365.hosting ermöglichen, Abrechnungs-, Bereitstellungs-, Support-Wissens- und Serververwaltungssysteme wiederzuverwenden, anstatt sie von Null aufzubauen. Es schafft auch eine Ausfall- und Governance-Grenze. Ein Kunde kann eine laufende VM haben, deren öffentliche Pakete durch AS30344 fließen, während er dennoch für Bestellung, Zahlung, Passwort-Reset, Tickets, Konsolenzugriff oder Automatisierung von einer anderen Domain und Plattform abhängt.
Die365.hosting Dokumentenseitezeigte Links zu einem öffentlichen Angebot, Kontoladegrenzen und Bedingungen für personenbezogene Daten, aber die überprüfte englische Seite legte keinen vollständigen, leicht prüfbaren Firmennamen und Serviceplan offen. Der Abschnitt mit Bankverbindungen auf der Kontaktseite erschien in der gerenderten englischen Ansicht ebenfalls unausgefüllt. Das macht es schwierig, anhand der öffentlichen englischen Oberfläche zu bestimmen, welche genaue juristische Person einen Kunden abrechnet, welche Bedingungen für die US- und niederländischen Produkte gelten und ob Webhost LLC, 365.partners INC oder ein anderer Verbundener eine bestimmte Verpflichtung erfüllt.
Dies ist kein Beweis dafür, dass Verträge fehlen; Kunden können während des Bezahlvorgangs vollständige Bedingungen erhalten. Es ist ein Beweis dafür, dass ein externer Kunde die vollständige Vertragskette nicht überprüfen kann, bevor er in den privaten Kaufprozess eintritt. Für Datensouveränität, Eskalation von Vorfällen und Insolvenzplanung ist diese Unterscheidung wichtig. Die Partei, die das Control-Panel betreibt, ist möglicherweise nicht die Partei, die den Rack-Mietvertrag hält oder die Route ursprüngt.
Ein robuster Ausstiegsplan muss beide Ebenen berücksichtigen. Datenbackups ohne Anmeldeinformationen, Images, DNS-Zonen und Domain-Transfer-Zugriff reichen möglicherweise nicht aus. Umgekehrt ist der Control-Panel-Zugriff von begrenztem Wert, wenn sich die einzige Kopie der Kundendaten auf nicht verfügbarem Speicher befindet. Öffentliches Material spezifiziert keine Exportformate, API-Garantien, Account-Übergabeverfahren oder Notfallzugriff, falls die normale Plattform ausfällt.
Ausfall beginnt dort, wo das Eigentum den Besitzer wechselt
Der erste Ausfallpfad ist die sichtbare Routengrenze. Wenn AS30344 seine Beziehung zu AS52000 verliert, könnten alle fünf beobachteten Ankündigungen gemeinsam unerreichbar werden, es sei denn, ein nicht offengelegter Alternativpfad übernimmt. Kunden, die Adressen verwenden, die an anderem Ort ursprüngt werden, könnten sich anders verhalten, weshalb die Zuordnung von Dienst zu Präfix wichtig ist. Die öffentliche Aufzeichnung liefert sie nicht.
Der zweite Pfad ist einrichtungsspezifisch. In Secaucus kontrolliert H5 die Gebäudeebene, die nun einem historischen vXchnge-Namen zugeschrieben wird. In den Niederlanden sagt das Angebot immer noch Serverius, während die öffentliche Facility-Plattform unter den Namen Kolo wechselt, und der genaue Standort ist nicht offengelegt. Eine Unterbrechung der Versorgung, ein UPS-Fehler, ein Kühlungsproblem, eine Zugangsbeschränkung oder eine Einrichtungswartung können den Kundendienst beeinträchtigen, selbst wenn das eigene Personal und die Router von 365.hosting gesund sind.
Der dritte ist Rack- und Hardwareausfall. „Eigene Racks“ konzentrieren nützliche Kontrolle, schaffen aber auch Verantwortung für Stromverteilung, Top-of-Rack-Switching, Hypervisoren, Laufwerke und Ersatzteile. Ein Fenster von fünf bis zehn Tagen für die Einrichtung neuer Server kann nicht als Austauschziel behandelt werden. Kunden müssen wissen, ob ausgefallene Festplatten gespiegelt sind, ob ein ausgefallener Host automatisch einen VM-Neustart an anderer Stelle auslöst, ob sich Backup-Daten in einer separaten Fehlerdomäne befinden und wie schnell ein dedizierter Server wieder aufgebaut werden kann.
Der vierte ist der operative Support. Öffentliche Texte versprechen rund-um-die-Uhr-Hilfe, während die Chat-Zeiten enger sind und Ticket-Ziele unveröffentlicht sind. Ein schwerwiegender Vorfall kann verlängert werden, wenn der Hosting-Anbieter, der Upstream und der Facility-Betreiber jeweils auf die Diagnose der anderen Partei warten. Benannte Eskalationspfade und gemeinsame Vorfallverfahren sind wertvoller als ein allgemeines Support-Abzeichen.
Der fünfte ist die Abrechnung und Account-Kontrolle. Gemeinsame WebHOST1-Infrastruktur, Zahlungs-Skripte von Drittanbietern und private Abrechnungs-Panels können Service-Abhängigkeiten werden. Ein Zahlungsstreit, ein Betrugsvorbehalt, eine abgelaufene Karte oder eine Account-Kompromittierung kann den Verwaltungszugriff entfernen, selbst während die Hardware läuft. Öffentliche Seiten nennen keine Gnadenfrist, Aussetzungssequenz, Notfallkontakt oder Exportrecht.
Der sechste ist die Migration. Die Site bewirbt kostenlose Migration und eine 30-tägige Rückerstattung für einige Dienste. Das senkt die anfänglichen Wechselkosten, beweist aber keine schnelle Ausreise. Große Datensätze, private Konfigurationen, dedizierte IP-Reputation, DNS-Timing und Anwendungsabhängigkeiten können die Migration langsamer machen als die Serverbereitstellung. Keine überprüfte Seite verspricht portable VM-Images, Bulk-Export-Bandbreite, beibehaltene Snapshots nach Kündigung oder unterstützte Evakuierung während eines Einrichtungsproblems.
Dies sind keine Vorwürfe des Versagens. Es ist die Abhängigkeitskette, die durch die öffentliche Betriebsvereinbarung entsteht. Der Schwachpunkt ist nicht unbedingt eine Komponente; es ist die Übergabe zwischen Komponenten, deren Verträge und getestetes Wiederherstellungsverhalten nicht offengelegt sind.
Zwei Verkaufsländer ergeben noch kein Wiederherstellungspaar
Das Vorhandensein sowohl von US- als auch niederländischen Angeboten lädt zu einer häufigen Annahme ein: Wenn ein Standort ausfällt, können Arbeitslasten zum anderen verschoben werden. Die öffentlichen Seiten machen dieses Versprechen nicht. Sie verkaufen Standorte unabhängig. Sie beschreiben keinen Active-Active-Dienst, replizierten Speicher, gemeinsame Orchestrierung, gemeinsames privates Networking, DNS-Failover oder reservierte Standby-Kapazität.
Standortübergreifende Wiederherstellung würde auch eine rechtliche und Latenzgrenze überschreiten. Das Verschieben von Daten aus den Niederlanden nach New Jersey kann die anwendbare Gerichtsbarkeit, Kundenbenachrichtigungspflichten, den Übertragungsmechanismus und die Round-Trip-Verzögerung ändern. Ein Kunde, der die Niederlande für die europäische Verarbeitung ausgewählt hat, kann nicht davon ausgehen, dass eine Wiederherstellung in den USA akzeptabel ist. Das kontrollierte Thema Datensouveränität ist gerade deshalb relevant, weil der Standort Teil des Produkts ist, nicht weil die Beweise einen Compliance-Verstoß belegen.
Sogar innerhalb der Niederlande können die vier aufgeführten Einrichtungen von Kolo nicht als Redundanz von 365.hosting gezählt werden. Kolo bewirbt Multi-Site-Resilienz-Optionen, aber 365.hosting identifiziert seine Einrichtung nicht oder gibt an, dass Kundendaten zu einer anderen repliziert werden. Eine carrier-neutrale Halle schafft Optionen; sie schafft nicht automatisch einen zweiten vertraglichen Dienst.
Ebenso beweisen die Einrichtungen von MIRhosting in beiden Ländern nicht, dass AS30344 unabhängige Übergaben an beiden hat. Die BGP-Ansicht mit einem Nachbarn kann mehrere physische Verbindungen zum selben AS abdecken, oder sie kann eine abdecken. Öffentliche Daten unterscheiden sie nicht. Eine glaubwürdige Redundanzaussage würde die Standorte, Schaltkreise und Ausfalltests nennen, während legitime Sicherheitsdetails gewahrt bleiben.
Kunden sollten daher das Ländermentü als Platzierungswahl betrachten, nicht als Wiederherstellungsarchitektur. Diejenigen, die Kontinuität über Standortverlust hinweg benötigen, müssen dies explizit entwerfen und kaufen: Anwendungsreplikation, separate Anmeldeinformationen, unabhängiges DNS, Backups außerhalb des primären Accounts, getestete Wiederherstellung, Kapazitätsreservierungen und eine rechtliche Grundlage für den sekundären Standort. Das öffentliche Material des Anbieters zeigt nicht, dass diese Kontrollen standardmäßig enthalten sind.
Wer ist exponiert, wenn das System ausfällt
Die Behauptung „20.000+ Projekte“ auf der Startseite impliziert eine bedeutende Nutzerbasis, aber keine unabhängige Aufschlüsselung verbindet diese Zahl mit aktuellen AS30344-Diensten. Reverse-DNS und gehostete Domain-Beobachtungen bestätigen, dass der geroutete Space internetfähige Systeme trägt. Sie offenbaren nicht, ob diese Systeme zu kleinen Websites, Agenturen, Softwarediensten, Spielservern, Shops, internen Unternehmenswerkzeugen oder Infrastruktur-Resellern gehören.
Die Produktsprache verweist auf mehrere betroffene Gruppen. VPS-Kunden können Webanwendungen, Datenbanken, VPNs und Entwicklungsumgebungen verlieren, wenn ein Host oder eine Route ausfällt. Kunden dedizierter Server können mit einem längeren Hardware-Austausch konfrontiert sein, da ihre Umgebung an ein bestimmtes Chassis gebunden ist. Domain- und DNS-Kunden können auf einer Steuerungsebene betroffen sein, selbst wenn ihr Inhalt anderswo gehostet wird. Reseller können einen einzigen Upstream-Vorfall auf viele Endkunden verstärken, die möglicherweise noch nie von 365.hosting gehört haben.
Die Kundenauswirkung hängt auch von der Adresskontinuität ab. Das Verschieben einer Arbeitslast zu einem anderen Anbieter, ohne dieselbe IP zu behalten, kann Allowlists, Mail-Reputation, DNS-Caching, API-Integrationen und Sicherheitsregeln stören. Die vier /24er sind daher betriebliche Vermögenswerte, die über ihre numerische Größe hinausgehen. Dennoch sagt keine öffentliche Portabilitätsrichtlinie, ob ein Kunde eine Adresse mitbringen, sein eigenes Präfix ankündigen, eine IP während der Migration behalten oder BGP-Dienst erhalten kann.
Datenverlust und Nichtverfügbarkeit sind getrennte Ergebnisse. Ein Routenausfall kann intakte Daten unerreichbar machen. Ein Speicherausfall kann Daten zerstören, während das Netzwerk gesund bleibt. Eine Abrechnungssperre kann den Verwaltungszugriff blockieren, während öffentliche Dienste vorübergehend weiterlaufen. Die Wiederherstellungsplanung sollte identifizieren, welcher Zustand geschützt wird: Paketerreichbarkeit, VM-Strom, Datenhaltbarkeit, Verwaltungszugriff oder Anwendungskorrektheit.
Die begrenzte Offenlegung bedeutet, dass Kunden viel von dieser Widerstandsfähigkeit selbst bereitstellen müssen. Backups außerhalb des Anbieters, dokumentierte Wiederherstellungsschritte, sekundäres DNS, unabhängige Domain-Anmeldeinformationen, Überwachung von mehr als einem Netzwerk und geprobte Migration reduzieren die Abhängigkeit von Behauptungen, die nicht extern verifiziert werden können. Der Bedarf ist am größten für Kunden, deren eigene Benutzer davon ausgehen, dass der Kauf eines „Cloud“-Dienstes unsichtbares Failover beinhaltet.
Was die Beweise stützen und was nicht
Die Beweise stützen die Bezeichnung von 365.hosting als operierenden Hosting-Anbieter, der mit einem aktiven in den USA registrierten autonomen System verbunden ist. Seine Domain löst innerhalb von AS30344 auf. Seine IPv4-Präfixe werden angekündigt, der neueste Block trat sofort nach der Zuweisung in das Routing ein, Reverse-DNS zeigt Hosting-Nutzung, und Produktseiten akzeptieren ein detailliertes kommerzielles Vokabular von Prozessoren, Festplatten, Kanälen und Standorten. Dies ist materiell stärker als eine Verzeichniskarte, die nur aus einem Namen besteht.
Es stützt auch einen spezifischen Konzentrationsbefund. Im Schnappschuss vom 15. Juli hatten alle beobachteten AS30344-Routen einen sichtbaren AS-Nachbarn, MIRhosting AS52000. Vier IPv4-Ursprünge waren RPKI-valide; der IPv6-Ursprung war unbekannt statt ungültig. Der Routenbeweis sagt nichts über versteckte Backup-Links aus, aber es wurde kein öffentlicher Beweis für einen zweiten Transit oder getestetes Failover gefunden.
Die physischen Beweise stützen Secaucus auf Stadt- und Einrichtungsgeschichte-Ebene für das US-Angebot, mit einer Korrektur: H5, nicht vXchnge, präsentiert nun die Anlage 200B Meadowlands Parkway. Für das niederländische Angebot stützen sie ein veraltetes Serverius-Produktlabel und eine aktuelle Kolo-Plattform mit vier niederländischen Standorten, ohne Dronten, Meppel, Apeldoorn oder Amsterdam als Standort von 365.hosting zu identifizieren. Sie stützen Wyoming nicht als Serverstandort.
Die Kapazitätsbeweise stützen aktuelle Planspezifikationen und ein Fenster von fünf bis zehn Tagen für die Bereitstellung dedizierter Server. Sie legen keine installierten oder verfügbaren Serveranzahlen, Rack-Belegung, aggregierte Bandbreite, Strom, Ersatzbestand, verkauften Prozentsatz oder nutzbare Kapazität nach einem Ausfall offen. Die 99,9-Prozent- und Kunden-/Projektmetriken bleiben Marketing-Behauptungen ohne veröffentlichte Messdetails.
Die Unternehmensbeweise stützen eine öffentliche Zugehörigkeit zwischen 365.hosting, 365.partners und WebHOST1 durch gemeinsame Kontakte, Domains, Seiteninfrastruktur und Registereinträge. Sie machen nicht jede AS198178-Ressource zu einem Teil von AS30344 oder beweisen, dass ein anderes Gruppen-Netzwerk ein Standby ist. Sie legen auch nicht offen, welche Entität jedem Kunden den vollständigen Service schuldet.
Dies ist ein mittelstarker Netzwerkbefund und eine schwache bis mittlere Infrastrukturoffenlegung. Die Herabstufung ist beabsichtigt. Der Routenursprung und der Shop sind real; die genauen Betriebs- und Wiederherstellungsgrenzen bleiben zu undurchsichtig für eine stärkere Resilienzschlussfolgerung.
Der nächste Beweis sollte operativ sein, nicht werblich
Die einfachste Korrektur ist redaktionell: Aktualisieren Sie den Secaucus-Einrichtungsnamen und identifizieren Sie H5 als aktuellen Betreiber, während Sie die Rolle von 365.hosting und MIRhosting erläutern. Ein Kunde sollte nicht einen Launch-Post von 2026 mit der aktuellen Site-Identität von H5 und Akquisitionsquellen in Einklang bringen müssen, die die Transaktion auf entweder 2021 oder 2022 datieren. Die Niederlande-Seite sollte das Serverius-Label für den Kolo-Übergang aktualisieren und den relevanten Kolo-Einrichtungscode und die Stadt identifizieren.
Der nächste Schritt ist eine Service-zu-Infrastruktur-Matrix. Für jede US- und niederländische Produktfamilie könnte 365.hosting den Facility-Betreiber, die vertragsschließende Entität, den Routenursprung, die Upstreams, den Backup-Standort, den Support-Kanal und die geltende SLA angeben. Es muss keine Rack-Nummern oder sensible Topologie preisgeben. Es sollte klarstellen, ob der Kunde eine VM, ein dediziertes Chassis oder einen verwalteten Dienst kauft und welche Komponenten gemeinsam genutzt werden.
Für die Netzwerkresilienz würde eine datierte Failover-Notiz viel von der Unsicherheit beseitigen: die Anzahl der AS30344-Transit-Beziehungen, ob sie in separaten Einrichtungen enden, ob IPv4 und IPv6 denselben Schutz haben und der letzte erfolgreiche Routenentzugstest. Die Ein-Nachbar-Ansicht wäre dann als Kollektor-Begrenzung, beabsichtigtem Design oder echter Konzentration interpretierbar.
Für die Kapazität sind die nützlichen Metriken nicht die Gesamtadresszahl oder die Quadratmeterzahl der Einrichtung. Sie sind installierte Hosts, versorgte Racks, verfügbare Konfigurationen, Ersatzhardware, aggregierte gebuchte Bandbreite und Austauschziele. Der Status sollte zwischen Design, installiert, versorgt, in Betrieb, verkauft, reserviert und verfügbarer Kapazität unterscheiden. Ein Anbieter kann Bereiche oder Prozentsätze offenlegen, wenn genaue Zahlen geschäftlich sensibel sind.
Für die Wiederherstellung benötigen Kunden Wiederherstellungspunkt- und Wiederherstellungszeitziele, Backup-Fehlerdomänen, Image-Exportformate und einen dokumentierten Weg aus der Plattform. Grenzüberschreitende Wiederherstellung sollte Opt-in und rechtlich explizit sein. Eine 30-tägige Rückerstattung ist eine kommerzielle Zusicherung; sie ist kein Disaster-Recovery-Design.
Schließlich sollte die öffentliche Statusaufzeichnung Vorfälle und Wartungsarbeiten in konsistentem Deutsch führen, mit betroffenem Standort, Dienst, Start- und Endzeit, Auswirkung, Ursache und Behebung. Serverius demonstriert bereits den Wert dieser Praxis in seinen eigenen NOC-Meldungen. Die Ausweitung dieser Klarheit auf die Kundenschicht von 365.hosting würde mehr für das Vertrauen tun als ein weiteres generisches Verfügbarkeitsabzeichen.
Bis diese Beweise erscheinen, bleibt die genaueste Lesart eng. 365.hosting hat echten Adressraum in Betrieb genommen, einschließlich eines neu zugewiesenen /24. Es verkauft identifizierbare Hardware in zwei Ländern und scheint in eine breitere Hosting-Gruppe eingebettet zu sein. Aber in der überprüften Ansicht vom 15. Juli traf die neueste Route das öffentliche Internet immer noch durch einen sichtbaren Upstream, das US-Einrichtungslabel war mindestens vier Jahre hinter seinem Betreibereintrag zurück, und das niederländische Label löste sich nicht zu einem der vier Kolo-Standorte auf.
Weder der Verkaufskatalog noch die Routingtabelle beweisen, wie viel Kapazität den Ausfall eines Racks, Standorts, Vertrags oder der Steuerungsebene übersteht.