Site, app en kaartautomaten van NS liggen eruit, vermoedelijk door migratie

Een migratie van de Nederlandse Spoorwegen lijkt fout te zijn gegaan, waardoor de site en app de hele ochtend onbereikbaar zijn geweest. De nameservers gingen over van Akamai naar Argeweb. Ook de kaartautomaten lagen eruit.

Door de wijziging werkte de DNSSEC niet meer en was de site dus niet langer bereikbaar. De NS verwees de nameservers terug naar Akamai, maar door caching zat er enige vertraging tussen het doorvoeren van die wijziging en het weer beschikbaar zijn van de site.

Volgens AlleStoringen hadden gebruikers sinds een uur of tien maandagochtend problemen met de site. De NS zegt tegen Tweakers dat de storing optrad op de site, de app én de kaartautomaten op stations. "Dit is echt een grote storing", aldus een woordvoerder. De informatieborden op stations werkten naar behoren en gebruikers van het openbaar vervoer konden voor reisinformatie terecht bij 9292.

Directeur Wouter Stoutjesdijk van YourHosting, waar Argeweb onder valt, zegt dat de storing niet bij Argeweb vandaan kwam. "Onze systemen hebben goed gewerkt. Wij wisten ook niets van deze wijziging naar onze nameservers. We hebben onze hulp aangeboden voor het oplossen van de NS-storing, maar de oorzaak lag niet bij ons."

Update, 13.54 uur - De reactie van YourHosting is toegevoegd. De NS bevestigt dat de storing is opgelost. "Het lag aan een fout in een DNS-update", aldus de woordvoerder.

Reacties (127)

[CAPSLOCK2000]

De nameservers gingen over van Akamai op Argeweb. De NS probeert het fiksen. Ook de kaartautomaten liggen eruit.

Door de wijziging werkt de dnssec niet meer en is de site dus niet langer bereikbaar. NS probeert dat te fiksen door de nameservers terug te verwijzen naar Akamai, maar door caching zit er enige vertraging tussen het doorvoeren van die wijziging en het weer beschikbaar zijn van de site.

Als ik terugkijk via dnsviz.net* dan lijkt de migratie opzich wel goed te zijn gegaan vanuit de kant van Argeweb. Op enig moment veranderen deDNS-records en gaat alles over Argeweb en dat lijkt (op grond van wat ik er nu nog van kan zien) goed te zijn gegaan. Ik kan niet zeker zeggen of de nameservers van Argeweb daarbij alles goed hebben gedaan, maar het lijkt er wel op.
Het probleem dat ik zie/vermoed is dat de nameservers van Argeweb alleen hun eigen sleutels kennen en niet de sleutels die door Akamai gebruikt werden. Op het moment van overgang werden alle oude records in de cache daarmee oncontroleerbaar. Helaas heb je daar als beheerder minder controler over dan je zou willen. Het verlagen van de TTL helpt, maar is geen garantie.

Kort daarna worden de NS-records weer terug richting Akamai gezet maar zonder ook de bijhorende sleutels te publiceren. Dat was waarschijnlijk de verkeerde beslissing en op dat moment was het zeker stuk. Zojuist (ongeveer 12:50) is DNSSEC helemaal uitgeschakeld voor ns.nl. Ik denk dat men daar aardig in paniek is. Succes allemaal!

* pas op, dnsviz.net is niet compleet. Dat werkt alleen als iemand op het knopje drukt om een domein te testen. Het kan best zijn dat de configuratie nog anders geweest maar dat dnsviz.net het niet gezien heeft.

[Blokker_1999]

TTL op een lage waarde zetten is altijd een goed idee als je DNS aanpassingen gaat doen. Dan verklein je net de caching voor even. Als eenmaal alles gevalideerd is en opnieuw rustig is dan kan je de TTL terug verhogen.

En als je DNSSEC doet lijkt het mij ook aan te raden deze tijdens de migratie even uit te zetten net om dit soort problemen te voorkomen. De kans dat een aanvaller zit te wachten op het moment dat je DNSSEC even voor een uurtje uitschakeld lijkt mij enorm klein te zijn.

DNSSEC is niet het eenvoudigste, en kan me zo inbeelden dat men hier geen rekening mee had gehouden bij het plannen van de migratie. Het is niet iets wat je regelmatig doet of waar je regelmatig aan denkt. Dus begrijp wel dat ze hier de mist in zijn gegaan.

[NL_Windhoos]

Je zou de nieuwe KSK's en ZSK's kunnen introduceren als 'pre-published' keys binnen de oude omgeving om deze vooraf dus te publiceren en aan de kant van SIDN de nieuwe DS-records opvoeren om de transitie zo soepel mogelijk te laten gaan. Dit vereist wel de nodige flexibiliteit van desbetreffende (DNS) providers die niet altijd wordt geboden (het liefst doe je dit met het handje met bind ). Als dat er niet is kun je echt geen andere kant op dan unsignen -> verhuizen -> signen.

Hoewel ik ook inschat dat men DNSSEC waarschijnlijk over het hoofd heeft gezien (niet unsigned, überhaupt geen nieuwe DS records geüpload) en er verder niet over is nagedacht tijdens deze migratie, ben ik het er alleen niet mee eens dat dit begrijpelijk is. DNSSEC bestaat juist voor het niet accepteren van forged DNS Data door een chain of trust te creëren met de Internet Root Name Servers, iets wat je juist verbreekt op het moment dat je desbetreffende DNS omgeving gaat verhuizen.

Succes aan de betrokkenen, ook al is het nu een kwestie van cache afwachten en daarna je nieuwe DS-records plaatsen.

[Ryangr0]

Als je ooit deze fout hebt gemaakt, maak het hem nooit weer. Ik denk dat je gewoon een random medior de DNS change hebben laten maken. Hier houd je natuurlijk wel rekening mee. Als je zaken zoals Akamai geïntegreerd heb neem ik aan dat er wat kennis in house is.

[Habbie]

Nette uitleg. Ik vermoed dat de migratie naar Argeweb alleen helemaal niet de bedoeling was Wat "zeker stuk" betreft, na beide nameserver-wijzigingen was er nog een uur waarin de verkeerde DS in caches stond.

Over dnsviz: naast dat dat inderdaad alleen de snapshots heeft waar mensen om hebben gevraagd, is het onhandigste dat DNSViz helemaal "groen" kan zijn terwijl je weet dat er nog oude data in caches zit. Ik heb heel wat migraties mis zien gaan omdat mensen goed nieuws van DNSViz kregen en dus dachten dat ze alvast de volgende stappen konden gaan zetten.

[Habbie]

Ergens tussen 12:07 en 12:15 zonet is het foute DS-record (van Argeweb) eindelijk uit de SIDN-database verwijderd. SIDN zal deze update om 12:30 gaan deployen, deze is dan om 12:50 live. Uiterlijk een uur later, om 13:50, is de foute DNSSEC DS dan uit alle caches, en gaat hopelijk alles overal weer werken.

[gpon]

Van Akamai (grote CDN wat ook als anti DDos fungeert) naar de kleine Nederlandse provider, Argeweb?

[CAPSLOCK2000]

Van Akamai (grote CDN wat ook als anti DDos fungeert) naar de kleine Nederlandse provider, Argeweb?

Klinkt als een mooie stukje digitale souvereiniteit. Laat onze kritieke infrastructuur (zoals spoorwegen) niet afhankelijk zijn van een Amerikaans bedrijf. Of in ieder geval zo min mogelijk....

[gpon]

Leuk idee maar er zijn geen Nederlandse alternatieven met dezelfde capaciteiten, kennis en kunde. Cloudflare en Akamai zijn als netwerk zo ongeveer de enige die enorme hoeveelheden traffic aankunnen.

[CAPSLOCK2000]

Leuk idee maar er zijn geen Nederlandse alternatieven met dezelfde capaciteiten, kennis en kunde.

Die gaan er ook niet komen als we alles bij Amerikaanse bedrijven blijven onderbrengen.

Cloudflare en Akamai zijn als netwerk zo ongeveer de enige die enorme hoeveelheden traffic aankunnen.

Als het gaat om DDOS-bescherming zijn die inderdaad groter en (dus) beter, maar ik weet niet of dat relevant is, want ik weet niet wat voor diensten de NS precies afneemt bij Argeweb.

Dan nog blijft de vraag of Cloudflare/Akamai zakelijk gezien ook beter zijn dan het aanbod van Argeweb. Misschien is Argeweb wel veel goedkoper voor de diensten die de NS nodig heeft.

[djwice]

Valt NS niet onder kritieke infrastructuur? Daarvoor zijn er andere oplossingen in Nederland beschikbaar.

[CAPSLOCK2000]

Ja, daarom denk ik niet dat het hier om DDoS-bescherming gaat en de vergelijking met Cloudflare en Akamai dus niet op die grond gemaakt moet worden.

[ANdrode]

Er zijn zat partijen die deze hoeveelheid data aan kunnen. Misschien verlies je dan wel wat features. Maar dat heb je bij de keuze tussen Akamai en Cloudflare ook al (één van twee is veel beter in observability).

Kijk je binnen Nederland? Dan i3d en allerlei CDNs die voor media gebruikt worden. In de EU? Veel grotere lijst. Telt volgens jouw juristen de locatie van het hoofdkantoor? Dan kan yandex . Het hoeft niet allemaal Amerikaans te zijn.

[gpon]

Dat betwijfel ik, want als ik kijk naar de meeste grote websites in de EU, of het nou een krant, tv-zender of vervoer is. Allemaal zitten ze met hun online infra bij Akamai, Cloudflare of AWS. Moet toch een reden voor zijn?

[Spykie]

Er zijn zat Europese aanbieders. Maar onbekend maakt onbemind.

Netnod is bijvoorbeeld een grootte: https://www.netnod.se/dns

[ANdrode]

Voor hosting (en vooral hoger niveau diensten, zoals managed databases, managed k8s) is het op dit moment lastiger.

Wil je een CDN waar je goede support bij krijgt, maar ook extreem scherpe randjes én een grote leercurve én wat minder observability accepteert (wat Akamai in mijn ervaring is), dan zijn er EU opties.

[Yankovic]

Waarom zou ns.nl die vrijwel enkel relevant is voor reizigers binnen Nederland enorme hoeveelheden traffic moeten aankunnen?

[readefries]

Voor normaal gebruik niet, maar wel als iemand het nodig vindt op grote schaal verkeer naar de NS te (laten) sturen

[William_H]

Dan hebben we daar in NL altijd nog de Nawas voor.

[bzzzt]

Soevereiniteit is prachtig, maar principes heb je weinig aan als kritieke infrastructuur door een kleine DDoS uit de lucht getrokken kan worden.

[CAPSLOCK2000]

Soevereiniteit is prachtig, maar principes heb je weinig aan als kritieke infrastructuur door een kleine DDoS uit de lucht getrokken kan worden.

Waarom zou Argeweb fundamenteel niet in staat zijn om met een kleine DDOS om te gaan?

In alle eerlijkheid denk ik dat de DDoS-beveilinging van Akamai in praktijk beter is, maar het kan nog steeds genoeg zijn. We weten niet precies wat de NS afneemt en wat het doel van deze migratie is.

Ik hoop dat ze bij de NS een risico-analyse hebben gedaan en wellicht is daar uit gekomen dat het risico van bezwijken onder een DDoS kleiner is dan andere risico's. Aan werkende servers heb je niks als een buitenlandse rechter je de toegang ontzegt. Het is maar net welk probleem je probeert te voorkomen.

[bzzzt]

Waarom zou Argeweb fundamenteel niet in staat zijn om met een kleine DDOS om te gaan?

Ok, ik bedoel relatief kleine vergeleken met wat Akamai kan doorstaan. Heb wat ervaringen via werk met anti-DDoS bij Nederlandse datacenters en hoewel ze behoorlijk capabel zijn halen ze het qua capaciteit en tegengaan van storingen nog niet bij de US partijen.

Je hebt helemaal gelijk dat het een afweging is. Dus is blind kiezen voor 'soevereiniteit' zonder de gevolgen goed te doorzien imo geen goed plan.

[Spykie]

[...]

Ok, ik bedoel relatief kleine vergeleken met wat Akamai kan doorstaan. Heb wat ervaringen via werk met anti-DDoS bij Nederlandse datacenters en hoewel ze behoorlijk capabel zijn halen ze het qua capaciteit en tegengaan van storingen nog niet bij de US partijen.

Je hebt helemaal gelijk dat het een afweging is. Dus is blind kiezen voor 'soevereiniteit' zonder de gevolgen goed te doorzien imo geen goed plan.

Daarom zit je voor je anti-DDoS niet bij een NL datacentrum maar bij de NaWas.

[bzzzt]

Daarom zit je voor je anti-DDoS niet bij een NL datacentrum maar bij de NaWas.

En dat is een Nederlandse dienst die het aflegt tegen de US diensten op dat vlak. Ken bedrijven die daar vandaan gemigreerd zijn omdat ze alsnog veel last van DDoS aanvallen hadden.

[Habbie]

1 theorie die op de mij beschikbare feiten past is dat ze hun -registrar- wilden wisselen van de oude (vorig jaar was het BT Nederland N.V, weet niet hoe recent dat nog waar was) naar Argeweb, en dat de automation bij Argeweb meteen de DNS even instelde op de default Argeweb-settings. Maar het verhaal kan ook anders zijn dan dit.

[gpon]

Dat denk ik ook. Lijkt mij erg onwaarschijnlijk dat zij van Akamai afstappen en alles bij Argeweb onderbrengen.

[Habbie]

DNS is sinds einde ochtend ook alweer terug naar Akamai, alleen met foute DNSSEC. Dat lijkt nu ook goed te gaan komen.

[3dfx]

En Argeweb wat nu onderdeel is van Yourhosting, een partij die weinig lijkt te doen met dat merk.
Althans, pas moest ik voor iemand inloggen op het klantenpaneel, en het zag het er nog hetzelfde uit als 15-20 jaar geleden volgens mij.
Ik ben een voorstander van "Als het niet kapot is, probeer het dan niet te fiksen", maar dit is wel extreem

[SPee]

Dit is dus niet goed getest en het migratie en rollback script waren niet compleet.

Meestal moet een belangrijke wijziging goed getest worden én wordt uitgevoerd op een zeer rustig moment. Ze hebben dus gedacht "1 minuut na de ochtendspits is hét moment". Volgens mij was tussen 10-14 het 'in uiterste noodzaak' moment en is het standaard moment voor impactvolle wijzigingen in de nacht van zaterdag op zondag.

[Keypunchie]

Volgens mij was tussen 10-14 het 'in uiterste noodzaak' moment en is het standaard moment voor impactvolle wijzigingen in de nacht van zaterdag op zondag.

Dit is een wat achterhaald inzicht voor de missie-kritische IT sector. Mid jaren '00 was dit inderdaad nog de praktijk, maar in de jaren '10, mede door verregaande virtualisatie van systemen, en introductie van niet-monolitische architecturen met veel meer 'loose coupling' zijn ook impactvolle wijzigingen juist dingen die je bij voorkeur overdag doet.

De techniek (denk aan Kubernetes, microservices, gedistribueerde databases, etc.) zorgt ervoor dat het mogelijk is om zelfs complexe wijzigingen aan te brengen terwijl de toko doordraait.

En vanuit menselijk perspectief is het wenselijk, omdat personeel veel beter presteert overdag (met wakkere kop) en dat escalaties en/of het bijtrekken van specialisten van andere teams (bvb. infrateams, of teams van aanpalende applicaties) veel makkelijker gaat.

Het komt nog wel eens voor, hoor, weekendwerk. En er wordt zeker wel rekening gehouden met piek/daluren. Bij banken zie je bijvoorbeeld dat rond Sinterklaas en Kerst er nog steeds change-luwe periodes worden gepland, maar de nacht is zeker niet meer het standaard voorkeursmoment.

[Reactie gewijzigd door Keypunchie op 25 augustus 2025 14:02]

[William_H]

Dat is allemaal "fine and dandy", maar dat geldt niet voor een DNS change.

Waarschijnlijk is er gedacht zoals jij aangeeft, met andere changes doen we dat ook vlak na de ochtendspits. Alleen niet even nagedacht dat je bij DNS wijzigingen geen controle hebt over cache etc. Dus dit soort dingen doe je wel het liefst op een luw moment.

Hier gaat een Change manager wel ff een douwtje krijgen, want de risico's zijn niet goed doorgenomen. Daarnaast, de eerste dag na de vakantie voor regio Noord (waar een groot deel van de Randstad onder valt), ook niet echt handig...

[CAPSLOCK2000]

Dit is dus niet goed getest en het migratie en rollback script waren niet compleet.

Rollback is in dit geval wel een beetje lastig. DNS wordt gecached en daar heb je als beheerder van een domein maar beperkte controle over. Je kan zelf een korte cache tijd opgeven maar die kan en mag genegeerd worden.

Als het eenmaal fout in de cache staat dan kun je daar eigenlijk niks meer aan doen anders dan wachten tot de cache verloopt. Die DNS-caches zitten immers bij providers en bij mensen thuis en kunnen dus niet worden gerest door de beheerder van het domein dat problemen heeft.

[gpon]

Feit dat ze niet meer op Twitter zitten helpt ook niet mee qua communicatie.

[Alex3]

En het forum is opgeheven. Een dikke middelvinger naar de reizigers.

[gpon]

Nooit geweten dat zij een forum hadden. Voor updates keek ik altijd op hun social media.

[William_H]

Want daar kun je tegenwoordig zolekker op kijken als jegeen account hebt. Doe dan Mastodon / fediverse. Daar kan iedereen bij, zonder account.

[readefries]

Klinkt alsof ze vergeten zijn om DNSSEC sleutels aan te maken en publiceren voor de migratie. Los daarvan is het sowieso handig om ter voorbereiding de TTL van je records op 5 minuten te zetten zodat je snel kan schakelen.

[WernerL]

De TTL staat zelfs op 20 seconden dus dat lijken ze wel gedaan te hebben. Alleen ik heb het idee dat de oude omgeving op Akamai nu ook stuk is aangezien de A-record daar nu naar verwijst terwijl ns.nl hier niet werkt.

[Reactie gewijzigd door WernerL op 25 augustus 2025 12:16]

[3raser]

De TTL van de NS records staat op 24 uur, dus terug schakelen naar je oude nameservers bij Akamai is niet zomaar gebeurd. Dan kan je A-record wel op 5 seconden staan maar dat doet niets als hij naar de verkeerde nameserver verwijst.

[readefries]

Auch, dat is wel heel hoog in het oog van een migratie

[FurrBeast]

Ik snap dat bedrijven zo'n migratie graag tijdens kantooruren wilt doen, maar voor een bedrijf als NS kan zo'n migratie toch wel 's nachts en eventueel in het weekend plaatsvinden?

[2cents]

Wellicht hebben ze dat gedaan en is de DNS cache pas vanochtend voor deze records verlopen.

[pascallj]

Dan zorg je ervoor dat je de TTL op tijd verkort en wacht je de originele duur van de TTL af zodat je zeker weet dat iedereen de nieuwe TTL heeft overgenomen. Daarna ga je pas wijzigingen uitvoeren. Alle DNS resolvers die zich aan de standaard houden zullen dan weinig last hebben van caching problemen en je kunt ook snel weer terug naar de oude situatie.

[Punkbuster]

Dan snap je als NS weinig van DNS

[Aalard99]

Mogelijk dat de NS dit heeft uitbesteed aan een leverancier die een fout heeft gemaakt?

[GrooV]

Want in het weekend rijdt niemand met de trein? Weekend/nacht migraties zijn kut en als het fout gaat zit je met niet uitgeruste medewerkers die de nacht mogen doorhalen.

Migraties doe je op normale tijdstippen of eventueel vroeg in de ochtend maar niet in de nacht. Als het fout gaat heb je de tijd tegen je.

[SPee]

Er rijden in het weekend een heel stuk minder treinen, dus er hebben weinig mensen last van. En hoewel vervelend, zou het met een goed uitgewerkt proces makkelijk uit te voeren zijn. Voor de kritische systemen is het tijdslot de zaterdagnacht met in noodgeval uitloop tot de zondagochtend.

En wat bedoel je met "vroeg in de ochtend"? Want tussen 06:00 en 10:00 is het spits en dus drukte bij de NS. Dan kun je beter om 24:00 beginnen dan om 04:00, want als het fout gaat, heb je meer tijd. Na 10:00 is er een korte rustiger moment, totdat de dienst wisselt en iets later om 16:00 de spits weer begint.

[CivLord]

Dooe de week en vooral in de spits reizen de meeste mensen op voor hen bekende trajecten, op voor hen gebruikelijke tijden. Zij hebben maar zeer beperkt reisinformatie via de site en de app nodig en reizen met OVpay, een eigen OV-kaart of een OV-kaart van het werk.
In het weekend reizen de meeste mensen juist op incidentele trajecten voor een dagje weg. Juist zij hebben reisinformatie nodig en maken relatief veel gebruik van kaartautomaten.

Een storing op de site, app en kaartautomaten heeft dus veel meer impact in het weekend, ondanks dat er dan juist minder reizigers zijn, dan door de week in de spits.

[Robbierut4]

Migraties doe je op normale tijdstippen of eventueel vroeg in de ochtend maar niet in de nacht. Als het fout gaat heb je de tijd tegen je.

Bij mijn bank wordt onderhoud aan de app/systemen altijd in de nacht van zaterdag op zondag gedaan.

Het kan blijkbaar dus wel.

[William_H]

En bij overheid (DigiD, UWV etc) gebeurt dat inderdaad ook.

[lenwar]

Daar is helemaal niets algemeens over te zeggen.

Het verschilt per bedrijf/organisatie en per applicatie. De ene applicatie wil je 'juist overdag' doen. De andere juist buiten kantooruren, of op zaterdag middennacht, omdat dat het enige moment is dat het over heel de wereld weekend is in onze tijdzone.

Denk je dat een bank zegt "Hey, mensen van de AEX. Kunnen jullie even een uurtje stoppen. We gaan een migratie doen." (En voor de AEX mag je iedere beurs in de wereld invullen.)

De ene applicatie kan gewoon op gecontroleerde momenten plat gaan, de andere moet 24x7 beschikbaar zijn (los van hoe haalbaar dit gegarandeerd is.)

[Sparks.nl]

Ik kom weer op ns.nl dus gefixed lijkt het.

[WernerL]

Gefixed of verwijst de DNS weer tijdelijk naar de oude omgeving? Ik gok het laatste.

Bij mij werkt het in ieder geval nog niet. Ik krijg de melding "Dit domein is geregistreerd, maar heeft geen website."

[Carlos0_0]

Bij mij werkt het prima, en kan ook een route plannen.

[Alex3]

Tijdelijk dan, want nu is-ie weer uit de lucht.

[wild_dog]

... Als je zulke kritische DNS aanpassingen moet maken, dan ga je toch eerst de TTL drastisch verlagen, juist zodat die vertraging minimaal is? Een hosting provider waar ik een domeinnaam heb zet die standaard op 90 seconden ofzo.

[gertvdijk]

... Als je zulke kritische DNS aanpassingen moet maken, dan ga je toch eerst de TTL drastisch verlagen, juist zodat die vertraging minimaal is? Een hosting provider waar ik een domeinnaam heb zet die standaard op 90 seconden ofzo.

Ik vermoed dat je nog niets met DNSSEC gedaan hebt.

Als je de reguliere records verlaagt maar daarbij DNSSEC vergeet te voorbereiden (nieuwe public key publishen bij oude hoster, oude public key ook publishen bij nieuwe hoster), dan gaat het gruwelijk mis ondanks welke TTL je kiest. Bovendien heeft SIDN een speciale ceremonie voor het opnemen van die public keys (DS records) naar de .nl (parent zone), dus je kan het zo laag zetten als je wilt, maar zo werkt dat niet.

[readefries]

Precies, al snap ik dat je hier niet meteen aan denkt als dit je eerste migratie is bij een DNSSEC domein

[king006]

Opmerkelijk dat het nu fout ging. Ze hebben eerder (23-7) namelijk nsinternational.nl ook naar Argeweb gezet met de juiste nameservers en DNSSEC. Bij nsinternational.com zijn ook wijzigingen geweest rond 20-4. Daar lijken alleen de nameservers gewijzigd te zijn.

Gezien nsinternational.nl al eerder bij Argeweb is geplaatst, kan ik mij haast niet voorstellen dat Argeweb niet wist dat de NS hiermee bezig is ;)

[Reactie gewijzigd door king006 op 25 augustus 2025 19:19]

[William_H]

Ik vermoed dat nsinternational.nl de enige site is die op die server/dns zit. Nu wordt de NS.nl site gemigreerd en blijkbaar hangt daar meer aan vast, en dat geeft mede daardoor gedonder op een groter vlak.

[king006]

Ja, is ook niet handig om de nameservers dan te wijzigen naar Argeweb. Iemand heeft een vinkje gemist denk ik.