Herstel DNS problemen binnen een uur voor MKB en webshops

Controleer eerst je nameservers en de kernrecords A, MX en TXT: daarmee verhelp je het grootste deel van hostinggerelateerde DNS-storingen. Als DNSSEC-fouten in het spel zijn of de storing langer dan een paar uur duurt, stop dan met zelf sleutelen en schakel een professionele partij in. Professionele partijen kunnen dit soort DNS-incidenten voor MKB-bedrijven en webshops uit handen nemen.

Kort samengevat:

• Controleer de nameservers, kernrecords en DNSSEC-instellingen zorgvuldig voordat je zelf ingrijpt, vooral bij langdurige storingen.
• Verlaag de TTL voorafgaand aan wijzigingen en test de DNS-propagatie met externe resolvers om cache-problemen te voorkomen.
• Een fout in DNSSEC-ondertekening kan het hele domein onbereikbaar maken, waardoor een gefaseerde uitrol en back-upplan essentieel zijn.
• Bij complexe problemen zoals nameserverwissels, langdurige downtime of e-mailproblemen is het verstandig direct een professionele partij in te schakelen.
• Een goede documentatie en structureel beheer van DNS-instellingen helpen herhaalde storingen te voorkomen en de continuïteit te waarborgen.

Inhoudsopgave

• Stappenplan om een DNS-probleem snel te diagnosticeren
• Veelvoorkomende oorzaken van DNS-fouten en hoe je ze oplost
• DNSSEC: bescherming die verkeerd geïmplementeerd averechts werkt
• Wanneer schakel je een professional in?
• Waarom een verkeerde DNS-cache je site laat “verdwijnen”
• Wat betekenen de meest voorkomende DNS-foutmeldingen?
• Misconfiguraties bij subdomeinen corrigeren
• Hoe firewalls en netwerkconfiguraties DNS-storingen veroorzaken
• Zakelijk perspectief: waarom structureel DNS-beheer loont
• Wat NLXS doet bij een DNS-storing
• Bronnen

Stappenplan om een DNS-probleem snel te diagnosticeren

Voordat je iets aanpast, moet je weten wat er precies mis is. Een DNS-probleem oplossen begint niet bij het wijzigen van records, maar bij het isoleren van de oorzaak. Ga systematisch te werk met deze checklist.

1. Bepaal de omvang. Is de website voor iedereen onbereikbaar of alleen voor jou? Test vanaf een ander netwerk of gebruik een mobiele verbinding zonder wifi om lokale cache-effecten uit te sluiten.
2. Check recente wijzigingen. Is er kort geleden een migratie, nameserverwissel of hostingoverstap geweest? Negen van de tien DNS-fout meldingen ontstaan direct na zo’n wijziging.
3. Zoek uit waar de nameservers staan. Dit is niet altijd bij je registrar. Log in bij de registrar om te zien welke nameservers actief zijn, en controleer vervolgens bij de hostingpartij of de zonebestanden daar overeenkomen.
4. Controleer de kernrecords. Gebruik nslookup of dig om A, CNAME, MX en TXT-records op te vragen en te vergelijken met wat er zou moeten staan.
5. Verlaag de TTL en monitor de propagatie. Zet de TTL tijdig naar 300 seconden voordat je wijzigingen doorvoert, en volg de verspreiding via publieke resolvers zoals whatsmydns.net of dnschecker.org.
6. Verzamel bewijsmateriaal. Screenshots van de zone-instellingen, de output van dig en nslookup, en een tijdlijn van wijzigingen zijn onmisbaar als je alsnog hulp inschakelt.

Pro-tip: Voer wijzigingen altijd één voor één door en documenteer elke stap. Zo weet je bij een fout direct welke aanpassing je moet terugdraaien, in plaats van te gokken tussen vijf mogelijke oorzaken.

Wie structureel grip wil houden op zijn domeinconfiguratie, leest ook onze uitleg over de rol van DNS-beheer bij hosting voor kleine bedrijven.

Veelvoorkomende oorzaken van DNS-fouten en hoe je ze oplost

De meeste DNS-problemen bij MKB-bedrijven en webshops vallen terug op een handvol herkenbare patronen. Ken je deze patronen, dan verhelp je een DNS-fout meestal binnen een uur in plaats van een dag.

A-records: het IP-adres klopt niet meer

Een A-record wijst een domein naar een IP-adres. Na een serverwissel blijft het oude adres soms nog dagenlang actief in caches. Test eerst lokaal via je hosts-bestand of het nieuwe IP-adres al werkt, voordat je het A-record live aanpast. Klopt er iets niet na de wijziging? Rol dan terug naar het vorige IP-adres en zoek de oorzaak in alle rust, in plaats van onder tijdsdruk te blijven doorpuzzelen.

CNAME en root-domeinbeperkingen

Een CNAME-record verwijst een subdomein naar een ander domein, maar kan technisch niet samen met andere records op hetzelfde niveau bestaan. Veel beheerders proberen een CNAME op het root-domein zelf te zetten (dus zonder www) en lopen dan tegen conflicten aan met bestaande MX- of TXT-records. De oplossing: gebruik voor het root-domein altijd een A-record of, waar de provider dat ondersteunt, een ALIAS/ANAME-record.

MX-records en e-mailcontinuïteit

E-mail is vaak het eerste wat klanten missen bij een DNS-storing, en het laatste waar beheerders aan denken. Houd bij een providerwissel de oude mailserver actief totdat je zeker weet dat de nieuwe MX-records overal zijn doorgekomen. Controleer tegelijk de SPF- en overige TXT-records: een verkeerd ingestelde SPF-regel zorgt ervoor dat legitieme e-mail als spam wordt gemarkeerd, ook als de MX-records zelf correct staan.

Nameserverwissels duren structureel langer

Een wijziging van een los record verspreidt zich via de TTL van dat record. Een nameserverwissel werkt anders: die verandering moet via de hele DNS-hiërarchie opnieuw worden opgehaald, wat vaak langer duurt dan een enkele recordwijziging. Verlaag daarom de TTL tijdig voor een geplande wijziging naar een lagere waarde zoals 300 seconden, zodat caches sneller vernieuwen zodra je de knop omzet.

• Plan nameserverwissels buiten piekuren, bij voorkeur in het weekend.
• Houd de oude configuratie minimaal 48 uur actief als terugvalscenario.
• Test na de wissel vanaf meerdere locaties, niet alleen vanaf je eigen kantoornetwerk.

Een gestructureerde aanpak met documentatie en een concreet terugrolplan voorkomt onnodige downtime bij DNS-aanpassingen, en dat scheelt in de praktijk vaak meer tijd dan de wijziging zelf.

Meer weten over hoe A, CNAME, MX en TXT precies samenwerken? Bekijk de verdiepende uitleg over DNS-records.

DNSSEC: bescherming die verkeerd geïmplementeerd averechts werkt

DNSSEC ondertekent DNS-antwoorden digitaal, waardoor bezoekers zeker weten dat ze bij de juiste server uitkomen en niet bij een vervalste kopie. SIDN benadrukt het belang van DNSSEC voor de betrouwbaarheid van .nl-domeinen, maar waarschuwt tegelijk dat een verkeerde implementatie net zo schadelijk kan zijn als geen beveiliging.

Het risico zit in de details. Een foutief ondertekende zone kan ervoor zorgen dat je domein voor bezoekers met een valideerende resolver volledig onbereikbaar wordt, terwijl bezoekers zonder validatie niets merken. Dat maakt het probleem sluipend: de storing lijkt eerst incidenteel, terwijl een groeiend deel van je bezoekers al buiten spel staat.

• Test een nieuwe DNSSEC-configuratie altijd eerst in een staging-omgeving of op een testdomein.
• Voer de uitrol gefaseerd door en houd een back-out plan gereed om de ondertekening direct te kunnen uitschakelen.
• Zorg dat de publieke sleutel correct bij de registrar staat geüpload, anders breekt de vertrouwensketen.
• Vergeet niet dat ook caching-resolvers onderweg een zwakke schakel kunnen zijn als de keten niet volledig sluitend is.

Voor webshops met verhoogde beveiligingseisen is DANE het overwegen waard: dit koppelt certificaatvalidatie aan DNS en biedt een extra laag zekerheid naast een regulier SSL-certificaat, zeker omdat DNS-manipulatie kan leiden tot afluisteren of omleiding van verkeer.

Pro-tip: Laat DNSSEC nooit door één persoon zonder tweede blik implementeren. Een kleine typefout in de zone-ondertekening merk je vaak pas als klanten al klagen dat de site niet meer laadt.

Wanneer schakel je een professional in?

Zelf sleutelen aan DNS-instellingen is prima voor kleine correcties. Bij een aantal signalen is doorgaan zonder hulp echter geen besparing, maar een risico.

Schakel direct hulp in bij:

• een DNSSEC-fout die de site voor een deel van de bezoekers onbereikbaar maakt;
• downtime die langer dan een paar uur aanhoudt zonder duidelijke oorzaak;
• een nameserverwissel die vastloopt of waarbij je geen toegang meer hebt tot de oude configuratie;
• e-mailverkeer dat structureel wegvalt of als spam wordt gemarkeerd na een wijziging.

Een gespecialiseerde partij werkt sneller als je vooraf de juiste gegevens klaar hebt liggen: de naam van je registrar en hostingpartij, een screenshot van de huidige zone-instellingen, de output van dig of nslookup, en een tijdlijn van recente wijzigingen. Met die informatie kan een ervaren beheerder de oorzaak vaak binnen een uur lokaliseren, terwijl het zonder die gegevens al snel een dag zoekwerk wordt. Twijfel je of uitbesteden in jouw situatie zin heeft, dan geeft dit overzicht over wanneer DNS-beheer uitbesteden slim is een helder beslissingskader.

Waarom een verkeerde DNS-cache je site laat “verdwijnen”

Elke computer, router en internetprovider slaat DNS-antwoorden tijdelijk op om herhaalde opzoekingen te versnellen. Dat is meestal handig, maar bij een DNS-wijziging wordt het een valkuil: je systeem blijft het oude, verlopen antwoord tonen terwijl de rest van de wereld al de nieuwe versie ziet.

Dit verklaart een klassiek scenario: een klant belt dat de website niet werkt, terwijl collega’s op een ander netwerk niets vreemds merken. Op Windows wis je de lokale cache met het commando ipconfig /flushdns, op macOS met sudo dscacheutil -flushcache. Op serverniveau ligt het genuanceerder: een DNS-resolver bij de internetprovider houdt zich niet aan jouw lokale flush en blijft de oude waarde tonen totdat de TTL daadwerkelijk verstrijkt.

Voor beheerders is dit een belangrijk inzicht bij het testen na een wijziging: zie je zelf nog de oude situatie, controleer dan altijd via een externe tool of publieke resolver voordat je concludeert dat de wijziging niet is doorgekomen. Vaak is het probleem niet de configuratie, maar simpelweg je eigen cache die nog niet is bijgewerkt. Dat onderscheid bespaart veel onnodig gepuzzel aan instellingen die intussen al correct staan.

Wat betekenen de meest voorkomende DNS-foutmeldingen?

Foutmeldingen rond DNS zijn vaak vaag geformuleerd, maar wijzen bijna altijd op een specifiek, herkenbaar probleem.

“DNS_PROBE_FINISHED_NXDOMAIN” betekent dat het domein niet gevonden kan worden. Dit wijst meestal op een niet-actieve nameserverconfiguratie, een net verlopen domeinregistratie, of een typefout in het domein zelf.

“Server IP address could not be found” geeft aan dat de browser geen enkel antwoord van de nameservers kreeg. Vaak liggen hier verkeerd ingestelde of niet-bereikbare nameservers aan de basis, bijvoorbeeld na een mislukte migratie.

“SERVFAIL”, zichtbaar in de output van dig of nslookup, duidt bijna altijd op een DNSSEC-validatiefout: de resolver kreeg een antwoord, maar kon de digitale handtekening niet correct verifiëren en weigert het antwoord daarom.

“Too many redirects” in combinatie met DNS-wijzigingen wijst vaak niet op DNS zelf, maar op een verkeerd ingestelde CNAME die naar een verkeerde omgeving verwijst, waardoor bezoekers in een lus terechtkomen tussen oude en nieuwe hosting.

Ken je deze meldingen, dan bespaar je jezelf de eerste, tijdrovende zoekfase en start je direct bij de juiste diagnose in plaats van bij giswerk.

Misconfiguraties bij subdomeinen corrigeren

Subdomeinen zoals webshop.jouwbedrijf.nl of mail.jouwbedrijf.nl hebben hun eigen DNS-records nodig, los van het hoofddomein. Een veelgemaakte fout: het hoofddomein wordt verhuisd naar een nieuwe host, maar de subdomeinen blijven achter op de oude configuratie omdat niemand ze los heeft gecontroleerd.

Ga bij elke subdomein-fout na of het record daadwerkelijk bestaat en naar het juiste doel wijst. Een CNAME die naar een verwijderde omgeving verwijst, geeft niet altijd een duidelijke foutmelding: soms laadt de pagina gedeeltelijk, met ontbrekende afbeeldingen of stylesheets, wat het probleem lastiger te herkennen maakt dan een volledige uitval.

Let ook op de wildcard-configuratie. Sommige providers zetten automatisch een wildcard-record (*.jouwbedrijf.nl) dat alle niet-gedefinieerde subdomeinen naar een standaardpagina stuurt. Dat lost tijdelijk fouten op, maar verhult ook echte configuratiefouten: een subdomein lijkt te werken, terwijl het in werkelijkheid alleen de wildcard-pagina toont in plaats van de juiste inhoud.

Controleer bij twijfel elk subdomein afzonderlijk met dig subdomein.jouwbedrijf.nl en vergelijk de uitkomst met de verwachte bestemming. Dat voorkomt dat een half opgelost probleem weken later alsnog voor verwarring zorgt bij klanten of collega’s.

Hoe firewalls en netwerkconfiguraties DNS-storingen veroorzaken

Niet elk DNS-probleem zit in de DNS-instellingen zelf. Firewalls, proxyservers en netwerkconfiguraties aan de kant van de hostingomgeving kunnen DNS-verkeer blokkeren of vertragen, waardoor het lijkt op een DNS-fout terwijl de records perfect correct staan.

Een veelvoorkomend scenario: een firewall op de server blokkeert UDP-poort 53, waardoor DNS-opzoekingen mislukken of onnodig lang duren voordat ze terugvallen op TCP. Voor beheerders die net een nieuwe server hebben ingericht, is dit een blinde vlek: de DNS-records zijn correct ingesteld, maar het netwerk laat het verkeer simpelweg niet door.

Ook load balancers en reverse proxy’s kunnen verwarring veroorzaken. Als een A-record naar het juiste IP-adres wijst, maar de proxy daarachter verkeer naar de verkeerde backend stuurt, oogt het resultaat identiek aan een DNS-fout: de site laadt niet of toont verkeerde inhoud. Controleer daarom bij twijfel niet alleen de DNS-records, maar ook of de server zelf reageert op het IP-adres waar het record naar wijst, los van de domeinnaam.

Bedrijven met een eigen netwerkinfrastructuur doen er goed aan om DNS-diagnose en netwerkdiagnose in dezelfde stap uit te voeren, in plaats van ze als twee losse problemen te behandelen. Vaak ligt de oplossing niet bij het domein, maar bij een regel in de firewallconfiguratie die niemand recent had gecontroleerd.

Zakelijk perspectief: waarom structureel DNS-beheer loont

Een paar uur onbereikbaarheid kost een webshop niet alleen omzet, maar ook vertrouwen: klanten die een foutmelding zien, komen niet automatisch terug bij de volgende poging. Wat opvalt in de praktijk is dat de meeste ernstige incidenten niet ontstaan door complexe fouten, maar door het ontbreken van documentatie. Wie niet vastlegt welke nameservers actief zijn en welke wijzigingen wanneer zijn doorgevoerd, verliest bij elke storing tijd aan reconstructie in plaats van aan de oplossing. Structureel beheer is daarom geen luxe, maar een investering in continuïteit. Sommige partijen lossen DNS-gerelateerde incidenten binnen één dag op door monitoring en documentatie als standaard onderdeel van de aanpak te hanteren.

— Ken

Wat NLXS doet bij een DNS-storing

Specialistische bedrijven kunnen dit hele proces uit handen nemen zodra zelf uitzoeken te veel tijd of risico kost. Bij een melding starten zij met een snelle analyse van nameservers, zonebestanden en recordconfiguratie, gevolgd door herstel binnen dezelfde dag en, waar gewenst, doorlopend DNS-beheer zodat een volgende storing wordt voorkomen in plaats van opnieuw bestreden.

Voor een snelle start heeft NLXS enkele basisgegevens nodig: de naam van je registrar en hostingpartij, toegang tot het beheerpanel of een contactpersoon daar, en een korte omschrijving van wat er sinds wanneer misgaat. Met een gratis ICT-scan brengt NLXS bovendien de bredere risico’s in je infrastructuur in kaart, nog voordat die tot een storing leiden. Bekijk de mogelijkheden voor betrouwbare webhosting met DNS-beheer of maak vrijblijvend kennis via de contactpagina van NLXS om je huidige DNS-configuratie te laten controleren.

Bronnen

• DNSSEC is een cryptografische beveiliging voor het DNS-protocol | Cybersecurity | SIDN
• DNS-propagatie: hoe lang duurt het en wat doe je tussentijds? | Cloud Captains // Docs

Aanbevelingen

• Beste zakelijke DNS-oplossing voor het mkb
• Zakelijke DNS failover zonder onnodige stress
• Wanneer dns beheer uitbesteden slim is
• DNS-beheer voor continuïteit zonder verrassingen