The BIND nameserver named server uses the/etc/named.conf file for configuration. All zonefiles 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 inorder for named to start. While some erroneousoptions used in with some statements are not considered critical enoughto stop the server, any errors in the statements themselves will preventthe 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.
options { listen-on { 10.0.1.1; };};Figure 17-4. Example of listen-on option
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 namedto include another zone file in this zone file at the placewhere the directive is used. This allows additional zonesettings to be stored apart from the main zone file.
$ORIGIN — Sets the domain name to beappended to any unqualified records, such as those that onlyspecify 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 anddo not end in a trailing dot(.) will have this domain nameadded to them. So, in other words, when the zone record is readby the nameserver, the first line below will be interpreted asthe second line:
ftp IN CNAME server1ftp.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 Timeto Live (TTL) value for the zone. This is thenumber, in seconds, given to nameservers that tells how long thezone's resource records should continue to be valid. A resourcerecord can contains its own TTL value, which would override thisdirective.
Increasing this value tells remote nameservers to cache thiszone's information for a longer time. This reduces the number ofqueries made concerning this zone, but it also lengthens theamount 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 IPaddress to assign to a name.
<host> IN A <IP-address>
Figure 17-7. Sample A record configuration
If the <host>value is omitted, then an A record points to adefault IP address for the top of the namespace. This systemwill be the target of all non-FQDN requests.
Consider the following A record examples forthe domain.com zone file:
IN A 10.0.1.3server1 IN A 10.0.1.5
Figure 17-8. Example A records
Requests for domain.com arepointed to 10.0.1.3, while requests forserver1.domain.com are pointedto 10.0.1.5.
CNAME — Canonical name record, whichtells the nameserver that one name is also known as another.
<alias-name> IN CNAME <real-name>
Figure 17-9. Sample CNAME record configuration
In Figure 17-9, any requests sent tothe <alias-name> willpoint to the host named<real-name>.CNAME records are most commonly used to pointservices 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 toan IP address and a CNAME record points thecommonly used www hostname toit.
server1 IN A 10.0.1.5www IN CNAME server1
Figure 17-10. Example CNAME record
MX — Mail eXchange record, which tellswhere mail sent to a particular namespace controlled by thiszone should go.
IN MX <preference-value> <email-server-name>
Figure 17-11. Sample MX record configuration
In Figure 17-11, the<preference-value>allows you to numerically rank the email servers you wouldprefer to receive email for this namespace, giving preference tosome email systems over others. The MX resourcerecord with the lowest<preference-value> ispreferred over the others, but you can set multiple emailservers with the same value to distribute email traffic betweenthem.
The<email-server-name>may be a hostname or FQDN, as long as it points to the correctsystem.
IN MX 10 mail.domain.com. IN MX 20 mail2.domain.com.
Figure 17-12. Example MX records
In this example, the firstmail.domain.com email server ispreferred to themail2.domain.com email serverwhen receiving email destined for thedomain.com domain.
NS — NameServer record, which announcesthe authoritative nameservers for a particular zone.
IN NS <nameserver-name>
Figure 17-13. Sample NS record configuration
The <nameserver-name>should be a FQDN.
In Figure 17-14, two nameservers arelisted as authoritative for a domain. It is not importantwhether these nameservers are slaves or if one is a master; theyare both still considered authoritative.
IN NS dns1.domain.com. IN NS dns2.domain.com.
Figure 17-14. Example NS records
PTR — PoinTeR record, designed to pointto another part of the namespace.
PTR records are primarily used for reverse nameresolution, as they point IP addresses back to a particularname. See the Section called Reverse Name Resolution Zone Filesfor more examples of PTR records in use.
SOA — Start Of Authority record,proclaiming important authoritative information about thenamespace to the nameserver.
Located after the directives, an SOA record isthe 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 namespacebeing defined by this SOA resource record. Theprimary nameserver that is authoritative for this domain is usedfor the<primary-name-server>,and the email of the person to contact about this namespace issubstituted for the<hostmaster-email>.
The<serial-number>is incremented every time you change the zone file so thatnamed will know that it should reload thiszone. The<time-to-refresh>tells any slave servers how long to wait before asking themaster 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 outdatedzone data and should refresh it.
The<time-to-retry>tells the slave nameserver the interval to wait before issuinganother refresh request, if the master nameserver is notanswering. If the master has not replied to a refresh requestbefore the<time-to-expire>elapses, the slave stops responding as an authority for requestsconcerning that namespace.
The<minimum-TTL>requests that other nameservers cache the zone's information forat least this amount of time (in seconds).
With BIND, all times refer to seconds. However, you can also useabbreviations for other units of time other than seconds, suchas minutes (M), hours (H),days (D), and weeks (W). Thetable in Table 17-1 shows an amount oftime 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 basicSOA 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 17-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 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.5server1 IN A 10.0.1.5server2 IN A 10.0.1.7dns1 IN A 10.0.1.2dns2 IN A 10.0.1.3ftp IN CNAME server1mail IN CNAME server1mail2 IN CNAME server2www 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.
<last-IP-digit> IN PTR <FQDN-of-system>
Figure 17-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 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.
