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.

The third article in my series detailing the newest DNS software release from ISC - BIND 10 - will cover the configuration of zone transfers and dynamic DNS, both secured with TSIG. This article assumes you know a little about the new architecture of BIND 10 (I’ve written about it here).

I have two servers configured for this as follows, both running BIND 10 built as per my first article in the series:

No BIND 10 modules other than the default have been enabled at this point, and the servers have been started for the very first time. First, we need to perform some configuration of our master DNS server - ns1.example.com.

Master Configuration

I’ll work through the required master DNS server configuration in stages, explaining the steps as you follow along.

Connect to your master instance using bindctl. First, enable the required modules for an authoritative DNS service (b10-auth), also supporting outbound zone transfers (b10-xfrout):

See my previous article if this makes no sense at all. The configuration is committed, and a check of the logs will show the appropriate modules being started. You can also use Boss show_processes from the bindctl prompt.

Next, add your TSIG key (I generated mine with dnssec-keygen available with the bindutils package on many modern Linux distributions, or with the BIND 9 source):

The next piece of configuration is of the Xfrout module itself (which we refer to by its message bus address, not component name):

OK - a lot just happened there. I configured a new zone configuration (index 0, it’s the first one) with origin "example.com" and a transfer_acl that ACCEPTs only zone transfer requests from 172.16.18.172 (our slave’s IP) and encrypted using the TSIG key example.com.key. I could also have set up IXFR here, but with the current BIND 10 release there is no failback to AXFR should IXFR fail. So, AXFR will suffice.

Xfrout is now configured to allow zone transfers. We still need a way of updating the zone (without manually altering the backend) and allowing NOTIFYs to work. DDNS is the way to go here. When the b10-ddns module receives an update (from nsupdate, for example), it sends a NOTIFY to b10-xfrout, which in turn sends out NOTIFYs to all NS records (other than itself) present in the database backend for the updated zone.

To handle this, enable the b10-ddns module as well as the zone manager - b10-zonemgr:

Run Boss show_processes and make sure the modules are enabled and the processes are running. Finally, configure DDNS so that it is aware of example.com, and will only accept updates from clients using TSIG key example.com.key.

Slave Configuration

A number of configuration steps must now be performed on the slave server, ns2.example.com. Start by enabling the appropriate modules required for authoritative DNS service, inbound zone transfers and zone management (b10-auth, b10-xfrin and b10-zonemgr respectively):

Confirm all is well with Boss show_processes. Add your TSIG key, ensuring it is identical to the master key (otherwise zone transfers will obviously fail):

Next, configure Xfrin and Zonemgr as follows:

Now that you’re getting to grips with the BIND 10 way of doing things, you should see what we’re doing above - configuring Xfrin to get example.com (name) from 172.16.18.169 (master_addr) using the example.com.key (tsig_key) TSIG key. Note, we also have to add a secondary_zones definition so that Zonemgr can handle the management of the slave zones.

Loading a Zone, Dynamic Updates and More

If you’ve got this far, load an example zone in to the master instance:

The zone should be instantly provisioned on the master, and a NOTIFY sent to the slave, who duly performs an AXFR of the zone. Run dig against both nameservers to ensure they both have the same copy of the zone loaded:

The master BIND logs will show messages such as:

And the slave should show:

The slave complains about the SOA record not existing - which is fine as this is a new zone and will not be present in the slave’s database at first.

Connect via nsupdate, and add a new resource record to the zone:

If you receive a NOTAUTH(BADKEY) response, check you are using the correct TSIG key for your zone update.

If all went well, in the master BIND logs you should see something like:

And on the slave:

Awesome stuff. Zone transfers, TSIG and DDNS are all working as expected under BIND 10.

If you need to manually send notifies for a zone, you can do so using bindctl from the master as follows:

And if you need to manually retransfer a zone from the master to a slave, log into the slave via bindctl and issue:

A Note About Xfrout

When initially using nsupdate after configuring DDNS, b10-ddns was unable to notify b10-xfrout that an update had been made, and this no notifies were sent to the slaves. The following message was noted in the master BIND logs:

I tried shutting down the Xfrout module, to let the Boss restart it:

Uh-oh! Out to the shell for a bit of kill -9 … Then the Boss restarted it anyway.

And, not during the course of this article - but worth noting here anyway, on another system Xfrout failed to send notifies for a newly added zone, complaining:

This was fixed with (again):

The Boss process then automatically restarted Xfrout - the desired effect. So - the Xfrout module does seem to be a little buggy and has needed a couple of restarts to make it work as configured.

Conclusion

This article has guided you through the configuration of outbound and inbound zone transfers, TSIG and Dynamic DNS with BIND 10.

Whilst the configuration is manageable, I’ve yet to load additional zones and evaluate the administrative complexity of the configuration. With even a few hundred zones configured for transfer, I can imagine using bindctl to be quite cumbersome. However, more interfaces are promised, and even bindctl could be wrapped and scripted with a slightly friendlier interface if you felt like it.