Wat is DNS: Alles over het Domain Name System
Wanneer je surft, tik je doorgaans een webadres op basis van een (sub)domeinnaam in. Daarmee zet je wel een heel systeem in werking, want achterliggend wordt naar de gewenste webserver op basis van het ip-adres gezocht. Er is dus een vertaalslag nodig en daar zorgt het DNS-protocol voor. Wat is DNS?
Wat is DNS?
DNS (Domain Name System) is een client-serversysteem dat via het gelijknamige protocol een ip-adres dat bij een hostnaam hoort (of omgekeerd) opzoekt in een gedistribueerde en dynamische database.
De oorsprong van het internet ligt bij het Amerikaanse DARPAnet (Defense Advanced Research Projects Agency Network). Aanvankelijk was dit netwerk nog voldoende behapbaar om de koppeling tussen ip-adressen en hostnamen in een statisch tekstbestand (host.txt) te vatten en nieuwe adressen handmatig toe te voegen. Het team dat deze lijst onderhield, ontwikkelde trouwens ook het concept van (sub)domeinen en zette een whois-directory op om administratieve gegevens van een host te achterhalen.
De explosieve groei van het internet vanaf de jaren 80 maakte de behoefte aan een geautomatiseerd systeem steeds groter en dit leidde tot het ontstaan van DNS in 1983. De specificaties werden in 1987 vastgelegd in RFC’s 1034 en 1035, de verdienste van computerwetenschapper Paul Mockapetris (https://kwikr.nl/rfc1034 en https://kwikr.nl/rfc1035). RFC’s (Request for Comments) zijn documenten die de protocollen en andere aspecten van het internet beschrijven.
Inmiddels hebben bijkomende RFC’s voor allerlei uitbreidingen van het DNS-protocol gezorgd. Op https://kwikr.nl/dnstl vind je hiervan een overzicht.
Zoekmechanisme
Wat gebeurt er nu wanneer je bijvoorbeeld www.pcmweb.nl in je browser intikt of een e-mail verstuurt naar iets als mailbox@pcmweb.nl?
In eerste instantie vraagt je netwerkapplicatie aan de lokale resolver naar de hostgegevens. Deze software kijkt normaliter eerst in het lokale hosts-bestand (in /etc/hosts of in %systemroot%\System32\etc\hosts). Vindt die niks, dan wordt mogelijk nog een (caching of forwarding) resolver binnen je eventuele bedrijf geraadpleegd. Geen succes? Dan gaat je DNS-verzoek naar een recursive resolver, kortweg recursor, zoals die van je internetprovider of van een DNS-provider als Google of Cloudflare. Kent ook die het antwoord niet, dan verzoekt deze aan de root-nameservers om de DNS-records voor www.pcmweb.nl in hun databases op te zoeken.
De kans is groot dat die als respons geven “ik vind de host niet, maar ik beschik wel over de DNS-gegevens van .nl; je checkt het daarom best even bij de tld-nameservers (topleveldomein) van .nl”. De recursor gaat hierop in en krijgt vervolgens wellicht de suggestie door “check het bij de sld-nameserver (secondleveldomein) van pcmweb.nl”, waarop die vermoedelijk zal reageren met het gezochte antwoord: www.pcmweb.nl A 149.210.193.187. De recursor stuurt dit vervolgens netjes terug naar je webapplicatie.
Merk ook op dat in dit proces alleen de recursor recursief werkt en het geretourneerde antwoord verwerkt en doorstuurt. De andere, gezaghebbende (authoritative) DNS-servers zijn van het iteratieve type en zorgen slechts voor een doorverwijzing. Dit is begrijpelijk, omdat recursie veel te intensief zou zijn voor de overbevraagde nameservers.
©PXimport
Caching
In de praktijk beschikken de resolvers ook over uitgebreide caches. Dat geldt tevens voor je eigen systeem. Zo beschikt niet alleen je besturingssysteem over een eigen DNS-cache – in Windows haal je die op met ipconfig /displaydns en maak je die leeg met ipconfig /flushdns – maar kunnen ook de internetapplicaties zelf een DNS-cache bevatten. In Chrome bijvoorbeeld beheer en leeg je die via chrome://net-internals/#dns en in Firefox via about:networking#dns.
Ook recursors beschikken normaliter over caches, bedoeld om de DNS-nameservers te ontlasten. Hoelang een DNS-record wordt gecachet, hangt af van de TTL-waarde (Time To Live) die in (het SOA-record van) het zogenoemde zonebestand van je DNS-server is ingesteld. In Windows Opdrachtprompt kun je deze waarde opvragen met een opdracht als nslookup -type=soa pcmweb.nl.
Door deze caching zal een wijziging in een DNS-record ook niet meteen overal worden gepropageerd – dat kan wel tot drie dagen duren. Daarom is het vaak een goed idee de TTL-waarde tijdelijk lager in te stellen, voordat je aanpassingen aan je DNS-records doorvoert.
©PXimport
DNS-records
We hebben het al even gehad over zogeheten zonebestanden (zone files) in de nameservers, die zowat alle informatie over een domeinnaam bevatten en in principe uit twee delen bestaan: richtlijnen, zoals het al vermelde $ TTL, en bronrecords (resource records). Deze laatste bevatten DNS-informatie over een specifieke host of internetbron. De IETF (Internet Engineering Task Force) heeft talrijke recordtypes gedefinieerd. We beperken ons hier tot enkele van de meest gebruikte.
Zo bevatten de al eerder vermelde SOA-records (Start Of Authority) administratieve informatie voor de complete zone, waaronder dus de TTL-waarde. A-records linken dan weer een domeinnaam aan IPv4-adressen, terwijl AAAA-records dat voor IPv6-adressen doen. Een CNAME (Canonical Name Record) verwijst naar een andere domeinnaam, wat handig is als je een subdomein hebt dat naar hetzelfde ip-adres als je hoofddomein mag verwijzen. Ook MX-records verwijzen naar een domeinnaam, maar hier is dat de doelserver voor e-mailverkeer.
Veiligheid en privacy
Sinds het ontstaan van DNS in 1983 werd tot voor kort eigenlijk uitsluitend het UDP-transportprotocol gebruikt, kortweg Do53 (DNS-over-UDP op poort 53). Hierbij wordt een DNS-query in leesbare tekst van de client naar de server verstuurd en ook de reply komt in leesbare vorm in zo’n UDP-pakket terug. Erg veilig of privacybewust is dit uiteraard niet, omdat er op dit niveau niet in encryptie of in enig authenticatiemechanisme wordt voorzien en je evenmin garanties krijgt op een succesvolle of niet-gemodificeerde aflevering.
Via een RFC werd daarom naderhand ook TCP (Transmission Control Protocol) als mogelijk transportprotocol toegevoegd en nog later werd het DNSCrypt-protocol ontwikkeld, dat encryptie toeliet aan de downstream-zijde van recursive DNS-resolvers.
Inmiddels werden er ook diverse andere DNS-transportroutes ontwikkeld, waaronder DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), DNS-over-Quic (DoQ), DNS-over-HTTPS/3 (DoH3) en Oblivious DNS-over-HTTPS (ODoH). Bij Apple heet die laatste trouwens Private Relay.
©PXimport
De ontwikkeling van DNS
1983 Ontwikkeling van DNS
1985 Verdere ontwikkeling van DNS-serversoftware BIND
1989 Ook TCP kan worden ingezet voor DNS-query-transport (RFC 1123)
2000 BIND 9 (geheel nieuwe versie)
2011 DNSCrypt-protocol
2016 DoT
2018 DoH
2019 Toevoeging van een ‘geanonimiseerde’ modus aan DNSCrypt
2019 DNS-over-TOR
2021 ODoH
