skip to content

In DNS, how do you delegate the subdomain dev.example.com to another team's name servers, and what must each zone publish?

level: middleimportance: must knowfreq 45%

answer

  1. two sides of one cut
  2. parent: NS set owned by the child name
  3. child: its own SOA and apex NS
  4. referral with AA clear

basics

~20 s

The other team serves a dev.example.com zone with its own SOA and apex NS records; then the example.com zone adds an NS RRset for dev.example.com naming the same servers, plus glue only for servers named inside dev.example.com.

solid answer

~40 s

Delegation is two edits that must agree. First the other team stands up the `dev.example.com` zone on at least two servers, with its own `SOA` and an apex `NS` RRset listing them. Then, as RFC 1034 §4.2.2 puts it, "as the last installation step", the parent adds an `NS` RRset owned by `dev.example.com` to the `example.com` zone naming the same servers, plus address (glue) records only if a server's name falls inside `dev.example.com`. A resolver asking the parent's servers about `www.dev.example.com` now gets a **referral**: an empty answer section, the child's `NS` set in the authority section and `AA` clear. The parent-side `NS` records are not the parent's authoritative data, so both administrators must keep the two `NS` sets identical, and any old records the parent still holds below the cut stop being served.

code

dns · 12 lines
dns
; example.com zone (parent): the delegation
$ORIGIN example.com.
dev   3600 IN NS  ns1.example.net.
dev   3600 IN NS  ns2.example.net.

; dev.example.com zone (child): served by ns1/ns2.example.net
$ORIGIN dev.example.com.
@     3600 IN SOA ns1.example.net. hostmaster.dev.example.com. (
                  2026100101 7200 900 1209600 300 )
@     3600 IN NS  ns1.example.net.
@     3600 IN NS  ns2.example.net.
www   3600 IN A   198.51.100.10

go deeper

for a junior

Remember that delegating a subdomain means NS records in the parent zone naming the other team's servers, and a separate zone with its own SOA on those servers.

for a middle

Walk through both sides of the cut, the order of the steps, and the referral a resolver receives: empty answer, child NS set in authority, AA clear.

for a senior

Show the operational care: bring the child up and verify every listed server before touching the parent, keep the two NS sets identical, and clean occluded records out of the parent.

for a principal

Weigh when to delegate at all: a cut gives a team autonomy but adds servers, a second consistency surface, and a parent-side edit for every server change they make.

## What delegation actually is **Delegation** is creating a new zone beneath a name you control and handing authority for it to other servers. RFC 9499 defines it simply: delegation "happens when an NS RRset is added in the parent zone for the child origin", and it always happens at a **zone cut**. After the cut, the parent zone (`example.com`) no longer answers authoritatively for anything at or below `dev.example.com`; it only points to who does. A delegation therefore has two sides, and both must exist and agree: | Side | Zone | What it publishes | Authoritative? | |---|---|---|---| | Child | `dev.example.com` | one `SOA` and an `NS` RRset at the apex, plus all of its own records | yes | | Parent | `example.com` | an `NS` RRset owned by `dev.example.com`, plus glue if needed | no, the cut data belongs to the child | RFC 2181 §6.1 is explicit that "the NS records that indicate a zone cut are the property of the child zone". The parent serves them only to send resolvers on their way. ## The procedure, in order RFC 1034 §4.2.2 describes the administrative sequence, and the order is not arbitrary: 1. **Agree on the name and the servers.** The child team chooses at least two name servers; RFC 1034 asks new owners to "demonstrate redundant name server support". 2. **Build the child zone first.** Load `dev.example.com` on the primary with its `SOA`, its apex `NS` RRset and its data, and make sure every secondary has transferred it. 3. **Check each listed server.** Every server that will be named should answer a `SOA` query for `dev.example.com` authoritatively. 4. **Add the delegation to the parent last.** Insert the `NS` RRset for `dev.example.com` in `example.com`, add glue only for in-domain servers, and bump the parent's serial so its secondaries pick it up. Reversing steps 2 and 4 publishes a delegation to servers that do not yet serve the zone. That is a **lame delegation**, and resolvers that follow it get errors or silence until the child is ready. ## What a resolver sees at the cut A recursive resolver looking up `www.dev.example.com` that reaches a server for `example.com` receives a **referral** rather than an answer. RFC 9499 describes its shape: - the answer section is **empty**; - the authority section carries the **`NS` RRset for `dev.example.com`**; - the additional section may carry **glue** addresses; - the **`AA` bit is clear**, because the parent is not authoritative for the child's names. The resolver then asks one of the child's servers, which answers with `AA` set. Nothing in the child zone points back at the parent: RFC 2181 §6 notes that "a child zone does not contain any explicit reference to its parent". ## Keeping the two sides consistent RFC 1034 §4.2.1 says the parent's cut records "should be exactly the same as the corresponding RRs in the top node of the subzone", and §4.2.2 asks both administrators to "insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so". In practice they drift: - the child team adds or retires a server and updates only its own apex `NS` set; - the parent still lists a server that was decommissioned; - glue in the parent still carries an old address after a renumbering. Resolvers learn the parent's set from the referral and then see the child's own set from the child's servers. RFC 2181 §5.4.1 ranks authority-section data from an authoritative answer above the authority section of a non-authoritative referral, so a resolver that holds both prefers the child's. Implementations differ in exactly when they switch, which is why a mismatch shows up as inconsistent behaviour rather than a clean failure. ## What happens to data the parent still holds If `example.com` still contains, say, an `A` record for `app.dev.example.com` after the cut is added, that record is not served. RFC 2181 §6.1 says servers "should ignore data other than NS records, and necessary A records to locate the servers" at a cut, and RFC 9499, quoting RFC 5936, calls names left below an added delegation point **occluded**: still in the file, no longer reachable by lookups. Queries for them get the referral instead. Clean those records out so nobody mistakes them for live configuration.

  • If the parent's NS set for dev.example.com and the child's apex NS set differ, which one does a resolver use?
    It first uses the parent's set, because that is all the referral gives it. Once a child server answers, RFC 2181 §5.4.1 ranks the child's authoritative NS data above the referral's, so a resolver holding both prefers the child's. Exactly when it switches is implementation behaviour, which is why mismatched sets produce inconsistent, hard-to-reproduce results. Keep them identical.
  • Why should the parent add the delegation only after the child zone is live on every listed server?
    Because the moment the parent's NS records are published, resolvers start following them. If a listed server does not yet serve dev.example.com, the delegation is lame: that server answers with an error or not at all and the resolver must retry elsewhere. RFC 1034 §4.2.2 calls the parent-side NS and glue records the last installation step for this reason.

A building lobby's directory says which reception desk handles each floor, not who sits there. The lobby sends you to the floor's reception, which alone knows its occupants; if the directory lists a desk that closed, visitors get lost.

saying these in an interview costs you the question

  • Delegation is a CNAME from the subdomain to the other team's server.
  • The parent's NS records for the child are authoritative data of the parent.
  • The parent answers questions about names in the child zone with AA set.
  • Records left in the parent below the cut act as a fallback.
  • The child zone can skip its apex NS set because the parent lists the servers.