|
HP OpenVMS Systems Documentation |
|
HP TCP/IP Services for OpenVMS
|
| Previous | Contents | Index |
The key statement defines a shared secret key for use with TSIG (see Section 6.2.3) or the command channel (see Section 6.5.3.2). 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.
| Element | Description |
|---|---|
| key_id | Specifies a domain name that uniquely identifies the key (also known as the key name). It can be used in a server statement to cause requests sent to that server to be signed with this key, or in address match lists to verify that incoming requests have been signed with a key matching this name, algorithm, and secret. |
| algorithm-id | Specifies an authentication algorithm. The only algorithm currently supported with TSIG authentication is HMAC-MD5. |
| secret-string | Specifies the secret to be used by the algorithm; treated as a Base-64 encoded string. |
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 default { default_syslog; default_debug; };
category unmatched { null; };
};
|
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:
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:
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 6.5.3.5.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.
| Category | Meaning |
|---|---|
| default | The logging options for those categories where no specific configuration has been defined. |
| general | The default category for messages that are not classified. |
| database | Messages relating to the databases used internally by the name server to store zone and cache data. |
| security | Approval and denial of requests. |
| config | Configuration file parsing and processing. |
| resolver | DNS resolution, such as the recursive lookups performed on behalf of clients by a caching name server. |
| xfer-in | Zone transfers the server is receiving. |
| xfer-out | Zone transfers the server is sending. |
| notify | The NOTIFY protocol. |
| client | Processing of client requests. |
| unmatched | Messages for which the BIND server was unable to determine the class, or for which there was no matching view. A one-line summary is also logged to the client category. |
| network | Network operations. |
| update | Dynamic updates. |
| update-security | Approval and denial of update requests. |
| queries |
Queries. Specify where queries should be logged to. At startup,
specifing the category queries will also enable query logging unless
querylog
option has been specified. The query log entry reports the client's IP
address and port number. The query name, class and type. It also
reports whether the Recursion Desired flag was set (+ if set, - if not
set), EDNS was in use (E) or if the query was signed (S).
client 127.0.0.1#62536: query: www.example.com IN AAAA +SE |
| dispatch | Dispatching of incoming packets to the server modules where they are to be processed. |
| dnssec | DNSSEC and TSIG protocol processing. |
| lame-servers | Lame servers (misconfigurations in remote servers, discovered by BIND 9 when trying to query those servers during resolution). |
| delegation-only | Delegation only. Logs queries that have been forced to NXDOMAIN as the result of a delegation-only zone or a delegation-only in a hint or stub zone declaration.File |
| queries |
Specifies where queries should be logged to. At startup, specifying the
category queries will also enable query logging unless the querylog
option has been specified. The query log entry reports the client's IP
address and port number. The query name, class and type. It also
reports whether the Recursion Desired flag was set (+ if set, - if not
set), EDNS was in use (E), or if the query was signed (S).
client 127.0.0.1#62536: query: www.example.com IN AAAA +SE |
| dispatch | Dispatching of incoming packets to the server modules where they are to be processed. |
| dnssec | DNSSEC and TSIG protocol processing. |
| lame-servers | Lame servers (misconfiguraitons in remote servers, discovered by BIND 9 when trying to query those servers during resollution). |
| delegation-only | Delegation only. Logs queries that have been forced to NXDOMAIN as the result of a delegation-only zone or a delegation-only in a hint or stub zone declaration. |
The masters statement allows for a common set of masters to be easily used by multiple stub and slave zones.
The masters statement has the following syntax:
masters name [port ip_port] { ( masters_list | ip_addr [port ip_port]
[key key] ) ; [...] } ;
|
The options statement sets up global options to be used by BIND. This statement should appear only once in a configuration file. 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; ]
[ hostname hostname_string; ]
[ server-id server_id_string; ]
[ directory path_name; ]
[ key-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; ]
[ flush-zones-on-shutdown yes_or_no; ]
[ has-old-clients yes_or_no; ]
[ host-statistics yes_or_no; ]
[ host-statistics-max number; ]
[ 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; ]
[ dnssec-enable yes_or_no; ]
[ dnssec-lookaside domain trust-anchor domain; ]
[ dnssec-must-be-secure domain yes_or_no; ]
[ forward ( only | first ); ]
[ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ]
}; ]
[ dual-stack-servers [port ip_port] { ( domain_name [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-update-forwarding { address_match_list }; ]
[ allow-v6-synthesis { address_match_list }; ]
[ blackhole { address_match_list }; ]
[ avoid-v4-udp-ports { port_list }; ]
[ avoid-v6-udp-ports { port_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; ]
[ tcp-listen-queue 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] ; ]
[ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
[ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ use-alt-transfer-source yes_or_no; ]
[ 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; ]
[ max-journal-size size_spec; ]
[ 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 ; ]
[ provide-ixfr yes_or_no; ]
[ request-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; ]
[ preferred-glue ( A | AAAA | NONE ); ]
[ edns-udp-size number; ]
[ root-delegation-only [ exclude { namelist } ] ; ]
[ querylog yes_or_no ; ]
[ disable-algorithms domain { algorithm; [ algorithm; ] }; ]
};
|
Table 6-6 through Table 6-15 describe the BIND server configuration options.
| Option | Description |
|---|---|
| version | The version the server should report using a query of name version.bind in class CHAOS. The default is the real version number of this server. |
| directory | The working directory of the server. Any nonabsolute path names in the configuration file is assumed to be relative to this directory. The default location for the server output file (TCPIP$BIND_RUN.LOG) is this directory. If a directory is not specified, the working directory defaults to SYS$SPECIFIC:[TCPIP$BIND]. If you are configuring a BIND failover environment in an OpenVMS Cluster, the working directory is defined by the logical TCPIP$BIND_COMMON. |
| key-directory | When performing dynamic update of secure zones, the directory where the public and private key files should be found, if different than the current working directory. The directory specified must be an absolute path. |
| named-xfer | This option is obsolete. It was used in BIND 8 to specify the path name to the named-xfer program. In BIND 9, no separate named-xfer program is needed; its functionality is built into the name server. |
| tkey-domain |
|