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 domain.xyz db.domain.xyz
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:
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 domain.xyz bind/db.domain.xyz > zones.domain.xyz