Setting Up Zone Data (DNS and BIND, 4th Edition)

4.2. Setting Up Zone Data

Our first step in setting up the Movie U. name servers is to translate the host table into equivalent DNS zone data. The DNS version of the data has multiple files. One file maps all the host names to addresses. Other files map the addresses back to host names. The name-to-address lookup is sometimes called forward mapping , and the address-to-name lookup reverse mapping. Each network has its own file for reverse-mapping data.

As a convention in this book, a file that maps host names to addresses is called db.DOMAIN. For movie.edu, this file is called db.movie.edu. The files mapping addresses to host names are called db.ADDR, where ADDR is the network number without trailing zeros or the specification of a netmask. In our example, the files are called db.192.249.249 and db.192.253.253; there's one for each network. The db is short for database. We'll refer to the collection of db.DOMAIN and db.ADDR files as zone data files. There are a few other zone data files: db.cache and db.127.0.0. These files are overhead. Each name server must have them, and they are more or less the same for each server.

To tie all the zone data files together, a name server needs a configuration file -- for BIND Version 4, this file is usually called /etc/named.boot. For BIND Versions 8 and 9, it is usually called /etc/named.conf. The format of the zone data files is common to all DNS implementations: it's called the master file format. The format of the configuration files, on the other hand, is specific to the name server implementation -- in this case, BIND.

4.2.1. The Zone Data Files

Most entries in zone data files are called DNS resource records. DNS lookups are case-insensitive, so you can enter names in your zone data files in uppercase, lowercase, or mixed case. We tend to use all lowercase. However, even though lookups are case-insensitive, case is preserved. That way, if you add records for Tootsie.movie.edu to your zone data, people looking up tootsie.movie.edu will find the records, but with a capital "T" in the domain name.

Resource records must start in the first column of a line. The resource records in the example files in this book do start in the first column, but they may look indented because of the way the book is formatted. In the DNS RFCs, the examples present the resource records in a certain order. Most people have chosen to follow that order, as we have here, but the order is not a requirement. The order of resource records in the zone data files is as follows:

SOA record

NS record

Other records: Data about hosts in this zone

Of the other records, this chapter covers:

A

PTR

CNAME

Those of you who have some experience with the master file format will no doubt look at our data and say to yourselves, "It would have been shorter to specify it this other way...." We're not using abbreviations or shortcuts in our zone data, at least not initially, so that you'll understand the full syntax of each resource record. Once you understand the long version, we'll go back and "tighten up" the files.

4.2.2. Comments

The zone data files are easier to read if they contain comments and blank lines. Comments start with a semicolon and finish at the end of the line. As you might guess, the name server ignores comments and blank lines.

4.2.3. Setting the Zone's Default TTL

Before we start writing our zone data file, we have to find out what version of BIND we're running. The version makes a difference because the way you set the default time to live for a zone changed in BIND 8.2. Prior to BIND 8.2, the last field in the SOA record set the default TTL for a zone. But just before BIND 8.2 came out, RFC 2308 was published, which changed the meaning of the final field in the SOA record to the negative caching TTL. This is how long a remote name server can cache negative responses about the zone, answers that say that a particular domain name or the type of data sought for a particular domain name doesn't exist.

So how do you set a default TTL for a zone in BIND 8.2 and later? With the new $TTL control statement. $TTL specifies the time to live for all records in the file that follow the statement (but precede any other $TTLstatements) and don't have an explicit TTL.

The name server supplies this TTL in query responses, allowing other servers to cache the data for the TTL interval. If your data doesn't change much, you might consider using a default TTL of several days. One week is about the longest value that makes sense. You can use a value as short as one hour, but we typically don't recommend TTLs lower than that because of the amount of DNS traffic they cause.

Since we're running a new version of BIND, we need to set a default TTL for our zones with a $TTL statement. Three hours seems about right to us, so we start our zone data files with:

$TTL 3h

If you're running a name server older than BIND 8.2, don't try adding a $TTL statement -- the name server won't understand it and will treat it as a syntax error.

4.2.4. SOA Records

The next entry (the first for pre-8.2 BIND servers) in each of these files is the SOA (start of authority) resource record. The SOA record indicates that this name server is the best source of information for the data within this zone. Our name server is authoritative for the zone movie.edu because of the SOA record. An SOA record is required in each db.DOMAIN and db.ADDR file. There can be one, and only one, SOA record in a zone data file.

We added the following SOA record to the db.movie.edu file:

movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 day

The name movie.edu. must start in the first column of the file. Make sure the name ends with a trailing dot, as ours does here, or you'll be surprised at the result! (We'll explain later in this chapter.)

The IN stands for Internet. This is one class of data -- other classes exist, but none of them is currently in widespread use. Our examples use only the IN class. The class field is optional. If the class is omitted, the name server determines the class from the statement in the configuration file that instructs it to read this file. We'll see this later in the chapter, too.

The first name after SOA (terminator.movie.edu.) is the name of the primary master name server for the movie.edu zone. The second name (al.robocop.movie.edu.) is the mail address of the person in charge of the zone if you replace the first "." with an "@". Often you'll see root, postmaster, or hostmaster as the email address. Name servers won't use this address -- it's meant for human consumption. If you have a problem with a zone, you can send a message to the listed email address. BIND 4.9 and later versions provide another resource record type, RP (responsible person), for this purpose also. The RP record is discussed in Chapter 7, "Maintaining BIND".

The parentheses allow the SOA record to span more than one line. Most of the fields within the parentheses of the SOA record are for use by slave name servers and are discussed when we introduce slave name servers later in this chapter. For now, assume these are reasonable values.

4.2.5. NS Records

The next entries we add to each file are NS (name server) resource records. We add one NS record for each name server authoritative for our zone. Here are the NS records from the db.movie.edu file:

movie.edu.  IN NS  terminator.movie.edu.
movie.edu.  IN NS  wormhole.movie.edu.

These records indicate that there are two name servers for the zone movie.edu. The name servers are on the hosts terminator.movie.edu and wormhole.movie.edu. Multihomed hosts, like wormhole.movie.edu, are excellent choices for name servers because they are "well-connected." They are directly accessible by hosts on more than one network and, if they also serve as routers, are not often down because they are closely monitored. We'll cover more on where to place your name servers in Chapter 8, "Growing Your Domain".

As with the SOA record, we add NS records to the db.192.249.249 and db.192.253.253 files, too.

4.2.6. Address and Alias Records

Next, we create the name-to-address mappings. We add the following resource records to the db.movie.edu file:

;
; Host addresses
;
localhost.movie.edu.  IN A     127.0.0.1
robocop.movie.edu.    IN A     192.249.249.2
terminator.movie.edu. IN A     192.249.249.3
diehard.movie.edu.    IN A     192.249.249.4
misery.movie.edu.     IN A     192.253.253.2
shining.movie.edu.    IN A     192.253.253.3
carrie.movie.edu.     IN A     192.253.253.4
;
; Multi-homed hosts
;
wormhole.movie.edu.   IN A     192.249.249.1
wormhole.movie.edu.   IN A     192.253.253.1
;
; Aliases
;
bigt.movie.edu.       IN CNAME terminator.movie.edu.
dh.movie.edu.         IN CNAME diehard.movie.edu.
wh.movie.edu.         IN CNAME wormhole.movie.edu.
wh249.movie.edu.      IN A     192.249.249.1
wh253.movie.edu.      IN A     192.253.253.1

The first two blocks are probably not a surprise. The A stands for address, and each resource record maps a name to an address. wormhole.movie.edu acts as a router. It has two addresses associated with its name and therefore two address records. Unlike host table lookups, a DNS lookup can return more than one address for a name; a lookup of wormhole.movie.edu returns two. If the requestor and name server are on the same network, some name servers place the "closest" address first in the response for better performance. This feature is called address sorting and is covered in Chapter 10, "Advanced Features". If address sorting does not apply, the addresses are rotated between queries so subsequent responses list them in a different order. This "round robin" feature first shows up in BIND 4.9.

The third block has the host table aliases. For the first three aliases, we created CNAME (canonical name) resource records. However, we created address records for the other two aliases (more on this in a moment). A CNAME record maps an alias to its canonical name. The name server handles CNAME records differently from the way aliases are handled in the host table. When a name server looks up a name and finds a CNAME record, it replaces the name with the canonical name and looks up the new name. For example, when the name server looks up wh.movie.edu, it finds a CNAME record pointing to wormhole.movie.edu. It then looks up wormhole.movie.edu and returns both addresses.

There is one thing to remember about aliases like bigt.movie.edu -- they should never appear on the right-hand side of a resource record. Stated differently, you should always use the canonical name (e.g., terminator.movie.edu) in the data portion of the resource record. Notice that the NS records we just created use the canonical name.

The final two entries solve a special problem. Suppose you have a router, like wormhole.movie.edu, and you want to check one of the interfaces. One common troubleshooting technique is to ping the interface to verify that it is responding. If you ping the name wormhole.movie.edu, the name server returns both addresses for the name. ping uses the first address in the list. But which address is first?

With the host table, we choose the address we want by using either wh249.movie.edu or wh253.movie.edu; each name referred to one of the host's addresses. To provide an equivalent capability with DNS, we don't make wh249.movie.edu and wh253.movie.edu into aliases (CNAME records). That would result in both addresses for wormhole.movie.edu being returned when the alias was looked up. Instead, we use address records. Now, to check the operation of the 192.253.253.1 interface on wormhole.movie.edu, we ping wh253.movie.edu since it refers to only one address. The same applies to wh249.movie.edu.

To state this as a general rule: if a host is multihomed (has more than one network interface), create an address (A) record for each alias unique to one address. Create a CNAME record for each alias common to all the addresses.

Now, don't tell your users about names like wh249.movie.edu and wh253.movie.edu. Those names are meant for system-administration purposes only. If users learn to use names like wh249.movie.edu, they'll be confused when the name doesn't work for them in some places, like .rhosts files. That's because these places need the name that results from looking up the address: the canonical name, wormhole.movie.edu.

Since we use A (address) records for the wh249.movie.edu and wh253.movie.edu aliases, you might ask, "Is it okay to use address records instead of CNAME records in all cases?" Well, using address records instead of CNAME records doesn't cause problems with most applications, since most applications care only about finding IP addresses. There is one application -- sendmail -- whose behavior changes, though. sendmail usually replaces aliases in mail headers with their canonical names; this canonicalization happens only if the names in the mail header have CNAME data associated with them. If you don't use CNAME records for aliases, your sendmail will have to understand all the possible aliases your host might be known by, which will require extra sendmail configuration on your part.

In addition to the problem with sendmail, users might be confused when they try to figure out the canonical name to enter in their .rhosts file. Looking up a name that has CNAME data leads them to the canonical name, whereas address data won't. In this case, users should instead be looking up the IP address to get the canonical name, as rlogind does, but users like these never seem to be on systems we administer.

4.2.7. PTR Records

Next we create the address-to-name mappings. The file db.192.249.249 maps addresses to host names for the 192.249.249/24 network. The DNS resource records used for this mapping are PTR (pointer) records. There is one record for each network interface on this network. (Recall that addresses are looked up as names in DNS. The address is reversed and in-addr.arpa is appended.)

Here are the PTR records we added for network 192.249.249/24:

1.249.249.192.in-addr.arpa.  IN PTR wormhole.movie.edu.
2.249.249.192.in-addr.arpa.  IN PTR robocop.movie.edu.
3.249.249.192.in-addr.arpa.  IN PTR terminator.movie.edu.
4.249.249.192.in-addr.arpa.  IN PTR diehard.movie.edu.

There are a couple of things you should notice about this data. First, addresses should point to only a single name: the canonical name. Thus, 192.249.249.1 maps to wormhole.movie.edu, not to wh249.movie.edu. You can create two PTR records, one for wormhole.movie.edu and one for wh249.movie.edu, but most systems are not prepared to see more than one name for an address. Second, even though wormhole.movie.edu has two addresses, you see only one of them here. That's because this file shows only the direct connections to network 192.249.249/24, and wormhole.movie.edu has only one connection there.

We created similar data for the 192.253.253/24 network.

4.2.8. The Completed Zone Data Files

Now that we've explained the various resource records in the zone data files, we'll show you what they look like with all the data in one place. Again, the actual order of these resource records does not matter.

Here are the contents of the file db.movie.edu:

$TTL 3h
movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 hour

;
; Name servers
;
movie.edu.  IN NS  terminator.movie.edu.
movie.edu.  IN NS  wormhole.movie.edu.

;
; Addresses for the canonical names
;
localhost.movie.edu.  IN A     127.0.0.1
robocop.movie.edu.    IN A     192.249.249.2
terminator.movie.edu. IN A     192.249.249.3
diehard.movie.edu.    IN A     192.249.249.4
misery.movie.edu.     IN A     192.253.253.2
shining.movie.edu.    IN A     192.253.253.3
carrie.movie.edu.     IN A     192.253.253.4
wormhole.movie.edu.   IN A     192.249.249.1
wormhole.movie.edu.   IN A     192.253.253.1

;
; Aliases
;
bigt.movie.edu.       IN CNAME terminator.movie.edu.
dh.movie.edu.         IN CNAME diehard.movie.edu.
wh.movie.edu.         IN CNAME wormhole.movie.edu.

;
; Interface specific names
;
wh249.movie.edu.      IN A     192.249.249.1
wh253.movie.edu.      IN A     192.253.253.1

Here are the contents of the file db.192.249.249 :

$TTL 3h
249.249.192.in-addr.arpa. IN SOA terminator.movie.edu. al.robocop.movie.edu.(
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 hour

;
; Name servers
;
249.249.192.in-addr.arpa.  IN NS  terminator.movie.edu.
249.249.192.in-addr.arpa.  IN NS  wormhole.movie.edu.

;
; Addresses point to canonical name
;
1.249.249.192.in-addr.arpa.  IN PTR wormhole.movie.edu.
2.249.249.192.in-addr.arpa.  IN PTR robocop.movie.edu.
3.249.249.192.in-addr.arpa.  IN PTR terminator.movie.edu.
4.249.249.192.in-addr.arpa.  IN PTR diehard.movie.edu.

And here are the contents of the file db.192.253.253:

$TTL 3h
253.253.192.in-addr.arpa. IN SOA terminator.movie.edu. al.robocop.movie.edu.(
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 hour
;
; Name servers
;
253.253.192.in-addr.arpa.  IN NS  terminator.movie.edu.
253.253.192.in-addr.arpa.  IN NS  wormhole.movie.edu.

;
; Addresses point to canonical name
;
1.253.253.192.in-addr.arpa.  IN PTR wormhole.movie.edu.
2.253.253.192.in-addr.arpa.  IN PTR misery.movie.edu.
3.253.253.192.in-addr.arpa.  IN PTR shining.movie.edu.
4.253.253.192.in-addr.arpa.  IN PTR carrie.movie.edu.

4.2.9. The Loopback Address

A name server needs one additional db.ADDR file to cover the loopback network: the special address that hosts use to direct traffic to themselves. This network is (almost) always 127.0.0/24, and the host number is (almost) always 127.0.0.1. Therefore, the name of this file is db.127.0.0. No surprise here; it looks like the other db.ADDR files.

Here are the contents of the file db.127.0.0 :

$TTL 3h
0.0.127.in-addr.arpa. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 hour

0.0.127.in-addr.arpa.  IN NS  terminator.movie.edu.
0.0.127.in-addr.arpa.  IN NS  wormhole.movie.edu.

1.0.0.127.in-addr.arpa.  IN PTR localhost.

Why do name servers need this silly little file? Think about it for a second. No one was given responsibility for network 127.0.0/24, yet systems use it for a loopback address. Since no one has direct responsibility, everyone who uses it is responsible for it individually. You could omit this file and your name server would operate. However, a lookup of 127.0.0.1 might fail because the root name server contacted wasn't itself configured to map 127.0.0.1 to a name. You should provide the mapping yourself so there are no surprises.

4.2.10. The Root Hints Data

Besides your local information, the name server also needs to know where the name servers for the root zone are. You must retrieve this information from the Internet host ftp.rs.internic.net (198.41.0.6). Use anonymous FTP to retrieve the file named.root from the domain subdirectory. (named.root is the same file we've been calling db.cache . Just rename it db.cache after you've retrieved it.)

;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC registration services
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.RS.INTERNIC.NET
;       -OR- under Gopher at    RS.INTERNIC.NET
;           under menu          InterNIC Registration Services (NSI)
;              submenu          InterNIC Registration Archives
;           file                named.root
;
;       last update:    Aug 22, 1997
;       related version of root zone:   1997082200
;
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;
; formerly C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; formerly NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;
; formerly NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
;
; temporarily housed at ISI (IANA)
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
;
; housed in Japan, operated by WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
; End of File

The domain name "." refers to the root zone. Since the root zone's name servers change over time, don't assume this list is current. Download a new version of named.root.

How is this file kept up to date? As the network administrator, that's your responsibility. Some old versions of BIND did update this file periodically. That feature was disabled, though; apparently, it didn't work as well as the authors had hoped. Sometimes the changed db.cache file is mailed to the bind-users or namedroppers mailing list. If you are on one of these lists, you are likely to hear about changes.

Can you put data other than root name server data in this file? You can, but it won't be used. Originally, the name server installed this data in its cache. However, the use of the file has changed (subtly) though the name "cache file" stuck. The name server stores the data in this file in a special place in memory as the root hints. It does not discard the hints if their TTLs drop to zero, as it would with cached data. The name server uses the hint data to query the root name servers for the current list of root name servers, which it caches. When the cached list of root name servers times out, the name server again uses the hints to get a new list.

Why does the name server bother querying a name server in the root hints file -- probably itself a root name server -- for a list of root name servers when it already has a list? Because that name server almost certainly knows the current list of root name servers, while the file may be out of date.

What are the 3600000s for? That's an explicit time to live for the records in the file. In older versions of this file, this number was 99999999. Since the contents of this file were originally cached, the name server needed to know how long to keep those records active. 99999999 seconds was just a very long time -- the root name server data was to be kept in cache for as long as the server ran. Since the name server now stores this data in a special place and doesn't discard it if it times out, the TTL is unnecessary. But it's not harmful to have the 3600000s, and it makes for interesting BIND folklore when you pass responsibility to the next name server administrator.