txdyn - DYNDNS with djbdns

No liability for the contents of this document and the usage of the described software can be accepted. Use the software, concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility.

All copyrights are held by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.

Copyright (c) 2006-2007 by Frank Bergmann

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License ([GFDL]) , Version 1.2 published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and with no Back-Cover Texts.

For their software and the inspiration I received by their work I would like to thank D. J. Bernstein (djb) and Felix Leitner (fefe).

The following typographic and usage conventions occur in this text:

terminal view

Thanks to Machtelt “Tille” Garrels for this list of conventions.

Running my own nameservers (in one subnet) and having access to a server in a different subnet I thought about a DYNDNS solution. For a long time I used software by D. J. Bernstein including his software suite djbdns ([DJBDNS]) with its easy-to-use, small, fast, secure and reliable DNS-server tinydns. Therefore I wanted a DYNDNS solution with tinydns and as simple as tinydns.

To realize DYNDNS with tinydns you have to (continously) alter its database, the file data. Using ed, sed, perl or something similar would be a chaotic solution, no easy task to implement and can cause data loss. It seemed more easy to create the file data periodically. But data itself acts as the database for tinydns and what database should be the database for this?

Software engineers like DJB have shown that the filesystem and the files can be a easy-to-use database. With this idea in mind I started to write the main script create-data.sh. This script collects data from a file hierarchy (file contents and filenames) and creates a new data file. It's easy to use a webserver script to write DYNDNS data in this file hierarchy, it's easy to get an overview or search in the nameserver data and it's very easy i.e. to move a www-domain from one IP-address zo a different address:

[me@dns ip] mv 1.2.3.4/aliases/mydom.org 1.2.3.5/aliases/

.

The following text is taken from http://cr.yp.to/:

It works for Lycos. It works for citysearch.com. It works for pobox.com. It works for 1.85 million more .com's. It works for several of the Internet's largest domain-hosting companies: directNIC, MyDomain/NamesDirect, Interland, Dotster, Easyspace, Namezero, Netfirms, and Rackspace Managed Hosting. It'll work for you too.

djbdns is a collection of Domain Name System tools. It includes software for all the fundamental DNS operations:

djbdns also includes several DNS debugging tools, notably dnstrace, which administrators use to diagnose misconfigured remote servers.

The djbdns package includes three servers that publish local host information: tinydns, walldns, and rbldns. Every aspect of configuration was rethought from the perspective of an overworked administrator who has better things to do than play with DNS.

tinydns handles basic DNS service. The tinydns-data file format combines the flexibility of zone files with the convenience of modern zone-building tools. Host information is stored in one file. PTR records are handled automatically. Changes can be scheduled in advance, with TTLs handled automatically.

tinydns has several load-balancing features. It automatically selects a random set of 8 servers from a cluster of any size. It allows easy removal of dead servers by external monitoring tools. It also supports client differentiation, checking the client's IP address and choosing one of several clusters accordingly.

Databases for tinydns and rbldns are compiled into cdb format. The servers start responding immediately, even if the database is a gigabyte or more. (In contrast: BIND cannot answer questions until it has loaded all your data into memory.)

One site reported tinydns answering 6000 queries per second on a dual Pentium III-1000 using 40% of one CPU. That's real queries, not peak performance in lab tests.

While a new database is being compiled, the servers continue to answer queries from the old database. There is no gap in DNS service when the new database is finished. The old database is left in place if anything goes wrong.

Database compilation is very fast. One site reported tinydns-data taking under a minute on a Pentium III-550 to create a 350-megabyte data.cdb covering almost 300000 domains.

The following text is taken from http://cr.yp.to/:

daemontools ([DAEMONT]) is a collection of tools for managing UNIX services.

supervise monitors a service. It starts the service and restarts the service if it dies. Setting up a new service is easy: all supervise needs is a directory with a run script that runs the service.

multilog saves error messages to one or more logs. It optionally timestamps each line and, for each log, includes or excludes lines matching specified patterns. It automatically rotates logs to limit the amount of disk space used. If the disk fills up, it pauses and tries again, without losing any data.

The base directory for the script create-data.sh is the root-subdirectory of the tinydns-service: ​

The following description uses file and directory paths relative to this base directory.

The script create-data.sh creates a file ./data suitable for tinydns with the information it collects from the directory ./ip like it's described in before.

If the nameserver data in the ./ip directory will change frequently then create-data.sh must be started periodically in short intervals. This is the case if you want to use DYNDNS. One possible solution is a cronjob, another solution is to use tinydnsupdate which will call the script by make more often than a minutely cronjob.

create-data.sh creates a PID-file in the ./tmp directory to avoid multiple running instances.

create-data.sh does not create a new data-file if there were no changes of nameserver data in the ./ip-directory.

tinydnsupdate substitutes a cronjob for periodically calling create-data.sh. If even a minutely cronjob is not frequently enough for calling create-data.sh then this small helper tool can be used.

tinydnsupdate reads the environment variable TINYDNS_ROOT, does a chdir into this directory and calls make forever with breaks of 10 seconds.

Its working directory must be the directory which contains create-data.sh and its Makefile (default: /service/tinydns/root).

tinydnsupdate is designed to run under daemontools. You must create a directory for it, containing the tool itself, a daemontools run script and an env-directory with the file TINYDNS_ROOT. Here's an example:

$ cd /service/tinydns/root/tinydnsupdate/
$ ls -l
total 32
dr-xr-xr-x 2 tinydns tinydns 4096 Apr  9 14:22 env
-r-xr-xr-x 1 tinydns tinydns   62 Apr  9 14:22 run
drwx------ 2 tinydns tinydns 4096 Apr  9 14:22 supervise
-r-xr-xr-x 1 tinydns tinydns 1252 Apr  9 14:22 tinydnsupdate
$ cat env/TINYDNS_ROOT 
/service/tinydns/root
$ cat run
#!/bin/sh
exec setuidgid tinydns envdir ./env ./tinydnsupdate

As the example shows the directory can be set up in the tinydns root-directory. This tool must not run with root rights. It should be run as the user who may create the data-file. To start it you must create a symlink in the /service-directory to this directory:

$ cd /service
$ ln -s tinydns/root/tinydnsupdate

There are a few requirements to install/run the txdyn software:

Here's a sample installation for a quick start.