Wrapping Up DJBDNS

by Brian Hatch

August 13, 2002 —

At the beginning of this trip down DJBDNS lane, I tagged a challenge at
the end of the message. Unlike my previous [1] challenge, this one had
almost no response, probably because it was lost in obscurity at the
bottom of the email. I'm re-issuing it again this week, and you'll find
it at the end of this article.

Welcome to the home stretch, my last [2] ITworld article on installing
DJBDNS. I'll cover two things here. First, I'll show you how to 'import'
your existing BIND zones into tinydns data format so you don't need to
convert those files by hand. Lastly, I'll show you how to start up the
axfrdns server, which will allow DNS secondaries running BIND to mirror
your DNS zones.

Import Your Existing BIND Zones
First, both of these require another piece of DJB software, ucspi-tcp
(Unix Client Server Program Interface). Run the following to install it:

$ mkdir /tmp/src
$ cd /tmp/src
$ wget http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
$ tar xzvf ucspi-tcp-0.88.tar.gz
$ cd ucspi-tcp-0.88
$ make
# make setup check

This installs a bunch of different TCP client and server programs in
/usr/local/bin, though we'll only be using two of them: tcpserver and
tcpclient.

So, let's see how we can snag our existing BIND zone files. I'll assume
we want to get the 'example.dom' domain. First, make sure that BIND
allows you to perform DNS transfers for our IP address. Assuming you are
doing this on the same machine, localhost should be allowed in
/etc/named.conf:

allow-transfer { 127.0.0.1; };

If you don't have an allow-transfer directive, then create one like the
one above. Test to verify that you can do a transfer using 'host':

$ host -l example.dom
example.dom SOA example.dom. hostmaster.example.dom 10 3600 180
25920 8640
example.dom name server ns1.example.dom
example.dom name server ns2.example.dom
www.example.dom has address 192.168.1.1
...

If you don't get a listing, then check your logs and make sure that
localhost is allowed to perform a transfer. If all's well, then do the
following:

# cd /etc/tinydns/root
# tcpclient -v 127.0.0.1 53 axfr-get example.dom example.dom.zone
tmpfile

This connects to the local BIND server, snags a copy of the zone, and
saves in the proper format as example.dom.zone in the local directory.
You can do this for all the domains that you support, it's that easy.
Once you've got all the zones saved, you can edit them if you want to
make them more tinydns-ish, for example deleting the TTLs, converting Z
and & lines to .domain lines instead, etc.... However, even if you leave
them as is, they'll work exactly as before. All that's left to do is
merge these files into the data file:

# cat *.zone > data
# make
/usr/local/bin/tinydns-data

That's it. You've just taken all your BIND data and turned it into
tinydns data format. Kill off BIND, tell tinydns to listen on the old IP
address (192.168.1.1 for example), and restart tinydns:

# killall named
# echo 192.168.1.1 > /etc/tinydns/env/IP
# svc -d /etc/tinydns
# svc -u /etc/tinydns

You are BIND free. Isn't that a great feeling! Of course, since we're
not using BIND, there are a few BIND-specific niceties we're missing

* The ability to mirror other BIND servers' data
* The ability for secondary BIND servers to mirror our data

Start Up the axfrdns
The 'official' way to send and receive zone updates for DJBDNS is to
simply rsync /etc/tinydns/root/data from one host to another. This is
great if you are in control of all your DNS servers, but doesn't work if
you rely on third party BIND name servers as well. However, you can use
the axfrdns program to allow BIND servers to mirror your domains.
axfrdns was installed as part of DJBDNS already, but we still need to
configure it. axfrdns only listens on TCP port 53 and, since tinydns
only listens on UDP port 53, you can have axfrdns run on the same IP as
tinydns. Let's assume that's 192.168.1.1 for this example:

# axfrdns-conf axfrdns dnslog /etc/axfrdns /etc/tinydns 192.168.1.1

Those arguments, from left to right, are the user id for axfrdns, userid
for logging, the new axfrdns directory, the location of your existing
tinydns directory, and the IP to listen on. axfrdns looks at the very
same data.cdb file that tinydns uses, so it's always in sync. Let's
start up axfrdns with:

# cd /etc/axfrdns
# make
tcprules tcp.cdb tcp.tmp < tcp
# ln -s /etc/axfrdns /service

In about five seconds axfrdns will be started by svscan. By default,
axfrdns will reject any requests for a zone transfer. This is good,
because it keeps the bad guys from easily getting a list of all your
machines names and IPs. The access restrictions are located in the file
/etc/axfrdns/tcp. Let's look at a sample file to illustrate:

# allow 10.0.0.1 to get any zone
10.0.0.1:allow

# allow 10.0.0.2 to get only these two zones
10.0.0.2:allow,AXFR="example.dom/some_domain.org"

# deny 10.0.0.3 entirely
10.0.0.3:deny

# allow all other 10.0.0.x machines to get another_domain.edu
10.0.0.:allow,AXFR="another_domain.edu"

# deny all others. (Default deny is good.)
:deny

There are more ways of specifying hosts than just these. See
http://cr.yp.to/ucspi-tcp/tcprules.html for the full man page. But in
the simplest case, you create a line for each secondary dns server you
have, and list all the domains that it should be allowed to transfer in
the AXFR="" section.

So, you now have all the pieces you need to get rid of BIND. Let's do a
quick recap:

* dnscache functions as your recursive DNS resolver, pointed to by
/etc/resolv.conf for example.
* tinydns serves your DNS data.
* axfrdns allows you to have BIND servers secondary your DNS data.
* normal tinydns data mirroring is accomplished by rsyncing the
data file to the remote servers, ala:

$ rsync /etc/tinydns/root/datasecondary:/etc/tinydns/root
$ ssh secondary 'cd /etc/tinydns/root; make'

* axfr-get can be used to snag data from BIND or axfrdns servers.

In fact, if you don't want to use rsync to get your data to your tinydns
secondary DNS servers, you could set up a cron job to simply use
axfr-get much as we did at the beginning of this article to snag all the
domains:

# cd /etc/tinydns/root
# cat *.zone data.local > data
# make

We're only missing two things with DJBDNS that we don't have with BIND.
The first is the 'notify' functionality, which lets a DNS master tell
its secondaries to update the zones. However, this isn't necessary if
you use rsync to update zones, or if you have frequent enough cron jobs
to do the same.[3]

And the second thing we no longer have when we switch to DJBDNS is a
horrible security track record. You'll need to get used to not patching
your systems every few months. Hopefully, you'll have some other
software that is still buggy so those parallel upgrade skills don't go
to waste.

The Challenge
One of the members of my local Linux User Group asked for a quick way to
delete the first four bytes from a file. This begat a rapid series of
emails showing the many, many ways you can do things on Unix systems.
Tail, dd, sed, and of course perl all came into play. In the spirit of
TMTOWTDI (there's more than one way to do it), I challenge folks on this
list to create a file that can strip the first four bytes from the file
'modifyme' in the current working directory. The file may not be an
executable, but instead must be one of the following types:

* A man page /usr/share/man/man1/stripfourbytes.1 viewed with 'man
stripfourbytes'.
* A postscript file, 'stripfourbytes.ps', viewed with ghostview or
ghostscript.
* A LaTeX file stripfourbytes.tex, viewed with 'latex
stripfourbytes'
* A PDF file, stripfourbytes.pdf, viewed with xpdf or acroread,
etc....
* An image file, viewed with any standard Linux image viewer
(eeyes, qiv, xv, etc....)
* Any other non-executable file that you can use to trick a
standard Linux program into running arbitrary code. (An attack
against grep, for example.)

Some of the above are definitely possible. Others I've heard of folks
doing, but have never tried myself. Others I doubt are exploitable at
all.

The first or best winner of each category will get a postcard from sunny
Seattle from yours truly, and get their name immortalized in a future
column. I'll post answer and discussion in two weeks, so get coding!

NOTES

[1] http://www.hackinglinuxexposed.com/articles/20020416.html
[2] Yes, if you were getting bored of this thread, you can resubscribe
now.
[3] There are a few programs linked from http://www.tinydns.org/ that
will let you send BIND NOTIFY packets to trigger instant updates
from BIND secondary DNS machines.

ITworld