Module 1 · 1.4
De reis van een DNS-vraag
Module 1: Wat is DNS? · Leestijd: 8 minuten
Leerdoel: Na deze les kun je stap voor stap uitleggen hoe een resolver een antwoord vindt, en waar onderweg antwoorden worden onthouden.
Kernbegrippen: resolver (recursief), rootserver, TLD-server, gezaghebbende (authoritative) nameserver, verwijzing (delegatie), cache
Twee soorten DNS-servers
In les 1.1 zag je dat DNS verdeeld is: niemand weet alles. Hoe komt jouw browser dan toch aan het adres van www.example.com? Daarvoor werken twee soorten servers samen:
- Gezaghebbende nameservers (in het Engels authoritative) weten het antwoord voor hun eigen stukje. De nameservers van
example.comweten de records vanexample.com. Ze zoeken niets voor anderen op. - Resolvers (ook wel recursieve resolvers) zoeken het antwoord voor jou op. Ze vragen het net zo lang na tot ze het hebben. Je internetprovider heeft een resolver, en er zijn openbare resolvers zoals die van Quad9, Cloudflare of Google.
Je computer zelf zoekt bijna niets op. Hij heeft een kleine stub resolver die de vraag doorgeeft aan de resolver van je netwerk en het antwoord terugkrijgt.
De reis, stap voor stap
Stel: de resolver heeft nog niets onthouden en jij vraagt om het A-record van www.example.com.
- Je computer vraagt de resolver: "Wat is het A-record van www.example.com?"
- De resolver vraagt een rootserver. Elke resolver heeft een lijstje met de adressen van de rootservers ingebouwd. De rootserver weet niets van
example.com, maar wel wie.nlbeheert. Hij antwoordt met een verwijzing: "Daarvoor moet je bij de nameservers van nl zijn: ns1.dns.nl, ns3.dns.nl, ns4.dns.nl." - De resolver vraagt een nameserver van .nl. Die weet ook niet het IP-adres van
www.example.com, maar wel welke nameserversexample.comheeft. Weer een verwijzing: "Vraag het aan ns1.hosting.example of ns2.hosting.example." - De resolver vraagt een nameserver van example.com. Die is gezaghebbend voor dit domein en geeft het antwoord: "www.example.com heeft A-record 192.0.2.10."
- De resolver geeft het antwoord aan je computer. Je browser maakt verbinding met 192.0.2.10.
Een verwijzing van een hoger niveau naar de nameservers van een lager niveau heet een delegatie. De root delegeert .nl aan SIDN, .nl delegeert example.com aan de nameservers die de houder heeft opgegeven. Daarom is het zo belangrijk dat de nameservers bij de registry kloppen (les 2.1).
De cache: niet elke keer de hele reis
Als elke resolver bij elke vraag weer bij de root zou beginnen, kreeg de root een onvoorstelbare hoeveelheid vragen. Dat gebeurt niet, want de resolver onthoudt de antwoorden een tijdje. Dat geheugen heet de cache.
Hoe lang een antwoord onthouden mag worden, staat in het antwoord zelf: de TTL (time to live), in seconden. Een TTL van 3600 betekent: dit antwoord mag een uur worden onthouden. Ook de verwijzingen worden onthouden. Een resolver die net heeft gehoord welke nameservers .nl heeft, hoeft dat de volgende keer niet opnieuw aan de root te vragen.
Vraagt iemand anders bij dezelfde provider een minuut later naar www.example.com, dan antwoordt de resolver meteen uit zijn cache. Geen reis, geen wachttijd.
Caches zitten op meer plekken:
- in de resolver van je provider of de openbare resolver die je gebruikt;
- in je besturingssysteem (Windows, macOS, je telefoon);
- in je browser;
- soms in je router.
Dat is snel en efficiënt, maar het heeft een gevolg dat je later vaak tegenkomt: wijzig je een record, dan blijven caches het oude antwoord geven tot hun TTL voorbij is. Daarom ziet de een een wijziging al en de ander nog niet. Module 6 gaat daar uitgebreid over.
De rootservers
Er zijn 13 namen voor de rootservers: a.root-servers.net tot en met m.root-servers.net. Ze worden beheerd door twaalf verschillende organisaties. Achter elke naam staan wereldwijd veel servers, op honderden plekken, die hetzelfde adres delen (dat heet anycast). Je resolver komt automatisch bij een dichtbije terecht. Ook de TLD-nameservers, zoals die van .nl, werken zo. Daardoor is DNS snel en blijft het werken als er ergens een server uitvalt.
Waar het mis kan gaan
Als je de reis kent, kun je problemen beter plaatsen:
- De delegatie klopt niet. Bij de registry staan nameservers die het domein niet (meer) kennen. De resolver komt bij stap 4 dan niet verder. Het antwoord is een fout of er komt helemaal geen antwoord.
- De gezaghebbende server heeft een ander antwoord dan je verwacht. Je hebt het record dan op een andere plek gewijzigd dan waar de nameservers staan (les 2.1).
- De cache heeft nog het oude antwoord. Dan is er niets kapot. Je moet wachten tot de TTL voorbij is, of je eigen cache legen.
- DNSSEC klopt niet. Een validerende resolver controleert onderweg handtekeningen. Klopt de keten niet, dan weigert hij het antwoord (les 8.1).
Met het hulpmiddel dig +trace kun je de reis zelf nadoen, vanaf de root tot de gezaghebbende server. Dat leer je in les 8.2. Online tools kunnen het ook.
Samenvatting
- Gezaghebbende nameservers weten het antwoord voor hun eigen domein; resolvers zoeken het antwoord voor jou op.
- Een resolver begint bij de root, krijgt een verwijzing naar de TLD, dan naar de nameservers van het domein, en krijgt daar het antwoord.
- Zo'n verwijzing heet een delegatie.
- Antwoorden worden onthouden in caches, zo lang als de TTL zegt; daardoor zijn wijzigingen niet overal meteen zichtbaar.
- Er zijn 13 rootservernamen, maar dankzij anycast staan er wereldwijd veel servers achter.
Quiz
Opdracht
Z1.4 Doe de reis na. Volg de reis voor www.sidn.nl, met dig +trace www.sidn.nl of een online tool die een trace laat zien. Vul in: (1) één nameserver van nl. die je onderweg tegenkomt, (2) één gezaghebbende nameserver van sidn.nl.4.
Verder lezen
Deze artikelen beschrijven de situatie bij WebOké. Bij andere aanbieders werkt het vergelijkbaar.