HP TCP/IP Services for OpenVMS
Management


Previous Contents Index

6.5.3.7.6 The Query Address Options

If the server does not know the answer to a question, it queries other name servers. The query address options allow you to specify the address and port for these queries.

Table 6-12 describes the query address options.

Table 6-12 Query Address Options
Option Description
query-source Specifies the IPv4 address and port used for such queries. If the address is a wildcard character or is omitted, a wildcard IP address (INADDR_ANY) is used. If the port is a wildcard character or is omitted, a random unprivileged port is used. avoid-v4-udp-ports and avoid-v6-udp-ports can be used to prevent named from selecting certain ports. The default is:
query-source address * port *;

query-source-v6 Specifies the IPv6 address and port used for such queries. The default is:
query-source-v6 address * port *

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.

6.5.3.7.7 Zone Transfer Options

BIND includes mechanisms to facilitate zone transfers and to limit the amount of load that transfers place on the system. Table 6-13 describes the zone transfer options.

Table 6-13 Zone Transfer Options
Option Description
also-notify Defines a global list of IP addresses of name servers that are also sent NOTIFY messages whenever a fresh copy of the zone is loaded, in addition to the servers listed in the zone's NS records. This helps to ensure that copies of the zones will quickly converge on stealth servers. If an also-notify list is given in a zone statement, that list overrides the also-notify options in the options statement. When a zone notify statement is set to NO, the IP addresses in the global also-notify list are not sent NOTIFY messages for that zone. The default is the empty list (no global notification list).
max-transfer-time-in Inbound zone transfers running longer than this many minutes are terminated. The default is 120 minutes (2 hours). The maximum value is 28 days (40320 minutes).
max-transfer-idle-in Inbound zone transfers making no progress in this many minutes are terminated. The default is 60 minutes. The maximum value is 28 days (40320 minutes).
max-transfer-time-out Outbound zone transfers running longer than this many minutes are terminated. The default is 120 minutes. The maximum value is 28 days (40320 minutes).
max-transfer-idle-out Outbound zone transfers making no progress in this many minutes are terminated. The default is 60 minutes. The maximum value is 28 days (40320 minutes).
alt-transfer-source An alternate transfer source if the one listed in transfer-source fails and use-alt-transfer-source is set.
alt-transfer-source-v6 An alternate transfer source if the one listed in transfer-source-v6 fails and use-alt-transfer-source is set.
use-alt-transfer-source Use the alternate transfer sources or not. If views are specified this defaults to no otherwise it defaults to yes (for BIND 8 compatibility).
serial-query-rate Slave servers periodically query master servers to find out whether zone serial numbers have changed. Each such query uses a minute amount of the slave server's network bandwidth. To limit the amount of bandwidth used, BIND 9 limits the rate at which queries are sent. The value of the serial-query-rate option is the maximum number of queries sent per second. The default is 20.
serial-queries In BIND 8, this option set the maximum number of concurrent serial number queries allowed to be outstanding at any given time. BIND 9 does not limit the number of outstanding serial queries and ignores the serial-queries option. Instead, it limits the rate at which the queries are sent as defined by the serial-query-rate option.
transfer-format Specifies whether zone transfers are sent using the one-answer format or the many-answers format. The transfer-format option is used on the master server to determine which format it sends. When set to one-answer , it uses one DNS message per resource record transferred. When set to many-answers , it packs as many resource records as possible into a message. many-answers is more efficient, but it is supported only by relatively new slave servers, such as BIND Version 9, BIND Version 8, and later versions of BIND Version 4. The default is many-answers .

The transfer-format option can be overridden on a per-server basis by using the server statement.

transfers-in Specifies the maximum number of inbound zone transfers that can be running concurrently. The default value is 10. Increasing the transfers-in value might speed up the convergence of slave zones, but it also might increase the load on the local system.
transfers-out Specifies the maximum number of outbound zone transfers that can be running concurrently. Zone transfer requests in excess of the limit are refused. The default value is 10.
transfers-per-ns Specifies the maximum number of inbound zone transfers that can be concurrently transferring from a given remote name server. The default value is 2. Increasing the value of the transfers-per-ns option might speed up the convergence of slave zones, but it also might increase the load on the remote name server. This option can be overridden on a per-server basis by using the transfers phrase of the server statement.
transfer-source Determines which local address is bound to IPv4 TCP connections used to fetch zones transferred inbound by the server. It also determines the source IPv4 address and, optionally, the UDP port used for the refresh queries and forwarded dynamic updates. If not set, this option defaults to a system-controlled value, which is usually the address of the interface closest to the remote end. This address must appear in the remote end's allow-transfer option for the zone being transferred, if one is specified. This statement sets the transfer source for all zones, but it can be overridden on a per-view or per-zone basis by including a transfer-source statement within the view or zone statement in the configuration file.
transfer-source-v6 Determines which local address is bound to IPv6 TCP connections used to fetch zones transferred inbound by the server. This is the same as the transfer-source option, except zone transfers are performed using IPv6.
notify-source Determines which local source address and, optionally, UDP port is used to send NOTIFY messages. This address must appear in the slave server's masters clause in the zone statement or in an allow-notify clause.

This statement sets the notify-source for all zones, but it can be overridden on a per-zone or per-view basis by including a notify-source statement within the zone or view statement in the configuration file.

notify-source-v6 Determines which local source address and, optionally, UDP port is used to send NOTIFY messages. This option is identical to notify-source , but it applies to NOTIFY messages sent to IPv6 addresses.

6.5.3.7.8 Bad UDP Port Lists

avoid-v4-udp-ports and avoid-v6-udp-ports specify a list of IPv4 and IPv6 UDP ports that will not be used as system assigned source ports for UDP sockets. These lists prevent the BIND server from choosing as its random source port a port that is blocked by your firewall. If a query went out with such a source port, the answer would not get by the firewall and the name server would have to query again.

6.5.3.7.9 Server Resource Limits

Table 6-14 describes options that limit the server's resource consumption and are enforced internally by the server rather than by the operating system.

Table 6-14 Server Resource Limit Options
Option Description
max-ixfr-log-size This option is obsolete; it is accepted and ignored.
max-journal-size Sets a maximum size for each journal file (see Section 6.5.7.1). When the journal file approaches the specified size, some of the oldest transactions in the journal will be automatically removed. The default is unlimited.
host-statistics-max In BIND 8, specifies the maximum number of host statistic entries to be kept. Not implemented in BIND 9.
recursive-clients Specifies the maximum number of simultaneous recursive lookups the server performs on behalf of clients. The default is 1000. Because each recursing client uses about 20 kilobytes of memory, the value of the recursive-clients option might have to be decreased on hosts with limited memory.
tcp-clients Specifies the maximum number of simultaneous client TCP connections that the server accepts. The default is 100.
max-cache-size Specifies the maximum amount of memory (in bytes) to use for the server's cache. When the amount of data in the cache reaches this limit, the server causes records to expire prematurely so that the limit is not exceeded. In a server with multiple views, the limit applies separately to the cache of each view. The default is unlimited, which means that records are purged from the cache only when their TTL (time-to-live) values expire.
tcp-listen-queue The listen queue depth. The default and minimum is 3. Values less than 3 will be silently raised.

6.5.3.7.10 Periodic Task Intervals Options

Table 6-15 describes the options that control the intervals for periodic tasks.

Table 6-15 Periodic Task Intervals Options
Option Description
cleaning-interval The server removes expired resource records from the cache every cleaning-interval minutes. The default is 60 minutes. The maximum value is 28 days (40320 minutes). If set to 0, periodic cleaning does not occur.
heartbeat-interval The server performs zone maintenance tasks for all zones marked as dialup whenever this interval expires. The default is 60 minutes.

Reasonable values are up to 1 day (1440 minutes). The maximum value is 28 days (40320 minutes). If set to 0, no zone maintenance for these zones will occur.

interface-interval The server scans the network interface list every interface-interval minutes. The default is 60 minutes.

The maximum value is 28 days (40320 minutes). If set to 0, interface scanning will only occur when the configuration file is loaded. After the scan, the server will begin listening for queries on any newly discovered interfaces (provided they are allowed by the listen-on configuration), and will stop listening on interfaces that have gone away.

statistics-interval Name server statistics are logged every statistics-interval minutes. The default is 60. The maximum value is 28 days (40320 minutes). If set to 0, no statistics will be logged.

This option is not yet implemented.

6.5.3.7.11 The TOPOLOGY Statement

When the server chooses a name server to query from a list of name servers, it prefers the one that is topologically closest to itself. The topology statement takes an address match list and interprets it in a special way. Each top-level list element is assigned a distance. Nonnegated elements get a distance based on their position in the list; the closer the match is to the start of the list, the shorter the distance between it and the server. A negated match is assigned the maximum distance from the server. If there is no match, the address gets a distance that is further than any nonnegated list element and closer than any negated element. For example:


topology { 
    10/8; 
    !1.2.3/24; 
    { 1.2/16; 3/8; }; 
}; 

The example configuration prefers servers on network 10 the most, followed by hosts on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the exception of hosts on network 1.2.3 (netmask 255.255.255.0), which is the least preferred. The default topology is:


    topology { localhost; localnets; }; 

Note

The topology statement is not implemented in BIND Version 9.

6.5.3.7.12 The SORTLIST Statement

The response to a DNS query can consist of multiple resource records (RRs) forming a resource record set (RRset). The name server normally returns the RRs within the RRset in an indeterminate order. (See Section 6.5.3.7.13.)

The client resolver code should rearrange the RRs as appropriate, that is, by using any addresses on the local network 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 requires configuring only the name servers, not all the clients.

The sortlist statement takes an address match list and interprets it even more specifically than the topology statement does (see Section 6.5.3.7.11). Each top-level statement in the sortlist must itself be an explicit address match list with one or two elements. The first element (which can 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 is 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 treated the same as the address match list in a topology statement. 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.

Example 1

In the following example, any queries received from any of the addresses of the host itself gets responses that prefer addresses on any of the locally connected networks. The next-most-preferred are 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 prefers 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 prefer only 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 
    }; 
}; 

Example 2

The following example illustrates reasonable behavior for the local host and for hosts on directly connected networks. This behavior is similar to that of the address sort in BIND Version 4. Responses sent to queries from the local host favor any of the directly connected networks. Responses sent to queries from any other hosts on a directly connected network prefer addresses on that same network. Responses to other queries are not sorted.


 
sortlist { 
           { localhost; localnets; }; 
           { localnets; }; 
}; 

6.5.3.7.13 RRset Ordering

When multiple records are returned in an answer, it might be useful to configure the order of the records placed into the response. The rrset-order statement permits configuration of the ordering of the records in a multiple-record response.

An order_spec is defined as follows:


[ class class_name ][ type type_name ][ name "domain_name"] 
 order ordering

If no class is specified, the default is ANY. If no type is specified, the default is ANY. If no name is specified, the default is wildcard.

The legal values for ordering are:

For example:


rrset-order { 
   class IN type A name "host.example.com" order random; 
   order cyclic; 
}; 

This example causes any responses for type A records in class IN that have host.example.com as a suffix to always be returned in random order. All other records are returned in cyclic order.

If multiple rrset-order statements appear, they are not combined; the last one applies.

Note

The rrset-order statement is not yet fully implemented. BIND currently does not support "fixed" ordering.

6.5.3.7.14 Tuning Options

Table 6-16 describes the options provided for tuning the BIND server.

Table 6-16 Tuning Options
Options Description
lame-ttl Sets the number of seconds to cache a lame server indication. A value of zero disables caching. (This is not recommended.) The default is 600 (10 minutes); the maximum value is 1800 (30 minutes).
max-ncache-ttl To reduce network traffic and increase performance, the server stores negative answers. The max-ncache-ttl option is used to set a maximum retention time for these answers in the server in seconds. The default is 10800 seconds (3 hours). The value of max-ncache-ttl cannot exceed 7 days and is silently truncated to 7 days if set to a greater value.
max-cache-ttl Sets the maximum time for which the server caches ordinary (positive) answers. The default is one week (7 days).
min-roots The minimum number of root servers that is required for a request for the root servers to be accepted. The default is 2.

This option is not yet implemented.

sig-validity-interval Specifies the number of days into the future when DNSSEC signatures automatically generated as a result of dynamic updates will expire. (See Section 6.5.7 for more information.) The default is 30 days. The maximum value is 10 years (3660 days). The signature inception time is unconditionally set to one hour before the current time to allow for a limited amount of clock skew.
edns-udp-size Sets the advertised EDNS UDP buffer size. Valid values are 512 to 4096 (values outside this range will be silently adjusted). The default value is 4096. The usual reason for setting edns-udp-size to a non default value it to get UDP answers to pass through broken firewalls that block fragmented packets and/or block UDP packets that are greater than 512 bytes.
min-refresh-time
max-refresh-time
min-retry-time
max-retry-time
Controls the server's behavior when refreshing a zone (querying for SOA changes) or when retrying failed transfers. Usually the SOA values for the zone are used, but these values are set by the master, giving slave server administrators little control over their contents.

These options allow the administrator to set a minimum and maximum refresh and retry time either per-zone, per-view, or globally. These options are valid for slave and stub zones, and clamp the SOA refresh and retry times to the specified values.


Previous Next Contents Index