HP-UX Reference (11i v2 04/09) - 4 File Formats (vol 8)

n
named.conf(4) named.conf(4)
// 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 Responses
Many 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 light-
weight 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 dis-
abled 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, recur-
sive 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 sup-
ported; therefore responses containing synthetic RRs will not have the AD flag set.
Tuning
lame-ttl Sets the number of seconds to cache a lame server indication. 0 disables caching. (This
is NOT recommended.) Default is 600 (10 minutes). Maximum value is 1800 (30
minutes).
max-ncache-ttl
To reduce network traffic and increase performance, the server stores negative answers.
max-ncache-ttl is used to set a maximum retention time for these answers in the
server in seconds. The default max-ncache-ttl is 10800 seconds (3 hours). max-
ncache-ttl cannot exceed 7 days and will be truncated to 7 days if set to a greater
value.
max-cache-ttl
Sets the maximum time for which the server will cache ordinary (positive) answers.
Default is one week (7 days).
sig-validity-interval
Specifies the number of days into the future when DNSSEC signatures automatically
generated as a result of dynamic updates will expire. Default is 30 days. The signature
inception time is unconditionally set to one hour before the current time to allow for a
limited amount of clock skew.
HP-UX 11i Version 2: September 2004 − 16 − Hewlett-Packard Company Section 4−−191