Creating a Zone File


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

$TTL 3600     example.com. IN SOA stripes.example.com. root.example.com. (                             20050610        ; Serial                             10800           ; Refresh                             3600            ; Retry                             604800          ; Expire                             86400 )         ; Minimum TTL     ; DNS Servers     @       IN NS           stripes.example.com.     @       IN NS           spots.example.com.     ; Machine Names     localhost       IN A    127.0.0.1     ns1             IN A    64.41.131.162     ns2             IN A    64.41.131.163     mail            IN A    64.41.131.167     @               IN A    64.41.131.162     ; Aliases     www             IN CNAME        @     ftp             IN CNAME        www.example.com.     ; MX Record     @               IN MX   10      mail.example.com.

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:

  • A $TTL directive

  • The SOA (Start of Authority) record

  • A block of NS (Name Server) records

  • A block of A (Address) records

  • A block of CNAME (Canonical Name) records, which define aliases

  • An MX (Mail Exchanger) record

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) Records

Following 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:

  • Serial Number The serial number is the way BIND keeps track of how recent a zone file is. Each time you update the zone file, you must increment the number so that BIND knows to refresh its information from the file. Standard practice is to use the format YYYYMMDDNN for this number; the final two digits are for revisions within a day. Update the number to reflect the current day when you make a change.

    Note

    When you use ndc reload to refresh a master zone file's information, BIND will automatically determine that the data needs to be refreshed, regardless of the serial number. However, keeping the serial number accurate is a good habit to be in; it will ensure proper operation in cases such as manually refreshing slave zone data.


  • Refresh This number, in seconds, specifies how frequently slave servers should check the master for updated zone data. If the master's serial number has changed since the last zone transfer, a new zone transfer will be performed.

  • Retry If the master server cannot be contacted, the slaves will retry at intervals specified by this number (in seconds).

  • Expire If the master server cannot be contacted within this time (in seconds), the slave servers discard all their data for the zone.

  • Minimum TTL This number (in seconds) specifies how long "negative cache" responses (which indicate the absence of a piece of data) should be kept.

Name Server (NS) Records

Listing 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) Records

The 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) Records

Canonical 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) Records

Mail 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) Records

Pointer (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 Files

A 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

   $TTL 3600    131.41.64.in-addr.arpa. IN SOA stripes.example.com. root.example.com. (                            2005061000      ; Serial                            10800           ; Refresh                            3600            ; Retry                            604800          ; Expire                            86400 )         ; Minimum TTL    @     IN NS     stripes.example.com.    @     IN NS     spots.example.com.    162   IN PTR    stripes.example.com.    163   IN PTR    spots.example.com.    167   IN PTR    mail.example.com.

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 File

A 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

;       From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90 ; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $ ; ; This file is automatically edited by the `make-localhost' script in ; the /etc/namedb directory. ; $TTL    3600 @       IN     SOA     stripes.example.com. root.stripes.example.com. (                                20050612        ; Serial                                3600    ; Refresh                                900     ; Retry                                3600000 ; Expire                                3600 )  ; Minimum         IN     NS      stripes.example.com. 1       IN     PTR     localhost.example.com.

Make sure to create this file before fully deploying your DNS service!




FreeBSD 6 Unleashed
FreeBSD 6 Unleashed
ISBN: 0672328755
EAN: 2147483647
Year: 2006
Pages: 355
Authors: Brian Tiemann

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net