Hoe DNS-delegatie werkt
Kort antwoord
Delegatie is de manier waarop een bovenliggende zone het gezag over een naam overdraagt aan een specifieke set nameservers. Wanneer je een domein naar de nameservers van je DNS-provider wijst, of een subdomein ergens anders laat beheren, delegeer je: de bovenliggende zone bevat NS-records die zeggen "vraag deze servers voor alles onder deze naam" en beantwoordt dat deel van de boom zelf niet meer.
Delegatie in één zin
Elke DNS-zone kan de verantwoordelijkheid voor een deel van zijn namespace overdragen aan een andere set nameservers, en die overdracht heet delegatie. De bovenliggende zone houdt geen kopie bij van de records onder de gedelegeerde naam. In plaats daarvan bevat hij een NS-record dat naar de nameservers verwijst die dat wel doen, en elke opzoeking voor iets onder die naam wordt daarnaartoe doorgestuurd.
Dit gebeurt op elk niveau van DNS, niet één keer maar telkens weer. Het is het mechanisme waarmee een hiërarchie zonder centrale eigenaar toch werkt als één samenhangend opzoeksysteem.
De keten van root tot jouw domein
Een opzoeking voor example.com doorloopt een keten van delegaties. De rootzone kent het IP-adres van example.com niet, maar weet wel welke servers gezaghebbend zijn voor het topleveldomein .com, omdat die verantwoordelijkheid is gedelegeerd aan het registry dat .com beheert. Vraag het aan een .com-server, en ook die kent het IP-adres niet, maar weet wel welke nameservers gezaghebbend zijn voor example.com, omdat je registrar NS-records heeft gepubliceerd die dat domein delegeren aan de nameservers die jij hebt gekozen. Pas bij die laatste stap geeft iets daadwerkelijk antwoord met het record dat je zocht.
Elke stap is een aparte delegatie, en elke stap hoeft alleen te weten welke server hij daarna moet vragen, niet het uiteindelijke antwoord. Zie DNS-recordtypes uitgelegd voor hoe een NS-record eruitziet naast de andere recordtypes die je in een zone tegenkomt.
Een subdomein delegeren
Hetzelfde mechanisme werkt één niveau dieper. Wil je dat shop.example.com door een andere DNS-provider, of een ander team, wordt beheerd dan de rest van example.com, dan voeg je een NS-record voor shop toe binnen de example.com-zone, dat verwijst naar de nameservers die daarvoor moeten antwoorden. Vanaf dat moment wordt alles onder shop.example.com opgezocht bij die nameservers, en hoeven wijzigingen aan dat subdomein de bovenliggende zone helemaal niet meer te raken. Het is hetzelfde delegatiepatroon als voor een heel domein, alleen toegepast één label dieper.
De veelvoorkomende fout: NS-records die niet overeenkomen
Delegatie werkt alleen als de bovenliggende zone en de gedelegeerde kant het eens zijn over wie gezaghebbend is. In de praktijk betekent dat: de NS-records die bij je registrar staan ingesteld, moeten overeenkomen met de nameservers die je DNS-provider daadwerkelijk verwacht te gebruiken voor de zone. Lopen die uit elkaar, bijvoorbeeld doordat een domein bij de registrar nog oude nameservers vermeldt na het overstappen van provider, dan kan de resolutie op manieren mislukken die lastig te diagnosticeren zijn: sommige resolvers hebben de oude delegatie mogelijk gecachet en blijven een tijd werken, andere pikken de nieuwe direct op, en het domein kan er vanaf de ene locatie uitzien alsof het werkt en vanaf de andere alsof het kapot is, totdat elke cache onderweg is verlopen.
De oplossing is eenvoudig zodra je weet waar je moet kijken: de NS-records bij de registrar moeten precies overeenkomen met wat de DNS-provider verwacht, niet meer en niet minder. Reverse DNS wordt op dezelfde manier gedelegeerd, alleen voor IP-adresruimte in plaats van domeinnamen, en wordt los van de forward-zone beheerd. Zie Reverse DNS (rDNS) bewerken om dat aan te passen op een Worldstream-IP.