9.0.0b3

author: Internet Software Consortium, Inc <@isc.org> 2007-09-07 14:08:19 -0600
committer: LaMont Jones <lamont@debian.org> 2007-09-07 14:08:19 -0600
commit: 93744e253a50cdd78097dc5a150f4c035e8cbcc9 (patch)
tree: f7470097a04345f967281dd4d658dd065c51d166 /doc
parent: 6257efc35455318993208bef65a551ac6039f51f (diff)
download: bind9-93744e253a50cdd78097dc5a150f4c035e8cbcc9.tar.gz
36 files changed, 5551 insertions, 7465 deletions
diff --git a/doc/arm/BV9ARM.PDF b/doc/arm/BV9ARM.PDF
deleted file mode 100644
index 0974407e..00000000
--- a/doc/arm/BV9ARM.PDF
+++ /dev/null
diff --git a/doc/arm/BV9ARM.1.html b/doc/arm/Bv9ARM.1.html
index 24e5fe4f..949b3790 100644..100755
--- a/doc/arm/BV9ARM.1.html
+++ b/doc/arm/Bv9ARM.1.html
@@ -2,7 +2,7 @@
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
 <TITLE> Section 1.	Introduction </TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
 <OL>
@@ -34,30 +34,30 @@ The Berkeley Internet Name Domain (BIND) implements an Internet nameserver for a
  </A>
 1.2	Organization of This Document</H3>
 </OL>
-<P CLASS="2LevelContinued1">
+<P CLASS="2LevelContinued">
 <A NAME="pgfId=997355">
  </A>
-In this document, <EM CLASS="Emphasis">
+In this document, <EM CLASS="EquationVariables">
 Section 1</EM>
- introduces the basic DNS and BIND concepts. <EM CLASS="Emphasis">
+ introduces the basic DNS and BIND concepts. <EM CLASS="EquationVariables">
 Section 2</EM>
- describes resource requirements for running BIND in various environments. Information in <EM CLASS="Emphasis">
+ describes resource requirements for running BIND in various environments. Information in <EM CLASS="EquationVariables">
 Section 3</EM>
- is <EM CLASS="Emphasis">
+ is <EM CLASS="EquationVariables">
 task-oriented</EM>
- in its presentation and is organized functionally, to aid in the process of installing the BINDv9 software. The task-oriented section is followed by <EM CLASS="Emphasis">
+ in its presentation and is organized functionally, to aid in the process of installing the BINDv9 software. The task-oriented section is followed by <EM CLASS="EquationVariables">
 Section 4</EM>
-, which contains more advanced concepts that the system administrator may need for implementing certain options. The contents of <EM CLASS="Emphasis">
+, which contains more advanced concepts that the system administrator may need for implementing certain options. The contents of <EM CLASS="EquationVariables">
 Section 5</EM>
- are organized as in a reference manual to aid in the ongoing maintenance of the software.  <EM CLASS="Emphasis">
+ are organized as in a reference manual to aid in the ongoing maintenance of the software. <EM CLASS="EquationVariables">
 Section 6</EM>
- addresses security considerations, and <EM CLASS="Emphasis">
+ addresses security considerations, and <EM CLASS="EquationVariables">
 Section 7</EM>
- contains troubleshooting help. The main body of the document is followed by several <EM CLASS="Emphasis">
+ contains troubleshooting help. The main body of the document is followed by several <EM CLASS="EquationVariables">
 Appendices</EM>
- which contain useful reference information, such as a <EM CLASS="Emphasis">
+ which contain useful reference information, such as a <EM CLASS="EquationVariables">
 Glossary</EM>
- and a <EM CLASS="Emphasis">
+ and a <EM CLASS="EquationVariables">
 Bibliography</EM>
 , as well as historic information related to BIND and the Domain Name System.</P>
 </DIV>
@@ -71,20 +71,24 @@ Bibliography</EM>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997382">
  </A>
-In this document, the following general typographic conventions are used:</P>
+In this document, we use the following general typographic conventions:</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody">
+<P CLASS="CellBody3">
 <A NAME="pgfId=997359">
  </A>
-When describing:</P>
+<EM CLASS="EquationVariables">
+To describe:</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody">
+<P CLASS="CellBody3">
 <A NAME="pgfId=997361">
  </A>
-Style Used:</P>
+<EM CLASS="EquationVariables">
+Style:</EM>
+</P>
 </TD>
 </TR>
 <TR>
@@ -92,30 +96,14 @@ Style Used:</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=997363">
  </A>
-A pathname, filename, URL, hostname, or mailing list name</P>
+a pathname, filename, URL, hostname, mailing list name, or new term or concept</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody1">
+<P CLASS="CellBody5">
 <A NAME="pgfId=997365">
  </A>
-<EM CLASS="Emphasis">
-Times Italic</EM>
-</P>
-</TD>
-</TR>
-<TR>
-<TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody">
-<A NAME="pgfId=997367">
- </A>
-A new term or concept</P>
-</TD>
-<TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody1">
-<A NAME="pgfId=997369">
- </A>
-<EM CLASS="Emphasis">
-Times Italic</EM>
+<EM CLASS="EquationVariables">
+Italic</EM>
 </P>
 </TD>
 </TR>
@@ -124,13 +112,14 @@ Times Italic</EM>
 <P CLASS="CellBody">
 <A NAME="pgfId=997371">
  </A>
-Literal user input</P>
+literal user input</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody2">
+<P CLASS="CellBody4">
 <A NAME="pgfId=997373">
  </A>
-Courier Bold
+<KBD CLASS="Literal-user-input">
+Fixed Width Bold</KBD>
 </P>
 </TD>
 </TR>
@@ -139,14 +128,14 @@ Courier Bold
 <P CLASS="CellBody">
 <A NAME="pgfId=997375">
  </A>
-Variable user input</P>
+variable user input</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody3">
-<A NAME="pgfId=997377">
+<P CLASS="CellBody5">
+<A NAME="pgfId=1034911">
  </A>
-<EM CLASS="Emphasis">
-Courier Italic</EM>
+<EM CLASS="Optional-meta-syntax">
+Fixed Width Italic</EM>
 </P>
 </TD>
 </TR>
@@ -155,14 +144,14 @@ Courier Italic</EM>
 <P CLASS="CellBody">
 <A NAME="pgfId=997379">
  </A>
-Program output</P>
+program output</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody4">
 <A NAME="pgfId=997381">
  </A>
-<KBD CLASS="Literal-user-input">
-Courier Plain</KBD>
+<CODE CLASS="Program-Process">
+Fixed Width</CODE>
 </P>
 </TD>
 </TR>
@@ -174,16 +163,20 @@ The following conventions are used in descriptions of the BIND configuration fil
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody">
+<P CLASS="CellBody3">
 <A NAME="pgfId=997385">
  </A>
-When describing:</P>
+<EM CLASS="EquationVariables">
+When describing:</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody">
+<P CLASS="CellBody3">
 <A NAME="pgfId=997387">
  </A>
-Style Used:</P>
+<EM CLASS="EquationVariables">
+Style Used:</EM>
+</P>
 </TD>
 </TR>
 <TR>
@@ -194,11 +187,11 @@ Style Used:</P>
 keywords</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody5">
+<P CLASS="CellBody6">
 <A NAME="pgfId=997391">
  </A>
-<KBD CLASS="Literal-user-input">
-Arial Bold</KBD>
+<EM CLASS="production_target">
+Sans Serif Bold</EM>
 </P>
 </TD>
 </TR>
@@ -210,12 +203,12 @@ Arial Bold</KBD>
 variables</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody6">
+<H6 CLASS="CellBody7">
 <A NAME="pgfId=997395">
  </A>
-<EM CLASS="Emphasis">
-Arial Italic</EM>
-</P>
+<EM CLASS="variable">
+Sans Serif Italic</EM>
+</H6>
 </TD>
 </TR>
 <TR>
@@ -226,11 +219,11 @@ Arial Italic</EM>
 &quot;meta-syntactic&quot; information (within brackets when optional)</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody3">
+<P CLASS="CellBody5">
 <A NAME="pgfId=997399">
  </A>
-<EM CLASS="Emphasis">
-Courier Italic</EM>
+<EM CLASS="Optional-meta-syntax">
+Fixed Width Italic</EM>
 </P>
 </TD>
 </TR>
@@ -242,11 +235,11 @@ Courier Italic</EM>
 Command line input</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody2">
+<P CLASS="CellBody4">
 <A NAME="pgfId=997403">
  </A>
 <KBD CLASS="Literal-user-input">
-Courier Bold</KBD>
+Fixed Width Bold</KBD>
 </P>
 </TD>
 </TR>
@@ -261,8 +254,8 @@ Program output</P>
 <P CLASS="CellBody4">
 <A NAME="pgfId=997407">
  </A>
-<KBD CLASS="Literal-user-input">
-Courier Plain</KBD>
+<CODE CLASS="Program-Process">
+Fixed Width</CODE>
 </P>
 </TD>
 </TR>
@@ -277,7 +270,7 @@ Optional input</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=997411">
  </A>
-Text is enclosed in square brackets </P>
+Text is enclosed in square brackets</P>
 </TD>
 </TR>
 </TABLE>
@@ -292,15 +285,15 @@ Text is enclosed in square brackets </P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997414">
  </A>
-The purpose of this document is to explain the installation and basic upkeep of the BIND software package, and we begin by reviewing the fundamentals of the domain naming system as they relate to BIND. BIND consists of a <EM CLASS="Emphasis">
+The purpose of this document is to explain the installation and basic upkeep of the BIND software package, and we begin by reviewing the fundamentals of the domain naming system as they relate to BIND. BIND consists of a <EM CLASS="EquationVariables">
 nameserver</EM>
  (or &quot;daemon&quot;) called <CODE CLASS="Program-Process">
 named</CODE>
  and a <CODE CLASS="Program-Process">
 resolver</CODE>
- library. The BIND server runs in the background, servicing queries on a well known network port. The standard port for UDP and TCP, usually port 53,  is specified in<CODE CLASS="Program-Process">
+ library. The BIND server runs in the background, servicing queries on a well known network port. The standard port for UDP and TCP, usually port 53, is specified in<CODE CLASS="Program-Process">
  /etc/services</CODE>
-. The <EM CLASS="Emphasis">
+. The <EM CLASS="EquationVariables">
 resolver</EM>
  is a set of routines residing in a system library that provides the interface that programs can use to access the domain name services.</P>
 <DIV>
@@ -313,49 +306,49 @@ resolver</EM>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997416">
  </A>
-A nameserver (NS) is a program that stores information about named resources and responds to queries from programs called <EM CLASS="Emphasis">
+A nameserver (NS) is a program that stores information about named resources and responds to queries from programs called <EM CLASS="EquationVariables">
 resolvers</EM>
  which act as client processes. The basic function of an NS is to provide information about network objects by answering queries.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997417">
  </A>
-With the nameserver, the network can be broken into a hierarchy of domains. The name space is organized as a tree according to organizational or administrative boundaries. Each node of the tree, called a domain, is given a label. The name of the domain is the concatenation of all the labels of the domains from the root to the current domain. 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 domain. The whole name space is partitioned into areas called <EM CLASS="Emphasis">
+With the nameserver, the network can be broken into a hierarchy of domains. The name space is organized as a tree according to organizational or administrative boundaries. Each node of the tree, called a domain, is given a label. The name of the domain is the concatenation of all the labels of the domains from the root to the current domain. 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 domain. The whole name space is partitioned into areas called <EM CLASS="EquationVariables">
 zones</EM>
-, each starting at a domain and extending down to the leaf domains or to domains where other zones start. Zones usually represent administrative boundaries. For example, a domain name for a host at the company <EM CLASS="Emphasis">
+, each starting at a domain and extending down to the leaf domains or to domains where other zones start. Zones usually represent administrative boundaries. For example, a domain name for a host at the company <EM CLASS="EquationVariables">
 Example, Inc.</EM>
  would be:</P>
 <P CLASS="3LevelContinued1">
 <A NAME="pgfId=997418">
  </A>
-<EM CLASS="Emphasis">
+<EM CLASS="EquationVariables">
 ourhost.example.com</EM>
 </P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997419">
  </A>
-The top level domain for corporate organizations is <EM CLASS="Emphasis">
+The top level domain for corporate organizations is <EM CLASS="EquationVariables">
 com</EM>
-; <EM CLASS="Emphasis">
+; <EM CLASS="EquationVariables">
 example</EM>
- is a subdomain of <EM CLASS="Emphasis">
+ is a subdomain of <EM CLASS="EquationVariables">
 .com</EM>
-; and <EM CLASS="Emphasis">
+; and <EM CLASS="EquationVariables">
 ourhost</EM>
  is the name of the host.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997420">
  </A>
 The specifications for the domain nameserver are defined in RFC1034, RFC1035 and RFC974. These documents can be found in<BR>
-<EM CLASS="Emphasis">
+<EM CLASS="pathname">
 /usr/src/etc/named/doc</EM>
  in 4.4BSD or are available via <CODE CLASS="Program-Process">
 FTP</CODE>
  from<BR>
-<EM CLASS="Emphasis">
+<EM CLASS="URL">
 ftp://www.isi.edu/in-notes/</EM>
- or via the Web at <EM CLASS="Emphasis">
+ or via the Web at <EM CLASS="URL">
 http://www.ietf.org/rfc/</EM>
-.  (See Appendix C for complete information on finding and retrieving RFCs.) It is also recommended that you read the related <CODE CLASS="Program-Process">
+. (See Appendix C for complete information on finding and retrieving RFCs.) It is also recommended that you read the related <CODE CLASS="Program-Process">
 man</CODE>
  pages: <CODE CLASS="Program-Process">
 named</CODE>
@@ -377,31 +370,31 @@ As we stated previously, a zone is a point of delegation in the DNS tree. A zone
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997423">
  </A>
-To properly operate a nameserver, it is important to understand the difference between a <EM CLASS="Emphasis">
+To properly operate a nameserver, it is important to understand the difference between a <EM CLASS="EquationVariables">
 zone</EM>
- and a <EM CLASS="Emphasis">
+ and a <EM CLASS="EquationVariables">
 domain</EM>
 .</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997424">
  </A>
-As an example, consider the <EM CLASS="Emphasis">
+As an example, consider the <EM CLASS="EquationVariables">
 example.com</EM>
- domain, which includes names such as <EM CLASS="Emphasis">
+ domain, which includes names such as <EM CLASS="EquationVariables">
 host.aaa.example.com </EM>
-and <EM CLASS="Emphasis">
+and <EM CLASS="EquationVariables">
 host.bbb.example.com</EM>
- even though the <EM CLASS="Emphasis">
+ even though the <EM CLASS="EquationVariables">
 example.com</EM>
- zone includes only delegations for the <EM CLASS="Emphasis">
+ zone includes only delegations for the <EM CLASS="EquationVariables">
 aaa.example.com</EM>
- and <EM CLASS="Emphasis">
+ and <EM CLASS="EquationVariables">
 bbb.example.com</EM>
- 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 nameservers. Every name in the DNS tree is a <EM CLASS="Emphasis">
+ 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 nameservers. Every name in the DNS tree is a <EM CLASS="EquationVariables">
 domain</EM>
-, even if it is <EM CLASS="Emphasis">
+, even if it is <EM CLASS="EquationVariables">
 terminal</EM>
-, that is, has no <EM CLASS="Emphasis">
+, that is, has no <EM CLASS="EquationVariables">
 subdomains</EM>
 . Every subdomain is a domain and every domain except the root is also a subdomain. The terminology is not intuitive and it is suggested that you read RFCs 1033, 1034, and 1035 to gain a complete understanding of this difficult and subtle topic.</P>
 <P CLASS="3LevelContinued">
@@ -409,25 +402,25 @@ subdomains</EM>
  </A>
 Though BIND is a Domain Nameserver, it deals primarily in terms of zones. The primary and secondary declarations in the <CODE CLASS="Program-Process">
 named.conf</CODE>
- file specify zones, not domains. When you ask some other site if it is willing to be a secondary server for your <EM CLASS="Emphasis">
+ file specify zones, not domains. When you ask some other site if it is willing to be a secondary server for your <EM CLASS="EquationVariables">
 domain</EM>
 , you are actually asking for secondary service for some collection of zones.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997426">
  </A>
-Each zone will have one <EM CLASS="Emphasis">
+Each zone will have one <EM CLASS="EquationVariables">
 primary master</EM>
- (also called <EM CLASS="Emphasis">
+ (also called <EM CLASS="EquationVariables">
 primary</EM>
-) server which 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. There there will be some number of <EM CLASS="Emphasis">
+) server which 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. There there will be some number of <EM CLASS="EquationVariables">
 secondary master </EM>
-servers, which load the zone contents using the DNS protocol (that is, the secondary servers will contact the primary and fetch the zone data using TCP). This set of servers--the primary and all of its secondaries--should be listed in the NS records in the parent zone and will constitute a <EM CLASS="Emphasis">
+servers, which load the zone contents using the DNS protocol (that is, the secondary servers will contact the primary and fetch the zone data using TCP). This set of servers--the primary and all of its secondaries--should be listed in the NS records in the parent zone and will constitute a <EM CLASS="EquationVariables">
 delegation</EM>
 . This set of servers must also be listed in the zone file itself, usually under the <CODE CLASS="Program-Process">
 @</CODE>
- name which indicates the <EM CLASS="Emphasis">
+ name which indicates the <EM CLASS="EquationVariables">
 top level</EM>
- or <EM CLASS="Emphasis">
+ or <EM CLASS="EquationVariables">
 root</EM>
  of the current zone. You can list servers in the zone's top-level <CODE CLASS="Program-Process">
 @</CODE>
@@ -445,7 +438,7 @@ cuts around the bottom edge of the zone.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997430">
  </A>
-Adding a zone as a type master or type slave will tell the server to answer questions for the zone authoritatively. If the server is able to load the zone into memory without any errors it will set the AA bit when it replies to queries for the zone.  See RFCs 1034 and 1035 for more information about the AA bit.</P>
+Adding a zone as a type master or type slave will tell the server to answer questions for the zone authoritatively. If the server is able to load the zone into memory without any errors it will set the AA bit when it replies to queries for the zone. See RFCs 1034 and 1035 for more information about the AA bit.</P>
 </DIV>
 <DIV>
 <OL>
@@ -457,11 +450,11 @@ Adding a zone as a type master or type slave will tell the server to answer ques
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997432">
  </A>
-A DNS server can be master for some zones and slave for others or can be only a master, or only a slave, or can serve no zones and just answer queries via its <EM CLASS="Emphasis">
+A DNS server can be master for some zones and slave for others or can be only a master, or only a slave, or can serve no zones and just answer queries via its <EM CLASS="EquationVariables">
 cache</EM>
-. Master servers are often also called <EM CLASS="Emphasis">
+. Master servers are often also called <EM CLASS="EquationVariables">
 primaries</EM>
- and slave servers are often also called <EM CLASS="Emphasis">
+ and slave servers are often also called <EM CLASS="EquationVariables">
 secondaries</EM>
 . Both master/primary and slave/secondary servers are authoritative for a zone.</P>
 <P CLASS="3LevelContinued">
@@ -478,9 +471,9 @@ All servers keep data in their cache until the data expires, based on a TTL (Tim
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997435">
  </A>
-The <EM CLASS="Emphasis">
+The <EM CLASS="EquationVariables">
 primary master</EM>
- server is the ultimate source of information about a domain. The primary master is an authoritative server configured to be the source of zone transfer for one or  more secondary servers. The primary master server obtains data for the zone from a file on disk.</P>
+ server is the ultimate source of information about a domain. The primary master is an authoritative server configured to be the source of zone transfer for one or more secondary servers. The primary master server obtains data for the zone from a file on disk.</P>
 </DIV>
 <DIV>
 <OL>
@@ -492,9 +485,9 @@ primary master</EM>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997437">
  </A>
-A <EM CLASS="Emphasis">
+A <EM CLASS="EquationVariables">
 slave server</EM>
-, also called a <EM CLASS="Emphasis">
+, also called a <EM CLASS="EquationVariables">
 secondary server</EM>
 , is an authoritative server that uses zone transfers from the primary master server to retrieve the zone data. Optionally, the slave server obtains zone data from a cache on disk. Slave servers provide necessary redundancy. All secondary/slave servers are named in the NS resource records (RRs) for the zone.</P>
 </DIV>
@@ -508,7 +501,7 @@ secondary server</EM>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997439">
  </A>
-Some servers are <EM CLASS="Emphasis">
+Some servers are <EM CLASS="EquationVariables">
 caching only servers</EM>
 . This means that the server caches the information that it receives and uses it until the data expires. A caching only server is a server that is not authoritative for any zone. This server services queries and asks other servers, who have the authority, for the information it needs.</P>
 </DIV>
@@ -522,11 +515,11 @@ caching only servers</EM>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997441">
  </A>
-Instead of interacting with the nameservers for the root and other domains, a <EM CLASS="Emphasis">
+Instead of interacting with the nameservers for the root and other domains, a <EM CLASS="EquationVariables">
 forwarding server</EM>
- always forwards queries it cannot satisfy from its authoritative data or cache to a fixed list of other servers. The forwarded queries are also known as <EM CLASS="Emphasis">
+ always forwards queries it cannot satisfy from its authoritative data or cache to a fixed list of other servers. The forwarded queries are also known as <EM CLASS="EquationVariables">
 recursive queries, </EM>
-the same type as a client would send to a server.  There may be one or more servers forwarded to, and they are queried in turn until the list is exhausted or an answer is found. A forwarding server  is typically used when you do not wish all the servers at a given site to interact with the rest of the Internet servers. A typical scenario would involve a number of internal DNS servers, and an internet firewall. The servers which cannot pass packets through the firewall would forward to the server which can, which would ask the internet DNS servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the workstations can take advantage of. </P>
+the same type as a client would send to a server. There may be one or more servers forwarded to, and they are queried in turn until the list is exhausted or an answer is found. A forwarding server is typically used when you do not wish all the servers at a given site to interact with the rest of the Internet servers. A typical scenario would involve a number of internal DNS servers, and an internet firewall. The servers which cannot pass packets through the firewall would forward to the server which can, which would ask the internet DNS servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the workstations can take advantage of. </P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997442">
  </A>
@@ -539,30 +532,13 @@ There is no prohibition against declaring a server to be a forwarder even though
  </A>
 1.4.3.5	Stealth Server</H5>
 </OL>
-<!--
-[[P CLASS="comment"]]
-[[A NAME="pgfId=997445"]]
- [[/A]]
-A [[A NAME="marker=997444"]]
- [[/A]]
-stealth server is a primary master server that is neither listed in any root zone files nor advertised as being a server. It is set up to hide the true master server for a zone in order to provide some measure of security, or protect the zone from [[A NAME="marker=997446"]]
- [[/A]]
-Denial of Service ([[A NAME="marker=997447"]]
- [[/A]]
-DoS) attacks, or reduce the load on the main server, or any number of other reasons. It is also used to provide some measure of network redundancy. Slave servers load zone data from it.[[/P]]
-[[P CLASS="4LevelContinued"]]
-[[A NAME="pgfId=997347"]]
- [[/A]]
--->
 <P CLASS="4LevelContinued">
-A stealth server is a server that answers authoritatively for a zone, but is not listed in that zone's NS records. Stealth servers can be used as a way to centralise distribution of a zone, without having to edit the zone on a remote nameserver. Where the master file for a zone resides on a stealth server in this way,  it often referred to as a 'hidden primary' configuration. Stealth servers can also be a way to keep a local copy of a zone for rapid access to the zone's records, even if all 'official' nameservers for the zone are inaccessable.</P>
-<P CLASS="Body">
-<A NAME="pgfId=1007863">
+<A NAME="pgfId=1014846">
  </A>
-&nbsp;</P>
+A stealth server is a server that answers authoritatively for a zone, but is not listed in that zone's NS records. Stealth servers can be used as a way to centralize distribution of a zone, without having to edit the zone on a remote nameserver. Where the master file for a zone resides on a stealth server in this way, it is often referred to as a &quot;hidden primary&quot; configuration. Stealth servers can also be a way to keep a local copy of a zone for rapid access to the zone's records, even if all &quot;official&quot; nameservers for the zone are inaccessible.</P>
 </DIV>
 </DIV>
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
 </DIV>
+<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> 
 </BODY>
 </HTML>
diff --git a/doc/arm/BV9ARM.2.html b/doc/arm/Bv9ARM.2.html
index 748670f4..20a50567 100644..100755
--- a/doc/arm/BV9ARM.2.html
+++ b/doc/arm/Bv9ARM.2.html
@@ -2,99 +2,90 @@
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
 <TITLE> Section 2.	BIND Resource Requirements</TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
 <OL>
 <H1 CLASS="1Level">
 <A NAME="pgfId=997350">
-</A>
+ </A>
 Section 2.	BIND Resource Requirements</H1>
 </OL>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997351">
-</A>
+ </A>
 2.1	Hardware requirements</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997352">
-</A>
+ </A>
 DNS hardware requirements have traditionally been quite modest. For many installations, servers that have been pensioned off from active duty have performed admirably as DNS servers.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997353">
-</A>
+ </A>
 The DNSSEC and IPv6 features of BINDv9 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. BINDv9 is now fully multithreaded, allowing full utilization of multiprocessor systems, for installations that need it.</P>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997354">
-</A>
+ </A>
 2.2	CPU Requirements</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997355">
-</A>
+ </A>
 CPU requirements for BINDv9 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.</P>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997356">
-</A>
+ </A>
 2.3	Memory Requirements </H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997357">
-</A>
+ </A>
 The memory of the server has to be large enough to fit the cache and zones loaded off disk. Future releases of BINDv9 will provide methods to limit the amount of memory used by the cache, at the expense of reducing cache hit rates and causing more DNS traffic. 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 nameserver 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. Ideally, the resource limits should be set higher than this stable size.</P>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997358">
-</A>
+ </A>
 2.4	Nameserver Intensive Environment Issues</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997359">
-</A>
+ </A>
 For nameserver intensive environments, there are two alternative configurations that may be used. The first is where clients and any second-level internal nameservers query a main nameserver, 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 nameservers 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 nameservers share their cached data.</P>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997360">
-</A>
+ </A>
 2.5	Operating Systems Supported by the Internet Software Consortium</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997361">
-</A>
+ </A>
 ISC BINDv9 compiles and runs on the following operating systems:</P>
-<PRE CLASS="2Level-fixed"><A NAME="pgfId=997362"></A>
-IBM AIX 4.3
-<PRE CLASS="2Level-fixed"><A NAME="pgfId=997363"></A>
-Compaq Digital/Tru64 UNIX 4.0D
-<PRE CLASS="2Level-fixed"><A NAME="pgfId=997364"></A>
-HP HP-UX 11
-<PRE CLASS="2Level-fixed"><A NAME="pgfId=997365"></A>
-IRIX64 6.5
-<PRE CLASS="2Level-fixed"><A NAME="pgfId=997366"></A>
-Red Hat Linux 6.0, 6.1
-<PRE CLASS="2Level-fixed"><A NAME="pgfId=997367"></A>
-Sun Solaris 2.6, 7, 8 (beta)
-<PRE CLASS="2Level-fixed"><A NAME="pgfId=997368"></A>
-FreeBSD 3.4-STABLE
-<PRE CLASS="2Level-fixed"><A NAME="pgfId=997369"></A>
-NetBSD-current with &quot;unproven&quot; pthreads</PRE>
-<P CLASS="Body">
-<A NAME="pgfId=997347">
-</A>
-&nbsp;</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=997362">
+ </A>
+IBM AIX 4.3<BR>
+Compaq Digital/Tru64 UNIX 4.0D<BR>
+HP HP-UX 11<BR>
+IRIX64 6.5<BR>
+Red Hat Linux 6.0, 6.1<BR>
+Sun Solaris 2.6, 7, 8 (beta)<BR>
+FreeBSD 3.4-STABLE<BR>
+NetBSD-current with &quot;unproven&quot; pthreads</P>
 </DIV>
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
+<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> 
 </BODY>
 </HTML>
diff --git a/doc/arm/BV9ARM.3.html b/doc/arm/Bv9ARM.3.html
index 90e0206c..a505907f 100644..100755
--- a/doc/arm/BV9ARM.3.html
+++ b/doc/arm/Bv9ARM.3.html
@@ -2,271 +2,259 @@
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
 <TITLE> Section 3.	Nameserver Configuration</TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
 <OL>
 <H1 CLASS="1Level">
 <A NAME="pgfId=997350">
-</A>
+ </A>
 Section 3.	Nameserver Configuration</H1>
 </OL>
 <P CLASS="1LevelContinued">
 <A NAME="pgfId=997351">
-</A>
+ </A>
 In this section we provide some suggested configurations along with guidelines for their use. We also address the topic of reasonable option setting.</P>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997353">
-</A>
+ </A>
 3.1	<A NAME="30164">
-</A>
+ </A>
 Sample Configuration and Logging</H3>
 </OL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997354"></A>
-logging {
-       channel named_log {
-           file &quot;logs/named.log&quot;;
-           print-time yes;
-           print-category yes;
-           print-severity yes;
-           severity info;
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997354"></A>
+
+<CODE>logging {
+        channel <VAR>named_log</VAR> {
+             file &quot;<EM>logs/named.log</EM>&quot;;
+             print-time <VAR>yes</VAR>;
+             print-category <VAR>yes</VAR>;
+             print-severity <VAR>yes</VAR>;
+             severity <VAR>info</VAR>;
 };
-       channel security_log {
-           file &quot;logs/security.log&quot; versions 7 ;
-           print-time yes;
+       channel <VAR>security_log</VAR> {
+             file &quot;<EM>logs/security.log</EM> &quot; <VAR>versions 7</VAR> ;
+             print-time <VAR>yes</VAR> ;
 };
-       category default { named_log; default_debug; };
-       category security { security_log };
+       category <VAR>default</VAR> { named_log; default_debug; };
+             category security { security_log };
 };
-// The two corporate subnets.  Use real IP numbers here in the real world.
+                                                    // The two corporate subnets.
+                                                    // Use real IP numbers
+                                                    // here in the real world.
 acl corpnet { 192.168.4.0/24; 192.168.7.0/24; };
-// The options statement.
+                              // The options statement.
 options {
-   directory &quot;/etc/namedb&quot;;    // Directory
-   pid-file &quot;named.pid&quot;;        // Put .pid file in named directory.
-   named-xfer &quot;/path/to/named-xfer&quot;;  // Where is our named-xfer ?
-   check-names master fail;												// Fail on db errors in master zones.
-   check-names slave warn;												// Warn about db errors
-                              // in slave zones.
-   check-names response warn;												// Warn about invalid responses
-   use-id-pool yes;												// Help prevent spoofing
-   host-statistics yes;												// Keep track of hosts/servers
-                               // we've talked to.
-   listen-on { 192.168.7.20; };       // Listen on this address.
+   directory &quot;<EM>/etc/namedb</EM>&quot;;      // Directory
+   pid-file &quot;<EM>named.pid</EM>&quot;;         // Put .pid file in named directory.
+   check-names master <VAR>fail</VAR>;              // Fail on db errors in master zones.
+   check-names slave <VAR>warn</VAR>;               // Warn about db errors
+                                                    // in slave zones.
+   check-names response <VAR>warn</VAR>;            // Warn about invalid responses
+   use-id-pool <VAR>yes</VAR>;                      // Help prevent spoofing
+   host-statistics <VAR>yes</VAR>;                  // Keep track of hosts/servers
+                                                    // we've talked to.
+   listen-on { 192.168.7.20; };                     // Listen on this address.
    query-source address 192.168.7.20 port 53 ;
-                                     // Source queries from port 53
-                                      // to get past firewall.
-   allow-transfer { none; };        // Don't allow anyone to
-                                      // transfer zones.
-   allow-query { corpnet; };        // Allow only corpnets to query server.
-                                      // Helps prevent DoS, spoofing.
-   allow-recursion { corpnet; };     // Same, except this is for recursion.
+                                                    // Source queries from port 53
+                                                    // to get past firewall.
+   allow-transfer { <VAR>none</VAR>; };             // Don't allow anyone to
+                                                    // transfer zones.
+   allow-query { corpnet; };                        // Allow only corpnets to query server.
+                                                    // Helps prevent DoS, spoofing.
+   allow-recursion { corpnet; };                    // Same, except this is for recursion.
 };
+
+   include &quot;<EM>keys.conf</EM>&quot;;                   // Include a keys.conf with
+                                                     // TSIG/DNSSEC keys.
+                                                     // Shouldn't be readable to anyone
+                                                     // except BIND user.
+   zone &quot;<EM>.</EM>&quot;{ type <VAR>hint</VAR>; file &quot;<EM>local/named.root</EM>&quot;;
+};                                                    // root hints
+
+   zone &quot;<EM>0.0.127.IN-ADDR.ARPA</EM>&quot; {
+   type <VAR>master</VAR>; file &quot;<EM>local/localhost.db</EM>&quot;; notify <VAR>no</VAR>;
+                                                     // localhost
+};
+
+   zone &quot;example.com&quot; {                      // Example zone for &quot;<EM>example.com</EM>&quot;.
+   type <VAR>master</VAR>;                             // It's a master zone.
+   file &quot;<EM>m/example.com.db</EM>&quot;;                 // The file is here.
+   allow-query { <VAR>any</VAR>; };                      // Allow anyone to query.
+   allow-transfer { corpnet; };                         // Only allow corp nets to transfer zone.
+}; 
+ 
+   zone &quot;<EM>offsite.example.com</EM>&quot; {              // Example zone for an off-site corp zone.
+   type <VAR>slave</VAR>;                                        // It's a slave zone.
+   masters { 192.168.4.12; };                                // The master is at this address.
+   file &quot;<EM>s/offsite.example.com.db</EM>&quot;;             // The file is here.
+   notify <VAR>no</VAR>;                                             // Don't worry about NOTIFYing.
+allow-query { <VAR>any</VAR>; };                                 // Allow anyone to query.
+};</CODE>
+
 </PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=1007322"></A>
-include &quot;keys.conf&quot;;                     // Include a keys.conf with
-                                         // TSIG/DNSSEC keys.
-                                         // Shouldn't be readable to anyone
-                                          // except BIND user.
-zone &quot;.&quot;{ type hint; file &quot;local/named.root&quot;; };
-                                          // root hints
-</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997391"></A>
-zone &quot;0.0.127.IN-ADDR.ARPA&quot; {</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997392"></A>
-        type master; file &quot;local/localhost.db&quot;; notify no;
-                                          // localhost
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997395"></A>
-&nbsp;</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997396"></A>
-zone &quot;example.com&quot; {            // Example zone for &quot;example.com&quot;.
-type master;                    // It's a master zone.
-file &quot;m/example.com.db&quot;;        // The file is here.
-allow-query { any; };           // Allow anyone to query.
-allow-transfer { corpnet; };    // Only allow corp nets to transfer zone.
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997402"></A>
-&nbsp;</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997403"></A>
-zone &quot;offsite.example.com&quot; {     // Example zone for an off-site corp zone.
-type slave;                      // It's a slave zone.
-masters { 192.168.4.12; };       // The master is at this address.
-file &quot;s/offsite.example.com.db&quot;; // The file is here.
-notify no;                       // Don't worry about <CODE CLASS="Program-Process">NOTIFY</CODE>
-ing.
-allow-query { any; };            // Allow anyone to query.
-;</PRE>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997410">
-</A>
+ </A>
 3.2	Load Balancing and Round Robin</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997411">
-</A>
+ </A>
 Primitive load balancing can be achieved in DNS using multiple A records for one name.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997412">
-</A>
+ </A>
 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 record like the following means that clients will connect to each machine one third of the time:</P>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997454"></A>
+<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997454"> </A>
 &nbsp;</PRE>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997415">
-</A>
+ </A>
 Name</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997417">
-</A>
+ </A>
 TTL</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997419">
-</A>
+ </A>
 CLASS</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997421">
-</A>
+ </A>
 TYPE</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997423">
-</A>
+ </A>
 Resource Record (RR) Data</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997425">
-</A>
-<CODE CLASS="Program-Process">
-www</CODE>
-</P>
+ </A>
+www</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997427">
-</A>
+ </A>
 10m</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997429">
-</A>
-<CODE CLASS="Program-Process">
-IN</CODE>
-</P>
+ </A>
+IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997431">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997433">
-</A>
+ </A>
 10.0.0.1</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG">
+<P CLASS="CellBody">
 <A NAME="pgfId=997435">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997437">
-</A>
+ </A>
 10m</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997439">
-</A>
-<CODE CLASS="Program-Process">
-IN</CODE>
-</P>
+ </A>
+IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997441">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997443">
-</A>
+ </A>
 10.0.0.2</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG">
+<P CLASS="CellBody">
 <A NAME="pgfId=997445">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997447">
-</A>
+ </A>
 10m</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997449">
-</A>
-<CODE CLASS="Program-Process">
-IN</CODE>
-</P>
+ </A>
+IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997451">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfontLG1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997453">
-</A>
+ </A>
 10.0.0.3</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997455">
-</A>
+ </A>
 When a resolver queries for these records, BIND will rotate them and respond to the query with the records in a different order. This is known as cyclic or round-robin ordering.In the example above, the first client will receive the records in the order 1,2,3; the second client will receive them in the order 2,3,1; and the third 3,1,2. Most clients will use the first record returned, and discard the rest.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997456">
-</A>
+ </A>
 For more detail on ordering responses, check the <CODE CLASS="Program-Process">
 rrset-order</CODE>
  substatement in the <CODE CLASS="Program-Process">
 options</CODE>
- statement in <A HREF="BV9ARM.5.html#22766" CLASS="XRef">
+ statement in <A HREF="Bv9ARM.5.html#22766" CLASS="XRef">
 RRset Ordering</A>
 .</P>
 </DIV>
@@ -274,54 +262,56 @@ RRset Ordering</A>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997460">
-</A>
+ </A>
 3.3	Notify</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997461">
-</A>
+ </A>
 DNS Notify is a mechanism that allows master nameservers to notify their slave servers of changes to a zone's data and that a query should be initiated to discover the new data. DNS Notify is turned on by default.</P>
 <P CLASS="2LevelContinued">
-<A NAME="pgfId=997462">
-</A>
+<A NAME="pgfId=1016466">
+ </A>
 DNS Notify is fully documented in RFC 1996. See also the description of the zone option <CODE CLASS="Program-Process">
 also-notify</CODE>
- in section 3.1.3.7, &quot;Zone transfers.&quot;</P>
+ on <A HREF="Bv9ARM.5.html#32057" CLASS="XRef">
+Zone Transfers</A>
+.</P>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
-<A NAME="pgfId=997463">
-</A>
+<A NAME="pgfId=1016467">
+ </A>
 3.4	Nameserver Operations</H3>
 </OL>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997464">
-</A>
+ </A>
 3.4.1	Tools for Use With the Nameserver Daemon</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997465">
-</A>
+ </A>
 There are several indispensable diagnostic, administrative and monitoring tools available to the system administrator for controlling and debugging the nameserver daemon. We describe several in this section </P>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997466">
-</A>
+ </A>
 3.4.1.1	Diagnostic Tools</H5>
 </OL>
 </DIV>
 <DIV>
 <H5 CLASS="Subhead4">
 <A NAME="pgfId=997467">
-</A>
+ </A>
 dig</H5>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997468">
-</A>
+ </A>
 The domain information groper (<CODE CLASS="Program-Process">
 dig</CODE>
 ) is a command line tool that can be used to gather information from the Domain Name System servers. Dig 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.</P>
@@ -329,30 +319,30 @@ dig</CODE>
 <DIV>
 <H5 CLASS="Subhead4">
 <A NAME="pgfId=997469">
-</A>
+ </A>
 Usage</H5>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997470"></A>
+<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997470"> </A>
 dig [@server] domain [&lt;query-type&gt;] [&lt;query-class&gt;]
 [+&lt;query-option&gt;] [-&lt;dig-option&gt;] [%comment]</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997471">
-</A>
+ </A>
 The usual simple use of dig will take the form</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997472"></A>
+<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997472"> </A>
 dig @server domain query-type query-class</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997473">
-</A>
+ </A>
 For more information and a list of available commands and options, see the dig man page.</P>
 </DIV>
 <DIV>
 <H5 CLASS="Subhead4">
 <A NAME="pgfId=997474">
-</A>
+ </A>
 host</H5>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997475">
-</A>
+ </A>
 The<EM CLASS="pathname">
  </EM>
 <CODE CLASS="Program-Process">
@@ -364,113 +354,114 @@ utility provides a simple DNS lookup using a command-line interface for looking
 <DIV>
 <H5 CLASS="Subhead4">
 <A NAME="pgfId=997476">
-</A>
+ </A>
 Usage</H5>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997477"></A>
+<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997477"> </A>
 host [-l] [-v] [-w] [-r] [-d] [-t querytype] [-a] host [server]</PRE>
 </DIV>
 <DIV>
 <H5 CLASS="Subhead4">
 <A NAME="pgfId=997478">
-</A>
+ </A>
 nslookup</H5>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997479">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 nslookup</CODE>
- is a program used to query Internet domain nameservers. nslookup has two modes: interactive and non-interactive. Interactive mode allows the user to query nameservers 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.</P>
+ is a program used to query Internet domain nameservers. <CODE CLASS="Program-Process">
+nslookup</CODE>
+ has two modes: interactive and non-interactive. Interactive mode allows the user to query nameservers 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.</P>
 </DIV>
 <DIV>
 <H5 CLASS="Subhead4">
 <A NAME="pgfId=997480">
-</A>
+ </A>
 Usage</H5>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997481"></A>
+<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997481"> </A>
 nslookup [-option ...] [host-to-find | -[server]]</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997482">
-</A>
+ </A>
 Interactive mode is entered when no arguments are given (the default nameserver will be used) or when the first argument is a hyphen (-) and the second argument is the host name or Internet address of a nameserver.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997483">
-</A>
+ </A>
 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 nameserver.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997484">
-</A>
-The options listed under the &quot;set&quot; command (see the nslookup man page for details) can be specified in the .nslookuprc file in the user's home directory if they are listed one per line. Options can also be specified on the command line if they precede the arguments and are prefixed with a hyphen. For example, to change the default query type to host information, and the initial time-out to 10 seconds, type:</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997485"></A>
+ </A>
+The options listed under the &quot;set&quot; command (see the <CODE CLASS="Program-Process">
+nslookup</CODE>
+ man page for details) can be specified in the <EM CLASS="pathname">
+.nslookuprc</EM>
+ file in the user's home directory if they are listed one per line. Options can also be specified on the command line if they precede the arguments and are prefixed with a hyphen. For example, to change the default query type to host information, and the initial time-out to 10 seconds, type:</P>
+<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997485"> </A>
 nslookup -query=hinfo -timeout=10</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997486">
-</A>
-For more information and a list of available commands and options, see the nslookup man page.</P>
+ </A>
+For more information and a list of available commands and options, see the <CODE CLASS="Program-Process">
+nslookup</CODE>
+ man page.</P>
 </DIV>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997487">
-</A>
+ </A>
 3.4.1.2	Administrative Tools</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997488">
-</A>
+ </A>
 Administrative tools play an integral part in the management of a server.</P>
 </DIV>
 <DIV>
 <H5 CLASS="Subhead4">
 <A NAME="pgfId=997489">
-</A>
+ </A>
 rndc</H5>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997490">
-</A>
+ </A>
 The remote name daemon control (<CODE CLASS="Program-Process">
 rndc</CODE>
 ) program is a program that allows the system administrator to control the operation of a nameserver. If you run rndc without any options it will display a usage message.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1012780">
-</A>
+ </A>
 Usage:</P>
-<P CLASS="4LevelContinued">
-<A NAME="pgfId=1012777">
-</A>
-<CODE CLASS="Program-Process">
-rndc [-p port] [-m] server command [command ...]</CODE>
-</P>
+<PRE CLASS="4Level-fixed"><A NAME="pgfId=1012777"> </A>
+<CODE CLASS="Program-Process">rndc [-p port] [-m] server command [command ...]</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997493">
-</A>
+ </A>
 For more information and a list of available commands and options, see the rndc man page.</P>
 </DIV>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997494">
-</A>
+ </A>
 3.4.1.3	Monitoring Tools</H5>
 </OL>
 </DIV>
 <DIV>
 <H5 CLASS="Subhead4">
 <A NAME="pgfId=997495">
-</A>
+ </A>
 MRTG</H5>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997496">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 MRTG</CODE>
  is primarily a router traffic grapher, but can be used to monitor BIND DNS servers, as well. The `stat' script, supplied with MRTG in the MRTG `contrib/stat' directory, can be used to monitor numbers of queries, and counts of various sorts of responses.</P>
-<P CLASS="Body">
-<A NAME="pgfId=997347">
-</A>
-&nbsp;</P>
 </DIV>
 </DIV>
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
 </DIV>
+<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> 
 </BODY>
 </HTML>
diff --git a/doc/arm/BV9ARM.4.html b/doc/arm/Bv9ARM.4.html
index 3f23152d..1f066128 100644..100755
--- a/doc/arm/BV9ARM.4.html
+++ b/doc/arm/Bv9ARM.4.html
@@ -2,29 +2,29 @@
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
 <TITLE> Section 4.	Advanced Concepts</TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
 <OL>
 <H1 CLASS="1Level">
 <A NAME="pgfId=997350">
-</A>
+ </A>
 Section 4.	Advanced Concepts</H1>
 </OL>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997351">
-</A>
+ </A>
 4.1	Dynamic Update</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997352">
-</A>
+ </A>
 Dynamic update is the term used for the ability under certain specified conditions to add, modify or delete records or RRsets in the master zone files. Dynamic update is fully described in RFC 2136.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997353">
-</A>
+ </A>
 Dynamic update is enabled on a zone-by-zone basis, by including an <CODE CLASS="Program-Process">
 allow-update</CODE>
  or <CODE CLASS="Program-Process">
@@ -34,40 +34,40 @@ zone</CODE>
  statement.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1008560">
-</A>
+ </A>
 Updating of secure zones (zones using DNSSEC) works as specified in the <EM CLASS="Emphasis">
 simple-secure-update</EM>
  proposal. SIG and NXT 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.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1008576">
-</A>
-The zone files of dynamic zones must not be edited by hand.  The zone file on disk at any given time may not contain the latest changes performed by dynamic update.  The zone file is written to disk only periodically, and changes that have occurred since the zone file was last written to disk are stored only in the zone's journal (<EM CLASS="pathname">
+ </A>
+The zone files of dynamic zones must not be edited by hand. The zone file on disk at any given time may not contain the latest changes performed by dynamic update. The zone file is written to disk only periodically, and changes that have occurred since the zone file was last written to disk are stored only in the zone's journal (<EM CLASS="pathname">
 .jnl</EM>
-) file.  BIND 9 currently does not update the zone file when it exits like BIND 8 does, so editing the zone file manually is unsafe even when the server has been shut down. </P>
+) file. BINDv9 currently does not update the zone file when it exits like BIND 8 does, so editing the zone file manually is unsafe even when the server has been shut down. </P>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997356">
-</A>
+ </A>
 4.2	<A NAME="19780">
-</A>
+ </A>
 Incremental Zone Transfers (IXFR)</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1008466">
-</A>
-The incremental zone transfer protocol (IXFR, RFC1995--see the list of Proposed Standards in the <A HREF="BV9ARM.8.html">Appendices
-</A>
+ </A>
+The incremental zone transfer protocol (IXFR, RFC1995--see the list of proposed standards on in Appendix C on <A HREF="Bv9ARM.7.html#17631" CLASS="XRef">
+Proposed Standards</A>
 ) is a way for slave servers to transfer only changed data, instead of having to transfer the entire zone every time it changes.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1008471">
-</A>
-When acting as a master, BIND 9 supports IXFR for those zones where the necessary change history information is available.  These include master zones maintained by dynamic update and slave zones whose data was obtained by IXFR, but not manually maintained master zones nor slave zones obtained by AXFR.</P>
+ </A>
+When acting as a master, BINDv9 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, but not manually maintained master zones nor slave zones obtained by AXFR.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1008502">
-</A>
-When acting as a slave, BIND 9 will attempt to use IXFR unless it is explicitly disabled.  For more information about disabling IXFR, see the description of the <CODE CLASS="Program-Process">
+ </A>
+When acting as a slave, BINDv9 will attempt to use IXFR unless it is explicitly disabled. For more information about disabling IXFR, see the description of the <CODE CLASS="Program-Process">
 request-ixfr</CODE>
  clause of the <CODE CLASS="Program-Process">
 server</CODE>
@@ -77,440 +77,480 @@ server</CODE>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997360">
-</A>
+ </A>
 4.3	Split DNS</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997361">
-</A>
-Setting up different views, or visibility, of DNS space to internal , as opposed to external, resolvers is usually referred to as a &quot;Split DNS&quot; or &quot;Split Brain DNS&quot; setup. There are several reasons an organization would want to set its DNS up this way.</P>
+ </A>
+Setting up different views, or visibility, of DNS space to internal, as opposed to external, resolvers is usually referred to as a &quot;Split DNS&quot; or &quot;Split Brain DNS&quot; setup. There are several reasons an organization would want to set its DNS up this way.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997362">
-</A>
-One common reason for setting up a DNS system this way is to hide &quot;internal&quot; DNS information from &quot;external&quot; 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 e-mail headers, for example) and most savvy &quot;attackers&quot; can find the information they need using  other means.</P>
+ </A>
+One common reason for setting up a DNS system this way is to hide &quot;internal&quot; DNS information from &quot;external&quot; 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 e-mail headers, for example) and most savvy &quot;attackers&quot; can find the information they need using other means.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997363">
-</A>
+ </A>
 Another common reason for setting up a Split DNS system is to allow internal networks that are behind filters or RFC1918 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.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997364">
-</A>
+ </A>
 Here is an example of a split DNS setup:</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997365">
-</A>
+ </A>
 Let's say a company named <EM CLASS="Emphasis">
 Example, Inc.</EM>
  (example.com) has several corporate sites that have an internal network with reserved IP space and an external DMZ (the demilitarized zone, or &quot;outside&quot; section of a network) that is available to the public.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997366">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 Example, Inc.</EM>
  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.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997367">
-</A>
+ </A>
 In order to accomplish this, the company will set up two sets of nameservers. One set will be on the inside network (in the reserved IP space) and the other set will be on bastion hosts, which are &quot;proxy&quot; hosts that can talk to both sides of its network, in the DMZ.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997368">
-</A>
-The internal servers will be configured to forward all queries, except queries for <EM CLASS="Emphasis">
+ </A>
+The internal servers will be configured to forward all queries, except queries for <EM CLASS="pathname">
 site1.example</EM>
-, <EM CLASS="Emphasis">
+, <EM CLASS="pathname">
 site2.example</EM>
-, <EM CLASS="Emphasis">
+, <EM CLASS="pathname">
 site1.example.com</EM>
-, and <EM CLASS="Emphasis">
+, and <EM CLASS="pathname">
 site2.example.com</EM>
-, to the servers in the DMZ. These internal servers will have complete sets of information for <EM CLASS="Emphasis">
+, to the servers in the DMZ. These internal servers will have complete sets of information for <EM CLASS="pathname">
 site1.example.com</EM>
-, <EM CLASS="Emphasis">
+, <EM CLASS="pathname">
 site2.example.com</EM>
 ,<EM CLASS="Emphasis">
- site1.internal</EM>
-, and <EM CLASS="Emphasis">
+ </EM>
+<EM CLASS="pathname">
+site1.internal</EM>
+, and <EM CLASS="pathname">
 site2.internal</EM>
 .</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997369">
-</A>
-To protect the <EM CLASS="Emphasis">
-site1.internal</EM>
+ </A>
+To protect the<EM CLASS="pathname">
+ site1.interna</EM>
+<EM CLASS="Emphasis">
+l</EM>
  and<EM CLASS="Emphasis">
- site2.internal</EM>
+ </EM>
+<EM CLASS="pathname">
+site2.internal</EM>
  domains, the internal nameservers must be configured to disallow all queries to these domains from any external hosts, including the bastion hosts.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997370">
-</A>
-The external servers, which are on the bastion hosts, will be configured to serve the &quot;public&quot; version of the <EM CLASS="Emphasis">
+ </A>
+The external servers, which are on the bastion hosts, will be configured to serve the &quot;public&quot; version of the <EM CLASS="pathname">
 site1</EM>
- and <EM CLASS="Emphasis">
+ and <EM CLASS="pathname">
 site2.example.com</EM>
- zones. This could include things such as the host records for public servers (<EM CLASS="Emphasis">
+ zones. This could include things such as the host records for public servers (<EM CLASS="pathname">
 www.example.com</EM>
-, <EM CLASS="Emphasis">
+, <EM CLASS="pathname">
 ftp.example.com</EM>
-), and mail exchanger records (<EM CLASS="Emphasis">
+), and mail exchanger records (<EM CLASS="pathname">
 a.mx.example.com</EM>
- and <EM CLASS="Emphasis">
+ and <EM CLASS="pathname">
 b.mx.example.com</EM>
 ).</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997371">
-</A>
-In addition, the public <EM CLASS="Emphasis">
+ </A>
+In addition, the public <EM CLASS="pathname">
 site1</EM>
- and <EM CLASS="Emphasis">
-site2 .example.com</EM>
- 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.</P>
+ and <EM CLASS="pathname">
+site2.example.com</EM>
+ zones should have special MX records that contain wildcard (&quot;*&quot;) 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.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997372">
-</A>
+ </A>
 Here's an example of a wildcard MX record:</P>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997373"></A>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997373"> </A>
 *   IN MX 10 external1.example.com.</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997374">
-</A>
+ </A>
 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 nameservers for DNS resolution.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997375">
-</A>
+ </A>
 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.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997376">
-</A>
+ </A>
 In order for all this to work properly, internal clients will need to be configured to query <EM CLASS="Emphasis">
 only</EM>
  the internal nameservers for DNS queries. This could also be enforced via selective filtering on the network.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997377">
-</A>
+ </A>
 If everything has been set properly, <EM CLASS="Emphasis">
 Example, Inc.</EM>
 's internal clients will now be able to:</P>
 <UL>
 <LI CLASS="2Level-bullet1">
 <A NAME="pgfId=997378">
-</A>
-Look up any hostnames in the <EM CLASS="Emphasis">
+ </A>
+Look up any hostnames in the <EM CLASS="pathname">
 site1</EM>
- and <EM CLASS="Emphasis">
-site2 .example.com</EM>
+ and <EM CLASS="pathname">
+site2.example.com</EM>
  zones.</LI>
 <LI CLASS="2Level-bullet2">
 <A NAME="pgfId=997379">
-</A>
-Look up any hostnames in the <EM CLASS="Emphasis">
+ </A>
+Look up any hostnames in the <EM CLASS="pathname">
 site1.internal</EM>
- and <EM CLASS="Emphasis">
+ and <EM CLASS="pathname">
 site2.internal</EM>
  domains.</LI>
 <LI CLASS="2Level-bullet2">
 <A NAME="pgfId=997380">
-</A>
+ </A>
 Look up any hostnames on the Internet.</LI>
 <LI CLASS="2Level-bullet2">
 <A NAME="pgfId=997381">
-</A>
+ </A>
 Exchange mail with internal AND external people.</LI>
 </UL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997382">
-</A>
+ </A>
 Hosts on the Internet will be able to:</P>
 <UL>
 <LI CLASS="2Level-bullet1">
 <A NAME="pgfId=997383">
-</A>
-Look up any hostnames in the <EM CLASS="Emphasis">
+ </A>
+Look up any hostnames in the <EM CLASS="pathname">
 site1</EM>
- and <EM CLASS="Emphasis">
-site2 .example.com </EM>
+ and <EM CLASS="pathname">
+site2.example.com </EM>
 zones.</LI>
 <LI CLASS="2Level-bullet2">
 <A NAME="pgfId=997384">
-</A>
-Exchange mail with anyone in the <EM CLASS="Emphasis">
+ </A>
+Exchange mail with anyone in the <EM CLASS="pathname">
 site1</EM>
- and <EM CLASS="Emphasis">
-site2 .example.com</EM>
+ and <EM CLASS="pathname">
+site2.example.com</EM>
  zones.</LI>
 </UL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997385">
-</A>
-Here is an example configuration for the setup we just described above. Note that this is only configuration information; see <A HREF="BV9ARM.3.html#30164" CLASS="XRef">
-Sample Configuration and Logging</A>
- for information on how to configure your zone files.</P>
+ </A>
+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 <A HREF="Bv9ARM.3.html#30164" CLASS="XRef">
+See Sample Configuration and Logging.</A>
+</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997389">
-</A>
+ </A>
 Internal DNS server config:</P>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997390"></A>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997390"> </A>
+
+<CODE>
 acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-acl externals { <EM CLASS="Emphasis">bastion-ips-go-here</EM>; };
+acl externals { bastion-ips-go-here; };
 options {
     ...
     ...
     forward only;
-    forwarders { <EM CLASS="Emphasis">bastion-ips-go-here</EM>; };  // forward to external servers
-    allow-transfer { none; };                    // sample allow-transfer (no one)
-    allow-query { internals; externals; };       // restrict query access
-    allow-recursion { internals; };              // restrict recursion
+    forwarders { <VAR>bastion-ips-go-here</VAR>; };			//forward to external servers
+    allow-transfer { <VAR>none</VAR>; };				// sample allow-transfer (no one)
+    allow-query { <VAR>internals</VAR>; <VAR>externals</VAR>; };			// restrict query access
+    allow-recursion { <VAR>internals</VAR>; };			// restrict recursion
     ...
     ...
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997402"></A>
-zone &quot;site1.example.com&quot; { // sample slave zone
-  type master;
-  file &quot;m/site1.example.com&quot;;
+};
+
+zone &quot;<EM>site1.example.com</EM>&quot; { // sample slave zone
+  type <VAR>master</VAR>;
+  file &quot;<EM>m/site1.example.com</EM>&quot;;
   forwarders { };          // do normal iterative resolution (do not forward)
-  allow-query { internals; externals; };
-  allow-transfer { internals; };
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997409"></A>
-zone &quot;site2.example.com&quot; {
-  type slave;
-  file &quot;s/site2.example.com&quot;;
+  allow-query { <VAR>internals</VAR>; <VAR>externals</VAR>; };
+  allow-transfer { <VAR>internals</VAR>; };
+};
+
+zone &quot;<EM>site2.example.com</EM>&quot; {
+  type <VAR>slave</VAR>;
+  file &quot;<EM>s/site2.example.com</EM>&quot;;
   masters { 172.16.72.3; };
   forwarders { };
-  allow-query { internals; externals; };
-  allow-transfer { internals; };
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997417"></A>
-zone &quot;site1.internal&quot; {
-  type master;
-  file &quot;m/site1.internal&quot;;
+  allow-query { <VAR>internals</VAR>; <VAR>externals</VAR>; };
+  allow-transfer { <VAR>internals</VAR>; };
+};
+
+zone &quot;<EM>site1.internal</EM>&quot; {
+  type <VAR>master</VAR>;
+  file &quot;<EM>m/site1.internal</EM>&quot;;
   forwarders { };
-  allow-query { internals; };
-  allow-transfer { internals; }
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997424"></A>
-zone &quot;site2.internal&quot; {
-  type slave;
-  file &quot;s/site2.internal&quot;;
+  allow-query { <VAR>internals</VAR>; };
+  allow-transfer { <VAR>internals</VAR>; }
+};
+
+zone &quot;<EM>site2.internal</EM>&quot; {
+  type <VAR>slave</VAR>;
+  file &quot;<EM>s/site2.internal</EM>&quot;;
   masters { 172.16.72.3; };
   forwarders { };
-  allow-query { internals };
-  allow-transfer { internals; }
-};</PRE>
-<P CLASS="2LevelContinued">
-<A NAME="pgfId=997431">
-</A>
-External (bastion host) DNS server config:</P>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997432"></A>
+  allow-query { <VAR>internals</VAR> };
+  allow-transfer { <VAR>internals</VAR>; }
+};
+</CODE>
+
+External (bastion host) DNS server config:
+ 
+<CODE>
 acl internals { 172.16.72.0/24; 192.168.1.0/24; };
-acl externals { <EM CLASS="Emphasis">bastion-ips-go-here</EM>; };
+acl externals { bastion-ips-go-here; };
 options {
   ...
   ...
-  allow-transfer { none; };                  // sample allow-transfer (no one)
-  allow-query { internals; externals; };     // restrict query access
-  allow-recursion { internals; externals; }; // restrict recursion
+  allow-transfer { <VAR>none</VAR>; };                  // sample allow-transfer (no one)
+  allow-query { <VAR>internals</VAR>; <VAR>externals</VAR>; };     // restrict query access
+  allow-recursion { <VAR>internals</VAR>; <VAR>externals</VAR>; }; // restrict recursion
   ...
   ...
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997443"></A>
-zone &quot;site1.example.com&quot; {        // sample slave zone
-  type master;
-  file &quot;m/site1.foo.com&quot;;
-  allow-query { any; };
-  allow-transfer { internals; externals; };
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997449"></A>
-zone &quot;site2.example.com&quot; {
-  type slave;
-  file &quot;s/site2.foo.com&quot;;
-  masters { another_bastion_host_maybe; };
-  allow-query { any; };
-  allow-transfer { internals; externals; }
-};</PRE>
-<P CLASS="2LevelContinued">
-<A NAME="pgfId=997456">
-</A>
-In the <EM CLASS="pathname">
-resolv.conf</EM>
- (or equivalent) on the bastion host(s):</P>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997457"></A>
-search ...
+};
+
+zone &quot;<EM>site1.example.com</EM>&quot; {        // sample slave zone
+  type <VAR>master</VAR>;
+  file &quot;<EM>m/site1.foo.com</EM>&quot;;
+  allow-query { <VAR>any</VAR>; };
+  allow-transfer { <VAR>internals</VAR>; <VAR>externals</VAR>; };
+};
+
+zone &quot;<EM>site2.example.com</EM>&quot; {
+  type <VAR>slave</VAR>;
+  file &quot;<EM>s/site2.foo.com</EM>&quot;;
+  masters { a<VAR>nother_bastion_host_maybe</VAR>; };
+  allow-query { <VAR>any</VAR>; };
+  allow-transfer { <VAR>internal</VAR>; <VAR>externals</VAR>; }
+};
+</CODE>
+
+In the <EM>resolv.conf</EM> (or equivalent) on the bastion host(s):
+ 
+<CODE>search ...
 nameserver 172.16.72.2
 nameserver 172.16.72.3
-nameserver 172.16.72.4</PRE>
+nameserver 172.16.72.4</CODE>
+</PRE>
+
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997461">
-</A>
+ </A>
 4.4	TSIG</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997462">
-</A>
-Information about TSIG in this section was provided by Brian Wellington of TISLabs. This is a short guide to setting up TSIG based transaction security in BIND. It describes changes to the configuration file as well as what changes are required for different features, including the process of creating transaction keys and using transaction signatures with BIND.</P>
+ </A>
+This is a short guide to setting up TSIG based transaction security in BIND. It describes changes to the configuration file as well as what changes are required for different features, including the process of creating transaction keys and using transaction signatures with BIND.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997463">
-</A>
+ </A>
 BIND primarily supports TSIG for server-server communication. This includes zone transfer, notify, and recursive query messages. The resolver bundled with BIND 8.2 has limited support for TSIG, but it is doubtful that support will be integrated into any client applications.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997464">
-</A>
+ </A>
 TSIG might be most useful for dynamic update. A primary server for a dynamic zone should use access control to control updates, but IP-based access control is insufficient. Key-based access control is far superior (see <EM CLASS="pathname">
 draft-ietf-dnsext-simple-secure-update-00.txt</EM>
- in<EM CLASS="pathname">
- </EM>
-<A HREF="BV9ARM.8.html#" CLASS="XRef">
-Internet Drafts</A>
+ in Appendix C on <A HREF="Bv9ARM.7.html#42144" CLASS="XRef">
+Request for Comments (RFCs)</A>
 ). The <CODE CLASS="Program-Process">
 nsupdate</CODE>
- program that is shipped with BIND 8 supports TSIG via the &quot;<CODE CLASS="Program-Process">
+ program that is shipped with BIND 8 supports TSIG via the<BR>
+&quot;<CODE CLASS="Program-Process">
 -k</CODE>
 &quot; command line option.</P>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997465">
-</A>
+ </A>
 4.4.1	Generate Shared Keys for Each Pair of Hosts</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997466">
-</A>
+ </A>
 A shared secret is generated to be shared between host1 and host2. The key name is chosen to be &quot;host1-host2.&quot;, which is arbitrary. The key name must be the same on both hosts.</P>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997467">
-</A>
+ </A>
 4.4.1.1	Automatic Generation</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997468">
-</A>
+ </A>
 The following command will generate a 128 bit (16 byte) HMAC-MD5 key as described above. Longer keys are better, but shorter keys are easier to read. Note that the maximum key length is 512 bits; keys longer than that will be digested with MD5 to produce a 128 bit key.</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997469"></A>
+
+<PRE CLASS="4Level-fixed"><A NAME="pgfId=997469"></A>
 src/bin/dnskeygen/dnskeygen -H 128 -h -n host1-host2.</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997470">
-</A>
+ </A>
 The key is in the file &quot;Khost1-host2.+157+00000.private&quot;. Nothing actually uses this file, but the base64 encoded string following &quot;Key:&quot; can be extracted:</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997471"></A>
+<PRE CLASS="4Level-fixed"><A NAME="pgfId=997471"></A>
    La/E5CjG9O+os1jq0a2jdA==</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997472">
-</A>
+ </A>
 This string represents a shared secret.</P>
 </DIV>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997473">
-</A>
+ </A>
 4.4.1.2	Manual Generation</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997474">
-</A>
+ </A>
 The shared secret is simply a random sequence of bits, encoded in base64. Most ASCII strings are valid base64 strings (assuming the length is a multiple of 4 and only valid characters are used), so the shared secret can be manually generated.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997475">
-</A>
-Also, a known string can be run through mmencode or a similar program to generate base64 encoded data.</P>
+ </A>
+Also, a known string can be run through <CODE CLASS="Program-Process">
+mmencode</CODE>
+ or a similar program to generate base64 encoded data.</P>
 </DIV>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997476">
-</A>
+ </A>
 4.4.2	Copying the Shared Secret to Both Machines</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997477">
-</A>
+ </A>
 This is beyond the scope of DNS. A secure transport mechanism should be used. This could be secure FTP, ssh, telephone, etc.</P>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997478">
-</A>
+ </A>
 4.4.3	Informing the Servers of the Key's Existence</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997479">
-</A>
-Imagine host1 and host 2 are both servers. The following is added to each server's named.conf file:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997480"></A>
+ </A>
+Imagine <EM CLASS="Emphasis">
+host1</EM>
+ and <EM CLASS="Emphasis">
+host 2</EM>
+ are both servers. The following is added to each server's <CODE CLASS="Program-Process">
+named.conf</CODE>
+ file:</P>
+
+<PRE>
+<CODE> 
 key host1-host2. {
   algorithm hmac-md5;
   secret &quot;La/E5CjG9O+os1jq0a2jdA==&quot;;
-};</PRE>
+};
+</CODE>
+</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997484">
-</A>
+ </A>
 The algorithm, hmac-md5, is the only one supported by BIND. The secret is the one generated above. Since this is a secret, it is recommended that either <CODE CLASS="Program-Process">
 named.conf</CODE>
  be non-world readable, or the key directive be added to a non-world readable file that's included by named.conf.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997485">
-</A>
+ </A>
 At this point, the key is recognized. This means that if the server receives a message signed by this key, it can verify the signature. If the signature succeeds, the response is signed by the same key.</P>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997486">
-</A>
+ </A>
 4.4.4	Instructing the Server to Use the Key</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997487">
-</A>
-Since keys are shared between two hosts only, the server must be told when keys are to be used. The following is added to host1's named.conf file, if host2's IP address is 10.1.2.3:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997488"></A>
+ </A>
+Since keys are shared between two hosts only, the server must be told when keys are to be used. The following is added to the <CODE CLASS="Program-Process">
+named.conf</CODE>
+ file for <EM CLASS="Emphasis">
+host1</EM>
+, if the IP address of <EM CLASS="Emphasis">
+host2</EM>
+ is 10.1.2.3:</P>
+ 
+<PRE>
+<CODE>
 server 10.1.2.3 {
   keys {host1-host2.;};
-};</PRE>
+};</CODE>
+</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997491">
-</A>
+ </A>
 Multiple keys may be present, but only the first is used. This directive does not contain any secrets, so it may be in a world-readable file.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997492">
-</A>
+ </A>
 If host1 sends a message that is a response to that address, the message will be signed with the specified key. host1 will expect any responses to signed messages to be signed with the same key.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997493">
-</A>
+ </A>
 A similar statement must be present in host2's configuration file (with host1's address) for host2 to sign non-response messages to host1.</P>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997494">
-</A>
+ </A>
 4.4.5	TSIG Key Based Access Control</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997495">
-</A>
+ </A>
 BIND allows IP addresses and ranges to be specified in ACL definitions and <CODE CLASS="Program-Process">
-allow-{query|transfer|update}</CODE>
+allow-{ query </CODE>
+<EM CLASS="Optional-meta-syntax">
+| </EM>
+<CODE CLASS="Program-Process">
+transfer </CODE>
+<EM CLASS="Optional-meta-syntax">
+| </EM>
+<CODE CLASS="Program-Process">
+update }</CODE>
  directives. This has been extended to allow TSIG keys also. The above key would be denoted <CODE CLASS="Program-Process">
 key host1-host2</CODE>
 .</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997496">
-</A>
+ </A>
 An example of an allow-update directive would be:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997497"></A>
-allow-update {key host1-host2.;};</PRE>
+
+ 
+<PRE>
+<CODE>allow-update {key host1-host2.;};
+</CODE>
+</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997498">
-</A>
+ </A>
 This allows dynamic updates to succeed only if the request was signed by a key named &quot;<CODE CLASS="Program-Process">
 host1-host2.</CODE>
 &quot;</P>
@@ -519,26 +559,30 @@ host1-host2.</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997499">
-</A>
+ </A>
 4.4.6	Errors</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997500">
-</A>
+ </A>
 The processing of TSIG signed messages can result in several errors. If a signed message is sent to a non-TSIG aware server, a FORMERR will be returned, since the server will not understand the record. This is a result of misconfiguration, since the server must be explicitly configured to send a TSIG signed message to a specific server.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997501">
-</A>
+ </A>
 If a TSIG aware server receives a message signed by an unknown key, the response will be unsigned with the TSIG extended error code set to BADKEY. If a TSIG aware server receives a message with a signature that does not validate, the response will be unsigned with the TSIG extended error code set to BADSIG. If a TSIG aware server receives a message with a time outside of the allowed range, the response will be signed with the TSIG extended error code set to BADTIME, and the time values will be adjusted so that the response can be successfully verified. In any of these cases, the message's rcode is set to NOTAUTH.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997502">
-</A>
+ </A>
 TSIG verification errors are logged by the server as</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997503"></A>
-&quot;ns_req: TSIG verify failed - (reason)&quot; </PRE>
+
+<PRE>
+<CODE>
+&quot;ns_req: TSIG verify failed - (reason)&quot;
+</CODE> 
+</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997504">
-</A>
+ </A>
 which is printed at debug level 1.</P>
 </DIV>
 </DIV>
@@ -546,226 +590,325 @@ which is printed at debug level 1.</P>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997505">
-</A>
-4.5	DNSSEC</H3>
+ </A>
+4.5	TKEY</H3>
 </OL>
 <P CLASS="2LevelContinued">
-<A NAME="pgfId=997506">
-</A>
-Cryptographc authentication of DNS information is made possible through the DNS Security (DNSSEC) extension to the domain system. This describes the processing of creating and using DNSSEC signed zones. The zones used in this exercise will be <CODE CLASS="Program-Process">
-dnssec.example</CODE>
- and <CODE CLASS="Program-Process">
-sub.dnssec.example</CODE>
-.</P>
-<UL>
-<LI CLASS="Subhead2-noBullet">
-<A NAME="pgfId=997507">
-</A>
-Step 1: Generate zone keys.</LI>
-</UL>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997508">
-</A>
-The following commands generate 640 bit DSA keys to be used as zone keys for the zones:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997509"></A>
-src/bin/dnskeygen/dnskeygen -D 640 -z -n dnssec.example.
-src/bin/dnskeygen/dnskeygen -D 640 -z -n sub.dnssec.example.</PRE>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997511">
-</A>
-In our example, keys with id 64555 and 39020 were generated.</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997512">
-</A>
-Four files were created on disk:</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=1007504">
-</A>
-<CODE CLASS="Program-Process">
-Kdnssec.example.+003+64555.key</CODE>
- (public key)</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=1007508">
-</A>
-<CODE CLASS="Program-Process">
-Kdnssec.example.+003+64555.private</CODE>
- (private key)</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=1007505">
-</A>
+<A NAME="pgfId=1021941">
+ </A>
 <CODE CLASS="Program-Process">
-Ksub.dnssec.example.+003+39020.key</CODE>
- (public key)</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997516">
-</A>
-<CODE CLASS="Program-Process">
-Ksub.dnssec.example.+003+39020.private</CODE>
- (private key)</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997517">
-</A>
+TKEY</CODE>
+ is a mechanism for automatically generating a shared secret between two hosts.  There are several &quot;modes&quot; of <CODE CLASS="Program-Process">
+TKEY</CODE>
+ that specify how the key is generated or assigned.  BIND implements only one of these modes, the Diffie-Hellman key exchange.  Both hosts are required to have a Diffie-Hellman KEY record (although this record is not required to be present in a zone).  The <CODE CLASS="Program-Process">
+TKEY</CODE>
+ process must use signed messages, signed either by TSIG or SIG(0).  The result of <CODE CLASS="Program-Process">
+TKEY</CODE>
+ is a shared secret that can be used to sign messages with TSIG.  <CODE CLASS="Program-Process">
+TKEY</CODE>
+ can also be used to delete shared secrets that it had previously generated.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1021952">
+ </A>
 The <CODE CLASS="Program-Process">
-.key</CODE>
- files contain public keys in DNS RR format, which is base 64. The <CODE CLASS="Program-Process">
-.private</CODE>
- files contain private keys, with each field encoded in base 64.</P>
-<UL>
-<LI CLASS="Subhead2-noBullet">
-<A NAME="pgfId=997518">
-</A>
-Step 2: Enter the keys into the zones.</LI>
-</UL>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997519">
-</A>
-The parent zone needs its own key and the child key (as glue). The child zone needs its own key.</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997520"></A>
-cat Kdnssec.example.+003+64555.key &gt;&gt; zone.dnssec.example
-cat Ksub.dnssec.example.+003+39020.key &gt;&gt; zone.dnssec.example
-cat Ksub.dnssec.example.+003+39020.key &gt;&gt; zone.sub.dnssec.example</PRE>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997523">
-</A>
-Edit the zone files if desired (to move and/or format KEY records, etc.). This is also a good time to add <CODE CLASS="Program-Process">
-$ORIGIN</CODE>
- directives to the zone files if they aren't present.</P>
-<UL>
-<LI CLASS="Subhead2-noBullet">
-<A NAME="pgfId=997524">
-</A>
-Step 3: Sign the parent zone.</LI>
-</UL>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997525">
-</A>
-The following command uses the zone.dnssec.example as input and creates the zone.dnssec.example.signed file. The key used is the dsa key for dnssec.example with id 64555 (<CODE CLASS="Program-Process">
--ki</CODE>
-), and statistics are printed (<CODE CLASS="Program-Process">
--st</CODE>
-). Parent files are generated for each child zone (<CODE CLASS="Program-Process">
--ps</CODE>
-), and no global parent file is produced (<CODE CLASS="Program-Process">
--no-p1</CODE>
-).</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997526"></A>
-contrib/dns_signer/signer/dnssigner -zi zone.dnssec.example \
--zo zone.dnssec.example.signed -st -k1 dnssec.example dsa 64555 -ps
--no-p1</PRE>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997528">
-</A>
-The following files are created:</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997529">
-</A>
-<CODE CLASS="Program-Process">
-zone.dnssec.example.signed</CODE>
- (signed zone)</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997530">
-</A>
-<CODE CLASS="Program-Process">
-sub.dnssec.example..PARENT</CODE>
- (parent file for sub.dnssec.example)</P>
-<UL>
-<LI CLASS="Subhead2-noBullet">
-<A NAME="pgfId=997531">
-</A>
-Step 4: Sign the child zone.</LI>
-</UL>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997532">
-</A>
-The following command is similar to the previous one. The main difference is that the input parent file sub.dnssec.example..PARENT is specified (<CODE CLASS="Program-Process">
--pi</CODE>
-) in addition to the input zone file; this file was generated by the previous call to the signer. Also, the -ps and -no-p1 options are omitted since there are no child zones of this zone. If this zone had child zones, these options should be present.</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997533"></A>
-contrib/dns_signer/signer/<CODE CLASS="Program-Process">dnssigner</CODE>
- -zi zone.sub.dnssec.example \
--pi sub.dnssec.example..PARENT -zo zone.sub.dnssec.example.signed \
--st -k1 sub.dnssec.example dsa 39020</PRE>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997534">
-</A>
-The following file is created:</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997535">
-</A>
-<CODE CLASS="Program-Process">
-zone.sub.dnssec.example.signed</CODE>
- (signed zone)</P>
-<UL>
-<LI CLASS="Subhead2-noBullet">
-<A NAME="pgfId=997536">
-</A>
-Step 5: Enter the top-level zone key in the named.conf file for the master server.</LI>
-</UL>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997537">
-</A>
-The public key for the top-level signed zone must be present in named.conf, so that the server can verify the data on load (it must be able to traverse a keychain and end at a trusted key). This key is added in a zone pubkey directive (which has a format similar to a KEY record, but not identical). Note that this is not needed for the subzone, as its key is signed by the trusted key in the parent zone.</P>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997538">
-</A>
-This uses the key from Kdnssec.example.+003+64555.key</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997539"></A>
-zone &quot;dnssec.example&quot; {
-type master;
-file &quot;zone.dnssec.example.signed&quot;;
-pubkey 16641 3 3 &quot;AuNiWOmzSHwrzLMWv1C1gbKQBNAHwMeX+C0owQkfmdxjoTJvnmbN
-       CdbGM/fnejQhEXsRT5l3NLy0H4UCX3ElGJT49n3nFb2jPuDYbkPh
-       VV4sLfLJzQs/RWeQmQnNFF2HNmwksWlPvUT66k4mqJDtIk60Dio6
-       1PML5sVDMQns7Zukq4aSn4jzRGkbDGhB9S3yzXVMVjYDwlM9frW9
-       Ayt0vqDa0zG+V52YiCSOdFGWJ0bSFa8sTwcp4BEVUt/Kg2Zo4VAy
-       +AeYLcQLb6vDZUX8x/BPByKKptfXirhNPv43xE6vT4xCxYPhvyDk
-       Y7Qlf4W+/sSNNKE7P/JAKmQxxXAVPoXtBpa6&quot;;
-};</PRE>
-<UL>
-<LI CLASS="Subhead2-noBullet">
-<A NAME="pgfId=997550">
-</A>
-Step 6: Enter the top-level zone key in the named.conf file for any other servers that will trust the key.</LI>
-</UL>
-<P CLASS="3LevelContinued">
-<A NAME="pgfId=997551">
-</A>
-This uses the same key as above.</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997552"></A>
-trusted-keys {
-		dnssec.example 16641 3 3
-       &quot;AuNiWOmzSHwrzLMWv1C1gbKQBNAHwMeX+C0owQkfmdxjoTJvnmbN
-       CdbGM/fnejQhEXsRT5l3NLy0H4UCX3ElGJT49n3nFb2jPuDYbkPh
-       VV4sLfLJzQs/RWeQmQnNFF2HNmwksWlPvUT66k4mqJDtIk60Dio6
-       1PML5sVDMQns7Zukq4aSn4jzRGkbDGhB9S3yzXVMVjYDwlM9frW9
-       Ayt0vqDa0zG+V52YiCSOdFGWJ0bSFa8sTwcp4BEVUt/Kg2Zo4VAy
-       +AeYLcQLb6vDZUX8x/BPByKKptfXirhNPv43xE6vT4xCxYPhvyDk
-       Y7Qlf4W+/sSNNKE7P/JAKmQxxXAVPoXtBpa6&quot;;
-}</PRE>
-<UL>
-<LI CLASS="Subhead2-noBullet">
-<A NAME="pgfId=997562">
-</A>
-Start named.</LI>
-</UL>
+TKEY</CODE>
+ process is initiated by a client or server by sending a signed <CODE CLASS="Program-Process">
+TKEY</CODE>
+ query (including any appropriate KEYs) to a TKEY-aware server.  The server response, if it indicates success, will contain a <CODE CLASS="Program-Process">
+TKEY</CODE>
+ record and any appropriate keys.  After this exchange, both participants have enough information to determine the shared secret; the exact process depends on the <CODE CLASS="Program-Process">
+TKEY</CODE>
+ mode.  When using the Diffie-Hellman <CODE CLASS="Program-Process">
+TKEY</CODE>
+ mode, Diffie-Hellman keys are exchanged, and the shared secret is derived by both participants.</P>
+</DIV>
+<DIV>
+<OL>
+<H3 CLASS="2Level">
+<A NAME="pgfId=1021928">
+ </A>
+4.6	DNSSEC Secured Zones</H3>
+</OL>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039857">
+ </A>
+Cryptographic authentication of DNS information is made possible through the DNS Security (<EM CLASS="Emphasis">
+DNSSEC</EM>
+) extension to the domain system. This describes the processing of creating and using DNSSEC signed zones.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039810">
+ </A>
+In order to set up a DNSSEC secure zone, there are a series of steps which must be followed.  BINDv9 ships with several tools that are used in this process, which are explained in more detail below.  In all cases, the &quot;<CODE CLASS="Program-Process">
+-h</CODE>
+&quot; option prints a full list of parameters.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039811">
+ </A>
+There must also be communication with the administrators of the parent and/or child zone to transmit keys and signatures.  A zone's security status must be indicated by the parent zone for a DNSSEC capable resolver to trust its data.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039812">
+ </A>
+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.</P>
+<DIV>
+<OL>
+<H4 CLASS="3Level">
+<A NAME="pgfId=1039813">
+ </A>
+4.6.1	Generating Keys</H4>
+</OL>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039814">
+ </A>
+The <CODE CLASS="Program-Process">
+dnssec-keygen</CODE>
+ program is used to generate keys.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039815">
+ </A>
+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 <CODE CLASS="Program-Process">
+ZONE</CODE>
+, and must be usable for authentication.  It is recommended that zone keys be mandatory to implement a cryptographic algorithm; currently the only key mandatory to implement an algorithm is DSA.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039816">
+ </A>
+The following command will generate a 768 bit DSA key for the <EM CLASS="pathname">
+child.example</EM>
+ zone:</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039817">
+ </A>
+<EM CLASS="grammar_literal">
+dnssec-keygen</EM>
+ <EM CLASS="grammar_literal">
+-a</EM>
+ <EM CLASS="variable">
+DSA</EM>
+ <EM CLASS="grammar_literal">
+-b</EM>
+ <EM CLASS="variable">
+768</EM>
+ <EM CLASS="grammar_literal">
+-n</EM>
+ <EM CLASS="variable">
+ZONE</EM>
+ <EM CLASS="pathname">
+child.example</EM>
+.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039818">
+ </A>
+Two output files will be produced: <EM CLASS="pathname">
+Kchild.example.+003+12345.key</EM>
+ and <EM CLASS="pathname">
+Kchild.example.+003+12345.private</EM>
+ (where 12345 is an example of a key identifier).  The key file names contain the key name (<EM CLASS="pathname">
+child.example</EM>
+), algorithm (3 is DSA, 1 is RSA, etc.), and the key identifier (12345 in this case).  The private key (in the <EM CLASS="pathname">
+.private</EM>
+ file) is used to generate signatures, and the public key (in the <EM CLASS="pathname">
+.key</EM>
+ file) is used for signature verification.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039819">
+ </A>
+To generate another key with the same properties, repeat the above command.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039820">
+ </A>
+The public keys should be inserted into the zone file with $<CODE CLASS="Program-Process">
+INCLUDE</CODE>
+ statements.</P>
+</DIV>
+<DIV>
+<OL>
+<H4 CLASS="3Level">
+<A NAME="pgfId=1039821">
+ </A>
+4.6.2	Creating a Keyset</H4>
+</OL>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039822">
+ </A>
+The <CODE CLASS="Program-Process">
+dnssec-makekeyset</CODE>
+ program is used to create a key set from one or more keys.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039823">
+ </A>
+Once the zone keys have been generated, a key set must be built for transmission to the administrator of the parent zone, so that the parent zone can sign the keys with its own zone key and correctly indicate the security status of this zone.  When building a key set, the list of keys to be included and the TTL of the set must be specified, and the desired signature validity period of the parent's signature may also be specified.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039824">
+ </A>
+The list of keys to be inserted into the key set may also included non-zone keys present at the apex.  <CODE CLASS="Program-Process">
+dnssec-makekeyset</CODE>
+ may also be used at non-apex names.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039825">
+ </A>
+The following command generates a key set containing the above key and another key similarly generated, with a TTL of 3600 and a signature validity period of 10 days starting from now.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039826">
+ </A>
+<EM CLASS="grammar_literal">
+dnssec-makekeyset</EM>
+ <EM CLASS="grammar_literal">
+-t</EM>
+ <EM CLASS="variable">
+3600</EM>
+ <EM CLASS="grammar_literal">
+-s</EM>
+ <EM CLASS="variable">
+now</EM>
+ <EM CLASS="grammar_literal">
+-e</EM>
+ <EM CLASS="variable">
+now+864000</EM>
+ <EM CLASS="pathname">
+Kchild.example.+003+12345</EM>
+<EM CLASS="Optional-meta-syntax">
+ \</EM>
+ <EM CLASS="pathname">
+Kchild.example.+003+23456</EM>
+</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039827">
+ </A>
+One output file is produced: <EM CLASS="pathname">
+child.example.keyset</EM>
+.  This file should be transmitted to the parent to be signed.  It includes the keys, as well as signatures over the key set generated by the zone keys themselves, which are used to prove ownership of the private keys and encode the desired validity period.</P>
+</DIV>
+<DIV>
+<OL>
+<H4 CLASS="3Level">
+<A NAME="pgfId=1039828">
+ </A>
+4.6.3	Signing the Child's Keyset</H4>
+</OL>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039829">
+ </A>
+The <CODE CLASS="Program-Process">
+dnssec-signkey</CODE>
+ program is used to sign one child's keyset.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039830">
+ </A>
+If the <EM CLASS="pathname">
+child.example</EM>
+ zone has any delegations which are secure, for example, <EM CLASS="pathname">
+grand.child.example</EM>
+, the <EM CLASS="pathname">
+child.example</EM>
+ administrator should receive keyset files for each secure subzone.  These keys must be signed by this zone's zone keys.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039831">
+ </A>
+The following command signs the child's key set with the zone keys:</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039832">
+ </A>
+<EM CLASS="grammar_literal">
+dnssec-signkey</EM>
+ <EM CLASS="pathname">
+grand.child.example.keyset</EM>
+ <EM CLASS="pathname">
+Kchild.example.+003+12345 </EM>
+<EM CLASS="Optional-meta-syntax">
+\ </EM>
+<EM CLASS="pathname">
+Kchild.example.+003+23456</EM>
+</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039833">
+ </A>
+One output file is produced: <EM CLASS="pathname">
+grand.child.example.signedkey</EM>
+. This file should be both transmitted back to the child and retained.  It includes all keys (the child's keys) from the keyset file and signatures generated by this zone's zone keys.</P>
+</DIV>
+<DIV>
+<OL>
+<H4 CLASS="3Level">
+<A NAME="pgfId=1040038">
+ </A>
+4.6.4	Signing the Zone</H4>
+</OL>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1040039">
+ </A>
+The <CODE CLASS="Program-Process">
+dnssec-signzone</CODE>
+ program is used to sign a zone.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1040040">
+ </A>
+Any <EM CLASS="pathname">
+signedkey</EM>
+ files corresponding to secure subzones should be present, as well as a <EM CLASS="pathname">
+signedkey</EM>
+ file for this zone generated by the parent (if there is one). The zone signer will generate <CODE CLASS="Program-Process">
+NXT</CODE>
+ and <CODE CLASS="Program-Process">
+SIG</CODE>
+ records for the zone, as well as incorporate the zone key signature from the parent and indicate the security status at all delegation points.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039837">
+ </A>
+The following command signs the zone, assuming it is in a file called <EM CLASS="pathname">
+zone.child.example</EM>
+.  By default, all zone keys which have an available private key are used to generate signatures.:</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039838">
+ </A>
+<EM CLASS="grammar_literal">
+dnssec-signzone</EM>
+ <EM CLASS="grammar_literal">
+-o</EM>
+ <EM CLASS="pathname">
+child.example zone.child.example</EM>
+</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039839">
+ </A>
+One output file is produced: <EM CLASS="pathname">
+zone.child.example.signed</EM>
+. This file should be referenced by <CODE CLASS="Program-Process">
+named.conf</CODE>
+ as the input file for the zone.</P>
+</DIV>
+<DIV>
+<OL>
+<H4 CLASS="3Level">
+<A NAME="pgfId=1039840">
+ </A>
+4.6.5	Configuring Servers</H4>
+</OL>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039841">
+ </A>
+Unlike in BIND 8, data is not verified on load in BINDv9, so zone keys for authoritative zones do not need to be specified in the configuration file.</P>
+<P CLASS="2LevelContinued">
+<A NAME="pgfId=1039842">
+ </A>
+The public key for any security root must be present in the configuration file's trusted-keys statement, as described later in this document. </P>
+</DIV>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997563">
-</A>
-4.6	IPv6</H3>
+ </A>
+4.7	IPv6</H3>
 </OL>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997564">
-</A>
-4.6.1	IPv6 addresses (A6)</H4>
+ </A>
+4.7.1	IPv6 addresses (A6)</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997565">
-</A>
+ </A>
 IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces which were introduced in the DNS to facilitate scalable Internet routing. There are three types of addresses: <EM CLASS="Emphasis">
 Unicast</EM>
 , an identifier for a single interface; <EM CLASS="Emphasis">
@@ -775,208 +918,208 @@ Multicast</EM>
 , an identifier for a set of interfaces. Here we describe the global Unicast address scheme. For more information, see RFC 2374.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997566">
-</A>
+ </A>
 The aggregatable global Unicast address format is as follows:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997628">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997569">
-</A>
+ </A>
 3</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997571">
-</A>
+ </A>
 13</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997573">
-</A>
+ </A>
 8</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997575">
-</A>
+ </A>
 24</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997577">
-</A>
+ </A>
 16</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997579">
-</A>
+ </A>
 64 bits</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997581">
-</A>
+ </A>
 FP</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997583">
-</A>
+ </A>
 TLA ID</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997585">
-</A>
+ </A>
 RES</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997587">
-</A>
+ </A>
 NLA ID</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997589">
-</A>
+ </A>
 SLA ID</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997591">
-</A>
+ </A>
 Interface ID</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="4">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997593">
-</A>
-&lt;------- Public Topology -------&gt;</P>
+ </A>
+&lt;------ Public Topology ------&gt;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997601">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997603">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997605">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997607">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997609">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997611">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997613">
-</A>
-&lt;--Site Topology--&gt;</P>
+ </A>
+&lt;-Site Topology-&gt;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997615">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997617">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997619">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997621">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997623">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997625">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=997627">
-</A>
+ </A>
 &lt;------ Interface Identifier ------&gt;</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997666">
-</A>
+ </A>
 Where</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997631">
-</A>
+ </A>
 FP</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997633">
-</A>
+ </A>
 =</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997635">
-</A>
+ </A>
 Format Prefix (001)</P>
 </TD>
 </TR>
@@ -984,19 +1127,19 @@ Format Prefix (001)</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997637">
-</A>
+ </A>
 TLA ID</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997639">
-</A>
+ </A>
 =</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997641">
-</A>
+ </A>
 Top-Level Aggregation Identifier</P>
 </TD>
 </TR>
@@ -1004,19 +1147,19 @@ Top-Level Aggregation Identifier</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997643">
-</A>
+ </A>
 RES</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997645">
-</A>
+ </A>
 =</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997647">
-</A>
+ </A>
 Reserved for future use</P>
 </TD>
 </TR>
@@ -1024,19 +1167,19 @@ Reserved for future use</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997649">
-</A>
+ </A>
 NLA ID</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997651">
-</A>
+ </A>
 =</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997653">
-</A>
+ </A>
 Next-Level Aggregation Identifier</P>
 </TD>
 </TR>
@@ -1044,19 +1187,19 @@ Next-Level Aggregation Identifier</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997655">
-</A>
+ </A>
 SLA ID</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997657">
-</A>
+ </A>
 =</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997659">
-</A>
+ </A>
 Site-Level Aggregation Identifier</P>
 </TD>
 </TR>
@@ -1064,63 +1207,71 @@ Site-Level Aggregation Identifier</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997661">
-</A>
+ </A>
 INTERFACE ID</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997663">
-</A>
+ </A>
 =</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997665">
-</A>
+ </A>
 Interface Identifier</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997667">
-</A>
-The `Public Topology' is provided by the upstream provider or ISP, and (roughly) corresponds to the IPv4 `network' section of the address range. The `Site Topology' is where you can subnet this space, much like subnetting an IPv4 class A or B network into class Cs. The `Interface Identifier' is the address of an individual interface on a given network. (With IPv6, addresses belong to interfaces rather than machines.)</P>
+ </A>
+The <EM CLASS="Emphasis">
+Public Topology</EM>
+ is provided by the upstream provider or ISP, and (roughly) corresponds to the IPv4 <EM CLASS="Emphasis">
+network</EM>
+ section of the address range. The <EM CLASS="Emphasis">
+Site Topology</EM>
+ is where you can subnet this space, much like subnetting an IPv4 class A or B network into class Cs. The <EM CLASS="Emphasis">
+Interface Identifier</EM>
+ is the address of an individual interface on a given network. (With IPv6, addresses belong to interfaces rather than machines.)</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997668">
-</A>
+ </A>
 The subnetting capability of IPv6 is much more flexible than that of IPv4: subnetting can now be carried out on bit boundaries, in much the same way as Classless InterDomain Routing (CIDR).</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997669">
-</A>
-The internal structure of the `Public Topology' for an A6 global unicast address consists of:</P>
+ </A>
+The internal structure of the Public Topology for an A6 global unicast address consists of:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997687">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997672">
-</A>
+ </A>
 3</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997674">
-</A>
+ </A>
 13</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997676">
-</A>
+ </A>
 8</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997678">
-</A>
+ </A>
 24</P>
 </TD>
 </TR>
@@ -1128,379 +1279,380 @@ The internal structure of the `Public Topology' for an A6 global unicast address
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997680">
-</A>
+ </A>
 FP</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997682">
-</A>
+ </A>
 TLA ID</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997684">
-</A>
+ </A>
 RES</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997686">
-</A>
+ </A>
 NLA ID</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997688">
-</A>
+ </A>
 A 3 bit FP (Format Prefix) of 001 indicates this is a global unicast address. FP lengths for other types of addresses may vary.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997689">
-</A>
+ </A>
 13 TLA (Top Level Aggregator) bits give the prefix of your top-level IP backbone carrier.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997690">
-</A>
+ </A>
 8 Reserved bits</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997691">
-</A>
+ </A>
 24 bits for Next Level Aggregators. This allows organizations with a TLA to hand out portions of their IP space to client organizations, so that the client can then split up the network further by filling in more NLA bits, and hand out IPv6 prefixes to their clients, and so forth.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997692">
-</A>
-There is no particular structure for the `Site topology' section. Organizations can allocate these bits in any way they desire, in the same way as they would subnet an IPv4 class A (8 bit prefix) network.</P>
+ </A>
+There is no particular structure for the Site topology section. Organizations can allocate these bits in any way they desire, in the same way as they would subnet an IPv4 class A (8 bit prefix) network.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997693">
-</A>
-The Interface identifier must be unique on that network. On ethernet networks, one way to ensure this is to set the address to the first three bytes of the hardware address, `FFFE', then the last three bytes of the hardware address. The lowest significant bit of the first byte should then be complemented. Addresses are written as 32-bit blocks separated with a colon, and leading zeros of a block may be omitted, for example:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997694"></A>
-3ffe:8050:201:9:a00:20ff:fe81:2b32</PRE>
+ </A>
+The Interface identifier must be unique on that network. On ethernet networks, one way to ensure this is to set the address to the first three bytes of the hardware address, &quot;FFFE&quot;, then the last three bytes of the hardware address. The lowest significant bit of the first byte should then be complemented. Addresses are written as 32-bit blocks separated with a colon, and leading zeros of a block may be omitted, for example:</P>
+ 
+<PRE>
+<CODE>3ffe:8050:201:9:a00:20ff:fe81:2b32
+</CODE>
+</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997695">
-</A>
-IPv6 address specifications are likely to 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.</P>
+ </A>
+IPv6 address specifications are likely to contain long strings of zeros, so the architects have included a shorthand for specifying them. The double colon (&quot;::&quot;) indicates the longest possible string of zeros that can fit, and can be used only once in an address.</P>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997696">
-</A>
-4.6.2	Name to Address Lookup</H4>
+ </A>
+4.7.2	Name to Address Lookup</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997697">
-</A>
+ </A>
 Forward name lookups (host name to IP address) under IPv6 do not necessarily return the complete IPv6 address of the host. Because the provider-assigned prefix may change, the A6 record can simply specify the locally assigned portion of the name, and refer to the provider for the remainder.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997698">
-</A>
+ </A>
 A complete IPv6 A6 record that provides the full 128 bit address looks like:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997730">
-</A>
+ </A>
 &nbsp;</P>
+
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="5">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997701">
-</A>
+ </A>
 $ORIGIN example.com.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997711">
-</A>
+ </A>
 ; NAME</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997713">
-</A>
+ </A>
 TTL TYPE</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997715">
-</A>
+ </A>
 BITS IN REFERRAL</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997717">
-</A>
+ </A>
 ADDRESS</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997719">
-</A>
+ </A>
 REFERRAL</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997721">
-</A>
+ </A>
 host.example.com.</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997723">
-</A>
+ </A>
 1h IN A6</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997725">
-</A>
+ </A>
 0</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997727">
-</A>
+ </A>
 3ffe:8050:201:9:a00:20ff:fe81:2b32</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997729">
-</A>
+ </A>
 .</P>
 </TD>
 </TR>
 </TABLE>
-</TABLE>
-</TABLE>
-</TABLE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997731">
-</A>
+ </A>
 Note that the number preceding the address is the number of bits to be provided via the referral. This is probably the easiest way to roll out an IPv6 installation, though you may wish to provide a reference to your provider assigned prefix:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997763">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="5">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997734">
-</A>
+ </A>
 $ORIGIN example.com.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997744">
-</A>
+ </A>
 ; NAME</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997746">
-</A>
+ </A>
 TTL TYPE</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997748">
-</A>
+ </A>
 BITS IN REFERRAL</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997750">
-</A>
+ </A>
 ADDRESS</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997752">
-</A>
+ </A>
 REFERRAL</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997754">
-</A>
+ </A>
 host.example.com.</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997756">
-</A>
+ </A>
 1h IN A6</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997758">
-</A>
+ </A>
 48</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997760">
-</A>
+ </A>
 ::9:a00:20ff:fe81:2b32</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997762">
-</A>
+ </A>
 prefix.example2.com.</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997764">
-</A>
+ </A>
 Then, in example2.com's zone:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997796">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="5">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997767">
-</A>
+ </A>
 $ORIGIN example.com.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997777">
-</A>
+ </A>
 ; NAME</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997779">
-</A>
+ </A>
 TTL TYPE</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997781">
-</A>
+ </A>
 BITS IN REFERRAL</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997783">
-</A>
+ </A>
 ADDRESS</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997785">
-</A>
+ </A>
 REFERRAL</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997787">
-</A>
+ </A>
 prefix.example2.com.</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997789">
-</A>
+ </A>
 1h IN A6</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997791">
-</A>
+ </A>
 0</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997793">
-</A>
+ </A>
 3ffe:8050:201::</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody-fixedfont">
+<P CLASS="CellBody-fixedFontMed">
 <A NAME="pgfId=997795">
-</A>
+ </A>
 .</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997797">
-</A>
-The referral where there are no more bits is to `.', the root zone. Be warned that excessive use of this chaining can lead to extremely poor name resolution for people trying to access your hosts.</P>
+ </A>
+The referral where there are no more bits is to &quot;.&quot;, the root zone. Be warned that excessive use of this chaining can lead to extremely poor name resolution for people trying to access your hosts.</P>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997798">
-</A>
-4.6.3	Address to Name Lookup</H4>
+ </A>
+4.7.3	Address to Name Lookup</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997799">
-</A>
+ </A>
 Reverse IPv6 addresses may appear as one or more hex strings, known as &quot;bitstring labels,&quot; each followed by a number of valid bits. A full 128 bits may be specified at the ip6.int top level, or more likely, the provider will delegate you a smaller chunk of addresses for which you will need to supply reverse DNS.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997800">
-</A>
-The address can be split up along arbitrary boundaries, and is written with hex numbers in forward order, rather than in reverse order as IPv4 PTR records are written. The sections between dot separators are reversed as usual. If the number of valid bits in the hex string is less than the string specifies, it is the <EM CLASS="CharFmt">
+ </A>
+The address can be split up along arbitrary boundaries, and is written with hex numbers in forward order, rather than in reverse order as IPv4 PTR records are written. The sections between dot separators are reversed as usual. If the number of valid bits in the hex string is less than the string specifies, it is the <EM CLASS="Emphasis-underline">
 first N bits</EM>
  that are counted. Thus, \[x2/3] gives a bit pattern of 0010, the first three bits of which, 001, are valid.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997801">
-</A>
+ </A>
 The address above, then, is:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997802">
-</A>
-<CODE CLASS="Program-Process">
-\[x3FFE8050020100090A0020FFFE812B32/128].ip6.int.</CODE>
+ </A>
+<EM CLASS="pathname">
+\[x3FFE8050020100090A0020FFFE812B32/128].ip6.int.</EM>
  (not divided)</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997803">
-</A>
-<CODE CLASS="Program-Process">
-\[x00090A0020FFFE812B32/80].\[xFFF402801008/45].\[x2/3].ip6.int.</CODE>
+ </A>
+<EM CLASS="pathname">
+\[x00090A0020FFFE812B32/80].\[xFFF402801008/45].\[x2/3].ip6.int.</EM>
  (divided into FP, TLA/RES/NLA, and local)</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997807">
-</A>
-<CODE CLASS="Program-Process">
-\[x00090A0020FFFE812B32/80].\[x80500201/32].\[xFFF0/13].\[x2/3].ip6.int.</CODE>
+ </A>
+<EM CLASS="pathname">
+\[x00090A0020FFFE812B32/80].\[x80500201/32].\[xFFF0/13].\[x2/3].ip6.int.</EM>
  (divided into FP, TLA, RES/NLA, and local)</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997808">
-</A>
+ </A>
 These strings are all equivalent. The combined TLA/RES/NLA in the second example bears no resemblance to any string in the address because it is offset by three bits.</P>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997809">
-</A>
-4.6.4	Using DNAME for Delegation of IPv6 Reverse Addresses</H4>
+ </A>
+4.7.4	Using DNAME for Delegation of IPv6 Reverse Addresses</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997810">
-</A>
+ </A>
 Delegation of reverse addresses is done through the new DNAME RR. In the example above, where <EM CLASS="Emphasis">
 \[x2/3].ip6.int.</EM>
  needs to delegate<CODE CLASS="Program-Process">
@@ -1514,45 +1666,51 @@ example2.com</EM>
 ), the domain administrator would insert a line similar to the following in the <EM CLASS="Emphasis">
 \[x2/3].ip6.int.</EM>
  zone:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997811"></A>
+
+<PRE>
+CODE> 
 $ORIGIN \[x2/3].ip6.int.
-\[xFFF0/13] 1h IN DNAME ip6.example2.com.</PRE>
+\[xFFF0/13] 1h IN DNAME ip6.example2.com.
+</CODE>
+</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997813">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 example2.com</EM>
  would then place into the <EM CLASS="Emphasis">
 ip6 </EM>
 zone:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997814"></A>
+ 
+<PRE>
+<CODE>
 $ORIGIN ip6.example.com.
-\[x80500201/32] 1h IN DNAME ip6.example.com.</PRE>
+\[x80500201/32] 1h IN DNAME ip6.example.com.
+</CODE>
+</PRE>
+
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997816">
-</A>
+ </A>
 Finally, <EM CLASS="Emphasis">
 example.com </EM>
 needs to include in the <EM CLASS="Emphasis">
 ip6.example.com</EM>
  zone:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997817"></A>
+ 
+<PRE>
+<CODE>
 $ORIGIN ip6.example.com.
-\[x00090A0020FFFE812B32/80] 1h IN PTR host.example.com.</PRE>
+\[x00090A0020FFFE812B32/80] 1h IN PTR host.example.com.</CODE>
+</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997819">
-</A>
+ </A>
 We suggest that the top of your administrative control (<EM CLASS="Emphasis">
 example.com</EM>
-, in this case) provide all the bits required for reverse and forward resolution to allow name resolution even if the network is disconnected from the Internet. This will also allow operation with DNSSEC if you set up a false trusted server for &quot;.&quot; containing only  delegations for your forward and reverse zones directly to the top of your administrative control. This should be signed with a key trusted by all of your clients, equivalent to the real key for &quot;<CODE CLASS="Program-Process">
-.</CODE>
-&quot;. </P>
-<P CLASS="Body">
-<A NAME="pgfId=997347">
-</A>
-&nbsp;</P>
+, in this case) provide all the bits required for reverse and forward resolution to allow name resolution even if the network is disconnected from the Internet. This will also allow operation with DNSSEC if you set up a false trusted server for &quot;.&quot; containing only  delegations for your forward and reverse zones directly to the top of your administrative control. This should be signed with a key trusted by all of your clients, equivalent to the real key for &quot;.&quot;. </P>
 </DIV>
 </DIV>
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
+<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> 
 </BODY>
 </HTML>
diff --git a/doc/arm/BV9ARM.5.html b/doc/arm/Bv9ARM.5.html
index 97433beb..1f64433a 100644..100755
--- a/doc/arm/BV9ARM.5.html
+++ b/doc/arm/Bv9ARM.5.html
@@ -1,57 +1,57 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
 <TITLE> Section 5.	BINDv9 Configuration Reference</TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
 <OL>
 <H1 CLASS="1Level">
 <A NAME="pgfId=997350">
-</A>
+ </A>
 Section 5.	BINDv9 Configuration Reference</H1>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997351">
-</A>
-BINDv9 configuration is broadly similar to BIND 8.x; however, there are a few new areas of configuration, such as views. BIND 8.x configuration files should work with few alterations in BINDv9, although more complex configurations should be reviewed to check if they can be more efficiently implemented using the new features found in BIND 9.</P>
+ </A>
+BINDv9 configuration is broadly similar to BIND 8.x; however, there are a few new areas of configuration, such as views. BIND 8.x configuration files should work with few alterations in BINDv9, although more complex configurations should be reviewed to check if they can be more efficiently implemented using the new features found in BINDv9.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997352">
-</A>
-BIND 4.9.x configuration files can be converted to the new format by using the Perl script <CODE CLASS="Program-Process">
-src/bin/named/named-bootconf.pl</CODE>
+ </A>
+BIND 4.9.x configuration files can be converted to the new format by using the Perl script <EM CLASS="pathname">
+src/bin/named/named-bootconf.pl</EM>
  from the BIND 8 release kit.</P>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997353">
-</A>
+ </A>
 5.1	Configuration file elements</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997354">
-</A>
+ </A>
 Following is a list of elements used throughout the BIND configuration file documentation:</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997410">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1022979">
-</A>
-<CODE CLASS="Program-Process">
-acl_name</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+acl_name</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1022981">
-</A>
-The name of an <CODE CLASS="Program-Process">
-address_match_list</CODE>
+ </A>
+The name of an <EM CLASS="variable">
+address_match_list</EM>
  as defined by the <CODE CLASS="Program-Process">
 acl</CODE>
  statement.</P>
@@ -59,58 +59,72 @@ acl</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1022983">
-</A>
-<CODE CLASS="Program-Process">
-address_match_list</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+address_match_list</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1022985">
-</A>
-A list of one or more <CODE CLASS="Program-Process">
-ip_addr, ip_prefix, key_id, </CODE>
-or <CODE CLASS="Program-Process">
-acl_name</CODE>
- elements, as described in <A HREF="BV9ARM.5.html#28183" CLASS="XRef">
+ </A>
+A list of one or more <EM CLASS="variable">
+ip_addr</EM>
+<CODE CLASS="Program-Process">
+, </CODE>
+<EM CLASS="variable">
+ip_prefix</EM>
+<CODE CLASS="Program-Process">
+, </CODE>
+<EM CLASS="variable">
+key_id</EM>
+<CODE CLASS="Program-Process">
+, </CODE>
+or <EM CLASS="variable">
+acl_name</EM>
+ elements, as described in <A HREF="Bv9ARM.5.html#28183" CLASS="XRef">
 Address Match Lists</A>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1022990">
-</A>
-<CODE CLASS="Program-Process">
-domain_name</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+domain_name</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1022992">
-</A>
-A quoted string which will be used as a DNS name, for example &quot;<EM CLASS="URL">
+ </A>
+A quoted string which will be used as a DNS name, for example <EM CLASS="grammar_literal">
+&quot;</EM>
+<EM CLASS="URL">
 my.test.domain</EM>
-&quot;.</P>
+<EM CLASS="grammar_literal">
+&quot;</EM>
+.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1022994">
-</A>
-<CODE CLASS="Program-Process">
-dotted_decimal</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+dotted_decimal</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1022996">
-</A>
-One or more integers valued 0 through 255 separated only by dots (&quot;.&quot;), such as <CODE CLASS="Program-Process">
+ </A>
+One or more integers valued 0 through 255 separated only by dots (`.'), such as <CODE CLASS="Program-Process">
 123</CODE>
 , <CODE CLASS="Program-Process">
 45.67</CODE>
@@ -121,34 +135,35 @@ One or more integers valued 0 through 255 separated only by dots (&quot;.&quot;)
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1022998">
-</A>
-<CODE CLASS="Program-Process">
-ip4_addr</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+ip4_addr</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023000">
-</A>
-An IPv4 address with exactly four elements in <CODE CLASS="Program-Process">
-dotted_decimal</CODE>
+ </A>
+An IPv4 address with exactly four elements in <EM CLASS="variable">
+dotted_decimal</EM>
  notation.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023033">
-</A>
-<CODE CLASS="Program-Process">
-ip6_addr</CODE></H6>
+ </A>
+<EM CLASS="variable">
+ip6_addr</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023035">
-</A>
+ </A>
 An IPv6 address, like <CODE CLASS="Program-Process">
 fe80::200:f8ff:fe01:9742</CODE>
 .</P>
@@ -156,59 +171,62 @@ fe80::200:f8ff:fe01:9742</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023098">
-</A>
-<CODE CLASS="Program-Process">
-ip_addr</CODE></H6>
+ </A>
+<EM CLASS="variable">
+ip_addr</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023100">
-</A>
-An <CODE CLASS="Program-Process">
-ip4_addr</CODE>
+ </A>
+An <EM CLASS="variable">
+ip4_addr</EM>
  or<CODE CLASS="Program-Process">
- ip6_addr</CODE>
+ </CODE>
+<EM CLASS="variable">
+ip6_addr</EM>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023002">
-</A>
-<CODE CLASS="Program-Process">
-ip_port</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+ip_port</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023004">
-</A>
-An IP port <CODE CLASS="Program-Process">
-number</CODE>
-.  <CODE CLASS="Program-Process">
-number</CODE>
- is limited to 0 through 65535, with values below 1024 typically restricted to root-owned processes. In some cases an asterisk (*) character can be used as a placeholder to select a random high-numbered port.</P>
+ </A>
+An IP port <EM CLASS="variable">
+number</EM>
+.  <EM CLASS="variable">
+number</EM>
+ is limited to 0 through 65535, with values below 1024 typically restricted to root-owned processes. In some cases an asterisk (`*') character can be used as a placeholder to select a random high-numbered port.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023006">
-</A>
-<CODE CLASS="Program-Process">
-ip_prefix</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+ip_prefix</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023008">
-</A>
-An IP network specified as an <CODE CLASS="Program-Process">
-ip_addr</CODE>
-, followed by &quot;/'' and then the number of bits in the netmask. E.g. <CODE CLASS="Program-Process">
+ </A>
+An IP network specified as an <EM CLASS="variable">
+ip_addr</EM>
+, followed by a slash (`/') and then the number of bits in the netmask. For example, <CODE CLASS="Program-Process">
 127/8</CODE>
  is the network <CODE CLASS="Program-Process">
 127.0.0.0</CODE>
@@ -225,135 +243,143 @@ ip_addr</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023010">
-</A>
-<CODE CLASS="Program-Process">
-key_name</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+key_name</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023012">
-</A>
-A <CODE CLASS="Program-Process">
-domain_name</CODE>
+ </A>
+A <EM CLASS="variable">
+domain_name</EM>
  representing the name of a shared key, to be used for transaction security.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023014">
-</A>
-<CODE CLASS="Program-Process">
-number</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+number</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023016">
-</A>
+ </A>
 A non-negative integer with an entire range limited by the range of a C language signed integer (2,147,483,647 on a machine with 32 bit integers). Its acceptable value might further be limited by the context in which it is used.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023018">
-</A>
-<CODE CLASS="Program-Process">
-path_name</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+path_name</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023020">
-</A>
-A quoted string which will be used as a pathname, such as &quot;<EM CLASS="pathname">
+ </A>
+A quoted string which will be used as a pathname, such as <EM CLASS="grammar_literal">
+&quot;</EM>
+<EM CLASS="pathname">
 zones/master/my.test.domain</EM>
-&quot;.</P>
+<EM CLASS="grammar_literal">
+&quot;</EM>
+.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023022">
-</A>
-<CODE CLASS="Program-Process">
-size_spec</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+size_spec</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023024">
-</A>
-A number, the word <CODE CLASS="Program-Process">
-unlimited</CODE>
-, or the word <CODE CLASS="Program-Process">
-default</CODE>
+ </A>
+A number, the word <EM CLASS="variable">
+unlimited</EM>
+, or the word <EM CLASS="variable">
+default</EM>
 .</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=1023025">
-</A>
-The maximum value of <CODE CLASS="Program-Process">
-size_spec</CODE>
- is that of unsigned long integers on the machine.  <CODE CLASS="Program-Process">
-unlimited</CODE>
- requests unlimited use, or the maximum available amount. <CODE CLASS="Program-Process">
-default</CODE>
+ </A>
+The maximum value of <EM CLASS="variable">
+size_spec</EM>
+ is that of unsigned long integers on the machine. An <EM CLASS="variable">
+unlimited</EM>
+ <EM CLASS="variable">
+size_spec</EM>
+ requests unlimited use, or the maximum available amount. A <EM CLASS="variable">
+default size_spec</EM>
  uses the limit that was in force when the server was started.</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=1023026">
-</A>
-A <CODE CLASS="Program-Process">
-number</CODE>
- can optionally be followed by a scaling factor: <CODE CLASS="Program-Process">
-K</CODE>
- or <CODE CLASS="Program-Process">
-k </CODE>
-for kilobytes, <CODE CLASS="Program-Process">
-M</CODE>
- or <CODE CLASS="Program-Process">
-m</CODE>
- for megabytes, and <CODE CLASS="Program-Process">
-G</CODE>
- or <CODE CLASS="Program-Process">
-g</CODE>
+ </A>
+A <EM CLASS="variable">
+number</EM>
+ can optionally be followed by a scaling factor: <EM CLASS="variable">
+K</EM>
+ or <EM CLASS="variable">
+k</EM>
+<CODE CLASS="Program-Process">
+ </CODE>
+for kilobytes, <EM CLASS="variable">
+M</EM>
+ or <EM CLASS="variable">
+m</EM>
+ for megabytes, and <EM CLASS="variable">
+G</EM>
+ or <EM CLASS="variable">
+g</EM>
  for gigabytes, which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=1023027">
-</A>
-Integer storage overflow is currently silently ignored during conversion of scaled values, resulting in values less than intended, possibly even negative. Using <CODE CLASS="Program-Process">
-unlimited</CODE>
+ </A>
+Integer storage overflow is currently silently ignored during conversion of scaled values, resulting in values less than intended, possibly even negative. Using <EM CLASS="variable">
+unlimited</EM>
  is the best way to safely set a really large number.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023029">
-</A>
-<CODE CLASS="Program-Process">
-yes_or_no</CODE>
-</H6>
+ </A>
+<EM CLASS="variable">
+yes_or_no</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023031">
-</A>
-Either <CODE CLASS="Program-Process">
-yes</CODE>
- or <CODE CLASS="Program-Process">
-no</CODE>
-. The words <CODE CLASS="Program-Process">
-true</CODE>
- and <CODE CLASS="Program-Process">
-false</CODE>
- are also accepted, as are the numbers <CODE CLASS="Program-Process">
-1</CODE>
- and <CODE CLASS="Program-Process">
-0</CODE>
+ </A>
+Either <EM CLASS="variable">
+yes</EM>
+ or <EM CLASS="variable">
+no</EM>
+. The words <EM CLASS="variable">
+true</EM>
+ and <EM CLASS="variable">
+false</EM>
+ are also accepted, as are the numbers <EM CLASS="variable">
+1</EM>
+ and <EM CLASS="variable">
+0</EM>
 .</P>
 </TD>
 </TR>
@@ -362,94 +388,87 @@ false</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997412">
-</A>
+ </A>
 5.1.1	<A NAME="28183">
-</A>
+ </A>
 Address Match Lists</H4>
 </OL>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997413">
-</A>
+ </A>
 5.1.1.1	Syntax</H5>
 </OL>
 
-<PRE CLASS="4Level-fixed"><A NAME="pgfId=997414"></A><EM CLASS="production_target">address_match_list</EM><EM CLASS="Optional-meta-syntax"> = </EM><EM CLASS="variable">address_match_list_element</EM><EM CLASS="Optional-meta-syntax"> </EM><KBD CLASS="Literal-user-input">;</KBD><EM CLASS="Optional-meta-syntax"> [</EM><EM CLASS="variable">address_match_list_element</EM><KBD CLASS="Literal-user-input">;</KBD><EM CLASS="Optional-meta-syntax"> ... ]</EM>
-</PRE>
-<PRE CLASS="4Level-fixed"><A NAME="pgfId=1018549"></A><EM CLASS="production_target">address_match_list_element </EM><EM CLASS="Optional-meta-syntax">= [ </EM><KBD CLASS="Literal-user-input">!</KBD><EM CLASS="Optional-meta-syntax"> ]</EM><EM CLASS="production_target"> </EM><EM CLASS="Optional-meta-syntax">(</EM><EM CLASS="variable">ip_address</EM><EM CLASS="production_target"> </EM><EMCLASS="Optional-meta-syntax">[</EM><KBD CLASS="Literal-user-input">/</KBD><EM CLASS="variable">length</EM><EM CLASS="Optional-meta-syntax">] | </EM><KBD CLASS="Literal-user-input">key</KBD><EM CLASS="production_target"> </EM><EM CLASS="variable">key_id</EM><EM CLASS="Optional-meta-syntax"> |</EM><EM CLASS="production_target"> </EM><EM CLASS="variable">acl_name</EM><EM CLASS="production_target"> </EM><EM CLASS="Optional-meta-syntax">| </EM><KBD CLASS="Literal-user-input">{</KBD><EM CLASS="variable">address_match_list</EM><KBDCLASS="Literal-user-input">}</KBD><EMCLASS="Optional-meta-syntax">)</EM>
+<PRE>
+<CODE>
+address_match_list = <VAR>address_match_list_element</VAR> ;
+  [ <VAR>address_match_list_element</VAR>; ... ]
+address_match_list_element = [ <STRONG>!</STRONG> ] (<VAR>ip_address</VAR> [<STRONG>/</STRONG><VAR>length</VAR>] |
+   key <VAR>key_id</VAR> | <VAR>acl_name</VAR> | { <VAR>address_match_list</VAR> } )</CODE>
 </PRE>
 </DIV>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997415">
-</A>
+ </A>
 5.1.1.2	Definition and Usage</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997416">
-</A>
-Address match lists are primarily used to determine access control for various server operations. They are also used to define priorities for querying other nameservers and to set the addresses on which named will listen for queries. The elements which constitute an address match list can be any of the following:</P>
+ </A>
+Address match lists are primarily used to determine access control for various server operations. They are also used to define priorities for querying other nameservers and to set the addresses on which <CODE CLASS="Program-Process">
+named</CODE>
+ will listen for queries. The elements which constitute an address match list can be any of the following:</P>
 <UL>
 <LI CLASS="4Level-bullet1">
 <A NAME="pgfId=997417">
-</A>
+ </A>
 an IP address (IPv4 or IPv6)</LI>
 <LI CLASS="4Level-bullet2">
 <A NAME="pgfId=997418">
-</A>
-an IP prefix (in the '/'-notation)</LI>
+ </A>
+an IP prefix (in the &quot;/&quot;-notation)</LI>
 <LI CLASS="4Level-bullet2">
 <A NAME="pgfId=997419">
-</A>
+ </A>
 a key ID, as defined by the key statement</LI>
 <LI CLASS="4Level-bullet2">
 <A NAME="pgfId=997420">
-</A>
+ </A>
 the name of an address match list previously defined with the <CODE CLASS="Program-Process">
 acl</CODE>
  statment</LI>
 <LI CLASS="4Level-bullet2">
 <A NAME="pgfId=997421">
-</A>
+ </A>
 a nested address match list enclosed in braces</LI>
 </UL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997422">
-</A>
-Elements can be negated with a leading exclamation mark (&quot;<CODE CLASS="Program-Process">
-!</CODE>
-&quot;), and the match list names &quot;<CODE CLASS="Program-Process">
-any</CODE>
-&quot;, &quot;<CODE CLASS="Program-Process">
-none</CODE>
-&quot;, &quot;<CODE CLASS="Program-Process">
-localhost</CODE>
-&quot; and &quot;<CODE CLASS="Program-Process">
-localnets</CODE>
-&quot; are predefined. More information on those names can be found in the description of the <CODE CLASS="Program-Process">
-acl</CODE>
- statement.</P>
+ </A>
+Elements can be negated with a leading exclamation mark (&quot;!&quot;), and the match list names &quot;any&quot;, &quot;none&quot;, &quot;localhost&quot; and &quot;localnets&quot; are predefined. More information on those names can be found in the description of the acl statement.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997423">
-</A>
+ </A>
 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 &quot;address match list&quot; is still used throughout the documentation.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997424">
-</A>
+ </A>
 When a given IP address or prefix is compared to an address match list, the list is traversed in order until an element matches. The interpretation of a match depends on whether the list is being used for access control, defining listen-on ports, or as a topology, and whether the element was negated.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997425">
-</A>
+ </A>
 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 allow-query, allow-transfer, allow-update and blackhole all use address match lists like this. Similarly, the listen-on option will cause the server to not accept queries on any of the machine's addresses which do not match the list.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997426">
-</A>
+ </A>
 When used with the topology clause, a non-negated match returns a distance based on its position on the list (the closer the match is to the start of the list, the shorter the distance is between it and the server). A negated match will be assigned the maximum distance from the server. If there is no match, the address will get a distance which is further than any non-negated list element, and closer than any negated element.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997427">
-</A>
+ </A>
 Because of the first-match aspect of the algorithm, 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<BR>
 <CODE CLASS="Program-Process">
 1.2.3/24; ! 1.2.3.13;</CODE>
@@ -462,23 +481,23 @@ Because of the first-match aspect of the algorithm, an element that defines a su
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997428">
-</A>
+ </A>
 5.1.2	Comment Syntax</H4>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997429">
-</A>
+ </A>
 The BINDv9 comment syntax allows for comments to appear anywhere that white space may appear in a BIND configuration file. To appeal to programmers of all kinds, they can be written in C, C++, or shell/perl constructs.</P>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997430">
-</A>
+ </A>
 5.1.2.1	Syntax</H5>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997431">
-</A>
+ </A>
 /* This is a BIND comment as in C */<BR>
 // This is a BIND comment as in C++<BR>
 # This is a BIND comment as in common UNIX shells and perl</P>
@@ -487,60 +506,60 @@ The BINDv9 comment syntax allows for comments to appear anywhere that white spac
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997432">
-</A>
+ </A>
 5.1.2.2	Definition and Usage</H5>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997433">
-</A>
+ </A>
 Comments may appear anywhere that whitespace may appear in a BIND configuration file.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997434">
-</A>
+ </A>
 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.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997435">
-</A>
+ </A>
 C-style comments cannot be nested. For example, the following is not valid because the entire comment ends with the first */:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997436">
-</A>
+ </A>
 /* This is the start of a comment.<BR>
    This is still part of the comment.<BR>
 /* This is an incorrect attempt at nesting a comment. */<BR>
    This is no longer in any comment. */</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997437">
-</A>
+ </A>
 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.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997438">
-</A>
+ </A>
 For example:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997439">
-</A>
+ </A>
 // This is the start of a comment.  The next line<BR>
 // is a new comment, even though it is logically<BR>
 // part of the previous comment.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997440">
-</A>
+ </A>
 Shell-style (or perl-style, if you prefer) comments start with the character # (number sign) and continue to the end of the physical line, like C++ comments.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997441">
-</A>
+ </A>
 For example:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997442">
-</A>
+ </A>
 # This is the start of a comment.  The next line<BR>
 # is a new comment, even though it is logically<BR>
 # part of the previous comment.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997443">
-</A>
-WARNING: you cannot use the &quot;;&quot; (semicolon) character to start a comment such as you would in a zone file. The semicolon indicates the end of a configuration statement.</P>
+ </A>
+WARNING: you cannot use the semicolon (&quot;;&quot;) character to start a comment such as you would in a zone file. The semicolon indicates the end of a configuration statement.</P>
 </DIV>
 </DIV>
 </DIV>
@@ -548,53 +567,53 @@ WARNING: you cannot use the &quot;;&quot; (semicolon) character to start a comme
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997445">
-</A>
+ </A>
 5.2	<A NAME="40894">
-</A>
+ </A>
 Configuration File Grammar</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997446">
-</A>
+ </A>
 A BINDv9 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 substatements, which are also terminated with a semicolon.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997447">
-</A>
+ </A>
 The following statements are supported:</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1023879">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023840">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 acl</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023842">
-</A>
+ </A>
 defines a named IP address matching list, for access control and other uses</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023844">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 controls</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023846">
-</A>
+ </A>
 declares control channels to be used by the <CODE CLASS="Program-Process">
 rndc</CODE>
  utility</P>
@@ -602,33 +621,33 @@ rndc</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023848">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 include</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023850">
-</A>
+ </A>
 includes a file</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023852">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 key</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023854">
-</A>
+ </A>
 specifies key information for use in authentication and authorization using TSIG. See <EM CLASS="pathname">
 draft-ietf-dnsind-tsig-13.txt</EM>
  for more information.</P>
@@ -636,104 +655,104 @@ draft-ietf-dnsind-tsig-13.txt</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023856">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 logging</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023858">
-</A>
+ </A>
 specifies what the server logs, and where the log messages are sent</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023860">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 options</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023862">
-</A>
+ </A>
 controls global server configuration options and sets defaults for other statements</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023864">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 server</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023866">
-</A>
+ </A>
 sets certain configuration options on a per-server basis</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023868">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 trusted-keys</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023870">
-</A>
+ </A>
 defines keys that are preconfigured into the server and implicitly trusted. See RFC 2535 for more information.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023872">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 view</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023874">
-</A>
+ </A>
 defines a view</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023876">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 zone</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023878">
-</A>
+ </A>
 defines a zone</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1023880">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 logging</CODE>
  and <CODE CLASS="Program-Process">
@@ -743,53 +762,56 @@ options</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=1023881">
-</A>
+ </A>
 5.2.1	<CODE CLASS="Program-Process">
 acl</CODE>
  Statement Grammar</H4>
 </OL>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997492"></A>
-acl <EM CLASS="variable">acl-name</EM> { 
-    <EM CLASS="variable">address_match_list</EM>
- };</PRE>
+ 
+<PRE>
+<CODE>
+acl <VAR>acl-name</VAR> { 
+    <VAR>address_match_list</VAR> 
+};</CODE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997496">
-</A>
+ </A>
 5.2.2	<CODE CLASS="Program-Process">
 acl</CODE>
 <A NAME="14672">
-</A>
+ </A>
  Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997497">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 acl</CODE>
  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).</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997498">
-</A>
+ </A>
 Note that an address match list's name must be defined with <CODE CLASS="Program-Process">
 acl</CODE>
  before it can be used elsewhere; no forward references are allowed.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997499">
-</A>
+ </A>
 The following ACLs are built-in:</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997517">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
 <H6 CLASS="CellBody21">
 <A NAME="pgfId=997502">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 any</CODE>
 </H6>
@@ -797,7 +819,7 @@ any</CODE>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997504">
-</A>
+ </A>
 Matches all hosts.</P>
 </TD>
 </TR>
@@ -805,7 +827,7 @@ Matches all hosts.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <H6 CLASS="CellBody21">
 <A NAME="pgfId=997506">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 none</CODE>
 </H6>
@@ -813,7 +835,7 @@ none</CODE>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997508">
-</A>
+ </A>
 Matches no hosts.</P>
 </TD>
 </TR>
@@ -821,7 +843,7 @@ Matches no hosts.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <H6 CLASS="CellBody21">
 <A NAME="pgfId=997510">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 localhost</CODE>
 </H6>
@@ -829,7 +851,7 @@ localhost</CODE>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997512">
-</A>
+ </A>
 Matches the IP addresses of all interfaces on the system.</P>
 </TD>
 </TR>
@@ -837,7 +859,7 @@ Matches the IP addresses of all interfaces on the system.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <H6 CLASS="CellBody21">
 <A NAME="pgfId=997514">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 localnets</CODE>
 </H6>
@@ -845,7 +867,7 @@ localnets</CODE>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997516">
-</A>
+ </A>
 Matches any host on a network for which the system has an interface.</P>
 </TD>
 </TR>
@@ -855,29 +877,35 @@ Matches any host on a network for which the system has an interface.</P>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997518">
-</A>
+ </A>
 5.2.3	<CODE CLASS="Program-Process">
-controls</CODE>
+control</CODE>
  Statement Grammar</H4>
 </OL>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997519"></A>
+ 
+<PRE>
+<CODE>
 controls {
-       <EM CLASS="Optional-meta-syntax">[</EM> inet <EM CLASS="Optional-meta-syntax">(</EM> <EM CLASS="variable">ip_addr</EM><EM CLASS="Optional-meta-syntax">|</EM>*<EM CLASS="Optional-meta-syntax">)</EM> port <EM CLASS="variable">ip_port</EM> allow { <EMCLASS="variable">address_match_list</EM>} ; <EM CLASS="Optional-meta-syntax">[</EM>inet...;<EM CLASS="Optional-meta-syntax">[...]]]</EM>
-       <EM CLASS="Optional-meta-syntax">[</EM> unix <EM CLASS="variable">string</EM> permission <EM CLASS="variable">number</EM> owner <EM CLASS="variable">number</EM> group <EM CLASS="variable">number</EM> ; <EM CLASS="Optional-meta-syntax">[</EM>unix...;<EM CLASS="Optional-meta-syntax">[..]]]</EM>
-};</PRE>
+   [ inet (<VAR>ip_addr</VAR>|*) port <VAR>ip_port</VAR> allow { <VAR>address_match_list</VAR> } ;
+      [ inet...;[...]]]
+   [ unix <VAR>string</VAR> permission <VAR>number</VAR> owner <VAR>number</VAR> group <VAR>number</VAR> ;
+      [ unix...;[..]]]
+};</CODE>
+</PRE>
+
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997523">
-</A>
+ </A>
 5.2.4	<CODE CLASS="Program-Process">
 controls</CODE>
  Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997524">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 controls</CODE>
  statement declares control channels to be used by system administrators to affect the operation of the local nameserver. These control channels are used by the <CODE CLASS="Program-Process">
@@ -885,7 +913,7 @@ ndc</CODE>
  utility to send commands to and retrieve non-DNS results from a nameserver.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997525">
-</A>
+ </A>
 A UNIX control channel is a &quot;first in first out&quot; (FIFO) named pipe in the file system, and access to it is controlled by normal file system permissions. It is created by <CODE CLASS="Program-Process">
 named</CODE>
  with the specified file mode bits (see the <CODE CLASS="Program-Process">
@@ -899,7 +927,7 @@ permission</CODE>
  so the number is interpreted as octal. Also note that the user and group ownership specified as owner and group must be given as numbers, not names. It is recommended that the permissions be restricted to administrative personnel only to prevent random users on the system from having the ability to manage the local nameserver.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997526">
-</A>
+ </A>
 An <CODE CLASS="Program-Process">
 inet</CODE>
  control channel is a TCP/IP socket accessible to the Internet, created at the specified <CODE CLASS="Program-Process">
@@ -911,7 +939,7 @@ ip_addr</CODE>
  used, and this only if you trust all non-privileged users on the local host to manage your nameserver.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=1023964">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 The </EM>
 <CODE CLASS="Program-Process">
@@ -924,26 +952,30 @@ controls</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997527">
-</A>
+ </A>
 5.2.5	<CODE CLASS="Program-Process">
 include</CODE>
  Statement Grammar</H4>
 </OL>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997528"></A>
-include &quot;<EM CLASS="variable">filename</EM>&quot;;</PRE>
+
+<PRE>
+<CODE>
+include <VAR>filename</VAR>;
+</CODE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997529">
-</A>
+ </A>
 5.2.6	<CODE CLASS="Program-Process">
 include</CODE>
  Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997530">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 include</CODE>
  statement inserts the specified file at the point that the <CODE CLASS="Program-Process">
@@ -956,51 +988,54 @@ include</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997531">
-</A>
+ </A>
 5.2.7	<CODE CLASS="Program-Process">
 key</CODE>
  Statement Grammar</H4>
 </OL>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997532"></A>
-key <EM CLASS="variable">key_id</EM> {
-    algorithm <EM CLASS="variable">string</EM>;
-    secret <EM CLASS="variable">string</EM>;
-};</PRE>
+ 
+<PRE>
+<CODE>key <VAR>key_id</VAR> {
+    algorithm <VAR>string</VAR>;
+    secret <VAR>string</VAR>;
+};
+</CODE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997536">
-</A>
+ </A>
 5.2.8	<CODE CLASS="Program-Process">
 key</CODE>
  Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997537">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 key</CODE>
  statement defines a key ID which can be used in a server statement to associate an authentication method with a particular nameserver.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997538">
-</A>
+ </A>
 A key ID must be created with the <CODE CLASS="Program-Process">
 key</CODE>
  statement before it can be used in a server definition or an address match list.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997539">
-</A>
-The <CODE CLASS="Program-Process">
-algorithm_id</CODE>
- is a string that specifies a security/authentication algorithm. The only algorithm currently supported with tsig authentication is <CODE CLASS="Program-Process">
-hmac-md5</CODE>
-. The <CODE CLASS="Program-Process">
-secret_string</CODE>
+ </A>
+The <EM CLASS="variable">
+algorithm_id</EM>
+ is a string that specifies a security/authentication algorithm. The only algorithm currently supported with tsig authentication is <EM CLASS="variable">
+hmac-md5</EM>
+. The <EM CLASS="variable">
+secret_string</EM>
  is the secret to be used by the algorithm, and is treated as a base-64 encoded string.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997540">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 key</CODE>
  statement is intended for use in transaction security. Unless included in a server statement, it is not used to sign any requests. It is used to verify requests matching the <CODE CLASS="Program-Process">
@@ -1013,42 +1048,50 @@ algorithm_id</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997541">
-</A>
+ </A>
 5.2.9	<CODE CLASS="Program-Process">
 logging</CODE>
- statement grammar</H4>
+ Statement Grammar</H4>
 </OL>
-<pre>
+ 
+<PRE>
+<CODE>
 logging {
-   [ channel channel_name {
-     ( file path name
-         [ versions (number | unlimited ) ]
-         [ size size spec ]
-       | syslog ( syslog_facility )
-       | null );
+   [ channel <VAR>channel_name</VAR> {
+     ( file <VAR>path name</VAR>
+         [ versions ( <VAR>number</VAR> | unlimited ) ]
+         [ size <VAR>size spec</VAR> ]
+       | syslog ( <STRONG>syslog_facility</STRONG> )
+       | <VAR>null</VAR> );
 
-     [ severity (critical | error | warning | notice |
-                 info | debug [ level ] | dynamic ); ]
-     [ print-category yes or no; ]
-     [ print-severity yes or no; ]
-     [ print-time yes or no; ]
+     [ severity (<VAR>critical</VAR> | <VAR>error</VAR> | <VAR>warning</VAR> | <VAR>notice</VAR> |
+                 <VAR>info</VAR> | <VAR>debug</VAR> [ level ] | <VAR>dynamic</VAR> ); ]
+     [ print-category <VAR>yes or no</VAR>; ]
+     [ print-severity <VAR>yes or no</VAR>; ]
+     [ print-time <VAR>yes or no</VAR>; ] 
    }; ]
 
-   [ category category_name {
-     channel_name ; [channel_name ; ... ]
+   [ category <VAR>category_name</VAR> { 
+     channel_name ; [ <VAR>channel_name</VAR> ; ... ] 
    }; ]
-   ...
-};
-</pre>
 
+   ... 
+};</CODE>
+</PRE>
 
+</DIV>
+<DIV>
+<OL>
+<H4 CLASS="3Level">
+<A NAME="pgfId=997554">
+ </A>
 5.2.10	<CODE CLASS="Program-Process">
 logging</CODE>
- statement definition and usage</H4>
+ Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997555">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 logging</CODE>
  statement configures a wide variety of logging options for the nameserver. Its <CODE CLASS="Program-Process">
@@ -1070,13 +1113,16 @@ logging</CODE>
  statement, the logging configuration will be:</P>
 <PRE CLASS="3Level-fixed"><A NAME="pgfId=997558"></A>
 &nbsp;</PRE>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=1023128"></A>
-logging {
+ 
+<PRE>
+<CODE>logging {
      category default { default_syslog; default_debug; };
-};</PRE>
+};</CODE>
+</PRE>
+
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997565">
-</A>
+ </A>
 In BINDv9, the logging configuration is only established when the entire configuration file has been parsed.  In BIND 8, it was established as soon as the <CODE CLASS="Program-Process">
 logging</CODE>
  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 <CODE CLASS="Program-Process">
@@ -1086,40 +1132,38 @@ logging</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=1022605">
-</A>
+ </A>
 5.2.10.1	The <CODE CLASS="Program-Process">
 channel</CODE>
  Phrase</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022606">
-</A>
+ </A>
 All log output goes to one or more &quot;channels&quot;; you can make as many of them as you want.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022607">
-</A>
-Every <CODE CLASS="Program-Process">
-channel</CODE>
- definition must include a clause that says whether messages selected for the channel go to a file, to a particular syslog facility, or are discarded. It can optionally also limit the message severity level that will be accepted by the channel (default is <CODE CLASS="Program-Process">
+ </A>
+Every channel definition must include a clause that says whether messages selected for the channel go to a file, to a particular syslog facility, or are discarded. It can optionally also limit the message severity level that will be accepted by the channel (the default is <CODE CLASS="Program-Process">
 info</CODE>
 ), and whether to include a <CODE CLASS="Program-Process">
 named</CODE>
--generated time stamp, the category name and/or severity level (default is not to include any).</P>
+-generated time stamp, the category name and/or severity level (the default is not to include any).</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022608">
-</A>
+ </A>
 The word <CODE CLASS="Program-Process">
 null</CODE>
  as the destination option for the channel will cause all messages sent to it to be discarded; in that case, other options for the channel are meaningless.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022609">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 file</CODE>
  clause 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022610">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 size</CODE>
  option for files is simply a hard ceiling on log growth. If the file ever exceeds the size, then <CODE CLASS="Program-Process">
@@ -1127,7 +1171,7 @@ named</CODE>
  will not write anything more to it until the file is reopened; exceeding the size does not automatically trigger a reopen. The default behavior is not to limit the size of the file.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022611">
-</A>
+ </A>
 If you use the <CODE CLASS="Program-Process">
 version</CODE>
  log file option, then <CODE CLASS="Program-Process">
@@ -1153,22 +1197,27 @@ unlimited</CODE>
  in current BIND releases.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022612">
-</A>
+ </A>
 Example usage of the size and versions options:</P>
-<PRE CLASS="4Level-fixed"><A NAME="pgfId=1022613"></A>
-    channel an_example_level {
-        file &quot;lamers.log&quot; versions 3 size 20m;
-        print-time yes;
-        print-category yes;
-    };</PRE>
+
+ 
+<PRE>
+<CODE>
+    channel <VAR>an_example_level</VAR> {
+        file &quot;<EM>lamers.log</EM>&quot; versions 3 size 20m;
+        print-time <VAR>yes</VAR>;
+        print-category <VAR>yes</VAR>;
+    };</CODE>
+</PRE>
+
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022614">
-</A>
+ </A>
 The argument for the <CODE CLASS="Program-Process">
 syslog</CODE>
  clause is a syslog facility as described in the <CODE CLASS="Program-Process">
 syslog</CODE>
- manual page. How <CODE CLASS="Program-Process">
+ man page. How <CODE CLASS="Program-Process">
 syslog</CODE>
  will handle messages sent to this facility is described in the <CODE CLASS="Program-Process">
 syslog.conf</CODE>
@@ -1179,7 +1228,7 @@ openlog()</CODE>
  function, then this clause is silently ignored.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022615">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 severity</CODE>
  clause works like <CODE CLASS="Program-Process">
@@ -1189,7 +1238,7 @@ syslog</CODE>
 . 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022616">
-</A>
+ </A>
 If you are using <CODE CLASS="Program-Process">
 syslog</CODE>
 , then the <CODE CLASS="Program-Process">
@@ -1215,7 +1264,7 @@ syslogd</CODE>
  would print all messages it received from the channel.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022617">
-</A>
+ </A>
 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 <CODE CLASS="Program-Process">
 named</CODE>
  server with the &quot;<CODE CLASS="Program-Process">
@@ -1227,20 +1276,22 @@ the latter method is not yet implemented</EM>
 ). The global debug level can be set to zero, and debugging mode turned off, by running <CODE CLASS="Program-Process">
 ndc notrace</CODE>
 . 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, e.g.</P>
-<PRE CLASS="4Level-fixed"><A NAME="pgfId=1022618"></A>
-  channel specific_debug_level {
-      file &quot;foo&quot;;
+ 
+<PRE>
+<CODE>  channel <VAR>specific_debug_level</VAR> {
+      file &quot;<EM>foo</EM>&quot;;
       severity debug 3;
-  };</PRE>
+        };</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022619">
-</A>
+ </A>
 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 <CODE CLASS="Program-Process">
 dynamic</CODE>
  severity use the server's global level to determine what messages to print.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022620">
-</A>
+ </A>
 If <CODE CLASS="Program-Process">
 print-time</CODE>
  has been turned on, then the date and time will be logged. <CODE CLASS="Program-Process">
@@ -1260,108 +1311,143 @@ print-</CODE>
  options are on:</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022621">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 28-Feb-2000 15:05:32.863 general: notice: running</CODE>
 </P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022622">
-</A>
+ </A>
 There are four predefined channels that are used for <CODE CLASS="Program-Process">
 named</CODE>
-'s default logging as follows. How they are used is described in the section <A HREF="BV9ARM.5.html#36082" CLASS="XRef">
+'s default logging as follows. How they are used is described in the section <A HREF="Bv9ARM.5.html#36082" CLASS="XRef">
 The category Phrase</A>
 .</P>
-<PRE CLASS="4Level-fixedSmall"><A NAME="pgfId=1022813"></A>
+
+<PRE>
+<CODE>
     channel default_syslog {
-        syslog daemon;     # send to syslog's daemon facility
-        severity info;     # only send priority info and higher
+        syslog daemon;    // end to syslog's daemon facility
+        severity info;    // only send priority info and higher
     };
     channel default_debug {
-        file &quot;named.run&quot;;  # write to named.run in the working directory
-                           # Note: stderr is used instead of &quot;named.run&quot;
-                          # if the server is started with the &quot;-f&quot;
-                          # option.
-        severity dynamic  # log at the server's current debug level
+        file &quot;named.run&quot;;  // write to named.run in
+                          // the working directory
+                          // Note: stderr is used instead of
+                          // &quot;named.run&quot;
+                          // if the server is started
+                          // with the &quot;-f&quot; option.
+        severity dynamic  // log at the server's
+                          // current debug level
     };
-    channel default_stderr {     # writes to stderr
-        file &quot;&lt;stderr&gt;&quot;;         # this is illustrative only;
-                                 # there's currently no way of
-                                 # specifying an internal file
-                                 # descriptor in the configuration
-                                 # language.
-        severity info;           # only send priority info and higher
+    channel default_stderr {  // writes to stderr
+        file &quot;&lt;stderr&gt;&quot;;   // this is illustrative only;
+                          // there's currently no way of
+                          // specifying an internal file
+                          // descriptor in the configuration
+                          // language.
+        severity info;    // only send priority info and higher
     };
     channel null {
-       null;                     # toss anything sent to this channel
-    };</PRE>
+       null;                // toss anything sent to this channel
+    };</CODE>
+</PRE>
+
 <P CLASS="4LevelContinued">
-<A NAME="pgfId=1022627">
-</A>
+<A NAME="pgfId=1038366">
+ </A>
+The <CODE CLASS="Program-Process">
+default_debug</CODE>
+ channel normally writes to a file <EM CLASS="pathname">
+named.run</EM>
+ in the server's working directory.  For security reasons, when the &quot;<CODE CLASS="Program-Process">
+-u</CODE>
+&quot;command line option is used, the <EM CLASS="pathname">
+named.run</EM>
+ file is created only after <CODE CLASS="Program-Process">
+named</CODE>
+ has changed to the new UID, and any debug output generated while <CODE CLASS="Program-Process">
+named</CODE>
+ is starting up and still running as root is discarded.  If you need to capture this output, you must run the server with the <CODE CLASS="Program-Process">
+-g</CODE>
+ option and redirect standard error to a file.</P>
+<P CLASS="4LevelContinued">
+<A NAME="pgfId=1038348">
+ </A>
 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.</P>
 </DIV>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=1022629">
-</A>
+ </A>
 5.2.10.2	<A NAME="36082">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 category</CODE>
  Phrase</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022630">
-</A>
+ </A>
 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 <CODE CLASS="Program-Process">
 default</CODE>
  category instead. If you don't specify a default category, the following &quot;default default&quot; is used:</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=1022631"></A>
-    category default { default_syslog; default_debug; };</PRE>
+ 
+<PRE>
+<CODE>    category default { default_syslog; default_debug; };
+</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022632">
-</A>
+ </A>
 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:</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=1022633"></A>
-channel my_security_channel {
-    file &quot;my_security_file&quot;;
-    severity info;
+ 
+<PRE>
+<CODE>
+channel <VAR>my_security_channel</VAR> {
+    file &quot;<EM>my_security_file</EM>&quot;;
+    severity <VAR>info</VAR>;
 };
-category security {
-    my_security_channel;
+category <VAR>security</VAR> {
+    <VAR>my_security_channel</VAR>;
     default_syslog;
     default_debug;
-};</PRE>
+};
+</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1022634">
-</A>
+ </A>
 To discard all messages in a category, specify the <CODE CLASS="Program-Process">
 null</CODE>
  channel:</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=1022635"></A>
-category lame-servers { null; };
-category cname { null; };</PRE>
+<PRE>
+<CODE>
+category lame-<VAR>servers</VAR> { <VAR>null</VAR>; };
+category <VAR>cname</VAR> { <VAR>null</VAR>; };
+</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1024497">
-</A>
+ </A>
 Following are the available categories and brief descriptions of the types of log information they contain.  <EM CLASS="Emphasis">
 This list is still subject to change.</EM>
  </P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024500">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 default</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024502">
-</A>
+ </A>
 The default category defines the logging options for those categories where no specific configuration has been defined. If you do not define a default category, the following definition is used:<BR>
 <EM CLASS="Command">
 category default { default_syslog; default_debug; };</EM>
@@ -1370,173 +1456,177 @@ category default { default_syslog; default_debug; };</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024504">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-general</CODE></H6>
+general</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024506">
-</A>
+ </A>
 The catch-all. Many things still aren't classified into categories, and they all end up here.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024508">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-database</CODE></H6>
+database</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024510">
-</A>
+ </A>
 Messages relating to the databases used internally by the name server to store zone and cache data.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024512">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-security</CODE></H6>
+security</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024514">
-</A>
+ </A>
 Approval and denial of requests.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024516">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 config</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024518">
-</A>
+ </A>
 Configuration file parsing and processing.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024520">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-resolver</CODE></H6>
+resolver</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024522">
-</A>
+ </A>
 DNS resolution, such as the recursive lookups performed on behalf of clients by a caching name server.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024524">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 xfer-in</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024526">
-</A>
+ </A>
 Zone transfers the server is receiving.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024528">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 xfer-out</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024530">
-</A>
+ </A>
 Zone transfers the server is sending.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024532">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 notify</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024534">
-</A>
+ </A>
 The NOTIFY protocol.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024536">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 client</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024538">
-</A>
+ </A>
 Processing of client requests.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024540">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 network</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024542">
-</A>
+ </A>
 Network operations.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024544">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 update</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024546">
-</A>
+ </A>
 Dynamic updates.</P>
 </TD>
 </TR>
@@ -1547,96 +1637,99 @@ Dynamic updates.</P>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=1024547">
-</A>
+ </A>
 5.2.11	<CODE CLASS="Program-Process">
 options</CODE>
  Statement Grammar</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=1024267">
-</A>
+ </A>
 This is the grammar of the <CODE CLASS="Program-Process">
-options</CODE>
- statement in the <CODE CLASS="Program-Process">
-named.conf</CODE>
+option</CODE>
+ statement in the <EM CLASS="pathname">
+named.conf</EM>
  file:</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997568"></A>
-options {
-    <EM CLASS="Optional-meta-syntax">[</EM>version <EM CLASS="variable">version_string</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM>directory <EM CLASS="variable">path_name</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> named-xfer <EM CLASS="variable">path_name</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM>tkey-domain <EM CLASS="variable">string</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM>tkey-dhkey <EM CLASS="variable">string number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM>dump-file <EM CLASS="variable">path_name</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM>memstatistics-file <EM CLASS="variable">path_name</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM>pid-file <EM CLASS="variable">path_name</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM>statistics-file <EM CLASS="variable">path_name</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM>auth-nxdomain <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> deallocate-on-exit <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> dialup <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> fake-iquery <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> fetch-glue <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> has-old-clients <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> host-statistics <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> multiple-cnames <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> notify <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> recursion <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> rfc2308-type1 <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> use-id-pool <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> maintain-ixfr-base <EM CLASS="variable">yes_or_no</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> forward <EM CLASS="Optional-meta-syntax">(</EM> only <EM CLASS="Optional-meta-syntax">|</EM> first <EM CLASS="Optional-meta-syntax">)</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> forwarders { <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">in_addr</EM> ; <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">in_addr</EM> ; ... <EM CLASS="Optional-meta-syntax">] ]</EM> }; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> check-names <EM CLASS="Optional-meta-syntax">(</EM> master <EM CLASS="Optional-meta-syntax">|</EM> slave <EM CLASS="Optional-meta-syntax">|</EM> response <EM CLASS="Optional-meta-syntax">) (</EM> warn <EM CLASS="Optional-meta-syntax">|</EM> fail <EM CLASS="Optional-meta-syntax">|</EM> ignore<EM CLASS="Optional-meta-syntax">)</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> allow-query { <EM CLASS="variable">address_match_list</EM> }; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> allow-transfer { <EM CLASS="variable">address_match_list</EM> }; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> allow-recursion { <EM CLASS="variable">address_match_list</EM> }; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> blackhole { <EM CLASS="variable">address_match_list</EM> }; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> listen-on <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">port ip_port</EM> <EM CLASS="Optional-meta-syntax">]</EM> { <EM CLASS="variable">address_match_list</EM> }; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> query-source <EM CLASS="Optional-meta-syntax">[</EM> address <EM CLASS="Optional-meta-syntax">(</EM> <EM CLASS="variable">ip_addr</EM> <EM CLASS="Optional-meta-syntax">|</EM> * <EM CLASS="Optional-meta-syntax">) ] [</EM> port <EM CLASS="Optional-meta-syntax">(</EM> <EM CLASS="variable">ip_port</EM> <EM CLASS="Optional-meta-syntax">|</EM> * <EM CLASS="Optional-meta-syntax">) ]</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> max-transfer-time-in <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> max-transfer-time-out <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> max-transfer-idle-in <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> max-transfer-idle-out <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> tcp-clients <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> recursive-clients <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> serial-queries <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> transfer-format <EM CLASS="Optional-meta-syntax">(</EM> one-answer <EM CLASS="Optional-meta-syntax">|</EM> many-answers <EM CLASS="Optional-meta-syntax">)</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> transfers-in  <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> transfers-out <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> transfers-per-ns <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> transfer-source <EM CLASS="variable">ip_addr</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> also-notify { <EM CLASS="variable">ip_addr</EM>; <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">ip_addr</EM>; ... <EM CLASS="Optional-meta-syntax">]</EM> };
-    <EM CLASS="Optional-meta-syntax">[</EM> max-ixfr-log-size <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> coresize <EM CLASS="variable">size_spec</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> datasize <EM CLASS="variable">size_spec</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> files <EM CLASS="variable">size_spec</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> stacksize <EM CLASS="variable">size_spec</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> cleaning-interval <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> heartbeat-interval <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> interface-interval <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> statistics-interval <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> topology { <EM CLASS="variable">address_match_list</EM> }; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> sortlist { <EM CLASS="variable">address_match_list</EM> }; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> rrset-order { <EM CLASS="variable">order_spec</EM> ; <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">order_spec</EM> ; ... <EM CLASS="Optional-meta-syntax">] ]</EM> };
-    <EM CLASS="Optional-meta-syntax">[</EM> lame-ttl <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> max-ncache-ttl <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> min-roots <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> use-ixfr <EM CLASS="variable">yes_or_no</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> treat-cr-as-space <EM CLASS="variable">yes_or_no</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-};</PRE>
+
+<PRE>
+<CODE>options {
+    [ version <VAR>version_string</VAR>; ]
+    [ directory <VAR>path_name</VAR>; ]
+    [ named-xfer <VAR>path_name</VAR>; ]
+    [ tkey-domain <VAR>domainname</VAR>; ]
+    [ tkey-dhkey <VAR>keyname</VAR> <VAR>keyid</VAR>; ]
+    [ dump-file <VAR>path_name</VAR>; ]
+    [ memstatistics-file <VAR>path_name</VAR>; ]
+    [ pid-file <VAR>path_name</VAR>; ]
+    [ statistics-file <VAR>path_name</VAR>; ]
+    [ auth-nxdomain <VAR>yes_or_no</VAR>; ]
+    [ deallocate-on-exit <VAR>yes_or_no</VAR>; ]
+    [ dialup <VAR>yes_or_no</VAR>; ]
+    [ fake-iquery <VAR>yes_or_no</VAR>; ]
+    [ fetch-glue <VAR>yes_or_no</VAR>; ]
+    [ has-old-clients <VAR>yes_or_no</VAR>; ]
+    [ host-statistics <VAR>yes_or_no</VAR>; ]
+    [ multiple-cnames <VAR>yes_or_no</VAR>; ]
+    [ notify <VAR>yes_or_no</VAR>; ]
+    [ recursion <VAR>yes_or_no</VAR>; ]
+    [ rfc2308-type1 <VAR>yes_or_no</VAR>; ]
+    [ use-id-pool <VAR>yes_or_no</VAR>; ]
+    [ maintain-ixfr-base <VAR>yes_or_no</VAR>; ]
+    [ forward ( only | first ); ]
+    [ forwarders { [ <VAR>in_addr</VAR> ; [ <VAR>in_addr</VAR> ; ... ] ] }; ]
+    [ check-names ( master | slave | response )( warn | fail | ignore ); ]
+    [ allow-query { <VAR>address_match_list</VAR> }; ]
+    [ allow-transfer { <VAR>address_match_list</VAR> }; ]
+    [ allow-recursion { <VAR>address_match_list</VAR> }; ]
+    [ blackhole { <VAR>address_match_list</VAR> }; ]
+    [ listen-on [ port <VAR>ip_port</VAR> ] { <VAR>address_match_list</VAR> }; ]
+    [ query-source [ address ( <VAR>ip_addr</VAR> | * ) ] [ port ( <VAR>ip_port</VAR> | * ) ]; ]
+    [ max-transfer-time-in <VAR>number</VAR>; ]
+    [ max-transfer-time-out <VAR>number</VAR>; ]
+    [ max-transfer-idle-in <VAR>number</VAR>; ]
+    [ max-transfer-idle-out <VAR>number</VAR>; ]
+    [ tcp-clients <VAR>number</VAR>; ]
+    [ recursive-clients <VAR>number</VAR>; ]
+    [ serial-queries <VAR>number</VAR>; ]
+    [ transfer-format ( one-answer | many-answers ); ]
+    [ transfers-in  <VAR>number</VAR>; ]
+    [ transfers-out <VAR>number</VAR>; ]
+    [ transfers-per-ns <VAR>number</VAR>; ]
+    [ transfer-source <VAR>ip_addr</VAR>; ]
+    [ also-notify { <VAR>ip_addr</VAR>; [ <VAR>ip_addr</VAR>; ... ] }; ]
+    [ max-ixfr-log-size <VAR>number</VAR>; ]
+    [ coresize <VAR>size_spec</VAR> ; ]
+    [ datasize <VAR>size_spec</VAR> ; ]
+    [ files <VAR>size_spec</VAR> ; ]
+    [ stacksize <VAR>size_spec</VAR> ; ]
+    [ cleaning-interval <VAR>number</VAR>; ]
+    [ heartbeat-interval <VAR>number</VAR>; ]
+    [ interface-interval <VAR>number</VAR>; ]
+    [ statistics-interval <VAR>number</VAR>; ]
+    [ topology { <VAR>address_match_list</VAR> }; ]
+    [ sortlist { <VAR>address_match_list</VAR> };]
+    [ rrset-order { <VAR>order_spec</VAR> ; [ <VAR>order_spec</VAR> ; ... ] ] };
+    [ lame-ttl <VAR>number</VAR>; ]
+    [ max-ncache-ttl <VAR>number</VAR>; ]
+    [ min-roots <VAR>number</VAR>; ]
+    [ use-ixfr <VAR>yes_or_no</VAR> ; ]
+    [ treat-cr-as-space <VAR>yes_or_no</VAR> ; ]
+};
+</CODE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997632">
-</A>
+ </A>
 5.2.12	<CODE CLASS="Program-Process">
 options</CODE>
  Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997633">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 options</CODE>
  statement sets up global options to be used by BIND. This statement may appear only once in a configuration file. If more than one occurrence is found, the first occurrence determines the actual options used, and a warning will be generated. If there is no <CODE CLASS="Program-Process">
@@ -1645,19 +1738,19 @@ options</CODE>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997636">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 version</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997638">
-</A>
-The version the server should report via a query of name <CODE CLASS="Program-Process">
-version.bind</CODE>
+ </A>
+The version the server should report via a query of name <EM CLASS="pathname">
+version.bind</EM>
  in class <CODE CLASS="Program-Process">
 chaos</CODE>
 . The default is the real version number of this server.</P>
@@ -1665,35 +1758,37 @@ chaos</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997640">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 directory</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997642">
-</A>
-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. &quot;<CODE CLASS="Program-Process">
-named.run</CODE>
-&quot;) is this directory. If a directory is not specified, the working directory defaults to &quot;.&quot;, the directory from which the server was started. The directory specified should be an absolute path.</P>
+ </A>
+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. <EM CLASS="pathname">
+named.run</EM>
+) is this directory. If a directory is not specified, the working directory defaults to `<EM CLASS="pathname">
+.</EM>
+', the directory from which the server was started. The directory specified should be an absolute path.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997644">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 named-xfer</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997646">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 This option is obsolete.</EM>
   It was used in BIND 8 to specify the pathname to the <CODE CLASS="Program-Process">
@@ -1705,62 +1800,111 @@ named-xfer</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
+<A NAME="pgfId=1038439">
+ </A>
+<CODE CLASS="Program-Process">
+tkey-domain</CODE>
+</P>
+</TD>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
+<A NAME="pgfId=1038441">
+ </A>
+The domain appended to the names of all shared keys generated with <CODE CLASS="Program-Process">
+TKEY</CODE>
+. When a client requests a <CODE CLASS="Program-Process">
+TKEY</CODE>
+ exchange, it may or may not specify the desired name for the key. If present, the name of the shared key will be &quot;<EM CLASS="variable">
+client specified part</EM>
+&quot; + &quot;<EM CLASS="variable">
+tkey-domain</EM>
+&quot;. Otherwise, the name of the shared key will be &quot;<EM CLASS="variable">
+random hex digits</EM>
+&quot; + &quot;<EM CLASS="variable">
+tkey-domain</EM>
+&quot;. In most cases, the <CODE CLASS="Program-Process">
+domainname</CODE>
+ should be the server's domain name.</P>
+</TD>
+</TR>
+<TR>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
+<A NAME="pgfId=1038443">
+ </A>
+<CODE CLASS="Program-Process">
+tkey-dhkey</CODE>
+</P>
+</TD>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
+<A NAME="pgfId=1038445">
+ </A>
+The Diffie-Hellman key used by the server to generate shared keys with clients using the Diffie-Hellman mode of <CODE CLASS="Program-Process">
+TKEY</CODE>
+. The server must be able to load the public and private keys from files in the working directory. In most cases, the keyname should be the server's host name.</P>
+</TD>
+</TR>
+<TR>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997648">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 dump-file</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997650">
-</A>
+ </A>
 The pathname of the file the server dumps the database to when it receives <CODE CLASS="Program-Process">
 SIGINT</CODE>
  signal (<CODE CLASS="Program-Process">
 ndc dumpdb</CODE>
-). If not specified, the default is &quot;<CODE CLASS="Program-Process">
-named_dump.db</CODE>
-&quot;. <EM CLASS="Emphasis">
+). If not specified, the default is <EM CLASS="pathname">
+named_dump.db</EM>
+. <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
 </P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997652">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 memstatistics-file</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997654">
-</A>
-The pathname of the file the server writes memory usage statistics to on exit.  If not specified, the default is &quot;<CODE CLASS="Program-Process">
-named.memstats</CODE>
-&quot;. <EM CLASS="Emphasis">
+ </A>
+The pathname of the file the server writes memory usage statistics to on exit.  If not specified, the default is <EM CLASS="pathname">
+named.memstats</EM>
+. <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
 </P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997656">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 pid-file</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997658">
-</A>
-The pathname of the file the server writes its process ID in. If not specified, the default is operating system dependent, but is usually <EM CLASS="pathname">
+ </A>
+The pathname of the file the server writes its process ID in. If not specified, the default is operating system dependent, but is usually<BR>
+<EM CLASS="pathname">
 /var/run/named.pid</EM>
  or <EM CLASS="pathname">
 /etc/named.pid</EM>
@@ -1769,20 +1913,20 @@ The pathname of the file the server writes its process ID in. If not specified,
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997660">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 statistics-file</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997662">
-</A>
-The pathname of the file the server appends statistics to. If not specified, the default is &quot;<CODE CLASS="Program-Process">
-named.stats</CODE>
-&quot;. <EM CLASS="Emphasis">
+ </A>
+The pathname of the file the server appends statistics to. If not specified, the default is <EM CLASS="pathname">
+named.stats</EM>
+. <EM CLASS="Emphasis">
 Not yet implemented in BINDv9</EM>
 .</P>
 </TD>
@@ -1792,79 +1936,79 @@ Not yet implemented in BINDv9</EM>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997664">
-</A>
+ </A>
 5.2.12.1	<A NAME="12205">
-</A>
+ </A>
 Boolean Options</H5>
 </OL>
-<P CLASS="4LevelContinued">
+<P CLASS="CellBody">
 <A NAME="pgfId=997722">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997667">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 auth-nxdomain</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997669">
-</A>
-If <CODE CLASS="Program-Process">
-yes</CODE>
+ </A>
+If <EM CLASS="variable">
+yes</EM>
 , then the <CODE CLASS="Program-Process">
 AA</CODE>
- bit is always set on NXDOMAIN responses, even if the server is not actually authoritative. The default is <CODE CLASS="Program-Process">
-no</CODE>
-; this is a change from BIND 8. If you are using very old DNS software, you may need to set it to <CODE CLASS="Program-Process">
-yes</CODE>
+ bit is always set on NXDOMAIN responses, even if the server is not actually authoritative. The default is <EM CLASS="variable">
+no</EM>
+; this is a change from BIND 8. If you are using very old DNS software, you may need to set it to <EM CLASS="variable">
+yes</EM>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997671">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 deallocate-on-exit</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997673">
-</A>
+ </A>
 This option was used in BIND 8 to enable checking for memory leaks on exit. BINDv9 ignores the option and always performs the checks.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997675">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 dialup</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997677">
-</A>
-If <CODE CLASS="Program-Process">
-yes</CODE>
+ </A>
+If <EM CLASS="variable">
+yes</EM>
 , 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 <CODE CLASS="Program-Process">
 heartbeat-interval</CODE>
- and hopefully during the one call. It also suppresses some of the normal zone maintenance traffic. The default is <CODE CLASS="Program-Process">
-no</CODE>
+ and hopefully during the one call. It also suppresses some of the normal zone maintenance traffic. The default is <EM CLASS="variable">
+no</EM>
 .</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=997678">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 dialup</CODE>
  option may also be specified in the <CODE CLASS="Program-Process">
@@ -1874,20 +2018,12 @@ options dialup </CODE>
 statement.</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=997679">
-</A>
-If the zone is a <CODE CLASS="Program-Process">
-master</CODE>
- then the server will send out a NOTIFY request to all the slaves. This will trigger the zone serial number check in the slave (providing it supports NOTIFY) allowing the <CODE CLASS="Program-Process">
-slave</CODE>
- to verify the zone while the connection is active.</P>
+ </A>
+If the zone is a master then the server will send out a NOTIFY request to all the slaves. This will 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.</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=997680">
-</A>
-If the zone is a <CODE CLASS="Program-Process">
-slave</CODE>
- or <CODE CLASS="Program-Process">
-stub</CODE>
- then the server will suppress the regular &quot;zone up to date&quot; queries and only perform them when the<BR>
+ </A>
+If the zone is a slave or stub then the server will suppress the regular &quot;zone up to date&quot; queries and only perform them when the<BR>
 <CODE CLASS="Program-Process">
 heartbeat-interval</CODE>
  expires.  <EM CLASS="Emphasis">
@@ -1897,40 +2033,38 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997682">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 fake-iquery</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997684">
-</A>
+ </A>
 In BIND 8, this option was used to enable simulating the obsolete DNS query type IQUERY. BINDv9 never does IQUERY simulation.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997686">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 fetch-glue</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997688">
-</A>
+ </A>
 If <CODE CLASS="Program-Process">
 yes</CODE>
  (the default), the server will fetch &quot;glue&quot; resource records it doesn't have when constructing the additional data section of a response. (Information present outside of the authoritative nodes in the zone is called &quot;glue&quot; information). <CODE CLASS="Program-Process">
-fetch-glue</CODE>
- <CODE CLASS="Program-Process">
-no</CODE>
- can be used in conjunction with <CODE CLASS="Program-Process">
+fetch-glue no </CODE>
+can be used in conjunction with <CODE CLASS="Program-Process">
 recursion no </CODE>
 to prevent the server's cache from growing or becoming corrupted (at the cost of requiring more work from the client). <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
@@ -1939,18 +2073,19 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997690">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 has-old-clients</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997692">
-</A>
-This option was incorrectly implemented in BIND 8, and is ignored by BINDv9.  To achieve the intended effect of <CODE CLASS="Program-Process">
+ </A>
+This option was incorrectly implemented in BIND 8, and is ignored by BINDv9.  To achieve the intended effect of<BR>
+<CODE CLASS="Program-Process">
 has-old-clients yes</CODE>
 , specify the two separate options <CODE CLASS="Program-Process">
 auth-nxdomain yes</CODE>
@@ -1961,21 +2096,21 @@ rfc2308-type-1 no</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997695">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 host-statistics</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997697">
-</A>
-If <CODE CLASS="Program-Process">
-yes</CODE>
-, then statistics are kept for every host that the nameserver interacts with. The default is <CODE CLASS="Program-Process">
-no</CODE>
+ </A>
+If <EM CLASS="variable">
+yes</EM>
+, then statistics are kept for every host that the nameserver interacts with. The default is <EM CLASS="variable">
+no</EM>
 . Note: turning on <CODE CLASS="Program-Process">
 host-statistics</CODE>
  can consume huge amounts of memory. <EM CLASS="Emphasis">
@@ -1985,17 +2120,17 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997699">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 maintain-ixfr-base</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997701">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 This option is obsolete</EM>
 .  It was used in BIND 8 to determine whether a transaction log was kept for Incremental Zone Transfer. BINDv9 maintains a transaction log whenever possible.  If you need to disable outgoing incremental zone transfers, use <CODE CLASS="Program-Process">
@@ -2005,35 +2140,35 @@ provide-ixfr no</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997703">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 multiple-cnames</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997705">
-</A>
+ </A>
 This option was used in BIND 8 to allow a domain name to allow multiple CNAME records in violation of the DNS standards.  BINDv9 currently does not check for multiple CNAMEs in zone data loaded from master files, but such checks may be introduced in a later release.  BINDv9 always strictly enforces the CNAME rules in dynamic updates.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997707">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 notify</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997709">
-</A>
-If <CODE CLASS="Program-Process">
-yes</CODE>
+ </A>
+If <EM CLASS="variable">
+yes</EM>
  (the default), DNS NOTIFY messages are sent when a zone the server is authoritative for changes. The use of NOTIFY speeds synchronization between the master and its slaves. Slave servers that receive a NOTIFY message and understand it will contact the master server for the zone and see if they need to do a zone transfer, and if they do, they will initiate it immediately. The <CODE CLASS="Program-Process">
 notify</CODE>
  option may also be specified in the <CODE CLASS="Program-Process">
@@ -2047,21 +2182,21 @@ Not yet supported in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997711">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 recursion</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997713">
-</A>
-If <CODE CLASS="Program-Process">
-yes</CODE>
-, and a DNS query requests recursion, then the server will attempt to do all the work required to answer the query. If recursion is not on, the server will return a referral to the client if it doesn't know the answer. The default is <CODE CLASS="Program-Process">
-yes</CODE>
+ </A>
+If <EM CLASS="variable">
+yes</EM>
+, and a DNS query requests recursion, then the server will attempt to do all the work required to answer the query. If recursion is not on, the server will return a referral to the client if it doesn't know the answer. The default is <EM CLASS="variable">
+yes</EM>
 . See also <CODE CLASS="Program-Process">
 fetch-glue</CODE>
  above.</P>
@@ -2069,23 +2204,23 @@ fetch-glue</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997715">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 rfc2308-type1</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997717">
-</A>
-If <CODE CLASS="Program-Process">
-yes</CODE>
-, the server will send NS records along with the SOA record for negative answers. You need to set this to <CODE CLASS="Program-Process">
-no</CODE>
- if you have an old BIND server using you as a forwarder that does not understand negative answers which contain both SOA and NS records or you have an old version of sendmail. The correct fix is to upgrade the broken server or sendmail. The default is <CODE CLASS="Program-Process">
-no</CODE>
+ </A>
+If <EM CLASS="variable">
+yes</EM>
+, the server will send NS records along with the SOA record for negative answers. You need to set this to <EM CLASS="variable">
+no</EM>
+ if you have an old BIND server using you as a forwarder that does not understand negative answers which contain both SOA and NS records or you have an old version of sendmail. The correct fix is to upgrade the broken server or sendmail. The default is <EM CLASS="variable">
+no</EM>
 . <EM CLASS="Emphasis">
 Not yet implemented in BINDv9</EM>
 .</P>
@@ -2093,16 +2228,17 @@ Not yet implemented in BINDv9</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023686">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-use-id-pool</CODE></H6>
+use-id-pool</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023688">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 This option is obsolete</EM>
 .  BINDv9 always allocates query IDs from a pool.</P>
@@ -2110,24 +2246,24 @@ This option is obsolete</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997719">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 treat-cr-as-space</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997721">
-</A>
+ </A>
 This option was used in BIND 8 to make the server treat `<CODE CLASS="Program-Process">
 \r</CODE>
 ' characters the same way as <CODE CLASS="Program-Process">
 &lt;space&gt; </CODE>
-&quot;<CODE CLASS="Program-Process">
+`<CODE CLASS="Program-Process">
  </CODE>
-&quot; or `<CODE CLASS="Program-Process">
+` or `<CODE CLASS="Program-Process">
 \t</CODE>
 ', to facilitate loading of zone files on a UNIX system that were generated on an NT or DOS machine. In BINDv9, both UNIX `<CODE CLASS="Program-Process">
 \n</CODE>
@@ -2142,61 +2278,61 @@ This option was used in BIND 8 to make the server treat `<CODE CLASS="Program-Pr
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997723">
-</A>
+ </A>
 5.2.12.2	Forwarding</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997724">
-</A>
+ </A>
 The forwarding facility can be used to create a large site-wide cache on a few servers, reducing traffic over links to external nameservers. 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997734">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997727">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 forward</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997729">
-</A>
-This option is only meaningful if the forwarders list is not empty. A value of <CODE CLASS="Program-Process">
-first</CODE>
-, 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 <CODE CLASS="Program-Process">
-only</CODE>
+ </A>
+This option is only meaningful if the forwarders list is not empty. A value of <EM CLASS="variable">
+first</EM>
+, 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 <EM CLASS="variable">
+only</EM>
  is specified, the server will only query the forwarders.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997731">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 forwarders</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997733">
-</A>
+ </A>
 Specifies the IP addresses to be used for forwarding. The default is the empty list (no forwarding).</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997735">
-</A>
+ </A>
 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 different <CODE CLASS="Program-Process">
 forward only/first behavior</CODE>
-, or not forward at all. See <A HREF="BV9ARM.5.html#20328" CLASS="XRef">
+, or not forward at all. See <A HREF="Bv9ARM.5.html#20328" CLASS="XRef">
 zone Statement Grammar</A>
  for more information.</P>
 </DIV>
@@ -2204,90 +2340,92 @@ zone Statement Grammar</A>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997741">
-</A>
+ </A>
 5.2.12.3	<A NAME="30910">
-</A>
+ </A>
 Name Checking</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997742">
-</A>
+ </A>
 The server can check domain names based upon their expected client contexts. For example, a domain name used as a hostname can be checked for compliance with the RFCs defining valid hostnames.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997743">
-</A>
+ </A>
 Three checking methods are available:</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997757">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997746">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 ignore</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997748">
-</A>
+ </A>
 No checking is done.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997750">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 warn</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997752">
-</A>
+ </A>
 Names are checked against their expected client contexts. Invalid names are logged, but processing continues normally.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997754">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 fail</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997756">
-</A>
+ </A>
 Names are checked against their expected client contexts. Invalid names are logged, and the offending data is rejected.</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997758">
-</A>
+ </A>
 The server can check names in three areas: master zone files, slave zone files, and in responses to queries the server has initiated. If <CODE CLASS="Program-Process">
 check-names response fail</CODE>
  has been specified, and answering the client's question would require sending an invalid name to the client, the server will send a REFUSED response code to the client.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997759">
-</A>
+ </A>
 The defaults are:</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997760"></A>
-    check-names master fail;
+ 
+<PRE>
+<CODE>    check-names master fail;
     check-names slave warn;
-    check-names response ignore;</PRE>
+    check-names response ignore;</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997763">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 check-names</CODE>
  may also be specified in the <CODE CLASS="Program-Process">
@@ -2299,7 +2437,7 @@ zone</CODE>
  statement, the area is not specified (because it can be deduced from the zone type).</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1023294">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 Name checking is not yet implemented in BINDv9.</EM>
 </P>
@@ -2308,35 +2446,35 @@ Name checking is not yet implemented in BINDv9.</EM>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997765">
-</A>
+ </A>
 5.2.12.4	<A NAME="40536">
-</A>
+ </A>
 Access Control</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997766">
-</A>
-Access to the server can be restricted based on the IP address of the requesting system. See <A HREF="BV9ARM.5.html#28183" CLASS="XRef">
+ </A>
+Access to the server can be restricted based on the IP address of the requesting system. See <A HREF="Bv9ARM.5.html#28183" CLASS="XRef">
 Address Match Lists</A>
  for details on how to specify IP address lists.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997787">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997772">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 allow-query</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997774">
-</A>
+ </A>
 Specifies which hosts are allowed to ask ordinary questions. <CODE CLASS="Program-Process">
 allow-query</CODE>
  may also be specified in the <CODE CLASS="Program-Process">
@@ -2348,33 +2486,33 @@ options allow-query</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997776">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 allow-recursion</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997778">
-</A>
+ </A>
 Specifies which hosts are allowed to make recursive queries through this server. If not specified, the default is to allow recursive queries from all hosts. </P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997780">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 allow-transfer</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997782">
-</A>
+ </A>
 Specifies which hosts are allowed to receive zone transfers from the server. <CODE CLASS="Program-Process">
 allow-transfer</CODE>
  may also be specified in the <CODE CLASS="Program-Process">
@@ -2386,17 +2524,17 @@ options allow-transfer</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997784">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 blackhole</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997786">
-</A>
+ </A>
 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 <CODE CLASS="Program-Process">
 none</CODE>
 .  <EM CLASS="Emphasis">
@@ -2410,12 +2548,12 @@ Not yet implemented in BINDv9.</EM>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997788">
-</A>
+ </A>
 5.2.12.5	Interfaces</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997789">
-</A>
+ </A>
 The interfaces and ports that the server will answer queries from may be specified using the <CODE CLASS="Program-Process">
 listen-on</CODE>
  option. <CODE CLASS="Program-Process">
@@ -2425,24 +2563,26 @@ address_match_list</CODE>
 . The server will listen on all interfaces allowed by the address match list. If a port is not specified, port 53 will be used.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997790">
-</A>
+ </A>
 Multiple listen-on statements are allowed. For example,</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997791"></A>
-listen-on { 5.6.7.8; };
-listen-on port 1234 { !1.2.3.4; 1.2/16; };</PRE>
+ 
+<PRE>
+<CODE>listen-on { 5.6.7.8; };
+listen-on port 1234 { !1.2.3.4; 1.2/16; };</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997793">
-</A>
+ </A>
 will enable the nameserver 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997794">
-</A>
+ </A>
 If no <CODE CLASS="Program-Process">
 listen-on</CODE>
  is specified, the server will listen on port 53 on all interfaces.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1023295">
-</A>
+ </A>
 The listen-on option only applies to IPv4.  Currently, the server always listens for IPv6 requests on a wildcard address and port 53.  A separate <CODE CLASS="Program-Process">
 listen-on-v6</CODE>
  option may be added in a later release.</P>
@@ -2451,12 +2591,12 @@ listen-on-v6</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997795">
-</A>
+ </A>
 5.2.12.6	Query Address</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997796">
-</A>
+ </A>
 If the server doesn't know the answer to a question, it will query other nameservers. <CODE CLASS="Program-Process">
 query-source</CODE>
  specifies the address and port used for such queries. For queries sent over IPv6, there is a separate <CODE CLASS="Program-Process">
@@ -2472,12 +2612,14 @@ port</CODE>
  is <CODE CLASS="Program-Process">
 *</CODE>
  or is omitted, a random unprivileged port will be used. The defaults are</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997797"></A>
-query-source address * port *;
-query-source-v6 address * port *</PRE>
+ 
+<PRE>
+<CODE>query-source address * port *;
+query-source-v6 address * port *</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997798">
-</A>
+ </A>
 Note: <CODE CLASS="Program-Process">
 query-source</CODE>
  currently applies only to UDP queries; TCP queries always use a wildcard IP address and a random unprivileged port.</P>
@@ -2486,94 +2628,151 @@ query-source</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997800">
-</A>
+ </A>
 5.2.12.7	<A NAME="32057">
-</A>
+ </A>
 Zone Transfers</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997801">
-</A>
+ </A>
 BIND has mechanisms in place to facilitate zone transfers and set limits on the amount of load that transfers place on the system. The following options apply to zone transfers.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997835">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
+<A NAME="pgfId=1040036">
+ </A>
+<CODE CLASS="Program-Process">
+also-notify</CODE>
+</P>
+</TD>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
+<A NAME="pgfId=1040039">
+ </A>
+Defines a global list of IP addresses that are also sent NOTIFY messages whenever a fresh copy of the zone is loaded. This helps to ensure that copies of the zones will quickly converge on &quot;stealth&quot; servers. If an <CODE CLASS="Program-Process">
+also-notify</CODE>
+ list is given in a <CODE CLASS="Program-Process">
+zone</CODE>
+ statement, it will override the <CODE CLASS="Program-Process">
+options also-notify</CODE>
+ statement. When a <CODE CLASS="Program-Process">
+zone notify</CODE>
+ statement is set to <CODE CLASS="Program-Process">
+no</CODE>
+, the IP addresses in the global <CODE CLASS="Program-Process">
+also-notify</CODE>
+ list will not be sent NOTIFY messages for that zone. The default is the empty list (no global notification list). <EM CLASS="Emphasis">
+Not yet implemented in BINDv9.</EM>
+</P>
+</TD>
+</TR>
+<TR>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997804">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 max-transfer-time-in</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997806">
-</A>
+ </A>
 Inbound zone transfers running longer than this many minutes will be terminated. The default is 120 minutes (2 hours).</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023326">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-max-transfer-idle-in</CODE></H6>
+max-transfer-idle-in</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023328">
-</A>
+ </A>
 Inbound zone transfers making no progress in this many minutes will be terminated. The default is 60 minutes (1 hour).</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023322">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-max-transfer-time-out</CODE></H6>
+max-transfer-time-out</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023324">
-</A>
+ </A>
 Outbound zone transfers running longer than this many minutes will be terminated. The default is 120 minutes (2 hours).</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023318">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-max-transfer-idle-out</CODE></H6>
+max-transfer-idle-out</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023320">
-</A>
-Outbound zone transfers making no progress in this many minutes will be terminated.  The default is 60 minutes (1 hour).</P>
+ </A>
+Outbound zone transfers making no progress in this many minutes will be terminated.  The default is 60 minutes</P>
+<P CLASS="CellBody">
+<A NAME="pgfId=1059994">
+ </A>
+(1 hour).</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
+<A NAME="pgfId=1040047">
+ </A>
+<CODE CLASS="Program-Process">
+serial-queries</CODE>
+</P>
+</TD>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
+<A NAME="pgfId=1040049">
+ </A>
+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, but more importantly each query uses a small amount of memory in the slave server while waiting for the master server to respond. The <CODE CLASS="Program-Process">
+serial-queries </CODE>
+option sets the maximum number of concurrent serial-number queries allowed to be outstanding at any given time. The default is 4. Note: If a server loads a large (tens or hundreds of thousands) number of slave zones, then this limit should be raised to the high hundreds or low thousands -- otherwise the slave server may never actually become aware of zone changes in the master servers. Beware, though, that setting this limit arbitrarily high can spend a considerable amount of your slave server's network, CPU, and memory resources. As with all tunable limits, this one should be changed gently and monitored for its effects. <EM CLASS="Emphasis">
+Not yet implemented in BINDv9.</EM>
+</P>
+</TD>
+</TR>
+<TR>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997808">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 transfer-format</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997810">
-</A>
+ </A>
 The server supports two zone transfer methods. <CODE CLASS="Program-Process">
 one-answer</CODE>
  uses one DNS message per resource record transferred. <CODE CLASS="Program-Process">
@@ -2591,17 +2790,17 @@ server</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997812">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 transfers-in</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997814">
-</A>
+ </A>
 The maximum number of inbound zone transfers that can be running concurrently. The default value is 10. Increasing <CODE CLASS="Program-Process">
 transfers-in</CODE>
  may speed up the convergence of slave zones, but it also may increase the load on the local system.</P>
@@ -2609,33 +2808,33 @@ transfers-in</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997816">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 transfers-out</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997818">
-</A>
+ </A>
 The maximum number of outbound zone transfers that can be running concurrently. Zone transfer requests in excess of the limit will be refused. The default value is 10.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997820">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 transfers-per-ns</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997822">
-</A>
+ </A>
 The maximum number of inbound zone transfers that can be concurrently transferring from a given remote nameserver. The default value is 2. Increasing <CODE CLASS="Program-Process">
 transfers-per-ns</CODE>
  may speed up the convergence of slave zones, but it also may increase the load on the remote nameserver. <CODE CLASS="Program-Process">
@@ -2649,17 +2848,17 @@ server</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997824">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 transfer-source</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997826">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 transfer-source</CODE>
  determines which local address will be bound to IPv4 TCP connections used to fetch zones transferred inbound by the server. If not set, it defaults to a system controlled value which will usually be the address of the interface &quot;closest to&quot; the remote end. This address must appear in the remote end's <CODE CLASS="Program-Process">
@@ -2676,87 +2875,38 @@ zone</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023338">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-transfer-source-v6</CODE></H6>
+transfer-source-v6</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023340">
-</A>
+ </A>
 Like <CODE CLASS="Program-Process">
 transfer-source</CODE>
 , but for zone transfers performed using IPv6.</P>
 </TD>
 </TR>
-<TR>
-<TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=997828">
-</A>
-<CODE CLASS="Program-Process">
-serial-queries</CODE>
-</H6>
-</TD>
-<TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody">
-<A NAME="pgfId=997830">
-</A>
-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, but more importantly each query uses a small amount of memory in the slave server while waiting for the master server to respond. The <CODE CLASS="Program-Process">
-serial-queries </CODE>
-option sets the maximum number of concurrent serial-number queries allowed to be outstanding at any given time. The default is 4. Note: If a server loads a large (tens or hundreds of thousands) number of slave zones, then this limit should be raised to the high hundreds or low thousands -- otherwise the slave server may never actually become aware of zone changes in the master servers. Beware, though, that setting this limit arbitrarily high can spend a considerable amount of your slave server's network, CPU, and memory resources. As with all tunable limits, this one should be changed gently and monitored for its effects. <EM CLASS="Emphasis">
-Not yet implemented in BINDv9.</EM>
-</P>
-</TD>
-</TR>
-<TR>
-<TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=997832">
-</A>
-<CODE CLASS="Program-Process">
-also-notify</CODE>
-</H6>
-</TD>
-<TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody">
-<A NAME="pgfId=997834">
-</A>
-Defines a global list of IP addresses that are also sent NOTIFY messages whenever a fresh copy of the zone is loaded. This helps to ensure that copies of the zones will quickly converge on &quot;stealth&quot; servers. If an <CODE CLASS="Program-Process">
-also-notify</CODE>
- list is given in a <CODE CLASS="Program-Process">
-zone</CODE>
- statement, it will override the <CODE CLASS="Program-Process">
-options also-notify</CODE>
- statement. When a <CODE CLASS="Program-Process">
-zone notify</CODE>
- statement is set to <CODE CLASS="Program-Process">
-no</CODE>
-, the IP addresses in the global <CODE CLASS="Program-Process">
-also-notify</CODE>
- list will not be sent NOTIFY messages for that zone. The default is the empty list (no global notification list). <EM CLASS="Emphasis">
-Not yet implemented in BINDv9.</EM>
-</P>
-</TD>
-</TR>
 </TABLE>
 </DIV>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997836">
-</A>
+ </A>
 5.2.12.8	Resource Limits</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997837">
-</A>
+ </A>
 The server's usage of many system resources can be limited. Some operating systems don't support some of the limits. On such systems, a warning will be issued if the unsupported limit is used. Some operating systems don't support limiting resources.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997838">
-</A>
+ </A>
 Scaled values are allowed when specifying resource limits. For example, <CODE CLASS="Program-Process">
 1G</CODE>
  can be used instead of <CODE CLASS="Program-Process">
@@ -2767,29 +2917,29 @@ unlimited</CODE>
 default</CODE>
  uses the limit that was in force when the server was started. See the description of <CODE CLASS="Program-Process">
 size_spec</CODE>
- in <A HREF="BV9ARM.5.html#40894" CLASS="XRef">
+ in <A HREF="Bv9ARM.5.html#40894" CLASS="XRef">
 Configuration File Grammar</A>
  for more details.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997863">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997844">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 coresize</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997846">
-</A>
-The maximum size of a core dump. The default is <CODE CLASS="Program-Process">
-default</CODE>
+ </A>
+The maximum size of a core dump. The default is <EM CLASS="variable">
+default</EM>
 . <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
 </P>
@@ -2797,19 +2947,19 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997848">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 datasize</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997850">
-</A>
-The maximum amount of data memory the server may use. The default is <CODE CLASS="Program-Process">
-default</CODE>
+ </A>
+The maximum amount of data memory the server may use. The default is <EM CLASS="variable">
+default</EM>
 . <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
 </P>
@@ -2817,21 +2967,21 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997852">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 files</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997854">
-</A>
-The maximum number of files the server may have open concurrently. The default is <CODE CLASS="Program-Process">
-unlimited</CODE>
-. Note: on some operating systems the server cannot set an unlimited value and cannot determine the maximum number of open files the kernel can support. On such systems, choosing <CODE CLASS="Program-Process">
-unlimited</CODE>
+ </A>
+The maximum number of files the server may have open concurrently. The default is <EM CLASS="variable">
+unlimited</EM>
+. Note: on some operating systems the server cannot set an unlimited value and cannot determine the maximum number of open files the kernel can support. On such systems, choosing <EM CLASS="variable">
+unlimited</EM>
  will cause the server to use the larger of the <CODE CLASS="Program-Process">
 rlim_max</CODE>
  for <CODE CLASS="Program-Process">
@@ -2847,17 +2997,17 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997856">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 max-ixfr-log-size</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997858">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 max-ixfr-log-size</CODE>
  will be used in a future release of the server to limit the size of the transaction log kept for Incremental Zone Transfer. <EM CLASS="Emphasis">
@@ -2867,19 +3017,35 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
+<A NAME="pgfId=1040060">
+ </A>
+<CODE CLASS="Program-Process">
+recursive-clients</CODE>
+</P>
+</TD>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
+<A NAME="pgfId=1040062">
+ </A>
+The maximum number of simultaneous recursive lookup the server will perform on behalf of clients.  The default is 100.</P>
+</TD>
+</TR>
+<TR>
+<TD ROWSPAN="1" COLSPAN="1">
+<P CLASS="CellBody">
 <A NAME="pgfId=997860">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 stacksize</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997862">
-</A>
-The maximum amount of stack memory the server may use. The default is <CODE CLASS="Program-Process">
-default</CODE>
+ </A>
+The maximum amount of stack memory the server may use. The default is <EM CLASS="variable">
+default</EM>
 . <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
 </P>
@@ -2887,37 +3053,24 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023744">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
-tcp-clients</CODE></H6>
+tcp-clients</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023746">
-</A>
+ </A>
 The maximum number of simultaneous client TCP connections that the server will accept. The default is 100.</P>
 </TD>
 </TR>
-<TR>
-<TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1023740">
-</A>
-<CODE CLASS="Program-Process">recursive-clients</CODE></H6>
-</TD>
-<TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody">
-<A NAME="pgfId=1023742">
-</A>
-The maximum number of simultaneous recursive lookup the server will perform on behalf of clients.  The default is 100.</P>
-</TD>
-</TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1023396">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 Resource limits are not yet implemented in BINDv9.</EM>
 </P>
@@ -2926,27 +3079,27 @@ Resource limits are not yet implemented in BINDv9.</EM>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=1023375">
-</A>
+ </A>
 5.2.12.9	Periodic Task Intervals</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1023393">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023378">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 cleaning-interval</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023380">
-</A>
+ </A>
 The server will remove expired resource records from the cache every <CODE CLASS="Program-Process">
 cleaning-interval </CODE>
 minutes. The default is 60 minutes. If set to 0, no  periodic cleaning will occur.</P>
@@ -2954,17 +3107,17 @@ minutes. The default is 60 minutes. If set to 0, no  periodic cleaning will occu
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023382">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 heartbeat-interval</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023384">
-</A>
+ </A>
 The server will perform zone maintenance tasks for all zones marked  <CODE CLASS="Program-Process">
 dialup yes</CODE>
  whenever this interval expires. The default is 60 minutes.  Reasonable values are up to 1 day (1440 minutes). If set to 0, no zone maintenance for these zones will occur. <EM CLASS="Emphasis">
@@ -2974,17 +3127,17 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023386">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 interface-interval</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023388">
-</A>
+ </A>
 The server will scan the network interface list every <CODE CLASS="Program-Process">
 interface-interval</CODE>
  minutes. The default is 60 minutes. If set to 0,  interface scanning will only occur when the configuration file is  loaded. After the scan, listeners will be started on any new interfaces (provided they are allowed by the <CODE CLASS="Program-Process">
@@ -2994,17 +3147,17 @@ listen-on</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=1023390">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 statistics-interval</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1023392">
-</A>
+ </A>
 Nameserver statistics will be logged every <CODE CLASS="Program-Process">
 statistics-interval</CODE>
  minutes. The default is 60. If set to 0, no statistics will be logged. <EM CLASS="Emphasis">
@@ -3018,38 +3171,43 @@ Not yet implemented in BINDv9.</EM>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997884">
-</A>
+ </A>
 5.2.12.10	<A NAME="15119">
-</A>
+ </A>
 Topology</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997885">
-</A>
+ </A>
 All other things being equal, when the server chooses a nameserver to query from a list of nameservers, it prefers the one that is topologically closest to itself. The <CODE CLASS="Program-Process">
 topology</CODE>
  statement takes an <CODE CLASS="Program-Process">
 address_match_list</CODE>
  and interprets it in a special way. Each top-level list element is assigned a distance. Non-negated elements get a distance based on their position in the list, where the closer the match is to the start of the list, the shorter the distance is between it and the server. A negated match will be assigned the maximum distance from the server. If there is no match, the address will get a distance which is further than any non-negated list element, and closer than any negated element. For example,</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997886"></A>
-    topology {
+ 
+<PRE>
+<CODE>    topology {
     10/8;
     !1.2.3/24;
     { 1.2/16; 3/8; };
-    };</PRE>
+    };</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997891">
-</A>
+ </A>
 will prefer servers on network 10 the most, followed by hosts on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the exception of hosts on network 1.2.3 (netmask 255.255.255.0), which is preferred least of all.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997892">
-</A>
+ </A>
 The default topology is</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=1023414"></A>
-    topology { localhost; localnets; };</PRE>
+ 
+<PRE>
+CODE>    topology { localhost; localnets; };
+</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1023427">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 The </EM>
 <CODE CLASS="Program-Process">
@@ -3062,16 +3220,16 @@ topology</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=1023411">
-</A>
+ </A>
 5.2.12.11	<A NAME="39491">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 sortlist</CODE>
  Statement</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997896">
-</A>
+ </A>
 Resource Records (RRs) are the data associated with the names in a  domain name space. The data is maintained in the form of sets of RRs. The order of RRs in a set is, by default, not significant. Therefore, to control the sorting of records in a set resource records, or <EM CLASS="Optional-meta-syntax">
 RRset</EM>
 , you must use the <CODE CLASS="Program-Process">
@@ -3079,26 +3237,26 @@ sortlist</CODE>
  statement.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997899">
-</A>
-RRs are explained more fully in <A HREF="BV9ARM.5.html#29114" CLASS="XRef">
+ </A>
+RRs are explained more fully in <A HREF="Bv9ARM.5.html#29114" CLASS="XRef">
 See Types of Resource Records and When to Use Them.</A>
 . Specifications for RRs are documented in RFC 1035.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997901">
-</A>
-When returning multiple RRs, the nameserver will normally return them in <EM CLASS="Optional-meta-syntax">
-Round Robin</EM>
- order, i.e. after each request, the first RR is put at the end of the list. The client resolver code should rearrange the RRs as appropriate, i.e. 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 nameservers, not all the clients.</P>
+ </A>
+When returning multiple RRs, the nameserver will normally return them in <EM CLASS="Emphasis">
+Round Robin </EM>
+order, i.e. after each request, the first RR is put at the end of the list. The client resolver code should rearrange the RRs as appropriate, i.e. 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 nameservers, not all the clients.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997902">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 sortlist</CODE>
  statement (see below) takes an <CODE CLASS="Program-Process">
 address_match_list </CODE>
 and interprets it even more specifically than the <CODE CLASS="Program-Process">
 topology</CODE>
- statement does (see <A HREF="BV9ARM.5.html#15119" CLASS="XRef">
+ statement does (see <A HREF="Bv9ARM.5.html#15119" CLASS="XRef">
 Topology</A>
 ). Each top level statement in the <CODE CLASS="Program-Process">
 sortlist</CODE>
@@ -3109,7 +3267,7 @@ address_match_list</CODE>
 ) of each top level list is checked against the source address of the query until a match is found.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997906">
-</A>
+ </A>
 Once the source address of the query has been matched, if the top level statement contains only one element, the actual primitive element that matched the source address is used to select the address in the response to move to the beginning of the response. If the statement is a list of two elements, then the second element is treated like the <CODE CLASS="Program-Process">
 address_match_list</CODE>
  in a <CODE CLASS="Program-Process">
@@ -3117,12 +3275,13 @@ topology</CODE>
  statement. Each top level element is assigned a distance and the address in the response with the minimum distance is moved to the beginning of the response.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997907">
-</A>
+ </A>
 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<BR>
 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<BR>
 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.</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997908"></A>
-sortlist {
+ 
+<PRE>
+<CODE>sortlist {
     { localhost;            // IF   the local host
         { localnets;        // THEN first fit on the
             192.168.1/24;   //   following nets
@@ -3139,19 +3298,25 @@ sortlist {
     { { 192.168.4/24; 192.168.5/24; };
                           // if .4 or .5, prefer that net
     };
-};</PRE>
+};</CODE>
+</PRE>
+
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997923">
-</A>
+ </A>
 The following example will give reasonable behavior for the local host and hosts on directly connected networks. It is similar to the behavior of the address sort in BIND 8.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.</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997924"></A>
+ 
+<PRE>
+<CODE>
 sortlist {
            { localhost; localnets; };
            { localnets; };
-};</PRE>
+};</CODE>
+</PRE>
+
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1023426">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 The </EM>
 <CODE CLASS="Program-Process">
@@ -3164,108 +3329,115 @@ sortlist</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997929">
-</A>
+ </A>
 5.2.12.12	<A NAME="22766">
-</A>
+ </A>
 RRset Ordering</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997930">
-</A>
+ </A>
 When multiple records are returned in an answer it may be useful to configure the order of the records placed into the response. For example, the records for a zone might be configured always to be returned in the order they are defined in the zone file. Or perhaps a random shuffle of the records as they are returned is wanted. The <CODE CLASS="Program-Process">
 rrset-order</CODE>
  statement permits configuration of the ordering made of the records in a multiple record response. The default, if no ordering is defined, is a cyclic ordering (round robin).</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997931">
-</A>
+ </A>
 An <CODE CLASS="Program-Process">
 order_spec</CODE>
  is defined as follows:</P>
-<PRE CLASS="4Level-fixedSmall"><A NAME="pgfId=997932"></A>
-[ class <EM CLASS="variable">class_name</EM> ][ type <EM CLASS="variable">type_name</EM> ][ name &quot;<EM CLASS="variable">domain_name</EM>&quot;] order <EM CLASS="variable">ordering</EM>
+ 
+<PRE>
+<CODE>
+[ class <VAR>class_name</VAR> ][ type <VAR>type_name</VAR> ][ name &quot;<EM>domain_name</EM>&quot;]
+      order <VAR>ordering</VAR></CODE>
 </PRE>
+
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997933">
-</A>
+ </A>
 If no class is specified, the default is <CODE CLASS="Program-Process">
 ANY</CODE>
 . If no type is specified, the default is <CODE CLASS="Program-Process">
 ANY</CODE>
-. If no name is specified, the default is &quot;<CODE CLASS="Program-Process">
+. If no name is specified, the default is `<CODE CLASS="Program-Process">
 *</CODE>
-&quot;.</P>
+'.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997934">
-</A>
+ </A>
 The legal values for <CODE CLASS="Program-Process">
 ordering</CODE>
  are:</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997948">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997937">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 fixed</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997939">
-</A>
+ </A>
 Records are returned in the order they are defined in the zone file.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997941">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 random</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997943">
-</A>
+ </A>
 Records are returned in some random order.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997945">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 cyclic</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997947">
-</A>
+ </A>
 Records are returned in a round-robin order.</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997949">
-</A>
+ </A>
 For example:</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997950"></A>
-    rrset-order {
-        class IN type A name &quot;host.example.com&quot; order random;
-        order cyclic;
-    };</PRE>
+ 
+<PRE>
+<CODE>    rrset-order {
+        class <VAR>IN</VAR> type <VAR>A</VAR> name &quot;<EM>host.example.com</EM>&quot; order <VAR>random</VAR>;
+        order <VAR>cyclic</VAR>;
+    };
+</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997954">
-</A>
+ </A>
 will cause any responses for type <EM CLASS="Optional-meta-syntax">
 A</EM>
  records in class <EM CLASS="Optional-meta-syntax">
@@ -3273,25 +3445,29 @@ IN</EM>
  that have &quot;host.example.com&quot; as a suffix, to always be returned in random order. All other records are returned in cyclic order.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997955">
-</A>
+ </A>
 If multiple <CODE CLASS="Program-Process">
 rrset-order</CODE>
  statements appear, they are not combined--the last one applies.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997956">
-</A>
+ </A>
 If no <CODE CLASS="Program-Process">
 rrset-order</CODE>
  statement is specified, then a default one of:</P>
-<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997957"></A>
-    rrset-order { class ANY type ANY name &quot;*&quot;; order cyclic ; };</PRE>
+ 
+<PRE>
+<CODE>    rrset-order { class <VAR>ANY</VAR> type <VAR>ANY</VAR> name &quot;<EM>*</EM>&quot;; order <VAR>cyclic</VAR> 
+     };</CODE>
+</PRE>
+
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997958">
-</A>
+ </A>
 is used.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1023432">
-</A>
+ </A>
 <EM CLASS="Emphasis">
 The </EM>
 <CODE CLASS="Program-Process">
@@ -3304,27 +3480,27 @@ rrset-order</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997959">
-</A>
+ </A>
 5.2.12.13	Tuning</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=997973">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997962">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 lame-ttl</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997964">
-</A>
+ </A>
 Sets the number of seconds to cache a lame server indication. 0 disables caching. (This is NOT recommended.) Default is 600 (10 minutes). Maximum value is 1800 (30 minutes). <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
 </P>
@@ -3332,17 +3508,17 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997966">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 max-ncache-ttl</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997968">
-</A>
+ </A>
 To reduce network traffic and increase performance the server stores negative answers. <CODE CLASS="Program-Process">
 max-ncache-ttl</CODE>
  is used to set a maximum retention time for these answers in the server in seconds. The default<BR>
@@ -3358,17 +3534,17 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=997970">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 min-roots</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=997972">
-</A>
+ </A>
 The minimum number of root servers that is required for a request for the root servers to be accepted. Default is 2. <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
 </P>
@@ -3380,59 +3556,65 @@ Not yet implemented in BINDv9.</EM>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=997974">
-</A>
+ </A>
 5.2.12.14	Deprecated Features</H5>
 </OL>
 <P CLASS="4LevelContinued">
-<A NAME="pgfId=997975">
-</A>
+<A NAME="pgfId=1038290">
+ </A>
 <CODE CLASS="Program-Process">
 use-ixfr</CODE>
  is deprecated in BINDv9. If you need to disable IXFR to a particular server or servers see information on the  <CODE CLASS="Program-Process">
 provide-ixfr</CODE>
- option in the Server Statement description (<A HREF="BV9ARM.5.html#34774" CLASS="XRef">
+ option in the Server Statement description (<A HREF="Bv9ARM.5.html#34774" CLASS="XRef">
 server Statement Grammar</A>
- , below) and  in the description of Incremental Transfer (IXFR) (<A HREF="BV9ARM.4.html#19780" CLASS="XRef">
-Incremental Transfer (IXFR)</A>
-).</P>
+ , below) and  in the description of Incremental Transfer (IXFR) in the section <A HREF="Bv9ARM.4.html#19780" CLASS="XRef">
+Incremental Zone Transfers (IXFR)</A>
+.</P>
 </DIV>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
-<A NAME="pgfId=997983">
-</A>
+<A NAME="pgfId=1038295">
+ </A>
 5.2.13	<CODE CLASS="Program-Process">
 server</CODE>
 <A NAME="34774">
-</A>
+ </A>
  Statement Grammar</H4>
 </OL>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997984"></A>
-server <EM CLASS="URL">ip_addr</EM>{
-    <EM CLASS="Optional-meta-syntax">[</EM>bogus <EM CLASS="variable">yes_or_no</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> provide-ixfr <EM CLASS="variable">yes_or_no</EM> ; <EM CLASS="Optional-meta-syntax">]   [</EM> request-ixfr <EM CLASS="variable">yes_or_no</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> transfers <EM CLASS="variable">number</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> transfer-format <EM CLASS="Optional-meta-syntax">(</EM>one-answer <EM CLASS="Optional-meta-syntax">|</EM> many-answers<EM CLASS="Optional-meta-syntax">)</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-    <EM CLASS="Optional-meta-syntax">[</EM> keys { <EM CLASS="variable">string</EM> ; <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">string</EM> ; <EM CLASS="Optional-meta-syntax">[...]]</EM> } ; <EM CLASS="Optional-meta-syntax">]</EM>
-};</PRE>
+<PRE>
+<CODE> 
+<PRE>
+server <VAR>ip_addr</VAR> {
+    [ bogus <VAR>yes_or_no</VAR> ; ]
+    [ provide-ixfr <VAR>yes_or_no</VAR> ; ]
+    [ request-ixfr <VAR>yes_or_no</VAR> ; ]
+    [ transfers <VAR>number</VAR> ; ]
+    [ transfer-format (one-answer | many-answers) ; ]
+    [ keys { <VAR>string</VAR> ; [ <VAR>string</VAR> ; [...]] } ; ]
+};
+</CODE>
+</PRE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997991">
-</A>
+ </A>
 5.2.14	<CODE CLASS="Program-Process">
 server</CODE>
  Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997992">
-</A>
+ </A>
 The server statement defines the characteristics to be associated with a remote nameserver.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997993">
-</A>
+ </A>
 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 <CODE CLASS="Program-Process">
 bogus</CODE>
  is <CODE CLASS="Program-Process">
@@ -3446,7 +3628,7 @@ bogus</CODE>
 </P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997994">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 provide-ixfr</CODE>
  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 <CODE CLASS="Program-Process">
@@ -3458,7 +3640,7 @@ provide-ixfr </CODE>
 option in the global options block is used as a default.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=1023455">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 request-ixfr</CODE>
  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 <CODE CLASS="Program-Process">
@@ -3466,7 +3648,7 @@ request-ixfr</CODE>
  option in the global options block is used as a default.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=1023490">
-</A>
+ </A>
 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 <CODE CLASS="Program-Process">
 yes</CODE>
  should always work. The purpose of the <CODE CLASS="Program-Process">
@@ -3476,14 +3658,14 @@ request-ixfr</CODE>
  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.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=1023509">
-</A>
+ </A>
 The server supports two zone transfer methods. The first, <CODE CLASS="Program-Process">
 one-answer</CODE>
 , uses one DNS message per resource record transferred. <CODE CLASS="Program-Process">
 many-answers</CODE>
  packs as many resource records as possible into a message. <CODE CLASS="Program-Process">
 many-answers</CODE>
- is more efficient, but is only known to be understood by BIND 9, BIND 8.x, and patched versions of BIND 4.9.5. You can specify which method to use for a server with the <CODE CLASS="Program-Process">
+ is more efficient, but is only known to be understood by BINDv9, BIND 8.x, and patched versions of BIND 4.9.5. You can specify which method to use for a server with the <CODE CLASS="Program-Process">
 transfer-format </CODE>
 option. If <CODE CLASS="Program-Process">
 transfer-format </CODE>
@@ -3494,13 +3676,13 @@ options</CODE>
  statement will be used.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997995">
-</A>
+ </A>
 <CODE CLASS="Program-Process">
 transfers</CODE>
  is used to limit the number of concurrent in-bound zone transfers from the specified server.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997996">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 keys</CODE>
  clause is used to identify a <CODE CLASS="Program-Process">
@@ -3514,7 +3696,7 @@ server</CODE>
  statement that references it. 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.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=1023566">
-</A>
+ </A>
 Although the grammar of the <CODE CLASS="Program-Process">
 keys</CODE>
  clause allows for multiple keys, only a single key per server is currently supported.</P>
@@ -3523,129 +3705,222 @@ keys</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997997">
-</A>
+ </A>
 5.2.15	<CODE CLASS="Program-Process">
 trusted-keys</CODE>
  Statement Grammar</H4>
 </OL>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=997998"></A>
-trusted-keys {
-    <EM CLASS="variable">string number number number string</EM> ;
-      [<EM CLASS="variable">string number number number string</EM> ; [...]]
-};</PRE>
+ 
+<PRE>
+<CODE>trusted-keys {
+    <VAR>string number number number string</VAR> ;
+    [ <VAR>string number number number string</VAR> ; [...]]
+};
+</CODE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=998002">
-</A>
+ </A>
 5.2.16	<CODE CLASS="Program-Process">
 trusted-keys</CODE>
  Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998003">
-</A>
-The trusted-keys statement is for use with DNSSEC-style security, originally specified in RFC 2065. DNSSEC is meant to provide three distinct services: key distribution, data origin authentication, and transaction and request authentication. A complete description of DNSSEC and its use is beyond the scope of this document, and readers interested in more information should start with RFC 2065 and then continue with the relevant <EM CLASS="Optional-meta-syntax">
-Internet Drafts</EM>
- (IDs) documents. A list of the Internet Drafts pertaining to DNSSEC can be found in <A HREF="BV9ARM.8.html#" CLASS="XRef">
+ </A>
+The trusted-keys statement is for use with DNSSEC-style security, originally specified in RFC 2065. DNSSEC is meant to provide three distinct services: key distribution, data origin authentication, and transaction and request authentication. A complete description of DNSSEC and its use is beyond the scope of this document, and readers interested in more information should start with RFC 2065 and then continue with the relevant <EM CLASS="Emphasis">
+Internet Drafts </EM>
+(IDs) documents. A list of the IDs pertaining to DNSSEC can be found in <A HREF="Bv9ARM.7.html#" CLASS="XRef">
 Internet Drafts</A>
- in Appendix C of this document. (Their filenames begin with &quot;draft-ietf-dnssec.&quot;). IDs are RFCs in their preliminary stages of development--they are the working drafts of IETF working groups--and can be obtained via anonymous <CODE CLASS="Program-Process">
-FTP</CODE>
- from<BR>
+  in Appendix C of this document. (Their filenames begin with &quot;<EM CLASS="pathname">
+draft-ietf-dnssec</EM>
+.&quot;). IDs are RFCs in the preliminary stages of development--they are the working drafts of IETF working groups--and can be obtained via anonymous FTP from<BR>
 <EM CLASS="URL">
 ftp://www.isi.edu/internet-drafts/ or ftp://www.ietf.org/rfcs/</EM>
 . </P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998007">
-</A>
+ </A>
 Each trusted key is associated with a domain name. Its attributes are the non-negative integral flags, protocol, and algorithm, as well as a base-64 encoded string representing the key.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998008">
-</A>
+ </A>
 A trusted key is added when a public key for a non-authoritative zone is known, but cannot be securely obtained through DNS. This occurs when a signed zone is a child of an unsigned zone. Adding the trusted key here allows data signed by that zone to be considered secure.</P>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=998162">
-</A>
+ </A>
 5.2.17	<CODE CLASS="Program-Process">
 view</CODE>
  Statement Grammar</H4>
 </OL>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=998163"></A>
-view &quot;name&quot; {
-      <EM CLASS="Optional-meta-syntax">... </EM>
-      <EM CLASS="Optional-meta-syntax"> [</EM><EM CLASS="variable">zone_statement</EM; <EM CLASS="Optional-meta-syntax">[</EM><EM CLASS="variable">zone_statement</EM>; <EM CLASS="Optional-meta-syntax">[....]]</EM>
-};</PRE>
+<PRE>
+<CODE> 
+view <VAR>view name</VAR> {
+      match_clients { <VAR>address_match_list</VAR> } ;
+      [view_option; ...]
+     [zone_statement; ...]]
+};
+</CODE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
-<A NAME="pgfId=998166">
-</A>
+<A NAME="pgfId=1038533">
+ </A>
 5.2.18	<CODE CLASS="Program-Process">
 view</CODE>
  Statement Definition and Usage</H4>
 </OL>
 <P CLASS="3LevelContinued">
-<A NAME="pgfId=998167">
-</A>
-<CODE CLASS="Program-Process">
+<A NAME="pgfId=1038546">
+ </A>
+The <CODE CLASS="Program-Process">
 view</CODE>
- statements are used to provide a different view of the same namespace to different clients.  <EM CLASS="Emphasis">
-They are not yet fully implemented.</EM>
-<CODE CLASS="Program-Process">
-</CODE>
-<A NAME="25091">
-</A>
-</P>
+ statement is a powerful new feature of BINDv9 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.</P>
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1038875">
+ </A>
+Each <CODE CLASS="Program-Process">
+view</CODE>
+ statement defines a view of the DNS namespace that will be seen by those clients whose IP addresses match the <CODE CLASS="Program-Process">
+address_match_list</CODE>
+ of the view's <CODE CLASS="Program-Process">
+match-clients</CODE>
+ clause.  The order of the <CODE CLASS="Program-Process">
+view</CODE>
+ statements is significant--a client query will be resolved in the context of the first <CODE CLASS="Program-Process">
+view</CODE>
+ whose <CODE CLASS="Program-Process">
+match-clients </CODE>
+list matches the client's IP address.</P>
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1038605">
+ </A>
+Zones defined within a <CODE CLASS="Program-Process">
+view</CODE>
+ statement will be only be accessible to clients that match the <CODE CLASS="Program-Process">
+view</CODE>
+.  By defining a zone of the same name in multiple views, different zone data can be given to different clients, e.g. &quot;internal&quot; and &quot;external&quot; clients in a split DNS setup.</P>
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1038606">
+ </A>
+Many of the options given in the <CODE CLASS="Program-Process">
+options</CODE>
+ statement can also be used within a <CODE CLASS="Program-Process">
+view</CODE>
+ statement, and then apply only when resolving queries with that view.  When no a view-specific value is given, the value in the <CODE CLASS="Program-Process">
+options</CODE>
+ statement is used as a default.  Also, zone options can have default values specified in the <CODE CLASS="Program-Process">
+view</CODE>
+ statement; these view-specific defaults take precedence over those in the <CODE CLASS="Program-Process">
+options</CODE>
+ statement. </P>
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1038571">
+ </A>
+Views are class specific.  If no class is given, class IN is assumed.</P>
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1038607">
+ </A>
+If there are no <CODE CLASS="Program-Process">
+view</CODE>
+ statements in the config file, a default view that matches any client is automatically created in class IN, and any <CODE CLASS="Program-Process">
+zone</CODE>
+ statements specified on the top level of the configuration file are considered to be part of this default view.  If any explicit <CODE CLASS="Program-Process">
+view</CODE>
+ statements are present, all <CODE CLASS="Program-Process">
+zone</CODE>
+ statements must occur inside <CODE CLASS="Program-Process">
+view</CODE>
+ statements.</P>
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1038608">
+ </A>
+Here is an example of a typical split DNS setup implemented using <CODE CLASS="Program-Process">
+view</CODE>
+ statements.</P>
+ 
+<PRE>
+<CODE>
+view &quot;internal&quot; {               // 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 &quot;e<EM>xample.com</EM>&quot; {
+            type <VAR>master</VAR>;
+            file &quot;<EM>example-internal.db</EM>&quot;;
+      };
+};
+ 
+view &quot;external&quot; {
+      match-clients { <VAR>any</VAR>; };
+                          // Refuse recursive service to external clients.
+      recursion no;
+                         // Provide a restricted view of the example.com zone
+                         // containing only publicly accessible hosts.
+      zone &quot;<EM>example.com</EM>&quot; {
+           type <VAR>master</VAR>;
+           file &quot;<EM>example-external.db</EM>&quot;;
+      };
+};</CODE>
+</PRE>
+
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
-<A NAME="pgfId=998170">
-</A>
+<A NAME="pgfId=1038536">
+ </A>
 5.2.19	<CODE CLASS="Program-Process">
 zone</CODE>
 <A NAME="20328">
-</A>
+ </A>
  Statement Grammar</H4>
 </OL>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=998171"></A>
-zone <EM CLASS="variable"> string</EM> <EM CLASS="Optional-meta-syntax">[</EM><EM CLASS="variable">class</EM><EM CLASS="Optional-meta-syntax">] [</EM>{ 
-    type <EM CLASS="Optional-meta-syntax">(</EM> master<EM CLASS="Optional-meta-syntax">|</EM>slave<EM CLASS="Optional-meta-syntax">|</EM>hint<EM CLASS="Optional-meta-syntax">|</EM>stub<EM CLASS="Optional-meta-syntax">|</EM>forward<EM CLASS="Optional-meta-syntax">)</EM> ;
-   <EM CLASS="Optional-meta-syntax">[</EM> allow-query { <EM CLASS="variable">address_match_list</EM> } ;<EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> allow-transfer { <EM CLASS="variable">address_match_list</EM> } ;<EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> allow-update { <EM CLASS="variable">address_match_list</EM> } ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> update-policy { <EM CLASS="variable">update_policy_rule </EM><EM CLASS="Optional-meta-syntax">[...]</EM> } ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> allow-update-forwarding { <EM CLASS="variable">address_match_list</EM> } ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> also-notify { <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">ip_addr</EM> ; <EM CLASS="Optional-meta-syntax">[</EM>   <EM CLASS="variable">ip_addr</EM> ; <EM CLASS="Optional-meta-syntax">[...]]]</EM> } ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> check-names <EM CLASS="Optional-meta-syntax">(</EM>warn<EM CLASS="Optional-meta-syntax">|</EM>fail<EM CLASS="Optional-meta-syntax">|</EM>ignore<EM CLASS="Optional-meta-syntax">)</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> dialup <EM CLASS="variable">true_or_false</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> file <EM CLASS="variable">string</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> forward <EM CLASS="Optional-meta-syntax">(</EM>only<EM CLASS="Optional-meta-syntax">|</EM>first<EM CLASS="Optional-meta-syntax">)</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> forwarders { <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">ip_addr</EM> ; <EM CLASS="Optional-meta-syntax">[</EM> <EM CLASS="variable">ip_addr</EM> ; <EM CLASS="Optional-meta-syntax">[...]]]</EM> } ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> ixfr-base <EM CLASS="variable">string</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> ixfr-tmp-file <EM CLASS="variable">string</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> maintain-ixfr-base <EM CLASS="variable">true_or_false</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> masters <EM CLASS="Optional-meta-syntax">[</EM>port <EM CLASS="variable">number</EM><EM CLASS="Optional-meta-syntax">]</EM> { <EM CLASS="variable">ip_addr</EM> ; <EM CLASS="Optional-meta-syntax">[</EM><EM CLASS="variable">ip_addr</EM> ; <EM CLASS="Optional-meta-syntax">[...]]</EM> } ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> max-ixfr-log-size <EM CLASS="variable">number</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> max-transfer-idle-in <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> max-transfer-idle-out <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> max-transfer-time-in <EM CLASS="variable">number</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> max-transfer-time-out <EM CLASS="variable">number</EM>; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> notify <EM CLASS="variable">true_or_false</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> pubkey <EM CLASS="variable">number number number</EM> <EM CLASS="variable">string</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>
-   <EM CLASS="Optional-meta-syntax">[</EM> transfer-source <EM CLASS="Optional-meta-syntax">(</EM><EM CLASS="variable">ip_addr</EM> <EM CLASS="Optional-meta-syntax">|</EM> *<EM CLASS="Optional-meta-syntax">)</EM> ; <EM CLASS="Optional-meta-syntax">]</EM>}<EM CLASS="Optional-meta-syntax">]</EM>
-;</PRE>
+ 
+<PRE>
+<CODE>
+zone <VAR>zone name</VAR> [<VAR>class</VAR>] [{ 
+    type ( master|slave|hint|stub|forward ) ;
+    [ allow-query { <VAR>address_match_list</VAR> } ; ]
+    [ allow-transfer { <VAR>address_match_list</VAR> } ; ]
+    [ allow-update { <VAR>address_match_list</VAR> } ; ]
+    [ update-policy { <VAR>update_policy_rule</VAR> [...] } ; ]
+    [ allow-update-forwarding { <VAR>address_match_list</VAR> } ; ]
+    [ also-notify { [ <VAR>ip_addr</VAR> ; [<VAR>ip_addr</VAR> ; [...]]] } ; ]
+    [ check-names (warn|fail|ignore) ; ]
+    [ dialup <VAR>true_or_false</VAR> ; ]
+    [ file <VAR>string</VAR> ; ]
+    [ forward (only|first) ; ]
+    [ forwarders { [ <VAR>ip_addr</VAR> ; [ <VAR>ip_addr</VAR> ; [...]]] } ; ]
+    [ ixfr-base <VAR>string</VAR> ; ]
+    [ ixfr-tmp-file <VAR>string</VAR> ; ]
+    [ maintain-ixfr-base <VAR>true_or_false</VAR> ; ]
+    [ masters [port number] { <VAR>ip_addr</VAR> ; [<VAR>ip_addr</VAR> ; [...]] } ; ]
+    [ max-ixfr-log-size <VAR>number</VAR> ; ]
+    [ max-transfer-idle-in <VAR>number</VAR> ; ]
+    [ max-transfer-idle-out <VAR>number</VAR> ; ]
+    [ max-transfer-time-in <VAR>number</VAR> ; ]
+    [ max-transfer-time-out <VAR>number</VAR> ; ]
+    [ notify <VAR>true_or_false</VAR> ; ]
+    [ pubkey <VAR>number</VAR> <VAR>number</VAR> <VAR>number</VAR> <VAR>string</VAR> ; ]
+    [ transfer-source (<VAR>ip_addr</VAR> | *) ; ]
+}];</CODE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=998197">
-</A>
+ </A>
 5.2.20	<CODE CLASS="Program-Process">
 zone</CODE>
  Statement Definition and Usage</H4>
@@ -3654,38 +3929,38 @@ zone</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=998221">
-</A>
+ </A>
 5.2.20.1	Zone Types</H5>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998200">
-</A>
-<CODE CLASS="Program-Process">
-master</CODE>
-</H6>
+ </A>
+<EM CLASS="Emphasis">
+master</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998202">
-</A>
+ </A>
 The server has a master copy of the data for the zone and will be able to provide authoritative answers for it.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998204">
-</A>
-<CODE CLASS="Program-Process">
-slave</CODE>
-</H6>
+ </A>
+<EM CLASS="Emphasis">
+slave</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998206">
-</A>
+ </A>
 A slave zone is a replica of a master zone. The masters list specifies one or more IP addresses that the slave contacts to update its copy of the zone. If a port is specified, the slave then checks to see if the zone is current and zone transfers will be done to the port given. 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 start-up 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 file names. For example, a slave server for the zone <EM CLASS="Optional-meta-syntax">
 example.com</EM>
  might place the zone contents into a file called<BR>
@@ -3698,33 +3973,33 @@ ex/</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998208">
-</A>
-<CODE CLASS="Program-Process">
-stub</CODE>
-</H6>
+ </A>
+<EM CLASS="Emphasis">
+stub</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998210">
-</A>
+ </A>
 A stub zone is like a slave zone, except that it replicates only the NS records of a master zone instead of the entire zone.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998212">
-</A>
-<CODE CLASS="Program-Process">
-forward</CODE>
-</H6>
+ </A>
+<EM CLASS="Emphasis">
+forward</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998214">
-</A>
+ </A>
 A &quot;forward zone&quot; is a way to configure forwarding on a per-domain basis.  A <CODE CLASS="Program-Process">
 zone</CODE>
  statement of type <CODE CLASS="Program-Process">
@@ -3741,22 +4016,22 @@ forwarders</CODE>
 options</CODE>
  statement. Thus if you want to use this type of zone to change the behavior of the global <CODE CLASS="Program-Process">
 forward</CODE>
- option (i.e., &quot;forward first to, &quot; then &quot;forward only,&quot; or vice versa, but want to use the same servers as set globally) you need to respecify the global forwarders.</P>
+ option (i.e., &quot;forward first to&quot;, then &quot;forward only&quot;, or vice versa, but want to use the same servers as set globally) you need to respecify the global forwarders.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998218">
-</A>
-<CODE CLASS="Program-Process">
-hint</CODE>
-</H6>
+ </A>
+<EM CLASS="Emphasis">
+hint</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998220">
-</A>
+ </A>
 The initial set of root nameservers is specified using a &quot;hint zone&quot;. When the server starts up, it uses the root hints to find a root nameserver and get the most recent list of root nameservers.</P>
 </TD>
 </TR>
@@ -3767,12 +4042,12 @@ The initial set of root nameservers is specified using a &quot;hint zone&quot;.
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=998222">
-</A>
+ </A>
 5.2.20.2	Class</H5>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998223">
-</A>
+ </A>
 The zone's name may optionally be followed by a class. If a class is not specified, class <CODE CLASS="Program-Process">
 in</CODE>
  (for <EM CLASS="Optional-meta-syntax">
@@ -3780,16 +4055,16 @@ internet</EM>
 ), is assumed. This is correct for the vast majority of cases.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998224">
-</A>
+ </A>
 The <EM CLASS="Optional-meta-syntax">
 hesiod </EM>
-class is 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 <CODE CLASS="Program-Process">
+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 <CODE CLASS="Program-Process">
 hs</CODE>
  is a synonym for hesiod.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=1024705">
-</A>
-Another MIT development was CHAOSnet, a LAN protocol created in the mid-1970s. Zone data for it can be specified with the <CODE CLASS="Program-Process">
+ </A>
+Another MIT development is CHAOSnet, a LAN protocol created in the mid-1970s. Zone data for it can be specified with the <CODE CLASS="Program-Process">
 chaos</CODE>
  class.</P>
 </DIV>
@@ -3797,92 +4072,94 @@ chaos</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=1024807">
-</A>
+ </A>
 5.2.20.3	Zone Options</H5>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024708">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031068">
+ </A>
 <CODE CLASS="Program-Process">
 allow-query</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024710">
-</A>
+<A NAME="pgfId=1031070">
+ </A>
 See the description of <CODE CLASS="Program-Process">
 allow-query</CODE>
- under <A HREF="BV9ARM.5.html#40536" CLASS="XRef">
+ under <A HREF="Bv9ARM.5.html#40536" CLASS="XRef">
 Access Control</A>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024715">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031075">
+ </A>
 <CODE CLASS="Program-Process">
 allow-transfer</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024717">
-</A>
+<A NAME="pgfId=1031077">
+ </A>
 See the description of <CODE CLASS="Program-Process">
 allow-transfer</CODE>
- under <A HREF="BV9ARM.5.html#40536" CLASS="XRef">
+ under <A HREF="Bv9ARM.5.html#40536" CLASS="XRef">
 Access Control</A>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024722">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031082">
+ </A>
 <CODE CLASS="Program-Process">
 allow-update</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024724">
-</A>
+<A NAME="pgfId=1031084">
+ </A>
 Specifies which hosts are allowed to submit Dynamic DNS updates for master zones. The default is to deny updates from all hosts.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024726">
-</A>
-update-policy</H6>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031086">
+ </A>
+<CODE CLASS="Program-Process">
+update-policy</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024728">
-</A>
+<A NAME="pgfId=1031088">
+ </A>
 Specifies a &quot;Simple Secure Update&quot; policy. See description below.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024730">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031090">
+ </A>
 <CODE CLASS="Program-Process">
 allow-update-forwarding</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024732">
-</A>
+<A NAME="pgfId=1031092">
+ </A>
 Specifies which hosts are allowed to submit Dynamic DNS updates to slave zones to be forwarded to the master. The default is to deny update forwarding from all hosts. <EM CLASS="Emphasis">
 Update forwarding is not yet implemented.</EM>
 </P>
@@ -3890,17 +4167,17 @@ Update forwarding is not yet implemented.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024734">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031094">
+ </A>
 <CODE CLASS="Program-Process">
 also-notify</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024736">
-</A>
+<A NAME="pgfId=1031096">
+ </A>
 Only meaningful if <CODE CLASS="Program-Process">
 notify</CODE>
  is active for this zone. The set of machines that will receive a <EM CLASS="Optional-meta-syntax">
@@ -3918,18 +4195,18 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024738">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031098">
+ </A>
 <CODE CLASS="Program-Process">
 check-names</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024743">
-</A>
-See <A HREF="BV9ARM.5.html#30910" CLASS="XRef">
+<A NAME="pgfId=1031103">
+ </A>
+See <A HREF="Bv9ARM.5.html#30910" CLASS="XRef">
 Name Checking</A>
 .<BR>
 <EM CLASS="Emphasis">
@@ -3939,20 +4216,20 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024745">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031105">
+ </A>
 <CODE CLASS="Program-Process">
 dialup</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024749">
-</A>
+<A NAME="pgfId=1031107">
+ </A>
 See the description of <CODE CLASS="Program-Process">
 dialup</CODE>
- under <A HREF="BV9ARM.5.html#12205" CLASS="XRef">
+ under <A HREF="Bv9ARM.5.html#12205" CLASS="XRef">
 Boolean Options</A>
 .<BR>
 <EM CLASS="Emphasis">
@@ -3962,17 +4239,17 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024752">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031112">
+ </A>
 <CODE CLASS="Program-Process">
 forward</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024754">
-</A>
+<A NAME="pgfId=1031114">
+ </A>
 Only meaningful if the zone has a forwarders list. The <CODE CLASS="Program-Process">
 only</CODE>
  value causes the lookup to fail after trying the forwarders and getting no answer, while <CODE CLASS="Program-Process">
@@ -3985,23 +4262,23 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024756">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031116">
+ </A>
 <CODE CLASS="Program-Process">
 forwarders</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024758">
-</A>
+<A NAME="pgfId=1031118">
+ </A>
 Used to override the list of global forwarders. If it is not specified in a zone of type <CODE CLASS="Program-Process">
 forward</CODE>
 , no forwarding is done for the zone; the global options are not used.</P>
 <P CLASS="CellBody">
-<A NAME="pgfId=1024759">
-</A>
+<A NAME="pgfId=1031119">
+ </A>
 <EM CLASS="Emphasis">
 Not yet implemented in BINDv9.</EM>
 </P>
@@ -4009,149 +4286,153 @@ Not yet implemented in BINDv9.</EM>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024761">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031121">
+ </A>
 <CODE CLASS="Program-Process">
 ixfr-base</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024763">
-</A>
+<A NAME="pgfId=1031123">
+ </A>
 Specifies the file name for the transaction log file used for dynamic update and IXFR.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024765">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031125">
+ </A>
 <CODE CLASS="Program-Process">
 max-transfer-time-in</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024767">
-</A>
-See the description of <CODE CLASS="Program-Process">
+<A NAME="pgfId=1031127">
+ </A>
+See the description of<BR>
+<CODE CLASS="Program-Process">
 max-transfer-time-in</CODE>
- under <A HREF="BV9ARM.5.html#32057" CLASS="XRef">
+ under <A HREF="Bv9ARM.5.html#32057" CLASS="XRef">
 Zone Transfers</A>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024772">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031132">
+ </A>
 <CODE CLASS="Program-Process">
 max-transfer-idle-in</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024774">
-</A>
-See the description of <CODE CLASS="Program-Process">
+<A NAME="pgfId=1031134">
+ </A>
+See the description of<BR>
+<CODE CLASS="Program-Process">
 max-transfer-idle-in</CODE>
- under <A HREF="BV9ARM.5.html#32057" CLASS="XRef">
+ under <A HREF="Bv9ARM.5.html#32057" CLASS="XRef">
 Zone Transfers</A>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024779">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031139">
+ </A>
 <CODE CLASS="Program-Process">
 max-transfer-time-out</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024781">
-</A>
-See the description of <CODE CLASS="Program-Process">
+<A NAME="pgfId=1031141">
+ </A>
+See the description of<BR>
+<CODE CLASS="Program-Process">
 max-transfer-time-outn</CODE>
- under <A HREF="BV9ARM.5.html#32057" CLASS="XRef">
+ under <A HREF="Bv9ARM.5.html#32057" CLASS="XRef">
 Zone Transfers</A>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024786">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031146">
+ </A>
 <CODE CLASS="Program-Process">
 max-transfer-idle-out</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024788">
-</A>
-See the description of <CODE CLASS="Program-Process">
+<A NAME="pgfId=1031148">
+ </A>
+See the description of<BR>
+<CODE CLASS="Program-Process">
 max-transfer-idle-out</CODE>
- under <A HREF="BV9ARM.5.html#32057" CLASS="XRef">
+ under <A HREF="Bv9ARM.5.html#32057" CLASS="XRef">
 Zone Transfers</A>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024793">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031153">
+ </A>
 <CODE CLASS="Program-Process">
 notify</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024797">
-</A>
+<A NAME="pgfId=1031155">
+ </A>
 See the description of <CODE CLASS="Program-Process">
 notify</CODE>
- under <A HREF="BV9ARM.5.html#12205" CLASS="XRef">
+ under <A HREF="Bv9ARM.5.html#12205" CLASS="XRef">
 Boolean Options</A>
 .</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024800">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031160">
+ </A>
 <CODE CLASS="Program-Process">
 pubkey</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024802">
-</A>
+<A NAME="pgfId=1031162">
+ </A>
 Represents a public key for this zone. It is needed when this is the top level authoritative zone served by this server and there is no chain of trust to a trusted key. It is considered secure, so that data that it signs will be considered secure. The DNSSEC flags, protocol, and algorithm are specified, as well as a base-64 encoded string representing the key.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024804">
-</A>
+<P CLASS="CellBody">
+<A NAME="pgfId=1031164">
+ </A>
 <CODE CLASS="Program-Process">
 transfer-source</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024806">
-</A>
+<A NAME="pgfId=1031166">
+ </A>
 Determines which local address will be bound to the TCP connection used to fetch this zone. If not set, it defaults to a system controlled value which will usually be the address of the interface <EM CLASS="Optional-meta-syntax">
 closest to</EM>
  the remote end. This address must appear in the remote end's <CODE CLASS="Program-Process">
@@ -4166,12 +4447,12 @@ allow-transfer</CODE>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=1024815">
-</A>
+ </A>
 5.2.20.4	Dynamic Update Policies</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1025001">
-</A>
+ </A>
 BINDv9 supports two alternative methods of granting clients the right to perform dynamic updates to a zone, configured by the <CODE CLASS="Program-Process">
 allow-update</CODE>
  and <CODE CLASS="Program-Process">
@@ -4179,19 +4460,19 @@ update-policy</CODE>
  option, respectively.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1024859">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 allow-update</CODE>
  clause works the same way as in previous versions of BIND. It grants given clients the permission to update any record of any name in the zone.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1024862">
-</A>
+ </A>
 The <CODE CLASS="Program-Process">
 update-policy</CODE>
  clause is new in BINDv9 and allows more fine-grained control over what updates are allowed. A set of rules is specified, where each rule either grants or denies permissions for one or more names to be updated by one or more identities.  If the dynamic update request message is signed (that is, it includes either a TSIG or SIG(0) record), the identity of the signer can be determined.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1024826">
-</A>
+ </A>
 Rules are specified in the <CODE CLASS="Program-Process">
 update-policy</CODE>
  zone option, and are only meaninful for master zones.  When the <CODE CLASS="Program-Process">
@@ -4203,45 +4484,20 @@ update-policy</CODE>
  statement only examines the signer of a message; the source address is not relevant.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1024827">
-</A>
-A rule defition looks like:</P>
-<P CLASS="4LevelContinued">
-<A NAME="pgfId=1024828">
-</A>
-(<EM CLASS="Optional-meta-syntax">
- </EM>
-<CODE CLASS="Program-Process">
-grant</CODE>
-<EM CLASS="Optional-meta-syntax">
- | </EM>
-<CODE CLASS="Program-Process">
-deny</CODE>
-<EM CLASS="Optional-meta-syntax">
- ) </EM>
-<EM CLASS="variable">
-identity</EM>
-<EM CLASS="Optional-meta-syntax">
- </EM>
-<EM CLASS="variable">
-nametype</EM>
-<EM CLASS="Optional-meta-syntax">
- </EM>
-<EM CLASS="variable">
-name</EM>
-<EM CLASS="Optional-meta-syntax">
- [ </EM>
-<EM CLASS="variable">
-types</EM>
-<EM CLASS="Optional-meta-syntax">
- ]</EM>
-</P>
+ </A>
+A rule definition looks like:</P>
+ 
+<PRE>
+<CODE>( grant | deny ) identity nametype nam [ types ]
+</CODE>
+</PRE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1024829">
-</A>
+ </A>
 Each rule grants or denies privileges.  Once a messages has successfully matched a rule, the operation is immediately granted or denied - no further rules are examined.  A rule is matched when the signer matches the identity field, the name matches the name field, and the type is specified in the type field.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1024969">
-</A>
+ </A>
 The identity field specifies a name or a wildcard name.  The nametype field has 4 values: <EM CLASS="Emphasis">
 name</EM>
 , <EM CLASS="Emphasis">
@@ -4254,65 +4510,73 @@ self</EM>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody1">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024972">
-</A>
-name</P>
+ </A>
+<EM CLASS="variable">
+name</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024974">
-</A>
+ </A>
 Matches when the updated name is the same as the name in the name field.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody1">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024976">
-</A>
-subdomain</P>
+ </A>
+<EM CLASS="variable">
+subdomain</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024978">
-</A>
+ </A>
 Matches when the updated name is a subdomain of the name in the name field.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody1">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024980">
-</A>
-wildcard</P>
+ </A>
+<EM CLASS="variable">
+wildcard</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024982">
-</A>
+ </A>
 Matches when the updated name is a valid expansion of the wildcard name in the name field.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<P CLASS="CellBody1">
+<P CLASS="CellBody">
 <A NAME="pgfId=1024984">
-</A>
-self</P>
+ </A>
+<EM CLASS="variable">
+self</EM>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=1024986">
-</A>
+ </A>
 Matches when the updated name is the same as the message signer. The name field is ignored.</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=1025025">
-</A>
-If no types are specified, the rule matches all types except SIG, NS, SOA, and NXT. Types may be specified by name, including &quot;any&quot; (which matches all types except NXT, which can never be updated).</P>
+ </A>
+If no types are specified, the rule matches all types except SIG, NS, SOA, and NXT. Types may be specified by name, including &quot;ANY&quot; (ANY matches all types except NXT, which can never be updated).</P>
 </DIV>
 </DIV>
 </DIV>
@@ -4320,53 +4584,53 @@ If no types are specified, the rule matches all types except SIG, NS, SOA, and N
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=1024987">
-</A>
+ </A>
 5.3	 Zone File</H3>
 </OL>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=1024701">
-</A>
+ </A>
 5.3.1	<A NAME="29114">
-</A>
+ </A>
 Types of Resource Records and When to Use Them</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=1024991">
-</A>
+ </A>
 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.</P>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=998303">
-</A>
+ </A>
 5.3.1.1	Resource Records</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998304">
-</A>
-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 nameservers, 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 <A HREF="BV9ARM.5.html#39491" CLASS="XRef">
+ </A>
+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 nameservers, 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 <A HREF="Bv9ARM.5.html#39491" CLASS="XRef">
 The sortlist Statement</A>
- and <A HREF="BV9ARM.5.html#22766" CLASS="XRef">
+ and <A HREF="Bv9ARM.5.html#22766" CLASS="XRef">
 RRset Ordering</A>
  for details.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998332">
-</A>
+ </A>
 The components of a RR are</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998313">
-</A>
+ </A>
 owner name</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998315">
-</A>
+ </A>
 the domain name where the RR is found.</P>
 </TD>
 </TR>
@@ -4374,13 +4638,13 @@ the domain name where the RR is found.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998317">
-</A>
+ </A>
 type</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998319">
-</A>
+ </A>
 an encoded 16 bit value that specifies the type of the resource in this resource record. Types refer to abstract resources.</P>
 </TD>
 </TR>
@@ -4388,13 +4652,13 @@ an encoded 16 bit value that specifies the type of the resource in this resource
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998321">
-</A>
+ </A>
 TTL</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998323">
-</A>
+ </A>
 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.</P>
 </TD>
 </TR>
@@ -4402,13 +4666,13 @@ the time to live of the RR. This field is a 32 bit integer in units of seconds,
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998325">
-</A>
+ </A>
 class</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998327">
-</A>
+ </A>
 an encoded 16 bit value that identifies a protocol family or instance of a protocol.</P>
 </TD>
 </TR>
@@ -4416,20 +4680,20 @@ an encoded 16 bit value that identifies a protocol family or instance of a proto
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998329">
-</A>
+ </A>
 RDATA</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998331">
-</A>
+ </A>
 the type and sometimes class-dependent data that describes the resource.</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998333">
-</A>
+ </A>
 The following are <EM CLASS="Optional-meta-syntax">
 types</EM>
  of valid RRs (some of these listed, although not obsolete, are experimental (x) or historical (h) and no longer in general use):</P>
@@ -4438,13 +4702,13 @@ types</EM>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998336">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998338">
-</A>
+ </A>
 a host address.</P>
 </TD>
 </TR>
@@ -4452,13 +4716,13 @@ a host address.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998340">
-</A>
+ </A>
 A6</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998342">
-</A>
+ </A>
 an IPv6 address.</P>
 </TD>
 </TR>
@@ -4466,13 +4730,13 @@ an IPv6 address.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998344">
-</A>
+ </A>
 AAAA</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998346">
-</A>
+ </A>
 Obsolete format of IPv6 address</P>
 </TD>
 </TR>
@@ -4480,13 +4744,13 @@ Obsolete format of IPv6 address</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998348">
-</A>
+ </A>
 AFSDB</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998350">
-</A>
+ </A>
 (x) location of AFS database servers. Experimental.</P>
 </TD>
 </TR>
@@ -4494,13 +4758,13 @@ AFSDB</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998352">
-</A>
+ </A>
 CNAME</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998354">
-</A>
+ </A>
 identifies the canonical name of an alias.</P>
 </TD>
 </TR>
@@ -4508,13 +4772,13 @@ identifies the canonical name of an alias.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998356">
-</A>
+ </A>
 DNAME</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998358">
-</A>
+ </A>
 for delegation of reverse addresses. Replaces the domain name specified with another name to be looked up. Described in RFC 2672.</P>
 </TD>
 </TR>
@@ -4522,13 +4786,13 @@ for delegation of reverse addresses. Replaces the domain name specified with ano
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998360">
-</A>
+ </A>
 HINFO</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998362">
-</A>
+ </A>
 identifies the CPU and OS used by a host.</P>
 </TD>
 </TR>
@@ -4536,13 +4800,13 @@ identifies the CPU and OS used by a host.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998364">
-</A>
+ </A>
 ISDN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998366">
-</A>
+ </A>
 (x) representation of ISDN addresses. Experimental.</P>
 </TD>
 </TR>
@@ -4550,13 +4814,13 @@ ISDN</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998368">
-</A>
+ </A>
 KEY</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998370">
-</A>
+ </A>
 stores a public key associated with a DNS name.</P>
 </TD>
 </TR>
@@ -4564,13 +4828,13 @@ stores a public key associated with a DNS name.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998372">
-</A>
+ </A>
 LOC</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998374">
-</A>
+ </A>
 (x) for storing GPS info. See RFC 1876. Experimental.</P>
 </TD>
 </TR>
@@ -4578,13 +4842,13 @@ LOC</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998376">
-</A>
+ </A>
 MX</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998378">
-</A>
+ </A>
 identifies a mail exchange for the domain.  See RFC 974 for details.</P>
 </TD>
 </TR>
@@ -4592,13 +4856,13 @@ identifies a mail exchange for the domain.  See RFC 974 for details.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998380">
-</A>
+ </A>
 NS</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998382">
-</A>
+ </A>
 the authoritative nameserver for the domain.</P>
 </TD>
 </TR>
@@ -4606,13 +4870,13 @@ the authoritative nameserver for the domain.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998384">
-</A>
+ </A>
 NXT</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998386">
-</A>
+ </A>
 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. See RFC 2535 for details.</P>
 </TD>
 </TR>
@@ -4620,13 +4884,13 @@ used in DNSSEC to securely indicate that RRs with an owner name in a certain nam
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998388">
-</A>
+ </A>
 PTR</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998390">
-</A>
+ </A>
 a pointer to another part of the domain name space.</P>
 </TD>
 </TR>
@@ -4634,13 +4898,13 @@ a pointer to another part of the domain name space.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998392">
-</A>
+ </A>
 RP</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998394">
-</A>
+ </A>
 (x) information on persons responsible for the domain. Experimental.</P>
 </TD>
 </TR>
@@ -4648,13 +4912,13 @@ RP</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998396">
-</A>
+ </A>
 RT</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998398">
-</A>
+ </A>
 (x) route-through binding for hosts that do not have their own direct wide area network addresses. Experimental.</P>
 </TD>
 </TR>
@@ -4662,13 +4926,13 @@ RT</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998400">
-</A>
+ </A>
 SIG</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998402">
-</A>
+ </A>
 (&quot;signature&quot;) contains data authenticated in the secure DNS. See RFC 2535 for details.</P>
 </TD>
 </TR>
@@ -4676,13 +4940,13 @@ SIG</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998404">
-</A>
+ </A>
 SOA</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998406">
-</A>
+ </A>
 identifies the start of a zone of authority.</P>
 </TD>
 </TR>
@@ -4690,13 +4954,13 @@ identifies the start of a zone of authority.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998408">
-</A>
+ </A>
 SRV</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998410">
-</A>
+ </A>
 information about well known network services (replaces WKS).</P>
 </TD>
 </TR>
@@ -4704,13 +4968,13 @@ information about well known network services (replaces WKS).</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998412">
-</A>
+ </A>
 WKS</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998414">
-</A>
+ </A>
 (h) information about which well known network services, such as SMTP, that a domain supports. Historical, replaced by newer RR SRV.</P>
 </TD>
 </TR>
@@ -4718,20 +4982,20 @@ WKS</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998416">
-</A>
+ </A>
 X25</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998418">
-</A>
+ </A>
 (x) representation of X.25 network addresses. Experimental.</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998431">
-</A>
+ </A>
 The following <EM CLASS="Optional-meta-syntax">
 classes</EM>
  of resource records are currently valid in the DNS:</P>
@@ -4740,30 +5004,30 @@ classes</EM>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998421">
-</A>
+ </A>
 IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998423">
-</A>
+ </A>
 the Internet system.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="2">
 <P CLASS="CellBody">
-<A NAME="pgfId=998427">
-</A>
-For information about other, older classes of RRs, <A HREF="BV9ARM.8.html#13688" CLASS="XRef">
-See Historical DNS Information.</A>
-.</P>
+<A NAME="pgfId=1030860">
+ </A>
+For information about other, older classes of RRs, see <A HREF="Bv9ARM.7.html#13688" CLASS="XRef">
+Historical DNS Information</A>
+ of Appendix B .</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998432">
-</A>
+ </A>
 <EM CLASS="Optional-meta-syntax">
 RDATA</EM>
  is the type-dependent or class-dependent data that describes the resource:</P>
@@ -4772,13 +5036,13 @@ RDATA</EM>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998435">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998437">
-</A>
+ </A>
 for the IN class, a 32 bit IP address</P>
 </TD>
 </TR>
@@ -4786,13 +5050,13 @@ for the IN class, a 32 bit IP address</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998439">
-</A>
+ </A>
 A6</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998441">
-</A>
+ </A>
 maps a domain name to an IPv6 address, with a provision for indirection for leading &quot;prefix&quot; bits.</P>
 </TD>
 </TR>
@@ -4800,13 +5064,13 @@ maps a domain name to an IPv6 address, with a provision for indirection for lead
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998443">
-</A>
+ </A>
 CNAME</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998445">
-</A>
+ </A>
 a domain name</P>
 </TD>
 </TR>
@@ -4814,13 +5078,13 @@ a domain name</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998447">
-</A>
+ </A>
 DNAME</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998449">
-</A>
+ </A>
 provides alternate naming to an entire subtree of the domain name space, rather than to a single node.  It causes some suffix of a queried name to be substituted with a name from the DNAME record's RDATA.</P>
 </TD>
 </TR>
@@ -4828,13 +5092,13 @@ provides alternate naming to an entire subtree of the domain name space, rather
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998451">
-</A>
+ </A>
 MX</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998453">
-</A>
+ </A>
 a 16 bit preference value (lower is better) followed by a host name willing to act as a mail exchange for the owner domain.</P>
 </TD>
 </TR>
@@ -4842,13 +5106,13 @@ a 16 bit preference value (lower is better) followed by a host name willing to a
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998455">
-</A>
+ </A>
 NS</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998457">
-</A>
+ </A>
 a fully qualified domain name.</P>
 </TD>
 </TR>
@@ -4856,13 +5120,13 @@ a fully qualified domain name.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998459">
-</A>
+ </A>
 PTR</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998461">
-</A>
+ </A>
 a fully qualified doman name.</P>
 </TD>
 </TR>
@@ -4870,75 +5134,75 @@ a fully qualified doman name.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998463">
-</A>
+ </A>
 SOA</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998465">
-</A>
+ </A>
 several fields.</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998466">
-</A>
+ </A>
 The owner name is often implicit, rather than forming an integral part of the RR.  For example, many nameservers 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998467">
-</A>
+ </A>
 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998468">
-</A>
+ </A>
 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 &quot;pointers&quot; to other data in the DNS.</P>
 </DIV>
 <DIV>
 <OL>
 <H5 CLASS="4Level">
 <A NAME="pgfId=998469">
-</A>
+ </A>
 5.3.1.2	Textual expression of RRs</H5>
 </OL>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998470">
-</A>
+ </A>
 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 nameserver 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998471">
-</A>
+ </A>
 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998472">
-</A>
+ </A>
 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998473">
-</A>
+ </A>
 The resource data or RDATA section of the RR are given using knowledge of the typical representation for the data.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998511">
-</A>
+ </A>
 For example, we might show the RRs carried in a message as: </P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998476">
-</A>
+ </A>
 ISI.EDU.</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998478">
-</A>
+ </A>
 MX</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998480">
-</A>
+ </A>
 10 VENERA.ISI.EDU.</P>
 </TD>
 </TR>
@@ -4946,19 +5210,19 @@ MX</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998482">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998484">
-</A>
+ </A>
 MX</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998486">
-</A>
+ </A>
 10 VAXA.ISI.EDU</P>
 </TD>
 </TR>
@@ -4966,19 +5230,19 @@ MX</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998488">
-</A>
+ </A>
 VENERA.ISI.EDU</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998490">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998492">
-</A>
+ </A>
 128.9.0.32</P>
 </TD>
 </TR>
@@ -4986,19 +5250,19 @@ A</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998494">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998496">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998498">
-</A>
+ </A>
 10.1.0.52</P>
 </TD>
 </TR>
@@ -5006,19 +5270,19 @@ A</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998500">
-</A>
+ </A>
 VAXA.ISI.EDU</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998502">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998504">
-</A>
+ </A>
 10.2.0.27</P>
 </TD>
 </TR>
@@ -5026,53 +5290,53 @@ A</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998506">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998508">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998510">
-</A>
+ </A>
 128.9.0.33</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998512">
-</A>
+ </A>
 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.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998513">
-</A>
+ </A>
 This example shows six RRs, with two RRs at each of three domain names.</P>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998527">
-</A>
+ </A>
 Similarly we might see:</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998516">
-</A>
+ </A>
 XX.LCS.MIT.EDU. IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998518">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998520">
-</A>
+ </A>
 10.0.0.44</P>
 </TD>
 </TR>
@@ -5080,27 +5344,27 @@ A</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998522">
-</A>
+ </A>
 CH</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998524">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998526">
-</A>
+ </A>
 MIT.EDU. 2420</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="4LevelContinued">
 <A NAME="pgfId=998528">
-</A>
-This example shows two addresses for <EM CLASS="URL">
+ </A>
+This example shows two addresses for <EM CLASS="pathname">
 XX.LCS.MIT.EDU</EM>
 , each of a different class.</P>
 </DIV>
@@ -5109,57 +5373,57 @@ XX.LCS.MIT.EDU</EM>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=998529">
-</A>
+ </A>
 5.3.2	Discussion of MX Records</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998530">
-</A>
+ </A>
 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 datum, a domain name matched with relevant data, and stored with some additional type information to help systems determine when the RR is relevant.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998531">
-</A>
+ </A>
 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 <EM CLASS="Optional-meta-syntax">
 must</EM>
  have an associated A record--a CNAME is not sufficient.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998532">
-</A>
+ </A>
 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.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998584">
-</A>
+ </A>
 For example:</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998535">
-</A>
+ </A>
 example.com.</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998537">
-</A>
+ </A>
 IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998539">
-</A>
+ </A>
 MX</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998541">
-</A>
+ </A>
 10</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998543">
-</A>
+ </A>
 mail.foo.com.</P>
 </TD>
 </TR>
@@ -5167,31 +5431,31 @@ mail.foo.com.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998545">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998547">
-</A>
+ </A>
 IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998549">
-</A>
+ </A>
 MX</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998551">
-</A>
+ </A>
 10</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998553">
-</A>
+ </A>
 mail2.foo.com.</P>
 </TD>
 </TR>
@@ -5199,31 +5463,31 @@ mail2.foo.com.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998555">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998557">
-</A>
+ </A>
 IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998559">
-</A>
+ </A>
 MX</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998561">
-</A>
+ </A>
 20</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998563">
-</A>
+ </A>
 mail.backup.org.</P>
 </TD>
 </TR>
@@ -5231,31 +5495,31 @@ mail.backup.org.</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998565">
-</A>
+ </A>
 mail.example.com.</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998567">
-</A>
+ </A>
 IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998569">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998571">
-</A>
+ </A>
 10.0.0.1</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998573">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 </TR>
@@ -5263,71 +5527,73 @@ A</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998575">
-</A>
+ </A>
 mail2.example.com.</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998577">
-</A>
+ </A>
 IN</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998579">
-</A>
+ </A>
 A</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998581">
-</A>
+ </A>
 10.0.0.2</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody-fixedfontLG">
 <A NAME="pgfId=998583">
-</A>
+ </A>
 &nbsp;</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998585">
-</A>
+ </A>
 Mail delivery will be attempted to mail.foo.com and mail2.foo.com (in any order), and if neither of those succeed, delivery to mail.backup.org will be attempted.</P>
 </DIV>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=998586">
-</A>
-5.3.3	Setting TTLs</H4>
+ </A>
+5.3.3	<A NAME="19693">
+ </A>
+Setting TTLs</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998587">
-</A>
+ </A>
 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.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998602">
-</A>
+ </A>
 &nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998590">
-</A>
+ </A>
 SOA</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998592">
-</A>
+ </A>
 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.</P>
 <P CLASS="CellBody">
 <A NAME="pgfId=998593">
-</A>
+ </A>
 The maximum time for negative caching is 3 hours (3h).</P>
 </TD>
 </TR>
@@ -5335,13 +5601,13 @@ The maximum time for negative caching is 3 hours (3h).</P>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998595">
-</A>
+ </A>
 $TTL</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998597">
-</A>
+ </A>
 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.</P>
 </TD>
 </TR>
@@ -5349,20 +5615,20 @@ The $TTL directive at the top of the zone file (before the SOA) gives a default
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998599">
-</A>
+ </A>
 RR TTLs</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
 <A NAME="pgfId=998601">
-</A>
+ </A>
 Each RR can have a TTL as the second field in the RR, which will control how long other servers can cache the it.</P>
 </TD>
 </TR>
 </TABLE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998603">
-</A>
+ </A>
 All of these TTLs default to units of seconds, though units can be explicitly specified, e.g. <EM CLASS="Optional-meta-syntax">
 1h30m</EM>
 . </P>
@@ -5371,12 +5637,12 @@ All of these TTLs default to units of seconds, though units can be explicitly sp
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=998604">
-</A>
+ </A>
 5.3.4	Inverse Mapping in IPv4</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998605">
-</A>
+ </A>
 Reverse name resolution (i.e., translation from IP address to name) is achieved by means of the in-addr.arpa domain and PTR records. Entries in the in-addr.arpa domain are made in least-to-most significant order, read left to right. This is the opposite order to the way IP addresses are usually written. Thus, a machine with an IP address of 10.1.2.3 would have a corresponding in-addr.arpa name of<BR>
 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 <EM CLASS="Optional-meta-syntax">
 example.com</EM>
@@ -5386,7 +5652,7 @@ $ORIGIN      2.1.10.in-addr.arpa
 3            IN PTR foo.example.com.</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998607">
-</A>
+ </A>
 (Note: The <CODE CLASS="Program-Process">
 $ORIGIN</CODE>
  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.)</P>
@@ -5395,16 +5661,16 @@ $ORIGIN</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=998608">
-</A>
+ </A>
 5.3.5	Other Zone File Directives</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998609">
-</A>
+ </A>
 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.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998610">
-</A>
+ </A>
 Master File Directives include <CODE CLASS="Program-Process">
 $ORIGIN</CODE>
 , <CODE CLASS="Program-Process">
@@ -5424,8 +5690,7 @@ $ORIGIN</CODE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998612">
 </A>
-Syntax: <CODE CLASS="Program-Process">
-$ORIGIN &lt;domain-name&gt; [&lt;comment&gt;]</CODE>
+Syntax: <CODE>$ORIGIN &lt; <EM>domain-name</EM> &gt; [&lt;<EM>comment</EM>&gt;]</CODE>
 </P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998613">
@@ -5434,22 +5699,29 @@ $ORIGIN &lt;domain-name&gt; [&lt;comment&gt;]</CODE>
 $ORIGIN </CODE>
 sets the domain name that will be appended to any unqualified records. When a zone is first read in there is an implicit <CODE CLASS="Program-Process">
 $ORIGIN </CODE>
-&lt;zone-name&gt;<CODE CLASS="Program-Process">
+&lt;<EM CLASS="variable">
+zone-name</EM>
+&gt;<CODE CLASS="Program-Process">
 .</CODE>
  The current <CODE CLASS="Program-Process">
 $ORIGIN</CODE>
  is appended to the domain specified in the <CODE CLASS="Program-Process">
 $ORIGIN</CODE>
  argument if it is not absolute.</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=998614"></A>
-$ORIGIN EXAMPLE.COM
-WWW     CNAME   MAIN-SERVER</PRE>
+ 
+<PRE>
+<CODE>$ORIGIN example.com
+WWW     CNAME   MAIN-SERVER</CODE>
+</PRE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998615">
 </A>
 is equivalent to</P>
-<PRE CLASS="3Level-fixed"><A NAME="pgfId=998616"></A>
-WWW.EXAMPLE.COM CNAME MAIN-SERVER.EXAMPLE.COM.</PRE>
+ 
+<PRE>
+<CODE>WWW.EXAMPLE.COM CNAME MAIN-SERVER.EXAMPLE.COM.
+</CODE>
+</PRE>
 </DIV>
 <DIV>
 <OL>
@@ -5463,14 +5735,15 @@ $INCLUDE</CODE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998618">
 </A>
-Syntax: <CODE CLASS="Program-Process">
-$INCLUDE &lt;filename&gt; [&lt;origin&gt;] [&lt;comment&gt;]</CODE>
+<PRE>
+Syntax: <CODE>$INCLUDE &lt filename&gt; [&lt; origin&gt;] [&lt;comment&gt;]</CODE>
+</PRE>
 </P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998619">
 </A>
-Read and process the file <CODE CLASS="Program-Process">
-filename</CODE>
+Read and process the file <EM CLASS="pathname">
+filename</EM>
  as if it were included into the file at this point.  If <CODE CLASS="Program-Process">
 origin</CODE>
  is specified the file is processed with <CODE CLASS="Program-Process">
@@ -5481,9 +5754,9 @@ $ORIGIN</CODE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998620">
 </A>
-<EM CLASS="Optional-meta-syntax">
-NOTE</EM>
-: The behavior when <CODE CLASS="Program-Process">
+<EM CLASS="Emphasis">
+NOTE:</EM>
+ The behavior when <CODE CLASS="Program-Process">
 origin</CODE>
  is specified differs from that described in RFC&nbsp;1035. The origin and current domain revert to the values they were prior to the <CODE CLASS="Program-Process">
 $INCLUDE</CODE>
@@ -5501,8 +5774,10 @@ $TTL</CODE>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998622">
 </A>
-Syntax: <CODE CLASS="Program-Process">
-$TTL &lt;default-ttl&gt; [&lt;comment&gt;]</CODE>
+<PRE>
+<CODE>Syntax: $TTL &lt;default-ttl&gt; [&lt;comment&gt;]
+</CODE>
+</PRE>
 </P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998623">
@@ -5531,7 +5806,33 @@ $GENERATE</PRE>
 <A NAME="pgfId=998627">
 </A>
 Syntax: <CODE CLASS="Program-Process">
-$GENERATE &lt;range&gt; &lt;lhs&gt; &lt;type&gt; &lt;rhs&gt; [&lt;comment&gt;]</CODE>
+$GENERATE &lt;</CODE>
+<EM CLASS="variable">
+range</EM>
+<CODE CLASS="Program-Process">
+&gt; &lt;</CODE>
+<EM CLASS="variable">
+lhs</EM>
+<CODE CLASS="Program-Process">
+&gt; &lt;</CODE>
+<EM CLASS="variable">
+type</EM>
+<CODE CLASS="Program-Process">
+&gt; &lt;</CODE>
+<EM CLASS="variable">
+rhs</EM>
+<CODE CLASS="Program-Process">
+&gt; </CODE>
+<EM CLASS="Optional-meta-syntax">
+[</EM>
+<CODE CLASS="Program-Process">
+&lt;</CODE>
+<EM CLASS="variable">
+comment</EM>
+<CODE CLASS="Program-Process">
+&gt;</CODE>
+<EM CLASS="Optional-meta-syntax">
+]</EM>
 </P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=998628">
@@ -5566,12 +5867,12 @@ is equivalent to</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998634">
 </A>
 <CODE CLASS="Program-Process">
 range</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
@@ -5582,12 +5883,12 @@ This can be one of two forms: start-stop or start-stop/step. If the first form i
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998638">
 </A>
 <CODE CLASS="Program-Process">
 lhs</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
@@ -5612,12 +5913,12 @@ is appended to the name.</P>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998642">
 </A>
 <CODE CLASS="Program-Process">
 type</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
@@ -5628,12 +5929,12 @@ At present the only supported types are PTR, CNAME and NS.</P>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
+<P CLASS="CellBody">
 <A NAME="pgfId=998646">
 </A>
 <CODE CLASS="Program-Process">
 rhs</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
@@ -5665,23 +5966,23 @@ It is not yet implemented in BINDv9.</EM>
 Certain UNIX signals cause the name server to take specific actions, as described in the following table.  These signals can be sent using the <CODE CLASS="Program-Process">
 kill</CODE>
  command.</P>
-<P CLASS="Body">
-<A NAME="pgfId=997347">
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1073295">
 </A>
- &nbsp;</P>
+&nbsp;</P>
 <TABLE>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=998654">
+<P CLASS="CellBody">
+<A NAME="pgfId=1073306">
 </A>
 <CODE CLASS="Program-Process">
 SIGHUP</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=998656">
+<A NAME="pgfId=1073308">
 </A>
 Causes the server to read <CODE CLASS="Program-Process">
 named.conf</CODE>
@@ -5690,51 +5991,55 @@ named.conf</CODE>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=998658">
+<P CLASS="CellBody">
+<A NAME="pgfId=1073310">
 </A>
 <CODE CLASS="Program-Process">
 SIGTERM</CODE>
-</H6>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=998660">
+<A NAME="pgfId=1073312">
 </A>
 Causes the server to clean up and exit.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024021">
-</A>
-SIGINT</H6>
+<P CLASS="CellBody">
+<A NAME="pgfId=1073322">
+ </A>
+<CODE CLASS="Program-Process">
+SIGINT</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024023">
+<A NAME="pgfId=1073324">
 </A>
 Causes the server to clean up and exit.</P>
 </TD>
 </TR>
 <TR>
 <TD ROWSPAN="1" COLSPAN="1">
-<H6 CLASS="CellBody21">
-<A NAME="pgfId=1024017">
+<P CLASS="CellBody">
+<A NAME="pgfId=1073326">
 </A>
-SIGQUIT</H6>
+<CODE CLASS="Program-Process">
+SIGQUIT</CODE>
+</P>
 </TD>
 <TD ROWSPAN="1" COLSPAN="1">
 <P CLASS="CellBody">
-<A NAME="pgfId=1024019">
-</A>
+<A NAME="pgfId=1073328">
+ </A>
 Causes the server to clean up and exit.</P>
 </TD>
 </TR>
 </TABLE>
 </DIV>
 </DIV>
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
+<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> 
 </BODY>
 </HTML>
diff --git a/doc/arm/BV9ARM.6.html b/doc/arm/Bv9ARM.6.html
index 1e0348a3..9b70e597 100644..100755
--- a/doc/arm/BV9ARM.6.html
+++ b/doc/arm/Bv9ARM.6.html
@@ -2,27 +2,27 @@
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
 <TITLE> Section 6.	Security Considerations</TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
 <OL>
 <H1 CLASS="1Level">
 <A NAME="pgfId=997350">
-</A>
+ </A>
 Section 6.	Security Considerations</H1>
 </OL>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997352">
-</A>
+ </A>
 6.1	<A NAME="32222">
-</A>
+ </A>
 Access Control Lists</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997353">
-</A>
+ </A>
 Access Control Lists (ACLs), are address match lists that you can set up and nickname for future use in <CODE CLASS="Program-Process">
 allow-query</CODE>
 , <CODE CLASS="Program-Process">
@@ -34,58 +34,63 @@ allow-transfer</CODE>
 , etc.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997354">
-</A>
+ </A>
 Using ACLs allows you to have finer control over who can access your nameserver, without cluttering up your config files with huge lists of IP addresses.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997355">
-</A>
+ </A>
 It is a <EM CLASS="Emphasis">
 good idea</EM>
  to use ACLs, and to control access to your server. Limiting access to your server by outside parties can help prevent spoofing and DoS attacks against your server.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997356">
-</A>
+ </A>
 Here is an example of how to properly apply ACLs:</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997357">
-</A>
+ </A>
 // Set up an ACL named &quot;bogusnets&quot; that will block RFC1918 space,<BR>
 // which is commonly used in spoofing attacks.</P>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997358"></A>
-acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.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; };</PRE>
+ 
+<PRE>
+<CODE>acl bogusnets{ 0.0.0.0/8; 1.0.0.0/8; 2.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; };
+</CODE>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997359">
-</A>
-// Set up an ACL called our-nets.  Replace this with the real IP numbers.</P>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997360"></A>
-acl our-nets { x.x.x.x/24; x.x.x.x/21; }; </PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997361"></A>
+ </A>
+// Set up an ACL called our-nets. Replace this with the real IP numbers.</P>
+ 
+<PRE>
+<CODE>acl our-nets { x.x.x.x/24; x.x.x.x/21; };  
 options {
   ...
   ...
-  allow-query { our-nets; };
-  allow-recursion { our-nets; };
+  allow-query { <VAR>our-nets</VAR>; };
+  allow-recursion { <VAR>our-nets</VAR>; };
   ...
   blackhole { bogusnets; };
   ...
-};</PRE>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997362"></A>
-zone &quot;example.com&quot; {
-  type master;
-  file &quot;m/example.com&quot;;
-  allow-query { any; };
-};</PRE>
+};
+
+zone &quot;<EM>example.com</EM>&quot; {
+  type <VAR>master</VAR>;
+  file &quot;<EM>m/example.com</EM>&quot;;
+  allow-query { <VAR>any</VAR>; };
+};</CODE>
+</PRE>
+
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997363">
-</A>
+ </A>
 This allows recursive queries of the server from the outside unless recursion has been previously disabled.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997364">
-</A>
+ </A>
 For more information on how to use ACLs to protect your server, see the <EM CLASS="Emphasis">
 AUSCERT</EM>
  advisory at<BR>
-<EM CLASS="Emphasis">
+<EM CLASS="URL">
 ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</EM>
 </P>
 </DIV>
@@ -93,7 +98,7 @@ ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</EM>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997365">
-</A>
+ </A>
 6.2	<CODE CLASS="Program-Process">
 chroot</CODE>
  and <CODE CLASS="Program-Process">
@@ -102,7 +107,7 @@ setuid</CODE>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997366">
-</A>
+ </A>
 On UNIX servers, it is possible to run BIND in a <EM CLASS="Emphasis">
 chrooted</EM>
  environment (<CODE CLASS="Program-Process">
@@ -112,15 +117,17 @@ chroot()</CODE>
 &quot; option. This can help improve system security by placing BIND in a &quot;sandbox,&quot; which will limit the damage done if a server is compromised.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997367">
-</A>
+ </A>
 Another useful feature in the UNIX version of BIND is the ability to run the daemon as a nonprivileged user ( <CODE CLASS="Program-Process">
 -u</CODE>
- &lt;user&gt; ). We suggest running as a nonprivileged user when using the <CODE CLASS="Program-Process">
+ &lt;<EM CLASS="variable">
+user</EM>
+&gt; ). We suggest running as a nonprivileged user when using the <CODE CLASS="Program-Process">
 chroot</CODE>
  feature.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997368">
-</A>
+ </A>
 Here is an example command line to load BIND in a <CODE CLASS="Program-Process">
 chroot()</CODE>
  sandbox, <BR>
@@ -131,35 +138,36 @@ named</CODE>
  <CODE CLASS="Program-Process">
 setuid</CODE>
  to user 202:</P>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997369"></A>
-/usr/local/bin/named -u 202 -t /var/named</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997369"></A>
+<KBD CLASS="Literal-user-input">/usr/local/bin/named -u 202 -t /var/named</KBD>
+</PRE>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997370">
-</A>
+ </A>
 6.2.1	The <CODE CLASS="Program-Process">
 chroot</CODE>
- environment</H4>
+ Environment</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997371">
-</A>
+ </A>
 In order for a <CODE CLASS="Program-Process">
 chroot()</CODE>
- environment to work properly in a particular directory (e.g. <EM CLASS="pathname">
+ environment to work properly in a particular directory (e.g., <EM CLASS="pathname">
 /var/named</EM>
 ), you will need to set up an environment that includes everything BIND needs to run. From BIND's point of view, <EM CLASS="pathname">
 /var/named</EM>
  is the root of the filesystem. You will need <EM CLASS="pathname">
 /dev/null</EM>
-, and any library directories and files that BIND needs to run on your system.  Please consult your operating system's instructions if you need help figuring out which library files you need to copy over to the <CODE CLASS="Program-Process">
+, and any library directories and files that BIND needs to run on your system. Please consult your operating system's instructions if you need help figuring out which library files you need to copy over to the <CODE CLASS="Program-Process">
 chroot()</CODE>
  sandbox.</P>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997372">
-</A>
-If you are running an operating system that supports static binaries, you can also compile BIND staticly and avoid the need to copy system libraries over to your <CODE CLASS="Program-Process">
+ </A>
+If you are running an operating system that supports static binaries, you can also compile BIND statically and avoid the need to copy system libraries over to your <CODE CLASS="Program-Process">
 chroot()</CODE>
  sandbox.</P>
 </DIV>
@@ -167,14 +175,14 @@ chroot()</CODE>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997373">
-</A>
-6.2.2	Using <CODE CLASS="Program-Process">
+ </A>
+6.2.2	Using the <CODE CLASS="Program-Process">
 setuid</CODE>
-</H4>
+ Function </H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997374">
-</A>
+ </A>
 Prior to running the <CODE CLASS="Program-Process">
 named</CODE>
  daemon, use the <CODE CLASS="Program-Process">
@@ -188,18 +196,18 @@ chown</CODE>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997375">
-</A>
-6.3	Dynamic updates</H3>
+ </A>
+6.3	Dynamic Updates</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997376">
-</A>
+ </A>
 Access to the dynamic update facility should be strictly limited. In earlier versions of BIND the only way to do this was based on the IP address of the host requesting the update. BINDv9 also supports authenticating updates cryptographically by means of transaction signatures (TSIG). The use of TSIG is strongly recommended.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1006806">
-</A>
+ </A>
 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.</P>
 </DIV>
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
+<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> 
 </BODY>
 </HTML>
diff --git a/doc/arm/BV9ARM.7.html b/doc/arm/Bv9ARM.7.html
index 322ee560..ece6c8f6 100644..100755
--- a/doc/arm/BV9ARM.7.html
+++ b/doc/arm/Bv9ARM.7.html
@@ -2,177 +2,225 @@
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
 <TITLE> Section 7.	Troubleshooting</TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
 <OL>
 <H1 CLASS="1Level">
 <A NAME="pgfId=997350">
-</A>
+ </A>
 Section 7.	Troubleshooting</H1>
 </OL>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997351">
-</A>
+ </A>
 7.1	Common Log Messages and What They Mean</H3>
 </OL>
 <DIV>
 <UL>
 <H6 CLASS="Subhead2">
 <A NAME="pgfId=997352">
-</A>
+ </A>
 lame server</H6>
 </UL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997353"></A>
-ns named[111]: Lame server on 'www.foo.com' (in 'foo.com'?): [192.168.0.2].53 'ns2.foo.com'</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997353"> </A>
+<EM CLASS="grammar_literal">ns named[111]: Lame server on 'www.foo.com' (in 'foo.com'?): [192.168.0.2].53 'ns2.foo.com'</EM>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997354">
-</A>
-This is a harmless error message. It means that the server at 192.168.0.2 (ns2.foo.com) is listed as a nameserver for &quot;foo.com&quot;, but it doesn't really know anything about foo.com.</P>
+ </A>
+This is a harmless error message. It means that the server at 192.168.0.2 (<EM CLASS="pathname">
+ns2.foo.com</EM>
+) is listed as a nameserver for &quot;<EM CLASS="pathname">
+foo.com</EM>
+&quot;, but it doesn't really know anything about <EM CLASS="pathname">
+foo.com</EM>
+.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997355">
-</A>
+ </A>
 If this is a zone under your control, check each of the nameservers to ensure that they are configured to answer questions properly.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997356">
-</A>
+ </A>
 If it's a zone out on the Internet, it would be nice to notify the owners of the domain in question so that they can take a look at it. In practice, though, not many people have time to do this.</P>
 </DIV>
 <DIV>
 <UL>
 <H6 CLASS="Subhead2">
 <A NAME="pgfId=997357">
-</A>
+ </A>
 bad referral</H6>
 </UL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997358"></A>
-ns named[111]: bad referral (other.com !&lt; subdomain.other.com)</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997358"> </A>
+<EM CLASS="grammar_literal">ns named[111]: bad referral (other.com !&lt; subdomain.other.com)</EM>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997359">
-</A>
-This indicates that your nameserver (ns.foo.com) queried the nameserver for foo2.com to find out how to get to subdomain.foo2.com. foo2.com told your nameserver that subdomain.foo2.com was delegated to some other.foo2.com, so your nameserver queried that.</P>
+ </A>
+This indicates that your nameserver (<EM CLASS="pathname">
+ns.foo.com</EM>
+) queried the nameserver for <EM CLASS="pathname">
+foo2.com</EM>
+ to find out how to get to <EM CLASS="pathname">
+subdomain.foo2.com</EM>
+. <EM CLASS="pathname">
+foo2.com</EM>
+ told your nameserver that <EM CLASS="pathname">
+subdomain.foo2.com</EM>
+ was delegated to some <EM CLASS="pathname">
+other.foo2.com</EM>
+, so your nameserver queried that.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997360">
-</A>
-someother.foo2.com didn't think that subdomain.foo2.com had been delegated to it, so it referred your server (ns.foo.com) back to the foo2.com nameserver.</P>
+ </A>
+<EM CLASS="pathname">
+someother.foo2.com</EM>
+ didn't think that <EM CLASS="pathname">
+subdomain.foo2.com</EM>
+ had been delegated to it, so it referred your server (<EM CLASS="pathname">
+ns.foo.com</EM>
+) back to the <EM CLASS="pathname">
+foo2.com</EM>
+ nameserver.</P>
 </DIV>
 <DIV>
 <UL>
 <H6 CLASS="Subhead2">
 <A NAME="pgfId=997361">
-</A>
+ </A>
 not authoritative for</H6>
 </UL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997362"></A>
-ns named-xfer[111]: [192.168.0.1] not authoritative for foo.com, SOA query got rcode 0, aa 0, ancount 1, aucount 0</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997362"> </A>
+<EM CLASS="grammar_literal">ns named-xfer[111]: [192.168.0.1] not authoritative for foo.com, SOA query got rcode 0, aa 0, ancount 1, aucount 0</EM>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997363">
-</A>
+ </A>
 This error usually shows up on a slave server. It indicates that the master server is not answering authoritatively for the zone. This usually happens when the zone is rejected (while named is loading) on the master server. Check the logs on the master server. If ancount -- 0, you may be pointing at the wrong master server for the zone.</P>
 </DIV>
 <DIV>
 <UL>
 <H6 CLASS="Subhead2">
 <A NAME="pgfId=997364">
-</A>
+ </A>
 rejected zone</H6>
 </UL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997365"></A>
-ns named[111]: master zone &quot;foo.com&quot; (IN) rejected due to errors (serial111)</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997365"> </A>
+<EM CLASS="grammar_literal">ns named[111]: master zone &quot;foo.com&quot; (IN) rejected due to errors (serial111)</EM>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997366">
-</A>
-This indicates that the foo.com zone was rejected because of an error in the zone file. Check the lines above this error -- named will usually tell you what it didn't like and where to find it in the zone file.</P>
+ </A>
+This indicates that the <EM CLASS="pathname">
+foo.com</EM>
+ zone was rejected because of an error in the zone file. Check the lines above this error. <CODE CLASS="Program-Process">
+named</CODE>
+ will usually tell you what it didn't like and where to find it in the zone file.</P>
 </DIV>
 <DIV>
 <UL>
 <H6 CLASS="Subhead2">
 <A NAME="pgfId=997367">
-</A>
+ </A>
 no NS RRs found</H6>
 </UL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997368"></A>
-ns named[111]: Zone &quot;foo.com&quot; (file foo.com.db): no NS RRs found at zonetop</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997368"> </A>
+<EM CLASS="grammar_literal">ns named[111]: Zone &quot;foo.com&quot; (file foo.com.db): no NS RRs found at zonetop</EM>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997369">
-</A>
-The foo.com.db file is missing NS records at the top of the zone (in the SOA section). Check to make sure they exist and that there is white space (spaces or tabs) in front of them. White spaces matter here.</P>
+ </A>
+The <EM CLASS="pathname">
+foo.com.db</EM>
+ file is missing NS records at the top of the zone (in the SOA section). Check to make sure they exist and that there is white space (spaces or tabs) in front of them. White spaces matter here.</P>
 </DIV>
 <DIV>
 <UL>
 <H6 CLASS="Subhead2">
 <A NAME="pgfId=997370">
-</A>
+ </A>
 no default TTL set</H6>
 </UL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997371"></A>
-ns named[111]: Zone &quot;foo.com&quot; (file foo.com.db): No default TTL set using SOA minimum instead</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997371"> </A>
+<EM CLASS="grammar_literal">ns named[111]: Zone &quot;foo.com&quot; (file foo.com.db): No default TTL set using SOA minimum instead</EM>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997372">
-</A>
-You need to add a $TTL to the top of the foo.com.db zone file. See RFC2308, or section 3.2.3, &quot;Setting TTLs&quot; in this document, for information on how to use $TTL.</P>
+ </A>
+You need to add a $TTL to the top of the <EM CLASS="pathname">
+foo.com.db</EM>
+ zone file. See RFC2308, or <A HREF="Bv9ARM.5.html#19693" CLASS="XRef">
+Setting TTLs</A>
+ in this document, for information on how to use $TTL.</P>
 </DIV>
 <DIV>
 <UL>
 <H6 CLASS="Subhead2">
 <A NAME="pgfId=997373">
-</A>
+ </A>
 no root nameserver for class</H6>
 </UL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997374"></A>
-findns: No root nameservers for class IN?</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997374"> </A>
+<EM CLASS="grammar_literal">findns: No root nameservers for class IN?</EM>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997375">
-</A>
+ </A>
 Your nameserver is having problems finding the root nameservers. Check your root hints file to make sure it is not corrupted. Also, make sure that your nameserver can reach the Internet.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997376">
-</A>
-If you are running an internal root nameserver, make sure it's configured properly and is answering queries.</P>
+ </A>
+If you are running an internal root nameserver, make sure it is configured properly and is answering queries.</P>
 </DIV>
 <DIV>
 <UL>
 <H6 CLASS="Subhead2">
 <A NAME="pgfId=997377">
-</A>
+ </A>
 address already in use</H6>
 </UL>
-<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997378"></A>
-ctl_server: bind: Address already in use</PRE>
+<PRE CLASS="2Level-fixed"><A NAME="pgfId=997378"> </A>
+<EM CLASS="grammar_literal">ctl_server: bind: Address already in use</EM>
+</PRE>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997379">
-</A>
+ </A>
 This usually indicates that another copy of BIND is already running. Verify that you have killed old copies of the daemon.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997380">
-</A>
+ </A>
 This can also pop up if you originally ran named as &quot;root&quot; and now run it as a regular user. named may have left behind an ndc control socket that is owned by root if it crashed, or was not killed gracefully.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997381">
-</A>
-This means that the regular user wouldn't be able to delete it, so it would think named is still running. The solution is to remove any ndc sockets in /usr/local/etc, or /var/run, etc.</P>
+ </A>
+This means that the regular user wouldn't be able to delete it, so it would think named is still running. The solution is to remove any ndc sockets in <EM CLASS="pathname">
+/usr/local/etc</EM>
+, or <EM CLASS="pathname">
+/var/run</EM>
+, etc.</P>
 </DIV>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997382">
-</A>
+ </A>
 7.2	Common Problems</H3>
 </OL>
 <DIV>
 <OL>
 <H4 CLASS="3Level">
 <A NAME="pgfId=997383">
-</A>
+ </A>
 7.2.1	It's not working; how can I figure out what's wrong?</H4>
 </OL>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=997384">
-</A>
-The best solution to solving installation and configuration issues is to take preventative measures by setting up logging files beforehand (see the sample configurations in <A HREF="BvARM.3.html#30164" CLASS="XRef">
+ </A>
+The best solution to solving installation and configuration issues is to take preventative measures by setting up logging files beforehand (see the sample configurations in <A HREF="Bv9ARM.3.html#30164" CLASS="XRef">
 Sample Configuration and Logging</A>
 ). 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.</P>
 </DIV>
@@ -181,49 +229,49 @@ Sample Configuration and Logging</A>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997388">
-</A>
+ </A>
 7.3	Incrementing and Changing the Serial Number</H3>
 </OL>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1001230">
-</A>
+ </A>
 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. A number of people have been testing these numbers for Y2K compliance and have set the number to the year 2000 to see if it will work. They then try to restore the old serial number. This will cause problems, because serial numbers are used to indicate that a zone has been updated. If the serial number on the secondary server is lower than the serial number on the primary, the secondary server will attempt to update its copy of the zone.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997390">
-</A>
+ </A>
 Setting the serial number to a lower number on the primary server than the secondary server means that the secondary will not perform updates to its copy of the zone.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997391">
-</A>
+ </A>
 The solution to this is to add 2147483647 (2^31-1) to the number, reload the zone and make sure all secondaries have updated to the new zone serial number, then reset the number to what you want it to be, and reload the zone again.</P>
 </DIV>
 <DIV>
 <OL>
 <H3 CLASS="2Level">
 <A NAME="pgfId=997392">
-</A>
+ </A>
 7.4	Where Can I Get Help?</H3>
 </OL>
 <P CLASS="2LevelContinued">
-<A NAME="pgfId=997393">
-</A>
+<A NAME="pgfId=1001264">
+ </A>
 The Internet Software Consortium (ISC) offers a wide range of support and service agreements for BIND, DHCP and INN servers. Four levels of premium support are available and each level includes support for all ISC programs, significant discounts on products and training, and a recognized priority on bug fixes and non-funded feature requests. In addition, ISC offers a standard support agreement package which includes services ranging from bug fix announcements to remote support. It also includes training in BIND, DHCP or INN.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=997394">
-</A>
-To discuss arrangements for support, contact
-<a href="mailto: info@isc.org">info@isc.org</A></CODE>
-or visit the ISC web page at 
-<a href="http://www.isc.org/services/support/">the ISC web site</A></EM>
+ </A>
+To discuss arrangements for support, contact <EM CLASS="pathname">
+info@isc.org</EM>
+<CODE CLASS="Program-Process">
+ </CODE>
+or visit the ISC web page at<BR>
+<EM CLASS="URL">
+http://www.isc.org/services/support/</EM>
  to read more.</P>
-<P CLASS="Body">
-<A NAME="pgfId=997347">
-</A>
-&nbsp;</P>
-
+<DIV>
+<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> 
+</DIV>
 </DIV>
 </DIV>
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
 </DIV>
 </BODY>
 </HTML>
diff --git a/doc/arm/BV9ARM.8.html b/doc/arm/Bv9ARM.8.html
index e6fc8cdf..2193ce6a 100644..100755
--- a/doc/arm/BV9ARM.8.html
+++ b/doc/arm/Bv9ARM.8.html
@@ -2,121 +2,135 @@
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
 <TITLE> Appendices</TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
-<OL>
-<H1 CLASS="1Level">
-<A NAME="pgfId=997350">
-</A>
-Appendices</H1>
-</OL>
-
 <DIV>
-<H3 CLASS="AppendixLevel1">
+<H6 CLASS="Title">
+<A NAME="pgfId=997347">
+ </A>
+Appendices</H6>
+<DIV>
+<H6 CLASS="AppendixLevel1">
 <A NAME="pgfId=999043">
-</A>
-Appendix A. Acknowledgements</H3>
+ </A>
+Appendix A. Acknowledgements</H6>
 <DIV>
-<H4 CLASS="AppendixLevel2">
+<H6 CLASS="AppendixLevel2">
 <A NAME="pgfId=1000953">
-</A>
-A Brief History of the DNS and BIND</H4>
+ </A>
+A Brief History of the DNS and BIND</H6>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1000944">
-</A>
+ </A>
 Although the &quot;official&quot; 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 an 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, &quot;Domain Names-Concepts and Facilities,&quot; and RFC 1035, &quot;Domain Names-Implementation and Specification&quot; were published and became the standards upon which all DNS implementations are built.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1000945">
-</A>
+ </A>
 The first working domain name server, called &quot;Jeeves,&quot; was written in 1983-84 by Paul Mockapetris for operation on DEC Tops-20 machines located at the University of Southern California's Information Sciences Institute (USC-ISI) and SRI International's Network Information Center (SRI-NIC). A DNS server for Unix machines, the Berkeley Internet Name Domain (BIND) package, was written soon after by a group of graduate students at the University of California at Berkeley under a grant from the US Defense Advanced Research Projects Administration (DARPA). Versions of BIND through 4.8.3 were maintained by the Computer Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark Painter, David Riggle and Songnian Zhou made up the initial BIND project team. After that, additional work on the software package was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation employee on loan to the CSRG, worked on BIND for 2 years, from 1985 to 1987. Many other people also contributed to BIND development during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently handled by Mike Karels and O. Kure.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1000946">
-</A>
+ </A>
 BIND versions 4.9 and 4.9.1 were released by Digital Equipment Corporation (now Compaq Computer Corporation). Paul Vixie, then a DEC employee, became BIND's primary caretaker. Paul 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.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1000947">
-</A>
+ </A>
 BIND Version 4.9.2 was sponsored by Vixie Enterprises. Paul Vixie became BIND's principal architect/programmer.</P>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1000948">
-</A>
+ </A>
 BIND versions from 4.9.3 onward have been developed and maintained by the Internet Software Consortium with support being provided by ISC's sponsors. As co-architects/programmers, Bob Halley and Paul Vixie released the first production-ready version of BIND version 8 in May 1997.</P>
-<P CLASS="2LevelContinued1">
+<P CLASS="2LevelContinued">
 <A NAME="pgfId=1000986">
-</A>
-BIND development work is made possible today by the sponsorship of several corporations, and by the tireless work efforts of numerous individuals.
-</P>
+ </A>
+BIND development work is made possible today by the sponsorship of several corporations, and by the tireless work efforts of numerous individuals.</P>
 </DIV>
 </DIV>
 <DIV>
-<H3 CLASS="AppendixLevel1">
+<H6 CLASS="AppendixLevel1">
 <A NAME="pgfId=1001064">
-</A>
+ </A>
 <A NAME="13688">
-</A>
-Appendix B. Historical DNS Information</H3>
+ </A>
+Appendix B. Historical DNS Information</H6>
 <DIV>
-<H4 CLASS="AppendixLevel2">
+<H6 CLASS="AppendixLevel2">
 <A NAME="pgfId=1001089">
-</A>
-Classes of resource records</H4>
+ </A>
+Classes of resource records</H6>
 <DIV>
 <H6 CLASS="AppendixLevel3">
-<A NAME="pgfId=1001093">
-</A>
+<A NAME="pgfId=1029256">
+ </A>
 HS = hesiod</H6>
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1029267">
+ </A>
+The <EM CLASS="Optional-meta-syntax">
+hesiod </EM>
+class is an information service developed by MIT's Project Athena. It is used to share information about various systems databases, such as users, groups, printers and so on. The keyword <CODE CLASS="Program-Process">
+hs</CODE>
+ is a synonym for hesiod.</P>
 </DIV>
 <DIV>
 <H6 CLASS="AppendixLevel3">
-<A NAME="pgfId=1001097">
-</A>
+<A NAME="pgfId=1029289">
+ </A>
 CH = chaos</H6>
+<P CLASS="3LevelContinued">
+<A NAME="pgfId=1029290">
+ </A>
+The <CODE CLASS="Program-Process">
+chaos</CODE>
+ class is used to specify zone data for the MIT-developed CHAOSnet, a LAN protocol created in the mid-1970s.</P>
 </DIV>
 </DIV>
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
 </DIV>
 <DIV>
-<H3 CLASS="AppendixLevel1">
-<A NAME="pgfId=1000908">
-</A>
-Appendix C. Bibliography (and Suggested Reading)</H3>
+<H6 CLASS="AppendixLevel1">
+<A NAME="pgfId=1029291">
+ </A>
+<A NAME="35452">
+ </A>
+Appendix C. Bibliography (and Suggested Reading)</H6>
 <DIV>
-<H4 CLASS="AppendixLevel2">
+<H6 CLASS="AppendixLevel2">
 <A NAME="pgfId=999193">
-</A>
-Request for Comments (RFCs)</H4>
+ </A>
+<A NAME="42144">
+ </A>
+C.1 Request for Comments (RFCs)</H6>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=999780">
-</A>
+ </A>
 Specification documents for the Internet protocol suite, including the DNS, are published as part of the Request for Comments (RFCs) series of technical notes. The standards themselvers are defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG). RFCs can be obtained online via FTP at <BR>
 <EM CLASS="URL">
 ftp://www.isi.edu/in-notes/RFCxxx.txt</EM>
  (where <EM CLASS="URL">
 xxx</EM>
  is the number of the RFC). RFCs are also available via the Web at <EM CLASS="URL">
-<a href="http://www.ietf.org/rfc/"> http://www.ietf.org/rfc/</A></EM>
+http://www.ietf.org/rfc/</EM>
 .</P>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999212">
-</A>
+ </A>
 Standards</H6>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999776">
-</A>
+ </A>
 RFC974. Partridge, C. <EM CLASS="doc-title">
 Mail Routing and the Domain System</EM>
-. January 1986. (Standard </P>
-<P CLASS="Bib3">
+. January 1986.</P>
+<P CLASS="Biblio">
 <A NAME="pgfId=999777">
-</A>
+ </A>
 RFC1034.  Mockapetris, P.V.  <EM CLASS="doc-title">
 Domain Names - Concepts and Facilities</EM>
 . P.V. November 1987.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=1000013">
-</A>
+ </A>
 RFC1035.  Mockapetris, P. V. <EM CLASS="doc-title">
 Domain Names - Implementation and Specification</EM>
 . November 1987.</P>
@@ -124,35 +138,37 @@ Domain Names - Implementation and Specification</EM>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999218">
-</A>
+ </A>
+<A NAME="17631">
+ </A>
 Proposed Standards</H6>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999220">
-</A>
+ </A>
 RFC2181. Elz, R., R. Bush. <EM CLASS="doc-title">
 Clarifications to the DNS Specification</EM>
 . July 1997.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999221">
-</A>
+ </A>
 RFC2308. Andrews, M. <EM CLASS="doc-title">
 Negative Caching of DNS Queries</EM>
 . March 1998.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999222">
-</A>
+ </A>
 RFC1995. Ohta, M. <EM CLASS="doc-title">
 Incremental Zone Transfer in DNS</EM>
 . August 1996.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999223">
-</A>
+ </A>
 RFC1996. Vixie, P. <EM CLASS="doc-title">
 A Mechanism for Prompt Notification of Zone Changes</EM>
 . August 1996.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999747">
-</A>
+ </A>
 RFC2136. Vixie, P., S. Thomson, Y. Rekhter, J. Bound. <EM CLASS="doc-title">
 Dynamic Updates in the Domain Name System</EM>
 . April 1997.</P>
@@ -160,31 +176,29 @@ Dynamic Updates in the Domain Name System</EM>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999227">
-</A>
+ </A>
 Proposed Standards Still Under Development</H6>
 <P CLASS="3LevelContinued">
 <A NAME="pgfId=999436">
-</A>
-<EM CLASS="doc-title1">
+ </A>
+<EM CLASS="Emphasis">
 Note:</EM>
- the following list of RFCs are undergoing major revision by the IETF. (See the Internet Drafts section below
-for current versions.)
-</P>
-<P CLASS="Bib3">
+ the following list of RFCs are undergoing major revision by the IETF. (See the Internet Drafts section, below, for current versions).</P>
+<P CLASS="Biblio">
 <A NAME="pgfId=999230">
-</A>
+ </A>
 RFC1886. Thomson, S., C. Huitema. <EM CLASS="doc-title">
 DNS Extensions to support IP version 6</EM>
 . S. December 1995.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999231">
-</A>
+ </A>
 RFC2065. Eastlake, 3rd, D., C. Kaufman. <EM CLASS="doc-title">
 Domain Name System Security Extensions</EM>
 . January 1997.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999232">
-</A>
+ </A>
 RFC2137. Eastlake, 3rd,  D. <EM CLASS="doc-title">
 Secure Domain Name System Dynamic Update</EM>
 . April 1997.</P>
@@ -192,23 +206,23 @@ Secure Domain Name System Dynamic Update</EM>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999235">
-</A>
+ </A>
 Other Important RFCs About DNS Implementation</H6>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999237">
-</A>
+ </A>
 RFC1535. Gavron, E. <EM CLASS="doc-title">
 A Security Problem and Proposed Correction With Widely Deployed DNS Software.</EM>
  October 1993.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=1000173">
-</A>
+ </A>
 RFC1536. Kumar, A., J. Postel, C. Neuman, P. Danzig, S. Miller. <EM CLASS="doc-title">
 Common DNS Implementation Errors and Suggested Fixes</EM>
 . October 1993.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999239">
-</A>
+ </A>
 RFC1982. Elz, R., R. Bush. <EM CLASS="doc-title">
 Serial Number Arithmetic</EM>
 . August 1996.</P>
@@ -216,53 +230,47 @@ Serial Number Arithmetic</EM>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999242">
-</A>
+ </A>
 Resource Record Types</H6>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999244">
-</A>
+ </A>
 RFC1183. Everhart, C.F., L. A. Mamakos, R. Ullmann, P. Mockapetris.  <EM CLASS="doc-title">
 New DNS RR Definitions</EM>
 . October 1990.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999249">
-</A>
+ </A>
 RFC1706. Manning, B., R. Colella. <EM CLASS="doc-title">
 DNS NSAP Resource Records</EM>
 . October 1994.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999253">
-</A>
+ </A>
 RFC2168. Danie1,R.,  M. Mealling. <EM CLASS="doc-title">
 Resolution of Uniform Resource Identifiers using the Domain Name System. June 1997.</EM>
 </P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999254">
-</A>
+ </A>
 RFC1876. Davis, C., P. Vixie, T. Goodwin, I. Dickinson. <EM CLASS="doc-title">
 A Means for Expressing Location Information in the Domain Name System</EM>
 . January 1996.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999255">
-</A>
+ </A>
 RFC2052. Gulbrandsen,A., P. Vixie. <EM CLASS="doc-title">
 A DNS RR for Specifying the Location of Services.</EM>
  October 1996.</P>
 <P CLASS="Bib31">
 <A NAME="pgfId=1000261">
-</A>
-<EM CLASS="CharFmt">
-RFC2163. Allocchio, A. U</EM>
-<EM CLASS="doc-title">
+ </A>
+RFC2163. Allocchio, A. U<EM CLASS="doc-title">
 sing the Internet DNS to Distribute MIXER Conformant Global Address Mapping</EM>
-<EM CLASS="CharFmt1">
-.</EM>
-<EM CLASS="CharFmt">
-January 1998.</EM>
-</P>
-<P CLASS="Bib3">
+.January 1998.</P>
+<P CLASS="Biblio">
 <A NAME="pgfId=1000251">
-</A>
+ </A>
 RFC2230. Atkinson, R. <EM CLASS="doc-title">
 Key Exchange Delegation Record for the DNS</EM>
 .  October 1997.</P>
@@ -270,29 +278,29 @@ Key Exchange Delegation Record for the DNS</EM>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999260">
-</A>
+ </A>
 DNS and the Internet</H6>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999262">
-</A>
+ </A>
 RFC1101. Mockapetris, P. V. <EM CLASS="doc-title">
 Dns Encoding of Network Names and Other Types</EM>
 . April 1989.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999263">
-</A>
+ </A>
 RFC1123.  Braden, R. <EM CLASS="doc-title">
 Requirements for Internet Hosts - Application and Support</EM>
 . October 1989.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999264">
-</A>
+ </A>
 RFC1591. Postel, J. D<EM CLASS="doc-title">
 omain Name System Structure and Delegation</EM>
 . March 1994.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999265">
-</A>
+ </A>
 RFC2317. Eidnes, H., G. de Groot, P. Vixie. <EM CLASS="doc-title">
 Classless IN-ADDR.ARPA Delegation</EM>
 . March 1998.</P>
@@ -300,29 +308,29 @@ Classless IN-ADDR.ARPA Delegation</EM>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999274">
-</A>
+ </A>
 DNS Operations</H6>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999276">
-</A>
+ </A>
 RFC1537. Beertema, P. <EM CLASS="doc-title">
 Common DNS Data File Configuration Errors</EM>
 . October 1993.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999277">
-</A>
+ </A>
 RFC1912. Barr, D. <EM CLASS="doc-title">
 Common DNS Operational and Configuration Errors</EM>
 . February 1996.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=1000360">
-</A>
+ </A>
 RFC2182. Elz, R. R. Bush, S. Bradner, M. Patton. <EM CLASS="doc-title">
 Selection and Operation of Secondary DNS Servers</EM>
 . July 1997.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=1000361">
-</A>
+ </A>
 RFC2219. Hamilton, M., R. Wright. <EM CLASS="doc-title">
 Use of DNS Aliases for Network Services.</EM>
  October 1997.</P>
@@ -330,86 +338,90 @@ Use of DNS Aliases for Network Services.</EM>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999282">
-</A>
+ </A>
 Other DNS-related RFCs</H6>
-<P CLASS="3LevelContinued1">
+</DIV>
+</DIV>
+</DIV>
+</DIV>
+<DIV>
+<H6 CLASS="3LevelContinued1">
 <A NAME="pgfId=999409">
-</A>
+ </A>
 <EM CLASS="doc-title">
 Note:</EM>
- the following list of RFCs, although DNS-related, are not concerned with implementing software.</P>
-<P CLASS="Bib3">
+ the following list of RFCs, although DNS-related, are not concerned with implementing software.</H6>
+<P CLASS="Biblio">
 <A NAME="pgfId=999284">
-</A>
+ </A>
 RFC1464. Rosenbaum, R. <EM CLASS="doc-title">
 Using the Domain Name System To Store Arbitrary String Attributes</EM>
 . May 1993.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999285">
-</A>
+ </A>
 RFC1713. Romao, A. <EM CLASS="doc-title">
 Tools for DNS Debugging</EM>
 . November 1994.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999286">
-</A>
+ </A>
 RFC1794. Brisco, T. <EM CLASS="doc-title">
 DNS Support for Load Balancing</EM>
 . April 1995.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999287">
-</A>
+ </A>
 RFC2240. Vaughan, O. <EM CLASS="doc-title">
 A Legal Basis for Domain Name Allocation</EM>
 . November1997.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999288">
-</A>
+ </A>
 RFC2345. Klensin, J., T. Wolf, G. Oglesby. <EM CLASS="doc-title">
 Domain Names and Company Name Retrieval</EM>
 . May 1998.</P>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999289">
-</A>
+ </A>
 RFC2352. Vaughan, O. <EM CLASS="doc-title">
 A Convention For Using Legal Names as Domain Names</EM>
 . May 1998.</P>
-</DIV>
 <DIV>
 <H6 CLASS="AppendixLevel3">
 <A NAME="pgfId=999292">
-</A>
+ </A>
 Obsolete and Unimplemented Experimental RRs</H6>
-<P CLASS="Bib3">
+<P CLASS="Biblio">
 <A NAME="pgfId=999294">
-</A>
+ </A>
 RFC1712. Farrell, C., M. Schulze, S. Pleitner, D. Baldoni. <EM CLASS="doc-title">
 DNS Encoding of Geographical Location</EM>
 . November 1994.</P>
 </DIV>
-</DIV>
 <DIV>
 <H6 CLASS="AppendixLevel2">
 <A NAME="pgfId=999195">
-</A>
+ </A>
 <A NAME="">
-</A>
-Internet Drafts</H6>
+ </A>
+C.2 Internet Drafts</H6>
 <P CLASS="2LevelContinued">
 <A NAME="pgfId=1000609">
-</A>
+ </A>
 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 &quot;works in progress.&quot; IDs have a lifespan of six months after which they are deleted unless updated by their authors.</P>
-<P CLASS="2LevelContinued1">
+<P CLASS="2LevelContinued">
 <A NAME="pgfId=1000433">
-</A>
-IDs can be obtained via FTP from
-<a href="ftp://www.isi.edu/internet-drafts/">ftp://www.isi.edu/internet-drafts/</A>
- or from
-<a href="http://www.ietf.org/1id-abstracts.html">http://www.ietf.org/1id-abstracts.html</A>.
-</P>
-<P CLASS="2LevelContinued2">
+ </A>
+IDs can be obtained via FTP from<BR>
+<EM CLASS="URL">
+ftp://www.isi.edu/internet-drafts/</EM>
+ or from <EM CLASS="URL">
+http://www.ietf.org/1id-abstracts.html</EM>
+.</P>
+<P CLASS="2LevelContinued">
 <A NAME="pgfId=1000877">
-</A>
+ </A>
 <EM CLASS="doc-title">
 draft-duerst-dns-i18n-01.txt<BR>
 draft-ietf-dhc-dhcp-dns-10.txt<BR>
@@ -448,17 +460,17 @@ draft-skwan-utf8-dns-02.txt</EM>
 <DIV>
 <H6 CLASS="AppendixLevel2">
 <A NAME="pgfId=999464">
-</A>
-Electronic Mail Communication</H6>
+ </A>
+C.3 Electronic Mail Communication</H6>
 <P CLASS="Bib2">
 <A NAME="pgfId=1001024">
-</A>
+ </A>
 Wellington, Brian (bwellington@tislabs.com). <EM CLASS="doc-title">
 DNSSEC usage document</EM>
 . E-mail to David Conrad (David_Conrad@isc.org). 15 March 1999.</P>
 <P CLASS="Bib2">
 <A NAME="pgfId=1001025">
-</A>
+ </A>
 Wellington, Brian (bwellington@tislabs.com). <EM CLASS="doc-title">
 TSIG guide for BIND 8.2+</EM>
 . E-mail to private mailing list (private communication). 22 April 1999.</P>
@@ -466,16 +478,17 @@ TSIG guide for BIND 8.2+</EM>
 <DIV>
 <H6 CLASS="AppendixLevel2">
 <A NAME="pgfId=1000764">
-</A>
-Other BIND Documents</H6>
+ </A>
+C.4 Other BIND Documents</H6>
 <P CLASS="Bib2">
-<A NAME="pgfId=999522">
-</A>
+<A NAME="pgfId=1039827">
+ </A>
 Albitz, Paul and Cricket Liu. 1998. <EM CLASS="doc-title">
 DNS and BIND</EM>
 . Sebastopol, CA: O'Reilly and Associates.</P>
 
-<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
+<p>Return to <A href="Bv9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
+
 </DIV>
 </DIV>
 </BODY>
diff --git a/doc/arm/BV9ARM.css b/doc/arm/Bv9ARM.css
index 0b2bed39..7b74b2ac 100644..100755
--- a/doc/arm/BV9ARM.css
+++ b/doc/arm/Bv9ARM.css
@@ -24,7 +24,7 @@ H1.1Level, H2.1Level, H3.1Level, H4.1Level, H5.1Level, H6.1Level {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Arial;
 }
 P.1LevelContinued {
 	text-align: left;
@@ -40,23 +40,7 @@ P.1LevelContinued {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
-}
-THROW AWAY.1LevelTOC {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 14.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 0.000000pt;
-	font-size: 12.000000pt;
-	font-weight: Bold;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Helvetica;
+	font-family: Times;
 }
 H1.2Level, H2.2Level, H3.2Level, H4.2Level, H5.2Level, H6.2Level {
 	text-align: left;
@@ -72,7 +56,7 @@ H1.2Level, H2.2Level, H3.2Level, H4.2Level, H5.2Level, H6.2Level {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Arial;
 }
 LI.2Level-bullet1 {
 	text-align: left;
@@ -106,37 +90,21 @@ LI.2Level-bullet2 {
 	text-transform: none;
 	font-family: Times;
 }
-PRE.2Level-fixed {
+P.2Level-fixed {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 3.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 63.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Bold;
+	font-size: 11.000000pt;
+	font-weight: medium;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
-}
-PRE.2Level-fixed1 {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 3.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 63.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Bold;
-	font-style: Regular;
-	color: #ff00ff;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Helvetica;
+	font-family: Courier New;
 }
 LI.2Level-numList1 {
 	text-align: left;
@@ -184,54 +152,6 @@ P.2LevelContinued {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
-}
-P.2LevelContinued1 {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 13.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 63.000000pt;
-	font-size: 11.000000pt;
-	font-weight: medium;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Times New Roman;
-}
-P.2LevelContinued2 {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 13.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 63.000000pt;
-	font-size: 11.000000pt;
-	font-weight: medium;
-	font-style: Italic;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Times;
-}
-THROW AWAY.2LevelTOC {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 0.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 0.000000pt;
-	font-size: 12.000000pt;
-	font-weight: medium;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
 	font-family: Times;
 }
 H1.3Level, H2.3Level, H3.3Level, H4.3Level, H5.3Level, H6.3Level {
@@ -248,39 +168,39 @@ H1.3Level, H2.3Level, H3.3Level, H4.3Level, H5.3Level, H6.3Level {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Arial;
 }
-PRE.3Level-fixed {
+P.3Level-fixed {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 3.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 99.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Bold;
+	font-size: 9.000000pt;
+	font-weight: medium;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
-P.3Level-fixed1 {
+P.3Level-fixed-special {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 3.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 99.000000pt;
-	font-size: 10.000000pt;
+	font-size: 9.000000pt;
 	font-weight: medium;
 	font-style: Regular;
-	color: #ff00ff;
+	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
 P.3LevelContinued {
 	text-align: left;
@@ -296,9 +216,9 @@ P.3LevelContinued {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
+	font-family: Times;
 }
-P.3LevelContinued1 {
+H1.3LevelContinued1, H2.3LevelContinued1, H3.3LevelContinued1, H4.3LevelContinued1, H5.3LevelContinued1, H6.3LevelContinued1 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 13.000000pt;
@@ -312,55 +232,7 @@ P.3LevelContinued1 {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times;
-}
-P.3LevelContinued2 {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 11.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 99.000000pt;
-	font-size: 10.000000pt;
-	font-weight: medium;
-	font-style: Regular;
-	color: #ff00ff;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Helvetica;
-}
-P.3LevelContinued21 {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 11.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 99.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Bold;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Courier New;
-}
-THROW AWAY.3LevelTOC {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 0.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 0.000000pt;
-	font-size: 12.000000pt;
-	font-weight: medium;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Times;
+	font-family: Times New Roman;
 }
 H1.4Level, H2.4Level, H3.4Level, H4.4Level, H5.4Level, H6.4Level {
 	text-align: left;
@@ -376,9 +248,9 @@ H1.4Level, H2.4Level, H3.4Level, H4.4Level, H5.4Level, H6.4Level {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Arial;
 }
-LI.4Level-bullet1 {
+H1.4Level-bullet1, H2.4Level-bullet1, H3.4Level-bullet1, H4.4Level-bullet1, H5.4Level-bullet1, H6.4Level-bullet1 {
 	text-align: left;
 	text-indent: 72.000000pt;
 	margin-top: 13.000000pt;
@@ -410,53 +282,37 @@ LI.4Level-bullet2 {
 	text-transform: none;
 	font-family: Times;
 }
-PRE.4Level-fixed {
+P.4Level-fixed {
 	text-align: left;
 	text-indent: 0.000000pt;
-	margin-top: 3.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 144.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Bold;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Helvetica;
-}
-PRE.4Level-fixed1 {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 3.000000pt;
+	margin-top: 2.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 144.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Bold;
+	font-size: 9.000000pt;
+	font-weight: medium;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
-PRE.4Level-fixedSmall {
+P.4Level-fixedSmall {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 2.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
-	margin-left: 144.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Bold;
+	margin-left: 126.000000pt;
+	font-size: 9.000000pt;
+	font-weight: medium;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
 P.4LevelContinued {
 	text-align: left;
@@ -472,25 +328,9 @@ P.4LevelContinued {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
-}
-THROW AWAY.4LevelTOC {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 0.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 0.000000pt;
-	font-size: 12.000000pt;
-	font-weight: medium;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
 	font-family: Times;
 }
-THROW AWAY.ActiveTOC {
+P.ActiveTOC {
 	text-align: justify;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -504,7 +344,7 @@ THROW AWAY.ActiveTOC {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
+	font-family: Times;
 }
 H1.AppendixLevel1, H2.AppendixLevel1, H3.AppendixLevel1, H4.AppendixLevel1, H5.AppendixLevel1, H6.AppendixLevel1 {
 	text-align: left;
@@ -522,7 +362,7 @@ H1.AppendixLevel1, H2.AppendixLevel1, H3.AppendixLevel1, H4.AppendixLevel1, H5.A
 	text-transform: none;
 	font-family: Arial;
 }
-THROW AWAY.AppendixLevel1TOC {
+P.AppendixLevel1TOC {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 14.000000pt;
@@ -554,7 +394,7 @@ H1.AppendixLevel2, H2.AppendixLevel2, H3.AppendixLevel2, H4.AppendixLevel2, H5.A
 	text-transform: none;
 	font-family: Arial;
 }
-THROW AWAY.AppendixLevel2TOC {
+P.AppendixLevel2TOC {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -586,7 +426,7 @@ H1.AppendixLevel3, H2.AppendixLevel3, H3.AppendixLevel3, H4.AppendixLevel3, H5.A
 	text-transform: none;
 	font-family: Arial;
 }
-THROW AWAY.AppendixLevel3TOC {
+P.AppendixLevel3TOC {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -618,7 +458,7 @@ P.Bib2 {
 	text-transform: none;
 	font-family: Times New Roman;
 }
-P.Bib3 {
+P.Bib31 {
 	text-align: left;
 	text-indent: -9.000000pt;
 	margin-top: 4.000000pt;
@@ -634,7 +474,7 @@ P.Bib3 {
 	text-transform: none;
 	font-family: Times New Roman;
 }
-P.Bib31 {
+P.Biblio {
 	text-align: left;
 	text-indent: -9.000000pt;
 	margin-top: 4.000000pt;
@@ -648,7 +488,7 @@ P.Bib31 {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times;
+	font-family: Times New Roman;
 }
 P.Body {
 	text-align: left;
@@ -669,6 +509,22 @@ P.Body {
 P.Body1 {
 	text-align: left;
 	text-indent: 0.000000pt;
+	margin-top: 0.000000pt;
+	margin-bottom: 0.000000pt;
+	margin-right: 0.000000pt;
+	margin-left: 0.000000pt;
+	font-size: 10.000000pt;
+	font-weight: medium;
+	font-style: Regular;
+	color: #000000;
+	text-decoration: none;
+	vertical-align: baseline;
+	text-transform: none;
+	font-family: Courier New;
+}
+P.Body11 {
+	text-align: left;
+	text-indent: 0.000000pt;
 	margin-top: 6.000000pt;
 	margin-bottom: 6.000000pt;
 	margin-right: 0.000000pt;
@@ -696,7 +552,7 @@ P.CellBody {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
+	font-family: Times;
 }
 P.CellBody-fixedfont {
 	text-align: left;
@@ -705,14 +561,14 @@ P.CellBody-fixedfont {
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Medium;
+	font-size: 6.000000pt;
+	font-weight: Bold;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
 P.CellBody-fixedfontLG {
 	text-align: left;
@@ -721,32 +577,32 @@ P.CellBody-fixedfontLG {
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Medium;
+	font-size: 8.000000pt;
+	font-weight: medium;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
-P.CellBody-fixedfontLG1 {
+H1.CellBody1, H2.CellBody1, H3.CellBody1, H4.CellBody1, H5.CellBody1, H6.CellBody1 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Medium;
+	font-size: 9.000000pt;
+	font-weight: medium;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
-P.CellBody1 {
+H1.CellBody2, H2.CellBody2, H3.CellBody2, H4.CellBody2, H5.CellBody2, H6.CellBody2 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -756,13 +612,13 @@ P.CellBody1 {
 	font-size: 11.000000pt;
 	font-weight: medium;
 	font-style: Italic;
-	color: #000000;
+	color: #ff00ff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
 	font-family: Times;
 }
-P.CellBody11 {
+H1.CellBody3, H2.CellBody3, H3.CellBody3, H4.CellBody3, H5.CellBody3, H6.CellBody3 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -771,78 +627,78 @@ P.CellBody11 {
 	margin-left: 0.000000pt;
 	font-size: 11.000000pt;
 	font-weight: medium;
-	font-style: Regular;
+	font-style: Italic;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Times;
 }
-P.CellBody2 {
+H1.CellBody4, H2.CellBody4, H3.CellBody4, H4.CellBody4, H5.CellBody4, H6.CellBody4 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 11.000000pt;
+	font-size: 9.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
-H1.CellBody21, H2.CellBody21, H3.CellBody21, H4.CellBody21, H5.CellBody21, H6.CellBody21 {
+H1.CellBody5, H2.CellBody5, H3.CellBody5, H4.CellBody5, H5.CellBody5, H6.CellBody5 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 11.000000pt;
-	font-weight: Medium;
-	font-style: Regular;
+	font-size: 9.000000pt;
+	font-weight: medium;
+	font-style: Italic;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
-P.CellBody3 {
+H1.CellBody6, H2.CellBody6, H3.CellBody6, H4.CellBody6, H5.CellBody6, H6.CellBody6 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 11.000000pt;
-	font-weight: medium;
-	font-style: Oblique;
+	font-size: 9.000000pt;
+	font-weight: Bold;
+	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Arial;
 }
-P.CellBody4 {
+P.CellBody7 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 11.000000pt;
+	font-size: 9.000000pt;
 	font-weight: medium;
-	font-style: Regular;
+	font-style: Italic;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Arial;
 }
-P.CellBody5 {
+P.CellBody8 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -850,64 +706,48 @@ P.CellBody5 {
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
 	font-size: 11.000000pt;
-	font-weight: Bold;
+	font-weight: medium;
 	font-style: Regular;
 	color: #000000;
-	text-decoration: none;
+	text-decoration: underline ;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Times;
 }
-P.CellBody6 {
+THROW AWAY.Footer {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
-	font-weight: medium;
-	font-style: Oblique;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Helvetica;
-}
-P.comment {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 13.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 144.000000pt;
-	font-size: 11.000000pt;
+	font-size: 9.000000pt;
 	font-weight: medium;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
+	font-family: Arial;
 }
-P.Comment {
+P.Footer1 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
+	font-size: 9.000000pt;
 	font-weight: medium;
 	font-style: Regular;
-	color: #ff00ff;
+	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
 	font-family: Helvetica;
 }
-THROW AWAY.Footer {
-	text-align: justify;
+P.Header {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
@@ -916,69 +756,69 @@ THROW AWAY.Footer {
 	font-size: 10.000000pt;
 	font-weight: medium;
 	font-style: Regular;
-	color: #ffffff;
+	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
+	font-family: Arial;
 }
-THROW AWAY.Footer1 {
+P.Mapping-Table-Cell {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
+	font-size: 12.000000pt;
 	font-weight: medium;
 	font-style: Regular;
-	color: #000000;
+	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Times;
 }
-THROW AWAY.Header {
+P.Mapping-Table-Cell1 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
-	font-weight: medium;
+	font-size: 18.000000pt;
+	font-weight: Bold;
 	font-style: Regular;
-	color: #000000;
+	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Times;
 }
-H1.Header1, H2.Header1, H3.Header1, H4.Header1, H5.Header1, H6.Header1 {
+P.Mapping-Table-Cell11 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
-	font-weight: medium;
+	font-size: 18.000000pt;
+	font-weight: Bold;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Arial;
 }
-P.Mapping-Table-Cell {
+P.Mapping-Table-Cell2 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 12.000000pt;
-	font-weight: medium;
+	font-size: 14.000000pt;
+	font-weight: Bold;
 	font-style: Regular;
 	color: #ffffff;
 	text-decoration: none;
@@ -986,14 +826,14 @@ P.Mapping-Table-Cell {
 	text-transform: none;
 	font-family: Times;
 }
-P.Mapping-Table-Cell1 {
+P.Mapping-Table-Cell3 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 18.000000pt;
+	font-size: 12.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
 	color: #ffffff;
@@ -1002,56 +842,56 @@ P.Mapping-Table-Cell1 {
 	text-transform: none;
 	font-family: Times;
 }
-P.Mapping-Table-Cell10 {
-	text-align: justify;
+P.Mapping-Table-Cell31 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
+	font-size: 14.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
 	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Arial;
+	font-family: Helvetica;
 }
-P.Mapping-Table-Cell11 {
-	text-align: justify;
+P.Mapping-Table-Cell310 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 11.000000pt;
+	font-size: 9.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
 	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Arial;
+	font-family: Courier;
 }
-P.Mapping-Table-Cell12 {
-	text-align: justify;
+P.Mapping-Table-Cell311 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
+	font-size: 11.000000pt;
 	font-weight: medium;
 	font-style: Regular;
 	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Arial;
+	font-family: Times;
 }
-P.Mapping-Table-Cell13 {
-	text-align: justify;
+P.Mapping-Table-Cell312 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
@@ -1060,77 +900,77 @@ P.Mapping-Table-Cell13 {
 	font-size: 10.000000pt;
 	font-weight: medium;
 	font-style: Regular;
-	color: #ffffff;
+	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Arial;
+	font-family: Helvetica;
 }
-P.Mapping-Table-Cell14 {
-	text-align: justify;
+P.Mapping-Table-Cell313 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 14.000000pt;
+	font-size: 10.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
-	color: #ffffff;
+	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
+	font-family: Times;
 }
-P.Mapping-Table-Cell15 {
-	text-align: justify;
+P.Mapping-Table-Cell314 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 12.000000pt;
+	font-size: 14.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
-	color: #ffffff;
+	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
+	font-family: Arial;
 }
-P.Mapping-Table-Cell16 {
-	text-align: justify;
+P.Mapping-Table-Cell315 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 18.000000pt;
+	font-size: 11.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
-	color: #ffffff;
+	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
 	font-family: Arial;
 }
-P.Mapping-Table-Cell2 {
+P.Mapping-Table-Cell316 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 14.000000pt;
+	font-size: 9.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
-	color: #ffffff;
+	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times;
+	font-family: Courier New;
 }
-P.Mapping-Table-Cell3 {
+P.Mapping-Table-Cell32 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -1144,25 +984,9 @@ P.Mapping-Table-Cell3 {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times;
-}
-P.Mapping-Table-Cell31 {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 0.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 0.000000pt;
-	font-size: 14.000000pt;
-	font-weight: Bold;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
 	font-family: Helvetica;
 }
-P.Mapping-Table-Cell32 {
+P.Mapping-Table-Cell33 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -1170,15 +994,15 @@ P.Mapping-Table-Cell32 {
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
 	font-size: 11.000000pt;
-	font-weight: Bold;
-	font-style: Regular;
-	color: #000000;
+	font-weight: medium;
+	font-style: Italic;
+	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Times;
 }
-P.Mapping-Table-Cell33 {
+P.Mapping-Table-Cell34 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
@@ -1186,22 +1010,22 @@ P.Mapping-Table-Cell33 {
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
 	font-size: 10.000000pt;
-	font-weight: medium;
+	font-weight: Bold;
 	font-style: Regular;
-	color: #000000;
+	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
 	font-family: Helvetica;
 }
-P.Mapping-Table-Cell4 {
+P.Mapping-Table-Cell35 {
 	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
+	font-size: 11.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
 	color: #ffffff;
@@ -1210,72 +1034,72 @@ P.Mapping-Table-Cell4 {
 	text-transform: none;
 	font-family: Courier;
 }
-P.Mapping-Table-Cell5 {
-	text-align: justify;
+P.Mapping-Table-Cell36 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 14.000000pt;
-	font-weight: Bold;
-	font-style: Regular;
+	font-size: 11.000000pt;
+	font-weight: medium;
+	font-style: Oblique;
 	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Arial;
+	font-family: Courier;
 }
-P.Mapping-Table-Cell6 {
-	text-align: justify;
+P.Mapping-Table-Cell37 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 12.000000pt;
-	font-weight: Bold;
+	font-size: 11.000000pt;
+	font-weight: medium;
 	font-style: Regular;
 	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Arial;
+	font-family: Courier;
 }
-P.Mapping-Table-Cell7 {
-	text-align: justify;
+P.Mapping-Table-Cell38 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
 	font-size: 11.000000pt;
-	font-weight: medium;
+	font-weight: Bold;
 	font-style: Regular;
 	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Times New Roman;
+	font-family: Helvetica;
 }
-P.Mapping-Table-Cell8 {
-	text-align: justify;
+P.Mapping-Table-Cell39 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
 	margin-right: 0.000000pt;
 	margin-left: 0.000000pt;
-	font-size: 10.000000pt;
-	font-weight: Bold;
-	font-style: Italic;
+	font-size: 9.000000pt;
+	font-weight: medium;
+	font-style: Oblique;
 	color: #ffffff;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Helvetica;
 }
-P.Mapping-Table-Cell9 {
-	text-align: justify;
+P.Mapping-Table-Cell4 {
+	text-align: left;
 	text-indent: 0.000000pt;
 	margin-top: 0.000000pt;
 	margin-bottom: 0.000000pt;
@@ -1306,7 +1130,7 @@ P.Mapping-Table-Title {
 	text-transform: none;
 	font-family: Times;
 }
-H1.Subhead2, H2.Subhead2, H3.Subhead2, H4.Subhead2, H5.Subhead2, H6.Subhead2 {
+LI.Subhead2 {
 	text-align: left;
 	text-indent: 63.000000pt;
 	margin-top: 12.000000pt;
@@ -1320,39 +1144,7 @@ H1.Subhead2, H2.Subhead2, H3.Subhead2, H4.Subhead2, H5.Subhead2, H6.Subhead2 {
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
-}
-LI.Subhead2-noBullet {
-	text-align: left;
-	text-indent: -55.799988pt;
-	margin-top: 12.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 118.799988pt;
-	font-size: 10.000000pt;
-	font-weight: medium;
-	font-style: Regular;
-	color: #0000ff;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Helvetica;
-}
-H1.Subhead4, H2.Subhead4, H3.Subhead4, H4.Subhead4, H5.Subhead4, H6.Subhead4 {
-	text-align: left;
-	text-indent: 0.000000pt;
-	margin-top: 12.000000pt;
-	margin-bottom: 0.000000pt;
-	margin-right: 0.000000pt;
-	margin-left: 144.000000pt;
-	font-size: 12.000000pt;
-	font-weight: Bold;
-	font-style: Regular;
-	color: #000000;
-	text-decoration: none;
-	vertical-align: baseline;
-	text-transform: none;
-	font-family: Times;
+	font-family: Arial;
 }
 H1.Title, H2.Title, H3.Title, H4.Title, H5.Title, H6.Title {
 	text-align: center;
@@ -1370,15 +1162,17 @@ H1.Title, H2.Title, H3.Title, H4.Title, H5.Title, H6.Title {
 	text-transform: none;
 	font-family: Arial;
 }
-EM.CharFmt {
-	text-decoration: underline ;
-}
 EM.CharFmt1 {
-	font-family: Courier;
 }
 EM.Command {
-	font-size: 7.000000pt;
-	font-family: Courier;
+	font-size: 9.000000pt;
+	font-weight: medium;
+	font-style: Regular;
+	color: #000000;
+	text-decoration: none;
+	vertical-align: baseline;
+	text-transform: none;
+	font-family: Courier New;
 }
 EM.Comment {
 	font-size: 11.000000pt;
@@ -1390,71 +1184,103 @@ EM.Comment {
 	text-transform: none;
 	font-family: Times;
 }
-EM.Comment21 {
+EM.doc-title {
 	font-size: 10.000000pt;
+	font-weight: medium;
 	font-style: Italic;
-	color: #ff00ff;
-	font-family: Arial;
+	color: #000000;
+	text-decoration: none;
+	vertical-align: baseline;
+	text-transform: none;
+	font-family: Times;
 }
-EM.doc-title {
+EM.Emphasis {
 	font-style: Italic;
 }
-EM.doc-title1 {
-	font-style: Italic;
-	font-family: Times New Roman;
+EM.Emphasis-underline {
+	font-size: 11.000000pt;
+	font-weight: medium;
+	font-style: Regular;
+	color: #000000;
+	text-decoration: underline ;
+	vertical-align: baseline;
+	text-transform: none;
+	font-family: Times;
 }
-EM.Emphasis {
+EM.EquationVariables {
 	font-style: Italic;
 }
 EM.grammar_literal {
-	font-size: 10.000000pt;
+	font-size: 9.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Courier;
+	font-family: Courier New;
 }
-KBD.Literal-user-input {
+TT.Literal-user-input {
+	font-size: 9.000000pt;
+	font-weight: Bold;
+	font-style: Regular;
+	color: #000000;
+	text-decoration: none;
+	vertical-align: baseline;
+	text-transform: none;
+	font-family: Courier New;
 }
 EM.Optional-meta-syntax {
-	font-size: 11.000000pt;
+	font-size: 9.000000pt;
 	font-weight: medium;
 	font-style: Italic;
+	color: #000000;
+	text-decoration: none;
+	vertical-align: baseline;
+	text-transform: none;
+	font-family: Courier New;
 }
 EM.pathname {
 	font-size: 10.000000pt;
 	font-style: Italic;
 }
 EM.production_target {
-	font-size: 10.000000pt;
+	font-size: 9.000000pt;
 	font-weight: Bold;
 	font-style: Regular;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Arial;
 }
 CODE.Program-Process {
-	font-size: 12.000000pt;
+	font-size: 9.000000pt;
 	font-weight: Bold;
-	font-family: Courier;
+	font-style: Regular;
+	color: #000000;
+	text-decoration: none;
+	vertical-align: baseline;
+	text-transform: none;
+	font-family: Courier New;
 }
 EM.URL {
 	font-size: 11.000000pt;
 	font-weight: medium;
 	font-style: Italic;
-	font-family: Times New Roman;
+	color: #000000;
+	text-decoration: none;
+	vertical-align: baseline;
+	text-transform: none;
+	font-family: Times;
 }
 EM.variable {
-	font-size: 11.000000pt;
+	font-size: 9.000000pt;
 	font-weight: medium;
-	font-style: Oblique;
+	font-style: Italic;
 	color: #000000;
 	text-decoration: none;
 	vertical-align: baseline;
 	text-transform: none;
-	font-family: Helvetica;
+	font-family: Arial;
 }
diff --git a/doc/arm/BV9ARM.html b/doc/arm/Bv9ARM.html
index c16274a7..e2296cb5 100644..100755
--- a/doc/arm/BV9ARM.html
+++ b/doc/arm/Bv9ARM.html
@@ -2,19 +2,19 @@
 <HTML>
 <HEAD>
 <META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
-<LINK REL="STYLESHEET" HREF="BV9ARM.css">
-<TITLE> </TITLE></HEAD>
+<LINK REL="STYLESHEET" HREF="Bv9ARM.css">
+<TITLE>BINDv9 Administrator Reference Manual</TITLE></HEAD>
 <BODY BGCOLOR="#ffffff">
+<DIV>
 
 <DIV ALIGN="left">
-<IMG SRC="isc.color.gif" ALT="ISC logo" WIDTH="144" HEIGHT="90" ALIGN="left" HSPACE=30>
+<A HREF="http://www.isc.org/"><IMG SRC="isc.color.gif" ALT="ISC logo" WIDTH="144" HEIGHT="90" ALIGN="left" HSPACE="30" BORDER="0"></A>
 </DIV>
-
 <DIV ALIGN="left">
 <H2>BIND version 9<BR>Administrator Reference Manual</H2>
 <H2>DRAFT
 <br>
-March 19, 2000</H2>
+May, 2000</H2>
 </DIV>
 
 <HR ALIGN="center">
@@ -22,39 +22,46 @@ March 19, 2000</H2>
 <H4>Warning! This DRAFT document is the property of the Internet Software Consortium (ISC) and contains proprietary ISC information. The information in this document is subject to change.</H4>
 </DIV>
 <HR ALIGN="center">
+
+<H6 CLASS="Title">
+<A NAME="pgfId=21862">
+ </A>
+Table of Contents</H6>
+</DIV>
 <OL>
 <H1 CLASS="1LevelTOC">
-<A HREF="BV9ARM.1.html#pgfId=1007883" CLASS="Hypertext">
+<A HREF="Bv9ARM.1.html#pgfId=1007883" CLASS="Hypertext">
 Section 1.	Introduction </A>
 </H1>
 <H1 CLASS="1LevelTOC">
-<A HREF="BV9ARM.2.html#pgfId=997350" CLASS="Hypertext">
+<A HREF="Bv9ARM.2.html#pgfId=997350" CLASS="Hypertext">
 Section 2.	BIND Resource Requirements</A>
 </H1>
 <H1 CLASS="1LevelTOC">
-<A HREF="BV9ARM.3.html#pgfId=997350" CLASS="Hypertext">
+<A HREF="Bv9ARM.3.html#pgfId=997350" CLASS="Hypertext">
 Section 3.	Nameserver Configuration</A>
 </H1>
 <H1 CLASS="1LevelTOC">
-<A HREF="BV9ARM.4.html#pgfId=997350" CLASS="Hypertext">
+<A HREF="Bv9ARM.4.html#pgfId=997350" CLASS="Hypertext">
 Section 4.	Advanced Concepts</A>
 </H1>
 <H1 CLASS="1LevelTOC">
-<A HREF="BV9ARM.5.html#pgfId=997350" CLASS="Hypertext">
+<A HREF="Bv9ARM.5.html#pgfId=997350" CLASS="Hypertext">
 Section 5.	BINDv9 Configuration Reference</A>
 </H1>
 <H1 CLASS="1LevelTOC">
-<A HREF="BV9ARM.6.html#pgfId=997350" CLASS="Hypertext">
+<A HREF="Bv9ARM.6.html#pgfId=997350" CLASS="Hypertext">
 Section 6.	Security Considerations</A>
 </H1>
 <H1 CLASS="1LevelTOC">
-<A HREF="BV9ARM.7.html#pgfId=997350" CLASS="Hypertext">
+<A HREF="Bv9ARM.7.html#pgfId=997350" CLASS="Hypertext">
 Section 7.	Troubleshooting</A>
 </H1>
 <H1 CLASS="1LevelTOC">
-<A HREF="BV9ARM.8.html#pgfId=997350" CLASS="Hypertext">
+<A HREF="Bv9ARM.8.html#pgfId=997350" CLASS="Hypertext">
 Appendices</A>
-</H1>
-</OL>
+</H1></OL>
+<HR ALIGN="center">
+
 </BODY>
 </HTML>
diff --git a/doc/draft/draft-duerst-dns-i18n-02.txt b/doc/draft/draft-duerst-dns-i18n-02.txt
deleted file mode 100644
index a4298163..00000000
--- a/doc/draft/draft-duerst-dns-i18n-02.txt
+++ /dev/null
@@ -1,905 +0,0 @@
-
-
-
-
-
-
-Internet Draft                                                M. Duerst
-<draft-duerst-dns-i18n-02.txt>                          Keio University
-Expires in six months                                         July 1998
-
-
-                  Internationalization of Domain Names
-
-
-Status of this Memo
-
-   This document is an Internet-Draft.  Internet-Drafts are working doc-
-   uments of the Internet Engineering Task Force (IETF), its areas, and
-   its working groups. Note that other groups may also distribute work-
-   ing documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months. Internet-Drafts may be updated, replaced, or obsoleted by
-   other documents at any time.  It is not appropriate to use Internet-
-   Drafts as reference material or to cite them other than as a "working
-   draft" or "work in progress".
-
-   To learn the current status of any Internet-Draft, please check the
-   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
-   Directories on ftp.ietf.org (US East Coast), nic.nordu.net
-   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   Distribution of this document is unlimited.  Please send comments to
-   the author at <mduerst@w3.org>.
-
-
-Abstract
-
-   Internet domain names are currently limited to a very restricted
-   character set. This document proposes the introduction of a new
-   "zero-level" domain (ZLD) to allow the use of arbitrary characters
-   from the Universal Character Set (ISO 10646/Unicode) in domain names.
-   The proposal is fully backwards compatible and does not need any
-   changes to DNS. Version 02 is reissued without changes just to
-   keep this draft available.
-
-Table of contents
-
-   0. Change History ................................................. 2
-     0.8 Changes Made from Version 01 to Version 02 .................. 2
-     0.9 Changes Made from Version 00 to Version 01 .................. 2
-   1. Introduction ................................................... 3
-     1.1 Motivation .................................................. 3
-
-
-
-                       Expires End of January 1998      [Page 1]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-     1.2 Notational Conventions ...................................... 4
-   2. The Hidden Zero Level Domain ................................... 4
-   3. Encoding International Characters .............................. 5
-     3.1 Encoding Requirements ....................................... 5
-     3.2 Encoding Definition ......................................... 5
-     3.3 Encoding Example ............................................ 7
-     3.4 Length Considerations ....................................... 8
-   4. Usage Considerations ........................................... 8
-     4.1 General Usage ............................................... 8
-     4.2 Usage Restrictions .......................................... 9
-     4.3 Domain Name Creation ....................................... 10
-     4.4 Usage in URLs .............................................. 12
-   5. Alternate Proposals ........................................... 13
-     5.1 The Dillon Proposal ........................................ 13
-     5.2 Using a Separate Lookup Service ............................ 13
-   6. Generic Considerations ........................................ 14
-     5.1 Security Considerations .................................... 14
-     5.2 Internationalization Considerations ........................ 14
-   Acknowledgements ................................................. 14
-   Bibliography ..................................................... 15
-   Author's Address .................................................=
- 16
-
-
-
-
-0. Change History
-
-
-
-0.8 Changes Made from Version 01 to Version 02
-
-   No significant changes; reissued to make it available officially.
-   Changed author's address.
-
-   Changes deferred to future versions (if ever):
-   -  Decide on ZLD name (.i or .i18n.int or something else)
-   -  Decide on casing solution
-   -  Decide on exact syntax
-   -  Proposals for experimental setup
-
-
-
-
-0.9 Changes Made from Version 00 to Version 01
-
-
-
-
-
-
-
-                       Expires End of January 1998      [Page 2]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   -  Minor rewrites and clarifications
-
-   -  Added the following references: [RFC1730], [Kle96], [ISO3166],
-      [iNORM]
-
-   -  Slightly expanded discussion about casing
-
-   -  Added some variant proposals for syntax
-
-   -  Added some explanations about different kinds of name parallelism
-
-   -  Added some explanation about independent addition of internation-
-      alized names in subdomains without bothering higher-level domains
-
-   -  Added some explanations about tools needed for support, and the
-      MX/CNAME problem
-
-   -  Change to RFC1123 (numbers allowed at beginning of labels)
-
-
-
-
-1. Introduction
-
-
-1.1 Motivation
-
-
-   The lower layers of the Internet do not discriminate any language or
-   script. On the application level, however, the historical dominance
-   of the US and the ASCII character set [ASCII] as a lowest common
-   denominator have led to limitations. The process of removing these
-   limitations is called internationalization (abbreviated i18n).  One
-   example of the abovementioned limitations are domain names [RFC1034,
-   RFC1035], where only the letters of the basic Latin alphabet (case-
-   insensitive), the decimal digits, and the hyphen are allowed.
-
-   While such restrictions are convenient if a domain name is intended
-   to be used by arbitrary people around the globe, there may be very
-   good reasons for using aliases that are more easy to remember or type
-   in a local context. This is similar to traditional mail addresses,
-   where both local scripts and conventions and the Latin script can be
-   used.
-
-   There are many good reasons for domain name i18n, and some arguments
-   that are brought forward against such an extension. This document,
-   however, does not discuss the pros and cons of domain name i18n. It
-   proposes and discusses a solution and therefore eliminates one of the
-
-
-
-                       Expires End of January 1998      [Page 3]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   most often heard arguments agains, namely "it cannot be done".
-
-   The solution proposed in this document consists of the introduction
-   of a new "zero-level" domain building the root of a new domain
-   branch, and an encoding of the Universal Character Set (UCS)
-   [ISO10646] into the limited character set of domain names.
-
-
-
-1.2 Notational Conventions
-
-   In the domain name examples in this document, characters of the basic
-   Latin alphabet (expressible in ASCII) are denoted with lower case
-   letters. Upper case letters are used to represent characters outside
-   ASCII, such as accented characters of the Latin alphabet, characters
-   of other alphabets and syllabaries, ideographic characters, and vari-
-   ous signs.
-
-
-2. The Hidden Zero Level Domain
-
-   The domain name system uses the domain "in-addr.arpa" to convert
-   internet addresses back to domain names. One way to view this is to
-   say that in-addr.arpa forms the root of a separate hierarchy.  This
-   hierarchy has been made part of the main domain name hierarchy just
-   for implementation convenience. While syntactically, in-addr.arpa is
-   a second level domain (SLD), functionally it is a zero level domain
-   (ZLD) in the same way as "." is a ZLD.  A similar example of a ZLD is
-   the domain tpc.int, which provides a hierarchy of the global phone
-   numbering system [RFC1530] for services such as paging and printing
-   to fax machines.
-
-   For domain name i18n to work inside the tight restrictions of domain
-   name syntax, one has to define an encoding that maps strings of UCS
-   characters to strings of characters allowable in domain names, and a
-   means to distinguish domain names that are the result of such an
-   encoding from ordinary domain names.
-
-   This document proposes to create a new ZLD to distinguish encoded
-   i18n domain names from traditional domain names.  This domain would
-   be hidden from the user in the same way as a user does not see in-
-   addr.arpa.  This domain could be called "i18n.arpa" (although the use
-   of arpa in this context is definitely not appropriate), simply
-   "i18n", or even just "i". Below, we are using "i" for shortness,
-   while we leave the decision on the actual name to further=
- discussion.
-
-
-
-
-
-
-                       Expires End of January 1998      [Page 4]
-
-Internet Draft    Internationalization of Domain Names         July=
- 1997
-
-
-3. Encoding International Characters
-
-
-
-
-3.1 Encoding Requirements
-
-
-   Until quite recently, the thought of going beyond ASCII for something
-   such as domain names failed because of the lack of a single encom-
-   passing character set for the scripts and languages of the world.
-   Tagging techniques such as those used in MIME headers [RFC1522] would
-   be much too clumsy for domain names.
-
-   The definition of ISO 10646 [ISO10646], codepoint by codepoint iden-
-   tical with Unicode [Unicode], provides a single Universal Character
-   Set (UCS).  A recent report [RFCIAB] clearly recommends to base the
-   i18n of the Internet on these standards.
-
-   An encoding for i18n domain names therefore has to take the charac-
-   ters of ISO 10646/Unicode as a starting point.  The full four-byte
-   (31 bit) form of UCS, called UCS4, should be used. A limitation to
-   the two-byte form (UCS2), which allows only for the encoding of the
-   Base Multilingual Plane, is too restricting.
-
-   For the mapping between UCS4 and the strongly limited character set
-   of domain names, the following constraints have to be considered:
-
-   -  The structure of domain names, and therefore the "dot", have to be
-      conserved. Encoding is done for individual labels.
-
-   -  Individual labels in domain names allow the basic Latin alphabet
-      (monocase, 26 letters), decimal digits, and the "-" inside the
-      label.  The capacity per octet is therefore limited to somewhat
-      above 5 bits.
-
-   -  There is no need nor possibility to preserve any characters.
-
-   -  Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order)
-      should be encoded relatively compactly. A variable-length encoding
-      (similar to UTF-8) seems desirable.
-
-
-
-3.2 Encoding Definition
-
-
-   Several encodings for UCS, so called UCS Transform Formats, exist
-
-
-
-                       Expires End of January 1998      [Page 5]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni-
-   code]. Unfortunately, none of them is suitable for our purposes. We
-   therefore use the following encoding:
-
-   -  To accommodate the slanted probability distribution of characters
-      in UCS4, a variable-length encoding is used.
-
-   -  Each target letter encodes 5 bits of information.  Four bits of
-      information encode character data, the fifth bit is used to indi-
-      cate continuation of the variable-length encoding.
-
-   -  Continuation is indicated by distinguishing the initial letter
-      from the subsequent letter.
-
-   -  Leading four-bit groups of binary value 0000 of UCS4 characters
-      are discarded, except for the last TWO groups (i.e. the last
-      octet).  This means that ASCII and Latin-1 characters need two
-      target letters, the main alphabets up to and including Tibetan
-      need three target letters, the rest of the characters in the BMP
-      need four target letters, all except the last (private) plane in
-      the UTF-16/Surrogates area [Unicode] need five target letters, and
-      so on.
-
-   -  The letters representing the various bit groups in the various
-      positions are chosen according to the following table:
-
-
-        Nibble Value   Initial        Subsequent
-        Hex  Binary
-        0    0000 G         0
-        1    0001 H         1
-        2    0010 I         2
-        3    0011 J         3
-        4    0100 K         4
-        5    0101 L         5
-        6    0110 M         6
-        7    0111 N         7
-        8    1000 O         8
-        9    1001 P         9
-        A    1010 Q         A
-        B    1011 R         B
-        C    1100 S         C
-        D    1101 T         D
-        E    1110 U         E
-        F    1111 V         F
-
-
-   [Should we try to eliminate "I" and "O" from initial? "I" might be
-
-
-
-                       Expires End of January 1998      [Page 6]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   eliminated because then an algorithm can more easily detect ".i". "O"
-   could lead to some confusion with "0".  What other protocols are
-   there that might be able to use a similar solution, but that might
-   have other restrictions for the initial letters? Proposal to run ini-
-   tial range from H to X. Extracting the initial bits then becomes ^
-   'H'.  Proposal to have a special convention for all-ASCII labels
-   (start label with one of the letters not used above).]
-
-   Please note that this solution has the following interesting proper-
-   ties:
-
-   -  For subsequent positions, there is an equivalence between the hex-
-      adecimal value of the character code and the target letter used.
-      This assures easy conversion and checking.
-
-   -  The absence of digits from the "initial" column, and the fact that
-      the hyphen is not used, assures that the resulting string conforms
-      to domain name syntax.
-
-   -  Raw sorting of encoded and unencoded domain names is equivalent.
-
-   -  The boundaries of characters can always be detected easily.
-      (While this is important for representations that are used inter-
-      nally for text editing, it is actually not very important here,
-      because tools for editing can be assumed to use a more straight-
-      forward representation internally.)
-
-   -  Unless control characters are allowed, the target string will
-      never actually contain a G.
-
-
-
-3.3 Encoding Example
-
-
-   As an example, the current domain
-
-        is.s.u-tokyo.ac.jp
-
-   with the components standing for information science, science, the
-   University of Tokyo, academic, and Japan, might in future be repre-
-   sented by
-
-        JOUHOU.RI.TOUDAI.GAKU.NIHON
-
-   (a transliteration of the kanji that might probably be chosen to rep-
-   resent the same domain). Writing each character in U+HHHH notation as
-   in [Unicode], this results in the following (given for reference
-
-
-
-                       Expires End of January 1998      [Page 7]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   only, not the actual encoding or something being typed in by the
-   user):
-
-        U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c
-
-   The software handling internationalized domain names will translate
-   this, according to the above specifications, before submitting it to
-   the DNS resolver, to:
-
-        M0C5L831.N406.M771L927.LB66.M5E5M72C.i
-
-
-
-3.4 Length Considerations
-
-
-   DNS allows for a maximum of 63 positions in each part, and for 255
-   positions for the overall domain name including dots.  This allows up
-   to 15 ideographs, or up to 21 letters e.g.  from the Hebrew or Arabic
-   alphabet, in a label.  While this does not allow for the same margin
-   as in the case of ASCII domain names, it should still be quite suffi-
-   cient.  [Problems could only surface for languages that use very long
-   words or terms and don't know any kind of abbreviations or similar
-   shortening devices. Do these exist?  Islandic expert asserted
-   Islandic is not a problem.]  DNS contains a compression scheme that
-   avoids sending the same trailing portion of a domain name twice in
-   the same transmission. Long domain names are therefore not that much
-   of a concern.
-
-
-4. Usage Considerations
-
-
-
-4.1 General Usage
-
-
-   To implement this proposal, neither DNS servers nor resolvers need
-   changes.  These programs will only deal with the encoded form of the
-   domain name with the .i suffix. Software that wants to offer an
-   internationalized user interface (for example a web browser) is
-   responsible for the necessary conversions. It will analyze the domain
-   name, call the resolver directly if the domain name conforms to the
-   domain name syntax restrictions, and otherwise encode the name
-   according to the specifications of Section 3.2 and append the .i suf-
-   fix before calling the resolver.  New implementations of resolvers
-   will of course offer a companion function to gethostbyname accepting
-   a ISO10646/Unicode string as input.
-
-
-
-                       Expires End of January 1998      [Page 8]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   For domain name administrators, them main tool that will be needed is
-   a program to compile files configuring zones from an UTF-8 notation
-   (or any other suitable encoding) to the encoding described in Section
-   3.3. Utility tools will include a corresponding decompiler, checkers
-   for various kinds of internationalization-related errors, and tools
-   for managing syntactic parallelism (see Section 4.3).
-
-
-4.2 Usage Restrictions
-
-
-   While this proposal in theory allows to have control characters such
-   as BEL or NUL or symbols such as arrows and smilies in domain names,
-   such characters should clearly be excluded from domain names. Whether
-   this has to be explicitly specified or whether the difficulty to type
-   these characters on any keyboard of the world will limit their use
-   has to be discussed. One approach is to start with a very restricted
-   subset and gradually relax it; the other is to allow almost anything
-   and to rely on common sense. Anyway, such specifications should go
-   into a separate document to allow easy updates.
-
-   A related point is the question of equivalence. For historical rea-
-   sons, ISO 10646/Unicode contain considerable number of compatibility
-   characters and allow more than one representation for characters with
-   diacritics. To guarantee smooth interoperability in these and related
-   cases, additional restrictions or the definition of some form of nor-
-   malization seem necessary.  However, this is a general problem
-   affecting all areas where ISO 10646/Unicode is used in identifiers,
-   and should therefore be addressed in a generic way.  See [iNORM] for
-   an initial proposal.
-
-   Equally related is the problem of case equivalence.  Users can very
-   well distinguish between upper case and lower case.  Also, casing in
-   an i18n context is not as straightforward as for ASCII, so that case
-   equivalence is best avoided.  Problems therefore result not from the
-   fact that case is distinguished for i18n domain names, but from the
-   fact that existing domain names do not distinguish case. Where it is
-   impossible to distinguish between next.com and NeXT.com, the same two
-   subdomains would easily be distinguishable if subordinate to a i18n
-   domain.  There are several possible solutions. One is to try to grad-
-   ually migrate from a case-insensitive solution to a case-sensitive
-   solution even for ASCII. Another is to allow case-sensitivity only
-   beyond ASCII. Another is to restrict anything beyond ASCII to lower-
-   case only (lowercase distinguishes better than uppercase, and is also
-   generally used for ASCII domain names).
-
-   A problem that also has to be discussed and solved is bidirectional-
-   ity.  Arabic and Hebrew characters are written right-to-left, and the
-
-
-
-                       Expires End of January 1998      [Page 9]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   mixture with other characters results in a divergence between logical
-   and graphical sequence. See [HTML-I18N] for more explanations.  The
-   proposal of [Yer96] for dealing with bidirectionality in URLs could
-   probably be applied to domain names. Anyway, there should be a gen-
-   eral solution for identifiers, not a DNS-specific solution.
-
-
-4.3 Domain Name Creation
-
-
-   The ".i" ZLD should be created as such to allow the internationaliza-
-   tion of domain names. Rules for creating subdomains inside ".i"
-   should follow the established rules for the creation of functionally
-   equivalent domains in the existing domain hierarchy, and should
-   evolve in parallel.
-
-   For the actual domain hierarchy, the amount of parallelism between
-   the current ASCII-oriented hierarchy and some internationalized hier-
-   archy depends on various factors.  In some cases, two fully parallel
-   hierarchies may emerge.  In other cases, if more than one script or
-   language is used locally, more than two parallel hierarchies may
-   emerge.  Some nodes, e.g. in intranets, may only appear in an i18n
-   hierarchy, whereas others may only appear in the current hierarchy.
-   In some cases, the pecularities of scripts, languages, cultures, and
-   the local marketplace may lead to completely different hierarchies.
-
-   Also, one has to be aware that there may be several kinds of paral-
-   lelisms. The first one is called syntactic parallelism.  If there is
-   a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz
-   will have to exist both in the traditional DNS hierarchy as well as
-   within the hierarchy starting at the .i ZLD, with appropriate encod-
-   ing.
-
-   The second type of parallelism is called transcription parallelism.
-   It results by transcribing or transliterating relations between ASCII
-   domain names and domain names in other scripts.
-
-   The third type of parallelism is called semantic parallelism.  It
-   results from translating elements of a domain name from one language
-   to another, possibly also changing the script or set of used charac-
-   ters.
-
-   On the host level, parallelism means that there are two names for the
-   same host. Conventions should exist to decide whether the parallel
-   names should have separate IP addresses or not (A record or CNAME
-   record).  With separate IP addresses, address to name lookup is easy,
-   otherwise it needs special precautions to be able to find all names
-   corresponding to a given host address.  Another detail entering this
-
-
-
-                       Expires End of January 1998     [Page 10]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   consideration is that MX records only work for  hostnames/domains,
-   not for CNAME aliases.  This at least has the consequence that alias
-   resolution for internationalized mail addresses has to occur before
-   MX record lookup.
-
-   When discussing and applying the rules for creating domain names,
-   some peculiarities of i18n domain names should be carefully consid-
-   ered:
-
-   -  Depending on the script, reasonable lengths for domain name parts
-      may differ greatly. For ideographic scripts, a part may often be
-      only a one-letter code. Established rules for lengths may need
-      adaptation. For example, a rule for country TLDs could read: one
-      ideographic character or two other characters.
-
-   -  If the number of generic TLDs (.com, .edu, .org, .net) is kept
-      low, then it may be feasible to restrict i18n TLDs to country
-      TLDs.
-
-   -  There are no ISO 3166 [ISO3166] two-letter codes in scripts other
-      than Latin.  I18n domain names for countries will have to be
-      designed from scratch.
-
-   -  The names of some countries or regions may pose greater political
-      problems when expressed in the native script than when expressed
-      in 2-letter ISO 3166 codes.
-
-   -  I18n country domain names should in principle only be created in
-      those scripts that are used locally. There is probably little use
-      in creating an Arabic domain name for China, for example.
-
-   -  In those cases where domain names are open to a wide range of
-      applicants, a special procedure for accepting applications should
-      be used so that a reasonable-quality fit between ASCII domain
-      names and i18n domain names results where desired.  This would
-      probably be done by establishing a period of about a month for
-      applications inside a i18n domain newly created as a parallel for
-      an existing domain, and resolving the detected conflicts.  For
-      syntactically parallel domain names, the owners should always be
-      the same. Administration may be split in some cases to account for
-      the necessary linguistic knowledge.  For domain names with tran-
-      scription parallelism and semantic parallelism, the question of
-      owner identity should depend on the real-life situation (trade-
-      marks,...).
-
-   -  It will be desirable to have internationalized subdomains in non-
-      internationalized TLDs. As an example, many companies in France
-      may want to register an accented version of their company name,
-
-
-
-                       Expires End of January 1998     [Page 11]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-      while remaining under the .fr TLD. For this, .fr would have to be
-      reregistered as .M6N2.i. Accented and other internationalized sub-
-      domains would go below .M6N2.i, whereas unaccented ones would go
-      below .fr in its plain form.
-
-   -  To generalize the above case, one may need to create a requirement
-      that any domain name registry would have to register and manage
-      syntactically parallel domain names below the .i ZLD upon request
-      to allow registration of i18n domain names in arbitrary subdo-
-      mains.  An alternative to this is to organize domain name search
-      so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in
-      .i, the name server for .fr is queried for XXXXXX.M6N2.i (with
-      XXXXXX appropriately encoded).  This convention would allow lower-
-      level domains to introduce internationalized subdomains without
-      depending on higher-level domains.
-
-
-
-4.4 Usage in URLs
-
-   According to current definitions, URLs encode sequences of octets
-   into a sequence of characters from a character set that is almost as
-   limited as the character set of domain names [RFC1738].  This is
-   clearly not satisfying for i18n.
-
-   Internationalizing URLs, i.e. assigning character semantics to the
-   encoded octets, can either be done separately for each part and/or
-   scheme, or in an uniform way. Doing it separately has the serious
-   disadvantage that software providing user interfaces for URLs in gen-
-   eral would have to know about all the different i18n solutions of the
-   different parts and schemes. Many of these solutions may not even be
-   known yet.
-
-   It is therefore definitely more advantageous to decide on a single
-   and consistent solution for URL internationalization. The most valu-
-   able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an
-   ASCII-compatible encoding of UCS4.
-
-   Therefore, an URL containing the domain name of the example of Sec-
-   tion 3.3 should not be written as:
-
-        ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i
-
-   (although this will also work) but rather
-
-        ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7.
-             %e5%ad%a6.%e6%97%a5%e6%9c%ac
-
-
-
-
-                       Expires End of January 1998     [Page 12]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   In this canonical form, the trailing .i is absent, and the octets can
-   be reconstructed from the %HH-encoding and interpreted as UTF-8 by
-   generic URL software. The software part dealing with domain names
-   will carry out the conversion to the .i form.
-
-
-5. Alternate Proposals
-
-
-
-5.1 The Dillon Proposal
-
-   The proposal of Michael Dillon [Dillon96] is also based on encoding
-   Unicode into the limited character set of domain names. Distinction
-   is done for each part, using the hyphen in initial position. Because
-   this does not fully conform to the syntax of existing domain names,
-   it is questionable whether it is backwards-compatible. On the other
-   hand, this has the advantage that local i18n domain names can be
-   installed easily without cooperation by the manager of the superdo-
-   main.
-
-   A variable-length scheme with base 36 is used that can encode up to
-   1610 characters, absolutely insufficient for Chinese or Japanese.
-   Characters assumed not to be used in i18n domain names are excluded,
-   i.e. only one case is allowed for basic Latin characters.  This means
-   that large tables have to be worked out carefully to convert between
-   ISO 10646/Unicode and the actual number that is encoded with base=
- 36.
-
-
-5.2 Using a Separate Lookup Service
-
-   Instead of using a special encoding and burdening DNS with i18n, one
-   could build and use a separate lookup service for i18n domain names.
-   Instead of converting to UCS4 and encoding according to Section 3.2,
-   and then calling the DNS resolver, a program would contact this new
-   service when seeing a domain name with characters outside the allowed
-   range.
-
-   Such solutions have various problems. There are many directory ser-
-   vices and proposals for how to use them in a way similar to DNS. For
-   an overview and a specific proposal, see [Kle96].  However, while
-   there are many proposals, a real service containing the necessary
-   data and providing the wide installed base and distributed updating
-   is in DNS does not exist.
-
-   Most directory service proposals also do not offer uniqueness.
-   Defining unique names again for a separate service will duplicate
-   much of the work done for DNS. If uniqueness is not guaranteed, the
-
-
-
-                       Expires End of January 1998     [Page 13]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   user is bundened with additional selection steps.
-
-   Using a separate lookup service for the internationalization of
-   domain names also results in more complex implementations than the
-   proposal made in this draft. Contrary to what some people might
-   expect, the use of a separate lookup service also does not solve a
-   capacity problem with DNS, because there is no such problem, nor will
-   one be created with the introduction of i18n domain names.
-
-
-6. Generic Considerations
-
-
-
-6.1 Security Considerations
-
-   This proposal is believed not to raise any other security considera-
-   tions than the current use of the domain name system.
-
-
-6.2 Internationalization Considerations
-
-   This proposal addresses internationalization as such. The main addi-
-   tional consideration with respect to internationalization may be the
-   indication of language. However, for concise identifiers such as
-   domain names, language tagging would be too much of a burden and
-   would create complex dependencies with semantics.
-
-
-        NOTE -- This section is introduced based on a recommenda-
-        tion in [RFCIAB]. A similar section addressing internation-
-        alization should be included in all application level
-        internet drafts and RFCs.
-
-
-
-
-
-Acknowledgements
-
-   I am grateful in particular to the following persons for their advice
-   or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E.
-   Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith
-   Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl,
-   Paul A. Vixie, Francois Yergeau, and others.
-
-
-
-
-
-
-                       Expires End of January 1998     [Page 14]
-
-Internet Draft    Internationalization of Domain Names         July=
- 1997
-
-
-Bibliography
-
-   [ASCII]        Coded Character Set -- 7-Bit American Standard Code
-                  for Information Interchange, ANSI X3.4-1986.
-
-   [Dillon96]     M. Dillon, "Multilingual Domain Names", Memra Software
-                  Inc., November 1996 (circulated Dec. 6, 1996 on iahc-
-                  discuss@iahc.org).
-
-   [HTML-I18N]    F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter-
-                  nationalization of the Hypertext Markup Language",
-                  Work in progress (draft-ietf-html-i18n-05.txt), August
-                  1996.
-
-   [iNORM]        M. Duerst, "Normalization of Internationalized Identi-
-                  fiers", draft-duerst-i18n-norm-00.txt, July 1997.
-
-   [ISO3166]      ISO 3166, "Code for the representation of names of
-                  countries", ISO 3166:1993.
-
-   [ISO10646]     ISO/IEC 10646-1:1993. International standard -- Infor-
-                  mation technology -- Universal multiple-octet coded
-                  character Set (UCS) -- Part 1: Architecture and basic
-                  multilingual plane.
-
-   [Kle96]        J. Klensin and T. Wolf, Jr., "Domain Names and Company
-                  Name Retrieval", Work in progress (draft-klensin-tld-
-                  whois-01.txt), November 1996.
-
-   [RFC1034]      P. Mockapetris, "Domain Names - Concepts and Facili-
-                  ties", ISI, Nov. 1987.
-
-   [RFC1035]      P. Mockapetris, "Domain Names - Implementation and
-                  Specification", ISI, Nov. 1987.
-
-   [RFC1522]      K. Moore, "MIME (Multipurpose Internet Mail Exten-
-                  sions) Part Two: Message Header Extensions for Non-
-                  ASCII Text", University of Tennessee, September 1993.
-
-   [RFC1642]      D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor-
-                  mation Format of Unicode", Taligent Inc., July 1994.
-
-   [RFC1730]      C. Malamud and M. Rose, "Principles of Operation for
-                  the TPC.INT Subdomain: General Principles and Policy",
-                  Internet Multicasting Service, October 1993.
-
-   [RFC1738]      T. Berners-Lee, L. Masinter, and M. McCahill,
-                   "Uniform Resource Locators (URL)", CERN, Dec. 1994.
-
-
-
-                       Expires End of January 1998     [Page 15]
-
-Internet Draft    Internationalization of Domain Names         July 1997
-
-
-   [RFC2044]      F. Yergeau, "UTF-8, A Transformation Format of Unicode
-                  and ISO 10646", Alis Technologies, October 1996.
-
-   [RFCIAB]       C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R.
-                  Atkinson, M. Crispin, P. Svanberg, "Report from the
-                  IAB Character Set Workshop", October 1996 (currently
-                  available as draft-weider-iab-char-wrkshop-00.txt).
-
-   [Unicode]      The Unicode Consortium, "The Unicode Standard, Version
-                  2.0", Addison-Wesley, Reading, MA, 1996.
-
-   [Yer96]        F. Yergeau, "Internationalization of URLs", Alis Tech-
-                  nologies,
-                 =
- <http://www.alis.com:8085/~yergeau/url-00.html>.
-
-
-
-Author's Address
-
-   Martin J. Duerst
-   World Wide Web Consortium
-   Keio Research Institute at SFC
-   Keio University
-   5322 Endo
-   Fujisawa
-   252-8520 Japan
-
-   Tel: +81 466 49 11 70
-   E-mail: mduerst@w3.org
-
-
-     NOTE -- Please write the author's name with u-Umlaut wherever
-     possible, e.g. in HTML as D&uuml;rst.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-                       Expires End of January 1998     [Page 16]
-
diff --git a/doc/draft/draft-duerst-dns-i18n-03.txt b/doc/draft/draft-duerst-dns-i18n-03.txt
new file mode 100644
index 00000000..d09a2ded
--- /dev/null
+++ b/doc/draft/draft-duerst-dns-i18n-03.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt
new file mode 100644
index 00000000..b9988762
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt
@@ -0,0 +1,278 @@
+
+INTERNET-DRAFT                                      Andreas Gustafsson
+draft-ietf-dnsext-axfr-clarify-00.txt                     Nominum Inc.
+                                                            March 2000
+
+
+               DNS Zone Transfer Protocol Clarifications
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Abstract
+
+   In the Domain Name System, zone data is replicated among
+   authoritative DNS servers by means of the "zone transfer" protocol,
+   also known as the "AXFR" protocol.  This memo clarifies, updates, and
+   adds missing detail to the original AXFR protocol specification in
+   RFC1034.
+
+1. Introduction
+
+   The original definition of the DNS zone transfer protocol consists of
+   a single paragraph in [RFC1034] section 4.3.5 and some additional
+   notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
+   serve as the sole basis for constructing interoperable
+   implementations.  This document is an attempt to provide a more
+   complete definition of the protocol.  Where the text in RFC1034
+   conflicts with existing practice, the existing practice has been
+   codified in the interest of interoperability.
+
+
+
+
+Expires September 2000                                          [Page 1]
+
+draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+2. The zone transfer request
+
+   To initiate a zone transfer, the slave server sends a zone transfer
+   request to the master server over a reliable transport such as TCP.
+   The form of this request is specified in sufficient detail in RFC1034
+   and needs no further clarification.
+
+3. The zone transfer response
+
+   If the master server is unable or unwilling to provide a zone
+   transfer, it MUST respond with a single DNS message containing an
+   appropriate RCODE other than NOERROR.
+
+   If a zone transfer can be provided, the master server sends one or
+   more DNS messages containing the zone data as described below.
+
+3.1. Multiple answers per message
+
+   The zone data in a zone transfer response is a sequence of answer
+   RRs.  These RRs are transmitted in the answer section(s) of one or
+   more DNS response messages.
+
+   The AXFR protocol definition in RFC1034 does not make a clear
+   distinction between response messages and answer RRs.  Historically,
+   DNS servers always transmitted a single answer RR per message.  This
+   encoding is wasteful due to the overhead of repeatedly sending DNS
+   message headers and the loss of domain name compression
+   opportunities.  To improve efficiency, some newer servers support a
+   mode where multiple RRs are transmitted in a single DNS response
+   message.
+
+   A master MAY transmit multiple answer RRs per response message up to
+   the largest number that will fit within the 65535 byte limit on TCP
+   DNS message size.  In the case of a small zone, this can cause the
+   entire transfer to be transmitted in a single response message.
+
+   Slaves MUST accept messages containing any number of answer RRs.  For
+   compatibility with old slaves, masters that support sending multiple
+   answers per message SHOULD be configurable to revert to the
+   historical mode of one answer per message, and the configuration
+   SHOULD be settable on a per-slave basis.
+
+3.2. DNS message header contents
+
+
+
+
+Expires September 2000                                          [Page 2]
+
+draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
+
+
+   RFC1034 does not specify the contents of the DNS message header of
+   the zone transfer response messages.  The header of each message MUST
+   be as follows:
+
+       ID      Copy from request
+       QR      1
+       OPCODE  QUERY
+       AA      1 (but MAY be 0 when RCODE is nonzero)
+       TC      0
+       RD      Copy from request
+       RA      Set according to availability of recursion
+       Z       000
+       RCODE   0 or error code
+
+   The slave MUST check the RCODE and abort the transfer if it is
+   nonzero.  It SHOULD check the ID of the first message received and
+   abort the transfer if it does not match the ID of the request.  The
+   ID SHOULD be ignored in subsequent messages, and fields other than
+   RCODE and ID SHOULD be ignored in all messages, to ensure
+   interoperability with certain older implementations which transmit
+   incorrect or arbitrary values in these fields.
+
+3.3. Additional section and SIG processing
+
+   Zone transfer responses are not subject to any kind of additional
+   section processing or automatic inclusion of SIG records.  SIG RRs in
+   the zone data are treated exactly the same as any other RR type.
+
+3.4. The question section
+
+   RFC1034 does not specify whether zone transfer response messages have
+   a question section or not.  The initial message of a zone transfer
+   response SHOULD have a question section identical to that in the
+   request.  Subsequent messages SHOULD NOT have a question section,
+   though the final message MAY.  The receiving slave server MUST accept
+   any combination of messages with and without a question section.
+
+3.5. The authority section
+
+   The master server MUST transmit messages with an empty authority
+   section.  Slaves MUST ignore any authority section contents they may
+   receive from masters that do not comply with this requirement.
+
+3.6. The additional section
+
+   The additional section MAY contain additional RRs such as transaction
+   signatures.  The slave MUST ignore any unexpected RRs in the
+   additional section.
+
+
+
+Expires September 2000                                          [Page 3]
+
+draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
+
+
+4. Glue
+
+   Zone transfers MAY contain glue RRs pertaining to NS records in the
+   zone.  An RR is considered a glue RR when it is not within the zone
+   being transferred.  A slave MUST recognize glue RRs as such; it MUST
+   NOT treat them as authoritative data.
+
+   Note that classifying an RR as glue or non-glue may not be possible
+   until the entire zone has been received so that the zone cuts defined
+   by the zone's NS records can be determined.
+
+5. Transmission order
+
+   RFC1034 states that "The first and last messages must contain the
+   data for the top authoritative node of the zone".  This is not
+   consistent with existing practice.  All known master implementations
+   send, and slave implementations expect to receive, the zone's SOA RR
+   as the first and last record of the transfer.  Any other RRs at the
+   zone's apex are transmitted only once.
+
+   Therefore, the quoted sentence is hereby changed to read "The first
+   and last RR transmitted must be the SOA record of the zone".
+
+   The initial and final SOA record MUST be identical, with the possible
+   exception of case and compression.  In particular, they MUST have the
+   same serial number.
+
+   The transmission order of all other RRs in the zone, including glue
+   records, is undefined.
+
+References
+
+   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
+   November 1987.
+
+   [RFC1035] - Domain Names - Implementation and Specifications, P.
+   Mockapetris, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+Author's Address
+
+   Andreas Gustafsson
+   Nominum Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+   USA
+
+
+
+Expires September 2000                                          [Page 4]
+
+draft-ietf-dnsext-axfr-clarify-00.txt                         March 2000
+
+
+   Phone: +1 650 779 6004
+
+   Email: gson@nominum.com
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published and
+   distributed, in whole or in part, without restriction of any kind,
+   provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires September 2000                                          [Page 5]
+
diff --git a/doc/draft/draft-ietf-dnsext-ixfr-00.txt b/doc/draft/draft-ietf-dnsext-ixfr-00.txt
new file mode 100644
index 00000000..f81b5521
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-ixfr-00.txt
@@ -0,0 +1,557 @@
+INTERNET DRAFT                                                   M. Ohta
+draft-ietf-dnsext-ixfr-00.txt              Tokyo Institute of Technology
+                                                              March 2000
+
+                    Incremental Zone Transfer in DNS
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   Copyright (C) The Internet Society (March/5/2000).  All Rights
+   Reserved.
+
+Abstract
+
+   This document proposes extensions to the DNS protocols to provide an
+   incremental zone transfer (IXFR) mechanism.
+
+1. Introduction
+
+   For rapid propagation of changes to a DNS database [STD13], it is
+   necessary to reduce latency by actively notifying servers of the
+   change.  This is accomplished by the NOTIFY extension of the DNS
+   [NOTIFY].
+
+   The current full zone transfer mechanism (AXFR) is not an efficient
+   means to propagate changes to a small part of a zone, as it transfers
+   the entire zone file.
+
+   Incremental transfer (IXFR) as proposed is a more efficient
+   mechanism, as it transfers only the changed portion(s) of a zone.
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 1]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+   In this document, a secondary name server which requests IXFR is
+   called an IXFR client and a primary or secondary name server which
+   responds to the request is called an IXFR server.
+
+   The AXFR specification is very terse, and in practice it does not
+   contain sufficient information to construct interoperable
+   implementations.  [XFRCLARIFY] gives the clarification on the AXFR
+   specification based on existing practice, which is, unless otherwise
+   noted, also applicable to IXFR.
+
+2. Brief Description of the Protocol
+
+   If an IXFR client, which likely has an older version of a zone,
+   thinks it needs new information about the zone (typically through SOA
+   refresh timeout or the NOTIFY mechanism), it sends an IXFR message
+   containing the SOA serial number of its, presumably outdated, copy of
+   the zone.
+
+   An IXFR server should keep record of the newest version of the zone
+   and the differences between that copy and several older versions.
+   When an IXFR request with an older version number is received, the
+   IXFR server needs to send only the differences required to make that
+   version current.  Alternatively, the server may choose to transfer
+   the entire zone just as in a normal full zone transfer.
+
+   When a zone has been updated, it should be saved in stable storage
+   before the new version is used to respond to IXFR (or AXFR) queries.
+   Otherwise, if the server crashes, data which is no longer available
+   may have been distributed to secondary servers, which can cause
+   persistent database inconsistencies.
+
+   If an IXFR query with the same or newer version number than that of
+   the server is received, it is replied to with a single SOA record of
+   the server's current version, just as a SOA query before TCP AXFR.
+
+   Transport of a query may be by either UDP or TCP.  If an IXFR query
+   is via UDP, the IXFR server may attempt to reply using UDP if the
+   entire response can be contained in a single UDP packet.  If the UDP
+   reply does not fit, the query is responded to with a single SOA
+   record of the server's current version to inform the client that a
+   TCP query should be initiated.
+
+   Thus, a client should first make an IXFR query using UDP.  If the
+   query type or other part of the query is not recognized by the
+   server, an AXFR (preceded by a UDP SOA query) should be tried,
+   ensuring backward compatibility.  If the query response is a single
+   packet with the entire new zone, or if the server does not have a
+   newer version than the client, everything is done.  Otherwise, a TCP
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 2]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+   IXFR query should be tried.
+
+   To ensure integrity, servers should use UDP checksums for all UDP
+   responses.  A cautious client which receives a UDP packet with a
+   checksum value of zero should ignore the result and try a TCP IXFR
+   instead.
+
+   The query type value of IXFR assigned by IANA is 251.
+
+3. Query Format
+
+   The IXFR query packet format is the same as that of a normal DNS
+   query, but with the query type being IXFR and the authority section
+   containing the SOA record of client's version of the zone.
+
+4. Response Format
+
+   If incremental zone transfer is not available, the entire zone is
+   returned.  The first and the last RR of the response is the SOA
+   record of the zone.  I.e. the behavior is the same as an AXFR
+   response except the query type is IXFR.
+
+   If incremental zone transfer is available, one or more difference
+   sequences is returned.  The list of difference sequences is preceded
+   and followed by a copy of the server's current version of the SOA.
+
+   Each difference sequence represents one update to the zone (one SOA
+   serial change) consisting of deleted RRs and added RRs.  The first RR
+   of the deleted RRs is the older SOA RR and the first RR of the added
+   RRs is the newer SOA RR.
+
+   Modification of an RR is performed first by removing the original RR
+   and then adding the modified one.
+
+   A difference sequence which indicates the removal of a non-existent
+   RR is an indication of an error that the IXFR client is out-of-sync
+   with the IXFR server. The IXFR SHOULD be aborted, and an AXFR
+   requested from the same server.  A difference sequence which
+   indicates the addition of a seemingly duplicate (through a node may
+   have multiple TXT RRs of the duplicated content) or conflicting RR
+   may just be a result of malformed zone ando should be treated just as
+   a AXFR with malformed zone content.
+
+   The sequences of differential information are ordered oldest first
+   newest last.  Thus, the differential sequences are the history of
+   changes made since the version known by the IXFR client up to the
+   server's current version.
+
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 3]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+   RR sets (RRs of the same RR types) in the incremental transfer
+   messages may be partial.  For examle, if a single RR of multiple RRs
+   of the same RR type changes, only the changed RR needs to be
+   transferred.
+
+   An IXFR client, should only replace an older version with a newer
+   version after all the differences have been successfully processed.
+
+   An incremental response is different from that of a non-incremental
+   response in that it begins with two SOA RRs, the server's current SOA
+   followed by the SOA of the client's version which is about to be
+   replaced.
+
+   To determine whether an IXFR response received over TCP is
+   incremental or not, it is necessary to try to receive the first two
+   answer RRs in the answer stream (which may or may not involve
+   receiving two TCP DNS messages).  The first RR is always an SOA.  If
+   the second RR does not exist, the client copy of the zone is up to
+   date and no zone transfer is necessary.  If the second RR is an SOA
+   with a serial number different from the first SOA, the response is
+   incremental, in IXFR format.  If it is a non-SOA RR or a SOA RR with
+   the same serial number as the initial SOA RR, it is a nonincremental
+   response in AXFR format.  The last case cannot arise unless the zone
+   is malformed containing only the SOA record without NS records.
+
+   This is the only way to identify an incremental response.  A slave
+   cannot reliably identify an incremental response based on the
+   presence or absence of a question section, the QTYPE field of a
+   possible question section, or the number of response RRs per message,
+
+5. Purging Strategy
+
+   An IXFR server can not be required to hold all previous versions
+   forever and may delete them anytime. In general, there is a trade-off
+   between the size of storage space and the possibility of using IXFR.
+
+   Information about older versions should be purged if the total length
+   of an IXFR response would be longer than that of an AXFR response.
+   Given that the purpose of IXFR is to reduce AXFR overhead, this
+   strategy is quite reasonable.  The strategy assures that the amount
+   of storage required is at most twice that of the current zone
+   information.
+
+   Information older than the SOA expire period should also be purged.
+
+6. Optional Condensation of Multiple Versions
+
+   An IXFR server may optionally condense multiple difference sequences
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 4]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+   into a single difference sequence, thus, dropping information on
+   intermediate versions.
+
+   This may be beneficial if a lot of versions, not all of which are
+   useful, are generated. For example, if multiple ftp servers share a
+   single DNS name and the IP address associated with the name is
+   changed once a minute to balance load between the ftp servers, it is
+   not so important to keep track of all the history of changes.
+
+   But, this feature may not be so useful if an IXFR client has access
+   to two IXFR servers: A and B, with inconsistent condensation results.
+   The current version of the IXFR client, received from server A, may
+   be unknown to server B. In such a case, server B can not provide
+   incremental data from the unknown version and a full zone transfer is
+   necessary.
+
+   Condensation is completely optional. Clients can't detect from the
+   response whether the server has condensed the reply or not.
+
+   For interoperability, IXFR servers, including those without the
+   condensation feature, should not flag an error even if it receives a
+   client's IXFR request with a version number known not to exist (which
+   means that the server has versions with version numbers newer and
+   older than, but not equal to, the version number) and should,
+   instead, attempt to perform a full zone transfer by replying with a
+   single SOA record of the server's current version (UDP case) or with
+   a full zone content (UDP or TCP case).
+
+7. Example
+
+   Given the following three generations of data with the current serial
+   number of 3,
+
+      JAIN.AD.JP.         IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
+                                        1 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      NEZU.JAIN.AD.JP.    IN A   133.69.136.5
+
+   NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
+
+      jain.ad.jp.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
+                                        2 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4
+                          IN A   192.41.197.2
+
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 5]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+   One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
+
+      JAIN.AD.JP.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
+                                        3 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3
+                          IN A   192.41.197.2
+
+   The following IXFR query
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY                                     |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | <empty>                                           |
+                 +---------------------------------------------------+
+      Authority  | JAIN.AD.JP.         IN SOA serial=1               |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+   could be replied to with the following full zone transfer message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN NS  NS.JAIN.AD.JP.         |
+                 | NS.JAIN.AD.JP.      IN A   133.69.136.1           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+   or with the following incremental message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 6]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN SOA serial=1               |
+                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
+                 | JAIN.AD.JP.         IN SOA serial=2               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=2               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+   or with the following condensed incremental message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN SOA serial=1               |
+                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+   or, if UDP packet overflow occurs, with the following message:
+
+
+
+
+
+
+
+
+
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 7]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+8. Acknowledgements
+
+   The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
+   and Jon Postel.
+
+   For the refinement of the protocol and documentation, many people
+   have contributed including, but not limited to, Anant Kumar, Robert
+   Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz, Andreas
+   Gustafsson, Josh Littlefield, Olafur Gudmundsson, William King and
+   the members of the IETF DNSEXT working group.
+
+9. References
+
+   [NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone
+   Changes (DNS NOTIFY)", RFC1996, August 1996.
+
+   [STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035),
+   November 1987.
+
+   [XFRCLARIFY]
+
+10. Security Considerations
+
+   Though DNS is related to several security problems, no attempt is
+   made to fix them in this document.
+
+   This document is believed to introduce no additional security
+   problems to the current DNS protocol.
+
+11. Author's Address
+
+   Masataka Ohta
+   Computer Center, Tokyo Institute of Technology
+   2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN
+
+   Phone: +81-3-5734-3299, Fax: +81-3-5734-3415
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 8]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+   EMail: mohta@necom830.hpcl.titech.ac.jp
+
+   Comments should be directed to DNSEXT WG <namedroppers@ops.ietf.org>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M. Ohta               Expires on September 5, 2000              [Page 9]
+
+INTERNET DRAFT      Incremental Zone Transfer in DNS          March 2000
+
+
+12. Full Copyright Statement
+
+   "Copyright (C) The Internet Society (March/5/2000).  All Rights
+   Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M. Ohta               Expires on September 5, 2000             [Page 10]
+
diff --git a/doc/draft/draft-ietf-dnsext-sig-zero-00.txt b/doc/draft/draft-ietf-dnsext-sig-zero-01.txt
index 8052d1f7..971b13d3 100644
--- a/doc/draft/draft-ietf-dnsext-sig-zero-00.txt
+++ b/doc/draft/draft-ietf-dnsext-sig-zero-01.txt
@@ -1,24 +1,23 @@
+
 INTERNET-DRAFT                                    Donald E. Eastlake 3rd
 UPDATES RFC 2535                                                Motorola
 
-Expires: September 2000                                       March 2000
+Expires: October 2000                                         April 2000
 
 
 
            DNS Request and Transaction Signatures ( SIG(0)s )
            --- ------- --- ----------- ---------- - ------- -
-                     draft-ietf-dnsext-sig-zero-00.txt
+                  <draft-ietf-dnsext-sig-zero-01.txt>
 
 
 
 Status of This Document
 
-   This draft, file name draft-ietf-dnsext-sig-zero-00.txt, is intended
-   to become a Proposed Standard RFC updating Proposed Standard [RFC
-   2535].  Distribution of this document is unlimited. Comments should
-   be sent to the DNS Working Group mailing list
-   <namedroppers@internic.net> or to the author.  [This is the successor
-   to draft-ietf-dnsind-sig-zero-01.txt.]
+   This draft is intended to become a Proposed Standard RFC updating
+   Proposed Standard [RFC 2535].  Distribution of this document is
+   unlimited. Comments should be sent to the DNS Working Group mailing
+   list <namedroppers@internic.net> or to the author.
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  Internet-Drafts are working
@@ -26,10 +25,11 @@ Status of This Document
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.
 
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet- Drafts as reference
-   material or to cite them other than as "work in progress."
+   Internet-Drafts are draft documents valid for a maximum of six
+   months.  Internet-Drafts may be updated, replaced, or obsoleted by
+   other documents at any time.  It is not appropriate to use Internet-
+   Drafts as reference material or to cite them other than as a
+   ``working draft'' or ``work in progress.''
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt
@@ -57,7 +57,7 @@ Abstract
 D. Eastlake 3rd                                                 [Page 1]
 
 
-INTERNET-DRAFT                 DNS SIG(0)                     March 2000
+INTERNET-DRAFT                 DNS SIG(0)                     April 2000
 
 
 Acknowledgments
@@ -67,6 +67,7 @@ Acknowledgments
    acknowledged:
 
         Olafur Gudmundsson
+        Ed Lewis
         Brian Wellington
 
 
@@ -111,11 +112,10 @@ Table of Contents
 
 
 
-
 D. Eastlake 3rd                                                 [Page 2]
 
 
-INTERNET-DRAFT                 DNS SIG(0)                     March 2000
+INTERNET-DRAFT                 DNS SIG(0)                     April 2000
 
 
 1. Introduction
@@ -127,8 +127,8 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
    transactions / responses.  Such a resource record, because it has a
    type covered field of zero, is frequently called a SIG(0). The
    changes are based on implementation and attempted implementation
-   experience with TSIG [draft-ietf-{dnsind|dnsext}-tsig-*.txt] and the
-   [RFC 2535] specification for SIG(0).
+   experience with TSIG [draft-ietf-dnsext-tsig-*.txt] and the [RFC
+   2535] specification for SIG(0).
 
    Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
    and 4.3.  No changes are made herein related to the KEY or NXT RRs or
@@ -143,17 +143,14 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
 
 2. SIG(0) Design Rationale
 
-   The authenticated data origin and data existence denial services of
-   secure DNS protect only regular data resource records (RRs) or
-   authenticatably deny their nonexistence.  These services provide no
-   protection for glue records, DNS requests, no protection for message
-   headers on requests or responses, and no protection of the overall
-   integrity of a response.
-
-   If header bits are falsely set or the like by a bad server, there is
-   little that can be done.  However, it is possible to add transaction
-   and query authentication to be sure that queries and responses and
-   not tampered with in transit.
+   SIG(0) provides protection for DNS transactions and requests that is
+   not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
+   2535].  The authenticated data origin services of secure DNS either
+   provide protected data resource records (RRs) or authenticatably deny
+   their nonexistence.  These services provide no protection for glue
+   records, DNS requests, no protection for message headers on requests
+   or responses, and no protection of the overall integrity of a
+   response.
 
 
 
@@ -161,19 +158,22 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
 
    Transaction authentication means that a requester can be sure it is
    at least getting the messages from the server it queried and that the
-   response is from the request it sent (i.e., that these messages have
-   not been diddled in transit).  This is accomplished by optionally
-   adding either a TSIG RR [draft-ietf-{dnsind|dnsext}-tsig-*.txt] or,
-   as described herein, a SIG(0) resource record at the end of the
-   response which digitally signs the concatenation of the server's
-   response and the corresponding resolver query.
+   received messages are in response to me query it sent.  This is
+   accomplished by optionally adding either a TSIG RR [draft-ietf-
+   dnsext-tsig-*.txt] or, as described herein, a SIG(0) resource record
+   at the end of the response which digitally signs the concatenation of
+   the server's response and the corresponding resolver query.
+
+
+
+
 
 
 
 D. Eastlake 3rd                                                 [Page 3]
 
 
-INTERNET-DRAFT                 DNS SIG(0)                     March 2000
+INTERNET-DRAFT                 DNS SIG(0)                     April 2000
 
 
 2.2 Request Authentication
@@ -214,43 +214,41 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
 
    Because TSIG involves secret keys installed at both the requester and
    server the presence of such a key implies that the other party
-   understands TSIG and likely has the same key installed.  Furthermore,
-   TSIG uses keyed hash authentication codes which are relatively
-   inexpensive to compute.  Thus it is common to authenticate requests
-   with TSIG and responses are authenticated with TSIG if the
+   understands TSIG and very likely has the same key installed.
+   Furthermore, TSIG uses keyed hash authentication codes which are
+   relatively inexpensive to compute.  Thus it is common to authenticate
+   requests with TSIG and responses are authenticated with TSIG if the
    corresponding request is authenticated.
 
    SIG(0) on the other hand, uses public key authentication, where the
-   public keys are stored in DNS as KEY RRs.  Thus, existence of such a
-   KEY RR does not necessarily imply implementation of SIG(0).  In
-   addition, SIG(0) involves relatively expensive public key
-   cryptographic operations that should be minimized and the
-   verification of a SIG(0) involves obtaining and verifying the
+   public keys are stored in DNS as KEY RRs and a private key is stored
+   at the signer.  Existence of such a KEY RR does not necessarily imply
+   implementation of SIG(0).  In addition, SIG(0) involves relatively
+   expensive public key cryptographic operations that should be
+   minimized and the verification of a SIG(0) involves obtaining and
 
 
 D. Eastlake 3rd                                                 [Page 4]
 
 
-INTERNET-DRAFT                 DNS SIG(0)                     March 2000
+INTERNET-DRAFT                 DNS SIG(0)                     April 2000
 
 
-   corresponding KEY which can be an expensive and lengthy operation.
-   Indeed, a policy of using SIG(0) on all requests and verifying it
-   before responding would, for some configurations, lead to a deadly
-   embrace with the attempt to obtain and verify the KEY needed to
-   authenticate the request SIG(0) resulting in additional requests
-   accompanied by a SIG(0) leading to further requests accompanied by a
-   SIG(0), etc.  Furthermore, omitting SIG(0)s when not required on
-   requests halves the number of public key operations required by the
-   transaction.
+   verifying the corresponding KEY which can be an expensive and lengthy
+   operation.  Indeed, a policy of using SIG(0) on all requests and
+   verifying it before responding would, for some configurations, lead
+   to a deadly embrace with the attempt to obtain and verify the KEY
+   needed to authenticate the request SIG(0) resulting in additional
+   requests accompanied by a SIG(0) leading to further requests
+   accompanied by a SIG(0), etc.  Furthermore, omitting SIG(0)s when not
+   required on requests halves the number of public key operations
+   required by the transaction.
 
    For these reasons, SIG(0)s SHOULD only be used on requests when
    necessary to authenticate that the requester has some required
    privilege or identity.  SIG(0)s on replies are defined in such a way
    as to not require a SIG(0) on the corresponding request and still
-   provide transaction protection.  Some responses, such as those
-   involving TKEY [draft-ietf-dnsext-tkey-*.txt], MUST be authenticated
-   with TSIG or SIG(0).  For other replies, whether they are
+   provide transaction protection.  For other replies, whether they are
    authenticated by the server or required to be authenticated by the
    requester SHOULD be a local configuration option.
 
@@ -265,14 +263,15 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
    2535] and this document concerning SIG(0) RRs should be resolved in
    favor of this document.
 
-   For all transaction SIG(0)s, the signer field MUST be the name of the
-   originating server host and there MUST be a KEY RR at that name with
-   the public key corresponding to the private key used to calculate the
-   signature.  (The inverse IP address mapping name for an IP address of
-   the server MAY be used if the relevant KEY is stored there.)
+   For all transaction SIG(0)s, the signer field MUST be a name of the
+   originating host and there MUST be a KEY RR at that name with the
+   public key corresponding to the private key used to calculate the
+   signature.  (The host domain name used may be the inverse IP address
+   mapping name for an IP address of the host if the relevant KEY is
+   stored there.)
 
    For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
-   meaningless.  The TTL fields SHOULD be zero and the CLASS filed
+   meaningless.  The TTL fields SHOULD be zero and the CLASS field
    SHOULD be ANY.  To conserve space, the owner name SHOULD be root (a
    single zero octet).  When SIG(0) authentication on a response is
    desired, that SIG RR must be considered the highest priority of any
@@ -286,32 +285,29 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
 
 
 
+
 D. Eastlake 3rd                                                 [Page 5]
 
 
-INTERNET-DRAFT                 DNS SIG(0)                     March 2000
+INTERNET-DRAFT                 DNS SIG(0)                     April 2000
 
 
 3.1 Calculating Request and Transaction SIGs
 
-   A DNS request may be optionally signed by including one or more
-   SIG(0)s at the end of the query additional information section.  Such
-   SIGs are identified by having a "type covered" field of zero. They
-   sign the preceding DNS request message including DNS header but not
-   including the UDP/IP header or any request SIG(0)s at the end and
-   before the request RR counts have been adjusted for the inclusions of
-   any request SIG(0)s.
+   A DNS request may be optionally signed by including one SIG(0)s at
+   the end of the query additional information section.  Such a SIG is
+   identified by having a "type covered" field of zero. It signs the
+   preceding DNS request message including DNS header but not including
+   the UDP/IP header and before the request RR counts have been adjusted
+   for the inclusions of the request SIG(0).
 
-   Note: requests and response can either have a single TSIG or one or
-   more SIG(0)s but not both a TSIG and a SIG(0).
+   It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
+   (1) the SIG's RDATA section omitting the signature subfield itself,
+   (2) the entire DNS query messages, including DNS header, but not the
+   UDP/IP header and before the reply RR counts have been adjusted for
+   the inclusion of the SIG(0).  That is
 
-   They are calculated by using a "data" (see [RFC 2535], Section 4.1.8)
-   of (1) the SIG's RDATA section omitting the signature subfield
-   itself, (2) the entire DNS query messages, including DNS header, but
-   not the UDP/IP header or any SIG(0) and before the reply RR counts
-   have been adjusted for the inclusion of any SIG(0).  That is
-
-      data = RDATA | request - SIG(0)s
+      data = RDATA | request - SIG(0)
 
    where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
    calculated less the signature itself.
@@ -320,14 +316,14 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
    that produced it.  Such transaction signatures are calculated by
    using a "data" of (1) the SIG's RDATA section omitting the signature
    itself, (2) the entire DNS query message that produced this response,
-   including the query's DNS header and any SIG(0)s but not its UDP/IP
-   header, and (3) the entire DNS response message, including DNS header
-   but not the UDP/IP header or any SIG(0) and before the response RR
-   counts have been adjusted for the inclusion of any SIG(0).
+   including the query's DNS header but not its UDP/IP header, and (3)
+   the entire DNS response message, including DNS header but not the
+   UDP/IP header and before the response RR counts have been adjusted
+   for the inclusion of the SIG(0).
 
    That is
 
-      data = RDATA | full query | response - SIG(0)s
+      data = RDATA | full query | response - SIG(0)
 
    where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
    calculated less the signature itself.
@@ -342,24 +338,28 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
    packet is calculated with "data" as above and for each subsequent
    packet, it is calculated as follows:
 
+      data = RDATA | DNS payload - SIG(0) | previous packet
+
+   where "|" is concatenations, RDATA is as above, and previous packet
+   is the previous DNS payload including DNS header and the SIG(0) but
 
 
 D. Eastlake 3rd                                                 [Page 6]
 
 
-INTERNET-DRAFT                 DNS SIG(0)                     March 2000
-
+INTERNET-DRAFT                 DNS SIG(0)                     April 2000
 
-      data = RDATA | DNS payload - SIG(0)s | previous packet
 
-   where "|" is concatenations, RDATA is as above, and previous packet
-   is the previous DNS payload including DNS header and any SIG(0)s but
    not the TCP/IP header.  Support of SIG(0) for TCP is OPTIONAL.  As an
    alternative, TSIG may be used after, if necessary, setting up a key
    with TKEY [draft-ietf-dnsext-tkey-*.txt].
 
    Except where needed to authenticate an update, TKEY, or similar
-   privileged request, servers are not required to check request SIGs.
+   privileged request, servers are not required to check a request
+   SIG(0).
+
+   Note: requests and response can either have a single TSIG or one
+   SIG(0) but not both a TSIG and a SIG(0).
 
 
 
@@ -373,7 +373,7 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
    mode in use.  For all other responses, it MAY be checked and the
    message rejected if the checks fail.
 
-   If a response SIG(0) checks succeed, such a transaction
+   If a responses SIG(0) check succeed, such a transaction
    authentication SIG does NOT directly authenticate the validity any
    data-RRs in the message.  However, it authenticates that they were
    sent by the queried server and have not been diddled.  (Only a proper
@@ -405,7 +405,7 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
 D. Eastlake 3rd                                                 [Page 7]
 
 
-INTERNET-DRAFT                 DNS SIG(0)                     March 2000
+INTERNET-DRAFT                 DNS SIG(0)                     April 2000
 
 
    The inclusion of the SIG(0) inception and expiration time under the
@@ -415,7 +415,8 @@ INTERNET-DRAFT                 DNS SIG(0)                     March 2000
 
 5. IANA Considerations
 
-   No new fields are created or field values assigned by the document.
+   No new parameters are created or parameter values assigned by the
+   document.
 
 
 
@@ -433,13 +434,12 @@ References
    [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
    March 1999.
 
-   [draft-ietf-{dnsind|dnsext}-tsig-*.txt] - P. Vixie, O. Gudmundsson,
-   D. Eastlake, B. Wellington, "Secret Key Transaction Signatures for
-   DNS (TSIG)".
+   [draft-ietf-dnsext-tsig-*.txt] - P. Vixie, O. Gudmundsson, D.
+   Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS
+   (TSIG)".
 
    [draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key
-   Establishment for DNS  (RR)"
-
+   Establishment for DNS  (RR)".
 
 
 
@@ -463,7 +463,7 @@ References
 D. Eastlake 3rd                                                 [Page 8]
 
 
-INTERNET-DRAFT                 DNS SIG(0)                     March 2000
+INTERNET-DRAFT                 DNS SIG(0)                     April 2000
 
 
 Author's Address
@@ -483,9 +483,9 @@ Author's Address
 
 Expiration and File Name
 
-   This draft expires September 2000.
+   This draft expires October 2000.
 
-   Its file name is draft-ietf-dnsext-sig-zero-00.txt.
+   Its file name is draft-ietf-dnsext-sig-zero-01.txt.
 
 
 
diff --git a/doc/draft/draft-ietf-dnsext-signing-auth-00.txt b/doc/draft/draft-ietf-dnsext-signing-auth-01.txt
index a7468bc0..9fbe1497 100644
--- a/doc/draft/draft-ietf-dnsext-signing-auth-00.txt
+++ b/doc/draft/draft-ietf-dnsext-signing-auth-01.txt
@@ -1,8 +1,8 @@
 
-DNSIND Working Group                          Brian Wellington (NAILabs)
-INTERNET-DRAFT                                              January 2000
+DNSIND Working Group                          Brian Wellington (Nominum)
+INTERNET-DRAFT                                                  May 2000
 
-<draft-ietf-dnsext-signing-auth-00.txt>
+<draft-ietf-dnsext-signing-auth-01.txt>
 
 Updates: RFC 2535
 
@@ -35,7 +35,7 @@ Status of this Memo
    Comments should be sent to the authors or the DNSIND WG mailing list
    namedroppers@internic.net.
 
-   This draft expires on July 31, 2000.
+   This draft expires on November 12, 2000.
 
    Copyright Notice
 
@@ -50,9 +50,9 @@ Abstract
 
 
 
-Expires July 2000                                               [Page 1]
+Expires November 2000                                           [Page 1]
 
-INTERNET-DRAFT          DNSSEC Signing Authority            January 2000
+INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
 
 
    secure resolution process.  Specifically, this affects the
@@ -64,8 +64,8 @@ INTERNET-DRAFT          DNSSEC Signing Authority            January 2000
 This document defines additional restrictions on DNSSEC signatures (SIG)
 records relating to their authority to sign associated data.  The intent
 is to establish a standard policy followed by a secure resolver; this
-policy can be augmented by local rules.  This builds upon [RFC2535] and
-updates section 2.3.6.
+policy can be augmented by local rules.  This builds upon [RFC2535],
+updating section 2.3.6 of that document.
 
 The most significant change is that in a secure zone, zone data is
 required to be signed by the zone key.
@@ -90,7 +90,8 @@ necessary.
 
 SIGs may also be used for transaction security.  In this case, a SIG
 record with a type covered field of 0 is attached to a message, and is
-used to protect message integrity.  This is referred to as a SIG(0).
+used to protect message integrity.  This is referred to as a SIG(0)
+[RFC2535].
 
 The following sections define requirements for all of the fields of a
 SIG record.  These requirements MUST be met in order for a DNSSEC
@@ -105,10 +106,9 @@ SIG, there are requirements that it MUST meet.
 
 
 
-
-Expires July 2000                                               [Page 2]
+Expires November 2000                                           [Page 2]
 
-INTERNET-DRAFT          DNSSEC Signing Authority            January 2000
+INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
 
 
 2.1 - Type Covered
@@ -153,8 +153,8 @@ that future algorithms will impose contraints.
 The signer's name field of a data SIG MUST contain the name of the zone
 to which the data and signature belong.  The combination of signer's
 name, key tag, and algorithm MUST identify a zone key if the SIG is to
-be considered material.  As this document defines a standard policy,
-this can be overriden by local configuration.
+be considered material.  This document defines a standard policy for
+DNSSEC validation; local policy may override the standard policy.
 
 There are no restrictions on the signer field of a SIG(0) record.  The
 combination of signer's name, key tag, and algorithm MUST identify a key
@@ -162,15 +162,15 @@ if this SIG(0) is to be processed.
 
 
 
-Expires July 2000                                               [Page 3]
+Expires November 2000                                           [Page 3]
 
-INTERNET-DRAFT          DNSSEC Signing Authority            January 2000
+INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
 
 
 2.8 - Signature
 
 There are no restrictions on the signature field.  The signature will be
-verified at some point, but does not need to be examined prior to pre-
+verified at some point, but does not need to be examined prior to
 verification unless a future algorithm imposes constraints.
 
 3 - The Signing KEY Record
@@ -189,9 +189,9 @@ generated the signature until the verification is performed.
 3.1 - Type Flags
 
 The signing KEY record MUST have a flags value of 00 or 01
-(authentication allowed, confidentiality optional) [RFC2535, 3.1.2].  If
-a key is not permitted to authenticate data, a DNSSEC resolver MUST NOT
-trust any signature that it generates.
+(authentication allowed, confidentiality optional) [RFC2535, 3.1.2].  A
+DNSSEC resolver MUST only trust signatures generated by keys that are
+permitted to authenticate data.
 
 
 3.2 - Name Flags
@@ -208,29 +208,29 @@ MUST be 01 (zone) [RFC2535, 3.1.2].  This updates RFC 2535, section
 ignore all keys that are not zone keys unless local policy dictates
 otherwise.
 
-The primary reason that host and/or user keys were allowed to generate
-material DNSSEC signatures was to allow dynamic update without online
-zone keys.  The desire to avoid online signing keys cannot be achieved,
-though, because they are necessary to sign NXT and SOA sets [SSU].
-These online zone keys can sign any incoming data, thus removing the
-need for host/user key signatures stored in the DNS.
-
+The primary reason that RFC 2535 allows host and user keys to generate
+material DNSSEC signatures is to allow dynamic update without online
+zone keys; that is, avoid storing private keys in an online server.  The
+desire to avoid online signing keys cannot be achieved, though, because
+they are necessary to sign NXT and SOA sets [SSU].  These online zone
+keys can sign any incoming data.  Removing the goal of having no online
+keys removes the reason to allow host and user keys to generate material
 
 
 
-Expires July 2000                                               [Page 4]
+Expires November 2000                                           [Page 4]
 
-INTERNET-DRAFT          DNSSEC Signing Authority            January 2000
+INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
 
 
-This simplifies the validation process.  If data must be signed by a
-zone key, determining whether a key is authorized to sign an RRset
-requires finding the enclosing zone of the RRset, and following a chain
-of trusted zone keys to a known trusted key (which may be the DNS root
-key).  If host and user keys were permitted to generate material
-signatures, following a chain of trust to a trusted DNSSEC key could
-involve any number of non-zone keys and a non-trivial amount of work to
-determine if all such keys have the proper authority.
+signatures.  in the DNS.
+
+Limiting material signatures to zone keys simplifies the validation
+process.  The length of the verification chain is bounded by the name's
+label depth.  The authority of a key is clearly defined; a resolver does
+not need to make a potentially complicated decision to determine whether
+a key can sign data.  amount of work to determine if all such keys have
+the proper authority.
 
 Finally, there is no additional flexibility granted by allowing
 host/user key generated material signatures.  As long as users and hosts
@@ -274,9 +274,9 @@ record.
 
 
 
-Expires July 2000                                               [Page 5]
+Expires November 2000                                           [Page 5]
 
-INTERNET-DRAFT          DNSSEC Signing Authority            January 2000
+INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
 
 
 4 - Security considerations
@@ -317,7 +317,7 @@ informative comments (in alphabetical order):
 
 [SSU]      B. Wellington, ``Simple Secure Domain Name System (DNS)
            Dynamic Update,'' draft-ietf-dnsext-simple-secure-
-           update-00.txt, NAILabs, January 2000.
+           update-01.txt, Nominum, May 2000.
 
 
 
@@ -330,21 +330,20 @@ informative comments (in alphabetical order):
 
 
 
-Expires July 2000                                               [Page 6]
+Expires November 2000                                           [Page 6]
 
-INTERNET-DRAFT          DNSSEC Signing Authority            January 2000
+INTERNET-DRAFT          DNSSEC Signing Authority                May 2000
 
 
 7 - Author's Address
 
 
    Brian Wellington
-       NAILabs
-       Network Associates
-       3060 Washington Road (Rt. 97)
-       Glenwood, MD 21738
-       +1 443 259 2369
-       <bwelling@tislabs.com>
+       Nominum, Inc.
+       950 Charter Street
+       Redwood City, CA 94063
+       +1 650 779 6022
+       <Brian.Wellington@nominum.com>
 
 
 8 - Full Copyright Statement
@@ -386,5 +385,6 @@ FITNESS FOR A PARTICULAR PURPOSE."
 
 
 
-Expires July 2000                                               [Page 7]
+
+Expires November 2000                                           [Page 7]
 
diff --git a/doc/draft/draft-ietf-dnsext-simple-secure-update-00.txt b/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt
index cd49664e..1034426a 100644
--- a/doc/draft/draft-ietf-dnsext-simple-secure-update-00.txt
+++ b/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt
@@ -1,14 +1,14 @@
 DNSIND Working Group                          Brian Wellington (NAILabs)
-INTERNET-DRAFT                                              January 2000
+INTERNET-DRAFT                                                  May 2000
 
-<draft-ietf-dnsext-simple-secure-update-00.txt>
+<draft-ietf-dnsext-simple-secure-update-01.txt>
 
 Updates: RFC 2535, RFC 2136,
 Replaces: RFC 2137, [update2]
 
 
 
-         Simple Secure Domain Name System (DNS) Dynamic Update
+             Secure Domain Name System (DNS) Dynamic Update
 
 
 Status of this Memo
@@ -35,7 +35,7 @@ Status of this Memo
    Comments should be sent to the authors or the DNSIND WG mailing list
    namedroppers@internic.net.
 
-   This draft expires on July 31, 2000.
+   This draft expires on November 12, 2000.
 
    Copyright Notice
 
@@ -49,9 +49,9 @@ Abstract
 
 
 
-Expires July 2000                                               [Page 1]
+Expires November 2000                                           [Page 1]
 
-INTERNET-DRAFT        Simple Secure Dynamic Update          January 2000
+INTERNET-DRAFT            Secure Dynamic Update                 May 2000
 
 
    to be flexible and useful while requiring as few changes to the
@@ -105,42 +105,39 @@ SIG(0), is more scalable as the public keys are stored in DNS.
 
 
 
-Expires July 2000                                               [Page 2]
+Expires November 2000                                           [Page 2]
 
-INTERNET-DRAFT        Simple Secure Dynamic Update          January 2000
+INTERNET-DRAFT            Secure Dynamic Update                 May 2000
 
 
 1.3 - Comparison of data authentication and message authentication
 
+Message based authentication, using TSIG or SIG(0), provides protection
+for the entire message with a single signing and single verification
+which, in the case of TSIG, is a relatively inexpensive MAC creation and
+check.  For update requests, this signature can establish, based on
+policy or key negotation, the authority to make the request.
+
 DNSSEC SIG records can be used to protect the integrity of individual
-RRs or RRsets in an update message.  However, this cannot sufficiently
-protect the dynamic update request.
+RRs or RRsets in a DNS message with the authority of the zone owner.
+However, this cannot sufficiently protect the dynamic update request.
+
+Using SIG records to secure RRsets in an update request is incompatible
+with the design of update, as described below, and would in any case
+require multiple expensive public key signatures and verifcations.
 
 SIG records do not cover the message header, which includes record
 counts.  Therefore, it is possibly to maliciously insert or remove
-RRsets without causing a verification failure.
-
-A SIG record can be used to protect the contents of the zone section (an
-SOA record).  Including such a SIG record in the zone section violates
-the dynamic update protocol.
+RRsets in an update request without causing a verification failure.
 
 If SIG records were used to protect the prerequisite section, it would
 be impossible to determine whether the SIGs themselves were a
 prerequisite or simply used for validation.
 
-In the update section, signing requests to add an RRset is
-straightforward, and this signature could be permanently used to protect
-the data, as specified in [RFC2535].  However, if an RRset is deleted,
-there is no data for a SIG to cover.
-
-Requiring SIGs in the zone, prerequisite, and update sections might be a
-feasible solution.  Multiple signatures would be generated and verified
-for each update, though, which requires considerable processing time.
-
-Message based authentication, using TSIG or SIG(0), avoids all of these
-problems.  Only one signature/MAC is generated for the entire message,
-and it protects the integrity of the message header and all sections, as
-well as having the advantage that only one verification is performed.
+In the update section of an update request, signing requests to add an
+RRset is straightforward, and this signature could be permanently used
+to protect the data, as specified in [RFC2535].  However, if an RRset is
+deleted, there is no data for a SIG to cover.
 
 
 1.4 - Data and message signatures
@@ -158,16 +155,15 @@ user keys MAY be used to generate SIG(0) records to authenticate updates
 and MAY be used in the TKEY [TKEY] process to generate TSIG shared
 secrets.  In both cases, no SIG records generated by non-zone keys will
 be used in a DNSSEC validation process unless local policy dictates.
+Authentication of data, once it is present in DNS, only involves DNSSEC
+zone keys and signatures generated by them.
 
 
 
-Expires July 2000                                               [Page 3]
-
-INTERNET-DRAFT        Simple Secure Dynamic Update          January 2000
 
-
-Authentication of data, once it is present in DNS, only involves DNSSEC
-zone keys and signatures generated by them.
+Expires November 2000                                           [Page 3]
+
+INTERNET-DRAFT            Secure Dynamic Update                 May 2000
 
 
 1.5 - Signatory strength
@@ -203,25 +199,6 @@ server MUST indicate failure by returning a message with RCODE REFUSED.
 Other TSIG, SIG(0), or dynamic update errors are returned as specified
 in the appropriate protocol description.
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 2000                                               [Page 4]
-
-INTERNET-DRAFT        Simple Secure Dynamic Update          January 2000
-
-
 3 - Policy
 
 All policy is configured by the zone administrator and enforced by the
@@ -236,6 +213,15 @@ sign the update is permitted to perform the requested updates.  By
 default, a principal MUST NOT be permitted to make any changes to zone
 data; any permissions MUST be enabled though configuration.
 
+
+
+
+
+Expires November 2000                                           [Page 4]
+
+INTERNET-DRAFT            Secure Dynamic Update                 May 2000
+
+
 The policy is fully implemented in the primary zone server's
 configuration for several reasons.  This removes limitations imposed by
 encoding policy into a fixed number of bits (such as the KEY RR's
@@ -270,14 +256,6 @@ of DNS itself.
 
 User types include all data types except SOA, NS, SIG, and NXT.  SOA and
 NS SHOULD NOT be modified by normal users, since these types create or
-
-
-
-Expires July 2000                                               [Page 5]
-
-INTERNET-DRAFT        Simple Secure Dynamic Update          January 2000
-
-
 modify delegation points.  The addition of SIG records can lead to
 attacks resulting in additional workload for resolvers, and the deletion
 of SIG records could lead to extra work for the server if the zone SIG
@@ -292,6 +270,14 @@ Issues concerning updates of KEY records are discussed in the Security
 Considerations section.
 
 
+
+
+
+Expires November 2000                                           [Page 5]
+
+INTERNET-DRAFT            Secure Dynamic Update                 May 2000
+
+
 3.2 - Additional policies
 
 Users are free to implement any policies.  Policies may be as specific
@@ -326,17 +312,27 @@ the server.
 
 The server MUST also, if necessary, generate a new SOA record and new
 NXT records, and sign these with the appropriate zone keys.  NXT records
+are explicitly forbidden.  SOA updates are allowed, since the
+maintenance of SOA parameters is outside of the scope of the DNS
+protocol.
+
+
+
+
+
 
 
 
-Expires July 2000                                               [Page 6]
-
-INTERNET-DRAFT        Simple Secure Dynamic Update          January 2000
 
 
-are explicitly forbidden.  SOA updates are allowed, since the
-maintenance of SOA parameters is outside of the scope of the DNS
-protocol.
+
+
+
+
+Expires November 2000                                           [Page 6]
+
+INTERNET-DRAFT            Secure Dynamic Update                 May 2000
+
 
 5 - Security considerations
 
@@ -382,37 +378,35 @@ informative comments (in alphabetical order):
 [RFC2535]  D. Eastlake, ``Domain Name System Security Extensions,'' RFC
            2065, IBM, March 1999.
 
+[TSIG]     P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington
+           ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
+           ietf-dnsext-tsig-00.txt, ISC & NAILabs & IBM & NAILabs, March
+           2000.
 
 
 
-Expires July 2000                                               [Page 7]
+Expires November 2000                                           [Page 7]
 
-INTERNET-DRAFT        Simple Secure Dynamic Update          January 2000
+INTERNET-DRAFT            Secure Dynamic Update                 May 2000
 
 
-[TSIG]     P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington
-           ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
-           ietf-dnsind-tsig-13.txt, ISC & NAILabs & IBM & NAILabs,
-           December 1999.
-
 [TKEY]     D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
-           draft-ietf-dnsind-tkey-03.txt, IBM, December 1999.
+           draft-ietf-dnsext-tkey-02.txt, IBM, April 2000.
 
 [signing-auth]
            B. Wellington ``Domain Name System Security (DNSSEC) Signing
-           Authority,'' draft-ietf-dnsext-signing-auth-00.txt, NAILabs,
-           January 2000.
+           Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum,
+           May 2000.
 
 8 - Author's Address
 
 
    Brian Wellington
-       NAILabs
-       Network Associates
-       3060 Washington Road (Rt. 97)
-       Glenwood, MD 21738
-       +1 443 259 2369
-       <bwelling@tislabs.com>
+       Nominum, Inc.
+       950 Charter Street
+       Redwood City, CA 94063
+       +1 650 779 6022
+       <Brian.Wellington@nominum.com>
 
 
 9 - Full Copyright Statement
@@ -438,14 +432,6 @@ revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an "AS
 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
-
-
-
-Expires July 2000                                               [Page 8]
-
-INTERNET-DRAFT        Simple Secure Dynamic Update          January 2000
-
-
 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
 FITNESS FOR A PARTICULAR PURPOSE."
@@ -455,47 +441,5 @@ FITNESS FOR A PARTICULAR PURPOSE."
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 2000                                               [Page 9]
+Expires November 2000                                           [Page 8]
 
diff --git a/doc/draft/draft-ietf-dnsext-tkey-01.txt b/doc/draft/draft-ietf-dnsext-tkey-02.txt
index 6f9b3cc2..5cee98b5 100644
--- a/doc/draft/draft-ietf-dnsext-tkey-01.txt
+++ b/doc/draft/draft-ietf-dnsext-tkey-02.txt
@@ -1,24 +1,22 @@
 
 DNSEXT Working Group                             Donald E. Eastlake, 3rd
 INTERNET-DRAFT                                                  Motorola
-Expires: September 2000                                       March 2000
+Expires: October 2000                                         April 2000
 
 
 
                Secret Key Establishment for DNS (TKEY RR)
                ------ --- ------------- --- --- ----- ---
-                      draft-ietf-dnsext-tkey-01.txt
-
-                         Donald E. Eastlake 3rd
+                    <draft-ietf-dnsext-tkey-02.txt>
 
 
 
 Status of This Document
 
-   This draft, file name draft-ietf-dnsext-tkey-01.txt, is intended to
-   be become a Proposed Standard RFC.  Distribution of this document is
-   unlimited. Comments should be sent to the DNS working group mailing
-   list <namedroppers@ops.ietf.org> or to the author.
+   This draft is intended to be become a Proposed Standard RFC.
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS working group mailing list <namedroppers@ops.ietf.org> or
+   to the author.
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  Internet-Drafts are working
@@ -26,10 +24,11 @@ Status of This Document
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.
 
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet- Drafts as reference
-   material or to cite them other than as "work in progress."
+   Internet-Drafts are draft documents valid for a maximum of six
+   months.  Internet-Drafts may be updated, replaced, or obsoleted by
+   other documents at any time.  It is not appropriate to use Internet-
+   Drafts as reference material or to cite them other than as a
+   ``working draft'' or ``work in progress.''
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt
@@ -55,21 +54,21 @@ Status of This Document
 
 
 
-Donald E. Eastlake 3rd                                          [Page 1]
+Donald Eastlake 3rd                                             [Page 1]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
 Abstract
 
-   [draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of
-   authenticating Domain Name System (DNS) queries and responses using
-   shared secret keys via the TSIG resource record (RR).  However, it
-   provides no mechanism for setting up such keys other than manual
-   exchange. This document describes a TKEY RR that can be used in a
-   number of different modes to establish shared secret keys between a
-   DNS resolver and server.
+   [draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating
+   Domain Name System (DNS) queries and responses using shared secret
+   keys via the TSIG resource record (RR).  However, it provides no
+   mechanism for setting up such keys other than manual exchange. This
+   document describes a TKEY RR that can be used in a number of
+   different modes to establish shared secret keys between a DNS
+   resolver and server.
 
 
 
@@ -113,10 +112,10 @@ Acknowledgments
 
 
 
-Donald E. Eastlake 3rd                                          [Page 2]
+Donald Eastlake 3rd                                             [Page 2]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
 Table of Contents
@@ -148,7 +147,6 @@ Table of Contents
       4.5 Query for Resolver Assigned Keying....................12
       5. Spontaneous Server Inclusion...........................13
       5.1 Spontaneous Server Key Deletion.......................13
-      5.2 Spontaneous GSS-API Exchange..........................14
       6. Methods of Encryption..................................14
       7. IANA Considerations....................................14
       8. Security Considerations................................15
@@ -171,10 +169,11 @@ Table of Contents
 
 
 
-Donald E. Eastlake 3rd                                          [Page 3]
+
+Donald Eastlake 3rd                                             [Page 3]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
 1. Introduction
@@ -186,12 +185,12 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
    these RFCs is assumed.
 
-   [draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of
-   efficiently authenticating DNS messages using shared secret keys via
-   the TSIG resource record (RR) but provides no mechanism for setting
-   up such keys other than manual exchange. This document specifies a
-   TKEY RR that can be used in a number of different modes to establish
-   and delete such shared secret keys between a DNS resolver and server.
+   [draft-ietf-dnsext-tsig-*.txt] provides a means of efficiently
+   authenticating DNS messages using shared secret keys via the TSIG
+   resource record (RR) but provides no mechanism for setting up such
+   keys other than manual exchange. This document specifies a TKEY RR
+   that can be used in a number of different modes to establish and
+   delete such shared secret keys between a DNS resolver and server.
 
    Note that TKEY established keying material and TSIGs that use it are
    associated with DNS servers or resolvers.  They are not associated
@@ -229,13 +228,13 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
 
 
-Donald E. Eastlake 3rd                                          [Page 4]
+Donald Eastlake 3rd                                             [Page 4]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
-   servers.
+   servers which is currently used only for key deletion.
 
    Section 6 describes encryption methods for transmitting secret key
    information. In this document these are used only for the server
@@ -287,10 +286,10 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    For a TKEY with a non-root name appearing in a query, the TKEY RR
 
 
-Donald E. Eastlake 3rd                                          [Page 5]
+Donald Eastlake 3rd                                             [Page 5]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
    name SHOULD be a domain locally unique at the resolver, less than 128
@@ -305,30 +304,30 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
         its owner name, then the server SHOULD create a globally unique
         domain name, to be the key name, by suffixing a pseudo-random
         [RFC 1750] label with a domain name of the server.  For example
-        89n3mDgX072pp.server.example.com.  If generation of a new
+        89n3mDgX072pp.server1.example.com.  If generation of a new
         pseudo-random name in each case is an excessive computation load
         or entropy drain, a serial number prefix can be added to a fixed
         pseudo-random name generated an DNS server start time, such as
-        1001.89n3mDgX072pp.server.example.com.
+        1001.89n3mDgX072pp.server1.example.com.
 
         If the key is generated as the result of a query with a non-root
         name, say 789.resolver.example.net, then use the concatenation
         of that with a name of the server.  For example
-        789.resolver.example.net.server.example.com.
+        789.resolver.example.net.server1.example.com.
 
 
 
 2.2 The TTL Field
 
-   The TTL field is meaningless. It SHOULD always be zero to be sure
-   that older DNS implementations do not cache TKEY RRs.
+   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
+   be sure that older DNS implementations do not cache TKEY RRs.
 
 
 
 2.3 The Algorithm Field
 
    The algorithm name is in the form of a domain name with the same
-   meaning as in [draft-ietf-{dnsind|dnsext}-tsig-*.txt].  The algorithm
+   meaning as in [draft-ietf-dnsext-tsig-*.txt].  The algorithm
    determines how the secret keying material agreed to using the TKEY RR
    is actually used to derive the algorithm specific key.
 
@@ -345,10 +344,10 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    material provided.
 
 
-Donald E. Eastlake 3rd                                          [Page 6]
+Donald Eastlake 3rd                                             [Page 6]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
    To avoid different interpretations of the inception and expiration
@@ -403,10 +402,10 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    possible if a TKEY is spontaneously included in a response the TKEY
 
 
-Donald E. Eastlake 3rd                                          [Page 7]
+Donald Eastlake 3rd                                             [Page 7]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
    RR and DNS header error field could have unrelated non-zero error
@@ -418,7 +417,7 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
 
    The key data size field is an unsigned 16 bit integer in network
    order which specifies the size of the key exchange data field in
-   octets. The meaning of the key data depends on the mode.
+   octets. The meaning of this data depends on the mode.
 
 
 
@@ -461,10 +460,10 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
 
 
 
-Donald E. Eastlake 3rd                                          [Page 8]
+Donald Eastlake 3rd                                             [Page 8]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
    TKEY queries MUST be authenticated for all modes except GSS-API and,
@@ -478,6 +477,9 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    a public (SIG(0)) key signature.  It MUST NOT use any key that the
    query is itself providing.
 
+   In the absence of required TKEY authentication, a NOTAUTH error MUST
+   be returned.
+
    To avoid replay attacks, it is necessary that a TKEY response or
    query not be valid if replayed on the order of 2**32 second (about
    136 years), or a multiple thereof, later.  To accomplish this, the
@@ -514,17 +516,17 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    the additional information section specifying the Diffie-Hellman mode
    and accompanied by a KEY RR also in the additional information
    section specifying a resolver Diffie-Hellman key.  The TKEY RR
-   algorithm field is set to the authentication algorithm the resolver
-   plans to use. The "key data" provided in the TKEY is used as a random
-   [RFC 1750] nonce to avoid always deriving the same keying material
 
 
-Donald E. Eastlake 3rd                                          [Page 9]
+Donald Eastlake 3rd                                             [Page 9]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
+   algorithm field is set to the authentication algorithm the resolver
+   plans to use. The "key data" provided in the TKEY is used as a random
+   [RFC 1750] nonce to avoid always deriving the same keying material
    for the same pair of DH KEYs.
 
    The server response contains a TKEY in its answer section with the
@@ -572,17 +574,17 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    toss keys, although it may have to go through another key exchange if
    it later needs one.  Similarly, the server can discard keys although
    that will result in an error on receiving a query with a TSIG using
-   the discarded key.
 
-   To avoid attempted reliance in requests on keys no longer in effect,
 
-
-Donald E. Eastlake 3rd                                         [Page 10]
+Donald Eastlake 3rd                                            [Page 10]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
+
 
+   the discarded key.
 
+   To avoid attempted reliance in requests on keys no longer in effect,
    servers MUST implement key deletion whereby the server "discards" a
    key on receipt from a resolver of an authenticated delete request for
    a TKEY RR with the key's name.  If the server has no record of a key
@@ -605,8 +607,7 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    should be seen for the full description.  Basically the resolver and
    server can exchange queries and responses for type TKEY with a TKEY
    RR specifying the GSS-API mode in the additional information section
-   and a GSS-API token in the key data portion of the TKEY RR. See also
-   section 5.2.
+   and a GSS-API token in the key data portion of the TKEY RR.
 
    Any issues of possible encryption of parts the GSS-API token data
    being transmitted are handled by the GSS-API level.  In addition, the
@@ -631,23 +632,23 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    algorithm the resolver plans to use.  It is RECOMMENDED that any "key
    data" provided in the query TKEY RR by the resolver be strongly mixed
    by the server with server generated randomness [RFC 1750] to derive
-   the keying material to be used.  The KEY RR that appears in the query
-   need not be accompanied by a SIG(KEY) RR.  If the query is
 
 
-Donald E. Eastlake 3rd                                         [Page 11]
+Donald Eastlake 3rd                                            [Page 11]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
-   authenticated by the resolver with a TSIG RR [draft-ietf-
-   {dnsind|dnsext}-tsig-*.txt] or SIG(0) RR and that authentication is
-   verified, then any SIG(KEY) provided in the query SHOULD be ignored.
-   The KEY RR in such a query SHOULD have a name that corresponds to the
-   resolver but it is only essential that it be a public key for which
-   the resolver has the corresponding private key so it can decrypt the
-   response data.
+   the keying material to be used.  The KEY RR that appears in the query
+   need not be accompanied by a SIG(KEY) RR.  If the query is
+   authenticated by the resolver with a TSIG RR [draft-ietf-dnsext-
+   tsig-*.txt] or SIG(0) RR and that authentication is verified, then
+   any SIG(KEY) provided in the query SHOULD be ignored.  The KEY RR in
+   such a query SHOULD have a name that corresponds to the resolver but
+   it is only essential that it be a public key for which the resolver
+   has the corresponding private key so it can decrypt the response
+   data.
 
    The server response contains a TKEY RR in its answer section with the
    server assigned mode and echoes the KEY RR provided in the query in
@@ -689,19 +690,19 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    section.  The name of the key and the keying data are completely
    controlled by the sending resolver so a globally unique key name
    SHOULD be used.  The KEY RR used MUST be one for which the server has
-   the corresponding private key, or it will not be able to decrypt the
-   keying material and will return a FORMERR, and no untrusted party
 
 
-Donald E. Eastlake 3rd                                         [Page 12]
+Donald Eastlake 3rd                                            [Page 12]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
-   (preferably no other party than the server) has the private key, or
-   the untrusted private key holder can capture the messages to the
-   server, learn the shared secret, and spoof valid TSIGs.
+   the corresponding private key, or it will not be able to decrypt the
+   keying material and will return a FORMERR, and for which no untrusted
+   party (preferably no other party than the server) has the private
+   key, or the untrusted private key holder can capture the messages to
+   the server, learn the shared secret, and spoof valid TSIGs.
 
    The query TKEY RR inception and expiry give the time period the
    querier intends to consider the keying material valid.  The server
@@ -720,16 +721,17 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    A DNS server may include a TKEY RR spontaneously as additional
    information in responses.  This SHOULD only be done if the server
    knows the querier understands TKEY and has this option implemented.
-   This technique can be used for GSS-API exchange, and to delete a key.
-   A disadvantage of this technique is that there is no way for the
-   server to get any error or success indication back and, in the case
-   of UDP, no way to even know if the DNS response reached the resolver.
+   This technique can be used to delete a key and may be specified for
+   modes defined in the future.  A disadvantage of this technique is
+   that there is no way for the server to get any error or success
+   indication back and, in the case of UDP, no way to even know if the
+   DNS response reached the resolver.
 
 
 
 5.1 Spontaneous Server Key Deletion
 
-   A server can optionally tell a client that it has deleted a symmetric
+   A server can optionally tell a client that it has deleted a secret
    key by spontaneously including a TKEY RR in the additional
    information section of a response with the key's name and specifying
    the key deletion mode.  Such a response SHOULD be authenticated.  If
@@ -748,28 +750,10 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
 
 
 
-
-
-
-Donald E. Eastlake 3rd                                         [Page 13]
+Donald Eastlake 3rd                                            [Page 13]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
-
-
-5.2 Spontaneous GSS-API Exchange
-
-   A server can spontaneously include in the additional information
-   section of a response, a GSS-API mode TKEY RR.  The information in
-   the key data section of such a TKEY is a GSS-API token which SHOULD
-   be fed by the resolver to its local GSS-API implementation.  If such
-   a response is authenticated, the authentication MAY be verify before
-   processing the data.  To the extent that GSS-API provides its own
-   security, such a response need not be authenticated.  To the extent
-   that GSS-API handles duplicated messages, such a spontaneous TKEY
-   could be sent repeatedly, until, for example, a response via a GSS-
-   API mode TKEY query is received. See also section 4.3.
-
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
 6. Methods of Encryption
@@ -788,16 +772,17 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    symmetric algorithms.
 
    If the KEY RR specifies the RSA algorithm, then the keying material
-   is encrypted as per the description of RSA encryption in PKCS#1 [RFC
-   2437].  (Note, the secret keying material being sent is directly RSA
-   encrypted in PKCS#1 format, It is not "enveloped" under some other
-   symmetric algorithm.)  In the unlikely event that the keying material
-   will not fit within one RSA modulus of the chosen public key,
-   additional RSA encryption blocks are included.  The length of each
-   block is clear from the public RSA key specified and the PKCS#1
-   padding makes it clear what part of the encrypted data is actually
-   keying material and what part is formatting or the required at least
-   eight bytes of random [RFC 1750] padding.
+   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
+   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
+   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
+   some other symmetric algorithm.)  In the unlikely event that the
+   keying material will not fit within one RSA modulus of the chosen
+   public key, additional RSA encryption blocks are included.  The
+   length of each block is clear from the public RSA key specified and
+   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
+   encrypted data is actually keying material and what part is
+   formatting or the required at least eight bytes of random [RFC 1750]
+   padding.
 
 
 
@@ -807,14 +792,6 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
 
    Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF
    can only be assigned by an IETF standards action.  Special
-
-
-Donald E. Eastlake 3rd                                         [Page 14]
-
-
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
-
-
    consideration should be given before the allocation of meaning for
    Mode field values 0x0000 and 0xFFFF.
 
@@ -829,6 +806,14 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
    Standard should not be changed later just because that standard's
    status is changed to Proposed.
 
+
+
+Donald Eastlake 3rd                                            [Page 14]
+
+
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
+
+
    The following assignments are documented herein:
 
        RR Type 249 for TKEY.
@@ -844,7 +829,7 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
 
    The entirety of this specification is concerned with the secure
    establishment of a shared secret between DNS clients and servers in
-   support of TSIG.
+   support of TSIG [draft-ietf-dnsext-tsig-*.txt].
 
    Protection against denial of service via the use of TKEY is not
    provided.
@@ -867,10 +852,24 @@ INTERNET-DRAFT              The DNS TKEY RR                   March 2000
 
 
 
-Donald E. Eastlake 3rd                                         [Page 15]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Donald Eastlake 3rd                                            [Page 15]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
 References
@@ -917,7 +916,7 @@ References
    RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
    Name System (DNS)", March 1999.
 
-   draft-ietf-{dnsind|dnsext}-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
+   draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
    Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
 
 
@@ -925,10 +924,10 @@ References
 
 
 
-Donald E. Eastlake 3rd                                         [Page 16]
+Donald Eastlake 3rd                                            [Page 16]
 
 
-INTERNET-DRAFT              The DNS TKEY RR                   March 2000
+INTERNET-DRAFT              The DNS TKEY RR                   April 2000
 
 
 Author's Address
@@ -940,16 +939,16 @@ Author's Address
 
    Telephone:   +1 914-276-2668 (h)
                 +1 508-261-5434 (w)
-   FAX:         +1 914-276-2947 (h)
+   FAX:         +1 508-261-4447 (w)
    email:       Donald.Eastlake@motorola.com
 
 
 
 Expiration and File Name
 
-   This draft expires August 2000.
+   This draft expires October 2000.
 
-   Its file name is draft-ietf-dnsext-tkey-01.txt.
+   Its file name is draft-ietf-dnsext-tkey-02.txt.
 
 
 
@@ -983,5 +982,5 @@ Expiration and File Name
 
 
 
-Donald E. Eastlake 3rd                                         [Page 17]
+Donald Eastlake 3rd                                            [Page 17]
 
diff --git a/doc/draft/draft-ietf-dnsext-zone-status-00.txt b/doc/draft/draft-ietf-dnsext-zone-status-01.txt
index e6b788b5..af7c85bb 100644
--- a/doc/draft/draft-ietf-dnsext-zone-status-00.txt
+++ b/doc/draft/draft-ietf-dnsext-zone-status-01.txt
@@ -1,10 +1,9 @@
-DNSEXT WG                                           Edward Lewis
-INTERNET DRAFT                                      NAI Labs
-Category:I-D                                        Feburary 1, 2000
+DNSEXT WG                                               Edward Lewis
+INTERNET DRAFT                                          NAI Labs
+Category:I-D                                            April 13, 2000
 
-
-           DNS Security Extension Clarification on Zone Status
-                <draft-ietf-dnsext-zone-status-00.txt>
+       DNS Security Extension Clarification on Zone Status
+             <draft-ietf-dnsext-zone-status-01.txt>
 
 Status of this Memo
 
@@ -29,7 +28,7 @@ http://www.ietf.org/shadow.html.
 Comments should be sent to the authors or the DNSIND WG mailing list
 namedroppers@internic.net.
 
-This draft expires on August 1, 2000.
+This draft expires on October 13, 2000.
 
 Copyright Notice
 
@@ -38,7 +37,7 @@ Copyright (C) The Internet Society (1999, 2000).  All rights reserved.
 Abstract
 
 The definition of a secured zone is presented, updating RFC 2535.  The
-new definition has consequences which alter the interpretation of the
+new definition has consequences that alter the interpretation of the
 NXT record, obsolete NULL keys, and the designation of "experimentally
 secure."
 
@@ -54,11 +53,11 @@ asks the question upon receipt of data belonging to the zone.
 
 A zone administrator needs to be able to determine what steps are
 needed to make the zone as secure as it can be.  Realizing that due to
+the distributed nature of DNS and its administration, any single zone
 
-Expires August 1, 2000                                       [Page  1]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
+Expires October 13, 2000                                     [Page  1]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
 
-the distributed nature of DNS and its administration, any single zone
 is at the mercy of other zones when it comes to the appearance of
 security.  This document will define what makes a zone qualify as
 secure (absent interaction with other zones).
@@ -89,44 +88,65 @@ secured.
 This document updates several sections of RFC 2535.  The definition of
 a secured zone is an update to section 3.4 of the RFC.  The document
 updates section 2.3.4, by specifying a replacement for the NULL zone
-keys.  The document also updates section 3.4 to eliminate the
-definition of experimental keys and illustrate a way to still achieve
-the functionality they were designed to provide.
+keys.  Section 3.4 is updated to eliminate the definition of
+experimental keys and illustrate a way to still achieve the
+functionality they were designed to provide.  Section 3.1.3 is updated
+by the specifying the value of the protocol octet in a zone key.
 
 2 Status of a Zone
 
 In this section, rules governing a zone's DNSSEC status are presented.
-There are three levels of security defined; full, private, and
+There are three levels of security defined: full, private, and
 unsecured.  A zone is fully secure when it complies with the strictest
 set of DNSSEC processing rules.  A zone is privately secured when it
 is configured in such a way that only resolvers that are appropriately
 configured see the zone as secured.  All other zones are unsecured.
 
-Note: there currently is no other document completely defining DNSSEC
-processing rules.  For the purposes of this document, the strictest
+Note: there currently is no document completely defining DNSSEC
+verification rules.  For the purposes of this document, the strictest
 rules are assumed to state that the verification chain of zone keys
 parallels the delegation tree up to the root zone.  This is not
 intended to disallow alternate verification paths, just to establish a
 baseline definition.
 
-To avoid repetition in the rules below, the following term is defined.
+To avoid repetition in the rules below, the following terms are
+defined.
 
-2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
 
-Expires August 1, 2000                                       [Page  2]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
+Expires October 13, 2000                                     [Page  2]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
 
+2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
 for name type (indicating a zone key) and either value 00 or value 01
 for key type (indicating a key permitted to authenticate data).  (See
 RFC 2535, section 3.1.2).  The KEY RR also has a protocol octet value
 of DNSSEC (3) or All (255).
 
+The definition updates RFC 2535's definition of a zone key.  The
+requirement that the protocol field be either DNSSEC or All is a new
+requirement.
+
+2.b On-tree Validation - The authorization model in which only the
+parent zone can is recognized to supply a DNSSEC-meaningful signature
+that is used by a resolver to build a chain of trust from the child's
+keys to a recognized root of security.  The term "on-tree" refers to
+following up the DNS domain hierarchy to reach a trusted key,
+presumably the root key if no other key is available.  The term
+"validation" refers to the digital signature by the parent to prove
+the integrity, authentication and authorization of the child' key to
+sign the child's zone data.
+
+2.c Off-tree Validation - Any authorization model that permits domain
+names other than the parent's to provide a signature over a child's
+zone keys that will enable a resolver to trust the keys.
+
 2.1 Fully Secured
 
 A fully secured zone, in a nutshell, is a zone that uses only
 mandatory to implement algorithms (RFC 2535, section 3.2) and relies
-on a key certification chain that parallels the delegation tree. Fully
-secured zones are defined by the following rules.
+on a key certification chain that parallels the delegation tree
+(on-tree validation).  Fully secured zones are defined by the
+following rules.
 
 2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at least
 one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
@@ -138,7 +158,8 @@ be a zone signing KEY RR (2.a) of a mandatory to implement algorithm
 and owned by the parent's apex.
 
 If a zone cannot get a conforming signature from the parent zone, the
-child zone cannot be considered fully secured.
+child zone cannot be considered fully secured.  The only exception to
+this is the root zone, for which there is no parent zone.
 
 2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC
 2535, section 2.3.2.)  Note: there is some operational discomfort with
@@ -149,30 +170,43 @@ using an alternate method.
 
 2.1.d. Each RR set that qualifies for zone membership MUST be signed
 by a key that is in the apex's KEY RR set and is a zone signing KEY RR
+
+Expires October 13, 2000                                     [Page  3]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
+
 (2.a) of a mandatory to implement algorithm.  (Updates 2535, section
 2.3.1.)
 
+Mentioned earlier, the root zone is a special case.  Defining what
+constitutes a secure root zone is difficult, as the discussion on
+securing the root zone has not come to a consensus in an open forum. 
+However, the security of the root zone will be determined by the
+preconfiguration of a trusted key in resolvers.  Who generates and
+distributes the trusted key is an open issue.
+
 2.2 Privately Secured
 
+Note that the term "privately" is open to debate...
+
 A privately secured zone is a zone that complies with rules like those
-for fully secured, with the following exceptions.  The signing keys
-may be of an algorithm that is not mandatory to implement and/or the
-verification of the zone keys in use may rely on a verification chain
-that is not parallel to the delegation tree.
+for a fully secured zone with the following exceptions.  The signing
+keys may be of an algorithm that is not mandatory to implement and/or
+the verification of the zone keys in use may rely on a verification
+chain that is not parallel to the delegation tree (off-tree
+validation).
 
 2.2.a. The zone's apex MUST have a KEY RR set.  There MUST be at least
 one zone signing KEY RR (2.a) in the set.
 
 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
-one of the following two sentences MUST hold true.  The private key's
-public companion MUST be preconfigured in all the resolvers of
-interest.  The private key's public component MUST be a zone signing
-KEY RR (2.a) authorized to provide validation of the zone's apex KEY
-RR set, as recognized by resolvers of interest.
+one of the following two subclauses MUST hold true.
 
+2.2.b.1 The private key's public companion MUST be preconfigured in
+all the resolvers of interest.
 
-Expires August 1, 2000                                       [Page  3]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
+2.2.b.2 The private key's public component MUST be a zone signing KEY
+RR (2.a) authorized to provide validation of the zone's apex KEY RR
+set, as recognized by resolvers of interest.
 
 The previous sentence is trying to convey the notion of using a
 trusted third party to provide validation of keys.  If the domain name
@@ -184,7 +218,7 @@ represent someone the resolver trusts to provide validation.
 
 2.2.d. Each RR set that qualifies for zone membership MUST be signed
 by a key that is in the apex's KEY RR set and is a zone signing KEY RR
-(2.a).  (Updates 2535, section 2.3.1.)
+(2.a)..  (Updates 2535, section 2.3.1.)
 
 2.3 Unsecured
 
@@ -192,6 +226,12 @@ All other zones qualify as unsecured.  This includes zones that are
 designed to be experimentally secure, as defined in a later section on
 that topic.
 
+
+
+
+Expires October 13, 2000                                     [Page  4]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
+
 2.4 Wrap up
 
 The designation of fully secured, privately secured, and unsecured are
@@ -202,7 +242,7 @@ a zone as secured or unsecured.
 Resolvers that follow the most restrictive DNSSEC verification rules
 will only see fully secured zones as secured, and all others as
 unsecured, including zones which are privately secured.  Resolvers
-which are not as restrictive, such as those that implement algorithms
+that are not as restrictive, such as those that implement algorithms
 in addition to the mandatory to implement algorithms, will see some
 privately secured zones as secured.
 
@@ -216,7 +256,7 @@ security standards.
 3 Parental Notification
 
 For a resolver to come to a definitive answer concerning a zone's
-security status, there is a requirement that the parent of a zone
+security status there is a requirement that the parent of a zone
 signify whether the child zone is signed or not.  The justification of
 this requirement requires a discussion of the resolver's activity,
 which is described in RFC 2535.
@@ -224,24 +264,32 @@ which is described in RFC 2535.
 In RFC 2535, a parent is required to hold a NULL key for an unsigned
 child (a bone of contention here is how this works in light of
 multiple algorithms).  The parent has the option to hold the keys of
-the child if the child is signed. The parent may also hold nothing
+the child if the child is signed.  The parent may also hold nothing
 cryptographic if the child is signed.  This, of course, assumes the
 parent is a signed zone.
 
-
-Expires August 1, 2000                                       [Page  4]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
+RFC 2535 does permit the following case, a child zone that uses DNSSEC
+capable software yet chooses to remain unsecured could hold a signed
+NULL key delivered from the parent.  This is considered to be a rare
+condition, a zone administrator that goes to the trouble to get the
+keys from the parent and have it signed will likely just sign the
+whole zone, or leave the NULL key to the parent.
 
 There is a strong case for discouraging a parent from holding keys of
-a signed child.  These include concrete concerns about performance and
-more abstract concerns about the liability of the parent.
+a signed child, or an unsigned child for that matter.  These include
+concrete concerns about performance and more abstract concerns about
+the liability of the parent.
 
 DNS [RFC 1034 and 1035] requires a parent to hold NS records for a
 child zone, this signifies the delegation.  RFC 2535 requires a
 secured parent to also have signed NXT records for the child, and
-possibly a signed KEY RR set (required for NULL key situations).
+possibly a signed KEY RR set (required for some NULL key situations).
 
 By redefining the security status of a zone to be per zone and not per
+
+Expires October 13, 2000                                     [Page  5]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
+
 algorithm, there is an opportunity to completely remove the need for a
 KEY RR set in the parent.  Because the question of whether the zone is
 secure or not is a yes-or-no question, the notification needs just one
@@ -256,10 +304,10 @@ supposed to hold.  (E.g., if a parent zone's name server caches the
 SOA for the child, the SOA is not in the parent zone, but is in the
 server's cache.)
 
-3.1 Child Is Secured Bit
+3.1 Child Has Keys Bit
 
-This section is written assuming the current definition of NXT holds. 
-There is some controversy surrounding the NXT record which may result
+This section is written assuming the current definition of NXT holds.
+There is some controversy surrounding the NXT record, which may result
 in a complete replacement of it for proof of non-existence.  The
 current NXT definition provides an extension bit in the types present
 bit map, whose use is remains incompletely defined.  The following
@@ -267,40 +315,53 @@ text largely ignores these uncertainties, and should be rewritten to
 accommodate these uncertainties in revisions.
 
 In the parent's half of the delegation point, there will be an NXT
-record.  According to the rules for a delegation point, only the NS,
-NXT, and SIG bits will be turned on in the types present field,
-assuming we drop the KEY set altogether.
+record, called an "upper" NXT.  According to the rules for a
+delegation point, only the NS, NXT, and SIG bits will be turned on in
+the types present field, assuming we drop the KEY set altogether.
 
 The KEY bit in the parent's NXT types present bit map is hereby
-redefined to have the following meaning.
-
-If the bit corresponding to the KEY RR set in a parent NXT is set, the
-parent has signed a KEY RR set for the child that includes a zone
-signing KEY RR (2.a).  Furthermore, the validity period on the SIG
-(KEY) RR covers the current time and the public component of the key
-used to generate the SIG (KEY) RR is validly available from the
-parent.
-
-E.g., Assume the zone "test." signs a key for "zone1.test.," with the
-signature valid from May 1st to June 1st and a public key from "test."
-available from April 1st until July 1st.  The NXT record for
-"zone1.test." will have the KEY RR bit set from May 1st to June 1st.
-
-
-Expires August 1, 2000                                       [Page  5]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
-
-This constraint may be enforced in the SIG (NXT) RR validity period,
-timely editing of the master file, or whatever other mechanism "test."
-chooses to implement.
-
-Conversely, if the bit is 0, then the child is not secured.  Note that
-for a fully secured zone (section 2.1), the bit is on (1).  For all
-unsecured zones (section 2.3) the bit is off (0).  For privately
-secured zones (section 2.2), the setting of the bit is determined by
-whether the parent signs the child's keys or not.  Hence, for
-privately secured zones, the parent may have no responsibility.  A
-child wishing to have the parent set the bit must contact the parent.
+redefined to have the following meaning.  (Note that this applies to
+just delegation points.)
+
+If the bit corresponding to the KEY RR set in an upper NXT is set, the
+parent has generated and issued a currently valid SIG (KEY) RR
+validating the child's apex KEY RR set.  Note that this does not
+require the child to include either a zone signing KEY RR (2.a) or a
+NULL zone KEY RR.  This does assume that only on-tree validation (2.b)
+is in use.
+
+The temporal validity of the bit's setting may be enforced in the SIG
+(NXT) RR validity period, timely editing of the master file, dynamic
+updates, or whatever another mechanism.
+
+If a child submits a key set to the parent for validation that does
+not include a zone signing KEY RR (2.a), then the child will remain
+unsecured although the upper NXT KEY RR bit will be set to 1 by the
+parent.  A resolver seeing this will know to look for a child key set,
+and see that there is no zone signing KEY RR (2.a) and know to treat
+the child as unsecured.
+
+If a NULL zone KEY RR is seen, the resolver ignores it.  If a NULL key
+is the only zone key, then the resolver will deduce the child is
+unsecured as in the previous paragraph.  If there is both a NULL and
+
+Expires October 13, 2000                                     [Page  6]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
+
+one or more zone signing KEY RR (2.a), then the zone is considered
+signed in the algorithm(s) identified in the signing capable key(s).
+
+If the bit is 0 then the child has not submitted a KEY RR set for
+validation, hence is to be considered unsigned.
+
+Note that for a fully secured zone (section 2.1), the bit is on (1). 
+For all unsecured zones (section 2.3) the bit is either off (0) or on
+(1) with a NULL KEY and no zone signing KEY RR at the apex.  For
+privately secured zones (section 2.2), the setting of the bit is
+determined by whether the parent signs the child's keys or not. 
+Hence, for privately secured zones, the parent may have no
+responsibility.  A child wishing to have the parent set the bit must
+contact the parent.
 
 3.2 Rules Governing the Bit
 
@@ -310,15 +371,15 @@ the NXT.  This is in anticipation of a change in the way NXT indicates
 types present (e.g., if bit 0 of the field is defined) or a successor
 to the NXT is defined.
 
-3.2.a. At a delegation point, a parent zone MUST have a mechanism in
-place to indicate which RR sets are present.  The mechanism MUST
-indicate that the NS, SIG, and the type(s) corresponding to the
-mechanism itself are present (of course, with these types actually
-being present).  With the exception of the KEY RR type, all other
-types MUST be indicated as not present, and, in accordance with
-delegation rules, actually be absent from the zone.  If, in the
-future, other data is permitted to be present at a delegation point,
-this requirement MUST be amended.
+3.2.a. At a delegation point, a secured parent zone MUST have a
+mechanism in place to indicate which RR sets are present.  The
+mechanism MUST indicate that the NS, SIG, and the type(s)
+corresponding to the mechanism itself are present (of course, with
+these types actually being present).  With the exception of the KEY RR
+type, all other types MUST be indicated as not present, and, in
+accordance with delegation rules, actually be absent from the zone. 
+If, in the future, other data is permitted to be present at a
+delegation point, this requirement MUST be amended.
 
 Assuming the NXT record, the above requirement reads as follows.  At a
 delegation point, a parent zone must have a secured NXT record.  This
@@ -337,33 +398,30 @@ If the parent has issued signatures with discontinuous validity spans,
 then the presence of the KEY set will flip from present to not present
 and back as time progresses.
 
-If the parent is aware that the child's keys are becoming valid or
-will be becoming invalid at a certain point in time, it is recommended
-that this be reflected in the NXT's signature validity period.
-
 3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully
 consider the algorithm of the key used to generate the signature.  The
 parent SHOULD make clear to child zones what steps are to be taken to
 
-Expires August 1, 2000                                       [Page  6]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
+
+Expires October 13, 2000                                     [Page  7]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
 
 get the parent to indicate that the child is signed.  This document
 will go no further in specifying operational considerations.
 
 (Let's say the parent signs the child's key set with an algorithm the
 child can't process.  The child could elect not to advertise this
-signature as it cannot verify that the signature covers the real key
+signature, as it cannot verify that the signature covers the real key
 set.  If this happens, is the parent justified in claiming that the
 child is secured?)
 
-3.2.d. The parent MUST allow the child, through some trusted, probably
-non-DNS mechanism, to request that the indication of the KEY set in
-the NXT be turned off.  This allows a child to revert to an unsigned
-state.
+3.2.d. The parent MUST have the capability to allow the child, through
+some trusted, probably non-DNS mechanism, to request that the
+indication of the KEY set to be turned off.  This allows a child to
+revert to an unsigned state.
 
 3.2.e. The parent SHOULD NOT allow the child to request that the KEY
-set be indicated in the absence of a key signing request.
+set be indicated as present in the absence of a key signing request.
 
 3.3 Operational Considerations
 
@@ -385,13 +443,16 @@ query for the upper NXT may be confused for a lower NXT query.  This
 is akin to the issue of the ANY query, where a server with some cached
 data will answer with just that and not seek the rest of the data.
 
+Note that distinguishing between an upper and lower NXT is a trivial
+operation, especially so if the SIG RR is available.
+
 A resolver may know the child's server's addresses and the parent zone
 may not be sharing servers with the child.  In this case the resolver
 will need to be able to locate the parent zones (possibly having to go
 to the root servers and descend) in order to obtain the upper NXT
 record.
 
-A potential solution to this is to define an NXT meta-query which will
+A potential solution to this is to define an NXT meta-query that will
 force a recursive server to find all available NXT RR sets for a given
 name.  Details of this have not been examined.
 
@@ -399,13 +460,14 @@ name.  Details of this have not been examined.
 
 Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update-
 xy.txt] defines a means by which a zone can change without undergoing
+
+Expires October 13, 2000                                     [Page  8]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
+
 a full reload.  This combination of dynamic update and the proposed
 use of the NXT record to signify a child's status raises some
 concerns.
 
-Expires August 1, 2000                                       [Page  7]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
-
 First a few elements need to be labeled.  There is an off-line signer,
 which is the process that signs zone data files away from the name
 server.  There is an on-line signer, part of a name server, that the
@@ -415,12 +477,12 @@ requests for parent signatures over each child zone's keys.
 
 The proposal depicted in this draft relies upon the on-line key
 validator informing the on-line and off-line signers of the status of
-a child, recall that the status of a child has a temporal element. 
+a child, recall that the status of a child has a temporal element.
 E.g., a signature may be generated for just the month of July, so the
-child is secured for the month of July, but not August.
+child is secured for the month of July, but not the month of August.
 
-The first issues pertain to the way in which a validation is encoded
-in an NXT record by the off-line signer.  There is a need for the
+The first issues pertain to the way in which an off-line signer comes
+to encode a validation in an NXT record.  There is a need for the
 status information to flow from the on-line validator to the off-line
 signer and then be used as input to the signing process.  The way that
 this information makes the transition is an issue.  The second issue
@@ -456,13 +518,12 @@ needed is not currently covered by a valid signature?
 
 Through the use of the types present to indicate the existence of a
 signature validating the KEY set of a child, the need for NULL keys
-effectively disappears.  NULL keys are left as a defined entity, but
-are rendered meaningless in DNSSEC.
-
 
+Expires October 13, 2000                                     [Page  9]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
 
-Expires August 1, 2000                                       [Page  8]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
+effectively disappears.  NULL keys are left as a defined entity, but
+are rendered meaningless in DNSSEC.
 
 5 Experimental Status
 
@@ -515,12 +576,12 @@ RFC 1034, November 1987.
 [RFC1035] P. Mockapetris, "Domain Names - Implementation and
 Specification," RFC 1034, November 1987.
 
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels," RFC 2119, March 1997
 
+Expires October 13, 2000                                     [Page 10]
+DNS Security Extension Clarification on Zone Status     April 13, 2000
 
-Expires August 1, 2000                                       [Page  9]
-DNS Security Extension Clarification on Zone Status   February 1, 2000
+[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+Requirement Levels," RFC 2119, March 1997
 
 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
 Updates in the Domain Name System," RFC 2136, April 1997.
@@ -529,7 +590,7 @@ Updates in the Domain Name System," RFC 2136, April 1997.
 2535, March 1999.
 
 [draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
-Secure Domain Name System (DNS) Dynamic Update", version 00, February
+Secure Domain Name System (DNS) Dynamic Update," version 00, February
 2000.
 
 10 Author Information
@@ -574,7 +635,6 @@ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 
 
 
+Expires October 13, 2000                                     [Page 11]
 
 
-
-Expires August 1, 2000                                       [Page 10]
diff --git a/doc/draft/draft-ietf-dnsind-dddd-01.txt b/doc/draft/draft-ietf-dnsind-dddd-01.txt
deleted file mode 100644
index 0d3b429c..00000000
--- a/doc/draft/draft-ietf-dnsind-dddd-01.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-
-DNSIND Working Group                          Brian Wellington (TISLabs)
-INTERNET-DRAFT                              Olafur Gudmundsson (TISLabs)
-                                                              April 1999
-
-<draft-ietf-dnsind-dddd-01.txt>
-
-Updates: RFC 2136
-
-
-
-      Deferred Dynamic Domain Name System (DNS) Delete Operations
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as ``work in progress.''
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document proposes a mechanism for notifying a dynamic DNS server
-   that a delete operation should be performed at a certain point in the
-   future.  This works within the framework of the current DNS dynamic
-   update protocol, and provides needed functionality for clients with
-   leased dynamic addresses.
-
-
-
-
-
-
-
-
-
-Expires October 1999                                            [Page 1]
-
-INTERNET-DRAFT        Deferred Dynamic DNS Deletes         February 1999
-
-
-1 - Introduction
-
-Dynamic update operations for the Domain Name System [RFC1034, RFC1035]
-are defined in [RFC2136], but there is no automated method of specifying
-that records should have a fixed lifetime, or lease.
-
-1.1 - Overview of DNS Dynamic Update
-
-DNS dynamic update defines a new DNS opcode and a new interpretation of
-the DNS message if that opcode is used.  An update can specify
-insertions or deletions of data, along with prerequisites necessary for
-the updates to occur.  All tests and changes for a DNS update request
-are restricted to a single zone, and are performed at the primary server
-for the zone.  The primary server for a dynamic zone must increment the
-zone SOA serial number when an update occurs or before the next
-retrieval of the SOA.
-
-1.2 - Overview of DHCP leases
-
-DHCP [RFC2131] provides a means for a host to obtain a network address
-from a DHCP server.  The server may ``lease'' this address to the host,
-meaning that it is valid only for the period of time specified in the
-lease.  The host may may extend its lease with subsequent requests, or
-may issue a message to release the address back to the server when it is
-no longer needed.
-
-2 - Background
-
-When a host receives dynamic addresses with associated dynamic DNS
-records, the records can be updated by either the host or the DHCP
-server.  In many cases, update by the server is recommended, since the
-server maintains lease information for each address.  In some cases,
-though, the server cannot update some or all of the DNS records.  This
-happens when the DNS and DHCP server are under different administration,
-for example.
-
-A host can easily update its own DNS records when receiving information
-from the DHCP server.  It can also delete its records when shutting
-down.  If the host unexpectedly goes down, though, it cannot delete the
-records.  When the DHCP lease on the address expires and is not renewed,
-the DHCP server may reassign the address.  The DNS records now point to
-an assigned address, but not the correct address.  Until the host
-updates its records again, DNS will contain bad information.
-
-Since the DHCP and DNS servers are often not co-located with the
-clients, the possibility of a host unexpectedly going down and not
-communicating with the servers is non-trivial.
-
-
-
-
-Expires October 1999                                            [Page 2]
-
-INTERNET-DRAFT        Deferred Dynamic DNS Deletes         February 1999
-
-
-If the host could set a lease on the DNS records similar to that on its
-address, the DNS records would lose validity at the same time as the
-address.  This would prevent bad information from remaining in DNS.  DNS
-has no such provision for leases, though, since this would require
-storing a lease time along with each record (or each record in a dynamic
-zone).
-
-An alternative method is suggested.  A ``delete'' update is sent along
-with the ``add'' update, but the delete is marked in such a way that it
-will not be exectuted immediately.  Instead, it will be stored for the
-specified amount of time before being applied.  If the host wishes to
-extend or shorten the lifetime of the DNS record(s), it can replace the
-``deferred delete'' record, which will reset the lease time of the
-record(s).  The ``deferred delete'' record would, of course, also be
-removed if a normal delete update was received.
-
-3 - Protocol changes
-
-When doing a delete update operation as defined in [RFC2136] (deleting
-an RR, an RRset, or all RRset from a name), the TTL field MUST be
-specified as 0.  An [RFC2136] compliant server will silently ignore (*)
-an update record with a non-zero TTL.  This document overloads the TTL
-field.  If TTL is non-zero, the value represents the number of seconds
-(a 32 bit unsigned integer) before which the delete will be applied to
-the zone.  Thus, the delete operation will be deferred for that number
-of seconds, where the number of seconds indicates the lease time.  A 32
-bit integer provides for a lease time of over 136 years, which should be
-long enough for most uses.
-
-3.1 - Storage and execution
-
-Deferred delete records are stored, persistently, by the name server.
-The name server SHOULD attempt to evaluate the deletes in a timely
-manner.  If multiple deferred deletes are sent in the same DNS message
-with the same TTL value, they MUST be processed atomically if processed
-as planned (that is, none of the deferred deletes are updated or
-cancelled).
-
-3.2 - Processing of deferred deletes
-
-When a deferred delete is received, the server must check to see if it
-matches an existing deferred delete records, where matching indicates
-the same name, type, class, and rdata.  If a match is found, the new
-deferred delete MUST replace the old one.  If the deferred delete does
-not refer to any record in the server, it should fail as a normal delete
-would.
-
-
-
-
-
-Expires October 1999                                            [Page 3]
-
-INTERNET-DRAFT        Deferred Dynamic DNS Deletes         February 1999
-
-
-3.3 - Processing of normal deletes
-
-When a normal delete is received and accepted, the server SHOULD purge
-any matching deferred delete records.
-
-3.4 - Processing of cancellations
-
-The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL
-field has a special meaning.  If a delete containing this lease time is
-received, the server will unconditionally remove any matching deferred
-deletes.  If no deferred delete matches, this request will be silently
-ignored.
-
-3.5 - Processing of adds
-
-When data is added through a dynamic update which matches a deferred
-delete, there is no additional processing done.
-
-4 - TTL handling
-
-Any record that may be deleted SHOULD have a short TTL compared to its
-lease time, to prevent deleted data from being cached past its
-expiration.
-
-When the time until an RR is deleted becomes low enough, the server MAY
-modify the TTL of the RRset.  Whenever the TTL is automatically reduced
-by this process, the zone will be considered ``changed'' for the purpose
-of automatic SOA SERIAL increment (as in [RFC2136]) and real time zone
-slave notification [RFC1996].  As these operations can potentially be
-expensive (more so if DNSSEC [RFC2535] signatures must be regenerated),
-the specific limits and effects are left to the implementation.
-
-If the TTL is modified by the server, it is not reset if the lease is
-renewed.  Therefore, the original RR SHOULD be sent with the lease
-renewal if the client expects that the server has modified the TTL.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires October 1999                                            [Page 4]
-
-INTERNET-DRAFT        Deferred Dynamic DNS Deletes         February 1999
-
-
-5 - Usage
-
-Normally, a deferred delete update will initially be sent along with an
-add, although this is not required.  Further updates to the deferred
-delete may be sent independently, although the add should be sent again.
-If the deferred delete is associated with a leased address, the lease
-time of the update SHOULD be approximately equal to the lease time of
-the address.
-
-6 - Protocol robustness
-
-This protocol has no inherent protection against replayed messages,
-which can either originate from an attack or faulty hardware.  To
-prevent this problem, prerequisites should be used in the update
-message, such as a test for the existence of a TXT record describing the
-lease, which would be added along with the other records (see [RFC2136],
-section 5).
-
-7 - Security considerations
-
-This addition to the dynamic DNS protocol does not affect the security
-of the protocol.  If security is desired, TSIG [TSIG] and/or DNSSEC
-[RFC2535] authentication should be used, as specified in [simple-update]
-or [RFC2137, update2].  The authors strongly recommend using security
-along with this protocol.
-
-If a DNSSEC signed-zone is modified with deferred deletes, the server
-must resign any affected records when the delete is executed.  No
-special processing is required when the delete is received.
-
-8 - IANA Considerations
-
-None.
-
-9 - References
-
-[RFC1034]  P. Mockapetris, ``Domain Names - Concepts and Facilities,''
-           RFC 1034, ISI, November 1987.
-
-[RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
-           Specification,'' RFC 1035, ISI, November 1987.
-
-[RFC1996]  P. Vixie ``A Mechanism for Prompt Notification of Zone
-           Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996.
-
-[RFC2136]  P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
-           Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
-           & Cisco & DEC, April 1997.
-
-
-
-Expires October 1999                                            [Page 5]
-
-INTERNET-DRAFT        Deferred Dynamic DNS Deletes         February 1999
-
-
-[RFC2137]  D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
-           2137, CyberCash, April 1997.
-
-[RFC2535]  D. Eastlake ``Domain Name System Security Extensions,'' RFC
-           2535, IBM, March 1999.
-
-[TSIG]     P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
-           ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
-           ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs,
-           February 1999.
-
-[simple-update]
-           B. Wellington ``Simple Secure Domain Name System (DNS)
-           Dynamic Update,'' draft-ietf-dnssec-simple-update-00.txt,
-           TISLabs, November 1998.
-
-[update2]  D. Eastlake ``Secure Domain Name System (DNS) Dynamic
-           Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
-           Systems Company, August 1998.
-
-8 - Author's Address
-
-
-   Brian Wellington                          Olafur Gudmundsson
-       TISLabs at Network Associates             TISLabs at Network Associates
-       3060 Washington Road, Route 97            3060 Washington Road, Route 97
-       Glenwood, MD 21738                      Glenwood, MD 21738
-       +1 443 259 2369                           +1 443 259 2389
-       <bwelling@tislabs.com>                    <ogud@tislabs.com>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires October 1999                                            [Page 6]
-
diff --git a/doc/draft/draft-ietf-dnsind-dddd-02.txt b/doc/draft/draft-ietf-dnsind-dddd-02.txt
new file mode 100644
index 00000000..d09a2ded
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsind-dddd-02.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/doc/draft/draft-ietf-dnsind-edns1-03.txt b/doc/draft/draft-ietf-dnsind-edns1-03.txt
deleted file mode 100644
index b300eed2..00000000
--- a/doc/draft/draft-ietf-dnsind-edns1-03.txt
+++ /dev/null
@@ -1,249 +0,0 @@
-   DNSIND Working Group                                         Paul Vixie
-   INTERNET-DRAFT                                                      ISC
-   <draft-ietf-dnsind-edns1-03.txt>                                  June, 1999
-
-                          Extensions to DNS (EDNS1)
-
-   Status of this Memo
-
-      This document is an Internet-Draft and is in full conformance with
-      all provisions of Section 10 of RFC2026.
-
-      Internet-Drafts are working documents of the Internet Engineering
-      Task Force (IETF), its areas, and its working groups.  Note that
-      other groups may also distribute working documents as Internet-
-      Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of six months
-      and may be updated, replaced, or obsoleted by other documents at any
-      time.  It is inappropriate to use Internet-Drafts as reference
-      material or to cite them other than as "work in progress."
-
-      The list of current Internet-Drafts can be accessed at
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-      The list of Internet-Draft Shadow Directories can be accessed at
-      http://www.ietf.org/shadow.html.
-
-   Abstract
-
-      This document specifies a number of extensions within the Extended
-      DNS framework defined by [EDNS0], including several new extended
-      label types and the ability to ask multiple questions in a single
-      request.
-
-   1 - Rationale and Scope
-
-   1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see
-   [RFC1035]) which provides for larger message sizes, additional label
-   types, and new message flags.
-
-   1.2. This document makes use of the EDNS extension mechanisms to add
-   several new extended label types and message options, and the ability to
-   ask multiple questions in a single request.
-
-   Expires December 1999                                           [Page 1]
-
-   INTERNET-DRAFT                    EDNS1                        June 1999
-
-   2 - Affected Protocol Elements
-
-   2.1. Compression pointers are 14 bits in size and are relative to the
-   start of the DNS Message, which can be 64KB in length.  14 bits restrict
-   pointers to the first 16KB of the message, which makes labels introduced
-   in the last 48KB of the message unreachable by compression pointers.  A
-   longer pointer format is needed.
-
-   2.2. DNS Messages are limited to 65535 octets in size when sent over
-   TCP.  This acts as an effective maximum on RRset size, since multiple
-   TCP messages are only possible in the case of zone transfers.  Some
-   mechanism must be created to allow normal DNS responses (other than zone
-   transfers) to span multiple DNS Messages when TCP is used.
-
-   2.3. Multiple queries in a question section have not been supported in
-   DNS due the applicability of some DNS Message Header flags (such as AA)
-   and of the RCODE field only to a single QNAME, QTYPE, and QCLASS.
-   Multiple questions per request are desirable, and some way of asking
-   them must be made available.
-
-   3 - Extended Label Types
-
-   3.1. In [EDNS0], the ``0 1'' label type was specified to denote an
-   extended label type, whose value is encoded in the lower six bits of the
-   first octet of a label, and an extended label type of ``1 1 1 1 1 1''
-   was further reserved for use in future multibyte extended label types.
-
-   3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended
-   compression pointer, such that the following two octets comprise a
-   16-bit compression pointer in network byte order.  Like the normal
-   compression pointer, this pointer is relative to the start of the DNS
-   Message.
-
-   3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit
-   string label as described in [CRAW98].
-
-   3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long
-   local compression pointer'' as described in [KOCH98].
-
-   Expires December 1999                                           [Page 2]
-
-   INTERNET-DRAFT                    EDNS1                        June 1999
-
-   4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags
-   are structured as follows:
-
-                    +0 (MSB)                            +1 (LSB)
-         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      0: |         EXTENDED-RCODE        |            VERSION            |
-         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      2: |MD |FM |RRD|LM |                       Z                       |
-         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  (As
-                   defined by [EDNS0].)
-
-   VERSION         Indicates the implementation level of whoever sets it.
-                   Full conformance with the draft standard version of this
-                   specification is version ``1.''  Note that both
-                   requestors and responders should set this to the highest
-                   level they implement, that responders should send back
-                   RCODE=BADVERS and that requestors should be prepared to
-                   probe using lower version numbers if they receive an
-                   RCODE=BADVERS.
-
-   MD              ``More data'' flag.  Valid only in TCP streams where
-                   message ordering and reliability are guaranteed.  This
-                   flag indicates that the current message is not the
-                   complete request or response, and should be aggregated
-                   with the following message(s) before being considered
-                   complete.  Such messages are called ``segmented.''  It
-                   is an error for the RCODE (including the EXTENDED-
-                   RCODE), AA flag, or DNS Message ID to differ among
-                   segments of a segmented message.  It is an error for TC
-                   to be set on any message of a segmented message.  Any
-                   given RR must fit completely within a message, and all
-                   messages will both begin and end on RR boundaries.  Each
-                   section in a multipart message must appear in normal
-                   message order, and each section must be complete before
-                   later sections are added.  All segments of a message
-                   must be transmitted contiguously, without interleaving
-                   of other messages.
-
-   FM              ``First match'' flag.  Notable only when multiple
-                   questions are present.  If set in a request, questions
-                   will be processed in wire order and the first question
-                   whose answer would have NOERROR AND ANCOUNT>0 is treated
-
-   Expires December 1999                                           [Page 3]
-
-   INTERNET-DRAFT                    EDNS1                        June 1999
-
-                   as if it were the only question in the query message.
-                   Otherwise, questions can be processed in any order and
-                   all possible answer records will be included in the
-                   response.  Response FM should be ignored by requestors.
-
-   RRD             ``Recursion really desired'' flag.  Notable only when a
-                   request is processed by an intermediate name server
-                   (``forwarder'') who is not authoritative for the zone
-                   containing QNAME, and where QTYPE=ANY or QDCOUNT>1.  If
-                   set in a request, the intermediate name server can only
-                   answer using unexpired cached answers (either positive
-                   or negative) which were atomically acquired using (a)
-                   the same QTYPE or set of QTYPEs present in the current
-                   question and whose TTLs were each minimized to the
-                   smallest among them when first cached, and (b) the same
-                   FM and LM settings present in the current question.
-
-   LM              ``Longest match'' flag.  If this flag is present in a
-                   query message, then for any question whose QNAME is not
-                   fully matched by zone or cache data, the longest
-                   trailing label-bounded suffix of the QNAME for which
-                   zone or cache data is present will be eligible for use
-                   as an answer.  Note that an intervening wildcard name
-                   shall supercede this behaviour and the rules described
-                   in [RFC1034 4.3.2, 4.3.3] shall apply, except that the
-                   owner name of the answer will be the wildcard name
-                   rather than the QNAME.  Any of: QTYPE=ANY, or
-                   QCLASS=ANY, or QCOUNT>1, shall be considered an error if
-                   the LM flag is set.
-
-                   If LM is set in a request, then LM has meaning in the
-                   response as follows: If the content of the response
-                   would have been different without the LM flag being set
-                   on the request, then the response LM will be set; If the
-                   content of the response was not determined or affected
-                   by the request LM, then the response LM will be cleared.
-                   If the request LM was not set, then the response LM is
-                   not meaningful and should be set to zero by responders
-                   and ignored by requestors.
-
-   Z               Set to zero by senders and ignored by receivers, unless
-                   modified in a subsequent specification.
-
-   Expires December 1999                                           [Page 4]
-
-   INTERNET-DRAFT                    EDNS1                        June 1999
-
-   5 - Multiple Questions for QUERY
-
-   5.1. If QDCOUNT>1, multiple questions are present.  All questions must
-   be for the same QNAME and QCLASS; only the QTYPE is allowed to vary.  It
-   is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.
-
-   5.2. RCODE and AA apply to all RRs in the answer section having the
-   QNAME that is shared by all questions in the question section.  AA
-   applies to all matching answers, and will not be set unless the exact
-   original request was processed by an authoritative server and the
-   response forwarded in its entirety.
-
-   5.3. If a multiple question request is processed by an intermediate
-   server and the authority server does not support multiple questions, the
-   intermediate server must generate an answer iteratively by making
-   multiple requests of the authority server.  In this case, AA must never
-   be set in the final answer due to lack of atomicity of the contributing
-   authoritative responses.
-
-   5.4. If iteratively processing a multiple question request using an
-   authority server which can only process single question requests, if any
-   contributing request generates a SERVFAIL response, then the final
-   response's RCODE should be SERVFAIL.
-
-   6 - Acknowledgements
-
-   Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-   Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton,
-   and Michael Graff were each instrumental in creating this specification.
-
-   7 - References
-
-   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
-              Specification,'' RFC 1035, USC/Information Sciences
-              Institute, November 1987.
-
-   [EDNS0]    P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft
-              draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998
-
-   [CRAW98]   M. Crawford, ``Binary Labels in the Domain Name System,''
-              Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March
-              1998.
-
-   [KOCH98]   P. Koch, ``A New Scheme for the Compression of Domain
-              Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt.
-
-   Expires December 1999                                           [Page 5]
-
-   INTERNET-DRAFT                    EDNS1                        June 1999
-
-              IETF DNSIND, March 1998.
-
-   8 - Author's Address
-
-                 Paul Vixie
-                    Internet Software Consortium
-                    950 Charter Street
-                    Redwood City, CA 94063
-                    +1 650 779 7001
-                    <vixie@isc.org>
-
-   Expires December 1999                                           [Page 6]
diff --git a/doc/draft/draft-ietf-dnsind-edns1-04.txt b/doc/draft/draft-ietf-dnsind-edns1-04.txt
new file mode 100644
index 00000000..d09a2ded
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsind-edns1-04.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/doc/draft/draft-ietf-dnsind-keyreferral-00.txt b/doc/draft/draft-ietf-dnsind-keyreferral-00.txt
deleted file mode 100644
index 7670b4c6..00000000
--- a/doc/draft/draft-ietf-dnsind-keyreferral-00.txt
+++ /dev/null
@@ -1,440 +0,0 @@
-
-DNSIND WG                                                Edward Lewis
-INTERNET DRAFT                                           TIS Labs
-May Update: RFC 2535                                     Jerry Scharf
-Catagory: I-D                                            ISC
-                                                         April 1, 1999
-
-                             The Zone Key Referral
-                     <draft-ietf-dnsind-keyreferral-00.txt>
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Comments should be sent to the authors or the DNSIND WG mailing list
-   <namedroppers@internic.net>.
-
-   This draft expires on October 1, 1999
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All rights
-   reserved.
-
-Notes on this document
-
-This section will only appear in the -00.txt edition of this draft.
-
-This document originated in the DNSSEC working group in June 1998.  The
-discussion of the issues in this draft were tabled until the publication
-of the then current DNSSEC drafts as RFCs.
-
-The first version of this document lists a third author, John Gilmore.
-He is listed as an author because he was one of the initiators of what is
-proposed.  In this and following versions he is only listed in the
-Acknowledgements (as opposed to being an author) as he has not been
-involved in the writing/editing of the draft.  This has been done to
-avoid assigning his name to a document he may not have a chance to read,
-this is not intended as a slight on his efforts.
-
-When commenting on this draft, please be aware that some terms used here
-are up for negotiation before progressing - such as "thief" and "road
-block" appearing later in the draft.  Comments which are left justified
-were added during the re-issuing of the draft, they add context that
-may have been lost over time.
-
-  Abstract
-
-    A new type of key is defined to address the problems of
-    performance in large delegeted zones and issues of liability of
-    registrars with regards to the storing of public keys belonging
-    to zone cuts.  This new key type also brings DNSSEC more in line
-    with the DNS treatment of zone cuts and speeds recovery in
-    handling privatekey exposure.
-
-    The new type of key is a referral record that is stored, signed,
-    at the parent zone's place for the delegation point.  A resolver
-    receiving this record is being informed that there are genuine
-    public keys at the child's authoritative name servers.  The
-    parent no longer needs to store the child's public keys locally.
-
-1 Introduction
-
-    There are a number of different reasons for the proposal of this
-    new key type.  Reasons include:
-     o the performance impact that RFC 2535 has on name servers
-     o the problem of updating a widely delegated parent zone on demand
-     o statements in RFC 2181 on authoritative data at delegations
-     o perceived liability of the operator of a name server or registry
-
-    To address these issues, which are expanded upon below, a new
-    key type is proposed - a "zone key referral" - to join the user
-    key, host key, and zone key types defined in RFC 2535.
-
-1.1 Performance Issues
-
-    A sample zone will be used to illustrate the problem.  The
-    example will part from reality mostly in the length of zone
-    names, which changes the size of the owner and resource record
-    data fields.
-
-        # $ORIGIN test.
-        # @         IN SOA   <SOA data>
-        #           IN SIG   SOA <by test.>
-        #           IN KEY   <1024 bit zone key>
-        #           IN SIG   KEY <by test.>
-        #           IN SIG   KEY <by .>
-        #           IN NS    ns.test.
-        #           IN SIG   NS <by test.>
-        #           IN NXT   my-org.test. NS SOA SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-        #
-        # my-org    IN KEY   <1024 bit zone key>
-        #           IN KEY   <1024 bit zone key>
-        #           IN SIG   KEY <by test.>
-        #           IN NS    ns1.my-org.test.
-        #           IN NS    ns2.my-org.test.
-        #           IN NXT   them.test. NS SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-        #
-        # them      IN KEY   0xC100 3 1
-        #           IN SIG   KEY <by test.>
-        #           IN NS    ns1.them.test.
-        #           IN NS    ns2.them.test.
-        #           IN NXT   test. NS SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-
-    In this zone file fragment, "my-org" is a delegation point of
-    interest with two registered public keys.  Presumably, one key
-    is for signatures generated currently and the other is for still
-    living and valid but older signatures.  "them" is another
-    delegation point, with a NULL key. This signifies that this zone
-    is unsecured.
-
-    To analyze the performance impact of the storing of keys, the
-    number of bytes used to represent the RRs in the procotol format
-    is used.  The actual number of bytes stored will likely be
-    higher, accounting for data structure overhead and alignment.
-    The actual number of bytes transferred will be lower due to DNS
-    name compression.
-
-    The number of bytes for my-org's two 1024-bit keys, two NS
-    records, NXT and the associated signatures is 526.  The bytes
-    needed for them (with the NULL key) is 346.  Currently, there
-    are close to 2 million entries in com., so if we take my-org as
-    a typical domain, over 1GB on memory will be needed for com.
-
-    The zone keys used in the example are set to 1024 bits.  This
-    number may range from as low as 512 bits upwards to over 3000
-    bits.  To scale the above numbers to a different key size,
-    multiply the difference in key sizes by 4 for my-org and by 2
-    for them, and adjust the numbers accordingly.
-
-    The increased size of the data held for the zone cuts will have
-    two impacts at the transport and below layers.  Bandwidth beyond
-    that currently needed will be used to carry the KEY records.
-    The inclusion of all of the child's keys will also push DNS over
-    the UDP size limit and start using TCP - which could cause
-    critical problems for current heavily used name servers, like
-    the roots.
-
-    Another impact, not illustrated by the example, is the frequency
-    of updates.  If each time a public key for my-org is added or
-    deleted, the SOA serial number will have to increase, and the
-    SOA signed again.  If an average zone changes its keys(s) once
-    per month, there will be on average 45 updates per minute in a
-    zone of 2 million delegations.
-
-(The multiple algorithms issue is an extension of multiple keys.  The
-example should be updated to show at least a DSS key as well as an RSA
-key.)
-
-1.2 Security Incident Recovery (w/ respect to keys only)
-
-    Once a zone administrator is alerted that any key's private
-    counterpart has been discovered (exposed), the first action to
-    be taken is to stop advertising the public key in DNS.  This
-    doesn't end the availability of the key - it will be residing in
-    caches - but is the closest action resembling revokation
-    available in DNS.
-
-    Stopping the advertisement in the zone's name servers is as
-    quick as altering the master file and restarting the name
-    server.  Having to do this in two places will will only delay
-    the time until the recovery is complete.
-
-    For example, a registrar of a top level domain has decided to
-    update its zone only on Mondays and Fridays due to the size of
-    the zone.  A customer/delegatee is the victim of a break in, in
-    which one of the items taken is the file of private keys used to
-    sign DNS data. If this occurs on a Tuesday, the thief has until
-    Friday to use the keys before they disappear from the DNS, even
-    if the child stops publishing them immediately.
-
-    If the public key set is in the parent zone, and the parent zone
-    is not able to make the change quickly, the public key cannot be
-    revoked quickly.  If the parent only refers to there being a key
-    at the child zone, then the child has the agility to change the
-    keys - even issue a NULL key, which will force all signatures in
-    the zone to become suspect.
-
-1.3 DNS Clarifications
-
-    RFC 2181, section 6, clarifies the status of data appearing at a
-    zone cut.  Data at a zone cut is served authoritatively from the
-    servers listed in the NS set present at the zone cut.  The data
-    is not (necessarily) served authoritatively from the parent.
-    (The exception is in servers handling both the parent and child
-    zone.)
-
-    Section 6 also mentions that there are two exceptions created by
-    DNSSEC, the NXT single record set and the KEY set.  This
-    proposal addresses the exception relating to the KEY set,
-    limiting its severity (but falling short of removing it
-    altogether).  By limiting the exception, we will be simplifying
-    DNS.
-
-1.4 Liability
-
-    Liability is a legal concept, so it is not wise to attempt an
-    engineering solution to it.  However, the perceived liability
-    incurred in using DNSSEC by registrars may prevent the adoption
-    of DNSSEC.  Hence DNSSEC should be engineered in such a away to
-    address the concern.
-
-    One source of liability is the notion that by advertising a
-    public key for a child zone, a parent zone is providing a
-    service of security.  With that comes responsibility.  By having
-    the parent merely indicate that a child has a key (or has no
-    key), the parent is providing less in the way of security.  If
-    the parent is wrong, the potential loss is less.  Instead of
-    falsely authenticated data, configuration errors will be
-    apparent to the resolving client.
-
-2 The Proposal
-
-    The proposal is to introduce a new key type which indicates
-    whether the delegated zone is running secured or not.  Running
-    secured is either a zone signed with at least one key, an
-    experimental zone, or a zone with only NULL keys published.
-
-    The Zone Referral Key will resemble the NULL key in syntax.
-    There will be a flags field, an algorithm field, and a protocol
-    field, but no public key material.  The Referral Key is signed
-    by the parent zone, as was the public key set in RFC 2065.
-    There is only one Referral Key RR present.
-
-    The Referral Key flags field will have the following values:
-     Field      Bit(s)     Value      Meaning
-
-      A/C        0- 1      0b01       indicates a key will be found
-                           0b11       indicates a key will not be found
-                           0b?0       error (referral cannot encrypt)
-      XT          2        0          no extended flags are needed
-      Z          4- 5      0          must be zero for all keys
-      NAMTYP     6- 7      0b11       this is a referral to a zone key
-      Z          8-11      0          must be zero for all keys
-      SIG       12-15      0          must be zero for a referral key
-
-    The legal values of the flags field are (in summary):
-
-      Hex Value    Indicates
-      0x4300       The delegation has a key record set
-      0xC300       The delegation has no key record
-
-    Other values are not valid for Referral Keys (but may be valid
-    for other keys).
-
-    The Protocol field must be set to 3, the DNSSEC protocol value.
-
-    The Algorithm field must be 0.
-
-The algorithm is not important at this point.  So long as the searcher
-knows to expect a key set at the delegated zone's apex, a secure chain
-is possible.  One the key set is retrieved and verified, then the
-algorithms used in the delegated zone are known.  (The issue is that a
-zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc.,
-and a secure resolver must know this in order to set signature arrival
-expectations.
-
-2.1 Example
-
-    The Referral key for my-org.test. and them.test. would appear as
-    the following in the zone master file:
-
-          my-org.test. IN KEY   0x4300 3 0
-          them.test.   IN KEY   0xC300 3 0
-
-    In the example introduced earlier, the master file would change
-    to the following.
-
-        # $ORIGIN test.
-        # @         IN SOA   <SOA data>
-        #           IN SIG   SOA <by test.>
-        #           IN KEY   <1024 bit zone key>
-        #           IN SIG   KEY <by test.>
-        #           IN SIG   KEY <by .>
-        #           IN NS    ns.test.
-        #           IN SIG   NS <by test.>
-        #           IN NXT   my-org.test. NS SOA SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-        #
-        # my-org    IN KEY   0x4300 3 0
-        #           IN SIG   KEY <by test.>
-        #           IN NS    ns1.my-org.test.
-        #           IN NS    ns2.my-org.test.
-        #           IN NXT   them.test. NS SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-        #
-        # them      IN KEY   0xC300 3 1
-        #           IN SIG   KEY <by test.>
-        #           IN NS    ns1.them.test.
-        #           IN NS    ns2.them.test.
-        #           IN NXT   test. NS SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-
-3 Analysis
-
-    By removing the public keys from the parent's master file, the
-    parent is no longer a road block during an emergency removal of
-    keys.  A parent zone is unchanged as a zone changes from NULL
-    keys to experimental keys to fully signed.  The parent is also
-    not providing a security service, other than to authentically
-    claim the existence of a KEY record set - akin to the "hints" of
-    the name servers.
-
-    The change also improves the prospect for performance.  The need
-    for multiple KEY RR's, each one on the order of 100 bytes, is
-    removed and replaced by a single KEY RR of the order of 25
-    bytes.  Saving bytes reduces the need to use TCP to avoid
-    truncated responses.  Also, the need for updating the zone drops
-    - no longer will there be updates for each key change.
-
-    As far as the statements by RFC 2181 conerning authority levels,
-    the Referral Key is not authortative and would be superseeded by
-    a verified set of the real zone keys.  The only caveat is that
-    once the verified set of keys expire (assuming the parent has to
-    learn the keys from another server), the Referal Key must
-    reappear.  This is an example of what has been labelled "mount-
-    like semantics."
-
-    [No reference for mount-like semantics has yet been found.]
-
-    The last point is important.  This requires the "mount-like
-    semantics" that have been discussed for the BIND name servers.
-    Once hints are overridden by learned, authorititative and
-    verified data, the hints are not discarded.  Hints in this state
-    are stored and become visible when the learned data expires.
-
-4 IANA Considerations
-
-    Other than using a new value in the flags field of the KEY RR,
-    no new number assignments are needed.  The flags field is not
-    under the control of IANA as of yet.  There are no requirements
-    placed on IANA by this draft.
-
-5 Security Considerations
-
-    There has been some debate about whether the Referral key should
-    be treated as a hint - just like the NS records.  If so, then
-    there is no need to sign the Referral Key, and an unsigned
-    (hence non-authenticated) security record is of little value.
-    So, is the Referral Key even needed?
-
-    Authentication in DNSSEC is done from the data "back" towards a
-    trusted point - e.g., "up" to the root.  Since the
-    authentication is done by going repeatedly from child to parent,
-    why bother having the parent indicate the status of the child?
-
-    The answer is in the scenario in which a resolver somewhere has
-    obtained data which fails the verification process.  Perhaps the
-    signature is wrong, a key in the chain of trust is unavailable,
-    the set should have had a signature, but none is found (or vice
-    versa), or the trail of signed-by names is not acceptable.  In
-    this case, the resolver needs to find the authoritative zone,
-    its status and its name server set.
-
-    If a zone is being attacked by a masquerader, and parents do not
-    make any statements about the security of child zones, then an
-    easy and successfull attack may occur.  An attacker only needs
-    to supply either fake name server records or glue records to
-    redirect queries.
-
-    While this attack will not be stopped as far as denial of
-    service, the masquerader can be stopped from being accepted as
-    an authoritative source if the parent of the zone claims the
-    child is secure and signs the public keys of the true child and
-    not the masquerader.
-
-    The masquerader cannot successfully claim that the zone is
-    unsigned, because it must have a zone key signed by the parent.
-    NULL or not, the key would not be trusted by the resolver,
-    assuming the parent has not also been duped.  The resolver,
-    sensing this, should report an error or security incident, and
-    not accept data.
-
-6 Acknowledgements
-
-    John Gilmore originally raised the issues that have led to this
-    document.
-
-7 Author's addresses
-
-Edward Lewis                 Jerry Scharf
-<lewis@tislabs.com>          <scharf@vix.com>
-3060 Washinton Rd (Rte 97)
-Glenwood, MD 21738
-+1(443)259-2352
-
-8 References
-
-RFC 2181 "Clarifications to the DNS Specification", Elz and Bush
-RFC 2535 "Domain Name System Security Extensions", Eastlake
-
-9 Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published and
-   distributed, in whole or in part, without restriction of any kind,
-   provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-This draft expires on October 1, 1999
diff --git a/doc/draft/draft-ietf-dnsind-keyreferral-01.txt b/doc/draft/draft-ietf-dnsind-keyreferral-01.txt
new file mode 100644
index 00000000..d09a2ded
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsind-keyreferral-01.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/doc/draft/draft-ietf-dnsind-local-compression-05.txt b/doc/draft/draft-ietf-dnsind-local-compression-05.txt
deleted file mode 100644
index ec27e3ac..00000000
--- a/doc/draft/draft-ietf-dnsind-local-compression-05.txt
+++ /dev/null
@@ -1,420 +0,0 @@
-INTERNET-DRAFT                                                Peter Koch
-Expires: December 1999                            Universitaet Bielefeld
-Updates: 1035, 1183, 2163, 2168, 2535                          June 1999
-
-            A New Scheme for the Compression of Domain Names
-               draft-ietf-dnsind-local-compression-05.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Comments should be sent to the author or the DNSIND WG mailing list
-   <namedroppers@internic.net>.
-
-Abstract
-
-   The compression of domain names in DNS messages was introduced in
-   [RFC1035].  Although some remarks were made about applicability to
-   future defined resource record types, no method has been deployed yet
-   to support interoperable DNS compression for RR types specified since
-   then.
-
-   This document summarizes current problems and proposes a new
-   compression scheme to be applied to future RR types which supports
-   interoperability.  Also, suggestions are made how to deal with RR
-   types defined so far.
-
-1. Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-
-Koch                     Expires December 1999                  [Page 1]
-
-INTERNET-DRAFT              DNS Compression                    June 1999
-
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Domain names herein are for explanatory purposes only and should not
-   be expected to lead to useful information in real life [RFC2606].
-
-2. Background
-
-   Domain name compression was introduced in [RFC1035], section 4.1.4,
-   as an optional protocol feature and later mandated by [RFC1123],
-   section 6.1.2.4.  The intent was to reduce the message length,
-   especially that of UDP datagrams, by avoiding repetition of domain
-   names or even parts thereof.
-
-   A domain name is internally represented by the concatenation of label
-   strings, where the first octet denotes the string length, not
-   including itself.  The null string, consisting of a single octet of
-   zeroes, is the representation of the root domain name and also
-   terminates every domain name.
-
-   As labels may be at most 63 characters long, the two most significant
-   bits in the length octet will always be zero. Compression works by
-   overloading the length octet with a second meaning. If the two MSB
-   have the value '1', the remainder of the length octet and the next
-   octet form a compression pointer, which denotes the position of the
-   next label of the current domain name in the message:
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          | 1  1|                OFFSET                   |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   It is important that these pointers always point backwards.
-
-   Compression may occur in several places. First, the owner name of an
-   RR may be compressed. The compression target may be another owner
-   name or a domain name in the RDATA section of a previous RR.  Second,
-   any domain name within the RDATA section may be compressed and the
-   target may be part of the same RR, being the owner name or another
-   domain name in the RDATA section, or it may live in a previous RR,
-   either as its owner or as a domain name in its RDATA section.  In
-   fact, due to the chaining feature, combinations of the above may
-   occur.
-
-3. Problems
-
-   While implementations shall use and must understand compressed domain
-   names in the RDATA section of "well known" RR types (those initially
-   defined in [RFC1035]), there is no interoperable way of applying
-
-Koch                     Expires December 1999                  [Page 2]
-
-INTERNET-DRAFT              DNS Compression                    June 1999
-
-   compression to the RDATA section of newer RRs:
-
-   Quote from [RFC1123], section 6.1.3.5:
-        Compression relies on knowledge of the format of data inside a
-        particular RR.  Hence compression must only be used for the
-        contents of well-known, class-independent RRs, and must never be
-        used for class-specific RRs or RR types that are not well-known.
-        The owner name of an RR is always eligible for compression.
-
-   DNS records in messages may travel through caching resolvers not
-   aware of the particular RR's type and format. These caches cannot
-   rearrange compression pointers in the RDATA section simply because
-   they do not recognize them. Handing out these RRs in a different
-   context later will lead to confusion if the target resolver tries to
-   uncompress the domain names using wrong information.  This is not
-   restricted to intermediate caching but affects any modification to
-   the order of RRs in the DNS message.
-
-4. Local Compression
-
-   We often observe a certain locality in the domain names used as owner
-   and occuring in the RDATA section, e.g. in MX or NS RRs but also in
-   newer RR types [RFC1183]:
-
-      host.foo.bar.example  RP  adm.foo.bar.example  adm.persons.bar.example
-
-   So, to still profit from compression without putting interoperability
-   at risk, a new scheme is defined which limits the effect of
-   compression to a single RR.
-
-   In contrast to the usual method of using offsets relative to the
-   start of a DNS packet we start counting at the RR owner or calculate
-   pointers relative to the start of the RDATA to avoid context
-   sensitivity.  We use an additional compression indicator for a two
-   octet local pointer:
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          | 1  0|                OFFSET                   |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The "10" bits will indicate the use of local compression and
-   distinguish it from conventional compression, plain labels and EDNS
-   label codes [EDNS0].  Two types of pointers need to be specified:
-   those pointing into the owner name and those pointing into RDATA.
-
-   A) Pointers into the owner name are interpreted as the ordinal label
-      number (starting at 0 for the topmost label, the TLD). This way we
-      avoid the need for extra decompression of the owner name during
-
-Koch                     Expires December 1999                  [Page 3]
-
-INTERNET-DRAFT              DNS Compression                    June 1999
-
-      message composition or decomposition.
-
-      The highest possible value of a compression pointer pointing into
-      the owner name is 254. The value 255 is reserved for future use.
-
-   B) Pointers into the RDATA section start at the fixed value 256 for
-      the first octet and have a maximum value of 16383 limiting
-      possible targets to the first 16128 octets. The actual offset
-      relative to the start of RDATA is determined by subtracting 256
-      from the value of the pointer.
-
-   Local pointers MUST point to a previous occurence of the same name in
-   the same RR.  Even domain names in another RR of the same type cannot
-   serve as compression targets since the order of RRs in an RRSet is
-   not necessarily stable.  The length of the compressed name(s) MUST be
-   used in the length calculation for the RDLENGTH field.
-
-Example
-
-   Consider a DNS message containing two resource records, one CNAME RR
-   and one XMPL RR, undefined and meaningless so far, with an RDATA
-   section consisting of two domain names:
-
-      ab.foo.example  IN  CNAME  bar.example
-      bar.example     IN  XMPL   a.foo.example  foo.example
-
-   In a message this appears as follows (randomly starting at octet 12):
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       12 |           2           |           a           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       14 |           b           |           3           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       16 |           f           |           o           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       18 |           o           |           7           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       20 |           e           |           x           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       22 |           a           |           m           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       24 |           p           |           l           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       26 |           e           |           0           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
-
-Koch                     Expires December 1999                  [Page 4]
-
-INTERNET-DRAFT              DNS Compression                    June 1999
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       38 |           3           |           b           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       40 |           a           |           r           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       42 | 1  1|                 19                      |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The XMPL RR with local compression applied:
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       44 | 1 1 |                 38                      |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       56 |           1           |           a           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       58 |           3           |           f           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       60 |           o           |           o           |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       62 | 1  0|                 0                       |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       64 | 1  0|               258                       |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The first local pointer at position 62 points to the topmost label
-   "example" of the XMPL RR's owner.
-
-   The second local pointer at position 64 represents the "foo.example"
-   and points backwards into the RDATA section, third octet, at absolute
-   position 58.  Note that with conventional compression this example
-   message would have occupied less space.
-
-5. Interaction with DNSSEC
-
-   The security extensions to DNS [RFC2535] mandate that domain names in
-   RDATA be signed only in expanded, lower case format. For RR types
-   using local compression the specification is changed as follows:
-
-      Resource Records subject to local compression MUST be stored,
-      signed, transmitted and verified in locally compressed form.  Name
-      expansion or canonicalization MUST NOT be performed on the RDATA
-      section for signing or verification.
-
-   This way RR type transparency can be achieved, since domain names in
-
-Koch                     Expires December 1999                  [Page 5]
-
-INTERNET-DRAFT              DNS Compression                    June 1999
-
-   the RDATA section are treated as arbitrary data and can be cached and
-   verified by resolvers not aware of the particular RR type. Old RR
-   types subject to conventional or no compression are not affected by
-   this change.
-
-   Wildcard owners may serve as compression targets only in their fixed
-   part.  Even if a particular query asks for a domain name which could
-   be used to compress the RDATA part more efficiently, this MUST NOT be
-   done. Otherwise signatures would be invalidated.
-
-   Currently slave servers store zones in text format and re-encode the
-   data into wire format, e.g. after a restart. This encoding must be
-   unique to ensure signature validity. To achieve this, local
-   compression MUST be applied optimally, i.e. every domain name must be
-   compressed as far as possible and each local compression pointer must
-   point to the earliest available target (including the owner).
-
-6. Interaction with Binary Labels
-
-   When constructing local compression pointers into the owner name,
-   every one-bit label is counted as a label. This way the compression
-   and decompression is independent of the actual bit-string
-   representation.
-
-   For local compression pointers into the RDATA section, only bit-
-   string labels may serve as targets, not single one-bit labels. Bit-
-   string labels may be adjusted to increase compression efficiency
-   [BINLABELS, section 3.1]
-
-   The internal representation of a domain name has a maximum length of
-   255 [RFC 1035].  Any label consists of at least two octets, leading
-   to at most 127 labels per domain name plus the terminating zero
-   octet, which does not qualify as a compression target. With the
-   introduction of binary labels a domain name can consist of up to 1904
-   labels (all one-bit labels). This document restricts the possible
-   compression targets in an owner name to the topmost 255 labels. This
-   limit was chosen to be consistent with [RFC2535], section 4.1.3.
-
-7. Old RR types and deployment
-
-   Although differences in RDATA sections by class have not yet been
-   reported and the concept of classes did not really spread, we are
-   just considering the IN class here.
-
-   The following RR types with domain names in the RDATA section have
-   been defined since [RFC1035] (Standards Track, Experimental and
-   Informational RFCs, ignoring withdrawn types):  RP [RFC1183], AFSDB
-   [RFC1183], RT [RFC1183], SIG [RFC2535], PX [RFC2163], NXT [RFC2535],
-
-Koch                     Expires December 1999                  [Page 6]
-
-INTERNET-DRAFT              DNS Compression                    June 1999
-
-   SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230].  Some specifications do
-   not mention DNS compression at all, others explicitly suggest it and
-   only in part identify interoperability issues.  Only the KX and SRV
-   RR types are safe as their specifications prohibit compression.
-
-   The specification of RP, AFSDB, RT, PX, and NAPTR is hereby changed
-   in that domain names in the RDATA section MUST NOT be compressed and
-   MUST NOT be compression targets.
-
-   Local compression MUST NOT be used for owner names and it MUST NOT be
-   applied to domain names in RDATA sections of any RR type defined so
-   far.
-
-   The specification of future RR types should explicitly select the use
-   of local compression or forbid RDATA domain name compression at all.
-
-8. Security Considerations
-
-   The usual caveats for using unauthenticated DNS apply. This scheme is
-   believed not to introduce any new security problems.  However,
-   implementors should be aware of problems caused by blindly following
-   compression pointers of any kind. [RFC1035] and this document limit
-   compression targets to previous occurences and this MUST be followed
-   in constructing and decoding messages. Otherwise applications might
-   be vulnerable to denial of service attacks launched by sending DNS
-   messages with infinite compression pointer loops. In addition,
-   pointers should be verified to really point to the start of a label
-   (for conventional and local RDATA pointers) and not beyond the end of
-   the domain name (for local owner name pointers).
-
-   The maximum length of 255 applies to domain names in uncompressed
-   wire format, so care must be taken during decompression not to exceed
-   this limit to avoid buffer overruns.
-
-9. Acknowledgements
-
-   The author would like to thank Andreas Gustafsson, Paul Vixie, Bob
-   Halley, Mark Andrews and Thomas Narten for their review and
-   constructive comments.
-
-10. References
-
-   [RFC1034]     Mockapetris,P., "Domain Names - Concepts and Facilities",
-                 RFC 1034, STD 13, November 1987
-
-Koch                     Expires December 1999                  [Page 7]
-
-INTERNET-DRAFT              DNS Compression                    June 1999
-
-   [RFC1035]     Mockapetris,P., "Domain Names - Implementation and
-                 Specification", RFC 1035, STD 13, November 1987
-
-   [RFC1123]     Braden,R., "Requirements for Internet Hosts -- Application
-                 and Support", RFC 1123, STD 3, October 1989
-
-   [RFC1183]     Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New
-                 DNS RR Definitions", RFC 1183, October 1990
-
-   [RFC2052]     Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the
-                 location of services (DNS SRV)", RFC 2052, October 1996
-
-   [RFC2119]     Bradner,S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", RFC 2119, BCP 14, March 1997
-
-   [RFC2163]     Allocchio,C., "Using the Internet DNS to Distribute MIXER
-                 Conformant Global Address Mapping (MCGAM)", RFC 2163,
-                 January 1998
-
-   [RFC2168]     Daniel,R., Mealling,M., "Resolution of Uniform Resource
-                 Identifiers using the Domain Name System", RFC 2168, June
-                 1997
-
-   [RFC2230]     Atkinson,R., "Key Exchange Delegation Record for the DNS",
-                 RFC 2230, November 1997
-
-   [RFC2535]     Eastlake,D., "Domain Name System Security Extensions", RFC
-                 2535, March 1999
-
-   [RFC2606]     Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
-                 RFC 2606, BCP 32, June 1999
-
-   [EDNS0]       Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft-
-                 ietf-dnsind-edns0-XX.txt, work in progress
-
-   [BINLABELS]   Crawford,M., "Binary Labels in the Domain Name System",
-                 draft-ietf-dnsind-binary-labels-XX.txt, work in progress
-
-11. Author's Address
-
-   Peter Koch
-   Universitaet Bielefeld
-   Technische Fakultaet
-   Postfach 10 01 31
-   D-33501 Bielefeld
-   Germany
-
-Koch                     Expires December 1999                  [Page 8]
-
-INTERNET-DRAFT              DNS Compression                    June 1999
-
-   +49 521 106 2902
-   <pk@TechFak.Uni-Bielefeld.DE>
-
-Koch                     Expires December 1999                  [Page 9]
diff --git a/doc/draft/draft-ietf-dnsind-local-compression-06.txt b/doc/draft/draft-ietf-dnsind-local-compression-06.txt
new file mode 100644
index 00000000..d09a2ded
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsind-local-compression-06.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/doc/draft/draft-ietf-dnsind-rollover-00.txt b/doc/draft/draft-ietf-dnsind-rollover-00.txt
deleted file mode 100644
index 8d8cef1c..00000000
--- a/doc/draft/draft-ietf-dnsind-rollover-00.txt
+++ /dev/null
@@ -1,648 +0,0 @@
-INTERNET-DRAFT           			     DNSIND Key Rollover
-UPDATES RFC 1996                                              April 1999
-                                                    Expires October 1999
-draft-ietf-dnsind-rollover-00.txt
-
-
-
-             Domain Name System (DNS) Security Key Rollover
-             ------ ---- ------ ----- -------- --- --------
-
-                  Donald E. Eastlake 3rd, Mark Andrews
-
-
-
-Status of This Document
-
-   This draft, file name draft-ietf-dnsind-rollover-00.txt, is intended
-   to be become a Proposed Standard RFC.  Distribution of this document
-   is unlimited. Comments should be sent to the DNS working group
-   mailing list <namedroppers@internic.net> or to the authors.
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups.  Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months.  Internet-Drafts may be updated, replaced, or obsoleted by
-   other documents at any time.  It is not appropriate to use Internet-
-   Drafts as reference material or to cite them other than as a
-   ``working draft'' or ``work in progress.''
-   
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-
-Abstract
-
-   Deployment of Domain Name System (DNS) security with good cryptologic
-   practice will involve large volumes of key rollover traffic.  A
-   standard format and protocol for such messages will be necessary for
-   this to be practical and is specified herein.
-
-   [Note: this draft has been moved to dnsind from dnssec as part of the
-   ongoing combination of these working groups.  It would have been
-   draft-ietf-dnssec-rollover-01.txt otherwise.]
-
-
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 1]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. Key Rollover Scenario...................................3
-      3. Rollover Operation......................................5
-      3.1 Rollover to Parent.....................................5
-      3.2 Rollover to Children...................................6
-      4. Secure Zone Cuts and Joinders...........................7
-      5. Security Considerations.................................8
-      6. IANA Considerations.....................................9
-
-      References................................................10
-      Authors Address...........................................10
-      Expiration and File Name..................................11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 2]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-1. Introduction
-
-   The Domain Name System (DNS) [RFC 1034, 1035] is the global
-   hierarchical replicated distributed database system for Internet
-   addressing, mail proxy, and other information.  The DNS has been
-   extended to include digital signatures and cryptographic keys as
-   described in [RFC 2535].
-
-   The principle security service provided for DNS data is data origin
-   authentication.  The owner of each zone signs the data in that zone
-   with a private key known only to the zone owner.  Anyone that knows
-   the corresponding public key can then authenticate that zone data is
-   from the zone owner.  To avoid having to preconfigure resolvers with
-   all zone's public keys, keys are stored in the DNS with each zone's
-   key signed by its parent (if the parent is secure).
-
-   To obtain high levels of security, keys must be periodically changed,
-   or "rolled over".  The longer a private key is used, the more likely
-   it is to be compromised due to cryptanalysis, accident, or treachery
-   [RFC 2541].
-
-   In a widely deployed DNS security system, the volume of update
-   traffic will be large.  Just consider the .com zone.  If only 10% of
-   its children are secure and change their keys only once a year, you
-   are talking about hundreds of thousands of new child public keys that
-   must be securely sent to the .com manager to sign and return with
-   their new parent signature.  And when .com rolls over its private
-   key, it will needs to send hundred of thousands of new signatures on
-   the existing child public keys to the child zones.
-
-   It will be impractical to handle such update volumes manually on a
-   case by case basis.  The bulk of such key rollover updates must be
-   automated.
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and "MAY"
-   in this document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Key Rollover Scenario
-
-   Although DNSSEC provides for the storage of other keys in the DNS for
-   other purposes, DNSSEC zone keys are included solely for the purpose
-   of being retrieved to authenticate DNSSEC signatures.  Thus, when a
-   zone key is being rolled over, the old public key should be left in
-   the zone, along with the addition of the new public key, for as long
-   as it will reasonably be needed to authenticate old signatures that
-   have been cached or are held by applications.  Similarly, old parent
-   SIGs should be retained for a short time after a parent KEY(s) roll
-   over and new parent SIGs have been installed.
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 3]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-   If DNSSEC were universally deployed and all DNS server's clocks were
-   synchronized and zone transfers were instantaneous etc., it might be
-   possible to avoid ever having duplicate old/new KEY/SIG RRsets due to
-   simultaneous expiration of SIGs everywhere in the DNS.  But these
-   assumptions do not hold.  Security aware DNS servers decrease the TTL
-   of secure RRs served as the expiration of their authenticating SIG(s)
-   approaches but some dithered fudge must generally be left due to
-   clock skew, RR retention by applications, and the like.  Retaining
-   old KEYs for a while after rolling over to new KEYs will be necessary
-   in practical cases.
-
-   Assume a middle zone with a secure parent and a secure child wishes
-   to role over its KEY RRset.  This RRset would probably be one KEY RR
-   per crypto algorithm used to secure the zone, but for this scenario,
-   we will simply assume it is one KEY RR.  The old KEY RR and two SIG
-   RRs will exist at the apex of the middle zone.  (These RRs may also
-   exist at the leaf node for this zone in its parent if the parent
-   chooses to store them there.) The contents of the middle zone and the
-   zone KEY RRs of its secure child will have SIGs under the old key.
-
-   The middle zone owner needs to communicate with its parent to obtain
-   a new parental signature covering both the old and new KEY RRs and
-   covering just the new KEY RR.  The signature on both is needed so the
-   old KEY can be retain for the period it might be needed to
-   authenticate old SIGs.  The middle zone would probably want to obtain
-   these in advance so that it can install them at the right time along
-   with its new SIG RRs covering the content of its zone.  Finally, it
-   needs to give new SIG RRs to its child that cover its KEY RRs so it
-   must signal its children to ask for such SIG RRs.
-
-          BEFORE ROLLOVER        SHORTLY AFTER             AFTER ROLLOVER
-
-       p.x     KEY      P1     p.x     KEY      P1     p.x     KEY      P1
-       p.x     SIG(KEY) P1     p.x     SIG(KEY) P1     p.x     SIG(KEY) P1
-       p.x     SIG(KEY) GP     p.x     SIG(KEY) GP     p.x     SIG(KEY) GP
-
-       m.p.x   KEY      M1     m.p.x   KEY      M2     m.p.x   KEY      M2
-       m.p.x   SIG(KEY) P1     m.p.x   KEY      M1     m.p.x   SIG(KEY) P1
-       m.p.x   SIG(KEY) M1     m.p.x   SIG(KEY) P1     m.p.x   SIG(KEY) M2
-                               m.p.x   SIG(KEY) M2
-
-       c.m.p.x KEY      C1     c.m.p.x KEY      C1     c.m.p.x KEY      C1
-       c.m.p.x SIG(KEY) M1     c.m.p.x SIG(KEY) M2     c.m.p.x SIG(KEY) M2
-       c.m.p.x SIG(KEY) C1     c.m.p.x SIG(KEY) M1     c.m.p.x SIG(KEY) C1
-                               c.m.p.x SIG(KEY) C1
-
-         p = parent, m = middle, c = child, GP = grandparent key
-         P* = parent key, M* = middle zone key, C* = child key
-
-
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 4]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-3. Rollover Operation
-
-   Rollover operations use a DNS request syntactically identical to the
-   UPDATE request [RFC 2136] (except that the operation code is ROLLOVER
-   which is equal to (TBD)) and use a new form of NOTIFY [RFC 1996].
-   Considerations for such requests to the parent and children of a zone
-   are givens below.
-
-   All rollover operations involve significant amounts of cryptographic
-   calculations.  Appropriate rate limiting SHOULD be applied to avoid
-   denial of service attacks.
-
-   [This draft does not consider cross-certification key rollover.]
-
-
-
-3.1 Rollover to Parent
-
-   A zone rolling over its KEY RRset sends an upward ROLLOVER request to
-   its parent.  Actually, it will normally do two upward ROLLOVERs, one
-   for a combined KEY RRset of its old and new KEYs and one for just its
-   new KEY RRset, as discussed above.
-
-   The server selection algorithm in [RFC 2136] section 4 should be
-   used.  A child needs to be configured with or determine the name of
-   its parent but SHOULD NOT remember the location of its parent other
-   than via normal DNS caching of address RRs so that rollover will
-   continue to work if its parent servers are moved.
-
-   The ROLLOVER request Zone should be specified as the parent zone.
-   The request Update section has the new KEY RRset on which the parent
-   signature is requested along with the requesting zone's SIG(s) under
-   its old KEY(s) as RRs to be "added" to the parent zone.  The
-   inception and expiration times in this child SIG or SIGs are the
-   requested inception and expiration times for the new parent SIG(s).
-   The "prerequisites" section has the old child KEY RRset with the
-   parent SIG (see next paragraph).
-
-   An upward ROLLOVER request MUST be signed and if not signed a BADAUTH
-   response generated. The signature MUST be under the previous zone
-   KEY, so the parent can validate it, or under a valid TSIG key
-   [draft-ietf-dnsind-tsig-*.txt] arranged with the parent.  Including
-   the "prerequisite" section as specified above enables a parent that
-   keeps no record of its children's KEYs to still authenticate a
-   child's ROLLOVER request based on the old child KEY because the
-   parent is presented with its own SIG on the old KEY.
-
-   If the ROLLOVER command is erroneous or violates parental policy, an
-   Error response is returned.  If a parent retains copies of its
-   children's KEYs, it may use that knowledge to validate ROLLOVER
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 5]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-   request SIGs and ignore the "prerequisites" section.
-
-   If the ROLLOVER command is OK and the parent can sign online, its
-   response MAY include the new parent SIG(s) in the response Update
-   section.  This response MUST be sent to the originator of the
-   request.
-
-   If the parent can not sign online, it should return a response with
-   an empty Update section and queue the SIG(s) calculation request.
-   This response MUST be sent to the originator of the request.
-
-   ROLLOVER response messages MUST always include the actual parent's
-   SOA signed with a key the child should recognize in the Additional
-   Information section (see section 4 below).
-
-   Regardless of whether the server has sent the new signatures above,
-   it MUST, once it has calculated the new SIG(s), send a ROLLOVER to
-   the child zone using the DNS port (53) and the server selection
-   algorithm defined in RFC 2136, Section 4.  This ROLLOVER reqeust
-   contains the KEY RRset that triggered it and the new SIG(s).  There
-   are several reasons for sending the ROLLOVER response regardless of
-   whether the new SIG RR(s) were sent in the original response.  One is
-   to provide an indication to the operators of the zone in the event
-   someone is trying to hijack the zone.  Another is that this maximizes
-   the probability of the response getting through.
-
-   Although the parent zone need not hold or serve the child's key, if
-   it does the ROLLOVER command REQUEST SHOULD NOT automatically update
-   the parent zone.  A later UPDATE command can be used to actually put
-   the new KEY into the parent zone if desired and supported by parent
-   policy.
-
-   This document does not cover the question of parental policy on key
-   rollovers.  Parents may have restrictions on how far into the future
-   they will sign KEY RRsets, what algorithms or key lengths they will
-   support, might require payment for the service, etc.  The signing of
-   a future KEY by a parent is, to some extent, a granting of future
-   authoritative existence to the controller of the child private key
-   even if the child zone ownership should change.  The only effective
-   way of invalidating such future signed child public keys would be for
-   the parent to roll over its key(s), which might be an expensive
-   operation.
-
-
-
-3.2 Rollover to Children
-
-   When a secure zone is going to rollover its key(s), it needs to re-
-   sign the zone keys of any secure children under its new key(s).  The
-   parent simply notifIES the child via a rollover NOTIFY [RFC 1996]
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 6]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-   that the parent KEY(s) have changed.  The child then proceeds to do
-   an upward ROLLOVER request, as described in 3.1 above to obtain the
-   new parental SIG(s).
-
-   A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of
-   SIG and the owner name of the child zone.  The answer section has the
-   current parent SOA signed by a key the child will know (see section
-   4).
-
-   A rollover NOTIFY MUST be signed and if not signed a BADAUTH response
-   generated. The signature MUST be under the previous parental zone
-   KEY, so the child can validate it, or under a valid TSIG key [draft-
-   ietf-dnsind-tsig-*.txt] negotiated between parent and child.
-
-   The rollover NOTIFY can be sent to any of the nameservers for the
-   child using the nameserver selection algorithm defined in RFC 2136,
-   Section 4.  Nameservers for the child zone receiving a rollover
-   NOTIFY query will forward the rollover NOTIFY in the same manner as
-   an UPDATE is forwarded.
-
-   Unless the master server is configured to initiate an automatic
-   ROLLOVER it MUST seek to inform its operators that a rollover NOTIFY
-   request has been received.  This could be done by a number of methods
-   including generating a log message, generating an email request to
-   the child zone's SOA RNAME or any other method defined in the
-   server's configuration for the zone.  The default SHOULD be to send
-   mail to the zone's SOA RNAME.  As with all rollover operations, care
-   should be taken to rate limit these messages so prevent them being
-   used to facilitate a denial of service attack.
-
-   Once the message has been sent (or suppressed if so configured) to
-   the child zone's administrator the master server for the child zone
-   is free to respond to the rollover NOTIFY request.
-
-
-
-4. Secure Zone Cuts and Joinders
-
-   There are two other events that have some similarity to key rollover.
-
-   The first is when a secure zone the is more than one level deep has a
-   zone cut introduced inside it.  For example, assume zone example.com
-   has a.b.c.example.com, d.b.c.example.com and e.example.com in it.  A
-   zone cut could be introduced such that b.c.example.com became a
-   separate child zone of example.com.  A real world exampe would be a
-   company that structures its DNS as host.branch.company.example.  It
-   might start out will all of these names in one zone but later decide
-   to delegate all or some of the branches to branch zone file
-   maintainers.
-
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 7]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-   The second is when a secure zone absorbs a child zone eliminating a
-   zone cut.  This is simply the inverse of the previous paragraph.
-
-   From the point of view of the parent zone above the splitting zone or
-   above the upper of the two combining zones, there is no change.
-
-   When a zone is split by introducing a cut, the newly created child
-   must be properly configured.
-
-   However, from the point of view of a child of the splitting zone
-   which becomes a grandchild or a grandchild that becomes a child due
-   to joinder, there is a change in parent name.  Therefore, in general,
-   there is a change in parent KEY(s).  Unless the entity that handles
-   rollovers for the zone whose parent name has changed is appropriately
-   updated, future automated rollover will fail because it will be sent
-   to the old parent.
-
-   For this reason and so that other consistency checks can be made, the
-   parent SOA and SIG(SOA) are always included in the Answer section of
-   rollover NOTIFY requests and in ROLLOVER responsess.  For automated
-   rollover to the new cut or joined state to work, these SOAs must be
-   signed with old KEY(s) of the former parent so the signatures can be
-   validated by the zone whose parent name is changing.  In the case of
-   a joinder, if the private key of the pinched out middle zone is not
-   available, then manual update of the former grandchild, now child,
-   will be necessary.  In the case of introducing a cut, operational
-   coordination with the former parent, now grandparent, signing the
-   initial updates to the former child, now grandchild, will be needed
-   to automate the reconfiguration of the zones.
-
-
-
-5. Security Considerations
-
-   The security of ROLLOVER or UPDATE requests is essential, otherwise
-   false children could steal parental authorization or a false parent
-   could cause a child to install an invalid signature on its zone key,
-   etc.
-
-   A ROLLOVER request can be authenticated by request SIG(s)under the
-   old zone KEY(s) of the requestor [RFC 2535].  The response SHOULD
-   have transaction SIG(s) under the old zone KEY(s) of the responder.
-   (This public key security could be used to rollover a zone to the
-   unsecured state but at that point it would generally not be possible
-   to roll back without manual intervention.)
-
-   Alternatively, if there is a prior arrangement between a child and a
-   parent, ROLLOVER requests and responses can be secured and
-   authenticated using TSIG [draft-ietf-dnsind-tsig-*.txt].  (TSIG
-   security could be used to rollover a zone to unsecured and to
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 8]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-   rollover an unsecured zone to the secured state.)
-
-   A server that implements online signing SHOULD have the ability to
-   black list a zone and force manual processing or demand that a
-   particular signature be used to generate the ROLLOVER request.  This
-   it to allow ROLLOVER to be used even after a private key has been
-   compromised.
-
-
-
-6. IANA Considerations
-
-   The DNS operation code (TBD) is assigned to ROLLOVER.  There are no
-   other IANA considerations in this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd, M. Andrews                                     [Page 9]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-References
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes
-   (DNS NOTIFY)", P. Vixie, August 1996.
-
-   [RFC 2119] - "Key words for use in RFCs to Indicate Requirement
-   Levels", S.  Bradner. March 1997.
-
-   [RFC 2136] - "Dynamic Updates in the Domain Name System (DNS
-   UPDATE)", P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April
-   1997.
-
-   [draft-ietf-dnsind-tsig-*.txt]
-
-   [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake.
-   March 1999.
-
-   [RFC 2541] - "DNS Security Operational Considerations", D. Eastlake.
-   March 1999.
-
-
-
-Authors Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Sindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Telephone:   +1 914-276-2668 (h)
-                +1 914-784-7913 (w)
-   FAX:         +1 914-784-3833 (w)
-   EMail:       dee3@us.ibm.com
-
-
-   Mark Andrews
-   Internet Software Consortium
-   1 Seymour Street
-   Dundas Valley, NSW 2117
-   AUSTRALIA
-
-   Telephone:   +61-2-9871-4742
-   Email:       marka@isc.org
-
-
-
-D. Eastlake 3rd, M. Andrews                                    [Page 10]
-
-
-
-INTERNET-DRAFT                 April 1999            DNSSEC Key Rollover
-
-
-Expiration and File Name
-
-   This draft expires in October 1999.
-
-   Its file name is draft-ietf-dnsind-rollover-00.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd, M. Andrews                                    [Page 11]
-
-
diff --git a/doc/draft/draft-ietf-dnsind-rollover-01.txt b/doc/draft/draft-ietf-dnsind-rollover-01.txt
new file mode 100644
index 00000000..d09a2ded
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsind-rollover-01.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/doc/draft/draft-ietf-dnsind-sec-rr-00.txt b/doc/draft/draft-ietf-dnsind-sec-rr-00.txt
deleted file mode 100644
index 81ab5155..00000000
--- a/doc/draft/draft-ietf-dnsind-sec-rr-00.txt
+++ /dev/null
@@ -1,663 +0,0 @@
-DNSIND WG                                           Edward Lewis
-INTERNET DRAFT                                      NAI Labs
-Category: I-D                                       Jerry Scharf
-                                                    ISC
-                                                    Olafur Gudmundsson
-                                                    NAI Labs
-                                                    June 25, 1999
-                       The SEC Resource Record
-                   <draft-ietf-dnsind-sec-rr-00.txt>
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other
-groups may also distribute working documents as Internet- Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Comments should be sent to the authors or the DNSIND WG mailing list
-namedroppers@internic.net.
-
-This draft expires on December 25, 1999.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (1999).  All rights reserved.
-
-Abstract
-
-A new DNS reseource record, the SECurity RR, is defined to address
-concerns about the parent zone's holding of the child zone's KEY RR
-set.  These concerns are addressed in a manner that retains the
-information needed by a secure resolver when asking a parent zone
-about the child zone.  This proposal updates RFC 2535 and RFC 2181.
-
-1. Introduction
-
-DNS security extensions require a signed zone to hold KEY RR sets for
-each of its delegations.  This requirement has four negative
-implications for the top level domains, which, for the most part,
-consist of delegation points.  (These issues also impact other
-delegating zones, these problems are not unique to the TLDs.)
-Addressing these concerns by removing the requirement for the KEY RR
-in the parent has an adverse effect on secure resolution of DNS
-
-Expires December 25, 1999                                   [Page  1]
-Internet Draft                                          June 25, 1999
-
-signatures.  A new DNS reseource record, the SECurity RR, is defined
-to address these concerns.
-
-The Zone Key Referral, described in another draft by the same authors,
-is one proposed response to the concerns about parent's holding child
-keys.  However, that proposal has two drawbacks.  One, it results in
-two KEY RR sets at a delegation, one in the parent and one in the
-child, which differ.  It also does not address the expression of
-security parameters, such as whether or not the child zone uses the
-NXT record (which is currently mandatory).
-
-This document will begin by repeating the arguments against the
-holding of keys at the parent as presented in the Zone Key Referral.
-The document will then present the need for information about the
-child to be held in parent.  Following this, the SEC RR will be
-defined, its master file representation discussed, and implications on
-name servers.
-
-(Editorial note.  Sections 1.1 through 1.5 are copied nearly verbatim
-from the Zone Key Referral so that retirement of that draft will not
-cause a problem.)
-
-1.1 Reasons for removing the KEY data from the parent
-
-There are a number of different reasons for the removal of the KEY RR
-from the parent.  Reasons include:
-
-  o the performance impact that holding keys has on name servers
-  o the problem of updating a widely delegated parent zone on demand
-  o statements in RFC 2181 on authoritative data at delegations
-  o perceived liability of the operator of a name server or registry
-
-1.2 Performance Issues
-
-A sample zone will be used to illustrate the problem.  The example
-will part from reality mostly in the length of zone names, which
-changes the size of the owner and resource record data fields.
-
-Expires December 25, 1999                                   [Page  2]
-Internet Draft                                          June 25, 1999
-
-        # $ORIGIN test.
-        # @         IN SOA   <SOA data>
-        #           IN SIG   SOA <by test.>
-        #           IN KEY   <1024 bit zone key>
-        #           IN SIG   KEY <by test.>
-        #           IN SIG   KEY <by .>
-        #           IN NS    ns.test.
-        #           IN SIG   NS <by test.>
-        #           IN NXT   my-org.test. NS SOA SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-        #
-        # my-org    IN KEY   <1024 bit zone key>
-        #           IN KEY   <1024 bit zone key>
-        #           IN SIG   KEY <by test.>
-        #           IN NS    ns1.my-org.test.
-        #           IN NS    ns2.my-org.test.
-        #           IN NXT   that-org.test. NS SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-        #
-        # that-org  IN KEY   0xC100 3 255
-        #           IN SIG   KEY <by test.>
-        #           IN NS    ns1.that-org.test.
-        #           IN NS    ns2.that-org.test.
-        #           IN NXT   test. NS SIG KEY NXT
-        #           IN SIG   NXT <by test.>
-
-In this zone file, "my-org" is a delegation point of interest with two
-registered public keys.  Presumably, one key is for signatures
-generated currently and the other is for still living and valid but
-older signatures.  "that-org" is another delegation point, with a NULL
-key.  This signifies that this zone is unsecured.
-
-To analyze the performance impact of the storing of keys, the number
-of bytes used to represent the RRs in the procotol format is used.
-The actual number of bytes stored will likely be higher, accounting
-for data structure overhead and alignment. The actual number of bytes
-transferred will be lower due to DNS name compression.
-
-The number of bytes for my-org's two 1024-bit keys, two NS records,
-NXT and the associated signatures is 526.  (1024 bit RSA/MD5 keys were
-used for the calculation.)  The bytes needed for that-org (with the
-NULL key) is 346.  Currently, there are close to 2 million entries in
-com., so if we take my-org as a typical domain, over 1GB on memory
-will be needed for com.  The zone keys used in the example are set to
-1024 bits.  This number may range from as low as 512 bits upwards to
-over 3000 bits.
-
-The increased size of the data held for the zone cuts will have two
-impacts at the transport and below layers.  Bandwidth beyond that
-currently needed will be used to carry the KEY records. The inclusion
-of all of the child's keys will also push DNS over the UDP size limit
-and start using TCP - which could cause critical problems for current
-
-Expires December 25, 1999                                   [Page  3]
-Internet Draft                                          June 25, 1999
-
-heavily used name servers, like the root and TLD name servers.  EDNS0
-[RFC-to-be] addresses expansion of UDP message size, which alleviates
-this problem.
-
-Another impact, not illustrated by the example, is the frequency of
-updates.  If each time a public key for my-org is added or deleted,
-the SOA serial number will have to increase, and the SOA signed again.
-If an average zone changes the contents of its key RR set once per
-month, there will be on average 45 updates per minute in a zone of 2
-million delegations.  (This estimate does not address the fact that
-signatures also expire, requiring a new signing of the zone
-periodically.)
-
-1.3 Security Incident Recovery (w/ respect to keys only)
-
-Once a zone administrator is alerted that any key's private
-counterpart has been discovered (exposed), the first action to be
-taken is to stop advertising the public key in DNS.  This doesn't end
-the availability of the key - it will be residing in caches and given
-in answers from those caches - but is the closest action resembling
-revokation available in DNS.
-
-Stopping the advertisement in the zone's name servers is as quick as
-altering the master file and restarting the name server.  Having to do
-this in two places will will only delay the time until the recovery is
-complete.
-
-For example, a registrar of a top level domain has decided to update
-its zone only on Mondays and Fridays due to the size of the zone.  A
-customer/delegatee is the victim of a break in, in which one of the
-items taken is the file of private keys used to sign DNS data. If this
-occurs on a Tuesday, the thief has until Friday to use the keys before
-they disappear from the DNS, even if the child stops publishing them
-immediately.
-
-If the public key set is in the parent zone, and the parent zone is
-not able to make the change quickly, the public key cannot be revoked
-quickly.  If the parent only refers to there being a key at the child
-zone, then the child has the agility to change the keys - even issue a
-NULL key, which will force all signatures in the zone to become
-suspect.
-
-1.4 DNS Clarifications
-
-RFC 2181, section 6, clarifies the status of data appearing at a zone
-cut.  Data at a zone cut is served authoritatively from the servers
-listed in the NS set present at the zone cut.  The data is not
-(necessarily) served authoritatively from the parent. (The exception
-is in servers handling both the parent and child zone.)
-
-Section 6 also mentions that there are two exceptions created by
-DNSSEC, the NXT single record set and the KEY set.  This proposal
-addresses the exception relating to the KEY set, by removing the set
-
-Expires December 25, 1999                                   [Page  4]
-Internet Draft                                          June 25, 1999
-
-from the parent.  The SEC RR is introduced and belongs in the parent
-zone, there is no counterpart in the child (at the apex).
-
-1.5 Liability
-
-Liability is a legal concept, so it is not wise to attempt an
-engineering solution to it.  However, the perceived liability incurred
-in using DNSSEC by registrars may prevent the adoption of DNSSEC.
-Hence DNSSEC should be engineered in such a way to address the
-concern.
-
-One source of liability is the notion that by advertising a public key
-for a child zone, a parent zone is providing a service of security.
-With that comes responsibility.  By having the parent merely indicate
-that a child has a key (or has no key), the parent is providing less
-in the way of security.  If the parent is wrong, the potential loss is
-less.  Instead of falsely authenticated data, configuration errors
-will be apparent to the resolving client.
-
-Whether or not the KEY RR remains advertised in the parent zone or the
-SEC RR is in place, the parent zone administrators still have to
-adhere to proper key handling practices, which are being documented in
-DNSOP draft.  In particular, the parent has to be sure that the keys
-it is signing for a child have been submitted by the true
-administrator of the the child zone, and not submitted by an imposter.
-
-1.6 The needs of the resolver
-
-Now that the reasons for removing the child's keys from the parent
-zone have been presented, reasons why something must take their place
-are presented.  A "secure" resolver is a DNS resolver that receives an
-answer and, if a signature arrives, verifies the signature.  Most
-often, this operation will happen in resolvers that are part of name
-servers, as opposed to general purpose hosts.
-
-The first step in authenticating a DNS response is to see if the data
-is accompanied by a signature.  There are five possible outcomes.
-Three results are not desirable, a signature may arrive but shouldn't,
-no signature arrives but should,  or a signature arrives but uses the
-wrong cryptographic algorthm  Two outcomes can be considered
-successful, a signature arriving with the correct algorithm or no
-signature arrives and shouldn't.  (There is one other case - a
-signature generated with an inappropriate key - which is a matter
-beyond the scope of this draft.)
-
-Since the resolver can not instantly know whether a signature is
-expected, the resolver must start a discovery process.  This process
-can be done by the resolver querying zones between the root and the
-desired domain for information about the next successive zones.
-(Optimizing this search is not presented here.)  For this search to be
-successful, the parent must hold something that indicates the status
-of the child's security, so the resolver may search with certainty.
-While refraining from using the word "policy" to describe the data,
-the phrase "security parameters" is used.
-
-Expires December 25, 1999                                   [Page  5]
-Internet Draft                                          June 25, 1999
-
-The security parameters of a zone are not entirely defined yet, and
-will remain open until a critical mass of operations experience is
-gained.  Initially, the following information is known to be needed.
-
-The set of algorithms in use by the zone.
-KEY RRs and SIG RRs have protocol fields indicating how the key is
-made.  For now, two are in distribution, a value of 1 for RSA/MD5 and
-3 for DSA.  Unfortunately, the value are numeric in 8 bits, so a
-bitmap representation cannot be used.
-
-The mechanism for negative answers.
-Currently, the NXT is mandatory, liked by some administrators and
-disliked by other administrators.  NXTs cannot be made optional, doing
-so makes them obsolete.  (An attacker can make the responses look like
-a zone doesn't use NXTs, even if the zone does.)  If the choice of NXT
-or no NXT can be securely indicated, then this is solved.  There have
-been discussions on alternatives to the NXT record.  By allowing a
-zone to indicate the style of negative answer in use, alternatives can
-be installed in experimental zones.
-
-Signature policy.
-This is an untested issue.  Expressing a policy, such as whether
-multiple algorithms are used, whether verification of one signature
-needed or all signatures, etc., has not been fully studied.
-
-2. The SEC RR
-
-The SEC RR is a record that describes the DNS security parameters of
-the owner.  The owner MUST also have an NS RR set, i.e., the owner
-MUST be a cut point.  A signed zone MUST have a SEC RR set for each
-delegation point.
-
-    0                   1                   2                   3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   Negative Answer Bitmap      |                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
-   |                                                               |
-   ~                     Security Parameters                       ~
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                       The RDATA of the SEC RR
-
-The SEC RR RDATA contains two data fields.  One is a 16-bit field
-acting as a bitmap to indicate the means used to signify a negative
-answer.  The other field is an unbounded field of option-value pairs
-indicating other salient settings for the zone.  The latter field is
-not padded to any particular byte boundary.
-
-The SEC RR is answered authoritatively from the parent zone, and is
-signed by the parent.  A properly configured delegation point in the
-parent would have just an SEC RR, records used for negative answering,
-and a glue NS set.  The corresponding point in the child (the zone's
-apex) would have the SOA, KEY set, NS records, negative answer
-
-Expires December 25, 1999                                   [Page  6]
-Internet Draft                                          June 25, 1999
-
-records, and other desired and legal RR sets.  SIG RR's appear in both
-the parent and child side of the delegation.
-
-There is no other special processing of the SEC RR set.  It is used in
-a reply as an answer when it is the subject of a direct query (QTYPE
-IS SEC) or when a QTYPE=ANY reaches the delegating zone.  If a name
-server is authoritative for both the parent and child, the SEC is
-included in the ANY reply for the delegation point.
-
-(Editorial note: this region is in particular need of careful review.)
-
-The SEC RR for a name SHOULD be supplied optionally in the additional
-data section if the CD bit is not set whenever a zone's NS or KEY set
-is requested.  If a request for a KEY set is sent to a parent-only
-server and the server is not recursive, the server should add the SEC
-record to the additional section of the referral message.
-
-If a name server authoritative for a child zone is asked for its SEC
-RR and the server has never learned the SEC RR (whether through
-caching the record or by also loading the parent zone), the server MAY
-answer with a negative answer.  The resolver seeking a SEC RR SHOULD
-know to ask for this from a parent-serving name server.
-
-2.1 Negative Answer Bitmap
-
-The Negative Answer Bitmap indicates the mechanism for use in denying
-the existance of data.  The bitmap is 16 bits, the most significant
-bit called 0, least significant is 15.
-
-   Bit  0 = The parent doesn't know what the child uses (1=Yes)
-   Bit  1 = The child signs its negative answers (1=Yes)
-   Bit  2 = The child follows traditional DNS rules (1=yes)
-   Bit  3 = The child uses the NXT record (1=yes)
-   Bit 14 = The child uses a locally defined mechanism (1=yes)
-   Bit 15 = The length of the bit field has been extended (1=yes)
-
-Bits 4 through 14 are currently unassigned, and are under the purview
-of IANA.  Bit 15 MUST BE zero.  (This specification must be
-superceeded to define an extension mechanism.)
-
-A zone may use multiple mechanisms to indicate a negative answer.  A
-zone SHOULD expect that a resolver finding any one of the mechanisms
-used in a reply indicates a negative answer, i.e. the mechanisms are
-OR'd together.
-
-The only illegal values for this bit field are:
-   Bit 0 = 1 and any other bit turned on
-   Bit 0 = 0, Bit 1 = 1, and no other bit turned on
-   Bit 15 = 1
-
-2.1.1 Bit 0 (Better titles will be attached later)
-
-The situation in which this bit is on should not arise, but it is
-defined to be safe.  The philosophy behind this is that security
-
-Expires December 25, 1999                                   [Page  7]
-Internet Draft                                          June 25, 1999
-
-parameters should always be made explicit, including when a sitation
-is unclear.
-
-2.1.2 Bit 1
-
-This bit indicates that the child attachs SIG records to the resource
-records used in the negative answer.  For example, this may indicate
-that the reslover should expect to see a SIG (NXT) when an NXT is
-returned.
-
-2.1.3 Bit 2
-
-The child will answer with an SOA or any of the other means used in
-the past to indicate a negative answer.  (I think a reference to the
-negative answer/cache document should go here.)
-
-2.1.4. Bit 3
-
-The child uses the NXT as defined in RFC 2535.  This document declares
-that the use of the NXT is optional, a deviation from RFC 2535.
-
-2.1.5 Bit 14
-
-The child is using a mechanism that is not globally defined.  A zone
-should be in such a state for only experimental reasons and realize
-that in this state, the negative answers it gives may not be useful to
-the general population of resolvers.
-
-2.1.6 Bit 15
-
-As of this specification, this bit must be 0 (zero).
-
-2.1.7 Unallocated bits
-
-The remainder of the bits must also be zero.  A procedure will be
-defined for allocating them.
-
-2.2 Security Parameters
-
-The Security parameters is a sequence of options and values.  An
-option is a numeric indicatior of the parameter.  The value is usually
-either a yes or no, or a enumerated value.  In rare instances, an
-option may require variable length data, in this case a triplet of
-option-length-value is used.  The presence of the length field is
-indicated by the most significant bit in the option field being 1.
-Due to the nature of the SEC RR, the length field is not commonly
-used.
-
-The option field is 8 bits.  The most significant bit of the options
-field is turned on if there is a length field.  The value field is
-also 8 bits.  If the option-length-value is needed, the length is 8
-bits and contains the number of octets comprising the value.  No
-padding is used.
-
-Expires December 25, 1999                                   [Page  8]
-Internet Draft                                          June 25, 1999
-
-An option may appear multiple times in the Security Parameters.  The
-sequencing of the options is not significant.  If two options
-
-contradict each other, this is an error, and is noted by the resolver.
-A self-contradictory SEC RR is a security error and data from the zone
-covered by it SHOULD be considered at risk.
-
-Option Values are
-          0            Reserved
-          1            Zone is unsigned
-          2            Key Algorithm in use
-          3            Signing policy
-      0x70-0x7F      Locally defined (no length field)
-      0xF0-0xFF      Locally defined (uses length field)
-
-All unassigned option values are under the control of IANA.  Values 0
-to 127 do not use the length field, values 128 to 255 do use the
-length field.  The option value is to be treated as unsigned.
-
-2.2.1 Option 0
-
-This option is reserved for future definition.
-
-2.2.2 Option 1
-
-The parent has not signed a KEY RR for the child, therefore the child
-zone has no DNSSEC approved signing keys.  If this option is not
-present, then the resolver SHOULD assume that there are zone keys in
-the child zone.
-
-If the value of this is non-zero, this assertion is true.  If the
-value is zero, this assertion is false.  If the parent has signed keys
-for the child, the value is zero, however, in this case, the parent
-SHOULD NOT include this option in the security parameters.
-
-It is tempting to exclude an unsigned zone option from this list,
-relying on the absence of any in use key algorithms (option 2) to
-imply that the zone is unsigned.  The unsigned option is included to
-make this information explicit, so that when analyzing a running zone,
-it is obvious to an administrator that a zone is unsigned.
-
-2.2.3 Option 2
-
-The parent has signed a key for the child which claims a particular
-algorithm.  This value field is equal to that of the algorithm field
-of the triggering KEY RR.
-
-Option 2 can be repeated for different algorithms.  It is not
-necessary to have multiple Option 2 entries with the same key
-algorithm value.
-
-If Option 1 and Option 2 appear in the same SEC RR, this is a
-self-contradictory record.  If neither Option 1 nor Option 2 appear,
-this also constitues a self-contradictory record.
-
-Expires December 25, 1999                                   [Page  9]
-Internet Draft                                          June 25, 1999
-
-2.2.4 Option 3
-
-The child has the option to require that all material signatures
-(those generated by DNSSEC-approved signing keys) must be validated
-(within any temporal constraints) for the data to be considered valid.
-The child may instead require that just one of the signatures be
-validated.  This may be a reflection of the manner in which a zone's
-administration is shared amongst organizations.
-
-If Option 3 is not present (and Option 2 is), the resolver SHOULD
-assume that ALL (temporally valid) signatures are required.  If the
-parent includes at least one Option 2, it SHOULD specify an Option 3,
-with a value indicated by the child.
-
-Values for Option 3 are
-          0            Reserved
-          1            All signatures are required
-          2            One signature is required
-        256            Locally defined
-
-All remaining values are under the control of IANA.
-
-(Editorial note: whether the assumption that all signatures are
-necessary or just one is sufficient in the absence of this option is
-open to WG debate.)
-
-2.2.5 Options 0x70-0x7F
-
-This option is reserved for an organization to use locally, in an
-experimental fashion.  This option does not use the length field.
-Global interpretation of this option is undefined.
-
-2.2.6 Options 0xF0-0xFF
-
-This option is reserved for an organization to use locally, in an
-experimental fashion.  This option uses the length field. Global
-interpretation of this option is undefined.
-
-3. Master File Representation
-
-The SEC RR fields are to be represented as hexidecimal fields, with a
-preceeding '0x', or in decimal format.  Hexidecimal SHOULD be used.
-
-For example, the SEC RR representing a zone that use signed NXT
-records, and has one or more DSA keys, one or more RSA keys, and
-requires that just one signature be verified would be:
-
-myzone.test.   3500 IN SEC 0x5000 0x0201 0203 0302
-
-(0x020102030302 is one field, hence one 0x prefix.)
-
-Hex values for the security parameters MAY BE separated by
-whitespace, as shown.  DNS data display routines SHOULD substitute
-
-Expires December 25, 1999                                   [Page 10]
-Internet Draft                                          June 25, 1999
-
-mnemonics for these values, but MUST write the numeric form in master
-files.
-
-4. Signature Policy
-
-The SEC RR must be signed by one or more zone keys of the parent
-(delgating) zone, and the signatures must adhere to the parent's
-policy.
-
-The SEC RR for the root zone is the lone exception, it appears at the
-apex of the root zone, and must be signed sufficiently by the root's
-zone key or keys.
-
-5. Cache Considerations
-
-When a SEC RR set for a name is held in a cache, it will have a
-credibility rating indicating that the data came from the parent
-(unless the parent and child share servers).  When data about the same
-name arrives from the child, with a higher credibility, the newly
-arrived data MUST NOT cause the cache to remove the SEC RR.
-
-6. IANA Considerations
-
-IANA is requested to assign this RR an type parameter for DNS, and to
-assign the indicated option numbers and values when requests are
-approved.  The procedure for requesting new options and values will be
-defined in future versions of this specfication.
-
-7. Security Considerations
-
-This record is designed to address the concerns of securing delegation
-points and resolving the security of DNS answers.  This record is
-important to the security because it supplies needed information and
-eases the burden of security on the DNS.
-
-The SEC RR does require one piece of additional information not
-addressed to date to be communicated from the parent to the child.
-This is the signature policy.  This will be needed in the operations
-documents.
-
-Editorial Note: This document would benefit by a companion document
-describing the process of evaluating the signatures in DNS.  Such a
-document would provide clearer input to the security parameters field.
-
-8. Editorial Considerations
-
-Although somewhat detailed in this current description, this record is
-still in the formative state.  The -00 document has been quickly
-written to test the waters for interest.
-
-9. References
-
-RFC 2535 is the prime DNSSEC definition.  RFC 2181 is the Clarify
-document.  EDNS0 reference needed...
-
-Expires December 25, 1999                                   [Page 11]
-Internet Draft                                          June 25, 1999
-
-10. Acknowledgements
-
-This record is a successor to the Zone Key Referral, originally
-promoted by John Gilmore and Jerry Scharf.  A DNSSEC workshop
-sponsored by the NIC-SE in May 1999 provided the enlightenment that
-expanded the Zone Key Referral into the SEC RR proposal.
-
-11. Author's Addresses
-
-Edward Lewis                Jerry Scharf           Olafur Gudmundsson
-NAI Labs             Internet Software Consortium            NAI Labs
-3060 Washington Road        950 Charter St         3060 Washington Rd
-Glenwood, MD 21738      Redwood City, CA 94063     Glenwood, MD 21738
-+1 443 259 2352            +1 650 779 7060            +1 443 259 2389
-<lewis@tislabs.com>        <scharf@vix.com>        <ogud@tislabs.com>
-
-12. Full Copyright Statement
-
-Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it
-or assist in its implmentation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are
-included on all such copies and derivative works.  However, this
-document itself may not be modified in any way, such as by removing
-the copyright notice or references to the Internet Society or other
-Internet organizations, except as needed for the purpose of
-developing Internet standards in which case the procedures for
-copyrights defined in the Internet Standards process must be
-followed, or as required to translate it into languages other than
-English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-Expires December 25, 1999                                   [Page 12]
diff --git a/doc/draft/draft-ietf-dnsind-sec-rr-01.txt b/doc/draft/draft-ietf-dnsind-sec-rr-01.txt
new file mode 100644
index 00000000..d09a2ded
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsind-sec-rr-01.txt
@@ -0,0 +1,5 @@
+This Internet-Draft has expired and is no longer available.
+
+Unrevised documents placed in the Internet-Drafts directories have a
+maximum life of six months. After that time, they must be updated, or
+they will be deleted. This document was deleted on March 20, 2000.
diff --git a/doc/misc/dnssec b/doc/misc/dnssec
new file mode 100644
index 00000000..949c44d8
--- /dev/null
+++ b/doc/misc/dnssec
@@ -0,0 +1,72 @@
+
+
+
+DNSSEC Release Notes
+
+
+
+This document summarizes the state of the DNSSEC implementation in
+this release of BIND9.
+
+
+Key generation and signing
+
+The tools for generating DNSSEC keys and signatures are now in the
+bin/dnssec directory.  Documentation for these programs can be found
+in doc/arm/Bv9ARM.4.html.
+
+The random data used in generating DNSSEC keys and signatures
+currently contains a significant pseudo-random component and is
+therefore not cryptographically strong.  We do not recommend that keys
+generated by the key generation tools in this distribution be used in
+production.
+
+
+Serving secure zones
+
+When acting as an authoritative name server, BIND9 includes KEY, SIG
+and NXT records in responses as specified in RFC2535.
+
+Response generation for wildcard records in secure zones is not fully
+supported.  Responses indicating the nonexistence of a name include a
+NXT record proving the nonexistence of the name itself, but do not
+include any NXT records to prove the nonexistence of a matching
+wildcard record.  Positive responses resulting from wildcard expansion
+do not include the NXT records to prove the nonexistence of a
+non-wildcard match or a more specific wildcard match.
+
+
+Secure resolution
+
+Basic support for validation of DNSSEC signatures in responses has
+been implemented but should still be considered experimental.
+
+When acting as a caching name server, BIND9 is capable of performing
+basic DNSSEC validation of positive as well as nonexistence responses.
+This functionality is enabled by including a "trusted-keys" clause
+in the configuration file, containing the top-level zone key of the
+the DNSSEC tree.
+
+Validation of wildcard responses is not currently supported.  In
+particular, a "name does not exist" response will validate
+successfully even if it does not contain the NXT records to prove the
+nonexistence of a matching wildcard.
+
+Proof of insecure status for insecure zones delegated from secure
+zones has been partially implemented but should not yet be expected to
+work in all cases.
+
+Handling of the CD bit in queries is not yet fully implemented;
+validation is currently attempted for all recursive queries, even if
+CD is set.
+
+
+Secure dynamic update
+
+Dynamic update of secure zones has been implemented, but may not be
+complete.  Affected NXT and SIG records are updated by the server when
+an update occurs.  Advanced access control is possible using the
+"update-policy" statement in the zone definition.
+
+
+$Id: dnssec,v 1.2 2000/05/23 16:41:25 gson Exp $
diff --git a/doc/misc/ipv6 b/doc/misc/ipv6
new file mode 100644
index 00000000..eb5d541e
--- /dev/null
+++ b/doc/misc/ipv6
@@ -0,0 +1,98 @@
+
+Currently, there are multiple interesting problems with ipv6
+implementations on various platforms.  These problems range from not
+being able to use ipv6 with bind9 (or in particular the ISC socket
+library, contained in libisc) to listen-on lists not being respected,
+to strange warnings but seemingly correct behavior of named.
+
+
+COMPILE-TIME ISSUES
+-------------------
+
+The socket library requires a certain level of support from the
+operating system.  In particular, it must follow the advanced ipv6
+socket API to be usable.  The systems which do not follow this will
+currently not get any warnings or errors, but ipv6 will simply not
+function on them.
+
+These systems currently include, but are not limited to:
+
+	AIX 3.4 (with ipv6 patches)
+
+
+RUN-TIME ISSUES
+---------------
+
+In the original drafts of the ipv6 RFC documents, binding an ipv6
+socket to the ipv6 wildcard address would also cause the socket to
+accept ipv4 connections and datagrams.  When an ipv4 packet is
+received on these systems, it is mapped into an ipv6 address.  For
+example, 1.2.3.4 would be mapped into ffff::1.2.3.4.  The intent of
+this mapping was to make transition from an ipv4-only application into
+ipv6 easier, by only requiring one socket to be open on a given port.
+
+Later, it was discovered that this was generally a bad idea.  For one,
+many firewalls will block connection to 1.2.3.4, but will let through
+ffff::1.2.3.4.  This, of course, is bad.  Also, access control lists
+written to accept only ipv4 addresses were suddenly ignored unless
+they were rewritten to handle the ipv6 mapped addresses as well.
+
+In bind9, we always bind to the ipv6 wildcard port for both TCP and
+UDP, and specific addresses for ipv4 sockets.  This causes some
+interesting behavior depending on the system implementation of ipv6.
+
+
+IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail
+---------------------------------------------------------------
+
+The only OS which seems to do this is linux.  If an ipv6 socket is
+bound to the ipv6 wildcard socket, and a specific ipv4 socket is
+later bound (say, to 1.2.3.4 port 53) the ipv4 binding will fail.
+
+What this means to bind9 is that the application will log warnings
+about being unable to bind to a socket because the address is already
+in use.  Since the ipv6 socket will accept ipv4 packets and map them,
+however, the ipv4 addresses continue to function.
+
+The effect is that the config file listen-on directive will not be
+respected on these systems.
+
+
+IPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed
+----------------------------------------------------------------
+
+In this case, the system allows opening an ipv6 wildcard address
+socket and then binding to a more specific ipv4 address later.  An
+example of this type of system is Digital Unix with ipv6 patches
+applied.
+
+What this means to bind9 is that the application will respect
+listen-on in regards to ipv4 sockets, but it will use mapped ipv6
+addresses for any that do not match the listen-on list.  This, in
+effect, makes listen-on useless for these machines as well.
+
+
+IPV6 Sockets Do Not Accept IPV4
+-------------------------------
+
+On these systems, opening an IPV6 socket does not implicitly open any
+ipv4 sockets.  An example of these systems are NetBSD-current with the
+latest KAME patch, and other systems which use the latest KAME patches
+as their ipv6 implementation.
+
+On these systems, listen-on is fully functional, as the ipv6 socket
+only accepts ipv6 packets, and the ipv4 sockets will handle the ipv4
+packets.
+
+
+RELEVANT RFCs
+-------------
+
+2373:  IP Version 6 Addressing Architecture
+
+2553:  Basic Socket Interface Extensions for IPv6
+
+draft-ietf-ipngwg-rfc2292bis-01:  Advanced Sockets API for IPv6 (draft)
+
+
+$Id: ipv6,v 1.2 2000/05/23 22:42:00 gson Exp $
diff --git a/doc/misc/options b/doc/misc/options
index bd6e8c12..f27d06a9 100644
--- a/doc/misc/options
+++ b/doc/misc/options
@@ -5,28 +5,28 @@ options in BIND 9.
 
 Legend:
 
-  Yes       Implemented in this release.
+  Yes	    Implemented in this release.
 
-  No        Not implemented, may be implemented in a later release.
+  No	    Not implemented, may be implemented in a later release.
 
   Obsolete  Obsolete, not applicable to BIND 9, or just evil.  
-            Will not be implemented.
+	    Will not be implemented.
 
-  *         New in BIND 9.
+  *	    New in BIND 9.
 
-  + 	    The option is now always enabled.
+  +	    The option is now always enabled.
 
-  -         The option is now always disabled.
+  -	    The option is now always disabled.
 
-  %         The default value has changed since BIND 8.
+  %	    The default value has changed since BIND 8.
 
   @	    Semantics of certain pathological address match lists, in
 	    particular those involving double negation, have changed.  
 	    The new semantics are generally safer.  IPv6 addresses
-            are supported, but the predefined ACLs "localhost" and 
-            "localnets" match IPv4 addresses only.
+	    are supported, but the predefined ACLs "localhost" and 
+	    "localnets" match IPv4 addresses only.
 
-  #         BIND 9 accepts both LF and CRLF as end-of-line markers.
+  #	    BIND 9 accepts both LF and CRLF as end-of-line markers.
 
 
 options {
@@ -45,27 +45,28 @@ options {
   [ has-old-clients yes_or_no; ]			    Obsolete
   [ host-statistics yes_or_no; ]			    No
   [ multiple-cnames yes_or_no; ]			    Obsolete-
-  [ notify yes_or_no; ]					    No
+  [ notify yes_or_no; ]					    Yes
   [ recursion yes_or_no; ]				    Yes
   [ rfc2308-type1 yes_or_no; ]				    No
   [ use-id-pool yes_or_no; ]				    Obsolete+
   [ treat-cr-as-space yes_or_no; ]			    Obsolete#
-  [ also-notify { ip_addr; [ ip_addr; ... ] };		    No
+  [ also-notify { ip_addr; [ ip_addr; ... ] }; ]	    Yes
   [ forward ( only | first ); ]				    Yes
   [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ]	    Yes
-  [ check-names ... ]				            No
+  [ check-names ... ]					    No
   [ allow-query { address_match_list }; ]		    Yes@
   [ allow-transfer { address_match_list }; ]		    Yes@
   [ allow-recursion { address_match_list }; ]		    Yes@
   [ blackhole { address_match_list }; ]			    No
   [ listen-on [ port ip_port ] { address_match_list }; ]    Yes@ (IPv4 only)
-  [ query-source .... ]                                     Yes
-  [ query-source-v6 .... ]                                  Yes*
+  [ query-source ... ]					    Yes
+  [ query-source-v6 ... ]				    Yes*
   [ lame-ttl number; ]					    No
   [ max-transfer-time-in number; ]			    Yes
   [ max-transfer-idle-in number; ]			    Yes*
   [ max-transfer-time-out number; ]			    Yes*
   [ max-transfer-idle-out number; ]			    Yes*
+  [ max-cache-ttl number; ]				    No*
   [ max-ncache-ttl number; ]				    No
   [ min-roots number; ]					    No
   [ serial-queries number; ]				    No
@@ -89,20 +90,22 @@ options {
   [ statistics-interval number; ]			    No
   [ topology { address_match_list }; ]			    No
   [ sortlist { address_match_list }; ]			    No
-  [ rrset-order { order_spec ; [ order_spec ; ... ] ] };    No
+  [ rrset-order { order_spec ; [ order_spec ; ... ] }; ]    No
   [ recursive-clients number; ]				    Yes*
   [ tcp-clients number; ]				    Yes*
+  [ tkey-domain ... ]					    Yes*
+  [ tkey-dhkey ... ]					    Yes*
 };
 
-acl 						            Yes@
+acl							    Yes@
 
-include                                                     Yes
+include							    Yes
 
 key							    Yes
 
-logging						            Yes
+logging							    Yes
 
-controls                                                    No
+controls						    No
 
 server ip_addr {
   [ bogus yes_or_no; ]					    No
@@ -111,13 +114,13 @@ server ip_addr {
   [ support-ixfr yes_or_no; ]				    Obsolete
   [ transfers number; ]					    Yes
   [ transfer-format ( one-answer | many-answers ); ]	    Yes
-  [ keys { key_id [key_id ... ] }; ]                        Yes
+  [ keys { key_id [key_id ... ] }; ]			    Yes
 };
 
-trusted-keys                                                No
+trusted-keys						    Yes
 
-zone domain_name [ ( in | hs | hesiod | chaos ) ] { 
-  type master;					            Yes
+zone "domain_name" [ ( in | hs | hesiod | chaos ) ] { 
+  type master;						    Yes
   file path_name;					    Yes
   [ forward ( only | first ); ]				    No
   [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]	    No
@@ -128,17 +131,17 @@ zone domain_name [ ( in | hs | hesiod | chaos ) ] {
   [ dialup yes_or_no; ]					    No
   [ max-transfer-time-out number; ]			    Yes*
   [ max-transfer-idle-out number; ]			    Yes*
-  [ notify yes_or_no; ]					    No
-  [ also-notify { ip_addr; [ ip_addr; ... ] };		    No
+  [ notify yes_or_no; ]					    Yes
+  [ also-notify { ip_addr; [ ip_addr; ... ] };		    Yes
   [ ixfr-base  path_name; ]				    Obsolete
   [ pubkey number number number string; ]		    No
 };
 
-zone domain_name [ ( in | hs | hesiod | chaos ) ] { 	    
+zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {	    
   type stub;						    No
 };
 
-zone domain_name [ ( in | hs | hesiod | chaos ) ] { 	    
+zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {	    
   type slave;						    Yes
   [ file path_name; ]					    Yes
   [ ixfr-base  path_name; ]				    Obsolete
@@ -157,17 +160,53 @@ zone domain_name [ ( in | hs | hesiod | chaos ) ] {
   [ max-transfer-idle-in number; ]			    Yes*
   [ max-transfer-time-out number; ]			    Yes*
   [ max-transfer-idle-out number; ]			    Yes*
-  [ notify yes_or_no; ]					    No
-  [ also-notify { ip_addr; [ ip_addr; ... ] };		    No
+  [ notify yes_or_no; ]					    Yes
+  [ also-notify { ip_addr; [ ip_addr; ... ] };		    Yes
   [ pubkey number number number string; ]		    No
 };
 
-zone domain_name [ ( in | hs | hesiod | chaos ) ] { 	    
+zone "domain_name" [ ( in | hs | hesiod | chaos ) ] {	    
   type forward;						    No
 };
 
-zone "." [ ( in | hs | hesiod | chaos ) ] { 		    
+zone "." [ ( in | hs | hesiod | chaos ) ] {		    
   type hint;						    Yes
   file path_name;					    Yes
   [ check-names ( warn | fail | ignore ); ]		    No
 };
+
+view "view_name" [ ( in | hs | hesiod | chaos ) ] {	    Yes*
+  match-clients { address_match_list };			    Yes*
+  [ zone ... ]						    Yes
+  [ auth-nxdomain yes_or_no; ]				    Yes
+  [ fetch-glue yes_or_no; ]				    No
+  [ notify yes_or_no; ]					    Yes
+  [ recursion yes_or_no; ]				    Yes
+  [ rfc2308-type1 yes_or_no; ]				    No
+  [ also-notify { ip_addr; [ ip_addr; ... ] }; ]	    No
+  [ forward ( only | first ); ]				    Yes
+  [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ]	    Yes
+  [ check-names ... ]					    No
+  [ allow-query { address_match_list }; ]		    Yes
+  [ allow-transfer { address_match_list }; ]		    Yes
+  [ allow-recursion { address_match_list }; ]		    Yes
+  [ query-source ... ]					    Yes
+  [ query-source-v6 ... ]				    Yes
+  [ lame-ttl number; ]					    No
+  [ max-transfer-time-out number; ]			    Yes*
+  [ max-transfer-idle-out number; ]			    Yes*
+  [ max-ncache-ttl number; ]				    No
+  [ min-roots number; ]					    No
+  [ transfer-format ( one-answer | many-answers ); ]	    Yes
+  [ transfer-source ip_addr; ]				    Yes
+  [ transfer-source-v6 ip_addr; ]			    Yes*
+  [ request-ixfr yes_or_no; ]				    Yes*
+  [ provide-ixfr yes_or_no;]				    Yes*
+  [ cleaning-interval number; ]				    Yes
+  [ topology { address_match_list }; ]			    No
+  [ sortlist{ address_match_list }; ]			    No
+  [ rrset-order { order_spec ; [ order_spec ; ... ] }; ]    No
+  [ key ... ]						    No
+  [ server ... ]					    No
+  [ trusted-keys ... ]					    No
+};
diff --git a/doc/rfc/rfc952.txt b/doc/rfc/rfc952.txt
new file mode 100644
index 00000000..7df339a2
--- /dev/null
+++ b/doc/rfc/rfc952.txt
@@ -0,0 +1,340 @@
+Network Working Group                               K. Harrenstien (SRI)
+Request for Comments: 952                                 M. Stahl (SRI)
+                                                        E. Feinler (SRI)
+Obsoletes:  RFC 810, 608                                    October 1985
+
+                 DOD INTERNET HOST TABLE SPECIFICATION
+
+
+STATUS OF THIS MEMO
+
+   This RFC is the official specification of the format of the Internet
+   Host Table.  This edition of the specification includes minor
+   revisions to RFC-810 which brings it up to date. Distribution of this
+   memo is unlimited.
+
+INTRODUCTION
+
+   The DoD Host Table is utilized by the DoD Hostname Server maintained
+   by the DDN Network Information Center (NIC) on behalf of the Defense
+   Communications Agency (DCA) [See RFC-953].
+
+LOCATION OF THE STANDARD DOD ONLINE HOST TABLE
+
+   A machine-translatable ASCII text version of the DoD Host Table is
+   online in the file NETINFO:HOSTS.TXT on the SRI-NIC host.  It can be
+   obtained via FTP from your local host by connecting to host
+   SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user =
+   ANONYMOUS, password = GUEST, and retrieving the file
+   "NETINFO:HOSTS.TXT".  The same table may also be obtained via the NIC
+   Hostname Server, as described in RFC-953.  The latter method is
+   faster and easier, but requires a user program to make the necessary
+   connection to the Name Server.
+
+ASSUMPTIONS
+
+   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
+   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
+   sign (-), and period (.).  Note that periods are only allowed when
+   they serve to delimit components of "domain style names". (See
+   RFC-921, "Domain Name System Implementation Schedule", for
+   background).  No blank or space characters are permitted as part of a
+   name. No distinction is made between upper and lower case.  The first
+   character must be an alpha character.  The last character must not be
+   a minus sign or period.  A host which serves as a GATEWAY should have
+   "-GATEWAY" or "-GW" as part of its name.  Hosts which do not serve as
+   Internet gateways should not use "-GATEWAY" and "-GW" as part of
+   their names. A host which is a TAC should have "-TAC" as the last
+   part of its host name, if it is a DoD host.  Single character names
+   or nicknames are not allowed.
+
+   2. Internet Addresses are 32-bit addresses [See RFC-796].  In the
+
+
+Harrenstien & Stahl & Feinler                                   [Page 1]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   host table described herein each address is represented by four
+   decimal numbers separated by a period.  Each decimal number
+   represents 1 octet.
+
+   3. If the first bit of the first octet of the address is 0 (zero),
+   then the next 7 bits of the first octet indicate the network number
+   (Class A Address).  If the first two bits are 1,0 (one,zero), then
+   the next 14 bits define the net number (Class B Address).  If the
+   first 3 bits are 1,1,0 (one,one,zero), then the next 21 bits define
+   the net number (Class C Address) [See RFC-943].
+
+      This is depicted in the following diagram:
+
+      +-+------------+--------------+--------------+--------------+
+      |0|  NET <-7-> |         LOCAL ADDRESS <-24->               |
+      +-+------------+--------------+--------------+--------------+
+
+      +---+----------+--------------+--------------+--------------+
+      |1 0|      NET  <-14->        |  LOCAL ADDRESS <-16->       |
+      +---+----------+--------------+--------------+--------------+
+
+      +-----+--------+--------------+--------------+--------------+
+      |1 1 0|            NET  <-21->               | LOCAL ADDRESS|
+      +-----+--------+--------------+--------------+--------------+
+
+   4. The LOCAL ADDRESS portion of the internet address identifies a
+   host within the network specified by the NET portion of the address.
+
+   5. The ARPANET and MILNET are both Class A networks.  The NET portion
+   is 10 decimal for ARPANET, 26 decimal for MILNET, and the LOCAL
+   ADDRESS maps as follows: the second octet identifies the physical
+   host, the third octet identifies the logical host, and the fourth
+   identifies the Packet Switching Node (PSN), formerly known as an
+   Interface Message Processor (IMP).
+
+      +-+------------+--------------+--------------+--------------+
+      |0|  10 or 26  |    HOST      | LOGICAL HOST |   PSN (IMP)  |
+      +-+------------+--------------+--------------+--------------+
+
+      (NOTE:  RFC-796 also describes the local address mappings for
+      several other networks.)
+
+   6. It is the responsibility of the users of this host table to
+   translate it into whatever format is needed for their purposes.
+
+   7. Names and addresses for DoD hosts and gateways will be negotiated
+   and registered with the DDN PMO, and subsequently with the NIC,
+
+
+Harrenstien & Stahl & Feinler                                   [Page 2]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   before being used and before traffic is passed by a DoD host.  Names
+   and addresses for domains and networks are to be registered with the
+   DDN Network Information Center (HOSTMASTER@SRI-NIC.ARPA) or
+   800-235-3155.
+
+   The NIC will attempt to keep similar information for non-DoD networks
+   and hosts, if this information is provided, and as long as it is
+   needed, i.e., until intercommunicating network name servers are in
+   place.
+
+EXAMPLE OF HOST TABLE FORMAT
+
+   NET : 10.0.0.0 : ARPANET :
+   NET : 128.10.0.0 : PURDUE-CS-NET :
+   GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW.ARPA,MIT-GATEWAY : PDP-11 :
+             MOS : IP/GW,EGP :
+   HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 :
+          TOPS20 :TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
+   HOST : 10.2.0.11 : SU-TAC.ARPA,SU-TAC : C/30 : TAC : TCP :
+
+SYNTAX AND CONVENTIONS
+
+   ; (semicolon)   is used to denote the beginning of a comment.
+                   Any text on a given line following a ';' is a
+                   comment, and not part of the host table.
+
+   NET             keyword introducing a network entry
+
+   GATEWAY         keyword introducing a gateway entry
+
+   HOST            keyword introducing a host entry
+
+   DOMAIN          keyword introducing a domain entry
+
+   :(colon)        is used as a field delimiter
+
+   ::(2 colons)    indicates a null field
+
+   ,(comma)        is used as a data element delimiter
+
+   XXX/YYY         indicates protocol information of the type
+                   TRANSPORT/SERVICE.
+
+      where TRANSPORT/SERVICE options are specified as
+
+         "FOO/BAR"       both transport and service known
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 3]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+         "FOO"           transport known; services not known
+
+         "BAR"           service is known, transport not known
+
+         NOTE:  See "Assigned Numbers" for specific options and acronyms
+         for machine types, operating systems, and protocol/services.
+
+   Each host table entry is an ASCII text string comprised of 6 fields,
+   where
+
+      Field 1         KEYWORD indicating whether this entry pertains to
+                      a NET, GATEWAY, HOST, or DOMAIN.  NET entries are
+                      assigned and cannot have alternate addresses or
+                      nicknames.  DOMAIN entries do not use fields 4, 5,
+                      or 6.
+
+      Field 2         Internet Address of Network, Gateway, or Host
+                      followed by alternate addresses.  Addresses for a
+                      Domain are those where a Domain Name Server exists
+                      for that domain.
+
+      Field 3         Official Name of Network, Gateway, Host, or Domain
+                      (with optional nicknames, where permitted).
+
+      Field 4         Machine Type
+
+      Field 5         Operating System
+
+      Field 6         Protocol List
+
+   Fields 4, 5 and 6 are optional.  For a Domain they are not used.
+
+   Fields 3-6, if included, pertain to the first address in Field 2.
+
+   'Blanks' (spaces and tabs) are ignored between data elements or
+   fields, but are disallowed within a data element.
+
+   Each entry ends with a colon.
+
+   The entries in the table are grouped by types in the order Domain,
+   Net, Gateway, and Host.  Within each type the ordering is
+   unspecified.
+
+   Note that although optional nicknames are allowed for hosts, they are
+   discouraged, except in the case where host names have been changed
+
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 4]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   and both the new and the old names are maintained for a suitable
+   period of time to effect a smooth transition.  Nicknames are not
+   permitted for NET names.
+
+GRAMMATICAL HOST TABLE SPECIFICATION
+
+   A. Parsing grammar
+
+      <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
+         [":" [<opsys>]  [":" [<protocol list>] ]]] ":"
+      <addresses> ::= <address> *["," <address>]
+      <address> ::= <octet> "." <octet> "." <octet> "." <octet>
+      <octet> ::= <0 to 255 decimal>
+      <names> ::= <netname> | <gatename> | <domainname> *[","
+         <nicknames>]
+         | <official hostname> *["," <nicknames>]
+      <netname>  ::= <name>
+      <gatename> ::= <hname>
+      <domainname> ::= <hname>
+      <official hostname> ::= <hname>
+      <nickname> ::= <hname>
+      <protocol list> ::= <protocol spec> *["," <protocol spec>]
+      <protocol spec> ::= <transport name> "/" <service name>
+         | <raw protocol name>
+
+   B. Lexical grammar
+
+      <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
+      <entry-text>  ::= <print-char> *<text>
+      <blank> ::= <space-or-tab> [<blank>]
+      <keyword> ::= NET | GATEWAY | HOST | DOMAIN
+      <hname> ::= <name>*["."<name>]
+      <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
+      <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
+      <opsys>   ::= ITS | MULTICS | TOPS20 | UNIX...etc.
+      <transport name> ::= TCP | NCP | UDP | IP...etc.
+      <service name> ::= TELNET | FTP | SMTP | MTP...etc.
+      <raw protocol name> ::= <name>
+      <comment> ::= ";" <text><cr><lf>
+      <text>    ::= *[<print-char> | <blank>]
+      <print-char>  ::= <any printing char (not space or tab)>
+
+   Notes:
+
+      1. Zero or more 'blanks' between separators " , : " are allowed.
+      'Blanks' are spaces and tabs.
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 5]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+      2. Continuation lines are lines that begin with at least one
+      blank.  They may be used anywhere 'blanks' are legal to split an
+      entry across lines.
+
+BIBLIOGRAPHY
+
+   1. Feinler, E., Harrenstien, K., Su, Z. and White, V., "Official DoD
+      Internet Host Table Specification", RFC-810, Network Information
+      Center, SRI International, March 1982.
+
+   2. Harrenstien, K., Stahl, M., and Feinler, E., "Hostname Server",
+      RFC-953, Network Information Center, SRI International, October
+      1985.
+
+   3. Kudlick, M. "Host Names Online", RFC-608, Network Information
+      Center, SRI International, January 1973.
+
+   4. Postel, J., "Internet Protocol", RFC-791, Information Sciences
+      Institute, University of Southern California, Marina del Rey,
+      September 1981.
+
+   5. Postel, J., "Address Mappings", RFC-796, Information Sciences
+      Institute, University of Southern California, Marina del Rey,
+      September 1981.
+
+   6. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
+      Information Sciences Institute, University of Southern California,
+      Marina del Rey, October 1984.
+
+   7. Reynolds, J. and Postel, J., "Assigned Numbers", RFC-943,
+      Information Sciences Institute, University of Southern California,
+      Marina del Rey, April 1985.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 6]
+
author	Internet Software Consortium, Inc <@isc.org>	2007-09-07 14:08:19 -0600
committer	LaMont Jones <lamont@debian.org>	2007-09-07 14:08:19 -0600
commit	93744e253a50cdd78097dc5a150f4c035e8cbcc9 (patch)
tree	f7470097a04345f967281dd4d658dd065c51d166 /doc
parent	6257efc35455318993208bef65a551ac6039f51f (diff)
download	bind9-93744e253a50cdd78097dc5a150f4c035e8cbcc9.tar.gz