Adding upstream version 1:9.11.5.P4+dfsg.upstream/1%9.11.5.P4+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 18117 insertions, 0 deletions

diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
new file mode 100644
index 0000000..719b074
--- /dev/null
+++ b/doc/arm/Bv9ARM-book.xml
@@ -0,0 +1,18117 @@
+<!--
+ - Copyright (C) Internet Systems Consortium, Inc. ("ISC")
+ -
+ - This Source Code Form is subject to the terms of the Mozilla Public
+ - License, v. 2.0. If a copy of the MPL was not distributed with this
+ - file, You can obtain one at http://mozilla.org/MPL/2.0/.
+ -
+ - See the COPYRIGHT file distributed with this work for additional
+ - information regarding copyright ownership.
+-->
+
+<!-- Converted by db4-upgrade version 1.0 -->
+<book xmlns:db="http://docbook.org/ns/docbook" version="5.0">
+  <info>
+    <title>BIND 9 Administrator Reference Manual</title>
+    <!-- insert copyright start -->
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <year>2003</year>
+      <year>2004</year>
+      <year>2005</year>
+      <year>2006</year>
+      <year>2007</year>
+      <year>2008</year>
+      <year>2009</year>
+      <year>2010</year>
+      <year>2011</year>
+      <year>2012</year>
+      <year>2013</year>
+      <year>2014</year>
+      <year>2015</year>
+      <year>2016</year>
+      <year>2017</year>
+      <year>2018</year>
+      <year>2019</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <!-- insert copyright end -->
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="releaseinfo.xml"/>
+  </info>
+
+  <chapter xml:id="Bv9ARM.ch01"><info><title>Introduction</title></info>
+
+    <para>
+      The Internet Domain Name System (<acronym>DNS</acronym>)
+      consists of the syntax
+      to specify the names of entities in the Internet in a hierarchical
+      manner, the rules used for delegating authority over names, and the
+      system implementation that actually maps names to Internet
+      addresses.  <acronym>DNS</acronym> data is maintained in a
+      group of distributed
+      hierarchical databases.
+    </para>
+
+    <section xml:id="doc_scope"><info><title>Scope of Document</title></info>
+
+      <para>
+	The Berkeley Internet Name Domain
+	(<acronym>BIND</acronym>) implements a
+	domain name server for a number of operating systems. This
+	document provides basic information about the installation and
+	care of the Internet Systems Consortium (<acronym>ISC</acronym>)
+	<acronym>BIND</acronym> version 9 software package for
+	system administrators.
+      </para>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="pkgversion.xml"/>
+    </section>
+
+    <section xml:id="organization"><info><title>Organization of This Document</title></info>
+
+      <para>
+	In this document, <emphasis>Chapter 1</emphasis> introduces
+	the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Chapter 2</emphasis>
+	describes resource requirements for running <acronym>BIND</acronym> in various
+	environments. Information in <emphasis>Chapter 3</emphasis> is
+	<emphasis>task-oriented</emphasis> in its presentation and is
+	organized functionally, to aid in the process of installing the
+	<acronym>BIND</acronym> 9 software. The task-oriented
+	section is followed by
+	<emphasis>Chapter 4</emphasis>, which contains more advanced
+	concepts that the system administrator may need for implementing
+	certain options. <emphasis>Chapter 5</emphasis>
+	describes the <acronym>BIND</acronym> 9 lightweight
+	resolver.  The contents of <emphasis>Chapter 6</emphasis> are
+	organized as in a reference manual to aid in the ongoing
+	maintenance of the software. <emphasis>Chapter 7</emphasis> addresses
+	security considerations, and
+	<emphasis>Chapter 8</emphasis> contains troubleshooting help. The
+	main body of the document is followed by several
+	<emphasis>appendices</emphasis> which contain useful reference
+	information, such as a <emphasis>bibliography</emphasis> and
+	historic information related to <acronym>BIND</acronym>
+	and the Domain Name
+	System.
+      </para>
+    </section>
+    <section xml:id="conventions"><info><title>Conventions Used in This Document</title></info>
+
+      <para>
+	In this document, we use the following general typographic
+	conventions:
+      </para>
+
+      <informaltable>
+	<tgroup cols="2">
+	  <colspec colname="1" colnum="1" colwidth="3.000in"/>
+	  <colspec colname="2" colnum="2" colwidth="2.625in"/>
+	  <tbody>
+	    <row>
+	      <entry colname="1">
+		<para>
+		  <emphasis>To describe:</emphasis>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  <emphasis>We use the style:</emphasis>
+		</para>
+	      </entry>
+	    </row>
+	    <row>
+	      <entry colname="1">
+		<para>
+		  a pathname, filename, URL, hostname,
+		  mailing list name, or new term or concept
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  <filename>Fixed width</filename>
+		</para>
+	      </entry>
+	    </row>
+	    <row>
+	      <entry colname="1">
+		<para>
+		  literal user
+		  input
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  <userinput>Fixed Width Bold</userinput>
+		</para>
+	      </entry>
+	    </row>
+	    <row>
+	      <entry colname="1">
+		<para>
+		  program output
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  <computeroutput>Fixed Width</computeroutput>
+		</para>
+	      </entry>
+	    </row>
+	  </tbody>
+	</tgroup>
+      </informaltable>
+
+      <para>
+	The following conventions are used in descriptions of the
+	<acronym>BIND</acronym> configuration file:<informaltable colsep="0" frame="all" rowsep="0">
+		  <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
+		      <colspec colname="1" colnum="1" colsep="0" colwidth="3.000in"/>
+	    <colspec colname="2" colnum="2" colsep="0" colwidth="2.625in"/>
+	    <tbody>
+	      <row rowsep="0">
+		<entry colname="1" colsep="1" rowsep="1">
+		  <para>
+		    <emphasis>To describe:</emphasis>
+		  </para>
+		</entry>
+		<entry colname="2" rowsep="1">
+		  <para>
+		    <emphasis>We use the style:</emphasis>
+		  </para>
+		</entry>
+	      </row>
+	      <row rowsep="0">
+		<entry colname="1" colsep="1" rowsep="1">
+		  <para>
+		    keywords
+		  </para>
+		</entry>
+		<entry colname="2" rowsep="1">
+		  <para>
+		    <literal>Fixed Width</literal>
+		  </para>
+		</entry>
+	      </row>
+	      <row rowsep="0">
+		<entry colname="1" colsep="1" rowsep="1">
+		  <para>
+		    variables
+		  </para>
+		</entry>
+		<entry colname="2" rowsep="1">
+		  <para>
+		    <varname>Fixed Width</varname>
+		  </para>
+		</entry>
+	      </row>
+	      <row rowsep="0">
+		<entry colname="1" colsep="1">
+		  <para>
+		    Optional input
+		  </para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    <optional>Text is enclosed in square brackets</optional>
+		  </para>
+		</entry>
+	      </row>
+	    </tbody>
+	  </tgroup>
+	</informaltable>
+      </para>
+    </section>
+    <section xml:id="dns_overview"><info><title>The Domain Name System (<acronym>DNS</acronym>)</title></info>
+
+      <para>
+	The purpose of this document is to explain the installation
+	and upkeep of the <acronym>BIND</acronym> (Berkeley Internet
+	Name Domain) software package, and we
+	begin by reviewing the fundamentals of the Domain Name System
+	(<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>.
+      </para>
+
+      <section xml:id="dns_fundamentals"><info><title>DNS Fundamentals</title></info>
+
+	<para>
+	  The Domain Name System (DNS) is a hierarchical, distributed
+	  database.  It stores information for mapping Internet host names to
+	  IP
+	  addresses and vice versa, mail routing information, and other data
+	  used by Internet applications.
+	</para>
+
+	<para>
+	  Clients look up information in the DNS by calling a
+	  <emphasis>resolver</emphasis> library, which sends queries to one or
+	  more <emphasis>name servers</emphasis> and interprets the responses.
+	  The <acronym>BIND</acronym> 9 software distribution
+	  contains a name server, <command>named</command>, and a
+	  resolver library, <command>liblwres</command>.
+	</para>
+
+	</section>
+	<section xml:id="domain_names"><info><title>Domains and Domain Names</title></info>
+
+	<para>
+	  The data stored in the DNS is identified by <emphasis>domain names</emphasis> that are organized as a tree according to
+	  organizational or administrative boundaries. Each node of the tree,
+	  called a <emphasis>domain</emphasis>, is given a label. The domain
+	  name of the
+	  node is the concatenation of all the labels on the path from the
+	  node to the <emphasis>root</emphasis> node.  This is represented
+	  in written form as a string of labels listed from right to left and
+	  separated by dots. A label need only be unique within its parent
+	  domain.
+	</para>
+
+	<para>
+	  For example, a domain name for a host at the
+	  company <emphasis>Example, Inc.</emphasis> could be
+	  <literal>ourhost.example.com</literal>,
+	  where <literal>com</literal> is the
+	  top level domain to which
+	  <literal>ourhost.example.com</literal> belongs,
+	  <literal>example</literal> is
+	  a subdomain of <literal>com</literal>, and
+	  <literal>ourhost</literal> is the
+	  name of the host.
+	</para>
+
+	<para>
+	  For administrative purposes, the name space is partitioned into
+	  areas called <emphasis>zones</emphasis>, each starting at a node and
+	  extending down to the leaf nodes or to nodes where other zones
+	  start.
+	  The data for each zone is stored in a <emphasis>name server</emphasis>, which answers queries about the zone using the
+	  <emphasis>DNS protocol</emphasis>.
+	</para>
+
+	<para>
+	  The data associated with each domain name is stored in the
+	  form of <emphasis>resource records</emphasis> (<acronym>RR</acronym>s).
+	  Some of the supported resource record types are described in
+	  <xref linkend="types_of_resource_records_and_when_to_use_them"/>.
+	</para>
+
+	<para>
+	  For more detailed information about the design of the DNS and
+	  the DNS protocol, please refer to the standards documents listed in
+	  <xref linkend="rfcs"/>.
+	</para>
+      </section>
+
+      <section xml:id="zones"><info><title>Zones</title></info>
+
+	<para>
+	  To properly operate a name server, it is important to understand
+	  the difference between a <emphasis>zone</emphasis>
+	  and a <emphasis>domain</emphasis>.
+	</para>
+
+	<para>
+	  As stated previously, a zone is a point of delegation in
+	  the <acronym>DNS</acronym> tree. A zone consists of
+	  those contiguous parts of the domain
+	  tree for which a name server has complete information and over which
+	  it has authority. It contains all domain names from a certain point
+	  downward in the domain tree except those which are delegated to
+	  other zones. A delegation point is marked by one or more
+	  <emphasis>NS records</emphasis> in the
+	  parent zone, which should be matched by equivalent NS records at
+	  the root of the delegated zone.
+	</para>
+
+	<para>
+	  For instance, consider the <literal>example.com</literal>
+	  domain which includes names
+	  such as <literal>host.aaa.example.com</literal> and
+	  <literal>host.bbb.example.com</literal> even though
+	  the <literal>example.com</literal> zone includes
+	  only delegations for the <literal>aaa.example.com</literal> and
+	  <literal>bbb.example.com</literal> zones.  A zone can
+	  map
+	  exactly to a single domain, but could also include only part of a
+	  domain, the rest of which could be delegated to other
+	  name servers. Every name in the <acronym>DNS</acronym>
+	  tree is a
+	  <emphasis>domain</emphasis>, even if it is
+	  <emphasis>terminal</emphasis>, that is, has no
+	  <emphasis>subdomains</emphasis>.  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
+	  to
+	  gain a complete understanding of this difficult and subtle
+	  topic.
+	</para>
+
+	<para>
+	  Though <acronym>BIND</acronym> is called a "domain name
+	  server",
+	  it deals primarily in terms of zones. The master and slave
+	  declarations in the <filename>named.conf</filename> file
+	  specify
+	  zones, not domains. When you ask some other site if it is willing to
+	  be a slave server for your <emphasis>domain</emphasis>, you are
+	  actually asking for slave service for some collection of zones.
+	</para>
+      </section>
+
+      <section xml:id="auth_servers"><info><title>Authoritative Name Servers</title></info>
+
+	<para>
+	  Each zone is served by at least
+	  one <emphasis>authoritative name server</emphasis>,
+	  which contains the complete data for the zone.
+	  To make the DNS tolerant of server and network failures,
+	  most zones have two or more authoritative servers, on
+	  different networks.
+	</para>
+
+	<para>
+	  Responses from authoritative servers have the "authoritative
+	  answer" (AA) bit set in the response packets.  This makes them
+	  easy to identify when debugging DNS configurations using tools like
+	  <command>dig</command> (<xref linkend="diagnostic_tools"/>).
+	</para>
+
+	<section xml:id="primary_master"><info><title>The Primary Master</title></info>
+
+	  <para>
+	    The authoritative server where the master copy of the zone
+	    data is maintained is called the
+	    <emphasis>primary master</emphasis> server, or simply the
+	    <emphasis>primary</emphasis>.  Typically it loads the zone
+	    contents from some local file edited by humans or perhaps
+	    generated mechanically from some other local file which is
+	    edited by humans.  This file is called the
+	    <emphasis>zone file</emphasis> or
+	    <emphasis>master file</emphasis>.
+	  </para>
+
+	  <para>
+	    In some cases, however, the master file may not be edited
+	    by humans at all, but may instead be the result of
+	    <emphasis>dynamic update</emphasis> operations.
+	  </para>
+	</section>
+
+	<section xml:id="slave_server"><info><title>Slave Servers</title></info>
+
+	  <para>
+	    The other authoritative servers, the <emphasis>slave</emphasis>
+	    servers (also known as <emphasis>secondary</emphasis> servers)
+	    load the zone contents from another server using a replication
+	    process known as a <emphasis>zone transfer</emphasis>.
+	    Typically the data are 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.
+	  </para>
+	  <para>
+	    Periodically, the slave server must send a refresh query to
+	    determine whether the zone contents have been updated. This
+	    is done by sending a query for the zone's SOA record and
+	    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
+	    fields, but can be overrridden with the
+	    <command>max-refresh-time</command>,
+	    <command>min-refresh-time</command>,
+	    <command>max-retry-time</command>, and
+	    <command>min-retry-time</command> options.
+	  </para>
+	  <para>
+	    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.
+	  </para>
+	</section>
+
+	<section xml:id="stealth_server"><info><title>Stealth Servers</title></info>
+
+	  <para>
+	    Usually all of the zone's authoritative servers are listed in
+	    NS records in the parent zone.  These NS records constitute
+	    a <emphasis>delegation</emphasis> of the zone from the parent.
+	    The authoritative servers are also listed in the zone file itself,
+	    at the <emphasis>top level</emphasis> or <emphasis>apex</emphasis>
+	    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.
+	  </para>
+
+	  <para>
+	    A <emphasis>stealth server</emphasis> is a server that is
+	    authoritative for a zone but is not listed in that zone's NS
+	    records.  Stealth servers can be used for keeping a local copy of
+	    a
+	    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
+	    inaccessible.
+	  </para>
+
+	  <para>
+	    A configuration where the primary master server itself is a
+	    stealth server is often referred to as a "hidden primary"
+	    configuration.  One use for this configuration is when the primary
+	    master
+	    is behind a firewall and therefore unable to communicate directly
+	    with the outside world.
+	  </para>
+
+	</section>
+
+      </section>
+      <section xml:id="cache_servers"><info><title>Caching Name Servers</title></info>
+
+	<!--
+	  - Terminology here is inconsistent.  Probably ought to
+	  - convert to using "recursive name server" everywhere
+	  - with just a note about "caching" terminology.
+	  -->
+
+	<para>
+	  The resolver libraries provided by most operating systems are
+	  <emphasis>stub resolvers</emphasis>, meaning that they are not
+	  capable of
+	  performing the full DNS resolution process by themselves by talking
+	  directly to the authoritative servers.  Instead, they rely on a
+	  local
+	  name server to perform the resolution on their behalf.  Such a
+	  server
+	  is called a <emphasis>recursive</emphasis> name server; it performs
+	  <emphasis>recursive lookups</emphasis> for local clients.
+	</para>
+
+	<para>
+	  To improve performance, recursive servers cache the results of
+	  the lookups they perform.  Since the processes of recursion and
+	  caching are intimately connected, the terms
+	  <emphasis>recursive server</emphasis> and
+	  <emphasis>caching server</emphasis> are often used synonymously.
+	</para>
+
+	<para>
+	  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.
+	</para>
+
+	<section xml:id="forwarder"><info><title>Forwarding</title></info>
+
+	  <para>
+	    Even a caching name server does not necessarily perform
+	    the complete recursive lookup itself.  Instead, it can
+	    <emphasis>forward</emphasis> some or all of the queries
+	    that it cannot satisfy from its cache to another caching name
+	    server,
+	    commonly referred to as a <emphasis>forwarder</emphasis>.
+	  </para>
+
+	  <para>
+	    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 <acronym>DNS</acronym> 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 <acronym>DNS</acronym> servers
+	    on the internal server's behalf.
+	  </para>
+	</section>
+
+      </section>
+
+      <section xml:id="multi_role"><info><title>Name Servers in Multiple Roles</title></info>
+
+	<para>
+	  The <acronym>BIND</acronym> name server can
+	  simultaneously act as
+	  a master for some zones, a slave for other zones, and as a caching
+	  (recursive) server for a set of local clients.
+	</para>
+
+	<para>
+	  However, since the functions of authoritative name service
+	  and caching/recursive name service are logically separate, it is
+	  often advantageous to run them on separate server machines.
+
+	  A server that only provides authoritative name service
+	  (an <emphasis>authoritative-only</emphasis> server) can run with
+	  recursion disabled, improving reliability and security.
+
+	  A server that is not authoritative for any zones and only provides
+	  recursive service to local
+	  clients (a <emphasis>caching-only</emphasis> server)
+	  does not need to be reachable from the Internet at large and can
+	  be placed inside a firewall.
+	</para>
+
+      </section>
+    </section>
+
+  </chapter>
+
+  <chapter xml:id="Bv9ARM.ch02"><info><title><acronym>BIND</acronym> Resource Requirements</title></info>
+
+    <section xml:id="hw_req"><info><title>Hardware requirements</title></info>
+      <para>
+	<acronym>DNS</acronym> hardware requirements have
+	traditionally been quite modest.
+	For many installations, servers that have been pensioned off from
+	active duty have performed admirably as <acronym>DNS</acronym> servers.
+      </para>
+      <para>
+	The DNSSEC features of <acronym>BIND</acronym> 9
+	may prove to be quite
+	CPU intensive however, so organizations that make heavy use of these
+	features may wish to consider larger systems for these applications.
+	<acronym>BIND</acronym> 9 is fully multithreaded, allowing
+	full utilization of
+	multiprocessor systems for installations that need it.
+      </para>
+    </section>
+    <section xml:id="cpu_req"><info><title>CPU Requirements</title></info>
+      <para>
+	CPU requirements for <acronym>BIND</acronym> 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.
+      </para>
+    </section>
+    <section xml:id="mem_req"><info><title>Memory Requirements</title></info>
+      <para>
+	The memory of the server has to be large enough to fit the
+	cache and zones loaded off disk.  The <command>max-cache-size</command>
+	option can be used to limit the amount of memory used by the cache,
+	at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
+	traffic.
+	Additionally, if additional section caching
+	(<xref linkend="acache"/>) is enabled,
+	the <command>max-acache-size</command> option can be used to
+	limit the amount
+	of memory used by the mechanism.
+	It is still good practice to have enough memory to load
+	all zone and cache data into memory — unfortunately, the best
+	way
+	to determine this for a given installation is to watch the name server
+	in operation. After a few weeks the server process should reach
+	a relatively stable size where entries are expiring from the cache as
+	fast as they are being inserted.
+      </para>
+      <!--
+	- Add something here about leaving overhead for attacks?
+	- How much overhead?  Percentage?
+	-->
+    </section>
+
+    <section xml:id="intensive_env"><info><title>Name Server Intensive Environment Issues</title></info>
+
+      <para>
+	For name server intensive environments, there are two alternative
+	configurations that may be used. The first is where clients and
+	any second-level internal name servers query a main name server, which
+	has enough memory to build a large cache. This approach minimizes
+	the bandwidth used by external name lookups. The second alternative
+	is to set up second-level internal name servers to make queries
+	independently.
+	In this configuration, none of the individual machines needs to
+	have as much memory or CPU power as in the first alternative, but
+	this has the disadvantage of making many more external queries,
+	as none of the name servers share their cached data.
+      </para>
+    </section>
+
+    <section xml:id="supported_os"><info><title>Supported Operating Systems</title></info>
+
+      <para>
+	ISC <acronym>BIND</acronym> 9 compiles and runs on a large
+	number
+	of Unix-like operating systems and on
+	Microsoft Windows Server 2003 and 2008, and Windows XP and Vista.
+	For an up-to-date
+	list of supported systems, see the README file in the top level
+	directory
+	of the BIND 9 source distribution.
+      </para>
+    </section>
+  </chapter>
+
+  <chapter xml:id="Bv9ARM.ch03"><info><title>Name Server Configuration</title></info>
+
+    <para>
+      In this chapter we provide some suggested configurations along
+      with guidelines for their use.  We suggest reasonable values for
+      certain option settings.
+    </para>
+
+    <section xml:id="sample_configuration"><info><title>Sample Configurations</title></info>
+
+      <section xml:id="cache_only_sample"><info><title>A Caching-only Name Server</title></info>
+
+	<para>
+	  The following sample configuration is appropriate for a caching-only
+	  name server for use by clients internal to a corporation.  All
+	  queries
+	  from outside clients are refused using the <command>allow-query</command>
+	  option.  Alternatively, the same effect could be achieved using
+	  suitable
+	  firewall rules.
+	</para>
+
+<programlisting>
+// Two corporate subnets we wish to allow queries from.
+acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
+options {
+     // Working directory
+     directory "/etc/namedb";
+
+     allow-query { corpnets; };
+};
+// Provide a reverse mapping for the loopback
+// address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+</programlisting>
+
+      </section>
+
+      <section xml:id="auth_only_sample"><info><title>An Authoritative-only Name Server</title></info>
+
+	<para>
+	  This sample configuration is for an authoritative-only server
+	  that is the master server for "<filename>example.com</filename>"
+	  and a slave for the subdomain "<filename>eng.example.com</filename>".
+	</para>
+
+<programlisting>
+options {
+     // Working directory
+     directory "/etc/namedb";
+     // Do not allow access to cache
+     allow-query-cache { none; };
+     // This is the default
+     allow-query { any; };
+     // Do not provide recursive service
+     recursion no;
+};
+
+// Provide a reverse mapping for the loopback
+// address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+// We are the master server for example.com
+zone "example.com" {
+     type master;
+     file "example.com.db";
+     // IP addresses of slave 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
+zone "eng.example.com" {
+     type slave;
+     file "eng.example.com.bk";
+     // IP address of eng.example.com master server
+     masters { 192.168.4.12; };
+};
+</programlisting>
+
+      </section>
+    </section>
+
+    <section xml:id="load_balancing"><info><title>Load Balancing</title></info>
+
+      <!--
+	- Add explanation of why load balancing is fragile at best
+	- and completely pointless in the general case.
+	-->
+
+      <para>
+	A primitive form of load balancing can be achieved in
+	the <acronym>DNS</acronym> by using multiple records
+	(such as multiple A records) for one name.
+      </para>
+
+      <para>
+	For example, if you have three WWW servers with network addresses
+	of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the
+	following means that clients will connect to each machine one third
+	of the time:
+      </para>
+
+      <informaltable colsep="0" rowsep="0">
+	<tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="2Level-table">
+	  <colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
+	  <colspec colname="2" colnum="2" colsep="0" colwidth="0.500in"/>
+	  <colspec colname="3" colnum="3" colsep="0" colwidth="0.750in"/>
+	  <colspec colname="4" colnum="4" colsep="0" colwidth="0.750in"/>
+	  <colspec colname="5" colnum="5" colsep="0" colwidth="2.028in"/>
+	  <tbody>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  Name
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  TTL
+		</para>
+	      </entry>
+	      <entry colname="3">
+		<para>
+		  CLASS
+		</para>
+	      </entry>
+	      <entry colname="4">
+		<para>
+		  TYPE
+		</para>
+	      </entry>
+	      <entry colname="5">
+		<para>
+		  Resource Record (RR) Data
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <literal>www</literal>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  <literal>600</literal>
+		</para>
+	      </entry>
+	      <entry colname="3">
+		<para>
+		  <literal>IN</literal>
+		</para>
+	      </entry>
+	      <entry colname="4">
+		<para>
+		  <literal>A</literal>
+		</para>
+	      </entry>
+	      <entry colname="5">
+		<para>
+		  <literal>10.0.0.1</literal>
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para/>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  <literal>600</literal>
+		</para>
+	      </entry>
+	      <entry colname="3">
+		<para>
+		  <literal>IN</literal>
+		</para>
+	      </entry>
+	      <entry colname="4">
+		<para>
+		  <literal>A</literal>
+		</para>
+	      </entry>
+	      <entry colname="5">
+		<para>
+		  <literal>10.0.0.2</literal>
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para/>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  <literal>600</literal>
+		</para>
+	      </entry>
+	      <entry colname="3">
+		<para>
+		  <literal>IN</literal>
+		</para>
+	      </entry>
+	      <entry colname="4">
+		<para>
+		  <literal>A</literal>
+		</para>
+	      </entry>
+	      <entry colname="5">
+		<para>
+		  <literal>10.0.0.3</literal>
+		</para>
+	      </entry>
+	    </row>
+	  </tbody>
+	</tgroup>
+      </informaltable>
+      <para>
+	When a resolver queries for these records, <acronym>BIND</acronym> will rotate
+	them and respond to the query with the records in a different
+	order.  In the example above, clients will randomly receive
+	records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
+	will use the first record returned and discard the rest.
+      </para>
+      <para>
+	For more detail on ordering responses, check the
+	<command>rrset-order</command> sub-statement in the
+	<command>options</command> statement, see
+	<xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.
+      </para>
+
+    </section>
+
+    <section xml:id="ns_operations"><info><title>Name Server Operations</title></info>
+
+      <section xml:id="tools"><info><title>Tools for Use With the Name Server Daemon</title></info>
+	<para>
+	  This section describes several indispensable diagnostic,
+	  administrative and monitoring tools available to the system
+	  administrator for controlling and debugging the name server
+	  daemon.
+	</para>
+	<section xml:id="diagnostic_tools"><info><title>Diagnostic Tools</title></info>
+	  <para>
+	    The <command>dig</command>, <command>host</command>, and
+	    <command>nslookup</command> programs are all command
+	    line tools
+	    for manually querying name servers.  They differ in style and
+	    output format.
+	  </para>
+
+	  <variablelist>
+	    <varlistentry>
+	      <term xml:id="dig"><command>dig</command></term>
+	      <listitem>
+		<para>
+		  <command>dig</command>
+		  is the most versatile and complete of these lookup tools.
+		  It has two modes: simple interactive
+		  mode for a single query, and batch mode which executes a
+		  query for
+		  each in a list of several query lines. All query options are
+		  accessible
+		  from the command line.
+		</para>
+		<cmdsynopsis label="Usage" sepchar=" ">
+		  <command>dig</command>
+		  <arg choice="opt" rep="norepeat">@<replaceable>server</replaceable></arg>
+		  <arg choice="plain" rep="norepeat"><replaceable>domain</replaceable></arg>
+		  <arg choice="opt" rep="norepeat"><replaceable>query-type</replaceable></arg>
+		  <arg choice="opt" rep="norepeat"><replaceable>query-class</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">+<replaceable>query-option</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-<replaceable>dig-option</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">%<replaceable>comment</replaceable></arg>
+		</cmdsynopsis>
+		<para>
+		  The usual simple use of <command>dig</command> will take the form
+		</para>
+		<simpara>
+		  <command>dig @server domain query-type query-class</command>
+		</simpara>
+		<para>
+		  For more information and a list of available commands and
+		  options, see the <command>dig</command> man
+		  page.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>host</command></term>
+	      <listitem>
+		<para>
+		  The <command>host</command> utility emphasizes
+		  simplicity
+		  and ease of use.  By default, it converts
+		  between host names and Internet addresses, but its
+		  functionality
+		  can be extended with the use of options.
+		</para>
+		<cmdsynopsis label="Usage" sepchar=" ">
+		  <command>host</command>
+		  <arg choice="opt" rep="norepeat">-aCdlnrsTwv</arg>
+		  <arg choice="opt" rep="norepeat">-c <replaceable>class</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-N <replaceable>ndots</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-t <replaceable>type</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-W <replaceable>timeout</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-R <replaceable>retries</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-m <replaceable>flag</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-4</arg>
+		  <arg choice="opt" rep="norepeat">-6</arg>
+		  <arg choice="plain" rep="norepeat"><replaceable>hostname</replaceable></arg>
+		  <arg choice="opt" rep="norepeat"><replaceable>server</replaceable></arg>
+		</cmdsynopsis>
+		<para>
+		  For more information and a list of available commands and
+		  options, see the <command>host</command> man
+		  page.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>nslookup</command></term>
+	      <listitem>
+		<para><command>nslookup</command>
+		  has two modes: interactive and
+		  non-interactive. Interactive mode allows the user to
+		  query name servers for information about various
+		  hosts and domains or to print a list of hosts in a
+		  domain. Non-interactive mode is used to print just
+		  the name and requested information for a host or
+		  domain.
+		</para>
+		<cmdsynopsis label="Usage" sepchar=" ">
+		  <command>nslookup</command>
+		  <arg rep="repeat" choice="opt">-option</arg>
+		  <group choice="opt" rep="norepeat">
+		    <arg choice="opt" rep="norepeat"><replaceable>host-to-find</replaceable></arg>
+		    <arg choice="opt" rep="norepeat">- <arg choice="opt" rep="norepeat">server</arg></arg>
+		  </group>
+		</cmdsynopsis>
+		<para>
+		  Interactive mode is entered when no arguments are given (the
+		  default name server will be used) or when the first argument
+		  is a
+		  hyphen (`-') and the second argument is the host name or
+		  Internet address
+		  of a name server.
+		</para>
+		<para>
+		  Non-interactive mode is used when the name or Internet
+		  address
+		  of the host to be looked up is given as the first argument.
+		  The
+		  optional second argument specifies the host name or address
+		  of a name server.
+		</para>
+		<para>
+		  Due to its arcane user interface and frequently inconsistent
+		  behavior, we do not recommend the use of <command>nslookup</command>.
+		  Use <command>dig</command> instead.
+		</para>
+	      </listitem>
+
+	    </varlistentry>
+	  </variablelist>
+	</section>
+
+	<section xml:id="admin_tools"><info><title>Administrative Tools</title></info>
+	  <para>
+	    Administrative tools play an integral part in the management
+	    of a server.
+	  </para>
+	  <variablelist>
+	    <varlistentry xml:id="named-checkconf" xreflabel="Named Configuration Checking application">
+
+	      <term><command>named-checkconf</command></term>
+	      <listitem>
+		<para>
+		  The <command>named-checkconf</command> program
+		  checks the syntax of a <filename>named.conf</filename> file.
+		</para>
+		<cmdsynopsis label="Usage" sepchar=" ">
+		  <command>named-checkconf</command>
+		  <arg choice="opt" rep="norepeat">-jvz</arg>
+		  <arg choice="opt" rep="norepeat">-t <replaceable>directory</replaceable></arg>
+		  <arg choice="opt" rep="norepeat"><replaceable>filename</replaceable></arg>
+		</cmdsynopsis>
+	      </listitem>
+	    </varlistentry>
+	    <varlistentry xml:id="named-checkzone" xreflabel="Zone Checking application">
+
+	      <term><command>named-checkzone</command></term>
+	      <listitem>
+		<para>
+		  The <command>named-checkzone</command> program
+		  checks a master file for
+		  syntax and consistency.
+		</para>
+		<cmdsynopsis label="Usage" sepchar=" ">
+		  <command>named-checkzone</command>
+		  <arg choice="opt" rep="norepeat">-djqvD</arg>
+		  <arg choice="opt" rep="norepeat">-c <replaceable>class</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-o <replaceable>output</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-t <replaceable>directory</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-w <replaceable>directory</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-k <replaceable>(ignore|warn|fail)</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-n <replaceable>(ignore|warn|fail)</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-W <replaceable>(ignore|warn)</replaceable></arg>
+		  <arg choice="plain" rep="norepeat"><replaceable>zone</replaceable></arg>
+		  <arg choice="opt" rep="norepeat"><replaceable>filename</replaceable></arg>
+		</cmdsynopsis>
+	      </listitem>
+	    </varlistentry>
+	    <varlistentry xml:id="named-compilezone" xreflabel="Zone Compilation application">
+	      <term><command>named-compilezone</command></term>
+	      <listitem>
+		<para>
+		  Similar to <command>named-checkzone,</command> but
+		  it always dumps the zone content to a specified file
+		  (typically in a different format).
+		</para>
+	      </listitem>
+	    </varlistentry>
+	    <varlistentry xml:id="rndc" xreflabel="Remote Name Daemon Control application">
+
+	      <term><command>rndc</command></term>
+	      <listitem>
+		<para>
+		  The remote name daemon control
+		  (<command>rndc</command>) program allows the
+		  system
+		  administrator to control the operation of a name server.
+		  Since <acronym>BIND</acronym> 9.2, <command>rndc</command>
+		  supports all the commands of the BIND 8 <command>ndc</command>
+		  utility except <command>ndc start</command> and
+		  <command>ndc restart</command>, which were also
+		  not supported in <command>ndc</command>'s
+		  channel mode.
+		  If you run <command>rndc</command> without any
+		  options
+		  it will display a usage message as follows:
+		</para>
+		<cmdsynopsis label="Usage" sepchar=" ">
+		  <command>rndc</command>
+		  <arg choice="opt" rep="norepeat">-c <replaceable>config</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-s <replaceable>server</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-p <replaceable>port</replaceable></arg>
+		  <arg choice="opt" rep="norepeat">-y <replaceable>key</replaceable></arg>
+		  <arg choice="plain" rep="norepeat"><replaceable>command</replaceable></arg>
+		  <arg rep="repeat" choice="opt"><replaceable>command</replaceable></arg>
+		</cmdsynopsis>
+
+		<para>See <xref linkend="man.rndc"/> for details of
+		  the available <command>rndc</command> commands.
+		</para>
+
+		<para>
+		  <command>rndc</command> requires a configuration file,
+		  since all
+		  communication with the server is authenticated with
+		  digital signatures that rely on a shared secret, and
+		  there is no way to provide that secret other than with a
+		  configuration file.  The default location for the
+		  <command>rndc</command> configuration file is
+		  <filename>/etc/rndc.conf</filename>, but an
+		  alternate
+		  location can be specified with the <option>-c</option>
+		  option.  If the configuration file is not found,
+		  <command>rndc</command> will also look in
+		  <filename>/etc/rndc.key</filename> (or whatever
+		  <varname>sysconfdir</varname> was defined when
+		  the <acronym>BIND</acronym> build was
+		  configured).
+		  The <filename>rndc.key</filename> file is
+		  generated by
+		  running <command>rndc-confgen -a</command> as
+		  described in
+		  <xref linkend="controls_statement_definition_and_usage"/>.
+		</para>
+
+		<para>
+		  The format of the configuration file is similar to
+		  that of <filename>named.conf</filename>, but
+		  limited to
+		  only four statements, the <command>options</command>,
+		  <command>key</command>, <command>server</command> and
+		  <command>include</command>
+		  statements.  These statements are what associate the
+		  secret keys to the servers with which they are meant to
+		  be shared.  The order of statements is not
+		  significant.
+		</para>
+
+		<para>
+		  The <command>options</command> statement has
+		  three clauses:
+		  <command>default-server</command>, <command>default-key</command>,
+		  and <command>default-port</command>.
+		  <command>default-server</command> takes a
+		  host name or address argument  and represents the server
+		  that will
+		  be contacted if no <option>-s</option>
+		  option is provided on the command line.
+		  <command>default-key</command> takes
+		  the name of a key as its argument, as defined by a <command>key</command> statement.
+		  <command>default-port</command> specifies the
+		  port to which
+		  <command>rndc</command> should connect if no
+		  port is given on the command line or in a
+		  <command>server</command> statement.
+		</para>
+
+		<para>
+		  The <command>key</command> statement defines a
+		  key to be used
+		  by <command>rndc</command> when authenticating
+		  with
+		  <command>named</command>.  Its syntax is
+		  identical to the
+		  <command>key</command> statement in <filename>named.conf</filename>.
+		  The keyword <userinput>key</userinput> is
+		  followed by a key name, which must be a valid
+		  domain name, though it need not actually be hierarchical;
+		  thus,
+		  a string like "<userinput>rndc_key</userinput>" is a valid
+		  name.
+		  The <command>key</command> statement has two
+		  clauses:
+		  <command>algorithm</command> and <command>secret</command>.
+		  While the configuration parser will accept any string as the
+		  argument
+		  to algorithm, currently only the strings
+		  "<userinput>hmac-md5</userinput>",
+		  "<userinput>hmac-sha1</userinput>",
+		  "<userinput>hmac-sha224</userinput>",
+		  "<userinput>hmac-sha256</userinput>",
+		  "<userinput>hmac-sha384</userinput>"
+		  and "<userinput>hmac-sha512</userinput>"
+		  have any meaning.  The secret is a Base64 encoded string
+		  as specified in RFC 3548.
+		</para>
+
+		<para>
+		  The <command>server</command> statement
+		  associates a key
+		  defined using the <command>key</command>
+		  statement with a server.
+		  The keyword <userinput>server</userinput> is followed by a
+		  host name or address.  The <command>server</command> statement
+		  has two clauses: <command>key</command> and <command>port</command>.
+		  The <command>key</command> clause specifies the
+		  name of the key
+		  to be used when communicating with this server, and the
+		  <command>port</command> clause can be used to
+		  specify the port <command>rndc</command> should
+		  connect
+		  to on the server.
+		</para>
+
+		<para>
+		  A sample minimal configuration file is as follows:
+		</para>
+
+<programlisting>
+key rndc_key {
+     algorithm "hmac-sha256";
+     secret
+       "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
+};
+options {
+     default-server 127.0.0.1;
+     default-key    rndc_key;
+};
+</programlisting>
+
+		<para>
+		  This file, if installed as <filename>/etc/rndc.conf</filename>,
+		  would allow the command:
+		</para>
+
+		<para>
+		  <prompt>$ </prompt><userinput>rndc reload</userinput>
+		</para>
+
+		<para>
+		  to connect to 127.0.0.1 port 953 and cause the name server
+		  to reload, if a name server on the local machine were
+		  running with
+		  following controls statements:
+		</para>
+
+<programlisting>
+controls {
+	inet 127.0.0.1
+	    allow { localhost; } keys { rndc_key; };
+};
+</programlisting>
+
+		<para>
+		  and it had an identical key statement for
+		  <literal>rndc_key</literal>.
+		</para>
+
+		<para>
+		  Running the <command>rndc-confgen</command>
+		  program will
+		  conveniently create a <filename>rndc.conf</filename>
+		  file for you, and also display the
+		  corresponding <command>controls</command>
+		  statement that you need to
+		  add to <filename>named.conf</filename>.
+		  Alternatively,
+		  you can run <command>rndc-confgen -a</command>
+		  to set up
+		  a <filename>rndc.key</filename> file and not
+		  modify
+		  <filename>named.conf</filename> at all.
+		</para>
+
+	      </listitem>
+	    </varlistentry>
+	  </variablelist>
+
+	</section>
+      </section>
+
+      <section xml:id="signals"><info><title>Signals</title></info>
+	<para>
+	  Certain UNIX signals cause the name server to take specific
+	  actions, as described in the following table.  These signals can
+	  be sent using the <command>kill</command> command.
+	</para>
+	<informaltable frame="all">
+	  <tgroup cols="2">
+	    <colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
+	    <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
+	    <tbody>
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para><command>SIGHUP</command></para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Causes the server to read <filename>named.conf</filename> and
+		    reload the database.
+		  </para>
+		</entry>
+	      </row>
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para><command>SIGTERM</command></para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Causes the server to clean up and exit.
+		  </para>
+		</entry>
+	      </row>
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para><command>SIGINT</command></para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Causes the server to clean up and exit.
+		  </para>
+		</entry>
+	      </row>
+	    </tbody>
+	  </tgroup>
+	</informaltable>
+      </section>
+    </section>
+  </chapter>
+
+  <chapter xml:id="Bv9ARM.ch04"><info><title>Advanced DNS Features</title></info>
+
+    <section xml:id="notify"><info><title>Notify</title></info>
+      <para>
+	<acronym>DNS</acronym> NOTIFY is a mechanism that allows master
+	servers to notify their slave servers of changes to a zone's data. In
+	response to a <command>NOTIFY</command> 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.
+      </para>
+
+      <para>
+	For more information about <acronym>DNS</acronym>
+	<command>NOTIFY</command>, see the description of the
+	<command>notify</command> option in <xref linkend="boolean_options"/> and
+	the description of the zone option <command>also-notify</command> in
+	<xref linkend="zone_transfers"/>.  The <command>NOTIFY</command>
+	protocol is specified in RFC 1996.
+      </para>
+
+      <note><simpara>
+	As a slave zone can also be a master to other slaves, <command>named</command>,
+	by default, sends <command>NOTIFY</command> messages for every zone
+	it loads.  Specifying <command>notify master-only;</command> will
+	cause <command>named</command> to only send <command>NOTIFY</command> for master
+	zones that it loads.
+      </simpara></note>
+
+    </section>
+
+    <section xml:id="dynamic_update"><info><title>Dynamic Update</title></info>
+
+      <para>
+	Dynamic Update is a method for adding, replacing or deleting
+	records in a master server by sending it a special form of DNS
+	messages.  The format and meaning of these messages is specified
+	in RFC 2136.
+      </para>
+
+      <para>
+	Dynamic update is enabled by including an
+	<command>allow-update</command> or an <command>update-policy</command>
+	clause in the <command>zone</command> statement.
+      </para>
+
+      <para>
+	If the zone's <command>update-policy</command> is set to
+	<userinput>local</userinput>, updates to the zone
+	will be permitted for the key <varname>local-ddns</varname>,
+	which will be generated by <command>named</command> at startup.
+	See <xref linkend="dynamic_update_policies"/> for more details.
+      </para>
+
+      <para>
+	Dynamic updates using Kerberos signed requests can be made
+	using the TKEY/GSS protocol by setting either the
+	<command>tkey-gssapi-keytab</command> option, or alternatively
+	by setting both the <command>tkey-gssapi-credential</command>
+	and <command>tkey-domain</command> options. Once enabled,
+	Kerberos signed requests will be matched against the update
+	policies for the zone, using the Kerberos principal as the
+	signer for the request.
+      </para>
+
+      <para>
+	Updating of secure zones (zones using DNSSEC) follows RFC
+	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.
+      </para>
+
+      <section xml:id="journal"><info><title>The journal file</title></info>
+
+	<para>
+	  All changes made to a zone using dynamic update are stored
+	  in the zone's journal file.  This file is automatically created
+	  by the server when the first dynamic update takes place.
+	  The name of the journal file is formed by appending the extension
+	  <filename>.jnl</filename> to the name of the
+	  corresponding zone
+	  file unless specifically overridden.  The journal file is in a
+	  binary format and should not be edited manually.
+	</para>
+
+	<para>
+	  The server will also occasionally write ("dump")
+	  the complete contents of the updated zone to its zone file.
+	  This is not done immediately after
+	  each dynamic update, because that would be too slow when a large
+	  zone is updated frequently.  Instead, the dump is delayed by
+	  up to 15 minutes, allowing additional updates to take place.
+	  During the dump process, transient files will be created
+	  with the extensions <filename>.jnw</filename> and
+	  <filename>.jbk</filename>; under ordinary circumstances, these
+	  will be removed when the dump is complete, and can be safely
+	  ignored.
+	</para>
+
+	<para>
+	  When a server is restarted after a shutdown or crash, it will replay
+	      the journal file to incorporate into the zone any updates that
+	  took
+	  place after the last zone dump.
+	</para>
+
+	<para>
+	  Changes that result from incoming incremental zone transfers are
+	  also
+	  journalled in a similar way.
+	</para>
+
+	<para>
+	  The zone files of dynamic zones cannot normally be edited by
+	  hand because they are not guaranteed to contain the most recent
+	  dynamic changes — those are only in the journal file.
+	  The only way to ensure that the zone file of a dynamic zone
+	  is up to date is to run <command>rndc stop</command>.
+	</para>
+
+	<para>
+	  If you have to make changes to a dynamic zone
+	  manually, the following procedure will work:
+	  Disable dynamic updates to the zone using
+	  <command>rndc freeze <replaceable>zone</replaceable></command>.
+	  This will update the zone's master file with the changes
+	  stored in its <filename>.jnl</filename> file.
+	  Edit the zone file.  Run
+	  <command>rndc thaw <replaceable>zone</replaceable></command>
+	  to reload the changed zone and re-enable dynamic updates.
+	</para>
+
+	<para>
+	  <command>rndc sync <replaceable>zone</replaceable></command>
+	  will update 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 <filename>.jnl</filename>
+	  file after updating the zone file, use
+	  <command>rndc sync -clean</command>.
+	</para>
+
+      </section>
+
+    </section>
+
+    <section xml:id="incremental_zone_transfers"><info><title>Incremental Zone Transfers (IXFR)</title></info>
+
+      <para>
+	The incremental zone transfer (IXFR) protocol is a way for
+	slave servers to transfer only changed data, instead of having to
+	transfer the entire zone. The IXFR protocol is specified in RFC
+	1995. See <xref linkend="proposed_standards"/>.
+      </para>
+
+      <para>
+	When acting as a master, <acronym>BIND</acronym> 9
+	supports IXFR for those zones
+	where the necessary change history information is available. These
+	include master zones maintained by dynamic update and slave zones
+	whose data was obtained by IXFR.  For manually maintained master
+	zones, and for slave zones obtained by performing a full zone
+	transfer (AXFR), IXFR is supported only if the option
+	<command>ixfr-from-differences</command> is set
+	to <userinput>yes</userinput>.
+      </para>
+
+      <para>
+	When acting as a slave, <acronym>BIND</acronym> 9 will
+	attempt to use IXFR unless
+	it is explicitly disabled. For more information about disabling
+	IXFR, see the description of the <command>request-ixfr</command> clause
+	of the <command>server</command> statement.
+      </para>
+    </section>
+
+    <section xml:id="split_dns"><info><title>Split DNS</title></info>
+
+      <para>
+	Setting up different views, or visibility, of the DNS space to
+	internal and external resolvers is usually referred to as a
+	<emphasis>Split DNS</emphasis> setup. There are several
+	reasons an organization would want to set up its DNS this way.
+      </para>
+      <para>
+	One common reason for setting up a DNS system this way is
+	to hide "internal" DNS information from "external" clients on the
+	Internet. There is some debate as to whether or not this is actually
+	useful.
+	Internal DNS information leaks out in many ways (via email headers,
+	for example) and most savvy "attackers" can find the information
+	they need using other means.
+	However, since listing addresses of internal servers that
+	external clients cannot possibly reach can result in
+	connection delays and other annoyances, an organization may
+	choose to use a Split DNS to present a consistent view of itself
+	to the outside world.
+      </para>
+      <para>
+	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.
+      </para>
+      <section xml:id="split_dns_sample"><info><title>Example split DNS setup</title></info>
+	<para>
+	  Let's say a company named <emphasis>Example, Inc.</emphasis>
+	  (<literal>example.com</literal>)
+	  has several corporate sites that have an internal network with
+	  reserved
+	  Internet Protocol (IP) space and an external demilitarized zone (DMZ),
+	  or "outside" section of a network, that is available to the public.
+	</para>
+	<para>
+	  <emphasis>Example, Inc.</emphasis> wants its internal clients
+	  to be able to resolve external hostnames and to exchange mail with
+	  people on the outside. The company also wants its internal resolvers
+	  to have access to certain internal-only zones that are not available
+	  at all outside of the internal network.
+	</para>
+	<para>
+	  In order to accomplish this, the company will set up two sets
+	  of name servers. One set will be on the inside network (in the
+	  reserved
+	  IP space) and the other set will be on bastion hosts, which are
+	  "proxy"
+	  hosts that can talk to both sides of its network, in the DMZ.
+	</para>
+	<para>
+	  The internal servers will be configured to forward all queries,
+	  except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>,
+	  and <filename>site2.example.com</filename>, to the servers
+	  in the
+	  DMZ. These internal servers will have complete sets of information
+	  for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>, <filename>site1.internal</filename>,
+	  and <filename>site2.internal</filename>.
+	</para>
+	<para>
+	  To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
+	  the internal name servers must be configured to disallow all queries
+	  to these domains from any external hosts, including the bastion
+	  hosts.
+	</para>
+	<para>
+	  The external servers, which are on the bastion hosts, will
+	  be configured to serve the "public" version of the <filename>site1</filename> and <filename>site2.example.com</filename> zones.
+	  This could include things such as the host records for public servers
+	  (<filename>www.example.com</filename> and <filename>ftp.example.com</filename>),
+	  and mail exchange (MX)  records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).
+	</para>
+	<para>
+	  In addition, the public <filename>site1</filename> and <filename>site2.example.com</filename> zones
+	  should have special MX records that contain wildcard (`*') records
+	  pointing to the bastion hosts. This is needed because external mail
+	  servers do not have any other way of looking up how to deliver mail
+	  to those internal hosts. With the wildcard records, the mail will
+	  be delivered to the bastion host, which can then forward it on to
+	  internal hosts.
+	</para>
+	<para>
+	  Here's an example of a wildcard MX record:
+	</para>
+	<programlisting>*   IN MX 10 external1.example.com.</programlisting>
+	<para>
+	  Now that they accept mail on behalf of anything in the internal
+	  network, the bastion hosts will need to know how to deliver mail
+	  to internal hosts. In order for this to work properly, the resolvers
+	  on
+	  the bastion hosts will need to be configured to point to the internal
+	  name servers for DNS resolution.
+	</para>
+	<para>
+	  Queries for internal hostnames will be answered by the internal
+	  servers, and queries for external hostnames will be forwarded back
+	  out to the DNS servers on the bastion hosts.
+	</para>
+	<para>
+	  In order for all this to work properly, internal clients will
+	  need to be configured to query <emphasis>only</emphasis> the internal
+	  name servers for DNS queries. This could also be enforced via
+	  selective
+	  filtering on the network.
+	</para>
+	<para>
+	  If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s
+	  internal clients will now be able to:
+	</para>
+	<itemizedlist>
+	  <listitem>
+	    <simpara>
+	      Look up any hostnames in the <literal>site1</literal>
+	      and
+	      <literal>site2.example.com</literal> zones.
+	    </simpara>
+	  </listitem>
+	  <listitem>
+	    <simpara>
+	      Look up any hostnames in the <literal>site1.internal</literal> and
+	      <literal>site2.internal</literal> domains.
+	    </simpara>
+	  </listitem>
+	  <listitem>
+	    <simpara>Look up any hostnames on the Internet.</simpara>
+	  </listitem>
+	  <listitem>
+	    <simpara>Exchange mail with both internal and external people.</simpara>
+	  </listitem>
+	</itemizedlist>
+	<para>
+	  Hosts on the Internet will be able to:
+	</para>
+	<itemizedlist>
+	  <listitem>
+	    <simpara>
+	      Look up any hostnames in the <literal>site1</literal>
+	      and
+	      <literal>site2.example.com</literal> zones.
+	    </simpara>
+	  </listitem>
+	  <listitem>
+	    <simpara>
+	      Exchange mail with anyone in the <literal>site1</literal> and
+	      <literal>site2.example.com</literal> zones.
+	    </simpara>
+	  </listitem>
+	</itemizedlist>
+
+	<para>
+	  Here is an example configuration for the setup we just
+	  described above. Note that this is only configuration information;
+	  for information on how to configure your zone files, see <xref linkend="sample_configuration"/>.
+	</para>
+
+	<para>
+	  Internal DNS server config:
+	</para>
+
+<programlisting>
+
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { <varname>bastion-ips-go-here</varname>; };
+
+options {
+    ...
+    ...
+    forward only;
+    // forward to external servers
+    forwarders {
+	<varname>bastion-ips-go-here</varname>;
+    };
+    // sample allow-transfer (no one)
+    allow-transfer { none; };
+    // restrict query access
+    allow-query { internals; externals; };
+    // restrict recursion
+    allow-recursion { internals; };
+    ...
+    ...
+};
+
+// sample master zone
+zone "site1.example.com" {
+  type master;
+  file "m/site1.example.com";
+  // do normal iterative resolution (do not forward)
+  forwarders { };
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+// sample slave zone
+zone "site2.example.com" {
+  type slave;
+  file "s/site2.example.com";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site1.internal" {
+  type master;
+  file "m/site1.internal";
+  forwarders { };
+  allow-query { internals; };
+  allow-transfer { internals; }
+};
+
+zone "site2.internal" {
+  type slave;
+  file "s/site2.internal";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals };
+  allow-transfer { internals; }
+};
+</programlisting>
+
+	<para>
+	  External (bastion host) DNS server config:
+	</para>
+
+<programlisting>
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { bastion-ips-go-here; };
+
+options {
+  ...
+  ...
+  // sample allow-transfer (no one)
+  allow-transfer { none; };
+  // default query access
+  allow-query { any; };
+  // restrict cache access
+  allow-query-cache { internals; externals; };
+  // restrict recursion
+  allow-recursion { internals; externals; };
+  ...
+  ...
+};
+
+// sample slave zone
+zone "site1.example.com" {
+  type master;
+  file "m/site1.foo.com";
+  allow-transfer { internals; externals; };
+};
+
+zone "site2.example.com" {
+  type slave;
+  file "s/site2.foo.com";
+  masters { another_bastion_host_maybe; };
+  allow-transfer { internals; externals; }
+};
+</programlisting>
+
+	<para>
+	  In the <filename>resolv.conf</filename> (or equivalent) on
+	  the bastion host(s):
+	</para>
+
+<programlisting>
+search ...
+nameserver 172.16.72.2
+nameserver 172.16.72.3
+nameserver 172.16.72.4
+</programlisting>
+
+      </section>
+    </section>
+    <section xml:id="tsig"><info><title>TSIG</title></info>
+
+      <para>
+	TSIG (Transaction SIGnatures) is a mechanism for authenticating DNS
+	messages, originally specified in RFC 2845. It allows DNS messages
+	to be cryptographically signed using a shared secret.  TSIG can
+	be used in any DNS transaction, as a way to restrict access to
+	certain server functions (e.g., recursive queries) to authorized
+	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.
+      </para>
+      <para>
+	This is a guide to setting up TSIG in <acronym>BIND</acronym>.
+	It describes the configuration syntax and the process of creating
+	TSIG keys.
+      </para>
+      <para>
+	<command>named</command> supports TSIG for server-to-server
+	communication, and some of the tools included with
+	<acronym>BIND</acronym> support it for sending messages to
+	<command>named</command>:
+	<itemizedlist>
+	  <listitem>
+	    <xref linkend="man.nsupdate"/> supports TSIG via the
+	    <option>-k</option>, <option>-l</option> and
+	    <option>-y</option> command line options, or via
+	    the <command>key</command> command when running
+	    interactively.
+	  </listitem>
+	  <listitem>
+	    <xref linkend="man.dig"/> supports TSIG via the
+	    <option>-k</option> and <option>-y</option> command
+	    line options.
+	  </listitem>
+	</itemizedlist>
+      </para>
+
+      <section><info><title>Generating a Shared Key</title></info>
+	<para>
+	  TSIG keys can be generated using the <command>tsig-keygen</command>
+	  command; the output of the command is a <command>key</command> directive
+	  suitable for inclusion in <filename>named.conf</filename>.  The
+	  key name, algorithm and size can be specified by command line parameters;
+	  the defaults are "tsig-key", HMAC-SHA256, and 256 bits, respectively.
+	</para>
+	<para>
+	  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
+	  <emphasis>host1</emphasis> and <emphasis>host2</emphasis> could
+	  be called "host1-host2.", and this key could be generated using:
+	</para>
+<programlisting>
+  $ tsig-keygen host1-host2. > host1-host2.key
+</programlisting>
+	<para>
+	  This key may then be copied to both hosts.  The key name and secret
+	  must be identical on both hosts.
+	  (Note: copying a shared secret from one server to another is beyond
+	  the scope of the DNS. A secure transport mechanism should be used:
+	  secure FTP, SSL, ssh, telephone, encrypted email, etc.)
+	</para>
+	<para>
+	  <command>tsig-keygen</command> can also be run as
+	  <command>ddns-confgen</command>, in which case its output includes
+	  additional configuration text for setting up dynamic DNS in
+	  <command>named</command>.  See <xref linkend="man.ddns-confgen"/>
+	  for details.
+	</para>
+      </section>
+
+      <section><info><title>Loading A New Key</title></info>
+	<para>
+	  For a key shared between servers called
+	  <emphasis>host1</emphasis> and <emphasis>host2</emphasis>,
+	  the following could be added to each server's
+	  <filename>named.conf</filename> file:
+	</para>
+<programlisting>
+key "host1-host2." {
+	algorithm hmac-sha256;
+	secret "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=";
+};
+</programlisting>
+	<para>
+	  (This is the same key generated above using
+	  <command>tsig-keygen</command>.)
+	</para>
+	<para>
+	  Since this text contains a secret, it
+	  is recommended that either <filename>named.conf</filename> not be
+	  world-readable, or that the <command>key</command> directive
+	  be stored in a file which is not world-readable, and which is
+	  included in <filename>named.conf</filename> via the
+	  <command>include</command> directive.
+	</para>
+	<para>
+	  Once a key has been added to <filename>named.conf</filename> 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.
+	</para>
+	<para>
+	  TSIG keys that are known to a server can be listed using the
+	  command <command>rndc tsig-list</command>.
+	</para>
+      </section>
+
+      <section><info><title>Instructing the Server to Use a Key</title></info>
+	<para>
+	  A server sending a request to another server must be told whether
+	  to use a key, and if so, which key to use.
+	</para>
+	<para>
+	  For example, a key may be specified for each server in the
+	  <command>masters</command> 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
+	  signed using the specified key.  Keys may also be specified
+	  in the <command>also-notify</command> statement of a master
+	  or slave zone, causing NOTIFY messages to be signed using
+	  the specified key.
+	</para>
+	<para>
+	  Keys can also be specified in a <command>server</command>
+	  directive. Adding the following on <emphasis>host1</emphasis>,
+	  if the IP address of <emphasis>host2</emphasis> is 10.1.2.3, would
+	  cause <emphasis>all</emphasis> requests from <emphasis>host1</emphasis>
+	  to <emphasis>host2</emphasis>, including normal DNS queries, to be
+	  signed using the <command>host1-host2.</command> key:
+	</para>
+<programlisting>
+server 10.1.2.3 {
+	keys { host1-host2. ;};
+};
+</programlisting>
+	<para>
+	  Multiple keys may be present in the <command>keys</command>
+	  statement, but only the first one is used.  As this directive does
+	  not contain secrets, it can be used in a world-readable file.
+	</para>
+	<para>
+	  Requests sent by <emphasis>host2</emphasis> to <emphasis>host1</emphasis>
+	  would <emphasis>not</emphasis> be signed, unless a similar
+	  <command>server</command> directive were in <emphasis>host2</emphasis>'s
+	  configuration file.
+	</para>
+	<para>
+	  Whenever any server sends a TSIG-signed DNS request, it will expect
+	  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
+	  rejected.
+	</para>
+      </section>
+
+      <section><info><title>TSIG-Based Access Control</title></info>
+	<para>
+	  TSIG keys may be specified in ACL definitions and ACL directives
+	  such as <command>allow-query</command>, <command>allow-transfer</command>
+	  and <command>allow-update</command>.
+	  The above key would be denoted in an ACL element as
+	  <command>key host1-host2.</command>
+	</para>
+	<para>
+	  An example of an <command>allow-update</command> directive using
+	  a TSIG key:
+	</para>
+<programlisting>
+allow-update { !{ !localnets; any; }; key host1-host2. ;};
+</programlisting>
+	<para>
+	  This allows dynamic updates to succeed only if the UPDATE
+	  request comes from an address in <command>localnets</command>,
+	  <emphasis>and</emphasis> if it is signed using the
+	  <command>host1-host2.</command> key.
+	</para>
+	<para>
+	  See <xref linkend="dynamic_update_policies"/> for a discussion of
+	  the more flexible <command>update-policy</command> statement.
+	</para>
+      </section>
+
+      <section><info><title>Errors</title></info>
+	<para>
+	  Processing of TSIG-signed messages can result in several errors:
+	  <itemizedlist>
+	    <listitem>
+	      If a TSIG-aware server receives a message signed by an
+	      unknown key, the response will be unsigned, with the TSIG
+	      extended error code set to BADKEY.
+	    </listitem>
+	    <listitem>
+	      If a TSIG-aware server receives a message from a known key
+	      but with an invalid signature, the response will be unsigned,
+	      with the TSIG extended error code set to BADSIG.
+	    </listitem>
+	    <listitem>
+	      If a TSIG-aware server receives a message with a time
+	      outside of the allowed range, the response will be signed, with
+	      the TSIG extended error code set to BADTIME, and the time values
+	      will be adjusted so that the response can be successfully
+	      verified.
+	    </listitem>
+	  </itemizedlist>
+	  In all of the above cases, the server will return a response code
+	  of NOTAUTH (not authenticated).
+	</para>
+      </section>
+    </section>
+
+    <section xml:id="tkey"><info><title>TKEY</title></info>
+
+      <para>
+	TKEY (Transaction KEY) is a mechanism for automatically negotiating
+	a shared secret between two hosts, originally specified in RFC 2930.
+      </para>
+      <para>
+	There are several TKEY "modes" that specify how a key is to be
+	generated or assigned.  <acronym>BIND</acronym> 9 implements only
+	one of these modes: Diffie-Hellman key exchange.  Both hosts are
+	required to have a KEY record with algorithm DH (though this
+	record is not required to be present in a zone).
+      </para>
+      <para>
+	The TKEY process is initiated by a client or server by sending
+	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
+	shared secret using Diffie-Hellman key exchange.  The shared secret
+	can then be used by to sign subsequent transactions between the
+	two servers.
+      </para>
+      <para>
+	TSIG keys known by the server, including TKEY-negotiated keys, can
+	be listed using <command>rndc tsig-list</command>.
+      </para>
+      <para>
+	TKEY-negotiated keys can be deleted from a server using
+	<command>rndc tsig-delete</command>.  This can also be done via
+	the TKEY protocol itself, by sending an authenticated TKEY query
+	specifying the "key deletion" mode.
+      </para>
+
+    </section>
+    <section xml:id="sig0"><info><title>SIG(0)</title></info>
+
+      <para>
+	<acronym>BIND</acronym> partially supports DNSSEC SIG(0)
+	transaction signatures as specified in RFC 2535 and RFC 2931.
+	SIG(0) uses public/private keys to authenticate messages.  Access control
+	is performed in the same manner as TSIG keys; privileges can be
+	granted or denied in ACL directives based on the key name.
+      </para>
+      <para>
+	When a SIG(0) signed message is received, it will only be
+	verified if the key is known and trusted by the server. The
+	server will not attempt to recursively fetch or validate the
+	key.
+      </para>
+      <para>
+	SIG(0) signing of multiple-message TCP streams is not supported.
+      </para>
+      <para>
+	The only tool shipped with <acronym>BIND</acronym> 9 that
+	generates SIG(0) signed messages is <command>nsupdate</command>.
+      </para>
+    </section>
+
+    <section xml:id="DNSSEC"><info><title>DNSSEC</title></info>
+      <para>
+	Cryptographic authentication of DNS information is possible
+	through the DNS Security (<emphasis>DNSSEC-bis</emphasis>) extensions,
+	defined in RFC 4033, RFC 4034, and RFC 4035.
+	This section describes the creation and use of DNSSEC signed zones.
+      </para>
+
+      <para>
+	In order to set up a DNSSEC secure zone, there are a series
+	of steps which must be followed.  <acronym>BIND</acronym>
+	9 ships
+	with several tools
+	that are used in this process, which are explained in more detail
+	below.  In all cases, the <option>-h</option> option prints a
+	full list of parameters.  Note that the DNSSEC tools require the
+	keyset files to be in the working directory or the
+	directory specified by the <option>-d</option> option, and
+	that the tools shipped with BIND 9.2.x and earlier are not compatible
+	with the current ones.
+      </para>
+
+      <para>
+	There must also be communication with the administrators of
+	the parent and/or child zone to transmit keys.  A zone's security
+	status must be indicated by the parent zone for a DNSSEC capable
+	resolver to trust its data.  This is done through the presence
+	or absence of a <literal>DS</literal> record at the
+	delegation
+	point.
+      </para>
+
+      <para>
+	For other servers to trust data in this zone, they must
+	either be statically configured with this zone's zone key or the
+	zone key of another zone above this one in the DNS tree.
+      </para>
+
+      <section xml:id="dnssec_keys"><info><title>Generating Keys</title></info>
+
+	<para>
+	  The <command>dnssec-keygen</command> program is used to
+	  generate keys.
+	</para>
+
+	<para>
+	  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
+	  <command>ZONE</command>, and must be usable for
+	  authentication.
+	  It is recommended that zone keys use a cryptographic algorithm
+	  designated as "mandatory to implement" by the IETF; currently
+	  the only one is RSASHA1.
+	</para>
+
+	<para>
+	  The following command will generate a 768-bit RSASHA1 key for
+	  the <filename>child.example</filename> zone:
+	</para>
+
+	<para>
+	  <userinput>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</userinput>
+	</para>
+
+	<para>
+	  Two output files will be produced:
+	  <filename>Kchild.example.+005+12345.key</filename> and
+	  <filename>Kchild.example.+005+12345.private</filename>
+	  (where
+	  12345 is an example of a key tag).  The key filenames contain
+	  the key name (<filename>child.example.</filename>),
+	  algorithm (3
+	  is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in
+	  this case).
+	  The private key (in the <filename>.private</filename>
+	  file) is
+	  used to generate signatures, and the public key (in the
+	  <filename>.key</filename> file) is used for signature
+	  verification.
+	</para>
+
+	<para>
+	  To generate another key with the same properties (but with
+	  a different key tag), repeat the above command.
+	</para>
+
+	<para>
+	  The <command>dnssec-keyfromlabel</command> program is used
+	  to get a key pair from a crypto hardware and build the key
+	  files. Its usage is similar to <command>dnssec-keygen</command>.
+	</para>
+
+	<para>
+	  The public keys should be inserted into the zone file by
+	  including the <filename>.key</filename> files using
+	  <command>$INCLUDE</command> statements.
+	</para>
+
+      </section>
+      <section xml:id="dnssec_signing"><info><title>Signing the Zone</title></info>
+
+	<para>
+	  The <command>dnssec-signzone</command> program is used
+	  to sign a zone.
+	</para>
+
+	<para>
+	  Any <filename>keyset</filename> files corresponding to
+	  secure subzones should be present.  The zone signer will
+	  generate <literal>NSEC</literal>, <literal>NSEC3</literal>
+	  and <literal>RRSIG</literal> records for the zone, as
+	  well as <literal>DS</literal> for the child zones if
+	  <literal>'-g'</literal> is specified.  If <literal>'-g'</literal>
+	  is not specified, then DS RRsets for the secure child
+	  zones need to be added manually.
+	</para>
+
+	<para>
+	  The following command signs the zone, assuming it is in a
+	  file called <filename>zone.child.example</filename>.  By
+		default, all zone keys which have an available private key are
+		used to generate signatures.
+	</para>
+
+	<para>
+	  <userinput>dnssec-signzone -o child.example zone.child.example</userinput>
+	</para>
+
+	<para>
+	  One output file is produced:
+	  <filename>zone.child.example.signed</filename>.  This
+	  file
+	  should be referenced by <filename>named.conf</filename>
+	  as the
+	  input file for the zone.
+	</para>
+
+	<para><command>dnssec-signzone</command>
+	  will also produce a keyset and dsset files and optionally a
+	  dlvset file.  These are used to provide the parent zone
+	  administrators with the <literal>DNSKEYs</literal> (or their
+	  corresponding <literal>DS</literal> records) that are the
+	  secure entry point to the zone.
+	</para>
+
+      </section>
+
+      <section xml:id="dnssec_config"><info><title>Configuring Servers</title></info>
+
+	<para>
+	  To enable <command>named</command> to respond appropriately
+	  to DNS requests from DNSSEC aware clients,
+	  <command>dnssec-enable</command> must be set to yes.
+	  (This is the default setting.)
+	</para>
+
+	<para>
+	  To enable <command>named</command> to validate answers from
+	  other servers, the <command>dnssec-enable</command> option
+	  must be set to <userinput>yes</userinput>, and the
+	  <command>dnssec-validation</command> options must be set to
+	  <userinput>yes</userinput> or <userinput>auto</userinput>.
+	</para>
+
+	<para>
+	  If <command>dnssec-validation</command> is set to
+	  <userinput>auto</userinput>, then a default
+	  trust anchor for the DNS root zone will be used.
+	  If it is set to <userinput>yes</userinput>, however,
+	  then at least one trust anchor must be configured
+	  with a <command>trusted-keys</command> or
+	  <command>managed-keys</command> statement in
+	  <filename>named.conf</filename>, or DNSSEC validation
+	  will not occur.  The default setting is
+	  <userinput>yes</userinput>.
+	</para>
+
+	<para>
+	  <command>trusted-keys</command> are copies of DNSKEY RRs
+	  for zones that are used to form the first link in the
+	  cryptographic chain of trust.  All keys listed in
+	  <command>trusted-keys</command> (and corresponding zones)
+	  are deemed to exist and only the listed keys will be used
+	  to validated the DNSKEY RRset that they are from.
+	</para>
+
+	<para>
+	  <command>managed-keys</command> are trusted keys which are
+	  automatically kept up to date via RFC 5011 trust anchor
+	  maintenance.
+	</para>
+
+	<para>
+	  <command>trusted-keys</command> and
+	  <command>managed-keys</command> are described in more detail
+	  later in this document.
+	</para>
+
+	<para>
+	  Unlike <acronym>BIND</acronym> 8, <acronym>BIND</acronym>
+	  9 does not verify signatures on load, so zone keys for
+	  authoritative zones do not need to be specified in the
+	  configuration file.
+	</para>
+
+	<para>
+	  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
+	  controls.  These are here to ensure that <command>named</command>
+	  is immune to compromises in the DNSSEC components of the security
+	  of parent zones.
+	</para>
+
+<programlisting>
+managed-keys {
+	/* Root Key */
+	"." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
+				 JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
+				 aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
+				 4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
+				 hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
+				 5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
+				 g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
+				 66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
+				 97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
+				 dgxbcDTClU0CRBdiieyLMNzXG3";
+};
+
+trusted-keys {
+	/* Key for our organization's forward zone */
+	example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
+			      5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
+			      GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
+			      4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
+			      kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O
+			      g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
+			      TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
+			      FxmAVZP20igTixin/1LcrgX/KMEGd/biuv
+			      F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
+			      /oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o
+			      1OTQ09A0=";
+
+	/* Key for our reverse zone. */
+	2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc
+				       xOdNax071L18QqZnQQQAVVr+i
+				       LhGTnNGp3HoWQLUIzKrJVZ3zg
+				       gy3WwNT6kZo6c0tszYqbtvchm
+				       gQC8CzKojM/W16i6MG/eafGU3
+				       siaOdS0yOI6BgPsw+YZdzlYMa
+				       IJGf4M4dyoKIhzdZyQ2bYQrjy
+				       Q4LB0lC7aOnsMyYKHHYeRvPxj
+				       IQXmdqgOJGq+vsevG06zW+1xg
+				       YJh9rCIfnm1GX/KMgxLPG2vXT
+				       D/RnLX+D3T3UL7HJYHJhAZD5L
+				       59VvjSPsZJHeDCUyWYrvPZesZ
+				       DIRvhDD52SKvbheeTJUm6Ehkz
+				       ytNN2SN96QRk8j/iI8ib";
+};
+
+options {
+	...
+	dnssec-enable yes;
+	dnssec-validation yes;
+};
+</programlisting>
+
+	<note><simpara>
+	  None of the keys listed in this example are valid.  In particular,
+	  the root key is not valid.
+	</simpara></note>
+
+	<para>
+	  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.
+	</para>
+
+	<para>
+	  Responses may fail to validate for any of several reasons,
+	  including missing, expired, or invalid signatures, a key which
+	  does not match the DS RRset in the parent zone, or an insecure
+	  response from a zone which, according to its parent, should have
+	  been secure.
+	</para>
+
+	<note>
+	  <para>
+	    When the validator receives a response from an unsigned zone
+	    that has a signed parent, it must confirm with the parent
+	    that the zone was intentionally left unsigned.  It does
+	    this by verifying, via signed and validated NSEC/NSEC3 records,
+	    that the parent zone contains no DS records for the child.
+	  </para>
+	  <para>
+	    If the validator <emphasis>can</emphasis> 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
+	    forgery; it rejects the response and logs an error.
+	  </para>
+	  <para>
+	    The logged error reads "insecurity proof failed" and
+	    "got insecure response; parent indicates it should be secure".
+	  </para>
+	</note>
+      </section>
+    </section>
+
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dnssec.xml"/>
+
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="managed-keys.xml"/>
+
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="pkcs11.xml"/>
+
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dlz.xml"/>
+
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dyndb.xml"/>
+
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="catz.xml"/>
+
+    <section xml:id="ipv6"><info><title>IPv6 Support in <acronym>BIND</acronym> 9</title></info>
+      <para>
+	<acronym>BIND</acronym> 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.
+      </para>
+
+      <para>
+	For forward lookups, <acronym>BIND</acronym> 9 supports
+	only AAAA records.  RFC 3363 deprecated the use of A6 records,
+	and client-side support for A6 records was accordingly removed
+	from <acronym>BIND</acronym> 9.
+	However, authoritative <acronym>BIND</acronym> 9 name servers still
+	load zone files containing A6 records correctly, answer queries
+	for A6 records, and accept zone transfer for a zone containing A6
+	records.
+      </para>
+
+      <para>
+	For IPv6 reverse lookups, <acronym>BIND</acronym> 9 supports
+	the traditional "nibble" format used in the
+	<emphasis>ip6.arpa</emphasis> domain, as well as the older, deprecated
+	<emphasis>ip6.int</emphasis> domain.
+	Older versions of <acronym>BIND</acronym> 9
+	supported the "binary label" (also known as "bitstring") format,
+	but support of binary labels has been completely removed per
+	RFC 3363.
+	Many applications in <acronym>BIND</acronym> 9 do not understand
+	the binary label format at all any more, and will return an
+	error if given.
+	In particular, an authoritative <acronym>BIND</acronym> 9
+	name server will not load a zone file containing binary labels.
+      </para>
+
+      <para>
+	For an overview of the format and structure of IPv6 addresses,
+	see <xref linkend="ipv6addresses"/>.
+      </para>
+
+      <section><info><title>Address Lookups Using AAAA Records</title></info>
+
+	<para>
+	  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,
+	</para>
+
+<programlisting>
+$ORIGIN example.com.
+host            3600    IN      AAAA    2001:db8::1
+</programlisting>
+
+	<para>
+	  Use of IPv4-in-IPv6 mapped addresses is not recommended.
+	  If a host has an IPv4 address, use an A record, not
+	  a AAAA, with <literal>::ffff:192.168.42.1</literal> as
+	  the address.
+	</para>
+      </section>
+      <section><info><title>Address to Name Lookups Using Nibble Format</title></info>
+
+	<para>
+	  When looking up an address in nibble format, the address
+	  components are simply reversed, just as in IPv4, and
+	  <literal>ip6.arpa.</literal> is appended to the
+	  resulting name.
+	  For example, the following would provide reverse name lookup for
+	  a host with address
+	  <literal>2001:db8::1</literal>.
+	</para>
+
+<programlisting>
+$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
+1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  14400   IN    PTR    (
+				    host.example.com. )
+</programlisting>
+
+      </section>
+    </section>
+  </chapter>
+
+  <chapter xml:id="Bv9ARM.ch05"><info><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title></info>
+
+    <section xml:id="lightweight_resolver"><info><title>The Lightweight Resolver Library</title></info>
+
+      <para>
+	Traditionally applications have been linked with a stub resolver
+	library that sends recursive DNS queries to a local caching name
+	server.
+      </para>
+      <para>
+	IPv6 once introduced new complexity into the resolution process,
+	such as following A6 chains and DNAME records, and simultaneous
+	lookup of IPv4 and IPv6 addresses.  Though most of the complexity was
+	then removed, these are hard or impossible
+	to implement in a traditional stub resolver.
+      </para>
+      <para>
+	<acronym>BIND</acronym> 9 therefore can also provide resolution
+	services to local clients
+	using a combination of a lightweight resolver library and a resolver
+	daemon process running on the local host.  These communicate using
+	a simple UDP-based protocol, the "lightweight resolver protocol"
+	that is distinct from and simpler than the full DNS protocol.
+      </para>
+    </section>
+    <section xml:id="lwresd"><info><title>Running a Resolver Daemon</title></info>
+
+      <para>
+	To use the lightweight resolver interface, the system must
+	run the resolver daemon <command>lwresd</command> or a
+	local
+	name server configured with a <command>lwres</command>
+	statement.
+      </para>
+
+      <para>
+	By default, applications using the lightweight resolver library will
+	make
+	UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.
+	The
+	address can be overridden by <command>lwserver</command>
+	lines in
+	<filename>/etc/resolv.conf</filename>.
+      </para>
+
+      <para>
+	The daemon currently only looks in the DNS, but in the future
+	it may use other sources such as <filename>/etc/hosts</filename>,
+	NIS, etc.
+      </para>
+
+      <para>
+	The <command>lwresd</command> daemon is essentially a
+	caching-only name server that responds to requests using the
+	lightweight
+	resolver protocol rather than the DNS protocol.  Because it needs
+	to run on each host, it is designed to require no or minimal
+	configuration.
+	Unless configured otherwise, it uses the name servers listed on
+	<command>nameserver</command> lines in <filename>/etc/resolv.conf</filename>
+	as forwarders, but is also capable of doing the resolution
+	autonomously if
+	none are specified.
+      </para>
+      <para>
+	The <command>lwresd</command> daemon may also be
+	configured with a
+	<filename>named.conf</filename> style configuration file,
+	in
+	<filename>/etc/lwresd.conf</filename> by default.  A name
+	server may also
+	be configured to act as a lightweight resolver daemon using the
+	<command>lwres</command> statement in <filename>named.conf</filename>.
+      </para>
+      <para>
+	The number of client queries that the <command>lwresd</command>
+	daemon is able to serve can be set using the
+	<option>lwres-tasks</option> and <option>lwres-clients</option>
+	statements in the configuration.
+      </para>
+    </section>
+  </chapter>
+
+  <chapter xml:id="Bv9ARM.ch06"><info><title><acronym>BIND</acronym> 9 Configuration Reference</title></info>
+
+    <para>
+      <acronym>BIND</acronym> 9 configuration is broadly similar
+      to <acronym>BIND</acronym> 8; however, there are a few new
+      areas
+      of configuration, such as views. <acronym>BIND</acronym>
+      8 configuration files should work with few alterations in <acronym>BIND</acronym>
+      9, although more complex configurations should be reviewed to check
+      if they can be more efficiently implemented using the new features
+      found in <acronym>BIND</acronym> 9.
+    </para>
+
+    <para>
+      <acronym>BIND</acronym> 4 configuration files can be
+      converted to the new format
+      using the shell script
+      <filename>contrib/named-bootconf/named-bootconf.sh</filename>.
+    </para>
+    <section xml:id="configuration_file_elements"><info><title>Configuration File Elements</title></info>
+
+      <para>
+	Following is a list of elements used throughout the <acronym>BIND</acronym> configuration
+	file documentation:
+      </para>
+      <informaltable colsep="0" rowsep="0">
+	<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
+	  <colspec colname="1" colnum="1" colsep="0" colwidth="1.855in"/>
+	  <colspec colname="2" colnum="2" colsep="0" colwidth="3.770in"/>
+	  <tbody>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>acl_name</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  The name of an <varname>address_match_list</varname> as
+		  defined by the <command>acl</command> statement.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>address_match_list</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A list of one or more
+		  <varname>ip_addr</varname>,
+		  <varname>ip_prefix</varname>, <varname>key_id</varname>,
+		  or <varname>acl_name</varname> elements, see
+		  <xref linkend="address_match_lists"/>.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>masters_list</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A named list of one or more <varname>ip_addr</varname>
+		  with optional <varname>key_id</varname> and/or
+		  <varname>ip_port</varname>.
+		  A <varname>masters_list</varname> may include other
+		  <varname>masters_lists</varname>.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>domain_name</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A quoted string which will be used as
+		  a DNS name, for example "<literal>my.test.domain</literal>".
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>namelist</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A list of one or more <varname>domain_name</varname>
+		  elements.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>dotted_decimal</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  One to four integers valued 0 through
+		  255 separated by dots (`.'), such as <command>123</command>,
+		  <command>45.67</command> or <command>89.123.45.67</command>.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>ip4_addr</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  An IPv4 address with exactly four elements
+		  in <varname>dotted_decimal</varname> notation.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>ip6_addr</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  An IPv6 address, such as <command>2001:db8::1234</command>.
+		  IPv6 scoped addresses that have ambiguity on their
+		  scope zones must be disambiguated by an appropriate
+		  zone ID with the percent character (`%') as
+		  delimiter.  It is strongly recommended to use
+		  string zone names rather than numeric identifiers,
+		  in order 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
+		  are supported, assuming one-to-one mapping between
+		  interfaces and links.  For example, a link-local
+		  address <command>fe80::1</command> on the link
+		  attached to the interface <command>ne0</command>
+		  can be specified as <command>fe80::1%ne0</command>.
+		  Note that on most systems link-local addresses
+		  always have the ambiguity, and need to be
+		  disambiguated.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>ip_addr</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  An <varname>ip4_addr</varname> or <varname>ip6_addr</varname>.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>ip_dscp</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A <varname>number</varname> between 0 and 63, used
+		  to select a differentiated services code point (DSCP)
+		  value for use with outgoing traffic on operating systems
+		  that support DSCP.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>ip_port</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  An IP port <varname>number</varname>.
+		  The <varname>number</varname> is limited to 0
+		  through 65535, with values
+		  below 1024 typically restricted to use by processes running
+		  as root.
+		  In some cases, an asterisk (`*') character can be used as a
+		  placeholder to
+		  select a random high-numbered port.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>ip_prefix</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  An IP network specified as an <varname>ip_addr</varname>,
+		  followed by a slash (`/') and then the number of bits in the
+		  netmask.
+		  Trailing zeros in a <varname>ip_addr</varname>
+		  may omitted.
+		  For example, <command>127/8</command> is the
+		  network <command>127.0.0.0</command> with
+		  netmask <command>255.0.0.0</command> and <command>1.2.3.0/28</command> is
+		  network <command>1.2.3.0</command> with netmask <command>255.255.255.240</command>.
+		</para>
+		<para>
+		  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.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>key_id</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A <varname>domain_name</varname> representing
+		  the name of a shared key, to be used for transaction
+		  security.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>key_list</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A list of one or more
+		  <varname>key_id</varname>s,
+		  separated by semicolons and ending with a semicolon.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>number</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A non-negative 32-bit integer
+		  (i.e., a number between 0 and 4294967295, inclusive).
+		  Its acceptable value might be further
+		  limited by the context in which it is used.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>fixedpoint</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A non-negative real number that can be specified to
+		  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.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>path_name</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A quoted string which will be used as
+		  a pathname, such as <filename>zones/master/my.test.domain</filename>.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>port_list</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A list of an <varname>ip_port</varname> or a port
+		  range.
+		  A port range is specified in the form of
+		  <userinput>range</userinput> followed by
+		  two <varname>ip_port</varname>s,
+		  <varname>port_low</varname> and
+		  <varname>port_high</varname>, which represents
+		  port numbers from <varname>port_low</varname> through
+		  <varname>port_high</varname>, inclusive.
+		  <varname>port_low</varname> must not be larger than
+		  <varname>port_high</varname>.
+		  For example,
+		  <userinput>range 1024 65535</userinput> represents
+		  ports from 1024 through 65535.
+		  In either case an asterisk (`*') character is not
+		  allowed as a valid <varname>ip_port</varname>.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>size_spec</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  A 64-bit unsigned integer, or the keywords
+		  <userinput>unlimited</userinput> or
+		  <userinput>default</userinput>.
+		</para>
+		<para>
+		  Integers may take values
+		  0 &lt;= value &lt;= 18446744073709551615, though
+		  certain parameters
+		  (such as <command>max-journal-size</command>) may
+		  use a more limited range within these extremes.
+		  In most cases, setting a value to 0 does not
+		  literally mean zero; it means "undefined" or
+		  "as big as possible", depending on the context.
+		  See the explanations of particular parameters
+		  that use <varname>size_spec</varname>
+		  for details on how they interpret its use.
+		</para>
+		<para>
+		  Numeric values can optionally be followed by a
+		  scaling factor:
+		  <userinput>K</userinput> or <userinput>k</userinput>
+		  for kilobytes,
+		  <userinput>M</userinput> or <userinput>m</userinput>
+		  for megabytes, and
+		  <userinput>G</userinput> or <userinput>g</userinput>
+		  for gigabytes, which scale by 1024, 1024*1024, and
+		  1024*1024*1024 respectively.
+		</para>
+		<para>
+		  <varname>unlimited</varname> generally means
+		  "as big as possible", and is usually the best
+		  way to safely set a very large number.
+		</para>
+		<para>
+		  <varname>default</varname>
+		  uses the limit that was in force when the server was started.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>size_or_percent</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  <varname>size_spec</varname> or integer value
+		  followed by '%' to represent percents.
+		</para>
+		<para>
+		  The behavior is exactly the same as
+		  <varname>size_spec</varname>, but
+		  <varname>size_or_percent</varname> allows also
+		  to specify a positive integer value followed by
+		  '%' sign to represent percents.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>yes_or_no</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  Either <userinput>yes</userinput> or <userinput>no</userinput>.
+		  The words <userinput>true</userinput> and <userinput>false</userinput> are
+		  also accepted, as are the numbers <userinput>1</userinput>
+		  and <userinput>0</userinput>.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para>
+		  <varname>dialup_option</varname>
+		</para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  One of <userinput>yes</userinput>,
+		  <userinput>no</userinput>, <userinput>notify</userinput>,
+		  <userinput>notify-passive</userinput>, <userinput>refresh</userinput> or
+		  <userinput>passive</userinput>.
+		  When used in a zone, <userinput>notify-passive</userinput>,
+		  <userinput>refresh</userinput>, and <userinput>passive</userinput>
+		  are restricted to slave and stub zones.
+		</para>
+	      </entry>
+	    </row>
+	  </tbody>
+	</tgroup>
+      </informaltable>
+      <section xml:id="address_match_lists"><info><title>Address Match Lists</title></info>
+
+	<section><info><title>Syntax</title></info>
+
+<programlisting><replaceable>address_match_list</replaceable> = <replaceable>address_match_list_element</replaceable> <command>;</command> ...
+
+<replaceable>address_match_list_element</replaceable> = [ <command>!</command> ] ( <replaceable>ip_address</replaceable> | <replaceable>ip_prefix</replaceable> |
+     <command>key</command> <replaceable>key_id</replaceable> | <replaceable>acl_name</replaceable> | <command>{</command> <replaceable>address_match_list</replaceable> <command>}</command> )
+</programlisting>
+
+	</section>
+	<section><info><title>Definition and Usage</title></info>
+
+	  <para>
+	    Address match lists are primarily used to determine access
+	    control for various server operations. They are also used in
+	    the <command>listen-on</command> and <command>sortlist</command>
+	    statements. The elements which constitute an address match
+	    list can be any of the following:
+	  </para>
+	  <itemizedlist>
+	    <listitem>
+	      <simpara>an IP address (IPv4 or IPv6)</simpara>
+	    </listitem>
+	    <listitem>
+	      <simpara>an IP prefix (in `/' notation)</simpara>
+	    </listitem>
+	    <listitem>
+	      <simpara>
+		a key ID, as defined by the <command>key</command>
+		statement
+	      </simpara>
+	    </listitem>
+	    <listitem>
+	      <simpara>the name of an address match list defined with
+		the <command>acl</command> statement
+	      </simpara>
+	    </listitem>
+	    <listitem>
+	      <simpara>a nested address match list enclosed in braces</simpara>
+	    </listitem>
+	  </itemizedlist>
+
+	  <para>
+	    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.
+	  </para>
+
+	  <para>
+	    The addition of the key clause made the name of this syntactic
+	    element something of a misnomer, since security keys can be used
+	    to validate access without regard to a host or network address.
+	    Nonetheless, the term "address match list" is still used
+	    throughout the documentation.
+	  </para>
+
+	  <para>
+	    When a given IP address or prefix is compared to an address
+	    match list, the comparison takes place in approximately O(1)
+	    time.  However, key comparisons require that the list of keys
+	    be traversed until a matching key is found, and therefore may
+	    be somewhat slower.
+	  </para>
+
+	  <para>
+	    The interpretation of a match depends on whether the list is being
+	    used for access control, defining <command>listen-on</command> ports, or in a
+	    <command>sortlist</command>, and whether the element was negated.
+	  </para>
+
+	  <para>
+	    When used as an access control list, a non-negated match
+	    allows access and a negated match denies access. If
+	    there is no match, access is denied. The clauses
+	    <command>allow-notify</command>,
+	    <command>allow-recursion</command>,
+	    <command>allow-recursion-on</command>,
+	    <command>allow-query</command>,
+	    <command>allow-query-on</command>,
+	    <command>allow-query-cache</command>,
+	    <command>allow-query-cache-on</command>,
+	    <command>allow-transfer</command>,
+	    <command>allow-update</command>,
+	    <command>allow-update-forwarding</command>,
+	    <command>blackhole</command>, and
+	    <command>keep-response-order</command> all use address match
+	    lists.  Similarly, the <command>listen-on</command> option will cause the
+	    server to refuse queries on any of the machine's
+	    addresses which do not match the list.
+	  </para>
+
+	  <para>
+	    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
+	    <emphasis>first</emphasis> in the ACL definition.
+	    Because of this first-match behavior, an element that
+	    defines a subset of another element in the list should
+	    come before the broader element, regardless of whether
+	    either is negated. For example, in
+	    <command>1.2.3/24; ! 1.2.3.13;</command>
+	    the 1.2.3.13 element is completely useless because the
+	    algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24
+	    element.  Using <command>! 1.2.3.13; 1.2.3/24</command> fixes
+	    that problem by having 1.2.3.13 blocked by the negation, but
+	    all other 1.2.3.* hosts fall through.
+	  </para>
+	</section>
+      </section>
+
+      <section xml:id="comment_syntax"><info><title>Comment Syntax</title></info>
+
+	<para>
+	  The <acronym>BIND</acronym> 9 comment syntax allows for
+	  comments to appear
+	  anywhere that whitespace may appear in a <acronym>BIND</acronym> configuration
+	  file. To appeal to programmers of all kinds, they can be written
+	  in the C, C++, or shell/perl style.
+	</para>
+
+	<section><info><title>Syntax</title></info>
+
+	  <para>
+	    <programlisting>/* This is a <acronym>BIND</acronym> comment as in C */</programlisting>
+	    <programlisting>// This is a <acronym>BIND</acronym> comment as in C++</programlisting>
+	    <programlisting># This is a <acronym>BIND</acronym> comment as in common UNIX shells
+# and perl</programlisting>
+	  </para>
+	</section>
+	<section><info><title>Definition and Usage</title></info>
+
+	  <para>
+	    Comments may appear anywhere that whitespace may appear in
+	    a <acronym>BIND</acronym> configuration file.
+	  </para>
+	  <para>
+	    C-style comments start with the two characters /* (slash,
+	    star) and end with */ (star, slash). Because they are completely
+	    delimited with these characters, they can be used to comment only
+	    a portion of a line or to span multiple lines.
+	  </para>
+	  <para>
+	    C-style comments cannot be nested. For example, the following
+	    is not valid because the entire comment ends with the first */:
+	  </para>
+	  <para>
+
+<programlisting>/* This is the start of a comment.
+   This is still part of the comment.
+/* This is an incorrect attempt at nesting a comment. */
+   This is no longer in any comment. */
+</programlisting>
+
+	  </para>
+
+	  <para>
+	    C++-style comments start with the two characters // (slash,
+	    slash) and continue to the end of the physical line. They cannot
+	    be continued across multiple physical lines; to have one logical
+	    comment span multiple lines, each line must use the // pair.
+	    For example:
+	  </para>
+	  <para>
+
+<programlisting>// This is the start of a comment.  The next line
+// is a new comment, even though it is logically
+// part of the previous comment.
+</programlisting>
+
+	  </para>
+	  <para>
+	    Shell-style (or perl-style, if you prefer) comments start
+	    with the character <literal>#</literal> (number sign)
+	    and continue to the end of the
+	    physical line, as in C++ comments.
+	    For example:
+	  </para>
+
+	  <para>
+
+<programlisting># This is the start of a comment.  The next line
+# is a new comment, even though it is logically
+# part of the previous comment.
+</programlisting>
+
+	  </para>
+
+	  <warning>
+	    <para>
+	      You cannot use the semicolon (`;') character
+	      to start a comment such as you would in a zone file. The
+	      semicolon indicates the end of a configuration
+	      statement.
+	    </para>
+	  </warning>
+	</section>
+      </section>
+    </section>
+
+    <section xml:id="Configuration_File_Grammar"><info><title>Configuration File Grammar</title></info>
+
+      <para>
+	A <acronym>BIND</acronym> 9 configuration consists of
+	statements and comments.
+	Statements end with a semicolon. Statements and comments are the
+	only elements that can appear without enclosing braces. Many
+	statements contain a block of sub-statements, which are also
+	terminated with a semicolon.
+      </para>
+
+      <para>
+	The following statements are supported:
+      </para>
+
+      <informaltable colsep="0" rowsep="0">
+	<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="2Level-table">
+	  <colspec colname="1" colnum="1" colsep="0" colwidth="1.336in"/>
+	  <colspec colname="2" colnum="2" colsep="0" colwidth="3.778in"/>
+	  <tbody>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>acl</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  defines a named IP address
+		  matching list, for access control and other uses.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>controls</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  declares control channels to be used
+		  by the <command>rndc</command> utility.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>include</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  includes a file.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>key</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  specifies key information for use in
+		  authentication and authorization using TSIG.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>logging</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  specifies what the server logs, and where
+		  the log messages are sent.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>lwres</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  configures <command>named</command> to
+		  also act as a light-weight resolver daemon (<command>lwresd</command>).
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>masters</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  defines a named masters list for
+		  inclusion in stub and slave zones'
+		  <command>masters</command> or
+		  <command>also-notify</command> lists.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>options</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  controls global server configuration
+		  options and sets defaults for other statements.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>server</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  sets certain configuration options on
+		  a per-server basis.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>statistics-channels</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  declares communication channels to get access to
+		  <command>named</command> statistics.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>trusted-keys</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  defines trusted DNSSEC keys.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>managed-keys</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  lists DNSSEC keys to be kept up to date
+		  using RFC 5011 trust anchor maintenance.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>view</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  defines a view.
+		</para>
+	      </entry>
+	    </row>
+	    <row rowsep="0">
+	      <entry colname="1">
+		<para><command>zone</command></para>
+	      </entry>
+	      <entry colname="2">
+		<para>
+		  defines a zone.
+		</para>
+	      </entry>
+	    </row>
+	  </tbody>
+	</tgroup>
+      </informaltable>
+
+      <para>
+	The <command>logging</command> and
+	<command>options</command> statements may only occur once
+	per
+	configuration.
+      </para>
+
+      <section xml:id="acl_grammar"><info><title><command>acl</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="acl.grammar.xml"/>
+      </section>
+      <section xml:id="acl"><info><title><command>acl</command> Statement Definition and
+	  Usage</title></info>
+
+	<para>
+	  The <command>acl</command> 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).
+	</para>
+
+	<para>
+	  The following ACLs are built-in:
+	</para>
+
+	<informaltable colsep="0" rowsep="0">
+	  <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+	    <colspec colname="1" colnum="1" colsep="0" colwidth="1.130in"/>
+	    <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
+	    <tbody>
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para><command>any</command></para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Matches all hosts.
+		  </para>
+		</entry>
+	      </row>
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para><command>none</command></para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Matches no hosts.
+		  </para>
+		</entry>
+	      </row>
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para><command>localhost</command></para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Matches the IPv4 and IPv6 addresses of all network
+		    interfaces on the system.  When addresses are
+		    added or removed, the <command>localhost</command>
+		    ACL element is updated to reflect the changes.
+		  </para>
+		</entry>
+	      </row>
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para><command>localnets</command></para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Matches any host on an IPv4 or IPv6 network
+		    for which the system has an interface.
+		    When addresses are added or removed,
+		    the <command>localnets</command>
+		    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, <command>localnets</command>
+		    only matches the local
+		    IPv6 addresses, just like <command>localhost</command>.
+		  </para>
+		</entry>
+	      </row>
+	    </tbody>
+	  </tgroup>
+	</informaltable>
+      </section>
+      <section xml:id="controls_grammar"><info><title><command>controls</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="controls.grammar.xml"/>
+      </section>
+
+      <section xml:id="controls_statement_definition_and_usage"><info><title><command>controls</command> Statement Definition and
+	  Usage</title></info>
+
+	<para>
+	  The <command>controls</command> statement declares control
+	  channels to be used by system administrators to control the
+	  operation of the name server. These control channels are
+	  used by the <command>rndc</command> utility to send
+	  commands to and retrieve non-DNS results from a name server.
+	</para>
+
+	<para>
+	  An <command>inet</command> control channel is a TCP socket
+	  listening at the specified <command>ip_port</command> on the
+	  specified <command>ip_addr</command>, which can be an IPv4 or IPv6
+	  address.  An <command>ip_addr</command> of <literal>*</literal> (asterisk) is
+	  interpreted as the IPv4 wildcard address; connections will be
+	  accepted on any of the system's IPv4 addresses.
+	  To listen on the IPv6 wildcard address,
+	  use an <command>ip_addr</command> of <literal>::</literal>.
+	  If you will only use <command>rndc</command> on the local host,
+	  using the loopback address (<literal>127.0.0.1</literal>
+	  or <literal>::1</literal>) is recommended for maximum security.
+	</para>
+
+	<para>
+	  If no port is specified, port 953 is used. The asterisk
+	  "<literal>*</literal>" cannot be used for <command>ip_port</command>.
+	</para>
+
+	<para>
+	  The ability to issue commands over the control channel is
+	  restricted by the <command>allow</command> and
+	  <command>keys</command> clauses.
+	  Connections to the control channel are permitted based on the
+	  <command>address_match_list</command>.  This is for simple
+	  IP address based filtering only; any <command>key_id</command>
+	  elements of the <command>address_match_list</command>
+	  are ignored.
+	</para>
+
+	<para>
+	  A <command>unix</command> control channel is a UNIX domain
+	  socket listening at the specified path in the file system.
+	  Access to the socket is specified by the <command>perm</command>,
+	  <command>owner</command> and <command>group</command> clauses.
+	  Note on some platforms (SunOS and Solaris) the permissions
+	  (<command>perm</command>) are applied to the parent directory
+	  as the permissions on the socket itself are ignored.
+	</para>
+
+	<para>
+	  The primary authorization mechanism of the command
+	  channel is the <command>key_list</command>, which
+	  contains a list of <command>key_id</command>s.
+	  Each <command>key_id</command> in the <command>key_list</command>
+	  is authorized to execute commands over the control channel.
+	  See <xref linkend="rndc"/> in <xref linkend="admin_tools"/>)
+	  for information about configuring keys in <command>rndc</command>.
+	</para>
+
+	<para>
+	  If the <command>read-only</command> clause is enabled, the
+	  control channel is limited to the following set of read-only
+	  commands: <command>nta -dump</command>,
+	  <command>null</command>, <command>status</command>,
+	  <command>showzone</command>, <command>testgen</command>, and
+	  <command>zonestatus</command>. By default,
+	  <command>read-only</command> is not enabled and the control
+	  channel allows read-write access.
+	</para>
+
+	<para>
+	  If no <command>controls</command> statement is present,
+	  <command>named</command> will set up a default
+	  control channel listening on the loopback address 127.0.0.1
+	  and its IPv6 counterpart ::1.
+	  In this case, and also when the <command>controls</command> statement
+	  is present but does not have a <command>keys</command> clause,
+	  <command>named</command> will attempt to load the command channel key
+	  from the file <filename>rndc.key</filename> in
+	  <filename>/etc</filename> (or whatever <varname>sysconfdir</varname>
+	  was specified as when <acronym>BIND</acronym> was built).
+	  To create a <filename>rndc.key</filename> file, run
+	  <userinput>rndc-confgen -a</userinput>.
+	</para>
+
+	<para>
+	  The <filename>rndc.key</filename> feature was created to
+	  ease the transition of systems from <acronym>BIND</acronym> 8,
+	  which did not have digital signatures on its command channel
+	  messages and thus did not have a <command>keys</command> clause.
+
+	  It makes it possible to use an existing <acronym>BIND</acronym> 8
+	  configuration file in <acronym>BIND</acronym> 9 unchanged,
+	  and still have <command>rndc</command> work the same way
+	  <command>ndc</command> worked in BIND 8, simply by executing the
+	  command <userinput>rndc-confgen -a</userinput> after BIND 9 is
+	  installed.
+	</para>
+
+	<para>
+	  Since the <filename>rndc.key</filename> feature
+	  is only intended to allow the backward-compatible usage of
+	  <acronym>BIND</acronym> 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
+	  <filename>rndc.conf</filename> with your own key if you
+	  wish to change
+	  those things.  The <filename>rndc.key</filename> file
+	  also has its
+	  permissions set such that only the owner of the file (the user that
+	  <command>named</command> is running as) can access it.
+	  If you
+	  desire greater flexibility in allowing other users to access
+	  <command>rndc</command> commands, then you need to create
+	  a
+	  <filename>rndc.conf</filename> file and make it group
+	  readable by a group
+	  that contains the users who should have access.
+	</para>
+
+	<para>
+	  To disable the command channel, use an empty
+	  <command>controls</command> statement:
+	  <command>controls { };</command>.
+	</para>
+
+      </section>
+      <section xml:id="include_grammar"><info><title><command>include</command> Statement Grammar</title></info>
+
+	<programlisting><command>include</command> <replaceable>filename</replaceable><command>;</command></programlisting>
+      </section>
+      <section xml:id="include_statement"><info><title><command>include</command> Statement Definition and Usage</title></info>
+
+	<para>
+	  The <command>include</command> statement inserts the
+	  specified file at the point where the <command>include</command>
+	  statement is encountered. The <command>include</command>
+		statement facilitates the administration of configuration
+	  files
+	  by permitting the reading or writing of some things but not
+	  others. For example, the statement could include private keys
+	  that are readable only by the name server.
+	</para>
+
+      </section>
+      <section xml:id="key_grammar"><info><title><command>key</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="key.grammar.xml"/>
+      </section>
+
+      <section xml:id="key_statement"><info><title><command>key</command> Statement Definition and Usage</title></info>
+
+	<para>
+	  The <command>key</command> statement defines a shared
+	  secret key for use with TSIG (see <xref linkend="tsig"/>)
+	  or the command channel
+	  (see <xref linkend="controls_statement_definition_and_usage"/>).
+	</para>
+
+	<para>
+	  The <command>key</command> statement can occur at the
+	  top level
+	  of the configuration file or inside a <command>view</command>
+	  statement.  Keys defined in top-level <command>key</command>
+	  statements can be used in all views.  Keys intended for use in
+	  a <command>controls</command> statement
+	  (see <xref linkend="controls_statement_definition_and_usage"/>)
+	  must be defined at the top level.
+	</para>
+
+	<para>
+	  The <replaceable>key_id</replaceable>, also known as the
+	  key name, is a domain name uniquely identifying the key. It can
+	  be used in a <command>server</command>
+	  statement to cause requests sent to that
+	  server to be signed with this key, or in address match lists to
+	  verify that incoming requests have been signed with a key
+	  matching this name, algorithm, and secret.
+	</para>
+
+	<para>
+	  The <replaceable>algorithm_id</replaceable> is a string
+	  that specifies a security/authentication algorithm.  The
+	  <command>named</command> server supports <literal>hmac-md5</literal>,
+	  <literal>hmac-sha1</literal>, <literal>hmac-sha224</literal>,
+	  <literal>hmac-sha256</literal>, <literal>hmac-sha384</literal>
+	  and <literal>hmac-sha512</literal> TSIG authentication.
+	  Truncated hashes are supported by appending the minimum
+	  number of required bits preceded by a dash, e.g.
+	  <literal>hmac-sha1-80</literal>.  The
+	  <replaceable>secret_string</replaceable> is the secret
+	  to be used by the algorithm, and is treated as a Base64
+	  encoded string.
+	</para>
+
+      </section>
+      <section xml:id="logging_grammar"><info><title><command>logging</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="logging.grammar.xml"/>
+      </section>
+
+      <section xml:id="logging_statement"><info><title><command>logging</command> Statement Definition and Usage</title></info>
+
+	<para>
+	  The <command>logging</command> statement configures a
+	  wide
+	  variety of logging options for the name server. Its <command>channel</command> phrase
+	  associates output methods, format options and severity levels with
+	  a name that can then be used with the <command>category</command> phrase
+	  to select how various classes of messages are logged.
+	</para>
+	<para>
+	  Only one <command>logging</command> statement is used to
+	  define
+	  as many channels and categories as are wanted. If there is no <command>logging</command> statement,
+	  the logging configuration will be:
+	</para>
+
+<programlisting>logging {
+     category default { default_syslog; default_debug; };
+     category unmatched { null; };
+};
+</programlisting>
+
+	<para>
+	  If <command>named</command> is started with the
+	  <option>-L</option> option, it logs to the specified file
+	  at startup, instead of using syslog. In this case the logging
+	  configuration will be:
+	</para>
+
+<programlisting>logging {
+     category default { default_logfile; default_debug; };
+     category unmatched { null; };
+};
+</programlisting>
+
+	<para>
+	  In <acronym>BIND</acronym> 9, the logging configuration
+	  is only established when
+	  the entire configuration file has been parsed.  In <acronym>BIND</acronym> 8, it was
+	  established as soon as the <command>logging</command>
+	  statement
+	  was parsed. When the server is starting up, all logging messages
+	  regarding syntax errors in the configuration file go to the default
+	  channels, or to standard error if the <option>-g</option> option
+	  was specified.
+	</para>
+
+	<section xml:id="channel"><info><title>The <command>channel</command> Phrase</title></info>
+
+	  <para>
+	    All log output goes to one or more <emphasis>channels</emphasis>;
+	    you can make as many of them as you want.
+	  </para>
+
+	  <para>
+	    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
+	    <command>info</command>), and whether to include a
+	    <command>named</command>-generated time stamp, the
+	    category name
+	    and/or severity level (the default is not to include any).
+	  </para>
+
+	  <para>
+	    The <command>null</command> destination clause
+	    causes all messages sent to the channel to be discarded;
+	    in that case, other options for the channel are meaningless.
+	  </para>
+
+	  <para>
+	    The <command>file</command> destination clause directs
+	    the channel
+	    to a disk file.  It can include limitations
+	    both on how large the file is allowed to become, and how many
+	    versions
+	    of the file will be saved each time the file is opened.
+	  </para>
+
+	  <para>
+	    If you use the <command>versions</command> log file
+	    option, then
+	    <command>named</command> will retain that many backup
+	    versions of the file by
+	    renaming them when opening.  For example, if you choose to keep
+	    three old versions
+	    of the file <filename>lamers.log</filename>, then just
+	    before it is opened
+	    <filename>lamers.log.1</filename> is renamed to
+	    <filename>lamers.log.2</filename>, <filename>lamers.log.0</filename> is renamed
+	    to <filename>lamers.log.1</filename>, and <filename>lamers.log</filename> is
+	    renamed to <filename>lamers.log.0</filename>.
+	    You can say <command>versions unlimited</command> to
+	    not limit
+	    the number of versions.
+	    If a <command>size</command> option is associated with
+	    the log file,
+	    then renaming is only done when the file being opened exceeds the
+	    indicated size.  No backup versions are kept by default; any
+	    existing
+	    log file is simply appended.
+	  </para>
+
+	  <para>
+	    The <command>size</command> option for files is used
+	    to limit log
+	    growth. If the file ever exceeds the size, then <command>named</command> will
+	    stop writing to the file unless it has a <command>versions</command> 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
+	    <command>versions</command> option, no more data will
+	    be written to the log
+	    until some out-of-band mechanism removes or truncates the log to
+	    less than the
+	    maximum size.  The default behavior is not to limit the size of
+	    the
+	    file.
+	  </para>
+
+	  <para>
+	    Example usage of the <command>size</command> and
+	    <command>versions</command> options:
+	  </para>
+
+<programlisting>channel an_example_channel {
+    file "example.log" versions 3 size 20m;
+    print-time yes;
+    print-category yes;
+};
+</programlisting>
+
+	  <para>
+	    The <command>syslog</command> destination clause
+	    directs the
+	    channel to the system log.  Its argument is a
+	    syslog facility as described in the <command>syslog</command> man
+	    page. Known facilities are <command>kern</command>, <command>user</command>,
+	    <command>mail</command>, <command>daemon</command>, <command>auth</command>,
+	    <command>syslog</command>, <command>lpr</command>, <command>news</command>,
+	    <command>uucp</command>, <command>cron</command>, <command>authpriv</command>,
+	    <command>ftp</command>, <command>local0</command>, <command>local1</command>,
+	    <command>local2</command>, <command>local3</command>, <command>local4</command>,
+	    <command>local5</command>, <command>local6</command> and
+	    <command>local7</command>, however not all facilities
+	    are supported on
+	    all operating systems.
+	    How <command>syslog</command> will handle messages
+	    sent to
+	    this facility is described in the <command>syslog.conf</command> man
+	    page. If you have a system which uses a very old version of <command>syslog</command> that
+	    only uses two arguments to the <command>openlog()</command> function,
+	    then this clause is silently ignored.
+	  </para>
+	  <para>
+	    On Windows machines syslog messages are directed to the EventViewer.
+	  </para>
+	  <para>
+	    The <command>severity</command> clause works like <command>syslog</command>'s
+	    "priorities", except that they can also be used if you are writing
+	    straight to a file rather than using <command>syslog</command>.
+	    Messages which are not at least of the severity level given will
+	    not be selected for the channel; messages of higher severity
+	    levels
+	    will be accepted.
+	  </para>
+	  <para>
+	    If you are using <command>syslog</command>, then the <command>syslog.conf</command> priorities
+	    will also determine what eventually passes through. For example,
+	    defining a channel facility and severity as <command>daemon</command> and <command>debug</command> but
+	    only logging <command>daemon.warning</command> via <command>syslog.conf</command> will
+	    cause messages of severity <command>info</command> and
+	    <command>notice</command> to
+	    be dropped. If the situation were reversed, with <command>named</command> writing
+	    messages of only <command>warning</command> or higher,
+	    then <command>syslogd</command> would
+	    print all messages it received from the channel.
+	  </para>
+
+	  <para>
+	    The <command>stderr</command> destination clause
+	    directs the
+	    channel to the server's standard error stream.  This is intended
+	    for
+	    use when the server is running as a foreground process, for
+	    example
+	    when debugging a configuration.
+	  </para>
+
+	  <para>
+	    The server can supply extensive debugging information when
+	    it is in debugging mode. If the server's global debug level is
+	    greater
+	    than zero, then debugging mode will be active. The global debug
+	    level is set either by starting the <command>named</command> server
+	    with the <option>-d</option> flag followed by a positive integer,
+	    or by running <command>rndc trace</command>.
+	    The global debug level
+	    can be set to zero, and debugging mode turned off, by running <command>rndc
+notrace</command>. All debugging messages in the server have a debug
+	    level, and higher debug levels give more detailed output. Channels
+	    that specify a specific debug severity, for example:
+	  </para>
+
+<programlisting>channel specific_debug_level {
+    file "foo";
+    severity debug 3;
+};
+</programlisting>
+
+	  <para>
+	    will get debugging output of level 3 or less any time the
+	    server is in debugging mode, regardless of the global debugging
+	    level. Channels with <command>dynamic</command>
+	    severity use the
+	    server's global debug level to determine what messages to print.
+	  </para>
+	  <para>
+	    If <command>print-time</command> has been turned on,
+	    then
+	    the date and time will be logged. <command>print-time</command> may
+	    be specified for a <command>syslog</command> channel,
+	    but is usually
+	    pointless since <command>syslog</command> also logs
+	    the date and
+	    time. If <command>print-category</command> is
+	    requested, then the
+	    category of the message will be logged as well. Finally, if <command>print-severity</command> is
+	    on, then the severity level of the message will be logged. The <command>print-</command> options may
+	    be used in any combination, and will always be printed in the
+	    following
+	    order: time, category, severity. Here is an example where all
+	    three <command>print-</command> options
+	    are on:
+	  </para>
+
+	  <para>
+	    <computeroutput>28-Feb-2000 15:05:32.863 general: notice: running</computeroutput>
+	  </para>
+
+	  <para>
+	    If <command>buffered</command> has been turned on the output
+	    to files will not be flushed after each log entry.  By default
+	    all log messages are flushed.
+	  </para>
+
+	  <para>
+	    There are four predefined channels that are used for
+	    <command>named</command>'s default logging as follows.
+	    If <command>named</command> is started with the
+	    <option>-L</option> then a
+	    fifth channel <command>default_logfile</command> is added.
+	    How they are
+	    used is described in <xref linkend="the_category_phrase"/>.
+	  </para>
+
+<programlisting>channel default_syslog {
+    // send to syslog's daemon facility
+    syslog daemon;
+    // only send priority info and higher
+    severity info;
+};
+
+channel default_debug {
+    // write to named.run in the working directory
+    // Note: stderr is used instead of "named.run" if
+    // the server is started with the '-g' option.
+    file "named.run";
+    // log at the server's current debug level
+    severity dynamic;
+};
+
+channel default_stderr {
+    // writes to stderr
+    stderr;
+    // only send priority info and higher
+    severity info;
+};
+
+channel null {
+   // toss anything sent to this channel
+   null;
+};
+
+channel default_logfile {
+    // this channel is only present if named is
+    // started with the -L option, whose argument
+    // provides the file name
+    file "...";
+    // log at the server's current debug level
+    severity dynamic;
+};
+</programlisting>
+
+	  <para>
+	    The <command>default_debug</command> channel has the
+	    special
+	    property that it only produces output when the server's debug
+	    level is
+	    nonzero.  It normally writes to a file called <filename>named.run</filename>
+	    in the server's working directory.
+	  </para>
+
+	  <para>
+	    For security reasons, when the <option>-u</option>
+	    command line option is used, the <filename>named.run</filename> file
+	    is created only after <command>named</command> has
+	    changed to the
+	    new UID, and any debug output generated while <command>named</command> is
+	    starting up and still running as root is discarded.  If you need
+	    to capture this output, you must run the server with the <option>-L</option>
+	    option to specify a default logfile, or the <option>-g</option>
+	    option to log to standard error which you can redirect to a file.
+	  </para>
+
+	  <para>
+	    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.
+	  </para>
+	</section>
+
+	<section xml:id="the_category_phrase"><info><title>The <command>category</command> Phrase</title></info>
+
+	  <para>
+	    There are many categories, so you can send the logs you want
+	    to see wherever you want, without seeing logs you don't want. If
+	    you don't specify a list of channels for a category, then log
+	    messages
+	    in that category will be sent to the <command>default</command> category
+	    instead. If you don't specify a default category, the following
+	    "default default" is used:
+	  </para>
+
+<programlisting>category default { default_syslog; default_debug; };
+</programlisting>
+
+	  <para>
+	    If you start <command>named</command> with the
+	    <option>-L</option> option then the default category is:
+	  </para>
+
+<programlisting>category default { default_logfile; default_debug; };
+</programlisting>
+
+	  <para>
+	    As an example, let's say you want to log security events to
+	    a file, but you also want keep the default logging behavior. You'd
+	    specify the following:
+	  </para>
+
+<programlisting>channel my_security_channel {
+    file "my_security_file";
+    severity info;
+};
+category security {
+    my_security_channel;
+    default_syslog;
+    default_debug;
+};</programlisting>
+
+	  <para>
+	    To discard all messages in a category, specify the <command>null</command> channel:
+	  </para>
+
+<programlisting>category xfer-out { null; };
+category notify { null; };
+</programlisting>
+
+	  <para>
+	    Following are the available categories and brief descriptions
+	    of the types of log information they contain. More
+	    categories may be added in future <acronym>BIND</acronym> releases.
+	  </para>
+	  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="logging-categories.xml"/>
+	</section>
+	<section xml:id="query_errors"><info><title>The <command>query-errors</command> Category</title></info>
+	  <para>
+	    The <command>query-errors</command> category is
+	    specifically intended for debugging purposes: To identify
+	    why and how specific queries result in responses which
+	    indicate an error.
+	    Messages of this category are therefore only logged
+	    with <command>debug</command> levels.
+	  </para>
+
+	  <para>
+	    At the debug levels of 1 or higher, each response with the
+	    rcode of SERVFAIL is logged as follows:
+	  </para>
+	  <para>
+	    <computeroutput>client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880</computeroutput>
+	  </para>
+	  <para>
+	    This means an error resulting in SERVFAIL was
+	    detected at line 3880 of source file
+	    <filename>query.c</filename>.
+	    Log messages of this level will particularly
+	    help identify the cause of SERVFAIL for an
+	    authoritative server.
+	  </para>
+	  <para>
+	    At the debug levels of 2 or higher, detailed context
+	    information of recursive resolutions that resulted in
+	    SERVFAIL is logged.
+	    The log message will look like as follows:
+	  </para>
+	  <para>
+<!-- NOTE: newlines and some spaces added so this would fit on page -->
+	    <programlisting>
+fetch completed at resolver.c:2970 for www.example.com/A
+in 30.000183: timed out/success [domain:example.com,
+referral:2,restart:7,qrysent:8,timeout:5,lame:0,neterr:0,
+badresp:1,adberr:0,findfail:0,valfail:0]
+	    </programlisting>
+	  </para>
+	  <para>
+	    The first part before the colon shows that a recursive
+	    resolution for AAAA records of www.example.com completed
+	    in 30.000183 seconds and the final result that led to the
+	    SERVFAIL was determined at line 2970 of source file
+	    <filename>resolver.c</filename>.
+	  </para>
+	  <para>
+	    The following part shows the detected final result and the
+	    latest result of DNSSEC validation.
+	    The latter is always success when no validation attempt
+	    is made.
+	    In this example, this query resulted in SERVFAIL probably
+	    because all name servers are down or unreachable, leading
+	    to a timeout in 30 seconds.
+	    DNSSEC validation was probably not attempted.
+	  </para>
+	  <para>
+	    The last part enclosed in square brackets shows statistics
+	    information collected for this particular resolution
+	    attempt.
+	    The <varname>domain</varname> field shows the deepest zone
+	    that the resolver reached;
+	    it is the zone where the error was finally detected.
+	    The meaning of the other fields is summarized in the
+	    following table.
+	  </para>
+
+	  <informaltable colsep="0" rowsep="0">
+	    <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+	      <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+	      <colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
+	      <tbody>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>referral</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The number of referrals the resolver received
+		      throughout the resolution process.
+		      In the above example this is 2, which are most
+		      likely com and example.com.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>restart</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The number of cycles that the resolver tried
+		      remote servers at the <varname>domain</varname>
+		      zone.
+		      In each cycle the resolver sends one query
+		      (possibly resending it, depending on the response)
+		      to each known name server of
+		      the <varname>domain</varname> zone.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>qrysent</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The number of queries the resolver sent at the
+		      <varname>domain</varname> zone.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>timeout</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The number of timeouts since the resolver
+		      received the last response.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>lame</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The number of lame servers the resolver detected
+		      at the <varname>domain</varname> 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
+		      servers are cached.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>neterr</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The number of erroneous results that the
+		      resolver encountered in sending queries
+		      at the <varname>domain</varname> zone.
+		      One common case is the remote server is
+		      unreachable and the resolver receives an ICMP
+		      unreachable error message.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>badresp</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The number of unexpected responses (other than
+		      <varname>lame</varname>) to queries sent by the
+		      resolver at the <varname>domain</varname> zone.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>adberr</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Failures in finding remote server addresses
+		      of the <varname>domain</varname> zone in the ADB.
+		      One common case of this is that the remote
+		      server's name does not have any address records.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>findfail</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Failures of resolving remote server addresses.
+		      This is a total number of failures throughout
+		      the resolution process.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><varname>valfail</varname></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Failures of DNSSEC validation.
+		      Validation failures are counted throughout
+		      the resolution process (not limited to
+		      the <varname>domain</varname> zone), but should
+		      only happen in <varname>domain</varname>.
+		    </para>
+		  </entry>
+		</row>
+	      </tbody>
+	    </tgroup>
+	  </informaltable>
+	  <para>
+	    At the debug levels of 3 or higher, the same messages
+	    as those at the debug 1 level are logged for other errors
+	    than SERVFAIL.
+	    Note that negative responses such as NXDOMAIN are not
+	    regarded as errors here.
+	  </para>
+	  <para>
+	    At the debug levels of 4 or higher, the same messages
+	    as those at the debug 2 level are logged for other errors
+	    than SERVFAIL.
+	    Unlike the above case of level 3, messages are logged for
+	    negative responses.
+	    This is because any unexpected results can be difficult to
+	    debug in the recursion case.
+	  </para>
+	</section>
+      </section>
+
+      <section xml:id="lwres_grammar"><info><title><command>lwres</command> Statement Grammar</title></info>
+
+	<para>
+	   This is the grammar of the <command>lwres</command>
+	  statement in the <filename>named.conf</filename> file:
+	</para>
+
+<programlisting><command>lwres {</command>
+  [ <command>listen-on {</command>
+    ( <replaceable>ip_addr</replaceable> [ <command>port</command> <replaceable>ip_port</replaceable> ] [ <command>dscp</command> <replaceable>ip_dscp</replaceable> ] <command>;</command> )
+      ...
+    <command>};</command> ]
+  [ <command>view</command> <replaceable>view_name</replaceable><command>;</command> ]
+  [ <command>search {</command> <replaceable>domain_name</replaceable> <command>;</command> ... <command>};</command> ]
+  [ <command>ndots</command> <replaceable>number</replaceable><command>;</command> ]
+  [ <command>lwres-tasks</command> <replaceable>number</replaceable><command>;</command> ]
+  [ <command>lwres-clients</command> <replaceable>number</replaceable><command>;</command> ]
+<command>};</command>
+</programlisting>
+
+      </section>
+      <section xml:id="lwres_statement"><info><title><command>lwres</command> Statement Definition and Usage</title></info>
+
+	<para>
+	  The <command>lwres</command> statement configures the
+	  name
+	  server to also act as a lightweight resolver server. (See
+	  <xref linkend="lwresd"/>.)  There may be multiple
+	  <command>lwres</command> statements configuring
+	  lightweight resolver servers with different properties.
+	</para>
+
+	<para>
+	  The <command>listen-on</command> statement specifies a
+	  list of
+	  IPv4 addresses (and ports) that this instance of a lightweight
+	  resolver daemon
+	  should accept requests on.  If no port is specified, port 921 is
+	  used.
+	  If this statement is omitted, requests will be accepted on
+	  127.0.0.1,
+	  port 921.
+	</para>
+
+	<para>
+	  The <command>view</command> statement binds this
+	  instance of a
+	  lightweight resolver daemon to a view in the DNS namespace, so that
+	  the
+	  response will be constructed in the same manner as a normal DNS
+	  query
+	  matching this view.  If this statement is omitted, the default view
+	  is
+	  used, and if there is no default view, an error is triggered.
+	</para>
+
+	<para>
+	  The <command>search</command> statement is equivalent to
+	  the
+	  <command>search</command> statement in
+	  <filename>/etc/resolv.conf</filename>.  It provides a
+	  list of domains
+	  which are appended to relative names in queries.
+	</para>
+
+	<para>
+	  The <command>ndots</command> statement is equivalent to
+	  the
+	  <command>ndots</command> statement in
+	  <filename>/etc/resolv.conf</filename>.  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.
+	</para>
+	<para>
+	  The <option>lwres-tasks</option> 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
+	  the system; this can be overridden using the <option>-n</option>
+	  command line option when starting the server.
+	</para>
+	<para>
+	  The <option>lwres-clients</option> 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 <command>named</command>, 256 client objects are
+	  created for each task; if it runs as <command>lwresd</command>,
+	  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.
+	  Note that setting too high a value may overconsume
+	  system resources.
+	</para>
+	<para>
+	  The maximum number of client queries that the lightweight
+	  resolver can handle at any one time equals
+	  <option>lwres-tasks</option> times <option>lwres-clients</option>.
+	</para>
+      </section>
+      <section xml:id="masters_grammar"><info><title><command>masters</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="masters.grammar.xml"/>
+      </section>
+
+      <section xml:id="masters_statement"><info><title><command>masters</command> Statement Definition and
+	  Usage</title></info>
+
+	<para><command>masters</command>
+	  lists allow for a common set of masters to be easily used by
+	  multiple stub and slave zones in their <command>masters</command>
+	  or <command>also-notify</command> lists.
+	</para>
+      </section>
+
+      <section xml:id="options_grammar"><info><title><command>options</command> Statement Grammar</title></info>
+
+	<para>
+	  This is the grammar of the <command>options</command>
+	  statement in the <filename>named.conf</filename> file:
+	</para>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="options.grammar.xml"/>
+      </section>
+
+      <section xml:id="options"><info><title><command>options</command> Statement Definition and
+	  Usage</title></info>
+
+	<para>
+	  The <command>options</command> statement sets up global
+	  options
+	  to be used by <acronym>BIND</acronym>. This statement
+	  may appear only
+	  once in a configuration file. If there is no <command>options</command>
+	  statement, an options block with each option set to its default will
+	  be used.
+	</para>
+
+	<variablelist>
+
+	    <varlistentry>
+	      <term><command>attach-cache</command></term>
+	      <listitem>
+		<para>
+		  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.
+		</para>
+
+		<para>
+		  The <command>attach-cache</command> option
+		  may also be specified in <command>view</command>
+		  statements, in which case it overrides the
+		  global <command>attach-cache</command> option.
+		</para>
+
+		<para>
+		  The <replaceable>cache_name</replaceable> specifies
+		  the cache to be shared.
+		  When the <command>named</command> server configures
+		  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.
+		</para>
+
+		<para>
+		  One common configuration to share a cache would be to
+		  allow all views to share a single cache.
+		  This can be done by specifying
+		  the <command>attach-cache</command> as a global
+		  option with an arbitrary name.
+		</para>
+
+		<para>
+		  Another possible operation is to allow a subset of
+		  all views to share a cache while the others to
+		  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
+		  <command>attach-cache</command> option as a view A (or
+		  B)'s option, referring to the other view name:
+		</para>
+
+<programlisting>
+  view "A" {
+    // this view has its own cache
+    ...
+  };
+  view "B" {
+    // this view refers to A's cache
+    attach-cache "A";
+  };
+  view "C" {
+    // this view has its own cache
+    ...
+  };
+</programlisting>
+
+		<para>
+		  Views that share a cache must have the same policy
+		  on configurable parameters that may affect caching.
+		  The current implementation requires the following
+		  configurable options be consistent among these
+		  views:
+		  <command>check-names</command>,
+		  <command>cleaning-interval</command>,
+		  <command>dnssec-accept-expired</command>,
+		  <command>dnssec-validation</command>,
+		  <command>max-cache-ttl</command>,
+		  <command>max-ncache-ttl</command>,
+		  <command>max-cache-size</command>, and
+		  <command>zero-no-soa-ttl</command>.
+		</para>
+
+		<para>
+		  Note that there may be other parameters that may
+		  cause confusion if they are inconsistent for
+		  different views that share a single cache.
+		  For example, if these views define different sets of
+		  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
+		  configuration differences in different views do
+		  not cause disruption with a shared cache.
+		</para>
+	      </listitem>
+
+	    </varlistentry>
+
+	  <varlistentry>
+	    <term><command>directory</command></term>
+	    <listitem>
+	      <para>
+		The working directory of the server.
+		Any non-absolute pathnames in the configuration file will
+		be taken as relative to this directory. The default
+		location for most server output files
+		(e.g. <filename>named.run</filename>) is this directory.
+		If a directory is not specified, the working directory
+		defaults to `<filename>.</filename>', the directory from
+		which the server was started. The directory specified
+		should be an absolute path. It is
+		<emphasis>strongly recommended</emphasis>
+		that the directory be writable by the effective user
+		ID of the <command>named</command> process.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dnstap</command></term>
+	    <listitem>
+	      <para>
+		<command>dnstap</command> is a fast, flexible method
+		for capturing and logging DNS traffic. Developed by
+		Robert Edmonds at Farsight Security, Inc., and supported
+		by multiple DNS implementations, <command>dnstap</command>
+		uses
+		<command>libfstrm</command> (a lightweight high-speed
+		framing library, see
+		<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://github.com/farsightsec/fstrm">https://github.com/farsightsec/fstrm</link>) to send
+		event payloads which are encoded using Protocol Buffers
+		(<command>libprotobuf-c</command>, a mechanism for
+		serializing structured data developed
+		by Google, Inc.; see
+		<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://developers.google.com/protocol-buffers/">https://developers.google.com/protocol-buffers</link>).
+	      </para>
+	      <para>
+		To enable <command>dnstap</command> at compile time,
+		the <command>fstrm</command> and <command>protobuf-c</command>
+		libraries must be available, and BIND must be configured with
+		<option>--enable-dnstap</option>.
+	      </para>
+	      <para>
+		The <command>dnstap</command> option is a bracketed list
+		of message types to be logged. These may be set differently
+		for each view. Supported types are <literal>client</literal>,
+		<literal>auth</literal>, <literal>resolver</literal>, and
+		<literal>forwarder</literal>.  Specifying type
+		<literal>all</literal> will cause all <command>dnstap</command>
+		messages to be logged, regardless of type.
+	      </para>
+	      <para>
+		Each type may take an additional argument to indicate whether
+		to log <literal>query</literal> messages or
+		<literal>response</literal> messages; if not specified,
+		both queries and responses are logged.
+	      </para>
+	      <para>
+		Example: To log all authoritative queries and responses,
+		recursive client responses, and upstream queries sent by
+		the resolver, use:
+<programlisting>dnstap {
+  auth;
+  client response;
+  resolver query;
+};
+</programlisting>
+	      </para>
+	      <para>
+		Logged <command>dnstap</command> messages can be parsed
+		using the <command>dnstap-read</command> utility (see
+		<xref linkend="man.dnstap-read"/> for details).
+	      </para>
+	      <para>
+		For more information on <command>dnstap</command>, see
+		<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://dnstap.info">http://dnstap.info</link>.
+	      </para>
+	      <para>
+		The fstrm library has a number of tunables that are exposed
+		in <filename>named.conf</filename>, and can be modified
+		if necessary to improve performance or prevent loss of data.
+		These are:
+	      </para>
+	      <itemizedlist>
+		<listitem>
+		  <simpara>
+		    <command>fstrm-set-buffer-hint</command>: The
+		    threshold number of bytes to accumulate in the output
+		    buffer before forcing a buffer flush. The minimum is
+		    1024, the maximum is 65536, and the default is 8192.
+		  </simpara>
+		</listitem>
+		<listitem>
+		  <simpara>
+		    <command>fstrm-set-flush-timeout</command>: The number
+		    of seconds to allow unflushed data to remain in the
+		    output buffer. The minimum is 1 second, the maximum is
+		    600 seconds (10 minutes), and the default is 1 second.
+		  </simpara>
+		</listitem>
+		<listitem>
+		  <simpara>
+		    <command>fstrm-set-output-notify-threshold</command>:
+		    The number of outstanding queue entries to allow on
+		    an input queue before waking the I/O thread.
+		    The minimum is 1 and the default is 32.
+		  </simpara>
+		</listitem>
+		<listitem>
+		  <simpara>
+		    <command>fstrm-set-output-queue-model</command>:
+		    Controls the queuing semantics to use for queue
+		    objects. The default is <literal>mpsc</literal>
+		    (multiple producer, single consumer); the other
+		    option is <literal>spsc</literal> (single producer,
+		    single consumer).
+		  </simpara>
+		</listitem>
+		<listitem>
+		  <simpara>
+		    <command>fstrm-set-input-queue-size</command>: The
+		    number of queue entries to allocate for each
+		    input queue. This value must be a power of 2.
+		    The minimum is 2, the maximum is 16384, and
+		    the default is 512.
+		  </simpara>
+		</listitem>
+		<listitem>
+		  <simpara>
+		    <command>fstrm-set-output-queue-size</command>:
+		    The number of queue entries to allocate for each
+		    output queue. The minimum is 2, the maximum is
+		    system-dependent and based on <option>IOV_MAX</option>,
+		    and the default is 64.
+		  </simpara>
+		</listitem>
+		<listitem>
+		  <simpara>
+		    <command>fstrm-set-reopen-interval</command>:
+		    The number of seconds to wait between attempts to
+		    reopen a closed output stream. The minimum is 1 second,
+		    the maximum is 600 seconds (10 minutes), and the default
+		    is 5 seconds.
+		  </simpara>
+		</listitem>
+	      </itemizedlist>
+	      <para>
+		Note that all of the above minimum, maximum, and default
+		values are set by the <command>libfstrm</command> library,
+		and may be subject to change in future versions of the
+		library. See the <command>libfstrm</command> documentation
+		for more information.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dnstap-output</command></term>
+	    <listitem>
+	      <para>
+		Configures the path to which the <command>dnstap</command>
+		frame stream will be sent if <command>dnstap</command>
+		is enabled at compile time and active.
+	      </para>
+	      <para>
+		The first argument is either <literal>file</literal> or
+		<literal>unix</literal>, indicating whether the destination
+		is a file or a UNIX domain socket.  The second argument
+		is the path of the file or socket.  (Note: when using a
+		socket, <command>dnstap</command> messages will
+		only be sent if another process such as
+		<command>fstrm_capture</command>
+		(provided with <command>libfstrm</command>) is listening on
+		the socket.)
+	      </para>
+	      <para>
+		<command>dnstap-output</command> can only be set globally
+		in <command>options</command>. Currently, it can only be
+		set once while <command>named</command> is running;
+		once set, it cannot be changed by
+		<command>rndc reload</command> or
+		<command>rndc reconfig</command>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dnstap-identity</command></term>
+	    <listitem>
+	      <para>
+		Specifies an <command>identity</command> string to send in
+		<command>dnstap</command> messages. If set to
+		<literal>hostname</literal>, which is the default, the
+		server's hostname will be sent. If set to
+		<literal>none</literal>, no identity string will be sent.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dnstap-version</command></term>
+	    <listitem>
+	      <para>
+		Specifies a <command>version</command> string to send in
+		<command>dnstap</command> messages. The default is the
+		version number of the BIND release. If set to
+		<literal>none</literal>, no version string will be sent.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>geoip-directory</command></term>
+	    <listitem>
+	      <para>
+		Specifies the directory containing GeoIP
+		<filename>.dat</filename> database files for GeoIP
+		initialization.  By default, this option is unset
+		and the GeoIP support will use libGeoIP's
+		built-in directory.
+		(For details, see <xref linkend="acl"/> about the
+		<command>geoip</command> ACL.)
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>key-directory</command></term>
+	    <listitem>
+	      <para>
+		When performing dynamic update of secure zones, the
+		directory where the public and private DNSSEC key files
+		should be found, if different than the current working
+		directory.  (Note that this option has no effect on the
+		paths for files containing non-DNSSEC keys such as
+		<filename>bind.keys</filename>,
+		<filename>rndc.key</filename> or
+		<filename>session.key</filename>.)
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>lmdb-mapsize</command></term>
+	    <listitem>
+	      <para>
+		When <command>named</command> is built with liblmdb,
+		this option sets a maximum size for the memory map of
+		the new-zone database (NZD) in LMDB database format.
+		This database is used to store configuration information
+		for zones added using <command>rndc addzone</command>.
+		Note that this is not the NZD database file size, but
+		the largest size that the database may grow to.
+	      </para>
+	      <para>
+		Because the database file is memory mapped, its size is
+		limited by the address space of the named process.  The
+		default of 32 megabytes was chosen to be usable with
+		32-bit <command>named</command> builds.  The largest
+		permitted value is 1 terabyte. Given typical zone
+		configurations without elaborate ACLs, a 32 MB NZD file
+		ought to be able to hold configurations of about 100,000
+		zones.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>managed-keys-directory</command></term>
+	    <listitem>
+	      <para>
+		Specifies the directory in which to store the files that
+		track managed DNSSEC keys.  By default, this is the working
+		directory.  The directory <emphasis>must</emphasis>
+		be writable by the effective user ID of the
+		<command>named</command> process.
+	      </para>
+	      <para>
+		If <command>named</command> is not configured to use views,
+		then managed keys for the server will be tracked in a single
+		file called <filename>managed-keys.bind</filename>.
+		Otherwise, managed keys will be tracked in separate files,
+		one file per view; each file name will be 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
+		<filename>.mkeys</filename>.
+	      </para>
+	      <para>
+		(Note: in previous releases, file names for views
+		always used the SHA256 hash of the view name. To ensure
+		compatibility after upgrade, if a file using the old
+		name format is found to exist, it will be used instead
+		of the new format.)
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>named-xfer</command></term>
+	    <listitem>
+	      <para>
+		<emphasis>This option is obsolete.</emphasis> It
+		was used in <acronym>BIND</acronym> 8 to specify
+		the pathname to the <command>named-xfer</command>
+		program.  In <acronym>BIND</acronym> 9, no separate
+		<command>named-xfer</command> program is needed;
+		its functionality is built into the name server.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>tkey-gssapi-keytab</command></term>
+	    <listitem>
+	      <para>
+		The KRB5 keytab file to use for GSS-TSIG updates. If
+		this option is set and tkey-gssapi-credential is not
+		set, then updates will be allowed with any key
+		matching a principal in the specified keytab.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>tkey-gssapi-credential</command></term>
+	    <listitem>
+	      <para>
+		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
+		server can acquire through the default system key
+		file, normally <filename>/etc/krb5.keytab</filename>.
+		The location keytab file can be overridden using the
+		tkey-gssapi-keytab option. Normally this principal is
+		of the form "<userinput>DNS/</userinput><varname>server.domain</varname>".
+		To use GSS-TSIG, <command>tkey-domain</command> must
+		also be set if a specific keytab is not set with
+		tkey-gssapi-keytab.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>tkey-domain</command></term>
+	    <listitem>
+	      <para>
+		The domain appended to the names of all shared keys
+		generated with <command>TKEY</command>.  When a
+		client requests a <command>TKEY</command> exchange,
+		it may or may not specify the desired name for the
+		key. If present, the name of the shared key will
+		be <varname>client specified part</varname> +
+		<varname>tkey-domain</varname>.  Otherwise, the
+		name of the shared key will be <varname>random hex
+		digits</varname> + <varname>tkey-domain</varname>.
+		In most cases, the <command>domainname</command>
+		should be the server's domain name, or an otherwise
+		non-existent subdomain like
+		"_tkey.<varname>domainname</varname>".  If you are
+		using GSS-TSIG, this variable must be defined, unless
+		you specify a specific keytab using tkey-gssapi-keytab.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>tkey-dhkey</command></term>
+	    <listitem>
+	      <para>
+		The Diffie-Hellman key used by the server
+		to generate shared keys with clients using the Diffie-Hellman
+		mode
+		of <command>TKEY</command>. The server must be
+		able to load the
+		public and private keys from files in the working directory.
+		In
+		most cases, the <varname>key_name</varname> should be the server's host name.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>cache-file</command></term>
+	    <listitem>
+	      <para>
+		This is for testing only.  Do not use.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dump-file</command></term>
+	    <listitem>
+	      <para>
+		The pathname of the file the server dumps
+		the database to when instructed to do so with
+		<command>rndc dumpdb</command>.
+		If not specified, the default is <filename>named_dump.db</filename>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>memstatistics-file</command></term>
+	    <listitem>
+	      <para>
+		The pathname of the file the server writes memory
+		usage statistics to on exit. If not specified,
+		the default is <filename>named.memstats</filename>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>lock-file</command></term>
+	    <listitem>
+	      <para>
+		The pathname of a file on which <command>named</command> 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
+		server is already running.  If not specified, the default is
+		<filename>/var/run/named/named.lock</filename>.
+	      </para>
+	      <para>
+		Specifying <command>lock-file none</command> disables the
+		use of a lock file.  <command>lock-file</command> is
+		ignored if <command>named</command> was run using the <option>-X</option>
+		option, which overrides it.  Changes to
+		<command>lock-file</command> are ignored if
+		<command>named</command> is being reloaded or
+		reconfigured; it is only effective when the server is
+		first started up.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>pid-file</command></term>
+	    <listitem>
+	      <para>
+		The pathname of the file the server writes its process ID
+		in. If not specified, the default is
+		<filename>/var/run/named/named.pid</filename>.
+		The PID file is used by programs that want to send signals to
+		the running
+		name server. Specifying <command>pid-file none</command> disables the
+		use of a PID file — no file will be written and any
+		existing one will be removed.  Note that <command>none</command>
+		is a keyword, not a filename, and therefore is not enclosed
+		in
+		double quotes.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>recursing-file</command></term>
+	    <listitem>
+	      <para>
+		The pathname of the file the server dumps
+		the queries that are currently recursing when instructed
+		to do so with <command>rndc recursing</command>.
+		If not specified, the default is <filename>named.recursing</filename>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>statistics-file</command></term>
+	    <listitem>
+	      <para>
+		The pathname of the file the server appends statistics
+		to when instructed to do so using <command>rndc stats</command>.
+		If not specified, the default is <filename>named.stats</filename> in the
+		server's current directory.  The format of the file is
+		described
+		in <xref linkend="statsfile"/>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>bindkeys-file</command></term>
+	    <listitem>
+	      <para>
+		The pathname of a file to override the built-in trusted
+		keys provided by <command>named</command>.
+		See the discussion of <command>dnssec-validation</command>
+		for details.  If not specified, the default is
+		<filename>/etc/bind.keys</filename>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>secroots-file</command></term>
+	    <listitem>
+	      <para>
+		The pathname of the file the server dumps
+		security roots to when instructed to do so with
+		<command>rndc secroots</command>.
+		If not specified, the default is
+		<filename>named.secroots</filename>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>session-keyfile</command></term>
+	    <listitem>
+	      <para>
+		The pathname of the file into which to write a TSIG
+		session key generated by <command>named</command> for use by
+		<command>nsupdate -l</command>.  If not specified, the
+		default is <filename>/var/run/named/session.key</filename>.
+		(See <xref linkend="dynamic_update_policies"/>, and in
+		particular the discussion of the
+		<command>update-policy</command> statement's
+		<userinput>local</userinput> option for more
+		information about this feature.)
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>session-keyname</command></term>
+	    <listitem>
+	      <para>
+		The key name to use for the TSIG session key.
+		If not specified, the default is "local-ddns".
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>session-keyalg</command></term>
+	    <listitem>
+	      <para>
+		The algorithm to use for the TSIG session key.
+		Valid values are hmac-sha1, hmac-sha224, hmac-sha256,
+		hmac-sha384, hmac-sha512 and hmac-md5.  If not
+		specified, the default is hmac-sha256.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>port</command></term>
+	    <listitem>
+	      <para>
+		The UDP/TCP port number the server uses for
+		receiving and sending DNS protocol traffic.
+		The default is 53.  This option is mainly intended for server
+		testing;
+		a server using a port other than 53 will not be able to
+		communicate with
+		the global DNS.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dscp</command></term>
+	    <listitem>
+	      <para>
+		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.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>random-device</command></term>
+	    <listitem>
+	      <para>
+		The source of entropy to be used by the server.  Entropy is
+		primarily needed
+		for DNSSEC operations, such as TKEY transactions and dynamic
+		update of signed
+		zones.  This options specifies the device (or file) from which
+		to read
+		entropy.  If this is a file, operations requiring entropy will
+		fail when the
+		file has been exhausted.  If not specified, the default value
+		is
+		<filename>/dev/random</filename>
+		(or equivalent) when present, and none otherwise.  The
+		<command>random-device</command> option takes
+		effect during
+		the initial configuration load at server startup time and
+		is ignored on subsequent reloads.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>preferred-glue</command></term>
+	    <listitem>
+	      <para>
+		If specified, the listed type (A or AAAA) will be emitted
+		before other glue
+		in the additional section of a query response.
+		The default is to prefer A records when responding
+		to queries that arrived via IPv4 and AAAA when
+		responding to queries that arrived via IPv6.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry xml:id="root_delegation_only">
+	    <term><command>root-delegation-only</command></term>
+	    <listitem>
+	      <para>
+		Turn on enforcement of delegation-only in TLDs
+		(top level domains) and root zones with an optional
+		exclude list.
+	      </para>
+	      <para>
+		DS queries are expected to be made to and be answered by
+		delegation only zones.  Such queries and responses are
+		treated as an exception to delegation-only processing
+		and are not converted to NXDOMAIN responses provided
+		a CNAME is not discovered at the query name.
+	      </para>
+	      <para>
+		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
+		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
+		false negatives when a child zone is being served.
+	      </para>
+	      <para>
+		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.
+	      </para>
+	      <para>
+		Note some TLDs are not delegation only (e.g. "DE", "LV",
+		"US" and "MUSEUM").  This list is not exhaustive.
+	      </para>
+
+<programlisting>
+options {
+	root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
+};
+</programlisting>
+
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>disable-algorithms</command></term>
+	    <listitem>
+	      <para>
+		Disable the specified DNSSEC algorithms at and below the
+		specified name.
+		Multiple <command>disable-algorithms</command>
+		statements are allowed.
+		Only the best match <command>disable-algorithms</command>
+		clause will be used to determine which algorithms are used.
+	      </para>
+	      <para>
+		If all supported algorithms are disabled, the zones covered
+		by the <command>disable-algorithms</command> will be treated
+		as insecure.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>disable-ds-digests</command></term>
+	    <listitem>
+	      <para>
+		Disable the specified DS/DLV digest types at and below the
+		specified name.
+		Multiple <command>disable-ds-digests</command>
+		statements are allowed.
+		Only the best match <command>disable-ds-digests</command>
+		clause will be used to determine which digest types are used.
+	      </para>
+	      <para>
+		If all supported digest types are disabled, the zones covered
+		by the <command>disable-ds-digests</command> will be treated
+		as insecure.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dnssec-lookaside</command></term>
+	    <listitem>
+	      <para>
+		When set, <command>dnssec-lookaside</command> provides the
+		validator with an alternate method to validate DNSKEY
+		records at the top of a zone.  When a DNSKEY is at or
+		below a domain specified by the deepest
+		<command>dnssec-lookaside</command>, 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
+		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.
+	      </para>
+	      <para>
+		If <command>dnssec-lookaside</command> is set to
+		<userinput>no</userinput>, then dnssec-lookaside
+		is not used.
+	      </para>
+	      <para>
+		NOTE: The ISC-provided DLV service at
+		<literal>dlv.isc.org</literal>, has been shut down.
+		The <command>dnssec-lookaside auto;</command>
+		configuration option, which set <command>named</command>
+		up to use ISC DLV with minimal configuration, has
+		accordingly been removed.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dnssec-must-be-secure</command></term>
+	    <listitem>
+	      <para>
+		Specify hierarchies which must be or may not be secure
+		(signed and validated).  If <userinput>yes</userinput>,
+		then <command>named</command> will only accept answers if
+		they are secure.  If <userinput>no</userinput>, then normal
+		DNSSEC validation applies allowing for insecure answers to
+		be accepted.  The specified domain must be under a
+		<command>trusted-keys</command> or
+		<command>managed-keys</command> statement, or
+		<command>dnssec-validation auto</command> must be active.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dns64</command></term>
+	    <listitem>
+	      <para>
+		This directive instructs <command>named</command> to
+		return mapped IPv4 addresses to AAAA queries when
+		there are no AAAA records.  It is intended to be
+		used in conjunction with a NAT64.  Each
+		<command>dns64</command> defines one DNS64 prefix.
+		Multiple DNS64 prefixes can be defined.
+	      </para>
+	      <para>
+		Compatible IPv6 prefixes have lengths of 32, 40, 48, 56,
+		64 and 96 as per RFC 6052.
+	      </para>
+	      <para>
+		Additionally a reverse IP6.ARPA zone will be created for
+		the prefix to provide a mapping from the IP6.ARPA names
+		to the corresponding IN-ADDR.ARPA names using synthesized
+		CNAMEs.  <command>dns64-server</command> and
+		<command>dns64-contact</command> 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.
+	      </para>
+	      <para>
+		Each <command>dns64</command> supports an optional
+		<command>clients</command> ACL that determines which
+		clients are affected by this directive.  If not defined,
+		it defaults to <userinput>any;</userinput>.
+	      </para>
+	      <para>
+		Each <command>dns64</command> supports an optional
+		<command>mapped</command> ACL that selects which
+		IPv4 addresses are to be mapped in the corresponding
+		A RRset.  If not defined it defaults to
+		<userinput>any;</userinput>.
+	      </para>
+	      <para>
+		Normally, DNS64 won't apply to a domain name that
+		owns one or more AAAA records; these records will
+		simply be returned.  The optional
+		<command>exclude</command> 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
+		name owns.  If not defined, <command>exclude</command>
+		defaults to ::ffff:0.0.0.0/96.
+	      </para>
+	      <para>
+		A optional <command>suffix</command> can also
+		be defined to set the bits trailing the mapped
+		IPv4 address bits.  By default these bits are
+		set to <userinput>::</userinput>.  The bits
+		matching the prefix and mapped IPv4 address
+		must be zero.
+	      </para>
+	      <para>
+		If <command>recursive-only</command> is set to
+		<command>yes</command> the DNS64 synthesis will
+		only happen for recursive queries.  The default
+		is <command>no</command>.
+	      </para>
+	      <para>
+		If <command>break-dnssec</command> is set to
+		<command>yes</command> the DNS64 synthesis will
+		happen even if the result, if validated, would
+		cause a DNSSEC validation failure.  If this option
+		is set to <command>no</command> (the default), the DO
+		is set on the incoming query, and there are RRSIGs on
+		the applicable records, then synthesis will not happen.
+	      </para>
+<programlisting>
+	acl rfc1918 { 10/8; 192.168/16; 172.16/12; };
+
+	dns64 64:FF9B::/96 {
+		clients { any; };
+		mapped { !rfc1918; any; };
+		exclude { 64:FF9B::/96; ::ffff:0000:0000/96; };
+		suffix ::;
+	};
+</programlisting>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dnssec-loadkeys-interval</command></term>
+	    <listitem>
+		<para>
+		  When a zone is configured with <command>auto-dnssec
+		  maintain;</command> 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 <xref linkend="man.dnssec-keygen"/> and
+		  <xref linkend="man.dnssec-settime"/>).  The
+		  <command>dnssec-loadkeys-interval</command> option
+		  sets the frequency of automatic repository checks, in
+		  minutes.  The default is <literal>60</literal> (1 hour),
+		  the minimum is <literal>1</literal> (1 minute), and the
+		  maximum is <literal>1440</literal> (24 hours); any higher
+		  value is silently reduced.
+		</para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>dnssec-update-mode</command></term>
+	    <listitem>
+		<para>
+		  If this option is set to its default value of
+		  <literal>maintain</literal> in a zone of type
+		  <literal>master</literal> which is DNSSEC-signed
+		  and configured to allow dynamic updates (see
+		  <xref linkend="dynamic_update_policies"/>), and
+		  if <command>named</command> has access to the
+		  private signing key(s) for the zone, then
+		  <command>named</command> will automatically sign all new
+		  or changed records and maintain signatures for the zone
+		  by regenerating RRSIG records whenever they approach
+		  their expiration date.
+		</para>
+		<para>
+		  If the option is changed to <literal>no-resign</literal>,
+		  then <command>named</command> will sign all new or
+		  changed records, but scheduled maintenance of
+		  signatures is disabled.
+		</para>
+		<para>
+		  With either of these settings, <command>named</command>
+		  will reject updates to a DNSSEC-signed zone when the
+		  signing keys are inactive or unavailable to
+		  <command>named</command>.  (A planned third option,
+		  <literal>external</literal>, will disable all automatic
+		  signing and allow DNSSEC data to be submitted into a zone
+		  via dynamic update; this is not yet implemented.)
+		</para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>nta-lifetime</command></term>
+	    <listitem>
+		<para>
+		  Species the default lifetime, in seconds,
+		  that will be used for negative trust anchors added
+		  via <command>rndc nta</command>.
+		</para>
+		<para>
+		  A negative trust anchor selectively disables
+		  DNSSEC validation for zones that are known to be
+		  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), <command>named</command> will
+		  abort the DNSSEC validation process and treat the data as
+		  insecure rather than bogus.  This continues until the
+		  NTA's lifetime is elapsed. NTAs persist
+		  across <command>named</command> restarts.
+		</para>
+		<para>
+		  For convenience, TTL-style time unit suffixes can be
+		  used to specify the NTA lifetime in seconds, minutes
+		  or hours.  <option>nta-lifetime</option> defaults to
+		  one hour.  It cannot exceed one week.
+		</para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>nta-recheck</command></term>
+	    <listitem>
+		<para>
+		  Species how often to check whether negative
+		  trust anchors added via <command>rndc nta</command>
+		  are still necessary.
+		</para>
+		<para>
+		  A negative trust anchor is normally used when a
+		  domain has stopped validating due to operator error;
+		  it temporarily disables DNSSEC validation for that
+		  domain. In the interest of ensuring that DNSSEC
+		  validation is turned back on as soon as possible,
+		  <command>named</command> will periodically send 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.
+		</para>
+		<para>
+		  Validity checks can be disabled for an individual
+		  NTA by using <command>rndc nta -f</command>, or
+		  for all NTAs by setting <option>nta-recheck</option>
+		  to zero.
+		</para>
+		<para>
+		  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 <option>nta-lifetime</option>
+		  (which cannot be longer than a week).
+		</para>
+	    </listitem>
+	  </varlistentry>
+
+
+	  <varlistentry>
+	    <term><command>max-zone-ttl</command></term>
+	    <listitem>
+	      <para>
+		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
+		<option>masterfile-format</option> of
+		<constant>text</constant> or <constant>raw</constant>,
+		any record encountered with a TTL higher than
+		<option>max-zone-ttl</option> will cause the zone to
+		be rejected.
+	      </para>
+	      <para>
+		This is useful in DNSSEC-signed zones because when
+		rolling to a new DNSKEY, the old key needs to remain
+		available until RRSIG records have expired from
+		caches.  The <option>max-zone-ttl</option> option guarantees
+		that the largest TTL in the zone will be no higher
+		than the set value.
+	      </para>
+	      <para>
+		(NOTE: Because <constant>map</constant>-format files
+		load directly into memory, this option cannot be
+		used with them.)
+	      </para>
+	      <para>
+		The default value is <constant>unlimited</constant>.
+		A <option>max-zone-ttl</option> of zero is treated as
+		<constant>unlimited</constant>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>serial-update-method</command></term>
+	    <listitem>
+	      <para>
+		Zones configured for dynamic DNS may use this
+		option to set the update method that will be used for
+		the zone serial number in the SOA record.
+	      </para>
+	      <para>
+		With the default setting of
+		<command>serial-update-method increment;</command>, the
+		SOA serial number will be incremented by one each time
+		the zone is updated.
+	      </para>
+	      <para>
+		When set to
+		<command>serial-update-method unixtime;</command>, the
+		SOA serial number will be set to the number of seconds
+		since the UNIX epoch, unless the serial number is
+		already greater than or equal to that value, in which
+		case it is simply incremented by one.
+	      </para>
+	      <para>
+		When set to
+		<command>serial-update-method date;</command>, the
+		new SOA serial number will be 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
+		incremented by one.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+
+	  <varlistentry>
+	    <term><command>zone-statistics</command></term>
+	    <listitem>
+	      <para>
+		If <userinput>full</userinput>, the server will collect
+		statistical data on all zones (unless specifically
+		turned off on a per-zone basis by specifying
+		<command>zone-statistics terse</command> or
+		<command>zone-statistics none</command>
+		in the <command>zone</command> statement).
+		The default is <userinput>terse</userinput>, providing
+		minimal statistics on zones (including name and
+		current serial number, but not query type
+		counters).
+	      </para>
+	      <para>
+		These statistics may be accessed via the
+		<command>statistics-channel</command> or
+		using <command>rndc stats</command>, which
+		will dump them to the file listed
+		in the <command>statistics-file</command>.  See
+		also <xref linkend="statsfile"/>.
+	      </para>
+	      <para>
+		For backward compatibility with earlier versions
+		of BIND 9, the <command>zone-statistics</command>
+		option can also accept <userinput>yes</userinput>
+		or <userinput>no</userinput>; <userinput>yes</userinput>
+		has the same meaning as <userinput>full</userinput>.
+		As of <acronym>BIND</acronym> 9.10,
+		<userinput>no</userinput> has the same meaning
+		as <userinput>none</userinput>; previously, it
+		was the same as <userinput>terse</userinput>.
+	      </para>
+	    </listitem>
+	  </varlistentry>
+	</variablelist>
+
+	<section xml:id="boolean_options"><info><title>Boolean Options</title></info>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>automatic-interface-scan</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput> and supported by the OS,
+		  automatically rescan network interfaces when the interface
+		  addresses are added or removed.  The default is
+		  <userinput>yes</userinput>.
+		</para>
+		<para>
+		  Currently the OS needs to support routing sockets for
+		  <command>automatic-interface-scan</command> to be
+		  supported.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-new-zones</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput>, then zones can be
+		  added at runtime via <command>rndc addzone</command>.
+		  The default is <userinput>no</userinput>.
+		</para>
+		<para>
+		  Newly added zones' configuration parameters
+		  are stored so that they can persist after the
+		  server is restarted.  The configuration information
+		  is saved in a file called
+		  <filename><replaceable>viewname</replaceable>.nzf</filename>
+		  (or, if <command>named</command> is compiled with
+		  liblmdb, in an LMDB database file called
+		  <filename><replaceable>viewname</replaceable>.nzd</filename>).
+		  <replaceable>viewname</replaceable> is the name of the
+		  view, unless the view name contains characters that are
+		  incompatible with use as a file name, in which case a
+		  cryptographic hash of the view name is used instead.
+		</para>
+		<para>
+		  Zones added at runtime will have their configuration
+		  stored either in a new-zone file (NZF) or a new-zone
+		  database (NZD) depending on whether
+		  <command>named</command> was linked with
+		  liblmdb at compile time.
+		  See <xref linkend="man.rndc"/> for further details
+		  about <command>rndc addzone</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>auth-nxdomain</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput>, then the <command>AA</command> bit
+		  is always set on NXDOMAIN responses, even if the server is
+		  not actually
+		  authoritative. The default is <userinput>no</userinput>;
+		  this is
+		  a change from <acronym>BIND</acronym> 8. If you
+		  are using very old DNS software, you
+		  may need to set it to <userinput>yes</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>deallocate-on-exit</command></term>
+	      <listitem>
+		<para>
+		  This option was used in <acronym>BIND</acronym>
+		  8 to enable checking
+		  for memory leaks on exit. <acronym>BIND</acronym> 9 ignores the option and always performs
+		  the checks.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>memstatistics</command></term>
+	      <listitem>
+		<para>
+		  Write memory statistics to the file specified by
+		  <command>memstatistics-file</command> at exit.
+		  The default is <userinput>no</userinput> unless
+		  '-m record' is specified on the command line in
+		  which case it is <userinput>yes</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>dialup</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput>, then the
+		  server treats all zones as if they are doing zone transfers
+		  across
+		  a dial-on-demand dialup link, which can be brought up by
+		  traffic
+		  originating from this server. This has different effects
+		  according
+		  to zone type and concentrates the zone maintenance so that
+		  it all
+		  happens in a short interval, once every <command>heartbeat-interval</command> and
+		  hopefully during the one call. It also suppresses some of
+		  the normal
+		  zone maintenance traffic. The default is <userinput>no</userinput>.
+		</para>
+		<para>
+		  The <command>dialup</command> option
+		  may also be specified in the <command>view</command> and
+		  <command>zone</command> statements,
+		  in which case it overrides the global <command>dialup</command>
+		  option.
+		</para>
+		<para>
+		  If the zone is a master zone, then the server will send out a
+		  NOTIFY
+		  request to all the slaves (default). This should trigger the
+		  zone serial
+		  number check in the slave (providing it supports NOTIFY)
+		  allowing the slave
+		  to verify the zone while the connection is active.
+		  The set of servers to which NOTIFY is sent can be controlled
+		  by
+		  <command>notify</command> and <command>also-notify</command>.
+		</para>
+		<para>
+		  If the
+		  zone is a slave or stub zone, then the server will suppress
+		  the regular
+		  "zone up to date" (refresh) queries and only perform them
+		  when the
+		  <command>heartbeat-interval</command> expires in
+		  addition to sending
+		  NOTIFY requests.
+		</para>
+		<para>
+		  Finer control can be achieved by using
+		  <userinput>notify</userinput> which only sends NOTIFY
+		  messages,
+		  <userinput>notify-passive</userinput> which sends NOTIFY
+		  messages and
+		  suppresses the normal refresh queries, <userinput>refresh</userinput>
+		  which suppresses normal refresh processing and sends refresh
+		  queries
+		  when the <command>heartbeat-interval</command>
+		  expires, and
+		  <userinput>passive</userinput> which just disables normal
+		  refresh
+		  processing.
+		</para>
+
+		<informaltable colsep="0" rowsep="0">
+		  <tgroup cols="4" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		    <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		    <colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
+		    <colspec colname="3" colnum="3" colsep="0" colwidth="1.150in"/>
+		    <colspec colname="4" colnum="4" colsep="0" colwidth="1.150in"/>
+		    <tbody>
+		      <row rowsep="0">
+			<entry colname="1">
+			  <para>
+			    dialup mode
+			  </para>
+			</entry>
+			<entry colname="2">
+			  <para>
+			    normal refresh
+			  </para>
+			</entry>
+			<entry colname="3">
+			  <para>
+			    heart-beat refresh
+			  </para>
+			</entry>
+			<entry colname="4">
+			  <para>
+			    heart-beat notify
+			  </para>
+			</entry>
+		      </row>
+		      <row rowsep="0">
+			<entry colname="1">
+			  <para><command>no</command> (default)</para>
+			</entry>
+			<entry colname="2">
+			  <para>
+			    yes
+			  </para>
+			</entry>
+			<entry colname="3">
+			  <para>
+			    no
+			  </para>
+			</entry>
+			<entry colname="4">
+			  <para>
+			    no
+			  </para>
+			</entry>
+		      </row>
+		      <row rowsep="0">
+			<entry colname="1">
+			  <para><command>yes</command></para>
+			</entry>
+			<entry colname="2">
+			  <para>
+			    no
+			  </para>
+			</entry>
+			<entry colname="3">
+			  <para>
+			    yes
+			  </para>
+			</entry>
+			<entry colname="4">
+			  <para>
+			    yes
+			  </para>
+			</entry>
+		      </row>
+		      <row rowsep="0">
+			<entry colname="1">
+			  <para><command>notify</command></para>
+			</entry>
+			<entry colname="2">
+			  <para>
+			    yes
+			  </para>
+			</entry>
+			<entry colname="3">
+			  <para>
+			    no
+			  </para>
+			</entry>
+			<entry colname="4">
+			  <para>
+			    yes
+			  </para>
+			</entry>
+		      </row>
+		      <row rowsep="0">
+			<entry colname="1">
+			  <para><command>refresh</command></para>
+			</entry>
+			<entry colname="2">
+			  <para>
+			    no
+			  </para>
+			</entry>
+			<entry colname="3">
+			  <para>
+			    yes
+			  </para>
+			</entry>
+			<entry colname="4">
+			  <para>
+			    no
+			  </para>
+			</entry>
+		      </row>
+		      <row rowsep="0">
+			<entry colname="1">
+			  <para><command>passive</command></para>
+			</entry>
+			<entry colname="2">
+			  <para>
+			    no
+			  </para>
+			</entry>
+			<entry colname="3">
+			  <para>
+			    no
+			  </para>
+			</entry>
+			<entry colname="4">
+			  <para>
+			    no
+			  </para>
+			</entry>
+		      </row>
+		      <row rowsep="0">
+			<entry colname="1">
+			  <para><command>notify-passive</command></para>
+			</entry>
+			<entry colname="2">
+			  <para>
+			    no
+			  </para>
+			</entry>
+			<entry colname="3">
+			  <para>
+			    no
+			  </para>
+			</entry>
+			<entry colname="4">
+			  <para>
+			    yes
+			  </para>
+			</entry>
+		      </row>
+		    </tbody>
+		  </tgroup>
+		</informaltable>
+
+		<para>
+		  Note that normal NOTIFY processing is not affected by
+		  <command>dialup</command>.
+		</para>
+
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>fake-iquery</command></term>
+	      <listitem>
+		<para>
+		  In <acronym>BIND</acronym> 8, this option
+		  enabled simulating the obsolete DNS query type
+		  IQUERY. <acronym>BIND</acronym> 9 never does
+		  IQUERY simulation.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>fetch-glue</command></term>
+	      <listitem>
+		<para>
+		  This option is obsolete.
+		  In BIND 8, <userinput>fetch-glue yes</userinput>
+		  caused the server to attempt to fetch glue resource records
+		  it
+		  didn't have when constructing the additional
+		  data section of a response.  This is now considered a bad
+		  idea
+		  and BIND 9 never does it.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>flush-zones-on-shutdown</command></term>
+	      <listitem>
+		<para>
+		  When the nameserver exits due receiving SIGTERM,
+		  flush or do not flush any pending zone writes.  The default
+		  is
+		  <command>flush-zones-on-shutdown</command> <userinput>no</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>geoip-use-ecs</command></term>
+	      <listitem>
+		<para>
+		  When BIND is compiled with GeoIP support and configured
+		  with "geoip" ACL elements, this option indicates whether
+		  the EDNS Client Subnet option, if present in a request,
+		  should be used for matching against the GeoIP database.
+		  The default is
+		  <command>geoip-use-ecs</command> <userinput>yes</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>has-old-clients</command></term>
+	      <listitem>
+		<para>
+		  This option was incorrectly implemented
+		  in <acronym>BIND</acronym> 8, and is ignored by <acronym>BIND</acronym> 9.
+		  To achieve the intended effect
+		  of
+		  <command>has-old-clients</command> <userinput>yes</userinput>, specify
+		  the two separate options <command>auth-nxdomain</command> <userinput>yes</userinput>
+		  and <command>rfc2308-type1</command> <userinput>no</userinput> instead.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>host-statistics</command></term>
+	      <listitem>
+		<para>
+		  In BIND 8, this enabled keeping of
+		  statistics for every host that the name server interacts
+		  with.
+		  Not implemented in BIND 9.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>root-key-sentinel</command></term>
+	      <listitem>
+		<para>
+		  Respond to root key sentinel probes as described in
+		  draft-ietf-dnsop-kskroll-sentinel-08. The default is
+		  <userinput>yes</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>maintain-ixfr-base</command></term>
+	      <listitem>
+		<para>
+		  <emphasis>This option is obsolete</emphasis>.
+		  It was used in <acronym>BIND</acronym> 8 to
+		  determine whether a transaction log was
+		  kept for Incremental Zone Transfer. <acronym>BIND</acronym> 9 maintains a transaction
+		  log whenever possible.  If you need to disable outgoing
+		  incremental zone
+		  transfers, use <command>provide-ixfr</command> <userinput>no</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>message-compression</command></term> <listitem>
+		<para>
+		  If <userinput>yes</userinput>, DNS name compression is
+		  used in responses to regular queries (not including
+		  AXFR or IXFR, which always uses compression).  Setting
+		  this option to <userinput>no</userinput> reduces CPU
+		  usage on servers and may improve throughput.  However,
+		  it increases response size, which may cause more queries
+		  to be processed using TCP; a server with compression
+		  disabled is out of compliance with RFC 1123 Section
+		  6.1.3.2. The default is <userinput>yes</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>minimal-responses</command></term>
+	      <listitem>
+		<para>
+		  If set to <userinput>yes</userinput>, then when generating
+		  responses the server will only add records to the authority
+		  and additional data sections when they are required (e.g.
+		  delegations, negative responses).  This may improve the
+		  performance of the server.
+		</para>
+		<para>
+		  When set to <userinput>no-auth</userinput>, the
+		  server will omit records from the authority section
+		  unless they are required, but it may still add
+		  records to the additional section.  When set to
+		  <userinput>no-auth-recursive</userinput>, this
+		  is only done if the query is recursive.  These
+		  settings are useful when answering stub clients,
+		  which usually ignore the authority section.
+		  <userinput>no-auth-recursive</userinput> is
+		  designed for mixed-mode servers which handle
+		  both authoritative and recursive queries.
+		</para>
+		<para>
+		  The default is <userinput>no</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>minimal-any</command></term>
+	      <listitem>
+		<para>
+		  If set to <userinput>yes</userinput>, then when
+		  generating a positive response to a query of type
+		  ANY over UDP, the server will reply with only one
+		  of the RRsets for the query name, and its covering
+		  RRSIGs if any, instead of replying with all known
+		  RRsets for the name.  Similarly, a query for type
+		  RRSIG will be 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
+		  first one found in the database; it is not necessarily
+		  the smallest available RRset.)
+		  Additionally, <option>minimal-responses</option> is
+		  turned on for these queries, so no unnecessary records
+		  will be added to the authority or additional sections.
+		  The default is <userinput>no</userinput>.
+		</para>
+	    </listitem>
+	  </varlistentry>
+
+	    <varlistentry>
+	      <term><command>multiple-cnames</command></term>
+	      <listitem>
+		<para>
+		  This option was used in <acronym>BIND</acronym> 8 to allow
+		  a domain name to have multiple CNAME records in violation of
+		  the DNS standards.  <acronym>BIND</acronym> 9.2 onwards
+		  always strictly enforces the CNAME rules both in master
+		  files and dynamic updates.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>notify</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput> (the default),
+		  DNS NOTIFY messages are sent when a zone the server is
+		  authoritative for
+		  changes, see <xref linkend="notify"/>.  The messages are
+		  sent to the
+		  servers listed in the zone's NS records (except the master
+		  server identified
+		  in the SOA MNAME field), and to any servers listed in the
+		  <command>also-notify</command> option.
+		</para>
+		<para>
+		  If <userinput>master-only</userinput>, notifies are only
+		  sent
+		  for master zones.
+		  If <userinput>explicit</userinput>, notifies are sent only
+		  to
+		  servers explicitly listed using <command>also-notify</command>.
+		  If <userinput>no</userinput>, no notifies are sent.
+		</para>
+		<para>
+		  The <command>notify</command> option may also be
+		  specified in the <command>zone</command>
+		  statement,
+		  in which case it overrides the <command>options notify</command> statement.
+		  It would only be necessary to turn off this option if it
+		  caused slaves
+		  to crash.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>notify-to-soa</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput> do not check the nameservers
+		  in the NS RRset against the SOA MNAME.  Normally a NOTIFY
+		  message is not sent to the SOA MNAME (SOA ORIGIN) as it is
+		  supposed to contain the name of the ultimate master.
+		  Sometimes, however, a slave is listed as the SOA MNAME in
+		  hidden master configurations and in that case you would
+		  want the ultimate master to still send NOTIFY messages to
+		  all the nameservers listed in the NS RRset.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>recursion</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput>, and a
+		  DNS query requests recursion, then the server will attempt
+		  to do
+		  all the work required to answer the query. If recursion is
+		  off
+		  and the server does not already know the answer, it will
+		  return a
+		  referral response. The default is
+		  <userinput>yes</userinput>.
+		  Note that setting <command>recursion no</command> does not prevent
+		  clients from getting data from the server's cache; it only
+		  prevents new data from being cached as an effect of client
+		  queries.
+		  Caching may still occur as an effect the server's internal
+		  operation, such as NOTIFY address lookups.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>request-nsid</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput>, then an empty EDNS(0)
+		  NSID (Name Server Identifier) option is sent with all
+		  queries to authoritative name servers during iterative
+		  resolution. If the authoritative server returns an NSID
+		  option in its response, then its contents are logged in
+		  the <command>resolver</command> category at level
+		  <command>info</command>.
+		  The default is <userinput>no</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>request-sit</command></term>
+	      <listitem>
+		<para>
+		  This experimental option is obsolete.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>require-server-cookie</command></term>
+	      <listitem>
+		<para>
+		  Require a valid server cookie before sending a full
+		  response to a UDP request from a cookie aware client.
+		  BADCOOKIE is sent if there is a bad or no existent
+		  server cookie.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>answer-cookie</command></term>
+	      <listitem>
+		<para>
+		  When set to the default value of <userinput>yes</userinput>,
+		  COOKIE EDNS options will be sent when applicable in
+		  replies to client queries. If set to
+		  <userinput>no</userinput>, COOKIE EDNS options will not
+		  be sent in replies.  This can only be set at the global
+		  options level, not per-view.
+		</para>
+		<para>
+		  <command>answer-cookie no</command> is only intended as a
+		  temporary measure, for use when <command>named</command>
+		  shares an IP address with other servers that do not yet
+		  support DNS COOKIE.  A mismatch between servers on the
+		  same address is not expected to cause operational
+		  problems, but the option to disable COOKIE responses so
+		  that all servers have the same behavior is provided out
+		  of an abundance of caution. DNS COOKIE is an important
+		  security mechanism, and should not be disabled unless
+		  absolutely necessary.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>send-cookie</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput>, then a COOKIE EDNS
+		  option is sent along with the query.  If the
+		  resolver has previously talked to 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
+		  sending the correct COOKIE is assumed not to be an
+		  off-path attacker sending a spoofed-source query;
+		  the query is therefore unlikely to be part of a
+		  reflection/amplification attack, so resolvers
+		  sending a correct COOKIE option are not subject to
+		  response rate limiting (RRL).  Resolvers which
+		  do not send a correct COOKIE option may be limited
+		  to receiving smaller responses via the
+		  <command>nocookie-udp-size</command> option.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>nocookie-udp-size</command></term>
+	      <listitem>
+		<para>
+		  Sets the maximum size of UDP responses that will be
+		  sent to queries without a valid server COOKIE. A value
+		  below 128 will be silently raised to 128. The default
+		  value is 4096, but the <command>max-udp-size</command>
+		  option may further limit the response size.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>sit-secret</command></term>
+	      <listitem>
+		<para>
+		  This experimental option is obsolete.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>cookie-algorithm</command></term>
+	      <listitem>
+		<para>
+		  Set the algorithm to be used when generating the
+		  server cookie.  One of "aes", "sha1" or "sha256".
+		  The default is "aes" if supported by the cryptographic
+		  library or otherwise "sha256".
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>cookie-secret</command></term>
+	      <listitem>
+		<para>
+		  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
+		  shared secret is encoded as a hex string and needs
+		  to be 128 bits for AES128, 160 bits for SHA1 and
+		  256 bits for SHA256.
+		</para>
+		<para>
+		  If there are multiple secrets specified, the first
+		  one listed in <filename>named.conf</filename> is
+		  used to generate new server cookies.  The others
+		  will only be used to verify returned cookies.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>rfc2308-type1</command></term>
+	      <listitem>
+		<para>
+		  Setting this to <userinput>yes</userinput> will
+		  cause the server to send NS records along with the SOA
+		  record for negative
+		  answers. The default is <userinput>no</userinput>.
+		</para>
+		<note>
+		  <simpara>
+		    Not yet implemented in <acronym>BIND</acronym>
+		    9.
+		  </simpara>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>trust-anchor-telemetry</command></term>
+	      <listitem>
+		<para>
+		  Causes <command>named</command> to send specially-formed
+		  queries once per day to domains for which trust anchors
+		  have been configured via <command>trusted-keys</command>,
+		  <command>managed-keys</command>, or
+		  <command>dnssec-validation auto</command>.
+		</para>
+		<para>
+		  The query name used for these queries has the
+		  form "_ta-xxxx(-xxxx)(...)".&lt;domain&gt;, where
+		  each "xxxx" is a group of four hexadecimal digits
+		  representing the key ID of a trusted DNSSEC key.
+		  The key IDs for each domain are sorted smallest
+		  to largest prior to encoding. The query type is NULL.
+		</para>
+		<para>
+		  By monitoring these queries, zone operators will
+		  be able to see which resolvers have been updated to
+		  trust a new key; this may help them decide when it
+		  is safe to remove an old one.
+		</para>
+		<para>
+		  The default is <userinput>yes</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>use-id-pool</command></term>
+	      <listitem>
+		<para>
+		  <emphasis>This option is obsolete</emphasis>.
+		  <acronym>BIND</acronym> 9 always allocates query
+		  IDs from a pool.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>use-ixfr</command></term>
+	      <listitem>
+		<para>
+		  <emphasis>This option is obsolete</emphasis>.
+		  If you need to disable IXFR to a particular server or
+		  servers, see
+		  the information on the <command>provide-ixfr</command> option
+		  in <xref linkend="server_statement_definition_and_usage"/>.
+		  See also
+		  <xref linkend="incremental_zone_transfers"/>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>provide-ixfr</command></term>
+	      <listitem>
+		<para>
+		  See the description of
+		  <command>provide-ixfr</command> in
+		  <xref linkend="server_statement_definition_and_usage"/>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>request-ixfr</command></term>
+	      <listitem>
+		<para>
+		  See the description of
+		  <command>request-ixfr</command> in
+		  <xref linkend="server_statement_definition_and_usage"/>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>request-expire</command></term>
+	      <listitem>
+		<para>
+		  See the description of
+		  <command>request-expire</command> in
+		  <xref linkend="server_statement_definition_and_usage"/>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>treat-cr-as-space</command></term>
+	      <listitem>
+		<para>
+		  This option was used in <acronym>BIND</acronym>
+		  8 to make
+		  the server treat carriage return ("<command>\r</command>") characters the same way
+		  as a space or tab character,
+		  to facilitate loading of zone files on a UNIX system that
+		  were generated
+		  on an NT or DOS machine. In <acronym>BIND</acronym> 9, both UNIX "<command>\n</command>"
+		  and NT/DOS "<command>\r\n</command>" newlines
+		  are always accepted,
+		  and the option is ignored.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>additional-from-auth</command></term>
+	      <term><command>additional-from-cache</command></term>
+	      <listitem>
+
+		<para>
+		  These options control the behavior of an authoritative
+		  server when
+		  answering queries which have additional data, or when
+		  following CNAME
+		  and DNAME chains.
+		</para>
+
+		<para>
+		  When both of these options are set to <userinput>yes</userinput>
+		  (the default) and a
+		  query is being answered from authoritative data (a zone
+		  configured into the server), the additional data section of
+		  the
+		  reply will be filled in using data from other authoritative
+		  zones
+		  and from the cache.  In some situations this is undesirable,
+		  such
+		  as when there is concern over the correctness of the cache,
+		  or
+		  in servers where slave zones may be added and modified by
+		  untrusted third parties.  Also, avoiding
+		  the search for this additional data will speed up server
+		  operations
+		  at the possible expense of additional queries to resolve
+		  what would
+		  otherwise be provided in the additional section.
+		</para>
+
+		<para>
+		  For example, if a query asks for an MX record for host <literal>foo.example.com</literal>,
+		  and the record found is "<literal>MX 10 mail.example.net</literal>", normally the address
+		  records (A and AAAA) for <literal>mail.example.net</literal> will be provided as well,
+		  if known, even though they are not in the example.com zone.
+		  Setting these options to <command>no</command>
+		  disables this behavior and makes
+		  the server only search for additional data in the zone it
+		  answers from.
+		</para>
+
+		<para>
+		  These options are intended for use in authoritative-only
+		  servers, or in authoritative-only views.  Attempts to set
+		  them to <command>no</command> without also
+		  specifying
+		  <command>recursion no</command> will cause the
+		  server to
+		  ignore the options and log a warning message.
+		</para>
+
+		<para>
+		  Specifying <command>additional-from-cache no</command> actually
+		  disables the use of the cache not only for additional data
+		  lookups
+		  but also when looking up the answer.  This is usually the
+		  desired
+		  behavior in an authoritative-only server where the
+		  correctness of
+		  the cached data is an issue.
+		</para>
+
+		<para>
+		  When a name server is non-recursively queried for a name
+		  that is not
+		  below the apex of any served zone, it normally answers with
+		  an
+		  "upwards referral" to the root servers or the servers of
+		  some other
+		  known parent of the query name.  Since the data in an
+		  upwards referral
+		  comes from the cache, the server will not be able to provide
+		  upwards
+		  referrals when <command>additional-from-cache no</command>
+		  has been specified.  Instead, it will respond to such
+		  queries
+		  with REFUSED.  This should not cause any problems since
+		  upwards referrals are not required for the resolution
+		  process.
+		</para>
+
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>match-mapped-addresses</command></term>
+	      <listitem>
+		<para>
+		  If <userinput>yes</userinput>, then an
+		  IPv4-mapped IPv6 address will match any address match
+		  list entries that match the corresponding IPv4 address.
+		</para>
+		<para>
+		  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,
+		  <command>named</command> now solves this problem
+		  internally.  The use of this option is discouraged.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>filter-aaaa-on-v4</command></term>
+	      <listitem>
+		<para>
+		  This option is only available when
+		  <acronym>BIND</acronym> 9 is compiled with the
+		  <userinput>--enable-filter-aaaa</userinput> option on the
+		  "configure" command line.  It is intended to help the
+		  transition from IPv4 to IPv6 by not giving IPv6 addresses
+		  to DNS clients unless they have connections to the IPv6
+		  Internet.  This is not recommended unless absolutely
+		  necessary.  The default is <userinput>no</userinput>.
+		  The <command>filter-aaaa-on-v4</command> option
+		  may also be specified in <command>view</command> statements
+		  to override the global <command>filter-aaaa-on-v4</command>
+		  option.
+		</para>
+		<para>
+		  If <userinput>yes</userinput>,
+		  the DNS client is at an IPv4 address, in <command>filter-aaaa</command>,
+		  and if the response does not include DNSSEC signatures,
+		  then all AAAA records are deleted from the response.
+		  This filtering applies to all responses and not only
+		  authoritative responses.
+		</para>
+		<para>
+		  If <userinput>break-dnssec</userinput>,
+		  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.
+		</para>
+		<para>
+		  This mechanism can erroneously cause other servers to
+		  not give AAAA records to their clients.
+		  A recursing server with both IPv6 and IPv4 network connections
+		  that queries an authoritative server using this mechanism
+		  via IPv4 will be denied AAAA records even if its client is
+		  using IPv6.
+		</para>
+		<para>
+		  This mechanism is applied to authoritative as well as
+		  non-authoritative records.
+		  A client using IPv4 that is not allowed recursion can
+		  erroneously be given AAAA records because the server is not
+		  allowed to check for A records.
+		</para>
+		<para>
+		  Some AAAA records are given to IPv4 clients in glue records.
+		  IPv4 clients that are servers can then erroneously
+		  answer requests for AAAA records received via IPv4.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>filter-aaaa-on-v6</command></term>
+	      <listitem>
+		<para>
+		  Identical to <command>filter-aaaa-on-v4</command>,
+		  except it filters AAAA responses to queries from IPv6
+		  clients instead of IPv4 clients.  To filter all
+		  responses, set both options to <userinput>yes</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>ixfr-from-differences</command></term>
+	      <listitem>
+		<para>
+		  When <userinput>yes</userinput> and the server loads a new
+		  version of a master zone from its zone file or receives a
+		  new version of a slave file via zone transfer, it will
+		  compare the new version to the previous one and calculate
+		  a set of differences.  The differences are then logged in
+		  the zone's journal file such that the changes can be
+		  transmitted to downstream slaves as an incremental zone
+		  transfer.
+		</para>
+		<para>
+		  By allowing incremental zone transfers to be used for
+		  non-dynamic zones, this option saves bandwidth at the
+		  expense of increased CPU and memory consumption at the
+		  master.
+		  In particular, if the new version of a zone is completely
+		  different from the previous one, the set of differences
+		  will be of a size comparable to the combined size of the
+		  old and new zone version, and the server will need to
+		  temporarily allocate memory to hold this complete
+		  difference set.
+		</para>
+		<para><command>ixfr-from-differences</command>
+		  also accepts <command>master</command> and
+		  <command>slave</command> at the view and options
+		  levels which causes
+		  <command>ixfr-from-differences</command> to be enabled for
+		  all <command>master</command> or
+		  <command>slave</command> zones respectively.
+		  It is off by default.
+		</para>
+		<para>
+		  Note: if inline signing is enabled for a zone, the
+		  user-provided <command>ixfr-from-differences</command>
+		  setting is ignored for that zone.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>multi-master</command></term>
+	      <listitem>
+		<para>
+		  This should be set when you have multiple masters for a zone
+		  and the
+		  addresses refer to different machines.  If <userinput>yes</userinput>, <command>named</command> will
+		  not log
+		  when the serial number on the master is less than what <command>named</command>
+		  currently
+		  has.  The default is <userinput>no</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>auto-dnssec</command></term>
+	      <listitem>
+		<para>
+		  Zones configured for dynamic DNS may use this
+		  option to allow varying levels of automatic DNSSEC key
+		  management. There are three possible settings:
+		</para>
+		<para>
+		  <command>auto-dnssec allow;</command> permits
+		  keys to be updated and the zone fully re-signed
+		  whenever the user issues the command <command>rndc sign
+		  <replaceable>zonename</replaceable></command>.
+		</para>
+		<para>
+		  <command>auto-dnssec maintain;</command> includes the
+		  above, but also automatically adjusts the zone's DNSSEC
+		  keys on schedule, according to the keys' timing metadata
+		  (see <xref linkend="man.dnssec-keygen"/> and
+		  <xref linkend="man.dnssec-settime"/>).  The command
+		  <command>rndc sign
+		  <replaceable>zonename</replaceable></command> causes
+		  <command>named</command> to load keys from the key
+		  repository and sign the zone with all keys that are
+		  active.
+		  <command>rndc loadkeys
+		  <replaceable>zonename</replaceable></command> causes
+		  <command>named</command> to load keys from the key
+		  repository and schedule key maintenance events to occur
+		  in the future, but it does not sign the full zone
+		  immediately.  Note: once keys have been loaded for a
+		  zone the first time, the repository will be searched
+		  for changes periodically, regardless of whether
+		  <command>rndc loadkeys</command> is used.  The recheck
+		  interval is defined by
+		  <command>dnssec-loadkeys-interval</command>.)
+		</para>
+		<para>
+		  The default setting is <command>auto-dnssec off</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>dnssec-enable</command></term>
+	      <listitem>
+		<para>
+		  This indicates whether DNSSEC-related resource
+		  records are to be returned by <command>named</command>.
+		  If set to <userinput>no</userinput>,
+		  <command>named</command> will not return DNSSEC-related
+		  resource records unless specifically queried for.
+		  The default is <userinput>yes</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>dnssec-validation</command></term>
+	      <listitem>
+		<para>
+		  Enable DNSSEC validation in <command>named</command>.
+		  Note <command>dnssec-enable</command> also needs to be
+		  set to <userinput>yes</userinput> to be effective.
+		  If set to <userinput>no</userinput>, DNSSEC validation
+		  is disabled.
+		</para>
+	        <para>
+		  If set to <userinput>auto</userinput>, DNSSEC validation
+		  is enabled, and a default trust anchor for the DNS root
+		  zone is used.  If set to <userinput>yes</userinput>,
+		  DNSSEC validation is enabled, but a trust anchor must be
+		  manually configured using a <command>trusted-keys</command>
+		  or <command>managed-keys</command> statement.  The default
+		  is <userinput>yes</userinput>.
+		</para>
+		<para>
+		  The default root trust anchor is stored in the file
+		  <filename>bind.keys</filename>.
+		  <command>named</command> will load that key at
+		  startup if <command>dnssec-validation</command> is
+		  set to <constant>auto</constant>.  A copy of the file is
+		  installed along with BIND 9, and is current as of the
+		  release date.  If the root key expires, a new copy of
+		  <filename>bind.keys</filename> can be downloaded
+		  from <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.isc.org/bind-keys">https://www.isc.org/bind-keys</link>.
+		</para>
+		<para>
+		  To prevent problems if <filename>bind.keys</filename> is
+		  not found, the current trust anchor is also compiled in
+		  to <command>named</command>.  Relying on this is not
+		  recommended, however, as it requires <command>named</command>
+		  to be recompiled with a new key when the root key expires.)
+		</para>
+		<note>
+		  <para>
+		    <command>named</command> <emphasis>only</emphasis>
+		    loads the root key from <filename>bind.keys</filename>.
+		    The file cannot be used to store keys for other zones.
+		    The root key in <filename>bind.keys</filename> is ignored
+		    if <command>dnssec-validation auto</command> is not in
+		    use.
+		  </para>
+		  <para>
+		    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
+		    <command>dnssec-validation</command> is off.
+		  </para>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>dnssec-accept-expired</command></term>
+	      <listitem>
+		<para>
+		  Accept expired signatures when verifying DNSSEC signatures.
+		  The default is <userinput>no</userinput>.
+		  Setting this option to <userinput>yes</userinput>
+		  leaves <command>named</command> vulnerable to
+		  replay attacks.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>querylog</command></term>
+	      <listitem>
+		<para>
+		  Specify whether query logging should be started when <command>named</command>
+		  starts.
+		  If <command>querylog</command> is not specified,
+		  then the query logging
+		  is determined by the presence of the logging category <command>queries</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-names</command></term>
+	      <listitem>
+		<para>
+		  This option is used to restrict the character set and syntax
+		  of
+		  certain domain names in master files and/or DNS responses
+		  received
+		  from the network.  The default varies according to usage
+		  area.  For
+		  <command>master</command> zones the default is <command>fail</command>.
+		  For <command>slave</command> zones the default
+		  is <command>warn</command>.
+		  For answers received from the network (<command>response</command>)
+		  the default is <command>ignore</command>.
+		</para>
+		<para>
+		  The rules for legal hostnames and mail domains are derived
+		  from RFC 952 and RFC 821 as modified by RFC 1123.
+		</para>
+		<para><command>check-names</command>
+		  applies to the owner names of A, AAAA and MX records.
+		  It also applies to the domain names in the RDATA of NS, SOA,
+		  MX, and SRV records.
+		  It also applies to the RDATA of PTR records where the owner
+		  name indicated that it is a reverse lookup of a hostname
+		  (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-dup-records</command></term>
+	      <listitem>
+		<para>
+		  Check master zones for records that are treated as different
+		  by DNSSEC but are semantically equal in plain DNS.  The
+		  default is to <command>warn</command>.  Other possible
+		  values are <command>fail</command> and
+		  <command>ignore</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-mx</command></term>
+	      <listitem>
+		<para>
+		  Check whether the MX record appears to refer to a IP address.
+		  The default is to <command>warn</command>.  Other possible
+		  values are <command>fail</command> and
+		  <command>ignore</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-wildcard</command></term>
+	      <listitem>
+		<para>
+		  This option is used to check for non-terminal wildcards.
+		  The use of non-terminal wildcards is almost always as a
+		  result of a failure
+		  to understand the wildcard matching algorithm (RFC 1034).
+		  This option
+		  affects master zones.  The default (<command>yes</command>) is to check
+		  for non-terminal wildcards and issue a warning.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-integrity</command></term>
+	      <listitem>
+		<para>
+		  Perform post load zone integrity checks on master
+		  zones.  This checks that MX and SRV records refer
+		  to address (A or AAAA) records and that glue
+		  address records exist for delegated zones.  For
+		  MX and SRV records only in-zone hostnames are
+		  checked (for out-of-zone hostnames use
+		  <command>named-checkzone</command>).
+		  For NS records only names below top of zone are
+		  checked (for out-of-zone names and glue consistency
+		  checks use <command>named-checkzone</command>).
+		  The default is <command>yes</command>.
+		</para>
+		<para>
+		  The use of the SPF record for publishing Sender
+		  Policy Framework is deprecated as the migration
+		  from using TXT records to SPF records was abandoned.
+		  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
+		  <command>check-spf</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-mx-cname</command></term>
+	      <listitem>
+		<para>
+		  If <command>check-integrity</command> is set then
+		  fail, warn or ignore MX records that refer
+		  to CNAMES.  The default is to <command>warn</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-srv-cname</command></term>
+	      <listitem>
+		<para>
+		  If <command>check-integrity</command> is set then
+		  fail, warn or ignore SRV records that refer
+		  to CNAMES.  The default is to <command>warn</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-sibling</command></term>
+	      <listitem>
+		<para>
+		  When performing integrity checks, also check that
+		  sibling glue exists.  The default is <command>yes</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>check-spf</command></term>
+	      <listitem>
+		<para>
+		  If <command>check-integrity</command> is set then
+		  check that there is a TXT Sender Policy Framework
+		  record present (starts with "v=spf1") if there is an
+		  SPF record present. The default is
+		  <command>warn</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>zero-no-soa-ttl</command></term>
+	      <listitem>
+		<para>
+		  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 <command>yes</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>zero-no-soa-ttl-cache</command></term>
+	      <listitem>
+		<para>
+		  When caching a negative response to a SOA query
+		  set the TTL to zero.
+		  The default is <command>no</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>update-check-ksk</command></term>
+	      <listitem>
+		<para>
+		  When set to the default value of <literal>yes</literal>,
+		  check the KSK bit in each key to determine how the key
+		  should be used when generating RRSIGs for a secure zone.
+		</para>
+		<para>
+		  Ordinarily, zone-signing keys (that is, keys without the
+		  KSK bit set) are used to sign the entire zone, while
+		  key-signing keys (keys with the KSK bit set) are only
+		  used to sign the DNSKEY RRset at the zone apex.
+		  However, if this option is set to <literal>no</literal>,
+		  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 <command>dnssec-signzone -z</command>
+		  command line option.
+		</para>
+		<para>
+		  When this option is set to <literal>yes</literal>, there
+		  must be at least two active keys for every algorithm
+		  represented in the DNSKEY RRset: at least one KSK and one
+		  ZSK per algorithm.  If there is any algorithm for which
+		  this requirement is not met, this option will be ignored
+		  for that algorithm.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>dnssec-dnskey-kskonly</command></term>
+	      <listitem>
+		<para>
+		  When this option and <command>update-check-ksk</command>
+		  are both set to <literal>yes</literal>, only key-signing
+		  keys (that is, keys with the KSK bit set) will be used
+		  to sign the DNSKEY RRset at the zone apex.  Zone-signing
+		  keys (keys without the KSK bit set) will be used to sign
+		  the remainder of the zone, but not the DNSKEY RRset.
+		  This is similar to the
+		  <command>dnssec-signzone -x</command> command line option.
+		</para>
+		<para>
+		  The default is <command>no</command>.  If
+		  <command>update-check-ksk</command> is set to
+		  <literal>no</literal>, this option is ignored.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>try-tcp-refresh</command></term>
+	      <listitem>
+		<para>
+		  Try to refresh the zone using TCP if UDP queries fail.
+		  For BIND 8 compatibility, the default is
+		  <command>yes</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>dnssec-secure-to-insecure</command></term>
+	      <listitem>
+		<para>
+		  Allow a dynamic zone to transition from secure to
+		  insecure (i.e., signed to unsigned) by deleting all
+		  of the DNSKEY records.  The default is <command>no</command>.
+		  If set to <command>yes</command>, and if the DNSKEY RRset
+		  at the zone apex is deleted, all RRSIG and NSEC records
+		  will be removed from the zone as well.
+		</para>
+		<para>
+		  If the zone uses NSEC3, then it is also necessary to
+		  delete the NSEC3PARAM RRset from the zone apex; this will
+		  cause the removal of all corresponding NSEC3 records.
+		  (It is expected that this requirement will be eliminated
+		  in a future release.)
+		</para>
+		<para>
+		  Note that if a zone has been configured with
+		  <command>auto-dnssec maintain</command> and the
+		  private keys remain accessible in the key repository,
+		  then the zone will be automatically signed again the
+		  next time <command>named</command> is started.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="forwarding"><info><title>Forwarding</title></info>
+
+	  <para>
+	    The forwarding facility can be used to create a large site-wide
+	    cache on a few servers, reducing traffic over links to external
+	    name servers. It can also be used to allow queries by servers that
+	    do not have direct access to the Internet, but wish to look up
+	    exterior
+	    names anyway. Forwarding occurs only on those queries for which
+	    the server is not authoritative and does not have the answer in
+	    its cache.
+	  </para>
+
+	  <variablelist>
+	    <varlistentry>
+	      <term><command>forward</command></term>
+	      <listitem>
+		<para>
+		  This option is only meaningful if the
+		  forwarders list is not empty. A value of <varname>first</varname>,
+		  the default, causes the server to query the forwarders
+		  first — and
+		  if that doesn't answer the question, the server will then
+		  look for
+		  the answer itself. If <varname>only</varname> is
+		  specified, the
+		  server will only query the forwarders.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>forwarders</command></term>
+	      <listitem>
+		<para>
+		  Specifies the IP addresses to be used
+		  for forwarding. The default is the empty list (no
+		  forwarding).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+
+	  <para>
+	    Forwarding can also be configured on a per-domain basis, allowing
+	    for the global forwarding options to be overridden in a variety
+	    of ways. You can set particular domains to use different
+	    forwarders,
+	    or have a different <command>forward only/first</command> behavior,
+	    or not forward at all, see <xref linkend="zone_statement_grammar"/>.
+	  </para>
+	</section>
+
+	<section xml:id="dual_stack"><info><title>Dual-stack Servers</title></info>
+
+	  <para>
+	    Dual-stack servers are used as servers of last resort to work
+	    around
+	    problems in reachability due the lack of support for either IPv4
+	    or IPv6
+	    on the host machine.
+	  </para>
+
+	  <variablelist>
+	    <varlistentry>
+	      <term><command>dual-stack-servers</command></term>
+	      <listitem>
+		<para>
+		  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 <command>dual-stack-servers</command> have no effect unless
+		  access to a transport has been disabled on the command line
+		  (e.g. <command>named -4</command>).
+		</para>
+	      </listitem>
+	    </varlistentry>
+	  </variablelist>
+	</section>
+
+	<section xml:id="access_control"><info><title>Access Control</title></info>
+
+
+	  <para>
+	    Access to the server can be restricted based on the IP address
+	    of the requesting system. See <xref linkend="address_match_lists"/> for
+	    details on how to specify IP address lists.
+	  </para>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>allow-notify</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to
+		  notify this server, a slave, of zone changes in addition
+		  to the zone masters.
+		  <command>allow-notify</command> may also be
+		  specified in the
+		  <command>zone</command> statement, in which case
+		  it overrides the
+		  <command>options allow-notify</command>
+		  statement.  It is only meaningful
+		  for a slave zone.  If not specified, the default is to
+		  process notify messages
+		  only from a zone's master.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-query</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to ask ordinary
+		  DNS questions. <command>allow-query</command> may
+		  also be specified in the <command>zone</command>
+		  statement, in which case it overrides the
+		  <command>options allow-query</command> statement.
+		  If not specified, the default is to allow queries
+		  from all hosts.
+		</para>
+		<note>
+		  <para>
+		    <command>allow-query-cache</command> is now
+		    used to specify access to the cache.
+		  </para>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-query-on</command></term>
+	      <listitem>
+		<para>
+		  Specifies which local addresses can accept ordinary
+		  DNS questions. This makes it possible, for instance,
+		  to allow queries on internal-facing interfaces but
+		  disallow them on external-facing ones, without
+		  necessarily knowing the internal network's addresses.
+		</para>
+		<para>
+		  Note that <command>allow-query-on</command> is only
+		  checked for queries that are permitted by
+		  <command>allow-query</command>.  A query must be
+		  allowed by both ACLs, or it will be refused.
+		</para>
+		<para>
+		  <command>allow-query-on</command> may
+		  also be specified in the <command>zone</command>
+		  statement, in which case it overrides the
+		  <command>options allow-query-on</command> statement.
+		</para>
+		<para>
+		  If not specified, the default is to allow queries
+		  on all addresses.
+		</para>
+		<note>
+		  <para>
+		    <command>allow-query-cache</command> is
+		    used to specify access to the cache.
+		  </para>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-query-cache</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to get answers
+		  from the cache.  If <command>allow-query-cache</command>
+		  is not set then <command>allow-recursion</command>
+		  is used if set, otherwise <command>allow-query</command>
+		  is used if set unless <command>recursion no;</command> is
+		  set in which case <command>none;</command> is used,
+		  otherwise the default (<command>localnets;</command>
+		  <command>localhost;</command>) is used.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-query-cache-on</command></term>
+	      <listitem>
+		<para>
+		  Specifies which local addresses can give answers
+		  from the cache.  If not specified, the default is
+		  to allow cache queries on any address,
+		  <command>localnets</command> and
+		  <command>localhost</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-recursion</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to make recursive
+		  queries through this server. If
+		  <command>allow-recursion</command> is not set
+		  then <command>allow-query-cache</command> is
+		  used if set, otherwise <command>allow-query</command>
+		  is used if set, otherwise the default
+		  (<command>localnets;</command>
+		  <command>localhost;</command>) is used.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-recursion-on</command></term>
+	      <listitem>
+		<para>
+		  Specifies which local addresses can accept recursive
+		  queries.  If not specified, the default is to allow
+		  recursive queries on all addresses.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-update</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to
+		  submit Dynamic DNS updates for master zones. The default is
+		  to deny
+		  updates from all hosts.  Note that allowing updates based
+		  on the requestor's IP address is insecure; see
+		  <xref linkend="dynamic_update_security"/> for details.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-update-forwarding</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to
+		  submit Dynamic DNS updates to slave zones to be forwarded to
+		  the
+		  master.  The default is <userinput>{ none; }</userinput>,
+		  which
+		  means that no update forwarding will be performed.  To
+		  enable
+		  update forwarding, specify
+		  <userinput>allow-update-forwarding { any; };</userinput>.
+		  Specifying values other than <userinput>{ none; }</userinput> or
+		  <userinput>{ any; }</userinput> is usually
+		  counterproductive, since
+		  the responsibility for update access control should rest
+		  with the
+		  master server, not the slaves.
+		</para>
+		<para>
+		  Note that enabling the update forwarding feature on a slave
+		  server
+		  may expose master servers relying on insecure IP address
+		  based
+		  access control to attacks; see <xref linkend="dynamic_update_security"/>
+		  for more details.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-v6-synthesis</command></term>
+	      <listitem>
+		<para>
+		  This option was introduced for the smooth transition from
+		  AAAA
+		  to A6 and from "nibble labels" to binary labels.
+		  However, since both A6 and binary labels were then
+		  deprecated,
+		  this option was also deprecated.
+		  It is now ignored with some warning messages.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>allow-transfer</command></term>
+	      <listitem>
+		<para>
+		  Specifies which hosts are allowed to
+		  receive zone transfers from the server. <command>allow-transfer</command> may
+		  also be specified in the <command>zone</command>
+		  statement, in which
+		  case it overrides the <command>options allow-transfer</command> statement.
+		  If not specified, the default is to allow transfers to all
+		  hosts.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>blackhole</command></term>
+	      <listitem>
+		<para>
+		  Specifies a list of addresses that the
+		  server will not accept queries from or use to resolve a
+		  query. Queries
+		  from these addresses will not be responded to. The default
+		  is <userinput>none</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>filter-aaaa</command></term>
+	      <listitem>
+		<para>
+		  Specifies a list of addresses to which
+		  <command>filter-aaaa-on-v4</command>
+		  and <command>filter-aaaa-on-v6</command>
+		  apply.  The default is <userinput>any</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>keep-response-order</command></term>
+	      <listitem>
+		<para>
+		  Specifies a list of addresses to which the server
+		  will send responses to TCP queries in the same order
+		  in which they were received.  This disables the
+		  processing of TCP queries in parallel. The default
+		  is <userinput>none</userinput>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>no-case-compress</command></term> <listitem>
+		<para>
+		  Specifies a list of addresses which require responses
+		  to use case-insensitive compression.  This ACL can be
+		  used when <command>named</command> needs to work with
+		  clients that do not comply with the requirement in RFC
+		  1034 to use case-insensitive name comparisons when
+		  checking for matching domain names.
+		</para>
+		<para>
+		  If left undefined, the ACL defaults to
+		  <command>none</command>: case-insensitive compression
+		  will be used for all clients.  If the ACL is defined and
+		  matches a client, then case will be ignored when
+		  compressing domain names in DNS responses sent to that
+		  client.
+		</para>
+		<para>
+		  This can result in slightly smaller responses: if
+		  a response contains the names "example.com" and
+		  "example.COM", case-insensitive compression would treat
+		  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
+		  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.
+		</para>
+		<para>
+		  Case-insensitive compression is <emphasis>always</emphasis>
+		  used in AXFR and IXFR responses, regardless of whether
+		  the client matches this ACL.
+		</para>
+		<para>
+		  There are circumstances in which <command>named</command>
+		  will 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 <emphasis>first</emphasis> 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
+		  have their case preserved unless the client matches this
+		  ACL.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>resolver-query-timeout</command></term>
+	      <listitem>
+		<para>
+		  The amount of time in seconds that the resolver
+		  will spend attempting to resolve a recursive
+		  query before failing.  The default and minimum
+		  is <literal>10</literal> and the maximum is
+		  <literal>30</literal>.  Setting it to
+		  <literal>0</literal> will result in the default
+		  being used.
+		</para>
+	      </listitem>
+	    </varlistentry>
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="interfaces"><info><title>Interfaces</title></info>
+
+	  <para>
+	    The interfaces and ports that the server will answer queries
+	    from may be specified using the <command>listen-on</command> option. <command>listen-on</command> takes
+	    an optional port and an <varname>address_match_list</varname>
+	    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.
+	  </para>
+	  <para>
+	    Multiple <command>listen-on</command> statements are
+	    allowed.
+	    For example,
+	  </para>
+
+<programlisting>listen-on { 5.6.7.8; };
+listen-on port 1234 { !1.2.3.4; 1.2/16; };
+</programlisting>
+
+	  <para>
+	    will enable the name server on port 53 for the IP address
+	    5.6.7.8, and on port 1234 of an address on the machine in net
+	    1.2 that is not 1.2.3.4.
+	  </para>
+
+	  <para>
+	    If no <command>listen-on</command> is specified, the
+	    server will listen on port 53 on all IPv4 interfaces.
+	  </para>
+
+	  <para>
+	    The <command>listen-on-v6</command> 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.
+	  </para>
+
+	  <para>
+	    When <programlisting>{ any; }</programlisting> is
+	    specified
+	    as the <varname>address_match_list</varname> for the
+	    <command>listen-on-v6</command> option,
+	    the server does not bind a separate socket to each IPv6 interface
+	    address as it does for IPv4 if the operating system has enough API
+	    support for IPv6 (specifically if it conforms to RFC 3493 and RFC
+	    3542).
+	    Instead, it listens on the IPv6 wildcard address.
+	    If the system only has incomplete API support for IPv6, however,
+	    the behavior is the same as that for IPv4.
+	  </para>
+
+	  <para>
+	    A list of particular IPv6 addresses can also be specified, in
+	    which case
+	    the server listens on a separate socket for each specified
+	    address,
+	    regardless of whether the desired API is supported by the system.
+	    IPv4 addresses specified in <command>listen-on-v6</command>
+	    will be ignored, with a logged warning.
+	  </para>
+
+	  <para>
+	    Multiple <command>listen-on-v6</command> options can
+	    be used.
+	    For example,
+	  </para>
+
+<programlisting>listen-on-v6 { any; };
+listen-on-v6 port 1234 { !2001:db8::/32; any; };
+</programlisting>
+
+	  <para>
+	    will enable the name server on port 53 for any IPv6 addresses
+	    (with a single wildcard socket),
+	    and on port 1234 of IPv6 addresses that is not in the prefix
+	    2001:db8::/32 (with separate sockets for each matched address.)
+	  </para>
+
+	  <para>
+	    To make the server not listen on any IPv6 address, use
+	  </para>
+
+<programlisting>listen-on-v6 { none; };
+</programlisting>
+
+	</section>
+
+	<section xml:id="query_address"><info><title>Query Address</title></info>
+
+	  <para>
+	    If the server doesn't know the answer to a question, it will
+	    query other name servers. <command>query-source</command> specifies
+	    the address and port used for such queries. For queries sent over
+	    IPv6, there is a separate <command>query-source-v6</command> option.
+	    If <command>address</command> is <command>*</command> (asterisk) or is omitted,
+	    a wildcard IP address (<command>INADDR_ANY</command>)
+	    will be used.
+	  </para>
+
+	  <para>
+	    If <command>port</command> is <command>*</command> or is omitted,
+	    a random port number from a pre-configured
+	    range is picked up and will be used for each query.
+	    The port range(s) is that specified in
+	    the <command>use-v4-udp-ports</command> (for IPv4)
+	    and <command>use-v6-udp-ports</command> (for IPv6)
+	    options, excluding the ranges specified in
+	    the <command>avoid-v4-udp-ports</command>
+	    and <command>avoid-v6-udp-ports</command> options, respectively.
+	  </para>
+
+	  <para>
+	    The defaults of the <command>query-source</command> and
+	    <command>query-source-v6</command> options
+	    are:
+	  </para>
+
+<programlisting>query-source address * port *;
+query-source-v6 address * port *;
+</programlisting>
+
+	  <para>
+	    If <command>use-v4-udp-ports</command> or
+	    <command>use-v6-udp-ports</command> is unspecified,
+	    <command>named</command> will check if the operating
+	    system provides a programming interface to retrieve the
+	    system's default range for ephemeral ports.
+	    If such an interface is available,
+	    <command>named</command> will use the corresponding system
+	    default range; otherwise, it will use its own defaults:
+	 </para>
+
+<programlisting>use-v4-udp-ports { range 1024 65535; };
+use-v6-udp-ports { range 1024 65535; };
+</programlisting>
+
+	  <para>
+	    Note: make sure the ranges be sufficiently large for
+	    security.  A desirable size depends on various parameters,
+	    but we generally recommend it contain at least 16384 ports
+	    (14 bits of entropy).
+	    Note also that the system's default range when used may be
+	    too small for this purpose, and that the range may even be
+	    changed while <command>named</command> is running; the new
+	    range will automatically be applied when <command>named</command>
+	    is reloaded.
+	    It is encouraged to
+	    configure <command>use-v4-udp-ports</command> and
+	    <command>use-v6-udp-ports</command> explicitly so that the
+	    ranges are sufficiently large and are reasonably
+	    independent from the ranges used by other applications.
+	  </para>
+
+	  <para>
+	    Note: the operational configuration
+	    where <command>named</command> runs may prohibit the use
+	    of some ports.  For example, UNIX systems will not allow
+	    <command>named</command> running without a root privilege
+	    to use ports less than 1024.
+	    If such ports are included in the specified (or detected)
+	    set of query ports, the corresponding query attempts will
+	    fail, resulting in resolution failures or delay.
+	    It is therefore important to configure the set of ports
+	    that can be safely used in the expected operational environment.
+	  </para>
+
+	  <para>
+	    The defaults of the <command>avoid-v4-udp-ports</command> and
+	    <command>avoid-v6-udp-ports</command> options
+	    are:
+	  </para>
+
+<programlisting>avoid-v4-udp-ports {};
+avoid-v6-udp-ports {};
+</programlisting>
+
+	  <para>
+	    Note: BIND 9.5.0 introduced
+	    the <command>use-queryport-pool</command>
+	    option to support a pool of such random ports, but this
+	    option is now obsolete because reusing the same ports in
+	    the pool may not be sufficiently secure.
+	    For the same reason, it is generally strongly discouraged to
+	    specify a particular port for the
+	    <command>query-source</command> or
+	    <command>query-source-v6</command> options;
+	    it implicitly disables the use of randomized port numbers.
+	  </para>
+
+	  <variablelist>
+	    <varlistentry>
+	      <term><command>use-queryport-pool</command></term>
+	      <listitem>
+		<para>
+		  This option is obsolete.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>queryport-pool-ports</command></term>
+	      <listitem>
+		<para>
+		  This option is obsolete.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>queryport-pool-updateinterval</command></term>
+	      <listitem>
+		<para>
+		  This option is obsolete.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+	  <note>
+	    <para>
+	      The address specified in the <command>query-source</command> option
+	      is used for both UDP and TCP queries, but the port applies only
+	      to UDP queries.  TCP queries always use a random
+	      unprivileged port.
+	    </para>
+	  </note>
+	  <note>
+	    <para>
+	      Solaris 2.5.1 and earlier does not support setting the source
+	      address for TCP sockets.
+	    </para>
+	  </note>
+	  <note>
+	    <para>
+	      See also <command>transfer-source</command> and
+	      <command>notify-source</command>.
+	    </para>
+	  </note>
+	</section>
+
+	<section xml:id="zone_transfers"><info><title>Zone Transfers</title></info>
+
+	  <para>
+	    <acronym>BIND</acronym> has mechanisms in place to
+	    facilitate zone transfers
+	    and set limits on the amount of load that transfers place on the
+	    system. The following options apply to zone transfers.
+	  </para>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>also-notify</command></term>
+	      <listitem>
+		<para>
+		  Defines a global list of IP addresses of name servers
+		  that are also sent NOTIFY messages whenever a fresh copy of
+		  the
+		  zone is loaded, in addition to the servers listed in the
+		  zone's NS records.
+		  This helps to ensure that copies of the zones will
+		  quickly converge on stealth servers.
+		  Optionally, a port may be specified with each
+		  <command>also-notify</command> address to send
+		  the notify messages to a port other than the
+		  default of 53.
+		  An optional TSIG key can also be specified with each
+		  address to cause the notify messages to be signed; this
+		  can be useful when sending notifies to multiple views.
+		  In place of explicit addresses, one or more named
+		  <command>masters</command> lists can be used.
+		</para>
+		<para>
+		  If an <command>also-notify</command> list
+		  is given in a <command>zone</command> statement,
+		  it will override
+		  the <command>options also-notify</command>
+		  statement. When a <command>zone notify</command>
+		  statement
+		  is set to <command>no</command>, the IP
+		  addresses in the global <command>also-notify</command> list will
+		  not be sent NOTIFY messages for that zone. The default is
+		  the empty
+		  list (no global notification list).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-transfer-time-in</command></term>
+	      <listitem>
+		<para>
+		  Inbound zone transfers running longer than
+		  this many minutes will be terminated. The default is 120
+		  minutes
+		  (2 hours).  The maximum value is 28 days (40320 minutes).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-transfer-idle-in</command></term>
+	      <listitem>
+		<para>
+		  Inbound zone transfers making no progress
+		  in this many minutes will be terminated. The default is 60
+		  minutes
+		  (1 hour).  The maximum value is 28 days (40320 minutes).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-transfer-time-out</command></term>
+	      <listitem>
+		<para>
+		  Outbound zone transfers running longer than
+		  this many minutes will be terminated. The default is 120
+		  minutes
+		  (2 hours).  The maximum value is 28 days (40320 minutes).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-transfer-idle-out</command></term>
+	      <listitem>
+		<para>
+		  Outbound zone transfers making no progress
+		  in this many minutes will be terminated.  The default is 60
+		  minutes (1
+		  hour).  The maximum value is 28 days (40320 minutes).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>notify-rate</command></term>
+	      <listitem>
+		<para>
+		  The rate at which NOTIFY requests will be 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.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>startup-notify-rate</command></term>
+	      <listitem>
+		<para>
+		  The rate at which NOTIFY requests will be sent
+		  when the name server is first starting up, or when
+		  zones have been newly added to the nameserver.
+		  The default is 20 per second.
+		  The lowest possible rate is one per second; when set
+		  to zero, it will be silently raised to one.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>serial-query-rate</command></term>
+	      <listitem>
+		<para>
+		  Slave servers will periodically query master
+		  servers to find out if zone serial numbers have
+		  changed. Each such query uses a minute amount of
+		  the slave server's network bandwidth.  To limit
+		  the amount of bandwidth used, BIND 9 limits the
+		  rate at which queries are sent.  The value of the
+		  <command>serial-query-rate</command> 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.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>serial-queries</command></term>
+	      <listitem>
+		<para>
+		  In BIND 8, the <command>serial-queries</command>
+		  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 <command>serial-queries</command> option.
+		  Instead, it limits the rate at which the queries are sent
+		  as defined using the <command>serial-query-rate</command> option.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>transfer-format</command></term>
+	      <listitem>
+
+		<para>
+		  Zone transfers can be sent using two different formats,
+		  <command>one-answer</command> and
+		  <command>many-answers</command>.
+		  The <command>transfer-format</command> option is used
+		  on the master server to determine which format it sends.
+		  <command>one-answer</command> uses one DNS message per
+		  resource record transferred.
+		  <command>many-answers</command> packs as many resource
+		  records as possible into a message.
+		  <command>many-answers</command> is more efficient, but is
+		  only supported by relatively new slave servers,
+		  such as <acronym>BIND</acronym> 9, <acronym>BIND</acronym>
+		  8.x and <acronym>BIND</acronym> 4.9.5 onwards.
+		  The <command>many-answers</command> format is also supported by
+		  recent Microsoft Windows nameservers.
+		  The default is <command>many-answers</command>.
+		  <command>transfer-format</command> may be overridden on a
+		  per-server basis by using the <command>server</command>
+		  statement.
+		</para>
+
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>transfer-message-size</command></term>
+	      <listitem>
+		<para>
+		  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
+		  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
+		  fit within the size limit, a larger message will be
+		  permitted so the record can be transferred.)
+		</para>
+		<para>
+		  Valid values are between 512 and 65535 octets, and any
+		  values outside that range will be adjusted to the nearest
+		  value within it.  The default is <literal>20480</literal>,
+		  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
+		  compression offset pointer in a DNS message.
+		</para>
+		<para>
+		  This option is mainly intended for server testing;
+		  there is rarely any benefit in setting a value other
+		  than the default.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>transfers-in</command></term>
+	      <listitem>
+		<para>
+		  The maximum number of inbound zone transfers
+		  that can be running concurrently. The default value is <literal>10</literal>.
+		  Increasing <command>transfers-in</command> may
+		  speed up the convergence
+		  of slave zones, but it also may increase the load on the
+		  local system.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>transfers-out</command></term>
+	      <listitem>
+		<para>
+		  The maximum number of outbound zone transfers
+		  that can be running concurrently. Zone transfer requests in
+		  excess
+		  of the limit will be refused. The default value is <literal>10</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>transfers-per-ns</command></term>
+	      <listitem>
+		<para>
+		  The maximum number of inbound zone transfers
+		  that can be concurrently transferring from a given remote
+		  name server.
+		  The default value is <literal>2</literal>.
+		  Increasing <command>transfers-per-ns</command>
+		  may
+		  speed up the convergence of slave zones, but it also may
+		  increase
+		  the load on the remote name server. <command>transfers-per-ns</command> may
+		  be overridden on a per-server basis by using the <command>transfers</command> phrase
+		  of the <command>server</command> statement.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>transfer-source</command></term>
+	      <listitem>
+		<para><command>transfer-source</command>
+		  determines which local address will be bound to IPv4
+		  TCP connections used to fetch zones transferred
+		  inbound by the server.  It also determines the
+		  source IPv4 address, and optionally the UDP port,
+		  used for the refresh queries and forwarded dynamic
+		  updates.  If not set, it defaults to a system
+		  controlled value which will usually be the address
+		  of the interface "closest to" the remote end. This
+		  address must appear in the remote end's
+		  <command>allow-transfer</command> option for the
+		  zone being transferred, if one is specified. This
+		  statement sets the
+		  <command>transfer-source</command> for all zones,
+		  but can be overridden on a per-view or per-zone
+		  basis by including a
+		  <command>transfer-source</command> statement within
+		  the <command>view</command> or
+		  <command>zone</command> block in the configuration
+		  file.
+		</para>
+		<note>
+		  <para>
+		    Solaris 2.5.1 and earlier does not support setting the
+		    source address for TCP sockets.
+		  </para>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>transfer-source-v6</command></term>
+	      <listitem>
+		<para>
+		  The same as <command>transfer-source</command>,
+		  except zone transfers are performed using IPv6.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>alt-transfer-source</command></term>
+	      <listitem>
+		<para>
+		  An alternate transfer source if the one listed in
+		  <command>transfer-source</command> fails and
+		  <command>use-alt-transfer-source</command> is
+		  set.
+		</para>
+		<note><simpara>
+		  If you do not wish the alternate transfer source
+		  to be used, you should set
+		  <command>use-alt-transfer-source</command>
+		  appropriately and you should not depend upon
+		  getting an answer back to the first refresh
+		  query.
+		</simpara></note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>alt-transfer-source-v6</command></term>
+	      <listitem>
+		<para>
+		  An alternate transfer source if the one listed in
+		  <command>transfer-source-v6</command> fails and
+		  <command>use-alt-transfer-source</command> is
+		  set.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>use-alt-transfer-source</command></term>
+	      <listitem>
+		<para>
+		  Use the alternate transfer sources or not.  If views are
+		  specified this defaults to <command>no</command>
+		  otherwise it defaults to
+		  <command>yes</command> (for BIND 8
+		  compatibility).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>notify-source</command></term>
+	      <listitem>
+		<para><command>notify-source</command>
+		  determines which local source address, and
+		  optionally UDP port, will be used to send NOTIFY
+		  messages.  This address must appear in the slave
+		  server's <command>masters</command> zone clause or
+		  in an <command>allow-notify</command> clause.  This
+		  statement sets the <command>notify-source</command>
+		  for all zones, but can be overridden on a per-zone or
+		  per-view basis by including a
+		  <command>notify-source</command> statement within
+		  the <command>zone</command> or
+		  <command>view</command> block in the configuration
+		  file.
+		</para>
+		<note>
+		  <para>
+		    Solaris 2.5.1 and earlier does not support setting the
+		    source address for TCP sockets.
+		  </para>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>notify-source-v6</command></term>
+	      <listitem>
+		<para>
+		  Like <command>notify-source</command>,
+		  but applies to notify messages sent to IPv6 addresses.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="port_lists"><info><title>UDP Port Lists</title></info>
+
+	  <para>
+	    <command>use-v4-udp-ports</command>,
+	    <command>avoid-v4-udp-ports</command>,
+	    <command>use-v6-udp-ports</command>, and
+	    <command>avoid-v6-udp-ports</command>
+	    specify a list of IPv4 and IPv6 UDP ports that will be
+	    used or not used as source ports for UDP messages.
+	    See <xref linkend="query_address"/> about how the
+	    available ports are determined.
+	    For example, with the following configuration
+	  </para>
+
+<programlisting>
+use-v6-udp-ports { range 32768 65535; };
+avoid-v6-udp-ports { 40000; range 50000 60000; };
+</programlisting>
+
+	   <para>
+	     UDP ports of IPv6 messages sent
+	     from <command>named</command> will be in one
+	     of the following ranges: 32768 to 39999, 40001 to 49999,
+	     and 60001 to 65535.
+	   </para>
+
+	   <para>
+	     <command>avoid-v4-udp-ports</command> and
+	     <command>avoid-v6-udp-ports</command> can be used
+	     to prevent <command>named</command> from choosing as its random source port a
+	     port that is blocked by your firewall or a port that is
+	     used by other applications;
+	     if a query went out with a source port blocked by a
+	     firewall, the
+	     answer would not get by the firewall and the name server would
+	     have to query again.
+	     Note: the desired range can also be represented only with
+	     <command>use-v4-udp-ports</command> and
+	     <command>use-v6-udp-ports</command>, and the
+	     <command>avoid-</command> options are redundant in that
+	     sense; they are provided for backward compatibility and
+	     to possibly simplify the port specification.
+	   </para>
+	</section>
+
+	<section xml:id="resource_limits"><info><title>Operating System Resource Limits</title></info>
+
+	  <para>
+	    The server's usage of many system resources can be limited.
+	    Scaled values are allowed when specifying resource limits.  For
+	    example, <command>1G</command> can be used instead of
+	    <command>1073741824</command> to specify a limit of
+	    one
+	    gigabyte. <command>unlimited</command> requests
+	    unlimited use, or the
+	    maximum available amount. <command>default</command>
+	    uses the limit
+	    that was in force when the server was started. See the description
+	    of <command>size_spec</command> in <xref linkend="configuration_file_elements"/>.
+	  </para>
+
+	  <para>
+	    The following options set operating system resource limits for
+	    the name server process.  Some operating systems don't support
+	    some or
+	    any of the limits. On such systems, a warning will be issued if
+	    the
+	    unsupported limit is used.
+	  </para>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>coresize</command></term>
+	      <listitem>
+		<para>
+		  The maximum size of a core dump. The default
+		  is <literal>default</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>datasize</command></term>
+	      <listitem>
+		<para>
+		  The maximum amount of data memory the server
+		  may use. The default is <literal>default</literal>.
+		  This is a hard limit on server memory usage.
+		  If the server attempts to allocate memory in excess of this
+		  limit, the allocation will fail, which may in turn leave
+		  the server unable to perform DNS service.  Therefore,
+		  this option is rarely useful as a way of limiting the
+		  amount of memory used by the server, but it can be used
+		  to raise an operating system data size limit that is
+		  too small by default.  If you wish to limit the amount
+		  of memory used by the server, use the
+		  <command>max-cache-size</command> and
+		  <command>recursive-clients</command>
+		  options instead.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>files</command></term>
+	      <listitem>
+		<para>
+		  The maximum number of files the server
+		  may have open concurrently. The default is <literal>unlimited</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>stacksize</command></term>
+	      <listitem>
+		<para>
+		  The maximum amount of stack memory the server
+		  may use. The default is <literal>default</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="server_resource_limits"><info><title>Server  Resource Limits</title></info>
+
+	  <para>
+	    The following options set limits on the server's
+	    resource consumption that are enforced internally by the
+	    server rather than the operating system.
+	  </para>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>max-ixfr-log-size</command></term>
+	      <listitem>
+		<para>
+		  This option is obsolete; it is accepted
+		  and ignored for BIND 8 compatibility.  The option
+		  <command>max-journal-size</command> performs a
+		  similar function in BIND 9.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-journal-size</command></term>
+	      <listitem>
+		<para>
+		  Sets a maximum size for each journal file
+		  (see <xref linkend="journal"/>).  When the journal file
+		  approaches
+		  the specified size, some of the oldest transactions in the
+		  journal
+		  will be automatically removed.  The largest permitted
+		  value is 2 gigabytes. The default is
+		  <literal>unlimited</literal>, which also
+		  means 2 gigabytes.
+		  This may also be set on a per-zone basis.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-records</command></term>
+	      <listitem>
+		<para>
+		  The maximum number of records permitted in a zone.
+		  The default is zero which means unlimited.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>host-statistics-max</command></term>
+	      <listitem>
+		<para>
+		  In BIND 8, specifies the maximum number of host statistics
+		  entries to be kept.
+		  Not implemented in BIND 9.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>recursive-clients</command></term>
+	      <listitem>
+		<para>
+		  The maximum number ("hard quota") of simultaneous
+		  recursive lookups the server will perform on behalf
+		  of clients.  The default is
+		  <literal>1000</literal>.  Because each recursing
+		  client uses a fair
+		  bit of memory (on the order of 20 kilobytes), the
+		  value of the
+		  <command>recursive-clients</command> option may
+		  have to be decreased on hosts with limited memory.
+		</para>
+		<para>
+		  <option>recursive-clients</option> defines a "hard
+		  quota" limit for pending recursive clients: when more
+		  clients than this are pending, new incoming requests
+		  will not be accepted, and for each incoming request
+		  a previous pending request will also be dropped.
+		</para>
+		<para>
+		  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.
+		  If <option>recursive-clients</option> is greater than
+		  1000, the soft quota is set to
+		  <option>recursive-clients</option> minus 100;
+		  otherwise it is set to 90% of
+		  <option>recursive-clients</option>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>tcp-clients</command></term>
+	      <listitem>
+		<para>
+		  The maximum number of simultaneous client TCP
+		  connections that the server will accept.
+		  The default is <literal>150</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry xml:id="clients-per-query">
+	      <term xml:id="cpq_term"><command>clients-per-query</command></term>
+	      <term><command>max-clients-per-query</command></term>
+	      <listitem>
+		<para>These set the
+		  initial value (minimum) and maximum number of recursive
+		  simultaneous clients for any given query
+		  (&lt;qname,qtype,qclass&gt;) that the server will accept
+		  before dropping additional clients.  <command>named</command> will attempt to
+		  self tune this value and changes will be logged.  The
+		  default values are 10 and 100.
+		</para>
+		<para>
+		  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, <command>named</command> will
+		  assume that it is dealing with a non-responsive zone
+		  and will drop additional queries.  If it gets a response
+		  after dropping queries, it will raise the estimate.  The
+		  estimate will then be lowered in 20 minutes if it has
+		  remained unchanged.
+		</para>
+		<para>
+		  If <command>clients-per-query</command> is set to zero,
+		  then there is no limit on the number of clients per query
+		  and no queries will be dropped.
+		</para>
+		<para>
+		  If <command>max-clients-per-query</command> is set to zero,
+		  then there is no upper bound other than imposed by
+		  <command>recursive-clients</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry xml:id="fetches-per-zone">
+	      <term><command>fetches-per-zone</command></term>
+	      <listitem>
+		<para>
+		  The maximum number of simultaneous iterative
+		  queries to any one domain that the server will
+		  permit 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
+		  would take to resolve them.  It should be smaller
+		  than <option>recursive-clients</option>.
+		</para>
+		<para>
+		  When many clients simultaneously query for the
+		  same name and type, the clients will all be attached
+		  to the same fetch, up to the
+		  <option>max-clients-per-query</option> limit,
+		  and only one iterative query will be sent.
+		  However, when clients are simultaneously
+		  querying for <emphasis>different</emphasis> names
+		  or types, multiple queries will be sent and
+		  <option>max-clients-per-query</option> is not
+		  effective as a limit.
+		</para>
+		<para>
+		  Optionally, this value may be followed by the keyword
+		  <literal>drop</literal> or <literal>fail</literal>,
+		  indicating whether queries which exceed the fetch
+		  quota for a zone will be dropped with no response,
+		  or answered with SERVFAIL.  The default is
+		  <literal>drop</literal>.
+		</para>
+		<para>
+		  If <command>fetches-per-zone</command> 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.
+		</para>
+		<para>
+		  The current list of active fetches can be dumped by
+		  running <command>rndc recursing</command>.  The list
+		  includes the number of active fetches for each
+		  domain and the number of queries that have been
+		  passed or dropped as a result of the
+		  <option>fetches-per-zone</option> limit.  (Note:
+		  these counters are not cumulative over time; whenever
+		  the number of active fetches for a domain drops to
+		  zero, the counter for that domain is deleted, and the
+		  next time a fetch is sent to that domain, it is
+		  recreated with the counters set to zero.)
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry xml:id="fetches-per-server">
+	      <term><command>fetches-per-server</command></term>
+	      <listitem>
+		<para>
+		  The maximum number of simultaneous iterative
+		  queries that the server will allow to be sent to
+		  a single upstream name server before blocking
+		  additional queries.
+		  This value should reflect how many fetches would
+		  normally be sent to any one server in the time it
+		  would take to resolve them.  It should be smaller
+		  than <option>recursive-clients</option>.
+		</para>
+		<para>
+		  Optionally, this value may be followed by the keyword
+		  <literal>drop</literal> or <literal>fail</literal>,
+		  indicating whether queries will be 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
+		  <literal>fail</literal>.
+		</para>
+		<para>
+		  If <command>fetches-per-server</command> 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.
+		</para>
+		<para>
+		  The <command>fetches-per-server</command> quota is
+		  dynamically adjusted in response to detected
+		  congestion. As queries are sent to a server
+		  and are either answered or time out, an
+		  exponentially weighted moving average is calculated
+		  of the ratio of timeouts to responses.  If the
+		  current average timeout ratio rises above a "high"
+		  threshold, then <command>fetches-per-server</command>
+		  is reduced for that server.  If the timeout ratio
+		  drops below a "low" threshold, then
+		  <command>fetches-per-server</command> is increased.
+		  The <command>fetch-quota-params</command> options
+		  can be used to adjust the parameters for this
+		  calculation.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>fetch-quota-params</command></term>
+	      <listitem>
+		<para>
+		  Sets the parameters to use for dynamic resizing of
+		  the <option>fetches-per-server</option> quota in
+		  response to detected congestion.
+		</para>
+		<para>
+		  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
+		  the average ratio after every 100 queries have either
+		  been answered or timed out.
+		</para>
+		<para>
+		  The remaining three arguments represent the "low"
+		  threshold (defaulting to a timeout ratio of 0.1),
+		  the "high" threshold (defaulting to a timeout
+		  ratio of 0.3), and the discount rate for
+		  the moving average (defaulting to 0.7).
+		  A higher discount rate causes recent events to
+		  weigh more heavily when calculating the moving
+		  average; a lower discount rate causes past
+		  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
+		  the decimal point are significant.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>reserved-sockets</command></term>
+	      <listitem>
+		<para>
+		  The number of file descriptors reserved for TCP, stdio,
+		  etc.  This needs to be big enough to cover the number of
+		  interfaces <command>named</command> listens on, <command>tcp-clients</command> as well as
+		  to provide room for outgoing TCP queries and incoming zone
+		  transfers.  The default is <literal>512</literal>.
+		  The minimum value is <literal>128</literal> and the
+		  maximum value is <literal>128</literal> less than
+		  maxsockets (-S).  This option may be removed in the future.
+		</para>
+		<para>
+		  This option has little effect on Windows.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-cache-size</command></term>
+	      <listitem>
+		<para>
+		  The maximum amount of memory to use for the
+		  server's cache, in bytes or % of total physical memory.
+		  When the amount of data in the cache
+		  reaches this limit, the server will cause records to
+		  expire prematurely based on an LRU based strategy so
+		  that the limit is not exceeded.
+		  The keyword <userinput>unlimited</userinput>,
+		  or the value 0, will place no limit on cache size;
+		  records will be purged from the cache only when their
+		  TTLs expire.
+		  Any positive values less than 2MB will be ignored
+		  and reset to 2MB.
+		  In a server with multiple views, the limit applies
+		  separately to the cache of each view.
+		  The default is <userinput>90%</userinput>.
+		  On systems where detection of amount of physical
+		  memory is not supported values represented as %
+		  fall back to unlimited.
+		  Note that the detection of physical memory is done only
+		  once at startup, so <command>named</command> will not
+		  adjust the cache size if the amount of physical memory
+		  is changed during runtime.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>tcp-listen-queue</command></term>
+	      <listitem>
+		<para>
+		  The listen queue depth.  The default and minimum is 10.
+		  If the kernel supports the accept filter "dataready" this
+		  also controls how
+		  many TCP connections that will be queued in kernel space
+		  waiting for
+		  some data before being passed to accept.  Nonzero values
+		  less than 10 will be silently raised. A value of 0 may also
+		  be used; on most platforms this sets the listen queue
+		  length to a system-defined default value.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="intervals"><info><title>Periodic Task Intervals</title></info>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>cleaning-interval</command></term>
+	      <listitem>
+		<para>
+		  This interval is effectively obsolete.  Previously,
+		  the server would remove expired resource records
+		  from the cache every <command>cleaning-interval</command> minutes.
+		  <acronym>BIND</acronym> 9 now manages cache
+		  memory in a more sophisticated manner and does not
+		  rely on the periodic cleaning any more.
+		  Specifying this option therefore has no effect on
+		  the server's behavior.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>heartbeat-interval</command></term>
+	      <listitem>
+		<para>
+		  The server will perform zone maintenance tasks
+		  for all zones marked as <command>dialup</command> 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.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>interface-interval</command></term>
+	      <listitem>
+		<para>
+		  The server will scan the network interface list
+		  every <command>interface-interval</command>
+		  minutes. The default
+		  is 60 minutes. The maximum value is 28 days (40320 minutes).
+		  If set to 0, interface scanning will only occur when
+		  the configuration file is  loaded. After the scan, the
+		  server will
+		  begin listening for queries on any newly discovered
+		  interfaces (provided they are allowed by the
+		  <command>listen-on</command> configuration), and
+		  will
+		  stop listening on interfaces that have gone away.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>statistics-interval</command></term>
+	      <listitem>
+		<para>
+		  Name server statistics will be logged
+		  every <command>statistics-interval</command>
+		  minutes. The default is
+		  60. The maximum value is 28 days (40320 minutes).
+		  If set to 0, no statistics will be logged.
+		  </para><note>
+		  <simpara>
+		    Not yet implemented in
+		    <acronym>BIND</acronym> 9.
+		  </simpara>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>topology</command></term>
+	      <listitem>
+		<para>
+		  In BIND 8, this option indicated network topology
+		  so that preferential treatment could be given to
+		  the topologicaly closest name servers when sending
+		  queries. It is not implemented in BIND 9.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="the_sortlist_statement"><info><title>The <command>sortlist</command> Statement</title></info>
+
+	  <para>
+	    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
+	    indeterminate order (but see the <command>rrset-order</command>
+	    statement in <xref linkend="rrset_ordering"/>).  The client
+	    resolver code should rearrange the RRs as appropriate, that is,
+	    using any addresses on the local net in preference to other
+	    addresses.  However, not all resolvers can do this or are
+	    correctly configured.  When a client is using a local server,
+	    the sorting can be performed in the server, based on the
+	    client's address. This only requires configuring the name
+	    servers, not all the clients.
+	  </para>
+
+	  <para>
+	    The <command>sortlist</command> statement (see below) takes an
+	    <command>address_match_list</command> and interprets it in a
+	    special way.  Each top level statement in the
+	    <command>sortlist</command> must itself be an explicit
+	    <command>address_match_list</command> with one or two elements.
+	    The first element (which may be an IP address, an IP prefix, an
+	    ACL name or a nested <command>address_match_list</command>) of
+	    each top level list is checked against the source address of
+	    the query until a match is found.
+	  </para>
+	  <para>
+	    Once the source address of the query has been matched, if the
+	    top level statement contains only one element, the actual
+	    primitive element that matched the source address is used to
+	    select the address in the response to move to the beginning of
+	    the response. If the statement is a list of two elements, then
+	    the second element is interpreted as a topology preference
+	    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.
+	  </para>
+	  <para>
+	    In the following example, any queries received from any of the
+	    addresses of the host itself will get responses preferring
+	    addresses on any of the locally connected networks. Next most
+	    preferred are addresses on the 192.168.1/24 network, and after
+	    that either the 192.168.2/24 or 192.168.3/24 network with no
+	    preference shown between these two networks. Queries received
+	    from a host on the 192.168.1/24 network will prefer other
+	    addresses on that network to the 192.168.2/24 and 192.168.3/24
+	    networks. Queries received from a host on the 192.168.4/24 or
+	    the 192.168.5/24 network will only prefer other addresses on
+	    their directly connected networks.
+	  </para>
+
+<programlisting>sortlist {
+    // IF the local host
+    // THEN first fit on the following nets
+    { localhost;
+	{ localnets;
+	    192.168.1/24;
+	    { 192.168.2/24; 192.168.3/24; }; }; };
+    // IF on class C 192.168.1 THEN use .1, or .2 or .3
+    { 192.168.1/24;
+	{ 192.168.1/24;
+	    { 192.168.2/24; 192.168.3/24; }; }; };
+    // IF on class C 192.168.2 THEN use .2, or .1 or .3
+    { 192.168.2/24;
+	{ 192.168.2/24;
+	    { 192.168.1/24; 192.168.3/24; }; }; };
+    // IF on class C 192.168.3 THEN use .3, or .1 or .2
+    { 192.168.3/24;
+	{ 192.168.3/24;
+	    { 192.168.1/24; 192.168.2/24; }; }; };
+    // IF .4 or .5 THEN prefer that net
+    { { 192.168.4/24; 192.168.5/24; };
+    };
+};</programlisting>
+
+	  <para>
+	    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
+	    <acronym>BIND</acronym> 4.9.x. Responses sent to queries from
+	    the local host will favor any of the directly connected
+	    networks. Responses sent to queries from any other hosts on a
+	    directly connected network will prefer addresses on that same
+	    network.  Responses to other queries will not be sorted.
+	  </para>
+
+<programlisting>sortlist {
+	   { localhost; localnets; };
+	   { localnets; };
+};
+</programlisting>
+
+	</section>
+	<section xml:id="rrset_ordering"><info><title xml:id="rrset_ordering_title">RRset Ordering</title></info>
+
+	  <para>
+	    When multiple records are returned in an answer it may be
+	    useful to configure the order of the records placed into the
+	    response.
+	    The <command>rrset-order</command> statement permits
+	    configuration
+	    of the ordering of the records in a multiple record response.
+	    See also the <command>sortlist</command> statement,
+	    <xref linkend="the_sortlist_statement"/>.
+	  </para>
+
+	  <para>
+	    An <command>order_spec</command> is defined as
+	    follows:
+	  </para>
+	  <para>
+	    <optional>class <replaceable>class_name</replaceable></optional>
+	    <optional>type <replaceable>type_name</replaceable></optional>
+	    <optional>name <replaceable>"domain_name"</replaceable></optional>
+	    order <replaceable>ordering</replaceable>
+	  </para>
+	  <para>
+	    If no class is specified, the default is <command>ANY</command>.
+	    If no type is specified, the default is <command>ANY</command>.
+	    If no name is specified, the default is "<command>*</command>" (asterisk).
+	  </para>
+	  <para>
+	    The legal values for <command>ordering</command> are:
+	  </para>
+	  <informaltable colsep="0" rowsep="0">
+	    <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+	      <colspec colname="1" colnum="1" colsep="0" colwidth="0.750in"/>
+	      <colspec colname="2" colnum="2" colsep="0" colwidth="3.750in"/>
+	      <tbody>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>fixed</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Records are returned in the order they
+		      are defined in the zone file.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>random</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Records are returned in some random order.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>cyclic</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Records are returned in a cyclic round-robin order.
+		    </para>
+		    <para>
+		      If <acronym>BIND</acronym> is configured with the
+		      "--enable-fixed-rrset" option at compile time, then
+		      the initial ordering of the RRset will match the
+		      one specified in the zone file.
+		    </para>
+		  </entry>
+		</row>
+	      </tbody>
+	    </tgroup>
+	  </informaltable>
+	  <para>
+	    For example:
+	  </para>
+
+<programlisting>rrset-order {
+   class IN type A name "host.example.com" order random;
+   order cyclic;
+};
+</programlisting>
+
+	  <para>
+	    will cause any responses for type A records in class IN that
+	    have "<literal>host.example.com</literal>" as a
+	    suffix, to always be returned
+	    in random order. All other records are returned in cyclic order.
+	  </para>
+	  <para>
+	    If multiple <command>rrset-order</command> statements
+	    appear, they are not combined — the last one applies.
+	  </para>
+	  <para>
+	    By default, all records are returned in random order.
+	  </para>
+
+	  <note>
+	    <simpara>
+	      In this release of <acronym>BIND</acronym> 9, the
+	      <command>rrset-order</command> statement does not support
+	      "fixed" ordering by default.  Fixed ordering can be enabled
+	      at compile time by specifying "--enable-fixed-rrset" on
+	      the "configure" command line.
+	    </simpara>
+	  </note>
+	</section>
+
+	<section xml:id="tuning"><info><title>Tuning</title></info>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>lame-ttl</command></term>
+	      <listitem>
+		<para>
+		  Sets the number of seconds to cache a
+		  lame server indication. 0 disables caching. (This is
+		  <emphasis role="bold">NOT</emphasis> recommended.)
+		  The default is <literal>600</literal> (10 minutes) and the
+		  maximum value is
+		  <literal>1800</literal> (30 minutes).
+		</para>
+
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>servfail-ttl</command></term>
+	      <listitem>
+		<para>
+		  Sets the number of seconds to cache a
+		  SERVFAIL response due to DNSSEC validation failure or
+		  other general server failure.  If set to
+		  <literal>0</literal>, SERVFAIL caching is disabled.
+		  The SERVFAIL cache is not consulted if a query has
+		  the CD (Checking Disabled) bit set; this allows a
+		  query that failed due to DNSSEC validation to be retried
+		  without waiting for the SERVFAIL TTL to expire.
+		</para>
+		<para>
+		  The maximum value is <literal>30</literal>
+		  seconds; any higher value will be silently
+		  reduced. The default is <literal>1</literal>
+		  second.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-ncache-ttl</command></term>
+	      <listitem>
+		<para>
+		  To reduce network traffic and increase performance,
+		  the server stores negative answers. <command>max-ncache-ttl</command> is
+		  used to set a maximum retention time for these answers in
+		  the server
+		  in seconds. The default
+		  <command>max-ncache-ttl</command> is <literal>10800</literal> seconds (3 hours).
+		  <command>max-ncache-ttl</command> cannot exceed
+		  7 days and will
+		  be silently truncated to 7 days if set to a greater value.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-cache-ttl</command></term>
+	      <listitem>
+		<para>
+		  Sets the maximum time for which the server will
+		  cache 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
+		  RRsets (such as NS and glue AAAA/A records) in the
+		  resolution process.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>min-roots</command></term>
+	      <listitem>
+		<para>
+		  The minimum number of root servers that
+		  is required for a request for the root servers to be
+		  accepted. The default
+		  is <userinput>2</userinput>.
+		</para>
+		<note>
+		  <simpara>
+		    Not implemented in <acronym>BIND</acronym> 9.
+		  </simpara>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>sig-validity-interval</command></term>
+	      <listitem>
+		<para>
+		  Specifies the number of days into the future when
+		  DNSSEC signatures automatically generated as a
+		  result of dynamic updates (<xref linkend="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
+		  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 <literal>30</literal> days
+		  giving a re-signing interval of 7 1/2 days.  The maximum
+		  values are 10 years (3660 days).
+		</para>
+		<para>
+		  The signature inception time is unconditionally
+		  set to one hour before the current time to allow
+		  for a limited amount of clock skew.
+		</para>
+		<para>
+		  The <command>sig-validity-interval</command>
+		  should be, at least, several multiples of the SOA
+		  expire interval to allow for reasonable interaction
+		  between the various timer and expiry dates.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>sig-signing-nodes</command></term>
+	      <listitem>
+		<para>
+		  Specify the maximum number of nodes to be
+		  examined in each quantum when signing a zone with
+		  a new DNSKEY. The default is
+		  <literal>100</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>sig-signing-signatures</command></term>
+	      <listitem>
+		<para>
+		  Specify a threshold number of signatures that
+		  will terminate processing a quantum when signing
+		  a zone with a new DNSKEY.  The default is
+		  <literal>10</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>sig-signing-type</command></term>
+	      <listitem>
+		<para>
+		  Specify a private RDATA type to be used when generating
+		  signing state records.  The default is
+		  <literal>65534</literal>.
+		</para>
+		<para>
+		  It is expected that this parameter may be removed
+		  in a future version once there is a standard type.
+		</para>
+		<para>
+		  Signing state records are used to internally by
+		  <command>named</command> 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
+		  <command>rndc signing -list <replaceable>zone</replaceable></command>.
+		  Once <command>named</command> has finished signing
+		  a zone with a particular key, the signing state
+		  record associated with that key can be removed from
+		  the zone by running
+		  <command>rndc signing -clear <replaceable>keyid/algorithm</replaceable> <replaceable>zone</replaceable></command>.
+		  To clear all of the completed signing state
+		  records for a zone, use
+		  <command>rndc signing -clear all <replaceable>zone</replaceable></command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>min-refresh-time</command></term>
+	      <term><command>max-refresh-time</command></term>
+	      <term><command>min-retry-time</command></term>
+	      <term><command>max-retry-time</command></term>
+	      <listitem>
+		<para>
+		  These options control the server's behavior on refreshing a
+		  zone (querying for SOA changes) or retrying failed
+		  transfers.  Usually the SOA values for the zone are used,
+		  up to a hard-coded maximum expiry of 24 weeks. However,
+		  these values are set by the master, giving slave server
+		  administrators little control over their contents.
+		</para>
+		<para>
+		  These options allow the administrator to set a minimum and
+		  maximum refresh and retry time in seconds per-zone,
+		  per-view, or globally.  These options are valid for
+		  slave and stub zones, and clamp the SOA refresh and
+		  retry times to the specified values.
+		</para>
+		<para>
+		  The following defaults apply.
+		  <command>min-refresh-time</command> 300 seconds,
+		  <command>max-refresh-time</command> 2419200 seconds
+		  (4 weeks), <command>min-retry-time</command> 500 seconds,
+		  and <command>max-retry-time</command> 1209600 seconds
+		  (2 weeks).
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>edns-udp-size</command></term>
+	      <listitem>
+		<para>
+		  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.
+		</para>
+		<para>
+		  The usual reason for setting
+		  <command>edns-udp-size</command> to a non-default value
+		  is to get UDP answers to pass through broken firewalls
+		  that block fragmented packets and/or block UDP DNS
+		  packets that are greater than 512 bytes.
+		</para>
+		<para>
+		  When <command>named</command> first queries a remote
+		  server, it will advertise a UDP buffer size of 512, as
+		  this has the greatest chance of success on the first try.
+		</para>
+		<para>
+		  If the initial response times out, <command>named</command>
+		  will try again with plain DNS, and if that is successful,
+		  it will be taken as evidence that the server does not
+		  support EDNS. After enough failures using EDNS and
+		  successes using plain DNS, <command>named</command>
+		  will default to plain DNS for future communications
+		  with that server.  (Periodically, <command>named</command>
+		  will send an EDNS query to see if the situation has
+		  improved.)
+		</para>
+		<para>
+		  However, if the initial query is successful with
+		  EDNS advertising a buffer size of 512, then
+		  <command>named</command> will advertise progressively
+		  larger buffer sizes on successive queries, until
+		  responses begin timing out or
+		  <command>edns-udp-size</command> is reached.
+		</para>
+		<para>
+		  The default buffer sizes used by <command>named</command>
+		  are 512, 1232, 1432, and 4096, but never exceeding
+		  <command>edns-udp-size</command>.  (The values 1232 and
+		  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.)
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-udp-size</command></term>
+	      <listitem>
+		<para>
+		  Sets the maximum EDNS UDP message size
+		  <command>named</command> 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.
+		</para>
+		<para>
+		  This value applies to responses sent by a server; to
+		  set the advertised buffer size in queries, see
+		  <command>edns-udp-size</command>.
+		</para>
+		<para>
+		  The usual reason for setting
+		  <command>max-udp-size</command> to a non-default
+		  value is to get UDP answers to pass through broken
+		  firewalls that block fragmented packets and/or
+		  block UDP packets that are greater than 512 bytes.
+		  This is independent of the advertised receive
+		  buffer (<command>edns-udp-size</command>).
+		</para>
+		<para>
+		  Setting this to a low value will encourage additional
+		  TCP traffic to the nameserver.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>masterfile-format</command></term>
+	      <listitem>
+		<para>Specifies
+		  the file format of zone files (see
+		  <xref linkend="zonefile_format"/>).
+		  The default value is <constant>text</constant>, which is the
+		  standard textual representation, except for slave zones,
+		  in which the default value is <constant>raw</constant>.
+		  Files in other formats than <constant>text</constant> are
+		  typically expected to be generated by the
+		  <command>named-compilezone</command> tool, or dumped by
+		  <command>named</command>.
+		</para>
+		<para>
+		  Note that when a zone file in a different format than
+		  <constant>text</constant> is loaded, <command>named</command>
+		  may omit some of the checks which would be performed for a
+		  file in the <constant>text</constant> format.  In particular,
+		  <command>check-names</command> checks do not apply
+		  for the <constant>raw</constant> format.  This means
+		  a zone file in the <constant>raw</constant> format
+		  must be generated with the same check level as that
+		  specified in the <command>named</command> configuration
+		  file.  Also, <constant>map</constant> format files are
+		  loaded directly into memory via memory mapping, with only
+		  minimal checking.
+		</para>
+		<para>
+		  This statement sets the
+		  <command>masterfile-format</command> for all zones,
+		  but can be overridden on a per-zone or per-view basis
+		  by including a <command>masterfile-format</command>
+		  statement within the <command>zone</command> or
+		  <command>view</command> block in the configuration
+		  file.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>masterfile-style</command></term>
+	      <listitem>
+		<para>
+		  Specifies the formatting of zone files during dump
+		  when the <option>masterfile-format</option> is
+		  <constant>text</constant>. (This option is ignored
+		  with any other <option>masterfile-format</option>.)
+		</para>
+		<para>
+		  When set to <constant>relative</constant>,
+		  records are printed in a multi-line format with owner
+		  names expressed relative to a shared origin.  When set
+		  to <constant>full</constant>, records are printed in
+		  a single-line format with absolute owner names.
+		  The <constant>full</constant> format is most suitable
+		  when a zone file needs to be processed automatically
+		  by a script.  The <constant>relative</constant> format
+		  is more human-readable, and is thus suitable when a
+		  zone is to be edited by hand.  The default is
+		  <constant>relative</constant>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry xml:id="max-recursion-depth">
+	      <term><command>max-recursion-depth</command></term>
+	      <listitem>
+		<para>
+		  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
+		  query is terminated and returns SERVFAIL.  The
+		  default is 7.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry xml:id="max-recursion-queries">
+	      <term><command>max-recursion-queries</command></term>
+	      <listitem>
+		<para>
+		  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. Queries to
+		  look up top level domains such as "com" and "net"
+		  and the DNS root zone are exempt from this limitation.
+		  The default is 75.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>notify-delay</command></term>
+	      <listitem>
+		<para>
+		  The delay, in seconds, between sending sets of notify
+		  messages for a zone.  The default is five (5) seconds.
+		</para>
+		<para>
+		  The overall rate that NOTIFY messages are sent for all
+		  zones is controlled by <command>serial-query-rate</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-rsa-exponent-size</command></term>
+	      <listitem>
+		<para>
+		  The maximum RSA exponent size, in bits, that will
+		  be accepted when validating.  Valid values are 35
+		  to 4096 bits.  The default zero (0) is also accepted
+		  and is equivalent to 4096.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>prefetch</command></term>
+	      <listitem>
+		<para>
+		  When a query is received for cached data which
+		  is to expire shortly, <command>named</command> can
+		  refresh the data from the authoritative server
+		  immediately, ensuring that the cache always has an
+		  answer available.
+		</para>
+		<para>
+		  The <option>prefetch</option> specifies the
+		  "trigger" TTL value at which prefetch of the current
+		  query will take place: when a cache record with a
+		  lower TTL value is encountered during query processing,
+		  it will be refreshed.  Valid trigger TTL values are 1 to
+		  10 seconds.  Values larger than 10 seconds will be silently
+		  reduced to 10.
+		  Setting a trigger TTL to zero (0) causes
+		  prefetch to be disabled.
+		  The default trigger TTL is <literal>2</literal>.
+		</para>
+		<para>
+		  An optional second argument specifies the "eligibility"
+		  TTL: the smallest <emphasis>original</emphasis>
+		  TTL value that will be 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, <command>named</command> will silently
+		  adjust it upward.
+		  The default eligibility TTL is <literal>9</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>v6-bias</command></term>
+	      <listitem>
+		<para>
+		  When determining the next nameserver to try
+		  preference IPv6 nameservers by this many milliseconds.
+		  The default is <literal>50</literal> milliseconds.
+		</para>
+	      </listitem>
+	    </varlistentry>
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="builtin"><info><title>Built-in server information zones</title></info>
+
+	  <para>
+	    The server provides some helpful diagnostic information
+	    through a number of built-in zones under the
+	    pseudo-top-level-domain <literal>bind</literal> in the
+	    <command>CHAOS</command> class.  These zones are part
+	    of a
+	    built-in view (see <xref linkend="view_statement_grammar"/>) of
+	    class
+	    <command>CHAOS</command> which is separate from the
+	    default view of class <command>IN</command>. Most global
+	    configuration options (<command>allow-query</command>,
+	    etc) will apply to this view, but some are locally
+	    overridden: <command>notify</command>,
+	    <command>recursion</command> and
+	    <command>allow-new-zones</command> are
+	    always set to <userinput>no</userinput>, and
+	    <command>rate-limit</command> is set to allow
+	    three responses per second.
+	  </para>
+	  <para>
+	    If you need to disable these zones, use the options
+	    below, or hide the built-in <command>CHAOS</command>
+	    view by
+	    defining an explicit view of class <command>CHAOS</command>
+	    that matches all clients.
+	  </para>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>version</command></term>
+	      <listitem>
+		<para>
+		  The version the server should report
+		  via a query of the name <literal>version.bind</literal>
+		  with type <command>TXT</command>, class <command>CHAOS</command>.
+		  The default is the real version number of this server.
+		  Specifying <command>version none</command>
+		  disables processing of the queries.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>hostname</command></term>
+	      <listitem>
+		<para>
+		  The hostname the server should report via a query of
+		  the name <filename>hostname.bind</filename>
+		  with type <command>TXT</command>, class <command>CHAOS</command>.
+		  This defaults to the hostname of the machine hosting the
+		  name server as
+		  found by the gethostname() function.  The primary purpose of such queries
+		  is to
+		  identify which of a group of anycast servers is actually
+		  answering your queries.  Specifying <command>hostname none;</command>
+		  disables processing of the queries.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>server-id</command></term>
+	      <listitem>
+		<para>
+		  The ID the server should report when receiving a Name
+		  Server Identifier (NSID) query, or a query of the name
+		  <filename>ID.SERVER</filename> with type
+		  <command>TXT</command>, class <command>CHAOS</command>.
+		  The primary purpose of such queries is to
+		  identify which of a group of anycast servers is actually
+		  answering your queries.  Specifying <command>server-id none;</command>
+		  disables processing of the queries.
+		  Specifying <command>server-id hostname;</command> will cause <command>named</command> to
+		  use the hostname as found by the gethostname() function.
+		  The default <command>server-id</command> is <command>none</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="empty"><info><title>Built-in Empty Zones</title></info>
+
+	  <para>
+	    The <command>named</command> server has some built-in
+	    empty zones (SOA and NS records only).
+	    These are for zones that should normally be answered locally
+	    and which queries should not be sent to the Internet's root
+	    servers.  The official servers which cover these namespaces
+	    return NXDOMAIN responses to these queries.  In particular,
+	    these cover the reverse namespaces for addresses from
+	    RFC 1918, RFC 4193, RFC 5737 and RFC 6598.  They also include the
+	    reverse namespace for IPv6 local address (locally assigned),
+	    IPv6 link local addresses, the IPv6 loopback address and the
+	    IPv6 unknown address.
+	  </para>
+	  <para>
+	    The server will attempt to determine if a built-in zone
+	    already exists or is active (covered by a forward-only
+	    forwarding declaration) and will not create an empty
+	    zone in that case.
+	  </para>
+	  <para>
+	    The current list of empty zones is:
+	    <itemizedlist>
+	      <listitem>10.IN-ADDR.ARPA</listitem>
+	      <listitem>16.172.IN-ADDR.ARPA</listitem>
+	      <listitem>17.172.IN-ADDR.ARPA</listitem>
+	      <listitem>18.172.IN-ADDR.ARPA</listitem>
+	      <listitem>19.172.IN-ADDR.ARPA</listitem>
+	      <listitem>20.172.IN-ADDR.ARPA</listitem>
+	      <listitem>21.172.IN-ADDR.ARPA</listitem>
+	      <listitem>22.172.IN-ADDR.ARPA</listitem>
+	      <listitem>23.172.IN-ADDR.ARPA</listitem>
+	      <listitem>24.172.IN-ADDR.ARPA</listitem>
+	      <listitem>25.172.IN-ADDR.ARPA</listitem>
+	      <listitem>26.172.IN-ADDR.ARPA</listitem>
+	      <listitem>27.172.IN-ADDR.ARPA</listitem>
+	      <listitem>28.172.IN-ADDR.ARPA</listitem>
+	      <listitem>29.172.IN-ADDR.ARPA</listitem>
+	      <listitem>30.172.IN-ADDR.ARPA</listitem>
+	      <listitem>31.172.IN-ADDR.ARPA</listitem>
+	      <listitem>168.192.IN-ADDR.ARPA</listitem>
+	      <listitem>64.100.IN-ADDR.ARPA</listitem>
+	      <listitem>65.100.IN-ADDR.ARPA</listitem>
+	      <listitem>66.100.IN-ADDR.ARPA</listitem>
+	      <listitem>67.100.IN-ADDR.ARPA</listitem>
+	      <listitem>68.100.IN-ADDR.ARPA</listitem>
+	      <listitem>69.100.IN-ADDR.ARPA</listitem>
+	      <listitem>70.100.IN-ADDR.ARPA</listitem>
+	      <listitem>71.100.IN-ADDR.ARPA</listitem>
+	      <listitem>72.100.IN-ADDR.ARPA</listitem>
+	      <listitem>73.100.IN-ADDR.ARPA</listitem>
+	      <listitem>74.100.IN-ADDR.ARPA</listitem>
+	      <listitem>75.100.IN-ADDR.ARPA</listitem>
+	      <listitem>76.100.IN-ADDR.ARPA</listitem>
+	      <listitem>77.100.IN-ADDR.ARPA</listitem>
+	      <listitem>78.100.IN-ADDR.ARPA</listitem>
+	      <listitem>79.100.IN-ADDR.ARPA</listitem>
+	      <listitem>80.100.IN-ADDR.ARPA</listitem>
+	      <listitem>81.100.IN-ADDR.ARPA</listitem>
+	      <listitem>82.100.IN-ADDR.ARPA</listitem>
+	      <listitem>83.100.IN-ADDR.ARPA</listitem>
+	      <listitem>84.100.IN-ADDR.ARPA</listitem>
+	      <listitem>85.100.IN-ADDR.ARPA</listitem>
+	      <listitem>86.100.IN-ADDR.ARPA</listitem>
+	      <listitem>87.100.IN-ADDR.ARPA</listitem>
+	      <listitem>88.100.IN-ADDR.ARPA</listitem>
+	      <listitem>89.100.IN-ADDR.ARPA</listitem>
+	      <listitem>90.100.IN-ADDR.ARPA</listitem>
+	      <listitem>91.100.IN-ADDR.ARPA</listitem>
+	      <listitem>92.100.IN-ADDR.ARPA</listitem>
+	      <listitem>93.100.IN-ADDR.ARPA</listitem>
+	      <listitem>94.100.IN-ADDR.ARPA</listitem>
+	      <listitem>95.100.IN-ADDR.ARPA</listitem>
+	      <listitem>96.100.IN-ADDR.ARPA</listitem>
+	      <listitem>97.100.IN-ADDR.ARPA</listitem>
+	      <listitem>98.100.IN-ADDR.ARPA</listitem>
+	      <listitem>99.100.IN-ADDR.ARPA</listitem>
+	      <listitem>100.100.IN-ADDR.ARPA</listitem>
+	      <listitem>101.100.IN-ADDR.ARPA</listitem>
+	      <listitem>102.100.IN-ADDR.ARPA</listitem>
+	      <listitem>103.100.IN-ADDR.ARPA</listitem>
+	      <listitem>104.100.IN-ADDR.ARPA</listitem>
+	      <listitem>105.100.IN-ADDR.ARPA</listitem>
+	      <listitem>106.100.IN-ADDR.ARPA</listitem>
+	      <listitem>107.100.IN-ADDR.ARPA</listitem>
+	      <listitem>108.100.IN-ADDR.ARPA</listitem>
+	      <listitem>109.100.IN-ADDR.ARPA</listitem>
+	      <listitem>110.100.IN-ADDR.ARPA</listitem>
+	      <listitem>111.100.IN-ADDR.ARPA</listitem>
+	      <listitem>112.100.IN-ADDR.ARPA</listitem>
+	      <listitem>113.100.IN-ADDR.ARPA</listitem>
+	      <listitem>114.100.IN-ADDR.ARPA</listitem>
+	      <listitem>115.100.IN-ADDR.ARPA</listitem>
+	      <listitem>116.100.IN-ADDR.ARPA</listitem>
+	      <listitem>117.100.IN-ADDR.ARPA</listitem>
+	      <listitem>118.100.IN-ADDR.ARPA</listitem>
+	      <listitem>119.100.IN-ADDR.ARPA</listitem>
+	      <listitem>120.100.IN-ADDR.ARPA</listitem>
+	      <listitem>121.100.IN-ADDR.ARPA</listitem>
+	      <listitem>122.100.IN-ADDR.ARPA</listitem>
+	      <listitem>123.100.IN-ADDR.ARPA</listitem>
+	      <listitem>124.100.IN-ADDR.ARPA</listitem>
+	      <listitem>125.100.IN-ADDR.ARPA</listitem>
+	      <listitem>126.100.IN-ADDR.ARPA</listitem>
+	      <listitem>127.100.IN-ADDR.ARPA</listitem>
+	      <listitem>0.IN-ADDR.ARPA</listitem>
+	      <listitem>127.IN-ADDR.ARPA</listitem>
+	      <listitem>254.169.IN-ADDR.ARPA</listitem>
+	      <listitem>2.0.192.IN-ADDR.ARPA</listitem>
+	      <listitem>100.51.198.IN-ADDR.ARPA</listitem>
+	      <listitem>113.0.203.IN-ADDR.ARPA</listitem>
+	      <listitem>255.255.255.255.IN-ADDR.ARPA</listitem>
+	      <listitem>0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</listitem>
+	      <listitem>1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA</listitem>
+	      <listitem>8.B.D.0.1.0.0.2.IP6.ARPA</listitem>
+	      <listitem>D.F.IP6.ARPA</listitem>
+	      <listitem>8.E.F.IP6.ARPA</listitem>
+	      <listitem>9.E.F.IP6.ARPA</listitem>
+	      <listitem>A.E.F.IP6.ARPA</listitem>
+	      <listitem>B.E.F.IP6.ARPA</listitem>
+	      <listitem>EMPTY.AS112.ARPA</listitem>
+	      <listitem>HOME.ARPA</listitem>
+	    </itemizedlist>
+	  </para>
+	  <para>
+	    Empty zones are settable at the view level and only apply to
+	    views of class IN.  Disabled empty zones are only inherited
+	    from options if there are no disabled empty zones specified
+	    at the view level.  To override the options list of disabled
+	    zones, you can disable the root zone at the view level, for example:
+<programlisting>
+	    disable-empty-zone ".";
+</programlisting>
+	  </para>
+	  <para>
+	    If you are using the address ranges covered here, you should
+	    already have reverse zones covering the addresses you use.
+	    In practice this appears to not be the case with many queries
+	    being made to the infrastructure servers for names in these
+	    spaces.  So many in fact that sacrificial servers were needed
+	    to be deployed to channel the query load away from the
+	    infrastructure servers.
+	  </para>
+	  <note><simpara>
+	    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.
+	  </simpara></note>
+	  <variablelist>
+	    <varlistentry>
+	      <term><command>empty-server</command></term>
+	      <listitem>
+		<para>
+		  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.
+		</para>
+	       </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>empty-contact</command></term>
+	      <listitem>
+		<para>
+		  Specify what contact name will appear in the returned
+		  SOA record for empty zones.  If none is specified, then
+		  "." will be used.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>empty-zones-enable</command></term>
+	      <listitem>
+		<para>
+		  Enable or disable all empty zones.  By default, they
+		  are enabled.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	    <term><command>disable-empty-zone</command></term>
+	      <listitem>
+		<para>
+		  Disable individual empty zones.  By default, none are
+		  disabled.  This option can be specified multiple times.
+		</para>
+	      </listitem>
+	    </varlistentry>
+	  </variablelist>
+	</section>
+
+	<section xml:id="acache"><info><title>Additional Section Caching</title></info>
+
+
+	  <para>
+	    The additional section cache, also called <command>acache</command>,
+	    is an internal cache to improve the response performance of BIND 9.
+	    When additional section caching is enabled, BIND 9 will
+	    cache an internal short-cut to the additional section content for
+	    each answer RR.
+	    Note that <command>acache</command> is an internal caching
+	    mechanism of BIND 9, and is not related to the DNS caching
+	    server function.
+	  </para>
+
+	  <para>
+	    Additional section caching does not change the
+	    response content (except the RRsets ordering of the additional
+	    section, see below), but can improve the response performance
+	    significantly.
+	    It is particularly effective when BIND 9 acts as an authoritative
+	    server for a zone that has many delegations with many glue RRs.
+	  </para>
+
+	  <para>
+	    In order to obtain the maximum performance improvement
+	    from additional section caching, setting
+	    <command>additional-from-cache</command>
+	    to <command>no</command> is recommended, since the current
+	    implementation of <command>acache</command>
+	    does not short-cut of additional section information from the
+	    DNS cache data.
+	  </para>
+
+	  <para>
+	    One obvious disadvantage of <command>acache</command> is
+	    that it requires much more
+	    memory for the internal cached data.
+	    Thus, if the response performance does not matter and memory
+	    consumption is much more critical, the
+	    <command>acache</command> mechanism can be
+	    disabled by setting <command>acache-enable</command> to
+	    <command>no</command>.
+	    It is also possible to specify the upper limit of memory
+	    consumption
+	    for acache by using <command>max-acache-size</command>.
+	  </para>
+
+	  <para>
+	    Additional section caching also has a minor effect on the
+	    RRset ordering in the additional section.
+	    Without <command>acache</command>,
+	    <command>cyclic</command> order is effective for the additional
+	    section as well as the answer and authority sections.
+	    However, additional section caching fixes the ordering when it
+	    first caches an RRset for the additional section, and the same
+	    ordering will be kept in succeeding responses, regardless of the
+	    setting of <command>rrset-order</command>.
+	    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.
+	  </para>
+
+	  <para>
+	    The following is a summary of options related to
+	    <command>acache</command>.
+	  </para>
+
+	  <variablelist>
+
+	    <varlistentry>
+	      <term><command>acache-enable</command></term>
+	      <listitem>
+		<para>
+		  If <command>yes</command>, additional section caching is
+		  enabled.  The default value is <command>no</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>acache-cleaning-interval</command></term>
+	      <listitem>
+		<para>
+		  The server will remove stale cache entries, based on an LRU
+		  based
+		  algorithm, every <command>acache-cleaning-interval</command> minutes.
+		  The default is 60 minutes.
+		  If set to 0, no periodic cleaning will occur.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>max-acache-size</command></term>
+	      <listitem>
+		<para>
+		  The maximum amount of memory in bytes to use for the server's acache.
+		  When the amount of data in the acache reaches this limit,
+		  the server
+		  will clean more aggressively so that the limit is not
+		  exceeded.
+		  In a server with multiple views, the limit applies
+		  separately to the
+		  acache of each view.
+		  The default is <literal>16M</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	  </variablelist>
+
+	</section>
+
+	<section xml:id="content_filtering"><info><title>Content Filtering</title></info>
+
+	  <para>
+	    <acronym>BIND</acronym> 9 provides the ability to filter
+	    out DNS responses from external DNS servers containing
+	    certain types of data in the answer section.
+	    Specifically, it can reject address (A or AAAA) records if
+	    the corresponding IPv4 or IPv6 addresses match the given
+	    <varname>address_match_list</varname> of the
+	    <command>deny-answer-addresses</command> option.
+	    It can also reject CNAME or DNAME records if the "alias"
+	    name (i.e., the CNAME alias or the substituted query name
+	    due to DNAME) matches the
+	    given <varname>namelist</varname> of the
+	    <command>deny-answer-aliases</command> option, where
+	    "match" means the alias name is a subdomain of one of
+	    the <varname>name_list</varname> elements.
+	    If the optional <varname>namelist</varname> is specified
+	    with <command>except-from</command>, records whose query name
+	    matches the list will be accepted regardless of the filter
+	    setting.
+	    Likewise, if the alias name is a subdomain of the
+	    corresponding zone, the <command>deny-answer-aliases</command>
+	    filter will not apply;
+	    for example, even if "example.com" is specified for
+	    <command>deny-answer-aliases</command>,
+	  </para>
+<programlisting>www.example.com. CNAME xxx.example.com.</programlisting>
+
+	  <para>
+	    returned by an "example.com" server will be accepted.
+	  </para>
+
+	  <para>
+	    In the <varname>address_match_list</varname> of the
+	    <command>deny-answer-addresses</command> option, only
+	    <varname>ip_addr</varname>
+	    and <varname>ip_prefix</varname>
+	    are meaningful;
+	    any <varname>key_id</varname> will be silently ignored.
+	  </para>
+
+	  <para>
+	    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.
+	  </para>
+
+	  <para>
+	    This filtering is intended to prevent "DNS rebinding attacks," in
+	    which an attacker, in response to a query for a domain name the
+	    attacker controls, returns an IP address within your own network or
+	    an alias name within your own domain.
+	    A naive web browser or script could then serve as an
+	    unintended proxy, allowing the attacker
+	    to get access to an internal node of your local network
+	    that couldn't be externally accessed otherwise.
+	    See the paper available at
+	    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://portal.acm.org/citation.cfm?id=1315245.1315298">
+	    http://portal.acm.org/citation.cfm?id=1315245.1315298
+	    </link>
+	    for more details about the attacks.
+	  </para>
+
+	  <para>
+	    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:
+	  </para>
+
+<programlisting>deny-answer-addresses { 192.0.2.0/24; } except-from { "example.net"; };
+deny-answer-aliases { "example.net"; };
+</programlisting>
+
+	  <para>
+	    If an external attacker lets a web browser in your local
+	    network look up an IPv4 address of "attacker.example.com",
+	    the attacker's DNS server would return a response like this:
+	  </para>
+
+<programlisting>attacker.example.com. A 192.0.2.1</programlisting>
+
+	  <para>
+	    in the answer section.
+	    Since the rdata of this record (the IPv4 address) matches
+	    the specified prefix 192.0.2.0/24, this response will be
+	    ignored.
+	  </para>
+
+	  <para>
+	    On the other hand, if the browser looks up a legitimate
+	    internal web server "www.example.net" and the
+	    following response is returned to
+	    the <acronym>BIND</acronym> 9 server
+	  </para>
+
+<programlisting>www.example.net. A 192.0.2.2</programlisting>
+
+	  <para>
+	    it will be accepted since the owner name "www.example.net"
+	    matches the <command>except-from</command> element,
+	    "example.net".
+	  </para>
+
+	  <para>
+	    Note that this is not really an attack on the DNS per se.
+	    In fact, there is nothing wrong for an "external" name to
+	    be mapped to your "internal" IP address or domain name
+	    from the DNS point of view.
+	    It might actually be provided for a legitimate purpose,
+	    such as for debugging.
+	    As long as the mapping is provided by the correct owner,
+	    it is not possible or does not make sense to detect
+	    whether the intent of the mapping is legitimate or not
+	    within the DNS.
+	    The "rebinding" attack must primarily be protected at the
+	    application that uses the DNS.
+	    For a large site, however, it may be difficult to protect
+	    all possible applications at once.
+	    This filtering feature is provided only to help such an
+	    operational environment;
+	    it is generally discouraged to turn it on unless you are
+	    very sure you have no other choice and the attack is a
+	    real threat for your applications.
+	  </para>
+
+	  <para>
+	    Care should be particularly taken if you want to use this
+	    option for addresses within 127.0.0.0/8.
+	    These addresses are obviously "internal", but many
+	    applications conventionally rely on a DNS mapping from
+	    some name to such an address.
+	    Filtering out DNS records containing this address
+	    spuriously can break such applications.
+	  </para>
+	</section>
+
+	<section xml:id="rpz"><info><title>Response Policy Zone (RPZ) Rewriting</title></info>
+
+	  <para>
+	    <acronym>BIND</acronym> 9 includes a limited
+	    mechanism to modify DNS responses for requests
+	    analogous to email anti-spam DNS blacklists.
+	    Responses can be changed to deny the existence of domains (NXDOMAIN),
+	    deny the existence of IP addresses for domains (NODATA),
+	    or contain other IP addresses or data.
+	  </para>
+
+	  <para>
+	    Response policy zones are named in the
+	    <command>response-policy</command> option for the view or among the
+	    global options if there is no response-policy option for the view.
+	    Response policy zones are ordinary DNS zones containing RRsets
+	    that can be queried normally if allowed.
+	    It is usually best to restrict those queries with something like
+	    <command>allow-query { localhost; };</command>.
+	    Note that zones using <command>masterfile-format map</command>
+	    cannot be used as policy zones.
+	  </para>
+
+	  <para>
+	    A <command>response-policy</command> option can support
+	    multiple policy zones.  To maximize performance, a radix
+	    tree is used to quickly identify response policy zones
+	    containing triggers that match the current query.  This
+	    imposes an upper limit of 32 on the number of policy zones
+	    in a single <command>response-policy</command> option; more
+	    than that is a configuration error.
+	  </para>
+
+	  <para>
+	    Five policy triggers can be encoded in RPZ records.
+	    <variablelist>
+	      <varlistentry>
+		<term><command>RPZ-CLIENT-IP</command></term>
+		<listitem>
+		  <para>
+		    IP records are triggered by the IP address of the
+		    DNS client.
+		    Client IP address triggers are encoded in records that have
+		    owner names that are subdomains of
+		    <command>rpz-client-ip</command> relativized to the
+		    policy zone origin name
+		    and encode an address or address block.
+		    IPv4 addresses are represented as
+		    <userinput>prefixlength.B4.B3.B2.B1.rpz-client-ip</userinput>.
+		    The IPv4 prefix length must be between 1 and 32.
+		    All four bytes, B4, B3, B2, and B1, must be present.
+		    B4 is the decimal value of the least significant byte of the
+		    IPv4 address as in IN-ADDR.ARPA.
+		  </para>
+
+		  <para>
+		    IPv6 addresses are encoded in a format similar
+		    to the standard IPv6 text representation,
+		    <userinput>prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-client-ip</userinput>.
+		    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 <userinput>.zz.</userinput>
+		    analogous to double colons (::) in standard IPv6 text
+		    encodings.
+		    The IPv6 prefix length must be between 1 and 128.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>QNAME</command></term>
+		<listitem>
+		  <para>
+		    QNAME policy records are triggered by query names of
+		    requests and targets of CNAME records resolved to generate
+		    the response.
+		    The owner name of a QNAME policy record is
+		    the query name relativized to the policy zone.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>RPZ-IP</command></term>
+		<listitem>
+		  <para>
+		    IP triggers are IP addresses in an
+		    A or AAAA record in the ANSWER section of a response.
+		    They are encoded like client-IP triggers except as
+		    subdomains of <command>rpz-ip</command>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>RPZ-NSDNAME</command></term>
+		<listitem>
+		  <para>
+		    NSDNAME triggers match names of authoritative servers
+		    for the query name, a parent of the query name, a CNAME for
+		    query name, or a parent of a CNAME.
+		    They are encoded as subdomains of
+		    <command>rpz-nsdname</command> 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.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>RPZ-NSIP</command></term>
+		<listitem>
+		  <para>
+		    NSIP triggers match the IP addresses of authoritative
+		    servers.  They are enncoded like IP triggers, except as
+		    subdomains of <command>rpz-nsip</command>.
+		    NSDNAME and NSIP triggers are checked only for names with at
+		    least <command>min-ns-dots</command> dots.
+		    The default value of <command>min-ns-dots</command> is
+		    1, to exclude top level domains.
+		  </para>
+		  <para>
+		    If a name server's IP address is not yet known,
+		    <command>named</command> will recursively look up
+		    the IP address before applying an RPZ-NSIP rule.
+		    This can cause a processing delay. To speed up
+		    processing at the cost of precision, the
+		    <command>nsip-wait-recurse</command> option
+		    can be used: when set to <userinput>no</userinput>,
+		    RPZ-NSIP rules will only be applied when a name
+		    servers'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
+		    to subsequent queries.  The default is
+		    <userinput>yes</userinput>, meaning RPZ-NSIP
+		    rules should always be applied even if an
+		    address needs to be looked up first.
+		  </para>
+		</listitem>
+	      </varlistentry>
+	    </variablelist>
+	  </para>
+
+	  <para>
+	    The query response is checked against all response policy zones,
+	    so two or more policy records can be triggered by a response.
+	    Because DNS responses are rewritten according to at most one
+	    policy record, a single record encoding an action (other than
+	    <command>DISABLED</command> actions) must be chosen.
+	    Triggers or the records that encode them are chosen for the
+	    rewriting in the following order:
+	    <orderedlist inheritnum="ignore" continuation="restarts">
+	      <listitem>Choose the triggered record in the zone that appears
+		first in the <command>response-policy</command> option.
+	      </listitem>
+	      <listitem>Prefer CLIENT-IP to QNAME to IP to NSDNAME to NSIP
+		triggers in a single zone.
+	      </listitem>
+	      <listitem>Among NSDNAME triggers, prefer the
+		trigger that matches the smallest name under the DNSSEC ordering.
+	      </listitem>
+	      <listitem>Among IP or NSIP triggers, prefer the trigger
+		with the longest prefix.
+	      </listitem>
+	      <listitem>Among triggers with the same prefix length,
+		prefer the IP or NSIP trigger that matches
+		the smallest IP address.
+	      </listitem>
+	    </orderedlist>
+	  </para>
+
+	  <para>
+	    When the processing of a response is restarted to resolve
+	    DNAME or CNAME records and a policy record set has
+	    not been triggered,
+	    all response policy zones are again consulted for the
+	    DNAME or CNAME names and addresses.
+	  </para>
+
+	  <para>
+	    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 <command>TCP-only</command> policy is
+	    commonly used with <command>client-IP</command> triggers,
+	    it can be used with any type of trigger to force the use of
+	    TCP for responses with owner names in a zone.
+	    <variablelist>
+	      <varlistentry>
+		<term><command>PASSTHRU</command></term>
+		<listitem>
+		  <para>
+		    The whitelist policy is specified
+		    by a CNAME whose target is <command>rpz-passthru</command>.
+		    It causes the response to not be rewritten
+		    and is most often used to "poke holes" in policies for
+		    CIDR blocks.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>DROP</command></term>
+		<listitem>
+		  <para>
+		    The blacklist policy is specified
+		    by a CNAME whose target is <command>rpz-drop</command>.
+		    It causes the response to be discarded.
+		    Nothing is sent to the DNS client.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>TCP-Only</command></term>
+		<listitem>
+		  <para>
+		    The "slip" policy is specified
+		    by a CNAME whose target is <command>rpz-tcp-only</command>.
+		    It changes UDP responses to short, truncated DNS responses
+		    that require the DNS client to try again with TCP.
+		    It is used to mitigate distributed DNS reflection attacks.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>NXDOMAIN</command></term>
+		<listitem>
+		  <para>
+		    The domain undefined response is encoded
+		    by a CNAME whose target is the root domain (.)
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>NODATA</command></term>
+		<listitem>
+		  <para>
+		    The empty set of resource records is specified by
+		    CNAME whose target is the wildcard top-level
+		    domain (*.).
+		    It rewrites the response to NODATA or ANCOUNT=1.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>Local Data</command></term>
+		<listitem>
+		  <para>
+		    A set of ordinary DNS records can be used to answer queries.
+		    Queries for record types not the set are answered with
+		    NODATA.
+		  </para>
+
+		  <para>
+		    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 (*)
+		    has been replaced with the query name.
+		    The purpose for this special form is query logging in the
+		    walled garden's authority DNS server.
+		  </para>
+		</listitem>
+	      </varlistentry>
+	    </variablelist>
+	  </para>
+
+	  <para>
+	    All of the actions specified in all of the individual records
+	    in a policy zone
+	    can be overridden with a <command>policy</command> clause in the
+	    <command>response-policy</command> option.
+	    An organization using a policy zone provided by another
+	    organization might use this mechanism to redirect domains
+	    to its own walled garden.
+	    <variablelist>
+	      <varlistentry>
+		<term><command>GIVEN</command></term>
+		<listitem>
+		  <para>The placeholder policy says "do not override but
+		    perform the action specified in the zone."
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>DISABLED</command></term>
+		<listitem>
+		  <para>
+		    The testing override policy causes policy zone records to do
+		    nothing but log what they would have done if the
+		    policy zone were not disabled.
+		    The response to the DNS query will be written (or not)
+		    according to any triggered policy records that are not
+		    disabled.
+		    Disabled policy zones should appear first,
+		    because they will often not be logged
+		    if a higher precedence trigger is found first.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>PASSTHRU</command></term>,
+		<term><command>DROP</command></term>,
+		<term><command>TCP-Only</command></term>,
+		<term><command>NXDOMAIN</command></term>,
+		and
+		<term><command>NODATA</command></term>
+		<listitem>
+		  <para>
+		    override with the corresponding per-record policy.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		  <term><command>CNAME domain</command></term>
+		  <listitem>
+		    <para>
+		      causes all RPZ policy records to act as if they were
+		      "cname domain" records.
+		    </para>
+		  </listitem>
+		</varlistentry>
+	    </variablelist>
+	  </para>
+
+	  <para>
+	    By default, the actions encoded in a response policy zone
+	    are applied only to queries that ask for recursion (RD=1).
+	    That default can be changed for a single policy zone or
+	    all response policy zones in a view
+	    with a <command>recursive-only no</command> clause.
+	    This feature is useful for serving the same zone files
+	    both inside and outside an RFC 1918 cloud and using RPZ to
+	    delete answers that would otherwise contain RFC 1918 values
+	    on the externally visible name server or view.
+	  </para>
+
+	  <para>
+	    Also by default, RPZ actions are applied only to DNS requests
+	    that either do not request DNSSEC metadata (DO=0) or when no
+	    DNSSEC records are available for request name in the original
+	    zone (not the response policy zone).  This default can be
+	    changed for all response policy zones in a view with a
+	    <command>break-dnssec yes</command> clause.  In that case, RPZ
+	    actions are applied regardless of DNSSEC.  The name of the
+	    clause option reflects the fact that results rewritten by RPZ
+	    actions cannot verify.
+	  </para>
+
+	  <para>
+	    No DNS records are needed for a QNAME or Client-IP trigger.
+	    The name or IP address itself is sufficient,
+	    so in principle the query name need not be recursively resolved.
+	    However, not resolving the requested
+	    name can leak the fact that response policy rewriting is in use
+	    and that the name is listed in a policy zone to operators of
+	    servers for listed names.  To prevent that information leak, by
+	    default any recursion needed for a request is done before any
+	    policy triggers are considered.  Because listed domains often
+	    have slow authoritative servers, this default behavior can cost
+	    significant time.
+	    The <command>qname-wait-recurse no</command> option
+	    overrides that default behavior when recursion cannot
+	    change a non-error response.
+	    The option does not affect QNAME or client-IP triggers
+	    in policy zones listed
+	    after other zones containing IP, NSIP and NSDNAME triggers, because
+	    those may depend on the A, AAAA, and NS records that would be
+	    found during recursive resolution.  It also does not affect
+	    DNSSEC requests (DO=1) unless <command>break-dnssec yes</command>
+	    is in use, because the response would depend on whether or not
+	    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
+	    discover problems at the authoritative server.
+	  </para>
+
+	  <para>
+	    The TTL of a record modified by RPZ policies is set from the
+	    TTL of the relevant record in policy zone.  It is then limited
+	    to a maximum value.
+	    The <command>max-policy-ttl</command> clause changes the
+	    maximum seconds from its default of 5.
+	  </para>
+
+	  <para>
+	    For example, you might use this option statement
+	  </para>
+<programlisting>    response-policy { zone "badlist"; };</programlisting>
+	  <para>
+	    and this zone statement
+	  </para>
+<programlisting>    zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };</programlisting>
+	  <para>
+	    with this zone file
+	  </para>
+<programlisting>$TTL 1H
+@                       SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
+			NS  LOCALHOST.
+
+; QNAME policy records.  There are no periods (.) after the owner names.
+nxdomain.domain.com     CNAME   .               ; NXDOMAIN policy
+*.nxdomain.domain.com   CNAME   .               ; NXDOMAIN policy
+nodata.domain.com       CNAME   *.              ; NODATA policy
+*.nodata.domain.com     CNAME   *.              ; NODATA policy
+bad.domain.com          A       10.0.0.1        ; redirect to a walled garden
+			AAAA    2001:2::1
+bzone.domain.com        CNAME   garden.example.com.
+
+; do not rewrite (PASSTHRU) OK.DOMAIN.COM
+ok.domain.com           CNAME   rpz-passthru.
+
+; redirect x.bzone.domain.com to x.bzone.domain.com.garden.example.com
+*.bzone.domain.com      CNAME   *.garden.example.com.
+
+
+; IP policy records that rewrite all responses containing A records in 127/8
+;       except 127.0.0.1
+8.0.0.0.127.rpz-ip      CNAME   .
+32.1.0.0.127.rpz-ip     CNAME   rpz-passthru.
+
+; NSDNAME and NSIP policy records
+ns.domain.com.rpz-nsdname   CNAME   .
+48.zz.2.2001.rpz-nsip       CNAME   .
+
+; blacklist and whitelist some DNS clients
+112.zz.2001.rpz-client-ip    CNAME   rpz-drop.
+8.0.0.0.127.rpz-client-ip    CNAME   rpz-drop.
+
+; force some DNS clients and responses in the example.com zone to TCP
+16.0.0.1.10.rpz-client-ip   CNAME   rpz-tcp-only.
+example.com                 CNAME   rpz-tcp-only.
+*.example.com               CNAME   rpz-tcp-only.
+
+</programlisting>
+	  <para>
+	    RPZ can affect server performance.
+	    Each configured response policy zone requires the server to
+	    perform one to four additional database lookups before a
+	    query can be answered.
+	    For example, a DNS server with four policy zones, each with all
+	    four kinds of response triggers, QNAME, IP, NSIP, and
+	    NSDNAME, requires a total of 17 times as many database
+	    lookups as a similar DNS server with no response policy zones.
+	    A <acronym>BIND9</acronym> server with adequate memory and one
+	    response policy zone with QNAME and IP triggers might achieve a
+	    maximum queries-per-second rate about 20% lower.
+	    A server with four response policy zones with QNAME and IP
+	    triggers might have a maximum QPS rate about 50% lower.
+	  </para>
+
+	  <para>
+	    Responses rewritten by RPZ are counted in the
+	    <command>RPZRewrites</command> statistics.
+	  </para>
+
+	  <para>
+	    The <command>log</command> clause can be used to optionally
+	    turn off rewrite logging for a particular response policy
+	    zone. By default, all rewrites are logged.
+	  </para>
+	</section>
+
+	<section xml:id="rrl"><info><title>Response Rate Limiting</title></info>
+
+	  <para>
+	    Excessive almost identical UDP <emphasis>responses</emphasis>
+	    can be controlled by configuring a
+	    <command>rate-limit</command> clause in an
+	    <command>options</command> or <command>view</command> statement.
+	    This mechanism keeps authoritative BIND 9 from being used
+	    in amplifying reflection denial of service (DoS) attacks.
+	    Short truncated (TC=1) responses can be sent to provide
+	    rate-limited responses to legitimate clients within
+	    a range of forged, attacked IP addresses.
+	    Legitimate clients react to dropped or truncated response
+	    by retrying with UDP or with TCP respectively.
+	  </para>
+
+	  <para>
+	    This mechanism is intended for authoritative DNS servers.
+	    It can be used on recursive servers but can slow
+	    applications such as SMTP servers (mail receivers) and
+	    HTTP clients (web browsers) that repeatedly request the
+	    same domains.
+	    When possible, closing "open" recursive servers is better.
+	  </para>
+
+	  <para>
+	    Response rate limiting uses a "credit" or "token bucket" scheme.
+	    Each combination of identical response and client
+	    has a conceptual account that earns a specified number
+	    of credits every second.
+	    A prospective response debits its account by one.
+	    Responses are dropped or truncated
+	    while the account is negative.
+	    Responses are tracked within a rolling window of time
+	    which defaults to 15 seconds, but can be configured with
+	    the <command>window</command> option to any value from
+	    1 to 3600 seconds (1 hour).
+	    The account cannot become more positive than
+	    the per-second limit
+	    or more negative than <command>window</command>
+	    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.
+	  </para>
+
+	  <para>
+	    The notions of "identical response" and "DNS client"
+	    for rate limiting are not simplistic.
+	    All responses to an address block are counted as if to a
+	    single client.
+	    The prefix lengths of addresses blocks are
+	    specified with <command>ipv4-prefix-length</command> (default 24)
+	    and <command>ipv6-prefix-length</command> (default 56).
+	  </para>
+
+	  <para>
+	    All non-empty responses for a valid domain name (qname)
+	    and record type (qtype) are identical and have a limit specified
+	    with <command>responses-per-second</command>
+	    (default 0 or no limit).
+	    All empty (NODATA) responses for a valid domain,
+	    regardless of query type, are identical.
+	    Responses in the NODATA class are limited by
+	    <command>nodata-per-second</command>
+	    (default <command>responses-per-second</command>).
+	    Requests for any and all undefined subdomains of a given
+	    valid domain result in NXDOMAIN errors, and are identical
+	    regardless of query type.
+	    They are limited by <command>nxdomains-per-second</command>
+	    (default <command>responses-per-second</command>).
+	    This controls some attacks using random names, but
+	    can be relaxed or turned off (set to 0)
+	    on servers that expect many legitimate
+	    NXDOMAIN responses, such as from anti-spam blacklists.
+	    Referrals or delegations to the server of a given
+	    domain are identical and are limited by
+	    <command>referrals-per-second</command>
+	    (default <command>responses-per-second</command>).
+	  </para>
+
+	  <para>
+	    Responses generated from local wildcards are counted and limited
+	    as if they were for the parent domain name.
+	    This controls flooding using random.wild.example.com.
+	  </para>
+
+	  <para>
+	    All requests that result in DNS errors other
+	    than NXDOMAIN, such as SERVFAIL and FORMERR, are identical
+	    regardless of requested name (qname) or record type (qtype).
+	    This controls attacks using invalid requests or distant,
+	    broken authoritative servers.
+	    By default the limit on errors is the same as the
+	    <command>responses-per-second</command> value,
+	    but it can be set separately with
+	    <command>errors-per-second</command>.
+	  </para>
+
+	  <para>
+	    Many attacks using DNS involve UDP requests with forged source
+	    addresses.
+	    Rate limiting prevents the use of BIND 9 to flood a network
+	    with responses to requests with forged source addresses,
+	    but could let a third party block responses to legitimate requests.
+	    There is a mechanism that can answer some legitimate
+	    requests from a client whose address is being forged in a flood.
+	    Setting <command>slip</command> to 2 (its default) causes every
+	    other UDP request to be answered with a small truncated (TC=1)
+	    response.
+	    The small size and reduced frequency, and so lack of
+	    amplification, of "slipped" responses make them unattractive
+	    for reflection DoS attacks.
+	    <command>slip</command> must be between 0 and 10.
+	    A value of 0 does not "slip":
+	    no truncated responses are sent due to rate limiting,
+	    all responses are dropped.
+	    A value of 1 causes every response to slip;
+	    values between 2 and 10 cause every n'th response to slip.
+	    Some error responses including REFUSED and SERVFAIL
+	    cannot be replaced with truncated responses and are instead
+	    leaked at the <command>slip</command> rate.
+	  </para>
+
+	  <para>
+	    (NOTE: Dropped responses from an authoritative server may
+	    reduce the difficulty of a third party successfully forging
+	    a response to a recursive resolver. The best security
+	    against forged responses is for authoritative operators
+	    to sign their zones using DNSSEC and for resolver operators
+	    to validate the responses. When this is not an option,
+	    operators who are more concerned with response integrity
+	    than with flood mitigation may consider setting
+	    <command>slip</command> to 1, causing all rate-limited
+	    responses to be truncated rather than dropped.  This reduces
+	    the effectiveness of rate-limiting against reflection attacks.)
+	  </para>
+
+	  <para>
+	    When the approximate query per second rate exceeds
+	    the <command>qps-scale</command> value,
+	    then the <command>responses-per-second</command>,
+	    <command>errors-per-second</command>,
+	    <command>nxdomains-per-second</command> and
+	    <command>all-per-second</command> values are reduced by the
+	    ratio of the current rate to the <command>qps-scale</command> value.
+	    This feature can tighten defenses during attacks.
+	    For example, with
+	    <command>qps-scale 250; responses-per-second 20;</command> and
+	    a total query rate of 1000 queries/second for all queries from
+	    all DNS clients including via TCP,
+	    then the effective responses/second limit changes to
+	    (250/1000)*20 or 5.
+	    Responses sent via TCP are not limited
+	    but are counted to compute the query per second rate.
+	  </para>
+
+	  <para>
+	    Rate limiters for different name spaces maintain
+	    separate counters: If, for example, there is a
+	    <command>rate-limit</command> statement for "com" and
+	    another for "example.com", queries matching "example.com"
+	    will not be debited against the rate limiter for "com".
+	  </para>
+
+	  <para>
+	    If a <command>rate-limit</command> statement does not specify a
+	    <command>domain</command>, then it applies to the root domain
+	    (".") and thus affects the entire DNS namespace, except those
+	    portions covered by other <command>rate-limit</command>
+	    statements.
+	  </para>
+
+	  <para>
+	    Communities of DNS clients can be given their own parameters or no
+	    rate limiting by putting
+	    <command>rate-limit</command> statements in <command>view</command>
+	    statements instead of the global <command>option</command>
+	    statement.
+	    A <command>rate-limit</command> statement in a view replaces,
+	    rather than supplementing, a <command>rate-limit</command>
+	    statement among the main options.
+	    DNS clients within a view can be exempted from rate limits
+	    with the <command>exempt-clients</command> clause.
+	  </para>
+
+	  <para>
+	    UDP responses of all kinds can be limited with the
+	    <command>all-per-second</command> phrase.  This rate
+	    limiting is unlike the rate limiting provided by
+	    <command>responses-per-second</command>,
+	    <command>errors-per-second</command>, and
+	    <command>nxdomains-per-second</command> on a DNS server
+	    which are often invisible to the victim of a DNS
+	    reflection attack.  Unless the forged requests of the
+	    attack are the same as the legitimate requests of the
+	    victim, the victim's requests are not affected.  Responses
+	    affected by an <command>all-per-second</command> limit
+	    are always dropped; the <command>slip</command> value
+	    has no effect.  An <command>all-per-second</command>
+	    limit should be at least 4 times as large as the other
+	    limits, because single DNS clients often send bursts
+	    of legitimate requests.  For example, the receipt of a
+	    single mail message can prompt requests from an SMTP
+	    server for NS, PTR, A, and AAAA records as the incoming
+	    SMTP/TCP/IP connection is considered.  The SMTP server
+	    can need additional NS, A, AAAA, MX, TXT, and SPF records
+	    as it considers the STMP <command>Mail From</command>
+	    command.  Web browsers often repeatedly resolve the
+	    same names that are repeated in HTML &lt;IMG&gt; tags
+	    in a page.  <command>all-per-second</command> is similar
+	    to the rate limiting offered by firewalls but often
+	    inferior.  Attacks that justify ignoring the contents
+	    of DNS responses are likely to be attacks on the DNS
+	    server itself.  They usually should be discarded before
+	    the DNS server spends resources make TCP connections
+	    or parsing DNS requests, but that rate limiting must
+	    be done before the DNS server sees the requests.
+	  </para>
+
+	  <para>
+	    The maximum size of the table used to track requests and
+	    rate limit responses is set with <command>max-table-size</command>.
+	    Each entry in the table is between 40 and 80 bytes.
+	    The table needs approximately as many entries as the number
+	    of requests received per second.
+	    The default is 20,000.
+	    To reduce the cold start of growing the table,
+	    <command>min-table-size</command> (default 500)
+	    can set the minimum table size.
+	    Enable <command>rate-limit</command> category logging to monitor
+	    expansions of the table and inform
+	    choices for the initial and maximum table size.
+	  </para>
+
+	  <para>
+	    Use <command>log-only yes</command> to test rate limiting parameters
+	    without actually dropping any requests.
+	  </para>
+
+	  <para>
+	    Responses dropped by rate limits are included in the
+	    <command>RateDropped</command> and <command>QryDropped</command>
+	    statistics.
+	    Responses that truncated by rate limits are included in
+	    <command>RateSlipped</command> and <command>RespTruncated</command>.
+	  </para>
+	</section>
+
+	<section title="NXDOMAIN Redirection"><info/>
+	  <para>
+	    Named supports NXDOMAIN redirection via two methods:
+	    <itemizedlist>
+	      <listitem>Redirect zone <xref linkend="zone_statement_grammar"/></listitem>
+	      <listitem>Redirect namespace</listitem>
+	    </itemizedlist>
+	  </para>
+	  <para>
+	    With both methods when named gets a NXDOMAIN response
+	    it examines a separate namespace to see if the NXDOMAIN
+	    response should be replaced with an alternative response.
+	  </para>
+	  <para>
+	    With a redirect zone (<command>zone "." { type redirect; };</command>), the
+	    data used to replace the NXDOMAIN is held in a single
+	    zone which is not part of the normal namespace.  All the
+	    redirect information is contained in the zone; there are
+	    no delegations.
+	  </para>
+	  <para>
+	    With a redirect namespace (<command>option { nxdomain-redirect
+	    &lt;suffix&gt; };</command>) 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.
+	  </para>
+	  <para>
+	    If both a redirect zone and a redirect namespace are configured,
+	    the redirect zone is tried first.
+	  </para>
+	</section>
+      </section>
+
+      <section xml:id="server_statement_grammar"><info><title><command>server</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="server.grammar.xml"/>
+	</section>
+
+	<section xml:id="server_statement_definition_and_usage"><info><title><command>server</command> Statement Definition and
+	    Usage</title></info>
+
+	  <para>
+	    The <command>server</command> statement defines
+	    characteristics
+	    to be associated with a remote name server.  If a prefix length is
+	    specified, then a range of servers is covered.  Only the most
+	    specific
+	    server clause applies regardless of the order in
+	    <filename>named.conf</filename>.
+	  </para>
+
+	  <para>
+	    The <command>server</command> statement can occur at
+	    the top level of the
+	    configuration file or inside a <command>view</command>
+	    statement.
+	    If a <command>view</command> statement contains
+	    one or more <command>server</command> statements, only
+	    those
+	    apply to the view and any top-level ones are ignored.
+	    If a view contains no <command>server</command>
+	    statements,
+	    any top-level <command>server</command> statements are
+	    used as
+	    defaults.
+	  </para>
+
+	  <para>
+	    If you discover that a remote server is giving out bad data,
+	    marking it as bogus will prevent further queries to it. The
+	    default
+	    value of <command>bogus</command> is <command>no</command>.
+	  </para>
+	  <para>
+	    The <command>provide-ixfr</command> clause determines
+	    whether
+	    the local server, acting as master, will respond with an
+	    incremental
+	    zone transfer when the given remote server, a slave, requests it.
+	    If set to <command>yes</command>, incremental transfer
+	    will be provided
+	    whenever possible. If set to <command>no</command>,
+	    all transfers
+	    to the remote server will be non-incremental. If not set, the
+	    value
+	    of the <command>provide-ixfr</command> option in the
+	    view or
+	    global options block is used as a default.
+	  </para>
+
+	  <para>
+	    The <command>request-ixfr</command> clause determines
+	    whether
+	    the local server, acting as a slave, will request incremental zone
+	    transfers from the given remote server, a master. If not set, the
+	    value of the <command>request-ixfr</command> 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.
+	  </para>
+
+	  <para>
+	    IXFR requests to servers that do not support IXFR will
+	    automatically
+	    fall back to AXFR.  Therefore, there is no need to manually list
+	    which servers support IXFR and which ones do not; the global
+	    default
+	    of <command>yes</command> should always work.
+	    The purpose of the <command>provide-ixfr</command> and
+	    <command>request-ixfr</command> clauses is
+	    to make it possible to disable the use of IXFR even when both
+	    master
+	    and slave claim to support it, for example if one of the servers
+	    is buggy and crashes or corrupts data when IXFR is used.
+	  </para>
+
+	  <para>
+	    The <command>request-expire</command> 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
+	    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
+	    record instead.
+	    The default is <command>yes</command>.
+	  </para>
+
+	  <para>
+	    The <command>edns</command> clause determines whether
+	    the local server will attempt to use EDNS when communicating
+	    with the remote server.  The default is <command>yes</command>.
+	  </para>
+
+	  <para>
+	    The <command>edns-udp-size</command> option sets the
+	    EDNS UDP size that is advertised by <command>named</command>
+	    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,
+	    for example, when there is a firewall at the remote
+	    site that is blocking large replies. (Note: Currently,
+	    this sets a single UDP size for all packets sent to the
+	    server; <command>named</command> will not deviate from
+	    this value.  This differs from the behavior of
+	    <command>edns-udp-size</command> in <command>options</command>
+	    or <command>view</command> statements, where it specifies
+	    a maximum value. The <command>server</command> statement
+	    behavior may be brought into conformance with the
+	    <command>options/view</command> behavior in future releases.)
+	  </para>
+
+	  <para>
+	    The <command>edns-version</command> option sets the
+	    maximum EDNS VERSION that will be sent to the server(s)
+	    by the resolver.  The actual EDNS version sent is still
+	    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
+	    EDNS versions than 0 are in use.
+	  </para>
+
+	  <para>
+	    The <command>max-udp-size</command> option sets the
+	    maximum EDNS UDP message size <command>named</command>
+	    will send.  Valid values are 512 to 4096 bytes (values
+	    outside this range will be silently adjusted).  This
+	    option is useful when you know that there is a firewall
+	    that is blocking large replies from <command>named</command>.
+	  </para>
+
+	  <para>
+	    The <command>tcp-only</command> option sets the transport
+	    protocol to TCP. The default is to use the UDP transport
+	    and to fallback on TCP only when a truncated response
+	    is received.
+	  </para>
+
+	  <para>
+	    The server supports two zone transfer methods. The first, <command>one-answer</command>,
+	    uses one DNS message per resource record transferred. <command>many-answers</command> packs
+	    as many resource records as possible into a message. <command>many-answers</command> is
+	    more efficient, but is only known to be understood by <acronym>BIND</acronym> 9, <acronym>BIND</acronym>
+	    8.x, and patched versions of <acronym>BIND</acronym>
+	    4.9.5. You can specify which method
+	    to use for a server with the <command>transfer-format</command> option.
+	    If <command>transfer-format</command> is not
+	    specified, the <command>transfer-format</command>
+	    specified
+	    by the <command>options</command> statement will be
+	    used.
+	  </para>
+
+	  <para><command>transfers</command>
+	    is used to limit the number of concurrent inbound zone
+	    transfers from the specified server. If no
+	    <command>transfers</command> clause is specified, the
+	    limit is set according to the
+	    <command>transfers-per-ns</command> option.
+	  </para>
+
+	  <para>
+	    The <command>keys</command> clause identifies a
+	    <command>key_id</command> defined by the <command>key</command> statement,
+	    to be used for transaction security (TSIG, <xref linkend="tsig"/>)
+	    when talking to the remote server.
+	    When a request is sent to the remote server, a request signature
+	    will be generated using the key specified here and appended to the
+	    message. A request originating from the remote server is not
+	    required
+	    to be signed by this key.
+	  </para>
+
+	  <para>
+	    Only a single key per server is currently supported.
+	  </para>
+
+	  <para>
+	    The <command>transfer-source</command> and
+	    <command>transfer-source-v6</command> clauses specify
+	    the IPv4 and IPv6 source
+	    address to be used for zone transfer with the remote server,
+	    respectively.
+	    For an IPv4 remote server, only <command>transfer-source</command> can
+	    be specified.
+	    Similarly, for an IPv6 remote server, only
+	    <command>transfer-source-v6</command> can be
+	    specified.
+	    For more details, see the description of
+	    <command>transfer-source</command> and
+	    <command>transfer-source-v6</command> in
+	    <xref linkend="zone_transfers"/>.
+	  </para>
+
+	  <para>
+	    The <command>notify-source</command> and
+	    <command>notify-source-v6</command> clauses specify the
+	    IPv4 and IPv6 source address to be used for notify
+	    messages sent to remote servers, respectively.  For an
+	    IPv4 remote server, only <command>notify-source</command>
+	    can be specified.  Similarly, for an IPv6 remote server,
+	    only <command>notify-source-v6</command> can be specified.
+	  </para>
+
+	  <para>
+	    The <command>query-source</command> and
+	    <command>query-source-v6</command> clauses specify the
+	    IPv4 and IPv6 source address to be used for queries
+	    sent to remote servers, respectively.  For an IPv4
+	    remote server, only <command>query-source</command> can
+	    be specified.  Similarly, for an IPv6 remote server,
+	    only <command>query-source-v6</command> can be specified.
+	  </para>
+
+	  <para>
+	    The <command>request-nsid</command> clause determines
+	    whether the local server will add a NSID EDNS option
+	    to requests sent to the server.  This overrides
+	    <command>request-nsid</command> set at the view or
+	    option level.
+	  </para>
+
+	  <para>
+	    The <command>send-cookie</command> clause determines
+	    whether the local server will add a COOKIE EDNS option
+	    to requests sent to the server.  This overrides
+	    <command>send-cookie</command> set at the view or
+	    option level.  The <command>named</command> server may
+	    determine that COOKIE is not supported by the remote server
+	    and not add a COOKIE EDNS option to requests.
+	  </para>
+	</section>
+
+      <section xml:id="statschannels"><info><title><command>statistics-channels</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="statistics-channels.grammar.xml"/>
+      </section>
+
+      <section xml:id="statistics_channels"><info><title><command>statistics-channels</command> Statement Definition and
+	    Usage</title></info>
+
+	<para>
+	  The <command>statistics-channels</command> statement
+	  declares communication channels to be used by system
+	  administrators to get access to statistics information of
+	  the name server.
+	</para>
+
+	<para>
+	  This statement intends to be flexible to support multiple
+	  communication protocols in the future, but currently only
+	  HTTP access is supported.
+	  It requires that BIND 9 be compiled with libxml2 and/or
+	  json-c (also known as libjson0); the
+	  <command>statistics-channels</command> statement is
+	  still accepted even if it is built without the library,
+	  but any HTTP access will fail with an error.
+	</para>
+
+	<para>
+	  An <command>inet</command> control channel is a TCP socket
+	  listening at the specified <command>ip_port</command> on the
+	  specified <command>ip_addr</command>, which can be an IPv4 or IPv6
+	  address.  An <command>ip_addr</command> of <literal>*</literal>
+	  (asterisk) is
+	  interpreted as the IPv4 wildcard address; connections will be
+	  accepted on any of the system's IPv4 addresses.
+	  To listen on the IPv6 wildcard address,
+	  use an <command>ip_addr</command> of <literal>::</literal>.
+	</para>
+
+	<para>
+	  If no port is specified, port 80 is used for HTTP channels.
+	  The asterisk "<literal>*</literal>" cannot be used for
+	  <command>ip_port</command>.
+	</para>
+
+	<para>
+	  The attempt of opening a statistics channel is
+	  restricted by the optional <command>allow</command> clause.
+	  Connections to the statistics channel are permitted based on the
+	  <command>address_match_list</command>.
+	  If no <command>allow</command> clause is present,
+	  <command>named</command> accepts connection
+	  attempts from any address; since the statistics may
+	  contain sensitive internal information, it is highly
+	  recommended to restrict the source of connection requests
+	  appropriately.
+	</para>
+
+	<para>
+	  If no <command>statistics-channels</command> statement is present,
+	  <command>named</command> will not open any communication channels.
+	</para>
+
+	<para>
+	  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
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/">http://127.0.0.1:8888/</link> or
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml">http://127.0.0.1:8888/xml</link>. A CSS file is
+	  included which can format the XML statistics into tables
+	  when viewed with a stylesheet-capable browser, and into
+	  charts and graphs using the Google Charts API when using a
+	  javascript-capable browser.
+	</para>
+
+	<para>
+	  Applications that depend on a particular XML schema
+	  can request
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v2">http://127.0.0.1:8888/xml/v2</link> for version 2
+	  of the statistics XML schema or
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3">http://127.0.0.1:8888/xml/v3</link> for version 3.
+	  If the requested schema is supported by the server, then
+	  it will respond; if not, it will return a "page not found"
+	  error.
+	</para>
+
+	<para>
+	  Broken-out subsets of the statistics can be viewed at
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/status">http://127.0.0.1:8888/xml/v3/status</link>
+	  (server uptime and last reconfiguration time),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/server">http://127.0.0.1:8888/xml/v3/server</link>
+	  (server and resolver statistics),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/zones">http://127.0.0.1:8888/xml/v3/zones</link>
+	  (zone statistics),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/net">http://127.0.0.1:8888/xml/v3/net</link>
+	  (network status and socket statistics),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/mem">http://127.0.0.1:8888/xml/v3/mem</link>
+	  (memory manager statistics),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/tasks">http://127.0.0.1:8888/xml/v3/tasks</link>
+	  (task manager statistics), and
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v3/traffic">http://127.0.0.1:8888/xml/v3/traffic</link>
+	  (traffic sizes).
+	</para>
+
+	<para>
+	  The full set of statistics can also be read in JSON format at
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json">http://127.0.0.1:8888/json</link>,
+	  with the broken-out subsets at
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/status">http://127.0.0.1:8888/json/v1/status</link>
+	  (server uptime and last reconfiguration time),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/server">http://127.0.0.1:8888/json/v1/server</link>
+	  (server and resolver statistics),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/zones">http://127.0.0.1:8888/json/v1/zones</link>
+	  (zone statistics),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/net">http://127.0.0.1:8888/json/v1/net</link>
+	  (network status and socket statistics),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/mem">http://127.0.0.1:8888/json/v1/mem</link>
+	  (memory manager statistics),
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/tasks">http://127.0.0.1:8888/json/v1/tasks</link>
+	  (task manager statistics), and
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/json/v1/traffic">http://127.0.0.1:8888/json/v1/traffic</link>
+	  (traffic sizes).
+	</para>
+      </section>
+
+	<section xml:id="trusted-keys"><info><title><command>trusted-keys</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="trusted-keys.grammar.xml"/>
+	</section>
+	<section xml:id="trusted_keys"><info><title><command>trusted-keys</command> Statement Definition
+	    and Usage</title></info>
+
+	  <para>
+	    The <command>trusted-keys</command> statement defines
+	    DNSSEC security roots. DNSSEC is described in <xref linkend="DNSSEC"/>. A security root is defined when the
+	    public key for a non-authoritative zone is known, but
+	    cannot be securely obtained through DNS, either because
+	    it is the DNS root zone or because its parent zone is
+	    unsigned.  Once a key has been configured as a trusted
+	    key, it is treated as if it had been validated and
+	    proven secure. The resolver attempts DNSSEC validation
+	    on all DNS data in subdomains of a security root.
+	  </para>
+	  <para>
+	    All keys (and corresponding zones) listed in
+	    <command>trusted-keys</command> are deemed to exist regardless
+	    of what parent zones say.  Similarly for all keys listed in
+	    <command>trusted-keys</command> only those keys are
+	    used to validate the DNSKEY RRset.  The parent's DS RRset
+	    will not be used.
+	  </para>
+	  <para>
+	    The <command>trusted-keys</command> statement can contain
+	    multiple key entries, each consisting of the key's
+	    domain name, flags, protocol, 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
+	    multiple lines.
+	  </para>
+	  <para>
+	    <command>trusted-keys</command> may be set at the top level
+	    of <filename>named.conf</filename> or within a view.  If it is
+	    set in both places, they are additive: keys defined at the top
+	    level are inherited by all views, but keys defined in a view
+	    are only used within that view.
+	  </para>
+	  <para>
+	    Validation below specified names can be temporarily disabled
+	    by using <command>rndc nta</command>.
+	  </para>
+	</section>
+
+	<section xml:id="managed_keys"><info><title><command>managed-keys</command> Statement Grammar</title></info>
+	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="managed-keys.grammar.xml"/>
+	</section>
+	<section xml:id="managed-keys"><info><title><command>managed-keys</command> Statement Definition
+	    and Usage</title></info>
+
+	  <para>
+	    The <command>managed-keys</command> statement, like
+	    <command>trusted-keys</command>, defines DNSSEC
+	    security roots.  The difference is that
+	    <command>managed-keys</command> can be kept up to date
+	    automatically, without intervention from the resolver
+	    operator.
+	  </para>
+	  <para>
+	    Suppose, for example, that a zone's key-signing
+	    key was compromised, and the zone owner had to revoke and
+	    replace the key.  A resolver which had the old key in a
+	    <command>trusted-keys</command> statement would be
+	    unable to validate this zone any longer; it would
+	    reply with a SERVFAIL response code.  This would
+	    continue until the resolver operator had updated the
+	    <command>trusted-keys</command> statement with the new key.
+	  </para>
+	  <para>
+	    If, however, the zone were listed in a
+	    <command>managed-keys</command> statement instead, then the
+	    zone owner could add a "stand-by" key to the zone in advance.
+	    <command>named</command> would store the stand-by key, and
+	    when the original key was revoked, <command>named</command>
+	    would be able to transition smoothly to the new key.  It would
+	    also recognize that the old key had been revoked, and cease
+	    using that key to validate answers, minimizing the damage that
+	    the compromised key could do.
+	  </para>
+	  <para>
+	    A <command>managed-keys</command> statement contains a list of
+	    the keys to be managed, along with information about how the
+	    keys are to be initialized for the first time.  The only
+	    initialization method currently supported is
+	    <literal>initial-key</literal>.
+	    This means the <command>managed-keys</command> statement must
+	    contain a copy of the initializing key.  (Future releases may
+	    allow keys to be initialized by other methods, eliminating this
+	    requirement.)
+	  </para>
+	  <para>
+	    Consequently, a <command>managed-keys</command> statement
+	    appears similar to a <command>trusted-keys</command>, differing
+	    in the presence of the second field, containing the keyword
+	    <literal>initial-key</literal>.  The difference is, whereas the
+	    keys listed in a <command>trusted-keys</command> continue to be
+	    trusted until they are removed from
+	    <filename>named.conf</filename>, an initializing key listed
+	    in a <command>managed-keys</command> statement is only trusted
+	    <emphasis>once</emphasis>: for as long as it takes to load the
+	    managed key database and start the RFC 5011 key maintenance
+	    process.
+	  </para>
+	  <para>
+	    The first time <command>named</command> runs with a managed key
+	    configured in <filename>named.conf</filename>, it fetches the
+	    DNSKEY RRset directly from the zone apex, and validates it
+	    using the key specified in the <command>managed-keys</command>
+	    statement.  If the DNSKEY RRset is validly signed, then it is
+	    used as the basis for a new managed keys database.
+	  </para>
+	  <para>
+	    From that point on, whenever <command>named</command> runs, it
+	    sees the <command>managed-keys</command> statement, checks to
+	    make sure RFC 5011 key maintenance has already been initialized
+	    for the specified domain, and if so, it simply moves on.  The
+	    key specified in the <command>managed-keys</command>
+	    statement is not used to validate answers; it has been
+	    superseded by the key or keys stored in the managed keys database.
+	  </para>
+	  <para>
+	    The next time <command>named</command> runs after a name
+	    has been <emphasis>removed</emphasis> from the
+	    <command>managed-keys</command> statement, the corresponding
+	    zone will be removed from the managed keys database,
+	    and RFC 5011 key maintenance will no longer be used for that
+	    domain.
+	  </para>
+	  <para>
+	    In the current implementation, the managed keys database
+	    is stored as a master-format zone file.
+	  </para>
+	  <para>
+	    On servers which do not use views, this file is named
+	    <filename>managed-keys.bind</filename>.  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
+	    contains characters which would make it illegal as a filename,
+	    a hash of the view name), followed by
+	    the suffix <filename>.mkeys</filename>.
+	  </para>
+	  <para>
+	    When the key database is changed, the zone is updated.
+	    As with any other dynamic zone, changes will be written
+	    into a journal file, e.g.,
+	    <filename>managed-keys.bind.jnl</filename> or
+	    <filename>internal.mkeys.jnl</filename>.
+	    Changes are committed to the master file as soon as
+	    possible afterward; this will usually occur within 30
+	    seconds.  So, whenever <command>named</command> 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
+	    should be always be writable by <command>named</command>.)
+	  </para>
+	  <para>
+	    If the <command>dnssec-validation</command> option is
+	    set to <userinput>auto</userinput>, <command>named</command>
+	    will automatically initialize a managed key for the
+	    root zone.  The key that is used to initialize the key
+	    maintenance process is stored in <filename>bind.keys</filename>;
+	    the location of this file can be overridden with the
+	    <command>bindkeys-file</command> option. As a fallback
+	    in the event no <filename>bind.keys</filename> can be
+	    found, the initializing key is also compiled directly
+	    into <command>named</command>.
+	  </para>
+	</section>
+
+	<section xml:id="view_statement_grammar"><info><title><command>view</command> Statement Grammar</title></info>
+
+<programlisting><command>view</command> <replaceable>view_name</replaceable> [ <replaceable>class</replaceable> ] <command>{</command>
+    <command>match-clients {</command> <replaceable>address_match_list</replaceable> <command>}</command> ;
+    <command>match-destinations {</command> <replaceable>address_match_list</replaceable> <command>}</command> ;
+    <command>match-recursive-only</command> <replaceable>yes_or_no</replaceable> ;
+  [ <replaceable>view_option</replaceable> ; ... ]
+  [ <replaceable>zone_statement</replaceable> ; ... ]
+<command>} </command>;
+</programlisting>
+
+	</section>
+	<section xml:id="view_statement"><info><title><command>view</command> Statement Definition and Usage</title></info>
+
+	  <para>
+	    The <command>view</command> statement is a powerful
+	    feature
+	    of <acronym>BIND</acronym> 9 that lets a name server
+	    answer a DNS query differently
+	    depending on who is asking. It is particularly useful for
+	    implementing
+	    split DNS setups without having to run multiple servers.
+	  </para>
+
+	  <para>
+	    Each <command>view</command> statement defines a view
+	    of the
+	    DNS namespace that will be seen by a subset of clients.  A client
+	    matches
+	    a view if its source IP address matches the
+	    <varname>address_match_list</varname> of the view's
+	    <command>match-clients</command> clause and its
+	    destination IP address matches
+	    the <varname>address_match_list</varname> of the
+	    view's
+	    <command>match-destinations</command> clause.  If not
+	    specified, both
+	    <command>match-clients</command> and <command>match-destinations</command>
+	    default to matching all addresses.  In addition to checking IP
+	    addresses
+	    <command>match-clients</command> and <command>match-destinations</command>
+	    can also take <command>keys</command> which provide an
+	    mechanism for the
+	    client to select the view.  A view can also be specified
+	    as <command>match-recursive-only</command>, which
+	    means that only recursive
+	    requests from matching clients will match that view.
+	    The order of the <command>view</command> statements is
+	    significant —
+	    a client request will be resolved in the context of the first
+	    <command>view</command> that it matches.
+	  </para>
+
+	  <para>
+	    Zones defined within a <command>view</command>
+	    statement will
+	    only be accessible to clients that match the <command>view</command>.
+	    By defining a zone of the same name in multiple views, different
+	    zone data can be given to different clients, for example,
+	    "internal"
+	    and "external" clients in a split DNS setup.
+	  </para>
+
+	  <para>
+	    Many of the options given in the <command>options</command> statement
+	    can also be used within a <command>view</command>
+	    statement, and then
+	    apply only when resolving queries with that view.  When no
+	    view-specific
+	    value is given, the value in the <command>options</command> statement
+	    is used as a default.  Also, zone options can have default values
+	    specified
+	    in the <command>view</command> statement; these
+	    view-specific defaults
+	    take precedence over those in the <command>options</command> statement.
+	  </para>
+
+	  <para>
+	    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.
+	  </para>
+
+	  <para>
+	    If there are no <command>view</command> statements in
+	    the config
+	    file, a default view that matches any client is automatically
+	    created
+	    in class IN. Any <command>zone</command> statements
+	    specified on
+	    the top level of the configuration file are considered to be part
+	    of
+	    this default view, and the <command>options</command>
+	    statement will
+	    apply to the default view. If any explicit <command>view</command>
+	    statements are present, all <command>zone</command>
+	    statements must
+	    occur inside <command>view</command> statements.
+	  </para>
+
+	  <para>
+	    Here is an example of a typical split DNS setup implemented
+	    using <command>view</command> statements:
+	  </para>
+
+<programlisting>view "internal" {
+      // This should match our internal networks.
+      match-clients { 10.0.0.0/8; };
+
+      // Provide recursive service to internal
+      // clients only.
+      recursion yes;
+
+      // Provide a complete view of the example.com
+      // zone including addresses of internal hosts.
+      zone "example.com" {
+	    type master;
+	    file "example-internal.db";
+      };
+};
+
+view "external" {
+      // Match all clients not matched by the
+      // previous view.
+      match-clients { any; };
+
+      // Refuse recursive service to external clients.
+      recursion no;
+
+      // Provide a restricted view of the example.com
+      // zone containing only publicly accessible hosts.
+      zone "example.com" {
+	   type master;
+	   file "example-external.db";
+      };
+};
+</programlisting>
+
+	</section>
+	<section xml:id="zone_statement_grammar"><info><title><command>zone</command>
+	    Statement Grammar</title></info>
+
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="master.zoneopt.xml"/>
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="slave.zoneopt.xml"/>
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="hint.zoneopt.xml"/>
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="stub.zoneopt.xml"/>
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="static-stub.zoneopt.xml"/>
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="forward.zoneopt.xml"/>
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="redirect.zoneopt.xml"/>
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="delegation-only.zoneopt.xml"/>
+<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="in-view.zoneopt.xml"/>
+
+	</section>
+	<section xml:id="zone_statement"><info><title><command>zone</command> Statement Definition and Usage</title></info>
+
+	  <section xml:id="zone_types"><info><title>Zone Types</title></info>
+	    <para>
+	      The <command>type</command> keyword is required
+	      for the <command>zone</command> configuration unless
+	      it is an <command>in-view</command> configuration. Its
+	      acceptable values include: <varname>delegation-only</varname>,
+	      <varname>forward</varname>, <varname>hint</varname>,
+	      <varname>master</varname>, <varname>redirect</varname>,
+	      <varname>slave</varname>, <varname>static-stub</varname>,
+	      and <varname>stub</varname>.
+	    </para>
+
+	    <informaltable colsep="0" rowsep="0">
+	      <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+		<!--colspec colname="1" colnum="1" colsep="0" colwidth="1.108in"/-->
+		<!--colspec colname="2" colnum="2" colsep="0" colwidth="4.017in"/-->
+		<colspec colname="1" colnum="1" colsep="0"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="4.017in"/>
+		<tbody>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>master</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			The server has a master copy of the data
+			for the zone and will be able to provide authoritative
+			answers for
+			it.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>slave</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A slave zone is a replica of a master
+			zone. The <command>masters</command> list
+			specifies one or more IP addresses
+			of master servers that the slave contacts to update
+			its copy of the zone.
+			Masters list elements can also be names of other
+			masters lists.
+			By default, transfers are made from port 53 on the
+			servers; this can
+			be changed for all servers by specifying a port number
+			before the
+			list of IP addresses, or on a per-server basis after
+			the IP address.
+			Authentication to the master can also be done with
+			per-server TSIG keys.
+			If a file is specified, then the
+			replica will be written to this file whenever the zone
+			is changed,
+			and reloaded from this file on a server restart. Use
+			of a file is
+			recommended, since it often speeds server startup and
+			eliminates
+			a needless waste of bandwidth. Note that for large
+			numbers (in the
+			tens or hundreds of thousands) of zones per server, it
+			is best to
+			use a two-level naming scheme for zone filenames. For
+			example,
+			a slave server for the zone <literal>example.com</literal> might place
+			the zone contents into a file called
+			<filename>ex/example.com</filename> where <filename>ex/</filename> is
+			just the first two letters of the zone name. (Most
+			operating systems
+			behave very slowly if you put 100000 files into
+			a single directory.)
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>stub</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A stub zone is similar to a slave zone,
+			except that it replicates only the NS records of a
+			master zone instead
+			of the entire zone. Stub zones are not a standard part
+			of the DNS;
+			they are a feature specific to the <acronym>BIND</acronym> implementation.
+		      </para>
+
+		      <para>
+			Stub zones can be used to eliminate the need for glue
+			NS record
+			in a parent zone at the expense of maintaining a stub
+			zone entry and
+			a set of name server addresses in <filename>named.conf</filename>.
+			This usage is not recommended for new configurations,
+			and BIND 9
+			supports it only in a limited way.
+			In <acronym>BIND</acronym> 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. <acronym>BIND</acronym>
+			9 never mixes together zone data from different zones
+			in this
+			way. Therefore, if a <acronym>BIND</acronym> 9 master serving a parent
+			zone has child stub zones configured, all the slave
+			servers for the
+			parent zone also need to have the same child stub
+			zones
+			configured.
+		      </para>
+
+		      <para>
+			Stub zones can also be used as a way of forcing the
+			resolution
+			of a given domain to use a particular set of
+			authoritative servers.
+			For example, the caching name servers on a private
+			network using
+			RFC1918 addressing may be configured with stub zones
+			for
+			<literal>10.in-addr.arpa</literal>
+			to use a set of internal name servers as the
+			authoritative
+			servers for that domain.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>static-stub</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A static-stub zone is similar to a stub zone
+			with the following exceptions:
+			the zone data is statically configured, rather
+			than transferred from a master server;
+			when recursion is necessary for a query that
+			matches a static-stub zone, the locally
+			configured data (nameserver names and glue addresses)
+			is always used even if different authoritative
+			information is cached.
+		      </para>
+		      <para>
+			Zone data is configured via the
+			<command>server-addresses</command> and
+			<command>server-names</command> zone options.
+		      </para>
+		      <para>
+			The zone data is maintained in the form of NS
+			and (if necessary) glue A or AAAA RRs
+			internally, which can be seen by dumping zone
+			databases by <command>rndc dumpdb -all</command>.
+			The configured RRs are considered local configuration
+			parameters rather than public data.
+			Non recursive queries (i.e., those with the RD
+			bit off) to a static-stub zone are therefore
+			prohibited and will be responded with REFUSED.
+		      </para>
+		      <para>
+			Since the data is statically configured, no
+			zone maintenance action takes place for a static-stub
+			zone.
+			For example, there is no periodic refresh
+			attempt, and an incoming notify message
+			will be rejected with an rcode of NOTAUTH.
+		      </para>
+		      <para>
+			Each static-stub zone is configured with
+			internally generated NS and (if necessary)
+			glue A or AAAA RRs
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>forward</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A "forward zone" is a way to configure
+			forwarding on a per-domain basis.  A <command>zone</command> statement
+			of type <command>forward</command> can
+			contain a <command>forward</command>
+			and/or <command>forwarders</command>
+			statement,
+			which will apply to queries within the domain given by
+			the zone
+			name. If no <command>forwarders</command>
+			statement is present or
+			an empty list for <command>forwarders</command> is given, then no
+			forwarding will be done for the domain, canceling the
+			effects of
+			any forwarders in the <command>options</command> statement. Thus
+			if you want to use this type of zone to change the
+			behavior of the
+			global <command>forward</command> option
+			(that is, "forward first"
+			to, then "forward only", or vice versa, but want to
+			use the same
+			servers as set globally) you need to re-specify the
+			global forwarders.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>hint</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>redirect</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Redirect zones are used to provide answers to
+			queries when normal resolution would result in
+			NXDOMAIN being returned.
+			Only one redirect zone is supported
+			per view.  <command>allow-query</command> can be
+			used to restrict which clients see these answers.
+		      </para>
+		      <para>
+			If the client has requested DNSSEC records (DO=1) and
+			the NXDOMAIN response is signed then no substitution
+			will occur.
+		      </para>
+		      <para>
+			To redirect all NXDOMAIN responses to
+			100.100.100.2 and
+			2001:ffff:ffff::100.100.100.2, one would
+			configure a type redirect zone named ".",
+			with the zone file containing wildcard records
+			that point to the desired addresses:
+			<literal>"*. IN A 100.100.100.2"</literal>
+			and
+			<literal>"*. IN AAAA 2001:ffff:ffff::100.100.100.2"</literal>.
+		      </para>
+		      <para>
+			To redirect all Spanish names (under .ES) one
+			would use similar entries but with the names
+			"*.ES." instead of "*.".  To redirect all
+			commercial Spanish names (under COM.ES) one
+			would use wildcard entries called "*.COM.ES.".
+		      </para>
+		      <para>
+			Note that the redirect zone supports all
+			possible types; it is not limited to A and
+			AAAA records.
+		      </para>
+		      <para>
+			Because redirect zones are not referenced
+			directly by name, they are not kept in the
+			zone lookup table with normal master and slave
+			zones. Consequently, it is not currently possible
+			to use
+			<command>rndc reload
+				<replaceable>zonename</replaceable></command>
+			to reload a redirect zone.  However, when using
+			<command>rndc reload</command> without specifying
+			a zone name, redirect zones will be reloaded along
+			with other zones.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>delegation-only</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			This is used to enforce the delegation-only
+			status of infrastructure zones (e.g. COM,
+			NET, ORG).  Any answer that is received
+			without an explicit or implicit delegation
+			in the authority section will be treated
+			as NXDOMAIN.  This does not apply to the
+			zone apex.  This should not be applied to
+			leaf zones.
+		      </para>
+		      <para>
+			<varname>delegation-only</varname> has no
+			effect on answers received from forwarders.
+		      </para>
+		      <para>
+			See caveats in <xref linkend="root_delegation_only"/>.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	  </section>
+
+	  <section xml:id="class"><info><title>Class</title></info>
+
+	    <para>
+	      The zone's name may optionally be followed by a class. If
+	      a class is not specified, class <literal>IN</literal> (for <varname>Internet</varname>),
+	      is assumed. This is correct for the vast majority of cases.
+	    </para>
+	    <para>
+	      The <literal>hesiod</literal> class is
+	      named for an information service from MIT's Project Athena. It
+	      is
+	      used to share information about various systems databases, such
+	      as users, groups, printers and so on. The keyword
+	      <literal>HS</literal> is
+	      a synonym for hesiod.
+	    </para>
+	    <para>
+	      Another MIT development is Chaosnet, a LAN protocol created
+	      in the mid-1970s. Zone data for it can be specified with the <literal>CHAOS</literal> class.
+	    </para>
+	  </section>
+
+	  <section xml:id="zone_options"><info><title>Zone Options</title></info>
+
+	    <variablelist>
+
+	      <varlistentry>
+		<term><command>allow-notify</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>allow-notify</command> in <xref linkend="access_control"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>allow-query</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>allow-query</command> in <xref linkend="access_control"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>allow-query-on</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>allow-query-on</command> in <xref linkend="access_control"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>allow-transfer</command></term>
+		<listitem>
+		  <para>
+		    See the description of <command>allow-transfer</command>
+		    in <xref linkend="access_control"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>allow-update</command></term>
+		<listitem>
+		  <para>
+		    See the description of <command>allow-update</command>
+		    in <xref linkend="access_control"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>update-policy</command></term>
+		<listitem>
+		  <para>
+		    Specifies a "Simple Secure Update" policy. See
+		    <xref linkend="dynamic_update_policies"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>allow-update-forwarding</command></term>
+		<listitem>
+		  <para>
+		    See the description of <command>allow-update-forwarding</command>
+		    in <xref linkend="access_control"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>also-notify</command></term>
+		<listitem>
+		  <para>
+		    Only meaningful if <command>notify</command>
+		    is
+		    active for this zone. The set of machines that will
+		    receive a
+		    <literal>DNS NOTIFY</literal> message
+		    for this zone is made up of all the listed name servers
+		    (other than
+		    the primary master) for the zone plus any IP addresses
+		    specified
+		    with <command>also-notify</command>. A port
+		    may be specified
+		    with each <command>also-notify</command>
+		    address to send the notify
+		    messages to a port other than the default of 53.
+		    A TSIG key may also be specified to cause the
+		    <literal>NOTIFY</literal> to be signed by the
+		    given key.
+		    <command>also-notify</command> is not
+		    meaningful for stub zones.
+		    The default is the empty list.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>check-names</command></term>
+		<listitem>
+		  <para>
+		    This option is used to restrict the character set and
+		    syntax of
+		    certain domain names in master files and/or DNS responses
+		    received from the
+		    network.  The default varies according to zone type.  For <command>master</command> zones the default is <command>fail</command>.  For <command>slave</command>
+		    zones the default is <command>warn</command>.
+		    It is not implemented for <command>hint</command> zones.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>check-mx</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>check-mx</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>check-spf</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>check-spf</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>check-wildcard</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>check-wildcard</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>check-integrity</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>check-integrity</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>check-sibling</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>check-sibling</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>zero-no-soa-ttl</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>zero-no-soa-ttl</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>update-check-ksk</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>update-check-ksk</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>dnssec-loadkeys-interval</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>dnssec-loadkeys-interval</command> in <xref linkend="options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>dnssec-update-mode</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>dnssec-update-mode</command> in <xref linkend="options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>dnssec-dnskey-kskonly</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>dnssec-dnskey-kskonly</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>try-tcp-refresh</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>try-tcp-refresh</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>database</command></term>
+		<listitem>
+		  <para>
+		    Specify the type of database to be used for storing the
+		    zone data.  The string following the <command>database</command> keyword
+		    is interpreted as a list of whitespace-delimited words.
+		    The first word
+		    identifies the database type, and any subsequent words are
+		    passed
+		    as arguments to the database to be interpreted in a way
+		    specific
+		    to the database type.
+		  </para>
+		  <para>
+		    The default is <userinput>"rbt"</userinput>, BIND 9's
+		    native in-memory
+		    red-black-tree database.  This database does not take
+		    arguments.
+		  </para>
+		  <para>
+		    Other values are possible if additional database drivers
+		    have been linked into the server.  Some sample drivers are
+		    included
+		    with the distribution but none are linked in by default.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>dialup</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>dialup</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>delegation-only</command></term>
+		<listitem>
+		  <para>
+		    The flag only applies to forward, hint and stub
+		    zones.  If set to <userinput>yes</userinput>,
+		    then the zone will also be treated as if it is
+		    also a delegation-only type zone.
+		  </para>
+		  <para>
+		    See caveats in <xref linkend="root_delegation_only"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>file</command></term>
+		<listitem>
+		  <para>
+		    Set the zone's filename. In <command>master</command>,
+		    <command>hint</command>, and <command>redirect</command>
+		    zones which do not have <command>masters</command>
+		    defined, zone data is loaded from this file. In
+		    <command>slave</command>, <command>stub</command>, and
+		    <command>redirect</command> zones which do have
+		    <command>masters</command> defined, zone data is
+		    retrieved from another server and saved in this file.
+		    This option is not applicable to other zone types.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>forward</command></term>
+		<listitem>
+		  <para>
+		    Only meaningful if the zone has a forwarders
+		    list. The <command>only</command> value causes
+		    the lookup to fail
+		    after trying the forwarders and getting no answer, while <command>first</command> would
+		    allow a normal lookup to be tried.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>forwarders</command></term>
+		<listitem>
+		  <para>
+		    Used to override the list of global forwarders.
+		    If it is not specified in a zone of type <command>forward</command>,
+		    no forwarding is done for the zone and the global options are
+		    not used.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>ixfr-base</command></term>
+		<listitem>
+		  <para>
+		    Was used in <acronym>BIND</acronym> 8 to
+		    specify the name
+		    of the transaction log (journal) file for dynamic update
+		    and IXFR.
+		    <acronym>BIND</acronym> 9 ignores the option
+		    and constructs the name of the journal
+		    file by appending "<filename>.jnl</filename>"
+		    to the name of the
+		    zone file.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>ixfr-tmp-file</command></term>
+		<listitem>
+		  <para>
+		    Was an undocumented option in <acronym>BIND</acronym> 8.
+		    Ignored in <acronym>BIND</acronym> 9.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>journal</command></term>
+		<listitem>
+		  <para>
+		    Allow the default journal's filename to be overridden.
+		    The default is the zone's filename with "<filename>.jnl</filename>" appended.
+		    This is applicable to <command>master</command> and <command>slave</command> zones.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>max-journal-size</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>max-journal-size</command> in <xref linkend="server_resource_limits"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>max-records</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>max-records</command> in <xref linkend="server_resource_limits"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>max-transfer-time-in</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>max-transfer-time-in</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>max-transfer-idle-in</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>max-transfer-idle-in</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>max-transfer-time-out</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>max-transfer-time-out</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>max-transfer-idle-out</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>max-transfer-idle-out</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>notify</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>notify</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>notify-delay</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>notify-delay</command> in <xref linkend="tuning"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>notify-to-soa</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>notify-to-soa</command> in
+		    <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>pubkey</command></term>
+		<listitem>
+		  <para>
+		    In <acronym>BIND</acronym> 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. <acronym>BIND</acronym> 9 does not verify signatures
+		    on load and ignores the option.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>zone-statistics</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>zone-statistics</command> in
+		    <xref linkend="options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>server-addresses</command></term>
+		<listitem>
+		  <para>
+		    Only meaningful for static-stub zones.
+		    This is a list of IP addresses to which queries
+		    should be sent in recursive resolution for the
+		    zone.
+		    A non empty list for this option will internally
+		    configure the apex NS RR with associated glue A or
+		    AAAA RRs.
+		  </para>
+		  <para>
+		    For example, if "example.com" is configured as a
+		    static-stub zone with 192.0.2.1 and 2001:db8::1234
+		    in a <command>server-addresses</command> option,
+		    the following RRs will be internally configured.
+		  </para>
+<programlisting>example.com. NS example.com.
+example.com. A 192.0.2.1
+example.com. AAAA 2001:db8::1234</programlisting>
+		  <para>
+		    These records are internally used to resolve
+		    names under the static-stub zone.
+		    For instance, if the server receives a query for
+		    "www.example.com" with the RD bit on, the server
+		    will initiate recursive resolution and send
+		    queries to 192.0.2.1 and/or 2001:db8::1234.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>server-names</command></term>
+		<listitem>
+		  <para>
+		    Only meaningful for static-stub zones.
+		    This is a list of domain names of nameservers that
+		    act as authoritative servers of the static-stub
+		    zone.
+		    These names will be resolved to IP addresses when
+		    <command>named</command> needs to send queries to
+		    these servers.
+		    To make this supplemental resolution successful,
+		    these names must not be a subdomain of the origin
+		    name of static-stub zone.
+		    That is, when "example.net" is the origin of a
+		    static-stub zone, "ns.example" and
+		    "master.example.com" can be specified in the
+		    <command>server-names</command> option, but
+		    "ns.example.net" cannot, and will be rejected by
+		    the configuration parser.
+		  </para>
+		  <para>
+		    A non empty list for this option will internally
+		    configure the apex NS RR with the specified names.
+		    For example, if "example.com" is configured as a
+		    static-stub zone with "ns1.example.net" and
+		    "ns2.example.net"
+		    in a <command>server-names</command> option,
+		    the following RRs will be internally configured.
+		  </para>
+<programlisting>example.com. NS ns1.example.net.
+example.com. NS ns2.example.net.
+</programlisting>
+		  <para>
+		    These records are internally used to resolve
+		    names under the static-stub zone.
+		    For instance, if the server receives a query for
+		    "www.example.com" with the RD bit on, the server
+		    initiate recursive resolution,
+		    resolve "ns1.example.net" and/or
+		    "ns2.example.net" to IP addresses, and then send
+		    queries to (one or more of) these addresses.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>sig-validity-interval</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>sig-validity-interval</command> in <xref linkend="tuning"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>sig-signing-nodes</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>sig-signing-nodes</command> in <xref linkend="tuning"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>sig-signing-signatures</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>sig-signing-signatures</command> in <xref linkend="tuning"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>sig-signing-type</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>sig-signing-type</command> in <xref linkend="tuning"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>transfer-source</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>transfer-source</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>transfer-source-v6</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>transfer-source-v6</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>alt-transfer-source</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>alt-transfer-source</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>alt-transfer-source-v6</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>alt-transfer-source-v6</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>use-alt-transfer-source</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>use-alt-transfer-source</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+
+	      <varlistentry>
+		<term><command>notify-source</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>notify-source</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>notify-source-v6</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>notify-source-v6</command> in <xref linkend="zone_transfers"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>min-refresh-time</command></term>
+		<term><command>max-refresh-time</command></term>
+		<term><command>min-retry-time</command></term>
+		<term><command>max-retry-time</command></term>
+		<listitem>
+		  <para>
+		    See the description in <xref linkend="tuning"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>ixfr-from-differences</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>ixfr-from-differences</command> in <xref linkend="boolean_options"/>.
+		    (Note that the <command>ixfr-from-differences</command>
+		    <userinput>master</userinput> and
+		    <userinput>slave</userinput> choices are not
+		    available at the zone level.)
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>key-directory</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>key-directory</command> in <xref linkend="options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>auto-dnssec</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>auto-dnssec</command> in
+		    <xref linkend="options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>serial-update-method</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>serial-update-method</command> in
+		    <xref linkend="options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>inline-signing</command></term>
+		<listitem>
+		  <para>
+		    If <literal>yes</literal>, this enables
+		    "bump in the wire" signing of a zone, where a
+		    unsigned zone is transferred in or loaded from
+		    disk and a signed version of the zone is served,
+		    with possibly, a different serial number.  This
+		    behavior is disabled by default.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>multi-master</command></term>
+		<listitem>
+		  <para>
+		    See the description of <command>multi-master</command> in
+		    <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>masterfile-format</command></term>
+		<listitem>
+		  <para>
+		    See the description of <command>masterfile-format</command>
+		    in <xref linkend="tuning"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>max-zone-ttl</command></term>
+		<listitem>
+		  <para>
+		    See the description of <command>max-zone-ttl</command>
+		    in <xref linkend="options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>dnssec-secure-to-insecure</command></term>
+		<listitem>
+		  <para>
+		    See the description of
+		    <command>dnssec-secure-to-insecure</command> in <xref linkend="boolean_options"/>.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	    </variablelist>
+
+	  </section>
+	  <section xml:id="dynamic_update_policies"><info><title>Dynamic Update Policies</title></info>
+
+	    <para><acronym>BIND</acronym> 9 supports two alternative
+	      methods of granting clients the right to perform
+	      dynamic updates to a zone, configured by the
+	      <command>allow-update</command> and
+	      <command>update-policy</command> option, respectively.
+	    </para>
+	    <para>
+	      The <command>allow-update</command> clause is a simple
+	      access control list.  Any client that matches
+	      the ACL is granted permission to update any record
+	      in the zone.
+	    </para>
+	    <para>
+	      The <command>update-policy</command> clause
+	      allows more fine-grained control over what 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).
+	      In most cases, <command>update-policy</command> rules
+	      only apply to key-based identities.  There is no way
+	      to specify update permissions based on client source
+	      address.
+	    </para>
+	    <para>
+	      <command>update-policy</command> rules are only meaningful
+	      for zones of type <command>master</command>, and are
+	      not allowed in any other zone type.
+	      It is a configuration error to specify both
+	      <command>allow-update</command> and
+	      <command>update-policy</command> at the same time.
+	    </para>
+	    <para>
+	      A pre-defined <command>update-policy</command> rule can be
+	      switched on with the command
+	      <command>update-policy local;</command>.
+	      Using this in a zone causes
+	      <command>named</command> to generate a TSIG session key
+	      when starting up and store it in a file; this key can then
+	      be used by local clients to update the zone while
+	      <command>named</command> is running.
+	      By default, the session key is stored in the file
+	      <filename>/var/run/named/session.key</filename>, the key name
+	      is "local-ddns", and the key algorithm is HMAC-SHA256.
+	      These values are configurable with the
+	      <command>session-keyfile</command>,
+	      <command>session-keyname</command> and
+	      <command>session-keyalg</command> 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
+	      within the zone.  Assuming the key name is "local-ddns",
+	      this policy is equivalent to:
+	    </para>
+
+	    <programlisting>update-policy { grant local-ddns zonesub any; };
+	    </programlisting>
+
+	    <para>
+	      ...with the additional restriction that only clients
+	      connecting from the local system will be permitted to send
+	      updates.
+	    </para>
+	    <para>
+	      Note that only one session key is generated by
+	      <command>named</command>; all zones configured to use
+	      <command>update-policy local</command> will accept the same key.
+	    </para>
+	    <para>
+	      The command <command>nsupdate -l</command> implements this
+	      feature, sending requests to localhost and signing them using
+	      the key retrieved from the session key file.
+	    </para>
+
+	    <para>
+	      Other rule definitions look like this:
+	    </para>
+
+<programlisting>
+( <command>grant</command> | <command>deny</command> ) <replaceable>identity</replaceable> <replaceable>ruletype</replaceable> <optional> <replaceable>name</replaceable> </optional> <optional> <replaceable>types</replaceable> </optional>
+</programlisting>
+
+	    <para>
+	      Each rule grants or denies privileges.  Rules are checked
+	      in the order in which they are specified in the
+	      <command>update-policy</command> statement. Once a message
+	      has successfully matched a rule, the operation is immediately
+	      granted or denied, and no further rules are examined.  There
+	      are 13 types of rules; the rule type is specified by the
+	      <command>ruletype</command> field, and the interpretation
+	      of other fields varies depending on the rule type.
+	    </para>
+	    <para>
+	      In general, a rule is matched when the
+	      key that signed an update request matches the
+	      <command>identity</command> field, the name of the record
+	      to be updated matches the <command>name</command> field
+	      (in the manner specified by the <command>ruletype</command>
+	      field), and the type of the record to be updated matches the
+	      <command>types</command> field. Details for each rule type
+	      are described below.
+	    </para>
+	    <para>
+	      The <command>identity</command> 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
+	      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
+	      used as the identity of the shared secret.  Some rule types
+	      use identities matching the client's Kerberos principal
+	      (e.g, <userinput>"host/machine@REALM"</userinput>) or
+	      Windows realm (<userinput>machine$@REALM</userinput>).
+	    </para>
+	    <para>
+	      The <replaceable>name</replaceable> field also specifies
+	      a fully-qualified domain name. This often
+	      represents the name of the record to be updated.
+	      Interpretation of this field is dependent on rule type.
+	    </para>
+	    <para>
+	      If no <command>types</command> are explicitly specified,
+	      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
+	      is made to delete all records associated with a name,
+	      the rules are checked for each existing record type.
+	    </para>
+	    <para>
+	      The <replaceable>ruletype</replaceable> field has 16
+	      values:
+	      <varname>name</varname>, <varname>subdomain</varname>,
+	      <varname>wildcard</varname>, <varname>self</varname>,
+	      <varname>selfsub</varname>, <varname>selfwild</varname>,
+	      <varname>krb5-self</varname>, <varname>ms-self</varname>,
+	      <varname>krb5-selfsub</varname>, <varname>ms-selfsub</varname>,
+	      <varname>krb5-subdomain</varname>,
+	      <varname>ms-subdomain</varname>,
+	      <varname>tcp-self</varname>, <varname>6to4-self</varname>,
+	      <varname>zonesub</varname>, and <varname>external</varname>.
+	    </para>
+	    <informaltable>
+	      <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="0.819in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="3.681in"/>
+		<tbody>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>name</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			Exact-match semantics.  This rule matches
+			when the name being updated is identical
+			to the contents of the
+			<replaceable>name</replaceable> field.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>subdomain</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule matches when the name being updated
+			is a subdomain of, or identical to, the
+			contents of the <replaceable>name</replaceable>
+			field.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>zonesub</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule is similar to subdomain, except that
+			it matches when the name being updated is a
+			subdomain of the zone in which the
+			<command>update-policy</command> statement
+			appears.  This obviates the need to type the zone
+			name twice, and enables the use of a standard
+			<command>update-policy</command> statement in
+			multiple zones without modification.
+		      </para>
+		      <para>
+			When this rule is used, the
+			<replaceable>name</replaceable> field is omitted.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>wildcard</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			The <replaceable>name</replaceable> field
+			is subject to DNS wildcard expansion, and
+			this rule matches when the name being updated
+			is a valid expansion of the wildcard.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>self</varname>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			This rule matches when the name of the record
+			being updated matches the contents of the
+			<replaceable>identity</replaceable> field.
+			The <replaceable>name</replaceable> field
+			is ignored. To avoid confusion, it is recommended
+			that this field be set to the same value as the
+			<replaceable>identity</replaceable> field or to
+			"."
+		      </para>
+		      <para>
+			The <varname>self</varname> rule type is
+			most useful when allowing one key per
+			name to update, where the key has the same
+			name as the record to be updated.  In this case,
+			the <replaceable>identity</replaceable> field
+			can be specified as <constant>*</constant>
+			(an asterisk).
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>selfsub</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule is similar to <varname>self</varname>
+			except that subdomains of <varname>self</varname>
+			can also be updated.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>selfwild</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule is similar to <varname>self</varname>
+			except that only subdomains of
+			<varname>self</varname> can be updated.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>ms-self</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			When a client sends an UPDATE using a Windows
+			machine principal (for example, 'machine$@REALM'),
+			this rule allows records with the absolute name
+			of 'machine.REALM' to be updated.
+		      </para>
+		      <para>
+			The realm to be matched is specified in the
+			<replaceable>identity</replaceable> field.
+		      </para>
+		      <para>
+			The <replaceable>name</replaceable> field has
+			no effect on this rule; it should be set to "."
+			as a placeholder.
+		      </para>
+		      <para>
+			For example,
+			<userinput>grant EXAMPLE.COM ms-self . A AAAA</userinput>
+			allows any machine with a valid principal in
+			the realm <userinput>EXAMPLE.COM</userinput> to update
+			its own address records.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>ms-selfsub</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This is similar to <command>ms-self</command>
+			except it also allows updates to any subdomain of
+			the name specified in the Windows machine
+			principal, not just to the name itself.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>ms-subdomain</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			When a client sends an UPDATE using a Windows
+			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.
+		      </para>
+		      <para>
+			The realm to be matched is specified in the
+			<replaceable>identity</replaceable> field.
+		      </para>
+		      <para>
+			The <replaceable>name</replaceable> 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
+			updated.
+		      </para>
+		      <para>
+			For example, if <command>update-policy</command>
+			for the zone "example.com" includes
+			<userinput>grant EXAMPLE.COM ms-subdomain hosts.example.com. A AAAA</userinput>,
+			any machine with a valid principal in
+			the realm <userinput>EXAMPLE.COM</userinput> will
+			be able to update address records at or below
+			"hosts.example.com".
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>krb5-self</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			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
+			by REALM.  This is similar but not identical
+			to <command>ms-self</command> due to the
+			'machine' part of the Kerberos principal
+			being an absolute name instead of a unqualified
+			name.
+		      </para>
+		      <para>
+			The realm to be matched is specified in the
+			<replaceable>identity</replaceable> field.
+		      </para>
+		      <para>
+			The <replaceable>name</replaceable> field has
+			no effect on this rule; it should be set to "."
+			as a placeholder.
+		      </para>
+		      <para>
+			For example,
+			<userinput>grant EXAMPLE.COM krb5-self . A AAAA</userinput>
+			allows any machine with a valid principal in
+			the realm <userinput>EXAMPLE.COM</userinput> to update
+			its own address records.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>krb5-selfsub</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This is similar to <command>krb5-self</command>
+			except it also allows updates to any subdomain of
+			the name specified in the 'machine' part of the
+			Kerberos principal, not just to the name itself.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>krb5-subdomain</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule is identical to
+			<command>ms-subdomain</command>, except that it works
+			with Kerberos machine principals (i.e.,
+			'host/machine@REALM') rather than Windows machine
+			principals.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>tcp-self</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule allows updates that have been sent via
+			TCP and for which the standard mapping from the
+			client's IP address into the
+			<literal>in-addr.arpa</literal> and
+			<literal>ip6.arpa</literal>
+			namespaces match the name to be updated.
+			The <command>identity</command> field must match
+			that name.  The <command>name</command> field
+			should be set to ".".
+			Note that, since identity is based on the client's
+			IP address, it is not necessary for update request
+			messages to be signed.
+		      </para>
+		      <note>
+			It is theoretically possible to spoof these TCP
+			sessions.
+		      </note>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>6to4-self</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This allows the name matching a 6to4 IPv6 prefix,
+			as specified in RFC 3056, to be updated by any
+			TCP connection from either the 6to4 network or
+			from the corresponding IPv4 address.  This is
+			intended to allow NS or DNAME RRsets to be added
+			to the <literal>ip6.arpa</literal> reverse tree.
+		      </para>
+		      <para>
+			The <command>identity</command> field must match
+			the 6to4 prefix in <literal>ip6.arpa</literal>.
+			The <command>name</command> field should
+			be set to ".".
+			Note that, since identity is based on the client's
+			IP address, it is not necessary for update request
+			messages to be signed.
+		      </para>
+		      <para>
+			In addition, if specified for an
+			<literal>ip6.arpa</literal> name outside of the
+			<literal>2.0.0.2.ip6.arpa</literal> namespace,
+			the corresponding /48 reverse name can be updated.
+			For example, TCP/IPv6 connections
+			from 2001:DB8:ED0C::/48 can update records at
+			<literal>C.0.D.E.8.B.D.0.1.0.0.2.ip6.arpa</literal>.
+		      </para>
+		      <note>
+			It is theoretically possible to spoof these TCP
+			sessions.
+		      </note>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>external</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			This rule allows <command>named</command>
+			to defer the decision of whether to allow a
+			given update to an external daemon.
+		      </para>
+		      <para>
+			The method of communicating with the daemon is
+			specified in the <replaceable>identity</replaceable>
+			field, the format of which is
+			"<constant>local:</constant><replaceable>path</replaceable>",
+			where <replaceable>path</replaceable> is the location
+			of a UNIX-domain socket.  (Currently, "local" is the
+			only supported mechanism.)
+		      </para>
+		      <para>
+			Requests to the external daemon are sent over the
+			UNIX-domain socket as datagrams with the following
+			format:
+		      </para>
+		      <programlisting>
+   Protocol version number (4 bytes, network byte order, currently 1)
+   Request length (4 bytes, network byte order)
+   Signer (null-terminated string)
+   Name (null-terminated string)
+   TCP source address (null-terminated string)
+   Rdata type (null-terminated string)
+   Key (null-terminated string)
+   TKEY token length (4 bytes, network byte order)
+   TKEY token (remainder of packet)</programlisting>
+		      <para>
+			The daemon replies with a four-byte value in
+			network byte order, containing either 0 or 1; 0
+			indicates that the specified update is not
+			permitted, and 1 indicates that it is.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	  </section>
+
+	  <section xml:id="multiple_views"><info><title>Multiple views</title></info>
+
+	    <para>
+	      When multiple views are in use, a zone may be
+	      referenced by more than one of them. Often, the views
+	      will contain different zones with the same name, allowing
+	      different clients to receive different answers for the same
+	      queries. At times, however, it is desirable for multiple
+	      views to contain identical zones.  The
+	      <command>in-view</command> zone option provides an efficient
+	      way to do this: it allows a view to reference a zone that
+	      was defined in a previously configured view. Example:
+	    </para>
+	    <programlisting>
+view internal {
+    match-clients { 10/8; };
+
+    zone example.com {
+	type master;
+	file "example-external.db";
+    };
+};
+
+view external {
+    match-clients { any; };
+
+    zone example.com {
+	in-view internal;
+    };
+};
+	    </programlisting>
+	    <para>
+	      An <command>in-view</command> option cannot refer to a view
+	      that is configured later in the configuration file.
+	    </para>
+	    <para>
+	      A <command>zone</command> statement which uses the
+	      <command>in-view</command> option may not use any other
+	      options with the exception of <command>forward</command>
+	      and <command>forwarders</command>. (These options control
+	      the behavior of the containing view, rather than changing
+	      the zone object itself.)
+	    </para>
+	    <para>
+	      Zone level acls (e.g. allow-query, allow-transfer) and
+	      other configuration details of the zone are all set
+	      in the view the referenced zone is defined in.  Care
+	      need to be taken to ensure that acls are wide enough
+	      for all views referencing the zone.
+	    </para>
+	    <para>
+	      An <command>in-view</command> zone cannot be used as a
+	      response policy zone.
+	    </para>
+	    <para>
+	      An <command>in-view</command> zone is not intended to reference
+	      a <command>forward</command> zone.
+	    </para>
+	  </section>
+
+	</section>
+      </section>
+      <section xml:id="zone_file"><info><title>Zone File</title></info>
+
+	<section xml:id="types_of_resource_records_and_when_to_use_them"><info><title>Types of Resource Records and When to Use Them</title></info>
+
+	  <para>
+	    This section, largely borrowed from RFC 1034, describes the
+	    concept of a Resource Record (RR) and explains when each is used.
+	    Since the publication of RFC 1034, several new RRs have been
+	    identified
+	    and implemented in the DNS. These are also included.
+	  </para>
+	  <section><info><title>Resource Records</title></info>
+
+	    <para>
+	      A domain name identifies a node.  Each node has a set of
+	      resource information, which may be empty.  The set of resource
+	      information associated with a particular name is composed of
+	      separate RRs. The order of RRs in a set is not significant and
+	      need not be preserved by name servers, resolvers, or other
+	      parts of the DNS. However, sorting of multiple RRs is
+	      permitted for optimization purposes, for example, to specify
+	      that a particular nearby server be tried first. See <xref linkend="the_sortlist_statement"/> and <xref linkend="rrset_ordering"/>.
+	    </para>
+
+	    <para>
+	      The components of a Resource Record are:
+	    </para>
+	    <informaltable colsep="0" rowsep="0">
+	      <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.000in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="3.500in"/>
+		<tbody>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			owner name
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			The domain name where the RR is found.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			type
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			An encoded 16-bit value that specifies
+			the type of the resource record.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			TTL
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			The time-to-live of the RR. This field
+			is a 32-bit integer in units of seconds, and is
+			primarily used by
+			resolvers when they cache RRs. The TTL describes how
+			long a RR can
+			be cached before it should be discarded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			class
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			An encoded 16-bit value that identifies
+			a protocol family or instance of a protocol.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			RDATA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			The resource data.  The format of the
+			data is type (and sometimes class) specific.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	    <para>
+	      The following are <emphasis>types</emphasis> of valid RRs:
+	    </para>
+	    <informaltable colsep="0" rowsep="0">
+	      <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="3.625in"/>
+		<tbody>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			A
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A host address.  In the IN class, this is a
+			32-bit IP address.  Described in RFC 1035.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			AAAA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 address.  Described in RFC 1886.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			A6
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			AFSDB
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Location of AFS database servers.
+			Experimental.  Described in RFC 1183.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			APL
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Address prefix list.  Experimental.
+			Described in RFC 3123.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			ATMA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			ATM Address.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			AVC
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Application Visibility and Control record.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			CAA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Identifies which Certificate Authorities can issue
+			certificates for this domain and what rules they
+			need to follow when doing so. Defined in RFC 6844.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			CDNSKEY
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Identifies which DNSKEY records should be published
+			as DS records in the parent zone.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			CDS
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Contains the set of DS records that should be published
+			by the parent zone.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			CERT
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Holds a digital certificate.
+			Described in RFC 2538.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			CNAME
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Identifies the canonical name of an alias.
+			Described in RFC 1035.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			CSYNC
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Child-to-Parent Synchronization in DNS as described
+			in RFC 7477.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			DHCID
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Is used for identifying which DHCP client is
+			associated with this name.  Described in RFC 4701.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			DLV
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			DNAME
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			DNSKEY
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Stores a public key associated with a signed
+			DNS zone.  Described in RFC 4034.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			DOA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Implements the Digital Object Architecture over
+			DNS. Experimental.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			DS
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Stores the hash of a public key associated with a
+			signed DNS zone.  Described in RFC 4034.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			EID
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			End Point Identifier.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			EUI48
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A 48-bit EUI address. Described in RFC 7043.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			EUI64
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A 64-bit EUI address. Described in RFC 7043.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			GID
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Reserved.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			GPOS
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Specifies the global position.  Superseded by LOC.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			HINFO
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Identifies the CPU and OS used by a host.
+			Described in RFC 1035.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			HIP
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Host Identity Protocol Address.
+			Described in RFC 5205.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			IPSECKEY
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Provides a method for storing IPsec keying material in
+			DNS.  Described in RFC 4025.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			ISDN
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Representation of ISDN addresses.
+			Experimental.  Described in RFC 1183.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			KEY
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			KX
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Identifies a key exchanger for this
+			DNS name.  Described in RFC 2230.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			L32
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Holds 32-bit Locator values for
+			Identifier-Locator Network Protocol. Described
+			in RFC 6742.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			L64
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Holds 64-bit Locator values for
+			Identifier-Locator Network Protocol. Described
+			in RFC 6742.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			LOC
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			For storing GPS info.  Described in RFC 1876.
+			Experimental.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			LP
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Identifier-Locator Network Protocol.
+			Described in RFC 6742.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			MB
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Mail Box.  Historical.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			MD
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Mail Destination.  Historical.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			MF
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Mail Forwarder.  Historical.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			MG
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Mail Group.  Historical.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			MINFO
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Mail Information.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			MR
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Mail Rename. Historical.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			MX
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NAPTR
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Name authority pointer.  Described in RFC 2915.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NID
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Holds values for Node Identifiers in
+			Identifier-Locator Network Protocol. Described
+			in RFC 6742.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NINFO
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Contains zone status information.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NIMLOC
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Nimrod Locator.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NSAP
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A network service access point.
+			Described in RFC 1706.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NSAP-PTR
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Historical.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NS
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			The authoritative name server for the
+			domain.  Described in RFC 1035.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NSEC
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NSEC3
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NSEC3PARAM
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Used in DNSSECbis to tell the authoritative
+			server which NSEC3 chains are available to use.
+			Described in RFC 5155.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NULL
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			This is an opaque container.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			NXT
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			OPENPGPKEY
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Used to hold an OPENPGPKEY.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			PTR
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			A pointer to another part of the domain
+			name space.  Described in RFC 1035.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			PX
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Provides mappings between RFC 822 and X.400
+			addresses.  Described in RFC 2163.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			RKEY
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Resource key.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			RP
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Information on persons responsible
+			for the domain.  Experimental.  Described in RFC 1183.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			RRSIG
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Contains DNSSECbis signature data.  Described
+			in RFC 4034.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			RT
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Route-through binding for hosts that
+			do not have their own direct wide area network
+			addresses.
+			Experimental.  Described in RFC 1183.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			SIG
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			SINK
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			The kitchen sink record.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			SMIMEA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			The S/MIME Security Certificate Association.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			SOA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Identifies the start of a zone of authority.
+			Described in RFC 1035.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			SPF
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Contains the Sender Policy Framework information
+			for a given email domain.  Described in RFC 4408.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			SRV
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Information about well known network
+			services (replaces WKS).  Described in RFC 2782.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			SSHFP
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Provides a way to securely publish a secure shell key's
+			fingerprint.  Described in RFC 4255.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			TA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Trust Anchor. Experimental.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			TALINK
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Trust Anchor Link.  Experimental.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			TLSA
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Transport Layer Security Certificate Association.
+			Described in RFC 6698.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			TXT
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Text records.  Described in RFC 1035.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			UID
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Reserved.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			UINFO
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Reserved.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			UNSPEC
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Reserved. Historical.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			URI
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Holds a URI. Described in RFC 7553.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			WKS
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Information about which well known
+			network services, such as SMTP, that a domain
+			supports. Historical.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			X25
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Representation of X.25 network addresses.
+			Experimental.  Described in RFC 1183.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	    <para>
+	      The following <emphasis>classes</emphasis> of resource records
+	      are currently valid in the DNS:
+	    </para>
+	    <informaltable colsep="0" rowsep="0"><tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="3.625in"/>
+		<tbody>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			IN
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			The Internet.
+		      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			CH
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Chaosnet, a LAN protocol created at MIT in the
+			mid-1970s.
+			Rarely used for its historical purpose, but reused for
+			BIND's
+			built-in server information zones, e.g.,
+			<literal>version.bind</literal>.
+		      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			HS
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Hesiod, an information service
+			developed by MIT's Project Athena. It is used to share
+			information
+			about various systems databases, such as users,
+			groups, printers
+			and so on.
+		      </para>
+		    </entry>
+		  </row>
+
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+
+	    <para>
+	      The owner name is often implicit, rather than forming an
+	      integral
+	      part of the RR.  For example, many name servers internally form
+	      tree
+	      or hash structures for the name space, and chain RRs off nodes.
+	      The remaining RR parts are the fixed header (type, class, TTL)
+	      which is consistent for all RRs, and a variable part (RDATA)
+	      that
+	      fits the needs of the resource being described.
+	    </para>
+	    <para>
+	      The meaning of the TTL field is a time limit on how long an
+	      RR can be kept in a cache.  This limit does not apply to
+	      authoritative
+	      data in zones; it is also timed out, but by the refreshing
+	      policies
+	      for the zone.  The TTL is assigned by the administrator for the
+	      zone where the data originates.  While short TTLs can be used to
+	      minimize caching, and a zero TTL prohibits caching, the
+	      realities
+	      of Internet performance suggest that these times should be on
+	      the
+	      order of days for the typical host.  If a change can be
+	      anticipated,
+	      the TTL can be reduced prior to the change to minimize
+	      inconsistency
+	      during the change, and then increased back to its former value
+	      following
+	      the change.
+	    </para>
+	    <para>
+	      The data in the RDATA section of RRs is carried as a combination
+	      of binary strings and domain names.  The domain names are
+	      frequently
+	      used as "pointers" to other data in the DNS.
+	    </para>
+	  </section>
+	  <section xml:id="rr_text"><info><title>Textual expression of RRs</title></info>
+
+	    <para>
+	      RRs are represented in binary form in the packets of the DNS
+	      protocol, and are usually represented in highly encoded form
+	      when
+	      stored in a name server or resolver.  In the examples provided
+	      in
+	      RFC 1034, a style similar to that used in master files was
+	      employed
+	      in order to show the contents of RRs.  In this format, most RRs
+	      are shown on a single line, although continuation lines are
+	      possible
+	      using parentheses.
+	    </para>
+	    <para>
+	      The start of the line gives the owner of the RR.  If a line
+	      begins with a blank, then the owner is assumed to be the same as
+	      that of the previous RR.  Blank lines are often included for
+	      readability.
+	    </para>
+	    <para>
+	      Following the owner, we list the TTL, type, and class of the
+	      RR.  Class and type use the mnemonics defined above, and TTL is
+	      an integer before the type field.  In order to avoid ambiguity
+	      in
+	      parsing, type and class mnemonics are disjoint, TTLs are
+	      integers,
+	      and the type mnemonic is always last. The IN class and TTL
+	      values
+	      are often omitted from examples in the interests of clarity.
+	    </para>
+	    <para>
+	      The resource data or RDATA section of the RR are given using
+	      knowledge of the typical representation for the data.
+	    </para>
+	    <para>
+	      For example, we might show the RRs carried in a message as:
+	    </para>
+	    <informaltable colsep="0" rowsep="0"><tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.381in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="1.020in"/>
+		<colspec colname="3" colnum="3" colsep="0" colwidth="2.099in"/>
+		<tbody>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<literal>ISI.EDU.</literal>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<literal>MX</literal>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<literal>10 VENERA.ISI.EDU.</literal>
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para/>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<literal>MX</literal>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<literal>10 VAXA.ISI.EDU</literal>
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<literal>VENERA.ISI.EDU</literal>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<literal>A</literal>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<literal>128.9.0.32</literal>
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para/>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<literal>A</literal>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<literal>10.1.0.52</literal>
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<literal>VAXA.ISI.EDU</literal>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<literal>A</literal>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<literal>10.2.0.27</literal>
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para/>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<literal>A</literal>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<literal>128.9.0.33</literal>
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	    <para>
+	      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.
+	    </para>
+	    <para>
+	      The above example shows six RRs, with two RRs at each of three
+	      domain names.
+	    </para>
+	    <para>
+	      Similarly we might see:
+	    </para>
+	    <informaltable colsep="0" rowsep="0"><tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.491in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="1.067in"/>
+		<colspec colname="3" colnum="3" colsep="0" colwidth="2.067in"/>
+		<tbody>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<literal>XX.LCS.MIT.EDU.</literal>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<literal>IN A</literal>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<literal>10.0.0.44</literal>
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1"/>
+		    <entry colname="2">
+		      <para>
+			<literal>CH A</literal>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<literal>MIT.EDU. 2420</literal>
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	    <para>
+	      This example shows two addresses for
+	      <literal>XX.LCS.MIT.EDU</literal>, each of a different class.
+	    </para>
+	  </section>
+	</section>
+
+	<section xml:id="mx_records"><info><title>Discussion of MX Records</title></info>
+
+	  <para>
+	    As described above, domain servers store information as a
+	    series of resource records, each of which contains a particular
+	    piece of information about a given domain name (which is usually,
+	    but not always, a host). The simplest way to think of a RR is as
+	    a typed pair of data, a domain name matched with a relevant datum,
+	    and stored with some additional type information to help systems
+	    determine when the RR is relevant.
+	  </para>
+
+	  <para>
+	    MX records are used to control delivery of email. The data
+	    specified in the record is a priority and a domain name. The
+	    priority
+	    controls the order in which email delivery is attempted, with the
+	    lowest number first. If two priorities are the same, a server is
+	    chosen randomly. If no servers at a given priority are responding,
+	    the mail transport agent will fall back to the next largest
+	    priority.
+	    Priority numbers do not have any absolute meaning — they are
+	    relevant
+	    only respective to other MX records for that domain name. The
+	    domain
+	    name given is the machine to which the mail will be delivered.
+	    It <emphasis>must</emphasis> have an associated address record
+	    (A or AAAA) — CNAME is not sufficient.
+	  </para>
+	  <para>
+	    For a given domain, if there is both a CNAME record and an
+	    MX record, the MX record is in error, and will be ignored.
+	    Instead,
+	    the mail will be delivered to the server specified in the MX
+	    record
+	    pointed to by the CNAME.
+	    For example:
+	  </para>
+	  <informaltable colsep="0" rowsep="0">
+	    <tgroup cols="5" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+	      <colspec colname="1" colnum="1" colsep="0" colwidth="1.708in"/>
+	      <colspec colname="2" colnum="2" colsep="0" colwidth="0.444in"/>
+	      <colspec colname="3" colnum="3" colsep="0" colwidth="0.444in"/>
+	      <colspec colname="4" colnum="4" colsep="0" colwidth="0.976in"/>
+	      <colspec colname="5" colnum="5" colsep="0" colwidth="1.553in"/>
+	      <tbody>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para>
+		      <literal>example.com.</literal>
+		    </para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      <literal>IN</literal>
+		    </para>
+		  </entry>
+		  <entry colname="3">
+		    <para>
+		      <literal>MX</literal>
+		    </para>
+		  </entry>
+		  <entry colname="4">
+		    <para>
+		      <literal>10</literal>
+		    </para>
+		  </entry>
+		  <entry colname="5">
+		    <para>
+		      <literal>mail.example.com.</literal>
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para/>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      <literal>IN</literal>
+		    </para>
+		  </entry>
+		  <entry colname="3">
+		    <para>
+		      <literal>MX</literal>
+		    </para>
+		  </entry>
+		  <entry colname="4">
+		    <para>
+		      <literal>10</literal>
+		    </para>
+		  </entry>
+		  <entry colname="5">
+		    <para>
+		      <literal>mail2.example.com.</literal>
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para/>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      <literal>IN</literal>
+		    </para>
+		  </entry>
+		  <entry colname="3">
+		    <para>
+		      <literal>MX</literal>
+		    </para>
+		  </entry>
+		  <entry colname="4">
+		    <para>
+		      <literal>20</literal>
+		    </para>
+		  </entry>
+		  <entry colname="5">
+		    <para>
+		      <literal>mail.backup.org.</literal>
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para>
+		      <literal>mail.example.com.</literal>
+		    </para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      <literal>IN</literal>
+		    </para>
+		  </entry>
+		  <entry colname="3">
+		    <para>
+		      <literal>A</literal>
+		    </para>
+		  </entry>
+		  <entry colname="4">
+		    <para>
+		      <literal>10.0.0.1</literal>
+		    </para>
+		  </entry>
+		  <entry colname="5">
+		    <para/>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para>
+		      <literal>mail2.example.com.</literal>
+		    </para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      <literal>IN</literal>
+		    </para>
+		  </entry>
+		  <entry colname="3">
+		    <para>
+		      <literal>A</literal>
+		    </para>
+		  </entry>
+		  <entry colname="4">
+		    <para>
+		      <literal>10.0.0.2</literal>
+		    </para>
+		  </entry>
+		  <entry colname="5">
+		    <para/>
+		  </entry>
+		</row>
+	      </tbody>
+	    </tgroup>
+	    </informaltable><para>
+	    Mail delivery will be attempted to <literal>mail.example.com</literal> and
+	    <literal>mail2.example.com</literal> (in
+	    any order), and if neither of those succeed, delivery to <literal>mail.backup.org</literal> will
+	    be attempted.
+	  </para>
+	</section>
+	<section xml:id="Setting_TTLs"><info><title>Setting TTLs</title></info>
+
+	  <para>
+	    The time-to-live of the RR field is a 32-bit integer represented
+	    in units of seconds, and is primarily used by resolvers when they
+	    cache RRs. The TTL describes how long a RR can be cached before it
+	    should be discarded. The following three types of TTL are
+	    currently
+	    used in a zone file.
+	  </para>
+	  <informaltable colsep="0" rowsep="0">
+	    <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+	      <colspec colname="1" colnum="1" colsep="0" colwidth="0.750in"/>
+	      <colspec colname="2" colnum="2" colsep="0" colwidth="4.375in"/>
+	      <tbody>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para>
+		      SOA
+		    </para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The last field in the SOA is the negative
+		      caching TTL. This controls how long other servers will
+		      cache no-such-domain
+		      (NXDOMAIN) responses from you.
+		    </para>
+		    <para>
+		      The maximum time for
+		      negative caching is 3 hours (3h).
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para>
+		      $TTL
+		    </para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      The $TTL directive at the top of the
+		      zone file (before the SOA) gives a default TTL for every
+		      RR without
+		      a specific TTL set.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para>
+		      RR TTLs
+		    </para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Each RR can have a TTL as the second
+		      field in the RR, which will control how long other
+		      servers can cache it.
+		    </para>
+		  </entry>
+		</row>
+	      </tbody>
+	    </tgroup>
+	  </informaltable>
+	  <para>
+	    All of these TTLs default to units of seconds, though units
+	    can be explicitly specified, for example, <literal>1h30m</literal>.
+	  </para>
+	</section>
+	<section xml:id="ipv4_reverse"><info><title>Inverse Mapping in IPv4</title></info>
+
+	  <para>
+	    Reverse name resolution (that is, translation from IP address
+	    to name) is achieved by means of the <emphasis>in-addr.arpa</emphasis> domain
+	    and PTR records. Entries in the in-addr.arpa domain are made in
+	    least-to-most significant order, read left to right. This is the
+	    opposite order to the way IP addresses are usually written. Thus,
+	    a machine with an IP address of 10.1.2.3 would have a
+	    corresponding
+	    in-addr.arpa name of
+	    3.2.1.10.in-addr.arpa. This name should have a PTR resource record
+	    whose data field is the name of the machine or, optionally,
+	    multiple
+	    PTR records if the machine has more than one name. For example,
+	    in the <optional>example.com</optional> domain:
+	  </para>
+	  <informaltable colsep="0" rowsep="0">
+	    <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+	      <colspec colname="1" colnum="1" colsep="0" colwidth="1.125in"/>
+	      <colspec colname="2" colnum="2" colsep="0" colwidth="4.000in"/>
+	      <tbody>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para>
+		      <literal>$ORIGIN</literal>
+		    </para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      <literal>2.1.10.in-addr.arpa</literal>
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para>
+		      <literal>3</literal>
+		    </para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      <literal>IN PTR foo.example.com.</literal>
+		    </para>
+		  </entry>
+		</row>
+	      </tbody>
+	    </tgroup>
+	  </informaltable>
+	  <note>
+	    <para>
+	      The <command>$ORIGIN</command> lines in the examples
+	      are for providing context to the examples only — they do not
+	      necessarily
+	      appear in the actual usage. They are only used here to indicate
+	      that the example is relative to the listed origin.
+	    </para>
+	  </note>
+	</section>
+	<section xml:id="zone_directives"><info><title>Other Zone File Directives</title></info>
+
+	  <para>
+	    The Master File Format was initially defined in RFC 1035 and
+	    has subsequently been extended. While the Master File Format
+	    itself
+	    is class independent all records in a Master File must be of the
+	    same
+	    class.
+	  </para>
+	  <para>
+	    Master File Directives include <command>$ORIGIN</command>, <command>$INCLUDE</command>,
+	    and <command>$TTL.</command>
+	  </para>
+	  <section xml:id="atsign"><info><title>The <command>@</command> (at-sign)</title></info>
+
+	    <para>
+	      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
+	      &lt;<varname>zone_name</varname>&gt; (followed by
+	      trailing dot).
+	    </para>
+	  </section>
+	  <section xml:id="origin_directive"><info><title>The <command>$ORIGIN</command> Directive</title></info>
+
+	    <para>
+	      Syntax: <command>$ORIGIN</command>
+	      <replaceable>domain-name</replaceable>
+	      <optional><replaceable>comment</replaceable></optional>
+	    </para>
+	    <para><command>$ORIGIN</command>
+	      sets the domain name that will be appended to any
+	      unqualified records. When a zone is first read in there
+	      is an implicit <command>$ORIGIN</command>
+	      &lt;<varname>zone_name</varname>&gt;<command>.</command>
+	      (followed by trailing dot).
+	      The current <command>$ORIGIN</command> is appended to
+	      the domain specified in the <command>$ORIGIN</command>
+	      argument if it is not absolute.
+	    </para>
+
+<programlisting>
+$ORIGIN example.com.
+WWW     CNAME   MAIN-SERVER
+</programlisting>
+
+	    <para>
+	      is equivalent to
+	    </para>
+
+<programlisting>
+WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
+</programlisting>
+
+	  </section>
+	  <section xml:id="include_directive"><info><title>The <command>$INCLUDE</command> Directive</title></info>
+
+	    <para>
+	      Syntax: <command>$INCLUDE</command>
+	      <replaceable>filename</replaceable>
+	      <optional>
+<replaceable>origin</replaceable> </optional>
+	      <optional> <replaceable>comment</replaceable> </optional>
+	    </para>
+	    <para>
+	      Read and process the file <filename>filename</filename> as
+	      if it were included into the file at this point.  If <command>origin</command> is
+	      specified the file is processed with <command>$ORIGIN</command> set
+	      to that value, otherwise the current <command>$ORIGIN</command> is
+	      used.
+	    </para>
+	    <para>
+	      The origin and the current domain name
+	      revert to the values they had prior to the <command>$INCLUDE</command> once
+	      the file has been read.
+	    </para>
+	    <note>
+	      <para>
+		RFC 1035 specifies that the current origin should be restored
+		after
+		an <command>$INCLUDE</command>, but it is silent
+		on whether the current
+		domain name should also be restored.  BIND 9 restores both of
+		them.
+		This could be construed as a deviation from RFC 1035, a
+		feature, or both.
+	      </para>
+	    </note>
+	  </section>
+	  <section xml:id="ttl_directive"><info><title>The <command>$TTL</command> Directive</title></info>
+
+	    <para>
+	      Syntax: <command>$TTL</command>
+	      <replaceable>default-ttl</replaceable>
+	      <optional>
+<replaceable>comment</replaceable> </optional>
+	    </para>
+	    <para>
+	      Set the default Time To Live (TTL) for subsequent records
+	      with undefined TTLs. Valid TTLs are of the range 0-2147483647
+	      seconds.
+	    </para>
+	    <para><command>$TTL</command>
+	       is defined in RFC 2308.
+	    </para>
+	  </section>
+	</section>
+	<section xml:id="generate_directive"><info><title><acronym>BIND</acronym> Master File Extension: the  <command>$GENERATE</command> Directive</title></info>
+
+	  <para>
+	    Syntax: <command>$GENERATE</command>
+	    <replaceable>range</replaceable>
+	    <replaceable>lhs</replaceable>
+	    <optional><replaceable>ttl</replaceable></optional>
+	    <optional><replaceable>class</replaceable></optional>
+	    <replaceable>type</replaceable>
+	    <replaceable>rhs</replaceable>
+	    <optional><replaceable>comment</replaceable></optional>
+	  </para>
+	  <para><command>$GENERATE</command>
+	    is used to create a series of resource records that only
+	    differ from each other by an
+	    iterator. <command>$GENERATE</command> can be used to
+	    easily generate the sets of records required to support
+	    sub /24 reverse delegations described in RFC 2317:
+	    Classless IN-ADDR.ARPA delegation.
+	  </para>
+
+<programlisting>$ORIGIN 0.0.192.IN-ADDR.ARPA.
+$GENERATE 1-2 @ NS SERVER$.EXAMPLE.
+$GENERATE 1-127 $ CNAME $.0</programlisting>
+
+	  <para>
+	    is equivalent to
+	  </para>
+
+<programlisting>0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE.
+0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
+1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
+2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
+...
+127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
+</programlisting>
+
+	   <para>
+	    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.
+	   </para>
+
+<programlisting>
+$ORIGIN EXAMPLE.
+$GENERATE 1-127 HOST-$ A 1.2.3.$
+$GENERATE 1-127 HOST-$ MX "0 ."</programlisting>
+
+	  <para>
+	    is equivalent to
+	  </para>
+
+<programlisting>HOST-1.EXAMPLE.   A  1.2.3.1
+HOST-1.EXAMPLE.   MX 0 .
+HOST-2.EXAMPLE.   A  1.2.3.2
+HOST-2.EXAMPLE.   MX 0 .
+HOST-3.EXAMPLE.   A  1.2.3.3
+HOST-3.EXAMPLE.   MX 0 .
+...
+HOST-127.EXAMPLE. A  1.2.3.127
+HOST-127.EXAMPLE. MX 0 .
+</programlisting>
+
+	  <informaltable colsep="0" rowsep="0">
+	    <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
+			<colspec colname="1" colnum="1" colsep="0" colwidth="0.875in"/>
+	      <colspec colname="2" colnum="2" colsep="0" colwidth="4.250in"/>
+	      <tbody>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>range</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      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.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>lhs</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>This
+		      describes the owner name of the resource records
+		      to be created.  Any single <command>$</command>
+		      (dollar sign)
+		      symbols within the <command>lhs</command> string
+		      are replaced by the iterator value.
+
+		      To get a $ in the output, you need to escape the
+		      <command>$</command> using a backslash
+		      <command>\</command>,
+		      e.g. <command>\$</command>. The
+		      <command>$</command> may optionally be followed
+		      by modifiers which change the offset from the
+		      iterator, field width and base.
+
+		      Modifiers are introduced by a
+		      <command>{</command> (left brace) immediately following the
+		      <command>$</command> as
+		      <command>${offset[,width[,base]]}</command>.
+		      For example, <command>${-20,3,d}</command>
+		      subtracts 20 from the current value, prints the
+		      result as a decimal in a zero-padded field of
+		      width 3.
+
+		      Available output forms are decimal
+		      (<command>d</command>), octal
+		      (<command>o</command>), hexadecimal
+		      (<command>x</command> or <command>X</command>
+		      for uppercase) and nibble
+		      (<command>n</command> or <command>N</command>\
+		      for uppercase).  The default modifier is
+		      <command>${0,0,d}</command>.  If the
+		      <command>lhs</command> is not absolute, the
+		      current <command>$ORIGIN</command> is appended
+		      to the name.
+		    </para>
+		    <para>
+		      In nibble mode the value will be treated as
+		      if it was a reversed hexadecimal string
+		      with each hexadecimal digit as a separate
+		      label.  The width field includes the label
+		      separator.
+		    </para>
+		    <para>
+		      For compatibility with earlier versions,
+		      <command>$$</command> is still recognized as
+		      indicating a literal $ in the output.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>ttl</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Specifies the time-to-live of the generated records. If
+		      not specified this will be inherited using the
+		      normal TTL inheritance rules.
+		    </para>
+		    <para><command>class</command>
+		      and <command>ttl</command> can be
+		      entered in either order.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>class</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Specifies the class of the generated records.
+		      This must match the zone class if it is
+		      specified.
+		    </para>
+		    <para><command>class</command>
+		      and <command>ttl</command> can be
+		      entered in either order.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>type</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      Any valid type.
+		    </para>
+		  </entry>
+		</row>
+		<row rowsep="0">
+		  <entry colname="1">
+		    <para><command>rhs</command></para>
+		  </entry>
+		  <entry colname="2">
+		    <para>
+		      <command>rhs</command>, optionally, quoted string.
+		    </para>
+		  </entry>
+		</row>
+	      </tbody>
+	    </tgroup>
+	  </informaltable>
+	  <para>
+	    The <command>$GENERATE</command> directive is a <acronym>BIND</acronym> extension
+	    and not part of the standard zone file format.
+	  </para>
+	  <para>
+	    BIND 8 did not support the optional TTL and CLASS fields.
+	  </para>
+	</section>
+
+	<section xml:id="zonefile_format"><info><title>Additional File Formats</title></info>
+
+	  <para>
+	    In addition to the standard textual format, BIND 9
+	    supports the ability to read or dump to zone files in
+	    other formats.
+	  </para>
+	  <para>
+	    The <constant>raw</constant> format is
+	    a binary representation of zone data in a manner similar
+	    to that used in zone transfers.  Since it does not require
+	    parsing text, load time is significantly reduced.
+	  </para>
+	  <para>
+	    An even faster alternative is the <constant>map</constant>
+	    format, which is an image of a <acronym>BIND</acronym> 9
+	    in-memory zone database; it is capable of being loaded
+	    directly into memory via the <command>mmap()</command>
+	    function; the zone can begin serving queries almost
+	    immediately.
+	  </para>
+	  <para>
+	    For a primary server, a zone file in
+	    <constant>raw</constant> or <constant>map</constant>
+	    format is expected to be generated from a textual zone
+	    file by the <command>named-compilezone</command> command.
+	    For a secondary server or for a dynamic zone, it is automatically
+	    generated (if this format is specified by the
+	    <command>masterfile-format</command> option) when
+	    <command>named</command> dumps the zone contents after
+	    zone transfer or when applying prior updates.
+	  </para>
+	  <para>
+	    If a zone file in a binary format needs manual modification,
+	    it first must be converted to a textual form by the
+	    <command>named-compilezone</command> command.  All
+	    necessary modification should go to the text file, which
+	    should then be converted to the binary form by the
+	    <command>named-compilezone</command> command again.
+	  </para>
+	  <para>
+	    Note that <command>map</command> format is extremely
+	    architecture-specific.  A <constant>map</constant>
+	    file <emphasis>cannot</emphasis> be used on a system
+	    with different pointer size, endianness or data alignment
+	    than the system on which it was generated, and should in
+	    general be used only inside a single system.
+	    While <constant>raw</constant> format uses
+	    network byte order and avoids architecture-dependent
+	    data alignment so that it is as portable as
+	    possible, it is also primarily expected to be used
+	    inside the same single system.  To export a
+	    zone file in either <constant>raw</constant> or
+	    <constant>map</constant> format, or make a
+	    portable backup of such a file, conversion to
+	    <constant>text</constant> format is recommended.
+	  </para>
+	</section>
+      </section>
+
+      <section xml:id="statistics"><info><title>BIND9 Statistics</title></info>
+
+	<para>
+	  <acronym>BIND</acronym> 9 maintains lots of statistics
+	  information and provides several interfaces for users to
+	  get access to the statistics.
+	  The available statistics include all statistics counters
+	  that were available in <acronym>BIND</acronym> 8 and
+	  are meaningful in <acronym>BIND</acronym> 9,
+	  and other information that is considered useful.
+	</para>
+
+	<para>
+	  The statistics information is categorized into the following
+	  sections.
+	</para>
+
+	<informaltable frame="all">
+	  <tgroup cols="2">
+	    <colspec colname="1" colnum="1" colsep="0" colwidth="3.300in"/>
+	    <colspec colname="2" colnum="2" colsep="0" colwidth="2.625in"/>
+	    <tbody>
+
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para>Incoming Requests</para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    The number of incoming DNS requests for each OPCODE.
+		  </para>
+		</entry>
+	      </row>
+
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para>Incoming Queries</para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    The number of incoming queries for each RR type.
+		  </para>
+		</entry>
+	      </row>
+
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para>Outgoing Queries</para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    The number of outgoing queries for each RR
+		    type sent from the internal resolver.
+		    Maintained per view.
+		  </para>
+		</entry>
+	      </row>
+
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para>Name Server Statistics</para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Statistics counters about incoming request processing.
+		  </para>
+		</entry>
+	      </row>
+
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para>Zone Maintenance Statistics</para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Statistics counters regarding zone maintenance
+		    operations such as zone transfers.
+		  </para>
+		</entry>
+	      </row>
+
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para>Resolver Statistics</para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Statistics counters about name resolution
+		    performed in the internal resolver.
+		    Maintained per view.
+		  </para>
+		</entry>
+	      </row>
+
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para>Cache DB RRsets</para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    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.
+		  </para>
+		</entry>
+	      </row>
+
+	      <row rowsep="0">
+		<entry colname="1">
+		  <para>Socket I/O Statistics</para>
+		</entry>
+		<entry colname="2">
+		  <para>
+		    Statistics counters about network related events.
+		  </para>
+		</entry>
+	      </row>
+
+	    </tbody>
+	  </tgroup>
+	</informaltable>
+
+	<para>
+	  A subset of Name Server Statistics is collected and shown
+	  per zone for which the server has the authority when
+	  <command>zone-statistics</command> is set to
+	  <userinput>full</userinput> (or <userinput>yes</userinput>
+	  for backward compatibility. See the description of
+	  <command>zone-statistics</command> in <xref linkend="options"/>
+	  for further details.
+	</para>
+
+	<para>
+	  These statistics counters are shown with their zone and
+	  view names. The view name is omitted when the server is
+	  not configured with explicit views.</para>
+
+	<para>
+	  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 <command>statistics-file</command> configuration option.
+	  The other is remotely accessible via a statistics channel
+	  when the <command>statistics-channels</command> statement
+	  is specified in the configuration file
+	  (see <xref linkend="statschannels"/>.)
+	</para>
+
+	<section xml:id="statsfile"><info><title>The Statistics File</title></info>
+
+	  <para>
+	    The text format statistics dump begins with a line, like:
+	  </para>
+	  <para>
+	    <command>+++ Statistics Dump +++ (973798949)</command>
+	  </para>
+	  <para>
+	    The number in parentheses is a standard
+	    Unix-style timestamp, measured as seconds since January 1, 1970.
+
+	    Following
+	    that line is a set of statistics information, which is categorized
+	    as described above.
+	    Each section begins with a line, like:
+	  </para>
+
+	  <para>
+	    <command>++ Name Server Statistics ++</command>
+	  </para>
+
+	  <para>
+	    Each section consists of lines, each containing the statistics
+	    counter value followed by its textual description.
+	    See below for available counters.
+	    For brevity, counters that have a value of 0 are not shown
+	    in the statistics file.
+	  </para>
+
+	  <para>
+	    The statistics dump ends with the line where the
+	    number is identical to the number in the beginning line; for example:
+	  </para>
+	  <para>
+	    <command>--- Statistics Dump --- (973798949)</command>
+	  </para>
+	</section>
+
+	<section xml:id="statistics_counters"><info><title>Statistics Counters</title></info>
+
+	  <para>
+	    The following tables summarize statistics counters that
+	    <acronym>BIND</acronym> 9 provides.
+	    For each row of the tables, the leftmost column is the
+	    abbreviated symbol name of that counter.
+	    These symbols are shown in the statistics information
+	    accessed via an HTTP statistics channel.
+	    The rightmost column gives the description of the counter,
+	    which is also shown in the statistics file
+	    (but, in this document, possibly with slight modification
+	    for better readability).
+	    Additional notes may also be provided in this column.
+	    When a middle column exists between these two columns,
+	    it gives the corresponding counter name of the
+	    <acronym>BIND</acronym> 8 statistics, if applicable.
+	  </para>
+
+	  <section xml:id="stats_counters"><info><title>Name Server Statistics Counters</title></info>
+
+	    <informaltable colsep="0" rowsep="0">
+	      <tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
+		<colspec colname="3" colnum="3" colsep="0" colwidth="3.350in"/>
+		<tbody>
+		  <row>
+		    <entry colname="1">
+		      <para>
+			<emphasis>Symbol</emphasis>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<emphasis>BIND8 Symbol</emphasis>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<emphasis>Description</emphasis>
+		      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Requestv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 requests received.
+			Note: this also counts non query requests.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Requestv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 requests received.
+			Note: this also counts non query requests.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqEdns0</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with EDNS(0) received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqBadEDNSVer</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with unsupported EDNS version received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqTSIG</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with TSIG received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqSIG0</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with SIG(0) received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqBadSIG</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with invalid (TSIG or SIG(0)) signature.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqTCP</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RTCP</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			TCP requests received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>AuthQryRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RUQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Authoritative (non recursive) queries rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RecQryRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RURQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Recursive queries rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>XfrRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RUXFR</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Zone transfer requests rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RUUpd</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic update requests rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Response</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SAns</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RespTruncated</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Truncated responses sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RespEDNS0</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses with EDNS(0) sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RespTSIG</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses with TSIG sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RespSIG0</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses with SIG(0) sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QrySuccess</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in a successful answer.
+			This means the query which returns a NOERROR response
+			with at least one answer RR.
+			This corresponds to the
+			<command>success</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryAuthAns</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in authoritative answer.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryNoauthAns</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SNaAns</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in non authoritative answer.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryReferral</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in referral answer.
+			This corresponds to the
+			<command>referral</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryNxrrset</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in NOERROR responses with no data.
+			This corresponds to the
+			<command>nxrrset</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QrySERVFAIL</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SFail</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in SERVFAIL.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryFORMERR</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SFErr</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in FORMERR.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryNXDOMAIN</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SNXD</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in NXDOMAIN.
+			This corresponds to the
+			<command>nxdomain</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryRecursion</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RFwdQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries which caused the server
+			to perform recursion in order to find the final answer.
+			This corresponds to the
+			<command>recursion</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryDuplicate</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RDupQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries which the server attempted to
+			recurse but discovered an existing query with the same
+			IP address, port, query ID, name, type and class
+			already being processed.
+			This corresponds to the
+			<command>duplicate</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryDropped</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			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.
+			This is the number of dropped queries due to
+			the reason explained with the
+			<command>clients-per-query</command>
+			and
+			<command>max-clients-per-query</command>
+			options
+			(see the description about
+			<xref endterm="cpq_term" linkend="clients-per-query"/>.)
+			This corresponds to the
+			<command>dropped</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryFailure</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Other query failures.
+			This corresponds to the
+			<command>failure</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+			Note: this counter is provided mainly for
+			backward compatibility with the previous versions.
+			Normally a more fine-grained counters such as
+			<command>AuthQryRej</command> and
+			<command>RecQryRej</command>
+			that would also fall into this counter are provided,
+			and so this counter would not be of much
+			interest in practice.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryNXRedir</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in NXDOMAIN that were redirected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryNXRedirRLookup</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in NXDOMAIN that were redirected
+			and resulted in a successful remote lookup.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>XfrReqDone</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requested zone transfers completed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateReqFwd</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Update requests forwarded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateRespFwd</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Update responses forwarded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateFwdFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic update forward failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateDone</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic updates completed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic updates failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateBadPrereq</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic updates rejected due to prerequisite failure.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RateDropped</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses dropped by rate limits.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RateSlipped</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses truncated by rate limits.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RPZRewrites</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Response policy zone rewrites.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	  </section>
+
+	  <section xml:id="zone_stats"><info><title>Zone Maintenance Statistics Counters</title></info>
+
+	    <informaltable colsep="0" rowsep="0">
+	      <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
+		<tbody>
+		  <row>
+		    <entry colname="1">
+		      <para>
+			<emphasis>Symbol</emphasis>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<emphasis>Description</emphasis>
+		      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyOutv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 notifies sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyOutv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 notifies sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyInv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 notifies received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyInv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 notifies received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Incoming notifies rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>SOAOutv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 SOA queries sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>SOAOutv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 SOA queries sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>AXFRReqv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 AXFR requested.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>AXFRReqv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 AXFR requested.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>IXFRReqv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 IXFR requested.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>IXFRReqv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 IXFR requested.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>XfrSuccess</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Zone transfer requests succeeded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>XfrFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Zone transfer requests failed.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	  </section>
+
+	  <section xml:id="resolver_stats"><info><title>Resolver Statistics Counters</title></info>
+
+	    <informaltable colsep="0" rowsep="0">
+	      <tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
+		<colspec colname="3" colnum="3" colsep="0" colwidth="3.350in"/>
+		<tbody>
+		  <row>
+		    <entry colname="1">
+		      <para>
+			<emphasis>Symbol</emphasis>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<emphasis>BIND8 Symbol</emphasis>
+		      </para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			<emphasis>Description</emphasis>
+		      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Queryv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SFwdQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 queries sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Queryv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SFwdQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 queries sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Responsev4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RR</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 responses received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Responsev6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RR</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 responses received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NXDOMAIN</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RNXD</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			NXDOMAIN received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>SERVFAIL</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RFail</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			SERVFAIL received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>FORMERR</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RFErr</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			FORMERR received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>OtherError</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RErr</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Other errors received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>EDNS0Fail</command></para>
+						 </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			EDNS(0) query failures.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Mismatch</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RDupR</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Mismatch responses received.
+			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
+			the <command>port</command> option.)
+			This may be an indication of a cache
+			poisoning attempt.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Truncated</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Truncated responses received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Lame</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RLame</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Lame delegations received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Retry</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SDupQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Query retries performed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QueryAbort</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries aborted due to quota control.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QuerySockFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			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.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QueryTimeout</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Query timeouts.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>GlueFetchv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SSysQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 NS address fetches invoked.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>GlueFetchv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SSysQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 NS address fetches invoked.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>GlueFetchv4Fail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 NS address fetch failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>GlueFetchv6Fail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 NS address fetch failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ValAttempt</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			DNSSEC validation attempted.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ValOk</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			DNSSEC validation succeeded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ValNegOk</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			DNSSEC validation on negative information succeeded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ValFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			DNSSEC validation failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryRTTnn</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command/></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Frequency table on round trip times (RTTs) of
+			queries.
+			Each <command>nn</command> specifies the corresponding
+			frequency.
+			In the sequence of
+			<command>nn_1</command>,
+			<command>nn_2</command>,
+			...,
+			<command>nn_m</command>,
+			the value of <command>nn_i</command> is the
+			number of queries whose RTTs are between
+			<command>nn_(i-1)</command> (inclusive) and
+			<command>nn_i</command> (exclusive) milliseconds.
+			For the sake of convenience we define
+			<command>nn_0</command> to be 0.
+			The last entry should be represented as
+			<command>nn_m+</command>, which means the
+			number of queries whose RTTs are equal to or over
+			<command>nn_m</command> milliseconds.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+
+	  </section>
+
+	  <section xml:id="socket_stats"><info><title>Socket I/O Statistics Counters</title></info>
+
+	    <para>
+	      Socket I/O statistics counters are defined per socket
+	      types, which are
+	      <command>UDP4</command> (UDP/IPv4),
+	      <command>UDP6</command> (UDP/IPv6),
+	      <command>TCP4</command> (TCP/IPv4),
+	      <command>TCP6</command> (TCP/IPv6),
+	      <command>Unix</command> (Unix Domain), and
+	      <command>FDwatch</command> (sockets opened outside the
+	      socket module).
+	      In the following table <command>&lt;TYPE&gt;</command>
+	      represents a socket type.
+	      Not all counters are available for all socket types;
+	      exceptions are noted in the description field.
+	    </para>
+
+	    <informaltable colsep="0" rowsep="0">
+	      <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
+		<tbody>
+		  <row>
+		    <entry colname="1">
+		      <para>
+			<emphasis>Symbol</emphasis>
+		      </para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			<emphasis>Description</emphasis>
+		      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;Open</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Sockets opened successfully.
+			This counter is not applicable to the
+			<command>FDwatch</command> type.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;OpenFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Failures of opening sockets.
+			This counter is not applicable to the
+			<command>FDwatch</command> type.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;Close</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Sockets closed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;BindFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Failures of binding sockets.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;ConnFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Failures of connecting sockets.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;Conn</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Connections established successfully.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;AcceptFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Failures of accepting incoming connection requests.
+			This counter is not applicable to the
+			<command>UDP</command> and
+			<command>FDwatch</command> types.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;Accept</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Incoming connections successfully accepted.
+			This counter is not applicable to the
+			<command>UDP</command> and
+			<command>FDwatch</command> types.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;SendErr</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Errors in socket send operations.
+			This counter corresponds
+			to <command>SErr</command> counter of
+			<command>BIND</command> 8.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;RecvErr</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Errors in socket receive operations.
+			This includes errors of send operations on a
+			connected UDP socket notified by an ICMP error
+			message.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+	      </tgroup>
+	    </informaltable>
+	  </section>
+
+	  <section xml:id="bind8_compatibility"><info><title>Compatibility with <emphasis>BIND</emphasis> 8 Counters</title></info>
+
+	    <para>
+	      Most statistics counters that were available
+	      in <command>BIND</command> 8 are also supported in
+	      <command>BIND</command> 9 as shown in the above tables.
+	      Here are notes about other counters that do not appear
+	      in these tables.
+	    </para>
+
+	    <variablelist>
+	      <varlistentry>
+		<term><command>RFwdR,SFwdR</command></term>
+		<listitem>
+		  <para>
+		    These counters are not supported
+		    because <command>BIND</command> 9 does not adopt
+		    the notion of <emphasis>forwarding</emphasis>
+		    as <command>BIND</command> 8 did.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>RAXFR</command></term>
+		<listitem>
+		  <para>
+		    This counter is accessible in the Incoming Queries section.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>RIQ</command></term>
+		<listitem>
+		  <para>
+		    This counter is accessible in the Incoming Requests section.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+	      <varlistentry>
+		<term><command>ROpts</command></term>
+		<listitem>
+		  <para>
+		    This counter is not supported
+		    because <command>BIND</command> 9 does not care
+		    about IP options in the first place.
+		  </para>
+		</listitem>
+	      </varlistentry>
+	    </variablelist>
+	  </section>
+	</section>
+      </section>
+
+    </chapter>
+    <chapter xml:id="Bv9ARM.ch07"><info><title><acronym>BIND</acronym> 9 Security Considerations</title></info>
+
+      <section xml:id="Access_Control_Lists"><info><title>Access Control Lists</title></info>
+
+	<para>
+	  Access Control Lists (ACLs) are address match lists that
+	  you can set up and nickname for future use in
+	  <command>allow-notify</command>, <command>allow-query</command>,
+	  <command>allow-query-on</command>, <command>allow-recursion</command>,
+	  <command>blackhole</command>, <command>allow-transfer</command>,
+	  <command>match-clients</command>, etc.
+	</para>
+	<para>
+	  Using ACLs allows you to have finer control over who can access
+	  your name server, without cluttering up your config files with huge
+	  lists of IP addresses.
+	</para>
+	<para>
+	  It is a <emphasis>good idea</emphasis> to use ACLs, and to
+	  control access to your server. Limiting access to your server by
+	  outside parties can help prevent spoofing and denial of service
+	  (DoS) attacks against your server.
+	</para>
+	<para>
+	  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.
+	</para>
+	<para>
+	  Here is an example of ACLs based on client addresses:
+	</para>
+
+<programlisting>
+// Set up an ACL named "bogusnets" that will block
+// RFC1918 space and some reserved space, which is
+// commonly used in spoofing attacks.
+acl bogusnets {
+	0.0.0.0/8;  192.0.2.0/24; 224.0.0.0/3;
+	10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
+};
+
+// Set up an ACL called our-nets. Replace this with the
+// real IP numbers.
+acl our-nets { x.x.x.x/24; x.x.x.x/21; };
+options {
+  ...
+  ...
+  allow-query { our-nets; };
+  allow-recursion { our-nets; };
+  ...
+  blackhole { bogusnets; };
+  ...
+};
+
+zone "example.com" {
+  type master;
+  file "m/example.com";
+  allow-query { any; };
+};
+</programlisting>
+
+	<para>
+	  This allows authoritative queries for "example.com" from any
+	  address, but recursive queries only from the networks specified
+	  in "our-nets", and no queries at all from the networks
+	  specified in "bogusnets".
+	</para>
+	<para>
+	  In addition to network addresses and prefixes, which are
+	  matched against the source address of the DNS request, ACLs
+	  may include <option>key</option> elements, which specify the
+	  name of a TSIG or SIG(0) key, or <option>ecs</option>
+	  elements, which specify a network prefix but are only matched
+	  if that prefix matches an EDNS client subnet option included
+	  in the request.
+	</para>
+	<para>
+	  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
+	  resolver for different resolver clients.  An ACL containing
+	  an element of the form
+	  <command>ecs <replaceable>prefix</replaceable></command>
+	  will match if a request arrives in containing an ECS option
+	  encoding an address within that prefix.  If the request has no
+	  ECS option, then "ecs" elements are simply ignored.  Addresses
+	  in ACLs that are not prefixed with "ecs" are matched only
+	  against the source address.
+	</para>
+	<note>
+	  <simpara>
+	    (Note: The authoritative ECS implementation in
+	    <command>named</command> is based on an early version of the
+	    specification, and is known to have incompatibilities with
+	    other implementations.  It is also inefficient, requiring
+	    a separate view for each client subnet to be sent different
+	    answers, and it is unable to correct for overlapping subnets in
+	    the configuration.  It can be used for testing purposes, but is
+	    not recommended for production use.)
+	  </simpara>
+	</note>
+	<para>
+	  When <acronym>BIND</acronym> 9 is built with GeoIP support,
+	  ACLs can also be used for geographic access restrictions.
+	  This is done by specifying an ACL element of the form:
+	  <command>geoip <optional>db <replaceable>database</replaceable></optional> <replaceable>field</replaceable> <replaceable>value</replaceable></command>
+	</para>
+	<para>
+	  The <replaceable>field</replaceable> indicates which field
+	  to search for a match.  Available fields are "country",
+	  "region", "city", "continent", "postal" (postal code),
+	  "metro" (metro code), "area" (area code), "tz" (timezone),
+	  "isp", "org", "asnum", "domain" and "netspeed".
+	</para>
+	<para>
+	  <replaceable>value</replaceable> is the value to search
+	  for within the database.  A string may be quoted if it
+	  contains spaces or other special characters.  If this is
+	  an "asnum" search, then the leading "ASNNNN" string can be
+	  used, otherwise the full description must be used (e.g.
+	  "ASNNNN Example Company Name").  If this is a "country"
+	  search and the string is two characters long, then it must
+	  be a standard ISO-3166-1 two-letter country code, and if it
+	  is three characters long then it must be an ISO-3166-1
+	  three-letter country code; otherwise it is the full name
+	  of the country.  Similarly, if this is a "region" search
+	  and the string is two characters long, then it must be a
+	  standard two-letter state or province abbreviation;
+	  otherwise it is the full name of the state or province.
+	</para>
+	<para>
+	  The <replaceable>database</replaceable> field indicates which
+	  GeoIP database to search for a match.  In most cases this is
+	  unnecessary, because most search fields can only be found in
+	  a single database.  However, searches for country can be
+	  answered from the "city", "region", or "country" databases,
+	  and searches for region (i.e., state or province) can be
+	  answered from the "city" or "region" databases.  For these
+	  search types, specifying a <replaceable>database</replaceable>
+	  will force the query to be answered from that database and no
+	  other.  If <replaceable>database</replaceable> is not
+	  specified, then these queries will be answered from the "city",
+	  database if it is installed, or the "region" database if it is
+	  installed, or the "country" database, in that order.
+	</para>
+	<para>
+	  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
+	  prevent GeoIP ACLs from matching against ECS options, set
+	  the <command>geoip-use-ecs</command> to <literal>no</literal>.
+	</para>
+	<para>
+	  Some example GeoIP ACLs:
+	</para>
+	<programlisting>geoip country US;
+geoip country JAP;
+geoip db country country Canada;
+geoip db region region WA;
+geoip city "San Francisco";
+geoip region Oklahoma;
+geoip postal 95062;
+geoip tz "America/Los_Angeles";
+geoip org "Internet Systems Consortium";
+</programlisting>
+
+	<para>
+	  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
+	  <command> { 10/8; !10.0.0.1; }</command> would actually
+	  match a query from 10.0.0.1, because the first element
+	  indicated that the query should be accepted, and the second
+	  element is ignored.
+	</para>
+	<para>
+	  When using "nested" ACLs (that is, ACLs included or referenced
+	  within other ACLs), a negative match of a nested ACL will
+	  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
+	  it originates from a particular network <emphasis>and</emphasis>
+	  only when it is signed with a particular key, use:
+	</para>
+	<programlisting>
+allow-query { !{ !10/8; any; }; key example; };
+</programlisting>
+	<para>
+	  Within the nested ACL, any address that is
+	  <emphasis>not</emphasis> in the 10/8 network prefix will
+	  be rejected, and this will terminate processing of the
+	  ACL.  Any address that <emphasis>is</emphasis> in the 10/8
+	  network prefix will be 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
+	  by the key "example", and rejected otherwise.  The ACL, then,
+	  will only matches when <emphasis>both</emphasis> conditions
+	  are true.
+	</para>
+      </section>
+
+      <section xml:id="chroot_and_setuid"><info><title><command>Chroot</command> and <command>Setuid</command></title></info>
+
+	<para>
+	  On UNIX servers, it is possible to run <acronym>BIND</acronym>
+	  in a <emphasis>chrooted</emphasis> environment (using
+	  the <command>chroot()</command> function) by specifying
+	  the <option>-t</option> option for <command>named</command>.
+	  This can help improve system security by placing
+	  <acronym>BIND</acronym> in a "sandbox", which will limit
+	  the damage done if a server is compromised.
+	</para>
+	<para>
+	  Another useful feature in the UNIX version of <acronym>BIND</acronym> is the
+	  ability to run the daemon as an unprivileged user ( <option>-u</option> <replaceable>user</replaceable> ).
+	  We suggest running as an unprivileged user when using the <command>chroot</command> feature.
+	</para>
+	<para>
+	  Here is an example command line to load <acronym>BIND</acronym> in a <command>chroot</command> sandbox,
+	  <command>/var/named</command>, and to run <command>named</command> <command>setuid</command> to
+	  user 202:
+	</para>
+	<para>
+	  <userinput>/usr/local/sbin/named -u 202 -t /var/named</userinput>
+	</para>
+
+	<section xml:id="chroot"><info><title>The <command>chroot</command> Environment</title></info>
+
+	  <para>
+	    In order for a <command>chroot</command> environment
+	    to work properly in a particular directory (for example,
+	    <filename>/var/named</filename>), you will need to set
+	    up an environment that includes everything
+	    <acronym>BIND</acronym> needs to run.  From
+	    <acronym>BIND</acronym>'s point of view,
+	    <filename>/var/named</filename> is the root of the
+	    filesystem.  You will need to adjust the values of
+	    options like <command>directory</command> and
+	    <command>pid-file</command> to account for this.
+	  </para>
+	  <para>
+	    Unlike with earlier versions of BIND, you typically will
+	    <emphasis>not</emphasis> need to compile <command>named</command>
+	    statically nor install shared libraries under the new root.
+	    However, depending on your operating system, you may need
+	    to set up things like
+	    <filename>/dev/zero</filename>,
+	    <filename>/dev/random</filename>,
+	    <filename>/dev/log</filename>, and
+	    <filename>/etc/localtime</filename>.
+	  </para>
+	</section>
+
+	<section xml:id="setuid"><info><title>Using the <command>setuid</command> Function</title></info>
+
+	  <para>
+	    Prior to running the <command>named</command> daemon,
+	    use
+	    the <command>touch</command> utility (to change file
+	    access and
+	    modification times) or the <command>chown</command>
+	    utility (to
+	    set the user id and/or group id) on files
+	    to which you want <acronym>BIND</acronym>
+	    to write.
+	  </para>
+	  <note><simpara>
+	    If the <command>named</command> daemon is running as an
+	    unprivileged user, it will not be able to bind to new restricted
+	    ports if the server is reloaded.
+	  </simpara></note>
+	</section>
+      </section>
+
+      <section xml:id="dynamic_update_security"><info><title>Dynamic Update Security</title></info>
+
+	<para>
+	  Access to the dynamic
+	  update facility should be strictly limited.  In earlier versions of
+	  <acronym>BIND</acronym>, the only way to do this was
+	  based on the IP
+	  address of the host requesting the update, by listing an IP address
+	  or
+	  network prefix in the <command>allow-update</command>
+	  zone option.
+	  This method is insecure since the source address of the update UDP
+	  packet
+	  is easily forged.  Also note that if the IP addresses allowed by the
+	  <command>allow-update</command> option include the
+	  address of a slave
+	  server which performs forwarding of dynamic updates, the master can
+	  be
+	  trivially attacked by sending the update to the slave, which will
+	  forward it to the master with its own source IP address causing the
+	  master to approve it without question.
+	</para>
+
+	<para>
+	  For these reasons, we strongly recommend that updates be
+	  cryptographically authenticated by means of transaction signatures
+	  (TSIG).  That is, the <command>allow-update</command>
+	  option should
+	  list only TSIG key names, not IP addresses or network
+	  prefixes. Alternatively, the new <command>update-policy</command>
+	  option can be used.
+	</para>
+
+	<para>
+	  Some sites choose to keep all dynamically-updated DNS data
+	  in a subdomain and delegate that subdomain to a separate zone. This
+	  way, the top-level zone containing critical data such as the IP
+	  addresses
+	  of public web and mail servers need not allow dynamic update at
+	  all.
+	</para>
+
+      </section>
+    </chapter>
+
+    <chapter xml:id="Bv9ARM.ch08"><info><title>Troubleshooting</title></info>
+
+      <section xml:id="common_problems"><info><title>Common Problems</title></info>
+
+	<section><info><title>It's not working; how can I figure out what's wrong?</title></info>
+
+	  <para>
+	    The best solution to solving installation and
+	    configuration issues is to take preventative measures by setting
+	    up logging files beforehand. The log files provide a
+	    source of hints and information that can be used to figure out
+	    what went wrong and how to fix the problem.
+	  </para>
+
+	</section>
+      </section>
+      <section><info><title>Incrementing and Changing the Serial Number</title></info>
+
+	<para>
+	  Zone serial numbers are just numbers — they aren't
+	  date related.  A lot of 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
+	  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.
+	</para>
+
+	<para>
+	  Setting the serial number to a lower number on the master
+	  server than the slave server means that the slave will not perform
+	  updates to its copy of the zone.
+	</para>
+
+	<para>
+	  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.
+	</para>
+
+      </section>
+      <section xml:id="more_help"><info><title>Where Can I Get Help?</title></info>
+
+	<para>
+	  The Internet Systems Consortium
+	  (<acronym>ISC</acronym>) offers a wide range
+	  of support and service agreements for <acronym>BIND</acronym> and <acronym>DHCP</acronym> servers. Four
+	  levels of premium support are available and each level includes
+	  support for all <acronym>ISC</acronym> programs,
+	  significant discounts on products
+	  and training, and a recognized priority on bug fixes and
+	  non-funded feature requests. In addition, <acronym>ISC</acronym> offers a standard
+	  support agreement package which includes services ranging from bug
+	  fix announcements to remote support. It also includes training in
+	  <acronym>BIND</acronym> and <acronym>DHCP</acronym>.
+	</para>
+
+	<para>
+	  To discuss arrangements for support, contact
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="mailto:info@isc.org">info@isc.org</link> or visit the
+	  <acronym>ISC</acronym> web page at
+	  <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.isc.org/services/support/">http://www.isc.org/services/support/</link>
+	  to read more.
+	</para>
+      </section>
+    </chapter>
+
+    <appendix xml:id="Bv9ARM.ch09"><info><title>Release Notes</title></info>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="notes.xml"/>
+    </appendix>
+
+    <appendix xml:id="Bv9ARM.ch10"><info><title>A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym></title></info>
+      <para xml:id="historical_dns_information">
+	Although the "official" beginning of the Domain Name
+	System occurred in 1984 with the publication of RFC 920, the
+	core of the new system was described in 1983 in RFCs 882 and
+	883. From 1984 to 1987, the ARPAnet (the precursor to today's
+	Internet) became a testbed of experimentation for developing the
+	new naming/addressing scheme in a rapidly expanding,
+	operational network environment.  New RFCs were written and
+	published in 1987 that modified the original documents to
+	incorporate improvements based on the working model. RFC 1034,
+	"Domain Names-Concepts and Facilities", and RFC 1035, "Domain
+	Names-Implementation and Specification" were published and
+	became the standards upon which all <acronym>DNS</acronym> implementations are
+	built.
+      </para>
+
+      <para>
+	The first working domain name server, called "Jeeves", was
+	written in 1983-84 by Paul Mockapetris for operation on DEC
+	Tops-20
+	machines located at the University of Southern California's
+	Information
+	Sciences Institute (USC-ISI) and SRI International's Network
+	Information
+	Center (SRI-NIC). A <acronym>DNS</acronym> server for
+	Unix machines, the Berkeley Internet
+	Name Domain (<acronym>BIND</acronym>) package, was
+	written soon after by a group of
+	graduate students at the University of California at Berkeley
+	under
+	a grant from the US Defense Advanced Research Projects
+	Administration
+	(DARPA).
+      </para>
+      <para>
+	Versions of <acronym>BIND</acronym> 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 <acronym>BIND</acronym>
+	project team. After that, additional work on the software package
+	was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment
+	Corporation
+	employee on loan to the CSRG, worked on <acronym>BIND</acronym> for 2 years, from 1985
+	to 1987. Many other people also contributed to <acronym>BIND</acronym> development
+	during that time: Doug Kingston, Craig Partridge, Smoot
+	Carl-Mitchell,
+	Mike Muuss, Jim Bloom and Mike Schwartz. <acronym>BIND</acronym> maintenance was subsequently
+	handled by Mike Karels and Øivind Kure.
+      </para>
+      <para>
+	<acronym>BIND</acronym> versions 4.9 and 4.9.1 were
+	released by Digital Equipment
+	Corporation (now Compaq Computer Corporation). Paul Vixie, then
+	a DEC employee, became <acronym>BIND</acronym>'s
+	primary caretaker. He was assisted
+	by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan
+	Beecher, Andrew
+	Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat
+	Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe
+	Wolfhugel, and others.
+      </para>
+      <para>
+	In 1994, <acronym>BIND</acronym> version 4.9.2 was sponsored by
+	Vixie Enterprises. Paul
+	Vixie became <acronym>BIND</acronym>'s principal
+	architect/programmer.
+      </para>
+      <para>
+	<acronym>BIND</acronym> versions from 4.9.3 onward
+	have been developed and maintained
+	by the Internet Systems Consortium and its predecessor,
+	the Internet Software Consortium,  with support being provided
+	by ISC's sponsors.
+      </para>
+      <para>
+	As co-architects/programmers, Bob Halley and
+	Paul Vixie released the first production-ready version of
+	<acronym>BIND</acronym> version 8 in May 1997.
+      </para>
+      <para>
+	BIND version 9 was released in September 2000 and is a
+	major rewrite of nearly all aspects of the underlying
+	BIND architecture.
+      </para>
+      <para>
+	BIND versions 4 and 8 are officially deprecated.
+	No additional development is done
+	on BIND version 4 or BIND version 8.
+      </para>
+      <para>
+	<acronym>BIND</acronym> development work is made
+	possible today by the sponsorship
+	of several corporations, and by the tireless work efforts of
+	numerous individuals.
+      </para>
+    </appendix>
+
+    <appendix xml:id="Bv9ARM.ch11"><info><title>General <acronym>DNS</acronym> Reference Information</title></info>
+
+      <section xml:id="ipv6addresses"><info><title>IPv6 addresses (AAAA)</title></info>
+
+	  <para>
+	    IPv6 addresses are 128-bit identifiers for interfaces and
+	    sets of interfaces which were introduced in the <acronym>DNS</acronym> to facilitate
+	    scalable Internet routing. There are three types of addresses: <emphasis>Unicast</emphasis>,
+	    an identifier for a single interface;
+	    <emphasis>Anycast</emphasis>,
+	    an identifier for a set of interfaces; and <emphasis>Multicast</emphasis>,
+	    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."
+	  </para>
+	  <para>
+	    IPv6 unicast addresses consist of a
+	    <emphasis>global routing prefix</emphasis>, a
+	    <emphasis>subnet identifier</emphasis>, and an
+	    <emphasis>interface identifier</emphasis>.
+	  </para>
+	  <para>
+	    The global routing prefix is provided by the
+	    upstream provider or ISP, and (roughly) corresponds to the
+	    IPv4 <emphasis>network</emphasis> section
+	    of the address range.
+
+	    The subnet identifier is for local subnetting, much the
+	    same as subnetting an
+	    IPv4 /16 network into /24 subnets.
+
+	    The interface identifier is the address of an individual
+	    interface on a given network; in IPv6, addresses belong to
+	    interfaces rather than to machines.
+	  </para>
+	  <para>
+	    The subnetting capability of IPv6 is much more flexible than
+	    that of IPv4: subnetting can be carried out on bit boundaries,
+	    in much the same way as Classless InterDomain Routing
+	    (CIDR), and the DNS PTR representation ("nibble" format)
+	    makes setting up reverse zones easier.
+	  </para>
+	  <para>
+	    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:
+	    <command>2001:db8:201:9:a00:20ff:fe81:2b32</command>
+	  </para>
+	  <para>
+	    IPv6 address specifications often contain long strings
+	    of zeros, so the architects have included a shorthand for
+	    specifying
+	    them. The double colon (`::') indicates the longest possible
+	    string
+	    of zeros that can fit, and can be used only once in an address.
+	  </para>
+      </section>
+      <section xml:id="bibliography"><info><title>Bibliography (and Suggested Reading)</title></info>
+
+	<section xml:id="rfcs"><info><title>Request for Comments (RFCs)</title></info>
+
+	  <para>
+	    Specification documents for the Internet protocol suite, including
+	    the <acronym>DNS</acronym>, are published as part of
+	    the Request for Comments (RFCs)
+	    series of technical notes. The standards themselves are defined
+	    by the Internet Engineering Task Force (IETF) and the Internet
+	    Engineering Steering Group (IESG). RFCs can be obtained online via FTP at:
+	  </para>
+	  <para>
+	    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="ftp://www.isi.edu/in-notes/">
+	      ftp://www.isi.edu/in-notes/RFC<replaceable>xxxx</replaceable>.txt
+	    </link>
+	  </para>
+	  <para>
+	    (where <replaceable>xxxx</replaceable> is
+	    the number of the RFC). RFCs are also available via the Web at:
+	  </para>
+	  <para>
+	    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ietf.org/rfc/">http://www.ietf.org/rfc/</link>.
+	  </para>
+	  <bibliography>
+	    <bibliodiv><info><title>Standards</title></info>
+	      <!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
+
+	      <biblioentry>
+		<abbrev>RFC974</abbrev>
+		<author><personname><surname>Partridge</surname><firstname>C.</firstname></personname></author>
+		<citetitle>Mail Routing and the Domain System</citetitle>
+		<pubdate>January 1986</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1034</abbrev>
+		<author><personname><surname>Mockapetris</surname><firstname>P.V.</firstname></personname></author>
+		<citetitle>Domain Names — Concepts and Facilities</citetitle>
+		<pubdate>November 1987</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1035</abbrev>
+		<author><personname><surname>Mockapetris</surname><firstname>P. V.</firstname></personname></author> <citetitle>Domain Names — Implementation and
+		  Specification</citetitle>
+		<pubdate>November 1987</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv xml:id="proposed_standards" xreflabel="Proposed Standards"><info><title>Proposed Standards</title></info>
+
+	      <!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
+	      <biblioentry>
+		<abbrev>RFC2181</abbrev>
+		<author><personname><surname>Elz</surname><firstname>R., R. Bush</firstname></personname></author>
+		<citetitle>Clarifications to the <acronym>DNS</acronym>
+		  Specification</citetitle>
+		<pubdate>July 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2308</abbrev>
+		<author><personname><surname>Andrews</surname><firstname>M.</firstname></personname></author>
+		<citetitle>Negative Caching of <acronym>DNS</acronym>
+		  Queries</citetitle>
+		<pubdate>March 1998</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1995</abbrev>
+		<author><personname><surname>Ohta</surname><firstname>M.</firstname></personname></author>
+		<citetitle>Incremental Zone Transfer in <acronym>DNS</acronym></citetitle>
+		<pubdate>August 1996</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1996</abbrev>
+		<author><personname><surname>Vixie</surname><firstname>P.</firstname></personname></author>
+		<citetitle>A Mechanism for Prompt Notification of Zone Changes</citetitle>
+		<pubdate>August 1996</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2136</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Vixie</surname><firstname>P.</firstname></personname></author>
+		  <author><personname><firstname>S.</firstname><surname>Thomson</surname></personname></author>
+		  <author><personname><firstname>Y.</firstname><surname>Rekhter</surname></personname></author>
+		  <author><personname><firstname>J.</firstname><surname>Bound</surname></personname></author>
+		</authorgroup>
+		<citetitle>Dynamic Updates in the Domain Name System</citetitle>
+		<pubdate>April 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2671</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
+		</authorgroup>
+		<citetitle>Extension Mechanisms for DNS (EDNS0)</citetitle>
+		<pubdate>August 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2672</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>M.</firstname><surname>Crawford</surname></personname></author>
+		</authorgroup>
+		<citetitle>Non-Terminal DNS Name Redirection</citetitle>
+		<pubdate>August 1999</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2845</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Vixie</surname><firstname>P.</firstname></personname></author>
+		  <author><personname><firstname>O.</firstname><surname>Gudmundsson</surname></personname></author>
+		  <author><personname><firstname>D.</firstname><surname>Eastlake</surname><lineage>3rd</lineage></personname></author>
+		  <author><personname><firstname>B.</firstname><surname>Wellington</surname></personname></author>
+		</authorgroup>
+		<citetitle>Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG)</citetitle>
+		<pubdate>May 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2930</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>D.</firstname><surname>Eastlake</surname><lineage>3rd</lineage></personname></author>
+		</authorgroup>
+		<citetitle>Secret Key Establishment for DNS (TKEY RR)</citetitle>
+		<pubdate>September 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2931</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>D.</firstname><surname>Eastlake</surname><lineage>3rd</lineage></personname></author>
+		</authorgroup>
+		<citetitle>DNS Request and Transaction Signatures (SIG(0)s)</citetitle>
+		<pubdate>September 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3007</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>B.</firstname><surname>Wellington</surname></personname></author>
+		</authorgroup>
+		<citetitle>Secure Domain Name System (DNS) Dynamic Update</citetitle>
+		<pubdate>November 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3645</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>S.</firstname><surname>Kwan</surname></personname></author>
+		  <author><personname><firstname>P.</firstname><surname>Garg</surname></personname></author>
+		  <author><personname><firstname>J.</firstname><surname>Gilroy</surname></personname></author>
+		  <author><personname><firstname>L.</firstname><surname>Esibov</surname></personname></author>
+		  <author><personname><firstname>J.</firstname><surname>Westhead</surname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Hall</surname></personname></author>
+		</authorgroup>
+		<citetitle>Generic Security Service Algorithm for Secret
+		       Key Transaction Authentication for DNS
+		       (GSS-TSIG)</citetitle>
+		<pubdate>October 2003</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title><acronym>DNS</acronym> Security Proposed Standards</title></info>
+
+	      <biblioentry>
+		<abbrev>RFC3225</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>D.</firstname><surname>Conrad</surname></personname></author>
+		</authorgroup>
+		<citetitle>Indicating Resolver Support of DNSSEC</citetitle>
+		<pubdate>December 2001</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3833</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>D.</firstname><surname>Atkins</surname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Austein</surname></personname></author>
+		</authorgroup>
+		<citetitle>Threat Analysis of the Domain Name System (DNS)</citetitle>
+		<pubdate>August 2004</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC4033</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>R.</firstname><surname>Arends</surname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Austein</surname></personname></author>
+		  <author><personname><firstname>M.</firstname><surname>Larson</surname></personname></author>
+		  <author><personname><firstname>D.</firstname><surname>Massey</surname></personname></author>
+		  <author><personname><firstname>S.</firstname><surname>Rose</surname></personname></author>
+		</authorgroup>
+		<citetitle>DNS Security Introduction and Requirements</citetitle>
+		<pubdate>March 2005</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC4034</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>R.</firstname><surname>Arends</surname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Austein</surname></personname></author>
+		  <author><personname><firstname>M.</firstname><surname>Larson</surname></personname></author>
+		  <author><personname><firstname>D.</firstname><surname>Massey</surname></personname></author>
+		  <author><personname><firstname>S.</firstname><surname>Rose</surname></personname></author>
+		</authorgroup>
+		<citetitle>Resource Records for the DNS Security Extensions</citetitle>
+		<pubdate>March 2005</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC4035</abbrev>
+		<authorgroup>
+		  <author><personname><firstname>R.</firstname><surname>Arends</surname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Austein</surname></personname></author>
+		  <author><personname><firstname>M.</firstname><surname>Larson</surname></personname></author>
+		  <author><personname><firstname>D.</firstname><surname>Massey</surname></personname></author>
+		  <author><personname><firstname>S.</firstname><surname>Rose</surname></personname></author>
+		</authorgroup>
+		<citetitle>Protocol Modifications for the DNS
+		       Security Extensions</citetitle>
+		<pubdate>March 2005</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title>Other Important RFCs About <acronym>DNS</acronym>
+		Implementation</title></info>
+
+	      <biblioentry>
+		<abbrev>RFC1535</abbrev>
+		<author><personname><surname>Gavron</surname><firstname>E.</firstname></personname></author>
+		<citetitle>A Security Problem and Proposed Correction With Widely
+		  Deployed <acronym>DNS</acronym> Software</citetitle>
+		<pubdate>October 1993</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1536</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Kumar</surname><firstname>A.</firstname></personname></author>
+		  <author><personname><firstname>J.</firstname><surname>Postel</surname></personname></author>
+		  <author><personname><firstname>C.</firstname><surname>Neuman</surname></personname></author>
+		  <author><personname><firstname>P.</firstname><surname>Danzig</surname></personname></author>
+		  <author><personname><firstname>S.</firstname><surname>Miller</surname></personname></author>
+		</authorgroup>
+		<citetitle>Common <acronym>DNS</acronym> Implementation
+		  Errors and Suggested Fixes</citetitle>
+		<pubdate>October 1993</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1982</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Elz</surname><firstname>R.</firstname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Bush</surname></personname></author>
+		</authorgroup>
+		<citetitle>Serial Number Arithmetic</citetitle>
+		<pubdate>August 1996</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC4074</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Morishita</surname><firstname>Y.</firstname></personname></author>
+		  <author><personname><firstname>T.</firstname><surname>Jinmei</surname></personname></author>
+		</authorgroup>
+		<citetitle>Common Misbehaviour Against <acronym>DNS</acronym>
+		Queries for IPv6 Addresses</citetitle>
+		<pubdate>May 2005</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title>Resource Record Types</title></info>
+
+	      <biblioentry>
+		<abbrev>RFC1183</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Everhart</surname><firstname>C.F.</firstname></personname></author>
+		  <author><personname><firstname>L. A.</firstname><surname>Mamakos</surname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Ullmann</surname></personname></author>
+		  <author><personname><firstname>P.</firstname><surname>Mockapetris</surname></personname></author>
+		</authorgroup>
+		<citetitle>New <acronym>DNS</acronym> RR Definitions</citetitle>
+		<pubdate>October 1990</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1706</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Manning</surname><firstname>B.</firstname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Colella</surname></personname></author>
+		</authorgroup>
+		<citetitle><acronym>DNS</acronym> NSAP Resource Records</citetitle>
+		<pubdate>October 1994</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2168</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Daniel</surname><firstname>R.</firstname></personname></author>
+		  <author><personname><firstname>M.</firstname><surname>Mealling</surname></personname></author>
+		</authorgroup>
+		<citetitle>Resolution of Uniform Resource Identifiers using
+		  the Domain Name System</citetitle>
+		<pubdate>June 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1876</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Davis</surname><firstname>C.</firstname></personname></author>
+		  <author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
+		  <author><personname><firstname>T.</firstname><firstname>Goodwin</firstname></personname></author>
+		  <author><personname><firstname>I.</firstname><surname>Dickinson</surname></personname></author>
+		</authorgroup>
+		<citetitle>A Means for Expressing Location Information in the
+		  Domain
+		  Name System</citetitle>
+		<pubdate>January 1996</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2052</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Gulbrandsen</surname><firstname>A.</firstname></personname></author>
+		  <author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
+		</authorgroup>
+		<citetitle>A <acronym>DNS</acronym> RR for Specifying the
+		  Location of
+		  Services</citetitle>
+		<pubdate>October 1996</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2163</abbrev>
+		<author><personname><surname>Allocchio</surname><firstname>A.</firstname></personname></author>
+		<citetitle>Using the Internet <acronym>DNS</acronym> to
+		  Distribute MIXER
+		  Conformant Global Address Mapping</citetitle>
+		<pubdate>January 1998</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2230</abbrev>
+		<author><personname><surname>Atkinson</surname><firstname>R.</firstname></personname></author>
+		<citetitle>Key Exchange Delegation Record for the <acronym>DNS</acronym></citetitle>
+		<pubdate>October 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2536</abbrev>
+		<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
+		<citetitle>DSA KEYs and SIGs in the Domain Name System (DNS)</citetitle>
+		<pubdate>March 1999</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2537</abbrev>
+		<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
+		<citetitle>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</citetitle>
+		<pubdate>March 1999</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2538</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
+		  <author><personname><surname>Gudmundsson</surname><firstname>O.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Storing Certificates in the Domain Name System (DNS)</citetitle>
+		<pubdate>March 1999</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2539</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
+		</authorgroup>
+		<citetitle>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</citetitle>
+		<pubdate>March 1999</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2540</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
+		</authorgroup>
+		<citetitle>Detached Domain Name System (DNS) Information</citetitle>
+		<pubdate>March 1999</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2782</abbrev>
+		<author><personname><surname>Gulbrandsen</surname><firstname>A.</firstname></personname></author>
+		<author><personname><surname>Vixie</surname><firstname>P.</firstname></personname></author>
+		<author><personname><surname>Esibov</surname><firstname>L.</firstname></personname></author>
+		<citetitle>A DNS RR for specifying the location of services (DNS SRV)</citetitle>
+		<pubdate>February 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2915</abbrev>
+		<author><personname><surname>Mealling</surname><firstname>M.</firstname></personname></author>
+		<author><personname><surname>Daniel</surname><firstname>R.</firstname></personname></author>
+		<citetitle>The Naming Authority Pointer (NAPTR) DNS Resource Record</citetitle>
+		<pubdate>September 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3110</abbrev>
+		<author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
+		<citetitle>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</citetitle>
+		<pubdate>May 2001</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3123</abbrev>
+		<author><personname><surname>Koch</surname><firstname>P.</firstname></personname></author>
+		<citetitle>A DNS RR Type for Lists of Address Prefixes (APL RR)</citetitle>
+		<pubdate>June 2001</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3596</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Thomson</surname><firstname>S.</firstname></personname></author>
+		  <author><personname><firstname>C.</firstname><surname>Huitema</surname></personname></author>
+		  <author><personname><firstname>V.</firstname><surname>Ksinant</surname></personname></author>
+		  <author><personname><firstname>M.</firstname><surname>Souissi</surname></personname></author>
+		</authorgroup>
+		<citetitle><acronym>DNS</acronym> Extensions to support IP
+		  version 6</citetitle>
+		<pubdate>October 2003</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3597</abbrev>
+		<author><personname><surname>Gustafsson</surname><firstname>A.</firstname></personname></author>
+		<citetitle>Handling of Unknown DNS Resource Record (RR) Types</citetitle>
+		<pubdate>September 2003</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title><acronym>DNS</acronym> and the Internet</title></info>
+
+	      <biblioentry>
+		<abbrev>RFC1101</abbrev>
+		<author><personname><surname>Mockapetris</surname><firstname>P. V.</firstname></personname></author>
+		<citetitle><acronym>DNS</acronym> Encoding of Network Names
+		  and Other Types</citetitle>
+		<pubdate>April 1989</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1123</abbrev>
+		<author><personname><surname>Braden</surname><surname>R.</surname></personname></author>
+		<citetitle>Requirements for Internet Hosts - Application and
+		  Support</citetitle>
+		<pubdate>October 1989</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1591</abbrev>
+		<author><personname><surname>Postel</surname><firstname>J.</firstname></personname></author>
+		<citetitle>Domain Name System Structure and Delegation</citetitle>
+		<pubdate>March 1994</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2317</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Eidnes</surname><firstname>H.</firstname></personname></author>
+		  <author><personname><firstname>G.</firstname><surname>de Groot</surname></personname></author>
+		  <author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
+		</authorgroup>
+		<citetitle>Classless IN-ADDR.ARPA Delegation</citetitle>
+		<pubdate>March 1998</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2826</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Internet Architecture Board</surname></personname></author>
+		</authorgroup>
+		<citetitle>IAB Technical Comment on the Unique DNS Root</citetitle>
+		<pubdate>May 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2929</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Eastlake</surname><firstname>D.</firstname><lineage>3rd</lineage></personname></author>
+		  <author><personname><surname>Brunner-Williams</surname><firstname>E.</firstname></personname></author>
+		  <author><personname><surname>Manning</surname><firstname>B.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Domain Name System (DNS) IANA Considerations</citetitle>
+		<pubdate>September 2000</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title><acronym>DNS</acronym> Operations</title></info>
+
+	      <biblioentry>
+		<abbrev>RFC1033</abbrev>
+		<author><personname><surname>Lottor</surname><firstname>M.</firstname></personname></author>
+		<citetitle>Domain administrators operations guide</citetitle>
+		<pubdate>November 1987</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1537</abbrev>
+		<author><personname><surname>Beertema</surname><firstname>P.</firstname></personname></author>
+		<citetitle>Common <acronym>DNS</acronym> Data File
+		  Configuration Errors</citetitle>
+		<pubdate>October 1993</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1912</abbrev>
+		<author><personname><surname>Barr</surname><firstname>D.</firstname></personname></author>
+		<citetitle>Common <acronym>DNS</acronym> Operational and
+		  Configuration Errors</citetitle>
+		<pubdate>February 1996</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2010</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Manning</surname><firstname>B.</firstname></personname></author>
+		  <author><personname><firstname>P.</firstname><surname>Vixie</surname></personname></author>
+		</authorgroup>
+		<citetitle>Operational Criteria for Root Name Servers</citetitle>
+		<pubdate>October 1996</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2219</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Hamilton</surname><firstname>M.</firstname></personname></author>
+		  <author><personname><firstname>R.</firstname><surname>Wright</surname></personname></author>
+		</authorgroup>
+		<citetitle>Use of <acronym>DNS</acronym> Aliases for
+		  Network Services</citetitle>
+		<pubdate>October 1997</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title>Internationalized Domain Names</title></info>
+
+	      <biblioentry>
+		<abbrev>RFC2825</abbrev>
+		<authorgroup>
+		  <author><personname><surname>IAB</surname></personname></author>
+		  <author><personname><surname>Daigle</surname><firstname>R.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>A Tangled Web: Issues of I18N, Domain Names,
+		       and the Other Internet protocols</citetitle>
+		<pubdate>May 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3490</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Faltstrom</surname><firstname>P.</firstname></personname></author>
+		  <author><personname><surname>Hoffman</surname><firstname>P.</firstname></personname></author>
+		  <author><personname><surname>Costello</surname><firstname>A.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Internationalizing Domain Names in Applications (IDNA)</citetitle>
+		<pubdate>March 2003</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3491</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Hoffman</surname><firstname>P.</firstname></personname></author>
+		  <author><personname><surname>Blanchet</surname><firstname>M.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Nameprep: A Stringprep Profile for Internationalized Domain Names</citetitle>
+		<pubdate>March 2003</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3492</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Costello</surname><firstname>A.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Punycode: A Bootstring encoding of Unicode
+		       for Internationalized Domain Names in
+		       Applications (IDNA)</citetitle>
+		<pubdate>March 2003</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title>Other <acronym>DNS</acronym>-related RFCs</title></info>
+
+	      <note>
+		<para>
+		  Note: the following list of RFCs, although
+		  <acronym>DNS</acronym>-related, are not
+		  concerned with implementing software.
+		</para>
+	      </note>
+	      <biblioentry>
+		<abbrev>RFC1464</abbrev>
+		<author><personname><surname>Rosenbaum</surname><firstname>R.</firstname></personname></author>
+		<citetitle>Using the Domain Name System To Store Arbitrary String
+		  Attributes</citetitle>
+		<pubdate>May 1993</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1713</abbrev>
+		<author><personname><surname>Romao</surname><firstname>A.</firstname></personname></author>
+		<citetitle>Tools for <acronym>DNS</acronym> Debugging</citetitle>
+		<pubdate>November 1994</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC1794</abbrev>
+		<author><personname><surname>Brisco</surname><firstname>T.</firstname></personname></author>
+		<citetitle><acronym>DNS</acronym> Support for Load
+		  Balancing</citetitle>
+		<pubdate>April 1995</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2240</abbrev>
+		<author><personname><surname>Vaughan</surname><firstname>O.</firstname></personname></author>
+		<citetitle>A Legal Basis for Domain Name Allocation</citetitle>
+		<pubdate>November 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2345</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Klensin</surname><firstname>J.</firstname></personname></author>
+		  <author><personname><firstname>T.</firstname><surname>Wolf</surname></personname></author>
+		  <author><personname><firstname>G.</firstname><surname>Oglesby</surname></personname></author>
+		</authorgroup>
+		<citetitle>Domain Names and Company Name Retrieval</citetitle>
+		<pubdate>May 1998</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2352</abbrev>
+		<author><personname><surname>Vaughan</surname><firstname>O.</firstname></personname></author>
+		<citetitle>A Convention For Using Legal Names as Domain Names</citetitle>
+		<pubdate>May 1998</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3071</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Klensin</surname><firstname>J.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Reflections on the DNS, RFC 1591, and Categories of Domains</citetitle>
+		<pubdate>February 2001</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3258</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Hardie</surname><firstname>T.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Distributing Authoritative Name Servers via
+		       Shared Unicast Addresses</citetitle>
+		<pubdate>April 2002</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3901</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Durand</surname><firstname>A.</firstname></personname></author>
+		  <author><personname><firstname>J.</firstname><surname>Ihren</surname></personname></author>
+		</authorgroup>
+		<citetitle>DNS IPv6 Transport Operational Guidelines</citetitle>
+		<pubdate>September 2004</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title>Obsolete and Unimplemented Experimental RFC</title></info>
+
+	      <biblioentry>
+		<abbrev>RFC1712</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Farrell</surname><firstname>C.</firstname></personname></author>
+		  <author><personname><firstname>M.</firstname><surname>Schulze</surname></personname></author>
+		  <author><personname><firstname>S.</firstname><surname>Pleitner</surname></personname></author>
+		  <author><personname><firstname>D.</firstname><surname>Baldoni</surname></personname></author>
+		</authorgroup>
+		<citetitle><acronym>DNS</acronym> Encoding of Geographical
+		  Location</citetitle>
+		<pubdate>November 1994</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2673</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Crawford</surname><firstname>M.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Binary Labels in the Domain Name System</citetitle>
+		<pubdate>August 1999</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2874</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Crawford</surname><firstname>M.</firstname></personname></author>
+		  <author><personname><surname>Huitema</surname><firstname>C.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>DNS Extensions to Support IPv6 Address Aggregation
+		       and Renumbering</citetitle>
+		<pubdate>July 2000</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	    <bibliodiv><info><title>Obsoleted DNS Security RFCs</title></info>
+
+	      <note>
+		<para>
+		  Most of these have been consolidated into RFC4033,
+		  RFC4034 and RFC4035 which collectively describe DNSSECbis.
+		</para>
+	      </note>
+	      <biblioentry>
+		<abbrev>RFC2065</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Eastlake</surname><lineage>3rd</lineage><firstname>D.</firstname></personname></author>
+		  <author><personname><firstname>C.</firstname><surname>Kaufman</surname></personname></author>
+		</authorgroup>
+		<citetitle>Domain Name System Security Extensions</citetitle>
+		<pubdate>January 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2137</abbrev>
+		<author><personname><surname>Eastlake</surname><lineage>3rd</lineage><firstname>D.</firstname></personname></author>
+		<citetitle>Secure Domain Name System Dynamic Update</citetitle>
+		<pubdate>April 1997</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC2535</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Eastlake</surname><lineage>3rd</lineage><firstname>D.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Domain Name System Security Extensions</citetitle>
+		<pubdate>March 1999</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3008</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Wellington</surname><firstname>B.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Domain Name System Security (DNSSEC)
+		       Signing Authority</citetitle>
+		<pubdate>November 2000</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3090</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Lewis</surname><firstname>E.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>DNS Security Extension Clarification on Zone Status</citetitle>
+		<pubdate>March 2001</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3445</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Massey</surname><firstname>D.</firstname></personname></author>
+		  <author><personname><surname>Rose</surname><firstname>S.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Limiting the Scope of the KEY Resource Record (RR)</citetitle>
+		<pubdate>December 2002</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3655</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Wellington</surname><firstname>B.</firstname></personname></author>
+		  <author><personname><surname>Gudmundsson</surname><firstname>O.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Redefinition of DNS Authenticated Data (AD) bit</citetitle>
+		<pubdate>November 2003</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3658</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Gudmundsson</surname><firstname>O.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Delegation Signer (DS) Resource Record (RR)</citetitle>
+		<pubdate>December 2003</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3755</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Weiler</surname><firstname>S.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Legacy Resolver Compatibility for Delegation Signer (DS)</citetitle>
+		<pubdate>May 2004</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3757</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Kolkman</surname><firstname>O.</firstname></personname></author>
+		  <author><personname><surname>Schlyter</surname><firstname>J.</firstname></personname></author>
+		  <author><personname><surname>Lewis</surname><firstname>E.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>Domain Name System KEY (DNSKEY) Resource Record
+		      (RR) Secure Entry Point (SEP) Flag</citetitle>
+		<pubdate>April 2004</pubdate>
+	      </biblioentry>
+	      <biblioentry>
+		<abbrev>RFC3845</abbrev>
+		<authorgroup>
+		  <author><personname><surname>Schlyter</surname><firstname>J.</firstname></personname></author>
+		</authorgroup>
+		<citetitle>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</citetitle>
+		<pubdate>August 2004</pubdate>
+	      </biblioentry>
+	    </bibliodiv>
+	  </bibliography>
+	</section>
+	<section xml:id="internet_drafts"><info><title>Internet Drafts</title></info>
+
+	  <para>
+	    Internet Drafts (IDs) are rough-draft working documents of
+	    the Internet Engineering Task Force. They are, in essence, RFCs
+	    in the preliminary stages of development. Implementors are
+	    cautioned not
+	    to regard IDs as archival, and they should not be quoted or cited
+	    in any formal documents unless accompanied by the disclaimer that
+	    they are "works in progress." IDs have a lifespan of six months
+	    after which they are deleted unless updated by their authors.
+	  </para>
+	</section>
+	<section xml:id="more_about_bind"><info><title>Other Documents About <acronym>BIND</acronym></title></info>
+
+	  <para/>
+	  <bibliography>
+	    <biblioentry>
+	      <authorgroup>
+		<author><personname><surname>Albitz</surname><firstname>Paul</firstname></personname></author>
+		<author><personname><firstname>Cricket</firstname><surname>Liu</surname></personname></author>
+	      </authorgroup>
+	      <citetitle><acronym>DNS</acronym> and <acronym>BIND</acronym></citetitle>
+	      <copyright>
+		<year>1998</year>
+		<holder>Sebastopol, CA: O'Reilly and Associates</holder>
+	      </copyright>
+	    </biblioentry>
+	  </bibliography>
+	</section>
+      </section>
+    </appendix>
+
+    <appendix xml:id="Bv9ARM.ch12"><info><title>BIND 9 DNS Library Support</title></info>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="libdns.xml"/>
+    </appendix>
+
+    <reference xml:id="Bv9ARM.ch13"><info><title>Manual pages</title></info>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dig/dig.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/mdig.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dig/host.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/delv/delv.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dig/nslookup.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/python/dnssec-checkds.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/python/dnssec-coverage.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-dsfromkey.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-importkey.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-keyfromlabel.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-keygen.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/python/dnssec-keymgr.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-revoke.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-settime.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-signzone.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dnssec/dnssec-verify.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/named/lwresd.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/named/named.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/named/named.conf.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/check/named-checkconf.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/check/named-checkzone.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/named-journalprint.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/named-nzd2nzf.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/named-rrchecker.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/nsupdate/nsupdate.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/rndc/rndc.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/rndc/rndc.conf.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/confgen/rndc-confgen.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/confgen/ddns-confgen.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/arpaname.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/dnstap-read.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/genrandom.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/isc-hmac-fixup.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/tools/nsec3hash.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/pkcs11/pkcs11-destroy.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/pkcs11/pkcs11-list.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/pkcs11/pkcs11-keygen.docbook"/>
+      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/pkcs11/pkcs11-tokens.docbook"/>
+    </reference>
+
+  </book>