diff --git a/CHANGES b/CHANGES index 18a6cf237a..1478e37956 100644 --- a/CHANGES +++ b/CHANGES @@ -10,19 +10,38 @@ the view being deleted while nta tests are being performed. [GL #2067] + --- 9.11.22 released --- + +5481. [security] "update-policy" rules of type "subdomain" were + incorrectly treated as "zonesub" rules, which allowed + keys used in "subdomain" rules to update names outside + of the specified subdomains. The problem was fixed by + making sure "subdomain" rules are again processed as + described in the ARM. (CVE-2020-8624) [GL #2055] + +5480. [security] When BIND 9 was compiled with native PKCS#11 support, it + was possible to trigger an assertion failure in code + determining the number of bits in the PKCS#11 RSA public + key with a specially crafted packet. (CVE-2020-8623) + [GL #2037] + +5476. [security] It was possible to trigger an assertion failure when + verifying the response to a TSIG-signed request. + (CVE-2020-8622) [GL #2028] + +5475. [bug] Wildcard RPZ passthru rules could incorrectly be + overridden by other rules that were loaded from RPZ + zones which appeared later in the "response-policy" + statement. This has been fixed. [GL #1619] + 5474. [bug] dns_rdata_hip_next() failed to return ISC_R_NOMORE when it should have. [GL !3880] -5466. [bug] Fix RPZ wildcard passthru ignored when a rejection - file would overwrite a passthru action matching some - rule in a previously loaded passthru rpz zone. - [GL #1619] - -5465. [func] Fallback to built in trust-anchors, managed-keys, or - trusted-keys if the bindkeys-file (bind.keys) cannot +5465. [func] Added fallback to built-in trust-anchors, managed-keys, + or trusted-keys if the bindkeys-file (bind.keys) cannot be parsed. [GL #1235] -5463. [bug] Address potential NULL pointer dereference on out of +5463. [bug] Address a potential NULL pointer dereference when out of memory in dnstap.c. [GL #2010] 5462. [bug] Move LMDB locking from LMDB itself to named. [GL #1976] diff --git a/README b/README index 5c9c82a357..5639fa6269 100644 --- a/README +++ b/README @@ -342,6 +342,12 @@ BIND 9.11.21 BIND 9.11.21 is a maintenance release. +BIND 9.11.22 + +BIND 9.11.22 is a maintenance release, and also addresses the security +vulnerabilities disclosed in CVE-2020-8622, CVE-2020-8623, and +CVE-2020-8624. + Building BIND Minimally, BIND requires a UNIX or Linux system with an ANSI C compiler, diff --git a/README.md b/README.md index 6a4dff8e26..acbd1d5362 100644 --- a/README.md +++ b/README.md @@ -359,6 +359,12 @@ vulnerability disclosed in CVE-2020-8619. BIND 9.11.21 is a maintenance release. +#### BIND 9.11.22 + +BIND 9.11.22 is a maintenance release, and also addresses the security +vulnerabilities disclosed in CVE-2020-8622, CVE-2020-8623, and +CVE-2020-8624. + ### Building BIND Minimally, BIND requires a UNIX or Linux system with an ANSI C compiler, diff --git a/bin/named/zoneconf.c b/bin/named/zoneconf.c index 55f191bad4..b77a07c14a 100644 --- a/bin/named/zoneconf.c +++ b/bin/named/zoneconf.c @@ -239,7 +239,8 @@ configure_zone_ssutable(const cfg_obj_t *zconfig, dns_zone_t *zone, str = cfg_obj_asstring(matchtype); CHECK(dns_ssu_mtypefromstring(str, &mtype)); - if (mtype == dns_ssumatchtype_subdomain) { + if (mtype == dns_ssumatchtype_subdomain && + strcasecmp(str, "zonesub") == 0) { usezone = true; } diff --git a/bin/tests/system/nsupdate/ns1/named.conf.in b/bin/tests/system/nsupdate/ns1/named.conf.in index 1d999adc39..e90907aecd 100644 --- a/bin/tests/system/nsupdate/ns1/named.conf.in +++ b/bin/tests/system/nsupdate/ns1/named.conf.in @@ -36,6 +36,16 @@ key altkey { secret "1234abcd8765"; }; +key restricted.example.nil { + algorithm hmac-md5; + secret "1234abcd8765"; +}; + +key zonesub-key.example.nil { + algorithm hmac-md5; + secret "1234subk8765"; +}; + include "ddns.key"; zone "example.nil" { @@ -44,7 +54,9 @@ zone "example.nil" { check-integrity no; check-mx ignore; update-policy { + grant zonesub-key.example.nil zonesub TXT; grant ddns-key.example.nil subdomain example.nil ANY; + grant restricted.example.nil subdomain restricted.example.nil ANY; }; allow-transfer { any; }; }; diff --git a/bin/tests/system/nsupdate/tests.sh b/bin/tests/system/nsupdate/tests.sh index 44436dbce8..14952c8cd6 100755 --- a/bin/tests/system/nsupdate/tests.sh +++ b/bin/tests/system/nsupdate/tests.sh @@ -428,7 +428,7 @@ EOF # this also proves that the server is still running. $DIG $DIGOPTS +tcp +noadd +nosea +nostat +noquest +nocmd +norec example.\ @10.53.0.3 nsec3param > dig.out.ns3.$n || ret=1 -grep "ANSWER: 0" dig.out.ns3.$n > /dev/null || ret=1 +grep "ANSWER: 0," dig.out.ns3.$n > /dev/null || ret=1 grep "flags:[^;]* aa[ ;]" dig.out.ns3.$n > /dev/null || ret=1 [ $ret = 0 ] || { echo_i "failed"; status=1; } @@ -443,7 +443,7 @@ EOF $DIG $DIGOPTS +tcp +noadd +nosea +nostat +noquest +nocmd +norec nsec3param.test.\ @10.53.0.3 nsec3param > dig.out.ns3.$n || ret=1 -grep "ANSWER: 1" dig.out.ns3.$n > /dev/null || ret=1 +grep "ANSWER: 1," dig.out.ns3.$n > /dev/null || ret=1 grep "3600.*NSEC3PARAM" dig.out.ns3.$n > /dev/null || ret=1 grep "flags:[^;]* aa[ ;]" dig.out.ns3.$n > /dev/null || ret=1 [ $ret = 0 ] || { echo_i "failed"; status=1; } @@ -460,7 +460,7 @@ EOF _ret=1 for i in 0 1 2 3 4 5 6 7 8 9; do $DIG $DIGOPTS +tcp +norec +time=1 +tries=1 @10.53.0.3 nsec3param.test. NSEC3PARAM > dig.out.ns3.$n || _ret=1 - if grep "ANSWER: 2" dig.out.ns3.$n > /dev/null; then + if grep "ANSWER: 2," dig.out.ns3.$n > /dev/null; then _ret=0 break fi @@ -485,7 +485,7 @@ EOF _ret=1 for i in 0 1 2 3 4 5 6 7 8 9; do $DIG $DIGOPTS +tcp +norec +time=1 +tries=1 @10.53.0.3 nsec3param.test. NSEC3PARAM > dig.out.ns3.$n || _ret=1 - if grep "ANSWER: 1" dig.out.ns3.$n > /dev/null; then + if grep "ANSWER: 1," dig.out.ns3.$n > /dev/null; then _ret=0 break fi @@ -631,6 +631,58 @@ then echo_i "failed"; status=1 fi +n=`expr $n + 1` +ret=0 +echo_i "check that 'update-policy subdomain' is properly enforced ($n)" +# "restricted.example.nil" matches "grant ... subdomain restricted.example.nil" +# and thus this UPDATE should succeed. +$NSUPDATE -d < nsupdate.out1-$n 2>&1 || ret=1 +server 10.53.0.1 ${PORT} +key restricted.example.nil 1234abcd8765 +update add restricted.example.nil 0 IN TXT everywhere. +send +END +$DIG $DIGOPTS +tcp @10.53.0.1 restricted.example.nil TXT > dig.out.1.test$n || ret=1 +grep "TXT.*everywhere" dig.out.1.test$n > /dev/null || ret=1 +# "example.nil" does not match "grant ... subdomain restricted.example.nil" and +# thus this UPDATE should fail. +$NSUPDATE -d < nsupdate.out2-$n 2>&1 && ret=1 +server 10.53.0.1 ${PORT} +key restricted.example.nil 1234abcd8765 +update add example.nil 0 IN TXT everywhere. +send +END +$DIG $DIGOPTS +tcp @10.53.0.1 example.nil TXT > dig.out.2.test$n || ret=1 +grep "TXT.*everywhere" dig.out.2.test$n > /dev/null && ret=1 +[ $ret = 0 ] || { echo_i "failed"; status=1; } + +n=`expr $n + 1` +ret=0 +echo_i "check that 'update-policy zonesub' is properly enforced ($n)" +# grant zonesub-key.example.nil zonesub TXT; +# the A record update should be rejected as it is not in the type list +$NSUPDATE -d < nsupdate.out1-$n 2>&1 && ret=1 +server 10.53.0.1 ${PORT} +key zonesub-key.example.nil 1234subk8765 +update add zonesub.example.nil 0 IN A 1.2.3.4 +send +END +$DIG $DIGOPTS +tcp @10.53.0.1 zonesub.example.nil A > dig.out.1.test$n || ret=1 +grep "status: REFUSED" nsupdate.out1-$n > /dev/null || ret=1 +grep "ANSWER: 0," dig.out.1.test$n > /dev/null || ret=1 +# the TXT record update should be accepted as it is in the type list +$NSUPDATE -d < nsupdate.out2-$n 2>&1 || ret=1 +server 10.53.0.1 ${PORT} +key zonesub-key.example.nil 1234subk8765 +update add zonesub.example.nil 0 IN TXT everywhere. +send +END +$DIG $DIGOPTS +tcp @10.53.0.1 zonesub.example.nil TXT > dig.out.2.test$n || ret=1 +grep "status: REFUSED" nsupdate.out2-$n > /dev/null && ret=1 +grep "ANSWER: 1," dig.out.2.test$n > /dev/null || ret=1 +grep "TXT.*everywhere" dig.out.2.test$n > /dev/null || ret=1 +[ $ret = 0 ] || { echo_i "failed"; status=1; } + n=`expr $n + 1` ret=0 echo_i "check that changes to the DNSKEY RRset TTL do not have side effects ($n)" diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html index 920aa37109..dffc85142e 100644 --- a/doc/arm/Bv9ARM.ch01.html +++ b/doc/arm/Bv9ARM.ch01.html @@ -247,9 +247,9 @@ The Domain Name System (DNS)

- The purpose of this document is to explain the installation + This document explains the installation and upkeep of the BIND (Berkeley Internet - Name Domain) software package, and we + Name Domain) software package. We begin by reviewing the fundamentals of the Domain Name System (DNS) as they relate to BIND.

@@ -308,7 +308,7 @@

For administrative purposes, the name space is partitioned into areas called zones, each starting at a node and - extending down to the leaf nodes or to nodes where other zones + extending down to the "leaf" nodes or to nodes where other zones start. The data for each zone is stored in a name server, which answers queries about the zone using the DNS protocol. @@ -368,7 +368,7 @@ terminal, that is, has no subdomains. Every subdomain is a domain and every domain except the root is also a subdomain. The terminology is - not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 + not intuitive and we suggest reading RFCs 1033, 1034, and 1035 to gain a complete understanding of this difficult and subtle topic. @@ -377,12 +377,12 @@

Though BIND is called a "domain name server", - it deals primarily in terms of zones. The master and slave + it deals primarily in terms of zones. The "primary" and "secondary" declarations in the named.conf file specify - zones, not domains. When you ask some other site if it is willing to - be a slave server for your domain, you are - actually asking for slave service for some collection of zones. + zones, not domains. When BIND asks some other site if it is willing to + be a secondary server for a domain, it is + actually asking for secondary service for some collection of zones.

@@ -408,12 +408,13 @@

-The Primary Master

+The Primary Server

- The authoritative server where the master copy of the zone + The authoritative server where the main copy of the zone data is maintained is called the - primary master server, or simply the + primary (or + master) server, or simply the primary. Typically it loads the zone contents from some local file edited by humans or perhaps generated mechanically from some other local file which is @@ -423,7 +424,7 @@

- In some cases, however, the master file may not be edited + In some cases, however, the zone file may not be edited by humans at all, but may instead be the result of dynamic update operations.

@@ -431,22 +432,23 @@

-Slave Servers

+Secondary Servers

- The other authoritative servers, the slave - servers (also known as secondary servers) - load the zone contents from another server using a replication + The other authoritative servers, called the + secondary + (or slave) servers, load the zone + contents from another server using a replication process known as a zone transfer. - Typically the data are transferred directly from the primary + Typically the data is transferred directly from the primary master, but it is also possible to transfer it from another - slave. In other words, a slave server may itself act as a - master to a subordinate slave server. + secondary. In other words, a secondary server may itself act as a + primary to a subordinate secondary server.

- Periodically, the slave server must send a refresh query to + Periodically, the secondary server must send a refresh query to determine whether the zone contents have been updated. This - is done by sending a query for the zone's SOA record and + is done by sending a query for the zone's Start of Authority (SOA) record and checking whether the SERIAL field has been updated; if so, a new transfer request is initiated. The timing of these refresh queries is controlled by the SOA REFRESH and RETRY @@ -459,8 +461,8 @@

If the zone data cannot be updated within the time specified by the SOA EXPIRE option (up to a hard-coded maximum of - 24 weeks) then the slave zone expires and will no longer - respond to queries. + 24 weeks), the secondary zone expires and no longer + responds to queries.

@@ -469,15 +471,14 @@ Stealth Servers

- Usually all of the zone's authoritative servers are listed in + Usually, all of the zone's authoritative servers are listed in NS records in the parent zone. These NS records constitute a delegation of the zone from the parent. The authoritative servers are also listed in the zone file itself, at the top level or apex - of the zone. You can list servers in the zone's top-level NS - records that are not in the parent's NS delegation, but you cannot - list servers in the parent's delegation that are not present at - the zone's top level. + of the zone. Servers that are not in the parent's NS delegation can be listed in the zone's top-level NS + records, but servers that are not present at + the zone's top level cannot be listed in the parent's delegation.

@@ -485,7 +486,7 @@ authoritative for a zone but is not listed in that zone's NS records. Stealth servers can be used for keeping a local copy of a - zone to speed up access to the zone's records or to make sure that + zone, to speed up access to the zone's records, or to make sure that the zone is available even if all the "official" servers for the zone are @@ -493,11 +494,10 @@

- A configuration where the primary master server itself is a + A configuration where the primary server itself is a stealth server is often referred to as a "hidden primary" configuration. One use for this configuration is when the primary - master - is behind a firewall and therefore unable to communicate directly + is behind a firewall and is therefore unable to communicate directly with the outside world.

@@ -534,7 +534,7 @@

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. + Time-To-Live (TTL) field associated with each resource record.

@@ -551,18 +551,35 @@

- 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. + Forwarders are typically used when an administrator does not + wish for all the servers at a given site to interact + directly with the rest of the Internet. For example, a + common scenario is when multiple internal DNS servers are + behind an Internet firewall. Servers behind the firewall + forward their requests to the server with external access, + which queries Internet DNS servers on the internal servers' + behalf. +

+ +

+ Another scenario (largely now superseded by Response Policy + Zones) is to send queries first to a custom server for RBL + processing before forwarding them to the wider Internet. +

+ +

+ There may be one or more forwarders in a given setup. The + order in which the forwarders are listed in + named.conf does not determine the + sequence in which they are queried; rather, + named uses the response times from + previous queries to select the server that is likely to + respond the most quickly. A server that has not yet been + queried is given an initial small random response time to + ensure that it is tried at least once. Dynamic adjustment of + the recorded response times ensures that all forwarders are + queried, even those with slower response times. This + permits changes in behavior based on server responsiveness.

@@ -575,7 +592,7 @@

The BIND name server can simultaneously act as - a master for some zones, a slave for other zones, and as a caching + a primary for some zones, a secondary for other zones, and a caching (recursive) server for a set of local clients.

@@ -616,6 +633,6 @@ -

BIND 9.11.21 (Extended Support Version)

+

BIND 9.11.22 (Extended Support Version)

diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html index a630e95cc1..031cb49c47 100644 --- a/doc/arm/Bv9ARM.ch02.html +++ b/doc/arm/Bv9ARM.ch02.html @@ -39,7 +39,7 @@
Hardware requirements
CPU Requirements
Memory Requirements
-
Name Server Intensive Environment Issues
+
Name Server-Intensive Environment Issues
Supported Operating Systems
@@ -50,13 +50,13 @@

DNS hardware requirements have traditionally been quite modest. - For many installations, servers that have been pensioned off from + For many installations, servers that have been retired 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 + However, the DNSSEC features of BIND 9 + may be quite + CPU-intensive, 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 @@ -68,31 +68,31 @@ 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. + i386-class machines, + for serving static zones without caching, to enterprise-class + machines 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, + Server memory must be sufficient to hold both the + cache and the zones loaded from disk. The max-cache-size + option can 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 + If additional section caching (the section called “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 + 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 + 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.

@@ -101,17 +101,17 @@

-Name Server Intensive Environment Issues

+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 + For name server-intensive environments, there are two + configurations that may be used. The first is one 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 + 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 + In this configuration, none of the individual machines need 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. @@ -123,12 +123,11 @@ 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. + ISC BIND 9 compiles and runs on many + Unix-like operating systems and on + Microsoft Windows Server 2012 R2, 2016 and Windows 10. For an up-to-date - list of supported systems, see the README file in the top level + list of supported systems, see the PLATFORMS.md file in the top-level directory of the BIND 9 source distribution.

@@ -151,6 +150,6 @@ -

BIND 9.11.21 (Extended Support Version)

+

BIND 9.11.22 (Extended Support Version)

diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html index 0ed14425e0..6a3d091104 100644 --- a/doc/arm/Bv9ARM.ch03.html +++ b/doc/arm/Bv9ARM.ch03.html @@ -51,7 +51,7 @@

- In this chapter we provide some suggested configurations along + In this chapter we provide some suggested configurations, along with guidelines for their use. We suggest reasonable values for certain option settings.

@@ -69,7 +69,7 @@ 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 + option. The same effect can be achieved using suitable firewall rules.

@@ -100,8 +100,8 @@ zone "0.0.127.in-addr.arpa" {

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". + that is the primary server for "example.com" + and a secondary server for the subdomain "eng.example.com". 

@@ -123,22 +123,22 @@ zone "0.0.127.in-addr.arpa" {
      file "localhost.rev";
      notify no;
 };
-// We are the master server for example.com
+// We are the primary server for example.com
 zone "example.com" {
      type master;
      file "example.com.db";
-     // IP addresses of slave servers allowed to
+     // IP addresses of secondary servers allowed to
      // transfer example.com
      allow-transfer {
           192.168.4.14;
           192.168.5.53;
      };
 };
-// We are a slave server for eng.example.com
+// We are a secondary server for eng.example.com
 zone "eng.example.com" {
      type slave;
      file "eng.example.com.bk";
-     // IP address of eng.example.com master server
+     // IP address of eng.example.com primary server
      masters { 192.168.4.12; };
 };
@@ -159,9 +159,9 @@ zone "eng.example.com" {

- 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 + For example, assuming three HTTP 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:

@@ -283,11 +283,11 @@ zone "eng.example.com" {

- 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 + When a resolver queries for these records, BIND rotates + them and responds to the query with the records in a different + order. In the example above, clients 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. + use the first record returned and discard the rest.

For more detail on ordering responses, check the @@ -307,7 +307,7 @@ zone "eng.example.com" { Tools for Use With the Name Server Daemon

This section describes several indispensable diagnostic, - administrative and monitoring tools available to the system + administrative, and monitoring tools available to the system administrator for controlling and debugging the name server daemon.

@@ -316,8 +316,7 @@ zone "eng.example.com" { Diagnostic Tools

The dig, host, and - nslookup programs are all command - line tools + nslookup programs are all command-line tools for manually querying name servers. They differ in style and output format.

@@ -329,7 +328,7 @@ zone "eng.example.com" { 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 + 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 @@ -346,7 +345,7 @@ zone "eng.example.com" { [%comment]

- The usual simple use of dig will take the form + The usual simple use of dig takes the form

dig @server domain query-type query-class @@ -393,7 +392,7 @@ zone "eng.example.com" { 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 + 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. @@ -408,9 +407,9 @@ zone "eng.example.com" {

Interactive mode is entered when no arguments are given (the - default name server will be used) or when the first argument + default name server is used) or when the first argument is a - hyphen (`-') and the second argument is the host name or + hyphen ("-") and the second argument is the host name or Internet address of a name server.

@@ -460,7 +459,7 @@ zone "eng.example.com" {

The named-checkzone program - checks a master file for + checks a zone file for syntax and consistency.

@@ -482,7 +481,7 @@ zone "eng.example.com" {

- Similar to named-checkzone, but + This tool is similar to named-checkzone, but it always dumps the zone content to a specified file (typically in a different format).

@@ -496,15 +495,9 @@ zone "eng.example.com" { (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: + If rndc is run without any + options, + it displays a usage message as follows:

rndc @@ -532,7 +525,7 @@ zone "eng.example.com" { alternate location can be specified with the -c option. If the configuration file is not found, - rndc will also look in + rndc also looks in /etc/rndc.key (or whatever sysconfdir was defined when the BIND build was @@ -547,10 +540,10 @@ zone "eng.example.com" {

The format of the configuration file is similar to - that of named.conf, but + that of named.conf, but is limited to - only four statements, the options, - key, server and + 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 @@ -564,9 +557,9 @@ zone "eng.example.com" { 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 -s + host name or address argument and represents the server + that + is contacted if no -s option is provided on the command line. default-key takes the name of a key as its argument, as defined by a key statement. @@ -594,16 +587,16 @@ zone "eng.example.com" { The key statement has two clauses: algorithm and secret. - While the configuration parser will accept any string as the + While the configuration parser accepts any string as the argument - to algorithm, currently only the strings + to algorithm, currently only the strings "hmac-md5", "hmac-sha1", "hmac-sha224", "hmac-sha256", - "hmac-sha384" + "hmac-sha384", and "hmac-sha512" - have any meaning. The secret is a Base64 encoded string + have any meaning. The secret is a Base64-encoded string as specified in RFC 3548.

@@ -642,7 +635,7 @@ options {

This file, if installed as /etc/rndc.conf, - would allow the command: + allows the command:

@@ -650,8 +643,8 @@ options {

- 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 + to connect to 127.0.0.1 port 953 and causes the name server + to reload, if a name server on the local machine is running with following controls statements:

@@ -664,22 +657,22 @@ controls {

- and it had an identical key statement for + and it has 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 + program + conveniently creates an rndc.conf + file, and also displays the corresponding controls - statement that you need to + statement needed to add to named.conf. Alternatively, - you can run rndc-confgen -a + it is possible to run rndc-confgen -a to set up - a rndc.key file and not + an rndc.key file and not modify named.conf at all.

@@ -694,7 +687,7 @@ controls {

Signals

- Certain UNIX signals cause the name server to take specific + 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.

@@ -759,6 +752,6 @@ controls {
-

BIND 9.11.21 (Extended Support Version)

+

BIND 9.11.22 (Extended Support Version)

diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html index ccf881c0aa..885302a89a 100644 --- a/doc/arm/Bv9ARM.ch04.html +++ b/doc/arm/Bv9ARM.ch04.html @@ -38,14 +38,14 @@
Notify
Dynamic Update
-
The journal file
+
The Journal File
Incremental Zone Transfers (IXFR)
Split DNS
-
Example split DNS setup
+
Example Split DNS Setup
TSIG
Generating a Shared Key
-
Loading A New Key
+
Loading a New Key
Instructing the Server to Use a Key
TSIG-Based Access Control
Errors
@@ -56,22 +56,22 @@
Generating Keys
Signing the Zone
-
Configuring Servers
+
Configuring Servers for DNSSEC
DNSSEC, Dynamic Zones, and Automatic Signing
Converting from insecure to secure
-
Dynamic DNS update method
-
Fully automatic zone signing
-
Private-type records
-
DNSKEY rollovers
-
Dynamic DNS update method
-
Automatic key rollovers
-
NSEC3PARAM rollovers via UPDATE
-
Converting from NSEC to NSEC3
-
Converting from NSEC3 to NSEC
-
Converting from secure to insecure
-
Periodic re-signing
+
Dynamic DNS Update Method
+
Fully Automatic Zone Signing
+
Private Type Records
+
DNSKEY Rollovers
+
Dynamic DNS Update Method
+
Automatic Key Rollovers
+
NSEC3PARAM Rollovers via UPDATE
+
Converting From NSEC to NSEC3
+
Converting From NSEC3 to NSEC
+
Converting From Secure to Insecure
+
Periodic Re-signing
NSEC3 and OPTOUT
Dynamic Trust Anchor Management
@@ -79,7 +79,7 @@
Validating Resolver
Authoritative Server
-
PKCS#11 (Cryptoki) support
+
PKCS#11 (Cryptoki) Support
Prerequisites
Native PKCS#11
@@ -94,7 +94,7 @@
Configuring DLZ
Sample DLZ Driver
-
DynDB (Dynamic Database)
+
Dynamic Database (DynDB)
Configuring DynDB
Sample DynDB Module
@@ -103,12 +103,12 @@
Principle of Operation
Configuring Catalog Zones
-
Catalog Zone format
+
Catalog Zone Format
IPv6 Support in BIND 9
Address Lookups Using AAAA Records
-
Address to Name Lookups Using Nibble Format
+
Address-to-Name Lookups Using Nibble Format
@@ -117,11 +117,11 @@

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 primary + servers to notify their secondary servers of changes to a zone's data. In + response to a NOTIFY from a primary server, the + secondary checks to see that its version of the zone is the + current version and, if not, initiates a zone transfer.

@@ -136,10 +136,10 @@

Note

- As a slave zone can also be a master to other slaves, named, + As a secondary zone can also be a primary to other secondaries, named, by default, sends NOTIFY messages for every zone - it loads. Specifying notify master-only; will - cause named to only send NOTIFY for master + it loads. Specifying notify primary-only; + causes named to only send NOTIFY for primary zones that it loads.

@@ -151,8 +151,8 @@ 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 + Dynamic Update is a method for adding, replacing, or deleting + records in a primary server by sending it a special form of DNS messages. The format and meaning of these messages is specified in RFC 2136.

@@ -166,25 +166,25 @@

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. + are permitted for the key local-ddns, + which is generated by named at startup. See the section called “Dynamic Update Policies” for more details.

- Dynamic updates using Kerberos signed requests can be made - using the TKEY/GSS protocol by setting either the - tkey-gssapi-keytab option, or alternatively + Dynamic updates using Kerberos-signed requests can be made + using the TKEY/GSS protocol, either by setting the + tkey-gssapi-keytab option, or by setting both the tkey-gssapi-credential and tkey-domain options. Once enabled, - Kerberos signed requests will be matched against the update + Kerberos-signed requests are matched against the update policies for the zone, using the Kerberos principal as the signer for the request.

Updating of secure zones (zones using DNSSEC) follows RFC - 3007: RRSIG, NSEC and NSEC3 records affected by updates are + 3007: RRSIG, NSEC, and NSEC3 records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based on transaction signatures and an explicit server policy. @@ -192,7 +192,7 @@

-The journal file

+The Journal File

All changes made to a zone using dynamic update are stored @@ -201,27 +201,27 @@ 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 + 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 server also occasionally writes ("dumps") 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 + During the dump process, transient files are created with the extensions .jnw and .jbk; under ordinary circumstances, these - will be removed when the dump is complete, and can be safely + are 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 + When a server is restarted after a shutdown or crash, it replays + the journal file to incorporate into the zone any updates that took place after the last zone dump.

@@ -229,32 +229,32 @@

Changes that result from incoming incremental zone transfers are also - journalled in a similar way. + journaled 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. + 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. + 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 + To make changes to a dynamic zone + manually, follow these steps: + first, disable dynamic updates to the zone using rndc freeze zone. - This will update the zone's master file with the changes + This updates the zone file with the changes stored in its .jnl file. - Edit the zone file. Run + Then, edit the zone file. Finally, run rndc thaw zone to reload the changed zone and re-enable dynamic updates.

rndc sync zone - will update the zone file with changes from the journal file + updates the zone file with changes from the journal file without stopping dynamic updates; this may be useful for viewing the current zone state. To remove the .jnl file after updating the zone file, use @@ -271,26 +271,26 @@

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 + secondary servers to transfer only changed data, instead of having to + transfer an entire zone. The IXFR protocol is specified in RFC 1995. See Proposed Standards.

- When acting as a master, BIND 9 + When acting as a primary server, 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 + include primary zones maintained by dynamic update and secondary zones + whose data was obtained by IXFR. For manually maintained primary + zones, and for secondary 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 + When acting as a secondary server, BIND 9 + attempts 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. @@ -302,15 +302,15 @@ Split DNS

- Setting up different views, or visibility, of the DNS space to + Setting up different views 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. + split DNS setup. There are several + reasons an organization might want to set up its DNS this way.

- One common reason for setting up a DNS system this way is + One common reason to use split DNS is to hide "internal" DNS information from "external" clients on the - Internet. There is some debate as to whether or not this is actually + Internet. There is some debate as to whether 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 @@ -318,19 +318,19 @@ 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 + choose to use split DNS to present a consistent view of itself to the outside world.

- Another common reason for setting up a Split DNS system is + 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. + back into the internal network.

-Example split DNS setup

+Example Split DNS Setup

Let's say a company named Example, Inc. (example.com) @@ -347,15 +347,15 @@ 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 + In order to accomplish this, the company sets up two sets + of name servers. One set is on the inside network (in the reserved - IP space) and the other set will be on bastion hosts, which are + IP space) and the other set is on bastion hosts, which are "proxy" - hosts that can talk to both sides of its network, in the DMZ. + hosts in the DMZ that can talk to both sides of its network.

- The internal servers will be configured to forward all queries, + The internal servers are configured to forward all queries, except queries for site1.internal, site2.internal, site1.example.com, and site2.example.com, to the servers in the @@ -370,19 +370,19 @@ 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. + The external servers, which are on the bastion hosts, are + configured to serve the "public" version of the site1.example.com 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). + (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 + In addition, the public site1.example.com 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 + to those internal hosts. With the wildcard records, the mail is + delivered to the bastion host, which can then forward it on to internal hosts.

@@ -391,19 +391,19 @@ 

*   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 + network, the bastion hosts need to know how to deliver mail + to internal hosts. The resolvers on - the bastion hosts will need to be configured to point to the internal + the bastion hosts 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 + Queries for internal hostnames are answered by the internal + servers, and queries for external hostnames are forwarded back out to the DNS servers on the bastion hosts.

- In order for all this to work properly, internal clients will + For all of this to work properly, internal clients need to be configured to query only the internal name servers for DNS queries. This could also be enforced via selective @@ -411,12 +411,12 @@

If everything has been set properly, Example, Inc.'s - internal clients will now be able to: + internal clients are now able to:

  • - Look up any hostnames in the site1 + Look up any hostnames in the site1.example.com and site2.example.com zones. @@ -431,32 +431,32 @@ Look up any hostnames on the Internet.
  • - Exchange mail with both internal and external people. + Exchange mail with both internal and external users.

- Hosts on the Internet will be able to: + Hosts on the Internet are able to:

  • - Look up any hostnames in the site1 + Look up any hostnames in the site1.example.com and site2.example.com zones.
  • - Exchange mail with anyone in the site1 and + Exchange mail with anyone in the site1.example.com and site2.example.com zones.

- Here is an example configuration for the setup we just + Here is an example configuration for the setup just described above. Note that this is only configuration information; - for information on how to configure your zone files, see the section called “Sample Configurations”. + for information on how to configure the zone files, see the section called “Sample Configurations”.

@@ -487,7 +487,7 @@ options { ... }; -// sample master zone +// sample primary zone zone "site1.example.com" { type master; file "m/site1.example.com"; @@ -497,7 +497,7 @@ zone "site1.example.com" { allow-transfer { internals; }; }; -// sample slave zone +// sample secondary zone zone "site2.example.com" { type slave; file "s/site2.example.com"; @@ -549,7 +549,7 @@ options { ... }; -// sample slave zone +// sample secondary zone zone "site1.example.com" { type master; file "m/site1.foo.com"; @@ -591,10 +591,10 @@ nameserver 172.16.72.4 clients when IP-based access control is insufficient or needs to be overridden, or as a way to ensure message authenticity when it is critical to the integrity of the server, such as with dynamic - UPDATE messages or zone transfers from a master to a slave server. + UPDATE messages or zone transfers from a primary to a secondary server.

- This is a guide to setting up TSIG in BIND. + This section is a guide to setting up TSIG in BIND. It describes the configuration syntax and the process of creating TSIG keys.

@@ -607,15 +607,15 @@ nameserver 172.16.72.4
  • nsupdate(1) supports TSIG via the - -k, -l and - -y command line options, or via + -k, -l, and + -y command-line options, or via the key command when running interactively.
  • dig(1) supports TSIG via the - -k and -y command - line options. + -k and -y + command-line options.

@@ -628,14 +628,14 @@ nameserver 172.16.72.4 TSIG keys can be generated using the tsig-keygen command; the output of the command is a key directive suitable for inclusion in named.conf. The - key name, algorithm and size can be specified by command line parameters; + key name, algorithm, and size can be specified by command-line parameters; the defaults are "tsig-key", HMAC-SHA256, and 256 bits, respectively.

Any string which is a valid DNS name can be used as a key name. For example, a key to be shared between servers called host1 and host2 could - be called "host1-host2.", and this key could be generated using: + be called "host1-host2.", and this key can be generated using: 

   $ tsig-keygen host1-host2. > host1-host2.key
@@ -658,7 +658,7 @@ nameserver 172.16.72.4
 
       

 

-Loading A New Key

+Loading a New Key

         

           For a key shared between servers called
           host1 and host2,
@@ -679,7 +679,7 @@ key "host1-host2." {
           Since this text contains a secret, it
           is recommended that either named.conf not be
           world-readable, or that the key directive
-          be stored in a file which is not world-readable, and which is
+          be stored in a file which is not world-readable and which is
           included in named.conf via the
           include directive.
         

@@ -687,8 +687,8 @@ key "host1-host2." {
           Once a key has been added to named.conf and the
           server has been restarted or reconfigured, the server can recognize
           the key.  If the server receives a message signed by the
-          key, it will be able to verify the signature.  If the signature
-          is valid, the response will be signed using the same key.
+          key, it is able to verify the signature.  If the signature
+          is valid, the response is signed using the same key.
         

         

           TSIG keys that are known to a server can be listed using the
@@ -706,11 +706,11 @@ key "host1-host2." {
         

           For example, a key may be specified for each server in the
           masters statement in the definition of a
-          slave zone; in this case, all SOA QUERY messages, NOTIFY
-          messages, and zone transfer requests (AXFR or IXFR) will be
+          secondary zone; in this case, all SOA QUERY messages, NOTIFY
+          messages, and zone transfer requests (AXFR or IXFR) are
           signed using the specified key.  Keys may also be specified
-          in the also-notify statement of a master
-          or slave zone, causing NOTIFY messages to be signed using
+          in the also-notify statement of a primary
+          or secondary zone, causing NOTIFY messages to be signed using
           the specified key.
         

         

@@ -738,9 +738,9 @@ server 10.1.2.3 {
           configuration file.
         

         

-          Whenever any server sends a TSIG-signed DNS request, it will expect
+          Whenever any server sends a TSIG-signed DNS request, it expects
           the response to be signed with the same key. If a response is not
-          signed, or if the signature is not valid, the response will be
+          signed, or if the signature is not valid, the response is
           rejected.
         

       
@@ -750,13 +750,13 @@ server 10.1.2.3 {
 TSIG-Based Access Control
         

           TSIG keys may be specified in ACL definitions and ACL directives
-          such as allow-query, allow-transfer
+          such as allow-query, allow-transfer,
           and allow-update.
           The above key would be denoted in an ACL element as
           key host1-host2.
         

         

-          An example of an allow-update directive using
+          Here is an example of an allow-update directive using
           a TSIG key:
         

 
@@ -793,14 +793,14 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
             
 
  • 
               If a TSIG-aware server receives a message with a time
-              outside of the allowed range, the response will be signed, with
+              outside of the allowed range, the response will be signed but
               the TSIG extended error code set to BADTIME, and the time values
               will be adjusted so that the response can be successfully
               verified.
             
    • 
 
 
    
-          In all of the above cases, the server will return a response code
+          In all of the above cases, the server returns a response code
           of NOTAUTH (not authenticated).
         
    
       
@@ -826,9 +826,9 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
         a query of type TKEY to a TKEY-aware server.  The query must include
         an appropriate KEY record in the additional section, and
         must be signed using either TSIG or SIG(0) with a previously
-        established key.  The server's response, if successful, will
-        contain a TKEY record in its answer section.  After this transaction,
-        both participants will have enough information to calculate a
+        established key.  The server's response, if successful,
+        contains a TKEY record in its answer section.  After this transaction,
+        both participants have enough information to calculate a
         shared secret using Diffie-Hellman key exchange.  The shared secret
         can then be used by to sign subsequent transactions between the
         two servers.
@@ -853,13 +853,13 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
         BIND 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
+        is performed in the same manner as with TSIG keys; privileges can be
         granted or denied in ACL directives based on the key name.
       
    
       
    
-        When a SIG(0) signed message is received, it will only be
+        When a SIG(0) signed message is received, it is only
         verified if the key is known and trusted by the server. The
-        server will not attempt to recursively fetch or validate the
+        server does not attempt to recursively fetch or validate the
         key.
       
    
       
    
@@ -890,15 +890,13 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
         below.  In all cases, the -h 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 -d option, and
-        that the tools shipped with BIND 9.2.x and earlier are not compatible
-        with the current ones.
+        directory specified by the -d option.
       
    
 
       
    
         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
+        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
@@ -907,7 +905,7 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
 
       
    
         For other servers to trust data in this zone, they must
-        either be statically configured with this zone's zone key or the
+        be statically configured with either this zone's zone key or the
         zone key of another zone above this one in the DNS tree.
       
    
 
@@ -924,8 +922,8 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
           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
+          have the same name as the zone, have a name type of
+          ZONE, and be usable for
           authentication.
           It is recommended that zone keys use a cryptographic algorithm
           designated as "mandatory to implement" by the IETF; currently
@@ -933,7 +931,7 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
         
    
 
         
    
-          The following command will generate a 768-bit RSASHA1 key for
+          The following command generates a 768-bit RSASHA1 key for
           the child.example zone:
         
    
 
@@ -942,12 +940,12 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
         
    
 
         
    
-          Two output files will be produced:
+          Two output files are 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.),
+          the key name (child.example.), the
           algorithm (3
           is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
           this case).
@@ -959,13 +957,13 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
         
    
 
         
    
-          To generate another key with the same properties (but with
-          a different key tag), repeat the above command.
+          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
+          to get a key pair from a crypto hardware device and build the key
           files. Its usage is similar to dnssec-keygen.
         
    
 
@@ -987,20 +985,19 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
 
         
    
           Any keyset files corresponding to
-          secure subzones should be present.  The zone signer will
-          generate NSEC, NSEC3
+          secure sub-zones should be present.  The zone signer
+          generates NSEC, NSEC3,
           and RRSIG records for the zone, as
           well as DS for the child zones if
-          '-g' is specified.  If '-g'
+          -g is specified.  If -g
           is not specified, then DS RRsets for the secure child
           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.
+          By default, all zone keys which have an available private key are
+          used to generate signatures. The following command signs the zone, assuming it is in a
+          file called zone.child.example:
         
    
 
         
    
@@ -1017,8 +1014,8 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
         
    
 
         
    dnssec-signzone
-          will also produce a keyset and dsset files and optionally a
-          dlvset file.  These are used to provide the parent zone
+          also produces keyset and dsset files.
+          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.
@@ -1028,11 +1025,11 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
 
       
    
 
    
-Configuring Servers
    
+Configuring Servers for DNSSEC
    
 
         
    
           To enable named to respond appropriately
-          to DNS requests from DNSSEC aware clients,
+          to DNS requests from DNSSEC-aware clients,
           dnssec-enable must be set to yes.
           (This is the default setting.)
         
    
@@ -1041,14 +1038,14 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
           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
+          dnssec-validation option 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.
+          trust anchor for the DNS root zone is used.
           If it is set to yes, however,
           then at least one trust anchor must be configured
           with a trusted-keys or
@@ -1063,13 +1060,13 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
           for zones that are used to form the first link in the
           cryptographic chain of trust.  All keys listed in
           trusted-keys (and corresponding zones)
-          are deemed to exist and only the listed keys will be used
-          to validated the DNSKEY RRset that they are from.
+          are deemed to exist and only the listed keys are used
+          to validate the DNSKEY RRset that they are from.
         
    
 
         
    
           managed-keys are trusted keys which are
-          automatically kept up to date via RFC 5011 trust anchor
+          automatically kept up-to-date via RFC 5011 trust anchor
           maintenance.
         
    
 
@@ -1080,20 +1077,20 @@ allow-update { !{ !localnets; any; }; key host1-host2. ;};
         
    
 
         
    
-          Unlike BIND 8, BIND
+          BIND
           9 does not verify signatures on load, so zone keys for
           authoritative zones do not need to be specified in the
           configuration file.
         
    
 
         
    
-          After DNSSEC gets established, a typical DNSSEC configuration
-          will look something like the following.  It has one or
-          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
+          After DNSSEC is established, a typical DNSSEC configuration
+          looks something like the following.  It has one or
+          more public keys for the root, which allows answers from
+          outside the organization to be validated.  It also
+          has several keys for parts of the namespace that the organization
           controls.  These are here to ensure that named
-          is immune to compromises in the DNSSEC components of the security
+          is immune to compromised security in the DNSSEC components
           of parent zones.
         
    
 
@@ -1160,8 +1157,8 @@ options {
 
         
    
           When DNSSEC validation is enabled and properly configured,
-          the resolver will reject any answers from signed, secure zones
-          which fail to validate, and will return SERVFAIL to the client.
+          the resolver rejects any answers from signed, secure zones
+          which fail to validate, and returns SERVFAIL to the client.
         
    
 
         
    
@@ -1184,7 +1181,7 @@ options {
           
    
             If the validator can prove that the zone
             is insecure, then the response is accepted.  However, if it
-            cannot, then it must assume an insecure response to be a
+            cannot, the validator must assume an insecure response to be a
             forgery; it rejects the response and logs an error.
           
    
           
    
@@ -1204,15 +1201,15 @@ options {
 Converting from insecure to secure
 
   
-  
    Changing a zone from insecure to secure can be done in two
-  ways: using a dynamic DNS update, or the
+  
    A zone ca be changed from insecure to secure in two
+  ways: using a dynamic DNS update, or via the
   auto-dnssec zone option.
    
-  
    For either method, you need to configure
-  named so that it can see the
+  
    For either method,
+  named must be configured so that it can see the
   K* files which contain the public and private
-  parts of the keys that will be used to sign the zone. These files
-  will have been generated by
-  dnssec-keygen. You can do this by placing them
+  parts of the keys that are used to sign the zone. These files
+  are generated by
+  dnssec-keygen, and they should be placed
   in the key-directory, as specified in
   named.conf:
    
   
    @@ -1224,13 +1221,13 @@ options {
 	};
 
    
   
    If one KSK and one ZSK DNSKEY key have been generated, this
-  configuration will cause all records in the zone to be signed
-  with the ZSK, and the DNSKEY RRset to be signed with the KSK as
-  well. An NSEC chain will be generated as part of the initial
+  configuration causes all records in the zone to be signed
+  with the ZSK, and the DNSKEY RRset to be signed with the KSK.
+  An NSEC chain is generated as part of the initial
   signing process.
    
   
    
 
    
-Dynamic DNS update method
    
+Dynamic DNS Update Method
    
 
   
   
    To insert the keys via dynamic update:
    
@@ -1241,15 +1238,15 @@ options {
 	> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
 	> send
 
    
-  
    While the update request will complete almost immediately,
-  the zone will not be completely signed until
-  named has had time to walk the zone and
+  
    While the update request completes almost immediately,
+  the zone is not completely signed until
+  named has had time to "walk" the zone and
   generate the NSEC and RRSIG records. The NSEC record at the apex
-  will be added last, to signal that there is a complete NSEC
+  is added last, to signal that there is a complete NSEC
   chain.
    
-  
    If you wish to sign using NSEC3 instead of NSEC, you should
-  add an NSEC3PARAM record to the initial update request. If you
-  wish the NSEC3 chain to have the OPTOUT bit set, set it in the
+  
    To sign using NSEC3 instead of NSEC,
+  add an NSEC3PARAM record to the initial update request.
+  The OPTOUT bit in the NSEC3 chain can be set in the
   flags field of the NSEC3PARAM record.
    
   
     	% nsupdate
@@ -1259,17 +1256,17 @@ options {
 	> update add example.net NSEC3PARAM 1 1 100 1234567890
 	> send
 
    
-  
    Again, this update request will complete almost
-  immediately; however, the record won't show up until
+  
    Again, this update request completes almost
+  immediately; however, the record does not show up until
   named has had a chance to build/remove the
-  relevant chain. A private type record will be created to record
-  the state of the operation (see below for more details), and will
-  be removed once the operation completes.
    
+  relevant chain. A private type record is created to record
+  the state of the operation (see below for more details), and is
+  removed once the operation completes.
    
   
    While the initial signing and NSEC/NSEC3 chain generation
   is happening, other updates are possible as well.
    
   
    
 
    
-Fully automatic zone signing
    
+Fully Automatic Zone Signing
    
 
   
   
    To enable automatic signing, add the
@@ -1282,71 +1279,71 @@ options {
   auto-dnssec allow,
   named can search the key directory for keys
   matching the zone, insert them into the zone, and use them to
-  sign the zone. It will do so only when it receives an
+  sign the zone. It does so only when it receives an
   rndc sign <zonename>.
    
   
    
   
   auto-dnssec maintain includes the above
-  functionality, but will also automatically adjust the zone's
-  DNSKEY records on schedule according to the keys' timing metadata.
+  functionality, but also automatically adjusts the zone's
+  DNSKEY records on a schedule according to the keys' timing metadata.
   (See dnssec-keygen(8) and
   dnssec-settime(8) for more information.)
   
    
   
    
-  named will periodically search the key directory
-  for keys matching the zone, and if the keys' metadata indicates
-  that any change should be made the zone, such as adding, removing,
-  or revoking a key, then that action will be carried out.  By default,
+  named periodically searches the key directory
+  for keys matching the zone; if the keys' metadata indicates
+  that any change should be made to the zone - such as adding, removing,
+  or revoking a key - then that action is carried out.  By default,
   the key directory is checked for changes every 60 minutes; this period
-  can be adjusted with the dnssec-loadkeys-interval, up
+  can be adjusted with dnssec-loadkeys-interval, up
   to a maximum of 24 hours.  The rndc loadkeys forces
   named to check for key updates immediately.
   
    
   
    
   If keys are present in the key directory the first time the zone
-  is loaded, the zone will be signed immediately, without waiting for an
+  is loaded, the zone is signed immediately, without waiting for an
   rndc sign or rndc loadkeys
-  command. (Those commands can still be used when there are unscheduled
-  key changes, however.)
+  command. Those commands can still be used when there are unscheduled
+  key changes.
   
    
   
    
   When new keys are added to a zone, the TTL is set to match that
   of any existing DNSKEY RRset. If there is no existing DNSKEY RRset,
-  then the TTL will be set to the TTL specified when the key was
+  the TTL is set to the TTL specified when the key was
   created (using the dnssec-keygen -L option), if
   any, or to the SOA TTL.
   
    
   
    
-  If you wish the zone to be signed using NSEC3 instead of NSEC,
+  To sign the zone using NSEC3 instead of NSEC,
   submit an NSEC3PARAM record via dynamic update prior to the
-  scheduled publication and activation of the keys.  If you wish the
-  NSEC3 chain to have the OPTOUT bit set, set it in the flags field
-  of the NSEC3PARAM record.  The NSEC3PARAM record will not appear in
-  the zone immediately, but it will be stored for later reference.  When
+  scheduled publication and activation of the keys.
+  The OPTOUT bit for the NSEC3 chain can be set in the flags field
+  of the NSEC3PARAM record.  The NSEC3PARAM record does not appear in
+  the zone immediately, but it is stored for later reference.  When
   the zone is signed and the NSEC3 chain is completed, the NSEC3PARAM
-  record will appear in the zone.
+  record appears in the zone.
   
    
   
    Using the
   auto-dnssec option requires the zone to be
   configured to allow dynamic updates, by adding an
   allow-update or
   update-policy statement to the zone
-  configuration. If this has not been done, the configuration will
-  fail.
    
+  configuration. If this has not been done, the configuration
+  fails.
    
   
    
 
    
-Private-type records
    
+Private Type Records
    
 
   
   
    The state of the signing process is signaled by
-  private-type records (with a default type value of 65534). When
-  signing is complete, these records will have a nonzero value for
-  the final octet (for those records which have a nonzero initial
-  octet).
    
-  
    The private type record format: If the first octet is
-  non-zero then the record indicates that the zone needs to be
+  private type records (with a default type value of 65534). When
+  signing is complete, these records with a non-zero initial octet
+  have a non-zero value for the final octet.
    
+  
    If the first octet of a private type record is
+  non-zero, the record indicates either that the zone needs to be
   signed with the key matching the record, or that all signatures
-  that match the record should be removed.
    
+  that match the record should be removed. Here are the meanings
+  of the different values of the first octet:
    
   
    
     
    
 

    
@@ -1359,13 +1356,13 @@ options {
 
    
   
    
   
    Only records flagged as "complete" can be removed via
-  dynamic update. Attempts to remove other private type records
-  will be silently ignored.
    
+  dynamic update; attempts to remove other private type records
+  are silently ignored.
    
   
    If the first octet is zero (this is a reserved algorithm
-  number that should never appear in a DNSKEY record) then the
-  record indicates changes to the NSEC3 chains are in progress. The
-  rest of the record contains an NSEC3PARAM record. The flag field
-  tells what operation to perform based on the flag bits.
    
+  number that should never appear in a DNSKEY record), the
+  record indicates that changes to the NSEC3 chains are in progress. The
+  rest of the record contains an NSEC3PARAM record, while the flag field
+  tells what operation to perform based on the flag bits:
    
   
    
     
    
 

    
@@ -1379,111 +1376,109 @@ options {
   
    
   
    
 
    
-DNSKEY rollovers
    
+DNSKEY Rollovers
    
 
   
-  
    As with insecure-to-secure conversions, rolling DNSSEC
-  keys can be done in two ways: using a dynamic DNS update, or the
+  
    As with insecure-to-secure conversions, DNSSEC keyrolls
+  can be done in two ways: using a dynamic DNS update, or via the
   auto-dnssec zone option.
    
   
    
 
    
-Dynamic DNS update method
    
+Dynamic DNS Update Method
    
 
   
-  
     To perform key rollovers via dynamic update, you need to add
-  the K* files for the new keys so that
-  named can find them. You can then add the new
-  DNSKEY RRs via dynamic update.
-  named will then cause the zone to be signed
-  with the new keys. When the signing is complete the private type
-  records will be updated so that the last octet is non
-  zero.
    
-  
    If this is for a KSK you need to inform the parent and any
-  trust anchor repositories of the new KSK.
    
-  
    You should then wait for the maximum TTL in the zone before
+  
     To perform key rollovers via dynamic update,
+  the K* files for the new keys must be added so that
+  named can find them. The new
+  DNSKEY RRs can then be added via dynamic update.
+  named then causes the zone to be signed
+  with the new keys; when the signing is complete, the private type
+  records are updated so that the last octet is non-zero.
    
+  
    If this is for a KSK, the parent and any
+  trust anchor repositories of the new KSK must be informed.
    
+  
    The maximum TTL in the zone must expire before
   removing the old DNSKEY. If it is a KSK that is being updated,
-  you also need to wait for the DS RRset in the parent to be
-  updated and its TTL to expire. This ensures that all clients will
-  be able to verify at least one signature when you remove the old
-  DNSKEY.
    
-  
    The old DNSKEY can be removed via UPDATE. Take care to
+  the DS RRset in the parent must also be
+  updated its TTL allowed to expire. This ensures that all clients
+  are able to verify at least one signature when the old DNSKEY is removed.
    
+  
    The old DNSKEY can be removed via UPDATE, taking care to
   specify the correct key.
-  named will clean out any signatures generated
+  named cleans out any signatures generated
   by the old key after the update completes.
    
   
    
 
    
-Automatic key rollovers
    
+Automatic Key Rollovers
    
 
   
   
    When a new key reaches its activation date (as set by
   dnssec-keygen or dnssec-settime),
-  if the auto-dnssec zone option is set to
-  maintain, named will
-  automatically carry out the key rollover.  If the key's algorithm
-  has not previously been used to sign the zone, then the zone will
-  be fully signed as quickly as possible.  However, if the new key
-  is replacing an existing key of the same algorithm, then the
-  zone will be re-signed incrementally, with signatures from the
-  old key being replaced with signatures from the new key as their
+  and if the auto-dnssec zone option is set to
+  maintain, named
+  automatically carries out the key rollover.  If the key's algorithm
+  has not previously been used to sign the zone, then the zone is
+  fully signed as quickly as possible.  However, if the new key
+  replaces an existing key of the same algorithm, the
+  zone is re-signed incrementally, with signatures from the
+  old key replaced with signatures from the new key as their
   signature validity periods expire.  By default, this rollover
-  completes in 30 days, after which it will be safe to remove the
+  completes in 30 days, after which it is safe to remove the
   old key from the DNSKEY RRset.
    
   
    
 
    
-NSEC3PARAM rollovers via UPDATE
    
+NSEC3PARAM Rollovers via UPDATE
    
 
   
-  
    Add the new NSEC3PARAM record via dynamic update. When the
+  
    The new NSEC3PARAM record can be added via dynamic update. When the
   new NSEC3 chain has been generated, the NSEC3PARAM flag field
-  will be zero. At this point you can remove the old NSEC3PARAM
-  record. The old chain will be removed after the update request
+  is set to zero. At that point, the old NSEC3PARAM
+  record can be removed. The old chain is removed after the update request
   completes.
    
   
    
 
    
-Converting from NSEC to NSEC3
    
+Converting From NSEC to NSEC3
    
 
   
-  
    To do this, you just need to add an NSEC3PARAM record. When
-  the conversion is complete, the NSEC chain will have been removed
-  and the NSEC3PARAM record will have a zero flag field. The NSEC3
-  chain will be generated before the NSEC chain is
+  
    To do this, an NSEC3PARAM record must be added. When
+  the conversion is complete, the NSEC chain is removed
+  and the NSEC3PARAM record has a zero flag field. The NSEC3
+  chain is generated before the NSEC chain is
   destroyed.
    
   
    
 
    
-Converting from NSEC3 to NSEC
    
+Converting From NSEC3 to NSEC
    
 
   
   
    To do this, use nsupdate to
   remove all NSEC3PARAM records with a zero flag
-  field. The NSEC chain will be generated before the NSEC3 chain is
+  field. The NSEC chain is generated before the NSEC3 chain is
   removed.
    
   
    
 
    
-Converting from secure to insecure
    
+Converting From Secure to Insecure
    
 
   
   
    To convert a signed zone to unsigned using dynamic DNS,
   delete all the DNSKEY records from the zone apex using
   nsupdate. All signatures, NSEC or NSEC3 chains,
-  and associated NSEC3PARAM records will be removed automatically.
-  This will take place after the update request completes.
    
+  and associated NSEC3PARAM records are removed automatically.
+  This takes place after the update request completes.
    
   
     This requires the
   dnssec-secure-to-insecure option to be set to
   yes in
   named.conf.
    
   
    In addition, if the auto-dnssec maintain
   zone statement is used, it should be removed or changed to
-  allow instead (or it will re-sign).
+  allow instead; otherwise, it will re-sign).
   
    
   
    
 
    
-Periodic re-signing
    
+Periodic Re-signing
    
 
   
   
    In any secure zone which supports dynamic updates, named
-  will periodically re-sign RRsets which have not been re-signed as
-  a result of some update action. The signature lifetimes will be
-  adjusted so as to spread the re-sign load over time rather than
+  periodically re-signs RRsets which have not been re-signed as
+  a result of some update action. The signature lifetimes are
+  adjusted to spread the re-sign load over time rather than
   all at once.
    
   
    
 
    
@@ -1497,8 +1492,8 @@ options {
   named supports UPDATES to zones where the NSEC3
   records in the chain have mixed OPTOUT state.
   named does not support changing the OPTOUT
-  state of an individual NSEC3 record, the entire chain needs to be
-  changed if the OPTOUT state of an individual NSEC3 needs to be
+  state of an individual NSEC3 record; if the OPTOUT state of an individual NSEC3 needs to be
+  changed, the entire chain must be
   changed.
    
 
    
 
@@ -1536,53 +1531,52 @@ options {
     KSK. All KSKs which do not sign the zone are "stand-by"
     keys.
    
     
    Any validating resolver which is configured to use the
-    active KSK as an RFC 5011-managed trust anchor will take note
-    of the stand-by KSKs in the zone's DNSKEY RRset, and store them
-    for future reference. The resolver will recheck the zone
-    periodically, and after 30 days, if the new key is still there,
-    then the key will be accepted by the resolver as a valid trust
-    anchor for the zone. Any time after this 30-day acceptance
+    active KSK as an RFC 5011-managed trust anchor takes note
+    of the stand-by KSKs in the zone's DNSKEY RRset, and stores them
+    for future reference. The resolver rechecks the zone
+    periodically; after 30 days, if the new key is still there,
+    the key is accepted by the resolver as a valid trust
+    anchor for the zone. Anytime after this 30-day acceptance
     timer has completed, the active KSK can be revoked, and the
     zone can be "rolled over" to the newly accepted key.
    
     
    The easiest way to place a stand-by key in a zone is to
     use the "smart signing" features of
     dnssec-keygen and
-    dnssec-signzone. If a key with a publication
+    dnssec-signzone. If a key exists with a publication
     date in the past, but an activation date which is unset or in
-    the future, "
-    dnssec-signzone -S" will include the DNSKEY
-    record in the zone, but will not sign with it:
    
+    the future, dnssec-signzone -S includes the DNSKEY
+    record in the zone but does not sign with it:
    
     
     $ dnssec-keygen -K keys -f KSK -P now -A now+2y example.net
 $ dnssec-signzone -S -K keys example.net
 
    
-    
    To revoke a key, the new command
-    dnssec-revoke has been added. This adds the
-    REVOKED bit to the key flags and re-generates the
+    
    To revoke a key, use the command
+    dnssec-revoke. This adds the
+    REVOKED bit to the key flags and regenerates the
     K*.key and
     K*.private files.
    
     
    After revoking the active key, the zone must be signed
-    with both the revoked KSK and the new active KSK. (Smart
-    signing takes care of this automatically.)
    
+    with both the revoked KSK and the new active KSK. Smart
+    signing takes care of this automatically.
    
     
    Once a key has been revoked and used to sign the DNSKEY
-    RRset in which it appears, that key will never again be
+    RRset in which it appears, that key is never again
     accepted as a valid trust anchor by the resolver. However,
-    validation can proceed using the new active key (which had been
-    accepted by the resolver when it was a stand-by key).
    
+    validation can proceed using the new active key, which was
+    accepted by the resolver when it was a stand-by key.
    
     
    See RFC 5011 for more details on key rollover
     scenarios.
    
     
    When a key has been revoked, its key ID changes,
-    increasing by 128, and wrapping around at 65535. So, for
+    increasing by 128 and wrapping around at 65535. So, for
     example, the key "Kexample.com.+005+10000" becomes
     "Kexample.com.+005+10128".
    
-    
    If two keys have IDs exactly 128 apart, and one is
-    revoked, then the two key IDs will collide, causing several
+    
    If two keys have IDs exactly 128 apart and one is
+    revoked, the two key IDs will collide, causing several
     problems. To prevent this,
-    dnssec-keygen will not generate a new key if
-    another key is present which may collide. This checking will
-    only occur if the new keys are written to the same directory
-    which holds all other keys in use for that zone.
    
-    
    Older versions of BIND 9 did not have this precaution.
+    dnssec-keygen does not generate a new key if
+    another key which may collide is present. This checking
+    only occurs if the new keys are written to the same directory
+    that holds all other keys in use for that zone.
    
+    
    Older versions of BIND 9 did not have this protection.
     Exercise caution if using key revocation on keys that were
     generated by previous releases, or if using keys stored in
     multiple directories or on multiple machines.
    
@@ -1594,10 +1588,10 @@ $ dnssec-signzone -S -K keys example.net<
 
     
    
 
    
-PKCS#11 (Cryptoki) support
    
+PKCS#11 (Cryptoki) Support
    
 
   
    
-    PKCS#11 (Public Key Cryptography Standard #11) defines a
+    Public Key Cryptography Standard #11 (PKCS#11) defines a
     platform-independent API for the control of hardware security
     modules (HSMs) and other cryptographic support devices.
   
    
@@ -2254,17 +2248,17 @@ $ dnssec-signzone -E '' -S example.netDLZ (Dynamically Loadable Zones)
    
 
   
    
-    DLZ (Dynamically Loadable Zones) is an extension to BIND 9 that allows
+    Dynamically Loadable Zones (DLZ) are an extension to BIND 9 that allows
     zone data to be retrieved directly from an external database.  There is
     no required format or schema.  DLZ drivers exist for several different
-    database backends including PostgreSQL, MySQL, and LDAP and can be
+    database backends, including PostgreSQL, MySQL, and LDAP, and can be
     written for any other.
   
    
   
    
     Historically, DLZ drivers had to be statically linked with the named
     binary and were turned on via a configure option at compile time (for
-    example, "configure --with-dlz-ldap").
-    Currently, the drivers provided in the BIND 9 tarball in
+    example, configure --with-dlz-ldap).
+    The drivers provided in the BIND 9 tarball in
     contrib/dlz/drivers are still linked this
     way.
   
    
@@ -2273,21 +2267,21 @@ $ dnssec-signzone -E '' -S example.netnamed by default, so configure options
-    are no longer necessary when using these dynamically linkable drivers,
-    but are still needed for the older drivers in
+    are no longer necessary when using these dynamically linkable drivers;
+    they are still needed for the older drivers in
     contrib/dlz/drivers.
   
    
 
   
    
-    When the DLZ module provides data to named, it does so in text format.
-    The response is converted to DNS wire format by named.  This
+    The DLZ module provides data to named in text format,
+    which is then converted to DNS wire format by named.  This
     conversion, and the lack of any internal caching, places significant
     limits on the query performance of DLZ modules.  Consequently, DLZ is
     not recommended for use on high-volume servers.  However, it can be
-    used in a hidden master configuration, with slaves retrieving zone
-    updates via AXFR.  (Note, however, that DLZ has no built-in support for
-    DNS notify; slaves are not automatically informed of changes to the
-    zones in the database.)
+    used in a hidden primary configuration, with secondaries retrieving zone
+    updates via AXFR.  Note, however, that DLZ has no built-in support for
+    DNS notify; secondary servers are not automatically informed of changes to the
+    zones in the database.
   
    
 
   
    
@@ -2310,9 +2304,9 @@ $ dnssec-signzone -E '' -S example.netdlz statements can be specified; when
       answering a query, all DLZ modules with search
-      set to yes will be queried to find out if
-      they contain an answer for the query name; the best available
-      answer will be returned to the client.
+      set to yes are queried to see whether
+      they contain an answer for the query name. The best available
+      answer is returned to the client.
     
    
     
    
       The search option in the above example can be
@@ -2322,11 +2316,11 @@ $ dnssec-signzone -E '' -S example.netsearch is set to no, then
       this DLZ module is not searched for the best
       match when a query is received.  Instead, zones in this DLZ must be
-      separately specified in a zone statement.  This allows you to
-      configure a zone normally using standard zone option semantics,
-      but specify a different database back-end for storage of the
+      separately specified in a zone statement.  This allows users to
+      configure a zone normally using standard zone-option semantics,
+      but specify a different database backend for storage of the
       zone's data.  For example, to implement NXDOMAIN redirection using
-      a DLZ module for back-end storage of redirection rules:
+      a DLZ module for backend storage of redirection rules:
     
    
     
         dlz other {
@@ -2345,9 +2339,9 @@ $ dnssec-signzone -E '' -S example.netSample DLZ Driver
    
 
     
    
-      For guidance in implementation of DLZ modules, the directory
+      For guidance in the implementation of DLZ modules, the directory
       contrib/dlz/example contains a basic
-      dynamically-linkable DLZ module--i.e., one which can be
+      dynamically linkable DLZ module - i.e., one which can be
       loaded at runtime by the "dlopen" DLZ driver.
       The example sets up a single zone, whose name is passed
       to the module as an argument in the dlz
@@ -2360,7 +2354,7 @@ $ dnssec-signzone -E '' -S example.net
     
    
       In the above example, the module is configured to create a zone
-      "example.nil", which can answer queries and AXFR requests, and
+      "example.nil", which can answer queries and AXFR requests and
       accept DDNS updates.  At runtime, prior to any updates, the zone
       contains an SOA, NS, and a single A record at the apex:
     
    
@@ -2372,13 +2366,13 @@ $ dnssec-signzone -E '' -S example.net
     
    
-      The sample driver is capable of retrieving information about the
-      querying client, and altering its response on the basis of this
+      The sample driver can retrieve information about the
+      querying client and alter its response on the basis of this
       information.  To demonstrate this feature, the example driver
       responds to queries for "source-addr.zonename>/TXT"
       with the source address of the query.  Note, however, that this
-      record will *not* be included in AXFR or ANY responses.  Normally,
-      this feature would be used to alter responses in some other fashion,
+      record will not be included in AXFR or ANY responses.  Normally,
+      this feature is used to alter responses in some other fashion,
       e.g., by providing different address records for a particular name
       depending on the network from which the query arrived.
     
    
@@ -2386,7 +2380,7 @@ $ dnssec-signzone -E '' -S example.netcontrib/dlz/example/README.  This directory also
       contains the header file dlz_minimal.h, which
-      defines the API and should be included by any dynamically-linkable
+      defines the API and should be included by any dynamically linkable
       DLZ module.
     
    
   
@@ -2394,10 +2388,10 @@ $ dnssec-signzone -E '' -S example.net
 
    
-DynDB (Dynamic Database)
    
+Dynamic Database (DynDB)
 
   
    
-    DynDB is an extension to BIND 9 which, like DLZ
+    Dynamic Database, or DynDB, is an extension to BIND 9 which, like DLZ
     (see the section called “DLZ (Dynamically Loadable Zones)”), allows zone data to be
     retrieved from an external database.  Unlike DLZ, a DynDB module
     provides a full-featured BIND zone database interface.  Where
@@ -2411,7 +2405,7 @@ $ dnssec-signzone -E '' -S example.net
     A DynDB module supporting LDAP has been created by Red Hat
     and is available from
-    https://fedorahosted.org/bind-dyndb-ldap/.
+    https://pagure.io/bind-dyndb-ldap.
   
    
   
    
     A sample DynDB module for testing and developer guidance
@@ -2439,13 +2433,13 @@ $ dnssec-signzone -E '' -S example.net
     
    
       The parameters are passed as an opaque
       string to the DynDB module's initialization routine. Configuration
-      syntax will differ depending on the driver.
+      syntax differs depending on the driver.
     
    
   
   
    
@@ -2453,8 +2447,8 @@ $ dnssec-signzone -E '' -S example.netSample DynDB Module
    
 
     
    
-      For guidance in implementation of DynDB modules, the directory
-      bin/tests/system/dyndb/driver.
+      For guidance in the implementation of DynDB modules, the directory
+      bin/tests/system/dyndb/driver
       contains a basic DynDB module.
       The example sets up two zones, whose names are passed
       to the module as arguments in the dyndb
@@ -2464,7 +2458,7 @@ $ dnssec-signzone -E '' -S example.net
     
    
-      In the above example, the module is configured to create a zone
+      In the above example, the module is configured to create a zone,
       "example.nil", which can answer queries and AXFR requests, and
       accept DDNS updates.  At runtime, prior to any updates, the zone
       contains an SOA, NS, and a single A record at the apex:
@@ -2477,11 +2471,11 @@ $ dnssec-signzone -E '' -S example.net
     
    
-      When the zone is updated dynamically, the DynDB module will determine
-      whether the updated RR is an address (i.e., type A or AAAA) and if
-      so, it will automatically update the corresponding PTR record in a
-      reverse zone.  (Updates are not stored permanently; all updates are
-      lost when the server is restarted.)
+      When the zone is updated dynamically, the DynDB module determines
+      whether the updated RR is an address (i.e., type A or AAAA); if
+      so, it automatically updates the corresponding PTR record in a
+      reverse zone.  Note that updates are not stored permanently; all updates are
+      lost when the server is restarted.
     
    
   
 
@@ -2493,49 +2487,49 @@ $ dnssec-signzone -E '' -S example.net
     A "catalog zone" is a special DNS zone that contains a list of
     other zones to be served, along with their configuration parameters.
-    Zones listed in a catalog zone are called "member zones".
-    When a catalog zone is loaded or transferred to a slave server
-    which supports this functionality, the slave server will create
+    Zones listed in a catalog zone are called "member zones."
+    When a catalog zone is loaded or transferred to a secondary server
+    which supports this functionality, the secondary server creates
     the member zones automatically. When the catalog zone is updated
     (for example, to add or delete member zones, or change
-    their configuration parameters) those changes are immediately put
+    their configuration parameters), those changes are immediately put
     into effect. Because the catalog zone is a normal DNS zone, these
     configuration changes can be propagated using the standard AXFR/IXFR
     zone transfer mechanism.
   
    
   
    
-    Catalog zones' format and behavior are specified as an internet draft
-    for interoperability among DNS implementations.  As of this release, the
+    Catalog zones' format and behavior are specified as an Internet draft
+    for interoperability among DNS implementations.  The
     latest revision of the DNS catalog zones draft can be found here:
-    https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/
+    https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/.
   
    
 
   
    
 
    
 Principle of Operation
    
     
    
-      Normally, if a zone is to be served by a slave server, the
+      Normally, if a zone is to be served by a secondary server, the
       named.conf file on the server must list the
       zone, or the zone must be added using rndc addzone.
-      In environments with a large number of slave servers and/or where
+      In environments with a large number of secondary servers, and/or where
       the zones being served are changing frequently, the overhead involved
-      in maintaining consistent zone configuration on all the slave
+      in maintaining consistent zone configuration on all the secondary
       servers can be significant.
     
    
     
    
-      A catalog zone is a way to ease this administrative burden.  It is a
-      DNS zone that lists member zones that should be served by slave servers.
-      When a slave server receives an update to the catalog zone, it adds,
+      A catalog zone is a way to ease this administrative burden: it is a
+      DNS zone that lists member zones that should be served by secondary servers.
+      When a secondary server receives an update to the catalog zone, it adds,
       removes, or reconfigures member zones based on the data received.
     
    
     
    
-      To use a catalog zone, it must first be set up as a normal zone on
-      the master and the on slave servers that will be configured to use
+      To use a catalog zone, it must first be set up as a normal zone on both
+      the primary and secondary servers that are configured to use
       it.  It must also be added to a catalog-zones list
       in the options or view statement
-      in named.conf.  (This is comparable to the way
+      in named.conf.  This is comparable to the way
       a policy zone is configured as a normal zone and also listed in
-      a response-policy statement.)
+      a response-policy statement.
     
    
     
    
       To use the catalog zone feature to serve a new member zone:
@@ -2543,38 +2537,38 @@ $ dnssec-signzone -E '' -S example.net
      
 
    • 
           
      
-	    Set up the the member zone to be served on the master as normal.
-	    This could be done by editing named.conf,
+	    Set up the the member zone to be served on the primary as normal.
+	    This can be done by editing named.conf
 	    or by running rndc addzone.
           
      
         
      • 
 
    • 
           
      
             Add an entry to the catalog zone for the new member zone.
-	    This could be done by editing the catalog zone's master file
+	    This can be done by editing the catalog zone's zone file
 	    and running rndc reload, or by updating
 	    the zone using nsupdate.
           
      
         
      • 
 
    
 
    
-      The change to the catalog zone will be propagated from the master to all
-      slaves using the normal AXFR/IXFR mechanism.  When the slave receives the
-      update to the catalog zone, it will detect the entry for the new member
-      zone, create an instance of of that zone on the slave server, and point
+      The change to the catalog zone is propagated from the primary to all
+      secondaries using the normal AXFR/IXFR mechanism.  When the secondary receives the
+      update to the catalog zone, it detects the entry for the new member
+      zone, creates an instance of that zone on the secondary server, and points
       that instance to the masters specified in the catalog
-      zone data. The newly created member zone is a normal slave zone, so
-      BIND will immediately initiate a transfer of zone contents from the
-      master.  Once complete, the slave will start serving the member zone.
+      zone data. The newly created member zone is a normal secondary zone, so
+      BIND immediately initiates a transfer of zone contents from the
+      primary.  Once complete, the secondary starts serving the member zone.
     
    
     
    
-      Removing a member zone from a slave server requires nothing more than
-      deleting the member zone's entry in the catalog zone. The change to the
-      catalog zone is propagated to the slave server using the normal AXFR/IXFR
-      transfer mechanism.  The slave server, on processing the update, will
-      notice that the member zone has been removed.  It will stop serving the
-      zone and remove it from its list of configured zones.  (Removing the
-      member zone from the master server has to be done in the normal way,
+      Removing a member zone from a secondary server requires only
+      deleting the member zone's entry in the catalog zone; the change to the
+      catalog zone is propagated to the secondary server using the normal AXFR/IXFR
+      transfer mechanism.  The secondary server, on processing the update,
+      notices that the member zone has been removed, stops serving the
+      zone, and removes it from its list of configured zones. However, removing the
+      member zone from the primary server must be done
       by editing the configuration file or running
       rndc delzone.)
     
    
@@ -2601,31 +2595,31 @@ catalog-zones {
       This statement specifies that the zone
       catalog.example is a catalog zone. This zone must be
       properly configured in the same view. In most configurations, it would
-      be a slave zone.
+      be a secondary zone.
     
    
     
    
       The options following the zone name are not required, and may be
       specified in any order:
     
    
     
    
-      The default-masters option defines the default masters
-      for member zones listed in a catalog zone. This can be overridden by
+      The default-masters option defines the default primaries
+      for member zones listed in a catalog zone, and can be overridden by
       options within a catalog zone. If no such options are included, then
-      member zones will transfer their contents from the servers listed in
+      member zones transfer their contents from the servers listed in
       this option.
     
    
     
    
       The in-memory option, if set to yes,
       causes member zones to be stored only in memory. This is functionally
-      equivalent to configuring a slave zone without a file.
+      equivalent to configuring a secondary zone without a file
       option.  The default is no; member zones' content
-      will be stored locally in a file whose name is automatically generated
+      is stored locally in a file whose name is automatically generated
       from the view name, catalog zone name, and member zone name.
     
    
     
    
       The zone-directory option causes local copies of
-      member zones' master files (if in-memory is not set
-      to yes) to be stored in the specified directory.
+      member zones' zone files to be stored in the specified directory,
+      if in-memory is not set to yes.
       The default is to store zone files in the server's working directory.
       A non-absolute pathname in zone-directory is
       assumed to be relative to the working directory.
@@ -2635,23 +2629,23 @@ catalog-zones {
       interval between processing of updates to catalog zones, in seconds.
       If an update to a catalog zone (for example, via IXFR) happens less
       than min-update-interval seconds after the most
-      recent update, then the changes will not be carried out until this
+      recent update, the changes are not carried out until this
       interval has elapsed.  The default is 5 seconds.
     
    
     
    
       Catalog zones are defined on a per-view basis. Configuring a non-empty
-      catalog-zones statement in a view will automatically
-      turn on allow-new-zones for that view. (Note: this
-      means rndc addzone and rndc delzone
-      will also work in any view that supports catalog zones.)
+      catalog-zones statement in a view automatically
+      turns on allow-new-zones for that view. This
+      means that rndc addzone and rndc delzone
+      also work in any view that supports catalog zones.
     
    
   
 
   
    
 
    
-Catalog Zone format
    
+Catalog Zone Format
    
     
    
-      A catalog zone is a regular DNS zone; therefore, it has to have a
+      A catalog zone is a regular DNS zone; therefore, it must have a
       single SOA and at least one NS
       record.
     
    
@@ -2667,14 +2661,14 @@ version.catalog.example.    IN TXT "1"

    Note that this record must have the domain name - version.catalog-zone-name. This illustrates - how the meaning of data stored in a catalog zone is indicated by the + "version.catalog-zone-name". + The data stored in a catalog zone is indicated by the the domain name label immediately before the catalog zone domain.

    Catalog zone options can be set either globally for the whole catalog zone or for a single member zone. Global options override the settings - in the configuration file and member zone options override global + in the configuration file, and member zone options override global options.

    @@ -2691,8 +2685,8 @@ version.catalog.example. IN TXT "1" masters.catalog.example. IN A 192.0.2.1

    - This option defines a master server for the member zones - it - can be either an A or AAAA record. If multiple masters are set the + This option defines a primary server for the member zones, which + can be either an A or AAAA record. If multiple primaries are set, the order in which they are used is random.

    @@ -2703,7 +2697,7 @@ version.catalog.example. IN TXT "1" label.masters.catalog.example. IN TXT "tsig_key_name"

    - This option defines a master server for the member zone with a TSIG + This option defines a primary server for the member zone with a TSIG key set. The TSIG key must be configured in the configuration file. label can be any valid DNS label.

    @@ -2719,9 +2713,9 @@ version.catalog.example. IN TXT "1" These options are the equivalents of allow-query and allow-transfer in a zone declaration in the named.conf configuration file. The ACL is - processed in order - if there's no match to any rule the default - policy is to deny access. For the syntax of the APL RR see RFC - 3123 + processed in order; if there is no match to any rule, the default + policy is to deny access. For the syntax of the APL RR, see RFC + 3123.

    @@ -2748,17 +2742,17 @@ label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN APL 1:10.0.0.0/24

    - As would be expected, options defined for a specific zone override + Options defined for a specific zone override the global options defined in the catalog zone. These in turn override the global options defined in the catalog-zones statement in the configuration file.

    - (Note that none of the global records an option will be inherited if + Note that none of the global records for an option are inherited if any records are defined for that option for the specific zone. For example, if the zone had a masters record of type - A but not AAAA, then it would not inherit the - type AAAA record from the global option.) + A but not AAAA, it would not inherit the + type AAAA record from the global option.

    @@ -2768,9 +2762,9 @@ allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A IPv6 Support in BIND 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. + defined forms of IPv6 name-to-address and address-to-name + lookups. It also uses IPv6 addresses to make queries when + running on an IPv6-capable system.

    @@ -2794,8 +2788,8 @@ allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 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. + the binary label format at all anymore, and return an + error if one is given. In particular, an authoritative BIND 9 name server will not load a zone file containing binary labels.

    @@ -2812,7 +2806,7 @@ allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A

    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, + IPv6 address in a single record. For example: 

    @@ -2829,7 +2823,7 @@ host            3600    IN      AAAA    2001:db8::1
       
       
    
 
    
-Address to Name Lookups Using Nibble Format
    
+Address-to-Name Lookups Using Nibble Format
    
 
         
    
           When looking up an address in nibble format, the address
@@ -2838,7 +2832,7 @@ host            3600    IN      AAAA    2001:db8::1
           resulting name.
           For example, the following would provide reverse name lookup for
           a host with address
-          2001:db8::1.
+          2001:db8::1:
         
    
 
 
    @@ -2867,6 +2861,6 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
 
 
 
-
    BIND 9.11.21 (Extended Support Version)
    
+
    BIND 9.11.22 (Extended Support Version)
    
 
 
diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html
index f807200fcf..030566f821 100644
--- a/doc/arm/Bv9ARM.ch05.html
+++ b/doc/arm/Bv9ARM.ch05.html
@@ -46,12 +46,12 @@
 The Lightweight Resolver Library
 
       
    
-        Traditionally applications have been linked with a stub resolver
+        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,
+        At first, IPv6 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
@@ -62,7 +62,7 @@
         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"
+        a simple UDP-based protocol, the "lightweight resolver protocol,"
         that is distinct from and simpler than the full DNS protocol.
       
    
     
@@ -79,7 +79,7 @@
       
    
 
       
    
-        By default, applications using the lightweight resolver library will
+        By default, applications using the lightweight resolver library
         make
         UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
         The
@@ -88,12 +88,6 @@
         /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 lwresd daemon is essentially a
         caching-only name server that responds to requests using the
@@ -101,7 +95,7 @@
         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
+        Unless otherwise instructed, 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
@@ -110,7 +104,7 @@
       
    
         The lwresd daemon may also be
         configured with a
-        named.conf style configuration file,
+        named.conf-style configuration file,
         in
         /etc/lwresd.conf by default.  A name
         server may also
@@ -119,7 +113,7 @@
       
    
       
    
         The number of client queries that the lwresd
-        daemon is able to serve can be set using the
+        daemon serves can be set using the
         lwres-tasks and lwres-clients
         statements in the configuration.
       
    
@@ -142,6 +136,6 @@
 
 
 
-
    BIND 9.11.21 (Extended Support Version)
    
+
    BIND 9.11.22 (Extended Support Version)
    
 
 
diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html
index cdd1a4fcc5..ac56f0c148 100644
--- a/doc/arm/Bv9ARM.ch06.html
+++ b/doc/arm/Bv9ARM.ch06.html
@@ -88,10 +88,10 @@
 
    Setting TTLs
    
 
    Inverse Mapping in IPv4
    
 
    Other Zone File Directives
    
-
    BIND Master File Extension: the  $GENERATE Directive
    
+
    BIND Primary File Extension: the  $GENERATE Directive
    
 
    Additional File Formats
    -
    BIND9 Statistics
    +
    BIND 9 Statistics
    The Statistics File
    Statistics Counters
    @@ -99,23 +99,6 @@
    -

    - BIND 9 configuration is broadly similar - to BIND 8; however, there are a few new - areas - of configuration, such as views. BIND - 8 configuration files should work with few alterations in BIND - 9, although more complex configurations should be reviewed to check - if they can be more efficiently implemented using the new features - found in BIND 9. -

    - -

    - BIND 4 configuration files can be - converted to the new format - using the shell script - contrib/named-bootconf/named-bootconf.sh. -

    Configuration File Elements

    @@ -155,7 +138,7 @@ A list of one or more ip_addr, ip_prefix, key_id, - or acl_name elements, see + or acl_name elements; see the section called “Address Match Lists”.

    @@ -172,7 +155,7 @@ with optional key_id and/or ip_port. A masters_list may include other - masters_lists. + masters_lists.

    @@ -184,8 +167,8 @@

    - A quoted string which will be used as - a DNS name, for example "my.test.domain". + A quoted string which is used as + a DNS name; for example, my.test.domain.

    @@ -211,8 +194,7 @@

    One to four integers valued 0 through - 255 separated by dots (`.'), such as 123, - 45.67 or 89.123.45.67. + 255 separated by dots ("."), such as 123.45.67 or 89.123.45.67.

    @@ -238,22 +220,22 @@

    An IPv6 address, such as 2001:db8::1234. - IPv6 scoped addresses that have ambiguity on their + IPv6-scoped addresses that have ambiguity on their scope zones must be disambiguated by an appropriate - zone ID with the percent character (`%') as + zone ID with the percent character ("%") as a delimiter. It is strongly recommended to use string zone names rather than numeric identifiers, - in order to be robust against system configuration + to be robust against system configuration changes. However, since there is no standard mapping for such names and identifier values, - currently only interface names as link identifiers + only interface names as link identifiers are supported, assuming one-to-one mapping between interfaces and links. For example, a link-local address fe80::1 on the link attached to the interface ne0 can be specified as fe80::1%ne0. Note that on most systems link-local addresses - always have the ambiguity, and need to be + always have ambiguity and need to be disambiguated.

    @@ -298,7 +280,7 @@ 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 + In some cases, an asterisk ("*") character can be used as a placeholder to select a random high-numbered port.

    @@ -313,19 +295,19 @@

    An IP network specified as an ip_addr, - followed by a slash (`/') and then the number of bits in the + followed by a slash ("/") and then the number of bits in the netmask. - Trailing zeros in a ip_addr - may omitted. + Trailing zeros in an ip_addr + may be 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. + When specifying a prefix involving a IPv6-scoped address, + the scope may be omitted. In that case, the prefix + matches packets from any scope.

    @@ -381,11 +363,11 @@

    A non-negative real number that can be specified to - the nearest one hundredth. Up to five digits can be + the nearest one-hundredth. Up to five digits can be specified before a decimal point, and up to two digits after, so the maximum value is 99999.99. Acceptable values might be further limited by the - context in which it is used. + contexts in which they are used.

    @@ -397,7 +379,7 @@

    - A quoted string which will be used as + A quoted string which is used as a pathname, such as zones/master/my.test.domain.

    @@ -424,7 +406,7 @@ For example, range 1024 65535 represents ports from 1024 through 65535. - In either case an asterisk (`*') character is not + In either case an asterisk ("*") character is not allowed as a valid ip_port.

    @@ -449,7 +431,7 @@ 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. + "as big as possible," depending on the context. See the explanations of particular parameters that use size_spec for details on how they interpret its use. @@ -467,7 +449,7 @@

    unlimited generally means - "as big as possible", and is usually the best + "as big as possible," and is usually the best way to safely set a very large number.

    @@ -484,15 +466,15 @@

    - size_spec or integer value - followed by '%' to represent percents. + A size_spec or integer value + followed by "%" to represent percent.

    The behavior is exactly the same as size_spec, but - size_or_percent allows also - to specify a positive integer value followed by - '%' sign to represent percents. + size_or_percent also allows + specifying a positive integer value followed by the + "%"" sign to represent percent.

    @@ -521,11 +503,11 @@

    One of yes, no, notify, - notify-passive, refresh or + notify-passive, refresh, or passive. When used in a zone, notify-passive, refresh, and passive - are restricted to slave and stub zones. + are restricted to secondary and stub zones.

    @@ -538,7 +520,7 @@

    -Syntax

    +Syntax
    address_match_list = address_match_list_element ; ...
 
@@ -549,7 +531,7 @@
         
         
    
 
    
-Definition and Usage
    
+Definition and Usage
    
 
           
    
             Address match lists are primarily used to determine access
@@ -563,7 +545,7 @@
               an IP address (IPv4 or IPv6)
             
 
  • 
-              an IP prefix (in `/' notation)
+              an IP prefix (in "/" notation)
             
    • 
 
  • 
               
@@ -582,10 +564,11 @@
 
 
           
    
-            Elements can be negated with a leading exclamation mark (`!'),
+            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.
+            can be found in the description of the acl
+            statement.
           
    
 
           
    
@@ -626,7 +609,7 @@
             allow-update-forwarding,
             blackhole, and
             keep-response-order all use address match
-            lists.  Similarly, the listen-on option will cause the
+            lists.  Similarly, the listen-on option causes the
             server to refuse queries on any of the machine's
             addresses which do not match the list.
           
    
@@ -634,7 +617,7 @@
           
    
             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
+            preference is 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
@@ -642,10 +625,10 @@
             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
+            algorithm matches 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.
+            that problem by blocking 1.2.3.13 via the negation, but
+            all other 1.2.3.* hosts pass through.
           
    
         
       
@@ -655,7 +638,7 @@
 Comment Syntax
 
         
    
-          The BIND 9 comment syntax allows for
+          The BIND 9 comment syntax allows
           comments to appear
           anywhere that whitespace may appear in a BIND configuration
           file. To appeal to programmers of all kinds, they can be written
@@ -664,7 +647,7 @@
 
         
    
 
    
-Syntax
    
+Syntax
    
 
           
    
             
    
@@ -674,14 +657,14 @@
 
    // This is a BIND comment as in C++
    
 
    
             
    
-
    # This is a BIND comment as in common UNIX shells
+
    # This is a BIND comment as in common Unix shells
 # and perl
    
 
    
           
    
         
         
    
 
    
-Definition and Usage
    
+Definition and Usage
    
 
           
    
             Comments may appear anywhere that whitespace may appear in
@@ -727,7 +710,7 @@
 
           
    
           
    
-            Shell-style (or perl-style, if you prefer) comments start
+            Shell-style (or perl-style) comments start
             with the character # (number sign)
             and continue to the end of the
             physical line, as in C++ comments.
@@ -748,8 +731,8 @@
           
    
 
    Warning
    
             
    
-              You cannot use the semicolon (`;') character
-              to start a comment such as you would in a zone file. The
+              The semicolon (";") character
+              cannot start a comment, unlike in a zone file. The
               semicolon indicates the end of a configuration
               statement.
             
    
@@ -765,7 +748,7 @@
       
    
         A BIND 9 configuration consists of
         statements and comments.
-        Statements end with a semicolon. Statements and comments are the
+        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.
@@ -788,7 +771,7 @@
               
 
                 
    
-                  defines a named IP address
+                  Defines a named IP address
                   matching list, for access control and other uses.
                 
    
               
@@ -799,7 +782,7 @@
               
 
                 
    
-                  declares control channels to be used
+                  Declares control channels to be used
                   by the rndc utility.
                 
    
               
@@ -810,7 +793,7 @@
               
 
                 
    
-                  includes a file.
+                  Includes a file.
                 
    
               
 
@@ -820,7 +803,7 @@
               
 
                 
    
-                  specifies key information for use in
+                  Specifies key information for use in
                   authentication and authorization using TSIG.
                 
    
               
@@ -831,7 +814,7 @@
               
 
                 
    
-                  specifies what the server logs, and where
+                  Specifies what information the server logs and where
                   the log messages are sent.
                 
    
               
@@ -842,8 +825,8 @@
               
 
                 
    
-                  configures named to
-                  also act as a light-weight resolver daemon (lwresd).
+                  Configures named to
+                  also act as a lightweight resolver daemon (lwresd).
                 
    
               
 
@@ -853,8 +836,8 @@
               
 
                 
    
-                  defines a named masters list for
-                  inclusion in stub and slave zones'
+                  Defines a named list of primary servers for
+                  inclusion in stub and secondary zones'
                   masters or
                   also-notify lists.
                 
    
@@ -866,7 +849,7 @@
               
 
                 
    
-                  controls global server configuration
+                  Controls global server configuration
                   options and sets defaults for other statements.
                 
    
               
@@ -877,7 +860,7 @@
               
 
                 
    
-                  sets certain configuration options on
+                  Sets certain configuration options on
                   a per-server basis.
                 
    
               
@@ -888,7 +871,7 @@
               
 
                 
    
-                  declares communication channels to get access to
+                  Declares communication channels to get access to
                   named statistics.
                 
    
               
@@ -899,7 +882,7 @@
               
 
                 
    
-                  defines trusted DNSSEC keys.
+                  Defines trusted DNSSEC keys.
                 
    
               
 
@@ -909,7 +892,7 @@
               
 
                 
    
-                  lists DNSSEC keys to be kept up to date
+                  Lists DNSSEC keys to be kept up-to-date
                   using RFC 5011 trust anchor maintenance.
                 
    
               
@@ -920,7 +903,7 @@
               
 
                 
    
-                  defines a view.
+                  Defines a view.
                 
    
               
 
@@ -930,7 +913,7 @@
               
 
                 
    
-                  defines a zone.
+                  Defines a zone.
                 
    
               
 
@@ -959,8 +942,8 @@
 
         
    
           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).
+          name to an address match list. It gets its name from one of the primary
+          uses of address match lists: Access Control Lists (ACLs).
         
    
 
         
    
@@ -1020,8 +1003,8 @@
                     ACL element is updated to reflect the changes.
                     Some systems do not provide a way to determine the prefix
                     lengths of
-                    local IPv6 addresses.
-                    In such a case, localnets
+                    local IPv6 addresses;
+                    in such cases, localnets
                     only matches the local
                     IPv6 addresses, just like localhost.
                   
    
@@ -1056,7 +1039,7 @@
 
         
    
           The controls statement declares control
-          channels to be used by system administrators to control the
+          channels to be used by system administrators to manage 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.
@@ -1067,11 +1050,11 @@
           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
+          interpreted as the IPv4 wildcard address; connections are
           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,
+          If rndc is only used on the local host,
           using the loopback address (127.0.0.1
           or ::1) is recommended for maximum security.
         
    
@@ -1087,17 +1070,17 @@
           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
+          IP address-based filtering only; any key_id
           elements of the address_match_list
           are ignored.
         
    
 
         
    
-          A unix control channel is a UNIX domain
+          A unix control channel is a Unix domain
           socket listening at the specified path in the file system.
           Access to the socket is specified by the perm,
-          owner and group clauses.
-          Note on some platforms (SunOS and Solaris) the permissions
+          owner, and group clauses.
+          Note on some platforms (SunOS and Solaris), the permissions
           (perm) are applied to the parent directory
           as the permissions on the socket itself are ignored.
         
    
@@ -1125,52 +1108,30 @@
 
         
    
           If no controls statement is present,
-          named will set up a default
+          named sets 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
+          named attempts 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
+          was specified when BIND was built).
+          To create an 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
+          The key name and the size of the secret cannot be easily changed; if it
+          is desirable to change those things, make a
+          rndc.conf with a custom key.  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
+          For greater flexibility in allowing other users to access
+          rndc commands, create
           a
-          rndc.conf file and make it group
-          readable by a group
+          rndc.conf file and make it group-readable by a group
           that contains the users who should have access.
         
    
 
@@ -1240,7 +1201,7 @@
 
         
    
           The key_id, also known as the
-          key name, is a domain name uniquely identifying the key. It can
+          key name, is a domain name that uniquely identifies 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
@@ -1253,14 +1214,13 @@
           that specifies a security/authentication algorithm.  The
           named server supports hmac-md5,
           hmac-sha1, hmac-sha224,
-          hmac-sha256, hmac-sha384
+          hmac-sha256, hmac-sha384,
           and hmac-sha512 TSIG authentication.
           Truncated hashes are supported by appending the minimum
-          number of required bits preceded by a dash, e.g.
+          number of required bits preceded by a dash, e.g.,
           hmac-sha1-80.  The
           secret_string is the secret
-          to be used by the algorithm, and is treated as a Base64
-          encoded string.
+          to be used by the algorithm, and is treated as a Base64-encoded string.
         
    
 
       
    
@@ -1294,15 +1254,15 @@
           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
+          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:
+          as many channels and categories as desired. If there is no logging statement,
+          the logging configuration is:
         
    
 
 
    logging {
@@ -1315,7 +1275,7 @@
           If named is started with the
           -L option, it logs to the specified file
           at startup, instead of using syslog. In this case the logging
-          configuration will be:
+          configuration is:
         
    
 
 
    logging {
@@ -1325,12 +1285,9 @@
 
    
 
         
    
-          In BIND 9, the logging configuration
+          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
+          the entire configuration file has been parsed. When the server starts up, all logging messages
           regarding syntax errors in the configuration file go to the default
           channels, or to standard error if the -g option
           was specified.
@@ -1342,19 +1299,19 @@
 
           
    
             All log output goes to one or more channels;
-            you can make as many of them as you want.
+            there is no limit to the number of channels that can be created.
           
    
 
           
    
             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
+            says whether messages selected for the channel go to a file, go to a
+            particular syslog facility, go to the standard error stream, or are
+            discarded. The definition can optionally also limit the message severity level
+            that is 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).
+            category name,
+            and/or the severity level (the default is not to include any).
           
    
 
           
    
@@ -1367,25 +1324,25 @@
             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
+            both on how large the file is allowed to become, and on how many
             versions
-            of the file will be saved each time the file is opened.
+            of the file are saved each time the file is opened.
           
    
 
           
    
-            If you use the versions log file
-            option, then
-            named will retain that many backup
+            If the versions log file
+            option is used, then
+            named retains that many backup
             versions of the file by
-            renaming them when opening.  For example, if you choose to keep
+            renaming them when opening.  For example, to keep
             three old versions
-            of the file lamers.log, then just
+            of the file lamers.log, 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
+            The versions unlimited option can be set to
             not limit
             the number of versions.
             If a size option is associated with
@@ -1399,13 +1356,13 @@
           
    
             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
+            growth. If the file ever exceeds the size, then named
+            stops writing to the file unless it also 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
+            versions option, no more data is
+            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
@@ -1414,7 +1371,7 @@
           
    
 
           
    
-            Example usage of the size and
+            Here is an example using the size and
             versions options:
           
    
 
@@ -1436,35 +1393,35 @@
             uucp, cron, authpriv,
             ftp, local0, local1,
             local2, local3, local4,
-            local5, local6 and
-            local7, however not all facilities
+            local5, local6, and
+            local7; however, not all facilities
             are supported on
             all operating systems.
-            How syslog will handle messages
+            How syslog handles 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
+            page. On a system which uses a very old version of syslog, which
             only uses two arguments to the openlog() function,
             then this clause is silently ignored.
           
    
           
    
-            On Windows machines syslog messages are directed to the EventViewer.
+            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
+            "priorities," except that they can also be used when 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
+            Messages which are not at least of the severity level given are
+            not selected for the channel; messages of higher severity
             levels
-            will be accepted.
+            are 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
+            When using syslog, the syslog.conf priorities
+            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,
+            causes messages of severity info and
             notice to
             be dropped. If the situation were reversed, with named writing
             messages of only warning or higher,
@@ -1477,23 +1434,22 @@
             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.
+            use when the server is running as a foreground process, as
+            when debugging a configuration, for example.
           
    
 
           
    
             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
+            than zero, debugging mode is active. The global debug
             level is set either by starting the named server
             with the -d 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
+                notrace. All debugging messages in the server have a debug
+            level; higher debug levels give more detailed output. Channels
             that specify a specific debug severity, for example:
           
    
 
@@ -1504,25 +1460,25 @@ notrace    . All debugging messages in the server have a debug
 
    
 
           
    
-            will get debugging output of level 3 or less any time the
+            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
+            If print-time is set to
+            yes, then the date and time are logged.
+            print-time may be specified for a
+            syslog channel, but is usually
+            unnecessary since syslog also logs
+            the date and time. If print-category is
+            set to yes, then the
+            category of the message is logged as well. Finally, if
+            print-severity is set, then the severity
+            level of the message is logged.
+            The print- options may
+            be used in any combination, and are always printed in the
             following
             order: time, category, severity. Here is an example where all
             three print- options
@@ -1534,17 +1490,17 @@ notrace. All debugging messages in the server have a debug
           
    
 
           
    
-            If buffered has been turned on the output
-            to files will not be flushed after each log entry.  By default
+            If buffered has been turned on, the output
+            to files is not flushed after each log entry.  By default
             all log messages are flushed.
           
    
 
           
    
             There are four predefined channels that are used for
-            named's default logging as follows.
+            named's default logging, as follows.
             If named is started with the
-            -L then a
-            fifth channel default_logfile is added.
+            -L, then a
+            fifth channel, default_logfile, is added.
             How they are
             used is described in the section called “The category Phrase”.
           
    
@@ -1592,27 +1548,26 @@ channel default_logfile {
             special
             property that it only produces output when the server's debug
             level is
-            nonzero.  It normally writes to a file called named.run
+            non-zero.  It normally writes to a file called named.run
             in the server's working directory.
           
    
 
           
    
             For security reasons, when the -u
-            command line option is used, the named.run file
+            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 -L
+            starting - and still running as root - is discarded.
+            To capture this output, run the server with the -L
             option to specify a default logfile, or the -g
-            option to log to standard error which you can redirect to a file.
+            option to log to standard error which can be redirected 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.
+            Once a channel is defined, it cannot be redefined.
+            The built-in channels cannot be altered directly, but
+            the default logging can be modified by pointing categories at defined channels.
           
    
         
 
@@ -1621,12 +1576,12 @@ channel default_logfile {
 The category 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
+            There are many categories, so desired logs
+            can be sent anywhere while unwanted logs are ignored. If
+            a list of channels is not specified for a category, log
             messages
-            in that category will be sent to the default category
-            instead. If you don't specify a default category, the following
+            in that category are sent to the default category
+            instead. If no default category is specified, the following
             "default default" is used:
           
    
 
@@ -1634,16 +1589,16 @@ channel default_logfile {
 
    
 
           
    
-            If you start named with the
-            -L option then the default category is:
+            If named is started with the
+            -L option, the default category is:
           
    
 
 
    category default { default_logfile; default_debug; };
 
    
 
           
    
-            As an example, let's say you want to log security events to
-            a file, but you also want keep the default logging behavior. You'd
+            As an example, let's say a user wants to log security events to
+            a file, but also wants to keep the default logging behavior. They would
             specify the following:
           
    
 
@@ -1666,7 +1621,7 @@ category notify { null; };

    • - Following are the available categories and brief descriptions + The 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.

    @@ -1693,8 +1648,8 @@ category notify { null; };

    - Logs nameservers that are skipped due to them being - a CNAME rather than A / AAAA records. + Name servers that are skipped for being + a CNAME rather than A/AAAA records.

    @@ -1726,7 +1681,7 @@ category notify { null; };

    - The default category defines the logging + Logging options for those categories where no specific configuration has been defined. @@ -1739,11 +1694,11 @@ category notify { null; };

    - Delegation only. Logs queries that have been + Queries that have been forced to NXDOMAIN as the result of a delegation-only zone or a delegation-only in a - forward, hint or stub zone declaration. + forward, hint, or stub zone declaration.

    @@ -1786,7 +1741,7 @@ category notify { null; };

    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 + 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 @@ -1803,11 +1758,11 @@ category notify { null; };

    Note: eventually named will have to stop - treating such timeouts as due to RFC 1034 non - compliance and start treating it as plain + 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 + loss as due to RFC 1034 non-compliance impacts + DNSSEC validation, which requires EDNS for the DNSSEC records to be returned.

    @@ -1818,8 +1773,8 @@ category notify { null; };

    - The catch-all. Many things still aren't - classified into categories, and they all end up here. + Catch-all for many things that still are not + classified into categories.

    @@ -1829,8 +1784,8 @@ category notify { null; };

    - Lame servers. These are misconfigurations - in remote servers, discovered by BIND 9 when trying to + Misconfigurations + in remote servers, discovered by BIND 9 when trying to query those servers during resolution.

    @@ -1861,11 +1816,11 @@ category notify { null; };

    - Specify where queries should be logged to. + Location where queries should be logged.

    - At startup, specifying the category queries will also - enable query logging unless querylog option has been + At startup, specifying the category queries also + enables query logging unless querylog option has been specified.

    @@ -1874,16 +1829,16 @@ category notify { null; }; identifier in @0x<hexadecimal-number> format. Next, it reports the client's IP address and port number, and the query name, - class and type. Next, it reports whether the + 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 used along with the EDNS version - number (E(#)), if TCP was used (T), if DO - (DNSSEC Ok) was set (D), if CD (Checking - Disabled) was set (C), if a valid DNS Server - COOKIE was received (V), or if a DNS COOKIE + if not set), whether the query was signed (S), + whether EDNS was in use along with the EDNS version + number (E(#)), whether TCP was used (T), whether DO + (DNSSEC Ok) was set (D), whether CD (Checking + Disabled) was set (C), whether a valid DNS Server + COOKIE was received (V), and whether a DNS COOKIE option without a valid Server COOKIE was - present (K). After this the destination + present (K). After this, the destination address the query was sent to is reported.

    @@ -1894,10 +1849,10 @@ category notify { null; }; client ::1#62537 (www.example.net): query: www.example.net IN AAAA -SE

    - (The first part of this log message, showing the + 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.) + to the same query.

    @@ -1924,12 +1879,12 @@ category notify { null; }; 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 name for the final notice. The final notice is normally delayed until about one - minute after rate limit stops. + minute after rate limiting 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 + which is indicated by an initial asterisk (*). + Various internal events are logged at debug level 1 and higher.

    @@ -1957,7 +1912,7 @@ category notify { null; };

    Information about errors in response policy zone files, - rewritten responses, and at the highest + rewritten responses, and, at the highest debug levels, mere rewriting attempts.

    @@ -1979,7 +1934,7 @@ category notify { null; };

    - Logs queries that have been terminated, either by dropping + Queries that have been terminated, either by dropping or responding with SERVFAIL, as a result of a fetchlimit quota being exceeded.

    @@ -1991,7 +1946,7 @@ category notify { null; };

    - Logs trust-anchor-telemetry requests received by named. + Trust-anchor-telemetry requests received by named.

    @@ -2002,9 +1957,9 @@ category notify { null; };

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

    @@ -2062,7 +2017,7 @@ category notify { null; }; used to indicate why and how specific queries resulted in responses which indicate an error. Normally, these messages will be logged at debug logging levels; - note, however, that if query logging is active, some will be + note, however, that if query logging is active, some are logged at info. The logging levels are described below:

    @@ -2070,7 +2025,7 @@ category notify { null; };

    At debug level 1 or higher - or at info, when query logging is active - each - response with response code SERVFAIL will be logged as follows: + response with response code SERVFAIL is logged as follows:

    client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880 @@ -2078,13 +2033,13 @@ category notify { null; };

    This means an error resulting in SERVFAIL was detected at line 3880 of source file query.c. Log messages - of this level will particularly help identify the cause of + of this level are particularly helpful in identifying the cause of SERVFAIL for an authoritative server.

    At debug level 2 or higher, detailed context information about recursive resolutions that resulted in - SERVFAIL will be logged. The log message will look like this: + SERVFAIL is logged. The log message looks like this:

    @@ -2100,12 +2055,12 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    The first part before the colon shows that a recursive resolution for AAAA records of www.example.com completed - in 10.000183 seconds and the final result that led to the + in 10.000183 seconds, and the final result that led to the SERVFAIL was determined at line 2970 of source file resolver.c.

    - The following part shows the detected final result and the + The next part shows the detected final result and the latest result of DNSSEC validation. The latter is always "success" when no validation attempt was made. In this example, this query probably resulted in SERVFAIL because all name @@ -2136,7 +2091,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    The number of referrals the resolver received throughout the resolution process. - In the above example this is 2, which are most + In the above example there are two, which are most likely com and example.com.

    @@ -2150,7 +2105,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] The number of cycles that the resolver tried remote servers at the domain zone. - In each cycle the resolver sends one query + In each cycle, the resolver sends one query (possibly resending it, depending on the response) to each known name server of the domain zone. @@ -2189,7 +2144,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] at the domain zone. A server is detected to be lame either by an invalid response or as a result of lookup in - BIND9's address database (ADB), where lame + BIND 9's address database (ADB), where lame servers are cached.

    @@ -2215,9 +2170,9 @@ badresp:1,adberr:0,findfail:0,valfail:0] The number of erroneous results that the resolver encountered in sending queries at the domain zone. - One common case is the remote server is - unreachable and the resolver receives an ICMP - unreachable error message. + One common case is when the remote server is + unreachable and the resolver receives an "ICMP + unreachable" error message.

    @@ -2252,7 +2207,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    - Failures of resolving remote server addresses. + Failures to resolve remote server addresses. This is a total number of failures throughout the resolution process.

    @@ -2277,16 +2232,16 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    At debug level 3 or higher, the same - messages as those at debug level 1 will be - logged for other errors than SERVFAIL. Note that negative + messages as those at debug level 1 are + logged for errors other than SERVFAIL. Note that negative responses such as NXDOMAIN are not errors, and are not logged at this debug level.

    At debug level 4 or higher, the detailed context information logged at debug - level 2 will be logged for other errors than SERVFAIL and - for negative resonses such as NXDOMAIN. + level 2 is logged for errors other than SERVFAIL and + for negative responses such as NXDOMAIN.

    @@ -2334,7 +2289,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] 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 + If this statement is omitted, requests are accepted on 127.0.0.1, port 921.

    @@ -2344,11 +2299,11 @@ badresp:1,adberr:0,findfail:0,valfail:0] 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 + response is 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. + used; if there is no default view, an error is triggered.

    @@ -2367,25 +2322,25 @@ badresp:1,adberr:0,findfail:0,valfail:0] /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. + exact-match lookup before search path elements are appended.

    The lwres-tasks statement specifies the number - of worker threads the lightweight resolver will dedicate to serving - clients. By default the number is the same as the number of CPUs on + of worker threads the lightweight resolver dedicates to serving + clients. By default, the number is the same as the number of CPUs on the system; this can be overridden using the -n - command line option when starting the server. + command-line option when starting the server.

    - The lwres-clients specifies + The lwres-clients statement specifies the number of client objects per thread the lightweight resolver should create to serve client queries. By default, if the lightweight resolver runs as a part of named, 256 client objects are created for each task; if it runs as lwresd, 1024 client objects are created for each thread. The maximum - value is 32768; higher values will be silently ignored and - the maximum will be used instead. + value is 32768; higher values are silently ignored and + the maximum is used instead. Note that setting too high a value may overconsume system resources.

    @@ -2412,8 +2367,8 @@ badresp:1,adberr:0,findfail:0,valfail:0] Usage

    masters - lists allow for a common set of masters to be easily used by - multiple stub and slave zones in their masters + lists allow for a common set of primaries to be easily used by + multiple stub and secondary zones in their masters or also-notify lists.

    @@ -2715,21 +2670,21 @@ badresp:1,adberr:0,findfail:0,valfail:0] 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. + statement, an options block with each option set to its default is + used.

    attach-cache

    - Allows multiple views to share a single cache + This option allows multiple views to share a single cache database. Each view has its own cache database by default, but if multiple views have the same operational policy for name resolution and caching, those views can - share a single cache to save memory and possibly - improve resolution efficiency by using this option. + share a single cache to save memory, and possibly + improve resolution efficiency, by using this option.

    @@ -2746,25 +2701,25 @@ badresp:1,adberr:0,findfail:0,valfail:0] views which are supposed to share a cache, it creates a cache with the specified name for the first view of these sharing views. - The rest of the views will simply refer to the - already created cache. + The rest of the views simply refer to the + already-created cache.

    - One common configuration to share a cache would be to + One common configuration to share a cache is to allow all views to share a single cache. This can be done by specifying - the attach-cache as a global + attach-cache as a global option with an arbitrary name.

    Another possible operation is to allow a subset of - all views to share a cache while the others to + all views to share a cache while the others retain their own caches. For example, if there are three views A, B, and C, and only A and B should share a cache, specify the - attach-cache option as a view A (or + attach-cache option as a view of A (or B)'s option, referring to the other view name:

    @@ -2807,7 +2762,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] forwarders that can return different answers for the same question, sharing the answer does not make sense or could even be harmful. - It is administrator's responsibility to ensure + It is administrator's responsibility to ensure that configuration differences in different views do not cause disruption with a shared cache.

    @@ -2815,13 +2770,13 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    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 + This sets the working directory of the server. + Any non-absolute pathnames in the configuration file are + taken as relative to this directory. The default location for most server output files - (e.g. named.run) is this directory. + (e.g., named.run) is this directory. If a directory is not specified, the working directory - defaults to `.', the directory from + defaults to ".", the directory from which the server was started. The directory specified should be an absolute path. It is strongly recommended @@ -2849,7 +2804,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    To enable dnstap at compile time, the fstrm and protobuf-c - libraries must be available, and BIND must be configured with + libraries must be available, and BIND must be configured with --enable-dnstap.

    @@ -2858,7 +2813,7 @@ badresp:1,adberr:0,findfail:0,valfail:0] for each view. Supported types are client, auth, resolver, and forwarder. Specifying type - all will cause all dnstap + all causes all dnstap messages to be logged, regardless of type.

    @@ -2923,7 +2878,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

  • fstrm-set-output-queue-model: - Controls the queuing semantics to use for queue + The queuing semantics to use for queue objects. The default is mpsc (multiple producer, single consumer); the other option is spsc (single producer, @@ -2969,17 +2924,17 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    dnstap-output

    - Configures the path to which the dnstap - frame stream will be sent if dnstap + This configures the path to which the dnstap + frame stream is sent if dnstap is enabled at compile time and active.

    The first argument is either file or unix, indicating whether the destination - is a file or a UNIX domain socket. The second argument + is a file or a Unix domain socket. The second argument is the path of the file or socket. (Note: when using a - socket, dnstap messages will - only be sent if another process such as + socket, dnstap messages are + only sent if another process such as fstrm_capture (provided with libfstrm) is listening on the socket.) @@ -2996,20 +2951,20 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    dnstap-identity

    - Specifies an identity string to send in + This specifies an identity string to send in dnstap messages. If set to hostname, which is the default, the - server's hostname will be sent. If set to - none, no identity string will be sent. + server's hostname is sent. If set to + none, no identity string is sent.

    dnstap-version

    - Specifies a version string to send in + This specifies a version string to send in dnstap messages. The default is the - version number of the BIND release. If set to - none, no version string will be sent. + version number of the BIND release. If set to + none, no version string is sent.

    geoip-directory
    @@ -3020,9 +2975,9 @@ badresp:1,adberr:0,findfail:0,valfail:0] this specifies the directory containing GeoIP database files. By default, the option is set based on the prefix used to build the libmaxminddb - module: for example, if the library is installed in + module; for example, if the library is installed in /usr/local/lib, then the default - geoip-directory will be + geoip-directory is /usr/local/share/GeoIP. On Windows, the default is the named working directory. See the section called “acl Statement Definition and @@ -3033,13 +2988,13 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    key-directory

    - When performing dynamic update of secure zones, the + This is the directory where the public and private DNSSEC key files - should be found, if different than the current working + should be found when performing a dynamic update of secure zones, 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 + rndc.key, or session.key.)

    @@ -3056,7 +3011,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    Because the database file is memory mapped, its size is - limited by the address space of the named process. The + limited by the address space of the named process. The default of 32 megabytes was chosen to be usable with 32-bit named builds. The largest permitted value is 1 terabyte. Given typical zone @@ -3068,7 +3023,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    managed-keys-directory

    - Specifies the directory in which to store the files that + This specifies the directory in which to store the files that track managed DNSSEC keys. By default, this is the working directory. The directory must be writable by the effective user ID of the @@ -3076,30 +3031,28 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    If named is not configured to use views, - then managed keys for the server will be tracked in a single + managed keys for the server are 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 view name + Otherwise, managed keys are tracked in separate files, + one file per view; each file name is the view name (or, if it contains characters that are incompatible with use as a file name, the SHA256 hash of the view name), followed by the extension .mkeys.

    - (Note: in previous releases, file names for views + (Note: in earlier releases, file names for views always used the SHA256 hash of the view name. To ensure - compatibility after upgrade, if a file using the old - name format is found to exist, it will be used instead + compatibility after upgrading, if a file using the old + name format is found to exist, it is used instead of the new format.)

    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 + This option is obsolete. + In BIND 9, no separate named-xfer program is needed; its functionality is built into the name server.

    @@ -3107,53 +3060,53 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    tkey-gssapi-keytab

    - The KRB5 keytab file to use for GSS-TSIG updates. If + This is 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 + set, updates are allowed with any key matching a principal in the specified keytab.

    tkey-gssapi-credential

    - The security credential with which the server should + This is the security credential with which the server should authenticate keys requested by the GSS-TSIG protocol. - Currently only Kerberos 5 authentication is available - and the credential is a Kerberos principal which the + Currently only Kerberos 5 authentication is available; + the credential is a Kerberos principal which the server can acquire through the default system key file, normally /etc/krb5.keytab. - The location keytab file can be overridden using the - tkey-gssapi-keytab option. Normally this principal is + The location of the keytab file can be overridden using the + tkey-gssapi-keytab option. Normally this principal is of the form "DNS/server.domain". To use GSS-TSIG, tkey-domain must also be set if a specific keytab is not set with - tkey-gssapi-keytab. + tkey-gssapi-keytab.

    tkey-domain

    - The domain appended to the names of all shared keys + This domain is appended to the names of all shared keys generated with TKEY. When a client requests a TKEY exchange, it may or may not specify the desired name for the - key. If present, the name of the shared key will - be client specified part + + key. If present, the name of the shared key is + client-specified part + tkey-domain. Otherwise, the - name of the shared key will be random hex + name of the shared key is random hex digits + tkey-domain. In most cases, the domainname should be the server's domain name, or an otherwise - non-existent subdomain like - "_tkey.domainname". If you are + nonexistent subdomain like + "_tkey.domainname". If using GSS-TSIG, this variable must be defined, unless - you specify a specific keytab using tkey-gssapi-keytab. + a specific keytab is specified using tkey-gssapi-keytab.

    tkey-dhkey

    - The Diffie-Hellman key used by the server + This is 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 @@ -3172,8 +3125,8 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    dump-file

    - The pathname of the file the server dumps - the database to when instructed to do so with + This is 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.

    @@ -3181,7 +3134,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    memstatistics-file

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

    @@ -3189,10 +3142,10 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    lock-file

    - The pathname of a file on which named will - attempt to acquire a file lock when starting up for - the first time; if unsuccessful, the server will - will terminate, under the assumption that another + This is the pathname of a file on which named + attempts to acquire a file lock when starting for + the first time; if unsuccessful, the server + terminates, under the assumption that another server is already running. If not specified, the default is none.

    @@ -3204,20 +3157,20 @@ badresp:1,adberr:0,findfail:0,valfail:0] lock-file are ignored if named is being reloaded or reconfigured; it is only effective when the server is - first started up. + first started.

    pid-file

    - The pathname of the file the server writes its process ID + This is 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 PID file is used by programs that 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 + use of a PID file; no file is written and any + existing one is removed. Note that none is a keyword, not a filename, and therefore is not enclosed in double quotes. @@ -3226,8 +3179,8 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    recursing-file

    - The pathname of the file the server dumps - the queries that are currently recursing when instructed + This is the pathname of the file where 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.

    @@ -3235,8 +3188,8 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    statistics-file

    - The pathname of the file the server appends statistics - to when instructed to do so using rndc stats. + This is 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 @@ -3246,7 +3199,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    bindkeys-file

    - The pathname of a file to override the built-in trusted + This is the pathname of a file to override the built-in trusted keys provided by named. See the discussion of dnssec-validation for details. If not specified, the default is @@ -3256,8 +3209,8 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    secroots-file

    - The pathname of the file the server dumps - security roots to when instructed to do so with + This is 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. @@ -3266,7 +3219,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    session-keyfile

    - The pathname of the file into which to write a TSIG + This is 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. @@ -3280,27 +3233,27 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    session-keyname

    - The key name to use for the TSIG session key. - If not specified, the default is "local-ddns". + This is 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. + This is 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 + 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. + This is the UDP/TCP port number the server uses to + receive and send 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 + a server using a port other than 53 is not able to communicate with the global DNS.

    @@ -3308,8 +3261,8 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    dscp

    - The global Differentiated Services Code Point (DSCP) - value to classify outgoing DNS traffic on operating + This is the global Differentiated Services Code Point (DSCP) + value to classify outgoing DNS traffic, on operating systems that support DSCP. Valid values are 0 through 63. It is not configured by default.

    @@ -3317,15 +3270,15 @@ badresp:1,adberr:0,findfail:0,valfail:0]
    random-device

    - The source of entropy to be used by the server. Entropy is + This specifies a 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 + zones. This option specifies the device (or file) from which to read - entropy. If this is a file, operations requiring entropy will + entropy. If it is a file, operations requiring entropy will fail when the - file has been exhausted. If not specified, the default value + file has been exhausted. If random-device is not specified, the default value is /dev/random (or equivalent) when present, and none otherwise. The @@ -3338,7 +3291,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    preferred-glue

    - If specified, the listed type (A or AAAA) will be emitted + If specified, the listed type (A or AAAA) is emitted before other glue in the additional section of a query response. The default is to prefer A records when responding @@ -3351,41 +3304,41 @@ badresp:1,adberr:0,findfail:0,valfail:0]

    - Turn on enforcement of delegation-only in TLDs - (top level domains) and root zones with an optional + This turns 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 + delegation-only zones. Such queries and responses are treated as an exception to delegation-only processing - and are not converted to NXDOMAIN responses provided + and are not converted to NXDOMAIN responses, provided a CNAME is not discovered at the query name.

    - If a delegation only zone server also serves a child - zone it is not always possible to determine whether - an answer comes from the delegation only zone or the - child zone. SOA NS and DNSKEY records are apex - only records and a matching response that contains + If a delegation-only zone server also serves a child + zone, it is not always possible to determine whether + an answer comes from the delegation-only zone or the + child zone. SOA NS and DNSKEY records are apex-only + records and a matching response that contains these records or DS is treated as coming from a child zone. RRSIG records are also examined to see - if they are signed by a child zone or not. The - authority section is also examined to see if there + if they are signed by a child zone, and the + authority section is examined to see if there is evidence that the answer is from the child zone. Answers that are determined to be from a child zone are not converted to NXDOMAIN responses. Despite - all these checks there is still a possibility of + all these checks, there is still a possibility of false negatives when a child zone is being served.

    - Similarly false positives can arise from empty nodes - (no records at the name) in the delegation only zone - when the query type is not ANY. + Similarly, false positives can arise from empty nodes + (no records at the name) in the delegation-only zone + when the query type is not ANY.

    - Note some TLDs are not delegation only (e.g. "DE", "LV", - "US" and "MUSEUM"). This list is not exhaustive. + Note that some TLDs are not delegation-only; e.g., "DE", "LV", + "US", and "MUSEUM". This list is not exhaustive. 

    @@ -3398,38 +3351,38 @@ options {
 
    disable-algorithms
    
 
    
               
    
-                Disable the specified DNSSEC algorithms at and below the
+                This disables 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.
+                Only the best-match disable-algorithms
+                clause is used to determine the algorithms.
               
    
               
    
                 If all supported algorithms are disabled, the zones covered
-                by the disable-algorithms will be treated
+                by the disable-algorithms setting are treated
                 as insecure.
               
    
               
    
                 Configured trust anchors in trusted-keys
                 or managed-keys that match a disabled
-                algorithm will be ignored and treated as if they were not
-                configured at all.
+                algorithm are ignored and treated as if they were not
+                configured.
               
    
             
    
 
    disable-ds-digests
    
 
    
               
    
-                Disable the specified DS/DLV digest types at and below the
+                This disables the specified DS 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.
+                Only the best-match disable-ds-digests
+                clause is used to determine the digest types.
               
    
               
    
                 If all supported digest types are disabled, the zones covered
-                by the disable-ds-digests will be treated
+                by disable-ds-digests are treated
                 as insecure.
               
    
             
    
@@ -3442,33 +3395,33 @@ options {
                 below a domain specified by the deepest
                 dnssec-lookaside, and the normal DNSSEC
                 validation has left the key untrusted, the trust-anchor
-                will be appended to the key name and a DLV record will be
+                is appended to the key name and a DLV record is
                 looked up to see if it can validate the key.  If the DLV
                 record validates a DNSKEY (similarly to the way a DS
-                record does) the DNSKEY RRset is deemed to be trusted.
+                record does), the DNSKEY RRset is deemed to be trusted.
               
    
               
    
                 If dnssec-lookaside is set to
-                no, then dnssec-lookaside
+                no, then dnssec-lookaside
                 is not used.
               
    
               
    
-                NOTE: The ISC-provided DLV service at
-                dlv.isc.org, has been shut down.
+                Note: the ISC-provided DLV service at
+                dlv.isc.org has been shut down.
                 The dnssec-lookaside auto;
                 configuration option, which set named
-                up to use ISC DLV with minimal configuration, has
+                to use ISC DLV with minimal configuration, has
                 accordingly been removed.
    dnssec-must-be-secure

    - Specify hierarchies which must be or may not be secure + This specifies hierarchies which must be or may not be secure (signed and validated). If yes, - then named will only accept answers if + then named only accepts answers if they are secure. If no, then normal - DNSSEC validation applies allowing for insecure answers to + DNSSEC validation applies, allowing insecure answers to be accepted. The specified domain must be under a trusted-keys or managed-keys statement, or @@ -3487,19 +3440,19 @@ options {

    Compatible IPv6 prefixes have lengths of 32, 40, 48, 56, - 64 and 96 as per RFC 6052. Bits 64..71 inclusive must - be zero with the most significate bit of the prefix in + 64, and 96, per RFC 6052. Bits 64..71 inclusive must + be zero, with the most significant bit of the prefix in position 0.

    - Additionally a reverse IP6.ARPA zone will be created for + In addition, a reverse IP6.ARPA zone is created for the prefix to provide a mapping from the IP6.ARPA names to the corresponding IN-ADDR.ARPA names using synthesized CNAMEs. dns64-server and dns64-contact can be used to specify the name of the server and contact for the zones. These - are settable at the view / options level. These are - not settable on a per-prefix basis. + can be set at the view/options level but not + on a per-prefix basis.

    Each dns64 supports an optional @@ -3511,17 +3464,17 @@ options { Each dns64 supports an optional mapped ACL that selects which IPv4 addresses are to be mapped in the corresponding - A RRset. If not defined it defaults to + A RRset. If not defined, it defaults to any;.

    - Normally, DNS64 won't apply to a domain name that - owns one or more AAAA records; these records will - simply be returned. The optional + Normally, DNS64 does not apply to a domain name that + owns one or more AAAA records; these records are + simply returned. The optional exclude ACL allows specification - of a list of IPv6 addresses that will be ignored - if they appear in a domain name's AAAA records, and - DNS64 will be applied to any A records the domain + of a list of IPv6 addresses that are ignored + if they appear in a domain name's AAAA records; + DNS64 is applied to any A records the domain name owns. If not defined, exclude defaults to ::ffff:0.0.0.0/96.

    @@ -3535,18 +3488,18 @@ options {

    If recursive-only is set to - yes the DNS64 synthesis will - only happen for recursive queries. The default + yes, the DNS64 synthesis + only happens for recursive queries. The default is no.

    If break-dnssec is set to - yes the DNS64 synthesis will - happen even if the result, if validated, would + yes, the DNS64 synthesis + happens even if the result, if validated, would cause a DNSSEC validation failure. If this option is set to no (the default), the DO is set on the incoming query, and there are RRSIGs on - the applicable records, then synthesis will not happen. + the applicable records, then synthesis does not happen. 

             acl rfc1918 { 10/8; 192.168/16; 172.16/12; };
@@ -3563,7 +3516,7 @@ options {
 
    
                 
    
                   When a zone is configured with auto-dnssec
-                  maintain; its key repository must be checked
+                  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 dnssec-keygen(8) and
@@ -3586,20 +3539,20 @@ options {
                   the section called “Dynamic Update Policies”), 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
+                  named automatically signs all new
+                  or changed records and maintains 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
+                  then named signs 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
+                  rejects 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
@@ -3610,33 +3563,33 @@ options {
 
    nta-lifetime
    
 
    
                 
    
-                  Species the default lifetime, in seconds,
-                  that will be used for negative trust anchors added
+                  This specifies the default lifetime, in seconds,
+                  for negative trust anchors added
                   via rndc nta.
                 
    
                 
    
                   A negative trust anchor selectively disables
                   DNSSEC validation for zones that are known to be
-                  failing because of misconfiguration rather than
+                  failing because of misconfiguration, rather than
                   an attack.  When data to be validated is
                   at or below an active NTA (and above any other
-                  configured trust anchors), named will
-                  abort the DNSSEC validation process and treat the data as
+                  configured trust anchors), named
+                  aborts the DNSSEC validation process and treats the data as
                   insecure rather than bogus.  This continues until the
                   NTA's lifetime is elapsed. NTAs persist
                   across named restarts.
                 
    
                 
    
-                  For convenience, TTL-style time unit suffixes can be
-                  used to specify the NTA lifetime in seconds, minutes
+                  For convenience, TTL-style time-unit suffixes can be
+                  used to specify the NTA lifetime in seconds, minutes,
                   or hours.  nta-lifetime defaults to
-                  one hour.  It cannot exceed one week.
+                  one hour; it cannot exceed one week.
                 
    
             
    
 
    nta-recheck
    
 
    
                 
    
-                  Species how often to check whether negative
+                  This specifies how often to check whether negative
                   trust anchors added via rndc nta
                   are still necessary.
                 
    
@@ -3646,7 +3599,7 @@ options {
                   it temporarily disables DNSSEC validation for that
                   domain. In the interest of ensuring that DNSSEC
                   validation is turned back on as soon as possible,
-                  named will periodically send a
+                  named periodically sends a
                   query to the domain, ignoring negative trust anchors,
                   to find out whether it can now be validated.  If so,
                   the negative trust anchor is allowed to expire early.
@@ -3658,24 +3611,24 @@ options {
                   to zero.
                 
    
                 
    
-                  For convenience, TTL-style time unit suffixes can be
+                  For convenience, TTL-style time-unit suffixes can be
                   used to specify the NTA recheck interval in seconds,
-                  minutes or hours.  The default is five minutes.  It
-                  cannot be longer than nta-lifetime
-                  (which cannot be longer than a week).
+                  minutes, or hours.  The default is five minutes.  It
+                  cannot be longer than nta-lifetime,
+                  which cannot be longer than a week.
                 
    
             
    
 
    max-zone-ttl
    
 
    
               
    
-                Specifies a maximum permissible TTL value in seconds.
-                For convenience, TTL-style time unit suffixes may be
+                This specifies a maximum permissible TTL value in seconds.
+                For convenience, TTL-style time-unit suffixes may be
                 used to specify the maximum value.
                 When loading a zone file using a
                 masterfile-format of
                 text or raw,
                 any record encountered with a TTL higher than
-                max-zone-ttl will cause the zone to
+                max-zone-ttl causes the zone to
                 be rejected.
               
    
               
    
@@ -3683,11 +3636,11 @@ options {
                 rolling to a new DNSKEY, the old key needs to remain
                 available until RRSIG records have expired from
                 caches.  The max-zone-ttl option guarantees
-                that the largest TTL in the zone will be no higher
+                that the largest TTL in the zone is no higher
                 than the set value.
               
    
               
    
-                (NOTE: Because map-format files
+                (Note: because map-format files
                 load directly into memory, this option cannot be
                 used with them.)
               
    
@@ -3701,27 +3654,27 @@ options {
 
    
               
    
                 Zones configured for dynamic DNS may use this
-                option to set the update method that will be used for
+                option to set the update method to 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
+                SOA serial number is 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
+                SOA serial number is 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.
               
    
               
    
                 When set to
                 serial-update-method date;, the
-                new SOA serial number will be the current date
+                new SOA serial number is the current date
                 in the form "YYYYMMDD", followed by two zeroes,
                 unless the existing serial number is already greater
                 than or equal to that value, in which case it is
@@ -3731,12 +3684,12 @@ options {
 
    zone-statistics
    
 
    
               
    
-                If full, the server will collect
-                statistical data on all zones (unless specifically
+                If full, the server collects
+                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).
+                in the zone statement.
                 The default is terse, providing
                 minimal statistics on zones (including name and
                 current serial number, but not query type
@@ -3746,7 +3699,7 @@ options {
                 These statistics may be accessed via the
                 statistics-channel or
                 using rndc stats, which
-                will dump them to the file listed
+                dumps them to the file listed
                 in the statistics-file.  See
                 also the section called “The Statistics File”.
               
    
@@ -3773,19 +3726,19 @@ options {
 
    
                 
    
                   If yes and supported by the operating
-                  system, automatically rescan network interfaces when the
+                  system, this automatically rescans network interfaces when the
                   interface addresses are added or removed.  The default is
                   yes.  This configuration option does
-                  not affect time based interface-interval
-                  option, and it is recommended to set the time based
+                  not affect the time-based interface-interval
+                  option; it is recommended to set the time-based
                   interface-interval to 0 when the operator
                   confirms that automatic interface scanning is supported by the
                   operating system.
                 
    
                 
    
                   The automatic-interface-scan implementation
-                  uses routing sockets for the network interface discovery,
-                  and therefore the operating system has to support the routing
+                  uses routing sockets for the network interface discovery;
+                  therefore, the operating system must support the routing
                   sockets for this feature to work.
                 
    
               
    
@@ -3811,9 +3764,9 @@ options {
                   cryptographic hash of the view name is used instead.
                 
    
                 
    
-                  Zones added at runtime will have their configuration
+                  Configurations for zones added at runtime are
                   stored either in a new-zone file (NZF) or a new-zone
-                  database (NZD) depending on whether
+                  database (NZD), depending on whether
                   named was linked with
                   liblmdb at compile time.
                   See rndc(8) for further details
@@ -3826,11 +3779,7 @@ options {
                   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.
+                  authoritative. The default is no.
    deallocate-on-exit
    @@ -3845,10 +3794,10 @@ options {
    memstatistics

    - Write memory statistics to the file specified by + This writes 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 + -m record is specified on the command line, in which case it is yes.

    @@ -3860,29 +3809,27 @@ options { across a dial-on-demand dialup link, which can be brought up by traffic - originating from this server. This has different effects + originating from this server. Although this setting 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 + to zone type, it concentrates the zone maintenance so that + everything + happens quickly, once every heartbeat-interval, + ideally during a single call. It also suppresses some + 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 specified in the view and + zone statements, the dialup option + overrides the global dialup option.

    - If the zone is a master zone, then the server will send out a + If the zone is a primary zone, the server sends out a NOTIFY - request to all the slaves (default). This should trigger the + request to all the secondaries (default). This should trigger the zone serial - number check in the slave (providing it supports NOTIFY) - allowing the slave + number check in the secondary (providing it supports NOTIFY), + allowing the secondary to verify the zone while the connection is active. The set of servers to which NOTIFY is sent can be controlled by @@ -3890,26 +3837,26 @@ options {

    If the - zone is a slave or stub zone, then the server will suppress + zone is a secondary or stub zone, the server suppresses the regular - "zone up to date" (refresh) queries and only perform them + "zone up to date" (refresh) queries and only performs them when the - heartbeat-interval expires in + 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 + notify, which only sends NOTIFY + messages; + notify-passive, which sends NOTIFY messages and - suppresses the normal refresh queries, refresh + 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 + expires; and + passive, which disables normal refresh processing.

    @@ -4091,7 +4038,7 @@ options { In BIND 8, fetch-glue yes caused the server to attempt to fetch glue resource records it - didn't have when constructing the additional + did not have when constructing the additional data section of a response. This is now considered a bad idea and BIND 9 never does it. @@ -4100,7 +4047,7 @@ options {
    flush-zones-on-shutdown

    - When the nameserver exits due receiving SIGTERM, + When the nameserver exits upon receiving SIGTERM, flush or do not flush any pending zone writes. The default is flush-zones-on-shutdown no. @@ -4135,13 +4082,13 @@ options { In BIND 8, this enabled keeping of statistics for every host that the name server interacts with. - Not implemented in BIND 9. + It is not implemented in BIND 9.

    root-key-sentinel

    - Respond to root key sentinel probes as described in + If yes, respond to root key sentinel probes as described in draft-ietf-dnsop-kskroll-sentinel-08. The default is yes.

    @@ -4153,7 +4100,7 @@ options { 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 + log whenever possible. To disable outgoing incremental zone transfers, use provide-ixfr no.

    @@ -4163,7 +4110,7 @@ options {

    If yes, DNS name compression is used in responses to regular queries (not including - AXFR or IXFR, which always uses compression). Setting + AXFR or IXFR, which always use compression). Setting this option to no reduces CPU usage on servers and may improve throughput. However, it increases response size, which may cause more queries @@ -4176,14 +4123,14 @@ options {

    If set to yes, then when generating - responses the server will only add records to the authority + responses the server only adds 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.

    When set to no-auth, the - server will omit records from the authority section + server omits records from the authority section unless they are required, but it may still add records to the additional section. When set to no-auth-recursive, this @@ -4191,7 +4138,7 @@ options { settings are useful when answering stub clients, which usually ignore the authority section. no-auth-recursive is - designed for mixed-mode servers which handle + designed for mixed-mode servers that handle both authoritative and recursive queries.

    @@ -4201,13 +4148,13 @@ options {

    minimal-any

    - If set to yes, then when - generating a positive response to a query of type - ANY over UDP, the server will reply with only one + If set to yes, the server replies with only one of the RRsets for the query name, and its covering - RRSIGs if any, instead of replying with all known + RRSIGs if any, when + generating a positive response to a query of type + ANY over UDP, instead of replying with all known RRsets for the name. Similarly, a query for type - RRSIG will be answered with the RRSIG records covering + RRSIG is answered with the RRSIG records covering only one type. This can reduce the impact of some kinds of attack traffic, without harming legitimate clients. (Note, however, that the RRset returned is the @@ -4215,7 +4162,7 @@ options { the smallest available RRset.) Additionally, minimal-responses is turned on for these queries, so no unnecessary records - will be added to the authority or additional sections. + are added to the authority or additional sections. The default is no.

    @@ -4223,9 +4170,9 @@ options {

    This option was used in BIND 8 to allow - a domain name to have multiple CNAME records in violation of + 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 + always strictly enforces the CNAME rules both in primary files and dynamic updates.

    @@ -4235,9 +4182,9 @@ options { If yes (the default), DNS NOTIFY messages are sent when a zone the server is authoritative for - changes, see the section called “Notify”. The messages are + changes; see the section called “Notify”. The messages are sent to the - servers listed in the zone's NS records (except the master + servers listed in the zone's NS records (except the primary server identified in the SOA MNAME field), and to any servers listed in the also-notify option. @@ -4245,7 +4192,7 @@ options {

    If master-only, notifies are only sent - for master zones. + for primary zones. If explicit, notifies are sent only to servers explicitly listed using also-notify. @@ -4257,33 +4204,33 @@ options { statement, in which case it overrides the options notify statement. It would only be necessary to turn off this option if it - caused slaves + caused secondary zones to crash.

    • notify-to-soa

    - If yes do not check the nameservers + If yes, do not check the name servers 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. + message is not sent to the SOA MNAME (SOA ORIGIN), as it is + supposed to contain the name of the ultimate primary server. + Sometimes, however, a secondary server is listed as the SOA MNAME in + hidden primary configurations; in that case, + the ultimate primary should be set to still send NOTIFY messages to + all the name servers listed in the NS RRset.

    recursion

    If yes, and a - DNS query requests recursion, then the server will attempt + DNS query requests recursion, then the server attempts to do all the work required to answer the query. If recursion is off - and the server does not already know the answer, it will - return a + and the server does not already know the answer, it + returns a referral response. The default is yes. Note that setting recursion no does not prevent @@ -4316,19 +4263,19 @@ options {

    require-server-cookie

    - Require a valid server cookie before sending a full - response to a UDP request from a cookie aware client. - BADCOOKIE is sent if there is a bad or no existent + If yes, require a valid server cookie before sending a full + response to a UDP request from a cookie-aware client. + BADCOOKIE is sent if there is a bad or nonexistent server cookie. The default is no.

    - Set this to yes to test that DNS - COOKIE clients correctly handle BADCOOKIE or if you are + Users wishing to test that DNS COOKIE clients correctly handle BADCOOKIE, or who are getting a lot of forged DNS requests with DNS COOKIES - present. Setting this to yes will - result in reduced amplification effect in a reflection - attack, as the BADCOOKIE response will be smaller than + present, should set this to yes. + Setting this to yes + results in a reduced amplification effect in a reflection + attack, as the BADCOOKIE response is smaller than a full response, while also requiring a legitimate client to follow up with a second query with the new, valid, cookie.

    @@ -4337,10 +4284,10 @@ options {

    When set to the default value of yes, - COOKIE EDNS options will be sent when applicable in + COOKIE EDNS options are sent when applicable in replies to client queries. If set to - no, COOKIE EDNS options will not - be sent in replies. This can only be set at the global + no, COOKIE EDNS options are not + sent in replies. This can only be set at the global options level, not per-view.

    @@ -4361,7 +4308,7 @@ options {

    If yes, then a COOKIE EDNS option is sent along with the query. If the - resolver has previously talked to the server, the + resolver has previously communicated with the server, the COOKIE returned in the previous transaction is sent. This is used by the server to determine whether the resolver has talked to it before. A resolver @@ -4380,9 +4327,9 @@ options {

    nocookie-udp-size

    - Sets the maximum size of UDP responses that will be + This sets the maximum size of UDP responses that are sent to queries without a valid server COOKIE. A value - below 128 will be silently raised to 128. The default + below 128 is silently raised to 128. The default value is 4096, but the max-udp-size option may further limit the response size.

    @@ -4396,10 +4343,10 @@ options {
    cookie-algorithm

    - Set the algorithm to be used when generating the - server cookie. One of "aes", "sha1" or "sha256". + This sets the algorithm to be used when generating the + server cookie; the options are "aes", "sha1", or "sha256". The default is "aes" if supported by the cryptographic - library or otherwise "sha256". + library; otherwise, "sha256".

    cookie-secret
    @@ -4408,30 +4355,30 @@ options { If set, this is a shared secret used for generating and verifying EDNS COOKIE options within an anycast cluster. If not set, the system - will generate a random secret at startup. The + generates a random secret at startup. The shared secret is encoded as a hex string and needs - to be 128 bits for AES128, 160 bits for SHA1 and + to be 128 bits for AES128, 160 bits for SHA1, and 256 bits for SHA256.

    If there are multiple secrets specified, the first one listed in named.conf is used to generate new server cookies. The others - will only be used to verify returned cookies. + are only used to verify returned cookies.

    rfc2308-type1

    - Setting this to yes will - cause the server to send NS records along with the SOA + Setting this to yes + causes the server to send NS records along with the SOA record for negative answers. The default is no.

    Note

    - Not yet implemented in BIND + This is not yet implemented in BIND 9.

    @@ -4439,7 +4386,7 @@ options {
    trust-anchor-telemetry

    - Causes named to send specially-formed + This causes named to send specially formed queries once per day to domains for which trust anchors have been configured via trusted-keys, managed-keys, or @@ -4454,8 +4401,8 @@ options { to largest prior to encoding. The query type is NULL.

    - By monitoring these queries, zone operators will - be able to see which resolvers have been updated to + By monitoring these queries, zone operators are + able to see which resolvers have been updated to trust a new key; this may help them decide when it is safe to remove an old one.

    @@ -4475,7 +4422,7 @@ options {

    This option is obsolete. - If you need to disable IXFR to a particular server or + To disable IXFR to a particular server or servers, see the information on the provide-ixfr option in the section called “server Statement Definition and @@ -4518,7 +4465,7 @@ options { 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 + 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 @@ -4545,15 +4492,15 @@ options { 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 + reply is filled in using data from other authoritative zones and from the cache. In some situations this is undesirable, such as when there is concern over the correctness of the cache, or - in servers where slave zones may be added and modified by + in servers where secondary zones may be added and modified by untrusted third parties. Also, avoiding - the search for this additional data will speed up server + the search for this additional data speeds up server operations at the possible expense of additional queries to resolve what would @@ -4563,7 +4510,7 @@ options {

    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, + records (A and AAAA) for mail.example.net are provided as well, if known, even though they are not in the example.com zone. Setting these options to no disables this behavior and makes @@ -4601,10 +4548,10 @@ options { 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 + comes from the cache, the server is not able to provide upwards referrals when additional-from-cache no - has been specified. Instead, it will respond to such + has been specified. Instead, it responds to such queries with REFUSED. This should not cause any problems since upwards referrals are not required for the resolution @@ -4616,15 +4563,15 @@ options {

    If yes, then an - IPv4-mapped IPv6 address will match any address match + IPv4-mapped IPv6 address matches 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, + 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.

    @@ -4656,15 +4603,15 @@ options {

    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. + As suggested by the name, this causes the response to not verify, + because the DNSSEC protocol is designed to 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 + 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 + via IPv4, is denied AAAA records even if its client is using IPv6.

    @@ -4683,7 +4630,7 @@ options {

    filter-aaaa-on-v6

    - Identical to filter-aaaa-on-v4, + This is 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. @@ -4693,33 +4640,32 @@ options {

    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 + version of a primary zone from its zone file or receives a + new version of a secondary file via zone transfer, it + compares the new version to the previous one and calculates a set of differences. The differences are then logged in - the zone's journal file such that the changes can be - transmitted to downstream slaves as an incremental zone + the zone's journal file so that the changes can be + transmitted to downstream secondaries 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. + primary server. 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 + is of a size comparable to the combined size of the + old and new zone versions, and the server needs 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 + levels, which causes ixfr-from-differences to be enabled for - all master or - slave zones respectively. + all primary or secondary zones, respectively. It is off by default.

    @@ -4731,11 +4677,11 @@ options {

    multi-master

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

    @@ -4756,7 +4702,7 @@ options {

    auto-dnssec maintain; includes the above, but also automatically adjusts the zone's DNSSEC - keys on schedule, according to the keys' timing metadata + keys on a schedule, according to the keys' timing metadata (see dnssec-keygen(8) and dnssec-settime(8)). The command rndc sign @@ -4770,7 +4716,7 @@ options { 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 + zone the first time, the repository is searched for changes periodically, regardless of whether rndc loadkeys is used. The recheck interval is defined by @@ -4786,7 +4732,7 @@ options { This indicates whether DNSSEC-related resource records are to be returned by named. If set to no, - named will not return DNSSEC-related + named does not return DNSSEC-related resource records unless specifically queried for. The default is yes.

    @@ -4794,15 +4740,15 @@ options {
    dnssec-validation

    - Enable DNSSEC validation in named. - Note dnssec-enable also needs to be + This option enables DNSSEC validation in named. + Note that 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 + 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 @@ -4812,7 +4758,7 @@ options {

    The default root trust anchor is stored in the file bind.keys. - named will load that key at + named loads that key at startup if dnssec-validation is set to auto. A copy of the file is installed along with BIND 9, and is current as of the @@ -4821,7 +4767,7 @@ options { from https://www.isc.org/bind-keys.

    - To prevent problems if bind.keys is + (To prevent problems if bind.keys is not found, the current trust anchor is also compiled in to named. Relying on this is not recommended, however, as it requires named @@ -4830,8 +4776,8 @@ options {

    Note

    - named only - loads the root key from bind.keys. + named loads only + the root key from bind.keys. The file cannot be used to store keys for other zones. The root key in bind.keys is ignored if dnssec-validation auto is not in @@ -4840,7 +4786,7 @@ options {

    Whenever the resolver sends out queries to an EDNS-compliant server, it always sets the DO bit - indicating it can support DNSSEC responses even if + indicating it can support DNSSEC responses, even if dnssec-validation is off.

    @@ -4848,7 +4794,7 @@ options {
    dnssec-accept-expired

    - Accept expired signatures when verifying DNSSEC signatures. + This accepts expired signatures when verifying DNSSEC signatures. The default is no. Setting this option to yes leaves named vulnerable to @@ -4861,7 +4807,7 @@ options { Query logging provides a complete log of all incoming queries and all query errors. This provides more insight into the server's activity, but with a cost to - performance which may be significant on heavily-loaded + performance which may be significant on heavily loaded servers.

    @@ -4881,14 +4827,15 @@ options {

    This option is used to restrict the character set and syntax of - certain domain names in master files and/or DNS responses + certain domain names in zone 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) + area. For primary zones (i.e., + type master), + the default is fail. + For secondary zones (type slave), the + default is warn. + For answers received from the network (response), the default is ignore.

    @@ -4896,18 +4843,18 @@ options { from RFC 952 and RFC 821 as modified by RFC 1123.

    check-names - applies to the owner names of A, AAAA and MX records. + 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 + It further applies to the RDATA of PTR records where the owner + name indicates that it is a reverse lookup of a hostname (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).

    check-dup-records

    - Check master zones for records that are treated as different + This checks primary 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 @@ -4917,7 +4864,7 @@ options {

    check-mx

    - Check whether the MX record appears to refer to a IP address. + This checks whether the MX record appears to refer to a IP address. The default is to warn. Other possible values are fail and ignore. @@ -4931,49 +4878,49 @@ options { result of a failure to understand the wildcard matching algorithm (RFC 1034). This option - affects master zones. The default (yes) is to check + affects primary zones. The default (yes) is to check for non-terminal wildcards and issue a warning.

    check-integrity

    - Perform post load zone integrity checks on master - zones. This checks that MX and SRV records refer + This performs post-load zone integrity checks on primary + zones. It 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 + 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 + For NS records, only names below top-of-zone are checked (for out-of-zone names and glue consistency - checks use named-checkzone). + checks, use named-checkzone). The default is yes.

    - The use of the SPF record for publishing Sender - Policy Framework is deprecated as the migration + The use of the SPF record to publish Sender + Policy Framework is deprecated, as the migration from using TXT records to SPF records was abandoned. Enabling this option also checks that a TXT Sender Policy Framework record exists (starts with "v=spf1") if there is an SPF record. Warnings are emitted if the - TXT record does not exist and can be suppressed with + TXT record does not exist; they can be suppressed with check-spf.

    check-mx-cname

    - If check-integrity is set then - fail, warn or ignore MX records that refer + If check-integrity is set, then + fail, warn, or ignore MX records that refer to CNAMES. The default is to warn.

    check-srv-cname

    - If check-integrity is set then - fail, warn or ignore SRV records that refer + If check-integrity is set, then + fail, warn, or ignore SRV records that refer to CNAMES. The default is to warn.

    @@ -4987,7 +4934,7 @@ options {
    check-spf

    - If check-integrity is set then + If check-integrity is set, check that there is a TXT Sender Policy Framework record present (starts with "v=spf1") if there is an SPF record present. The default is @@ -4997,8 +4944,8 @@ options {

    zero-no-soa-ttl

    - When returning authoritative negative responses to - SOA queries set the TTL of the SOA record returned in + If yes, 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.

    @@ -5006,7 +4953,7 @@ options {
    zero-no-soa-ttl-cache

    - When caching a negative response to a SOA query + If yes, when caching a negative response to an SOA query set the TTL to zero. The default is no.

    @@ -5027,14 +4974,14 @@ options { 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. + 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 + this requirement is not met, this option is ignored for that algorithm.

    @@ -5043,12 +4990,12 @@ options {

    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 + keys (that is, keys with the KSK bit set) are used to sign the DNSKEY RRset at the zone apex. Zone-signing - keys (keys without the KSK bit set) will be used to sign + keys (keys without the KSK bit set) are used to sign the remainder of the zone, but not the DNSKEY RRset. This is similar to the - dnssec-signzone -x command line option. + dnssec-signzone -x command-line option.

    The default is no. If @@ -5059,25 +5006,25 @@ options {

    try-tcp-refresh

    - Try to refresh the zone using TCP if UDP queries fail. - For BIND 8 compatibility, the default is + If yes, try to refresh the zone using TCP if UDP queries fail. + The default is yes.

    dnssec-secure-to-insecure

    - Allow a dynamic zone to transition from secure to + This allows 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. + are 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. + If the zone uses NSEC3, it is also necessary to + delete the NSEC3PARAM RRset from the zone apex; this + causes the removal of all corresponding NSEC3 records. (It is expected that this requirement will be eliminated in a future release.)

    @@ -5113,20 +5060,20 @@ options {

    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 + forwarders list is not empty. A value of first is + the default and causes the server to query the forwarders + first; + if that does not answer the question, the server then + looks for the answer itself. If only is specified, the - server will only query the forwarders. + server only queries the forwarders.

    forwarders

    - Specifies a list of IP addresses to which queries shall be + This specifies a list of IP addresses to which queries are forwarded. The default is the empty list (no forwarding). Each address in the list can be associated with an optional port number and/or DSCP value, and a default port number and @@ -5138,10 +5085,10 @@ options {

    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 + of ways. Particular domains can be set to use different forwarders, or have a different forward only/first behavior, - or not forward at all, see the section called “zone + or not forward at all; see the section called “zone Statement Grammar”.

    @@ -5151,7 +5098,7 @@ options { Dual-stack Servers

    - Dual-stack servers are used as servers of last resort to work + 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 @@ -5162,14 +5109,13 @@ options {

    dual-stack-servers

    - Specifies host names or addresses of machines with access to + This 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 + machine is dual-stacked, the dual-stack-servers parameter has no effect unless access to a transport has been disabled on the command line - (e.g. named -4). + (e.g., named -4).

    @@ -5190,24 +5136,24 @@ options {
    allow-notify

    - Specifies which hosts are allowed to - notify this server, a slave, of zone changes in addition - to the zone masters. + This ACL specifies which hosts are allowed to + notify this secondary server of zone changes in addition + to the zone primaries. 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 + for a secondary zone. If not specified, the default is to process notify messages - only from a zone's master. + only from a zone's primary.

    allow-query

    - Specifies which hosts are allowed to ask ordinary + This 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 @@ -5218,7 +5164,7 @@ options {

    Note

    - allow-query-cache is now + allow-query-cache is used to specify access to the cache.

    @@ -5226,7 +5172,7 @@ options {
    allow-query-on

    - Specifies which local addresses can accept ordinary + This 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 @@ -5236,7 +5182,7 @@ options { 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. + allowed by both ACLs, or it is refused.

    allow-query-on may @@ -5259,35 +5205,36 @@ options {

    allow-query-cache

    - Specifies which hosts are allowed to get answers + This 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; + is not set, BIND checks to see if the following parameters + are set, in order: allow-recursion and + allow-query + (unless recursion no; is + set, in which case none; is used). + If neither of those parameters is set, the default (localnets; localhost;) is used.

    allow-query-cache-on

    - Specifies which local addresses can give answers + This specifies which local addresses can send answers from the cache. If not specified, the default is to allow cache queries on any address, - localnets and + 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 + This specifies which hosts are allowed to make recursive + queries through this server. BIND checks to see if the + following parameters are set, in order: + allow-recursion, allow-query-cache, + and allow-query. + If none of those parameters are set, the default (localnets; localhost;) is used.

    @@ -5295,7 +5242,7 @@ options {
    allow-recursion-on

    - Specifies which local addresses can accept recursive + This specifies which local addresses can accept recursive queries. If not specified, the default is to allow recursive queries on all addresses.

    @@ -5303,8 +5250,8 @@ options {
    allow-update

    - Specifies which hosts are allowed to - submit Dynamic DNS updates for master zones. The default is + This specifies which hosts are allowed to + submit Dynamic DNS updates for primary zones. The default is to deny updates from all hosts. Note that allowing updates based on the requestor's IP address is insecure; see @@ -5314,28 +5261,28 @@ options {

    allow-update-forwarding

    - Specifies which hosts are allowed to - submit Dynamic DNS updates to slave zones to be forwarded to + This specifies which hosts are allowed to + submit Dynamic DNS updates to secondary zones to be forwarded to the - master. The default is { none; }, + primary. The default is { none; }, which - means that no update forwarding will be performed. To + means that no update forwarding is performed. To enable update forwarding, specify allow-update-forwarding { any; };. Specifying values other than { none; } or { any; } is usually - counterproductive, since + counterproductive; the responsibility for update access control should rest with the - master server, not the slaves. + primary server, not the secondaries.

    - Note that enabling the update forwarding feature on a slave + Note that enabling the update forwarding feature on a secondary server - may expose master servers relying on insecure IP address - based - access control to attacks; see the section called “Dynamic Update Security” + may expose primary servers to attacks if they rely on insecure + IP-address-based + access control; see the section called “Dynamic Update Security” for more details.

    @@ -5354,7 +5301,7 @@ options {
    allow-transfer

    - Specifies which hosts are allowed to + This specifies which hosts are allowed to receive zone transfers from the server. allow-transfer may also be specified in the zone statement, in which @@ -5366,17 +5313,17 @@ options {

    blackhole

    - Specifies a list of addresses that the - server will not accept queries from or use to resolve a + This specifies a list of addresses which the + server does accept queries from or use to resolve a query. Queries - from these addresses will not be responded to. The default + from these addresses are not responded to. The default is none.

    filter-aaaa

    - Specifies a list of addresses to which + This specifies a list of addresses to which filter-aaaa-on-v4 and filter-aaaa-on-v6 apply. The default is any. @@ -5385,8 +5332,8 @@ options {

    keep-response-order

    - Specifies a list of addresses to which the server - will send responses to TCP queries in the same order + This specifies a list of addresses to which the server + sends responses to TCP queries, in the same order in which they were received. This disables the processing of TCP queries in parallel. The default is none. @@ -5395,7 +5342,7 @@ options {

    no-case-compress

    - Specifies a list of addresses which require responses + This specifies a list of addresses which require responses to use case-insensitive compression. This ACL can be used when named needs to work with clients that do not comply with the requirement in RFC @@ -5405,19 +5352,19 @@ options {

    If left undefined, the ACL defaults to none: case-insensitive compression - will be used for all clients. If the ACL is defined and - matches a client, then case will be ignored when + is used for all clients. If the ACL is defined and + matches a client, case is ignored when compressing domain names in DNS responses sent to that client.

    - This can result in slightly smaller responses: if + This can result in slightly smaller responses; if a response contains the names "example.com" and - "example.COM", case-insensitive compression would treat + "example.COM", case-insensitive compression treats the second one as a duplicate. It also ensures that the case of the query name exactly matches the case of the owner names of returned records, rather - than matching the case of the records entered in + than matches the case of the records entered in the zone file. This allows responses to exactly match the query, which is required by some clients due to incorrect use of case-sensitive comparisons. @@ -5429,16 +5376,16 @@ options {

    There are circumstances in which named - will not preserve the case of owner names of records: + does not preserve the case of owner names of records: if a zone file defines records of different types with the same name, but the capitalization of the name is different (e.g., "www.example.com/A" and "WWW.EXAMPLE.COM/AAAA"), then all responses for that - name will use the first version + name use the first version of the name that was used in the zone file. This limitation may be addressed in a future release. However, domain names specified in the rdata of resource records - (i.e., records of type NS, MX, CNAME, etc) will always + (i.e., records of type NS, MX, CNAME, etc.) always have their case preserved unless the client matches this ACL.

    @@ -5446,12 +5393,12 @@ options {
    resolver-query-timeout

    - The amount of time in seconds that the resolver - will spend attempting to resolve a recursive + This is the amount of time in seconds that the + resolver spends 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 + 0 results in the default being used.

    @@ -5464,18 +5411,18 @@ options { Interfaces

    - The interfaces and ports that the server will answer queries + The interfaces and ports that the server answers queries from may be specified using the listen-on option. listen-on takes an optional port and an address_match_list of IPv4 addresses. (IPv6 addresses are ignored, with a logged warning.) - The server will listen on all interfaces allowed by the address - match list. If a port is not specified, port 53 will be used. + The server listens on all interfaces allowed by the address + match list. If a port is not specified, port 53 is used.

    Multiple listen-on statements are allowed. - For example, + For example: 

    listen-on { 5.6.7.8; };
@@ -5483,21 +5430,21 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; };

    - will enable the name server on port 53 for the IP address + enables 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. + server listens 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. + specify the interfaces and the ports on which the server + listens for incoming queries sent using IPv6. If not specified, + the server listens on port 53 on all IPv6 interfaces.

    @@ -5508,8 +5455,8 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; }; 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 + 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, @@ -5523,13 +5470,13 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; }; address, regardless of whether the desired API is supported by the system. IPv4 addresses specified in listen-on-v6 - will be ignored, with a logged warning. + are ignored, with a logged warning.

    Multiple listen-on-v6 options can be used. - For example, + For example: 

    listen-on-v6 { any; };
@@ -5537,14 +5484,14 @@ listen-on-v6 port 1234 { !2001:db8::/32; any; };

    - will enable the name server on port 53 for any IPv6 addresses + enables 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.) + and on port 1234 of IPv6 addresses that are not in the prefix + 2001:db8::/32 (with separate sockets for each matched address).

    - To make the server not listen on any IPv6 address, use + To instruct the server not to listen on any IPv6 address, use: 

    listen-on-v6 { none; };
@@ -5557,20 +5504,20 @@ listen-on-v6 port 1234 { !2001:db8::/32; any; };
 Query Address
 
           
    
-            If the server doesn't know the answer to a question, it will
-            query other name servers. query-source specifies
+            If the server does not know the answer to a question, it
+            queries 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.
+            is used.
           
    
 
           
    
             If port is * or is omitted,
             a random port number from a pre-configured
-            range is picked up and will be used for each query.
-            The port range(s) is that specified in
+            range is picked up and used for each query.
+            The port range(s) is specified in
             the use-v4-udp-ports (for IPv4)
             and use-v6-udp-ports (for IPv6)
             options, excluding the ranges specified in
@@ -5591,12 +5538,12 @@ query-source-v6 address * port *;
           
    
             If use-v4-udp-ports or
             use-v6-udp-ports is unspecified,
-            named will check if the operating
+            named checks whether 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:
+            named uses the corresponding system
+            default range; otherwise, it uses its own defaults:
          
    
 
 
    use-v4-udp-ports { range 1024 65535; };
@@ -5604,18 +5551,18 @@ use-v6-udp-ports { range 1024 65535; };
 
    
 
           
    
-            Note: make sure the ranges be sufficiently large for
-            security.  A desirable size depends on various parameters,
+            Note: make sure the ranges are sufficiently large for
+            security.  A desirable size depends on several 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
+            range is automatically applied when named
             is reloaded.
-            It is encouraged to
-            configure use-v4-udp-ports and
-            use-v6-udp-ports explicitly so that the
+            Explicit
+            configuration of use-v4-udp-ports and
+            use-v6-udp-ports is encouraged, so that the
             ranges are sufficiently large and are reasonably
             independent from the ranges used by other applications.
           
    
@@ -5623,8 +5570,8 @@ use-v6-udp-ports { range 1024 65535; };
           
    
             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
+            of some ports.  For example, Unix systems do not allow
+            named, if run without 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
@@ -5716,12 +5663,12 @@ avoid-v6-udp-ports {};
 
    also-notify
    
 
    
                 
    
-                  Defines a global list of IP addresses of name servers
+                  This option 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
+                  This helps to ensure that copies of the zones
                   quickly converge on stealth servers.
                   Optionally, a port may be specified with each
                   also-notify address to send
@@ -5736,13 +5683,13 @@ avoid-v6-udp-ports {};
                 
    
                   If an also-notify list
                   is given in a zone statement,
-                  it will override
+                  it overrides
                   the options also-notify
                   statement. When a zone notify
                   statement
                   is set to no, the IP
-                  addresses in the global also-notify list will
-                  not be sent NOTIFY messages for that zone. The default is
+                  addresses in the global also-notify list are
+                  not sent NOTIFY messages for that zone. The default is
                   the empty
                   list (no global notification list).
                 
    
@@ -5751,7 +5698,7 @@ avoid-v6-udp-ports {};
 
    
                 
    
                   Inbound zone transfers running longer than
-                  this many minutes will be terminated. The default is 120
+                  this many minutes are terminated. The default is 120
                   minutes
                   (2 hours).  The maximum value is 28 days (40320 minutes).
                 
    
@@ -5760,7 +5707,7 @@ avoid-v6-udp-ports {};
 
    
                 
    
                   Inbound zone transfers making no progress
-                  in this many minutes will be terminated. The default is 60
+                  in this many minutes are terminated. The default is 60
                   minutes
                   (1 hour).  The maximum value is 28 days (40320 minutes).
                 
    
@@ -5769,7 +5716,7 @@ avoid-v6-udp-ports {};
 
    
                 
    
                   Outbound zone transfers running longer than
-                  this many minutes will be terminated. The default is 120
+                  this many minutes are terminated. The default is 120
                   minutes
                   (2 hours).  The maximum value is 28 days (40320 minutes).
                 
    
@@ -5778,7 +5725,7 @@ avoid-v6-udp-ports {};
 
    
                 
    
                   Outbound zone transfers making no progress
-                  in this many minutes will be terminated.  The default is 60
+                  in this many minutes are terminated.  The default is 60
                   minutes (1
                   hour).  The maximum value is 28 days (40320 minutes).
                 
    
@@ -5786,49 +5733,45 @@ avoid-v6-udp-ports {};
 
    notify-rate
    
 
    
                 
    
-                  The rate at which NOTIFY requests will be sent
+                  This specifies the rate at which NOTIFY requests are sent
                   during normal zone maintenance operations. (NOTIFY
                   requests due to initial zone loading are subject
                   to a separate rate limit; see below.) The default is
                   20 per second.
                   The lowest possible rate is one per second; when set
-                  to zero, it will be silently raised to one.
+                  to zero, it is silently raised to one.
                 
    
               
    
 
    startup-notify-rate
    
 
    
                 
    
-                  The rate at which NOTIFY requests will be sent
+                  This is the rate at which NOTIFY requests are sent
                   when the name server is first starting up, or when
-                  zones have been newly added to the nameserver.
+                  zones have been newly added to the name server.
                   The default is 20 per second.
                   The lowest possible rate is one per second; when set
-                  to zero, it will be silently raised to one.
+                  to zero, it is silently raised to one.
                 
    
               
    
 
    serial-query-rate
    
 
    
                 
    
-                  Slave servers will periodically query master
+                  Secondary servers periodically query primary
                   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 secondary 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 per second.
                   The lowest possible rate is one per second; when set
-                  to zero, it will be silently raised to one.
+                  to zero, it is silently raised to one.
                 
    
               
    
 
    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
@@ -5843,18 +5786,14 @@ avoid-v6-udp-ports {};
                   one-answer and
                   many-answers.
                   The transfer-format option is used
-                  on the master server to determine which format it sends.
+                  on the primary 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.
+                  records as possible into one message.
+                  many-answers is more efficient; the default is many-answers.
                   The many-answers format is also supported by
-                  recent Microsoft Windows nameservers.
-                  The default is many-answers.
+                  recent Microsoft Windows name servers.
                   transfer-format may be overridden on a
                   per-server basis by using the server
                   statement.
@@ -5866,7 +5805,7 @@ avoid-v6-udp-ports {};
                 
    
                   This is an upper bound on the uncompressed size of DNS
                   messages used in zone transfers over TCP.  If a message
-                  grows larger than this size, additional messages will be
+                  grows larger than this size, additional messages are
                   used to complete the zone transfer.  (Note, however,
                   that this is a hint, not a hard limit; if a message
                   contains a single resource record whose RDATA does not
@@ -5874,10 +5813,10 @@ avoid-v6-udp-ports {};
                   permitted so the record can be transferred.)
                 
    
                 
    
-                  Valid values are between 512 and 65535 octets, and any
-                  values outside that range will be adjusted to the nearest
+                  Valid values are between 512 and 65535 octets; any
+                  values outside that range are adjusted to the nearest
                   value within it.  The default is 20480,
-                  which was selected to improve message compression:
+                  which was selected to improve message compression;
                   most DNS messages of this size will compress to less
                   than 16536 bytes.  Larger messages cannot be compressed
                   as effectively, because 16536 is the largest permissible
@@ -5892,33 +5831,33 @@ avoid-v6-udp-ports {};
 
    transfers-in
    
 
    
                 
    
-                  The maximum number of inbound zone transfers
-                  that can be running concurrently. The default value is 10.
+                  This is the maximum number of inbound zone transfers
+                  that can run 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
+                  of secondary 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
+                  This is the maximum number of outbound zone transfers
+                  that can run concurrently. Zone transfer requests in
                   excess
-                  of the limit will be refused. The default value is 10.
+                  of the limit are 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
+                  This is the maximum number of inbound zone transfers
+                  that can concurrently transfer 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
+                  speed up the convergence of secondary 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
@@ -5928,13 +5867,13 @@ avoid-v6-udp-ports {};
 
    transfer-source
    
 
    
                 
    transfer-source
-                  determines which local address will be bound to IPv4
+                  determines which local address is 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
+                  updates.  If not set, it defaults to a
+                  system-controlled value which is usually the address
                   of the interface "closest to" the remote end. This
                   address must appear in the remote end's
                   allow-transfer option for the
@@ -5959,14 +5898,14 @@ avoid-v6-udp-ports {};
 
    transfer-source-v6
    
 
    
                 
    
-                  The same as transfer-source,
+                  This option is the same as transfer-source,
                   except zone transfers are performed using IPv6.
                 
    
               
    
 
    alt-transfer-source
    
 
    
                 
    
-                  An alternate transfer source if the one listed in
+                  This indicates an alternate transfer source if the one listed in
                   transfer-source fails and
                   use-alt-transfer-source is
                   set.
@@ -5974,10 +5913,9 @@ avoid-v6-udp-ports {};
                 
    
 
    Note
    
 
    
-                  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
+                  To avoid using the alternate transfer source,
+                  set use-alt-transfer-source
+                  appropriately and do not depend upon
                   getting an answer back to the first refresh
                   query.
                 
    
@@ -5986,7 +5924,7 @@ avoid-v6-udp-ports {};
 
    alt-transfer-source-v6
    
 
    
                 
    
-                  An alternate transfer source if the one listed in
+                  This indicates an alternate transfer source if the one listed in
                   transfer-source-v6 fails and
                   use-alt-transfer-source is
                   set.
@@ -5995,19 +5933,18 @@ avoid-v6-udp-ports {};
 
    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).
+                  This indicates whether the alternate transfer sources should be used.  If views are
+                  specified, this defaults to no;
+                  otherwise, it defaults to
+                  yes.
                 
    
               
    
 
    notify-source
    
 
    
                 
    notify-source
                   determines which local source address, and
-                  optionally UDP port, will be used to send NOTIFY
-                  messages.  This address must appear in the slave
+                  optionally UDP port, is used to send NOTIFY
+                  messages.  This address must appear in the secondary
                   server's masters zone clause or
                   in an allow-notify clause.  This
                   statement sets the notify-source
@@ -6029,7 +5966,7 @@ avoid-v6-udp-ports {};
 
    notify-source-v6
    
 
    
                 
    
-                  Like notify-source,
+                  This option acts like notify-source,
                   but applies to notify messages sent to IPv6 addresses.
                 
    
               
    
@@ -6046,11 +5983,11 @@ avoid-v6-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.
+            specify a list of IPv4 and IPv6 UDP ports that are
+            or are not used as source ports for UDP messages.
             See the section called “Query Address” about how the
             available ports are determined.
-            For example, with the following configuration
+            For example, with the following configuration:
           
    
 
 
    @@ -6060,7 +5997,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
            
    
              UDP ports of IPv6 messages sent
-             from named will be in one
+             from named are in one
              of the following ranges: 32768 to 39999, 40001 to 49999,
              and 60001 to 65535.
            
    
@@ -6069,11 +6006,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
              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
+             port that is blocked by a 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
+             answer would not pass through 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
@@ -6104,10 +6041,10 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
           
    
             The following options set operating system resource limits for
-            the name server process.  Some operating systems don't support
+            the name server process.  Some operating systems do not support
             some or
-            any of the limits. On such systems, a warning will be issued if
-            the
+            any of the limits; on such systems, a warning is issued if
+            an
             unsupported limit is used.
           
    
 
@@ -6115,23 +6052,23 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    coresize
    
 
    
                 
    
-                  The maximum size of a core dump. The default
+                  This sets the maximum size of a core dump. The default
                   is default.
                 
    
               
    
 
    datasize
    
 
    
                 
    
-                  The maximum amount of data memory the server
+                  This sets 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
+                  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
+                  this option is rarely useful as a way to limit the
                   amount of memory used by the server, but it can be used
                   to raise an operating system data size limit that is
-                  too small by default.  If you wish to limit the amount
+                  too small by default.  To limit the amount
                   of memory used by the server, use the
                   max-cache-size and
                   recursive-clients
@@ -6141,14 +6078,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    files
    
 
    
                 
    
-                  The maximum number of files the server
+                  This sets the maximum number of files the server
                   may have open concurrently. The default is unlimited.
                 
    
               
    
 
    stacksize
    
 
    
                 
    
-                  The maximum amount of stack memory the server
+                  This sets the maximum amount of stack memory the server
                   may use. The default is default.
                 
    
               
    
@@ -6158,12 +6095,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
         
    
 
    
-Server  Resource Limits
    
+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.
+            server rather than by the operating system.
           
    
 
           
    
@@ -6179,38 +6116,38 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    max-journal-size
    
 
    
                 
    
-                  Sets a maximum size for each journal file
-                  (see the section called “The journal file”).  When the journal file
+                  This sets a maximum size for each journal file
+                  (see the section called “The Journal File”).  When the journal file
                   approaches
                   the specified size, some of the oldest transactions in the
                   journal
-                  will be automatically removed.  The largest permitted
+                  are 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.
+                  This option may also be set on a per-zone basis.
                 
    
               
    
 
    max-records
    
 
    
                 
    
-                  The maximum number of records permitted in a zone.
-                  The default is zero which means unlimited.
+                  This sets the maximum number of records permitted in a zone.
+                  The default is zero, which means the maximum is unlimited.
                 
    
               
    
 
    host-statistics-max
    
 
    
                 
    
-                  In BIND 8, specifies the maximum number of host statistics
+                  In BIND 8, this specified the maximum number of host statistics
                   entries to be kept.
-                  Not implemented in BIND 9.
+                  It is not implemented in BIND 9.
                 
    
               
    
 
    recursive-clients
    
 
    
                 
    
-                  The maximum number ("hard quota") of simultaneous
-                  recursive lookups the server will perform on behalf
+                  This sets the maximum number (a "hard quota") of simultaneous
+                  recursive lookups the server performs on behalf
                   of clients.  The default is
                   1000.  Because each recursing
                   client uses a fair
@@ -6221,15 +6158,15 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    
                 
    
                   recursive-clients defines a "hard
-                  quota" limit for pending recursive clients: when more
+                  quota" limit for pending recursive clients; when more
                   clients than this are pending, new incoming requests
-                  will not be accepted, and for each incoming request
-                  a previous pending request will also be dropped.
+                  are not accepted, and for each incoming request
+                  a previous pending request is dropped.
                 
    
                 
    
                   A "soft quota" is also set.  When this lower
                   quota is exceeded, incoming requests are accepted, but
-                  for each one, a pending request will be dropped.
+                  for each one, a pending request is dropped.
                   If recursive-clients is greater than
                   1000, the soft quota is set to
                   recursive-clients minus 100;
@@ -6240,8 +6177,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    tcp-clients
    
 
    
                 
    
-                  The maximum number of simultaneous client TCP
-                  connections that the server will accept.
+                  This is the maximum number of simultaneous client TCP
+                  connections that the server accepts.
                   The default is 150.
                 
    
               
    
@@ -6252,29 +6189,29 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    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
+                  (<qname,qtype,qclass>) that the server accepts
+                  before dropping additional clients.  named attempts to
+                  self-tune this value and changes are 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
+                  If the number of queries exceeds this value, named
+                  assumes that it is dealing with a non-responsive zone
+                  and drops additional queries.  If it gets a response
+                  after dropping queries, it raises the estimate.  The
+                  estimate is then 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.
+                  there is no limit on the number of clients per query
+                  and no queries are dropped.
                 
    
                 
    
                   If max-clients-per-query is set to zero,
-                  then there is no upper bound other than imposed by
+                  there is no upper bound other than imposed by
                   recursive-clients.
                 
    
               
@@ -6283,9 +6220,9 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 
    
                 
    
-                  The maximum number of simultaneous iterative
-                  queries to any one domain that the server will
-                  permit before blocking new queries for data
+                  This sets the maximum number of simultaneous iterative
+                  queries to any one domain that the server
+                  permits before blocking new queries for data
                   in or beneath that zone.
                   This value should reflect how many fetches would
                   normally be sent to any one zone in the time it
@@ -6294,13 +6231,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    
                 
    
                   When many clients simultaneously query for the
-                  same name and type, the clients will all be attached
+                  same name and type, the clients are all attached
                   to the same fetch, up to the
                   max-clients-per-query limit,
-                  and only one iterative query will be sent.
+                  and only one iterative query is sent.
                   However, when clients are simultaneously
                   querying for different names
-                  or types, multiple queries will be sent and
+                  or types, multiple queries are sent and
                   max-clients-per-query is not
                   effective as a limit.
                 
    
@@ -6308,14 +6245,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   Optionally, this value may be followed by the keyword
                   drop or fail,
                   indicating whether queries which exceed the fetch
-                  quota for a zone will be dropped with no response,
+                  quota for a zone are dropped with no response,
                   or answered with SERVFAIL.  The default is
                   drop.
                 
    
                 
    
                   If fetches-per-zone is set to zero,
-                  then there is no limit on the number of fetches per query
-                  and no queries will be dropped.  The default is zero.
+                  there is no limit on the number of fetches per query
+                  and no queries are dropped.  The default is zero.
                 
    
                 
    
                   The current list of active fetches can be dumped by
@@ -6336,8 +6273,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 
    
                 
    
-                  The maximum number of simultaneous iterative
-                  queries that the server will allow to be sent to
+                  This sets the maximum number of simultaneous iterative
+                  queries that the server allows to be sent to
                   a single upstream name server before blocking
                   additional queries.
                   This value should reflect how many fetches would
@@ -6348,16 +6285,16 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    
                   Optionally, this value may be followed by the keyword
                   drop or fail,
-                  indicating whether queries will be dropped with no
-                  response, or answered with SERVFAIL, when all of the
+                  indicating whether queries are dropped with no
+                  response or answered with SERVFAIL, when all of the
                   servers authoritative for a zone are found to have
                   exceeded the per-server quota.  The default is
                   fail.
                 
    
                 
    
                   If fetches-per-server is set to zero,
-                  then there is no limit on the number of fetches per query
-                  and no queries will be dropped.  The default is zero.
+                  there is no limit on the number of fetches per query
+                  and no queries are dropped.  The default is zero.
                 
    
                 
    
                   The fetches-per-server quota is
@@ -6379,7 +6316,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    fetch-quota-params
    
 
    
                 
    
-                  Sets the parameters to use for dynamic resizing of
+                  This sets the parameters to use for dynamic resizing of
                   the fetches-per-server quota in
                   response to detected congestion.
                 
    
@@ -6387,7 +6324,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   The first argument is an integer value indicating
                   how frequently to recalculate the moving average
                   of the ratio of timeouts to responses for each
-                  server.  The default is 100, meaning we recalculate
+                  server.  The default is 100, meaning that BIND recalculates
                   the average ratio after every 100 queries have either
                   been answered or timed out.
                 
    
@@ -6403,21 +6340,21 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   events to weigh more heavily, smoothing out
                   short-term blips in the timeout ratio.
                   These arguments are all fixed-point numbers with
-                  precision of 1/100: at most two places after
+                  precision of 1/100; at most two places after
                   the decimal point are significant.
                 
    
               
    
 
    reserved-sockets
    
 
    
                 
    
-                  The number of file descriptors reserved for TCP, stdio,
+                  This sets the number of file descriptors reserved for TCP, stdio,
                   etc.  This needs to be big enough to cover the number of
                   interfaces named listens on plus
                   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
+                  maximum value is 128 fewer than
                   maxsockets (-S).  This option may be removed in the future.
                 
    
                 
    
@@ -6427,26 +6364,26 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    max-cache-size
    
 
    
                 
    
-                  The maximum amount of memory to use for the
-                  server's cache, in bytes or % of total physical memory.
+                  This sets the maximum amount of memory to use for the
+                  server's cache, in bytes or percentage of total physical memory.
                   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
+                  reaches this limit, the server causes records to
+                  expire prematurely, following 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
+                  or the value 0, places no limit on the cache size;
+                  records are purged from the cache only when their
                   TTLs expire.
-                  Any positive values less than 2MB will be ignored
+                  Any positive values less than 2MB are ignored
                   and reset to 2MB.
                   In a server with multiple views, the limit applies
                   separately to the cache of each view.
                   The default is 90%.
-                  On systems where detection of amount of physical
-                  memory is not supported values represented as %
+                  On systems where detection of the amount of physical
+                  memory is not supported, values represented as a percentage
                   fall back to unlimited.
                   Note that the detection of physical memory is done only
-                  once at startup, so named will not
+                  once at startup, so named does not
                   adjust the cache size if the amount of physical memory
                   is changed during runtime.
                 
    
@@ -6454,14 +6391,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    tcp-listen-queue
    
 
    
                 
    
-                  The listen queue depth.  The default and minimum is 10.
-                  If the kernel supports the accept filter "dataready" this
+                  This sets 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
+                  many TCP connections are 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
+                  some data before being passed to accept.  Non-zero values
+                  less than 10 are 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.
                 
    
               
    
@@ -6478,11 +6415,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    
                 
    
                   This interval is effectively obsolete.  Previously,
-                  the server would remove expired resource records
+                  the server removed 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.
+                  rely on periodic cleaning anymore.
                   Specifying this option therefore has no effect on
                   the server's behavior.
                 
    
@@ -6490,46 +6427,45 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    heartbeat-interval
    
 
    
                 
    
-                  The server will perform zone maintenance tasks
+                  The server performs zone maintenance tasks
                   for all zones marked as dialup whenever this
                   interval expires. The default is 60 minutes. Reasonable
                   values are up
                   to 1 day (1440 minutes).  The maximum value is 28 days
                   (40320 minutes).
-                  If set to 0, no zone maintenance for these zones will occur.
+                  If set to 0, no zone maintenance for these zones occurs.
                 
    
               
    
 
    interface-interval
    
 
    
                 
    
-                  The server will scan the network interface list
+                  The server scans 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
+                  is 60 minutes; the maximum value is 28 days (40320 minutes).
+                  If set to 0, interface scanning only occurs when
                   the configuration file is loaded, or when
                   automatic-interface-scan is enabled
                   and supported by the operating system. After the scan, the
-                  server will begin listening for queries on any newly
+                  server begins 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.
+                  stops listening on interfaces that have gone away.
                 
    
               
    
 
    statistics-interval
    
 
    
                 
    
-                  Name server statistics will be logged
+                  Name server statistics are 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.
+                  60, and the maximum value is 28 days (40320 minutes).
+                  If set to 0, no statistics are logged.
                   
    
 
    
 
    Note
    
                   
    
-                    Not yet implemented in
+                    This option is not implemented in
                     BIND 9.
                   
    
                 
    
@@ -6539,7 +6475,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    
                   In BIND 8, this option indicated network topology
                   so that preferential treatment could be given to
-                  the topologicaly closest name servers when sending
+                  the topologically closest name servers when sending
                   queries. It is not implemented in BIND 9.
                 
    
               
    
@@ -6554,10 +6490,10 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           
    
             The response to a DNS query may consist of multiple resource
             records (RRs) forming a resource record set (RRset).  The name
-            server will normally return the RRs within the RRset in an
+            server normally returns the RRs within the RRset in an
             indeterminate order (but see the rrset-order
             statement in the section called “RRset Ordering”).  The client
-            resolver code should rearrange the RRs as appropriate, that is,
+            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,
@@ -6569,37 +6505,37 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           
    
             The sortlist statement (see below) takes an
             address_match_list and interprets it in a
-            special way.  Each top level statement in the
+            special way.  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
+            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. When the addresses in the
-            first element overlap, the first rule to match gets selected.
+            first element overlap, the first rule to match is selected.
           
    
           
    
             Once the source address of the query has been matched, if the
-            top level statement contains only one element, the actual
+            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 interpreted as a topology preference
-            list.  Each top level element is assigned a distance and the
+            list.  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 of the host itself 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
+            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
+            from a host on the 192.168.1/24 network 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
+            the 192.168.5/24 network only prefer other addresses on
             their directly connected networks.
           
    
 
@@ -6628,14 +6564,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 };
    
 
           
    
-            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
+            The following example illustrates reasonable behavior for the
+            local host and hosts on directly connected networks. Responses sent to queries from
+            the local host 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.
+            directly connected network prefer addresses on that same
+            network.  Responses to other queries are not sorted.
           
    
 
 
    sortlist {
@@ -6650,12 +6584,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 RRset Ordering
 
           
    
-            When multiple records are returned in an answer it may be
+            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.
+            of the ordering of the records in a multiple-record response.
             See also the sortlist statement,
             the section called “The sortlist Statement”.
           
    
@@ -6702,7 +6636,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   
 
                     
    
-                      Records are returned in some random order.
+                      Records are returned in a random order.
                     
    
                   
 
@@ -6712,12 +6646,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   
 
                     
    
-                      Records are returned in a cyclic round-robin order.
+                      Records are returned in a cyclic round-robin order, rotating by one record per query.
                     
    
                     
    
                       If BIND is configured with the
-                      "--enable-fixed-rrset" option at compile time, then
-                      the initial ordering of the RRset will match the
+                      "--enable-fixed-rrset" option at compile time,
+                      the initial ordering of the RRset matches the
                       one specified in the zone file.
                     
    
                   
@@ -6736,17 +6670,17 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    
 
           
    
-            will cause any responses for type A records in class IN that
+            causes 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.
+            appear, they are not combined; the last one applies.
           
    
           
    
-            By default, all records are returned in random order.
+            By default, records are returned in random order.
           
    
 
           
    
@@ -6769,7 +6703,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    lame-ttl
    
 
    
                 
    
-                  Sets the number of seconds to cache a
+                  This 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
@@ -6781,7 +6715,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    servfail-ttl
    
 
    
                 
    
-                  Sets the number of seconds to cache a
+                  This sets the number of seconds to cache a
                   SERVFAIL response due to DNSSEC validation failure or
                   other general server failure.  If set to
                   0, SERVFAIL caching is disabled.
@@ -6792,7 +6726,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    
                 
    
                   The maximum value is 30
-                  seconds; any higher value will be silently
+                  seconds; any higher value is silently
                   reduced. The default is 1
                   second.
                 
    
@@ -6803,19 +6737,19 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   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
+                  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.
+                  7 days and is
+                  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 in seconds.
+                  This sets the maximum time for which the server
+                  caches ordinary (positive) answers, in seconds.
                   The default is 604800 (one week).
                   A value of zero may cause all queries to return
                   SERVFAIL, because of lost caches of intermediate
@@ -6826,7 +6760,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    min-roots
    
 
    
                 
    
-                  The minimum number of root servers that
+                  This sets the minimum number of root servers that
                   is required for a request for the root servers to be
                   accepted. The default
                   is 2.
@@ -6834,43 +6768,43 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    
 
    Note
    
                   
    
-                    Not implemented in BIND 9.
+                    This is not implemented in BIND 9.
                   
    
                 
    
               
    
 
    sig-validity-interval
    
 
    
                 
    
-                  Specifies the number of days into the future when
-                  DNSSEC signatures automatically generated as a
+                  This specifies the number of days into the future that
+                  DNSSEC signatures that are automatically generated as a
                   result of dynamic updates (the section called “Dynamic Update”) 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
+                  long before expiry that the signatures are
+                  regenerated.  If not specified, the signatures are
+                  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
+                  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).
+                  value is 10 years (3660 days).
                 
    
                 
    
                   The signature inception time is unconditionally
-                  set to one hour before the current time to allow
+                  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
+                  should be at least several multiples of the SOA
+                  expire interval, to allow for reasonable interaction
                   between the various timer and expiry dates.
                 
    
               
    
 
    sig-signing-nodes
    
 
    
                 
    
-                  Specify the maximum number of nodes to be
-                  examined in each quantum when signing a zone with
+                  This specifies the maximum number of nodes to be
+                  examined in each quantum, when signing a zone with
                   a new DNSKEY. The default is
                   100.
                 
    
@@ -6878,8 +6812,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    sig-signing-signatures
    
 
    
                 
    
-                  Specify a threshold number of signatures that
-                  will terminate processing a quantum when signing
+                  This specifies a threshold number of signatures that
+                  terminates processing a quantum, when signing
                   a zone with a new DNSKEY.  The default is
                   10.
                 
    
@@ -6887,27 +6821,27 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    sig-signing-type
    
 
    
                 
    
-                  Specify a private RDATA type to be used when generating
-                  signing state records.  The default is
+                  This specifies a private RDATA type to be used when generating
+                  signing-state records.  The default is
                   65534.
                 
    
                 
    
-                  It is expected that this parameter may be removed
-                  in a future version once there is a standard type.
+                  This parameter may be removed
+                  in a future version, once there is a standard type.
                 
    
                 
    
-                  Signing state records are used to internally by
+                  Signing-state records are used internally by
                   named to track the current state of
                   a zone-signing process, i.e., whether it is still active
                   or has been completed.  The records can be inspected
                   using the command
                   rndc signing -list zone.
                   Once named has finished signing
-                  a zone with a particular key, the signing state
+                  a zone with a particular key, the signing-state
                   record associated with that key can be removed from
                   the zone by running
                   rndc signing -clear keyid/algorithm zone.
-                  To clear all of the completed signing state
+                  To clear all of the completed signing-state
                   records for a zone, use
                   rndc signing -clear all zone.
                 
    
@@ -6921,18 +6855,18 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   zone (querying for SOA changes) or retrying failed
                   transfers.  Usually the SOA values for the zone are used,
                   up to a hard-coded maximum expiry of 24 weeks. However,
-                  these values are set by the master, giving slave server
+                  these values are set by the primary, giving secondary server
                   administrators little control over their contents.
                 
    
                 
    
                   These options allow the administrator to set a minimum and
                   maximum refresh and retry time in seconds per-zone,
                   per-view, or globally.  These options are valid for
-                  slave and stub zones, and clamp the SOA refresh and
+                  secondary and stub zones, and clamp the SOA refresh and
                   retry times to the specified values.
                 
    
                 
    
-                  The following defaults apply.
+                  The following defaults apply:
                   min-refresh-time 300 seconds,
                   max-refresh-time 2419200 seconds
                   (4 weeks), min-retry-time 500 seconds,
@@ -6943,12 +6877,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    edns-udp-size
    
 
    
                 
    
-                  Sets the maximum advertised EDNS UDP buffer size in
+                  This sets the maximum advertised EDNS UDP buffer size, in
                   bytes, to control the size of packets received from
                   authoritative servers in response to recursive queries.
-                  Valid values are 512 to 4096 (values outside this range
-                  will be silently adjusted to the nearest value within
-                  it).  The default value is 4096.
+                  Valid values are 512 to 4096; values outside this range
+                  are silently adjusted to the nearest value within
+                  it.  The default value is 4096.
                 
    
                 
    
                   The usual reason for setting
@@ -6959,33 +6893,33 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    
                 
    
                   When named first queries a remote
-                  server, it will advertise a UDP buffer size of 512, as
+                  server, it advertises 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
+                  tries again with plain DNS; if that is successful,
+                  it is 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 send an EDNS query to see if the situation has
-                  improved.)
+                  defaults to plain DNS for future communications
+                  with that server.  If that happens, named
+                  periodically sends 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
+                  named advertises 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
+                  are 512, 1232, 1432, and 4096, but never exceed
                   edns-udp-size.  (The values 1232 and
-                  1432 are chosen to allow for an IPv4/IPv6 encapsulated
+                  1432 are chosen to allow for an IPv4-/IPv6-encapsulated
                   UDP message to be sent without fragmentation at the
                   minimum MTU sizes for Ethernet and IPv6 networks.)
                 
    
@@ -6993,11 +6927,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    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 to the nearest
-                  value within it).  The default value is 4096.
+                  This sets the maximum EDNS UDP message size that
+                  named sends, in bytes.
+                  Valid values are 512 to 4096; values outside this
+                  range are silently adjusted to the nearest
+                  value within it.  The default value is 4096.
                 
    
                 
    
                   This value applies to responses sent by a server; to
@@ -7007,35 +6941,35 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 
    
                   The usual reason for setting
                   max-udp-size to a non-default
-                  value is to get UDP answers to pass through broken
+                  value is to allow 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.
+                  Setting this to a low value encourages additional
+                  TCP traffic to the name server.
                 
    
               
    
 
    masterfile-format
    
 
    
-                
    Specifies
+                
    This specifies
                   the file format of zone files (see
                   the section called “Additional File Formats”).
                   The default value is text, which is the
-                  standard textual representation, except for slave zones,
+                  standard textual representation, except for secondary zones,
                   in which the default value is raw.
-                  Files in other formats than text are
+                  Files in formats other 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
+                  Note that when a zone file in a format other than
                   text is loaded, named
                   may omit some of the checks which would be performed for a
-                  file in the text format.  In particular,
+                  file in text format.  In particular,
                   check-names checks do not apply
                   for the raw format.  This means
                   a zone file in the raw format
@@ -7058,14 +6992,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    masterfile-style
    
 
    
                 
    
-                  Specifies the formatting of zone files during dump
+                  This specifies the formatting of zone files during dump,
                   when the masterfile-format is
-                  text. (This option is ignored
-                  with any other masterfile-format.)
+                  text. This option is ignored
+                  with any other masterfile-format.
                 
    
                 
    
                   When set to relative,
-                  records are printed in a multi-line format with owner
+                  records are printed in a multi-line format, with owner
                   names expressed relative to a shared origin.  When set
                   to full, records are printed in
                   a single-line format with absolute owner names.
@@ -7082,12 +7016,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 
    
                 
    
-                  Sets the maximum number of levels of recursion
+                  This sets the maximum number of levels of recursion
                   that are permitted at any one time while servicing
                   a recursive query. Resolving a name may require
                   looking up a name server address, which in turn
-                  requires resolving another name, etc; if the number
-                  of indirections exceeds this value, the recursive
+                  requires resolving another name, etc.; if the number
+                  of recursions exceeds this value, the recursive
                   query is terminated and returns SERVFAIL.  The
                   default is 7.
                 
    
@@ -7097,7 +7031,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
 
    
                 
    
-                  Sets the maximum number of iterative queries that
+                  This sets the maximum number of iterative queries that
                   may be sent while servicing a recursive query.
                   If more queries are sent, the recursive query
                   is terminated and returns SERVFAIL.  The default is 75.
@@ -7106,20 +7040,20 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    notify-delay
    
 
    
                 
    
-                  The delay, in seconds, between sending sets of notify
-                  messages for a zone.  The default is five (5) seconds.
+                  This sets the delay, in seconds, between sending sets of NOTIFY
+                  messages for a zone.  The default is 5 seconds.
                 
    
                 
    
-                  The overall rate that NOTIFY messages are sent for all
+                  The overall rate at which 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
+                  This sets the maximum RSA exponent size, in bits, that is
+                  accepted when validating.  Valid values are 35
+                  to 4096 bits.  The default, zero, is also accepted
                   and is equivalent to 4096.
                 
    
               
    
@@ -7133,33 +7067,33 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   answer available.
                 
    
                 
    
-                  The prefetch specifies the
+                  prefetch specifies the
                   "trigger" TTL value at which prefetch of the current
-                  query will take place: when a cache record with a
+                  query takes 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.  Values larger than 10 seconds will be silently
+                  it is refreshed.  Valid trigger TTL values are 1 to
+                  10 seconds.  Values larger than 10 seconds are silently
                   reduced to 10.
-                  Setting a trigger TTL to zero (0) causes
+                  Setting a trigger TTL to zero causes
                   prefetch to be disabled.
                   The default trigger TTL is 2.
                 
    
                 
    
                   An optional second argument specifies the "eligibility"
                   TTL: the smallest original
-                  TTL value that will be accepted for a record to be
+                  TTL value that is accepted for a record to be
                   eligible for prefetching.  The eligibility TTL must
                   be at least six seconds longer than the trigger TTL;
-                  if it isn't, named will silently
-                  adjust it upward.
+                  if not, named silently
+                  adjusts it upward.
                   The default eligibility TTL is 9.
                 
    
               
 
    v6-bias
    
 
    
                 
    
-                  When determining the next nameserver to try
-                  preference IPv6 nameservers by this many milliseconds.
+                  When determining the next name server to try,
+                  this indicates by how many milliseconds to prefer IPv6 name servers.
                   The default is 50 milliseconds.
                 
    
               
    
@@ -7169,7 +7103,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
         
    
 
    
-Built-in server information zones
    
+Built-in Server Information Zones
    
 
           
    
             The server provides some helpful diagnostic information
@@ -7179,20 +7113,20 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
             of a
             built-in view (see the section called “view Statement Grammar”) of
             class
-            CHAOS which is separate from the
+            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
+            etc.) apply to this view, but some are locally
             overridden: notify,
-            recursion and
+            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
+            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.
@@ -7202,47 +7136,47 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    version
    
 
    
                 
    
-                  The version the server should report
+                  This is the version the server should report
                   via a query of the name version.bind
-                  with type TXT, class CHAOS.
+                  with type TXT and class CHAOS.
                   The default is the real version number of this server.
                   Specifying version none
                   disables processing of the queries.
                 
    
                 
    
                   Setting version to any value
-                  (including none) will also
-                  disable queries for authors.bind TXT CH.
+                  (including none) also
+                  disables queries for authors.bind TXT CH.
                 
    
               
    
 
    hostname
    
 
    
                 
    
-                  The hostname the server should report via a query of
+                  This is the hostname the server should report via a query of
                   the name hostname.bind
-                  with type TXT, class CHAOS.
+                  with type TXT and 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
+                  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;
+                  answering the queries.  Specifying hostname none;
                   disables processing of the queries.
                 
    
               
    
 
    server-id
    
 
    
                 
    
-                  The ID the server should report when receiving a Name
+                  This is 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.
+                  TXT and 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;
+                  answering the 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.
+                  Specifying server-id hostname; causes named to
+                  use the hostname as found by the gethostname() function.
                   The default server-id is none.
                 
    
               
    
@@ -7256,22 +7190,22 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
           
    
             The named server has some built-in
-            empty zones (SOA and NS records only).
+            empty zones, for 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
+            RFC 1918, RFC 4193, RFC 5737, and RFC 6598.  They also include the
+            reverse namespace for the IPv6 local address (locally assigned),
+            IPv6 link local addresses, the IPv6 loopback address, and the
             IPv6 unknown address.
           
    
           
    
-            The server will attempt to determine if a built-in zone
+            The server attempts 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.
+            forwarding declaration) and does not create an empty
+            zone if either is true.
           
    
           
    
             The current list of empty zones is:
@@ -7380,11 +7314,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    
           
    
           
    
-            Empty zones are settable at the view level and only apply to
+            Empty zones can be set 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:
+            zones, disable the root zone at the view level. For example:
 
    
 
                 disable-empty-zone ".";
@@ -7392,11 +7326,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    
           
    
           
    
-            If you are using the address ranges covered here, you should
-            already have reverse zones covering the addresses you use.
-            In practice this appears to not be the case with many queries
+            If using the address ranges covered here,
+            reverse zones covering the addresses should already be in place.
+            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
+            spaces.  So many, in fact, that sacrificial servers had
             to be deployed to channel the query load away from the
             infrastructure servers.
           
    
@@ -7404,39 +7338,39 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    Note
    
 
    
             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 zones under the parent zone they serve.  For the real
+            root servers, this is all built-in empty zones.  This
+            enables 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.
+                  This specifies the server name that appears in the returned
+                  SOA record for empty zones.  If none is specified,
+                  the zone's name is 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.
+                  This specifies the contact name that appears in the returned
+                  SOA record for empty zones.  If none is specified,
+                  "." is used.
                 
    
               
    
 
    empty-zones-enable
    
 
    
                 
    
-                  Enable or disable all empty zones.  By default, they
+                  This enables or disables all empty zones.  By default, they
                   are enabled.
                 
    
               
    
 
    disable-empty-zone
    
 
    
                 
    
-                  Disable individual empty zones.  By default, none are
+                  This disables individual empty zones.  By default, none are
                   disabled.  This option can be specified multiple times.
                 
    
               
    
@@ -7451,8 +7385,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           
    
             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
+            When additional section caching is enabled, BIND 9
+            caches an internal shortcut 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
@@ -7462,19 +7396,19 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           
    
             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
+            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
+            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
+            does not shortcut additional section information from the
             DNS cache data.
           
    
 
@@ -7483,13 +7417,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
             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
+            consumption is 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.
+            for acache by using max-acache-size.
           
    
 
           
    
@@ -7497,16 +7431,16 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
             RRset ordering in the additional section.
             Without acache,
             cyclic order is effective for the additional
-            section as well as the answer and authority sections.
+            section as well as for 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
+            ordering is 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.
+            only a single RR), so the
+            ordering is not significant.
           
    
 
           
    
@@ -7525,24 +7459,23 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
    acache-cleaning-interval
    
 
    
                 
    
-                  The server will remove stale cache entries, based on an LRU
-                  based
+                  The server removes 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.
+                  If set to 0, no periodic cleaning occurs.
                 
    
               
    
 
    max-acache-size
    
 
    
                 
    
-                  The maximum amount of memory in bytes to use for the server's acache.
+                  This is 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
+                  cleans 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.
+                  acache of each view.
                   The default is 16M.
                 
    
               
    
@@ -7556,7 +7489,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
           
    
             BIND 9 provides the ability to filter
-            out DNS responses from external DNS servers containing
+            out 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
@@ -7571,18 +7504,18 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
             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
+            matches the list are 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;
+            filter does not apply;
             for example, even if "example.com" is specified for
             deny-answer-aliases,
           
    
 
    www.example.com. CNAME xxx.example.com.
    
 
           
    
-            returned by an "example.com" server will be accepted.
+            returned by an "example.com" server is accepted.
           
    
 
           
    
@@ -7591,35 +7524,35 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
             ip_addr
             and ip_prefix
             are meaningful;
-            any key_id will be silently ignored.
+            any key_id is silently ignored.
           
    
 
           
    
             If a response message is rejected due to the filtering,
             the entire message is discarded without being cached, and
-            a SERVFAIL error will be returned to the client.
+            a SERVFAIL error is returned to the client.
           
    
 
           
    
             This filtering is intended to prevent "DNS rebinding attacks," in
             which an attacker, in response to a query for a domain name the
-            attacker controls, returns an IP address within your own network or
-            an alias name within your own domain.
+            attacker controls, returns an IP address within the user's own network or
+            an alias name within the user's 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.
+            to get access to an internal node of the local network
+            that could not be externally accessed otherwise.
             See the paper available at
-            
-            http://portal.acm.org/citation.cfm?id=1315245.1315298
+            
+            https://dl.acm.org/doi/10.1145/1315245.1315298
             
-            for more details about the attacks.
+            for more details about these attacks.
           
    
 
           
    
-            For example, if you own a domain named "example.net" and
-            your internal network uses an IPv4 prefix 192.0.2.0/24,
-            you might specify the following rules:
+            For example, with a domain named "example.net" and
+            an internal network using an IPv4 prefix 192.0.2.0/24,
+            an administrator might specify the following rules:
           
    
 
 
    deny-answer-addresses { 192.0.2.0/24; } except-from { "example.net"; };
@@ -7627,7 +7560,7 @@ deny-answer-aliases { "example.net"; };
 
    
 
           
    
-            If an external attacker lets a web browser in your local
+            If an external attacker let a web browser in the local
             network look up an IPv4 address of "attacker.example.com",
             the attacker's DNS server would return a response like this:
           
    
@@ -7637,35 +7570,35 @@ deny-answer-aliases { "example.net"; };
           
    
             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
+            the specified prefix 192.0.2.0/24, this response would be
             ignored.
           
    
 
           
    
-            On the other hand, if the browser looks up a legitimate
+            On the other hand, if the browser looked up a legitimate
             internal web server "www.example.net" and the
-            following response is returned to
-            the BIND 9 server
+            following response were returned to
+            the BIND 9 server:
           
    
 
 
    www.example.net. A 192.0.2.2
    
 
           
    
-            it will be accepted since the owner name "www.example.net"
+            it would be accepted, since the owner name "www.example.net"
             matches the except-from element,
             "example.net".
           
    
 
           
    
             Note that this is not really an attack on the DNS per se.
-            In fact, there is nothing wrong for an "external" name to
-            be mapped to your "internal" IP address or domain name
-            from the DNS point of view.
-            It might actually be provided for a legitimate purpose,
+            In fact, there is nothing wrong with having an "external" name
+            mapped to an "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
+            it either is not possible or does not make sense to detect
+            whether the intent of the mapping is legitimate
             within the DNS.
             The "rebinding" attack must primarily be protected at the
             application that uses the DNS.
@@ -7673,15 +7606,15 @@ deny-answer-aliases { "example.net"; };
             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.
+            turning it on is generally discouraged unless there is
+            no other choice and the attack is a
+            real threat to applications.
           
    
 
           
    
-            Care should be particularly taken if you want to use this
+            Care should be particularly taken if using this
             option for addresses within 127.0.0.0/8.
-            These addresses are obviously "internal", but many
+            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
@@ -7696,7 +7629,7 @@ deny-answer-aliases { "example.net"; };
           
    
             BIND 9 includes a limited
             mechanism to modify DNS responses for requests
-            analogous to email anti-spam DNS blacklists.
+            analogous to email anti-spam DNS rejection lists.
             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.
@@ -7705,7 +7638,7 @@ deny-answer-aliases { "example.net"; };
           
    
             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.
+            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
@@ -7726,9 +7659,9 @@ deny-answer-aliases { "example.net"; };
 
           
    
             Rules encoded in response policy zones are processed after
-            Access Control Lists
+            those defined in Access Control Lists
             (ACLs).  All queries from clients which are not
-            permitted access to the resolver will be answered with a
+            permitted access to the resolver are answered with a
             status code of REFUSED, regardless of configured RPZ rules.
           
    
 
@@ -7743,13 +7676,13 @@ deny-answer-aliases { "example.net"; };
                     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
+                    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-client-ip.
                     The IPv4 prefix length must be between 1 and 32.
-                    All four bytes, B4, B3, B2, and B1, must be present.
+                    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.
                   
    
@@ -7758,14 +7691,14 @@ deny-answer-aliases { "example.net"; };
                     IPv6 addresses are encoded in a format similar
                     to the standard IPv6 text representation,
                     prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-client-ip.
-                    Each of W8,...,W1 is a one to four digit hexadecimal number
+                    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
                     IP6.ARPA. (Note that this representation of IPv6
                     address is different from IP6.ARPA where each hex
                     digit occupies a label.)
                     All 8 words must be present except when one set of consecutive
-                    zero words is replaced with .zz.
+                    zero words is replaced with .zz.,
                     analogous to double colons (::) in standard IPv6 text
                     encodings.
                     The IPv6 prefix length must be between 1 and 128.
@@ -7786,7 +7719,7 @@ deny-answer-aliases { "example.net"; };
                   
    
                     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
+                    They are encoded like client-IP triggers, except as
                     subdomains of rpz-ip.
                   
    
                 
@@ -7795,13 +7728,37 @@ deny-answer-aliases { "example.net"; };
                   
    
                     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.
+                    the query name, or a parent of a CNAME.
                     They are encoded as subdomains of
-                    rpz-nsdname relativized
+                    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.
+                    policy records.  The
+                    nsdname-enable phrase turns NSDNAME
+                    triggers off or on for a single policy zone or for all
+                    zones.
+                  
    
+                
+                  
    
+                    If authoritative nameservers for the query name are not
+                    yet known, named recursively
+                    looks up the authoritative servers for the query name
+                    before applying an RPZ-NSDNAME rule,
+                    which can cause a processing delay. To speed up
+                    processing at the cost of precision, the
+                    nsdname-wait-recurse option
+                    can be used; when set to no,
+                    RPZ-NSDNAME rules are only applied when authoritative
+                    servers for the query name have already been looked up and
+                    cached.  If authoritative servers for the query name
+                    are not in the cache, the RPZ-NSDNAME rule is
+                    ignored, but the authoritative servers for the query name
+                    are looked up in the background and the rule is
+                    applied to subsequent queries. The default is
+                    yes, meaning RPZ-NSDNAME
+                    rules are always applied, even if authoritative
+                    servers for the query name need to be looked up first.
                   
    
                 
 
    RPZ-NSIP
    
@@ -7813,25 +7770,25 @@ deny-answer-aliases { "example.net"; };
                     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.
+                    1, to exclude top-level domains.
                   
    
                   
    
                     If a name server's IP address is not yet known,
-                    named will recursively look up
-                    the IP address before applying an RPZ-NSIP rule.
-                    This can cause a processing delay. To speed up
+                    named recursively looks up
+                    the IP address before applying an RPZ-NSIP rule,
+                    which can cause a processing delay. To speed up
                     processing at the cost of precision, the
                     nsip-wait-recurse option
                     can be used: when set to no,
-                    RPZ-NSIP rules will only be applied when a name
-                    servers's IP address has already been looked up and
+                    RPZ-NSIP rules are only applied when a name
+                    server's IP address has already been looked up and
                     cached.  If a server's IP address is not in the
-                    cache, then the RPZ-NSIP rule will be ignored,
-                    but the address will be looked up in the
-                    background, and the rule will be applied
+                    cache, the RPZ-NSIP rule is ignored,
+                    but the address is looked up in the
+                    background and the rule is applied
                     to subsequent queries.  The default is
                     yes, meaning RPZ-NSIP
-                    rules should always be applied even if an
+                    rules are always applied, even if an
                     address needs to be looked up first.
                   
    
                 
@@ -7845,7 +7802,7 @@ deny-answer-aliases { "example.net"; };
             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
+            Triggers, or the records that encode them, are chosen for
             rewriting in the following order:
             
    
 
      
@@ -7878,8 +7835,8 @@ deny-answer-aliases { "example.net"; };
           
      
 
           
      
-            RPZ record sets are any types of DNS record except
-            DNAME or DNSSEC that encode actions or responses to
+            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
@@ -7891,7 +7848,7 @@ deny-answer-aliases { "example.net"; };
 
      PASSTHRU
      
 
      
                   
      
-                    The whitelist policy is specified
+                    The auto-acceptance 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
@@ -7901,7 +7858,7 @@ deny-answer-aliases { "example.net"; };
 
      DROP
      
 
      
                   
      
-                    The blacklist policy is specified
+                    The auto-rejection 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.
@@ -7920,16 +7877,16 @@ deny-answer-aliases { "example.net"; };
 
      NXDOMAIN
      
 
      
                   
      
-                    The domain undefined response is encoded
+                    The "domain undefined" response is encoded
                     by a CNAME whose target is the root domain (.)
                   
      
                 
      
 
      NODATA
      
 
      
                   
      
-                    The empty set of resource records is specified by
+                    The empty set of resource records is specified by a
                     CNAME whose target is the wildcard top-level
-                    domain (*.).
+                    domain (*.).
                     It rewrites the response to NODATA or ANCOUNT=0.
                   
      
                 
      
@@ -7944,10 +7901,10 @@ deny-answer-aliases { "example.net"; };
                   
      
                     A special form of local data is a CNAME whose target is a
                     wildcard such as *.example.com.
-                    It is used as if were an ordinary CNAME after the asterisk (*)
+                    It is used as if an ordinary CNAME after the asterisk (*)
                     has been replaced with the query name.
-                    The purpose for this special form is query logging in the
-                    walled garden's authority DNS server.
+                    This special form is useful for query logging in the
+                    walled garden's authoritative DNS server.
                   
      
                 
 
    
@@ -7976,12 +7933,12 @@ deny-answer-aliases { "example.net"; };
                     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)
+                    The response to the DNS query is 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.
+                    because they are often not logged
+                    if a higher-precedence trigger is found first.
                   
    
                 
 
    
@@ -7989,7 +7946,7 @@ deny-answer-aliases { "example.net"; };
 
    
 
    
                   
    
-                    override with the corresponding per-record policy.
+                    each override the corresponding per-record policy.
                   
    
                 
    
 
    CNAME domain
    
@@ -8006,8 +7963,8 @@ deny-answer-aliases { "example.net"; };
           
    
             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
+            That default can be changed for a single policy zone, or for
+            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
@@ -8018,7 +7975,7 @@ deny-answer-aliases { "example.net"; };
           
    
             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
+            DNSSEC records are available for the requested 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
@@ -8028,27 +7985,27 @@ deny-answer-aliases { "example.net"; };
           
    
 
           
    
-            No DNS records are needed for a QNAME or Client-IP trigger.
-            The name or IP address itself is sufficient,
+            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
+            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
+            have slow authoritative servers, this 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
+            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
+            is in use, because the response would depend on whether
             RRSIG records were found during resolution.
             Using this option can cause error responses such as SERVFAIL to
             appear to be rewritten, since no recursion is being done to
@@ -8057,22 +8014,22 @@ deny-answer-aliases { "example.net"; };
 
           
    
             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
+            TTL of the relevant record in the policy zone.  It is then limited
             to a maximum value.
             The max-policy-ttl clause changes the
-            maximum seconds from its default of 5.
+            maximum number of seconds from its default of 5.
           
    
 
           
    
-            For example, you might use this option statement
+            For example, an administrator might use this option statement:
           
    
 
        response-policy { zone "badlist"; };
    
           
    
-            and this zone statement
+            and this zone statement:
           
    
 
        zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };
    
           
    
-            with this zone file
+            with this zone file:
           
    
 
    $TTL 1H
 @                       SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
@@ -8103,7 +8060,7 @@ ok.domain.com           CNAME   rpz-passthru.
 ns.domain.com.rpz-nsdname   CNAME   .
 48.zz.2.2001.rpz-nsip       CNAME   .
 
-; blacklist and whitelist some DNS clients
+; auto-reject and auto-accept some DNS clients
 112.zz.2001.rpz-client-ip    CNAME   rpz-drop.
 8.0.0.0.127.rpz-client-ip    CNAME   rpz-drop.
 
@@ -8119,12 +8076,12 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            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
+            A BIND 9 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.
+            maximum queries-per-second (QPS) 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.
           
    
@@ -8146,22 +8103,22 @@ example.com                 CNAME   rpz-tcp-only.
 Response Rate Limiting
 
           
    
-            Excessive almost identical UDP responses
+            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
+            to amplify 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.
+            Legitimate clients react to dropped or truncated responses
+            by retrying with UDP or with TCP, respectively.
           
    
 
           
    
             This mechanism is intended for authoritative DNS servers.
-            It can be used on recursive servers but can slow
+            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.
@@ -8171,13 +8128,13 @@ example.com                 CNAME   rpz-tcp-only.
           
    
             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
+            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
+            which defaults to 15 seconds, but which can be configured with
             the window option to any value from
             1 to 3600 seconds (1 hour).
             The account cannot become more positive than
@@ -8185,7 +8142,7 @@ example.com                 CNAME   rpz-tcp-only.
             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.
+            responses is set to 0, those responses are not rate-limited.
           
    
 
           
    
@@ -8193,7 +8150,7 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            The prefix lengths of address blocks are
             specified with ipv4-prefix-length (default 24)
             and ipv6-prefix-length (default 56).
           
    
@@ -8216,7 +8173,7 @@ example.com                 CNAME   rpz-tcp-only.
             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.
+            NXDOMAIN responses, such as from anti-spam rejection lists.
             Referrals or delegations to the server of a given
             domain are identical and are limited by
             referrals-per-second
@@ -8252,22 +8209,22 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            The small size and reduced frequency, and resulting 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 0 does not "slip";
+            no truncated responses are sent due to rate limiting.
+            Rather, 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
+            values between 2 and 10 cause every nth 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
+            (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
@@ -8281,11 +8238,11 @@ example.com                 CNAME   rpz-tcp-only.
           
    
 
           
    
-            When the approximate query per second rate exceeds
+            When the approximate query-per-second rate exceeds
             the qps-scale value,
-            then the responses-per-second,
+            the responses-per-second,
             errors-per-second,
-            nxdomains-per-second and
+            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.
@@ -8294,19 +8251,19 @@ example.com                 CNAME   rpz-tcp-only.
             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.
+            (250/1000)*20, or 5.
             Responses sent via TCP are not limited
-            but are counted to compute the query per second rate.
+            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
+            statements instead of in the global option
             statement.
             A rate-limit statement in a view replaces,
-            rather than supplementing, a rate-limit
+            rather than supplements, a rate-limit
             statement among the main options.
             DNS clients within a view can be exempted from rate limits
             with the exempt-clients clause.
@@ -8318,7 +8275,7 @@ example.com                 CNAME   rpz-tcp-only.
             limiting is unlike the rate limiting provided by
             responses-per-second,
             errors-per-second, and
-            nxdomains-per-second on a DNS server
+            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
@@ -8333,11 +8290,11 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            as it considers the SMTP Mail From
             command.  Web browsers often repeatedly resolve the
-            same names that are repeated in HTML <IMG> tags
+            same names that are duplicated in HTML <IMG> tags
             in a page.  all-per-second is similar
-            to the rate limiting offered by firewalls but often
+            to the rate limiting offered by firewalls but is 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
@@ -8348,7 +8305,7 @@ example.com                 CNAME   rpz-tcp-only.
 
           
    
             The maximum size of the table used to track requests and
-            rate limit responses is set with max-table-size.
+            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.
@@ -8362,7 +8319,7 @@ example.com                 CNAME   rpz-tcp-only.
           
    
 
           
    
-            Use log-only yes to test rate limiting parameters
+            Use log-only yes to test rate-limiting parameters
             without actually dropping any requests.
           
    
 
@@ -8376,9 +8333,10 @@ example.com                 CNAME   rpz-tcp-only.
         
 
         
    
-
    
+
    
+NXDOMAIN Redirection
    
           
    
-            Named supports NXDOMAIN redirection via two methods:
+            named supports NXDOMAIN redirection via two methods:
             
    
 
      
 
    • Redirect zone the section called “zone
@@ -8389,7 +8347,7 @@ example.com                 CNAME   rpz-tcp-only.
 
      
           
      
           
      
-            With both methods when named gets a NXDOMAIN response
+            With either method, when named gets an NXDOMAIN response
             it examines a separate namespace to see if the NXDOMAIN
             response should be replaced with an alternative response.
           
      
@@ -8402,13 +8360,13 @@ example.com                 CNAME   rpz-tcp-only.
           
      
           
      
             With a redirect namespace (option { nxdomain-redirect
-            <suffix> };) the data used to replace the
+            <suffix> };), the data used to replace the
             NXDOMAIN is part of the normal namespace and is looked up by
             appending the specified suffix to the original query name.
             This roughly doubles the cache required to process NXDOMAIN
-            responses as you have the original NXDOMAIN response and
-            the replacement data or a NXDOMAIN indicating that there
-            is no replacement.
+            responses, as both the original NXDOMAIN response and
+            the replacement data (or a NXDOMAIN indicating that there
+            is no replacement) must be stored.
           
      
           
      
             If both a redirect zone and a redirect namespace are configured,
@@ -8465,7 +8423,7 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            server clause applies, regardless of the order in
             named.conf.
           
      
 
@@ -8486,22 +8444,22 @@ example.com                 CNAME   rpz-tcp-only.
           
      
 
           
      
-            If you discover that a remote server is giving out bad data,
-            marking it as bogus will prevent further queries to it. The
+            If a remote server is giving out bad data,
+            marking it as bogus prevents 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
+            the local server, acting as primary, responds with an
             incremental
-            zone transfer when the given remote server, a slave, requests it.
+            zone transfer when the given remote server, a secondary, requests it.
             If set to yes, incremental transfer
-            will be provided
+            is provided
             whenever possible. If set to no,
             all transfers
-            to the remote server will be non-incremental. If not set, the
+            to the remote server are non-incremental. If not set, the
             value
             of the provide-ixfr option in the
             view or
@@ -8511,16 +8469,16 @@ example.com                 CNAME   rpz-tcp-only.
           
      
             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
+            the local server, acting as a secondary, requests incremental zone
+            transfers from the given remote server, a primary. 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.
+            also be set in the zone block; if set there, it
+            overrides the global or view setting for that zone.
           
      
 
           
      
-            IXFR requests to servers that do not support IXFR will
+            IXFR requests to servers that do not support IXFR
             automatically
             fall back to AXFR.  Therefore, there is no need to manually list
             which servers support IXFR and which ones do not; the global
@@ -8529,17 +8487,17 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            primary
+            and secondary claim to support it: for example, if one of the servers
             is buggy and crashes or corrupts data when IXFR is used.
           
      
 
           
      
             The request-expire clause determines
-            whether the local server, when acting as a slave, will
-            request the EDNS EXPIRE value.  The EDNS EXPIRE value
-            indicates the remaining time before the zone data will
-            expire and need to be be refreshed.  This is used
+            whether the local server, when acting as a secondary,
+            requests the EDNS EXPIRE value.  The EDNS EXPIRE value
+            indicates the remaining time before the zone data
+            expires and needs to be refreshed.  This is used
             when a secondary server transfers a zone from another
             secondary server; when transferring from the primary, the
             expiration timer is set from the EXPIRE field of the SOA
@@ -8549,7 +8507,7 @@ example.com                 CNAME   rpz-tcp-only.
 
           
      
             The edns clause determines whether
-            the local server will attempt to use EDNS when communicating
+            the local server attempts to use EDNS when communicating
             with the remote server.  The default is yes.
           
      
 
@@ -8557,44 +8515,44 @@ example.com                 CNAME   rpz-tcp-only.
             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 to the nearest value within it).  This option
-            is useful when you wish to advertise a different value
-            to this server than the value you advertise globally,
+            to 4096 bytes; values outside this range are silently
+            adjusted to the nearest value within it.  This option
+            is useful when advertising a different value
+            to this server than the value advertised globally:
             for example, when there is a firewall at the remote
-            site that is blocking large replies. (Note: Currently,
+            site that is blocking large replies. Note: currently,
             this sets a single UDP size for all packets sent to the
-            server; named will not deviate from
+            server; named does not deviate from
             this value.  This differs from the behavior of
             edns-udp-size in options
             or view statements, where it specifies
             a maximum value. The server statement
             behavior may be brought into conformance with the
-            options/view behavior in future releases.)
+            options/view behavior in future releases.
           
      
 
           
      
             The edns-version option sets the
-            maximum EDNS VERSION that will be sent to the server(s)
+            maximum EDNS VERSION that is sent to the server(s)
             by the resolver.  The actual EDNS version sent is still
-            subject to normal EDNS version negotiation rules (see
+            subject to normal EDNS version-negotiation rules (see
             RFC 6891), the maximum EDNS version supported by the
             server, and any other heuristics that indicate that a
             lower version should be sent.  This option is intended
             to be used when a remote server reacts badly to a given
             EDNS version or higher; it should be set to the highest
             version the remote server is known to support.  Valid
-            values are 0 to 255; higher values will be silently
-            adjusted.  This option will not be needed until higher
+            values are 0 to 255; higher values are silently
+            adjusted.  This option is not needed until higher
             EDNS versions than 0 are in use.
           
      
 
           
      
             The max-udp-size option sets the
             maximum EDNS UDP message size named
-            will send.  Valid values are 512 to 4096 bytes (values
-            outside this range will be silently adjusted).  This
-            option is useful when you know that there is a firewall
+            sends.  Valid values are 512 to 4096 bytes; values
+            outside this range are silently adjusted.  This
+            option is useful when there is a firewall
             that is blocking large replies from named.
           
      
 
@@ -8608,15 +8566,12 @@ example.com                 CNAME   rpz-tcp-only.
           
      
             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
+            as many resource records as possible into a single message, which is
+            more efficient. It is possible to specify which method
+            to use for a server via the transfer-format option;
+            If not set there, the transfer-format
             specified
-            by the options statement will be
+            by the options statement is
             used.
           
      
 
@@ -8634,7 +8589,7 @@ example.com                 CNAME   rpz-tcp-only.
             to be used for transaction security (TSIG,       the section called “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
+            is 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.
@@ -8648,8 +8603,7 @@ example.com                 CNAME   rpz-tcp-only.
             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.
+            address, respectively, to be used for zone transfer with the remote server.
             For an IPv4 remote server, only transfer-source can
             be specified.
             Similarly, for an IPv6 remote server, only
@@ -8664,8 +8618,8 @@ example.com                 CNAME   rpz-tcp-only.
           
      
             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 and IPv6 source address, respectively, to be used for notify
+            messages sent to remote servers.  For an
             IPv4 remote server, only notify-source
             can be specified.  Similarly, for an IPv6 remote server,
             only notify-source-v6 can be specified.
@@ -8674,8 +8628,8 @@ example.com                 CNAME   rpz-tcp-only.
           
      
             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
+            IPv4 and IPv6 source address, respectively, to be used for queries
+            sent to remote servers.  For an IPv4
             remote server, only query-source can
             be specified.  Similarly, for an IPv6 remote server,
             only query-source-v6 can be specified.
@@ -8683,7 +8637,7 @@ example.com                 CNAME   rpz-tcp-only.
 
           
      
             The request-nsid clause determines
-            whether the local server will add a NSID EDNS option
+            whether the local server adds an NSID EDNS option
             to requests sent to the server.  This overrides
             request-nsid set at the view or
             option level.
@@ -8691,7 +8645,7 @@ example.com                 CNAME   rpz-tcp-only.
 
           
      
             The send-cookie clause determines
-            whether the local server will add a COOKIE EDNS option
+            whether the local server adds a COOKIE EDNS option
             to requests sent to the server.  This overrides
             send-cookie set at the view or
             option level.  The named server may
@@ -8721,19 +8675,19 @@ example.com                 CNAME   rpz-tcp-only.
         
      
           The statistics-channels statement
           declares communication channels to be used by system
-          administrators to get access to statistics information of
+          administrators to get access to statistics information on
           the name server.
         
      
 
         
      
-          This statement intends to be flexible to support multiple
+          This statement is intended 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.
+          but any HTTP access fails with an error.
         
      
 
         
      
@@ -8742,7 +8696,7 @@ example.com                 CNAME   rpz-tcp-only.
           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
+          interpreted as the IPv4 wildcard address; connections are
           accepted on any of the system's IPv4 addresses.
           To listen on the IPv6 wildcard address,
           use an ip_addr of ::.
@@ -8750,12 +8704,12 @@ example.com                 CNAME   rpz-tcp-only.
 
         
      
           If no port is specified, port 80 is used for HTTP channels.
-          The asterisk "*" cannot be used for
+          The asterisk (*) cannot be used for
           ip_port.
         
      
 
         
      
-          The attempt of opening a statistics channel is
+          Attempts to open a statistics channel are
           restricted by the optional allow clause.
           Connections to the statistics channel are permitted based on the
           address_match_list.
@@ -8769,20 +8723,20 @@ example.com                 CNAME   rpz-tcp-only.
 
         
      
           If no statistics-channels statement is present,
-          named will not open any communication channels.
+          named does not open any communication channels.
         
      
 
         
      
-          The statistics are available in various formats and views
+          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
+          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.
+          JavaScript-capable browser.
         
      
 
         
      
@@ -8844,31 +8798,31 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            key, it is treated as if it has 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
+            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.
+            is not used.
           
      
           
      
             The trusted-keys statement can contain
             multiple key entries, each consisting of the key's
-            domain name, flags, protocol, algorithm, and the Base64
+            domain name, flags, protocol, and algorithm, and the Base64
             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
+            Spaces, tabs, newlines, and carriage returns are ignored
+            in the key data, so the configuration may be split 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
+            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.
           
      
@@ -8895,7 +8849,7 @@ example.com                 CNAME   rpz-tcp-only.
             The managed-keys statement, like
             trusted-keys, defines DNSSEC
             security roots.  The difference is that
-            managed-keys can be kept up to date
+            managed-keys can be kept up-to-date
             automatically, without intervention from the resolver
             operator.
           
      
@@ -8904,19 +8858,19 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            unable to validate this zone; it would
             reply with a SERVFAIL response code.  This would
-            continue until the resolver operator had updated the
+            continue until the resolver operator updated the
             trusted-keys statement with the new key.
           
      
           
      
             If, however, the zone were listed in a
-            managed-keys statement instead, then the
+            managed-keys statement instead, 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
+            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.
           
      
@@ -8933,15 +8887,15 @@ example.com                 CNAME   rpz-tcp-only.
           
      
           
      
             Consequently, a managed-keys statement
-            appears similar to a trusted-keys, differing
-            in the presence of the second field, containing the keyword
+            appears similar to a trusted-keys statement, differing
+            by the presence of the second field, which contains 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
+            managed-key database and start the RFC 5011 key-maintenance
             process.
           
      
           
      
@@ -8950,58 +8904,58 @@ example.com                 CNAME   rpz-tcp-only.
             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.
+            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
+            for the specified domain, and if so, simply moves on.  The
             key specified in the managed-keys
-            statement is not used to validate answers; it has been
-            superseded by the key or keys stored in the managed keys database.
+            statement is not used to validate answers; it is
+            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
+            zone is removed from the managed-keys database,
+            and RFC 5011 key maintenance is no longer used for that
             domain.
           
      
           
      
-            In the current implementation, the managed keys database
+            In the current implementation, the managed-keys database
             is stored as a master-format zone file.
           
      
           
      
             On servers which do not use views, this file is named
             managed-keys.bind.  When views are in
-            use, there will be a separate managed keys database for each
-            view; the filename will be the view name (or, if a view name
+            use, there is a separate managed-keys database for each
+            view; the filename is the view name (or, if a view name
             contains characters which would make it illegal as a filename,
             a hash of the view name), followed by
             the suffix .mkeys.
           
      
           
      
             When the key database is changed, the zone is updated.
-            As with any other dynamic zone, changes will be written
+            As with any other dynamic zone, changes are written
             into a journal file, e.g.,
             managed-keys.bind.jnl or
             internal.mkeys.jnl.
-            Changes are committed to the master file as soon as
-            possible afterward; this will usually occur within 30
-            seconds.  So, whenever named is using
+            Changes are committed to the zone file as soon as
+            possible afterward, usually within 30
+            seconds.  Whenever named is using
             automatic key maintenance, the zone file and journal file
             can be expected to exist in the working directory.
-            (For this reason among others, 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.  The key that is used to initialize the key
-            maintenance process is stored in bind.keys;
+            automatically initializes a managed key for the
+            root zone.  The key that is used to initialize the
+                key-maintenance process is stored in bind.keys;
             the location of this file can be overridden with the
             bindkeys-file option. As a fallback
             in the event no bind.keys can be
@@ -9041,7 +8995,7 @@ example.com                 CNAME   rpz-tcp-only.
           
      
             Each view statement defines a view
             of the
-            DNS namespace that will be seen by a subset of clients.  A client
+            DNS namespace that is 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
@@ -9053,26 +9007,26 @@ example.com                 CNAME   rpz-tcp-only.
             specified, both
             match-clients and match-destinations
             default to matching all addresses.  In addition to checking IP
-            addresses
+            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.
+            requests from matching clients match that view.
             The order of the view statements is
-            significant —
-            a client request will be resolved in the context of the first
+            significant;
+            a client request is 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.
+            statement are
+            only 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,
+            zone data can be given to different clients: for example,
             "internal"
             and "external" clients in a split DNS setup.
           
      
@@ -9092,7 +9046,7 @@ example.com                 CNAME   rpz-tcp-only.
           
      
 
           
      
-            Views are class specific.  If no class is given, class IN
+            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.
           
      
@@ -9107,8 +9061,8 @@ example.com                 CNAME   rpz-tcp-only.
             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
+            statement
+            applies to the default view. If any explicit view
             statements are present, all zone
             statements must
             occur inside view statements.
@@ -9371,12 +9325,20 @@ view "external" {
               The type keyword is required
               for the zone configuration unless
               it is an in-view configuration. Its
-              acceptable values include: delegation-only,
-              forward, hint,
-              master, redirect,
-              slave, static-stub,
-              and stub.
+              acceptable values are: master,
+              slave, hint,
+              stub, static-stub,
+              forward, redirect,
+              or delegation-only.
             
      
+            
      
+
      Note
      
+              Later versions of BIND added type primary
+              and type secondary as synonyms for
+              type master and type slave,
+              as those terms are in more common use now. BIND 9.11's
+              configuration syntax predates this change.
+            
      
 
             
      
               
@@ -9394,9 +9356,8 @@ view "external" {
 
@@ -9408,10 +9369,11 @@ view "external" {
                     
+
+
+
+
@@ -9561,53 +9535,32 @@ view "external" {
                     
-
-
-
-
@@ -9673,13 +9626,13 @@ view "external" {
                     
+
+
+
+
      
                       
      
                         The server has a master copy of the data
-                        for the zone and will be able to provide authoritative
-                        answers for
-                        it.
+                        for the zone and is able to provide authoritative
+                        answers for it.
                       
      
                           		
 
      
 
      
                       
      
-                        A slave zone is a replica of a master
-                        zone. The masters list
+                        A secondary zone, replicating a primary zone
+                        provided by another authoritative server.
+                        The masters list
                         specifies one or more IP addresses
-                        of master servers that the slave contacts to update
+                        of primary servers that the secondary contacts to update
                         its copy of the zone.
                         Masters list elements can also be names of other
                         masters lists.
@@ -9421,10 +9383,10 @@ view "external" {
                         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
+                        Authentication to the primary 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
+                        replica is written to this file whenever the zone
                         is changed,
                         and reloaded from this file on a server restart. Use
                         of a file is
@@ -9436,17 +9398,38 @@ view "external" {
                         is best to
                         use a two-level naming scheme for zone filenames. For
                         example,
-                        a slave server for the zone example.com might place
+                        a secondary 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
+                        behave very slowly if there are 100000 files in
                         a single directory.)
                       
      
                           		
 
      
 
      
+                      
      
+                        hint
+                      
      
+                          		
+                      
      
+                        The initial set of root name servers is
+                        specified using a hint zone. When the server starts,
+                        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 default hints.
+                      
      
+                    
      
 
                       
      
                         stub
@@ -9454,34 +9437,25 @@ view "external" {
                     
      		
 
                       
      
-                        A stub zone is similar to a slave zone,
+                        A stub zone is similar to a secondary zone,
                         except that it replicates only the NS records of a
-                        master zone instead
+                        primary 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
+                        Stub zones can be used to eliminate the need for a glue
                         NS record
-                        in a parent zone at the expense of maintaining a stub
+                        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
+                        If a BIND 9 primary, serving a parent
+                        zone, has child stub zones configured, all the secondary
                         servers for the
                         parent zone also need to have the same child stub
                         zones
@@ -9489,13 +9463,13 @@ view "external" {
                       
      
 
                       
      
-                        Stub zones can also be used as a way of forcing the
+                        Stub zones can also be used as a way to force 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
+                        RFC 1918 addressing may be configured with stub zones
                         for
                         10.in-addr.arpa
                         to use a set of internal name servers as the
@@ -9515,11 +9489,11 @@ view "external" {
                         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;
+                        than transferred from a primary server; and
                         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
+                        configured data (name server names and glue addresses)
+                        is always used, even if different authoritative
                         information is cached.
                       
      
                       
      
@@ -9534,9 +9508,9 @@ view "external" {
                         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
+                        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.
+                        prohibited and are responded to with REFUSED.
                       
      
                       
      
                         Since the data is statically configured, no
@@ -9549,7 +9523,7 @@ view "external" {
                       
      
                         Each static-stub zone is configured with
                         internally generated NS and (if necessary)
-                        glue A or AAAA RRs
+                        glue A or AAAA RRs.
                       
      
                           		
 
      
 
      
                       
      
-                        A "forward zone" is a way to configure
+                        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
+                        which applies to queries within the domain given by
                         the zone
                         name. If no forwarders
-                        statement is present or
+                        statement is present, or
                         an empty list for forwarders is given, then no
-                        forwarding will be done for the domain, canceling the
+                        forwarding is 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
+                        any forwarders in the options statement. Thus,
+                        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
+                        to, then "forward only", or vice versa), but
                         use the same
-                        servers as set globally) you need to re-specify the
+                        servers as set globally, 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
@@ -9624,26 +9577,26 @@ view "external" {
                       
      
                       
      
                         If the client has requested DNSSEC records (DO=1) and
-                        the NXDOMAIN response is signed then no substitution
-                        will occur.
+                        the NXDOMAIN response is signed, no substitution
+                        occurs.
                       
      
                       
      
                         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 ".",
+                        2001:ffff:ffff::100.100.100.2,
+                        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"
+                        *. IN A 100.100.100.2
                         and
-                        "*. IN AAAA 2001:ffff:ffff::100.100.100.2".
+                        *. 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
+                        As another example, to redirect all Spanish names (under .ES),
+                        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.".
+                        commercial Spanish names (under COM.ES),
+                        use wildcard entries called "*.COM.ES.".
                       
      
                       
      
                         Note that the redirect zone supports all
@@ -9653,14 +9606,14 @@ view "external" {
                       
      
                         Because redirect zones are not referenced
                         directly by name, they are not kept in the
-                        zone lookup table with normal master and slave
+                        zone lookup table with normal primary and secondary
                         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
+                        a zone name, redirect zones are reloaded along
                         with other zones.
                       
      
                           		
 
                       
      
-                        This is used to enforce the delegation-only
-                        status of infrastructure zones (e.g. COM,
+                        This zone type 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
+                        in the authority section is treated
                         as NXDOMAIN.  This does not apply to the
-                        zone apex.  This should not be applied to
+                        zone apex, and should not be applied to
                         leaf zones.
                       
      
                       
      
@@ -9691,6 +9644,32 @@ view "external" {
                       
      
                           		
 
      
+                      
      
+                        in-view
+                      
      
+                          		
+                      
      
+                        When using multiple views, a primary or secondary zone
+                        configured in one view can be referenced in a
+                        subsequent view. This allows both views to serve the
+                        same zone without the overhead of loading it more
+                        than once. This is configured using a
+                        zone statement, with an
+                        in-view option specifying the
+                        view in which the zone is defined.
+                        A zone statement containing
+                        in-view does not need to specify
+                        a type, since that is part of the zone definition
+                        in the other view.
+                      
      
+                      
      
+                        See the section called “Multiple Views” for more information.
+                      
      
+                    
      
       
 
      
             
      
@@ -9707,10 +9686,9 @@ view "external" {
             
      
             
      
               The hesiod class is
-              named for an information service from MIT's Project Athena. It
-              is
+              named for an information service from MIT's Project Athena. It was
               used to share information about various systems databases, such
-              as users, groups, printers and so on. The keyword
+              as users, groups, printers, and so on. The keyword
               HS is
               a synonym for hesiod.
             
      
@@ -9763,7 +9741,7 @@ view "external" {
 
      update-policy
      
 
      
                   
      
-                    Specifies a "Simple Secure Update" policy. See
+                    This specifies a "Simple Secure Update" policy. See
                     the section called “Dynamic Update Policies”.
                   
      
                 
      
@@ -9777,14 +9755,14 @@ view "external" {
 
      also-notify
      
 
      
                   
      
-                    Only meaningful if notify
+                    This option is only meaningful if notify
                     is
-                    active for this zone. The set of machines that will
+                    active for this zone. The set of machines that
                     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
+                    the primary) for the zone, plus any IP addresses
                     specified
                     with also-notify. A port
                     may be specified
@@ -9804,10 +9782,11 @@ view "external" {
                   
      
                     This option is used to restrict the character set and
                     syntax of
-                    certain domain names in master files and/or DNS responses
+                    certain domain names in zone 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.
+                    network.  The default varies according to zone type.
+                    For primary zones the default is fail;
+                    for secondary zones the default is warn.
                     It is not implemented for hint zones.
                   
      
                 
      
@@ -9893,7 +9872,7 @@ view "external" {
 
      database
      
 
      
                   
      
-                    Specify the type of database to be used for storing the
+                    This specifies the type of database to be used to store the
                     zone data.  The string following the database keyword
                     is interpreted as a list of whitespace-delimited words.
                     The first word
@@ -9906,7 +9885,7 @@ view "external" {
                   
      
                     The default is "rbt", BIND 9's
                     native in-memory
-                    red-black-tree database.  This database does not take
+                    red-black tree database.  This database does not take
                     arguments.
                   
      
                   
      
@@ -9926,9 +9905,9 @@ view "external" {
 
      delegation-only
      
 
      
                   
      
-                    The flag only applies to forward, hint and stub
+                    This flag only applies to forward, hint, and stub
                     zones.  If set to yes,
-                    then the zone will also be treated as if it is
+                    then the zone is treated as if it is
                     also a delegation-only type zone.
                   
      
                   
      
@@ -9938,7 +9917,7 @@ view "external" {
 
      file
      
 
      
                   
      
-                    Set the zone's filename. In master,
+                    This sets the zone's filename. In master,
                     hint, and redirect
                     zones which do not have masters
                     defined, zone data is loaded from this file. In
@@ -9952,17 +9931,17 @@ view "external" {
 
      forward
      
 
      
                   
      
-                    Only meaningful if the zone has a forwarders
+                    This option is 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.
+                    after trying the forwarders and getting no answer, while first
+                    allows a normal lookup to be tried.
                   
      
                 
      
 
      forwarders
      
 
      
                   
      
-                    Used to override the list of global forwarders.
+                    This is 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.
@@ -9971,7 +9950,7 @@ view "external" {
 
      ixfr-base
      
 
      
                   
      
-                    Was used in BIND 8 to
+                    This was used in BIND 8 to
                     specify the name
                     of the transaction log (journal) file for dynamic update
                     and IXFR.
@@ -9985,30 +9964,31 @@ view "external" {
 
      ixfr-tmp-file
      
 
      
                   
      
-                    Was an undocumented option in BIND 8.
-                    Ignored in BIND 9.
+                    This was an undocumented option in BIND 8.
+                    It is ignored in BIND 9.
                   
      
                 
      
 
      journal
      
 
      
                   
      
-                    Allow the default journal's filename to be overridden.
+                    This allows 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.
+                    This is applicable to primary (master)
+                    and secondary (slave) zones.
                   
      
                 
      
 
      max-journal-size
      
 
      
                   
      
                     See the description of
-                    max-journal-size in the section called “Server  Resource Limits”.
+                    max-journal-size in the section called “Server Resource Limits”.
                   
      
                 
      
 
      max-records
      
 
      
                   
      
                     See the description of
-                    max-records in the section called “Server  Resource Limits”.
+                    max-records in the section called “Server Resource Limits”.
                   
      
                 
      
 
      max-transfer-time-in
      
@@ -10065,10 +10045,9 @@ view "external" {
 
      
                   
      
                     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
+                    intended to specify
+                    a public zone key for verification of signatures in DNSSEC-signed
+                    zones when they were loaded from disk. BIND 9 does not verify signatures
                     on load and ignores the option.
                   
      
                 
      
@@ -10084,73 +10063,75 @@ view "external" {
 
      server-addresses
      
 
      
                   
      
-                    Only meaningful for static-stub zones.
+                    This option is 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
+                    A non-empty list for this option internally
+                    configures 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.
+                    the following RRs are 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
+                    These records are used internally 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
+                    initiates recursive resolution and sends
                     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
+                    This option is only meaningful for static-stub zones.
+                    This is a list of domain names of name servers that
                     act as authoritative servers of the static-stub
                     zone.
-                    These names will be resolved to IP addresses when
+                    These names are resolved to IP addresses when
                     named needs to send queries to
                     these servers.
-                    To make this supplemental resolution successful,
+                    For this supplemental resolution to be successful,
                     these names must not be a subdomain of the origin
-                    name of static-stub zone.
+                    name of the 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
+                    "ns.example.net" cannot; it is rejected by
                     the configuration parser.
                   
      
                   
      
-                    A non empty list for this option will internally
-                    configure the apex NS RR with the specified names.
+                    A non-empty list for this option internally
+                    configures 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.
+                    the following RRs are internally configured:
                   
      
+
 
      example.com. NS ns1.example.net.
 example.com. NS ns2.example.net.
 
      
+
                   
      
-                    These records are internally used to resolve
+                    These records are used internally 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.
+                    initiates recursive resolution,
+                    resolves "ns1.example.net" and/or
+                    "ns2.example.net" to IP addresses, and then sends
+                    queries to one or more of these addresses.
                   
      
                 
      
 
      sig-validity-interval
      
@@ -10235,7 +10216,7 @@ example.com. NS ns2.example.net.
 
 
      
                   
      
-                    See the description in the section called “Tuning”.
+                    See the descriptions in the section called “Tuning”.
                   
      
                 
      
 
      ixfr-from-differences
      
@@ -10244,8 +10225,8 @@ example.com. NS ns2.example.net.
                     See the description of
                     ixfr-from-differences in the section called “Boolean Options”.
                     (Note that the ixfr-from-differences
-                    master and
-                    slave choices are not
+                    choices of master and
+                    slave are not
                     available at the zone level.)
                   
      
                 
@@ -10279,10 +10260,10 @@ example.com. NS ns2.example.net.
 
      
                   
      
                     If yes, this enables
-                    "bump in the wire" signing of a zone, where a
+                    "bump in the wire" signing of a zone, where an
                     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
+                    with, possibly, a different serial number.  This
                     behavior is disabled by default.
                   
      
                 
      
@@ -10322,11 +10303,11 @@ example.com. NS ns2.example.net.
 
      
 Dynamic Update Policies
      
 
-            
      BIND 9 supports two alternative
+            
      BIND 9 supports two
               methods of granting clients the right to perform
               dynamic updates to a zone, configured by the
               allow-update and
-              update-policy option, respectively.
+              update-policy options.
             
      
             
      
               The allow-update clause is a simple
@@ -10336,12 +10317,12 @@ example.com. NS ns2.example.net.
             
      
             
      
               The update-policy clause
-              allows more fine-grained control over what updates are
+              allows more fine-grained control over which updates are
               allowed.  It specifies a set of rules, in which each rule
               either grants or denies permission for one or more
               names in the zone to be updated by one or more
               identities. Identity is determined by the key that
-              signed the update request using either TSIG or SIG(0).
+              signed the update request, using either TSIG or SIG(0).
               In most cases, update-policy rules
               only apply to key-based identities.  There is no way
               to specify update permissions based on client source
@@ -10349,7 +10330,7 @@ example.com. NS ns2.example.net.
             
      
             
      
               update-policy rules are only meaningful
-              for zones of type master, and are
+              for primary zones (type master), and are
               not allowed in any other zone type.
               It is a configuration error to specify both
               allow-update and
@@ -10368,12 +10349,12 @@ example.com. NS ns2.example.net.
               is "local-ddns", and the key algorithm is HMAC-SHA256.
               These values are configurable with the
               session-keyfile,
-              session-keyname and
+              session-keyname, and
               session-keyalg options, respectively.
               A client running on the local system, if run with appropriate
               permissions, may read the session key from the key file and
               use it to sign update requests.  The zone's update
-              policy will be set to allow that key to change any record
+              policy is set to allow that key to change any record
               within the zone.  Assuming the key name is "local-ddns",
               this policy is equivalent to:
             
      
@@ -10382,14 +10363,14 @@ example.com. NS ns2.example.net.
             
    
 
             
    
-              ...with the additional restriction that only clients
-              connecting from the local system will be permitted to send
+              with the additional restriction that only clients
+              connecting from the local system are permitted to send
               updates.
             
    
             
    
               Note that only one session key is generated by
               named; all zones configured to use
-              update-policy local will accept the same key.
+              update-policy local accept the same key.
             
    
             
    
               The command nsupdate -l implements this
@@ -10427,13 +10408,13 @@ example.com. NS ns2.example.net.
             
    
             
    
               The identity field must be set to
-              a fully-qualified domain name.  In most cases, this
-              represensts the name of the TSIG or SIG(0) key that must be
+              a fully qualified domain name.  In most cases, this
+              represents the name of the TSIG or SIG(0) key that must be
               used to sign the update request.  If the specified name is a
               wildcard, it is subject to DNS wildcard expansion, and the
               rule may apply to multiple identities.  When a TKEY exchange
               has been used to create a shared secret, the identity of
-              the key used to authenticate the TKEY exchange will be
+              the key used to authenticate the TKEY exchange is
               used as the identity of the shared secret.  Some rule types
               use identities matching the client's Kerberos principal
               (e.g, "host/machine@REALM") or
@@ -10441,16 +10422,16 @@ example.com. NS ns2.example.net.
             
    
             
    
               The name field also specifies
-              a fully-qualified domain name. This often
+              a fully qualified domain name. This often
               represents the name of the record to be updated.
               Interpretation of this field is dependent on rule type.
             
    
             
    
               If no types are explicitly specified,
-              then a rule matches all types except RRSIG, NS, SOA, NSEC
+              then a 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
+              "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.
             
    
@@ -10458,14 +10439,13 @@ example.com. NS ns2.example.net.
               The ruletype field has 16
               values:
               name, subdomain,
-              wildcard, self,
-              selfsub, selfwild,
-              krb5-self, ms-self,
-              krb5-selfsub, ms-selfsub,
-              krb5-subdomain,
-              ms-subdomain,
-              tcp-self, 6to4-self,
-              zonesub, and external.
+              zonesub, wildcard,
+                  self, selfsub,
+                  selfwild, ms-self,
+              ms-selfsub, ms-subdomain,
+              krb5-self, krb5-selfsub,
+              krb5-subdomain, tcp-self,
+                  6to4-self, and external.
             
    
             
    
               
@@ -10482,7 +10462,7 @@ example.com. NS ns2.example.net.
                     
@@ -10578,7 +10558,7 @@ example.com. NS ns2.example.net.
                     
@@ -10690,13 +10670,13 @@ example.com. NS ns2.example.net.
                       
    
                         When a client sends an UPDATE using a
                         Kerberos machine principal (for example,
-                        'host/machine@REALM'), this rule allows
-                        records with the absolute name of 'machine'
-                        to be updated provided it has been authenticated
+                        "host/machine@REALM"), this rule allows
+                        records with the absolute name of "machine"
+                        to be updated, provided it has been authenticated
                         by REALM.  This is similar but not identical
-                        to ms-self due to the
-                        'machine' part of the Kerberos principal
-                        being an absolute name instead of a unqualified
+                        to ms-self, due to the
+                        "machine" part of the Kerberos principal
+                        being an absolute name instead of an unqualified
                         name.
                       
    
@@ -10725,9 +10705,9 @@ example.com. NS ns2.example.net.
                     
 
    
@@ -10743,7 +10723,7 @@ example.com. NS ns2.example.net.
                         This rule is identical to
                         ms-subdomain, except that it works
                         with Kerberos machine principals (i.e.,
-                        'host/machine@REALM') rather than Windows machine
+                        "host/machine@REALM") rather than Windows machine
                         principals.
                       
    
@@ -10761,7 +10741,7 @@ example.com. NS ns2.example.net.
                         client's IP address into the
                         in-addr.arpa and
                         ip6.arpa
-                        namespaces match the name to be updated.
+                        namespaces matches the name to be updated.
                         The identity field must match
                         that name.  The name field
                         should be set to ".".
@@ -10834,12 +10814,12 @@ example.com. NS ns2.example.net.
                         field, the format of which is
                         "local:path",
                         where path is the location
-                        of a UNIX-domain socket.  (Currently, "local" is the
+                        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
+                        Unix-domain socket as datagrams with the following
                         format:
                       
    @@ -10867,17 +10847,17 @@ example.com. NS ns2.example.net.
 
           
    
 
    
-Multiple views
    
+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
+              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
+              way to do this; it allows a view to reference a zone that
               was defined in a previously configured view. Example:
             
    
             
    @@ -10905,16 +10885,16 @@ view external {
             
    
               A zone statement which uses the
               in-view option may not use any other
-              options with the exception of forward
+              , with the exception of forward
               and forwarders. (These options control
-              the behavior of the containing view, rather than changing
+              the behavior of the containing view, rather than change
               the zone object itself.)
             
    
             
    
-              Zone level acls (e.g. allow-query, allow-transfer) and
-              other configuration details of the zone are all set
-              in the view the referenced zone is defined in.  Care
-              need to be taken to ensure that acls are wide enough
+              Zone-level ACLs (e.g., allow-query, allow-transfer), and
+              other configuration details of the zone, are all set
+              in the view the referenced zone is defined in.  Be
+              careful to ensure that ACLs are wide enough
               for all views referencing the zone.
             
    
             
    
@@ -10939,14 +10919,14 @@ view external {
 
           
    
             This section, largely borrowed from RFC 1034, describes the
-            concept of a Resource Record (RR) and explains when each is used.
+            concept of a Resource Record (RR) and explains when each type 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
    
+Resource Records
    
 
             
    
               A domain name identifies a node.  Each node has a set of
@@ -10955,7 +10935,7 @@ view external {
               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
+              permitted for optimization purposes: for example, to specify
               that a particular nearby server be tried first. See the section called “The sortlist Statement” and the section called “RRset Ordering”.
             
    
 
@@ -11020,7 +11000,7 @@ view external {
 
    
@@ -11033,1064 +11013,19 @@ view external {
 
-
-
-
    
 
    
                       
    
-                        Exact-match semantics.  This rule matches
+                        With exact-match semantics, this rule matches
                         when the name being updated is identical
                         to the contents of the
                         name field.
@@ -10566,7 +10546,7 @@ example.com. NS ns2.example.net.
                         name as the record to be updated.  In this case,
                         the identity field
                         can be specified as *
-                        (an asterisk).
+                        (asterisk).
                       
    
                         		
 
    
 
    
                       
    
-                        This rule is similar to self
+                        This rule is similar to self,
                         except that subdomains of self
                         can also be updated.
                       
    
@@ -10592,7 +10572,7 @@ example.com. NS ns2.example.net.
                         		
 
                       
    
-                        This rule is similar to self
+                        This rule is similar to self,
                         except that only subdomains of
                         self can be updated.
                       
    
@@ -10607,9 +10587,9 @@ example.com. NS ns2.example.net.
     		
                       
    
                         When a client sends an UPDATE using a Windows
-                        machine principal (for example, 'machine$@REALM'),
+                        machine principal (for example, "machine$@REALM"),
                         this rule allows records with the absolute name
-                        of 'machine.REALM' to be updated.
+                        of "machine.REALM" to be updated.
                       
    
                       
    
                         The realm to be matched is specified in the
@@ -10637,7 +10617,7 @@ example.com. NS ns2.example.net.
                     
    		
 
                       
    
-                        This is similar to ms-self
+                        This is similar to ms-self,
                         except it also allows updates to any subdomain of
                         the name specified in the Windows machine
                         principal, not just to the name itself.
@@ -10653,7 +10633,7 @@ example.com. NS ns2.example.net.
 
    		
                       
    
                         When a client sends an UPDATE using a Windows
-                        machine principal (for example, 'machine$@REALM'),
+                        machine principal (for example, "machine$@REALM"),
                         this rule allows any machine in the specified
                         realm to update any record in the zone or in a
                         specified subdomain of the zone.
@@ -10665,8 +10645,8 @@ example.com. NS ns2.example.net.
                       
    
                         The name field
                         specifies the subdomain that may be updated.
-                        If set to "." (or any other name at or above
-                        the zone apex), any name in the zone can be
+                        If set to "." or any other name at or above
+                        the zone apex, any name in the zone can be
                         updated.
                       
    
                       
    
@@ -10674,8 +10654,8 @@ example.com. NS ns2.example.net.
                         for the zone "example.com" includes
                         grant EXAMPLE.COM ms-subdomain hosts.example.com. A AAAA,
                         any machine with a valid principal in
-                        the realm EXAMPLE.COM will
-                        be able to update address records at or below
+                        the realm EXAMPLE.COM is
+                        able to update address records at or below
                         "hosts.example.com".
                       
    
                         		
                       
                       
    
-                        This is similar to krb5-self
+                        This is similar to krb5-self,
                         except it also allows updates to any subdomain of
-                        the name specified in the 'machine' part of the
+                        the name specified in the "machine" part of the
                         Kerberos principal, not just to the name itself.
                       
    
                         		
                     
                       
                       
                       
    
                         An encoded 16-bit value that identifies
-                        a protocol family or instance of a protocol.
+                        a protocol family or an instance of a protocol.
                       
    
                         		
 
    
                       
    
                         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.
-                      
    
-                    
    
-                      
    
-                        AMTRELAY
-                      
    
-                        		
-                      
    
-                        Automatic Multicast Tunneling Relay
-                        discovery record.
-                        Work in progress draft-ietf-mboned-driad-amt-discovery.
-                      
    
-                    
    
-                      
    
-                        APL
-                      
    
-                        		
-                      
    
-                        Address prefix list.  Experimental.
-                        Described in RFC 3123.
-                      
    
-                    
    
-                      
    
-                        ATMA
-                      
    
-                        		
-                      
    
-                        ATM Address.
-                      
    
-                    
    
-                      
    
-                        AVC
-                      
    
-                        		
-                      
    
-                        Application Visibility and Control record.
-                      
    
-                    
    
-                      
    
-                        CAA
-                      
    
-                        		
-                      
    
-                        Identifies which Certificate Authorities can issue
-                        certificates for this domain and what rules they
-                        need to follow when doing so. Defined in RFC 6844.
-                      
    
-                    
    
-                      
    
-                        CDNSKEY
-                      
    
-                        		
-                      
    
-                        Identifies which DNSKEY records should be published
-                        as DS records in the parent zone.
-                      
    
-                    
    
-                      
    
-                        CDS
-                      
    
-                        		
-                      
    
-                        Contains the set of DS records that should be published
-                        by the parent zone.
-                      
    
-                    
    
-                      
    
-                        CERT
-                      
    
-                        		
-                      
    
-                        Holds a digital certificate.
-                        Described in RFC 2538.
-                      
    
-                    
    
-                      
    
-                        CNAME
-                      
    
-                        		
-                      
    
-                        Identifies the canonical name of an alias.
-                        Described in RFC 1035.
-                      
    
-                    
    
-                      
    
-                        CSYNC
-                      
    
-                        		
-                      
    
-                        Child-to-Parent Synchronization in DNS as described
-                        in RFC 7477.
-                      
    
-                    
    
-                      
    
-                        DHCID
-                      
    
-                        		
-                      
    
-                        Is used for identifying which DHCP client is
-                        associated with this name.  Described in RFC 4701.
-                      
    
-                    
    
-                      
    
-                        DLV
-                      
    
-                        		
-                      
    
-                        A DNS Look-aside Validation record which contains
-                        the records that are used as trust anchors for
-                        zones in a DLV namespace.  Described in RFC 4431.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        DOA
-                      
    
-                        		
-                      
    
-                        Implements the Digital Object Architecture over
-                        DNS. Experimental.
-                      
    
-                    
    
-                      
    
-                        DS
-                      
    
-                        		
-                      
    
-                        Stores the hash of a public key associated with a
-                        signed DNS zone.  Described in RFC 4034.
-                      
    
-                    
    
-                      
    
-                        EID
-                      
    
-                        		
-                      
    
-                        End Point Identifier.
-                      
    
-                    
    
-                      
    
-                        EUI48
-                      
    
-                        		
-                      
    
-                        A 48-bit EUI address. Described in RFC 7043.
-                      
    
-                    
    
-                      
    
-                        EUI64
-                      
    
-                        		
-                      
    
-                        A 64-bit EUI address. Described in RFC 7043.
-                      
    
-                    
    
-                      
    
-                        GID
-                      
    
-                        		
-                      
    
-                        Reserved.
-                      
    
-                    
    
-                      
    
-                        GPOS
-                      
    
-                        		
-                      
    
-                        Specifies the global position.  Superseded by LOC.
-                      
    
-                    
    
-                      
    
-                        HINFO
-                      
    
-                        		
-                      
    
-                        Identifies the CPU and OS used by a host.
-                        Described in RFC 1035.
-                      
    
-                    
    
-                      
    
-                        HIP
-                      
    
-                        		
-                      
    
-                        Host Identity Protocol Address.
-                        Described in RFC 5205.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        L32
-                      
    
-                        		
-                      
    
-                        Holds 32-bit Locator values for
-                        Identifier-Locator Network Protocol. Described
-                        in RFC 6742.
-                      
    
-                    
    
-                      
    
-                        L64
-                      
    
-                        		
-                      
    
-                        Holds 64-bit Locator values for
-                        Identifier-Locator Network Protocol. Described
-                        in RFC 6742.
-                      
    
-                    
    
-                      
    
-                        LOC
-                      
    
-                        		
-                      
    
-                        For storing GPS info.  Described in RFC 1876.
-                        Experimental.
-                      
    
-                    
    
-                      
    
-                        LP
-                      
    
-                        		
-                      
    
-                        Identifier-Locator Network Protocol.
-                        Described in RFC 6742.
-                      
    
-                    
    
-                      
    
-                        MB
-                      
    
-                        		
-                      
    
-                        Mail Box.  Historical.
-                      
    
-                    
    
-                      
    
-                        MD
-                      
    
-                        		
-                      
    
-                        Mail Destination.  Historical.
-                      
    
-                    
    
-                      
    
-                        MF
-                      
    
-                        		
-                      
    
-                        Mail Forwarder.  Historical.
-                      
    
-                    
    
-                      
    
-                        MG
-                      
    
-                        		
-                      
    
-                        Mail Group.  Historical.
-                      
    
-                    
    
-                      
    
-                        MINFO
-                      
    
-                        		
-                      
    
-                        Mail Information.
-                      
    
-                    
    
-                      
    
-                        MR
-                      
    
-                        		
-                      
    
-                        Mail Rename. Historical.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        NID
-                      
    
-                        		
-                      
    
-                        Holds values for Node Identifiers in
-                        Identifier-Locator Network Protocol. Described
-                        in RFC 6742.
-                      
    
-                    
    
-                      
    
-                        NINFO
-                      
    
-                        		
-                      
    
-                        Contains zone status information.
-                      
    
-                    
    
-                      
    
-                        NIMLOC
-                      
    
-                        		
-                      
    
-                        Nimrod Locator.
-                      
    
-                    
    
-                      
    
-                        NSAP
-                      
    
-                        		
-                      
    
-                        A network service access point.
-                        Described in RFC 1706.
-                      
    
-                    
    
-                      
    
-                        NSAP-PTR
-                      
    
-                        		
-                      
    
-                        Historical.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        NULL
-                      
    
-                        		
-                      
    
-                        This is an opaque container.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        OPENPGPKEY
-                      
    
-                        		
-                      
    
-                        Used to hold an OPENPGPKEY.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        RKEY
-                      
    
-                        		
-                      
    
-                        Resource key.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        SINK
-                      
    
-                        		
-                      
    
-                        The kitchen sink record.
-                      
    
-                    
    
-                      
    
-                        SMIMEA
-                      
    
-                        		
-                      
    
-                        The S/MIME Security Certificate Association.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        TA
-                      
    
-                        		
-                      
    
-                        Trust Anchor. Experimental.
-                      
    
-                    
    
-                      
    
-                        TALINK
-                      
    
-                        		
-                      
    
-                        Trust Anchor Link.  Experimental.
-                      
    
-                    
    
-                      
    
-                        TLSA
-                      
    
-                        		
-                      
    
-                        Transport Layer Security Certificate Association.
-                        Described in RFC 6698.
-                      
    
-                    
    
-                      
    
-                        TXT
-                      
    
-                        		
-                      
    
-                        Text records.  Described in RFC 1035.
-                      
    
-                    
    
-                      
    
-                        UID
-                      
    
-                        		
-                      
    
-                        Reserved.
-                      
    
-                    
    
-                      
    
-                        UINFO
-                      
    
-                        		
-                      
    
-                        Reserved.
-                      
    
-                    
    
-                      
    
-                        UNSPEC
-                      
    
-                        		
-                      
    
-                        Reserved. Historical.
-                      
    
-                    
    
-                      
    
-                        URI
-                      
    
-                        		
-                      
    
-                        Holds a URI. Described in RFC 7553.
-                      
    
-                    
    
-                      
    
-                        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.
-                      
    
-                    
    
-                      
    
-                        ZONEMD
-                      
    
-                        		
-                      
    
-                        Zone Message Digest.
-                        Work in progress draft-wessels-dns-zone-digest.
+                        data is type- and sometimes class-specific.
                       
    
                         		
 
    
     
 
    
             
    
+                
    
+                For a complete list of types of valid RRs,
+                including those that have been obsoleted,
+                please refer to https://en.wikipedia.org/wiki/List_of_DNS_record_types.
+                
    
+
             
    
               The following classes of resource records
               are currently valid in the DNS:
@@ -12124,7 +11059,7 @@ view external {
                       
    
                         Chaosnet, a LAN protocol created at MIT in the
                         mid-1970s.
-                        Rarely used for its historical purpose, but reused for
+                        It was rarely used for its historical purpose, but was reused for
                         BIND's
                         built-in server information zones, e.g.,
                         version.bind.
@@ -12140,11 +11075,11 @@ view external {
 
                       
    
                         Hesiod, an information service
-                        developed by MIT's Project Athena. It is used to share
+                        developed by MIT's Project Athena. It was used to share
                         information
                         about various systems databases, such as users,
-                        groups, printers
-                        and so on.
+                        groups, printers,
+                        etc.
                       
    
                     
 
@@ -12158,16 +11093,16 @@ view external {
               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)
+              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
+              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
+              data in zones; that also times out, but follows 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
@@ -12178,8 +11113,7 @@ view external {
               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
+              inconsistency, and then increased back to its former value
               following
               the change.
             
    
@@ -12192,7 +11126,7 @@ view external {
           
           
    
 
    
-Textual expression of RRs
    
+Textual Expression of RRs
    
 
             
    
               RRs are represented in binary form in the packets of the DNS
@@ -12200,7 +11134,7 @@ view external {
               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
+              RFC 1034, a style similar to that used in zone 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
@@ -12214,22 +11148,22 @@ view external {
               readability.
             
    
             
    
-              Following the owner, we list the TTL, type, and class of the
+              Following the owner are 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
+              an integer before the type field.  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.
+              are often omitted from examples in the interest of clarity.
             
    
             
    
-              The resource data or RDATA section of the RR are given using
+              The resource data or RDATA section of the RR is given using
               knowledge of the typical representation for the data.
             
    
             
    
-              For example, we might show the RRs carried in a message as:
+              For example, the RRs carried in a message might be shown as:
             
    
             
    
 
@@ -12342,14 +11276,14 @@ view external {
               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.
+              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:
+              Here is another possible example:
             
    
 
    
             
             
             
    
@@ -12408,8 +11342,8 @@ view external {
             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
+            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.
           
    
 
@@ -12420,21 +11354,21 @@ view external {
             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
+            the mail transport agent falls back to the next largest
             priority.
-            Priority numbers do not have any absolute meaning — they are
+            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.
+            name given is the machine to which the mail is delivered.
             It must have an associated address record
-            (A or AAAA) — CNAME is not sufficient.
+            (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.
+            MX record, the MX record is in error, and is ignored.
             Instead,
-            the mail will be delivered to the server specified in the MX
+            the mail is delivered to the server specified in the MX
             record
             pointed to by the CNAME.
             For example:
@@ -12580,10 +11514,10 @@ view external {
 
    
           
    
             
    
 
    
-            Mail delivery will be attempted to mail.example.com and
+            Mail delivery is 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.
+            any order); if neither of those succeeds, delivery to mail.backup.org
+            is attempted.
           
    
         
         
    
@@ -12591,10 +11525,10 @@ view external {
 Setting TTLs
    
 
           
    
-            The time-to-live of the RR field is a 32-bit integer represented
+            The time-to- (TTL) 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
+            cache RRs. The TTL describes how long an RR can be cached before it
+            should be discarded. The following three types of TTLs are
             currently
             used in a zone file.
           
    
@@ -12614,9 +11548,9 @@ view external {
 
                     
    
                       The last field in the SOA is the negative
-                      caching TTL. This controls how long other servers will
+                      caching TTL. This controls how long other servers
                       cache no-such-domain
-                      (NXDOMAIN) responses from you.
+                      (NXDOMAIN) responses from this server.
                     
    
                     
    
                       The maximum time for
@@ -12648,7 +11582,7 @@ view external {
 
                     
    
                       Each RR can have a TTL as the second
-                      field in the RR, which will control how long other
+                      field in the RR, which controls how long other
                       servers can cache it.
                     
    
                   
@@ -12658,7 +11592,7 @@ view external {
           
           
    
             All of these TTLs default to units of seconds, though units
-            can be explicitly specified, for example, 1h30m.
+            can be explicitly specified: for example, 1h30m.
           
    
         
         
    
@@ -12717,10 +11651,10 @@ view external {
           
    
 
    Note
    
             
    
-              The $ORIGIN lines in the examples
-              are for providing context to the examples only — they do not
+              The $ORIGIN line in this example
+              is only to provide context; it does not
               necessarily
-              appear in the actual usage. They are only used here to indicate
+              appear in the actual usage. It is only used here to indicate
               that the example is relative to the listed origin.
             
    
           
    
@@ -12730,15 +11664,15 @@ view external {
 Other Zone File Directives
    
 
           
    
-            The Master File Format was initially defined in RFC 1035 and
-            has subsequently been extended. While the Master File Format
+            The DNS "master file" format was initially defined in RFC 1035 and
+            has subsequently been extended. While the format
             itself
-            is class independent all records in a Master File must be of the
+            is class-independent, all records in a zone file must be of the
             same
             class.
           
    
           
    
-            Master File Directives include $ORIGIN, $INCLUDE,
+            Master file directives include $ORIGIN, $INCLUDE,
             and $TTL.
           
    
           
    
@@ -12749,8 +11683,8 @@ view external {
               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).
+              <zone_name>, followed by a
+              trailing dot (.).
             
    
           
    
           
    
@@ -12763,11 +11697,11 @@ view external {
               [comment]
             
    
             
    $ORIGIN
-              sets the domain name that will be appended to any
-              unqualified records. When a zone is first read in there
+              sets the domain name that is appended to any
+              unqualified records. When a zone is first read, there
               is an implicit $ORIGIN
-              <zone_name>.
-              (followed by trailing dot).
+              <zone_name>.;
+              note the trailing dot.
               The current $ORIGIN is appended to
               the domain specified in the $ORIGIN
               argument if it is not absolute.
@@ -12799,10 +11733,10 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
               [ 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
+              This reads and processes the file filename as
+              if it were included in 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.
             
    
             
    
@@ -12835,7 +11769,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 comment ]
             
    
             
    
-              Set the default Time To Live (TTL) for subsequent records
+              This sets the default Time-To-Live (TTL) for subsequent records
               with undefined TTLs. Valid TTLs are of the range 0-2147483647
               seconds.
             
    
@@ -12846,7 +11780,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
         
    
         
    
 
    
-BIND Master File Extension: the  $GENERATE Directive
    
+BIND Primary File Extension: the  $GENERATE Directive
    
 
           
    
             Syntax: $GENERATE
@@ -12863,7 +11797,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
             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:
+            sub-/24 reverse delegations described in RFC 2317:
             Classless IN-ADDR.ARPA delegation.
           
    
 
@@ -12884,9 +11818,9 @@ $GENERATE 1-127 $ CNAME $.0

    - 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. + Both generate a set of A and MX records. Note the MX's right-hand + side is a quoted string. The quotes are stripped when the + right-hand side is processed. 

    @@ -12924,9 +11858,9 @@ HOST-127.EXAMPLE. MX 0 .
                     
    
                       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. start, stop and step must be positive
-                      integers between 0 and (2^31)-1. start must not be
-                      larger than stop.
+                      is set to 1. "start", "stop", and "step" must be positive
+                      integers between 0 and (2^31)-1. "start" must not be
+                      larger than "stop".
                     
    
                   
 
@@ -12942,20 +11876,20 @@ HOST-127.EXAMPLE. MX 0 .
                       symbols within the lhs string
                       are replaced by the iterator value.
 
-                      To get a $ in the output, you need to escape the
+                      To get a $ in the output, escape the
                       $ using a backslash
                       \,
-                      e.g. \$. The
+                      e.g., \$. The
                       $ may optionally be followed
                       by modifiers which change the offset from the
-                      iterator, field width and base.
+                      iterator, field width, and base.
 
                       Modifiers are introduced by a
                       { (left brace) immediately following the
-                      $ as
+                      $, as in
                       ${offset[,width[,base]]}.
                       For example, ${-20,3,d}
-                      subtracts 20 from the current value, prints the
+                      subtracts 20 from the current value and prints the
                       result as a decimal in a zero-padded field of
                       width 3.
 
@@ -12963,8 +11897,8 @@ HOST-127.EXAMPLE. MX 0 .
                       (d), octal
                       (o), hexadecimal
                       (x or X
-                      for uppercase) and nibble
-                      (n or N\
+                      for uppercase), and nibble
+                      (n or N
                       for uppercase).  The default modifier is
                       ${0,0,d}.  If the
                       lhs is not absolute, the
@@ -12972,8 +11906,8 @@ HOST-127.EXAMPLE. MX 0 .
                       to the name.
                     
    
                     
    
-                      In nibble mode the value will be treated as
-                      if it was a reversed hexadecimal string
+                      In nibble mode, the value is treated as
+                      if it were a reversed hexadecimal string,
                       with each hexadecimal digit as a separate
                       label.  The width field includes the label
                       separator.
@@ -12991,8 +11925,8 @@ HOST-127.EXAMPLE. MX 0 .
                   
 
                     
    
-                      Specifies the time-to-live of the generated records. If
-                      not specified this will be inherited using the
+                      This specifies the time-to-live of the generated records. If
+                      not specified, this is inherited using the
                       normal TTL inheritance rules.
                     
    
                     
    class
@@ -13007,7 +11941,7 @@ HOST-127.EXAMPLE. MX 0 .
                   
 
                     
    
-                      Specifies the class of the generated records.
+                      This specifies the class of the generated records.
                       This must match the zone class if it is
                       specified.
                     
    
@@ -13023,7 +11957,7 @@ HOST-127.EXAMPLE. MX 0 .
                   
 
                     
    
-                      Any valid type.
+                      This can be any valid type.
                     
    
                   
 
@@ -13033,7 +11967,7 @@ HOST-127.EXAMPLE. MX 0 .
                   
 
                     
    
-                      rhs, optionally, quoted string.
+                      rhs is an optionally quoted string.
                     
    
                   
 
@@ -13054,7 +11988,7 @@ HOST-127.EXAMPLE. MX 0 .
 Additional File Formats
 
           
    
-            In addition to the standard textual format, BIND 9
+            In addition to the standard text format, BIND 9
             supports the ability to read or dump to zone files in
             other formats.
           
    
@@ -13067,9 +12001,9 @@ HOST-127.EXAMPLE. MX 0 .
           
    
             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
+            in-memory zone database; it can be loaded
             directly into memory via the mmap()
-            function; the zone can begin serving queries almost
+            function and the zone can begin serving queries almost
             immediately.
           
    
           
    
@@ -13077,25 +12011,25 @@ HOST-127.EXAMPLE. MX 0 .
             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
+            For a secondary server or for a dynamic zone, the zone file is automatically
+            generated when
             named dumps the zone contents after
-            zone transfer or when applying prior updates.
+            zone transfer or when applying prior updates, if one of these formats is specified by the
+            masterfile-format option.
           
    
           
    
             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.  Make any
+            necessary modifications to the text file, and
+            then convert it to the binary form via 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
+            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
@@ -13113,21 +12047,20 @@ HOST-127.EXAMPLE. MX 0 .
 
       
    
 
    
-BIND9 Statistics
    
+BIND 9 Statistics
    
 
         
    
           BIND 9 maintains lots of statistics
           information and provides several interfaces for users to
-          get access to the statistics.
+          access those statistics.
           The available statistics include all statistics counters
-          that were available in BIND 8 and
-          are meaningful in BIND 9,
+          that are meaningful in BIND 9,
           and other information that is considered useful.
         
    
 
         
    
           The statistics information is categorized into the following
-          sections.
+          sections:
         
    
 
         
    
@@ -13164,8 +12097,8 @@ HOST-127.EXAMPLE. MX 0 .
 
                   
    
                     The number of outgoing queries for each RR
-                    type sent from the internal resolver.
-                    Maintained per view.
+                    type sent from the internal resolver,
+                    maintained per view.
                   
    
                 
 
@@ -13175,7 +12108,7 @@ HOST-127.EXAMPLE. MX 0 .
                 
 
                   
    
-                    Statistics counters about incoming request processing.
+                    Statistics counters for incoming request processing.
                   
    
                 
 
@@ -13186,7 +12119,7 @@ HOST-127.EXAMPLE. MX 0 .
 
                   
    
                     Statistics counters regarding zone maintenance
-                    operations such as zone transfers.
+                    operations, such as zone transfers.
                   
    
                 
 
@@ -13196,9 +12129,9 @@ HOST-127.EXAMPLE. MX 0 .
                 
 
                   
    
-                    Statistics counters about name resolution
-                    performed in the internal resolver.
-                    Maintained per view.
+                    Statistics counters for name resolutions
+                    performed in the internal resolver,
+                    maintained per view.
                   
    
                 
 
@@ -13208,14 +12141,29 @@ HOST-127.EXAMPLE. MX 0 .
                 
 
                   
    
-                    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.
+                    Statistics counters related to cache contents,
+                    maintained per view.
+                  
    
+                  
    
+                    The "NXDOMAIN" counter is the number of names
+                    that have been cached as nonexistent.
+                    Counters named for RR types indicate the
+                    number of active RRsets for each type in the cache
+                    database.
+                  
    
+                  
    
+                    If an RR type name is preceded by an exclamation
+                    point (!), it represents the number of records in the
+                    cache which indicate that the type does not exist
+                    for a particular name; this is also known as "NXRRSET".
+                    If an RR type name is preceded by a hash mark (#), it
+                    represents the number of RRsets for this type that are
+                    present in the cache but whose TTLs have expired; these
+                    RRsets may only be used if stale answers are enabled.
+                    If an RR type name is preceded by a tilde (~), it
+                    represents the number of RRsets for this type that are
+                    present in the cache database but are marked for garbage
+                    collection; these RRsets cannot be used.
                   
    
                 
 
@@ -13225,7 +12173,7 @@ HOST-127.EXAMPLE. MX 0 .
                 
 
                   
    
-                    Statistics counters about network related events.
+                    Statistics counters for network-related events.
                   
    
                 
 
@@ -13235,9 +12183,9 @@ HOST-127.EXAMPLE. MX 0 .
 
         
    
           A subset of Name Server Statistics is collected and shown
-          per zone for which the server has the authority when
+          per zone for which the server has the authority, when
           zone-statistics is set to
-          full (or yes
+          full (or yes),
           for backward compatibility. See the description of
           zone-statistics in the section called “options Statement Definition and
           Usage”
@@ -13252,9 +12200,9 @@ HOST-127.EXAMPLE. MX 0 .
         
    
           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
+          One is in 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 section called “statistics-channels Statement Grammar”.)
@@ -13272,7 +12220,7 @@ HOST-127.EXAMPLE. MX 0 .
           
    
           
    
             The number in parentheses is a standard
-            Unix-style timestamp, measured as seconds since January 1, 1970.
+            Unix-style timestamp, measured in seconds since January 1, 1970.
 
             Following
             that line is a set of statistics information, which is categorized
@@ -13286,8 +12234,8 @@ HOST-127.EXAMPLE. MX 0 .
 
           
    
             Each section consists of lines, each containing the statistics
-            counter value followed by its textual description.
-            See below for available counters.
+            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.
           
    
@@ -13306,16 +12254,16 @@ HOST-127.EXAMPLE. MX 0 .
 Statistics Counters
    
 
           
    
-            The following tables summarize statistics counters that
+            The following tables summarize the 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
+            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).
+            which is also shown in the statistics file,
+            but, in this document, may be slightly modified
+            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
@@ -13342,7 +12290,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        BIND8 Symbol
+                        BIND 8 Symbol
                       
    
                     
 
@@ -13360,8 +12308,8 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 requests received.
-                        Note: this also counts non query requests.
+                        This indicates the number of IPv4 requests received.
+                        Note: this also counts non-query requests.
                       
    
                     
 
@@ -13374,8 +12322,8 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 requests received.
-                        Note: this also counts non query requests.
+                        This indicates the number of IPv6 requests received.
+                        Note: this also counts non-query requests.
                       
    
                     
 
@@ -13388,7 +12336,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Requests with EDNS(0) received.
+                        This indicates the number of requests received with EDNS(0).
                       
    
                     
 
@@ -13401,7 +12349,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Requests with unsupported EDNS version received.
+                        This indicates the number of requests received with an unsupported EDNS version.
                       
    
                     
 
@@ -13414,7 +12362,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Requests with TSIG received.
+                        This indicates the number of requests received with TSIG.
                       
    
                     
 
@@ -13427,7 +12375,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Requests with SIG(0) received.
+                        This indicates the number of requests received with SIG(0).
                       
    
                     
 
@@ -13440,7 +12388,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Requests with invalid (TSIG or SIG(0)) signature.
+                        This indicates the number of requests received with an invalid (TSIG or SIG(0)) signature.
                       
    
                     
 
@@ -13453,7 +12401,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        TCP requests received.
+                        This indicates the number of TCP requests received.
                       
    
                     
 
@@ -13466,7 +12414,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Authoritative (non recursive) queries rejected.
+                        This indicates the number of rejected authoritative (non-recursive) queries.
                       
    
                     
 
@@ -13479,7 +12427,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Recursive queries rejected.
+                        This indicates the number of rejected recursive queries.
                       
    
                     
 
@@ -13492,7 +12440,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Zone transfer requests rejected.
+                        This indicates the number of rejected zone transfer requests.
                       
    
                     
 
@@ -13505,7 +12453,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Dynamic update requests rejected.
+                        This indicates the number of rejected dynamic update requests.
                       
    
                     
 
@@ -13518,7 +12466,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Responses sent.
+                        This indicates the number of responses sent.
                       
    
                     
 
@@ -13531,7 +12479,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Truncated responses sent.
+                        This indicates the number of truncated responses sent.
                       
    
                     
 
@@ -13544,7 +12492,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Responses with EDNS(0) sent.
+                        This indicates the number of responses sent with EDNS(0).
                       
    
                     
 
@@ -13557,7 +12505,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Responses with TSIG sent.
+                        This indicates the number of responses sent with TSIG.
                       
    
                     
 
@@ -13570,7 +12518,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Responses with SIG(0) sent.
+                        This indicates the number of responses sent with SIG(0).
                       
    
                     
 
@@ -13583,8 +12531,8 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in a successful answer.
-                        This means the query which returns a NOERROR response
+                        This indicates the number of queries that resulted in a successful answer,
+                        meaning queries which return a NOERROR response
                         with at least one answer RR.
                         This corresponds to the
                         success counter
@@ -13602,7 +12550,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in authoritative answer.
+                        This indicates the number of queries that resulted in an authoritative answer.
                       
    
                     
 
@@ -13615,7 +12563,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in non authoritative answer.
+                        This indicates the number of queries that resulted in a non-authoritative answer.
                       
    
                     
 
@@ -13628,7 +12576,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in referral answer.
+                        This indicates the number of queries that resulted in a referral answer.
                         This corresponds to the
                         referral counter
                         of previous versions of
@@ -13645,7 +12593,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in NOERROR responses with no data.
+                        This indicates the number of queries that resulted in NOERROR responses with no data.
                         This corresponds to the
                         nxrrset counter
                         of previous versions of
@@ -13662,7 +12610,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in SERVFAIL.
+                        This indicates the number of queries that resulted in SERVFAIL.
                       
    
                     
 
@@ -13675,7 +12623,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in FORMERR.
+                        This indicates the number of queries that resulted in FORMERR.
                       
    
                     
 
@@ -13688,7 +12636,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in NXDOMAIN.
+                        This indicates the number of queries that resulted in NXDOMAIN.
                         This corresponds to the
                         nxdomain counter
                         of previous versions of
@@ -13705,7 +12653,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries which caused the server
+                        This indicates the number of queries that caused the server
                         to perform recursion in order to find the final answer.
                         This corresponds to the
                         recursion counter
@@ -13723,9 +12671,9 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries which the server attempted to
-                        recurse but discovered an existing query with the same
-                        IP address, port, query ID, name, type and class
+                        This indicates the number of queries which the server attempted to
+                        recurse but for which it discovered an existing query with the same
+                        IP address, port, query ID, name, type, and class
                         already being processed.
                         This corresponds to the
                         duplicate counter
@@ -13743,10 +12691,10 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Recursive queries for which the server
+                        This indicates the number of recursive queries for which the server
                         discovered an excessive number of existing
-                        recursive queries for the same name, type and
-                        class and were subsequently dropped.
+                        recursive queries for the same name, type, and
+                        class, and which were subsequently dropped.
                         This is the number of dropped queries due to
                         the reason explained with the
                         clients-per-query
@@ -13771,18 +12719,18 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Other query failures.
+                        This indicates the number of query failures.
                         This corresponds to the
                         failure counter
                         of previous versions of
                         BIND 9.
                         Note: this counter is provided mainly for
-                        backward compatibility with the previous versions.
-                        Normally a more fine-grained counters such as
+                        backward compatibility with the previous versions;
+                        normally, more fine-grained counters such as
                         AuthQryRej and
                         RecQryRej
                         that would also fall into this counter are provided,
-                        and so this counter would not be of much
+                        so this counter is not of much
                         interest in practice.
                       
    
                     
@@ -13796,7 +12744,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in NXDOMAIN that were redirected.
+                        This indicates the number of queries that resulted in NXDOMAIN that were redirected.
                       
    
                     
 
@@ -13809,7 +12757,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries resulted in NXDOMAIN that were redirected
+                        This indicates the number of queries that resulted in NXDOMAIN that were redirected
                         and resulted in a successful remote lookup.
                       
    
                     
@@ -13823,7 +12771,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Requested zone transfers completed.
+                        This indicates the number of requested and completed zone transfers.
                       
    
                     
 
@@ -13836,7 +12784,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Update requests forwarded.
+                        This indicates the number of forwarded update requests.
                       
    
                     
 
@@ -13849,7 +12797,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Update responses forwarded.
+                        This indicates the number of forwarded update responses.
                       
    
                     
 
@@ -13862,7 +12810,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Dynamic update forward failed.
+                        This indicates the number of forwarded dynamic updates that failed.
                       
    
                     
 
@@ -13875,7 +12823,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Dynamic updates completed.
+                        This indicates the number of completed dynamic updates.
                       
    
                     
 
@@ -13888,7 +12836,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Dynamic updates failed.
+                        This indicates the number of failed dynamic updates.
                       
    
                     
 
@@ -13901,7 +12849,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Dynamic updates rejected due to prerequisite failure.
+                        This indicates the number of dynamic updates rejected due to a prerequisite failure.
                       
    
                     
 
@@ -13914,7 +12862,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Responses dropped by rate limits.
+                        This indicates the number of responses dropped due to rate limits.
                       
    
                     
 
@@ -13927,7 +12875,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Responses truncated by rate limits.
+                        This indicates the number of responses truncated by rate limits.
                       
    
                     
 
@@ -13940,7 +12888,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Response policy zone rewrites.
+                        This indicates the number of response policy zone rewrites.
                       
    
                     
 
@@ -13978,7 +12926,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 notifies sent.
+                        This indicates the number of IPv4 notifies sent.
                       
    
                     
 
@@ -13988,7 +12936,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 notifies sent.
+                        This indicates the number of IPv6 notifies sent.
                       
    
                     
 
@@ -13998,7 +12946,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 notifies received.
+                        This indicates the number of IPv4 notifies received.
                       
    
                     
 
@@ -14008,7 +12956,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 notifies received.
+                        This indicates the number of IPv6 notifies received.
                       
    
                     
 
@@ -14018,7 +12966,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Incoming notifies rejected.
+                        This indicates the number of incoming notifies rejected.
                       
    
                     
 
@@ -14028,7 +12976,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 SOA queries sent.
+                        This indicates the number of IPv4 SOA queries sent.
                       
    
                     
 
@@ -14038,7 +12986,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 SOA queries sent.
+                        This indicates the number of IPv6 SOA queries sent.
                       
    
                     
 
@@ -14048,7 +12996,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 AXFR requested.
+                        This indicates the number of requested IPv4 AXFRs.
                       
    
                     
 
@@ -14058,7 +13006,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 AXFR requested.
+                        This indicates the number of requested IPv6 AXFRs.
                       
    
                     
 
@@ -14068,7 +13016,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 IXFR requested.
+                        This indicates the number of requested IPv4 IXFRs.
                       
    
                     
 
@@ -14078,7 +13026,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 IXFR requested.
+                        This indicates the number of requested IPv6 IXFRs.
                       
    
                     
 
@@ -14088,7 +13036,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Zone transfer requests succeeded.
+                        This indicates the number of successful zone transfer requests.
                       
    
                     
 
@@ -14098,7 +13046,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Zone transfer requests failed.
+                        This indicates the number of failed zone transfer requests.
                       
    
                     
 
@@ -14127,7 +13075,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        BIND8 Symbol
+                        BIND 8 Symbol
                       
    
                     
 
@@ -14145,7 +13093,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 queries sent.
+                        This indicates the number of IPv4 queries sent.
                       
    
                     
 
@@ -14158,7 +13106,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 queries sent.
+                        This indicates the number of IPv6 queries sent.
                       
    
                     
 
@@ -14171,7 +13119,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 responses received.
+                        This indicates the number of IPv4 responses received.
                       
    
                     
 
@@ -14184,7 +13132,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 responses received.
+                        This indicates the number of IPv6 responses received.
                       
    
                     
 
@@ -14197,7 +13145,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        NXDOMAIN received.
+                        This indicates the number of NXDOMAINs received.
                       
    
                     
 
@@ -14210,7 +13158,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        SERVFAIL received.
+                        This indicates the number of SERVFAILs received.
                       
    
                     
 
@@ -14223,7 +13171,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        FORMERR received.
+                        This indicates the number of FORMERRs received.
                       
    
                     
 
@@ -14236,7 +13184,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Other errors received.
+                        This indicates the number of other errors received.
                       
    
                     
 
@@ -14249,7 +13197,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        EDNS(0) query failures.
+                        This indicates the number of EDNS(0) query failures.
                       
    
                     
 
@@ -14262,8 +13210,8 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Mismatch responses received.
-                        The DNS ID, response's source address,
+                        This indicates the number of mismatched responses received,
+                        meaning the DNS ID, response's source address,
                         and/or the response's source port does not
                         match what was expected.
                         (The port must be 53 or as defined by
@@ -14282,7 +13230,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Truncated responses received.
+                        This indicates the number of truncated responses received.
                       
    
                     
 
@@ -14295,7 +13243,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Lame delegations received.
+                        This indicates the number of lame delegations received.
                       
    
                     
 
@@ -14308,7 +13256,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Query retries performed.
+                        This indicates the number of query retries performed.
                       
    
                     
 
@@ -14321,7 +13269,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Queries aborted due to quota control.
+                        This indicates the number of queries aborted due to quota control.
                       
    
                     
 
@@ -14334,10 +13282,9 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Failures in opening query sockets.
+                        This indicates the number of failures in opening query sockets.
                         One common reason for such failures is a
-                        failure of opening a new socket due to a
-                        limitation on file descriptors.
+                        due to a limitation on file descriptors.
                       
    
                     
 
@@ -14350,7 +13297,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Query timeouts.
+                        This indicates the number of query timeouts.
                       
    
                     
 
@@ -14363,7 +13310,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 NS address fetches invoked.
+                        This indicates the number of IPv4 NS address fetches invoked.
                       
    
                     
 
@@ -14376,7 +13323,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 NS address fetches invoked.
+                        This indicates the number of IPv6 NS address fetches invoked.
                       
    
                     
 
@@ -14389,7 +13336,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv4 NS address fetch failed.
+                        This indicates the number of failed IPv4 NS address fetches.
                       
    
                     
 
@@ -14402,7 +13349,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        IPv6 NS address fetch failed.
+                        This indicates the number of failed IPv6 NS address fetches.
                       
    
                     
 
@@ -14415,7 +13362,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        DNSSEC validation attempted.
+                        This indicates the number of attempted DNSSEC validations.
                       
    
                     
 
@@ -14428,7 +13375,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        DNSSEC validation succeeded.
+                        This indicates the number of successful DNSSEC validations.
                       
    
                     
 
@@ -14441,7 +13388,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        DNSSEC validation on negative information succeeded.
+                        This indicates the number of successful DNSSEC validations on negative information.
                       
    
                     
 
@@ -14454,7 +13401,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        DNSSEC validation failed.
+                        This indicates the number of failed DNSSEC validations.
                       
    
                     
 
@@ -14467,8 +13414,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Frequency table on round trip times (RTTs) of
-                        queries.
+                        This provides a frequency table on query round-trip times (RTTs).
                         Each nn specifies the corresponding
                         frequency.
                         In the sequence of
@@ -14480,11 +13426,11 @@ HOST-127.EXAMPLE. MX 0 .
                         number of queries whose RTTs are between
                         nn_(i-1) (inclusive) and
                         nn_i (exclusive) milliseconds.
-                        For the sake of convenience we define
+                        For the sake of convenience, we define
                         nn_0 to be 0.
                         The last entry should be represented as
                         nn_m+, which means the
-                        number of queries whose RTTs are equal to or over
+                        number of queries whose RTTs are equal to or greater than
                         nn_m milliseconds.
                       
    
                     
@@ -14501,7 +13447,7 @@ HOST-127.EXAMPLE. MX 0 .
 
             
    
               Socket I/O statistics counters are defined per socket
-              types, which are
+              type, which are
               UDP4 (UDP/IPv4),
               UDP6 (UDP/IPv6),
               TCP4 (TCP/IPv4),
@@ -14509,7 +13455,7 @@ HOST-127.EXAMPLE. MX 0 .
               Unix (Unix Domain), and
               FDwatch (sockets opened outside the
               socket module).
-              In the following table <TYPE>
+              In the following table, <TYPE>
               represents a socket type.
               Not all counters are available for all socket types;
               exceptions are noted in the description field.
@@ -14540,8 +13486,8 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Sockets opened successfully.
-                        This counter is not applicable to the
+                        This indicates the number of sockets opened successfully.
+                        This counter does not apply to the
                         FDwatch type.
                       
    
                     
@@ -14552,8 +13498,8 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Failures of opening sockets.
-                        This counter is not applicable to the
+                        This indicates the number of failures to open sockets.
+                        This counter does not apply to the
                         FDwatch type.
                       
    
                     
@@ -14564,7 +13510,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Sockets closed.
+                        This indicates the number of closed sockets.
                       
    
                     
 
@@ -14574,7 +13520,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Failures of binding sockets.
+                        This indicates the number of failures to bind sockets.
                       
    
                     
 
@@ -14584,7 +13530,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Failures of connecting sockets.
+                        This indicates the number of failures to connect sockets.
                       
    
                     
 
@@ -14594,7 +13540,7 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Connections established successfully.
+                        This indicates the number of connections established successfully.
                       
    
                     
 
@@ -14604,8 +13550,8 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Failures of accepting incoming connection requests.
-                        This counter is not applicable to the
+                        This indicates the number of failures to accept incoming connection requests.
+                        This counter does not apply to the
                         UDP and
                         FDwatch types.
                       
    
@@ -14617,8 +13563,8 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Incoming connections successfully accepted.
-                        This counter is not applicable to the
+                        This indicates the number of incoming connections successfully accepted.
+                        This counter does not apply to the
                         UDP and
                         FDwatch types.
                       
    
@@ -14630,9 +13576,9 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Errors in socket send operations.
+                        This indicates the number of errors in socket send operations.
                         This counter corresponds
-                        to SErr counter of
+                        to the SErr counter of
                         BIND 8.
                       
    
                     
@@ -14643,9 +13589,9 @@ HOST-127.EXAMPLE. MX 0 .
                     
 
                       
    
-                        Errors in socket receive operations.
-                        This includes errors of send operations on a
-                        connected UDP socket notified by an ICMP error
+                        This indicates the number of errors in socket receive operations,
+                        including errors of send operations on a
+                        connected UDP socket, notified by an ICMP error
                         message.
                       
    
                     
@@ -14662,7 +13608,7 @@ HOST-127.EXAMPLE. MX 0 .
             
    
               Most statistics counters that were available
               in BIND 8 are also supported in
-              BIND 9 as shown in the above tables.
+              BIND 9, as shown in the above tables.
               Here are notes about other counters that do not appear
               in these tables.
             
    
@@ -14671,7 +13617,7 @@ HOST-127.EXAMPLE. MX 0 .
 
    RFwdR,SFwdR
    
 
    
                   
    
-                    These counters are not supported
+                    These counters are not supported,
                     because BIND 9 does not adopt
                     the notion of forwarding
                     as BIND 8 did.
@@ -14692,9 +13638,9 @@ HOST-127.EXAMPLE. MX 0 .
 
    ROpts
    
 
    
                   
    
-                    This counter is not supported
+                    This counter is not supported,
                     because BIND 9 does not care
-                    about IP options in the first place.
+                    about IP options.
                   
    
                 
    
 
@@ -14720,6 +13666,6 @@ HOST-127.EXAMPLE. MX 0 .
 
 
 
-
    BIND 9.11.21 (Extended Support Version)
    
+
    BIND 9.11.22 (Extended Support Version)
    
 
 
diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html
index 2e0ca88ff0..63f7574e6f 100644
--- a/doc/arm/Bv9ARM.ch07.html
+++ b/doc/arm/Bv9ARM.ch07.html
@@ -52,36 +52,36 @@
 
         
    
           Access Control Lists (ACLs) are address match lists that
-          you can set up and nickname for future use in
+          can be set up and nicknamed for future use in
           allow-notify, allow-query,
           allow-query-on, allow-recursion,
           blackhole, allow-transfer,
           match-clients, etc.
         
    
         
    
-          Using ACLs allows you to have finer control over who can access
-          your name server, without cluttering up your config files with huge
+          ACLs give users finer control over who can access
+          the name server, without cluttering up configuration 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
+          control access. Limiting access to the server by
           outside parties can help prevent spoofing and denial of service
-          (DoS) attacks against your server.
+          (DoS) attacks against the server.
         
    
         
    
           ACLs match clients on the basis of up to three characteristics:
           1) The client's IP address; 2) the TSIG or SIG(0) key that was
           used to sign the request, if any; and 3) an address prefix
-          encoded in an EDNS Client Subnet option, if any.
+          encoded in an EDNS Client-Subnet option, if any.
         
    
         
    
           Here is an example of ACLs based on client addresses:
         
    
 
 
    -// Set up an ACL named "bogusnets" that will block
-// RFC1918 space and some reserved space, which is
+// Set up an ACL named "bogusnets" that blocks
+// RFC 1918 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;
@@ -120,11 +120,11 @@ zone "example.com" {
           may include key elements, which specify the
           name of a TSIG or SIG(0) key, or ecs
           elements, which specify a network prefix but are only matched
-          if that prefix matches an EDNS client subnet option included
+          if that prefix matches an EDNS client-subnet option included
           in the request.
         
    
         
    
-          The EDNS Client Subnet (ECS) option is used by a recursive
+          The EDNS Client-Subnet (ECS) option is used by a recursive
           resolver to inform an authoritative name server of the network
           address block from which the original query was received, enabling
           authoritative servers to give different answers to the same
@@ -140,7 +140,7 @@ zone "example.com" {
         
    
 
    Note
    
           
    
-            (Note: The authoritative ECS implementation in
+            (Note: the authoritative ECS implementation in
             named is based on an early version of the
             specification, and is known to have incompatibilities with
             other implementations.  It is also inefficient, requiring
@@ -157,7 +157,7 @@ zone "example.com" {
           geoip [db database] field value
         
    
         
    
-          The field indicates which field
+          The field parameter 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),
@@ -169,13 +169,13 @@ zone "example.com" {
           contains spaces or other special characters.  An "asnum"
           search for autonomous system number can be specified using
           the string "ASNNNN" or the integer NNNN.
-          When "country" search is specified with a string is two
-          characters long, then it must be a standard ISO-3166-1
-          two-letter country code; otherwise it is interpreted as
-          the full name of the country.  Similarly, if this is a
-          "region" search and the string is two characters long,
-          then it treated as a standard two-letter state or province
-          abbreviation; otherwise it treated as the full name of the
+          When "country" search is specified with a string that is two
+          characters long, it must be a standard ISO-3166-1
+          two-letter country code; otherwise, it is interpreted as
+          the full name of the country.  Similarly, if
+          "region" is the search term and the string is two characters long,
+          it is treated as a standard two-letter state or province
+          abbreviation; otherwise, it is treated as the full name of the
           state or province.
         
    
         
    
@@ -186,20 +186,20 @@ zone "example.com" {
           can be answered from either the "city" or "country" databases,
           so for these search types, specifying a
           database
-          will force the query to be answered from that database and no
+          forces 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 "country" database if it
-          is installed, in that order. Valid database names are
+          specified, these queries are first answered from the "city"
+          database if it is installed, and then from the "country" database if it
+          is installed. Valid database names are
           "country", "city", "asnum", "isp", and "domain". (If using
           the legacy GeoIP API, "netspeed" and "org" databases are also
           available.)
         
    
         
    
-          By default, if a DNS query includes an EDNS Client Subnet (ECS)
-          option which encodes a non-zero address prefix, then GeoIP ACLs
-          will be matched against that address prefix.  Otherwise, they
-          are matched against the source address of the query.  To
+          By default, if a DNS query includes an EDNS Client-Subnet (ECS)
+          option which encodes a non-zero address prefix, then GeoIP ACL
+          elements are matched against that address prefix.  Otherwise,
+          they are matched against the source address of the query.  To
           prevent GeoIP ACLs from matching against ECS options, set
           the geoip-use-ecs to no.
         
    
@@ -218,22 +218,22 @@ geoip org "Internet Systems Consortium";
 
    
 
         
    
-          ACLs use a "first-match" logic rather than "best-match":
+          ACLs use a "first-match" logic rather than "best-match";
           if an address prefix matches an ACL element, then that ACL
           is considered to have matched even if a later element would
           have matched more specifically.  For example, the ACL
-           { 10/8; !10.0.0.1; } would actually
+          { 10/8; !10.0.0.1; } would actually
           match a query from 10.0.0.1, because the first element
-          indicated that the query should be accepted, and the second
+          indicates that the query should be accepted, and the second
           element is ignored.
         
    
         
    
           When using "nested" ACLs (that is, ACLs included or referenced
-          within other ACLs), a negative match of a nested ACL will
+          within other ACLs), a negative match of a nested ACL tells
           the containing ACL to continue looking for matches.  This
           enables complex ACLs to be constructed, in which multiple
           client characteristics can be checked at the same time. For
-          example, to construct an ACL which allows queries only when
+          example, to construct an ACL which allows a query only when
           it originates from a particular network and
           only when it is signed with a particular key, use:
         
    
@@ -242,14 +242,14 @@ allow-query { !{ !10/8; any; }; key example; };

    Within the nested ACL, any address that is - not in the 10/8 network prefix will - be rejected, and this will terminate processing of the + not in the 10/8 network prefix is + rejected, which terminates processing of the ACL. Any address that is in the 10/8 - network prefix will be accepted, but this causes a negative + network prefix is accepted, but this causes a negative match of the nested ACL, so the containing ACL continues - processing. The query will then be accepted if it is signed + processing. The query is accepted if it is signed by the key "example", and rejected otherwise. The ACL, then, - will only matches when both conditions + only matches when both conditions are true.

    @@ -260,17 +260,17 @@ allow-query { !{ !10/8; any; }; key example; };

    - On UNIX servers, it is possible to run BIND + On Unix servers, it is possible to run BIND in a chrooted environment (using the chroot() function) by specifying the -t option for named. This can help improve system security by placing - BIND in a "sandbox", which will limit + BIND in a "sandbox," which limits 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 ( -u user ). + Another useful feature in the Unix version of BIND is the + ability to run the daemon as an unprivileged user (-u user). We suggest running as an unprivileged user when using the chroot feature.

    @@ -287,23 +287,23 @@ allow-query { !{ !10/8; any; }; key example; }; The chroot Environment

    - In order for a chroot environment + 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 + /var/named), the + environment must include 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 + filesystem; the values of options like directory and - pid-file to account for this. + pid-file must be adjusted 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 + Unlike with earlier versions of BIND, + named does not typically need to be compiled + statically, nor do shared libraries need to be installed under the new root. + However, depending on the operating system, it may be necessary + to set up locations such as /dev/zero, /dev/random, /dev/log, and @@ -323,14 +323,14 @@ allow-query { !{ !10/8; any; }; key example; }; modification times) or the chown utility (to set the user id and/or group id) on files - to which you want BIND - to write. + where BIND + should write.

    Note

    If the named daemon is running as an - unprivileged user, it will not be able to bind to new restricted + unprivileged user, it cannot bind to new restricted ports if the server is reloaded.

    @@ -350,16 +350,16 @@ allow-query { !{ !10/8; any; }; key example; }; or network prefix in the allow-update zone option. - This method is insecure since the source address of the update UDP + 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 + address of a secondary + server which performs forwarding of dynamic updates, the primary 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. + trivially attacked by sending the update to the secondary, which + forwards it to the primary with its own source IP address - causing the + primary to approve it without question.

    @@ -368,16 +368,16 @@ allow-query { !{ !10/8; any; }; key example; }; (TSIG). That is, the allow-update option should list only TSIG key names, not IP addresses or network - prefixes. Alternatively, the new update-policy + prefixes. Alternatively, the update-policy option can be used.

    - Some sites choose to keep all dynamically-updated DNS data + 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 + 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 + of public web and mail servers, need not allow dynamic update at all.

    @@ -400,6 +400,6 @@ allow-query { !{ !10/8; any; }; key example; }; -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html index bbd34eece3..f0625658fd 100644 --- a/doc/arm/Bv9ARM.ch08.html +++ b/doc/arm/Bv9ARM.ch08.html @@ -37,7 +37,7 @@

    Table of Contents

    Common Problems
    -
    It's not working; how can I figure out what's wrong?
    +
    It's Not Working; How Can I Figure Out What's Wrong?
    Incrementing and Changing the Serial Number
    Where Can I Get Help?
    @@ -49,14 +49,14 @@

    -It's not working; how can I figure out what's wrong?

    +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 + The best solution to installation and + configuration issues is to take preventive 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. + source of hints and information that can be used to identify + what went wrong and fix the problem.

    @@ -66,29 +66,29 @@ Incrementing and Changing the Serial Number

    - Zone serial numbers are just numbers — they aren't - date related. A lot of people set them to a number that + Zone serial numbers are just numbers — they are not + date-related. However, many people set them to a number that represents a date, usually of the form YYYYMMDDRR. - Occasionally they will make a mistake and set them to a - "date in the future" then try to correct them by setting - them to the "current date". This causes problems because + Occasionally they make a mistake and set the serial number to a + date in the future, then try to correct it by setting + it to the current date. This causes problems because serial numbers are used to indicate that a zone has been - updated. If the serial number on the slave server is - lower than the serial number on the master, the slave - server will attempt to update its copy of the zone. + updated. If the serial number on the secondary server is + lower than the serial number on the primary, the secondary + server attempts 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 + Setting the serial number to a lower number on the primary + server than the one on the secondary server means that the secondary 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. + number, reload the zone and make sure all secondaries have updated to + the new zone serial number, then reset it to the desired number + and reload the zone again.

    @@ -97,25 +97,25 @@ 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. + The BIND-users mailing list, at https://lists.isc.org/mailman/listinfo/bind-users, + is an excellent resource for peer user support. In addition, ISC maintains a + Knowledgebase of helpful articles at https://kb.isc.org.

    - 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. + Internet Systems Consortium + (ISC) offers annual + support agreements for BIND9, ISC DHCP, and Kea DHCP. + All paid support contracts include advance security notifications; some levels include + service level agreements (SLAs), premium software features, and increased priority on bug fixes + and feature requests. +

    + +

    + Please contact + info@isc.org or visit + https://www.isc.org/contact/ + for more information.

    @@ -136,6 +136,6 @@ -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html index 95a0b879d7..0c9f207d86 100644 --- a/doc/arm/Bv9ARM.ch09.html +++ b/doc/arm/Bv9ARM.ch09.html @@ -36,11 +36,12 @@

    Table of Contents

    -
    Release Notes for BIND Version 9.11.21
    +
    Release Notes for BIND Version 9.11.22
    Introduction
    Download
    License Change
    +
    Notes for BIND 9.11.22
    Notes for BIND 9.11.21
    Notes for BIND 9.11.20
    Notes for BIND 9.11.19
    @@ -70,7 +71,7 @@

    -Release Notes for BIND Version 9.11.21

    +Release Notes for BIND Version 9.11.22

    @@ -128,6 +129,77 @@

    +Notes for BIND 9.11.22

    + +
    +

    +Security Fixes

    +
      +
    • +

      + It was possible to trigger an assertion failure when verifying the + response to a TSIG-signed request. This was disclosed in + CVE-2020-8622. +

      +

      + ISC would like to thank Dave Feldman, Jeff Warren, and Joel Cunningham + of Oracle for bringing this vulnerability to our attention. [GL #2028] +

      +
      • +
    • +

      + When BIND 9 was compiled with native PKCS#11 support, it was possible + to trigger an assertion failure in code determining the number of bits + in the PKCS#11 RSA public key with a specially crafted packet. This + was disclosed in CVE-2020-8623. +

      +

      + ISC would like to thank Lyu Chiy for bringing this vulnerability to + our attention. [GL #2037] +

      +
      • +
    • +

      + update-policy rules of type + subdomain were incorrectly treated as + zonesub rules, which allowed keys used in + subdomain rules to update names outside of the + specified subdomains. The problem was fixed by making sure + subdomain rules are again processed as described in + the ARM. This was disclosed in CVE-2020-8624. +

      +

      + ISC would like to thank Joop Boonen of credativ GmbH for bringing this + vulnerability to our attention. [GL #2055] +

      +
      • +
    +
    + +
    +

    +Bug Fixes

    +
      +
    • +

      + Wildcard RPZ passthru rules could incorrectly be overridden by other + rules that were loaded from RPZ zones which appeared later in the + response-policy statement. This has been fixed. + [GL #1619] +

      +
      • +
    • +

      + LMDB locking code was revised to make rndc reconfig + work properly on FreeBSD and with LMDB >= 0.9.26. [GL #1976] +

      +
      • +
    +
    + +
    +
    +

    Notes for BIND 9.11.21

    @@ -2292,6 +2364,6 @@
    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/Bv9ARM.ch10.html b/doc/arm/Bv9ARM.ch10.html index 59fb0ac342..cf3414990d 100644 --- a/doc/arm/Bv9ARM.ch10.html +++ b/doc/arm/Bv9ARM.ch10.html @@ -36,8 +36,8 @@ A Brief History of the DNS and BIND

    - Although the "official" beginning of the Domain Name - System occurred in 1984 with the publication of RFC 920, the + Although the Domain Name + System "officially" began 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 @@ -45,14 +45,14 @@ 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 + "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 + 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 @@ -73,7 +73,7 @@ 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 + 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 @@ -87,7 +87,7 @@

    BIND versions 4.9 and 4.9.1 were released by Digital Equipment - Corporation (now Compaq Computer Corporation). Paul Vixie, then + Corporation (which became Compaq Computer Corporation and eventually merged with Hewlett-Packard). Paul Vixie, then a DEC employee, became BIND's primary caretaker. He was assisted by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan @@ -105,8 +105,8 @@

    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 Internet Systems Consortium and its predecessor, + the Internet Software Consortium, with support provided by ISC's sponsors.

    @@ -127,7 +127,8 @@

    BIND development work is made possible today by the sponsorship - of several corporations, and by the tireless work efforts of + of corporations who purchase professional support services from ISC + (https://www.isc.org/contact/) and/or donate to our mission, and by the tireless efforts of numerous individuals.

    @@ -148,6 +149,6 @@ -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/Bv9ARM.ch11.html b/doc/arm/Bv9ARM.ch11.html index 36fa376f01..b275886067 100644 --- a/doc/arm/Bv9ARM.ch11.html +++ b/doc/arm/Bv9ARM.ch11.html @@ -51,15 +51,15 @@ IPv6 addresses (AAAA)

    - IPv6 addresses are 128-bit identifiers for interfaces and - sets of interfaces which were introduced in the DNS to facilitate + 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 Global Unicast Address Format."

    IPv6 unicast addresses consist of a @@ -69,12 +69,12 @@

    The global routing prefix is provided by the - upstream provider or ISP, and (roughly) corresponds to the + upstream provider or ISP, and roughly corresponds to the IPv4 network section of the address range. - The subnet identifier is for local subnetting, much the - same as subnetting an + The subnet identifier is for local subnetting, much + like subnetting an IPv4 /16 network into /24 subnets. The interface identifier is the address of an individual @@ -83,24 +83,24 @@

    The subnetting capability of IPv6 is much more flexible than - that of IPv4: subnetting can be carried out on bit boundaries, + 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, + 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 + 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 + them. The double colon ("::") indicates the longest possible string of zeros that can fit, and can be used only once in an address.

    @@ -119,29 +119,23 @@ 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: + Engineering Steering Group (IESG). RFCs can be obtained online at:

    - - ftp://www.isi.edu/in-notes/RFCxxxx.txt + + https://datatracker.ietf.org/doc/

    -

    - (where xxxx is - the number of the RFC). RFCs are also available via the Web at: -

    -

    - http://www.ietf.org/rfc/. -

    +
    -

    +

    -Standards

    +Standards
    -

    [RFC974] +

    [RFC974] C. Partridge. Mail Routing and the Domain System. @@ -149,7 +143,7 @@

    -

    [RFC1034] +

    [RFC1034] P.V. Mockapetris. Domain Names — Concepts and Facilities. @@ -157,7 +151,7 @@

    -

    [RFC1035] +

    [RFC1035] P. V. Mockapetris. Domain Names — Implementation and Specification. @@ -171,7 +165,7 @@

    -

    [RFC2181] +

    [RFC2181] R., R. Bush Elz. Clarifications to the DNS @@ -180,7 +174,7 @@

    -

    [RFC2308] +

    [RFC2308] M. Andrews. Negative Caching of DNS @@ -189,7 +183,7 @@

    -

    [RFC1995] +

    [RFC1995] M. Ohta. Incremental Zone Transfer in DNS. @@ -197,7 +191,7 @@

    -

    [RFC1996] +

    [RFC1996] P. Vixie. A Mechanism for Prompt Notification of Zone Changes. @@ -205,7 +199,7 @@

    -

    [RFC2136] +

    [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System. @@ -213,7 +207,7 @@

    -

    [RFC2671] +

    [RFC2671] P. Vixie. Extension Mechanisms for DNS (EDNS0). @@ -221,7 +215,7 @@

    -

    [RFC2672] +

    [RFC2672] M. Crawford. Non-Terminal DNS Name Redirection. @@ -229,7 +223,7 @@

    -

    [RFC2845] +

    [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington. Secret Key Transaction Authentication for DNS (TSIG). @@ -237,7 +231,7 @@

    -

    [RFC2930] +

    [RFC2930] D. Eastlake, 3rd. Secret Key Establishment for DNS (TKEY RR). @@ -245,7 +239,7 @@

    -

    [RFC2931] +

    [RFC2931] D. Eastlake, 3rd. DNS Request and Transaction Signatures (SIG(0)s). @@ -253,7 +247,7 @@

    -

    [RFC3007] +

    [RFC3007] B. Wellington. Secure Domain Name System (DNS) Dynamic Update. @@ -261,7 +255,7 @@

    -

    [RFC3645] +

    [RFC3645] S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, and R. Hall. Generic Security Service Algorithm for Secret @@ -273,10 +267,10 @@

    -DNS Security Proposed Standards

    +DNS Security Proposed Standards
    -

    [RFC3225] +

    [RFC3225] D. Conrad. Indicating Resolver Support of DNSSEC. @@ -284,7 +278,7 @@

    -

    [RFC3833] +

    [RFC3833] D. Atkins and R. Austein. Threat Analysis of the Domain Name System (DNS). @@ -292,7 +286,7 @@

    -

    [RFC4033] +

    [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Introduction and Requirements. @@ -300,7 +294,7 @@

    -

    [RFC4034] +

    [RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource Records for the DNS Security Extensions. @@ -308,7 +302,7 @@

    -

    [RFC4035] +

    [RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Protocol Modifications for the DNS @@ -319,11 +313,11 @@

    -Other Important RFCs About DNS +Other Important RFCs About DNS Implementation

    -

    [RFC1535] +

    [RFC1535] E. Gavron. A Security Problem and Proposed Correction With Widely @@ -332,7 +326,7 @@

    -

    [RFC1536] +

    [RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. Common DNS Implementation @@ -341,7 +335,7 @@

    -

    [RFC1982] +

    [RFC1982] R. Elz and R. Bush. Serial Number Arithmetic. @@ -349,7 +343,7 @@

    -

    [RFC4074] +

    [RFC4074] Y. Morishita and T. Jinmei. Common Misbehaviour Against DNS @@ -360,10 +354,10 @@

    -Resource Record Types

    +Resource Record Types
    -

    [RFC1183] +

    [RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris. New DNS RR Definitions. @@ -371,7 +365,7 @@

    -

    [RFC1706] +

    [RFC1706] B. Manning and R. Colella. DNS NSAP Resource Records. @@ -379,7 +373,7 @@

    -

    [RFC2168] +

    [RFC2168] R. Daniel and M. Mealling. Resolution of Uniform Resource Identifiers using @@ -388,7 +382,7 @@

    -

    [RFC1876] +

    [RFC1876] C. Davis, P. Vixie, T., and I. Dickinson. A Means for Expressing Location Information in the @@ -398,7 +392,7 @@

    -

    [RFC2052] +

    [RFC2052] A. Gulbrandsen and P. Vixie. A DNS RR for Specifying the @@ -408,7 +402,7 @@

    -

    [RFC2163] +

    [RFC2163] A. Allocchio. Using the Internet DNS to @@ -418,7 +412,7 @@

    -

    [RFC2230] +

    [RFC2230] R. Atkinson. Key Exchange Delegation Record for the DNS. @@ -426,7 +420,7 @@

    -

    [RFC2536] +

    [RFC2536] D. Eastlake, 3rd. DSA KEYs and SIGs in the Domain Name System (DNS). @@ -434,7 +428,7 @@

    -

    [RFC2537] +

    [RFC2537] D. Eastlake, 3rd. RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). @@ -442,7 +436,7 @@

    -

    [RFC2538] +

    [RFC2538] D. Eastlake, 3rd and O. Gudmundsson. Storing Certificates in the Domain Name System (DNS). @@ -450,7 +444,7 @@

    -

    [RFC2539] +

    [RFC2539] D. Eastlake, 3rd. Storage of Diffie-Hellman Keys in the Domain Name System (DNS). @@ -458,7 +452,7 @@

    -

    [RFC2540] +

    [RFC2540] D. Eastlake, 3rd. Detached Domain Name System (DNS) Information. @@ -466,7 +460,7 @@

    -

    [RFC2782] +

    [RFC2782] A. Gulbrandsen. P. Vixie. @@ -476,7 +470,7 @@

    -

    [RFC2915] +

    [RFC2915] M. Mealling. R. Daniel. @@ -485,7 +479,7 @@

    -

    [RFC3110] +

    [RFC3110] D. Eastlake, 3rd. RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). @@ -493,7 +487,7 @@

    -

    [RFC3123] +

    [RFC3123] P. Koch. A DNS RR Type for Lists of Address Prefixes (APL RR). @@ -501,7 +495,7 @@

    -

    [RFC3596] +

    [RFC3596] S. Thomson, C. Huitema, V. Ksinant, and M. Souissi. DNS Extensions to support IP @@ -510,7 +504,7 @@

    -

    [RFC3597] +

    [RFC3597] A. Gustafsson. Handling of Unknown DNS Resource Record (RR) Types. @@ -520,10 +514,10 @@

    -DNS and the Internet

    +DNS and the Internet
    -

    [RFC1101] +

    [RFC1101] P. V. Mockapetris. DNS Encoding of Network Names @@ -532,7 +526,7 @@

    -

    [RFC1123] +

    [RFC1123] Braden. Requirements for Internet Hosts - Application and @@ -541,7 +535,7 @@

    -

    [RFC1591] +

    [RFC1591] J. Postel. Domain Name System Structure and Delegation. @@ -549,7 +543,7 @@

    -

    [RFC2317] +

    [RFC2317] H. Eidnes, G. de Groot, and P. Vixie. Classless IN-ADDR.ARPA Delegation. @@ -557,7 +551,7 @@

    -

    [RFC2826] +

    [RFC2826] Internet Architecture Board. IAB Technical Comment on the Unique DNS Root. @@ -565,7 +559,7 @@

    -

    [RFC2929] +

    [RFC2929] D. Eastlake, 3rd, E. Brunner-Williams, and B. Manning. Domain Name System (DNS) IANA Considerations. @@ -575,10 +569,10 @@

    -DNS Operations

    +DNS Operations
    -

    [RFC1033] +

    [RFC1033] M. Lottor. Domain administrators operations guide. @@ -586,7 +580,7 @@

    -

    [RFC1537] +

    [RFC1537] P. Beertema. Common DNS Data File @@ -595,7 +589,7 @@

    -

    [RFC1912] +

    [RFC1912] D. Barr. Common DNS Operational and @@ -604,7 +598,7 @@

    -

    [RFC2010] +

    [RFC2010] B. Manning and P. Vixie. Operational Criteria for Root Name Servers. @@ -612,7 +606,7 @@

    -

    [RFC2219] +

    [RFC2219] M. Hamilton and R. Wright. Use of DNS Aliases for @@ -623,10 +617,10 @@

    -Internationalized Domain Names

    +Internationalized Domain Names
    -

    [RFC2825] +

    [RFC2825] IAB and R. Daigle. A Tangled Web: Issues of I18N, Domain Names, @@ -635,7 +629,7 @@

    -

    [RFC3490] +

    [RFC3490] P. Faltstrom, P. Hoffman, and A. Costello. Internationalizing Domain Names in Applications (IDNA). @@ -643,7 +637,7 @@

    -

    [RFC3491] +

    [RFC3491] P. Hoffman and M. Blanchet. Nameprep: A Stringprep Profile for Internationalized Domain Names. @@ -651,7 +645,7 @@

    -

    [RFC3492] +

    [RFC3492] A. Costello. Punycode: A Bootstring encoding of Unicode @@ -663,7 +657,7 @@

    -Other DNS-related RFCs

    +Other DNS-related RFCs

    Note

    @@ -674,7 +668,7 @@

    -

    [RFC1464] +

    [RFC1464] R. Rosenbaum. Using the Domain Name System To Store Arbitrary String @@ -683,7 +677,7 @@

    -

    [RFC1713] +

    [RFC1713] A. Romao. Tools for DNS Debugging. @@ -691,7 +685,7 @@

    -

    [RFC1794] +

    [RFC1794] T. Brisco. DNS Support for Load @@ -700,7 +694,7 @@

    -

    [RFC2240] +

    [RFC2240] O. Vaughan. A Legal Basis for Domain Name Allocation. @@ -708,7 +702,7 @@

    -

    [RFC2345] +

    [RFC2345] J. Klensin, T. Wolf, and G. Oglesby. Domain Names and Company Name Retrieval. @@ -716,7 +710,7 @@

    -

    [RFC2352] +

    [RFC2352] O. Vaughan. A Convention For Using Legal Names as Domain Names. @@ -724,7 +718,7 @@

    -

    [RFC3071] +

    [RFC3071] J. Klensin. Reflections on the DNS, RFC 1591, and Categories of Domains. @@ -732,7 +726,7 @@

    -

    [RFC3258] +

    [RFC3258] T. Hardie. Distributing Authoritative Name Servers via @@ -741,7 +735,7 @@

    -

    [RFC3901] +

    [RFC3901] A. Durand and J. Ihren. DNS IPv6 Transport Operational Guidelines. @@ -751,10 +745,10 @@

    -Obsolete and Unimplemented Experimental RFC

    +Obsolete and Unimplemented Experimental RFC
    -

    [RFC1712] +

    [RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni. DNS Encoding of Geographical @@ -763,7 +757,7 @@

    -

    [RFC2673] +

    [RFC2673] M. Crawford. Binary Labels in the Domain Name System. @@ -771,7 +765,7 @@

    -

    [RFC2874] +

    [RFC2874] M. Crawford and C. Huitema. DNS Extensions to Support IPv6 Address Aggregation @@ -782,7 +776,7 @@

    -Obsoleted DNS Security RFCs

    +Obsoleted DNS Security RFCs

    Note

    @@ -792,7 +786,7 @@

    -

    [RFC2065] +

    [RFC2065] D. Eastlake, 3rd and C. Kaufman. Domain Name System Security Extensions. @@ -800,7 +794,7 @@

    -

    [RFC2137] +

    [RFC2137] D. Eastlake, 3rd. Secure Domain Name System Dynamic Update. @@ -808,7 +802,7 @@

    -

    [RFC2535] +

    [RFC2535] D. Eastlake, 3rd. Domain Name System Security Extensions. @@ -816,7 +810,7 @@

    -

    [RFC3008] +

    [RFC3008] B. Wellington. Domain Name System Security (DNSSEC) @@ -825,7 +819,7 @@

    -

    [RFC3090] +

    [RFC3090] E. Lewis. DNS Security Extension Clarification on Zone Status. @@ -833,7 +827,7 @@

    -

    [RFC3445] +

    [RFC3445] D. Massey and S. Rose. Limiting the Scope of the KEY Resource Record (RR). @@ -841,7 +835,7 @@

    -

    [RFC3655] +

    [RFC3655] B. Wellington and O. Gudmundsson. Redefinition of DNS Authenticated Data (AD) bit. @@ -849,7 +843,7 @@

    -

    [RFC3658] +

    [RFC3658] O. Gudmundsson. Delegation Signer (DS) Resource Record (RR). @@ -857,7 +851,7 @@

    -

    [RFC3755] +

    [RFC3755] S. Weiler. Legacy Resolver Compatibility for Delegation Signer (DS). @@ -865,7 +859,7 @@

    -

    [RFC3757] +

    [RFC3757] O. Kolkman, J. Schlyter, and E. Lewis. Domain Name System KEY (DNSKEY) Resource Record @@ -874,7 +868,7 @@

    -

    [RFC3845] +

    [RFC3845] J. Schlyter. DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. @@ -935,6 +929,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/Bv9ARM.ch12.html b/doc/arm/Bv9ARM.ch12.html index e523161559..5521522a32 100644 --- a/doc/arm/Bv9ARM.ch12.html +++ b/doc/arm/Bv9ARM.ch12.html @@ -66,7 +66,7 @@

    • - The "DNS client" module. This is a higher level API that + The "DNS client" module. This is a higher-level API that provides an interface to name resolution, single DNS transaction with a particular server, and dynamic update. Regarding name resolution, it supports advanced features such as DNSSEC validation @@ -110,11 +110,11 @@ $ make install

      - Normal installation of BIND will also install library object + Normal installation of BIND also installs library object and header files. Root privilege is normally required.

      - To see how to build your own application after the installation, see + To see how to build a custom application after the installation, see lib/samples/Makefile-postinstall.in.

    @@ -126,9 +126,9 @@ $ make install

  • The "fixed" RRset order is not (currently) supported in the export - library. If you want to use "fixed" RRset order for, e.g. + library. To use "fixed" RRset order for, e.g., named while still building the export library - even without the fixed order support, build them separately: + even without the fixed-order support, build them separately: 

     $ ./configure --enable-fixed-rrset [other flags, but not --enable-exportlib]
@@ -143,9 +143,9 @@ $ make
 
  • 
         
    
 	RFC 5011 is not supported in the validating stub resolver of the
-	export library. In fact, it is not clear whether it should: trust
+	export library. In fact, it is not clear whether it should be: trust
 	anchors would be a system-wide configuration which would be managed
-	by an administrator, while the stub resolver will be used by
+	by an administrator, while the stub resolver is used by
 	ordinary applications run by a normal user.
       
    
       
    • 
@@ -164,9 +164,9 @@ $ make
     
     
    
       The IRS library supports an "advanced" configuration file related to
-      the DNS library for configuration parameters that would be beyond the
+      the DNS library, for configuration parameters that would be beyond the
       capability of the resolv.conf file.
-      Specifically, it is intended to provide DNSSEC related configuration
+      Specifically, it is intended to provide DNSSEC-related configuration
       parameters. By default the path to this configuration file is
       /etc/dns.conf.  This module is very experimental
       and the configuration syntax or library interfaces may change in
@@ -190,10 +190,10 @@ $ make
 sample: a simple stub resolver utility

    • - Sends a query of a given name (of a given optional RR type) to a + This sends a query of a given name (of a given optional RR type) to a specified recursive server and prints the result as a list of RRs. It can also act as a validating stub resolver if a trust anchor is - given via a set of command line options. + given via a set of command-line options.

    Usage: sample [options] server_address hostname @@ -205,13 +205,13 @@ $ make

    -t RRtype

    - specify the RR type of the query. The default is the A RR. + specifies the RR type of the query. The default is the A RR.

    [-a algorithm] [-e] -k keyname -K keystring

    - specify a command-line DNS key to validate the answer. For + specifies a command-line DNS key to validate the answer. For example, to specify the following DNSKEY of example.com:


    @@ -226,27 +226,27 @@ $ make

    -e means that this key is a zone's "key signing key" (also known as "secure entry point"). - When -a is omitted rsasha1 will be used by default. + When -a is omitted rsasha1 is used by default.

    -s domain:alt_server_address

    - specify a separate recursive server address for the specific + specifies a separate recursive server address for the specific "domain". Example: -s example.com:2001:db8::1234

    server_address

    - an IP(v4/v6) address of the recursive server to which queries + is an IP(v4/v6) address of the recursive server to which queries are sent.

    hostname

    - the domain name for the query + is the domain name for the query

    @@ -256,7 +256,7 @@ $ make sample-async: a simple stub resolver, working asynchronously

    - Similar to "sample", but accepts a list + This is similar to "sample", but accepts a list of (query) domain names as a separate file and resolves the names asynchronously.

    @@ -267,18 +267,18 @@ $ make

    -s server_address
    - an IPv4 address of the recursive server to which queries are sent. - (IPv6 addresses are not supported in this implementation) + is an IPv4 address of the recursive server to which queries are sent. + (IPv6 addresses are not supported in this implementation.)
    -t RR_type
    - specify the RR type of the queries. The default is the A + specifies the RR type of the queries. The default is the A RR.
    input_file
    - a list of domain names to be resolved. each line consists of a - single domain name. Example: + is a list of domain names to be resolved; each line consists of a + single domain name. For example:


          www.example.com
          mx.example.net
    @@ -292,8 +292,8 @@ $ make sample-request: a simple DNS transaction client

    - Sends a query to a specified server, and prints the response with - minimal processing. It doesn't act as a "stub resolver": it stops + sends a query to a specified server, and prints the response with + minimal processing. It does not act as a "stub resolver": it stops the processing once it gets any response from the server, whether it's a referral or an alias (CNAME or DNAME) that would require further queries to get the ultimate answer. In other words, this @@ -309,20 +309,20 @@ $ make

    -t RRtype

    - specify the RR type of the queries. The default is the A RR. + specifies the RR type of the queries. The default is the A RR.

    server_address

    - an IP(v4/v6) address of the recursive server to which + is an IP(v4/v6) address of the recursive server to which the query is sent.

    hostname

    - the domain name for the query + is the domain name for the query

    @@ -332,15 +332,15 @@ $ make sample-gai: getaddrinfo() and getnameinfo() test code

    - This is a test program to check getaddrinfo() and + is a test program to check getaddrinfo() and getnameinfo() behavior. It takes a host name as an argument, calls getaddrinfo() with the given host name, and calls getnameinfo() with the resulting IP addresses returned by getaddrinfo(). If the dns.conf file exists and defines a trust anchor, the underlying - resolver will act as a validating resolver, and + resolver acts as a validating resolver, and getaddrinfo()/getnameinfo() - will fail with an EAI_INSECUREDATA error when DNSSEC validation + fails with an EAI_INSECUREDATA error when DNSSEC validation fails.

    @@ -352,7 +352,7 @@ $ make sample-update: a simple dynamic update client program

    - Accepts a single update command as a command-line argument, sends + accepts a single update command as a command-line argument, sends an update request message to the authoritative server, and shows the response from the server. In other words, this is a simplified nsupdate. @@ -367,7 +367,7 @@ $ make

    -a auth_server

    - An IP address of the authoritative server that has authority + is an IP address of the authoritative server that has authority for the zone containing the update name. This should normally be the primary authoritative server that accepts dynamic updates. It can also be a secondary server that is @@ -377,23 +377,23 @@ $ make

    -k keyfile

    - A TSIG key file to secure the update transaction. The + is a TSIG key file to secure the update transaction. The keyfile format is the same as that for the nsupdate utility.

    -p prerequisite

    - A prerequisite for the update (only one prerequisite can be - specified). The prerequisite format is the same as that is + is a prerequisite for the update; only one prerequisite can be + specified. The prerequisite format is the same as that accepted by the nsupdate utility.

    -r recursive_server

    - An IP address of a recursive server that this utility will - use. A recursive server may be necessary to identify the + is an IP address of a recursive server that this utility + uses. A recursive server may be necessary to identify the authoritative server address to which the update request is sent.

    @@ -401,21 +401,21 @@ $ make
    -z zonename

    - The domain name of the zone that contains + is the domain name of the zone that it contains.

    (add|delete)

    - Specify the type of update operation. Either "add" or + specifies the type of update operation. Either "add" or "delete" must be specified.

    "update data"

    - Specify the data to be updated. A typical example of the - data would look like "name TTL RRtype RDATA". + specifies the data to be updated. A typical example of the + data looks like "name TTL RRtype RDATA".

    @@ -452,7 +452,7 @@ $ sample-update -a sample-update -k Kxxx.+nnn+mm nsprobe: domain/name server checker in terms of RFC 4074

    - Checks a set of domains to see the name servers of the domains + checks a set of domains to ensure the name servers of the domains behave correctly in terms of RFC 4074. This is included in the set of sample programs to show how the export library can be used in a DNS-related application. @@ -467,21 +467,21 @@ $ sample-update -a sample-update -k Kxxx.+nnn+mm

    -d

    - Run in "debug" mode. With this option nsprobe will dump - every RRs it receives. + runs in "debug" mode. With this option, nsprobe dumps + every RR it receives.

    -v

    - Increase verbosity of other normal log messages. This can be + increases verbosity of other normal log messages. This can be specified multiple times.

    -c cache_address

    - Specify an IP address of a recursive (caching) name server. + specifies an IP address of a recursive (caching) name server. nsprobe uses this server to get the NS RRset of each domain and the A and/or AAAA RRsets for the name servers. The default value is 127.0.0.1. @@ -490,14 +490,14 @@ $ sample-update -a sample-update -k Kxxx.+nnn+mm

    input_file

    - A file name containing a list of domain (zone) names to be - probed. when omitted the standard input will be used. Each - line of the input file specifies a single domain name such as - "example.com". In general this domain name must be the apex - name of some DNS zone (unlike normal "host names" such as - "www.example.com"). nsprobe first identifies the NS RRsets + is a file name containing a list of domain (zone) names to be + probed. when omitted the standard input is used. Each + line of the input file specifies a single domain name, such as + "example.com". In general, this domain name must be the apex + name of some DNS zone, unlike normal "host names" such as + "www.example.com". nsprobe first identifies the NS RRsets for the given domain name, and sends A and AAAA queries to - these servers for some "widely used" names under the zone; + these servers for some widely used names under the zone; specifically, adding "www" and "ftp" to the zone name.

    @@ -533,6 +533,6 @@ $ sample-update -a sample-update -k Kxxx.+nnn+mm -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/Bv9ARM.ch13.html b/doc/arm/Bv9ARM.ch13.html index d09c4d628d..c72e3b2ff3 100644 --- a/doc/arm/Bv9ARM.ch13.html +++ b/doc/arm/Bv9ARM.ch13.html @@ -14,7 +14,7 @@ - +
    @@ -24,7 +24,7 @@ Prev    - Next + Next @@ -40,19 +40,16 @@

    Table of Contents

    -dig — DNS lookup utility +arpaname — translate IP addresses to the corresponding ARPA names
    -mdig — DNS pipelined lookup utility -
    -
    -host — DNS lookup utility +ddns-confgen — ddns key generation tool
    delv — DNS lookup and validation utility
    -nslookup — query Internet name servers interactively +dig — DNS lookup utility
    dnssec-checkds — DNSSEC delegation consistency checking tool @@ -88,13 +85,22 @@ dnssec-verify — DNSSEC zone verification tool
    +dnstap-read — print dnstap data in human-readable form +
    +
    +genrandom — generate a file containing random data +
    +
    +host — DNS lookup utility +
    +
    +isc-hmac-fixup — fixes HMAC keys generated by older versions of BIND +
    +
    lwresd — lightweight resolver daemon
    -named — Internet domain name server -
    -
    -named.conf — configuration file for named +mdig — DNS pipelined lookup utility
    named-checkconf — named configuration file syntax checking tool @@ -114,47 +120,41 @@ named-rrchecker — syntax checker for individual DNS resource records
    -nsupdate — Dynamic DNS update utility +named.conf — configuration file for named
    -rndc — name server control utility -
    -
    -rndc.conf — rndc configuration file -
    -
    -rndc-confgen — rndc key generation tool -
    -
    -ddns-confgen — ddns key generation tool -
    -
    -arpaname — translate IP addresses to the corresponding ARPA names -
    -
    -dnstap-read — print dnstap data in human-readable form -
    -
    -genrandom — generate a file containing random data -
    -
    -isc-hmac-fixup — fixes HMAC keys generated by older versions of BIND +named — Internet domain name server
    nsec3hash — generate NSEC3 hash
    -pkcs11-destroy — destroy PKCS#11 objects +nslookup — query Internet name servers interactively
    -pkcs11-list — list PKCS#11 objects +nsupdate — Dynamic DNS update utility +
    +
    +pkcs11-destroy — destroy PKCS#11 objects
    pkcs11-keygen — generate keys on a PKCS#11 device
    +pkcs11-list — list PKCS#11 objects +
    +
    pkcs11-tokens — list PKCS#11 available tokens
    +
    +rndc-confgen — rndc key generation tool +
    +
    +rndc.conf — rndc configuration file +
    +
    +rndc — name server control utility +
    @@ -185,8 +185,8 @@ - - + + @@ -203,16 +203,17 @@ Prev    - Next + Next Appendix D. BIND 9 DNS Library Support  Home - dig + arpaname + -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html index 5007d422df..e7c6186f12 100644 --- a/doc/arm/Bv9ARM.html +++ b/doc/arm/Bv9ARM.html @@ -32,7 +32,7 @@

    BIND 9 Administrator Reference Manual

    -

    BIND Version 9.11.21

    +

    BIND Version 9.11.22

    Copyright © 2000-2020 Internet Systems Consortium, Inc. ("ISC")

    @@ -60,7 +60,7 @@
    Hardware requirements
    CPU Requirements
    Memory Requirements
    -
    Name Server Intensive Environment Issues
    +
    Name Server-Intensive Environment Issues
    Supported Operating Systems
    3. Name Server Configuration
    @@ -81,14 +81,14 @@
    Notify
    Dynamic Update
    -
    The journal file
    +
    The Journal File
    Incremental Zone Transfers (IXFR)
    Split DNS
    -
    Example split DNS setup
    +
    Example Split DNS Setup
    TSIG
    Generating a Shared Key
    -
    Loading A New Key
    +
    Loading a New Key
    Instructing the Server to Use a Key
    TSIG-Based Access Control
    Errors
    @@ -99,22 +99,22 @@
    Generating Keys
    Signing the Zone
    -
    Configuring Servers
    +
    Configuring Servers for DNSSEC
    DNSSEC, Dynamic Zones, and Automatic Signing
    Converting from insecure to secure
    -
    Dynamic DNS update method
    -
    Fully automatic zone signing
    -
    Private-type records
    -
    DNSKEY rollovers
    -
    Dynamic DNS update method
    -
    Automatic key rollovers
    -
    NSEC3PARAM rollovers via UPDATE
    -
    Converting from NSEC to NSEC3
    -
    Converting from NSEC3 to NSEC
    -
    Converting from secure to insecure
    -
    Periodic re-signing
    +
    Dynamic DNS Update Method
    +
    Fully Automatic Zone Signing
    +
    Private Type Records
    +
    DNSKEY Rollovers
    +
    Dynamic DNS Update Method
    +
    Automatic Key Rollovers
    +
    NSEC3PARAM Rollovers via UPDATE
    +
    Converting From NSEC to NSEC3
    +
    Converting From NSEC3 to NSEC
    +
    Converting From Secure to Insecure
    +
    Periodic Re-signing
    NSEC3 and OPTOUT
    Dynamic Trust Anchor Management
    @@ -122,7 +122,7 @@
    Validating Resolver
    Authoritative Server
    -
    PKCS#11 (Cryptoki) support
    +
    PKCS#11 (Cryptoki) Support
    Prerequisites
    Native PKCS#11
    @@ -137,7 +137,7 @@
    Configuring DLZ
    Sample DLZ Driver
    -
    DynDB (Dynamic Database)
    +
    Dynamic Database (DynDB)
    Configuring DynDB
    Sample DynDB Module
    @@ -146,12 +146,12 @@
    Principle of Operation
    Configuring Catalog Zones
    -
    Catalog Zone format
    +
    Catalog Zone Format
    IPv6 Support in BIND 9
    Address Lookups Using AAAA Records
    -
    Address to Name Lookups Using Nibble Format
    +
    Address-to-Name Lookups Using Nibble Format
    5. The BIND 9 Lightweight Resolver
    @@ -213,10 +213,10 @@
    Setting TTLs
    Inverse Mapping in IPv4
    Other Zone File Directives
    -
    BIND Master File Extension: the $GENERATE Directive
    +
    BIND Primary File Extension: the $GENERATE Directive
    Additional File Formats
    -
    BIND9 Statistics
    +
    BIND 9 Statistics
    The Statistics File
    Statistics Counters
    @@ -235,17 +235,18 @@
    8. Troubleshooting
    Common Problems
    -
    It's not working; how can I figure out what's wrong?
    +
    It's Not Working; How Can I Figure Out What's Wrong?
    Incrementing and Changing the Serial Number
    Where Can I Get Help?
    A. Release Notes
    -
    Release Notes for BIND Version 9.11.21
    +
    Release Notes for BIND Version 9.11.22
    Introduction
    Download
    License Change
    +
    Notes for BIND 9.11.22
    Notes for BIND 9.11.21
    Notes for BIND 9.11.20
    Notes for BIND 9.11.19
    @@ -297,19 +298,16 @@
    I. Manual pages
    -dig — DNS lookup utility +arpaname — translate IP addresses to the corresponding ARPA names
    -mdig — DNS pipelined lookup utility -
    -
    -host — DNS lookup utility +ddns-confgen — ddns key generation tool
    delv — DNS lookup and validation utility
    -nslookup — query Internet name servers interactively +dig — DNS lookup utility
    dnssec-checkds — DNSSEC delegation consistency checking tool @@ -345,13 +343,22 @@ dnssec-verify — DNSSEC zone verification tool
    +dnstap-read — print dnstap data in human-readable form +
    +
    +genrandom — generate a file containing random data +
    +
    +host — DNS lookup utility +
    +
    +isc-hmac-fixup — fixes HMAC keys generated by older versions of BIND +
    +
    lwresd — lightweight resolver daemon
    -named — Internet domain name server -
    -
    -named.conf — configuration file for named +mdig — DNS pipelined lookup utility
    named-checkconf — named configuration file syntax checking tool @@ -371,47 +378,41 @@ named-rrchecker — syntax checker for individual DNS resource records
    -nsupdate — Dynamic DNS update utility +named.conf — configuration file for named
    -rndc — name server control utility -
    -
    -rndc.conf — rndc configuration file -
    -
    -rndc-confgen — rndc key generation tool -
    -
    -ddns-confgen — ddns key generation tool -
    -
    -arpaname — translate IP addresses to the corresponding ARPA names -
    -
    -dnstap-read — print dnstap data in human-readable form -
    -
    -genrandom — generate a file containing random data -
    -
    -isc-hmac-fixup — fixes HMAC keys generated by older versions of BIND +named — Internet domain name server
    nsec3hash — generate NSEC3 hash
    -pkcs11-destroy — destroy PKCS#11 objects +nslookup — query Internet name servers interactively
    -pkcs11-list — list PKCS#11 objects +nsupdate — Dynamic DNS update utility +
    +
    +pkcs11-destroy — destroy PKCS#11 objects
    pkcs11-keygen — generate keys on a PKCS#11 device
    +pkcs11-list — list PKCS#11 objects +
    +
    pkcs11-tokens — list PKCS#11 available tokens
    +
    +rndc-confgen — rndc key generation tool +
    +
    +rndc.conf — rndc configuration file +
    +
    +rndc — name server control utility +
    @@ -459,6 +460,6 @@ -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf index 60146454c5..c83621c49d 100644 Binary files a/doc/arm/Bv9ARM.pdf and b/doc/arm/Bv9ARM.pdf differ diff --git a/doc/arm/man.arpaname.html b/doc/arm/man.arpaname.html index 3dac98bcf8..681087937b 100644 --- a/doc/arm/man.arpaname.html +++ b/doc/arm/man.arpaname.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ arpaname -Prev  +Prev  Manual pages - Next + Next @@ -55,7 +55,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    arpaname translates IP addresses (IPv4 and @@ -64,7 +64,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    BIND 9 Administrator Reference Manual. @@ -77,20 +77,19 @@ +Prev  - - + -
    -Prev  Up Next + Next
    -ddns-confgen Manual pages  Home dnstap-read + ddns-confgen

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.ddns-confgen.html b/doc/arm/man.ddns-confgen.html index bd74946a2b..eef3487747 100644 --- a/doc/arm/man.ddns-confgen.html +++ b/doc/arm/man.ddns-confgen.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ ddns-confgen -Prev  +Prev  Manual pages - Next + Next @@ -71,7 +71,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    tsig-keygen and ddns-confgen @@ -112,7 +112,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -201,7 +201,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    nsupdate(1) @@ -222,20 +222,19 @@ +Prev  - +arpaname  - +
    -Prev  Up Next + Next
    -rndc-confgen  Home arpaname - delv

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.delv.html b/doc/arm/man.delv.html index 951df9053c..1afe6ad5d6 100644 --- a/doc/arm/man.delv.html +++ b/doc/arm/man.delv.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ delv -Prev  +Prev  Manual pages - Next + Next @@ -90,7 +90,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    delv is a tool for sending @@ -134,7 +134,7 @@

    -

    SIMPLE USAGE

    +

    SIMPLE USAGE

    @@ -197,7 +197,7 @@

    -

    OPTIONS

    +

    OPTIONS

    -a anchor-file
    @@ -358,7 +358,7 @@
    -

    QUERY OPTIONS

    +

    QUERY OPTIONS

    delv @@ -583,14 +583,14 @@

    -

    FILES

    +

    FILES

    /etc/bind.keys

    /etc/resolv.conf

    -

    SEE ALSO

    +

    SEE ALSO

    dig(1) @@ -612,18 +612,19 @@ +Prev  - - + - +
    -Prev  Up Next + Next
    host  +ddns-confgen  Home nslookup dig

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html index 4501b00c8e..1a87f579b2 100644 --- a/doc/arm/man.dig.html +++ b/doc/arm/man.dig.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ dig -Prev  +Prev  Manual pages - Next + Next @@ -86,7 +86,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and @@ -141,7 +141,7 @@

    -

    SIMPLE USAGE

    +

    SIMPLE USAGE

    @@ -202,7 +202,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -384,7 +384,7 @@
    -

    QUERY OPTIONS

    +

    QUERY OPTIONS

    dig @@ -1022,7 +1022,7 @@

    -

    MULTIPLE QUERIES

    +

    MULTIPLE QUERIES

    @@ -1074,7 +1074,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

    -

    IDN SUPPORT

    +

    IDN SUPPORT

    If dig has been built with IDN (internationalized @@ -1089,7 +1089,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

    -

    FILES

    +

    FILES

    /etc/resolv.conf

    @@ -1098,7 +1098,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
    -

    SEE ALSO

    +

    SEE ALSO

    delv(1) @@ -1117,7 +1117,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

    -

    BUGS

    +

    BUGS

    There are probably too many query options. @@ -1130,19 +1130,19 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr +Prev  - - + -
    -Prev  Up Next + Next
    Manual pages delv  Home mdig + dnssec-checkds

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-checkds.html b/doc/arm/man.dnssec-checkds.html index 6298138ec5..42778cbdb7 100644 --- a/doc/arm/man.dnssec-checkds.html +++ b/doc/arm/man.dnssec-checkds.html @@ -13,7 +13,7 @@ - + @@ -22,7 +22,7 @@ dnssec-checkds -Prev  +Prev  Manual pages  Next @@ -68,7 +68,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-checkds verifies the correctness of Delegation Signer (DS) or DNSSEC @@ -78,7 +78,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -115,7 +115,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-dsfromkey(8) @@ -135,19 +135,19 @@ +Prev  - +
    -Prev  Up  Next
    nslookup dig  Home  dnssec-coverage

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-coverage.html b/doc/arm/man.dnssec-coverage.html index 908b404b91..8a399ea315 100644 --- a/doc/arm/man.dnssec-coverage.html +++ b/doc/arm/man.dnssec-coverage.html @@ -65,7 +65,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-coverage verifies that the DNSSEC keys for a given zone or a set of zones @@ -95,7 +95,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -232,7 +232,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    @@ -270,6 +270,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-dsfromkey.html b/doc/arm/man.dnssec-dsfromkey.html index 23eb71ea88..415eebdf1b 100644 --- a/doc/arm/man.dnssec-dsfromkey.html +++ b/doc/arm/man.dnssec-dsfromkey.html @@ -111,7 +111,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    The dnssec-dsfromkey command outputs DS (Delegation @@ -147,7 +147,7 @@

    -

    OPTIONS

    +

    OPTIONS

    -1
    @@ -273,7 +273,7 @@
    -

    EXAMPLE

    +

    EXAMPLE

    To build the SHA-256 DS RR from the @@ -291,7 +291,7 @@

    -

    FILES

    +

    FILES

    The keyfile can be designated by the key identification @@ -307,7 +307,7 @@

    -

    CAVEAT

    +

    CAVEAT

    A keyfile error can give a "file not found" even if the file exists. @@ -315,7 +315,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-keygen(8) @@ -352,6 +352,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-importkey.html b/doc/arm/man.dnssec-importkey.html index b3680ebaa5..68ed277e69 100644 --- a/doc/arm/man.dnssec-importkey.html +++ b/doc/arm/man.dnssec-importkey.html @@ -79,7 +79,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-importkey reads a public DNSKEY record and generates a pair of @@ -101,7 +101,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -157,7 +157,7 @@
    -

    TIMING OPTIONS

    +

    TIMING OPTIONS

    Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS. @@ -206,7 +206,7 @@

    -

    FILES

    +

    FILES

    A keyfile can be designed by the key identification @@ -217,7 +217,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-keygen(8) @@ -250,6 +250,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-keyfromlabel.html b/doc/arm/man.dnssec-keyfromlabel.html index 89e0f0df8a..1b83dba157 100644 --- a/doc/arm/man.dnssec-keyfromlabel.html +++ b/doc/arm/man.dnssec-keyfromlabel.html @@ -81,7 +81,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-keyfromlabel generates a key pair of files that referencing a key object stored @@ -99,7 +99,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -309,7 +309,7 @@
    -

    TIMING OPTIONS

    +

    TIMING OPTIONS

    @@ -409,7 +409,7 @@

    -

    GENERATED KEY FILES

    +

    GENERATED KEY FILES

    When dnssec-keyfromlabel completes @@ -456,7 +456,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-keygen(8) @@ -490,6 +490,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-keygen.html b/doc/arm/man.dnssec-keygen.html index 1a57d413ea..b19c83ee47 100644 --- a/doc/arm/man.dnssec-keygen.html +++ b/doc/arm/man.dnssec-keygen.html @@ -86,7 +86,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-keygen generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 @@ -102,7 +102,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -365,7 +365,7 @@
    -

    TIMING OPTIONS

    +

    TIMING OPTIONS

    @@ -468,7 +468,7 @@

    -

    GENERATED KEYS

    +

    GENERATED KEYS

    When dnssec-keygen completes @@ -522,7 +522,7 @@

    -

    EXAMPLE

    +

    EXAMPLE

    To generate a 768-bit DSA key for the domain @@ -551,7 +551,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-signzone(8) @@ -583,6 +583,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-keymgr.html b/doc/arm/man.dnssec-keymgr.html index e82e4b7334..725836d83f 100644 --- a/doc/arm/man.dnssec-keymgr.html +++ b/doc/arm/man.dnssec-keymgr.html @@ -66,7 +66,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-keymgr is a high level Python wrapper to facilitate the key rollover process for zones handled by @@ -124,7 +124,7 @@

    -

    OPTIONS

    +

    OPTIONS

    -c file
    @@ -219,7 +219,7 @@
    -

    POLICY CONFIGURATION

    +

    POLICY CONFIGURATION

    The dnssec-policy.conf file can specify three kinds of policies: @@ -357,7 +357,7 @@

    -

    REMAINING WORK

    +

    REMAINING WORK

    • @@ -379,7 +379,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-coverage(8) @@ -416,6 +416,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-revoke.html b/doc/arm/man.dnssec-revoke.html index 358e946476..65d2e74e27 100644 --- a/doc/arm/man.dnssec-revoke.html +++ b/doc/arm/man.dnssec-revoke.html @@ -63,7 +63,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-revoke reads a DNSSEC key file, sets the REVOKED bit on the key as defined @@ -73,7 +73,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -141,7 +141,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-keygen(8) @@ -171,6 +171,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-settime.html b/doc/arm/man.dnssec-settime.html index 213c6a3537..4aa521de51 100644 --- a/doc/arm/man.dnssec-settime.html +++ b/doc/arm/man.dnssec-settime.html @@ -72,7 +72,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-settime reads a DNSSEC private key file and sets the key timing metadata @@ -100,7 +100,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -172,7 +172,7 @@
    -

    TIMING OPTIONS

    +

    TIMING OPTIONS

    Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS. @@ -280,7 +280,7 @@

    -

    PRINTING OPTIONS

    +

    PRINTING OPTIONS

    dnssec-settime can also be used to print the @@ -316,7 +316,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-keygen(8) @@ -349,6 +349,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-signzone.html b/doc/arm/man.dnssec-signzone.html index 786ce7a646..13054e10b2 100644 --- a/doc/arm/man.dnssec-signzone.html +++ b/doc/arm/man.dnssec-signzone.html @@ -95,7 +95,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-signzone signs a zone. It generates @@ -108,7 +108,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -646,7 +646,7 @@
    -

    EXAMPLE

    +

    EXAMPLE

    The following command signs the example.com @@ -678,7 +678,7 @@ db.example.com.signed

    -

    SEE ALSO

    +

    SEE ALSO

    dnssec-keygen(8) @@ -708,6 +708,6 @@ db.example.com.signed

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnssec-verify.html b/doc/arm/man.dnssec-verify.html index a11e787607..611e8e5a10 100644 --- a/doc/arm/man.dnssec-verify.html +++ b/doc/arm/man.dnssec-verify.html @@ -14,7 +14,7 @@ - +
    @@ -24,7 +24,7 @@ Prev  Manual pages - Next + Next @@ -64,7 +64,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnssec-verify verifies that a zone is fully signed for each algorithm found @@ -74,7 +74,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -171,7 +171,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    @@ -190,18 +190,18 @@ Prev  Up - Next + Next dnssec-signzone  Home - lwresd + dnstap-read

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.dnstap-read.html b/doc/arm/man.dnstap-read.html index 8f1da1b442..a045864c3d 100644 --- a/doc/arm/man.dnstap-read.html +++ b/doc/arm/man.dnstap-read.html @@ -13,7 +13,7 @@ - + @@ -22,7 +22,7 @@ dnstap-read -Prev  +Prev  Manual pages  Next @@ -59,7 +59,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    dnstap-read @@ -72,7 +72,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -101,7 +101,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    @@ -120,20 +120,20 @@ +Prev  +dnssec-verify 
    -Prev  Up  Next
    -arpaname  Home  genrandom

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.genrandom.html b/doc/arm/man.genrandom.html index bb571d5fb2..34b786a160 100644 --- a/doc/arm/man.genrandom.html +++ b/doc/arm/man.genrandom.html @@ -14,7 +14,7 @@ - +
    @@ -24,7 +24,7 @@ Prev  Manual pages - Next + Next @@ -58,7 +58,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    genrandom @@ -69,7 +69,7 @@

    -

    ARGUMENTS

    +

    ARGUMENTS

    -n number
    @@ -95,7 +95,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    @@ -115,18 +115,17 @@ Prev  Up - Next + Next dnstap-read  Home - isc-hmac-fixup - + host

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.host.html b/doc/arm/man.host.html index 22324e26a6..0ef22e0281 100644 --- a/doc/arm/man.host.html +++ b/doc/arm/man.host.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ host -Prev  +Prev  Manual pages - Next + Next @@ -71,7 +71,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    host @@ -98,7 +98,7 @@

    -

    OPTIONS

    +

    OPTIONS

    -4
    @@ -320,7 +320,7 @@
    -

    IDN SUPPORT

    +

    IDN SUPPORT

    If host has been built with IDN (internationalized @@ -336,14 +336,14 @@

    -

    FILES

    +

    FILES

    /etc/resolv.conf

    -

    SEE ALSO

    +

    SEE ALSO

    dig(1) @@ -360,19 +360,20 @@ +Prev  - +genrandom  - +
    -Prev  Up Next + Next
    -mdig  Home delv isc-hmac-fixup +

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.isc-hmac-fixup.html b/doc/arm/man.isc-hmac-fixup.html index 11bfa47175..32f8f2490b 100644 --- a/doc/arm/man.isc-hmac-fixup.html +++ b/doc/arm/man.isc-hmac-fixup.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ isc-hmac-fixup -Prev  +Prev  Manual pages - Next + Next @@ -57,7 +57,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    Versions of BIND 9 up to and including BIND 9.6 had a bug causing @@ -85,7 +85,7 @@

    -

    SECURITY CONSIDERATIONS

    +

    SECURITY CONSIDERATIONS

    Secrets that have been converted by isc-hmac-fixup @@ -98,7 +98,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    BIND 9 Administrator Reference Manual, @@ -112,20 +112,19 @@ +Prev  - - + -
    -Prev  Up Next + Next
    -genrandom host  Home nsec3hash + lwresd

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.lwresd.html b/doc/arm/man.lwresd.html index 8671663cc7..13c4642997 100644 --- a/doc/arm/man.lwresd.html +++ b/doc/arm/man.lwresd.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ lwresd -Prev  +Prev  Manual pages - Next + Next @@ -73,7 +73,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    lwresd @@ -112,7 +112,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -274,7 +274,7 @@
    -

    FILES

    +

    FILES

    @@ -295,7 +295,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    named(8) @@ -315,20 +315,20 @@ +Prev  - +isc-hmac-fixup  -
    -Prev  Up Next + Next
    -dnssec-verify  Home named + mdig

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.mdig.html b/doc/arm/man.mdig.html index a80cdf39fa..537b22fc3a 100644 --- a/doc/arm/man.mdig.html +++ b/doc/arm/man.mdig.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ mdig -Prev  +Prev  Manual pages - Next + Next @@ -84,7 +84,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    mdig is a multiple/pipelined query version of dig: @@ -134,7 +134,7 @@

    -

    ANYWHERE OPTIONS

    +

    ANYWHERE OPTIONS

    @@ -158,7 +158,7 @@

    -

    GLOBAL OPTIONS

    +

    GLOBAL OPTIONS

    @@ -358,7 +358,7 @@

    -

    LOCAL OPTIONS

    +

    LOCAL OPTIONS

    @@ -583,7 +583,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    dig(1) @@ -597,18 +597,20 @@ +Prev  - - + - +
    -Prev  Up Next + Next
    dig  +lwresd  Home host named-checkconf +

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.named-checkconf.html b/doc/arm/man.named-checkconf.html index 7606af85ee..8e49b64078 100644 --- a/doc/arm/man.named-checkconf.html +++ b/doc/arm/man.named-checkconf.html @@ -13,7 +13,7 @@ - + @@ -22,7 +22,7 @@ named-checkconf -Prev  +Prev  Manual pages  Next @@ -61,7 +61,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    named-checkconf checks the syntax, but not the semantics, of a @@ -83,7 +83,7 @@

    -

    OPTIONS

    +

    OPTIONS

    -h
    @@ -152,7 +152,7 @@
    -

    RETURN VALUES

    +

    RETURN VALUES

    named-checkconf returns an exit status of 1 if @@ -161,7 +161,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    named(8) @@ -178,20 +178,20 @@ +Prev  +mdig 
    -Prev  Up  Next
    -named.conf  Home  named-checkzone

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.named-checkzone.html b/doc/arm/man.named-checkzone.html index bbf8bdbb6a..bea2f75948 100644 --- a/doc/arm/man.named-checkzone.html +++ b/doc/arm/man.named-checkzone.html @@ -111,7 +111,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    named-checkzone checks the syntax and integrity of a zone file. It performs the @@ -133,7 +133,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -421,7 +421,7 @@
    -

    RETURN VALUES

    +

    RETURN VALUES

    named-checkzone returns an exit status of 1 if @@ -430,7 +430,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    named(8) @@ -463,6 +463,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.named-journalprint.html b/doc/arm/man.named-journalprint.html index 04aa6329a2..07ac9b8e32 100644 --- a/doc/arm/man.named-journalprint.html +++ b/doc/arm/man.named-journalprint.html @@ -56,7 +56,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    named-journalprint @@ -84,7 +84,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    @@ -117,6 +117,6 @@

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.named-nzd2nzf.html b/doc/arm/man.named-nzd2nzf.html index ad2a8a875a..3a7af1bbe2 100644 --- a/doc/arm/man.named-nzd2nzf.html +++ b/doc/arm/man.named-nzd2nzf.html @@ -57,7 +57,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    named-nzd2nzf converts an NZD database to NZF @@ -71,7 +71,7 @@

    -

    ARGUMENTS

    +

    ARGUMENTS

    filename
    @@ -85,7 +85,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    BIND 9 Administrator Reference Manual @@ -93,7 +93,7 @@

    -

    AUTHOR

    +

    AUTHOR

    Internet Systems Consortium

    @@ -119,6 +119,6 @@
    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.named-rrchecker.html b/doc/arm/man.named-rrchecker.html index 23328d0e83..7918743b1c 100644 --- a/doc/arm/man.named-rrchecker.html +++ b/doc/arm/man.named-rrchecker.html @@ -14,7 +14,7 @@ - +
    @@ -24,7 +24,7 @@ Prev  Manual pages - Next + Next @@ -60,7 +60,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    named-rrchecker read a individual DNS resource record from standard input and checks if it @@ -90,7 +90,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    RFC 1034, @@ -109,18 +109,18 @@ Prev  Up - Next + Next named-nzd2nzf  Home - nsupdate + named.conf

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.named.conf.html b/doc/arm/man.named.conf.html index 714b405721..47a4d42892 100644 --- a/doc/arm/man.named.conf.html +++ b/doc/arm/man.named.conf.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ named.conf -Prev  +Prev  Manual pages - Next + Next @@ -55,7 +55,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    named.conf is the configuration file for @@ -76,7 +76,7 @@

    -

    ACL

    +

    ACL


    acl string { address_match_element; ... };
    @@ -84,7 +84,7 @@ acl

    -

    CONTROLS

    +

    CONTROLS


    controls {
    @@ -102,7 +102,7 @@ controls

    -

    DLZ

    +

    DLZ


    dlz string {
    @@ -113,7 +113,7 @@ dlz

    -

    DYNDB

    +

    DYNDB


    dyndb string quoted_string {
    @@ -122,7 +122,7 @@ dyndb

    -

    KEY

    +

    KEY


    key string {
    @@ -133,7 +133,7 @@ key

    -

    LOGGING

    +

    LOGGING


    logging {
    @@ -155,7 +155,7 @@ logging

    -

    LWRES

    +

    LWRES


    lwres {
    @@ -171,7 +171,7 @@ lwres

    -

    MANAGED-KEYS

    +

    MANAGED-KEYS


    managed-keys { string string integer
    @@ -180,7 +180,7 @@ managed-keys

    -

    MASTERS

    +

    MASTERS


    masters string [ port integer ] [ dscp
    @@ -191,7 +191,7 @@ masters

    -

    OPTIONS

    +

    OPTIONS


    options {
    @@ -472,7 +472,7 @@ options

    -

    SERVER

    +

    SERVER


    server netprefix {
    @@ -509,7 +509,7 @@ server

    -

    STATISTICS-CHANNELS

    +

    STATISTICS-CHANNELS


    statistics-channels {
    @@ -522,7 +522,7 @@ statistics-channels

    -

    TRUSTED-KEYS

    +

    TRUSTED-KEYS


    trusted-keys { string integer integer
    @@ -531,7 +531,7 @@ trusted-keys

    -

    VIEW

    +

    VIEW


    view string [ class ] {
    @@ -887,7 +887,7 @@ view

    -

    ZONE

    +

    ZONE


    zone string [ class ] {
    @@ -986,14 +986,14 @@ zone

    -

    FILES

    +

    FILES

    /etc/named.conf

    -

    SEE ALSO

    +

    SEE ALSO

    ddns-confgen(8) @@ -1020,20 +1020,20 @@ zone +Prev  - +named-rrchecker  -
    -Prev  Up Next + Next
    -named  Home named-checkconf + named

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.named.html b/doc/arm/man.named.html index dcb716e078..870bc1ee6b 100644 --- a/doc/arm/man.named.html +++ b/doc/arm/man.named.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ named -Prev  +Prev  Manual pages - Next + Next @@ -79,7 +79,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    named is a Domain Name System (DNS) server, @@ -96,7 +96,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -369,7 +369,7 @@
    -

    SIGNALS

    +

    SIGNALS

    In routine operation, signals should not be used to control @@ -399,7 +399,7 @@

    -

    CONFIGURATION

    +

    CONFIGURATION

    The named configuration file is too complex @@ -420,7 +420,7 @@

    -

    FILES

    +

    FILES

    @@ -441,7 +441,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    RFC 1033, RFC 1034, @@ -476,20 +476,20 @@ +Prev  - +named.conf  -
    -Prev  Up Next + Next
    -lwresd  Home named.conf + nsec3hash

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.nsec3hash.html b/doc/arm/man.nsec3hash.html index ef2e692366..bfb4958a44 100644 --- a/doc/arm/man.nsec3hash.html +++ b/doc/arm/man.nsec3hash.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ nsec3hash -Prev  +Prev  Manual pages - Next + Next @@ -59,7 +59,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    nsec3hash generates an NSEC3 hash based on @@ -69,7 +69,7 @@

    -

    ARGUMENTS

    +

    ARGUMENTS

    salt
    @@ -103,7 +103,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    BIND 9 Administrator Reference Manual, @@ -117,20 +117,19 @@ +Prev  - +named  - +
    -Prev  Up Next + Next
    -isc-hmac-fixup  Home pkcs11-destroy - nslookup

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.nslookup.html b/doc/arm/man.nslookup.html index b9053be033..25fad0f496 100644 --- a/doc/arm/man.nslookup.html +++ b/doc/arm/man.nslookup.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ nslookup -Prev  +Prev  Manual pages - Next + Next @@ -58,7 +58,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    Nslookup is a program to query Internet domain name servers. Nslookup @@ -72,7 +72,7 @@

    -

    ARGUMENTS

    +

    ARGUMENTS

    Interactive mode is entered in the following cases: @@ -121,7 +121,7 @@ nslookup -query=hinfo -timeout=10

    -

    INTERACTIVE COMMANDS

    +

    INTERACTIVE COMMANDS

    host [server]
    @@ -378,7 +378,7 @@ nslookup -query=hinfo -timeout=10
    -

    RETURN VALUES

    +

    RETURN VALUES

    nslookup returns with an exit status of 1 if any query failed, and 0 otherwise. @@ -386,7 +386,7 @@ nslookup -query=hinfo -timeout=10

    -

    IDN SUPPORT

    +

    IDN SUPPORT

    If nslookup has been built with IDN (internationalized @@ -403,14 +403,14 @@ nslookup -query=hinfo -timeout=10

    -

    FILES

    +

    FILES

    /etc/resolv.conf

    -

    SEE ALSO

    +

    SEE ALSO

    dig(1) @@ -429,19 +429,20 @@ nslookup -query=hinfo -timeout=10 +Prev  - - + -
    -Prev  Up Next + Next
    delv  +nsec3hash  Home dnssec-checkds + nsupdate

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.nsupdate.html b/doc/arm/man.nsupdate.html index 722fa0d781..dafb1ed89c 100644 --- a/doc/arm/man.nsupdate.html +++ b/doc/arm/man.nsupdate.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ nsupdate -Prev  +Prev  Manual pages - Next + Next @@ -74,7 +74,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    nsupdate is used to submit Dynamic DNS Update requests as defined in RFC 2136 @@ -134,7 +134,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -306,7 +306,7 @@
    -

    INPUT FORMAT

    +

    INPUT FORMAT

    nsupdate reads input from @@ -670,7 +670,7 @@

    -

    EXAMPLES

    +

    EXAMPLES

    The examples below show how @@ -726,7 +726,7 @@

    -

    FILES

    +

    FILES

    @@ -764,7 +764,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    RFC 2136, @@ -787,7 +787,7 @@

    -

    BUGS

    +

    BUGS

    The TSIG key is redundantly stored in two separate files. @@ -803,20 +803,19 @@ +Prev  - - + -
    -Prev  Up Next + Next
    -named-rrchecker nslookup  Home rndc + pkcs11-destroy

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.pkcs11-destroy.html b/doc/arm/man.pkcs11-destroy.html index 9fbf283477..18af232384 100644 --- a/doc/arm/man.pkcs11-destroy.html +++ b/doc/arm/man.pkcs11-destroy.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ pkcs11-destroy -Prev  +Prev  Manual pages - Next + Next @@ -63,7 +63,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    pkcs11-destroy destroys keys stored in a @@ -78,7 +78,7 @@

    -

    ARGUMENTS

    +

    ARGUMENTS

    -m module
    @@ -127,7 +127,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    @@ -148,20 +148,20 @@ +Prev  - +nsupdate  -
    -Prev  Up Next + Next
    -nsec3hash  Home pkcs11-list + pkcs11-keygen

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.pkcs11-keygen.html b/doc/arm/man.pkcs11-keygen.html index 00c5a085d9..a3e850f066 100644 --- a/doc/arm/man.pkcs11-keygen.html +++ b/doc/arm/man.pkcs11-keygen.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ pkcs11-keygen -Prev  +Prev  Manual pages - Next + Next @@ -66,7 +66,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    pkcs11-keygen causes a PKCS#11 device to generate @@ -76,7 +76,7 @@

    -

    ARGUMENTS

    +

    ARGUMENTS

    -a algorithm
    @@ -162,7 +162,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    @@ -186,20 +186,20 @@ +Prev  - +pkcs11-destroy  -
    -Prev  Up Next + Next
    -pkcs11-list  Home pkcs11-tokens + pkcs11-list

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.pkcs11-list.html b/doc/arm/man.pkcs11-list.html index 2843c8cea6..0c650ea99a 100644 --- a/doc/arm/man.pkcs11-list.html +++ b/doc/arm/man.pkcs11-list.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ pkcs11-list -Prev  +Prev  Manual pages - Next + Next @@ -61,7 +61,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    pkcs11-list @@ -75,7 +75,7 @@

    -

    ARGUMENTS

    +

    ARGUMENTS

    -P
    @@ -123,7 +123,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    @@ -144,20 +144,20 @@ +Prev  - +pkcs11-keygen  -
    -Prev  Up Next + Next
    -pkcs11-destroy  Home pkcs11-keygen + pkcs11-tokens

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.pkcs11-tokens.html b/doc/arm/man.pkcs11-tokens.html index e725642500..6158a0dd9e 100644 --- a/doc/arm/man.pkcs11-tokens.html +++ b/doc/arm/man.pkcs11-tokens.html @@ -13,7 +13,8 @@ - + +
    @@ -21,9 +22,10 @@ pkcs11-tokens -Prev  +Prev  Manual pages -  + Next +
    @@ -55,7 +57,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    pkcs11-tokens @@ -65,7 +67,7 @@

    -

    ARGUMENTS

    +

    ARGUMENTS

    -m module
    @@ -86,7 +88,7 @@
    -

    SEE ALSO

    +

    SEE ALSO

    @@ -107,18 +109,20 @@ +Prev  - + +pkcs11-list  - +
    -Prev  Up  Next +
    -pkcs11-keygen  Home  rndc-confgen +

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.rndc-confgen.html b/doc/arm/man.rndc-confgen.html index 0216ac67c2..a127c5e139 100644 --- a/doc/arm/man.rndc-confgen.html +++ b/doc/arm/man.rndc-confgen.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ rndc-confgen -Prev  +Prev  Manual pages - Next + Next @@ -66,7 +66,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    rndc-confgen generates configuration files @@ -85,7 +85,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -223,7 +223,7 @@
    -

    EXAMPLES

    +

    EXAMPLES

    To allow rndc to be used with @@ -242,7 +242,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    rndc(8) @@ -263,20 +263,20 @@ +Prev  - +pkcs11-tokens  -
    -Prev  Up Next + Next
    -rndc.conf  Home ddns-confgen + rndc.conf

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.rndc.conf.html b/doc/arm/man.rndc.conf.html index 84022ea3e9..d07dc21e71 100644 --- a/doc/arm/man.rndc.conf.html +++ b/doc/arm/man.rndc.conf.html @@ -13,8 +13,8 @@ - - + +
    @@ -22,9 +22,9 @@ rndc.conf -Prev  +Prev  Manual pages - Next + Next @@ -55,7 +55,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    rndc.conf is the configuration file for rndc, the BIND 9 name server control @@ -143,7 +143,7 @@

    -

    EXAMPLE

    +

    EXAMPLE

    @@ -221,7 +221,7 @@
    -

    NAME SERVER CONFIGURATION

    +

    NAME SERVER CONFIGURATION

    The name server must be configured to accept rndc connections and @@ -233,7 +233,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    rndc(8) @@ -254,20 +254,20 @@ +Prev  - +rndc-confgen  -
    -Prev  Up Next + Next
    -rndc  Home rndc-confgen + rndc

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/man.rndc.html b/doc/arm/man.rndc.html index 4ef8259361..693aa5006a 100644 --- a/doc/arm/man.rndc.html +++ b/doc/arm/man.rndc.html @@ -13,8 +13,7 @@ - - +
    @@ -22,10 +21,9 @@ rndc -Prev  +Prev  Manual pages - Next - + 
    @@ -65,7 +63,7 @@
    -

    DESCRIPTION

    +

    DESCRIPTION

    rndc controls the operation of a name @@ -98,7 +96,7 @@

    -

    OPTIONS

    +

    OPTIONS

    @@ -196,7 +194,7 @@
    -

    COMMANDS

    +

    COMMANDS

    A list of commands supported by rndc can @@ -841,7 +839,7 @@

    -

    LIMITATIONS

    +

    LIMITATIONS

    There is currently no way to provide the shared secret for a @@ -853,7 +851,7 @@

    -

    SEE ALSO

    +

    SEE ALSO

    rndc.conf(5) @@ -880,20 +878,18 @@ +Prev  - + +rndc.conf  - +
    -Prev  Up Next - 
    -nsupdate  Home rndc.conf - 

    -

    BIND 9.11.21 (Extended Support Version)

    +

    BIND 9.11.22 (Extended Support Version)

    diff --git a/doc/arm/notes-9.11.22.xml b/doc/arm/notes-9.11.22.xml index b867722d06..62fe1d8ea5 100644 --- a/doc/arm/notes-9.11.22.xml +++ b/doc/arm/notes-9.11.22.xml @@ -15,38 +15,59 @@ - None. + It was possible to trigger an assertion failure when verifying the + response to a TSIG-signed request. This was disclosed in + CVE-2020-8622. + + + ISC would like to thank Dave Feldman, Jeff Warren, and Joel Cunningham + of Oracle for bringing this vulnerability to our attention. [GL #2028] - - - -
    Known Issues - - None. + When BIND 9 was compiled with native PKCS#11 support, it was possible + to trigger an assertion failure in code determining the number of bits + in the PKCS#11 RSA public key with a specially crafted packet. This + was disclosed in CVE-2020-8623. + + + ISC would like to thank Lyu Chiy for bringing this vulnerability to + our attention. [GL #2037] - -
    - -
    Feature Changes - - None. + update-policy rules of type + subdomain were incorrectly treated as + zonesub rules, which allowed keys used in + subdomain rules to update names outside of the + specified subdomains. The problem was fixed by making sure + subdomain rules are again processed as described in + the ARM. This was disclosed in CVE-2020-8624. + + + ISC would like to thank Joop Boonen of credativ GmbH for bringing this + vulnerability to our attention. [GL #2055]
    -
    Bug Fixes - None. + Wildcard RPZ passthru rules could incorrectly be overridden by other + rules that were loaded from RPZ zones which appeared later in the + response-policy statement. This has been fixed. + [GL #1619] + + + + + LMDB locking code was revised to make rndc reconfig + work properly on FreeBSD and with LMDB >= 0.9.26. [GL #1976] diff --git a/doc/arm/notes.html b/doc/arm/notes.html index 1fc1c94cd3..7740762e46 100644 --- a/doc/arm/notes.html +++ b/doc/arm/notes.html @@ -15,7 +15,7 @@

    -Release Notes for BIND Version 9.11.21

    +Release Notes for BIND Version 9.11.22

    @@ -73,6 +73,77 @@

    +Notes for BIND 9.11.22

    + +
    +

    +Security Fixes

    +
      +
    • +

      + It was possible to trigger an assertion failure when verifying the + response to a TSIG-signed request. This was disclosed in + CVE-2020-8622. +

      +

      + ISC would like to thank Dave Feldman, Jeff Warren, and Joel Cunningham + of Oracle for bringing this vulnerability to our attention. [GL #2028] +

      +
      • +
    • +

      + When BIND 9 was compiled with native PKCS#11 support, it was possible + to trigger an assertion failure in code determining the number of bits + in the PKCS#11 RSA public key with a specially crafted packet. This + was disclosed in CVE-2020-8623. +

      +

      + ISC would like to thank Lyu Chiy for bringing this vulnerability to + our attention. [GL #2037] +

      +
      • +
    • +

      + update-policy rules of type + subdomain were incorrectly treated as + zonesub rules, which allowed keys used in + subdomain rules to update names outside of the + specified subdomains. The problem was fixed by making sure + subdomain rules are again processed as described in + the ARM. This was disclosed in CVE-2020-8624. +

      +

      + ISC would like to thank Joop Boonen of credativ GmbH for bringing this + vulnerability to our attention. [GL #2055] +

      +
      • +
    +
    + +
    +

    +Bug Fixes

    +
      +
    • +

      + Wildcard RPZ passthru rules could incorrectly be overridden by other + rules that were loaded from RPZ zones which appeared later in the + response-policy statement. This has been fixed. + [GL #1619] +

      +
      • +
    • +

      + LMDB locking code was revised to make rndc reconfig + work properly on FreeBSD and with LMDB >= 0.9.26. [GL #1976] +

      +
      • +
    +
    + +
    +
    +

    Notes for BIND 9.11.21

    diff --git a/doc/arm/notes.pdf b/doc/arm/notes.pdf index ad780aa86c..fc9e790fd7 100644 Binary files a/doc/arm/notes.pdf and b/doc/arm/notes.pdf differ diff --git a/doc/arm/notes.txt b/doc/arm/notes.txt index 5e3e39e041..13faa57f87 100644 --- a/doc/arm/notes.txt +++ b/doc/arm/notes.txt @@ -1,4 +1,4 @@ -Release Notes for BIND Version 9.11.21 +Release Notes for BIND Version 9.11.22 Introduction @@ -36,6 +36,43 @@ Those unsure whether or not the license change affects their use of BIND, or who wish to discuss how to comply with the license may contact ISC at https://www.isc.org/mission/contact/. +Notes for BIND 9.11.22 + +Security Fixes + + • It was possible to trigger an assertion failure when verifying the + response to a TSIG-signed request. This was disclosed in + CVE-2020-8622. + + ISC would like to thank Dave Feldman, Jeff Warren, and Joel Cunningham + of Oracle for bringing this vulnerability to our attention. [GL #2028] + + • When BIND 9 was compiled with native PKCS#11 support, it was possible + to trigger an assertion failure in code determining the number of bits + in the PKCS#11 RSA public key with a specially crafted packet. This + was disclosed in CVE-2020-8623. + + ISC would like to thank Lyu Chiy for bringing this vulnerability to + our attention. [GL #2037] + + • update-policy rules of type subdomain were incorrectly treated as + zonesub rules, which allowed keys used in subdomain rules to update + names outside of the specified subdomains. The problem was fixed by + making sure subdomain rules are again processed as described in the + ARM. This was disclosed in CVE-2020-8624. + + ISC would like to thank Joop Boonen of credativ GmbH for bringing this + vulnerability to our attention. [GL #2055] + +Bug Fixes + + • Wildcard RPZ passthru rules could incorrectly be overridden by other + rules that were loaded from RPZ zones which appeared later in the + response-policy statement. This has been fixed. [GL #1619] + + • LMDB locking code was revised to make rndc reconfig work properly on + FreeBSD and with LMDB >= 0.9.26. [GL #1976] + Notes for BIND 9.11.21 Bug Fixes diff --git a/lib/dns/api b/lib/dns/api index 51834587be..6412460d83 100644 --- a/lib/dns/api +++ b/lib/dns/api @@ -9,5 +9,5 @@ # 9.11: 160-169,1100-1199 # 9.12: 1200-1299 LIBINTERFACE = 1110 -LIBREVISION = 4 +LIBREVISION = 5 LIBAGE = 0 diff --git a/lib/dns/message.c b/lib/dns/message.c index d9e341a09e..7c813a5cf6 100644 --- a/lib/dns/message.c +++ b/lib/dns/message.c @@ -1712,6 +1712,19 @@ dns_message_parse(dns_message_t *msg, isc_buffer_t *source, msg->header_ok = 0; msg->question_ok = 0; + if ((options & DNS_MESSAGEPARSE_CLONEBUFFER) == 0) { + isc_buffer_usedregion(&origsource, &msg->saved); + } else { + msg->saved.length = isc_buffer_usedlength(&origsource); + msg->saved.base = isc_mem_get(msg->mctx, msg->saved.length); + if (msg->saved.base == NULL) { + return (ISC_R_NOMEMORY); + } + memmove(msg->saved.base, isc_buffer_base(&origsource), + msg->saved.length); + msg->free_saved = 1; + } + isc_buffer_remainingregion(source, &r); if (r.length < DNS_MESSAGE_HEADERLEN) return (ISC_R_UNEXPECTEDEND); @@ -1787,17 +1800,6 @@ dns_message_parse(dns_message_t *msg, isc_buffer_t *source, } truncated: - if ((options & DNS_MESSAGEPARSE_CLONEBUFFER) == 0) - isc_buffer_usedregion(&origsource, &msg->saved); - else { - msg->saved.length = isc_buffer_usedlength(&origsource); - msg->saved.base = isc_mem_get(msg->mctx, msg->saved.length); - if (msg->saved.base == NULL) - return (ISC_R_NOMEMORY); - memmove(msg->saved.base, isc_buffer_base(&origsource), - msg->saved.length); - msg->free_saved = 1; - } if (ret == ISC_R_UNEXPECTEDEND && ignore_tc) return (DNS_R_RECOVERABLE); diff --git a/lib/dns/pkcs11dh_link.c b/lib/dns/pkcs11dh_link.c index e2b60ea7c5..4cd8e32d60 100644 --- a/lib/dns/pkcs11dh_link.c +++ b/lib/dns/pkcs11dh_link.c @@ -748,6 +748,7 @@ pkcs11dh_fromdns(dst_key_t *key, isc_buffer_t *data) { CK_BYTE *prime = NULL, *base = NULL, *pub = NULL; CK_ATTRIBUTE *attr; int special = 0; + unsigned int bits; isc_result_t result; isc_buffer_remainingregion(data, &r); @@ -852,7 +853,11 @@ pkcs11dh_fromdns(dst_key_t *key, isc_buffer_t *data) { pub = r.base; isc_region_consume(&r, publen); - key->key_size = pk11_numbits(prime, plen_); + result = pk11_numbits(prime, plen_, &bits); + if (result != ISC_R_SUCCESS) { + goto cleanup; + } + key->key_size = bits; dh->repr = (CK_ATTRIBUTE *) isc_mem_get(key->mctx, sizeof(*attr) * 3); if (dh->repr == NULL) @@ -1012,6 +1017,7 @@ pkcs11dh_parse(dst_key_t *key, isc_lex_t *lexer, dst_key_t *pub) { dst_private_t priv; isc_result_t ret; int i; + unsigned int bits; pk11_object_t *dh = NULL; CK_ATTRIBUTE *attr; isc_mem_t *mctx; @@ -1082,7 +1088,12 @@ pkcs11dh_parse(dst_key_t *key, isc_lex_t *lexer, dst_key_t *pub) { attr = pk11_attribute_bytype(dh, CKA_PRIME); INSIST(attr != NULL); - key->key_size = pk11_numbits(attr->pValue, attr->ulValueLen); + + ret = pk11_numbits(attr->pValue, attr->ulValueLen, &bits); + if (ret != ISC_R_SUCCESS) { + goto err; + } + key->key_size = bits; return (ISC_R_SUCCESS); diff --git a/lib/dns/pkcs11dsa_link.c b/lib/dns/pkcs11dsa_link.c index 12d707a112..24d4c149ff 100644 --- a/lib/dns/pkcs11dsa_link.c +++ b/lib/dns/pkcs11dsa_link.c @@ -983,6 +983,7 @@ pkcs11dsa_parse(dst_key_t *key, isc_lex_t *lexer, dst_key_t *pub) { dst_private_t priv; isc_result_t ret; int i; + unsigned int bits; pk11_object_t *dsa = NULL; CK_ATTRIBUTE *attr; isc_mem_t *mctx = key->mctx; @@ -1072,7 +1073,12 @@ pkcs11dsa_parse(dst_key_t *key, isc_lex_t *lexer, dst_key_t *pub) { attr = pk11_attribute_bytype(dsa, CKA_PRIME); INSIST(attr != NULL); - key->key_size = pk11_numbits(attr->pValue, attr->ulValueLen); + + ret = pk11_numbits(attr->pValue, attr->ulValueLen, &bits); + if (ret != ISC_R_SUCCESS) { + goto err; + } + key->key_size = bits; return (ISC_R_SUCCESS); diff --git a/lib/dns/pkcs11rsa_link.c b/lib/dns/pkcs11rsa_link.c index 096c1a8e91..1d10d26564 100644 --- a/lib/dns/pkcs11rsa_link.c +++ b/lib/dns/pkcs11rsa_link.c @@ -332,6 +332,7 @@ pkcs11rsa_createctx_verify(dst_key_t *key, unsigned int maxbits, key->key_alg == DST_ALG_RSASHA256 || key->key_alg == DST_ALG_RSASHA512); #endif + REQUIRE(maxbits <= RSA_MAX_PUBEXP_BITS); /* * Reject incorrect RSA key lengths. @@ -376,6 +377,7 @@ pkcs11rsa_createctx_verify(dst_key_t *key, unsigned int maxbits, for (attr = pk11_attribute_first(rsa); attr != NULL; attr = pk11_attribute_next(rsa, attr)) + { switch (attr->type) { case CKA_MODULUS: INSIST(keyTemplate[5].type == attr->type); @@ -396,12 +398,16 @@ pkcs11rsa_createctx_verify(dst_key_t *key, unsigned int maxbits, memmove(keyTemplate[6].pValue, attr->pValue, attr->ulValueLen); keyTemplate[6].ulValueLen = attr->ulValueLen; - if (pk11_numbits(attr->pValue, - attr->ulValueLen) > maxbits && - maxbits != 0) + unsigned int bits; + ret = pk11_numbits(attr->pValue, attr->ulValueLen, + &bits); + if (ret != ISC_R_SUCCESS || + (bits > maxbits && maxbits != 0)) { DST_RET(DST_R_VERIFYFAILURE); + } break; } + } pk11_ctx->object = CK_INVALID_HANDLE; pk11_ctx->ontoken = false; PK11_RET(pkcs_C_CreateObject, @@ -1072,6 +1078,7 @@ pkcs11rsa_verify(dst_context_t *dctx, const isc_region_t *sig) { keyTemplate[5].ulValueLen = attr->ulValueLen; break; case CKA_PUBLIC_EXPONENT: + unsigned int bits; INSIST(keyTemplate[6].type == attr->type); keyTemplate[6].pValue = isc_mem_get(dctx->mctx, attr->ulValueLen); @@ -1080,10 +1087,12 @@ pkcs11rsa_verify(dst_context_t *dctx, const isc_region_t *sig) { memmove(keyTemplate[6].pValue, attr->pValue, attr->ulValueLen); keyTemplate[6].ulValueLen = attr->ulValueLen; - if (pk11_numbits(attr->pValue, - attr->ulValueLen) - > RSA_MAX_PUBEXP_BITS) + ret = pk11_numbits(attr->pValue, attr->ulValueLen, + &bits); + if (ret != ISC_R_SUCCESS || bits > RSA_MAX_PUBEXP_BITS) + { DST_RET(DST_R_VERIFYFAILURE); + } break; } pk11_ctx->object = CK_INVALID_HANDLE; @@ -1461,6 +1470,8 @@ pkcs11rsa_fromdns(dst_key_t *key, isc_buffer_t *data) { CK_BYTE *exponent = NULL, *modulus = NULL; CK_ATTRIBUTE *attr; unsigned int length; + unsigned int bits; + isc_result_t ret = ISC_R_SUCCESS; isc_buffer_remainingregion(data, &r); if (r.length == 0) @@ -1478,9 +1489,7 @@ pkcs11rsa_fromdns(dst_key_t *key, isc_buffer_t *data) { if (e_bytes == 0) { if (r.length < 2) { - isc_safe_memwipe(rsa, sizeof(*rsa)); - isc_mem_put(key->mctx, rsa, sizeof(*rsa)); - return (DST_R_INVALIDPUBLICKEY); + DST_RET(DST_R_INVALIDPUBLICKEY); } e_bytes = (*r.base) << 8; isc_region_consume(&r, 1); @@ -1489,16 +1498,18 @@ pkcs11rsa_fromdns(dst_key_t *key, isc_buffer_t *data) { } if (r.length < e_bytes) { - isc_safe_memwipe(rsa, sizeof(*rsa)); - isc_mem_put(key->mctx, rsa, sizeof(*rsa)); - return (DST_R_INVALIDPUBLICKEY); + DST_RET(DST_R_INVALIDPUBLICKEY); } exponent = r.base; isc_region_consume(&r, e_bytes); modulus = r.base; mod_bytes = r.length; - key->key_size = pk11_numbits(modulus, mod_bytes); + ret = pk11_numbits(modulus, mod_bytes, &bits); + if (ret != ISC_R_SUCCESS) { + goto err; + } + key->key_size = bits; isc_buffer_forward(data, length); @@ -1548,9 +1559,12 @@ pkcs11rsa_fromdns(dst_key_t *key, isc_buffer_t *data) { rsa->repr, rsa->attrcnt * sizeof(*attr)); } + ret = ISC_R_NOMEMORY; + + err: isc_safe_memwipe(rsa, sizeof(*rsa)); isc_mem_put(key->mctx, rsa, sizeof(*rsa)); - return (ISC_R_NOMEMORY); + return (ret); } static isc_result_t @@ -1729,6 +1743,7 @@ pkcs11rsa_fetch(dst_key_t *key, const char *engine, const char *label, pk11_object_t *pubrsa; pk11_context_t *pk11_ctx = NULL; isc_result_t ret; + unsigned int bits; if (label == NULL) return (DST_R_NOENGINE); @@ -1815,7 +1830,11 @@ pkcs11rsa_fetch(dst_key_t *key, const char *engine, const char *label, attr = pk11_attribute_bytype(rsa, CKA_MODULUS); INSIST(attr != NULL); - key->key_size = pk11_numbits(attr->pValue, attr->ulValueLen); + ret = pk11_numbits(attr->pValue, attr->ulValueLen, &bits); + if (ret != ISC_R_SUCCESS) { + goto err; + } + key->key_size = bits; return (ISC_R_SUCCESS); @@ -1901,6 +1920,7 @@ pkcs11rsa_parse(dst_key_t *key, isc_lex_t *lexer, dst_key_t *pub) { CK_ATTRIBUTE *attr; isc_mem_t *mctx = key->mctx; const char *engine = NULL, *label = NULL; + unsigned int bits; /* read private key file */ ret = dst__privstruct_parse(key, DST_ALG_RSA, lexer, mctx, &priv); @@ -2044,12 +2064,22 @@ pkcs11rsa_parse(dst_key_t *key, isc_lex_t *lexer, dst_key_t *pub) { attr = pk11_attribute_bytype(rsa, CKA_MODULUS); INSIST(attr != NULL); - key->key_size = pk11_numbits(attr->pValue, attr->ulValueLen); + ret = pk11_numbits(attr->pValue, attr->ulValueLen, &bits); + if (ret != ISC_R_SUCCESS) { + goto err; + } + key->key_size = bits; attr = pk11_attribute_bytype(rsa, CKA_PUBLIC_EXPONENT); INSIST(attr != NULL); - if (pk11_numbits(attr->pValue, attr->ulValueLen) > RSA_MAX_PUBEXP_BITS) + + ret = pk11_numbits(attr->pValue, attr->ulValueLen, &bits); + if (ret != ISC_R_SUCCESS) { + goto err; + } + if (bits > RSA_MAX_PUBEXP_BITS) { DST_RET(ISC_R_RANGE); + } dst__privstruct_free(&priv, mctx); isc_safe_memwipe(&priv, sizeof(priv)); @@ -2084,6 +2114,7 @@ pkcs11rsa_fromlabel(dst_key_t *key, const char *engine, const char *label, pk11_context_t *pk11_ctx = NULL; isc_result_t ret; unsigned int i; + unsigned int bits; UNUSED(pin); @@ -2178,12 +2209,22 @@ pkcs11rsa_fromlabel(dst_key_t *key, const char *engine, const char *label, attr = pk11_attribute_bytype(rsa, CKA_PUBLIC_EXPONENT); INSIST(attr != NULL); - if (pk11_numbits(attr->pValue, attr->ulValueLen) > RSA_MAX_PUBEXP_BITS) + + ret = pk11_numbits(attr->pValue, attr->ulValueLen, &bits); + if (ret != ISC_R_SUCCESS) { + goto err; + } + if (bits > RSA_MAX_PUBEXP_BITS) { DST_RET(ISC_R_RANGE); + } attr = pk11_attribute_bytype(rsa, CKA_MODULUS); INSIST(attr != NULL); - key->key_size = pk11_numbits(attr->pValue, attr->ulValueLen); + ret = pk11_numbits(attr->pValue, attr->ulValueLen, &bits); + if (ret != ISC_R_SUCCESS) { + goto err; + } + key->key_size = bits; pk11_return_session(pk11_ctx); isc_safe_memwipe(pk11_ctx, sizeof(*pk11_ctx)); diff --git a/lib/isc/api b/lib/isc/api index 7b4fc59ceb..b114ab54a1 100644 --- a/lib/isc/api +++ b/lib/isc/api @@ -8,6 +8,6 @@ # 9.10-sub: 180-189 # 9.11: 160-169,1100-1199 # 9.12: 1200-1299 -LIBINTERFACE = 1106 -LIBREVISION = 1 -LIBAGE = 1 +LIBINTERFACE = 1107 +LIBREVISION = 0 +LIBAGE = 0 diff --git a/lib/isc/include/pk11/internal.h b/lib/isc/include/pk11/internal.h index aa8907ab08..7cc8ec812b 100644 --- a/lib/isc/include/pk11/internal.h +++ b/lib/isc/include/pk11/internal.h @@ -25,7 +25,8 @@ void pk11_mem_put(void *ptr, size_t size); CK_SLOT_ID pk11_get_best_token(pk11_optype_t optype); -unsigned int pk11_numbits(CK_BYTE_PTR data, unsigned int bytecnt); +isc_result_t +pk11_numbits(CK_BYTE_PTR data, unsigned int bytecnt, unsigned int *bits); CK_ATTRIBUTE *pk11_attribute_first(const pk11_object_t *obj); diff --git a/lib/isc/pk11.c b/lib/isc/pk11.c index 012afd968a..4e4052044b 100644 --- a/lib/isc/pk11.c +++ b/lib/isc/pk11.c @@ -962,13 +962,15 @@ pk11_get_best_token(pk11_optype_t optype) { return (token->slotid); } -unsigned int -pk11_numbits(CK_BYTE_PTR data, unsigned int bytecnt) { +isc_result_t +pk11_numbits(CK_BYTE_PTR data, unsigned int bytecnt, unsigned int *bits) { unsigned int bitcnt, i; CK_BYTE top; - if (bytecnt == 0) - return (0); + if (bytecnt == 0) { + *bits = 0; + return (ISC_R_SUCCESS); + } bitcnt = bytecnt * 8; for (i = 0; i < bytecnt; i++) { top = data[i]; @@ -976,26 +978,41 @@ pk11_numbits(CK_BYTE_PTR data, unsigned int bytecnt) { bitcnt -= 8; continue; } - if (top & 0x80) - return (bitcnt); - if (top & 0x40) - return (bitcnt - 1); - if (top & 0x20) - return (bitcnt - 2); - if (top & 0x10) - return (bitcnt - 3); - if (top & 0x08) - return (bitcnt - 4); - if (top & 0x04) - return (bitcnt - 5); - if (top & 0x02) - return (bitcnt - 6); - if (top & 0x01) - return (bitcnt - 7); + if (top & 0x80) { + *bits = bitcnt; + return (ISC_R_SUCCESS); + } + if (top & 0x40) { + *bits = bitcnt - 1; + return (ISC_R_SUCCESS); + } + if (top & 0x20) { + *bits = bitcnt - 2; + return (ISC_R_SUCCESS); + } + if (top & 0x10) { + *bits = bitcnt - 3; + return (ISC_R_SUCCESS); + } + if (top & 0x08) { + *bits = bitcnt - 4; + return (ISC_R_SUCCESS); + } + if (top & 0x04) { + *bits = bitcnt - 5; + return (ISC_R_SUCCESS); + } + if (top & 0x02) { + *bits = bitcnt - 6; + return (ISC_R_SUCCESS); + } + if (top & 0x01) { + *bits = bitcnt - 7; + return (ISC_R_SUCCESS); + } break; } - INSIST(0); - ISC_UNREACHABLE(); + return (ISC_R_RANGE); } CK_ATTRIBUTE * diff --git a/version b/version index 6a49b6ea06..47d4fbfaf2 100644 --- a/version +++ b/version @@ -5,7 +5,7 @@ PRODUCT=BIND DESCRIPTION="(Extended Support Version)" MAJORVER=9 MINORVER=11 -PATCHVER=21 +PATCHVER=22 RELEASETYPE= RELEASEVER= EXTENSIONS=