8. Zones and delegation

A zone is a file, or a database, that one operator edits and several servers serve. This chapter is the mechanics of that: how the copies stay in step, and how the delegation above them is maintained.

The SOA, field by field

Every zone has exactly one, at its apex, and each field controls something specific.

   example.com. 3600 IN SOA
     ns1.example.com.      ; MNAME
     admin.example.com.    ; RNAME
     2024061503            ; SERIAL
     7200                  ; REFRESH
     900                   ; RETRY
     1209600               ; EXPIRE
     300                   ; MINIMUM

   MNAME     the PRIMARY server's name. used
             by dynamic update to find where
             to send changes. otherwise
             informational.

   RNAME     the administrator's email, with
             the @ replaced by a dot.
             admin.example.com = admin@…

   SERIAL    a 32-bit number the secondaries
             compare. HIGHER MEANS NEWER,
             with wraparound arithmetic
             (RFC 1982).

   REFRESH   how often a secondary checks
             the serial, absent a NOTIFY.
             7200 = 2 h.

   RETRY     how soon to re-check after a
             failed check. always < REFRESH.

   EXPIRE    how long a secondary keeps
             serving a zone it cannot
             refresh. AFTER THIS IT STOPS
             ANSWERING ENTIRELY — SERVFAIL,
             not stale data.

   MINIMUM   the NEGATIVE cache TTL for this
             zone. nothing to do with
             minimum TTLs on records.

Caution

EXPIRE is the field with teeth. If your primary is unreachable for longer than EXPIRE, every secondary stops serving the zone and your domain disappears — not degraded, gone. Two weeks (1209600) is the conventional value and is sensible; shortening it to “fail fast” is one of the few DNS tuning ideas that can take you offline.

Serial number conventions

   DATE-BASED   2024061503
                YYYYMMDDnn — readable, and
                caps you at 100 changes a
                day. the traditional choice.

   UNIX TIME    1718452800
                never collides, never
                readable.

   COUNTER      1, 2, 3, …
                what every managed provider
                and every automated system
                actually uses.

dig +short example.com SOA | awk '{print $3}'
for ns in $(dig +short example.com NS); do
  echo -n "$ns "; dig +short @$ns example.com SOA | awk '{print $3}'
done

That loop is the single most useful zone-health check there is: every authoritative server should report the same serial. A disagreement means a transfer is failing, and it means different users are getting different answers right now.

Zone transfers

   AXFR — FULL TRANSFER
     over TCP. the entire zone, record by
     record, starting and ending with the
     SOA.
     simple, works everywhere, expensive
     for large zones.

   IXFR — INCREMENTAL TRANSFER
     "I have serial N; send me the
     difference." the primary replies with
     deletions and additions per version.
     falls back to AXFR if it cannot
     compute the delta.

dig @ns1.example.com example.com AXFR
dig @ns1.example.com example.com IXFR=2024061502
named-checkzone example.com db.example.com

   AXFR MUST BE RESTRICTED.

   AN OPEN AXFR HANDS AN ATTACKER YOUR
   ENTIRE INTERNAL NAMING: every host, every
   staging environment, every internal
   service name. it is a free
   reconnaissance gift and it is still
   found in the wild constantly.

   # BIND
   allow-transfer { 198.51.100.2; key xfer; };
   # Knot
   acl: [ { id: sec, address: 198.51.100.2,
            action: transfer } ]
   # NSD
   provide-xfr: 198.51.100.2 xfer_key

NOTIFY

   WITHOUT NOTIFY: a secondary learns about
   a change at the next REFRESH — up to two
   hours late.

   WITH NOTIFY: the primary sends a small
   UDP message to each secondary the moment
   the zone changes. the secondary then
   checks the serial and transfers.

   SO THE REAL PROPAGATION TIME BETWEEN YOUR
   OWN SERVERS IS SECONDS, AND `REFRESH` IS
   A FALLBACK FOR WHEN NOTIFY IS LOST.

rndc notify example.com
grep -i notify /var/log/named/named.log | tail
knotc zone-notify example.com

TSIG, and authenticating the transfer

   TSIG (RFC 8945): A SHARED SECRET AND AN
   HMAC OVER THE MESSAGE, IN AN EXTRA
   RECORD.

   USED FOR
     − authorising AXFR/IXFR
     − authorising dynamic updates
     − authenticating NOTIFY

   NOT used for normal queries — it is a
   point-to-point mechanism between servers
   you control, not an end-to-end one.
   that is DNSSEC's job.

tsig-keygen -a hmac-sha256 xfer > /etc/bind/xfer.key
dig @ns1.example.com -y "hmac-sha256:xfer:BASE64==" example.com AXFR
nsupdate -k /etc/bind/xfer.key

   TSIG ALSO SIGNS A TIMESTAMP, SO CLOCK
   SKEW BREAKS IT. the default fudge is 300
   seconds; a server whose NTP has failed
   stops being able to transfer, and the
   error says BADTIME rather than anything
   about clocks.

Dynamic updates

   RFC 2136: CHANGE A ZONE WITH A DNS
   MESSAGE RATHER THAN BY EDITING A FILE.

   nsupdate -k key.conf
   > server ns1.example.com
   > zone example.com
   > update delete old.example.com A
   > update add new.example.com 300 A 192.0.2.9
   > send

   WHO USES IT

   DHCP servers registering leases
   Active Directory, constantly
   certbot's dns-01 plugins
   external-dns in Kubernetes
   Consul and etcd integrations, sometimes

   AND IT IS WHY MOST MANAGED PROVIDERS
   OFFER AN HTTP API INSTEAD: RFC 2136 is
   fiddly, needs TSIG, and does not map
   onto web authentication at all.

The practical choice in 2026 is usually between RFC 2136 against your own servers and a provider’s REST API. Anything automated — ACME DNS-01, external-dns, Terraform — will support both, and the provider API is almost always the lower-friction path.

Keeping the parent and child in step

This is where zones break, and the failure is always the same shape.

   THE DELEGATION LIVES IN TWO PLACES

   AT THE REGISTRY (the parent zone)
     example.com. NS ns1.example.com.
     example.com. NS ns2.example.com.
     ns1.example.com. A 192.0.2.1   ← glue
     ns2.example.com. A 198.51.100.1 ← glue
     example.com. DS …               ← DNSSEC

   IN YOUR OWN ZONE (the child)
     example.com. NS ns1.example.com.
     example.com. NS ns2.example.com.
     ns1.example.com. A 192.0.2.1
     ns2.example.com. A 198.51.100.1

# the parent's view
dig +norecurse @a.gtld-servers.net example.com NS
# the child's view
dig +norecurse @ns1.example.com example.com NS
# compare them. they should be identical.

   THE THREE CLASSIC MISMATCHES

   1. A DECOMMISSIONED NAMESERVER LEFT AT
      THE REGISTRAR.
      works until a resolver refreshes from
      the parent and picks it. then
      intermittent SERVFAIL for a third of
      users.

   2. GLUE NOT UPDATED AFTER AN IP CHANGE.
      the zone says the new address; the
      parent hands out the old one. a
      resolver with cold cache cannot reach
      you at all.

   3. A DS RECORD AT THE PARENT WITH NO
      MATCHING DNSKEY IN THE CHILD.
      every validating resolver returns
      SERVFAIL. total outage for ~30% of
      the internet. chapter 9.

Note

Register these checks, do not remember them. delv, dnsviz, Zonemaster and dig +trace all compare parent and child automatically, and a weekly automated run catches the latent cases before a resolver does.

delv example.com @8.8.8.8
dnsviz probe example.com | dnsviz print
# or the hosted version: zonemaster.net, dnsviz.net

Zone file syntax, briefly

Even if you never run BIND, zone-file syntax is the lingua franca: it is what dig prints, what every tool imports and exports, and what documentation uses.

   $ORIGIN example.com.
   $TTL 3600

   @   IN SOA ns1.example.com. admin.example.com. (
               2024061503 7200 900 1209600 300 )
       IN NS  ns1.example.com.
       IN NS  ns2.example.com.
       IN MX  10 mail.example.com.
       IN A   192.0.2.1
       IN TXT "v=spf1 include:_spf.example.net -all"

   ns1 IN A   192.0.2.1
   ns2 IN A   198.51.100.1
   www 300 IN CNAME cdn.example.net.
   *   IN A   192.0.2.99

   THE RULES WORTH KNOWING

   @          the current $ORIGIN
   a blank
   owner name repeats the PREVIOUS owner
   no trailing
   dot        $ORIGIN is appended
   $TTL       the default for records with
              no explicit TTL
   ( )        continues a record across
              lines
   ;          comment

named-checkzone example.com db.example.com
dig @ns1.example.com example.com AXFR > exported.zone
kzonecheck db.example.com

The blank-owner-name rule is responsible for a specific class of error: insert a record in the middle of a block and the records below it silently change owner. Running named-checkzone after every edit catches it, and it is cheap enough to put in a pre-commit hook.

CDS, CDNSKEY and automated DS updates

   THE PROBLEM: THE DS LIVES AT THE
   REGISTRAR, AND CHANGING IT USUALLY MEANS
   A HUMAN IN A WEB FORM.

   RFC 7344 / 8078: THE CHILD PUBLISHES
   WHAT IT WANTS.

   example.com. CDS     12345 13 2 ABCD…
   example.com. CDNSKEY 257 3 13 MIIB…

   the PARENT polls for these, validates
   them against the CURRENT chain, and
   updates the DS automatically.

dig +short example.com CDS
dig +short example.com CDNSKEY
rndc dnssec -checkds published example.com

Support is the limiting factor: most ccTLDs and several large registrars honour CDS, and many do not. It is worth checking before choosing a registrar, because automated key rollover is the difference between DNSSEC being routine and DNSSEC being a quarterly risk.

Multiple providers

   TWO INDEPENDENT DNS PROVIDERS, BOTH
   AUTHORITATIVE, LISTED TOGETHER IN THE
   NS SET.

   example.com. NS ns1.provider-a.net.
   example.com. NS ns2.provider-a.net.
   example.com. NS ns1.provider-b.net.
   example.com. NS ns2.provider-b.net.

   WHY: a provider-wide outage stops being
   a total outage. resolvers try the others.

   WHAT IT COSTS
     − both must serve IDENTICAL data, so
       you need a single source of truth
       and automation (octodns, dnscontrol,
       Terraform)
     − DNSSEC across providers requires
       either shared keys or the
       multi-signer model (RFC 8901), which
       is genuinely hard
     − provider-specific records (ALIAS,
       geo-routing) often cannot be
       mirrored

The 2016 Dyn attack is the canonical argument for this: a single provider’s outage removed a large fraction of well-known sites from the internet, and the ones with a second provider stayed up. The counter-argument is operational complexity, and it is real — which is why octodns and dnscontrol exist and why multi-provider setups almost always drop DNSSEC or use a single signer.

What to take from this chapter

• The SOA has seven fields, each controlling something real. MINIMUM is the negative cache TTL, not a floor on record TTLs.
• EXPIRE has teeth: if secondaries cannot refresh for that long, they stop serving the zone entirely. Two weeks is conventional and sensible; shortening it can take you offline.
• Every authoritative server must report the same serial. A one-line loop over the NS set is the single most useful zone-health check there is.
• AXFR is a full transfer, IXFR a delta. An open AXFR hands out your complete internal naming, and it is still found in the wild constantly — restrict it.
• NOTIFY makes inter-server propagation seconds rather than hours; REFRESH is only the fallback for a lost notify.
• TSIG authenticates server-to-server operations — transfers, notifies, dynamic updates — and is point-to-point, not end-to-end. It signs a timestamp, so failed NTP breaks it with a BADTIME error that mentions nothing about clocks.
• RFC 2136 dynamic update is what DHCP, Active Directory and ACME plugins use; managed providers offer REST APIs instead because 2136 needs TSIG and does not fit web auth.
• The delegation exists in two places, and the three classic mismatches are a decommissioned nameserver left at the registrar, stale glue after an IP change, and a DS record with no matching DNSKEY — the last of which is a total outage for every validating resolver.
• Automate the parent/child comparison with delv, dnsviz or Zonemaster rather than remembering to check.
• Two independent providers turn a provider outage into a non-event, at the cost of a single source of truth, cross-provider DNSSEC difficulty, and losing provider-specific record types.

Next: DNSSEC — what it actually signs, the chain of trust, why it is hard to operate, and the failure mode that takes domains offline.