GnuDIP Release 2.3 - Back End INSTALL File
Releases of BIND prior to 8.2.3 and the
DNS server software do not support dynamic DNS in the fashion prescribed by
the IETF RFC-s, and cannot be updated using the
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
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:
mkfifo). The fifo may be created anywhere, but
/usr/local/gnudip/run/would be an obvious place for it. Ensure that it is owned by and writable by user
nobody" that GnuDIP runs as), with no access by any other user.
Three attributes must be provided in
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
nsupdate command with the back end client
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
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
to start at system start up using a command line like:
Where you put this command line depends on the flavor of UNIX you have.
For Slackware Linux it would go in
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
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:
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.
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
These scripts are very simple because they each use a database scan script provided with GnuDIP:
gdipbind.plfor 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 -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
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.