named.conf Configuration Commands

The named.conf file defines the name server configuration and tells named where to obtain the name server database information. BIND 8 uses the following configuration commands: key, acl, options, logging, zone, server, controls, and trusted-keys. BIND 9 uses the same eight commands and adds the view command.

In addition to these configuration commands, both BIND 8 and BIND 9 provide an include statement used to load an external file that contains any of the configuration commands. For example: 

include /var/named/keys

copies the file /var/named/keys, which might be a file containing key and trusted-key commands into the named.conf file.

The key Statement

The key statement assigns an internal name used to reference an authentication method. key statements usually occur near the start of the configuration because forward references are not allowed. The syntax of the key statement for both BIND 8 and BIND 9 is: 

key key_id {
 algorithm algorithm_id; secret secret_string;
}
;

The acl Statement

The acl command assigns a name to an address match list so that it can be referenced later in the configuration. Forward references are not allowed. The syntax of the acl command for both BIND 8 and BIND 9 is: 

acl name {
 address_match_list };

The trusted-keys Statement

The trusted-keys statement manually defines the public key for a remote domain when that key cannot be securely obtained from the network. The BIND 8 and BIND 9 syntax for the trusted-keys statement is: 

trusted-keys {
 domain_name flags protocol algorithm key; [...] };

The server Statement

The server statement defines the characteristics of a remote server. The BIND 8 syntax is: 

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

The server statement applies to the remote server identified by address.

The BIND 9 server statement

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 options Statement

The options statement defines global options for BIND and the DNS protocol. The BIND 8 syntax of the options command is: 

options {
 [ version string; ] [ directory pathname; ] [ named-xfer pathname; ] [ dump-file pathname; ] [ memstatistics-file pathname; ] [ pid-file pathname; ] [ statistics-file pathname; ] [ auth-nxdomain yes|no; ] [ deallocate-on-exit yes|no; ] [ dialup yes|no; ] [ fake-iquery yes|no; ] [ fetch-glue yes|no; ] [ has-old-clients yes|no; ] [ host-statistics yes|no; ] [ multiple-cnames yes|no; ] [ notify yes|no; ] [ recursion yes|no; ] [ rfc2308-type1 yes|no; ] [ use-id-pool yes|no; ] [ treat-cr-as-space yes|no; ] [ also-notify {
 address-list;
}
; [ forward only|first; ] [ forwarders {
 address-list;
}
; ] [ check-names master|slave|response warn|fail|ignore; ] [ 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 }; ] [ query-source [address ip_addr|*] [port ip_port|*] ; ] [ lame-ttl number; ] [ max-transfer-time-in number; ] [ max-ncache-ttl number; ] [ min-roots number; ] [ serial-queries number; ] [ transfer-format one-answer|many-answers; ] [ transfers-in number; ] [ transfers-out number; ] [ transfers-per-ns number; ] [ transfer-source ip_addr; ] [ maintain-ixfr-base yes|no; ] [ max-ixfr-log-size number; ] [ coresize size; ] [ datasize size; ] [ files size; ] [ stacksize size; ] [ cleaning-interval number; ] [ heartbeat-interval number; ] [ interface-interval number; ] [ statistics-interval number; ] [ topology {
 address_match_list }; ] [ sortlist {
 address_match_list }; ] [ rrset-order {
 order_spec ; [ order_spec ; ... ] ] };
}
;

There are almost a dozen different types of values for these options. Two options, check-names and transfer-format, accept keyword values. Boolean options accept either yes or no. All other options expect an appropriate value in a specific format. Some formats (string, number, pathname, domain, type, class, ip_port, and ip_addr) are self-explanatory. Some formats require a little explanation:.

The BIND 8 options are:

The BIND 9 options statement

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 logging Statement

The logging statement defines the logging options for the server. The logging statement can include two different types of subordinate clauses: the channel clause and the category clause. The BIND 8 syntax of the 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 |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 defines how logging messages are handled. Messages are written to a file (file), sent to syslog (syslog), or discarded (null). If a file is used, you can specify how many old versions are retained (version), how large the log file is allowed to grow (size), and the severity of the messages written to the log file (severity). You can specify that the time (print-time), category (print-category), and severity (print-severity) of the message be included in the log.

The category clause defines the types of messages sent to the channel. Thus the category clause defines what is logged, and the channel clause defines where it is logged. The categories are listed in Table C-1.

Table C-1. BIND 8 logging categories

Category Type of messages logged
cname Messages recording CNAME references.
config Messages about configuration file processing.
db Messages that log database operations.
default Various types of messages. This is the default if nothing is specified.
eventlib Messages containing debugging data from the event system.
insist Messages that report internal consistency check failures.
lame-servers Messages about lame server delegations.
load Messages about loading the zone.
maintenance Messages reporting maintenance events.
ncache Messages about negative caching.
notify Messages tracing the NOTIFY protocol.
os Messages reporting operating system problems.
packet Messages containing dumps of all of the packets sent and received.
panic Messages generated by a fault that causes the server to shut down.
parser Messages about configuration command processing.
queries Messages about every DNS query received.
response-checks Messages reporting the results of response checking.
security Messages concerning the application of security criteria. These are most meaningful if allow-update, allow-query, and allow-transfer options are in use.
statistics Messages containing server statistics.
update Messages concerning dynamic updates.
xfer-in Messages recording inbound zone transfers.
xfer-out Messages recording outbound zone transfers.

The BIND 9 logging statement

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 zone Statement

The zone statement identifies the zone being served and defines the source of DNS database information. There are four variants of the zone statement: one for the master server, one for the slave servers, one for the root cache zone, and a special one for forwarding. The BIND 8 syntax of each variant is: 

zone domain_name [ in|hs|hesiod|chaos ] {
 type master; file pathname; [ forward only|first; ] [ forwarders {
 address-list;
}
; ] [ check-names warn|fail|ignore; ] [ allow-update {
 address_match_list }; ] [ allow-query {
 address_match_list }; ] [ allow-transfer {
 address_match_list }; ] [ dialup yes|no; ] [ notify yes|no; ] [ also-notify {
 address-list }; [ ixfr-base pathname; ] [ pubkey flags protocol algorithm key; ] }; 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-query {
 address_match_list }; ] [ allow-transfer {
 address_match_list }; ] [ transfer-source ip_addr; ] [ dialup yes|no; ] [ max-transfer-time-in number; ] [ notify yes|no; ] [ also-notify {
 address-list }; [ pubkey flags protocol algorithm key; ] }; zone "." [ in|hs|hesiod|chaos ] {
 type hint; file pathname; [ check-names warn|fail|ignore; ] }; zone domain_name [in|hs|hesiod|chaos] {
 type forward; [ forward only|first; ] [ forwarders {
 address-list;
}
; ] [ check-names warn|fail|ignore; ] };

The zone keyword is followed by the name of the domain. For the root cache, the domain name is always "". The domain name is followed by the data class. This is always IN for Internet DNS service, which is the default if no value is supplied.

The type clause defines whether this is a master server, a slave server, a forwarded zone, or the hints file for the root cache. A stub server is a slave server that loads only the NS records instead of the entire domain.

The file clause for a master server points to the source file from which the zone is loaded. For the slave server, it points to the file to which the zone is written, and the master clause points to the source of the data written to the file. For the root cache, the file clause points to the hints file used to initialize the cache. A forwarded domain does not have a file clause because no data for the forwarded domain is stored on the local server.

With the exception of the pubkey option, all of the options available for the BIND 8 zone statement are covered earlier in this appendix. When defined in a zone statement, an option applies only to the specific zone. When specified in the options statement, an option applies to all zones. The specific settings for a zone override the global settings of the options statement.

The pubkey option defines the DNSSEC public encryption key for the zone when there is no trusted mechanism for distributing public keys over the network. pubkey defines the DNSSEC flags, protocol, and algorithm as well as a base64-encoded version of the key. The remote server that will be accessing this domain through DNSSEC defines the same settings using the trusted-key command described earlier in this appendix.

The BIND 9 zone statement

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 controls Statement

The BIND 8 controls statement defines the control channels used by ndc. ndc can use a Unix socket or a network socket as a control channel. The controls statement defines those sockets. The syntax is: 

controls {
 [ inet ip_addr port ip_port allow {
 address_match_list;
}
; ] [ unix pathname perm file_permissions owner uid group gid; ] };

The first three options, inet, port, and allow, define the IP address and the port number of a network socket and the access control list of those systems allowed to control named through that channel. Because BIND 8 has weak authentication, creating a control channel that is accessible from the network is a risky thing to do. Whoever gains access to that channel has control over the name server process.

The last four options, unix, perm, owner, and group, define the Unix control socket. The Unix socket appears as a file in the filesystem. It is identified by a normal file pathname, for example, /var/run/ndc. Like any file, the Unix socket is assigned the user ID (uid) of its owner and a valid group ID (gid). It is protected by standard file permissions. Only numeric uid, gid, and file_permissions values are acceptable. The file_permissions value must start with a 0. For example, to set owner read and write, group read, and world no permissions, the numeric value would be 0640.

The BIND 9 controls statement

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.

BIND 9 view Statement

The view statement allows the same zone to be viewed differently by different clients. This makes it possible to provide an internal view to clients within an organization, and a more limited, external view to clients in the outside world. The syntax of the view command is: 

view view-name {
 match-clients {
 address_match_list }; [ view-option; ... ] [ zone-statement; ... ] };

The view statement is available only in BIND 9. BIND 8 does not support views.