The BIND 9 server statement syntax varies slightly. It is:

server address {
  [ bogus yes|no; ]
  [ provide-ixfr yes|no; ]
  [ request-ixfr yes|no; ]
  [ transfers number; ]
  [ transfer-format one-answer|many-answers; ]
  [ keys { key_id [key_id ... ] }; ]
};

All of the fields are the same as BIND 8, with the exception that support-ixfr has been replaced by two options:

The BIND 9 syntax of the options command is:

options {
  [ version string; ]
  [ directory pathname; ]
  [ additional-from-auth yes|no; ] 
  [ additional-from-cache yes|no; ]
  [ dump-file pathname; ]
  [ pid-file pathname; ]
  [ statistics-file pathname; ]
  [ auth-nxdomain yes|no; ]
  [ dialup yes|no; ]
  [ notify yes|no|explicit; ] 
  [ notify-source [ip_addr|*] [port ip_port] ; ]
  [ notify-source-v6 [ip_addr|*] [port ip_port] ; ]
  [ recursion yes|no; ]
  [ recursive-clients number; ] 
  [ tcp-clients number; ]
  [ also-notify { address-list; };
  [ forward only|first; ]
  [ forwarders { address-list; }; ]
  [ allow-notify { address_match_list }; ]
  [ allow-query { address_match_list }; ]
  [ allow-transfer { address_match_list }; ]
  [ allow-recursion { address_match_list }; ]
  [ blackhole { address_match_list }; ]
  [ listen-on [ port ip_port ] { address_match_list }; ] 
  [ listen-on-v6 [ port ip_port ] { address_match_list }; ]
  [ port ip_port; ]
  [ query-source [address ip_addr|*] [port ip_port|*] ; ] 
  [ query-source-v6 [address ip6_addr|*] [port ip_port|*] ; ]
  [ lame-ttl number; ]
  [ max-transfer-time-in number; ] 
  [ max-transfer-time-out number; ] 
  [ max-transfer-idle-in number; ] 
  [ max-transfer-idle-out number; ] 
  [ max-refresh-time number; ] 
  [ max-retry-time number; ] 
  [ max-cache-ttl number; ]
  [ max-ncache-ttl number; ]
  [ min-refresh-time number; ] 
  [ min-retry-time number; ]
  [ transfer-format one-answer|many-answers; ]
  [ transfers-in  number; ]
  [ transfers-out number; ]
  [ transfers-per-ns number; ]
  [ transfer-source ip_addr|*] [port ip_port|*]; ] 
  [ transfer-source-v6 ip6_addr|*] [port ip_port|*]; ]
  [ coresize size; ]
  [ datasize size; ]
  [ files size; ]
  [ stacksize size; ]
  [ cleaning-interval number; ]
  [ heartbeat-interval number; ]
  [ interface-interval number; ]
  [ sortlist { address_match_list }; ]
  [ sig-validity-interval number; ]
  [ tkey-dhkey key_name 
                  key_tag; ]
  [ tkey-domain domain; ]
  [ zone-statistics yes|no; ]
};

Many BIND 9 options are the same as those used for BIND 8 and perform exactly the same functions. A few options have been added to BIND 9 to handle IPv6, which is an integral part of BIND 9. These options, listen-on-v6, notify-source-v6, query-source-v6, and transfer-source-v6, perform exactly the same functions as the like-named options do for IPv4. Many BIND 8 options are no longer needed because important functions have been incorporated into the new BIND 9 code. However, the list of options is no shorter because many new options have been added:

Options change over time. Check the documentation that comes with the BIND 9 distribution for the latest list of options.

The BIND 9 syntax of the logging command is:

logging {
  [ channel channel_name {
     file pathname
       [ versions number|unlimited ]
       [ size size ]
    |syslog kern|user|mail|daemon|auth|syslog|lpr
                |news|uucp|cron|authpriv|ftp
                |local0|local1|local2|local3
                |local4|local5|local6|local7
    |stderr
    |null;

    [ severity critical|error|warning|notice
                 |info|debug [level]|dynamic; ]
    [ print-category yes|no; ]
    [ print-severity yes|no; ]
    [ print-time yes|no; ]
  }; ]

  [ category category_name {
    channel_name; [ channel_name; ... ]
  }; ]
  ...
};

The channel clause is essentially the same as it was in BIND 8 with the addition of stderr as a possible destination for messages. The category clause looks the same, but there has been a major change in the categories supported. One category has been renamed from db to database. A dozen categories are no longer supported: cname, eventlib, insist, load, maintenance, ncache, os, packet, panic, parser, response-check, and statistics. Six new categories have been added:

The BIND 9 syntax of the four zone statement variants is:

zone domain_name [ in|hs|hesiod|chaos ] { 
  type master;
  file pathname;
  [ forward only|first; ]
  [ forwarders { address-list; }; ]
  [ allow-update { address_match_list }; ] 
  [ allow-update-forwarding { address_match_list }; ]
  [ allow-query { address_match_list }; ]
  [ allow-transfer { address_match_list }; ]
  [ allow-notify { address_match_list }; ]
  [ dialup yes|no; ]
  [ notify yes|no|notify|notify-passive|refresh|passive; ]
  [ also-notify { address-list };
  [ database string; [...] ]
  [ update-policy { policy }; ]
  [ sig-validity-interval number; ]
  [ max-refresh-time number; ] 
  [ max-retry-time number; ] 
  [ max-transfer-idle-out number; ] 
  [ max-transfer-time-out number; ] 
  [ min-refresh-time number; ] 
  [ min-retry-time number; ]
};

zone domain_name [ in|hs|hesiod|chaos ] { 
  type slave|stub;
  [ file pathname; ]
  [ ixfr-base pathname; ]
  masters [port ip_port]{ address-list };
  [ forward only|first; ]
  [ forwarders { address-list; }; ]
  [ check-names warn|fail|ignore; ]
  [ allow-update { address_match_list }; ]
  [ allow-update-forwarding { address_match_list }; ]
  [ allow-query { address_match_list }; ]
  [ allow-transfer { address_match_list }; ]
  [ transfer-source ip_addr; ]
  [ dialup yes|no|notify|notify-passive|refresh|passive; ]
  [ max-transfer-time-in number; ]
  [ notify yes|no; ]
  [ also-notify { address-list };
  [ max-refresh-time number; ] 
  [ max-retry-time number; ] 
  [ max-transfer-idle-in number; ] 
  [ max-transfer-idle-out number; ] 
  [ max-transfer-time-in number; ] 
  [ max-transfer-time-out number; ] 
  [ min-refresh-time number; ] 
  [ min-retry-time number; ]  
  [ transfer-source ip_addr|*] [port ip_port|*]; ] 
  [ transfer-source-v6 ip6_addr|*] [port ip_port|*]; ]
};

zone "." [ in|hs|hesiod|chaos ] { 
  type hint;
  file pathname;
};

zone domain_name [in|hs|hesiod|chaos] { 
  type forward;
  [ forward only|first; ]
  [ forwarders { address-list; }; ]
};

BIND 9 uses the same four zone command variations as does BIND 8. The difference between the two versions of BIND is that they use different options. Most of the options shown in the BIND 9 syntax were explained in the discussion of the BIND 9 options statement. The two options that are unique to the BIND 9 zone statement are:

The BIND 9 controls statement defines the control channels used by rndc. rndc performs the same functions as the older ndc program, but it can reliably be used over a network. The BIND 9 controls statement is:

controls {
  [ inet ip_addr|*
    port ip_port 
    allow address_match_list;
    keys key_list; ]
};

In BIND 9, the controls statement always defines a network socket. However, strong authentication is used that requires cryptographic keys.

The Start of Authority (SOA) record marks the beginning of a zone, and is usually the first record in a zone file. All of the records that follow are part of the zone declared by the SOA. Each zone has only one SOA record; the next SOA record encountered marks the beginning of another zone. Because a zone file is normally associated with a single zone, it normally contains only one SOA record.

The format of the SOA record is:

[zone] [ttl] IN SOA origin contact  ( 
                    serial
                  refresh
                    retry
                  expire 
                  negative_cache_ttl  )

The components of the SOA record are:

Most of the fields in the SOA record provide values used to keep the slave servers synchronized with the master server. These values are used to guarantee that the slave will periodically pull a copy of the zone from the master server. In addition to this, and completely independent of the settings on the SOA record, the master notifies the slaves when the zone is updated in order to push a copy of the zone down to the slave. Combining the master-initiated zone push and the slave-initiated zone pull ensures that the zone files on the master and its slaves stay tightly synchronized.

A sample SOA record for the wrotethebook.com domain is:

@    IN  SOA  crab.wrotethebook.com. david.crab.wrotethebook.com. ( 
              2001061801             ; serial 
              21600                  ; refresh four times a day 
              1800                   ; retry every half hour 
              604800                 ; expire after 1 week 
              900                    ; negative cache ttl is 15 minutes
)

Notice the serial number in this SOA. The serial number is in the format yyyymmddvv, where yyyy is the year, mm is the month, dd is the day, and vv is the version written that day. This type of serial number allows the administrator to track what day the zone was updated. Adding the version number allows for multiple updates in a single day. This zone file was created June 18, 2001, and it is the first update that day.

This SOA record also says that crab is the master server for this zone and that the person responsible for this zone can be reached at the email address david@crab.wrotethebook.com. The SOA tells the slave servers to check the zone for changes four times a day and to retry every half hour if they don’t get an answer. If they retry for an entire week and never get an answer, they should discard the data for this zone. Finally, if an RR does not exist in this zone and the remote server decides to cache that information, it should cache that information for 15 minutes.

Name Server (NS) resource records identify the authoritative servers for a zone. These records are the pointers that link the domain hierarchy together. NS records in the top-level domains point to the servers for the second-level domains, which in turn contain NS records that point to the servers for their subdomains. Name server records pointing to the servers for subordinate domains are required for these domains to be accessible. Without NS records, the servers for a domain would be unknown.

The format of the NS RR is:

[domain] [ttl] IN NS server

The majority of the resource records in a forward-mapping zone file^[161] are address records. Address records are used to convert hostnames to IP addresses, which is the most common use of the DNS database.

The address RR contains the following:

 [host] [ttl] IN A address

A glue record is a special type of address record. Most address records refer to hosts within the zone, but sometimes an address record needs to refer to a host in another zone. This is done to provide the address of a name server for a subordinate domain. Recall that the NS record for a subdomain server identifies the server by name. An address is needed to communicate with that server, so an A record must also be provided. The address record, combined with the name server record, links the domains together—thus the term “glue record.”

The Mail Exchanger (MX) record redirects mail to a mail server. It can redirect mail for an individual computer or an entire domain. MX records are extremely useful for domains that contain some systems that don’t run SMTP server software. Mail addressed to those systems can be redirected to computers that do run server software. MX records are also used to simplify mail addressing by redirecting mail to servers that understand the simplified addresses.

The format of the MX RR is:

[name] [ttl] IN MX preference host

Here is how MX records work. If a remote system has mail to send to a host, it requests the host’s MX records. DNS returns all of the MX records for the specified host. The remote server chooses the MX with the lowest preference value and attempts to deliver the mail to that server. If it cannot connect to that server, it will try each of the remaining servers in preference order until it can deliver the mail. If no MX records are returned by DNS, the remote server delivers the mail directly to the host to which the mail is addressed. MX records only define how to redirect mail. The remote system and the mail server perform all of the processing that actually delivers the mail.

Because the remote system will first try to use an MX record, many domain administrators include MX records for every host in the zone. Many of these MX records point right back to the host to which the mail is addressed, e.g., an MX for crab with a host field of crab.wrotethebook.com. These records are used to ensure that the remote computer first attempts delivery to the host, and uses the MX server only if the host cannot accept the mail.

An important use for MX records is to allow mail to non-Internet sites to be delivered using Internet-style addressing. MX records do this by redirecting the mail to computers that know how to deliver the mail to non-Internet networks. For example, sites using uucp can register an Internet domain name with UUNET. UUNET uses MX records to redirect Internet mail addressed to these non-connected sites to uunet.uu.net, which delivers the mail to its final destination via uucp.

Here are some MX examples. All of these examples are for the imaginary domain wrotethebook.com. In the first example, mail addressed to clock.wrotethebook.com is redirected to crab.wrotethebook.com with this MX record:

 clock IN MX 10 crab

The second example is an MX record used to simplify mail addressing. People can send mail to any user in this domain without knowing the specific computer that the user reads his mail on. Mail addressed to user@wrotethebook.com is redirected by this MX record to crab, which is a mail server that knows how to deliver mail to every individual user in the domain.

 wrotethebook.com. IN MX 10 crab.wrotethebook.com.

The last example is an MX record that redirects mail addressed to any host within the domain to a central mail server. Mail addressed to any host, horseshoe.wrotethebook.com, 24seven.wrotethebook.com, or anything.wrotethebook.com, is redirected to crab. This is the most common use of the wildcard character (*).

 *.wrotethebook.com. IN MX 10 crab.wrotethebook.com.

In these examples, the preference is 10 so that a mail server with a lower preference number can be added to the zone without changing the existing MX record. Also notice that the hostnames in the first example are specified relative to the wrotethebook.com domain, but the other names are not relative because they end in a dot. All of these names could have been entered as relative names because they all are hosts in the wrotethebook.com domain; fully qualified names were used only to vary the examples. Finally, the wildcard MX record applies only to hosts that do not have specific MX records. If the specific record for clock is in the same configuration as the wildcard record, the wildcard MX does not apply to clock.

The Canonical Name (CNAME) resource record defines an alias for the official name of a host. The CNAME record provides a facility similar to nicknames in the host table. The facility provides alternate hostnames for the convenience of users, and generic hostnames used by applications (such as loghost used by syslogd).

The CNAME record is frequently used to ease the transition from an old hostname to a new hostname. While it is best to avoid hostname changes by carefully choosing hostnames in the first place, not all changes can be avoided. When you do make a name change, it can take a long time before it becomes completely effective, particularly if the hostname is embedded in a mailing list run at a remote site. To reduce problems for the remote site, use a CNAME record until they can make the change.

The format of the CNAME record is:

                  nickname [ttl] IN CNAME host

One important thing to remember about the CNAME record is that all other resource records must be associated with the official hostname and not with the nickname. This means that the CNAME record should not be placed between a host and the list of RRs associated with that host. The example below shows a correctly placed CNAME record:

rodent     IN    A       172.16.12.2 
           IN    MX      5 rodent.wrotethebook.com. 
           IN    RP      alana.wrotethebook.com. alana 
           IN    TXT     "Linux workstation in room A15"
mouse      IN    CNAME   rodent.wrotethebook.com.

In this example, the hostname rodent stays in force for the MX, RP, and TXT records because they all have blank name fields. The CNAME record changes the name field value to mouse, which is a nickname for rodent. Any RRs with blank name fields following this CNAME record would associate themselves with the nickname mouse, which is illegal. An improper CNAME placement is:

rodent     IN    A       172.16.12.2 
mouse      IN    CNAME   rodent.wrotethebook.com. 
           IN    MX      5 rodent.wrotethebook.com. 
           IN    RP      alana.wrotethebook.com. alana 
           IN    TXT     "Linux workstation in room A15"

This improperly placed CNAME record causes named to display the error message “mouse.wrotethebook.com has CNAME and other data (illegal).” Check /var/adm/messages for named error messages to ensure that you have not misplaced any CNAME records.

The Domain Name Pointer (PTR) resource records are used to convert numeric IP addresses to hostnames. This is the opposite of what is done by the address record that converts hostnames to addresses. PTR records are used to construct the in-addr.arpa reverse domain files.

Many administrators ignore the reverse domains because things appear to run fine without them. Don’t ignore them. Keep these zones up to date. Several programs use the reverse domains to map IP addresses to hostnames when preparing status displays. A good example is the netstat command. Some service providers use the reverse domains to track who is using their services. If they cannot map your IP address back to a hostname, they reject your connection.

The format of the PTR record is:

                  name [ttl] IN PTR host

There are many examples of PTR records in the sample reverse-mapping zone file (172.16.rev) shown in Chapter 8.

The Responsible Person (RP) record identifies the point of contact for a host or domain. The format of the RP record is:

[name] [ttl] IN RP mail_address text_pointer

Here’s an example of how an RP record is used with a TXT record:

crab.wrotethebook.com.   IN RP  craig.wrotethebook.com. crabRP
crabRP.wrotethebook.com. IN TXT "Craig Hunt (301)555-1234 X237"

The RP record states that the person responsible for crab.wrotethebook.com can be reached via email at craig@wrotethebook.com and that additional information about the person can be obtained in the TXT records for crabRP.wrotethebook.com. The TXT record provides the contact person’s name and phone number.

The Text (TXT) resource record holds string data. The text data can be in any format. Some sites define a local format for the information. For example, a TXT record could hold the Ethernet address of a host at one site and a room number at another site.

The format of the TXT record is:

[name] [ttl] IN TXT string

The Host Information (HINFO) resource record provides a short description of the hardware and operating system used by a specific host. The hardware and software are described using standard terminology defined in the Assigned Numbers RFC in the sections on Machine Names (hardware) and System Names (software). There are a large number of hardware and software designators listed in the RFC. Most names use the same general format. Names with embedded blanks must be enclosed in quotes, so some names have a dash (-) where you might expect a blank. A machine name is usually the manufacturer’s name in uppercase letters separated from the model number by a dash. The system name is usually the manufacturer’s operating system name written in uppercase letters. Naturally the rapid changes in the computer market constantly make the data in the Assigned Numbers RFC out of date. Because of this, many administrators make up their own values for machine names and system names.

The format of the HINFO record is:

[host] [ttl] IN HINFO hardware software

No widely used application makes use of the HINFO record; the record just provides information. Some security-conscious sites discourage its use. They fear that this additional information helps intruders narrow their attacks to the specific hardware and operating system that they wish to crack. The general-purpose TXT record is more often used to provide information about systems than is the HINFO record.

The Well-Known Services (WKS) resource record names the network services supported by the specified host. The official protocol names and services names used on the WKS record are defined in the Assigned Numbers RFC. The simplest way to list the names of the well-known services is to cat the /etc/services file on your system. Each host can have no more than two WKS records; one record for TCP and one for UDP. Because several services are usually listed on the WKS record, each record may extend through multiple lines.

The format of the WKS record is:

[host] [ttl] IN WKS address protocol services

There are no widely used applications that make use of this record. It is used only to provide general information about the system. Again, security-conscious sites may not wish to advertise their services. Some protocols, such as tftp and finger, are prime targets for intruders. The SRV record is more useful for providing information about the services offered by a specific server.

The Server Selection (SRV) record provides a standardized way to locate network servers. The SRV record provides a standard convention for creating generic server names, and it adds features for server selection and load-balancing. The format of the SRV record is:

                  name [ttl] IN SRV preference weight port server