Export to BIND

Matt Simerson edited this page Jan 23, 2015 · 3 revisions

Export to BIND setup

There are 2 ways to export to BIND

  1. Run nt_export on the BIND nameserver

    This is generally only used when BIND is running on the same server as NicTool Server. Just configure the data directory in the web interface to export to /etc/namedb/nictool. If the nictool export user has permission to write there, it will. Otherwise, it exports to a data directory in the exports working directory, expecting you to export via method #2.

    One should not entertain using this method with remote BIND installs. The remote nameserver would need the mysql client installed and permission to connect to the NicTool database to export the data.

  2. Run nt_export on the NicTool server and push data to the remote NS

These directions assume you already have NicTool Server installed.

# cd /usr/local/nictool; mkdir ns1.example.com
# cd ns1.example.com
# ln -s ../server/bin/nt_export.pl
# su -m nictool -c ./nt_export.pl

If NicTool Server is set up according to the instructions, the export script will connect to the nictool database and display of list of your nameservers. Choose the correct NSID and run the export:

# su -m nictool -c './nt_export.pl -nsid 4'

You should see some output explaining what just happened:

nsid 4 reading DB settings from ../server/lib/nictoolserver.conf
nsid 4 has 256 zones, 0 changed, export dir (/etc/namedb/nictool) not writable, created /usr/local/nictool/ns1.example.com/data-ns1.example.com, exiting

The export just ran, but since no changes have been made since the last success export, it didn't export anything. So we force it to export:

# su -m nictool -c './nt_export.pl -nsid 4 -force'

And now we get export results:

nsid 4 reading DB settings from ../server/lib/nictoolserver.conf
nsid 4 has 256 zones, 0 changed, export dir (/etc/namedb/nictool) not writable, forced, retrieved 256 zones, exported, complete

If we look in your export directory, we'll see the appearance of a new directory, and a new file:

# ls
data-ns1.example.com    nt_export.pl        run

The run file has instructions for execution via daemontools, cron, or manually. The manual export is enabled by default and should look quite familiar. The data directory is populated with all the NicTool zones that publish to that NS. There's also a special file: named.conf.nictool. That file needs to be included in your main named.conf as described later.

Congratulations. Your data is sitting in BIND format, ready to get served. Now it needs to get pushed out to your nameserver.

Push the data to the BIND server(s)

If you were paying attention above, you may have noticed the error, "export dir (/etc/namedb/nictool) not writable" in the output. If you were going to run BIND locally (on the same server as the export process), then make that directory exist and writable, and voila, skip on ahead to Configure BIND. This scenario would most commonly exist for a NicTool install with only a single set of nameservers that use BIND zone transfer protocol to keep the remote NS data up-to-date. For everyone else, read on.

If NicTool can't write to the datadir defined in the web server configuration, then it exports into a local directory (as shown above). To get the data moved from there to the remote server, the export script has a -pfextra option you might have noticed in the run file. Let's see how it works:

# ./run
nsid 4 reading DB settings from ../server/lib/nictoolserver.conf
nsid 4 has 256 zones, 0 changed, forced, retrieved 256 zones, exported, test 1, compiled, test 1, copied, test 1, restarted, complete

Lets unpack that a step at a time. After doing the export (as above), 3 new postflight targets were run: compile, remote, and restart. The default "action" of each target is to run "test 1", which always succeeds. You'll also notice a rsync and ssh entry with a comment before it. Here is where the power of NicTool's exports come into play. You, the local site admin, can make those targets do anything you wish. You have complete control over exactly what happens after the export, through the power and simplicity of a Makefile.

# ls
Makefile       nt_export.pl@      run     data-ns2.cadillac.net/

Yessir, that's a standard Makefile. It has targets set up for each of the postflight commands and examples of how one would use it to export to BIND, NSD, and PowerDNS. Uncomment the entries that suit your needs. If your setup is a little different, you can tailor the Makefile to precisely fit your needs. After making changes, you can test it by running make compile, make remote or make restart in the export directory to test your handiwork.

Edit the Makefile, and uncomment the rsync and ssh commands in the BIND section. Add comments in front of the test 1 entries (or delete them) in those two blocks. Trigger another export:

# ./run
nsid 4 reading DB settings from ../server/lib/nictoolserver.conf
nsid 4 has 256 zones, 0 changed, forced, retrieved 256 zones, exported, compiled, rsync -az /usr/local/nictool/ns1.example.com/data-ns1.example.com/ bind@10.0.179.14:/etc/namedb/nictool/, copied, ssh bind@174.127.179.146 rndc reload
server reload successful, restarted, complete

And just like that, the data has been synced to the remote BIND server, and the server was reloaded.

Automate the exports

Look inside the run file, decide which deployment model you prefer, and set it up. Examples are provided for use with daemontools, upstart, and cron.

Configure BIND

Add an include directive within the options section of /etc/namedb/named.conf that includes the list of nictool zones:

include "/etc/namedb/master/named.conf.nictool";

Here are a few more settings that are appropriate for an authoritative only BIND nameserver:

recursion no;
allow-recursion {"none"};
allow-transfer {"none"};
version "NicTool BIND";

Adjust the listen-on directive, if necessary, and restart BIND.

nscd restart

Check your syslog logs (/var/log/[messages|system|etc]) and make sure BIND likes the data. Fix any errors it complains about, and if NicTool still allows errors to be entered, open an issue on the github issue tracker so that the validation can be improved.

Templates

Paul Hamby contributed support for zone templates. By default, a line such as this is added for each zone:

zone "example.com"  IN { type master; file "/etc/namedb/master/example.com"; };

Templates provide a way to customize the additions that NicTool makes to named.conf. Templates are configured by creating a 'templates' directory in the BIND export directory (as defined within the NicTool nameserver config). Populate the templates directory with a 'default' template, and/or templates that match specific zone names you wish to customize.

Example template

 zone "ZONE" {
    type master;
    file "/etc/namedb/master/ZONE";
    notify yes;
    also-notify {
        10.1.1.1;
    };
    allow-transfer {
        10.1.1.1;
    };
 };

Any instances of the keyword ZONE in a template are replaced by the zone name.