Hi fellow PLUGgers,
The subject says it all. Now to briefly detail (huh??) how I did it. :)
0. Overview: I'm using Debian, with packages at various snapshot states
from the unstable tree. I also read djb's documentation in his webpage.
This is a must. Whether you like his style or not, you gotta read it for
documentation. Otherwise things won't work.
1. 'apt-get install build-essential djbdns-installer \
daemontools-installer ucspi-tcp-src' gets the sources, with some
patches in Debian fashion, and simple build scripts that make Debian
packages for the djb packages. It's a super straightforward way of
bypassing the inability to distribute djb binariy packages.
2. 'dpkg --installer djbdns daemontools ucspi-tcp' installs the packages.
They are Debanized such that there are valid init.d scripts to start up
svscan, whose data files are in /var/lib/svscan with /service as an
optional symlink.
3. Use the various -conf utilities to create the /etc/* directories,
symlinks of which are subsequently created in {/service,/var/lib/svscan}
which svscan loads up within 5 minutes.
So it's super straightforward. Well, in theory. There are various gotchas
that one will run into. These gotchas lessen as one gets used to djb's
style. Here are some gotchas I ran into:
1. The major change for me as far as configuration is concerned is that
unlike BIND, djbdns doesn't run one monolithic program to handle proxying
and content serving. What's more, tinydns (the content server), and
dnscache (the proxy) can't listen on the same IP address. So you either
create an alias IP address, or have two ethernet ports. I have an unused
one (unused because I don't have a switch capable of handling channel
bonding), so I decided to load it up as 192.168.0.2. tinydns listens to
that, dnscache listens to 192.168.0.1. :)
With all this brouhaha about who listens to what, I got life really fooked
up. I had things not listening here, or listening there when it shouldn't.
Here's a summary of how I actually configured tinydns, dnscache, and
axfrdns:
a. Configure tinydns to listen to IP 0.0.0.0. It listens to port 53 on UDP
so it won't conflict with any of the other programs.
b. Configure dnscache twice (with separate root directories,
/etc/dnscache-lo and /etc/dnscache-lan), because I need to listen to both
localhost and the LAN, but cannot just listen to 0.0.0.0 because this will
bork access from outside which would otherwise be received by axfrdns or
tinydns directly. One listens to 127.0.0.1 and the other to 192.168.0.1.
c. Configure axfrdns to listen to live IP address, configure tcp to allow
secondary servers to to AXFR transfer.
2. Because of the capability of tinydns's data to handle both forward and
reverse lookup, I forgot to insert a line for the nameserver of the
reverse lookup. If you don't do this, reverse lookup won't work even if
you have "=host.domain.com:a.b.c.d" entries.
To those of you who are wondering why the hell I went through this just to
use djbdns, well, here are my personal motivations:
1. A single IPTraf IP Traffic Monitor session on an otherwise idle Pentium
III 733MHz with 512MB of RAM and the latest, properly configured kernels,
running the latest BINDv9 release would reliable freeze my machine between
one to three minutes when IPTraf had to do massive name lookups. While
this is not "ordinary", it's not extraordinary, either. I can't afford to
get comfortable with a DNS proxy server that can be frozen by one IPTraf
session. I've tested, and dnscache is lovely. And I'm sure it'd be lovely
on a much less powerful machine, too. :)
2. I have multiple views set up with BINDv9, as I use leathercollection.ph
to handle my private IPs and my live IPs depending on who is asking. With
BINDv9 I needed separate zone files for this, and while zone files are
lovely to read (at least when I code them), having to update two zone
files every time you do a minor change really hurts. With tinydns, the
single data file can have multiple views side by side. Allows for better
consistenc checking (by inspection) too, and lessens the chance that
you'll forget something during an update.
3. I have a growing list of virtual hosts for Apache, and just love this
way of doing things. With BINDv9 I had to update two zone files every
time. This was super painful. With djbdns there are wildcards so I just
think of any virtual host I want and configure Apache to recognize it as
unique from the default. Voila! Zero dns update. :)
4. Maintaining reverse lookup files are painful. You have to remember to
configure them and keep them in sync. With tinydns's data file, you just
need the "=" entries. It handles forward and reverse lookup entries. And
of course it's automatically synchronized. The computer is doing what it
does best, that is, handles mechanical things that human's tend to miss
out on. :)
So, I'm officially using djbdns, and will "dpkg --purge bind bind-doc"
now. Yeah! :)
--> Jijo
--
Federico Sevilla III :: [EMAIL PROTECTED]
Network Administrator :: The Leather Collection, Inc.
GnuPG Key: <http://jijo.leathercollection.ph/jijo.gpg>
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
To subscribe to the Linux Newbies' List: send "subscribe" in the body to
[EMAIL PROTECTED]
