DjbDNS is a collection of Domain Name System tools. It includes software for all the fundamental DNS operations:
DNS cache: Finding addresses of Internet hosts. When a browser wants to contact www.hotwired.com, it first asks a DNS cache, such as djbdns’s dnscache, to find the IP address of www.hotwired.com. Internet service providers run dnscache to find IP addresses requested by their customers. If you’re running a home computer or a workstation, you can run your own dnscache to speed up your web browsing.
DNS server: Publishing addresses of Internet hosts. The IP address of www.hotwired.com is published by HotWired’s DNS servers. djbdns includes a general-purpose DNS server, tinydns; network administrators run tinydns to publish the IP addresses of their computers. djbdns also includes special-purpose servers for publishing DNS walls and RBLs.
DNS client: Talking to a DNS cache. djbdns includes a DNS client C library and several command-line DNS client utilities. Programmers use these tools to send requests to DNS caches.
DjbDNS also includes several DNS debugging tools, notably dnstrace, which administrators use to diagnose misconfigured remote servers.
- dnscache runs as a dedicated non-root uid inside a chroot jail, so it can’t touch the rest of the machine.
- tinydns runs as another dedicated non-root uid inside its own chroot jail.
- walldns runs as another dedicated non-root uid inside its own chroot jail.
- dnscache discards DNS queries from outside a specified list of IP addresses.
- dnscache and the dns library use a new query ID and a new UDP port for each query packet. They discard DNS responses from any IP address other than the one that the corresponding query was just sent to.
- dnscache uses a cryptographic generator to select unpredictable port numbers and IDs.
- dnscache is immune to cache poisoning.
tinydns never caches information. It does not support recursion.
apt-get install build-essential
wget -c HYPERLINK “http://www.thedjbway.org/patches/djb_errno_patches.tgz” http://www.thedjbway.org/patches/djb_errno_patches.tgz
tar -zxvf djb_errno_patches.tgz
wget -c HYPERLINK “http://cr.yp.to/daemontools/daemontools-0.76.tar.gz” http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
wget -c HYPERLINK “http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz” http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
wget -c HYPERLINK “http://cr.yp.to/djbdns/djbdns-1.05.tar.gz” http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
Install All The Packages
a. Install ucspi-tcp-src:
tar -zxvf ucspi-tcp-0.88.tar.gz
patch -p1 < /tmp/downloads/ucspi-tcp-0.88.errno.patch
make setup check
tar -zxvf daemontools-0.76.tar.gz
patch -p1 < /tmp/downloads/daemontools-0.76.errno.patch
# svscan - daemontools start on runlevel 2 start on runlevel 3 start on runlevel 4 start on runlevel 5 stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /command/svscanboot
This installer only creates links to all svscan commands in /command, so it’s better to copy these:
rm -rf *
cp /tmp/downloads/admin/daemontools/command/* /command/
That’s all… then (you might need to reboot) …
initctl start svscan
tar -zxvf djbdns-1.05.tar.gz
echo gcc -O2 -include /usr/include/errno.h > conf-cc
make setup check
Create users (if they haven’t been created automatically):
adduser –no-create-home –disabled-login –shell /bin/false dnscache
adduser –no-create-home –disabled-login –shell /bin/false dnslog
adduser –no-create-home –disabled-login –shell /bin/false tinydns
In our scenario, we need each master and slave server(s) as both “authoritative” and “caching”. So it is very important to understand that how to achieve these with djbdns. Unlike bind, djbdns uses individual IP for each kind of dns service. By default each system is ready with 2 IP’s => one host-IP and other is loopback-IP. So any system on LAN should hit caching dns, hence the host-IP for caching-dns. And we will run authoritative on loopback-IP, and later bind that to caching-dns, hence LAN hosts can query authoritative host records also.
dnscache-conf dnscache dnslog /var/lib/svscan/dnscache <host-IP>
ln -sf /var/lib/svscan/dnscache /service
Check that “supervise” directory was create in /service/dnscache
To check it’s running: just add only single entry like ‘nameserver <host-IP>’ in /etc/resolv.conf and do check some public website query using ‘nslookup’ or ‘dig’ from command-line.
Now you need to allow the LAN hosts to query from it. So just create a blank file named after your network or subnet as:
That’s it. Now you can query from any of hosts of that <subnet>. Similarly you can enable multiple hosts, networks or subnets for query.
Unlike bind, you can adjust the nameserver’s cache size by editing the file /etc/dnscache/env/CACHESIZE. Also you can manually refresh or flush the cache by running the following command:
svc -t /service/dnscache
Temporarily you can stop and start dnscache with the following commands:
svc -d /service/dnscache => to down the dnscache service
svc -u /service/dnscache => to up the dnscache service
tinydns-conf tinydns dnslog /var/lib/svscan/tinydns <loopback-IP>
ln -sf /var/lib/svscan/tinydns /service
Check that “supervise” directory was created in /service/tinydns.
They don’t contain any zone entries for any domains yet, but we’ll get to that in a bit. Well unlike bind the zone information are written in a single file (even for multiple zones, including reverse-zones) and that is /var/lib/svscan/tinydns/root/data. This is a human writable file which is later converted in binary format using a tinydns-command and that binary is called cdb format, so that binary file is /var/lib/svscan/tinydns/root/data.cdb from where tinydns answers all queries. The syntax for zone records is very short and compact compared to bind. Here are some examples:
a. For name server entry:
b. For reverse-dns for above name-server:
c. For MX records:
d. A records:
e. Alias records for hosts:
And finally convert /var/lib/svscan/tinydns/root/data to cdb format by
At the end to bind these zone information to the caching-dns server, create files named like 10.in-addr.arpa, in.domain.com and domain.com etc. in the /var/lib/svscan/dnscache/root/servers/ directory, whose contents should be 127.0.0.1 (the Loopback-IP). That’s it. It’s all set up.
Note: Whenever you are making any changes on data and create a changed data.cdb file, don’t forget to refresh or flash the cache.
svc -t /services/*
Slave Server Setup Using Djbdbs
Just follow http://www.seebq.com/dns-replication-using-rsync and some tweaks on some files of Master and Slaves.
a. Changes on master’s /var/lib/svscan/tinydns/root/Makefile: Edit the file as
remote: data.cdb rsync -az -e ssh data.cdb <slave-ip>:/service/tinydns/root/data.cdb ssh <slave-ip> 'svc -t /service/dnscache' data.cdb: data /usr/local/bin/tinydns-data svc -t /service/dnscache
b. Changes on slave’s /var/libsvscan/tinydns/root/data file as
# Do not edit data on this computer! data.cdb is copied from MASTER. # The following line protects data.cdb by stopping make. 9
So if by mistake anybody types make command in /etc/tinydns/root/ directory or the command tinydns-data, this will just flash the cache as there is no data file in slave(s).
And yes just an auto-ssh login setup between master to slave(s) so that the above changes will automate the process. The above changes will push only the data.cdbfile over to the slave(s). So no chance of different data across name servers, means consistency across all.
Backup And Restore
As minimum we need just copy of the /var/lib/svscan/tinydns/root/data file or else at max the whole /var/lib/svscan/dnscache and /var/lib/svscan/tinydns. That’s it.
For restoration, just set up dnscache or tinydns, it will hardly take any time, and copy the backup data. Finally soft link to /service. That’s it.