The Nameserver List

Now that your resolver knows which domains to try by default, you can tell it which nameservers to use. List each nameserver on a single line, in the order of preference. The nameservers will be tried in order. It would look something like this:

...............................................................................................

nameserver 127.0.0.1

nameserver	209.168.70.3
nameserver	192.168.87.3

...............................................................................................

Note that the first entry in this list is the "loopback" IP address 127.0.0.1. You'll need this entry if the machine is a nameserver because it tells the resolver to check the local host's nameserver. While in some rare instances you might not want to use the local nameserver, you don't have to, but in most cases it's a waste of network bandwidth not to.

With nameserver entries and either domain or search keywords, your /etc/resolv.conf is complete.

DNS Information Sources

To truly manage Internet services, you must be able to control your own domain naming service. While many ISPs will provide this service for you, you don't want to have to coordinate with their staff to make a vital change in your infrastructure.

Now that you know how to look at DNS data, and how the chain of DNS authority works, you can start building your own nameserver. FreeBSD includes all the software you need to run a DNS server; all you have to do is configure it and turn it on. We'll do so by building the two possible sources of hostname and IP address information: the hosts file and the named daemon. Each is configured separately.

The Hosts File

The /etc/hosts file matches Internet addresses to hostnames for a single host. However, while the hosts file is very simple, its contents are only effective on a single machine. One system cannot use the hosts file from another system, without some unpleasant tricks.

Dynamic nameserver programs have largely superseded /etc/hosts, but the hosts file is still useful on small networks or behind a Network Address Translation (NAT) device. For example, the hosts file is just fine if you have one or two servers and if someone else is responsible for managing your public nameservice. If you have multiple servers that would each have to be maintained separately, you should investigate using a full−fledged nameserver.

Each line in /etc/hosts represents one host. The first entry on each line is an IP address, and the second is the fully qualified domain name of the host, such as mail.mycompany.com. Following these two entries you can list an arbitrary number of aliases for that host.

For example, a small company might have a single server that handles mail, FTP, Web services, DNS, and a variety of other functions. A desktop on that network might have a hosts entry

275

something like this:

...............................................................................................

192.168.1.2 mail.mycompany.com mail ftp www dns dns

...............................................................................................

Using this /etc/hosts entry, the desktop could find that host (mail.mycompany.com) with either the full domain name or any of the brief aliases listed (such as ftp.mycompany.com, www.mycompany.com, and so on).

If you find that you need more than two or three hosts entries, or that maintaining hosts files is becoming a problem, it's a sign that you need to build a nameserver to handle your hosts data. A nameserver is far more scalable than a hosts file on each machine, and it's much simpler to maintain once you set it up.

The Named Daemon

The most popular DNS server software is BIND (Berkeley Internet Name Daemon). (The actual server program is called named(8).) BIND is actually a suite of tools that includes named and supporting programs such as dig.

BIND is maintained by the Internet Software Consortium (http://www.isc.org/) and is released under a BSD−style license. While there are competitors, such as djbdns (/usr/ports/net/djbdns), BIND is considered the nameservice reference implementation, so we'll focus on it. The concepts used in BIND are generally applicable to any nameserver programs.

Because BIND has been the target of malicious hackers over the last several years, its most recent version was completely rewritten with a focus on security. It includes some very powerful security features and extremely defensive programming.

Masters and Slaves

No matter what nameserver daemon you use, you'll keep running into the terms masters and slaves. Every domain needs at least two nameservers, but only one can be the master; the rest are slaves.

A master nameserver is the final authority on a domain. When you make changes to a domain, you make the changes on the master nameserver. The slaves take their information from the master nameserver for that domain.

One nameserver can be both a master for some domains and a slave for others. For example, http://absolutebsd . com/ has two nameservers, http://blackhelicopters . org/ and http://ralph.glblnet.com/; http://blackhelicopters.org/ holds the original reference files for this domain, and any changes are to be made on that system. That makes http://blackhelicopters.org/ the master nameserver. Every so often, http://ralph.glblnet.com/ updates its records for this domain from http://blackhelicopters.org/, making it the slave. If the blackhelicopters.org system is abducted by a l i e n s , h t t p : / / r a l p h . g l b l n e t . c o m / w o u l d c o n t i n u e t o s e r v e D N S i n f o r m a t i o n f o r http://absolutebsd.com/.

On the other hand, http://ralph.glblnet.com/ holds the master records for many other domains, and other nameservers update their records for these domains from http://ralph.glblnet.com/. Therefore,

276

http://ralph.glblnet.com/ is both a master and a slave nameserver, but for different domains.

Forward and Reverse DNS

You may have heard of or otherwise encountered the concepts of forward and reverse DNS. Forward DNS is what you do when you have a hostname and you look up an IP address. You saw examples of forward DNS in the A records in our dig examples:

...............................................................................................

nostarch.com. 2h13m2s IN A 66.80.60.21

...............................................................................................

The A means that this is an address record, or forward DNS. This is known as an “A record” or an “address record.”

Reverse DNS is what you do when you have an IP address and want a hostname. For example, suppose your system logs show that someone keeps trying to connect to your SSH server from the IP address 66.80.60.21, and you want to know the name of that host. You can look up IP addresses using dig's −x option. Much of the output will look the same as a forward lookup, but the answer is considerably different:

...............................................................................................

# dig –x 66.80.60.21

...

;; ANSWER SECTION:

21.60.80.66.in−addr.arpa. 2h24m IN PTR www.megapathdsl.net. …

#

...............................................................................................

Examining this output we see that, for historical reasons we won't delve into, IP addresses are displayed in reverse order and as part of the domain in−addr.arpa when you're doing a reverse lookup. Next we have the usual time−to−live data and the IN for Internet data.

The interesting part is the PTR or pointer record, which tells us that an IP address "points to" a name. Basically, this is the canonical, most correct hostname for an IP address. This is much like a phone system; again, while many people can share a phone number, it's only registered to one person.

Forward and reverse DNS are generally expected to match, but since many hosts can share one IP address, an A record does not necessarily need a matching PTR record. For example, we saw earlier that http://nostarch.com/ has an IP of 66.80.60.21, but the hostname associated with that IP address is http://www.megapathdsl.net/. The part that must match is the A record for http://www.megapathdsl.net/. If the hostname given by a reverse lookup does not have a matching forward record, DNS is not correctly configured, and the tools that rely upon DNS checking, such as certain configurations of TCP wrappers, will reject connections from this system. Fortunately, automated tools exist to check forward and reverse DNS matches.

277

In−addr.arpa

There's one major difficulty with PTR records: Often, when they appear, they're listed backwards.

Y o u s e e , D N S c h e c k s h o s t s f r o m l e f t t o r i g h t . W h e n y o u c h e c k f o r t h e h o s t http://www.absolutebsd.com/, the nameserver first looks for a nameserver for .com. It then checks under . com for http://absolutebsd . com/, then under http://absolutebsd . com/ for http://www.absolutebsd.com/. The biggest units are on the left, but in an IP address, the biggest unit is on the right. To check the IP address, we have to reverse it. For example, we turn 66.80.60.21 into 21.60.80.66.

It's very easy to confuse a forward IP address with a reversed IP address, so DNS uses a special marker to indicate that an IP address is reversed. Reversed IP addresses have the string "in−addr.arpa" on the end of them. (The reasons for this date back several years and are quite boring, so we won't go into them.) The bottom line is that our 66.80.60.21 becomes 21.60.80.66.in−addr.arpa.

So why not just leave the IP address forward, and use the in−addr.arpa to indicate it's a reverse DNS check? Glad you asked. The preceding address is a simple one, and if you ran dig, it would check a very limited space. If you're running a large network, you might need to run a DNS query of a much larger range of IP addresses, like 118.168.192.in−addr.arpa, which would translate to everything under 192.168.118. You might even need to run 168.192.in−addr.arpa, or even 192.in−addr.arpa. Each is a check of an increasingly large space—much like doing dig .com. (You'll probably never need to run dig .com, but Internet backbone engineers do, and backbone engineers are the ones who write this sort of program. One of the problems with using professional−strength tools is that they're geared toward, well, professionals.)

Note If you're looking for quick−and−dirty answers, host(1) does this reversal for you. Dig also does this for you, if you use the −x option. Don't be confused when you see in−addr.arpa, however.

Configuring Named

Before you can start named, you need to set it up. The directory /etc/namedb contains the basic named configuration files.

named.root

One file that must be present, but that doesn't need editing, is named.rooti, which lists the root nameservers. If a nameserver receives a query for a site it doesn't have in its cache, it asks these nameservers. (This file changes rarely—the last update was in August 1997.) You may need to edit this file if your system is not on the Internet and if you have a private root server.

named.conf

The other important file is named.conf, named's central file. If your named.conf file is broken, your nameserver is hosed.

The syntax of named.conf resembles C code. If you don't know C, though, don't worry, because the rules are very simple, and the examples demonstrate everything you need to know. Any line beginning with two slashes (//) is a comment. Similarly, any text contained within old−fashioned C comment marks (/* and */) is a multi−line comment.

278

There are two types of entries in named.conf: options and zones. Everything in your configuration file should be either an option, a zone, or a comment. A zone is a fancy name for a domain (while they aren't, strictly speaking, identical, they're close enough for our purposes). Options control how BIND operates.

Options

If you ignore the comments in the default named.conf, the file opens with a list of options, most of which are obscure and are commented out by default. You use options by putting them in the options section of the file, which contains the word options and a set of curly brackets. The actual options go between the brackets and are separated from one another by semicolons. Here's a very simple options section from a named.conf file:

...............................................................................................

options {

directory "/var/named"; listen−on {127.0.0.1; 209.69.178.18; };

};

...............................................................................................

In this example, the option directory has the value “/var/named”, and the listen−on option lists two IP addresses.

Let's first look at the directory option, which specifies the directory where named.conf will look for and store DNS files. Beginning here will make setting up your server more straightforward.

The default directory (/etc/namedb) should be fine if all you want to do is provide a nameservice for a couple of domains. However, if you are providing DNS for dozens or hundreds of clients, this directory will quickly become painfully full and will be unable to live on the root partition.

The standard alternative to /etc/namedb is /var/named, which is the location for nameservice files on larger servers. I generally use /var/named even when I have just a few domains to serve, as these files tend to accumulate.

The listen−on option controls which IP addresses named will accept connections on. If you have dozens of IP addresses on a single network card, you might want to confine your named to attaching to only one of those addresses. (This is particularly valuable if you have jails on your system.)

BIND supports many more options, but these are perhaps the most popu− lar. You can check the full BIND Operators’ Guide (at http://www.isc.org/) for the complete list of options and their usage.

Zones

The default named.conf defines three zones, or domains, that the nameserver handles by default: the root zone, the IPv4 localhost, and the IPv6 localhost. Each of these zones has an entry in named.conf, beneath the options list. You shouldn't need to tweak the default zones—in fact, if you're thinking of changing them, you're almost certainly doing something wrong. But we'll discuss what these zones are for and what they do.

279

The Root Zone

The nameserver uses the root zone when it has no information on a requested domain or host. These queries are recursed to a root nameserver. Here's the named.conf entry for the root zone:

...............................................................................................

zone v "." {

w type hint;

x file "named.root";

};

...............................................................................................

The first entry (v) tells which domain this entry is for. The dot, in quotes, indicates that this is for the entire Internet.

The type (w) is an indicator that says what sort of domain this is. The root zone is special, and it is the only one with the type of hint.

Finally, the file keyword (x) tells named which file contains the information for this domain. Named will look in the directory specified in the directory option for a file of this name, and will assign its contents to this zone. We'll look at these files later.

Localhost Zones

The localhost zones (IPv4 and IPv6) are used for the local host; they provide DNS services for the loopback IP address, 127.0.0.1. Without them, each system call that tried to look up the hostname for the local host would have to wait to time out, slowing the system immeasurably. Each looks much like the root zone, with a different filename.

Here's the configuration for the IPv4 localhost zone. You'll find it in named.conf, just under the root zone:

...............................................................................................

zone v "0.0.127.IN−ADDR.ARPA" { w type master;

x file "localhost.rev";

};

...............................................................................................

Looks pretty similar to the options statement and the root zone in the previous section, doesn't it?

The zone name (v) appears in quotes after the word zone. Because this zone is used for reverse DNS, we see IN−ADDR.ARPA. (If you reverse the IP address, you'll see it's actually for the 127.0.0 group of IP addresses.)

The type (w) indicates whether this nameserver is a master or a slave for this domain. Every nameserver is a master for the localhost zones.

Finally, the file keyword (x) tells the nameserver where the file of information on this domain can be found. The information on this zone is contained in the file localhost.rev, found in the directory specified in the directory option.

280

Setting Up a Slave

Perhaps the easiest task in DNS is to set up a slave domain. The entry will look much like the entries for the root zone and the localhost zone. You need to know the name of the domain you want to slave, and the IP address of the master nameserver.

To set up a slave domain, copy the localhost zone entry and change it slightly. The configuration for the slave server for http://absolutebsd.com/, for example, looks like the following, which closely resembles the root and localhost zones.

...............................................................................................

v	zone "AbsoluteBSD.com" {	w type slave;	x file
"AbsoluteBSD.com.db";		y masters {209.69.178.18;};
}

...............................................................................................

We have the domain name (v), a label for the type of zone it is (w), and a filename (x). The filename is where the information for the domain is kept. It's traditional in DNS to give these files the same name as the domain, with a ".db" extension. (Despite what the extension might imply, these files are in no way databases.) This file will be created when the slave downloads the domain data from the master.

We then have the IP address of the master server (y). The slave will request the domain's DNS information from the master at regular intervals. (We'll see what sort of intervals later.) The master nameserver must be listed by IP address; after all, the DNS server must be able to bootstrap its records before it knows the IP of anything!

Setting Up a Master

The named.conf configuration you need when you want a server to be a master is even simpler than the setup for a slave zone:

...............................................................................................

v zone "AbsoluteBSD.com" { w type master; x file

"AbsoluteBSD.com.db";

}

...............................................................................................

Once more there's the domain name (v), a label for the type of zone it is (w), and a filename (x). Unlike a slave domain, you'll have to create this file. We'll look at how to create that file in the "Zone Files" section.

Setting Up Multiple Zones

If you're managing high−end Internet nameservers, you may be responsible for thousands of domains. If you screw up, you will have a lot of people very angry with you. Therefore, before you set up hundreds of zones, think about how you're going to arrange them.

One thing that can make your life easier when setting up multiple zones is to divide a server's zone files between those that the server is the master for and those that the server just backs up. I usually do this with two directories, master and slave. Files in the master directory are sacred, and

281