A DNS glue record is what allows a parent zone to delegate a subdomain to a name server that is itself hosted within that same subdomain.
Let’s see this in action. Imagine you’ve just registered example.com and you want to host your own DNS for it. You’ll need name servers. A common practice is to name your name servers something like ns1.example.com and ns2.example.com.
Now, here’s the rub: for the world to find ns1.example.com and ns2.example.com, the DNS system needs to know their IP addresses. But where do you store the IP addresses for ns1.example.com? You’d typically store them in the example.com zone!
This creates a circular dependency:
- To find the IP address of
ns1.example.com(to resolveexample.com), you need to ask a name server. - Which name server do you ask? You’d ask
ns1.example.comandns2.example.com. - But to find the IP address of
ns1.example.com, you need to look it up in theexample.comzone.
The DNS system would get stuck in an infinite loop trying to resolve this.
This is where glue records come in. A glue record is a special type of DNS record that provides the IP address of a name server along with the delegation. When you delegate example.com to ns1.example.com and ns2.example.com, you, or your domain registrar, will create glue records at the parent zone (which is the root zone for .com in this case, but more generally, it’s the zone that owns the domain you’re delegating).
These glue records are typically A (IPv4) and AAAA (IPv6) records for the name servers themselves. For instance, if you delegate example.com and your name servers are ns1.example.com (IP 192.0.2.1) and ns2.example.com (IP 192.0.2.2), the glue records would look like this at the .com TLD level:
ns1.example.com. 3600 IN A 192.0.2.1
ns2.example.com. 3600 IN A 192.0.2.2
When a resolver (like your local ISP’s DNS server) needs to find www.example.com, it first queries the root servers for .com. The .com servers, instead of just returning the name servers for example.com (ns1.example.com, ns2.example.com), will also return the IP addresses for those name servers directly.
The resolver then uses these provided IP addresses to query ns1.example.com and ns2.example.com directly for the www.example.com record. This breaks the circular dependency because the resolver gets the IP address of the authoritative name server before it has to ask that name server for any records within its own zone.
Think of it like this: You need to call John. John’s phone number is listed in the "John’s Contacts" directory. But to get the "John’s Contacts" directory, you need to ask John. This is a paradox. A glue record is like having John’s phone number written down on the same page in the main phone book that tells you where to find the "John’s Contacts" directory. You get the essential piece of information (John’s number) without needing to resolve the directory itself first.
This mechanism is fundamental for any "sub-delegation" where the name servers for a zone are located within that same zone. Without glue records, you couldn’t have self-hosted name servers for your own domain. The registrar’s interface is where you’d typically configure these, as they are responsible for managing the records in the parent zone. When you set up your name servers with your registrar, they often prompt you to enter the IP addresses for those name servers, and they then generate the necessary glue records in the .com zone (or whichever TLD you’re using).
The key takeaway is that glue records are not part of the example.com zone itself. They are hosted in the parent zone (e.g., .com or .org). This is why they are called "glue" – they bridge the gap between the parent zone and the child zone’s name servers by providing the necessary IP address information to initiate the resolution process.
The next problem you’ll encounter is understanding how DNSSEC interacts with glue records, specifically regarding "insecure delegation" scenarios.