Zoals je hebt kunnen zien kun je subdomeinen delegeren naar onderliggende nameservers. Maar als er onderliggende servers zijn, dan zijn er ook bovenliggende servers. En waar houdt dat op?
Het houdt op bij de DNS root. De root heeft geen naam, hij wordt
aangegeven met een punt. De rootservers (er zijn er 13) weten wat de
nameservers zijn voor de toplevel-domeinen, bijvoorbeeld wat de
nameservers zijn voor het domein "nl.", of het domein
"com.".
De namen en adressen van de 13 rootservers zijn bekend bij (zo goed
als) alle nameservers. Ook die in ons voorbeeld: root.hint bevat
ze alle 13. De lijst is ook op te vragen met het commando host -t
ns . (host -t ns punt)
Het hele DNS systeem is opgebouwd vanuit de root. Vanaf de root wordt steeds verder gedelegeerd tot je uiteindelijk uit komt bij een server die authoritative is voor de data die je wilt hebben.
Er is wel een probleem: wat nou als je nou het adres van een
nameserver wilt hebben, en je alleen maar de naam van die server weet?
En wat nou als nou net die server de enige server is die dat
adres weet? Theoretisch? Vraag maar aan de nameserver van com.
wat de nameserver is van example.com. Het antwoord zal zijn:
ns.example.com. Maar als je het adres van ns.example.com
wilt weten, dan zul je toch eerst zijn.... adres moeten weten.
Om deze kip-en-ei situatie op te lossen zijn er glue records.
De nameserver van com. weet ook het adres van
ns.example.com zodat je keurig doorverwezen kunt worden.
In het voorbeeld komt ook zoiets voor: ns.example.com heeft een
delegatie naar ns.office.example.com voor
office.example.com, maar ook een A-record voor die naam.
De gegevens in glue records worden op twee plekken opgeslagen: in de
delegerende server (oftewel parent server, in dit geval
ns.example.com) en in de authoritative server (in dit geval
ns.office.example.com). Bind zal de glue records altijd vervangen
door data vanaf authoritative servers. Uiteraard moet je zorgen dat de
data in beide gevallen hetzelfde is, maar bijvoorbeeld de TTL kan
verschillen.