From: Evan Hunt Date: Thu, 30 Jan 2014 22:51:34 +0000 (-0800) Subject: [master] improve EDNS doc X-Git-Tag: v9.10.0a2~22 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=47c847e286ac1d9dcc1b6dec5430ad9d2abad7b2;p=thirdparty%2Fbind9.git [master] improve EDNS doc 3721. [doc] Improved doucmentation of the EDNS processing enhancements introduced in change #3593. [RT #35275] --- diff --git a/CHANGES b/CHANGES index fe433dc2e0c..6c243a811a3 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +3721. [doc] Improved doucmentation of the EDNS processing + enhancements introduced in change #3593. [RT #35275] + 3720. [bug] Address compiler warnings. [RT #35261] 3719. [bug] Address memory leak in in peer.c. [RT #35255] diff --git a/EDNS-9.10 b/EDNS-9.10 deleted file mode 100644 index d54cb1f8c4d..00000000000 --- a/EDNS-9.10 +++ /dev/null @@ -1,33 +0,0 @@ -Copyright (C) 2013 Internet Systems Consortium, Inc. ("ISC") -See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. - - EDNS in BIND 9.10 - -The EDNS code in BIND 9.10 records successful plain and EDNS query -counts as well at timeouts for plain DNS and EDNS queries at various -EDNS buffer sizes: 4096, 1432, 1232 and 512 for each server named -talks to. A EDNS timeout for a lower buffer size is also counted -against higher buffer sizes. These are held in 8 bit counters and -are shifted on overflow of any counter. This will result in false -positives due to transitory network problems to be removed from the -history. - -The buffer sizes of 1432 and 1232 are choosen to allow for a IPv4/IPv6 -encapsulated UDP message to be sent without fragmentation at Ethernet -and IPv6 network mimimum MTU sizes. - -Named also records the largest successful EDNS response size seen. - -When talking to a new server named will send a EDNS query advertising -a 512 byte UDP buffer. This is the most conservative EDNS message -that can be sent. If this results in a response with TC=1 being -sent a larger EDNS buffer size will be used rather than a immediate -fallback to TCP. - -If there are too many timeouts to EDNS queries without a successful EDNS -query and with successful plain DNS queries named will fallback to using -plain DNS when taking to a server. Named will periodically send a EDNS -query to see if the server now supports EDNS. - -When talking to a server using EDNS named will choose a EDNS buffer size -based on the history of EDNS timeouts at various advertised sizes. diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index b30901aefac..0353ddf3aca 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -1,5 +1,5 @@ ]> - - The resolver libraries provided by most operating systems are - stub resolvers, meaning that they are not - capable of - performing the full DNS resolution process by themselves by talking - directly to the authoritative servers. Instead, they rely on a - local - name server to perform the resolution on their behalf. Such a - server - 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. - - - - Forwarding - - - Even a caching name server does not necessarily perform - the complete recursive lookup itself. Instead, it can - forward some or all of the queries - that it cannot satisfy from its cache to another caching name - 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 - is found. Forwarders are typically used when you do not - wish all the servers at a given site to interact directly with the - rest of - the Internet servers. A typical scenario would involve a number - of internal DNS servers and an - Internet firewall. Servers unable - to pass packets through the firewall would forward to the server - that can do it, and that server would query the Internet DNS servers - on the internal server's behalf. - - + + The resolver libraries provided by most operating systems are + stub resolvers, meaning that they are not + capable of + performing the full DNS resolution process by themselves by talking + directly to the authoritative servers. Instead, they rely on a + local + name server to perform the resolution on their behalf. Such a + server + 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. + + + + Forwarding + + + Even a caching name server does not necessarily perform + the complete recursive lookup itself. Instead, it can + forward some or all of the queries + that it cannot satisfy from its cache to another caching name + 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 + is found. Forwarders are typically used when you do not + wish all the servers at a given site to interact directly with the + rest of + the Internet servers. A typical scenario would involve a number + of internal DNS servers and an + Internet firewall. Servers unable + to pass packets through the firewall would forward to the server + that can do it, and that server would query the Internet DNS servers + on the internal server's behalf. + + - Name Servers in Multiple Roles - - - 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. - - A server that only provides authoritative name service - (an authoritative-only server) can run with - recursion disabled, improving reliability and security. - - A server that is not authoritative for any zones and only provides - recursive service to local - clients (a caching-only server) - does not need to be reachable from the Internet at large and can - be placed inside a firewall. - + Name Servers in Multiple Roles + + + 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. + + A server that only provides authoritative name service + (an authoritative-only server) can run with + recursion disabled, improving reliability and security. + + A server that is not authoritative for any zones and only provides + recursive service to local + clients (a caching-only server) + does not need to be reachable from the Internet at large and can + be placed inside a firewall. + @@ -573,87 +573,87 @@ Hardware requirements - DNS hardware requirements have - traditionally been quite modest. - For many installations, servers that have been pensioned off from - active duty have performed admirably as DNS servers. + DNS hardware requirements have + traditionally been quite modest. + For many installations, servers that have been pensioned off from + active duty have performed admirably as DNS servers. - The DNSSEC features of BIND 9 - may prove to be quite - CPU intensive however, so organizations that make heavy use of these - features may wish to consider larger systems for these applications. - BIND 9 is fully multithreaded, allowing - full utilization of - multiprocessor systems for installations that need it. + The DNSSEC features of BIND 9 + may prove to be quite + CPU intensive however, so organizations that make heavy use of these + features may wish to consider larger systems for these applications. + BIND 9 is fully multithreaded, allowing + full utilization of + multiprocessor systems for installations that need it. CPU Requirements - CPU requirements for BIND 9 range from - i486-class machines - for serving of static zones without caching, to enterprise-class - machines if you intend to process many dynamic updates and DNSSEC - signed zones, serving many thousands of queries per second. + CPU requirements for BIND 9 range from + i486-class machines + for serving of static zones without caching, to enterprise-class + machines if you intend to process many dynamic updates and DNSSEC + signed zones, serving many thousands of queries per second. Memory Requirements - The memory of the server has to be large enough to fit the - cache and zones loaded off disk. The max-cache-size - option can be used to limit the amount of memory used by the cache, - at the expense of reducing cache hit rates and causing more DNS - traffic. - Additionally, if additional section caching - () is enabled, - the max-acache-size option can be used to - limit the amount - of memory used by the mechanism. - It is still good practice to have enough memory to load - all zone and cache data into memory — unfortunately, the best - way - to determine this for a given installation is to watch the name server - in operation. After a few weeks the server process should reach - a relatively stable size where entries are expiring from the cache as - fast as they are being inserted. + The memory of the server has to be large enough to fit the + cache and zones loaded off disk. The max-cache-size + option can be used to limit the amount of memory used by the cache, + at the expense of reducing cache hit rates and causing more DNS + traffic. + Additionally, if additional section caching + () is enabled, + the max-acache-size option can be used to + limit the amount + of memory used by the mechanism. + It is still good practice to have enough memory to load + all zone and cache data into memory — unfortunately, the best + way + to determine this for a given installation is to watch the name server + in operation. After a few weeks the server process should reach + a relatively stable size where entries are expiring from the cache as + fast as they are being inserted. + --> Name Server Intensive Environment Issues - For name server intensive environments, there are two alternative - configurations that may be used. The first is where clients and - any second-level internal name servers query a main name server, which - has enough memory to build a large cache. This approach minimizes - the bandwidth used by external name lookups. The second alternative - is to set up second-level internal name servers to make queries - independently. - In this configuration, none of the individual machines needs to - have as much memory or CPU power as in the first alternative, but - this has the disadvantage of making many more external queries, - as none of the name servers share their cached data. + For name server intensive environments, there are two alternative + configurations that may be used. The first is where clients and + any second-level internal name servers query a main name server, which + has enough memory to build a large cache. This approach minimizes + the bandwidth used by external name lookups. The second alternative + is to set up second-level internal name servers to make queries + independently. + In this configuration, none of the individual machines needs to + have as much memory or CPU power as in the first alternative, but + this has the disadvantage of making many more external queries, + as none of the name servers share their cached data. Supported Operating Systems - ISC BIND 9 compiles and runs on a large - number - of Unix-like operating systems and on - Microsoft Windows Server 2003 and 2008, and Windows XP and Vista. - For an up-to-date - list of supported systems, see the README file in the top level - directory - of the BIND 9 source distribution. + ISC BIND 9 compiles and runs on a large + number + of Unix-like operating systems and on + Microsoft Windows Server 2003 and 2008, and Windows XP and Vista. + For an up-to-date + list of supported systems, see the README file in the top level + directory + of the BIND 9 source distribution. @@ -669,16 +669,16 @@ Sample Configurations - A Caching-only Name Server - - The following sample configuration is appropriate for a caching-only - name server for use by clients internal to a corporation. All - queries - from outside clients are refused using the allow-query - option. Alternatively, the same effect could be achieved using - suitable - firewall rules. - + A Caching-only Name Server + + The following sample configuration is appropriate for a caching-only + name server for use by clients internal to a corporation. All + queries + from outside clients are refused using the allow-query + option. Alternatively, the same effect could be achieved using + suitable + firewall rules. + // Two corporate subnets we wish to allow queries from. @@ -701,12 +701,12 @@ zone "0.0.127.in-addr.arpa" { - An Authoritative-only Name Server - - This sample configuration is for an authoritative-only server - that is the master server for "example.com" - and a slave for the subdomain "eng.example.com". - + An Authoritative-only Name Server + + This sample configuration is for an authoritative-only server + that is the master server for "example.com" + and a slave for the subdomain "eng.example.com". + options { @@ -734,8 +734,8 @@ zone "example.com" { // IP addresses of slave servers allowed to // transfer example.com allow-transfer { - 192.168.4.14; - 192.168.5.53; + 192.168.4.14; + 192.168.5.53; }; }; // We are a slave server for eng.example.com @@ -753,150 +753,150 @@ zone "eng.example.com" { Load Balancing + --> - A primitive form of load balancing can be achieved in - the DNS by using multiple records + A primitive form of load balancing can be achieved in + the DNS by using multiple records (such as multiple A records) for one name. - For example, if you have three WWW servers with network addresses - of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the - following means that clients will connect to each machine one third - of the time: + For example, if you have three WWW servers with network addresses + of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the + following means that clients will connect to each machine one third + of the time: - - - - - - - - - - - Name - - - - - TTL - - - - - CLASS - - - - - TYPE - - - - - Resource Record (RR) Data - - - - - - - www - - - - - 600 - - - - - IN - - - - - A - - - - - 10.0.0.1 - - - - - - - - - - 600 - - - - - IN - - - - - A - - - - - 10.0.0.2 - - - - - - - - - - 600 - - - - - IN - - - - - A - - - - - 10.0.0.3 - - - - - + + + + + + + + + + + Name + + + + + TTL + + + + + CLASS + + + + + TYPE + + + + + Resource Record (RR) Data + + + + + + + www + + + + + 600 + + + + + IN + + + + + A + + + + + 10.0.0.1 + + + + + + + + + + 600 + + + + + IN + + + + + A + + + + + 10.0.0.2 + + + + + + + + + + 600 + + + + + IN + + + + + A + + + + + 10.0.0.3 + + + + + - When a resolver queries for these records, BIND will rotate - them and respond to the query with the records in a different - order. In the example above, clients will randomly receive - records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients - will use the first record returned and discard the rest. + When a resolver queries for these records, BIND will rotate + them and respond to the query with the records in a different + order. In the example above, clients will randomly receive + records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients + will use the first record returned and discard the rest. - For more detail on ordering responses, check the - rrset-order sub-statement in the - options statement, see - . + For more detail on ordering responses, check the + rrset-order sub-statement in the + options statement, see + . @@ -905,339 +905,339 @@ zone "eng.example.com" { Name Server Operations - Tools for Use With the Name Server Daemon - - This section describes several indispensable diagnostic, - administrative and monitoring tools available to the system - administrator for controlling and debugging the name server - daemon. - - - Diagnostic Tools - - The dig, host, and - nslookup programs are all command - line tools - for manually querying name servers. They differ in style and - output format. - - - - - dig - - - The domain information groper (dig) - is the most versatile and complete of these lookup tools. - It has two modes: simple interactive - mode for a single query, and batch mode which executes a - query for - each in a list of several query lines. All query options are - accessible - from the command line. - - - dig - @server - domain - query-type - query-class - +query-option - -dig-option - %comment - - - The usual simple use of dig will take the form - - - dig @server domain query-type query-class - - - For more information and a list of available commands and - options, see the dig man - page. - - - - - - host - - - The host utility emphasizes - simplicity - and ease of use. By default, it converts - between host names and Internet addresses, but its - functionality - can be extended with the use of options. - - - host - -aCdlnrsTwv - -c class - -N ndots - -t type - -W timeout - -R retries - -m flag + Tools for Use With the Name Server Daemon + + This section describes several indispensable diagnostic, + administrative and monitoring tools available to the system + administrator for controlling and debugging the name server + daemon. + + + Diagnostic Tools + + The dig, host, and + nslookup programs are all command + line tools + for manually querying name servers. They differ in style and + output format. + + + + + dig + + + The domain information groper (dig) + is the most versatile and complete of these lookup tools. + It has two modes: simple interactive + mode for a single query, and batch mode which executes a + query for + each in a list of several query lines. All query options are + accessible + from the command line. + + + dig + @server + domain + query-type + query-class + +query-option + -dig-option + %comment + + + The usual simple use of dig will take the form + + + dig @server domain query-type query-class + + + For more information and a list of available commands and + options, see the dig man + page. + + + + + + host + + + The host utility emphasizes + simplicity + and ease of use. By default, it converts + between host names and Internet addresses, but its + functionality + can be extended with the use of options. + + + host + -aCdlnrsTwv + -c class + -N ndots + -t type + -W timeout + -R retries + -m flag -4 -6 - hostname - server - - - For more information and a list of available commands and - options, see the host man - page. - - - - - - nslookup - - nslookup - has two modes: interactive and - non-interactive. Interactive mode allows the user to - query name servers for information about various - hosts and domains or to print a list of hosts in a - domain. Non-interactive mode is used to print just - the name and requested information for a host or - domain. - - - nslookup - -option - - host-to-find - - server - - - - Interactive mode is entered when no arguments are given (the - default name server will be used) or when the first argument - is a - hyphen (`-') and the second argument is the host name or - Internet address - of a name server. - - - Non-interactive mode is used when the name or Internet - address - of the host to be looked up is given as the first argument. - The - optional second argument specifies the host name or address - of a name server. - - - Due to its arcane user interface and frequently inconsistent - behavior, we do not recommend the use of nslookup. - Use dig instead. - - - - - - - - - Administrative Tools - - Administrative tools play an integral part in the management - of a server. - - - - - named-checkconf - - - The named-checkconf program - checks the syntax of a named.conf file. - - - named-checkconf - -jvz - -t directory - filename - - - - - - named-checkzone - - - The named-checkzone program - checks a master file for - syntax and consistency. - - - named-checkzone - -djqvD - -c class - -o output - -t directory - -w directory - -k (ignore|warn|fail) - -n (ignore|warn|fail) - -W (ignore|warn) - zone - filename - - - - - named-compilezone + hostname + server + + + For more information and a list of available commands and + options, see the host man + page. + + + + + + nslookup + nslookup + has two modes: interactive and + non-interactive. Interactive mode allows the user to + query name servers for information about various + hosts and domains or to print a list of hosts in a + domain. Non-interactive mode is used to print just + the name and requested information for a host or + domain. + + + nslookup + -option + + host-to-find + - server + + - Similar to named-checkzone, but - it always dumps the zone content to a specified file - (typically in a different format). + Interactive mode is entered when no arguments are given (the + default name server will be used) or when the first argument + is a + hyphen (`-') and the second argument is the host name or + Internet address + of a name server. + + + Non-interactive mode is used when the name or Internet + address + of the host to be looked up is given as the first argument. + The + optional second argument specifies the host name or address + of a name server. + + + Due to its arcane user interface and frequently inconsistent + behavior, we do not recommend the use of nslookup. + Use dig instead. + - - - rndc - - - The remote name daemon control - (rndc) program allows the - system - administrator to control the operation of a name server. - Since BIND 9.2, rndc - supports all the commands of the BIND 8 ndc - utility except ndc start and - ndc restart, which were also - not supported in ndc's - channel mode. - If you run rndc without any - options - it will display a usage message as follows: - - - rndc - -c config - -s server - -p port - -y key - command - command - - - See for details of - the available rndc commands. - - - - rndc requires a configuration file, - since all - communication with the server is authenticated with - digital signatures that rely on a shared secret, and - there is no way to provide that secret other than with a - configuration file. The default location for the - rndc configuration file is - /etc/rndc.conf, but an - alternate - location can be specified with the - option. If the configuration file is not found, - rndc will also look in - /etc/rndc.key (or whatever - sysconfdir was defined when - the BIND build was - configured). - The rndc.key file is - generated by - running rndc-confgen -a as - described in - . - - - - The format of the configuration file is similar to - that of named.conf, but - limited to - only four statements, the options, - key, server and - include - statements. These statements are what associate the - secret keys to the servers with which they are meant to - be shared. The order of statements is not - significant. - - - - The options statement has - three clauses: - default-server, default-key, - and default-port. - default-server takes a - host name or address argument and represents the server - that will - be contacted if no - option is provided on the command line. - default-key takes - the name of a key as its argument, as defined by a key statement. - default-port specifies the - port to which - rndc should connect if no - port is given on the command line or in a - server statement. - - - - The key statement defines a - key to be used - by rndc when authenticating - with - named. Its syntax is - identical to the - key statement in named.conf. - The keyword key is - followed by a key name, which must be a valid - domain name, though it need not actually be hierarchical; - thus, - a string like "rndc_key" is a valid - name. - The key statement has two - clauses: - algorithm and secret. - While the configuration parser will accept any string as the - argument - to algorithm, currently only the strings - "hmac-md5", - "hmac-sha1", - "hmac-sha224", - "hmac-sha256", - "hmac-sha384" - and "hmac-sha512" - have any meaning. The secret is a base-64 encoded string - as specified in RFC 3548. - - - - The server statement - associates a key - defined using the key - statement with a server. - The keyword server is followed by a - host name or address. The server statement - has two clauses: key and port. - The key clause specifies the - name of the key - to be used when communicating with this server, and the - port clause can be used to - specify the port rndc should - connect - to on the server. - - - - A sample minimal configuration file is as follows: - + + - + + Administrative Tools + + Administrative tools play an integral part in the management + of a server. + + + + + named-checkconf + + + The named-checkconf program + checks the syntax of a named.conf file. + + + named-checkconf + -jvz + -t directory + filename + + + + + + named-checkzone + + + The named-checkzone program + checks a master file for + syntax and consistency. + + + named-checkzone + -djqvD + -c class + -o output + -t directory + -w directory + -k (ignore|warn|fail) + -n (ignore|warn|fail) + -W (ignore|warn) + zone + filename + + + + + named-compilezone + + + Similar to named-checkzone, but + it always dumps the zone content to a specified file + (typically in a different format). + + + + + + rndc + + + The remote name daemon control + (rndc) program allows the + system + administrator to control the operation of a name server. + Since BIND 9.2, rndc + supports all the commands of the BIND 8 ndc + utility except ndc start and + ndc restart, which were also + not supported in ndc's + channel mode. + If you run rndc without any + options + it will display a usage message as follows: + + + rndc + -c config + -s server + -p port + -y key + command + command + + + See for details of + the available rndc commands. + + + + rndc requires a configuration file, + since all + communication with the server is authenticated with + digital signatures that rely on a shared secret, and + there is no way to provide that secret other than with a + configuration file. The default location for the + rndc configuration file is + /etc/rndc.conf, but an + alternate + location can be specified with the + option. If the configuration file is not found, + rndc will also look in + /etc/rndc.key (or whatever + sysconfdir was defined when + the BIND build was + configured). + The rndc.key file is + generated by + running rndc-confgen -a as + described in + . + + + + The format of the configuration file is similar to + that of named.conf, but + limited to + only four statements, the options, + key, server and + include + statements. These statements are what associate the + secret keys to the servers with which they are meant to + be shared. The order of statements is not + significant. + + + + The options statement has + three clauses: + default-server, default-key, + and default-port. + default-server takes a + host name or address argument and represents the server + that will + be contacted if no + option is provided on the command line. + default-key takes + the name of a key as its argument, as defined by a key statement. + default-port specifies the + port to which + rndc should connect if no + port is given on the command line or in a + server statement. + + + + The key statement defines a + key to be used + by rndc when authenticating + with + named. Its syntax is + identical to the + key statement in named.conf. + The keyword key is + followed by a key name, which must be a valid + domain name, though it need not actually be hierarchical; + thus, + a string like "rndc_key" is a valid + name. + The key statement has two + clauses: + algorithm and secret. + While the configuration parser will accept any string as the + argument + to algorithm, currently only the strings + "hmac-md5", + "hmac-sha1", + "hmac-sha224", + "hmac-sha256", + "hmac-sha384" + and "hmac-sha512" + have any meaning. The secret is a base-64 encoded string + as specified in RFC 3548. + + + + The server statement + associates a key + defined using the key + statement with a server. + The keyword server is followed by a + host name or address. The server statement + has two clauses: key and port. + The key clause specifies the + name of the key + to be used when communicating with this server, and the + port clause can be used to + specify the port rndc should + connect + to on the server. + + + + A sample minimal configuration file is as follows: + + + key rndc_key { algorithm "hmac-sha256"; secret @@ -1249,103 +1249,103 @@ options { }; - - This file, if installed as /etc/rndc.conf, - would allow the command: - + + This file, if installed as /etc/rndc.conf, + would allow the command: + - - $ rndc reload - + + $ rndc reload + - - to connect to 127.0.0.1 port 953 and cause the name server - to reload, if a name server on the local machine were - running with - following controls statements: - + + to connect to 127.0.0.1 port 953 and cause the name server + to reload, if a name server on the local machine were + running with + following controls statements: + controls { - inet 127.0.0.1 - allow { localhost; } keys { rndc_key; }; + inet 127.0.0.1 + allow { localhost; } keys { rndc_key; }; }; - - and it had an identical key statement for - rndc_key. - - - - Running the rndc-confgen - program will - conveniently create a rndc.conf - file for you, and also display the - corresponding controls - statement that you need to - add to named.conf. - Alternatively, - you can run rndc-confgen -a - to set up - a rndc.key file and not - modify - named.conf at all. - - - - - - - + + and it had an identical key statement for + rndc_key. + + + + Running the rndc-confgen + program will + conveniently create a rndc.conf + file for you, and also display the + corresponding controls + statement that you need to + add to named.conf. + Alternatively, + you can run rndc-confgen -a + to set up + a rndc.key file and not + modify + named.conf at all. + + + + + + + - Signals - - Certain UNIX signals cause the name server to take specific - actions, as described in the following table. These signals can - be sent using the kill command. - - - - - - - - - SIGHUP - - - - Causes the server to read named.conf and - reload the database. - - - - - - SIGTERM - - - - Causes the server to clean up and exit. - - - - - - SIGINT - - - - Causes the server to clean up and exit. - - - - - - + Signals + + Certain UNIX signals cause the name server to take specific + actions, as described in the following table. These signals can + be sent using the kill command. + + + + + + + + + SIGHUP + + + + Causes the server to read named.conf and + reload the database. + + + + + + SIGTERM + + + + Causes the server to clean up and exit. + + + + + + SIGINT + + + + Causes the server to clean up and exit. + + + + + + @@ -1357,25 +1357,25 @@ controls { Notify - DNS NOTIFY is a mechanism that allows master - servers to notify their slave servers of changes to a zone's data. In - response to a NOTIFY from a master server, the - slave will check to see that its version of the zone is the - current version and, if not, initiate a zone transfer. + DNS NOTIFY is a mechanism that allows master + servers to notify their slave servers of changes to a zone's data. In + response to a NOTIFY from a master server, the + slave will check to see that its version of the zone is the + current version and, if not, initiate a zone transfer. - For more information about DNS - NOTIFY, see the description of the - notify option in and - the description of the zone option also-notify in - . The NOTIFY - protocol is specified in RFC 1996. + For more information about DNS + NOTIFY, see the description of the + notify option in and + the description of the zone option also-notify in + . The NOTIFY + protocol is specified in RFC 1996. As a slave zone can also be a master to other slaves, named, - by default, sends NOTIFY messages for every zone + by default, sends NOTIFY messages for every zone it loads. Specifying notify master-only; will cause named to only send NOTIFY for master zones that it loads. @@ -1387,10 +1387,10 @@ controls { Dynamic Update - Dynamic Update is a method for adding, replacing or deleting - records in a master server by sending it a special form of DNS - messages. The format and meaning of these messages is specified - in RFC 2136. + Dynamic Update is a method for adding, replacing or deleting + records in a master server by sending it a special form of DNS + messages. The format and meaning of these messages is specified + in RFC 2136. @@ -1403,7 +1403,7 @@ controls { If the zone's update-policy is set to local, updates to the zone will be permitted for the key local-ddns, - which will be generated by named at startup. + which will be generated by named at startup. See for more details. @@ -1429,62 +1429,62 @@ controls { The journal file - - All changes made to a zone using dynamic update are stored - in the zone's journal file. This file is automatically created - by the server when the first dynamic update takes place. - The name of the journal file is formed by appending the extension - .jnl to the name of the - corresponding zone - file unless specifically overridden. The journal file is in a - binary format and should not be edited manually. - - - - The server will also occasionally write ("dump") - the complete contents of the updated zone to its zone file. - This is not done immediately after - each dynamic update, because that would be too slow when a large - zone is updated frequently. Instead, the dump is delayed by - up to 15 minutes, allowing additional updates to take place. - During the dump process, transient files will be created - with the extensions .jnw and - .jbk; under ordinary circumstances, these - will be removed when the dump is complete, and can be safely - ignored. - - - - When a server is restarted after a shutdown or crash, it will replay - the journal file to incorporate into the zone any updates that - took - place after the last zone dump. - - - - Changes that result from incoming incremental zone transfers are - also - journalled in a similar way. - - - - The zone files of dynamic zones cannot normally be edited by - hand because they are not guaranteed to contain the most recent - dynamic changes — those are only in the journal file. - The only way to ensure that the zone file of a dynamic zone - is up to date is to run rndc stop. - - - - If you have to make changes to a dynamic zone - manually, the following procedure will work: Disable dynamic updates - to the zone using - rndc freeze zone. - This will also remove the zone's .jnl file - and update the master file. Edit the zone file. Run - rndc thaw zone - to reload the changed zone and re-enable dynamic updates. - + + All changes made to a zone using dynamic update are stored + in the zone's journal file. This file is automatically created + by the server when the first dynamic update takes place. + The name of the journal file is formed by appending the extension + .jnl to the name of the + corresponding zone + file unless specifically overridden. The journal file is in a + binary format and should not be edited manually. + + + + The server will also occasionally write ("dump") + the complete contents of the updated zone to its zone file. + This is not done immediately after + each dynamic update, because that would be too slow when a large + zone is updated frequently. Instead, the dump is delayed by + up to 15 minutes, allowing additional updates to take place. + During the dump process, transient files will be created + with the extensions .jnw and + .jbk; under ordinary circumstances, these + will be removed when the dump is complete, and can be safely + ignored. + + + + When a server is restarted after a shutdown or crash, it will replay + the journal file to incorporate into the zone any updates that + took + place after the last zone dump. + + + + Changes that result from incoming incremental zone transfers are + also + journalled in a similar way. + + + + The zone files of dynamic zones cannot normally be edited by + hand because they are not guaranteed to contain the most recent + dynamic changes — those are only in the journal file. + The only way to ensure that the zone file of a dynamic zone + is up to date is to run rndc stop. + + + + If you have to make changes to a dynamic zone + manually, the following procedure will work: Disable dynamic updates + to the zone using + rndc freeze zone. + This will also remove the zone's .jnl file + and update the master file. Edit the zone file. Run + rndc thaw zone + to reload the changed zone and re-enable dynamic updates. + @@ -1494,194 +1494,194 @@ controls { Incremental Zone Transfers (IXFR) - The incremental zone transfer (IXFR) protocol is a way for - slave servers to transfer only changed data, instead of having to - transfer the entire zone. The IXFR protocol is specified in RFC - 1995. See . + The incremental zone transfer (IXFR) protocol is a way for + slave servers to transfer only changed data, instead of having to + transfer the entire zone. The IXFR protocol is specified in RFC + 1995. See . - When acting as a master, BIND 9 - supports IXFR for those zones - where the necessary change history information is available. These - include master zones maintained by dynamic update and slave zones - whose data was obtained by IXFR. For manually maintained master - zones, and for slave zones obtained by performing a full zone - transfer (AXFR), IXFR is supported only if the option - ixfr-from-differences is set - to yes. + When acting as a master, BIND 9 + supports IXFR for those zones + where the necessary change history information is available. These + include master zones maintained by dynamic update and slave zones + whose data was obtained by IXFR. For manually maintained master + zones, and for slave zones obtained by performing a full zone + transfer (AXFR), IXFR is supported only if the option + ixfr-from-differences is set + to yes. - When acting as a slave, BIND 9 will - attempt to use IXFR unless - it is explicitly disabled. For more information about disabling - IXFR, see the description of the request-ixfr clause - of the server statement. + When acting as a slave, BIND 9 will + attempt to use IXFR unless + it is explicitly disabled. For more information about disabling + IXFR, see the description of the request-ixfr clause + of the server statement. Split DNS - Setting up different views, or visibility, of the DNS space to - internal and external resolvers is usually referred to as a + Setting up different views, or visibility, of the DNS space to + internal and external resolvers is usually referred to as a Split DNS setup. There are several - reasons an organization would want to set up its DNS this way. + reasons an organization would want to set up its DNS this way. - One common reason for setting up a DNS system this way is - to hide "internal" DNS information from "external" clients on the - Internet. There is some debate as to whether or not this is actually - useful. - Internal DNS information leaks out in many ways (via email headers, - for example) and most savvy "attackers" can find the information - they need using other means. + One common reason for setting up a DNS system this way is + to hide "internal" DNS information from "external" clients on the + Internet. There is some debate as to whether or not this is actually + useful. + Internal DNS information leaks out in many ways (via email headers, + for example) and most savvy "attackers" can find the information + they need using other means. However, since listing addresses of internal servers that - external clients cannot possibly reach can result in - connection delays and other annoyances, an organization may - choose to use a Split DNS to present a consistent view of itself - to the outside world. + external clients cannot possibly reach can result in + connection delays and other annoyances, an organization may + choose to use a Split DNS to present a consistent view of itself + to the outside world. - Another common reason for setting up a Split DNS system is - to allow internal networks that are behind filters or in RFC 1918 - space (reserved IP space, as documented in RFC 1918) to resolve DNS - on the Internet. Split DNS can also be used to allow mail from outside - back in to the internal network. + Another common reason for setting up a Split DNS system is + to allow internal networks that are behind filters or in RFC 1918 + space (reserved IP space, as documented in RFC 1918) to resolve DNS + on the Internet. Split DNS can also be used to allow mail from outside + back in to the internal network. Example split DNS setup - Let's say a company named Example, Inc. - (example.com) - has several corporate sites that have an internal network with - reserved - Internet Protocol (IP) space and an external demilitarized zone (DMZ), - or "outside" section of a network, that is available to the public. + Let's say a company named Example, Inc. + (example.com) + has several corporate sites that have an internal network with + reserved + Internet Protocol (IP) space and an external demilitarized zone (DMZ), + or "outside" section of a network, that is available to the public. - Example, Inc. wants its internal clients - to be able to resolve external hostnames and to exchange mail with - people on the outside. The company also wants its internal resolvers - to have access to certain internal-only zones that are not available - at all outside of the internal network. + Example, Inc. wants its internal clients + to be able to resolve external hostnames and to exchange mail with + people on the outside. The company also wants its internal resolvers + to have access to certain internal-only zones that are not available + at all outside of the internal network. - In order to accomplish this, the company will set up two sets - of name servers. One set will be on the inside network (in the - reserved - IP space) and the other set will be on bastion hosts, which are - "proxy" - hosts that can talk to both sides of its network, in the DMZ. + In order to accomplish this, the company will set up two sets + of name servers. One set will be on the inside network (in the + reserved + IP space) and the other set will be on bastion hosts, which are + "proxy" + hosts that can talk to both sides of its network, in the DMZ. - The internal servers will be configured to forward all queries, - except queries for site1.internal, site2.internal, site1.example.com, - and site2.example.com, to the servers - in the - DMZ. These internal servers will have complete sets of information - for site1.example.com, site2.example.com, site1.internal, - and site2.internal. + The internal servers will be configured to forward all queries, + except queries for site1.internal, site2.internal, site1.example.com, + and site2.example.com, to the servers + in the + DMZ. These internal servers will have complete sets of information + for site1.example.com, site2.example.com, site1.internal, + and site2.internal. - To protect the site1.internal and site2.internal domains, - the internal name servers must be configured to disallow all queries - to these domains from any external hosts, including the bastion - hosts. + To protect the site1.internal and site2.internal domains, + the internal name servers must be configured to disallow all queries + to these domains from any external hosts, including the bastion + hosts. - The external servers, which are on the bastion hosts, will - be configured to serve the "public" version of the site1 and site2.example.com zones. - This could include things such as the host records for public servers - (www.example.com and ftp.example.com), - and mail exchange (MX) records (a.mx.example.com and b.mx.example.com). + The external servers, which are on the bastion hosts, will + be configured to serve the "public" version of the site1 and site2.example.com zones. + This could include things such as the host records for public servers + (www.example.com and ftp.example.com), + and mail exchange (MX) records (a.mx.example.com and b.mx.example.com). - In addition, the public site1 and site2.example.com zones - should have special MX records that contain wildcard (`*') records - pointing to the bastion hosts. This is needed because external mail - servers do not have any other way of looking up how to deliver mail - to those internal hosts. With the wildcard records, the mail will - be delivered to the bastion host, which can then forward it on to - internal hosts. + In addition, the public site1 and site2.example.com zones + should have special MX records that contain wildcard (`*') records + pointing to the bastion hosts. This is needed because external mail + servers do not have any other way of looking up how to deliver mail + to those internal hosts. With the wildcard records, the mail will + be delivered to the bastion host, which can then forward it on to + internal hosts. - Here's an example of a wildcard MX record: + Here's an example of a wildcard MX record: * IN MX 10 external1.example.com. - Now that they accept mail on behalf of anything in the internal - network, the bastion hosts will need to know how to deliver mail - to internal hosts. In order for this to work properly, the resolvers - on - the bastion hosts will need to be configured to point to the internal - name servers for DNS resolution. + Now that they accept mail on behalf of anything in the internal + network, the bastion hosts will need to know how to deliver mail + to internal hosts. In order for this to work properly, the resolvers + on + the bastion hosts will need to be configured to point to the internal + name servers for DNS resolution. - Queries for internal hostnames will be answered by the internal - servers, and queries for external hostnames will be forwarded back - out to the DNS servers on the bastion hosts. + Queries for internal hostnames will be answered by the internal + servers, and queries for external hostnames will be forwarded back + out to the DNS servers on the bastion hosts. - In order for all this to work properly, internal clients will - need to be configured to query only the internal - name servers for DNS queries. This could also be enforced via - selective - filtering on the network. + In order for all this to work properly, internal clients will + need to be configured to query only the internal + name servers for DNS queries. This could also be enforced via + selective + filtering on the network. - If everything has been set properly, Example, Inc.'s - internal clients will now be able to: + If everything has been set properly, Example, Inc.'s + internal clients will now be able to: - - - Look up any hostnames in the site1 - and - site2.example.com zones. - - - - - Look up any hostnames in the site1.internal and - site2.internal domains. - - - - Look up any hostnames on the Internet. - - - Exchange mail with both internal and external people. - + + + Look up any hostnames in the site1 + and + site2.example.com zones. + + + + + Look up any hostnames in the site1.internal and + site2.internal domains. + + + + Look up any hostnames on the Internet. + + + Exchange mail with both internal and external people. + - Hosts on the Internet will be able to: + Hosts on the Internet will be able to: - - - Look up any hostnames in the site1 - and - site2.example.com zones. - - - - - Exchange mail with anyone in the site1 and - site2.example.com zones. - - + + + Look up any hostnames in the site1 + and + site2.example.com zones. + + + + + Exchange mail with anyone in the site1 and + site2.example.com zones. + + - Here is an example configuration for the setup we just - described above. Note that this is only configuration information; - for information on how to configure your zone files, see . + Here is an example configuration for the setup we just + described above. Note that this is only configuration information; + for information on how to configure your zone files, see . - Internal DNS server config: + Internal DNS server config: @@ -1696,7 +1696,7 @@ options { forward only; // forward to external servers forwarders { - bastion-ips-go-here; + bastion-ips-go-here; }; // sample allow-transfer (no one) allow-transfer { none; }; @@ -1747,7 +1747,7 @@ zone "site2.internal" { - External (bastion host) DNS server config: + External (bastion host) DNS server config: @@ -1786,8 +1786,8 @@ zone "site2.example.com" { - In the resolv.conf (or equivalent) on - the bastion host(s): + In the resolv.conf (or equivalent) on + the bastion host(s): @@ -1802,89 +1802,89 @@ nameserver 172.16.72.4 TSIG - This is a short guide to setting up Transaction SIGnatures - (TSIG) based transaction security in BIND. It describes changes - to the configuration file as well as what changes are required for - different features, including the process of creating transaction - keys and using transaction signatures with BIND. + This is a short guide to setting up Transaction SIGnatures + (TSIG) based transaction security in BIND. It describes changes + to the configuration file as well as what changes are required for + different features, including the process of creating transaction + keys and using transaction signatures with BIND. - BIND primarily supports TSIG for server - to server communication. - This includes zone transfer, notify, and recursive query messages. - Resolvers based on newer versions of BIND 8 have limited support - for TSIG. + BIND primarily supports TSIG for server + to server communication. + This includes zone transfer, notify, and recursive query messages. + Resolvers based on newer versions of BIND 8 have limited support + for TSIG. - TSIG can also be useful for dynamic update. A primary - server for a dynamic zone should control access to the dynamic - update service, but IP-based access control is insufficient. - The cryptographic access control provided by TSIG - is far superior. The nsupdate - program supports TSIG via the and - command line options or inline by use + TSIG can also be useful for dynamic update. A primary + server for a dynamic zone should control access to the dynamic + update service, but IP-based access control is insufficient. + The cryptographic access control provided by TSIG + is far superior. The nsupdate + program supports TSIG via the and + command line options or inline by use of the key. - Generate Shared Keys for Each Pair of Hosts - - A shared secret is generated to be shared between host1 and host2. - An arbitrary key name is chosen: "host1-host2.". The key name must - be the same on both hosts. - - - Automatic Generation - - The following command will generate a 128-bit (16 byte) HMAC-SHA256 - key as described above. Longer keys are better, but shorter keys - are easier to read. Note that the maximum key length is the digest - length, here 256 bits. - - - dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2. - - - The key is in the file Khost1-host2.+163+00000.private. - Nothing directly uses this file, but the base-64 encoded string - following "Key:" - can be extracted from the file and used as a shared secret: - - Key: La/E5CjG9O+os1jq0a2jdA== - - The string "La/E5CjG9O+os1jq0a2jdA==" can - be used as the shared secret. - - - - Manual Generation - - The shared secret is simply a random sequence of bits, encoded - in base-64. Most ASCII strings are valid base-64 strings (assuming - the length is a multiple of 4 and only valid characters are used), - so the shared secret can be manually generated. - - - Also, a known string can be run through mmencode or - a similar program to generate base-64 encoded data. - - + Generate Shared Keys for Each Pair of Hosts + + A shared secret is generated to be shared between host1 and host2. + An arbitrary key name is chosen: "host1-host2.". The key name must + be the same on both hosts. + + + Automatic Generation + + The following command will generate a 128-bit (16 byte) HMAC-SHA256 + key as described above. Longer keys are better, but shorter keys + are easier to read. Note that the maximum key length is the digest + length, here 256 bits. + + + dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2. + + + The key is in the file Khost1-host2.+163+00000.private. + Nothing directly uses this file, but the base-64 encoded string + following "Key:" + can be extracted from the file and used as a shared secret: + + Key: La/E5CjG9O+os1jq0a2jdA== + + The string "La/E5CjG9O+os1jq0a2jdA==" can + be used as the shared secret. + + + + Manual Generation + + The shared secret is simply a random sequence of bits, encoded + in base-64. Most ASCII strings are valid base-64 strings (assuming + the length is a multiple of 4 and only valid characters are used), + so the shared secret can be manually generated. + + + Also, a known string can be run through mmencode or + a similar program to generate base-64 encoded data. + + - Copying the Shared Secret to Both Machines - - This is beyond the scope of DNS. A secure transport mechanism - should be used. This could be secure FTP, ssh, telephone, etc. - + Copying the Shared Secret to Both Machines + + This is beyond the scope of DNS. A secure transport mechanism + should be used. This could be secure FTP, ssh, telephone, etc. + - Informing the Servers of the Key's Existence - - Imagine host1 and host 2 - are - both servers. The following is added to each server's named.conf file: - + Informing the Servers of the Key's Existence + + Imagine host1 and host 2 + are + both servers. The following is added to each server's named.conf file: + key host1-host2. { @@ -1893,28 +1893,28 @@ key host1-host2. { }; - - The secret is the one generated above. Since this is a secret, it - is recommended that either named.conf be - non-world readable, or the key directive be added to a non-world - readable file that is included by named.conf. - - - At this point, the key is recognized. This means that if the - server receives a message signed by this key, it can verify the - signature. If the signature is successfully verified, the - response is signed by the same key. - + + The secret is the one generated above. Since this is a secret, it + is recommended that either named.conf be + non-world readable, or the key directive be added to a non-world + readable file that is included by named.conf. + + + At this point, the key is recognized. This means that if the + server receives a message signed by this key, it can verify the + signature. If the signature is successfully verified, the + response is signed by the same key. + - Instructing the Server to Use the Key - - Since keys are shared between two hosts only, the server must - be told when keys are to be used. The following is added to the named.conf file - for host1, if the IP address of host2 is - 10.1.2.3: - + Instructing the Server to Use the Key + + Since keys are shared between two hosts only, the server must + be told when keys are to be used. The following is added to the named.conf file + for host1, if the IP address of host2 is + 10.1.2.3: + server 10.1.2.3 { @@ -1922,38 +1922,38 @@ server 10.1.2.3 { }; - - Multiple keys may be present, but only the first is used. - This directive does not contain any secrets, so it may be in a - world-readable - file. - - - If host1 sends a message that is a request - to that address, the message will be signed with the specified key. host1 will - expect any responses to signed messages to be signed with the same - key. - - - A similar statement must be present in host2's - configuration file (with host1's address) for host2 to - sign request messages to host1. - + + Multiple keys may be present, but only the first is used. + This directive does not contain any secrets, so it may be in a + world-readable + file. + + + If host1 sends a message that is a request + to that address, the message will be signed with the specified key. host1 will + expect any responses to signed messages to be signed with the same + key. + + + A similar statement must be present in host2's + configuration file (with host1's address) for host2 to + sign request messages to host1. + - TSIG Key Based Access Control - - BIND allows IP addresses and ranges - to be specified in ACL - definitions and - allow-{ query | transfer | update } - directives. - This has been extended to allow TSIG keys also. The above key would - be denoted key host1-host2. - - - An example of an allow-update directive would be: - + TSIG Key Based Access Control + + BIND allows IP addresses and ranges + to be specified in ACL + definitions and + allow-{ query | transfer | update } + directives. + This has been extended to allow TSIG keys also. The above key would + be denoted key host1-host2. + + + An example of an allow-update directive would be: + allow-update { key host1-host2. ;}; @@ -1966,35 +1966,35 @@ allow-update { key host1-host2. ;}; See for a discussion of - the more flexible update-policy statement. + the more flexible update-policy statement. - Errors - - - The processing of TSIG signed messages can result in - several errors. If a signed message is sent to a non-TSIG aware - server, a FORMERR (format error) will be returned, since the server will not - understand the record. This is a result of misconfiguration, - since the server must be explicitly configured to send a TSIG - signed message to a specific server. - - - - If a TSIG aware server receives a message signed by an - unknown key, the response will be unsigned with the TSIG - extended error code set to BADKEY. If a TSIG aware server - receives a message with a signature that does not validate, the - response will be unsigned with the TSIG extended error code set - to BADSIG. If a TSIG aware server receives a message with a time - outside of the allowed range, the response will be signed with - the TSIG extended error code set to BADTIME, and the time values - will be adjusted so that the response can be successfully - verified. In any of these cases, the message's rcode (response code) is set to - NOTAUTH (not authenticated). - + Errors + + + The processing of TSIG signed messages can result in + several errors. If a signed message is sent to a non-TSIG aware + server, a FORMERR (format error) will be returned, since the server will not + understand the record. This is a result of misconfiguration, + since the server must be explicitly configured to send a TSIG + signed message to a specific server. + + + + If a TSIG aware server receives a message signed by an + unknown key, the response will be unsigned with the TSIG + extended error code set to BADKEY. If a TSIG aware server + receives a message with a signature that does not validate, the + response will be unsigned with the TSIG extended error code set + to BADSIG. If a TSIG aware server receives a message with a time + outside of the allowed range, the response will be signed with + the TSIG extended error code set to BADTIME, and the time values + will be adjusted so that the response can be successfully + verified. In any of these cases, the message's rcode (response code) is set to + NOTAUTH (not authenticated). + @@ -2002,37 +2002,37 @@ allow-update { key host1-host2. ;}; TKEY TKEY - is a mechanism for automatically generating a shared secret - between two hosts. There are several "modes" of - TKEY that specify how the key is generated - or assigned. BIND 9 implements only one of - these modes, the Diffie-Hellman key exchange. Both hosts are - required to have a Diffie-Hellman KEY record (although this - record is not required to be present in a zone). The - TKEY process must use signed messages, - signed either by TSIG or SIG(0). The result of - TKEY is a shared secret that can be used to - sign messages with TSIG. TKEY can also be - used to delete shared secrets that it had previously - generated. + is a mechanism for automatically generating a shared secret + between two hosts. There are several "modes" of + TKEY that specify how the key is generated + or assigned. BIND 9 implements only one of + these modes, the Diffie-Hellman key exchange. Both hosts are + required to have a Diffie-Hellman KEY record (although this + record is not required to be present in a zone). The + TKEY process must use signed messages, + signed either by TSIG or SIG(0). The result of + TKEY is a shared secret that can be used to + sign messages with TSIG. TKEY can also be + used to delete shared secrets that it had previously + generated. - The TKEY process is initiated by a - client - or server by sending a signed TKEY - query - (including any appropriate KEYs) to a TKEY-aware server. The - server response, if it indicates success, will contain a - TKEY record and any appropriate keys. - After - this exchange, both participants have enough information to - determine the shared secret; the exact process depends on the - TKEY mode. When using the - Diffie-Hellman - TKEY mode, Diffie-Hellman keys are - exchanged, - and the shared secret is derived by both participants. + The TKEY process is initiated by a + client + or server by sending a signed TKEY + query + (including any appropriate KEYs) to a TKEY-aware server. The + server response, if it indicates success, will contain a + TKEY record and any appropriate keys. + After + this exchange, both participants have enough information to + determine the shared secret; the exact process depends on the + TKEY mode. When using the + Diffie-Hellman + TKEY mode, Diffie-Hellman keys are + exchanged, + and the shared secret is derived by both participants. @@ -2040,28 +2040,28 @@ allow-update { key host1-host2. ;}; SIG(0) - BIND 9 partially supports DNSSEC SIG(0) - transaction signatures as specified in RFC 2535 and RFC 2931. - SIG(0) - uses public/private keys to authenticate messages. Access control - is performed in the same manner as TSIG keys; privileges can be - granted or denied based on the key name. + BIND 9 partially supports DNSSEC SIG(0) + transaction signatures as specified in RFC 2535 and RFC 2931. + SIG(0) + uses public/private keys to authenticate messages. Access control + is performed in the same manner as TSIG keys; privileges can be + granted or denied based on the key name. - When a SIG(0) signed message is received, it will only be - verified if the key is known and trusted by the server; the server - will not attempt to locate and/or validate the key. + When a SIG(0) signed message is received, it will only be + verified if the key is known and trusted by the server; the server + will not attempt to locate and/or validate the key. - SIG(0) signing of multiple-message TCP streams is not - supported. + SIG(0) signing of multiple-message TCP streams is not + supported. - The only tool shipped with BIND 9 that - generates SIG(0) signed messages is nsupdate. + The only tool shipped with BIND 9 that + generates SIG(0) signed messages is nsupdate. @@ -2069,108 +2069,108 @@ allow-update { key host1-host2. ;}; DNSSEC - Cryptographic authentication of DNS information is possible - through the DNS Security (DNSSEC-bis) extensions, - defined in RFC 4033, RFC 4034, and RFC 4035. + Cryptographic authentication of DNS information is possible + through the DNS Security (DNSSEC-bis) extensions, + defined in RFC 4033, RFC 4034, and RFC 4035. This section describes the creation and use of DNSSEC signed zones. - In order to set up a DNSSEC secure zone, there are a series - of steps which must be followed. BIND - 9 ships - with several tools - that are used in this process, which are explained in more detail - below. In all cases, the option prints a - full list of parameters. Note that the DNSSEC tools require the - keyset files to be in the working directory or the - directory specified by the option, and - that the tools shipped with BIND 9.2.x and earlier are not compatible - with the current ones. + In order to set up a DNSSEC secure zone, there are a series + of steps which must be followed. BIND + 9 ships + with several tools + that are used in this process, which are explained in more detail + below. In all cases, the option prints a + full list of parameters. Note that the DNSSEC tools require the + keyset files to be in the working directory or the + directory specified by the option, and + that the tools shipped with BIND 9.2.x and earlier are not compatible + with the current ones. - There must also be communication with the administrators of - the parent and/or child zone to transmit keys. A zone's security - status must be indicated by the parent zone for a DNSSEC capable - resolver to trust its data. This is done through the presence - or absence of a DS record at the - delegation - point. + There must also be communication with the administrators of + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presence + or absence of a DS record at the + delegation + point. - For other servers to trust data in this zone, they must - either be statically configured with this zone's zone key or the - zone key of another zone above this one in the DNS tree. + For other servers to trust data in this zone, they must + either be statically configured with this zone's zone key or the + zone key of another zone above this one in the DNS tree. - Generating Keys - - - The dnssec-keygen program is used to - generate keys. - - - - A secure zone must contain one or more zone keys. The - zone keys will sign all other records in the zone, as well as - the zone keys of any secure delegated zones. Zone keys must - have the same name as the zone, a name type of - ZONE, and must be usable for - authentication. - It is recommended that zone keys use a cryptographic algorithm - designated as "mandatory to implement" by the IETF; currently - the only one is RSASHA1. - - - - The following command will generate a 768-bit RSASHA1 key for - the child.example zone: - - - - dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example. - - - - Two output files will be produced: - Kchild.example.+005+12345.key and - Kchild.example.+005+12345.private - (where - 12345 is an example of a key tag). The key filenames contain - the key name (child.example.), - algorithm (3 - is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in - this case). - The private key (in the .private - file) is - used to generate signatures, and the public key (in the - .key file) is used for signature - verification. - - - - To generate another key with the same properties (but with - a different key tag), repeat the above command. - - - - The dnssec-keyfromlabel program is used - to get a key pair from a crypto hardware and build the key - files. Its usage is similar to dnssec-keygen. - - - - The public keys should be inserted into the zone file by - including the .key files using - $INCLUDE statements. - + Generating Keys + + + The dnssec-keygen program is used to + generate keys. + + + + A secure zone must contain one or more zone keys. The + zone keys will sign all other records in the zone, as well as + the zone keys of any secure delegated zones. Zone keys must + have the same name as the zone, a name type of + ZONE, and must be usable for + authentication. + It is recommended that zone keys use a cryptographic algorithm + designated as "mandatory to implement" by the IETF; currently + the only one is RSASHA1. + + + + The following command will generate a 768-bit RSASHA1 key for + the child.example zone: + + + + dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example. + + + + Two output files will be produced: + Kchild.example.+005+12345.key and + Kchild.example.+005+12345.private + (where + 12345 is an example of a key tag). The key filenames contain + the key name (child.example.), + algorithm (3 + is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in + this case). + The private key (in the .private + file) is + used to generate signatures, and the public key (in the + .key file) is used for signature + verification. + + + + To generate another key with the same properties (but with + a different key tag), repeat the above command. + + + + The dnssec-keyfromlabel program is used + to get a key pair from a crypto hardware and build the key + files. Its usage is similar to dnssec-keygen. + + + + The public keys should be inserted into the zone file by + including the .key files using + $INCLUDE statements. + - Signing the Zone + Signing the Zone The dnssec-signzone program is used @@ -2188,66 +2188,66 @@ allow-update { key host1-host2. ;}; zones need to be added manually. - - The following command signs the zone, assuming it is in a - file called zone.child.example. By - default, all zone keys which have an available private key are - used to generate signatures. - - - - dnssec-signzone -o child.example zone.child.example - - - - One output file is produced: - zone.child.example.signed. This - file - should be referenced by named.conf - as the - input file for the zone. - - - dnssec-signzone + + The following command signs the zone, assuming it is in a + file called zone.child.example. By + default, all zone keys which have an available private key are + used to generate signatures. + + + + dnssec-signzone -o child.example zone.child.example + + + + One output file is produced: + zone.child.example.signed. This + file + should be referenced by named.conf + as the + input file for the zone. + + + dnssec-signzone will also produce a keyset and dsset files and optionally a - dlvset file. These are used to provide the parent zone - administrators with the DNSKEYs (or their - corresponding DS records) that are the - secure entry point to the zone. - + dlvset file. These are used to provide the parent zone + administrators with the DNSKEYs (or their + corresponding DS records) that are the + secure entry point to the zone. + - Configuring Servers + Configuring Servers To enable named to respond appropriately to DNS requests from DNSSEC aware clients, dnssec-enable must be set to yes. - (This is the default setting.) - + (This is the default setting.) + To enable named to validate answers from other servers, the dnssec-enable option - must be set to yes, and the - dnssec-validation options must be set to - yes or auto. - + must be set to yes, and the + dnssec-validation options must be set to + yes or auto. + - If dnssec-validation is set to - auto, then a default - trust anchor for the DNS root zone will be used. - If it is set to yes, however, - then at least one trust anchor must be configured - with a trusted-keys or - managed-keys statement in - named.conf, or DNSSEC validation - will not occur. The default setting is - yes. - + If dnssec-validation is set to + auto, then a default + trust anchor for the DNS root zone will be used. + If it is set to yes, however, + then at least one trust anchor must be configured + with a trusted-keys or + managed-keys statement in + named.conf, or DNSSEC validation + will not occur. The default setting is + yes. + trusted-keys are copies of DNSKEY RRs @@ -2260,13 +2260,13 @@ allow-update { key host1-host2. ;}; managed-keys are trusted keys which are - automatically kept up to date via RFC 5011 trust anchor - maintenance. + automatically kept up to date via RFC 5011 trust anchor + maintenance. trusted-keys and - managed-keys are described in more detail + managed-keys are described in more detail later in this document. @@ -2283,55 +2283,55 @@ allow-update { key host1-host2. ;}; more public keys for the root. This allows answers from outside the organization to be validated. It will also have several keys for parts of the namespace the organization - controls. These are here to ensure that named - is immune to compromises in the DNSSEC components of the security - of parent zones. + controls. These are here to ensure that named + is immune to compromises in the DNSSEC components of the security + of parent zones. managed-keys { /* Root Key */ - "." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS - JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh - aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy - 4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg - hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp - 5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke - g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq - 66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ - 97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ - dgxbcDTClU0CRBdiieyLMNzXG3"; + "." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS + JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh + aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy + 4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg + hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp + 5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke + g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq + 66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ + 97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ + dgxbcDTClU0CRBdiieyLMNzXG3"; }; trusted-keys { - /* Key for our organization's forward zone */ - example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6 - 5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z - GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb - 4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL - kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O - g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S - TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq - FxmAVZP20igTixin/1LcrgX/KMEGd/biuv - F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm - /oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o - 1OTQ09A0="; - - /* Key for our reverse zone. */ - 2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc - xOdNax071L18QqZnQQQAVVr+i - LhGTnNGp3HoWQLUIzKrJVZ3zg - gy3WwNT6kZo6c0tszYqbtvchm - gQC8CzKojM/W16i6MG/eafGU3 - siaOdS0yOI6BgPsw+YZdzlYMa - IJGf4M4dyoKIhzdZyQ2bYQrjy - Q4LB0lC7aOnsMyYKHHYeRvPxj - IQXmdqgOJGq+vsevG06zW+1xg - YJh9rCIfnm1GX/KMgxLPG2vXT - D/RnLX+D3T3UL7HJYHJhAZD5L - 59VvjSPsZJHeDCUyWYrvPZesZ - DIRvhDD52SKvbheeTJUm6Ehkz - ytNN2SN96QRk8j/iI8ib"; + /* Key for our organization's forward zone */ + example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6 + 5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z + GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb + 4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL + kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O + g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S + TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq + FxmAVZP20igTixin/1LcrgX/KMEGd/biuv + F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm + /oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o + 1OTQ09A0="; + + /* Key for our reverse zone. */ + 2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc + xOdNax071L18QqZnQQQAVVr+i + LhGTnNGp3HoWQLUIzKrJVZ3zg + gy3WwNT6kZo6c0tszYqbtvchm + gQC8CzKojM/W16i6MG/eafGU3 + siaOdS0yOI6BgPsw+YZdzlYMa + IJGf4M4dyoKIhzdZyQ2bYQrjy + Q4LB0lC7aOnsMyYKHHYeRvPxj + IQXmdqgOJGq+vsevG06zW+1xg + YJh9rCIfnm1GX/KMgxLPG2vXT + D/RnLX+D3T3UL7HJYHJhAZD5L + 59VvjSPsZJHeDCUyWYrvPZesZ + DIRvhDD52SKvbheeTJUm6Ehkz + ytNN2SN96QRk8j/iI8ib"; }; options { @@ -2375,10 +2375,10 @@ options { forgery; it rejects the response and logs an error. - The logged error reads "insecurity proof failed" and - "got insecure response; parent indicates it should be secure". + The logged error reads "insecurity proof failed" and + "got insecure response; parent indicates it should be secure". (Prior to BIND 9.7, the logged error was "not insecure". - This referred to the zone, not the response.) + This referred to the zone, not the response.) @@ -2397,82 +2397,82 @@ options { IPv6 Support in <acronym>BIND</acronym> 9 - BIND 9 fully supports all currently - defined forms of IPv6 name to address and address to name - lookups. It will also use IPv6 addresses to make queries when - running on an IPv6 capable system. + BIND 9 fully supports all currently + defined forms of IPv6 name to address and address to name + lookups. It will also use IPv6 addresses to make queries when + running on an IPv6 capable system. - For forward lookups, BIND 9 supports - only AAAA records. RFC 3363 deprecated the use of A6 records, - and client-side support for A6 records was accordingly removed - from BIND 9. - However, authoritative BIND 9 name servers still - load zone files containing A6 records correctly, answer queries - for A6 records, and accept zone transfer for a zone containing A6 - records. + For forward lookups, BIND 9 supports + only AAAA records. RFC 3363 deprecated the use of A6 records, + and client-side support for A6 records was accordingly removed + from BIND 9. + However, authoritative BIND 9 name servers still + load zone files containing A6 records correctly, answer queries + for A6 records, and accept zone transfer for a zone containing A6 + records. - For IPv6 reverse lookups, BIND 9 supports - the traditional "nibble" format used in the - ip6.arpa domain, as well as the older, deprecated - ip6.int domain. - Older versions of BIND 9 - supported the "binary label" (also known as "bitstring") format, - but support of binary labels has been completely removed per - RFC 3363. - Many applications in BIND 9 do not understand - the binary label format at all any more, and will return an - error if given. + For IPv6 reverse lookups, BIND 9 supports + the traditional "nibble" format used in the + ip6.arpa domain, as well as the older, deprecated + ip6.int domain. + Older versions of BIND 9 + supported the "binary label" (also known as "bitstring") format, + but support of binary labels has been completely removed per + RFC 3363. + Many applications in BIND 9 do not understand + the binary label format at all any more, and will return an + error if given. In particular, an authoritative BIND 9 - name server will not load a zone file containing binary labels. + name server will not load a zone file containing binary labels. - For an overview of the format and structure of IPv6 addresses, - see . + For an overview of the format and structure of IPv6 addresses, + see . - Address Lookups Using AAAA Records + Address Lookups Using AAAA Records - - The IPv6 AAAA record is a parallel to the IPv4 A record, - and, unlike the deprecated A6 record, specifies the entire - IPv6 address in a single record. For example, - + + The IPv6 AAAA record is a parallel to the IPv4 A record, + and, unlike the deprecated A6 record, specifies the entire + IPv6 address in a single record. For example, + $ORIGIN example.com. host 3600 IN AAAA 2001:db8::1 - - Use of IPv4-in-IPv6 mapped addresses is not recommended. + + Use of IPv4-in-IPv6 mapped addresses is not recommended. If a host has an IPv4 address, use an A record, not - a AAAA, with ::ffff:192.168.42.1 as - the address. - + a AAAA, with ::ffff:192.168.42.1 as + the address. + - Address to Name Lookups Using Nibble Format - - - When looking up an address in nibble format, the address - components are simply reversed, just as in IPv4, and - ip6.arpa. is appended to the - resulting name. - For example, the following would provide reverse name lookup for - a host with address - 2001:db8::1. - + Address to Name Lookups Using Nibble Format + + + When looking up an address in nibble format, the address + components are simply reversed, just as in IPv4, and + ip6.arpa. is appended to the + resulting name. + For example, the following would provide reverse name lookup for + a host with address + 2001:db8::1. + $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR ( - host.example.com. ) + host.example.com. ) @@ -2484,75 +2484,75 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. The Lightweight Resolver Library - Traditionally applications have been linked with a stub resolver - library that sends recursive DNS queries to a local caching name - server. + Traditionally applications have been linked with a stub resolver + library that sends recursive DNS queries to a local caching name + server. - IPv6 once introduced new complexity into the resolution process, - such as following A6 chains and DNAME records, and simultaneous - lookup of IPv4 and IPv6 addresses. Though most of the complexity was - then removed, these are hard or impossible - to implement in a traditional stub resolver. + IPv6 once introduced new complexity into the resolution process, + such as following A6 chains and DNAME records, and simultaneous + lookup of IPv4 and IPv6 addresses. Though most of the complexity was + then removed, these are hard or impossible + to implement in a traditional stub resolver. - BIND 9 therefore can also provide resolution - services to local clients - using a combination of a lightweight resolver library and a resolver - daemon process running on the local host. These communicate using - a simple UDP-based protocol, the "lightweight resolver protocol" - that is distinct from and simpler than the full DNS protocol. + BIND 9 therefore can also provide resolution + services to local clients + using a combination of a lightweight resolver library and a resolver + daemon process running on the local host. These communicate using + a simple UDP-based protocol, the "lightweight resolver protocol" + that is distinct from and simpler than the full DNS protocol. Running a Resolver Daemon - To use the lightweight resolver interface, the system must - run the resolver daemon lwresd or a - local - name server configured with a lwres - statement. + To use the lightweight resolver interface, the system must + run the resolver daemon lwresd or a + local + name server configured with a lwres + statement. - By default, applications using the lightweight resolver library will - make - UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. - The - address can be overridden by lwserver - lines in - /etc/resolv.conf. + By default, applications using the lightweight resolver library will + make + UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. + The + address can be overridden by lwserver + lines in + /etc/resolv.conf. - The daemon currently only looks in the DNS, but in the future - it may use other sources such as /etc/hosts, - NIS, etc. + The daemon currently only looks in the DNS, but in the future + it may use other sources such as /etc/hosts, + NIS, etc. - The lwresd daemon is essentially a - caching-only name server that responds to requests using the - lightweight - resolver protocol rather than the DNS protocol. Because it needs - to run on each host, it is designed to require no or minimal - configuration. - Unless configured otherwise, it uses the name servers listed on - nameserver lines in /etc/resolv.conf - as forwarders, but is also capable of doing the resolution - autonomously if - none are specified. + The lwresd daemon is essentially a + caching-only name server that responds to requests using the + lightweight + resolver protocol rather than the DNS protocol. Because it needs + to run on each host, it is designed to require no or minimal + configuration. + Unless configured otherwise, it uses the name servers listed on + nameserver lines in /etc/resolv.conf + as forwarders, but is also capable of doing the resolution + autonomously if + none are specified. - The lwresd daemon may also be - configured with a - named.conf style configuration file, - in - /etc/lwresd.conf by default. A name - server may also - be configured to act as a lightweight resolver daemon using the - lwres statement in named.conf. + The lwresd daemon may also be + configured with a + named.conf style configuration file, + in + /etc/lwresd.conf by default. A name + server may also + be configured to act as a lightweight resolver daemon using the + lwres statement in named.conf. @@ -2581,118 +2581,118 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. Configuration File Elements - Following is a list of elements used throughout the BIND configuration - file documentation: + Following is a list of elements used throughout the BIND configuration + file documentation: - - - - - - - - acl_name - - - - - The name of an address_match_list as - defined by the acl statement. - - - - - - - address_match_list - - - - - A list of one or more - ip_addr, - ip_prefix, key_id, - or acl_name elements, see - . - - - - - - - masters_list - - - - - A named list of one or more ip_addr + + + + + + + + acl_name + + + + + The name of an address_match_list as + defined by the acl statement. + + + + + + + address_match_list + + + + + A list of one or more + ip_addr, + ip_prefix, key_id, + or acl_name elements, see + . + + + + + + + masters_list + + + + + A named list of one or more ip_addr with optional key_id and/or ip_port. A masters_list may include other masters_lists. - - - - - - - domain_name - - - - - A quoted string which will be used as - a DNS name, for example "my.test.domain". - - - - - - - namelist - - - - - A list of one or more domain_name - elements. - - - - - - - dotted_decimal - - - - - One to four integers valued 0 through - 255 separated by dots (`.'), such as 123, - 45.67 or 89.123.45.67. - - - - - - - ip4_addr - - - - - An IPv4 address with exactly four elements - in dotted_decimal notation. - - - - - - - ip6_addr - - + + + + + + + domain_name + + + + + A quoted string which will be used as + a DNS name, for example "my.test.domain". + + + + + + + namelist + + + + + A list of one or more domain_name + elements. + + + + + + + dotted_decimal + + + + + One to four integers valued 0 through + 255 separated by dots (`.'), such as 123, + 45.67 or 89.123.45.67. + + + + + + + ip4_addr + + + + + An IPv4 address with exactly four elements + in dotted_decimal notation. + + + + + + + ip6_addr + + An IPv6 address, such as 2001:db8::1234. @@ -2716,144 +2716,144 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. - - - - ip_addr - - - - - An ip4_addr or ip6_addr. - - - - - - - ip_dscp - - - - - A number between 0 and 63, used - to select a differentiated services code point (DSCP) - value for use with outgoing traffic on operating systems - that support DSCP. - - - - - - - ip_port - - - - - An IP port number. - The number is limited to 0 - through 65535, with values - below 1024 typically restricted to use by processes running - as root. - In some cases, an asterisk (`*') character can be used as a - placeholder to - select a random high-numbered port. - - - - - - - ip_prefix - - - - - An IP network specified as an ip_addr, - followed by a slash (`/') and then the number of bits in the - netmask. - Trailing zeros in a ip_addr - may omitted. - For example, 127/8 is the - network 127.0.0.0 with - netmask 255.0.0.0 and 1.2.3.0/28 is - network 1.2.3.0 with netmask 255.255.255.240. - - - When specifying a prefix involving a IPv6 scoped address - the scope may be omitted. In that case the prefix will - match packets from any scope. - - - - - - - key_id - - - - - A domain_name representing - the name of a shared key, to be used for transaction - security. - - - - - - - key_list - - - - - A list of one or more - key_ids, - separated by semicolons and ending with a semicolon. - - - - - - - number - - - - - A non-negative 32-bit integer - (i.e., a number between 0 and 4294967295, inclusive). - Its acceptable value might further - be limited by the context in which it is used. - - - - - - - path_name - - - - - A quoted string which will be used as - a pathname, such as zones/master/my.test.domain. - - - - - - - port_list - - - - - A list of an ip_port or a port - range. - A port range is specified in the form of + + + + ip_addr + + + + + An ip4_addr or ip6_addr. + + + + + + + ip_dscp + + + + + A number between 0 and 63, used + to select a differentiated services code point (DSCP) + value for use with outgoing traffic on operating systems + that support DSCP. + + + + + + + ip_port + + + + + An IP port number. + The number is limited to 0 + through 65535, with values + below 1024 typically restricted to use by processes running + as root. + In some cases, an asterisk (`*') character can be used as a + placeholder to + select a random high-numbered port. + + + + + + + ip_prefix + + + + + An IP network specified as an ip_addr, + followed by a slash (`/') and then the number of bits in the + netmask. + Trailing zeros in a ip_addr + may omitted. + For example, 127/8 is the + network 127.0.0.0 with + netmask 255.0.0.0 and 1.2.3.0/28 is + network 1.2.3.0 with netmask 255.255.255.240. + + + When specifying a prefix involving a IPv6 scoped address + the scope may be omitted. In that case the prefix will + match packets from any scope. + + + + + + + key_id + + + + + A domain_name representing + the name of a shared key, to be used for transaction + security. + + + + + + + key_list + + + + + A list of one or more + key_ids, + separated by semicolons and ending with a semicolon. + + + + + + + number + + + + + A non-negative 32-bit integer + (i.e., a number between 0 and 4294967295, inclusive). + Its acceptable value might further + be limited by the context in which it is used. + + + + + + + path_name + + + + + A quoted string which will be used as + a pathname, such as zones/master/my.test.domain. + + + + + + + port_list + + + + + A list of an ip_port or a port + range. + A port range is specified in the form of range followed by two ip_ports, port_low and @@ -2867,96 +2867,96 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. ports from 1024 through 65535. In either case an asterisk (`*') character is not allowed as a valid ip_port. - - - - - - - size_spec - - - - - A 64-bit unsigned integer, or the keywords - unlimited or - default. - - - Integers may take values - 0 <= value <= 18446744073709551615, though - certain parameters - (such as max-journal-size) may - use a more limited range within these extremes. - In most cases, setting a value to 0 does not - literally mean zero; it means "undefined" or - "as big as possible", depending on the context. - See the expalantions of particular parameters - that use size_spec - for details on how they interpret its use. - - - Numeric values can optionally be followed by a - scaling factor: + + + + + + + size_spec + + + + + A 64-bit unsigned integer, or the keywords + unlimited or + default. + + + Integers may take values + 0 <= value <= 18446744073709551615, though + certain parameters + (such as max-journal-size) may + use a more limited range within these extremes. + In most cases, setting a value to 0 does not + literally mean zero; it means "undefined" or + "as big as possible", depending on the context. + See the expalantions of particular parameters + that use size_spec + for details on how they interpret its use. + + + Numeric values can optionally be followed by a + scaling factor: K or k for kilobytes, M or m for megabytes, and - G or g - for gigabytes, which scale by 1024, 1024*1024, and - 1024*1024*1024 respectively. - - - unlimited generally means - "as big as possible", and is usually the best - way to safely set a very large number. - - - default - uses the limit that was in force when the server was started. - - - - - - - yes_or_no - - - - - Either yes or no. - The words true and false are - also accepted, as are the numbers 1 - and 0. - - - - - - - dialup_option - - - - - One of yes, - no, notify, - notify-passive, refresh or - passive. - When used in a zone, notify-passive, - refresh, and passive - are restricted to slave and stub zones. - - - - - + G or g + for gigabytes, which scale by 1024, 1024*1024, and + 1024*1024*1024 respectively. + + + unlimited generally means + "as big as possible", and is usually the best + way to safely set a very large number. + + + default + uses the limit that was in force when the server was started. + + + + + + + yes_or_no + + + + + Either yes or no. + The words true and false are + also accepted, as are the numbers 1 + and 0. + + + + + + + dialup_option + + + + + One of yes, + no, notify, + notify-passive, refresh or + passive. + When used in a zone, notify-passive, + refresh, and passive + are restricted to slave and stub zones. + + + + + - Address Match Lists - - Syntax + Address Match Lists + + Syntax address_match_list = address_match_list_element ; address_match_list_element; ... @@ -2964,67 +2964,67 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. key key_id | acl_name | { address_match_list } ) - - - Definition and Usage - - 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: - - - - an IP address (IPv4 or IPv6) - - - an IP prefix (in `/' notation) - - - - a key ID, as defined by the key - statement - - - - the name of an address match list defined with - the acl statement - - - - a nested address match list enclosed in braces - - - - - 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. - + + + Definition and Usage + + 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: + + + + an IP address (IPv4 or IPv6) + + + an IP prefix (in `/' notation) + + + + a key ID, as defined by the key + statement + + + + the name of an address match list defined with + the acl statement + + + + a nested address match list enclosed in braces + + + + + 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 @@ -3046,63 +3046,63 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 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 - first in the ACL definition. - Because of this first-match behavior, an element that - defines a subset of another element in the list should - come before the broader element, regardless of whether - either is negated. For example, in - 1.2.3/24; ! 1.2.3.13; - the 1.2.3.13 element is completely useless because the - algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 - element. Using ! 1.2.3.13; 1.2.3/24 fixes - that problem by having 1.2.3.13 blocked by the negation, but - all other 1.2.3.* hosts fall through. - - + + 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 + first in the ACL definition. + Because of this first-match behavior, an element that + defines a subset of another element in the list should + come before the broader element, regardless of whether + either is negated. For example, in + 1.2.3/24; ! 1.2.3.13; + the 1.2.3.13 element is completely useless because the + algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 + element. Using ! 1.2.3.13; 1.2.3/24 fixes + that problem by having 1.2.3.13 blocked by the negation, but + all other 1.2.3.* hosts fall through. + + - Comment Syntax - - - 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. - - - - Syntax - - - /* This is a BIND comment as in C */ - // This is a BIND comment as in C++ - # This is a BIND comment as in common UNIX shells + Comment Syntax + + + 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. + + + + Syntax + + + /* This is a BIND comment as in C */ + // This is a BIND comment as in C++ + # This is a BIND comment as in common UNIX shells # and perl - - - - Definition and Usage - - 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 */: - - + + + + Definition and Usage + + 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. This is still part of the comment. @@ -3110,49 +3110,49 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. This is no longer in any comment. */ - + - - 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: - - + + 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 // is a new comment, even though it is logically // part of the previous comment. - - - 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: - + + + 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 # is a new comment, even though it is logically # part of the previous comment. - - - - - 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. - - - + + + + + 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. + + + @@ -3160,188 +3160,188 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. Configuration File Grammar - A BIND 9 configuration consists of - statements and comments. - Statements end with a semicolon. Statements and comments are the - only elements that can appear without enclosing braces. Many - statements contain a block of sub-statements, which are also - terminated with a semicolon. + A BIND 9 configuration consists of + statements and comments. + Statements end with a semicolon. Statements and comments are the + only elements that can appear without enclosing braces. Many + statements contain a block of sub-statements, which are also + terminated with a semicolon. - The following statements are supported: + The following statements are supported: - - - - - - - acl - - - - defines a named IP address - matching list, for access control and other uses. - - - - - - controls - - - - declares control channels to be used - by the rndc utility. - - - - - - include - - - - includes a file. - - - - - - key - - - - specifies key information for use in - authentication and authorization using TSIG. - - - - - - logging - - - - specifies what the server logs, and where - the log messages are sent. - - - - - - lwres - - - - configures named to - also act as a light-weight resolver daemon (lwresd). - - - - - - masters - - - - defines a named masters list for - inclusion in stub and slave zones' - masters or - also-notify lists. - - - - - - options - - - - controls global server configuration - options and sets defaults for other statements. - - - - - - server - - - - sets certain configuration options on - a per-server basis. - - - - - - statistics-channels - - - + + + + + + + acl + + + + defines a named IP address + matching list, for access control and other uses. + + + + + + controls + + + + declares control channels to be used + by the rndc utility. + + + + + + include + + + + includes a file. + + + + + + key + + + + specifies key information for use in + authentication and authorization using TSIG. + + + + + + logging + + + + specifies what the server logs, and where + the log messages are sent. + + + + + + lwres + + + + configures named to + also act as a light-weight resolver daemon (lwresd). + + + + + + masters + + + + defines a named masters list for + inclusion in stub and slave zones' + masters or + also-notify lists. + + + + + + options + + + + controls global server configuration + options and sets defaults for other statements. + + + + + + server + + + + sets certain configuration options on + a per-server basis. + + + + + + statistics-channels + + + declares communication channels to get access to named statistics. - - - - - - trusted-keys - - - - defines trusted DNSSEC keys. - - - - - - managed-keys - - - - lists DNSSEC keys to be kept up to date - using RFC 5011 trust anchor maintenance. - - - - - - view - - - - defines a view. - - - - - - zone - - - - defines a zone. - - - - - + + + + + + trusted-keys + + + + defines trusted DNSSEC keys. + + + + + + managed-keys + + + + lists DNSSEC keys to be kept up to date + using RFC 5011 trust anchor maintenance. + + + + + + view + + + + defines a view. + + + + + + zone + + + + defines a zone. + + + + + - The logging and - options statements may only occur once - per - configuration. + The logging and + options statements may only occur once + per + configuration. - <command>acl</command> Statement Grammar + <command>acl</command> Statement Grammar acl acl-name { address_match_list @@ -3350,127 +3350,127 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. - <command>acl</command> Statement Definition and - Usage - - - 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). - - - - Note that an address match list's name must be defined - with acl before it can be used - elsewhere; no forward references are allowed. - - - - The following ACLs are built-in: - - - - - - - - - - any - - - - Matches all hosts. - - - - - - none - - - - Matches no hosts. - - - - - - localhost - - - - Matches the IPv4 and IPv6 addresses of all network - interfaces on the system. - - - - - - localnets - - - - Matches any host on an IPv4 or IPv6 network - for which the system has an interface. - Some systems do not provide a way to determine the prefix - lengths of - local IPv6 addresses. - In such a case, localnets - only matches the local - IPv6 addresses, just like localhost. - - - - - - - - - When BIND 9 is built with GeoIP support, - ACLs can also be used for geographic access restrictions. - This is done by specifying an ACL element of the form: - geoip db database field value - - - The field indicates which field - to search for a match. Available fields are "country", - "region", "city", "continent", "postal" (postal code), - "metro" (metro code), "area" (area code), "tz" (timezone), - "isp", "org", "asnum", "domain" and "netspeed". - - - value is the value to searched for - within the database. A string may be quoted if it contains - spaces or other special characters. If this is a "country" - search and the string is two characters long, then it must be a - standard ISO-3166-1 two-letter country code, and if it is three - characters long then it must be an ISO-3166-1 three-letter - country code; otherwise it is the full name of the country. - Similarly, if this is a "region" search and the string is - two characters long, then it must be a standard two-letter state - or province abbreviation; otherwise it is the full name of the - state or province. - - - The database field indicates which - GeoIP database to search for a match. In most cases this is - unnecessary, because most search fields can only be found in - a single database. However, searches for country can be - answered from the "city", "region", or "country" databases, - and searches for region (i.e., state or province) can be - answered from the "city" or "region" databases. For these - search types, specifying a database - will force the query to be answered from that database and no - other. If database is not - specified, then these queries will be answered from the "city", - database if it is installed, or the "region" database if it is - installed, or the "country" database, in that order. - - - Some example GeoIP ACLs: - - geoip country US; + <command>acl</command> Statement Definition and + Usage + + + 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). + + + + Note that an address match list's name must be defined + with acl before it can be used + elsewhere; no forward references are allowed. + + + + The following ACLs are built-in: + + + + + + + + + + any + + + + Matches all hosts. + + + + + + none + + + + Matches no hosts. + + + + + + localhost + + + + Matches the IPv4 and IPv6 addresses of all network + interfaces on the system. + + + + + + localnets + + + + Matches any host on an IPv4 or IPv6 network + for which the system has an interface. + Some systems do not provide a way to determine the prefix + lengths of + local IPv6 addresses. + In such a case, localnets + only matches the local + IPv6 addresses, just like localhost. + + + + + + + + + When BIND 9 is built with GeoIP support, + ACLs can also be used for geographic access restrictions. + This is done by specifying an ACL element of the form: + geoip db database field value + + + The field indicates which field + to search for a match. Available fields are "country", + "region", "city", "continent", "postal" (postal code), + "metro" (metro code), "area" (area code), "tz" (timezone), + "isp", "org", "asnum", "domain" and "netspeed". + + + value is the value to searched for + within the database. A string may be quoted if it contains + spaces or other special characters. If this is a "country" + search and the string is two characters long, then it must be a + standard ISO-3166-1 two-letter country code, and if it is three + characters long then it must be an ISO-3166-1 three-letter + country code; otherwise it is the full name of the country. + Similarly, if this is a "region" search and the string is + two characters long, then it must be a standard two-letter state + or province abbreviation; otherwise it is the full name of the + state or province. + + + The database field indicates which + GeoIP database to search for a match. In most cases this is + unnecessary, because most search fields can only be found in + a single database. However, searches for country can be + answered from the "city", "region", or "country" databases, + and searches for region (i.e., state or province) can be + answered from the "city" or "region" databases. For these + search types, specifying a database + will force the query to be answered from that database and no + other. If database is not + specified, then these queries will be answered from the "city", + database if it is installed, or the "region" database if it is + installed, or the "country" database, in that order. + + + Some example GeoIP ACLs: + + geoip country US; geoip country JAP; geoip db country country Canada; geoip db region region WA; @@ -3484,12 +3484,12 @@ geoip org "Internet Systems Consortium"; - <command>controls</command> Statement Grammar + <command>controls</command> Statement Grammar controls { [ inet ( ip_addr | * ) [ port ip_port ] - allow { address_match_list } - keys { key_list }; ] + allow { address_match_list } + keys { key_list }; ] [ inet ...; ] [ unix path perm number owner number group number keys { key_list }; ] @@ -3500,46 +3500,46 @@ geoip org "Internet Systems Consortium"; - <command>controls</command> Statement Definition and - Usage - - - 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 + <command>controls</command> Statement Definition and + Usage + + + 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 address. An ip_addr of * (asterisk) is interpreted as the IPv4 wildcard address; connections will be accepted on any of the system's IPv4 addresses. To listen on the IPv6 wildcard address, - use an ip_addr of ::. - If you will only use rndc on the local host, - 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 + use an ip_addr of ::. + If you will only use rndc on the local host, + 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. + + The ability to issue commands over the control channel is + restricted by the allow and + keys clauses. Connections to the control channel are permitted based on the - address_match_list. This is for simple - IP address based filtering only; any key_id - elements of the address_match_list - are ignored. - + address_match_list. This is for simple + IP address based filtering only; any key_id + elements of the address_match_list + are ignored. + A unix control channel is a UNIX domain @@ -3551,96 +3551,96 @@ geoip org "Internet Systems Consortium"; 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. - Each key_id in the key_list + + The primary authorization mechanism of the command + channel is the key_list, which + contains a list of key_ids. + Each key_id in the key_list is authorized to execute commands over the control channel. - See in ) + See in ) for information about configuring keys in rndc. - - - - If no controls statement is present, - named will set up a default - control channel listening on the loopback address 127.0.0.1 - and its IPv6 counterpart ::1. - In this case, and also when the controls statement - is present but does not have a keys clause, - named will attempt to load the command channel key - from the file rndc.key in - /etc (or whatever sysconfdir - was specified as when BIND was built). - 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 - messages and thus did not have a keys clause. - - It makes it possible to use an existing BIND 8 - configuration file in BIND 9 unchanged, - and still have rndc work the same way - ndc worked in BIND 8, simply by executing the - 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 - feature does not - have a high degree of configurability. You cannot easily change - the key name or the size of the secret, so you should make a - rndc.conf with your own key if you - wish to change - those things. The rndc.key file - also has its - permissions set such that only the owner of the file (the user that - named is running as) can access it. - If you - desire greater flexibility in allowing other users to access - rndc commands, then you need to create - a - rndc.conf file and make it group - readable by a group - that contains the users who should have access. - - - - To disable the command channel, use an empty + + + + If no controls statement is present, + named will set up a default + control channel listening on the loopback address 127.0.0.1 + and its IPv6 counterpart ::1. + In this case, and also when the controls statement + is present but does not have a keys clause, + named will attempt to load the command channel key + from the file rndc.key in + /etc (or whatever sysconfdir + was specified as when BIND was built). + 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 + messages and thus did not have a keys clause. + + It makes it possible to use an existing BIND 8 + configuration file in BIND 9 unchanged, + and still have rndc work the same way + ndc worked in BIND 8, simply by executing the + 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 + feature does not + have a high degree of configurability. You cannot easily change + the key name or the size of the secret, so you should make a + rndc.conf with your own key if you + wish to change + those things. The rndc.key file + also has its + permissions set such that only the owner of the file (the user that + named is running as) can access it. + If you + desire greater flexibility in allowing other users to access + rndc commands, then you need to create + a + rndc.conf file and make it group + readable by a group + that contains the users who should have access. + + + + To disable the command channel, use an empty controls statement: controls { };. - + - <command>include</command> Statement Grammar - include filename; + <command>include</command> Statement Grammar + include filename; - <command>include</command> Statement Definition and - Usage - - - The include statement inserts the - specified file at the point where the include - statement is encountered. The include - statement facilitates the administration of configuration - files - by permitting the reading or writing of some things but not - others. For example, the statement could include private keys - that are readable only by the name server. - + <command>include</command> Statement Definition and + Usage + + + The include statement inserts the + specified file at the point where the include + statement is encountered. The include + statement facilitates the administration of configuration + files + by permitting the reading or writing of some things but not + others. For example, the statement could include private keys + that are readable only by the name server. + - <command>key</command> Statement Grammar + <command>key</command> Statement Grammar key key_id { algorithm string; @@ -3651,35 +3651,35 @@ geoip org "Internet Systems Consortium"; - <command>key</command> Statement Definition and Usage - - - The key statement defines a shared - secret key for use with TSIG (see ) - or the command channel - (see ). - - - - The key statement can occur at the - top level - of the configuration file or inside a view - statement. Keys defined in top-level key - statements can be used in all views. Keys intended for use in - a controls statement - (see ) - 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 - statement to cause requests sent to that - server to be signed with this key, or in address match lists to - verify that incoming requests have been signed with a key - matching this name, algorithm, and secret. - + <command>key</command> Statement Definition and Usage + + + The key statement defines a shared + secret key for use with TSIG (see ) + or the command channel + (see ). + + + + The key statement can occur at the + top level + of the configuration file or inside a view + statement. Keys defined in top-level key + statements can be used in all views. Keys intended for use in + a controls statement + (see ) + 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 + statement to cause requests sent to that + server to be signed with this key, or in address match lists to + verify that incoming requests have been signed with a key + matching this name, algorithm, and secret. + The algorithm_id is a string @@ -3698,18 +3698,18 @@ geoip org "Internet Systems Consortium"; - <command>logging</command> Statement Grammar + <command>logging</command> Statement Grammar logging { [ channel channel_name { ( file path_name - [ versions ( number | unlimited ) ] - [ size size_spec ] + [ versions ( number | unlimited ) ] + [ size size_spec ] | syslog syslog_facility | stderr | null ); [ severity ( | | | | - | [ level ] | ); ] + | [ level ] | ); ] [ print-category or ; ] [ print-severity or ; ] [ print-time or ; ] @@ -3724,23 +3724,23 @@ geoip org "Internet Systems Consortium"; - <command>logging</command> Statement Definition and - Usage - - - The logging statement configures a - wide - variety of logging options for the name server. Its channel phrase - associates output methods, format options and severity levels with - 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: - + <command>logging</command> Statement Definition and + Usage + + + The logging statement configures a + wide + variety of logging options for the name server. Its channel phrase + associates output methods, format options and severity levels with + 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; }; @@ -3748,98 +3748,98 @@ geoip org "Internet Systems Consortium"; }; - - In BIND 9, the logging configuration - is only established when - the entire configuration file has been parsed. In BIND 8, it was - established as soon as the logging - statement - was parsed. When the server is starting up, all logging messages - regarding syntax errors in the configuration file go to the default - channels, or to standard error if the "" option - was specified. - - - - The <command>channel</command> Phrase - - - 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 - discarded. It can optionally also limit the message severity level - that will be accepted by the channel (the default is - info), and whether to include a - named-generated time stamp, the - 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 limitations - both on how large the file is allowed to become, and how many - versions - of the file will be saved each time the file is opened. - - - - If you use the versions log file - option, then - named will retain that many backup - versions of the file by - renaming them when opening. For example, if you choose to keep - three old versions - of the file lamers.log, then just - before it is opened - lamers.log.1 is renamed to - lamers.log.2, lamers.log.0 is renamed - to lamers.log.1, and lamers.log is - renamed to lamers.log.0. - You can say versions unlimited to - not limit - the number of versions. - If a size option is associated with - the log file, - then renaming is only done when the file being opened exceeds the - indicated size. No backup versions are kept by default; any - existing - log file is simply appended. - - - - The size option for files is used - to limit log - growth. If the file ever exceeds the size, then named will - stop writing to the file unless it has a versions option - associated with it. If backup versions are kept, the files are - rolled as - described above and a new one begun. If there is no - versions option, no more data will - be written to the log - until some out-of-band mechanism removes or truncates the log to - less than the - maximum size. The default behavior is not to limit the size of - the - file. - - - - Example usage of the size and - versions options: - + + In BIND 9, the logging configuration + is only established when + the entire configuration file has been parsed. In BIND 8, it was + established as soon as the logging + statement + was parsed. When the server is starting up, all logging messages + regarding syntax errors in the configuration file go to the default + channels, or to standard error if the "" option + was specified. + + + + The <command>channel</command> Phrase + + + 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 + discarded. It can optionally also limit the message severity level + that will be accepted by the channel (the default is + info), and whether to include a + named-generated time stamp, the + 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 limitations + both on how large the file is allowed to become, and how many + versions + of the file will be saved each time the file is opened. + + + + If you use the versions log file + option, then + named will retain that many backup + versions of the file by + renaming them when opening. For example, if you choose to keep + three old versions + of the file lamers.log, then just + before it is opened + lamers.log.1 is renamed to + lamers.log.2, lamers.log.0 is renamed + to lamers.log.1, and lamers.log is + renamed to lamers.log.0. + You can say versions unlimited to + not limit + the number of versions. + If a size option is associated with + the log file, + then renaming is only done when the file being opened exceeds the + indicated size. No backup versions are kept by default; any + existing + log file is simply appended. + + + + The size option for files is used + to limit log + growth. If the file ever exceeds the size, then named will + stop writing to the file unless it has a versions option + associated with it. If backup versions are kept, the files are + rolled as + described above and a new one begun. If there is no + versions option, no more data will + be written to the log + until some out-of-band mechanism removes or truncates the log to + less than the + maximum size. The default behavior is not to limit the size of + the + file. + + + + Example usage of the size and + versions options: + channel an_example_channel { file "example.log" versions 3 size 20m; @@ -3848,77 +3848,77 @@ geoip org "Internet Systems Consortium"; }; - - The syslog destination clause - directs the - channel to the system log. Its argument is a - syslog facility as described in the syslog man - page. Known facilities are kern, user, - mail, daemon, auth, - syslog, lpr, news, - uucp, cron, authpriv, - ftp, local0, local1, - local2, local3, local4, - local5, local6 and - local7, however not all facilities - are supported on - all operating systems. - How syslog will handle messages - sent to - this facility is described in the syslog.conf man - page. If you have a system which uses a very old version of syslog that - only uses two arguments to the openlog() function, - then this clause is silently ignored. - - + + The syslog destination clause + directs the + channel to the system log. Its argument is a + syslog facility as described in the syslog man + page. Known facilities are kern, user, + mail, daemon, auth, + syslog, lpr, news, + uucp, cron, authpriv, + ftp, local0, local1, + local2, local3, local4, + local5, local6 and + local7, however not all facilities + are supported on + all operating systems. + How syslog will handle messages + sent to + this facility is described in the syslog.conf man + page. If you have a system which uses a very old version of syslog that + 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. - Messages which are not at least of the severity level given will - not be selected for the channel; messages of higher severity - 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 - only logging daemon.warning via syslog.conf will - cause messages of severity info and - notice to - be dropped. If the situation were reversed, with named writing - messages of only warning or higher, - 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 - for - use when the server is running as a foreground process, for - 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 - than zero, then debugging mode will be active. The global debug - level is set either by starting the named server - with the flag followed by a positive integer, - or by running rndc trace. - The global debug level - can be set to zero, and debugging mode turned off, by running rndc + + + 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. + Messages which are not at least of the severity level given will + not be selected for the channel; messages of higher severity + 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 + only logging daemon.warning via syslog.conf will + cause messages of severity info and + notice to + be dropped. If the situation were reversed, with named writing + messages of only warning or higher, + 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 + for + use when the server is running as a foreground process, for + 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 + than zero, then debugging mode will be active. The global debug + level is set either by starting the named server + with the flag followed by a positive integer, + or by running rndc trace. + The global debug level + can be set to zero, and debugging mode turned off, by running rndc 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: - + level, and higher debug levels give more detailed output. Channels + that specify a specific debug severity, for example: + channel specific_debug_level { file "foo"; @@ -3926,42 +3926,42 @@ notrace. All debugging messages in the server have a debug }; - - 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. - - - If print-time has been turned on, - then - the date and time will be logged. print-time may - be specified for a syslog channel, - but 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 - on, then the severity level of the message will be logged. The print- options may - be used in any combination, and will always be printed in the - following - order: time, category, severity. Here is an example where all - three print- options - are on: - - - - 28-Feb-2000 15:05:32.863 general: notice: running - - - - There are four predefined channels that are used for - named's default logging as follows. - How they are - used is described in . - + + 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. + + + If print-time has been turned on, + then + the date and time will be logged. print-time may + be specified for a syslog channel, + but 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 + on, then the severity level of the message will be logged. The print- options may + be used in any combination, and will always be printed in the + following + order: time, category, severity. Here is an example where all + three print- options + are on: + + + + 28-Feb-2000 15:05:32.863 general: notice: running + + + + There are four predefined channels that are used for + named's default logging as follows. + How they are + used is described in . + channel default_syslog { // send to syslog's daemon facility @@ -3991,55 +3991,55 @@ channel null { }; - - The default_debug channel has the - special - property that it only produces output when the server's debug - level is - nonzero. It normally writes to a file called named.run - in the server's working directory. - - - - For security reasons, when the "" - command line option is used, the named.run file - is created only after named has - changed to the - new UID, and any debug output generated while named is - starting up and still running as root is discarded. If you need - to capture this output, you must run the server with the "" - option and redirect standard error 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. - - - - - The <command>category</command> Phrase - - - 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 - messages - in that category will be sent to the default category - instead. If you don't specify a default category, the following - "default default" is used: - + + The default_debug channel has the + special + property that it only produces output when the server's debug + level is + nonzero. It normally writes to a file called named.run + in the server's working directory. + + + + For security reasons, when the "" + command line option is used, the named.run file + is created only after named has + changed to the + new UID, and any debug output generated while named is + starting up and still running as root is discarded. If you need + to capture this output, you must run the server with the "" + option and redirect standard error 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. + + + + + The <command>category</command> Phrase + + + 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 + messages + in that category will be sent to the default category + instead. If you don't specify a default category, the following + "default default" is used: + category default { default_syslog; 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: - + + 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"; @@ -4051,371 +4051,371 @@ category security { default_debug; }; - - To discard all messages in a category, specify the null channel: - + + 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. - - - - - - - - - default - - - - The default category defines the logging - options for those categories where no specific - configuration has been - defined. - - - - - - general - - - - The catch-all. Many things still aren't - classified into categories, and they all end up here. - - - - - - database - - - - Messages relating to the databases used - internally by the name server to store zone and cache - data. - - - - - - security - - - - Approval and denial of requests. - - - - - - config - - - - Configuration file parsing and processing. - - - - - - resolver - - - - DNS resolution, such as the recursive - lookups performed on behalf of clients by a caching name - server. - - - - - - xfer-in - - - - Zone transfers the server is receiving. - - - - - - xfer-out - - - - Zone transfers the server is sending. - - - - - - notify - - - - The NOTIFY protocol. - - - - - - client - - - - Processing of client requests. - - - - - - unmatched - - - - Messages that named was unable to determine the - class of or for which there was no matching view. - A one line summary is also logged to the client category. - This category is best sent to a file or stderr, by - default it is sent to - the null channel. - - - - - - network - - - - Network operations. - - - - - - update - - - - Dynamic updates. - - - - - - update-security - - - - Approval and denial of update requests. - - - - - - queries - - - - Specify where queries should be logged to. - - - At startup, specifying the category queries will also - enable query logging unless querylog option has been - specified. - - + + 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. + + + + + + + + + default + + - The query log entry reports the client's IP - address and port number, and the query name, - class and type. Next it reports whether the - Recursion Desired flag was set (+ if set, - - if not set), if the query was signed (S), - EDNS was in use (E), if TCP was used (T), if - DO (DNSSEC Ok) was set (D), or if CD (Checking - Disabled) was set (C). After this the - destination address the query was sent to is - reported. + The default category defines the logging + options for those categories where no specific + configuration has been + defined. - - - client 127.0.0.1#62536 (www.example.com): query: www.example.com IN AAAA +SE - - - client ::1#62537 (www.example.net): query: www.example.net IN AAAA -SE - + + + + + general + + - (The first part of this log message, showing the - client address/port number and query name, is - repeated in all subsequent log messages related - to the same query.) + The catch-all. Many things still aren't + classified into categories, and they all end up here. - - - - - query-errors - - - - Information about queries that resulted in some - failure. + + + + + database + + + + Messages relating to the databases used + internally by the name server to store zone and cache + data. - - - dispatch - - - - Dispatching of incoming packets to the - server modules where they are to be processed. - - - - - - dnssec - - - - DNSSEC and TSIG protocol processing. - - - - - - lame-servers - - - - Lame servers. These are misconfigurations - in remote servers, discovered by BIND 9 when trying to - query those servers during resolution. - - - - - - delegation-only - + + + security + - Delegation only. Logs queries that have been - forced to NXDOMAIN as the result of a - delegation-only zone or a - delegation-only in a hint - or stub zone declaration. + Approval and denial of requests. - - - edns-disabled - + + + config + - Log queries that have been forced to use plain - DNS due to timeouts. This is often due to - the remote servers not being RFC 1034 compliant - (not always returning FORMERR or similar to - EDNS queries and other extensions to the DNS - when they are not understood). In other words, this is - targeted at servers that fail to respond to - DNS queries that they don't understand. + Configuration file parsing and processing. + + + + + resolver + + - Note: the log message can also be due to - packet loss. Before reporting servers for - non-RFC 1034 compliance they should be re-tested - to determine the nature of the non-compliance. - This testing should prevent or reduce the - number of false-positive reports. + DNS resolution, such as the recursive + lookups performed on behalf of clients by a caching name + server. + + + + + xfer-in + + - Note: eventually named will have to stop - treating such timeouts as due to RFC 1034 non - compliance and start treating it as plain - packet loss. Falsely classifying packet - loss as due to RFC 1034 non compliance impacts - on DNSSEC validation which requires EDNS for - the DNSSEC records to be returned. + Zone transfers the server is receiving. - - - RPZ - + + + xfer-out + - Information about errors in response policy zone files, - rewritten responses, and at the highest - debug levels, mere rewriting - attempts. + Zone transfers the server is sending. - - - rate-limit - + + + notify + - The start, periodic, and final notices of the - rate limiting of a stream of responses are logged at - info severity in this category. - These messages include a hash value of the domain name - of the response and the name itself, - except when there is insufficient memory to record - the name for the final notice - The final notice is normally delayed until about one - minute after rate limit stops. - A lack of memory can hurry the final notice, - in which case it starts with an asterisk (*). - Various internal events are logged at debug 1 level - and higher. + The NOTIFY protocol. + + + + + client + + - Rate limiting of individual requests - is logged in the query-errors category. + Processing of client requests. - - - - - - The <command>query-errors</command> Category - - The query-errors category is - specifically intended for debugging purposes: To identify - why and how specific queries result in responses which - indicate an error. - Messages of this category are therefore only logged - with debug levels. - - - - At the debug levels of 1 or higher, each response with the - rcode of SERVFAIL is logged as follows: - - - client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880 - + + + unmatched + + + + Messages that named was unable to determine the + class of or for which there was no matching view. + A one line summary is also logged to the client category. + This category is best sent to a file or stderr, by + default it is sent to + the null channel. + + + + + + network + + + + Network operations. + + + + + + update + + + + Dynamic updates. + + + + + + update-security + + + + Approval and denial of update requests. + + + + + + queries + + + + Specify where queries should be logged to. + + + At startup, specifying the category queries will also + enable query logging unless querylog option has been + specified. + + + + The query log entry reports the client's IP + address and port number, and the query name, + class and type. Next it reports whether the + Recursion Desired flag was set (+ if set, - + if not set), if the query was signed (S), + EDNS was in use (E), if TCP was used (T), if + DO (DNSSEC Ok) was set (D), or if CD (Checking + Disabled) was set (C). After this the + destination address the query was sent to is + reported. + + + + client 127.0.0.1#62536 (www.example.com): query: www.example.com IN AAAA +SE + + + client ::1#62537 (www.example.net): query: www.example.net IN AAAA -SE + + + (The first part of this log message, showing the + client address/port number and query name, is + repeated in all subsequent log messages related + to the same query.) + + + + + + query-errors + + + + Information about queries that resulted in some + failure. + + + + + + dispatch + + + + Dispatching of incoming packets to the + server modules where they are to be processed. + + + + + + dnssec + + + + DNSSEC and TSIG protocol processing. + + + + + + lame-servers + + + + Lame servers. These are misconfigurations + in remote servers, discovered by BIND 9 when trying to + query those servers during resolution. + + + + + + delegation-only + + + + Delegation only. Logs queries that have been + forced to NXDOMAIN as the result of a + delegation-only zone or a + delegation-only in a hint + or stub zone declaration. + + + + + + edns-disabled + + + + Log queries that have been forced to use plain + DNS due to timeouts. This is often due to + the remote servers not being RFC 1034 compliant + (not always returning FORMERR or similar to + EDNS queries and other extensions to the DNS + when they are not understood). In other words, this is + targeted at servers that fail to respond to + DNS queries that they don't understand. + + + Note: the log message can also be due to + packet loss. Before reporting servers for + non-RFC 1034 compliance they should be re-tested + to determine the nature of the non-compliance. + This testing should prevent or reduce the + number of false-positive reports. + + + Note: eventually named will have to stop + treating such timeouts as due to RFC 1034 non + compliance and start treating it as plain + packet loss. Falsely classifying packet + loss as due to RFC 1034 non compliance impacts + on DNSSEC validation which requires EDNS for + the DNSSEC records to be returned. + + + + + + RPZ + + + + Information about errors in response policy zone files, + rewritten responses, and at the highest + debug levels, mere rewriting + attempts. + + + + + + rate-limit + + + + The start, periodic, and final notices of the + rate limiting of a stream of responses are logged at + info severity in this category. + These messages include a hash value of the domain name + of the response and the name itself, + except when there is insufficient memory to record + the name for the final notice + The final notice is normally delayed until about one + minute after rate limit stops. + A lack of memory can hurry the final notice, + in which case it starts with an asterisk (*). + Various internal events are logged at debug 1 level + and higher. + + + Rate limiting of individual requests + is logged in the query-errors category. + + + + + + + + + The <command>query-errors</command> Category + + The query-errors category is + specifically intended for debugging purposes: To identify + why and how specific queries result in responses which + indicate an error. + Messages of this category are therefore only logged + with debug levels. + + + + At the debug levels of 1 or higher, each response with the + rcode of SERVFAIL is 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 @@ -4432,12 +4432,12 @@ category notify { null; }; - + fetch completed at resolver.c:2970 for www.example.com/A in 30.000183: timed out/success [domain:example.com, referral:2,restart:7,qrysent:8,timeout:5,lame:0,neterr:0, badresp:1,adberr:0,findfail:0,valfail:0] - + The first part before the colon shows that a recursive @@ -4467,30 +4467,30 @@ badresp:1,adberr:0,findfail:0,valfail:0] following table. - - - - - - - - referral - - - + + + + + + + + referral + + + The number of referrals the resolver received throughout the resolution process. In the above example this is 2, which are most likely com and example.com. - - - - - - restart - - - + + + + + + restart + + + The number of cycles that the resolver tried remote servers at the domain zone. @@ -4498,37 +4498,37 @@ badresp:1,adberr:0,findfail:0,valfail:0] (possibly resending it, depending on the response) to each known name server of the domain zone. - - - - - - qrysent - - - + + + + + + qrysent + + + The number of queries the resolver sent at the domain zone. - - - - - - timeout - - - + + + + + + timeout + + + The number of timeouts since the resolver received the last response. - - - lame - - - + + + lame + + + The number of lame servers the resolver detected at the domain zone. A server is detected to be lame either by an @@ -4538,12 +4538,12 @@ badresp:1,adberr:0,findfail:0,valfail:0] - - - neterr - - - + + + neterr + + + The number of erroneous results that the resolver encountered in sending queries at the domain zone. @@ -4553,24 +4553,24 @@ badresp:1,adberr:0,findfail:0,valfail:0] - - - badresp - - - + + + badresp + + + The number of unexpected responses (other than lame) to queries sent by the resolver at the domain zone. - - - adberr - - - + + + adberr + + + Failures in finding remote server addresses of the domain zone in the ADB. One common case of this is that the remote @@ -4578,24 +4578,24 @@ badresp:1,adberr:0,findfail:0,valfail:0] - - - findfail - - - + + + findfail + + + Failures of resolving remote server addresses. This is a total number of failures throughout the resolution process. - - - valfail - - - + + + valfail + + + Failures of DNSSEC validation. Validation failures are counted throughout the resolution process (not limited to @@ -4627,12 +4627,12 @@ badresp:1,adberr:0,findfail:0,valfail:0] - <command>lwres</command> Statement Grammar + <command>lwres</command> Statement Grammar - - This is the grammar of the lwres - statement in the named.conf file: - + + This is the grammar of the lwres + statement in the named.conf file: + lwres { listen-on { ip_addr port ip_port dscp ip_dscp ; @@ -4645,62 +4645,62 @@ badresp:1,adberr:0,findfail:0,valfail:0] - <command>lwres</command> Statement Definition and Usage - - - The lwres statement configures the - name - server to also act as a lightweight resolver server. (See - .) There may be multiple - lwres statements configuring - lightweight resolver servers with different properties. - - - - The listen-on statement specifies a - list of - addresses (and ports) that this instance of a lightweight resolver - daemon - should accept requests on. If no port is specified, port 921 is - used. - If this statement is omitted, requests will be accepted on - 127.0.0.1, - port 921. - - - - The view statement binds this - instance of a - lightweight resolver daemon to a view in the DNS namespace, so that - the - response will be constructed in the same manner as a normal DNS - query - matching this view. If this statement is omitted, the default view - is - used, and if there is no default view, an error is triggered. - - - - The search statement is equivalent to - the - search statement in - /etc/resolv.conf. It provides a - list of domains - which are appended to relative names in queries. - - - - The ndots statement is equivalent to - the - ndots statement in - /etc/resolv.conf. It indicates the - minimum - number of dots in a relative domain name that should result in an - exact match lookup before search path elements are appended. - + <command>lwres</command> Statement Definition and Usage + + + The lwres statement configures the + name + server to also act as a lightweight resolver server. (See + .) There may be multiple + lwres statements configuring + lightweight resolver servers with different properties. + + + + The listen-on statement specifies a + list of + addresses (and ports) that this instance of a lightweight resolver + daemon + should accept requests on. If no port is specified, port 921 is + used. + If this statement is omitted, requests will be accepted on + 127.0.0.1, + port 921. + + + + The view statement binds this + instance of a + lightweight resolver daemon to a view in the DNS namespace, so that + the + response will be constructed in the same manner as a normal DNS + query + matching this view. If this statement is omitted, the default view + is + used, and if there is no default view, an error is triggered. + + + + The search statement is equivalent to + the + search statement in + /etc/resolv.conf. It provides a + list of domains + which are appended to relative names in queries. + + + + The ndots statement is equivalent to + the + ndots statement in + /etc/resolv.conf. It indicates the + minimum + number of dots in a relative domain name that should result in an + exact match lookup before search path elements are appended. + - <command>masters</command> Statement Grammar + <command>masters</command> Statement Grammar masters name port ip_port dscp ip_dscp { ( masters_list | @@ -4710,22 +4710,22 @@ badresp:1,adberr:0,findfail:0,valfail:0] - <command>masters</command> Statement Definition and - Usage - masters + <command>masters</command> Statement Definition and + Usage + 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. - + multiple stub and slave zones in their masters + or also-notify lists. + - <command>options</command> Statement Grammar + <command>options</command> Statement Grammar - - This is the grammar of the options - statement in the named.conf file: - + + This is the grammar of the options + statement in the named.conf file: + options { attach-cache cache_name; @@ -4775,17 +4775,17 @@ badresp:1,adberr:0,findfail:0,valfail:0] dnssec-validation (yes_or_no | auto); dnssec-lookaside ( auto | no | - domain trust-anchor domain ); + domain trust-anchor domain ); dnssec-must-be-secure domain yes_or_no; dnssec-accept-expired yes_or_no; forward ( only | first ); forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; dual-stack-servers port ip_port dscp ip_dscp { - ( domain_name port ip_port dscp ip_dscp | - ip_addr port ip_port dscp ip_dscp) ; - ... }; + ( domain_name port ip_port dscp ip_dscp | + ip_addr port ip_port dscp ip_dscp) ; + ... }; check-names ( master | slave | response ) - ( warn | fail | ignore ); + ( warn | fail | ignore ); check-dup-records ( warn | fail | ignore ); check-mx ( warn | fail | ignore ); check-wildcard yes_or_no; @@ -4821,17 +4821,17 @@ badresp:1,adberr:0,findfail:0,valfail:0] listen-on-v6 port ip_port dscp ip_dscp { address_match_list }; query-source ( ( ip4_addr | * ) - port ( ip_port | * ) - dscp ip_dscp | - address ( ip4_addr | * ) - port ( ip_port | * ) ) - dscp ip_dscp ; + port ( ip_port | * ) + dscp ip_dscp | + address ( ip4_addr | * ) + port ( ip_port | * ) ) + dscp ip_dscp ; query-source-v6 ( ( ip6_addr | * ) - port ( ip_port | * ) - dscp ip_dscp | - address ( ip6_addr | * ) - port ( ip_port | * ) ) - dscp ip_dscp ; + port ( ip_port | * ) + dscp ip_dscp | + address ( ip6_addr | * ) + port ( ip_port | * ) ) + dscp ip_dscp ; use-queryport-pool yes_or_no; queryport-pool-ports number; queryport-pool-updateinterval number; @@ -4859,8 +4859,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] notify-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; notify-to-soa yes_or_no ; also-notify { ip_addr - port ip_port dscp ip_dscp key keyname ; - ip_addr port ip_port dscp ip_dscp key keyname ; ... }; + port ip_port dscp ip_dscp key keyname ; + ip_addr port ip_port dscp ip_dscp key keyname ; ... }; max-ixfr-log-size number; max-journal-size size_spec; coresize size_spec ; @@ -4903,7 +4903,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] dns64 ipv6-prefix { clients { address_match_list }; mapped { address_match_list }; - exclude { address_match_list }; + exclude { address_match_list }; suffix IPv6-address; recursive-only yes_or_no; break-dnssec yes_or_no; @@ -4917,16 +4917,16 @@ badresp:1,adberr:0,findfail:0,valfail:0] root-delegation-only exclude { namelist } ; querylog yes_or_no ; disable-algorithms domain { algorithm; - algorithm; }; + algorithm; }; disable-ds-digests domain { digest_type; - digest_type; }; + digest_type; }; acache-enable yes_or_no ; acache-cleaning-interval number; max-acache-size size_spec ; clients-per-query number ; max-clients-per-query number ; masterfile-format - (text|raw|map) ; + (text|raw|map) ; empty-server name ; empty-contact name ; empty-zones-enable yes_or_no ; @@ -4965,25 +4965,25 @@ badresp:1,adberr:0,findfail:0,valfail:0] - <command>options</command> Statement Definition and - Usage - - - The options statement sets up global - options - to be used by BIND. This statement - may appear only - once in a configuration file. If there is no options - statement, an options block with each option set to its default will - be used. - - - - - - attach-cache - - + <command>options</command> Statement Definition and + Usage + + + The options statement sets up global + options + to be used by BIND. This statement + may appear only + once in a configuration file. If there is no options + statement, an options block with each option set to its default will + be used. + + + + + + attach-cache + + Allows multiple views to share a single cache database. Each view has its own cache database by default, but @@ -4991,14 +4991,14 @@ badresp:1,adberr:0,findfail:0,valfail:0] for name resolution and caching, those views can 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 attach-cache option + may also be specified in view + statements, in which case it overrides the + global attach-cache option. + The cache_name specifies @@ -5072,85 +5072,85 @@ badresp:1,adberr:0,findfail:0,valfail:0] configuration differences in different views do not cause disruption with a shared cache. - - - - - - directory - - - The working directory of the server. - Any non-absolute pathnames in the configuration file will be - taken - as relative to this directory. The default location for most - server - output files (e.g. named.run) - is this directory. - If a directory is not specified, the working directory - defaults to `.', the directory from - which the server - was started. The directory specified should be an absolute - path. - - - - - - key-directory - - - 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 - directory. (Note that this option has no effect on the - paths for files containing non-DNSSEC keys such as - bind.keys, - rndc.key or - session.key.) - - - - - - managed-keys-directory - - - Specifies the directory in which to store the files that - track managed DNSSEC keys. By default, this is the working - directory. - - - 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. - Otherwise, managed keys will be tracked in separate files, - one file per view; each file name will be the SHA256 hash - of the view name, followed by the extension - .mkeys. - - - - - - named-xfer + + + + + + directory - This option is obsolete. It - was used in BIND 8 to specify - the pathname to the named-xfer - program. In BIND 9, no separate - named-xfer program is needed; - its functionality is built into the name server. + The working directory of the server. + Any non-absolute pathnames in the configuration file will be + taken + as relative to this directory. The default location for most + server + output files (e.g. named.run) + is this directory. + If a directory is not specified, the working directory + defaults to `.', the directory from + which the server + was started. The directory specified should be an absolute + path. - tkey-gssapi-keytab + key-directory - The KRB5 keytab file to use for GSS-TSIG updates. If + 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 + directory. (Note that this option has no effect on the + paths for files containing non-DNSSEC keys such as + bind.keys, + rndc.key or + session.key.) + + + + + + managed-keys-directory + + + Specifies the directory in which to store the files that + track managed DNSSEC keys. By default, this is the working + directory. + + + 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. + Otherwise, managed keys will be tracked in separate files, + one file per view; each file name will be the SHA256 hash + of the view name, followed by the extension + .mkeys. + + + + + + named-xfer + + + This option is obsolete. It + was used in BIND 8 to specify + the pathname to the named-xfer + program. In BIND 9, no separate + named-xfer program is needed; + its functionality is built into the name server. + + + + + + tkey-gssapi-keytab + + + 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. @@ -5178,8 +5178,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] - - tkey-domain + + tkey-domain The domain appended to the names of all shared keys @@ -5201,224 +5201,224 @@ badresp:1,adberr:0,findfail:0,valfail:0] - - tkey-dhkey - - - The Diffie-Hellman key used by the server - to generate shared keys with clients using the Diffie-Hellman - mode - of TKEY. The server must be - able to load the - public and private keys from files in the working directory. - In - most cases, the keyname should be the server's host name. - - - - - - cache-file - - + + tkey-dhkey + + + The Diffie-Hellman key used by the server + to generate shared keys with clients using the Diffie-Hellman + mode + of TKEY. The server must be + able to load the + public and private keys from files in the working directory. + In + most cases, the keyname should be the server's host name. + + + + + + cache-file + + This is for testing only. Do not use. - - - - - - dump-file - - - 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. - - - - - - memstatistics-file - - - The pathname of the file the server writes memory - usage statistics to on exit. If not specified, - the default is named.memstats. - - - - - - pid-file - - - The pathname of the file the server writes its process ID - in. If not specified, the default is + + + + + + dump-file + + + 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. + + + + + + memstatistics-file + + + The pathname of the file the server writes memory + usage statistics to on exit. If not specified, + the default is named.memstats. + + + + + + pid-file + + + The pathname of the file the server writes its process ID + in. If not specified, the default is /var/run/named/named.pid. - The PID file is used by programs that want to send signals to - the running - name server. Specifying pid-file none disables the - use of a PID file — no file will be written and any - existing one will be removed. Note that none - is a keyword, not a filename, and therefore is not enclosed - in - double quotes. - - - - - - recursing-file - - - 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. - - - - - - statistics-file - - - 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 . - - - - - - bindkeys-file - - - The pathname of a file to override the built-in trusted + The PID file is used by programs that want to send signals to + the running + name server. Specifying pid-file none disables the + use of a PID file — no file will be written and any + existing one will be removed. Note that none + is a keyword, not a filename, and therefore is not enclosed + in + double quotes. + + + + + + recursing-file + + + 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. + + + + + + statistics-file + + + 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 . + + + + + + bindkeys-file + + + The pathname of a file to override the built-in trusted keys provided by named. See the discussion of dnssec-lookaside - and dnssec-validation for details. - If not specified, the default is + and dnssec-validation for details. + If not specified, the default is /etc/bind.keys. - - - - - - secroots-file - - - 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 + + + + + + secroots-file + + + 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. - - - - - - session-keyfile - - - 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 - default is /var/run/named/session.key. - (See , and in - particular the discussion of the - update-policy statement's - local option for more - information about this feature.) - - - - - - session-keyname - - - The key name to use for the TSIG session key. - If not specified, the default is "local-ddns". - - - - - - session-keyalg - - - 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. - - - - - - port - - - The UDP/TCP port number the server uses for - receiving and sending DNS protocol traffic. - The default is 53. This option is mainly intended for server - testing; - a server using a port other than 53 will not be able to - communicate with - the global DNS. - - - - - - random-device - - - The source of entropy to be used by the server. Entropy is - primarily needed - for DNSSEC operations, such as TKEY transactions and dynamic - update of signed - zones. This options specifies the device (or file) from which - to read - entropy. If this is a file, operations requiring entropy will - fail when the - file has been exhausted. If not specified, the default value - is - /dev/random - (or equivalent) when present, and none otherwise. The - random-device option takes - effect during - the initial configuration load at server startup time and - is ignored on subsequent reloads. - - - - - - preferred-glue - - - 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 not to prefer any type (NONE). - - - - - - root-delegation-only - - - Turn on enforcement of delegation-only in TLDs + + + + + + session-keyfile + + + 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 + default is /var/run/named/session.key. + (See , and in + particular the discussion of the + update-policy statement's + local option for more + information about this feature.) + + + + + + session-keyname + + + The key name to use for the TSIG session key. + If not specified, the default is "local-ddns". + + + + + + session-keyalg + + + 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. + + + + + + port + + + The UDP/TCP port number the server uses for + receiving and sending DNS protocol traffic. + The default is 53. This option is mainly intended for server + testing; + a server using a port other than 53 will not be able to + communicate with + the global DNS. + + + + + + random-device + + + The source of entropy to be used by the server. Entropy is + primarily needed + for DNSSEC operations, such as TKEY transactions and dynamic + update of signed + zones. This options specifies the device (or file) from which + to read + entropy. If this is a file, operations requiring entropy will + fail when the + file has been exhausted. If not specified, the default value + is + /dev/random + (or equivalent) when present, and none otherwise. The + random-device option takes + effect during + the initial configuration load at server startup time and + is ignored on subsequent reloads. + + + + + + preferred-glue + + + 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 not to prefer any type (NONE). + + + + + + root-delegation-only + + + 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 @@ -5447,10 +5447,10 @@ badresp:1,adberr:0,findfail:0,valfail:0] (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", + + Note some TLDs are not delegation only (e.g. "DE", "LV", "US" and "MUSEUM"). This list is not exhaustive. - + options { @@ -5458,51 +5458,51 @@ options { }; - - - - - disable-algorithms - - - Disable the specified DNSSEC algorithms at and below the - specified name. - Multiple disable-algorithms - statements are allowed. - Only the best match disable-algorithms + + + + + disable-algorithms + + + Disable the specified DNSSEC algorithms at and below the + specified name. + Multiple disable-algorithms + statements are allowed. + 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. - - - - - - disable-ds-digests - - - Disable the specified DS/DLV digest types at and below the - specified name. - Multiple disable-ds-digests - statements are allowed. - Only the best match disable-ds-digests + + + + + + disable-ds-digests + + + Disable the specified DS/DLV digest types at and below the + specified name. + Multiple disable-ds-digests + statements are allowed. + 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. - - + + - - dnssec-lookaside - - + + dnssec-lookaside + + When set, dnssec-lookaside provides the validator with an alternate method to validate DNSKEY records at the top of a zone. When a DNSKEY is at or @@ -5512,7 +5512,7 @@ options { will be appended to the key name and a DLV record will be looked up to see if it can validate the key. If the DLV record validates a DNSKEY (similarly to the way a DS - record does) the DNSKEY RRset is deemed to be trusted. + record does) the DNSKEY RRset is deemed to be trusted. If dnssec-lookaside is set to @@ -5525,54 +5525,54 @@ options { no, then dnssec-lookaside is not used. - - The default DLV key is stored in the file - bind.keys; - named will load that key at - startup if dnssec-lookaside is set to - auto. A copy of the file is - installed along with BIND 9, and is - current as of the release date. If the DLV key expires, a - new copy of bind.keys can be downloaded - from + The default DLV key is stored in the file + bind.keys; + named will load that key at + startup if dnssec-lookaside is set to + auto. A copy of the file is + installed along with BIND 9, and is + current as of the release date. If the DLV key expires, a + new copy of bind.keys can be downloaded + from https://www.isc.org/solutions/dlv/. - - - (To prevent problems if bind.keys is - not found, the current key 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 DLV key expires.) - - - NOTE: named only loads certain specific - keys from bind.keys: those for the - DLV zone and for the DNS root zone. The file cannot be - used to store keys for other zones. - - - - - - dnssec-must-be-secure - - - Specify hierarchies which must be or may not be secure - (signed and validated). If yes, - then named will only accept answers if - they are secure. If no, then normal - DNSSEC validation applies allowing for insecure answers to - be accepted. The specified domain must be under a - trusted-keys or - managed-keys statement, or - dnssec-lookaside must be active. - - - + + + (To prevent problems if bind.keys is + not found, the current key 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 DLV key expires.) + + + NOTE: named only loads certain specific + keys from bind.keys: those for the + DLV zone and for the DNS root zone. The file cannot be + used to store keys for other zones. + + + + + + dnssec-must-be-secure + + + Specify hierarchies which must be or may not be secure + (signed and validated). If yes, + then named will only accept answers if + they are secure. If no, then normal + DNSSEC validation applies allowing for insecure answers to + be accepted. The specified domain must be under a + trusted-keys or + managed-keys statement, or + dnssec-lookaside must be active. + + + dns64 - + This directive instructs named to return mapped IPv4 addresses to AAAA queries when @@ -5598,8 +5598,8 @@ options { Each dns64 supports an optional clients ACL that determines which - clients are affected by this directive. If not defined, - it defaults to any;. + clients are affected by this directive. If not defined, + it defaults to any;. Each dns64 supports an optional @@ -5645,8855 +5645,8890 @@ options { acl rfc1918 { 10/8; 192.168/16; 172.16/12; }; - dns64 64:FF9B::/96 { - clients { any; }; - mapped { !rfc1918; any; }; - exclude { 64:FF9B::/96; ::ffff:0000:0000/96; }; - suffix ::; - }; + dns64 64:FF9B::/96 { + clients { any; }; + mapped { !rfc1918; any; }; + exclude { 64:FF9B::/96; ::ffff:0000:0000/96; }; + suffix ::; + }; - + dnssec-update-mode - - If this option is set to its default value of - maintain in a zone of type - master which is DNSSEC-signed - and configured to allow dynamic updates (see - ), and - if named has access to the - private signing key(s) for the zone, then - named will automatically sign all new - or changed records and maintain signatures for the zone - 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 - named. (A planned third option, - external, will disable all automatic - signing and allow DNSSEC data to be submitted into a zone - via dynamic update; this is not yet implemented.) + + If this option is set to its default value of + maintain in a zone of type + master which is DNSSEC-signed + and configured to allow dynamic updates (see + ), and + if named has access to the + private signing key(s) for the zone, then + named will automatically sign all new + or changed records and maintain signatures for the zone + 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 + named. (A planned third option, + external, will disable all automatic + signing and allow DNSSEC data to be submitted into a zone + via dynamic update; this is not yet implemented.) - - zone-statistics - - - If full, the server will collect - statistical data on all zones (unless specifically - turned off on a per-zone basis by specifying - zone-statistics terse or - zone-statistics none - in the zone statement). - The default is terse, providing - minimal statistics on zones (including name and - current serial number, but not query type - counters). - - - These statistics may be accessed via the - statistics-channel or - using rndc stats, which - will dump them to the file listed - in the statistics-file. See - also . - - - For backward compatibility with earlier versions - of BIND 9, the zone-statistics - option can also accept yes - or no; yes - has the same meaning as full. - As of BIND 9.10, - no has the same meaning - as none; previously, it - was the same as terse. - - - - - - - Boolean Options - - - - - allow-new-zones - - - If yes, then zones can be - added at runtime via rndc addzone - or deleted via rndc delzone. - The default is no. - - - - - - auth-nxdomain - - - If yes, then the AA bit - is always set on NXDOMAIN responses, even if the server is - not actually - authoritative. The default is no; - this is - a change from BIND 8. If you - are using very old DNS software, you - may need to set it to yes. - - - - - - deallocate-on-exit - - - 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. - - - - - - memstatistics - - - 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. - - - - - - dialup - - - If yes, then the - server treats all zones as if they are doing zone transfers - across - a dial-on-demand dialup link, which can be brought up by - traffic - originating from this server. This has different effects - according - to zone type and concentrates the zone maintenance so that - it all - happens in a short interval, once every heartbeat-interval and - hopefully during the one call. It also suppresses some of - the normal - zone maintenance traffic. The default is no. - - - The dialup option - may also be specified in the view and - zone statements, - in which case it overrides the global dialup - option. - - - If the zone is a master zone, then the server will send out a - NOTIFY - request to all the slaves (default). This should trigger the - zone serial - number check in the slave (providing it supports NOTIFY) - allowing the slave - to verify the zone while the connection is active. - The set of servers to which NOTIFY is sent can be controlled - by - notify and also-notify. - - - If the - zone is a slave or stub zone, then the server will suppress - the regular - "zone up to date" (refresh) queries and only perform them - when the - heartbeat-interval expires in - addition to sending - NOTIFY requests. - - - Finer control can be achieved by using - notify which only sends NOTIFY - messages, - notify-passive which sends NOTIFY - messages and - suppresses the normal refresh queries, refresh - which suppresses normal refresh processing and sends refresh - queries - when the heartbeat-interval - expires, and - passive which just disables normal - refresh - processing. - - - - - - - - - - - - - dialup mode - - - - - normal refresh - - - - - heart-beat refresh - - - - - heart-beat notify - - - - - - no (default) - - - - yes - - - - - no - - - - - no - - - - - - yes - - - - no - - - - - yes - - - - - yes - - - - - - notify - - - - yes - - - - - no - - - - - yes - - - - - - refresh - - - - no - - - - - yes - - - - - no - - - - - - passive - - - - no - - - - - no - - - - - no - - - - - - notify-passive - - - - no - - - - - no - - - - - yes - - - - - - - - - Note that normal NOTIFY processing is not affected by - dialup. - - - - - - - fake-iquery - - - In BIND 8, this option - enabled simulating the obsolete DNS query type - IQUERY. BIND 9 never does - IQUERY simulation. - - - - - - fetch-glue - - - This option is obsolete. - In BIND 8, fetch-glue yes - caused the server to attempt to fetch glue resource records - it - didn't have when constructing the additional - data section of a response. This is now considered a bad - idea - and BIND 9 never does it. - - - - - - flush-zones-on-shutdown - - - When the nameserver exits due receiving SIGTERM, - flush or do not flush any pending zone writes. The default - is - flush-zones-on-shutdown no. - - - - - - has-old-clients - - - This option was incorrectly implemented - in BIND 8, and is ignored by BIND 9. - To achieve the intended effect - of - has-old-clients yes, specify - the two separate options auth-nxdomain yes - and rfc2308-type1 no instead. - - - - - - host-statistics - - - In BIND 8, this enables keeping of - statistics for every host that the name server interacts - with. - Not implemented in BIND 9. - - - - - - maintain-ixfr-base - - - This option is obsolete. - It was used in BIND 8 to - determine whether a transaction log was - kept for Incremental Zone Transfer. BIND 9 maintains a transaction - log whenever possible. If you need to disable outgoing - incremental zone - transfers, use provide-ixfr no. - - - - - - minimal-responses - - - If yes, then when generating - responses the server will only add records to the authority - and additional data sections when they are required (e.g. - delegations, negative responses). This may improve the - performance of the server. - The default is no. - - - - - - multiple-cnames - - - This option was used in BIND 8 to allow - a domain name to have multiple CNAME records in violation of - the DNS standards. BIND 9.2 onwards - always strictly enforces the CNAME rules both in master - files and dynamic updates. - - - - - - notify - - - If yes (the default), - DNS NOTIFY messages are sent when a zone the server is - authoritative for - changes, see . The messages are - sent to the - servers listed in the zone's NS records (except the master - server identified - in the SOA MNAME field), and to any servers listed in the - also-notify option. - - - If master-only, notifies are only - sent - for master zones. - If explicit, notifies are sent only - to - servers explicitly listed using also-notify. - If no, no notifies are sent. - - - The notify option may also be - specified in the zone - statement, - in which case it overrides the options notify statement. - It would only be necessary to turn off this option if it - caused slaves - to crash. - - - - - - notify-to-soa - - - 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 - supposed to contain the name of the ultimate master. - Sometimes, however, a slave is listed as the SOA MNAME in - 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. - - - - - - recursion - - - If yes, and a - DNS query requests recursion, then the server will attempt - to do - all the work required to answer the query. If recursion is - off - and the server does not already know the answer, it will - return a - referral response. The default is - yes. - Note that setting recursion no does not prevent - clients from getting data from the server's cache; it only - prevents new data from being cached as an effect of client - queries. - Caching may still occur as an effect the server's internal - operation, such as NOTIFY address lookups. - See also fetch-glue above. - - - - - - request-nsid - - - If yes, then an empty EDNS(0) - NSID (Name Server Identifier) option is sent with all - queries to authoritative name servers during iterative - resolution. If the authoritative server returns an NSID - option in its response, then its contents are logged in - the resolver category at level - info. - The default is no. - - - - - - rfc2308-type1 - - - Setting this to yes will - cause the server to send NS records along with the SOA - record for negative - answers. The default is no. - - - - Not yet implemented in BIND - 9. - - - - - - - use-id-pool - - - This option is obsolete. - BIND 9 always allocates query - IDs from a pool. - - - - - - use-ixfr - - - This option is obsolete. - If you need to disable IXFR to a particular server or - servers, see - the information on the provide-ixfr option - in . - See also - . - - - - - - provide-ixfr - - - See the description of - provide-ixfr in - . - - - - - - request-ixfr - - - See the description of - request-ixfr in - . - - - - - - treat-cr-as-space - - - This option was used in BIND - 8 to make - the server treat carriage return ("\r") characters the same way - as a space or tab character, - to facilitate loading of zone files on a UNIX system that - were generated - on an NT or DOS machine. In BIND 9, both UNIX "\n" - and NT/DOS "\r\n" newlines - are always accepted, - and the option is ignored. - - - - - - additional-from-auth - additional-from-cache - - - - These options control the behavior of an authoritative - server when - answering queries which have additional data, or when - following CNAME - and DNAME chains. - - - - When both of these options are set to yes - (the default) and a - query is being answered from authoritative data (a zone - configured into the server), the additional data section of - the - reply will be filled in using data from other authoritative - zones - and from the cache. In some situations this is undesirable, - such - as when there is concern over the correctness of the cache, - or - in servers where slave zones may be added and modified by - untrusted third parties. Also, avoiding - the search for this additional data will speed up server - operations - at the possible expense of additional queries to resolve - what would - otherwise be provided in the additional section. - - - - For example, if a query asks for an MX record for host foo.example.com, - and the record found is "MX 10 mail.example.net", normally the address - records (A and AAAA) for mail.example.net will be provided as well, - if known, even though they are not in the example.com zone. - Setting these options to no - disables this behavior and makes - the server only search for additional data in the zone it - answers from. - - - - These options are intended for use in authoritative-only - servers, or in authoritative-only views. Attempts to set - them to no without also - specifying - recursion no will cause the - server to - ignore the options and log a warning message. - - - - Specifying additional-from-cache no actually - disables the use of the cache not only for additional data - lookups - but also when looking up the answer. This is usually the - desired - behavior in an authoritative-only server where the - correctness of - the cached data is an issue. - - - - When a name server is non-recursively queried for a name - that is not - below the apex of any served zone, it normally answers with - an - "upwards referral" to the root servers or the servers of - some other - known parent of the query name. Since the data in an - upwards referral - comes from the cache, the server will not be able to provide - upwards - referrals when additional-from-cache no - has been specified. Instead, it will respond to such - queries - with REFUSED. This should not cause any problems since - upwards referrals are not required for the resolution - process. - - - - - - - match-mapped-addresses - - - 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 - IPv6 socket using mapped addresses. This caused address - match lists designed for IPv4 to fail to match. However, - named now solves this problem - internally. The use of this option is discouraged. - - - - - - filter-aaaa-on-v4 - - - This option is only available when - BIND 9 is compiled with the - --enable-filter-aaaa option on the - "configure" command line. It is intended to help the - transition from IPv4 to IPv6 by not giving IPv6 addresses - to DNS clients unless they have connections to the IPv6 - Internet. This is not recommended unless absolutely - necessary. The default is no. - The filter-aaaa-on-v4 option - may also be specified in view statements - to override the global filter-aaaa-on-v4 - option. - - - If yes, - the DNS client is at an IPv4 address, in filter-aaaa, - and if the response does not include DNSSEC signatures, - then all AAAA records are deleted from the response. - This filtering applies to all responses and not only - authoritative responses. - - - If break-dnssec, - then AAAA records are deleted even when DNSSEC is enabled. - As suggested by the name, this makes the response not verify, - because the DNSSEC protocol is designed detect deletions. - - - This mechanism can erroneously cause other servers to - not give AAAA records to their clients. - A recursing server with both IPv6 and IPv4 network connections - that queries an authoritative server using this mechanism - via IPv4 will be denied AAAA records even if its client is - using IPv6. - - - This mechanism is applied to authoritative as well as - non-authoritative records. - A client using IPv4 that is not allowed recursion can - erroneously be given AAAA records because the server is not - allowed to check for A records. - - - Some AAAA records are given to IPv4 clients in glue records. - IPv4 clients that are servers can then erroneously - answer requests for AAAA records received via IPv4. - - - - - - filter-aaaa-on-v6 - - - Identical to filter-aaaa-on-v4, - except it filters AAAA responses to queries from IPv6 - clients instead of IPv4 clients. To filter all - responses, set both options to yes. - - - - - - ixfr-from-differences - - - When yes and the server loads a new - version of a master zone from its zone file or receives a - new version of a slave file via zone transfer, it will - compare the new version to the previous one and calculate - a set of differences. The differences are then logged in - the zone's journal file such that the changes can be - transmitted to downstream slaves as an incremental zone - transfer. - - - By allowing incremental zone transfers to be used for - non-dynamic zones, this option saves bandwidth at the - expense of increased CPU and memory consumption at the - master. - In particular, if the new version of a zone is completely - different from the previous one, the set of differences - will be of a size comparable to the combined size of the - old and new zone version, and the server will need to - temporarily allocate memory to hold this complete - difference set. - - ixfr-from-differences - also accepts master and - slave at the view and options - levels which causes - ixfr-from-differences to be enabled for - all master or - slave zones respectively. - It is off by default. - - - - - - multi-master - - - This should be set when you have multiple masters for a zone - and the - addresses refer to different machines. If yes, named will - not log - when the serial number on the master is less than what named - currently - has. The default is no. - - - - - - dnssec-enable - - - Enable DNSSEC support in named. Unless set to yes, - named behaves as if it does not support DNSSEC. - The default is yes. - - - - - - dnssec-validation - - - Enable DNSSEC validation in named. - Note dnssec-enable also needs to be - set to yes to be effective. - If set to no, DNSSEC validation - is disabled. 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 trusted-keys or - managed-keys statement. The default - is yes. - - - - - - dnssec-accept-expired - - - Accept expired signatures when verifying DNSSEC signatures. - The default is no. - Setting this option to yes - leaves named vulnerable to - replay attacks. - - - - - - querylog - - - Specify whether query logging should be started when named - starts. - If querylog is not specified, - then the query logging - is determined by the presence of the logging category queries. - - - - - - check-names - - - This option is used to restrict the character set and syntax - of - certain domain names in master files and/or DNS responses - received - from the network. The default varies according to usage - area. For - master zones the default is fail. - For slave zones the default - is warn. - For 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 - 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. - It also applies to the RDATA of PTR records where the owner - name indicated that it is a reverse lookup of a hostname - (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT). - - - + + zone-statistics + + + If full, the server will collect + statistical data on all zones (unless specifically + turned off on a per-zone basis by specifying + zone-statistics terse or + zone-statistics none + in the zone statement). + The default is terse, providing + minimal statistics on zones (including name and + current serial number, but not query type + counters). + + + These statistics may be accessed via the + statistics-channel or + using rndc stats, which + will dump them to the file listed + in the statistics-file. See + also . + + + For backward compatibility with earlier versions + of BIND 9, the zone-statistics + option can also accept yes + or no; yes + has the same meaning as full. + As of BIND 9.10, + no has the same meaning + as none; previously, it + was the same as terse. + + + + + + + Boolean Options + + - check-dup-records + allow-new-zones - 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. + If yes, then zones can be + added at runtime via rndc addzone + or deleted via rndc delzone. + The default is no. - check-mx + auth-nxdomain - Check whether the MX record appears to refer to a IP address. - The default is to warn. Other possible - values are fail and - ignore. + If yes, then the AA bit + is always set on NXDOMAIN responses, even if the server is + not actually + authoritative. The default is no; + this is + a change from BIND 8. If you + are using very old DNS software, you + may need to set it to yes. - - check-wildcard - - - 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 - to understand the wildcard matching algorithm (RFC 1034). - This option - affects master zones. The default (yes) is to check - for non-terminal wildcards and issue a warning. - - - + + deallocate-on-exit + + + 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. + + + - check-integrity + memstatistics - 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 - address records exist for delegated zones. For - MX and SRV records only in-zone hostnames are - checked (for out-of-zone hostnames use - named-checkzone). - For NS records only names below top of zone are - checked (for out-of-zone names and glue consistency - checks use named-checkzone). - The default is yes. + 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. + + + + + + dialup + + + If yes, then the + server treats all zones as if they are doing zone transfers + across + a dial-on-demand dialup link, which can be brought up by + traffic + originating from this server. This has different effects + according + to zone type and concentrates the zone maintenance so that + it all + happens in a short interval, once every heartbeat-interval and + hopefully during the one call. It also suppresses some of + the normal + zone maintenance traffic. The default is no. - Check that the two forms of Sender Policy Framework - records (TXT records starting with "v=spf1" and SPF) either - both exist or both don't exist. Warnings are - emitted it they don't and be suppressed with - check-spf. + 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 + zone serial + number check in the slave (providing it supports NOTIFY) + allowing the slave + to verify the zone while the connection is active. + The set of servers to which NOTIFY is sent can be controlled + by + notify and also-notify. + + + If the + zone is a slave or stub zone, then the server will suppress + the regular + "zone up to date" (refresh) queries and only perform them + when the + heartbeat-interval expires in + addition to sending + NOTIFY requests. + + + Finer control can be achieved by using + notify which only sends NOTIFY + messages, + notify-passive which sends NOTIFY + messages and + suppresses the normal refresh queries, refresh + which suppresses normal refresh processing and sends refresh + queries + when the heartbeat-interval + expires, and + passive which just disables normal + refresh + processing. + + + + + + + + + + + + dialup mode + + + + + normal refresh + + + + + heart-beat refresh + + + + + heart-beat notify + + + + + + no (default) + + + + yes + + + + + no + + + + + no + + + + + + yes + + + + no + + + + + yes + + + + + yes + + + + + + notify + + + + yes + + + + + no + + + + + yes + + + + + + refresh + + + + no + + + + + yes + + + + + no + + + + + + passive + + + + no + + + + + no + + + + + no + + + + + + notify-passive + + + + no + + + + + no + + + + + yes + + + + + + + + + Note that normal NOTIFY processing is not affected by + dialup. + + - check-mx-cname + fake-iquery - If check-integrity is set then - fail, warn or ignore MX records that refer - to CNAMES. The default is to warn. + In BIND 8, this option + enabled simulating the obsolete DNS query type + IQUERY. BIND 9 never does + IQUERY simulation. - check-srv-cname + fetch-glue - If check-integrity is set then - fail, warn or ignore SRV records that refer - to CNAMES. The default is to warn. + This option is obsolete. + In BIND 8, fetch-glue yes + caused the server to attempt to fetch glue resource records + it + didn't have when constructing the additional + data section of a response. This is now considered a bad + idea + and BIND 9 never does it. - check-sibling + flush-zones-on-shutdown - When performing integrity checks, also check that - sibling glue exists. The default is yes. + When the nameserver exits due receiving SIGTERM, + flush or do not flush any pending zone writes. The default + is + flush-zones-on-shutdown no. - check-spf + has-old-clients - When performing integrity checks, check that the - two forms of Sender Policy Framwork records (TXT - records starting with "v=spf1" and SPF) both exist - or both don't exist and issue a warning if not - met. The default is warn. + This option was incorrectly implemented + in BIND 8, and is ignored by BIND 9. + To achieve the intended effect + of + has-old-clients yes, specify + the two separate options auth-nxdomain yes + and rfc2308-type1 no instead. - zero-no-soa-ttl + host-statistics - - 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. - + + In BIND 8, this enables keeping of + statistics for every host that the name server interacts + with. + Not implemented in BIND 9. + - zero-no-soa-ttl-cache + maintain-ixfr-base - - When caching a negative response to a SOA query - set the TTL to zero. - The default is no. - + + This option is obsolete. + It was used in BIND 8 to + determine whether a transaction log was + kept for Incremental Zone Transfer. BIND 9 maintains a transaction + log whenever possible. If you need to disable outgoing + incremental zone + transfers, use provide-ixfr no. + - update-check-ksk + minimal-responses - - 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 - used to sign the DNSKEY RRset at the zone apex. - However, if this option is set to no, - then the KSK bit is ignored; KSKs are treated as if they - were ZSKs and are used to sign the entire zone. This is - 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 - ZSK per algorithm. If there is any algorithm for which - this requirement is not met, this option will be ignored - for that algorithm. + + If yes, then when generating + responses the server will only add records to the authority + and additional data sections when they are required (e.g. + delegations, negative responses). This may improve the + performance of the server. + The default is no. - dnssec-dnskey-kskonly + multiple-cnames - - 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 - to sign the DNSKEY RRset at the zone apex. Zone-signing - keys (keys without the KSK bit set) will be used to sign - the remainder of the zone, but not the DNSKEY RRset. - 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. + This option was used in BIND 8 to allow + a domain name to have multiple CNAME records in violation of + the DNS standards. BIND 9.2 onwards + always strictly enforces the CNAME rules both in master + files and dynamic updates. - dnssec-loadkeys-interval + notify - - 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 - or any existing keys' timing metadata has been updated - (see and - ). The - dnssec-loadkeys-interval option - sets the frequency of automatic repository checks, in - minutes. The default is 60 (1 hour), - the minimum is 1 (1 minute), and the - maximum is 1440 (24 hours); any higher - value is silently reduced. + + If yes (the default), + DNS NOTIFY messages are sent when a zone the server is + authoritative for + changes, see . The messages are + sent to the + servers listed in the zone's NS records (except the master + server identified + in the SOA MNAME field), and to any servers listed in the + also-notify option. + + + If master-only, notifies are only + sent + for master zones. + If explicit, notifies are sent only + to + servers explicitly listed using also-notify. + If no, no notifies are sent. + + + The notify option may also be + specified in the zone + statement, + in which case it overrides the options notify statement. + It would only be necessary to turn off this option if it + caused slaves + to crash. - try-tcp-refresh + notify-to-soa - - Try to refresh the zone using TCP if UDP queries fail. - For BIND 8 compatibility, the default is - yes. + + 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 + supposed to contain the name of the ultimate master. + Sometimes, however, a slave is listed as the SOA MNAME in + 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. - dnssec-secure-to-insecure + recursion - - 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. - If set to yes, and if the DNSKEY RRset - 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. + + If yes, and a + DNS query requests recursion, then the server will attempt + to do + all the work required to answer the query. If recursion is + off + and the server does not already know the answer, it will + return a + referral response. The default is + yes. + Note that setting recursion no does not prevent + clients from getting data from the server's cache; it only + prevents new data from being cached as an effect of client + queries. + Caching may still occur as an effect the server's internal + operation, such as NOTIFY address lookups. + See also fetch-glue above. - - - - - - Forwarding - - 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 - do not have direct access to the Internet, but wish to look up - exterior - names anyway. Forwarding occurs only on those queries for which - the server is not authoritative and does not have the answer in - its cache. - - - - - forward - - - 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 - first — and - if that doesn't answer the question, the server will then - look for - the answer itself. If only is - specified, the - server will only query the forwarders. - - - - - - forwarders - - - Specifies the IP addresses to be used - for forwarding. The default is the empty list (no - forwarding). - - - - - - - - Forwarding can also be configured on a per-domain basis, allowing - for the global forwarding options to be overridden in a variety - of ways. You can set particular domains to use different - forwarders, - or have a different forward only/first behavior, - or not forward at all, see . - - - - - Dual-stack Servers - - Dual-stack servers are used as servers of last resort to work - around - problems in reachability due the lack of support for either IPv4 - or IPv6 - on the host machine. - - - - - dual-stack-servers - - - 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 - to resolve the name using only the transport it has. If the - machine is dual - 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 Control - - - Access to the server can be restricted based on the IP address - of the requesting system. See for - details on how to specify IP address lists. - - - - - - allow-notify - - - Specifies which hosts are allowed to - notify this server, a slave, of zone changes in addition - to the zone masters. - allow-notify may also be - specified in the - zone statement, in which case - it overrides the - options allow-notify - statement. It is only meaningful - for a slave zone. If not specified, the default is to - process notify messages - only from a zone's master. - - - + + request-nsid + + + If yes, then an empty EDNS(0) + NSID (Name Server Identifier) option is sent with all + queries to authoritative name servers during iterative + resolution. If the authoritative server returns an NSID + option in its response, then its contents are logged in + the resolver category at level + info. + The default is no. + + + - allow-query + rfc2308-type1 - Specifies which hosts are allowed to ask ordinary - DNS questions. allow-query may - also be specified in the zone - statement, in which case it overrides the - options allow-query statement. - If not specified, the default is to allow queries - from all hosts. + Setting this to yes will + cause the server to send NS records along with the SOA + record for negative + answers. The default is no. - - allow-query-cache is now - used to specify access to the cache. - + + Not yet implemented in BIND + 9. + - allow-query-on + use-id-pool - 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. + This option is obsolete. + BIND 9 always allocates query + IDs from a pool. + + + + + use-ixfr + - If not specified, the default is to allow queries - on all addresses. + This option is obsolete. + If you need to disable IXFR to a particular server or + servers, see + the information on the provide-ixfr option + in . + See also + . - - - allow-query-cache is - used to specify access to the cache. - - - allow-query-cache + provide-ixfr - Specifies which hosts are allowed to get answers - from the cache. If allow-query-cache - is not set then allow-recursion - is used if set, otherwise allow-query - is used if set unless recursion no; is - set in which case none; is used, - otherwise the default (localnets; - localhost;) is used. + See the description of + provide-ixfr in + . - allow-query-cache-on + request-ixfr - Specifies which local addresses can give answers - from the cache. If not specified, the default is - to allow cache queries on any address, - localnets and - localhost. + See the description of + request-ixfr in + . - - allow-recursion - + + treat-cr-as-space + - Specifies which hosts are allowed to make recursive - queries through this server. If - allow-recursion is not set - then allow-query-cache is - used if set, otherwise allow-query - is used if set, otherwise the default - (localnets; - localhost;) is used. + This option was used in BIND + 8 to make + the server treat carriage return ("\r") characters the same way + as a space or tab character, + to facilitate loading of zone files on a UNIX system that + were generated + on an NT or DOS machine. In BIND 9, both UNIX "\n" + and NT/DOS "\r\n" newlines + are always accepted, + and the option is ignored. - - + + - - allow-recursion-on - - - Specifies which local addresses can accept recursive - queries. If not specified, the default is to allow - recursive queries on all addresses. - - - - - - allow-update - - - Specifies which hosts are allowed to - submit Dynamic DNS updates for master zones. The default is - to deny - updates from all hosts. Note that allowing updates based - on the requestor's IP address is insecure; see - for details. - - - - - - allow-update-forwarding - - - Specifies which hosts are allowed to - submit Dynamic DNS updates to slave zones to be forwarded to - the - master. The default is { none; }, - which - means that no update forwarding will be performed. To - enable - update forwarding, specify - allow-update-forwarding { any; };. - Specifying values other than { none; } or - { any; } is usually - counterproductive, since - the responsibility for update access control should rest - with the - master server, not the slaves. - - - Note that enabling the update forwarding feature on a slave - server - may expose master servers relying on insecure IP address - based - access control to attacks; see - for more details. - - - - - - allow-v6-synthesis - - - This option was introduced for the smooth transition from - AAAA - to A6 and from "nibble labels" to binary labels. - However, since both A6 and binary labels were then - deprecated, - this option was also deprecated. - It is now ignored with some warning messages. - - - - - - allow-transfer - - - Specifies which hosts are allowed to - receive zone transfers from the server. allow-transfer may - also be specified in the zone - statement, in which - case it overrides the options allow-transfer statement. - If not specified, the default is to allow transfers to all - hosts. - - - - - - blackhole - - - 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. - - - - - - filter-aaaa - - - Specifies a list of addresses to which - filter-aaaa-on-v4 - is applies. The default is any. - - - - - - resolver-query-timeout - - - The amount of time the resolver will spend attempting - to resolve a recursive query before failing. The default - and minimum is 10 and the maximum is - 30. Setting it to 0 - will result in the default being used. - - - - - - - - - Interfaces - - 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. - 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, - + + additional-from-auth + additional-from-cache + -listen-on { 5.6.7.8; }; -listen-on port 1234 { !1.2.3.4; 1.2/16; }; - + + These options control the behavior of an authoritative + server when + answering queries which have additional data, or when + following CNAME + and DNAME chains. + - - 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 - specified - as the address_match_list for the - listen-on-v6 option, - the server does not bind a separate socket to each IPv6 interface - address as it does for IPv4 if the operating system has enough API - support for IPv6 (specifically if it conforms to RFC 3493 and RFC - 3542). - Instead, it listens on the IPv6 wildcard address. - 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 - address, - regardless of whether the desired API is supported by the system. - - - - Multiple listen-on-v6 options can - be used. - For example, - + + When both of these options are set to yes + (the default) and a + query is being answered from authoritative data (a zone + configured into the server), the additional data section of + the + reply will be filled in using data from other authoritative + zones + and from the cache. In some situations this is undesirable, + such + as when there is concern over the correctness of the cache, + or + in servers where slave zones may be added and modified by + untrusted third parties. Also, avoiding + the search for this additional data will speed up server + operations + at the possible expense of additional queries to resolve + what would + otherwise be provided in the additional section. + -listen-on-v6 { any; }; -listen-on-v6 port 1234 { !2001:db8::/32; any; }; - + + For example, if a query asks for an MX record for host foo.example.com, + and the record found is "MX 10 mail.example.net", normally the address + records (A and AAAA) for mail.example.net will be provided as well, + if known, even though they are not in the example.com zone. + Setting these options to no + disables this behavior and makes + the server only search for additional data in the zone it + answers from. + - - 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.) - + + These options are intended for use in authoritative-only + servers, or in authoritative-only views. Attempts to set + them to no without also + specifying + recursion no will cause the + server to + ignore the options and log a warning message. + - - To make the server not listen on any IPv6 address, use - + + Specifying additional-from-cache no actually + disables the use of the cache not only for additional data + lookups + but also when looking up the answer. This is usually the + desired + behavior in an authoritative-only server where the + correctness of + the cached data is an issue. + -listen-on-v6 { none; }; - + + When a name server is non-recursively queried for a name + that is not + below the apex of any served zone, it normally answers with + an + "upwards referral" to the root servers or the servers of + some other + known parent of the query name. Since the data in an + upwards referral + comes from the cache, the server will not be able to provide + upwards + referrals when additional-from-cache no + has been specified. Instead, it will respond to such + queries + with REFUSED. This should not cause any problems since + upwards referrals are not required for the resolution + process. + - + + - - Query Address - - 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 - IPv6, there is a separate query-source-v6 option. - If address is * (asterisk) or is omitted, - a wildcard IP address (INADDR_ANY) - will be used. - + + match-mapped-addresses + + + 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 + IPv6 socket using mapped addresses. This caused address + match lists designed for IPv4 to fail to match. However, + named now solves this problem + internally. The use of this option is discouraged. + + + - - 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. - The port range(s) is that specified in - the use-v4-udp-ports (for IPv4) - and use-v6-udp-ports (for IPv6) - options, excluding the ranges specified in - the avoid-v4-udp-ports - and avoid-v6-udp-ports options, respectively. - + + filter-aaaa-on-v4 + + + This option is only available when + BIND 9 is compiled with the + --enable-filter-aaaa option on the + "configure" command line. It is intended to help the + transition from IPv4 to IPv6 by not giving IPv6 addresses + to DNS clients unless they have connections to the IPv6 + Internet. This is not recommended unless absolutely + necessary. The default is no. + The filter-aaaa-on-v4 option + may also be specified in view statements + to override the global filter-aaaa-on-v4 + option. + + + If yes, + the DNS client is at an IPv4 address, in filter-aaaa, + and if the response does not include DNSSEC signatures, + then all AAAA records are deleted from the response. + This filtering applies to all responses and not only + authoritative responses. + + + If break-dnssec, + then AAAA records are deleted even when DNSSEC is enabled. + As suggested by the name, this makes the response not verify, + because the DNSSEC protocol is designed detect deletions. + + + This mechanism can erroneously cause other servers to + not give AAAA records to their clients. + A recursing server with both IPv6 and IPv4 network connections + that queries an authoritative server using this mechanism + via IPv4 will be denied AAAA records even if its client is + using IPv6. + + + This mechanism is applied to authoritative as well as + non-authoritative records. + A client using IPv4 that is not allowed recursion can + erroneously be given AAAA records because the server is not + allowed to check for A records. + + + Some AAAA records are given to IPv4 clients in glue records. + IPv4 clients that are servers can then erroneously + answer requests for AAAA records received via IPv4. + + + - - The defaults of the query-source and - query-source-v6 options - are: - + + filter-aaaa-on-v6 + + + Identical to filter-aaaa-on-v4, + except it filters AAAA responses to queries from IPv6 + clients instead of IPv4 clients. To filter all + responses, set both options to yes. + + + -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 - system provides a programming interface to retrieve the - system's default range for ephemeral ports. - If such an interface is available, - named will use the corresponding system - default range; otherwise, it will use its own defaults: - + + ixfr-from-differences + + + When yes and the server loads a new + version of a master zone from its zone file or receives a + new version of a slave file via zone transfer, it will + compare the new version to the previous one and calculate + a set of differences. The differences are then logged in + the zone's journal file such that the changes can be + transmitted to downstream slaves as an incremental zone + transfer. + + + By allowing incremental zone transfers to be used for + non-dynamic zones, this option saves bandwidth at the + expense of increased CPU and memory consumption at the + master. + In particular, if the new version of a zone is completely + different from the previous one, the set of differences + will be of a size comparable to the combined size of the + old and new zone version, and the server will need to + temporarily allocate memory to hold this complete + difference set. + + ixfr-from-differences + also accepts master and + slave at the view and options + levels which causes + ixfr-from-differences to be enabled for + all master or + slave zones respectively. + It is off by default. + + + -use-v4-udp-ports { range 1024 65535; }; -use-v6-udp-ports { range 1024 65535; }; - + + multi-master + + + This should be set when you have multiple masters for a zone + and the + addresses refer to different machines. If yes, named will + not log + when the serial number on the master is less than what named + currently + has. The default is no. + + + - - 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 - (14 bits of entropy). - Note also that the system's default range when used may be - too small for this purpose, and that the range may even be - changed while named is running; the new - range will automatically be applied when named - is reloaded. - It is encouraged to - configure use-v4-udp-ports and - use-v6-udp-ports explicitly so that the - ranges are sufficiently large and are reasonably - independent from the ranges used by other applications. - + + dnssec-enable + + + Enable DNSSEC support in named. Unless set to yes, + named behaves as if it does not support DNSSEC. + The default is yes. + + + - - Note: the operational configuration - where named runs may prohibit the use - of some ports. For example, UNIX systems will not allow - named running without a root privilege - to use ports less than 1024. - If such ports are included in the specified (or detected) - set of query ports, the corresponding query attempts will - fail, resulting in resolution failures or delay. - It is therefore important to configure the set of ports - that can be safely used in the expected operational environment. - + + dnssec-validation + + + Enable DNSSEC validation in named. + Note dnssec-enable also needs to be + set to yes to be effective. + If set to no, DNSSEC validation + is disabled. 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 trusted-keys or + managed-keys statement. The default + is yes. + + + - - The defaults of the avoid-v4-udp-ports and - avoid-v6-udp-ports options - are: - + + dnssec-accept-expired + + + Accept expired signatures when verifying DNSSEC signatures. + The default is no. + Setting this option to yes + leaves named vulnerable to + replay attacks. + + + -avoid-v4-udp-ports {}; -avoid-v6-udp-ports {}; - + + querylog + + + Specify whether query logging should be started when named + starts. + If querylog is not specified, + then the query logging + is determined by the presence of the logging category queries. + + + - - Note: BIND 9.5.0 introduced - the use-queryport-pool - option to support a pool of such random ports, but this - option is now obsolete because reusing the same ports in - the pool may not be sufficiently secure. - For the same reason, it is generally strongly discouraged to - specify a particular port for the - query-source or - query-source-v6 options; - it implicitly disables the use of randomized port numbers. - + + check-names + + + This option is used to restrict the character set and syntax + of + certain domain names in master files and/or DNS responses + received + from the network. The default varies according to usage + area. For + master zones the default is fail. + For slave zones the default + is warn. + For 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 + 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. + It also applies to the RDATA of PTR records where the owner + name indicated that it is a reverse lookup of a hostname + (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT). + + + - - - use-queryport-pool - - - This option is obsolete. + + check-dup-records + + + 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. - - queryport-pool-ports - - - This option is obsolete. + + check-mx + + + Check whether the MX record appears to refer to a IP address. + The default is to warn. Other possible + values are fail and + ignore. - - queryport-pool-updateinterval - - - This option is obsolete. + + check-wildcard + + + 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 + to understand the wildcard matching algorithm (RFC 1034). + This option + affects master zones. The default (yes) is to check + for non-terminal wildcards and issue a warning. - - - - - 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. - - - - - - Zone Transfers - - 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. - - - - - - also-notify - - - Defines a global list of IP addresses of name servers - that are also sent NOTIFY messages whenever a fresh copy of - the - zone is loaded, in addition to the servers listed in the - zone's NS records. - This helps to ensure that copies of the zones will - quickly converge on stealth servers. - Optionally, a port may be specified with each - also-notify address to send - the notify messages to a port other than the - default of 53. - An optional TSIG key can also be specified with each - address to cause the notify messages to be signed; this - can be useful when sending notifies to multiple views. - 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 - the options also-notify - statement. When a zone notify - statement - is set to no, the IP - addresses in the global also-notify list will - not be sent NOTIFY messages for that zone. The default is - the empty - list (no global notification list). - - - - - - max-transfer-time-in - - - 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). - - - - - - max-transfer-idle-in - - - 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). - - - - - - max-transfer-time-out - - - 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). - - - - - - max-transfer-idle-out - - - 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). - - - - - - serial-query-rate + + + check-integrity - Slave servers will periodically query master - servers to find out if zone serial numbers have - changed. Each such query uses a minute amount of - the slave server's network bandwidth. To limit - the amount of bandwidth used, BIND 9 limits the - rate at which queries are sent. The value of the - serial-query-rate option, an - integer, is the maximum number of queries sent - per second. The default is 20. + 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 + address records exist for delegated zones. For + MX and SRV records only in-zone hostnames are + checked (for out-of-zone hostnames use + named-checkzone). + For NS records only names below top of zone are + checked (for out-of-zone names and glue consistency + checks use named-checkzone). + The default is yes. - In addition to controlling the rate SOA refresh - queries are issued at - serial-query-rate also controls - the rate at which NOTIFY messages are sent from - both master and slave zones. + Check that the two forms of Sender Policy Framework + records (TXT records starting with "v=spf1" and SPF) either + both exist or both don't exist. Warnings are + emitted it they don't and be suppressed with + check-spf. - - serial-queries - - - In BIND 8, the serial-queries - option - set the maximum number of concurrent serial number queries - allowed to be outstanding at any given time. - BIND 9 does not limit the number of outstanding - serial queries and ignores the serial-queries option. - Instead, it limits the rate at which the queries are sent - as defined using the serial-query-rate option. - - - - - - transfer-format - - - - Zone transfers can be sent using two different formats, - one-answer and - many-answers. - The transfer-format option is used - on the master server to determine which format it sends. - one-answer uses one DNS message per - resource record transferred. - many-answers packs as many resource - records as possible into a message. - many-answers is more efficient, but is - only supported by relatively new slave servers, - such as BIND 9, BIND - 8.x and BIND 4.9.5 onwards. - The many-answers format is also supported by - recent Microsoft Windows nameservers. - The default is many-answers. - transfer-format may be overridden on a - per-server basis by using the server - statement. - - - - - - - transfers-in - - - 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. - - - - - - transfers-out - - - 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. - - - - - - transfers-per-ns - - - The maximum number of inbound zone transfers - that can be concurrently transferring from a given remote - name server. - The default value is 2. - Increasing transfers-per-ns - may - speed up the convergence of slave zones, but it also may - increase - the load on the remote 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 - source IPv4 address, and optionally the UDP port, - used for the refresh queries and forwarded dynamic - updates. If not set, it defaults to a system - controlled value which will usually be the address - of the interface "closest to" the remote end. This - address must appear in the remote end's - allow-transfer option for the - zone being transferred, if one is specified. This - statement sets the - transfer-source for all zones, - but can be overridden on a per-view or per-zone - basis by including a - transfer-source statement within - the view or - zone block in the configuration - file. - - - - Solaris 2.5.1 and earlier does not support setting the - source address for TCP sockets. - - - - - - - transfer-source-v6 - - - The same as transfer-source, - except zone transfers are performed using IPv6. - - - - - - alt-transfer-source - - - 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 - to be used, you should set - use-alt-transfer-source - appropriately and you should not depend upon - getting an answer back to the first refresh - query. - - - - - - alt-transfer-source-v6 - - - An alternate transfer source if the one listed in - transfer-source-v6 fails and - use-alt-transfer-source is - set. - - - - - - use-alt-transfer-source - - - Use the alternate transfer sources or not. If views are - specified this defaults to no - otherwise it defaults to - yes (for BIND 8 - compatibility). - - - - - - notify-source - - 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 - server's masters zone clause or - in an allow-notify clause. This - statement sets the notify-source - for all zones, but can be overridden on a per-zone or - per-view basis by including a - notify-source statement within - the zone or - view block in the configuration - file. - - - - Solaris 2.5.1 and earlier does not support setting the - source address for TCP sockets. - - - - - - - notify-source-v6 - - - Like notify-source, - but applies to notify messages sent to IPv6 addresses. - - - - - - - - - - UDP Port Lists - - use-v4-udp-ports, - avoid-v4-udp-ports, - use-v6-udp-ports, and - avoid-v6-udp-ports - specify a list of IPv4 and IPv6 UDP ports that will be - used or not used as source ports for UDP messages. - See about how the - available ports are determined. - For example, with the following configuration - + + check-mx-cname + + + If check-integrity is set then + fail, warn or ignore MX records that refer + to CNAMES. The default is to warn. + + + - -use-v6-udp-ports { range 32768 65535; }; -avoid-v6-udp-ports { 40000; range 50000 60000; }; - + + check-srv-cname + + + If check-integrity is set then + fail, warn or ignore SRV records that refer + to CNAMES. The default is to warn. + + + - - 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 - port that is blocked by your firewall or a port that is - used by other applications; - if a query went out with a source port blocked by a - firewall, the - answer would not get by the firewall and the name server would - have to query again. - Note: the desired range can also be represented only with - use-v4-udp-ports and - use-v6-udp-ports, and the - avoid- options are redundant in that - sense; they are provided for backward compatibility and - to possibly simplify the port specification. - - - - - Operating System Resource Limits - - - 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 - 1073741824 to specify a limit of - one - gigabyte. unlimited requests - unlimited use, or the - maximum available amount. default - uses the limit - that was in force when the server was started. See the description - of size_spec in . - - - - The following options set operating system resource limits for - the name server process. Some operating systems don't support - some or - any of the limits. On such systems, a warning will be issued if - the - unsupported limit is used. - - - - - - coresize - - - The maximum size of a core dump. The default - is default. - - - - - - datasize - - - The maximum amount of data memory the server - may use. The default is default. - This is a hard limit on server memory usage. - If the server attempts to allocate memory in excess of this - limit, the allocation will fail, which may in turn leave - the server unable to perform DNS service. Therefore, - this option is rarely useful as a way of limiting the - amount of memory used by the server, but it can be used - to raise an operating system data size limit that is - too small by default. If you wish to limit the amount - of memory used by the server, use the - max-cache-size and - recursive-clients - options instead. - - - - - - files - - - The maximum number of files the server - may have open concurrently. The default is unlimited. - - - - - - stacksize - - - The maximum amount of stack memory the server - may use. The default is default. - - - - - - - - - - Server Resource Limits - - - The following options set limits on the server's - resource consumption that are enforced internally by the - server rather than the operating system. - - - - - - max-ixfr-log-size - - - This option is obsolete; it is accepted - and ignored for BIND 8 compatibility. The option - max-journal-size performs a - similar function in BIND 9. - - - - - - max-journal-size - - - Sets a maximum size for each journal file - (see ). When the journal file - approaches - the specified size, some of the oldest transactions in the - journal - will be automatically removed. The largest permitted - value is 2 gigabytes. The default is - unlimited, which also - means 2 gigabytes. - This may also be set on a per-zone basis. - - - - - - host-statistics-max - - - In BIND 8, specifies the maximum number of host statistics - entries to be kept. - Not implemented in BIND 9. - - - - - - recursive-clients - - - The maximum number of simultaneous recursive lookups - the server will perform on behalf of clients. The default - is - 1000. Because each recursing - client uses a fair - bit of memory, on the order of 20 kilobytes, the value of - the - recursive-clients option may - have to be decreased - on hosts with limited memory. - - - - - - tcp-clients - - - The maximum number of simultaneous client TCP - connections that the server will accept. - The default is 100. - - - - - - reserved-sockets - - - 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, tcp-clients as well as - to provide room for outgoing TCP queries and incoming zone - transfers. The default is 512. - The minimum value is 128 and the - maximum value is 128 less than - maxsockets (-S). This option may be removed in the future. - - - This option has little effect on Windows. - - - - - - max-cache-size - - - The maximum amount of memory to use for the - server's cache, in bytes. - When the amount of data in the cache - reaches this limit, the server will cause records to - expire prematurely based on an LRU based strategy so - that the limit is not exceeded. - The keyword unlimited, - or the value 0, will place no limit on cache size; - records will be purged from the cache only when their - TTLs expire. - Any positive values less than 2MB will be ignored - and reset to 2MB. - In a server with multiple views, the limit applies - separately to the cache of each view. - The default is unlimited. - - - - - - tcp-listen-queue - - - The listen queue depth. The default and minimum is 10. - If the kernel supports the accept filter "dataready" this - also controls how - many TCP connections that will be queued in kernel space - waiting for - some data before being passed to accept. Nonzero values - 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. - - - - - - - - - - Periodic Task Intervals - - - - - cleaning-interval - - - This interval is effectively obsolete. Previously, - the server would remove expired resource records - from the cache every cleaning-interval minutes. - BIND 9 now manages cache - memory in a more sophisticated manner and does not - rely on the periodic cleaning any more. - Specifying this option therefore has no effect on - the server's behavior. - - - - - - heartbeat-interval - - - The server will perform zone maintenance tasks - for all zones marked as dialup whenever this - interval expires. The default is 60 minutes. Reasonable - values are up - to 1 day (1440 minutes). The maximum value is 28 days - (40320 minutes). - If set to 0, no zone maintenance for these zones will occur. - - - - - - interface-interval - - - The server will scan the network interface list - every interface-interval - minutes. The default - is 60 minutes. The maximum value is 28 days (40320 minutes). - If set to 0, interface scanning will only occur when - the configuration file is loaded. After the scan, the - server will - begin listening for queries on any newly discovered - interfaces (provided they are allowed by the - listen-on configuration), and - will - stop listening on interfaces that have gone away. - - - - - - statistics-interval - - - Name server statistics will be logged - every statistics-interval - minutes. The default is - 60. The maximum value is 28 days (40320 minutes). - If set to 0, no statistics will be logged. - - - Not yet implemented in - BIND 9. - - - - - - - - - - - Topology - - - All other things being equal, when the server chooses a name - server - to query from a list of name servers, it prefers the one that is - topologically closest to itself. The topology statement - takes an address_match_list and - interprets it - in a special way. Each top-level list element is assigned a - distance. - Non-negated elements get a distance based on their position in the - list, where the closer the match is to the start of the list, the - shorter the distance is between it and the server. A negated match - will be assigned the maximum distance from the server. If there - is no match, the address will get a distance which is further than - any non-negated list element, and closer than any negated element. - For example, - - -topology { - 10/8; - !1.2.3/24; - { 1.2/16; 3/8; }; -}; - - - will prefer servers on network 10 the most, followed by hosts - on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the - exception of hosts on network 1.2.3 (netmask 255.255.255.0), which - is preferred least of all. - - - The default topology is - - - topology { localhost; localnets; }; - - - - - The topology option - is not implemented in BIND 9. - - - - - - - The <command>sortlist</command> Statement - - - The response to a DNS query may consist of multiple resource - records (RRs) forming a resource records set (RRset). - The name server will normally return the - RRs within the RRset in an indeterminate order - (but see the rrset-order - statement in ). - The client resolver code should rearrange the RRs as appropriate, - that is, using any addresses on the local net in preference to - other addresses. - However, not all resolvers can do this or are correctly - configured. - When a client is using a local server, the sorting can be performed - in the server, based on the 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 even - more specifically than the topology - statement - does (). - Each top level statement in the sortlist must - itself be an explicit address_match_list with - one or two elements. The first element (which may be an IP - address, - an IP prefix, an ACL name or a nested address_match_list) - of each top level list is checked against the source address of - the query until a match is found. - - - 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 select the - address - in the response to move to the beginning of the response. If the - statement is a list of two elements, then the second element is - treated the same as the address_match_list in - a topology statement. Each top - level element - is assigned a distance and the 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 preferred are - addresses - on the 192.168.1/24 network, and after that either the - 192.168.2/24 - or - 192.168.3/24 network with no preference shown between these two - networks. Queries received from a host on the 192.168.1/24 network - will prefer other addresses on that network to the 192.168.2/24 - and - 192.168.3/24 networks. Queries received from a host on the - 192.168.4/24 - or 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 - { localhost; - { localnets; - 192.168.1/24; - { 192.168.2/24; 192.168.3/24; }; }; }; - // IF on class C 192.168.1 THEN use .1, or .2 or .3 - { 192.168.1/24; - { 192.168.1/24; - { 192.168.2/24; 192.168.3/24; }; }; }; - // IF on class C 192.168.2 THEN use .2, or .1 or .3 - { 192.168.2/24; - { 192.168.2/24; - { 192.168.1/24; 192.168.3/24; }; }; }; - // IF on class C 192.168.3 THEN use .3, or .1 or .2 - { 192.168.3/24; - { 192.168.3/24; - { 192.168.1/24; 192.168.2/24; }; }; }; - // IF .4 or .5 THEN prefer that net - { { 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 BIND 4.9.x. Responses sent - to queries from the local host will favor any of the directly - connected - networks. Responses sent to queries from any other hosts on a - directly - connected network will prefer addresses on that same network. - Responses - to other queries will not be sorted. - - -sortlist { - { localhost; localnets; }; - { localnets; }; -}; - - - - - RRset Ordering - - 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 - configuration - of the ordering of the records in a multiple record response. - See also 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: - - - - - - - - - fixed - - - - Records are returned in the order they - are defined in the zone file. - - - - - - random - - - - Records are returned in some random order. - - - - - - cyclic - - - - Records are returned in a cyclic round-robin order. - - - If BIND is configured with the - "--enable-fixed-rrset" option at compile time, then - the initial ordering of the RRset will match the - one specified in the zone file. - - - - - - - - For example: - - -rrset-order { - class IN type A name "host.example.com" order random; - 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, all 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. - - - - - - Tuning - - - - - lame-ttl - - - 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). - - - - Lame-ttl also controls the amount of time DNSSEC - validation failures are cached. There is a minimum - of 30 seconds applied to bad cache entries if the - lame-ttl is set to less than 30 seconds. - - - - - - - max-ncache-ttl - - - To reduce network traffic and increase performance, - the server stores negative answers. max-ncache-ttl is - used to set a maximum retention time for these answers in - the server - in seconds. The default - max-ncache-ttl is 10800 seconds (3 hours). - max-ncache-ttl cannot exceed - 7 days and will - be silently truncated to 7 days if set to a greater value. - - - - - - max-cache-ttl - - - Sets the maximum time for which the server will - cache ordinary (positive) answers. The default is - one week (7 days). - 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. - - - - - - min-roots - - - The minimum number of root servers that - is required for a request for the root servers to be - accepted. The default - is 2. - - - - Not implemented in BIND 9. - - - - + + check-sibling + + + When performing integrity checks, also check that + sibling glue exists. The default is yes. + + + - sig-validity-interval + check-spf - Specifies the number of days into the future when - DNSSEC signatures automatically generated as a - result of dynamic updates () will expire. There - is an optional second field which specifies how - long before expiry that the signatures will be - regenerated. If not specified, the signatures will - be regenerated at 1/4 of base interval. The second - field is specified in days if the base interval is - greater than 7 days otherwise it is specified in hours. - The default base interval is 30 days - 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 - should be, at least, several multiples of the SOA - expire interval to allow for reasonable interaction - between the various timer and expiry dates. + When performing integrity checks, check that the + two forms of Sender Policy Framwork records (TXT + records starting with "v=spf1" and SPF) both exist + or both don't exist and issue a warning if not + met. The default is warn. - sig-signing-nodes + zero-no-soa-ttl - Specify the maximum number of nodes to be - examined in each quantum when signing a zone with - a new DNSKEY. The default is - 100. + 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. - sig-signing-signatures + zero-no-soa-ttl-cache - Specify a threshold number of signatures that - will terminate processing a quantum when signing - a zone with a new DNSKEY. The default is - 10. + When caching a negative response to a SOA query + set the TTL to zero. + The default is no. - sig-signing-type + update-check-ksk - Specify a private RDATA type to be used when generating - key signing records. The default is - 65534. + 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. - It is expected that this parameter may be removed - in a future version once there is a standard type. + 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 + used to sign the DNSKEY RRset at the zone apex. + However, if this option is set to no, + then the KSK bit is ignored; KSKs are treated as if they + were ZSKs and are used to sign the entire zone. This is + similar to the dnssec-signzone -z + command line option. - These records can be removed from the zone once named - has completed signing the zone with the matching key - using nsupdate or - rndc signing -clear. - rndc signing -clear is the only supported - way to remove these records from - inline-signing zones. + 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 + ZSK per algorithm. If there is any algorithm for which + this requirement is not met, this option will be ignored + for that algorithm. - - min-refresh-time - max-refresh-time - min-retry-time - max-retry-time - - - These options control the server's behavior on refreshing a - zone - (querying for SOA changes) or retrying failed transfers. - Usually the SOA values for the zone are used, but these - values - are set by the master, giving slave server administrators - little - control over their contents. - - - These options allow the administrator to set a minimum and - maximum - refresh and retry time either 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. - + + dnssec-dnskey-kskonly + - The following defaults apply. - min-refresh-time 300 seconds, - max-refresh-time 2419200 seconds - (4 weeks), min-retry-time 500 seconds, - and max-retry-time 1209600 seconds - (2 weeks). + 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 + to sign the DNSKEY RRset at the zone apex. Zone-signing + keys (keys without the KSK bit set) will be used to sign + the remainder of the zone, but not the DNSKEY RRset. + This is similar to the + dnssec-signzone -x command line option. - - - - - edns-udp-size - - - Sets the advertised EDNS UDP buffer size in bytes - to control the size of packets received. - Valid values are 512 to 4096 (values outside this range - will be silently adjusted). 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 packets that are greater than 512 bytes. - - named will fallback to using 512 bytes - if it get a series of timeout at the initial value. 512 - bytes is not being offered to encourage sites to fix their - firewalls. Small EDNS UDP sizes will result in the - excessive use of TCP. + The default is no. If + update-check-ksk is set to + no, this option is ignored. - - + + - - max-udp-size + + dnssec-loadkeys-interval - 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). The default - value is 4096. The usual reason for setting - max-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 packets that are greater than 512 bytes. - 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. + 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 + or any existing keys' timing metadata has been updated + (see and + ). The + dnssec-loadkeys-interval option + sets the frequency of automatic repository checks, in + minutes. The default is 60 (1 hour), + the minimum is 1 (1 minute), and the + maximum is 1440 (24 hours); any higher + value is silently reduced. - masterfile-format + try-tcp-refresh - Specifies - the file format of zone files (see - ). - The default value is text, which is the - standard textual representation, except for slave zones, - in which the default value is raw. - Files in other formats than text are - typically expected to be generated by the - 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 - file in the text format. In particular, - check-names checks do not apply - for the raw format. This means - a zone file in the raw format - must be generated with the same check level as that - specified in the named configuration - file. Also, map format files are - 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 - by including a masterfile-format - statement within the zone or - view block in the configuration - file. - + + Try to refresh the zone using TCP if UDP queries fail. + For BIND 8 compatibility, the default is + yes. + - - clients-per-query - max-clients-per-query - - 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 - before dropping additional clients. named will attempt to - self tune this value and changes will be logged. The - default values are 10 and 100. - + + dnssec-secure-to-insecure + - 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 - assume that it is dealing with a non-responsive zone - and will drop additional queries. If it gets a response - after dropping queries, it will raise the estimate. The - estimate will then be lowered in 20 minutes if it has - remained unchanged. + 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. + If set to yes, and if the DNSKEY RRset + at the zone apex is deleted, all RRSIG and NSEC records + will be removed from the zone as well. - 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 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.) - If max-clients-per-query is set to zero, - then there is no upper bound other than imposed by - recursive-clients. + 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. - + - - notify-delay - - - 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. - - - + - - max-rsa-exponent-size - - - 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. - - - + + + Forwarding + + 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 + do not have direct access to the Internet, but wish to look up + exterior + names anyway. Forwarding occurs only on those queries for which + the server is not authoritative and does not have the answer in + its cache. + + + - prefetch + forward - 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. + 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 + first — and + if that doesn't answer the question, the server will then + look for + the answer itself. If only is + specified, the + server will only query the forwarders. + + + + + forwarders + - The specifies the the - "trigger" TTL value at which prefetch of the current - query will take place: when a cache record with a - lower TTL value is encountered during query processing, - it will be refreshed. Valid trigger TTL values are 1 to - 10 seconds. Setting a trigger TTL to zero disables - prefetch. - - - An optional second argument can be used - to set the smallest original - TTL value that will be accepted for a record to be - eligible for prefetching. The difference between - the trigger TTL and the eligibility TTL must be - at least 6 seconds. - - - The default trigger and eligibility TTLs are - 2 and 9, - respectively. + Specifies the IP addresses to be used + for forwarding. The default is the empty list (no + forwarding). + - - - - Built-in server information zones - - - The server provides some helpful diagnostic information - through a number of built-in zones under the - pseudo-top-level-domain bind in the - CHAOS class. These zones are part - of a - built-in view (see ) of - class - CHAOS which is separate from the - default view of class IN. Most global - configuration options (allow-query, - etc) will apply to this view, but some are locally - overridden: notify, - recursion and - allow-new-zones are - always set to no, and - 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. - - - - - - version - - - The version the server should report - via a query of the name version.bind - with type TXT, class CHAOS. - The default is the real version number of this server. - Specifying version none - disables processing of the queries. - - - - - - hostname - - - The hostname the server should report via a query of - the name hostname.bind - with type TXT, class CHAOS. - This defaults to the hostname of the machine hosting the - name server as - found by the gethostname() function. The primary purpose of such queries - is to - identify which of a group of anycast servers is actually - answering your queries. Specifying hostname none; - disables processing of the queries. - - - - - - server-id - - - The ID the server should report when receiving a Name - Server Identifier (NSID) query, or a query of the name - ID.SERVER with type - TXT, class CHAOS. - The primary purpose of such queries is to - identify which of a group of anycast servers is actually - answering your queries. Specifying server-id none; - disables processing of the queries. - Specifying server-id hostname; will cause named to - use the hostname as found by the gethostname() function. - The default server-id is none. - - - - - - - - - - Built-in Empty Zones - - Named has some built-in empty zones (SOA and NS records only). - These are for zones that should normally be answered locally - and which queries should not be sent to the Internet's root - servers. The official servers which cover these namespaces - return NXDOMAIN responses to these queries. In particular, - these cover the reverse namespaces for addresses from - RFC 1918, RFC 4193, RFC 5737 and RFC 6598. They also include the - reverse namespace for IPv6 local address (locally assigned), - IPv6 link local addresses, the IPv6 loopback address and the - IPv6 unknown address. - - - Named 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: - - 10.IN-ADDR.ARPA - 16.172.IN-ADDR.ARPA - 17.172.IN-ADDR.ARPA - 18.172.IN-ADDR.ARPA - 19.172.IN-ADDR.ARPA - 20.172.IN-ADDR.ARPA - 21.172.IN-ADDR.ARPA - 22.172.IN-ADDR.ARPA - 23.172.IN-ADDR.ARPA - 24.172.IN-ADDR.ARPA - 25.172.IN-ADDR.ARPA - 26.172.IN-ADDR.ARPA - 27.172.IN-ADDR.ARPA - 28.172.IN-ADDR.ARPA - 29.172.IN-ADDR.ARPA - 30.172.IN-ADDR.ARPA - 31.172.IN-ADDR.ARPA - 168.192.IN-ADDR.ARPA - 64.100.IN-ADDR.ARPA - 65.100.IN-ADDR.ARPA - 66.100.IN-ADDR.ARPA - 67.100.IN-ADDR.ARPA - 68.100.IN-ADDR.ARPA - 69.100.IN-ADDR.ARPA - 70.100.IN-ADDR.ARPA - 71.100.IN-ADDR.ARPA - 72.100.IN-ADDR.ARPA - 73.100.IN-ADDR.ARPA - 74.100.IN-ADDR.ARPA - 75.100.IN-ADDR.ARPA - 76.100.IN-ADDR.ARPA - 77.100.IN-ADDR.ARPA - 78.100.IN-ADDR.ARPA - 79.100.IN-ADDR.ARPA - 80.100.IN-ADDR.ARPA - 81.100.IN-ADDR.ARPA - 82.100.IN-ADDR.ARPA - 83.100.IN-ADDR.ARPA - 84.100.IN-ADDR.ARPA - 85.100.IN-ADDR.ARPA - 86.100.IN-ADDR.ARPA - 87.100.IN-ADDR.ARPA - 88.100.IN-ADDR.ARPA - 89.100.IN-ADDR.ARPA - 90.100.IN-ADDR.ARPA - 91.100.IN-ADDR.ARPA - 92.100.IN-ADDR.ARPA - 93.100.IN-ADDR.ARPA - 94.100.IN-ADDR.ARPA - 95.100.IN-ADDR.ARPA - 96.100.IN-ADDR.ARPA - 97.100.IN-ADDR.ARPA - 98.100.IN-ADDR.ARPA - 99.100.IN-ADDR.ARPA - 100.100.IN-ADDR.ARPA - 101.100.IN-ADDR.ARPA - 102.100.IN-ADDR.ARPA - 103.100.IN-ADDR.ARPA - 104.100.IN-ADDR.ARPA - 105.100.IN-ADDR.ARPA - 106.100.IN-ADDR.ARPA - 107.100.IN-ADDR.ARPA - 108.100.IN-ADDR.ARPA - 109.100.IN-ADDR.ARPA - 110.100.IN-ADDR.ARPA - 111.100.IN-ADDR.ARPA - 112.100.IN-ADDR.ARPA - 113.100.IN-ADDR.ARPA - 114.100.IN-ADDR.ARPA - 115.100.IN-ADDR.ARPA - 116.100.IN-ADDR.ARPA - 117.100.IN-ADDR.ARPA - 118.100.IN-ADDR.ARPA - 119.100.IN-ADDR.ARPA - 120.100.IN-ADDR.ARPA - 121.100.IN-ADDR.ARPA - 122.100.IN-ADDR.ARPA - 123.100.IN-ADDR.ARPA - 124.100.IN-ADDR.ARPA - 125.100.IN-ADDR.ARPA - 126.100.IN-ADDR.ARPA - 127.100.IN-ADDR.ARPA - 0.IN-ADDR.ARPA - 127.IN-ADDR.ARPA - 254.169.IN-ADDR.ARPA - 2.0.192.IN-ADDR.ARPA - 100.51.198.IN-ADDR.ARPA - 113.0.203.IN-ADDR.ARPA - 255.255.255.255.IN-ADDR.ARPA - 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA - 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA - 8.B.D.0.1.0.0.2.IP6.ARPA - D.F.IP6.ARPA - 8.E.F.IP6.ARPA - 9.E.F.IP6.ARPA - A.E.F.IP6.ARPA - B.E.F.IP6.ARPA - + Forwarding can also be configured on a per-domain basis, allowing + for the global forwarding options to be overridden in a variety + of ways. You can set particular domains to use different + forwarders, + or have a different forward only/first behavior, + or not forward at all, see . + + + + Dual-stack Servers - 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 - at the view level. To override the options list of disabled - zones, you can disable the root zone at the view level, for example: - - disable-empty-zone "."; - + 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. + + + + dual-stack-servers + + + 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 + to resolve the name using only the transport it has. If the + machine is dual + 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 Control + - 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 - being made to the infrastructure servers for names in these - spaces. So many in fact that sacrificial servers were needed - to be deployed to channel the query load away from the - infrastructure servers. + Access to the server can be restricted based on the IP address + of the requesting system. See for + details on how to specify IP address lists. - - The real parent servers for these zones should disable all - empty zone under the parent zone they serve. For the real - root servers, this is all built-in empty zones. This will - enable them to return referrals to deeper in the tree. - - + + + - empty-server + allow-notify - - 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. - - + + Specifies which hosts are allowed to + notify this server, a slave, of zone changes in addition + to the zone masters. + allow-notify may also be + specified in the + zone statement, in which case + it overrides the + options allow-notify + statement. It is only meaningful + for a slave zone. If not specified, the default is to + process notify messages + only from a zone's master. + + - + - empty-contact + allow-query - - Specify what contact name will appear in the returned - SOA record for empty zones. If none is specified, then - "." will be used. - + + Specifies which hosts are allowed to ask ordinary + DNS questions. allow-query may + also be specified in the zone + statement, in which case it overrides the + options allow-query statement. + If not specified, the default is to allow queries + from all hosts. + + + + allow-query-cache is now + used to specify access to the cache. + + - + - empty-zones-enable + allow-query-on - - Enable or disable all empty zones. By default, they - are enabled. - + + 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. + + - + - disable-empty-zone + allow-query-cache - - Disable individual empty zones. By default, none are - disabled. This option can be specified multiple times. - + + Specifies which hosts are allowed to get answers + from the cache. If allow-query-cache + is not set then allow-recursion + is used if set, otherwise allow-query + is used if set unless recursion no; is + set in which case none; is used, + otherwise the default (localnets; + localhost;) is used. + - - - - - Additional Section Caching - - - The additional section cache, also called acache, - is an internal cache to improve the response performance of BIND 9. - When additional section caching is enabled, BIND 9 will - cache an internal short-cut to the additional section content for - each answer RR. - Note that acache is an internal caching - mechanism of BIND 9, and is not related to the DNS caching - server function. - - - - Additional section caching does not change the - response content (except the RRsets ordering of the additional - section, see below), but can improve the response performance - significantly. - It is particularly effective when BIND 9 acts as an authoritative - server for a zone that has many delegations with many glue RRs. - - - - In order to obtain the maximum performance improvement - from additional section caching, setting - additional-from-cache - to no is recommended, since the current - implementation of acache - does not short-cut of additional section information from the - DNS cache data. - - - - One obvious disadvantage of acache is - that it requires much more - memory for the internal cached data. - Thus, if the response performance does not matter and memory - consumption is much more critical, the - acache mechanism can be - disabled by setting acache-enable to - no. - It is also possible to specify the upper limit of memory - consumption - for acache by using max-acache-size. - - - - Additional section caching also has a minor effect on the - RRset ordering in the additional section. - Without acache, - cyclic order is effective for the additional - section as well as the answer and authority sections. - However, additional section caching fixes the ordering when it - first caches an RRset for the additional section, and the same - ordering will be kept in succeeding responses, regardless of the - setting of rrset-order. - The effect of this should be minor, however, since an - RRset in the additional section - typically only contains a small number of RRs (and in many cases - it only contains a single RR), in which case the - ordering does not matter much. - - - - The following is a summary of options related to - acache. - - - - - - acache-enable - - - If yes, additional section caching is - enabled. The default value is no. - - - - - - acache-cleaning-interval - - - The server will remove stale cache entries, based on an LRU - based - algorithm, every acache-cleaning-interval minutes. - The default is 60 minutes. - If set to 0, no periodic cleaning will occur. - - - - - - max-acache-size - - - The maximum amount of memory in bytes to use for the server's acache. - When the amount of data in the acache reaches this limit, - the server - will clean more aggressively so that the limit is not - exceeded. - In a server with multiple views, the limit applies - separately to the - acache of each view. - The default is 16M. - - - - - - - - - - Content Filtering - - BIND 9 provides the ability to filter - out DNS responses from external DNS servers containing - certain types of data in the answer section. - Specifically, it can reject address (A or AAAA) records if - the corresponding IPv4 or IPv6 addresses match the given - address_match_list of the - deny-answer-addresses option. - It can also reject CNAME or DNAME records if the "alias" - name (i.e., the CNAME alias or the substituted query name - due to DNAME) matches the - given namelist of the - deny-answer-aliases option, where - "match" means the alias name is a subdomain of one of - the name_list elements. - If the optional namelist is specified - with except-from, records whose query name - matches the list will be accepted regardless of the filter - setting. - Likewise, if the alias name is a subdomain of the - corresponding zone, the deny-answer-aliases - filter will not apply; - for example, even if "example.com" is specified for - deny-answer-aliases, - -www.example.com. CNAME xxx.example.com. + + allow-query-cache-on + + + Specifies which local addresses can give answers + from the cache. If not specified, the default is + to allow cache queries on any address, + localnets and + localhost. + + + + + + allow-recursion + + + Specifies which hosts are allowed to make recursive + queries through this server. If + allow-recursion is not set + then allow-query-cache is + used if set, otherwise allow-query + is used if set, otherwise the default + (localnets; + localhost;) is used. + + + + + + allow-recursion-on + + + Specifies which local addresses can accept recursive + queries. If not specified, the default is to allow + recursive queries on all addresses. + + + + + + allow-update + + + Specifies which hosts are allowed to + submit Dynamic DNS updates for master zones. The default is + to deny + updates from all hosts. Note that allowing updates based + on the requestor's IP address is insecure; see + for details. + + + + + + allow-update-forwarding + + + Specifies which hosts are allowed to + submit Dynamic DNS updates to slave zones to be forwarded to + the + master. The default is { none; }, + which + means that no update forwarding will be performed. To + enable + update forwarding, specify + allow-update-forwarding { any; };. + Specifying values other than { none; } or + { any; } is usually + counterproductive, since + the responsibility for update access control should rest + with the + master server, not the slaves. + + + Note that enabling the update forwarding feature on a slave + server + may expose master servers relying on insecure IP address + based + access control to attacks; see + for more details. + + + + + + allow-v6-synthesis + + + This option was introduced for the smooth transition from + AAAA + to A6 and from "nibble labels" to binary labels. + However, since both A6 and binary labels were then + deprecated, + this option was also deprecated. + It is now ignored with some warning messages. + + + + + + allow-transfer + + + Specifies which hosts are allowed to + receive zone transfers from the server. allow-transfer may + also be specified in the zone + statement, in which + case it overrides the options allow-transfer statement. + If not specified, the default is to allow transfers to all + hosts. + + + + + + blackhole + + + 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. + + + + + + filter-aaaa + + + Specifies a list of addresses to which + filter-aaaa-on-v4 + is applies. The default is any. + + + + + + resolver-query-timeout + + + The amount of time the resolver will spend attempting + to resolve a recursive query before failing. The default + and minimum is 10 and the maximum is + 30. Setting it to 0 + will result in the default being used. + + + + + + + + + Interfaces - returned by an "example.com" server will be accepted. + 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. + 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; }; + + - In the address_match_list of the - deny-answer-addresses option, only - ip_addr - and ip_prefix - are meaningful; - any key_id will be silently ignored. + 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 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. + If no listen-on is specified, the + server will listen on port 53 on all IPv4 interfaces. - 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 - an alias name within your own domain. - A naive web browser or script could then serve as an - unintended proxy, allowing the attacker - to get access to an internal node of your local network - that couldn't be externally accessed otherwise. - See the paper available at - - http://portal.acm.org/citation.cfm?id=1315245.1315298 - - for more details about the attacks. + 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. - 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: + When { any; } is + specified + as the address_match_list for the + listen-on-v6 option, + the server does not bind a separate socket to each IPv6 interface + address as it does for IPv4 if the operating system has enough API + support for IPv6 (specifically if it conforms to RFC 3493 and RFC + 3542). + Instead, it listens on the IPv6 wildcard address. + If the system only has incomplete API support for IPv6, however, + the behavior is the same as that for IPv4. -deny-answer-addresses { 192.0.2.0/24; } except-from { "example.net"; }; -deny-answer-aliases { "example.net"; }; - + + A list of particular IPv6 addresses can also be specified, in + which case + the server listens on a separate socket for each specified + address, + regardless of whether the desired API is supported by the system. + - 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: + Multiple listen-on-v6 options can + be used. + For example, -attacker.example.com. A 192.0.2.1 +listen-on-v6 { any; }; +listen-on-v6 port 1234 { !2001:db8::/32; any; }; + - 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. + 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.) - 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 + To make the server not listen on any IPv6 address, use -www.example.net. A 192.0.2.2 +listen-on-v6 { none; }; + + + + + Query Address - it will be accepted since the owner name "www.example.net" - matches the except-from element, - "example.net". + 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 + IPv6, there is a separate query-source-v6 option. + If address is * (asterisk) or is omitted, + a wildcard IP address (INADDR_ANY) + will be used. - 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 - from the DNS point of view. - It might actually be provided for a legitimate purpose, - such as for debugging. - As long as the mapping is provided by the correct owner, - it is not possible or does not make sense to detect - whether the intent of the mapping is legitimate or not - within the DNS. - The "rebinding" attack must primarily be protected at the - application that uses the DNS. - For a large site, however, it may be difficult to protect - all possible applications at once. - This filtering feature is provided only to help such an - operational environment; - it is generally discouraged to turn it on unless you are - very sure you have no other choice and the attack is a - real threat for your applications. + 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. + The port range(s) is that specified in + the use-v4-udp-ports (for IPv4) + and use-v6-udp-ports (for IPv6) + options, excluding the ranges specified in + the avoid-v4-udp-ports + and avoid-v6-udp-ports options, respectively. - 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 - applications conventionally rely on a DNS mapping from - some name to such an address. - Filtering out DNS records containing this address - spuriously can break such applications. + The defaults of the query-source and + query-source-v6 options + are: - - - Response Policy Zone (RPZ) Rewriting +query-source address * port *; +query-source-v6 address * port *; + + - BIND 9 includes a limited - mechanism to modify DNS responses for requests - analogous to email anti-spam DNS blacklists. - Responses can be changed to deny the existence of domains(NXDOMAIN), - deny the existence of IP addresses for domains (NODATA), - or contain other IP addresses or data. + If use-v4-udp-ports or + use-v6-udp-ports is unspecified, + named will check if the operating + system provides a programming interface to retrieve the + system's default range for ephemeral ports. + If such an interface is available, + 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 + (14 bits of entropy). + Note also that the system's default range when used may be + too small for this purpose, and that the range may even be + changed while named is running; the new + range will automatically be applied when named + is reloaded. + It is encouraged to + configure use-v4-udp-ports and + use-v6-udp-ports explicitly so that the + ranges are sufficiently large and are reasonably + independent from the ranges used by other applications. - 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. - Response policy zones are ordinary DNS zones containing RRsets - that can be queried normally if allowed. - It is usually best to restrict those queries with something like - allow-query { localhost; };. + Note: the operational configuration + where named runs may prohibit the use + of some ports. For example, UNIX systems will not allow + named running without a root privilege + to use ports less than 1024. + If such ports are included in the specified (or detected) + set of query ports, the corresponding query attempts will + fail, resulting in resolution failures or delay. + It is therefore important to configure the set of ports + that can be safely used in the expected operational environment. - Five policy triggers can be encoded in RPZ records. - - - RPZ-CLIENT-IP - - - IP records are triggered by the IP address of the - DNS client. - Client IP address triggers are encoded in records that have - owner names that are subdomains of - rpz-client-ip relativized to the - policy zone origin name - and encode an address or address block. - IPv4 addresses are represented as - prefixlength.B4.B3.B2.B1.rpz-ip. - The IPv4 prefix length must be between 1 and 32. - All four bytes, B4, B3, B2, and B1, must be present. - 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-ip. - Each of W8,...,W1 is a one to four digit hexadecimal number - representing 16 bits of the IPv6 address as in the standard - text representation of IPv6 addresses, - but reversed as in IN-ADDR.ARPA. - All 8 words must be present except when one set of consecutive - zero words is replaced with .zz. - analogous to double colons (::) in standard IPv6 text - encodings. - The IPv6 prefix length must be between 64 and 128. - - - - - - QNAME - - - 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. - - - - - - RPZ-IP - - - 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. - - - - - - RPZ-NSDNAME - - - 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. - They are encoded as subdomains of - rpz-nsdname relativized - to the RPZ origin name. - NSIP triggers match IP addresses in A and - AAAA RRsets for domains that can be checked against NSDNAME - policy records. - - - + The defaults of the avoid-v4-udp-ports and + avoid-v6-udp-ports options + are: + - - RPZ-NSIP - - - NSIP triggers are encoded like IP triggers except as - subdomains of rpz-nsip. - NSDNAME and NSIP triggers are checked only for names with at - least min-ns-dots dots. - The default value of min-ns-dots is 1 to - exclude top level domains. - - - - - +avoid-v4-udp-ports {}; +avoid-v6-udp-ports {}; + - 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 - policy record, a single record encoding an action (other than - DISABLED actions) must be chosen. - Triggers or the records that encode them are chosen for the - rewriting in the following order: - - Choose the triggered record in the zone that appears - first in the response-policy option. - - Prefer CLIENT-IP to QNAME to IP to NSDNAME to NSIP - triggers in a single zone. - - Among NSDNAME triggers, prefer the - trigger that matches the smallest name under the DNSSEC ordering. + Note: BIND 9.5.0 introduced + the use-queryport-pool + option to support a pool of such random ports, but this + option is now obsolete because reusing the same ports in + the pool may not be sufficiently secure. + For the same reason, it is generally strongly discouraged to + specify a particular port for the + query-source or + query-source-v6 options; + it implicitly disables the use of randomized port numbers. + + + + + use-queryport-pool + + + This option is obsolete. + - Among IP or NSIP triggers, prefer the trigger - with the longest prefix. + + + + queryport-pool-ports + + + This option is obsolete. + - Among triggers with the same prefex length, - prefer the IP or NSIP trigger that matches - the smallest IP address. + + + + queryport-pool-updateinterval + + + 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. + + + + + Zone Transfers - 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. + 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. - - RPZ record sets are any types of DNS record except - DNAME or DNSSEC that encode actions or responses to - individual queries. - Any of the policies can be used with any of the triggers. - For example, while the TCP-only policy is - commonly used with client-IP triggers, - it cn be used with any type of trigger to force the use of - TCP for responses with owner names in a zone. - - - PASSTHRU - - - 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. - - - + - - DROP - - - 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. - - - + + also-notify + + + Defines a global list of IP addresses of name servers + that are also sent NOTIFY messages whenever a fresh copy of + the + zone is loaded, in addition to the servers listed in the + zone's NS records. + This helps to ensure that copies of the zones will + quickly converge on stealth servers. + Optionally, a port may be specified with each + also-notify address to send + the notify messages to a port other than the + default of 53. + An optional TSIG key can also be specified with each + address to cause the notify messages to be signed; this + can be useful when sending notifies to multiple views. + 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 + the options also-notify + statement. When a zone notify + statement + is set to no, the IP + addresses in the global also-notify list will + not be sent NOTIFY messages for that zone. The default is + the empty + list (no global notification list). + + + - - TCP-Only - - - 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. - - - + + max-transfer-time-in + + + 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). + + + - - NXDOMAIN - - - The domain undefined response is encoded - by a CNAME whose target is the root domain (.) - - - + + max-transfer-idle-in + + + 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). + + + - - NODATA - - - 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=1. - - - + + max-transfer-time-out + + + 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). + + + - - Local Data - - - A set of ordinary DNS records can be used to answer queries. - Queries for record types not the set are answered with - NODATA. - + + max-transfer-idle-out + + + 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). + + + - - 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 astrisk (*) - has been replaced with the query name. - The purpose for this special form is query logging in the - walled garden's authority DNS server. - - - - - + + serial-query-rate + + + Slave servers will periodically query master + servers to find out if zone serial numbers have + changed. Each such query uses a minute amount of + the slave server's network bandwidth. To limit + the amount of bandwidth used, BIND 9 limits the + rate at which queries are sent. The value of the + serial-query-rate option, an + integer, is the maximum number of queries sent + per second. The default is 20. + + + In addition to controlling the rate SOA refresh + queries are issued at + serial-query-rate also controls + the rate at which NOTIFY messages are sent from + both master and slave zones. + + + - - All of the actions specified in all of the individual records - in a policy zone - can be overridden with a policy clause in the - response-policy option. - An organization using a policy zone provided by another - organization might use this mechanism to redirect domains - to its own walled garden. - - - GIVEN - - The placeholder policy says "do not override but - perform the action specified in the zone." - - - + + serial-queries + + + In BIND 8, the serial-queries + option + set the maximum number of concurrent serial number queries + allowed to be outstanding at any given time. + BIND 9 does not limit the number of outstanding + serial queries and ignores the serial-queries option. + Instead, it limits the rate at which the queries are sent + as defined using the serial-query-rate option. + + + - - DISABLED - + + transfer-format + + + + Zone transfers can be sent using two different formats, + one-answer and + many-answers. + The transfer-format option is used + on the master server to determine which format it sends. + one-answer uses one DNS message per + resource record transferred. + many-answers packs as many resource + records as possible into a message. + many-answers is more efficient, but is + only supported by relatively new slave servers, + such as BIND 9, BIND + 8.x and BIND 4.9.5 onwards. + The many-answers format is also supported by + recent Microsoft Windows nameservers. + The default is many-answers. + transfer-format may be overridden on a + per-server basis by using the server + statement. + + + + + + + transfers-in + + + 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. + + + + + + transfers-out + + + 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. + + + + + + transfers-per-ns + + + The maximum number of inbound zone transfers + that can be concurrently transferring from a given remote + name server. + The default value is 2. + Increasing transfers-per-ns + may + speed up the convergence of slave zones, but it also may + increase + the load on the remote 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 + source IPv4 address, and optionally the UDP port, + used for the refresh queries and forwarded dynamic + updates. If not set, it defaults to a system + controlled value which will usually be the address + of the interface "closest to" the remote end. This + address must appear in the remote end's + allow-transfer option for the + zone being transferred, if one is specified. This + statement sets the + transfer-source for all zones, + but can be overridden on a per-view or per-zone + basis by including a + transfer-source statement within + the view or + zone block in the configuration + file. + + - The testing override policy causes policy zone records to do - nothing but log what they would have done if the - policy zone were not disabled. - The response to the DNS query will be written (or not) - according to any triggered policy records that are not - disabled. - Disabled policy zones should appear first, - because they will often not be logged - if a higher precedence trigger is found first. + Solaris 2.5.1 and earlier does not support setting the + source address for TCP sockets. - - + + + - - PASSTHRU, - DROP, - TCP-Only, - NXDOMAIN, - and - NODATA - + + transfer-source-v6 + + + The same as transfer-source, + except zone transfers are performed using IPv6. + + + + + + alt-transfer-source + + + 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 + to be used, you should set + use-alt-transfer-source + appropriately and you should not depend upon + getting an answer back to the first refresh + query. + + + + + + alt-transfer-source-v6 + + + An alternate transfer source if the one listed in + transfer-source-v6 fails and + use-alt-transfer-source is + set. + + + + + + use-alt-transfer-source + + + Use the alternate transfer sources or not. If views are + specified this defaults to no + otherwise it defaults to + yes (for BIND 8 + compatibility). + + + + + + notify-source + + 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 + server's masters zone clause or + in an allow-notify clause. This + statement sets the notify-source + for all zones, but can be overridden on a per-zone or + per-view basis by including a + notify-source statement within + the zone or + view block in the configuration + file. + + - override with the corresponding per-record policy. + Solaris 2.5.1 and earlier does not support setting the + source address for TCP sockets. - - + + + - - CNAME domain - - - causes all RPZ policy records to act as if they were - "cname domain" records. - - - - - + + notify-source-v6 + + + Like notify-source, + but applies to notify messages sent to IPv6 addresses. + + + - - 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 - all response policy zones in a view - with a recursive-only no clause. - This feature is useful for serving the same zone files - both inside and outside an RFC 1918 cloud and using RPZ to - 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 - zone (not the response policy zone). This default can be - changed for all response policy zones in a view with a - break-dnssec yes clause. In that case, RPZ - actions are applied regardless of DNSSEC. The name of the - clause option reflects the fact that results rewritten by RPZ - actions cannot verify. - + + + UDP Port Lists - 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. - However, not resolving the requested - name can leak the fact that response policy rewriting is in use - and that the name is listed in a policy zone to operators of - servers for listed names. To prevent that information leak, by - default any recursion needed for a request is done before any - policy triggers are considered. Because listed domains often - have slow authoritative servers, this default behavior can cost - significant time. - The qname-wait-recurse no option - overrides that default behavior when recursion cannot - change a non-error response. - The option does not affect QNAME or client-IP triggers - in policy zones listed - after other zones containing IP, NSIP and NSDNAME triggers, because - those may depend on the A, AAAA, and NS records that would be - found during recursive resolution. It also does not affect - DNSSEC requests (DO=1) unless break-dnssec yes - is in use, because the response would depend on whether or not - RRSIG records were found during resolution. - The option can cause appear to rewrite error responses - such as SERVFAIL when no recursion is done to discover problems - at the authoritative server. + use-v4-udp-ports, + avoid-v4-udp-ports, + use-v6-udp-ports, and + avoid-v6-udp-ports + specify a list of IPv4 and IPv6 UDP ports that will be + used or not used as source ports for UDP messages. + See about how the + 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 + port that is blocked by your firewall or a port that is + used by other applications; + if a query went out with a source port blocked by a + firewall, the + answer would not get by the firewall and the name server would + have to query again. + Note: the desired range can also be represented only with + use-v4-udp-ports and + use-v6-udp-ports, and the + avoid- options are redundant in that + sense; they are provided for backward compatibility and + to possibly simplify the port specification. + + + + + Operating System Resource Limits + - 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. - The max-policy-ttl clause changes that - maximum from its default of 5. + 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 + 1073741824 to specify a limit of + one + gigabyte. unlimited requests + unlimited use, or the + maximum available amount. default + uses the limit + that was in force when the server was started. See the description + of size_spec in . - 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 -@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h) - NS LOCALHOST. + The following options set operating system resource limits for + the name server process. Some operating systems don't support + some or + any of the limits. On such systems, a warning will be issued if + the + unsupported limit is used. + -; QNAME policy records. There are no periods (.) after the owner names. -nxdomain.domain.com CNAME . ; NXDOMAIN policy -*.nxdomain.domain.com CNAME . ; NXDOMAIN policy -nodata.domain.com CNAME *. ; NODATA policy -*.nodata.domain.com CNAME *. ; NODATA policy -bad.domain.com A 10.0.0.1 ; redirect to a walled garden - AAAA 2001:2::1 -bzone.domain.com CNAME garden.example.com. + -; do not rewrite (PASSTHRU) OK.DOMAIN.COM -ok.domain.com CNAME rpz-passthru. + + coresize + + + The maximum size of a core dump. The default + is default. + + + -; redirect x.bzone.domain.com to x.bzone.domain.com.garden.example.com -*.bzone.domain.com CNAME *.garden.example.com. + + datasize + + + The maximum amount of data memory the server + may use. The default is default. + This is a hard limit on server memory usage. + If the server attempts to allocate memory in excess of this + limit, the allocation will fail, which may in turn leave + the server unable to perform DNS service. Therefore, + this option is rarely useful as a way of limiting the + amount of memory used by the server, but it can be used + to raise an operating system data size limit that is + too small by default. If you wish to limit the amount + of memory used by the server, use the + max-cache-size and + recursive-clients + options instead. + + + + + + files + + + The maximum number of files the server + may have open concurrently. The default is unlimited. + + + + + stacksize + + + The maximum amount of stack memory the server + may use. The default is default. + + + -; IP policy records that rewrite all responses containing A records in 127/8 -; except 127.0.0.1 -8.0.0.0.127.rpz-ip CNAME . -32.1.0.0.127.rpz-ip CNAME rpz-passthru. + -; NSDNAME and NSIP policy records -ns.domain.com.rpz-nsdname CNAME . -48.zz.2.2001.rpz-nsip CNAME . + -; blacklist and whitelist some DNS clients -112.zz.2001.rpz-client-ip CNAME rpz-drop. -8.0.0.0.127.rpz-client-ip CNAME rpz-drop. + + Server Resource Limits -; force some DNS clients and responses in the example.com zone to TCP -16.0.0.1.10.rpz-client-ip CNAME rpz-tcp-only. -example.com CNAME rpz-tcp-only. -*.example.com CNAME rpz-tcp-only. + + The following options set limits on the server's + resource consumption that are enforced internally by the + server rather than the operating system. + - - - RPZ can affect server performance. - Each configured response policy zone requires the server to - perform one to four additional database lookups before a - query can be answered. - For example, a DNS server with four policy zones, each with all - four kinds of response triggers, QNAME, IP, NSIP, and - NSDNAME, requires a total of 17 times as many database - lookups as a similar DNS server with no response policy zones. - A BIND9 server with adequate memory and one - response policy zone with QNAME and IP triggers might achieve a - maximum queries-per-second rate about 20% lower. - 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. - - + + + + max-ixfr-log-size + + + This option is obsolete; it is accepted + and ignored for BIND 8 compatibility. The option + max-journal-size performs a + similar function in BIND 9. + + + + + + max-journal-size + + + Sets a maximum size for each journal file + (see ). When the journal file + approaches + the specified size, some of the oldest transactions in the + journal + will be automatically removed. The largest permitted + value is 2 gigabytes. The default is + unlimited, which also + means 2 gigabytes. + This may also be set on a per-zone basis. + + + + + + host-statistics-max + + + In BIND 8, specifies the maximum number of host statistics + entries to be kept. + Not implemented in BIND 9. + + + + + + recursive-clients + + + The maximum number of simultaneous recursive lookups + the server will perform on behalf of clients. The default + is + 1000. Because each recursing + client uses a fair + bit of memory, on the order of 20 kilobytes, the value of + the + recursive-clients option may + have to be decreased + on hosts with limited memory. + + + + + + tcp-clients + + + The maximum number of simultaneous client TCP + connections that the server will accept. + The default is 100. + + + + + + reserved-sockets + + + 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, tcp-clients as well as + to provide room for outgoing TCP queries and incoming zone + transfers. The default is 512. + The minimum value is 128 and the + maximum value is 128 less than + maxsockets (-S). This option may be removed in the future. + + + This option has little effect on Windows. + + + + + + max-cache-size + + + The maximum amount of memory to use for the + server's cache, in bytes. + When the amount of data in the cache + reaches this limit, the server will cause records to + expire prematurely based on an LRU based strategy so + that the limit is not exceeded. + The keyword unlimited, + or the value 0, will place no limit on cache size; + records will be purged from the cache only when their + TTLs expire. + Any positive values less than 2MB will be ignored + and reset to 2MB. + In a server with multiple views, the limit applies + separately to the cache of each view. + The default is unlimited. + + + + + + tcp-listen-queue + + + The listen queue depth. The default and minimum is 10. + If the kernel supports the accept filter "dataready" this + also controls how + many TCP connections that will be queued in kernel space + waiting for + some data before being passed to accept. Nonzero values + 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. + + + + + + + - Response Rate Limiting + Periodic Task Intervals + + + + + cleaning-interval + + + This interval is effectively obsolete. Previously, + the server would remove expired resource records + from the cache every cleaning-interval minutes. + BIND 9 now manages cache + memory in a more sophisticated manner and does not + rely on the periodic cleaning any more. + Specifying this option therefore has no effect on + the server's behavior. + + + + + + heartbeat-interval + + + The server will perform zone maintenance tasks + for all zones marked as dialup whenever this + interval expires. The default is 60 minutes. Reasonable + values are up + to 1 day (1440 minutes). The maximum value is 28 days + (40320 minutes). + If set to 0, no zone maintenance for these zones will occur. + + + + + + interface-interval + + + The server will scan the network interface list + every interface-interval + minutes. The default + is 60 minutes. The maximum value is 28 days (40320 minutes). + If set to 0, interface scanning will only occur when + the configuration file is loaded. After the scan, the + server will + begin listening for queries on any newly discovered + interfaces (provided they are allowed by the + listen-on configuration), and + will + stop listening on interfaces that have gone away. + + + + + + statistics-interval + + + Name server statistics will be logged + every statistics-interval + minutes. The default is + 60. The maximum value is 28 days (40320 minutes). + If set to 0, no statistics will be logged. + + + Not yet implemented in + BIND 9. + + + + + + + + + + + Topology + - Excessive almost identical UDP responses - can be controlled by configuring a - rate-limit clause in an - options or view statement. - This mechanism keeps authoritative BIND 9 from being used - in amplifying reflection denial of service (DoS) attacks. - Short truncated (TC=1) responses can be sent to provide - rate-limited responses to legitimate clients within - a range of forged, attacked IP addresses. - Legitimate clients react to dropped or truncated response - by retrying with UDP or with TCP respectively. + All other things being equal, when the server chooses a name + server + to query from a list of name servers, it prefers the one that is + topologically closest to itself. The topology statement + takes an address_match_list and + interprets it + in a special way. Each top-level list element is assigned a + distance. + Non-negated elements get a distance based on their position in the + list, where the closer the match is to the start of the list, the + shorter the distance is between it and the server. A negated match + will be assigned the maximum distance from the server. If there + is no match, the address will get a distance which is further than + any non-negated list element, and closer than any negated element. + For example, +topology { + 10/8; + !1.2.3/24; + { 1.2/16; 3/8; }; +}; + - 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 - HTTP clients (web browsers) that repeatedly request the - same domains. - When possible, closing "open" recursive servers is better. + will prefer servers on network 10 the most, followed by hosts + on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the + exception of hosts on network 1.2.3 (netmask 255.255.255.0), which + is preferred least of all. + + + The default topology is + topology { localhost; localnets; }; + + + + + The topology option + is not implemented in BIND 9. + + + + + + + The <command>sortlist</command> Statement + - 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 - of credits every second. - A prospective response debits its account by one. - Responses are dropped or truncated - while the account is negative. - Responses are tracked within a rolling window of time - which defaults to 15 seconds, but can be configured with - the window option to any value from - 1 to 3600 seconds (1 hour). - The account cannot become more positive than - the per-second limit - or more negative than window - times the per-second limit. - When the specified number of credits for a class of - responses is set to 0, those responses are not rate limited. + The response to a DNS query may consist of multiple resource + records (RRs) forming a resource records set (RRset). + The name server will normally return the + RRs within the RRset in an indeterminate order + (but see the rrset-order + statement in ). + The client resolver code should rearrange the RRs as appropriate, + that is, using any addresses on the local net in preference to + other addresses. + However, not all resolvers can do this or are correctly + configured. + When a client is using a local server, the sorting can be performed + in the server, based on the client's address. This only requires + configuring the name servers, not all the clients. - 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 - single client. - The prefix lengths of addresses blocks are - specified with ipv4-prefix-length (default 24) - and ipv6-prefix-length (default 56). + The sortlist statement (see below) + takes + an address_match_list and + interprets it even + more specifically than the topology + statement + does (). + Each top level statement in the sortlist must + itself be an explicit address_match_list with + one or two elements. The first element (which may be an IP + address, + an IP prefix, an ACL name or a nested address_match_list) + of each top level list is checked against the source address of + the query until a match is found. - - 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 - (default 0 or no limit). - All empty (NODATA) responses for a valid domain, - regardless of query type, are identical. - Responses in the NODATA class are limited by - nodata-per-second - (default responses-per-second). - Requests for any and all undefined subdomains of a given - valid domain result in NXDOMAIN errors, and are identical - regardless of query type. - They are limited by nxdomain-per-second - (default responses-per-second). - This controls some attacks using random names, but - can be relaxed or turned off (set to 0) - on servers that expect many legitimate - NXDOMAIN responses, such as from anti-spam blacklists. - Referrals or delegations to the server of a given - domain are identical and are limited by - referrals-per-second - (default responses-per-second). + 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 select the + address + in the response to move to the beginning of the response. If the + statement is a list of two elements, then the second element is + treated the same as the address_match_list in + a topology statement. Each top + level element + is assigned a distance and the address in the response with the + minimum + distance is moved to the beginning of the response. - - 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. + 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 preferred are + addresses + on the 192.168.1/24 network, and after that either the + 192.168.2/24 + or + 192.168.3/24 network with no preference shown between these two + networks. Queries received from a host on the 192.168.1/24 network + will prefer other addresses on that network to the 192.168.2/24 + and + 192.168.3/24 networks. Queries received from a host on the + 192.168.4/24 + or 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 + { localhost; + { localnets; + 192.168.1/24; + { 192.168.2/24; 192.168.3/24; }; }; }; + // IF on class C 192.168.1 THEN use .1, or .2 or .3 + { 192.168.1/24; + { 192.168.1/24; + { 192.168.2/24; 192.168.3/24; }; }; }; + // IF on class C 192.168.2 THEN use .2, or .1 or .3 + { 192.168.2/24; + { 192.168.2/24; + { 192.168.1/24; 192.168.3/24; }; }; }; + // IF on class C 192.168.3 THEN use .3, or .1 or .2 + { 192.168.3/24; + { 192.168.3/24; + { 192.168.1/24; 192.168.2/24; }; }; }; + // IF .4 or .5 THEN prefer that net + { { 192.168.4/24; 192.168.5/24; }; + }; +}; + - 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). - This controls attacks using invalid requests or distant, - broken authoritative servers. - By default the limit on errors is the same as the - responses-per-second value, - but it can be set separately with - errors-per-second. + The following example will give reasonable behavior for the + local host and hosts on directly connected networks. It is similar + to the behavior of the address sort in BIND 4.9.x. Responses sent + to queries from the local host will favor any of the directly + connected + networks. Responses sent to queries from any other hosts on a + directly + connected network will prefer addresses on that same network. + Responses + to other queries will not be sorted. +sortlist { + { localhost; localnets; }; + { localnets; }; +}; + + + + + RRset Ordering - Many attacks using DNS involve UDP requests with forged source - addresses. - Rate limiting prevents the use of BIND 9 to flood a network - with responses to requests with forged source addresses, - but could let a third party block responses to legitimate requests. - There is a mechanism that can answer some legitimate - requests from a client whose address is being forged in a flood. - Setting slip to 2 (its default) causes every - other UDP request to be answered with a small truncated (TC=1) + When multiple records are returned in an answer it may be + useful to configure the order of the records placed into the response. - The small size and reduced frequency, and so lack of - amplification, of "slipped" responses make them unattractive - for reflection DoS attacks. - slip must be between 0 and 10. - A value of 0 does not "slip": - no truncated responses are sent due to rate limiting, - all responses are dropped. - A value of 1 causes every response to slip; - values between 2 and 10 cause every n'th response to slip. - Some error responses including REFUSED and SERVFAIL - cannot be replaced with truncated responses and are instead - leaked at the slip rate. + The rrset-order statement permits + configuration + of the ordering of the records in a multiple record response. + See also the sortlist statement, + . - (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 - against forged responses is for authoritative operators - to sign their zones using DNSSEC and for resolver operators - to validate the responses. When this is not an option, - operators who are more concerned with response integrity - than with flood mitigation may consider setting - slip to 1, causing all rate-limited - responses to be truncated rather than dropped. This reduces - the effectiveness of rate-limiting against reflection attacks.) + An order_spec is defined as + follows: - - When the approximate query per second rate exceeds - the qps-scale value, - then the responses-per-second, - errors-per-second, - nxdomains-per-second and - all-per-second values are reduced by the - ratio of the current rate to the qps-scale value. - This feature can tighten defenses during attacks. - For example, with - qps-scale 250; responses-per-second 20; and - a total query rate of 1000 queries/second for all queries from - all DNS clients including via TCP, - then the effective responses/second limit changes to - (250/1000)*20 or 5. - Responses sent via TCP are not limited - but are counted to compute the query per second rate. + class class_name + type type_name + name "domain_name" + order ordering - - Communities of DNS clients can be given their own parameters or no - rate limiting by putting - rate-limit statements in view - statements instead of the global option - statement. - A rate-limit statement in a view replaces, - rather than supplementing, a rate-limit - statement among the main options. - DNS clients within a view can be exempted from rate limits - with the exempt-clients clause. + 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). - - UDP responses of all kinds can be limited with the - all-per-second phrase. - This rate limiting is unlike the rate limiting provided by - responses-per-second, - errors-per-second, and - nxdomains-per-second on a DNS server - which are often invisible to the victim of a DNS reflection attack. - Unless the forged requests of the attack are the same as the - legitimate requests of the victim, the victim's requests are - not affected. - Responses affected by an all-per-second limit - are always dropped; the slip value has no - effect. - An all-per-second limit should be - at least 4 times as large as the other limits, - because single DNS clients often send bursts of legitimate - requests. - For example, the receipt of a single mail message can prompt - requests from an SMTP server for NS, PTR, A, and AAAA records - as the incoming SMTP/TCP/IP connection is considered. - The SMTP server can need additional NS, A, AAAA, MX, TXT, and SPF - records as it considers the STMP Mail From - command. - Web browsers often repeatedly resolve the same names that - are repeated in HTML <IMG> tags in a page. - All-per-second is similar to the - rate limiting offered by firewalls but often inferior. - Attacks that justify ignoring the - contents of DNS responses are likely to be attacks on the - DNS server itself. - They usually should be discarded before the DNS server - spends resources making TCP connections or parsing DNS requests, - but that rate limiting must be done before the - DNS server sees the requests. + The legal values for ordering are: - + + + + + + + + fixed + + + + Records are returned in the order they + are defined in the zone file. + + + + + + random + + + + Records are returned in some random order. + + + + + + cyclic + + + + Records are returned in a cyclic round-robin order. + + + If BIND is configured with the + "--enable-fixed-rrset" option at compile time, then + the initial ordering of the RRset will match the + one specified in the zone file. + + + + + + - 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. - The table needs approximately as many entries as the number - of requests received per second. - The default is 20,000. - To reduce the cold start of growing the table, - min-table-size (default 500) - can set the minimum table size. - Enable rate-limit category logging to monitor - expansions of the table and inform - choices for the initial and maximum table size. + For example: +rrset-order { + class IN type A name "host.example.com" order random; + order cyclic; +}; + + - Use log-only yes to test rate limiting parameters - without actually dropping any requests. + 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. - - 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. - + If multiple rrset-order statements + appear, they are not combined — the last one applies. + + + By default, all 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. + + - - - <command>server</command> Statement Grammar + + Tuning -server ip_addr[/prefixlen] { - bogus yes_or_no ; - provide-ixfr yes_or_no ; - request-ixfr yes_or_no ; - edns yes_or_no ; - edns-udp-size number ; - max-udp-size number ; - transfers number ; - transfer-format ( one-answer | many-answers ) ; ] - keys { string ; string ; ... } ; - transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; - transfer-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; - notify-source (ip4_addr | *) port ip_port dscp ip_dscp ; - notify-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; - query-source address ( ip_addr | * ) - port ( ip_port | * ) dscp ip_dscp ; - query-source-v6 address ( ip_addr | * ) - port ( ip_port | * ) dscp ip_dscp ; - use-queryport-pool yes_or_no; - queryport-pool-ports number; - queryport-pool-updateinterval number; -}; - + - - - - <command>server</command> Statement Definition and - Usage - - - The server statement defines - characteristics - to be associated with a remote name server. If a prefix length is - specified, then a range of servers is covered. Only the most - specific - 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 - statement. - If a view statement contains - one or more server statements, only - those - apply to the view and any top-level ones are ignored. - If a view contains no server - statements, - any top-level server statements are - 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 - incremental - zone transfer when the given remote server, a slave, requests it. - If set to yes, incremental transfer - will be provided - whenever possible. If set to no, - all transfers - to the remote server will be non-incremental. If not set, the - value - of the provide-ixfr option in the - 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 - transfers from the given remote server, a master. If not set, the - value of the request-ixfr option in - the view or global options block is used as a default. It may - 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 - which servers support IXFR and which ones do not; the global - default - of yes should always work. - The purpose of the provide-ixfr and - request-ixfr clauses is - to make it possible to disable the use of IXFR even when both - master - 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 edns clause determines whether - the local server will attempt to use EDNS when communicating - with the remote server. The default is yes. - + + lame-ttl + + + 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). + - - The edns-udp-size option sets the EDNS UDP size - that is advertised by named when querying the remote server. - Valid values are 512 to 4096 bytes (values outside this range will be - silently adjusted). This option is useful when you wish to - advertises a different value to this server than the value you - advertise globally, for example, when there is a firewall at the - remote site that is blocking large replies. - + + Lame-ttl also controls the amount of time DNSSEC + validation failures are cached. There is a minimum + of 30 seconds applied to bad cache entries if the + lame-ttl is set to less than 30 seconds. + - - The max-udp-size option sets the - maximum EDNS UDP message size named will send. Valid - values are 512 to 4096 bytes (values outside this range will - be silently adjusted). This option is useful when you - know that there is a firewall that is blocking large - replies from named. - - - - 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 - more efficient, but is only known to be understood by BIND 9, BIND - 8.x, and patched versions of BIND - 4.9.5. You can specify which method - to use for a server with the transfer-format option. - If transfer-format is not - specified, the transfer-format - specified - by the options statement will be - used. - - - 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, ) - when talking to the remote server. - When a request is sent to the remote server, a request signature - will be generated using the key specified here and appended to the - message. A request originating from the remote server is not - required - to be signed by this key. - - - - Although the grammar of the keys - clause - allows for multiple keys, only a single key per server is - currently - supported. - - - - The transfer-source and - transfer-source-v6 clauses specify - the IPv4 and IPv6 source - address to be used for zone transfer with the remote server, - respectively. - For an IPv4 remote server, only transfer-source can - be specified. - Similarly, for an IPv6 remote server, only - transfer-source-v6 can be - specified. - For more details, see the description of - transfer-source and - transfer-source-v6 in - . - - - - The notify-source and - notify-source-v6 clauses specify the - IPv4 and IPv6 source address to be used for notify - messages sent to remote servers, respectively. For an - IPv4 remote server, only notify-source - 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 - sent to remote servers, respectively. For an IPv4 - remote server, only query-source can - be specified. Similarly, for an IPv6 remote server, - only query-source-v6 can be specified. - + + - + + max-ncache-ttl + + + To reduce network traffic and increase performance, + the server stores negative answers. max-ncache-ttl is + used to set a maximum retention time for these answers in + the server + in seconds. The default + max-ncache-ttl is 10800 seconds (3 hours). + max-ncache-ttl cannot exceed + 7 days and will + be silently truncated to 7 days if set to a greater value. + + + - - <command>statistics-channels</command> Statement Grammar + + max-cache-ttl + + + Sets the maximum time for which the server will + cache ordinary (positive) answers. The default is + one week (7 days). + 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. + + + -statistics-channels { - [ inet ( ip_addr | * ) [ port ip_port ] - [ allow { address_match_list } ]; ] - [ inet ...; ] -}; - - + + min-roots + + + The minimum number of root servers that + is required for a request for the root servers to be + accepted. The default + is 2. + + + + Not implemented in BIND 9. + + + + - - <command>statistics-channels</command> Statement Definition and - Usage + + sig-validity-interval + + + Specifies the number of days into the future when + DNSSEC signatures automatically generated as a + result of dynamic updates () will expire. There + is an optional second field which specifies how + long before expiry that the signatures will be + regenerated. If not specified, the signatures will + be regenerated at 1/4 of base interval. The second + field is specified in days if the base interval is + greater than 7 days otherwise it is specified in hours. + The default base interval is 30 days + 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 + should be, at least, several multiples of the SOA + expire interval to allow for reasonable interaction + between the various timer and expiry dates. + + + - - The statistics-channels statement - declares communication channels to be used by system - administrators to get access to statistics information of - the name server. - + + sig-signing-nodes + + + Specify the maximum number of nodes to be + examined in each quantum when signing a zone with + a new DNSKEY. The default is + 100. + + + - - This statement intends to be flexible to support multiple - communication protocols in the future, but currently only - HTTP access is supported. - It requires that BIND 9 be compiled with libxml2 and/or - json-c (also known as libjson0); the - statistics-channels statement is - still accepted even if it is built without the library, - but any HTTP access will fail with an error. - + + sig-signing-signatures + + + Specify a threshold number of signatures that + will terminate processing a quantum when signing + a zone with a new DNSKEY. The default is + 10. + + + - - 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 - address. An ip_addr of * - (asterisk) is - interpreted as the IPv4 wildcard address; connections will be - accepted on any of the system's IPv4 addresses. - To listen on the IPv6 wildcard address, - use an ip_addr of ::. - + + sig-signing-type + + + Specify a private RDATA type to be used when generating + key signing records. The default is + 65534. + + + It is expected that this parameter may be removed + in a future version once there is a standard type. + + + These records can be removed from the zone once named + has completed signing the zone with the matching key + using nsupdate or + rndc signing -clear. + rndc signing -clear is the only supported + way to remove these records from + inline-signing zones. + + + - - If no port is specified, port 80 is used for HTTP channels. - The asterisk "*" cannot be used for - ip_port. - + + min-refresh-time + max-refresh-time + min-retry-time + max-retry-time + + + These options control the server's behavior on refreshing a + zone + (querying for SOA changes) or retrying failed transfers. + Usually the SOA values for the zone are used, but these + values + are set by the master, giving slave server administrators + little + control over their contents. + + + These options allow the administrator to set a minimum and + maximum + refresh and retry time either 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 + (4 weeks), min-retry-time 500 seconds, + and max-retry-time 1209600 seconds + (2 weeks). + + + - - The attempt of opening a statistics channel is - restricted by the optional allow clause. - Connections to the statistics channel are permitted based on the - address_match_list. - If no allow clause is present, - named accepts connection - attempts from any address; since the statistics may - contain sensitive internal information, it is highly - 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 - port 8888, then the statistics are accessible in XML format at - http://127.0.0.1:8888/ or - http://127.0.0.1:8888/xml. A CSS file is - included which can format the XML statistics into tables - when viewed with a stylesheet-capable browser, and into - charts and graphs using the Google Charts API when using a - javascript-capable browser. - - - - Applications that depend on a particular XML schema - can request - http://127.0.0.1:8888/xml/v2 for version 2 - of the statistics XML schema or - http://127.0.0.1:8888/xml/v3 for version 3. - If the requested schema is supported by the server, then - it will respond; if not, it will return a "page not found" - error. - - - - 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), - http://127.0.0.1:8888/xml/v3/server - (server and resolver statistics), - http://127.0.0.1:8888/xml/v3/zones - (zone statistics), - http://127.0.0.1:8888/xml/v3/net - (network status and socket statistics), - http://127.0.0.1:8888/xml/v3/mem - (memory manager statistics), - http://127.0.0.1:8888/xml/v3/tasks - (task manager statistics). - - - - 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 - http://127.0.0.1:8888/json/v1/status - (server uptime and last reconfiguration time), - http://127.0.0.1:8888/json/v1/server - (server and resolver statistics), - http://127.0.0.1:8888/json/v1/zones - (zone statistics), - http://127.0.0.1:8888/json/v1/net - (network status and socket statistics), - http://127.0.0.1:8888/json/v1/mem - (memory manager statistics), - http://127.0.0.1:8888/json/v1/tasks - (task manager statistics). - - + + edns-udp-size + + + Sets the initial advertised EDNS UDP buffer size in + bytes, to control the size of packets received from + authoritative servers in response to recursive queries. + Valid values are 512 to 4096 (values outside this range + will be silently adjusted). 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 response times out, named + will try again with plain DNS, and if that is successful, + it will be taken as evidence that the server does not + support EDNS. After enough failures using EDNS and + successes using plain DNS, named + will default to plain DNS for future communications + with that server. (Periodically, named + will an EDNS query to see if the situation has improved.) + + + However, if the initial query is successful with + EDNS advertising a buffer size of 512, then + named will advertise progressively + larger buffer sizes on successive queries, until + 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 + 1432 are chosen to allow for an IPv4/IPv6 encapsulated + UDP message to be sent without fragmentation at Ethernet + and IPv6 network mimimum MTU sizes.) + + + - - <command>trusted-keys</command> Statement Grammar + + max-udp-size + + + 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). 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 + firewalls that block fragmented packets and/or + block UDP packets that are greater than 512 bytes. + 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. + + + -trusted-keys { - string number number number string ; - string number number number string ; ... -}; - + + masterfile-format + + Specifies + the file format of zone files (see + ). + The default value is text, which is the + standard textual representation, except for slave zones, + in which the default value is raw. + Files in other formats than text are + typically expected to be generated by the + 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 + file in the text format. In particular, + check-names checks do not apply + for the raw format. This means + a zone file in the raw format + must be generated with the same check level as that + specified in the named configuration + file. Also, map format files are + 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 + by including a masterfile-format + statement within the zone or + view block in the configuration + file. + + + - - - <command>trusted-keys</command> Statement Definition - and Usage - - The trusted-keys statement defines - DNSSEC security roots. DNSSEC is described in . A security root is defined when the - public key for a non-authoritative zone is known, but - cannot be securely obtained through DNS, either because - it is the DNS root zone or because its parent zone is - unsigned. Once a key has been configured as a trusted - key, it is treated as if it had been validated and - proven secure. The resolver attempts DNSSEC validation - on all DNS data in subdomains of a security root. - - - All keys (and corresponding zones) listed in - trusted-keys are deemed to exist regardless - of what parent zones say. Similarly for all keys listed in - trusted-keys only those keys are - used to validate the DNSKEY RRset. The parent's DS RRset - will not be used. - - - The trusted-keys statement can contain - multiple key entries, each consisting of the key's - domain name, flags, protocol, algorithm, and the Base-64 - representation of the key data. - Spaces, tabs, newlines and carriage returns are ignored - in the key data, so the configuration may be split up into - multiple lines. - - - trusted-keys may be set at the top level - of named.conf or within a view. If it is - set in both places, they 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. - - + + clients-per-query + max-clients-per-query + + 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 + before dropping additional clients. named will attempt to + 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 + assume that it is dealing with a non-responsive zone + and will drop additional queries. If it gets a response + after dropping queries, it will raise the estimate. The + 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. + + + - - <command>managed-keys</command> Statement Grammar + + notify-delay + + + 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. + + + -managed-keys { - name initial-key flags protocol algorithm key-data ; - name initial-key flags protocol algorithm key-data ; ... -}; - + + max-rsa-exponent-size + + + 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. + + + + + + prefetch + + + 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 specifies the the + "trigger" TTL value at which prefetch of the current + query will take place: when a cache record with a + lower TTL value is encountered during query processing, + it will be refreshed. Valid trigger TTL values are 1 to + 10 seconds. Setting a trigger TTL to zero disables + prefetch. + + + An optional second argument can be used + to set the smallest original + TTL value that will be accepted for a record to be + eligible for prefetching. The difference between + the trigger TTL and the eligibility TTL must be + at least 6 seconds. + + + The default trigger and eligibility TTLs are + 2 and 9, + respectively. + + + + + + + + + Built-in server information zones - - - <command>managed-keys</command> Statement Definition - and Usage - - The managed-keys statement, like - trusted-keys, defines DNSSEC - security roots. The difference is that - managed-keys can be kept up to date - automatically, without intervention from the resolver - operator. - - - 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 old key in a - trusted-keys statement would be - unable to validate this zone any longer; it would - reply with a SERVFAIL response code. This would - continue until the resolver operator had updated the - trusted-keys statement with the new key. - - - If, however, the zone were listed in a - managed-keys statement instead, then the - zone owner could add a "stand-by" key to the zone in advance. - named would store the stand-by key, and - when the original key was revoked, named - would be able to transition smoothly to the new key. It would - also recognize that the old key had been revoked, and cease - using that key to validate answers, minimizing the damage that - the compromised key could do. - - - A managed-keys statement contains a list of - the keys to be managed, along with information about how the - keys are to be initialized for the first time. The only - initialization method currently supported (as of - BIND 9.7.0) is initial-key. - This means the managed-keys statement must - contain a copy of the initializing key. (Future releases may - allow keys to be initialized by other methods, eliminating this - requirement.) - - - Consequently, a managed-keys statement - appears similar to a trusted-keys, differing - in the presence of the second field, containing the keyword - initial-key. The difference is, whereas the - keys listed in a trusted-keys continue to be - trusted until they are removed from - named.conf, an initializing key listed - in a managed-keys statement is only trusted - once: for as long as it takes to load the - managed key database and start the RFC 5011 key maintenance - process. - - - The first time named runs with a managed key - configured in named.conf, it fetches the - DNSKEY RRset directly from the zone apex, and validates it - using the key specified in the managed-keys - statement. If the DNSKEY RRset is validly signed, then it is - used as the basis for a new managed keys database. - - - From that point on, whenever named runs, it - sees the managed-keys statement, checks to - make sure RFC 5011 key maintenance has already been initialized - for the specified domain, and if so, it simply moves on. The - key specified in the managed-keys is not - used to validate answers; it has been superseded by the key or - keys stored in the managed keys database. - - - The next time named runs after a name - has been removed from the - managed-keys statement, the corresponding - zone will be removed from the managed keys database, - and RFC 5011 key maintenance will no longer be used for that - domain. - - named only maintains a single managed keys - database; consequently, unlike trusted-keys, - managed-keys may only be set at the top - level of named.conf, not within a view. - - - In the current implementation, the managed keys database is - stored as a master-format zone file called - managed-keys.bind. When the key database - is changed, the zone is updated. As with any other dynamic - zone, changes will be written into a journal file, - managed-keys.bind.jnl. They are committed - to the master file as soon as possible afterward; in the case - of the managed key database, this will usually occur within 30 - seconds. So, whenever named is using - automatic key maintenance, those two files can be expected to - exist in the working directory. (For this reason among others, - the working directory should be always be writable by - named.) + The server provides some helpful diagnostic information + through a number of built-in zones under the + pseudo-top-level-domain bind in the + CHAOS class. These zones are part + of a + built-in view (see ) of + class + CHAOS which is separate from the + default view of class IN. Most global + configuration options (allow-query, + etc) will apply to this view, but some are locally + overridden: notify, + recursion and + allow-new-zones are + always set to no, and + rate-limit is set to allow + three responses per second. - If the dnssec-validation option is - set to auto, named - will automatically initialize a managed key for the - root zone. Similarly, if the dnssec-lookaside - option is set to auto, - named will automatically initialize - a managed key for the zone dlv.isc.org. - In both cases, the key that is used to initialize the key - maintenance process is built into named, - and can be overridden from bindkeys-file. + 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. - - - - <command>view</command> Statement Grammar - -view view_name - class { - match-clients { address_match_list }; - match-destinations { address_match_list }; - match-recursive-only yes_or_no ; - view_option; ... - zone_statement; ... -}; - - - - - <command>view</command> Statement Definition and Usage - - - The view statement is a powerful - feature - of BIND 9 that lets a name server - answer a DNS query differently - depending on who is asking. It is particularly useful for - 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 - matches - a view if its source IP address matches the - address_match_list of the view's - match-clients clause and its - destination IP address matches - the address_match_list of the - view's - match-destinations clause. If not - specified, both - match-clients and match-destinations - default to matching all addresses. In addition to checking IP - addresses - match-clients and match-destinations - can also take keys which provide an - mechanism for the - client to select the view. A view can also be specified - as match-recursive-only, which - means that only recursive - requests from matching clients will match that view. - The order of the view statements is - significant — - 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. - By defining a zone of the same name in multiple views, different - zone data can be given to different clients, for example, - "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 - apply only when resolving queries with that view. When no - view-specific - value is given, the value in the options statement - is used as a default. Also, zone options can have default values - specified - in the view statement; these - 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 - created - in class IN. Any zone statements - specified on - the top level of the configuration file are considered to be part - of - this default view, and the options - statement will - apply to the default view. If any explicit view - statements are present, all zone - 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; }; - - // Provide recursive service to internal - // clients only. - recursion yes; - // Provide a complete view of the example.com - // zone including addresses of internal hosts. - zone "example.com" { - type master; - file "example-internal.db"; - }; -}; + -view "external" { - // Match all clients not matched by the - // previous view. - match-clients { any; }; + + version + + + The version the server should report + via a query of the name version.bind + with type TXT, class CHAOS. + The default is the real version number of this server. + Specifying version none + disables processing of the queries. + + + - // Refuse recursive service to external clients. - recursion no; + + hostname + + + The hostname the server should report via a query of + the name hostname.bind + with type TXT, class CHAOS. + This defaults to the hostname of the machine hosting the + name server as + found by the gethostname() function. The primary purpose of such queries + is to + identify which of a group of anycast servers is actually + answering your queries. Specifying hostname none; + disables processing of the queries. + + + - // Provide a restricted view of the example.com - // zone containing only publicly accessible hosts. - zone "example.com" { - type master; - file "example-external.db"; - }; -}; - + + server-id + + + The ID the server should report when receiving a Name + Server Identifier (NSID) query, or a query of the name + ID.SERVER with type + TXT, class CHAOS. + The primary purpose of such queries is to + identify which of a group of anycast servers is actually + answering your queries. Specifying server-id none; + disables processing of the queries. + Specifying server-id hostname; will cause named to + use the hostname as found by the gethostname() function. + The default server-id is none. + + + - - - <command>zone</command> - Statement Grammar + -zone zone_name class { - type master; - allow-query { address_match_list }; - allow-query-on { address_match_list }; - allow-transfer { address_match_list }; - allow-update { address_match_list }; - update-check-ksk yes_or_no; - dnssec-dnskey-kskonly yes_or_no; - dnssec-loadkeys-interval number; - update-policy local | { update_policy_rule ... }; - also-notify { ip_addr port ip_port dscp ip_dscp ; - ip_addr port ip_port dscp ip_dscp ; ... }; - check-names (warn|fail|ignore) ; - check-mx (warn|fail|ignore) ; - check-wildcard yes_or_no; - check-spf ( warn | fail | ignore ); - check-integrity yes_or_no ; - dialup dialup_option ; - file string ; - masterfile-format (text|raw|map) ; - journal string ; - max-journal-size size_spec; - forward (only|first) ; - forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; - ixfr-base string ; - ixfr-from-differences yes_or_no; - ixfr-tmp-file string ; - request-ixfr yes_or_no ; - maintain-ixfr-base yes_or_no ; - max-ixfr-log-size number ; - max-transfer-idle-out number ; - max-transfer-time-out number ; - notify yes_or_no | explicit | master-only ; - notify-delay seconds ; - notify-to-soa yes_or_no; - pubkey number number number string ; - notify-source (ip4_addr | *) port ip_port dscp ip_dscp ; - notify-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; - zone-statistics full | terse | none; - sig-validity-interval number number ; - sig-signing-nodes number ; - sig-signing-signatures number ; - sig-signing-type number ; - database string ; - min-refresh-time number ; - max-refresh-time number ; - min-retry-time number ; - max-retry-time number ; - key-directory path_name; - auto-dnssec allow|maintain|off; - inline-signing yes_or_no; - zero-no-soa-ttl yes_or_no ; - serial-update-method increment|unixtime; -}; + -zone zone_name class { - type slave; - allow-notify { address_match_list }; - allow-query { address_match_list }; - allow-query-on { address_match_list }; - allow-transfer { address_match_list }; - allow-update-forwarding { address_match_list }; - dnssec-update-mode ( maintain | no-resign ); - update-check-ksk yes_or_no; - dnssec-dnskey-kskonly yes_or_no; - dnssec-loadkeys-interval number; - dnssec-secure-to-insecure yes_or_no ; - try-tcp-refresh yes_or_no; - also-notify port ip_port dscp ip_dscp { ( masters_list | ip_addr - port ip_port - dscp ip_dscp - key key ) ; ... }; - check-names (warn|fail|ignore) ; - dialup dialup_option ; - file string ; - masterfile-format (text|raw|map) ; - journal string ; - max-journal-size size_spec; - forward (only|first) ; - forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; - ixfr-base string ; - ixfr-from-differences yes_or_no; - ixfr-tmp-file string ; - maintain-ixfr-base yes_or_no ; - masters port ip_port dscp ip_dscp { ( masters_list | ip_addr - port ip_port - dscp ip_dscp - key key ) ; ... }; - max-ixfr-log-size number ; - max-transfer-idle-in number ; - max-transfer-idle-out number ; - max-transfer-time-in number ; - max-transfer-time-out number ; - notify yes_or_no | explicit | master-only ; - notify-delay seconds ; - notify-to-soa yes_or_no; - pubkey number number number string ; - transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; - transfer-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; - alt-transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; - alt-transfer-source-v6 (ip6_addr | *) - port ip_port - dscp ip_dscp ; - use-alt-transfer-source yes_or_no; - notify-source (ip4_addr | *) port ip_port dscp ip_dscp ; - notify-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; - zone-statistics full | terse | none; - sig-validity-interval number number ; - sig-signing-nodes number ; - sig-signing-signatures number ; - sig-signing-type number ; - database string ; - min-refresh-time number ; - max-refresh-time number ; - min-retry-time number ; - max-retry-time number ; - key-directory path_name; - auto-dnssec allow|maintain|off; - inline-signing yes_or_no; - multi-master yes_or_no ; - zero-no-soa-ttl yes_or_no ; -}; + + Built-in Empty Zones + + Named has some built-in empty zones (SOA and NS records only). + These are for zones that should normally be answered locally + and which queries should not be sent to the Internet's root + servers. The official servers which cover these namespaces + return NXDOMAIN responses to these queries. In particular, + these cover the reverse namespaces for addresses from + RFC 1918, RFC 4193, RFC 5737 and RFC 6598. They also include the + reverse namespace for IPv6 local address (locally assigned), + IPv6 link local addresses, the IPv6 loopback address and the + IPv6 unknown address. + + + Named 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: + + 10.IN-ADDR.ARPA + 16.172.IN-ADDR.ARPA + 17.172.IN-ADDR.ARPA + 18.172.IN-ADDR.ARPA + 19.172.IN-ADDR.ARPA + 20.172.IN-ADDR.ARPA + 21.172.IN-ADDR.ARPA + 22.172.IN-ADDR.ARPA + 23.172.IN-ADDR.ARPA + 24.172.IN-ADDR.ARPA + 25.172.IN-ADDR.ARPA + 26.172.IN-ADDR.ARPA + 27.172.IN-ADDR.ARPA + 28.172.IN-ADDR.ARPA + 29.172.IN-ADDR.ARPA + 30.172.IN-ADDR.ARPA + 31.172.IN-ADDR.ARPA + 168.192.IN-ADDR.ARPA + 64.100.IN-ADDR.ARPA + 65.100.IN-ADDR.ARPA + 66.100.IN-ADDR.ARPA + 67.100.IN-ADDR.ARPA + 68.100.IN-ADDR.ARPA + 69.100.IN-ADDR.ARPA + 70.100.IN-ADDR.ARPA + 71.100.IN-ADDR.ARPA + 72.100.IN-ADDR.ARPA + 73.100.IN-ADDR.ARPA + 74.100.IN-ADDR.ARPA + 75.100.IN-ADDR.ARPA + 76.100.IN-ADDR.ARPA + 77.100.IN-ADDR.ARPA + 78.100.IN-ADDR.ARPA + 79.100.IN-ADDR.ARPA + 80.100.IN-ADDR.ARPA + 81.100.IN-ADDR.ARPA + 82.100.IN-ADDR.ARPA + 83.100.IN-ADDR.ARPA + 84.100.IN-ADDR.ARPA + 85.100.IN-ADDR.ARPA + 86.100.IN-ADDR.ARPA + 87.100.IN-ADDR.ARPA + 88.100.IN-ADDR.ARPA + 89.100.IN-ADDR.ARPA + 90.100.IN-ADDR.ARPA + 91.100.IN-ADDR.ARPA + 92.100.IN-ADDR.ARPA + 93.100.IN-ADDR.ARPA + 94.100.IN-ADDR.ARPA + 95.100.IN-ADDR.ARPA + 96.100.IN-ADDR.ARPA + 97.100.IN-ADDR.ARPA + 98.100.IN-ADDR.ARPA + 99.100.IN-ADDR.ARPA + 100.100.IN-ADDR.ARPA + 101.100.IN-ADDR.ARPA + 102.100.IN-ADDR.ARPA + 103.100.IN-ADDR.ARPA + 104.100.IN-ADDR.ARPA + 105.100.IN-ADDR.ARPA + 106.100.IN-ADDR.ARPA + 107.100.IN-ADDR.ARPA + 108.100.IN-ADDR.ARPA + 109.100.IN-ADDR.ARPA + 110.100.IN-ADDR.ARPA + 111.100.IN-ADDR.ARPA + 112.100.IN-ADDR.ARPA + 113.100.IN-ADDR.ARPA + 114.100.IN-ADDR.ARPA + 115.100.IN-ADDR.ARPA + 116.100.IN-ADDR.ARPA + 117.100.IN-ADDR.ARPA + 118.100.IN-ADDR.ARPA + 119.100.IN-ADDR.ARPA + 120.100.IN-ADDR.ARPA + 121.100.IN-ADDR.ARPA + 122.100.IN-ADDR.ARPA + 123.100.IN-ADDR.ARPA + 124.100.IN-ADDR.ARPA + 125.100.IN-ADDR.ARPA + 126.100.IN-ADDR.ARPA + 127.100.IN-ADDR.ARPA + 0.IN-ADDR.ARPA + 127.IN-ADDR.ARPA + 254.169.IN-ADDR.ARPA + 2.0.192.IN-ADDR.ARPA + 100.51.198.IN-ADDR.ARPA + 113.0.203.IN-ADDR.ARPA + 255.255.255.255.IN-ADDR.ARPA + 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA + 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA + 8.B.D.0.1.0.0.2.IP6.ARPA + D.F.IP6.ARPA + 8.E.F.IP6.ARPA + 9.E.F.IP6.ARPA + A.E.F.IP6.ARPA + B.E.F.IP6.ARPA + + + + 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 + at the view level. To override the options list of disabled + zones, you can disable the root zone at the view level, for example: + + disable-empty-zone "."; + + + + 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 + being made to the infrastructure servers for names in these + spaces. So many in fact that sacrificial servers were needed + to be deployed to channel the query load away from the + infrastructure servers. + + + The real parent servers for these zones should disable all + empty zone under the parent zone they serve. For the real + root servers, this is all built-in empty zones. This will + enable them to return referrals to deeper in the tree. + + + + empty-server + + + 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. + + + + + + empty-contact + + + Specify what contact name will appear in the returned + SOA record for empty zones. If none is specified, then + "." will be used. + + + + + + empty-zones-enable + + + Enable or disable all empty zones. By default, they + are enabled. + + + + + + disable-empty-zone + + + Disable individual empty zones. By default, none are + disabled. This option can be specified multiple times. + + + + + -zone zone_name class { - type hint; - file string ; - delegation-only yes_or_no ; - check-names (warn|fail|ignore) ; // Not Implemented. -}; + + Additional Section Caching -zone zone_name class { - type stub; - allow-query { address_match_list }; - allow-query-on { address_match_list }; - check-names (warn|fail|ignore) ; - dialup dialup_option ; - delegation-only yes_or_no ; - file string ; - masterfile-format (text|raw|map) ; - forward (only|first) ; - forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; - masters port ip_port dscp ip_dscp { ( masters_list | ip_addr - port ip_port - dscp ip_dscp - key key ) ; ... }; - max-transfer-idle-in number ; - max-transfer-time-in number ; - pubkey number number number string ; - transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; - transfer-source-v6 (ip6_addr | *) - port ip_port dscp ip_dscp ; - alt-transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; - alt-transfer-source-v6 (ip6_addr | *) - port ip_port dscp ip_dscp ; - use-alt-transfer-source yes_or_no; - zone-statistics yes_or_no ; - database string ; - min-refresh-time number ; - max-refresh-time number ; - min-retry-time number ; - max-retry-time number ; - multi-master yes_or_no ; -}; + + The additional section cache, also called acache, + is an internal cache to improve the response performance of BIND 9. + When additional section caching is enabled, BIND 9 will + cache an internal short-cut to the additional section content for + each answer RR. + Note that acache is an internal caching + mechanism of BIND 9, and is not related to the DNS caching + server function. + -zone zone_name class { - type static-stub; - allow-query { address_match_list }; - server-addresses { ip_addr ; ... }; - server-names { namelist }; - zone-statistics yes_or_no ; -}; + + Additional section caching does not change the + response content (except the RRsets ordering of the additional + section, see below), but can improve the response performance + significantly. + It is particularly effective when BIND 9 acts as an authoritative + server for a zone that has many delegations with many glue RRs. + -zone zone_name class { - type forward; - forward (only|first) ; - forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; - delegation-only yes_or_no ; -}; + + In order to obtain the maximum performance improvement + from additional section caching, setting + additional-from-cache + to no is recommended, since the current + implementation of acache + does not short-cut of additional section information from the + DNS cache data. + -zone "." class { - type redirect; - file string ; - masterfile-format (text|raw|map) ; - allow-query { address_match_list }; -}; + + One obvious disadvantage of acache is + that it requires much more + memory for the internal cached data. + Thus, if the response performance does not matter and memory + consumption is much more critical, the + acache mechanism can be + disabled by setting acache-enable to + no. + It is also possible to specify the upper limit of memory + consumption + for acache by using max-acache-size. + -zone zone_name class { - type delegation-only; -}; + + Additional section caching also has a minor effect on the + RRset ordering in the additional section. + Without acache, + cyclic order is effective for the additional + section as well as the answer and authority sections. + However, additional section caching fixes the ordering when it + first caches an RRset for the additional section, and the same + ordering will be kept in succeeding responses, regardless of the + setting of rrset-order. + The effect of this should be minor, however, since an + RRset in the additional section + typically only contains a small number of RRs (and in many cases + it only contains a single RR), in which case the + ordering does not matter much. + -zone zone_name class { - in-view string ; -}; + + The following is a summary of options related to + acache. + - + - - - <command>zone</command> Statement Definition and Usage - - Zone Types - - - - - - - - - - - master - - - - - The server has a master copy of the data - for the zone and will be able to provide authoritative - answers for - it. - - - - - - - slave - - - - - A slave zone is a replica of a master - zone. The masters list - specifies one or more IP addresses - of master servers that the slave contacts to update - its copy of the zone. - Masters list elements can also be names of other - masters lists. - By default, transfers are made from port 53 on the - servers; this can - be changed for all servers by specifying a port number - before the - list of IP addresses, or on a per-server basis after - the IP address. - Authentication to the master can also be done with - per-server TSIG keys. - If a file is specified, then the - replica will be written to this file whenever the zone - is changed, - and reloaded from this file on a server restart. Use - of a file is - recommended, since it often speeds server startup and - eliminates - a needless waste of bandwidth. Note that for large - numbers (in the - tens or hundreds of thousands) of zones per server, it - is best to - use a two-level naming scheme for zone filenames. For - example, - a slave server for the zone example.com might place - the zone contents into a file called - ex/example.com where ex/ is - just the first two letters of the zone name. (Most - operating systems - behave very slowly if you put 100000 files into - a single directory.) - - - - - - - stub - - - - - A stub zone is similar to a slave zone, - except that it replicates only the NS records of a - master zone instead - of the entire zone. Stub zones are not a standard part - of the DNS; - they are a feature specific to the BIND implementation. - - - - Stub zones can be used to eliminate the need for glue - NS record - in a parent zone at the expense of maintaining a stub - zone entry and - a set of name server addresses in named.conf. - This usage is not recommended for new configurations, - and BIND 9 - supports it only in a limited way. - In BIND 4/8, zone - transfers of a parent zone - included the NS records from stub children of that - zone. This meant - that, in some cases, users could get away with - configuring child stubs - only in the master server for the parent zone. BIND - 9 never mixes together zone data from different zones - in this - way. Therefore, if a BIND 9 master serving a parent - zone has child stub zones configured, all the slave - servers for the - parent zone also need to have the same child stub - zones - configured. - - - - Stub zones can also be used as a way of forcing the - resolution - of a given domain to use a particular set of - authoritative servers. - For example, the caching name servers on a private - network using - RFC1918 addressing may be configured with stub zones - for - 10.in-addr.arpa - to use a set of internal name servers as the - authoritative - servers for that domain. - - - - - - - static-stub - - - - - A static-stub zone is similar to a stub zone - with the following exceptions: - the zone data is statically configured, rather - than transferred from a master server; - when recursion is necessary for a query that - matches a static-stub zone, the locally - configured data (nameserver names and glue addresses) - is always used even if different authoritative - information is cached. - - - Zone data is configured via the - server-addresses and - server-names zone options. - - - The zone data is maintained in the form of NS - and (if necessary) glue A or AAAA RRs - internally, which can be seen by dumping zone - databases by rndc dumpdb -all. - The configured RRs are considered local configuration - parameters rather than public data. - Non recursive queries (i.e., those with the RD - bit off) to a static-stub zone are therefore - prohibited and will be responded with REFUSED. - - - Since the data is statically configured, no - zone maintenance action takes place for a static-stub - zone. - For example, there is no periodic refresh - attempt, and an incoming notify message - will be rejected with an rcode of NOTAUTH. - - - Each static-stub zone is configured with - internally generated NS and (if necessary) - glue A or AAAA RRs - - - - - - - forward - - - - - A "forward zone" is a way to configure - forwarding on a per-domain basis. A zone statement - of type forward can - contain a forward - and/or forwarders - statement, - which will apply to queries within the domain given by - the zone - name. If no forwarders - statement is present or - an empty list for forwarders is given, then no - forwarding will be done for the domain, canceling the - effects of - any forwarders in the options statement. Thus - if you want to use this type of zone to change the - behavior of the - global forward option - (that is, "forward first" - to, then "forward only", or vice versa, but want to - use the same - servers as set globally) you need to re-specify the - global forwarders. - - - - - - - hint - - - - - The initial set of root name servers is - specified using a "hint zone". When the server starts - up, it uses - the root hints to find a root name server and get the - most recent - list of root name servers. If no hint zone is - specified for class - IN, the server uses a compiled-in default set of root - servers hints. - Classes other than IN have no built-in defaults hints. - - - - - - - redirect - - - - - Redirect zones are used to provide answers to - queries when normal resolution would result in - NXDOMAIN being returned. - Only one redirect zone is supported - per view. allow-query can be - used to restrict which clients see these answers. - - - If the client has requested DNSSEC records (DO=1) and - the NXDOMAIN response is signed then no substitution - will occur. - - - To redirect all NXDOMAIN responses to - 100.100.100.2 and - 2001:ffff:ffff::100.100.100.2, one would - configure a type redirect zone named ".", - with the zone file containing wildcard records - that point to the desired addresses: - "*. IN A 100.100.100.2" - and - "*. IN AAAA 2001:ffff:ffff::100.100.100.2". - - - To redirect all Spanish names (under .ES) one - would use similar entries but with the names - "*.ES." instead of "*.". To redirect all - commercial Spanish names (under COM.ES) one - would use wildcard entries called "*.COM.ES.". - - - Note that the redirect zone supports all - possible types; it is not limited to A and - AAAA records. - - - Because redirect zones are not referenced - directly by name, they are not kept in the - zone lookup table with normal master and slave - zones. Consequently, it is not currently possible - to use - rndc reload - zonename - to reload a redirect zone. However, when using - rndc reload without specifying - a zone name, redirect zones will be reloaded along - with other zones. - - - - - - - delegation-only - - - - - This is used to enforce the delegation-only - status of infrastructure zones (e.g. COM, - NET, ORG). Any answer that is received - without an explicit or implicit delegation - in the authority section will be treated - as NXDOMAIN. This does not apply to the - zone apex. This should not be applied to - leaf zones. - - - delegation-only has no - effect on answers received from forwarders. - - - See caveats in . - - - - - - - - - - Class - - 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 - used to share information about various systems databases, such - as users, groups, printers and so on. The keyword - 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. - - - - - Zone Options - - - - - allow-notify - - - See the description of - allow-notify in . - - - - - - allow-query - - - See the description of - allow-query in . - - - - - - allow-query-on - - - See the description of - allow-query-on in . - - - - - - allow-transfer - - - See the description of allow-transfer - in . - - - - - - allow-update - - - See the description of allow-update - in . - - - - - - update-policy - - - Specifies a "Simple Secure Update" policy. See - . - - - - - - allow-update-forwarding - - - See the description of allow-update-forwarding - in . - - - - - - also-notify - - - Only meaningful if notify - is - active for this zone. The set of machines that will - receive a - DNS NOTIFY message - for this zone is made up of all the listed name servers - (other than - the primary master) for the zone plus any IP addresses - specified - with also-notify. A port - may be specified - with each also-notify - address to send the notify - messages to a port other than the default of 53. - A TSIG key may also be specified to cause the - NOTIFY to be signed by the - given key. - also-notify is not - meaningful for stub zones. - The default is the empty list. - - - - - - check-names - - - This option is used to restrict the character set and - syntax of - certain domain names in master files and/or DNS responses - received from the - network. The default varies according to zone type. For master zones the default is fail. For slave - zones the default is warn. - It is not implemented for hint zones. - - - - - - check-mx - - - See the description of - check-mx in . - - - - - - check-spf - - - See the description of - check-spf in . - - - - - - check-wildcard - - - See the description of - check-wildcard in . - - - - - - check-integrity - - - See the description of - check-integrity in . - - - - - - check-sibling - - - See the description of - check-sibling in . - - - - - - zero-no-soa-ttl - - - See the description of - zero-no-soa-ttl in . - - - + + acache-enable + + + If yes, additional section caching is + enabled. The default value is no. + + + - - update-check-ksk - - - See the description of - update-check-ksk in . - - - + + acache-cleaning-interval + + + The server will remove stale cache entries, based on an LRU + based + algorithm, every acache-cleaning-interval minutes. + The default is 60 minutes. + If set to 0, no periodic cleaning will occur. + + + - - dnssec-update-mode - - - See the description of - dnssec-update-mode in . - - - + + max-acache-size + + + The maximum amount of memory in bytes to use for the server's acache. + When the amount of data in the acache reaches this limit, + the server + will clean more aggressively so that the limit is not + exceeded. + In a server with multiple views, the limit applies + separately to the + acache of each view. + The default is 16M. + + + - - dnssec-dnskey-kskonly - - - See the description of - dnssec-dnskey-kskonly in . - - - + - - try-tcp-refresh - - - See the description of - try-tcp-refresh in . - - - - - - database - - - 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. - The first word - identifies the database type, and any subsequent words are - passed - as arguments to the database to be interpreted in a way - 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. - - - - - - dialup - - - See the description of - dialup in . - - - - - - delegation-only - - - The flag only applies to 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 . - - - - - - forward - - - 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. - - - - - - forwarders - - - 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. - - - - - - ixfr-base - - - Was used in BIND 8 to - specify the name - of the transaction log (journal) file for dynamic update - and IXFR. - BIND 9 ignores the option - and constructs the name of the journal - file by appending ".jnl" - to the name of the - zone file. - - - - - - ixfr-tmp-file - - - Was an undocumented option in BIND 8. - Ignored in BIND 9. - - - - - - journal - - - 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. - - - - - - max-journal-size - - - See the description of - max-journal-size in . - - - - - - max-transfer-time-in - - - See the description of - max-transfer-time-in in . - - - - - - max-transfer-idle-in - - - See the description of - max-transfer-idle-in in . - - - - - - max-transfer-time-out - - - See the description of - max-transfer-time-out in . - - - - - - max-transfer-idle-out - - - See the description of - max-transfer-idle-out in . - - - - - - notify - - - See the description of - notify in . - - - - - - notify-delay - - - See the description of - notify-delay in . - - - - - - notify-to-soa - - - See the description of - notify-to-soa in - . - - - - - - pubkey - - - In BIND 8, this option was - intended for specifying - a public zone key for verification of signatures in DNSSEC - signed - zones when they are loaded from disk. BIND 9 does not verify signatures - on load and ignores the option. - - - - - - zone-statistics - - - If yes, the server will keep - statistical - information for this zone, which can be dumped to the - statistics-file defined in - the server options. - - - - - - server-addresses - - - Only meaningful for static-stub zones. - This is a list of IP addresses to which queries - should be sent in recursive resolution for the - zone. - A non empty list for this option will internally - 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, - the following RRs will be internally configured. - -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 - "www.example.com" with the RD bit on, the server - will initiate recursive resolution and send - queries to 192.0.2.1 and/or 2001:db8::1234. - - - - - - server-names - - - Only meaningful for static-stub zones. - This is a list of domain names of nameservers that - act as authoritative servers of the static-stub - zone. - These names will be resolved to IP addresses when - named needs to send queries to - these servers. - To make this supplemental resolution successful, - these names must not be a subdomain of the origin - name of static-stub zone. - That is, when "example.net" is the origin of a - static-stub zone, "ns.example" and - "master.example.com" can be specified in the - server-names option, but - "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 - static-stub zone with "ns1.example.net" and - "ns2.example.net" - in a server-names option, - the following RRs will be internally configured. - -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 - "www.example.com" with the RD bit on, the server - initiate recursive resolution, - resolve "ns1.example.net" and/or - "ns2.example.net" to IP addresses, and then send - queries to (one or more of) these addresses. - - - - - - sig-validity-interval - - - See the description of - sig-validity-interval in . - - - - - - sig-signing-nodes - - - See the description of - sig-signing-nodes in . - - - - - - sig-signing-signatures - - - See the description of - sig-signing-signatures in . - - - - - - sig-signing-type - - - See the description of - sig-signing-type in . - - - - - - transfer-source - - - See the description of - transfer-source in . - - - - - - transfer-source-v6 - - - See the description of - transfer-source-v6 in . - - - - - - alt-transfer-source - - - See the description of - alt-transfer-source in . - - - - - - alt-transfer-source-v6 - - - See the description of - alt-transfer-source-v6 in . - - - - - - use-alt-transfer-source - - - See the description of - use-alt-transfer-source in . - - - - - - - notify-source - - - See the description of - notify-source in . - - - - - - notify-source-v6 - - - See the description of - notify-source-v6 in . - - - - - - min-refresh-time - max-refresh-time - min-retry-time - max-retry-time - - - See the description in . - - - - - - ixfr-from-differences - - - See the description of - ixfr-from-differences in . - (Note that the ixfr-from-differences - master and - slave choices are not - available at the zone level.) - - - - - - key-directory - - - See the description of - key-directory in . - - - - - - auto-dnssec - - - Zones configured for dynamic DNS may also 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 - (see and - ). The command - rndc sign - zonename causes - named to load keys from the key - repository and sign the zone with all keys that are - active. - rndc loadkeys - zonename causes - named to load keys from the key - repository and schedule key maintenance events to occur - in the future, but it does not sign the full zone - immediately. Note: once keys have been loaded for a - zone the first time, the repository will be searched - for changes periodically, regardless of whether - rndc loadkeys is used. The recheck - interval is defined by - dnssec-loadkeys-interval.) - - - The default setting is auto-dnssec off. - - - - - - serial-update-method - - - 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 - since the UNIX epoch, unless the serial number is - already greater than or equal to that value, in which - case it is simply incremented by one. - - - - - - inline-signing - - - 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 - behaviour is disabled by default. - - - + - - multi-master - - - See the description of multi-master in - . - - - - - - masterfile-format - - - See the description of masterfile-format - in . - - - + + Content Filtering + + BIND 9 provides the ability to filter + out DNS responses from external DNS servers containing + certain types of data in the answer section. + Specifically, it can reject address (A or AAAA) records if + the corresponding IPv4 or IPv6 addresses match the given + address_match_list of the + deny-answer-addresses option. + It can also reject CNAME or DNAME records if the "alias" + name (i.e., the CNAME alias or the substituted query name + due to DNAME) matches the + given namelist of the + deny-answer-aliases option, where + "match" means the alias name is a subdomain of one of + the name_list elements. + If the optional namelist is specified + with except-from, records whose query name + matches the list will be accepted regardless of the filter + setting. + Likewise, if the alias name is a subdomain of the + corresponding zone, the deny-answer-aliases + filter will not apply; + for example, even if "example.com" is specified for + deny-answer-aliases, + +www.example.com. CNAME xxx.example.com. - - dnssec-secure-to-insecure - - - See the description of - dnssec-secure-to-insecure in . - - - - - - - - - Dynamic Update Policies - 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 works the - same way as in previous versions of BIND. - It grants given clients the permission to update any - record of any name in the zone. - - - The update-policy clause - allows more fine-grained control over what updates are - allowed. A set of rules is specified, where each rule - either grants or denies permissions for one or more - names to be updated by one or more identities. If - the dynamic update request message is signed (that is, - it includes either a TSIG or SIG(0) record), the - identity of the signer can be determined. - - - Rules are specified in the update-policy - zone option, and are only meaningful for master zones. - When the update-policy statement - is present, it is a configuration error for the - allow-update statement to be - present. The update-policy statement - only examines the signer of a message; the source - address is not relevant. - - - There is a pre-defined update-policy - rule which can be switched on with the command - update-policy local;. - Switching on this rule in a zone causes - named to generate a TSIG session - key and place it in a file, and to allow that key - to update the zone. (By default, the file is - /var/run/named/session.key, the key - name is "local-ddns" and the key algorithm is HMAC-SHA256, - but these values are configurable with the - session-keyfile, - session-keyname and - session-keyalg options, respectively). - - - A client running on the local system, and with appropriate - permissions, may read that file and use the key to sign update - requests. The zone's update policy will be set to allow that - key to change any record within the zone. Assuming the - key name is "local-ddns", this policy is equivalent to: - + + returned by an "example.com" server will be accepted. + - update-policy { grant local-ddns zonesub any; }; - + + In the address_match_list of the + deny-answer-addresses option, only + ip_addr + and ip_prefix + are meaningful; + any key_id will be silently ignored. + - - The command nsupdate -l sends update - requests to localhost, and signs them using the session key. - + + 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. + - - Other rule definitions look like this: - + + 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 + an alias name within your own domain. + A naive web browser or script could then serve as an + unintended proxy, allowing the attacker + to get access to an internal node of your local network + that couldn't be externally accessed otherwise. + See the paper available at + + http://portal.acm.org/citation.cfm?id=1315245.1315298 + + for more details about the attacks. + - -( grant | deny ) identity nametype name types + + 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"; }; - - Each rule grants or denies privileges. Once a message has - successfully matched a rule, the operation is immediately - granted or denied and no further rules are examined. A rule - is matched when the signer matches the identity field, the - name matches the name field in accordance with the nametype - field, and the type matches the types specified in the type - field. - - - No signer is required for tcp-self - or 6to4-self however the standard - reverse mapping / prefix conversion must match the identity - field. - - - The identity field specifies a name or a wildcard - name. Normally, this is the name of the TSIG or - SIG(0) key used to sign the update request. When a - TKEY exchange has been used to create a shared secret, - the identity of the shared secret is the same as the - identity of the key used to authenticate the TKEY - exchange. TKEY is also the negotiation method used - by GSS-TSIG, which establishes an identity that is - the Kerberos principal of the client, such as - "user@host.domain". When the - identity field specifies - a wildcard name, it is subject to DNS wildcard - expansion, so the rule will apply to multiple identities. - The identity field must - contain a fully-qualified domain name. - - - For nametypes krb5-self, - ms-self, krb5-subdomain, - and ms-subdomain the - identity field specifies - the Windows or Kerberos realm of the machine belongs to. - - - The nametype field has 13 - values: - name, subdomain, - wildcard, self, - selfsub, selfwild, - krb5-self, ms-self, - krb5-subdomain, - ms-subdomain, - tcp-self, 6to4-self, - zonesub, and external. - - - - - - - - - - name - - - - Exact-match semantics. This rule matches - when the name being updated is identical - to the contents of the - name field. - - - - - - - subdomain - - - - This rule matches when the name being updated - is a subdomain of, or identical to, the - contents of the name - field. - - - - - - - zonesub - - - - This rule is similar to subdomain, except that - it matches when the name being updated is a - subdomain of the zone in which the - update-policy statement - appears. This obviates the need to type the zone - name twice, and enables the use of a standard - update-policy statement in - multiple zones without modification. - - - When this rule is used, the - name field is omitted. - - - - - - - wildcard - - - - The name field - is subject to DNS wildcard expansion, and - this rule matches when the name being updated - name is a valid expansion of the wildcard. - - - - - - - self - - - - - This rule matches when the name being updated - matches the contents of the - identity field. - The name field - is ignored, but should be the same as the - identity field. - The self nametype is - most useful when allowing using one key per - name to update, where the key has the same - name as the name to be updated. The - identity would - be specified as * (an asterisk) in - this case. - - - - - - - selfsub - - - - This rule is similar to self - except that subdomains of self - can also be updated. - - - - - - - selfwild - - - - This rule is similar to self - except that only subdomains of - self can be updated. - - - - - - - ms-self - - - - This rule takes a Windows machine principal - (machine$@REALM) for machine in REALM and - and converts it machine.realm allowing the machine - to update machine.realm. The REALM to be matched - is specified in the identity - field. - - - - - - - ms-subdomain - - - - This rule takes a Windows machine principal - (machine$@REALM) for machine in REALM and - converts it to machine.realm allowing the machine - to update subdomains of machine.realm. The REALM - to be matched is specified in the - identity field. - - - - - - - krb5-self - - - - This rule takes a Kerberos machine principal - (host/machine@REALM) for machine in REALM and - and converts it machine.realm allowing the machine - to update machine.realm. The REALM to be matched - is specified in the identity - field. - - - - - - - krb5-subdomain - - - - This rule takes a Kerberos machine principal - (host/machine@REALM) for machine in REALM and - converts it to machine.realm allowing the machine - to update subdomains of machine.realm. The REALM - to be matched is specified in the - identity field. - - - - - - - tcp-self - - - - Allow updates that have been sent via TCP and - for which the standard mapping from the initiating - IP address into the IN-ADDR.ARPA and IP6.ARPA - namespaces match the name to be updated. - - - It is theoretically possible to spoof these TCP - sessions. - - - - - - - 6to4-self - - - - Allow the 6to4 prefix to be update by any TCP - connection from the 6to4 network or from the - corresponding IPv4 address. This is intended - to allow NS or DNAME RRsets to be added to the - reverse tree. - - - It is theoretically possible to spoof these TCP - sessions. - - - - - - - external - - - - This rule allows named - to defer the decision of whether to allow a - given update to an external daemon. - - - The method of communicating with the daemon is - specified in the identity - field, the format of which is - "local:path", - where path is the location - of a UNIX-domain socket. (Currently, "local" is the - only supported mechanism.) - - - Requests to the external daemon are sent over the - UNIX-domain socket as datagrams with the following - format: - - - Protocol version number (4 bytes, network byte order, currently 1) - Request length (4 bytes, network byte order) - Signer (null-terminated string) - Name (null-terminated string) - TCP source address (null-terminated string) - Rdata type (null-terminated string) - Key (null-terminated string) - TKEY token length (4 bytes, network byte order) - TKEY token (remainder of packet) - - The daemon replies with a four-byte value in - network byte order, containing either 0 or 1; 0 - indicates that the specified update is not - permitted, and 1 indicates that it is. - - - - - - - - - In all cases, the name - field must specify a fully-qualified domain name. - - - - If no types are explicitly specified, this rule matches - all types except RRSIG, NS, SOA, NSEC and NSEC3. Types - may be specified by name, including "ANY" (ANY matches - all types except NSEC and NSEC3, which can never be - updated). Note that when an attempt is made to delete - all records associated with a name, the rules are - checked for each existing record type. - - - - - Multiple views - - 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 - different clients to receive different answers for the same - queries. At times, however, it is desirable for multiple - views to contain identical zones. The - in-view zone option provides an efficient - 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; }; - - zone example.com { - type master; - file "example-external.db"; - }; -}; + + 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: + -view external { - match-clients { any; }; +attacker.example.com. A 192.0.2.1 - zone example.com { - in-view internal; - }; -}; - - - 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 - and forwarders. (These options control - the behavior of the containing view, rather than changing - the zone object itself.) - - - - - - - Zone File - - Types of Resource Records and When to Use Them - - 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. - - - Resource Records - - - 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 - separate RRs. The order of RRs in a set is not significant and - need not be preserved by name servers, resolvers, or other - parts of the DNS. However, sorting of multiple RRs is - permitted for optimization purposes, for example, to specify - that a particular nearby server be tried first. See and . - - - - The components of a Resource Record are: - - - - - - - - - - owner name - - - - - The domain name where the RR is found. - - - - - - - type - - - - - An encoded 16-bit value that specifies - the type of the resource record. - - - - - - - TTL - - - - - The time-to-live of the RR. This field - is a 32-bit integer 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 should be discarded. - - - - - - - class - - - - - An encoded 16-bit value that identifies - a protocol family or instance of a protocol. - - - - - - - RDATA - - - - - The resource data. The format of the - data is type (and sometimes class) specific. - - - - - - - - The following are types of valid RRs: - - - - - - - - - - A - - - - - A host address. In the IN class, this is a - 32-bit IP address. Described in RFC 1035. - - - - - - - AAAA - - - - - IPv6 address. Described in RFC 1886. - - - - - - - A6 - - - - - IPv6 address. This can be a partial - address (a suffix) and an indirection to the name - where the rest of the - address (the prefix) can be found. Experimental. - Described in RFC 2874. - - - - - - - AFSDB - - - - - Location of AFS database servers. - Experimental. Described in RFC 1183. - - - - - - - APL - - - - - Address prefix list. Experimental. - Described in RFC 3123. - - - - - - - CERT - - - - - Holds a digital certificate. - Described in RFC 2538. - - - - - - - CNAME - - - - - Identifies the canonical name of an alias. - Described in RFC 1035. - - - - - - - DHCID - - - - - Is used for identifying which DHCP client is - associated with this name. Described in RFC 4701. - - - - - - - DNAME - - - - - Replaces the domain name specified with - another name to be looked up, effectively aliasing an - entire - subtree of the domain name space rather than a single - record - as in the case of the CNAME RR. - Described in RFC 2672. - - - - - - - DNSKEY - - - - - Stores a public key associated with a signed - DNS zone. Described in RFC 4034. - - - - - - - DS - - - - - Stores the hash of a public key associated with a - signed DNS zone. Described in RFC 4034. - - - - - - - GPOS - - - - - Specifies the global position. Superseded by LOC. - - - - - - - HINFO - - - - - Identifies the CPU and OS used by a host. - Described in RFC 1035. - - - - - - - IPSECKEY - - - - - Provides a method for storing IPsec keying material in - DNS. Described in RFC 4025. - - - - - - - ISDN - - - - - Representation of ISDN addresses. - Experimental. Described in RFC 1183. - - - - - - - KEY - - - - - Stores a public key associated with a - DNS name. Used in original DNSSEC; replaced - by DNSKEY in DNSSECbis, but still used with - SIG(0). Described in RFCs 2535 and 2931. - - - - - - - KX - - - - - Identifies a key exchanger for this - DNS name. Described in RFC 2230. - - - - - - - LOC - - - - - For storing GPS info. Described in RFC 1876. - Experimental. - - - - - - - MX - - - - - Identifies a mail exchange for the domain with - a 16-bit preference value (lower is better) - followed by the host name of the mail exchange. - Described in RFC 974, RFC 1035. - - - - - - - NAPTR - - - - - Name authority pointer. Described in RFC 2915. - - - - - - - NSAP - - - - - A network service access point. - Described in RFC 1706. - - - - - - - NS - - - - - The authoritative name server for the - domain. Described in RFC 1035. - - - - - - - NSEC - - - - - Used in DNSSECbis to securely indicate that - RRs with an owner name in a certain name interval do - not exist in - a zone and indicate what RR types are present for an - existing name. - Described in RFC 4034. - - - - - - - NSEC3 - - - - - Used in DNSSECbis to securely indicate that - RRs with an owner name in a certain name - interval do not exist in a zone and indicate - what RR types are present for an existing - name. NSEC3 differs from NSEC in that it - prevents zone enumeration but is more - computationally expensive on both the server - and the client than NSEC. Described in RFC - 5155. - - - - - - - NSEC3PARAM - - - - - Used in DNSSECbis to tell the authoritative - server which NSEC3 chains are available to use. - Described in RFC 5155. - - - - - - - NXT - - - - - Used in DNSSEC to securely indicate that - RRs with an owner name in a certain name interval do - not exist in - a zone and indicate what RR types are present for an - existing name. - Used in original DNSSEC; replaced by NSEC in - DNSSECbis. - Described in RFC 2535. - - - - - - - PTR - - - - - A pointer to another part of the domain - name space. Described in RFC 1035. - - - - - - - PX - - - - - Provides mappings between RFC 822 and X.400 - addresses. Described in RFC 2163. - - - - - - - RP - - - - - Information on persons responsible - for the domain. Experimental. Described in RFC 1183. - - - - - - - RRSIG - - - - - Contains DNSSECbis signature data. Described - in RFC 4034. - - - - - - - RT - - - - - Route-through binding for hosts that - do not have their own direct wide area network - addresses. - Experimental. Described in RFC 1183. - - - - - - - SIG - - - - - Contains DNSSEC signature data. Used in - original DNSSEC; replaced by RRSIG in - DNSSECbis, but still used for SIG(0). - Described in RFCs 2535 and 2931. - - - - - - - SOA - - - - - Identifies the start of a zone of authority. - Described in RFC 1035. - - - - - - - SPF - - - - - Contains the Sender Policy Framework information - for a given email domain. Described in RFC 4408. - - - - - - - SRV - - - - - Information about well known network - services (replaces WKS). Described in RFC 2782. - - - - - - - SSHFP - - - - - Provides a way to securely publish a secure shell key's - fingerprint. Described in RFC 4255. - - - - - - - TXT - - - - - Text records. Described in RFC 1035. - - - - - - - WKS - - - - - Information about which well known - network services, such as SMTP, that a domain - supports. Historical. - - - - - - - X25 - - - - - Representation of X.25 network addresses. - Experimental. Described in RFC 1183. - - - - - - - - The following classes of resource records - are currently valid in the DNS: - - - - - - - - - - IN - - - - - The Internet. - - - - - - - - CH - - - - - Chaosnet, a LAN protocol created at MIT in the - mid-1970s. - Rarely used for its historical purpose, but reused for - BIND's - built-in server information zones, e.g., - version.bind. - - - - - - - - HS - - - - - Hesiod, an information service - developed by MIT's Project Athena. It is used to share - information - about various systems databases, such as users, - groups, printers - and so on. - - - - - - - - - - The owner name is often implicit, rather than forming an - integral - part of the RR. For example, many name servers internally form - tree - or hash structures for the name space, and chain RRs off nodes. - The remaining RR parts are the fixed header (type, class, TTL) - which is consistent for all RRs, and a variable part (RDATA) - 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 - data in zones; it is also timed out, but by the refreshing - policies - for the zone. The TTL is assigned by the administrator for the - zone where the data originates. While short TTLs can be used to - minimize caching, and a zero TTL prohibits caching, the - realities - of Internet performance suggest that these times should be on - the - order of days for the typical host. If a change can be - anticipated, - the TTL can be reduced prior to the change to minimize - inconsistency - during the change, and then increased back to its former value - 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. - - - - Textual expression of RRs - - RRs are represented in binary form in the packets of the DNS - protocol, and are usually represented in highly encoded form - when - stored in a name server or resolver. In the examples provided - in - RFC 1034, a style similar to that used in master files was - employed - in order to show the contents of RRs. In this format, most RRs - are shown on a single line, although continuation lines are - 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 - in - parsing, type and class mnemonics are disjoint, TTLs are - integers, - and the type mnemonic is always last. The IN class and TTL - 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: - - - - - - - - - - ISI.EDU. - - - - - MX - - - - - 10 VENERA.ISI.EDU. - - - - - - - - - - MX - - - - - 10 VAXA.ISI.EDU - - - - - - - VENERA.ISI.EDU - - - - - A - - - - - 128.9.0.32 - - - - - - - - - - A - - - - - 10.1.0.52 - - - - - - - VAXA.ISI.EDU - - - - - A - - - - - 10.2.0.27 - - - - - - - - - - A - - - - - 128.9.0.33 - - - - - - - - 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: - - - - - - - - - - XX.LCS.MIT.EDU. - - - - - IN A - - - - - 10.0.0.44 - - - - - - - - CH A - - - - - MIT.EDU. 2420 - - - - - - - - This example shows two addresses for - XX.LCS.MIT.EDU, each of a different class. - - - - - - Discussion of MX Records - - - 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, - but not always, a host). The simplest way to think of a RR is as - a typed pair of data, a domain name matched with a relevant datum, - 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 - controls the order in which email delivery is attempted, with the - lowest number first. If two priorities are the same, a server is - chosen randomly. If no servers at a given priority are responding, - the mail transport agent will fall back to the next largest - priority. - Priority numbers do not have any absolute meaning — they are - relevant - only respective to other MX records for that domain name. The - domain - name given is the machine to which the mail will be delivered. - 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, - the mail will be delivered to the server specified in the MX - record - pointed to by the CNAME. - For example: - - - - - - - - - - - - - example.com. - - - - - IN - - - - - MX - - - - - 10 - - - - - mail.example.com. - - - - - - - - - - IN - - - - - MX - - - - - 10 - - - - - mail2.example.com. - - - - - - - - - - IN - - - - - MX - - - - - 20 - - - - - mail.backup.org. - - - - - - - mail.example.com. - - - - - IN - - - - - A - - - - - 10.0.0.1 - - - - - - - - - - mail2.example.com. - - - - - IN - - - - - A - - - - - 10.0.0.2 - - - - - - - - - - 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. - - - - Setting TTLs - - 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 - should be discarded. The following three types of TTL are - currently - used in a zone file. - - - - - - - - - - SOA - - - - - The last field in the SOA is the negative - caching TTL. This controls how long other servers will - cache no-such-domain - (NXDOMAIN) responses from you. - - - The maximum time for - negative caching is 3 hours (3h). - - - - - - - $TTL - - - - - The $TTL directive at the top of the - zone file (before the SOA) gives a default TTL for every - RR without - a specific TTL set. - - - - - - - RR TTLs - - - - - Each RR can have a TTL as the second - field in the RR, which will control how long other - servers can cache - the it. - - - - - - - - All of these TTLs default to units of seconds, though units - can be explicitly specified, for example, 1h30m. - - - - Inverse Mapping in IPv4 - - 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 - least-to-most significant order, read left to right. This is the - opposite order to the way IP addresses are usually written. Thus, - a machine with an IP address of 10.1.2.3 would have a - corresponding - in-addr.arpa name of - 3.2.1.10.in-addr.arpa. This name should have a PTR resource record - whose data field is the name of the machine or, optionally, - multiple - PTR records if the machine has more than one name. For example, - in the example.com domain: - - - - - - - - - - $ORIGIN - - - - - 2.1.10.in-addr.arpa - - - - - - - 3 - - - - - IN PTR foo.example.com. - - - - - - - - - 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. - - - - - Other Zone File Directives - - The Master File Format was initially defined in RFC 1035 and - has subsequently been extended. While the Master File Format - itself - is class independent all records in a Master File must be of the - same - class. - - - Master File Directives include $ORIGIN, $INCLUDE, - and $TTL. - - - The <command>@</command> (at-sign) - - 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). - - - - The <command>$ORIGIN</command> Directive - - Syntax: $ORIGIN - domain-name - comment - - $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 - <zone_name>. - (followed by trailing dot). - The current $ORIGIN is appended to - the domain specified in the $ORIGIN - argument if it is not absolute. - + + 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. + - -$ORIGIN example.com. -WWW CNAME MAIN-SERVER - + + 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 + - - is equivalent to - +www.example.net. A 192.0.2.2 - -WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. - + + it will be accepted since the owner name "www.example.net" + matches the except-from element, + "example.net". + - - - The <command>$INCLUDE</command> Directive - - 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 - on whether the current - domain name should also be restored. BIND 9 restores both of - them. - This could be construed as a deviation from RFC 1035, a - feature, or both. - - - - - The <command>$TTL</command> Directive - - Syntax: $TTL - default-ttl - -comment - - - Set the default Time To Live (TTL) for subsequent records - with undefined TTLs. Valid TTLs are of the range 0-2147483647 - seconds. - - $TTL - is defined in RFC 2308. - - - - - <acronym>BIND</acronym> Master File Extension: the <command>$GENERATE</command> Directive - - Syntax: $GENERATE - range - lhs - ttl - class - type - rhs - comment - - $GENERATE - is used to create a series of resource records that only - differ from each other by an - iterator. $GENERATE can be used to - easily generate the sets of records required to support - sub /24 reverse delegations described in RFC 2317: - Classless IN-ADDR.ARPA delegation. - + + 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 + from the DNS point of view. + It might actually be provided for a legitimate purpose, + such as for debugging. + As long as the mapping is provided by the correct owner, + it is not possible or does not make sense to detect + whether the intent of the mapping is legitimate or not + within the DNS. + The "rebinding" attack must primarily be protected at the + application that uses the DNS. + For a large site, however, it may be difficult to protect + all possible applications at once. + This filtering feature is provided only to help such an + operational environment; + it is generally discouraged to turn it on unless you are + very sure you have no other choice and the attack is a + real threat for your applications. + -$ORIGIN 0.0.192.IN-ADDR.ARPA. -$GENERATE 1-2 @ NS SERVER$.EXAMPLE. -$GENERATE 1-127 $ CNAME $.0 + + 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 + applications conventionally rely on a DNS mapping from + some name to such an address. + Filtering out DNS records containing this address + spuriously can break such applications. + + - - is equivalent to - + + Response Policy Zone (RPZ) Rewriting + + BIND 9 includes a limited + mechanism to modify DNS responses for requests + analogous to email anti-spam DNS blacklists. + Responses can be changed to deny the existence of domains(NXDOMAIN), + deny the existence of IP addresses for domains (NODATA), + or contain other IP addresses or data. + -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. -2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA. -... -127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA. - + + 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. + Response policy zones are ordinary DNS zones containing RRsets + that can be queried normally if allowed. + It is usually best to restrict those queries with something like + allow-query { localhost; };. + - - 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 ." + + Five policy triggers can be encoded in RPZ records. + + + RPZ-CLIENT-IP + + + IP records are triggered by the IP address of the + DNS client. + Client IP address triggers are encoded in records that have + owner names that are subdomains of + rpz-client-ip relativized to the + policy zone origin name + and encode an address or address block. + IPv4 addresses are represented as + prefixlength.B4.B3.B2.B1.rpz-ip. + The IPv4 prefix length must be between 1 and 32. + All four bytes, B4, B3, B2, and B1, must be present. + B4 is the decimal value of the least significant byte of the + IPv4 address as in IN-ADDR.ARPA. + - - is equivalent to - + + IPv6 addresses are encoded in a format similar + to the standard IPv6 text representation, + prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-ip. + Each of W8,...,W1 is a one to four digit hexadecimal number + representing 16 bits of the IPv6 address as in the standard + text representation of IPv6 addresses, + but reversed as in IN-ADDR.ARPA. + All 8 words must be present except when one set of consecutive + zero words is replaced with .zz. + analogous to double colons (::) in standard IPv6 text + encodings. + The IPv6 prefix length must be between 64 and 128. + + + -HOST-1.EXAMPLE. A 1.2.3.1 -HOST-1.EXAMPLE. MX 0 . -HOST-2.EXAMPLE. A 1.2.3.2 -HOST-2.EXAMPLE. MX 0 . -HOST-3.EXAMPLE. A 1.2.3.3 -HOST-3.EXAMPLE. MX 0 . -... -HOST-127.EXAMPLE. A 1.2.3.127 -HOST-127.EXAMPLE. MX 0 . - + + QNAME + + + 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. + + + - - - - - - - - range - - - - This can be one of two forms: start-stop - or start-stop/step. If the first form is used, then step - is set to - 1. All of start, stop and step must be positive. - - - - - - lhs - - - This - describes the owner name of the resource records - to be created. Any single $ - (dollar sign) - symbols within the lhs string - are replaced by the iterator value. - - To get a $ in the output, you need to escape the - $ using a backslash - \, - e.g. \$. The - $ may optionally be followed - by modifiers which change the offset from the - iterator, field width and base. - - Modifiers are introduced by a - { (left brace) immediately following the - $ as - ${offset[,width[,base]]}. - For example, ${-20,3,d} - subtracts 20 from the current value, prints the - result as a decimal in a zero-padded field of - width 3. + + RPZ-IP + + + 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. + + + - Available output forms are decimal - (d), octal - (o), hexadecimal - (x or X - for uppercase) and nibble - (n or N\ - for uppercase). The default modifier is - ${0,0,d}. If the - lhs is not absolute, the - current $ORIGIN is appended - to the name. - - - In nibble mode the value will be treated as - if it was a reversed hexadecimal string - with each hexadecimal digit as a separate - label. The width field includes the label - separator. - - - For compatibility with earlier versions, - $$ is still recognized as - indicating a literal $ in the output. - - - - - - ttl - - - - Specifies the time-to-live of the generated records. If - not specified this will be inherited using the - normal TTL inheritance rules. - - class - and ttl can be - entered in either order. - - - - - - class - - - - Specifies the class of the generated records. - This must match the zone class if it is - specified. - - class - and ttl can be - entered in either order. - - - - - - type - - - - Any valid type. - - - - - - rhs - - - - rhs, optionally, quoted string. - - - - - - - - The $GENERATE directive is a BIND extension - and not part of the standard zone file format. - - - BIND 8 does not support the optional TTL and CLASS fields. - - + + RPZ-NSDNAME + + + 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. + They are encoded as subdomains of + rpz-nsdname relativized + to the RPZ origin name. + NSIP triggers match IP addresses in A and + AAAA RRsets for domains that can be checked against NSDNAME + policy records. + + + - - Additional File Formats - - 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. + + RPZ-NSIP + + + NSIP triggers are encoded like IP triggers except as + subdomains of rpz-nsip. + NSDNAME and NSIP triggers are checked only for names with at + least min-ns-dots dots. + The default value of min-ns-dots is 1 to + exclude top level domains. + + + + + - 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 - directly into memory via the mmap() - function; the zone can begin serving queries almost - immediately. + 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 + policy record, a single record encoding an action (other than + DISABLED actions) must be chosen. + Triggers or the records that encode them are chosen for the + rewriting in the following order: + + Choose the triggered record in the zone that appears + first in the response-policy option. + + Prefer CLIENT-IP to QNAME to IP to NSDNAME to NSIP + triggers in a single zone. + + Among NSDNAME triggers, prefer the + trigger that matches the smallest name under the DNSSEC ordering. + + Among IP or NSIP triggers, prefer the trigger + with the longest prefix. + + Among triggers with the same prefex length, + prefer the IP or NSIP trigger that matches + the smallest IP address. + + + - For a primary server, a zone file in - raw or map - format is expected to be generated from a textual zone - file by the named-compilezone command. - For a secondary server or for a dynamic zone, it is automatically - generated (if this format is specified by the - masterfile-format option) when - named dumps the zone contents after - zone transfer or when applying prior updates. + 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. + - 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 - necessary modification should go to the text file, which - 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 - with different pointer size, endianness or data alignment - than the system on which it was generated, and should in - general be used only inside a single system. - While raw format uses - network byte order and avoids architecture-dependent - data alignment so that it is as portable as - possible, it is also primarily expected to be used - inside the same single system. To export a - zone file in either raw or - map format, or make a - portable backup of such a file, conversion to - text format is recommended. - - - + RPZ record sets are any types of DNS record except + DNAME or DNSSEC that encode actions or responses to + individual queries. + Any of the policies can be used with any of the triggers. + For example, while the TCP-only policy is + commonly used with client-IP triggers, + it cn be used with any type of trigger to force the use of + TCP for responses with owner names in a zone. + + + PASSTHRU + + + 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. + + + - - BIND9 Statistics - - BIND 9 maintains lots of statistics - information and provides several interfaces for users to - get access to the statistics. - The available statistics include all statistics counters - that were available in BIND 8 and - are meaningful in BIND 9, - and other information that is considered useful. - + + DROP + + + 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 statistics information is categorized into the following - sections. - + + TCP-Only + + + 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. + + + - - - - - + + NXDOMAIN + + + The domain undefined response is encoded + by a CNAME whose target is the root domain (.) + + + - - - Incoming Requests - - - - The number of incoming DNS requests for each OPCODE. - - - + + NODATA + + + 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=1. + + + - - - Incoming Queries - - - - The number of incoming queries for each RR type. - - - + + Local Data + + + A set of ordinary DNS records can be used to answer queries. + Queries for record types not the set are answered with + NODATA. + - - - Outgoing Queries - - - - The number of outgoing queries for each RR - type sent from the internal resolver. - Maintained per view. - - - + + 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 astrisk (*) + has been replaced with the query name. + The purpose for this special form is query logging in the + walled garden's authority DNS server. + + + + + - - - Name Server Statistics - - - - Statistics counters about incoming request processing. - - - + + All of the actions specified in all of the individual records + in a policy zone + can be overridden with a policy clause in the + response-policy option. + An organization using a policy zone provided by another + organization might use this mechanism to redirect domains + to its own walled garden. + + + GIVEN + + The placeholder policy says "do not override but + perform the action specified in the zone." + + + - - - Zone Maintenance Statistics - - - - Statistics counters regarding zone maintenance - operations such as zone transfers. - - - + + DISABLED + + + 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. + The response to the DNS query will be written (or not) + according to any triggered policy records that are not + disabled. + Disabled policy zones should appear first, + because they will often not be logged + if a higher precedence trigger is found first. + + + - - - Resolver Statistics - - - - Statistics counters about name resolution - performed in the internal resolver. - Maintained per view. - - - + + PASSTHRU, + DROP, + TCP-Only, + NXDOMAIN, + and + NODATA + + + override with the corresponding per-record policy. + + + - - - Cache DB RRsets - - - - The number of RRsets per RR type and nonexistent - names stored in the cache database. - If the exclamation mark (!) is printed for a RR - type, it means that particular type of RRset is - known to be nonexistent (this is also known as - "NXRRSET"). If a hash mark (#) is present then - the RRset is marked for garbage collection. - Maintained per view. - - - + + CNAME domain + + + causes all RPZ policy records to act as if they were + "cname domain" records. + + + + + - - - Socket I/O Statistics - - - - Statistics counters about network related events. - - - + + 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 + all response policy zones in a view + with a recursive-only no clause. + This feature is useful for serving the same zone files + both inside and outside an RFC 1918 cloud and using RPZ to + 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 + zone (not the response policy zone). This default can be + changed for all response policy zones in a view with a + break-dnssec yes clause. In that case, RPZ + actions are applied regardless of DNSSEC. The name of the + clause option reflects the fact that results rewritten by RPZ + actions cannot verify. + - - 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 - yes. - These statistics counters are shown with their zone and view - names. - In some cases the view names are omitted for the default view. - + + 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. + However, not resolving the requested + name can leak the fact that response policy rewriting is in use + and that the name is listed in a policy zone to operators of + servers for listed names. To prevent that information leak, by + default any recursion needed for a request is done before any + policy triggers are considered. Because listed domains often + have slow authoritative servers, this default behavior can cost + significant time. + The qname-wait-recurse no option + overrides that default behavior when recursion cannot + change a non-error response. + The option does not affect QNAME or client-IP triggers + in policy zones listed + after other zones containing IP, NSIP and NSDNAME triggers, because + those may depend on the A, AAAA, and NS records that would be + found during recursive resolution. It also does not affect + DNSSEC requests (DO=1) unless break-dnssec yes + is in use, because the response would depend on whether or not + RRSIG records were found during resolution. + The option can cause appear to rewrite error responses + such as SERVFAIL when no recursion is done to discover problems + at the authoritative server. + - - There are currently two user interfaces to get access to the - statistics. - One is in the plain text format dumped to the file specified - by the statistics-file configuration option. - The other is remotely accessible via a statistics channel - when the statistics-channels statement - is specified in the configuration file - (see .) - + + 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. + The max-policy-ttl clause changes that + maximum from its default of 5. + - - The Statistics File - - The text format statistics dump begins with a line, like: + + For example, you might use this option statement - - +++ Statistics Dump +++ (973798949) + response-policy { zone "badlist"; }; + + and this zone statement + zone "badlist" {type master; file "master/badlist"; allow-query {none;}; }; - The number in parentheses is a standard - Unix-style timestamp, measured as seconds since January 1, 1970. + with this zone file + +$TTL 1H +@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h) + NS LOCALHOST. - Following - that line is a set of statistics information, which is categorized - as described above. - Each section begins with a line, like: +; QNAME policy records. There are no periods (.) after the owner names. +nxdomain.domain.com CNAME . ; NXDOMAIN policy +*.nxdomain.domain.com CNAME . ; NXDOMAIN policy +nodata.domain.com CNAME *. ; NODATA policy +*.nodata.domain.com CNAME *. ; NODATA policy +bad.domain.com A 10.0.0.1 ; redirect to a walled garden + AAAA 2001:2::1 +bzone.domain.com CNAME garden.example.com. + +; do not rewrite (PASSTHRU) OK.DOMAIN.COM +ok.domain.com CNAME rpz-passthru. + +; redirect x.bzone.domain.com to x.bzone.domain.com.garden.example.com +*.bzone.domain.com CNAME *.garden.example.com. + + +; IP policy records that rewrite all responses containing A records in 127/8 +; except 127.0.0.1 +8.0.0.0.127.rpz-ip CNAME . +32.1.0.0.127.rpz-ip CNAME rpz-passthru. + +; NSDNAME and NSIP policy records +ns.domain.com.rpz-nsdname CNAME . +48.zz.2.2001.rpz-nsip CNAME . + +; blacklist and whitelist some DNS clients +112.zz.2001.rpz-client-ip CNAME rpz-drop. +8.0.0.0.127.rpz-client-ip CNAME rpz-drop. + +; force some DNS clients and responses in the example.com zone to TCP +16.0.0.1.10.rpz-client-ip CNAME rpz-tcp-only. +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 + query can be answered. + For example, a DNS server with four policy zones, each with all + four kinds of response triggers, QNAME, IP, NSIP, and + NSDNAME, requires a total of 17 times as many database + lookups as a similar DNS server with no response policy zones. + A BIND9 server with adequate memory and one + response policy zone with QNAME and IP triggers might achieve a + maximum queries-per-second rate about 20% lower. + A server with four response policy zones with QNAME and IP + triggers might have a maximum QPS rate about 50% lower. - ++ Name Server Statistics ++ + Responses rewritten by RPZ are counted in the + RPZRewrites statistics. + + + Response Rate Limiting - 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. + Excessive almost identical UDP responses + can be controlled by configuring a + rate-limit clause in an + options or view statement. + This mechanism keeps authoritative BIND 9 from being used + in amplifying reflection denial of service (DoS) attacks. + Short truncated (TC=1) responses can be sent to provide + rate-limited responses to legitimate clients within + a range of forged, attacked IP addresses. + Legitimate clients react to dropped or truncated response + by retrying with UDP or with TCP respectively. - The statistics dump ends with the line where the - number is identical to the number in the beginning line; for example: - - - --- Statistics Dump --- (973798949) - - + 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 + HTTP clients (web browsers) that repeatedly request the + same domains. + When possible, closing "open" recursive servers is better. + - - Statistics Counters - The following tables summarize statistics counters that - BIND 9 provides. - For each row of the tables, the leftmost column is the - abbreviated symbol name of that counter. - These symbols are shown in the statistics information - accessed via an HTTP statistics channel. - The rightmost column gives the description of the counter, - which is also shown in the statistics file - (but, in this document, possibly with slight modification - for better readability). - Additional notes may also be provided in this column. - When a middle column exists between these two columns, - it gives the corresponding counter name of the - BIND 8 statistics, if applicable. + 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 + of credits every second. + A prospective response debits its account by one. + Responses are dropped or truncated + while the account is negative. + Responses are tracked within a rolling window of time + which defaults to 15 seconds, but can be configured with + the window option to any value from + 1 to 3600 seconds (1 hour). + The account cannot become more positive than + the per-second limit + or more negative than window + times the per-second limit. + When the specified number of credits for a class of + responses is set to 0, those responses are not rate limited. - - Name Server Statistics Counters + + 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 + single client. + The prefix lengths of addresses blocks are + specified with ipv4-prefix-length (default 24) + and ipv6-prefix-length (default 56). + - - - - - - - - - - Symbol - - - - - BIND8 Symbol - - - - - Description - - - + + 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 + (default 0 or no limit). + All empty (NODATA) responses for a valid domain, + regardless of query type, are identical. + Responses in the NODATA class are limited by + nodata-per-second + (default responses-per-second). + Requests for any and all undefined subdomains of a given + valid domain result in NXDOMAIN errors, and are identical + regardless of query type. + They are limited by nxdomain-per-second + (default responses-per-second). + This controls some attacks using random names, but + can be relaxed or turned off (set to 0) + on servers that expect many legitimate + NXDOMAIN responses, such as from anti-spam blacklists. + Referrals or delegations to the server of a given + domain are identical and are limited by + referrals-per-second + (default responses-per-second). + - - - Requestv4 - - - RQ - - - - IPv4 requests received. - Note: this also counts non query requests. - - - - - - Requestv6 - - - RQ - - - - IPv6 requests received. - Note: this also counts non query requests. - - - - - - ReqEdns0 - - - - - - - Requests with EDNS(0) received. - - - - - - ReqBadEDNSVer - - - - - - - Requests with unsupported EDNS version received. - - - - - - ReqTSIG - - - - - - - Requests with TSIG received. - - - - - - ReqSIG0 - - - - - - - Requests with SIG(0) received. - - - - - - ReqBadSIG - - - - - - - Requests with invalid (TSIG or SIG(0)) signature. - - - - - - ReqTCP - - - RTCP - - - - TCP requests received. - - - - - - AuthQryRej - - - RUQ - - - - Authoritative (non recursive) queries rejected. - - - - - - RecQryRej - - - RURQ - - - - Recursive queries rejected. - - - - - - XfrRej - - - RUXFR - - - - Zone transfer requests rejected. - - - - - - UpdateRej - - - RUUpd - - - - Dynamic update requests rejected. - - - - - - Response - - - SAns - - - - Responses sent. - - - - - - RespTruncated - - - - - - - Truncated responses sent. - - - - + + 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). + This controls attacks using invalid requests or distant, + broken authoritative servers. + By default the limit on errors is the same as the + responses-per-second value, + 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 + with responses to requests with forged source addresses, + but could let a third party block responses to legitimate requests. + There is a mechanism that can answer some legitimate + requests from a client whose address is being forged in a flood. + Setting slip to 2 (its default) causes every + other UDP request to be answered with a small truncated (TC=1) + response. + The small size and reduced frequency, and so lack of + amplification, of "slipped" responses make them unattractive + for reflection DoS attacks. + slip must be between 0 and 10. + A value of 0 does not "slip": + no truncated responses are sent due to rate limiting, + all responses are dropped. + A value of 1 causes every response to slip; + values between 2 and 10 cause every n'th response to slip. + Some error responses including REFUSED and SERVFAIL + 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 + against forged responses is for authoritative operators + to sign their zones using DNSSEC and for resolver operators + to validate the responses. When this is not an option, + operators who are more concerned with response integrity + than with flood mitigation may consider setting + slip to 1, causing all rate-limited + 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, + errors-per-second, + nxdomains-per-second and + all-per-second values are reduced by the + ratio of the current rate to the qps-scale value. + This feature can tighten defenses during attacks. + For example, with + qps-scale 250; responses-per-second 20; and + a total query rate of 1000 queries/second for all queries from + all DNS clients including via TCP, + then the effective responses/second limit changes to + (250/1000)*20 or 5. + 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 + statements instead of the global option + statement. + A rate-limit statement in a view replaces, + rather than supplementing, a rate-limit + statement among the main options. + 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 + responses-per-second, + errors-per-second, and + nxdomains-per-second on a DNS server + which are often invisible to the victim of a DNS reflection attack. + Unless the forged requests of the attack are the same as the + legitimate requests of the victim, the victim's requests are + not affected. + Responses affected by an all-per-second limit + are always dropped; the slip value has no + effect. + An all-per-second limit should be + at least 4 times as large as the other limits, + because single DNS clients often send bursts of legitimate + requests. + For example, the receipt of a single mail message can prompt + requests from an SMTP server for NS, PTR, A, and AAAA records + as the incoming SMTP/TCP/IP connection is considered. + The SMTP server can need additional NS, A, AAAA, MX, TXT, and SPF + records as it considers the STMP Mail From + command. + Web browsers often repeatedly resolve the same names that + are repeated in HTML <IMG> tags in a page. + All-per-second is similar to the + rate limiting offered by firewalls but often inferior. + Attacks that justify ignoring the + contents of DNS responses are likely to be attacks on the + DNS server itself. + They usually should be discarded before the DNS server + spends resources making TCP connections 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. + The table needs approximately as many entries as the number + of requests received per second. + The default is 20,000. + To reduce the cold start of growing the table, + min-table-size (default 500) + can set the minimum table size. + Enable rate-limit category logging to monitor + 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. + + + + + + <command>server</command> Statement Grammar + +server ip_addr[/prefixlen] { + bogus yes_or_no ; + provide-ixfr yes_or_no ; + request-ixfr yes_or_no ; + edns yes_or_no ; + edns-udp-size number ; + max-udp-size number ; + transfers number ; + transfer-format ( one-answer | many-answers ) ; ] + keys { string ; string ; ... } ; + transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; + transfer-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; + notify-source (ip4_addr | *) port ip_port dscp ip_dscp ; + notify-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; + query-source address ( ip_addr | * ) + port ( ip_port | * ) dscp ip_dscp ; + query-source-v6 address ( ip_addr | * ) + port ( ip_port | * ) dscp ip_dscp ; + use-queryport-pool yes_or_no; + queryport-pool-ports number; + queryport-pool-updateinterval number; +}; + + + + + + <command>server</command> Statement Definition and + Usage + + + The server statement defines + characteristics + to be associated with a remote name server. If a prefix length is + specified, then a range of servers is covered. Only the most + specific + 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 + statement. + If a view statement contains + one or more server statements, only + those + apply to the view and any top-level ones are ignored. + If a view contains no server + statements, + any top-level server statements are + 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 + incremental + zone transfer when the given remote server, a slave, requests it. + If set to yes, incremental transfer + will be provided + whenever possible. If set to no, + all transfers + to the remote server will be non-incremental. If not set, the + value + of the provide-ixfr option in the + 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 + transfers from the given remote server, a master. If not set, the + value of the request-ixfr option in + the view or global options block is used as a default. It may + 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 + which servers support IXFR and which ones do not; the global + default + of yes should always work. + The purpose of the provide-ixfr and + request-ixfr clauses is + to make it possible to disable the use of IXFR even when both + master + 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 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 to 4096 bytes (values outside this range will be + silently adjusted). This option is useful when you wish to + advertises a different value to this server than the value you + advertise globally, for example, when there is a firewall at the + remote site that is blocking large replies. + + + + The max-udp-size option sets the + maximum EDNS UDP message size named will send. Valid + values are 512 to 4096 bytes (values outside this range will + be silently adjusted). This option is useful when you + know that there is a firewall that is blocking large + replies from named. + + + + 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 + more efficient, but is only known to be understood by BIND 9, BIND + 8.x, and patched versions of BIND + 4.9.5. You can specify which method + to use for a server with the transfer-format option. + If transfer-format is not + specified, the transfer-format + specified + by the options statement will be + used. + + + 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, ) + when talking to the remote server. + When a request is sent to the remote server, a request signature + will be generated using the key specified here and appended to the + message. A request originating from the remote server is not + required + to be signed by this key. + + + + Although the grammar of the keys + clause + allows for multiple keys, only a single key per server is + currently + supported. + + + + The transfer-source and + transfer-source-v6 clauses specify + the IPv4 and IPv6 source + address to be used for zone transfer with the remote server, + respectively. + For an IPv4 remote server, only transfer-source can + be specified. + Similarly, for an IPv6 remote server, only + transfer-source-v6 can be + specified. + For more details, see the description of + transfer-source and + transfer-source-v6 in + . + + + + The notify-source and + notify-source-v6 clauses specify the + IPv4 and IPv6 source address to be used for notify + messages sent to remote servers, respectively. For an + IPv4 remote server, only notify-source + 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 + sent to remote servers, respectively. For an IPv4 + remote server, only query-source can + be specified. Similarly, for an IPv6 remote server, + only query-source-v6 can be specified. + + + + + + <command>statistics-channels</command> Statement Grammar + +statistics-channels { + [ inet ( ip_addr | * ) [ port ip_port ] + [ allow { address_match_list } ]; ] + [ inet ...; ] +}; + + + + + <command>statistics-channels</command> Statement Definition and + Usage + + + 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. + It requires that BIND 9 be compiled with libxml2 and/or + json-c (also known as libjson0); the + statistics-channels statement is + 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 + address. An ip_addr of * + (asterisk) is + interpreted as the IPv4 wildcard address; connections will be + accepted on any of the system's IPv4 addresses. + 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 + address_match_list. + If no allow clause is present, + named accepts connection + attempts from any address; since the statistics may + contain sensitive internal information, it is highly + 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 + port 8888, then the statistics are accessible in XML format at + http://127.0.0.1:8888/ or + http://127.0.0.1:8888/xml. A CSS file is + included which can format the XML statistics into tables + when viewed with a stylesheet-capable browser, and into + charts and graphs using the Google Charts API when using a + javascript-capable browser. + + + + Applications that depend on a particular XML schema + can request + http://127.0.0.1:8888/xml/v2 for version 2 + of the statistics XML schema or + http://127.0.0.1:8888/xml/v3 for version 3. + If the requested schema is supported by the server, then + it will respond; if not, it will return a "page not found" + error. + + + + 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), + http://127.0.0.1:8888/xml/v3/server + (server and resolver statistics), + http://127.0.0.1:8888/xml/v3/zones + (zone statistics), + http://127.0.0.1:8888/xml/v3/net + (network status and socket statistics), + http://127.0.0.1:8888/xml/v3/mem + (memory manager statistics), + http://127.0.0.1:8888/xml/v3/tasks + (task manager statistics). + + + + 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 + http://127.0.0.1:8888/json/v1/status + (server uptime and last reconfiguration time), + http://127.0.0.1:8888/json/v1/server + (server and resolver statistics), + http://127.0.0.1:8888/json/v1/zones + (zone statistics), + http://127.0.0.1:8888/json/v1/net + (network status and socket statistics), + http://127.0.0.1:8888/json/v1/mem + (memory manager statistics), + http://127.0.0.1:8888/json/v1/tasks + (task manager statistics). + + + + + <command>trusted-keys</command> Statement Grammar + +trusted-keys { + string number number number string ; + string number number number string ; ... +}; + + + + + <command>trusted-keys</command> Statement Definition + and Usage + + The trusted-keys statement defines + DNSSEC security roots. DNSSEC is described in . A security root is defined when the + public key for a non-authoritative zone is known, but + cannot be securely obtained through DNS, either because + it is the DNS root zone or because its parent zone is + unsigned. Once a key has been configured as a trusted + key, it is treated as if it had been validated and + proven secure. The resolver attempts DNSSEC validation + on all DNS data in subdomains of a security root. + + + All keys (and corresponding zones) listed in + trusted-keys are deemed to exist regardless + of what parent zones say. Similarly for all keys listed in + trusted-keys only those keys are + used to validate the DNSKEY RRset. The parent's DS RRset + will not be used. + + + The trusted-keys statement can contain + multiple key entries, each consisting of the key's + domain name, flags, protocol, algorithm, and the Base-64 + representation of the key data. + Spaces, tabs, newlines and carriage returns are ignored + in the key data, so the configuration may be split up into + multiple lines. + + + trusted-keys may be set at the top level + of named.conf or within a view. If it is + set in both places, they 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. + + + + + <command>managed-keys</command> Statement Grammar + +managed-keys { + name initial-key flags protocol algorithm key-data ; + name initial-key flags protocol algorithm key-data ; ... +}; + + + + + <command>managed-keys</command> Statement Definition + and Usage + + The managed-keys statement, like + trusted-keys, defines DNSSEC + security roots. The difference is that + managed-keys can be kept up to date + automatically, without intervention from the resolver + operator. + + + 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 old key in a + trusted-keys statement would be + unable to validate this zone any longer; it would + reply with a SERVFAIL response code. This would + continue until the resolver operator had updated the + trusted-keys statement with the new key. + + + If, however, the zone were listed in a + managed-keys statement instead, then the + zone owner could add a "stand-by" key to the zone in advance. + named would store the stand-by key, and + when the original key was revoked, named + would be able to transition smoothly to the new key. It would + also recognize that the old key had been revoked, and cease + using that key to validate answers, minimizing the damage that + the compromised key could do. + + + A managed-keys statement contains a list of + the keys to be managed, along with information about how the + keys are to be initialized for the first time. The only + initialization method currently supported (as of + BIND 9.7.0) is initial-key. + This means the managed-keys statement must + contain a copy of the initializing key. (Future releases may + allow keys to be initialized by other methods, eliminating this + requirement.) + + + Consequently, a managed-keys statement + appears similar to a trusted-keys, differing + in the presence of the second field, containing the keyword + initial-key. The difference is, whereas the + keys listed in a trusted-keys continue to be + trusted until they are removed from + named.conf, an initializing key listed + in a managed-keys statement is only trusted + once: for as long as it takes to load the + managed key database and start the RFC 5011 key maintenance + process. + + + The first time named runs with a managed key + configured in named.conf, it fetches the + DNSKEY RRset directly from the zone apex, and validates it + using the key specified in the managed-keys + statement. If the DNSKEY RRset is validly signed, then it is + used as the basis for a new managed keys database. + + + From that point on, whenever named runs, it + sees the managed-keys statement, checks to + make sure RFC 5011 key maintenance has already been initialized + for the specified domain, and if so, it simply moves on. The + key specified in the managed-keys is not + used to validate answers; it has been superseded by the key or + keys stored in the managed keys database. + + + The next time named runs after a name + has been removed from the + managed-keys statement, the corresponding + zone will be removed from the managed keys database, + and RFC 5011 key maintenance will no longer be used for that + domain. + + + named only maintains a single managed keys + database; consequently, unlike trusted-keys, + managed-keys may only be set at the top + level of named.conf, not within a view. + + + In the current implementation, the managed keys database is + stored as a master-format zone file called + managed-keys.bind. When the key database + is changed, the zone is updated. As with any other dynamic + zone, changes will be written into a journal file, + managed-keys.bind.jnl. They are committed + to the master file as soon as possible afterward; in the case + of the managed key database, this will usually occur within 30 + seconds. So, whenever named is using + automatic key maintenance, those two files can be expected to + exist in the working directory. (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 a managed key for the + root zone. Similarly, if the dnssec-lookaside + option is set to auto, + named will automatically initialize + a managed key for the zone dlv.isc.org. + In both cases, the key that is used to initialize the key + maintenance process is built into named, + and can be overridden from bindkeys-file. + + + + + <command>view</command> Statement Grammar + +view view_name + class { + match-clients { address_match_list }; + match-destinations { address_match_list }; + match-recursive-only yes_or_no ; + view_option; ... + zone_statement; ... +}; + + + + + <command>view</command> Statement Definition and Usage + + + The view statement is a powerful + feature + of BIND 9 that lets a name server + answer a DNS query differently + depending on who is asking. It is particularly useful for + 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 + matches + a view if its source IP address matches the + address_match_list of the view's + match-clients clause and its + destination IP address matches + the address_match_list of the + view's + match-destinations clause. If not + specified, both + match-clients and match-destinations + default to matching all addresses. In addition to checking IP + addresses + match-clients and match-destinations + can also take keys which provide an + mechanism for the + client to select the view. A view can also be specified + as match-recursive-only, which + means that only recursive + requests from matching clients will match that view. + The order of the view statements is + significant — + 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. + By defining a zone of the same name in multiple views, different + zone data can be given to different clients, for example, + "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 + apply only when resolving queries with that view. When no + view-specific + value is given, the value in the options statement + is used as a default. Also, zone options can have default values + specified + in the view statement; these + 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 + created + in class IN. Any zone statements + specified on + the top level of the configuration file are considered to be part + of + this default view, and the options + statement will + apply to the default view. If any explicit view + statements are present, all zone + 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; }; + + // Provide recursive service to internal + // clients only. + recursion yes; + + // Provide a complete view of the example.com + // zone including addresses of internal hosts. + zone "example.com" { + type master; + file "example-internal.db"; + }; +}; + +view "external" { + // Match all clients not matched by the + // previous view. + match-clients { any; }; + + // Refuse recursive service to external clients. + recursion no; + + // Provide a restricted view of the example.com + // zone containing only publicly accessible hosts. + zone "example.com" { + type master; + file "example-external.db"; + }; +}; + + + + + <command>zone</command> + Statement Grammar + +zone zone_name class { + type master; + allow-query { address_match_list }; + allow-query-on { address_match_list }; + allow-transfer { address_match_list }; + allow-update { address_match_list }; + update-check-ksk yes_or_no; + dnssec-dnskey-kskonly yes_or_no; + dnssec-loadkeys-interval number; + update-policy local | { update_policy_rule ... }; + also-notify { ip_addr port ip_port dscp ip_dscp ; + ip_addr port ip_port dscp ip_dscp ; ... }; + check-names (warn|fail|ignore) ; + check-mx (warn|fail|ignore) ; + check-wildcard yes_or_no; + check-spf ( warn | fail | ignore ); + check-integrity yes_or_no ; + dialup dialup_option ; + file string ; + masterfile-format (text|raw|map) ; + journal string ; + max-journal-size size_spec; + forward (only|first) ; + forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; + ixfr-base string ; + ixfr-from-differences yes_or_no; + ixfr-tmp-file string ; + request-ixfr yes_or_no ; + maintain-ixfr-base yes_or_no ; + max-ixfr-log-size number ; + max-transfer-idle-out number ; + max-transfer-time-out number ; + notify yes_or_no | explicit | master-only ; + notify-delay seconds ; + notify-to-soa yes_or_no; + pubkey number number number string ; + notify-source (ip4_addr | *) port ip_port dscp ip_dscp ; + notify-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; + zone-statistics full | terse | none; + sig-validity-interval number number ; + sig-signing-nodes number ; + sig-signing-signatures number ; + sig-signing-type number ; + database string ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + key-directory path_name; + auto-dnssec allow|maintain|off; + inline-signing yes_or_no; + zero-no-soa-ttl yes_or_no ; + serial-update-method increment|unixtime; +}; + +zone zone_name class { + type slave; + allow-notify { address_match_list }; + allow-query { address_match_list }; + allow-query-on { address_match_list }; + allow-transfer { address_match_list }; + allow-update-forwarding { address_match_list }; + dnssec-update-mode ( maintain | no-resign ); + update-check-ksk yes_or_no; + dnssec-dnskey-kskonly yes_or_no; + dnssec-loadkeys-interval number; + dnssec-secure-to-insecure yes_or_no ; + try-tcp-refresh yes_or_no; + also-notify port ip_port dscp ip_dscp { ( masters_list | ip_addr + port ip_port + dscp ip_dscp + key key ) ; ... }; + check-names (warn|fail|ignore) ; + dialup dialup_option ; + file string ; + masterfile-format (text|raw|map) ; + journal string ; + max-journal-size size_spec; + forward (only|first) ; + forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; + ixfr-base string ; + ixfr-from-differences yes_or_no; + ixfr-tmp-file string ; + maintain-ixfr-base yes_or_no ; + masters port ip_port dscp ip_dscp { ( masters_list | ip_addr + port ip_port + dscp ip_dscp + key key ) ; ... }; + max-ixfr-log-size number ; + max-transfer-idle-in number ; + max-transfer-idle-out number ; + max-transfer-time-in number ; + max-transfer-time-out number ; + notify yes_or_no | explicit | master-only ; + notify-delay seconds ; + notify-to-soa yes_or_no; + pubkey number number number string ; + transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; + transfer-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; + alt-transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; + alt-transfer-source-v6 (ip6_addr | *) + port ip_port + dscp ip_dscp ; + use-alt-transfer-source yes_or_no; + notify-source (ip4_addr | *) port ip_port dscp ip_dscp ; + notify-source-v6 (ip6_addr | *) port ip_port dscp ip_dscp ; + zone-statistics full | terse | none; + sig-validity-interval number number ; + sig-signing-nodes number ; + sig-signing-signatures number ; + sig-signing-type number ; + database string ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + key-directory path_name; + auto-dnssec allow|maintain|off; + inline-signing yes_or_no; + multi-master yes_or_no ; + zero-no-soa-ttl yes_or_no ; +}; + +zone zone_name class { + type hint; + file string ; + delegation-only yes_or_no ; + check-names (warn|fail|ignore) ; // Not Implemented. +}; + +zone zone_name class { + type stub; + allow-query { address_match_list }; + allow-query-on { address_match_list }; + check-names (warn|fail|ignore) ; + dialup dialup_option ; + delegation-only yes_or_no ; + file string ; + masterfile-format (text|raw|map) ; + forward (only|first) ; + forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; + masters port ip_port dscp ip_dscp { ( masters_list | ip_addr + port ip_port + dscp ip_dscp + key key ) ; ... }; + max-transfer-idle-in number ; + max-transfer-time-in number ; + pubkey number number number string ; + transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; + transfer-source-v6 (ip6_addr | *) + port ip_port dscp ip_dscp ; + alt-transfer-source (ip4_addr | *) port ip_port dscp ip_dscp ; + alt-transfer-source-v6 (ip6_addr | *) + port ip_port dscp ip_dscp ; + use-alt-transfer-source yes_or_no; + zone-statistics yes_or_no ; + database string ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + multi-master yes_or_no ; +}; + +zone zone_name class { + type static-stub; + allow-query { address_match_list }; + server-addresses { ip_addr ; ... }; + server-names { namelist }; + zone-statistics yes_or_no ; +}; + +zone zone_name class { + type forward; + forward (only|first) ; + forwarders { ip_addr port ip_port dscp ip_dscp ; ... }; + delegation-only yes_or_no ; +}; + +zone "." class { + type redirect; + file string ; + masterfile-format (text|raw|map) ; + allow-query { address_match_list }; +}; + +zone zone_name class { + type delegation-only; +}; + +zone zone_name class { + in-view string ; +}; + + + + + + <command>zone</command> Statement Definition and Usage + + Zone Types + + + + + + + + + + + master + + + + + The server has a master copy of the data + for the zone and will be able to provide authoritative + answers for + it. + + + + + + + slave + + + + + A slave zone is a replica of a master + zone. The masters list + specifies one or more IP addresses + of master servers that the slave contacts to update + its copy of the zone. + Masters list elements can also be names of other + masters lists. + By default, transfers are made from port 53 on the + servers; this can + be changed for all servers by specifying a port number + before the + list of IP addresses, or on a per-server basis after + the IP address. + Authentication to the master can also be done with + per-server TSIG keys. + If a file is specified, then the + replica will be written to this file whenever the zone + is changed, + and reloaded from this file on a server restart. Use + of a file is + recommended, since it often speeds server startup and + eliminates + a needless waste of bandwidth. Note that for large + numbers (in the + tens or hundreds of thousands) of zones per server, it + is best to + use a two-level naming scheme for zone filenames. For + example, + a slave server for the zone example.com might place + the zone contents into a file called + ex/example.com where ex/ is + just the first two letters of the zone name. (Most + operating systems + behave very slowly if you put 100000 files into + a single directory.) + + + + + + + stub + + + + + A stub zone is similar to a slave zone, + except that it replicates only the NS records of a + master zone instead + of the entire zone. Stub zones are not a standard part + of the DNS; + they are a feature specific to the BIND implementation. + + + + Stub zones can be used to eliminate the need for glue + NS record + in a parent zone at the expense of maintaining a stub + zone entry and + a set of name server addresses in named.conf. + This usage is not recommended for new configurations, + and BIND 9 + supports it only in a limited way. + In BIND 4/8, zone + transfers of a parent zone + included the NS records from stub children of that + zone. This meant + that, in some cases, users could get away with + configuring child stubs + only in the master server for the parent zone. BIND + 9 never mixes together zone data from different zones + in this + way. Therefore, if a BIND 9 master serving a parent + zone has child stub zones configured, all the slave + servers for the + parent zone also need to have the same child stub + zones + configured. + + + + Stub zones can also be used as a way of forcing the + resolution + of a given domain to use a particular set of + authoritative servers. + For example, the caching name servers on a private + network using + RFC1918 addressing may be configured with stub zones + for + 10.in-addr.arpa + to use a set of internal name servers as the + authoritative + servers for that domain. + + + + + + + static-stub + + + + + A static-stub zone is similar to a stub zone + with the following exceptions: + the zone data is statically configured, rather + than transferred from a master server; + when recursion is necessary for a query that + matches a static-stub zone, the locally + configured data (nameserver names and glue addresses) + is always used even if different authoritative + information is cached. + + + Zone data is configured via the + server-addresses and + server-names zone options. + + + The zone data is maintained in the form of NS + and (if necessary) glue A or AAAA RRs + internally, which can be seen by dumping zone + databases by rndc dumpdb -all. + The configured RRs are considered local configuration + parameters rather than public data. + Non recursive queries (i.e., those with the RD + bit off) to a static-stub zone are therefore + prohibited and will be responded with REFUSED. + + + Since the data is statically configured, no + zone maintenance action takes place for a static-stub + zone. + For example, there is no periodic refresh + attempt, and an incoming notify message + will be rejected with an rcode of NOTAUTH. + + + Each static-stub zone is configured with + internally generated NS and (if necessary) + glue A or AAAA RRs + + + + + + + forward + + + + + A "forward zone" is a way to configure + forwarding on a per-domain basis. A zone statement + of type forward can + contain a forward + and/or forwarders + statement, + which will apply to queries within the domain given by + the zone + name. If no forwarders + statement is present or + an empty list for forwarders is given, then no + forwarding will be done for the domain, canceling the + effects of + any forwarders in the options statement. Thus + if you want to use this type of zone to change the + behavior of the + global forward option + (that is, "forward first" + to, then "forward only", or vice versa, but want to + use the same + servers as set globally) you need to re-specify the + global forwarders. + + + + + + + hint + + + + + The initial set of root name servers is + specified using a "hint zone". When the server starts + up, it uses + the root hints to find a root name server and get the + most recent + list of root name servers. If no hint zone is + specified for class + IN, the server uses a compiled-in default set of root + servers hints. + Classes other than IN have no built-in defaults hints. + + + + + + + redirect + + + + + Redirect zones are used to provide answers to + queries when normal resolution would result in + NXDOMAIN being returned. + Only one redirect zone is supported + per view. allow-query can be + used to restrict which clients see these answers. + + + If the client has requested DNSSEC records (DO=1) and + the NXDOMAIN response is signed then no substitution + will occur. + + + To redirect all NXDOMAIN responses to + 100.100.100.2 and + 2001:ffff:ffff::100.100.100.2, one would + configure a type redirect zone named ".", + with the zone file containing wildcard records + that point to the desired addresses: + "*. IN A 100.100.100.2" + and + "*. IN AAAA 2001:ffff:ffff::100.100.100.2". + + + To redirect all Spanish names (under .ES) one + would use similar entries but with the names + "*.ES." instead of "*.". To redirect all + commercial Spanish names (under COM.ES) one + would use wildcard entries called "*.COM.ES.". + + + Note that the redirect zone supports all + possible types; it is not limited to A and + AAAA records. + + + Because redirect zones are not referenced + directly by name, they are not kept in the + zone lookup table with normal master and slave + zones. Consequently, it is not currently possible + to use + rndc reload + zonename + to reload a redirect zone. However, when using + rndc reload without specifying + a zone name, redirect zones will be reloaded along + with other zones. + + + + + + + delegation-only + + + + + This is used to enforce the delegation-only + status of infrastructure zones (e.g. COM, + NET, ORG). Any answer that is received + without an explicit or implicit delegation + in the authority section will be treated + as NXDOMAIN. This does not apply to the + zone apex. This should not be applied to + leaf zones. + + + delegation-only has no + effect on answers received from forwarders. + + + See caveats in . + + + + + + + + + + Class + + 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 + used to share information about various systems databases, such + as users, groups, printers and so on. The keyword + 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. + + + + + Zone Options + + + + + allow-notify + + + See the description of + allow-notify in . + + + + + + allow-query + + + See the description of + allow-query in . + + + + + + allow-query-on + + + See the description of + allow-query-on in . + + + + + + allow-transfer + + + See the description of allow-transfer + in . + + + + + + allow-update + + + See the description of allow-update + in . + + + + + + update-policy + + + Specifies a "Simple Secure Update" policy. See + . + + + + + + allow-update-forwarding + + + See the description of allow-update-forwarding + in . + + + + + + also-notify + + + Only meaningful if notify + is + active for this zone. The set of machines that will + receive a + DNS NOTIFY message + for this zone is made up of all the listed name servers + (other than + the primary master) for the zone plus any IP addresses + specified + with also-notify. A port + may be specified + with each also-notify + address to send the notify + messages to a port other than the default of 53. + A TSIG key may also be specified to cause the + NOTIFY to be signed by the + given key. + also-notify is not + meaningful for stub zones. + The default is the empty list. + + + + + + check-names + + + This option is used to restrict the character set and + syntax of + certain domain names in master files and/or DNS responses + received from the + network. The default varies according to zone type. For master zones the default is fail. For slave + zones the default is warn. + It is not implemented for hint zones. + + + + + + check-mx + + + See the description of + check-mx in . + + + + + + check-spf + + + See the description of + check-spf in . + + + + + + check-wildcard + + + See the description of + check-wildcard in . + + + + + + check-integrity + + + See the description of + check-integrity in . + + + + + + check-sibling + + + See the description of + check-sibling in . + + + + + + zero-no-soa-ttl + + + See the description of + zero-no-soa-ttl in . + + + + + + update-check-ksk + + + See the description of + update-check-ksk in . + + + + + + dnssec-update-mode + + + See the description of + dnssec-update-mode in . + + + + + + dnssec-dnskey-kskonly + + + See the description of + dnssec-dnskey-kskonly in . + + + + + + try-tcp-refresh + + + See the description of + try-tcp-refresh in . + + + + + + database + + + 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. + The first word + identifies the database type, and any subsequent words are + passed + as arguments to the database to be interpreted in a way + 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. + + + + + + dialup + + + See the description of + dialup in . + + + + + + delegation-only + + + The flag only applies to 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 . + + + + + + forward + + + 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. + + + + + + forwarders + + + 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. + + + + + + ixfr-base + + + Was used in BIND 8 to + specify the name + of the transaction log (journal) file for dynamic update + and IXFR. + BIND 9 ignores the option + and constructs the name of the journal + file by appending ".jnl" + to the name of the + zone file. + + + + + + ixfr-tmp-file + + + Was an undocumented option in BIND 8. + Ignored in BIND 9. + + + + + + journal + + + 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. + + + + + + max-journal-size + + + See the description of + max-journal-size in . + + + + + + max-transfer-time-in + + + See the description of + max-transfer-time-in in . + + + + + + max-transfer-idle-in + + + See the description of + max-transfer-idle-in in . + + + + + + max-transfer-time-out + + + See the description of + max-transfer-time-out in . + + + + + + max-transfer-idle-out + + + See the description of + max-transfer-idle-out in . + + + + + + notify + + + See the description of + notify in . + + + + + + notify-delay + + + See the description of + notify-delay in . + + + + + + notify-to-soa + + + See the description of + notify-to-soa in + . + + + + + + pubkey + + + In BIND 8, this option was + intended for specifying + a public zone key for verification of signatures in DNSSEC + signed + zones when they are loaded from disk. BIND 9 does not verify signatures + on load and ignores the option. + + + + + + zone-statistics + + + If yes, the server will keep + statistical + information for this zone, which can be dumped to the + statistics-file defined in + the server options. + + + + + + server-addresses + + + Only meaningful for static-stub zones. + This is a list of IP addresses to which queries + should be sent in recursive resolution for the + zone. + A non empty list for this option will internally + 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, + the following RRs will be internally configured. + +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 + "www.example.com" with the RD bit on, the server + will initiate recursive resolution and send + queries to 192.0.2.1 and/or 2001:db8::1234. + + + + + + server-names + + + Only meaningful for static-stub zones. + This is a list of domain names of nameservers that + act as authoritative servers of the static-stub + zone. + These names will be resolved to IP addresses when + named needs to send queries to + these servers. + To make this supplemental resolution successful, + these names must not be a subdomain of the origin + name of static-stub zone. + That is, when "example.net" is the origin of a + static-stub zone, "ns.example" and + "master.example.com" can be specified in the + server-names option, but + "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 + static-stub zone with "ns1.example.net" and + "ns2.example.net" + in a server-names option, + the following RRs will be internally configured. + +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 + "www.example.com" with the RD bit on, the server + initiate recursive resolution, + resolve "ns1.example.net" and/or + "ns2.example.net" to IP addresses, and then send + queries to (one or more of) these addresses. + + + + + + sig-validity-interval + + + See the description of + sig-validity-interval in . + + + + + + sig-signing-nodes + + + See the description of + sig-signing-nodes in . + + + + + + sig-signing-signatures + + + See the description of + sig-signing-signatures in . + + + + + + sig-signing-type + + + See the description of + sig-signing-type in . + + + + + + transfer-source + + + See the description of + transfer-source in . + + + + + + transfer-source-v6 + + + See the description of + transfer-source-v6 in . + + + + + + alt-transfer-source + + + See the description of + alt-transfer-source in . + + + + + + alt-transfer-source-v6 + + + See the description of + alt-transfer-source-v6 in . + + + + + + use-alt-transfer-source + + + See the description of + use-alt-transfer-source in . + + + + + + + notify-source + + + See the description of + notify-source in . + + + + + + notify-source-v6 + + + See the description of + notify-source-v6 in . + + + + + + min-refresh-time + max-refresh-time + min-retry-time + max-retry-time + + + See the description in . + + + + + + ixfr-from-differences + + + See the description of + ixfr-from-differences in . + (Note that the ixfr-from-differences + master and + slave choices are not + available at the zone level.) + + + + + + key-directory + + + See the description of + key-directory in . + + + + + + auto-dnssec + + + Zones configured for dynamic DNS may also 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 + (see and + ). The command + rndc sign + zonename causes + named to load keys from the key + repository and sign the zone with all keys that are + active. + rndc loadkeys + zonename causes + named to load keys from the key + repository and schedule key maintenance events to occur + in the future, but it does not sign the full zone + immediately. Note: once keys have been loaded for a + zone the first time, the repository will be searched + for changes periodically, regardless of whether + rndc loadkeys is used. The recheck + interval is defined by + dnssec-loadkeys-interval.) + + + The default setting is auto-dnssec off. + + + + + + serial-update-method + + + 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 + since the UNIX epoch, unless the serial number is + already greater than or equal to that value, in which + case it is simply incremented by one. + + + + + + inline-signing + + + 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 + behaviour is disabled by default. + + + + + + multi-master + + + See the description of multi-master in + . + + + + + + masterfile-format + + + See the description of masterfile-format + in . + + + + + + dnssec-secure-to-insecure + + + See the description of + dnssec-secure-to-insecure in . + + + + + + + + + Dynamic Update Policies + 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 works the + same way as in previous versions of BIND. + It grants given clients the permission to update any + record of any name in the zone. + + + The update-policy clause + allows more fine-grained control over what updates are + allowed. A set of rules is specified, where each rule + either grants or denies permissions for one or more + names to be updated by one or more identities. If + the dynamic update request message is signed (that is, + it includes either a TSIG or SIG(0) record), the + identity of the signer can be determined. + + + Rules are specified in the update-policy + zone option, and are only meaningful for master zones. + When the update-policy statement + is present, it is a configuration error for the + allow-update statement to be + present. The update-policy statement + only examines the signer of a message; the source + address is not relevant. + + + There is a pre-defined update-policy + rule which can be switched on with the command + update-policy local;. + Switching on this rule in a zone causes + named to generate a TSIG session + key and place it in a file, and to allow that key + to update the zone. (By default, the file is + /var/run/named/session.key, the key + name is "local-ddns" and the key algorithm is HMAC-SHA256, + but these values are configurable with the + session-keyfile, + session-keyname and + session-keyalg options, respectively). + + + A client running on the local system, and with appropriate + permissions, may read that file and use the key to sign update + requests. The zone's update policy will be set to allow that + key to change any record within the zone. Assuming the + key name is "local-ddns", this policy is equivalent to: + + + update-policy { grant local-ddns zonesub any; }; + + + + The command nsupdate -l sends update + requests to localhost, and signs them using the session key. + + + + Other rule definitions look like this: + + + +( grant | deny ) identity nametype name types + + + + Each rule grants or denies privileges. Once a message has + successfully matched a rule, the operation is immediately + granted or denied and no further rules are examined. A rule + is matched when the signer matches the identity field, the + name matches the name field in accordance with the nametype + field, and the type matches the types specified in the type + field. + + + No signer is required for tcp-self + or 6to4-self however the standard + reverse mapping / prefix conversion must match the identity + field. + + + The identity field specifies a name or a wildcard + name. Normally, this is the name of the TSIG or + SIG(0) key used to sign the update request. When a + TKEY exchange has been used to create a shared secret, + the identity of the shared secret is the same as the + identity of the key used to authenticate the TKEY + exchange. TKEY is also the negotiation method used + by GSS-TSIG, which establishes an identity that is + the Kerberos principal of the client, such as + "user@host.domain". When the + identity field specifies + a wildcard name, it is subject to DNS wildcard + expansion, so the rule will apply to multiple identities. + The identity field must + contain a fully-qualified domain name. + + + For nametypes krb5-self, + ms-self, krb5-subdomain, + and ms-subdomain the + identity field specifies + the Windows or Kerberos realm of the machine belongs to. + + + The nametype field has 13 + values: + name, subdomain, + wildcard, self, + selfsub, selfwild, + krb5-self, ms-self, + krb5-subdomain, + ms-subdomain, + tcp-self, 6to4-self, + zonesub, and external. + + + + + + + + + + name + + + + Exact-match semantics. This rule matches + when the name being updated is identical + to the contents of the + name field. + + + + + + + subdomain + + + + This rule matches when the name being updated + is a subdomain of, or identical to, the + contents of the name + field. + + + + + + + zonesub + + + + This rule is similar to subdomain, except that + it matches when the name being updated is a + subdomain of the zone in which the + update-policy statement + appears. This obviates the need to type the zone + name twice, and enables the use of a standard + update-policy statement in + multiple zones without modification. + + + When this rule is used, the + name field is omitted. + + + + + + + wildcard + + + + The name field + is subject to DNS wildcard expansion, and + this rule matches when the name being updated + name is a valid expansion of the wildcard. + + + + + + + self + + + + + This rule matches when the name being updated + matches the contents of the + identity field. + The name field + is ignored, but should be the same as the + identity field. + The self nametype is + most useful when allowing using one key per + name to update, where the key has the same + name as the name to be updated. The + identity would + be specified as * (an asterisk) in + this case. + + + + + + + selfsub + + + + This rule is similar to self + except that subdomains of self + can also be updated. + + + + + + + selfwild + + + + This rule is similar to self + except that only subdomains of + self can be updated. + + + + + + + ms-self + + + + This rule takes a Windows machine principal + (machine$@REALM) for machine in REALM and + and converts it machine.realm allowing the machine + to update machine.realm. The REALM to be matched + is specified in the identity + field. + + + + + + + ms-subdomain + + + + This rule takes a Windows machine principal + (machine$@REALM) for machine in REALM and + converts it to machine.realm allowing the machine + to update subdomains of machine.realm. The REALM + to be matched is specified in the + identity field. + + + + + + + krb5-self + + + + This rule takes a Kerberos machine principal + (host/machine@REALM) for machine in REALM and + and converts it machine.realm allowing the machine + to update machine.realm. The REALM to be matched + is specified in the identity + field. + + + + + + + krb5-subdomain + + + + This rule takes a Kerberos machine principal + (host/machine@REALM) for machine in REALM and + converts it to machine.realm allowing the machine + to update subdomains of machine.realm. The REALM + to be matched is specified in the + identity field. + + + + + + + tcp-self + + + + Allow updates that have been sent via TCP and + for which the standard mapping from the initiating + IP address into the IN-ADDR.ARPA and IP6.ARPA + namespaces match the name to be updated. + + + It is theoretically possible to spoof these TCP + sessions. + + + + + + + 6to4-self + + + + Allow the 6to4 prefix to be update by any TCP + connection from the 6to4 network or from the + corresponding IPv4 address. This is intended + to allow NS or DNAME RRsets to be added to the + reverse tree. + + + It is theoretically possible to spoof these TCP + sessions. + + + + + + + external + + + + This rule allows named + to defer the decision of whether to allow a + given update to an external daemon. + + + The method of communicating with the daemon is + specified in the identity + field, the format of which is + "local:path", + where path is the location + of a UNIX-domain socket. (Currently, "local" is the + only supported mechanism.) + + + Requests to the external daemon are sent over the + UNIX-domain socket as datagrams with the following + format: + + + Protocol version number (4 bytes, network byte order, currently 1) + Request length (4 bytes, network byte order) + Signer (null-terminated string) + Name (null-terminated string) + TCP source address (null-terminated string) + Rdata type (null-terminated string) + Key (null-terminated string) + TKEY token length (4 bytes, network byte order) + TKEY token (remainder of packet) + + The daemon replies with a four-byte value in + network byte order, containing either 0 or 1; 0 + indicates that the specified update is not + permitted, and 1 indicates that it is. + + + + + + + + + In all cases, the name + field must specify a fully-qualified domain name. + + + + If no types are explicitly specified, this rule matches + all types except RRSIG, NS, SOA, NSEC and NSEC3. Types + may be specified by name, including "ANY" (ANY matches + all types except NSEC and NSEC3, which can never be + updated). Note that when an attempt is made to delete + all records associated with a name, the rules are + checked for each existing record type. + + + + + Multiple views + + 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 + different clients to receive different answers for the same + queries. At times, however, it is desirable for multiple + views to contain identical zones. The + in-view zone option provides an efficient + 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; }; + + zone example.com { + type master; + file "example-external.db"; + }; +}; + +view external { + match-clients { any; }; + + zone example.com { + in-view internal; + }; +}; + + + 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 + and forwarders. (These options control + the behavior of the containing view, rather than changing + the zone object itself.) + + + + + + + Zone File + + Types of Resource Records and When to Use Them + + 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. + + + Resource Records + + + 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 + separate RRs. The order of RRs in a set is not significant and + need not be preserved by name servers, resolvers, or other + parts of the DNS. However, sorting of multiple RRs is + permitted for optimization purposes, for example, to specify + that a particular nearby server be tried first. See and . + + + + The components of a Resource Record are: + + + + + + + + + + owner name + + + + + The domain name where the RR is found. + + + + + + + type + + + + + An encoded 16-bit value that specifies + the type of the resource record. + + + + + + + TTL + + + + + The time-to-live of the RR. This field + is a 32-bit integer 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 should be discarded. + + + + + + + class + + + + + An encoded 16-bit value that identifies + a protocol family or instance of a protocol. + + + + + + + RDATA + + + + + The resource data. The format of the + data is type (and sometimes class) specific. + + + + + + + + The following are types of valid RRs: + + + + + + + + + + A + + + + + A host address. In the IN class, this is a + 32-bit IP address. Described in RFC 1035. + + + + + + + AAAA + + + + + IPv6 address. Described in RFC 1886. + + + + + + + A6 + + + + + IPv6 address. This can be a partial + address (a suffix) and an indirection to the name + where the rest of the + address (the prefix) can be found. Experimental. + Described in RFC 2874. + + + + + + + AFSDB + + + + + Location of AFS database servers. + Experimental. Described in RFC 1183. + + + + + + + APL + + + + + Address prefix list. Experimental. + Described in RFC 3123. + + + + + + + CERT + + + + + Holds a digital certificate. + Described in RFC 2538. + + + + + + + CNAME + + + + + Identifies the canonical name of an alias. + Described in RFC 1035. + + + + + + + DHCID + + + + + Is used for identifying which DHCP client is + associated with this name. Described in RFC 4701. + + + + + + + DNAME + + + + + Replaces the domain name specified with + another name to be looked up, effectively aliasing an + entire + subtree of the domain name space rather than a single + record + as in the case of the CNAME RR. + Described in RFC 2672. + + + + + + + DNSKEY + + + + + Stores a public key associated with a signed + DNS zone. Described in RFC 4034. + + + + + + + DS + + + + + Stores the hash of a public key associated with a + signed DNS zone. Described in RFC 4034. + + + + + + + GPOS + + + + + Specifies the global position. Superseded by LOC. + + + + + + + HINFO + + + + + Identifies the CPU and OS used by a host. + Described in RFC 1035. + + + + + + + IPSECKEY + + + + + Provides a method for storing IPsec keying material in + DNS. Described in RFC 4025. + + + + + + + ISDN + + + + + Representation of ISDN addresses. + Experimental. Described in RFC 1183. + + + + + + + KEY + + + + + Stores a public key associated with a + DNS name. Used in original DNSSEC; replaced + by DNSKEY in DNSSECbis, but still used with + SIG(0). Described in RFCs 2535 and 2931. + + + + + + + KX + + + + + Identifies a key exchanger for this + DNS name. Described in RFC 2230. + + + + + + + LOC + + + + + For storing GPS info. Described in RFC 1876. + Experimental. + + + + + + + MX + + + + + Identifies a mail exchange for the domain with + a 16-bit preference value (lower is better) + followed by the host name of the mail exchange. + Described in RFC 974, RFC 1035. + + + + + + + NAPTR + + + + + Name authority pointer. Described in RFC 2915. + + + + + + + NSAP + + + + + A network service access point. + Described in RFC 1706. + + + + + + + NS + + + + + The authoritative name server for the + domain. Described in RFC 1035. + + + + + + + NSEC + + + + + Used in DNSSECbis to securely indicate that + RRs with an owner name in a certain name interval do + not exist in + a zone and indicate what RR types are present for an + existing name. + Described in RFC 4034. + + + + + + + NSEC3 + + + + + Used in DNSSECbis to securely indicate that + RRs with an owner name in a certain name + interval do not exist in a zone and indicate + what RR types are present for an existing + name. NSEC3 differs from NSEC in that it + prevents zone enumeration but is more + computationally expensive on both the server + and the client than NSEC. Described in RFC + 5155. + + + + + + + NSEC3PARAM + + + + + Used in DNSSECbis to tell the authoritative + server which NSEC3 chains are available to use. + Described in RFC 5155. + + + + + + + NXT + + + + + Used in DNSSEC to securely indicate that + RRs with an owner name in a certain name interval do + not exist in + a zone and indicate what RR types are present for an + existing name. + Used in original DNSSEC; replaced by NSEC in + DNSSECbis. + Described in RFC 2535. + + + + + + + PTR + + + + + A pointer to another part of the domain + name space. Described in RFC 1035. + + + + + + + PX + + + + + Provides mappings between RFC 822 and X.400 + addresses. Described in RFC 2163. + + + + + + + RP + + + + + Information on persons responsible + for the domain. Experimental. Described in RFC 1183. + + + + + + + RRSIG + + + + + Contains DNSSECbis signature data. Described + in RFC 4034. + + + + + + + RT + + + + + Route-through binding for hosts that + do not have their own direct wide area network + addresses. + Experimental. Described in RFC 1183. + + + + + + + SIG + + + + + Contains DNSSEC signature data. Used in + original DNSSEC; replaced by RRSIG in + DNSSECbis, but still used for SIG(0). + Described in RFCs 2535 and 2931. + + + + + + + SOA + + + + + Identifies the start of a zone of authority. + Described in RFC 1035. + + + + + + + SPF + + + + + Contains the Sender Policy Framework information + for a given email domain. Described in RFC 4408. + + + + + + + SRV + + + + + Information about well known network + services (replaces WKS). Described in RFC 2782. + + + + + + + SSHFP + + + + + Provides a way to securely publish a secure shell key's + fingerprint. Described in RFC 4255. + + + + + + + TXT + + + + + Text records. Described in RFC 1035. + + + + + + + WKS + + + + + Information about which well known + network services, such as SMTP, that a domain + supports. Historical. + + + + + + + X25 + + + + + Representation of X.25 network addresses. + Experimental. Described in RFC 1183. + + + + + + + + The following classes of resource records + are currently valid in the DNS: + + + + + + + + + + IN + + + + + The Internet. + + + + + + + + CH + + + + + Chaosnet, a LAN protocol created at MIT in the + mid-1970s. + Rarely used for its historical purpose, but reused for + BIND's + built-in server information zones, e.g., + version.bind. + + + + + + + + HS + + + + + Hesiod, an information service + developed by MIT's Project Athena. It is used to share + information + about various systems databases, such as users, + groups, printers + and so on. + + + + + + + + + + The owner name is often implicit, rather than forming an + integral + part of the RR. For example, many name servers internally form + tree + or hash structures for the name space, and chain RRs off nodes. + The remaining RR parts are the fixed header (type, class, TTL) + which is consistent for all RRs, and a variable part (RDATA) + 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 + data in zones; it is also timed out, but by the refreshing + policies + for the zone. The TTL is assigned by the administrator for the + zone where the data originates. While short TTLs can be used to + minimize caching, and a zero TTL prohibits caching, the + realities + of Internet performance suggest that these times should be on + the + order of days for the typical host. If a change can be + anticipated, + the TTL can be reduced prior to the change to minimize + inconsistency + during the change, and then increased back to its former value + 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. + + + + Textual expression of RRs + + RRs are represented in binary form in the packets of the DNS + protocol, and are usually represented in highly encoded form + when + stored in a name server or resolver. In the examples provided + in + RFC 1034, a style similar to that used in master files was + employed + in order to show the contents of RRs. In this format, most RRs + are shown on a single line, although continuation lines are + 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 + in + parsing, type and class mnemonics are disjoint, TTLs are + integers, + and the type mnemonic is always last. The IN class and TTL + 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: + + + + + + + + + + ISI.EDU. + + + + + MX + + + + + 10 VENERA.ISI.EDU. + + + + + + + + + + MX + + + + + 10 VAXA.ISI.EDU + + + + + + + VENERA.ISI.EDU + + + + + A + + + + + 128.9.0.32 + + + + + + + + + + A + + + + + 10.1.0.52 + + + + + + + VAXA.ISI.EDU + + + + + A + + + + + 10.2.0.27 + + + + + + + + + + A + + + + + 128.9.0.33 + + + + + + + + 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: + + + + + + + + + + XX.LCS.MIT.EDU. + + + + + IN A + + + + + 10.0.0.44 + + + + + + + + CH A + + + + + MIT.EDU. 2420 + + + + + + + + This example shows two addresses for + XX.LCS.MIT.EDU, each of a different class. + + + + + + Discussion of MX Records + + + 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, + but not always, a host). The simplest way to think of a RR is as + a typed pair of data, a domain name matched with a relevant datum, + 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 + controls the order in which email delivery is attempted, with the + lowest number first. If two priorities are the same, a server is + chosen randomly. If no servers at a given priority are responding, + the mail transport agent will fall back to the next largest + priority. + Priority numbers do not have any absolute meaning — they are + relevant + only respective to other MX records for that domain name. The + domain + name given is the machine to which the mail will be delivered. + 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, + the mail will be delivered to the server specified in the MX + record + pointed to by the CNAME. + For example: + + + + + + + + + + + + + example.com. + + + + + IN + + + + + MX + + + + + 10 + + + + + mail.example.com. + + + + + + + + + + IN + + + + + MX + + + + + 10 + + + + + mail2.example.com. + + + + + + + + + + IN + + + + + MX + + + + + 20 + + + + + mail.backup.org. + + + + + + + mail.example.com. + + + + + IN + + + + + A + + + + + 10.0.0.1 + + + + + + + + + + mail2.example.com. + + + + + IN + + + + + A + + + + + 10.0.0.2 + + + + + + + + + + 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. + + + + Setting TTLs + + 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 + should be discarded. The following three types of TTL are + currently + used in a zone file. + + + + + + + + + + SOA + + + + + The last field in the SOA is the negative + caching TTL. This controls how long other servers will + cache no-such-domain + (NXDOMAIN) responses from you. + + + The maximum time for + negative caching is 3 hours (3h). + + + + + + + $TTL + + + + + The $TTL directive at the top of the + zone file (before the SOA) gives a default TTL for every + RR without + a specific TTL set. + + + + + + + RR TTLs + + + + + Each RR can have a TTL as the second + field in the RR, which will control how long other + servers can cache + the it. + + + + + + + + All of these TTLs default to units of seconds, though units + can be explicitly specified, for example, 1h30m. + + + + Inverse Mapping in IPv4 + + 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 + least-to-most significant order, read left to right. This is the + opposite order to the way IP addresses are usually written. Thus, + a machine with an IP address of 10.1.2.3 would have a + corresponding + in-addr.arpa name of + 3.2.1.10.in-addr.arpa. This name should have a PTR resource record + whose data field is the name of the machine or, optionally, + multiple + PTR records if the machine has more than one name. For example, + in the example.com domain: + + + + + + + + + + $ORIGIN + + + + + 2.1.10.in-addr.arpa + + + + + + + 3 + + + + + IN PTR foo.example.com. + + + + + + + + + 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. + + + + + Other Zone File Directives + + The Master File Format was initially defined in RFC 1035 and + has subsequently been extended. While the Master File Format + itself + is class independent all records in a Master File must be of the + same + class. + + + Master File Directives include $ORIGIN, $INCLUDE, + and $TTL. + + + The <command>@</command> (at-sign) + + 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). + + + + The <command>$ORIGIN</command> Directive + + Syntax: $ORIGIN + domain-name + comment + + $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 + <zone_name>. + (followed by trailing dot). + The current $ORIGIN is appended to + 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. + + + + + The <command>$INCLUDE</command> Directive + + 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 + on whether the current + domain name should also be restored. BIND 9 restores both of + them. + This could be construed as a deviation from RFC 1035, a + feature, or both. + + + + + The <command>$TTL</command> Directive + + Syntax: $TTL + default-ttl + +comment + + + Set the default Time To Live (TTL) for subsequent records + with undefined TTLs. Valid TTLs are of the range 0-2147483647 + seconds. + + $TTL + is defined in RFC 2308. + + + + + <acronym>BIND</acronym> Master File Extension: the <command>$GENERATE</command> Directive + + Syntax: $GENERATE + range + lhs + ttl + class + type + rhs + comment + + $GENERATE + is used to create a series of resource records that only + differ from each other by an + iterator. $GENERATE can be used to + easily generate the sets of records required to support + 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. +2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA. +... +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 +HOST-2.EXAMPLE. MX 0 . +HOST-3.EXAMPLE. A 1.2.3.3 +HOST-3.EXAMPLE. MX 0 . +... +HOST-127.EXAMPLE. A 1.2.3.127 +HOST-127.EXAMPLE. MX 0 . + + + + + + + + + + range + + + + This can be one of two forms: start-stop + or start-stop/step. If the first form is used, then step + is set to + 1. All of start, stop and step must be positive. + + + + + + lhs + + + This + describes the owner name of the resource records + to be created. Any single $ + (dollar sign) + symbols within the lhs string + are replaced by the iterator value. + + To get a $ in the output, you need to escape the + $ using a backslash + \, + e.g. \$. The + $ may optionally be followed + by modifiers which change the offset from the + iterator, field width and base. + + Modifiers are introduced by a + { (left brace) immediately following the + $ as + ${offset[,width[,base]]}. + For example, ${-20,3,d} + subtracts 20 from the current value, prints the + result as a decimal in a zero-padded field of + width 3. + + Available output forms are decimal + (d), octal + (o), hexadecimal + (x or X + for uppercase) and nibble + (n or N\ + for uppercase). The default modifier is + ${0,0,d}. If the + lhs is not absolute, the + current $ORIGIN is appended + to the name. + + + In nibble mode the value will be treated as + if it was a reversed hexadecimal string + with each hexadecimal digit as a separate + label. The width field includes the label + separator. + + + For compatibility with earlier versions, + $$ is still recognized as + indicating a literal $ in the output. + + + + + + ttl + + + + Specifies the time-to-live of the generated records. If + not specified this will be inherited using the + normal TTL inheritance rules. + + class + and ttl can be + entered in either order. + + + + + + class + + + + Specifies the class of the generated records. + This must match the zone class if it is + specified. + + class + and ttl can be + entered in either order. + + + + + + type + + + + Any valid type. + + + + + + rhs + + + + rhs, optionally, quoted string. + + + + + + + + The $GENERATE directive is a BIND extension + and not part of the standard zone file format. + + + BIND 8 does not support the optional TTL and CLASS fields. + + + + + Additional File Formats + + 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 + directly into memory via the mmap() + 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 + file by the named-compilezone command. + For a secondary server or for a dynamic zone, it is automatically + generated (if this format is specified by the + masterfile-format option) when + 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 + necessary modification should go to the text file, which + 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 + with different pointer size, endianness or data alignment + than the system on which it was generated, and should in + general be used only inside a single system. + While raw format uses + network byte order and avoids architecture-dependent + data alignment so that it is as portable as + possible, it is also primarily expected to be used + inside the same single system. To export a + zone file in either raw or + map format, or make a + portable backup of such a file, conversion to + text format is recommended. + + + + + + BIND9 Statistics + + BIND 9 maintains lots of statistics + information and provides several interfaces for users to + get access to the statistics. + The available statistics include all statistics counters + that were available in BIND 8 and + are meaningful in BIND 9, + and other information that is considered useful. + + + + The statistics information is categorized into the following + sections. + + + + + + + + + + + Incoming Requests + + + + The number of incoming DNS requests for each OPCODE. + + + + + + + Incoming Queries + + + + The number of incoming queries for each RR type. + + + + + + + Outgoing Queries + + + + The number of outgoing queries for each RR + type sent from the internal resolver. + Maintained per view. + + + + + + + Name Server Statistics + + + + Statistics counters about incoming request processing. + + + + + + + Zone Maintenance Statistics + + + + Statistics counters regarding zone maintenance + operations such as zone transfers. + + + + + + + Resolver Statistics + + + + Statistics counters about name resolution + performed in the internal resolver. + Maintained per view. + + + + + + + Cache DB RRsets + + + + The number of RRsets per RR type and nonexistent + names stored in the cache database. + If the exclamation mark (!) is printed for a RR + type, it means that particular type of RRset is + known to be nonexistent (this is also known as + "NXRRSET"). If a hash mark (#) is present then + the RRset is marked for garbage collection. + Maintained per view. + + + + + + + Socket I/O Statistics + + + + Statistics counters about network related events. + + + + + + + + + + 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 + yes. + These statistics counters are shown with their zone and view + names. + In some cases the view names are omitted for the default view. + + + + There are currently two user interfaces to get access to the + statistics. + One is in the plain text format dumped to the file specified + by the statistics-file configuration option. + The other is remotely accessible via a statistics channel + when the statistics-channels statement + is specified in the configuration file + (see .) + + + + The Statistics File + + 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. + + Following + that line is a set of statistics information, which is categorized + 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) + + + + + Statistics Counters + + The following tables summarize statistics counters that + BIND 9 provides. + For each row of the tables, the leftmost column is the + abbreviated symbol name of that counter. + These symbols are shown in the statistics information + accessed via an HTTP statistics channel. + The rightmost column gives the description of the counter, + which is also shown in the statistics file + (but, in this document, possibly with slight modification + for better readability). + Additional notes may also be provided in this column. + When a middle column exists between these two columns, + it gives the corresponding counter name of the + BIND 8 statistics, if applicable. + + + + Name Server Statistics Counters + + + + + + + + + + + Symbol + + + + + BIND8 Symbol + + + + + Description + + + + + + + Requestv4 + + + RQ + + + + IPv4 requests received. + Note: this also counts non query requests. + + + + + + Requestv6 + + + RQ + + + + IPv6 requests received. + Note: this also counts non query requests. + + + + + + ReqEdns0 + + + + + + + Requests with EDNS(0) received. + + + + + + ReqBadEDNSVer + + + + + + + Requests with unsupported EDNS version received. + + + + + + ReqTSIG + + + + + + + Requests with TSIG received. + + + + + + ReqSIG0 + + + + + + + Requests with SIG(0) received. + + + + + + ReqBadSIG + + + + + + + Requests with invalid (TSIG or SIG(0)) signature. + + + + + + ReqTCP + + + RTCP + + + + TCP requests received. + + + + + + AuthQryRej + + + RUQ + + + + Authoritative (non recursive) queries rejected. + + + + + + RecQryRej + + + RURQ + + + + Recursive queries rejected. + + + + + + XfrRej + + + RUXFR + + + + Zone transfer requests rejected. + + + + + + UpdateRej + + + RUUpd + + + + Dynamic update requests rejected. + + + + + + Response + + + SAns + + + + Responses sent. + + + + + + RespTruncated + + + + + + + Truncated responses sent. + + + + RespEDNS0 @@ -14876,28 +14911,28 @@ HOST-127.EXAMPLE. MX 0 . - - - + + + - Zone Maintenance Statistics Counters + Zone Maintenance Statistics Counters - - + + - + Symbol - + - + Description - + @@ -15032,34 +15067,34 @@ HOST-127.EXAMPLE. MX 0 . - - + + - Resolver Statistics Counters + Resolver Statistics Counters - - + + - + Symbol - + - + BIND8 Symbol - + - + Description - + @@ -15417,13 +15452,13 @@ HOST-127.EXAMPLE. MX 0 . - - + + - Socket I/O Statistics Counters + Socket I/O Statistics Counters Socket I/O statistics counters are defined per socket @@ -15442,20 +15477,20 @@ HOST-127.EXAMPLE. MX 0 . - + - + Symbol - + - + Description - + @@ -15576,11 +15611,11 @@ HOST-127.EXAMPLE. MX 0 . - + - Compatibility with <emphasis>BIND</emphasis> 8 Counters + Compatibility with <emphasis>BIND</emphasis> 8 Counters Most statistics counters that were available in BIND 8 are also supported in @@ -15589,8 +15624,8 @@ HOST-127.EXAMPLE. MX 0 . in these tables. - - + + RFwdR,SFwdR @@ -15602,7 +15637,7 @@ HOST-127.EXAMPLE. MX 0 . - + RAXFR @@ -15611,7 +15646,7 @@ HOST-127.EXAMPLE. MX 0 . - + RIQ @@ -15620,7 +15655,7 @@ HOST-127.EXAMPLE. MX 0 . - + ROpts @@ -15632,44 +15667,44 @@ HOST-127.EXAMPLE. MX 0 . - + <acronym>BIND</acronym> 9 Security Considerations - Access Control Lists - - Access Control Lists (ACLs) are address match lists that - you can set up and nickname for future use in allow-notify, - allow-query, allow-query-on, + Access Control Lists + + Access Control Lists (ACLs) are address match lists that + you can set up and nickname for future use in allow-notify, + allow-query, allow-query-on, allow-recursion, allow-recursion-on, - blackhole, allow-transfer, - etc. - - - Using ACLs allows you to have finer control over who can access - your name server, without cluttering up your config files with huge - lists of IP addresses. - - - It is a good idea to use ACLs, and to - control access to your server. Limiting access to your server by - outside parties can help prevent spoofing and denial of service (DoS) attacks against - your server. - - - Here is an example of how to properly apply ACLs: - + blackhole, allow-transfer, + etc. + + + Using ACLs allows you to have finer control over who can access + your name server, without cluttering up your config files with huge + lists of IP addresses. + + + It is a good idea to use ACLs, and to + control access to your server. Limiting access to your server by + outside parties can help prevent spoofing and denial of service (DoS) attacks against + your server. + + + Here is an example of how to properly apply ACLs: + // Set up an ACL named "bogusnets" that will block // RFC1918 space and some reserved space, which is // commonly used in spoofing attacks. acl bogusnets { - 0.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; - 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; + 0.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; + 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; // Set up an ACL called our-nets. Replace this with the @@ -15692,14 +15727,14 @@ zone "example.com" { }; - - This allows recursive queries of the server from the outside - unless recursion has been previously disabled. - + + This allows recursive queries of the server from the outside + unless recursion has been previously disabled. + - <command>Chroot</command> and <command>Setuid</command> - + <command>Chroot</command> and <command>Setuid</command> + On UNIX servers, it is possible to run BIND in a chrooted environment (using the chroot() function) by specifying @@ -15707,114 +15742,114 @@ zone "example.com" { This can help improve system security by placing BIND in a "sandbox", which will limit the damage done if a server is compromised. - - - Another useful feature in the UNIX version of BIND is the - ability to run the daemon as an unprivileged user ( user ). - We suggest running as an unprivileged user when using the chroot feature. - - - Here is an example command line to load BIND in a chroot sandbox, - /var/named, and to run named setuid to - user 202: - - - /usr/local/sbin/named -u 202 -t /var/named - - - - The <command>chroot</command> Environment - - - In order for a chroot environment - to - work properly in a particular directory - (for example, /var/named), - you will need to set up an environment that includes everything - BIND needs to run. - From BIND's point of view, /var/named is - the root of the filesystem. You will need to adjust the values of - options like - like directory and pid-file to account - for this. - - - Unlike with earlier versions of BIND, you typically will - not need to compile named - statically nor install shared libraries under the new root. - However, depending on your operating system, you may need - to set up things like - /dev/zero, - /dev/random, - /dev/log, and - /etc/localtime. - - - - - Using the <command>setuid</command> Function - - - Prior to running the named daemon, - use - the touch utility (to change file - access and - modification times) or the chown - utility (to - set the user id and/or group id) on files - to which you want BIND - to write. - + + + Another useful feature in the UNIX version of BIND is the + ability to run the daemon as an unprivileged user ( user ). + We suggest running as an unprivileged user when using the chroot feature. + + + Here is an example command line to load BIND in a chroot sandbox, + /var/named, and to run named setuid to + user 202: + + + /usr/local/sbin/named -u 202 -t /var/named + + + + The <command>chroot</command> Environment + + + In order for a chroot environment + to + work properly in a particular directory + (for example, /var/named), + you will need to set up an environment that includes everything + BIND needs to run. + From BIND's point of view, /var/named is + the root of the filesystem. You will need to adjust the values of + options like + like directory and pid-file to account + for this. + + + Unlike with earlier versions of BIND, you typically will + not need to compile named + statically nor install shared libraries under the new root. + However, depending on your operating system, you may need + to set up things like + /dev/zero, + /dev/random, + /dev/log, and + /etc/localtime. + + + + + Using the <command>setuid</command> Function + + + Prior to running the named daemon, + use + the touch utility (to change file + access and + modification times) or the chown + utility (to + set the user id and/or group id) on files + to which you want BIND + to write. + Note that if the named daemon is running as an - unprivileged user, it will not be able to bind to new restricted - ports if the server is reloaded. + unprivileged user, it will not be able to bind to new restricted + ports if the server is reloaded. - + - Dynamic Update Security - - - Access to the dynamic - update facility should be strictly limited. In earlier versions of - BIND, the only way to do this was - based on the IP - address of the host requesting the update, by listing an IP address - or - network prefix in the allow-update - zone option. - This method is insecure since the source address of the update UDP - packet - is easily forged. Also note that if the IP addresses allowed by the - allow-update option include the - address of a slave - server which performs forwarding of dynamic updates, the master can - be - trivially attacked by sending the update to the slave, which will - forward it to the master with its own source IP address causing the - master to approve it without question. - - - - For these reasons, we strongly recommend that updates be - cryptographically authenticated by means of transaction signatures - (TSIG). That is, the allow-update - option should - list only TSIG key names, not IP addresses or network - prefixes. Alternatively, the new update-policy - option can be used. - - - - Some sites choose to keep all dynamically-updated DNS data - in a subdomain and delegate that subdomain to a separate zone. This - way, the top-level zone containing critical data such as the IP - addresses - of public web and mail servers need not allow dynamic update at - all. - + Dynamic Update Security + + + Access to the dynamic + update facility should be strictly limited. In earlier versions of + BIND, the only way to do this was + based on the IP + address of the host requesting the update, by listing an IP address + or + network prefix in the allow-update + zone option. + This method is insecure since the source address of the update UDP + packet + is easily forged. Also note that if the IP addresses allowed by the + allow-update option include the + address of a slave + server which performs forwarding of dynamic updates, the master can + be + trivially attacked by sending the update to the slave, which will + forward it to the master with its own source IP address causing the + master to approve it without question. + + + + For these reasons, we strongly recommend that updates be + cryptographically authenticated by means of transaction signatures + (TSIG). That is, the allow-update + option should + list only TSIG key names, not IP addresses or network + prefixes. Alternatively, the new update-policy + option can be used. + + + + Some sites choose to keep all dynamically-updated DNS data + in a subdomain and delegate that subdomain to a separate zone. This + way, the top-level zone containing critical data such as the IP + addresses + of public web and mail servers need not allow dynamic update at + all. + @@ -15822,22 +15857,22 @@ zone "example.com" { Troubleshooting - Common Problems - - It's not working; how can I figure out what's wrong? - - - The best solution to solving installation and - configuration issues is to take preventative measures by setting - up logging files beforehand. The log files provide a - source of hints and information that can be used to figure out - what went wrong and how to fix the problem. - - - + Common Problems + + It's not working; how can I figure out what's wrong? + + + The best solution to solving installation and + configuration issues is to take preventative measures by setting + up logging files beforehand. The log files provide a + source of hints and information that can be used to figure out + what went wrong and how to fix the problem. + + + - Incrementing and Changing the Serial Number + Incrementing and Changing the Serial Number Zone serial numbers are just numbers — they aren't @@ -15852,1461 +15887,1461 @@ zone "example.com" { server will attempt to update its copy of the zone. - - Setting the serial number to a lower number on the master - server than the slave server means that the slave will not perform - updates to its copy of the zone. - + + Setting the serial number to a lower number on the master + server than the slave server means that the slave will not perform + updates to its copy of the zone. + - - The solution to this is to add 2147483647 (2^31-1) to the - number, reload the zone and make sure all slaves have updated to - the new zone serial number, then reset the number to what you want - it to be, and reload the zone again. - + + The solution to this is to add 2147483647 (2^31-1) to the + number, reload the zone and make sure all slaves have updated to + the new zone serial number, then reset the number to what you want + it to be, and reload the zone again. + - Where Can I Get Help? - - - The Internet Systems Consortium - (ISC) offers a wide range - of support and service agreements for BIND and DHCP servers. Four - levels of premium support are available and each level includes - support for all ISC programs, - significant discounts on products - and training, and a recognized priority on bug fixes and - non-funded feature requests. In addition, ISC offers a standard - support agreement package which includes services ranging from bug - fix announcements to remote support. It also includes training in - BIND and DHCP. - - - - To discuss arrangements for support, contact - info@isc.org or visit the - ISC web page at + Where Can I Get Help? + + + The Internet Systems Consortium + (ISC) offers a wide range + of support and service agreements for BIND and DHCP servers. Four + levels of premium support are available and each level includes + support for all ISC programs, + significant discounts on products + and training, and a recognized priority on bug fixes and + non-funded feature requests. In addition, ISC offers a standard + support agreement package which includes services ranging from bug + fix announcements to remote support. It also includes training in + BIND and DHCP. + + + + To discuss arrangements for support, contact + info@isc.org or visit the + ISC web page at http://www.isc.org/services/support/ - to read more. - + >http://www.isc.org/services/support/ + to read more. + Appendices - Acknowledgments - - A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym> - - - Although the "official" beginning of the Domain Name - System occurred in 1984 with the publication of RFC 920, the - core of the new system was described in 1983 in RFCs 882 and - 883. From 1984 to 1987, the ARPAnet (the precursor to today's - Internet) became a testbed of experimentation for developing the - new naming/addressing scheme in a rapidly expanding, - operational network environment. New RFCs were written and - published in 1987 that modified the original documents to - incorporate improvements based on the working model. RFC 1034, - "Domain Names-Concepts and Facilities", and RFC 1035, "Domain - Names-Implementation and Specification" were published and - became the standards upon which all DNS implementations are - built. - - - - The first working domain name server, called "Jeeves", was - written in 1983-84 by Paul Mockapetris for operation on DEC - Tops-20 - machines located at the University of Southern California's - Information - Sciences Institute (USC-ISI) and SRI International's Network - Information - Center (SRI-NIC). A DNS server for - Unix machines, the Berkeley Internet - Name Domain (BIND) package, was - written soon after by a group of - graduate students at the University of California at Berkeley - under - a grant from the US Defense Advanced Research Projects - Administration - (DARPA). - - + Acknowledgments + + A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym> + + + Although the "official" beginning of the Domain Name + System occurred in 1984 with the publication of RFC 920, the + core of the new system was described in 1983 in RFCs 882 and + 883. From 1984 to 1987, the ARPAnet (the precursor to today's + Internet) became a testbed of experimentation for developing the + new naming/addressing scheme in a rapidly expanding, + operational network environment. New RFCs were written and + published in 1987 that modified the original documents to + incorporate improvements based on the working model. RFC 1034, + "Domain Names-Concepts and Facilities", and RFC 1035, "Domain + Names-Implementation and Specification" were published and + became the standards upon which all DNS implementations are + built. + + + + The first working domain name server, called "Jeeves", was + written in 1983-84 by Paul Mockapetris for operation on DEC + Tops-20 + machines located at the University of Southern California's + Information + Sciences Institute (USC-ISI) and SRI International's Network + Information + Center (SRI-NIC). A DNS server for + Unix machines, the Berkeley Internet + Name Domain (BIND) package, was + written soon after by a group of + graduate students at the University of California at Berkeley + under + a grant from the US Defense Advanced Research Projects + Administration + (DARPA). + + Versions of BIND through - 4.8.3 were maintained by the Computer - Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark - Painter, David Riggle and Songnian Zhou made up the initial BIND - project team. After that, additional work on the software package - was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment - Corporation - employee on loan to the CSRG, worked on BIND for 2 years, from 1985 - to 1987. Many other people also contributed to BIND development - during that time: Doug Kingston, Craig Partridge, Smoot - Carl-Mitchell, - Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently - handled by Mike Karels and Øivind Kure. - - - BIND versions 4.9 and 4.9.1 were - released by Digital Equipment - Corporation (now Compaq Computer Corporation). Paul Vixie, then - a DEC employee, became BIND's - primary caretaker. He was assisted - by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan - Beecher, Andrew - Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat - Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe - Wolfhugel, and others. - - - In 1994, BIND version 4.9.2 was sponsored by - Vixie Enterprises. Paul - Vixie became BIND's principal - architect/programmer. - - - BIND versions from 4.9.3 onward - have been developed and maintained - by the Internet Systems Consortium and its predecessor, - the Internet Software Consortium, with support being provided - by ISC's sponsors. - + 4.8.3 were maintained by the Computer + Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark + Painter, David Riggle and Songnian Zhou made up the initial BIND + project team. After that, additional work on the software package + was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment + Corporation + employee on loan to the CSRG, worked on BIND for 2 years, from 1985 + to 1987. Many other people also contributed to BIND development + during that time: Doug Kingston, Craig Partridge, Smoot + Carl-Mitchell, + Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently + handled by Mike Karels and Øivind Kure. + + + BIND versions 4.9 and 4.9.1 were + released by Digital Equipment + Corporation (now Compaq Computer Corporation). Paul Vixie, then + a DEC employee, became BIND's + primary caretaker. He was assisted + by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan + Beecher, Andrew + Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat + Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe + Wolfhugel, and others. + + + In 1994, BIND version 4.9.2 was sponsored by + Vixie Enterprises. Paul + Vixie became BIND's principal + architect/programmer. + + + BIND versions from 4.9.3 onward + have been developed and maintained + by the Internet Systems Consortium and its predecessor, + the Internet Software Consortium, with support being provided + by ISC's sponsors. + As co-architects/programmers, Bob Halley and - Paul Vixie released the first production-ready version of + Paul Vixie released the first production-ready version of BIND version 8 in May 1997. - + BIND version 9 was released in September 2000 and is a major rewrite of nearly all aspects of the underlying BIND architecture. - - + + BIND versions 4 and 8 are officially deprecated. No additional development is done on BIND version 4 or BIND version 8. - - - BIND development work is made - possible today by the sponsorship - of several corporations, and by the tireless work efforts of - numerous individuals. - - + + + BIND development work is made + possible today by the sponsorship + of several corporations, and by the tireless work efforts of + numerous individuals. + + - General <acronym>DNS</acronym> Reference Information - - IPv6 addresses (AAAA) - - IPv6 addresses are 128-bit identifiers for interfaces and - sets of interfaces which were introduced in the DNS to facilitate - scalable Internet routing. There are three types of addresses: Unicast, - an identifier for a single interface; - Anycast, - an identifier for a set of interfaces; and Multicast, - an identifier for a set of interfaces. Here we describe the global - Unicast address scheme. For more information, see RFC 3587, + General <acronym>DNS</acronym> Reference Information + + IPv6 addresses (AAAA) + + IPv6 addresses are 128-bit identifiers for interfaces and + sets of interfaces which were introduced in the DNS to facilitate + scalable Internet routing. There are three types of addresses: Unicast, + an identifier for a single interface; + Anycast, + an identifier for a set of interfaces; and Multicast, + an identifier for a set of interfaces. Here we describe the global + Unicast address scheme. For more information, see RFC 3587, "Global Unicast Address Format." - - + + IPv6 unicast addresses consist of a global routing prefix, a subnet identifier, and an interface identifier. - - - The global routing prefix is provided by the - upstream provider or ISP, and (roughly) corresponds to the + + + The global routing prefix is provided by the + upstream provider or ISP, and (roughly) corresponds to the IPv4 network section - of the address range. + of the address range. The subnet identifier is for local subnetting, much the - same as subnetting an - IPv4 /16 network into /24 subnets. + same as subnetting an + IPv4 /16 network into /24 subnets. The interface identifier is the address of an individual - interface on a given network; in IPv6, addresses belong to - interfaces rather than to machines. - - - The subnetting capability of IPv6 is much more flexible than - that of IPv4: subnetting can be carried out on bit boundaries, - in much the same way as Classless InterDomain Routing - (CIDR), and the DNS PTR representation ("nibble" format) - makes setting up reverse zones easier. - - - The Interface Identifier must be unique on the local link, - and is usually generated automatically by the IPv6 - implementation, although it is usually possible to - override the default setting if necessary. A typical IPv6 - address might look like: + interface on a given network; in IPv6, addresses belong to + interfaces rather than to machines. + + + The subnetting capability of IPv6 is much more flexible than + that of IPv4: subnetting can be carried out on bit boundaries, + in much the same way as Classless InterDomain Routing + (CIDR), and the DNS PTR representation ("nibble" format) + makes setting up reverse zones easier. + + + The Interface Identifier must be unique on the local link, + and is usually generated automatically by the IPv6 + implementation, although it is usually possible to + override the default setting if necessary. A typical IPv6 + address might look like: 2001:db8:201:9:a00:20ff:fe81:2b32 - - IPv6 address specifications often contain long strings - of zeros, so the architects have included a shorthand for - specifying - them. The double colon (`::') indicates the longest possible - string - of zeros that can fit, and can be used only once in an address. - - + + IPv6 address specifications often contain long strings + of zeros, so the architects have included a shorthand for + specifying + them. The double colon (`::') indicates the longest possible + string + of zeros that can fit, and can be used only once in an address. + + - Bibliography (and Suggested Reading) - - Request for Comments (RFCs) - - Specification documents for the Internet protocol suite, including - the DNS, are published as part of - the Request for Comments (RFCs) - series of technical notes. The standards themselves are defined - by the Internet Engineering Task Force (IETF) and the Internet - Engineering Steering Group (IESG). RFCs can be obtained online via FTP at: - - - + Bibliography (and Suggested Reading) + + Request for Comments (RFCs) + + Specification documents for the Internet protocol suite, including + the DNS, are published as part of + the Request for Comments (RFCs) + series of technical notes. The standards themselves are defined + by the Internet Engineering Task Force (IETF) and the Internet + Engineering Steering Group (IESG). RFCs can be obtained online via FTP at: + + + ftp://www.isi.edu/in-notes/RFCxxxx.txt (where xxxx is - the number of the RFC). RFCs are also available via the Web at: - - - http://www.ietf.org/rfc/. - - - - - Standards - - RFC974 - - Partridge - C. - - Mail Routing and the Domain System - January 1986 - - - RFC1034 - - Mockapetris - P.V. - - Domain Names — Concepts and Facilities - November 1987 - - - RFC1035 - - Mockapetris - P. V. - Domain Names — Implementation and - Specification - November 1987 - - - - - Proposed Standards - - - RFC2181 - - Elz - R., R. Bush - - Clarifications to the <acronym>DNS</acronym> - Specification - July 1997 - - - RFC2308 - - Andrews - M. - - Negative Caching of <acronym>DNS</acronym> - Queries - March 1998 - - - RFC1995 - - Ohta - M. - - Incremental Zone Transfer in <acronym>DNS</acronym> - August 1996 - - - RFC1996 - - Vixie - P. - - A Mechanism for Prompt Notification of Zone Changes - August 1996 - - - RFC2136 - - - Vixie - P. - - - S. - Thomson - - - Y. - Rekhter - - - J. - Bound - - - Dynamic Updates in the Domain Name System - April 1997 - + the number of the RFC). RFCs are also available via the Web at: + + + http://www.ietf.org/rfc/. + + + + + Standards + + RFC974 + + Partridge + C. + + Mail Routing and the Domain System + January 1986 + + + RFC1034 + + Mockapetris + P.V. + + Domain Names — Concepts and Facilities + November 1987 + + + RFC1035 + + Mockapetris + P. V. + Domain Names — Implementation and + Specification + November 1987 + + + + + Proposed Standards + + + RFC2181 + + Elz + R., R. Bush + + Clarifications to the <acronym>DNS</acronym> + Specification + July 1997 + + + RFC2308 + + Andrews + M. + + Negative Caching of <acronym>DNS</acronym> + Queries + March 1998 + + + RFC1995 + + Ohta + M. + + Incremental Zone Transfer in <acronym>DNS</acronym> + August 1996 + + + RFC1996 + + Vixie + P. + + A Mechanism for Prompt Notification of Zone Changes + August 1996 + + + RFC2136 + + + Vixie + P. + + + S. + Thomson + + + Y. + Rekhter + + + J. + Bound + + + Dynamic Updates in the Domain Name System + April 1997 + + + RFC2671 + + + P. + Vixie + + + Extension Mechanisms for DNS (EDNS0) + August 1997 + + + RFC2672 + + + M. + Crawford + + + Non-Terminal DNS Name Redirection + August 1999 + + + RFC2845 + + + Vixie + P. + + + O. + Gudmundsson + + + D. + Eastlake + 3rd + + + B. + Wellington + + + Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG) + May 2000 + + + RFC2930 + + + D. + Eastlake + 3rd + + + Secret Key Establishment for DNS (TKEY RR) + September 2000 + + + RFC2931 + + + D. + Eastlake + 3rd + + + DNS Request and Transaction Signatures (SIG(0)s) + September 2000 + + + RFC3007 + + + B. + Wellington + + + Secure Domain Name System (DNS) Dynamic Update + November 2000 + + + RFC3645 + + + S. + Kwan + + + P. + Garg + + + J. + Gilroy + + + L. + Esibov + + + J. + Westhead + + + R. + Hall + + + Generic Security Service Algorithm for Secret + Key Transaction Authentication for DNS + (GSS-TSIG) + October 2003 + + + + <acronym>DNS</acronym> Security Proposed Standards + + RFC3225 + + + D. + Conrad + + + Indicating Resolver Support of DNSSEC + December 2001 + + + RFC3833 + + + D. + Atkins + + + R. + Austein + + + Threat Analysis of the Domain Name System (DNS) + August 2004 + + + RFC4033 + + + R. + Arends + + + R. + Austein + + + M. + Larson + + + D. + Massey + + + S. + Rose + + + DNS Security Introduction and Requirements + March 2005 + + + RFC4034 + + + R. + Arends + + + R. + Austein + + + M. + Larson + + + D. + Massey + + + S. + Rose + + + Resource Records for the DNS Security Extensions + March 2005 + + + RFC4035 + + + R. + Arends + + + R. + Austein + + + M. + Larson + + + D. + Massey + + + S. + Rose + + + Protocol Modifications for the DNS + Security Extensions + March 2005 + + + + Other Important RFCs About <acronym>DNS</acronym> + Implementation + + RFC1535 + + Gavron + E. + + A Security Problem and Proposed Correction With Widely + Deployed <acronym>DNS</acronym> Software. + October 1993 + + + RFC1536 + + + Kumar + A. + + + J. + Postel + + + C. + Neuman + + + P. + Danzig + + + S. + Miller + + + Common <acronym>DNS</acronym> Implementation + Errors and Suggested Fixes + October 1993 + + + RFC1982 + + + Elz + R. + + + R. + Bush + + + Serial Number Arithmetic + August 1996 + + + RFC4074 + + + Morishita + Y. + + + T. + Jinmei + + + Common Misbehaviour Against <acronym>DNS</acronym> + Queries for IPv6 Addresses + May 2005 + + + + Resource Record Types + + RFC1183 + + + Everhart + C.F. + + + L. A. + Mamakos + + + R. + Ullmann + + + P. + Mockapetris + + + New <acronym>DNS</acronym> RR Definitions + October 1990 + + + RFC1706 + + + Manning + B. + + + R. + Colella + + + <acronym>DNS</acronym> NSAP Resource Records + October 1994 + + + RFC2168 + + + Daniel + R. + + + M. + Mealling + + + Resolution of Uniform Resource Identifiers using + the Domain Name System + June 1997 + + + RFC1876 + + + Davis + C. + + + P. + Vixie + + + T. + Goodwin + + + I. + Dickinson + + + A Means for Expressing Location Information in the + Domain + Name System + January 1996 + + + RFC2052 + + + Gulbrandsen + A. + + + P. + Vixie + + + A <acronym>DNS</acronym> RR for Specifying the + Location of + Services. + October 1996 + + + RFC2163 + + Allocchio + A. + + Using the Internet <acronym>DNS</acronym> to + Distribute MIXER + Conformant Global Address Mapping + January 1998 + + + RFC2230 + + Atkinson + R. + + Key Exchange Delegation Record for the <acronym>DNS</acronym> + October 1997 + + + RFC2536 + + Eastlake + D. + 3rd + + DSA KEYs and SIGs in the Domain Name System (DNS) + March 1999 + + + RFC2537 + + Eastlake + D. + 3rd + + RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) + March 1999 + + + RFC2538 + + + Eastlake + D. + 3rd + + + Gudmundsson + O. + + + Storing Certificates in the Domain Name System (DNS) + March 1999 + + + RFC2539 + + + Eastlake + D. + 3rd + + + Storage of Diffie-Hellman Keys in the Domain Name System (DNS) + March 1999 + + + RFC2540 + + + Eastlake + D. + 3rd + + + Detached Domain Name System (DNS) Information + March 1999 + + + RFC2782 + + Gulbrandsen + A. + + + Vixie + P. + + + Esibov + L. + + A DNS RR for specifying the location of services (DNS SRV) + February 2000 + + + RFC2915 + + Mealling + M. + + + Daniel + R. + + The Naming Authority Pointer (NAPTR) DNS Resource Record + September 2000 + + + RFC3110 + + Eastlake + D. + 3rd + + RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) + May 2001 + + + RFC3123 + + Koch + P. + + A DNS RR Type for Lists of Address Prefixes (APL RR) + June 2001 + + + RFC3596 + + + Thomson + S. + + + C. + Huitema + + + V. + Ksinant + + + M. + Souissi + + + <acronym>DNS</acronym> Extensions to support IP + version 6 + October 2003 + + + RFC3597 + + Gustafsson + A. + + Handling of Unknown DNS Resource Record (RR) Types + September 2003 + + + + <acronym>DNS</acronym> and the Internet + + RFC1101 + + Mockapetris + P. V. + + <acronym>DNS</acronym> Encoding of Network Names + and Other Types + April 1989 + + + RFC1123 + + Braden + R. + + Requirements for Internet Hosts - Application and + Support + October 1989 + + + RFC1591 + + Postel + J. + + Domain Name System Structure and Delegation + March 1994 + + + RFC2317 + + + Eidnes + H. + + + G. + de Groot + + + P. + Vixie + + + Classless IN-ADDR.ARPA Delegation + March 1998 + - RFC2671 - - - P. - Vixie - - - Extension Mechanisms for DNS (EDNS0) - August 1997 + RFC2826 + + + Internet Architecture Board + + + IAB Technical Comment on the Unique DNS Root + May 2000 - RFC2672 - - - M. - Crawford - - - Non-Terminal DNS Name Redirection - August 1999 + RFC2929 + + + Eastlake + D. + 3rd + + + Brunner-Williams + E. + + + Manning + B. + + + Domain Name System (DNS) IANA Considerations + September 2000 - - RFC2845 - - - Vixie - P. - - - O. - Gudmundsson - - - D. - Eastlake - 3rd - - - B. - Wellington - - - Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG) - May 2000 - - - RFC2930 - - - D. - Eastlake - 3rd - - - Secret Key Establishment for DNS (TKEY RR) - September 2000 - - - RFC2931 - - - D. - Eastlake - 3rd - - - DNS Request and Transaction Signatures (SIG(0)s) - September 2000 - - - RFC3007 - - - B. - Wellington - - - Secure Domain Name System (DNS) Dynamic Update - November 2000 - - - RFC3645 - - - S. - Kwan - - - P. - Garg - - - J. - Gilroy - - - L. - Esibov - - - J. - Westhead - - - R. - Hall - - - Generic Security Service Algorithm for Secret - Key Transaction Authentication for DNS - (GSS-TSIG) - October 2003 - - + - <acronym>DNS</acronym> Security Proposed Standards + <acronym>DNS</acronym> Operations - RFC3225 - + RFC1033 + + Lottor + M. + + Domain administrators operations guide. + November 1987 + + + RFC1537 + + Beertema + P. + + Common <acronym>DNS</acronym> Data File + Configuration Errors + October 1993 + + + RFC1912 + + Barr + D. + + Common <acronym>DNS</acronym> Operational and + Configuration Errors + February 1996 + + + RFC2010 + - D. - Conrad + Manning + B. - - Indicating Resolver Support of DNSSEC - December 2001 + + P. + Vixie + + + Operational Criteria for Root Name Servers. + October 1996 - RFC3833 - + RFC2219 + - D. - Atkins + Hamilton + M. R. - Austein + Wright - Threat Analysis of the Domain Name System (DNS) - August 2004 + Use of <acronym>DNS</acronym> Aliases for + Network Services. + October 1997 + + + Internationalized Domain Names - RFC4033 - + RFC2825 + - R. - Arends + IAB + Daigle R. - Austein + + + A Tangled Web: Issues of I18N, Domain Names, + and the Other Internet protocols + May 2000 + + + RFC3490 + + + Faltstrom + P. + + + Hoffman + P. + + + Costello + A. + + + Internationalizing Domain Names in Applications (IDNA) + March 2003 + + + RFC3491 + + + Hoffman + P. + Blanchet M. - Larson + + Nameprep: A Stringprep Profile for Internationalized Domain Names + March 2003 + + + RFC3492 + - D. - Massey + Costello + A. + + + Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in + Applications (IDNA) + March 2003 + + + + Other <acronym>DNS</acronym>-related RFCs + + + Note: the following list of RFCs, although + DNS-related, are not + concerned with implementing software. + + + + RFC1464 + + Rosenbaum + R. + + Using the Domain Name System To Store Arbitrary String + Attributes + May 1993 + + + RFC1713 + + Romao + A. + + Tools for <acronym>DNS</acronym> Debugging + November 1994 + + + RFC1794 + + Brisco + T. + + <acronym>DNS</acronym> Support for Load + Balancing + April 1995 + + + RFC2240 + + Vaughan + O. + + A Legal Basis for Domain Name Allocation + November 1997 + + + RFC2345 + + + Klensin + J. - S. - Rose + T. + Wolf + + + G. + Oglesby - DNS Security Introduction and Requirements - March 2005 + Domain Names and Company Name Retrieval + May 1998 - RFC4034 - + RFC2352 + + Vaughan + O. + + A Convention For Using Legal Names as Domain Names + May 1998 + + + RFC3071 + - R. - Arends + Klensin + J. + + + Reflections on the DNS, RFC 1591, and Categories of Domains + February 2001 + + + RFC3258 + + + Hardie + T. + + + Distributing Authoritative Name Servers via + Shared Unicast Addresses + April 2002 + + + RFC3901 + + + Durand + A. - R. - Austein + J. + Ihren + + + DNS IPv6 Transport Operational Guidelines + September 2004 + + + + Obsolete and Unimplemented Experimental RFC + + RFC1712 + + + Farrell + C. M. - Larson + Schulze + + + S. + Pleitner D. - Massey + Baldoni + + <acronym>DNS</acronym> Encoding of Geographical + Location + November 1994 + + + RFC2673 + - S. - Rose + Crawford + M. - Resource Records for the DNS Security Extensions - March 2005 + Binary Labels in the Domain Name System + August 1999 - RFC4035 - + RFC2874 + - R. - Arends + Crawford + M. - R. - Austein + Huitema + C. + + + DNS Extensions to Support IPv6 Address Aggregation + and Renumbering + July 2000 + + + + Obsoleted DNS Security RFCs + + + Most of these have been consolidated into RFC4033, + RFC4034 and RFC4035 which collectively describe DNSSECbis. + + + + RFC2065 + + + Eastlake + 3rd + D. - M. - Larson + C. + Kaufman + + Domain Name System Security Extensions + January 1997 + + + RFC2137 + + Eastlake + 3rd + D. + + Secure Domain Name System Dynamic Update + April 1997 + + + RFC2535 + + Eastlake + 3rd D. - Massey + + Domain Name System Security Extensions + March 1999 + + + RFC3008 + - S. - Rose + Wellington + B. - Protocol Modifications for the DNS - Security Extensions - March 2005 + Domain Name System Security (DNSSEC) + Signing Authority + November 2000 - - - Other Important RFCs About <acronym>DNS</acronym> - Implementation - - RFC1535 - - Gavron - E. - - A Security Problem and Proposed Correction With Widely - Deployed <acronym>DNS</acronym> Software. - October 1993 - - - RFC1536 - - - Kumar - A. - - - J. - Postel - - - C. - Neuman - - - P. - Danzig - - - S. - Miller - - - Common <acronym>DNS</acronym> Implementation - Errors and Suggested Fixes - October 1993 - - - RFC1982 - - - Elz - R. - - - R. - Bush - - - Serial Number Arithmetic - August 1996 - - - RFC4074 - - - Morishita - Y. - - - T. - Jinmei - - - Common Misbehaviour Against <acronym>DNS</acronym> - Queries for IPv6 Addresses - May 2005 - - - - Resource Record Types - - RFC1183 - - - Everhart - C.F. - - - L. A. - Mamakos - - - R. - Ullmann - - - P. - Mockapetris - - - New <acronym>DNS</acronym> RR Definitions - October 1990 - - - RFC1706 - - - Manning - B. - - - R. - Colella - - - <acronym>DNS</acronym> NSAP Resource Records - October 1994 - - - RFC2168 - - - Daniel - R. - - - M. - Mealling - - - Resolution of Uniform Resource Identifiers using - the Domain Name System - June 1997 - - - RFC1876 - - - Davis - C. - - - P. - Vixie - - - T. - Goodwin - - - I. - Dickinson - - - A Means for Expressing Location Information in the - Domain - Name System - January 1996 - - - RFC2052 - - - Gulbrandsen - A. - - - P. - Vixie - - - A <acronym>DNS</acronym> RR for Specifying the - Location of - Services. - October 1996 - - - RFC2163 - - Allocchio - A. - - Using the Internet <acronym>DNS</acronym> to - Distribute MIXER - Conformant Global Address Mapping - January 1998 - - - RFC2230 - - Atkinson - R. - - Key Exchange Delegation Record for the <acronym>DNS</acronym> - October 1997 - - - RFC2536 - - Eastlake - D. - 3rd - - DSA KEYs and SIGs in the Domain Name System (DNS) - March 1999 - - - RFC2537 - - Eastlake - D. - 3rd - - RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) - March 1999 - - - RFC2538 + + RFC3090 - - Eastlake - D. - 3rd - - Gudmundsson - O. + Lewis + E. - Storing Certificates in the Domain Name System (DNS) - March 1999 - - - RFC2539 + DNS Security Extension Clarification on Zone Status + March 2001 + + + RFC3445 - - Eastlake - D. - 3rd - + + Massey + D. + + + Rose + S. + - Storage of Diffie-Hellman Keys in the Domain Name System (DNS) - March 1999 - - - RFC2540 + Limiting the Scope of the KEY Resource Record (RR) + December 2002 + + + RFC3655 - - Eastlake - D. - 3rd - + + Wellington + B. + + + Gudmundsson + O. + - Detached Domain Name System (DNS) Information - March 1999 - - - RFC2782 - - Gulbrandsen - A. - - - Vixie - P. - - - Esibov - L. - - A DNS RR for specifying the location of services (DNS SRV) - February 2000 - - - RFC2915 - - Mealling - M. - - - Daniel - R. - - The Naming Authority Pointer (NAPTR) DNS Resource Record - September 2000 - - - RFC3110 - - Eastlake - D. - 3rd - - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) - May 2001 - - - RFC3123 - - Koch - P. - - A DNS RR Type for Lists of Address Prefixes (APL RR) - June 2001 - - - RFC3596 - - - Thomson - S. - - - C. - Huitema - - - V. - Ksinant - - - M. - Souissi - - - <acronym>DNS</acronym> Extensions to support IP - version 6 - October 2003 - - - RFC3597 - - Gustafsson - A. - - Handling of Unknown DNS Resource Record (RR) Types - September 2003 - - - - <acronym>DNS</acronym> and the Internet - - RFC1101 - - Mockapetris - P. V. - - <acronym>DNS</acronym> Encoding of Network Names - and Other Types - April 1989 - - - RFC1123 - - Braden - R. - - Requirements for Internet Hosts - Application and - Support - October 1989 - - - RFC1591 - - Postel - J. - - Domain Name System Structure and Delegation - March 1994 - - - RFC2317 - - - Eidnes - H. - - - G. - de Groot - - - P. - Vixie - - - Classless IN-ADDR.ARPA Delegation - March 1998 - - - RFC2826 - - - Internet Architecture Board - - - IAB Technical Comment on the Unique DNS Root - May 2000 - - - RFC2929 - - - Eastlake - D. - 3rd - - - Brunner-Williams - E. - - - Manning - B. - - - Domain Name System (DNS) IANA Considerations - September 2000 - - - - <acronym>DNS</acronym> Operations - - RFC1033 - - Lottor - M. - - Domain administrators operations guide. - November 1987 - - - RFC1537 - - Beertema - P. - - Common <acronym>DNS</acronym> Data File - Configuration Errors - October 1993 - - - RFC1912 - - Barr - D. - - Common <acronym>DNS</acronym> Operational and - Configuration Errors - February 1996 - - - RFC2010 - - - Manning - B. - - - P. - Vixie - - - Operational Criteria for Root Name Servers. - October 1996 - - - RFC2219 - - - Hamilton - M. - - - R. - Wright - - - Use of <acronym>DNS</acronym> Aliases for - Network Services. - October 1997 - - - - Internationalized Domain Names - - RFC2825 + Redefinition of DNS Authenticated Data (AD) bit + November 2003 + + + RFC3658 - - IAB - - - Daigle - R. - + + Gudmundsson + O. + - A Tangled Web: Issues of I18N, Domain Names, - and the Other Internet protocols - May 2000 - - - RFC3490 + Delegation Signer (DS) Resource Record (RR) + December 2003 + + + RFC3755 - - Faltstrom - P. - - - Hoffman - P. - - - Costello - A. - + + Weiler + S. + - Internationalizing Domain Names in Applications (IDNA) - March 2003 - - - RFC3491 + Legacy Resolver Compatibility for Delegation Signer (DS) + May 2004 + + + RFC3757 - - Hoffman - P. - - - Blanchet - M. - + + Kolkman + O. + + + Schlyter + J. + + + Lewis + E. + - Nameprep: A Stringprep Profile for Internationalized Domain Names - March 2003 - - - RFC3492 + Domain Name System KEY (DNSKEY) Resource Record + (RR) Secure Entry Point (SEP) Flag + April 2004 + + + RFC3845 - - Costello - A. - + + Schlyter + J. + - Punycode: A Bootstring encoding of Unicode - for Internationalized Domain Names in - Applications (IDNA) - March 2003 - + DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format + August 2004 + - - Other <acronym>DNS</acronym>-related RFCs - - - Note: the following list of RFCs, although - DNS-related, are not - concerned with implementing software. - - - - RFC1464 - - Rosenbaum - R. - - Using the Domain Name System To Store Arbitrary String - Attributes - May 1993 - - - RFC1713 - - Romao - A. - - Tools for <acronym>DNS</acronym> Debugging - November 1994 - - - RFC1794 - - Brisco - T. - - <acronym>DNS</acronym> Support for Load - Balancing - April 1995 - - - RFC2240 - - Vaughan - O. - - A Legal Basis for Domain Name Allocation - November 1997 - - - RFC2345 - - - Klensin - J. - - - T. - Wolf - - - G. - Oglesby - - - Domain Names and Company Name Retrieval - May 1998 - - - RFC2352 - - Vaughan - O. - - A Convention For Using Legal Names as Domain Names - May 1998 - - - RFC3071 - - - Klensin - J. - - - Reflections on the DNS, RFC 1591, and Categories of Domains - February 2001 - - - RFC3258 - - - Hardie - T. - - - Distributing Authoritative Name Servers via - Shared Unicast Addresses - April 2002 - - - RFC3901 - - - Durand - A. - - - J. - Ihren - - - DNS IPv6 Transport Operational Guidelines - September 2004 - - - - Obsolete and Unimplemented Experimental RFC - - RFC1712 - - - Farrell - C. - - - M. - Schulze - - - S. - Pleitner - - - D. - Baldoni - - - <acronym>DNS</acronym> Encoding of Geographical - Location - November 1994 - - - RFC2673 - - - Crawford - M. - - - Binary Labels in the Domain Name System - August 1999 - - - RFC2874 - - - Crawford - M. - - - Huitema - C. - - - DNS Extensions to Support IPv6 Address Aggregation - and Renumbering - July 2000 - - - - Obsoleted DNS Security RFCs - - - Most of these have been consolidated into RFC4033, - RFC4034 and RFC4035 which collectively describe DNSSECbis. - - - - RFC2065 - - - Eastlake - 3rd - D. - - - C. - Kaufman - - - Domain Name System Security Extensions - January 1997 - - - RFC2137 - - Eastlake - 3rd - D. - - Secure Domain Name System Dynamic Update - April 1997 - - - RFC2535 - - - Eastlake - 3rd - D. - - - Domain Name System Security Extensions - March 1999 - - - RFC3008 - - - Wellington - B. - - - Domain Name System Security (DNSSEC) - Signing Authority - November 2000 - - - RFC3090 - - - Lewis - E. - - - DNS Security Extension Clarification on Zone Status - March 2001 - - - RFC3445 - - - Massey - D. - - - Rose - S. - - - Limiting the Scope of the KEY Resource Record (RR) - December 2002 - - - RFC3655 - - - Wellington - B. - - - Gudmundsson - O. - - - Redefinition of DNS Authenticated Data (AD) bit - November 2003 - - - RFC3658 - - - Gudmundsson - O. - - - Delegation Signer (DS) Resource Record (RR) - December 2003 - - - RFC3755 - - - Weiler - S. - - - Legacy Resolver Compatibility for Delegation Signer (DS) - May 2004 - - - RFC3757 - - - Kolkman - O. - - - Schlyter - J. - - - Lewis - E. - - - Domain Name System KEY (DNSKEY) Resource Record - (RR) Secure Entry Point (SEP) Flag - April 2004 - - - RFC3845 - - - Schlyter - J. - - - DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format - August 2004 - - - - - - Internet Drafts - - Internet Drafts (IDs) are rough-draft working documents of - the Internet Engineering Task Force. They are, in essence, RFCs - in the preliminary stages of development. Implementors are - cautioned not - to regard IDs as archival, and they should not be quoted or cited - in any formal documents unless accompanied by the disclaimer that - they are "works in progress." IDs have a lifespan of six months - after which they are deleted unless updated by their authors. - - - - Other Documents About <acronym>BIND</acronym> - - - - - - Albitz - Paul - - - Cricket - Liu - - - <acronym>DNS</acronym> and <acronym>BIND</acronym> - - 1998 - Sebastopol, CA: O'Reilly and Associates - - - - + + + + Internet Drafts + + Internet Drafts (IDs) are rough-draft working documents of + the Internet Engineering Task Force. They are, in essence, RFCs + in the preliminary stages of development. Implementors are + cautioned not + to regard IDs as archival, and they should not be quoted or cited + in any formal documents unless accompanied by the disclaimer that + they are "works in progress." IDs have a lifespan of six months + after which they are deleted unless updated by their authors. + + + + Other Documents About <acronym>BIND</acronym> + + + + + + Albitz + Paul + + + Cricket + Liu + + + <acronym>DNS</acronym> and <acronym>BIND</acronym> + + 1998 + Sebastopol, CA: O'Reilly and Associates + + + +