GnuDIP Release 2.3 - Back End INSTALL File

Back End Scripts to Support BIND 8 and tinydns

Releases of BIND prior to 8.2.3 and the tinydns DNS server software do not support dynamic DNS in the fashion prescribed by the IETF RFC-s, and cannot be updated using the nsupdate command.

It is still possible to use early BIND releases and tinydns with GnuDIP. A few additional scripts are involved. These scripts use the configuration file gnudip/etc/backend.conf.

Each back end has an associated:

UNIX FIFO file,
reload command and
minimum interval between reloads.

You must create the FIFO (using mkfifo) in /usr/local/gnudip/run/ Ensure that it is owned by and writable by user nobody, with no access by any other user.

These three attributes must be identified to GnuDIP in backend.conf. using syntax similiar to:

fifo.mybackend   = /usr/local/gnudip/run/backend.mybackend
reload.mybackend = /usr/local/gnudip/sbin/gdiprlbind.sh mydomain
wait.mybackend   = 30

To use a back end for a particular domain, you replace the nsupdate on a per domain basis with the back end client gdipbkclt.pl script in gnudip.conf using a line like:

nsupdate.mydomain = /usr/local/gnudip/sbin/gdipbkclt.pl mybackend

It must be passed the back end name as an argument. It indicates that an update for the specified domain is needed by writing the back end name to the FIFO.

You may have multiple domains for the same back end.

You must also set up the back end server script gdipbksrv.pl to start at system start up using a command line like:

/usr/local/gnudip/sbin/gdipbksrv.pl mybackend

Where you put this command line depends on the flavor of UNIX you have. For Slackware Linux it would go in /etc/rc.d/rc.local. You will have to determine where it goes on your system. For testing puposes you may start this server from the command line. It must also be passed the back end name as an argument.

This server script will run your back end reload command ("/usr/local/gnudip/sbin/gdiprlbind.sh mydomain") when it is notified of an update, unless enough time has not passed since the last time it was run. In that case it will run the reload script as soon as allowed. The script will be run as the root user.

You will in general need to customize the back end reload script to your the particular GnuDIP installation. Two sample UNIX shell scripts are provided as a starting point:

gdiprlbind.sh for BIND 8 and
gdiprltiny.sh for tinydns.

These scripts are very simple because they each use a database scan script provided with GnuDIP:

gdipbind.pl for BIND 8 and
gdiptinydns.pl for tinydns.

The first sample script, for BIND, takes a domain name as an argument. It scans the GnuDIP database for all users for that domain and generates input for a BIND 8 zone file.

The second sample script, for tinydns, never got written. If you can supply one please send a note to the mailing list.

Each reload script prefixes the output from the database scan script with additional input that is needed. It then initiates a DNS reload (i.e. on the local host).

You may require more sophisticated scripts for your environment.

The tinydns suite provides its own mechanism for detecting the changes to the domain file and performing an "incremental" zone transfer to secondary servers, using the rsync command. So if the primary tinydns server is on the GnuDIP machine, propogation of updates can be done in the normal way for tinydns.

Using BIND zone transfers to update secondary servers with early releases of BIND, while doing frequent zone reloads is problematic. The full zone transfers cause a severe demand on the network as the size of the zone grows. If you must use an early release of BIND, you may want to develop your mechanism for maintaining multiple servers.