HP OpenVMS Systems Documentation

The acl statement assigns a symbolic name to an address match list. It gets its name from a primary use of address match lists: access control lists (ACLs).

The acl statement is formatted as follows:

acl acl-name {
    address_match_list
};

Note that the address match list must be defined with acl before it can be used elsewhere; forward references are not allowed.

The following ACLs are created automatically:

The ACLs localhost and localnets do not support IPv6. The ACL localhost does not match the host's IPv6 addresses, and the ACL localnets does not match the host's attached IPv6 networks. This limitation is due to the fact that there is no standard method for determining the complete set of local IPv6 addresses for a host.

6.5.3.2 The CONTROLS Statement

The controls statement declares control channels to be used by system administrators to affect the operation of the local name server. These control channels are used by the rndc utility to send commands to, and retrieve non-DNS results from, a name server. The controls statement is formatted as follows:

controls {
   inet ( ip_addr | * ) [ port ip_port ] allow {  address_match_list  }
                keys {  key_list  };
   [ inet ...; ]
};

An inet control channel is a TCP/IP socket listening at the specified ip_port on the specified ip_addr , which can be either an IPv4 or IPv6 address. The asterisk character (*) is interpreted as the IPv4 wildcard address; connections are accepted on any of the system's IPv4 addresses. To listen on the IPv6 wildcard address, use :: for the ip_addr . If you use the rndc utility only on the local host, use the local loopback address ( 127.0.0.1 , or :: ) for maximum security.

The ability to issue commands over the control channel is restricted by the allow and keys clauses. Connections to the control channel are permitted based on the address permissions in the address match list. key_id members of the address match list are ignored, and instead are interpreted independently based the key_list . Each key_id in the key_list is used to authenticate commands and responses given over the control channel, by digitally signing each message between the server and a command client. In order to be honored, all commands to the control channel must be signed by one of its specified keys.

If no controls statement is present, the BIND server will set up a default control channel listening on the loopback address 127.0.0.1 and its IPv6 counterpart ::1 . In this case, and also when the controls statement is present but does not have a keys clause, the BIND server attempts to load the command channel key from the file RNDC.KEY in TCPIP$ETC. To create a RNDC.KEY file, use the following command:

rndc_confgen -a

See Section 6.10 for more information about using the rndc utility.

The RNDC.KEY feature eases the transition of systems from BIND Version 8, which did not have digital signatures on its command channel messages and thus did not have a keys clause. You can use an existing BIND Version 8 configuration file in BIND Version 9 unchanged, and rndc will work the same way that ndc worked in BIND Version 8.

Because the RNDC.KEY feature is only intended to allow the backward-compatible usage of BIND Version 8 configuration files, this feature does not have a high degree of configurability. You cannot easily change the key name or the size of the secret. You should make a RNDC.CONF file with your own key if you wish to change those things.

The UNIX control channel type of BIND Version 8 is not supported in BIND Version 9 and is not expected to be added in future releases. If it is present in the controls statement from a BIND Version 8 configuration file, it is ignored and a warning is logged.

To disable the command channel, use an empty controller statement. For example:

controls { };

The include statement inserts the specified file at the point that the include statement is encountered. The include statement facilitates the administration of configuration files by permitting the reading or writing of some things but not others. For example, the statement could include private keys that are readable only by a name server. The following example shows the format of the include statement:

include filename;

The key statement defines a shared secret key for use with TSIG (see Section 6.2.3). The following example shows the format of the key statement:

key key_id {
    algorithm algorithm-id;
    secret secret-string;
};

The key statement can occur at the top level of the configuration file or inside a view statement. Keys defined in top-level key statements can be used in all views. Keys intended for use in a controls statement must be defined at the top level.

Table 6-4 describes the elements of the key statement.

The logging statement configures a wide variety of logging options for the name server. Its channel phrase associates output methods, format options and severity levels with a name that can then be used with the category phrase to select the way each class of message is logged. The following example shows the format of the logging statement:

logging {
   [ channel channel_name {
     ( file path_name
             [size size_spec]
       | syslog | stderr | null );
     [ severity (critical | error | warning | notice |
                 info | debug [ level ] | dynamic ); ]
     [ print-category yes_or_no; ]
     [ print-severity yes_or_no; ]
     [ print-time yes_or_no; ]
   }; ]
   [ category category_name {
     channel_name ; [ channel_name ; ... ]
   }; ]
   ...
};

Use one logging statement to define as many channels and categories as you want. If there is no logging statement, the logging configuration defaults to the following:

logging {
     category "unmatched" { "null"; };
     category "default" { "default_syslog"; "default_debug"; };
};

In BIND Version 9, the logging configuration is only established after the entire configuration file has been parsed. In BIND Version 8, it was established as soon as the logging statement was parsed. When the server is starting up, all logging messages regarding syntax errors in the configuration file go to the default channels.

6.5.3.5.1 The Channel Phrase

All log output goes to one or more channels; you can make as many of them as you want. Every channel definition must include a destination clause that says whether messages selected for the channel go to a file (by default, TCPIP$BIND_RUN.LOG), or are discarded. It can optionally also limit the message severity level that is accepted by the channel (the default is info ); and can specify whether to include a time stamp, the category name and severity level (the default is not to include any).

The null destination clause causes all messages sent to the channel to be discarded; in that case, other options for the channel are meaningless.

The file destination clause directs the channel to a disk file. The size option for files is used to limit log file growth. The parameter (size_spec) is specified in bytes, but shorthand notation can be used (for example, 100K, or 2M for 2 MB). If the file exceeds the size, the BIND server stops writing to the file; no file version rollover occurs. After that, no data is written to the file until the server is restarted, reloaded, or until the file is truncated manually.

On OpenVMS, the syslog and stderr destination clauses direct the channel to the TCPIP$BIND_RUN.LOG file.

The severity clause allows you to specify the level of diagnostic messages to be logged.

The server can supply extensive debugging information when it is in debugging mode. If the server's global debug level is greater than zero, then debugging mode is activated. The global debug level is set by one of the following:

• Starting the BIND server with the -d flag followed by a positive integer.
• Entering the trace command with the rndc utility. To set the global debug level to zero and turn off debugging mode, enter the the notrace command.

All debugging messages in the server have a debug level; higher debug levels give more detailed output. Channels that specify a debug severity level get the specified debugging output and less any time the server is in debugging mode, regardless of the global debugging level. For example, to produce debugging output at level 3 and less, enter the following:

channel "specific_debug_level" {
    file "foo";
    severity debug 3;
};

Channels with dynamic severity use the server's global level to determine what messages to display.

If print-time is turned on, the date and time are logged. If print-category is requested, then the category of the message is logged as well. Finally, if print-severity is turned on, then the severity level of the message is logged. The print- options can be used in any combination and are always displayed in the following order:

1. Time
2. Category
3. Severity

The following example specifies all three print- options:

28-Feb-2000 15:05:32.863 general: notice: running

Four predefined channels are used for the BIND server's default logging, as shown in the following example. Section D.3.1.2 describes how these channels are used.

channel "default_syslog" {
    syslog daemon;                 // send to TCPIP$BIND_RUN.LOG

    severity info;                 // only send priority info
                                   // and higher
};

channel "default_debug" {
    file "TCPIP$BIND_RUN.LOG";     // write to the TCPIP$BIND_RUN.LOG

    severity dynamic;              // log at the server's
                                   // current debug level
};

channel "default_stderr" {
    stderr;                        // write to TCPIP$BIND_RUN.LOG
    severity info;                 // only send priority info
                                   // and higher
};

channel "null" {
   null;                           // discard anything sent to
                                   // this channel
};

The default_debug channel only produces output when the server's debug level is not zero. By default, the BIND server writes to the TCPIP$BIND_RUN.LOG file.

Once a channel is defined, it cannot be redefined. Thus, you cannot alter the built-in channels directly, but you can modify the default logging by pointing categories at channels you have defined.

6.5.3.5.2 The Category Phrase

There are many categories, so you can send the logs you want to see anywhere, without seeing logs you do not want. If you do not specify a list of channels for a category, then log messages in that category are sent to the default category instead. If you do not specify a default category, the following definition is used:

category default { default_syslog; default_debug; };

For example, if you want to log security events to a file but you also want to preserve the default logging behavior, specify the following:

channel my_security_channel {
    file "my_security_file";
    severity info;
};
category security {
    "my_security_channel";
    default_syslog;
    default_debug;
};

To discard all messages in a category, specify the null channel:

category lame-servers { null; };
category cname { null; };

Table 6-5 describes the logging categories.

The options statement sets up global options to be used by BIND. This statement should appear only once in a configuration file. If more than one occurrence is found, the first occurrence determines the actual options used, and a warning is generated. If there is no options statement, an options block with each option set to its default is used.

The options statement has the following syntax:

options {
    [ version version_string; ]
    [ directory path_name; ]
    [ named-xfer path_name; ]
    [ tkey-domain domainname; ]
    [ tkey-dhkey key_name key_tag; ]
    [ dump-file path_name; ]
    [ memstatistics-file path_name; ]
    [ pid-file path_name; ]
    [ statistics-file path_name; ]
    [ zone-statistics yes_or_no; ]
    [ auth-nxdomain yes_or_no; ]
    [ deallocate-on-exit yes_or_no; ]
    [ dialup dialup_option; ]
    [ fake-iquery yes_or_no; ]
    [ fetch-glue yes_or_no; ]
    [ has-old-clients yes_or_no; ]
    [ host-statistics yes_or_no; ]
    [ minimal-responses yes_or_no; ]
    [ multiple-cnames yes_or_no; ]
    [ notify yes_or_no | explicit; ]
    [ recursion yes_or_no; ]
    [ rfc2308-type1 yes_or_no; ]
    [ use-id-pool yes_or_no; ]
    [ maintain-ixfr-base yes_or_no; ]
    [ forward ( only | first ); ]
    [ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ;  ... ] }; ]
    [ check-names ( master | slave |  response )( warn | fail | ignore ); ]
    [ allow-notify { address_match_list }; ]
    [ allow-query { address_match_list }; ]
    [ allow-transfer { address_match_list }; ]
    [ allow-recursion { address_match_list }; ]
    [ allow-v6-synthesis { address_match_list }; ]
    [ blackhole { address_match_list }; ]
    [ listen-on [ port ip_port ] { address_match_list }; ]
    [ listen-on-v6 [ port ip_port ] { address_match_list }; ]
    [ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ];  ]
    [ query-source-v6 [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ];  ]
    [ max-transfer-time-in number; ]
    [ max-transfer-time-out number; ]
    [ max-transfer-idle-in number; ]
    [ max-transfer-idle-out number; ]
    [ tcp-clients number; ]
    [ recursive-clients number; ]
    [ serial-query-rate number; ]
    [ serial-queries number; ]
    [ transfer-format ( one-answer | many-answers ); ]
    [ transfers-in  number; ]
    [ transfers-out number; ]
    [ transfers-per-ns number; ]
    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
    [ notify-source (ip4_addr | *) [port ip_port] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ;  ... ] }; ]
    [ max-ixfr-log-size number; ]
    [ 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 ; ... ] ] };
    [ lame-ttl number; ]
    [ max-ncache-ttl number; ]
    [ max-cache-ttl number; ]
    [ sig-validity-interval number ; ]
    [ min-roots number; ]
    [ use-ixfr yes_or_no ; ]
    [ treat-cr-as-space yes_or_no ; ]
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ port ip_port; ]
    [ additional-from-auth yes_or_no ; ]
    [ additional-from-cache yes_or_no ; ]
    [ random-device path_name ; ]
    [ max-cache-size size_spec ; ]
    [ match-mapped-addresses yes_or_no; ]
};

Table 6-6 through Table 6-14 describe the BIND server configuration options.

"
client specified part" + "
tkey-domain"

"
random hex digits" + "
tkey-domain"