De onzichtbare magie van DNS: Hoe je browser de weg vindt

Stel je voor: je typt een domeinnaam in en binnen een oogwenk ben je op de site. Achter de schermen vertaalt je browser die naam naar een IP-adres, zoekt de juiste server en maakt verbinding. Dat wonder heet DNS, het Domain Name System. Simpel, maar geniaal – en slimmer dan veel developers denken.

DNS ontstond in 1983, toen het internet nog draaide op trage modems. Paul Mockapetris bouwde een systeem dat snel, schaalbaar en robuust is, zelfs op een netwerk vol haperingen. Veertig jaar later werkt het nog steeds vlekkeloos. Dit zijn de redenen.

Snelheid door slim protocol: UDP boven TCP

Het grootste trucje? DNS kiest standaard voor UDP, niet TCP.

TCP begint met een driedelige handshake: heen en terug voordat je iets kunt vragen. Bij elke DNS-opslag zou dat een ramp zijn – per pagina laadt je browser tientallen domeinen. Resultaat: pure traagheid.

UDP doet het anders. Je stuurt één pakketje naar poort 53 met je vraag. De server kaatst direct één antwoord terug. Klaar. Geen poespas.

Minpunt: UDP-pakketten raken soms zoek. DNS lost dat op door simpelweg opnieuw te vragen als er geen reactie komt. Meer dan 99% van de queries past in één klein 512-byte pakket, dus verlies is zeldzaam.

Voor grote antwoorden, zoals met DNSSEC, schakelt het over op TCP. De server zet een 'TC'-bit en je client haalt het volledige antwoord op. Snel als standaard, betrouwbaar waar nodig.

De boomstructuur: Delegatie van boven naar beneden

DNS schaalt omdat er geen centrale database is met alle domeinen ter wereld.

Het werkt als een omgekeerde boom, gelezen van rechts naar links. Bij www.example.com. begin je bij de root (die onzichtbare punt achteraan) en werk je omlaag:

Root servers vormen de start. Er zijn dertien logische roots (A tot M), maar door Anycast staan ze duizenden keren verspreid over de aarde. Ze kennen jouw domein niet, maar wel wie .com, .org of .nl beheert.

TLD-servers (Top-Level Domains) runnen registries zoals Verisign voor .com. Vraag naar example.com en ze wijzen de nameservers aan.

Authoritative nameservers zitten onderaan, bij je registrar of provider als Cloudflare of NameOcean. Zij hebben de zone file met A-, AAAA-, CNAME- en MX-records. Hun antwoord draagt de aa-bit: 'Dit is het officiële woord.'

Probleem: als ns1.example.com de nameserver is, hoe vind je die IP eerst? TLD's fixen dat met glue records: ze geven de IP meteen mee. Zonder dat stort alles in.

Caching: De echte krachtpatser

Zonder caching zou DNS bezwijken. Elke lookup door de hele boom lopen? Onmogelijk.

Overal wordt gecachet, met een TTL (Time-to-Live) in seconden: 'Dit klopt X seconden, wacht daarna.'

• In je browser: Chrome heeft een eigen cache, check chrome://net-internals/#dns.
• Op je OS: Linux met systemd-resolved, macOS met mDNSResponder, Windows met DNS Client.
• Bij de resolver: 8.8.8.8 van Google of 1.1.1.1 van Cloudflare deelt caches over miljoenen users.

Bij migraties is TTL cruciaal. Verlaag hem dagen vooruit van 24 uur naar 5 minuten. Anders blijven oude IP's hangen en mis je traffic.

Anycast: De illusie van nabijheid

Hoe haalt 8.8.8.8 queries uit Tokyo én Londen in 2 ms? Anycast routing.

Normaal wijst één IP naar één server. Anycast laat honderden servers wereldwijd hetzelfde IP claimen via BGP. Je router stuurt naar de dichtstbijzijnde.

Daarom blinkt Cloudflare uit in lage latency. En DDoS-aanvallen? Die spreiden zich vanzelf uit over alle locaties.

Alles in balans

DNS is een parel van distributed design. UDP voor snelheid, hiërarchische delegatie voor schaal, caching overal voor robuustheid, Anycast voor bereikbaarheid.

Bedacht in 1983 voor een pril internet, en nu miljarden lookups per dag. Timeless.

Bij NameOcean of grootschalig DNS-management verandert dit inzicht je aanpak voor domeinen, migraties en optimalisatie. DNS is geen bijzaak – het is de aderslag van het web.