Hoe DNS in 80 milliseconden een naam vindt
Je typt wallieweb.nl in de adresbalk en een fractie van een seconde later staat de pagina er. Voordat er ook maar één byte HTML over de lijn gaat, moet je laptop eerst iets anders uitzoeken: op welk IP-adres woont die naam eigenlijk? Dat opzoekwerk heet DNS. Het gebeurt bij bijna elke nieuwe verbinding en je merkt er pas iets van als het stukgaat.
Hieronder volg je één echte opvraging, stap voor stap. De tijden zijn gemeten met dig +trace wallieweb.nl vanaf een gewone Nederlandse verbinding.
A? wallieweb.nl
De vraag
Je browser heeft een naam en wil een adres. In DNS-termen: een A-record voor wallieweb.nl (of een AAAA-record voor IPv6). Tot dat antwoord binnen is, kan er geen TCP-verbinding worden opgezet en dus ook geen TLS-handshake of HTTP-request volgen.
Eerst kijken wat je al weet
Voordat er iets het netwerk op gaat, kijkt de browser in zijn eigen cache en daarna het besturingssysteem in de zijne. Heb je de site kort geleden bezocht, dan eindigt het verhaal hier en kost het nul milliseconden. In ons voorbeeld is dat niet zo: twee keer een miss.
Naar de recursive resolver
Je laptop is zelf maar een stub resolver: hij zoekt niets zelf uit, maar stuurt de vraag door naar een recursive resolver. Meestal is dat een server van je provider, of een publieke dienst als 1.1.1.1 (Cloudflare), 8.8.8.8 (Google) of 9.9.9.9 (Quad9). De vraag gaat als één klein UDP-pakketje naar poort 53, met de vlag RD (recursion desired): zoek jij het maar uit.
Die resolver doet het zware werk. Heeft hij het antwoord niet in zijn cache, dan begint hij bovenaan de boom.
De root: "Ik weet het niet, maar vraag het aan .nl"
Bovenaan de DNS-boom staan de rootservers. Er zijn er dertien, a.root-servers.net tot en met m.root-servers.net, beheerd door twaalf organisaties. Via anycast draaien er achter die dertien namen wereldwijd ruim 2.000 servers, dus er staat er vrijwel altijd één dichtbij.
De root kent wallieweb.nl niet. Hij geeft een referral terug: dit zijn de nameservers van .nl. Let op de TTL: 172800 seconden, twee dagen. Een drukke resolver heeft dit antwoord bijna altijd al in zijn cache en slaat deze stap in de praktijk meestal over.
.nl: "Vraag het aan thednscompany"
De .nl-zone wordt beheerd door SIDN in Arnhem. Hun nameservers weten niet welk IP-adres bij wallieweb.nl hoort, maar wel wie daarover gaat: ze delegeren naar de nameservers die de eigenaar bij zijn registrar heeft opgegeven. Weer een referral, nu met een TTL van een uur.
Zo werkt de hele boom. Elke laag weet alleen wie de volgende laag beheert. Daardoor schaalt DNS naar honderden miljoenen domeinen zonder dat iemand de hele lijst hoeft te kennen.
De autoritatieve server geeft het echte antwoord
De derde vraag gaat naar ns1.thednscompany.com, en die is autoritatief voor wallieweb.nl: hij verwijst niet door, hij weet het. Het antwoord is 52.236.137.214, met een TTL van 120 seconden.
Er komt ook een RRSIG-record mee. Dat is een DNSSEC-handtekening. Een validerende resolver kan daarmee controleren dat het antwoord onderweg niet is vervalst, via een keten van handtekeningen die terugloopt tot de root.
Terug naar je laptop
De resolver stuurt het antwoord terug en bewaart het in zijn cache. Opgeteld kostte de koude opvraging hier zo'n 80 milliseconden: 21 ms tussen laptop en resolver en daarna drie rondes van 15 tot 23 ms. Nu pas kan de browser een verbinding openen met 52.236.137.214 op poort 443.
De tweede keer
Vraagt iemand anders bij dezelfde resolver binnen twee minuten naar wallieweb.nl, dan komt het antwoord direct uit de cache. Alleen de rit tussen laptop en resolver blijft over. Wissel hierboven tussen koud en warm om het verschil te zien.
Dat is de afweging achter elke TTL. Een lange TTL maakt je site sneller en je nameservers rustiger. Een korte TTL laat je sneller verhuizen: verander je het IP-adres, dan zie je bij 120 seconden binnen twee minuten het nieuwe adres. Bij een TTL van een dag duurt dat voor sommige bezoekers tot een dag.
Wat niet in het plaatje past
UDP, en soms TCP
DNS gebruikt standaard UDP omdat vraag en antwoord meestal in één pakketje passen. Wordt een antwoord te groot, bijvoorbeeld door DNSSEC-handtekeningen, dan zet de server de vlag TC (truncated) aan en vraagt de resolver het opnieuw via TCP.
Versleutelde DNS
Klassieke DNS gaat onversleuteld over de lijn: iedereen tussen jou en je resolver kan zien welke namen je opvraagt. DNS-over-HTTPS (poort 443) en DNS-over-TLS (poort 853) versleutelen dat eerste stuk tussen laptop en resolver. De rondes die de resolver daarna maakt naar root, .nl en autoritatieve servers gaan meestal nog gewoon onversleuteld.
DNSSEC is geen privacy
DNSSEC bewijst dat een antwoord echt is, maar verbergt niets. Wie meekijkt, ziet nog steeds welke naam je opvraagt. Daarvoor heb je DoH of DoT nodig.
Zelf proberen
Op macOS en Linux zit dig er meestal al in:
dig +trace wallieweb.nl
Je ziet dan precies wat hierboven gebeurde, met je eigen tijden. Draai daarna dig wallieweb.nl twee keer achter elkaar en let op de TTL in het tweede antwoord: die is lager, omdat je resolver aan het aftellen is.
Tot slot
Wat me het meest bijblijft: de hele keten is in tachtig milliseconden klaar, maar hij is zo sterk als de zwakste schakel. Zit er een typefout in een NS-record of verloopt een DNSSEC-handtekening, dan is je site voor de hele wereld onbereikbaar terwijl de server gewoon draait. "It's always DNS" is niet voor niets een grap onder systeembeheerders.