Wat is DNS en hoe werkt het?

IPAddress-Lookup.com · June 28, 2025

Elke keer dat je een websitenaam in je browser intypt, treedt er een onzichtbaar systeem in werking om uit te zoeken waar die site zich daadwerkelijk bevindt. Dat systeem is het Domain Name System, of DNS, en het is een van de belangrijkste onderdelen van de infrastructuur op het internet. Zonder DNS zou je voor elke website die je bezoekt lange reeksen cijfers uit je hoofd moeten leren, in plaats van gebruiksvriendelijke namen zoals example.com. In deze handleiding leggen we precies uit wat DNS is, volgen we een echte opzoekactie van begin tot eind, lichten we alle belangrijke recordtypes toe en laten we je zien hoe je DNS zelf kunt controleren en eventuele problemen kunt oplossen.

Wat is DNS?

DNS is het telefoonboek van het internet. Computers communiceren niet met voor mensen leesbare namen; ze communiceren met numerieke adressen. Als je een vriend telefonisch wilt bereiken, toets je niet zijn naam in, maar zijn nummer, maar je onthoudt waarschijnlijk wel de naam en laat je contactenlijst die omzetten in cijfers. DNS doet hetzelfde voor het internet: het vertaalt een domeinnaam die mensen kunnen onthouden, zoals www.example.com, naar het numerieke IP-adres dat machines daadwerkelijk gebruiken om verkeer te routeren, zoals 93.184.216.34 voor IPv4 of een langere hexadecimale reeks voor IPv6.

Deze vertaling is belangrijk omdat IP-adressen veranderen. Een website kan naar een nieuwe server verhuizen, van hostingprovider wisselen of zijn inhoud verspreiden over tientallen datacenters over de hele wereld. Namen geven ons een stabiel, gemakkelijk te onthouden label dat hetzelfde blijft, zelfs als het onderliggende adres verandert. DNS is de laag die die belofte nakomt en wereldwijd miljarden keren per seconde namen naar adressen omzet. Het is ook een gedistribueerd systeem, wat betekent dat geen enkele computer het volledige adresboek bevat. In plaats daarvan is de verantwoordelijkheid verdeeld over een uitgebreide hiërarchie van servers, en dat is precies wat DNS snel, veerkrachtig en schaalbaar maakt voor de hele planeet.

De spelers die betrokken zijn bij een DNS-opzoeking

Voordat we een zoekopdracht volgen, is het handig om de spelers te leren kennen. Elk heeft een specifieke taak, en bij één enkele zoekopdracht kunnen ze allemaal betrokken zijn:

• Stub-resolver — het kleine stukje software dat in je besturingssysteem is ingebouwd. Wanneer een applicatie een adres nodig heeft, stuurt de stub-resolver het verzoek door. Hij denkt zelf nauwelijks na.
• Recursieve resolver — het werkpaard, meestal beheerd door je internetprovider of een openbare provider, zoals de bekende 8.8.8.8- of 1.1.1.1-dienst. Deze neemt je vraag in behandeling en doet al het nodige zoekwerk om het definitieve antwoord te vinden, waarna hij het aan jou teruggeeft.
• Root-naamservers — de top van de hiërarchie. Ze kennen het adres van geen enkele website, maar ze weten wel waar ze de servers kunnen vinden die verantwoordelijk zijn voor elk topleveldomein.
• TLD-naamservers — verantwoordelijk voor een topleveldomein zoals .com, .org of .net. Zij weten welke gezaghebbende servers elk domein beheren dat onder hen is geregistreerd.
• Autoritatieve naamservers — de uiteindelijke bron van waarheid. Deze servers bevatten de daadwerkelijke records voor een specifiek domein en geven het definitieve antwoord.

Een echte zoekopdracht volgen: www.example.com opzoeken

Laten we één verzoek stap voor stap volgen. Stel je voor dat je www.example.com in je browser typt en op Enter drukt. Dit is wat er achter de schermen gebeurt, ervan uitgaande dat er nog niets in de cache is opgeslagen:

1. De browser vraagt het aan de stub-resolver. De stub-resolver van je besturingssysteem ontvangt het verzoek voor www.example.com. Deze controleert eerst zijn eigen lokale cache. Als deze naam onlangs is opgezocht, wordt het antwoord onmiddellijk teruggestuurd en eindigt het traject hier.
2. De stub-resolver neemt contact op met de recursieve resolver. Omdat er geen antwoord in de cache staat, stuurt de stub-resolver de query door naar de door jou geconfigureerde recursieve resolver.
3. De recursieve resolver vraagt een rootserver. De recursieve resolver weet nog niet waar .com zich bevindt, dus vraagt hij het aan een van de rootservers. De rootserver kent www.example.com niet, maar antwoordt met een doorverwijzing: „Ik heb dat antwoord niet, maar hier zijn de servers die verantwoordelijk zijn voor .com.”
4. De recursieve resolver vraagt de .com-TLD-server. Na die doorverwijzing vraagt de resolver een .com-TLD-server naar www.example.com. De TLD-server antwoordt met nog een doorverwijzing: „Ik ken het adres niet, maar hier zijn de gezaghebbende naamservers voor example.com.”
5. De recursieve resolver vraagt de gezaghebbende server. Ten slotte vraagt de resolver de gezaghebbende naamserver voor example.com. Deze server bevat de daadwerkelijke records en geeft een definitief antwoord: „www.example.com bevindt zich op 93.184.216.34.”
6. Het antwoord wordt naar u teruggestuurd. De recursieve resolver slaat dit antwoord op in de cache, geeft het door aan uw stub-resolver, en uw browser opent een verbinding met dat IP-adres. Het hele proces duurt doorgaans slechts enkele tientallen milliseconden.

Recursieve versus iteratieve zoekopdrachten

De bovenstaande uitleg illustreert twee verschillende manieren van opvragen, en het begrijpen van het verschil neemt veel verwarring weg. Wanneer je apparaat een vraag stelt aan de recursieve resolver, verwacht het een volledig definitief antwoord. Dat is een recursieve query: de resolver neemt de verantwoordelijkheid op zich om alles te doen wat nodig is om een volledig resultaat terug te sturen. Je apparaat leunt achterover en wacht.

De communicatie die de recursieve resolver voert met de root-, TLD- en gezaghebbende servers bestaat uit iteratieve query’s. Geen van deze servers gaat namens jou op zoek naar het antwoord. In plaats daarvan reageren ze met de beste informatie die ze hebben, wat meestal een doorverwijzing is die je één stap dichter bij de bestemming brengt. De recursieve resolver herhaalt vervolgens het proces en werkt de hiërarchie af totdat hij een gezaghebbend antwoord bereikt. Kortom: je apparaat vraagt recursief, en de resolver werkt iteratief.

Caching en TTL op elke laag

Als elke zoekopdracht helemaal naar een gezaghebbende server zou moeten reizen, zou het internet tergend traag zijn en zouden de rootservers bezwijken onder de belasting. Caching voorkomt dat. Op vrijwel elke laag worden antwoorden tijdelijk opgeslagen, zodat ze kunnen worden hergebruikt. Je browser slaat gegevens op in de cache, je besturingssysteem doet dat, en de recursieve resolver maakt intensief gebruik van caching.

Hoe lang een record in de cache mag blijven, wordt bepaald door de TTL (time to live), gemeten in seconden en ingesteld door de domeineigenaar. Een record met een TTL van 3600 mag een uur in de cache blijven voordat een resolver een nieuwe kopie moet ophalen. Korte TTL’s stellen je in staat records snel te wijzigen, wat handig is tijdens een servermigratie, maar ze verhogen het aantal query’s. Lange TTL’s verbeteren de prestaties en verminderen de belasting, maar zorgen ervoor dat het langer duurt voordat wijzigingen wereldwijd zijn doorgevoerd. Daarom verlagen beheerders vaak de TTL van een record een dag vóór een geplande wijziging en verhogen ze deze daarna weer.

De DNS-hiërarchie en de rootservers

DNS is georganiseerd als een omgekeerde boom. Helemaal bovenaan bevindt zich de root, weergegeven als een enkele punt die meestal onzichtbaar is. Onder de root bevinden zich de topleveldomeinen (TLD’s) zoals .com, .org en landcodes zoals .uk of .de. Onder elk TLD bevinden zich de tweedelijnsdomeinen die door particulieren en organisaties worden geregistreerd, zoals example.com. Daaronder bevinden zich subdomeinen zoals www of mail. Als je een domeinnaam van rechts naar links leest, ga je in de hiërarchie van het algemene naar het specifieke.

De root wordt bediend door een systeem dat bekendstaat als de „13 rootservers“. In werkelijkheid zijn dit 13 benoemde clusters, gelabeld van A tot en met M, die elk door een andere organisatie worden beheerd. Achter elk van die 13 adressen gaan honderden fysieke servers schuil die wereldwijd zijn verspreid met behulp van een techniek die ‘anycast’ wordt genoemd, en die je verzoek naar de dichtstbijzijnde beschikbare server leidt. Zo kunnen een handvol benoemde toegangspunten op betrouwbare wijze de verzoeken van de hele wereld beantwoorden, met een lage latentie en een hoge weerbaarheid tegen storingen en aanvallen.

Uitleg over DNS-recordtypes

De DNS-zone van een domein is een verzameling records, en elk recordtype dient een specifiek doel. Inzicht hierin is essentieel voor iedereen die een website beheert of e-mail beheert. De onderstaande tabel geeft een overzicht van de belangrijkste typen met een voorbeeld van elk.

A- en AAAA-records

Dit zijn de werkpaarden die namen aan adressen koppelen. Een A-record verwijst naar een IPv4-adres, terwijl een AAAA-record verwijst naar een IPv6-adres. Een domein kan beide hebben, zodat clients die elk van beide protocollen gebruiken het kunnen bereiken. Wanneer uw browser vraagt "waar is example.com", is het meestal een van deze twee records die het definitieve antwoord geeft.

CNAME-records

Een CNAME creëert een alias, waarbij de ene naam wordt doorgestuurd naar een andere canonieke naam. Het wordt vaak gebruikt om www naar het kale domein te verwijzen, of om een aangepast subdomein naar het adres van een hostingprovider te verwijzen. Een belangrijke regel is dat een CNAME niet naast andere records met dezelfde naam kan bestaan; daarom worden in de root van een domein meestal A- of AAAA-records gebruikt in plaats van een CNAME.

MX- en e-mailrecords

MX-records geven aan welke servers e-mail voor uw domein accepteren, waarbij een prioriteitsnummer de volgorde bepaalt waarin ze worden geprobeerd. Lagere nummers hebben de voorkeur, dus een server met prioriteit 10 wordt eerder geprobeerd dan een server met prioriteit 20. Maar MX-records vormen slechts een deel van het DNS-verhaal rond e-mail.

TXT-records: SPF, DKIM en DMARC

TXT-records bevatten vrije tekst, en de e-mailwereld is er sterk van afhankelijk voor drie onderling samenhangende authenticatiemechanismen. SPF geeft een lijst van de servers die e-mail mogen verzenden namens uw domein, waardoor ontvangers vervalsingen kunnen afwijzen. DKIM publiceert een cryptografische openbare sleutel, zodat ontvangers kunnen verifiëren dat een bericht door uw domein is ondertekend en tijdens het transport niet is gewijzigd. DMARC koppelt deze twee aan elkaar en vertelt ontvangers wat ze moeten doen met berichten die de SPF- of DKIM-controles niet doorstaan en waar ze rapporten naartoe moeten sturen. Samen vormen ze de ruggengraat van de moderne e-mailbezorgbaarheid.

NS- en SOA-records

NS-records delegeren bevoegdheden en noemen de servers die verantwoordelijk zijn voor een zone. Het SOA-record staat bovenaan elke zone en bevat administratieve gegevens, zoals de primaire naamserver, de verantwoordelijke contactpersoon, een serienummer dat verandert wanneer de zone wordt bewerkt, en timers die bepalen hoe secundaire servers hun kopieën van de zone vernieuwen.

CAA- en PTR-records

Een CAA-record beperkt welke certificeringsinstanties certificaten voor uw domein mogen uitgeven, waardoor een extra beschermingslaag tegen ongeautoriseerde certificaten wordt toegevoegd. Als u wilt begrijpen hoe deze certificaten uw verkeer beveiligen, raadpleeg dan onze gids waarin SSL-certificaten worden uitgelegd. Een PTR-record regelt reverse DNS, waarbij een IP-adres wordt gekoppeld aan een hostnaam. Dit wordt regelmatig gecontroleerd door e-mailservers om de legitimiteit van een afzender te beoordelen.

DNS en e-mailbezorgbaarheid

DNS is voor e-mail minstens zo belangrijk als voor het web. Wanneer een e-mailserver een bericht naar uw domein wil bezorgen, zoekt deze uw MX-records op om de juiste bestemming te vinden. Wanneer een ontvangende server wil bepalen of een inkomend bericht betrouwbaar is, controleert deze uw SPF-, DKIM- en DMARC-records en verifieert vaak ook het PTR-record van de verzendende server. Als een van deze records ontbreekt of verkeerd is geconfigureerd, kan legitieme e-mail in de spamfolder terechtkomen of zelfs helemaal worden geweigerd. Het correct instellen van uw DNS-e-mailrecords is een van de meest effectieve maatregelen die u kunt nemen om ervoor te zorgen dat uw berichten in de inbox terechtkomen in plaats van in de spamfolder te verdwijnen.

DNS-beveiliging

Omdat DNS zo fundamenteel is, is het een doelwit geworden, en er bestaan verschillende technologieën om het te beveiligen:

• DNSSEC voegt cryptografische handtekeningen toe aan DNS-records, zodat resolvers kunnen verifiëren dat een antwoord daadwerkelijk afkomstig is van de gezaghebbende bron en niet is gemanipuleerd. Het beschermt de integriteit van de gegevens, maar versleutelt deze niet.
• DNS over HTTPS (DoH) en DNS over TLS (DoT) versleutelen de communicatie tussen je apparaat en de recursieve resolver. Van oudsher werden DNS-verzoeken in leesbare tekst verzonden, waardoor iedereen op het netwerkpad ze kon zien en zelfs wijzigen. DoH en DoT dichten dat gat door verzoeken te versleutelen.
• Cache poisoning is een klassieke aanval waarbij een kwaadwillende actor een resolver misleidt om een vals antwoord in de cache op te slaan, waardoor slachtoffers naar een frauduleuze server worden omgeleid. DNSSEC en moderne beveiligingsmaatregelen voor resolvers, zoals willekeurig gekozen bronpoorten, maken deze aanval veel moeilijker uit te voeren.

Veelvoorkomende DNS-problemen en probleemoplossing

Wanneer een website niet laadt, is DNS vaak de boosdoener. Enkele van de meest voorkomende problemen zijn:

• Vertragingen bij de verspreiding. Nadat u een record hebt gewijzigd, kunnen oude, in de cache opgeslagen waarden blijven bestaan totdat hun TTL is verstreken. Dit is de reden waarom een wijziging voor u al zichtbaar kan zijn, maar voor anderen nog niet.
• Typefouten en ontbrekende records. Een verkeerd gespelde hostnaam of een vergeten A-record leidt tot fouten die gemakkelijk over het hoofd worden gezien.
• Niet-overeenkomende naamservers. Als uw registrar het domein naar de verkeerde naamservers verwijst, wordt geen van uw zorgvuldig opgestelde records ooit geraadpleegd.
• Conflicterende CNAME’s. Het plaatsen van een CNAME naast andere records onder dezelfde naam verstoort de resolutie.
• Caching van de resolver. Soms is het probleem een verouderde vermelding in uw eigen apparaat of router, wat kan worden opgelost door de cache te legen.

Hoe je zelf DNS-records kunt controleren

Je hoeft geen netwerkingenieur te zijn om DNS-records op te zoeken. Met opdrachtregelprogramma’s zoals dig en nslookup, die op de meeste systemen beschikbaar zijn, kun je elk type record rechtstreeks opvragen. Als je bijvoorbeeld het A-record van een domein opvraagt, krijg je het IPv4-adres te zien, terwijl het opvragen van MX-records de mailservers onthult. Als je liever niet met de opdrachtregel werkt, kun je met een online DNS-opzoektool de records van elk domein vanuit je browser opvragen zonder dat je software hoeft te installeren. Zo kun je eenvoudig controleren of een recente wijziging is doorgevoerd of een verkeerde configuratie opsporen.

Door er een gewoonte van te maken om DNS-records te controleren, wordt het hele systeem begrijpelijker. Zodra je de A-, MX- en TXT-records voor je eigen domein kunt zien, verandert het abstracte telefoonboek in een concrete, begrijpelijke verzameling vermeldingen waarover je zelf de controle hebt. Vanaf dat moment is het opsporen van de oorzaak van een trage website, een teruggestuurde e-mail of een certificaatwaarschuwing een kwestie van het lezen van de records in plaats van gissen.

Veelgestelde vragen

Waar staat DNS voor?

DNS staat voor Domain Name System. Het is het gedistribueerde systeem dat voor mensen leesbare domeinnamen vertaalt naar de numerieke IP-adressen die computers gebruiken om met elkaar te communiceren.

Waarom wordt DNS het telefoonboek van het internet genoemd?

Net zoals je in een telefoonboek het telefoonnummer van iemand kunt opzoeken aan de hand van zijn of haar naam, stelt DNS je computer in staat het IP-adres van een website op te zoeken aan de hand van de domeinnaam. Jij onthoudt de eenvoudige naam, en DNS zorgt voor de vertaling naar het nummer dat machines daadwerkelijk nodig hebben.

Hoe lang duurt het voordat DNS-wijzigingen van kracht worden?

Dat hangt af van de TTL van het record en hoe intensief resolvers langs het pad het in de cache hebben opgeslagen. Wijzigingen kunnen binnen enkele minuten zichtbaar zijn als de TTL kort is, maar het kan tot 24 tot 48 uur duren voordat ze wereldwijd volledig zijn doorgevoerd wanneer oudere waarden uit de cache nog steeds in gebruik zijn.

Wat is het verschil tussen een recursieve resolver en een gezaghebbende server?

Een recursieve resolver doet het zoekwerk om een antwoord te vinden door namens u andere servers te raadplegen en het resultaat in de cache op te slaan. Een gezaghebbende server is de definitieve bron die daadwerkelijk de records van een domein bevat en het definitieve antwoord geeft.

Is DNS versleuteld?

Traditioneel DNS is niet versleuteld, wat betekent dat verzoeken in leesbare tekst worden verzonden. Nieuwere standaarden zoals DNS over HTTPS en DNS over TLS versleutelen het verkeer tussen uw apparaat en de resolver, terwijl DNSSEC handtekeningen toevoegt die de authenticiteit van de antwoorden verifiëren.

Hoe kan ik de DNS-records van een domein controleren?

Je kunt command-line tools zoals dig of nslookup gebruiken, of een browsergebaseerde DNS-opzoekservice. Hiermee kun je specifieke recordtypes opvragen, zoals A, AAAA, MX en TXT, zodat je de configuratie kunt controleren of problemen kunt oplossen.