|
|
HP-UX Reference > Nnamed.conf(4)HP-UX 11i Version 2: December 2007 Update |
|
NAMEnamed.conf — configuration file for NameDaemon DESCRIPTIONBIND 9 configuration is broadly similar to BIND 8.x. However, there are a few new areas of configuration, such as views. BIND 8.x configuration files should work with few alterations in BIND 9.2, although more complex configurations need to be reviewed to check if they can be more efficiently implemented using the new features implemented in BIND 9.2. BIND 4.9.7 configuration files can be converted to the BIND 9.2 format using the shell script, /usr/bin/named-bootconf.sh. Configuration File ElementsThe following configuration elements are used in BIND 9.2 configuration file documentation:
Address Match Lists Syntaxaddress_match_list3D address_match_list_element ; [ address_match_list_element; ... ] address_match_list_element3D [ ! ] (ip_address [/length] | key key_id | acl_name | { address_match_list } ) Address Match Lists Definition and UsageAddress match lists are primarily used to determine access control for various server operations. They are also used to define priorities for querying other nameservers and to set the addresses on which named will listen for queries. The elements which constitute an address match list may be any of the following:
Elements can be negated with a leading exclamation mark (!). The match list names of any, none, localhost, and localnets are predefined. For more information on these match list names, refer to the acl statement section. The addition of the key clause made the name of this syntactic element something of a misnomer, since security keys can be used to validate access without regard to a host or network address. However, the term "address match list" is still being used. When a given IP address or prefix is compared to an address match list, the list is traversed in order until an element matches. The interpretation of a match depends on whether the list is being used for access control, defining listen-on ports and whether the element was negated. When used as an access control list, a non-negated match allows access and a negated match denies access. If there is no match, access is denied. The clauses allow-notify, allow-query, allow-transfer, allow-update, and blackhole which can be specified in the options and/or zone use the address match lists. Similarly, the listen-on option causes the server not to accept queries on any of the machine's addresses which do not match the list. Because of the first-match aspect of the algorithm, an element that defines a subset of another element in the list should come before the broader element, regardless of whether either is negated. For example, in 1.2.3/24; ! 1.2.3.13; the 1.2.3.13 element is not of any use because the algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 element. Using ! 1.2.3.13; 1.2.3/24 fixes that problem by having 1.2.3.13 blocked by the negation but all other 1.2.3.* hosts fall through. Comment SyntaxComments in BIND 9.2 configuration file can be written in C, C++, or shell/perl constructs. WARNING: Unlike a zone file, you cannot use semicolon (;) character to start a comment in the BIND 9.2 configuration file. The semicolon indicates the end of a configuration statement. Configuration File GrammarA BIND 9.2 configuration file consists of statements and comments. Statements end with a semicolon. Statements and comments are the only elements that can appear without enclosing braces. Many statements contain a block of substatements, which are terminated with a semicolon. The following statements are supported:
The logging and options statements may occur only once per configuration. acl Statement Definition and UsageThe acl statement assigns a symbolic name to an address match list. It gets its name from the primary use of address match lists: "Access Control Lists" (ACLs). Note that an address match list's name must be defined with acl before it can be used elsewhere; no forward references are allowed. The following ACLs are built-in:
The localhost and localnets ACLs do not currently support IPv6 (i.e., localhost does not match the host's IPv6 addresses, and localnets does not match the host's attached IPv6 networks) due to the lack of a standard method of determining the complete set of local IPv6 addresses for a host. controls Statement Grammarcontrols { inet (ip_addr| * ) [port ip_port] allow { address_match_list } keys { key_list }; [ inet ...; ] }; controls Statement Definition and UsageThe controls statement declares control channels to be used by system administrators to affect the operation of the local nameserver. These control channels are used by the rndc utility to send commands to and retrieve non-DNS results from a nameserver. An inet control channel is a TCP/IP socket accessible to the Internet, created at the specified ip_port on the specified ip_addr. If no port is specified, port 953 is used by default. * cannot be used for ip_port. 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 address_match_list. key_id members of the address_match_list are ignored, and instead are interpreted independently based on the key_list. Each key_id in the key_list is allowed to be used to authenticate commands and responses given over the control channel by digitally signing each message between the server and a command client. All commands to the control channel must be signed by one of its specified keys to be honored. If no controls statement is present, named 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, named will attempt to load the command channel key from the file rndc.key in /etc. To create a rndc.key file, run rndc-confgen -a. The rndc.key feature was implemented to ease the transition of systems from BIND 8, which did not have digital signatures on its command channel messages and thus did not have a keys clause. Since the rndc.key feature is only intended to allow the backward-compatible usage of BIND 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, so you should make a rndc.conf with your own key if you wish to change them. The rndc.key file also has its permissions set such that only the owner of the file (the user that named is running as) can access it. If you desire greater flexibility in allowing other users to access rndc commands, then you need to create an rndc.conf and make it group-readable by a group that contains the users who should have access. The UNIX control channel type of BIND 8 is not supported in BIND 9.2, and is not expected to be added in future releases. If it is present in the controls statement from a BIND 8 configuration file, it is ignored and a warning is logged. include Statement Definition and UsageThe include statement inserts the specified file at the point where 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 nameserver. key Statement Definition and UsageThe key statement defines a shared secret key for use with TSIG. 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. The key_id, also known as the key name, is a domain name uniquely identifying the key. It can be used in a server statement to sign requests 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. The algorithm_id is a string that specifies a security/authentication algorithm. "hmac-md5" is the only algorithm which is currently supported with TSIG authentication. The secret_string is a base-64 encoded secret string to be used by the algorithm. logging Statement Grammarlogging { [ channel channel_name { ( file path name [ versions ( number | unlimited ) ] [ size size spec ] | syslog syslog_facility | 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 ; ... ] }; ] ... }; logging Statement Definition and UsageThe logging statement configures a wide variety of logging options for the nameserver. Its channel phrase associates output methods, format options and severity levels with a name that can be used with the category phrase to select how various classes of messages are logged. Only one logging statement is used to define any number of channels and categories. If there is no logging statement, the logging configuration will be: logging { category "unmatched" { "null"; }; category "default" { "default_syslog"; "default_debug"; }; }; In BIND 9.2, the logging configuration is established only when the entire configuration file has been parsed. In BIND 8, it was established as soon as the logging statement was parsed. When the server starts up, all logging messages related to syntax errors in the configuration file go to the default channels, or to standard error if the -g option was specified. The channel PhraseAll log output goes to one or more user defined or pre-defined channels; Every channel definition must include a destination clause that says whether messages selected for the channel go to a file, or to a particular syslog facility, or to the standard error stream, or are discarded. It can optionally also limit the message severity level that will be accepted by the channel (the default is info) , and whether to include a named-generated time stamp, the category name and/or severity level (the default is not to include any). The channel options are irrelevant when the null destination clause discards all messages sent to the channel. The file destination clause directs the channel to a disk file. It can include limitations both on file size limit and number of versions of the file, saved each time the file is opened. If you use the versions log file option, then named will retain that many backup versions of the file by renaming them when opening. For example, if you choose to keep three old versions of the file lamers.log, then just before it is opened:
Use versions unlimited; if you do not want to limit the number of versions. If a size option is associated with the log file, then renaming is only done when the file being opened exceeds the indicated size. No backup versions are kept by default; any existing log file is simply appended. The size option for files is used to limit log growth. If the file size exceeds the limit, then named will stop writing to the file unless it has a versions option associated with it. If backup versions are kept, the files are rolled as described above and a new file is opened. If there is no versions option, no more data will be written to the log until the log file is removed or truncated to less than the maximum size. The default behavior is not to limit the size of the file. Example usage of the size and versions options: channel "an_example_channel" { file "example.log" versions 3 size 20m; print-time yes; print-category yes; }; The syslog destination clause directs the channel to the system log. Its argument is a syslog facility as described in the syslog(3C) man page. The syslog(3C) man page describes how syslog will handle messages sent to this facility. If you have a system which uses a very old version of syslog that uses only two arguments to the openlog() function, then syslog destination clause is ignored. The severity clause works like syslog's "priorities", except that they can also be used if you are writing straight to a file rather than using syslog. Messages which are not at least of the severity level given will not be selected for the channel; messages of higher severity levels will be accepted. If you are using syslog, then the syslog.conf priorities will also determine what eventually passes through. For example, defining a channel facility and severity as daemon and debug but only logging daemon.warning via syslog.conf will cause messages of severity info and notice to be dropped. If the situation were reversed, with named writing messages of only warning or higher, then syslogd would print all messages it received from the channel. The stderr destination clause directs the channel to the server's standard error stream. This is intended for use when the server is running as a foreground process, for example when debugging the configuration. 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 will be active. The global debug level is set either by starting the named server with the -d flag followed by a positive integer, or by running rndc trace. The global debug level can be set to zero, and debugging mode turned off, by running rndc notrace. All debugging messages in the server have a debug level, and higher debug levels give more detailed output. For example: channel "specific_debug_level" { file "foo"; severity debug 3; }; In the above example, channels that specify a particular debug severity will get debugging output of level 3 or less any time the server is in debugging mode, regardless of the global debugging level. Channels with dynamic severity use the server's global level to determine what messages to print. If print-time has been turned on, then the date and time will be logged. print-time may be specified for a syslog channel, but is usually pointless since syslog also prints the date and time. If print-category is requested, then the category of the message will be logged as well. Finally, if print-severity is ON, then the severity level of the message will be logged. The print- options may be used in any combination, and will always be printed in the order: time, category, severity. Here is an example where all three print- options are ON: 28-Feb-2000 15:05:32.863 general: notice: running There are four pre-defined channels that are used for named's default logging as follows: channel "default_syslog" { syslog daemon; // send to syslog's daemon // facility severity info; // only send priority info // and higher }; channel "default_debug" { file "named.run"; // write to named.run in // the working directory // Note: stderr is used instead // of "named.run" // if the server is started // with the '-f' option. severity dynamic; // log at the server's // current debug level }; channel "default_stderr" { // writes to stderr stderr; severity info; // only send priority info // and higher }; channel "null" { null; // toss anything sent to // this channel }; The default_debug channel has the special property that it only produces output when the server's debug level is a non-zero value. It normally writes to a file named.run in the server's working directory. For security reasons, when the -u command line option is used, the named.run file is created only after named has changed to the new UID, and any debug output is generated while named is starting up and still running as root is discarded. If you need to capture this output, you must run the server with the -g option and redirect standard error to a 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. The category PhrasePre-defined categories allow the administrator to fine-tune what messages they want to log and where they want to log those messages to. If a list of channels is not specified for a category, then log messages in that category will be sent to the default category instead. If you do not specify a default category, the following category is used: category "default" { "default_syslog"; "default_debug"; }; For example, if you want to log security events to a file and also wish to keep the default logging behavior, you need to 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 as follows: category "xfer-out" { "null"; }; category "notify" { "null"; }; Following are the available categories and brief descriptions of the types of log information they contain. More categories may be added in future BIND releases.
lwres Statement GrammarThis is the grammar of the lwres statement in the named.conf file: lwres { [ listen-on { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ] [ view view_name; ] [ search { domain_name ; [ domain_name ; ... ] }; ] [ ndots number; ] }; lwres Statement Definition and UsageThe lwres statement configures the name server to also act as a lightweight resolver server. There may be be multiple lwres statements configuring lightweight resolver servers with different properties. The listen-on statement specifies a list of addresses and ports that a lightweight resolver daemon should accept requests on. If no port is specified, port 921 is used. If this statement is omitted, requests will be accepted on 127.0.0.1, port 921. The view statement binds this instance of a lightweight resolver daemon to a view in the DNS namespace, so that the response will be constructed in the same manner as a normal DNS query matching this view. If this statement is omitted, the default view is used, and if there is no default view, an error is triggered. The search statement is equivalent to the search statement in /etc/resolv.conf. It provides a list of domains which are appended to relative names in queries. The ndots statement is equivalent to the ndots statement in /etc/resolv.conf. It indicates the minimum number of dots in a relative domain name that should result in an exact match lookup before search path elements are appended. options Statement GrammarThis is the grammar of the options statement in the named.conf file: options { [ version version_string; ] [ directory path_name; ] [ tkey-domain domainname; ] [ tkey-dhkey key_name key_tag; ] [ dump-file path_name; ] [ pid-file path_name; ] [ statistics-file path_name; ] [ zone-statistics yes_or_no; ] [ auth-nxdomain yes_or_no; ] [ dialup dialup_option; ] [ minimal-responses yes_or_no; ] [ notify yes_or_no | explicit; ] [ recursion yes_or_no; ] [ forward ( only | first ); ] [ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ] [ 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 | * ) ]; ] [ 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; ] [ 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] ; ... ] }; ] [ coresize size_spec ; ] [ datasize size_spec ; ] [ files size_spec ; ] [ stacksize size_spec ; ] [ cleaning-interval number; ] [ heartbeat-interval number; ] [ interface-interval number; ] [ sortlist { address_match_list }]; [ lame-ttl number; ] [ max-ncache-ttl number; ] [ max-cache-ttl number; ] [ sig-validity-interval number ; ] [ use-ixfr yes_or_no ; ] [ provide-ixfr yes_or_no; ] [ request-ixfr 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; ] [ edns yes_or_no; ] }; options Statement Definition and UsageThe options statement sets up global options to be used by BIND. This statement may 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 will be generated. If there is no options statement, an options block with each option set to its default will be used.
Boolean Options
ForwardingThe forwarding facility can be used to create a large site-wide cache on a few servers, reducing traffic over links to external nameservers. It can also be used to allow queries by servers that do not have direct access to the Internet, but wish to look up exterior names anyway. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache.
Access ControlAccess to the server can be restricted based on the IP address of the requesting system.
InterfacesThe interfaces and ports that the server will answer queries from, may be specified using the listen-on option. listen-on takes an optional port, and an address_match_list The server will listen on all interfaces allowed by the address match list. If a port is not specified, port 53 will be used. Multiple listen-on statements are allowed. For example, listen-on { 5.6.7.8; }; listen-on port 1234 { !1.2.3.4; 1.2/16; }; will enable the nameserver on port 53 for the IP address 5.6.7.8, and on port 1234 of an address on the machine in net 1.2 that is not 1.2.3.4. If no listen-on is specified, the server will listen on port 53 on all interfaces. The listen-on-v6 option is used to specify the ports on which the server will listen for incoming queries sent using IPv6. The server does not bind a separate socket to each IPv6 interface address as it does for IPv4. Instead, it always listens on the IPv6 wildcard address. Therefore, the only values allowed for the address_match_list argument to the listen-on-v6 statement are: { any; } and { none;} Multiple listen-on-v6 options can be used to listen on multiple ports: listen-on-v6 port 53 { any; }; listen-on-v6 port 1234 { any; }; To make the server not to listen on any IPv6 address, use listen-on-v6 { none; }; If no listen-on-v6 statement is specified, the server will not listen on any IPv6 address. Query AddressIf the server is unable to answer a question, it will query other nameservers. query-source specifies the address and port used for such queries. For queries sent over IPv6, there is a separate query-source-v6 option. If address is * or is omitted, a wildcard IP address (INADDR_ANY) will be used. If port is * or is omitted, a random unprivileged port will be used. Default address and port are: query-source address * port *; query-source-v6 address * port * Note: The address specified in the query-source option is used for both UDP and TCP queries, but the port applies only to UDP queries. TCP queries always use a random unprivileged port. Zone TransfersBIND has mechanisms in place to facilitate zone transfers and set limits on the amount of load that transfers place on the system. The following options apply to zone transfers.
Operating System Resource LimitsThe server's usage of many system resources can be limited. Scaled values are allowed when specifying resource limits. For example, 1G can be used instead of 1073741824 to specify a limit of one gigabyte. An "unlimited_size_spec" requests unlimited use, or the maximum available amount. The default uses the limit that was in force when the server was started. The following options set operating system resource limits for the name server process. A warning will be issued if the unsupported limit is used.
Server Resource LimitsThe following options set limits on the server's resource consumption that are enforced internally by the server rather than the operating system.
Periodic Task Intervals
The sortlist StatementThe response to a DNS query may consist of multiple resource records (RRs) forming a resource records set (RRset). The name server will normally return the RRs within the RRset in an indeterminate order. The client resolver code should rearrange the RRs as appropriate, i.e., using any addresses on the local net in preference to other addresses. However, not all resolvers can do this or are correctly configured. When a client is using a local server the sorting can be performed in the server, based on the client's address. This only requires configuring the nameservers, not all the clients. The sortlist statement (refer to the sortlist section below) takes an address_match_list and interprets it. Each top level statement in the sortlist must itself be an explicit address_match_list with one or two elements. The first element (which may be an IP address, an IP prefix, an ACL name or a nested address_match_list) of each top level list is checked against the source address of the query until a match is found. Once the source address of the query has been matched, if the top level statement contains only one element, the actual primitive element that matched the source address is used to select the address in the response to move to the beginning of the response. If the statement is a list of two elements, then the second element is interpreted in a special way. Each top level element is assigned a distance and the address in the response with the minimum distance is moved to the beginning of the response. In the following example, any queries received from any of the addresses of the host itself will get responses preferring addresses on any of the locally connected networks. Next will be addresses on the 192.168.1/24 network, and after that either the 192.168.2/24 or 192.168.3/24 network with no preference shown between these two networks. Queries received from a host on the 192.168.1/24 network will prefer other addresses on that network to the 192.168.2/24 and 192.168.3/24 networks. Queries received from a host on the 192.168.4/24 or the 192.168.5/24 network will only prefer other addresses on their directly connected networks. sortlist { { localhost; // IF the local host { localnets; // THEN first fit on the 192.168.1/24; // following nets { 192.168.2/24; 192.168.3/24; }; }; }; { 192.168.1/24; // IF on class C 192.168.1 { 192.168.1/24; // THEN use .1, or .2 or .3 { 192.168.2/24; 192.168.3/24; }; }; }; { 192.168.2/24; // IF on class C 192.168.2 { 192.168.2/24; // THEN use .2, or .1 or .3 { 192.168.1/24; 192.168.3/24; }; }; }; { 192.168.3/24; // IF on class C 192.168.3 { 192.168.3/24; // THEN use .3, or .1 or .2 { 192.168.1/24; 192.168.2/24; }; }; }; { { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net }; }; The following example will give reasonable behavior for the local host and hosts on directly connected networks. It is similar to the behavior of the address sort in BIND 4.9.x. Responses sent to queries from the local host will favor any of the directly connected networks. Responses sent to queries from any other hosts on a directly connected network will prefer addresses on that same network. Responses to other queries will not be sorted. sortlist { { localhost; localnets; }; { localnets; }; }; Synthetic IPv6 ResponsesMany existing stub resolvers support IPv6 DNS lookups as defined in RFC1886, using AAAA records for forward lookups and nibble labels in the ip6.int domain for reverse lookups, but do not support RFC2874-style lookups (using A6 records and binary labels in the ip6.arpa domain). For those who wish to continue to use such stub resolvers rather than switching to the BIND 9.2 lightweight resolver, BIND 9.2 provides a way to automatically convert RFC1886-style lookups into RFC2874-style lookups and return the results as "synthetic" AAAA and PTR records. This feature is disabled by default and can be enabled on a per-client basis by adding a allow-v6-synthesis { address_match_list }; clause to the options or view statement. When it is enabled, recursive AAAA queries cause the server to first try an A6 lookup and if that fails, it tries an AAAA lookup. No matter which one succeeds, the results are returned as a set of synthetic AAAA records. Similarly, recursive PTR queries in ip6.int will cause a lookup in ip6.arpa using binary labels, and if that fails, another lookup in ip6.int. The results are returned as a synthetic PTR record in ip6.int. The synthetic records have a TTL of zero. DNSSEC validation of synthetic responses is not currently supported; therefore responses containing synthetic RRs will not have the AD flag set. Tuning
The Statistics FileThe statistics file generated by BIND 9.2 is similar, but not identical, to that generated by BIND 8. The statistics dump begins with the line +++ Statistics Dump +++ (973798949), where the number in parentheses is a standard Unix-style timestamp, measured as seconds since January 1, 1970. Following that line are a series of lines containing a counter type, the value of the counter, optionally a zone name, and optionally a view name. The lines without view and zone listed are global statistics for the entire server. Lines with a zone and view name for the given view and zone (the view name is omitted for the default view). The statistics dump ends with the line --- Statistics Dump --- (973798949), where the number is identical to the number in the beginning line. The following statistics counters are maintained:
server Statement Grammarserver ip_addr { [ bogus yes_or_no ; ] [ provide-ixfr yes_or_no ; ] [ request-ixfr yes_or_no ; ] [ edns yes_or_no ; ] [ transfers number ; ] [ transfer-format ( one-answer | many-answers ) ; ]] [ keys { string ; [ string ; [...]] } ; ] }; server Statement Definition and UsageThe server statement defines characteristics to be associated with a remote nameserver. The server statement can occur at the top level of the configuration file or inside a view statement. If a view statement contains one or more server statements, only those apply to the view and any top-level ones are ignored. If a view contains no server statements, any top-level server statements are used as defaults. If you discover that a remote server is giving out bad data, marking it as "bogus" will prevent further queries to it. Default value of bogus is "no". The provide-ixfr clause determines whether the local server, acting as master, will respond with an incremental zone transfer when the given remote server, a slave, requests it. If set to "yes", incremental transfer will be provided whenever possible. If set to "no", all transfers to the remote server will be nonincremental. If not set, the value of the provide-ixfr option in the view or global options block is used as a default. The request-ixfr clause determines whether the local server, acting as a slave, will request incremental zone transfers from the given remote server, a master. If not set, the value of the request-ixfr option in the view or global options block is used as a default. IXFR requests to servers that do not support IXFR will automatically fall back to AXFR. Therefore, there is no need to manually list which servers support IXFR and which ones do not; the global default of yes should always work. The purpose of the provide-ixfr and request-ixfr clauses is to make it possible to disable the use of IXFR even when both master and slave claim to support it, for example if one of the servers is defective and crashes or corrupts data when IXFR is used. The edns (Extended DNS) clause determines whether the local server will attempt to use EDNS when communicating with the remote server. Default is "yes". The server supports two zone transfer methods. The first, one-answer, uses one DNS message per resource record transferred. many-answers packs as many resource records as possible into a message. many-answers is more efficient, but is only known to be understood by BIND 9, BIND 8.x, and patched versions of BIND 4.9.5. You can specify which method to use for a server with the transfer-format option. If transfer-format is not specified, the transfer-format specified by the options statement will be used. The transfers clause is used to limit the number of concurrent inbound zone transfers from the specified server. If no transfers clause is specified, the limit is set according to the transfers-per-ns option. The keys clause is used to identify a key_id defined by the key statement, to be used for transaction security when talking to the remote server. The key statement must come before the server statement that references it. When a request is sent to the remote server, a request signature will be generated using the key specified here and appended to the message. A request originating from the remote server is not required to be signed by this key. Although the grammar of the keys clause allows for multiple keys, only a single key per server is currently supported. trusted-keys Statement Grammartrusted-keys { string number number number string ; [ string number number number string ; [...]] }; trusted-keys Statement Definition and UsageThe trusted-keys statement defines DNSSEC security roots. A security root is defined when the public key for a non-authoritative zone is known, but cannot be securely obtained through DNS, either because it is the DNS root zone or its parent zone is unsigned. Once a key has been configured as a trusted key, it is treated as if it had been validated and proven secure. The resolver attempts DNSSEC validation on all DNS data in subdomains of a security root. The trusted-keys statement can contain multiple key entries, each consisting of the key's domain name, flags, protocol, algorithm, and the base-64 representation of the key data. view Statement Grammarview view_name [class] { match-clients { address_match_list } ; match-destinations { address_match_list } ; match-recursive-only { yes_or_no } ; [ view_option; ...] [ zone-statistics yes_or_no ; ] [ zone_statement; ...] }; view Statement Definition and UsageThe view statement lets a name server answer a DNS query differently depending on who is asking. It is particularly useful for implementing split DNS setups without having to run multiple servers. Each view statement defines a view of the DNS namespace that will be seen by a subset of clients. A client matches a view if its source IP address matches the address_match_list of the view's match-clients clause and its destination IP address matches the address_match_list of the view's match-destinations clause. If not specified, both match-clients and match-destinations default to matching all addresses. A view can also be specified as match-recursive-only, which means that only recursive requests from matching clients will match that view. The order of the view statements is significant - a client request will be resolved in the context of the first view that it matches. Zones defined within a view statement will only be accessible to clients that match the view. By defining a zone of the same name in multiple views, different zone data can be given to different clients, for example, "internal" and "external" clients in a split DNS setup. Many of the options given in the options statement can also be used within a view statement, and then apply only when resolving queries with that view. When no view-specific value is given, the value in the options statement is used as a default. Also, zone options can have default values specified in the view statement; these view-specific defaults take precedence over those in the options statement. Views are class-specific. If no class is given, class IN is assumed. Note that all non-IN views must contain a hint zone, since only the IN class has compiled-in default hints. If there are no view statements in the config file, a default view that matches any client is automatically created in class IN, and any zone statements specified on the top level of the configuration file are considered to be part of this default view. If any explicit view statements are present, all zone statements must occur inside view statements. Here is an example of a typical split DNS setup implemented using view statements. view "internal" { // This should match our internal networks. match-clients { 10.0.0.0/8; }; // Provide recursive service to internal clients only. recursion yes; // Provide a complete view of the example.com zone // including addresses of internal hosts. zone "example.com" { type master; file "example-internal.db"; }; }; view "external" { match-clients { any; }; // Refuse recursive service to external clients. recursion no; // Provide a restricted view of the example.com zone // containing only publicly accessible hosts. zone "example.com" { type master; file "example-external.db"; }; }; zone Statement Grammarzone zone_name [class] [{ type ( master | slave | hint | stub | forward ) ; [ allow-notify { address_match_list } ; ] [ allow-query { address_match_list } ; ] [ allow-transfer { address_match_list } ; ] [ allow-update { address_match_list } ; ] [ update-policy { update_policy_rule [...] } ; ] [ allow-update-forwarding { address_match_list } ; ] [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ] [ dialup dialup_option ; ] [ file string ; ] [ forward (only|first) ; ] [ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ] [ masters [port ip_port] { ip_addr [port ip_port] [key key]; [...] } ; ] [ max-transfer-idle-in number ; ] [ max-transfer-idle-out number ; ] [ max-transfer-time-in number ; ] [ max-transfer-time-out number ; ] [ notify yes_or_no | explicit ; ] [ 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] ; ] [ zone-statistics yes_or_no ; ] [ sig-validity-interval number ; ] [ database string ; ] [ min-refresh-time number ; ] [ max-refresh-time number ; ] [ min-retry-time number ; ] [ max-retry-time number ; ] }]; zone Statement Definition and UsageZone Types
ClassThe zone's name may optionally be followed by a class. If a class is not specified, class IN (for Internet), is assumed. This is correct for the vast majority of cases. The "hesiod" class is named for an information service from MIT's Project Athena. It is used to share information about various systems databases, such as users, groups, printers and so on. The keyword HS is a synonym for hesiod. Another MIT development is CHAOSnet, a LAN protocol created in the mid-1970s. Zone data for it can be specified with the CHAOS class. Zone Options
Dynamic Update PoliciesBIND 9.2 supports two alternative methods of granting clients, the right to perform dynamic updates to a zone, configured by the allow-update and update-policy option, respectively. The allow-update clause works the same way as in previous versions of BIND. It grants given clients the permission to update any record of any name in the zone. The update-policy clause is new in BIND 9.2 and allows more fine-grained control over what updates are allowed. A set of rules is specified, where each rule either grants or denies permissions for one or more names to be updated by one or more identities. If the dynamic update request message is signed (that is, it includes either a TSIG or SIG(0) record), the identity of the signer can be determined. Rules are specified in the update-policy zone option, and are only meaningful for master zones. When the update-policy statement is present, it is a configuration error for the allow-update statement to be present. The update-policy statement only examines the signer of a message; the source address is not relevant. A sample rule definition is as shown below: ( grant | deny ) identity nametype name [ types ] Each rule grants or denies privileges. Once a message has successfully matched a rule, the operation is immediately granted or denied and no further rules are examined. A rule is matched when the signer matches the identity field, the name matches the name field, and the type is specified in the type field. The identity field specifies a name or a wildcard name. The nametype field has four values: name, subdomain, wildcard, and self:
If no types are specified, the rule matches all types except SIG, NS, SOA, and NXT. Types may be specified by name, including "ANY" (ANY matches all types except NXT, which can never be updated). Zone FileTypes of Resource Records and When to Use Them: This section describes the concept of a Resource Record (RR) and explains when each is used as per RFC 1034. Resource RecordsA domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate RRs. The order of RRs in a set is not significant and need not be preserved by nameservers, resolvers, or other parts of the DNS. However, sorting of multiple RRs is permitted for optimization purposes, for example, to specify that a particular nearby server be tried first. The components of a Resource Record are:
The following are the types of valid RRs (some of these listed, although not obsolete, are experimental (x) or historical (h) and no longer in general use):
The following classes of resource records are currently valid in the DNS:
The owner name is often implicit, rather than forming an integral part of the RR. For example, many nameservers internally form tree or hash structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, class, TTL) which is consistent for all RRs, and a variable part (RDATA) that fits the needs of the resource being described. The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change. The data in the RDATA section of RRs is carried as a combination of binary strings and domain names. The domain names are frequently used as "pointers" to other data in the DNS. Textual Expression of RRsRRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a nameserver or resolver. In the examples provided in RFC 1034, a style similar to that used in master files was employed in order to show the contents of RRs. In this format, most RRs are shown on a single line, although continuation lines are possible using parentheses. The start of the line gives the owner of the RR. If a line begins with a blank, then the owner is assumed to be the same as that of the previous RR. Blank lines are often included for readability. Following the owner, we list the TTL, type, and class of the RR. Class and type use the mnemonics defined above, and TTL is an integer before the type field. In order to avoid ambiguity in parsing, type and class mnemonics are disjoint, TTLs are integers, and the type mnemonic is always last. The IN class and TTL values are often omitted from examples in the interests of clarity. The resource data or RDATA section of the RR are given using knowledge of the typical representation for the data. For example, RRs carried in a message can be shown as: ISI.EDU.MX10 VENERA.ISI.EDU. MX10 VAXA.ISI.EDU VENERA.ISI.EDUA128.9.0.32 A10.1.0.52 VAXA.ISI.EDUA10.2.0.27 A128.9.0.33 The MX RRs have an RDATA section which consists of a 16 bit number followed by a domain name. The address RRs use a standard IP address format to contain a 32 bit internet address. This example shows six RRs, with two RRs at each of three domain names. Similarly RRs may also be shown as: XX.LCS.MIT.EDU. INA10.0.0.44 CHAMIT.EDU. 2420 This example shows two addresses for XX.LCS.MIT.EDU, each of a different class. MX RecordsAs described above, domain servers store information as a series of resource records, each of which contains a particular piece of information about a given domain name (which is usually, but not always, a host). The simplest way to think of a RR is as a typed pair of datum, a domain name matched with relevant data, and stored with some additional type information to help systems determine when the RR is relevant. MX records are used to control delivery of e-mail. The data specified in the record is a priority and a domain name. The priority controls the order in which email delivery is attempted, with the lowest number first. If two priorities are the same, a server is chosen randomly. If no servers at a given priority are responding, the mail transport agent will fall back to the next largest priority. Priority numbers do not have any absolute meaning - they are relevant only respective to other MX records for that domain name. The domain name given is the machine to which the mail will be delivered. It must have an associated A record - CNAME is not sufficient. For a given domain, if there is both a CNAME record and an MX record, the MX record is in error, and will be ignored. Instead, the mail will be delivered to the server specified in the MX record pointed to by the CNAME. example.com.INMX10mail.example.com. INMX10mail2.example.com. INMX20mail.backup.org. mail.example.com.INA10.0.0.1 mail2.example.com.INA10.0.0.2 For example: Mail delivery will be attempted to mail.example.com and mail2.example.com (in any order), and if neither of those succeed, delivery to mail.backup.org will be attempted. Setting TTLsThe TTL of the RR field is a 32-bit integer represented in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded. The following three types of TTL are currently used in a zone file.
All of these TTLs default to units of seconds, though units can be explicitly specified, for example, 1h30m. Inverse Mapping in IPv4Reverse name resolution (that is, translation from IP address to name) is achieved by means of the in-addr.arpa domain and PTR records. Entries in the in-addr.arpa domain are made in least-to-most significant order, read left to right. This is the opposite order to the way IP addresses are usually written. Thus, a machine with an IP address of 10.1.2.3 would have a corresponding in-addr.arpa name of 3.2.1.10.in-addr.arpa. This name should have a PTR resource record whose data field is the name of the machine or, optionally, multiple PTR records if the machine has more than one name. For example, in the [example.com] domain: $ORIGIN2.1.10.in-addr.arpa 3IN PTR foo.example.com. Note: The $ORIGIN lines in the examples are for providing context to the examples only-they do not necessarily appear in the actual usage. They are only used here to indicate that the example is relative to the listed origin. Other Zone File DirectivesThe Master File Format was initially defined in RFC 1035 and has subsequently been extended. While the Master File Format itself is class independent all records in a Master File must be of the same class. Master File Directives include $ORIGIN, $INCLUDE, and $TTL. The $ORIGIN DirectiveSyntax:
$ORIGIN sets the domain name that will be appended to any unqualified records. When a zone is first read in there is an implicit $ORIGIN zone-name. The current $ORIGIN is appended to the domain specified in the $ORIGIN argument if it is not absolute. $ORIGIN example.com. WWW CNAME MAIN-SERVER is equivalent to WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. The $INCLUDE DirectiveSyntax:
Read and process the file filename as if it were included into the file at this point. If origin is specified the file is processed with $ORIGIN set to that value, otherwise the current $ORIGIN is used. The origin and the current domain name revert to the values they had prior to the $INCLUDE once the file has been read. Note: RFC 1035 specifies that the current origin should be restored after an $INCLUDE, but it is silent on whether the current domain name should also be restored. BIND 9 restores both of them. This could be construed as a deviation from RFC 1035, a feature, or both. The $TTL DirectiveSyntax:
Set the default Time To Live (TTL) for subsequent records with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds. $TTL is defined in RFC 2308. BIND Master File Extension: the $GENERATE DirectiveSyntax:
$GENERATE is used to create a series of resource records that only differ from each other by an iterator. $GENERATE can be used to easily generate the sets of records required to support sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA delegation. $ORIGIN 0.0.192.IN-ADDR.ARPA. $GENERATE 1-2 0 NS SERVER$.EXAMPLE. $GENERATE 1-127 $ CNAME $.0 is equivalent to 0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE. 0.0.0.192.IN-ADDR.ARPA NS SERVER2.EXAMPLE. 1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA 2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA ... 127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA .
The $GENERATE directive is a BIND extension and not part of the standard zone file format. WARNINGSIPv6 is supported on HP-UX 11i Version 1.0, with the optional IPv6 software installed. Currently, IPv6 is not supported on systems running HP-UX 11i Version 1.6. SEE ALSOkill(1), hosts_to_named(1M), sig_named(1M), signal(2), gethostent(3N), resolver(3N), resolver(4), hostname(5), RFC 882, RFC 883, RFC 973, RFC 974, RFC 1032, RFC 1033, RFC 1034, RFC 1035, RFC 1123. |
|