| If you've created the /etc/named.conf file and set it up with global options and zones for your domain, you might be anxious to start up the server. Unless your server is a slave to another system, though, your configuration task isn't yet done. When you set up a master zone, as described earlier, you tell BIND to read a zone-specific configuration file. It's in this file that you store information on the hostnames and IP addresses for the zone. On a large name server, creating and maintaining these zone files is the bulk of the administrative work. If your domain is small and static, you may be able to set up a few zone files and then ignore them. A Sample Zone Configuration File Listing 18.2 shows a sample zone configuration file. This file begins with the name of the zone ( threeroomco.com . ) and a section that defines many defaults for the domain. These defaults are described in more detail in the next section, "Setting Master Zone Options." Following this section are a series of lines that provide information on the mapping between specific computer names and their IP addresses. Some of these actually apply to the entire domain. The upcoming section, "Specifying Addresses and Aliases," describes these lines. WARNING  | Technically, DNS hostnames all end in periods ( . ). When you enter a hostname without a period in a Web browser, FTP client, e-mail client, or the like, Linux first interprets the address as being one that's missing its domain, so Linux tries adding the default and search domain names, as specified in /etc/resolv.conf . When this lookup fails, Linux tries again by appending a single period to the domain name. This process is transparent in normal operation, but when configuring DNS, you can't afford to be sloppy . You must specify all hostnames as either fully-qualified domain names (FQDNs) with the trailing period or as hostnames only without the associated domain. If you provide an FQDN without the period, BIND will try to add the period, resulting in an effective doubling of the domain portion of the name, such as gingko.threeroomco.com.threeroomco.com . |
Listing 18.2 A sample zone configuration file threeroomco.com. IN SOA spruce.threeroomco.com. \ admin.threeroomco.com. ( 2002043004 ; serial 3600 ; refresh 600 ; retry 604800 ; expire 86400 ; default_ttl ) gingko.threeroomco.com. IN A 192.168.1.1 birch IN A 192.168.1.2 spruce IN A 192.168.1.3 threeroomco.com. IN A 192.168.1.4 www IN CNAME gingko kelp IN CNAME jacques.pangaea.edu. @ IN MX 10 birch.threeroomco.com. @ IN MX 20 mail.pangaea.edu. @ IN NS spruce.threeroomco.com. The general format for lines in a zone file is as follows : name IN record-type record-contents In such an entry, name is the computer's name, or a pseudo-name associated with an address in the case of a reverse DNS zone, as described in the upcoming section, "Configuring a Reverse DNS Zone." IN is a code that refers to a particular class of entry. It stands for Internet. There are other classes you can use in place of IN in some circumstances, but this chapter doesn't cover such configurations. The record-type is a code that stands for the type of record you're defining, such as a normal forward DNS entry, a reverse DNS entry, or an entry to specify a mail server. Finally, record-contents is one or more strings that go into defining the record, such as an IP address or hostname. In the case of the master options, record-contents is an entry that typically spans several lines. For most other records, the entire entry fits on a single line. A semicolon ( ; ) is a comment indicator; any text after a semicolon on a line is ignored. WARNING | | BIND's configuration files are inconsistent in their use of semicolons. In named.conf , a semicolon indicates the end of a configuration statement. In zone files, the semicolon indicates the start of a comment. Keep this important difference in mind when editing your configuration files. If you become confused and use the semicolons incorrectly, chances are BIND won't start, or will behave strangely. |
The entire zone configuration file is usually stored in /var/named and is given a name that's related to the zone name. Typically, the name is db . zone-name or named . zone-name , where zone-name is the name of the zone. You can call your zone files anything you like, though. The important thing is that you refer to them by their true names in /etc/named.conf . Setting Master Zone Options The master zone options appear in the start of authority (SOA) record, which has a record-type of SOA . The presence of this record indicates that the name server is authoritative for this domain. The name for this record is the zone name, as specified in /etc/named.conf ”but remember to include a trailing period, as shown in Listing 18.2! The record-contents for this entry consists of three parts : -
Master name server ” The first name ( spruce.threeroomco.com . in Listing 18.2) is the name of the master name server for the zone. This name is followed by a backslash ( \ ) in Listing 18.2. As in many configuration files, this is a line continuation character, so the second physical line in Listing 18.2 is interpreted as if it were part of the first line. Many zone files actually use a single long line instead of two lines separated by a backslash. -
Administrative e-mail address ” The second name ( admin.threeroomco.com . in Listing 18.2) is the e-mail address of the person responsible for maintaining this zone. The address form is somewhat unusual, though; to use it, you must replace the first period with an at-sign ( @ ), so Listing 18.2's administrator is admin@threeroomco.com . -
Timing information ” The numbers that span several lines, and that are surrounded by parentheses, provide timing information. These lines are commented in Listing 18.2 to indicate their purpose. The serial line is a serial number that should increase whenever you edit the zone file; slave servers use this number to determine whether or not to update their configuration files. Many administrators use the date (in YYYYMMDD format), followed by a number for the change number within a day, as the serial number. The refresh line is the time, in seconds, between checks made by the slave for updated zone files from the master. The 3600 value in Listing 18.2 translates to one hour, so the slaves will be updated within an hour of a change in the master's files. The retry value is the interval, in seconds, at which a slave will attempt another transfer if the first one failed; it's normally shorter than the refresh time. The expire value is the length of time, again in seconds, that a slave will wait before it discards a zone entirely because it can't reach the master. This value is normally at least a week, and it should always be longer than the refresh interval. Finally, the default_ttl entry sets the time to live (TTL) value for records. This is the length of time that remote DNS servers should keep information on individual lookups. Typical values range from a day ( 86400 , as in Listing 18.2) to about a week ( 604800 ). If IP addresses on your network change frequently, or if you expect to implement changes soon, setting a TTL value of an hour or so ( 3600 ) may be worthwhile. Specifying Addresses and Aliases Most of the lines in a zone file provide information linking IP addresses to hostnames, either directly or indirectly. In most cases, the name field is the name of an individual computer or a name associated with an IP address, as described shortly. It is possible, however, to use the at-sign ( @ ) as a stand-in for the domain name. You might use this feature in conjunction with the MX and NS records, as shown in Listing 18.2 and described in more detail shortly. Such records don't set up linkages between specific hostnames and IP addresses, but rather attach specific hostnames to take on specific duties for the domain as a whole. The most common record types are as follows: -
A ” An address (A) record uses a hostname as the name and provides an IP address as the record-contents . You can specify the hostname either as an FQDN with a trailing period, as in gingko.threeroomco.com . in Listing 18.2, or as a hostname without its domain or a trailing period, as in birch and spruce in Listing 18.2. It's also possible to assign a computer to use the domain name alone as its hostname, as in threeroomco.com . (192.168.1.4) in Listing 18.2. Such a configuration doesn't prevent you from using other names within the domain. -
CNAME ” Canonical name (CNAME) records link one hostname to another one. As with A records, the record-contents may be specified as either an FQDN with a trailing period or as a hostname without a domain. In the former case, the target domain need not be in the same domain as the zone that the file defines; for instance, kelp in Listing 18.2 points to a machine in another domain entirely. CNAMES in general are useful if an important system's IP address isn't directly under your control. For instance, if you use a Web hosting service, you might want to link the www address to that outside computer using a CNAME entry, so that www will continue to work even if your hosting service changes the IP address of its hosting machine. -
PTR ” Listing 18.2 contains no pointer (PTR) records. These records appear in the zone files for reverse DNS zones. They're discussed in the upcoming section, "Configuring a Reverse DNS Zone." -
NS ” Name server (NS) records specify the name servers for a domain. Normally, at least one NS record will point to the same computer as was listed as the master name server in the SOA record. The name of an NS record is normally either @ or your domain name alone, and the record-contents field usually lists an A record that defines a name server. -
MX ” Finally, a mail exchanger (MX) record provides information on a mail server for the zone. This entry uses either @ or the domain name alone as the name . The record-contents field has two components : a priority code and a hostname. When a mail server needs to send mail addressed to a user at the domain (such as lorax@threeroomco.com ), the remote server asks your name server for its MX records. The remote server then tries to contact the system with the lowest priority code ” birch.threeroomco.com in the case of Listing 18.2. If that system is down, the remote mail server tries the system with the next-higher priority code (such as mail.pangaea.edu . in Listing 18.2), and so on until the message is delivered or all the mail servers have failed. Of course, the mail server system must be configured to accept mail addressed to users at the domain, instead of or in addition to mail addressed to users of the specific computer. This is discussed in Chapter 19, Push Mail Protocol: SMTP. TIP  | Many record types can point to computers that reside outside of your own domain. This can be particularly helpful for CNAME records, as discussed earlier, as well as for NS and MX records if you rely upon an outside source for some or all of your DNS or mail server functions. |
Listing 18.2 shows most of these record types in action. A real domain is likely to provide information on many more computers than does Listing 18.2, though. Configuring a Reverse DNS Zone Listing 18.1 shows several zones, two of which are for reverse DNS entries. These zones allow the DNS server to retrieve hostnames when given IP addresses. The trick to this operation is the creation of a pseudo-domain, in-addr.arpa . Your /etc/named.conf file points BIND to zone files that are authoritative for certain subsets of this domain. Because the least significant element of a domain name is at the extreme left of the name, whereas the least significant element of an IP address is at the extreme right of the address, you enter the IP address as part of this pseudo-domain backward. Thus, the zone name for the 192.168.1.0/24 address is 1.168.192.in-addr. arpa . WARNING | | You can run a DNS server for your own domain after registering that domain (or even using a fake domain name, if your network is private). You should not attempt to run a reverse DNS service on an IP block unless you're in charge of that block. You're unlikely to cause problems for others if you do this accidentally , but if you set it up incorrectly, you might break reverse lookups from your own network. There are two exceptions to this rule: First, the localhost address block (127.0.0/24, or even 127/8) may be configured locally, and if you run a private network, you should set up a reverse DNS zone for the private IP address space you've used. |
A reverse DNS zone is configured just like a forward DNS zone, except that PTR records dominate the reverse DNS zone. (A reverse DNS zone also includes an SOA record, and often NS records.) There's no need to define MX records, A records, or CNAME records in most reverse DNS zone files. Listing 18.3 shows a reverse DNS zone file to match the forward DNS zone file shown in Listing 18.2. Listing 18.3 A reverse DNS zone file 1.168.192.in-addr.arpa. IN SOA spruce.threeroomco.com. \ admin.threeroomco.com. ( 2002043004 ; serial 3600 ; refresh 600 ; retry 604800 ; expire 86400 ; default_ttl ) 1 IN PTR gingko.threeroomco.com. 2.1.168.192.in-addr.arpa. IN PTR birch.threeroomco.com. 3.1.168.192.in-addr.arpa. IN PTR spruce.threeroomco.com. 4.1.168.192.in-addr.arpa. IN PTR threeroomco.com. @ IN NS spruce.threeroomco.com. You can specify the name using either a short name ”in this case, normally just the host portion of the IP address, such as 1 for 192.168.1.1 ”or the complete (but reverse-order) IP address followed by in-addr.arpa . Listing 18.3 illustrates both approaches. The record-contents field should always contain the complete hostname, including a trailing period. Because this zone is not the same as the forward zone, an attempt to abbreviate the name will result in incorrect lookups, such as birch.1.168.192. in-addr.arpa , rather than birch.threeroomco.com . |
