named.conf.4 (2010 09)

n
named.conf(4) named.conf(4)
(BIND 9.3)
In this example, any responses for type
A records in class IN that have host.example.com
as a suffix,
are always returned in
random order. All other records are returned in
cyclic order.
rrset-order {
class IN type A name "host.example.com" order random;
order cyclic;
};
If multiple
rrset-order statements appear, they are not combined; the last one applies.
Server Resource Limit Options
The following options set limits on the server’s resource consumption that are enforced internally by the
server rather than the operating system.
max-cache-size
The maximum amount of memory to use for the server’s cache, in bytes. When the
amount of data in the cache reaches this limit, the server will cause 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, meaning that
records are purged from the cache only when their TTLs expire.
max-journal-size
Sets a maximum size for each journal file. When the journal file approaches the specified
size, some of the oldest transactions in the journal will be automatically removed. The
default is
unlimited.
recursive-clients
The maximum number of simultaneous recursive lookups the server will perform on
behalf of clients. The default is 1000. Because each recursing client uses a fair bit of
memory, on the order of 20 kilobytes, the value of the
recursive-clients
option
may have to be decreased on hosts with limited memory.
tcp-clients
The maximum number of simultaneous client TCP connections that the server will
accept. The default is 100.
tcp-listen-queue
The listen queue depth. The default and minimum is 3. If the kernel supports the accept
filter "dataready", this also controls how many TCP connections that will be queued in
kernel space waiting for some data before being passed to accept. Values less than 3 are
silently raised.
Sorting Option
The 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
(but see the
rrset-reorder
statement in the RRset Reordering Option section). The client resolver
code should rearrange the RRs as appropriate, that is, 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 name servers, not all the clients.
The
sortlist option 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 ele-
ment, 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
HP-UX 11i Version 3: September 2010 − 19 − Hewlett-Packard Company 19