Hoe werkt DNS-resolutie? De route van root naar authoritative nameserver uitgelegd

DNS-resolutie is het proces waarbij een domeinnaam als example.com wordt omgezet in een IP-adres waarmee een computer verbinding kan maken. Dat gebeurt door een keten van servers af te lopen: je recursieve resolver, de root, de TLD en ten slotte de authoritative nameserver van het domein, totdat een van hen het daadwerkelijke record teruggeeft. Wie die keten begrijpt, kan het snelst achterhalen waarom een site "niet resolvet" of naar het verkeerde adres resolvet.

Recursieve resolver vs authoritative nameserver

Deze twee rollen worden voortdurend door elkaar gehaald, maar bij troubleshooting is het onderscheid belangrijk.

• Recursieve resolver: de server waarmee je apparaat daadwerkelijk communiceert (de resolver van je provider, of een publieke zoals 8.8.8.8 van Google of 1.1.1.1 van Cloudflare). Hij zoekt namens jou het antwoord op en slaat het resultaat op in de cache.
• Authoritative nameserver: de server die de daadwerkelijke DNS-records van een zone bevat (bijvoorbeeld de A-, MX- en TXT-records van je domein). Dit is de bron van waarheid; hij vraagt het nooit aan iemand anders.

Je laptop of telefoon draait een lichtgewicht stub resolver die dit zoekwerk zelf niet uitvoert: hij stuurt de vraag alleen door naar een recursieve resolver en wacht op het antwoord.

De route root → TLD → authoritative

Als een recursieve resolver niets in de cache heeft voor een naam, voert hij een iteratieve lookup uit en volgt hij verwijzingen omlaag door de DNS-hiërarchie:

1. Rootservers. De resolver vraagt het aan een van de 13 rootserver-identifiers (a.root-servers.net tot en met m.root-servers.net, elk via anycast verspreid over vele fysieke locaties). De root weet niet waar example.com staat, maar wel welke servers .com afhandelen, en geeft die verwijzing terug.
2. TLD-servers. De resolver vraagt het aan een .com-TLD-server. Die kent het IP-adres van example.com ook niet, maar weet wel welke nameservers authoritative zijn voor dat domein, en verwijst de resolver daarheen.
3. Authoritative servers. De resolver vraagt het rechtstreeks aan de authoritative nameserver van example.com. Deze server bevat het daadwerkelijke record en geeft het terug: geen gegok meer.

De recursieve resolver geeft dat antwoord vervolgens terug aan je apparaat en slaat het op in de cache voor de volgende keer, zolang de TTL (time to live) van het record dat toestaat.

Note"Iteratief" (van server naar server, waarbij elke server naar de volgende verwijst) en "recursief" (de client vraagt één server al het werk te doen) beschrijven hetzelfde totale proces vanuit twee verschillende gezichtspunten: je resolver doet namens jou recursief werk door een reeks iteratieve queries uit te voeren.

Waarom caching en TTL belangrijk zijn

Elk DNS-record heeft een TTL, een waarde in seconden die resolvers vertelt hoe lang ze het record mogen cachen voordat ze het opnieuw opvragen. Een lage TTL (bijvoorbeeld 300 seconden) betekent dat wijzigingen snel doorkomen, maar je genereert meer lookupverkeer; een hoge TTL (bijvoorbeeld 86400 seconden / 24 uur) vermindert de belasting, maar betekent dat een verouderd record na een wijziging nog een hele dag in caches kan blijven hangen.

Dit is ook waarom een mislukte migratie "gedeeltelijk" lijkt te werken: sommige resolvers hebben nog het oude antwoord in de cache, terwijl andere het nieuwe al hebben opgepikt. Zit je midden in een migratie of debug je de propagatie, vraag dan verschillende resolvers rechtstreeks op en vergelijk de antwoorden, in plaats van te vertrouwen op de cache van je browser.

Zelfs antwoorden dat "er geen record bestaat" worden gecachet. Dit heet negative caching en wordt bepaald door de TTL in het SOA-record van de zone, waardoor ook een NXDOMAIN een tijdje kan blijven bestaan.

Wat een DNS-query precies bevat

DNS-berichten hebben een vaste structuur: een header plus de secties Question, Answer, Authority en Additional. Standaardqueries lopen via UDP-poort 53, oorspronkelijk beperkt tot 512 bytes; moderne resolvers gebruiken EDNS0 om grotere buffergroottes aan te geven en onnodige fallbacks te voorkomen. Als een antwoord te groot is, of bij bewerkingen zoals zoneoverdrachten, valt DNS terug op TCP-poort 53.

Een typische dig-uitvoer voor een geresolved A-record ziet er zo uit:

;; ANSWER SECTION:
example.com.		300	IN	A	93.184.216.34

Die 300 is de TTL in seconden, IN is de klasse (internet) en A is het recordtype. Je kunt dezelfde lookup zelf uitvoeren vanuit elke browser met de DNS lookup-tool, handig om precies te controleren wat een authoritative server op dit moment serveert, los van je lokale cache.

Versleutelde DNS: DoH en DoT

Standaard DNS-queries worden in platte tekst verstuurd, waardoor netwerken (en iedereen onderweg) kunnen zien welke domeinen je opvraagt. Twee nieuwere transportmethoden pakken dit aan:

• DNS over TLS (DoT): DNS verpakt in TLS op TCP-poort 853.
• DNS over HTTPS (DoH): DNS getunneld binnen een HTTPS-verbinding, meestal op poort 443, waardoor het moeilijker te onderscheiden is van gewoon webverkeer.

Beide beschermen de query onderweg tussen je apparaat en de resolver, maar ze veranderen niets aan de onderliggende route root→TLD→authoritative die hierboven is beschreven: de versleuteling vindt plaats op de transportlaag, niet in de resolutielogica.

DNSSEC: authenticiteit zonder versleuteling

DNS Security Extensions (DNSSEC) voegen cryptografische handtekeningen toe (RRSIG-, DNSKEY- en DS-records), zodat een resolver kan verifiëren dat een antwoord echt afkomstig is van de authoritative bron van de zone en onderweg niet is gemanipuleerd. Het is goed om te benadrukken dat DNSSEC authenticiteit biedt, geen vertrouwelijkheid: iedereen kan de query nog steeds zien; DNSSEC voorkomt alleen dat iemand een vals antwoord vervalst.

Veelvoorkomende DNS-problemen en hun oorzaken

Als je DNS beheert bij meerdere registrars en providers, vermenigvuldigen deze symptomen zich: een delegatie die bij de ene registrar klopt maar bij de andere verouderd is, is een klassieke bron van supporttickets in de trant van "bij mij werkt het wel".

Wil je het DNS-beheer voor meerdere domeinen centraliseren, zodat je niet langer propagatieproblemen najaagt in een tiental dashboards? Met de DNS-functie van InfraNest beheer je zones, TTL's en records voor elke provider op één plek.

Probeer het zelf

Voer een live lookup uit tegen authoritative servers met de DNS lookup-tool om precies te zien wat er op dit moment wordt geserveerd, ongeacht wat je lokale resolver in de cache heeft.