What Is djbdns?

BIND can be considered the nuclear-powered kitchen sink, blender, and floor polisher of DNS software. It gurgles busily in the corner and occasionally springs a leak or explodes. Despite its market share, it’s an old machine with spotty maintenance records.

djbdns, then, is the set of tools that you’d find at a DNS specialty store: simple, secure, fast, and safe when used as directed. Almost unnoticed, this package serves millions of domain names every day at large Internet domain-hosting companies and other busy sites. It is very reliable. The software just keeps running without human intervention, other than to modify domain data. Memory use is limited, processes are monitored and restarted when needed, and logs are automatically rotated to avoid filling up the disk.

Like BIND, djbdns is free software for Unix and Unix-like systems. djbdns can replace BIND or coexist as a primary or secondary nameserver.

djbdns comprises servers, clients, libraries, and helper services (see Table 6-2). Table 6-2. djbdns’ component and associated packages

djbdns package Description

dnscache Caching name server tinydns Authoritative name server axfrdns Zone-transfer server axfr-get Zone-transfer client

Walldns A reverse DNS wall; provides reverse look-ups without revealing internal _{network layouts} Rbldns IP-address list server, suited for blackhole lists

dnsip, dnsname, dnsmx, dnsipq,

dnsfilter DNS utility clients dnsq, dnsqr, dnstrace DNS debugging clients

dns A C library for DNS

Associated package Description

Daemontools Service-management utilities, used by dnscache and tinydns ucspi-tcp TCP client-server interface, used by axfrdns and axfr-get

We’ll discuss how to install and configure the main components shortly. First, let’s see why djbdns was written and what problems it solves.

6.5.1.1 Why not BIND?

In a nutshell, djbdns was written in response to problems with BIND’s security, complexity, and

performance. It therefore makes sense to talk about what djbdns is in the context of how it relates to BIND. Table 6-3 shows such a comparison.

Table 6-3. BIND versus djbdns

Characteristic BIND djbdns

Security

BIND has had many security problems. Since it normally runs with root privileges, any exploit (by buffer overflow or some other means) can compromise the server. It takes extra effort to run as a normal user or in a chrooted environment. There are no security guarantees.

Each djbdns program runs as a dedicated nonroot user in a chrooted jail. Even if cracked, it can’t go anywhere else or gain control of the server. The author offers a $500 reward to "the first person to publicly report a verifiable security hole in the latest version of djbdns."

Ease of use

BIND is notoriously hard to learn, use, and manage. The file format is cryptic, hard to parse, and unforgiving (although BIND 9 is better). There is no automatic error checking, so system integrity relies on the knowledge and discipline of the

administrators. The same administrators are sometimes reluctant to apply security patches to a working but fragile system, increasing the window of vulnerability.

The djbdns zone file format (tinydns-data) is simple and intuitive. Input errors are checked automatically, so the name-server database is only updated with good data. Intelligent defaults are used for values like TTL and timestamps, so you don’t need to specify everything. PTR records are autogenerated. Split-horizon DNS is simple.

Efficiency BIND is a resource hog. It gobbles up memory like a turkey dinner; sometimes it passes out and pulls the tablecloth with it.

The default size of dnscache’s memory cache is one megabyte, but can be changed on the fly. When free cache space is low, it discards the oldest cache entries.

Clarity

Like Orson Welles, BIND is big, complex, and hard to manage. Some of its logic is convoluted and does not work as intended. Unexpected code interactions between caching and authoritative serving have left BIND susceptible to attacks like cache

djbdns is simple. Since each program does less and has much less code, there is less opportunity for problems. dnscache starts with the root servers to find the true authoritative servers for domains, and it can’t be tricked to follow hijacked name servers.

poisoning.

Separation of functions

BIND is a caching server, an authoritative server, and a zone-transfer server and client. If you only need one function, you need to disable the others and ensure that your firewall is blocking access to their ports. Code complexity has caused many bugs and security problems.

Separate functions are handled by separate servers. Each server is small, easier to learn, easier to understand, and easier to use day-to- day. You only install what you need: dnscache for caching, tinydns for serving, axfrdns and/or axfr-get for zone transfers. Data

availability

During zone transfers, BIND goes into a trance and will not communicate with anyone else.

tinydns always serves data from a consistent authoritative database, so name services stay available during database updates and zone transfers.

Data integrity

By default, zone data is transferred as clear text. DNSSEC has been proposed to encrypt the data stream, but it isn’t really working yet.

Secure, incremental zone transfers are simple: just use rsync with ssh to copy data files between tinydns servers. No special protocols or tools are needed. AXFR zone transfers to and from BIND are also supported.

Code ubiquity

BIND comes with every version of Unix and handles most of the name serving on the Internet. File locations, versions, and patch levels may vary significantly across different systems.

djbdns is not a standard component of any Linux or BSD installation. Its license requires any redistributed version to work the same on every platform. This is at odds with package managers (BSD ports, Red Hat RPM, etc.), which mold the package to fit the distribution. In the author’s words: "Breaking cross- platform compatibility for the sake of cross- package similarity is a horrible idea." It is permissible to distribute patches.

RFC compliance

BIND supports almost anything related to DNS. BIND 9.1.1 includes over 60 DNS- related RFCs and over 50 Internet Drafts.

djbdns does not support some RFCs: IXFR (RFC 1995), DNSSEC (RFC 2535, 2931, 3008), TSIG (RFC 2845), Dynamic DNS (RFC 2136), A6 (RFC 2874), and DNAME (RFC 2672). In each case, Bernstein argues that these standards either don’t work or have a better alternate implementation.