BIND Configuration Files

The BIND nameserver named server uses the /etc/named.conf file for configuration. All zone files are placed in the /var/named directory.

Warning Warning
 

Do not manually edit the /etc/named.conf file or any files in the /var/named directory if you are using the BIND Configuration Tool. Any manual changes to those files will be overwritten the next time the BIND Configuration Tool is used.

The /etc/named.conf file must be free of errors in order for named to start. While some erroneous options used in with some statements are not considered critical enough to stop the server, any errors in the statements themselves will prevent named from starting.

/etc/named.conf

The /etc/named.conf file is a collection of statements using nested options placed in ellipses { }. A sample /etc/named.conf file is organized similar to Figure 14-2.

<statement-1> ["<statement-1-name>"] [<statement-1-class>] {
   <option-1>;
   <option-2>;
   <option-N>;
};

<statement-2> ["<statement-2-name>"] [<statement-2-class>] {
   <option-1>;
   <option-2>;
   <option-N>;
};

<statement-N> ["<statement-N-name>"] [<statement-N-class>] {
   <option-1>;
   <option-2>;
   <option-N>;
};

Figure 14-2. Sample organization of /etc/named.conf

The "<statement-name>" is only needed with acl, include, server, view, and zone statements. The <statement-N-class> may only be specified with the zone statement.

Comments may be placed in /etc/named in nested C-style characters /* */ or after // and # characters.

The following statements may be used in /etc/named.conf:

Sample Zone Statements

Most changes to the /etc/named.conf file of a master or slave nameserver concerns adding, modifying, or deleting zone statements. While these zone statements can contain many options, most nameservers use few of them. The following zone statements are very basic examples that may be used in a master-slave nameserver relationship.

A zone statement on a primary nameserver hosting the domain domain.com may look like Figure 14-5.

zone "domain.com" IN {
  type master;
  file "domain.com.zone";
  allow-update { none; };
};

Figure 14-5. Example of a simple master zone statement

This zone statement names the zone domain.com, sets the type as master, tells named to read the /var/named/domain.com.zone file to configure the zone, and to allow no updates by any other hosts.

A slave server's zone statement for domain.com might look like Figure 14-6.

zone "domain.com" {
  type slave;
  file "domain.com.zone";
  masters { 192.168.0.1; };
};

Figure 14-6. Example of a simple slave zone statement

This zone statement tells named on the slave server to look to the 192.168.0.1 master server to find out the configuration information for the zone called domain.com. The information the slave server receives from the master server is saved in the /var/named/domain.com.zone file.

Zone Files

Zone files, which contain information about a particular namespace, are stored in the named working directory. By default, this is /var/named. Each zone file is named according to the file option data in the zone statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as example.com.zone.

Each zone file may contain directives and resource records. Directives tell the nameserver to do a certain thing or apply a special setting to the zone. Resource records define the parameters of the zone, assigning an identity within the zone's namespace to particular systems. Directives are optional, but resource records are required to provide nameservice to that zone. All directives and resource records should go on their own lines.

Comments can be placed after semicolon characters (;) in zone files.

Zone File Directives

Directives are identified by the leading $ character before the name of the directive and usually placed at the top of the zone file.

The following directives are the most commonly used:

  • $INCLUDE — Tells named to include another zone file in this zone file at the place where the directive is used. This allows additional zone settings to be stored apart from the main zone file.

  • $ORIGIN — Sets the domain name to be appended to any unqualified records, such as those that only specify the host and nothing more.

    For example, a zone file may contains the following line:

    $ORIGIN domain.com

    At this point, any names that are used in resource records and do not end in a trailing dot (.) will have this domain name added to them. So, in other words, when the zone record is read by the nameserver, the first line below will be interpreted as the second line:

    ftp               IN   CNAME   server1
    ftp.domain.com.   IN   CNAME   server1.domain.com.

    Note Note
     

    The use of the $ORIGIN directive is unnecessary if you name the zone in /etc/named.conf the same as the value you would assign to $ORIGIN. The zone's name is used as the $ORIGIN directive's value by default.

  • $TTL — Sets the default Time to Live (TTL) value for the zone. This is the number, in seconds, given to nameservers that tells how long the zone's resource records should continue to be valid. A resource record can contains its own TTL value, which would override this directive.

    Increasing this value tells remote nameservers to cache this zone's information for a longer time. This reduces the number of queries made concerning this zone, but it also lengthens the amount of time required to proliferate resource record changes.

Zone File Resource Records

Zone file resource records contain columns of data, separated by whitespace, that define the record. All zone file resource records are assigned a particular type, which designates the record's purpose. The following types of resource records are the most commonly used:

  • A — Address record, which specifies an IP address to assign to a name.

    <host>     IN     A     <IP-address>

    Figure 14-7. Sample A record configuration

    If the <host> value is omitted, then an A record points to a default IP address for the top of the namespace. This system will be the target of all non-FQDN requests.

    Consider the following A record examples for the domain.com zone file:

                 IN     A       10.0.1.3
    server1      IN     A       10.0.1.5

    Figure 14-8. Example A records

    Requests for domain.com are pointed to 10.0.1.3, while requests for server1.domain.com are pointed to 10.0.1.5.

  • CNAME — Canonical name record, which tells the nameserver that one name is also known as another.

    <alias-name>     IN     CNAME       <real-name>

    Figure 14-9. Sample CNAME record configuration

    In Figure 14-9, any requests sent to the <alias-name> will point to the host named <real-name>. CNAME records are most commonly used to point services that use a common naming scheme to the correct host.

    Consider the example in Figure 14-10, where an A record sets a particular hostname to an IP address and a CNAME record points the commonly used www hostname to it.

    server1      IN     A       10.0.1.5
    www          IN     CNAME   server1

    Figure 14-10. Example CNAME record

  • MX — Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.

          IN     MX     <preference-value>  <email-server-name>

    Figure 14-11. Sample MX record configuration

    In Figure 14-11, the <preference-value> allows you to numerically rank the email servers you would prefer to receive email for this namespace, giving preference to some email systems over others. The MX resource record with the lowest <preference-value> is preferred over the others, but you can set multiple email servers with the same value to distribute email traffic between them.

    The <email-server-name> may be a hostname or FQDN, as long as it points to the correct system.

          IN     MX     10     mail.domain.com.
          IN     MX     20     mail2.domain.com.

    Figure 14-12. Example MX records

    In this example, the first mail.domain.com email server is preferred to the mail2.domain.com email server when receiving email destined for the domain.com domain.

  • NS — NameServer record, which announces the authoritative nameservers for a particular zone.

          IN     NS     <nameserver-name>

    Figure 14-13. Sample NS record configuration

    The <nameserver-name> should be a FQDN.

    In Figure 14-14, two nameservers are listed as authoritative for a domain. It is not important whether these nameservers are slaves or if one is a master; they are both still considered authoritative.

          IN     NS     dns1.domain.com.
          IN     NS     dns2.domain.com.

    Figure 14-14. Example NS records

  • PTR — PoinTeR record, designed to point to another part of the namespace.

    PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. See the section called Reverse Name Resolution Zone Files for more examples of PTR records in use.

  • SOA — Start Of Authority record, proclaiming important authoritative information about the namespace to the nameserver.

    Located after the directives, an SOA record is the first resource record in a zone file.

    @     IN     SOA    <primary-name-server>     <hostmaster-email> (
                        <serial-number>
                        <time-to-refresh>
    		    <time-to-retry>
    		    <time-to-expire>
    		    <minimum-TTL> )

    Figure 14-15. Sample SOA record configuration

    The @ symbol places the $ORIGIN directive (or the zone's name, if the $ORIGIN directive is not set) as the namespace being defined by this SOA resource record. The primary nameserver that is authoritative for this domain is used for the <primary-name-server>, and the email of the person to contact about this namespace is substituted for the <hostmaster-email>.

    The <serial-number> is incremented every time you change the zone file so that named will know that it should reload this zone. The <time-to-refresh> tells any slave servers how long to wait before asking the master nameserver if any changes have been made to the zone. The <serial-number> value is used by the slave to determine if it is using outdated zone data and should refresh it.

    The <time-to-retry> tells the slave nameserver the interval to wait before issuing another refresh request, if the master nameserver is not answering. If the master has not replied to a refresh request before the <time-to-expire> elapses, the slave stops responding as an authority for requests concerning that namespace.

    The <minimum-TTL> requests that other nameservers cache the zone's information for at least this amount of time.

    With BIND, all times refer to seconds. However, you can also use abbreviations for other units of time other than seconds, such as minutes (M), hours (H), days (D), and weeks (W). The table in Table 14-1 shows an amount of time in seconds and the equivalent time in another format.

    Table 14-1. Seconds compared to other time units

    Seconds Other Time Units
    60 1M
    1800 30M
    3600 1H
    10800 3H
    21600 6H
    43200 12H
    86400 1D
    259200 3D
    604800 1W

    The following example demonstrates how a basic SOA resource record might look.

    @     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                        2001062501 ; serial
                        21600      ; refresh after 6 hours
                        3600       ; retry after 1 hour
                        604800     ; expire after 1 week
                        86400 )    ; minimum TTL of 1 day

    Figure 14-16. Example SOA records

Zone File Examples

Seen individually, the directives and resource records can be difficult to grasp. However, everything makes much more sense when it is placed together in a common file.

In Figure 14-17, a very basic zone file is shown.

$ORIGIN domain.com
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     dns1.domain.com.
      IN     NS     dns2.domain.com.

      IN     MX     10     mail.domain.com.
      IN     MX     20     mail2.domain.com.

             IN     A       10.0.1.5

server1      IN     A       10.0.1.5
server2      IN     A       10.0.1.7
dns1         IN     A       10.0.1.2
dns2         IN     A       10.0.1.3

ftp          IN     CNAME   server1
mail         IN     CNAME   server1
mail2        IN     CNAME   server2
www          IN     CNAME   server2

Figure 14-17. An example of a basic zone file

In this example, standard directives and SOA values are used. The authoritative nameservers are set to be dns1.domain.com and dns2.domain.com, which have A records that tie them to 10.0.1.2 and 10.0.1.3, respectively.

The email servers configured with the MX records point to server1 and server2 via CNAME records. Since the server1 and server2 names do not end in a trailing dot (.), the $ORIGIN domain is placed after them, expanding them to server1.domain.com and server2.domain.com. Through the related A resource records, their IP addresses can be determined.

The popular FTP and Web services, available at the standard ftp.domain.com and www.domain.com names, are pointed toward machines providing the appropriate services for those names using CNAME records.

Reverse Name Resolution Zone Files

A reverse name resolution zone file is used to translate an IP address in a particular namespace into a FQDN. It looks very similar to a standard zone file, except that PTR resource records are used to link the IP addresses to a certain system's name.

A PTR record is written in a manner similar to Figure 14-18.

<last-IP-digit>      IN     PTR    <FQDN-of-system>

Figure 14-18. Sample PTR record configuration

The <last-IP-digit> relates to the last number in an IP address that should point to a particular system's FQDN.

In Figure 14-19, IP addresses 10.0.1.20 through 10.0.1.25 are pointed to corresponding FQDNs.

$ORIGIN 1.0.10.in-addr.arpa
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     dns1.domain.com.
      IN     NS     dns2.domain.com.

20    IN     PTR    alice.domain.com.
21    IN     PTR    betty.domain.com.
22    IN     PTR    charlie.domain.com.
23    IN     PTR    doug.domain.com.
24    IN     PTR    ernest.domain.com.
25    IN     PTR    fanny.domain.com.

Figure 14-19. An example of a basic reverse zone resolution file

This zone file would be called into service with a zone statement in the /etc/named.conf file that looks similar to Figure 14-20.

zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "domain.com.rr.zone";
  allow-update { none; };
};

Figure 14-20. An example of a reverse resolution zone statement

There is very little difference between this example an a standard zone statement, except for how the zone is named. Note that a reverse name resolution zone requires the first three blocks of the IP address to be reversed and ".in-addr.arpa" to be included after them. This allows the single block of IP numbers used in the reverse name resolution zone file to be correctly attached with this zone.