BIND DNS server: supported versions and updates

Updated November 2026

BIND 9 is the DNS server from ISC (Internet Systems Consortium), the program called named. As of November 2026 the only supported production branch is BIND 9.20; 9.18 reached end of life in June 2026. Update through your distribution or ISC’s packages, test the config, then restart named.

Who runs BIND

BIND is used both as an authoritative server (it answers for your own domains) and as a recursive resolver (it looks up names for your users and servers). Many Linux distributions ship it as their standard DNS server, and hosting control panels often install it to serve customer zones. Because it answers queries from the network, a flaw can often be triggered remotely by a crafted packet. Most BIND advisories are about crashes (denial of service), which stop DNS for everything that depends on it.

Check the installed version

named -v
sudo rndc status

named -v prints the version of the installed binary; named -V adds build options. rndc status asks the running server, so it also tells you whether the server was restarted after the last update. Package versions:

# Debian/Ubuntu
dpkg -l bind9

# RHEL family, Fedora, SUSE
rpm -qa 'bind*'

# Alpine
apk version bind

# FreeBSD
pkg info | grep '^bind'

Distribution packages carry their own suffix, such as 1:9.20.30-1~deb13u1 on Debian. Compare with the distribution’s advisory, not only with ISC’s version number.

Supported versions

ISC uses even minor numbers (9.18, 9.20) for stable production branches and odd numbers (9.21) for development. A stable branch gets features and bug fixes for about a year, then becomes an Extended Support Version (ESV) with critical and security fixes only. In ISC’s words, “Each even-numbered version is supported for a total of 4 years.”

BIND 9 branches, as of November 2026
Branch	Status	Latest release	End of life
9.20	Current stable (supported)	9.20.30 (October 2026)	Q2 2028
9.21	Development, not for production	9.21.27 (October 2026)	–
9.18	End of life	9.18.50 (June 2026)	June 2026
9.16 and older	End of life	–	ended earlier

ISC says its dates are approximate. Security fixes for development versions arrive as normal maintenance releases, without separate advisories, which is another reason not to run 9.21 in production.

9.18 being end of life upstream doesn’t automatically mean your server is unpatched. Debian 12 (now in Long Term Support) still ships BIND 9.18 and Debian keeps patching it (9.18.49 with Debian security updates, as of November 2026); enterprise distributions also maintain the versions they ship. If you built 9.18 from source or use ISC’s own 9.18 packages, you get no more fixes: move to 9.20.

Distribution packages vs ISC packages

Your distribution’s package (bind9 on Debian and Ubuntu, bind on RHEL, Fedora, SUSE and Alpine, bind920 on FreeBSD) is the simplest choice: fixes arrive with normal security updates, and backports keep the same major version for the life of the release. A “backport” here means the distribution copies the fix into its older version instead of moving to ISC’s newest release.

If you need a newer branch than your distribution ships, ISC links packages from its BIND page: Launchpad PPAs for Ubuntu, Fedora COPR repositories for Fedora and RHEL-family systems, Debian packages, and an official Docker image. Once you use them, you depend on ISC’s release timing and must still install the updates.

Update commands

Debian and Ubuntu (the service is called named):

sudo apt update
sudo apt install --only-upgrade bind9 bind9-utils bind9-libs

RHEL, Rocky, AlmaLinux, Fedora:

sudo dnf upgrade --refresh 'bind*'

SUSE:

sudo zypper refresh
sudo zypper update bind bind-utils

Alpine (as root):

apk -U upgrade

FreeBSD (as root):

pkg update
pkg upgrade bind920

ISC’s Ubuntu PPA and Fedora COPR, if you choose them (after adding the repository, the normal update commands above pick up new releases):

# Ubuntu
sudo add-apt-repository ppa:isc/bind

# Fedora / RHEL family (needs dnf-plugins-core)
sudo dnf copr enable isc/bind

ISC’s Docker image: pull the new tag and recreate the container. Tag 9.20 is the stable branch; 9.18 is marked end of life.

docker pull internetsystemsconsortium/bind9:9.20

Test, then restart

A new binary only runs after named restarts; rndc reload rereads configuration and zones but keeps the old program running. Check the configuration first, because a typo stops the server from starting:

sudo named-checkconf -z
sudo systemctl restart named      # restarts the DNS service

named-checkconf -z also test-loads every primary zone. On FreeBSD use service named restart, on Alpine rc-service named restart. A restart takes a few seconds, and a resolver loses its cache. If you run two or more DNS servers, update and restart them one at a time so clients can fall back to the other. Distribution packages often restart the service themselves during the upgrade; check with rndc status rather than assume.

For a single zone change you can use named-checkzone example.com /path/to/zonefile and sudo rndc reload, but that is not a substitute for a restart after an update. See what to restart after an update.

Verify

sudo rndc status | head -3
dig @127.0.0.1 example.com SOA +short
sudo journalctl -u named --since "10 min ago"

The running version should match the fixed release, a test query should answer, and the log should show the zones loaded without errors.

Where ISC publishes advisories

BIND 9 Software Vulnerability Matrix: kb.isc.org/docs/aa-00913, with every CVE and the versions that fix it. For example, 9.20.30 (October 21, 2026) fixed four CVEs and 9.20.29 (September 16, 2026) fixed two.
Mailing list: bind-announce, which ISC recommends for vulnerability notices. Public disclosures also go to bind-users.
Policy: ISC’s disclosure policy. Paying support customers get notice three to five business days ahead; operating system packagers get up to 24 hours ahead through the openwall distros list. Fixed releases for all supported branches come out on the day of public disclosure.

Distributions build their updates after that notice, so the fixed package for your system can arrive a little after ISC’s release. Watch your distribution’s advisories too (following security advisories), and check our vulnerabilities page for current issues.

Hardening tips

Separate roles: authoritative servers should have recursion no;, and resolvers should not serve public zones.
On resolvers, limit who may query with allow-recursion and allow-query-cache set to your own networks. An open resolver gets abused for traffic amplification.
Set allow-transfer explicitly to your secondaries, ideally with TSIG keys.
Keep the rndc control channel on 127.0.0.1 and the rndc.key file readable only by root and the BIND user.
Run named as its unprivileged user (distribution packages do this by default) and keep the firewall closed except port 53 UDP/TCP. See firewall basics.
Consider response rate limiting (rate-limit) on authoritative servers.
Leave DNSSEC (signed DNS answers) validation on for resolvers, and monitor that your zones still resolve after every update. If records change unexpectedly, see DNS hijack response.