A parent zone delegates a subtree to another set of name servers by placing NS records at the zone cut. If a delegated server's own name sits below that cut, the parent must also supply glue address records. Every zone should be served from at least two name servers.
What delegation is
RFC 1034 describes a zone as a connected section of the DNS tree managed by a server, and describes delegation as the parent marking where another party takes over. The NS records at the cut say which servers are authoritative for the child. The RFC is clear that those NS records are not authoritative data for the parent zone. They are a pointer.
This is how a registrar change works. You tell the registry which NS records to publish for your domain, and resolvers then follow referrals to your servers.
Glue records
Imagine example.com delegated to ns1.example.com. A resolver needs ns1's address to ask it anything, but to find that address it would have to ask example.com's servers. A loop. The fix is glue: the parent zone also holds address records for the name server so it can hand them out with the referral. The RFC states that if a delegated server's name falls below the cut, the parent needs glue, or the resolver cannot reach it.
If your name servers live in a different domain, no glue is needed.
The two server rule
RFC 1034 says every zone must be available from at least two servers. The reason is basic availability. One server means one failure takes the zone down. Better still, put the two on different networks and different providers, so a single outage or routing problem does not hide them both.
Common mistakes
- Lame delegation. The parent lists a server that does not actually answer authoritatively for the zone. Resolvers waste time or fail.
- Stale glue. You change a name server's address but not the glue at the parent.
- Mismatched NS sets. The parent and the child list different servers. Keep them identical.
- One provider for everything. Both name servers share one point of failure. We looked at a regional example in the AWS us-east-1 DNS outage lessons.
- Forgotten delegations. A subdomain delegated to a service you no longer use can be claimed by someone else. See dangling DNS and subdomain takeover.
Security notes
Delegation data sits at a trust boundary. Anyone who can change your registrar account or NS records controls your domain, so protect those accounts with strong authentication and a lock where your registrar offers one. With DNSSEC, the DS record in the parent links to the child's key, and RFC 4033 notes that glue and NS records at zone cuts are unsigned in the parent. Read what DNSSEC protects and what it does not.
A delegation checklist
- Two or more name servers on separate networks.
- Parent and child NS sets match.
- Glue present and current where needed.
- Registrar account protected and monitored.
- Every delegated subdomain has an owner.
Where Safeguard fits
Safeguard does not operate DNS. It scans dependencies and SBOMs for known vulnerabilities and provides asset discovery and policies for your software. Try the free scan at gold.safeguard.sh/scan.
Quick check
When do I need glue records?
When a delegated name server's own name lies inside the zone being delegated, so the resolver cannot look it up otherwise.
Are NS records at the zone cut authoritative in the parent?
No. RFC 1034 says they are not authoritative data for the parent zone.
Sources
- RFC 1034, Domain Names: Concepts and Facilities
- RFC 4033, DNS Security Introduction and Requirements
Last reviewed: 19 October 2026.
