🖥️Module 05 — Running an Authoritative Server (BIND 9)

BIND 9.18.39-0ubuntu0.24.04.5-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.18.5 #1 SMP PREEMPT_DYNAMIC

/usr/sbin/named
/usr/sbin/rndc
/usr/sbin/rndc-confgen
/usr/sbin/tsig-keygen
/usr/bin/named-checkconf
/usr/bin/named-checkzone

Six binaries, and you will use every one of them in this module. Installing BIND gives you a toolchain, not just a daemon — and named-checkconf, named-checkzone and tsig-keygen are useful even on machines that never run a nameserver.

Note "Extended Support Version". BIND ships in two tracks: stable ESV releases with long support, and feature releases that move faster. On anything you have to operate, run the ESV — DNS is infrastructure, and infrastructure wants boring.

If named is missing but dig works, you installed only bind9-dnsutils back in Module 01. The client tools and the server are separate packages, which catches people out.

bad1.conf:5: missing ';' before 'listen-on-v6'

bad2.conf:15: 'primaryy' unexpected

zone lab.internal/IN: loading from master file /tmp/lab/p/missing.db failed: file not found
zone lab.internal/IN: not loaded due to errors.
_default/lab.internal/IN: file not found

Error 1 points at line 5 and names the line after the mistake. That is normal for a recursive-descent parser: it reads on until something does not fit. When named-checkconf blames a line, look at the line above it too — this one habit saves a surprising amount of time.

Error 2 is precise because primaryy is not a keyword at all.

Error 3 is the important one, and it needed -z. Plain named-checkconf only parses the configuration; it does not open the zone files. A config pointing at a nonexistent, unreadable or invalid zone file passes cleanly.

So the rule is: always named-checkconf -z. It loads every zone as named would. Without it you get a green light from the syntax checker and a server that starts up refusing to answer for the very zone it exists to serve — which is Module 03's lame delegation, self-inflicted.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50756
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 397d8dbd9fb4f662010000006a8674409ff7f1ea4829c8d0 (good)
;; ANSWER SECTION:
lab.internal.	300	IN	SOA	ns1.lab.internal. hostmaster.lab.internal. 2026081701 7200 900 1209600 300

api.lab.internal.	300	IN	A	192.0.2.30
api.lab.internal.	300	IN	A	192.0.2.31

www.lab.internal.	300	IN	CNAME	lab.internal.
lab.internal.		300	IN	A	192.0.2.20

Four things in that header, and you have met every one of them before.

aa is set. Your server holds the zone, so it marks the answer authoritative — the flag you have been using since Module 01 to tell ground truth from cache.

ra is absent, and dig warns you about it. ;; WARNING: recursion requested but not available is recursion no; working exactly as intended. This is a healthy authoritative server, not a broken one — that warning line is what a correctly configured nameserver looks like.

COOKIE: ... (good) is a DNS cookie, an EDNS option from Module 04 C2. BIND 9.18 does it automatically: a shared token that makes off-path spoofing considerably harder, with no configuration from you.

And the TTLs are the full 300, not counted down, because nothing here is a cache. Full TTL plus aa — the signature of an authoritative answer, exactly as promised in Module 01 C5.

api returned both addresses as one RRset with a shared TTL, and www returned the CNAME plus the resolved target — Module 02 A1 and B2, now coming out of a server you configured.

named-checkconf parses named.conf — syntax and structure. named-checkzone parses a zone file and reports errors and warnings in the records.

The detail that matters far more than the definition: plain named-checkconf does not open the zone files. A configuration pointing at a missing, unreadable or broken zone file passes cleanly, and then named starts and refuses to answer for that zone.

So the command to actually run is named-checkconf -z, which loads every zone as the server would. That single flag is the difference between a pre-flight check and a false sense of security — and I would put it in CI rather than trusting anyone to remember it.

recursion no;

One binary does both jobs, and an authoritative server that also recurses for the world is an open resolver — it lets strangers consume your capacity and, far worse, makes you a reflector and amplifier for attacks on other people, since a small forged query produces a large response to a victim.

What I would add to show it is a design principle rather than a checklist item: the two roles have opposite requirements. An authoritative server needs to be reachable by everyone and to answer only about its own zones. A resolver needs to answer anything but only for a known client set. Trying to satisfy both on one address is why the failure keeps recurring, which is why the right answer is separate servers or at minimum separate addresses.

$ rndc -c /tmp/lab/rndc.conf status
version: BIND 9.18.39-0ubuntu0.24.04.5-Ubuntu (Extended Support Version) <id:>
running on localhost: Linux x86_64 6.18.5 #1 SMP PREEMPT_DYNAMIC
boot time: Thu, 20 Aug 2026 03:29:12 GMT
last configured: Thu, 20 Aug 2026 03:29:13 GMT
configuration file: /tmp/lab/p/named.conf
CPUs found: 2
worker threads: 2
UDP listeners per interface: 2
number of zones: 2 (0 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF

$ rndc -c /tmp/lab/rndc.conf zonestatus lab.internal
name: lab.internal
type: primary
files: /tmp/lab/p/zone.db
serial: 2026081702
nodes: 5
last loaded: Thu, 20 Aug 2026 03:29:33 GMT
secure: no
dynamic: no

status gives you four things worth knowing in an incident:

• last configured — if it is older than your last change, your change never loaded. This one line settles the most common "but I edited the file" argument
• xfers running / xfers deferred — deferred transfers piling up means secondaries are struggling and you are about to have out-of-sync servers
• number of zones — 2 here: your zone plus the built-in bind chaos zone
• query logging is OFF — the switch you will want in B3

zonestatus is the per-zone version and serial is the field to read. It is the number a secondary compares against, and Part C is about what happens when it does not change.

secure: no means the zone is not DNSSEC-signed. Module 07 turns that to yes.

zone lab.internal/IN: Transfer started.
transfer of 'lab.internal/IN' from 127.0.0.1#5301: connected using 127.0.0.1#5301
zone lab.internal/IN: transferred serial 2026081701
transfer of 'lab.internal/IN' from 127.0.0.1#5301: Transfer status: success
transfer of 'lab.internal/IN' from 127.0.0.1#5301: Transfer completed: 1 messages, 10 records, 332 bytes, 0.001 secs
zone lab.internal/IN: sending notifies (serial 2026081701)

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32294
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
lab.internal.	300	IN	SOA	ns1.lab.internal. hostmaster.lab.internal. 2026081701 7200 900 1209600 300

The secondary now answers with aa set. It never read your zone file; it fetched the zone over the network and is serving it as authoritatively as the primary.

Three details in the log worth naming. 10 records — the whole zone, not a delta, because the secondary had nothing. 1 messages — the entire transfer fitted in one TCP message. And the secondary immediately sends notifies of its own, because it in turn could have secondaries beneath it.

And this is Module 04 B1 made concrete: 332 bytes in one TCP stream. A real zone with thousands of records is hundreds of kilobytes. There has never been a version of DNS where that could travel over UDP — which is why "TCP for zone transfers" is the one TCP answer everybody remembers.

=== baseline: do they agree? ===
primary   192.0.2.20
secondary 192.0.2.20

=== edit the record, do NOT touch the serial, reload ===
zone reload queued

primary   192.0.2.99   <- new value
secondary 192.0.2.20   <- STILL THE OLD VALUE

primary serial   2026081701
secondary serial 2026081701

There it is. Two authoritative servers for one zone, giving two different answers, and both reporting the same serial.

Read the last two lines carefully, because they are the whole diagnosis. The serials are identical — so from the secondary's point of view there is nothing to do. It checked, saw no change, and correctly did nothing. The secondary is not broken. It is behaving exactly as specified.

Note also that rndc reload reported success and the primary genuinely did reload. Every component reported success. The only evidence anything is wrong is that the two servers disagree — and nothing in the system is looking for that.

This is why "same serial, different data" is the signature to memorise. If two authoritative servers report the same serial but return different records, somebody edited a zone file without bumping the serial. It is not a network problem, not a cache, not a delegation issue.

Now imagine this at 500 hosts. Four nameservers in the delegation, one edited without a serial bump. Twenty-five per cent of cold lookups get the old address. The application team sees a 25% error rate with no pattern, the network team sees healthy DNS servers, and nobody looks at serials because everything is "up".

The fix, and the discipline that prevents it:

sed -i 's|2026081701 ; serial|2026081702 ; serial|' p/zone.db
rndc -c /tmp/lab/rndc.conf reload lab.internal

Then both servers return 192.0.2.99. Never edit a zone file by hand without a mechanical step that bumps the serial — a Makefile, a pre-commit hook, or generation from a template. Human memory is not a suitable mechanism, which is what every DNS-in-Git workflow exists to prove.

</callout>

$ dig @127.0.0.1 -p 5301 lab.internal AXFR +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 39795
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

$ dig @127.0.0.1 -p 5301 lab.internal AXFR -y "hmac-sha256:xfer-key:..." +noall +answer
lab.internal.		300	IN	SOA	ns1.lab.internal. hostmaster.lab.internal. 2026081702 7200 900 1209600 300
lab.internal.		300	IN	NS	ns1.lab.internal.
lab.internal.		300	IN	NS	ns2.lab.internal.
lab.internal.		300	IN	A	192.0.2.99
api.lab.internal.	300	IN	A	192.0.2.30
api.lab.internal.	300	IN	A	192.0.2.31
ns1.lab.internal.	300	IN	A	127.0.0.1
ns2.lab.internal.	300	IN	A	127.0.0.1
www.lab.internal.	300	IN	CNAME	lab.internal.
lab.internal.		300	IN	SOA	ns1.lab.internal. hostmaster.lab.internal. 2026081702 7200 900 1209600 300

The first is status: REFUSED — the exact code you got from a.iana-servers.net in Module 02 D3.1. Now you have seen it from the other side: it is allow-transfer doing its job. REFUSED means policy, and here you are the policy.

The second is the entire zone, and note what it starts and ends with: the SOA, twice. That is not a duplicate — it is how AXFR delimits itself. The trailing SOA is the end-of-transfer marker.

This is the open-AXFR finding from Module 02 D3, seen from the server side. A zone with allow-transfer { any; } hands that entire list to anyone who asks: every internal hostname, every staging system, every management interface. The correct setting is a key, not an address list — addresses are forgeable and cloud secondaries change theirs.

One practical warning about TSIG: it is time-sensitive. The HMAC covers a timestamp, and BIND rejects signatures outside a small window — by default five minutes. Clock skew between primary and secondary breaks zone transfers with a TSIG error and nothing else obviously wrong. If transfers fail with a clean key on both sides, check NTP before you check anything else.

And obviously: that secret is a credential. It authenticates a full zone dump. Never commit it to Git in the clear, and rotate it when people leave.

AXFR transfers the whole zone; IXFR transfers only the changes since the secondary's current serial. Both run over TCP, since neither fits in a datagram, and IXFR falls back to AXFR if the primary cannot compute a delta — commonly after a restart or a hand-edited zone file.

Why it matters at scale rather than in a lab: on a zone with hundreds of thousands of records, AXFR on every small change is expensive in bandwidth and in load on the primary, and it lengthens the window in which secondaries disagree. IXFR turns a two-record change into a two-record transfer.

The practical caveat worth adding: IXFR requires the primary to keep a journal of changes, so hand-editing the zone file and reloading typically forces a full AXFR anyway — which is one of the arguments for dynamic updates over file editing on large zones.

Almost always: the serial was not incremented. A secondary compares serials, not data — so if the number did not change, it correctly concludes there is nothing to do. The signature is two authoritative servers reporting the same serial while returning different records.

Other causes: NOTIFY not reaching the secondary because it is not in the zone's NS records and not in also-notify; allow-transfer or TSIG rejecting the transfer; or clock skew breaking the TSIG signature.

The detail that separates a strong answer: pointing out that this is not an outage. Both servers are healthy and in rotation, so a fraction of live traffic gets the wrong answer at random and it never reproduces on demand. And the real fix is not "remember to bump the serial" — it is to make the bump mechanical: generate the zone, or use a pre-commit hook. Human memory is not a control.

allow-transfer restricted to a TSIG key rather than an address list, with a global allow-transfer { none; } default and per-zone exceptions. TSIG signs each message with a shared HMAC key, so it survives NAT and changing secondary addresses in a way that IP-based ACLs do not.

Two things worth adding. First, the reason it matters: an open AXFR returns your entire zone to anyone who asks — every internal hostname, staging system and management interface — which is a decades-old audit finding that still appears, almost always on a forgotten secondary rather than the primary. Second, TSIG is time-sensitive: the signature covers a timestamp with a five-minute default window, so clock skew silently breaks zone transfers and NTP is the first thing to check when a correct key stops working.

1–3. The build. Primary named.conf needs recursion no; and allow-transfer { none; }; in options, with allow-transfer { key xfer-key; }; on the zone. Proof of requirement 1 is in the query output, not the config:

;; flags: qr aa rd;
;; WARNING: recursion requested but not available

ra absent and that warning line is the proof. Requirement 3's proof is aa present in the secondary's answers plus a Transfer status: success line in its log.

4. NOTIFY, via also-notify { 127.0.0.1 port 5402; }; notify explicit;. The default was not enough because named notifies the servers in the zone's NS records — and those point at port 53, where nothing in this lab is listening. Without it the secondary would wait out REFRESH, two hours.

5. The evidence is the serial comparison, not the record.

primary   192.0.2.99      primary serial   2026081701
secondary 192.0.2.20      secondary serial 2026081701

Identical serials with different data. That one line pair identifies the cause completely: the secondary compared serials, saw no change, and correctly did nothing. Anyone who reports "the secondary is broken" has not read it — the secondary is the only component behaving exactly as specified.

6. The fix is sed the serial and rndc reload. The command that would have caught it:

for s in 5401 5402; do dig @127.0.0.1 -p $s capstone.internal SOA +short | awk '{print $3}'; done | sort -u | wc -l

Any answer other than 1 is a divergence. One line, cheap enough to run on every change and in monitoring — and it catches serial mistakes, failed transfers and expired zones with the same test.

7. status: REFUSED. It is RCODE 5 — policy, not failure. The server understood the request perfectly and declined it, exactly as Module 01 D3 defined and exactly what a.iana-servers.net returned in Module 02. Nothing is broken; you are simply not on the list.

8. Skew the clock, not the key. TSIG signs a timestamp and BIND rejects signatures outside a five-minute window, so:

sudo date -s "+10 minutes"     # on one host only

breaks every transfer while both configurations remain perfectly correct. In production you diagnose it by the log message — a TSIG error or clocks are unsynchronized rather than BADKEY — and by comparing date on both hosts. The instinct to check NTP before re-checking a key that has not changed is what distinguishes someone who has met this before.

The five things most people miss:

1. Proving requirement 1 from query output rather than the config file. "I wrote recursion no" is not evidence; the absent ra flag is
2. Explaining why the NOTIFY default failed in requirement 4. The mechanism — notifies go to the NS set — is the answer, not the workaround
3. Naming the serial comparison as the evidence in requirement 5, rather than the differing A record. The A record is the symptom; the matching serials are the diagnosis
4. Giving a check that runs unattended in requirement 6. "Remember to bump the serial" is not a control
5. Requirement 8 at all. Almost everyone breaks the key. Clock skew is the failure that actually happens in production, because keys are configured once and clocks drift daily

recursion no;

Without it, the same binary will happily resolve arbitrary names for anyone who asks — an open resolver. That lets strangers consume your capacity and, far worse, makes you a reflector and amplifier: a small forged query produces a large response aimed at a victim.

It is the first line of an authoritative configuration, not a hardening step to get to later.

It parses named.conf only — it never opens the zone files. A configuration pointing at a missing, unreadable or invalid zone file passes cleanly, and then named starts and refuses to answer for that zone.

named-checkconf -z loads every zone as the server would. That flag is the difference between a pre-flight check and false confidence, and it belongs in CI rather than in someone's memory.

One number: the primary's SOA serial, compared with its own. It transfers only if the primary's is higher. It does not compare records, file timestamps or checksums.

Which is exactly why forgetting to bump the serial produces silent divergence rather than an error — the secondary is doing precisely what it was told.

Someone edited the zone file on the primary and did not increment the serial. The primary reloaded and serves new data; the secondary compared serials, saw no change, and correctly did nothing.

Same serial + different data is the signature. It is not caching, not delegation, not a network problem — and the secondary is not broken.

Because resolvers spread queries across all the nameservers in the delegation, all the time. There is no primary-preferred behaviour and a secondary is not a spare.

A dead server produces retries and a small latency penalty. A stale one answers confidently with the wrong data for its share of live traffic — so a quarter of users get the old address at random, and it never reproduces on demand.

AXFR sends the whole zone; IXFR sends only the changes since the secondary's serial. Both use TCP.

IXFR falls back to AXFR whenever the primary cannot compute a delta — commonly after a restart, or after the zone file was hand-edited rather than changed through a journal-aware mechanism like dynamic update.

At scale IXFR matters: it turns a two-record change on a large zone into a two-record transfer instead of hundreds of kilobytes.

A hint that the zone changed — no records, no data. The secondary responds by doing what it always does: query the primary for its SOA, compare serials, and transfer only if higher.

That is what makes it safe: a forged NOTIFY cannot inject anything. The worst outcome is an extra SOA query, because the secondary verifies everything for itself.

Default targets are the servers in the zone's NS records; anything else needs also-notify.

Source addresses are forgeable, and cloud secondaries change addresses. TSIG authenticates the message with a shared HMAC key, so it survives NAT, renumbering and address spoofing.

It also fails safely: a wrong or missing key gets REFUSED rather than a partial transfer.

The operational catch is the time window — signatures cover a timestamp and expire in about five minutes, so clock skew breaks transfers with a perfectly correct key, and NTP is the first thing to check.

reload re-reads named.conf and the zone files. reconfig re-reads named.conf and picks up added or removed zones only — it does not re-read an unchanged zone statement's file.

It bites when you edit a zone file, run reconfig because it sounds safer, see no change, and go looking for the problem somewhere else. reload <zone> is the everyday command.

A cross-server serial comparison: query every authoritative server for the zone's SOA and alert if the serials are not all equal. It catches missed serial bumps, failed transfers, and expired zones with one cheap check.

Alongside it: that every delegated server answers with aa set — the lame-delegation test from Module 03 — and that the parent's delegation matches the child's NS set.

What I would not alert on is any single server being briefly behind. Transfers take a moment; the alert should fire on sustained divergence, not on the propagation window.

Every command, configuration file, log line and error message in this module was run for real on 20 August 2026: two named 9.18.39 processes on 127.0.0.1 ports 5301 and 5302, with a TSIG-authenticated transfer between them. The named-checkconf errors, the REFUSED on the unauthenticated AXFR, the transfer log, and the serial-divergence in C3.1 are all captured output, not reconstructions.

Specifications verified directly: RFC 1035, RFC 1912, RFC 1982, RFC 1995, RFC 1996, RFC 5936, RFC 8945, plus the BIND 9 ARM.

Question selection cross-referenced against publicly published 2026 DNS and networking interview question sets:

• Top 25 DNS Interview Questions and Answers for 2026 — nitizsharma.com — zones and zone files, SOA and serial numbers, DNS forwarding, query logging
• Interview Questions & Answers for DNS — DevOpsSchool — "What is a zone? What types of zones are there?" verbatim
• Top 30 Most Common DNS Interview Questions — Verve AI — nameservers, zones and zone files; DNS security best practices
• 75+ Network Engineer Interview Questions for 2026 — Taggd

Answers were rewritten and deepened rather than reproduced. Published sets define primary and secondary and stop; they rarely mention that a secondary is in live rotation rather than standby, that the serial is the only thing compared, or that TSIG clock skew is the failure mode you will actually meet — and those are the parts that come up once an interviewer has run a nameserver themselves.