It's important to realize that, unlike bind, djbDNS is a collection of separate packages, each of which performs a minimal function extremely securely. It is this architecture that makes djbDNS so effective, since each part of the system is optimized in its own function. The average user, such as the LinuxIT office, does not need to use all parts of the djbdns system. A basic installation for a small office will be discussed later in this document.
Originally, domain names were administrated using a single flat-file document along the lines of /etc/hosts.However, this was not practical in the long term, since such a system scales badly. Therefore, this system was made obsolete and replaced in the long term by the modern DNS, or Domain Name System.
This system functions as a distributed database, allowing local control of the segments of the overall database - but data in each segment are available across the entire network through a client-server scheme. Robustness and adequate performance are achieved through replication and caching.
The structure of the DNS database is very similar to the structure of the UNIX filesystem. The whole database, or filesystem, is pictured as an inverted tree, with the root node at the top...
Each node is also the root of a new subtree of the overall tree. Each of these subtrees reresents a partition of the overall database, a ?directory? in the UNIX filesystem, or a 'domain' in the Domain Name system. Each of these can be further divided into additional partitions, called subdomains...
The 'distributed' comes into this from the fact that each domain name administrates the sub-domains under its charge. To continue the filesystem analogy, imagine an index file in each folder on a hard drive that describes the files and folders inside; now imagine that if you were to look inside a subfolder, you would find another index file, describing the insides of that subfolder, and so on. The point of this is that no one database/file ever has to hold all the information about DNS - they only exist to point you in the direction of the sub-sub-sub-database or file that holds the information you seek. And that sub-sub-sub-database is very probably administered by you, the owner of the domain you want to put into the worldwide DNS (or indeed in your office's DNS system...)
There are three packages to install, each of which are typically available as tarballs. These are respectively daemontools, ucspi-tcp, and djbdns.
Daemontools contains a system to assure that daemons keep running, the most important part of which is called svscan. To install this, un tar-gz it, using something like 'tar xvfz daemontools.tgz',
"cd admin/daemontools-$versionnumber$/" then
"./package/install"
This is the sum of daemontool installation. It starts running the svscan service automatically. However, a very important caveat is this: daemontools does not install itself - whilst it adds itself to boot scripts, it does not copy the executable from the place you put the untarred folder. This means that if you install it directly from cdrom, the moment you take the cdrom out, the binary will of course stop running. It will appear to install itself, but upon close inspection it actually just creates several links to itself from directories in $PATH.
uspci-tcp includes several packages which are used to provide the ability to talk between various dns servers. For example, in order to get the list of dns servers from a root server, you would use a uspci-tcp program. It's also used to exchange cache between two dns servers (such as a primary and secondary mirror).
It is simple to install (make all; install).
For a typical office, the services required are:
tinydns - providing a DNS lookup for local hostnames (on local ip blocks, for example, 192.168.x.x) dnscache - providing DNS lookup service for clients, using the tinydns install for local hostnames and external dns cache for other hostnames Optionally, a second dnscache/tinydns system for backup purposes. In our experience, a single well configured dns system is adequate provided the network connection is stable, but it is good practice to keep a backup in case of machine problems and similar.
Setting up svscan to run daemons
svscan installation creates a directory called /service. In order to get svscan to start a service, one has to link to it using a symbolic link placed in the /service directory. Example:
ln -s /etc/tinydns/ /service
Following the creation of this link tinydns will automatically be started (within five seconds). This sometimes seems to take longer, practically.
There are hundreds of different configurations that could be chosen when setting up DJBdns. The first decision has to be - do you want outside users (other name servers) to be able to send requests to tinydns? The answer, generally, is no - you?ll only want to do this if you want to discuss it with your service provider first and explain to them that you want to have a network that you can access from outside, which is therefore a network that uses an IP subblock available from outside (for example, my home network has no use at all for this, since I only have one IP address and therefore all the machines connected at home are on an internal network - 192.168.1.1 or 10.0.0.x...)
In the case of the home network/internal network, the only reason why you want tinydns is that you want to be able to use it to resolve hostnames of the various machines around your subnetwork - and of course to provide a handy backup to your external DNS service. It is evident that it would do no good in any case for external machines to access your dns information, since if they were to type 192.168.something, they would of course end up on their own home networks or nowhere at all...
However, it is important to realise that Tinydns does not exist to provide end users with IPs and hostnames... it is incapable of this, and should not be used in that way. Instead, you should use dnscache to talk to your end users (browsers, telnet, anything that needs IPs). So, only dnscache needs to talk to tinydns. For these admittedly long-winded reasons, you should install both tinydns and dnscache on the same machine. Tinydns should be invoked to listen only to 127.0.0.1 (local loopback, meaning that only the machine it?s on can talk to it) and dnscache should be given the IP of the machine. ie.
/usr/local/bin/tinydns-conf ?tinydns? dnslog /etc/tinydns 127.0.0.1
/usr/local/bin/dnscache-conf ?dnscache? dnslog /etc/dnscache 192.168.x.x
Note that the ?tinydns and ?dnscache? refer to the $SUID of the user accounts you intend to run tinydns under. You don't have to use these specific names - $SUID tinydns:users will do fine, if you have a tinydns user, a dnscache user, and you also need to create a ?dnslog? user. Remember for security purposes to make the user accounts with no /home directory and the set the shell to /bin/false. On my system the command would look like this: useradd $SUID -M -s /bin/false. Also you will want to make the password blank.
There are several standardised scripts that come along with the tinydns installation, add-alias, add-ns and so on. These do work, but in my opinion it's easier to simply edit the file yourself.
For the sake of completeness, here's some information about how these scripts would be used and the result they give if you use them:
If you choose to edit the file directly, the file to edit is /etc/tinydns/root/data. Here is an example:
=atuin.vogh.qib:192.168.109.1:86400
=cruithne.vogh.qib:192.168.109.2:86400
=thesaurus.vogh.qib:192.168.109.4:86400
=bob.vogh.qib:192.168.109.3:86400
=hal.vogh.qib:192.168.109.7:86400
=marvin.vogh.qib:192.168.109.8:86400
=localhost:127.0.0.1:86400
.vogh.qib:127.0.0.1:a:259200
.109.168.192.in-addr.arpa:127.0.0.1:a:259200
DNScache setup involves setting up the servers in /etc/dnscache/root/servers and setting up the IP access rules in /etc/dnscache/root/ip.
We decided to use the OpenNic servers for our dns (just because pinging ns1.opennic.glue was amusing). Here?s a short bash script that sets up the OpenNic servers (from Kuro5hin)
#!/bin/sh
cd /etc/dnscache/root
# Note: I have modified these slightly from the ones on OpenNIC?s
page # to have the format which dnscache wants. wget http://web.thock.com/Dylan/dns/opennic.tlds
wget http://web.thock.com/Dylan/dns/opennic.servers cd servers
cat ../opennic.tlds | xargs -l ln ../opennic.servers svc -t /service/dnscache
echo Done!
Whilst this does work, the server IPs available from this particular web site are old.
Or, from OpenNic?s web page (and Alan Hodgson):
#!/bin/sh
cd /etc/dnscache/root/servers
#Replace your root servers file (root/servers/@) with the IP numbers
of the OpenNIC Tier 1 servers,
#obtained by using dnsq to query the Tier 0 IP number (this step can
be done manually, as well)
# cp -f @ /tmp/@.saved
# dnsq ns . [Server IP number] | grep -iv ns0.opennic.glue \
| awk ?{ if (/^additional/) print $5}? > /tmp/@.new
# cat /tmp/@.new
If the output of this looks okay - and check this manually- replace
the file:
# mv -f /tmp/@.new @
# Restart DNScache
# svc -t /service/dnscache
#Now check it by running the line of code below:
# dnsip www.opennic.glue
If that lookup works, then the OpenNic servers have been correctly installed. NB. Remember to replace the [server ip number] with an IP address from www.opennic.unrated.net! NB2. You can of course also run this code on ?normal? name servers ie. the official nameservers run by Internic.
The second step, setting up the IP access rules, indicates to dnscache
the IP addresses that are permitted to use dnscache for lookups. If,
for example, you wanted to restrict access to the 192.168 local network
IP block, you would complete the following step: touch /etc/dnscache/root/ip/192.168
Of course, if the dnscache and tinydns are both running on the
same machine, it is clearly necessary to allow localhost to have access
as well, so an additional step would be: touch /etc/dnscache/root/ip/127.0.0.1
The last line in the /etc/tinydns/root/data example I gave above is in fact the answer to this question, along with one other important piece of information - dnscache needs to be specifically configured to know, not only to search for the vogh.qib subdomain in the local tinydns server, but to search for the 192.168 subdomain in reverse lookup space. This is achieved by creating a special file in /etc/dnscache/root/servers/. For example, if you want to be able to do reverse lookups on everything in 192.168.1 using your local dns server (tinydns), as is very likely given the fact that no external server is going to know what your 192.168 subdomain names would be, you do: 'echo '127.0.0.1'> 1.168.109.in-addr.arpa' This assumes that your internal network dns server is on the same machine as the dnscache you're using to serve the information, and is configured to listen at the 127.0.0.1 address (internal loopback). If, instead, it is on a separate machine, you would echo that machine name into the file instead. As it happens, the syntax for doing reverse dnslookups is a reversed IP address followed by the 'in-addr.arpa' domain. This is presumably just one of those things that became standard a very long time ago. So, for example, if your domain is 20.50.86.2, your reversed ip address for reverse lookups would be .86.50.20.in-addr.arpa if you wanted everything in the 20.50.86.x subdomain to be looked up from the local tinydns service.
Attemped Idiot proofing by Honig the Apothecary