Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 40 reacties
Submitter: skunkah

Afgelopen nacht waren een groot aantal .nl-domeinen niet bereikbaar nadat er iets mis ging met de update van de .nl-zonefile. De Sidn heeft een oude zonefile moeten terugzetten om de storing te verhelpen.

De Sidn bevestigt tegenover Tweakers.net dat een groot deel van de .nl-namespace tussen 00.00 en 06.40 plat lag. Volgens Lieke Hoogeveen, woordvoerster van de organisatie, waren zeker honderdduizend domeinnamen onbereikbaar. "De storing ontstond na onderhoud aan het domeinregistratiesysteem. Na afloop bleek dat een aantal glue records uit de zonefile waren verdwenen. Door caching bleef de schade aanvankelijk beperkt, maar na verloop van tijd waren de nameservers van providers niet meer te bereiken, waarna ook een groot aantal domeinen onbereikbaar werden. Verschillende isp's zouden na het constateren van de storing tevergeefs contact hebben gezocht met de Sidn, schrijft iSpam.

De Sidn heeft vanochtend de zonefile van woensdag 18.00 teruggezet, waarna de domeinen weer bereikbaar waren. "Domeinaanvragen die na die tijd zijn ingediend, zijn dan ook niet verwerkt in de zonefile", aldus Hoogeveen. De Sidn heeft het domeinregistratiesysteem uit voorzorg tijdelijk uitgeschakeld en onderzoekt waar het probleem lag. Nieuwe aanvragen kunnen dan ook niet verwerkt worden. Wanneer het systeem weer wordt ingeschakeld kon Hoogeveen niet zeggen.

Moderatie-faq Wijzig weergave

Reacties (40)

Het beste blijft ook je authorative ns te spreiden over verschilende tlds, bv.

ns1.isp.nl
ns2.isp.eu
ns3.isp.be
ns4.isp.net

In dat geval was alleen de .nl buiten service en was een hoop meer blijven werken, dus je moet niet alleen je nameservers in een verschillend netwerk hebben ook een verschillend tld is belangrijk.
Grapjas.. En waar denk je dat die authorative namesservers opgegeven moeten worden voor jouw .nl domein? Juist die staan in de nameserver van SDIN (whois). SDIN submit ze vervolgens naar de root servers terrecht komen. In de root servers staat dan je records ns1.isp.nl en ns2.isp.eu. In de nameservers van de TLD's (SDIN en EurID) worden die hostnames weer omgezet naar IP's zodat je nameservers ook daadwerkelijk te bereiken zijn. De glue records zijn hiervoor verantwoordelijk en dat ging nu juist fout vannacht.

Omdat de nameserver(s) van SDIN niet (goed) werkte, weet dus niemand wat de authorative nameservers voor jouw domein zijn. Wat dus inhoud dat niemand weet dat IP 1.2.3.4 gebruikt moet worden om ns2.isp.eu te benaderen voor het domein bedrijf.nl.

Wat mij persoonlijk beangstigd is dat SDIN blijkbaar geen backup maakt voordat ze een wijziging doorvoeren. Nu hebben ze een backup van de vorige dag (18:00 uur) moeten terug zetten, wat op mij zeer amateuristisch overkomt.

[Reactie gewijzigd door Niemand_Anders op 29 mei 2008 10:24]

De glue-records zijn verantwoordelijk voor het vertalen van ns1.isp.nl naar 1.2.3.4. Als je als authoritative nameservers voor "domein.nl" zowel ns1.isp.nl als ns2.isp.com had gebruikt, dan was je domein vannacht gewoon bereikbaar geweest.

De DNS-servers van SIDN konden je namelijk nog WEL vertellen wat de authoritative nameservers voor het domein zijn, maar niet welk IP er dan hoort bij ns1.isp.nl (mits dat een van de getroffen glue-records was). Omdat je als client weet dat zowel ns1.isp.nl als ns2.isp.com authoritative zijn, probeer je vervolgens het IP bij ns2.isp.com te achterhalen. Doordat er met die glue-records niets mis is, kun je alsnog de nameservers voor domein.nl bereiken.
Zoiets vermoede ik al, op een gegeven moment waren er via Telfort internet nog maar een paar Nederlandse sites te bereiken, .com was al helemaal niet meer te bereiken. Mijn torrents liepen ook gewoon door. Ik vermoede al dat er een nameserver probleem was, ik heb vervolgens een VPN gelegd naar de universiteit wat gelukkig nog lukte. En vervolgens heerlijk kunnen internetten zonder problemen.

Maar zo zien we maar weer hoe afhankelijk we van het SIDN zijn...
.com staat buiten het beheer van de SIDN.. Dus daar kunnen ze niets aan doen, blame Telfort :)
Telfort had eerder vannacht (weer eens) een storing in de routering, daar kwamen jouw problemen vandaan :)
Grapjs, die GLUE records zijn enkel nodig als de nameservers hetzelfde domein van de domeinnaam zelf liggen. Bijvoorbeeld:

mijndomein.nl
- ns1.mijndomein.nl
- ns2.mijndomein.nl

Dit voorbeeld heeft GLUE records nodig (anders heb je kip-of-ei situatie)

mijndomein.nl
- ns1.mijndomein.nl
- ns2.mijndomein.com

Het tweede NS record heeft geen GLUE in de mijndomein.nl zone nodig, want die kan gewoon geresolved worden. (Geen kip-of-ei). Als ns1.mijndomein.nl dus onbereikbaar is, kan men gewoon verder recursen op ns2.mijndomein.com

Het "trukje" dat Tomsworld dus voorstelt is geldig.

[Reactie gewijzigd door RedShift op 29 mei 2008 11:01]

@Niemand_Anders
Valt toch wel mee, niet? Voor hetzelfde geld was het een back-up van een week oud, of was er helemaal geen back-up. Dát zou pas vervelend zijn.
De back-up die ze gebruikt hebben was maar max. 12 uur oud. De meeste professionele domeinaanvragen worden dusdanig ver van te voren gedaan dat een extra dagje geen probleem moet zijn.
Edit2: Komkom, overdrijf je nou niet een beetje? Die back-up was van 1800 uur, de update vond in een tijdsbestek van 6 uur na de laatste update plaats. Dat vind ik accuraat genoeg. Je kunt anders wel aan het updaten blijven. Als ik weet dat er automatisch (cronjob oid) elke avond om 1800 een back-up wordt gemaakt, dan ga ik er een paar uur later niet nóg een maken.

[Reactie gewijzigd door Rick2910 op 29 mei 2008 12:53]

Nee, valt niet mee! Iedereen weet toch dat voordat je een wijziging doorvoert je een backup moet maken?! Dat is hier niet gebeurt waardoor zij terug hebben moeten vallen op een reguliere backup. Deze reguliere backups zijn bedoeld voor onvoorziene problemen.

Dit was niet een onvoorzien probleem omdat ze daadwerkelijk (BEWUST) wijzigingen aan de nameservers waren aan het maken.

Op zo'n moment 'vergeten' een backup te maken is ronduit schandalig.


Via SIDN kun je ook al enige tijd online wijzigingen doorvoeren. Dit kun je dus ook buiten kantoortijden doen. Dat betekend dat wijzigingen gedaan naar 18:00 uur dus niet in de backup zitten.
Het probleem is dat ze niet weten wat de fout veroorzaakt heeft
dus welke backup is de laatste die de fout niet bevat?

Dat weten ze dus niet, dus plaatsen ze een terug die zeker werkt, om dan de fout op te zoeken, en daarna de rest terug te verwerken...

Er zullen wss geen aanvragen verloren gegaan zijn, gewoon even vertraagd...
Precies... Dit is vaker gebeurt!!! 2 weken geleden zelfs! Toen hadden ze wel een backup gemaakt. Toen het mis ging werd de backup terug gezet en merkten niemands iets van. ;)
Waar haal jij uit de tekst dat die van woensdag 18:00 een reguliere backup is?

Dat is jou vermoeden misschien zijn ze wel om 18:00 uur begonnen met deze wijziging.
Er waren vooral problemen met het stuk gluerecords voor zover ik weet, voor de rest was de impact beperkter.
Oh dat is lastig, zijn er dan nu niet aan aantal providers die hun DNS records nog wel gelijk hebben staan als die bug? Of zie ik dat verkeerd. Een klant belde ons vanmorgen op dat hij een site niet kon benaderen die wel bij ons werkte via het domeinnaam... mogelijk dat dat het problem was?
Tussen 0.00 en 06.40? Ik zou toch zweren dat een groot aantal .nl domeinen het al eerder op de avond ook al niet meer deden.
Onderhoud was tussen die periode gepland.
Ja ik had er ook al last van rond 9 uur die avond. Msn bleef het wel doen, maar veel websites waren niet te bereiken.
Het beste blijft ook je authorative ns te spreiden over verschilende tlds, bv.
Om dit soort geintjes te verhelpen wel ja, maar dat levert wel een zooi extra requests op omdat de glue niet direct meegestuurd kan worden.
Hier in totaal 24.000 domeinen plat doordat ons domein niet meer gevonden kon worden.

Ik weet ook nog een andere partij waar er dik 20.000 offline waren en nog een partij waar er rond de 80.000 offline waren.
Google zou hier toch geen last van hebben gehad? Zat vannacht te zoeken via Google en kreeg te lezen dat "highly trained monkeys" mijn probleem op gaan lossen... :+

Het was laat.... O-)
Ik kon Google anders niet meer bereiken, nu.nl weer wel, maar .com en Google.nl lagen er helemaal uit. Althans via Telfort Internet, via een VPN naar de universiteit was het wel weer mogelijk en werkte alles weer lekker.

En ja het was laat ;-)...
Gelukkig een externe factor dus. Ik had namelijk al errors van oa mijn nagios monitoring. De mailflow check gaf vannacht errors, dat kan dus kloppen als ie niet meer kan resolven.
Haha, grappig om dit nu zo op Tweakers te lezen de volgende ochtend. :*)
Mijn mail- en webserver was vannacht ook niet te bereiken op domeinnaam. Alleen op IP. Vond dit al vreemd. Dacht eerst dat het aan m'n domein-hoster lag, want die site lag er ook uit (PCextreme).
Maar nu weet ik helemaal hoe de vork in de steel zit :)
Als je als dns server de ip's van openDNS opgeeft, dan was er voor jou vannacht waarschijnlijk niets aan de hand .. ;-)
Ook openDNS had er last van bij mij.
Volgens mij moeten ze weer (nabij) 6 miljoen Euro weggooien in een nieuw systeem.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True