Networking & DNS / Security / System Administration

Build a BIND 9 authoritative DNS service with DNSSEC

Publish a public zone from a recursion-disabled BIND 9 primary, transfer it only to approved secondaries, sign it with an explicit DNSSEC policy, submit the DS record to the parent, and prove delegation over UDP and TCP from outside the network.

150 min13 stepsHigh-impact changeRevision 2

Save or explore

#bind9 #authoritative-dns #dnssec #delegation #glue #zone-transfer

0 of 13 steps completed

Goal

Operate an authoritative-only DNS service whose zone serials, apex records, glue, transfers, DNSSEC keys, parent DS, firewall, and external answers form one coherent and recoverable chain.

Supported environments

Ubuntu Server 24.04 LTS
BIND 9 9.18.x
DNSSEC RFC 4033–4035, RFC 5011

Prerequisites

Registered public zone and registrar access Control {{zoneName}} at its parent and be able to create or replace NS, address glue, and DS records. Export the current parent delegation before changing it.
Two independent authoritative endpoints Provide stable public IPv4 and, when genuinely routed, IPv6 addresses for {{primaryNs}} and {{secondaryNs}} on separate failure domains. This guide configures the primary and assumes the secondary has an owned transfer procedure.
Out-of-band recovery and configuration backup Keep console access and an encrypted backup of /etc/bind, /var/lib/bind, DNSSEC keys, registrar delegation, and the last known-good unsigned zone before enabling signing.
Network path Permit inbound UDP and TCP port 53 to authoritative addresses, outbound notify/transfer traffic to the secondary, and reliable NTP. Do not place a generic HTTP-only proxy in front of DNS.ip -brief address && ip route && timedatectl status

Operating boundary

OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.

Full guide

What you will build

System

A BIND 9.18 primary that is authoritative for {{zoneName}} and explicitly refuses recursion. Its public socket answers ordinary zone queries on UDP and TCP port 53 while cache access and recursion remain disabled.
A signed source-to-serving workflow: a human-readable unsigned zone with a monotonic SOA serial, inline signing under an explicit CSK policy, protected key storage, controlled transfer to {{secondaryNs}}, and observable DNSKEY/RRSIG state.
A complete public trust path from parent NS and glue through authoritative apex records to the parent DS and active DNSKEY, tested from an independent validating resolver before the old delegation is retired.

Observable outcome

Both authoritative servers return AA answers with the same current SOA serial, NS set, DNSKEY, and signatures over UDP and TCP; an unrelated name sent with recursion desired is refused rather than resolved.
The parent delegation exposes {{primaryNs}} and {{secondaryNs}} with correct glue where required, and the parent DS exactly matches the active DNSSEC key served by the child.
A validating resolver reports secure answers and secure denial of existence, while monitoring detects expired signatures, missing DS/DNSKEY matches, transfer lag, listener loss, and serial divergence.

Architecture

How the parts fit together

The registry or parent zone delegates {{zoneName}} to two authoritative names. Glue supplies addresses when those names live below the delegated zone and would otherwise create a lookup loop. The primary reads a writable unsigned source file, applies a key and signing policy, and maintains a separately signed view containing DNSKEY, RRSIG, and denial-of-existence records. NOTIFY prompts the approved secondary to transfer a newer serial. Recursive resolvers follow the delegation, compare the parent DS with the child DNSKEY, validate signatures, and cache answers for their TTL. The authoritative hosts never perform recursion for clients.

Parent/registrar delegationPublishes child NS, necessary glue, and DS that starts the DNSSEC chain into {{zoneName}}.

BIND primaryOwns the source zone, serial changes, signing keys, policy, NOTIFY, and transfer allowlist.

Authoritative secondaryMaintains an independent transferred copy and continues serving if the primary is unavailable.

DNSSEC key directoryStores private and public CSK state required to refresh signatures and match the parent DS.

Validating recursive resolverFollows referrals, validates DS/DNSKEY/RRSIG/NSEC data, and supplies cached secure answers to clients.

A resolver asks a parent for {{zoneName}} and receives the child NS set plus in-bailiwick glue and, after signing activation, the DS RRset.
The resolver sends the query to one authoritative endpoint. BIND answers from zone data with AA and never performs recursion for unrelated names.
For signed data, the resolver retrieves DNSKEY, matches its digest to the parent DS, and validates the RRset's RRSIG and authenticated denial records.
A source-zone change increments {{zoneSerial}}, passes validation, reloads on the primary, is signed automatically, and triggers NOTIFY.
The secondary transfers only a higher serial, serves it independently, and is checked externally before change closure.

Assumptions

{{zoneName}} is a public delegated zone, not an internal split-horizon namespace. Internal views add key, cache, and leak boundaries beyond this guide.
The primary and secondary are on independent infrastructure, have stable address records, maintain accurate time, and can exchange zone transfer traffic under an explicit allowlist or stronger authenticated transfer design.
The registrar accepts DS algorithm 13 with SHA-256 digest type 2 and exposes the submitted record through the parent. If policy requires another supported algorithm, design and test that policy rather than editing examples ad hoc.
IPv6 listeners and AAAA glue are omitted unless end-to-end IPv6 routing, firewalling, monitoring, and secondary service are verified. Publishing unreachable AAAA creates real delegation failures.
The source zone uses conventional file updates. Dynamic DNS needs update-policy, journals, freeze/thaw behavior, and a distinct authorization model.

Key concepts

Authoritative answer: An answer served from a zone for which the server is authoritative, identified by the AA flag. It is different from cached recursive data.
SOA serial: A 32-bit sequence value used by secondaries to decide whether a zone is newer. Every published change must move forward under serial arithmetic.
Delegation and glue: The parent publishes child NS records. Address glue is required when a nameserver name is inside the child zone and cannot be resolved before following the delegation.
DNSSEC chain of trust: A validating resolver trusts a parent DS, matches it to a child DNSKEY, and uses that key to verify RRSIG records over child RRsets.
Inline signing: BIND maintains a signed serving version separately from the human-managed source zone and refreshes signatures under dnssec-policy.
Combined signing key (CSK): One key with SEP and zone-signing use that signs the DNSKEY RRset and ordinary zone data. Its DS must remain coordinated with the parent.
Negative caching: Resolvers cache authenticated or ordinary nonexistence for the SOA-derived negative TTL, so a corrected missing record may remain absent until cache expiry.

Before you copy

Values used in this guide

{{zoneName}}

Public zone without a trailing dot in paths and commands.

Example: example.net

{{primaryNs}}

FQDN of the primary authoritative server without trailing dot in the variable; templates add it.

Example: ns1.example.net

{{secondaryNs}}

FQDN of the independent authoritative secondary.

Example: ns2.example.net

{{primaryNsLabel}}

Owner label for the primary inside zoneName.

Example: ns1

{{secondaryNsLabel}}

Owner label for the secondary inside zoneName.

Example: ns2

{{primaryAddress}}

Stable public IPv4 address of this BIND primary.

Example: 192.0.2.53

{{secondaryAddress}}

Stable public IPv4 address allowed to transfer the zone.

Example: 198.51.100.53

{{publicInterface}}

Interface receiving authoritative public DNS traffic.

Example: ens3

{{hostmasterRname}}

SOA responsible mailbox encoded with the first at-sign replaced by a dot.

Example: hostmaster.example.net

{{zoneSerial}}

Initial monotonic YYYYMMDDnn serial for the source zone.

Example: 2026072801

{{nextSerial}}

A serial strictly newer than all values already served.

Example: 2026072802

{{webAddress}}

Public IPv4 for zone apex and www.

Example: 203.0.113.80

{{mailAddress}}

Public IPv4 of the mail exchanger.

Example: 203.0.113.25

Security and production boundaries

Authoritative and recursive roles are separated deliberately. An internet-facing resolver can be abused for amplification, cache probing, policy bypass, and denial of service; recursion no plus cache denial is verified rather than assumed.
DNSSEC private keys are availability and integrity assets. Losing them while their DS remains at the parent causes validation failure; exposing them permits forged signed data. Back up encrypted key state and restrict filesystem access.
Zone transfer exposes the full zone and can aid reconnaissance. Restrict by source and preferably authenticate with TSIG in a production secondary design; network address allowlists alone do not provide message authentication.
DNSSEC signs data but does not encrypt names or hide queries. Query logging, passive observation, and public zone enumeration remain privacy considerations.
Accurate time is required for RRSIG inception and expiry. Monitor NTP state and signature validity rather than extending signature lifetimes to hide clock incidents.

Stop before continuing if

Stop if either authoritative endpoint is unreachable over UDP or TCP 53, has an unexpected address, or returns a different zone serial before parent delegation changes.
Stop if named-checkconf or named-checkzone emits any warning/error, if the zone serial moves backward, or if an apex NS/MX target lacks the required address record.
Stop before DS publication until DNSKEY and RRSIG records are stable on every authoritative server and the DS is generated from the currently active key.
Stop a rollover if the parent DS and child DNSKEY sets do not maintain at least one continuous matching trust path through cache TTLs.
Stop if the public server performs recursion, exposes AXFR to an unauthorized source, or listener/firewall state differs from the approved addresses.

instruction

Document the parent delegation, nameserver addresses, and rollback TTL

read-only

Capture existing parent NS, glue, DS, and TTL values; confirm that each in-bailiwick nameserver has an address record at the parent and that both endpoints answer before any DS record is submitted.

Why this step matters

DNS migration starts at the parent, not at named.conf. Capturing the current delegation and reducing risk before signing preserves a way back when caches continue using old NS or DS data.

What to understand

In-bailiwick names such as ns1.example.net need parent address glue because resolving their address otherwise requires first entering the very zone they serve.

Apex NS records in the child must match the intended parent NS set. Recursive resolvers may cache both, and inconsistent sets create intermittent paths that are difficult to reproduce.

DS is deliberately absent during unsigned staging. Publishing it before every authoritative server signs converts a partial deployment into a validating-resolver outage.

Keep the command output with the change record. DNS is distributed and cached, so an immediate local success is only one layer of evidence; later checkpoints deliberately test authoritative behavior, delegation, validation, transport, and client-visible results separately.

Run the exact read-only checkpoint before moving on. If its evidence differs from the example, diagnose that layer instead of stacking another configuration change, restarting repeatedly, or weakening a security control to make a query appear successful.

System changes

No DNS state changes; records current and planned parent/child identity, addresses, TTLs, and rollback ownership.

Syntax explained

NS: Delegates the child zone to authoritative nameserver names.
Glue A/AAAA: Parent-side address hints needed for nameserver names below the delegated child.
DS: Parent digest of a child DNSKEY that creates the DNSSEC chain of trust.

Example output / evidence

Zone: example.net.
Current parent NS: ns-old1.example.net., ns-old2.example.net.
Planned NS: ns1.example.net. 192.0.2.53; ns2.example.net. 198.51.100.53
Parent DS: none
Rollback TTL: 3600 seconds

Checkpoint: Approve a reachable two-server plan

Continue whenOld and planned NS/glue/DS sets, TTLs, addresses, owners, and rollback timing are documented.

Stop whenOnly one endpoint exists, an address is dynamic/unrouted, or registrar access is untested.

If this step fails

The “Approve a reachable two-server plan” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Old and planned NS/glue/DS sets, TTLs, addresses, owners, and rollback timing are documented.

Safe checks

Compare the observed state with the documented checkpoint evidence before making another change.
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Only one endpoint exists, an address is dynamic/unrouted, or registrar access is untested.

Security notes

Use a protected registrar account with phishing-resistant MFA and separate recovery contacts.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Stage under a delegated test subdomain before changing a production parent.

Stop conditions

No DS or NS change occurs while either new endpoint is unverified.

command

Install BIND, DNS utilities, and record the packaged version

caution

Install Ubuntu-supported BIND and query tools, then capture the exact named feature/version line before writing service configuration.

Why this step matters

The distribution package supplies service integration, AppArmor policy, utilities, security updates, and a known BIND branch. Recording the version ties later syntax and DNSSEC behavior to a supported release.

What to understand

Ubuntu 24.04 tracks BIND 9.18 ESV. Do not copy 9.20-only configuration without checking the installed named-checkconf.

bind9-utils supplies rndc and DNSSEC tools; dnsutils supplies dig and delv used for independent protocol evidence.

Package installation may attempt to start the default caching configuration. Keep the public firewall closed until authoritative-only options validate.

System changes

Installs BIND service files, utilities, package-managed defaults, AppArmor rules, and may start the default named service.

Syntax explained

named -V: Prints build version, linked libraries, paths, and compile features.
dig -v: Records the query-tool version used in validation evidence.

Command

sudo apt update && sudo apt install --yes bind9 bind9-utils bind9-dnsutils dnsutils && named -V | head -n 2 && dig -v

Example output / evidence

BIND 9.18.39-0ubuntu0.24.04.5-Ubuntu (Extended Support Version)
running on Linux x86_64 6.8.0-71-generic
DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu

Checkpoint: Record supported packages

dpkg-query -W bind9 bind9-utils bind9-dnsutils

Continue whenAll packages are installed from approved Ubuntu sources and named reports 9.18.x.

Stop whenAn unsupported PPA, mixed package branch, or failed package configuration appears.

If this step fails

The “Record supported packages” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: All packages are installed from approved Ubuntu sources and named reports 9.18.x.

Safe checks

Run the read-only checkpoint again and preserve its complete output: dpkg-query -W bind9 bind9-utils bind9-dnsutils
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. An unsupported PPA, mixed package branch, or failed package configuration appears.

Security notes

Do not expose the default recursive listener while staging.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Use a vendor-supported BIND 9.20 package only with a separate compatibility and upgrade plan.

Stop conditions

No configuration follows a failed or untrusted package installation.

config

Disable recursion and constrain authoritative listeners

caution

Replace the package options file with a reviewed authoritative-only options block that disables recursion and cache answers, listens only on the approved service addresses, hides version metadata, and permits ordinary public queries without turning the host into an open resolver.

Why this step matters

Authoritative publication and recursion are different trust roles. Explicitly denying recursion and cache access prevents the public host from becoming an open resolver while still allowing anyone to query the zone.

What to understand

allow-query controls authoritative data; allow-recursion and allow-query-cache control resolver/cache behavior. All three are set intentionally rather than relying on defaults.

Listen only on loopback plus {{primaryAddress}}. If IPv6 is published later, add an exact routed address and equivalent firewall and monitoring evidence.

minimal-responses reduces unnecessary additional data but does not replace rate limiting or upstream DDoS capacity.

System changes

Creates the authoritative global options file and defines listener, recursion, cache, query, version, and response policy.

Syntax explained

recursion no: Prevents named from resolving on behalf of clients.
allow-query { any; }: Allows public reads of authoritative zone data.
allow-query-cache { none; }: Prevents clients from retrieving cached recursive data.
listen-on: Binds only loopback and the approved authoritative IPv4 address.

File /etc/bind/named.conf.options

Configuration

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Primary Address{{primaryAddress}}Stable public IPv4 address of this BIND primary.

options {
  directory "/var/cache/bind";
  recursion no;
  allow-recursion { none; };
  allow-query-cache { none; };
  allow-query { any; };
  listen-on port 53 { 127.0.0.1; {{primaryAddress}}; };
  listen-on-v6 { none; };
  version "not disclosed";
  minimal-responses yes;
  dnssec-validation no;
};

Example output / evidence

Configuration saved at /etc/bind/named.conf.options
recursion no;
allow-recursion { none; };
allow-query-cache { none; };
listen-on { 127.0.0.1; 192.0.2.53; };

Checkpoint: Parse the role boundary

named-checkconf -p | grep -E 'recursion|allow-recursion|allow-query-cache|listen-on'

Continue whenPrinted effective configuration shows recursion/cache denied and only approved listeners.

Stop whenAnother included options block conflicts or a wildcard/public recursive listener remains.

If this step fails

The “Parse the role boundary” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Printed effective configuration shows recursion/cache denied and only approved listeners.

Safe checks

Run the read-only checkpoint again and preserve its complete output: named-checkconf -p | grep -E 'recursion|allow-recursion|allow-query-cache|listen-on'
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Another included options block conflicts or a wildcard/public recursive listener remains.

Security notes

Hiding version is minor hardening; patching, recursion denial, rate controls, and network capacity remain primary.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Run a separate resolver process or host when internal clients also need recursion.

Stop conditions

Never combine public recursion with the authoritative listener for convenience.

config

Write the unsigned source zone with a monotonic serial

caution

Create the writable source zone with a date-based serial, apex SOA and NS RRsets, matching address records for both nameservers, and representative web and mail records. Fully qualify every target with a trailing dot.

Why this step matters

The source zone is the human-auditable truth from which BIND creates signed data. Explicit origin, TTL, SOA timing, serial, apex NS, and address records make delegation and transfers predictable.

What to understand

The serial YYYYMMDDnn convention is readable but must still obey monotonic serial arithmetic. Multiple edits on one day increment nn.

SOA RNAME encodes a mailbox with a dot replacing the first at-sign; dots inside the local part require escaping and should be avoided operationally.

NS and MX targets are names, not addresses or CNAMEs. Nameserver address records in the child must agree with parent glue.

System changes

Creates the unsigned source zone containing SOA, NS, address, and MX RRsets under /var/lib/bind.

Syntax explained

$ORIGIN: Sets the suffix for relative owner names in the file.
$TTL 3600: Provides the default cache lifetime for records without an explicit TTL.
SOA serial: Signals zone freshness to secondary servers.
negative TTL 300: Controls caching of authenticated/non-authenticated nonexistence through the SOA minimum field.

File /var/lib/bind/db.{{zoneName}}

Configuration

Fill variables0/11 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.Primary Ns{{primaryNs}}FQDN of the primary authoritative server without trailing dot in the variable; templates add it.Hostmaster Rname{{hostmasterRname}}SOA responsible mailbox encoded with the first at-sign replaced by a dot.Zone Serial{{zoneSerial}}Initial monotonic YYYYMMDDnn serial for the source zone.Secondary Ns{{secondaryNs}}FQDN of the independent authoritative secondary.Primary Ns Label{{primaryNsLabel}}Owner label for the primary inside zoneName.Primary Address{{primaryAddress}}Stable public IPv4 address of this BIND primary.Secondary Ns Label{{secondaryNsLabel}}Owner label for the secondary inside zoneName.Secondary Address{{secondaryAddress}}Stable public IPv4 address allowed to transfer the zone.Web Address{{webAddress}}Public IPv4 for zone apex and www.Mail Address{{mailAddress}}Public IPv4 of the mail exchanger.

$ORIGIN {{zoneName}}.
$TTL 3600
@ IN SOA {{primaryNs}}. {{hostmasterRname}}. (
  {{zoneSerial}} ; serial YYYYMMDDnn
  3600 ; refresh
  900 ; retry
  1209600 ; expire
  300 ; negative TTL
)
@ IN NS {{primaryNs}}.
@ IN NS {{secondaryNs}}.
{{primaryNsLabel}} IN A {{primaryAddress}}
{{secondaryNsLabel}} IN A {{secondaryAddress}}
@ IN A {{webAddress}}
www IN A {{webAddress}}
@ IN MX 10 mail.{{zoneName}}.
mail IN A {{mailAddress}}

Example output / evidence

Zone source saved at /var/lib/bind/db.example.net
SOA serial: 2026072801
Apex NS: ns1.example.net., ns2.example.net.
Authoritative addresses: 192.0.2.53, 198.51.100.53

Checkpoint: Review the zone as data

named-checkzone {{zoneName}} /var/lib/bind/db.{{zoneName}}

Continue whenThe exact origin loads with {{zoneSerial}} and OK; every target is fully qualified and addressable.

Stop whenOut-of-zone data, missing trailing dots, duplicate CNAME/data, or serial regression appears.

If this step fails

The “Review the zone as data” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: The exact origin loads with {{zoneSerial}} and OK; every target is fully qualified and addressable.

Safe checks

Run the read-only checkpoint again and preserve its complete output: named-checkzone {{zoneName}} /var/lib/bind/db.{{zoneName}}
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Out-of-zone data, missing trailing dots, duplicate CNAME/data, or serial regression appears.

Security notes

Public zones reveal names and addresses by design; do not publish private inventory or administrative hostnames unnecessarily.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Generate zones from a reviewed source-of-truth system while preserving deterministic serial and validation gates.

Stop conditions

Do not load a zone whose apex NS differs from the approved delegation.

config

Declare the primary zone, controlled transfers, and DNSSEC policy

caution

Store signing keys under a bind-owned per-zone directory, select the explicit policy, enable inline signing, and restrict AXFR/IXFR plus NOTIFY to the approved secondary address.

Why this step matters

An explicit policy freezes key algorithm and timing expectations across package upgrades, while inline signing lets operators retain a readable source zone and BIND maintain signed state.

What to understand

The CSK private key directory must be writable by bind for generation and rollover state, but inaccessible to unrelated users.

allow-transfer names only the secondary address; production should add TSIG because IP source alone is not cryptographic authentication.

signature and parent timing values must exceed publication and propagation delays. Unlimited CSK lifetime avoids an unpracticed automatic parent rollover in this first deployment.

System changes

Creates protected key storage, changes zone ownership, and declares signing, transfer, and notify behavior.

Syntax explained

dnssec-policy oneliners-csk: Selects explicit algorithm and lifecycle parameters.
inline-signing yes: Maintains a signed serving copy alongside the source zone.
key-directory: Separates per-zone signing material in bind-writable storage.
allow-transfer / also-notify: Limits transfers and proactively informs the approved secondary.

File /etc/bind/named.conf.local

Configuration

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.Secondary Address{{secondaryAddress}}Stable public IPv4 address allowed to transfer the zone.

dnssec-policy "oneliners-csk" {
  keys { csk lifetime unlimited algorithm ecdsap256sha256; };
  dnskey-ttl 3600;
  max-zone-ttl 86400;
  parent-ds-ttl 3600;
  parent-propagation-delay 2h;
  publish-safety 1h;
  retire-safety 1h;
  signatures-refresh 5d;
  signatures-validity 14d;
};

zone "{{zoneName}}" IN {
  type primary;
  file "/var/lib/bind/db.{{zoneName}}";
  key-directory "/var/lib/bind/keys/{{zoneName}}";
  dnssec-policy "oneliners-csk";
  inline-signing yes;
  allow-transfer { {{secondaryAddress}}; };
  also-notify { {{secondaryAddress}}; };
  notify yes;
};

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.

sudo install --directory --owner=bind --group=bind --mode=0750 /var/lib/bind/keys/{{zoneName}} && sudo chown bind:bind /var/lib/bind/db.{{zoneName}} && sudo chmod 0640 /var/lib/bind/db.{{zoneName}} && sudo chmod 0750 /var/lib/bind/keys/{{zoneName}} && sudo stat -c '%U:%G %a %n' /var/lib/bind/db.{{zoneName}} /var/lib/bind/keys/{{zoneName}}

Example output / evidence

bind:bind 640 /var/lib/bind/db.example.net
bind:bind 750 /var/lib/bind/keys/example.net

Checkpoint: Prove file and policy ownership

namei -l /var/lib/bind/keys/{{zoneName}} /var/lib/bind/db.{{zoneName}}

Continue whenbind can write zone/signing state; unrelated users cannot read private key material.

Stop whenThe source or key directory is world-readable/writable or AppArmor denies the path.

If this step fails

The “Prove file and policy ownership” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: bind can write zone/signing state; unrelated users cannot read private key material.

Safe checks

Run the read-only checkpoint again and preserve its complete output: namei -l /var/lib/bind/keys/{{zoneName}} /var/lib/bind/db.{{zoneName}}
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. The source or key directory is world-readable/writable or AppArmor denies the path.

Security notes

Back up key state encrypted; a restored source zone without its published key cannot satisfy the parent DS.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Use a hidden primary and TSIG-authenticated public secondaries to reduce exposure of key/update infrastructure.

Stop conditions

Do not generate keys until storage permissions, backup, and policy are reviewed.

verification

Validate configuration and the unsigned zone before loading it

read-only

Run the full configuration parser and named-checkzone against the source file. Require the exact origin and serial to appear with an OK result.

Why this step matters

Static validation catches syntax, duplicate options, bad owner names, missing targets, and unsupported policy before the running server changes. -z also attempts to load configured primary zones.

What to understand

Run both validators because named-checkconf checks service structure while named-checkzone gives zone-specific integrity diagnostics.

Warnings about out-of-zone data, MX/NS targets, CNAME conflicts, or missing glue-like addresses require resolution even when an exit code is zero.

Validation cannot prove parent delegation, firewall, or key publication; those remain explicit later checkpoints.

System changes

No persistent change; parses configuration and zone data using the installed BIND implementation.

Syntax explained

named-checkconf -z: Checks configuration and test-loads configured primary zones.
named-checkzone ORIGIN FILE: Validates one zone and prints loaded serial.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.

sudo named-checkconf -z /etc/bind/named.conf && sudo named-checkzone {{zoneName}} /var/lib/bind/db.{{zoneName}}

Example output / evidence

zone example.net/IN: loaded serial 2026072801
zone example.net/IN: loaded serial 2026072801 (DNSSEC signed)
zone example.net/IN: loaded serial 2026072801
OK

Checkpoint: Require zero validation findings

Continue whenBoth tools exit zero, emit no unresolved warning, and name the intended origin/serial.

Stop whenAny error, unsupported directive, or data-integrity warning remains.

If this step fails

The “Require zero validation findings” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Both tools exit zero, emit no unresolved warning, and name the intended origin/serial.

Safe checks

Compare the observed state with the documented checkpoint evidence before making another change.
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Any error, unsupported directive, or data-integrity warning remains.

Security notes

Run validators before a privileged reload, not after exposing a broken public service.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Add the same commands to CI and configuration-management review, then repeat on the target package.

Stop conditions

No reload follows a failed validation.

command

Open authoritative DNS over both UDP and TCP without recursion exposure

caution

Add narrowly scoped input rules for UDP and TCP 53 on the authoritative address and retain management access. DNSSEC, large responses, truncation retries, and zone transfers require TCP.

Why this step matters

DNS uses UDP for common queries and TCP for truncation, DNSSEC, and transfer. Opening only UDP creates intermittent failures; opening a wildcard listener broadens exposure beyond the owned service address.

What to understand

Rules name the inbound interface and destination address so another interface or address does not inherit public DNS exposure.

Provider firewalls, security groups, NAT, and upstream ACLs must match host policy. A host rule alone does not prove the external path.

Preserve SSH/console recovery before applying UFW and verify rule order rather than assuming comments control precedence.

System changes

Adds persistent inbound UFW rules for UDP and TCP 53 to the named authoritative address.

Syntax explained

to {{primaryAddress}}: Restricts the destination address rather than every host address.
proto udp / proto tcp: Creates both required transport rules explicitly.
comment: Associates operational purpose with each numbered rule.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Public Interface{{publicInterface}}Interface receiving authoritative public DNS traffic.Primary Address{{primaryAddress}}Stable public IPv4 address of this BIND primary.

sudo ufw allow in on {{publicInterface}} to {{primaryAddress}} port 53 proto udp comment 'authoritative DNS UDP' && sudo ufw allow in on {{publicInterface}} to {{primaryAddress}} port 53 proto tcp comment 'authoritative DNS TCP' && sudo ufw status numbered

Example output / evidence

[ 1] 192.0.2.53 53/udp on ens3 ALLOW IN Anywhere # authoritative DNS UDP
[ 2] 192.0.2.53 53/tcp on ens3 ALLOW IN Anywhere # authoritative DNS TCP

Checkpoint: Confirm exact DNS exposure

ufw status numbered && ss -lntup 'sport = :53'

Continue whenOnly intended address/interface rules and named listeners exist for both transports.

Stop whenManagement access is threatened, wildcard recursion exists, or another process owns port 53.

If this step fails

The “Confirm exact DNS exposure” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Only intended address/interface rules and named listeners exist for both transports.

Safe checks

Run the read-only checkpoint again and preserve its complete output: ufw status numbered && ss -lntup 'sport = :53'
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Management access is threatened, wildcard recursion exists, or another process owns port 53.

Security notes

Public authoritative DNS remains a DDoS target; UFW is not upstream capacity or response-rate limiting.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Express equivalent nftables or cloud-firewall rules under the host's single authoritative firewall owner.

Stop conditions

Do not enable UFW or change rules without console recovery and rule-owner knowledge.

command

Start BIND and prove authoritative-only behavior locally

caution

Enable the service, inspect its journal and listener ownership, then query the zone with recursion disabled and query an unrelated name to confirm the host does not recurse.

Why this step matters

Local direct queries separate BIND loading and role behavior from parent delegation and upstream firewalls. Testing an unrelated name with +norecurse is the decisive open-resolver boundary check.

What to understand

The authoritative answer must include AA. RA should not be offered, and an unrelated zone must be REFUSED rather than resolved or cached.

ss proves port, address, transport, process, and listener ownership; systemctl active alone cannot show correct binding.

Inspect the journal for permission, key generation, zone load, and managed-key errors before public testing.

System changes

Enables and starts named, creates signing state, and binds approved UDP/TCP sockets.

Syntax explained

enable --now: Starts named and persists boot activation.
+norecurse: Clears RD so the test requests only authoritative knowledge.
AA flag: Proves the returned RRset is authoritative for the zone.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.

sudo systemctl enable --now named && systemctl is-active named && sudo ss -lntup 'sport = :53' && dig @127.0.0.1 {{zoneName}} SOA +norecurse +multiline && dig @127.0.0.1 example.org A +norecurse

Example output / evidence

active
udp UNCONN 127.0.0.1:53 users:(("named",pid=1842,fd=20))
tcp LISTEN 192.0.2.53:53 users:(("named",pid=1842,fd=23))
;; flags: qr aa; QUERY: 1, ANSWER: 1
example.net. 3600 IN SOA ns1.example.net. hostmaster.example.net. 2026072801 3600 900 1209600 300
;; status: REFUSED

Checkpoint: Accept authoritative-only local service

dig @127.0.0.1 {{zoneName}} SOA +norecurse; dig @127.0.0.1 example.org A +norecurse

Continue whenZone SOA has AA and unrelated data is REFUSED with no recursive answer.

Stop whenService loops/restarts, recursion succeeds, AA is absent, or listeners differ.

If this step fails

The “Accept authoritative-only local service” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Zone SOA has AA and unrelated data is REFUSED with no recursive answer.

Safe checks

Run the read-only checkpoint again and preserve its complete output: dig @127.0.0.1 {{zoneName}} SOA +norecurse; dig @127.0.0.1 example.org A +norecurse
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Service loops/restarts, recursion succeeds, AA is absent, or listeners differ.

Security notes

Do not interpret localhost refusal as proof against external recursion until the public address is tested from outside.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Use named -g in a disposable namespace for interactive startup diagnosis without changing production listeners.

Stop conditions

Keep external firewall closed if local role separation fails.

verification

Wait for inline signing and record DNSKEY, RRSIG, and key state

read-only

Use rndc and direct authoritative queries to prove that BIND created the combined signing key, published DNSKEY, and generated valid signatures before a DS is sent to the parent.

Why this step matters

A configured policy is not evidence that signatures are ready. Key status plus DNSKEY and RRSIG queries prove the serving path before the irreversible parent DS creates validation expectations.

What to understand

The DNSKEY with flag 257 is the CSK used to generate DS. Record algorithm 13 and key tag from actual output.

RRSIG inception and expiration must be reasonable relative to accurate system time. Future inception or expired signatures indicate clock or maintenance failure.

Check both DNSKEY signatures and ordinary SOA/A signatures because key publication alone does not prove all RRsets are signed.

System changes

No new intended change; observes key-generation and inline-signing state created by named.

Syntax explained

rndc dnssec -status: Reports policy, key roles, tags, states, and timing.
+dnssec: Requests DNSSEC records and EDNS DO behavior from dig.
RRSIG: Carries algorithm, labels, TTL, inception, expiration, key tag, signer, and signature.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.

sudo rndc dnssec -status {{zoneName}}; dig @127.0.0.1 {{zoneName}} DNSKEY +dnssec +multiline; dig @127.0.0.1 {{zoneName}} SOA +dnssec +multiline

Example output / evidence

dnssec-policy: oneliners-csk
key: 12345 (ECDSAP256SHA256), CSK, active
example.net. 3600 IN DNSKEY 257 3 13 (...)
example.net. 3600 IN RRSIG DNSKEY 13 2 3600 20260811000000 20260728000000 12345 example.net. (...)

Checkpoint: Approve the child key state

Continue whenOne intended active CSK is published; DNSKEY and ordinary RRsets have current signatures on all servers.

Stop whenKeys differ unexpectedly, signatures are absent/expired, or time is unsynchronized.

If this step fails

The “Approve the child key state” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: One intended active CSK is published; DNSKEY and ordinary RRsets have current signatures on all servers.

Safe checks

Compare the observed state with the documented checkpoint evidence before making another change.
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Keys differ unexpectedly, signatures are absent/expired, or time is unsynchronized.

Security notes

Only public .key material belongs in evidence; never paste .private files or key-directory archives.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Use a separately designed split KSK/ZSK lifecycle when policy requires different custody or rotation.

Stop conditions

No DS is submitted until signed child state is stable on every authority.

verification

Verify the approved secondary transfer and serial

read-only

Query both nameservers directly over TCP and compare SOA serials, apex NS, DNSKEY, and RRSIG data. Attempt an AXFR from an unauthorized source and require refusal.

Why this step matters

DNS availability depends on independent authorities serving coherent data. TCP SOA comparisons and DNSSEC RRsets verify transfer completeness, while an unauthorized AXFR test confirms zone disclosure is constrained.

What to understand

A secondary should transfer the primary's signed serving zone or correctly maintain DNSSEC according to the designed topology; compare actual DNSKEY/RRSIG, not only serial.

SOA over TCP exercises the transport required for transfer and large-answer fallback.

The unauthorized AXFR attempt must come from a source outside allow-transfer; localhost or the approved secondary is not a valid negative test.

System changes

No primary metadata change; causes read-only queries and may cause the secondary to complete an already notified transfer.

Syntax explained

+tcp: Forces DNS over TCP for transport verification.
AXFR: Requests a full zone transfer; unauthorized sources must fail.
+short SOA: Makes serial comparison concise while retaining full SOA fields.

Command

Fill variables0/3 ready

Values stay on this page and are never sent or saved.

Primary Address{{primaryAddress}}Stable public IPv4 address of this BIND primary.Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.Secondary Address{{secondaryAddress}}Stable public IPv4 address allowed to transfer the zone.

dig @{{primaryAddress}} {{zoneName}} SOA +tcp +norecurse +short; dig @{{secondaryAddress}} {{zoneName}} SOA +tcp +norecurse +short; dig @{{secondaryAddress}} {{zoneName}} DNSKEY +dnssec +norecurse; dig @{{primaryAddress}} {{zoneName}} AXFR

Example output / evidence

ns1.example.net. hostmaster.example.net. 2026072801 3600 900 1209600 300
ns1.example.net. hostmaster.example.net. 2026072801 3600 900 1209600 300
;; flags: qr aa; ANSWER: 2
; Transfer failed.

Checkpoint: Require coherent independent authorities

Continue whenPrimary and secondary serve identical current serial/key/signature state; unauthorized AXFR fails.

Stop whenSecondary lags, differs, shares the same failure domain unexpectedly, or permits transfer.

If this step fails

The “Require coherent independent authorities” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Primary and secondary serve identical current serial/key/signature state; unauthorized AXFR fails.

Safe checks

Compare the observed state with the documented checkpoint evidence before making another change.
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Secondary lags, differs, shares the same failure domain unexpectedly, or permits transfer.

Security notes

Add TSIG before relying on transfers across untrusted networks; source IP can be spoofed or routed incorrectly.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Use provider-supported authenticated zone distribution or a hidden primary.

Stop conditions

Do not change parent NS until both authorities pass direct tests.

warning

Publish parent NS, glue, and the generated DS only after endpoints agree

danger

At the registrar or parent operator, publish both NS names and required address glue, wait for parent NS visibility, then submit the SHA-256 DS generated from the active CSK. Never derive DS from an old or unpublished key.

Why this step matters

The parent is the public entry point and trust anchor link. NS/glue establish reachability; DS tells validators which child key to trust. Publishing them in the wrong order can make correct child data unreachable or bogus.

What to understand

Publish NS and glue first, confirm them from the parent, and keep old authorities online through TTL convergence.

Generate SHA-256 DS from the active public key file in protected key storage. Compare key tag, algorithm, digest type, and full digest with registrar output.

Registrar interfaces may normalize case or spacing but must not change numeric fields or digest bytes.

System changes

Changes public parent NS/glue and DS state through the registrar; creates a global cached trust relationship.

Syntax explained

dnssec-dsfromkey -2: Generates digest type 2 (SHA-256) DS from a DNSKEY public file.
key tag 12345: Identifies the child DNSKEY referenced by DS.
algorithm 13: ECDSAP256SHA256, matching the explicit CSK policy.

Command

Fill variables0/1 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.

sudo find /var/lib/bind/keys/{{zoneName}} -maxdepth 1 -name 'K{{zoneName}}.+*.key' -exec dnssec-dsfromkey -2 {} \;

Example output / evidence

example.net. IN DS 12345 13 2 7A1E5C0D7D69A4B7E9F5E53A8C8B2B1E2B41D4D3C45E9C39A8D2A3C31F8C1010
Registrar status: NS and glue published; DS pending parent propagation

Checkpoint: Compare parent and child trust data

dig {{zoneName}} DS +dnssec; dig @{{primaryAddress}} {{zoneName}} DNSKEY +dnssec

Continue whenParent DS exactly matches one active child DNSKEY and every planned NS/glue entry is visible.

Stop whenAny numeric field/digest differs or a nameserver remains unreachable.

If this step fails

The “Compare parent and child trust data” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Parent DS exactly matches one active child DNSKEY and every planned NS/glue entry is visible.

Safe checks

Run the read-only checkpoint again and preserve its complete output: dig {{zoneName}} DS +dnssec; dig @{{primaryAddress}} {{zoneName}} DNSKEY +dnssec
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Any numeric field/digest differs or a nameserver remains unreachable.

Security notes

Registrar compromise can redirect or invalidate the entire zone; require protected accounts, alerts, and recovery contacts.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Use CDS/CDNSKEY automation only when the parent supports it and initial trust plus monitoring are explicitly designed.

Stop conditions

Never delete or replace the only matching DNSKEY while its DS is cached.

verification

Validate delegation and DNSSEC from outside the authoritative network

read-only

From an independent network and a validating resolver, trace delegation, query each authoritative server over UDP and TCP, verify the parent DS, require the AD bit from a validating recursive resolver, and check a nonexistent name for signed denial.

Why this step matters

Only an independent path observes the same parent referrals, glue, firewalls, MTU, TCP behavior, and DNSSEC chain as real users. Local success cannot prove public correctness.

What to understand

+trace shows iterative delegation but does not itself perform DNSSEC validation; delv supplies validation evidence.

Test both UDP and forced TCP against each authority and a validating recursive resolver from outside the hosting network.

A nonexistent name tests authenticated denial and negative caching, catching missing NSEC/RRSIG paths not seen in positive A queries.

System changes

No persistent change; performs public protocol queries that may populate recursive caches.

Syntax explained

+trace: Walks referrals from the root to the child authority.
delv: Validates DNSSEC using configured trust anchors and reports validation state.
nonexistent name: Exercises signed denial of existence and negative caching.

Command

Fill variables0/2 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.Primary Address{{primaryAddress}}Stable public IPv4 address of this BIND primary.

dig +trace {{zoneName}} NS; dig @{{primaryAddress}} {{zoneName}} SOA +norecurse; dig @{{primaryAddress}} {{zoneName}} SOA +tcp +norecurse; dig {{zoneName}} DS +dnssec; delv {{zoneName}} A; delv does-not-exist.{{zoneName}} A

Example output / evidence

example.net. 3600 IN NS ns1.example.net.
example.net. 3600 IN NS ns2.example.net.
;; flags: qr aa
example.net. 3600 IN DS 12345 13 2 7A1E...
; fully validated
; negative response, fully validated

Checkpoint: Accept the public chain

Continue whenDelegation, glue, both transports, both authorities, DS/DNSKEY match, positive validation, and negative validation all pass.

Stop whenAny path is intermittent, insecure unexpectedly, or SERVFAIL/bogus.

If this step fails

The “Accept the public chain” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Delegation, glue, both transports, both authorities, DS/DNSKEY match, positive validation, and negative validation all pass.

Safe checks

Compare the observed state with the documented checkpoint evidence before making another change.
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Any path is intermittent, insecure unexpectedly, or SERVFAIL/bogus.

Security notes

Use multiple independent vantage points without sending secret internal names to public resolvers.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Run owned probes in two external regions and retain raw dig output for continuous monitoring.

Stop conditions

Do not retire old authorities or lower monitoring while caches still expose mixed state.

command

Perform one serial-controlled record change and verify propagation

caution

Back up the source zone, increase the SOA serial monotonically, validate it, reload only the named zone, and require both primary and secondary to expose the new serial before considering the update complete.

Why this step matters

The operational value of DNS is in safe repeatable updates. A backup, higher serial, static validation, zone-scoped reload, and two-server comparison prove the full publication loop without restarting unrelated zones.

What to understand

Rollback also uses a new higher serial; restoring old bytes with an old serial will not reliably transfer.

rndc reload {{zoneName}} limits impact and triggers signing/notify for this zone. Watch signing and secondary propagation before closing.

TTL defines how long old RRsets remain valid in resolver caches. A new authoritative answer does not instantly change every client.

System changes

Creates a source-zone backup, reloads one zone, regenerates signed state, and notifies the secondary of a newer serial.

Syntax explained

cp --archive: Preserves the prior source zone and metadata for comparison/rollback.
rndc reload ZONE: Reloads only the named zone instead of restarting BIND.
SOA serial comparison: Proves the primary and secondary both published the new revision.

Command

Fill variables0/4 ready

Values stay on this page and are never sent or saved.

Zone Name{{zoneName}}Public zone without a trailing dot in paths and commands.Next Serial{{nextSerial}}A serial strictly newer than all values already served.Primary Address{{primaryAddress}}Stable public IPv4 address of this BIND primary.Secondary Address{{secondaryAddress}}Stable public IPv4 address allowed to transfer the zone.

sudo cp --archive /var/lib/bind/db.{{zoneName}} /var/lib/bind/db.{{zoneName}}.before-{{nextSerial}} && sudo named-checkzone {{zoneName}} /var/lib/bind/db.{{zoneName}} && sudo rndc reload {{zoneName}} && dig @{{primaryAddress}} {{zoneName}} SOA +short && dig @{{secondaryAddress}} {{zoneName}} SOA +short

Example output / evidence

zone example.net/IN: loaded serial 2026072802
OK
zone reload queued
ns1.example.net. hostmaster.example.net. 2026072802 3600 900 1209600 300
ns1.example.net. hostmaster.example.net. 2026072802 3600 900 1209600 300

Checkpoint: Close one controlled DNS update

Continue whenSource validates, signed state is current, both authorities serve {{nextSerial}}, and external answer/TTL match intent.

Stop whenSerial diverges, signing stalls, transfer fails, or a record differs from approval.

If this step fails

The “Close one controlled DNS update” checkpoint does not produce the expected evidence.

Likely causeThe preceding change is incomplete, the observed system differs from the documented assumptions, or the checkpoint reached a different DNS component than intended. Expected evidence: Source validates, signed state is current, both authorities serve {{nextSerial}}, and external answer/TTL match intent.

Safe checks

Compare the observed state with the documented checkpoint evidence before making another change.
Review the immediately preceding command or configuration diff, service status, listener ownership, journal timestamps, and the exact server address queried.

ResolutionStop at this layer and correct the discrepancy before continuing. Serial diverges, signing stalls, transfer fails, or a record differs from approval.

Security notes

Review changes for unintended internal addresses, takeover-prone CNAMEs, mail-routing changes, or long-lived sensitive TXT values.
Do not paste private names, client addresses, keys, complete query logs, or registrar account details into public support channels. Redact evidence while retaining timestamps, response codes, flags, serials, key tags, and server identities needed for diagnosis.

Alternatives

Use signed, reviewed GitOps generation while preserving authoritative serial, validation, and external acceptance tests.

Stop conditions

Do not issue repeated reloads or lower a serial to force propagation.

Finish line

Verification checklist

Authoritative separationdig @{{primaryAddress}} {{zoneName}} SOA +norecurse; dig @{{primaryAddress}} example.org A +norecurseThe zone answer has AA without RA; the unrelated recursive request is REFUSED.

UDP and TCP reachabilitydig @{{primaryAddress}} {{zoneName}} DNSKEY +dnssec; dig @{{primaryAddress}} {{zoneName}} DNSKEY +dnssec +tcpBoth transports return the same authoritative DNSKEY RRset and signatures.

Delegation and gluedig +trace {{zoneName}} NSThe parent returns the intended NS set and usable address glue where nameservers are inside the delegated zone.

DNSSEC chaindelv {{zoneName}} SOA && dig {{zoneName}} DS +dnssecThe resolver reports fully validated, and parent DS key tag, algorithm, digest type, and digest match the active key.

Recovery guidance

Common problems and safe checks

Queries to the primary return REFUSED for {{zoneName}}.

Likely causeThe zone failed to load, the query reached the wrong view/address, allow-query is narrower than intended, or the name is outside the authoritative origin.

Safe checks

named-checkconf -z
rndc zonestatus {{zoneName}}
dig @127.0.0.1 {{zoneName}} SOA +norecurse
journalctl -u named -n 100 --no-pager

ResolutionCorrect the loading, view, listener, or query policy; do not enable recursion to make the answer appear.

The secondary keeps serving the previous serial.

Likely causeThe primary serial did not increase, NOTIFY or TCP transfer is blocked, allow-transfer excludes the actual source, or the secondary rejected the signed transfer.

Safe checks

dig @{{primaryAddress}} {{zoneName}} SOA +short
dig @{{secondaryAddress}} {{zoneName}} SOA +short
journalctl -u named --since '-30 minutes'

ResolutionAssign a strictly newer serial, validate, and repair notify/transfer authorization and TCP reachability. Never edit the secondary copy manually.

The parent delegation loops or one nameserver is intermittently unreachable.

Likely causeIn-bailiwick glue is missing/wrong, apex and parent NS sets differ, AAAA glue is unreachable, or one endpoint lacks TCP 53.

Safe checks

dig +trace {{zoneName}} NS
dig @{{primaryAddress}} {{zoneName}} NS +norecurse
dig @{{secondaryAddress}} {{zoneName}} SOA +tcp +norecurse

ResolutionAlign parent and child NS, correct required glue, and remove an unreachable address only through a TTL-aware delegation change.

Validating resolvers return SERVFAIL after DS publication.

Likely causeThe parent DS references a different key, signatures expired or are not served by all secondaries, or time/key files are wrong.

Safe checks

dig {{zoneName}} DS +dnssec
dig @{{primaryAddress}} {{zoneName}} DNSKEY +dnssec
rndc dnssec -status {{zoneName}}
timedatectl status

ResolutionRestore the matching DNSKEY/signatures or correct the parent DS while maintaining a valid trust path. Do not disable validation on clients as the fix.

After the procedure

Alternatives and next steps

Consider these alternatives

Use a managed authoritative DNS provider when independent anycast endpoints, registrar automation, DDoS capacity, and audited key lifecycle provide a better operational fit.
Use separate hidden primary and public secondaries so the signing/update host is not internet-facing; transfers then require strong authentication and monitoring.
Use a split KSK/ZSK or offline KSK only when the team can operate parent coordination, rollover timing, HSM or offline workflows, and disaster recovery.
Use an unsigned zone temporarily only before any DS exists. Removing DNSSEC later requires a safe DS-first transition, not simply deleting dnssec-policy.

Operate it safely

Add TSIG-authenticated transfers and NOTIFY between primary and secondary, then test key rotation and authorization failure.
Monitor SOA serial agreement, UDP/TCP reachability, AA/RA flags, DS-to-DNSKEY match, RRSIG expiry horizon, transfer failures, and query-rate anomalies from outside the network.
Rehearse primary loss and key-directory restoration without changing the parent. Confirm the secondary continues serving and that restored signing state does not create an uncoordinated key.
Document registrar DS update lead time and perform a supervised rollover exercise before the organization depends on automatic key transitions.

Reference

Frequently asked questions

Why must TCP 53 be public?

DNS retries truncated UDP responses over TCP, DNSSEC responses are often larger, and zone transfers use TCP. Blocking it produces intermittent failures that simple A-record tests miss.

Why is dnssec-validation disabled on the authoritative host?

The service does not recurse. DNSSEC here signs authoritative data; validation belongs on recursive resolvers. The separation makes public behavior and attack surface easier to reason about.

Can I lower the serial when correcting a typo?

No. Secondaries compare serial arithmetic and may ignore a lower value. Publish another higher serial even when the content conceptually rolls back.

Does DNSSEC hide my zone?

No. It authenticates data and denial of existence. It provides neither confidentiality nor access control, and some denial mechanisms can make enumeration easier.

Recovery

Rollback

Rollback protects availability and the chain of trust: restore the last good source zone or BIND configuration, and remove a parent DS before withdrawing the only matching DNSKEY.

For a bad zone edit, restore /var/lib/bind/db.{{zoneName}}.before-{{nextSerial}}, assign a new serial greater than every serial already served, validate, and reload the zone.
For a BIND configuration failure, restore the timestamped /etc/bind backup, run named-checkconf -z, restart once, and repeat direct authoritative queries.
For a DNSSEC failure after DS publication, keep the matching DNSKEY and signatures available while diagnosing. If unsigned rollback is necessary, remove DS at the parent, wait through parent and resolver cache TTLs, verify the delegation is insecure, then transition the zone policy.
For a delegation failure, restore the previous parent NS/glue set while the old authoritative service remains online; wait for cached delegation TTL before decommissioning either endpoint.
Never delete key files as an immediate rollback. Restore the encrypted key directory and signed state from backup when the published DS still references that key.

Evidence

Sources and review

Verified 2026-07-24Review due 2026-10-22

BIND 9.18 DNSSEC administrator guideofficial BIND 9 configuration referenceofficial RFC 4035 DNSSEC protocol modificationsofficial