Kiss Your BIND Good-bye: In-Depth Configuration with Tinydns

Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Last week we looked at the broad strokes of Tinydns, a replacement for
BIND you can drop into anything from a home LAN to an enterprise
deployment. This week it’s time to get in-depth with configuration,
so let’s start off with some clarification of terminology. DNS is
confusing enough, and BIND is the Lord of Vague Concepts. Simply
resolving names to IP addresses shouldn’t be complicated and weird,
but it is.

Recursive: this is a word that UNIX gurus use and abuse to
death. All it means is “you do whatever it takes to answer this
question.” A recursive DNS query means the program doing the query
keeps churning until an authoritative answer is found. Aha! you say, a
light dawning. That is why tinydns does not support recursion- to
close off one popular avenue for Denial of Service attacks. dnscache
handles recursive requests, that is why it is hidden away inside the
private network.

Iterative: pass the buck. tinydns supports iterative queries- it
hands off the query to other servers and forgets about it until
someone sends back an answer. Same as ‘non-recursive’.

Resolver: the program on the client that resolves names to
addresses. You’ve probably configured this without realizing it is
called ‘resolver.’ This is where you set the DNS servers and the
search order on the client machine- on Windows, it’s the ‘DNS
Configuration’ tab in the TCP/IP control panel. In Linux, it’s
/etc/resolv.conf.

Installation
As you have faithfully read and memorized all
of my columns, you will have already done part 1, and installed
daemontools and djbdns. Skip anything about afxr. afxr is reluctantly
included for zone transfers, DJ Bernstein recommends using rsync
instead. afxr uses DNS-over-TCP, which DJB does not like, both for
speed and security reasons.

Configuration
All right, now we have fun. It is a good idea to draw up a network map first: hostnames, nameservers, IP addresses, DHCP ranges, web and mail servers, domain name. Our sample domain is www.guru.com. There are all kinds of ways to organize your data, tables and flow charts are fun and easy to read.

Our setup is an Internet account with a static IP, and a firewall
doing NAT (network address translation). To run your own nameserver,
it must be officially registered. Your domain name registrar ought to
provide this service. In this example, I would register ns1.guru.com
with my static, routable IP address: 216.46.203.130. This will point
all Internet queries for your domain name to your static IP. Your
firewall must then direct traffic to the appropriate server inside
your network. This simplifies network management, you can move servers
around and change IPs without having the 24-72 hour DNS propagation
delay.

Another option is to run certain servers outside the NAT firewall,
perhaps a Web server. This is perilous, make sure it is tightly locked
down. It will require a static, routable IP of its own.

Caching In
On a small network, every PC can have its own cache. It’s free and easy. Create two user accounts, dnscache and dnslog. Make sure they cannot log in (/sbin/nologin). Run dnscache-conf to create the service directory:

$ dnscache-conf dnscache dnslog /etc/dnscache

Tell svscan about the new service:

$ ln -s /etc/dnscache /service

Edit /etc/resolv.conf:

nameserver 127.0.0.1

To create an external cache on the local network:
In this example the external cache is on bigserver1. Run dnscache-conf to create the service directory, with your server IP address at the end of the line:

# dnscache-conf dnscache dnslog /etc/dnscachex 192.168.1.15

Tell svscan about the new service:

# ln -s /etc/dnscachex /service

Because dnscache by default does not accept queries from remote hosts, this must be enabled:

# touch /etc/dnscachex/root/ip/192.168.1

to accept queries from 192.168.1*

The client machines’ resolvers must point to 192.168.1.15

For security, do not put dnscache on the same IP address as the name server. In Linux it easy to assign multiple IPs to the same NIC, using ifconfig:

# /sbin/ifconfig eth0:0 address 192.168.1.18

etho0 is the first NIC on your system, eth0:0 is the first alias, eth0:1 is the second, and so forth. A non-routable IP, such as the example above, is good, remember the cache should not be visible to the outside world.

DNS Itself
Create a tinydns user account, with no login privileges. Run tiny-dns.conf:

$ tinydns-conf tinydns dnslog /etc/tinydns 192.168.1.18

Tell svscan:

$ ln -s /etc/tinydns /service

There are two ways to configure tinydns. One is to use DJB’s
scripts, such as add-ns, add-mx, and add-host, the other is open the
tinydns configuration file, /etc/tinydns/root, and edit it directly. I
like to edit /etc/tinydns/root directly, so I can organize and comment
it to suit my needs. The scripts have error-checking and automatically
write the correct syntax. A good learning tool is to generate a config
file with scripts, then study it. Notice the different prefixes for
the different types of servers. tinydns uses letter suffixes- a, b, c,
etc., to indicate mailserver precedence.

#name of authoritative nameserver
.guru.com::ns1.guru.com
#mail exchangers
@guru.com::mail1.guru.com:a
@guru.com::mail2.guru.com:b
#webserver
+www.guru.com:192.168.1.16
+www.sales.guru.com:192.168.1.16
#computers
=mail1.guru.com:192.168.1.16
=mail2.guru.com:192.168.1.17
=ns1.guru.com:192.168.1.18

Remember, the only computers listed here are the ones that need to
be visible by name to the outside world. Doubtless you alert readers
have noticed there is no TTL (time to live) specified. tinydns
contains default values, you may also specify your own:

=mail1.guru.com:192.168.1.16:86400

There is no SOA (start of authority) line, either. Again, tinydns makes one for you, or specify your own:

Zguru.com:ns1.guru.com:hostmaster.guru.com

The final step is cd to /etc/tinydns/root, and run make. This converts the text file to csb (constant database) format. That’s all there is to it.

This is a very simple setup. djbdns will do zone transfers,
reverse DNS, parents and delegations, and load balancing, pretty much
anything you need. For way big networks, it supports using mySQL,
LDAP, and other backends. If you’re an experienced BIND admin, you may
think it is lacking a function you want, when it actually does it in a
different way.

djbdns Quirks
tinydns likes to use its own server prefixes: a.ns, b.ns, and so forth, rather than ns1, ns2. This is not an industry standard, and will not work on all domain name registrars. Use either one as it suits you. It has its own ideas about where its files should be installed, I have not tried moving them to see if that breaks anything. As long as it works well and does what I want, I’m not going to crab about file locations.

Resources
Life With djbdns
djbdns

»


See All Articles by Columnist Carla Shroder