James Thornton logo
James Thornton
Google
Web jamesthornton.com
Internet Business Consultant
Home Blog Bio Projects Contact Latest Blog (new site): How to Get to Genius
JamesThornton.com -> Archive -> Redhat -> Linux -> 9 -> Reference-Guide -> One Page

Red Hat Linux 9: Red Hat Linux Reference Guide
PrevChapter 12. Berkeley Internet Name Domain (BIND)Next

12.2. /etc/named.conf

The named.conf file is a collection of statements using nested options surrounded by opening and closing ellipse characters, { }. Administrators must be careful when editing named.conf to avoid syntactical errors as many seemingly minor errors will prevent the named service from starting.

WarningWarning
 

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.

A typical named.conf file is organized similar to the following example: 

<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>;
};

12.2.1. Common Statement Types

The following types of statements are commonly used in /etc/named.conf:

12.2.1.1. acl Statement

The acl statement (or access control statement) defines groups of hosts which can then be permitted or denied access to the nameserver.

An acl statement takes the following form: 

acl <acl-name> {
    <match-element>;
    [<match-element>; ...]
};

In this statement, replace <acl-name> with the name of the access control list and replace <match-element> with a semi-colon separated list of IP addresses. Most of the time, an individual IP address or IP network notation (such as 10.0.1.0/24) is used to identify the IP addresses within the acl statement.

The following access control lists are already defined as keywords to simplify configuration:

  • 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 used in conjunction with other statements (such as the options statement), acl statements can be very useful in preventing the misuse of a BIND nameserver.

The following example defines two access control lists and uses an options statement to define how they are treated by the nameserver: 

  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; };
 }

This example contains two access control lists, black-hats and red-hats. Hosts in the black-hats list are denied access to the nameserver, while hosts in the red-hats list are given normal access.

12.2.1.2. include Statement

The include statement allows files to be included in a named.conf. This way sensitive configuration data (such as keys) can be placed in a separate file with restrictive permissions.

An include statement takes the following form: 

include  "<file-name>"

In this statement, <file-name> is replaced with an absolute path to a file.

12.2.1.3. options Statement

The options statement defines global server configuration options and sets defaults for other statements. It can be used to specify the location of the named working directory, the types of queries allowed, and much more.

The options statement takes the following form: 

options { 
        <option>;
	[<option>; ...] 
};

In this statement, the <option> directives are replaced with a valid option.

The following are commonly used options:

  • 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, this option applies to recursive queries. By default, all hosts are allowed to perform recursive queries on the nameserver.

  • blackhole — Specifies which hosts are not allowed to query the server.

  • directory — Changes the named working directory to something other than the default value, /var/named/.

  • forward — Controls forwarding behavior of a forwarders directive.

    The following options are accepted:

    • first — Specifies that the namservers specified in the forwarders directive be queried before named attempts to resolve the name itself.

    • only — Specifies that named not attempt name resolution itself in the event queries to namservers specified in the forwarders directive fail.

  • forwarders — Specifies a list of valid IP addresses for nameservers where requests should be forwarded for resolution.

  • listen-on — Specifies the network interface on which named listens for queries. By default, all interfaces are used.

    In this way, if the DNS server is also a gateway, BIND can be configured to only answer queries that originate from one of the networks.

    A listen-on directive might look like this: 

    options {
   listen-on { 10.0.1.1; };
};

    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. It accepts the following options:

    • yes — Notifies slave servers.

    • no — Does not notify slave servers.

    • explicit — Only notifies slave servers specified in an also-notify list within a zone statement.

  • pid-file — Specifies the location of the process ID file created by named.

  • statistics-file — Specifies an alternate location for statistics files. By default, named statistics are saved to the /var/named/named.stats file.

Dozens of other options are also available, many of which rely upon one another to work properly. See the BIND 9 Administrator Reference Manual in Section 12.7.1 Installed Documentation and the man page for bind.conf for more details.

12.2.1.4. zone Statement

A zone statement defines the characteristics of a zone such as the location of its configuration file and zone-specific options. This statement can be used to override the global options statements.

A zone statement takes the following form: 

zone <zone-name> <zone-class> {
     <zone-options>;
     [<zone-options>; ...]
};

In this statement, <zone-name> is the name of the zone, <zone-class> is the optional class of the zone, and <zone-options> is a list of options characterizing the zone.

The <zone-name> attribute for the zone statement is particularly important, as it is the default value assigned for the $ORIGIN directive used within the corresponding zone file located in the /var/named/ directory. The named daemon appends the name of the zone to any non-fully qualified domain name listed in the zone file.

For example, if a zone statement defines the namespace for example.com, use example.com as the <zone-name> so it is placed at the end of hostnames within the example.com zone file.

For more information about zone files, see Section 12.3 Zone Files.

The most common zone statement options include the following:

  • 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 careful when allowing hosts to update information about their zone. Do not enable this option unless the host specified is completely trusted. In general, it better to have an administrator manually update the records for a zone and reload the named service.

  • file — Specifies the name of the file in the named working directory that contains the zone's configuration data.

  • masters — The masters option lists the IP addresses from which to request authoritative zone information. Used only if the zone is defined as type slave.

  • notify — Controls whether named notifies the slave servers when a zone is updated. It accepts the following options:

    • yes — Notifies slave servers.

    • no — Does not notify slave servers.

    • explicit — Only notifies slave servers specified in an also-notify list within a zone statement.

  • type — Defines the type of zone.

    Below is a list of valid options:

    • forward — Forwards all requests for information about this zone to other nameservers.

    • hint — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a hint zone.

    • master — Designates the nameserver as authoritative for this zone. A zone should be set as the master if the zone's configuration files reside on the system.

    • slave — Designates the nameserver as a slave server for this zone. Also specifies the IP address of the master nameserver for the zone.

  • zone-statistics — Configures named to keep statistics concerning this zone, writing them to either the default location (/var/named/named.stats) or the file listed the statistics-file option in the server statement. See Section 12.2.2 Other Statement Types for more information about the server statement.

12.2.1.5. Sample zone Statements

Most changes to the /etc/named.conf file of a master or slave nameserver involves adding, modifying, or deleting zone statements. While these zone statements can contain many options, most nameservers require only a small subset to function efficiently. The following zone statements are very basic examples illustrating a master-slave nameserver relationship.

The following is an example of a zone statement for the primary nameserver hosting example.com (192.168.0.1): 

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

In the statement, the zone is identified as example.com, the type is set to master, and the named service is instructed to read the /var/named/example.com.zone file. It also tells named not to allow by any other hosts to update.

A slave server's zone statement for example.com looks slightly different from the previous example. For a slave server, the type is set to slave and in place of the allow-update line is a directive telling named the IP address of the master server.

A slave server's zone statement for example.com may look like this: 

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

This zone statement configures named on the slave server to look for the master server at the 192.168.0.1 IP address for information about the example.com zone. The information the slave server receives from the master server is saved to the /var/named/example.com.zone file.

12.2.2. Other Statement Types

The following is a list of lesser used statement types available within named.conf

  • controls — Configures various security requirements necessary to use the rndc command to administer the named service.

    See Section 12.4.1 Configuring /etc/named.conf to see how the controls statement should look, including various options that may only be used with 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 Section 12.4.2 Configuring /etc/rndc.conf for instruction on how to write 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 to 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 in Section 12.7.1 Installed Documentation.

  • 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 secure DNS (DNSSEC). See Section 12.5.3 Security for more information concerning BIND security.

  • view "<view-name>" — Creates special views depending upon the host contacting to 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 options 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 Section 12.5.2 Multiple Views for more information about the view statement.

12.2.3. Comment Tags

The following is a list of valid comment tags used within named.conf:

  • // — When placed at the beginning of a line, that line is ignored by named.

  • # — When placed at the beginning of a line, that line is ignored by named.

  • /* and */ — When text is enclose in these tags, the block of text is ignored by named.

PrevHomeNext
Berkeley Internet Name Domain (BIND)UpZone Files
Follow espeed on Twitter

James Thornton,<james@jamesthornton.com>
Services: Search Engine Optimization SEO 		Electric Speed: Marketing Internet