Forgot your password?
Document Actions
index_long.html
DNS using djbdns
DNS (Domain Name Service) is the backbone of the Internet, and any IP based system. It's the means by which meaningful domain and host names are turned into numeric IP addresses, and IP addresses translated back to FQDNs (Fully Qualified Domain Names). For years BIND (Berkeley Internet Name Daemon) has been the standard method of maintaining and resolving these addresses. Unfortunately BIND has also taken sendmail's place as one of the primary security hazards on the Internet.
Overview
The djbdns program is an alternative to BIND, and offers many advantages, notably security, speed, simplicity, and security (to paraphrase ``Blazing Saddles'' -- kinda like that security). A major reason for the increased security is that djbdns consists of several small programs, each of which handles a specific job instead of doing everything in one huge, monolithic program that does everything. This means that there's a bit more work to do to set up djbdns than to set up BIND (beyond the fact that BIND is pre-installed on most Unix-type systems). All the djbdns servers run as non-root users with limited privileges.
The most daunting aspect of djbdns is that each server requires its own IP address (with one exception that I'll address later). This requires some mental adjustment, and planning, but isn't difficult to implement.
Server Descriptions
| Server | Function |
|---|---|
| dnscache | DNS name resolution (find any address) |
| tinydns | DNS Authoritative Info (supplies domain information) |
| axfrdns | Supplies zone info to BIND servers. |
| rbldns | RBL server with very simple data format |
The ``tinydns'' program is a ``content'' server, and supplies authoritative DNS information from files on the system. It doesn't do any address resolution (this is done by dnscache). This will be running on at least one public address for a domain, the address specified in the NIC records as a name server. One can run multiple copies of tinydns on a system to implement ``split-horizon'' DNS where private DNS is maintained separate from the public records.
The axfrdns program allows zone transfers from remote BIND programs from the same data files used by tinydns. This is only necessary to support secondary servers running BIND as djbdns usually maintains multiple servers using rsync instead of zone transfers. This server normally runs on the same IP address as the public tinydns, and services TCP requests while tinydns only services UDP.
The rbldns program provides RBL (Realtime Blackhole List) lookups. These provide a fast way to identify hosts by their IP address that are either to be denied or allowed access. The input to rbldns is a flat ASCII file with IP addresses and CIDR network specifications (192.168.1.0/24 would specify a full class C network). These are very easy to maintain compared to using BIND, and should be much faster responding to queries.
The rootdns program runs a local copy of the root domain information which is faster, and cannot be polluted by somebody cracking or spoofing the root servers.
Assigning IP Addresses to Servers
This requires a bit of planning, and depends on the function of the system where the server(s) running.
A single machine on the Internet that doesn't supply any external information may just have dnscache running on 127.0.0.1 (localhost).
A machine supplying DNS lookup services to other machines on its network, but no other services, then dnscache would be run on the primary IP address on the LAN.
A machine supplying authoritative data would run tinydns on a public IP address, and dnscache on either 127.0.0.1 or a private IP address to do address resolution. It might also run another copy of tinydns on 127.0.0.2 (another localhost) with private authoritative data to handle ``split-horizon''. This machine would also run axfrdns to support zone transfers as required.
One could run multiple copies of dnscache on a machine to provide pure resolution on one IP address, and split-horizon on another.
Examples
Several of our machines support multiple public interfaces for DNS servers for historical reasons (a polite way of saying that I screwed up while learning DNS and there are people using us for secondary services where we don't want to change the NIC records). One of these machines, johngalt.celestial.com, has servers set up as follows:
| Name | Server | IP | Comments |
|---|---|---|---|
| tinydns | tinydns | 192.136.111.59 | Public NS |
| axfrdns | axfrdns | 192.136.111.59 | Public NS Zone Transfers |
| tinydns2 | tinydns | 192.136.111.2 | Public NS |
| axfrdns2 | axfrdns | 192.136.111.2 | Public NS Zone Transfers |
| tinydns-private | tinydns | 127.0.0.3 | Private NS for mi.celestial.com |
| dnscache | dnscache | 192.168.253.253 | Local DNS resolution |
| rootdns | tinydns | 127.53.0.1 | Local copy root DNS info |
My laptop machine is much simpler. I have it configured so that it will run reasonably when totally disconnected from the Internet. Here I've combined our public and private data into a single file served up by one copy of tinydns, and everything runs off of the 127/8 localhost network. It won't do lookups for anybody else.
Installing Software on Caldera Linux Systems
djbdns uses daemontools to start, monitor, and control the DNS services. Before running djbdns you need to install daemontools 0.70 or above.
You will also need to install ucspi-tcp if you want to use axfrdns or axfr-get.
I have RPMS for daemontools, ucspi-tcp, and djbdns on ftp.celestial.com compiled for various flavors of Caldera Linux. These RPMS include manual pages in addition to the software, and the daemontools rpm makes the necessary changes to /etc/inittab to have svscan run automatically.
OpenLinux 1.3 daemontools, ucspi-tcp, djbdns, and BIND and file utilities.
OpenLinux 2.3 daemontools, ucspi-tcp, djbdns, and BIND and file utilities.
eServer 2.3 daemontools, ucspi-tcp, djbdns, and BIND and file utilities.
eDesktop 2.4 daemontools, ucspi-tcp, djbdns, and BIND and file utilities.
Source RPMS daemontools, ucspi-tcp, djbdns, and BIND and file utilities.
Down load the appropriate files, login as root, and install them using the commands:
rpm -i daemontools*.i386.rpm rpm -i djbdns*.i386.rpm rpm -i ucspi-tcp*.i386.rpm |
Assuming that everything goes according to plan, you should now have a /service directory with the svscan program running to monitor daemon processes.
Installing and Starting Servers
Add DNS Users
One of the reasons that djbdns is more secure than the default installations of BIND is that every server runs with limited privileges. The first step then is to create these users. Assuming that you're going to run all the servers, and have each group of servers with its own user name. These commands will do the minimum necessary to create these users. Delete the ones you're not going to use.
useradd axfrdns -s /bin/false useradd dnscache -s /bin/false useradd dnslog -s /bin/false useradd rbldns -s /bin/false useradd tinydns -s /bin/false |
dnscache -- caching DNS resolver
Select the appropriate IP address for the resolver. Here I'm going to install it on the internal LAN interface where it's accessible by anybody on the internal LAN. For the purposes of this assume that the internal LAN's on the private class C 192.168.253.0/24, and this machine's on 192.168.253.1.
# Create /csoft/etc/dnscache with all necessary files dnscache-conf dnscache dnslog /csoft/etc/dnscache 192.168.253.1 # Tell dnscache to listen on the 192.168.253.0/24 network touch /csoft/etc/dnscache/root/ip/192.168.253 # Svscan will automatically start the daemon within 5 seconds ln -s /csoft/etc/dnscache /service |
Add dnscache Server to /etc/resolv.conf
Now if you put the line ``nameserver 192.168.253.1'' as the first nameserver line in /etc/resolv.conf you should be able to resolve IP addresses using the new dnscache server.
Enable Access to dnscache for Specific Networks
This server will only listen to UDP DNS requests from networks specified by files in the /csoft/etc/dnscache/root/ip directory. The dnscache-conf program creates one for the 127/8 localhost network, and you will have to create files for other valid networks which is what the ``touch'' command does above for the 192.168.253.0/24 private network. We also have files on our LAN here at Celestial for 192.136.111.0/24 and 204.57.163.0/24, our public networks.
Extensions to dnscache
The RPM for dnscache from Celestial is built with a couple of patches from Uwe Ohse's patches to djbdns which allow one to set the OKCLIENT environment variable to allow any client to access dnscache, and to have dnscache listen on multiple IP addresses which can be useful on dual-hosted machines.
To allow dnscache to answer requests from any client add a line to /csoft/etc/dnscache/run at the top of the file:
OKCLIENT=1; export OKCLIENT |
To have dnscache listen on multiple interfaces, use a comma separated list of IP addresses on the dnscache-conf command line (no spaces around the commas), or edit the /csoft/etc/dnscache/env/IP file manually.
Restart dnscache Server
You will need to restart the dnscache server after making any changes in its configuration files. This is done with the command:
svc -du /service/dnscache |
tinydns -- Authoritative DNS Server
The tinydns program is a content server that supplies DNS information only for those zones for which it is authoritative. This is the server to run on the public DNS server IP addresses to service requests for DNS information in the zones for which it's responsible.
Tinydns doesn't do any recursive lookups, so cannot be used in the /etc/resolv.conf file for general resolution.
Internal private domains require their own tinydns server that is accessible only from the private network. It's easy to run ``split-horizon'' DNS on the internal networks since dnscache can look to the private tinydns server for the internal addresses, and the public tinydns server for the public ones.
Select IP Address and Create Servers
Select the appropriate IP address for tinydns servers. There may well be multiple servers on a single host as describe in the Examples section. Each public DNS server IP address requires its own copy of tinydns, and another private tinydns server's necessary to implement split-horizon DNS. I'm going to use a private IP address, 192.168.1.1 in the example below to prevent any potential problems with people doing cut-n-paste from this documentation on real servers. The domain ``example.com'' is used for the same reasons.
The convention we use is that the first public server will run from /csoft/etc/tinydns, and the private in /csoft/etc/tinydns-private. Additional public servers will run in /csoft/etc/tinydnsN where N then number of the server (it doesn't matter what this is so long as it's consistent and unique to that server). When I configure multiple servers this way, I set the secondary servers to share the same data files by linking their root directories to /csoft/etc/tinydnscache/root.
tinydns-conf tinydns dnslog /csoft/etc/tinydns2 $IPADDR rm -f /csoft/etc/tinydns2/root ln -s /csoft/etc/tinydns/root /csoft/etc/tinydns2/root |
Normally there will only be one private server, unless there's a need to have multiple private domains. In this case, it's probably best to have the local private domains responsible for their own files rather than have a centralized location which might be more difficult to maintain. The private server will run on a localhost IP address since it will only be accessed by the dnscache program on that machine.
publicip=192.168.1.1 pubdomain=example.com privateip=127.0.0.3 privdomain=local.example.com # Create /csoft/etc/tinydns with all necessary files tinydns-conf tinydns dnslog /csoft/etc/tinydns $publicip # Tell dnscache where the public info is available echo $publicip > /csoft/etc/dnscache/root/servers/$pubdomain # create private tinydns server tinydns-conf tinydns dnslog /csoft/etc/tinydns-private $privateip # Tell dnscache where the private info is available echo $privateip > /csoft/etc/dnscache/root/servers/$privdomain # Svscan will automatically start the daemons within 5 seconds ln -s /csoft/etc/tinydns /service ln -s /csoft/etc/tinydns-private /service |
Zone Files
The configuration files for djbdns are considerably simpler than those for BIND as well. Small shops that only have to do DNS for a few domains can add hosts with a single line in a file instead of having to update multiple files as required by BIND. See Life with djbdns Simple Setup for some simple examples of the configuration files. I'm going to address this further in the section on maintaining multiple zones below.
Restart tinydns Server
You will need to restart the tinydns servers after making any changes in their configuration files. This is done with the commands:
rbldns -- Realtime Blackhole List DNS Server
The rbldns server is designed to maintain DNS lists of host IP addresses for fast lookup by mail servers, and other clients that permit them to ALLOW or DENY access depending on whether the IP address is in the list. Historically this has been implemeted to limit e-mail abuse groups with tools like Mail Abuse Prevention System MAPS RBL Realtime Blackhole List, MAPS DUL Dialup Users List, and MAPS RSS Relay Spam Stopper
Maintaining an RBL using standard BIND was messy and ineffient as the files tend to be large, and updating took quite a while. The rbldns program simplifies this drastically since it uses a single data file containing IP addresses and CIDR blocks, one per line. The rbldns server is designed to do one thing very efficiently so it doesn't have the overhead associated with a full content server.
The RBL servers are supported through programs like tcp_wrappers, rblsmtpd (part of the ucspi-tcp package), and other programs using the tcp_wrappers libraries (smail-3.2 uses this). The way this works is that an IP address is converted to an RBL entry by reversing the order of the octets, and appending the RBL name Thus 1.2.3.4 -> 4.3.2.1.rbl.celestial.net. in Celestial's local RBL of hosts that have connected to us to send unsolicited e-mail. All lookups that are in the RBL return the same IP address, typically 127.0.0.2.
The /etc/hosts.allow lines we use for the anti-spam RBLs are:
# local RBL, mostly systems that have hit our spam traps
sendmail,smtpd: {RBL}.rbl.celestial.net. : DENY
# MAPS RBL
sendmail,smtpd: {RBL}.rbl.maps.vix.com. : DENY
# MAPS DUL (Dialup Users List)
sendmail,smtpd: {RBL}.dialups.mail-abuse.org. : DENY
# MAPS RSS (Open Relays that have sent spam).
sendmail,smtpd: {RBL}.relays.mail-abuse.org. : DENY
sendmail,smtpd: {RBL}.rbl.xenitec.on.ca. : DENY
sendmail,smtpd: ALL : ALLOW
|
Select IP Address and Create Servers
Each rbldns server needs to run on its own IP address, usually public, and must have corresponding NS entries it its parent domain if it's to be publically accessible.
pubip=192.168.1.2 rbldomain=rbl.example.com rbltxt="Local RBL List" rbldns-conf tinydns dnslog /csoft/etc/rbldns $pubip echo $pubip > /csoft/etc/dnscache/root/servers/$rbldomain # Create IP address and description in file echo ":127.0.0.2:$rbltxt" > /csoft/etc/rbldns/root/data # now create the database gmake -C /csoft/etc/rbldns/root # finally link it to /service so that the daemon will start ln -s /csoft/etc/rbldns /service # restart dnscache so that it will recognize rbldns svc -du /service/dnscache |
axfrdns -- Server for BIND Zone Transfers
The axfrdns program runs on the same IP address as the tinydns server, and uses its data files to provide zone transfers to BIND systems. It listens on the TCP port of the IP address while tinydns listens on the UDP port.
It isn't necessary to run axfrdns if all the name servers for your domains are using dbjdns because they will keep their files synchronized using the rsync program.
Create axfrdns Servers
There will usually be one axfrdns server for each public tinydns server on a system. These can be added at the same time as the tinydns servers or later using these commands:
publicip=192.168.1.1 axfrdns-conf tinydns dnslog /csoft/etc/axfrdns /csoft/etc/tinydns $publicip ln -s /csoft/etc/axfrdns /service |
Edit the axfrdns Configuration File
One file, /csoft/etc/axfrdns/tcp, controls what servers are allowed to do zone transfers from the axfrdns server. Each axfrdns server gets its zone information from a corresponding /csoft/etc/tinydns/root directory.
This will have a line for each host with a list of the zones it can transfer:
# sample line: # 1.2.3.4:allow,AXFR="heaven.af.mil/3.2.1.in-addr.arpa" # 127.:allow,AXFR="celestial.com/111.136.192.in-addr.arpa" 204.122.16.4:allow,AXFR="gasboy.com/l3sys.com" # ... |
Run ``gmake -C /csoft/etc/axfrdns'' after editing this file to build the /csoft/etc/axfrdns/tcp.cdb file.
You can link the /csoft/etc/axfrdns/tcp* files to other multiple axfrdns servers if necessary so that there's only one file to edit for all the axfrdns servers running on a machine.
Maintaining Multiple Domain Files
I am putting together a system to maintain multiple zone files using the Unix file system as the primary database, with simple shell scripts to maintain the data files by combining the individual zone files. The djbdns files are designed to be simple to edit and maintain, and personally I find it easier to edit a file than to dig through a bunch of browser screens to do a simple task. All the djbdns files are under the /csoft/etc/djbdns directory in these subdirectories and files:
| Directory | Subdirectory | File | Description |
|---|---|---|---|
| primary | zonename | data | standard djbdns data for zone |
| primary | zonename | update.sh | Script to update secondaries |
| secondary | zonename | data | standard djbdns data for zone |
| secondary | zonename | axfrcmd | Script to do zone transfer if necessary |
| private | zonename | data | standard djbdns data for zone |
| pubdir | data | standard djbdns for primary and secondary zones | |
| privdir | data | standard djbdns for private zones |
This allows us to build public and private data files simply with scripts like this:
#!/bin/sh sort -u primary/*/data secondary/*/data > pubdir/data (cd pubdir; tinydns-data; rsync...) sort -u private/*/data > privdir/data (cd privdir; tinydns-data; rsync...) |
Primary Zone Files
The primary zone's data files can be maintained any way that seems appropriate including the simple shell scripts that the tinydns-conf program creates in the /csoft/etc/tinydns/root directory. Creating a new zone could be as simple as:
#!/bin/sh cd /csoft/etc/djbdns mkdir primary/example.com cd primary/example.com touch data tinydns-edit data data.new add ns ns1.example.com 192.168.1.1 tinydns-edit data data.new add ns ns2.example.com 192.168.1.2 tinydns-edit data data.new add host ns1.example.com 192.168.2.1 tinydns-edit data data.new add host ns2.example.com 192.168.1.2 tinydns-edit data data.new add host mail.example.com 192.168.1.3 tinydns-edit data data.new add mx example.com 192.168.1.3 tinydns-edit data data.new add mx example.com 192.168.1.1 tinydns-edit data data.new add mx example.com 192.168.1.2 tinydns-data |
This is a bit rudimentary, but should work. It has the MX records hard coded instead of with host names which will work, but I prefer to keep it a bit cleaner than that.
The update.sh script could be used to update ``secondary'' servers after making changes in the data files. This could also be in a ``Makefile'' that would also handle things like running tinydns-data as necessary.
Secondary Data Files
These are normally updated from the primary systems, either directly using rsync from those systems, or by doing zone transfers from their BIND servers.
Private Data Files
These are exactly like the primary data files except that they're destined for the /csoft/etc/tinydns-private/root/data for split-horizon DNS instead of for external use.
Purely private tinydns
There may well be self-contained machines such as laptops that are often used as disconnected from the net. These might well run a single tinydns program using the zone files from the public, secondary, and private directories:
#!/bin/sh cd /csoft/etc/djbdns mkdir selfdir sort -u primary/*/data secondary/*/data private/*/data > selfdir/data (cd selfdir; tinydns-data) |
Rsync Server Configuration for Secondary Servers
Secondary DNS servers can be configured using /csoft/etc/rsync/*conf so that they can be updated safely using the rsync in server mode instead of using ssh, secure shell. This has the advantage that it doesn't require using ssh identity files with null pass phrases if one wants to run jobs from cron, and it avoids some problems where rsync may hang using ssh connections.
There are a couple of different configurations possible using rsync, syncing the entire /csoft/etc/tinydns and /csoft/etc/tinydns-private data files on multiple machines within a single organization, and sync'ing a set of zone files to another site's secondary directories where that site may have a superset of the zones maintained on your system. In the first case, the updates will go directly to the /csoft/etc/tinydns/root directory, while in the second they will go to /csoft/etc/djbdns/secondary/zonename (which could well contain multiple zones so a single directory could handle all zones for a site).
Building the /csoft/etc/dnscache/root/servers Files
There are some significant advantages to running local copies of the root name server information. This eliminates the need to go out on the Internet to the root servers for every lookup, and also provides additional security against corruption of the root servers. The Open Root Server Confederation provides complete instructions on setting up your own root name server info using djbdns. They also tend to have the latest information on new Top Level Domains (TLDs) before ICANN does.
Documentation and Resource Links
href="index_long.html" Single Page Version of this Documentation (easier to search and print).
href="index.html" Multi-Page Version of this Documentation.
Open Root Server Confederation Info on having your local root files.
DNS Database Replication "primary" and "secondary" DNS servers.