Je tikt wedecom.net in je browser en binnen milliseconden laadt de site. Tussen dat moment en het eerste pakketje dat jouw computer verlaat, gebeurt er iets fundamenteels: DNS vertaalt die domeinnaam naar een IP-adres. Voor developers is DNS geen black box, het is een gelaagd, gedistribueerd systeem dat je dagelijks raakt zodra je een site deployt, een mailserver configureert of een staging-omgeving opzet.
In deze uitleg duiken we onder de motorkap. Je leert hoe DNS-resolutie werkt, welke records er bestaan, wat TTL betekent bij migraties, en hoe je met dig en nslookup snel debugt wanneer iets niet werkt zoals verwacht.
Wat is DNS eigenlijk?
DNS staat voor Domain Name System en is het gedistribueerde naamgevingssysteem van het internet. Het vertaalt voor mensen leesbare domeinnamen (zoals wedecom.net) naar IP-adressen die routers en servers gebruiken om verkeer te routeren (93.184.216.34 voor IPv4, of een langere hex-string voor IPv6).
Je kunt DNS zien als een hiërarchisch, wereldwijd telefoonboek. Maar anders dan een telefoonboek staat de data niet op één plek, ze is verspreid over miljoenen servers die samen één logisch systeem vormen. Dat maakt DNS tegelijk robuust en, bij verkeerde configuratie, lastig te debuggen.
Voor developers is DNS relevant omdat:
- Je elke deploy met een nieuwe subdomein-setup ermee te maken krijgt
- E-mailconfiguratie (SPF, DKIM, DMARC) volledig via DNS loopt
- CDN's, load balancers en failover-setups ervan afhangen
- SSL-certificaten via DNS-validatie uitgegeven worden (ACME DNS-01)
De hiërarchie: root, TLD en authoritative nameservers
DNS is strikt hiërarchisch opgebouwd. Elke laag is verantwoordelijk voor een deel van het systeem.
De rootzone
Bovenaan staat de rootzone, beheerd door IANA en bediend door 13 logische rootservers (die in werkelijkheid honderden anycast-instanties hebben). De rootservers weten één ding: welke servers verantwoordelijk zijn voor elke TLD.
Top-Level Domains (TLD's)
Daaronder zitten de TLD-nameservers. Voor .nl is dat SIDN, voor .com is dat Verisign. Zij weten welke nameservers verantwoordelijk zijn voor een specifiek domein binnen hun TLD.
Authoritative nameservers
Daaronder zitten de authoritative nameservers, de servers die de écht juiste antwoorden hebben voor jouw domein. Dit zijn meestal de nameservers van je hostingprovider, je DNS-provider (Cloudflare, AWS Route 53) of je registrar.
Wanneer je bij je domeinregistrar de nameservers instelt op bijvoorbeeld ns1.hostbit.nl en ns2.hostbit.nl, vertel je de TLD-nameservers: "voor alle vragen over mijn domein, ga naar die servers."
Hoe een DNS-query echt verloopt
Stel, je typt wedecom.net in je browser. Dit gebeurt er achter de schermen:
- Browsercache: eerst kijkt de browser in zijn eigen cache
- OS-cache: daarna het besturingssysteem (resolver-cache)
- Resolver: je stuurt de query naar een recursive resolver (meestal die van je ISP, of publiek zoals
1.1.1.1of8.8.8.8) - Root: de resolver vraagt een rootserver: "wie kent
.net?" - TLD: de rootserver wijst naar de
.net-TLD-nameservers - Authoritative: de
.net-nameserver wijst naar de nameservers vanwedecom.net - Antwoord: de authoritative nameserver geeft het A-record terug
- Cache: de resolver cachet het antwoord voor de duur van de TTL
De hele keten duurt meestal 20–100 milliseconden. Cache hits zijn vrijwel instant. Dit is ook waarom latency op DNS-niveau meetbaar is, een trage resolver voegt merkbaar tijd toe aan elke nieuwe verbinding.
De belangrijkste DNS-records op een rij
Als developer kom je deze record-types het vaakst tegen:
A en AAAA
- A-record: koppelt een domein aan een IPv4-adres (
93.184.216.34) - AAAA-record: hetzelfde, maar voor IPv6 (
2606:2800:220:1:248:1893:25c8:1946)
CNAME
Een CNAME (Canonical Name) verwijst naar een andere domeinnaam. Handig voor aliassen:
www.wedecom.net. CNAME wedecom.net.
Let op: een CNAME kan niet naast andere records op hetzelfde label bestaan. Daarom mag je geen CNAME op de apex (wedecom.net zelf) zetten, gebruik een A-record of een ALIAS/ANAME (provider-specifiek) als je een apex naar een CDN wil laten wijzen.
MX
MX-records bepalen welke mailserver e-mail voor je domein ontvangt. Lagere prioriteit = hogere voorkeur:
wedecom.net. MX 10 mail1.wedecom.net.
wedecom.net. MX 20 mail2.wedecom.net.
TXT
TXT-records bevatten vrije tekst. In de praktijk gebruikt voor:
- SPF: welke servers namens je domein mogen mailen
- DKIM: public keys voor e-mailhandtekeningen
- DMARC: beleid voor spoofed e-mail
- Domeinverificatie: Google Search Console, Microsoft 365, etc.
NS en SOA
- NS-records: welke nameservers verantwoordelijk zijn voor een zone
- SOA-record: metadata over de zone (primary nameserver, serial, refresh, retry, expire, minimum TTL)
PTR, SRV en CAA
Minder gebruikt maar goed om te kennen:
- PTR: reverse DNS (IP naar naam), belangrijk voor mailservers
- SRV: service discovery (XMPP, SIP, Minecraft)
- CAA: welke certificate authorities SSL mogen uitgeven voor je domein
TTL: de stille held van DNS-migraties
De TTL (Time To Live) bepaalt hoelang een resolver een antwoord mag cachen voordat hij opnieuw moet vragen. Waarden in seconden:
- 3600 (1 uur): veilige default
- 86400 (24 uur): stabiele, zelden wijzigende records
- 300 (5 minuten): voor migraties of failover
De migratie-workflow
Ga je migreren naar een nieuwe server? Hanteer dit patroon:
- 48 uur vooraf: verlaag TTL naar 300 seconden
- Wacht tot de oude hoge TTL verlopen is, resolvers cachen nu kort
- Cutover: wijzig het A-record naar de nieuwe server
- Monitor: binnen 5–10 minuten migreert verkeer
- 24 uur later: als alles stabiel is, zet TTL terug naar 3600+
Deze aanpak past goed bij een blue-green deployment en minimaliseert downtime. Maak altijd backups voor je begint, DNS-wijzigingen zelf zijn omkeerbaar, maar data-issues zijn dat niet.
DNS-propagation: mythe en realiteit
"Wacht 24 tot 48 uur voor DNS-propagation" is een klassieker. In werkelijkheid wordt DNS niet "gepropageerd", elke resolver haalt simpelweg een nieuw antwoord op zodra zijn cache verloopt.
Wat je wel ziet:
- Resolvers met lange cache-TTL's serveren nog even oude waardes
- Sommige ISP's negeren TTL's en cachen langer dan voorgeschreven
- Publieke resolvers (
1.1.1.1,8.8.8.8) updaten meestal binnen minuten - Eindgebruikers merken de verandering pas zodra hun lokale DNS-cache leegloopt
Test met tools zoals dnschecker.org om wereldwijd te zien welke resolvers al geüpdatet zijn. Het is géén garantie dat álle eindgebruikers het zien, maar geeft een goed beeld.
Debuggen met dig en nslookup
Elke developer zou dig moeten kunnen lezen. De basis:
dig wedecom.net
dig wedecom.net A +short
dig wedecom.net MX
dig wedecom.net TXT
Dig doorgronden
dig +trace wedecom.net
Met +trace zie je de volledige resolutie: van rootservers tot authoritative antwoord. Onmisbaar bij het debuggen van delegatieproblemen.
dig @8.8.8.8 wedecom.net
dig @ns1.hostbit.nl wedecom.net
Door een specifieke resolver (@8.8.8.8) of authoritative nameserver te bevragen, check je of een wijziging al op de bron staat, of dat een specifieke resolver nog een oude waarde cachet.
Nslookup op Windows
Voor Windows-developers is nslookup de ingebouwde tegenhanger:
nslookup wedecom.net
nslookup -type=MX wedecom.net 8.8.8.8
Voor diepere diagnose raden we dig (via WSL of Git Bash) aan, de output is completer.
DNS en security: DNSSEC, DoH en DoT
DNS was oorspronkelijk onversleuteld en ongeauthenticeerd. Dat is een probleem: man-in-the-middle-aanvallen en DNS-spoofing zijn reëel.
DNSSEC (DNS Security Extensions) voegt cryptografische handtekeningen toe aan DNS-antwoorden. Resolvers valideren zo dat het antwoord écht van de authoritative nameserver komt. Je activeert DNSSEC bij je registrar of DNS-provider, vergeet niet de DS-records bij je TLD te publiceren.
DoH (DNS over HTTPS) en DoT (DNS over TLS) versleutelen het transport tussen client en resolver. Browsers (Firefox, Chrome) ondersteunen DoH out of the box. Dit beschermt gebruikers, maar als developer heeft het beperkte impact op je eigen configuratie, het is vooral een privacylaag.
Zie voor de officiële specificaties de IETF RFC's over DNS en de documentatie van ICANN over DNSSEC.
DNS in moderne hostingstacks
Moderne hostingproviders bieden DNS-features die je als developer slim kunt inzetten:
- GeoDNS: verschillende antwoorden per regio, handig in combinatie met load balancing
- Health checks & failover: automatisch verkeer wegleiden bij downtime, aanvullend op wat je leest in uptime en SLA's uitgelegd
- ALIAS/ANAME-records: CNAME-gedrag op de apex, ondersteund door providers als Cloudflare en Route 53
- Anycast-nameservers: queries worden beantwoord door de dichtstbijzijnde locatie, wat latency drukt
Kijk bij het kiezen van een provider ook naar DNS-kwaliteit, het is een vaak vergeten criterium in hoe je de juiste hosting provider kiest.
Veelgemaakte fouten en hoe je ze voorkomt
Een paar valkuilen die we in de praktijk vaak zien:
- CNAME op de apex: gebruik een A-record of ALIAS/ANAME
- Dubbele MX-records zonder prioriteitsverschil: maakt mailrouting onvoorspelbaar
- SPF-record met meer dan 10 DNS-lookups: leidt tot
PermErroren bouncende mails - Vergeten AAAA-records: je site werkt niet voor IPv6-only clients
- TTL niet verlagen voor migratie: downtime van uren in plaats van minuten
- DNSSEC activeren zonder DS-records te publiceren: breekt resolutie volledig
- Oude nameservers niet verwijderen na provider-wissel: stale records blijven serveren
Bij alle pijn die dit kan veroorzaken geldt: monitor actief. Een simpele uptime-check op DNS-niveau scheelt uren aan paniek.
Conclusie
DNS is geen mystieke zwarte doos, het is een gelaagd, cacheerbaar, voorspelbaar systeem zodra je de hiërarchie en records begrijpt. Als developer hoef je geen nameserver-beheerder te zijn, maar je moet wel weten hoe een query loopt, welke records je nodig hebt, en hoe je met TTL's een migratie soepel laat verlopen.
Oefen met dig, experimenteer op een testdomein, en maak er een gewoonte van om vóór elke deploy je DNS-config door te lopen. Het is één van de goedkoopste investeringen in betrouwbaarheid die je kunt doen.
Veelgestelde vragen
Wat is DNS in simpele woorden?
DNS (Domain Name System) is het telefoonboek van het internet. Het vertaalt leesbare domeinnamen zoals wedecom.net naar IP-adressen die computers nodig hebben om met elkaar te communiceren.
Hoelang duurt DNS-propagation?
DNS-wijzigingen zijn meestal binnen enkele minuten tot een paar uur wereldwijd zichtbaar, afhankelijk van de TTL-waarde. In het slechtste geval kan het tot 48 uur duren voordat oude caches zijn vernieuwd.
Wat is het verschil tussen een A-record en een CNAME?
Een A-record wijst een domein naar een IPv4-adres. Een CNAME verwijst naar een andere domeinnaam, die vervolgens wordt opgelost. Gebruik A voor directe koppelingen en CNAME voor aliassen.
Waarom gebruik je een lage TTL voor migraties?
Een lage TTL (bijvoorbeeld 300 seconden) zorgt dat resolvers je DNS-records sneller opnieuw ophalen. Zet hem laag voor de migratie, zodat je na de cutover snel kunt terugvallen als er iets misgaat.
Wat doet een DNS-resolver precies?
Een resolver is de tussenpersoon die DNS-queries namens jouw apparaat uitvoert. Hij vraagt achtereenvolgens root-, TLD- en authoritative nameservers tot hij het juiste IP-adres vindt en cachet het antwoord.