+ +
The Internet Domain Name System (DNS) consists of the syntax to specify the names of entities in the Internet in a hierarchical @@ -60,10 +61,12 @@ group of distributed hierarchical databases.
-+ +
The Berkeley Internet Name Domain (BIND) implements a domain name server for a number of operating systems. This @@ -72,12 +75,14 @@ BIND version 9 software package for system administrators.
-This version of the manual corresponds to BIND version 9.17.
-This version of the manual corresponds to BIND version 9.17.
++ +
In this document, Chapter 1 introduces the basic DNS and BIND concepts. Chapter 2 describes resource requirements for running BIND in various @@ -100,15 +105,18 @@ and the Domain Name System.
-+ +
In this document, we use the following general typographic conventions:
-+
The following conventions are used in descriptions of the BIND configuration file:
--
+ +
The purpose of this document is to explain the installation and upkeep of the BIND (Berkeley Internet Name Domain) software package, and we begin by reviewing the fundamentals of the Domain Name System (DNS) as they relate to BIND.
-+ +
The Domain Name System (DNS) is a hierarchical, distributed database. It stores information for mapping Internet host names to IP addresses and vice versa, mail routing information, and other data used by Internet applications.
-+ +
Clients look up information in the DNS by calling a resolver library, which sends queries to one or more name servers and interprets the responses. @@ -256,11 +272,13 @@ contains a name server, named, and a set of associated tools.
-+ +
The data stored in the DNS is identified by domain names that are organized as a tree according to organizational or administrative boundaries. Each node of the tree, called a domain, is given a label. The domain @@ -271,7 +289,8 @@ separated by dots. A label need only be unique within its parent domain.
-+ +
For example, a domain name for a host at the
company Example, Inc. could be
ourhost.example.com,
@@ -283,7 +302,8 @@
ourhost is the
name of the host.
+ +
For administrative purposes, the name space is partitioned into areas called zones, each starting at a node and extending down to the leaf nodes or to nodes where other zones @@ -291,27 +311,32 @@ The data for each zone is stored in a name server, which answers queries about the zone using the DNS protocol.
-+ +
The data associated with each domain name is stored in the form of resource records (RRs). Some of the supported resource record types are described in the section called “Types of Resource Records and When to Use Them”.
-+ +
For more detailed information about the design of the DNS and the DNS protocol, please refer to the standards documents listed in the section called “Request for Comments (RFCs)”.
-+ +
To properly operate a name server, it is important to understand the difference between a zone and a domain.
-+ +
As stated previously, a zone is a point of delegation in the DNS tree. A zone consists of those contiguous parts of the domain @@ -323,7 +348,8 @@ parent zone, which should be matched by equivalent NS records at the root of the delegated zone.
-+ +
For instance, consider the example.com
domain which includes names
such as host.aaa.example.com and
@@ -345,7 +371,8 @@
gain a complete understanding of this difficult and subtle
topic.
+ +
Though BIND is called a "domain name server", it deals primarily in terms of zones. The master and slave @@ -355,11 +382,13 @@ be a slave server for your domain, you are actually asking for slave service for some collection of zones.
-+ +
Each zone is served by at least one authoritative name server, which contains the complete data for the zone. @@ -367,16 +396,19 @@ most zones have two or more authoritative servers, on different networks.
-+ +
Responses from authoritative servers have the "authoritative answer" (AA) bit set in the response packets. This makes them easy to identify when debugging DNS configurations using tools like dig (the section called “Diagnostic Tools”).
-+ +
The authoritative server where the master copy of the zone data is maintained is called the primary master server, or simply the @@ -387,16 +419,19 @@ zone file or master file.
-+ +
In some cases, however, the master file may not be edited by humans at all, but may instead be the result of dynamic update operations.
-+ +
The other authoritative servers, the slave servers (also known as secondary servers) load the zone contents from another server using a replication @@ -406,7 +441,7 @@ slave. In other words, a slave server may itself act as a master to a subordinate slave server.
-+
Periodically, the slave server must send a refresh query to determine whether the zone contents have been updated. This is done by sending a query for the zone's SOA record and @@ -419,17 +454,19 @@ max-retry-time, and min-retry-time options.
-+
If the zone data cannot be updated within the time specified by the SOA EXPIRE option (up to a hard-coded maximum of 24 weeks) then the slave zone expires and will no longer respond to queries.
-+ +
Usually all of the zone's authoritative servers are listed in NS records in the parent zone. These NS records constitute a delegation of the zone from the parent. @@ -440,7 +477,8 @@ list servers in the parent's delegation that are not present at the zone's top level.
-+ +
A stealth server is a server that is authoritative for a zone but is not listed in that zone's NS records. Stealth servers can be used for keeping a local copy of @@ -451,7 +489,8 @@ are inaccessible.
-+ +
A configuration where the primary master server itself is a stealth server is often referred to as a "hidden primary" configuration. One use for this configuration is when the primary @@ -459,12 +498,17 @@ is behind a firewall and therefore unable to communicate directly with the outside world.
-+ + + +
The resolver libraries provided by most operating systems are stub resolvers, meaning that they are not capable of @@ -476,22 +520,26 @@ is called a recursive name server; it performs recursive lookups for local clients.
-+ +
To improve performance, recursive servers cache the results of the lookups they perform. Since the processes of recursion and caching are intimately connected, the terms recursive server and caching server are often used synonymously.
-+ +
The length of time for which a record may be retained in the cache of a caching name server is controlled by the Time To Live (TTL) field associated with each resource record.
-+ +
Even a caching name server does not necessarily perform the complete recursive lookup itself. Instead, it can forward some or all of the queries @@ -499,7 +547,8 @@ server, commonly referred to as a forwarder.
-+ +
There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer @@ -513,18 +562,22 @@ that can do it, and that server would query the Internet DNS servers on the internal server's behalf.
-+ +
The BIND name server can simultaneously act as a master for some zones, a slave for other zones, and as a caching (recursive) server for a set of local clients.
-+ +
However, since the functions of authoritative name service and caching/recursive name service are logically separate, it is often advantageous to run them on separate server machines. @@ -539,9 +592,11 @@ does not need to be reachable from the Internet at large and can be placed inside a firewall.
--address_match_list=address_match_list_element; ...address_match_list_element= [ ! ] (ip_address|ip_prefix| keykey_id|acl_name| {address_match_list} )
+ +
Address match lists are primarily used to determine access control for various server operations. They are also used in the listen-on and sortlist statements. The elements which constitute an address match list can be any of the following:
-+ +
Elements can be negated with a leading exclamation mark (`!'), and the match list names "any", "none", "localhost", and "localnets" are predefined. More information on those names can be found in the description of the acl statement.
-+ +
The addition of the key clause made the name of this syntactic element something of a misnomer, since security keys can be used to validate access without regard to a host or network address. Nonetheless, the term "address match list" is still used throughout the documentation.
-+ +
When a given IP address or prefix is compared to an address match list, the comparison takes place in approximately O(1) time. However, key comparisons require that the list of keys be traversed until a matching key is found, and therefore may be somewhat slower.
-+ +
The interpretation of a match depends on whether the list is being used for access control, defining listen-on ports, or in a sortlist, and whether the element was negated.
-+ +
When used as an access control list, a non-negated match allows access and a negated match denies access. If there is no match, access is denied. The clauses @@ -609,7 +633,8 @@ server to refuse queries on any of the machine's addresses which do not match the list.
-+ +
Order of insertion is significant. If more than one element in an ACL is found to match a given IP address or prefix, preference will be given to the one that came @@ -625,22 +650,26 @@ that problem by having 1.2.3.13 blocked by the negation, but all other 1.2.3.* hosts fall through.
-+ +
The BIND 9 comment syntax allows for comments to appear anywhere that whitespace may appear in a BIND configuration file. To appeal to programmers of all kinds, they can be written in the C, C++, or shell/perl style.
-+ +
Comments may appear anywhere that whitespace may appear in a BIND configuration file.
-+
C-style comments start with the two characters /* (slash, star) and end with */ (star, slash). Because they are completely delimited with these characters, they can be used to comment only a portion of a line or to span multiple lines.
-+
C-style comments cannot be nested. For example, the following is not valid because the entire comment ends with the first */:
-+
/* This is the start of a comment. @@ -681,14 +711,15 @@-
+ +
C++-style comments start with the two characters // (slash, slash) and continue to the end of the physical line. They cannot be continued across multiple physical lines; to have one logical comment span multiple lines, each line must use the // pair. For example:
-+
// This is the start of a comment. The next line @@ -698,14 +729,15 @@-
+
Shell-style (or perl-style, if you prefer) comments start with the character
-#(number sign) and continue to the end of the physical line, as in C++ comments. For example:+ +
# This is the start of a comment. The next line @@ -715,22 +747,25 @@-
+ +--Warning
-+
You cannot use the semicolon (`;') character to start a comment such as you would in a zone file. The semicolon indicates the end of a configuration statement.
-
+ +
A BIND 9 configuration consists of statements and comments. Statements end with a semicolon. Statements and comments are the @@ -738,10 +773,13 @@ statements contain a block of sub-statements, which are also terminated with a semicolon.
-+ +
The following statements are supported:
-+
The logging and options statements may only occur once per configuration.
-+ +
The acl statement assigns a symbolic name to an address match list. It gets its name from a primary use of address match lists: Access Control Lists (ACLs).
-+ +
The following ACLs are built-in:
-+controls { inet (-ipv4_address|ipv6_address| * ) [ port (integer| * ) ] allow @@ -1028,19 +1074,22 @@boolean]; };
+ +
The controls statement declares control channels to be used by system administrators to control the operation of the name server. These control channels are used by the rndc utility to send commands to and retrieve non-DNS results from a name server.
-+ +
An inet control channel is a TCP socket
listening at the specified ip_port on the
specified ip_addr, which can be an IPv4 or IPv6
@@ -1053,11 +1102,13 @@
using the loopback address (127.0.0.1
or ::1) is recommended for maximum security.
+ +
If no port is specified, port 953 is used. The asterisk
"*" cannot be used for ip_port.
+ +
The ability to issue commands over the control channel is restricted by the allow and keys clauses. @@ -1067,7 +1118,8 @@ elements of the address_match_list are ignored.
-+ +
A unix control channel is a UNIX domain socket listening at the specified path in the file system. Access to the socket is specified by the perm, @@ -1076,7 +1128,8 @@ (perm) are applied to the parent directory as the permissions on the socket itself are ignored.
-+ +
The primary authorization mechanism of the command channel is the key_list, which contains a list of key_ids. @@ -1085,7 +1138,8 @@ See Remote Name Daemon Control application in the section called “Administrative Tools”) for information about configuring keys in rndc.
-+ +
If the read-only clause is enabled, the control channel is limited to the following set of read-only commands: nta -dump, @@ -1095,7 +1149,8 @@ read-only is not enabled and the control channel allows read-write access.
-+ +
If no controls statement is present,
named will set up a default
control channel listening on the loopback address 127.0.0.1
@@ -1109,7 +1164,8 @@
To create a rndc.key file, run
rndc-confgen -a.
+ +
The rndc.key feature was created to
ease the transition of systems from BIND 8,
which did not have digital signatures on its command channel
@@ -1122,7 +1178,8 @@
command rndc-confgen -a after BIND 9 is
installed.
+ +
Since the rndc.key feature
is only intended to allow the backward-compatible usage of
BIND 8 configuration files, this
@@ -1143,21 +1200,25 @@
readable by a group
that contains the users who should have access.
+ +
To disable the command channel, use an empty controls statement: controls { };.
-include filename;
+ + +
The include statement inserts the specified file (or files if a valid glob expression is detected) at the point where the include @@ -1168,28 +1229,32 @@ others. For example, the statement could include private keys that are readable only by the name server.
-+ +
The key statement defines a shared secret key for use with TSIG (see the section called “TSIG”) or the command channel (see the section called “controls Statement Definition and Usage”).
-+ +
The key statement can occur at the top level of the configuration file or inside a view @@ -1200,7 +1265,8 @@ Usage”) must be defined at the top level.
-+ +
The key_id, also known as the
key name, is a domain name uniquely identifying the key. It can
be used in a server
@@ -1209,7 +1275,8 @@
verify that incoming requests have been signed with a key
matching this name, algorithm, and secret.
+ +
The algorithm_id is a string
that specifies a security/authentication algorithm. The
named server supports hmac-md5,
@@ -1223,11 +1290,12 @@
to be used by the algorithm, and is treated as a Base64
encoded string.
+logging { category-string{string; ... }; channelstring{ @@ -1244,11 +1312,13 @@ }; };
+ +
The logging statement configures a wide variety of logging options for the name server. Its channel phrase @@ -1256,29 +1326,33 @@ a name that can then be used with the category phrase to select how various classes of messages are logged.
-+
Only one logging statement is used to define as many channels and categories as are wanted. If there is no logging statement, the logging configuration will be:
+logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
};
-+ +
If named is started with the
-L option, it logs to the specified file
at startup, instead of using syslog. In this case the logging
configuration will be:
logging {
category default { default_logfile; default_debug; };
category unmatched { null; };
};
-+ +
The logging configuration is only established when
the entire configuration file has been parsed.
When the server is starting up, all logging messages
@@ -1286,14 +1360,17 @@
channels, or to standard error if the -g option
was specified.
+ +
All log output goes to one or more channels; you can make as many of them as you want.
-+ +
Every channel definition must include a destination clause that says whether messages selected for the channel go to a file, to a particular syslog facility, to the standard error stream, or are @@ -1304,12 +1381,14 @@ category name and/or severity level (the default is not to include any).
-+ +
The null destination clause causes all messages sent to the channel to be discarded; in that case, other options for the channel are meaningless.
-+ +
The file destination clause directs the channel to a disk file. It can include additional arguments to specify how large the file is allowed to @@ -1319,7 +1398,8 @@ (versions), and the format to use for naming backup versions (suffix).
-+ +
The size option is used to limit log file growth. If the file ever exceeds the specified size, then named will stop writing to the @@ -1331,7 +1411,7 @@ removes or truncates the log to less than the maximum size. The default behavior is not to limit the size of the file.
-+
File rolling only occurs when the file exceeds the size
specified with the size option. No
backup versions are kept by default; any existing
@@ -1340,7 +1420,7 @@
how many backup versions of the file should be kept.
If set to unlimited, there is no limit.
+
The suffix option can be set to
either increment or
timestamp. If set to
@@ -1363,18 +1443,21 @@
whereupon a new filename.log is
opened.
+ +
Example usage of the size, versions, and suffix options:
+channel an_example_channel {
file "example.log" versions 3 size 20m suffix increment;
print-time yes;
print-category yes;
};
-+ +
The syslog destination clause directs the channel to the system log. Its argument is a @@ -1396,10 +1479,10 @@ only uses two arguments to the openlog() function, then this clause is silently ignored.
-+
On Windows machines syslog messages are directed to the EventViewer.
-+
The severity clause works like syslog's "priorities", except that they can also be used if you are writing straight to a file rather than using syslog. @@ -1408,7 +1491,7 @@ levels will be accepted.
-+
If you are using syslog, then the syslog.conf priorities will also determine what eventually passes through. For example, defining a channel facility and severity as daemon and debug but @@ -1420,7 +1503,8 @@ then syslogd would print all messages it received from the channel.
-+ +
The stderr destination clause directs the channel to the server's standard error stream. This is intended @@ -1429,7 +1513,8 @@ example when debugging a configuration.
-+ +
The server can supply extensive debugging information when it is in debugging mode. If the server's global debug level is greater @@ -1443,19 +1528,21 @@ notrace. All debugging messages in the server have a debug level, and higher debug levels give more detailed output. Channels that specify a specific debug severity, for example:
+channel specific_debug_level {
file "foo";
severity debug 3;
};
-+ +
will get debugging output of level 3 or less any time the server is in debugging mode, regardless of the global debugging level. Channels with dynamic severity use the server's global debug level to determine what messages to print.
-+
print-time can be set to
yes, no,
or a time format specifier, which may be one of
@@ -1471,14 +1558,14 @@ notrace. All debugging messages in the server have a debug
are logged in ISO8601 format, with time zone set to
UTC. The default is no.
+
print-time may be specified for a syslog channel, but it is usually pointless since syslog also logs the date and time.
-+
If print-category is requested, then the category of the message will be logged as well. Finally, if print-severity is @@ -1489,15 +1576,18 @@ notrace. All debugging messages in the server have a debug three print- options are on:
-+ +
28-Feb-2000 15:05:32.863 general: notice: running
+ +
If buffered has been turned on the output to files will not be flushed after each log entry. By default all log messages are flushed.
-+ +
There are four predefined channels that are used for named's default logging as follows. If named is started with the @@ -1506,6 +1596,7 @@ notrace. All debugging messages in the server have a debug How they are used is described in the section called “The category Phrase”.
+channel default_syslog {
// send to syslog's daemon facility
syslog daemon;
@@ -1543,7 +1634,8 @@ channel default_logfile {
severity dynamic;
};
-+ +
The default_debug channel has the
special
property that it only produces output when the server's debug
@@ -1551,7 +1643,8 @@ channel default_logfile {
nonzero. It normally writes to a file called named.run
in the server's working directory.
+ +
For security reasons, when the -u
command line option is used, the named.run file
is created only after named has
@@ -1562,17 +1655,20 @@ channel default_logfile {
option to specify a default logfile, or the -g
option to log to standard error which you can redirect to a file.
+ +
Once a channel is defined, it cannot be redefined. Thus you cannot alter the built-in channels directly, but you can modify the default logging by pointing categories at channels you have defined.
-+ +
There are many categories, so you can send the logs you want to see wherever you want, without seeing logs you don't want. If you don't specify a list of channels for a category, then log @@ -1581,19 +1677,24 @@ channel default_logfile { instead. If you don't specify a default category, the following "default default" is used:
+category default { default_syslog; default_debug; };
-+ +
If you start named with the
-L option then the default category is:
category default { default_logfile; default_debug; };
-+ +
As an example, let's say you want to log security events to a file, but you also want keep the default logging behavior. You'd specify the following:
+channel my_security_channel {
file "my_security_file";
severity info;
@@ -1603,18 +1704,22 @@ category security {
default_syslog;
default_debug;
};
-+ +
To discard all messages in a category, specify the null channel:
+category xfer-out { null; };
category notify { null; };
-+ +
Following are the available categories and brief descriptions of the types of log information they contain. More categories may be added in future BIND releases.
-+
The query-errors category is used to indicate why and how specific queries resulted in responses which indicate an error. Normally, these messages @@ -2043,26 +2149,27 @@ category notify { null; }; logged at info. The logging levels are described below:
-+ +
At debug level 1 or higher - or at info, when query logging is active - each response with response code SERVFAIL will be logged as follows:
-+
client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880
+
This means an error resulting in SERVFAIL was detected at line
3880 of source file query.c. Log messages
of this level will particularly help identify the cause of
SERVFAIL for an authoritative server.
+
At debug level 2 or higher, detailed context information about recursive resolutions that resulted in SERVFAIL will be logged. The log message will look like this:
-+
@@ -2073,14 +2180,14 @@ badresp:1,adberr:0,findfail:0,valfail:0]
-
+
The first part before the colon shows that a recursive
resolution for AAAA records of www.example.com completed
in 10.000183 seconds and the final result that led to the
SERVFAIL was determined at line 2970 of source file
resolver.c.
+
The following part shows the detected final result and the latest result of DNSSEC validation. The latter is always "success" when no validation attempt was made. In this example, @@ -2088,7 +2195,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] servers are down or unreachable, leading to a timeout in 10 seconds. DNSSEC validation was probably not attempted.
-+
The last part, enclosed in square brackets, shows statistics
collected for this particular resolution attempt.
The domain field shows the deepest zone that
@@ -2096,7 +2203,9 @@ badresp:1,adberr:0,findfail:0,valfail:0]
finally detected. The meaning of the other fields is
summarized in the following table.
+
At debug level 3 or higher, the same messages as those at debug level 1 will be logged for other errors than SERVFAIL. Note that negative responses such as NXDOMAIN are not errors, and are not logged at this debug level.
-+
At debug level 4 or higher, the detailed context information logged at debug level 2 will be logged for other errors than SERVFAIL and for negative resonses such as NXDOMAIN.
-+masters-string[ portinteger] [ dscpinteger] { (masters|ipv4_address[ portinteger] |ipv6_address[ portinteger] ) [ keystring]; ... };
masters + +
masters lists allow for a common set of masters to be easily used by multiple stub and slave zones in their masters or also-notify lists.
-+ +
This is the grammar of the options
statement in the named.conf file:
+options { allow-new-zones-boolean; allow-notify {address_match_element; ... }; @@ -2586,12 +2701,14 @@ badresp:1,adberr:0,findfail:0,valfail:0] zone-statistics ( full | terse | none |boolean); };
+ +
The options statement sets up global options to be used by BIND. This statement @@ -2600,10 +2717,11 @@ badresp:1,adberr:0,findfail:0,valfail:0] statement, an options block with each option set to its default will be used.
-+
Allows multiple views to share a single cache database. Each view has its own cache database by default, but @@ -2612,13 +2730,15 @@ badresp:1,adberr:0,findfail:0,valfail:0] share a single cache to save memory and possibly improve resolution efficiency by using this option.
-+ +
The attach-cache option may also be specified in view statements, in which case it overrides the global attach-cache option.
-+ +
The cache_name specifies
the cache to be shared.
When the named server configures
@@ -2628,14 +2748,16 @@ badresp:1,adberr:0,findfail:0,valfail:0]
The rest of the views will simply refer to the
already created cache.
+ +
One common configuration to share a cache would be to allow all views to share a single cache. This can be done by specifying the attach-cache as a global option with an arbitrary name.
-+ +
Another possible operation is to allow a subset of all views to share a cache while the others to retain their own caches. @@ -2644,6 +2766,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] attach-cache option as a view A (or B)'s option, referring to the other view name:
+
view "A" {
// this view has its own cache
@@ -2658,7 +2781,8 @@ badresp:1,adberr:0,findfail:0,valfail:0]
...
};
-+ +
Views that share a cache must have the same policy on configurable parameters that may affect caching. The current implementation requires the following @@ -2675,7 +2799,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] min-ncache-ttl, zero-no-soa-ttl.
-+ +
Note that there may be other parameters that may cause confusion if they are inconsistent for different views that share a single cache. @@ -2687,9 +2812,10 @@ badresp:1,adberr:0,findfail:0,valfail:0] configuration differences in different views do not cause disruption with a shared cache.
-+
The working directory of the server. Any non-absolute pathnames in the configuration file will be taken as relative to this directory. The default @@ -2701,10 +2827,11 @@ badresp:1,adberr:0,findfail:0,valfail:0] should be an absolute path, and must be writable by the effective user ID of the named process. -
+
dnstap is a fast, flexible method for capturing and logging DNS traffic. Developed by Robert Edmonds at Farsight Security, Inc., and supported @@ -2719,13 +2846,13 @@ badresp:1,adberr:0,findfail:0,valfail:0] by Google, Inc.; see https://developers.google.com/protocol-buffers).
-+
To enable dnstap at compile time,
the fstrm and protobuf-c
libraries must be available, and BIND must be configured with
--enable-dnstap.
+
The dnstap option is a bracketed list
of message types to be logged. These may be set differently
for each view. Supported types are client,
@@ -2735,13 +2862,13 @@ badresp:1,adberr:0,findfail:0,valfail:0]
dnstap messages to be logged, regardless of
type.
+
Each type may take an additional argument to indicate whether
to log query messages or
response messages; if not specified,
both queries and responses are logged.
+
Example: To log all authoritative queries and responses, recursive client responses, and upstream queries sent by the resolver, use: @@ -2754,63 +2881,76 @@ badresp:1,adberr:0,findfail:0,valfail:0]
-
+
Logged dnstap messages can be parsed using the dnstap-read utility (see dnstap-read(1) for details).
-+
For more information on dnstap, see http://dnstap.info.
-+
The fstrm library has a number of tunables that are exposed
in named.conf, and can be modified
if necessary to improve performance or prevent loss of data.
These are:
mpsc
(multiple producer, single consumer); the other
option is spsc (single producer,
single consumer).
- IOV_MAX,
and the default is 64.
- +
Note that all of the above minimum, maximum, and default values are set by the libfstrm library, and may be subject to change in future versions of the library. See the libfstrm documentation for more information.
- ++
Configures the path to which the dnstap frame stream will be sent if dnstap is enabled at compile time and active.
-+
The first argument is either file or
unix, indicating whether the destination
is a file or a UNIX domain socket. The second argument
@@ -2846,7 +2987,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
(provided with libfstrm) is listening on
the socket.)
+
If the first argument is file, then
up to three additional options can be added:
size indicates the size to which a
@@ -2863,7 +3004,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
The default is to allow dnstap log
files to grow to any size without rolling.
+
dnstap-output can only be set globally in options. Currently, it can only be set once while named is running; @@ -2871,24 +3012,29 @@ badresp:1,adberr:0,findfail:0,valfail:0] rndc reload or rndc reconfig.
-+
Specifies an identity string to send in
dnstap messages. If set to
hostname, which is the default, the
server's hostname will be sent. If set to
none, no identity string will be sent.
-
+
Specifies a version string to send in
dnstap messages. The default is the
version number of the BIND release. If set to
none, no version string will be sent.
-
+
When named is compiled using the MaxMind GeoIP2 geolocation API, this specifies the directory containing GeoIP @@ -2902,9 +3048,11 @@ badresp:1,adberr:0,findfail:0,valfail:0] directory. See the section called “acl Statement Definition and Usage” for details about geoip ACLs. -
+
When performing dynamic update of secure zones, the
directory where the public and private DNSSEC key files
should be found, if different than the current working
@@ -2913,10 +3061,11 @@ badresp:1,adberr:0,findfail:0,valfail:0]
bind.keys,
rndc.key or
session.key.)
-
+
When named is built with liblmdb, this option sets a maximum size for the memory map of the new-zone database (NZD) in LMDB database format. @@ -2925,7 +3074,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] Note that this is not the NZD database file size, but the largest size that the database may grow to.
-+
Because the database file is memory mapped, its size is limited by the address space of the named process. The default of 32 megabytes was chosen to be usable with @@ -2935,10 +3084,10 @@ badresp:1,adberr:0,findfail:0,valfail:0] ought to be able to hold configurations of about 100,000 zones.
-+
Specifies the directory in which to store the files that track managed DNSSEC keys (i.e., those configured using the initial-key or @@ -2948,7 +3097,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] must be writable by the effective user ID of the named process.
-+
If named is not configured to use views,
then managed keys for the server will be tracked in a single
file called managed-keys.bind.
@@ -2959,41 +3108,44 @@ badresp:1,adberr:0,findfail:0,valfail:0]
followed by the extension
.mkeys.
+
(Note: in previous releases, file names for views always used the SHA256 hash of the view name. To ensure compatibility after upgrade, if a file using the old name format is found to exist, it will be used instead of the new format.)
-+
Sets the size threshold (expressed as a percentage of the size of the full zone) beyond which named will choose to use an AXFR response rather than IXFR when answering zone transfer requests. See the section called “Incremental Zone Transfers (IXFR)”.
-+
The minimum value is 1%. The keyword
unlimited disables ratio checking and
allows IXFRs of any size. The default is
100%.
+
Specifies the directory in which to store the configuration parameters for zones added via rndc addzone. By default, this is the working directory. If set to a relative path, it will be relative to the working directory. The directory must be writable by the effective user ID of the named process. -
+
This option controls QNAME minimization behaviour in the BIND resolver. When set to strict, BIND will follow the QNAME minimization algorithm to @@ -3006,16 +3158,20 @@ badresp:1,adberr:0,findfail:0,valfail:0] QNAME minimization completely. The current default is relaxed, but it might be changed to strict in a future release. -
+
The KRB5 keytab file to use for GSS-TSIG updates. If this option is set and tkey-gssapi-credential is not set, then updates will be allowed with any key matching a principal in the specified keytab. -
+
The security credential with which the server should authenticate keys requested by the GSS-TSIG protocol. Currently only Kerberos 5 authentication is available @@ -3028,9 +3184,11 @@ badresp:1,adberr:0,findfail:0,valfail:0] To use GSS-TSIG, tkey-domain must also be set if a specific keytab is not set with tkey-gssapi-keytab. -
+
The domain appended to the names of all shared keys
generated with TKEY. When a
client requests a TKEY exchange,
@@ -3046,9 +3204,11 @@ badresp:1,adberr:0,findfail:0,valfail:0]
"_tkey.domainname". If you are
using GSS-TSIG, this variable must be defined, unless
you specify a specific keytab using tkey-gssapi-keytab.
-
+
The Diffie-Hellman key used by the server
to generate shared keys with clients using the Diffie-Hellman
mode
@@ -3057,27 +3217,34 @@ badresp:1,adberr:0,findfail:0,valfail:0]
public and private keys from files in the working directory.
In
most cases, the key_name should be the server's host name.
-
+
This is for testing only. Do not use. -
+
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 a file on which named will
attempt to acquire a file lock when starting up for
the first time; if unsuccessful, the server will
@@ -3085,7 +3252,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
server is already running. If not specified, the default is
none.
+
Specifying lock-file none disables the
use of a lock file. lock-file is
ignored if named was run using the -X
@@ -3095,9 +3262,10 @@ badresp:1,adberr:0,findfail:0,valfail:0]
reconfigured; it is only effective when the server is
first started up.
+
The pathname of the file the server writes its process ID
in. If not specified, the default is
/var/run/named/named.pid.
@@ -3109,41 +3277,51 @@ badresp:1,adberr:0,findfail:0,valfail:0]
is a keyword, not a filename, and therefore is not enclosed
in
double quotes.
-
+
The pathname of the file the server dumps
the queries that are currently recursing when instructed
to do so with rndc recursing.
If not specified, the default is named.recursing.
-
+
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 format of the file is
described
in the section called “The Statistics File”.
-
+
The pathname of a file to override the built-in trusted
keys provided by named.
See the discussion of dnssec-validation
for details. If not specified, the default is
/etc/bind.keys.
-
+
The pathname of the file the server dumps
security roots to when instructed to do so with
rndc secroots.
If not specified, the default is
named.secroots.
-
+
The pathname of the file into which to write a TSIG
session key generated by named for use by
nsupdate -l. If not specified, the
@@ -3153,21 +3331,27 @@ badresp:1,adberr:0,findfail:0,valfail:0]
update-policy statement's
local option for more
information about this feature.)
-
+
The key name to use for the TSIG session key. If not specified, the default is "local-ddns". -
+
The algorithm to use for the TSIG session key. Valid values are hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, hmac-sha512 and hmac-md5. If not specified, the default is hmac-sha256. -
+
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 @@ -3175,23 +3359,26 @@ badresp:1,adberr:0,findfail:0,valfail:0] a server using a port other than 53 will not be able to communicate with the global DNS. -
+
The global Differentiated Services Code Point (DSCP) value to classify outgoing DNS traffic on operating systems that support DSCP. Valid values are 0 through 63. It is not configured by default. -
+
Specifies a source of entropy to be used by the server. This is a device or file from which to read entropy. If it is a file, operations requiring entropy will fail when the file has been exhausted.
-+
Entropy is needed for cryptographic operations such as TKEY transactions, dynamic update of signed zones, and generation of TSIG session keys. It is also used for @@ -3200,45 +3387,47 @@ badresp:1,adberr:0,findfail:0,valfail:0] randomness such as generation of DNS message transaction ID's.
-+
If random-device is not specified, or
if it is set to none, entropy will be
read from the random number generation function supplied
by the cryptographic library with which BIND was linked
(i.e. OpenSSL or a PKCS#11 provider).
+
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) will be emitted before other glue in the additional section of a query response. The default is to prefer A records when responding to queries that arrived via IPv4 and AAAA when responding to queries that arrived via IPv6. -
+
Turn on enforcement of delegation-only in TLDs (top level domains) and root zones with an optional exclude list.
-+
DS queries are expected to be made to and be answered by delegation only zones. Such queries and responses are treated as an exception to delegation-only processing and are not converted to NXDOMAIN responses provided a CNAME is not discovered at the query name.
-+
If a delegation only zone server also serves a child zone it is not always possible to determine whether an answer comes from the delegation only zone or the @@ -3254,24 +3443,26 @@ badresp:1,adberr:0,findfail:0,valfail:0] all these checks there is still a possibility of false negatives when a child zone is being served.
-+
Similarly false positives can arise from empty nodes (no records at the name) in the delegation only zone when the query type is not ANY.
-+
Note some TLDs are not delegation only (e.g. "DE", "LV", "US" and "MUSEUM"). This list is not exhaustive.
+
options {
root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
};
-+
Disable the specified DNSSEC algorithms at and below the specified name. Multiple disable-algorithms @@ -3279,22 +3470,22 @@ options { Only the best match disable-algorithms clause will be used to determine which algorithms are used.
-+
If all supported algorithms are disabled, the zones covered by the disable-algorithms will be treated as insecure.
-+
Configured trust anchors in trust-anchors (or managed-keys or trusted-keys, both deprecated) that match a disabled algorithm will be ignored and treated as if they were not configured at all.
-+
Disable the specified DS digest types at and below the specified name. Multiple disable-ds-digests @@ -3302,14 +3493,15 @@ options { Only the best match disable-ds-digests clause will be used to determine which digest types are used.
-+
If all supported digest types are disabled, the zones covered by the disable-ds-digests will be treated as insecure.
-+
Specify hierarchies which must be or may not be secure
(signed and validated). If yes,
then named will only accept answers if
@@ -3319,10 +3511,11 @@ options {
trust anchor, for instance in a trust-anchors
statement, or dnssec-validation auto must
be active.
-
+
This directive instructs named to return mapped IPv4 addresses to AAAA queries when there are no AAAA records. It is intended to be @@ -3330,13 +3523,13 @@ options { dns64 defines one DNS64 prefix. Multiple DNS64 prefixes can be defined.
-+
Compatible IPv6 prefixes have lengths of 32, 40, 48, 56, 64 and 96 as per RFC 6052. Bits 64..71 inclusive must be zero with the most significate bit of the prefix in position 0.
-+
Additionally a reverse IP6.ARPA zone will be created for the prefix to provide a mapping from the IP6.ARPA names to the corresponding IN-ADDR.ARPA names using synthesized @@ -3346,20 +3539,20 @@ options { are settable at the view / options level. These are not settable on a per-prefix basis.
-+
Each dns64 supports an optional
clients ACL that determines which
clients are affected by this directive. If not defined,
it defaults to any;.
+
Each dns64 supports an optional
mapped ACL that selects which
IPv4 addresses are to be mapped in the corresponding
A RRset. If not defined it defaults to
any;.
+
Normally, DNS64 won't apply to a domain name that owns one or more AAAA records; these records will simply be returned. The optional @@ -3370,7 +3563,7 @@ options { name owns. If not defined, exclude defaults to ::ffff:0.0.0.0/96.
-+
A optional suffix can also be defined to set the bits trailing the mapped IPv4 address bits. By default these bits are @@ -3378,13 +3571,13 @@ options { matching the prefix and mapped IPv4 address must be zero.
-+
If recursive-only is set to yes the DNS64 synthesis will only happen for recursive queries. The default is no.
-+
If break-dnssec is set to yes the DNS64 synthesis will happen even if the result, if validated, would @@ -3403,9 +3596,10 @@ options { suffix ::; }; -
+
When a zone is configured with auto-dnssec
maintain; its key repository must be checked
periodically to see if any new keys have been added
@@ -3418,10 +3612,11 @@ options {
the minimum is 1 (1 minute), and the
maximum is 1440 (24 hours); any higher
value is silently reduced.
-
+
If this option is set to its default value of
maintain in a zone of type
master which is DNSSEC-signed
@@ -3434,13 +3629,13 @@ options {
by regenerating RRSIG records whenever they approach
their expiration date.
+
If the option is changed to no-resign,
then named will sign all new or
changed records, but scheduled maintenance of
signatures is disabled.
+
With either of these settings, named will reject updates to a DNSSEC-signed zone when the signing keys are inactive or unavailable to @@ -3449,15 +3644,15 @@ options { signing and allow DNSSEC data to be submitted into a zone via dynamic update; this is not yet implemented.)
-+
Species the default lifetime, in seconds, that will be used for negative trust anchors added via rndc nta.
-+
A negative trust anchor selectively disables DNSSEC validation for zones that are known to be failing because of misconfiguration rather than @@ -3469,24 +3664,24 @@ options { NTA's lifetime is elapsed. NTAs persist across named restarts.
-+
For convenience, TTL-style time unit suffixes can be used to specify the NTA lifetime in seconds, minutes or hours. It also accepts ISO 8601 duration formats.
-+
nta-lifetime defaults to one hour. It
cannot exceed one week.
+
Species how often to check whether negative trust anchors added via rndc nta are still necessary.
-+
A negative trust anchor is normally used when a domain has stopped validating due to operator error; it temporarily disables DNSSEC validation for that @@ -3497,33 +3692,33 @@ options { to find out whether it can now be validated. If so, the negative trust anchor is allowed to expire early.
-+
Validity checks can be disabled for an individual
NTA by using rndc nta -f, or
for all NTAs by setting nta-recheck
to zero.
+
For convenience, TTL-style time unit suffixes can be used to specify the NTA recheck interval in seconds, minutes or hours. It also accepts ISO 8601 duration formats.
-+
The default is five minutes. It cannot be longer than
nta-lifetime (which cannot be longer
than a week).
+
Specifies a maximum permissible TTL value in seconds. For convenience, TTL-style time unit suffixes may be used to specify the maximum value. It also accepts ISO 8601 duration formats.
-+
When loading a zone file using a
masterfile-format of
text or raw,
@@ -3531,7 +3726,7 @@ options {
max-zone-ttl will cause the zone to
be rejected.
+
This is useful in DNSSEC-signed zones because when rolling to a new DNSKEY, the old key needs to remain available until RRSIG records have expired from @@ -3539,46 +3734,46 @@ options { that the largest TTL in the zone will be no higher than the set value.
-+
(NOTE: Because map-format files
load directly into memory, this option cannot be
used with them.)
+
The default value is unlimited.
A max-zone-ttl of zero is treated as
unlimited.
+
Specifies the TTL to be returned on stale answers. The default is 1 second. The minimum allowed is also 1 second; a value of 0 will be updated silently to 1 second.
-+
For stale answers to be returned, they must be enabled, either in the configuration file using stale-answer-enable or via rndc serve-stale on.
-+
Zones configured for dynamic DNS may use this option to set the update method that will be used for the zone serial number in the SOA record.
-+
With the default setting of serial-update-method increment;, the SOA serial number will be incremented by one each time the zone is updated.
-+
When set to serial-update-method unixtime;, the SOA serial number will be set to the number of seconds @@ -3586,7 +3781,7 @@ options { already greater than or equal to that value, in which case it is simply incremented by one.
-+
When set to serial-update-method date;, the new SOA serial number will be the current date @@ -3595,10 +3790,10 @@ options { than or equal to that value, in which case it is incremented by one.
-+
If full, the server will collect
statistical data on all zones (unless specifically
turned off on a per-zone basis by specifying
@@ -3612,7 +3807,7 @@ options {
current serial number, but not query type
counters).
+
These statistics may be accessed via the statistics-channel or using rndc stats, which @@ -3620,7 +3815,7 @@ options { in the statistics-file. See also the section called “The Statistics File”.
-+
For backward compatibility with earlier versions
of BIND 9, the zone-statistics
option can also accept yes
@@ -3631,15 +3826,17 @@ options {
as none; previously, it
was the same as terse.
+
If yes and supported by the operating
system, automatically rescan network interfaces when the
interface addresses are added or removed. The default is
@@ -3650,21 +3847,21 @@ options {
confirms that automatic interface scanning is supported by the
operating system.
+
The automatic-interface-scan implementation uses routing sockets for the network interface discovery, and therefore the operating system has to support the routing sockets for this feature to work.
-+
If yes, then zones can be
added at runtime via rndc addzone.
The default is no.
+
Newly added zones' configuration parameters are stored so that they can persist after the server is restarted. The configuration information @@ -3678,7 +3875,7 @@ options { incompatible with use as a file name, in which case a cryptographic hash of the view name is used instead.
-+
Zones added at runtime will have their configuration stored either in a new-zone file (NZF) or a new-zone database (NZD) depending on whether @@ -3687,34 +3884,40 @@ options { See rndc(8) for further details about rndc addzone.
-+
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 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. -
+
Write memory statistics to the file specified by
memstatistics-file at exit.
The default is no unless
'-m record' is specified on the command line in
which case it is yes.
-
+
If yes, then the
server treats all zones as if they are doing zone transfers
across
@@ -3729,14 +3932,14 @@ options {
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, then the server will send out a NOTIFY request to all the slaves (default). This should trigger the @@ -3748,7 +3951,7 @@ options { by notify and also-notify.
-+
If the zone is a slave or stub zone, then the server will suppress the regular @@ -3758,7 +3961,7 @@ options { addition to sending NOTIFY requests.
-+
Finer control can be achieved by using
notify which only sends NOTIFY
messages,
@@ -3773,7 +3976,9 @@ options {
refresh
processing.
+
Note that normal NOTIFY processing is not affected by dialup.
-+
When the nameserver exits due receiving SIGTERM,
flush or do not flush any pending zone writes. The default
is
flush-zones-on-shutdown no.
-
+
This option was part of an experimental implementation of the EDNS CLIENT-SUBNET for authoritative servers, but is now obsolete. -
+
Respond to root key sentinel probes as described in
draft-ietf-dnsop-kskroll-sentinel-08. The default is
yes.
-
+
If yes, DNS name compression is
used in responses to regular queries (not including
AXFR or IXFR, which always uses compression). Setting
@@ -3960,10 +4175,11 @@ options {
to be processed using TCP; a server with compression
disabled is out of compliance with RFC 1123 Section
6.1.3.2. The default is yes.
-
+
This option controls the addition of records to the authority and additional sections of responses. Such records may be included in responses to be helpful @@ -3976,13 +4192,13 @@ options { minimal-responses takes one of four values:
-no: the server will be
+ no: the server will be
as complete as possible when generating responses.
yes: the server will only add
+ yes: the server will only add
records to the authority and additional sections when
such records are required by the DNS protocol (for
example, when returning delegations or negative
@@ -3990,20 +4206,20 @@ options {
but may result in more client queries.
no-auth: the server
+ no-auth: the server
will omit records from the authority section except
when they are required, but it may still add records
to the additional section.
no-auth-recursive: the same
+ no-auth-recursive: the same
as no-auth when recursion is
requested in the query (RD=1), or the same as
no if recursion is not
requested.
+
no-auth and
no-auth-recursive are useful when
answering stub clients, which usually ignore the
@@ -4011,29 +4227,30 @@ options {
is meant for use in mixed-mode servers that handle both
authoritative and recursive queries.
+
The default is no-auth-recursive.
+
When set to yes, a cache is
used to improve query performance when adding
address-type (A and AAAA) glue records to the
additional section of DNS response messages that
delegate to a child zone.
+
The glue cache uses memory proportional to the number
of delegations in the zone. The default setting is
yes, which improves performance
at the cost of increased memory usage for the zone. If
you don't want this, set it to no.
+
If set to yes, then when
generating a positive response to a query of type
ANY over UDP, the server will reply with only one
@@ -4050,10 +4267,11 @@ options {
turned on for these queries, so no unnecessary records
will be added to the authority or additional sections.
The default is no.
-
+
If yes (the default),
DNS NOTIFY messages are sent when a zone the server is
authoritative for
@@ -4064,7 +4282,7 @@ options {
in the SOA MNAME field), and to any servers listed in the
also-notify option.
+
If master-only, notifies are only
sent
for master zones.
@@ -4073,7 +4291,7 @@ options {
servers explicitly listed using also-notify.
If no, no notifies are sent.
+
The notify option may also be specified in the zone statement, @@ -4082,9 +4300,10 @@ options { caused slaves to crash.
-+
If yes do not check the nameservers
in the NS RRset against the SOA MNAME. Normally a NOTIFY
message is not sent to the SOA MNAME (SOA ORIGIN) as it is
@@ -4093,9 +4312,11 @@ options {
hidden master configurations and in that case you would
want the ultimate master to still send NOTIFY messages to
all the nameservers listed in the NS RRset.
-
+
If yes, and a
DNS query requests recursion, then the server will attempt
to do
@@ -4111,9 +4332,11 @@ options {
queries.
Caching may still occur as an effect the server's internal
operation, such as NOTIFY address lookups.
-
+
If yes, then an empty EDNS(0)
NSID (Name Server Identifier) option is sent with all
queries to authoritative name servers during iterative
@@ -4122,21 +4345,24 @@ options {
the nsid category at level
info.
The default is no.
-
+
This experimental option is obsolete. -
+
Require a valid server cookie before sending a full
response to a UDP request from a cookie aware client.
BADCOOKIE is sent if there is a bad or no existent
server cookie.
The default is no.
+
Set this to yes to test that DNS
COOKIE clients correctly handle BADCOOKIE or if you are
getting a lot of forged DNS requests with DNS COOKIES
@@ -4146,10 +4372,10 @@ options {
a full response, while also requiring a legitimate client
to follow up with a second query with the new, valid, cookie.
+
When set to the default value of yes,
COOKIE EDNS options will be sent when applicable in
replies to client queries. If set to
@@ -4157,7 +4383,7 @@ options {
be sent in replies. This can only be set at the global
options level, not per-view.
+
answer-cookie no is intended as a temporary measure, for use when named shares an IP address with other servers that do not yet @@ -4168,9 +4394,10 @@ options { caution. DNS COOKIE is an important security mechanism, and should not be disabled unless absolutely necessary.
-+
If yes, then a COOKIE EDNS
option is sent along with the query. If the
resolver has previously talked to the server, the
@@ -4187,15 +4414,16 @@ options {
to receiving smaller responses via the
nocookie-udp-size option.
The default is yes.
-
+
Enable the returning of "stale" cached answers when the nameservers for a zone are not answering. The default is not to return stale answers.
-+
Stale answers can also be enabled or disabled at runtime via rndc serve-stale on or rndc serve-stale off; these @@ -4210,33 +4438,39 @@ options { rndc serve-stale on, or the server must be restarted.
-+
Information about stale answers is logged under the serve-stale log category.
-+
Sets the maximum size of UDP responses that will be sent to queries without a valid server COOKIE. A value below 128 will be silently raised to 128. The default value is 4096, but the max-udp-size option may further limit the response size. -
+
This experimental option is obsolete. -
+
Set the algorithm to be used when generating the server cookie. One of "aes", "sha1" or "sha256". The default is "aes" if supported by the cryptographic library or otherwise "sha256". -
+
If set, this is a shared secret used for generating and verifying EDNS COOKIE options within an anycast cluster. If not set, the system @@ -4245,16 +4479,16 @@ options { to be 128 bits for AES128, 160 bits for SHA1 and 256 bits for SHA256.
-+
If there are multiple secrets specified, the first
one listed in named.conf is
used to generate new server cookies. The others
will only be used to verify returned cookies.
+
The EDNS Padding option is intended to improve confidentiality when DNS queries are sent over an encrypted channel by reducing the variability in @@ -4281,7 +4515,7 @@ options { If these conditions are not met, the response is not padded.
-+
If block-size is 0 or the ACL is
none;, then this feature is
disabled and no padding will occur; this is the
@@ -4290,17 +4524,17 @@ options {
to 512. Block sizes are ordinarily expected to be powers
of two (for instance, 128), but this is not mandatory.
+
Causes named to send specially-formed queries once per day to domains for which trust anchors have been configured via, e.g., trust-anchors or dnssec-validation auto.
-+
The query name used for these queries has the form "_ta-xxxx(-xxxx)(...)".<domain>, where each "xxxx" is a group of four hexadecimal digits @@ -4308,18 +4542,19 @@ options { The key IDs for each domain are sorted smallest to largest prior to encoding. The query type is NULL.
-+
By monitoring these queries, zone operators will be able to see which resolvers have been updated to trust a new key; this may help them decide when it is safe to remove an old one.
-+
The default is yes.
+
This option is obsolete. If you need to disable IXFR to a particular server or servers, see @@ -4328,36 +4563,43 @@ options { Usage”. See also the section called “Incremental Zone Transfers (IXFR)”. -
+
See the description of provide-ixfr in the section called “server Statement Definition and Usage”. -
+
See the description of request-ixfr in the section called “server Statement Definition and Usage”. -
+
See the description of request-expire in the section called “server Statement Definition and Usage”. -
+
If yes, then an
IPv4-mapped IPv6 address will match any address match
list entries that match the corresponding IPv4 address.
+
This option was introduced to work around a kernel quirk in some operating systems that causes IPv4 TCP connections, such as zone transfers, to be accepted on an @@ -4366,10 +4608,10 @@ options { named now solves this problem internally. The use of this option is discouraged.
-+
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 via zone transfer, it will
@@ -4379,7 +4621,7 @@ options {
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 @@ -4391,7 +4633,7 @@ options { temporarily allocate memory to hold this complete difference set.
-ixfr-from-differences +
ixfr-from-differences also accepts master (or primary) and slave (or secondary) @@ -4400,14 +4642,15 @@ options { all primary or secondary zones, respectively. It is off for all zones by default.
-+
Note: if inline signing is enabled for a zone, the user-provided ixfr-from-differences setting is ignored for that zone.
-+
This should be set when you have multiple masters for a zone
and the
addresses refer to different machines. If yes, named will
@@ -4415,21 +4658,22 @@ options {
when the serial number on the master is less than what named
currently
has. The default is no.
-
+
Zones configured for dynamic DNS may use this option to allow varying levels of automatic DNSSEC key management. There are three possible settings:
-+
auto-dnssec allow; permits
keys to be updated and the zone fully re-signed
whenever the user issues the command rndc sign
zonename.
+
auto-dnssec maintain; includes the above, but also automatically adjusts the zone's DNSSEC keys on schedule, according to the keys' timing metadata @@ -4452,28 +4696,30 @@ options { interval is defined by dnssec-loadkeys-interval.)
-+
The default setting is auto-dnssec off.
-+
This option is obsolete and has no effect. -
+
This option enables DNSSEC validation in named.
-+
If set to auto,
DNSSEC validation is enabled, and a default trust anchor
for the DNS root zone is used.
+
If set to yes, DNSSEC validation is
enabled, but a trust anchor must be manually configured
using a trust-anchors statement (or
@@ -4482,17 +4728,17 @@ options {
If there is no configured trust anchor, validation will
not take place.
+
If set to no, DNSSEC validation
is disabled.
+
The default is auto, unless
BIND is built with
configure --disable-auto-validation,
in which case the default is yes.
+
The default root trust anchor is stored in the file
bind.keys.
named will load that key at
@@ -4503,16 +4749,16 @@ options {
bind.keys can be downloaded
from https://www.isc.org/bind-keys.
+
(To prevent problems if bind.keys is
not found, the current trust anchor is also compiled in
to named. Relying on this is not
recommended, however, as it requires named
to be recompiled with a new key when the root key expires.)
+
named loads only
the root key from bind.keys.
The file cannot be used to store keys for other zones.
@@ -4520,16 +4766,17 @@ options {
if dnssec-validation auto is not in
use.
+
Whenever the resolver sends out queries to an EDNS-compliant server, it always sets the DO bit indicating it can support DNSSEC responses even if dnssec-validation is off.
-+
Specifies a list of domain names at and beneath which DNSSEC validation should not be performed, regardless of the presence of a trust anchor at or above @@ -4540,25 +4787,28 @@ options { to setting a negative trust anchor, except that it is a permanent configuration, whereas negative trust anchors expire and are removed after a set period of time.) -
+
Accept expired signatures when verifying DNSSEC signatures.
The default is no.
Setting this option to yes
leaves named vulnerable to
replay attacks.
-
+
Query logging provides a complete log of all incoming queries and all query errors. This provides more insight into the server's activity, but with a cost to performance which may be significant on heavily-loaded servers.
-+
The querylog option specifies whether query logging should be active when named first starts. @@ -4569,10 +4819,10 @@ options { command rndc querylog on, or deactivated with rndc querylog off.
-+
This option is used to restrict the character set and syntax of certain domain names in master files and/or DNS responses @@ -4585,11 +4835,11 @@ options { For answers received from the network (response) the default is ignore.
-+
The rules for legal hostnames and mail domains are derived from RFC 952 and RFC 821 as modified by RFC 1123.
-check-names +
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, MX, and SRV records. @@ -4597,24 +4847,29 @@ options { name indicated that it is a reverse lookup of a hostname (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
-+
Check master zones for records that are treated as different by DNSSEC but are semantically equal in plain DNS. The default is to warn. Other possible values are fail and ignore. -
+
Check whether the MX record appears to refer to a IP address. The default is to warn. Other possible values are fail and ignore. -
+
This option is used to check for non-terminal wildcards. The use of non-terminal wildcards is almost always as a result of a failure @@ -4622,10 +4877,11 @@ options { This option affects master zones. The default (yes) is to check for non-terminal wildcards and issue a warning. -
+
Perform post load zone integrity checks on master zones. This checks that MX and SRV records refer to address (A or AAAA) records and that glue @@ -4638,7 +4894,7 @@ options { checks use named-checkzone). The default is yes.
-+
The use of the SPF record for publishing Sender Policy Framework is deprecated as the migration from using TXT records to SPF records was abandoned. @@ -4648,53 +4904,65 @@ options { TXT record does not exist and can be suppressed with check-spf.
-+
If check-integrity is set then fail, warn or ignore MX records that refer to CNAMES. The default is to warn. -
+
If check-integrity is set then fail, warn or ignore SRV records that refer to CNAMES. The default is to warn. -
+
When performing integrity checks, also check that sibling glue exists. The default is yes. -
+
If check-integrity is set then check that there is a TXT Sender Policy Framework record present (starts with "v=spf1") if there is an SPF record present. The default is warn. -
+
When returning authoritative negative responses to SOA queries set the TTL of the SOA record returned in the authority section to zero. The default is yes. -
+
When caching a negative response to a SOA query set the TTL to zero. The default is no. -
+
When set to the default value of yes,
check the KSK bit in each key to determine how the key
should be used when generating RRSIGs for a secure zone.
+
Ordinarily, zone-signing keys (that is, keys without the KSK bit set) are used to sign the entire zone, while key-signing keys (keys with the KSK bit set) are only @@ -4705,7 +4973,7 @@ options { similar to the dnssec-signzone -z command line option.
-+
When this option is set to yes, there
must be at least two active keys for every algorithm
represented in the DNSKEY RRset: at least one KSK and one
@@ -4713,10 +4981,10 @@ options {
this requirement is not met, this option will be ignored
for that algorithm.
+
When this option and update-check-ksk
are both set to yes, only key-signing
keys (that is, keys with the KSK bit set) will be used
@@ -4726,20 +4994,22 @@ options {
This is similar to the
dnssec-signzone -x command line option.
+
The default is no. If
update-check-ksk is set to
no, this option is ignored.
+
Try to refresh the zone using TCP if UDP queries fail. The default is yes. -
+
Allow a dynamic zone to transition from secure to insecure (i.e., signed to unsigned) by deleting all of the DNSKEY records. The default is no. @@ -4747,54 +5017,57 @@ options { at the zone apex is deleted, all RRSIG and NSEC records will be removed from the zone as well.
-+
If the zone uses NSEC3, then it is also necessary to delete the NSEC3PARAM RRset from the zone apex; this will cause the removal of all corresponding NSEC3 records. (It is expected that this requirement will be eliminated in a future release.)
-+
Note that if a zone has been configured with auto-dnssec maintain and the private keys remain accessible in the key repository, then the zone will be automatically signed again the next time named is started.
-+
Synthesize answers from cached NSEC, NSEC3 and other RRsets that have been proved to be correct using DNSSEC. The default is no, but it will become yes again in the future releases.
-+
Note:
+
DNSSEC validation must be enabled for this option to be effective.
-+
This initial implementation only covers synthesis of answers from NSEC records. Synthesis from NSEC3 is planned for the future. This will also be controlled by synth-from-dnssec.
--
+ +
The forwarding facility can be used to create a large site-wide cache on a few servers, reducing traffic over links to external name servers. It can also be used to allow queries by servers that @@ -4804,9 +5077,11 @@ options { the server is not authoritative and does not have the answer in its cache.
-+
This option is only meaningful if the
forwarders list is not empty. A value of first,
the default, causes the server to query the forwarders
@@ -4816,17 +5091,21 @@ options {
the answer itself. If only is
specified, the
server will only query the forwarders.
-
+
Specifies a list of IP addresses to which queries shall be forwarded. The default is the empty list (no forwarding). Each address in the list can be associated with an optional port number and/or DSCP value, and a default port number and DSCP value can be set for the entire list. -
+ +
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 @@ -4835,20 +5114,24 @@ options { or not forward at all, see the section called “zone Statement Grammar”.
-+ +
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.
-+
Specifies host names or addresses of machines with access to both IPv4 and IPv6 transports. If a hostname is used, the server must be able @@ -4857,44 +5140,49 @@ options { stacked, then the dual-stack-servers have no effect unless access to a transport has been disabled on the command line (e.g. named -4). -
+ + +
Access to the server can be restricted based on the IP address of the requesting system. See the section called “Address Match Lists” for details on how to specify IP address lists.
-+
This ACL specifies which hosts may send NOTIFY messages
to inform this server of changes to zones for which it
is acting as a secondary server. This is only
applicable for secondary zones (i.e., type
secondary or slave).
+
If this option is set in view or options, it is globally applied to all secondary zones. If set in the zone statement, the global value is overridden.
-+
If not specified, the default is to process NOTIFY messages only from the configured masters for the zone. allow-notify can be used to expand the list of permitted hosts, not to reduce it.
-+
Specifies which hosts are allowed to ask ordinary DNS questions. allow-query may also be specified in the zone @@ -4903,49 +5191,50 @@ options { If not specified, the default is to allow queries from all hosts.
-+
allow-query-cache is now used to specify access to the cache.
-+
Specifies which local addresses can accept ordinary DNS questions. This makes it possible, for instance, to allow queries on internal-facing interfaces but disallow them on external-facing ones, without necessarily knowing the internal network's addresses.
-+
Note that allow-query-on is only checked for queries that are permitted by allow-query. A query must be allowed by both ACLs, or it will be refused.
-+
allow-query-on may also be specified in the zone statement, in which case it overrides the options allow-query-on statement.
-+
If not specified, the default is to allow queries on all addresses.
-+
allow-query-cache is used to specify access to the cache.
-+
Specifies which hosts are allowed to get answers from the cache. If allow-query-cache is not set then allow-recursion @@ -4954,9 +5243,11 @@ options { set in which case none; is used, otherwise the default (localnets; localhost;) is used. -
+
Specifies which local addresses can send answers from the cache. If allow-query-cache-on is not set, then allow-recursion-on is @@ -4967,9 +5258,11 @@ options { satisfied before a cache response can be sent; a client that is blocked by one cannot be allowed by the other. -
+
Specifies which hosts are allowed to make recursive queries through this server. If allow-recursion is not set @@ -4978,9 +5271,11 @@ options { is used if set, otherwise the default (localnets; localhost;) is used. -
+
Specifies which local addresses can accept recursive queries. If allow-recursion-on is not set, then allow-query-cache-on @@ -4993,21 +5288,22 @@ options { satisfied before recursion is allowed; a client that is blocked by one cannot be allowed by the other. -
+
When set in the zone statement for a master zone, specifies which hosts are allowed to submit Dynamic DNS updates to that zone. The default is to deny updates from all hosts.
-+
Note that allowing updates based on the requestor's IP address is insecure; see the section called “Dynamic Update Security” for details.
-+
In general this option should only be set at the zone level. While a default value can be set at the options or @@ -5015,10 +5311,10 @@ options { this could lead to some zones unintentionally allowing updates.
-+
When set in the zone statement for
a slave zone, specifies which hosts are allowed to
submit Dynamic DNS updates and have them be forwarded
@@ -5026,7 +5322,7 @@ options {
{ none; }, which means that no
update forwarding will be performed.
+
To enable update forwarding, specify
allow-update-forwarding { any; };.
in the zone statement.
@@ -5036,13 +5332,13 @@ options {
access control should rest with the master server, not
the slave.
+
Note that enabling the update forwarding feature on a slave server may expose master servers to attacks if they rely on insecure IP-address-based access control; see the section called “Dynamic Update Security” for more details.
-+
In general this option should only be set at the zone level. While a default value can be set at the options or @@ -5050,9 +5346,10 @@ options { this can lead to some zones unintentionally forwarding updates.
-+
This option was introduced for the smooth transition from AAAA to A6 and from "nibble labels" to binary labels. @@ -5060,11 +5357,13 @@ options { 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 @@ -5073,26 +5372,31 @@ options { options or view. If not specified, the default is to allow transfers to all hosts. -
+
Specifies a list of addresses that the
server will not accept queries from or use to resolve a
query. Queries
from these addresses will not be responded to. The default
is none.
-
+
Specifies a list of addresses to which the server
will send responses to TCP queries in the same order
in which they were received. This disables the
processing of TCP queries in parallel. The default
is none.
-
+
Specifies a list of addresses which require responses to use case-insensitive compression. This ACL can be used when named needs to work with @@ -5100,7 +5404,7 @@ options { 1034 to use case-insensitive name comparisons when checking for matching domain names.
-+
If left undefined, the ACL defaults to none: case-insensitive compression will be used for all clients. If the ACL is defined and @@ -5108,7 +5412,7 @@ options { compressing domain names in DNS responses sent to that client.
-+
This can result in slightly smaller responses: if a response contains the names "example.com" and "example.COM", case-insensitive compression would treat @@ -5120,12 +5424,12 @@ options { match the query, which is required by some clients due to incorrect use of case-sensitive comparisons.
-+
Case-insensitive compression is always used in AXFR and IXFR responses, regardless of whether the client matches this ACL.
-+
There are circumstances in which named will not preserve the case of owner names of records: if a zone file defines records of different types with @@ -5140,10 +5444,10 @@ options { have their case preserved unless the client matches this ACL.
-+
The amount of time in milliseconds that the resolver
will spend attempting to resolve a recursive
query before failing. The default and minimum
@@ -5152,19 +5456,22 @@ options {
0 will result in the default
being used.
+
This value was originally specified in seconds. Values less than or equal to 300 will be be treated as seconds and converted to milliseconds before applying the above limits.
-+ +
The interfaces and ports that the server will answer queries
from may be specified using the listen-on option. listen-on takes
an optional port and an address_match_list
@@ -5173,30 +5480,35 @@ options {
The server will listen on all interfaces allowed by the address
match list. If a port is not specified, port 53 will be used.
+
Multiple listen-on statements are allowed. For example,
+listen-on { 5.6.7.8; };
listen-on port 1234 { !1.2.3.4; 1.2/16; };
-+ +
will 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 no listen-on is specified, the server will listen on port 53 on all IPv4 interfaces.
-+ +
The listen-on-v6 option is used to specify the interfaces and the ports on which the server will listen for incoming queries sent using IPv6. If not specified, the server will listen on port 53 on all IPv6 interfaces.
-+ +
When
{ any; }
is @@ -5211,7 +5523,8 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; }; If the system only has incomplete API support for IPv6, however, the behavior is the same as that for IPv4.
-+ +
A list of particular IPv6 addresses can also be specified, in which case the server listens on a separate socket for each specified @@ -5220,30 +5533,38 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; }; IPv4 addresses specified in listen-on-v6 will be ignored, with a logged warning.
-+ +
Multiple listen-on-v6 options can be used. For example,
+listen-on-v6 { any; };
listen-on-v6 port 1234 { !2001:db8::/32; any; };
-+ +
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
+listen-on-v6 { none; };
-+ +
If the server doesn't know the answer to a question, it will query other name servers. query-source specifies the address and port used for such queries. For queries sent over @@ -5252,7 +5573,8 @@ listen-on-v6 port 1234 { !2001:db8::/32; any; }; a wildcard IP address (INADDR_ANY) will be used.
-+ +
If port is * or is omitted, a random port number from a pre-configured range is picked up and will be used for each query. @@ -5263,15 +5585,18 @@ listen-on-v6 port 1234 { !2001:db8::/32; any; }; the avoid-v4-udp-ports and avoid-v6-udp-ports options, respectively.
-+ +
The defaults of the query-source and query-source-v6 options are:
+query-source address * port *; query-source-v6 address * port *;-
+ +
If use-v4-udp-ports or use-v6-udp-ports is unspecified, named will check if the operating @@ -5281,10 +5606,12 @@ query-source-v6 address * port *; named will use the corresponding system default range; otherwise, it will use its own defaults:
+use-v4-udp-ports { range 1024 65535; };
use-v6-udp-ports { range 1024 65535; };
-+ +
Note: make sure the ranges be sufficiently large for security. A desirable size depends on various parameters, but we generally recommend it contain at least 16384 ports @@ -5300,7 +5627,8 @@ use-v6-udp-ports { range 1024 65535; }; ranges are sufficiently large and are reasonably independent from the ranges used by other applications.
-+ +
Note: the operational configuration where named runs may prohibit the use of some ports. For example, UNIX systems will not allow @@ -5312,15 +5640,18 @@ use-v6-udp-ports { range 1024 65535; }; It is therefore important to configure the set of ports that can be safely used in the expected operational environment.
-+ +
The defaults of the avoid-v4-udp-ports and avoid-v6-udp-ports options are:
+avoid-v4-udp-ports {};
avoid-v6-udp-ports {};
-+ +
Note: BIND 9.5.0 introduced the use-queryport-pool option to support a pool of such random ports, but this @@ -5332,57 +5663,67 @@ avoid-v6-udp-ports {}; query-source-v6 options; it implicitly disables the use of randomized port numbers.
-+
This option is obsolete. -
+
This option is obsolete. -
+
This option is obsolete. -
+
The address specified in the query-source option is used for both UDP and TCP queries, but the port applies only to UDP queries. TCP queries always use a random unprivileged port.
-+
Solaris 2.5.1 and earlier does not support setting the source address for TCP sockets.
-+
See also transfer-source and notify-source.
-+ +
BIND has mechanisms in place to facilitate zone transfers and set limits on the amount of load that transfers place on the system. The following options apply to zone transfers.
-+
Defines a global list of IP addresses of name servers that are also sent NOTIFY messages whenever a fresh copy of the @@ -5400,7 +5741,7 @@ avoid-v6-udp-ports {}; In place of explicit addresses, one or more named masters lists can be used.
-+
If an also-notify list is given in a zone statement, it will override @@ -5413,37 +5754,46 @@ avoid-v6-udp-ports {}; the empty list (no global notification list).
-+
Inbound zone transfers running longer than this many minutes will be terminated. The default is 120 minutes (2 hours). The maximum value is 28 days (40320 minutes). -
+
Inbound zone transfers making no progress in this many minutes will be terminated. The default is 60 minutes (1 hour). The maximum value is 28 days (40320 minutes). -
+
Outbound zone transfers running longer than this many minutes will be terminated. The default is 120 minutes (2 hours). The maximum value is 28 days (40320 minutes). -
+
Outbound zone transfers making no progress in this many minutes will be terminated. The default is 60 minutes (1 hour). The maximum value is 28 days (40320 minutes). -
+
The rate at which NOTIFY requests will be sent during normal zone maintenance operations. (NOTIFY requests due to initial zone loading are subject @@ -5451,18 +5801,22 @@ avoid-v6-udp-ports {}; 20 per second. The lowest possible rate is one per second; when set to zero, it will be silently raised to one. -
+
The rate at which NOTIFY requests will be sent when the name server is first starting up, or when zones have been newly added to the nameserver. The default is 20 per second. The lowest possible rate is one per second; when set to zero, it will be silently raised to one. -
+
Slave servers will periodically query master servers to find out if zone serial numbers have changed. Each such query uses a minute amount of @@ -5474,9 +5828,12 @@ avoid-v6-udp-ports {}; per second. The default is 20 per second. The lowest possible rate is one per second; when set to zero, it will be silently raised to one. -
+
Zone transfers can be sent using two different formats, one-answer and many-answers. @@ -5496,10 +5853,12 @@ avoid-v6-udp-ports {}; transfer-format may be overridden on a per-server basis by using the server statement. -
+
This is an upper bound on the uncompressed size of DNS messages used in zone transfers over TCP. If a message grows larger than this size, additional messages will be @@ -5509,7 +5868,7 @@ avoid-v6-udp-ports {}; fit within the size limit, a larger message will be permitted so the record can be transferred.)
-+
Valid values are between 512 and 65535 octets, and any
values outside that range will be adjusted to the nearest
value within it. The default is 20480,
@@ -5519,30 +5878,35 @@ avoid-v6-udp-ports {};
as effectively, because 16536 is the largest permissible
compression offset pointer in a DNS message.
+
This option is mainly intended for server testing; there is rarely any benefit in setting a value other than the default.
-+
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 will be refused. The default value is 10.
-
+
The maximum number of inbound zone transfers that can be concurrently transferring from a given remote name server. @@ -5554,10 +5918,11 @@ avoid-v6-udp-ports {}; the load on the remote name server. transfers-per-ns may be overridden on a per-server basis by using the transfers phrase of the server statement. -
transfer-source +
transfer-source determines which local address will be bound to IPv4 TCP connections used to fetch zones transferred inbound by the server. It also determines the @@ -5578,28 +5943,30 @@ avoid-v6-udp-ports {}; zone block in the configuration file.
-+
Solaris 2.5.1 and earlier does not support setting the source address for TCP sockets.
-+
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.
-If you do not wish the alternate transfer source @@ -5610,24 +5977,28 @@ avoid-v6-udp-ports {}; query.
+
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. -
notify-source +
notify-source determines which local source address, and optionally UDP port, will be used to send NOTIFY messages. This address must appear in the slave @@ -5641,25 +6012,30 @@ avoid-v6-udp-ports {}; view block in the configuration file.
-+
Solaris 2.5.1 and earlier does not support setting the source address for TCP sockets.
-+
Like notify-source, but applies to notify messages sent to IPv6 addresses. -
+ +
use-v4-udp-ports, avoid-v4-udp-ports, use-v6-udp-ports, and @@ -5670,17 +6046,20 @@ avoid-v6-udp-ports {}; available ports are determined. For example, with the following configuration
+
use-v6-udp-ports { range 32768 65535; };
avoid-v6-udp-ports { 40000; range 50000 60000; };
-+ +
UDP ports of IPv6 messages sent from named will be in one of the following ranges: 32768 to 39999, 40001 to 49999, and 60001 to 65535.
-+ +
avoid-v4-udp-ports and avoid-v6-udp-ports can be used to prevent named from choosing as its random source port a @@ -5697,11 +6076,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; sense; they are provided for backward compatibility and to possibly simplify the port specification.
-+ +
The server's usage of many system resources can be limited. Scaled values are allowed when specifying resource limits. For example, 1G can be used instead of @@ -5714,7 +6095,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; that was in force when the server was started. See the description of size_spec in the section called “Configuration File Elements”.
-+ +
The following options set operating system resource limits for the name server process. Some operating systems don't support some or @@ -5722,14 +6104,18 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; the unsupported limit is used.
-+
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.
@@ -5744,31 +6130,40 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
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.
-
+ +
The following options set limits on the server's resource consumption that are enforced internally by the server rather than the operating system.
-+
Sets a maximum size for each journal file (see the section called “The journal file”), expressed in bytes or, if followed by an optional unit suffix ('k', @@ -5785,18 +6180,20 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; the zone. (There is little benefit in storing larger journals.)
-+
This option may also be set on a per-zone basis.
-+
The maximum number of records permitted in a zone. The default is zero which means unlimited. -
+
The maximum number ("hard quota") of simultaneous recursive lookups the server will perform on behalf of clients. The default is @@ -5807,14 +6204,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; recursive-clients option may have to be decreased on hosts with limited memory.
-+
recursive-clients defines a "hard
quota" limit for pending recursive clients: when more
clients than this are pending, new incoming requests
will not be accepted, and for each incoming request
a previous pending request will also be dropped.
+
A "soft quota" is also set. When this lower
quota is exceeded, incoming requests are accepted, but
for each one, a pending request will be dropped.
@@ -5824,18 +6221,20 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
otherwise it is set to 90% of
recursive-clients.
+
The maximum number of simultaneous client TCP
connections that the server will accept.
The default is 150.
-
These set the +
These set the initial value (minimum) and maximum number of recursive simultaneous clients for any given query (<qname,qtype,qclass>) that the server will accept @@ -5843,7 +6242,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; self tune this value and changes will be logged. The default values are 10 and 100.
-+
This value should reflect how many queries come in for a given name in the time it takes to resolve that name. If the number of queries exceed this value, named will @@ -5853,22 +6252,22 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; estimate will then be lowered in 20 minutes if it has remained unchanged.
-+
If clients-per-query is set to zero, then there is no limit on the number of clients per query and no queries will be dropped.
-+
If max-clients-per-query is set to zero, then there is no upper bound other than imposed by recursive-clients.
-+
The maximum number of simultaneous iterative
queries to any one domain that the server will
permit before blocking new queries for data
@@ -5878,7 +6277,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
would take to resolve them. It should be smaller
than recursive-clients.
+
When many clients simultaneously query for the
same name and type, the clients will all be attached
to the same fetch, up to the
@@ -5890,7 +6289,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
max-clients-per-query is not
effective as a limit.
+
Optionally, this value may be followed by the keyword
drop or fail,
indicating whether queries which exceed the fetch
@@ -5898,12 +6297,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
or answered with SERVFAIL. The default is
drop.
+
If fetches-per-zone is set to zero, then there is no limit on the number of fetches per query and no queries will be dropped. The default is zero.
-+
The current list of active fetches can be dumped by running rndc recursing. The list includes the number of active fetches for each @@ -5916,12 +6315,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; next time a fetch is sent to that domain, it is recreated with the counters set to zero.)
-+
The maximum number of simultaneous iterative
queries that the server will allow to be sent to
a single upstream name server before blocking
@@ -5931,7 +6330,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
would take to resolve them. It should be smaller
than recursive-clients.
+
Optionally, this value may be followed by the keyword
drop or fail,
indicating whether queries will be dropped with no
@@ -5940,12 +6339,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
exceeded the per-server quota. The default is
fail.
+
If fetches-per-server is set to zero, then there is no limit on the number of fetches per query and no queries will be dropped. The default is zero.
-+
The fetches-per-server quota is dynamically adjusted in response to detected congestion. As queries are sent to a server @@ -5961,15 +6360,15 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; can be used to adjust the parameters for this calculation.
-+
Sets the parameters to use for dynamic resizing of
the fetches-per-server quota in
response to detected congestion.
+
The first argument is an integer value indicating how frequently to recalculate the moving average of the ratio of timeouts to responses for each @@ -5977,7 +6376,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; the average ratio after every 100 queries have either been answered or timed out.
-+
The remaining three arguments represent the "low" threshold (defaulting to a timeout ratio of 0.1), the "high" threshold (defaulting to a timeout @@ -5992,10 +6391,10 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; precision of 1/100: at most two places after the decimal point are significant.
-+
The number of file descriptors reserved for TCP, stdio,
etc. This needs to be big enough to cover the number of
interfaces named listens on plus
@@ -6006,12 +6405,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
maximum value is 128 less than
maxsockets (-S). This option may be removed in the future.
+
This option has little effect on Windows.
-+
The maximum amount of memory to use for the server's cache, in bytes or % of total physical memory. When the amount of data in the cache @@ -6034,9 +6434,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; once at startup, so named will not adjust the cache size if the amount of physical memory is changed during runtime. -
+
The listen queue depth. The default and minimum is 10. If the kernel supports the accept filter "dataready" this also controls how @@ -6046,9 +6448,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; less than 10 will be silently raised. A value of 0 may also be used; on most platforms this sets the listen queue length to a system-defined default value. -
+
The amount of time (in units of 100 milliseconds) the server waits on a new TCP connection for the first message from the client. The default is 300 (30 seconds), @@ -6060,9 +6464,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; have enough time to submit a message.) This value can be updated at runtime by using rndc tcp-timeouts. -
+
The amount of time (in units of 100 milliseconds) the server waits on an idle TCP connection before closing it when the client is not using the EDNS TCP keepalive @@ -6074,9 +6480,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; for clients using the EDNS TCP keepalive option. This value can be updated at runtime by using rndc tcp-timeouts. -
+
The amount of time (in units of 100 milliseconds) the server waits on an idle TCP connection before closing it when the client is using the EDNS TCP keepalive @@ -6090,9 +6498,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; to use TCP connections for more than one message. This value can be updated at runtime by using rndc tcp-timeouts. -
+
The timeout value (in units of 100 milliseconds) the server will send in respones containing the EDNS TCP keepalive option. This informs a client of the @@ -6104,19 +6514,26 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; same value as tcp-keepalive-timeout. This value can be updated at runtime by using rndc tcp-timeouts. -
+
This option is obsolete. -
+
The server will perform zone maintenance tasks for all zones marked as dialup whenever this interval expires. The default is 60 minutes. Reasonable @@ -6124,9 +6541,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; to 1 day (1440 minutes). The maximum value is 28 days (40320 minutes). If set to 0, no zone maintenance for these zones will occur. -
+
The server will scan the network interface list every interface-interval minutes. The default @@ -6142,13 +6561,17 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; For convenience, TTL-style time unit suffixes may be used to specify the value. It also accepts ISO 8601 duration formats. -
+ +
The response to a DNS query may consist of multiple resource records (RRs) forming a resource record set (RRset). The name server will normally return the RRs within the RRset in an @@ -6162,7 +6585,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; client's address. This only requires configuring the name servers, not all the clients.
-+ +
The sortlist statement (see below) takes an address_match_list and interprets it in a special way. Each top level statement in the @@ -6174,7 +6598,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; the query until a match is found. When the addresses in the first element overlap, the first rule to match gets selected.
-+
Once the source address of the query has been matched, if the top level statement contains only one element, the actual primitive element that matched the source address is used to @@ -6185,7 +6609,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; 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 most @@ -6198,6 +6622,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; the 192.168.5/24 network will only prefer other addresses on their directly connected networks.
+sortlist {
// IF the local host
// THEN first fit on the following nets
@@ -6221,7 +6646,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
{ { 192.168.4/24; 192.168.5/24; };
};
};
-+ +
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 @@ -6231,16 +6657,19 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; directly connected network will prefer addresses on that same network. Responses to other queries will not be sorted.
+sortlist {
{ localhost; localnets; };
{ localnets; };
};
-+ +
When multiple records are returned in an answer it may be useful to configure the order of the records placed into the response. The rrset-order statement permits @@ -6249,24 +6678,25 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; See also the sortlist statement, the section called “The sortlist Statement”.
-+
An order_spec is defined as follows:
-+
[class class_name]
[type type_name]
[name "domain_name"]
order ordering
+
If no class is specified, the default is ANY. If no type is specified, the default is ANY. If no name is specified, the default is "*" (asterisk).
-+
The legal values for ordering are:
-+
-
+
For example:
rrset-order {
@@ -6340,46 +6771,52 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
order cyclic;
};
-+
will cause any responses for type A records in class IN that
have "host.example.com" as a
suffix, to always be returned
in random order. All other records are returned in cyclic order.
+
If multiple rrset-order statements appear, they are not combined — the last one applies.
-+
By default, records are returned in random order.
-+
In this release of BIND 9, the rrset-order statement does not support "fixed" ordering by default. Fixed ordering can be enabled at compile time by specifying "--enable-fixed-rrset" on the "configure" command line.
-+
Sets the number of seconds to cache a
lame server indication. 0 disables caching. (This is
NOT recommended.)
The default is 600 (10 minutes) and the
maximum value is
1800 (30 minutes).
-
+
Sets the number of seconds to cache a SERVFAIL response due to DNSSEC validation failure or other general server failure. If set to @@ -6389,16 +6826,16 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; query that failed due to DNSSEC validation to be retried without waiting for the SERVFAIL TTL to expire.
-+
The maximum value is 30
seconds; any higher value will be silently
reduced. The default is 1
second.
+
To reduce network traffic and increase performance, the server stores negative answers. min-ncache-ttl is used to set a minimum retention time for these answers in the @@ -6406,33 +6843,33 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; suffixes may be used to specify the value. It also accepts ISO 8601 duration formats.
-+
The default min-ncache-ttl is
0 seconds.
min-ncache-ttl cannot exceed 90
seconds and will be truncated to 90 seconds if set to a
greater value.
+
Sets the minimum time for which the server will cache ordinary (positive) answers in seconds. For convenience, TTL-style time unit suffixes may be used to specify the value. It also accepts ISO 8601 duration formats.
-+
The default min-cache-ttl is
0 seconds.
min-cache-ttl cannot exceed 90
seconds and will be truncated to 90 seconds if set to a
greater value.
+
To reduce network traffic and increase performance, the server stores negative answers. max-ncache-ttl is @@ -6441,34 +6878,34 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; suffixes may be used to specify the value. It also accepts ISO 8601 duration formats.
-+
The default max-ncache-ttl is
10800 seconds (3 hours).
max-ncache-ttl cannot exceed 7 days and
will be silently truncated to 7 days if set to a greater
value.
+
Sets the maximum time for which the server will cache ordinary (positive) answers in seconds. For convenience, TTL-style time unit suffixes may be used to specify the value. It also accepts ISO 8601 duration formats.
-+
The default is 604800 (one week). A value of zero may cause all queries to return SERVFAIL, because of lost caches of intermediate RRsets (such as NS and glue AAAA/A records) in the resolution process.
-+
If stale answers are enabled, max-stale-ttl sets the maximum time for which the server will @@ -6479,26 +6916,30 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; 1 second; a value of 0 will be updated silently to 1 second.
-+
For stale answers to be returned, they must be enabled, either in the configuration file using stale-answer-enable or via rndc serve-stale on.
-+
Specifies how many retries occur before exponential
backoff kicks in. The default is 3.
-
+
The base retry interval in milliseconds.
The default is 800.
-
+
Specifies the number of days into the future when DNSSEC signatures automatically generated as a result of dynamic updates (the section called “Dynamic Update”) will expire. There @@ -6512,25 +6953,26 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; giving a re-signing interval of 7 1/2 days. The maximum values are 10 years (3660 days).
-+
The signature inception time is unconditionally set to one hour before the current time to allow for a limited amount of clock skew.
-+
The sig-validity-interval can be overridden for DNSKEY records by setting dnskey-sig-validity.
-+
The sig-validity-interval should be, at least, several multiples of the SOA expire interval to allow for reasonable interaction between the various timer and expiry dates.
-+
Specifies the number of days into the future when DNSSEC signatures that are automatically generated for DNSKEY RRsets as a result of dynamic updates @@ -6541,33 +6983,38 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; sig-validity-interval is used. The maximum value is 3660 days (10 years), and higher values will be rejected. -
+
Specify the maximum number of nodes to be
examined in each quantum when signing a zone with
a new DNSKEY. The default is
100.
-
+
Specify a threshold number of signatures that
will terminate processing a quantum when signing
a zone with a new DNSKEY. The default is
10.
-
+
Specify a private RDATA type to be used when generating
signing state records. The default is
65534.
+
It is expected that this parameter may be removed in a future version once there is a standard type.
-+
Signing state records are used to internally by
named to track the current state of
a zone-signing process, i.e., whether it is still active
@@ -6583,12 +7030,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
records for a zone, use
rndc signing -clear all zone.
+
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, @@ -6596,14 +7043,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; 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 in seconds 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.
-+
The following defaults apply. min-refresh-time 300 seconds, max-refresh-time 2419200 seconds @@ -6611,10 +7058,10 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; and max-retry-time 1209600 seconds (2 weeks).
-+
Sets the maximum advertised EDNS UDP buffer size in bytes, to control the size of packets received from authoritative servers in response to recursive queries. @@ -6622,19 +7069,19 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; will be silently adjusted to the nearest value within it). The default value is 4096.
-+
The usual reason for setting edns-udp-size to a non-default value is to get UDP answers to pass through broken firewalls that block fragmented packets and/or block UDP DNS packets that are greater than 512 bytes.
-+
When named first queries a remote server, it will advertise a UDP buffer size of 512, as this has the greatest chance of success on the first try.
-+
If the initial query is successful with EDNS advertising a buffer size of 512, then named will advertise progressively @@ -6642,7 +7089,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; responses begin timing out or edns-udp-size is reached.
-+
The default buffer sizes used by named are 512, 1232, 1432, and 4096, but never exceeding edns-udp-size. (The values 1232 and @@ -6650,22 +7097,22 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; UDP message to be sent without fragmentation at the minimum MTU sizes for Ethernet and IPv6 networks.)
-+
Sets the maximum EDNS UDP message size named will send in bytes. Valid values are 512 to 4096 (values outside this range will be silently adjusted to the nearest value within it). The default value is 4096.
-+
This value applies to responses sent by a server; to set the advertised buffer size in queries, see edns-udp-size.
-+
The usual reason for setting max-udp-size to a non-default value is to get UDP answers to pass through broken @@ -6674,14 +7121,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; This is independent of the advertised receive buffer (edns-udp-size).
-+
Setting this to a low value will encourage additional TCP traffic to the nameserver.
-Specifies +
Specifies
the file format of zone files (see
the section called “Additional File Formats”).
The default value is text, which is the
@@ -6692,7 +7139,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
named-compilezone tool, or dumped by
named.
+
Note that when a zone file in a different format than
text is loaded, named
may omit some of the checks which would be performed for a
@@ -6706,7 +7153,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
loaded directly into memory via memory mapping, with only
minimal checking.
+
This statement sets the masterfile-format for all zones, but can be overridden on a per-zone or per-view basis @@ -6715,16 +7162,16 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; view block in the configuration file.
-+
Specifies the formatting of zone files during dump
when the masterfile-format is
text. (This option is ignored
with any other masterfile-format.)
+
When set to relative,
records are printed in a multi-line format with owner
names expressed relative to a shared origin. When set
@@ -6737,11 +7184,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
zone is to be edited by hand. The default is
relative.
+
Sets the maximum number of levels of recursion that are permitted at any one time while servicing a recursive query. Resolving a name may require @@ -6750,11 +7198,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; of indirections exceeds this value, the recursive query is terminated and returns SERVFAIL. The default is 7. -
+
Sets the maximum number of iterative queries that may be sent while servicing a recursive query. If more queries are sent, the recursive query @@ -6762,35 +7212,38 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; look up top level domains such as "com" and "net" and the DNS root zone are exempt from this limitation. The default is 75. -
+
The delay, in seconds, between sending sets of notify messages for a zone. The default is five (5) seconds.
-+
The overall rate that NOTIFY messages are sent for all zones is controlled by serial-query-rate.
-+
The maximum RSA exponent size, in bits, that will be accepted when validating. Valid values are 35 to 4096 bits. The default zero (0) is also accepted and is equivalent to 4096. -
+
When a query is received for cached data which is to expire shortly, named can refresh the data from the authoritative server immediately, ensuring that the cache always has an answer available.
-+
The prefetch specifies the
"trigger" TTL value at which prefetch of the current
query will take place: when a cache record with a
@@ -6802,7 +7255,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
prefetch to be disabled.
The default trigger TTL is 2.
+
An optional second argument specifies the "eligibility"
TTL: the smallest original
TTL value that will be accepted for a record to be
@@ -6812,19 +7265,24 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
adjust it upward.
The default eligibility TTL is 9.
+
When determining the next nameserver to try
preference IPv6 nameservers by this many milliseconds.
The default is 50 milliseconds.
-
+ +
The server provides some helpful diagnostic information
through a number of built-in zones under the
pseudo-top-level-domain bind in the
@@ -6843,17 +7301,18 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
rate-limit is set to allow
three responses per second.
+
If you need to disable these zones, use the options below, or hide the built-in CHAOS view by defining an explicit view of class CHAOS that matches all clients.
-+
The version the server should report
via a query of the name version.bind
with type TXT, class CHAOS.
@@ -6861,14 +7320,15 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
Specifying version none
disables processing of the queries.
+
Setting version to any value
(including none) will also
disable queries for authors.bind TXT CH.
+
The hostname the server should report via a query of
the name hostname.bind
with type TXT, class CHAOS.
@@ -6879,9 +7339,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
identify which of a group of anycast servers is actually
answering your queries. Specifying hostname none;
disables processing of the queries.
-
+
The ID the server should report when receiving a Name
Server Identifier (NSID) query, or a query of the name
ID.SERVER with type
@@ -6893,13 +7355,17 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
Specifying server-id hostname; will cause named to
use the hostname as found by the gethostname() function.
The default server-id is none.
-
+ +
The named server has some built-in empty zones (SOA and NS records only). These are for zones that should normally be answered locally @@ -6912,13 +7378,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; IPv6 link local addresses, the IPv6 loopback address and the IPv6 unknown address.
-+
The server will attempt to determine if a built-in zone already exists or is active (covered by a forward-only forwarding declaration) and will not create an empty zone in that case.
-+
The current list of empty zones is:
-
+
Empty zones are settable at the view level and only apply to views of class IN. Disabled empty zones are only inherited from options if there are no disabled empty zones specified @@ -7036,7 +7502,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
-
+
If you are using the address ranges covered here, you should already have reverse zones covering the addresses you use. In practice this appears to not be the case with many queries @@ -7045,7 +7511,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; to be deployed to channel the query load away from the infrastructure servers.
-The real parent servers for these zones should disable all @@ -7054,35 +7520,45 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; enable them to return referrals to deeper in the tree.
+
Specify what server name will appear in the returned SOA record for empty zones. If none is specified, then the zone's name will be used. -
+
Specify what contact name will appear in the returned SOA record for empty zones. If none is specified, then "." will be used. -
+
Enable or disable all empty zones. By default, they are enabled. -
+
Disable individual empty zones. By default, none are disabled. This option can be specified multiple times. -
+ +
BIND 9 provides the ability to filter out DNS responses from external DNS servers containing certain types of data in the answer section. @@ -7108,10 +7584,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; deny-answer-aliases,
www.example.com. CNAME xxx.example.com.-
+ +
returned by an "example.com" server will be accepted.
-+ +
In the address_match_list of the
deny-answer-addresses option, only
ip_addr
@@ -7119,12 +7597,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
are meaningful;
any key_id will be silently ignored.
+ +
If a response message is rejected due to the filtering, the entire message is discarded without being cached, and a SERVFAIL error will be returned to the client.
-+ +
This filtering is intended to prevent "DNS rebinding attacks," in which an attacker, in response to a query for a domain name the attacker controls, returns an IP address within your own network or @@ -7139,39 +7619,48 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; for more details about the attacks.
-+ +
For example, if you own a domain named "example.net" and your internal network uses an IPv4 prefix 192.0.2.0/24, you might specify the following rules:
+deny-answer-addresses { 192.0.2.0/24; } except-from { "example.net"; };
deny-answer-aliases { "example.net"; };
-+ +
If an external attacker lets a web browser in your local network look up an IPv4 address of "attacker.example.com", the attacker's DNS server would return a response like this:
+attacker.example.com. A 192.0.2.1-
+ +
in the answer section. Since the rdata of this record (the IPv4 address) matches the specified prefix 192.0.2.0/24, this response will be ignored.
-+ +
On the other hand, if the browser looks up a legitimate internal web server "www.example.net" and the following response is returned to the BIND 9 server
+www.example.net. A 192.0.2.2-
+ +
it will be accepted since the owner name "www.example.net" matches the except-from element, "example.net".
-+ +
Note that this is not really an attack on the DNS per se. In fact, there is nothing wrong for an "external" name to be mapped to your "internal" IP address or domain name @@ -7192,7 +7681,8 @@ deny-answer-aliases { "example.net"; }; very sure you have no other choice and the attack is a real threat for your applications.
-+ +
Care should be particularly taken if you want to use this option for addresses within 127.0.0.0/8. These addresses are obviously "internal", but many @@ -7201,11 +7691,13 @@ deny-answer-aliases { "example.net"; }; Filtering out DNS records containing this address spuriously can break such applications.
-+ +
BIND 9 includes a limited mechanism to modify DNS responses for requests analogous to email anti-spam DNS blacklists. @@ -7213,7 +7705,8 @@ deny-answer-aliases { "example.net"; }; deny the existence of IP addresses for domains (NODATA), or contain other IP addresses or data.
-+ +
Response policy zones are named in the response-policy option for the view or among the global options if there is no response-policy option for the view. @@ -7224,7 +7717,8 @@ deny-answer-aliases { "example.net"; }; Note that zones using masterfile-format map cannot be used as policy zones.
-+ +
A response-policy option can support multiple policy zones. To maximize performance, a radix tree is used to quickly identify response policy zones @@ -7233,20 +7727,22 @@ deny-answer-aliases { "example.net"; }; in a single response-policy option; more than that is a configuration error.
-+ +
Rules encoded in response policy zones are processed after Access Control Lists (ACLs). All queries from clients which are not permitted access to the resolver will be answered with a status code of REFUSED, regardless of configured RPZ rules.
-+ +
Five policy triggers can be encoded in RPZ records.
+
IP records are triggered by the IP address of the DNS client. Client IP address triggers are encoded in records that have @@ -7261,7 +7757,8 @@ deny-answer-aliases { "example.net"; }; B4 is the decimal value of the least significant byte of the IPv4 address as in IN-ADDR.ARPA.
-+ +
IPv6 addresses are encoded in a format similar
to the standard IPv6 text representation,
prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-client-ip.
@@ -7277,24 +7774,29 @@ deny-answer-aliases { "example.net"; };
encodings.
The IPv6 prefix length must be between 1 and 128.
+
QNAME policy records are triggered by query names of requests and targets of CNAME records resolved to generate the response. The owner name of a QNAME policy record is the query name relativized to the policy zone. -
+
IP triggers are IP addresses in an A or AAAA record in the ANSWER section of a response. They are encoded like client-IP triggers except as subdomains of rpz-ip. -
+
NSDNAME triggers match names of authoritative servers for the query name, a parent of the query name, a CNAME for query name, or a parent of a CNAME. @@ -7307,10 +7809,11 @@ deny-answer-aliases { "example.net"; }; The nsdname-enable phrase turns NSDNAME triggers off or on for a single policy zone or all zones. -
+
NSIP triggers match the IP addresses of authoritative servers. They are enncoded like IP triggers, except as subdomains of rpz-nsip. @@ -7322,7 +7825,7 @@ deny-answer-aliases { "example.net"; }; triggers off or on for a single policy zone or all zones.
-+
If a name server's IP address is not yet known, named will recursively look up the IP address before applying an RPZ-NSIP rule. @@ -7341,11 +7844,12 @@ deny-answer-aliases { "example.net"; }; rules should always be applied even if an address needs to be looked up first.
--
+ +
The query response is checked against all response policy zones, so two or more policy records can be triggered by a response. Because DNS responses are rewritten according to at most one @@ -7374,14 +7878,16 @@ deny-answer-aliases { "example.net"; };
-
+ +
When the processing of a response is restarted to resolve DNAME or CNAME records and a policy record set has not been triggered, all response policy zones are again consulted for the DNAME or CNAME names and addresses.
-+ +
RPZ record sets are any types of DNS record except DNAME or DNSSEC that encode actions or responses to individual queries. @@ -7393,48 +7899,59 @@ deny-answer-aliases { "example.net"; };
+
The whitelist policy is specified by a CNAME whose target is rpz-passthru. It causes the response to not be rewritten and is most often used to "poke holes" in policies for CIDR blocks. -
+
The blacklist policy is specified by a CNAME whose target is rpz-drop. It causes the response to be discarded. Nothing is sent to the DNS client. -
+
The "slip" policy is specified by a CNAME whose target is rpz-tcp-only. It changes UDP responses to short, truncated DNS responses that require the DNS client to try again with TCP. It is used to mitigate distributed DNS reflection attacks. -
+
The domain undefined response is encoded by a CNAME whose target is the root domain (.) -
+
The empty set of resource records is specified by CNAME whose target is the wildcard top-level domain (*.). It rewrites the response to NODATA or ANCOUNT=0. -
+
A set of ordinary DNS records can be used to answer queries. Queries for record types not the set are answered with NODATA.
-+ +
A special form of local data is a CNAME whose target is a wildcard such as *.example.com. It is used as if were an ordinary CNAME after the asterisk (*) @@ -7442,11 +7959,12 @@ deny-answer-aliases { "example.net"; }; The purpose for this special form is query logging in the walled garden's authority DNS server.
--
+ +
All of the actions specified in all of the individual records in a policy zone can be overridden with a policy clause in the @@ -7457,11 +7975,14 @@ deny-answer-aliases { "example.net"; };
The placeholder policy says "do not override but +
The placeholder policy says "do not override but perform the action specified in the zone." -
+
The testing override policy causes policy zone records to do nothing but log what they would have done if the policy zone were not disabled. @@ -7471,22 +7992,28 @@ deny-answer-aliases { "example.net"; }; Disabled policy zones should appear first, because they will often not be logged if a higher precedence trigger is found first. -
+
override with the corresponding per-record policy. -
+
causes all RPZ policy records to act as if they were "cname domain" records. -
-
+ +
By default, the actions encoded in a response policy zone are applied only to queries that ask for recursion (RD=1). That default can be changed for a single policy zone or @@ -7497,7 +8024,8 @@ deny-answer-aliases { "example.net"; }; delete answers that would otherwise contain RFC 1918 values on the externally visible name server or view.
-+ +
Also by default, RPZ actions are applied only to DNS requests that either do not request DNSSEC metadata (DO=0) or when no DNSSEC records are available for request name in the original @@ -7508,7 +8036,8 @@ deny-answer-aliases { "example.net"; }; clause option reflects the fact that results rewritten by RPZ actions cannot verify.
-+ +
No DNS records are needed for a QNAME or Client-IP trigger. The name or IP address itself is sufficient, so in principle the query name need not be recursively resolved. @@ -7535,13 +8064,15 @@ deny-answer-aliases { "example.net"; }; appear to be rewritten, since no recursion is being done to discover problems at the authoritative server.
-+ +
The dnsrps-enable yes option turns on the DNS Rsponse Policy Service (DNSRPS) interface, if it has been compiled in to named using configure --enable-dnsrps.
-+ +
The dnsrps-options block provides additional RPZ configuration settings, which are passed through to the DNSRPS provider library. @@ -7552,7 +8083,8 @@ deny-answer-aliases { "example.net"; }; concatenated with settings derived from the response-policy statement.
-+ +
Note: The dnsrps-options text should only include configuration settings that are specific to the DNSRPS provider. For example, the DNSRPS provider from @@ -7568,7 +8100,8 @@ deny-answer-aliases { "example.net"; }; dnsrps-enable to "no", those options would be ignored.
-+ +
The TTL of a record modified by RPZ policies is set from the TTL of the relevant record in policy zone. It is then limited to a maximum value. @@ -7579,15 +8112,16 @@ deny-answer-aliases { "example.net"; }; formats.
-+ +
For example, you might use this option statement
response-policy { zone "badlist"; };
-+
and this zone statement
zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };
-+
with this zone file
$TTL 1H @@ -7629,7 +8163,7 @@ example.com CNAME rpz-tcp-only. *.example.com CNAME rpz-tcp-only.-
+
RPZ can affect server performance. Each configured response policy zone requires the server to perform one to four additional database lookups before a @@ -7644,23 +8178,27 @@ example.com CNAME rpz-tcp-only. A server with four response policy zones with QNAME and IP triggers might have a maximum QPS rate about 50% lower.
-+ +
Responses rewritten by RPZ are counted in the RPZRewrites statistics.
-+ +
The log clause can be used to optionally turn off rewrite logging for a particular response policy zone. By default, all rewrites are logged.
-+ +
The add-soa option controls whether the RPZ's
SOA record is added to the additional section for traceback
of changes from this zone or not. This can be set at the
individual policy zone level or at the response-policy level.
The default is yes.
+ +
Updates to RPZ zones are processed asynchronously; if there is more than one update pending they are bundled together. If an update to a RPZ zone (for example, via IXFR) happens less @@ -7671,11 +8209,13 @@ example.com CNAME rpz-tcp-only. used to specify the value. It also accepts ISO 8601 duration formats.
-+ +
Excessive almost identical UDP responses can be controlled by configuring a rate-limit clause in an @@ -7688,7 +8228,8 @@ example.com CNAME rpz-tcp-only. Legitimate clients react to dropped or truncated response by retrying with UDP or with TCP respectively.
-+ +
This mechanism is intended for authoritative DNS servers. It can be used on recursive servers but can slow applications such as SMTP servers (mail receivers) and @@ -7696,7 +8237,8 @@ example.com CNAME rpz-tcp-only. same domains. When possible, closing "open" recursive servers is better.
-+ +
Response rate limiting uses a "credit" or "token bucket" scheme. Each combination of identical response and client has a conceptual account that earns a specified number @@ -7715,7 +8257,8 @@ example.com CNAME rpz-tcp-only. When the specified number of credits for a class of responses is set to 0, those responses are not rate limited.
-+ +
The notions of "identical response" and "DNS client" for rate limiting are not simplistic. All responses to an address block are counted as if to a @@ -7724,7 +8267,8 @@ example.com CNAME rpz-tcp-only. specified with ipv4-prefix-length (default 24) and ipv6-prefix-length (default 56).
-+ +
All non-empty responses for a valid domain name (qname) and record type (qtype) are identical and have a limit specified with responses-per-second @@ -7748,12 +8292,14 @@ example.com CNAME rpz-tcp-only. referrals-per-second (default responses-per-second).
-+ +
Responses generated from local wildcards are counted and limited as if they were for the parent domain name. This controls flooding using random.wild.example.com.
-+ +
All requests that result in DNS errors other than NXDOMAIN, such as SERVFAIL and FORMERR, are identical regardless of requested name (qname) or record type (qtype). @@ -7764,7 +8310,8 @@ example.com CNAME rpz-tcp-only. but it can be set separately with errors-per-second.
-+ +
Many attacks using DNS involve UDP requests with forged source addresses. Rate limiting prevents the use of BIND 9 to flood a network @@ -7788,7 +8335,8 @@ example.com CNAME rpz-tcp-only. cannot be replaced with truncated responses and are instead leaked at the slip rate.
-+ +
(NOTE: Dropped responses from an authoritative server may reduce the difficulty of a third party successfully forging a response to a recursive resolver. The best security @@ -7801,7 +8349,8 @@ example.com CNAME rpz-tcp-only. responses to be truncated rather than dropped. This reduces the effectiveness of rate-limiting against reflection attacks.)
-+ +
When the approximate query per second rate exceeds the qps-scale value, then the responses-per-second, @@ -7819,7 +8368,8 @@ example.com CNAME rpz-tcp-only. Responses sent via TCP are not limited but are counted to compute the query per second rate.
-+ +
Communities of DNS clients can be given their own parameters or no rate limiting by putting rate-limit statements in view @@ -7831,7 +8381,8 @@ example.com CNAME rpz-tcp-only. DNS clients within a view can be exempted from rate limits with the exempt-clients clause.
-+ +
UDP responses of all kinds can be limited with the all-per-second phrase. This rate limiting is unlike the rate limiting provided by @@ -7864,7 +8415,8 @@ example.com CNAME rpz-tcp-only. or parsing DNS requests, but that rate limiting must be done before the DNS server sees the requests.
-+ +
The maximum size of the table used to track requests and rate limit responses is set with max-table-size. Each entry in the table is between 40 and 80 bytes. @@ -7878,21 +8430,24 @@ example.com CNAME rpz-tcp-only. expansions of the table and inform choices for the initial and maximum table size.
-+ +
Use log-only yes to test rate limiting parameters without actually dropping any requests.
-+ +
Responses dropped by rate limits are included in the RateDropped and QryDropped statistics. Responses that truncated by rate limits are included in RateSlipped and RespTruncated.
-+
Named supports NXDOMAIN redirection via two methods:
-
+
With both methods when named gets a NXDOMAIN response it examines a separate namespace to see if the NXDOMAIN response should be replaced with an alternative response.
-+
With a redirect zone (zone "." { type redirect; };), the data used to replace the NXDOMAIN is held in a single zone which is not part of the normal namespace. All the redirect information is contained in the zone; there are no delegations.
-+
With a redirect namespace (option { nxdomain-redirect <suffix> };) the data used to replace the NXDOMAIN is part of the normal namespace and is looked up by @@ -7925,16 +8480,17 @@ example.com CNAME rpz-tcp-only. the replacement data or a NXDOMAIN indicating that there is no replacement.
-+
If both a redirect zone and a redirect namespace are configured, the redirect zone is tried first.
-+server-netprefix{ bogusboolean; ednsboolean; @@ -7968,12 +8524,14 @@ example.com CNAME rpz-tcp-only. transfersinteger; };
+ +
The server statement defines
characteristics
to be associated with a remote name server. If a prefix length is
@@ -7982,7 +8540,8 @@ example.com CNAME rpz-tcp-only.
server clause applies regardless of the order in
named.conf.
+ +
The server statement can occur at the top level of the configuration file or inside a view @@ -7997,13 +8556,14 @@ example.com CNAME rpz-tcp-only. used as defaults.
-+ +
If you discover that a remote server is giving out bad data, marking it as bogus will prevent further queries to it. The default value of bogus is no.
-+
The provide-ixfr clause determines whether the local server, acting as master, will respond with an @@ -8019,7 +8579,8 @@ example.com CNAME rpz-tcp-only. view or global options block is used as a default.
-+ +
The request-ixfr clause determines whether the local server, acting as a slave, will request incremental zone @@ -8029,7 +8590,8 @@ example.com CNAME rpz-tcp-only. also be set in the zone block and, if set there, it will override the global or view setting for that zone.
-+ +
IXFR requests to servers that do not support IXFR will automatically fall back to AXFR. Therefore, there is no need to manually list @@ -8043,7 +8605,8 @@ example.com CNAME rpz-tcp-only. and slave claim to support it, for example if one of the servers is buggy and crashes or corrupts data when IXFR is used.
-+ +
The request-expire clause determines whether the local server, when acting as a slave, will request the EDNS EXPIRE value. The EDNS EXPIRE value @@ -8055,12 +8618,14 @@ example.com CNAME rpz-tcp-only. record instead. The default is yes.
-+ +
The edns clause determines whether the local server will attempt to use EDNS when communicating with the remote server. The default is yes.
-+ +
The edns-udp-size option sets the EDNS UDP size that is advertised by named when querying the remote server. Valid values are 512 @@ -8079,7 +8644,8 @@ example.com CNAME rpz-tcp-only. behavior may be brought into conformance with the options/view behavior in future releases.)
-+ +
The edns-version option sets the maximum EDNS VERSION that will be sent to the server(s) by the resolver. The actual EDNS version sent is still @@ -8094,7 +8660,8 @@ example.com CNAME rpz-tcp-only. adjusted. This option will not be needed until higher EDNS versions than 0 are in use.
-+ +
The max-udp-size option sets the maximum EDNS UDP message size named will send. Valid values are 512 to 4096 bytes (values @@ -8102,7 +8669,8 @@ example.com CNAME rpz-tcp-only. option is useful when you know that there is a firewall that is blocking large replies from named.
-+ +
The padding option adds EDNS Padding options to outgoing messages, increasing the packet size to a multiple of the specified block size. Valid block sizes @@ -8114,18 +8682,21 @@ example.com CNAME rpz-tcp-only. would have to be added to the packet after it had already been signed.
-+ +
The tcp-only option sets the transport protocol to TCP. The default is to use the UDP transport and to fallback on TCP only when a truncated response is received.
-+ +
The tcp-keepalive option adds EDNS TCP keepalive to messages sent over TCP. Note currently idle timeouts in responses are ignored.
-+ +
The server supports two zone transfer methods. The first, 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 @@ -8139,14 +8710,16 @@ example.com CNAME rpz-tcp-only. by the options statement will be used.
-transfers + +
transfers is used to limit the number of concurrent inbound zone transfers from the specified server. If no transfers clause is specified, the limit is set according to the transfers-per-ns option.
-+ +
The keys clause identifies a key_id defined by the key statement, to be used for transaction security (TSIG, the section called “TSIG”) @@ -8157,10 +8730,12 @@ example.com CNAME rpz-tcp-only. required to be signed by this key.
-+ +
Only a single key per server is currently supported.
-+ +
The transfer-source and transfer-source-v6 clauses specify the IPv4 and IPv6 source @@ -8176,7 +8751,8 @@ example.com CNAME rpz-tcp-only. transfer-source-v6 in the section called “Zone Transfers”.
-+ +
The notify-source and notify-source-v6 clauses specify the IPv4 and IPv6 source address to be used for notify @@ -8185,7 +8761,8 @@ example.com CNAME rpz-tcp-only. can be specified. Similarly, for an IPv6 remote server, only notify-source-v6 can be specified.
-+ +
The query-source and query-source-v6 clauses specify the IPv4 and IPv6 source address to be used for queries @@ -8194,14 +8771,16 @@ example.com CNAME rpz-tcp-only. be specified. Similarly, for an IPv6 remote server, only query-source-v6 can be specified.
-+ +
The request-nsid clause determines whether the local server will add a NSID EDNS option to requests sent to the server. This overrides request-nsid set at the view or option level.
-+ +
The send-cookie clause determines whether the local server will add a COOKIE EDNS option to requests sent to the server. This overrides @@ -8210,11 +8789,12 @@ example.com CNAME rpz-tcp-only. determine that COOKIE is not supported by the remote server and not add a COOKIE EDNS option to requests.
-+statistics-channels { inet (-ipv4_address|ipv6_address| * ) [ port (integer| * ) ] [ @@ -8222,18 +8802,21 @@ example.com CNAME rpz-tcp-only. } ]; };
+ +
The statistics-channels statement declares communication channels to be used by system administrators to get access to statistics information of the name server.
-+ +
This statement intends to be flexible to support multiple communication protocols in the future, but currently only HTTP access is supported. @@ -8243,7 +8826,8 @@ example.com CNAME rpz-tcp-only. still accepted even if it is built without the library, but any HTTP access will fail with an error.
-+ +
An inet control channel is a TCP socket
listening at the specified ip_port on the
specified ip_addr, which can be an IPv4 or IPv6
@@ -8254,12 +8838,14 @@ example.com CNAME rpz-tcp-only.
To listen on the IPv6 wildcard address,
use an ip_addr of ::.
+ +
If no port is specified, port 80 is used for HTTP channels.
The asterisk "*" cannot be used for
ip_port.
+ +
The attempt of opening a statistics channel is restricted by the optional allow clause. Connections to the statistics channel are permitted based on the @@ -8271,11 +8857,13 @@ example.com CNAME rpz-tcp-only. recommended to restrict the source of connection requests appropriately.
-+ +
If no statistics-channels statement is present, named will not open any communication channels.
-+ +
The statistics are available in various formats and views depending on the URI used to access them. For example, if the statistics channel is configured to listen on 127.0.0.1 @@ -8287,7 +8875,8 @@ example.com CNAME rpz-tcp-only. charts and graphs using the Google Charts API when using a javascript-capable browser.
-+ +
Broken-out subsets of the statistics can be viewed at http://127.0.0.1:8888/xml/v3/status (server uptime and last reconfiguration time), @@ -8304,7 +8893,8 @@ example.com CNAME rpz-tcp-only. http://127.0.0.1:8888/xml/v3/traffic (traffic sizes).
-+ +
The full set of statistics can also be read in JSON format at http://127.0.0.1:8888/json, with the broken-out subsets at @@ -8323,26 +8913,28 @@ example.com CNAME rpz-tcp-only. http://127.0.0.1:8888/json/v1/traffic (traffic sizes).
-+trust-anchors {-string( static-key | initial-key | static-ds | initial-ds )integerintegerintegerquoted_string; ... };
+ +
The trust-anchors statement defines DNSSEC trust anchors. DNSSEC is described in the section called “DNSSEC”.
-+
A trust anchor is defined when the public key or public key digest for a non-authoritative zone is known, but cannot be securely obtained through DNS, either because it is the DNS @@ -8350,34 +8942,34 @@ example.com CNAME rpz-tcp-only. or digest has been configured as a trust anchor, it is treated as if it had been validated and proven secure.
-+
The resolver attempts DNSSEC validation on all DNS data in subdomains of configured trust anchors. (Validation below specified names can be temporarily disabled by using rndc nta, or permanently disabled with the validate-except option).
-+
All keys listed in trust-anchors, and their corresponding zones, are deemed to exist regardless of what parent zones say. Only keys configured as trust anchors are used to validate the DNSKEY RRset for the corresponding name. The parent's DS RRset will not be used.
-+
trust-anchors may be set at the top level
of named.conf or within a view. If it is
set in both places, the configurations are additive: keys
defined at the top level are inherited by all views, but keys
defined in a view are only used within that view.
+
The trust-anchors statement can contain multiple trust anchor entries, each consisting of a domain name, followed by an "anchor type" keyword indicating the trust anchor's format, followed by the key or digest data.
-+
If the anchor type is static-key or initial-key, then it is followed with the key's flags, protocol, algorithm, and the Base64 representation @@ -8386,7 +8978,7 @@ example.com CNAME rpz-tcp-only. carriage returns are ignored in the key data, so the configuration may be split up into multiple lines.
-+
If the anchor type is static-ds or initial-ds, then it is followed with the key tag, algorithm, digest type, and the hexadecimal @@ -8394,7 +8986,7 @@ example.com CNAME rpz-tcp-only. text representation of a DS record. Spaces, tabs, newlines and carriage returns are ignored.
-+
Trust anchors configured with the static-key or static-ds anchor types are immutable, while keys configured with @@ -8404,7 +8996,7 @@ example.com CNAME rpz-tcp-only. keys are identical to keys configured using the deprecated trusted-keys statement.)
-+
Suppose, for example, that a zone's key-signing key was compromised, and the zone owner had to revoke and replace the key. A resolver which had the original key @@ -8415,7 +9007,7 @@ example.com CNAME rpz-tcp-only. updated the trust-anchors statement with the new key.
-+
If, however, the trust anchor had been configured with initial-key or initial-ds instead, then the zone owner could add a "stand-by" key to @@ -8428,7 +9020,7 @@ example.com CNAME rpz-tcp-only. This is the process used to keep the ICANN root DNSSEC key up to date.
-+
Whereas static-key and static-ds trust anchors continue to be trusted until they are removed from @@ -8438,11 +9030,11 @@ example.com CNAME rpz-tcp-only. takes to load the managed key database and start the RFC 5011 key maintenance process.
-+
It is not possible to mix static with initial trust anchors for the same domain name.
-+
The first time named runs with an
initial-key or initial-ds
configured in named.conf, it fetches the
@@ -8452,7 +9044,7 @@ example.com CNAME rpz-tcp-only.
the trust anchor, then it is used as the basis for a new
managed keys database.
+
From that point on, whenever named runs, it sees the initial-key or initial-ds listed in @@ -8464,7 +9056,7 @@ example.com CNAME rpz-tcp-only. superseded by the key or keys stored in the managed keys database.
-+
The next time named runs after an initial-key or initial-ds trust anchor has been removed from the @@ -8474,11 +9066,11 @@ example.com CNAME rpz-tcp-only. database, and RFC 5011 key maintenance will no longer be used for that domain.
-+
In the current implementation, the managed keys database is stored as a master-format zone file.
-+
On servers which do not use views, this file is named
managed-keys.bind. When views are in
use, there will be a separate managed keys database for each
@@ -8487,7 +9079,7 @@ example.com CNAME rpz-tcp-only.
a hash of the view name), followed by
the suffix .mkeys.
+
When the key database is changed, the zone is updated. As with any other dynamic zone, changes will be written into a journal file, e.g., @@ -8501,7 +9093,7 @@ example.com CNAME rpz-tcp-only. (For this reason among others, the working directory should be always be writable by named.)
-+
If the dnssec-validation option is
set to auto, named
will automatically initialize an initial-key
@@ -8513,11 +9105,12 @@ example.com CNAME rpz-tcp-only.
found, the initializing key is also compiled directly
into named.
+dnssec-policy-string{ dnskey-ttlduration; keys { ( csk | ksk | zsk ) key-directory lifetime (duration| unlimited ) algorithminteger[integer] ; ... }; @@ -8533,34 +9126,36 @@ example.com CNAME rpz-tcp-only. zone-propagation-delayduration; };
+ +
The dnssec-policy statement defines a key and signing policy (KASP) for zones.
-+
A KASP determines how one or more zones will be signed with DNSSEC. For example, it specifies how often keys should roll, which cryptographic algorithms to use, and how often RRSIG records need to be refreshed.
-+
Keys are not shared among zones, which means that one set of keys per zone will be generated even if they have the same policy. If multiple views are configured with different versions of the same zone, each separate version will use the same set of signing keys.
-+
Multiple key and signing policies can be configured. To attach a policy to a zone, add a dnssec-policy option to the zone statement, specifying he name of the policy that should be used.
-+
Key rollover timing is computed for each key according to the key lifetime defined in the KASP. The lifetime may be modified by zone TTLs and propagation delays, in order to @@ -8571,14 +9166,14 @@ example.com CNAME rpz-tcp-only. new one, and finally retire the old key according to a computed schedule.
-+
Zone-signing key (ZSK) rollovers require no operator input. Key-signing key (KSK) and combined signing key (CSK) rollovers require action to be taken to submit a DS record to the parent. Rollover timing for KSKs and CSKs is adjusted to take into account delays in processing and propagating DS updates.
-+
There are two predefined dnssec-policy names: none and default. Setting a zone's policy to @@ -8603,7 +9198,7 @@ example.com CNAME rpz-tcp-only.
-
+
If a dnssec-policy statement is modified and the server restarted or reconfigured, named will attempt to change the policy smoothly from the old one to @@ -8619,19 +9214,22 @@ example.com CNAME rpz-tcp-only.
-
+
The following options can be specified in a dnssec-policy statement:
-+
The TTL to use when generating DNSKEY resource records. The default is 1 hour (3600 seconds). -
+
A list specifying the algorithms and roles to use when generating keys and signing the zone. Entries in this list do not represent specific @@ -8641,18 +9239,20 @@ example.com CNAME rpz-tcp-only. that the DNSKEY RRset will always include a key-signing key for that algorithm.
-+
Here is an example (for illustration purposes only) of some possible entries in a keys list:
+keys {
ksk key-directory lifetime unlimited algorithm rsasha1 2048;
zsk lifetime P30D algorithm 8;
csk lifetime P6MT12H3M15S algorithm ecdsa256;
};
-+ +
This example specifies that three keys should be used
in the zone. The first token determines which role the
key will play in signing RRsets. If set to
@@ -8666,14 +9266,14 @@ example.com CNAME rpz-tcp-only.
csk the key will have the KSK
flag set and will be used to sign all RRsets.
+
An optional second token determines where the key will be stored. Currently, keys can only be stored in the configured key-directory. This token may be used in the future to store keys in hardware service modules or separate directories.
-+
The lifetime parameter specifies how long a key may be used before rolling over. In the example above, the first key will have an unlimited @@ -8682,14 +9282,14 @@ example.com CNAME rpz-tcp-only. 12 hours, 3 minutes and 15 seconds. A lifetime of 0 seconds is the same as unlimited.
-+
Note that the lifetime of a key may be extended if retiring it too soon would cause validation failures. For example, if the key were configured to roll more frequently than its own TTL, its lifetime would automatically be extended to account for this.
-+
The algorithm parameter specifies the key's algorithm, expressed either as a string ("rsasha256", "ecdsa384", etc) or as a decimal number. @@ -8698,47 +9298,57 @@ example.com CNAME rpz-tcp-only. example for the second and third keys, an appropriate default size for the algorithm will be used.
-+
A margin that is added to the pre-publication
interval in rollover timing calculations to give some
extra time to cover unforeseen events. This increases
the time that keys are published before becoming active.
The default is PT1H (1 hour).
-
+
A margin that is added to the post-publication interval
in rollover timing calculations to give some extra time
to cover unforeseen events. This increases the time a key
remains published after it is no longer active. The
default is PT1H (1 hour).
-
+
This determines how frequently an RRSIG record needs to be
refreshed. The signature is renewed when the time until
the expiration time is closer than the specified interval.
The default is P5D (5 days), meaning
signatures that will expire in 5 days or sooner will be
refreshed.
-
+
The validity period of an RRSIG record (subject to
inception offset and jitter). The default is
P2W (2 weeks).
-
+
Similar to signatures-validity but for
DNSKEY records. The default is P2W
(2 weeks).
-
+
Like the max-zone-ttl zone option,
this specifies the maximum permissible TTL value in
seconds for the zone. When loading a zone file using
@@ -8748,7 +9358,7 @@ example.com CNAME rpz-tcp-only.
max-zone-ttl will be capped at the
maximum permissible TTL value.
+
This is needed in DNSSEC-maintained zones because when rolling to a new DNSKEY, the old key needs to remain available until RRSIG records have expired from caches. @@ -8756,87 +9366,101 @@ example.com CNAME rpz-tcp-only. the largest TTL in the zone will be no higher than the set value.
-+
(NOTE: Because map-format files
load directly into memory, this option cannot be
used with them.)
+
The default value is PT24H (24 hours).
A max-zone-ttl of zero is treated as if
the default value were in use.
+
The expected propagation delay from the time when a zone
is first updated to the time when the new version of the
zone will be served by all secondary servers. The default
is PT5M (5 minutes).
-
+
The TTL of the DS RRset that the parent zone uses. The
default is P1D (1 day).
-
+
The expected propagation delay from the time when the
parent zone is updated to the time when the new version
is served by all of the parent zone's name servers.
The default is PT1H (1 hour).
-
+
The expected registration delay from the time when a DS
RRset change is requested to the time when the DS RRset
will be updated in the parent zone. The default is
P1D (1 day).
-
+managed-keys {-string( static-key | initial-key | static-ds | initial-ds )integerintegerintegerquoted_string; ... }; deprecated
+ +
The managed-keys statement has been deprecated in favor of the section called “trust-anchors Statement Grammar” with the initial-key keyword.
-+trusted-keys {-stringintegerintegerintegerquoted_string; ... }; deprecated
+ +
The trusted-keys statement has been deprecated in favor of the section called “trust-anchors Statement Grammar” with the static-key keyword.
-view-view_name[class] { match-clients {address_match_list} ; match-destinations {address_match_list} ; @@ -8845,11 +9469,13 @@ example.com CNAME rpz-tcp-only. [zone_statement; ... ] } ;
+ +
The view statement is a powerful feature of BIND 9 that lets a name server @@ -8858,7 +9484,8 @@ example.com CNAME rpz-tcp-only. implementing split DNS setups without having to run multiple servers.
-+ +
Each view statement defines a view of the DNS namespace that will be seen by a subset of clients. A client @@ -8886,7 +9513,8 @@ example.com CNAME rpz-tcp-only. a client request will be resolved in the context of the first view that it matches.
-+ +
Zones defined within a view statement will only be accessible to clients that match the view. @@ -8895,7 +9523,8 @@ example.com CNAME rpz-tcp-only. "internal" and "external" clients in a split DNS setup.
-+ +
Many of the options given in the options statement can also be used within a view statement, and then @@ -8908,12 +9537,14 @@ example.com CNAME rpz-tcp-only. view-specific defaults take precedence over those in the options statement.
-+ +
Views are class specific. If no class is given, class IN is assumed. Note that all non-IN views must contain a hint zone, since only the IN class has compiled-in default hints.
-+ +
If there are no view statements in the config file, a default view that matches any client is automatically @@ -8929,10 +9560,12 @@ example.com CNAME rpz-tcp-only. statements must occur inside view statements.
-+ +
Here is an example of a typical split DNS setup implemented using view statements:
+view "internal" {
// This should match our internal networks.
match-clients { 10.0.0.0/8; };
@@ -8965,11 +9598,13 @@ view "external" {
};
};
-zone-string[class] { type ( master | primary ); @@ -9218,14 +9853,16 @@ view "external" { in-viewstring; };
+
The type keyword is required
for the zone configuration unless
it is an in-view configuration. Its
@@ -9240,75 +9877,84 @@ view "external" {
static-stub,
and stub.
| + |
- |
-+ |
The server has a master copy of the data
for the zone and will be able to provide authoritative
- answers for it. Type |
| + |
- |
-+ |
- A secondary zone is a replica of a master
- zone. Type |
| + |
|
-+ |
A stub zone is similar to a slave zone, except that it replicates only the NS records of a @@ -9361,30 +10007,93 @@ view "external" { |
| + |
|
-+ |
- A mirror zone is similar to a zone of type
-
+ A mirror zone acts like a zone of type
+ + While any zone may be configured with this type, + it is intended to be used to set up a fast local + copy of the root zone, similar to the one + described in RFC 7706. Note, however, that + mirror zones are not supposed to augment the + example configuration provided by RFC 7706 but + rather to replace it altogether. + ++ A default list of primary servers for the IANA + root zone is built into named + and thus its mirroring can be enabled using the + following configuration: + +zone "." {
+ type mirror;
+};
+ + In order to set up mirroring of any other zone, + an explicit list of primary servers needs to be + provided using the masters + option (see the section called “masters Statement Grammar” + for details). + ++ To make mirror zone contents persist between + named restarts, use the + file + option. + ++ Mirror zone validation always happens for the + entire zone contents, i.e. no "incremental + validation" takes place, even for IXFRs. This + is required to ensure that each version of the + zone used by the resolver is fully + self-consistent with respect to DNSSEC. Other, + more efficient zone verification methods may be + added in the future. + +
+ For validation to succeed, a key-signing key
+ (KSK) for the zone must be configured as a trust
+ anchor in Answers coming from a mirror zone look almost @@ -9395,50 +10104,27 @@ view "external" { bit ("authenticated data") is. - Mirror zones are intended to be used to set up a - fast local copy of the root zone, similar to the - one described in RFC 7706. A default list of primary - servers for the IANA root zone is built into - named and thus its mirroring - can be enabled using the following configuration: - -zone "." {
- type mirror;
-};
- - Other zones can be configured as mirror zones, - but this should be considered - experimental and may cause - performance issues, especially with zones that - are large and/or frequently updated. - Mirroring a zone other than root requires an - explicit list of primary servers to be provided - using the masters option - (see the section called “masters Statement Grammar” - for details), and a key-signing key (KSK) - for the specified zone to be explicitly - configured as a trust anchor. - -- To make mirror zone contents persist between - named restarts, use the - file - option. + Since mirror zones are intended to be used by + recursive resolvers, adding one to a view with + recursion disabled is considered to be a + configuration error.
When configuring NOTIFY for a mirror zone, only
@@ -9449,12 +10135,12 @@ view "external" { |
| + |
|
-+ |
A static-stub zone is similar to a stub zone with the following exceptions: @@ -9498,12 +10184,12 @@ view "external" { |
| + |
|
-+ |
A "forward zone" is a way to configure forwarding on a per-domain basis. A zone statement @@ -9531,12 +10217,12 @@ view "external" { |
| + |
|
-+ |
The initial set of root name servers is specified using a "hint zone". When the server starts @@ -9552,12 +10238,12 @@ view "external" { |
| + |
|
-+ |
Redirect zones are used to provide answers to queries when normal resolution would result in @@ -9617,12 +10303,12 @@ view "external" { |
| + |
|
-+ |
This is used to enforce the delegation-only status of infrastructure zones (e.g. COM, @@ -9643,17 +10329,20 @@ view "external" { |
+ +
The zone's name may optionally be followed by a class. If
a class is not specified, class IN (for Internet),
is assumed. This is correct for the vast majority of cases.
+
The hesiod class is
named for an information service from MIT's Project Athena. It
is
@@ -9662,52 +10351,69 @@ view "external" {
HS is
a synonym for hesiod.
+
Another MIT development is Chaosnet, a LAN protocol created
in the mid-1970s. Zone data for it can be specified with the CHAOS class.
+
See the description of allow-notify in the section called “Access Control”. -
+
See the description of allow-query in the section called “Access Control”. -
+
See the description of allow-query-on in the section called “Access Control”. -
+
See the description of allow-transfer in the section called “Access Control”. -
+
See the description of allow-update in the section called “Access Control”. -
+
Specifies a "Simple Secure Update" policy. See the section called “Dynamic Update Policies”. -
+
See the description of allow-update-forwarding in the section called “Access Control”. -
+
Only meaningful if notify is active for this zone. The set of machines that will @@ -9728,9 +10434,11 @@ view "external" { also-notify is not meaningful for stub zones. The default is the empty list. -
+
This option is used to restrict the character set and syntax of certain domain names in master files and/or DNS responses @@ -9738,50 +10446,68 @@ view "external" { network. The default varies according to zone type. For master zones the default is fail. For slave zones the default is warn. It is not implemented for hint zones. -
+
See the description of check-mx in the section called “Boolean Options”. -
+
See the description of check-spf in the section called “Boolean Options”. -
+
See the description of check-wildcard in the section called “Boolean Options”. -
+
See the description of check-integrity in the section called “Boolean Options”. -
+
See the description of check-sibling in the section called “Boolean Options”. -
+
See the description of zero-no-soa-ttl in the section called “Boolean Options”. -
+
See the description of update-check-ksk in the section called “Boolean Options”. -
+
See the description of dnssec-loadkeys-interval in the section called “options Statement Definition and Usage”. -
+
Specifies which key and signing policy (KASP) should
be used for this zone. This is a string referring to
a dnssec-policy statement.
@@ -9792,26 +10518,33 @@ view "external" {
The default is none.
See the section called “dnssec-policy Statement Grammar” for
more details.
-
+
See the description of dnssec-update-mode in the section called “options Statement Definition and Usage”. -
+
See the description of dnssec-dnskey-kskonly in the section called “Boolean Options”. -
+
See the description of try-tcp-refresh in the section called “Boolean Options”. -
+
Specify the type of database to be used for storing the zone data. The string following the database keyword is interpreted as a list of whitespace-delimited words. @@ -9822,40 +10555,43 @@ view "external" { specific to the database type.
-+
The default is "rbt", BIND 9's
native in-memory
red-black-tree database. This database does not take
arguments.
+
Other values are possible if additional database drivers have been linked into the server. Some sample drivers are included with the distribution but none are linked in by default.
-+
See the description of dialup in the section called “Boolean Options”. -
+
The flag only applies to forward, hint and stub
zones. If set to yes,
then the zone will also be treated as if it is
also a delegation-only type zone.
+
See caveats in root-delegation-only.
-+
Set the zone's filename. In master, hint, and redirect zones which do not have masters @@ -9866,91 +10602,120 @@ view "external" { defined, zone data is retrieved from another server and saved in this file. This option is not applicable to other zone types. -
+
Only meaningful if the zone has a forwarders list. The only value causes the lookup to fail after trying the forwarders and getting no answer, while first would allow a normal lookup to be tried. -
+
Used to override the list of global forwarders. If it is not specified in a zone of type forward, no forwarding is done for the zone and the global options are not used. -
+
Allow the default journal's filename to be overridden.
The default is the zone's filename with ".jnl" appended.
This is applicable to master and slave zones.
-
+
See the description of max-ixfr-ratio in the section called “options Statement Definition and Usage”. -
+
See the description of max-journal-size in the section called “Server Resource Limits”. -
+
See the description of max-records in the section called “Server Resource Limits”. -
+
See the description of max-transfer-time-in in the section called “Zone Transfers”. -
+
See the description of max-transfer-idle-in in the section called “Zone Transfers”. -
+
See the description of max-transfer-time-out in the section called “Zone Transfers”. -
+
See the description of max-transfer-idle-out in the section called “Zone Transfers”. -
+
See the description of notify in the section called “Boolean Options”. -
+
See the description of notify-delay in the section called “Tuning”. -
+
See the description of notify-to-soa in the section called “Boolean Options”. -
+
See the description of zone-statistics in the section called “options Statement Definition and Usage”. -
+
Only meaningful for static-stub zones. This is a list of IP addresses to which queries should be sent in recursive resolution for the @@ -9959,7 +10724,7 @@ view "external" { configure the apex NS RR with associated glue A or AAAA RRs.
-+
For example, if "example.com" is configured as a static-stub zone with 192.0.2.1 and 2001:db8::1234 in a server-addresses option, @@ -9968,7 +10733,7 @@ view "external" {
example.com. NS example.com. example.com. A 192.0.2.1 example.com. AAAA 2001:db8::1234-
+
These records are internally used to resolve names under the static-stub zone. For instance, if the server receives a query for @@ -9976,10 +10741,10 @@ example.com. AAAA 2001:db8::1234 will initiate recursive resolution and send queries to 192.0.2.1 and/or 2001:db8::1234.
-+
Only meaningful for static-stub zones. This is a list of domain names of nameservers that act as authoritative servers of the static-stub @@ -9997,7 +10762,7 @@ example.com. AAAA 2001:db8::1234 "ns.example.net" cannot, and will be rejected by the configuration parser.
-+
A non empty list for this option will internally configure the apex NS RR with the specified names. For example, if "example.com" is configured as a @@ -10009,7 +10774,7 @@ example.com. AAAA 2001:db8::1234
example.com. NS ns1.example.net. example.com. NS ns2.example.net.-
+
These records are internally used to resolve names under the static-stub zone. For instance, if the server receives a query for @@ -10019,145 +10784,189 @@ example.com. NS ns2.example.net. "ns2.example.net" to IP addresses, and then send queries to (one or more of) these addresses.
-+
See the description of sig-validity-interval in the section called “Tuning”. -
+
See the description of sig-signing-nodes in the section called “Tuning”. -
+
See the description of sig-signing-signatures in the section called “Tuning”. -
+
See the description of sig-signing-type in the section called “Tuning”. -
+
See the description of transfer-source in the section called “Zone Transfers”. -
+
See the description of transfer-source-v6 in the section called “Zone Transfers”. -
+
See the description of alt-transfer-source in the section called “Zone Transfers”. -
+
See the description of alt-transfer-source-v6 in the section called “Zone Transfers”. -
+
See the description of use-alt-transfer-source in the section called “Zone Transfers”. -
+
See the description of notify-source in the section called “Zone Transfers”. -
+
See the description of notify-source-v6 in the section called “Zone Transfers”. -
+
See the description in the section called “Tuning”. -
+
See the description of
ixfr-from-differences in the section called “Boolean Options”.
(Note that the ixfr-from-differences
master and
slave choices are not
available at the zone level.)
-
+
See the description of key-directory in the section called “options Statement Definition and Usage”. -
+
See the description of auto-dnssec in the section called “options Statement Definition and Usage”. -
+
See the description of serial-update-method in the section called “options Statement Definition and Usage”. -
+
If yes, this enables
"bump in the wire" signing of a zone, where a
unsigned zone is transferred in or loaded from
disk and a signed version of the zone is served,
with possibly, a different serial number. This
behavior is disabled by default.
-
+
See the description of multi-master in the section called “Boolean Options”. -
+
See the description of masterfile-format in the section called “Tuning”. -
+
See the description of max-zone-ttl in the section called “options Statement Definition and Usage”. -
+
See the description of dnssec-secure-to-insecure in the section called “Boolean Options”. -
BIND 9 supports two alternative + +
BIND 9 supports two alternative methods of granting clients the right to perform dynamic updates to a zone, configured by the allow-update and update-policy option, respectively.
-+
The allow-update clause is a simple access control list. Any client that matches the ACL is granted permission to update any record in the zone.
-+
The update-policy clause allows more fine-grained control over what updates are allowed. It specifies a set of rules, in which each rule @@ -10170,7 +10979,7 @@ example.com. NS ns2.example.net. to specify update permissions based on client source address.
-+
update-policy rules are only meaningful for zones of type master, and are not allowed in any other zone type. @@ -10178,7 +10987,7 @@ example.com. NS ns2.example.net. allow-update and update-policy at the same time.
-+
A pre-defined update-policy rule can be switched on with the command update-policy local;. @@ -10201,30 +11010,35 @@ example.com. NS ns2.example.net. within the zone. Assuming the key name is "local-ddns", this policy is equivalent to:
-update-policy { grant local-ddns zonesub any; };
+
+ update-policy { grant local-ddns zonesub any; };
-
+
+
...with the additional restriction that only clients
connecting from the local system will be permitted to send
updates.
-
+
Note that only one session key is generated by
named; all zones configured to use
update-policy local will accept the same key.
-
+
The command nsupdate -l implements this
feature, sending requests to localhost and signing them using
the key retrieved from the session key file.
-
+
+
Other rule definitions look like this:
+
( grant | deny ) identity ruletype [ name ] [ types ]
-
+
+
Each rule grants or denies privileges. Rules are checked
in the order in which they are specified in the
update-policy statement. Once a message
@@ -10234,7 +11048,7 @@ example.com. NS ns2.example.net.
ruletype field, and the interpretation
of other fields varies depending on the rule type.
-
+
In general, a rule is matched when the
key that signed an update request matches the
identity field, the name of the record
@@ -10244,7 +11058,7 @@ example.com. NS ns2.example.net.
types field. Details for each rule type
are described below.
-
+
The identity field must be set to
a fully-qualified domain name. In most cases, this
represensts the name of the TSIG or SIG(0) key that must be
@@ -10258,13 +11072,13 @@ example.com. NS ns2.example.net.
(e.g, "host/machine@REALM") or
Windows realm (machine$@REALM).
-
+
The name field also specifies
a fully-qualified domain name. This often
represents the name of the record to be updated.
Interpretation of this field is dependent on rule type.
-
+
If no types are explicitly specified,
then a rule matches all types except RRSIG, NS, SOA, NSEC
and NSEC3. Types may be specified by name, including
@@ -10273,7 +11087,7 @@ example.com. NS ns2.example.net.
is made to delete all records associated with a name,
the rules are checked for each existing record type.
-
+
The ruletype field has 16
values:
name, subdomain,
@@ -10286,7 +11100,8 @@ example.com. NS ns2.example.net.
tcp-self, 6to4-self,
zonesub, and external.
-
+
+
-
-
+
+
+ + +
When multiple views are in use, a zone may be referenced by more than one of them. Often, the views will contain different zones with the same name, allowing @@ -10695,7 +11513,7 @@ example.com. NS ns2.example.net. way to do this: it allows a view to reference a zone that was defined in a previously configured view. Example:
-+view internal { match-clients { 10/8; }; @@ -10713,11 +11531,11 @@ view external { }; };-+
An in-view option cannot refer to a view that is configured later in the configuration file.
-+
A zone statement which uses the in-view option may not use any other options with the exception of forward @@ -10725,41 +11543,45 @@ view external { the behavior of the containing view, rather than changing the zone object itself.)
-+
Zone level acls (e.g. allow-query, allow-transfer) and other configuration details of the zone are all set in the view the referenced zone is defined in. Care need to be taken to ensure that acls are wide enough for all views referencing the zone.
-+
An in-view zone cannot be used as a response policy zone.
-+
An in-view zone is not intended to reference a forward zone.
-
+ +
This section, largely borrowed from RFC 1034, describes the concept of a Resource Record (RR) and explains when each is used. Since the publication of RFC 1034, several new RRs have been identified and implemented in the DNS. These are also included.
-+ +
A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of @@ -10769,10 +11591,12 @@ view external { permitted for optimization purposes, for example, to specify that a particular nearby server be tried first. See the section called “The sortlist Statement” and the section called “RRset Ordering”.
-+ +
The components of a Resource Record are:
-+
The following are types of valid RRs:
-+
The following classes of resource records are currently valid in the DNS:
-+
The owner name is often implicit, rather than forming an integral part of the RR. For example, many name servers internally form @@ -11966,7 +12796,7 @@ view external { that fits the needs of the resource being described.
-+
The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative @@ -11986,17 +12816,18 @@ view external { following the change.
-+
The data in the RDATA section of RRs is carried as a combination of binary strings and domain names. The domain names are frequently used as "pointers" to other data in the DNS.
-+ +
RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when @@ -12009,13 +12840,13 @@ view external { possible using parentheses.
-+
The start of the line gives the owner of the RR. If a line begins with a blank, then the owner is assumed to be the same as that of the previous RR. Blank lines are often included for readability.
-+
Following the owner, we list the TTL, type, and class of the RR. Class and type use the mnemonics defined above, and TTL is an integer before the type field. In order to avoid ambiguity @@ -12026,14 +12857,15 @@ view external { values are often omitted from examples in the interests of clarity.
-+
The resource data or RDATA section of the RR are given using knowledge of the typical representation for the data.
-+
For example, we might show the RRs carried in a message as:
-+
The MX RRs have an RDATA section which consists of a 16-bit number followed by a domain name. The address RRs use a standard IP address format to contain a 32-bit internet address.
-+
The above example shows six RRs, with two RRs at each of three domain names.
-+
Similarly we might see:
-+
This example shows two addresses for
XX.LCS.MIT.EDU, each of a different class.
+ +
As described above, domain servers store information as a series of resource records, each of which contains a particular piece of information about a given domain name (which is usually, @@ -12208,7 +13045,8 @@ view external { and stored with some additional type information to help systems determine when the RR is relevant.
-+ +
MX records are used to control delivery of email. The data specified in the record is a priority and a domain name. The priority @@ -12225,7 +13063,7 @@ view external { It must have an associated address record (A or AAAA) — CNAME is not sufficient.
-+
For a given domain, if there is both a CNAME record and an MX record, the MX record is in error, and will be ignored. Instead, @@ -12234,7 +13072,8 @@ view external { pointed to by the CNAME. For example:
-
Mail delivery will be attempted to mail.example.com and
mail2.example.com (in
any order), and if neither of those succeed, delivery to mail.backup.org will
be attempted.
+ +
The time-to-live of the RR field is a 32-bit integer represented in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it @@ -12390,7 +13231,8 @@ view external { currently used in a zone file.
-+
All of these TTLs default to units of seconds, though units
can be explicitly specified, for example, 1h30m.
+ +
Reverse name resolution (that is, translation from IP address to name) is achieved by means of the in-addr.arpa domain and PTR records. Entries in the in-addr.arpa domain are made in @@ -12469,7 +13313,8 @@ view external { PTR records if the machine has more than one name. For example, in the [example.com] domain:
-+
The $ORIGIN lines in the examples are for providing context to the examples only — they do not necessarily appear in the actual usage. They are only used here to indicate that the example is relative to the listed origin.
-+ +
The Master File Format was initially defined in RFC 1035 and has subsequently been extended. While the Master File Format itself @@ -12523,30 +13370,32 @@ view external { same class.
-+
Master File Directives include $ORIGIN, $INCLUDE, and $TTL.
-+ +
When used in the label (or name) field, the asperand or
at-sign (@) symbol represents the current origin.
At the start of the zone file, it is the
<zone_name> (followed by
trailing dot).
+ +
Syntax: $ORIGIN
domain-name
[comment]
$ORIGIN +
$ORIGIN sets the domain name that will be appended to any unqualified records. When a zone is first read in there is an implicit $ORIGIN @@ -12556,42 +13405,47 @@ view external { the domain specified in the $ORIGIN argument if it is not absolute.
+$ORIGIN example.com. WWW CNAME MAIN-SERVER-
+ +
is equivalent to
+WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.-
+ +
Syntax: $INCLUDE
filename
[
origin ]
[ comment ]
+
Read and process the file filename as
if it were included into the file at this point. If origin is
specified the file is processed with $ORIGIN set
to that value, otherwise the current $ORIGIN is
used.
+
The origin and the current domain name revert to the values they had prior to the $INCLUDE once the file has been read.
-+
RFC 1035 specifies that the current origin should be restored after an $INCLUDE, but it is silent @@ -12601,31 +13455,33 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. This could be construed as a deviation from RFC 1035, a feature, or both.
-+ +
Syntax: $GENERATE
range
lhs
@@ -12635,7 +13491,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
rhs
[comment]
$GENERATE +
$GENERATE is used to create a series of resource records that only differ from each other by an iterator. $GENERATE can be used to @@ -12643,12 +13499,15 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA delegation.
+$ORIGIN 0.0.192.IN-ADDR.ARPA. $GENERATE 1-2 @ NS SERVER$.EXAMPLE. $GENERATE 1-127 $ CNAME $.0-
+ +
is equivalent to
+0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE. 0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE. 1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA. @@ -12656,18 +13515,22 @@ $GENERATE 1-127 $ CNAME $.0... 127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA. -
+ +
Generate a set of A and MX records. Note the MX's right hand side is a quoted string. The quotes will be stripped when the right hand side is processed.
+$ORIGIN EXAMPLE. $GENERATE 1-127 HOST-$ A 1.2.3.$ $GENERATE 1-127 HOST-$ MX "0 ."-
+ +
is equivalent to
+HOST-1.EXAMPLE. A 1.2.3.1 HOST-1.EXAMPLE. MX 0 . HOST-2.EXAMPLE. A 1.2.3.2 @@ -12678,7 +13541,9 @@ HOST-3.EXAMPLE. MX 0 . HOST-127.EXAMPLE. A 1.2.3.127 HOST-127.EXAMPLE. MX 0 .-
+
The $GENERATE directive is a BIND extension and not part of the standard zone file format.
-+ +
In addition to the standard textual format, BIND 9 supports the ability to read or dump to zone files in other formats.
-+
The raw format is
a binary representation of zone data in a manner similar
to that used in zone transfers. Since it does not require
parsing text, load time is significantly reduced.
+
An even faster alternative is the map
format, which is an image of a BIND 9
in-memory zone database; it is capable of being loaded
@@ -12834,7 +13702,7 @@ HOST-127.EXAMPLE. MX 0 .
function; the zone can begin serving queries almost
immediately.
+
For a primary server, a zone file in
raw or map
format is expected to be generated from a textual zone
@@ -12845,7 +13713,7 @@ HOST-127.EXAMPLE. MX 0 .
named dumps the zone contents after
zone transfer or when applying prior updates.
+
If a zone file in a binary format needs manual modification, it first must be converted to a textual form by the named-compilezone command. All @@ -12853,7 +13721,7 @@ HOST-127.EXAMPLE. MX 0 . should then be converted to the binary form by the named-compilezone command again.
-+
Note that map format is extremely
architecture-specific. A map
file cannot be used on a system
@@ -12870,12 +13738,14 @@ HOST-127.EXAMPLE. MX 0 .
portable backup of such a file, conversion to
text format is recommended.
+ +
BIND 9 maintains lots of statistics information and provides several interfaces for users to get access to the statistics. @@ -12884,11 +13754,14 @@ HOST-127.EXAMPLE. MX 0 . are meaningful in BIND 9, and other information that is considered useful.
-+ +
The statistics information is categorized into the following sections.
-+
A subset of Name Server Statistics is collected and shown per zone for which the server has the authority when zone-statistics is set to @@ -13013,11 +13888,13 @@ HOST-127.EXAMPLE. MX 0 . Usage” for further details.
-+ +
These statistics counters are shown with their zone and view names. The view name is omitted when the server is not configured with explicit views.
-+ +
There are currently two user interfaces to get access to the statistics. One is in the plain text format dumped to the file specified @@ -13027,16 +13904,18 @@ HOST-127.EXAMPLE. MX 0 . is specified in the configuration file (see the section called “statistics-channels Statement Grammar”.)
-+ +
The text format statistics dump begins with a line, like:
-+
+++ Statistics Dump +++ (973798949)
-+
The number in parentheses is a standard Unix-style timestamp, measured as seconds since January 1, 1970. @@ -13045,28 +13924,33 @@ HOST-127.EXAMPLE. MX 0 . as described above. Each section begins with a line, like:
-+ +
++ Name Server Statistics ++
-+ +
Each section consists of lines, each containing the statistics counter value followed by its textual description. See below for available counters. For brevity, counters that have a value of 0 are not shown in the statistics file.
-+ +
The statistics dump ends with the line where the number is identical to the number in the beginning line; for example:
-+
--- Statistics Dump --- (973798949)
-+ +
The following tables summarize statistics counters that BIND 9 provides. For each row of the tables, the leftmost column is the @@ -13082,7 +13966,8 @@ HOST-127.EXAMPLE. MX 0 . it gives the corresponding counter name of the BIND 8 statistics, if applicable.
-+ +
Note: BIND statistics counters are signed 64-bit values on all platforms except one: 32-bit Windows, where they are signed 32-bit values. Given that 32-bit values have a @@ -13090,10 +13975,13 @@ HOST-127.EXAMPLE. MX 0 . counters in 32-bit Windows builds overflow significantly more quickly than on all other platforms.
-+ +
Socket I/O statistics counters are defined per socket types, which are UDP4 (UDP/IPv4), @@ -14268,7 +15168,9 @@ HOST-127.EXAMPLE. MX 0 . Not all counters are available for all socket types; exceptions are noted in the description field.
-+ +
Most statistics counters that were available in BIND 8 are also supported in BIND 9 as shown in the above tables. Here are notes about other counters that do not appear in these tables.
-+
These counters are not supported because BIND 9 does not adopt the notion of forwarding as BIND 8 did. -
+
This counter is accessible in the Incoming Queries section. -
+
This counter is accessible in the Incoming Requests section. -
+
This counter is not supported because BIND 9 does not care about IP options in the first place. -