Making the Conversion: From BIND to tinydns

Last week, we set up the dns caching server, appropriately named

dnscache. This week, we'll set up tinydns, the process that allows you

to serve your DNS data.

First, let's use the tinydns-conf program to set it up:

# tinydns-conf tinydns dnslog /etc/tinydns

Like last week, we'll set this up on an unused IP address for testing,

in this case If you have an actual IP address that is not

currently running BIND or dnscache, then you can use that instead of

tinydns-conf uses the same arguments, namely the user to run the server

(tinydns), the user to run the multilog program (dnslog), and the

directory tinydns will call home (/etc/tinydns). The /etc/tinydns

directory is set up almost exactly the same as /etc/dnscache from last

week, such as the env, log, and supervise directories. /etc/tinydns/root

will contain different data this time, of course.

Next, let's tell svscan that it should start up tinydns:

# ln -s /etc/tinydns /service

In five seconds or so, tinydns should be spawned; however, it doesn't

contain any data yet so let's learn how to put some in. Tinydns doesn't

have zone files like BIND. Instead, all the data resides in one big file

-- /etc/tinydns/root/data -- which is fairly readable by us humans.

Tinydns actually works on a compiled version of this file,

/etc/tinydns/root/data.cdb, which is in cdb (constant database) format

-- a very fast-access database format created by DJB. This file format

is so fast that tinydns never loads any of it's data into memory, unlike

BIND which must load everything to function at all. tinydns assumes the

kernel will keep frequently-accessed buffers in kernel memory (a good

assumption) so you don't hit the disk that often anyway. Tinydns can

keep answering queries even when the new data.cdb file is being updated.

So, lets see what's in the root directory:

# cd /etc/tinydns/root

# cat data

# make


# ls

Makefile add-host data

add-alias add-mk data.cdb

add-childns add-ns

Our data file currently doesn't have anything in it (no biggie), but we

recreated the data.cdb file with the 'make' command anyway. These add-*

files are simple shell scripts you can use to add new DNS records. Let's

create a new domain -- 'example.dom'[1] -- using these scripts and see

what the actual records look like in the data file:

# ./add-ns example.dom

# make


# cat data


# host -t soa example.dom

example.dom SOA a.ns.example.dom. hostmaster.example.dom.

1027968095 16384 2048 1048576 2560

# host -t soa example.dom

example.dom name server a.ns.example.dom.

# host a.ns.example.dom

a.ns.example.dom has address

(Note that all of our 'host' commands must specify the tinydns server's

IP address,, since we're just testing this out.) The add-ns

script simply adds a line of the form to the data file:


However, this one line is all that's needed to configure a domain's SOA

(start of authority) record, and set up an NS record and the associated

A record. Note that the default contact is hostmaster@example.dom. Make

sure this email address is valid.

The TTL for the SOA is set to three days by default (259200 seconds).

Instead of manually listing the NS host name, you simply provide the IP

address, and it dynamically creates the hostname 'a.ns.example.dom'. If

you want to add nameservers, simply call add-ns again:

# ./add-ns example.dom

# cat data



This command automatically creates a 'b.ns.example.dom' entry with the

new IP address. Since we're just testing here, you should delete that

last line for now using your favorite text editor.

# vi data

Ok, now it's time to add an 'actual' IP addresses. Let's assume we have

our fictitious servers on network:

# ./add-host www.example.dom

# ./add-ns

# cat data



# make


# host www.example.dom

www.example.dom has address

# host domain name pointer www.example.dom.

First we used add-ns to set up a zone for reverse DNS lookups (the zone). The data line for our new IP address is of

the form:


This sets up both a forward (A) and reverse (PTR) record for this host,

as seen in the output of the two host commands. If we wanted only a

forward record, we could have instead used an entry of the form:


This entry is created with the 'add-alias' command instead of 'add-host.

We've seen how to create SOA, NS, A, and PTR records thus far, and all

using three different kinds of lines in the data file, which are pretty

easy to read. Other useful lines in data include:


creates an MX record for example.dom pointing to ip_address

named '' of priority 'dist', and

the appropriate A record, for example


# host -t mx example.dom

example.dom mail is handled by 10

# host has address


creates a CNAME for hostname1 pointing to hostname2, for example


# host ftp.example.dom

ftp.example.dom is an alias for www.example.dom.

You can use other entries as well. These options can be found within the

documentation at, or locally

with the command

# lynx /doc/commands.html

The nice thing about the data lines is that you can usually drop most of

the fields at the end. tinydns automatically will pick appropriate TTLs.

For example, you could use:


instead of


At this point, you have all the info you need to create a new tinydns

data file to handle all the DNS data you currently use. You'll also find

that it is easier to read in general, and certainly easier for programs

to manipulate. Here's a quick summary of the line types, including some

I didn't discuss above:

Initial Char Mnemonic Purpose

. zone delimiter Create SOA and NS records

@ email delimiter Create MX records

= define/equal Create A and PTR records

+ Create A record only

C (C)name Create CNAME records

^ carat is pointy Create PTR record only

' text starts with quotes Create TXT record

Z (Z)one Create SOA record only

You can use a lot of different options for performing functions such as

creating different responses depending on the client IP address, similar

to BIND's views, or making records that are only good before or after a

certain time -- helpful for smoothly changing DNS data without

administrator interaction. Just for easy reference, here's a commented

example file:

# The example.dom domain:


# The reverse DNS entry

# A few host entries. (The '=' means PTR records are created too)





# Mail goes to primary first, backup if that fails






So, your task this week is to convert some or all of your BIND datafile

to tinydns data format. Test things out on the temporary IP address,, and when you get all the bugs worked out, simply turn off

BIND (Forever! Huzzah!) and have tinydns listen on your actual IP


If, for example, you were using with BIND, then do the

following to have tinydns take over:

# echo '' > /etc/tinydns/env/IP

# svc -d /etc/tinydns

# svc -u /etc/tinydns

Now you are 100% BIND free! Congratulations and welcome to the club of

the secure. Enjoy watching your friends run around like headless

chickens the next time BIND bugs are found as they frantically try to

upgrade machine after machine.

Though the native tinydns data file format is pretty painless and takes

up a lot less room than BIND zone files, you may have a lot of data to

convert. If that's the case, all is not lost. Next week, I'll show

you how you can quickly 'import' your old BIND zones into tinydns data



[1] Yes, '.dom' is not a valid DNS suffix. I'm intentionally

choosing something that will not clash with anything out in the real


ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon