Writing

BIND DNS server: patch and restart safely

Published 27 September 2026

A BIND DNS server runs ISC's named daemon. It may publish zones, resolve names for clients, or do both. Before a BIND9 update, record which job each node performs, validate the configuration and test the answers clients depend on. Patch one redundant node at a time, then verify UDP, TCP, authoritative answers and recursion separately.

First find out what the server does

The package name does not tell you the service's role. An authoritative server answers from zones it hosts. A recursive resolver follows referrals and caches the result for clients. One process can do both, although keeping the roles separate makes access control and failure isolation easier.

Ask the server directly rather than relying on the machine's resolver configuration. Replace the addresses and zones below with real ones:

dig @192.0.2.53 example.com SOA +norecurse
dig @192.0.2.53 example.com A +tcp +norecurse
dig @192.0.2.53 example.net A +dnssec
dig @192.0.2.53 version.bind TXT CH

The last query may be hidden or deliberately vague. Check the installed binary locally with named -V; it prints the version, build options and supported cryptographic algorithms. A distribution may backport a security fix without changing the number to the upstream fixed release, so confirm its package advisory as well.

Validate before changing the package

A restart reads paths and files that a long-running daemon may not have touched in months. That is why an update can expose an old configuration error even when the new binary is sound. Run the checks with the same configuration path, chroot and permissions the service uses.

named-checkconf
named-checkconf -z
named-checkzone example.com /path/to/example.com.zone
rndc status

named-checkconf checks syntax and included files. With -z, it also test-loads primary zones. ISC notes that separate parser contexts such as rndc.conf and rndc.key are not read automatically, so validate those explicitly if the deployment uses them. named-checkzone applies the same syntax and integrity checks that named uses when loading a zone.

Preserve the current package version, configuration, zone files, journals, keys and service-unit overrides in the normal backup system. Treat TSIG and DNSSEC private keys as secrets: verify that the backup contains them without printing or copying their values into a change record.

Patch one failure domain at a time

Use the operating system's supported repository or ISC's maintained packages. Review the branch's release notes and known issues before crossing a major-version boundary. A package update is not finished when the files install; the running process must be restarted onto the new binary.

1. Remove one resolver from client service, or choose one authoritative secondary.
2. Record baseline answers and the SOA serial from that node.
3. Install the vendor-approved update and restart the service.
4. Read the service log from startup through the first queries and zone transfers.
5. Repeat the direct tests for UDP, TCP, authoritative answers and recursion.
6. Return the node to service, watch it under traffic, then continue to the next node.

A configuration reload is not a binary upgrade. rndc reload reloads configuration and zones, while a package update requires the platform's service restart. If a pool has only one server, arrange a tested maintenance path first; a low DNS TTL does not provide a second resolver.

What the September 2026 BIND advisory changes

ISC published CVE-2026-77692 on 16 September 2026. A crafted DNS-over-HTTPS request containing an invalid SIG(0) record can remotely terminate named. ISC lists BIND 9.20.0 through 9.20.27 and 9.21.0 through 9.21.25 as affected, reports no known workaround and recommends 9.20.29 or 9.21.26. ISC said it was not aware of active exploitation when the advisory was posted.

The trigger uses DNS over HTTPS, but the operational response is still a complete DNS change. Confirm whether the server exposes DoH, patch the affected binary, and verify classic DNS transports plus any encrypted listener after restart.

Verify the service clients actually use

Run checks from both sides of any firewall or load balancer. For an authoritative service, compare the SOA serial and several important records on every published nameserver. For a resolver, test an uncached external name from an allowed client and confirm that an unauthorized source cannot recurse.

dig @192.0.2.53 example.com SOA +norecurse
dig @192.0.2.53 www.example.com A +norecurse
dig @192.0.2.53 www.example.com A +tcp +norecurse
dig @192.0.2.53 dnssec-failed.org A +dnssec

The last name is designed to fail on a validating resolver; use an approved DNSSEC test in your environment and interpret the result against local policy. The DNS lookup tool compares public resolvers, while the DNS propagation checker shows whether Cloudflare and Google hold the same record and TTL. Neither replaces a direct query to a private or authoritative server.

Cache flushing is a separate operation. If a correct BIND answer is already reaching the client, use the flush DNS guide to identify which local cache, if any, still holds the old value.

Sources

• ISC CVE-2026-77692 advisory: affected versions, impact, fixed releases and disclosure date
• BIND 9 downloads and support status: current branches, end-of-life status, packages and upgrade guidance
• BIND 9 manual pages: named-checkconf, named-checkzone, named and rndc behavior

BIND versions and advisory status were checked on 27 September 2026.