Operations

Reliability comes from disciplined changes and independent checks

A syntactically valid zone can still be operationally wrong. Good DNS operations verify parent delegation, child authority, signatures, reachability, transfer state and real resolver behaviour.

Deployment sequence

A safe authoritative-zone change

Edit the source of truth.
Change the unsigned source zone or managed record set; do not hand-edit generated signed output.
Validate syntax and semantics.
Run the authoritative server’s zone checker. Confirm absolute names, record constraints, TTLs and intended addresses.
Increment the SOA serial.
Use a monotonic scheme. Date-based serials are readable, but still require care when publishing more than 99 revisions in one day or rolling back.
Sign or refresh signatures.
Ensure inception and expiry windows are sensible and keys expected by the parent DS remain available.
Load the zone atomically.
Prefer a checker and reload mechanism that leaves the previous working zone active if the new version is rejected.
Notify and verify secondaries.
Confirm that each secondary has the new serial and serves the same DNSSEC material.
Test externally.
Query every authoritative server directly over UDP and TCP, then query independent validating resolvers.

Zone transfers

AXFR, IXFR, NOTIFY and TSIG solve different problems

AXFR transfers the complete zone. IXFR transfers differences when both peers retain suitable history. NOTIFY prompts a secondary to check sooner rather than waiting for the SOA refresh timer.

TSIG authenticates DNS transactions using a shared secret and message authentication code. It can authorise transfers and dynamic updates, but it does not encrypt zone contents. DNS Zone Transfer over TLS can add confidentiality.

Primary publishes serial 2026080302

NOTIFY

Secondary requests SOA

IXFR or AXFR + TSIG

Secondary serves new zone

Implementation example.

See NSD configuration and hardening for a complete primary/secondary configuration, a restrictive AppArmor profile and a systemd drop-in.

Monitoring

Test outcomes, not just processes

Authoritative reachability

Query every NS address directly using UDP and TCP from more than one network.

Serial convergence

Compare SOA serials across all authoritative servers and alert on prolonged mismatch.

DNSSEC validity

Track RRSIG expiry, DS/DNSKEY consistency and validation from external resolvers.

Resolver health

Watch latency, cache hit rate, SERVFAIL ratio, upstream timeouts and unwanted fallback.

Encrypted listeners

Monitor certificate validity, protocol negotiation, SNI and end-to-end query success.

Policy behaviour

Test both allowed and deliberately blocked names, including a documented bypass path.

Command toolbox

Small queries that answer precise questions

dig @ns1.example.net example.com SOA +norecurse

Does this server claim current authority, and which serial is loaded?

dig @ns1.example.net www.example.com A +tcp

Does the same authority work over TCP, which is required for robust DNS operation?

dig example.com DS +dnssec

What DS material does the parent publish?

dig @ns1.example.net example.com DNSKEY +dnssec

Does the child publish the key expected by the parent?

delv www.example.com A

Can a local validator build a complete chain to the answer?

kdig @resolver.example.net +tls-ca +tls-host=resolver.example.net example.com

Can the encrypted DNS endpoint be authenticated and used?

Time and DNSSEC

Correct time is part of the validation dependency chain

RRSIG records have inception and expiration times. Signing systems need correct time to create sensible windows, and validators need correct time to judge those windows.

A resilient host should establish time early, use multiple trustworthy sources, preserve reasonable RTC state where available and monitor offsets. A DNSSEC failure caused by a bad clock can look like a DNS outage even when packets and zone data are otherwise correct.

Avoid circular boot dependencies.

If secure time requires DNS, DNS validation requires secure time, and neither has a usable bootstrap path, recovery can stall. Define how the system obtains enough initial time and name resolution to break that cycle.

Change-management checklist

Before declaring success

Parent NS and glue are correct.
Every authority answers authoritatively.
UDP and TCP both work.
IPv4 and IPv6 paths are tested separately.
No public server offers open recursion.

Secondaries serve the current serial.
DS and DNSKEY match.
Signatures have comfortable remaining life.
Negative answers validate.
External resolvers see the intended result.