A zone is the unit of authority in DNS, and delegation is how authority is handed from one zone to another. Two structural quirks come out of this — NS records existing in two places at once, and glue — and both cause real outages.
Zone is not the same as domain
A zone is the part of the namespace a particular set of servers is authoritative for. example.com the domain might be one zone containing everything, or it might delegate eu.example.com to a different team’s servers, making that a second zone. The domain is a name; the zone is an administrative boundary.
NS records live in two places
A delegation is expressed as NS records in the parent zone. The child zone also publishes its own NS records. Both exist, and they are supposed to agree.
;; AUTHORITY SECTION: certadns.com. 172800 IN NS ns1.certadns.com. certadns.com. 172800 IN NS ns2.certadns.com. ;; ADDITIONAL SECTION: ns1.certadns.com. 172800 IN A 178.156.201.123 ns2.certadns.com. 172800 IN A 79.137.72.130
| Copy | Who controls it | What it does |
|---|---|---|
| Parent (the delegation) | Your registrar, pushing to the registry. | This is what resolvers follow. It decides who answers for your domain. |
| Child (in the zone) | You, in your DNS. | Informational in practice. Some tools check it; resolvers get where they are going without it. |
A mismatch is a long-lived, silent finding
After a DNS provider migration, the parent is updated and the old NS set is often left in the zone. Everything works, because resolvers follow the parent. It then sits there for years, misleading anyone who checks the zone, and it becomes a genuine problem the day someone reconciles the two in the wrong direction. Compare both after any migration:
dig +norecurse @<a parent server> NS example.com against dig NS example.com
Glue, and the circularity it breaks
In the output above, certadns.com’s nameservers are named ns1.certadns.com and ns2.certadns.com — inside the zone they serve. To resolve those names a resolver would have to ask them, which it cannot reach without resolving them first.
Glue records break the loop: the parent supplies the addresses alongside the delegation, in the ADDITIONAL section. That is what the two A records above are.
- Glue is required when a nameserver’s name is inside the zone it serves. Without it, the domain is unresolvable.
- Glue is not used when the nameservers are outside —
ns1.provider.exampleresolves throughprovider.examplenormally. - Glue lives in the parent, so it is a registrar operation. Changing a nameserver’s IP address means updating it at your registrar, not in your zone, and editing only the zone leaves the world using the old address.
Lame delegation
A delegation is lame when a server listed in it does not actually answer authoritatively for the zone — decommissioned, misconfigured, or never set up. Resolvers try it, wait, time out, and try the next. The domain still works and every lookup that happens to pick the lame server is slow.
Check each listed server individually rather than trusting the aggregate:
for ns in $(dig +short NS example.com); do echo "== $ns" dig +norecurse @"$ns" SOA example.com | grep -E 'flags:|SOA' done
You want aa in the flags on every one of them. A server answering without the authoritative-answer flag is not serving the zone, whatever the delegation says.