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

key_id: The name assigned to the authentication method.
algorithm_id: The authentication algorithm used.
secret_string: A base64-encoded key used by the algorithm.

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

name

An internal name for the list. There are four predefined names:

any: Match every possible address.
none: Match no address.
localhost: Match every address assigned to the local host.
localnet: Match every address where the network portion is the same as the network portion of any address assigned to the local hosts.

address_match_list

A list of IP addresses written in dotted decimal notation with an optional address mask prefix. An exclamation point (!) before an address means “don’t match” the value. An address_match_list can also contain the name of a previously defined access control list, including the four predefined names.

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; [...]
};

domain_name: The name of the remote domain.
flags, protocol, algorithm: Attributes of the authentication method used by the remote domain.
key: A base64-encoded string representing the remote domain’s public 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.

transfer-format: Sets the format used for zone transfers with this server to either the more efficient many-answers format or the backward-compatible one-answer format.
bogus yes: Prevents the local server from sending queries to this server. The default is no, which permits queries to the remote server.
support-ixfr yes: Indicates that the remote server can support incremental transfers. no, which is the default, says that the remote server cannot perform incremental transfers.
transfers: Defines the maximum number of concurrent inbound transfers permitted from this server.
keys: Identifies the key required by the remote host for transaction security.

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:

provide-ixfr: Indicates that the local server will provide incremental zone transfers to the remote server.
request-ixfr: Indicates that the local server will request incremental zone transfers from the remote server.

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:.

address-list

A list of IP addresses separated by semicolons. This is more limited than an address_match_list.

address_match_list

A list of addresses, acl names, and key_ids.

order_spec

A multi-part rule that defines how resource records are ordered when multiple records are sent in response to a single query. The structure of an order_spec is:

[ class class ][ type type ][ name "domain" ] order order

class, type and domain are self-explanatory. order is one of three possible values:

fixed: The order in which records are defined in the zone file is maintained.
random: Resource records are shuffled into a random order.
cyclic: The resource records are rotated in a round-robin manner, which is the default order.

The BIND 8 options are:

version: The string returned when the server is queried for its version.
directory: The path of the working directory from which the server reads and writes files.
named-xfer: The path to the named-xfer program.
dump-file: The file where the database is dumped if named receives a SIGINT signal. The default filename is named_dump.db.
memstatistics-file: The file where memory usage statistics are written. The default filename is named.memstats.
pid-file: The file where the process ID is stored.
statistics-file: The file where statistics are written when named receives a SIGILL signal. The default filename is named.stats.
auth-nxdomain: yes, which is the default, causes the server to respond as an authoritative server.
deallocate-on-exit: yes writes memory usage to the named.memstats file. The default is no.
dialup: yes optimizes the server for a dial-up network operation. The default is no.
fake-iquery: yes makes the server issue a fake reply instead of an error in response to inverse queries. The default is no.
fetch-glue: yes, which is the default, retrieves all of the glue records for a response.
has-old-clients: yes sets auth-nxdomain and maintain-ixfr-base to yes and rfc2308-type1 to no.
host-statistics: yes keeps statistics on every host. The default is no.
multiple-cnames: yes permits multiple CNAME records for a domain name. The default is no.
notify: yes, which is the default, sends DNS NOTIFY messages when a zone is updated.
recursion: yes, the default, recursively seeks answers to queries.
rfc2308-type1: yes returns NS records with the SOA record for negative caching. no, the default, returns only the SOA record for compatibility with old servers.
use-id-pool: yes tracks outstanding query IDs to increase randomness. no is the default.
treat-cr-as-space: yes treats carriage returns as spaces when loading a zone file. no is the default.
also-notify: Identifies unofficial name servers to which the server should send DNS NOTIFY messages.
forward: first causes the server to first query the forwarders and then look for the answer itself. only causes the server to query only the forwarders.
forwarders: Lists the IP addresses of the servers to which queries are forwarded. The default is not to use forwarding.
check-names: Checks hostnames for compliance with the RFC specifications. Names can be checked when the master server loads the zone (master), when the slave transfers the zone (slave), or when a response is processed (response). If an error is detected, it can be ignored (ignore), a warning can be sent (warn), or the bad name can be rejected (fail).
allow-query: Only queries from hosts in the address list will be accepted. The default is to accept queries from all hosts.
allow-transfer: Only hosts in the address list are allowed to receive zone transfers. The default is to allow transfers to all hosts.
allow-recursion: Only listed hosts are allowed to make recursive queries through this server. The default is to do recursive queries for all hosts.
blackhole: Lists hosts from which this server will not accept queries.
listen-on: Defines the interfaces and ports on which the server provides name service. By default, the server listens to the standard port (53) on all installed interfaces.
query-source: Defines the address and port used to query other servers.
lame-ttl: The amount of time a lame server indication will be cached. The default is 10 minutes.
max-transfer-time-in: The maximum amount of time the server waits for an inbound transfer to complete. The default is 120 minutes (2 hours).
max-ncache-ttl: The amount of time this server will cache negative answers. The default is 3 hours and the maximum acceptable value is 7 days.
min-roots: The minimum number of root servers that must be reachable for queries involving the root servers to be accepted. The default is 2.
serial-queries: The number of outstanding SOA queries a slave server can have at one time. The default is 4.
transfer-format: one-answer transfers one resource record per message. many-answers transfers as many resource records as possible in each message.
transfers-in: Sets the maximum number of concurrent inbound zone transfers. The default value is 10.
transfers-out: Lists the number of concurrent outbound zone transfers.
transfers-per-ns: Limits the number of concurrent inbound zone transfers from any one name server. The default value is 2.
transfer-source: The IP address of the network interface this server uses to transfer zones from remote masters.
maintain-ixfr-base: yes keeps a log of incremental zone transfers. no is the default.
max-ixfr-log-size: Sets the maximum size of the incremental zone transfer log file.
coresize: Sets the maximum size of a core dump file.
datasize: Limits the amount of data memory the server may use.
files: Limits the number of files the server may have open concurrently. The default is unlimited.
stacksize: Limits amount of stack memory the server may use.
cleaning-interval: Sets the time interval for the server to remove expired resource records from the cache. The default is 60 minutes.
heartbeat-interval: Sets the time interval used for zone maintenance when the dialup option is set to yes. 60 minutes is the default.
interface-interval: Sets the time interval for the server to scan the network interface list looking for new interfaces or interfaces that have been removed. The default is every 60 minutes.
statistics-interval: Sets the time interval for the server to log statistics. The default is every 60 minutes.
topology: Forces the server to prefer certain remote name servers over others. Normally, the server prefers the remote name server that is topologically closest to itself.
sortlist: Defines a sort algorithm applied to resource records before sending them to the client.
rrset-order: Specifies the ordering used when multiple records are returned for a single query.

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:

additional-from-auth: yes, the default, causes the server to use information from any zone for which it is authoritative when completing the additional data section of a response.
additional-from-cache: yes, the default, causes the server to use information from its cache when completing the additional data section of a response.
notify-source: Defines the address and port used to send NOTIFY messages.
recursive-clients: Defines the maximum number of outstanding recursive lookups the server will perform for its clients. The default is 1000.
tcp-clients: Defines the maximum number of concurrent client connections. The default is 1000.
allow-notify: Identifies the servers that are permitted to send NOTIFY messages to the slave servers.
port: Defines the port number used by the server. The default is standard port 53.
max-transfer-time-out: Defines the maximum time allowed for outbound zone transfers. The default is 2 hours.
max-transfer-idle-in: Defines the maximum time that an inbound zone transfer will be allowed to sit idle. The default is 1 hour.
max-transfer-idle-out: Defines the maximum time that an outbound zone transfer will be allowed to sit idle. The default is 1 hour.
max-refresh-time: Sets the maximum refresh time this server will use when acting as a slave. This value overrides the refresh time set in the SOA record of the zone for which this server acts as a slave.
max-retry-time: Sets the maximum retry time this server will use when acting as a slave. This value overrides the retry time set in the SOA record of the zone for which this server acts as a slave.
max-cache-ttl: Sets the maximum amount of time this server will cache data. This value overrides the TTL values defined in the zone from which the data was retrieved.
min-refresh-time: Sets the minimum refresh time this server will use when acting as a slave. This value overrides the refresh time set in the SOA record of the zone for which this server acts as a slave.
min-retry-time: Sets the minimum retry time this server will use when acting as a slave. This value overrides the retry time set in the SOA record of the zone for which this server acts as a slave.
sig-validity-interval: Defines the amount of time that digital signatures generated for automatic updates will be considered valid. The default is 30 days.
tkey-dhkey: Identifies the Diffie-Hellman key used by the server to generate shared keys.
tkey-domain: Defines the domain name appended to shared keys. Normally this is the server’s domain name.
zone-statistics: yes causes the server to collect statistics on all zones. The default is no.

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:

general: A wide variety of messages.
resolver: Messages relating to DNS resolution.
client: Messages concerning processing of client requests.
network: Messages relating to network operations.
dispatch: Messages that trace packets sent to various server modules.
dnssec: Messages that track the processing of the DNSSEC and TSIG protocols.

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:

allow-update-forwarding: Identifies the systems that are allowed to submit dynamic zone updates to a slave that will then be forwarded to the master.
database: Specifies the type of database used for storing zone data. The default is rbt, which is the only database type supported by the standard BIND 9 executable.

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

view-name: An arbitrary name used inside the configuration to identify this view. To prevent conflicts with keywords, view-name should be enclosed in quotes, e.g., "internal".
match-clients: Defines the list of clients that will access the zone through this view.
view-option: A standard BIND 9 option. Any option defined inside the view statement applies only to this view. This allows different options to be applied to the same zone depending on which view of the zone is being used.
zone-statement: A standard BIND 9 zone statement. A complete zone statement is embedded inside the view statement to define the zone accessed through this view.

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