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.

In the previous article in the BIND 10 series, we saw 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 this article, we will see how BIND 10 needs to be configured to act as an authoritative DNS server. Further articles will deal with recursion, the DHCP components, and more as I investigate BIND 10 in more detail. I’m learning as I write too, so bear with me - BIND 10 is very new software, and is still in Beta stages of development - thus a lot of BIND 10 is still incomplete, or even where complete - incoherent - especially to a BIND 9 veteran like myself!

If you haven’t read the BIND 10: First Steps article, I suggest you go and do that now.

We will use bindctl to interact with the BIND 10 command channel. I’ve had a bit more time to dig into bindctl and what it actually does (and where it stores its configuration) so we will digress a little at first, and take a look at that.

bindctl: Where are my Configuration Commands Going?

Before we start issuing configuration commands via bindctl, it’s worthwhile knowing exactly where the configuration is stored, how bindctl interacts with b10-cmdctl, and in what format the configuration is stored.

Reviewing the BIND 10 Guide (points for counting how many times I refer to this document over all my BIND 10 articles), we can see that we communicate with the configuration manager over some administrative interface (in our case the only option at present is bindctl). The configuration manager provides a RESTful API, and writes the configuration out in JSON (JavaScript Object Notation). Or … as the Guide points out “a format loosely based on JSON”. I will sigh (/sigh) and continue.

As we’ve not provided any configuration commands as yet, the configuration DB does not yet exist. However, once we have, it will be available for review at <BIND_10_BASE>/var/bind10/b10-config.db. This file is of cursory interest, but should not be modified directly.

Enabling Authoritative DNS

It’s time to get BIND 10 to do some work for us - configuring it to serve DNS data for a simple zone. There will be many things to note along the way, so pay attention! When we left the last article, BIND 10 was shutdown, so make sure it’s up and running before continuing with this article. It’s running? Good - let’s carry on.

Looking at the BIND 10 Guide (hereafter referred to as the Guide - too much typing otherwise), we have two choices. We can either execute the predefined command set init_authoritative_server, provided with BIND 10, or issue the commands required manually.

In order to cement your understanding of bindctl, and BIND 10 configuration in general, I suggest entering the commands manually for now. Connect to your BIND 10 instance viabindctl:

Next, enable the appropriate components. Looking at the Guide, we have to enable b10-auth, b10-xfrin, b10-xfrout and b10-zonemgr. I’ll issue the appropriate commands required to enable the authoritative DNS service within BIND 10, and then go over the commands used and try to explain them as best I can using the available resources (i.e. the Guide - there isn’t much else). Let’s enable authoritative DNS:

OK - a lot has just happened. Firstly, we’ve enabled all four required components, using config add. b10-auth has the kind parameter set to needed. If a component fails at startup and its kind is needed, BIND 10 will shut down and exit with an error code. If it fails at some time after startup, it’ll be restarted. The dispensable kind is the default, and means that the process will be restarted if it fails (though it will not cause BIND 10 to fail to start if the component fails to start when BIND 10 initially starts up). The address parameter defines the address of the component used on the b10-msgq message bus. By convention, this is the name of the component less the b10-, and with the first letter capitalised. Thus, b10-xfrinhas the address Xfrin on the bus. Lastly, no configuration is written until we run config commit. After issuing the commit, a Boss show_processes shows that all our original components are still running, as well as the four new components we configured. Let’s exit bindctl now, and see what’s happened:

Running a netstat confirms that a Python process is listening on 0.0.0.0:53 - both TCP and UDP:

A quick look at the PID shows that it’s actually the bind10 process that listens on port 53 - NOT b10-auth:

b10-auth is running, however, and will handle the actual business-end of authoritative DNS. I’ve yet to test whether both the authoritative and recursive components can run on the same server.

Looking under <BIND_10_BASE>/var/bind10, we can see that b10-config.db has now been created:

We can view that configuration too:

You can now see why this file shouldn’t be modified directly. The more configuration we apply to BIND 10, the more complicated this file will become. Querying this configuration should also be performed via bindctl.

Before we move on to loading a zone or two into our new authoritative BIND 10 instance, let’s confirm that it is serving DNS data authoritatively. The trusty CHAOS class (CH) is present in a default BIND 10 authoritative server install, so we can query version.bind and friends:

If this were a Production server, I’d look to remove the CH class entirely, or modify the version of BIND being returned via a query for version.bind to an empty string or similar.

You will also observe that zone.sqlite3 has now been created. This is the default location of the zonefile database. Time to have a poke around in there.

Once we load some zone data proper, we’ll see the database being populated. I’ll park SQLite for now, and revisit once a zone has been loaded.

Loading a Zone

Let’s create a sample zonefile. I’ll presume that you understand basic zonefile syntax as defined in RFC 1035 section 5 and RFC 1034 (section 3.6.1):

The b10-loadzone command is used to load the zone. In the following example, the -c option to b10-loadzone can be omitted as we’re using the default database location - but I’ve specified it below to show how the full command is formed:

“Loaded (at least) 0 RRs” - hmm - you’d hope so. Let’s use sqlite to confirm that BIND 10 has actually loaded the zone into the sqlite database:

OK - we can see that BIND 10 has loaded a single zone with 7 resource records. Our original zonefile had 7 RRs so this is promising. Let’s dig further:

All of our zone data has been loaded correctly. Exiting SQLite, we can query BIND:

So, we’re now serving example.com authoritatively out of BIND 10. Let’s modify the SQLite backend directly and update the IP address for the example.com A record:

Let’s check it’s worked from BIND 10′s perspective:

Excellent. One thing to note is that within SQLite you can use the “.schema <tablename>” command to understand the (basic) schema employed by BIND 10.

Conclusion

This article has shown how to enable the authoritative DNS server component within BIND 10, and how to load a sample zone to demonstrate the ability of BIND 10 to serve this data. It’s also shown how to make trivial updates directly in the SQLite database.

In future BIND 10 related articles, I’ll look at the recursive component, zone transfers, ACLs and the DHCP components of BIND 10. Hopefully, the first two articles in this series will give you enough to get you started.

My recommendation is (obviously) to continue to use BIND 9 for any Production purposes - or better yet switch to PowerDNS as I did. I will also be writing an article on getting PowerDNS 3.2 up and running, so stay tuned to tokiwinter.com for that soon.