 BIND
Management Using ProBIND
Mark Barrow
I was recently hired to sort out the management of a clients BIND
DNS servers. They had deployed multiple BIND DNS servers running
on Solaris to serve both internal and external DNS for themselves
as well as primary and secondary DNS services for many of their
customers. The current solution involved editing the zone files
on each master server (Internal/External), then reloading the DNS
into a test namespace to check for errors (using nslookup, etc.)
before deploying to the production namespace and running a Perl
script to reload all of the servers. Although extremely stable,
it was necessary that skilled sys admins spend a lot of time managing
the solution. They wanted a solution that that could be maintained
by other office staff.
I was asked to investigate GUI-based management products that
could replicate this functionality and decrease the sys admins'
workload. Furthermore, the client wanted to stick with BIND because
it had been extremely stable in production. This is how I encountered
ProBIND, which seemed to fit the bill perfectly.
ProBIND is an open source PHP/MySQL-based Web application that
can be used to distribute DNS data to multiple BIND 8/9-based DNS
servers. It is currently maintained by Alexi Roudnev at: http://probind2.sourceforge.net.
ProBIND holds all the data on zones and servers in a central MySQL
database. This is a one-way relationship, which means that if you
currently use BIND you will need to import the current data first.
However, it's very easy to add new servers or rebuild failed ones.
Benefits of Using ProBIND
ProBIND is an easy-to-use Web interface that can be used to manage
multiple BIND servers and namespaces. ProBIND can automatically
populate your reverse zones as new records are added. With the Perl::DNS
module, ProBIND can be used to check the servers; all data is held
in a central database simplifying the backup process for multiple
DNS servers. ProBIND can be configured to authenticate users and
provides granular access through DNS-Admin or DNS-User roles.
The Solution
For the purposes of this article, the DNS infrastructure consists
of three external servers (two secondary and one hidden primary)
and two internal DNS servers (one primary and one secondary). See
Figure 1.
ProBIND was installed onto the external hidden master DNS server.
This was firewalled so that only the two external secondary servers
were directly accessible from the Internet, and only DNS queries
from the external secondary servers would be accepted through to
the hidden primary server. ProBIND was configured to manage the
two external secondary servers and the local primary in the external
namespace together with a primary and secondary in the internal
namespace. The test namespace was configured, but no servers were
assigned because it was used purely for user testing. Note that
ProBIND and the database it uses could have been installed on separate
machines. However, as ProBIND uses minimal resources, both were
installed onto the current hidden master.
ProBIND displays the DNS data as it is in the database rather
than querying the servers directly. The ProBIND GUI can be used
to do almost anything that was previously only available through
the command line.
When you have finished editing, selecting PUSH from the GUI runs
a PHP script that generates the BIND config files and zone files
locally, then uses rsync over SSH to copy these to the master servers
(secondary servers only get the config files) then reloads all the
servers (using rndc over SSH). There is also an option to PUSH all
data, which is useful if the servers have somehow gone out of sync
or when recovering a failed server.
Prerequisites
In order for ProBIND to function correctly, it's necessary to install
the following prerequisite software:
- MySQL (3.23 and above).
- Apache (1.3 and above).
- PHP (4.0 and above) -- Register globals needs to be on, and
PHP needs to be able to run from the command line as well as through
the Apache module.
- Rsync (2.61 and above) -- Used to replicate to remote BIND
servers.
- Perl 5 Perl Net::DNS SSH.
Installing ProBIND
The latest version of ProBIND (2.01 at the time of writing)
can be downloaded from http://probind2.sourceforge.net,
but first install the prerequisites. The ProBIND distribution
contains a more detailed installation. For further information,
see Install.txt.
It is recommended that you install ProBIND in /var/ProBIND
and then link to it from your Web root. To manage both internal
and external DNS using ProBIND, you must install three instances
of ProBIND (internal namespace, external namespace, and a test
namespace for trying things out):
mkdir /var/ProBIND
cd /var/ProBIND
#copy the downloaded probind tar-ball to here
gunzip ProBIND2.0-build1.tar.gz
tar xvf ProBIND2.0-build.tar
mv probind internal
tar xvf ProBIND2.0-build.tar
mv probind external
tar xvf ProBIND2.0-build.tar
ProBIND comes with a basic html front page that can be used to
manage the multiple namespaces. To use this:
cd /var/ProBIND
cp /probind/parent/* .
ln s probind/images images
This default front page has a space for inserting your own DNS-monitoring
utility. If you don't have one, see Listing 1, which can be run
from cron as the user that owns the doc root.
On the ProBIND host, Apache needs to run as the same user
that will SSH to the remote servers. In my case, I created a
user called probind, under which the Web server runs and which
can SSH without a password to all DNS servers and reload BIND.
Create ProBIND working directories (used by ProBIND to generate
config and zone files prior to copying to servers) and allow
the Web server to write to them.
Carry out the following in each namespace:
Mkdir HOSTS
Mkdir LOGS
Chown probind HOSTS LOGS
Create a .htaccess file in each of these directories to enable
the Web server to list the contents. Without this, it is likely
you will be unable to navigate and view the BIND zone files stored
in the local file system that ProBIND rsyncs to the local and
remote servers:
cat > HOSTS/.htaccess
Options Indexes
FancyIndexing on
^D
cat > LOGS/.htaccess
Options Indexes
FancyIndexing on
^D
Set up the initial MySQL database and ProBIND user (note password
in "identified by"):
/usr/local/mysql/bin/mysql u root p - mysql -u root -p
create database extdns;
grant select,insert,update,delete on extdns.* to \
'pbext'@'localhost' identified by 'password';
quit
Initialize the database from the ProBIND SQL file:
/usr/local/mysql/bin/mysql -u root -p extdns <etc/mktables.sql
Edit inc/config.inc to match your details. For example:
$TOP = "/var/ProBIND/extdns";
$TMP="/tmp";
$MYSQL_HOST = "localhost";
$MYSQL_DB = "extdns";
$MYSQL_USER = "pbext";
$MYSQL_PASSWD = "password"; // Set up password here
$NAME_SPACE = "EXTERNAL";
To avoid having to add /usr/local/bin to the path of all the remote
servers (which is not usually set in Solaris), edit the shell
script sbin/push.remote. Change the lines:
RSYNC="-b -p -t -r --exclude='*.b,CVS,SEC,*.pid' --cvs-exclude --suffix=.bck"
User=named
to:
RSYNC="rsync--rsync-path=/usr/local/bin/rsync -b -p -t -r --exclude='*.b,CVS,SEC,*.pid'
\ --cvs-exclude --suffix=.bck"
User=probind
Configure the ProBIND GUI
Use your browser and navigate to http://probindservername/probind
and repeat the following for each namespace you manage.
Click the "Misc. tools" link in the top frame, then select
"Settings" in the sub-menu. Change the settings to reflect your
site. In my client's configuration, we set slave_on_slaves and
two_step_update to "on".
Create new template directories for master and slave servers
(or set up a directory for each server if you want different
configurations on each):
mkdir /var/ProBIND/extdns/templates/Master
mkdir /var/ProBIND/extdns/templates/Slave
For BIND version 9 servers:
cp /var/ProBIND/extdns/templates/v9-master /var/ProBIND/extdns/templates/Master
cp /var/ProBIND/extdns/templates/v9-slave /var/ProBIND/extdns/templates/Slave
Edit rndc.conf and named.conf to make sure that the key used by
BIND rndc to control the servers matches.
For BIND version 8 servers:
cp /var/ProBIND/extdns/templates/v8-master /var/ProBIND/extdns/templates/Master
cp /var/ProBIND/extdns/templates/v8-slave /var/ProBIND/extdns/templates/Slave
The file named.tmpl in the above directories is used by ProBIND
to generate named.conf at push time. If you have any specific
settings regarding logging, etc., add these to named.tmpl.
Configure Servers
Navigate to http://probindserveraddress/probind. For
each namespace, select "misc tools" from the Tab menu, then
select "servers" from the sub-menu. Select "Add another Server".
Update the settings for each of the servers you want to control
with ProBIND. If you intend to use a hidden master configuration,
you need to set the NS record to "Skip" for the hidden master
server to prevent the hidden master NS record being published
in the DNS.
Once the server is set up, a link to this server should appear
on the server's screen. Clicking on this link will allow you
to set specific options per server in ProBIND rather than having
to manually edit the named.tmpl file.
Import Script Caveats
ProBIND includes an import script to allow you to import. However,
ProBIND cannot support the include statement with named.conf,
which means a new named.conf must be created from the concatenation
of masters.conf and slaves.conf.
During evaluation, a bug was discovered in that the import
script fails if the named.conf uses the following (correct)
format:
zone "blconsulting.co.uk" in {
type master;
file "master/db.blconsulting.co.uk";
allow-transfer { blc-slaves; };
};
To work around this, edit and replace with this:
zone "blconsulting.co.uk" {
type master;
file "master/db.blconsulting.co.uk";
allow-transfer { blc-slaves; };
};
The data is then imported as follows:
cd /var/ProBIND/extdns/etc
./import -v -a -d /path to old named.conf/named.conf
The import also imports the zone options. For example, if you
set allow-transfer {slave-servers;};, where slave-servers
is an alias for all your slave servers, the name "slave-servers"
must be changed after import to {$ACL }. ($ACL gets
converted by ProBIND to the IP addresses of each server managed
by ProBIND at push time.) The easiest way to do this is by using
an SQL query. For example:
/usr/local/mysql/bin/mysql u root p - mysql -u root -p extdns
update zones set options='allow-transfer{ $ACL };' \ where options like
'%slaves-servers%';
Query OK, 38 rows affected (0.00 sec)
Rows matched: 38 Changed: 38 Warnings: 0
Using ProBIND
Use of ProBIND is pretty straightforward. For instance, editing
zones is simply a case of clicking on the zone listed on the
left-hand side, as shown in Figure 2. Then you can make the
required changes by selecting "Push Updates". You can review
the changes before sending them to each server by clicking on
named.conf or file links under "View", perform nslookup queries
against each server using "Test", or push the changes to all
or individual servers by clicking on "Start Update" (Figure
3).
Customizations
During the implementation, I discovered that there was no easy
way to get ProBIND to copy per zone options to secondary servers
(although this worked fine to the primaries). Because this was
a requirement for the client, I wrote a patch for ProBIND to
support it. If you are interested in this patch, just send me
an email and I'll share it.
Mark Barrow is a Senior Technical Consultant specializing
in UNIX/eCommerce working for Business Logic Consulting LTD.
He can be contacted at: mark.barrow@blconsulting.co.uk.
| 
