HP-UX Reference (11i v3 07/02) - 4 File Formats (vol 8)

n
named.conf(4) named.conf(4)
(BIND 9.3)
The Statistics File section.
tkey-dhkey The Diffie-Hellman key used by the server to generate shared keys with clients using the
Diffie-Hellman mode of TKEY. The server must be able to load the public and private keys
from files in the working directory. In most cases, the key_name should be the server’s host
name. The key_tag is an integer that is part of the key.
tkey-domain
The domain appended to the names of all shared keys generated with TKEY. When a client
requests a TKEY exchange, it can specify a preferred name for the key. If the name is
present, the name of the shared key will be client_specified_part
+tkey_domain.Otherwise,
the name of the shared key will be random_hex_digits+tkey-domain. In most cases, the
domain name should be the server’s domain name.
Boolean Options
additional-from-auth
, additional-from-cache
These options control the behavior of an authoritative server when answering queries
which have additional data, or when following CNAME and DNAME chains.
When both of these options are set to yes (the default) and a query is being answered from
authoritative data (a zone configured into the server), the additional data section of the
reply will be filled in using data from other authoritative zones and from the cache. In
some situations this is undesirable, such as when there is concern over the correctness of
the cache, or in servers where slave zones may be added and modified by untrusted third
parties. Also, avoiding the search for this additional data will speed up server operations at
the possible expense of additional queries to resolve what would otherwise be provided in
the additional section.
For example, if a query asks for an MX record for host foo.example.com
, and the
record found is
MX 10 mail.example.net
, normally the address records (A, A6, and
AAAA) for mail.example.net
will be provided as well, if known. Set these options to
no to disable this behavior.
These options are intended for use in authoritative-only servers, or in authoritative-only
views. Attempts to set them to no without also specifying recursion no will cause the
server to ignore the options and log a warning message.
Specifying additional-from-cache no
actually disables the use of the cache not
only for additional data lookups but also when looking up the answer. This is usually the
desired behavior in an authoritative-only server where the correctness of the cached data is
an issue.
When a name server is nonrecursively queried for a name that is not below the apex of any
served zone, it normally answers with an "upwards referral" to the root servers or the
servers of some other known parent of the query name. Since the data in an upwards
referral comes from the cache, the server will not be able to provide upwards referrals
when
additional-from-cache no
has been specified. Instead, it will respond to
such queries with REFUSED. This should not cause any problems since upwards referrals
are not required for the resolution process.
auth-nxdomain
If yes, then the AA bit is always set on NXDOMAIN responses, even if the server is not
actually authoritative. The default is no. If you are using an old version of BIND, you
might need to set this option to yes.
check-names
Restrict the character set and syntax of certain domain names in master files and/or DNS
responses received from the network. The default varies according to usage area. For mas-
ter zones, the default is fail. For slave zones, the default is warn. For answers received
from the network (response), the default is ignore.
The rules for legal host names and mail domains are derived from RFC 952 and RFC 821 as
modified by RFC 1123.
check-names applies to the owner names of A, AAAA, and MX records. It also applies to
the domain names in the rrdata of NS, SOA, and MX, records. It also applies to the rrdata
of PTR records where the owner name indicated that it is a reverse lookup of a host name
HP-UX 11i Version 3: February 2007 − 13 − Hewlett-Packard Company 245