Het volledige DNS-resolutieproces — hoeveel stappen van browser tot rootserver?

1. Het volledige proces in 8 stappen

┌──────────────────────────────────────────────────────────────┐
│  Browser (Chrome / Firefox) — typ google.com                 │
└────────────────┬─────────────────────────────────────────────┘
                 │ ① DNS-cache van de browser (Chrome ~60s)
                 ↓ miss
┌──────────────────────────────────────────────────────────────┐
│  Stub-resolver van het OS + DNS-cache van het systeem        │
└────────────────┬─────────────────────────────────────────────┘
                 │ ② Systeemcache miss → UDP-query naar de router
                 ↓
┌──────────────────────────────────────────────────────────────┐
│  DNS-doorsturing van de thuisrouter + routercache            │
└────────────────┬─────────────────────────────────────────────┘
                 │ ③ Routercache miss → door naar de recursieve resolver van de provider
                 ↓
┌──────────────────────────────────────────────────────────────┐
│  Recursieve resolver van provider of publieke DNS            │
│  (1.1.1.1 / 8.8.8.8 / 223.5.5.5)                             │
│  Cache-treffer: direct antwoord, het hele proces duurt 1-5ms │
│  Cache miss: verder met de “volledige opzoeking” hieronder   │
└────────────────┬─────────────────────────────────────────────┘
                 │ ④ Vraagt de root-NS: “waar is google.com?”
                 ↓
        13 clusters rootnameservers (a~m.root-servers.net)
                 │ ⑤ Antwoord: “Weet ik niet, vraag de NS van .com: a.gtld-servers.net”
                 ↓
        Gezaghebbende TLD-servers van .com (Verisign)
                 │ ⑥ Antwoord: “Ik heb ook niet alles, vraag de NS van google.com: ns1.google.com”
                 ↓
        Gezaghebbende servers van google.com (beheerd door Google zelf)
                 │ ⑦ Antwoord: “A-record van google.com = 142.250.x.x”
                 ↓
┌──────────────────────────────────────────────────────────────┐
│  ⑧ De recursieve resolver cachet het antwoord (volgens TTL)  │
│     en stuurt het naar de client — elke laag onderweg        │
│     bewaart ook een eigen kopie                              │
└──────────────────────────────────────────────────────────────┘

Belangrijk inzicht: in de praktijk wordt het volledige proces van 8 stappen bijna nooit doorlopen. De IP-adressen van grote sites staan vrijwel altijd al in de cache van de recursieve resolver, dus gewone gebruikers krijgen al bij stap ④ antwoord. Alleen obscure domeinen, zelden bezochte sites, verlopen TTL's of nieuw geregistreerde domeinen doorlopen het volledige proces.

2. De 5 lagen van DNS-caching uitgelegd

Toen DNS in 1983 werd ontworpen, hield men al rekening met één feit: er zijn 100.000 keer meer opzoekingen dan wijzigingen. Daarom wordt er overal gecachet, en elke laag bewaart gegevens gedurende een TTL-periode (Time To Live).

3. Recursieve vs. iteratieve query's — kernbegrippen

3.1 Recursief

De client (browser / stub van het OS) zegt tegen de recursieve resolver van de provider: “Zoek het IP-adres van google.com voor me op — hoe je dat doet, maakt me niet uit.” De recursieve resolver moet de hele opzoeking afronden en het eindresultaat teruggeven.

3.2 Iteratief

Als de recursieve resolver met de root-, TLD- en gezaghebbende servers praat, verloopt dat iteratief — hij vraagt het aan de root, de root zegt “vraag het aan .com”, hij vraagt het aan .com, .com zegt “vraag het aan google”, en hij vraagt het aan google. Elke stap gaat maar één niveau verder — het is niet zo dat “ik het aan de root vraag en de root alles voor me regelt”.

4. Test het zelf — dig +trace

dig +trace dwingt een volledige iteratieve opzoeking af en toont elke stap:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Hop 1 — vraag aan de root (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 NS-records van de root)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Hop 2 — vraag aan het TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (de 4 NS-records van .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Hop 3 — vraag aan de gezaghebbende servers van cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Eindelijk het antwoord
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Toelichting:

• Het hele proces duurde 5 + 121 + 53 + 12 = 191 ms — de eerste koude opzoeking is echt traag
• Maar dezelfde domeinnaam een seconde later opnieuw opvragen kost maar 1-2 ms, omdat de recursieve cache van de provider hem al heeft (TTL 300 seconden)
• 104.21.x.x / 172.67.x.x zijn CDN-adressen van Cloudflare — het echte origin-IP van onze site zit verborgen achter de CDN

5. TTL uitgelegd — hoe lang blijft iets echt in de cache?

TTL (Time To Live) is het veld waarmee de gezaghebbende server elke recursieve resolver vertelt “je mag dit maximaal zo lang cachen”, in seconden.

Let op: TTL is de “maximale cachetijd” — resolvers mogen hun cache eerder wissen, maar nooit langer bewaren. Dus ook als de gezaghebbende TTL 1 uur is, kunnen sommige resolvers al na 10 minuten opnieuw opvragen.

Valkuil: verkort vóór het wisselen van IP-adres eerst de TTL (1-5 minuten) en wacht tot de oude TTL volledig is verlopen voordat je overschakelt — anders blijven sommige gebruikers nog meer dan een uur bij het oude IP-adres uitkomen.

6. Overzicht van DNS-recordtypen

7. DNS-optimalisatie — zo wordt resolutie sneller

7.1 Kies een recursieve resolver dichtbij

Op het Chinese vasteland: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) resolven sites in China het snelst. Elders: 1.1.1.1 (Cloudflare, de breedste anycast-dekking) / 8.8.8.8 (Google). Zie hetoverzicht van publieke DNS-resolvers.

7.2 Schakel DoH in (DNS-over-HTTPS)

Door DNS-query's via HTTPS te versleutelen kunnen providers ze niet inzien of manipuleren (dat houdt ook NXDOMAIN-kaping tegen). Chrome, Firefox en Edge ondersteunen het allemaal — schakel het gewoon in bij de instellingen.

7.3 Vooraf opwarmen (DNS-prefetch)

Voeg <link rel="dns-prefetch" href="//api.example.com"> toe aan de <head> van je site, zodat de browser de naam al resolvet als hij niets te doen heeft — tegen de tijd dat het echte verzoek komt, staat het antwoord in de cache.

7.4 Gebruik een CDN + anycast-NS

Zet je gezaghebbende NS op anycast (Cloudflare / Route 53), zodat gebruikers wereldwijd de dichtstbijzijnde instantie bereiken — dat verlaagt de latentie van stap ③ van 100ms naar 10ms.

7.5 Stel de TTL verstandig in

Geef records die zelden veranderen (NS / MX) een lange TTL (1-7 dagen); geef A-records die misschien moeten wisselen een korte TTL (5-60 minuten).

8. Veelgestelde vragen

8.1 Ik heb mijn DNS gewijzigd, maar er verandert niets — waarom?

Kijk eerst naar de huidige TTL. Na een DNS-wijziging blijft elke recursieve resolver het oude IP-adres teruggeven tot de oude TTL verloopt. “Wereldwijde propagatie” duurt doorgaans ongeveer 2× de TTL (omdat resolvers onderling niet synchroon lopen).

• Op de client: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Wachten tot de cache van een publieke recursieve resolver verloopt: 1.1.1.1 / 8.8.8.8 bieden elk een eigen “purge”-tool om die handmatig te wissen

8.2 Sommige gebruikers kunnen de site bereiken, andere niet — DNS-vervuiling

Komt vaak voor bij het bezoeken van buitenlandse sites vanaf het Chinese vasteland — de GFW injecteert valse DNS-antwoorden / providers plegen DNS-kaping. Wie overstapt op DoH (versleutelde DNS in de browser), omzeilt de meeste DNS-vervuiling.

8.3 Hoe snel kan ik een domein na registratie gebruiken?

Na registratie zet het TLD-register je NS-records door naar de gezaghebbende topniveauservers van .com / .net enzovoort — meestal binnen 15 minuten tot 24 uur. Voor .cn- / .com.cn-domeinen kan een ICP-registratie nodig zijn voordat ze op het Chinese vasteland resolven.