BIND 9 in one process: authoritative server, resolver and forwarder

This GitHub repository is a mirror, not the place to file issues

The first thing to understand about this repository is that it is not the canonical home of the code. The repository description describes it as an archived mirror of the GitLab project at gitlab.isc.org/isc-projects/bind9, and asks that issues and pull requests or merge requests be submitted in GitLab instead. The homepage points at the GitLab project as well, and the README says the same thing in more detail: to report non-security-sensitive bugs or request new features, open an issue on the ISC GitLab server.

The mirror flag on the repository is not set, and the last push was on 2026-10-22, so the tree is being synced rather than frozen. That distinction matters if you plan to work on BIND yourself. The README explains the contribution mechanics on GitLab: by default, external contributors do not have the ability to fork BIND on the GitLab server, and if you wish to contribute code you may request permission to do so, after which you can create git branches and submit requests for review and merge. An alternative is to open a GitLab issue and attach a patch, preferably generated with git format-patch.

The mirror is still useful, and there are practical reasons to read it here rather than there. It carries the full documentation tree, the tests, the fuzzing and coverage directories, the CI configuration and the developer documentation, so a question about how the code is structured can be answered from this tree without cloning GitLab. Where the two differ, GitLab is the source of truth.

One more point about issue hygiene comes from the README. Unless an issue is explicitly marked confidential, it is publicly readable, and the recommendation is to obscure key secrets in any configuration you paste, which can be done automatically by using named-checkconf -px.

named can be authoritative, recursive and a forwarder in one process

BIND, the Berkeley Internet Name Domain, is described in the README as a complete, highly portable implementation of the Domain Name System protocol. The name server is named, and the sentence that defines the product is the one about roles: it can act as an authoritative name server, recursive resolver, DNS forwarder, or all three simultaneously.

That last clause is the design fact to carry away. A single daemon process can hold a copy of the zones it is authoritative for, answer recursive queries for clients on its own, and forward queries to upstream resolvers, and the configuration decides which of those a given instance does. An operator running a small authoritative service often ends up with one of these processes doing all three jobs, and BIND is built around that rather than treating each role as a separate product.

BIND 9 itself began as a complete rewrite of the BIND architecture used in versions 4 and 8. Internet Systems Consortium, described as a 501(c)(3) US public benefit corporation dedicated to providing software and services in support of the Internet infrastructure, developed BIND 9 and remains responsible for its ongoing maintenance and improvement.

For a detailed list of changes across the history of BIND 9, the README points to the changelog at doc/arm/changelog.rst, and for up-to-date versions and release notes it points to the ISC download pages. Those two references are the practical answer to the question of what a given BIND 9 version contains.

Views, catalog zones, RPZ and rate limiting are the operational payload

The advanced feature list in the README is really a list of operational problems that a large DNS deployment has to solve, and it is where BIND 9 earns its complexity.

Views implement split-horizon DNS, which is the mechanism for returning different answers to the same question depending on where the query came from. An internal resolver can see private addresses for an internal zone while an external one sees the public addresses, and that stays inside one named process rather than requiring two.

Automatic DNSSEC zone signing and key management handles the cryptographic side of zone publication, so an operator does not have to run the signing as a separate scheduled job. Catalog zones facilitate provisioning of zone data throughout a name server constellation, which is the mechanism for pushing a zone to a fleet of servers instead of copying it to each one.

Response policy zones, RPZ, protect clients from malicious data by rewriting answers that match a policy, which is a defensive use of the resolver rather than a signing feature. Response rate limiting, RRL, and recursive query limits reduce distributed denial of service attacks, which matters because a resolver on a network edge is the obvious target.

The trade-off is real and worth stating plainly. Every one of these is configuration surface area, and a misconfigured view or policy zone can cause outages that look like upstream DNS problems. BIND 9 is not a small program, and the operational skill it demands is part of what you are adopting.

The administrative tools are as important as the daemon

BIND ships a suite of administrative tools, and in practice they are what an engineer touches daily.

dig and delv are the DNS lookup tools, with delv being the one built for DNSSEC validation, so it can tell you whether a chain of trust is intact rather than just what the answer was. nsupdate performs dynamic DNS zone updates, which is how a host registers and deregisters itself or updates a record without a human editing a zone file. rndc provides remote name server administration, so a change to a running named can be made without restarting it or logging into the box.

A fifth tool appears in the bug reporting section rather than the feature list. named-checkconf -px checks a configuration file, and the -px option obscures key secrets automatically, which is why the README recommends it before attaching a configuration to a public issue.

This tool set is a genuine reason to prefer BIND over a narrower resolver. A team that already knows dig and nsupdate can operate BIND with familiar commands, and a team that has to learn a different toolchain for lookups, dynamic updates and remote control is learning three things instead of one. The counterargument is the size of the surface: each tool is another program with its own options and its own failure modes, and rndc in particular implies a control channel and an authentication configuration that a simple forwarder never needs.

Building with meson and running the pytest system suite

For information about building BIND 9, the README directs you to the Building BIND 9 section of the BIND 9 Administrator Reference Manual, and the repository is set up for meson. The presence of meson.build, meson.options and meson.format at the root is the confirmation, and the manual and the build tree are meant to be read together.

The automated testing story has two layers, and the second one has a prerequisite worth knowing before you start.

The system test suite is run with pytest bin/tests/system. These tests require you to configure a set of virtual IP addresses on your system, which allows multiple servers to run locally and communicate with each other, and they are configured by running the command bin/tests/system/ifconfig.sh up as root:

pytest bin/tests/system

bin/tests/system/ifconfig.sh up

The root requirement and the virtual IP addresses are the friction point here. The suite needs to bind addresses that a normal test run cannot use, so it needs privileges, and on a machine where those addresses are already taken the suite will not behave as documented.

The dependencies degrade gracefully. Some tests require Perl and the Net::DNS and or IO::Socket::IP modules and are skipped if those are not available, and some require Python and the dnspython module and are skipped if that is missing. Unit tests are implemented using the CMocka unit testing framework, built with the option -Dcmocka=enabled, and executed through the meson test functionality:

meson test

So the full picture is a Python driven system suite for behaviour, a C unit suite for internals, and a skipped-test policy when the language runtimes are absent. The repository also carries fuzz/, cocci/ and gcovr.cfg, so there is coverage and fuzzing infrastructure in the tree as well.

The Administrator Reference Manual ships with the source tree

The documentation is part of the distribution rather than a separate site, and that is a deliberate choice worth noting. The BIND 9 Administrator Reference Manual is included with the source distribution in .rst format in the doc/arm directory. The HTML version is generated automatically and published at bind9.readthedocs.io, and man pages for some of the programs in the distribution are also included in the manual.

The PDF can be built from the same tree. The README gives the two commands, and notes that TeX Live is required and that the result lands in a specific path:

meson setup build
ninja -C build arm-pdf

The output file is written to build/arm-pdf/latex/Bv9ARM.pdf.

There are also other README files scattered through the source tree, which the README points to as additional information on various subjects. That is worth knowing when you are diagnosing something: the notes closest to a subsystem usually describe its quirks.

For questions rather than instructions, the README directs readers to the ISC Knowledgebase at kb.isc.org for frequently and not-so-frequently asked questions, and to the BIND Users mailing list for discussion. Professional support and training for BIND are available from ISC, and the README gives the contact page for it.

MPL-2.0 licensing with an explicit upstream and support boundary

BIND is open source software licensed under the terms of the Mozilla Public License, version 2.0, and the source headers carry the SPDX identifier MPL-2.0. The file-level licensing is handled with the REUSE specification, with a REUSE.toml at the root, a LICENSES/ directory and a COPYRIGHT file that the README refers to for additional information about copyright ownership.

MPL-2.0 is a file-level copyleft licence, which is the practical point for a team considering modification and redistribution. That is a licensing question with real consequences for how you ship a patched BIND, and it belongs with the people who own your compliance obligations rather than with a summary on a website. The authoritative texts are the licence file and the COPYRIGHT file in this repository.

There is also a distinction between the software and the support around it. The README states that professional support and training for BIND are available from ISC, that ISC is a 501(c)(3) public benefit corporation, and that the ISC Knowledgebase and the BIND Users mailing list exist for questions. Security vulnerability reports follow a separate path documented in SECURITY.md, which is referenced from the bug reporting section.

The repository has no GitHub releases, so the release history lives on the ISC download pages and in the changelog inside the manual. With the last push on 2026-10-20, the mirror is current, and for the version you actually deploy, the Supported Platforms section of the manual is the document to read, since it states which operating systems a given release supports.

Editorial conclusion

BIND 9 is the right choice for an organisation that runs authoritative service for its own zones and wants recursion, policy and provisioning handled by one well documented daemon, and it is the right choice for teams that need the dig, nsupdate and rndc tooling to match. It is the wrong choice for a project that wants a minimal resolver with no authoritative role, since named carries the full server feature set whether you use it or not, and it is the wrong choice if you need to file issues in this repository, because the GitHub copy is a mirror and the README asks for issues and merge requests on the ISC GitLab server. Before adopting, read the Supported Platforms section in the BIND 9 Administrator Reference Manual for your operating system, and confirm that your deployment compiles from the meson build rather than relying on a distribution package.

Frequently asked questions

Official sources

1. isc-projects/bind9 on GitHub
2. Issues
3. License: MPL-2.0
4. Project website
5. README