Zones

Delegated zones

A delegated zone says: "I'm publishing NS records that point at a different nameserver for this sub-name. Clients should go ask them directly." Delegation is how the DNS hierarchy is built: it's what .com does when it tells you "go ask example.com's nameservers."

What it is#

In the parent zone you publish:

An NS record set at the child name, listing the nameservers that own the child zone
Glue records (A/AAAA) for any NS name that lives inside the delegated zone; required in that case, or resolvers cannot follow the referral (an in-domain nameserver in RFC 9499 section 7 terms: see "Glue" below)
If the child zone is DNSSEC-signed, a DS record at the same name, fingerprinting the child's key so the chain of trust crosses the cut (see dnssec)

That's it. The parent no longer answers for names under the child. A resolver walking the hierarchy hits the parent, gets back a referral ("go talk to those NS"), and continues there.

The child runs its own authoritative server. From the parent's perspective the child is opaque: it could be anything, anywhere.

When to use it#

Sub-team or sub-product owns the namespace. customers.example.com is owned by a team that runs their own auth servers.
Lab / pre-prod separation. Delegate lab.example.com to lab nameservers so prod is not on the hook for lab churn.
Sub-delegations in reverse zones. RFC 2317 classless reverse delegations are a special case of this: see Reverse DNS: in-addr.arpa and ip6.arpa.
Geo or capability splits: eu.example.com to a regional cluster.
Customer-owned subdomains. Customer points their NS records for <them>.yourservice.com at their own DNS; you delegate.

When not to use it#

If you just want your resolver to chase the queries to someone else's DNS without changing what the world sees: use forward instead.
If you own the records anyway: keep them in auth.

Real-world examples#

Parent zone	Child name	Where it goes
`example.com`	`customers.example.com`	Customers' SaaS namespace, owned by a SaaS team
`example.com`	`eu.example.com`	EU geo cluster's authoritative DNS
`example.com`	`corp.example.com`	Active Directory-owned namespace
`51.198.in-addr.arpa`	`100.51.198.in-addr.arpa`	A `/24` reverse zone delegated to an internal authoritative server
`isitdns.net`	`probe.isitdns.net`	This wiki's live example of delegating a subdomain to its own authoritative nameservers

The probe.isitdns.net row is the live example used below: this wiki's own delegated sub-zone. One nameserver serves it, pns2.isitdns.net, and every transcript on this page was captured against the live zone. Run the commands yourself and you should get the same shape back, with a newer serial.

How to create a delegation#

The setup is the same across every DNS server:

In the parent zone, add an NS record set at the child's apex naming the child's nameservers.
If the child's nameservers live inside the delegated zone (in-domain), also add A/AAAA glue records alongside the NS.
On the child's authoritative server, create the child zone and confirm its apex NS records list the same nameservers.
If the child zone is DNSSEC-signed, also publish its DS record in the parent at the child's name; without it, validating resolvers treat the child as unsigned (see dnssec).

In zone-file form the parent-side configuration looks like:

customers.example.com.       86400  IN  NS  ns1.customers.example.com.
customers.example.com.       86400  IN  NS  ns2.customers.example.com.
ns1.customers.example.com.   86400  IN  A   203.0.113.20
ns2.customers.example.com.   86400  IN  A   203.0.113.21

The last two lines are glue: A records for NS names that live inside the delegated zone itself.

Most managed DNS providers expose a form or API call that produces the same records. The zone-file form is shown here because it's server-agnostic and readable.

Glue records: the in-domain case#

If your NS name lives inside the delegated zone, for example ns1.customers.example.com, a resolver chasing customers.example.com NS gets ns1.customers.example.com. back and immediately needs that NS's address to make the next call. But the address record lives inside the delegated zone, which the resolver has not visited yet. That is a chicken-and-egg problem.

The parent solves this by publishing glue records: A/AAAA records for the NS name, served in the Additional section alongside the NS referral. The resolver does not need to go anywhere else to get the address.

The probe.isitdns.net delegation below is the near miss worth studying: its nameserver pns2.isitdns.net lives in the parent zone beside the cut, NOT under probe.isitdns.net. RFC 9499 section 7 calls that a sibling domain nameserver, and RFC 9471 splits the two cases cleanly: a server MUST include all available glue for in-domain nameservers (section 3.1), and SHOULD include it for sibling ones (section 3.2). So the address the parent hands back for pns2 is expected but not mandatory, while glue for a nameserver under the delegated zone is not optional at all.

If your NS names live in an unrelated zone (for example, ns1.example-dns-provider.com for example.com), no glue is possible or needed: the resolver looks those up via the normal path. That is the third relationship RFC 9499 section 7 names, after in-domain and sibling domain, and it is the one with the least to break. The older labels "in-bailiwick" and "out-of-bailiwick" cover this ground too, but RFC 9499 marks them historic because they blur the in-domain and sibling cases together.

Querying a live delegation#

The parent side of a delegation answers with a referral, not a normal answer: the NS records come back in the AUTHORITY section, the ANSWER section is empty, and the aa flag stays clear, because delegation NS records are not authoritative data in the parent ("these RRs are NOT part of the authoritative data of the zone", RFC 1034 section 4.2.1). You can watch a live one at the .net to isitdns.net cut:

dig @a.gtld-servers.net isitdns.net NS +norec

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ...
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; AUTHORITY SECTION:
isitdns.net.  172800  IN  NS  hera.ns.cloudflare.com.
isitdns.net.  172800  IN  NS  coleman.ns.cloudflare.com.

No glue rides along here (the single additional record is the EDNS OPT pseudo-record): coleman and hera live under cloudflare.com, outside the zone being cut, so a resolver looks their addresses up separately.

The live example: a delegation with sibling-domain glue. probe.isitdns.net is this wiki's delegated sub-zone of isitdns.net. You can watch the full picture with three queries.

Step 1: ask the parent's authoritative server for the delegation.

The parent for isitdns.net is Cloudflare. Query it directly:

dig @coleman.ns.cloudflare.com probe.isitdns.net NS +norecurse

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:
;probe.isitdns.net.        IN  NS

;; AUTHORITY SECTION:
probe.isitdns.net.  300  IN  NS  pns2.isitdns.net.

;; ADDITIONAL SECTION:
pns2.isitdns.net.   300  IN  A   158.101.0.110

This response is worth reading section by section, because the three sections are the whole story of a referral:

ANSWER: 0. The parent did not answer the question. It is not authoritative for probe.isitdns.net and it refuses to pretend otherwise: no aa flag, no answer records.
AUTHORITY: the handoff. "I do not hold this zone, but that server does." NS records in the AUTHORITY section of a response with an empty answer is a referral. This is the delegation, on the wire.
ADDITIONAL: the address, as a courtesy. The parent volunteers the A record for pns2 without being asked. Strictly it does not have to: pns2.isitdns.net sits in isitdns.net itself, beside the cut rather than under it, so a resolver could resolve it through the normal isitdns.net path. The parent is authoritative for that name anyway, so it saves everyone a round trip by riding the address in ADDITIONAL. Required glue is the stricter case in the Glue section above, where the NS name lives under the zone being delegated and the referral would otherwise be unfollowable. (The second additional record in the count is the EDNS OPT pseudo-record, which carries options rather than data.)

Compare the .net cut above, where ADDITIONAL was empty: coleman and hera live under cloudflare.com, a different tree entirely, so the .net servers hold no address for them and send none. Three shapes, one rule: address under the delegated zone = glue required; address elsewhere in the parent's own zone = optional courtesy; address in someone else's tree = nothing. Once you see that pattern you can read any referral.

nslookup -type=NS probe.isitdns.net coleman.ns.cloudflare.com

Step 2: ask the parent for the nameserver's address.

dig @coleman.ns.cloudflare.com pns2.isitdns.net A

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
pns2.isitdns.net.  300  IN  A  158.101.0.110

This comes back as an ordinary authoritative answer (aa set, the record in the ANSWER section), not as glue, because the pns2 name sits in isitdns.net itself, beside the cut rather than under it: the sibling-domain case. The parent publishes the same addresses alongside the NS referral so a resolver can reach the child without an extra lookup chain.

Step 3: verify the child answers for its own zone.

dig @pns2.isitdns.net probe.isitdns.net SOA +norec

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; ANSWER SECTION:
probe.isitdns.net.  5  IN  SOA  pns2.isitdns.net. hostmaster.isitdns.net. (
                                  2026082002 7200 3600 1209600 300 )

The serial (2026082002 above) increments each time the zone is updated, so your output will show a different value, and the record TTL is deliberately short so changes show up fast. The other fields (MNAME, RNAME, and the refresh/retry/expire/minimum timers) should be stable.

nslookup -norecurse -type=SOA probe.isitdns.net pns2.isitdns.net

On a network that intercepts port 53 (captive portals, some home routers), a @server query is answered by the interceptor rather than the named server. If you see only rd ra flags without aa, that is your network, not pns2.

A NOERROR answer with a SOA record from the child proves the delegation is not lame. The aa (authoritative answer) flag in the header confirms pns2 is serving this zone itself, not forwarding to another server. If you got REFUSED instead, the child server does not know about the zone and every referral to it would dead-end.

Checking consistency: do the child apex NS records match the parent's delegation?

dig @pns2.isitdns.net probe.isitdns.net NS +norec

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
probe.isitdns.net.  5  IN  NS  pns2.isitdns.net.

Parent says pns2, child says pns2. They match. The child's apex NS set is the authoritative one: caches rank it above the parent's referral copy and replace the referral data with it once seen (RFC 2181 section 5.4.1). A mismatch means different resolvers converge on different NS sets (see Gotchas below).

What `dig +trace` shows#

dig +trace walks the full hierarchy from the root downward, exactly as a recursive resolver would. It prints each referral as it crosses a delegation boundary. The ;; Received line after each referral shows which server answered and how many bytes came back.

dig +trace isitdns.net

nslookup has no +trace equivalent. Use dig.

Gotchas#

Apex of the child must agree with the parent's delegation. If you delegate customers.example.com to ns1/ns2, the child zone's apex NS records must also list ns1/ns2. The child's authoritative set outranks the parent's copy in caches (RFC 2181 section 5.4.1), so with a mismatch, which NS set a resolver uses depends on what its cache has seen; diagnostic tools like DNSViz flag the inconsistency. The consistency check in the section above shows how to verify this yourself.
Lame delegation. An NS that does not actually serve the zone. Resolvers get a referral, contact the server, get REFUSED, fall back to the next NS: slow and brittle. Always verify each NS before relying on it:

dig @ns1.customers.example.com customers.example.com SOA +norec

A NOERROR answer with a SOA record means the NS is authoritative. REFUSED or SERVFAIL means lame.

TTL on the delegation matters. A long TTL on NS records means you cannot change them quickly. 3600 (1 h) is a reasonable default; lower it before a planned move.
Delegation in a split-horizon view. Delegating in one view does not delegate in other views. If you need the delegation visible everywhere, add it in every applicable view.
Do not delegate to yourself. If the same server holds both the parent and a sub-zone, the delegation in the parent is redundant: the server answers from the child zone regardless. The risk is operational: two zone objects with overlapping scope create confusion. Keep the sub-zone and omit the delegation, or delegate to a genuinely separate server.