What subdomain delegation is
Delegating a subdomain hands control of a separate branch of the zone to other NS servers, without moving the whole domain. For example, shop.example.com can be served by the DNS servers of an online store platform while example.com itself stays on ZevsHost servers. The parent zone keeps only the NS records pointing to who is responsible for the subdomain, while all A, CNAME and TXT records of the subdomain live on the third-party servers.
This setup is needed when a subdomain connects to an external service: a CDN, a mailing platform, a separate cloud, or a partner system with its own requirements for DNS records.
How to set up delegation in the parent zone
Delegation is defined by NS records for the subdomain name. In the example.com zone, add:
shop IN NS ns1.partner-dns.com.
shop IN NS ns2.partner-dns.com.Note the trailing dot after the server name — it marks a fully qualified domain name (FQDN) and is required in BIND zone files. After adding these records, there must be no A or CNAME records for shop.example.com left in the main zone: they would be ignored, because the external NS servers now own that name.
The partner must set up the shop.example.com zone on the listed servers and add their own A, MX and other records there — otherwise the delegation points nowhere.
Glue records: when you cannot skip them
If the subdomain's NS servers themselves sit inside the same domain — for example, ns1.shop.example.com — a circular dependency appears: to learn the IP of ns1, you would need to ask that same server. Glue records solve this problem — A records for the NS server, published directly in the parent zone next to the delegation:
shop IN NS ns1.shop.example.com.
ns1.shop IN A 203.0.113.10If the subdomain's NS servers sit in a third-party domain (as in the partner-dns.com example), glue records are not needed — a resolver can find their IP through a normal DNS query anyway.
Checking delegation after setup
After publishing the zone, check that delegation actually works:
dig shop.example.com NS +traceThe answer should show the partner's NS servers, not the old example.com servers. A detailed walkthrough of the dig command and typical server answers is in the article on checking a DNS zone. Also query the delegated servers directly:
dig shop.example.com A @ns1.partner-dns.comIf you get an answer, the zone is up and delegation works. If you get REFUSED or a timeout, the zone has not been configured on the partner's side yet.
Common delegation mistakes
| Problem | Cause |
|---|---|
| Subdomain does not resolve anywhere | The zone was never created on the delegated servers |
| Works for some users only | The old NS record TTL has not expired in resolver caches yet |
| SERVFAIL when querying the A record | Missing glue record for an NS server inside the same domain |
| Delegation is not confirmed by dig +trace | Typo in the NS server name or an extra dot |
Subdomain delegation checklist
- Confirm the exact NS server names with the partner and never use IPs instead of names.
- Add NS records to the parent zone, without matching A or CNAME records for the same name.
- Set up glue records if the NS server itself belongs to the delegated or parent domain.
- Verify delegation with
dig +tracefrom two different resolvers. - Agree with the partner on the TTL of records inside the subdomain so changes apply quickly.