This document is not intended as a "total" guide for administring the DJBDNS-package.
Neither is it intended to be without errors. These are just the experiences I had when
setting up DJBDNS.
First of all, what is DJBDNS?
I quote Henning Brauer on www.lifewithdjbdns.com
djbdns is a simple software kit for serving and resolving DNS data.
It is intended to be a replacement for BIND in many settings, although it does not yet
include every feature implemented by BIND, and may never do so; djbdns includes
features that can be demonstrated to be needed, and there are some features
offered by BIND that do not make the cut.
Like qmail, especially in its younger days, djbdns can require some redesign to deploy.
I wanted to use DJBDNS because I had to much trouble maintaining the /etc/hosts file on my
For one or two machines it's not really a trouble. When the LAN keeps growing
it's almost impossible to keep them up-to-date. Off course, when you're one of those who
installs a system and afterwards never touches the set-up, it's a one-time-job. But then you wouldn't
be using GNU/Linux, would you?
For now, DJBDNS is running a while with not much off maintenance and it's giving some more spare time
to look into other facts of controlling my GNU/Linux-machines. I'm using it as the nameserver for
my local domain and as a caching-name-server.
Al lot of the this material is "collected" together from various other resources.
For a detailed explanation of how DJBDNS works I would strongly suggest you visit these
pages and read through them. Pick out the things you need and you'll see that putting it all
together isn't as hard as it could seem of the first sight.
Life With DJBDNS - http://www.lifewithdjbdns.com
Official DJBDNS-page - http://cr.yp.to/djbdns.html
DJBDNS by Russel Nelson - http://www.djbdns.org
Maybe a bit over the head but still useful information can be found in a nice HowTo that's written
by Nicolai Langfeldt and that can be found at
DNS HowTo - http://linuxdocs.org/HOWTOs/DNS-HOWTO.html
There's also a mailinglist, email@example.com.
Subscribe by sending an empty mail to
unsubscribing works similar by sending an empty mail to
Off course, before you could setup either a caching-name-server or your own nameserver,
it could come in handy that you now a little about what DNS is all about.
Everybody who has been surfing the internet has come, in some way or another, come in contact
with DNS. In one sentence I could describe DNS as :
DNS takes care of matching the right URL (WWW, FTP or something else) with the correct IP-address.
There, that's says it. We can finish now?
Not quite. Look at this nice definition found in the DNS-HowTo mentioned above :
DNS is is the Domain Name System.
DNS converts machine names to the IP addresses that all machines on the net have.
It maps from name to address and from address to name, and some other things.
A mapping is simply a association between two things, in this case a machine name,
like ftp.linux.org, and the machines IP number (or address) 184.108.40.206.
In fact, to be completely honest, that's almost all I know from DNS.
And even I could get DJBDNS running. So, isn't this a nice example that you don't have
to be a full technical expert to have your own nameserver? But please, when you're knowledge
stops here, don't let the 'whole' public use your nameserver because this could get some
quite unpleasant results!
Off course, some more knowledge could come in handy!
So, to complete the picture, I'll go a bit more in depth on DNS.
You could skip this section but bear in mind that you lose half of the fun!
The Domain Name Service (DNS) is like a very huge, distributed database that's supporting delegation
of authority for segments of the key space.
The prime use is for mapping hostnames to the IP-addresses. For now, to my knowledge, they
are only capable of coping with IPv4. So with the upcoming (10 years?) introduction of
IPv6 things need to be relooked.
Besides this mapping, it could provide you also with some extra information about the different
hosts and special routing support.
A DNS-database consists of different record types to define its own internal heirarchical structure and
the delegation of subdomains.
Off course, due to the complex nature of this material, there are quite a bunch of concepts
that are used with DNS. I'm not going to cover all of them, just the main part to give you
an idea what's out there.
One thing we've got to get right is that there's no "master" DNS. There are several off them!
They are called 'root-servers'.
In fact, one of the key-concepts of DNS is that a bunch of servers are exchanging their data.
They are passing Resource Records (RR) around. There are many types of RRs and several protocols exist
for requesting them. Normally DNS is carried around on the internet on port 53, both TCP and UDP.
Take a look in your /etc/service file and be convinced!
Most of the queries go over UDP. TCP is only used when the total of RR's exceeds 512 byes
or for performing a "zone transfer" (keep this term in mind).
...more to come...
For my LAN I have one caching nameserver (DNSCACHE) and one local DNS (TINYDNS) that serves all hosts
that belong to my LAN.
My caching nameserver is listening on IP 192.168.1.1 and the local DNS is listening on the localhost-ip
When I query for a local hosts-ip I'd like the caching nameserver to respond with the right address.
To do so, he needs to consult the nameserver (TINYDNS) that is "working" for my domain in question.
Out of the box, he doesn't know wich NS he needs to contact. For this to work you need to put a reference
to the nameserver in
/service/dnscache/root/servers. Just create a file in that directory
(with the name of the domain) that holds the ip-address of the nameserver that needs to be contacted.
So, for example when I want to serve mylocaldomain.com
After you have created this file, copy it to
for the reverse 'thing'. Make sure that both files are readable by the DNS cache account.
Restart dnscache with
svc -t /service/dnscache
...more to come...