Sometimes you want a subdomain to live somewhere other than the rest of your domain. Maybe a SaaS platform wants full control of app.example.com, or a separate team runs status.example.com on its own DNS provider. The clean way to do this is delegation: you place NS records at the parent zone that hand the subdomain off to another set of nameservers, which then answer for everything beneath it. This guide covers how delegation works, when it beats simply adding records, and how to confirm the handoff actually resolves.
What delegation really means
DNS is a tree of zones, and each zone is served by its own authoritative nameservers. Delegation is the act of a parent zone pointing to the child zone's nameservers, saying in effect, "I am not authoritative for names below this point; ask these servers instead." You do it by publishing NS records for the subdomain in the parent zone. From then on, any resolver walking down the tree is referred from the parent's nameservers to the child's, and the child's provider answers all queries for that subdomain and anything under it.
The crucial distinction is between the NS records at the parent and the records inside the child zone. The parent holds only the NS records that point the way. The child zone, hosted at the delegated provider, holds the actual A, AAAA, MX, TXT, and other records. Both sides must agree on which nameservers are authoritative.
Delegation versus just adding records
You do not need delegation to create a subdomain. If you simply want blog.example.com to point at a host, you add an A or CNAME record for it in your existing zone and you are done. Delegation is the right tool only when the subdomain needs to be managed as a separate zone, typically by a different operator.
| Situation | Add a record | Delegate |
|---|---|---|
| Point a subdomain at one IP or host | Yes | No |
| Let another team or vendor manage all records under the subdomain | No | Yes |
| Subdomain runs on a different DNS provider | No | Yes |
| Subdomain needs its own DNSSEC or many records | No | Yes |
If one or two records will do, delegation is overkill and adds moving parts. Reach for it when control, not just a value, needs to move.
Setting up the delegation
Delegation is a two-sided operation. First, in the parent zone, add NS records for the subdomain naming the child's nameservers.
; In the example.com zone (the parent)
app.example.com. 86400 IN NS ns1.vendor-dns.net.
app.example.com. 86400 IN NS ns2.vendor-dns.net.Second, on those child nameservers, create the zone for app.example.com and populate it with the records the subdomain needs. The child zone should list the same nameservers in its own NS records at the apex, so the two sides are consistent.
; In the app.example.com zone (the child, at the vendor)
app.example.com. 3600 IN NS ns1.vendor-dns.net.
app.example.com. 3600 IN NS ns2.vendor-dns.net.
app.example.com. 3600 IN A 203.0.113.20
www.app.example.com. 3600 IN CNAME app.example.com.Once the parent's NS records propagate, resolvers follow the referral to the vendor's servers for anything under app.example.com.
When glue records are needed
Glue records are A or AAAA records for a nameserver, supplied by the parent, to break a chicken-and-egg loop. They are needed only when the nameservers you delegate to are themselves inside the zone being delegated, which is called in-bailiwick. If you delegated app.example.com to ns1.app.example.com, a resolver cannot look up that nameserver's address without first reaching the very zone it is trying to find. The parent must supply glue to break the loop.
In the common case shown above, where you delegate to out-of-zone nameservers like ns1.vendor-dns.net, no glue is required. The resolver already resolves vendor-dns.net independently through its own delegation. This is one reason delegating to a provider's existing nameservers is simpler than running nameservers named inside the delegated subdomain.
TTL choices at the delegation point are worth a moment of thought too. The NS records in the parent control how long resolvers cache the referral itself, which affects how quickly a future change of provider takes effect. A moderate value such as one day is typical, but if you anticipate moving the subdomain soon, lower the parent NS TTL ahead of the change so stale referrals expire quickly. The records inside the child zone have their own independent TTLs, and the two layers do not need to match.
Confirming the handoff resolves
After setup, verify both the referral and the records behind it. Start by asking for the NS records of the subdomain, which shows whether the delegation is published.
$ dig NS app.example.com +short
ns1.vendor-dns.net.
ns2.vendor-dns.net.To watch the delegation actually happen, trace the resolution from the root. The trace shows the parent's nameservers returning a referral to the child's, which is the delegation working.
$ dig +trace app.example.com
; ... root servers ...
; ... .com servers ...
example.com. 172800 IN NS ns1.example-dns.com.
app.example.com. 86400 IN NS ns1.vendor-dns.net. ; referral to the child
app.example.com. 3600 IN A 203.0.113.20 ; answered by the childFinally, query the record you expect directly against one of the delegated nameservers to confirm the child zone is populated and answering authoritatively.
$ dig @ns1.vendor-dns.net app.example.com A +short
203.0.113.20Common delegation mistakes
- Parent and child disagree on nameservers. If the NS records at the parent list different servers than the child zone, resolvers may get inconsistent referrals. Keep both sides matched.
- Forgetting to create the child zone. Delegating to nameservers that have no zone for the subdomain yields SERVFAIL or REFUSED. Build the child zone before or as you delegate.
- Leaving stale records in the parent. An old A record for the subdomain in the parent zone can conflict with the delegation. The delegation point should hold NS records, not address records for the same name.
- Missing glue for in-bailiwick nameservers. If you must name nameservers inside the delegated subdomain, add glue at the parent or resolution will loop.
Verify the delegation across resolvers
A delegation is only complete once the parent's NS records have propagated and resolvers worldwide follow the referral to the child. Run the subdomain through the Valla DNS propagation checker to confirm the NS records and the records behind them appear consistently everywhere, and pair this with our guides on glue records and reading a delegation trace to be sure every hop in the chain lines up before you rely on the handoff.