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 |
|---|---|
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 the named service 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 17-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 17-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:
acl <acl-name> — Configures an access control list of IP addresses to be allowed or disallowed certain named services. Most of the time, individual IP addresses or IP network notation (such as 10.0.1.0/24) is used identify the exact IPs.
A few access control lists are already defined, so you do not have to configure an acl statement to define them:
any — Matches every IP address.
localhost — Matches any IP address in use by the local system.
localnets — Matches any IP address on any network to which the local system is connected .
none — Matches no IP addresses.
When utilized with other /etc/named.conf statements and their options, acl statements can be very useful in ensuring the proper use of your BIND nameserver. Consider the example in Figure 17-3.
acl black-hats { 10.0.2.0/24; 192.168.0.0/24; }; acl red-hats { 10.0.1.0/24; }; options { blackhole { black-hats; }; allow-query { red-hats; }; allow-recursion { red-hats; }; }Figure 17-3. Example of acl statements in use
This named.conf contains two access control lists (black-hats and red-hats.
controls — Configures various security requirements necessary to use the rndc command to administer the named service.
See the Section called /etc/named.conf to see how the controls statement should look, including various options that may only be used with it.
include "<file-name>" — Includes the specified file within the current configuration file, allowing sensitive configuration data (such as keys) to be placed in a separate file with permissions that prevent non-privileged users from reading it.
key "<key-name>" — Defines a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the rndc command. Two options are used with key:
algorithm <algorithm-name> — The type of algorithm used, such as dsa or hmac-md5.
secret "<key-value>" — The encrypted key.
See Figure 17-22 for an example of a key statement.
logging — Allows for the use of multiple types of logs, called channels. By using the channel option within the logging statement, a customized type of log, with its own file name (file), size limit (size), versioning (version), and level of importance (severity), can be constructed. Once a customized channel has been defined, a category option is used the categorize the channel and begin logging when named is restarted.
By default, named logs standard messages to the syslog daemon, which places them in /var/log/messages. This occurs because several standard channels are built into BIND with various severity levels, such as one that handles informational logging messages (default_syslog) and another that specifically handles debugging messages (default_debug). A default category, called default, uses the built-in channels to do normal logging without any special configuration.
Customizing the logging process can be a very detailed process and is beyond the scope of this chapter. For information on creating custom BIND logs, see the BIND 9 Administrator Reference Manual.
options — Assigns values to many assorted options, including the use of forwarders, the location of the named working directory, the names of the various files, and much more.
The following options are among the most commonly used:
allow-query — Specifies which hosts are allowed to query this nameserver. By default, all hosts are allowed to query. An access control list or collection of IP addresses or networks may be used here to only allow particular hosts to query the nameserver.
allow-recursion — Similar to allow-query, except it applies to recursive queries. By default, all hosts are allowed to perform recursive queries on the nameserver.
directory — Changes the named working directory to something other than the default, /var/named.
forward — Controls how forwarding occurs, if the forwarders option contains valid IP addresses designating where to send requests.
If the first option is used, then the nameservers specified in the forwarders option are queried first for the information, and if they do not have it, named will attempt the resolution itself.
If the only option is used, named will not attempt the resolution itself if the forwarders are not successful.
forwarders — Specifies a list of nameservers where requests should be forwarded for resolution.
listen-on — Specifies the network interface that named will use to listen for queries. By default, all interfaces are used.
This option is useful if you have more than one network interface and would like to limit the systems that can make requests of your nameserver. For example, if you have a machine serving as a gateway and a nameserver, and you would like to block any requests except those that originate from your private network, your listen-on option might look like Figure 17-4.
In this way, only requests that arrive from the network interface serving the private network (10.0.1.1) will be accepted.
notify — Controls whether named notifies the slave servers when a zone is updated. The default is yes, but you can set this to no, to prevent slaves from being notified, or explicit, to only notify servers in an also-notify list.
pid-file — Allows you to specify the location of the process ID file created by named when it starts.
statistics-file — Allows you to specify the location of where the statistics file is written. By default, named statistics are saved in /var/named/named.stats.
Dozens of other options are also available, many of which rely upon one another to work properly. See the BIND 9 Administrator Reference Manual for more details.
server — Defines particular options that affect how named should act toward remote nameservers, especially regarding notifications and zone transfers.
The transfer-format option controls whether one resource record is sent with each message (one-answer) or multiple resource records are sent with each message (many-answers). While many-answers is more efficient, only newer BIND nameservers understand it.
trusted-keys — Contains assorted public keys used for DNSSEC. See the Section called Security for an introduction to BIND security.
view "<view-name>" — Creates special views that respond with a particular type of information depending upon the host contacting the nameserver. This allows some hosts to receive one answer regarding a particular zone while other hosts receive totally different information. Alternatively, certain zones may only be made available to particular trusted hosts while non-trusted hosts can only make queries for other zones.
Multiple views may be used, so long as their names are unique. The match-clients option specifies the IP addresses that apply to a particular view. Any option statements may also be used within a view, overriding the global options already configured for named. Most view statements contain multiple zone statements that apply to the match-clients list. The order in which view statements are listed is important, as the first view statement that matches a particular client's IP address is used.
See the Section called Multiple Views for more information about the view statement.
zone "<zone-name>" — Specifies particular zones for which this nameserver is authoritative. The zone statement is primarily used to specify the file containing the zone's configuration and pass certain options about that zone to named that override other global option statements used in /etc/named.conf.
The name of the zone is important, as it is the default value assigned to the $ORIGIN directive used in the zone file and is appended to non-FQDNs. So, for example, if this zone statement defines the namespace for domain.com, you should use domain.com as the <zone-name> so it will be placed at the end of hostnames used in the zone file.
The most common zone statement options include:
allow-query — Specifies the clients that are allowed to request information about this zone. The default is to allow all query requests.
allow-transfer — Specifies the slave servers that are allowed to request a transfer of the zone's information. The default is to allow all transfer requests.
allow-update — Specifies the hosts that are allowed to dynamically update information in their zone. The default is to deny all dynamic update requests.
Be very careful about allowing hosts to update information about their zone. Do not enable this option unless the host specified is completely trusted. It is generally better to have an administrator manually update the zone's records and reload the named service, if possible.
file — Specifies the name of the file in the named working directory that contains the zone's configuration data. The default is /var/named.
masters — Used if the zone is defined as a slave type. The masters option tells a slave's named the IP addresses from which to request authoritative zone information.
notify — Works in a similar manner to the notify option used with the option statement.
type — Defines the type of zone. The following types may be used:
forward — Tells the nameserver to forward all requests for information about this zone to other nameservers.
hint — A special type of zone that is used to point to the root nameservers, which are used to resolve queries when a zone is not otherwise known. You should not need to configure a hint zone beyond the default in /etc/named.conf.
master — Designates this nameserver as authoritative for this zone. A zone should be set as the master type if you have the zone's configuration files on this system.
slave — Designates this nameserver as a slave server for this zone, telling named to request the zone's configuration files from the master nameserver's IP address for that zone.
zone-statistics — Tells named to keep statistics concerning this zone, writing them to either the default location (/var/named/named.stats) or the place specially designated by the statistics-file option in the server statement, if it exists.
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 17-5.
zone "domain.com" IN {
type master;
file "domain.com.zone";
allow-update { none; };
}; |
Figure 17-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 17-6.
zone "domain.com" {
type slave;
file "domain.com.zone";
masters { 192.168.0.1; };
}; |
Figure 17-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 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.
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:
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.
In Figure 17-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 17-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.
MX — Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.
In Figure 17-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 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.
The <nameserver-name> should be a FQDN.
In Figure 17-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.
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 17-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 (in seconds).
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 17-1 shows an amount of time in seconds and the equivalent time in another format.
Table 17-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 31536000 365D The following example demonstrates how a basic SOA resource record might look.
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 17-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 17-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 17-18.
The <last-IP-digit> relates to the last number in an IP address that should point to a particular system's FQDN.
In Figure 17-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 17-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 17-20.
zone "1.0.10.in-addr.arpa" IN {
type master;
file "domain.com.rr.zone";
allow-update { none; };
}; |
Figure 17-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.