Table of Contents for

DNS and BIND, 5th Edition

The working directory of the server. Any nonabsolute pathnames in the configuration file will be taken as relative to this directory. The default location for most server output files (e.g., named.run) is this directory. If a directory is not specified, the working directory defaults to ., the directory from which the server was started. The directory specified should be an absolute path.

When performing dynamic update of secure zones, the directory where the public- and private-key files should be found, if different than the current working directory. The directory specified must be an absolute path.

This option is obsolete. It was used in BIND 8 to specify the pathname to the named-xfer program. In BIND 9, no separate named-xfer program is needed; its functionality is built into the nameserver.

The domain appended to the names of all shared keys generated with TKEY. When a client requests a TKEY exchange, it may or may not specify the desired name for the key. If 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 domainname should be the server’s domain name.

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 keyname should be the server’s hostname.

The pathname of the file the server dumps the database to when instructed to do so with rndc dumpdb. If not specified, the default is named_dump.db.

The pathname of the file the server writes memory usage statistics to on exit. If not specified, the default is named.memstats.

The pathname of the file the server writes its process ID in. If not specified, the default is /var/run/named.pid. The pid-file is used by programs that want to send signals to the running nameserver. Specifying pid-file none disables the use of a PID file: no file will be written and all existing files are removed. Note that none is a keyword, not a filename, and therefore is not enclosed in double quotes.

The pathname of the file the server appends statistics to when instructed to do so using rndc stats. If not specified, the default is named.stats in the server’s current directory.

The UDP/TCP port number the server uses for receiving and sending DNS protocol traffic. The default is 53. This option is mainly intended for server testing; a server using a port other than 53 can’t communicate with the global DNS.

The source of entropy to be used by the server. Entropy is primarily needed for DNSSEC operations, such as TKEY transactions and dynamic update of signed zones. This option specifies the device (or file) from which to read entropy. If this is a file, operations requiring entropy will fail when the file has been exhausted. If not specified, the default value is /dev/random (or equivalent) when present, and none otherwise. The random-device option takes effect during the initial configuration load at server startup time and is ignored on subsequent reloads.

If specified, the listed type (A or AAAA) is emitted before other glue in the additional section of a query response. The default is not to preference any type (NONE).

Turns on enforcement of delegation-only in TLDs and root zones with an optional exclude list.

Note that some TLDs are not delegation-only (e.g., “DE,” “LV,” “US,” and “MUSEUM”).

options {
    root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
};

Disables the specified DNSSEC algorithms at and below the specified name. Multiple disable-algorithms statements are allowed. Only the most specific will be applied.

When set, dnssec-lookaside provides the validator with an alternate method to validate DNSKEY records at the top of a zone. When a DNSKEY is at or below a domain specified by the deepest dnssec-lookaside, and the normal dnssec validation has left the key untrusted, the trust-anchor is appended to the key name, and a DLV record is looked up to see if it can validate the key. If the DLV record validates a DNSKEY (similarly to the way a DS record does), the DNSKEY RRset is deemed to be trusted.

Specifies hierarchies that must/may not be secure (signed and validated). If yes, then named accepts answers only if they are secure. If no, normal dnssec validation applies, allowing for insecure answers to be accepted. The specified domain must be under a trusted-key, or dnssec-lookaside must be active.

If yes, 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 8. If you are using very old DNS software, you may need to set it to yes.

This option was used in BIND 8 to enable checking for memory leaks on exit. BIND 9 ignores the option and always performs the checks.

If yes, 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 concentrates the zone maintenance so that it all happens in a short interval, once every heartbeat-interval and hopefully during the one call. It also suppresses some of the normal zone maintenance traffic. The default is no.

The dialup option may also be specified in the view and zone statements, in which case it overrides the global dialup option.

If the zone is a master zone, the server sends 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, the server suppresses the regular “zone up to date” (refresh) queries and performs them only when the heartbeat-interval expires in addition to sending NOTIFY requests.

Finer control can be achieved using notify, which sends only 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.

In BIND 8, if this option is enabled, it simulates the obsolete DNS query type IQUERY. BIND 9 never does IQUERY simulation.

This option is obsolete. In BIND 8, fetch-glue yes caused the server to attempt to fetch-glue resource records it didn’t have when constructing the additional data section of a response. This is now considered a bad idea, and BIND 9 never does it.

When the nameserver exits due receiving SIGTERM, flush/do not flush any pending zone writes. The default is flush-zones-on-shutdown no.

This option was incorrectly implemented in BIND 8 and is ignored by BIND 9. To achieve the intended effect of has-old-clients yes, specify the two separate options auth-nxdomain yes and rfc2308-type1 no instead.

In BIND 8, this option enables statistics to be kept for every host the nameserver interacts with. Not implemented in BIND 9.

This option is obsolete. It was used in BIND 8 to determine whether a transaction log was kept for incremental zone transfer. BIND 9 maintains a transaction log whenever possible. If you need to disable outgoing incremental zone transfers, use provide-ixfr no.

If yes, then when generating responses, the server adds records to the authority and additional data sections only when they are required (e.g., delegations, negative responses). This may improve the performance of the server. The default is no.

This option is used in BIND 8 to allow a domain name to have multiple CNAME records in violation of the DNS standards. BIND 9.2 always strictly enforces the CNAME rules both in master files and dynamic updates.

If yes (the default), DNS NOTIFY messages are sent when a zone the server is in is authoritative for changes. 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 explicit, notifies are sent only to servers explicitly listed using also-notify. If no, no notifies are sent.

The notify option may also be specified in the zone statement, in which case it overrides the options notify statement. It is necessary to turn off this option only if it causes slaves to crash.

If yes, and a DNS query requests recursion, the server attempts to do all the work required to answer the query. If recursion is off, and the server does not already know the answer, it returns a referral response. The default is yes. Note that setting recursion 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 may still occur due to the server’s internal operation, such as NOTIFY address lookups. See also fetch-glue.

Setting this to yes causes the server to send NS records along with the SOA record for negative answers. The default is no. Not yet implemented in BIND 9.

This option is obsolete. BIND 9 always allocates query IDs from a pool.

If yes, the server collects statistical data on all zones (unless specifically turned off on a per-zone basis by specifying zone-statistics no in the zone statement). These statistics may be accessed using rndc stats, which dumps them to the file listed in the statistics-file.

This option is obsolete. If you need to disable IXFR to a particular server or servers, see the information on the provide-ixfr option.

This clause determines whether the local server, acting as master, will respond with an incremental zone transfer when the given remote server, a slave, requests it. If set to yes, incremental transfer is provided whenever possible. If set to no, all transfers to the remote server are nonincremental.

The request-ixfr clause determines whether the local server, acting as a slave, will request incremental zone transfers from the given remote server, a master.

This option was used in BIND 8 to make the server treat carriage return (“\r”) characters the same way as a space or tab character, in order to facilitate loading of zone files on a Unix system that were generated on an NT or DOS machine. In BIND 9, both Unix “\n” and NT/DOS “\r\n” newlines are always accepted, and the option is ignored.

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 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 about the correctness of the cache, or when servers have slave zones that may 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 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 and AAAA) for mail.example.net are provided as well, if known, even though they are not in the example.com zone. Setting these options to no disables this behavior and makes the server search for additional data only in the zone it answers from.

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 causes the server to ignore the options and logs 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 when the correctness of the cached data is an issue.

When a nameserver 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 can’t provide upwards referrals when additional-from-cache no has been specified. Instead, it responds to such queries with REFUSED. This should not cause any problems because upwards referrals are not required for the resolution process.

If yes, an IPv4-mapped IPv6 address matches any address match list entries that match the corresponding IPv4 address. Enabling this option is sometimes useful on IPv6-enabled Linux systems. It works around a kernel quirk that causes IPv4 TCP connections such as zone transfers to be accepted on an IPv6 socket that uses mapped addresses. As a result, address match lists designed for IPv4 fail to match. The use of this option for any other purpose is discouraged.

When yes, and when the server loads a new version of a master zone from its zone file or receives a new version of a slave file via a nonincremental zone transfer, it compares the new version to the previous one and calculates 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 nondynamic 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 are comparable in size to the combined size of the old and new zone version. The server then needs to temporarily allocate memory to hold this complete difference set.

This should be set when you have multiple masters for a zone and the addresses refer to different machines. If yes, named will not log when the serial number on the master is less than what named currently has. The default is no.

Enables DNSSEC support in named. Unless set to yes, named behaves as if it does not support DNSSEC. The default is no.

Specifies whether query logging should be started when named starts. If querylog is not specified, the query logging is determined by the presence of the logging category queries.

Restricts 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, AAA, and MX records. It also applies to the domain names in the RDATA of NS, SOA, and MX records, and to the RDATA of PTR records when the owner name indicates when it is a reverse lookup of a hostname (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, IP6.INT).

This option is 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 doesn’t answer the question, the server then looks for the answer itself. If only is specified, the server queries only the forwarders.

Specifies the IP addresses to be used for forwarding. The default is the empty list (no forwarding).

Specifies hostnames/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. If the machine is dual-stacked, the dual-stack-servers have no effect unless access to a transport has been disabled on the command line (e.g., named -4).

Specifies which hosts are allowed to notify this server—a slave—of zone changes in addition to the zone masters. allow-notify may also be specified in the zone statement, in which case it overrides the options allow-notify statement. It is only meaningful for a slave zone. If not specified, the default is to process notify messages only from a zone’s master.

Specifies which hosts are allowed to ask ordinary DNS questions. allow-query may also be specified in the zone statement, in which case it overrides the options allow-query statement. If not specified, the default is to allow queries from all hosts.

Specifies which hosts are allowed to make recursive queries through this server. If 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.

Specifies which hosts are allowed to submit dynamic DNS updates to slave zones that are forwarded to the master. The default is none, which means that no update forwarding is performed. To enable update forwarding, specify allow-update-forwarding any. Specifying values other than none or any is usually counterproductive because 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 to attacks those master servers that rely on insecure IP address-based access control.

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.

Specifies which hosts are allowed to receive zone transfers from the server. allow-transfer may also be specified in the zone statement, in which case it overrides the options allow-transfer statement. If not specified, the default allows transfers to all hosts.

Specifies a list of addresses the server doesn’t accept queries from or use to resolve a query. Queries from these addresses aren’t responded to. The default is none.

Defines a global list of IP addresses of nameservers that are also sent NOTIFY messages whenever a fresh copy of the zone is loaded, in addition to the servers listed in the zone’s NS records. This helps to ensure that copies of the zones will quickly converge on stealth servers. If an also-notify list is given in a zone statement, it overrides the options also-notify statement. When a zone notify statement is set to no, the IP addresses in the global also-notify list are not sent NOTIFY messages for that zone. The default is the empty list (no global notification list).

Inbound zone transfers running longer than this many minutes are terminated. The default is 120 minutes (2 hours). The maximum value is 28 days (40,320 minutes).

Inbound zone transfers making no progress in this many minutes are terminated. The default is 60 minutes (1 hour). The maximum value is 28 days (40,320 minutes).

Outbound zone transfers running longer than this many minutes are terminated. The default is 120 minutes (2 hours). The maximum value is 28 days (40,320 minutes).

Outbound zone transfers making no progress in this many minutes are terminated. The default is 60 minutes (1 hour). The maximum value is 28 days (40,320 minutes).

Slave servers periodically query master servers to find out if zone serial numbers have changed. Each such query uses a minute amount of the slave server’s network bandwidth. To limit the amount of bandwidth used, BIND 9 limits the rate at which queries are sent. The value of the serial-query-rate option, an integer, is the maximum number of queries sent per second. The default is 20.

In BIND 8, the serial-queries option sets the maximum number of concurrent serial number queries allowed to be outstanding at any given time. BIND 9 does not limit the number of outstanding serial queries and ignores the serial-queries option. Instead, it limits the rate at which the queries are sent as defined using the serial-query-rate option.

Zone transfers can be sent using two different formats, one-answer and many-answers. The transfer-format option is used on the master server to determine which format it sends. one-answer uses one DNS message per resource record transferred. many-answers packs as many resource records as possible into a message. many-answers is more efficient, but is only supported by relatively new slave servers, such as BIND 9, BIND 8.x, and patched versions of BIND 4.9.5. The default is many-answers. transfer-format may be overridden on a per-server basis using the server statement.

The maximum number of inbound zone transfers that can be running concurrently. The default value is 10. Increasing transfers-in may speed up the convergence of slave zones, but it also may increase the load on the local system.

The maximum number of outbound zone transfers that can be running concurrently. Zone transfer requests in excess of the limit are refused. The default value is 10.

The maximum number of inbound zone transfers that can be concurrently transferring from a given remote nameserver. The default value is 2. Increasing transfers-per-ns may speed up the convergence of slave zones, but it also may increase the load on the remote nameserver. transfers-per-ns may be overridden on a per-server basis by using the transfers phrase of the server statement.

transfer-source determines which local addresses are bound to IPv4 TCP connections that fetch zones transferred inbound by the server. It also determines the source IPv4 address, and optionally the UDP port, used for the refresh queries and forwarded dynamic updates. If not set, it defaults to a system controlled value that is usually the address of the interface closest to the remote end. This address must appear in the remote end’s allow-transfer option for the zone being transferred, if one is specified. This statement sets the transfer-source for all zones but can be overridden on a per-view or per-zone basis by including a transfer-source statement within the view or zone block in the configuration file.

The same as transfer-source, except zone transfers are performed using IPv6.

An alternate transfer source if the one listed in transfer-source fails, and use-alt-transfer-source is set.

An alternate transfer source if the one listed in transfer-source-v6 fails, and use-alt-transfer-source is set.

Use the alternate transfer sources or not. If views are specified, this defaults to no; otherwise, it defaults to yes (for BIND 8 compatibility).

notify-source determines which local source address—and, optionally, UDP port—is used to send NOTIFY messages. This address must appear in the slave server’s masters zone clause or in an allow-notify clause. This statement sets the notify-source for all zones but can be overridden on a per-zone/per-view basis by including a notify-source statement within the zone or view block in the configuration file.

Like notify-source, but applies to notify messages sent to IPv6 addresses.

The maximum size of a core dump. The default is default.

The maximum amount of data memory the server may use. The default is default. This is a hard limit on server memory usage. If the server attempts to allocate memory in excess of this limit, the allocation will fail, which may, in turn, leave the server unable to perform DNS service. Therefore, this option is rarely useful as a way to limit the amount of memory used by the server, but it can be used to raise an operating system data size limit that is too small by default. If you wish to limit the amount of memory used by the server, use the max-cache-size and recursive-clients options instead.

The maximum number of files the server may have open concurrently. The default is unlimited.

The maximum amount of stack memory the server may use. The default is default.

This option is obsolete; it is accepted and ignored for BIND 8 compatibility. The option max-journal-size performs a similar function in BIND 8.

Sets a maximum size for each journal file. When the journal file approaches the specified size, some of the oldest transactions in the journal are automatically removed. The default is unlimited.

In BIND 8, specifies the maximum number of host statistic entries to be kept. Not implemented in BIND 9.

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.

The maximum number of simultaneous client TCP connections the server will accept. The default is 100.

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 causes 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.

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 are queued in kernel space waiting for some data before being passed to accept. Values less than 3 are silently raised.

The server removes expired resource records from the cache every cleaning-interval minutes. The default is 60 minutes. The maximum value is 28 days (40,320 minutes). If set to 0, no periodic cleaning occurs.

The server performs zone maintenance tasks for all zones marked as dialup whenever this interval expires. The default is 60 minutes. Reasonable values are up to 1 day (1,440 minutes). The maximum value is 28 days (40,320 minutes). If set to 0, no zone maintenance for these zones occurs.

The server scans the network interface list every interface-interval minutes. The default is 60 minutes. The maximum value is 28 days (40,320 minutes). If set to 0, interface scanning occurs only when the configuration file is loaded. After the scan, the server begins listening for queries on any newly discovered interfaces (provided they are allowed by the listen-on configuration), and stops listening on interfaces that have gone away.

Nameserver statistics are logged every statistics-interval minutes. The default is 60. The maximum value is 28 days (40,320 minutes). If set to 0, no statistics are logged.

Records are returned in the order they are defined in the zone file.

Records are returned in a random order.

Records are returned in a round-robin order.

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

To reduce network traffic and increase performance, the server stores negative answers. max-ncache-ttl sets a maximum retention time for these answers in the server in seconds. The default max-ncache-ttl is 10,800 seconds (3 hours). max-ncache-ttl cannot exceed seven days and is silently truncated to seven days if set to a greater value.

max-cache-ttl sets the maximum time for which the server caches ordinary (positive) answers. The default is one week (seven days).

The minimum number of root servers that is required for a request for the root servers to be accepted. Default is 2. Not yet implemented in BIND 9.

Specifies the number of days in the future when DNSSEC signatures automatically generated as a result of dynamic updates will expire. The default is 30 days. The maximum value is 10 years (3,660 days). The signature inception time is unconditionally set to one hour before the current time to allow for a limited amount of clock skew.

These options control the server’s behavior on refreshing a zone (querying for SOA changes) or retrying failed transfers. Usually the SOA values for the zone are used, but these values are set by the master, giving slave server administrators little control over their contents.

These options allow the administrator to set a minimum and maximum refresh and retry time per-zone, per-view, or globally. These options are valid for slave and stub zones, and clamp the SOA refresh and retry times to the specified values.

edns-udp-size sets the advertised EDNS UDP buffer size. Valid values are 512 to 4096 (values outside this range are silently adjusted). The default value is 4096. The usual reason for setting edns-udp-size to a nondefault value is to get UDP answers to pass through broken firewalls that block fragmented packets and/or block UDP packets that are greater than 512 bytes.

The version the server should report via a query of the name version.bind with type TXT, class CHAOS. The default is the real version number of this server. Specifying version none disables processing of the queries.

The hostname the server should report via a query of the name hostname.bind with type TXT, class CHAOS. This defaults to the hostname of the machine hosting the nameserver as found by gethostname(). The primary purpose of such queries is to identify which of a group of anycast servers is actually answering your queries. Specifying hostname none; disables processing of the queries.

The ID of the server should report via a query of the name ID.SERVER with type TXT, class CHAOS. The primary purpose of such queries is to identify which of a group of anycast servers is actually answering your queries. Specifying server-id none; disables processing of the queries. Specifying server-id hostname; causes named to use the hostname as found by gethostname(). The default server-id is none.