Storing bij laadpalen Eneco kwam niet door Cloudflare, maar DNS-storing

De storing waardoor Eneco Connectric-wallboxen meerdere dagen niet meer werkten, werd veroorzaakt door een DNS-storing. Dat meldt een woordvoerder aan Tweakers. Eerder wees het bedrijf naar de wereldwijde Cloudflare-storing van vorige week.

De storing begon vorige week dinsdag en werd afgelopen maandag opgelost. Door een aanpassing op de DNS-server konden de laadpalen geen verbinding maken met de lokale websocket van de eigen backend, legt de woordvoerder uit. Daardoor werd het voor de laadpalen ook onmogelijk om data naar het beheerplatform van de laadpunten te sturen. Wat er precies misging op de DNS-server, wordt nog onderzocht. Door de server terug te zetten naar een vorige configuratie kon Eneco de storing oplossen.

Het bedrijf heeft een offlinebeleid van twee weken. Dat houdt in dat de laadpas twee weken onthouden blijft en dat gebruikers hun thuislaadpalen na de laatste 'online' laadbeurt in ieder geval twee weken lang kunnen blijven gebruiken. Normaliter is dat volgens Eneco ruim, maar omdat de storing meerdere dagen duurde, zijn er waarschijnlijk toch mensen geweest die een paar dagen niet hebben kunnen laden. Eneco schat in dat 'enkele honderden' klanten hinder hebben ondervonden van de storing.

De woordvoerder erkent dat het probleem relatief eenvoudig op te lossen was en zegt dat de oplossing normaal gesproken veel sneller was doorgevoerd. Hij noemt het feit dat de Cloudflare-storing samenviel met de DNS-storing een 'perfect storm': "Als je in de verkeerde hoek aan het zoeken bent, kun je zoeken tot je een ons weegt, maar dan ga je het probleem niet vinden."

Reacties (39)

[Kalix]

Standaard IT flowchart gevolgd? Kan ik iemand anders de schuld geven? Ja Cloudflare! Ow, dat was het niet? Dan gaan we verder zoeken. Blijkbaar weten ze zelf niet (goed genoeg) hoe hun systemen afhankelijk zijn van welke partijen. Als ze één blik op de webinterface van hun eigen palen hadden gewaagd, dan stond daar direct de oorzaak vermeld: Backoffice DNS Query failure.

Gelukkig waren het maar 'enkele honderden' klanten die hinder ondervonden. Dat is niet alleen hinder, maar in veel gevallen ook hogere kosten. Als ik thuis laadt kost dat de helft minder dan op een publieke paal in mijn dorp.

[digibaro]

Als ze één blik op de webinterface van hun eigen palen hadden gewaagd, dan stond daar direct de oorzaak vermeld: Backoffice DNS Query failure.

Dat is wel ernstig. Mijn paal lag er gedurende het hele incident er 5 dagen achter elkaar uit. Vooral de minimale communicatie via de app, website en de servicedesk vond ik erg irritant.

[sebastienbo]

Het is totaal niet accepteerbaar dat je niet meer kan laden door dit probleem.

Dat zou willen zeggen dat tijdens cyberaanvallen we altijd zonder laadpalen zitten?

Is het zo eenvoudig om het kritieke infrastructuur plat te trekken?

[JMS 450]

Daarom krijgen we van de overheid ook een folder in de bus.
En ja onze infrastructuur is zo erg afhankelijk geworden.

Je kan het ook omdraaien, waarom geen paal in eigen beheer? (omdat je je eigen stroom niet gratis in een lease auto gooit)

[yade]

In eigen beheer of niet, het is technisch mogelijk laadsessies te starten en te onthouden als er (tijdelijk) geen connectiviteit is met de backoffice. Dit is gewoon een instelling. Je eigen paal zou op zijn minst een whitelist moeten hebben voor de bijhorende passen. Dat is een keuze van Eneco.

Maar goed, daarom eiste ik admin toegang tot mijn laadpaal. Dat was me toch een partij lastig om voor elkaar te krijgen, maar wel gelukt. Ik heb hem nu aan een eigen backoffice hangen. Dat mag ook gewoon, maar moet je wel kunnen opzetten.

[GMJansen]

Wees blij dat je geen Shell Recharge paal hebt die naar 50five gegaan is...

[vlijmen]

Eerste idee, Cloudflare heeft een issue, dat zal de oorzaak zijn.

Cloudflare terug online, onze diensten niet, wat hebben we gedaan?

Oh een change, kan dat de oorzaak zijn, ja/nee. Maakt niet uit rollback om zeker te zijn.

Veel ingewikkelder zou het niet moeten zijn. Het gebeurt bij ons "regelmatig" dat we issues ontdekken en dan doen we van alles een rollback zelfs als we zeker zijn dat het geen impact zou kunnen hebben. Gewoon om zeker te zijn.

[SPee]

Alleen wel raar dat nadat ze wisten dat Cloudflare niet het probleem was, ze nog 5 dagen nodig hadden om die change terug te draaien.

[Punkbuster]

0 DAYS
SINCE IT WAS DNS
(It's always DNS)

😜

[marcelvb]

Als je een probleem hebt, altijd eerst deze site checken: https://isitdns.com/

[BlaTieBla]

DNS is als elektriciteit, gas en water. De wereld stopt als het wegvalt

[downtime]

Hij noemt het feit dat de Cloudflare-storing samenviel met de DNS-storing een 'perfect storm': "Als je in de verkeerde hoek aan het zoeken bent, kun je zoeken tot je een ons weegt, maar dan ga je het probleem niet vinden."

Vreemd. Je kent je eigen applicatie toch? Dan weet je toch in welke hoeken je het moet zoeken?

Dit klinkt gewoon alsof iemand er wat te makkelijk vanaf wilde zijn. Cloudflare ligt eruit, wij gebruiken Cloudflare, dus het ligt aan Cloudflare. En achteraf: Cloudflare doet het weer dus alle meldingen van vandaag kunnen klakkeloos dicht. Niet nodig om de klagers even te bellen/mailen en te vragen of het voor hun ook weer werkt.

[R_Zwart]

Jij hebt nooit iets aan de hand gehad waarbij je niet direct de root cause kon vinden? Ej waarvan je achteraf vond dat het eigenlijk wel een simpele oorzaak had? Zo nee, dan kan kan je als architect tonnen per jaar verdienen.

[jongetje]

Toen ik applicaties beheerde heb ik echt geen 2 weken downtijd gehad. Vraag me ook af of er wel goed getest wordt met een representatieve testomgeving.

En vaak is het iets kleins maar het gevaar bestaat dat er meteen al aanames worden gedaan en iedereen de verkeerde kant op zoekt. Al dan niet door een werkomgeving waar wat angst cultuur heerst een de mensen die het moeten oplossen door een dominante collega (of manager) de verkeerde kant moeten zoeken.

[CAPSLOCK2000]

Toen ik applicaties beheerde heb ik echt geen 2 weken downtijd gehad. Vraag me ook af of er wel goed getest wordt met een representatieve testomgeving.

Ik vind twee weken ook wel erg lang voor iets dat in je eigen product zit.
De iets minder mooie maar modernere variant is dat het helemaal niet hun 'eigen' product is maar dat het extern is ingekocht bij een tussenpartij(en) die het ook niet zelf hebben ontwikkeld. Niemand heeft overzicht over het hele project (van developer tot en met eindgebruiker) en door strenge contracten kan en wil niemand over de grens kijken.

Het nieuwsbericht leest een beetje alsof iemand te snel de conclusie heeft getrokken dat het aan CloudFlare lag waarna ze lekker naar huis gegaan met de gedachte "we kunnen niks doen en moeten wachten op CloudFlare".

Maar goed, dat zijn ook maar aannames en wellicht zijn wij het ook aan de verkeerde kant aan het zoeken

[Pasteis]

[...]

Vreemd. Je kent je eigen applicatie toch? Dan weet je toch in welke hoeken je het moet zoeken?

Dit klinkt gewoon alsof iemand er wat te makkelijk vanaf wilde zijn. Cloudflare ligt eruit, wij gebruiken Cloudflare, dus het ligt aan Cloudflare. En achteraf: Cloudflare doet het weer dus alle meldingen van vandaag kunnen klakkeloos dicht. Niet nodig om de klagers even te bellen/mailen en te vragen of het voor hun ook weer werkt.

het zal je eens verbazen hoeveel bedrijven hun eigen applicatie onvoldoende kennen. kan bijv. komen door dat kennis onvoldoende is geborgd en is weggelopen.

Ik heb bij een IT-bedrijf gezeten en daar was je maar al te blij als je een probleem kon verhelpen door bepaalde services te herstarten, moest je verder gaan zoeken kwam spontaan bij iedereen het zweet op zijn voorhoofd.

[Invictus66]

Die paragraaf over het offlinebeleid is wel erg vreemd. Het beleid zegt 2 weken, maar als er dan een paar dagen uitval is werkt het toch niet. Dit klopt toch ergens niet.

[Admiral Freebee]

Misschien is het twee weken sinds de laatste laadsessie?

[MrFax]

Stel je hebt je laadpaal al 10 dagen offline voor de storing... meer hoef ik niet uit te leggen denk ik.

[smoove]

daarom verstanding om secondary DNS bij een andere partij te plaatsen?

[CH4OS]

High(er) availability lost configuratie problemen anders niet magisch op of zo, dus een extra back-up DNS server is niet per definitie de oplossing.

[Reactie gewijzigd door CH4OS op 27 november 2025 20:12]

[pe0mot]

Geen real-time monitoring op de primaire processen?

Als DNS niet wordt bewaakt, mag je je zorgen maken over de rest.

[xxs]

Met zo’n beheer heb je geen hack nodig om de zaak plat te leggen.

[peize9]

Toch leuk om te zien dat de server van onze Lan Party (The Reality) betere monitoring heeft dan Eneco... Beschamend om dingen zo slecht te doen als zo'n vitaal bedrijf.

[digibaro]

Vreemd verhaal die 2 weken. Ik heb 5 dagen niet kunnen laden, vanaf het begin van de storing. Uit/Aan van de paal gaf geen verbertering. Pas aanbieden en rood knipper signaal.

[Clu3M0r3]

DNS probleem ... daar hebben meerdere bedrijven in de afgelopen tijd mee te maken gehad. Toeval of gebrek aan ter zake deskundig personeel?

Conceptueel gezien is DNS geen rocket science maar een klein foutje kan zeer grote gevolgen hebben.

En dat is een van de redenen dat je niet iemand met zeepogen aan DNS configuraties moet laten sleutelen

[xxs]

4 eyes principe hanteren.

[Clu3M0r3]

4 zeepogen helpen in dat geval wellicht ook niet. Probleem zit naar alle waarschijnlijkheid in de processen en de procedures die worden gevolgd. Testen kost immers tijd en geld en dan komen bonussen en aandeelhoudersbelangen in het geding. De klant betaalt immers toch wel, is de gedachte.

Ben een beetje cynisch, vat het niet persoonlijk op.