Sidn getroffen door storing domeinnaamregistratie

De Sidn kampte vrijdag met een storing in het domeinnaamregistratiesysteem en de whois-interface. De oorzaak van de storing is vooralsnog onbekend, maar deze lijkt nu opgelost.

Sinds vrijdagochtend weerhield een storing bij de Stichting Internet Domeinregistratie Nederland de klanten van de registratie-instantie ervan nieuwe domeinnamen te registreren. Ook de whois-database kon gedurende de storing niet geraadpleegd worden. Aanvragen voor domeinnaamregistraties werden opgeslagen tot de dienstverlening weer op gang kwam. Ook de generatie van de zonefiles, bestanden die de verwijzingen naar domeinnamen bevatten en elke twee uur worden bijgewerkt, werd tot vrijdagavond uitgesteld.

Hoewel de oorzaak van de storing nog onbekend is, heeft de Sidn de dienstverlening vrijdagavond weer hervat. Om half zeven 's avonds werden de systemen weer geactiveerd en werd een tussentijdse zonefile gegenereerd. De reguliere zonefilegeneratie van acht uur 's avonds vond zonder incidenten plaats. Volgens Sidn-woordvoerster Lieke Hoogeveen zullen de systemen nauwlettend in de gaten worden gehouden om een eventuele herhaling van de storing indien mogelijk in de kiem te smoren. Ook meldde zij aan Tweakers.net dat de registratie-achterstand een uur na het herstel van de dienstverlening was weggewerkt.

Reacties (28)

[Ulysses]

Ik vind het toch altijd maar knap dat server management van dit soort mega-instanties. Ik kan me de laatste keer dat er iets fout ging bij SIDN eigenlijk niet goed herinneren (2006 volgens de gerelateerde artikelen). Wel een beetje wazig dat ze zeggen de aard van de storing niet te kennen tegen een site als T.Net. Ik bedoel dat komt dan weer een beetje over als "Kweenie, we hebben gereboot en toen was het over." ofzo ... Zo beheerde ik vroeger ook altijd Windows systemen, trial-error... mag toch hopen dat dat niet het geval is geweest. En vermoed dan ook dat de verantwoordelijke netwerkbeheerder best een heel technisch verhaal had kunnen ophangen over de oorzaak maar dat ze dat omwille van duidelijkheid naar het publiek toe achterwege hebben gelaten.

quote: http://www.sidn.nl/ace.ph...te_verstoring_17_30u.html

In de tussentijd blijven we nader onderzoek doen naar de exacte toedracht van de verstoring.

[burne]

Wel een beetje wazig dat ze zeggen de aard van de storing niet te kennen tegen een site als T.Net.

Een perswoordvoerder weet natuurlijk alles van de automatisering en kan na 2 minuten babbelen met de techneuten tot in detail uitleggen wat er aan de hand was en zinnige antwoorden geven op de vragen van een stel nerds-met-een-nieuwssite.

[Verwijderd]

De perswoordvoerder weet niets van automatisering en kan niet uitleggen wat er aan de hand was of zinnige antwoorden geven op vragen van belanghebbenden zoals deelnemers van de SIDN, die verdomd graag willen weten wat er aan de hand was.

Dat is behoorlijk kwalijk.

[wildhagen]

Hoezo is dat kwalijk? Ben eens realistisch, het is een perswoordvoerder, je kan niet verwachten dat die specialist zijn op elk gebied/specialisme dat een bedrijf (in dit geval de SIDN) in huis heeft. Het zijn geen technici.

De woordvoerder kan alleen maar de aan hem/haar gecommuniceerde info doorgeven, en een verbindende rol tussen de pers en de betreffende afdeling uitvoeren.

Als de woordvoerder geen uitleg kan geven is dat eerder te wijten aan óf de IT-afdeling die kennelijk onjuiste danwel onvolledige informatie aan de woordvoerder doorgespeeld heeft, óf aan het feit dat hij/zij misschien niks mag zeggen ivm bedrijfspolicies of beslissingen van het management etc.

[burne]

Dat hoef je mij niet uit te leggen, ben sinds 1996 'deelnemer'. Van de andere kant heb ik liever dat techneuten ongestoord het probleem oplossen en later uitleggen wat er aan de hand was dan dat ze om de tien minuten een of andere drammerige hostert uit moeten leggen wat er aan de hand is, wat ze van plan zijn te gaan doen en vervolgens in een overloze discussie verzeild raken met iemand die vast heel goed in php is maar niets weet van unix systeembeheer.

Overal gaat wel eens wat mis en oplossen is belangerijker dan verantwoording afleggen aan puistige gassies die tussen hun lessen door een webdesing-bureuatje hebben. Ik generaliseer even.

[Verwijderd]

Kwalijk omdat "we weten het eigenlijk niet, maar het werkt weer" niet echt veel vertrouwen geeft. Als dat de reactie is omdat andere verklaringen, niet mogen, niet kunnen of niet bestaan, is dat niet zo best.

Het vertrouwen in SIDN is al niet groot door de overdreven procedures qua papierwerk en het falen bij de introductie van numerieke domeinnamen.

Overigens weet ik niet wat je bedoelt te zeggen met puistige gassies, webdesing-bureuatjes en php-ers die niets weten van unix systeembeheer, maar ik denk dat je sommige van je concullega's daar een klein beetje tekort mee doet, en SIDN behoorlijk overschat.

[wildhagen]

Kwalijk omdat "we weten het eigenlijk niet, maar het werkt weer" niet echt veel vertrouwen geeft. Als dat de reactie is omdat andere verklaringen, niet mogen, niet kunnen of niet bestaan, is dat niet zo best.

Beetje heel erg kortzichtig.

Men geeft alleen aan dat het weer werkt en dat men de oorzaak nog niet kent.

Zoals het artikel ook al zegt: is men nog druk doende om de oorzaak van het probleem te vinden en indien mogelijk op te lossen.

Of had je liever gezien dat ze alles maar down gelaten hadden tot ze een permanente oplossing gevonden hebben? Nee, éérst breng je de zaak weer in de lucht (al dan niet via een work-around) zodat je klanten weer verder kunnen, en dán ga je naar de oorzaak zoeken en, indien mogelijk, maatregelen nemen om dit in de toekomst te voorkomen.

[Verwijderd]

Dat is helemaal niet kortzichtig. Als ze niet eens kunnen, willen of mogen aangeven dat het om falende hardware, software of medewerkers gaat, getuigt dat van weinig begrip van hun deelnemers.

Misschien dat je jouw klanten kunt vertellen dat je "het niet weet" en dat het "nu gewoon weer werkt", maar dat kun je niet tegen klanten die minstens zoveel technische kennis hebben als jezelf. Die verliezen dan gewoon hun vertrouwen. En dát is dus kwalijk.

Als ze overigens nog niet weten wat de oorzaak is, kunnen ze beter maar vast aan de gang gaan met het aanschaffen van een systeem als dat van dns.be of EURid. Zijn we meteen van die papierwinkel af.

[Verwijderd]

Dat is helemaal niet kortzichtig. Als ze niet eens kunnen, willen of mogen aangeven dat het om falende hardware, software of medewerkers gaat, getuigt dat van weinig begrip van hun deelnemers.

ze leveren een dienst aan klanten en die doet het nu weer, de klant heeft verder niets te maken waarom de dienst het even niet deed. het is niet hun hardware of software.

Misschien dat je jouw klanten kunt vertellen dat je "het niet weet" en dat het "nu gewoon weer werkt", maar dat kun je niet tegen klanten die minstens zoveel technische kennis hebben als jezelf. Die verliezen dan gewoon hun vertrouwen. En dat is dus kwalijk.

Ligt er aan welke klanten het vragen als jij servers beheerd van klanten en hij gaat stuk. Kan je natuurlijk aangeven wat er mis was als er ongevraagd wordt. ingeval van hardware is dat niet zo moeilijk. In het geval van software is het soms best lastig aan te geven waarom iets uitgevallen was en het stoppen en starten van een services of server de boel weer aan de praat kreeg. Kan me best voorstellen dat je dan niet direct de oorzaak hebt gevonden en misschien ook wel helemaal niet vindt. Anders dan je de applicatie de schuld kan geven.

Je weet de oorzaak nog niet maar je gaat wel investeren in een nieuw systeem
Mag hopen dat jij daar bij je huidige werkgever dit soort fratsen niet uithaalt voor je klanten.

[Verwijderd]

Ze leveren een dienst aan klanten en die doet het nu weer, de klant heeft verder niets te maken waarom de dienst het even niet deed. het is niet hun hardware of software.

De klant heeft wel te maken met waarom dat zo is, want de klant moet weten of dat vaker gaat voorkomen of niet.

Ligt er aan welke klanten het vragen als jij servers beheerd van klanten en hij gaat stuk. Kan je natuurlijk aangeven wat er mis was als er ongevraagd wordt. ingeval van hardware is dat niet zo moeilijk. In het geval van software is het soms best lastig aan te geven waarom iets uitgevallen was en het stoppen en starten van een services of server de boel weer aan de praat kreeg. Kan me best voorstellen dat je dan niet direct de oorzaak hebt gevonden en misschien ook wel helemaal niet vindt. Anders dan je de applicatie de schuld kan geven.

Als er in elk geval wordt aangegeven of het om hardware, eigen software of third party software gaat, kun je iets beter inschatten over de gevolgen voor de dienstverlening in de toekomst. Even aangeven dat het om software gaat moet niet teveel moeite kosten.

Overigens mag je iets meer je best doen om duidelijker te schrijven.

Je weet de oorzaak nog niet maar je gaat wel investeren in een nieuw systeem
Mag hopen dat jij daar bij je huidige werkgever dit soort fratsen niet uithaalt voor je klanten.

Ik noem dat sarcasme.

[TheCapK]

Lijkt inderdaad op een reboot-en-draaien-maar-weer kwestie. Je vraagt je af wat ze dan precies draaien daar aan OS, programmatuur en apparatuur. Misschien zouden andere mensen daar iets uit kunnen filteren!

[Douweegbertje]

Als in jouw bedrijfje X iets gebeurt, hoef je ook niet perse alles DIRECT te melden aan de media, redenering van iedereen hier is een beetje vaag.
Volgens jullie moet er na A altijd een B komen..
Wellicht heeft SIDN er juist voor gekozen er mee te wachten om een technische verklaring naar buiten te brengen.
Wellicht willen ze het niet eens naar buiten brengen, dan is het gewoon dikke pech voor je als je het toch wilt weten.

oh en edit:
Het feit dat jullie niets weten, heeft niets te maken met het feit dat zij het wel weten, en dat ze dit gaan oplossen. Dit even voor wildhagen die denkt dat hij bij Sidn werkt

[Reactie gewijzigd door Douweegbertje op 27 juli 2024 00:44]

[Batje4]

Dikke pech is een beetje vergaand, laten we het erop houden dat je als leverancier je afspraken nakomt.
Uitgangspunt in elke overeenkomst is dat je je afspraken nakomt. Omgedraaid: SIDN hoeft dus niet iets doen wat niet is afgesproken; dus als niet is afgesproken tot bijv een volledige technisch inhoudelijke voortgangsrapportage per 15 minuten, dan is het dus heel redelijk dat dat niet gebeurd.

Het enige wat ik daarna nog wil weten is, of het een terugkerend issue kan worden, en hoe ze dat denken te gaan voorkomen. Wat inhoudelijk het probleem is, is verantwoordelijkheid SIDN en niet boeiend. Je wil dienstverlening; hoe ze dat realiseren is hun ding zolang ze hun afspraken maar nakomen.

Als vervolgens de service levels niet gehaald worden, of bijv informatiebeveiligingsissues zijn geweest, dan kunnen we daar ook weer met de afspraken in de hand, een boom over op gaan zetten.

En die boom zet je niet op met de techneut, niet met de perswoordvoerder, maar met een service manager.

[Reactie gewijzigd door Batje4 op 27 juli 2024 00:44]

[blorf]

Pardon? De SIDN is een stichting en dient transparant te zijn.
Als er technische problemen zijn hoort daar uitleg bij.

[Jaco69]

De storing was in het weekend.... Het is nog steeds weekend.

Waarschijnlijk zullen ze morgen beginnen met de oorzaak te achterhalen.

[bas-r]

Een maand of vijf geleden was er nog een storing downtime: het duurde een halve dag voor domeinnaam registraties er doorheen kwamen.
http://www.webhostingtalk.../137057-sidn-storing.html

[Reactie gewijzigd door bas-r op 27 juli 2024 00:44]

[Verwijderd]

Maar als ze oplossing hebben gevonden weten ze toch ook wel waar ze het probleem moeten zoeken Maar alles is weer up and running

[Verwijderd]

Das nogal kort door de bocht natuurlijk. Als de oplossing was een server rebooten en toen deed alles het weer weet je natuurlijk nog niks over de oorzaak.

[DJrDJ666]

maar wel netjes dat de achterstand supersnel was weggewerkt

[Wunk]

Was een paar maanden geleden 's nachts ook een storing waarbij de glue records van de hostende nameservers werden verwijderd als je een nameserverwijziging voor een domeinnaam aanvroeg die op die nameserver stond.

Resultaat was dat er ineens HEEL veel .nl zones niet meer werkten die nacht omdat nameservers bij bosjes omvielen en niet meer te vinden waren op internet.

[Verwijderd]

Niks onbekend! De site whois.domain-registry.nl had last van een overactieve McAfee-installatie die "externe toegang" blokkeerde, waar dus ook poort 80 onder viel.

Ik had echt wel gedacht dat de storing gespecificeerd werd en zie nu dat er niemand (tweakers? ) de reden heeft gevonden... Blijkbaar willen ze hun goede naam behouden door te zeggen "onbekende reden" ipv "we hebben gewoon een update uitgevoerd zonder te testen".

[Verwijderd]

Eerlijk gezegd zou me het een rot zorg zijn wat er aan de hand was. Het belangrijkste is dat ze het hebben opgelost. Snap niet dat iedereen altijd precies willen weten wat er aan de hand was. is volstrekt onbelangrijk en niet nodig om te weten. Het is niets meer dan pure nieuwsgierigheid.

[wildhagen]

Snap niet dat iedereen altijd precies willen weten wat er aan de hand was. is volstrekt onbelangrijk en niet nodig om te weten.

Pardon? Dit is wel heel erg kortzichtig.

Als je de oorzaak van een probleem kent, kan je gericht dingen doen om ervoor te zorgen dat dit probleem zich in de toekomst niet opnieuw voor gaat doen.

En nee, dat kan inderdaad niet altijd, maar soms kan het wel degelijk. En ja, van sommige problemen kun je de oorzaak niet achterhalen, maar bij het merendeel kan het wel.

En voorkomen (proactief werken) is nog altijd beter dan genezen (reactief werken)...

[Reactie gewijzigd door wildhagen op 27 juli 2024 00:44]

[PcDealer]

Oorzaak onbekend, maar hoe is het opgelost? Reboot van de servers of zo? Hoor Lieke Hoogeveen uit

[Reactie gewijzigd door PcDealer op 27 juli 2024 00:44]