Lees hoe Paul Mockapetris DNS creëerde en onhandige hostlijsten verving door een schaalbaar naamgevingssysteem. Ontdek hoe DNS werkt, waarom caching belangrijk is en basisbeveiliging.
Elke keer dat je een webadres typt, op een link klikt of een e-mail verstuurt, vertrouw je op een eenvoudige gedachte: mensen moeten gedenkwaardige namen kunnen gebruiken, terwijl computers het werk doen om de juiste machine te vinden.
DNS lost een alledaags probleem op: computers communiceren met numerieke adressen (IP-adressen) zoals 203.0.113.42, maar mensen willen geen reeksen cijfers onthouden. Je wilt example.com onthouden, niet welk adres die site vandaag toevallig gebruikt.
Het Domain Name System (DNS) is het "adresboek" van het internet dat mensvriendelijke domeinnamen vertaalt naar de IP-adressen die computers gebruiken om verbinding te maken.
Die vertaling klinkt klein, maar het is het verschil tussen een internet dat bruikbaar aanvoelt en een internet dat voelt als een telefoonboek dat volledig uit cijfers bestaat.
Dit is een niet-technische rondleiding—geen netwerkachtergrond nodig. We lopen langs:
Onderweg maak je kennis met Paul Mockapetris, de ingenieur die DNS ontwierp in het begin van de jaren 1980. Zijn werk was belangrijk omdat hij niet alleen een nieuw naamformaat creëerde—hij ontwierp een systeem dat kon schalen toen het internet zich uitbreidde van een klein onderzoeksnetwerk naar iets dat door miljarden mensen werd gebruikt.
Als je ooit hebt meegemaakt dat een site “down” ging, hebt gewacht tot een domeinwijziging “gepropageerd” was of je afgevraagd waarom e-mailinstellingen mysterieuze DNS-vermeldingen bevatten, dan heb je DNS al van buitenaf ontmoet. De rest van dit artikel legt uit wat er achter de schermen gebeurt—duidelijk en zonder jargon.
Lang voordat iemand een vertrouwd webadres typte, hadden vroege netwerken een eenvoudiger probleem: hoe bereik je een bepaald apparaat? Computers konden met elkaar praten met IP-adressen (nummers zoals 10.0.0.5), maar mensen gaven de voorkeur aan hostnamen—korte labels zoals MIT-MC of SRI-NIC die makkelijker te onthouden en te delen waren.
Voor het vroege ARPANET was de oplossing een enkel gedeeld bestand genaamd HOSTS.TXT. Het was in wezen een opzoektabel: een lijst hostnamen gekoppeld aan hun IP-adressen.
Elke computer bewaarde een lokale kopie van dit bestand. Als je met een naam naar een machine wilde verbinden, controleerde je systeem HOSTS.TXT en vond het bijbehorende IP-adres.
Dit werkte in het begin omdat het netwerk klein was, wijzigingen relatief zeldzaam waren en er een duidelijke plaats was om updates te halen.
Naarmate meer organisaties deelnamen, begon de aanpak te barsten door normale groei:
Het kernprobleem was coördinatie. HOSTS.TXT was als één gedeeld adresboek voor de hele wereld. Als iedereen van datzelfde boek afhankelijk is, vereist elke correctie een wereldwijde wijziging en moet iedereen snel de nieuwste versie downloaden. Zodra het netwerk een bepaalde omvang bereikte, werd dat “één bestand voor alles”-model te langzaam, te gecentraliseerd en te foutgevoelig.
DNS verving niet het idee om namen aan nummers te koppelen—het verving de fragiele manier waarop die koppeling werd onderhouden en verspreid.
Begin jaren 1980 verschuifte het internet van een klein onderzoeksnetwerk naar iets groters, rommeliger en meer gedeeld. Er kwamen meer machines bij, organisaties wilden autonomie en mensen hadden een gemakkelijkere manier nodig om diensten te bereiken dan numerieke adressen te onthouden.
Paul Mockapetris, die in die omgeving werkte, wordt algemeen erkend als de ontwerper van DNS. Zijn bijdrage was niet een flitsend product—het was een ingenieursantwoord op een heel praktisch vraagstuk: hoe houd je namen bruikbaar als het netwerk maar blijft groeien?
Een naamgevingssysteem klinkt simpel tot je je voorstelt wat “simpel” toen betekende: één gedeelde lijst van namen die iedereen moest downloaden en bijhouden. Die aanpak valt uit elkaar zodra verandering constant wordt. Elke nieuwe host, hernoeming of correctie wordt coördinatiewerk voor iedereen.
Mockapetris’ belangrijkste inzicht was dat namen niet alleen data zijn; het zijn gedeelde afspraken. Als het netwerk groeit, moet ook het systeem om die afspraken te maken en te verspreiden mee kunnen groeien—zonder dat elke computer voortdurend een meesterlijst hoeft op te halen.
DNS verving het idee van een “één autoritatief bestand” door een gedistribueerd ontwerp:
Dat is de stille genialiteit: DNS is niet ontworpen om slim te zijn; het is ontworpen om te blijven werken onder echte beperkingen—beperkte bandbreedte, frequente wijzigingen, veel onafhankelijke beheerders en een netwerk dat maar bleef groeien.
DNS is niet uitgevonden als een slimme truc—het is ontworpen om specifieke, erg praktische problemen op te lossen die zichtbaar werden toen het vroege internet groeide. Mockapetris’ benadering was eerst duidelijke doelen stellen en daarna een naamgevingssysteem bouwen dat decennialang mee kon gaan.
Het kernconcept is delegatie: verschillende groepen beheren verschillende delen van de naamboom.
Bijvoorbeeld: één organisatie beheert wat onder .com valt, een registrar helpt je example.com te claimen, en vervolgens beheer jij (of je DNS-provider) de records voor www.example.com, mail.example.com, enzovoort. Dit splitst de verantwoordelijkheid netjes, zodat groei geen knelpunt creëert.
DNS gaat ervan uit dat er problemen zullen optreden—servers crashen, netwerken partitioneren, routes veranderen. Daarom vertrouwt het op meerdere authoritative servers voor een domein en op caching in resolvers, zodat een tijdelijke storing niet meteen elke lookup breekt.
DNS vertaalt mensvriendelijke namen naar technische data, het meest bekend zijn IP-adressen. Het is niet "het internet zelf"—het is een naam- en opzoeksdienst die je apparaten helpt vinden waar ze verbinding mee moeten maken.
DNS maakt namen beheerbaar door ze als een boom te organiseren. In plaats van één gigantische lijst waarin elke naam uniek en wereldwijd gecontroleerd moet worden (en iemand die dat beheert), deelt DNS naamgeving op in niveaus en delegeert verantwoordelijkheid.
Een DNS-naam wordt van rechts naar links gelezen:
www.example.com. eindigt technisch met een ..com, .org, .net, landcodes zoals .ukexample in example.comwww in www.example.comDus www.example.com kan worden opgesplitst in:
com (de TLD)example (het domein geregistreerd onder .com)www (een label dat de domeineigenaar creëert en beheert)Deze structuur vermindert conflicten omdat namen alleen uniek hoeven te zijn binnen hun ouder. Veel organisaties kunnen een www subdomein hebben, omdat www.example.com en www.another-example.com elkaar niet in de weg zitten.
Het verdeelt ook de werklast. De .com-operators hoeven niet elke website te beheren; ze wijzen alleen naar wie verantwoordelijk is voor example.com, en daarna beheert de eigenaar van example.com de details.
Een zone is simpelweg een beheersbaar stuk van die boom—DNS-data waarvoor iemand verantwoordelijk is om te publiceren. Voor veel teams betekent “onze zone” de DNS-records voor example.com en de subdomeinen die ze hosten, opgeslagen op hun authoritatieve DNS-provider.
Als je een website-naam in je browser typt, vraag je niet direct aan “het internet”. Een paar gespecialiseerde helpers delen het werk zodat het antwoord snel en betrouwbaar gevonden kan worden.
Jij (je apparaat en browser) begint met een eenvoudige vraag: "Welk IP-adres hoort bij example.com?" Je apparaat weet het meestal nog niet en wil niet zelf tien servers moeten bellen om het uit te zoeken.
Een recursive resolver doet het zoekwerk namens jou. Deze wordt meestal geleverd door je ISP, je werkplek/school IT of een publieke resolver. Het belangrijkste voordeel: hij kan eerder opgehaalde antwoorden hergebruiken (cachen), wat voor iedereen sneller maakt.
Authoritatieve DNS-servers zijn de bron van waarheid voor een domein. Zij "zoeken" niet het internet af; ze hebben de officiële records die aangeven welke IP's, mailservers of verificatietokens bij dat domein horen.
example.com.Zie de recursive resolver als een bibliothecaris die iets voor je opzoekt (en populaire antwoorden onthoudt), terwijl een authoritative server de officiële catalogus van de uitgever is: die bladert niet in andere catalogi—hij vermeldt simpelweg wat waar is voor zijn eigen boeken.
Als je example.com in je browser typt, zoekt je browser eigenlijk niet naar een naam—hij heeft een IP-adres (een nummer zoals 93.184.216.34) nodig om te weten waar naartoe te verbinden. DNS is het systeem "vind het nummer voor deze naam".
Je browser vraagt eerst het besturingssysteem van je computer/telefoon: "Weten we al het IP-adres voor example.com?" Het OS controleert zijn korte-termijn geheugen (cache). Als er een vers antwoord is, is de lookup hier klaar.
Als het OS het niet heeft, stuurt het de vraag door naar een DNS-resolver—meestal beheerd door je ISP, je bedrijf of een publieke provider. Zie de resolver als je "DNS-conciërge": hij doet het werk zodat je apparaat dat niet hoeft te doen.
Als de resolver het antwoord niet in de cache heeft, start hij een geleide zoektocht:
.com) te vinden is. De rootserver geeft niet het eind-IP—hij geeft verwijzingen, oftewel aanwijzingen: "Vraag deze .com-servers daarna."\n- TLD-server (.com): De resolver vraagt de .com-servers waar example.com wordt afgehandeld. Weer geen eind-IP—meer aanwijzingen: "Vraag deze authoritative server voor example.com."\n- Authoritative server: Dit is de bron van waarheid voor dat domein. Hij antwoordt met het daadwerkelijke record (bijv. een A of AAAA record) met het IP-adres.De resolver stuurt het IP terug naar je OS en vervolgens naar je browser, die dan verbinding kan maken. De meeste opzoeken voelen meteen aan omdat resolvers en apparaten antwoorden tijdelijk opslaan voor de periode die door de domeineigenaar is ingesteld (TTL).
Een simpele stroom om te onthouden is: Browser → OS-cache → Resolver-cache → Root (verwijzing) → TLD (verwijzing) → Authoritative (antwoord) → terug naar Browser.
DNS zou erg traag aanvoelen als elke bezoek aan een site opnieuw moest beginnen en meerdere servers moest vragen voor hetzelfde antwoord. In plaats daarvan vertrouwt DNS op caching—tijdelijke "herinnering" van recente opzoeken—zodat de meeste gebruikers antwoorden in milliseconden krijgen.
Wanneer je apparaat een DNS-resolver vraagt om example.com, moet die resolver de eerste keer soms werk doen. Nadat hij het antwoord kent, slaat hij het op in een cache. De volgende persoon die dezelfde naam vraagt, krijgt direct antwoord.
Caching bestaat om twee redenen:
Elk DNS-record wordt geleverd met een TTL (Time To Live) waarde. Beschouw TTL als instructies die zeggen: bewaar dit antwoord X seconden, gooi het daarna weg en vraag opnieuw.
Als een record een TTL van 300 heeft, mogen resolvers het tot 5 minuten hergebruiken voordat ze opnieuw controleren.
TTL is een balans:
Als je een website naar een nieuwe host verhuist, een CDN wisselt of een e-mailovergang doet (MX-records wijzigen), bepaalt TTL hoe snel gebruikers stoppen met naar de oude locatie te gaan.
Een veelgebruikte aanpak is om TTL's vooraf te verlagen voor een geplande wijziging, de wijziging door te voeren en daarna de TTL's weer te verhogen als alles stabiel is. Daarom is DNS van dag tot dag snel—and toch soms “hardnekkig” direct na een update.
Als je in een DNS-dashboard inlogt, bewerk je meestal een handvol recordtypen. Elk record is een korte instructie die het internet vertelt waar mensen heen moeten (web), waar e-mail afgeleverd wordt of hoe eigendom te verifiëren.
| Record | Wat het doet | Simpel voorbeeld |
|---|---|---|
| A | Wijst een naam naar een IPv4-adres | example.com → 203.0.113.10 (je webserver) |
| AAAA | Wijst een naam naar een IPv6-adres | example.com → 2001:db8::10 (zelfde idee, nieuwere adressering) |
| CNAME | Maakt van de ene naam een alias van een andere naam | www.example.com → example.com (zodat beide naar hetzelfde wijzen) |
| MX | Zegt waar e-mail voor het domein naartoe moet | example.com → mail.provider.com (priority 10) |
| TXT | Slaat "notities" op die machines kunnen lezen (verificatie, e-mailbeleid) | example.com heeft een SPF-record zoals v=spf1 include:mailgun.org ~all |
| NS | Zegt welke authoritative servers DNS voor een domein/zone hosten | example.com → ns1.dns-host.com |
| SOA | De "header" van de zone: primaire NS, admin-contact en timingwaarden | example.com SOA bevat ns1.dns-host.com en retry/expire timers |
Een paar DNS-fouten komen steeds terug:
example.com). Veel DNS-providers staan dat niet toe omdat de root-naam ook records zoals NS en SOA moet bevatten. Als je het domein naar een hostnaam wilt laten wijzen, gebruik dan een A/AAAA-record of een “ALIAS/ANAME” functie als je provider die ondersteunt.www). Kies één aanpak.mail.provider.com kan e-mail breken; ontbrekende/extra punten en het kopiëren van het verkeerde hostveld (bijv. @ vs www) veroorzaken vaak uitval.Als je DNS-richtlijnen met een team deelt, maakt een kleine tabel zoals hierboven in je docs (of een runbook-pagina) controles en troubleshooting veel sneller.
DNS werkt omdat verantwoordelijkheid over veel organisaties is verdeeld. Die verdeling maakt het ook mogelijk om van provider te wisselen, instellingen te wijzigen en je naam online te houden zonder de "internet"-macht te hoeven vragen.
Een domein registreren is het recht kopen om een naam te gebruiken (zoals example.com) voor een bepaalde tijd. Zie het als het reserveren van een label zodat niemand anders het kan claimen.
DNS-hosting is het draaien van de instellingen die de wereld vertellen waar die naam naar verwijst—je website, e-mailprovider, verificatierecords, enz. Je kunt een domein registreren bij de ene partij en DNS hosten bij een andere.
.com, .org of .uk beheert. Zij houden de officiële database bij van wie welke naam onder die TLD bezit en welke name servers daarvoor verantwoordelijk zijn.Root-servers zitten bovenaan DNS. Ze kennen niet het IP-adres van je website en ze slaan je domeinrecords niet op. Hun taak is beperkter: ze vertellen resolvers waar ze de authoritative servers voor elke TLD kunnen vinden (bijv. waar .com wordt afgehandeld).
Wanneer je name servers instelt voor je domein bij je registrar, creëer je een delegatie. De .com registry (via zijn authoritative servers) zal dan queries voor example.com doorverwijzen naar de name servers die je hebt gekozen.
Vanaf dat moment bepalen die name servers de antwoorden die de rest van het internet ontvangt—totdat je de delegatie weer wijzigt.
DNS is gebouwd op vertrouwen: wanneer je een naam typt, ga je ervan uit dat het antwoord naar de echte dienst verwijst. Meestal is dat zo—maar DNS is ook een favoriete plek om aan te vallen, omdat een kleine wijziging in "waar deze naam heen gaat" veel mensen kan omleiden.
Een klassiek probleem is spoofing of cache poisoning. Als een aanvaller een DNS-resolver kan misleiden om een vervalst antwoord op te slaan, kunnen gebruikers naar het verkeerde IP-adres worden gestuurd, zelfs als ze de juiste domeinnaam typten. Het resultaat kan phishing, malware-downloads of onderschept verkeer zijn.
Een ander probleem is domeinkaping op registrar-niveau. Als iemand in je registrar-account komt, kan die persoon name servers of DNS-records wijzigen en je domein effectief overnemen zonder je hosting aan te raken.
En er is de alledaagse gevaar: misconfiguraties. Een verkeerde CNAME, een oud TXT-record of een fout MX-record kan inlogflows, e-mailbezorging of verificatiechecks breken. Zulke uitval ziet er vaak uit als "het internet is down", maar de oorzaak is meestal een kleine DNS-wijziging.
DNSSEC voegt cryptografische handtekeningen toe aan DNS-data. In eenvoudige bewoordingen: het DNS-antwoord kan geverifieerd worden om te bevestigen dat het niet onderweg is aangepast en dat het echt van de authoritatieve DNS van het domein komt. DNSSEC versleutelt DNS niet en maakt het opzoeken niet anoniem, maar het kan veel vormen van vervalste antwoorden voorkomen.
Traditionele DNS-query's zijn eenvoudig te observeren voor netwerken. DNS-over-HTTPS (DoH) en DNS-over-TLS (DoT) versleutelen de verbinding tussen je apparaat en een resolver, wat afluisteren en sommige manipulatie onderweg vermindert. Ze maken DNS niet per se anoniem, maar ze veranderen wie queries kan zien en manipuleren.
Gebruik MFA op je registrar, schakel domain/transfer locks in en beperk wie DNS mag wijzigen. Behandel DNS-wijzigingen als productie-deploys: eist review, houd een wijzigingslog bij en zet monitoring/alerts op voor record- of name server-wijzigingen zodat je snel op verrassingen wordt gewezen.
DNS voelt soms als "instellen en vergeten", tot een kleine wijziging je website of e-mail neerlegt. Het goede nieuws: een paar gewoontes maken DNS-beheer voorspelbaar—ook voor kleine teams.
Begin met een licht proces dat je kunt herhalen:
De meeste DNS-problemen zijn niet ingewikkeld—ze zijn gewoon lastig snel te ontdekken.
Als je vaak apps uitrolt, wordt DNS onderdeel van je releaseproces. Teams die webapps uitrollen via platforms zoals Koder.ai (waar je apps kunt bouwen en deployen via chat en daarna custom domains kunt koppelen) vertrouwen nog steeds op dezelfde basisprincipes: correcte A/AAAA/CNAME-doelen, verstandige TTL's tijdens cutovers en een duidelijk rollback-pad als iets naar de verkeerde plek wijst.
Als je e-mail vanaf je domein verstuurt, beïnvloedt DNS rechtstreeks of berichten in inboxen terechtkomen.
Mensvriendelijke namen maakten het internet groter dan een kleine onderzoeksgemeenschap. Behandel DNS als gedeelde infrastructuur—een beetje zorg vooraf houdt je site bereikbaar en je e-mail betrouwbaar naarmate je groeit.
DNS (Domain Name System) vertaalt mensvriendelijke namen zoals example.com naar IP-adressen zoals 93.184.216.34, zodat je apparaat weet waar het verbinding mee moet maken.
Zonder DNS zou je numerieke adressen voor elke site en dienst moeten onthouden.
Vroege netwerken vertrouwden op een enkel gedeeld bestand (HOSTS.TXT) dat namen aan IP-adressen koppelde.
Naarmate het netwerk groeide, werd dat onhoudbaar: constante updates, conflicterende namen en uitval door verouderde kopieën. DNS verving het “één globaal bestand”-model door een gedistribueerd systeem.
Paul Mockapetris ontwierp DNS begin jaren 1980 om het schaalbaarheidsprobleem van naamgeving op een snelgroeiend netwerk op te lossen.
De kern was delegatie: verantwoordelijkheid opdelen over veel organisaties zodat er geen enkele meesterlijst of beheerder als knelpunt fungeert.
DNS-namen zijn hiërarchisch en worden van rechts naar links gelezen:
www.example.com..comexample.comwww.example.comDeze hiërarchie maakt delegatie en beheer op wereldschaal praktisch.
Een recursive resolver zoekt antwoorden namens je en cachet ze (vaak beheerd door een ISP, werkplek of publieke provider).
Een authoritative DNS-server is de bron van waarheid voor de records van een domein; die ‘zoekt’ niet, maar geeft antwoord voor zijn zone.
Een typische lookup verloopt zo:
.com) → de authoritative servers van het domein.\n4. De authoritative server retourneert het record (bijv. een A/AAAA).\n5. De resolver cachet het resultaat en antwoordt je apparaat.TTL (Time To Live) vertelt resolvers hoe lang ze een DNS-antwoord mogen cachen voordat ze opnieuw controleren.
“Propagatie” is meestal gewoon dat caches op verschillende momenten verlopen.
De meest gebruikte records die je zult beheren:
Een registrar is waar je het domein registreert/verlenging doet (je recht om example.com te gebruiken).
Een DNS-host/provider runt de authoritative name servers en slaat je DNS-records op.
Je kunt registreren bij de ene partij en DNS hosten bij een andere door de NS-instellingen bij de registrar aan te passen.
DNS kan falen door:
MX, conflicterende records, typfouten)Praktische verdedigingen:
A / AAAA: wijzen een naam naar een IPv4/IPv6-adres (webapps, servers).CNAME: alias van de ene hostnaam naar een andere (veelgebruikt voor www).MX: waar e-mail voor het domein moet worden afgeleverd.TXT: verificatie en e-mailauthenticatie (SPF, DKIM, DMARC).NS: welke name servers autoritatief zijn voor het domein.Een praktische regel: plaats geen CNAME en A record op dezelfde hostnaam.