DNS delegation and glue records

What delegation is

DNS is organised as a tree of zones. The root zone delegates com to the .com nameservers, those delegate example.com to the nameservers that hold the example.com zone, and so on down to sub.example.com. Each delegation is a pair of records in the parent zone: an NS record that names the child zone's authoritative nameservers, and a matching A or AAAA record for that nameserver when the nameserver's name falls inside the child zone itself.

The NS record is what tells resolvers where to send queries for a child zone. Without it the parent does not point anywhere, and the child zone is unreachable even though the zone file exists on the nameserver.

When glue is needed

The problem a glue record solves is bootstrapping. A resolver that receives the delegation learns the authoritative nameserver's name, for example ns1.example.com. To query that server it must resolve ns1.example.com, but the answer for that name lives in the zone the server is authoritative for, a circular dependency.

When the nameserver name is inside the delegated zone, the parent includes a glue A or AAAA record alongside the NS record so the resolver can reach the nameserver without first going through the child zone. This is called an in-bailiwick nameserver.

An out-of-bailiwick nameserver is one whose name lives in a different zone, for example delegating example.com to a nameserver named ns1.somewhere-else.net. Because that name resolves normally through another part of the tree, glue is not strictly required, although some registries still provide it.

The same mechanism applies to subdomain hosting. If you point store.example.com at nameservers that are directly part of store.example.com, you must arrange the glue so resolvers can find them.

Delegating a zone

You do not usually edit glue by hand. When you change the nameservers for a domain at your registrar or DNS hosting panel, the system sends the new NS records and matching glue to the parent zone:

1. Confirm the child zone actually has the NS records that match what you advertise.
2. Update the nameserver delegation at the registrar or panel where the parent zone lives.
3. Wait for the parent zone to publish the update, which can take as long as the parent's TTL.
4. Test with a competing-resolver tool, for example a public resolver lookup, to confirm the delegation resolves.

The most common failure is a mismatch where the parent advertises nameservers the child zone does not serve, producing an SERVFAIL or an endless referral loop. Keep the advertised nameservers identical in the parent and child zones, and remove stale nameservers from both at the same time.

Misconfigured glue slows or breaks resolution for every client, not just you, because the delegation is shared data. Double-check each nameserver name and address before publishing.

Related reading: the difference between A and CNAME records matters when choosing nameserver names, and DNS record moves cover changing hosted nameservers cleanly alongside existing record type fundamentals.