Wrapping Up DJBDNS

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.

Free Course: JavaScript: The Good Parts
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies