 | Chapter 4 Setting Up BIND |  |
| Chapter 4 Setting Up BIND | |
Our first step in setting up the Movie U. name servers is to translate the host table into equivalent DNS 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 address-to-name lookup is sometimes called reverse mapping. Each network has its own file for the reverse mapping.
As a convention in this book, a file mapping host names to addresses is called db.DOMAIN. In movie.edu, this file is db.movie. The files mapping addresses to host names are called db.ADDR, where ADDR is the network number without the trailing zeros. In our example, the files are db.192.249.249 and db.192.253.253; there's one for each network. The db is short for database. We'll call the collection of db.DOMAIN and db.ADDR files db files or DNS database files. There are a couple of other 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 db files together, a name server needs a startup file - for BIND version 4, this file is usually /etc/named.boot. For BIND version 8, this file is usually /etc/named.conf. The db files are DNS-specific. The startup file is specific to the name server implementation - in this case, BIND.
Most entries in db files are called DNS resource records. DNS lookups are case-insensitive, so you can enter names in your db files in uppercase, lowercase, or mixed case. We tend to use all lowercase. Even though lookups are case-insensitive, case is preserved.
Resource records must start in column one. The resource records in the example files we present in this book do start in column one, but they may look indented because of the way this book is formatted. In the DNS RFCs, the examples present the resource records in a certain order. Most people have chosen to follow that ordering, as we have here, but this ordering is not a requirement. The ordering of resource records in the db files is as follows:
Indicates authority for this zone data
Lists a name server for this zone
Data about hosts in this zone
Of the other records, this chapter covers:
Those of you who have some experience with the DNS file format will look, no doubt, at our data and say to yourselves, "It would have been shorter to specify it this other way...." We are not using abbreviations or shortcuts in our data, at least not initially. Once you understand the long version, we'll go back and "tighten up" the files.
The db 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.
The first entry 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 db file.
We added the following SOA record to the db.movie file:
movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
1 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 dayThe name movie.edu. must start in column one of the file. Make sure the names end with a trailing dot, as we have done here, or you will 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 are currently in widespread use. Our examples use only the IN class. The class field is optional. If the class is omitted, the class IN is assumed.
The first name after SOA (terminator.movie.edu.) is the name of the primary master name server for this data. The second name (al.robocop.movie.edu.) is the mail address of the person in charge of the data (if you replace the first "." with an "@"). Often you'll see root, postmaster, or hostmaster as the email address. Name servers won't use these names - they are meant for human consumption. If you have a problem with someone's domain, you can send an email 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.
We added similar SOA records to the beginning of the db.192.249.249 and db.192.253.253 files. In these files, we changed the first name in the SOA record from movie.edu. to the name of the appropriate in-addr.arpa domain: 249.249.192.in-addr.arpa. and 253.253.192.in-addr.arpa., respectively.
The next entries we added to each file are NS (name server) resource records. We added one NS record for each name server for our zone. Here are the NS records from the db.movie 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 and wormhole. Multihomed hosts, like wormhole, are excellent choices for name servers since they are "well-connected." They are directly accessible by hosts on more than one network and, if they also serve as routers, they 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 added NS records to the db.192.249.249 and db.192.253.253 files.
Next, we created the name-to-address mappings. We added the following resource records to the db.movie 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 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 will return two. If the requestor and name server are on the same network, some name servers will 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 and Security. 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 shows up first 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 in a different manner than 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, it finds a CNAME record pointing to wormhole. wormhole is then looked up, and both addresses are returned.
There is one thing you need to remember about aliases like bigt - they should never appear on the right-hand side of a resource record. Stated differently: always use the canonical name (terminator) 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, 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, the name server returns both addresses when the name is looked up. ping uses the first address in the list. But which address is first?
With the host table, we chose the address we wanted by using either wh249 or wh253 - each name referred to one of the host's addresses. To provide equivalent capability with DNS, we didn't make wh249 and wh253 into aliases (CNAME records). That would result in both addresses for wormhole being returned when the alias was looked up. Instead, we used address records. Now, to check the operation of the 192.253.253.1 interface on wormhole, we ping wh253 since it refers to only one address. The same applies to wh249.
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 and wh253. Those names are meant for system-administration purposes only. If users learn to use names like wh249, they will be confused when the name doesn't work for them in some places, like .rhosts files. That's because these places want the name that results from looking up the address, and that name is going to be the canonical name, wormhole.
Since we used A (address) records for the wh249 and wh253 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 the application only cares that it finds the IP address. There is one application - sendmail - whose behavior changes, though. sendmail usually replaces aliases in mail headers with their canonical name; this canonicalization only happens if the name in the mail header has CNAME data associated with it. Without CNAME records for aliases, your sendmail will have to understand all of the possible aliases your host might be known by, which will require extra sendmail configuration work 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.
Next we created the address-to-name mappings. The file db.192.249.249 maps addresses to host names for the 192.249.249 network. The DNS resource records used for this mapping are PTR (pointer) records. There is one record for each host 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:
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 to notice about this data. First, addresses should only point to a single name: the canonical name. Thus, 192.249.249.1 maps to wormhole and not to wh249. You can create two PTR records, one for wormhole and one for wh249, but most systems are not prepared to see more than one name for an address. Second, even though wormhole has two addresses, you only see one of them here. That's because this file shows only the direct connections to network 192.249.249, and wormhole has only one connection there.
We created similar data for the 192.253.253 network.
Now that the various resource records of the db files have been explained, we'll show you what they look like when all the data are in one place. Again, the actual order of these resource records does not matter.
Here are the contents of the file db.movie:
movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
1 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
;
; 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.1Here are the contents of the file db.192.249.249:
249.249.192.in-addr.arpa. IN SOA terminator.movie.edu. al.robocop.movie.edu.(
1 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
;
; 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.Here are the contents of the file db.192.253.253:
253.253.192.in-addr.arpa. IN SOA terminator.movie.edu. al.robocop.movie.edu.(
1 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
;
; 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.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, 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:
0.0.127.in-addr.arpa. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
1 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
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, 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 configured itself to map 127.0.0.1 to a name. You ought to provide the mapping yourself so there are no surprises.
Besides your local information, the name server also needs to know where the name servers are for the root domain. This information must be retrieved from the Internet host ftp.rs.internic.net (198.41.0.7). 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 named.root to 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 domain. Since the root domain's name servers change over time, don't assume this list is current. Pull a new version of named.root.
How is this file kept up to date? As the network administrator, you must keep it up to date. Some versions of BIND did update this file periodically. That feature was disabled: 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 cache file has changed (subtly) to be the root name server hints (but the name "cache file" stuck). The name server stores the hints data in a special place and does not discard the hints if their TTLs drop to zero, as it would with cache 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.
What are the 3600000s for? In older versions
of this file, this number used to be 99999999.
Since this file was originally cache data, the name server needed to
know how long to keep these records active. The
99999999s meant a very long time. The root name
server data was to be kept active 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.
|  | |
| 4.1 Our Domain |  | 4.3 Setting Up a BIND Configuration File |