Note: This article was written alongside BIND 10 1.0.0-beta. See this article which covers the major differences to be aware of between 1.0.0-beta, and 1.0.0-rc.

I’ve been an avid BIND 9 administrator for many years, and have found its configuration to be straightforward and the software itself to be reliable and RFC compliant wherever I’ve taken the time to check RFC compliance. My only criticism of BIND 9 was not being able to easily and instantly provision new zones (e.g. requiring an rndc reconfig to add new zones), without the use of DLZ (Dynamically Loadable Zones). DLZ (http://bind-dlz.sourceforge.net) development stalled a long time ago, and the DLZ configuration was far from logical in my opinion. I moved away from BIND to PowerDNS for this very reason (I wanted zones provisioned instantly – i.e., as soon as they hit the backend DB, they’re live). However, with the new release of BIND being developed by ISC, everything is about to change – including the storage of zone data within a database. From the processes that actually comprise BIND to the configuration itself, it’s all different. BIND administrators are in for a big surprise the first time they get a chance to play with BIND 10. This article has been written to guide BIND administrators who have intermediate/advanced BIND 9 skills through their first steps with BIND 10.

BIND 10 will replace BIND 9 and ISC DHCP, and thus BIND 10 comprises processes to handle both authoritative and recursive DNS, as well as DHCPv4 and DHCPv6.

BIND 10 is still in development, and this article has been written around the current release (BIND 10 1.0.0 beta). SQLite is the only supported backend at present (except for DHCPv6 which confusingly supports only MySQL).

I’m sure ISC will release a coherent product as development continues, but in my opinion they have released a confusing and very incomplete beta version of BIND 10. The BIND 10 Guide (http://bind10.isc.org/docs/bind10-guide.html) is the current authoritative source of documentation, and the BIND 10 Wiki (http://bind10.isc.org/wiki) can be used to track development/releases.

I will do my best to give BIND 9 admins an interesting overview of getting BIND 10 up and running on a fresh CentOS install, and will demonstrate some of the features available, basic configuration, architecture of the new software and so on.

Stand by guys – it’s going to be odd. Very odd. I’ll be posting new articles as I learn more about BIND 10, so what you read in this article may be superseded by a later article (once I find a better/correct way of doing something, or BIND 10 itself changes).

Building BIND 10

My BIND 10 testbed is a fresh install of CentOS 6.3 x86_64 inside a Virtual Machine. I selected the Minimal package set, and as such will need to install a few prerequisite packages prior to building BIND 10. Some packages are not provided in the CentOS repositories (and in the case of Python, only Python 2.x is provided and we need Python 3.x), and in those cases I’ll show you how to install those packages too.

If you’re not running CentOS 6.3, check the system-specifc notes page on the BIND 10 wiki (http://bind10.isc.org/wiki/SystemSpecificNotes) to see if there are notes on building BIND 10 for your OS. If not, you should find that this article together with those notes are enough to get BIND 10 up and running.

First, install as many of the prerequisite packages as you can from the CentOS repositories. For building BIND 10, you will need gcc-c++, make, automake, libtool, boost, boost-devel, sqlite-devel. For Python, you’ll also need openssl-devel, bzip-devel, expat-devel, gdbm-devel, readline-devel. Install those packages first via yum.

Once all packages have been successfully installed, you can proceed to build the prerequisites that are not supplied within the CentOS package repositories. We will need to do this for Botan (http://botan.randombit.net), log4cplus (http://log4cplus.sourceforge.net/) and Python 3.2 (http://www.python.org).

Start with Botan. I presume that all source code tarballs have been downloaded to /usr/local/src.

Next, log4cplus:

Finally, Python 3.2 (3.1 also works):

OK - all our prerequisites are installed and we’re ready to build BIND 10 itself.

BIND 10 is now installed and ready for use.

Starting with the Processes

Before starting BIND 10 for the first time, it’s worth reviewing the BIND 10 Guide and understanding the process architecture of BIND 10 and how it differs from BIND 9.

BIND 9 had a single process - named. Depending on your OS and build-time options, this may or may not be a multi-threaded process. In BIND 10, there are a myriad of processes, as the software has been redesigned to be modular - with the bulk of it being written in Python. This is generally a good thing, and the BIND 10 control channel makes managing these processes fairly easy - you don’t have to worry about starting/stopping each of them individually once you’ve configured the BIND 10 Boss process to start them for you (this will all be explained).

Let’s look at the various processes that comprise BIND 10 and learn what they actually do. This is taken verbatim from the BIND 10 Guide - why reinvent the wheel?

• b10-auth — Authoritative DNS server. This process serves DNS requests.

• b10-cfgmgr — Configuration manager. This process maintains all of the configuration for BIND 10.
• b10-cmdctl — Command and control service. This process allows external control of the BIND 10 system.
• b10-ddns — Dynamic DNS update service. This process is used to handle incoming DNS update requests to allow granted clients to update zones for which BIND 10 is serving as a primary server.
• b10-msgq — Message bus daemon. This process coordinates communication between all of the other BIND 10 processes.
• b10-resolver — Recursive name server. This process handles incoming DNS queries and provides answers from its cache or by recursively doing remote lookups.
• b10-sockcreator — Socket creator daemon. This process creates sockets used by network-listening BIND 10 processes.
• b10-stats — Statistics collection daemon. This process collects and reports statistics data.
• b10-stats-httpd — HTTP server for statistics reporting. This process reports statistics data in XML format over HTTP.
• b10-xfrin — Incoming zone transfer service. This process is used to transfer a new copy of a zone into BIND 10, when acting as a secondary server.
• b10-xfrout — Outgoing zone transfer service. This process is used to handle transfer requests to send a local zone to a remote secondary server.
• b10-zonemgr — Secondary zone manager. This process keeps track of timers and other necessary information for BIND 10 to act as a slave server.

BIND 10: Starting Up

Now that BIND 10 is installed, and we know a little about the processes that may run (not all of them will be running; in fact, when you start BIND 10 for the first time only a few required processes will be running), we can start BIND 10 for the first time. As per the BIND 10 Guide, the <BIND_10_BASE>/sbin/bind10 command is used to start the server - this is the BIND 10 master (Boss) process, and will start all required sub-processes and will restart “some” processes that exit unexpectedly (though the documentation doesn’t make it clear which processes it will restart).

Let’s start out server:

What madness is this - it runs in the foreground, attached to our terminal! /sigh. Even the BIND 10 Guide makes reference to “using another terminal” to perform other tasks while leaving the bind10 process running in the foreground. Obviously this is nonsense, and useless for any real production purposes. For now, observe the log messages outputted to your console, and you’ll see:

BIND 10 is up and running! Hit ^C to shut it back down again - observe the messages until:

For now (until we write an init.d script), you can use bind10 back up using nohup so you can ditch your session if you want to. Another alternative until BIND 10 is daemonised properly is to run it in a screen session. I can’t see the ability to easily chroot BIND 10 at this point either - but a bind10 -h does show a -u option for running BIND 10 as a different user after startup (though it must obviously be started as root so it can bind to port 53 initially before dropping its privileges).

Let’s add a user specifically for BIND 10 (try and make this beta software at least partially secure), and see if it works as expected:

As you can see all processes are running as the bind10 user, as expected. As well as the bind10 process itself, four additional python3 processes are running (you can refer to the bullet list above to find out what they’re for), and as previously mentioned, no actual DNS/DHCP components are enabled - only the core processes required for messaging and command control within BIND 10 itself are running out-of-the-box.

bindctl and Shutting Down BIND 10

In the beta release of BIND 10, bindctl is the only administrative interface provided to configure and control your BIND 10 server. I’ll provide a cursory introduction to bindctl here, and use it to shut down the BIND 10 server we now have running in the background (if you’re running in the foreground as per the default behaviour - just hit ^C to shut the server down). Later, I will configure bindctl properly and use b10-cmdctl-usermgr to create an account other than the default out-of-the-box root BIND 10 account.

bindctl can be found in <BIND_10_BASE>/bin - which we will use to connect to our server and, in this initial case, shut it down. We haven’t changed any of BIND 10′s port bindings, so it’ll connect to the default address of the b10-cmdctl module - 127.0.0.1:8080. First, let’s verify

So we can see that b10-cmdctl is indeed listening on port 8080/tcp. Time to connect with bindctl:

As you can see, bindctl spits out “TEMP MESSAGE”, giving us the default credentials to use to connect. Once I start playing with b10-cmdctl-usermgr I’ll see if there is a way of removing this default account and creating a proper (i.e. secure and non-default) administrative account. For now, we know that we want to shut down the Boss process. Type Boss help at the bindctl prompt to receive a list of commands we can issue against the Boss process :

Looks like a Boss shutdown will do the trick - let’s try:

The “Failed to send request message” is expected, as I hit enter when Boss shutdown returned me to the bindctl prompt. Checking our nohup.out:

Perfect - the Boss process (and thus all sub-processes) has been shutdown. We can confirm:

We have now seen how to build and install BIND 10, start it up (in the background), get it running as a designated user, connect to the command channel, and issue a command to shut BIND 10 down.

In the next article, I’ll use bindctl to configure BIND 10 to run as an Authoritative DNS Server.