DNS-resolutie, van begin tot eind

Elke keer dat je een domeinnaam in een browser intypt, begint een reeks zoekopdrachten voordat een enkel pakket de site bereikt die je wilt bezoeken. Het meeste van die reeks is onzichtbaar, en de meeste uitleg erover eindigt met "het is als een telefoongids." Dit is wat er daadwerkelijk gebeurt, stap voor stap, inclusief de delen die mensen meestal overslaan.

De stub resolver is niet slim

Je besturingssysteem voert niet zelf echte DNS-resolutie uit. Het draait een stub resolver, een klein stukje code dat je query gewoon doorgeeft aan welke DNS-server ook geconfigureerd is in /etc/resolv.conf op Linux of in je netwerkaداpta instellingen op Windows. Controleer de jouwe met:

cat /etc/resolv.conf

Dat bestand wijst meestal naar je router (zoals 192.168.1.1), de resolver van je ISP, of een openbare zoals 1.1.1.1 of 8.8.8.8. De stub resolver heeft geen eigen cache-logica behalve wat het OS of een lokale daemon zoals systemd-resolved biedt.

De recursieve resolver doet het echte werk

Zodra je query een recursieve resolver bereikt, neemt die server de taak op zich om het antwoord te vinden, zelfs als het meerdere andere servers moet vragen om daar te komen. Als het antwoord al in cache staat van een vorige zoekopdracht, krijg je het direct terug. Controleer de TTL met:

dig example.com

Kijk naar de ANSWER SECTION — het getal voor het recordtype (zoals 300 voor A) is de TTL in seconden. Dat is hoe lang resolvers het record mogen cachen voordat ze opnieuw vragen.

Als niets in cache staat, begint de recursieve resolver een wandeling door de DNS-hiërarchie van de root.

Root-, TLD- en autoritatieve servers

Er zijn 13 root-serveradressen (a.root-servers.net tot en met m.root-servers.net), elk ondersteund door veel fysieke machines via anycast-routing. De root-server weet niet waar example.com zich bevindt, maar het weet welke servers .com afhandelen, dus het geeft een verwijzing terug.

De resolver vraagt dan een .com TLD-server, die weer niet het uiteindelijke antwoord kent maar wel weet welke naamservers autoritatief zijn voor example.com specifiek. Je kunt deze delegatie zelf zien:

dig +trace example.com

Die opdracht toont elke hop: root, dan TLD, dan de autoritatieve naamservers voor het domein, eindigend met de werkelijke A- of AAAA-record. Het is de beste opdracht om DNS visueel in plaats van theoretisch te begrijpen.

De autoritatieve naamserver is de laatste stop. Het is de server die de domeineigenaar daadwerkelijk heeft geconfigureerd, vaak via het DNS-paneel van een registrar of een service zoals Route 53 of Cloudflare DNS. Dit is de enige server in de hele keten die het echte, canonieke antwoord heeft in plaats van een cachedkopie of een verwijzing.

Recordtypen waar je daadwerkelijk mee te maken hebt

Een A-record wijst een naam toe aan een IPv4-adres, AAAA doet hetzelfde voor IPv6. CNAME wijst één naam naar een andere naam in plaats van een IP, dat is hoe CDN's zoals Cloudflare of Fastly verkeer routeren zonder ruwe IP's bloot te stellen. MX-records regelen mailrouting, en TXT-records bevatten willekeurige tekst, tegenwoordig vooral gebruikt voor SPF, DKIM en domeinverificatiestrings. NS-records vertellen de wereld welke servers autoritatief zijn voor een zone, en dat is het recordtype dat delegatie überhaupt mogelijk maakt.

Waar caching echt plaatsvindt

Caching gebeurt tegelijkertijd op meerdere lagen: de browser zelf (Chrome heeft een eigen DNS-cache zichtbaar op chrome://net-internals/#dns), het OS resolver-cache, de lokale router, en de recursieve resolver erbovenop. Dit is waarom een DNS-wijziging op het ene apparaat direct lijkt te werken en op het andere uren duurt om op te duiken — je raakt niet dezelfde cache.

Wanneer je het TTL van een record verlaagt vóór een geplande migratie, versnelle je niet onmiddellijk iets. Je verkleint alleen het venster waarin verouderde gegevens kunnen blijven bestaan zodra de wijziging daadwerkelijk plaatsvindt. Doe dit minstens één TTL-cyclus van tevoren, niet vijf minuten voor de cutover.

Waarom dit uitmaakt voor probleemoplossing

Wanneer een site onbereikbaar is, vertelt dig +trace je exact welke laag kapot is: een root/TLD-probleem ziet er totaal anders uit dan een missconfigureerde autoritatieve server of een verouderde cache op je eigen machine. Het vergelijken van dig example.com met een bekend-werkende resolver, zoals dig example.com @1.1.1.1, isoleert of het probleem je lokale resolver is of de werkelijke DNS-setup van het domein.

DNS ziet er eenvoudig uit van buiten omdat het meestal in minder dan 100ms wordt opgelost en niemand erover nadenkt. Eronder is het een gedistribueerd, gecacht, hiërarchisch querysysteem dat sinds de jaren tachtig grotendeels ongewijzigd qua structuur draait, wat een vrij goed argument is voor hoe goed het oorspronkelijke design standhield.

Als je hier verder mee wilt gaan, heeft Korra Studio gerelateerde segmenten op DEFENSE_GRID over DNS-beveiligingsextensies, DNS-tunneling als exfiltratietechniek, en het bouwen van je eigen resolver helemaal opnieuw in Python.