HP OpenVMS Systems Documentation

Table 6-13 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 describes the options that control the intervals for periodic tasks.

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

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.6.11.)

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.6.9). 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; };
};

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:

• fixed (Records are returned in the order they are defined in the zone file.)
• random (Records are returned in random order.)
• cyclic (Records are returned in round-robin order.)

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.

Many existing stub resolvers support IPv6 DNS lookups as defined in RFC 1886, using AAAA records for forward lookups and nibble labels in the ip6.int domain for reverse lookups. They do not support RFC 2874 lookups (using A6 records and binary labels in the ip6.arpa domain).

To continue to use such stub resolvers, BIND Version 9 provides a way to automatically convert RFC 1886 lookups into RFC 2874 lookups and to 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 the following clause to the to the options or view statement:

allow-v6-synthesis { address_match_list };

When this feature is enabled, recursive AAAA queries cause the server first to try an A6 lookup and then, if that fails, an AAAA lookup. Regardless of which one succeeds, the results are returned as a set of synthetic AAAA records. Similarly, recursive PTR queries in ip6.int 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 value of 0. DNSSEC validation of synthetic responses is not supported; therefore, responses containing synthetic RRs do not have the AD flag set.

The allow-v6-synthesis option is performed only for clients that are supplied recursive services.

6.5.3.6.13 Tuning Options

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

The statistics file generated by BIND 9 is similar, but not identical, to that generated by BIND 8.

The statistics dump begins with the following line:

+++ Statistics Dump +++ (973798949)

The number in parentheses is a standard UNIX time stamp, measured as seconds since January 1, 1970. Following that line are a series of lines containing a counter type, the value of the counter, a zone name (optional), and a view name (optional). The lines without view and zone listed are global statistics for the entire server. Lines with a zone and view name apply to the given view and zone (the view name is omitted for the default view). The statistics dump ends with the following line:

--- Statistics Dump --- (973798949)

The time stamp is identical to the one in the beginning line.

Table 6-16 describes the statistics counters that are maintained.

The server statement defines characteristics to be associated with a remote name server. The server statement has the following syntax:

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

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.

Table 6-17 describes the clauses in the server statement.