http:// / djbdns /

djbdns information

I am using djbdns instead of bind for my own DNS servers as well as any machines I may install for my employers and clients. The reason for this choice was originally security, but I have since found djbdns to be faster than bind, more flexible than bind, easier to configure, and much better able to tolerate high-load situations such as "floods" and other denial-of-service attacks.

I have developed a few pieces of add-on software for the djbdns system. If you are interested in using these packages, I highly recommend that you become familiar with how the various djbdns programs work (as well as being familiar with how to run your own system.)

Please understand that I am willing to help people with this software, however I cannot provide support beyond the scope of my own programs (at least not for free.) Questions which do not pertain to my own software should be researched on one of the other djbdns web sites, or asked on the djbdns mailing list.


This page tells how to use tinydns to set up a DNS poison server and block certain domain names from being able to resolve (to block banners, spam, and other undesirable traffic from being able to go through.) This page tells how to do the same thing, for people who are still using BIND.

This page tells about an extension of the "DNS poison server" idea, where the list of domain names to be blocked is contained in a single text file instead of a directory full of files. It's currently implemented as a perl script which reads the text file and creates the directory full of files, but I will be writing a patch to make dnscache read the text file directly.

This page explains how to set up dnscache on a Mac OS X system. DJB's instructions don't cover how to do this, because the mechanisms for managing userids and for making services start when the system boots are totally different from most other *nix systems.

This page explains how I am replicating my tinydns data from my master DNS server to the slave servers.

This page explains how to set up dynamic DNS names which automatically update themselves to point to a machine whose IP changes over time, such as a laptop, or a desktop machine on a cable or DSL connection.


I've written two patches which change how djbdns works, primarily the rbldns program. The first one lets rbldns return different IP addresses and TXT records for different RBL entries. The other one lets rbldns reply to queries within more than one domain name.

This page has the information about the patches.


zone-convert is a script I wrote long ago, which converts BIND zone files to tinydns "data" lines. I haven't really had time to document it, but if you want to try it, let me know if it works for you.

Note that the input to the script should be an actual zone file, not a "named.conf" file. At one point I had a higher-level script than this, which read the named.conf file and found the zone files automatically, but I don't know what happened to it- and to be honest, as often as the syntax of that file has been changed, it would only work with the specific version of BIND that I was testing it with anyway.

When you run it, if the zone file doesn't have a "$ORIGIN" line before any real records, you will need to specify the domain using the "-o" option, like so:

$ ./zone-convert -o

2009-04-05 I had occasion to actually USE this today, and found a few issues with it. I've pretty much re-written the tokenizer logic, now it works fairly well. I also added a few more command line options:

Debugging options

Turns on debugging messages. This is mostly for my own benefit, however if you're modifying the code, you might need it. Technically, this option makes the debug() function print its parameter- normally it just returns without printing anything.
Shows the source lines being read. At one point I needed this as a separate debugging option, now I'm not sure whether to remove it or not. I tend to think it's easier for me to just leave it there.
Dumps the stream of tokens after reading the input, and then exits the program. This forces the "-d" and "-s" options on as well.

User options

-o domain
Some BIND administrators use the same zone file for multiple domain names by not having a $ORIGIN line within the file. This option sets the domain name within which any names not ending with "." are assumed to exist. If this option is not specified and any records are found without dot-terminated names, and no $ORIGIN line was seen before them, the program will throw an error because it doesn't know which domain name to add to the end of the name.
Some BIND administrators mistakenly add "localhost" lines to every zone file. This can lead to problems, and is not recommended. This option causes any A records whose names start with "localhost", pointing to IP addresses starting with 127, to not be added to the tinydns output.
This option causes any "Z" lines generated by the program to have no serial number, and to have a set of specific timeout values (as specified in the code.) I use this option because I have another script (called "make-data", see my page about tinydns replication for more details) which joins multiple "zone.*" files together to build the "data" file used by tinydns, and this other script generates the serial numbers automatically (thereby ensuring that the serial numbers on multiple servers are all the same.)

As an example, this is the command I normally use to convert a domain's zone file from BIND format to tinydns format:

# zone-convert -LZo bind/ >

Links to other djbdns sites