Kennisbank

DNS-delegatie: hoe het internet zijn adresboek verdeelt

Bijgewerkt: 27 september 2026 · 5 min leestijd

Stel je voor dat er één telefoonboek voor de hele wereld zou bestaan, beheerd door één instantie. Iedere verhuizing, elke nieuwe aansluiting, elke wijziging zou via die ene organisatie moeten lopen. Dat zou onwerkbaar zijn. Het domeinnaamsysteem van het internet (DNS, het systeem dat namen als detoekomstisnu.nl omzet naar de cijfercodes waarmee computers elkaar vinden) lost dit probleem op met delegatie: het overdragen van de verantwoordelijkheid voor een stukje van dat adresboek aan een andere partij.

Concreet betekent dit dat de beheerder van het domein .nl niet zelf bijhoudt welk IP-adres bij detoekomstisnu.nl hoort. Die taak is gedelegeerd aan de organisatie die dit domein beheert, en die kan de verantwoordelijkheid voor bijvoorbeeld een subdomein weer verder delegeren aan een hostingbedrijf. Zo ontstaat een boomstructuur van vertrouwen en verantwoordelijkheid, met op de bovenste laag de zogeheten rootservers, en daaronder talloze vertakkingen die elk hun eigen stukje van het internet beheren.

Wat is het precies?

DNS is opgebouwd als een boomstructuur. Helemaal bovenaan staat de zogeheten root (letterlijk "wortel"), aangeduid met een punt. Daaronder hangen de topleveldomeinen (TLD's) zoals .nl, .com, .be of .org. Daaronder weer hangen de domeinen die mensen en bedrijven registreren, zoals detoekomstisnu.nl, en daaronder eventueel subdomeinen zoals mail.detoekomstisnu.nl.

Delegatie werkt via zogeheten NS-records (nameserver-records). Wanneer de beheerder van de root besluit dat .nl bestaat, plaatst deze een verwijzing: "voor alles onder .nl, vraag het aan deze specifieke nameservers". Die nameservers behoren toe aan de organisatie die het topleveldomein beheert. Voor .nl is dat SIDN (Stichting Internet Domeinregistratie Nederland). SIDN doet vervolgens hetzelfde één laag dieper: voor detoekomstisnu.nl wordt verwezen naar de nameservers van de hostingpartij die deze site beheert.

Het mooie aan dit systeem is dat elke laag alleen hoeft te vertrouwen op de laag direct erboven, en zelf volledige controle heeft over alles daaronder. De beheerder van .nl hoeft niets te weten van hoe detoekomstisnu.nl zijn e-mail of website inricht; die verantwoordelijkheid is volledig overgedragen, ofwel gedelegeerd.

Een belangrijke technische aanvulling hierop is DNSSEC (DNS Security Extensions), een uitbreiding die met digitale handtekeningen aantoonbaar maakt dat een delegatie ook echt van de juiste partij komt. Zonder DNSSEC kan in theorie iemand een vervalste delegatie invoegen en zo verkeer omleiden; met DNSSEC kan elke laag in de keten cryptografisch controleren of de informatie van de laag erboven ongewijzigd is doorgegeven.

Wat wil men ermee bereiken?

Het hoofddoel van delegatie is schaalbaarheid zonder centrale controle over de uitvoering. Er zijn wereldwijd honderden miljoenen domeinnamen; geen enkele server zou alle bijbehorende gegevens in real time kunnen bijhouden en beantwoorden. Door de verantwoordelijkheid laagsgewijs te verspreiden, kan elke organisatie haar eigen stukje beheren, updaten en beveiligen, terwijl het geheel toch als één samenhangend systeem functioneert.

Een tweede doel is autonomie. Landen en organisaties willen zelf kunnen bepalen wie een domeinnaam onder hun topleveldomein mag registreren, tegen welke regels en tegen welke prijs. Doordat .nl gedelegeerd is aan SIDN, bepaalt SIDN (binnen internationale kaders) het beleid voor Nederlandse domeinnamen, zonder dat een internationale instantie zich daarmee bemoeit.

Ten derde speelt veerkracht een rol. Een gedelegeerd systeem heeft geen enkel single point of failure op elke laag: als één nameserver uitvalt, springt een andere bij, en problemen in één tak van de boom hoeven de rest van het internet niet te raken. Ten slotte is er het beveiligingsdoel dat DNSSEC nastreeft: voorkomen dat kwaadwillenden zich tussen de lagen dringen en gebruikers naar foute adressen leiden.

Voorbeelden uit de praktijk

De delegatie van .nl aan SIDN (1996) is een schoolvoorbeeld: sinds de oprichting van SIDN in 1996 beheert deze Nederlandse stichting het topleveldomein .nl, met inmiddels ruim zes miljoen geregistreerde domeinnamen.

Ondertekening van de rootzone met DNSSEC (2010) was een mijlpalen-project van ICANN en Verisign, waarbij voor het eerst de allerhoogste laag van het DNS cryptografisch werd beveiligd. Sindsdien kunnen delegaties van de root naar TLD's aantoonbaar geverifieerd worden.

De introductie van nieuwe generieke topleveldomeinen (vanaf 2013), zoals .amsterdam, .shop of .bank, is in essentie een grootschalige delegatie-operatie: ICANN kende honderden nieuwe TLD's toe aan uiteenlopende partijen, elk met hun eigen delegatiestructuur eronder.

Cloudplatformen die subdomeinen delegeren, zoals wanneer een bedrijf een deel van zijn domein (bijvoorbeeld shop.bedrijf.nl) delegeert aan de nameservers van een clouddienst zoals AWS Route 53 of Cloudflare, is inmiddels dagelijkse praktijk voor duizenden Nederlandse organisaties die diensten uitbesteden zonder hun hele domein over te dragen.

Geschillen over ccTLD-delegatie tijdens conflicten, zoals de discussie in 2022 of Rusland losgekoppeld zou moeten worden van zijn topleveldomeinen .ru en .рф, illustreren dat delegatie ook een geopolitiek instrument kan worden: ICANN wees destijds verzoeken om dergelijke delegaties in te trekken af, met het argument dat DNS een technische, geen politieke laag moet blijven.

Hoe ver is de techniek?

Het basisprincipe van DNS-delegatie is sinds de introductie van DNS zelf in 1983-1987 (vastgelegd in de standaarddocumenten RFC 1034 en RFC 1035) nauwelijks veranderd; het is een van de meest stabiele en beproefde technische systemen van het internet. De grote ontwikkeling van de laatste vijftien jaar zit vooral in de beveiliging eromheen.

DNSSEC-adoptie gaat gestaag maar niet volledig: sinds de root in 2010 werd ondertekend, hebben veel TLD's waaronder .nl DNSSEC ingevoerd, maar wereldwijd valideert nog altijd niet elke resolver (de software die namen daadwerkelijk opzoekt) de handtekeningen, en niet elk domein onder een TLD past het toe. Cijfers van meetorganisaties zoals APNIC laten zien dat het percentage gebruikers achter een DNSSEC-valideerende resolver de afgelopen jaren is gegroeid, maar in veel landen nog geen meerderheid vormt.

Een terugkerend obstakel is complexiteit: correcte DNSSEC-configuratie vraagt zorgvuldig sleutelbeheer, en fouten daarin kunnen juist tot uitval leiden in plaats van extra veiligheid. Daarnaast blijft delegatie een systeem gebaseerd op vertrouwen tussen lagen; technische maatregelen zoals DNSSEC verkleinen het risico op misbruik, maar bestuurlijke kwesties (wie mag delegeren, onder welke voorwaarden) blijven onderwerp van internationaal debat, met name rond de rol van de Amerikaanse overheid versus internationale multistakeholder-organen.

Wie werken eraan?

ICANN (Internet Corporation for Assigned Names and Numbers), een Amerikaanse non-profitorganisatie, coördineert sinds 1998 de toewijzing van topleveldomeinen en beheert via zijn onderdeel IANA (Internet Assigned Numbers Authority) de rootzone zelf.

Verisign, een Amerikaans bedrijf, beheert operationeel een deel van de rootservers en de .com/.net-registers, en werkte nauw samen met ICANN aan de DNSSEC-ondertekening van de root.

SIDN is verantwoordelijk voor .nl; vergelijkbare nationale registries bestaan voor vrijwel elk land, zoals DNS Belgium voor .be.

De IETF (Internet Engineering Task Force) ontwikkelt en onderhoudt de technische standaarden achter DNS en DNSSEC via open RFC-documenten, terwijl regionale internetregistries zoals RIPE NCC (voor Europa) een rol spelen bij gerelateerde infrastructuur zoals IP-adrestoewijzing.

Verder lezen