Wat is Domain Name System (DNS)?

DNS staat voor Domain Name System. Het vertaalt een naam die mensen kunnen onthouden naar het cijferadres waar de server echt staat, zodat je platformpro.nl intikt in plaats van een rij getallen.

Die vertaling duurt milliseconden en je merkt er niets van, tot het misgaat. Dan is je site onbereikbaar of komt je post niet aan, en er verschijnt zelden een melding die uitlegt waarom.

De keten van vraag naar antwoord

Een opzoeking gaat langs vier partijen. Je computer stuurt de vraag naar een recursieve resolver: meestal die van je provider, soms een openbare zoals die van Cloudflare of Google, soms een in je eigen router. Die doet het echte werk.

Staat het antwoord niet in zijn geheugen, dan vraagt de resolver het aan een van de rootservers. Er zijn dertien logische rootadressen, en achter elk daarvan zitten via anycast honderden fysieke servers. De root weet het antwoord niet, maar wel wie het weet: hij verwijst naar de servers van de zone .nl.

Die zone verwijst op zijn beurt naar de nameservers van jouw domein. Dat heet een delegatie. Pas die laatste servers zijn autoritatief: zij hebben het echte antwoord.

Elk antwoord onderweg wordt opgeslagen, ook een antwoord dat zegt dat een naam niet bestaat. Dat opslaan maakt DNS snel en het is meteen de reden dat een wijziging niet overal tegelijk zichtbaar wordt.

Wie .nl beheert en waarom dat uitmaakt

Achter elke extensie zit een registry: de partij die de zone bijhoudt en bepaalt wie welke naam mag voeren. Voor .nl is dat SIDN, een Nederlandse stichting. De extensie bestaat sinds 1986 en hoort bij de oudste landextensies.

De regels rond registratie, verhuizing en opzegging komen dus van SIDN en niet van je hostingpartij, hoe hard die ook doet alsof. Bij een topleveldomein als .com of .eu geldt hetzelfde met een andere beheerder.

Twee regels kom je in de praktijk tegen. Verhuizen gaat met een verhuistoken dat je bij je huidige partij opvraagt. En zeg je een .nl-domein op of vergeet je te betalen, dan gaat de naam veertig dagen in quarantaine voordat hij vrijkomt; in die periode kun je hem terughalen. Bij .com geldt een autorisatiecode en een blokkade van zestig dagen na registratie of na een wisseling van houder.

Ik zie regelmatig dat een domein nog op naam van de vorige webbouwer staat. Wie als houder geregistreerd staat bepaalt waar de naam naartoe gaat, dus dat is het waard om een keer met een whois-opzoeking te controleren.

De records die in je zone staan

Een zone is de verzameling regels die bij jouw domein hoort. Elke regel is een record met een naam, een soort, een waarde en een geldigheidsduur.

• A. Wijst een naam naar een IPv4-adres, dus naar de webserver. Dit is het record dat je het vaakst aanpast. Wat zo'n adres precies is staat in het artikel over het IP-adres.
• AAAA. Hetzelfde, maar dan een IPv6-adres. Steeds meer providers leveren beide.
• CNAME. Zegt dat een naam een andere naam volgt. Handig voor www of voor een dienst van een derde partij die zelf zijn adressen wil beheren.
• MX. Wijst aan welke server je e-mail ontvangt, met een cijfer voor de voorkeursvolgorde. Lager cijfer is eerste keus.
• TXT. Vrije tekst. Wordt gebruikt om eigendom te bewijzen bij Google of Microsoft, en voor je mailbeveiliging.
• NS. Welke nameservers gezaghebbend zijn over je domein. Dit stel je in bij de partij waar je domein geregistreerd staat, niet in de zone zelf.
• CAA. Legt vast welke certificaatuitgevers een SSL-certificaat voor jouw domein mogen uitgeven.
• SOA. Het administratieve record bovenaan de zone, met onder meer hoe lang een negatief antwoord bewaard mag blijven.
• SRV. Wijst naar een dienst met een poortnummer erbij. Je komt hem tegen bij telefonie en bij automatische instellingen van mailprogramma's.

Waarom een CNAME niet op je hoofddomein past

Op het kale domein, zonder www ervoor, mag geen CNAME staan. Daar staan namelijk ook je NS-records en je SOA, en de standaard verbiedt dat een naam met een CNAME nog andere records heeft.

Diensten die toch willen dat je naar een naam wijst, lossen dat op met een eigen variant die vaak ALIAS of ANAME heet. Die staat niet in de standaard, dus je bent afhankelijk van je DNS-partij. Kan die het niet, dan blijft een A-record met een vast adres over.

De TTL en waarom een wijziging tijd kost

Bij elk record staat een TTL: het aantal seconden dat de rest van internet het antwoord mag onthouden. Staat die op 86400, dan kan een resolver ergens in het land het oude antwoord nog een etmaal blijven geven nadat jij het hebt aangepast.

Daarom voelt een DNS-wijziging als iets dat "moet doorkomen". Er komt niets door. Er verloopt alleen een voorraad oude antwoorden bij duizenden resolvers, elk op zijn eigen moment. Dat verklaart waarom jij de nieuwe site al ziet en je klant nog de oude.

De remedie is simpel en wordt bijna altijd overgeslagen. Verlaag de TTL een dag van tevoren naar bijvoorbeeld driehonderd seconden, wacht tot de oude waarde is verlopen, en doe dan pas de wijziging. Daarna zet je hem terug. De omschakeling gaat dan in minuten.

Eén ding kun je niet zelf verlagen: de TTL van de delegatie bij de extensie. Wissel je van nameservers, dan bepaalt de zone boven je hoe lang de oude verwijzing blijft hangen. Reken op uren.

Registrar, hosting en DNS-beheer zijn drie rollen

Bijna alle verwarring die ik tegenkom komt hier vandaan. Drie taken die bij één partij kunnen liggen en net zo vaak bij drie.

De registrar is waar je domeinnaam geregistreerd staat en waar je de nameservers instelt. De hostingpartij draait de server waar je site staat. De DNS-beheerder is van wie de nameservers zijn, en daar wordt je zone dus echt gelezen.

Wijzen je nameservers naar partij A en pas jij records aan in het beheerscherm van partij B, dan gebeurt er niets. Dat scherm slaat je wijziging netjes op en niemand vraagt het ooit aan B. Je zit in een zone die nergens meer wordt gebruikt.

Kijk daarom altijd eerst welke NS-records actief zijn. Dat kost tien seconden en scheelt een middag zoeken. Zet je een dienst als Cloudflare voor je site, dan verhuist je DNS-beheer daar meestal naartoe en wordt dat het enige scherm dat telt.

Nameservers wijzigen bij een verhuizing

Van nameservers wisselen is grover dan een record aanpassen. Je vervangt in één klap de hele zone door die van een andere partij.

Dat gaat mis als de nieuwe zone niet compleet is. De nieuwe partij vult meestal netjes een A-record voor de website in en laat je mailrecords leeg, of zet er eigen standaardwaarden neer. Zodra de delegatie omschakelt zijn je MX-records dus weg, of ze wijzen naar een mailserver waar jij geen postbus hebt.

Werk daarom vooraf. Haal het volledige overzicht van de oude zone op, bouw die bij de nieuwe partij regel voor regel na, inclusief alle TXT-records voor verificaties waarvan je vergeten bent dat ze er staan, en leg de twee lijsten naast elkaar voordat je omschakelt. Laat de oude zone daarna nog een week staan.

Een website verhuizen zonder uitval

De volgorde bepaalt alles. Zet de site eerst klaar bij de nieuwe webhosting en test hem daar voordat je iets aan DNS raakt.

Testen kan zonder dat de wereld het ziet. Zet in het hosts-bestand van je eigen computer een regel die de domeinnaam naar het nieuwe adres wijst. Op macOS en Linux staat dat bestand in /etc/hosts, op Windows onder Windows\System32\drivers\etc. Jouw machine gaat dan al naar de nieuwe server terwijl de rest nog naar de oude gaat, dus je loopt de hele site na inclusief formulieren en inloggen.

Regel het certificaat vooraf. De gebruikelijke controle daarvoor loopt via de website die op dat moment nog op de oude server staat. Kan je hostingpartij het aanvragen via een tijdelijk TXT-record in je DNS, dan kan het wel vooruit. Anders krijgen bezoekers na de omschakeling een waarschuwing tot het certificaat er is.

Let ook op HSTS. Heeft je site een header die browsers verplicht alleen via https te verbinden, dan is een tijdelijk certificaatprobleem geen waarschuwing meer maar een gesloten deur. Browsers onthouden die instructie maanden. Houd de oude hosting daarna twee weken aan.

E-mail verhuizen is een apart karwei

Verhuis je site en je mail tegelijk, dan verdubbel je het risico. Ik raad aan ze te scheiden en er een week tussen te laten.

Bij een mailverhuizing wijzig je de MX-records, en dat werkt anders dan bij een website. Tijdens de omschakeling levert de ene verzender nog bij de oude server af en de andere al bij de nieuwe, dus je post komt een dag lang op twee plekken binnen. Dat hoort erbij. Het betekent wel dat je beide postbussen in de gaten houdt en de oude pas opheft als er niets meer komt.

Zet de nieuwe omgeving vooraf klaar. Maak de postbussen aan, zet de DKIM-sleutel van de nieuwe partij alvast in je DNS, en breid je SPF-record uit met de nieuwe verzender voordat je de MX wijzigt. Dan mogen beide partijen even namens je verzenden en valt er niets uit.

Vergeet de automatische instellingen niet. Mailprogramma's zoeken bij het toevoegen van een account naar namen als autodiscover of autoconfig in jouw DNS, of naar een SRV-record. Wijzen die nog naar de oude partij, dan configureert elke nieuwe telefoon zich verkeerd.

Verhuis je alleen je website en blijft je mail waar hij is, laat de MX-records dan met rust. Dat klinkt vanzelfsprekend en het is de meest voorkomende oorzaak van mail die na een verhuizing stilvalt.

SPF, DKIM en DMARC staan gewoon in je DNS

Drie TXT-records bepalen tegenwoordig of je post aankomt of in de ongewenste map belandt. Ze staan los van je mailserver en horen bij je domein.

SPF

Een SPF-record noemt de servers die namens jouw domein mogen versturen. Je mag er maar één van hebben; twee SPF-records naast elkaar leveren een fout op en dan telt het hele record niet meer mee. Voeg een nieuwe verzender dus toe aan het bestaande record in plaats van er een tweede regel bij te zetten.

Er zit ook een grens aan. Bij het controleren mag een ontvanger hooguit tien keer verder opzoeken, en elke include van een mailingpakket of een boekhoudprogramma kost er minstens één. Zit je erboven, dan faalt de controle ook al klopt de lijst inhoudelijk. Dat sluipt erin naarmate je meer diensten koppelt.

DKIM

DKIM zet een digitale handtekening onder elk uitgaand bericht. De publieke sleutel staat in je DNS, onder een naam met een selector erin, bijvoorbeeld standaard._domainkey bij je domein. De ontvanger haalt die sleutel op en controleert of het bericht onderweg niet is aangepast.

Het aardige van DKIM is dat de handtekening blijft kloppen als iemand je bericht doorstuurt. Bij SPF is dat niet zo, want die kijkt naar de verzendende server en dat is na een doorstuur een andere. Vandaar dat mail die via een doorstuuradres binnenkomt vaker in de ongewenste map valt.

DMARC

DMARC staat in een record met de naam _dmarc bij je domein en zegt wat een ontvanger moet doen als SPF en DKIM niet kloppen. Je kiest tussen niets doen, apart zetten of weigeren.

Begin op niets doen en vraag rapportages op. Je krijgt dan overzichten van ontvangers over wat er namens jouw domein is verstuurd, en pas als die lijst klopt zet je het beleid strenger. Andersom blokkeer je je eigen nieuwsbrief zonder het te merken.

Eén subtiliteit wordt vaak overgeslagen: DMARC eist dat het domein in de zichtbare afzender overeenkomt met het domein dat SPF of DKIM heeft goedgekeurd. Een dienst die technisch correct verstuurt maar met zijn eigen domein tekent, komt de controle niet door.

Wat grote ontvangers sinds 2024 verlangen

In februari 2024 gingen Google en Yahoo eisen stellen aan wie grote hoeveelheden mail naar hun gebruikers stuurt. SPF en DKIM moeten geregeld zijn, er moet een DMARC-record staan, uitschrijven moet met één klik werken en het aantal spamklachten moet onder een grens blijven. Microsoft kondigde in 2025 vergelijkbare eisen aan voor Outlook.com.

Formeel gelden die drempels voor bulkverzenders. In de praktijk is de filtering voor iedereen strenger geworden, ook voor een eenmanszaak die per dag tien offertes verstuurt. Hapert er iets aan je bezorging, dan kijk ik altijd eerst naar deze drie records.

De Nederlandse overheid loopt hierop voor. Het Forum Standaardisatie zette DNSSEC, SPF, DKIM, DMARC en versleuteld mailtransport op de lijst waar overheidsorganisaties zich aan moeten houden of moeten uitleggen waarom niet. Wie voor de overheid werkt krijgt die eisen vroeg of laat doorgeschoven. Wat je verder met je post doet staat bij e-mailmarketing.

DNSSEC en het CAA-record

DNS is bedacht in een tijd waarin niemand rekening hield met kwaadwillenden. Een antwoord is van zichzelf niet te controleren, en daar kwamen later twee lapmiddelen bij.

DNSSEC

Met DNSSEC worden de antwoorden uit je zone digitaal ondertekend. Bij de extensie staat een verwijzing naar jouw sleutel, waardoor er een keten van vertrouwen ontstaat tot aan de root. Een resolver die controleert, weigert een vervalst antwoord. Versleutelen doet het niet; het bewijst alleen dat het antwoord is wat de eigenaar erin zette.

SIDN moedigt DNSSEC voor .nl actief aan en veel Nederlandse hostingpartijen zetten het standaard aan. Er zit wel een adder onder. Wissel je van DNS-partij zonder de sleutels over te dragen, dan is je domein voor iedereen die controleert onbereikbaar. Niet traag, maar weg. Zet het bij een verhuizing dus eerst uit en daarna opnieuw aan.

CAA

Een CAA-record noemt de certificaatuitgevers die voor jouw domein een certificaat mogen afgeven. Uitgevers zijn sinds 2017 verplicht dat record te raadplegen voordat ze er een uitgeven.

Verplicht is het voor jou niet, maar het kost niets. Het voorkomt dat iemand die even toegang tot je site krijgt bij een andere partij een geldig certificaat op jouw naam aanvraagt. Vergeet alleen niet de uitgever te noemen die je hostingpartij gebruikt, anders staan je automatische verlengingen stil.

Versleutelde DNS en wat dat op kantoor betekent

Een gewone DNS-vraag gaat onversleuteld over de lijn. Iedereen tussen jou en je resolver kan meelezen welke namen je opvraagt, ook als de site zelf via https gaat. Daar zijn twee oplossingen voor: DNS over TLS uit 2016 en DNS over HTTPS uit 2018. Bij die tweede vorm gaat het verkeer over dezelfde poort als gewoon webverkeer en valt het niet meer op.

Voor je privacy is dat winst. Op een bedrijfsnetwerk betekent het dat een filter op DNS-niveau het verkeer niet meer ziet langskomen en dus niets tegenhoudt. Met vijf man op kantoor is dat zelden een ramp; zit er een gastennetwerk of een kinderkamer achter, dan is het het nakijken waard.

Waar DNS wordt aangevallen

Er zijn drie manieren waarop dit misgaat en ze verschillen sterk in hoe erg het is.

De eerste is vervalsing. Een aanvaller propt een verkeerd antwoord in het geheugen van een resolver, zodat bezoekers bij hem uitkomen in plaats van bij jou. Sinds een bekende zwakke plek in 2008 zijn resolvers hiertegen beter gewapend, en DNSSEC sluit het gat verder.

De tweede is overname van je account bij de registrar. Wie daar binnenkomt wijzigt je nameservers en heeft daarmee je hele domein, inclusief je mail. Dit is verreweg het grootste risico en ook het makkelijkst af te dekken: tweestapsverificatie en een eigen wachtwoord op dat account. SIDN biedt daarnaast een registry lock aan, waarbij wijzigingen alleen na een handmatige controle doorgaan. Wat je aan je site zelf doet staat bij het beveiligen van een WordPress website.

De derde is een vergeten verwijzing. Heb je ooit een subdomein met een CNAME naar een dienst laten wijzen en die dienst later opgezegd, dan staat die verwijzing er nog. Wie dezelfde naam bij die dienst opnieuw claimt, publiceert vanaf dat moment op jouw subdomein.

Wat er misgaat en waaraan je het merkt

De meeste DNS-problemen hebben een herkenbaar signaal. Ken je die, dan sla je een hoop zoeken over.

• Bij jou werkt het en bij een klant niet. Vrijwel altijd caching: iemand zit nog op een oud antwoord. Wachten helpt, TTL verlagen had eerder geholpen.
• Met www werkt de site en zonder www niet. Er ontbreekt een A-record op het kale domein, of er staat wel een record maar de server kent die naam niet.
• De mail valt stil na een verhuizing van de site. De MX-records zijn overschreven door de standaardinstellingen van de nieuwe partij.
• Je post komt overal in de ongewenste map. Kijk naar SPF, DKIM en DMARC, in die volgorde.
• Je wijzigingen doen niets. Je bewerkt een zone die niet gebruikt wordt. Controleer de NS-records.
• Het domein is nergens meer te bereiken. Denk aan een verlopen registratie of aan DNSSEC dat na een verhuizing niet meer klopt.

Zelf controleren waar een domein naar wijst

Vertrouw het beheerscherm van je provider niet. Dat toont wat er opgeslagen staat, niet wat de wereld te zien krijgt. Kijk naar het echte antwoord.

Op macOS en Linux gebruik je daarvoor dig. Met dig platformpro.nl A +short zie je het adres, met dig platformpro.nl NS de nameservers en met dig platformpro.nl MX je mailservers. De hele keten van root tot autoritatieve server krijg je met dig platformpro.nl +trace. Op Windows doet nslookup ongeveer hetzelfde.

Twee dingen maken het verschil bij zoeken. Zet er een resolver achter, bijvoorbeeld dig @1.1.1.1 platformpro.nl, en vergelijk dat met wat je eigen provider teruggeeft; verschil betekent dat je in een overgang zit. En vraag het rechtstreeks aan de autoritatieve nameserver van je domein, want dat antwoord zit nooit in een geheugen.

Werk je liever niet in een terminal, dan zijn er online opzoektools genoeg, en voor de mailkant is er de gratis test op internet.nl.

Kijk tot slot naar de whois-gegevens: wie staat er als houder, bij welke registrar staat het, en wanneer loopt het af. Die drie weten is meer waard dan alle records bij elkaar. Hoe een adres in een browser is opgebouwd staat in het artikel over de URL.

Veelgestelde vragen over DNS

Wat betekent DNS?

DNS staat voor Domain Name System, het systeem dat domeinnamen omzet naar de adressen waarop servers bereikbaar zijn. Zonder DNS zou je voor elke website een reeks cijfers moeten intikken.

Hoe lang duurt het voordat een DNS-wijziging is doorgevoerd?

Dat hangt af van de TTL die op het record stond voordat je het wijzigde. Stond die op een uur, dan is de wereld binnen een uur bij; stond hij op een etmaal, dan duurt het een etmaal. Bij een wijziging van je nameservers reken je op uren.

Wat is een A-record?

Een A-record koppelt een naam aan een IPv4-adres en vertelt de wereld dus op welke server de website staat. Verhuis je naar een andere hostingpartij, dan is dit meestal het record dat je aanpast.

Wat is het verschil tussen een A-record en een CNAME?

Een A-record wijst rechtstreeks naar een adres, een CNAME wijst naar een andere naam die daarna zelf wordt opgezocht. Een CNAME is handig als de partij achter die naam zijn adressen wil kunnen wijzigen zonder dat jij iets doet. Op het kale domein zonder www mag geen CNAME staan.

Waarom werkt mijn website wel en mijn e-mail niet na een verhuizing?

Vrijwel altijd doordat de MX-records zijn meegegaan. De nieuwe partij vulde bij het aanmaken van de zone eigen mailinstellingen in, waardoor je post naar een server gaat waar geen postbus voor je bestaat. Zet de oude MX-records terug en controleer meteen je SPF-record.

Waar pas ik mijn DNS-records aan?

Bij de partij van wie de nameservers zijn die in je NS-records staan. Dat is niet automatisch de partij waar je het domein hebt gekocht en ook niet automatisch je hostingpartij. Zoek eerst de actieve nameservers op en log dan pas ergens in.

Hoe controleer ik naar welk IP-adres mijn domein wijst?

Met dig jouwdomein.nl A +short in een terminal, met nslookup op Windows, of met een online opzoektool. Vraag het bij twijfel aan twee verschillende resolvers, want dan zie je meteen of je nog in een overgang zit.

Wat is een TTL in DNS?

Het aantal seconden dat andere partijen jouw antwoord mogen bewaren voordat ze het opnieuw opvragen. Een hoge TTL maakt je site iets sneller en een wijziging veel trager. Verlaag hem een dag voor een geplande verhuizing en zet hem daarna terug.

Wat doen SPF, DKIM en DMARC?

SPF noemt de servers die namens je domein mogen versturen, DKIM zet een handtekening onder elk bericht en DMARC bepaalt wat de ontvanger doet als een van beide niet klopt. Samen voorkomen ze dat iemand anders mail verstuurt met jouw domeinnaam, en ze bepalen voor een groot deel of je post in de inbox belandt.

Heb ik DNSSEC nodig?

Nodig is het niet, verstandig meestal wel, en bij de meeste Nederlandse partijen staat het met één schakelaar aan. Let er alleen op dat je het uitzet voordat je van DNS-partij wisselt, want een sleutel die niet meer klopt maakt je domein onbereikbaar.

Wat gebeurt er als mijn domeinnaam verloopt?

Bij .nl gaat de naam eerst veertig dagen in quarantaine. In die periode werkt er niets meer, maar kun je hem via je registrar nog terughalen. Daarna komt de naam vrij voor iedereen. Zet de verlenging op automatisch en controleer of het betaalmiddel dat eraan hangt nog geldig is.

Waarom is mijn site wel via www bereikbaar en niet zonder?

Dan ontbreekt er een record voor het kale domein, of de webserver weet niet dat hij die naam moet bedienen. Zorg dat beide varianten bestaan en laat er één naar de ander doorverwijzen.

Wat is DNS over HTTPS?

Een manier om DNS-vragen versleuteld te versturen, zodat niemand tussen jou en je resolver kan meelezen welke namen je opvraagt. Browsers en besturingssystemen zetten het steeds vaker standaard aan. Op een bedrijfsnetwerk kan het betekenen dat een filter op DNS-niveau niets meer tegenhoudt.