Ga naar hoofdinhoud

DNS

Niemand typt 193.190.253.10 in zijn adresbalk. We typen www.ap.be. Het Domain Name System is het systeem dat die naam vertaalt naar een adres waar het netwerk iets mee kan.

DNS wordt vaak "het telefoonboek van het internet" genoemd. De vergelijking klopt, maar onderschat de schaal: het gaat om honderden miljoenen namen, verspreid over miljoenen servers, zonder centrale lijst, met antwoorden in enkele milliseconden.

Waarom DNS bestaat​

In de begindagen van het internet stond alles in één bestand: HOSTS.TXT. Wilde je een machine toevoegen, dan mailde je naar het instituut dat het bestand beheerde, en downloadde iedereen af en toe de nieuwe versie. Met enkele honderden machines werkte dat. Met enkele duizenden niet meer.

DNS (1983) verving dat door drie principes die het systeem tot vandaag dragen:

  • Hiërarchie – de namen zijn opgedeeld in niveaus, zodat niemand alles hoeft te kennen.
  • Delegatie – elk niveau wijst het volgende aan. Wie ap.be beheert, beslist zelf over www.ap.be.
  • Caching – antwoorden worden onderweg bewaard, zodat dezelfde vraag zelden twee keer helemaal moet reizen.

De hiërarchie​

Lees een domeinnaam van rechts naar links: elke punt is een niveau lager in de boom.

. ← root (de onzichtbare punt op het einde)
│
┌───────────┼───────────┐
.be .com .org ← topleveldomeinen (TLD)
│
ap.be ← domein (bij een registrar geregistreerd)
│
┌────┴────┐
www.ap.be mail.ap.be ← subdomeinen (beheerd door de eigenaar)
NiveauWie beheert hetVoorbeeld
RootDertien serverclusters wereldwijd, gecoördineerd door ICANN.
TLDPer extensie een registry, bv. DNS Belgium voor .be.be, .com, .dev
DomeinDe eigenaar, via een registrar waar hij de naam huurtap.be
SubdomeinDe eigenaar zelf, zonder tussenkomst van derdenwww.ap.be, api.ap.be
Je koopt een domeinnaam niet, je huurt ze

Een registrar (Combell, Cloudflare, Namecheap, …) registreert de naam in jouw plaats bij de registry en houdt ze geldig zolang je betaalt. Wat je daarna zelf beheert, zijn de records: de gegevens die zeggen waar het verkeer naartoe moet.

Een opzoeking, stap voor stap​

Klik door de stappen. Let op het label linksboven: dat zegt wie er op dat moment aan zet is.

www.ap.be -> ?
Jouw toestel

Stap 1. De browser kijkt in zijn eigen cache

Een naam die je net nog opvroeg, hoeft niet opnieuw opgezocht te worden.

Elke browser houdt zelf een korte lijst bij van namen die hij recent vertaald heeft. Zit het adres daar nog in, dan stopt de opzoeking hier al, in minder dan een milliseconde. In Chrome kan je die lijst bekijken via chrome://net-internals/#dns.

browsercache: www.ap.be -> 193.190.253.10 (nog 42 s geldig)
1 / 8

Caching en TTL​

Elk record draagt een TTL (time to live) in seconden. Zolang die tijd loopt, mag iedereen die het antwoord ontving het bewaren en hergebruiken.

TTLBetekenisTypisch gebruik
3005 minutenVlak voor een verhuizing van een site
36001 uurGewone instelling
8640024 uurRecords die zelden wijzigen

Caching verklaart ook de meest gehoorde frustratie bij een domeinverhuizing: je hebt het record aangepast, maar collega's zien nog steeds de oude site. Hun resolver bewaart het oude antwoord tot de TTL afloopt. Dat heet propagatie, en het is geen fout maar een gevolg van het ontwerp.

Vuistregel bij een verhuizing

Zet de TTL een dag op voorhand laag (bv. 300). Doe daarna pas de wijziging. Zo is iedereen binnen vijf minuten mee in plaats van binnen een dag. Verhoog de TTL nadien weer.

Zelf opzoeken met nslookup en dig​

ToolBeschikbaar opTypisch gebruik
nslookupWindows, macOS, LinuxSnel een adres opzoeken
digmacOS, Linux, Windows (via installatie)Volledig antwoord met records en TTL

nslookup​

nslookup www.ap.be
Server: 192.168.0.1
Address: 192.168.0.1#53

Non-authoritative answer:
Name: www.ap.be
Address: 193.190.253.10

Vier regels, vier betekenissen:

RegelWat ze zegt
Server / Address bovenaanWie je het gevraagd hebt: hier je eigen router, die de vraag doorspeelt. Poort 53 is de standaardpoort van DNS
Non-authoritative answerHet antwoord komt uit een cache, niet rechtstreeks van de autoritatieve nameserver. Dat is normaal en betekent niet dat het fout is
NameDe naam die je opvroeg
AddressHet IP-adres dat erbij hoort: dit is wat je zocht

Je kan ook een specifiek recordtype of een specifieke server bevragen:

nslookup -type=MX ap.be # Enkel de mailrecords
nslookup www.ap.be 8.8.8.8 # Vraag het aan Google in plaats van aan je eigen resolver

dig​

dig toont hetzelfde, maar completer: met TTL, met het exacte recordtype, en met de volledige administratie van het antwoord. Dit is de echte uitvoer op het schoolnetwerk:

dig www.ap.be

# output:
; <<>> DiG 9.17.12 <<>> www.ap.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35487 ← NOERROR: de naam bestaat
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.ap.be. IN A ← wat je vroeg: het A-record

;; ANSWER SECTION:
www.ap.be. 3600 IN CNAME ap.be. ← www.ap.be is een alias voor ap.be
ap.be. 3600 IN A 185.135.13.219 ← en dát heeft het adres

;; Query time: 3 msec ← 3 ms: de server staat vlakbij
;; SERVER: 10.200.216.17#53(10.200.216.17) (UDP) ← wie je het vroeg, op poort 53
;; WHEN: Wed Sep 16 16:31:43 Romance (zomertijd) 2026
;; MSG SIZE rcvd: 68

Vier dingen die je uit deze uitvoer leert:

WaarWat het zegt
status: NOERRORDe opzoeking is gelukt. Bij een naam die niet bestaat staat hier NXDOMAIN
ANSWER: 2Je vroeg één record en kreeg er twee: www.ap.be is een CNAME (alias) voor ap.be, en pas dat laatste heeft het A-record met het adres. De resolver volgt die keten voor jou
3600De TTL: dit antwoord mag nog een uur bewaard worden voor er opnieuw gevraagd wordt
SERVER: 10.200.216.17De DNS-server die je bevraagd hebt. Een privaat adres, dus de server van het schoolnetwerk zelf

Lees een antwoordregel altijd van links naar rechts: de naam, de TTL, de klasse IN (internet), het type en de waarde.

De vlag aa staat hier aan

In de regel met flags staat aa, authoritative answer. Dat betekent dat de bevraagde server het domein zelf beheert, en dat is logisch: de DNS-server van AP is de bron voor ap.be. Voer je hetzelfde commando thuis uit, dan ontbreekt die vlag: je provider geeft dan een kopie uit zijn cache door. Dat is wat nslookup hierboven Non-authoritative answer noemt.

dig +short www.ap.be # Enkel het antwoord: hier twee regels, de alias en het adres
dig ap.be MX # Mailrecords
dig ap.be NS # Welke nameservers beheren dit domein?
dig @1.1.1.1 www.ap.be # Vraag het rechtstreeks aan Cloudflare, en vergelijk de SERVER-regel
dig +trace www.ap.be # Volg de volledige weg: root, TLD, autoritatief
dig +trace toont de theorie in de praktijk

dig +trace slaat de cache over en zet elke stap uit de opzoeking hierboven letterlijk op je scherm: eerst de rootservers, dan de nameservers van .be, dan die van ap.be, en pas dan het antwoord. Wie de hiërarchie één keer wil zien werken, voert dit commando uit.

Recordtypes​

Een domein is meer dan één adres. In de zone van een domein staan verschillende records, elk met een eigen taak.

TypeWat het doetVoorbeeldwaarde
AKoppelt een naam aan een IPv4-adres193.190.253.10
AAAAKoppelt een naam aan een IPv6-adres2001:db8::10
CNAMEMaakt van een naam een alias voor een andere naammijnsite.netlify.app
MXZegt welke mailserver de post voor dit domein aanneemt10 mail.ap.be
TXTVrije tekst, meestal voor verificatie en mailbeveiliging (SPF, DKIM)v=spf1 include:...
NSZegt welke nameservers dit domein beherenns1.ap.be

Een vereenvoudigde zone ziet er zo uit:

ap.be. 3600 IN A 193.190.253.10
www.ap.be. 3600 IN CNAME ap.be.
api.ap.be. 3600 IN A 193.190.253.44
ap.be. 3600 IN MX 10 mail.ap.be.
ap.be. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"

A of CNAME: wat kies je?​

Dit is de keuze die je in de praktijk het vaakst moet maken.

SituatieRecordWaarom
Je hebt een server met een vast IP-adresAJe kent het adres en het verandert niet
Je site draait bij Netlify, Vercel of GitHub PagesCNAMEDie diensten wijzigen hun adressen; met een alias volg je automatisch mee
Je wil www.jouwdomein.be naar dezelfde site laten wijzen als jouwdomein.beCNAMEEén plek onderhouden in plaats van twee
Je wil het kale domein (jouwdomein.be, zonder www) laten wijzenAOp de top van een domein is een CNAME niet toegelaten
Mail moet bij een provider aankomenMXMail volgt een eigen record, los van de website
Google of Microsoft vraagt te bewijzen dat het domein van jou isTXTEen tekstregel die zij komen nalezen
Twee regels die je vaak zal tegenkomen
  1. Geen CNAME op de top van een domein. jouwdomein.be moet een A-record hebben (of een equivalent zoals ALIAS of ANAME bij sommige providers). Voor www.jouwdomein.be mag een CNAME wel.
  2. Een CNAME staat nooit naast andere records voor dezelfde naam. Heb je een CNAME voor www, dan kan je daar geen apart A- of MX-record meer bijzetten.

Het hosts-bestand​

Voor DNS ook maar iets doet, kijkt je besturingssysteem in één tekstbestand. Wat daar staat, wint altijd.

BesturingssysteemLocatie
WindowsC:\Windows\System32\drivers\etc\hosts
macOS en Linux/etc/hosts

De syntax is één regel per koppeling: eerst het IP-adres, dan een of meer namen.

127.0.0.1 localhost
127.0.0.1 mijn-project.test
192.168.0.20 testserver.local
0.0.0.0 www.tijdverspilling.be

Je hebt beheerdersrechten nodig om het bestand op te slaan: op Windows open je je editor met "Als administrator uitvoeren", op macOS of Linux gebruik je sudo nano /etc/hosts.

Waarvoor gebruik je dit in de praktijk?

  • Een domein testen voor je DNS aanpast. Je nieuwe server draait al op 203.0.113.42, maar de wereld wijst nog naar de oude. Zet de koppeling in je hosts-bestand en jij ziet de nieuwe site al, terwijl er voor niemand anders iets verandert.
  • Een leesbare naam voor je project. mijn-project.test in plaats van localhost:5173.
  • Een site blokkeren door ze naar 0.0.0.0 te sturen.
Werkt je aanpassing niet meteen?

Je toestel bewaart eerdere antwoorden. Leeg de DNS-cache na een wijziging:

ipconfig /flushdns # Windows
sudo dscacheutil -flushcache # macOS
resolvectl flush-caches # Linux (systemd)

Werkt het nog steeds niet, dan houdt je browser zelf nog een kopie bij. Chrome leeg je via chrome://net-internals/#dns.

Ruim je regels weer op

Een vergeten regel in je hosts-bestand kost later uren zoekwerk: de site werkt bij iedereen behalve bij jou, en aan de DNS ligt het niet. Zet er een commentaarregel met de datum bij, en haal ze weg zodra je test klaar is.

Test jezelf​

1. Je host je site bij Netlify en wil `www.jouwdomein.be` laten wijzen. Welk record kies je?

2. Wat betekent `Non-authoritative answer` in de uitvoer van nslookup?

3. Je zet `127.0.0.1 www.google.com` in je hosts-bestand. Wat gebeurt er als je die site opent?

4. Je hebt het A-record van je domein aangepast, maar een collega ziet nog de oude site. Wat is de meest waarschijnlijke verklaring?

Onthoud
  • DNS vertaalt namen naar IP-adressen via een hiërarchie: root → TLD → domein → subdomein.
  • Een opzoeking loopt van browsercache → hosts-bestand → OS-cache → resolver → root → TLD → autoritatieve nameserver.
  • De TTL bepaalt hoelang een antwoord bewaard mag worden; caching verklaart waarom wijzigingen niet meteen overal zichtbaar zijn.
  • nslookup en dig doen die opzoeking handmatig; dig +trace toont de volledige weg.
  • A koppelt aan een IPv4-adres, AAAA aan IPv6, CNAME is een alias, MX wijst mail aan, TXT dient voor verificatie.
  • Het hosts-bestand wint altijd van DNS. Handig om te testen, gevaarlijk om te vergeten.