[mijn.host] Ervaringen & Discussie

[webdesigner]

Hier zijn er nog steeds problemen met SSL certificaten die niet werken. Dus al bijna 2 dagen websites offline.

[Nachtkastje]

webdesigner schreef op dinsdag 13 oktober 2026 @ 10:19:
Hier zijn er nog steeds problemen met SSL certificaten die niet werken. Dus al bijna 2 dagen websites offline.

Vrijwel al mijn klanten zijn weer live, als je SSL het nog niet doet moet je handmatig inloggen en even Wildcard uitzetten en handmatig provisionen. Daarna werkt het weer.

Wel heb ik nog steeds dat de mail gewoon niet werkt en dus niet binnenkomt, waarbij partijen zelfs bounces krijgen nu helaas...

[Ernemmer]

Ballantines schreef op dinsdag 13 oktober 2026 @ 07:20:
Hier ook alles nog leeg in de reseller hosting. Geen idee hoe ik dit moet uitleggen aan mijn klanten.

Geachte klant, door een onvoorziene technische storing is uw website momenteel onbereikbaar, wij doen ons uiterste best om het probleem zo snel mogelijk te verhelpen. Als er nieuws te melden is ontvangt u dit zo spoedig mogelijk.

Met vriendelijke groet

[webdesigner]

Nachtkastje schreef op dinsdag 13 oktober 2026 @ 10:21:
[...]

Vrijwel al mijn klanten zijn weer live, als je SSL het nog niet doet moet je handmatig inloggen en even Wildcard uitzetten en handmatig provisionen. Daarna werkt het weer.

Wel heb ik nog steeds dat de mail gewoon niet werkt en dus niet binnenkomt, waarbij partijen zelfs bounces krijgen nu helaas...

Ik kreeg reactie van mijn.host. Doordat er enorm veel sites nu allemaal SSL certificaten aanvragen, gaat dit proces traag. Let's Encrypt laat maximaal 300 aanvragen per uur toe. Als je weet hoevel sites ze crammen op 1 server, zou ik zeggen: nog niet je adem inhouden tot alle SSL opnieuw werkt... Dat is de reden waarom nog veel sites bij mijn.host SSL errors hebben helaas.

[ Voor 5% gewijzigd door webdesigner op 13-10-2026 10:44 ]

[webdesigner]

True schreef op maandag 12 oktober 2026 @ 23:46:
[...]


Zullen we anders gewoon bij de feiten blijven? Of als je verdenkingen hebt daar bronnen en bewijzen voor delen, anders blijft het enkel de onderbuik die spreekt.

Denk jij dat de feiten hier correct zijn dat mijn.host aanhaalt ? "door een storing in onze serveropslag ...". Dat vind ik een heel vage reden. Dat een hostingbedrijf van die grootte bijna 2 dagen websites, mailboxen en SSL's niet allemaal online krijgt, doet me vermoeden dat er meer aand de hand is. Of ben jij @True iemand die blindelings alles gelooft wat bedrijven online vermelden ? Andere hostingbedrijven kunnen bij een crash van een opslag alles binnen de kortste keren weer online krijgen. Zie hoeveel hackings er de laatste weken overal gebeuren, tot koelsystemen van vriezers in de grootwarenhuizen (al wou men hier waarschijnlijk koelsystemen van datacenters treffen, maar dat is gewoon speculatie).

[fritsjof]

e.dewaal schreef op dinsdag 13 oktober 2026 @ 08:18:
Ik heb recent een aantal domeinnamen verhuisd naar mijn.host vanwege de goede reviews en het feit dat mijn.host onhafhankelijk is. Dat proces ging erg makkelijk. Ik sta nu op het punt om de hosting te kopen, maar vind dat toch spannend als ik zie hoe dit incident wordt opgepakt.

Het begon prima: korte berichtgeving dat er een storing is, vervolgens iets meer duidelijkheid, vervolgens 2× een update met daarin een tijdstip waarop we de volgende statusupdate konden ontvangen. Toen twee uur later een update dat de VPS's hersteld zijn en de shared hosting op 70%, gevolgd door doodse stilte sinds gisteren 16:18u op de statuspagina.

Ik snap dat ze druk zijn met herstellen, maar als het van 13:00u 40% restore, naar 16:18u 70% restore gaan, zou je verwachten dat rond 20:00u 100% restore wel zou moeten zijn.

Als ik zelf mijn kritieke hosting daar ook zou hebben, had ik inmiddels zelf een back-up teruggezet bij een andere partij en (tijdelijk) door middel van DNS de domeinnaam naar die hosting verwezen.

Op de website noemen ze overigens:


[...]

Ik ben benieuwd of dat nu in werking gaat treden voor de betreffende klanten.

Ik denk niet dat iemand echt gebaat is bij een maand gratis hosting - veel liever heb ik dat mijn websites weer online komen. Gelukkig is het hobby, als ik mijn core business daar had draaien dan zou ik er wel anders bijzitten nu. Sterkte voor iedereen die z'n productie heeft draaien daar en nu aan klanten moet uitleggen dat je er niks aan kan doen...

[True]

webdesigner schreef op dinsdag 13 oktober 2026 @ 10:48:
[...]

Denk jij dat de feiten hier correct zijn dat mijn.host aanhaalt ? "door een storing in onze serveropslag ...". Dat vind ik een heel vage reden. Dat een hostingbedrijf van die grootte bijna 2 dagen websites, mailboxen en SSL's niet allemaal online krijgt, doet me vermoeden dat er meer aand de hand is. Of ben jij @True iemand die blindelings alles gelooft wat bedrijven online vermelden ? Andere hostingbedrijven kunnen bij een crash van een opslag alles binnen de kortste keren weer online krijgen. Zie hoeveel hackings er de laatste weken overal gebeuren, tot koelsystemen van vriezers in de grootwarenhuizen (al wou men hier waarschijnlijk koelsystemen van datacenters treffen, maar dat is gewoon speculatie).

Als ik eerlijk en objectief probeer te kijken zou ik zeggen dat mijn.host in over their head is de communicatie is zoals het vaker bij hen is netjes en duidelijk, maar frequentere updates zou absoluut beter geweest zijn, ook als er geen voortgang/melding van voortgang gegeven kan worden.

Dat gezegd hebbende ben ik de afgelopen jaren echt wel positief verbaasd over hen, ik denk dan eigenlijk ook wel dat we de komende dagen een post-mortem van ze zullen zien die ze ook publiceren. Dat zou ik weer erg treffend vinden en passend vinden.

Ze mogen het vertrouwen wel weer iets terugwinnen na zo'n klap en acceptabel hoeft dit soort downtime niet te zijn. Ik denk ze vooral gaan twijfelen aan hun storage/hosting partner óf gaan twijfelen aan hun contracten, maar dat moeten we maar eens zien in hoeverre ze hier over informatie willen en gaan delen.

PS ik snap overigens niet waarom jij dit zo op de man wilt spelen, dat is toch nergens voor nodig.

[ Voor 3% gewijzigd door True op 13-10-2026 11:07 ]

[Yariva]

Laten we het netjes houden. Gissen en speculeren kan tot op zekere hoogte prima maar op de man spelen zien wij liever niet.

[Drardollan]

Om heel eerlijk te zijn vind ik het ook allemaal wel een beetje zorgelijk. Mijn.Host is een fijne partij om mee samen te werken. De prijzen zijn goed, de techniek over het algemeen betrouwbaar en de communicatie helder. Snap ook dat er een probleem kan optreden, niets in de IT is onfeilbaar.

De oplossing is wel heel rigoureus, als je terug moet van backups van bijna een dag oud dan is er wel een serieus probleem. Zonder te willen speculeren, ik vermoed dat de hele storage is geklapt en de volumes niet meer terug te halen waren. Bij een goed uitgevoerde redundante omgeving zou zoiets niet mogelijk mogen zijn toch?

Dat het gebeurd is, daar kunnen we niks meer aan doen. Dat is een feit en dat zij zo. Maar ik ben wel heel benieuwd naar een verklaring wat er nu gebeurd is, hoe dit kon gebeuren en vooral: hoe gaan ze dit in de toekomst voorkomen. Natuurlijk met alle slagen om de arm en er zijn altijd situaties denkbaar waarin elk noodplan faalt. Maar vooral het laatste ben ik dus erg benieuwd naar.

Voor mij is dat ook wel belangrijk, ben nu gelukkig niet getroffen maar ik heb redelijk kritische klanten in mijn reseller hosting en die leg ik liever niet uit dat we 24+ uur uit de lucht zijn omdat er iets kapot is gegaan. Die beloofde maand gratis hosting is leuk, maar daar koopt de eindklant niet veel voor.

Op dit moment hebben de mannen en vrouwen bij Mijn.Host ongetwijfeld wel iets anders aan het hoofd, maar ben benieuwd of hier later deze week of volgende week nog berichtgeving over komt.

[Room42]

Drardollan schreef op dinsdag 13 oktober 2026 @ 14:14:
[...]

Voor mij is dat ook wel belangrijk, ben nu gelukkig niet getroffen maar ik heb redelijk kritische klanten in mijn reseller hosting en die leg ik liever niet uit dat we 24+ uur uit de lucht zijn omdat er iets kapot is gegaan. Die beloofde maand gratis hosting is leuk, maar daar koopt de eindklant niet veel voor.

[...]

Oprechte interesse, zonder waardeoordeel; Wat staat hierover in de SLA?

Dit soort storingen zijn voor niemand leuk, ik heb ook in de MSP-rol gezeten toen bij ons wat serieus klapte. Ook heb ik wel eens een verstoring veroorzaakt door een fout van mijn kant (gelukkig niet zó groot). Echt een rotgevoel maar je moet er doorheen. Ik kan gelukkig erg goed fouten toegeven en dat helpt enorm voor het begrip en als je dan laat zien dat je ervan leert en je werkwijze verbetert, komt ook dat vertrouwen weer terug, gelukkig.

Maar ook als het niet bij jou (als leverancier) ligt, maar bij jouw leverancier, kun je niet anders dan open en eerlijk zijn en direct communiceren. En jij kunt ook nadenken hoe jij gaat voorkomen dat zoiets jou de volgende keer helemaal plat legt, of dat je, samen met je klant, ervoor kiest dit risico toch gewoon te dragen.

Maar ik hoop dat ze duidelijke en open kaart spelen.

[Room42]

Wat ik bedoel te zeggen, is dat je als reseller niet volledig de verantwoordelijkheid in de schoenen van mijn.host kunt schuiven, als jouw klanten niet even down kunnen zijn. Dan ben jij "net zo nalatig" (duidelijk tussen aanhalingstekens!!) door een single point of failure te huren zonder backup of uitwijkmogelijkheden.

Het is vaak een budgettaire keuze die heel logisch is. Maar daarmee loop je risico en dat moet je dan dus aanvaarden en mee leven. Het komt weer goed. Ik hoop voor je dat je je klanten geen 100% uptime beloofd hebt.

Ik kan dus alleen maar zeggen: Blijf praten met je klanten. Mogelijk bloeit er juist mooie business uit om extra garanties te bieden.

[ Voor 11% gewijzigd door Room42 op 13-10-2026 14:29 ]

[Drardollan]

@Room42

Ik heb zelf geen SLA's op dit vlak met mijn klanten en beloof ze zeker geen 100% uptime. Dus wat dat betreft zit het helemaal prima. En als ik dit zou moeten communiceren naar mijn klanten dan gebeurd dat ook gewoon, inclusief een uitleg (waar mogelijk).

Ik heb ook geen aparte SLA's met Mijn.Host. Mijn.Host geeft zelf namelijk aan:

Hoge uptime
Je wilt dat je website goed bereikbaar is en downtime voorkomen. Wij zorgen hiervoor met onze hoge uptime van 99,9%. We draaien de nieuwste hardware in een redundante setup.

Bron: https://mijn.host/over-ons

Heel kinderachtig gezegd betekent dit een maximale downtime per periode:
dag - 1 min en 26 seconden
week - 10 min en 5 seconden
maand - 43 min en 50 seconden
jaar - 8 uur, 45 minuten en 36 seconden

De 99,9% is een uitspraak en belofte die ze zelf doen, zonder verdere SLA's of andere overeenkomsten. Zonder extra kosten of andere grapjes.

In principe zou ik dat mijn klanten moeten kunnen vertellen en verkopen. Desnoods met een slag om te arm door mijn klanten 99,8% te beloven (verdubbeling van de tijd). Maar beide zijn niet gehaald bij deze storing, integendeel.

Natuurlijk snap ik dat er dingen fout kunnen gaan, natuurlijk snap ik dat je te maken kan hebben met invloeden van binnen of buitenaf en natuurlijk pin ik een provider niet vast op een minuut. Maar het is wel 1 van de redenen waarom ik gekozen heb om producten van Mijn.Host te verkopen. Als je dit beloofd als bedrijf, dan mag je dat als klant ook verwachten toch?

Verder is het vanuit mijn klanten niet een nodige keus of overweging, over het algemeen is een korte downtime geen probleem. Het zijn geen kritische zaken waar leven en dood vanaf hangen. Het zijn geen sites waarbij je een dubbele kost kan verantwoorden. Het zijn sites waarbij een uptime van 99,8% al meer dan voldoende is (en Mijn.Host beloofd dus 99,9%).

Dus ik ben het in dit geval met je oneens dat je niet alle schuld op Mijn.Host kan afschuiven. Ze hebben in de verste verte niet voldaan aan hun beloftes waarop bedrijven hun producten inkopen. De redundantie was niet aanwezig of werkte op zijn minst niet naar behoren. En ik vind dat, in dit specifieke geval, Mijn.Host daar voor 100% verantwoordelijk voor is. Als ze dat niet willen zijn, dan moeten ze dat niet op hun eigen site zetten.

Ik zou mijzelf als tussenpartij daarin niet nalatig voelen, er zijn namelijk backups (die koop je bewust bij de producten van Mijn.Host) en er zou geen SPOF zijn volgens Mijn.Host. Een uitwijkmogelijkheid heb je als tussenpersoon altijd, als je bij de backups had gekund in dit geval (maar hoe realistisch is dat, de DNS was ook een probleem gok ik). Dus nee, ik kan dat niet zien als nalatig. Ik als tussenpersoon heb er alles aan gedaan en producten ingekocht op basis van informatie die mij gegeven is.

Wat overigens niet zegt dat ik nu boos ben op Mijn.Host of ze ineens niet meer vertrouw. Ben zelf niet getroffen gelukkig, maar besef mij goed dat dit wel zo had kunnen zijn. Maar ook dan had ik ermee kunnen (en moeten) leven. Maar ik hecht wel waarde aan duidelijkheid wat er gebeurd is en vooral wat er aan gedaan wordt om dit in de toekomst te voorkomen (voor zover mogelijk en natuurlijk met alle slagen om de arm dat ook de best ingerichte systemen kunnen klappen).

[Room42]

@Drardollan Fair.

De DNS niet down geweest (zover ik gemerkt heb), dus je had bij (off-site) backups gekund. Sowieso kun je DNS natuurlijk makkelijk tijdelijk omzeilen met een host file of lokale server.
Die SLA van 99.9% hebben ze, lijkt me, niet helemaal gehaald, nee.

Overigens zie ik de laatste update op de statuspagina:

Ook de laatste server is volledig hersteld en weer online. Hiermee zijn alle diensten weer beschikbaar. We lopen de servers op dit moment nog na om te controleren of alles correct functioneert.

Ervaar je toch nog problemen? Stuur dan een e-mail naar [e-mail], dan kijken we het direct voor je na.

Dus mochten er nog mensen met issues zijn, kunnen die zich melden.

[ Voor 6% gewijzigd door Room42 op 13-10-2026 15:04 ]

[Drardollan]

Room42 schreef op dinsdag 13 oktober 2026 @ 15:03:
De DNS niet down geweest (zover ik gemerkt heb), dus je had bij (off-site) backups gekund. Sowieso kun je DNS natuurlijk makkelijk tijdelijk omzeilen met een host file of lokale server.

Je kon in principe geen wijzigingen aan de DNS doen, het hostingpakket was niet beschikbaar. En daarmee kon je ook niet bij de backups, want ook dat loopt via DirectAdmin. Waarschijnlijk waren bestaande zonefiles beschikbaar (ze doen een sync van DirectAdmin naar hun controlepaneel en de daadwerkelijke DNS servers), maar als je een site dan verhuisd naar een andere provider dan kan je nog niks. Je kan tenslotte moeilijk alle bezoekers gaan vragen of ze hun hosts file willen aanpassen

Daar zijn oplossingen voor, maar laten we die maar even achterwege laten omdat het dan offtopic wordt

[ Voor 7% gewijzigd door Drardollan op 13-10-2026 15:17 ]

[e.dewaal]

Ik vermoed dat je de nameservers had kunnen omzetten. Het probleem zat immers in de hosting, niet in de domeinnamen. Ik heb zelf gisteren nog de nameserver van één van mijn domeinen gewijzigd naar cloudflare. Daarmee krijg je de dns-config terug in handen en kan je verwijzen naar elke andere hosting om je website weer beschikbaar te maken.

[Drardollan]

e.dewaal schreef op dinsdag 13 oktober 2026 @ 15:20:
Ik vermoed dat je de nameservers had kunnen omzetten. Het probleem zat immers in de hosting, niet in de domeinnamen. Ik heb zelf gisteren nog de nameserver van één van mijn domeinen gewijzigd naar cloudflare. Daarmee krijg je de dns-config terug in handen en kan je verwijzen naar elke andere hosting om je website weer beschikbaar te maken.

Er is een reden dat ik niet op oplossingen in wilde gaan

[webdesigner]

Mochten alle domeinen bij CLoudflare staan, en je dagelijks een eigen back-up export naar een aparte niet mijn.host server doet, zou je 1 klant in principe binnen 20minuten kunnen restoren.
Cloudflare reageert heel snel bij DNS changes namelijk.
De mailboxen zijn iets complexer maar ook mogelijk via SSH Imapsync om zelf snel te verhuizen.
Het probleem is dat we niet wisten op voorhand hoe lang deze outage zou duren. Ik zit nu nog steeds met 1 klant die nog niet volledig hersteld is (dus bijna 48u, een webshop). Ik heb zelf al die klant gerestored met eigen backup en gepoint naar andere server, dus die site werkt opnieuw op een andere Combell server gelukkig.

Echter deze "Black Swan" kon niemand voorzien, en als je hiervoor zelf continu alles moet extra back-uppen, dan zou dit een extra kost zijn voor de klant. In 15 jaar tijd heb ik dit nog nooit gezien, en ik heb meer tientallen hostingproviders gebruikt.

Ik denk dat we een periode tegemoet gaan waar IT failures meer gaan voorkomen, niet alleen bij websites.

Al bij al blijf ik wel nog steeds heel tevreden van mijn.host ! Ze doen echt hun best.

[ Voor 23% gewijzigd door webdesigner op 13-10-2026 16:21 ]

[Drardollan]

Zoals gezegd, ik ga het hier niet hebben over oplossingen.

Ik heb dit soort incidenten wel vaker meegemaakt, al is het wel lang geleden dat ik heb meegemaakt dat er 24 uur terug in de tijd gegaan moest worden. Heel uniek is het verder niet, Versio is al weken deels uit de running en de verwachting is nog een paar weken (nieuws: Storing bij Versio kan nog twee weken duren en kwam door onbekende kw...).

En ben het niet met je eens dat het niet te voorzien was. Maar dat heb ik al eerder geschreven en ga ik niet herhalen, zie mijn vorige lange post daarvoor.

[t.martinali]

Ik zou eigenlijk ook wel weten wat de oorzaak is dat hun Ceph storage overleden/in storing is. Daar leren we iets van en kunnen andere providers het ook zelfs voorkomen wellicht.

Verder zijn dit soort zaken lastig en is het heel moeilijk een ETA voor een oplossing in te schatten. Als men mailt 'wanneer is het opgelost', dan is het vaak zo dat als je DAT weet dat het al opgelost is.

[Maarten69]

Ik ervaar nog steeds mail problemen. Verzenden lukt nog wel. Ontvangen vanuit hotmail ook, maar reguliere post komt niet binnen. certificaten automatisch vernieuwen ljikt te falen.
Ik zie het nog even een dag aan, anders zal ik ze morgen even contacteren. Ze zullen nu ook wel druk zijn.

[CUGEL2000]

Eerste post hier, maar ik wilde mijn ervaring toch delen. Ook ik was getroffen: mijn pakket stond op h56, waardoor mijn website en e-mail ruim 30 uur onbereikbaar waren. Na het herstel bleek bovendien mail van vlak voor de storing verloren te zijn gegaan en werd mijn site als onveilig gemarkeerd. Het SSL-certificaat moest ik zelf opnieuw aanvragen.

Ik heb inmiddels een account genomen bij mailbox.org, zodat mijn e-mail niet meer via mijn.host loopt. Les geleerd: ik wil nooit meer volledig afhankelijk zijn van één provider. Domeinen en DNS laten staan bij mijn.host. De nameservers bleven tijdens de storing gewoon werken, dus dat deel was het probleem niet.

Mijn tip: overweeg je mail los van je hosting te regelen, bij een partij die alleen mail doet. Mailbox.org is daar één optie van; andere bekende alternatieven zijn bijvoorbeeld Proton en Fastmail. Welke je kiest maakt minder uit dan het principe: valt je hoster om, dan blijft je mail gewoon werken.

Mijn mail komt nu bovendien merkbaar sneller binnen dan bij mijn.host. Dat was me trouwens al voor de storing opgevallen. En ook voor de website kijk ik verder: op termijn wil ik waarschijnlijk helemaal weg van klassieke shared hosting, richting een oplossing als Cloudflare of Bunny.net, waar je site verspreid over meerdere locaties draait in plaats van op één server.

[ Voor 11% gewijzigd door CUGEL2000 op 14-10-2026 07:44 ]

[Room42]

CUGEL2000 schreef op woensdag 14 oktober 2026 @ 07:09:
[...]

Ik heb inmiddels een account genomen bij mailbox.org, zodat mijn e-mail niet meer via mijn.host loopt. Les geleerd: ik wil nooit meer volledig afhankelijk zijn van één provider. Domeinen en DNS laten staan bij mijn.host. De nameservers bleven tijdens de storing gewoon werken, dus dat deel was het probleem niet.

[...]

Wacht, die volg ik niet helemaal. Want nu ben je alsnog volledig afhankelijk van één provider voor je mail. Als je dit goed op wilt lossen neem je backup MX-servers die bij storing van de primaire MX de mail voor je bewaren tot deze weer online komt.

[ Voor 11% gewijzigd door Room42 op 14-10-2026 08:47 ]

[Room42]

DNS kun je ook verdelen over meerdere providers, overigens. pas het NS1 of NS2 record van je domein aan naar een ander waar je exact dezelfde DNS-configuratie aanhoudt en je hebt een backup.

[Drardollan]

CUGEL2000 schreef op woensdag 14 oktober 2026 @ 07:09:
Ik heb inmiddels een account genomen bij mailbox.org, zodat mijn e-mail niet meer via mijn.host loopt. Les geleerd: ik wil nooit meer volledig afhankelijk zijn van één provider. Domeinen en DNS laten staan bij mijn.host. De nameservers bleven tijdens de storing gewoon werken, dus dat deel was het probleem niet.

Mijn tip: overweeg je mail los van je hosting te regelen, bij een partij die alleen mail doet. Mailbox.org is daar één optie van; andere bekende alternatieven zijn bijvoorbeeld Proton en Fastmail. Welke je kiest maakt minder uit dan het principe: valt je hoster om, dan blijft je mail gewoon werken.

Conclusie, je hebt niks opgelost. Je betaalt wel meer, maar bent nog steeds 100% afhankelijk van één provider.

Los van dat je keuze voor mailbox.org om allerlei redenen een prima keuze kan zijn natuurlijk.

En ook voor de website kijk ik verder: op termijn wil ik waarschijnlijk helemaal weg van klassieke shared hosting, richting een oplossing als Cloudflare of Bunny.net, waar je site verspreid over meerdere locaties draait in plaats van op één server.

Ik denk dat je beter eerst wat tijd kan besteden aan hoe een en ander werkt. Cloudflare en Bunny.net hosten geen websites en al zeker niet op meerdere locaties.

[Bedge85]

CloudFlare heeft wel hosting voor o.a. statische websites. CloudFlare heeft tegenwoordig ook iets dat lijkt op de Lambda functies van AWS, wel beperkt tot nodejs volgens mij. Daarnaast bieden ze storage op basis van S3 aan en volgens mij ook een database. Je kunt dus wel degelijk hosting doen in Cloudflare.

Of je het wil is natuurlijk een andere vraag .

[Drardollan]

Room42 schreef op woensdag 14 oktober 2026 @ 08:59:
DNS kun je ook verdelen over meerdere providers, overigens. pas het NS1 of NS2 record van je domein aan naar een ander waar je exact dezelfde DNS-configuratie aanhoudt en je hebt een backup.

Dat kan inderdaad, maar ik denk dat de gemiddelde consument en minder op de materie zittende IT’er dat niet voor elkaar gaat krijgen. Alleen al de communicatie / synchronisatie tussen de 2 nameservers bij 2 providers zal serieus lastig worden verwacht ik. En die wil je wel hebben, anders wordt het onbeheerbaar (al kan het wel wat je zegt).

DNS zijn prima, gratis, oplossingen voor bij bijvoorbeeld CloudFlare. Natuurlijk nog steeds 1 provider, maar wel een hele grote met een heel degelijke setup. En zelfs zij hebben wel eens problemen.

Maar laten we eerlijk zijn en het ontopic houden, hoeveel serieuze en langdurige storingen (buiten die van deze week) heeft mijn.host nou daadwerkelijk per jaar?

[Drardollan]

Bedge85 schreef op woensdag 14 oktober 2026 @ 09:07:
CloudFlare heeft wel hosting voor o.a. statische websites. CloudFlare heeft tegenwoordig ook iets dat lijkt op de Lambda functies van AWS, wel beperkt tot nodejs volgens mij. Daarnaast bieden ze storage op basis van S3 aan en volgens mij ook een database. Je kunt dus wel degelijk hosting doen in Cloudflare.

Of je het wil is natuurlijk een andere vraag .

Statische websites, in 1995 was dat nog een heel ding

Anno 2026 is het overgrote deel van de websites op shared hosting een Wordpress site. Die ga je niet kunnen draaien (op dit moment) bij CF of Bunny.

CF en Bunny zijn in principe niets meer dan reverse proxy aanbieders met een lading extra diensten. Ze zijn op dit moment geen hosting partij, al kan je inderdaad wel heel beperkt iets doen.

[Oon]

Drardollan schreef op woensdag 14 oktober 2026 @ 09:14:
[...]

Statische websites, in 1995 was dat nog een heel ding

Anno 2026 is het overgrote deel van de websites op shared hosting een Wordpress site. Die ga je niet kunnen draaien (op dit moment) bij CF of Bunny.

CF en Bunny zijn in principe niets meer dan reverse proxy aanbieders met een lading extra diensten. Ze zijn op dit moment geen hosting partij, al kan je inderdaad wel heel beperkt iets doen.

Dit gaat inmiddels vrij ver off-topic, maar ik heb wel vaker WordPress als CMS gebruikt en daarna de statische output gedeployed als eerste laag in nginx, waardoor alleen inloggen en beheren ervan PHP nodig hadden. Zelfde met Vue en React, kun je prima statische output uit halen.

Ben wel benieuwd hoe mijn.host dit gaat aanvliegen, want redundancy in opslag is duur maar wel de enige manier om dit soort discussies niet te hoeven voeren. Hoop dat ze snel weer helemaal 100% draaien en een update kunnen bieden met daarin een plan voor de toekomst.

[Drardollan]

Oon schreef op woensdag 14 oktober 2026 @ 09:24:
[...]

Dit gaat inmiddels vrij ver off-topic, maar ik heb wel vaker WordPress als CMS gebruikt en daarna de statische output gedeployed als eerste laag in nginx, waardoor alleen inloggen en beheren ervan PHP nodig hadden. Zelfde met Vue en React, kun je prima statische output uit halen.

Heb mij helaas toch laten verleiden tot oplossingen. Sorry.

Maar je hebt precies beschreven waar/hoe je CF of Bunny inzet als je deze voor je hosting plaatst

[CUGEL2000]

Klopt, ik ben nog steeds afhankelijk van één mailprovider. Mijn les is vooral dat ik mail en hosting niet meer bij dezelfde partij wil hebben. Bij mijn.host ging het mis door gefaalde opslag en een back-up van een dag oud, en dat risico schat ik bij een gespecialiseerde mailprovider een stuk kleiner in. Een backup MX heb ik overwogen, maar verzendende servers houden mail bij een storing zelf al een paar dagen vast, en dat zag ik deze week ook gebeuren. Voor mijn situatie vind ik dit een goede balans. Secundaire DNS is een interessante tip, die neem ik mee als ik mijn DNS verhuis.

Wat Cloudflare en Bunny.net betreft: ik had het te kort door de bocht geformuleerd. Het gaat niet om klassieke hosting met PHP en een database. Mijn site is een statische pagina met afbeeldingen, en die wil ik op termijn serveren via iets als Cloudflare Pages/Workers met R2-opslag, of Bunny Storage met hun CDN. De opslag staat dan op één plek, maar de site wordt via hun netwerk vanaf veel locaties geserveerd, en dat maakt hem een stuk minder kwetsbaar dan één shared server. En het kost minder of is het zelfs gratis.

[Diederik]

Het zou @mijn.host sieren als ze hier een Tweakers waardige uitleg plaatsen over dit grote incident. Ik heb er zelf (gelukkig) geen last van gehad maar ik wil wel graag horen wat er is mis gegaan en hoe ze dit in de toekomst willen voorkomen.

[Ruzor]

Diederik schreef op woensdag 14 oktober 2026 @ 12:14:
Het zou @mijn.host sieren als ze hier een Tweakers waardige uitleg plaatsen over dit grote incident. Ik heb er zelf (gelukkig) geen last van gehad maar ik wil wel graag horen wat er is mis gegaan en hoe ze dit in de toekomst willen voorkomen.

Hier hebben ze in ieder geval al een initiële reactie gegeven:
mijn.host in 'Defecte opslag brengt servers van mijn.host urenlang offline'

[CUGEL2000]

Drardollan schreef op woensdag 14 oktober 2026 @ 09:14:
[...]

Statische websites, in 1995 was dat nog een heel ding

Anno 2026 is het overgrote deel van de websites op shared hosting een Wordpress site. Die ga je niet kunnen draaien (op dit moment) bij CF of Bunny.

CF en Bunny zijn in principe niets meer dan reverse proxy aanbieders met een lading extra diensten. Ze zijn op dit moment geen hosting partij, al kan je inderdaad wel heel beperkt iets doen.

Ja het is een beetje off topic, ik weet het, maar door het incident van mijn.host ben ik wel gaan rondkijken voor alternatieven. Een WordPress-site draai je op CF en Bunny niet en voor de meeste shared hosting-klanten is het dus geen alternatief.

Mijn situatie is alleen anders: ik gebruik geen WordPress maar een zelfgebouwd CMS dat één statische pagina met afbeeldingen genereert. PHP gebruik ik alleen voor opslaan, uploaden en publiceren, en dat stukje is goed te vervangen door een Worker met R2-opslag.

Statisch klinkt misschien als 1995, maar met static site generators als Hugo of Astro is het juist weer helemaal terug, omdat het snel, veilig en goedkoop te serveren is. Voor een portfoliosite als de mijne is het eigenlijk de logische keuze. Voor een WordPress-site of een webwinkel zou ik het inderdaad niet doen.

[ Voor 6% gewijzigd door CUGEL2000 op 14-10-2026 13:43 ]

[Lost-Viking]

Waar ik mij vooral aan stoor is het feit dat ik managed omgevingen afneem en inhoudelijk geen enkel bericht heb ontvangen. We dus inderdaad zelf alle installaties langs moeten om te controleren dat er wijzigingen zijn, van wanneer de backup is en wat dus missende inzendingen,bestellingen,wijzigingen zijn. Vanochtend hierover gemaild maar ook hierop geen reactie ontvangen.

E-mail
We scheiden al jaren de webhosting en e-maildienstverlening van elkaar en hebben hele goede ervaringen met https://www.qboxmail.com/, wat draait in Europa. DNS draaien we o.a. via Openprovider, al hebben we daar 2 jaar geleden enorme sorres mee gehad. Gelukkig daar alweer 2 jaar rustig .

[mijn.host]

Diederik schreef op woensdag 14 oktober 2026 @ 12:14:
Het zou @mijn.host sieren als ze hier een Tweakers waardige uitleg plaatsen over dit grote incident. Ik heb er zelf (gelukkig) geen last van gehad maar ik wil wel graag horen wat er is mis gegaan en hoe ze dit in de toekomst willen voorkomen.

We zullen proberen later meer informatie te delen over de oorzaak van de storing. Daarnaast willen we alle mede-Tweakers bedanken voor het begrip, ook in dit topic. We realiseren ons dat dit zeer vervelend is en dat een downtime van deze duur niet acceptabel is.

De komende periode nemen we onze systemen grondig onder de loep en onderzoeken we hoe we dit in de toekomst kunnen voorkomen.

[CUGEL2000]

Room42 schreef op woensdag 14 oktober 2026 @ 08:45:
[...]

Wacht, die volg ik niet helemaal. Want nu ben je alsnog volledig afhankelijk van één provider voor je mail. Als je dit goed op wilt lossen neem je backup MX-servers die bij storing van de primaire MX de mail voor je bewaren tot deze weer online komt.

Een Backup MX klinkt in theorie leuk, maar is in de praktijk anno 2026 achterhaald en brengt vooral risico's met zich mee:

• Spammagneet: Spammers misbruiken back-upservers bewust omdat de spamfilters daar vaak minder streng zijn. Zodra je hoofdserver online komt, pomp je alsnog je eigen inbox vol met spam en malware.
• Beveiligingsellende: Het doorsturen van mail vanaf een back-upserver breekt al snel moderne e-mailbeveiliging zoals SPF, DKIM en DMARC, waardoor legitieme mail juist in de spambox belandt.
• Ingebouwde SMTP-logica: Als een partij als mailbox.org onbereikbaar is, gooien verzendende servers (zoals Gmail of Outlook) de mail niet weg. De mail blijft automatisch tot 4 à 5 dagen in hun eigen wachtrij (retry queue) staan en wordt netjes afgeleverd zodra de ontvanger er weer is.

Waarom ging er dan tóch mail verloren bij mijn.host?
Dat had niets te maken met het ontbreken van een Backup MX. Mijn.host heeft inmiddels laten weten dat een compleet storagecluster is uitgevallen en ze een back-up van de nacht ervoor moesten terugzetten. De mailserver was dus wel online, maar de live-data van die dag is door de restore simpelweg overschreven en gewist. Een backup MX had daar dus niets aan veranderd.

De overstap naar mailbox.org is omdat zij hun opslag realtime en geografisch gescheiden redundant opslaan over meerdere datacenters. Samen met Cloudflare voor de website is de single point of failure er nu volledig uit.

[webdesigner]

Ondertussen werken alle sites bij mijn.host opnieuw. Ik merk dat hun firewall nu plots extreem streng staat, veel gevoeliger dan voorheen. Dat valt me op... Als ik nu enkele sites na elkaar op die server open, is mijn IP adres direct geband, dat was vroeger niet.

Buiten deze maatregel wil ik wel benadrukken dat mijn.host enorm hun best heeft gedaan, en dat alles nu perfect opgelost is. Bij Combell ga je die uptime gegarandeerd hebben, maar betaal je wel een veelvoud per reseller slot, men moet ook wel appels met appels vergelijken.

Mijn.host blijft nog altijd bij de top prijs/kwaliteit/service !

[mijn.host]

Verklaring over de storing van 12 oktober

Hoi allemaal,

Allereerst bedankt voor jullie geduld. Zoals beloofd een uitgebreide toelichting op de storing die in de nacht van zondag 11 op maandag 12 oktober begon. De uitval was het gevolg van een beveiligingsincident op een beperkt aantal servers. Ongeveer 5% van onze klanten is hierdoor geraakt. Zij hebben vandaag een e-mail van ons ontvangen met een uitgebreide toelichting.

Wat is er gebeurd?

Toen de storing ontstond, zagen we in eerste instantie dat de opslag was uitgevallen, en dat hebben we op onze statuspagina gemeld. Onze eerste prioriteit was om alle diensten zo snel mogelijk te herstellen, wat veel tijd kostte. Tegelijkertijd hebben we onderzocht hoe de uitval kon ontstaan.

Na intensief onderzoek bleek dat via de beheerinterface (iDRAC) van de serverhardware een wisopdracht was gegeven voor de opslag van deze servers, zonder onze toestemming. Daardoor viel de opslag uit en ontstond de storing. Vervolgens hebben we de logbestanden grondig nagelopen om zeker te weten wat er wel en niet is gebeurd, zodat we iedereen volledig en juist konden informeren. We hebben tevens besloten juridische maatregelen te treffen tegen de verantwoordelijke.

Zijn er gegevens ingezien of gekopieerd?

Nee, daar zijn geen aanwijzingen voor. De beheerinterface legt vast welke acties er worden uitgevoerd. Daaruit blijkt dat er alleen een wisopdracht is gegeven. Bij een wisopdracht wordt de opslag gewist zonder dat de inhoud wordt uitgelezen.

Wat waren de gevolgen?

Het gevolg was dat de diensten op deze servers tijdelijk niet beschikbaar waren. Onze opslag is redundant uitgevoerd, maar die redundantie beschermt tegen hardwarestoringen en niet tegen een wisopdracht: die wist alle kopieën tegelijk. Daarom maken we daarnaast back-ups op gescheiden opslag.

Op maandagochtend 12 oktober zijn we begonnen met het terugzetten van alle gegevens vanuit die back-ups. Omdat dit herstel geleidelijk verliep, waren diensten afhankelijk van de server tussen de 6 en 30 uur offline, in uitzonderlijke gevallen iets langer.

De teruggezette gegevens komen uit de laatst beschikbare back-up. In de meeste gevallen was dat een back-up van dezelfde nacht, in andere gevallen van de nacht ervoor, en in enkele uitzonderlijke gevallen ouder. Gegevens die ná dat back-upmoment en vóór de storing zijn aangemaakt of gewijzigd, hebben wij mogelijk niet kunnen herstellen. Getroffen klanten die twijfelen of recente gegevens compleet zijn, kunnen contact met ons opnemen.

Wat hebben we gedaan?

• Direct na de ontdekking hebben we de betreffende toegang tot de beheerinterface ingetrokken.
• We hebben alle beheertoegang tot onze systemen gecontroleerd en de toegangsgegevens vervangen.
• We scherpen onze procedures voor toegangsbeheer verder aan.
• We evalueren ons herstelproces, zodat we bij een eventueel volgend incident sneller weer volledig online zijn.

Klanten zijn geïnformeerd

Alle getroffen klanten hebben van ons een persoonlijke e-mail ontvangen met alle details, inclusief informatie over hun eigen verplichtingen onder de AVG. Zij beoordelen zelf of een melding bij de Autoriteit Persoonsgegevens nodig is. Waar nodig helpen we ze daarbij.

Tot slot

Onze oprechte excuses voor de overlast die dit heeft veroorzaakt. We doen er alles aan om herhaling te voorkomen en blijven ons hierin verbeteren.

Heb je vragen? Stuur ons dan een bericht via onze website, want het forum volgen we niet continu. Getroffen klanten kunnen ook dit weekend bij ons terecht met vragen over dit incident.

[acermoi]

Heb flink wat mensen voor website hosting naar mijn.host verwezen, maar zie ik dat nou goed? Als ik naar self managed server ga, 1 v4 en geen v6?

Die ene 4 prima, maar geen 6, 3 soort os keuze, 100Gb voor 54 euro?

Als ik naar bv ultravps.eu kijk zie ik 250 Gb, 4 soort os en 1 v4 / 10 v6 voor 20 euro... Even helemaal los van uptime/routing etc..

[RobertMe]

@mijn.host niet verplicht om te antwoorden Maar wat in de post in het midden blijft is hoe de toegang verkregen is. Gaat het hier om een (ex) medewerker die legitiem login gegevens had (en misbruik van zijn toegang heeft gemaakt)? Of gaat het hier om een hack, van buitenaf? Medewerker of ex-medewerker is dan ook minder relevant en mag in het midden worden gelaten.

[DBreda]

Ik heb een VPS bij mijn.host maar lees het nieuws nu pas op de homepage, gelukkig dus niks van meegekregen!

[Room42]

mijn.host schreef op vrijdag 16 oktober 2026 @ 17:31:
[...] was het gevolg van een beveiligingsincident op een beperkt aantal servers. [...]

Hier val ik altijd een beetje over. Het klinkt nogal bagatelliserend. Hoezo en door wie was het aantal servers beperkt? En wat voor signaal geef je hiermee naar de klanten die wel getroffen zijn? Mijn tip: schrijf gewoon "een aantal servers", zeker ook omdat je daarna de schaal al aangeeft met de 5%.

Verder is het verhaal een wollig en draait het, voor mij, om de echte hete brij heen. Hoe heeft het zover kunnen komen en het was duidelijk dus een bekende die toegang had tot de systemen? En waarom konden sommige systemen niet van de backup van de nacht ervoor hersteld worden?

Ik weet niet of er elders een artikel staat met meer details?

[ Voor 10% gewijzigd door Room42 op 16-10-2026 21:53 ]

[True]

Room42 schreef op vrijdag 16 oktober 2026 @ 21:51:
[...]

Hier val ik altijd een beetje over. Het klinkt nogal bagatelliserend. Hoezo en door wie was het aantal servers beperkt? En wat voor signaal geef je hiermee naar de klanten die wel getroffen zijn? Mijn tip: schrijf gewoon "een aantal servers", zeker ook omdat je daarna de schaal al aangeeft met de 5%.

Verder is het verhaal een wollig en draait het, voor mij, om de echte hete brij heen. Hoe heeft het zover kunnen komen en het was duidelijk dus een bekende die toegang had tot de systemen? En waarom konden sommige systemen niet van de backup van de nacht ervoor hersteld worden?

Ik weet niet of er elders een artikel staat met meer details?

Uit de tekst (i.c.m. een eerder bericht wat verwijst naar een mail die ik voor waarheid aanneem: Lost-Viking in "[mijn.host] Ervaringen & Discussie") is bijv. ook niet op te maken of de storage dienstverlener "hostingleverancier" per ongeluk een wisopdracht gedaan heeft via de iDRAC. En juridische stappen zijn dan logisch als er een overeenkomst is tussen mijn.host en de storage dienstverlener.

Wat ik er voor nu van kan maken is één van deze opties:

1. credentials zijn gelekt en een derde partij heeft bewust een wisopdracht uitgevoerd, dit is een beveiligingslek.
2. storage dienstverlener "hostingleverancier" (medewerker daarvan) heeft per ongeluk een wisopdracht uitgevoerd, dit is een autorisatieprobleem en waarschijnlijk een contractbreuk in het hosting/storagecontract.
3. een medewerker van mijn.host heeft per ongeluk een wisopdracht uitgevoerd, dit is knullig, op te lossen met four-eyes principle, maar in de praktijk heb je gewoon senior medewerkers die dit moeten kunnen.
4. een medewerker van mijn.host heeft bewust een wisopdracht uitgevoerd, dit is een HR-probleem, had je moeten voorzien en moeten voorkomen het risico is te mitigeren met bijv. password splitting.

Bij alle vier kun je juridische stappen nemen, enkel vind ik 1 kwalijker dan 2, 3 of 4 en zijn 2, 3 en 4 heel goed van te leren en te mitigeren.
@mijn.host zouden jullie wellicht hier nog wat licht op willen schijnen en net wat meer willen delen dan jullie corporate AI-sausje, dat zou mij in ieder geval meer vertrouwen geven in jullie dienstverlening en jullie openheid hierin.

[Oon]

True schreef op vrijdag 16 oktober 2026 @ 22:14:
[...]


Uit de tekst (i.c.m. een eerder bericht wat verwijst naar een mail die ik voor waarheid aanneem: Lost-Viking in "[mijn.host] Ervaringen & Discussie") is bijv. ook niet op te maken of de storage dienstverlener "hostingleverancier" per ongeluk een wisopdracht gedaan heeft via de iDRAC. En juridische stappen zijn dan logisch als er een overeenkomst is tussen mijn.host en de storage dienstverlener.

Wat ik er voor nu van kan maken is één van deze opties:

1. credentials zijn gelekt en een derde partij heeft bewust een wisopdracht uitgevoerd, dit is een beveiligingslek.
2. storage dienstverlener "hostingleverancier" (medewerker daarvan) heeft per ongeluk een wisopdracht uitgevoerd, dit is een autorisatieprobleem en waarschijnlijk een contractbreuk in het hosting/storagecontract.
3. een medewerker van mijn.host heeft per ongeluk een wisopdracht uitgevoerd, dit is knullig, op te lossen met four-eyes principle, maar in de praktijk heb je gewoon senior medewerkers die dit moeten kunnen.
4. een medewerker van mijn.host heeft bewust een wisopdracht uitgevoerd, dit is een HR-probleem, had je moeten voorzien en moeten voorkomen het risico is te mitigeren met bijv. password splitting.

Bij alle vier kun je juridische stappen nemen, enkel vind ik 1 kwalijker dan 2, 3 of 4 en zijn 2, 3 en 4 heel goed van te leren en te mitigeren.
@mijn.host zouden jullie wellicht hier nog wat licht op willen schijnen en net wat meer willen delen dan jullie corporate AI-sausje, dat zou mij in ieder geval meer vertrouwen geven in jullie dienstverlening en jullie openheid hierin.

Juridische stappen bij een menselijke fout zou wel echt een uitzondering zijn, in principe kan je werkgever je niet aansprakelijk stellen voor een fout die je hebt gemaakt binnen je reguliere werk.
Op basis van de verwoording in het bericht ("de verantwoordelijke") lijkt mij ook dat het een individu is en niet een leverancier met eigen laag.
Daarnaast wordt gesproken over toegang intrekken/controleren, dus diegene had geen toegang moeten hebben.
Dus dan blijft een (ex-)werknemer over die geen toegang (meer) zou moeten hebben tot deze interface en moedwillig een actie heeft uitgevoerd om schade aan te richten.

Blijft allemaal speculatie en ik verwacht niet dat wij hier een bevestigend antwoord op gaan krijgen, maar ik vind het wel heel fijn dat @mijn.host zo open is hierover en dat we niet worden afgewimpeld met 'een security-incident', wat op zichzelf al een toevoeging is die ze achterwege hadden kunnen laten. Ik denk dat in deze tijd een security-incident zelfs zwaarder weegt in je reputatie dan een storing, dus die toevoeging getuigt al van de wil om hier eerlijk over te zijn.

Hier kunnen wat mij betreft veel marketingafdelingen wat van leren, heel wat anders dan de AH die iemand op TV een interview laten doen waarin ze helemaal niks willen zeggen

[webdesigner]

Hier het officiële post-morten verslag van mijn.host:

Subject: Beveiligingsincident 12 oktober

Beste,

In de nacht van zondag 11 op maandag 12 oktober heeft er een incident opgetreden waardoor jouw webhosting of VPS enige tijd niet beschikbaar was. Tijdens de uitval hebben we gemeld op onze statuspagina dat de opslag van een aantal servers was uitgevallen. Inmiddels kunnen we je meer vertellen over de oorzaak van deze uitval: de uitval was het gevolg van een beveiligingsincident. Het ging om een beperkt aantal servers. Ongeveer 5% van onze klanten is hierdoor geraakt, en omdat jouw dienst(en) daarbij hoorde, ontvang je dit bericht.

Dit betreft de volgende dienst(en):

Product: Hostingpakket & VPS
Naam: xxx

Wat is er gebeurd?

Toen de storing ontstond, zagen we in eerste instantie dat de opslag van een beperkt aantal servers was uitgevallen. Onze eerste prioriteit was om alle diensten zo snel mogelijk te herstellen, wat veel tijd kostte. Tegelijkertijd hebben we onderzocht hoe de uitval kon ontstaan.

Na intensief onderzoek bleek dat via de beheerinterface (iDRAC) van de serverhardware een wisopdracht was gegeven voor de opslag van deze servers, zonder onze toestemming. Daardoor viel de opslag uit en ontstond de storing die je mogelijk hebt gemerkt. Vervolgens hebben we de logbestanden grondig nagelopen om zeker te weten wat er wel en niet is gebeurd, zodat we je volledig en juist konden informeren. We hebben tevens besloten juridische maatregelen te treffen tegen de verantwoordelijke.

Zijn er gegevens ingezien of gekopieerd?

Nee, daarvoor hebben wij geen aanwijzingen. De beheerinterface legt vast welke acties er worden uitgevoerd. Daaruit blijkt dat er alleen een wisopdracht is gegeven. Bij een wisopdracht wordt de opslag gewist zonder dat de inhoud wordt uitgelezen.

Wat waren de gevolgen?

Het gevolg was dat je dienst tijdelijk niet beschikbaar was. Onze opslag is redundant uitgevoerd, maar die redundantie beschermt tegen hardwarestoringen en niet tegen een wisopdracht: die wist alle kopieën tegelijk. Daarom maken we daarnaast back-ups op gescheiden opslag.

Op maandagochtend 12 oktober zijn we begonnen met het terugzetten van alle gegevens vanuit die back-ups. Omdat dit herstel geleidelijk verliep, was je dienst afhankelijk van de server tussen de 6 en 30 uur offline. In uitzonderlijke gevallen was dit iets langer.

De teruggezette gegevens komen uit onze laatst beschikbare back-up. In de meeste gevallen was dat een back-up van dezelfde nacht, in andere gevallen van de nacht ervoor, en in enkele uitzonderlijke gevallen ouder. Gegevens die ná dat back-upmoment en vóór de storing zijn aangemaakt of gewijzigd, hebben wij mogelijk niet kunnen herstellen. Twijfel je of bepaalde recente gegevens compleet zijn, neem dan gerust contact met ons op.

Wat hebben we gedaan?

• Direct na de ontdekking hebben we de betreffende toegang tot de beheerinterface ingetrokken.
• We hebben alle beheertoegang tot onze systemen gecontroleerd en de toegangsgegevens vervangen.
• We hebben passende vervolgstappen ondernomen richting de verantwoordelijke.
• We scherpen onze procedures voor toegangsbeheer verder aan.
• We zijn bezig ons herstelproces te evalueren, zodat we bij een eventueel ander incident sneller weer volledig online zijn.

Waarom ontvang je dit bericht?

Gezien de impact van de storing willen we je volledig en eerlijk informeren over wat er is gebeurd. Daarom informeren we je over dit beveiligingsincident, zoals afgesproken in artikel 7 van onze verwerkersovereenkomst.

Wat betekent dit voor jou?

Gelet op onze bevindingen bestaat er voor jouw organisatie mogelijk een meldplicht bij de Autoriteit Persoonsgegevens en mogelijk aan personen, op grond van artikel 33 en 34 van de Algemene Verordening Gegevensbescherming (AVG). Meer informatie over deze meldplichten is te vinden op de volgende pagina's van de Autoriteit Persoonsgegevens:

• Informatie over stappen bij een datalek
• Melding bij de Autoriteit Persoonsgegevens
• Melding aan natuurlijke personen

We begrijpen dat dit bericht vlak voor het weekend komt. Daarom zijn we ook dit weekend bereikbaar voor vragen over dit incident.

Wij willen benadrukken dat wij deze situatie betreuren. Mocht je aan de hand van dit bericht vragen aan ons hebben, neem dan contact met ons op door te reageren op dit bericht.

Met vriendelijke groet,
mijn.host

[ Voor 58% gewijzigd door webdesigner op 19-10-2026 16:31 ]

[Drardollan]

Sorry, maar wat een slap kletsverhaal. Het belangrijkste staat er zoals gezegd niet in: intern of extern toegang verkregen. Niet dat het veel uitmaakt, beide zijn verwijtbare fouten van mijn.host en ik raad getroffenen aan om contact op te nemen met juridische bijstand om te zien of hier consequenties aan moeten worden verbonden. Want het wissen is 1 ding, wie garandeert dat er niks op straat ligt?

Het is duidelijk dat de boel niet op orde is. Externe toegang via een openstaande irDAC is echt kleuterniveau beveiliging en intern maar net iets minder erg.

Ik ga binnenkort mijn klant zijn bij mijn.host in ieder geval opnieuw beoordelen. Heb in 30 jaar IT een hoop meegemaakt, maar een storage bewust gewist is aardig uniek en echt zorgwekkend.

[CUGEL2000]

Drardollan schreef op maandag 19 oktober 2026 @ 23:05:
Sorry, maar wat een slap kletsverhaal. Het belangrijkste staat er zoals gezegd niet in: intern of extern toegang verkregen. Niet dat het veel uitmaakt, beide zijn verwijtbare fouten van mijn.host en ik raad getroffenen aan om contact op te nemen met juridische bijstand om te zien of hier consequenties aan moeten worden verbonden. Want het wissen is 1 ding, wie garandeert dat er niks op straat ligt?

Het is duidelijk dat de boel niet op orde is. Externe toegang via een openstaande irDAC is echt kleuterniveau beveiliging en intern maar net iets minder erg.

Ik ga binnenkort mijn klant zijn bij mijn.host in ieder geval opnieuw beoordelen. Heb in 30 jaar IT een hoop meegemaakt, maar een storage bewust gewist is aardig uniek en echt zorgwekkend.

Ja, precies dit. Toen alles uiteindelijk weer draaide, heb ik meteen mijn conclusies getrokken en mijn hele infrastructuur gesplitst en elders ondergebracht (DNS, hosting en e-mail nu volledig gescheiden). Geen eieren meer in één mandje bij één partij. Mijn hostingpakket bij mijn.host is inmiddels definitief opgezegd en verwijderd. Door dit voorval is alles achteraf wel meteen een stuk veiliger ingericht. (en zelfs goedkoper) Dit nooit meer.

[RobertMe]

CUGEL2000 schreef op dinsdag 20 oktober 2026 @ 06:12:
[...]

Ja, precies dit. Toen alles uiteindelijk weer draaide, heb ik meteen mijn conclusies getrokken en mijn hele infrastructuur gesplitst en elders ondergebracht (DNS, hosting en e-mail nu volledig gescheiden). Geen eieren meer in één mandje bij één partij. Mijn hostingpakket bij mijn.host is inmiddels definitief opgezegd en verwijderd. Door dit voorval is alles achteraf wel meteen een stuk veiliger ingericht. (en zelfs goedkoper) Dit nooit meer.

Hoezo is het nu veiliger ingericht? Je hebt alleen zaken gesplitst, maar elk ding nog steeds bij een partij ingericht. If anything is de kans op uitval nu groter (je bent nu afhankelijk van 3 partijen i.p.v. 1, en bij allen kan iets mis gaan). Alleen de kans op uitval van alle drie tegelijkertijd heb je verlaagd. Maarja, als DNS er uit ligt..., ligt effectief nog steeds alles tegelijkertijd er uit. En bij mijn.host lag nu ook niet alles er uit, DNS werkte nog. En afhankelijk van wat je specifiek af nam wellicht "iets anders" ook nog wel (als je een VPS afnam in combinatie met managed mail zouden dit neem ik aan ook twee aparte servers zijn. Hoe ik het begreep draait waarschijnlijk alleen de managed hosting incl mail op dezelfde server).

En ja, er zijn vast voordelen aan splitsen etc. Maar het is niet per definitie, in alle gevallen, beter.

[rvk]

In plaats van te splitsen kun je dan beter kijken om een live mirror naar andere provider (of je eigen server lokaal) in te stellen. Dan beperk je je downtime (die zoals toegegeven nu wat te lang was). Dit kan zowel met mail als website.

[Diederik]

Drardollan schreef op maandag 19 oktober 2026 @ 23:05:
Sorry, maar wat een slap kletsverhaal. Het belangrijkste staat er zoals gezegd niet in: intern of extern toegang verkregen. Niet dat het veel uitmaakt, beide zijn verwijtbare fouten van mijn.host en ik raad getroffenen aan om contact op te nemen met juridische bijstand om te zien of hier consequenties aan moeten worden verbonden. Want het wissen is 1 ding, wie garandeert dat er niks op straat ligt?

Het is duidelijk dat de boel niet op orde is. Externe toegang via een openstaande irDAC is echt kleuterniveau beveiliging en intern maar net iets minder erg.

Ik ga binnenkort mijn klant zijn bij mijn.host in ieder geval opnieuw beoordelen. Heb in 30 jaar IT een hoop meegemaakt, maar een storage bewust gewist is aardig uniek en echt zorgwekkend.

@mijn.host graag een onderbouwde reactie hierop, er zijn veel Tweakers enthousiast over jullie diensten (ik iig wel) en het is belangrijk voor het vertrouwen als jullie hier met de billen bloot gaan en verder verduidelijken hoe dit incident heeft kunnen plaatsvinden en wat jullie gaan doen om dit in de toekomst te voorkomen.

Edit: met member tags kan je ervoor zorgen dat alleen Tweakers het kunnen lezen, en niet het complete Internet.

Edit 2: desnoods reageren jullie via DM naar de kritische klanten.

[ Voor 6% gewijzigd door Diederik op 20-10-2026 10:01 ]

[CUGEL2000]

Om even in te haken op de reacties hierboven: de beste aanpak hangt natuurlijk helemaal af van de specifieke situatie en de gekozen architectuur.

Wat voor een grote, dynamische omgeving geldt, is niet de standaard voor elke opzet. In mijn specifieke situatie speelden een paar hele concrete punten mee:

1. Waarom een 'live mirror' overkill is. Het gaat in mijn geval om een statische website. Er is geen dynamische database die continu synchroon moet lopen. De bronbestanden staan gewoon veilig lokaal en in een cloudbackup. Een ingewikkelde dubbele hosting-setup tussen twee providers opzetten brengt voor zo'n site alleen maar onnodige complexiteit en kosten met zich mee. Valt de webhoster om? Dan staat die site via de cloudbackup binnen 5 minuten op een willekeurige andere plek weer online.

2. Waarom gescheiden infrastructuur fundamenteel veiliger is (blast radius) Soms wordt de kans op uitval verward met risicospreiding en impactbeperking:

• Geen single point of failure: Als de hostingpartij zijn servers wist, draait mijn e-mail via Mailbox.org gewoon 100% door. Bij een 'alles-in één'-pakket ben je op al je communicatiekanalen in één klap compleet blind en onbereikbaar.
• DNS-infrastructuur: Cloudflare's Anycast DNS vergelijken met de DNS van een gemiddelde shared-hostingprovider is qua redundantie en uptime simpelweg een heel andere klasse.

Door diensten strikt te ontkoppelen heb ik maximale controle over mijn eigen data, geen afhankelijkheid van 1 enkele partij als er weer zoiets geks gebeurt ben ik onder de streep nog goedkoper uit ook.

[mijn.host]

We snappen dat er vraag is naar meer duidelijkheid. Wel hebben we juist geprobeerd in ons vorige bericht al zoveel mogelijk informatie publiekelijk te delen. We snappen ook dat dat juist weer meer vragen oproept.

Omdat we nog bezig zijn met een juridisch traject, kunnen we daar op dit moment nog niet meer informatie over delen. Meer delen zou daarin gevolgen kunnen hebben, en we hopen op jullie begrip hierin.

We kunnen wel delen dat het geen hack van buitenaf was en dat er geen credentials op straat lagen. Ook zijn er nog steeds geen aanwijzingen dat er inzage was in data. We hebben alle logs van de actie die is uitgevoerd.

Uit veiligheidsoverwegingen kunnen we niet in detail uitleggen hoe de beveiliging van iDRAC bij ons is ingericht, wel kunnen we zeggen dat dit uiteraard niet openbaar benaderbaar was via het internet.

Zoals in het vorige bericht aangegeven hebben we inmiddels al meerdere maatregelen hiertegen genomen. We zijn volop bezig om het toegangsbeheer verder aan te scherpen en ons herstelproces te evalueren, zodat we bij een eventueel volgend incident sneller weer online zijn.

We nemen dit enorm serieus. Dit is iets wat niet had mogen gebeuren, en we doen er alles aan om te zorgen dat dit, of een vergelijkbaar incident, niet nog eens kan gebeuren. Bedankt aan iedereen die geduld heeft gehad en ons hierin het vertrouwen blijft geven.

[Diederik]

mijn.host schreef op dinsdag 20 oktober 2026 @ 10:41:
We snappen dat er vraag is naar meer duidelijkheid. Wel hebben we juist geprobeerd in ons vorige bericht al zoveel mogelijk informatie publiekelijk te delen. We snappen ook dat dat juist weer meer vragen oproept.

Omdat we nog bezig zijn met een juridisch traject, kunnen we daar op dit moment nog niet meer informatie over delen. Meer delen zou daarin gevolgen kunnen hebben, en we hopen op jullie begrip hierin.

We kunnen wel delen dat het geen hack van buitenaf was en dat er geen credentials op straat lagen. Ook zijn er nog steeds geen aanwijzingen dat er inzage was in data. We hebben alle logs van de actie die is uitgevoerd.

Uit veiligheidsoverwegingen kunnen we niet in detail uitleggen hoe de beveiliging van iDRAC bij ons is ingericht, wel kunnen we zeggen dat dit uiteraard niet openbaar benaderbaar was via het internet.

Zoals in het vorige bericht aangegeven hebben we inmiddels al meerdere maatregelen hiertegen genomen. We zijn volop bezig om het toegangsbeheer verder aan te scherpen en ons herstelproces te evalueren, zodat we bij een eventueel volgend incident sneller weer online zijn.

We nemen dit enorm serieus. Dit is iets wat niet had mogen gebeuren, en we doen er alles aan om te zorgen dat dit, of een vergelijkbaar incident, niet nog eens kan gebeuren. Bedankt aan iedereen die geduld heeft gehad en ons hierin het vertrouwen blijft geven.

Het is (voor mij) geen probleem om te wachten op meer duidelijkheid, kunnen jullie aangeven wanneer je verwacht wel te kunnen reageren?

[nescafe]

Van de statuspagina:

quote: https://status.mijn.host/history/inci_VseS2S9nmxWRhh

Er is een kritieke kwetsbaarheid in PHP aangekondigd (CVE-2026-109618 en CVE-2026-109619). Het PHP-team brengt vandaag om 16:00 uur een beveiligingsupdate uit.

Vooruitlopend daarop hebben we op al onze webhostingservers een tijdelijke beveiligingsmaatregel genomen: de PHP-instelling session.upload_progress is uitgeschakeld. Je hoeft zelf niets te doen en je websites blijven gewoon werken. Alleen de zelden gebruikte functie om de voortgang van uploads via PHP-sessies bij te houden is tijdelijk niet beschikbaar.

Zodra de bijgewerkte PHP-versies beschikbaar zijn, installeren we die op al onze servers. We houden je via deze pagina op de hoogte.

[True]

nescafe schreef op woensdag 21 oktober 2026 @ 09:18:
Van de statuspagina:


[...]

Deze kreeg ik werk ook door, dertien in dozijn hoge CVSS met mitigerende actie, verder niet zo bijzonder toch?
Voor de twijfelaars dit heeft niets te maken met de storage verstoring.

[EDIT]

Zie ook nieuws: PHP waarschuwt voor twee ernstige bugs die makkelijk uit te buiten lijken en een aantal van de comments daaronder. Dit is slechts één mogelijke aanvalsroute en waarschijnlijk niet voldoende om de aanvallen tegen te houden.

[ Voor 9% gewijzigd door EDIT op 21-10-2026 09:51 ]

[RobertMe]

True schreef op woensdag 21 oktober 2026 @ 09:43:
[...]


Deze kreeg ik werk ook door, dertien in dozijn hoge CVSS met mitigerende actie, verder niet zo bijzonder toch?

offtopic:
Die mitigerende actie is er één van de twee die rond gaan. Daarnaast heeft een van de PHP devs aangegeven dat deze wijziging niet helpt. Dus "met mitigerende actie" is het waarschijnlijk niet. En dertien in een dozijn zou ik hem waarschijnlijk ook niet noemen. Waarbij dit de eerste keer is dat ik me kan herinneren dat PHP zo'n groot security issue heeft dat ze een aankondiging van de security release doen zodat iedereen klaar kan zitten.

[Mr. Jinx]

Bericht van Mijn.Host:

We hebben de standaard PHP-versies (8.2 en hoger) van DirectAdmin op al onze servers bijgewerkt naar de gepatchte versies. Gebruikt je website de standaardversie, in de PHP Selector “native” genoemd, dan is je website beschermd.

De overige PHP-versies die je via de PHP Selector kunt kiezen, worden geleverd door CloudLinux. CloudLinux verwacht de updates daarvoor vanavond uit te brengen. Zodra ze beschikbaar zijn, voeren we ze direct door. Tot die tijd blijven de tijdelijke beveiligingsmaatregelen actief.

[ Voor 12% gewijzigd door Mr. Jinx op 21-10-2026 17:59 ]

[RobinF]

Mr. Jinx schreef op woensdag 21 oktober 2026 @ 17:30:
Bericht van Mijn.Host:

We hebben de standaard PHP-versies (8.2 en hoger) van DirectAdmin op al onze servers bijgewerkt naar de gepatchte versies. Gebruikt je website de standaardversie, in de PHP Selector “native” genoemd, dan is je website beschermd.

De overige PHP-versies die je via de PHP Selector kunt kiezen, worden geleverd door CloudLinux. CloudLinux verwacht de updates daarvoor vanavond uit te brengen. Zodra ze beschikbaar zijn, voeren we ze direct door. Tot die tijd blijven de tijdelijke beveiligingsmaatregelen actief.

Er staat nu "Inmiddels hebben we ook de meeste PHP-versies uit de PHP Selector van CloudLinux bijgewerkt naar gepatchte versies. Voor een aantal versies en servers heeft CloudLinux de updates nog niet beschikbaar gesteld. (...)"

Alleen, welke versies dan?

[jugger naut]

De php versie bij mij is geupdate van 8.4.22 naar 8.4.26

code:

php -v
PHP 8.4.26 (cli) (built: Oct 21 2026 00:00:00) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.26, Copyright (c) Zend Technologies
    with the ionCube PHP Loader v15.5.0, Copyright (c) 2002-2026, by ionCube Ltd.
    with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies

Volgens mij is er iets niet goed gegaan. De patched version is 8.4.27..

[mijn.host]

Alle servers zijn inderdaad voorzien van de PHP patch.

@jugger naut: CloudLinux heeft de fixes voor CVE-2026-109618 en CVE-2026-109619 in de bestaande alt-php-builds verwerkt (een backport). Het versienummer van PHP blijft daardoor gelijk, en alleen het releasenummer van het pakket gaat omhoog, bijvoorbeeld alt-php85 8.5.11-5 en alt-php84 8.4.26-5. Ook de EOL-versies 5.6 tot en met 8.1 hebben zo een gepatchte build gekregen. In jouw output zie je “built: Oct 21 2026”. Dat is de gepatchte build.

Wil je toch de nieuwste upstream-release gebruiken? Kies dan in de PHP Selector voor “native”. Dat is de PHP-versie van DirectAdmin, en die hebben we bijgewerkt naar de officiële release.

[LoneGunman]

code:

PHP versie  8.5.11 (Ondersteunt 64bit waarden)

^ Dit is nog de PHP-versie op een Shared Hosting-server (Wordpress). Moet dit ook niet 8.5.12 zijn @mijn.host ?

De update komt net binnen via hyperping, dank daarvoor:

Toelichting op de PHP-versies: in de PHP Selector kan het lijken alsof je PHP-versie nog niet is bijgewerkt. Je ziet daar bijvoorbeeld 8.4.26 in plaats van 8.4.27, of 8.5.11 in plaats van 8.5.12. Toch is je versie wel gepatcht.

CloudLinux, de leverancier van deze PHP-versies, heeft de beveiligingsfix in de bestaande versies verwerkt. Het versienummer is daardoor gelijk gebleven, maar de beveiligingsupdate zit erin. Ook de oudere PHP-versies (5.6 tot en met 8.1) zijn op deze manier bijgewerkt.

Wil je het zelf controleren? Kijk dan in phpinfo() naar de “Build Date”. Is die 21 oktober 2026 of later, dan is je PHP-versie gepatcht.

Wil je liever het officiële versienummer van PHP gebruiken? Kies dan in de PHP Selector voor “native”. Die versie hebben we bijgewerkt naar de officiële release van PHP.

[ Voor 71% gewijzigd door LoneGunman op 22-10-2026 09:39 ]

[Asphyxion]

Ik heb vandaag mijn site van Versio (Neostrada) naar mijn.host laten verhuizen. Deze ervaring was echt super. Goede en snelle communicatie. De site, mail en domeinnaam zijn zonder problemen verhuisd.

Vanavond maar eens spelen met alles wat mijn.host en Direct Admin te bieden heeft.

[PloeteraarCoffe]

@mijn.host Is dat releasenummer (dus die -5) ook ergens in DirectAdmin te zien? Op shared hosting heb je niet altijd shell-toegang, en in phpinfo zie je alleen 8.4.26 staan.

[AlbanVE]

Mochten er nog mensen zijn die zich afvragen waarom ssl certs niet automatisch vernieuwen, bij DirectAdmin zijn er wat vernieuwingen aan dit onderdeel geweest, even een ticketje geopend of er bij subaccounts niet automatisch 'Enable ACME' kan aangevinkt worden maar kan helaas niet:

DirectAdmin heeft recent inderdaad een grote update doorgevoerd aan het beheer van SSL-certificaten, waarbij is overgestapt op een vernieuwd ACME-systeem. Bij bestaande domeinen staat 'Enable ACME' standaard vaak nog uitgeschakeld. Het is daarom aan te raden om 'Enable ACME' in te schakelen, zodat automatische vernieuwingen via dit nieuwe systeem blijven verlopen.

DirectAdmin zet 'Prefer wildcard certificates' in deze nieuwe interface helaas standaard aan. Ons eerdere advies blijft echter van kracht: tenzij je met wisselende subdomeinen werkt, kun je dit het beste uitschakelen. Wildcard-certificaten vereisen validatie via DNS (DNS-01), wat storingsgevoeliger is door propagatie en achterblijvende records. Zonder wildcard verloopt de validatie via een stabielere HTTP-controle op de webserver.

Er is in DirectAdmin helaas geen centrale knop op reseller-niveau om dit in één keer voor alle subaccounts aan te passen, aangezien dit per domein is gekoppeld. Je kunt dit per gebruiker instellen door via Account Manager naar 'List Users' te gaan, te kiezen voor 'Login as' en bij Account Manager → SSL Certificates onder het tabblad 'ACME settings' de opties aan te passen ('Enable ACME' aan en 'Prefer wildcard certificates' uit). Beheer je veel accounts, dan kan dit eventueel ook geautomatiseerd via de DirectAdmin API worden bijgewerkt.

[nescafe]

@AlbanVE met de toevoeging dat 'Prefer wildcard certificates' bij voorkeur wordt ingeschakeld om het lekken van informatie over je subdomeinen via Certificate Transparency te voorkomen.

Sterker nog, voor mijn domeinen zou ik 'Require wildcart certificate' willen kunnen instellen en dat is volgens mij ook hoe het op dit moment geïnterpreteerd wordt: geen fallback naar HTTP-01 challenge maar een nette error met log in je message system.

[ Voor 41% gewijzigd door nescafe op 04-11-2026 12:38 ]

[EnigmA-X]

Uhh, ik krijg allemaal rare foutmeldingen in het controlpanel.



Meer mensen hier last van? Worden DNS changes wel goed doorgevoerd? Lijkt erop dat iemand lekker zit te knutselen aan het production frontend?

[ Voor 11% gewijzigd door EnigmA-X op 13-11-2026 12:17 ]

[Room42]

@EnigmA-X, alleen al bij het laden van de pagina. Op de statuspagina nog niks te zien. Ik zie het overigens alleen bij .nl-domeinen.
Of het systeem nog goed werkt, kun je natuurlijk testen met een testrecord.

Sowieso kun je even een mailtje naar de support sturen.

[Room42]

Ik kreeg wel nu deze; gaan ze Google gebruiken



Not a fan.

[EnigmA-X]

Room42 schreef op vrijdag 13 november 2026 @ 12:24:
@EnigmA-X, alleen al bij het laden van de pagina. Op de statuspagina nog niks te zien. Ik zie het overigens alleen bij .nl-domeinen.
Of het systeem nog goed werkt, kun je natuurlijk testen met een testrecord.

Sowieso kun je even een mailtje naar de support sturen.

Het bewerken lijkt nog wel te functioneren - dat ticket had ik al ingelegd

[EnigmA-X]

Room42 schreef op vrijdag 13 november 2026 @ 12:24:
Ik kreeg wel nu deze; gaan ze Google gebruiken

[Afbeelding]

Not a fan.

Oef. Dat vind ik ook niet bepaald een vooruitgang. Lekker bedacht qua soevereiniteit.....

[mijn.host]

EnigmA-X schreef op vrijdag 13 november 2026 @ 12:15:
Uhh, ik krijg allemaal rare foutmeldingen in het controlpanel.

Er was inderdaad een korte hiccup, inmiddels verholpen.

Room42 schreef op vrijdag 13 november 2026 @ 12:24:
Ik kreeg wel nu deze; gaan ze Google gebruiken

Klopt inderdaad, Europese modellen zitten helaas nog niet op hetzelfde niveau. We proberen dit daarom in ieder geval transparant te melden. Wel overwegen we om zelf een model te draaien, maar vergt dit tijd.

[Room42]

mijn.host schreef op vrijdag 13 november 2026 @ 12:59:
[...]

Klopt inderdaad, Europese modellen zitten helaas nog niet op hetzelfde niveau. We proberen dit daarom in ieder geval transparant te melden. Wel overwegen we om zelf een model te draaien, maar vergt dit tijd.

Al eens gekeken naar hostyourai.com? Die hosten verschillende modellen in NL, tevens het bedrijf achter loes.ai.