The zone file is where the mappings for hostnames to IP addresses within a domain or zone are defined; it's also where the most mistakes are commonly made in a BIND configuration, so we will cover it in detail. The format of a zone file (often referred to as a master zone file or simply master file) is quite complex and regimented, although there are certain things you can get away with. A "living" zone file in an existing BIND setup can be all but incomprehensible. It helps to understand what kinds of primitives (directives) are allowed and how each one is specified, as well as the shortcuts that are allowed and commonly used. First, consider the sample zone file, and its components, shown in Listing 32.2. Note that semicolons (;) are the comment characters in zone files. Listing 32.2. A Sample Zone File for the example.com Domain
Although it may look as though this is an unformatted mess, there is in fact a distinct structure to it. Listing 32.2 consists of six basic elements:
Aside from the directives, each element of the file is a resource record (RR), defining the properties of a name within the zone relative to a certain "origin." The following sections look at each of these elements in turn. Start of Authority (SOA) RecordsFollowing the basic directives that might appear at the top of the file (such as $TTL, which specifies a default time-to-live value), we come to the first resource record in a zone file: the Start of Authority (SOA) record. This is the most important part of a zone file, and the most commonly botched. Many mistakes are the result of the counterintuitive style of the SOA record's format. To understand this record, you need to look at it piece by piece. Here's the sample SOA record from Listing 32.2: example.com. IN SOA stripes.example.com. root.example.com. ( 2001061000 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL The SOA, like all records, has the following basic form: name [ttl] [class] type value If name is not absolute, the current contents of the $ORIGIN directive (which starts out with the same value as the corresponding zone statement in the named.conf file) are appended. In this case, the name is absolute (it ends with a dot). The ttl field is omitted because the sample file has a global $TTL directive specifying it. IN (for "Internet") is the class; BIND supports other kinds of classes, but we're not interested in them here. If in was specified in the zone statement in named.conf, this field is redundant and can be omitted. The value field for most records is quite simple: an IP address, a hostname, or some symbolic name. For the SOA record, though, it's much more complex. It begins, first of all, with the name of the authoritative name server for the zone (stripes.example.com). The next piece of information is the email address of the administrator of the domain, with the @ sign replaced by a dot. It also has a trailing dot at the end. In our example, the administrator (root@example.com) is specified as root.example.com., which will be used by BIND to mail status notifications to the responsible party. Note The reason for the @ sign in the administrator email address being replaced with a dot is that the @ symbol, in a zone file, has a special meaning. It's shorthand for the current value of the $ORIGIN directive and will be expanded by BIND into a fully qualified domain name. Note that the @ symbol must be the complete key if you use it; it can't be expanded implicitly, as in www.@ or some similar construct. Following the administrator address is a parenthesized block of settings; the parentheses specify a block in which line breaks are ignored, so you can format the values for better clarity. These are the numbers that define how the zone data will behave on the Internet:
Name Server (NS) RecordsListing 32.2 showed the following sample Name Server (NS) records: ; DNS Servers @ IN NS stripes.example.com. @ IN NS spots.example.com. These records specify the DNS servers that are allowed to give authoritative answers to queries about the zone. Note that the @ symbol refers to the current $ORIGIN (which, in this case, is example.com.) and that both server names have trailing dots (indicating that they are absolute). You can create NS records for subdomains, or zones within the current zone. For instance, suppose you have a cluster of machines within a zone called cluster.example.com., with their DNS information handled by their own name server (ns.cluster.example.com). A valid NS record for that server, allowing external hosts to query it for the cluster's IP addresses, would be cluster IN NS ns.cluster.example.com. Recall that by leaving the trailing dot off of cluster, the current $ORIGIN (example.com.) is appended to it by BIND. Address (A) RecordsThe Address (A) record is what you use to associate a hostname with an IP address. Our example had the following records: ; Machine Names localhost IN A 127.0.0.1 stripes IN A 64.41.131.162 spots IN A 64.41.131.163 mail IN A 64.41.131.167 @ IN A 64.41.131.162 The meaning of these records is fairly straightforward. The unqualified names on the left-hand side are expanded with the current $ORIGIN. Therefore, mail.example.com would resolve to 64.41.131.167. Similarly, the @ symbol expands so that a query for example.com would return 64.41.131.162. Names that are defined in A records are known as canonical names, as opposed to aliases (which are defined by CNAME records). Canonical Name (CNAME) RecordsCanonical Name (CNAME) records are used to create aliases. The terminology is such that in our example from Listing 32.2, the alias name www (which expands with $ORIGIN to www.example.com.) points to the canonical name @, or example.com. (whose IP address is defined in the A block): ; Aliases www IN CNAME @ ftp IN CNAME www.example.com. Note It's critical to remember that the trailing dot at the end of a hostname indicates that the name is absolute (fully qualified). If the dot is omitted, the value of $ORIGIN is appended automatically. If you find your programs looking for hosts with names like www.example.com.example.com, you know that a potential culprit is a DNS configuration where a hostname has been left unqualified and needs to have a dot added. CNAME records are often useful in that they are not immediately bound to an IP address. You can use CNAME records to point to names in another zone, for example, which can then be controlled by the owner of that zone. Also, CNAME records are helpful in reducing the number of changes that must be made in a zone file if an IP address changes. Mail Exchanger (MX) RecordsMail Exchanger (MX) records define which hosts are to be used for mail delivery to addresses in the zone. Sendmail (and other MTAs) look up the most preferred MX record within a zone and open a connection to it; you can find out the MX hosts for a domain with the host command: # host somecompany.com somecompany.com has address 207.114.98.18 somecompany.com mail is handled (pri=100) by mail.uu.net somecompany.com mail is handled (pri=5) by mx-1.somecompany.com Each MX record has a "priority" number associated with it, and mail servers for a domain are tried from lowest to highest numerical value until a successful SMTP connection can be made. The priority is specified as part of the value field in the record, as in this example, which sets the priority to 10: ; MX Record @ IN MX 10 mail.example.com. Caution An MX record cannot point to an IP addressyou must supply a name. Also, many MTAs and mail clients will complain if they detect an MX record that points to a CNAME. Make sure your MX records point to defined names specified elsewhere with A records! Pointer (PTR) RecordsPointer (PTR) records are the reverse of A or CNAME records and are used in reverse DNS zone files (for example, 131.41.64.in-addr.arpa) to map IP addresses to domain names. (An example of a reverse DNS zone file is shown in Listing 32.3.) It's possible to specify more than one PTR record for a given IP address, a configuration practice that's increasingly in use for purposes such as spam control. However, because a reverse DNS lookup only returns a single name, many administrators only attach a single PTR record to a given IP address even if many hostnames resolve to that address; this means that reverse files are often shorter than their forward counterparts. Reverse DNS Zone FilesA reverse DNS zone file, defining a zone of the form 131.41.64.in-addr.arpa, is used to map IP addresses to names. Files of this sort are referenced in named.conf and propagated to slave servers just like forward DNS zone files. Listing 32.3 shows a sample reverse DNS zone file. Listing 32.3. A Sample Reverse DNS Zone File for the 131.41.64.in-addr.arpa Zone
Note the use of PTR records instead of A or CNAME records. The name that each PTR points to is the true canonical name for that IP address. There is also no need for an MX record in a reverse file because MX records cannot be associated with IP addresses in the first place. Making a localhost Zone FileA special zone file must exist for the localhost zone (0.0.127.in-addr.arpa) to work properly. There's a shell script in /etc/namedb to help you create one. The script is called make-localhost, and it reads in a template (PROTO.localhost.rev) and fills in information that it derives from your input. Because it isn't set executable, you must run it with the sh command: # sh make-localhost Enter your domain name: example.com The resulting file, /etc/namedb/master/localhost.rev, should look something like Listing 32.4. Listing 32.4. Autogenerated localhost.rev Zone File
Make sure to create this file before fully deploying your DNS service! |