jouwsite.nl naar een server-IP. Belangrijkste records: A (IPv4-adres), AAAA (IPv6), CNAME (alias), MX (e-mail), TXT (verificatie/SPF/DKIM), NS (wie beheert je DNS). Wijzigingen duren 5min-48u. Backup je records voor je iets verandert.
Hoe DNS werkt in 30 seconden
Wanneer een bezoeker designcheck.nl in de browser typt:
- Browser vraagt aan DNS-resolver: "wat is het IP van designcheck.nl?"
- Resolver vraagt root-servers, dan .nl-TLD-servers, dan onze authoritative DNS-server
- Authoritative server antwoordt: "76.76.21.21" (Vercel-IP)
- Browser verbindt met die server om de site te laden
Dit gebeurt in milliseconden. Maar als één van deze stappen mis is, is je site onbereikbaar.
De zes record-types die je moet kennen
A record (Address)
Vertaalt domein naar IPv4-adres. De meest fundamentele record. Voorbeeld:
designcheck.nl A 76.76.21.21
Zonder A-record (of CNAME) is je site simpelweg niet bereikbaar.
AAAA record (quad-A, IPv6)
Hetzelfde als A maar voor IPv6-adressen. Optioneel maar steeds belangrijker. Voorbeeld:
designcheck.nl AAAA 2606:4700:3033::1234:5678
CNAME record (Canonical Name)
Verwijst een naam naar een andere naam. Vaak gebruikt voor subdomeinen of CDN's. Voorbeeld:
www.designcheck.nl CNAME designcheck.nl shop.designcheck.nl CNAME designcheck.myshopify.com
Belangrijke regel: een CNAME op de root van een domein (zoals designcheck.nl) is technisch niet toegestaan — gebruik ANAME of ALIAS records (door sommige DNS-providers ondersteund).
MX record (Mail Exchanger)
Vertelt waar e-mail voor je domein heen moet. Voorbeeld voor Google Workspace:
designcheck.nl MX 1 smtp.google.com
Voor 365: designcheck.nl MX 0 designcheck-nl.mail.protection.outlook.com. Voor TransIP-mail: mail.transip.nl. Priority-getal: lager = hogere prioriteit.
TXT record (Text)
Vrij-veld voor verificatie en e-mail-authenticatie. Drie cruciale TXT-records voor MKB:
- SPF:
v=spf1 include:_spf.google.com ~all— vertelt mailservers welke servers mogen mailen vanuit jouw domein - DKIM: publieke sleutel voor e-mail-signing (verkrijgbaar van je mail-provider)
- DMARC:
v=DMARC1; p=reject; rua=mailto:dmarc@designcheck.nl— beleid voor wat te doen met spoofed e-mails
Sinds februari 2024 vereisen Gmail en Yahoo SPF + DKIM + DMARC voor verzenders die >5000 mails per dag versturen. Voor MKB met lagere volumes nog niet kritisch, maar binnen 1-2 jaar wel norm.
NS record (Name Server)
Vertelt het internet wie de authoritative DNS voor je domein is. Voorbeeld:
designcheck.nl NS ns1.cloudflare.com designcheck.nl NS ns2.cloudflare.com
NS-records worden ingesteld bij je domein-registrar (TransIP, Versio etc.), niet bij je DNS-provider. Verkeerde NS = je hele site offline.
Waar het bij MKB-migraties misgaat
Probleem 1: TTL niet voorbereiden
TTL (Time To Live) bepaalt hoe lang DNS-resolvers je antwoord onthouden. Standaard 1-24 uur. Bij een migratie zonder TTL-voorbereiding: bezoekers krijgen 24+ uur de oude site terwijl jij denkt dat de nieuwe live is.
Oplossing: 24-48u vóór migratie zet je TTL op 300 seconden (5 minuten). Dan migreer je. Daarna terug naar 3600 of 86400.
Probleem 2: MX-records vergeten
Klassieker. Nieuwe hosting, nieuwe A-record gezet — maar oude MX-records overschreven. E-mail draait uren of dagen niet meer. Voor MKB die op zakelijke e-mail draait: catastrofaal.
Oplossing: Vóór wijzigingen: maak een screenshot of export van álle DNS-records. Wijzig alleen de specifieke records die je bedoeling is — laat MX en TXT met rust tenzij je ze actief migreert.
Probleem 3: CNAME op root-domein
Veel CDN-providers (Cloudflare, Vercel, Netlify) verwachten je root-domein naar hen te wijzen. Maar pure CNAME op root is technisch niet toegestaan. Sommige providers lossen dit op met ANAME/ALIAS, anderen met flattening. Test altijd na config.
Probleem 4: SSL-validatie blokkeren
Let's Encrypt heeft _acme-challenge TXT-records nodig om je SSL-certificaat te valideren. Als je een super-strikte DNSSEC of CAA-policy hebt, kan dit blokkeren. Resultaat: site geen geldig HTTPS.
Waar zet je je DNS?
Vier opties:
- Bij je registrar (TransIP, Versio): simpelste, maar vaak trager en minder feature-rijk
- Bij je host (Vercel, Netlify): handig als je niet veel DNS-wijzigingen doet
- Cloudflare DNS (gratis): snelst, beste analytics, sterke security-features, anycast
- AWS Route 53 / Google Cloud DNS: enterprise-level, vaak overkill voor MKB
Wij raden bij DesignCheck Mijdrecht Cloudflare DNS aan voor MKB-klanten. Gratis, snelle propagation, ingebouwde DDoS-protection. Zie ook CDN voor MKB.
DNS-check tools (gratis)
- whatsmydns.net — controleer DNS-propagatie wereldwijd
- mxtoolbox.com — alle records inspecteren + e-mail diagnostiek
- dnschecker.org — visuele propagation-map
- Cloudflare DNS Learning Center — gratis educatie-resource
Hoe wij dit aanpakken bij DC-migraties
Bij elke DC-rebuild documenteren we de bestaande DNS-config voor migratie. We bereiden TTL voor (24u tevoren), migreren in een afgesproken tijdvenster, monitoren 6 uur na go-live, en zetten TTL daarna terug. Bij twijfel: rollback-plan klaar.
Hulp nodig bij DNS-migratie of -audit? Gratis audit binnen 48u. Wat downtime kost: verliescalculator.
FAQ — DNS voor MKB
Wat is DNS en waarom is het belangrijk?
Hoe lang duurt het voordat DNS-wijzigingen actief zijn?
Mag ik mijn DNS bij een andere partij hebben dan mijn hosting?
Wat als ik per ongeluk DNS-records verwijder?
A, AAAA, CNAME, MX, TXT — diepe duik per type
De meeste MKB'ers krijgen pas met DNS te maken op het moment dat er iets misgaat. Een mailtje komt niet meer aan, een nieuwe webshop hangt op "Server not found", of een leverancier vraagt "kun je even een TXT-record toevoegen?". Op dat moment helpt het om te weten wat elk recordtype concreet doet. Een A-record koppelt een hostnaam aan een IPv4-adres (vier getallen, zoals 76.76.21.21). Dit is wat een browser uiteindelijk gebruikt om verbinding te maken. Per hostnaam mag je meerdere A-records hebben — dat heet round-robin en wordt gebruikt voor primitieve load-balancing.
Een AAAA-record is het IPv6-equivalent. IPv6-adressen zijn langer (acht groepen van vier hex-tekens) en steeds belangrijker omdat IPv4-adressen op zijn. Voor een Nederlandse MKB-site die voornamelijk vanuit Ziggo- en KPN-verbindingen wordt bezocht, wordt al meer dan 60 procent van het verkeer over IPv6 afgehandeld. Heb je geen AAAA-record, dan valt de bezoeker terug op IPv4 — meestal geen probleem, maar je mist een prestatievoordeel op mobiel. Een CNAME-record is een alias: het zegt "voor deze hostnaam, kijk verder bij die andere hostnaam". Handig voor subdomeinen die naar externe services wijzen (mail.jouwsite.nl → jouwbedrijf.mail.protection.outlook.com).
De MX-records bepalen waar e-mail voor jouw domein naartoe gaat. Elk MX-record heeft een prioriteit (lager getal = hogere prioriteit) en een mailserver-hostnaam. Een typische setup heeft twee of drie MX-records die naar dezelfde mailprovider wijzen, voor redundantie. Een TXT-record bevat platte tekst en wordt gebruikt voor een dozijn verschillende dingen: SPF (welke servers mogen mail versturen namens jouw domein), DKIM (cryptografische ondertekening van uitgaande mail), DMARC (wat moet de ontvanger doen met onechte mail), Google-verificatie, en third-party domain-ownership-checks. Bij een correcte mailsetup heb je al snel tien TXT-records actief.
De zes kritieke MKB-fouten in DNS-configuratie
Na jaren audits zien we steeds dezelfde fouten terugkomen. Eén: geen SPF-record. Het gevolg is dat jouw zakelijke mail in de spambox van klanten belandt zodra je iets meer dan twintig adressen tegelijk mailt. Twee: SPF-record met meer dan tien DNS-lookups (de protocol-limiet) — dat zorgt voor stille failures waarbij sommige ontvangers je mail wel zien en anderen niet. Drie: dubbele MX-records van twee verschillende providers, waardoor mail soms naar je oude en soms naar je nieuwe inbox gaat. Vier: een wildcard A-record (*.jouwsite.nl) dat naar je oude server wijst terwijl alle subdomeinen al ergens anders moeten staan.
Vijf: een verouderd TXT-record met een Google-verificatie van een ex-medewerker die zijn account heeft gesloten — meestal onschuldig, maar als die account ooit is gehackt kan een aanvaller via dat verificatiekanaal toegang vragen. Zes: NS-records die nog wijzen naar een hosting-partij waar je niets meer hebt staan. Dat laatste is verraderlijk: zolang het oude DNS-account nog draait werkt alles, maar zodra die provider je records opschoont staat je site offline. Een DNS-audit van een halfuur per jaar voorkomt al deze problemen.
DNS-propagatie — waarom duurt het soms zo lang?
Propagatie is het verschijnsel dat een DNS-wijziging niet direct overal ter wereld zichtbaar is. De oorzaak zit in de TTL (Time To Live) die op elk record staat. Een TTL van 3600 seconden betekent dat een resolver de waarde een uur cachet voor hij opnieuw vraagt. Wijzig je het record terwijl een resolver nog in z'n cache zit, dan kan een bezoeker een uur lang de oude waarde krijgen. In de praktijk variëren TTL's tussen 300 (vijf minuten) en 86400 (een dag), en de propagatietijd hangt dus af van wat jij in je records hebt staan.
De truc bij geplande migraties: verlaag de TTL naar 300 seconden, 24 uur voor de wijziging. Dan dwing je alle resolvers om hun cache snel te verversen. Doe je dat niet, dan zit je vast aan de oude TTL en moet je rekenen op een halve dag waarin sommige bezoekers naar de oude server gaan en anderen al naar de nieuwe. Voor een lokale MKB die een avond migreert is dit cruciaal — anders krijg je 's ochtends boze klanten omdat hun mail "weg" lijkt te zijn.
DNSSEC — waarom MKB het zou moeten aanzetten
DNSSEC is een uitbreiding op DNS die digitale handtekeningen toevoegt aan records, zodat een resolver kan verifiëren dat de waarde echt van de eigenaar komt en niet door een aanvaller is vervalst. Voor MKB-sites die formulieren verwerken, betalingen ontvangen of e-mail versturen is dit relevanter dan vaak gedacht. Zonder DNSSEC kan een aanvaller via DNS-cache-poisoning bezoekers naar een phishing-versie van jouw site sturen, zonder dat ze het merken — het slotje in de browser werkt nog steeds.
De goede nieuws: alle serieuze NL-registrars (TransIP, Versio, Hostnet, Mijndomein) ondersteunen DNSSEC met één klik in het control panel. Het kost niets extra en de prestatieimpact is verwaarloosbaar (een paar milliseconden per query). De enige situatie waarin je het beter even uit kunt laten is als je net midden in een DNS-migratie zit — dan kan een mismatch tussen oude en nieuwe ondertekening tijdelijk problemen geven. Verder is "aan" altijd beter dan "uit".
Wat doe je vandaag?
- Log in bij je registrar en maak een screenshot van al je huidige DNS-records — dat is je gratis backup.
- Controleer of DNSSEC aanstaat — zo niet, zet hem aan tenzij je in een migratie zit.
- Verlaag de TTL naar 300 seconden op kritieke records voor je iets gaat wijzigen.
- Test je SPF, DKIM en DMARC met mail-tester.com om mail-deliverability te checken.
- Zet een tweede nameserver in een ander land bij voor failover — gratis bij Cloudflare.
Door Lorenzo Ruisi — DesignCheck Mijdrecht. Laatst bijgewerkt 16 mei 2026.