So far, so good. Now assume that the master nameserver explodes, scattering your hard disk across three counties. What will happen to the slave server? The next time the slave tries to check to see if its records are out of date, it will be unable to reach the master. At that point, it changes how often it checks for updates. Instead of using the refresh time of four hours, it will use the retry time of one hour. Once it can successfully check the status of its records, it will go back to using the refresh time instead of the retry time.

If the slave cannot confirm its data for a length of time equal to the expire time, the domain data is considered too old to be useful and the slave nameserver will discard the data and return an error when anyone asks about the domain. The domain will disappear from the Net.

If your master nameserver really does fail in a horrible way, you have an amount of time equal to the expire plus the retry times to replace it or to reconfigure your slave as a master.

[1]DNS was created before the @ sign became popular in email addresses. This overlap is email's fault, not BIND's.

A Real Sample Zone

The localhost zone file is a somewhat contrived example; it represents only one machine, and has only the one IP address in it. But it's convenient, it's found on every nameserver, and all the data types given are either commonly used or flatout required.

Now let's consider a zone file that's more representative of the domains you'll be serving. We'll look at the relevant snippets from named.conf and the zone file for http://absolutebsd.com/.

named.conf

Here's a snippet from named.conf:

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

zone "AbsoluteBSD.com" { type master;

file "master/AbsoluteBSD.com";

};

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

In this example, we're telling named that it is responsible for the domain http://www.absolutebsd.com/, and that it's the master nameserver. We're also giving it the filename where the information on the domain can be found. If our directory option is set to /var/named, this file would be found in /var/named/master/ http://absolutebsd.com/. Without further ado, let's check out that file.

/var/named/master/absolutebsd.com

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

v	$TTL 345600
w	@	IN	SOA	blackhelicopters.org. root.blackhelicopters.org. (
				2001101501 ;	Serial
				86400 ; Refresh		−− 24 hours
				7200 ; Retry	−−	2 hours

286

					2592000	; Expire −− 30 days
					345600)	; Minimum −− 4 days
	x IN	NS	blackhelicopters.org.
			IN	NS	ralph.glblnet.com.
	y IN	MX	10		blackhelicopters.org.
			IN	MX	20 ralph.glblnet.com.
z	IN	CNAME		www.AbsoluteBSD.com.
www			IN	A	209.69.178.30

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

This file looks almost the same as the localhost file we looked at earlier, but it's an actual zone file from a real live Internet domain. Let's see what we've got. First we have the time to live (v), equal to four days, which means that when a nameserver grabs the IP information for this domain, it'll hang on to it for four days. The SOA record (w) lists the contact information and a variety of times for refresh, retry, and expire, as well as a serial number.

The zone file lists two nameservers (x): http://blackhelicopters.org/ and http://ralph.glblnet.com/. According to the times in the zone file, http://ralph.glblnet.com/ will compare its records to http://blackhelicopters.org/ every 24 hours. If it cannot compare its records successfully, it'll keep trying every 2 hours. If http://ralph.glblnet.com/ can− not check its records against the master nameserver for 30 days straight, it will stop giving any answer for http://www.absolutebsd.com/. Finally, remote nameservers will cache no−such−host responses for four days.

The Mail Exchanger

We then have a new record type, MX, the domain's mail exchanger (y). While a domain has only one primary mail host, it can have multiple backup mail servers. Nevertheless, the mail must ultimately reach the main mail host. Here's where you indicate which is the preferred mail server and which are backups. (We will discuss this in some detail in Chapter 14.)

Preference Numbers

The one additional entry in the MX record (the numbers 10 and 20) is a preference. Servers with lower preference numbers are more preferred. In this case, the server http://blackhelicopters.org/, with preference 10, is the preferred mail server for http://www.absolutebsd.com/. If http://blackhelicopters.org/ cannot be reached, http://ralph.glblnet.com/ is the backup.

Since you may someday want to add another mail server between the two, or change to a completely different preferred server, leave some space between your preference numbers. If you don't, and you number them 1, 2, 3, and so on, you won't have much flexibility later. For example, on the day when http://www.absolutebsd.com/ has thousands of clients receiving mail, I might have a set of MX records that look like this:

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

IN	MX	10	mail.AbsoluteBSD.com
IN	MX	20	mail2.AbsoluteBSD.com
IN	MX	30	mail.someothercompany.com

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

287