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 127.0.0.6
Like last week, we'll set this up on an unused IP address for testing,
in this case 127.0.0.6. If you have an actual IP address that is not
currently running BIND or dnscache, then you can use that instead of
127.0.0.6.
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
/usr/local/bin/tinydns-data
# 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 127.0.0.6
# make
/usr/local/bin/tinydns-data
# cat data
.example.dom:127.0.0.6:a:259200
# host -t soa example.dom 127.0.0.6
example.dom SOA a.ns.example.dom. hostmaster.example.dom.
1027968095 16384 2048 1048576 2560
# host -t soa example.dom 127.0.0.6
example.dom name server a.ns.example.dom.
# host a.ns.example.dom 127.0.0.6
a.ns.example.dom has address 127.0.0.6
(Note that all of our 'host' commands
Symantec Backup Exec 12 and Backup Exec System Recovery 8 deliver industry leading Windows data protection and system recovery. Download this whitepaper to find out the top reasons to upgrade and how to get continuous data protection and complete system recovery.
Data and system loss — from a hard drive failure, malicious attack, natural disaster, or simple human error — can happen anytime. Don’t leave your business vulnerable. Make sure you have a secure recovery strategy in place. Symantec's latest backup and system recovery technology can efficiently restore critical applications, individual emails and documents and even restore your entire system in minutes in the event of a loss.
Businesses face a growing challenge to ensure that the IT environment is properly protected. Backup Exec 12 integrates with other applications in the Symantec family of products, to complement your current data protection strategy, keep your data securely backed up and make it recoverable when you need it most.







