is it dns? / wiki ← back to the live monitor

🗂️ Zones: the four types you'll actually use

A DNS zone is a slice of the namespace that one set of servers is responsible for. There are four kinds you'll see in practice, and they exist for different reasons. This page is the one-paragraph overview; each type has its own lesson.

The four#

TypeWhat it doesUse when
AuthoritativeServer owns the zone: answers with aa=1You publish records for this name (example.com, internal services, anything you control)
ForwardServer hands queries for this name to a different upstreamYou want lookups for internal.partner.example to go to their DNS, not yours
Delegated (child)Server points downstream: "go ask that nameserver"You hand a sub-zone off to another team / appliance with its own NS
StubServer keeps a minimal copy of another zone's NS and SOA records: a caching shortcut, not a served zoneYou want fast resolution into another zone without becoming a real secondary

Plus the cross-cutting concern that touches all of them:

TopicWhy
Zone transfer: AXFR/IXFR/SOAHow a zone's data moves between servers, and how you watch it happen on the wire and in logs

One refinement that trips people up: an authoritative zone is served in two roles, primary (holds the editable copy) and secondary (pulls a read-only copy from the primary). Both answer with aa=1; the role split and how data moves between them is the transfer lesson.

The decision tree#

You have a name to answer for.
   |
   +-- You own the records?
   |       |
   |       +-- Yes  -> Authoritative zone
   |       +-- No, but you know who does
   |                |
   |                +-- Want clients to land directly on them?
   |                |        Yes -> Delegated zone
   |                |                (they become authoritative; you publish NS
   |                |                 in the parent zone, which you must own)
   |                |
   |                +-- Want your resolver to ask them, then cache the answer?
   |                         -> Forward zone
   |
   +-- You just want your resolver to know another zone's NS directly,
       but not to own or serve it?
           -> Stub zone

Why this distinction matters#

Each zone type creates a different signature on the wire and a different ACL surface:

Typeaa flag on responsesWho can read this data
Authaa=1 for the names in the zoneAnyone who can query the server (subject to ACLs)
Forwardaa=0: the server is acting as a recursive proxy for this zoneThe upstream's ACL applies once the forward happens
DelegatedThe parent returns a referral, not an answer, and the referral itself carries aa=0; the child's servers answer with aa=1Child's ACL
Stubaa=0 to the client: the stub is internal resolver state, the resolver queries the authoritative directly (skipping the full hierarchy walk) and relays the answer. No referral is exposed to the client.The authoritative zone's ACL applies to the resolver's direct queries

Get the zone type wrong and you can accidentally:

  • Leak internal records publicly (auth where you wanted forward)
  • Black-hole queries silently (delegated to a server that's down)
  • Create a recursion loop (forward → forward → forward)
  • Miss a serial bump that never propagates (stub stale, see transfer)

See also#