Previous | Contents | Index |
Table 6-7 describes the Boolean BIND server configuration options.
Option | Description | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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. This is a change from BIND Version 8. If you are upgrading from old software, you might need to set this option to YES. |
||||||||||||||||||||||||||||
deallocate-on-exit | This option was used in BIND Version 8 to enable checking for memory leaks on exit. BIND Version 9 ignores this option and always performs the checks. | ||||||||||||||||||||||||||||
dialup |
If YES, then the server treats all zones as if they are doing zone
transfers across a dial-on-demand dialup link, which can be brought up
by traffic originating from this server. This has different effects
according to zone type, and it concentrates the zone maintenance so
that it all happens in a short interval, once every
heartbeat-interval
and during the one call. It also suppresses some of the normal zone
maintenance traffic. The default is NO.
The dialup option can also be specified in the view and zone statements. In these cases, it overrides the global dialup option. If the zone is a master zone then the server will send out a NOTIFY request to all the slaves (default). This should trigger the zone serial number check in the slave (providing it supports NOTIFY) allowing the slave to verify the zone while the connection is active. The set of servers to which NOTIFY is sent can be controlled by notify and also-notify . If the zone is a slave or stub zone, then the server will suppress the regular "zone up to date" (refresh) queries and only perform them when the heartbeat-interval expires in addition to sending NOTIFY requests. Finer control can be achieved by using notify which only sends NOTIFY messages, notify-passive which sends NOTIFY messages and suppresses the normal refresh queries, refresh which suppresses normal refresh processing and sends refresh queries when the heartbeat-interval expires, and passive, which just disables normal refresh processing. Note that normal NOTIFY processing is not affected by dialup.
|
||||||||||||||||||||||||||||
fake-iquery | In BIND 8, this option enabled simulating the obsolete DNS query type IQUERY. BIND 9 never does IQUERY simulation. | ||||||||||||||||||||||||||||
flush-zones-on-shutdown | When the nameserver exits due to receiving SIGTERM, flush or do not flush any pending zone writes. The default is flush-zones-on-shutdown no . | ||||||||||||||||||||||||||||
fetch-glue | This option is obsolete. In BIND Version 8, this option caused the server to attempt to fetch glue resource records it lacked when constructing the additional data section of a response. In BIND Version 9, the server does not fetch glue resource records. | ||||||||||||||||||||||||||||
has-old-clients | This option was incorrectly implemented in BIND Version 8 and is ignored by BIND Version 9. | ||||||||||||||||||||||||||||
host-statistics | In BIND Version 8, this option enabled the keeping of statistics for every host with which the name server interacts. This option is not implemented in BIND Version 9. | ||||||||||||||||||||||||||||
maintain-ixfr-base | This option is obsolete. It was used in BIND Version 8 to determine whether a transaction log was kept for incremental zone transfers. BIND Version 9 maintains a transaction log whenever possible. To disable outgoing incremental zone transfers, set the provide-ixfr option to NO. See Section 6.5.3.8 for more information. | ||||||||||||||||||||||||||||
minimal-responses | Specifies that when the server generates responses, it adds records to the authority and additional data sections only when they are required (for example, for delegations and negative responses). This might improve the performance of the server. The default is NO. | ||||||||||||||||||||||||||||
multiple-cnames | This option was used in BIND Version 8 to allow a domain name to allow multiple CNAME records in violation of the DNS standards. BIND Version 9 strictly enforces the CNAME rules, both in master files and dynamic updates. | ||||||||||||||||||||||||||||
notify |
Sends DNS NOTIFY messages when a zone changes for which the server is
authoritative (see Section 6.5.5). The messages are sent to the servers
listed in the zone's NS records (except the master server identified in
the SOA MNAME field) and to any servers listed in the
also-notify
option. If this option is explicitly set (the default), notifications
are sent only to servers explicitly listed using
also-notify
. If it is set to NO, notifications are not sent.
The notify option can also be specified in the zone statement. This overrides the notify option in the options statement. |
||||||||||||||||||||||||||||
recursion | When a DNS query requests recursion, specifies that the server will attempt to do all the work required to answer the query. If the recursion option is off and the server does not already know the answer, it returns a referral response. The default is YES. Note that setting the recursion option to NO does not prevent clients from getting data from the server's cache; it only prevents new data from being cached as an effect of client queries. Caching can still occur as an effect of the server's internal operation, such as NOTIFY address lookups. | ||||||||||||||||||||||||||||
rfc2308-type1 |
Setting this option to YES causes the server to send NS records along
with the SOA record for negative answers. The default is NO.
This option is not yet implemented. |
||||||||||||||||||||||||||||
use-id-pool | This option is obsolete. BIND Version 9 always allocates query IDs from a pool. | ||||||||||||||||||||||||||||
zone-statistics | Collects statistical data on all zones in the server (unless specifically turned off on a per-zone basis by specifying zone-statistics no in the zone statment). | ||||||||||||||||||||||||||||
use-ixfr | This option is obsolete. If you need to disable IXFR to a particular server, see the information about the provide-ixfr option in Section 6.5.3.8. | ||||||||||||||||||||||||||||
treat-cr-as-space | This option was used in BIND 8 to make the server treat carriage return characters the same way as a space or tab character---to facilitate loading of zone files. In BIND 9, these characters are always accepted and the option is ignored. | ||||||||||||||||||||||||||||
additional-from-auth
additional-from-cache |
These options control the behavior of an authoritative server when
answering queries that 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 is 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 can be added and modified by untrusted third parties. Also, avoiding the search for this additional data speeds up server operations at the possible expense of additional queries to resolve what otherwise would be provided in the additional section. For example, if a query asks for an MX record for host
FOO.EXAMPLE.COM, the following record is found:
The address records (A and AAAA) for MAIL.EXAMPLE.NET are provided as well, if they are known, even though they are not in the example.com zone. Setting these options to NO disables this behavior and makes the server only search for additional data in the zone it answers from. These options are intended for use in authoritative-only servers or in authoritative-only views. If you attempt to set these options to NO without also specifying recursion no , the server ignores the options and log a warning message. Specifying additional-from-cache no 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 "upward referral" to the root servers or to the servers of some other known parent of the query name. Because the data in an upward referral comes from the cache, the server cannot provide upward referrals when additional-from-cache no has been specified. Instead, the server responds to such queries with "REFUSED." This should not cause any problems, because upward referrals are not required for the resolution process. |
||||||||||||||||||||||||||||
match-mapped-addresses | When this option is set, an IPv4-mapped IPv6 address matches any address match list entries that match the corresponding IPv4 address. Use of this option is not necessary on OpenVMS systems. | ||||||||||||||||||||||||||||
ixfr-from-differences |
When 'yes' and the server loads a new version of a master zone from its
zone file or receives a new version of a slave file by a
non-incremental zone transfer, it will compare the new version to the
previous one and calculate a set of differences. The differences are
then logged in the zone's journal file such that the changes can be
transmitted to downstream slaves as an incremental zone transfer.
By allowing incremental zone transfers to be used for non-dynamic zones, this option saves bandwidth at the expense of increased CPU and memory consumption at the master. In particular, if the new version of a zone is completely different from the previous one, the set of differences will be of a size comparable to the combined size of the old and new zone version, and the server will need to temporarily allocate memory to hold this complete difference set. |
||||||||||||||||||||||||||||
multi-master | This should be set when you have multiple masters for a zone and the addresses refer to different machines. If 'yes' BIND will not log when the serial number on the master is less than what named currently has. The default is no. | ||||||||||||||||||||||||||||
dnssec-enable | Enable DNSSEC support in the BIND Server. Unless set to yes BIND behaves as if it does not support DNSSEC. The default is no. | ||||||||||||||||||||||||||||
querylog | Specify whether query logging should be started when the BIND server starts. If querylog is not specified then the query logging is determined by the presence of the logging category queries. | ||||||||||||||||||||||||||||
check-names |
This option is used to 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 master zones
the default is fail. For slave zones the default is warn. For answer
received from the network (response) the default is ignore.
The rules for legal hostnames/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 RDATA of NS, SOA and MX records. It also applies to the RDATA of PTR records where the owner name indicated that it is a reverse lookup of a hostname. The owner name ends in IN-ADDR.ARPA, IP6.ARPA, IP6.INT. |
The forwarding facility helps you create a large, sitewide cache on a few servers, thereby reducing traffic over links to external name servers. It can also be used to allow queries by servers that do not have direct access to the Internet but that want to look up exterior names anyway. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache.
Table 6-8 describes the forwarding options.
Option | Description |
---|---|
forward | Meaningful only if the forwarders list is not empty. A value of first (the default) causes the server to query the forwarders first, and if that does not answer the question, the server then looks for the answer itself. If only is specified, the server queries only the forwarders. |
forwarders | Specifies the IP addresses to be used for forwarding. The default is the empty list (no forwarding). |
Forwarding can also be configured on a per-domain basis, allowing for
the global forwarding options to be overridden in a variety of ways.
You can set particular domains to use different forwarders, or have a
different forward only/first behavior, or not to forward at all. See
Section 6.5.3.11 for more information.
6.5.3.7.3 Dual-stack Servers
Dual-stack servers are used as servers of last resort to work around problems in reachability due the lack of support for either IPv4 or IPv6 on the host machine.
Table 6-9 describes the dual-stack server options.
Option | Description |
---|---|
dual-stack-servers | Specifies host names/addresses of machines with access to both IPv4 and IPv6 transports. If a hostname is used the server must be able to resolve the name using only the transport it has. |
Access to the server can be restricted based on the IP address of the requesting system. See Section 6.5.2 for details on how to specify IP address lists.
Table 6-10 describes the access control options.
Option | Description |
---|---|
allow-notify | Specifies which hosts are allowed to notify this server, a slave, of zone changes in addition to the zone masters. The allow-notify option can also be specified in the zone statement; in this case, it overrides the allow-notify option in the options statement. The allow-notify option is meaningful only for a slave zone. If this option is not specified, the default is to process notify messages from only a zone's master. |
allow-query | Specifies which hosts are allowed to ask ordinary DNS questions. The allow-query option can also be specified in the zone statement; in this case, it overrides the allow-query option in the options statement. If this option is not specified, the default is to allow queries from all hosts. |
allow-recursion | Specifies which hosts are allowed to make recursive queries through this server. If this option is not specified, the default is to allow recursive queries from all hosts. Note that disallowing recursive queries for a host does not prevent the host from retrieving data that is already in the server's cache. |
allow-update-forwarding |
Specifies which hosts are allowed to submit Dynamic DNS updates to
slave zones to be forwarded to the master. The default is
{ none; }
, which means that no update forwarding will be performed. To enable
update forwarding, specify allow-update-forwarding
{ any; };
. Specifying values other than
{none; }
or
{ any; }
is usually counterproductive, since the responsibility for update
access control should rest with the master server, not the slaves.
Note that enabling the update forwarding feature on a slave server may expose master servers relying on insecure IP address based access control to attacks. |
allow-v6-synthesis | This option was introduced for the smooth transition from AAAA to A6 and from "nibble labels" to binary labels. However, since both A6 and binary labels were then deprecated, this option was also deprecated. It is now ignored with some warning messages. |
allow-transfer | Specifies which hosts are allowed to receive zone transfers from the server. The allow-transfer option can also be specified in the zone statement; in this case, it overrides the allow-transfer statement in the options statment. If this option is not specified, the default is to allow transfers to all hosts. |
blackhole | Specifies a list of addresses from which the server will not accept queries or will not use to resolve a query. The server will not respond queries from these addresses. The default is NONE. |
The interfaces and ports from which the server answers queries can be specified using the listen-on options. Table 6-11 describes the listen-on options.
Option | Description |
---|---|
listen-on |
Specifies the port for listening for queries sent using IPv4 addresses.
The listen-on option takes an optional port number and an address_match_list . The server listens on all interfaces allowed by the address match list. If a port is not specified, port 53 is used. Multiple
listen-on
statements are allowed. For example:
These statements enable the name server on port 53 for the IP address 5.6.7.8, and on port 1234 of an address on the machine in net 1.2 that is not 1.2.3.4. If the listen-on option is not specified, the server listens on port 53 on all interfaces. |
listen-on-v6 |
Specifies the interfaces and the ports on which the server will listen
for incoming queries sent using IPv6.
When { any; } is specified as the address_match_list for the listen-on-v6 option, the server does not bind a separate socket to each IPv6 interface address as it does for IPv4. Instead, it listens on the IPv6 wildcard address. A list of particular IPv6 addresses can also be specified, in which case the server listens on a separate socket for each specified address, regardless of whether the desired API is supported by the system. Multiple listen-on-v6 options can be used. For example,
will enable the name server on port 53 for any IPv6 addresses (with a single wildcard socket), and on port 1234 of IPv6 addresses that is not in the prefix 2001:db8::/32 (with separate sockets for each matched address.) To make the server not listen on any IPv6 address, use
If no listen-on-v6 option is specified, the server will not listen on any IPv6 address. |
Previous | Next | Contents | Index |