Set up a caching name server. Then add zone blocks to named.confto define the new zones for your LAN hosts, and construct the zone files.

Table 1 lists the five hosts on windbag.net.

Add these zone blocks to named.conf:

zone "windbag.net" IN {

  type master;

  file "zone.net.windbag";

};

zone "12.11.10.in-addr.arpa" {

  type master;

  file "revp.10.11.12";

};

Here is the actual zone file for windbag.net:

// zone.net.windbag

// dns zone for for windbag.net

;

$ORIGIN windbag.net.

$TTL 1D

; any time you make a change to the domain, bump the

; "serial" setting below. the format is easy:

; YYYYMMDDI, with the I being an iterator in case you

; make more than one change during any one day

@     IN SOA   parsley hostmaster (

                        200405191 ; serial

                        8H        ; refresh

                        4H        ; retry

                        4W        ; expire

                        1D )      ; minimum

; parsley.windbag.net serves this domain as both the

; name server (NS) and mail exchange (MX)

                NS      parsley

                MX      10 parsley

; define domain functions with CNAMEs

ftp             CNAME   sage

www             CNAME   rosemary

; just in case someone asks for localhost.windbag.net

localhost       A       127.0.0.1

; our hostnames, in alphabetical order

rosemary            A       10.11.12.3

sage                A       10.11.12.2

parsley             A       10.11.12.1

thyme               A       10.11.12.4

cilantro            A       10.11.12.5

And finally, here are the reverse lookups for the domain in the revp.10.11.12 file:

; revp.10.11.12

; reverse pointers for 10.11.12.0 subnet

;

$ORIGIN 12.11.10.in-addr.arpa.

$TTL 1D

@     IN SOA  parsley.windbag.net. hostmaster.windbag.net. (

              200405190  ; serial

              28800      ; refresh (8 hours)

              14400      ; retry (4 hours)

              2419200    ; expire (4 weeks)

              86400      ; minimum (1 day)

              )

; define the authoritative name server

              NS      parsley.windbag.net.

; our hosts, in numeric order

1             PTR     parsley.windbag.net.

2             PTR     sage.windbag.net.

3             PTR     rosemary.windbag.net.

4             PTR     thyme.windbag.net.

5             PTR     cilantro.windbag.net.

Save your changes and restart BIND:

# /etc/init.d/named restart

And there you are—a shiny new fully functioning DNS server for your LAN.

There’s a whole lot happening in these three files. First of all, putting each zone into its own file is good organization. You may dump everything into a single zone file if you like, but you’ll find that it’s difficult to maintain.

In named.conf, the entries for windbag.net tell BIND that it is the authoritative server for windbag.net, and where to find the zone files.

The $origin directive is a nice timesaver. It lets you write:

$ORIGIN windbag.net.

www           CNAME   rosemary

instead of:

www.windbag.net    CNAME     rosemary.windbag.net

$TTL 1D sets a default time-to-live value. Values can be in this format:

w

For week

d

For day

h

For hour

m

For minute

s

For second

Individual entries may have their own TTL values:

rosemary      72h    A       10.11.12.3

The TTL tells visitors how often to refresh their own caches. If your site is fairly static, set this to a higher value. If you’re making frequent changes, use a lower value. The lower the TTL, the more hits there will be on your server.

@ IN SOA parsley hostmaster means:

@

This holds the same value as $ORIGIN.

IN

This defines the address class; IN = Internet.

SOA

Start of Authority; the beginning of a zone file. Only A records can be used as the MNAME—don’t use CNAMEs.

The SOA has 10 fields. These are the primary domain name, zone class, and SOA, plus the following:

MNAME

The master name server for the zone.

RNAME

The email address of the domain admin.

Serial number

BIND converts zone files into a binary file format. When you make changes to the zone file, you must also change the serial number, or BIND will not recognize the changes.

Refresh

This tells your slave, or secondary servers how often to check for updates.

Retry

If the master DNS server for the zone fails to answer a slave server’s request for an update, this tells the secondary server how often it should resend the request.

Expire

If the master DNS server fails for a longer period of time, this tells the the secondary server how to continue to use its existing data. After the expire time has passed, the data is considered stale and will not be used, at which time the domain will no longer resolve. Hopefully your master server will be back online before this happens.

Minimum, or Negative-caching TTL

Negative answers (such as when a requested record does not exist) should also be cached on nonauthoritative servers. Setting this value prevents your server from getting hammered by a bunch of repeated requests in a short time. A common use for this is when you are migrating to a new name server at a different IP address; setting a short value on the old server a few days before you take it offline assures that your change will propagate quickly.

The next section contains resource records (RRs).

NS parsley and MX 10 parsley define your name server and mail server. If you have more than one mail server for the domain, the number sets the priority. Lower numbers are higher priority. Because $ORIGIN windbag.net. defines the domain name for the whole record, these expand to ns.windbag.net and mx.windbag.net. Make note of the trailing dot—this is very important! That defines the qualified domain name. If you leave it off, BIND will think it needs to append the domain name, so you’ll have silliness like ns.windbag.net.windbag.net.

CNAME (canonical name) is an alias to an A record. Thus, a single A record can have several aliases. You can use a CNAME to add subdomains for virtual web or mail hosting—for example, programmers.only.domain.com or webmail.domain.com.

Instead of using CNAMES, you may assign subdomains their own A records. This means one less hit on your server per CNAME request, but it also means more work when you need to make changes. Endless debates rage over the use of CNAMEs; use what suits you.

"Canonical" is one of those weirdo geek words that defies a precise, logical definition. In this context, "canonical name" means "an alias assigned to the true (canonical) name of the server."

And finally, we come to the A (alias) records. An A record is the primary address for each of your hosts, the direct match of hostname to IP address.

Reverse pointers (RPTs) are technically not required, but in the real world so many servers require them that you had better use them.

If things are not working right, chances are it’s a syntax error or a typo—mind your dots and commas especially. There are two syntax checkers for BIND to help you.

The other common error is not starting from A records. Every host must first have an A record. Then you can assign name servers, mail servers, and CNAMEs.

Install BIND on a Linux machine with a static IP address. Be sure you get the latest version. Don’t mess with older versions, as they are buggy and exploitable. After installation, you’ll have four configuration files to edit or create:

• named.conf
• named.root
• zone.localhost
• revp.127.0.0

Al of these files are in /var/named, except for /etc/named.conf. named.confis the standard name for BIND’s configuration file; all the others you can name to suit yourself. Here is a sample named.conf:

//BIND configuration file

//named.conf for caching server

options {

// where all zone files are

  directory "/var/named";

// accept queries only from local subnet

  listen-on {

           127.0.0.1;

           10.11.12.1;

    };

  allow-recursion {

           127.0.0.0/8;

           10.11.12.0/24;

    };

};

zone "." IN {

     type hint;

     file "named.root";

};

// location of the zone file for localhost

zone "localhost" IN {

  type master;

  file "zone.localhost";

  allow-update { none; };

};

// reverse pointer file for localhost

zone "0.0.127.in-addr.arpa" IN {

  type master;

  file "revp.127.0.0";

  allow-update { none; };

};

Now add named.root.This is the master list of the root name servers; simply fetch the current version from ftp://ftp.internic.net/domain/named.root, and put it in /var/named.

Now create zone.localhost:

; zone.localhost

; loopback/localhost zone file

;

$TTL 1D

$ORIGIN localhost.

@              IN  SOA   @  root (

                         1   ; Serial

                         8H  ; Refresh

                         15M ; Retry

                         1W  ; Expire

                         1D) ; Minimum TTL

               IN   NS   @

               IN   A    127.0.0.1

Finally, create revp.127.0.0:

; revp.127.0.0

; reverse pointers for localhost

;

$TTL 1D

$ORIGIN 0.0.127.in-addr.arpa.

@    IN   SOA  localhost. root.localhost. (

               1    ; serial

               8H   ; refresh

               15M  ; retry

               1W   ; expire

               1D ) ; minimum

     IN   NS   localhost.

1    IN   PTR  localhost.

Then start up BIND:

# /etc/init.d/named start

You now have a local caching name server. See this to learn how to connect client PCs to your caching server.

named is short for "name daemon."

BIND configuration files can grow and multiply like weeds, so using a naming convention like the one shown here will save your sanity. Zone files each start with "zone," and reverse pointer files start with "revp." You may call them anything you want, as long as you use a consistent naming scheme.

You can use each one of these sample files exactly as they are shown. The only change you might need to make is the listen-on directive in named.conf—be sure to use your own network IP addresses. Leave localhost exactly as it is shown, unless you’re using some exotic networking voodoo, in which case you already know what to do. Do not allow traffic from outside your network! There is no reason for you to supply caching services to the world.

The named.root filedoes not change very often. Check it every few months just for kicks. You may call it anything you like, as long as you record the filename in named.conf.

zone.localhost tells named that the address of localhost is 127.0.0.1.

revp.127.0.0 does the opposite of zone.localhost—it tells named that the hostname associated with the IP address 127.0.0.1 is localhost.

Plain old rsync-over-ssh does the job just fine. This simple script copies your DNS data file to the backup, then runs make on the remote data file:

rsync -e ssh -az /etc/tinydns/root/data $backup-host:/etc/tinydns/root/data

ssh $backup-host "cd /etc/tinydns/root; make"

Replace $backup-host with the name or IP address of the remote server.

You can automate the entire process by adding these lines to /etc/tinydns/root/Makefile, so that when you run the make command on your primary server after updating /etc/tinydns/root/data, the backup will automatically be updated as well:

data.cdb: data

       /usr/local/bin/tinydns-data

       rsync -e ssh -az /etc/tinydns/root/data $backup-host:/etc/tinydns/root/data

       ssh $backup-host "cd /etc/tinydns/root; make"

Moving plain old text files doesn’t require a lot of sophistication; rsync is a fine tool for the job. You may schedule regular updates via cron, or add transport security and authentication with encrypted ssh keys.

Your backup server can also function as your secondary DNS server. You can configure client PCs to use it, or register it just like your main DNS server for a public authoritative DNS server.

DNS round-robin, or load balancing, is simple to implement. Just list all of your servers in /etc/tinydns/root/data:

+www.pixels.net:208.201.239.37:86400

+www.pixels.net:208.201.239.38:86400

+www.pixels.net:208.201.239.39:86400

@mail.pixels.net:208.201.239.37:a::86400

@mail.pixels.net:208.201.239.37:b::86400

tinydns returns a set of up to eight random addresses for any single request. If any single server becomes unavailable, the client attempting to connect to the server will go on to the next one in line.

Set up a dnscache server for your LAN. Set up a tinydns server, and enter your internal hosts in /etc/tinydns/root/data.

Using the pixels.net domain to illustrate, the next step is to tell your local dnscache to query your local, private tinydns server for your domain information. Create these files using the IP address of your private tinydns server:

# echo 192.168.1.100 > /service/dnscache/root/servers/pixels.net# echo 192.168.1.100 > /service/dnscache/root/servers/0.168.192.in-addr.arpa

The dnscache user should own these files:

# chown dnscache: /service/dnscache/root/servers/pixels.net# chown dnscache: /service/dnscache/root/servers/0.168.192.in-addr.arpa

Next, restart dnscache:

# svc -t /service/dnscache

dnscache will now consult the local tinydns server for local addresses, and it will consult the /service/dnscache/root/servers/@ file for external addresses.

You can easily do this for multiple domains; just add more domain files to /service/dnscache/root/servers/.

You have to have officially registered domain names for this to work, even if you are not running any public services. If you want the ability to invent whatever domain names you want for your LAN, see this.

Remember that dnscache and tinydns should be on separate machines. Always separate the caching/resolving server from the authoritative server. If you must put them on the same machine, give them separate IP addresses. tinydns can have 127.0.0.1, and dnscache can take the network IP address.

First, follow the preparatory steps in to run a public DNS server. Then follow these steps to install and set up tinydns, which is the authoritative DNS server component of djbdns. If you are also running dnscache, it must not have the same IP address as tinydns. This is a very important security measure. Both dnscache and tinydns will fail silently if you do it anyway.

Follow these steps in for djbdns installation. Then, create two system users, using any names you like. They will own the tinydns server, and the dnslog:

# useradd -d /dev/null -s /bin/false tinydns

# useradd -d /dev/null -s /bin/false dnslog

Run tinydns-conf to create directories and set the IP address of the tinydns server. List your system users in the order shown here:

# tinydns-conf tinydns dnslog /etc/tinydns 208.201.239.36

Create a startup entry in service:

# ln -s /etc/tinydns /service

Wait a few seconds, then run svstat to verify that it started:

# svstat /service/tinydns /service/tinydns: up (pid 6811) 14 seconds

If tinydns won’t stay up continuously, check the logfile in /etc/tinydns/log/main/current. That will tell you where the problem is.

Now it’s time to create your host entries. This shows how to create entries using the scripts that come with tinydns. In this example the domain name is pixels.net, which is duly registered with a domain name registrar.

Create the host entries as follows:

# cd /service/tinydns/root

# ./add-ns pixels.net 208.201.239.36

# ./add-ns .239.201.208.in-addr.arpa 208.201.239.36

# ./add-host parsley.pixels.net 208.201.239.36

# ./add-host sage.pixels.net 208.201.239.37

# ./add-host rosemary.pixels.net 208.201.239.38

# ./add-alias ftp.pixels.net 208.201.239.37

# ./add-alias www.pixels.net 208.201.239.38

# make

That’s all it takes to build a tinydns server.

The previous commands inserted data into /etc/tinydns/root/data; here’s what it looks like:

.pixels.net:208.201.239.36:a:259200

.239.201.208.in-addr.arpa:208.201.239.36:a:259200

=parsley.pixels.net:208.201.239.36:86400

=sage.pixels.net:208.201.239.37:86400

=rosemary.pixels.net:208.201.239.38:86400

+ftp.pixels.net:208.201.239.37:86400

+www.pixels.net:208.201.239.38:86400

You typically configure djbdns by running configuration scripts, not by editing the data file by hand. Here are the available configuration scripts:

add-host

Creates both an A (alias) record and a PTR (reverse pointer)

add-mx

Adds a mail server

add-ns

Adds a name server

add-alias

Creates an A record but not a matching PTR

add-childns

Adds a child name server—use this when you want to act like an ISP and host other name servers

Here is a list of the leading symbols used by tinydns:

. (leading dot)

Name server

=

Both pointer (PTR) and A record

+

A record

&

NS and A records

@

MX and A records

As you can see, tinydns thoughtfully calculates the time-to-live (TTL) values for you. The TTL tells caching servers, in seconds, how often they should come back to refresh their information. tinydns will continue to adjust these automatically; don’t worry about tweaking them manually.

You can edit the djbdns data file manually, if you want. You can add comments, change the order of the entries, whatever you like. The scripts are for convenience, and to ensure that each entry is in the correct format. Just remember to run make every time you make a change, to convert the file to /etc/tinydns/root/data.cdb.

The clear separation of functions is one of the strengths of djbdns. You do not want your caching server anywhere near your authoritative DNS server. In other words, the IP addresses listed in /etc/resolv.conf should never match any IP addresses listed in NS records. If your caching server is compromised and is running on the same IP address as your DNS server, the attacker could misdirect all of your traffic, including "secure" web applications.

If your clients are served by DHCP, you need to edit your DHCP configuration file to point to your new name server.

Linux hosts with static IP addresses that are not served by DHCP configure their name servers in /etc/resolv.conf. In this example, your name server is at 192.168.1.200, so all you do is edit /etc/resolv.conf:

nameserver 192.168.1.200

The resolver queries the entries in order, so make this the first one if you have others. Typically, your ISP will list a primary and a secondary name server in your account information, so you can list these next:

nameserver 192.168.1.200

nameserver 12.188.166.2

nameserver 12.188.166.3

On Windows hosts with static IP addresses, find the menu for configuring Internet Protocol (TCP/IP) properties. In Windows 95/98/ME, go to Control Panel -> Network -> TCP/IP -> Properties. Go to the DNS Configuration tab, and there you are.

In Windows NT/2000/XP, go to Control Panel -> Network Connections. Right-click Local Area Connection, then select Internet Protocol (TCP/IP) -> Properties.

That’s pretty much all you have to do; a DNS cache is low-maintenance. You may enter up to three name servers on client machines.

Make sure you do not give the entire Internet access to your caching server! This is a big security hole; plus, there’s no reason for you to provide caching for the masses.

Windows 2000/XP comes with its own built-in DNS cache. You didn’t know it was there, did you. You can view the contents of the cache with this command:

C:\> ipconfig /displaydns

To flush the cache, use:

C:\> ipconfig /flushdns

Flushing the cache is a quick way to get rid of stale data, such as when you change a server’s IP address.

The caching component of djbdns is dnscache. First, prepare your system by installing daemontools, uspci-tcp, and djbdns

After installing everything, run a dnsip query to confirm that djbdns installed correctly:

$ dnsip www.oreillynet.com

208.201.239.37 208.201.239.36

Now create two system users to own dnscache and dnslog. Call them anything you want. In this example, they are simply "dnscache" and "dnslog":

# useradd -d /dev/null -s /bin/false dnscache

# useradd -d /dev/null -s /bin/false dnslog

Then configure the IP address and service directory for dnscache. This also assigns the appropriate file ownerships:

# dnscache-conf dnscache dnslog /etc/dnscache 192.168.1.5

Create your "allow" list; this example permits your local subnet to use your dnscache:

# touch /etc/dnscache/root/ip/192.168.1

Now start it up:

# ln -s /etc/dnscache /service

To verify that it’s running, use svstat:

# svstat /service/dnscache

/service/dnscache: up (pid 6776) 30 seconds

To verify that it’s working, run dnsqr to query the local cache:

# env DNSCACHEIP=192.168.1.5 dnsqr a www.yahoo.com

1 www.yahoo.com:

193 bytes, 1+9+0+0 records, response, noerror

query: 1 www.yahoo.com

answer: www.yahoo.com 286 CNAME www.yahoo.akadns.net

answer: www.yahoo.akadns.net 60 A 66.94.230.52

answer: www.yahoo.akadns.net 60 A 66.94.230.48

Configure clients to point to your dnscache server, and you’re finished.

A caching server, or caching DNS resolver, does two things: it answers DNS requests by getting the information from other servers, and then it stores the results so that it can answer future requests for the same information directly. The cache lives only in memory, so restarting the cache’s process or rebooting wipes it all out.

A caching server and an authoritative DNS server should always be strictly separated. This means the IP address of your caching server should never match any IP addresses listed in NS records. A few bad things can happen when you put them together:

• If an attacker seizes control of your DNS cache, the attacker can control not only your incoming DNS data, but also your outgoing DNS data—which means he can hijack your web sites, email, FTP, and any "secure" web-based applications.
• If your DNS cache suffers a Distributed Denial of Service (DDoS) attack, your authoritative server will also be pummeled, and you will have no DNS service.

RFC 2010 also advises keeping caching servers separate from authoritative servers:

Recursion is a major source of cache pollution, and can be a major drain on name server performance. An organization’s recursive DNS needs should be served by some other host than its root name server(s).

With BIND, you cannot separate the two. But you can with djbdns.

When you’re testing dnscache, and making changes and generally futzing around, sometimes you’ll find it won’t stay up:

# svstat /service/dnscache

/service/dnscache: up (pid 6776) 1 seconds

# svstat /service/dnscache

/service/dnscache: up (pid 6781) 0 seconds

You probably have too many instances of it running. Try this:

# netstat -nap | grep ":53"

tcp  0  0 127.0.0.1:53    0.0.0.0:*    LISTEN     6327/dnscache

tcp  0  0 192.168.1.5:53  0.0.0.0:*    LISTEN     6129/dnscache

udp  0  0 127.0.0.1:53    0.0.0.0:*               6327/dnscache

udp  0  0 192.168.1.5:53  0.0.0.0:*               6129/dnscache

Yep, that’s too many. You should have two instances only: listening on TCP port 53 and UDP port 53. Do a killall supervise dnscache, give it a few seconds, then try again:

# svstat /service/dnscache

/service/dnscache: up (pid 6776) 21 seconds

# netstat -nap | grep ":53"

tcp  0  0 192.168.1.5:53   0.0.0.0:*   LISTEN     6776/dnscache

udp  0  0 192.168.1.5:53   0.0.0.0:*              6776/dnscache

That’s what you want to see.

Another common problem is having an old BIND server still running. There Can Be Only One.

djbdns comes with a number of network querying and diagnostic utilities: dnsqr, dnstrace, dnsip, tinydns-get, dnsipq, dnsmx, and dnsname. See the links below to learn more about them.

To put the logfiles for tinydns in /var/log/tinydns, edit /etc/tinydns/log/run, as follows:

#!/bin/sh

exec setuidgid dnslog multilog t /var/log/tinydns

Do the same for dnscache, editing /etc/dnscache/log/run, as follows:

#!/bin/sh

exec setuidgid dnslog multilog t /var/log/dnscache

After installation, you’re ready to start configuration.

To install daemontools, follow these steps:

# mkdir -m 1755 /package

# cd /package

Download and unpack the latest daemontools tarball into /package, as follows:

# tar xzvpf daemontools-0.76.tar.gz

# cd admin/daemontools-0.76

To compile and set up the daemontools programs, use:

# package/install

Next, fetch the latest uspci-tcp tarball and install it:

# cd /usr/sources

# tar xzvf ucspi-tcp-0.88.tar

# cd ucspi-tcp-0.88

# make

# make setup check

It puts itself into /usr/local/bin.

Finally, fetch and install djbdns:

# tar xzvf djbdns-1.05.tar.gz

# cd  djbdns-1.05

# make

# make setup check

It puts itself into /usr/local/bin.

daemontools is a suite of utilities for managing services. You’ll see supervise, multilog, and svstat. supervise automatically restarts services if they die unexpectedly. multilog is a nice log manager that automatically rotates log data, so that logs don’t consume your disk space and you always have fresh data. svstat tells you the status of a service.

uspci-tcp takes the place of inetd and xinetd, for running djbdns and other Dan Bernstein programs. You don’t have to do anything other than install it.

djbdns is a suite of DNS programs.