Zones

Delegated zones

Asks the parent zone where a child zone is delegated.

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

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> -4 @coleman.ns.cloudflare.com probe.isitdns.net NS +norecurse

; (3 servers found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50623

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

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; 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

;; Query time: 32 msec

;; SERVER: 172.64.35.64#53(coleman.ns.cloudflare.com) (UDP)

;; WHEN: Mon Sep 14 17:52:09 CDT 2026

;; MSG SIZE rcvd: 81

GO no aa, no answer, and the child nameservers in the authority section

NO GO an answer with aa, which means there is no delegation and it is one zone

what each part of this output means →

What it is#

The parent zone publishes an NS record set at the child name, naming the child's nameservers; RFC 1034 section 4.2.1 states these are not part of the parent's own authoritative data, which is why the answer comes back as a referral (empty ANSWER, the NS set in AUTHORITY, no aa flag) rather than an ordinary answer.

If an NS name lives inside the delegated zone (in-domain, RFC 9499 section 7), the parent must also publish glue: A/AAAA records for that name, riding in the ADDITIONAL section, or a resolver has no way to fetch the address (RFC 9471 section 3.1, MUST). A sibling domain nameserver, one that lives elsewhere in the parent's own zone, gets the same courtesy but it is optional (RFC 9471 section 3.2, SHOULD). A nameserver in an unrelated zone gets no glue at all; a resolver looks it up the normal way.

If the child zone is DNSSEC-signed, the parent also carries a DS record at the child's name, crossing the chain of trust to the child's key (dnssec).

The child runs its own authoritative server; the parent stops answering for names under it.

When to use it#

A sub-team or sub-product owns the namespace and runs its own auth servers.
Lab or pre-prod separation: delegate lab.example.com so prod is not on the hook for lab churn.
A reverse-zone sub-delegation: RFC 2317 classless reverse delegation is this pattern applied to in-addr.arpa. See Reverse DNS: in-addr.arpa and ip6.arpa.
A geo or capability split (eu.example.com to a regional cluster), or a customer-owned subdomain pointed at their own DNS.

When not to use it#

To send queries elsewhere without changing what the world sees: use forward.
If you already own the records: keep them in auth.

Gotchas#

Apex mismatch. The child zone's own apex NS records must list the same nameservers the parent delegates to. The child's set outranks the parent's cached copy in caches (RFC 2181 section 5.4.1), so a mismatch means different resolvers land on different NS sets depending on what each one's cache has already seen. Check it by querying the parent and the child and comparing.
Lame delegation. An NS listed in the delegation that does not actually serve the zone. A resolver follows the referral, asks that server, gets no authoritative answer (RFC 9499 section 7), and falls back to the next NS: slow and brittle. check-a-delegation covers verifying each listed server.
A long NS TTL slows a change. The TTL on the delegation's NS records is how long a stale set keeps being used after you change it (RFC 1035 section 3.2.1); lower it ahead of a planned nameserver move.
Split-horizon views delegate independently. Adding a delegation in one view does not add it in another. See split-horizon.
Delegate even to yourself. A server holding both zones answers from the child, but a zone cut exists only where the parent has NS records (RFC 2181 section 6): a parent server without the child answers from the parent, and under a parent signed without opt-out the child's answers fail validation.