GnuDIP Release 2.3 - Back End INSTALL File

Back End Scripts to Support Legacy BIND 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.

At a minimum, this configuration file must contain a line defining the command used to log messages. In the sample file this is:

# logger command for backend server
logger = /usr/bin/logger -t gnudip-bkend

Each back end has an associated:

• UNIX FIFO file,

• reload command and

• minimum interval between reloads.

Three attributes must be provided in backend.conf for each back end. For example, the sample legacy BIND back end is defined by:

# name of fifo for dyn3.yourhost.com
fifo.oldBIND.dyn3 = /usr/local/gnudip/run/backend.oldBIND.dyn3

# command to actually reload dyn3.yourhost.com
reload.oldBIND.dyn3 = /usr/local/gnudip/sbin/gdiprlbind.sh dyn3.yourhost.com

# minimum seconds between reloads
wait.oldBIND.dyn3 = 30

The sample tinydns back end is defined by:

# name of fifo for tinydns
fifo.tinydns = /usr/local/gnudip/run/tinydns

# command to actually reload
reload.tinydns = /usr/local/gnudip/sbin/gdiprltiny.sh

# minimum seconds between reloads
wait.tinydns = 5

To use a back end by default for all GnuDIP domains, you replace the global nsupdate command with the back end client gdipbkclt.pl script in gnudip.conf using a line like:

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

To use a back end for a particular domain, you replace the nsupdate on a per domain basis using a line like:

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

The back end client script must be passed the back end name as an argument. The script will indicate that an update for the specified domain is needed by writing the back end name to the FIFO.

For testing puposes you should use this client from the command line:

# gdipbkclt.pl
usage: gdipbkclt.pl [ -h | backend ]
usage: Notify the backend server that that an
usage: update to the backend has occured. The 'backend'
usage: argument is used for look ups in backend.conf.
usage: -h: Print this usage message.

If the back end is for tinydns, you will need to specify an additional configuration parameter, either:

tinydns = YES

globally or

tinydns.mydomain = YES

for the per domain case. The Web Tool needs to know if a domain is being served by tinydns, in order to correctly validate MX values.

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. It must also be passed the back end name as an argument.

For testing puposes you may start this server from the command line:

# gdipbksrv.pl
usage: gdipbksrv.pl [ -h | [ -d ] backend ]
usage: GnuDIP backend server.
usage: Receive notififications that updates to the backend have occured,
usage: and initiate reloads. The 'backend' argument is used for look
usage: ups in backend.conf.
usage: -h: Print this usage message.
usage: -d: Debug - stay attached to current terminal.

This server script will run your back end reload command when it receives a notification on the FIFO, 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 particular GnuDIP installation. Two sample UNIX shell scripts are provided as a starting point:

• gdiprlbind.sh

  The script is for BIND. It 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.

• gdiprltiny.sh

  This script is for tinydns. It takes no arguments. It scans the GnuDIP database for all users (from all domains) and generates input for the tinydns-data utility.

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

• gdipbind.pl for BIND 8:

  # gdipbind.pl -h
  usage: gdipbind.pl [ -h | [ [-o | -a] outfile ] domain ]
  usage: Scans the database and generates BIND zone file input.
  usage: -h: Print this usage message.
  usage: -o: Specify file to write output to.
  usage: -a: Specify file to append output to.
  

• gdiptinydns.pl for tinydns:

  # gdiptinydns.pl -h
  usage: gdiptinydns.pl [ -h | [ [-o | -a] outfile ] [domain] ]
  usage: Scans the database and generates tinydns input to create domain
  usage: file. Scans for all domains unless "domain" is specified.
  usage: -h: Print this usage message.
  usage: -o: Specify file to write output to.
  usage: -a: Specify file to append output to.
  

Each sample 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.