275 files changed, 19577 insertions, 62226 deletions

diff --git a/contrib/bind9/CHANGES b/contrib/bind9/CHANGES
index 1673ae0c476c..941b946db36a 100644
--- a/contrib/bind9/CHANGES
+++ b/contrib/bind9/CHANGES
@@ -1,4 +1,261 @@
 
+	--- 9.3.2 released ---
+
+	--- 9.3.2rc1 released ---
+
+1936.	[bug]		The validator could leak memory. [RT #15544]
+
+1932.	[bug]		hpux: LDFLAGS was getting corrupted. [RT #15530]
+
+	--- 9.3.2b2 released ---
+
+1930.	[port]		HPUX: ia64 support. [RT #15473]
+
+1929.	[port]		FreeBSD: extend use of PTHREAD_SCOPE_SYSTEM.
+
+1926.	[bug]		The Windows installer did not check for empty
+			passwords.  BINDinstall was being installed in
+			the wrong place. [RT #15483]
+
+1925.	[port]		All outer level AC_TRY_RUNs need cross compiling
+			defaults. [RT #15469]
+
+1924.	[port]		libbind: hpux ia64 support. [RT #15473]
+
+1923.	[bug]		ns_client_detach() called too early. [RT #15499]
+
+	--- 9.3.2b1 released ---
+
+1917.	[doc]		funcsynopsisinfo wasn't being treated as verbatim
+			when generating man pages. [RT #15385]
+
+1915.	[bug]		dig +ndots was broken. [RT #15215]
+
+1914.	[protocol]	DS is required to accept mnemonic algorithms
+			(RFC 4034).  Still emit numeric algorithms for
+			compatability with RFC 3658. [RT #15354]
+
+1911.	[bug]		Update windows socket code. [RT #14965]
+
+1910.	[bug]		dig's +sigchase code overhauled. [RT #14933]
+
+1909.	[bug]		The DLV code has been re-worked to make no longer
+			query order sensitive. [RT #14933]
+
+1905.	[bug]		Strings returned from cfg_obj_asstring() should be
+                        treated as read-only.  [RT #15256]
+
+1901.	[cleanup]	Don't add DNSKEY records to the additional section.
+
+1900.	[bug]		ixfr-from-differences failed to ensure that the
+			serial number increased. [RT #15036]
+
+1896.	[bug]		Extend ISC_SOCKADDR_FORMATSIZE and
+			ISC_NETADDR_FORMATSIZE to allow for scope details.
+
+1894.	[bug]		Recursive clients soft quota support wasn't working
+			as expected. [RT #15103]
+
+1893.	[bug]		A escaped character is, potentially, converted to
+			the output character set too early. [RT #14666]
+
+1892.	[port]		Use uintptr_t if available. [RT #14606]
+
+1889.	[port]		sunos: non blocking i/o support. [RT #14951]
+
+1887.	[bug]		The cache could delete expired records too fast for
+			clients with a virtual time in the past. [RT #14991]
+
+1886.	[bug]		fctx_create() could return success even though it
+			failed. [RT #14993]
+
+1884.	[cleanup]	dighost.c: move external declarations into <dig/dig.h>.
+
+1883.	[bug]		dnssec-signzone, dnssec-keygen: handle negative debug
+			levels. [RT #14962]
+
+1881.	[func]		Add a system test for named-checkconf. [RT #14931]
+
+1877.	[bug]		Fix unreasonably low quantum on call to
+			dns_rbt_destroy2().  Remove unnecessay unhash_node()
+			call. [RT #14919]
+
+1875.	[bug]		process_dhtkey() was using the wrong memory context
+			to free some memory. [RT #14890]
+
+1874.	[port]		sunos: portability fixes. [RT #14814]
+
+1873.	[port]		win32: isc__errno2result() now reports its caller.
+			[RT #13753]
+
+1872.	[port]		win32: Handle ERROR_NETNAME_DELETED.  [RT #13753]
+
+1867.	[bug]		It was possible to trigger a INSIST in
+			dlv_validatezonekey(). [RT #14846]
+
+1866.	[bug]		resolv.conf parse errors were being ignored by
+			dig/host/nslookup. [RT #14841]
+
+1865.	[bug]		Silently ignore nameservers in /etc/resolv.conf with
+			bad addresses. [RT #14841]
+
+1864.	[bug]		Don't try the alternative transfer source if you
+			got a answer / transfer with the main source
+			address. [RT #14802]
+
+1863.	[bug]		rrset-order "fixed" error messages not complete.
+
+1861.	[bug]		dig could trigger a INSIST on certain malformed
+			responses. [RT #14801]
+
+1860.	[port]		solaris 2.8: hack_shutup_pthreadmutexinit was
+			incorrectly set. [RT #14775]
+
+1858.	[bug]		The flush-zones-on-shutdown option wasn't being
+			parsed. [RT #14686]
+
+1857.	[bug]		named could trigger a INSIST() if reconfigured /
+			reloaded too fast.  [RT #14673]
+
+1856.	[doc]		Switch Docbook toolchain from DSSSL to XSL.
+			[RT #11398]
+
+1855.	[bug]		ixfr-from-differences was failing to detect changes
+			of ttl due to dns_diff_subtract() was ignoring the ttl
+			of records.  [RT #14616]
+
+1854.	[bug]		lwres also needs to know the print format for
+			(long long).  [RT #13754]
+
+1853.	[bug]		Rework how DLV interacts with proveunsecure().
+			[RT #13605]
+
+1852.	[cleanup]	Remove last vestiges of dnssec-signkey and
+			dnssec-makekeyset (removed from Makefile years ago).
+
+1850.	[bug]		Memory leak in lwres_getipnodebyaddr(). [RT #14591]
+
+1849.	[doc]		All forms of the man pages (docbook, man, html) should
+			have consistant copyright dates.
+
+1848.	[bug]		Improve SMF integration. [RT #13238]
+
+1847.	[bug]		isc_ondestroy_init() is called too late in
+			dns_rbtdb_create()/dns_rbtdb64_create(). 
+			[RT #13661]
+			
+1846.	[contrib]	query-loc-0.3.0 from Stephane Bortzmeyer
+			<bortzmeyer@nic.fr>.
+
+1845.	[bug]		Improve error reporting to distingish between
+			accept()/fcntl() and socket()/fcntl() errors.
+			[RT #13745]
+
+1844.	[bug]		inet_pton() accepted more that 4 hexadecimal digits
+			for each 16 bit piece of the IPv6 address.  The text
+			representation of a IPv6 address has been tighted
+			to disallow this (draft-ietf-ipv6-addr-arch-v4-02.txt).
+			[RT #5662]
+
+1843.	[cleanup]	CINCLUDES takes precedence over CFLAGS.  This helps
+			when CFLAGS contains "-I /usr/local/include"
+			resulting in old header files being used.
+
+1842.	[port]		cmsg_len() could produce incorrect results on
+			some platform. [RT #13744]
+
+1841.	[bug]		"dig +nssearch" now makes a recursive query to
+			find the list of nameservers to query. [RT #13694]
+
+1839.	[bug]		<isc/hash.h> was not being installed.
+
+1838.	[cleanup]	Don't allow Linux capabilities to be inherited.
+			[RT #13707]
+
+1837.	[bug]		Compile time option ISC_FACILITY was not effective
+			for 'named -u <user>'.  [RT #13714]
+
+1836.	[cleanup]	Silence compiler warnings in hash_test.c.
+
+1835.	[bug]		Update dnssec-signzone's usage message. [RT #13657]
+
+1834.	[bug]		Bad memset in rdata_test.c. [RT #13658]
+
+1833.	[bug]		Race condition in isc_mutex_lock_profile(). [RT #13660]
+
+1832.	[bug]		named fails to return BADKEY on unknown TSIG algorithm.
+			[RT #13620]
+
+1831.	[doc]		Update named-checkzone documentation. [RT#13604]
+
+1830.	[bug]		adb lame cache has sence of test reversed. [RT #13600]
+
+1829.	[bug]		win32: "pid-file none;" broken. [RT #13563]
+
+1828.	[bug]		isc_rwlock_init() failed to properly cleanup if it
+			encountered a error. [RT #13549]
+
+1827.	[bug]		host: update usage message for '-a'. [RT #37116]
+
+1826.	[bug]		Missing DESTROYLOCK() in isc_mem_createx() on out
+			of memory error. [RT #13537]
+
+1825.	[bug]		Missing UNLOCK() on out of memory error from in
+			rbtdb.c:subtractrdataset(). [RT #13519]
+
+1824.	[bug]		Memory leak on dns_zone_setdbtype() failure.
+			[RT #13510]
+
+1823.	[bug]		Wrong macro used to check for point to point interface.
+			[RT#13418]
+
+1822.	[bug]		check-names test for RT was reversed. [RT #13382]
+
+1821.	[doc]		acls definitions are no longer required to be 
+			in named.conf prior to reference.  They can be
+			defined after being referenced.
+
+1820.	[bug]		Gracefully handle acl loops. [RT #13659]
+
+1819.	[bug]		The validator needed to check both the algorithm and
+			digest types of the DS to determine if it could be
+			used to introduce a secure zone. [RT #13593]
+
+1816.	[port]		UnixWare: failed to compile lib/isc/unix/net.c.
+			[RT #13597]
+
+1815.	[bug]		nsupdate triggered a REQUIRE if the server was set
+			without also setting the zone and it encountered
+			a CNAME and was using TSIG.  [RT #13086]
+
+1810.	[bug]		configure, lib/bind/configure make different default
+			decisions about whether to do a threaded build.
+			[RT #13212]
+
+1809.	[bug]		"make distclean" failed for libbind if the platform
+			is not supported.
+
+1807.	[bug]		When forwarding (forward only) set the active domain
+			from the forward zone name. [RT #13526]
+			
+1804.	[bug]		Ensure that if we are queried for glue that it fits
+			in the additional section or TC is set to tell the
+			client to retry using TCP. [RT #10114]
+
+1803.	[bug]		dnssec-signzone sometimes failed to remove old
+			RRSIGs. [RT #13483]
+
+1802.	[bug]		Handle connection resets better. [RT #11280]
+
+1799.	[bug]		'rndc flushname' failed to flush negative cache
+			entries. [RT #13438]
+
+1795.	[bug]		"rndc dumpdb" was not fully documented.  Minor
+			formating issues with "rndc dumpdb -all".  [RT #13396]
+
+1791.	[bug]		'host -t a' still printed out AAAA and MX records.
+			[RT #13230]
+
 	--- 9.3.1 released ---
 
 1818.	[bug]		'named-checkconf -z' triggered an INSIST. [RT #13599]
diff --git a/contrib/bind9/FAQ b/contrib/bind9/FAQ
index f6ed41e422c5..9b806cbde533 100644
--- a/contrib/bind9/FAQ
+++ b/contrib/bind9/FAQ
@@ -1,470 +1,525 @@
-
-
-
 Frequently Asked Questions about BIND 9
 
+-------------------------------------------------------------------------------
 
 Q: Why doesn't -u work on Linux 2.2.x when I build with --enable-threads?
 
 A: Linux threads do not fully implement the Posix threads (pthreads) standard.
-In particular, setuid() operates only on the current thread, not the full
-process.  Because of this limitation, BIND 9 cannot use setuid() on Linux as it
-can on all other supported platforms.  setuid() cannot be called before
-creating threads, since the server does not start listening on reserved ports
-until after threads have started.
+   In particular, setuid() operates only on the current thread, not the full
+   process. Because of this limitation, BIND 9 cannot use setuid() on Linux as
+   it can on all other supported platforms. setuid() cannot be called before
+   creating threads, since the server does not start listening on reserved
+   ports until after threads have started.
 
-  In the 2.2.18 or 2.3.99-pre3 and newer kernels, the ability to preserve
-capabilities across a setuid() call is present.  This allows BIND 9 to call
-setuid() early, while retaining the ability to bind reserved ports.  This is
-a Linux-specific hack.
+   In the 2.2.18 or 2.3.99-pre3 and newer kernels, the ability to preserve
+   capabilities across a setuid() call is present. This allows BIND 9 to call
+   setuid() early, while retaining the ability to bind reserved ports. This is
+   a Linux-specific hack.
 
-  On a 2.2 kernel, BIND 9 does drop many root privileges, so it should be less
-of a security risk than a root process that has not dropped privileges.
+   On a 2.2 kernel, BIND 9 does drop many root privileges, so it should be less
+   of a security risk than a root process that has not dropped privileges.
 
-  If Linux threads ever work correctly, this restriction will go away.
+   If Linux threads ever work correctly, this restriction will go away.
 
-  Configuring BIND9 with the --disable-threads option (the default) causes a
-non-threaded version to be built, which will allow -u to be used.
+   Configuring BIND9 with the --disable-threads option (the default) causes a
+   non-threaded version to be built, which will allow -u to be used.
 
+Q: Why does named log the warning message "no TTL specified - using SOA MINTTL
+   instead"?
 
-Q: Why does named log the warning message "no TTL specified - using SOA
-MINTTL instead"?
-
-A: Your zone file is illegal according to RFC1035.  It must either
-have a line like
+A: Your zone file is illegal according to RFC1035. It must either have a line
+   like:
 
    $TTL 86400
 
-at the beginning, or the first record in it must have a TTL field,
-like the "84600" in this example:
+   at the beginning, or the first record in it must have a TTL field, like the
+   "84600" in this example:
 
    example.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 )
 
 Q: Why do I see 5 (or more) copies of named on Linux?
 
-A: Linux threads each show up as a process under ps.  The approximate
-number of threads running is n+4, where n is the number of CPUs.  Note that
-the amount of memory used is not cumulative; if each process is using 10M of
-memory, only a total of 10M is used.
-
+A: Linux threads each show up as a process under ps. The approximate number of
+   threads running is n+4, where n is the number of CPUs. Note that the amount
+   of memory used is not cumulative; if each process is using 10M of memory,
+   only a total of 10M is used.
 
-Q: Why does BIND 9 log "permission denied" errors accessing its
-configuration files or zones on my Linux system even though it is running
-as root?
-
-A: On Linux, BIND 9 drops most of its root privileges on startup.
-This including the privilege to open files owned by other users.
-Therefore, if the server is running as root, the configuration files
-and zone files should also be owned by root.
+Q: Why does BIND 9 log "permission denied" errors accessing its configuration
+   files or zones on my Linux system even though it is running as root?
 
+A: On Linux, BIND 9 drops most of its root privileges on startup. This
+   including the privilege to open files owned by other users. Therefore, if
+   the server is running as root, the configuration files and zone files should
+   also be owned by root.
 
 Q: Why do I get errors like "dns_zone_load: zone foo/IN: loading master file
-bar: ran out of space"
-
-A: This is often caused by TXT records with missing close quotes.  Check that
-all TXT records containing quoted strings have both open and close quotes.
+   bar: ran out of space"?
 
+A: This is often caused by TXT records with missing close quotes. Check that
+   all TXT records containing quoted strings have both open and close quotes.
 
 Q: How do I produce a usable core file from a multithreaded named on Linux?
 
-A: If the Linux kernel is 2.4.7 or newer, multithreaded core dumps
-are usable (that is, the correct thread is dumped).  Otherwise, if using
-a 2.2 kernel, apply the kernel patch found in contrib/linux/coredump-patch
-and rebuild the kernel.  This patch will cause multithreaded programs to dump
-the correct thread.
-
+A: If the Linux kernel is 2.4.7 or newer, multithreaded core dumps are usable
+   (that is, the correct thread is dumped). Otherwise, if using a 2.2 kernel,
+   apply the kernel patch found in contrib/linux/coredump-patch and rebuild the
+   kernel. This patch will cause multithreaded programs to dump the correct
+   thread.
 
 Q: How do I restrict people from looking up the server version?
 
-A: Put a "version" option containing something other than the real
-version in the "options" section of named.conf.  Note doing this will
-not prevent attacks and may impede people trying to diagnose problems
-with your server.  Also it is possible to "fingerprint" nameservers to
-determine their version.
-
-
-Q: How do I restrict only remote users from looking up the server
-version?
+A: Put a "version" option containing something other than the real version in
+   the "options" section of named.conf. Note doing this will not prevent
+   attacks and may impede people trying to diagnose problems with your server.
+   Also it is possible to "fingerprint" nameservers to determine their version.
 
-A: The following view statement will intercept lookups as the internal
-view that holds the version information will be matched last.  The
-caveats of the previous answer still apply, of course.
+Q: How do I restrict only remote users from looking up the server version?
 
-  view "chaos" chaos {
-	  match-clients { <those to be refused>; };
-	  allow-query { none; };
-	  zone "." {
-		  type hint;
-		  file "/dev/null";  // or any empty file
-	  };
-  };
+A: The following view statement will intercept lookups as the internal view
+   that holds the version information will be matched last. The caveats of the
+   previous answer still apply, of course.
 
+   view "chaos" chaos {
+           match-clients { <those to be refused>; };
+           allow-query { none; };
+           zone "." {
+                   type hint;
+                   file "/dev/null";  // or any empty file
+           };
+   };
 
 Q: What do "no source of entropy found" or "could not open entropy source foo"
-mean?
+   mean?
 
 A: The server requires a source of entropy to perform certain operations,
-mostly DNSSEC related.  These messages indicate that you have no source
-of entropy.  On systems with /dev/random or an equivalent, it is used by
-default.  A source of entropy can also be defined using the random-device
-option in named.conf.
+   mostly DNSSEC related. These messages indicate that you have no source of
+   entropy. On systems with /dev/random or an equivalent, it is used by
+   default. A source of entropy can also be defined using the random-device
+   option in named.conf.
 
+Q: I installed BIND 9 and restarted named, but it's still BIND 8. Why?
 
-Q: I installed BIND 9 and restarted named, but it's still BIND 8.  Why?
+A: BIND 9 is installed under /usr/local by default. BIND 8 is often installed
+   under /usr. Check that the correct named is running.
 
-A: BIND 9 is installed under /usr/local by default.  BIND 8 is often
-installed under /usr.  Check that the correct named is running.
+Q: I'm trying to use TSIG to authenticate dynamic updates or zone transfers.
+   I'm sure I have the keys set up correctly, but the server is rejecting the
+   TSIG. Why?
 
+A: This may be a clock skew problem. Check that the the clocks on the client
+   and server are properly synchronised (e.g., using ntp).
 
-Q: I'm trying to use TSIG to authenticate dynamic updates or zone
-transfers.  I'm sure I have the keys set up correctly, but the server
-is rejecting the TSIG.  Why?
+Q: I'm trying to compile BIND 9, and "make" is failing due to files not being
+   found. Why?
 
-A: This may be a clock skew problem.  Check that the the clocks on
-the client and server are properly synchronized (e.g., using ntp).
+A: Using a parallel or distributed "make" to build BIND 9 is not supported, and
+   doesn't work. If you are using one of these, use normal make or gmake
+   instead.
 
+Q: I have a BIND 9 master and a BIND 8.2.3 slave, and the master is logging
+   error messages like "notify to 10.0.0.1#53 failed: unexpected end of input".
+   What's wrong?
 
-Q: I'm trying to compile BIND 9, and "make" is failing due to files not
-being found.  Why?
+A: This error message is caused by a known bug in BIND 8.2.3 and is fixed in
+   BIND 8.2.4. It can be safely ignored - the notify has been acted on by the
+   slave despite the error message.
 
-A: Using a parallel or distributed "make" to build BIND 9 is not
-supported, and doesn't work.  If you are using one of these, use
-normal make or gmake instead.
+Q: I keep getting log messages like the following. Why?
 
+   Dec 4 23:47:59 client 10.0.0.1#1355: updating zone 'example.com/IN': update
+   failed: 'RRset exists (value dependent)' prerequisite not satisfied
+   (NXRRSET)
 
-Q: I have a BIND 9 master and a BIND 8.2.3 slave, and the master is
-logging error messages like "notify to 10.0.0.1#53 failed: unexpected
-end of input".  What's wrong?
+A: DNS updates allow the update request to test to see if certain conditions
+   are met prior to proceeding with the update. The message above is saying
+   that conditions were not met and the update is not proceeding. See doc/rfc/
+   rfc2136.txt for more details on prerequisites.
 
-A: This error message is caused by a known bug in BIND 8.2.3 and is fixed
-in BIND 8.2.4.  It can be safely ignored - the notify has been acted on by
-the slave despite the error message.
+Q: I keep getting log messages like the following. Why?
 
+   Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied
 
-Q: I keep getting log messages like the following.  Why?
+A: Someone is trying to update your DNS data using the RFC2136 Dynamic Update
+   protocol. Windows 2000 machines have a habit of sending dynamic update
+   requests to DNS servers without being specifically configured to do so. If
+   the update requests are coming from a Windows 2000 machine, see http://
+   support.microsoft.com/support/kb/articles/q246/8/04.asp for information
+   about how to turn them off.
 
-   Dec  4 23:47:59 client 10.0.0.1#1355: updating zone 'example.com/IN':
-   update failed: 'RRset exists (value dependent)' prerequisite not
-   satisfied (NXRRSET)
+Q: I see a log message like the following. Why?
 
-A: DNS updates allow the update request to test to see if certain
-conditions are met prior to proceeding with the update.  The message
-above is saying that conditions were not met and the update is not
-proceeding.  See doc/rfc/rfc2136.txt for more details on prerequisites.
+   couldn't open pid file '/var/run/named.pid': Permission denied
 
+A: You are most likely running named as a non-root user, and that user does not
+   have permission to write in /var/run. The common ways of fixing this are to
+   create a /var/run/named directory owned by the named user and set pid-file
+   to "/var/run/named/named.pid", or set pid-file to "named.pid", which will
+   put the file in the directory specified by the directory option (which, in
+   this case, must be writable by the named user).
+
+Q: When I do a "dig . ns", many of the A records for the root servers are
+   missing. Why?
+
+A: This is normal and harmless. It is a somewhat confusing side effect of the
+   way BIND 9 does RFC2181 trust ranking and of the efforts BIND 9 makes to
+   avoid promoting glue into answers.
+
+   When BIND 9 first starts up and primes its cache, it receives the root
+   server addresses as additional data in an authoritative response from a root
+   server, and these records are eligible for inclusion as additional data in
+   responses. Subsequently it receives a subset of the root server addresses as
+   additional data in a non-authoritative (referral) response from a root
+   server. This causes the addresses to now be considered non-authoritative
+   (glue) data, which is not eligible for inclusion in responses.
+
+   The server does have a complete set of root server addresses cached at all
+   times, it just may not include all of them as additional data, depending on
+   whether they were last received as answers or as glue. You can always look
+   up the addresses with explicit queries like "dig a.root-servers.net A".
+
+Q: Zone transfers from my BIND 9 master to my Windows 2000 slave fail. Why?
+
+A: This may be caused by a bug in the Windows 2000 DNS server where DNS
+   messages larger than 16K are not handled properly. This can be worked around
+   by setting the option "transfer-format one-answer;". Also check whether your
+   zone contains domain names with embedded spaces or other special characters,
+   like "John\032Doe\213s\032Computer", since such names have been known to
+   cause Windows 2000 slaves to incorrectly reject the zone.
 
-Q: I keep getting log messages like the following.  Why?
+Q: Why don't my zones reload when I do an "rndc reload" or SIGHUP?
 
-   Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied
+A: A zone can be updated either by editing zone files and reloading the server
+   or by dynamic update, but not both. If you have enabled dynamic update for a
+   zone using the "allow-update" option, you are not supposed to edit the zone
+   file by hand, and the server will not attempt to reload it.
+
+Q: I can query the nameserver from the nameserver but not from other machines.
+   Why?
+
+A: This is usually the result of the firewall configuration stopping the
+   queries and / or the replies.
+
+Q: How can I make a server a slave for both an internal and an external view at
+   the same time? When I tried, both views on the slave were transferred from
+   the same view on the master.
+
+A: You will need to give the master and slave multiple IP addresses and use
+   those to make sure you reach the correct view on the other machine.
+
+   Master: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias)
+       internal:
+           match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
+                   notify-source 10.0.1.1;
+                   transfer-source 10.0.1.1;
+                   query-source address 10.0.1.1;
+       external:
+           match-clients { any; };
+           recursion no;   // don't offer recursion to the world
+           notify-source 10.0.1.2;
+           transfer-source 10.0.1.2;
+           query-source address 10.0.1.2;
+
+   Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
+       internal:
+           match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
+           notify-source 10.0.1.3;
+           transfer-source 10.0.1.3;
+           query-source address 10.0.1.3;
+      external:
+           match-clients { any; };
+           recursion no;   // don't offer recursion to the world
+           notify-source 10.0.1.4;
+           transfer-source 10.0.1.4;
+           query-source address 10.0.1.4;
+
+   You put the external address on the alias so that all the other dns clients
+   on these boxes see the internal view by default.
+
+A: BIND 9.3 and later: Use TSIG to select the appropriate view.
+
+   Master 10.0.1.1:
+           key "external" {
+                   algorithm hmac-md5;
+                   secret "xxxxxxxx";
+           };
+           view "internal" {
+                   match-clients { !key external; 10.0.1/24; };
+                   ...
+           };
+           view "external" {
+                   match-clients { key external; any; };
+                   server 10.0.0.2 { keys external; };
+                   recursion no;
+                   ...
+           };
+
+   Slave 10.0.1.2:
+           key "external" {
+                   algorithm hmac-md5;
+                   secret "xxxxxxxx";
+           };
+           view "internal" {
+                   match-clients { !key external; 10.0.1/24; };
+                   ...
+           };
+           view "external" {
+                   match-clients { key external; any; };
+                   server 10.0.0.1 { keys external; };
+                   recursion no;
+                   ...
+           };
+
+Q: I have FreeBSD 4.x and "rndc-confgen -a" just sits there.
+
+A: /dev/random is not configured. Use rndcontrol(8) to tell the kernel to use
+   certain interrupts as a source of random events. You can make this permanent
+   by setting rand_irqs in /etc/rc.conf.
+
+   /etc/rc.conf
+   rand_irqs="3 14 15"
+
+   See also http://people.freebsd.org/~dougb/randomness.html
 
-A: Someone is trying to update your DNS data using the RFC2136 Dynamic
-Update protocol.  Windows 2000 machines have a habit of sending dynamic
-update requests to DNS servers without being specifically configured to
-do so.  If the update requests are coming from a Windows 2000 machine,
-see <http://support.microsoft.com/support/kb/articles/q246/8/04.asp>
-for information about how to turn them off.
+Q: Why is named listening on UDP port other than 53?
 
+A: Named uses a system selected port to make queries of other nameservers. This
+   behaviour can be overridden by using query-source to lock down the port and/
+   or address. See also notify-source and transfer-source.
 
-Q: I see a log message like the following.  Why?
+Q: I get error messages like "multiple RRs of singleton type" and "CNAME and
+   other data" when transferring a zone. What does this mean?
 
-   couldn't open pid file '/var/run/named.pid': Permission denied
+A: These indicate a malformed master zone. You can identify the exact records
+   involved by transferring the zone using dig then running named-checkzone on
+   it.
 
-A: You are most likely running named as a non-root user, and that user
-does not have permission to write in /var/run.  The common ways of
-fixing this are to create a /var/run/named directory owned by the named
-user and set pid-file to "/var/run/named/named.pid", or set
-pid-file to "named.pid", which will put the file in the directory
-specified by the directory option (which, in this case, must be writable
-by the named user).
+   dig axfr example.com @master-server > tmp
+   named-checkzone example.com tmp
 
+   A CNAME record cannot exist with the same name as another record except for
+   the DNSSEC records which prove its existance (NSEC).
 
-Q: When I do a "dig . ns", many of the A records for the root
-servers are missing.  Why?
+   RFC 1034, Section 3.6.2: "If a CNAME RR is present at a node, no other data
+   should be present; this ensures that the data for a canonical name and its
+   aliases cannot be different. This rule also insures that a cached CNAME can
+   be used without checking with an authoritative server for other RR types."
 
-A: This is normal and harmless.  It is a somewhat confusing side effect
-of the way BIND 9 does RFC2181 trust ranking and of the efforts BIND 9
-makes to avoid promoting glue into answers.
+Q: I get error messages like "named.conf:99: unexpected end of input" where 99
+   is the last line of named.conf.
 
-When BIND 9 first starts up and primes its cache, it receives the root
-server addresses as additional data in an authoritative response from
-a root server, and these records are eligible for inclusion as
-additional data in responses.  Subsequently it receives a subset of
-the root server addresses as additional data in a non-authoritative
-(referral) response from a root server.  This causes the addresses to
-now be considered non-authoritative (glue) data, which is not eligible
-for inclusion in responses.
+A: Some text editors (notepad and wordpad) fail to put a line title indication
+   (e.g. CR/LF) on the last line of a text file. This can be fixed by "adding"
+   a blank line to the end of the file. Named expects to see EOF immediately
+   after EOL and treats text files where this is not met as truncated.
 
-The server does have a complete set of root server addresses cached
-at all times, it just may not include all of them as additional data,
-depending on whether they were last received as answers or as glue.
-You can always look up the addresses with explicit queries like
-"dig a.root-servers.net A".
+Q: I get warning messages like "zone example.com/IN: refresh: failure trying
+   master 1.2.3.4#53: timed out".
 
+A: Check that you can make UDP queries from the slave to the master
 
-Q: Zone transfers from my BIND 9 master to my Windows 2000 slave
-fail.  Why?
+   dig +norec example.com soa @1.2.3.4
 
-A: This may be caused by a bug in the Windows 2000 DNS server where
-DNS messages larger than 16K are not handled properly.  This can be
-worked around by setting the option "transfer-format one-answer;".
-Also check whether your zone contains domain names with embedded
-spaces or other special characters, like "John\032Doe\213s\032Computer",
-since such names have been known to cause Windows 2000 slaves to
-incorrectly reject the zone.
+   You could be generating queries faster than the slave can cope with. Lower
+   the serial query rate.
 
+   serial-query-rate 5; // default 20
 
-Q: Why don't my zones reload when I do an "rndc reload" or SIGHUP?
+Q: How do I share a dynamic zone between multiple views?
 
-A: A zone can be updated either by editing zone files and reloading
-the server or by dynamic update, but not both.  If you have enabled
-dynamic update for a zone using the "allow-update" option, you are not
-supposed to edit the zone file by hand, and the server will not
-attempt to reload it.
-
-
-Q: I can query the nameserver from the nameserver but not from other
-machines.  Why?
-
-A: This is usually the result of the firewall configuration stopping
-the queries and / or the replies.
-
-
-Q: How can I make a server a slave for both an internal and
-an external view at the same time?  When I tried, both views
-on the slave were transferred from the same view on the master.
-
-A: You will need to give the master and slave multiple IP addresses and
-use those to make sure you reach the correct view on the other machine.
-
-	e.g.
-	Master: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias)
-	    internal:
-		match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
-		notify-source 10.0.1.1;
-		transfer-source 10.0.1.1;
-		query-source address 10.0.1.1;
-	    external:
-		match-clients { any; };
-		recursion no;	// don't offer recursion to the world
-		notify-source 10.0.1.2;
-		transfer-source 10.0.1.2;
-		query-source address 10.0.1.2;
-
-	Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
-	    internal:
-		match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
-		notify-source 10.0.1.3;
-		transfer-source 10.0.1.3;
-		query-source address 10.0.1.3;
-	    external:
-		match-clients { any; };
-		recursion no;	// don't offer recursion to the world
-		notify-source 10.0.1.4;
-		transfer-source 10.0.1.4;
-		query-source address 10.0.1.4;
-
-	You put the external address on the alias so that all the other
-	dns clients on these boxes see the internal view by default.
-
-A: (BIND 9.3 and later) Use TSIG to select the appropriate view.
-
-	Master 10.0.1.1:
-	key "external" {
-		algorithm hmac-md5;
-		secret "xxxxxxxx";
-	};
-	view "internal" {
-		match-clients { !key external; 10.0.1/24; };
-		...
-	};
-	view "external" {
-		match-clients { key external; any; };
-		server 10.0.0.2 { keys external; };
-		recursion no;
-		...
-	};
-
-	Slave 10.0.1.2:
-	key "external" {
-		 algorithm hmac-md5;
-		 secret "xxxxxxxx";
-	};
-	view "internal" {
-		match-clients { !key external; 10.0.1/24; };
-	};
-	view "external" {
-		match-clients { key external; any; };
-		server 10.0.0.1 { keys external; };
-		recursion no;
-		...
-	};
-
-
-Q: I have Freebsd 4.x and "rndc-confgen -a" just sits there.
-
-A: /dev/random is not configured.  Use rndcontrol(8) to tell the kernel
-to use certain interrupts as a source of random events.  You can make this
-permanent by setting rand_irqs in /etc/rc.conf.
-
-e.g.
-	/etc/rc.conf
-	rand_irqs="3 14 15"
-
-See also http://people.freebsd.org/~dougb/randomness.html
+A: You choose one view to be master and the second a slave and transfer the
+   zone between views.
+
+   Master 10.0.1.1:
+           key "external" {
+                   algorithm hmac-md5;
+                   secret "xxxxxxxx";
+           };
+
+           key "mykey" {
+                   algorithm hmac-md5;
+                   secret "yyyyyyyy";
+           };
+
+           view "internal" {
+                   match-clients { !external; 10.0.1/24; };
+                   server 10.0.1.1 {
+                           /* Deliver notify messages to external view. */
+                           keys { external; };
+                   };
+                   zone "example.com" {
+                           type master;
+                           file "internal/example.db";
+                           allow-update { key mykey; };
+                           notify-also { 10.0.1.1; };
+                   };
+           };
+
+           view "external" {
+                   match-clients { external; any; };
+                   zone "example.com" {
+                           type slave;
+                           file "external/example.db";
+                           masters { 10.0.1.1; };
+                           transfer-source { 10.0.1.1; };
+                           // allow-update-forwarding { any; };
+                           // allow-notify { ... };
+                   };
+           };
 
+Q: I get a error message like "zone wireless.ietf56.ietf.org/IN: loading master
+   file primaries/wireless.ietf56.ietf.org: no owner".
 
-Q: Why is named listening on UDP port other than 53?
+A: This error is produced when a line in the master file contains leading white
+   space (tab/space) but the is no current record owner name to inherit the
+   name from. Usually this is the result of putting white space before a
+   comment. Forgeting the "@" for the SOA record or indenting the master file.
 
-A: Named uses a system selected port to make queries of other nameservers.
-This behaviour can be overridden by using query-source to lock down the
-port and/or address.  See also notify-source and transfer-source.
+Q: Why are my logs in GMT (UTC).
 
+A: You are running chrooted (-t) and have not supplied local timzone
+   information in the chroot area.
 
-Q: I get error messages like "multiple RRs of singleton type" and
-"CNAME and other data" when transferring a zone.  What does this mean?
+   FreeBSD: /etc/localtime
+   Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo
+   OSF: /etc/zoneinfo/localtime
 
-A: These indicate a malformed master zone.  You can identify the
-exact records involved by transferring the zone using dig then
-running named-checkzone on it.
+   See also tzset(3) and zic(8).
 
-	e.g.
-		dig axfr example.com @master-server > tmp
-		named-checkzone example.com tmp
+Q: I get the error message "named: capset failed: Operation not permitted" when
+   starting named.
 
+A: The capability module, part of "Linux Security Modules/LSM", has not been
+   loaded into the kernel. See insmod(8).
 
-Q: I get error messages like "named.conf:99: unexpected end of input" where
-99 is the last line of named.conf.
+Q: I get "rndc: connect failed: connection refused" when I try to run rndc.
 
-A: Some text editors (notepad and wordpad) fail to put a line termination
-indication (e.g. CR/LF) on the last line of a text file.  This can be fixed
-by "adding" a blank line to the end of the file.  Named expects to see EOF
-immediately after EOL and treats text files where this is not met as truncated.
+A: This is usually a configuration error.
 
+   First ensure that named is running and no errors are being reported at
+   startup (/var/log/messages or equivalent). Running "named -g <usual
+   arguments>" from a title can help at this point.
 
-Q: I get warning messages like "zone example.com/IN: refresh: failure trying master
-1.2.3.4#53: timed out".
+   Secondly ensure that named is configured to use rndc either by "rndc-confgen
+   -a", rndc-confgen or manually. The Administrators Reference manual has
+   details on how to do this.
 
-A: Check that you can make UDP queries from the slave to the master
+   Old versions of rndc-confgen used localhost rather than 127.0.0.1 in /etc/
+   rndc.conf for the default server. Update /etc/rndc.conf if necessary so that
+   the default server listed in /etc/rndc.conf matches the addresses used in
+   named.conf. "localhost" has two address (127.0.0.1 and ::1).
 
-	dig +norec example.com soa @1.2.3.4
+   If you use "rndc-confgen -a" and named is running with -t or -u ensure that
+   /etc/rndc.conf has the correct ownership and that a copy is in the chroot
+   area. You can do this by re-running "rndc-confgen -a" with appropriate -t
+   and -u arguments.
 
-A: You could be generating queries faster than the slave can cope with.  Lower
-the serial query rate.
+Q: I don't get RRSIG's returned when I use "dig +dnssec".
 
-	serial-query-rate 5; // default 20
+A: You need to ensure DNSSEC is enabled (dnssec-enable yes;).
 
-Q: How do I share a dynamic zone between multiple views?
+Q: I get "Error 1067" when starting named under Windows.
 
-A: You choose one view to be master and the second a slave and transfer
-the zone between views.
-
-	Master 10.0.1.1:
-	key "external" {
-		algorithm hmac-md5;
-		secret "xxxxxxxx";
-	};
-
-	key "mykey" {
-		algorithm hmac-md5;
-		secret "yyyyyyyy";
-	};
-
-	view "internal" {
-		match-clients { !external; 10.0.1/24; };
-		server 10.0.1.1 {
-			/* Deliver notify messages to external view. */
-			keys { external; };
-		};
-		zone "example.com" {
-			type master;
-			file "internal/example.db";
-			allow-update { key mykey; };
-			notify-also { 10.0.1.1; };
-		};
-	};
-
-	view "external" {
-		match-clients { external; any; };
-		zone "example.com" {
-			type slave;
-			file "external/example.db";
-			masters { 10.0.1.1; };
-			transfer-source { 10.0.1.1; };
-			// allow-update-forwarding { any; };
-			// allow-notify { ... };
-		};
-	};
+A: This is the service manager saying that named exited. You need to examine
+   the Application log in the EventViewer to find out why.
 
-Q: I get a error message like "zone wireless.ietf56.ietf.org/IN: loading master
-file primaries/wireless.ietf56.ietf.org: no owner".
+   Common causes are that you failed to create "named.conf" (usually "C:\
+   windows\dns\etc\named.conf") or failed to specify the directory in
+   named.conf.
 
-A: This error is produced when a line in the master file contains leading
-white space (tab/space) but the is no current record owner name to inherit
-the name from.  Usually this is the result of putting white space before
-a comment.  Forgeting the "@" for the SOA record or indenting the master
-file.
+   options {
+           Directory "C:\windows\dns\etc";
+   };
 
+Q: I get "transfer of 'example.net/IN' from 192.168.4.12#53: failed while
+   receiving responses: permission denied" error messages.
 
-Q: Why are my logs in GMT (UTC).
+A: These indicate a filesystem permission error preventing named creating /
+   renaming the temporary file. These will usually also have other associated
+   error messages like
 
-A: You are running chrooted (-t) and have not supplied local timzone
-information in the chroot area.
+   "dumping master file: sl/tmp-XXXX5il3sQ: open: permission denied"
 
-	FreeBSD: /etc/localtime
-	Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo
-	OSF: /etc/zoneinfo/localtime
+   Named needs write permission on the directory containing the file. Named
+   writes the new cache file to a temporary file then renames it to the name
+   specified in named.conf to ensure that the contents are always complete.
+   This is to prevent named loading a partial zone in the event of power
+   failure or similar interrupting the write of the master file.
 
-	See also tzset(3) and zic(8).
+   Note file names are relative to the directory specified in options and any
+   chroot directory ([<chroot dir>/][<options dir>]).
 
+   If named is invoked as "named -t /chroot/DNS" with the following named.conf
+   then "/chroot/DNS/var/named/sl" needs to be writable by the user named is
+   running as.
 
-Q: I get the error message "named: capset failed: Operation not permitted"
-when starting named.
+   options {
+           directory "/var/named";
+   };
 
-A: The capset module has not been loaded into the kernel.  See insmod(8).
+   zone "example.net" {
+           type slave;
+           file "sl/example.net";
+           masters { 192.168.4.12; };
+   };
 
+Q: How do I intergrate BIND 9 and Solaris SMF
 
-Q: I get "rndc: connect failed: connection refused" when I try to run
-   rndc.
+A: Sun has a blog entry describing how to do this.
 
-A: This is usually a configuration error.
+   http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris
 
-   First ensure that named is running and no errors are being
-   reported at startup (/var/log/messages or equivalent).  Running
-   "named -g <usual arguements>" from a terminal can help at this
-   point.
+Q: Can a NS record refer to a CNAME.
 
-   Secondly ensure that named is configured to use rndc either by
-   "rndc-confgen -a", rndc-confgen or manually.  The Administators
-   Reference manual has details on how to do this.
+A: No. The rules for glue (copies of the *address* records in the parent zones)
+   and additional section processing do not allow it to work.
 
-   Old versions of rndc-confgen used localhost rather than 127.0.0.1
-   in /etc/rndc.conf for the default server.  Update /etc/rndc.conf
-   if necessary so that the default server listed in /etc/rndc.conf
-   matches the addresses used in named.conf.  "localhost" has two
-   address (127.0.0.1 and ::1).
+   You would have to add both the CNAME and address records (A/AAAA) as glue to
+   the parent zone and have CNAMEs be followed when doing additional section
+   processing to make it work. No namesever implementation supports either of
+   these requirements.
 
-   If you use "rndc-confgen -a" and named is running with -t or -u
-   ensure that /etc/rndc.conf has the correct ownership and that
-   a copy is in the chroot area.  You can do this by re-running
-   "rndc-confgen -a" with appropriate -t and -u arguements.
+Q: What does "RFC 1918 response from Internet for 0.0.0.10.IN-ADDR.ARPA" mean?
 
+A: If the IN-ADDR.ARPA name covered refers to a internal address space you are
+   using then you have failed to follow RFC 1918 usage rules and are leaking
+   queries to the Internet. You should establish your own zones for these
+   addresses to prevent you quering the Internet's name servers for these
+   addresses. Please see http://as112.net/ for details of the problems you are
+   causing and the counter measures that have had to be deployed.
 
-Q: I don't get RRSIG's returned when I use "dig +dnssec".
+   If you are not using these private addresses then a client has queried for
+   them. You can just ignore the messages, get the offending client to stop
+   sending you these messages as they are most probably leaking them or setup
+   your own zones empty zones to serve answers to these queries.
 
-A: You need to ensure DNSSEC is enabled (dnssec-enable yes;).
+   zone "10.IN-ADDR.ARPA" {
+           type master;
+           file "empty";
+   };
 
+   zone "16.172.IN-ADDR.ARPA" {
+           type master;
+           file "empty";
+   };
 
-Q: I get "Error 1067" when starting named under Windows.
+   ...
+
+   zone "31.172.IN-ADDR.ARPA" {
+           type master;
+           file "empty";
+   };
 
-A: This is the service manager saying that named exited.   You need to
-   examine the Application log in the EventViewer to find out why.
+   zone "168.192.IN-ADDR.ARPA" {
+           type master;
+           file "empty";
+   };
 
-   Common causes are that you failed to create "named.conf" (usually 
-   "C:\windows\dns\etc\named.conf") or failed to specify the directory
-   in named.conf.
+   empty:
+   @ 10800 IN SOA <name-of-server>. <contact-email>. (
+                  1 3600 1200 604800 10800 )
+   @ 10800 IN NS <name-of-server>.
 
-        options {
-                Directory "C:\windows\dns\etc";
-        };
+   Note
 
+   Future versions of named are likely to do this automatically.
 
diff --git a/contrib/bind9/README b/contrib/bind9/README
index 8e3d01df5bbf..574b07d73247 100644
--- a/contrib/bind9/README
+++ b/contrib/bind9/README
@@ -43,6 +43,26 @@ BIND 9
 		Nominum, Inc.
 
 
+BIND 9.3.2
+
+        BIND 9.3.2 is a maintenance release, containing fixes for
+        a number of bugs in 9.3.1.
+
+        libbind: corresponds to that from BIND 8.4.7-REL.
+
+	Known Issues:
+
+	The following INSIST can be triggered with DNSSEC enabled.
+
+resolver.c:762: INSIST(result != 0 || dns_rdataset_isassociated(event->rdataset) || fctx->type == ((dns_rdatatype_t)dns_rdatatype_any) || fctx->type == ((dns_rdatatype_t)dns_rdatatype_rrsig)) failed
+
+	We are still trying to isolate the cause.  If you have core
+	dump please send a bug report to bind9-bugs@isc.org with
+	the location of the core, named executable and OS details.
+	
+	Note: contrib/nanny contains a perl script to restart named
+	in the event of a INSIST/REQUIRE/ENSURE failure.
+
 BIND 9.3.1
 
         BIND 9.3.1 is a maintenance release, containing fixes for
@@ -210,7 +230,7 @@ Building
 		UnixWare 7.1.1
 		HP-UX 10.20
 		BSD/OS 4.2
-		Mac OS X 10.1
+		Mac OS X 10.1, 10.3.8
 
 	To build, just
 
@@ -300,9 +320,11 @@ Building
 	Building with gcc is not supported, unless gcc is the vendor's usual
 	compiler (e.g. the various BSD systems, Linux).
 	
+	Known compiler issues:
 	* gcc-3.2.1 and gcc-3.1.1 is known to cause problems with solaris-x86.
 	* gcc prior to gcc-3.2.3 ultrasparc generates incorrect code at -02.
 	* gcc-3.3.5 powerpc generates incorrect code at -02.
+	* Irix, MipsPRO 7.4.1m is known to cause problems.
 
 	A limited test suite can be run with "make test".  Many of
 	the tests require you to configure a set of virtual IP addresses
diff --git a/contrib/bind9/bin/check/named-checkconf.8 b/contrib/bind9/bin/check/named-checkconf.8
index 25dbdd86ff15..68b745aed290 100644
--- a/contrib/bind9/bin/check/named-checkconf.8
+++ b/contrib/bind9/bin/check/named-checkconf.8
@@ -1,59 +1,70 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000-2002  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000-2002 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: named-checkconf.8,v 1.11.12.4 2004/06/03 05:35:41 marka Exp $
+.\" $Id: named-checkconf.8,v 1.11.12.7 2005/10/13 02:33:41 marka Exp $
 .\"
-.TH "NAMED-CHECKCONF" "8" "June 14, 2000" "BIND9" ""
-.SH NAME
-named-checkconf \- named configuration file syntax checking tool
-.SH SYNOPSIS
-.sp
-\fBnamed-checkconf\fR [ \fB-v\fR ]  [ \fB-j\fR ]  [ \fB-t \fIdirectory\fB\fR ]  \fBfilename\fR [ \fB-z\fR ] 
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "NAMED\-CHECKCONF" "8" "June 14, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+named\-checkconf \- named configuration file syntax checking tool
+.SH "SYNOPSIS"
+.HP 16
+\fBnamed\-checkconf\fR [\fB\-v\fR] [\fB\-j\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] {filename} [\fB\-z\fR]
 .SH "DESCRIPTION"
 .PP
-\fBnamed-checkconf\fR checks the syntax, but not
-the semantics, of a named configuration file.
+\fBnamed\-checkconf\fR
+checks the syntax, but not the semantics, of a named configuration file.
 .SH "OPTIONS"
 .TP
-\fB-t \fIdirectory\fB\fR
-chroot to \fIdirectory\fR so that include
-directives in the configuration file are processed as if
-run by a similarly chrooted named.
+\-t \fIdirectory\fR
+chroot to
+\fIdirectory\fR
+so that include directives in the configuration file are processed as if run by a similarly chrooted named.
 .TP
-\fB-v\fR
-Print the version of the \fBnamed-checkconf\fR
+\-v
+Print the version of the
+\fBnamed\-checkconf\fR
 program and exit.
 .TP
-\fB-z\fR
+\-z
 Perform a check load the master zonefiles found in
 \fInamed.conf\fR.
 .TP
-\fB-j\fR
+\-j
 When loading a zonefile read the journal if it exists.
 .TP
-\fBfilename\fR
-The name of the configuration file to be checked. If not
-specified, it defaults to \fI/etc/named.conf\fR.
+filename
+The name of the configuration file to be checked. If not specified, it defaults to
+\fI/etc/named.conf\fR.
 .SH "RETURN VALUES"
 .PP
-\fBnamed-checkconf\fR returns an exit status of 1 if
-errors were detected and 0 otherwise.
+\fBnamed\-checkconf\fR
+returns an exit status of 1 if errors were detected and 0 otherwise.
 .SH "SEE ALSO"
 .PP
 \fBnamed\fR(8),
-\fIBIND 9 Administrator Reference Manual\fR.
+BIND 9 Administrator Reference Manual.
 .SH "AUTHOR"
 .PP
 Internet Systems Consortium
diff --git a/contrib/bind9/bin/check/named-checkconf.docbook b/contrib/bind9/bin/check/named-checkconf.docbook
index d1336cfa537b..c2529f642fe0 100644
--- a/contrib/bind9/bin/check/named-checkconf.docbook
+++ b/contrib/bind9/bin/check/named-checkconf.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2002  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2002  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: named-checkconf.docbook,v 1.3.2.1.8.5 2004/06/03 02:24:59 marka Exp $ -->
+<!-- $Id: named-checkconf.docbook,v 1.3.2.1.8.7 2005/05/12 21:35:56 sra Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,20 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><application>named-checkconf</application></refname>
     <refpurpose>named configuration file syntax checking tool</refpurpose>
@@ -116,6 +132,7 @@
     <para>
         <command>named-checkconf</command> returns an exit status of 1 if
 	errors were detected and 0 otherwise.
+    </para>
   </refsect1>
 
   <refsect1>
diff --git a/contrib/bind9/bin/check/named-checkconf.html b/contrib/bind9/bin/check/named-checkconf.html
index 8d5f38e99c51..14b8ff89cb1f 100644
--- a/contrib/bind9/bin/check/named-checkconf.html
+++ b/contrib/bind9/bin/check/named-checkconf.html
@@ -1,216 +1,92 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2002  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2002 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: named-checkconf.html,v 1.5.2.1.4.5 2004/08/22 23:38:57 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->named-checkconf</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><SPAN
-CLASS="APPLICATION"
->named-checkconf</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->named-checkconf</SPAN
->&nbsp;--&nbsp;named configuration file syntax checking tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->named-checkconf</B
->  [<VAR
-CLASS="OPTION"
->-v</VAR
->] [<VAR
-CLASS="OPTION"
->-j</VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></VAR
->] {filename} [<VAR
-CLASS="OPTION"
->-z</VAR
->]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN26"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->named-checkconf</B
-> checks the syntax, but not
+<!-- $Id: named-checkconf.html,v 1.5.2.1.4.12 2005/10/13 02:33:42 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>named-checkconf</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">named-checkconf</span> &#8212; named configuration file syntax checking tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-z</code>]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525865"></a><h2>DESCRIPTION</h2>
+<p>
+        <span><strong class="command">named-checkconf</strong></span> checks the syntax, but not
 	the semantics, of a named configuration file.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN30"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-t <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></DT
-><DD
-><P
->	      chroot to <TT
-CLASS="FILENAME"
->directory</TT
-> so that include
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525878"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
+<dd><p>
+	      chroot to <code class="filename">directory</code> so that include
 	      directives in the configuration file are processed as if
 	      run by a similarly chrooted named.
-	  </P
-></DD
-><DT
->-v</DT
-><DD
-><P
->	      Print the version of the <B
-CLASS="COMMAND"
->named-checkconf</B
->
+	  </p></dd>
+<dt><span class="term">-v</span></dt>
+<dd><p>
+	      Print the version of the <span><strong class="command">named-checkconf</strong></span>
 	      program and exit.
-	  </P
-></DD
-><DT
->-z</DT
-><DD
-><P
->	      Perform a check load the master zonefiles found in
-	      <TT
-CLASS="FILENAME"
->named.conf</TT
->.
-	  </P
-></DD
-><DT
->-j</DT
-><DD
-><P
->	      When loading a zonefile read the journal if it exists.
-	  </P
-></DD
-><DT
->filename</DT
-><DD
-><P
->	       The name of the configuration file to be checked.  If not
-	       specified, it defaults to <TT
-CLASS="FILENAME"
->/etc/named.conf</TT
->.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN58"
-></A
-><H2
->RETURN VALUES</H2
-><P
->        <B
-CLASS="COMMAND"
->named-checkconf</B
-> returns an exit status of 1 if
+	  </p></dd>
+<dt><span class="term">-z</span></dt>
+<dd><p>
+	      Perform a check load the master zonefiles found in
+	      <code class="filename">named.conf</code>.
+	  </p></dd>
+<dt><span class="term">-j</span></dt>
+<dd><p>
+	      When loading a zonefile read the journal if it exists.
+	  </p></dd>
+<dt><span class="term">filename</span></dt>
+<dd><p>
+	       The name of the configuration file to be checked.  If not
+	       specified, it defaults to <code class="filename">/etc/named.conf</code>.
+	  </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525970"></a><h2>RETURN VALUES</h2>
+<p>
+        <span><strong class="command">named-checkconf</strong></span> returns an exit status of 1 if
 	errors were detected and 0 otherwise.
-  </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN62"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN69"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525982"></a><h2>SEE ALSO</h2>
+<p>
+      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526006"></a><h2>AUTHOR</h2>
+<p>
+        <span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/check/named-checkzone.8 b/contrib/bind9/bin/check/named-checkzone.8
index efa600c8e087..33402d5fe8d0 100644
--- a/contrib/bind9/bin/check/named-checkzone.8
+++ b/contrib/bind9/bin/check/named-checkzone.8
@@ -1,94 +1,111 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000-2002  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000-2002 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: named-checkzone.8,v 1.11.2.1.8.4 2004/06/03 05:35:42 marka Exp $
+.\" $Id: named-checkzone.8,v 1.11.2.1.8.8 2005/10/13 02:33:41 marka Exp $
 .\"
-.TH "NAMED-CHECKZONE" "8" "June 13, 2000" "BIND9" ""
-.SH NAME
-named-checkzone \- zone file validity checking tool
-.SH SYNOPSIS
-.sp
-\fBnamed-checkzone\fR [ \fB-d\fR ]  [ \fB-j\fR ]  [ \fB-q\fR ]  [ \fB-v\fR ]  [ \fB-c \fIclass\fB\fR ]  [ \fB-k \fImode\fB\fR ]  [ \fB-n \fImode\fB\fR ]  [ \fB-o \fIfilename\fB\fR ]  [ \fB-t \fIdirectory\fB\fR ]  [ \fB-w \fIdirectory\fB\fR ]  [ \fB-D\fR ]  \fBzonename\fR \fBfilename\fR
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "NAMED\-CHECKZONE" "8" "June 13, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+named\-checkzone \- zone file validity checking tool
+.SH "SYNOPSIS"
+.HP 16
+\fBnamed\-checkzone\fR [\fB\-d\fR] [\fB\-j\fR] [\fB\-q\fR] [\fB\-v\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-k\ \fR\fB\fImode\fR\fR] [\fB\-n\ \fR\fB\fImode\fR\fR] [\fB\-o\ \fR\fB\fIfilename\fR\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-w\ \fR\fB\fIdirectory\fR\fR] [\fB\-D\fR] {zonename} {filename}
 .SH "DESCRIPTION"
 .PP
-\fBnamed-checkzone\fR checks the syntax and integrity of
-a zone file. It performs the same checks as \fBnamed\fR
+\fBnamed\-checkzone\fR
+checks the syntax and integrity of a zone file. It performs the same checks as
+\fBnamed\fR
 does when loading a zone. This makes
-\fBnamed-checkzone\fR useful for checking zone
-files before configuring them into a name server.
+\fBnamed\-checkzone\fR
+useful for checking zone files before configuring them into a name server.
 .SH "OPTIONS"
 .TP
-\fB-d\fR
+\-d
 Enable debugging.
 .TP
-\fB-q\fR
-Quiet mode - exit code only.
+\-q
+Quiet mode \- exit code only.
 .TP
-\fB-v\fR
-Print the version of the \fBnamed-checkzone\fR
+\-v
+Print the version of the
+\fBnamed\-checkzone\fR
 program and exit.
 .TP
-\fB-j\fR
+\-j
 When loading the zone file read the journal if it exists.
 .TP
-\fB-c \fIclass\fB\fR
+\-c \fIclass\fR
 Specify the class of the zone. If not specified "IN" is assumed.
 .TP
-\fB-k \fImode\fB\fR
-Perform \fB"check-name"\fR checks with the specified failure mode.
-Possible modes are \fB"fail"\fR,
-\fB"warn"\fR (default) and
+\-k \fImode\fR
+Perform
+\fB"check\-name"\fR
+checks with the specified failure mode. Possible modes are
+\fB"fail"\fR,
+\fB"warn"\fR
+(default) and
 \fB"ignore"\fR.
 .TP
-\fB-n \fImode\fB\fR
-Specify whether NS records should be checked to see if they
-are addresses. Possible modes are \fB"fail"\fR,
-\fB"warn"\fR (default) and
+\-n \fImode\fR
+Specify whether NS records should be checked to see if they are addresses. Possible modes are
+\fB"fail"\fR,
+\fB"warn"\fR
+(default) and
 \fB"ignore"\fR.
 .TP
-\fB-o \fIfilename\fB\fR
-Write zone output to \fIdirectory\fR.
+\-o \fIfilename\fR
+Write zone output to
+\fIfilename\fR.
 .TP
-\fB-t \fIdirectory\fB\fR
-chroot to \fIdirectory\fR so that include
-directives in the configuration file are processed as if
-run by a similarly chrooted named.
+\-t \fIdirectory\fR
+chroot to
+\fIdirectory\fR
+so that include directives in the configuration file are processed as if run by a similarly chrooted named.
 .TP
-\fB-w \fIdirectory\fB\fR
-chdir to \fIdirectory\fR so that relative
-filenames in master file $INCLUDE directives work. This
-is similar to the directory clause in
+\-w \fIdirectory\fR
+chdir to
+\fIdirectory\fR
+so that relative filenames in master file $INCLUDE directives work. This is similar to the directory clause in
 \fInamed.conf\fR.
 .TP
-\fB-D\fR
+\-D
 Dump zone file in canonical format.
 .TP
-\fBzonename\fR
+zonename
 The domain name of the zone being checked.
 .TP
-\fBfilename\fR
+filename
 The name of the zone file.
 .SH "RETURN VALUES"
 .PP
-\fBnamed-checkzone\fR returns an exit status of 1 if
-errors were detected and 0 otherwise.
+\fBnamed\-checkzone\fR
+returns an exit status of 1 if errors were detected and 0 otherwise.
 .SH "SEE ALSO"
 .PP
 \fBnamed\fR(8),
-\fIRFC 1035\fR,
-\fIBIND 9 Administrator Reference Manual\fR.
+RFC 1035,
+BIND 9 Administrator Reference Manual.
 .SH "AUTHOR"
 .PP
 Internet Systems Consortium
diff --git a/contrib/bind9/bin/check/named-checkzone.docbook b/contrib/bind9/bin/check/named-checkzone.docbook
index 68b0baeeba44..ce0d78bdbdfe 100644
--- a/contrib/bind9/bin/check/named-checkzone.docbook
+++ b/contrib/bind9/bin/check/named-checkzone.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2002  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2002  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: named-checkzone.docbook,v 1.3.2.2.8.7 2004/06/03 02:25:00 marka Exp $ -->
+<!-- $Id: named-checkzone.docbook,v 1.3.2.2.8.11 2005/05/12 21:35:57 sra Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,20 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><application>named-checkzone</application></refname>
     <refpurpose>zone file validity checking tool</refpurpose>
@@ -103,6 +119,7 @@
               When loading the zone file read the journal if it exists.
           </para>   
         </listitem>
+      </varlistentry>
 
       <varlistentry>
         <term>-c <replaceable class="parameter">class</replaceable></term>
@@ -141,7 +158,7 @@
         <term>-o <replaceable class="parameter">filename</replaceable></term>
         <listitem>
           <para>
-	      Write zone output to <filename>directory</filename>.
+	      Write zone output to <filename>filename</filename>.
           </para>
         </listitem>
       </varlistentry>
@@ -205,6 +222,7 @@
     <para>
         <command>named-checkzone</command> returns an exit status of 1 if
 	errors were detected and 0 otherwise.
+    </para>
   </refsect1>
 
   <refsect1>
diff --git a/contrib/bind9/bin/check/named-checkzone.html b/contrib/bind9/bin/check/named-checkzone.html
index dd14c1f8fd73..cf544c94728a 100644
--- a/contrib/bind9/bin/check/named-checkzone.html
+++ b/contrib/bind9/bin/check/named-checkzone.html
@@ -1,367 +1,135 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2002  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2002 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: named-checkzone.html,v 1.5.2.2.4.5 2004/08/22 23:38:57 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->named-checkzone</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><SPAN
-CLASS="APPLICATION"
->named-checkzone</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->named-checkzone</SPAN
->&nbsp;--&nbsp;zone file validity checking tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->named-checkzone</B
->  [<VAR
-CLASS="OPTION"
->-d</VAR
->] [<VAR
-CLASS="OPTION"
->-j</VAR
->] [<VAR
-CLASS="OPTION"
->-q</VAR
->] [<VAR
-CLASS="OPTION"
->-v</VAR
->] [<VAR
-CLASS="OPTION"
->-c <VAR
-CLASS="REPLACEABLE"
->class</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-k <VAR
-CLASS="REPLACEABLE"
->mode</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-n <VAR
-CLASS="REPLACEABLE"
->mode</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-o <VAR
-CLASS="REPLACEABLE"
->filename</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-w <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-D</VAR
->] {zonename} {filename}</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN46"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->named-checkzone</B
-> checks the syntax and integrity of
-	a zone file.  It performs the same checks as <B
-CLASS="COMMAND"
->named</B
->
+<!-- $Id: named-checkzone.html,v 1.5.2.2.4.13 2005/10/13 02:33:42 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>named-checkzone</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">named-checkzone</span> &#8212; zone file validity checking tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">named-checkzone</code>  [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-o <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] {zonename} {filename}</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525922"></a><h2>DESCRIPTION</h2>
+<p>
+        <span><strong class="command">named-checkzone</strong></span> checks the syntax and integrity of
+	a zone file.  It performs the same checks as <span><strong class="command">named</strong></span>
 	does when loading a zone.  This makes
-	<B
-CLASS="COMMAND"
->named-checkzone</B
-> useful for checking zone
+	<span><strong class="command">named-checkzone</strong></span> useful for checking zone
 	files before configuring them into a name server.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN52"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-d</DT
-><DD
-><P
->	      Enable debugging.
-	  </P
-></DD
-><DT
->-q</DT
-><DD
-><P
->	      Quiet mode - exit code only.
-	  </P
-></DD
-><DT
->-v</DT
-><DD
-><P
->	      Print the version of the <B
-CLASS="COMMAND"
->named-checkzone</B
->
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525942"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-d</span></dt>
+<dd><p>
+	      Enable debugging.
+	  </p></dd>
+<dt><span class="term">-q</span></dt>
+<dd><p>
+	      Quiet mode - exit code only.
+	  </p></dd>
+<dt><span class="term">-v</span></dt>
+<dd><p>
+	      Print the version of the <span><strong class="command">named-checkzone</strong></span>
 	      program and exit.
-	  </P
-></DD
-><DT
->-j</DT
-><DD
-><P
->              When loading the zone file read the journal if it exists.
-          </P
-></DD
-><DT
->-c <VAR
-CLASS="REPLACEABLE"
->class</VAR
-></DT
-><DD
-><P
->	      Specify the class of the zone.  If not specified "IN" is assumed.
-	  </P
-></DD
-><DT
->-k <VAR
-CLASS="REPLACEABLE"
->mode</VAR
-></DT
-><DD
-><P
->	      Perform <B
-CLASS="COMMAND"
->"check-name"</B
-> checks with the specified failure mode.
-	      Possible modes are <B
-CLASS="COMMAND"
->"fail"</B
->,
-	      <B
-CLASS="COMMAND"
->"warn"</B
-> (default) and
-	      <B
-CLASS="COMMAND"
->"ignore"</B
->.
-	  </P
-></DD
-><DT
->-n <VAR
-CLASS="REPLACEABLE"
->mode</VAR
-></DT
-><DD
-><P
->	      Specify whether NS records should be checked to see if they
-	      are addresses.  Possible modes are <B
-CLASS="COMMAND"
->"fail"</B
->,
-	      <B
-CLASS="COMMAND"
->"warn"</B
-> (default) and
-	      <B
-CLASS="COMMAND"
->"ignore"</B
->.
-	  </P
-></DD
-><DT
->-o <VAR
-CLASS="REPLACEABLE"
->filename</VAR
-></DT
-><DD
-><P
->	      Write zone output to <TT
-CLASS="FILENAME"
->directory</TT
->.
-          </P
-></DD
-><DT
->-t <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></DT
-><DD
-><P
->              chroot to <TT
-CLASS="FILENAME"
->directory</TT
-> so that include
+	  </p></dd>
+<dt><span class="term">-j</span></dt>
+<dd><p>
+              When loading the zone file read the journal if it exists.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
+<dd><p>
+	      Specify the class of the zone.  If not specified "IN" is assumed.
+	  </p></dd>
+<dt><span class="term">-k <em class="replaceable"><code>mode</code></em></span></dt>
+<dd><p>
+	      Perform <span><strong class="command">"check-name"</strong></span> checks with the specified failure mode.
+	      Possible modes are <span><strong class="command">"fail"</strong></span>,
+	      <span><strong class="command">"warn"</strong></span> (default) and
+	      <span><strong class="command">"ignore"</strong></span>.
+	  </p></dd>
+<dt><span class="term">-n <em class="replaceable"><code>mode</code></em></span></dt>
+<dd><p>
+	      Specify whether NS records should be checked to see if they
+	      are addresses.  Possible modes are <span><strong class="command">"fail"</strong></span>,
+	      <span><strong class="command">"warn"</strong></span> (default) and
+	      <span><strong class="command">"ignore"</strong></span>.
+	  </p></dd>
+<dt><span class="term">-o <em class="replaceable"><code>filename</code></em></span></dt>
+<dd><p>
+	      Write zone output to <code class="filename">filename</code>.
+          </p></dd>
+<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
+<dd><p>
+              chroot to <code class="filename">directory</code> so that include
               directives in the configuration file are processed as if
               run by a similarly chrooted named.
-          </P
-></DD
-><DT
->-w <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></DT
-><DD
-><P
->              chdir to <TT
-CLASS="FILENAME"
->directory</TT
-> so that relative
+          </p></dd>
+<dt><span class="term">-w <em class="replaceable"><code>directory</code></em></span></dt>
+<dd><p>
+              chdir to <code class="filename">directory</code> so that relative
 	      filenames in master file $INCLUDE directives work.  This
 	      is similar to the directory clause in
-	      <TT
-CLASS="FILENAME"
->named.conf</TT
->.
-          </P
-></DD
-><DT
->-D</DT
-><DD
-><P
->	      Dump zone file in canonical format.
-	  </P
-></DD
-><DT
->zonename</DT
-><DD
-><P
->	       The domain name of the zone being checked.
-	  </P
-></DD
-><DT
->filename</DT
-><DD
-><P
->	       The name of the zone file.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN125"
-></A
-><H2
->RETURN VALUES</H2
-><P
->        <B
-CLASS="COMMAND"
->named-checkzone</B
-> returns an exit status of 1 if
+	      <code class="filename">named.conf</code>.
+          </p></dd>
+<dt><span class="term">-D</span></dt>
+<dd><p>
+	      Dump zone file in canonical format.
+	  </p></dd>
+<dt><span class="term">zonename</span></dt>
+<dd><p>
+	       The domain name of the zone being checked.
+	  </p></dd>
+<dt><span class="term">filename</span></dt>
+<dd><p>
+	       The name of the zone file.
+	  </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526187"></a><h2>RETURN VALUES</h2>
+<p>
+        <span><strong class="command">named-checkzone</strong></span> returns an exit status of 1 if
 	errors were detected and 0 otherwise.
-  </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN129"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->RFC 1035</I
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN137"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526200"></a><h2>SEE ALSO</h2>
+<p>
+      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <em class="citetitle">RFC 1035</em>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526227"></a><h2>AUTHOR</h2>
+<p>
+        <span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/dig/dig.1 b/contrib/bind9/bin/dig/dig.1
index f14d9216873b..7031217dd2bb 100644
--- a/contrib/bind9/bin/dig/dig.1
+++ b/contrib/bind9/bin/dig/dig.1
@@ -1,216 +1,244 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000-2003  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000-2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: dig.1,v 1.14.2.4.2.6 2004/06/23 09:11:01 marka Exp $
+.\" $Id: dig.1,v 1.14.2.4.2.10 2005/10/13 02:33:42 marka Exp $
 .\"
-.TH "DIG" "1" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "DIG" "1" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 dig \- DNS lookup utility
-.SH SYNOPSIS
-.sp
-\fBdig\fR [ \fB@server\fR ]  [ \fB-b \fIaddress\fB\fR ]  [ \fB-c \fIclass\fB\fR ]  [ \fB-f \fIfilename\fB\fR ]  [ \fB-k \fIfilename\fB\fR ]  [ \fB-p \fIport#\fB\fR ]  [ \fB-t \fItype\fB\fR ]  [ \fB-x \fIaddr\fB\fR ]  [ \fB-y \fIname:key\fB\fR ]  [ \fB-4\fR ]  [ \fB-6\fR ]  [ \fBname\fR ]  [ \fBtype\fR ]  [ \fBclass\fR ]  [ \fBqueryopt\fR\fI...\fR ] 
-.sp
-\fBdig\fR [ \fB-h\fR ] 
-.sp
-\fBdig\fR [ \fBglobal-queryopt\fR\fI...\fR ]  [ \fBquery\fR\fI...\fR ] 
+.SH "SYNOPSIS"
+.HP 4
+\fBdig\fR [@server] [\fB\-b\ \fR\fB\fIaddress\fR\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-f\ \fR\fB\fIfilename\fR\fR] [\fB\-k\ \fR\fB\fIfilename\fR\fR] [\fB\-p\ \fR\fB\fIport#\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-x\ \fR\fB\fIaddr\fR\fR] [\fB\-y\ \fR\fB\fIname:key\fR\fR] [\fB\-4\fR] [\fB\-6\fR] [name] [type] [class] [queryopt...]
+.HP 4
+\fBdig\fR [\fB\-h\fR]
+.HP 4
+\fBdig\fR [global\-queryopt...] [query...]
 .SH "DESCRIPTION"
 .PP
-\fBdig\fR (domain information groper) is a flexible tool
-for interrogating DNS name servers. It performs DNS lookups and
-displays the answers that are returned from the name server(s) that
-were queried. Most DNS administrators use \fBdig\fR to
-troubleshoot DNS problems because of its flexibility, ease of use and
-clarity of output. Other lookup tools tend to have less functionality
-than \fBdig\fR.
+\fBdig\fR
+(domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most DNS administrators use
+\fBdig\fR
+to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than
+\fBdig\fR.
 .PP
-Although \fBdig\fR is normally used with command-line
-arguments, it also has a batch mode of operation for reading lookup
-requests from a file. A brief summary of its command-line arguments
-and options is printed when the \fB-h\fR option is given.
-Unlike earlier versions, the BIND9 implementation of
-\fBdig\fR allows multiple lookups to be issued from the
-command line.
+Although
+\fBdig\fR
+is normally used with command\-line arguments, it also has a batch mode of operation for reading lookup requests from a file. A brief summary of its command\-line arguments and options is printed when the
+\fB\-h\fR
+option is given. Unlike earlier versions, the BIND9 implementation of
+\fBdig\fR
+allows multiple lookups to be issued from the command line.
 .PP
 Unless it is told to query a specific name server,
-\fBdig\fR will try each of the servers listed in
+\fBdig\fR
+will try each of the servers listed in
 \fI/etc/resolv.conf\fR.
 .PP
-When no command line arguments or options are given, will perform an
-NS query for "." (the root).
+When no command line arguments or options are given, will perform an NS query for "." (the root).
 .PP
-It is possible to set per-user defaults for \fBdig\fR via
-\fI${HOME}/.digrc\fR. This file is read and any options in it
-are applied before the command line arguments.
+It is possible to set per\-user defaults for
+\fBdig\fR
+via
+\fI${HOME}/.digrc\fR. This file is read and any options in it are applied before the command line arguments.
 .SH "SIMPLE USAGE"
 .PP
-A typical invocation of \fBdig\fR looks like:
+A typical invocation of
+\fBdig\fR
+looks like:
 .sp
 .nf
  dig @server name type 
-.sp
 .fi
+.sp
 where:
 .TP
 \fBserver\fR
-is the name or IP address of the name server to query. This can be an IPv4
-address in dotted-decimal notation or an IPv6
-address in colon-delimited notation. When the supplied
-\fIserver\fR argument is a hostname,
-\fBdig\fR resolves that name before querying that name
-server. If no \fIserver\fR argument is provided,
-\fBdig\fR consults \fI/etc/resolv.conf\fR
-and queries the name servers listed there. The reply from the name
-server that responds is displayed.
+is the name or IP address of the name server to query. This can be an IPv4 address in dotted\-decimal notation or an IPv6 address in colon\-delimited notation. When the supplied
+\fIserver\fR
+argument is a hostname,
+\fBdig\fR
+resolves that name before querying that name server. If no
+\fIserver\fR
+argument is provided,
+\fBdig\fR
+consults
+\fI/etc/resolv.conf\fR
+and queries the name servers listed there. The reply from the name server that responds is displayed.
 .TP
 \fBname\fR
 is the name of the resource record that is to be looked up.
 .TP
 \fBtype\fR
-indicates what type of query is required \(em
-ANY, A, MX, SIG, etc.
-\fItype\fR can be any valid query type. If no
-\fItype\fR argument is supplied,
-\fBdig\fR will perform a lookup for an A record.
+indicates what type of query is required \(em ANY, A, MX, SIG, etc.
+\fItype\fR
+can be any valid query type. If no
+\fItype\fR
+argument is supplied,
+\fBdig\fR
+will perform a lookup for an A record.
 .SH "OPTIONS"
 .PP
-The \fB-b\fR option sets the source IP address of the query
-to \fIaddress\fR. This must be a valid address on
-one of the host's network interfaces or "0.0.0.0" or "::". An optional port
-may be specified by appending "#<port>"
+The
+\fB\-b\fR
+option sets the source IP address of the query to
+\fIaddress\fR. This must be a valid address on one of the host's network interfaces or "0.0.0.0" or "::". An optional port may be specified by appending "#<port>"
 .PP
 The default query class (IN for internet) is overridden by the
-\fB-c\fR option. \fIclass\fR is any valid
-class, such as HS for Hesiod records or CH for CHAOSNET records.
+\fB\-c\fR
+option.
+\fIclass\fR
+is any valid class, such as HS for Hesiod records or CH for CHAOSNET records.
 .PP
-The \fB-f\fR option makes \fBdig \fR operate
-in batch mode by reading a list of lookup requests to process from the
-file \fIfilename\fR. The file contains a number of
-queries, one per line. Each entry in the file should be organised in
-the same way they would be presented as queries to
-\fBdig\fR using the command-line interface.
+The
+\fB\-f\fR
+option makes
+\fBdig \fR
+operate in batch mode by reading a list of lookup requests to process from the file
+\fIfilename\fR. The file contains a number of queries, one per line. Each entry in the file should be organised in the same way they would be presented as queries to
+\fBdig\fR
+using the command\-line interface.
 .PP
-If a non-standard port number is to be queried, the
-\fB-p\fR option is used. \fIport#\fR is
-the port number that \fBdig\fR will send its queries
-instead of the standard DNS port number 53. This option would be used
-to test a name server that has been configured to listen for queries
-on a non-standard port number.
+If a non\-standard port number is to be queried, the
+\fB\-p\fR
+option is used.
+\fIport#\fR
+is the port number that
+\fBdig\fR
+will send its queries instead of the standard DNS port number 53. This option would be used to test a name server that has been configured to listen for queries on a non\-standard port number.
 .PP
-The \fB-4\fR option forces \fBdig\fR to only
-use IPv4 query transport. The \fB-6\fR option forces
-\fBdig\fR to only use IPv6 query transport.
+The
+\fB\-4\fR
+option forces
+\fBdig\fR
+to only use IPv4 query transport. The
+\fB\-6\fR
+option forces
+\fBdig\fR
+to only use IPv6 query transport.
 .PP
-The \fB-t\fR option sets the query type to
-\fItype\fR. It can be any valid query type which is
-supported in BIND9. The default query type "A", unless the
-\fB-x\fR option is supplied to indicate a reverse lookup.
-A zone transfer can be requested by specifying a type of AXFR. When
-an incremental zone transfer (IXFR) is required,
-\fItype\fR is set to ixfr=N.
-The incremental zone transfer will contain the changes made to the zone
-since the serial number in the zone's SOA record was
+The
+\fB\-t\fR
+option sets the query type to
+\fItype\fR. It can be any valid query type which is supported in BIND9. The default query type "A", unless the
+\fB\-x\fR
+option is supplied to indicate a reverse lookup. A zone transfer can be requested by specifying a type of AXFR. When an incremental zone transfer (IXFR) is required,
+\fItype\fR
+is set to
+ixfr=N. The incremental zone transfer will contain the changes made to the zone since the serial number in the zone's SOA record was
 \fIN\fR.
 .PP
-Reverse lookups - mapping addresses to names - are simplified by the
-\fB-x\fR option. \fIaddr\fR is an IPv4
-address in dotted-decimal notation, or a colon-delimited IPv6 address.
-When this option is used, there is no need to provide the
-\fIname\fR, \fIclass\fR and
-\fItype\fR arguments. \fBdig\fR
+Reverse lookups \- mapping addresses to names \- are simplified by the
+\fB\-x\fR
+option.
+\fIaddr\fR
+is an IPv4 address in dotted\-decimal notation, or a colon\-delimited IPv6 address. When this option is used, there is no need to provide the
+\fIname\fR,
+\fIclass\fR
+and
+\fItype\fR
+arguments.
+\fBdig\fR
 automatically performs a lookup for a name like
-11.12.13.10.in-addr.arpa and sets the query type and
-class to PTR and IN respectively. By default, IPv6 addresses are
-looked up using nibble format under the IP6.ARPA domain.
-To use the older RFC1886 method using the IP6.INT domain 
-specify the \fB-i\fR option. Bit string labels (RFC2874)
-are now experimental and are not attempted.
+11.12.13.10.in\-addr.arpa
+and sets the query type and class to PTR and IN respectively. By default, IPv6 addresses are looked up using nibble format under the IP6.ARPA domain. To use the older RFC1886 method using the IP6.INT domain specify the
+\fB\-i\fR
+option. Bit string labels (RFC2874) are now experimental and are not attempted.
 .PP
-To sign the DNS queries sent by \fBdig\fR and their
-responses using transaction signatures (TSIG), specify a TSIG key file
-using the \fB-k\fR option. You can also specify the TSIG
-key itself on the command line using the \fB-y\fR option;
-\fIname\fR is the name of the TSIG key and
-\fIkey\fR is the actual key. The key is a base-64
-encoded string, typically generated by \fBdnssec-keygen\fR(8).
-Caution should be taken when using the \fB-y\fR option on
-multi-user systems as the key can be visible in the output from
-\fBps\fR(1) or in the shell's history file. When
-using TSIG authentication with \fBdig\fR, the name
-server that is queried needs to know the key and algorithm that is
-being used. In BIND, this is done by providing appropriate
-\fBkey\fR and \fBserver\fR statements in
+To sign the DNS queries sent by
+\fBdig\fR
+and their responses using transaction signatures (TSIG), specify a TSIG key file using the
+\fB\-k\fR
+option. You can also specify the TSIG key itself on the command line using the
+\fB\-y\fR
+option;
+\fIname\fR
+is the name of the TSIG key and
+\fIkey\fR
+is the actual key. The key is a base\-64 encoded string, typically generated by
+\fBdnssec\-keygen\fR(8). Caution should be taken when using the
+\fB\-y\fR
+option on multi\-user systems as the key can be visible in the output from
+\fBps\fR(1 )
+or in the shell's history file. When using TSIG authentication with
+\fBdig\fR, the name server that is queried needs to know the key and algorithm that is being used. In BIND, this is done by providing appropriate
+\fBkey\fR
+and
+\fBserver\fR
+statements in
 \fInamed.conf\fR.
 .SH "QUERY OPTIONS"
 .PP
-\fBdig\fR provides a number of query options which affect
-the way in which lookups are made and the results displayed. Some of
-these set or reset flag bits in the query header, some determine which
-sections of the answer get printed, and others determine the timeout
-and retry strategies.
+\fBdig\fR
+provides a number of query options which affect the way in which lookups are made and the results displayed. Some of these set or reset flag bits in the query header, some determine which sections of the answer get printed, and others determine the timeout and retry strategies.
 .PP
-Each query option is identified by a keyword preceded by a plus sign
-(+). Some keywords set or reset an option. These may be preceded
-by the string no to negate the meaning of that keyword. Other
-keywords assign values to options like the timeout interval. They
-have the form \fB+keyword=value\fR.
-The query options are:
+Each query option is identified by a keyword preceded by a plus sign (+). Some keywords set or reset an option. These may be preceded by the string
+no
+to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They have the form
+\fB+keyword=value\fR. The query options are:
 .TP
 \fB+[no]tcp\fR
-Use [do not use] TCP when querying name servers. The default
-behaviour is to use UDP unless an AXFR or IXFR query is requested, in
-which case a TCP connection is used.
+Use [do not use] TCP when querying name servers. The default behaviour is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP connection is used.
 .TP
 \fB+[no]vc\fR
-Use [do not use] TCP when querying name servers. This alternate
-syntax to \fI+[no]tcp\fR is provided for backwards
-compatibility. The "vc" stands for "virtual circuit".
+Use [do not use] TCP when querying name servers. This alternate syntax to
+\fI+[no]tcp\fR
+is provided for backwards compatibility. The "vc" stands for "virtual circuit".
 .TP
 \fB+[no]ignore\fR
-Ignore truncation in UDP responses instead of retrying with TCP. By
-default, TCP retries are performed.
+Ignore truncation in UDP responses instead of retrying with TCP. By default, TCP retries are performed.
 .TP
 \fB+domain=somename\fR
 Set the search list to contain the single domain
 \fIsomename\fR, as if specified in a
-\fBdomain\fR directive in
-\fI/etc/resolv.conf\fR, and enable search list
-processing as if the \fI+search\fR option were given.
+\fBdomain\fR
+directive in
+\fI/etc/resolv.conf\fR, and enable search list processing as if the
+\fI+search\fR
+option were given.
 .TP
 \fB+[no]search\fR
-Use [do not use] the search list defined by the searchlist or domain
-directive in \fIresolv.conf\fR (if any).
-The search list is not used by default.
+Use [do not use] the search list defined by the searchlist or domain directive in
+\fIresolv.conf\fR
+(if any). The search list is not used by default.
 .TP
 \fB+[no]defname\fR
-Deprecated, treated as a synonym for \fI+[no]search\fR
+Deprecated, treated as a synonym for
+\fI+[no]search\fR
 .TP
 \fB+[no]aaonly\fR
 Sets the "aa" flag in the query.
 .TP
 \fB+[no]aaflag\fR
-A synonym for \fI+[no]aaonly\fR.
+A synonym for
+\fI+[no]aaonly\fR.
 .TP
 \fB+[no]adflag\fR
-Set [do not set] the AD (authentic data) bit in the query. The AD bit
-currently has a standard meaning only in responses, not in queries,
-but the ability to set the bit in the query is provided for
-completeness.
+Set [do not set] the AD (authentic data) bit in the query. The AD bit currently has a standard meaning only in responses, not in queries, but the ability to set the bit in the query is provided for completeness.
 .TP
 \fB+[no]cdflag\fR
-Set [do not set] the CD (checking disabled) bit in the query. This
-requests the server to not perform DNSSEC validation of responses.
+Set [do not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.
 .TP
 \fB+[no]cl\fR
 Display [do not display] the CLASS when printing the record.
@@ -219,170 +247,164 @@ Display [do not display] the CLASS when printing the record.
 Display [do not display] the TTL when printing the record.
 .TP
 \fB+[no]recurse\fR
-Toggle the setting of the RD (recursion desired) bit in the query.
-This bit is set by default, which means \fBdig\fR
-normally sends recursive queries. Recursion is automatically disabled
-when the \fI+nssearch\fR or
-\fI+trace\fR query options are used.
+Toggle the setting of the RD (recursion desired) bit in the query. This bit is set by default, which means
+\fBdig\fR
+normally sends recursive queries. Recursion is automatically disabled when the
+\fI+nssearch\fR
+or
+\fI+trace\fR
+query options are used.
 .TP
 \fB+[no]nssearch\fR
-When this option is set, \fBdig\fR attempts to find the
-authoritative name servers for the zone containing the name being
-looked up and display the SOA record that each name server has for the
-zone.
+When this option is set,
+\fBdig\fR
+attempts to find the authoritative name servers for the zone containing the name being looked up and display the SOA record that each name server has for the zone.
 .TP
 \fB+[no]trace\fR
-Toggle tracing of the delegation path from the root name servers for
-the name being looked up. Tracing is disabled by default. When
-tracing is enabled, \fBdig\fR makes iterative queries to
-resolve the name being looked up. It will follow referrals from the
-root servers, showing the answer from each server that was used to
-resolve the lookup.
+Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled,
+\fBdig\fR
+makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup.
 .TP
 \fB+[no]cmd\fR
-toggles the printing of the initial comment in the output identifying
-the version of \fBdig\fR and the query options that have
-been applied. This comment is printed by default.
+toggles the printing of the initial comment in the output identifying the version of
+\fBdig\fR
+and the query options that have been applied. This comment is printed by default.
 .TP
 \fB+[no]short\fR
-Provide a terse answer. The default is to print the answer in a
-verbose form.
+Provide a terse answer. The default is to print the answer in a verbose form.
 .TP
 \fB+[no]identify\fR
-Show [or do not show] the IP address and port number that supplied the
-answer when the \fI+short\fR option is enabled. If
-short form answers are requested, the default is not to show the
-source address and port number of the server that provided the answer.
+Show [or do not show] the IP address and port number that supplied the answer when the
+\fI+short\fR
+option is enabled. If short form answers are requested, the default is not to show the source address and port number of the server that provided the answer.
 .TP
 \fB+[no]comments\fR
-Toggle the display of comment lines in the output. The default is to
-print comments.
+Toggle the display of comment lines in the output. The default is to print comments.
 .TP
 \fB+[no]stats\fR
-This query option toggles the printing of statistics: when the query
-was made, the size of the reply and so on. The default behaviour is
-to print the query statistics.
+This query option toggles the printing of statistics: when the query was made, the size of the reply and so on. The default behaviour is to print the query statistics.
 .TP
 \fB+[no]qr\fR
-Print [do not print] the query as it is sent.
-By default, the query is not printed.
+Print [do not print] the query as it is sent. By default, the query is not printed.
 .TP
 \fB+[no]question\fR
-Print [do not print] the question section of a query when an answer is
-returned. The default is to print the question section as a comment.
+Print [do not print] the question section of a query when an answer is returned. The default is to print the question section as a comment.
 .TP
 \fB+[no]answer\fR
-Display [do not display] the answer section of a reply. The default
-is to display it.
+Display [do not display] the answer section of a reply. The default is to display it.
 .TP
 \fB+[no]authority\fR
-Display [do not display] the authority section of a reply. The
-default is to display it.
+Display [do not display] the authority section of a reply. The default is to display it.
 .TP
 \fB+[no]additional\fR
-Display [do not display] the additional section of a reply.
-The default is to display it.
+Display [do not display] the additional section of a reply. The default is to display it.
 .TP
 \fB+[no]all\fR
 Set or clear all display flags.
 .TP
 \fB+time=T\fR
 Sets the timeout for a query to
-\fIT\fR seconds. The default time out is 5 seconds.
-An attempt to set \fIT\fR to less than 1 will result
-in a query timeout of 1 second being applied.
+\fIT\fR
+seconds. The default time out is 5 seconds. An attempt to set
+\fIT\fR
+to less than 1 will result in a query timeout of 1 second being applied.
 .TP
 \fB+tries=T\fR
 Sets the number of times to try UDP queries to server to
-\fIT\fR instead of the default, 3. If
-\fIT\fR is less than or equal to zero, the number of
-tries is silently rounded up to 1.
+\fIT\fR
+instead of the default, 3. If
+\fIT\fR
+is less than or equal to zero, the number of tries is silently rounded up to 1.
 .TP
 \fB+retry=T\fR
 Sets the number of times to retry UDP queries to server to
-\fIT\fR instead of the default, 2. Unlike
-\fI+tries\fR, this does not include the initial
-query.
+\fIT\fR
+instead of the default, 2. Unlike
+\fI+tries\fR, this does not include the initial query.
 .TP
 \fB+ndots=D\fR
 Set the number of dots that have to appear in
-\fIname\fR to \fID\fR for it to be
-considered absolute. The default value is that defined using the
-ndots statement in \fI/etc/resolv.conf\fR, or 1 if no
-ndots statement is present. Names with fewer dots are interpreted as
-relative names and will be searched for in the domains listed in the
-\fBsearch\fR or \fBdomain\fR directive in
+\fIname\fR
+to
+\fID\fR
+for it to be considered absolute. The default value is that defined using the ndots statement in
+\fI/etc/resolv.conf\fR, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the
+\fBsearch\fR
+or
+\fBdomain\fR
+directive in
 \fI/etc/resolv.conf\fR.
 .TP
 \fB+bufsize=B\fR
 Set the UDP message buffer size advertised using EDNS0 to
-\fIB\fR bytes. The maximum and minimum sizes of this
-buffer are 65535 and 0 respectively. Values outside this range are
-rounded up or down appropriately.
+\fIB\fR
+bytes. The maximum and minimum sizes of this buffer are 65535 and 0 respectively. Values outside this range are rounded up or down appropriately.
 .TP
 \fB+[no]multiline\fR
-Print records like the SOA records in a verbose multi-line
-format with human-readable comments. The default is to print
-each record on a single line, to facilitate machine parsing 
-of the \fBdig\fR output.
+Print records like the SOA records in a verbose multi\-line format with human\-readable comments. The default is to print each record on a single line, to facilitate machine parsing of the
+\fBdig\fR
+output.
 .TP
 \fB+[no]fail\fR
-Do not try the next server if you receive a SERVFAIL. The default is
-to not try the next server which is the reverse of normal stub resolver
-behaviour.
+Do not try the next server if you receive a SERVFAIL. The default is to not try the next server which is the reverse of normal stub resolver behaviour.
 .TP
 \fB+[no]besteffort\fR
-Attempt to display the contents of messages which are malformed.
-The default is to not display malformed answers.
+Attempt to display the contents of messages which are malformed. The default is to not display malformed answers.
 .TP
 \fB+[no]dnssec\fR
-Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO)
-in the OPT record in the additional section of the query.
+Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional section of the query.
 .TP
 \fB+[no]sigchase\fR
-Chase DNSSEC signature chains. Requires dig be compiled with
--DDIG_SIGCHASE.
+Chase DNSSEC signature chains. Requires dig be compiled with \-DDIG_SIGCHASE.
 .TP
-\fB+trusted-key=####\fR
-Specify a trusted key to be used with \fB+sigchase\fR.
-Requires dig be compiled with -DDIG_SIGCHASE.
+\fB+trusted\-key=####\fR
+Specifies a file containing trusted keys to be used with
+\fB+sigchase\fR. Each DNSKEY record must be on its own line.
+.sp
+If not specified
+\fBdig\fR
+will look for
+\fI/etc/trusted\-key.key\fR
+then
+\fItrusted\-key.key\fR
+in the current directory.
+.sp
+Requires dig be compiled with \-DDIG_SIGCHASE.
 .TP
 \fB+[no]topdown\fR
-When chasing DNSSEC signature chains perform a top down validation.
-Requires dig be compiled with -DDIG_SIGCHASE.
+When chasing DNSSEC signature chains perform a top down validation. Requires dig be compiled with \-DDIG_SIGCHASE.
 .SH "MULTIPLE QUERIES"
 .PP
-The BIND 9 implementation of \fBdig \fR supports
-specifying multiple queries on the command line (in addition to
-supporting the \fB-f\fR batch file option). Each of those
-queries can be supplied with its own set of flags, options and query
-options.
+The BIND 9 implementation of
+\fBdig \fR
+supports specifying multiple queries on the command line (in addition to supporting the
+\fB\-f\fR
+batch file option). Each of those queries can be supplied with its own set of flags, options and query options.
 .PP
-In this case, each \fIquery\fR argument represent an
-individual query in the command-line syntax described above. Each
-consists of any of the standard options and flags, the name to be
-looked up, an optional query type and class and any query options that
-should be applied to that query.
+In this case, each
+\fIquery\fR
+argument represent an individual query in the command\-line syntax described above. Each consists of any of the standard options and flags, the name to be looked up, an optional query type and class and any query options that should be applied to that query.
 .PP
-A global set of query options, which should be applied to all queries,
-can also be supplied. These global query options must precede the
-first tuple of name, class, type, options, flags, and query options
-supplied on the command line. Any global query options (except
-the \fB+[no]cmd\fR option) can be
-overridden by a query-specific set of query options. For example:
+A global set of query options, which should be applied to all queries, can also be supplied. These global query options must precede the first tuple of name, class, type, options, flags, and query options supplied on the command line. Any global query options (except the
+\fB+[no]cmd\fR
+option) can be overridden by a query\-specific set of query options. For example:
 .sp
 .nf
-dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
-.sp
+dig +qr www.isc.org any \-x 127.0.0.1 isc.org ns +noqr
 .fi
-shows how \fBdig\fR could be used from the command line
-to make three lookups: an ANY query for www.isc.org, a
-reverse lookup of 127.0.0.1 and a query for the NS records of
-isc.org.
-A global query option of \fI+qr\fR is applied, so
-that \fBdig\fR shows the initial query it made for each
-lookup. The final query has a local query option of
-\fI+noqr\fR which means that \fBdig\fR
+.sp
+shows how
+\fBdig\fR
+could be used from the command line to make three lookups: an ANY query for
+www.isc.org, a reverse lookup of 127.0.0.1 and a query for the NS records of
+isc.org. A global query option of
+\fI+qr\fR
+is applied, so that
+\fBdig\fR
+shows the initial query it made for each lookup. The final query has a local query option of
+\fI+noqr\fR
+which means that
+\fBdig\fR
 will not print the initial query when it looks up the NS records for
 isc.org.
 .SH "FILES"
@@ -394,8 +416,8 @@ isc.org.
 .PP
 \fBhost\fR(1),
 \fBnamed\fR(8),
-\fBdnssec-keygen\fR(8),
-\fIRFC1035\fR.
-.SH "BUGS"
+\fBdnssec\-keygen\fR(8),
+RFC1035.
+.SH "BUGS "
 .PP
-There are probably too many query options. 
+There are probably too many query options.
diff --git a/contrib/bind9/bin/dig/dig.c b/contrib/bind9/bin/dig/dig.c
index 08f5b5b52802..52df6608685b 100644
--- a/contrib/bind9/bin/dig/dig.c
+++ b/contrib/bind9/bin/dig/dig.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dig.c,v 1.157.2.13.2.25 2004/09/16 02:14:14 marka Exp $ */
+/* $Id: dig.c,v 1.157.2.13.2.29 2005/10/14 01:38:40 marka Exp $ */
 
 #include <config.h>
 #include <stdlib.h>
@@ -45,10 +45,6 @@
 
 #include <dig/dig.h>
 
-extern ISC_LIST(dig_lookup_t) lookup_list;
-extern dig_serverlist_t server_list;
-extern ISC_LIST(dig_searchlist_t) search_list;
-
 #define ADD_STRING(b, s) { 				\
 	if (strlen(s) >= isc_buffer_availablelength(b)) \
  		return (ISC_R_NOSPACE); 		\
@@ -58,31 +54,8 @@ extern ISC_LIST(dig_searchlist_t) search_list;
 
 #define DIG_MAX_ADDRESSES 20
 
-extern isc_boolean_t have_ipv4, have_ipv6, specified_source,
-	usesearch, qr;
-extern in_port_t port;
-extern unsigned int timeout;
-extern isc_mem_t *mctx;
-extern dns_messageid_t id;
-extern int sendcount;
-extern int ndots;
-extern int lookup_counter;
-extern int exitcode;
-extern isc_sockaddr_t bind_address;
-extern char keynametext[MXNAME];
-extern char keyfile[MXNAME];
-extern char keysecret[MXNAME];
-#ifdef DIG_SIGCHASE
-extern char trustedkey[MXNAME];
-#endif
-extern dns_tsigkey_t *key;
-extern isc_boolean_t validated;
-extern isc_taskmgr_t *taskmgr;
-extern isc_task_t *global_task;
-extern isc_boolean_t free_now;
 dig_lookup_t *default_lookup = NULL;
 
-extern isc_boolean_t debugging, memdebugging;
 static char *batchname = NULL;
 static FILE *batchfp = NULL;
 static char *argv0;
@@ -133,8 +106,6 @@ static const char *rcodetext[] = {
 	"BADVERS"
 };
 
-extern char *progname;
-
 static void
 print_usage(FILE *fp) {
 	fputs(
@@ -593,6 +564,7 @@ buftoosmall:
 			}
 		}
 	}
+
 	if (headers && query->lookup->comments && !short_form)
 		printf("\n");
 
@@ -818,7 +790,7 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 			break;
 		case 'l': /* cl */
 			FULLCHECK("cl");
-			noclass = !state;
+			noclass = ISC_TF(!state);
 			break;
 		case 'm': /* cmd */
 			FULLCHECK("cmd");
@@ -892,7 +864,7 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 			lookup->ns_search_only = state;
 			if (state) {
 				lookup->trace_root = ISC_TRUE;
-				lookup->recurse = ISC_FALSE;
+				lookup->recurse = ISC_TRUE;
 				lookup->identify = ISC_TRUE;
 				lookup->stats = ISC_FALSE;
 				lookup->comments = ISC_FALSE;
@@ -1054,7 +1026,7 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 			break;
 		case 't': /* ttlid */
 			FULLCHECK("ttlid");
-			nottl = !state;
+			nottl = ISC_TF(!state);
 			break;
 		default:
 			goto invalid_option;
diff --git a/contrib/bind9/bin/dig/dig.docbook b/contrib/bind9/bin/dig/dig.docbook
index d22ae87064d0..87c98ae7b1f0 100644
--- a/contrib/bind9/bin/dig/dig.docbook
+++ b/contrib/bind9/bin/dig/dig.docbook
@@ -1,6 +1,8 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: dig.docbook,v 1.4.2.7.4.9 2004/06/23 04:19:41 marka Exp $ -->
+<!-- $Id: dig.docbook,v 1.4.2.7.4.12 2005/08/30 00:50:29 marka Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,21 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>dig</refname>
 <refpurpose>DNS lookup utility</refpurpose>
@@ -38,7 +55,7 @@
 <refsynopsisdiv>
 <cmdsynopsis>
 <command>dig</command>
-<arg choice=opt>@server</arg>
+<arg choice="opt">@server</arg>
 <arg><option>-b <replaceable class="parameter">address</replaceable></option></arg>
 <arg><option>-c <replaceable class="parameter">class</replaceable></option></arg>
 <arg><option>-f <replaceable class="parameter">filename</replaceable></option></arg>
@@ -49,10 +66,10 @@
 <arg><option>-y <replaceable class="parameter">name:key</replaceable></option></arg>
 <arg><option>-4</option></arg>
 <arg><option>-6</option></arg>
-<arg choice=opt>name</arg>
-<arg choice=opt>type</arg>
-<arg choice=opt>class</arg>
-<arg choice=opt rep=repeat>queryopt</arg>
+<arg choice="opt">name</arg>
+<arg choice="opt">type</arg>
+<arg choice="opt">class</arg>
+<arg choice="opt" rep="repeat">queryopt</arg>
 </cmdsynopsis>
 
 <cmdsynopsis>
@@ -62,8 +79,8 @@
 
 <cmdsynopsis>
 <command>dig</command>
-<arg choice=opt rep=repeat>global-queryopt</arg>
-<arg choice=opt rep=repeat>query</arg>
+<arg choice="opt" rep="repeat">global-queryopt</arg>
+<arg choice="opt" rep="repeat">query</arg>
 </cmdsynopsis>
 </refsynopsisdiv>
 
@@ -513,11 +530,24 @@ Chase DNSSEC signature chains.  Requires dig be compiled with
 -DDIG_SIGCHASE.
 </para></listitem></varlistentry>
 
-<varlistentry><term><option>+trusted-key=####</option></term>
-<listitem><para>
-Specify a trusted key to be used with <option>+sigchase</option>.
-Requires dig be compiled with -DDIG_SIGCHASE.
-</para></listitem></varlistentry>
+	<varlistentry>
+	  <term><option>+trusted-key=####</option></term>
+	  <listitem>
+	    <para>
+	      Specifies a file containing trusted keys to be used with
+	      <option>+sigchase</option>.  Each DNSKEY record must be
+	      on its own line.
+	    </para>
+	    <para>
+	      If not specified <command>dig</command> will look for
+	      <filename>/etc/trusted-key.key</filename> then
+	      <filename>trusted-key.key</filename> in the current directory.
+	    </para>
+	    <para>
+	      Requires dig be compiled with -DDIG_SIGCHASE.
+	    </para>
+	  </listitem>
+	</varlistentry>
 
 <varlistentry><term><option>+[no]topdown</option></term>
 <listitem><para>
diff --git a/contrib/bind9/bin/dig/dig.html b/contrib/bind9/bin/dig/dig.html
index e9e1fd4dc770..3425fb3d21b2 100644
--- a/contrib/bind9/bin/dig/dig.html
+++ b/contrib/bind9/bin/dig/dig.html
@@ -1,1174 +1,514 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2003  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: dig.html,v 1.6.2.4.2.7 2004/08/22 23:38:57 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->dig</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->dig</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->dig&nbsp;--&nbsp;DNS lookup utility</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN11"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->dig</B
->  [@server] [<VAR
-CLASS="OPTION"
->-b <VAR
-CLASS="REPLACEABLE"
->address</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-c <VAR
-CLASS="REPLACEABLE"
->class</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-f <VAR
-CLASS="REPLACEABLE"
->filename</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-k <VAR
-CLASS="REPLACEABLE"
->filename</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-p <VAR
-CLASS="REPLACEABLE"
->port#</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->type</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-x <VAR
-CLASS="REPLACEABLE"
->addr</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-y <VAR
-CLASS="REPLACEABLE"
->name:key</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-4</VAR
->] [<VAR
-CLASS="OPTION"
->-6</VAR
->] [name] [type] [class] [queryopt...]</P
-><P
-><B
-CLASS="COMMAND"
->dig</B
->  [<VAR
-CLASS="OPTION"
->-h</VAR
->]</P
-><P
-><B
-CLASS="COMMAND"
->dig</B
->  [global-queryopt...] [query...]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN55"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><B
-CLASS="COMMAND"
->dig</B
-> (domain information groper) is a flexible tool
+<!-- $Id: dig.html,v 1.6.2.4.2.13 2005/10/13 02:33:43 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dig</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>dig &#8212; DNS lookup utility</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dig</code>  [@server] [<code class="option">-b <em class="replaceable"><code>address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-f <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-k <em class="replaceable"><code>filename</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port#</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-x <em class="replaceable"><code>addr</code></em></code>] [<code class="option">-y <em class="replaceable"><code>name:key</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] [name] [type] [class] [queryopt...]</p></div>
+<div class="cmdsynopsis"><p><code class="command">dig</code>  [<code class="option">-h</code>]</p></div>
+<div class="cmdsynopsis"><p><code class="command">dig</code>  [global-queryopt...] [query...]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525976"></a><h2>DESCRIPTION</h2>
+<p>
+<span><strong class="command">dig</strong></span> (domain information groper) is a flexible tool
 for interrogating DNS name servers.  It performs DNS lookups and
 displays the answers that are returned from the name server(s) that
-were queried.  Most DNS administrators use <B
-CLASS="COMMAND"
->dig</B
-> to
+were queried.  Most DNS administrators use <span><strong class="command">dig</strong></span> to
 troubleshoot DNS problems because of its flexibility, ease of use and
 clarity of output.  Other lookup tools tend to have less functionality
-than <B
-CLASS="COMMAND"
->dig</B
->.</P
-><P
->Although <B
-CLASS="COMMAND"
->dig</B
-> is normally used with command-line
+than <span><strong class="command">dig</strong></span>.
+</p>
+<p>
+Although <span><strong class="command">dig</strong></span> is normally used with command-line
 arguments, it also has a batch mode of operation for reading lookup
 requests from a file.  A brief summary of its command-line arguments
-and options is printed when the <VAR
-CLASS="OPTION"
->-h</VAR
-> option is given.
+and options is printed when the <code class="option">-h</code> option is given.
 Unlike earlier versions, the BIND9 implementation of
-<B
-CLASS="COMMAND"
->dig</B
-> allows multiple lookups to be issued from the
-command line.</P
-><P
->Unless it is told to query a specific name server,
-<B
-CLASS="COMMAND"
->dig</B
-> will try each of the servers listed in
-<TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->.</P
-><P
->When no command line arguments or options are given, will perform an
-NS query for "." (the root).</P
-><P
->It is possible to set per-user defaults for <B
-CLASS="COMMAND"
->dig</B
-> via
-<TT
-CLASS="FILENAME"
->${HOME}/.digrc</TT
->.  This file is read and any options in it
-are applied before the command line arguments.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN72"
-></A
-><H2
->SIMPLE USAGE</H2
-><P
->A typical invocation of <B
-CLASS="COMMAND"
->dig</B
-> looks like:
-<PRE
-CLASS="PROGRAMLISTING"
-> dig @server name type </PRE
-> where:
+<span><strong class="command">dig</strong></span> allows multiple lookups to be issued from the
+command line.
+</p>
+<p>
+Unless it is told to query a specific name server,
+<span><strong class="command">dig</strong></span> will try each of the servers listed in
+<code class="filename">/etc/resolv.conf</code>.
+</p>
+<p>
+When no command line arguments or options are given, will perform an
+NS query for "." (the root).
+</p>
+<p>
+It is possible to set per-user defaults for <span><strong class="command">dig</strong></span> via
+<code class="filename">${HOME}/.digrc</code>.  This file is read and any options in it
+are applied before the command line arguments.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526035"></a><h2>SIMPLE USAGE</h2>
+<p>
+A typical invocation of <span><strong class="command">dig</strong></span> looks like:
+</p>
+<pre class="programlisting"> dig @server name type </pre>
+<p> where:
 
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->server</CODE
-></DT
-><DD
-><P
->is the name or IP address of the name server to query.  This can be an IPv4
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">server</code></span></dt>
+<dd><p>
+is the name or IP address of the name server to query.  This can be an IPv4
 address in dotted-decimal notation or an IPv6
 address in colon-delimited notation.  When the supplied
-<VAR
-CLASS="PARAMETER"
->server</VAR
-> argument is a hostname,
-<B
-CLASS="COMMAND"
->dig</B
-> resolves that name before querying that name
-server.  If no <VAR
-CLASS="PARAMETER"
->server</VAR
-> argument is provided,
-<B
-CLASS="COMMAND"
->dig</B
-> consults <TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->
+<em class="parameter"><code>server</code></em> argument is a hostname,
+<span><strong class="command">dig</strong></span> resolves that name before querying that name
+server.  If no <em class="parameter"><code>server</code></em> argument is provided,
+<span><strong class="command">dig</strong></span> consults <code class="filename">/etc/resolv.conf</code>
 and queries the name servers listed there.  The reply from the name
-server that responds is displayed.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->name</CODE
-></DT
-><DD
-><P
->is the name of the resource record that is to be looked up.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->type</CODE
-></DT
-><DD
-><P
->indicates what type of query is required &mdash;
+server that responds is displayed.
+</p></dd>
+<dt><span class="term"><code class="constant">name</code></span></dt>
+<dd><p>
+is the name of the resource record that is to be looked up.
+</p></dd>
+<dt><span class="term"><code class="constant">type</code></span></dt>
+<dd><p>
+indicates what type of query is required &#8212;
 ANY, A, MX, SIG, etc.
-<VAR
-CLASS="PARAMETER"
->type</VAR
-> can be any valid query type.  If no
-<VAR
-CLASS="PARAMETER"
->type</VAR
-> argument is supplied,
-<B
-CLASS="COMMAND"
->dig</B
-> will perform a lookup for an A record.</P
-></DD
-></DL
-></DIV
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN101"
-></A
-><H2
->OPTIONS</H2
-><P
->The <VAR
-CLASS="OPTION"
->-b</VAR
-> option sets the source IP address of the query
-to <VAR
-CLASS="PARAMETER"
->address</VAR
->.  This must be a valid address on
+<em class="parameter"><code>type</code></em> can be any valid query type.  If no
+<em class="parameter"><code>type</code></em> argument is supplied,
+<span><strong class="command">dig</strong></span> will perform a lookup for an A record.
+</p></dd>
+</dl></div>
+<p>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526114"></a><h2>OPTIONS</h2>
+<p>
+The <code class="option">-b</code> option sets the source IP address of the query
+to <em class="parameter"><code>address</code></em>.  This must be a valid address on
 one of the host's network interfaces or "0.0.0.0" or "::".  An optional port
-may be specified by appending "#&lt;port&gt;"</P
-><P
->The default query class (IN for internet) is overridden by the
-<VAR
-CLASS="OPTION"
->-c</VAR
-> option.  <VAR
-CLASS="PARAMETER"
->class</VAR
-> is any valid
-class, such as HS for Hesiod records or CH for CHAOSNET records.</P
-><P
->The <VAR
-CLASS="OPTION"
->-f</VAR
-> option makes <B
-CLASS="COMMAND"
->dig </B
-> operate
+may be specified by appending "#&lt;port&gt;"
+</p>
+<p>
+The default query class (IN for internet) is overridden by the
+<code class="option">-c</code> option.  <em class="parameter"><code>class</code></em> is any valid
+class, such as HS for Hesiod records or CH for CHAOSNET records.
+</p>
+<p>
+The <code class="option">-f</code> option makes <span><strong class="command">dig </strong></span> operate
 in batch mode by reading a list of lookup requests to process from the
-file <VAR
-CLASS="PARAMETER"
->filename</VAR
->.  The file contains a number of
+file <em class="parameter"><code>filename</code></em>.  The file contains a number of
 queries, one per line.  Each entry in the file should be organised in
 the same way they would be presented as queries to
-<B
-CLASS="COMMAND"
->dig</B
-> using the command-line interface.</P
-><P
->If a non-standard port number is to be queried, the
-<VAR
-CLASS="OPTION"
->-p</VAR
-> option is used.  <VAR
-CLASS="PARAMETER"
->port#</VAR
-> is
-the port number that <B
-CLASS="COMMAND"
->dig</B
-> will send its queries
+<span><strong class="command">dig</strong></span> using the command-line interface.
+</p>
+<p>
+If a non-standard port number is to be queried, the
+<code class="option">-p</code> option is used.  <em class="parameter"><code>port#</code></em> is
+the port number that <span><strong class="command">dig</strong></span> will send its queries
 instead of the standard DNS port number 53.  This option would be used
 to test a name server that has been configured to listen for queries
-on a non-standard port number.</P
-><P
->The <VAR
-CLASS="OPTION"
->-4</VAR
-> option forces <B
-CLASS="COMMAND"
->dig</B
-> to only
-use IPv4 query transport.  The <VAR
-CLASS="OPTION"
->-6</VAR
-> option forces
-<B
-CLASS="COMMAND"
->dig</B
-> to only use IPv6 query transport.</P
-><P
->The <VAR
-CLASS="OPTION"
->-t</VAR
-> option sets the query type to
-<VAR
-CLASS="PARAMETER"
->type</VAR
->.  It can be any valid query type which is
+on a non-standard port number.
+</p>
+<p>
+The <code class="option">-4</code> option forces <span><strong class="command">dig</strong></span> to only
+use IPv4 query transport.  The <code class="option">-6</code> option forces
+<span><strong class="command">dig</strong></span> to only use IPv6 query transport.
+</p>
+<p>
+The <code class="option">-t</code> option sets the query type to
+<em class="parameter"><code>type</code></em>.  It can be any valid query type which is
 supported in BIND9.  The default query type "A", unless the
-<VAR
-CLASS="OPTION"
->-x</VAR
-> option is supplied to indicate a reverse lookup.
+<code class="option">-x</code> option is supplied to indicate a reverse lookup.
 A zone transfer can be requested by specifying a type of AXFR.  When
 an incremental zone transfer (IXFR) is required,
-<VAR
-CLASS="PARAMETER"
->type</VAR
-> is set to <VAR
-CLASS="LITERAL"
->ixfr=N</VAR
->.
+<em class="parameter"><code>type</code></em> is set to <code class="literal">ixfr=N</code>.
 The incremental zone transfer will contain the changes made to the zone
 since the serial number in the zone's SOA record was
-<VAR
-CLASS="PARAMETER"
->N</VAR
->.</P
-><P
->Reverse lookups - mapping addresses to names - are simplified by the
-<VAR
-CLASS="OPTION"
->-x</VAR
-> option.  <VAR
-CLASS="PARAMETER"
->addr</VAR
-> is an IPv4
+<em class="parameter"><code>N</code></em>.
+</p>
+<p>
+Reverse lookups - mapping addresses to names - are simplified by the
+<code class="option">-x</code> option.  <em class="parameter"><code>addr</code></em> is an IPv4
 address in dotted-decimal notation, or a colon-delimited IPv6 address.
 When this option is used, there is no need to provide the
-<VAR
-CLASS="PARAMETER"
->name</VAR
->, <VAR
-CLASS="PARAMETER"
->class</VAR
-> and
-<VAR
-CLASS="PARAMETER"
->type</VAR
-> arguments.  <B
-CLASS="COMMAND"
->dig</B
->
+<em class="parameter"><code>name</code></em>, <em class="parameter"><code>class</code></em> and
+<em class="parameter"><code>type</code></em> arguments.  <span><strong class="command">dig</strong></span>
 automatically performs a lookup for a name like
-<VAR
-CLASS="LITERAL"
->11.12.13.10.in-addr.arpa</VAR
-> and sets the query type and
+<code class="literal">11.12.13.10.in-addr.arpa</code> and sets the query type and
 class to PTR and IN respectively.  By default, IPv6 addresses are
 looked up using nibble format under the IP6.ARPA domain.
 To use the older RFC1886 method using the IP6.INT domain 
-specify the <VAR
-CLASS="OPTION"
->-i</VAR
-> option.  Bit string labels (RFC2874)
-are now experimental and are not attempted.</P
-><P
->To sign the DNS queries sent by <B
-CLASS="COMMAND"
->dig</B
-> and their
+specify the <code class="option">-i</code> option.  Bit string labels (RFC2874)
+are now experimental and are not attempted.
+</p>
+<p>
+To sign the DNS queries sent by <span><strong class="command">dig</strong></span> and their
 responses using transaction signatures (TSIG), specify a TSIG key file
-using the <VAR
-CLASS="OPTION"
->-k</VAR
-> option.  You can also specify the TSIG
-key itself on the command line using the <VAR
-CLASS="OPTION"
->-y</VAR
-> option;
-<VAR
-CLASS="PARAMETER"
->name</VAR
-> is the name of the TSIG key and
-<VAR
-CLASS="PARAMETER"
->key</VAR
-> is the actual key.  The key is a base-64
-encoded string, typically generated by <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->.
+using the <code class="option">-k</code> option.  You can also specify the TSIG
+key itself on the command line using the <code class="option">-y</code> option;
+<em class="parameter"><code>name</code></em> is the name of the TSIG key and
+<em class="parameter"><code>key</code></em> is the actual key.  The key is a base-64
+encoded string, typically generated by <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>.
 
-Caution should be taken when using the <VAR
-CLASS="OPTION"
->-y</VAR
-> option on
+Caution should be taken when using the <code class="option">-y</code> option on
 multi-user systems as the key can be visible in the output from
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->ps</SPAN
->(1)</SPAN
-> or in the shell's history file.  When
-using TSIG authentication with <B
-CLASS="COMMAND"
->dig</B
->, the name
+<span class="citerefentry"><span class="refentrytitle">ps</span>(1
+)</span> or in the shell's history file.  When
+using TSIG authentication with <span><strong class="command">dig</strong></span>, the name
 server that is queried needs to know the key and algorithm that is
 being used.  In BIND, this is done by providing appropriate
-<B
-CLASS="COMMAND"
->key</B
-> and <B
-CLASS="COMMAND"
->server</B
-> statements in
-<TT
-CLASS="FILENAME"
->named.conf</TT
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN156"
-></A
-><H2
->QUERY OPTIONS</H2
-><P
-><B
-CLASS="COMMAND"
->dig</B
-> provides a number of query options which affect
+<span><strong class="command">key</strong></span> and <span><strong class="command">server</strong></span> statements in
+<code class="filename">named.conf</code>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526365"></a><h2>QUERY OPTIONS</h2>
+<p>
+<span><strong class="command">dig</strong></span> provides a number of query options which affect
 the way in which lookups are made and the results displayed.  Some of
 these set or reset flag bits in the query header, some determine which
 sections of the answer get printed, and others determine the timeout
-and retry strategies.</P
-><P
->Each query option is identified by a keyword preceded by a plus sign
-(<VAR
-CLASS="LITERAL"
->+</VAR
->).  Some keywords set or reset an option.  These may be preceded
-by the string <VAR
-CLASS="LITERAL"
->no</VAR
-> to negate the meaning of that keyword.  Other
+and retry strategies.
+</p>
+<p>
+Each query option is identified by a keyword preceded by a plus sign
+(<code class="literal">+</code>).  Some keywords set or reset an option.  These may be preceded
+by the string <code class="literal">no</code> to negate the meaning of that keyword.  Other
 keywords assign values to options like the timeout interval.  They
-have the form <VAR
-CLASS="OPTION"
->+keyword=value</VAR
->.
+have the form <code class="option">+keyword=value</code>.
 The query options are:
 
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><VAR
-CLASS="OPTION"
->+[no]tcp</VAR
-></DT
-><DD
-><P
->Use [do not use] TCP when querying name servers.  The default
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="option">+[no]tcp</code></span></dt>
+<dd><p>
+Use [do not use] TCP when querying name servers.  The default
 behaviour is to use UDP unless an AXFR or IXFR query is requested, in
-which case a TCP connection is used.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]vc</VAR
-></DT
-><DD
-><P
->Use [do not use] TCP when querying name servers.  This alternate
-syntax to <VAR
-CLASS="PARAMETER"
->+[no]tcp</VAR
-> is provided for backwards
-compatibility.  The "vc" stands for "virtual circuit".</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]ignore</VAR
-></DT
-><DD
-><P
->Ignore truncation in UDP responses instead of retrying with TCP.  By
-default, TCP retries are performed.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+domain=somename</VAR
-></DT
-><DD
-><P
->Set the search list to contain the single domain
-<VAR
-CLASS="PARAMETER"
->somename</VAR
->, as if specified in a
-<B
-CLASS="COMMAND"
->domain</B
-> directive in
-<TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->, and enable search list
-processing as if the <VAR
-CLASS="PARAMETER"
->+search</VAR
-> option were given.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]search</VAR
-></DT
-><DD
-><P
->Use [do not use] the search list defined by the searchlist or domain
-directive in <TT
-CLASS="FILENAME"
->resolv.conf</TT
-> (if any).
-The search list is not used by default.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]defname</VAR
-></DT
-><DD
-><P
->Deprecated, treated as a synonym for <VAR
-CLASS="PARAMETER"
->+[no]search</VAR
-></P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]aaonly</VAR
-></DT
-><DD
-><P
->Sets the "aa" flag in the query.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]aaflag</VAR
-></DT
-><DD
-><P
->A synonym for <VAR
-CLASS="PARAMETER"
->+[no]aaonly</VAR
->.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]adflag</VAR
-></DT
-><DD
-><P
->Set [do not set] the AD (authentic data) bit in the query.  The AD bit
+which case a TCP connection is used.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]vc</code></span></dt>
+<dd><p>
+Use [do not use] TCP when querying name servers.  This alternate
+syntax to <em class="parameter"><code>+[no]tcp</code></em> is provided for backwards
+compatibility.  The "vc" stands for "virtual circuit".
+</p></dd>
+<dt><span class="term"><code class="option">+[no]ignore</code></span></dt>
+<dd><p>
+Ignore truncation in UDP responses instead of retrying with TCP.  By
+default, TCP retries are performed.
+</p></dd>
+<dt><span class="term"><code class="option">+domain=somename</code></span></dt>
+<dd><p>
+Set the search list to contain the single domain
+<em class="parameter"><code>somename</code></em>, as if specified in a
+<span><strong class="command">domain</strong></span> directive in
+<code class="filename">/etc/resolv.conf</code>, and enable search list
+processing as if the <em class="parameter"><code>+search</code></em> option were given.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]search</code></span></dt>
+<dd><p>
+Use [do not use] the search list defined by the searchlist or domain
+directive in <code class="filename">resolv.conf</code> (if any).
+The search list is not used by default.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]defname</code></span></dt>
+<dd><p>
+Deprecated, treated as a synonym for <em class="parameter"><code>+[no]search</code></em>
+</p></dd>
+<dt><span class="term"><code class="option">+[no]aaonly</code></span></dt>
+<dd><p>
+Sets the "aa" flag in the query.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]aaflag</code></span></dt>
+<dd><p>
+A synonym for <em class="parameter"><code>+[no]aaonly</code></em>.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]adflag</code></span></dt>
+<dd><p>
+Set [do not set] the AD (authentic data) bit in the query.  The AD bit
 currently has a standard meaning only in responses, not in queries,
 but the ability to set the bit in the query is provided for
-completeness.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]cdflag</VAR
-></DT
-><DD
-><P
->Set [do not set] the CD (checking disabled) bit in the query.  This
-requests the server to not perform DNSSEC validation of responses.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]cl</VAR
-></DT
-><DD
-><P
->Display [do not display] the CLASS when printing the record.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]ttlid</VAR
-></DT
-><DD
-><P
->Display [do not display] the TTL when printing the record.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]recurse</VAR
-></DT
-><DD
-><P
->Toggle the setting of the RD (recursion desired) bit in the query.
-This bit is set by default, which means <B
-CLASS="COMMAND"
->dig</B
->
+completeness.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]cdflag</code></span></dt>
+<dd><p>
+Set [do not set] the CD (checking disabled) bit in the query.  This
+requests the server to not perform DNSSEC validation of responses.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]cl</code></span></dt>
+<dd><p>
+Display [do not display] the CLASS when printing the record.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]ttlid</code></span></dt>
+<dd><p>
+Display [do not display] the TTL when printing the record.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]recurse</code></span></dt>
+<dd><p>
+Toggle the setting of the RD (recursion desired) bit in the query.
+This bit is set by default, which means <span><strong class="command">dig</strong></span>
 normally sends recursive queries.  Recursion is automatically disabled
-when the <VAR
-CLASS="PARAMETER"
->+nssearch</VAR
-> or
-<VAR
-CLASS="PARAMETER"
->+trace</VAR
-> query options are used.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]nssearch</VAR
-></DT
-><DD
-><P
->When this option is set, <B
-CLASS="COMMAND"
->dig</B
-> attempts to find the
+when the <em class="parameter"><code>+nssearch</code></em> or
+<em class="parameter"><code>+trace</code></em> query options are used.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]nssearch</code></span></dt>
+<dd><p>
+When this option is set, <span><strong class="command">dig</strong></span> attempts to find the
 authoritative name servers for the zone containing the name being
 looked up and display the SOA record that each name server has for the
-zone.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]trace</VAR
-></DT
-><DD
-><P
->Toggle tracing of the delegation path from the root name servers for
+zone.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]trace</code></span></dt>
+<dd><p>
+Toggle tracing of the delegation path from the root name servers for
 the name being looked up.  Tracing is disabled by default.  When
-tracing is enabled, <B
-CLASS="COMMAND"
->dig</B
-> makes iterative queries to
+tracing is enabled, <span><strong class="command">dig</strong></span> makes iterative queries to
 resolve the name being looked up.  It will follow referrals from the
 root servers, showing the answer from each server that was used to
-resolve the lookup.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]cmd</VAR
-></DT
-><DD
-><P
->toggles the printing of the initial comment in the output identifying
-the version of <B
-CLASS="COMMAND"
->dig</B
-> and the query options that have
-been applied.  This comment is printed by default.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]short</VAR
-></DT
-><DD
-><P
->Provide a terse answer.  The default is to print the answer in a
-verbose form.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]identify</VAR
-></DT
-><DD
-><P
->Show [or do not show] the IP address and port number that supplied the
-answer when the <VAR
-CLASS="PARAMETER"
->+short</VAR
-> option is enabled.  If
+resolve the lookup.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]cmd</code></span></dt>
+<dd><p>
+toggles the printing of the initial comment in the output identifying
+the version of <span><strong class="command">dig</strong></span> and the query options that have
+been applied.  This comment is printed by default.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]short</code></span></dt>
+<dd><p>
+Provide a terse answer.  The default is to print the answer in a
+verbose form.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]identify</code></span></dt>
+<dd><p>
+Show [or do not show] the IP address and port number that supplied the
+answer when the <em class="parameter"><code>+short</code></em> option is enabled.  If
 short form answers are requested, the default is not to show the
-source address and port number of the server that provided the answer.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]comments</VAR
-></DT
-><DD
-><P
->Toggle the display of comment lines in the output.  The default is to
-print comments.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]stats</VAR
-></DT
-><DD
-><P
->This query option toggles the printing of statistics: when the query
+source address and port number of the server that provided the answer.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]comments</code></span></dt>
+<dd><p>
+Toggle the display of comment lines in the output.  The default is to
+print comments.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]stats</code></span></dt>
+<dd><p>
+This query option toggles the printing of statistics: when the query
 was made, the size of the reply and so on.  The default behaviour is
-to print the query statistics.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]qr</VAR
-></DT
-><DD
-><P
->Print [do not print] the query as it is sent.
-By default, the query is not printed.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]question</VAR
-></DT
-><DD
-><P
->Print [do not print] the question section of a query when an answer is
-returned.  The default is to print the question section as a comment.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]answer</VAR
-></DT
-><DD
-><P
->Display [do not display] the answer section of a reply.  The default
-is to display it.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]authority</VAR
-></DT
-><DD
-><P
->Display [do not display] the authority section of a reply.  The
-default is to display it.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]additional</VAR
-></DT
-><DD
-><P
->Display [do not display] the additional section of a reply.
-The default is to display it.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]all</VAR
-></DT
-><DD
-><P
->Set or clear all display flags.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+time=T</VAR
-></DT
-><DD
-><P
->&#13;Sets the timeout for a query to
-<VAR
-CLASS="PARAMETER"
->T</VAR
-> seconds.  The default time out is 5 seconds.
-An attempt to set <VAR
-CLASS="PARAMETER"
->T</VAR
-> to less than 1 will result
-in a query timeout of 1 second being applied.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+tries=T</VAR
-></DT
-><DD
-><P
->Sets the number of times to try UDP queries to server to
-<VAR
-CLASS="PARAMETER"
->T</VAR
-> instead of the default, 3.  If
-<VAR
-CLASS="PARAMETER"
->T</VAR
-> is less than or equal to zero, the number of
-tries is silently rounded up to 1.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+retry=T</VAR
-></DT
-><DD
-><P
->Sets the number of times to retry UDP queries to server to
-<VAR
-CLASS="PARAMETER"
->T</VAR
-> instead of the default, 2.  Unlike
-<VAR
-CLASS="PARAMETER"
->+tries</VAR
->, this does not include the initial
-query.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+ndots=D</VAR
-></DT
-><DD
-><P
->Set the number of dots that have to appear in
-<VAR
-CLASS="PARAMETER"
->name</VAR
-> to <VAR
-CLASS="PARAMETER"
->D</VAR
-> for it to be
+to print the query statistics.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]qr</code></span></dt>
+<dd><p>
+Print [do not print] the query as it is sent.
+By default, the query is not printed.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]question</code></span></dt>
+<dd><p>
+Print [do not print] the question section of a query when an answer is
+returned.  The default is to print the question section as a comment.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]answer</code></span></dt>
+<dd><p>
+Display [do not display] the answer section of a reply.  The default
+is to display it.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]authority</code></span></dt>
+<dd><p>
+Display [do not display] the authority section of a reply.  The
+default is to display it.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]additional</code></span></dt>
+<dd><p>
+Display [do not display] the additional section of a reply.
+The default is to display it.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]all</code></span></dt>
+<dd><p>
+Set or clear all display flags.
+</p></dd>
+<dt><span class="term"><code class="option">+time=T</code></span></dt>
+<dd><p>
+
+Sets the timeout for a query to
+<em class="parameter"><code>T</code></em> seconds.  The default time out is 5 seconds.
+An attempt to set <em class="parameter"><code>T</code></em> to less than 1 will result
+in a query timeout of 1 second being applied.
+</p></dd>
+<dt><span class="term"><code class="option">+tries=T</code></span></dt>
+<dd><p>
+Sets the number of times to try UDP queries to server to
+<em class="parameter"><code>T</code></em> instead of the default, 3.  If
+<em class="parameter"><code>T</code></em> is less than or equal to zero, the number of
+tries is silently rounded up to 1.
+</p></dd>
+<dt><span class="term"><code class="option">+retry=T</code></span></dt>
+<dd><p>
+Sets the number of times to retry UDP queries to server to
+<em class="parameter"><code>T</code></em> instead of the default, 2.  Unlike
+<em class="parameter"><code>+tries</code></em>, this does not include the initial
+query.
+</p></dd>
+<dt><span class="term"><code class="option">+ndots=D</code></span></dt>
+<dd><p>
+Set the number of dots that have to appear in
+<em class="parameter"><code>name</code></em> to <em class="parameter"><code>D</code></em> for it to be
 considered absolute.  The default value is that defined using the
-ndots statement in <TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->, or 1 if no
+ndots statement in <code class="filename">/etc/resolv.conf</code>, or 1 if no
 ndots statement is present.  Names with fewer dots are interpreted as
 relative names and will be searched for in the domains listed in the
-<VAR
-CLASS="OPTION"
->search</VAR
-> or <VAR
-CLASS="OPTION"
->domain</VAR
-> directive in
-<TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+bufsize=B</VAR
-></DT
-><DD
-><P
->Set the UDP message buffer size advertised using EDNS0 to
-<VAR
-CLASS="PARAMETER"
->B</VAR
-> bytes.  The maximum and minimum sizes of this
+<code class="option">search</code> or <code class="option">domain</code> directive in
+<code class="filename">/etc/resolv.conf</code>.
+</p></dd>
+<dt><span class="term"><code class="option">+bufsize=B</code></span></dt>
+<dd><p>
+Set the UDP message buffer size advertised using EDNS0 to
+<em class="parameter"><code>B</code></em> bytes.  The maximum and minimum sizes of this
 buffer are 65535 and 0 respectively.  Values outside this range are
-rounded up or down appropriately.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]multiline</VAR
-></DT
-><DD
-><P
->Print records like the SOA records in a verbose multi-line
+rounded up or down appropriately.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]multiline</code></span></dt>
+<dd><p>
+Print records like the SOA records in a verbose multi-line
 format with human-readable comments.  The default is to print
 each record on a single line, to facilitate machine parsing 
-of the <B
-CLASS="COMMAND"
->dig</B
-> output.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]fail</VAR
-></DT
-><DD
-><P
->Do not try the next server if you receive a SERVFAIL.  The default is
+of the <span><strong class="command">dig</strong></span> output.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]fail</code></span></dt>
+<dd><p>
+Do not try the next server if you receive a SERVFAIL.  The default is
 to not try the next server which is the reverse of normal stub resolver
-behaviour.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]besteffort</VAR
-></DT
-><DD
-><P
->Attempt to display the contents of messages which are malformed.
-The default is to not display malformed answers.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]dnssec</VAR
-></DT
-><DD
-><P
->Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO)
-in the OPT record in the additional section of the query.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]sigchase</VAR
-></DT
-><DD
-><P
->Chase DNSSEC signature chains.  Requires dig be compiled with
--DDIG_SIGCHASE.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+trusted-key=####</VAR
-></DT
-><DD
-><P
->Specify a trusted key to be used with <VAR
-CLASS="OPTION"
->+sigchase</VAR
->.
-Requires dig be compiled with -DDIG_SIGCHASE.</P
-></DD
-><DT
-><VAR
-CLASS="OPTION"
->+[no]topdown</VAR
-></DT
-><DD
-><P
->When chasing DNSSEC signature chains perform a top down validation.
-Requires dig be compiled with -DDIG_SIGCHASE.</P
-></DD
-></DL
-></DIV
->&#13;</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN385"
-></A
-><H2
->MULTIPLE QUERIES</H2
-><P
->The BIND 9 implementation of <B
-CLASS="COMMAND"
->dig </B
-> supports
+behaviour.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]besteffort</code></span></dt>
+<dd><p>
+Attempt to display the contents of messages which are malformed.
+The default is to not display malformed answers.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]dnssec</code></span></dt>
+<dd><p>
+Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO)
+in the OPT record in the additional section of the query.
+</p></dd>
+<dt><span class="term"><code class="option">+[no]sigchase</code></span></dt>
+<dd><p>
+Chase DNSSEC signature chains.  Requires dig be compiled with
+-DDIG_SIGCHASE.
+</p></dd>
+<dt><span class="term"><code class="option">+trusted-key=####</code></span></dt>
+<dd>
+<p>
+	      Specifies a file containing trusted keys to be used with
+	      <code class="option">+sigchase</code>.  Each DNSKEY record must be
+	      on its own line.
+	    </p>
+<p>
+	      If not specified <span><strong class="command">dig</strong></span> will look for
+	      <code class="filename">/etc/trusted-key.key</code> then
+	      <code class="filename">trusted-key.key</code> in the current directory.
+	    </p>
+<p>
+	      Requires dig be compiled with -DDIG_SIGCHASE.
+	    </p>
+</dd>
+<dt><span class="term"><code class="option">+[no]topdown</code></span></dt>
+<dd><p>
+When chasing DNSSEC signature chains perform a top down validation.
+Requires dig be compiled with -DDIG_SIGCHASE.
+</p></dd>
+</dl></div>
+<p>
+
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2527033"></a><h2>MULTIPLE QUERIES</h2>
+<p>
+The BIND 9 implementation of <span><strong class="command">dig </strong></span> supports
 specifying multiple queries on the command line (in addition to
-supporting the <VAR
-CLASS="OPTION"
->-f</VAR
-> batch file option).  Each of those
+supporting the <code class="option">-f</code> batch file option).  Each of those
 queries can be supplied with its own set of flags, options and query
-options.</P
-><P
->In this case, each <VAR
-CLASS="PARAMETER"
->query</VAR
-> argument represent an
+options.
+</p>
+<p>
+In this case, each <em class="parameter"><code>query</code></em> argument represent an
 individual query in the command-line syntax described above.  Each
 consists of any of the standard options and flags, the name to be
 looked up, an optional query type and class and any query options that
-should be applied to that query.</P
-><P
->A global set of query options, which should be applied to all queries,
+should be applied to that query.
+</p>
+<p>
+A global set of query options, which should be applied to all queries,
 can also be supplied.  These global query options must precede the
 first tuple of name, class, type, options, flags, and query options
 supplied on the command line.  Any global query options (except
-the <VAR
-CLASS="OPTION"
->+[no]cmd</VAR
-> option) can be
+the <code class="option">+[no]cmd</code> option) can be
 overridden by a query-specific set of query options.  For example:
-<PRE
-CLASS="PROGRAMLISTING"
->dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr</PRE
->
-shows how <B
-CLASS="COMMAND"
->dig</B
-> could be used from the command line
-to make three lookups: an ANY query for <VAR
-CLASS="LITERAL"
->www.isc.org</VAR
->, a
+</p>
+<pre class="programlisting">
+dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
+</pre>
+<p>
+shows how <span><strong class="command">dig</strong></span> could be used from the command line
+to make three lookups: an ANY query for <code class="literal">www.isc.org</code>, a
 reverse lookup of 127.0.0.1 and a query for the NS records of
-<VAR
-CLASS="LITERAL"
->isc.org</VAR
->.
+<code class="literal">isc.org</code>.
 
-A global query option of <VAR
-CLASS="PARAMETER"
->+qr</VAR
-> is applied, so
-that <B
-CLASS="COMMAND"
->dig</B
-> shows the initial query it made for each
+A global query option of <em class="parameter"><code>+qr</code></em> is applied, so
+that <span><strong class="command">dig</strong></span> shows the initial query it made for each
 lookup.  The final query has a local query option of
-<VAR
-CLASS="PARAMETER"
->+noqr</VAR
-> which means that <B
-CLASS="COMMAND"
->dig</B
->
+<em class="parameter"><code>+noqr</code></em> which means that <span><strong class="command">dig</strong></span>
 will not print the initial query when it looks up the NS records for
-<VAR
-CLASS="LITERAL"
->isc.org</VAR
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN403"
-></A
-><H2
->FILES</H2
-><P
-><TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
-></P
-><P
-><TT
-CLASS="FILENAME"
->${HOME}/.digrc</TT
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN409"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->host</SPAN
->(1)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->,
-<I
-CLASS="CITETITLE"
->RFC1035</I
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN422"
-></A
-><H2
->BUGS </H2
-><P
->There are probably too many query options. </P
-></DIV
-></BODY
-></HTML
->
+<code class="literal">isc.org</code>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2527092"></a><h2>FILES</h2>
+<p>
+<code class="filename">/etc/resolv.conf</code>
+</p>
+<p>
+<code class="filename">${HOME}/.digrc</code>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2527111"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>,
+<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+<span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
+<em class="citetitle">RFC1035</em>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2527149"></a><h2>BUGS </h2>
+<p>
+There are probably too many query options. 
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/dig/dighost.c b/contrib/bind9/bin/dig/dighost.c
index 63a81105a7d8..6129fedb6c64 100644
--- a/contrib/bind9/bin/dig/dighost.c
+++ b/contrib/bind9/bin/dig/dighost.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dighost.c,v 1.221.2.19.2.20 2004/11/22 23:30:31 marka Exp $ */
+/* $Id: dighost.c,v 1.221.2.19.2.31 2005/10/14 01:38:40 marka Exp $ */
 
 /*
  * Notice to programmers:  Do not use this code as an example of how to
@@ -37,7 +37,6 @@
 #include <dns/dnssec.h>
 #include <dns/ds.h>
 #include <dns/nsec.h>
-#include <isc/file.h>
 #include <isc/random.h>
 #include <ctype.h>
 #endif
@@ -58,6 +57,7 @@
 #include <isc/app.h>
 #include <isc/base64.h>
 #include <isc/entropy.h>
+#include <isc/file.h>
 #include <isc/lang.h>
 #include <isc/netaddr.h>
 #ifdef DIG_SIGCHASE
@@ -90,9 +90,9 @@
 static lwres_context_t *lwctx = NULL;
 static lwres_conf_t *lwconf;
 
-ISC_LIST(dig_lookup_t) lookup_list;
+dig_lookuplist_t lookup_list;
 dig_serverlist_t server_list;
-ISC_LIST(dig_searchlist_t) search_list;
+dig_searchlistlist_t search_list;
 
 isc_boolean_t
 	have_ipv4 = ISC_FALSE,
@@ -146,7 +146,7 @@ dig_lookup_t *current_lookup = NULL;
 
 #ifdef DIG_SIGCHASE
 
-isc_result_t      get_trusted_key(isc_mem_t *mctx);
+isc_result_t	  get_trusted_key(isc_mem_t *mctx);
 dns_rdataset_t *  sigchase_scanname(dns_rdatatype_t type,
 				    dns_rdatatype_t covers,
 				    isc_boolean_t *lookedup,
@@ -156,103 +156,104 @@ dns_rdataset_t *  chase_scanname_section(dns_message_t *msg,
 					 dns_rdatatype_t type,
 					 dns_rdatatype_t covers,
 					 int section);
-isc_result_t      advanced_rrsearch(dns_rdataset_t **rdataset,
+isc_result_t	  advanced_rrsearch(dns_rdataset_t **rdataset,
 				    dns_name_t *name,
 				    dns_rdatatype_t type,
 				    dns_rdatatype_t covers,
 				    isc_boolean_t *lookedup);
-isc_result_t      sigchase_verify_sig_key(dns_name_t *name,
+isc_result_t	  sigchase_verify_sig_key(dns_name_t *name,
 					  dns_rdataset_t *rdataset,
 					  dst_key_t* dnsseckey,
 					  dns_rdataset_t *sigrdataset,
 					  isc_mem_t *mctx);
-isc_result_t      sigchase_verify_sig(dns_name_t *name,
+isc_result_t	  sigchase_verify_sig(dns_name_t *name,
 				      dns_rdataset_t *rdataset,
 				      dns_rdataset_t *keyrdataset,
 				      dns_rdataset_t *sigrdataset,
 				      isc_mem_t *mctx);
-isc_result_t      sigchase_verify_ds(dns_name_t *name,
+isc_result_t	  sigchase_verify_ds(dns_name_t *name,
 				     dns_rdataset_t *keyrdataset,
 				     dns_rdataset_t *dsrdataset,
 				     isc_mem_t *mctx);
-void              sigchase(dns_message_t *msg);
-void              print_rdata(dns_rdata_t *rdata, isc_mem_t *mctx);
-void              print_rdataset(dns_name_t *name,
+void		  sigchase(dns_message_t *msg);
+void		  print_rdata(dns_rdata_t *rdata, isc_mem_t *mctx);
+void		  print_rdataset(dns_name_t *name,
 				 dns_rdataset_t *rdataset, isc_mem_t *mctx);
-void              dup_name(dns_name_t *source, dns_name_t* target,
+void		  dup_name(dns_name_t *source, dns_name_t* target,
 			   isc_mem_t *mctx);
-void              dump_database(void);
-void              dump_database_section(dns_message_t *msg, int section);
+void		  free_name(dns_name_t *name, isc_mem_t *mctx);
+void		  dump_database(void);
+void		  dump_database_section(dns_message_t *msg, int section);
 dns_rdataset_t *  search_type(dns_name_t *name, dns_rdatatype_t type,
 			      dns_rdatatype_t covers);
-isc_result_t      contains_trusted_key(dns_name_t *name,
+isc_result_t	  contains_trusted_key(dns_name_t *name,
 				       dns_rdataset_t *rdataset,
 				       dns_rdataset_t *sigrdataset,
 				       isc_mem_t *mctx);
-void              print_type(dns_rdatatype_t type);
-isc_result_t      prove_nx_domain(dns_message_t * msg,
+void		  print_type(dns_rdatatype_t type);
+isc_result_t	  prove_nx_domain(dns_message_t * msg,
 				  dns_name_t * name,
 				  dns_name_t * rdata_name,
 				  dns_rdataset_t ** rdataset,
 				  dns_rdataset_t ** sigrdataset);
-isc_result_t      prove_nx_type(dns_message_t * msg, dns_name_t *name,
+isc_result_t	  prove_nx_type(dns_message_t * msg, dns_name_t *name,
 				dns_rdataset_t *nsec,
 				dns_rdataclass_t class,
 				dns_rdatatype_t type,
 				dns_name_t * rdata_name,
 				dns_rdataset_t ** rdataset,
 				dns_rdataset_t ** sigrdataset);
-isc_result_t      prove_nx(dns_message_t * msg, dns_name_t * name,
+isc_result_t	  prove_nx(dns_message_t * msg, dns_name_t * name,
 			   dns_rdataclass_t class,
 			   dns_rdatatype_t type,
 			   dns_name_t * rdata_name,
 			   dns_rdataset_t ** rdataset,
 			   dns_rdataset_t ** sigrdataset);
 static void	  nameFromString(const char *str, dns_name_t *p_ret);
-int               inf_name(dns_name_t * name1, dns_name_t * name2);
-isc_result_t      opentmpkey(isc_mem_t *mctx, const char *file,
+int		  inf_name(dns_name_t * name1, dns_name_t * name2);
+isc_result_t	  opentmpkey(isc_mem_t *mctx, const char *file,
 			     char **tempp, FILE **fp);
-isc_result_t      removetmpkey(isc_mem_t *mctx, const char *file);
-void              clean_trustedkey(void );
-void              insert_trustedkey(dst_key_t  * key);
+isc_result_t	  removetmpkey(isc_mem_t *mctx, const char *file);
+void		  clean_trustedkey(void);
+void		  insert_trustedkey(dst_key_t  * key);
 #if DIG_SIGCHASE_BU
-isc_result_t      getneededrr(dns_message_t *msg);
-void              sigchase_bottom_up(dns_message_t *msg);
-void              sigchase_bu(dns_message_t *msg);
+isc_result_t	  getneededrr(dns_message_t *msg);
+void		  sigchase_bottom_up(dns_message_t *msg);
+void		  sigchase_bu(dns_message_t *msg);
 #endif
 #if DIG_SIGCHASE_TD
-isc_result_t      initialization(dns_name_t *name);
-isc_result_t      prepare_lookup(dns_name_t *name);
-isc_result_t      grandfather_pb_test(dns_name_t * zone_name,
+isc_result_t	  initialization(dns_name_t *name);
+isc_result_t	  prepare_lookup(dns_name_t *name);
+isc_result_t	  grandfather_pb_test(dns_name_t * zone_name,
 				      dns_rdataset_t *sigrdataset);
-isc_result_t      child_of_zone(dns_name_t *name,
+isc_result_t	  child_of_zone(dns_name_t *name,
 				dns_name_t *zone_name,
 				dns_name_t *child_name);
-void              sigchase_td(dns_message_t *msg);
+void		  sigchase_td(dns_message_t *msg);
 #endif
 char trustedkey[MXNAME] = "";
 
-dns_rdataset_t * chase_rdataset = NULL;
-dns_rdataset_t * chase_sigrdataset = NULL;
-dns_rdataset_t * chase_dsrdataset = NULL;
-dns_rdataset_t * chase_sigdsrdataset = NULL;
-dns_rdataset_t * chase_keyrdataset = NULL;
-dns_rdataset_t * chase_sigkeyrdataset = NULL;
-dns_rdataset_t * chase_nsrdataset = NULL;
+dns_rdataset_t *chase_rdataset = NULL;
+dns_rdataset_t *chase_sigrdataset = NULL;
+dns_rdataset_t *chase_dsrdataset = NULL;
+dns_rdataset_t *chase_sigdsrdataset = NULL;
+dns_rdataset_t *chase_keyrdataset = NULL;
+dns_rdataset_t *chase_sigkeyrdataset = NULL;
+dns_rdataset_t *chase_nsrdataset = NULL;
 
-dns_name_t  chase_name; /* the query name */
+dns_name_t chase_name; /* the query name */
 #if DIG_SIGCHASE_TD
 /*
  * the current name is the parent name when we follow delegation
  */
-dns_name_t  chase_current_name; 
+dns_name_t chase_current_name;
 /*
  * the child name is used for delegation (NS DS responses in AUTHORITY section)
  */
-dns_name_t  chase_authority_name;
+dns_name_t chase_authority_name;
 #endif
 #if DIG_SIGCHASE_BU
-dns_name_t  chase_signame;
+dns_name_t chase_signame;
 #endif
 
 
@@ -274,7 +275,7 @@ dns_message_t * error_message = NULL;
 #endif
 
 isc_boolean_t dsvalidating = ISC_FALSE;
-isc_boolean_t chase_name_dup  = ISC_FALSE;
+isc_boolean_t chase_name_dup = ISC_FALSE;
 
 ISC_LIST(dig_message_t) chase_message_list;
 ISC_LIST(dig_message_t) chase_message_list2;
@@ -282,11 +283,11 @@ ISC_LIST(dig_message_t) chase_message_list2;
 
 #define MAX_TRUSTED_KEY 5
 typedef struct struct_trusted_key_list {
-  dst_key_t * key[MAX_TRUSTED_KEY];
-  int nb_tk;
+	dst_key_t * key[MAX_TRUSTED_KEY];
+	int nb_tk;
 } struct_tk_list;
 
-struct_tk_list  tk_list = { {NULL, NULL, NULL, NULL, NULL}, 0};
+struct_tk_list tk_list = { {NULL, NULL, NULL, NULL, NULL}, 0};
 
 #endif
 
@@ -581,7 +582,7 @@ set_nameserver(char *opt) {
 		return;
 
 	result = bind9_getaddresses(opt, 0, sockaddrs,
-				    DIG_MAX_ADDRESSES, &count); 
+				    DIG_MAX_ADDRESSES, &count);
 	if (result != ISC_R_SUCCESS)
 		fatal("couldn't get address for '%s': %s",
 		      opt, isc_result_totext(result));
@@ -690,13 +691,13 @@ make_empty_lookup(void) {
 #ifdef DIG_SIGCHASE
 	looknew->sigchase = ISC_FALSE;
 #if DIG_SIGCHASE_TD
-	looknew->do_topdown =  ISC_FALSE;
+	looknew->do_topdown = ISC_FALSE;
 	looknew->trace_root_sigchase = ISC_FALSE;
 	looknew->rdtype_sigchaseset = ISC_FALSE;
 	looknew->rdtype_sigchase = dns_rdatatype_any;
 	looknew->qrdtype_sigchase = dns_rdatatype_any;
 	looknew->rdclass_sigchase = dns_rdataclass_in;
-	looknew->rdclass_sigchaseset  = ISC_FALSE;
+	looknew->rdclass_sigchaseset = ISC_FALSE;
 #endif
 #endif
 	looknew->udpsize = 0;
@@ -766,9 +767,9 @@ clone_lookup(dig_lookup_t *lookold, isc_boolean_t servers) {
 #ifdef DIG_SIGCHASE
 	looknew->sigchase = lookold->sigchase;
 #if DIG_SIGCHASE_TD
-	looknew->do_topdown =  lookold->do_topdown;
+	looknew->do_topdown = lookold->do_topdown;
 	looknew->trace_root_sigchase = lookold->trace_root_sigchase;
-	looknew->rdtype_sigchaseset =  lookold->rdtype_sigchaseset;
+	looknew->rdtype_sigchaseset = lookold->rdtype_sigchaseset;
 	looknew->rdtype_sigchase = lookold->rdtype_sigchase;
 	looknew->qrdtype_sigchase = lookold->qrdtype_sigchase;
 	looknew->rdclass_sigchase = lookold->rdclass_sigchase;
@@ -944,14 +945,17 @@ setup_system(void) {
 	if (lwresult != LWRES_R_SUCCESS)
 		fatal("lwres_context_create failed");
 
-	(void)lwres_conf_parse(lwctx, RESOLV_CONF);
+	if (isc_file_exists(RESOLV_CONF))
+		lwresult = lwres_conf_parse(lwctx, RESOLV_CONF);
+	if (lwresult != LWRES_R_SUCCESS)
+		fatal("parse of %s failed", RESOLV_CONF);
+
 	lwconf = lwres_conf_get(lwctx);
 
 	/* Make the search list */
 	if (lwconf->searchnxt > 0)
 		create_search_list(lwconf);
-	else {
-		/* No search list. Use the domain name if any */
+	else { /* No search list. Use the domain name if any */
 		if (lwconf->domainname != NULL) {
 			domain = make_searchlist_entry(lwconf->domainname);
 			ISC_LIST_INITANDAPPEND(search_list, domain, link);
@@ -959,8 +963,10 @@ setup_system(void) {
 		}
 	}
 			
-	ndots = lwconf->ndots;
-	debug("ndots is %d.", ndots);
+	if (ndots == -1) {
+		ndots = lwconf->ndots;
+		debug("ndots is %d.", ndots);
+	}
 
 	/* If we don't find a nameserver fall back to localhost */
 	if (lwconf->nsnext == 0) {
@@ -985,15 +991,15 @@ setup_system(void) {
 		setup_text_key();
 #ifdef DIG_SIGCHASE
 	/* Setup the list of messages for +sigchase */
-        ISC_LIST_INIT(chase_message_list);
-        ISC_LIST_INIT(chase_message_list2);
+	ISC_LIST_INIT(chase_message_list);
+	ISC_LIST_INIT(chase_message_list2);
 	dns_name_init(&chase_name, NULL);
 #if DIG_SIGCHASE_TD
 	dns_name_init(&chase_current_name, NULL);
 	dns_name_init(&chase_authority_name, NULL);
 #endif
 #if DIG_SIGCHASE_BU
-  	dns_name_init(&chase_signame, NULL);
+	dns_name_init(&chase_signame, NULL);
 #endif
 
 #endif
@@ -1210,8 +1216,7 @@ try_clear_lookup(dig_lookup_t *lookup) {
 		if (debugging) {
 			q = ISC_LIST_HEAD(lookup->q);
 			while (q != NULL) {
-				debug("query to %s still pending",
-				       q->servname);
+				debug("query to %s still pending", q->servname);
 				q = ISC_LIST_NEXT(q, link);
 			}
 			return (ISC_FALSE);
@@ -1224,8 +1229,7 @@ try_clear_lookup(dig_lookup_t *lookup) {
 	debug("cleared");
 	s = ISC_LIST_HEAD(lookup->my_server_list);
 	while (s != NULL) {
-		debug("freeing server %p belonging to %p",
-		      s, lookup);
+		debug("freeing server %p belonging to %p", s, lookup);
 		ptr = s;
 		s = ISC_LIST_NEXT(s, link);
 		ISC_LIST_DEQUEUE(lookup->my_server_list,
@@ -1278,12 +1282,12 @@ start_lookup(void) {
 #if DIG_SIGCHASE_TD
 		if (current_lookup->do_topdown &&
 		    !current_lookup->rdtype_sigchaseset) {
-			dst_key_t * trustedkey = NULL;
+			dst_key_t *trustedkey = NULL;
 			isc_buffer_t *b = NULL;
 			isc_region_t r;
 			isc_result_t result;
 			dns_name_t query_name;
-			dns_name_t * key_name;
+			dns_name_t *key_name;
 			int i;
 
 			result = get_trusted_key(mctx);
@@ -1296,9 +1300,9 @@ start_lookup(void) {
 			dns_name_init(&query_name, NULL);
 			nameFromString(current_lookup->textname, &query_name);
 
-			for (i = 0; i< tk_list.nb_tk; i++) {
+			for (i = 0; i < tk_list.nb_tk; i++) {
 				key_name = dst_key_name(tk_list.key[i]);
-		      
+
 				if (dns_name_issubdomain(&query_name,
 							 key_name) == ISC_TRUE)
 					trustedkey = tk_list.key[i];
@@ -1313,35 +1317,32 @@ start_lookup(void) {
 				printf(" isn't a subdomain of any Trusted Keys"
 				       ": +sigchase option is disable\n");
 				current_lookup->sigchase = ISC_FALSE;
-				dns_name_free(&query_name, mctx);
+				free_name(&query_name, mctx);
 				goto novalidation;
 			}
-			dns_name_free(&query_name, mctx);
+			free_name(&query_name, mctx);
 
-		    
 			current_lookup->rdtype_sigchase
-			  	= current_lookup->rdtype;
+				= current_lookup->rdtype;
 			current_lookup->rdtype_sigchaseset
-			  	= current_lookup->rdtypeset;
+				= current_lookup->rdtypeset;
 			current_lookup->rdtype = dns_rdatatype_ns;
-		      
-		 
+
 			current_lookup->qrdtype_sigchase
 				= current_lookup->qrdtype;
 			current_lookup->qrdtype = dns_rdatatype_ns;
-		   
+		
 			current_lookup->rdclass_sigchase
 				= current_lookup->rdclass;
 			current_lookup->rdclass_sigchaseset
 				= current_lookup->rdclassset;
 			current_lookup->rdclass = dns_rdataclass_in;
-		
 
 			strncpy(current_lookup->textnamesigchase,
 				current_lookup->textname, MXNAME);
 
 			current_lookup->trace_root_sigchase = ISC_TRUE;
-		    
+
 			result = isc_buffer_allocate(mctx, &b, BUFSIZE);
 			check_result(result, "isc_buffer_allocate");
 			result = dns_name_totext(dst_key_name(trustedkey),
@@ -1466,6 +1467,8 @@ followup_lookup(dns_message_t *msg, dig_query_t *query, dns_section_t section)
 				lookup->ns_search_only =
 					query->lookup->ns_search_only;
 				lookup->trace_root = ISC_FALSE;
+				if (lookup->ns_search_only)
+					lookup->recurse = ISC_FALSE;
 			}
 			srv = make_server(namestr, namestr);
 			debug("adding server %s", srv->servername);
@@ -1636,9 +1639,9 @@ setup_lookup(dig_lookup_t *lookup) {
 	/* XXX New search here? */
 	if ((count_dots(lookup->textname) >= ndots) || !usesearch)
 		lookup->origin = NULL; /* Force abs lookup */
-	else if (lookup->origin == NULL && lookup->new_search && usesearch) {
+	else if (lookup->origin == NULL && lookup->new_search && usesearch)
 		lookup->origin = ISC_LIST_HEAD(search_list);
-	}
+
 	if (lookup->origin != NULL) {
 		debug("trying origin %s", lookup->origin->origin);
 		result = dns_message_gettempname(lookup->sendmsg,
@@ -1922,21 +1925,17 @@ bringup_timer(dig_query_t *query, unsigned int default_timeout) {
 	if (ISC_LIST_NEXT(query, link) != NULL)
 		local_timeout = SERVER_TIMEOUT;
 	else {
-		if (timeout == 0) {
+		if (timeout == 0)
 			local_timeout = default_timeout;
-		} else
+		else
 			local_timeout = timeout;
 	}
 	debug("have local timeout of %d", local_timeout);
 	isc_interval_set(&l->interval, local_timeout, 0);
 	if (l->timer != NULL)
 		isc_timer_detach(&l->timer);
-	result = isc_timer_create(timermgr,
-				  isc_timertype_once,
-				  NULL,
-				  &l->interval,
-				  global_task,
-				  connect_timeout,
+	result = isc_timer_create(timermgr, isc_timertype_once, NULL,
+				  &l->interval, global_task, connect_timeout,
 				  l, &l->timer);
 	check_result(result, "isc_timer_create");
 }	
@@ -2029,8 +2028,7 @@ send_udp(dig_query_t *query) {
 	l = query->lookup;
 	bringup_timer(query, UDP_TIMEOUT);
 	l->current_query = query;
-	debug("working on lookup %p, query %p",
-	      query->lookup, query);
+	debug("working on lookup %p, query %p", query->lookup, query);
 	if (!query->recv_made) {
 		/* XXX Check the sense of this, need assertion? */
 		query->waiting_connect = ISC_FALSE;
@@ -2056,12 +2054,9 @@ send_udp(dig_query_t *query) {
 		ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf,
 				 link);
 		debug("recving with lookup=%p, query=%p, sock=%p",
-		      query->lookup, query,
-		      query->sock);
-		result = isc_socket_recvv(query->sock,
-					  &query->recvlist, 1,
-					  global_task, recv_done,
-					  query);
+		      query->lookup, query, query->sock);
+		result = isc_socket_recvv(query->sock, &query->recvlist, 1,
+					  global_task, recv_done, query);
 		check_result(result, "isc_socket_recvv");
 		recvcount++;
 		debug("recvcount=%d", recvcount);
@@ -2097,7 +2092,7 @@ send_udp(dig_query_t *query) {
  */
 static void
 connect_timeout(isc_task_t *task, isc_event_t *event) {
-	dig_lookup_t *l = NULL, *n;
+	dig_lookup_t *l = NULL;
 	dig_query_t *query = NULL, *cq;
 
 	UNUSED(task);
@@ -2133,7 +2128,7 @@ connect_timeout(isc_task_t *task, isc_event_t *event) {
 			debug("making new TCP request, %d tries left",
 			      l->retries);
 			l->retries--;
-			n = requeue_lookup(l, ISC_TRUE);
+			requeue_lookup(l, ISC_TRUE);
 			cancel_lookup(l);
 			check_next_lookup(l);
 		}
@@ -2220,8 +2215,7 @@ tcp_length_done(isc_task_t *task, isc_event_t *event) {
 	ENSURE(ISC_LIST_EMPTY(query->recvlist));
 	ISC_LINK_INIT(&query->recvbuf, link);
 	ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link);
-	debug("recving with lookup=%p, query=%p",
-	       query->lookup, query);
+	debug("recving with lookup=%p, query=%p", query->lookup, query);
 	result = isc_socket_recvv(query->sock, &query->recvlist, length, task,
 				  recv_done, query);
 	check_result(result, "isc_socket_recvv");
@@ -2339,8 +2333,7 @@ connect_done(isc_task_t *task, isc_event_t *event) {
 
 		debug("unsuccessful connection: %s",
 		      isc_result_totext(sevent->result));
-		isc_sockaddr_format(&query->sockaddr, sockstr,
-				    sizeof(sockstr));
+		isc_sockaddr_format(&query->sockaddr, sockstr, sizeof(sockstr));
 		if (sevent->result != ISC_R_CANCELED)
 			printf(";; Connection to %s(%s) for %s failed: "
 			       "%s.\n", sockstr,
@@ -2430,8 +2423,7 @@ check_for_more_data(dig_query_t *query, dns_message_t *msg,
 				if ((!query->first_soa_rcvd) &&
 				    (rdata.type != dns_rdatatype_soa)) {
 					puts("; Transfer failed.  "
-					     "Didn't start with "
-					     "SOA answer.");
+					     "Didn't start with SOA answer.");
 					return (ISC_TRUE);
 				}
 				if ((!query->second_rr_rcvd) &&
@@ -2608,7 +2600,7 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 		char buf2[ISC_SOCKADDR_FORMATSIZE];
 		isc_sockaddr_t any;
 
-		if (isc_sockaddr_pf(&query->sockaddr) == AF_INET) 
+		if (isc_sockaddr_pf(&query->sockaddr) == AF_INET)
 			isc_sockaddr_any(&any);
 		else
 			isc_sockaddr_any6(&any);
@@ -2629,7 +2621,7 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 		else
 #endif
 		/*
-		 * We don't expect a match above when the packet is 
+		 * We don't expect a match above when the packet is
 		 * sent to 0.0.0.0, :: or to a multicast addresses.
 		 * XXXMPA broadcast needs to be handled here as well.
 		 */
@@ -2843,9 +2835,6 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 	}
 
 	if (!l->doing_xfr || l->xfr_q == query) {
-#ifdef DIG_SIGCHASE
-		int count = 0;
-#endif
 		if (msg->rcode != dns_rcode_noerror && l->origin != NULL) {
 			if (!next_origin(msg, query)) {
 				printmessage(query, msg, ISC_TRUE);
@@ -2858,11 +2847,7 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 				printmessage(query, msg, ISC_TRUE);
 		} else if (l->trace) {
 			int n = 0;
-#ifdef DIG_SIGCHASE
-			count = msg->counts[DNS_SECTION_ANSWER];
-#else
 			int count = msg->counts[DNS_SECTION_ANSWER];
-#endif
 
 			debug("in TRACE code");
 			if (!l->ns_search_only)
@@ -2885,7 +2870,7 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 
 			if (l->trace_root) {
 				/*
-				 * This is the initial NS query. 
+				 * This is the initial NS query.
 				 */
 				int n;
 
@@ -2900,9 +2885,9 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 				if (!do_sigchase)
 #endif
 				printmessage(query, msg, ISC_TRUE);
-		} 
+		}
 #ifdef DIG_SIGCHASE
-		if ( do_sigchase) {	     
+		if (do_sigchase) {
 			chase_msg = isc_mem_allocate(mctx,
 						     sizeof(dig_message_t));
 			if (chase_msg == NULL) {
@@ -2916,16 +2901,16 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 				fatal("dns_message_create in %s:%d",
 				      __FILE__, __LINE__);
 			}
-	 
+
 			isc_buffer_usedregion(b, &r);
 			result = isc_buffer_allocate(mctx, &buf, r.length);
-	   
+	
 			check_result(result, "isc_buffer_allocate");
 			result =  isc_buffer_copyregion(buf, &r);
 			check_result(result, "isc_buffer_copyregion");
-	   
+	
 			result =  dns_message_parse(msg_temp, buf, 0);
- 
+
 			isc_buffer_free(&buf);
 			chase_msg->msg = msg_temp;
 
@@ -2942,9 +2927,9 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 #endif
 	
 	}
-       
+
 #ifdef DIG_SIGCHASE
-	if (l->sigchase && ISC_LIST_EMPTY(lookup_list) ) {   
+	if (l->sigchase && ISC_LIST_EMPTY(lookup_list)) {
 		sigchase(msg_temp);
 	}
 #endif
@@ -3101,7 +3086,7 @@ cancel_all(void) {
  */
 void
 destroy_libs(void) {
-#ifdef DIG_SIGCHASE 
+#ifdef DIG_SIGCHASE
 	void * ptr;
 	dig_message_t *chase_msg;
 #endif
@@ -3171,7 +3156,7 @@ destroy_libs(void) {
 
 	debug("Destroy the messages kept for sigchase");
 	/* Destroy the messages kept for sigchase */
-       	chase_msg = ISC_LIST_HEAD(chase_message_list);
+	chase_msg = ISC_LIST_HEAD(chase_message_list);
 
 	while (chase_msg != NULL) {
 		INSIST(chase_msg->msg != NULL);
@@ -3191,16 +3176,16 @@ destroy_libs(void) {
 		isc_mem_free(mctx, ptr);
 	}
 	if (dns_name_dynamic(&chase_name))
-		dns_name_free(&chase_name, mctx);
+		free_name(&chase_name, mctx);
 #if DIG_SIGCHASE_TD
 	if (dns_name_dynamic(&chase_current_name))
-		dns_name_free(&chase_current_name, mctx);
+		free_name(&chase_current_name, mctx);
 	if (dns_name_dynamic(&chase_authority_name))
-		dns_name_free(&chase_authority_name, mctx);
+		free_name(&chase_authority_name, mctx);
 #endif
 #if DIG_SIGCHASE_BU
 	if (dns_name_dynamic(&chase_signame))
-		dns_name_free(&chase_signame, mctx);
+		free_name(&chase_signame, mctx);
 #endif
 
 	debug("Destroy memory");
@@ -3212,7 +3197,7 @@ destroy_libs(void) {
 		isc_mem_destroy(&mctx);
 }
 
- 
+
 
 
 #ifdef DIG_SIGCHASE
@@ -3222,32 +3207,31 @@ print_type(dns_rdatatype_t type)
 	isc_buffer_t * b = NULL;
 	isc_result_t result;
 	isc_region_t r;
-  
+
 	result = isc_buffer_allocate(mctx, &b, 4000);
 	check_result(result, "isc_buffer_allocate");
 
 	result = dns_rdatatype_totext(type, b);
 	check_result(result, "print_type");
-  
+
 	isc_buffer_usedregion(b, &r);
 	r.base[r.length] = '\0';
-  
+
 	printf("%s", r.base);
 
 	isc_buffer_free(&b);
 }
 
-
 void
-dump_database_section( dns_message_t *msg, int section)
+dump_database_section(dns_message_t *msg, int section)
 {
 	dns_name_t *msg_name=NULL;
- 
+
 	dns_rdataset_t *rdataset;
 
 	do {
 		dns_message_currentname(msg, section, &msg_name);
-    
+
 		for (rdataset = ISC_LIST_HEAD(msg_name->list); rdataset != NULL;
 		     rdataset = ISC_LIST_NEXT(rdataset, link)) {	
 			dns_name_print(msg_name, stdout);
@@ -3256,35 +3240,32 @@ dump_database_section( dns_message_t *msg, int section)
 			printf("end\n");
 		}
 		msg_name = NULL;
-	} while ( dns_message_nextname(msg, section) == ISC_R_SUCCESS);
+	} while (dns_message_nextname(msg, section) == ISC_R_SUCCESS);
 }
 
-
-void dump_database(void)
-{
+void
+dump_database(void) {
 	dig_message_t * msg;
 
 	for (msg = ISC_LIST_HEAD(chase_message_list);  msg != NULL;
 	     msg = ISC_LIST_NEXT(msg, link)) {
 		if (dns_message_firstname(msg->msg, DNS_SECTION_ANSWER)
-		    == ISC_R_SUCCESS) 
+		    == ISC_R_SUCCESS)
 			dump_database_section(msg->msg, DNS_SECTION_ANSWER);
-       
+
 		if (dns_message_firstname(msg->msg, DNS_SECTION_AUTHORITY)
-		    == ISC_R_SUCCESS) 
+		    == ISC_R_SUCCESS)
 			dump_database_section(msg->msg, DNS_SECTION_AUTHORITY);
 	
 		if (dns_message_firstname(msg->msg, DNS_SECTION_ADDITIONAL)
-		    == ISC_R_SUCCESS) 
+		    == ISC_R_SUCCESS)
 			dump_database_section(msg->msg, DNS_SECTION_ADDITIONAL);
 	}
 }
 
 
-dns_rdataset_t *  search_type(dns_name_t *name,
-			      dns_rdatatype_t type,
-			      dns_rdatatype_t covers)
-{
+dns_rdataset_t *
+search_type(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) {
 	dns_rdataset_t *rdataset;
 	dns_rdata_sig_t siginfo;
 	dns_rdata_t sigrdata;
@@ -3294,10 +3275,9 @@ dns_rdataset_t *  search_type(dns_name_t *name,
 	     rdataset = ISC_LIST_NEXT(rdataset, link)) {
 		if (type == dns_rdatatype_any) {
 			if (rdataset->type != dns_rdatatype_rrsig)
-				return rdataset;
-		} 
-		else if ((type == dns_rdatatype_rrsig) &&
-			 (rdataset->type == dns_rdatatype_rrsig)) {
+				return (rdataset);
+		} else if ((type == dns_rdatatype_rrsig) &&
+			   (rdataset->type == dns_rdatatype_rrsig)) {
 			dns_rdata_init(&sigrdata);
 			result = dns_rdataset_first(rdataset);
 			check_result(result, "empty rdataset");
@@ -3309,38 +3289,35 @@ dns_rdataset_t *  search_type(dns_name_t *name,
 			    (covers == dns_rdatatype_any)) {
 				dns_rdata_reset(&sigrdata);
 				dns_rdata_freestruct(&siginfo);	
-				return rdataset;
+				return (rdataset);
 			}
 			dns_rdata_reset(&sigrdata);
 			dns_rdata_freestruct(&siginfo);
-		} 
-		else if (rdataset->type == type)
-			return rdataset;
+		} else if (rdataset->type == type)
+			return (rdataset);
 	}
-	return NULL;
+	return (NULL);
 }
 
 dns_rdataset_t *
-chase_scanname_section(dns_message_t *msg,
-		       dns_name_t *name,
-		       dns_rdatatype_t type,
-		       dns_rdatatype_t covers,
+chase_scanname_section(dns_message_t *msg, dns_name_t *name,
+		       dns_rdatatype_t type, dns_rdatatype_t covers,
 		       int section)
 {
 	dns_rdataset_t *rdataset;
 	dns_name_t *msg_name = NULL;
-  
+
 	do {
 		dns_message_currentname(msg, section, &msg_name);
 		if (dns_name_compare(msg_name, name) == 0) {
 			rdataset = search_type(msg_name, type, covers);
-			if ( rdataset != NULL)
-				return rdataset;
+			if (rdataset != NULL)
+				return (rdataset);
 		}
 		msg_name = NULL;
-	} while ( dns_message_nextname(msg, section) == ISC_R_SUCCESS);
-  
-	return(NULL);
+	} while (dns_message_nextname(msg, section) == ISC_R_SUCCESS);
+
+	return (NULL);
 }
 
 
@@ -3349,7 +3326,7 @@ chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers)
 {
 	dns_rdataset_t *rdataset = NULL;
 	dig_message_t * msg;
- 
+
 	for (msg = ISC_LIST_HEAD(chase_message_list2);  msg != NULL;
 	     msg = ISC_LIST_NEXT(msg, link)) {
 		if (dns_message_firstname(msg->msg, DNS_SECTION_ANSWER)
@@ -3358,7 +3335,7 @@ chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers)
 							  type, covers,
 							  DNS_SECTION_ANSWER);
 			if (rdataset != NULL)
-				return rdataset;
+				return (rdataset);
 		if (dns_message_firstname(msg->msg, DNS_SECTION_AUTHORITY)
 		    == ISC_R_SUCCESS)
 			rdataset =
@@ -3366,7 +3343,7 @@ chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers)
 						       type, covers,
 						       DNS_SECTION_AUTHORITY);
 			if (rdataset != NULL)
-				return rdataset;
+				return (rdataset);
 		if (dns_message_firstname(msg->msg, DNS_SECTION_ADDITIONAL)
 		    == ISC_R_SUCCESS)
 			rdataset =
@@ -3374,16 +3351,15 @@ chase_scanname(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers)
 						       covers,
 						       DNS_SECTION_ADDITIONAL);
 			if (rdataset != NULL)
-				return rdataset;
+				return (rdataset);
 	}
 
-	return NULL;
+	return (NULL);
 }
 
 dns_rdataset_t *
 sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers,
-		  isc_boolean_t * lookedup,
-		  dns_name_t *rdata_name )
+		  isc_boolean_t * lookedup, dns_name_t *rdata_name)
 {
 	dig_lookup_t *lookup;
 	isc_buffer_t *b = NULL;
@@ -3392,18 +3368,17 @@ sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers,
 	dns_rdataset_t * temp;
 	dns_rdatatype_t querytype;
 
-	if ((temp=chase_scanname(rdata_name, type, covers))!=NULL) {
-		return(temp);
-	}
+	temp = chase_scanname(rdata_name, type, covers);
+	if (temp != NULL)
+		return (temp);
 
-	if (*lookedup == ISC_TRUE) {
-		return(NULL);
-	}
+	if (*lookedup == ISC_TRUE)
+		return (NULL);
 
 	lookup = clone_lookup(current_lookup, ISC_TRUE);
 	lookup->trace_root = ISC_FALSE;
 	lookup->new_search = ISC_TRUE;
-  
+
 	result = isc_buffer_allocate(mctx, &b, BUFSIZE);
 	check_result(result, "isc_buffer_allocate");
 	result = dns_name_totext(rdata_name, ISC_FALSE, b);
@@ -3417,9 +3392,10 @@ sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers,
 		querytype = covers;
 	else
 		querytype = type;
+
 	if (querytype == 0 || querytype == 255) {
 		printf("Error in the queried type: %d\n", querytype);
-		return(NULL);
+		return (NULL);
 	}
 
 	lookup->rdtype = querytype;
@@ -3431,11 +3407,11 @@ sigchase_scanname(dns_rdatatype_t type, dns_rdatatype_t covers,
 	printf("\n\nLaunch a query to find a RRset of type ");
 	print_type(type);
 	printf(" for zone: %s\n", lookup->textname);
-	return(NULL);
+	return (NULL);
 }
 
 void
-insert_trustedkey(dst_key_t  * key)
+insert_trustedkey(dst_key_t * key)
 {
 	if (key == NULL)
 		return;
@@ -3443,7 +3419,7 @@ insert_trustedkey(dst_key_t  * key)
 		return;
 
 	tk_list.key[tk_list.nb_tk++] = key;
-	return;   
+	return;
 }
 
 void
@@ -3455,8 +3431,7 @@ clean_trustedkey()
 		if (tk_list.key[i] != NULL) {
 			dst_key_free(&tk_list.key[i]);
 			tk_list.key[i] = NULL;
-		}
-		else
+		} else
 			break;
 	}
 	tk_list.nb_tk = 0;
@@ -3467,36 +3442,36 @@ char alphnum[] =
 	"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
 
 isc_result_t
-removetmpkey(isc_mem_t *mctx, const char *file) 
+removetmpkey(isc_mem_t *mctx, const char *file)
 {
 	char *tempnamekey = NULL;
 	int tempnamekeylen;
 	isc_result_t result;
-  
+
 	tempnamekeylen = strlen(file)+10;
-  
+
 	tempnamekey = isc_mem_allocate(mctx, tempnamekeylen);
 	if (tempnamekey == NULL)
 		return (ISC_R_NOMEMORY);
 
 	memset(tempnamekey, 0, tempnamekeylen);
- 
+
 	strcat(tempnamekey, file);
 	strcat(tempnamekey,".key");
 	isc_file_remove(tempnamekey);
 
 	result = isc_file_remove(tempnamekey);
 	isc_mem_free(mctx, tempnamekey);
-	return(result);
+	return (result);
 }
 
 isc_result_t
 opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) {
-        FILE *f = NULL;
-        isc_result_t result;
-        char *tempname = NULL;
+	FILE *f = NULL;
+	isc_result_t result;
+	char *tempname = NULL;
 	char *tempnamekey = NULL;
-        int tempnamelen;
+	int tempnamelen;
 	int tempnamekeylen;
 	char *x;
 	char *cp;
@@ -3520,14 +3495,14 @@ opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) {
 			isc_mem_free(mctx, tempname);
 			return (ISC_R_FAILURE);
 		}
-	    
+	
 		x = cp--;
 		while (cp >= tempname && *cp == 'X') {
 			isc_random_get(&which);
 			*cp = alphnum[which % (sizeof(alphnum) - 1)];
 			x = cp--;
 		}
- 
+
 		tempnamekeylen = tempnamelen+5;
 		tempnamekey = isc_mem_allocate(mctx, tempnamekeylen);
 		if (tempnamekey == NULL)
@@ -3537,7 +3512,7 @@ opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) {
 		strncpy(tempnamekey, tempname, tempnamelen);
 		strcat(tempnamekey ,".key");
 
-	   
+	
 		if (isc_file_exists(tempnamekey)) {
 			isc_mem_free(mctx, tempnamekey);
 			isc_mem_free(mctx, tempname);
@@ -3547,19 +3522,19 @@ opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp) {
 		if ((f = fopen(tempnamekey, "w")) == NULL) {
 			printf("get_trusted_key(): trusted key not found %s\n",
 			       tempnamekey);
-			return ISC_R_FAILURE;
+			return (ISC_R_FAILURE);
 		}
 		break;
 	}
 	isc_mem_free(mctx, tempnamekey);
-        *tempp = tempname;
-        *fp = f;
-        return (ISC_R_SUCCESS);
+	*tempp = tempname;
+	*fp = f;
+	return (ISC_R_SUCCESS);
 
  cleanup:
-        isc_mem_free(mctx, tempname);
+	isc_mem_free(mctx, tempname);
 	
-        return (result);
+	return (result);
 }
 
 
@@ -3567,57 +3542,55 @@ isc_result_t
 get_trusted_key(isc_mem_t *mctx)
 {
 	isc_result_t result;
-	const char * filename = NULL;
-	char * filetemp =NULL;
+	const char *filename = NULL;
+	char *filetemp = NULL;
 	char buf[1500];
-	FILE *fp , *fptemp;
-	dst_key_t  * key = NULL;
- 
-	result  = isc_file_exists(trustedkey);
+	FILE *fp, *fptemp;
+	dst_key_t *key = NULL;
+
+	result = isc_file_exists(trustedkey);
 	if (result !=  ISC_TRUE) {
-		result  = isc_file_exists("/etc/trusted-key.key");
+		result = isc_file_exists("/etc/trusted-key.key");
 		if (result !=  ISC_TRUE) {
-			result  = isc_file_exists("./trusted-key.key");
+			result = isc_file_exists("./trusted-key.key");
 			if (result !=  ISC_TRUE)
-				return ISC_R_FAILURE;
+				return (ISC_R_FAILURE);
 			else
 				filename = "./trusted-key.key";
-		}
-		else
+		} else
 			filename = "/etc/trusted-key.key";
-	}
-	else
+	} else
 		filename = trustedkey;
 
 	if (filename == NULL) {
 		printf("No trusted key\n");
-		return ISC_R_FAILURE;
+		return (ISC_R_FAILURE);
 	}
 
 	if ((fp = fopen(filename, "r")) == NULL) {
 		printf("get_trusted_key(): trusted key not found %s\n",
 		       filename);
-		return ISC_R_FAILURE;
+		return (ISC_R_FAILURE);
 	}
 	while (fgets(buf, 1500, fp) != NULL) {
 		result = opentmpkey(mctx,"tmp_file", &filetemp, &fptemp);
 		if (result != ISC_R_SUCCESS) {
 			fclose(fp);
-			return ISC_R_FAILURE;
+			return (ISC_R_FAILURE);
 		}
-		if (fputs(buf, fptemp)<0) {
+		if (fputs(buf, fptemp) < 0) {
 			fclose(fp);
 			fclose(fptemp);
-			return ISC_R_FAILURE;
+			return (ISC_R_FAILURE);
 		}
 		fclose(fptemp);
 		result = dst_key_fromnamedfile(filetemp, DST_TYPE_PUBLIC,
 					       mctx, &key);
 		removetmpkey(mctx, filetemp);
 		isc_mem_free(mctx, filetemp);
-		if (result !=  ISC_R_SUCCESS ) {
+		if (result !=  ISC_R_SUCCESS) {
 			fclose(fp);
-			return ISC_R_FAILURE;
+			return (ISC_R_FAILURE);
 		}
 		insert_trustedkey(key);
 #if 0
@@ -3625,7 +3598,7 @@ get_trusted_key(isc_mem_t *mctx)
 #endif
 		key = NULL;
 	}
-	return ISC_R_SUCCESS;
+	return (ISC_R_SUCCESS);
 }
 
 
@@ -3648,19 +3621,19 @@ nameFromString(const char *str, dns_name_t *p_ret) {
 	check_result(result, "nameFromString");
 
 	if (dns_name_dynamic(p_ret))
-		dns_name_free(p_ret, mctx);
-  
+		free_name(p_ret, mctx);
+
 	result = dns_name_dup(dns_fixedname_name(&fixedname), mctx, p_ret);
 	check_result(result, "nameFromString");
-} 
+}
 
 
 #if DIG_SIGCHASE_TD
-isc_result_t 
+isc_result_t
 prepare_lookup(dns_name_t *name)
 {
-	isc_result_t    result;
-	dig_lookup_t  * lookup = NULL;
+	isc_result_t result;
+	dig_lookup_t *lookup = NULL;
 	dig_server_t *s;
 	void *ptr;
 
@@ -3674,7 +3647,7 @@ prepare_lookup(dns_name_t *name)
 	lookup->rdtype = lookup->rdtype_sigchase;
 	lookup->rdtypeset = ISC_TRUE;
 	lookup->qrdtype = lookup->qrdtype_sigchase;
-   
+
 	s = ISC_LIST_HEAD(lookup->my_server_list);
 	while (s != NULL) {
 		debug("freeing server %p belonging to %p",
@@ -3685,7 +3658,7 @@ prepare_lookup(dns_name_t *name)
 				 (dig_server_t *)ptr, link);
 		isc_mem_free(mctx, ptr);
 	}
-  
+
 
 	for (result = dns_rdataset_first(chase_nsrdataset);
 	     result == ISC_R_SUCCESS;
@@ -3694,13 +3667,13 @@ prepare_lookup(dns_name_t *name)
 		dns_rdata_ns_t ns;
 		dns_rdata_t rdata = DNS_RDATA_INIT;
 		dig_server_t * srv = NULL;
-#define  __FOLLOW_GLUE__
+#define __FOLLOW_GLUE__
 #ifdef __FOLLOW_GLUE__
-		isc_buffer_t * b = NULL;
+		isc_buffer_t *b = NULL;
 		isc_result_t result;
 		isc_region_t r;
-		dns_rdataset_t * rdataset =NULL;
-		isc_boolean_t   true = ISC_TRUE;
+		dns_rdataset_t *rdataset = NULL;
+		isc_boolean_t true = ISC_TRUE;
 #endif
 
 		memset(namestr, 0, DNS_NAME_FORMATSIZE);
@@ -3708,11 +3681,11 @@ prepare_lookup(dns_name_t *name)
 		dns_rdataset_current(chase_nsrdataset, &rdata);
 
 		(void)dns_rdata_tostruct(&rdata, &ns, NULL);
-      
-     
-      
+
+
+
 #ifdef __FOLLOW_GLUE__
-      
+
 		result = advanced_rrsearch(&rdataset, &ns.name,
 					   dns_rdatatype_aaaa,
 					   dns_rdatatype_any, &true);
@@ -3736,12 +3709,12 @@ prepare_lookup(dns_name_t *name)
 
 
 				srv = make_server(namestr, namestr);
-	     
+	
 				ISC_LIST_APPEND(lookup->my_server_list,
 						srv, link);
 			}
 		}
-      
+
 		rdataset = NULL;
 		result = advanced_rrsearch(&rdataset, &ns.name, dns_rdatatype_a,
 					   dns_rdatatype_any, &true);
@@ -3763,28 +3736,28 @@ prepare_lookup(dns_name_t *name)
 				isc_buffer_free(&b);
 				dns_rdata_reset(&a);
 				printf("ns name: %s\n", namestr);
-      
+
 
 				srv = make_server(namestr, namestr);
-	     
+	
 				ISC_LIST_APPEND(lookup->my_server_list,
 						srv, link);
 			}
 		}
 #else
-       
+
 		dns_name_format(&ns.name, namestr, sizeof(namestr));
 		printf("ns name: ");
 		dns_name_print(&ns.name, stdout);
 		printf("\n");
 		srv = make_server(namestr, namestr);
-	     
+	
 		ISC_LIST_APPEND(lookup->my_server_list, srv, link);
 
-#endif 
+#endif
 		dns_rdata_freestruct(&ns);
 		dns_rdata_reset(&rdata);
-      
+
 	}
 
 	ISC_LIST_APPEND(lookup_list, lookup, link);
@@ -3794,7 +3767,7 @@ prepare_lookup(dns_name_t *name)
 	printf(" with nameservers:");
 	printf("\n");
 	print_rdataset(name, chase_nsrdataset, mctx);
-	return ISC_R_SUCCESS;
+	return (ISC_R_SUCCESS);
 }
 
 
@@ -3807,15 +3780,14 @@ child_of_zone(dns_name_t * name, dns_name_t * zone_name,
 	unsigned int nlabelsp;
 
 	name_reln = dns_name_fullcompare(name, zone_name, &orderp, &nlabelsp);
-	if ( (name_reln != dns_namereln_subdomain) ||
-	     (dns_name_countlabels(name) <=
-	      dns_name_countlabels(zone_name) +1)) {
+	if (name_reln != dns_namereln_subdomain ||
+	    dns_name_countlabels(name) <= dns_name_countlabels(zone_name) + 1) {
 		printf("\n;; ERROR : ");
 		dns_name_print(name, stdout);
 		printf(" is not a subdomain of: ");
 		dns_name_print(zone_name, stdout);
 		printf(" FAILED\n\n");
-		return ISC_R_FAILURE;
+		return (ISC_R_FAILURE);
 	}
 
 	dns_name_getlabelsequence(name,
@@ -3823,11 +3795,11 @@ child_of_zone(dns_name_t * name, dns_name_t * zone_name,
 				  dns_name_countlabels(zone_name) -1,
 				  dns_name_countlabels(zone_name) +1,
 				  child_name);
-	return ISC_R_SUCCESS;
+	return (ISC_R_SUCCESS);
 }
 
 isc_result_t
-grandfather_pb_test(dns_name_t * zone_name, dns_rdataset_t  * sigrdataset)
+grandfather_pb_test(dns_name_t *zone_name, dns_rdataset_t  *sigrdataset)
 {
 	isc_result_t result;
 	dns_rdata_t sigrdata;
@@ -3836,31 +3808,31 @@ grandfather_pb_test(dns_name_t * zone_name, dns_rdataset_t  * sigrdataset)
 	result = dns_rdataset_first(sigrdataset);
 	check_result(result, "empty RRSIG dataset");
 	dns_rdata_init(&sigrdata);
-  
+
 	do {
 		dns_rdataset_current(sigrdataset, &sigrdata);
-    
+
 		result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL);
 		check_result(result, "sigrdata tostruct siginfo");
- 
+
 		if (dns_name_compare(&siginfo.signer, zone_name) == 0) {
 			dns_rdata_freestruct(&siginfo);
 			dns_rdata_reset(&sigrdata);
-			return ISC_R_SUCCESS;
+			return (ISC_R_SUCCESS);
 		}
 
 		dns_rdata_freestruct(&siginfo);
- 
+
 	} while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS);
 
 	dns_rdata_reset(&sigrdata);
 
-	return ISC_R_FAILURE;
+	return (ISC_R_FAILURE);
 }
 
 
 isc_result_t
-initialization(dns_name_t * name)
+initialization(dns_name_t *name)
 {
 	isc_result_t   result;
 	isc_boolean_t  true = ISC_TRUE;
@@ -3871,21 +3843,21 @@ initialization(dns_name_t * name)
 	if (result != ISC_R_SUCCESS) {
 		printf("\n;; NS RRset is missing to continue validation:"
 		       " FAILED\n\n");
-		return ISC_R_FAILURE;
+		return (ISC_R_FAILURE);
 	}
 	INSIST(chase_nsrdataset != NULL);
 	prepare_lookup(name);
 
 	dup_name(name, &chase_current_name, mctx);
 
-	return ISC_R_SUCCESS;
+	return (ISC_R_SUCCESS);
 }
-#endif 
+#endif
 
 void
-print_rdataset(dns_name_t * name, dns_rdataset_t *rdataset, isc_mem_t *mctx)
+print_rdataset(dns_name_t *name, dns_rdataset_t *rdataset, isc_mem_t *mctx)
 {
-	isc_buffer_t * b = NULL;
+	isc_buffer_t *b = NULL;
 	isc_result_t result;
 	isc_region_t r;
 
@@ -3904,16 +3876,22 @@ print_rdataset(dns_name_t * name, dns_rdataset_t *rdataset, isc_mem_t *mctx)
 }
 
 
-void 
+void
 dup_name(dns_name_t *source, dns_name_t *target, isc_mem_t *mctx) {
-	isc_result_t result; 
- 
+	isc_result_t result;
+
 	if (dns_name_dynamic(target))
-		dns_name_free(target, mctx);
+		free_name(target, mctx);
 	result = dns_name_dup(source, mctx, target);
 	check_result(result, "dns_name_dup");
 }
 
+void
+free_name(dns_name_t *name, isc_mem_t *mctx) {
+	dns_name_free(name, mctx);
+	dns_name_init(name, NULL);
+}
+
 /*
  *
  * take a DNSKEY RRset and the RRSIG RRset corresponding in parameter
@@ -3931,13 +3909,12 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset,
 {
 	isc_result_t result;
 	dns_rdata_t rdata;
-	dst_key_t * trustedKey = NULL;
-	dst_key_t * dnsseckey = NULL;
+	dst_key_t *trustedKey = NULL;
+	dst_key_t *dnsseckey = NULL;
 	int i;
-  
-	if (name == NULL || rdataset == NULL) {
-		return ISC_R_FAILURE;
-	}
+
+	if (name == NULL || rdataset == NULL)
+		return (ISC_R_FAILURE);
 
 	result = dns_rdataset_first(rdataset);
 	check_result(result, "empty rdataset");
@@ -3946,13 +3923,13 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset,
 	do {
 		dns_rdataset_current(rdataset, &rdata);
 		INSIST(rdata.type == dns_rdatatype_dnskey);
-  	  
+  	
 		result = dns_dnssec_keyfromrdata(name, &rdata,
 						 mctx, &dnsseckey);
 		check_result(result, "dns_dnssec_keyfromrdata");
 
-    
-		for (i = 0; i< tk_list.nb_tk; i++) {
+
+		for (i = 0; i < tk_list.nb_tk; i++) {
 			if (dst_key_compare(tk_list.key[i], dnsseckey)
 			    == ISC_TRUE) {
 				dns_rdata_reset(&rdata);
@@ -3967,11 +3944,11 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset,
 				    == ISC_R_SUCCESS) {
 					dst_key_free(&dnsseckey);
 					dnsseckey = NULL;
-					return  ISC_R_SUCCESS;
+					return (ISC_R_SUCCESS);
 				}
 			}
 		}
- 
+
 		dns_rdata_reset(&rdata);
 		if (dnsseckey != NULL)
 			dst_key_free(&dnsseckey);
@@ -3980,8 +3957,8 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset,
 	if (trustedKey != NULL)
 		dst_key_free(&trustedKey);
 	trustedKey = NULL;
-  
-	return ISC_R_NOTFOUND;
+
+	return (ISC_R_NOTFOUND);
 }
 
 isc_result_t
@@ -3992,7 +3969,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset,
 {
 	isc_result_t result;
 	dns_rdata_t keyrdata;
-	dst_key_t * dnsseckey = NULL;
+	dst_key_t *dnsseckey = NULL;
 
 	result = dns_rdataset_first(keyrdataset);
 	check_result(result, "empty DNSKEY dataset");
@@ -4001,7 +3978,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset,
 	do {
 		dns_rdataset_current(keyrdataset, &keyrdata);
 		INSIST(keyrdata.type == dns_rdatatype_dnskey);
-  	  
+  	
 		result = dns_dnssec_keyfromrdata(name, &keyrdata,
 						 mctx, &dnsseckey);
 		check_result(result, "dns_dnssec_keyfromrdata");
@@ -4011,20 +3988,20 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset,
 		if (result == ISC_R_SUCCESS) {
 			dns_rdata_reset(&keyrdata);
 			dst_key_free(&dnsseckey);
-			return(ISC_R_SUCCESS);
+			return (ISC_R_SUCCESS);
 		}
 		dst_key_free(&dnsseckey);
 	} while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS);
-  
+
 	dns_rdata_reset(&keyrdata);
-  
-	return ISC_R_NOTFOUND;
+
+	return (ISC_R_NOTFOUND);
 }
 
 isc_result_t
 sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset,
-			dst_key_t* dnsseckey,
-			dns_rdataset_t *sigrdataset, isc_mem_t *mctx)
+			dst_key_t *dnsseckey, dns_rdataset_t *sigrdataset,
+			isc_mem_t *mctx)
 {
 	isc_result_t result;
 	dns_rdata_t sigrdata;
@@ -4033,22 +4010,22 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset,
 	result = dns_rdataset_first(sigrdataset);
 	check_result(result, "empty RRSIG dataset");
 	dns_rdata_init(&sigrdata);
-    
+
 	do {
 		dns_rdataset_current(sigrdataset, &sigrdata);
 
 		result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL);
 		check_result(result, "sigrdata tostruct siginfo");
- 
+
 		/*
 		 * Test if the id of the DNSKEY is
 		 * the id of the DNSKEY signer's
 		 */
 		if (siginfo.keyid == dst_key_id(dnsseckey)) {
-    
+
 			result = dns_rdataset_first(rdataset);
 			check_result(result, "empty DS dataset");
-    
+
 			result = dns_dnssec_verify(name, rdataset, dnsseckey,
 						   ISC_FALSE, mctx, &sigrdata);
 
@@ -4058,19 +4035,19 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset,
 			dns_name_print(name, stdout);
 			printf(" with DNSKEY:%d: %s\n", dst_key_id(dnsseckey),
 			       isc_result_totext(result));
-	 
+
 			if (result == ISC_R_SUCCESS) {
 				dns_rdata_reset(&sigrdata);
-				return result;
+				return (result);
 			}
 		}
 		dns_rdata_freestruct(&siginfo);
- 
+
 	} while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS);
 
 	dns_rdata_reset(&sigrdata);
 
-	return ISC_R_NOTFOUND;
+	return (ISC_R_NOTFOUND);
 }
 
 
@@ -4083,7 +4060,7 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 	dns_rdata_t newdsrdata;
 	dns_rdata_t dsrdata;
 	dns_rdata_ds_t dsinfo;
-	dst_key_t* dnsseckey = NULL;
+	dst_key_t *dnsseckey = NULL;
 	unsigned char dsbuf[DNS_DS_BUFFERSIZE];
 
 	result = dns_rdataset_first(dsrdataset);
@@ -4091,18 +4068,18 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 	dns_rdata_init(&dsrdata);
 	do {
 		dns_rdataset_current(dsrdataset, &dsrdata);
-    
+
 		result = dns_rdata_tostruct(&dsrdata, &dsinfo, NULL);
 		check_result(result, "dns_rdata_tostruct  for DS");
-    
+
 		result = dns_rdataset_first(keyrdataset);
 		check_result(result, "empty KEY dataset");
-		dns_rdata_init(&keyrdata);	  
+		dns_rdata_init(&keyrdata);	
 
 		do {
 			dns_rdataset_current(keyrdataset, &keyrdata);
 			INSIST(keyrdata.type == dns_rdatatype_dnskey);
-  	  
+  	
 			result = dns_dnssec_keyfromrdata(name, &keyrdata,
 							 mctx, &dnsseckey);
 			check_result(result, "dns_dnssec_keyfromrdata");
@@ -4117,17 +4094,17 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 				result = dns_ds_buildrdata(name, &keyrdata,
 							   dsinfo.digest_type,
 							   dsbuf, &newdsrdata);
-				dns_rdata_freestruct(&dsinfo);  
+				dns_rdata_freestruct(&dsinfo);
 
 				if (result != ISC_R_SUCCESS) {
 					dns_rdata_reset(&keyrdata);
 					dns_rdata_reset(&newdsrdata);
 					dns_rdata_reset(&dsrdata);
 					dst_key_free(&dnsseckey);
-					dns_rdata_freestruct(&dsinfo);  
+					dns_rdata_freestruct(&dsinfo);
 					printf("Oops: impossible to build"
 					       " new DS rdata\n");
-					return result;
+					return (result);
 				}
 	
 	
@@ -4138,7 +4115,7 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 					printf(";; Now verify that this"
 					       " DNSKEY validates the "
 					       "DNSKEY RRset\n");
-	       
+	
 					result = sigchase_verify_sig_key(name,
 							 keyrdataset,
 							 dnsseckey,
@@ -4149,11 +4126,10 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 						dns_rdata_reset(&newdsrdata);
 						dns_rdata_reset(&dsrdata);
 						dst_key_free(&dnsseckey);
-		 
-						return result;
+		
+						return (result);
 					}
-				} 
-				else {
+				} else {
 					printf(";; This DS is NOT the DS for"
 					       " the chasing KEY: FAILED\n");
 				}
@@ -4164,13 +4140,13 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 			dnsseckey = NULL;
 		} while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS);
 		dns_rdata_reset(&keyrdata);
- 
+
 	} while (dns_rdataset_next(chase_dsrdataset) == ISC_R_SUCCESS);
 #if 0
 	dns_rdata_reset(&dsrdata); WARNING
 #endif
- 
-	return ISC_R_NOTFOUND;
+
+	return (ISC_R_NOTFOUND);
 }
 
 /*
@@ -4182,20 +4158,19 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
  * ISC_R_SUCCESS: if we found the rrset
  * ISC_R_NOTFOUND: we do not found the rrset in cache
  * and we do a query on the net
- * ISC_R_FAILURE: rrset not found 
+ * ISC_R_FAILURE: rrset not found
  */
 isc_result_t
-advanced_rrsearch(dns_rdataset_t **rdataset, dns_name_t * name,
-		  dns_rdatatype_t type,
-		  dns_rdatatype_t covers,
+advanced_rrsearch(dns_rdataset_t **rdataset, dns_name_t *name,
+		  dns_rdatatype_t type, dns_rdatatype_t covers,
 		  isc_boolean_t *lookedup)
-{ 
+{
 	isc_boolean_t  tmplookedup;
 
 	INSIST(rdataset != NULL);
 
 	if (*rdataset != NULL)
-		return(ISC_R_SUCCESS);
+		return (ISC_R_SUCCESS);
 
 	tmplookedup = *lookedup;
 	if ((*rdataset = sigchase_scanname(type, covers,
@@ -4205,20 +4180,19 @@ advanced_rrsearch(dns_rdataset_t **rdataset, dns_name_t * name,
 		return (ISC_R_NOTFOUND);
 	}
 	*lookedup = ISC_FALSE;
-	return(ISC_R_SUCCESS);
+	return (ISC_R_SUCCESS);
 }
 
 
 
 #if DIG_SIGCHASE_TD
 void
-sigchase_td(dns_message_t * msg)
+sigchase_td(dns_message_t *msg)
 {
-	isc_result_t    result;
-	dns_name_t    * name = NULL;
-	isc_boolean_t   have_answer = ISC_FALSE;
- 
-	isc_boolean_t   true = ISC_TRUE;
+	isc_result_t result;
+	dns_name_t *name = NULL;
+	isc_boolean_t have_answer = ISC_FALSE;
+	isc_boolean_t true = ISC_TRUE;
 
 	if ((result = dns_message_firstname(msg, DNS_SECTION_ANSWER))
 	    == ISC_R_SUCCESS) {
@@ -4228,8 +4202,7 @@ sigchase_td(dns_message_t * msg)
 			return;
 		}
 		have_answer = true;
-	}
-	else {
+	} else {
 		if (!current_lookup->trace_root_sigchase) {
 			result = dns_message_firstname(msg,
 						       DNS_SECTION_AUTHORITY);
@@ -4249,8 +4222,7 @@ sigchase_td(dns_message_t * msg)
 				       " in authority section:");
 				dns_name_print(name, stdout);
 				printf("\n");
-			}
-			else {
+			} else {
 				printf("no response and no delegation in "
 				       "authority section but a reference"
 				       " to: ");
@@ -4258,17 +4230,16 @@ sigchase_td(dns_message_t * msg)
 				printf("\n");
 				error_message = msg;
 			}
-		}
-		else {
+		} else {
 			printf(";; NO ANSWERS: %s\n",
 			       isc_result_totext(result));
-			dns_name_free(&chase_name, mctx);
+			free_name(&chase_name, mctx);
 			clean_trustedkey();
 			return;
 		}
 	}
 
-   
+
 	if (have_answer) {
 		chase_rdataset
 			= chase_scanname_section(msg, &chase_name,
@@ -4320,8 +4291,7 @@ sigchase_td(dns_message_t * msg)
 						      chase_keyrdataset,
 						      chase_sigkeyrdataset,
 						      mctx);
-		} 
-		else {
+		} else {
 			INSIST(chase_dsrdataset != NULL);
 			INSIST(chase_sigdsrdataset != NULL);
 			result = sigchase_verify_ds(&chase_current_name,
@@ -4329,13 +4299,12 @@ sigchase_td(dns_message_t * msg)
 						    chase_dsrdataset,
 						    mctx);
 		}
-      
+
 		if (result != ISC_R_SUCCESS) {
 			printf("\n;; chain of trust can't be validated:"
 			       " FAILED\n\n");
 			goto cleanandgo;
-		}
-		else {
+		} else {
 			chase_dsrdataset = NULL;
 			chase_sigdsrdataset = NULL;
 		}
@@ -4357,9 +4326,8 @@ sigchase_td(dns_message_t * msg)
 				       " FAILED\n\n");
 				goto cleanandgo;
 			}
-	 
-		}
-		else {
+
+		} else {
 			result = advanced_rrsearch(&chase_sigrdataset,
 						   &chase_authority_name,
 						   dns_rdatatype_rrsig,
@@ -4383,20 +4351,19 @@ sigchase_td(dns_message_t * msg)
 			chase_sigrdataset = NULL;
 			have_response = ISC_FALSE;
 			have_delegation_ns = ISC_FALSE;
-	  
+	
 			dns_name_init(&tmp_name, NULL);
 			result = child_of_zone(&chase_name, &chase_current_name,
 					       &tmp_name);
 			if (dns_name_dynamic(&chase_authority_name))
-				dns_name_free( &chase_authority_name, mctx);
+				free_name(&chase_authority_name, mctx);
 			dup_name(&tmp_name, &chase_authority_name, mctx);
 			printf(";; and we try to continue chain of trust"
 			       " validation of the zone: ");
 			dns_name_print(&chase_authority_name, stdout);
 			printf("\n");
 			have_delegation_ns = ISC_TRUE;
-		}
-		else {
+		} else {
 			if (have_response)
 				goto finalstep;
 			else
@@ -4420,7 +4387,7 @@ sigchase_td(dns_message_t * msg)
 			return;
 		}
 		INSIST(chase_nsrdataset != NULL);
-  
+
 		result = advanced_rrsearch(&chase_dsrdataset,
 					   &chase_authority_name,
 					   dns_rdatatype_ds,
@@ -4463,8 +4430,8 @@ sigchase_td(dns_message_t * msg)
 		}
 		chase_keyrdataset = NULL;
 		chase_sigkeyrdataset = NULL;
-    
- 
+
+
 		prepare_lookup(&chase_authority_name);
 	
 		have_response = ISC_FALSE;
@@ -4472,24 +4439,24 @@ sigchase_td(dns_message_t * msg)
 		delegation_follow = ISC_TRUE;
 		error_message = NULL;
 		dup_name(&chase_authority_name, &chase_current_name, mctx);
-		dns_name_free(&chase_authority_name, mctx);
+		free_name(&chase_authority_name, mctx);
 		return;
 	}
 
-  
+
 	if (error_message != NULL) {
-		dns_rdataset_t * rdataset;
-		dns_rdataset_t * sigrdataset;
-		dns_name_t       rdata_name;
-		isc_result_t     ret = ISC_R_FAILURE;
+		dns_rdataset_t *rdataset;
+		dns_rdataset_t *sigrdataset;
+		dns_name_t rdata_name;
+		isc_result_t ret = ISC_R_FAILURE;
 
 		dns_name_init(&rdata_name, NULL);
 		result = prove_nx(error_message, &chase_name,
 				  current_lookup->rdclass_sigchase,
 				  current_lookup->rdtype_sigchase, &rdata_name,
 				  &rdataset, &sigrdataset);
-		if (&rdata_name == NULL || rdataset == NULL ||
-		    sigrdataset == NULL) {
+		if (rdataset == NULL || sigrdataset == NULL ||
+		    dns_name_countlabels(&rdata_name) == 0) {
 			printf("\n;; Impossible to verify the non-existence,"
 			       " the NSEC RRset can't be validated:"
 			       " FAILED\n\n");
@@ -4499,18 +4466,17 @@ sigchase_td(dns_message_t * msg)
 					  chase_keyrdataset,
 					  sigrdataset, mctx);
 		if (ret != ISC_R_SUCCESS) {
-			dns_name_free(&rdata_name, mctx);
+			free_name(&rdata_name, mctx);
 			printf("\n;; Impossible to verify the NSEC RR to prove"
 			       " the non-existence : FAILED\n\n");
 			goto cleanandgo;
 		}
-		dns_name_free(&rdata_name, mctx);
+		free_name(&rdata_name, mctx);
 		if (result != ISC_R_SUCCESS) {
 			printf("\n;; Impossible to verify the non-existence:"
 			       " FAILED\n\n");
 			goto cleanandgo;
-		}
-		else {
+		} else {
 			printf("\n;; OK the query doesn't have response but"
 			       " we have validate this fact : SUCCESS\n\n");
 			goto cleanandgo;
@@ -4520,9 +4486,9 @@ sigchase_td(dns_message_t * msg)
  cleanandgo:
 	printf(";; cleanandgo \n");
 	if (dns_name_dynamic(&chase_current_name))
-		dns_name_free(&chase_current_name, mctx);
+		free_name(&chase_current_name, mctx);
 	if (dns_name_dynamic(&chase_authority_name))
-		dns_name_free(&chase_authority_name, mctx);
+		free_name(&chase_authority_name, mctx);
 	clean_trustedkey();
 	return;
 
@@ -4551,8 +4517,7 @@ sigchase_td(dns_message_t * msg)
 		  printf("\n");
 		*/
 		goto cleanandgo;
-	}
-	else {
+	} else {
 		printf("\n;; The Answer:\n");
 		print_rdataset(&chase_name , chase_rdataset, mctx);
 
@@ -4562,7 +4527,7 @@ sigchase_td(dns_message_t * msg)
 	}
 }
 
-#endif 
+#endif
 
 
 #if DIG_SIGCHASE_BU
@@ -4579,12 +4544,10 @@ getneededrr(dns_message_t *msg)
 	if ((result = dns_message_firstname(msg, DNS_SECTION_ANSWER))
 	    != ISC_R_SUCCESS) {
 		printf(";; NO ANSWERS: %s\n", isc_result_totext(result));
-    
-		if (chase_name.ndata == NULL) {
-			return ISC_R_ADDRNOTAVAIL;
-		}
-	}
-	else {
+
+		if (chase_name.ndata == NULL)
+			return (ISC_R_ADDRNOTAVAIL);
+	} else {
 		dns_message_currentname(msg, DNS_SECTION_ANSWER, &name);
 	}
 
@@ -4595,7 +4558,7 @@ getneededrr(dns_message_t *msg)
 					   dns_rdatatype_any, &true);
 		if (result != ISC_R_SUCCESS) {
 			printf("\n;; No Answers: Validation FAILED\n\n");
-			return ISC_R_NOTFOUND;
+			return (ISC_R_NOTFOUND);
 		}
 		dup_name(name, &chase_name, mctx);
 		printf(";; RRset to chase:\n");
@@ -4613,18 +4576,18 @@ getneededrr(dns_message_t *msg)
 			printf("\n;; RRSIG is missing for continue validation:"
 			       " FAILED\n\n");
 			if (dns_name_dynamic(&chase_name))
-				dns_name_free(&chase_name, mctx);
-			return ISC_R_NOTFOUND;
+				free_name(&chase_name, mctx);
+			return (ISC_R_NOTFOUND);
 		}
 		if (result == ISC_R_NOTFOUND) {
-			return(ISC_R_NOTFOUND);
+			return (ISC_R_NOTFOUND);
 		}
 		printf("\n;; RRSIG of the RRset to chase:\n");
 		print_rdataset(&chase_name, chase_sigrdataset, mctx);
 	}
 	INSIST(chase_sigrdataset != NULL);
 
- 
+
 	/* first find the DNSKEY name */
 	result = dns_rdataset_first(chase_sigrdataset);
 	check_result(result, "empty RRSIG dataset");
@@ -4635,7 +4598,7 @@ getneededrr(dns_message_t *msg)
 	dup_name(&siginfo.signer, &chase_signame, mctx);
 	dns_rdata_freestruct(&siginfo);
 	dns_rdata_reset(&sigrdata);
- 
+
 	/* Do we have a key?  */
 	if (chase_keyrdataset == NULL) {
 		result = advanced_rrsearch(&chase_keyrdataset,
@@ -4646,14 +4609,14 @@ getneededrr(dns_message_t *msg)
 		if (result == ISC_R_FAILURE) {
 			printf("\n;; DNSKEY is missing to continue validation:"
 			       " FAILED\n\n");
-			dns_name_free(&chase_signame, mctx);
+			free_name(&chase_signame, mctx);
 			if (dns_name_dynamic(&chase_name))
-				dns_name_free(&chase_name, mctx);
-			return ISC_R_NOTFOUND;
+				free_name(&chase_name, mctx);
+			return (ISC_R_NOTFOUND);
 		}
 		if (result == ISC_R_NOTFOUND) {
-			dns_name_free(&chase_signame, mctx);
-			return(ISC_R_NOTFOUND);
+			free_name(&chase_signame, mctx);
+			return (ISC_R_NOTFOUND);
 		}
 		printf("\n;; DNSKEYset that signs the RRset to chase:\n");
 		print_rdataset(&chase_signame, chase_keyrdataset, mctx);
@@ -4669,14 +4632,14 @@ getneededrr(dns_message_t *msg)
 		if (result == ISC_R_FAILURE) {
 			printf("\n;; RRSIG for DNSKEY  is missing  to continue"
 			       " validation : FAILED\n\n");
-			dns_name_free(&chase_signame, mctx);
+			free_name(&chase_signame, mctx);
 			if (dns_name_dynamic(&chase_name))
-				dns_name_free(&chase_name, mctx);
-			return ISC_R_NOTFOUND;
+				free_name(&chase_name, mctx);
+			return (ISC_R_NOTFOUND);
 		}
 		if (result == ISC_R_NOTFOUND) {
-			dns_name_free(&chase_signame, mctx);
-			return(ISC_R_NOTFOUND);
+			free_name(&chase_signame, mctx);
+			return (ISC_R_NOTFOUND);
 		}
 		printf("\n;; RRSIG of the DNSKEYset that signs the "
 		       "RRset to chase:\n");
@@ -4696,15 +4659,15 @@ getneededrr(dns_message_t *msg)
 			printf("\n");
 		}
 		if (result == ISC_R_NOTFOUND) {
-			dns_name_free(&chase_signame, mctx);
-			return(ISC_R_NOTFOUND);
+			free_name(&chase_signame, mctx);
+			return (ISC_R_NOTFOUND);
 		}
 		if (chase_dsrdataset != NULL) {
 			printf("\n;; DSset of the DNSKEYset\n");
 			print_rdataset(&chase_signame, chase_dsrdataset, mctx);
 		}
 	}
- 
+
 	if (chase_dsrdataset != NULL) {
 		/*
 		 * if there is no RRSIG of DS,
@@ -4722,14 +4685,13 @@ getneededrr(dns_message_t *msg)
 			 * because the DNSKEY could be a Trusted Key.
 			 */
 			chase_dsrdataset = NULL;
-		}
-		else {
+		} else {
 			printf("\n;; RRSIG of the DSset of the DNSKEYset\n");
 			print_rdataset(&chase_signame, chase_sigdsrdataset,
 				       mctx);
 		}
 	}
-	return(1);
+	return (1);
 }
 
 
@@ -4748,28 +4710,29 @@ sigchase_bu(dns_message_t *msg)
 		}
 	}
 
-  
+
 	ret = getneededrr(msg);
 	if (ret == ISC_R_NOTFOUND)
 		return;
 
 	if (ret == ISC_R_ADDRNOTAVAIL) {
 		/* We have no response */
-		dns_rdataset_t * rdataset;
-		dns_rdataset_t * sigrdataset;
-		dns_name_t       rdata_name;
-		dns_name_t       query_name;
+		dns_rdataset_t *rdataset;
+		dns_rdataset_t *sigrdataset;
+		dns_name_t rdata_name;
+		dns_name_t query_name;
 
 
 		dns_name_init(&query_name, NULL);
+		dns_name_init(&rdata_name, NULL);
 		nameFromString(current_lookup->textname, &query_name);
-   
+
 		result = prove_nx(msg, &query_name, current_lookup->rdclass,
 				  current_lookup->rdtype, &rdata_name,
 				  &rdataset, &sigrdataset);
-		dns_name_free(&query_name, mctx);
-		if (&rdata_name == NULL || rdataset == NULL ||
-		    sigrdataset == NULL) {
+		free_name(&query_name, mctx);
+		if (rdataset == NULL || sigrdataset == NULL ||
+		    dns_name_countlabels(&rdata_name) == 0) {
 			printf("\n;; Impossible to verify the Non-existence,"
 			       " the NSEC RRset can't be validated: "
 			       "FAILED\n\n");
@@ -4787,7 +4750,7 @@ sigchase_bu(dns_message_t *msg)
 		       " Now we want validate this NSEC\n");
 	
 		dup_name(&rdata_name, &chase_name, mctx);
-		dns_name_free(&rdata_name, mctx);
+		free_name(&rdata_name, mctx);
 		chase_rdataset =  rdataset;
 		chase_sigrdataset = sigrdataset;
 		chase_keyrdataset = NULL;
@@ -4802,7 +4765,7 @@ sigchase_bu(dns_message_t *msg)
 		clean_trustedkey();
 		return;
 	}
-  
+
 
 	printf("\n\n\n;; WE HAVE MATERIAL, WE NOW DO VALIDATION\n");
 
@@ -4810,8 +4773,8 @@ sigchase_bu(dns_message_t *msg)
 				     chase_keyrdataset,
 				     chase_sigrdataset, mctx);
 	if (result != ISC_R_SUCCESS) {
-		dns_name_free(&chase_name, mctx);
-		dns_name_free(&chase_signame, mctx);
+		free_name(&chase_name, mctx);
+		free_name(&chase_signame, mctx);
 		printf(";; No DNSKEY is valid to check the RRSIG"
 		       " of the RRset: FAILED\n");
 		clean_trustedkey();
@@ -4822,8 +4785,8 @@ sigchase_bu(dns_message_t *msg)
 	result = contains_trusted_key(&chase_signame, chase_keyrdataset,
 				      chase_sigkeyrdataset, mctx);
 	if (result ==  ISC_R_SUCCESS) {
-		dns_name_free(&chase_name, mctx);
-		dns_name_free(&chase_signame, mctx);
+		free_name(&chase_name, mctx);
+		free_name(&chase_signame, mctx);
 		printf("\n;; Ok this DNSKEY is a Trusted Key,"
 		       " DNSSEC validation is ok: SUCCESS\n\n");
 		clean_trustedkey();
@@ -4833,8 +4796,8 @@ sigchase_bu(dns_message_t *msg)
 	printf(";; Now, we are going to validate this DNSKEY by the DS\n");
 
 	if (chase_dsrdataset == NULL) {
-		dns_name_free(&chase_name, mctx);
-		dns_name_free(&chase_signame, mctx);
+		free_name(&chase_name, mctx);
+		free_name(&chase_signame, mctx);
 		printf(";; the DNSKEY isn't trusted-key and there isn't"
 		       " DS to validate the DNSKEY: FAILED\n");
 		clean_trustedkey();
@@ -4844,21 +4807,20 @@ sigchase_bu(dns_message_t *msg)
 	result =  sigchase_verify_ds(&chase_signame, chase_keyrdataset,
 				     chase_dsrdataset, mctx);
 	if (result !=  ISC_R_SUCCESS) {
-		dns_name_free(&chase_signame, mctx);
-		dns_name_free(&chase_name, mctx);
+		free_name(&chase_signame, mctx);
+		free_name(&chase_name, mctx);
 		printf(";; ERROR no DS validates a DNSKEY in the"
 		       " DNSKEY RRset: FAILED\n");
 		clean_trustedkey();
 		return;
-	} 
-	else
+	} else
 		printf(";; OK this DNSKEY (validated by the DS) validates"
 		       " the RRset of the DNSKEYs, thus the DNSKEY validates"
 		       " the RRset\n");
 	INSIST(chase_sigdsrdataset != NULL);
 
 	dup_name(&chase_signame, &chase_name, mctx);
-	dns_name_free(&chase_signame, mctx);
+	free_name(&chase_signame, mctx);
 	chase_rdataset = chase_dsrdataset;
 	chase_sigrdataset = chase_sigdsrdataset;
 	chase_keyrdataset = NULL;
@@ -4867,7 +4829,7 @@ sigchase_bu(dns_message_t *msg)
 	chase_sigdsrdataset = NULL;
 	chase_siglookedup = chase_keylookedup = ISC_FALSE;
 	chase_dslookedup = chase_sigdslookedup = ISC_FALSE;
- 
+
 	printf(";; Now, we want to validate the DS :  recursive call\n");
 	sigchase(msg);
 	return;
@@ -4875,8 +4837,7 @@ sigchase_bu(dns_message_t *msg)
 #endif
 
 void
-sigchase(dns_message_t * msg)
-{
+sigchase(dns_message_t *msg) {
 #if DIG_SIGCHASE_TD
 	if (current_lookup->do_topdown) {
 		sigchase_td(msg);
@@ -4892,12 +4853,12 @@ sigchase(dns_message_t * msg)
 
 /*
  * return 1  if name1  <  name2
- *        0  if name1  == name2
- *        -1 if name1  >  name2
+ *	  0  if name1  == name2
+ *	  -1 if name1  >  name2
  *    and -2 if problem
  */
 int
-inf_name(dns_name_t * name1, dns_name_t * name2)
+inf_name(dns_name_t *name1, dns_name_t *name2)
 {
 	dns_label_t  label1;
 	dns_label_t  label2;
@@ -4920,19 +4881,19 @@ inf_name(dns_name_t * name1, dns_name_t * name2)
 		dns_name_getlabel(name1, nblabel1 -1  - i, &label1);
 		dns_name_getlabel(name2, nblabel2 -1  - i, &label2);
 		if ((ret = isc_region_compare(&label1, &label2)) != 0) {
-			if (ret <0 )
-				return -1;
-			else if (ret >0 )
-				return 1;
+			if (ret < 0)
+				return (-1);
+			else if (ret > 0)
+				return (1);
 		}
 	}
 	if (nblabel1 == nblabel2)
-		return 0;
+		return (0);
 
 	if (nblabel1 < nblabel2)
-		return -1;
+		return (-1);
 	else
-		return 1;
+		return (1);
 }
 
 /**
@@ -4944,24 +4905,24 @@ isc_result_t
 prove_nx_domain(dns_message_t *msg,
 		dns_name_t *name,
 		dns_name_t *rdata_name,
-		dns_rdataset_t ** rdataset,
+		dns_rdataset_t **rdataset,
 		dns_rdataset_t **sigrdataset)
 {
-	isc_result_t      ret = ISC_R_FAILURE;
-	isc_result_t      result = ISC_R_NOTFOUND;
-	dns_rdataset_t  * nsecset = NULL;
-	dns_rdataset_t  * signsecset = NULL ;
-	dns_rdata_t       nsec = DNS_RDATA_INIT;
-	dns_name_t      * nsecname;
-	dns_rdata_nsec_t  nsecstruct;
-  
+	isc_result_t ret = ISC_R_FAILURE;
+	isc_result_t result = ISC_R_NOTFOUND;
+	dns_rdataset_t *nsecset = NULL;
+	dns_rdataset_t *signsecset = NULL ;
+	dns_rdata_t nsec = DNS_RDATA_INIT;
+	dns_name_t *nsecname;
+	dns_rdata_nsec_t nsecstruct;
+
 	if ((result = dns_message_firstname(msg, DNS_SECTION_AUTHORITY))
 	    != ISC_R_SUCCESS) {
 		printf(";; nothing in authority section : impossible to"
 		       " validate the non-existence : FAILED\n");
-		return(ISC_R_FAILURE);
+		return (ISC_R_FAILURE);
 	}
- 
+
 	do {
 		nsecname = NULL;
 		dns_message_currentname(msg, DNS_SECTION_AUTHORITY, &nsecname);
@@ -4989,7 +4950,7 @@ prove_nx_domain(dns_message_t *msg,
 				printf(";; no RRSIG NSEC in authority section:"
 				       " impossible to validate the "
 				       "non-existence: FAILED\n");
-				return(ISC_R_FAILURE);
+				return (ISC_R_FAILURE);
 			}
 
 			ret = dns_rdata_tostruct(&nsec, &nsecstruct, NULL);
@@ -5003,8 +4964,8 @@ prove_nx_domain(dns_message_t *msg,
 				*rdataset = nsecset;
 				*sigrdataset = signsecset;
 				dup_name(nsecname, rdata_name, mctx);
-		
-				return ISC_R_SUCCESS;
+
+				return (ISC_R_SUCCESS);
 			}
 
 			dns_rdata_freestruct(&nsecstruct);
@@ -5015,7 +4976,7 @@ prove_nx_domain(dns_message_t *msg,
 	*rdataset = NULL;
 	*sigrdataset =  NULL;
 	rdata_name = NULL;
-	return(ISC_R_FAILURE);
+	return (ISC_R_FAILURE);
 }
 
 /**
@@ -5026,27 +4987,22 @@ prove_nx_domain(dns_message_t *msg,
  *
  */
 isc_result_t
-prove_nx_type(dns_message_t * msg,
-	      dns_name_t *name,
-	      dns_rdataset_t *nsecset,
-	      dns_rdataclass_t class,
-	      dns_rdatatype_t type,
-	      dns_name_t * rdata_name,
-	      dns_rdataset_t ** rdataset,
-	      dns_rdataset_t ** sigrdataset)
+prove_nx_type(dns_message_t *msg, dns_name_t *name, dns_rdataset_t *nsecset,
+	      dns_rdataclass_t class, dns_rdatatype_t type,
+	      dns_name_t *rdata_name, dns_rdataset_t **rdataset,
+	      dns_rdataset_t **sigrdataset)
 {
-	isc_result_t       ret;
-	dns_rdataset_t   * signsecset;
-	dns_rdata_t        nsec = DNS_RDATA_INIT;
+	isc_result_t ret;
+	dns_rdataset_t *signsecset;
+	dns_rdata_t nsec = DNS_RDATA_INIT;
 
 	UNUSED(class);
-	UNUSED(rdata_name);
-  
+
 	ret = dns_rdataset_first(nsecset);
 	check_result(ret,"dns_rdataset_first");
 	
 	dns_rdataset_current(nsecset, &nsec);
-  
+
 	ret = dns_nsec_typepresent(&nsec, type);
 	if (ret == ISC_R_SUCCESS)
 		printf("OK the NSEC said that the type doesn't exist \n");
@@ -5057,8 +5013,9 @@ prove_nx_type(dns_message_t * msg,
 					    DNS_SECTION_AUTHORITY);
 	if (signsecset == NULL) {
 		printf("There isn't RRSIG NSEC for the zone \n");
-		return ISC_R_FAILURE;
+		return (ISC_R_FAILURE);
 	}
+	dup_name(name, rdata_name, mctx);
 	*rdataset = nsecset;
 	*sigrdataset = signsecset;
 
@@ -5072,17 +5029,12 @@ prove_nx_type(dns_message_t * msg,
  *
  */
 isc_result_t
-prove_nx(dns_message_t * msg,
-	 dns_name_t * name,
-	 dns_rdataclass_t class,
-	 dns_rdatatype_t type,
-	 dns_name_t * rdata_name,
-	 dns_rdataset_t ** rdataset,
-	 dns_rdataset_t ** sigrdataset)
+prove_nx(dns_message_t *msg, dns_name_t *name, dns_rdataclass_t class,
+	 dns_rdatatype_t type, dns_name_t *rdata_name,
+	 dns_rdataset_t **rdataset, dns_rdataset_t **sigrdataset)
 {
 	isc_result_t ret;
-	dns_rdataset_t * nsecset = NULL;
-  
+	dns_rdataset_t *nsecset = NULL;
 
 	printf("We want to prove the non-existance of a type of rdata %d"
 	       " or of the zone: \n", type);
@@ -5091,7 +5043,7 @@ prove_nx(dns_message_t * msg,
 	    != ISC_R_SUCCESS) {
 		printf(";; nothing in authority section : impossible to"
 		       " validate the non-existence : FAILED\n");
-		return(ISC_R_FAILURE);
+		return (ISC_R_FAILURE);
 	}
 
 	nsecset = chase_scanname_section(msg, name, dns_rdatatype_nsec,
@@ -5104,18 +5056,17 @@ prove_nx(dns_message_t * msg,
 				    sigrdataset);
 		if (ret != ISC_R_SUCCESS) {
 			printf("prove_nx: ERROR type exist\n");
-			return(ret);
+			return (ret);
 		} else {
 			printf("prove_nx: OK type does not exist\n");
-			return(ISC_R_SUCCESS);
+			return (ISC_R_SUCCESS);
 		}
 	} else {
 		printf("there is no NSEC for this zone: validating "
 		       "that the zone doesn't exist\n");
 		ret = prove_nx_domain(msg, name, rdata_name,
 				      rdataset, sigrdataset);
-		return(ret);
+		return (ret);
 	}
-	/* Never get here */ 
 }
 #endif
diff --git a/contrib/bind9/bin/dig/host.1 b/contrib/bind9/bin/dig/host.1
index c93ab184b57b..cf44a5c3f35c 100644
--- a/contrib/bind9/bin/dig/host.1
+++ b/contrib/bind9/bin/dig/host.1
@@ -1,132 +1,181 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000-2002  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000-2002 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: host.1,v 1.11.2.1.4.4 2004/04/13 04:11:03 marka Exp $
+.\" $Id: host.1,v 1.11.2.1.4.7 2005/10/13 02:33:43 marka Exp $
 .\"
-.TH "HOST" "1" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "HOST" "1" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 host \- DNS lookup utility
-.SH SYNOPSIS
-.sp
-\fBhost\fR [ \fB-aCdlnrTwv\fR ]  [ \fB-c \fIclass\fB\fR ]  [ \fB-N \fIndots\fB\fR ]  [ \fB-R \fInumber\fB\fR ]  [ \fB-t \fItype\fB\fR ]  [ \fB-W \fIwait\fB\fR ]  [ \fB-4\fR ]  [ \fB-6\fR ]  \fBname\fR [ \fBserver\fR ] 
+.SH "SYNOPSIS"
+.HP 5
+\fBhost\fR [\fB\-aCdlnrTwv\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-N\ \fR\fB\fIndots\fR\fR] [\fB\-R\ \fR\fB\fInumber\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-W\ \fR\fB\fIwait\fR\fR] [\fB\-4\fR] [\fB\-6\fR] {name} [server]
 .SH "DESCRIPTION"
 .PP
 \fBhost\fR
-is a simple utility for performing DNS lookups.
-It is normally used to convert names to IP addresses and vice versa.
-When no arguments or options are given,
+is a simple utility for performing DNS lookups. It is normally used to convert names to IP addresses and vice versa. When no arguments or options are given,
 \fBhost\fR
 prints a short summary of its command line arguments and options.
 .PP
-\fIname\fR is the domain name that is to be looked
-up. It can also be a dotted-decimal IPv4 address or a colon-delimited
-IPv6 address, in which case \fBhost\fR will by default
-perform a reverse lookup for that address.
-\fIserver\fR is an optional argument which is either
-the name or IP address of the name server that \fBhost\fR
+\fIname\fR
+is the domain name that is to be looked up. It can also be a dotted\-decimal IPv4 address or a colon\-delimited IPv6 address, in which case
+\fBhost\fR
+will by default perform a reverse lookup for that address.
+\fIserver\fR
+is an optional argument which is either the name or IP address of the name server that
+\fBhost\fR
 should query instead of the server or servers listed in
 \fI/etc/resolv.conf\fR.
 .PP
-The \fB-a\fR (all) option is equivalent to setting the
-\fB-v\fR option and asking \fBhost\fR to make
-a query of type ANY.
+The
+\fB\-a\fR
+(all) option is equivalent to setting the
+\fB\-v\fR
+option and asking
+\fBhost\fR
+to make a query of type ANY.
 .PP
-When the \fB-C\fR option is used, \fBhost\fR
+When the
+\fB\-C\fR
+option is used,
+\fBhost\fR
 will attempt to display the SOA records for zone
-\fIname\fR from all the listed authoritative name
-servers for that zone. The list of name servers is defined by the NS
-records that are found for the zone.
-.PP
-The \fB-c\fR option instructs to make a DNS query of class
-\fIclass\fR. This can be used to lookup Hesiod or
-Chaosnet class resource records. The default class is IN (Internet).
-.PP
-Verbose output is generated by \fBhost\fR when the
-\fB-d\fR or \fB-v\fR option is used. The two
-options are equivalent. They have been provided for backwards
-compatibility. In previous versions, the \fB-d\fR option
-switched on debugging traces and \fB-v\fR enabled verbose
-output.
-.PP
-List mode is selected by the \fB-l\fR option. This makes
-\fBhost\fR perform a zone transfer for zone
-\fIname\fR. Transfer the zone printing out the NS, PTR
-and address records (A/AAAA). If combined with \fB-a\fR
-all records will be printed. 
-.PP
-The \fB-i\fR
-option specifies that reverse lookups of IPv6 addresses should
-use the IP6.INT domain as defined in RFC1886.
-The default is to use IP6.ARPA.
-.PP
-The \fB-N\fR option sets the number of dots that have to be
-in \fIname\fR for it to be considered absolute. The
-default value is that defined using the ndots statement in
-\fI/etc/resolv.conf\fR, or 1 if no ndots statement is
-present. Names with fewer dots are interpreted as relative names and
-will be searched for in the domains listed in the \fBsearch\fR
-or \fBdomain\fR directive in
+\fIname\fR
+from all the listed authoritative name servers for that zone. The list of name servers is defined by the NS records that are found for the zone.
+.PP
+The
+\fB\-c\fR
+option instructs to make a DNS query of class
+\fIclass\fR. This can be used to lookup Hesiod or Chaosnet class resource records. The default class is IN (Internet).
+.PP
+Verbose output is generated by
+\fBhost\fR
+when the
+\fB\-d\fR
+or
+\fB\-v\fR
+option is used. The two options are equivalent. They have been provided for backwards compatibility. In previous versions, the
+\fB\-d\fR
+option switched on debugging traces and
+\fB\-v\fR
+enabled verbose output.
+.PP
+List mode is selected by the
+\fB\-l\fR
+option. This makes
+\fBhost\fR
+perform a zone transfer for zone
+\fIname\fR. Transfer the zone printing out the NS, PTR and address records (A/AAAA). If combined with
+\fB\-a\fR
+all records will be printed.
+.PP
+The
+\fB\-i\fR
+option specifies that reverse lookups of IPv6 addresses should use the IP6.INT domain as defined in RFC1886. The default is to use IP6.ARPA.
+.PP
+The
+\fB\-N\fR
+option sets the number of dots that have to be in
+\fIname\fR
+for it to be considered absolute. The default value is that defined using the ndots statement in
+\fI/etc/resolv.conf\fR, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the
+\fBsearch\fR
+or
+\fBdomain\fR
+directive in
 \fI/etc/resolv.conf\fR.
 .PP
 The number of UDP retries for a lookup can be changed with the
-\fB-R\fR option. \fInumber\fR indicates
-how many times \fBhost\fR will repeat a query that does
-not get answered. The default number of retries is 1. If
-\fInumber\fR is negative or zero, the number of
-retries will default to 1.
-.PP
-Non-recursive queries can be made via the \fB-r\fR option.
-Setting this option clears the \fBRD\fR \(em recursion
-desired \(em bit in the query which \fBhost\fR makes.
-This should mean that the name server receiving the query will not
-attempt to resolve \fIname\fR. The
-\fB-r\fR option enables \fBhost\fR to mimic
-the behaviour of a name server by making non-recursive queries and
-expecting to receive answers to those queries that are usually
-referrals to other name servers.
-.PP
-By default \fBhost\fR uses UDP when making queries. The
-\fB-T\fR option makes it use a TCP connection when querying
-the name server. TCP will be automatically selected for queries that
-require it, such as zone transfer (AXFR) requests.
-.PP
-The \fB-4\fR option forces \fBhost\fR to only
-use IPv4 query transport. The \fB-6\fR option forces
-\fBhost\fR to only use IPv6 query transport.
-.PP
-The \fB-t\fR option is used to select the query type.
-\fItype\fR can be any recognised query type: CNAME,
-NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified,
-\fBhost\fR automatically selects an appropriate query
-type. By default it looks for A records, but if the
-\fB-C\fR option was given, queries will be made for SOA
-records, and if \fIname\fR is a dotted-decimal IPv4
-address or colon-delimited IPv6 address, \fBhost\fR will
-query for PTR records. If a query type of IXFR is chosen the starting
-serial number can be specified by appending an equal followed by the
-starting serial number (e.g. -t IXFR=12345678).
+\fB\-R\fR
+option.
+\fInumber\fR
+indicates how many times
+\fBhost\fR
+will repeat a query that does not get answered. The default number of retries is 1. If
+\fInumber\fR
+is negative or zero, the number of retries will default to 1.
+.PP
+Non\-recursive queries can be made via the
+\fB\-r\fR
+option. Setting this option clears the
+\fBRD\fR
+\(em recursion desired \(em bit in the query which
+\fBhost\fR
+makes. This should mean that the name server receiving the query will not attempt to resolve
+\fIname\fR. The
+\fB\-r\fR
+option enables
+\fBhost\fR
+to mimic the behaviour of a name server by making non\-recursive queries and expecting to receive answers to those queries that are usually referrals to other name servers.
+.PP
+By default
+\fBhost\fR
+uses UDP when making queries. The
+\fB\-T\fR
+option makes it use a TCP connection when querying the name server. TCP will be automatically selected for queries that require it, such as zone transfer (AXFR) requests.
+.PP
+The
+\fB\-4\fR
+option forces
+\fBhost\fR
+to only use IPv4 query transport. The
+\fB\-6\fR
+option forces
+\fBhost\fR
+to only use IPv6 query transport.
+.PP
+The
+\fB\-t\fR
+option is used to select the query type.
+\fItype\fR
+can be any recognised query type: CNAME, NS, SOA, SIG, KEY, AXFR, etc. When no query type is specified,
+\fBhost\fR
+automatically selects an appropriate query type. By default it looks for A records, but if the
+\fB\-C\fR
+option was given, queries will be made for SOA records, and if
+\fIname\fR
+is a dotted\-decimal IPv4 address or colon\-delimited IPv6 address,
+\fBhost\fR
+will query for PTR records. If a query type of IXFR is chosen the starting serial number can be specified by appending an equal followed by the starting serial number (e.g. \-t IXFR=12345678).
 .PP
 The time to wait for a reply can be controlled through the
-\fB-W\fR and \fB-w\fR options. The
-\fB-W\fR option makes \fBhost\fR wait for
-\fIwait\fR seconds. If \fIwait\fR
+\fB\-W\fR
+and
+\fB\-w\fR
+options. The
+\fB\-W\fR
+option makes
+\fBhost\fR
+wait for
+\fIwait\fR
+seconds. If
+\fIwait\fR
 is less than one, the wait interval is set to one second. When the
-\fB-w\fR option is used, \fBhost\fR will
-effectively wait forever for a reply. The time to wait for a response
-will be set to the number of seconds given by the hardware's maximum
-value for an integer quantity.
+\fB\-w\fR
+option is used,
+\fBhost\fR
+will effectively wait forever for a reply. The time to wait for a response will be set to the number of seconds given by the hardware's maximum value for an integer quantity.
 .SH "FILES"
 .PP
 \fI/etc/resolv.conf\fR
diff --git a/contrib/bind9/bin/dig/host.c b/contrib/bind9/bin/dig/host.c
index b8f2d9379339..468d53bf944e 100644
--- a/contrib/bind9/bin/dig/host.c
+++ b/contrib/bind9/bin/dig/host.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: host.c,v 1.76.2.5.2.10 2004/09/06 01:33:05 marka Exp $ */
+/* $Id: host.c,v 1.76.2.5.2.13 2005/07/04 03:29:45 marka Exp $ */
 
 #include <config.h>
 #include <limits.h>
@@ -40,21 +40,6 @@
 
 #include <dig/dig.h>
 
-extern ISC_LIST(dig_lookup_t) lookup_list;
-extern dig_serverlist_t server_list;
-extern ISC_LIST(dig_searchlist_t) search_list;
-
-extern isc_boolean_t have_ipv4, have_ipv6;
-extern isc_boolean_t usesearch;
-extern isc_boolean_t debugging;
-extern unsigned int timeout;
-extern isc_mem_t *mctx;
-extern int ndots;
-extern int tries;
-extern char *progname;
-extern isc_task_t *global_task;
-extern int fatalexit;
-
 static isc_boolean_t short_form = ISC_TRUE, listed_server = ISC_FALSE;
 static isc_boolean_t default_lookups = ISC_TRUE;
 static int seen_error = -1;
@@ -604,6 +589,7 @@ parse_args(isc_boolean_t is_batchfile, int argc, char **argv) {
 			} else
 				list_type = rdtype;
 			list_addresses = ISC_FALSE;
+			default_lookups = ISC_FALSE;
 			break;
 		case 'c':
 			tr.base = isc_commandline_argument;
diff --git a/contrib/bind9/bin/dig/host.docbook b/contrib/bind9/bin/dig/host.docbook
index 561f7c4397d2..2b6e92b76d46 100644
--- a/contrib/bind9/bin/dig/host.docbook
+++ b/contrib/bind9/bin/dig/host.docbook
@@ -1,6 +1,8 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2002  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: host.docbook,v 1.2.2.2.4.5 2004/04/13 01:26:26 marka Exp $ -->
+<!-- $Id: host.docbook,v 1.2.2.2.4.7 2005/05/13 01:22:32 marka Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,20 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>host</refname>
 <refpurpose>DNS lookup utility</refpurpose>
@@ -46,8 +62,8 @@
   <arg><option>-W <replaceable class="parameter">wait</replaceable></option></arg>
   <arg><option>-4</option></arg>
   <arg><option>-6</option></arg>
-  <arg choice=req>name</arg>
-  <arg choice=opt>server</arg>
+  <arg choice="req">name</arg>
+  <arg choice="opt">server</arg>
 </cmdsynopsis>
 </refsynopsisdiv>
 
diff --git a/contrib/bind9/bin/dig/host.html b/contrib/bind9/bin/dig/host.html
index fb011c033b9e..7670868ceed8 100644
--- a/contrib/bind9/bin/dig/host.html
+++ b/contrib/bind9/bin/dig/host.html
@@ -1,434 +1,171 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000-2002  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2002 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: host.html,v 1.4.2.1.4.6 2004/08/22 23:38:58 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->host</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->host</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->host&nbsp;--&nbsp;DNS lookup utility</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN11"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->host</B
->  [<VAR
-CLASS="OPTION"
->-aCdlnrTwv</VAR
->] [<VAR
-CLASS="OPTION"
->-c <VAR
-CLASS="REPLACEABLE"
->class</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-N <VAR
-CLASS="REPLACEABLE"
->ndots</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-R <VAR
-CLASS="REPLACEABLE"
->number</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->type</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-W <VAR
-CLASS="REPLACEABLE"
->wait</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-4</VAR
->] [<VAR
-CLASS="OPTION"
->-6</VAR
->] {name} [server]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN37"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><B
-CLASS="COMMAND"
->host</B
->
+<!-- $Id: host.html,v 1.4.2.1.4.12 2005/10/13 02:33:44 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>host</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>host &#8212; DNS lookup utility</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">host</code>  [<code class="option">-aCdlnrTwv</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-N <em class="replaceable"><code>ndots</code></em></code>] [<code class="option">-R <em class="replaceable"><code>number</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-W <em class="replaceable"><code>wait</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] {name} [server]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525901"></a><h2>DESCRIPTION</h2>
+<p>
+<span><strong class="command">host</strong></span>
 is a simple utility for performing DNS lookups.
 It is normally used to convert names to IP addresses and vice versa.
 When no arguments or options are given,
-<B
-CLASS="COMMAND"
->host</B
->
-prints a short summary of its command line arguments and options.</P
-><P
-><VAR
-CLASS="PARAMETER"
->name</VAR
-> is the domain name that is to be looked
+<span><strong class="command">host</strong></span>
+prints a short summary of its command line arguments and options.
+</p>
+<p>
+<em class="parameter"><code>name</code></em> is the domain name that is to be looked
 up.  It can also be a dotted-decimal IPv4 address or a colon-delimited
-IPv6 address, in which case <B
-CLASS="COMMAND"
->host</B
-> will by default
+IPv6 address, in which case <span><strong class="command">host</strong></span> will by default
 perform a reverse lookup for that address.
-<VAR
-CLASS="PARAMETER"
->server</VAR
-> is an optional argument which is either
-the name or IP address of the name server that <B
-CLASS="COMMAND"
->host</B
->
+<em class="parameter"><code>server</code></em> is an optional argument which is either
+the name or IP address of the name server that <span><strong class="command">host</strong></span>
 should query instead of the server or servers listed in
-<TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->.</P
-><P
->The <VAR
-CLASS="OPTION"
->-a</VAR
-> (all) option is equivalent to setting the
-<VAR
-CLASS="OPTION"
->-v</VAR
-> option and asking <B
-CLASS="COMMAND"
->host</B
-> to make
-a query of type ANY.</P
-><P
->When the <VAR
-CLASS="OPTION"
->-C</VAR
-> option is used, <B
-CLASS="COMMAND"
->host</B
->
+<code class="filename">/etc/resolv.conf</code>.
+</p>
+<p>
+The <code class="option">-a</code> (all) option is equivalent to setting the
+<code class="option">-v</code> option and asking <span><strong class="command">host</strong></span> to make
+a query of type ANY.
+</p>
+<p>
+When the <code class="option">-C</code> option is used, <span><strong class="command">host</strong></span>
 will attempt to display the SOA records for zone
-<VAR
-CLASS="PARAMETER"
->name</VAR
-> from all the listed authoritative name
+<em class="parameter"><code>name</code></em> from all the listed authoritative name
 servers for that zone.  The list of name servers is defined by the NS
-records that are found for the zone.</P
-><P
->The <VAR
-CLASS="OPTION"
->-c</VAR
-> option instructs to make a DNS query of class
-<VAR
-CLASS="PARAMETER"
->class</VAR
->.  This can be used to lookup Hesiod or
-Chaosnet class resource records.  The default class is IN (Internet).</P
-><P
->Verbose output is generated by <B
-CLASS="COMMAND"
->host</B
-> when the
-<VAR
-CLASS="OPTION"
->-d</VAR
-> or <VAR
-CLASS="OPTION"
->-v</VAR
-> option is used.  The two
+records that are found for the zone.
+</p>
+<p>
+The <code class="option">-c</code> option instructs to make a DNS query of class
+<em class="parameter"><code>class</code></em>.  This can be used to lookup Hesiod or
+Chaosnet class resource records.  The default class is IN (Internet).
+</p>
+<p>
+Verbose output is generated by <span><strong class="command">host</strong></span> when the
+<code class="option">-d</code> or <code class="option">-v</code> option is used.  The two
 options are equivalent.  They have been provided for backwards
-compatibility.  In previous versions, the <VAR
-CLASS="OPTION"
->-d</VAR
-> option
-switched on debugging traces and <VAR
-CLASS="OPTION"
->-v</VAR
-> enabled verbose
-output.</P
-><P
->List mode is selected by the <VAR
-CLASS="OPTION"
->-l</VAR
-> option.  This makes
-<B
-CLASS="COMMAND"
->host</B
-> perform a zone transfer for zone
-<VAR
-CLASS="PARAMETER"
->name</VAR
->.  Transfer the zone printing out the NS, PTR
-and address records (A/AAAA).  If combined with <VAR
-CLASS="OPTION"
->-a</VAR
->
-all records will be printed.  </P
-><P
->The <VAR
-CLASS="OPTION"
->-i</VAR
->
+compatibility.  In previous versions, the <code class="option">-d</code> option
+switched on debugging traces and <code class="option">-v</code> enabled verbose
+output.
+</p>
+<p>
+List mode is selected by the <code class="option">-l</code> option.  This makes
+<span><strong class="command">host</strong></span> perform a zone transfer for zone
+<em class="parameter"><code>name</code></em>.  Transfer the zone printing out the NS, PTR
+and address records (A/AAAA).  If combined with <code class="option">-a</code>
+all records will be printed.  
+</p>
+<p>
+The <code class="option">-i</code>
 option specifies that reverse lookups of IPv6 addresses should
 use the IP6.INT domain as defined in RFC1886.
-The default is to use IP6.ARPA.</P
-><P
->The <VAR
-CLASS="OPTION"
->-N</VAR
-> option sets the number of dots that have to be
-in <VAR
-CLASS="PARAMETER"
->name</VAR
-> for it to be considered absolute.  The
+The default is to use IP6.ARPA.
+</p>
+<p>
+The <code class="option">-N</code> option sets the number of dots that have to be
+in <em class="parameter"><code>name</code></em> for it to be considered absolute.  The
 default value is that defined using the ndots statement in
-<TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->, or 1 if no ndots statement is
+<code class="filename">/etc/resolv.conf</code>, or 1 if no ndots statement is
 present.  Names with fewer dots are interpreted as relative names and
-will be searched for in the domains listed in the <SPAN
-CLASS="TYPE"
->search</SPAN
->
-or <SPAN
-CLASS="TYPE"
->domain</SPAN
-> directive in
-<TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->.</P
-><P
->The number of UDP retries for a lookup can be changed with the
-<VAR
-CLASS="OPTION"
->-R</VAR
-> option.  <VAR
-CLASS="PARAMETER"
->number</VAR
-> indicates
-how many times <B
-CLASS="COMMAND"
->host</B
-> will repeat a query that does
+will be searched for in the domains listed in the <span class="type">search</span>
+or <span class="type">domain</span> directive in
+<code class="filename">/etc/resolv.conf</code>.
+</p>
+<p>
+The number of UDP retries for a lookup can be changed with the
+<code class="option">-R</code> option.  <em class="parameter"><code>number</code></em> indicates
+how many times <span><strong class="command">host</strong></span> will repeat a query that does
 not get answered.  The default number of retries is 1.  If
-<VAR
-CLASS="PARAMETER"
->number</VAR
-> is negative or zero, the number of
-retries will default to 1.</P
-><P
->Non-recursive queries can be made via the <VAR
-CLASS="OPTION"
->-r</VAR
-> option.
-Setting this option clears the <SPAN
-CLASS="TYPE"
->RD</SPAN
-> &mdash; recursion
-desired &mdash; bit in the query which <B
-CLASS="COMMAND"
->host</B
-> makes.
+<em class="parameter"><code>number</code></em> is negative or zero, the number of
+retries will default to 1.
+</p>
+<p>
+Non-recursive queries can be made via the <code class="option">-r</code> option.
+Setting this option clears the <span class="type">RD</span> &#8212; recursion
+desired &#8212; bit in the query which <span><strong class="command">host</strong></span> makes.
 This should mean that the name server receiving the query will not
-attempt to resolve <VAR
-CLASS="PARAMETER"
->name</VAR
->.  The
-<VAR
-CLASS="OPTION"
->-r</VAR
-> option enables <B
-CLASS="COMMAND"
->host</B
-> to mimic
+attempt to resolve <em class="parameter"><code>name</code></em>.  The
+<code class="option">-r</code> option enables <span><strong class="command">host</strong></span> to mimic
 the behaviour of a name server by making non-recursive queries and
 expecting to receive answers to those queries that are usually
-referrals to other name servers.</P
-><P
->By default <B
-CLASS="COMMAND"
->host</B
-> uses UDP when making queries.  The
-<VAR
-CLASS="OPTION"
->-T</VAR
-> option makes it use a TCP connection when querying
+referrals to other name servers.
+</p>
+<p>
+By default <span><strong class="command">host</strong></span> uses UDP when making queries.  The
+<code class="option">-T</code> option makes it use a TCP connection when querying
 the name server.  TCP will be automatically selected for queries that
-require it, such as zone transfer (AXFR) requests.</P
-><P
->The <VAR
-CLASS="OPTION"
->-4</VAR
-> option forces <B
-CLASS="COMMAND"
->host</B
-> to only
-use IPv4 query transport.  The <VAR
-CLASS="OPTION"
->-6</VAR
-> option forces
-<B
-CLASS="COMMAND"
->host</B
-> to only use IPv6 query transport.</P
-><P
->The <VAR
-CLASS="OPTION"
->-t</VAR
-> option is used to select the query type.
-<VAR
-CLASS="PARAMETER"
->type</VAR
-> can be any recognised query type: CNAME,
+require it, such as zone transfer (AXFR) requests.
+</p>
+<p>
+The <code class="option">-4</code> option forces <span><strong class="command">host</strong></span> to only
+use IPv4 query transport.  The <code class="option">-6</code> option forces
+<span><strong class="command">host</strong></span> to only use IPv6 query transport.
+</p>
+<p>
+The <code class="option">-t</code> option is used to select the query type.
+<em class="parameter"><code>type</code></em> can be any recognised query type: CNAME,
 NS, SOA, SIG, KEY, AXFR, etc.  When no query type is specified,
-<B
-CLASS="COMMAND"
->host</B
-> automatically selects an appropriate query
+<span><strong class="command">host</strong></span> automatically selects an appropriate query
 type.  By default it looks for A records, but if the
-<VAR
-CLASS="OPTION"
->-C</VAR
-> option was given, queries will be made for SOA
-records, and if <VAR
-CLASS="PARAMETER"
->name</VAR
-> is a dotted-decimal IPv4
-address or colon-delimited IPv6 address, <B
-CLASS="COMMAND"
->host</B
-> will
+<code class="option">-C</code> option was given, queries will be made for SOA
+records, and if <em class="parameter"><code>name</code></em> is a dotted-decimal IPv4
+address or colon-delimited IPv6 address, <span><strong class="command">host</strong></span> will
 query for PTR records.  If a query type of IXFR is chosen the starting
 serial number can be specified by appending an equal followed by the
-starting serial number (e.g. -t IXFR=12345678).</P
-><P
->The time to wait for a reply can be controlled through the
-<VAR
-CLASS="OPTION"
->-W</VAR
-> and <VAR
-CLASS="OPTION"
->-w</VAR
-> options.  The
-<VAR
-CLASS="OPTION"
->-W</VAR
-> option makes <B
-CLASS="COMMAND"
->host</B
-> wait for
-<VAR
-CLASS="PARAMETER"
->wait</VAR
-> seconds.  If <VAR
-CLASS="PARAMETER"
->wait</VAR
->
+starting serial number (e.g. -t IXFR=12345678).
+</p>
+<p>
+The time to wait for a reply can be controlled through the
+<code class="option">-W</code> and <code class="option">-w</code> options.  The
+<code class="option">-W</code> option makes <span><strong class="command">host</strong></span> wait for
+<em class="parameter"><code>wait</code></em> seconds.  If <em class="parameter"><code>wait</code></em>
 is less than one, the wait interval is set to one second.  When the
-<VAR
-CLASS="OPTION"
->-w</VAR
-> option is used, <B
-CLASS="COMMAND"
->host</B
-> will
+<code class="option">-w</code> option is used, <span><strong class="command">host</strong></span> will
 effectively wait forever for a reply.  The time to wait for a response
 will be set to the number of seconds given by the hardware's maximum
-value for an integer quantity.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN115"
-></A
-><H2
->FILES</H2
-><P
-><TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN119"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dig</SPAN
->(1)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+value for an integer quantity.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526241"></a><h2>FILES</h2>
+<p>
+<code class="filename">/etc/resolv.conf</code>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526253"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
+<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/dig/include/dig/dig.h b/contrib/bind9/bin/dig/include/dig/dig.h
index 4e88b15336ee..431d109cf081 100644
--- a/contrib/bind9/bin/dig/include/dig/dig.h
+++ b/contrib/bind9/bin/dig/include/dig/dig.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dig.h,v 1.71.2.6.2.7 2004/09/06 01:33:06 marka Exp $ */
+/* $Id: dig.h,v 1.71.2.6.2.11 2005/07/04 03:29:45 marka Exp $ */
 
 #ifndef DIG_H
 #define DIG_H
@@ -35,7 +35,7 @@
 #include <isc/sockaddr.h>
 #include <isc/socket.h>
 
-#define MXSERV 6
+#define MXSERV 20
 #define MXNAME (DNS_NAME_MAXTEXT+1)
 #define MXRD 32
 #define BUFSIZE 512
@@ -66,14 +66,6 @@
  * in a tight loop of constant lookups.  It's value is arbitrary.
  */
 
-#define ROOTNS 1
-/*
- * Set the number of root servers to ask for information when running in
- * trace mode.
- * XXXMWS -- trace mode is currently semi-broken, and this number *MUST*
- * be 1.
- */
-
 /*
  * Defaults for the sigchase suboptions.  Consolidated here because
  * these control the layout of dig_lookup_t (among other things).
@@ -224,6 +216,46 @@ struct dig_message {
 		ISC_LINK(dig_message_t) link;
 };
 #endif
+
+typedef ISC_LIST(dig_searchlist_t) dig_searchlistlist_t;
+typedef ISC_LIST(dig_lookup_t) dig_lookuplist_t;
+
+/*
+ * Externals from dighost.c
+ */
+
+extern dig_lookuplist_t lookup_list;
+extern dig_serverlist_t server_list;
+extern dig_searchlistlist_t search_list;
+
+extern isc_boolean_t have_ipv4, have_ipv6, specified_source,
+        usesearch, qr;
+extern in_port_t port;
+extern unsigned int timeout;
+extern isc_mem_t *mctx;
+extern dns_messageid_t id;
+extern int sendcount;
+extern int ndots;
+extern int lookup_counter;
+extern int exitcode;
+extern isc_sockaddr_t bind_address;
+extern char keynametext[MXNAME];
+extern char keyfile[MXNAME];
+extern char keysecret[MXNAME];
+#ifdef DIG_SIGCHASE
+extern char trustedkey[MXNAME];
+#endif
+extern dns_tsigkey_t *key;
+extern isc_boolean_t validated;
+extern isc_taskmgr_t *taskmgr;
+extern isc_task_t *global_task;
+extern isc_boolean_t free_now;
+extern isc_boolean_t debugging, memdebugging;
+
+extern char *progname;
+extern int tries;
+extern int fatalexit;
+
 /*
  * Routines in dighost.c.
  */
diff --git a/contrib/bind9/bin/dig/nslookup.1 b/contrib/bind9/bin/dig/nslookup.1
index 71aa8a131e4a..3de04ca4f912 100644
--- a/contrib/bind9/bin/dig/nslookup.1
+++ b/contrib/bind9/bin/dig/nslookup.1
@@ -1,76 +1,72 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: nslookup.1,v 1.1.6.2 2004/08/20 02:29:39 marka Exp $
+.\" $Id: nslookup.1,v 1.1.6.5 2005/10/13 02:33:43 marka Exp $
 .\"
-.TH "NSLOOKUP" "1" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "NSLOOKUP" "1" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 nslookup \- query Internet name servers interactively
-.SH SYNOPSIS
-.sp
-\fBnslookup\fR [ \fB-option\fR ]  [ \fBname | -\fR ]  [ \fBserver\fR ] 
+.SH "SYNOPSIS"
+.HP 9
+\fBnslookup\fR [\fB\-option\fR] [name\ |\ \-] [server]
 .SH "DESCRIPTION"
 .PP
 \fBNslookup\fR
-is a program to query Internet domain name servers. \fBNslookup\fR
-has two modes: interactive and non-interactive. Interactive mode allows
-the user to query name servers for information about various hosts and
-domains or to print a list of hosts in a domain. Non-interactive mode is
-used to print just the name and requested information for a host or
-domain.
+is a program to query Internet domain name servers.
+\fBNslookup\fR
+has two modes: interactive and non\-interactive. Interactive mode allows the user to query name servers for information about various hosts and domains or to print a list of hosts in a domain. Non\-interactive mode is used to print just the name and requested information for a host or domain.
 .SH "ARGUMENTS"
 .PP
 Interactive mode is entered in the following cases:
-.IP 1. 
+.TP 3
+1.
 when no arguments are given (the default name server will be used)
-.IP 2. 
-when the first argument is a hyphen (-) and the second argument is
-the host name or Internet address of a name server.
-.PP
-Non-interactive mode is used when the name or Internet address of the
-host to be looked up is given as the first argument. The optional second
-argument specifies the host name or address of a name server.
+.TP
+2.
+when the first argument is a hyphen (\-) and the second argument is the host name or Internet address of a name server.
 .PP
-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 timeout to 10 seconds, type:
+Non\-interactive mode is used when the name or Internet address of the host to be looked up is given as the first argument. The optional second argument specifies the host name or address of a name server.
 .PP
-.sp
-.nf
-nslookup -query=hinfo  -timeout=10
-.sp
-.fi
+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 timeout to 10 seconds, type:
+.IP .sp .nf nslookup \-query=hinfo \-timeout=10 .fi
 .SH "INTERACTIVE COMMANDS"
 .TP
-\fBhost [server]\fR
-Look up information for host using the current default server or
-using server, if specified. If host is an Internet address and
-the query type is A or PTR, the name of the host is returned.
-If host is a name and does not have a trailing period, the
-search list is used to qualify the name.
-
-To look up a host not in the current domain, append a period to
-the name.
-.TP
-\fBserver \fIdomain\fB\fR
-.TP
-\fBlserver \fIdomain\fB\fR
-Change the default server to \fIdomain\fR; lserver uses the initial
-server to look up information about \fIdomain\fR, while server uses
-the current default server. If an authoritative answer can't be
-found, the names of servers that might have the answer are
-returned.
+host [server]
+Look up information for host using the current default server or using server, if specified. If host is an Internet address and the query type is A or PTR, the name of the host is returned. If host is a name and does not have a trailing period, the search list is used to qualify the name.
+.sp
+To look up a host not in the current domain, append a period to the name.
+.TP
+\fBserver\fR \fIdomain\fR
+.TP
+\fBlserver\fR \fIdomain\fR
+Change the default server to
+\fIdomain\fR;
+\fBlserver\fR
+uses the initial server to look up information about
+\fIdomain\fR, while
+\fBserver\fR
+uses the current default server. If an authoritative answer can't be found, the names of servers that might have the answer are returned.
 .TP
 \fBroot\fR
 not implemented
@@ -93,17 +89,15 @@ not implemented
 \fBexit\fR
 Exits the program.
 .TP
-\fBset \fIkeyword[=value]\fB\fR
-This command is used to change state information that affects
-the lookups. Valid keywords are:
+\fBset\fR \fIkeyword\fR\fI[=value]\fR
+This command is used to change state information that affects the lookups. Valid keywords are:
 .RS
 .TP
 \fBall\fR
-Prints the current values of the frequently used
-options to \fBset\fR. Information about the current default
-server and host is also printed.
+Prints the current values of the frequently used options to
+\fBset\fR. Information about the current default server and host is also printed.
 .TP
-\fBclass=\fIvalue\fB\fR
+\fBclass=\fR\fIvalue\fR
 Change the query class to one of:
 .RS
 .TP
@@ -119,66 +113,61 @@ the Hesiod class
 \fBANY\fR
 wildcard
 .RE
-.PP
+.IP
 The class specifies the protocol group of the information.
-
+.sp
 (Default = IN; abbreviation = cl)
 .TP
-\fB\fI[no]\fBdebug\fR
-Turn debugging mode on. A lot more information is
-printed about the packet sent to the server and the
-resulting answer.
-
-(Default = nodebug; abbreviation = [no]deb)
-.TP
-\fB\fI[no]\fBd2\fR
-Turn debugging mode on. A lot more information is
-printed about the packet sent to the server and the
-resulting answer.
-
+\fB\fI[no]\fR\fR\fBdebug\fR
+Turn debugging mode on. A lot more information is printed about the packet sent to the server and the resulting answer.
+.sp
+(Default = nodebug; abbreviation =
+[no]deb)
+.TP
+\fB\fI[no]\fR\fR\fBd2\fR
+Turn debugging mode on. A lot more information is printed about the packet sent to the server and the resulting answer.
+.sp
 (Default = nod2)
 .TP
-\fBdomain=\fIname\fB\fR
-Sets the search list to \fIname\fR.
+\fBdomain=\fR\fIname\fR
+Sets the search list to
+\fIname\fR.
 .TP
-\fB\fI[no]\fBsearch\fR
-If the lookup request contains at least one period but
-doesn't end with a trailing period, append the domain
-names in the domain search list to the request until an
-answer is received.
-
+\fB\fI[no]\fR\fR\fBsearch\fR
+If the lookup request contains at least one period but doesn't end with a trailing period, append the domain names in the domain search list to the request until an answer is received.
+.sp
 (Default = search)
 .TP
-\fBport=\fIvalue\fB\fR
-Change the default TCP/UDP name server port to \fIvalue\fR.
-
+\fBport=\fR\fIvalue\fR
+Change the default TCP/UDP name server port to
+\fIvalue\fR.
+.sp
 (Default = 53; abbreviation = po)
 .TP
-\fBquerytype=\fIvalue\fB\fR
+\fBquerytype=\fR\fIvalue\fR
 .TP
-\fBtype=\fIvalue\fB\fR
+\fBtype=\fR\fIvalue\fR
 Change the top of the information query.
-
+.sp
 (Default = A; abbreviations = q, ty)
 .TP
-\fB\fI[no]\fBrecurse\fR
-Tell the name server to query other servers if it does not have the
-information.
-
+\fB\fI[no]\fR\fR\fBrecurse\fR
+Tell the name server to query other servers if it does not have the information.
+.sp
 (Default = recurse; abbreviation = [no]rec)
 .TP
-\fBretry=\fInumber\fB\fR
+\fBretry=\fR\fInumber\fR
 Set the number of retries to number.
 .TP
-\fBtimeout=\fInumber\fB\fR
-Change the initial timeout interval for waiting for a
-reply to number seconds.
+\fBtimeout=\fR\fInumber\fR
+Change the initial timeout interval for waiting for a reply to number seconds.
 .TP
-\fB\fI[no]\fBvc\fR
+\fB\fI[no]\fR\fR\fBvc\fR
 Always use a virtual circuit when sending requests to the server.
-
+.sp
 (Default = novc)
 .RE
+.IP
 .SH "FILES"
 .PP
 \fI/etc/resolv.conf\fR
diff --git a/contrib/bind9/bin/dig/nslookup.c b/contrib/bind9/bin/dig/nslookup.c
index b26c605142e6..ab9ed68764c8 100644
--- a/contrib/bind9/bin/dig/nslookup.c
+++ b/contrib/bind9/bin/dig/nslookup.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nslookup.c,v 1.90.2.4.2.8 2004/09/06 01:33:05 marka Exp $ */
+/* $Id: nslookup.c,v 1.90.2.4.2.10 2005/07/12 05:47:42 marka Exp $ */
 
 #include <config.h>
 
@@ -44,19 +44,6 @@
 
 #include <dig/dig.h>
 
-extern ISC_LIST(dig_lookup_t) lookup_list;
-extern dig_serverlist_t server_list;
-extern ISC_LIST(dig_searchlist_t) search_list;
-
-extern isc_boolean_t usesearch, debugging;
-extern in_port_t port;
-extern unsigned int timeout;
-extern isc_mem_t *mctx;
-extern int tries;
-extern int lookup_counter;
-extern isc_task_t *global_task;
-extern char *progname;
-
 static isc_boolean_t short_form = ISC_TRUE,
 	tcpmode = ISC_FALSE,
 	identify = ISC_FALSE, stats = ISC_TRUE,
diff --git a/contrib/bind9/bin/dig/nslookup.docbook b/contrib/bind9/bin/dig/nslookup.docbook
index 134e5b32ec41..189fabe85073 100644
--- a/contrib/bind9/bin/dig/nslookup.docbook
+++ b/contrib/bind9/bin/dig/nslookup.docbook
@@ -1,6 +1,8 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -15,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: nslookup.docbook,v 1.3.6.3 2004/08/30 00:50:11 marka Exp $ -->
+<!-- $Id: nslookup.docbook,v 1.3.6.5 2005/05/13 01:22:33 marka Exp $ -->
 
 <!--
  - Copyright (c) 1985, 1989
@@ -62,6 +64,14 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>nslookup</refname>
 <refpurpose>query Internet name servers interactively</refpurpose>
@@ -71,8 +81,8 @@
 <cmdsynopsis>
   <command>nslookup</command>
   <arg><option>-option</option></arg>
-  <arg choice=opt>name | -</arg>
-  <arg choice=opt>server</arg>
+  <arg choice="opt">name | -</arg>
+  <arg choice="opt">server</arg>
 </cmdsynopsis>
 </refsynopsisdiv>
 
@@ -93,19 +103,19 @@ domain.
 <title>ARGUMENTS</title>
 <para>
 Interactive mode is entered in the following cases:
-<OrderedList Numeration=Loweralpha>
-<Listitem>
+<orderedlist numeration="loweralpha">
+<listitem>
 <para>
 when no arguments are given (the default name server will be used)
 </para>
-</Listitem>
-<Listitem>
+</listitem>
+<listitem>
 <para>
 when the first argument is a hyphen (-) and the second argument is
 the host name or Internet address of a name server.
 </para>
-</Listitem>
-</OrderedList>
+</listitem>
+</orderedlist>
 </para>
 
 <para>
@@ -118,11 +128,11 @@ argument specifies the host name or address of a name server.
 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 timeout to 10 seconds, type:
-<InformalExample>
-<PROGRAMLISTING>
+<informalexample>
+<programlisting>
 nslookup -query=hinfo  -timeout=10
-</PROGRAMLISTING>
-</InformalExample>
+</programlisting>
+</informalexample>
 </para>
 
 </refsect1>
diff --git a/contrib/bind9/bin/dig/nslookup.html b/contrib/bind9/bin/dig/nslookup.html
index e353377e8f03..fc2e4e80d723 100644
--- a/contrib/bind9/bin/dig/nslookup.html
+++ b/contrib/bind9/bin/dig/nslookup.html
@@ -1,617 +1,264 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: nslookup.html,v 1.1.6.3 2004/08/22 23:38:58 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->nslookup</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->nslookup</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->nslookup&nbsp;--&nbsp;query Internet name servers interactively</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN11"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->nslookup</B
->  [<VAR
-CLASS="OPTION"
->-option</VAR
->] [name | -] [server]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN18"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><B
-CLASS="COMMAND"
->Nslookup</B
->
-is a program to query Internet domain name servers.  <B
-CLASS="COMMAND"
->Nslookup</B
->
+<!-- $Id: nslookup.html,v 1.1.6.9 2005/10/13 02:33:44 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>nslookup</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463728"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>nslookup &#8212; query Internet name servers interactively</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">nslookup</code>  [<code class="option">-option</code>] [name | -] [server]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525973"></a><h2>DESCRIPTION</h2>
+<p>
+<span><strong class="command">Nslookup</strong></span>
+is a program to query Internet domain name servers.  <span><strong class="command">Nslookup</strong></span>
 has two modes: interactive and non-interactive.  Interactive mode allows
 the user to query name servers for information about various hosts and
 domains or to print a list of hosts in a domain.  Non-interactive mode is
 used to print just the name and requested information for a host or
-domain.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN23"
-></A
-><H2
->ARGUMENTS</H2
-><P
->Interactive mode is entered in the following cases:
-<P
-></P
-><OL
-TYPE="a"
-><LI
-><P
->when no arguments are given (the default name server will be used)</P
-></LI
-><LI
-><P
->when the first argument is a hyphen (-) and the second argument is
-the host name or Internet address of a name server.</P
-></LI
-></OL
-></P
-><P
->Non-interactive mode is used when the name or Internet address of the
+domain.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525990"></a><h2>ARGUMENTS</h2>
+<p>
+Interactive mode is entered in the following cases:
+</p>
+<div class="orderedlist"><ol type="a">
+<li><p>
+when no arguments are given (the default name server will be used)
+</p></li>
+<li><p>
+when the first argument is a hyphen (-) and the second argument is
+the host name or Internet address of a name server.
+</p></li>
+</ol></div>
+<p>
+</p>
+<p>
+Non-interactive mode is used when the name or Internet address of the
 host to be looked up is given as the first argument. The optional second
-argument specifies the host name or address of a name server.</P
-><P
->Options can also be specified on the command line if they precede the
+argument specifies the host name or address of a name server.
+</p>
+<p>
+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 timeout to 10 seconds, type:
-<DIV
-CLASS="INFORMALEXAMPLE"
-><P
-></P
-><A
-NAME="AEN33"
-></A
-><PRE
-CLASS="PROGRAMLISTING"
->nslookup -query=hinfo  -timeout=10</PRE
-><P
-></P
-></DIV
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN35"
-></A
-><H2
->INTERACTIVE COMMANDS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->host [<SPAN
-CLASS="OPTIONAL"
->server</SPAN
->]</DT
-><DD
-><P
->Look up information for host using the current default server or
+</p>
+<div class="informalexample"><pre class="programlisting">
+nslookup -query=hinfo  -timeout=10
+</pre></div>
+<p>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526033"></a><h2>INTERACTIVE COMMANDS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">host [<span class="optional">server</span>]</span></dt>
+<dd>
+<p>
+Look up information for host using the current default server or
 using server, if specified.  If host is an Internet address and
 the query type is A or PTR, the name of the host is returned.
 If host is a name and does not have a trailing period, the
-search list is used to qualify the name.</P
-><P
->To look up a host not in the current domain, append a period to
-the name.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->server</CODE
-> <VAR
-CLASS="REPLACEABLE"
->domain</VAR
-></DT
-><DD
-><P
-></P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->lserver</CODE
-> <VAR
-CLASS="REPLACEABLE"
->domain</VAR
-></DT
-><DD
-><P
->Change the default server to <VAR
-CLASS="REPLACEABLE"
->domain</VAR
->; <CODE
-CLASS="CONSTANT"
->lserver</CODE
-> uses the initial
-server to look up information about <VAR
-CLASS="REPLACEABLE"
->domain</VAR
->, while <CODE
-CLASS="CONSTANT"
->server</CODE
-> uses
+search list is used to qualify the name.
+</p>
+<p>
+To look up a host not in the current domain, append a period to
+the name.
+</p>
+</dd>
+<dt><span class="term"><code class="constant">server</code> <em class="replaceable"><code>domain</code></em></span></dt>
+<dd><p></p></dd>
+<dt><span class="term"><code class="constant">lserver</code> <em class="replaceable"><code>domain</code></em></span></dt>
+<dd><p>
+Change the default server to <em class="replaceable"><code>domain</code></em>; <code class="constant">lserver</code> uses the initial
+server to look up information about <em class="replaceable"><code>domain</code></em>, while <code class="constant">server</code> uses
 the current default server.  If an authoritative answer can't be
 found, the names of servers that might have the answer are
-returned.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->root</CODE
-></DT
-><DD
-><P
->not implemented</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->finger</CODE
-></DT
-><DD
-><P
->not implemented</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ls</CODE
-></DT
-><DD
-><P
->not implemented</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->view</CODE
-></DT
-><DD
-><P
->not implemented</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->help</CODE
-></DT
-><DD
-><P
->not implemented</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->?</CODE
-></DT
-><DD
-><P
->not implemented</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->exit</CODE
-></DT
-><DD
-><P
->Exits the program.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->set</CODE
-> <VAR
-CLASS="REPLACEABLE"
->keyword[<SPAN
-CLASS="OPTIONAL"
->=value</SPAN
->]</VAR
-></DT
-><DD
-><P
->This command is used to change state information that affects
+returned.
+</p></dd>
+<dt><span class="term"><code class="constant">root</code></span></dt>
+<dd><p>not implemented</p></dd>
+<dt><span class="term"><code class="constant">finger</code></span></dt>
+<dd><p>not implemented</p></dd>
+<dt><span class="term"><code class="constant">ls</code></span></dt>
+<dd><p>not implemented</p></dd>
+<dt><span class="term"><code class="constant">view</code></span></dt>
+<dd><p>not implemented</p></dd>
+<dt><span class="term"><code class="constant">help</code></span></dt>
+<dd><p>not implemented</p></dd>
+<dt><span class="term"><code class="constant">?</code></span></dt>
+<dd><p>not implemented</p></dd>
+<dt><span class="term"><code class="constant">exit</code></span></dt>
+<dd><p>Exits the program.</p></dd>
+<dt><span class="term"><code class="constant">set</code> <em class="replaceable"><code>keyword[<span class="optional">=value</span>]</code></em></span></dt>
+<dd>
+<p>This command is used to change state information that affects
 the lookups.  Valid keywords are:
- <P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->all</CODE
-></DT
-><DD
-><P
->Prints the current values of the frequently used
-  options to <B
-CLASS="COMMAND"
->set</B
->.  Information about the  current default
+ </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">all</code></span></dt>
+<dd><p>Prints the current values of the frequently used
+  options to <span><strong class="command">set</strong></span>.  Information about the  current default
   server and host is also printed.
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->class=</CODE
-><VAR
-CLASS="REPLACEABLE"
->value</VAR
-></DT
-><DD
-><P
->   Change the query class to one of:
-   <P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->IN</CODE
-></DT
-><DD
-><P
->the Internet class</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->CH</CODE
-></DT
-><DD
-><P
->the Chaos class</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->HS</CODE
-></DT
-><DD
-><P
->the Hesiod class</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ANY</CODE
-></DT
-><DD
-><P
->wildcard</P
-></DD
-></DL
-></DIV
->
+  </p></dd>
+<dt><span class="term"><code class="constant">class=</code><em class="replaceable"><code>value</code></em></span></dt>
+<dd>
+<p>
+   Change the query class to one of:
+   </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">IN</code></span></dt>
+<dd><p>the Internet class</p></dd>
+<dt><span class="term"><code class="constant">CH</code></span></dt>
+<dd><p>the Chaos class</p></dd>
+<dt><span class="term"><code class="constant">HS</code></span></dt>
+<dd><p>the Hesiod class</p></dd>
+<dt><span class="term"><code class="constant">ANY</code></span></dt>
+<dd><p>wildcard</p></dd>
+</dl></div>
+<p>
    The class specifies the protocol group of the information.
-   </P
-><P
->   (Default = IN; abbreviation = cl)
-   </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
-><VAR
-CLASS="REPLACEABLE"
->[<SPAN
-CLASS="OPTIONAL"
->no</SPAN
->]</VAR
->debug</CODE
-></DT
-><DD
-><P
->  Turn debugging mode on.  A lot more information is
+   </p>
+<p>
+   (Default = IN; abbreviation = cl)
+   </p>
+</dd>
+<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>debug</code></span></dt>
+<dd>
+<p>
+  Turn debugging mode on.  A lot more information is
   printed about the packet sent to the server and the
   resulting answer.
-  </P
-><P
->  (Default = nodebug; abbreviation = [<SPAN
-CLASS="OPTIONAL"
->no</SPAN
->]deb)
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
-><VAR
-CLASS="REPLACEABLE"
->[<SPAN
-CLASS="OPTIONAL"
->no</SPAN
->]</VAR
->d2</CODE
-></DT
-><DD
-><P
->  Turn debugging mode on.  A lot more information is
+  </p>
+<p>
+  (Default = nodebug; abbreviation = [<span class="optional">no</span>]deb)
+  </p>
+</dd>
+<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>d2</code></span></dt>
+<dd>
+<p>
+  Turn debugging mode on.  A lot more information is
   printed about the packet sent to the server and the
   resulting answer.
-  </P
-><P
->  (Default = nod2)
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->domain=</CODE
-><VAR
-CLASS="REPLACEABLE"
->name</VAR
-></DT
-><DD
-><P
->  Sets the search list to <VAR
-CLASS="REPLACEABLE"
->name</VAR
->.
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
-><VAR
-CLASS="REPLACEABLE"
->[<SPAN
-CLASS="OPTIONAL"
->no</SPAN
->]</VAR
->search</CODE
-></DT
-><DD
-><P
->  If the lookup request contains at least one period but
+  </p>
+<p>
+  (Default = nod2)
+  </p>
+</dd>
+<dt><span class="term"><code class="constant">domain=</code><em class="replaceable"><code>name</code></em></span></dt>
+<dd><p>
+  Sets the search list to <em class="replaceable"><code>name</code></em>.
+  </p></dd>
+<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>search</code></span></dt>
+<dd>
+<p>
+  If the lookup request contains at least one period but
   doesn't end with a trailing period, append the domain
   names in the domain search list to the request until an
   answer is received.
-  </P
-><P
->  (Default = search)
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->port=</CODE
-><VAR
-CLASS="REPLACEABLE"
->value</VAR
-></DT
-><DD
-><P
->  Change the default TCP/UDP name server port to <VAR
-CLASS="REPLACEABLE"
->value</VAR
->.
-  </P
-><P
->  (Default = 53; abbreviation = po)
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->querytype=</CODE
-><VAR
-CLASS="REPLACEABLE"
->value</VAR
-></DT
-><DD
-><P
-></P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->type=</CODE
-><VAR
-CLASS="REPLACEABLE"
->value</VAR
-></DT
-><DD
-><P
->  Change the top of the information query.
-  </P
-><P
->  (Default = A; abbreviations = q, ty)
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
-><VAR
-CLASS="REPLACEABLE"
->[<SPAN
-CLASS="OPTIONAL"
->no</SPAN
->]</VAR
->recurse</CODE
-></DT
-><DD
-><P
->  Tell the name server to query other servers if it does not have the
+  </p>
+<p>
+  (Default = search)
+  </p>
+</dd>
+<dt><span class="term"><code class="constant">port=</code><em class="replaceable"><code>value</code></em></span></dt>
+<dd>
+<p>
+  Change the default TCP/UDP name server port to <em class="replaceable"><code>value</code></em>.
+  </p>
+<p>
+  (Default = 53; abbreviation = po)
+  </p>
+</dd>
+<dt><span class="term"><code class="constant">querytype=</code><em class="replaceable"><code>value</code></em></span></dt>
+<dd><p></p></dd>
+<dt><span class="term"><code class="constant">type=</code><em class="replaceable"><code>value</code></em></span></dt>
+<dd>
+<p>
+  Change the top of the information query.
+  </p>
+<p>
+  (Default = A; abbreviations = q, ty)
+  </p>
+</dd>
+<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>recurse</code></span></dt>
+<dd>
+<p>
+  Tell the name server to query other servers if it does not have the
   information.
-  </P
-><P
->  (Default = recurse; abbreviation = [no]rec)
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->retry=</CODE
-><VAR
-CLASS="REPLACEABLE"
->number</VAR
-></DT
-><DD
-><P
->  Set the number of retries to number.
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->timeout=</CODE
-><VAR
-CLASS="REPLACEABLE"
->number</VAR
-></DT
-><DD
-><P
->  Change the initial timeout interval for waiting for a
+  </p>
+<p>
+  (Default = recurse; abbreviation = [no]rec)
+  </p>
+</dd>
+<dt><span class="term"><code class="constant">retry=</code><em class="replaceable"><code>number</code></em></span></dt>
+<dd><p>
+  Set the number of retries to number.
+  </p></dd>
+<dt><span class="term"><code class="constant">timeout=</code><em class="replaceable"><code>number</code></em></span></dt>
+<dd><p>
+  Change the initial timeout interval for waiting for a
   reply to number seconds.
-  </P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
-><VAR
-CLASS="REPLACEABLE"
->[<SPAN
-CLASS="OPTIONAL"
->no</SPAN
->]</VAR
->vc</CODE
-></DT
-><DD
-><P
->  Always use a virtual circuit when sending requests to the server.
-  </P
-><P
->  (Default = novc)
-  </P
-></DD
-></DL
-></DIV
-></P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN218"
-></A
-><H2
->FILES</H2
-><P
-><TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN222"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dig</SPAN
->(1)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->host</SPAN
->(1)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN234"
-></A
-><H2
->Author</H2
-><P
->Andrew Cherenson</P
-></DIV
-></BODY
-></HTML
->
+  </p></dd>
+<dt><span class="term"><code class="constant"><em class="replaceable"><code>[<span class="optional">no</span>]</code></em>vc</code></span></dt>
+<dd>
+<p>
+  Always use a virtual circuit when sending requests to the server.
+  </p>
+<p>
+  (Default = novc)
+  </p>
+</dd>
+</dl></div>
+<p>
+</p>
+</dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526490"></a><h2>FILES</h2>
+<p>
+<code class="filename">/etc/resolv.conf</code>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526503"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
+<span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>,
+<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526538"></a><h2>Author</h2>
+<p>
+Andrew Cherenson
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/dnssec/Makefile.in b/contrib/bind9/bin/dnssec/Makefile.in
index 993c54e4067f..b9b7bea37c26 100644
--- a/contrib/bind9/bin/dnssec/Makefile.in
+++ b/contrib/bind9/bin/dnssec/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000-2002  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.19.12.9 2004/07/20 07:01:48 marka Exp $
+# $Id: Makefile.in,v 1.19.12.12 2005/05/02 00:25:54 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -58,7 +58,8 @@ dnssec-keygen@EXEEXT@: dnssec-keygen.@O@ ${OBJS} ${DEPLIBS}
 	dnssec-keygen.@O@ ${OBJS} ${LIBS}
 
 dnssec-signzone.@O@: dnssec-signzone.c
-	${LIBTOOL_MODE_COMPILE} ${PURIFY} ${CC} ${ALL_CFLAGS} -c $<
+	${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} -DVERSION=\"${VERSION}\" \
+		-c ${srcdir}/dnssec-signzone.c
 
 dnssec-signzone@EXEEXT@: dnssec-signzone.@O@ ${OBJS} ${DEPLIBS}
 	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \
diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.8 b/contrib/bind9/bin/dnssec/dnssec-keygen.8
index 235c26ea32f9..0f8f003de426 100644
--- a/contrib/bind9/bin/dnssec/dnssec-keygen.8
+++ b/contrib/bind9/bin/dnssec/dnssec-keygen.8
@@ -1,174 +1,164 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000-2003  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000-2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: dnssec-keygen.8,v 1.19.12.5 2004/06/11 02:32:45 marka Exp $
+.\" $Id: dnssec-keygen.8,v 1.19.12.9 2005/10/13 02:33:45 marka Exp $
 .\"
-.TH "DNSSEC-KEYGEN" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
-dnssec-keygen \- DNSSEC key generation tool
-.SH SYNOPSIS
-.sp
-\fBdnssec-keygen\fR \fB-a \fIalgorithm\fB\fR \fB-b \fIkeysize\fB\fR \fB-n \fInametype\fB\fR [ \fB-c \fIclass\fB\fR ]  [ \fB-e\fR ]  [ \fB-f \fIflag\fB\fR ]  [ \fB-g \fIgenerator\fB\fR ]  [ \fB-h\fR ]  [ \fB-k\fR ]  [ \fB-p \fIprotocol\fB\fR ]  [ \fB-r \fIrandomdev\fB\fR ]  [ \fB-s \fIstrength\fB\fR ]  [ \fB-t \fItype\fB\fR ]  [ \fB-v \fIlevel\fB\fR ]  \fBname\fR
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "DNSSEC\-KEYGEN" "8" "June 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+dnssec\-keygen \- DNSSEC key generation tool
+.SH "SYNOPSIS"
+.HP 14
+\fBdnssec\-keygen\fR {\-a\ \fIalgorithm\fR} {\-b\ \fIkeysize\fR} {\-n\ \fInametype\fR} [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-e\fR] [\fB\-f\ \fR\fB\fIflag\fR\fR] [\fB\-g\ \fR\fB\fIgenerator\fR\fR] [\fB\-h\fR] [\fB\-k\fR] [\fB\-p\ \fR\fB\fIprotocol\fR\fR] [\fB\-r\ \fR\fB\fIrandomdev\fR\fR] [\fB\-s\ \fR\fB\fIstrength\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-v\ \fR\fB\fIlevel\fR\fR] {name}
 .SH "DESCRIPTION"
 .PP
-\fBdnssec-keygen\fR generates keys for DNSSEC
-(Secure DNS), as defined in RFC 2535 and RFC <TBA\\>. It can also generate
-keys for use with TSIG (Transaction Signatures), as
-defined in RFC 2845.
+\fBdnssec\-keygen\fR
+generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 and RFC <TBA\\>. It can also generate keys for use with TSIG (Transaction Signatures), as defined in RFC 2845.
 .SH "OPTIONS"
 .TP
-\fB-a \fIalgorithm\fB\fR
+\-a \fIalgorithm\fR
 Selects the cryptographic algorithm. The value of
-\fBalgorithm\fR must be one of RSAMD5 (RSA) or RSASHA1,
-DSA, DH (Diffie Hellman), or HMAC-MD5. These values
-are case insensitive.
-
-Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm,
-and DSA is recommended. For TSIG, HMAC-MD5 is mandatory.
-
-Note 2: HMAC-MD5 and DH automatically set the -k flag.
-.TP
-\fB-b \fIkeysize\fB\fR
-Specifies the number of bits in the key. The choice of key
-size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between
-512 and 2048 bits. Diffie Hellman keys must be between
-128 and 4096 bits. DSA keys must be between 512 and 1024
-bits and an exact multiple of 64. HMAC-MD5 keys must be
-between 1 and 512 bits.
-.TP
-\fB-n \fInametype\fB\fR
+\fBalgorithm\fR
+must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC\-MD5. These values are case insensitive.
+.sp
+Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, and DSA is recommended. For TSIG, HMAC\-MD5 is mandatory.
+.sp
+Note 2: HMAC\-MD5 and DH automatically set the \-k flag.
+.TP
+\-b \fIkeysize\fR
+Specifies the number of bits in the key. The choice of key size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between 512 and 2048 bits. Diffie Hellman keys must be between 128 and 4096 bits. DSA keys must be between 512 and 1024 bits and an exact multiple of 64. HMAC\-MD5 keys must be between 1 and 512 bits.
+.TP
+\-n \fInametype\fR
 Specifies the owner type of the key. The value of
-\fBnametype\fR must either be ZONE (for a DNSSEC
-zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)),
-USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are
-case insensitive.
+\fBnametype\fR
+must either be ZONE (for a DNSSEC zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are case insensitive.
 .TP
-\fB-c \fIclass\fB\fR
-Indicates that the DNS record containing the key should have
-the specified class. If not specified, class IN is used.
+\-c \fIclass\fR
+Indicates that the DNS record containing the key should have the specified class. If not specified, class IN is used.
 .TP
-\fB-e\fR
+\-e
 If generating an RSAMD5/RSASHA1 key, use a large exponent.
 .TP
-\fB-f \fIflag\fB\fR
-Set the specified flag in the flag field of the KEY/DNSKEY record.
-The only recognized flag is KSK (Key Signing Key) DNSKEY.
+\-f \fIflag\fR
+Set the specified flag in the flag field of the KEY/DNSKEY record. The only recognized flag is KSK (Key Signing Key) DNSKEY.
 .TP
-\fB-g \fIgenerator\fB\fR
-If generating a Diffie Hellman key, use this generator.
-Allowed values are 2 and 5. If no generator
-is specified, a known prime from RFC 2539 will be used
-if possible; otherwise the default is 2.
+\-g \fIgenerator\fR
+If generating a Diffie Hellman key, use this generator. Allowed values are 2 and 5. If no generator is specified, a known prime from RFC 2539 will be used if possible; otherwise the default is 2.
 .TP
-\fB-h\fR
+\-h
 Prints a short summary of the options and arguments to
-\fBdnssec-keygen\fR.
+\fBdnssec\-keygen\fR.
 .TP
-\fB-k\fR
+\-k
 Generate KEY records rather than DNSKEY records.
 .TP
-\fB-p \fIprotocol\fB\fR
-Sets the protocol value for the generated key. The protocol
-is a number between 0 and 255. The default is 3 (DNSSEC).
-Other possible values for this argument are listed in
-RFC 2535 and its successors.
-.TP
-\fB-r \fIrandomdev\fB\fR
-Specifies the source of randomness. If the operating
-system does not provide a \fI/dev/random\fR
-or equivalent device, the default source of randomness
-is keyboard input. \fIrandomdev\fR specifies
-the name of a character device or file containing random
-data to be used instead of the default. The special value
-\fIkeyboard\fR indicates that keyboard
-input should be used.
-.TP
-\fB-s \fIstrength\fB\fR
-Specifies the strength value of the key. The strength is
-a number between 0 and 15, and currently has no defined
-purpose in DNSSEC.
-.TP
-\fB-t \fItype\fB\fR
-Indicates the use of the key. \fBtype\fR must be
-one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default
-is AUTHCONF. AUTH refers to the ability to authenticate
-data, and CONF the ability to encrypt data.
-.TP
-\fB-v \fIlevel\fB\fR
+\-p \fIprotocol\fR
+Sets the protocol value for the generated key. The protocol is a number between 0 and 255. The default is 3 (DNSSEC). Other possible values for this argument are listed in RFC 2535 and its successors.
+.TP
+\-r \fIrandomdev\fR
+Specifies the source of randomness. If the operating system does not provide a
+\fI/dev/random\fR
+or equivalent device, the default source of randomness is keyboard input.
+\fIrandomdev\fR
+specifies the name of a character device or file containing random data to be used instead of the default. The special value
+\fIkeyboard\fR
+indicates that keyboard input should be used.
+.TP
+\-s \fIstrength\fR
+Specifies the strength value of the key. The strength is a number between 0 and 15, and currently has no defined purpose in DNSSEC.
+.TP
+\-t \fItype\fR
+Indicates the use of the key.
+\fBtype\fR
+must be one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default is AUTHCONF. AUTH refers to the ability to authenticate data, and CONF the ability to encrypt data.
+.TP
+\-v \fIlevel\fR
 Sets the debugging level.
 .SH "GENERATED KEYS"
 .PP
-When \fBdnssec-keygen\fR completes successfully,
-it prints a string of the form \fIKnnnn.+aaa+iiiii\fR
-to the standard output. This is an identification string for
-the key it has generated. These strings can be used as arguments
-to \fBdnssec-makekeyset\fR.
-.TP 0.2i
+When
+\fBdnssec\-keygen\fR
+completes successfully, it prints a string of the form
+\fIKnnnn.+aaa+iiiii\fR
+to the standard output. This is an identification string for the key it has generated.
+.TP 3
 \(bu
-\fInnnn\fR is the key name.
-.TP 0.2i
+\fInnnn\fR
+is the key name.
+.TP
 \(bu
-\fIaaa\fR is the numeric representation of the
-algorithm.
-.TP 0.2i
+\fIaaa\fR
+is the numeric representation of the algorithm.
+.TP
 \(bu
-\fIiiiii\fR is the key identifier (or footprint).
+\fIiiiii\fR
+is the key identifier (or footprint).
 .PP
-\fBdnssec-keygen\fR creates two file, with names based
-on the printed string. \fIKnnnn.+aaa+iiiii.key\fR
+\fBdnssec\-keygen\fR
+creates two file, with names based on the printed string.
+\fIKnnnn.+aaa+iiiii.key\fR
 contains the public key, and
-\fIKnnnn.+aaa+iiiii.private\fR contains the private
-key.
-.PP
-.PP
-The \fI.key\fR file contains a DNS KEY record that
-can be inserted into a zone file (directly or with a $INCLUDE
-statement).
-.PP
-.PP
-The \fI.private\fR file contains algorithm specific
-fields. For obvious security reasons, this file does not have
-general read permission.
-.PP
-.PP
-Both \fI.key\fR and \fI.private\fR
-files are generated for symmetric encryption algorithm such as
-HMAC-MD5, even though the public and private key are equivalent.
-.PP
+\fIKnnnn.+aaa+iiiii.private\fR
+contains the private key.
+.PP
+The
+\fI.key\fR
+file contains a DNS KEY record that can be inserted into a zone file (directly or with a $INCLUDE statement).
+.PP
+The
+\fI.private\fR
+file contains algorithm specific fields. For obvious security reasons, this file does not have general read permission.
+.PP
+Both
+\fI.key\fR
+and
+\fI.private\fR
+files are generated for symmetric encryption algorithm such as HMAC\-MD5, even though the public and private key are equivalent.
 .SH "EXAMPLE"
 .PP
-To generate a 768-bit DSA key for the domain
-\fBexample.com\fR, the following command would be
-issued:
+To generate a 768\-bit DSA key for the domain
+\fBexample.com\fR, the following command would be issued:
 .PP
-\fBdnssec-keygen -a DSA -b 768 -n ZONE example.com\fR
+\fBdnssec\-keygen \-a DSA \-b 768 \-n ZONE example.com\fR
 .PP
 The command would print a string of the form:
 .PP
 \fBKexample.com.+003+26160\fR
 .PP
-In this example, \fBdnssec-keygen\fR creates
-the files \fIKexample.com.+003+26160.key\fR and
+In this example,
+\fBdnssec\-keygen\fR
+creates the files
+\fIKexample.com.+003+26160.key\fR
+and
 \fIKexample.com.+003+26160.private\fR
 .SH "SEE ALSO"
 .PP
-\fBdnssec-signzone\fR(8),
-\fIBIND 9 Administrator Reference Manual\fR,
-\fIRFC 2535\fR,
-\fIRFC 2845\fR,
-\fIRFC 2539\fR.
+\fBdnssec\-signzone\fR(8),
+BIND 9 Administrator Reference Manual,
+RFC 2535,
+RFC 2845,
+RFC 2539.
 .SH "AUTHOR"
 .PP
 Internet Systems Consortium
diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.docbook b/contrib/bind9/bin/dnssec/dnssec-keygen.docbook
index a2034d9e8049..e1eee228ee65 100644
--- a/contrib/bind9/bin/dnssec/dnssec-keygen.docbook
+++ b/contrib/bind9/bin/dnssec/dnssec-keygen.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001-2003  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: dnssec-keygen.docbook,v 1.3.12.6 2004/06/11 01:17:34 marka Exp $ -->
+<!-- $Id: dnssec-keygen.docbook,v 1.3.12.9 2005/08/30 01:41:41 marka Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,21 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><application>dnssec-keygen</application></refname>
     <refpurpose>DNSSEC key generation tool</refpurpose>
@@ -244,8 +261,7 @@
         When <command>dnssec-keygen</command> completes successfully,
 	it prints a string of the form <filename>Knnnn.+aaa+iiiii</filename>
 	to the standard output.  This is an identification string for
-	the key it has generated.  These strings can be used as arguments
-	to <command>dnssec-makekeyset</command>.
+	the key it has generated.
     </para>
     <itemizedlist>
       <listitem>
diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.html b/contrib/bind9/bin/dnssec/dnssec-keygen.html
index 734c914ba617..00271faadf46 100644
--- a/contrib/bind9/bin/dnssec/dnssec-keygen.html
+++ b/contrib/bind9/bin/dnssec/dnssec-keygen.html
@@ -1,544 +1,228 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001-2003  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: dnssec-keygen.html,v 1.5.2.1.4.6 2004/08/22 23:38:58 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->dnssec-keygen</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><SPAN
-CLASS="APPLICATION"
->dnssec-keygen</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->dnssec-keygen</SPAN
->&nbsp;--&nbsp;DNSSEC key generation tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->dnssec-keygen</B
->  {-a <VAR
-CLASS="REPLACEABLE"
->algorithm</VAR
->} {-b <VAR
-CLASS="REPLACEABLE"
->keysize</VAR
->} {-n <VAR
-CLASS="REPLACEABLE"
->nametype</VAR
->} [<VAR
-CLASS="OPTION"
->-c <VAR
-CLASS="REPLACEABLE"
->class</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-e</VAR
->] [<VAR
-CLASS="OPTION"
->-f <VAR
-CLASS="REPLACEABLE"
->flag</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-g <VAR
-CLASS="REPLACEABLE"
->generator</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-h</VAR
->] [<VAR
-CLASS="OPTION"
->-k</VAR
->] [<VAR
-CLASS="OPTION"
->-p <VAR
-CLASS="REPLACEABLE"
->protocol</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-r <VAR
-CLASS="REPLACEABLE"
->randomdev</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-s <VAR
-CLASS="REPLACEABLE"
->strength</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->type</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-v <VAR
-CLASS="REPLACEABLE"
->level</VAR
-></VAR
->] {name}</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN53"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->dnssec-keygen</B
-> generates keys for DNSSEC
+<!-- $Id: dnssec-keygen.html,v 1.5.2.1.4.13 2005/10/13 02:33:45 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dnssec-keygen</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">dnssec-keygen</span> &#8212; DNSSEC key generation tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code>  {-a <em class="replaceable"><code>algorithm</code></em>} {-b <em class="replaceable"><code>keysize</code></em>} {-n <em class="replaceable"><code>nametype</code></em>} [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k</code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {name}</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525956"></a><h2>DESCRIPTION</h2>
+<p>
+        <span><strong class="command">dnssec-keygen</strong></span> generates keys for DNSSEC
 	(Secure DNS), as defined in RFC 2535 and RFC &lt;TBA\&gt;.  It can also generate
 	keys for use with TSIG (Transaction Signatures), as
 	defined in RFC 2845.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN57"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-a <VAR
-CLASS="REPLACEABLE"
->algorithm</VAR
-></DT
-><DD
-><P
->	      Selects the cryptographic algorithm.  The value of
-	      <VAR
-CLASS="OPTION"
->algorithm</VAR
-> must be one of RSAMD5 (RSA) or RSASHA1,
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525969"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
+<dd>
+<p>
+	      Selects the cryptographic algorithm.  The value of
+	      <code class="option">algorithm</code> must be one of RSAMD5 (RSA) or RSASHA1,
 	      DSA, DH (Diffie Hellman), or HMAC-MD5.  These values
 	      are case insensitive.
-	  </P
-><P
->	      Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm,
+	  </p>
+<p>
+	      Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm,
 	      and DSA is recommended.  For TSIG, HMAC-MD5 is mandatory.
-	  </P
-><P
->	      Note 2: HMAC-MD5 and DH automatically set the -k flag.
-	  </P
-></DD
-><DT
->-b <VAR
-CLASS="REPLACEABLE"
->keysize</VAR
-></DT
-><DD
-><P
->	       Specifies the number of bits in the key.  The choice of key
+	  </p>
+<p>
+	      Note 2: HMAC-MD5 and DH automatically set the -k flag.
+	  </p>
+</dd>
+<dt><span class="term">-b <em class="replaceable"><code>keysize</code></em></span></dt>
+<dd><p>
+	       Specifies the number of bits in the key.  The choice of key
 	       size depends on the algorithm used.  RSAMD5 / RSASHA1 keys must be between
 	       512 and 2048 bits.  Diffie Hellman keys must be between
 	       128 and 4096 bits.  DSA keys must be between 512 and 1024
 	       bits and an exact multiple of 64.  HMAC-MD5 keys must be
 	       between 1 and 512 bits.
-	  </P
-></DD
-><DT
->-n <VAR
-CLASS="REPLACEABLE"
->nametype</VAR
-></DT
-><DD
-><P
->	       Specifies the owner type of the key.  The value of
-	       <VAR
-CLASS="OPTION"
->nametype</VAR
-> must either be ZONE (for a DNSSEC
+	  </p></dd>
+<dt><span class="term">-n <em class="replaceable"><code>nametype</code></em></span></dt>
+<dd><p>
+	       Specifies the owner type of the key.  The value of
+	       <code class="option">nametype</code> must either be ZONE (for a DNSSEC
 	       zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)),
 	       USER (for a key associated with a user(KEY)) or OTHER (DNSKEY).  These values are
 	       case insensitive.
-	  </P
-></DD
-><DT
->-c <VAR
-CLASS="REPLACEABLE"
->class</VAR
-></DT
-><DD
-><P
->	       Indicates that the DNS record containing the key should have
+	  </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
+<dd><p>
+	       Indicates that the DNS record containing the key should have
 	       the specified class.  If not specified, class IN is used.
-	  </P
-></DD
-><DT
->-e</DT
-><DD
-><P
->	       If generating an RSAMD5/RSASHA1 key, use a large exponent.
-	  </P
-></DD
-><DT
->-f <VAR
-CLASS="REPLACEABLE"
->flag</VAR
-></DT
-><DD
-><P
->		Set the specified flag in the flag field of the KEY/DNSKEY record.
+	  </p></dd>
+<dt><span class="term">-e</span></dt>
+<dd><p>
+	       If generating an RSAMD5/RSASHA1 key, use a large exponent.
+	  </p></dd>
+<dt><span class="term">-f <em class="replaceable"><code>flag</code></em></span></dt>
+<dd><p>
+		Set the specified flag in the flag field of the KEY/DNSKEY record.
 		The only recognized flag is KSK (Key Signing Key) DNSKEY.
-	  </P
-></DD
-><DT
->-g <VAR
-CLASS="REPLACEABLE"
->generator</VAR
-></DT
-><DD
-><P
->	       If generating a Diffie Hellman key, use this generator.
+	  </p></dd>
+<dt><span class="term">-g <em class="replaceable"><code>generator</code></em></span></dt>
+<dd><p>
+	       If generating a Diffie Hellman key, use this generator.
 	       Allowed values are 2 and 5.  If no generator
 	       is specified, a known prime from RFC 2539 will be used
 	       if possible; otherwise the default is 2.
-	  </P
-></DD
-><DT
->-h</DT
-><DD
-><P
->	       Prints a short summary of the options and arguments to
-	       <B
-CLASS="COMMAND"
->dnssec-keygen</B
->.
-	  </P
-></DD
-><DT
->-k</DT
-><DD
-><P
->	       Generate KEY records rather than DNSKEY records.
-	  </P
-></DD
-><DT
->-p <VAR
-CLASS="REPLACEABLE"
->protocol</VAR
-></DT
-><DD
-><P
->	       Sets the protocol value for the generated key.  The protocol
+	  </p></dd>
+<dt><span class="term">-h</span></dt>
+<dd><p>
+	       Prints a short summary of the options and arguments to
+	       <span><strong class="command">dnssec-keygen</strong></span>.
+	  </p></dd>
+<dt><span class="term">-k</span></dt>
+<dd><p>
+	       Generate KEY records rather than DNSKEY records.
+	  </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>protocol</code></em></span></dt>
+<dd><p>
+	       Sets the protocol value for the generated key.  The protocol
 	       is a number between 0 and 255.  The default is 3 (DNSSEC).
 	       Other possible values for this argument are listed in
 	       RFC 2535 and its successors.
-	  </P
-></DD
-><DT
->-r <VAR
-CLASS="REPLACEABLE"
->randomdev</VAR
-></DT
-><DD
-><P
->	       Specifies the source of randomness.  If the operating
-	       system does not provide a <TT
-CLASS="FILENAME"
->/dev/random</TT
->
+	  </p></dd>
+<dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt>
+<dd><p>
+	       Specifies the source of randomness.  If the operating
+	       system does not provide a <code class="filename">/dev/random</code>
 	       or equivalent device, the default source of randomness
-	       is keyboard input.  <TT
-CLASS="FILENAME"
->randomdev</TT
-> specifies
+	       is keyboard input.  <code class="filename">randomdev</code> specifies
 	       the name of a character device or file containing random
 	       data to be used instead of the default.  The special value
-	       <TT
-CLASS="FILENAME"
->keyboard</TT
-> indicates that keyboard
+	       <code class="filename">keyboard</code> indicates that keyboard
 	       input should be used.
-	  </P
-></DD
-><DT
->-s <VAR
-CLASS="REPLACEABLE"
->strength</VAR
-></DT
-><DD
-><P
->	       Specifies the strength value of the key.  The strength is
+	  </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>strength</code></em></span></dt>
+<dd><p>
+	       Specifies the strength value of the key.  The strength is
 	       a number between 0 and 15, and currently has no defined
 	       purpose in DNSSEC.
-	  </P
-></DD
-><DT
->-t <VAR
-CLASS="REPLACEABLE"
->type</VAR
-></DT
-><DD
-><P
->	       Indicates the use of the key.  <VAR
-CLASS="OPTION"
->type</VAR
-> must be
+	  </p></dd>
+<dt><span class="term">-t <em class="replaceable"><code>type</code></em></span></dt>
+<dd><p>
+	       Indicates the use of the key.  <code class="option">type</code> must be
 	       one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF.  The default
 	       is AUTHCONF.  AUTH refers to the ability to authenticate
 	       data, and CONF the ability to encrypt data.
-	  </P
-></DD
-><DT
->-v <VAR
-CLASS="REPLACEABLE"
->level</VAR
-></DT
-><DD
-><P
->	       Sets the debugging level.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN136"
-></A
-><H2
->GENERATED KEYS</H2
-><P
->        When <B
-CLASS="COMMAND"
->dnssec-keygen</B
-> completes successfully,
-	it prints a string of the form <TT
-CLASS="FILENAME"
->Knnnn.+aaa+iiiii</TT
->
+	  </p></dd>
+<dt><span class="term">-v <em class="replaceable"><code>level</code></em></span></dt>
+<dd><p>
+	       Sets the debugging level.
+	  </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526306"></a><h2>GENERATED KEYS</h2>
+<p>
+        When <span><strong class="command">dnssec-keygen</strong></span> completes successfully,
+	it prints a string of the form <code class="filename">Knnnn.+aaa+iiiii</code>
 	to the standard output.  This is an identification string for
-	the key it has generated.  These strings can be used as arguments
-	to <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
->.
-    </P
-><P
-></P
-><UL
-><LI
-><P
->          <TT
-CLASS="FILENAME"
->nnnn</TT
-> is the key name.
-        </P
-></LI
-><LI
-><P
->          <TT
-CLASS="FILENAME"
->aaa</TT
-> is the numeric representation of the
+	the key it has generated.
+    </p>
+<div class="itemizedlist"><ul type="disc">
+<li><p>
+          <code class="filename">nnnn</code> is the key name.
+        </p></li>
+<li><p>
+          <code class="filename">aaa</code> is the numeric representation of the
           algorithm.
-        </P
-></LI
-><LI
-><P
->          <TT
-CLASS="FILENAME"
->iiiii</TT
-> is the key identifier (or footprint).
-        </P
-></LI
-></UL
-><P
->        <B
-CLASS="COMMAND"
->dnssec-keygen</B
-> creates two file, with names based
-	on the printed string.  <TT
-CLASS="FILENAME"
->Knnnn.+aaa+iiiii.key</TT
->
+        </p></li>
+<li><p>
+          <code class="filename">iiiii</code> is the key identifier (or footprint).
+        </p></li>
+</ul></div>
+<p>
+        <span><strong class="command">dnssec-keygen</strong></span> creates two file, with names based
+	on the printed string.  <code class="filename">Knnnn.+aaa+iiiii.key</code>
 	contains the public key, and
-	<TT
-CLASS="FILENAME"
->Knnnn.+aaa+iiiii.private</TT
-> contains the private
+	<code class="filename">Knnnn.+aaa+iiiii.private</code> contains the private
 	key.
-    </P
-><P
->        The <TT
-CLASS="FILENAME"
->.key</TT
-> file contains a DNS KEY record that
+    </p>
+<p>
+        The <code class="filename">.key</code> file contains a DNS KEY record that
 	can be inserted into a zone file (directly or with a $INCLUDE
 	statement).
-    </P
-><P
->        The <TT
-CLASS="FILENAME"
->.private</TT
-> file contains algorithm specific
+    </p>
+<p>
+        The <code class="filename">.private</code> file contains algorithm specific
 	fields.  For obvious security reasons, this file does not have
 	general read permission.
-    </P
-><P
->        Both <TT
-CLASS="FILENAME"
->.key</TT
-> and <TT
-CLASS="FILENAME"
->.private</TT
->
+    </p>
+<p>
+        Both <code class="filename">.key</code> and <code class="filename">.private</code>
 	files are generated for symmetric encryption algorithm such as
 	HMAC-MD5, even though the public and private key are equivalent.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN163"
-></A
-><H2
->EXAMPLE</H2
-><P
->        To generate a 768-bit DSA key for the domain
-	<KBD
-CLASS="USERINPUT"
->example.com</KBD
->, the following command would be
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526394"></a><h2>EXAMPLE</h2>
+<p>
+        To generate a 768-bit DSA key for the domain
+	<strong class="userinput"><code>example.com</code></strong>, the following command would be
 	issued:
-    </P
-><P
->        <KBD
-CLASS="USERINPUT"
->dnssec-keygen -a DSA -b 768 -n ZONE example.com</KBD
->
-    </P
-><P
->        The command would print a string of the form:
-    </P
-><P
->        <KBD
-CLASS="USERINPUT"
->Kexample.com.+003+26160</KBD
->
-    </P
-><P
->        In this example, <B
-CLASS="COMMAND"
->dnssec-keygen</B
-> creates
-	the files <TT
-CLASS="FILENAME"
->Kexample.com.+003+26160.key</TT
-> and
-	<TT
-CLASS="FILENAME"
->Kexample.com.+003+26160.private</TT
->
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN176"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-signzone</SPAN
->(8)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->,
-      <I
-CLASS="CITETITLE"
->RFC 2535</I
->,
-      <I
-CLASS="CITETITLE"
->RFC 2845</I
->,
-      <I
-CLASS="CITETITLE"
->RFC 2539</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN186"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+    </p>
+<p>
+        <strong class="userinput"><code>dnssec-keygen -a DSA -b 768 -n ZONE example.com</code></strong>
+    </p>
+<p>
+        The command would print a string of the form:
+    </p>
+<p>
+        <strong class="userinput"><code>Kexample.com.+003+26160</code></strong>
+    </p>
+<p>
+        In this example, <span><strong class="command">dnssec-keygen</strong></span> creates
+	the files <code class="filename">Kexample.com.+003+26160.key</code> and
+	<code class="filename">Kexample.com.+003+26160.private</code>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526440"></a><h2>SEE ALSO</h2>
+<p>
+      <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
+      <em class="citetitle">RFC 2535</em>,
+      <em class="citetitle">RFC 2845</em>,
+      <em class="citetitle">RFC 2539</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526473"></a><h2>AUTHOR</h2>
+<p>
+        <span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.8 b/contrib/bind9/bin/dnssec/dnssec-makekeyset.8
deleted file mode 100644
index 0189b31e62e5..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-makekeyset.8
+++ /dev/null
@@ -1,113 +0,0 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
-.\"
-.\" Permission to use, copy, modify, and distribute this software for any
-.\" purpose with or without fee is hereby granted, provided that the above
-.\" copyright notice and this permission notice appear in all copies.
-.\"
-.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-.\" PERFORMANCE OF THIS SOFTWARE.
-.\"
-.\" $Id: dnssec-makekeyset.8,v 1.16.2.2.4.1 2004/03/06 07:41:39 marka Exp $
-.\"
-.TH "DNSSEC-MAKEKEYSET" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
-dnssec-makekeyset \- DNSSEC zone signing tool
-.SH SYNOPSIS
-.sp
-\fBdnssec-makekeyset\fR [ \fB-a\fR ]  [ \fB-s \fIstart-time\fB\fR ]  [ \fB-e \fIend-time\fB\fR ]  [ \fB-h\fR ]  [ \fB-p\fR ]  [ \fB-r \fIrandomdev\fB\fR ]  [ \fB-t\fIttl\fB\fR ]  [ \fB-v \fIlevel\fB\fR ]  \fBkey\fR\fI...\fR
-.SH "DESCRIPTION"
-.PP
-\fBdnssec-makekeyset\fR generates a key set from one
-or more keys created by \fBdnssec-keygen\fR. It creates
-a file containing a KEY record for each key, and self-signs the key
-set with each zone key. The output file is of the form
-\fIkeyset-nnnn.\fR, where \fInnnn\fR
-is the zone name.
-.SH "OPTIONS"
-.TP
-\fB-a\fR
-Verify all generated signatures.
-.TP
-\fB-s \fIstart-time\fB\fR
-Specify the date and time when the generated SIG records
-become valid. This can be either an absolute or relative
-time. An absolute start time is indicated by a number
-in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-14:45:00 UTC on May 30th, 2000. A relative start time is
-indicated by +N, which is N seconds from the current time.
-If no \fBstart-time\fR is specified, the current
-time is used.
-.TP
-\fB-e \fIend-time\fB\fR
-Specify the date and time when the generated SIG records
-expire. As with \fBstart-time\fR, an absolute
-time is indicated in YYYYMMDDHHMMSS notation. A time relative
-to the start time is indicated with +N, which is N seconds from
-the start time. A time relative to the current time is
-indicated with now+N. If no \fBend-time\fR is
-specified, 30 days from the start time is used as a default.
-.TP
-\fB-h\fR
-Prints a short summary of the options and arguments to
-\fBdnssec-makekeyset\fR.
-.TP
-\fB-p\fR
-Use pseudo-random data when signing the zone. This is faster,
-but less secure, than using real random data. This option
-may be useful when signing large zones or when the entropy
-source is limited.
-.TP
-\fB-r \fIrandomdev\fB\fR
-Specifies the source of randomness. If the operating
-system does not provide a \fI/dev/random\fR
-or equivalent device, the default source of randomness
-is keyboard input. \fIrandomdev\fR specifies
-the name of a character device or file containing random
-data to be used instead of the default. The special value
-\fIkeyboard\fR indicates that keyboard
-input should be used.
-.TP
-\fB-t \fIttl\fB\fR
-Specify the TTL (time to live) of the KEY and SIG records.
-The default is 3600 seconds.
-.TP
-\fB-v \fIlevel\fB\fR
-Sets the debugging level.
-.TP
-\fBkey\fR
-The list of keys to be included in the keyset file. These keys
-are expressed in the form \fIKnnnn.+aaa+iiiii\fR
-as generated by \fBdnssec-keygen\fR.
-.SH "EXAMPLE"
-.PP
-The following command generates a keyset containing the DSA key for
-\fBexample.com\fR generated in the
-\fBdnssec-keygen\fR man page.
-.PP
-\fBdnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160\fR
-.PP
-In this example, \fBdnssec-makekeyset\fR creates
-the file \fIkeyset-example.com.\fR. This file
-contains the specified key and a self-generated signature.
-.PP
-The DNS administrator for \fBexample.com\fR could
-send \fIkeyset-example.com.\fR to the DNS
-administrator for \fB.com\fR for signing, if the
-\&.com zone is DNSSEC-aware and the administrators of the two zones
-have some mechanism for authenticating each other and exchanging
-the keys and signatures securely.
-.SH "SEE ALSO"
-.PP
-\fBdnssec-keygen\fR(8),
-\fBdnssec-signkey\fR(8),
-\fIBIND 9 Administrator Reference Manual\fR,
-\fIRFC 2535\fR.
-.SH "AUTHOR"
-.PP
-Internet Software Consortium
diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.c b/contrib/bind9/bin/dnssec/dnssec-makekeyset.c
deleted file mode 100644
index c8224ed3888f..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-makekeyset.c
+++ /dev/null
@@ -1,401 +0,0 @@
-/*
- * Portions Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (C) 2000-2003  Internet Software Consortium.
- * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
- *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC AND NETWORK ASSOCIATES DISCLAIMS
- * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE
- * FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
- * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-/* $Id: dnssec-makekeyset.c,v 1.52.2.1.10.7 2004/08/28 06:25:27 marka Exp $ */
-
-#include <config.h>
-
-#include <stdlib.h>
-
-#include <isc/commandline.h>
-#include <isc/entropy.h>
-#include <isc/mem.h>
-#include <isc/print.h>
-#include <isc/string.h>
-#include <isc/util.h>
-
-#include <dns/db.h>
-#include <dns/diff.h>
-#include <dns/dnssec.h>
-#include <dns/fixedname.h>
-#include <dns/log.h>
-#include <dns/rdata.h>
-#include <dns/rdataset.h>
-#include <dns/result.h>
-#include <dns/secalg.h>
-#include <dns/time.h>
-
-#include <dst/dst.h>
-
-#include "dnssectool.h"
-
-const char *program = "dnssec-makekeyset";
-int verbose;
-
-typedef struct keynode keynode_t;
-struct keynode {
-	dst_key_t *key;
-	ISC_LINK(keynode_t) link;
-};
-typedef ISC_LIST(keynode_t) keylist_t;
-
-static isc_stdtime_t starttime = 0, endtime = 0, now;
-static int ttl = -1;
-
-static isc_mem_t *mctx = NULL;
-static isc_entropy_t *ectx = NULL;
-
-static keylist_t keylist;
-
-static void
-usage(void) {
-	fprintf(stderr, "Usage:\n");
-	fprintf(stderr, "\t%s [options] keys\n", program);
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "Version: %s\n", VERSION);
-
-	fprintf(stderr, "Options: (default value in parenthesis) \n");
-	fprintf(stderr, "\t-a\n");
-	fprintf(stderr, "\t\tverify generated signatures\n");
-	fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n");
-	fprintf(stderr, "\t\tSIG start time - absolute|offset (now)\n");
-	fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n");
-	fprintf(stderr, "\t\tSIG end time  - "
-			     "absolute|from start|from now (now + 30 days)\n");
-	fprintf(stderr, "\t-t ttl\n");
-	fprintf(stderr, "\t-p\n");
-	fprintf(stderr, "\t\tuse pseudorandom data (faster but less secure)\n");
-	fprintf(stderr, "\t-r randomdev:\n");
-	fprintf(stderr, "\t\ta file containing random data\n");
-	fprintf(stderr, "\t-v level:\n");
-	fprintf(stderr, "\t\tverbose level (0)\n");
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "keys:\n");
-	fprintf(stderr, "\tkeyfile (Kname+alg+tag)\n");
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "Output:\n");
-	fprintf(stderr, "\tkeyset (keyset-<name>)\n");
-	exit(0);
-}
-
-static isc_boolean_t
-zonekey_on_list(dst_key_t *key) {
-	keynode_t *keynode;
-	for (keynode = ISC_LIST_HEAD(keylist);
-	     keynode != NULL;
-	     keynode = ISC_LIST_NEXT(keynode, link))
-	{
-		if (dst_key_compare(keynode->key, key))
-			return (ISC_TRUE);
-	}
-	return (ISC_FALSE);
-}
-
-int
-main(int argc, char *argv[]) {
-	int i, ch;
-	char *startstr = NULL, *endstr = NULL;
-	dns_fixedname_t fdomain;
-	dns_name_t *domain = NULL;
-	char *output = NULL;
-	char *endp;
-	unsigned char data[65536];
-	dns_db_t *db;
-	dns_dbversion_t *version;
-	dns_diff_t diff;
-	dns_difftuple_t *tuple;
-	dns_fixedname_t tname;
-	dst_key_t *key = NULL;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
-	dns_rdataset_t rdataset;
-	dns_rdataclass_t rdclass;
-	isc_result_t result;
-	isc_buffer_t b;
-	isc_region_t r;
-	isc_log_t *log = NULL;
-	keynode_t *keynode;
-	unsigned int eflags;
-	isc_boolean_t pseudorandom = ISC_FALSE;
-	isc_boolean_t tryverify = ISC_FALSE;
-
-	result = isc_mem_create(0, 0, &mctx);
-	if (result != ISC_R_SUCCESS)
-		fatal("failed to create memory context: %s",
-		      isc_result_totext(result));
-
-	dns_result_register();
-
-	while ((ch = isc_commandline_parse(argc, argv, "as:e:t:r:v:ph")) != -1)
-	{
-		switch (ch) {
-		case 'a':
-			tryverify = ISC_TRUE;
-			break;
-		case 's':
-			startstr = isc_commandline_argument;
-			break;
-
-		case 'e':
-			endstr = isc_commandline_argument;
-			break;
-
-		case 't':
-			endp = NULL;
-			ttl = strtol(isc_commandline_argument, &endp, 0);
-			if (*endp != '\0')
-				fatal("TTL must be numeric");
-			break;
-
-		case 'r':
-			setup_entropy(mctx, isc_commandline_argument, &ectx);
-			break;
-
-		case 'v':
-			endp = NULL;
-			verbose = strtol(isc_commandline_argument, &endp, 0);
-			if (*endp != '\0')
-				fatal("verbose level must be numeric");
-			break;
-
-		case 'p':
-			pseudorandom = ISC_TRUE;
-			break;
-
-		case 'h':
-		default:
-			usage();
-
-		}
-	}
-
-	argc -= isc_commandline_index;
-	argv += isc_commandline_index;
-
-	if (argc < 1)
-		usage();
-
-	if (ectx == NULL)
-		setup_entropy(mctx, NULL, &ectx);
-	eflags = ISC_ENTROPY_BLOCKING;
-	if (!pseudorandom)
-		eflags |= ISC_ENTROPY_GOODONLY;
-	result = dst_lib_init(mctx, ectx, eflags);
-	if (result != ISC_R_SUCCESS)
-		fatal("could not initialize dst: %s", 
-		      isc_result_totext(result));
-
-	isc_stdtime_get(&now);
-
-	if (startstr != NULL)
-		starttime = strtotime(startstr, now, now);
-	else
-		starttime = now;
-
-	if (endstr != NULL)
-		endtime = strtotime(endstr, now, starttime);
-	else
-		endtime = starttime + (30 * 24 * 60 * 60);
-
-	if (ttl == -1) {
-		ttl = 3600;
-		fprintf(stderr, "%s: TTL not specified, assuming 3600\n",
-			program);
-	}
-
-	setup_logging(verbose, mctx, &log);
-
-	dns_diff_init(mctx, &diff);
-	rdclass = 0;
-
-	ISC_LIST_INIT(keylist);
-
-	for (i = 0; i < argc; i++) {
-		char namestr[DNS_NAME_FORMATSIZE];
-		isc_buffer_t namebuf;
-
-		key = NULL;
-		result = dst_key_fromnamedfile(argv[i], DST_TYPE_PUBLIC,
-					       mctx, &key);
-		if (result != ISC_R_SUCCESS)
-			fatal("error loading key from %s: %s", argv[i],
-			      isc_result_totext(result));
-		if (rdclass == 0)
-			rdclass = dst_key_class(key);
-
-		isc_buffer_init(&namebuf, namestr, sizeof(namestr));
-		result = dns_name_tofilenametext(dst_key_name(key),
-						 ISC_FALSE,
-						 &namebuf);
-		check_result(result, "dns_name_tofilenametext");
-		isc_buffer_putuint8(&namebuf, 0);
-
-		if (domain == NULL) {
-			dns_fixedname_init(&fdomain);
-			domain = dns_fixedname_name(&fdomain);
-			dns_name_copy(dst_key_name(key), domain, NULL);
-		} else if (!dns_name_equal(domain, dst_key_name(key))) {
-			char str[DNS_NAME_FORMATSIZE];
-			dns_name_format(domain, str, sizeof(str));
-			fatal("all keys must have the same owner - %s "
-			      "and %s do not match", str, namestr);
-		}
-
-		if (output == NULL) {
-			output = isc_mem_allocate(mctx,
-						  strlen("keyset-") +
-						  strlen(namestr) + 1);
-			if (output == NULL)
-				fatal("out of memory");
-			sprintf(output, "keyset-%s", namestr);
-		}
-
-		if (dst_key_iszonekey(key)) {
-			dst_key_t *zonekey = NULL;
-			result = dst_key_fromnamedfile(argv[i],
-						       DST_TYPE_PUBLIC |
-						       DST_TYPE_PRIVATE,
-						       mctx, &zonekey);
-			if (result != ISC_R_SUCCESS)
-				fatal("failed to read private key %s: %s",
-				      argv[i], isc_result_totext(result));
-			if (!zonekey_on_list(zonekey)) {
-				keynode = isc_mem_get(mctx, sizeof(keynode_t));
-				if (keynode == NULL)
-					fatal("out of memory");
-				keynode->key = zonekey;
-				ISC_LIST_INITANDAPPEND(keylist, keynode, link);
-			} else
-				dst_key_free(&zonekey);
-		}
-		dns_rdata_reset(&rdata);
-		isc_buffer_init(&b, data, sizeof(data));
-		result = dst_key_todns(key, &b);
-		dst_key_free(&key);
-		if (result != ISC_R_SUCCESS)
-			fatal("failed to convert key %s to a DNS KEY: %s",
-			      argv[i], isc_result_totext(result));
-		isc_buffer_usedregion(&b, &r);
-		dns_rdata_fromregion(&rdata, rdclass, dns_rdatatype_dnskey, &r);
-		tuple = NULL;
-		result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD,
-					      domain, ttl, &rdata, &tuple);
-		check_result(result, "dns_difftuple_create");
-		dns_diff_append(&diff, &tuple);
-	}
-
-	db = NULL;
-	result = dns_db_create(mctx, "rbt", dns_rootname, dns_dbtype_zone,
-			       rdclass, 0, NULL, &db);
-	if (result != ISC_R_SUCCESS)
-		fatal("failed to create a database");
-
-	version = NULL;
-	dns_db_newversion(db, &version);
-
-	result = dns_diff_apply(&diff, db, version);
-	check_result(result, "dns_diff_apply");
-	dns_diff_clear(&diff);
-
-	dns_fixedname_init(&tname);
-	dns_rdataset_init(&rdataset);
-	result = dns_db_find(db, domain, version, dns_rdatatype_dnskey, 0, 0,
-			     NULL, dns_fixedname_name(&tname), &rdataset,
-			     NULL);
-	check_result(result, "dns_db_find");
-
-	if (ISC_LIST_EMPTY(keylist))
-		fprintf(stderr,
-			"%s: no private zone key found; not self-signing\n",
-			program);
-	for (keynode = ISC_LIST_HEAD(keylist);
-	     keynode != NULL;
-	     keynode = ISC_LIST_NEXT(keynode, link))
-	{
-		dns_rdata_reset(&rdata);
-		isc_buffer_init(&b, data, sizeof(data));
-		result = dns_dnssec_sign(domain, &rdataset, keynode->key,
-					 &starttime, &endtime, mctx, &b,
-					 &rdata);
-		isc_entropy_stopcallbacksources(ectx);
-		if (result != ISC_R_SUCCESS) {
-			char keystr[KEY_FORMATSIZE];
-			key_format(keynode->key, keystr, sizeof(keystr));
-			fatal("failed to sign keyset with key %s: %s",
-			      keystr, isc_result_totext(result));
-		}
-		if (tryverify) {
-			result = dns_dnssec_verify(domain, &rdataset,
-						   keynode->key, ISC_TRUE,
-						   mctx, &rdata);
-			if (result != ISC_R_SUCCESS) {
-				char keystr[KEY_FORMATSIZE];
-				key_format(keynode->key, keystr, sizeof(keystr));
-				fatal("signature from key '%s' failed to "
-				      "verify: %s",
-				      keystr, isc_result_totext(result));
-			}
-		}
-		tuple = NULL;
-		result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD,
-					      domain, ttl, &rdata, &tuple);
-		check_result(result, "dns_difftuple_create");
-		dns_diff_append(&diff, &tuple);
-	}
-
-	result = dns_diff_apply(&diff, db, version);
-	check_result(result, "dns_diff_apply");
-	dns_diff_clear(&diff);
-
-	dns_rdataset_disassociate(&rdataset);
-
-	dns_db_closeversion(db, &version, ISC_TRUE);
-	result = dns_db_dump(db, version, output);
-	if (result != ISC_R_SUCCESS) {
-		char domainstr[DNS_NAME_FORMATSIZE];
-		dns_name_format(domain, domainstr, sizeof(domainstr));
-		fatal("failed to write database for %s to %s",
-		      domainstr, output);
-	}
-
-	printf("%s\n", output);
-
-	dns_db_detach(&db);
-
-	while (!ISC_LIST_EMPTY(keylist)) {
-		keynode = ISC_LIST_HEAD(keylist);
-		ISC_LIST_UNLINK(keylist, keynode, link);
-		dst_key_free(&keynode->key);
-		isc_mem_put(mctx, keynode, sizeof(keynode_t));
-	}
-
-	cleanup_logging(&log);
-	cleanup_entropy(&ectx);
-
-	isc_mem_free(mctx, output);
-	dst_lib_destroy();
-	if (verbose > 10)
-		isc_mem_stats(mctx, stdout);
-	isc_mem_destroy(&mctx);
-	return (0);
-}
diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook b/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook
deleted file mode 100644
index 07327481550b..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook
+++ /dev/null
@@ -1,233 +0,0 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
-<!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- $Id: dnssec-makekeyset.docbook,v 1.2.2.3.4.2 2004/06/03 02:24:55 marka Exp $ -->
-
-<refentry>
-  <refentryinfo>
-    <date>June 30, 2000</date>
-  </refentryinfo>
-
-  <refmeta>
-    <refentrytitle><application>dnssec-makekeyset</application></refentrytitle>
-    <manvolnum>8</manvolnum>
-    <refmiscinfo>BIND9</refmiscinfo>
-  </refmeta>
-
-  <refnamediv>
-    <refname><application>dnssec-makekeyset</application></refname>
-    <refpurpose>DNSSEC zone signing tool</refpurpose>
-  </refnamediv>
-
-  <refsynopsisdiv>
-    <cmdsynopsis>
-      <command>dnssec-makekeyset</command>
-      <arg><option>-a</option></arg>
-      <arg><option>-s <replaceable class="parameter">start-time</replaceable></option></arg>
-      <arg><option>-e <replaceable class="parameter">end-time</replaceable></option></arg>
-      <arg><option>-h</option></arg>
-      <arg><option>-p</option></arg>
-      <arg><option>-r <replaceable class="parameter">randomdev</replaceable></option></arg>
-      <arg><option>-t</option><replaceable class="parameter">ttl</replaceable></arg>
-      <arg><option>-v <replaceable class="parameter">level</replaceable></option></arg>
-      <arg choice="req" rep="repeat">key</arg>
-    </cmdsynopsis>
-  </refsynopsisdiv>
-
-  <refsect1>
-    <title>DESCRIPTION</title>
-    <para>
-        <command>dnssec-makekeyset</command> generates a key set from one
-	or more keys created by <command>dnssec-keygen</command>.  It creates
-	a file containing a KEY record for each key, and self-signs the key
-	set with each zone key.  The output file is of the form
-	<filename>keyset-nnnn.</filename>, where <filename>nnnn</filename>
-	is the zone name.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>OPTIONS</title>
-
-    <variablelist>
-      <varlistentry>
-        <term>-a</term>
-	<listitem>
-	  <para>
-	      Verify all generated signatures.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-s <replaceable class="parameter">start-time</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the date and time when the generated SIG records
-	       become valid.  This can be either an absolute or relative
-	       time.  An absolute start time is indicated by a number
-	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-	       14:45:00 UTC on May 30th, 2000.  A relative start time is
-	       indicated by +N, which is N seconds from the current time.
-	       If no <option>start-time</option> is specified, the current
-	       time is used.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-e <replaceable class="parameter">end-time</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the date and time when the generated SIG records
-	       expire.  As with <option>start-time</option>, an absolute
-	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-	       to the start time is indicated with +N, which is N seconds from
-	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <option>end-time</option> is
-	       specified, 30 days from the start time is used as a default.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-h</term>
-	<listitem>
-	  <para>
-	       Prints a short summary of the options and arguments to
-	       <command>dnssec-makekeyset</command>.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-p</term>
-	<listitem>
-	  <para>
-	       Use pseudo-random data when signing the zone.  This is faster,
-	       but less secure, than using real random data.  This option
-	       may be useful when signing large zones or when the entropy
-	       source is limited.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-r <replaceable class="parameter">randomdev</replaceable></term>
-	<listitem>
-	  <para>
-	       Specifies the source of randomness.  If the operating
-	       system does not provide a <filename>/dev/random</filename>
-	       or equivalent device, the default source of randomness
-	       is keyboard input.  <filename>randomdev</filename> specifies
-	       the name of a character device or file containing random
-	       data to be used instead of the default.  The special value
-	       <filename>keyboard</filename> indicates that keyboard
-	       input should be used.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-t <replaceable class="parameter">ttl</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the TTL (time to live) of the KEY and SIG records.
-	       The default is 3600 seconds.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-v <replaceable class="parameter">level</replaceable></term>
-	<listitem>
-	  <para>
-	       Sets the debugging level.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>key</term>
-	<listitem>
-	  <para>
-	       The list of keys to be included in the keyset file.  These keys
-	       are expressed in the form <filename>Knnnn.+aaa+iiiii</filename>
-	       as generated by <command>dnssec-keygen</command>.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-    </variablelist>
-  </refsect1>
-
-  <refsect1>
-    <title>EXAMPLE</title>
-    <para>
-        The following command generates a keyset containing the DSA key for
-	<userinput>example.com</userinput> generated in the
-	<command>dnssec-keygen</command> man page.
-    </para>
-    <para>
-        <userinput>dnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160</userinput>
-    </para>
-    <para>
-        In this example, <command>dnssec-makekeyset</command> creates
-	the file <filename>keyset-example.com.</filename>.  This file
-	contains the specified key and a self-generated signature.
-    </para>
-    <para>
-        The DNS administrator for <userinput>example.com</userinput> could
-	send <filename>keyset-example.com.</filename> to the DNS
-	administrator for <userinput>.com</userinput> for signing, if the
-	.com zone is DNSSEC-aware and the administrators of the two zones
-	have some mechanism for authenticating each other and exchanging
-	the keys and signatures securely.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>SEE ALSO</title>
-    <para>
-      <citerefentry>
-        <refentrytitle>dnssec-keygen</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>,
-      <citerefentry>
-        <refentrytitle>dnssec-signkey</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>,
-      <citetitle>BIND 9 Administrator Reference Manual</citetitle>,
-      <citetitle>RFC 2535</citetitle>.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>AUTHOR</title>
-    <para>
-        <corpauthor>Internet Systems Consortium</corpauthor>
-    </para>
-  </refsect1>
-
-</refentry>
-
-<!--
- - Local variables:
- - mode: sgml
- - End:
--->
diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.html b/contrib/bind9/bin/dnssec/dnssec-makekeyset.html
deleted file mode 100644
index 48f1d4a59e11..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-makekeyset.html
+++ /dev/null
@@ -1,407 +0,0 @@
-<!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- $Id: dnssec-makekeyset.html,v 1.4.2.2.4.1 2004/03/06 10:21:15 marka Exp $ -->
-
-<HTML
-><HEAD
-><TITLE
->dnssec-makekeyset</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-><SPAN
-CLASS="APPLICATION"
->dnssec-makekeyset</SPAN
-></A
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->dnssec-makekeyset</SPAN
->&nbsp;--&nbsp;DNSSEC zone signing tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->dnssec-makekeyset</B
->  [<TT
-CLASS="OPTION"
->-a</TT
->] [<TT
-CLASS="OPTION"
->-s <TT
-CLASS="REPLACEABLE"
-><I
->start-time</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-e <TT
-CLASS="REPLACEABLE"
-><I
->end-time</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-h</TT
->] [<TT
-CLASS="OPTION"
->-p</TT
->] [<TT
-CLASS="OPTION"
->-r <TT
-CLASS="REPLACEABLE"
-><I
->randomdev</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-t</TT
-><TT
-CLASS="REPLACEABLE"
-><I
->ttl</I
-></TT
->] [<TT
-CLASS="OPTION"
->-v <TT
-CLASS="REPLACEABLE"
-><I
->level</I
-></TT
-></TT
->] {key...}</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN38"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
-> generates a key set from one
-	or more keys created by <B
-CLASS="COMMAND"
->dnssec-keygen</B
->.  It creates
-	a file containing a KEY record for each key, and self-signs the key
-	set with each zone key.  The output file is of the form
-	<TT
-CLASS="FILENAME"
->keyset-nnnn.</TT
->, where <TT
-CLASS="FILENAME"
->nnnn</TT
->
-	is the zone name.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN45"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-a</DT
-><DD
-><P
->	      Verify all generated signatures.
-	  </P
-></DD
-><DT
->-s <TT
-CLASS="REPLACEABLE"
-><I
->start-time</I
-></TT
-></DT
-><DD
-><P
->	       Specify the date and time when the generated SIG records
-	       become valid.  This can be either an absolute or relative
-	       time.  An absolute start time is indicated by a number
-	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-	       14:45:00 UTC on May 30th, 2000.  A relative start time is
-	       indicated by +N, which is N seconds from the current time.
-	       If no <TT
-CLASS="OPTION"
->start-time</TT
-> is specified, the current
-	       time is used.
-	  </P
-></DD
-><DT
->-e <TT
-CLASS="REPLACEABLE"
-><I
->end-time</I
-></TT
-></DT
-><DD
-><P
->	       Specify the date and time when the generated SIG records
-	       expire.  As with <TT
-CLASS="OPTION"
->start-time</TT
->, an absolute
-	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-	       to the start time is indicated with +N, which is N seconds from
-	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <TT
-CLASS="OPTION"
->end-time</TT
-> is
-	       specified, 30 days from the start time is used as a default.
-	  </P
-></DD
-><DT
->-h</DT
-><DD
-><P
->	       Prints a short summary of the options and arguments to
-	       <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
->.
-	  </P
-></DD
-><DT
->-p</DT
-><DD
-><P
->	       Use pseudo-random data when signing the zone.  This is faster,
-	       but less secure, than using real random data.  This option
-	       may be useful when signing large zones or when the entropy
-	       source is limited.
-	  </P
-></DD
-><DT
->-r <TT
-CLASS="REPLACEABLE"
-><I
->randomdev</I
-></TT
-></DT
-><DD
-><P
->	       Specifies the source of randomness.  If the operating
-	       system does not provide a <TT
-CLASS="FILENAME"
->/dev/random</TT
->
-	       or equivalent device, the default source of randomness
-	       is keyboard input.  <TT
-CLASS="FILENAME"
->randomdev</TT
-> specifies
-	       the name of a character device or file containing random
-	       data to be used instead of the default.  The special value
-	       <TT
-CLASS="FILENAME"
->keyboard</TT
-> indicates that keyboard
-	       input should be used.
-	  </P
-></DD
-><DT
->-t <TT
-CLASS="REPLACEABLE"
-><I
->ttl</I
-></TT
-></DT
-><DD
-><P
->	       Specify the TTL (time to live) of the KEY and SIG records.
-	       The default is 3600 seconds.
-	  </P
-></DD
-><DT
->-v <TT
-CLASS="REPLACEABLE"
-><I
->level</I
-></TT
-></DT
-><DD
-><P
->	       Sets the debugging level.
-	  </P
-></DD
-><DT
->key</DT
-><DD
-><P
->	       The list of keys to be included in the keyset file.  These keys
-	       are expressed in the form <TT
-CLASS="FILENAME"
->Knnnn.+aaa+iiiii</TT
->
-	       as generated by <B
-CLASS="COMMAND"
->dnssec-keygen</B
->.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN98"
-></A
-><H2
->EXAMPLE</H2
-><P
->        The following command generates a keyset containing the DSA key for
-	<TT
-CLASS="USERINPUT"
-><B
->example.com</B
-></TT
-> generated in the
-	<B
-CLASS="COMMAND"
->dnssec-keygen</B
-> man page.
-    </P
-><P
->        <TT
-CLASS="USERINPUT"
-><B
->dnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160</B
-></TT
->
-    </P
-><P
->        In this example, <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
-> creates
-	the file <TT
-CLASS="FILENAME"
->keyset-example.com.</TT
->.  This file
-	contains the specified key and a self-generated signature.
-    </P
-><P
->        The DNS administrator for <TT
-CLASS="USERINPUT"
-><B
->example.com</B
-></TT
-> could
-	send <TT
-CLASS="FILENAME"
->keyset-example.com.</TT
-> to the DNS
-	administrator for <TT
-CLASS="USERINPUT"
-><B
->.com</B
-></TT
-> for signing, if the
-	.com zone is DNSSEC-aware and the administrators of the two zones
-	have some mechanism for authenticating each other and exchanging
-	the keys and signatures securely.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN112"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-signkey</SPAN
->(8)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->,
-      <I
-CLASS="CITETITLE"
->RFC 2535</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN123"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Software Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.8 b/contrib/bind9/bin/dnssec/dnssec-signkey.8
deleted file mode 100644
index ea2818bdfe21..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-signkey.8
+++ /dev/null
@@ -1,108 +0,0 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
-.\"
-.\" Permission to use, copy, modify, and distribute this software for any
-.\" purpose with or without fee is hereby granted, provided that the above
-.\" copyright notice and this permission notice appear in all copies.
-.\"
-.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-.\" PERFORMANCE OF THIS SOFTWARE.
-.\"
-.\" $Id: dnssec-signkey.8,v 1.18.2.1.4.1 2004/03/06 07:41:39 marka Exp $
-.\"
-.TH "DNSSEC-SIGNKEY" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
-dnssec-signkey \- DNSSEC key set signing tool
-.SH SYNOPSIS
-.sp
-\fBdnssec-signkey\fR [ \fB-a\fR ]  [ \fB-c \fIclass\fB\fR ]  [ \fB-s \fIstart-time\fB\fR ]  [ \fB-e \fIend-time\fB\fR ]  [ \fB-h\fR ]  [ \fB-p\fR ]  [ \fB-r \fIrandomdev\fB\fR ]  [ \fB-v \fIlevel\fB\fR ]  \fBkeyset\fR \fBkey\fR\fI...\fR
-.SH "DESCRIPTION"
-.PP
-\fBdnssec-signkey\fR signs a keyset. Typically
-the keyset will be for a child zone, and will have been generated
-by \fBdnssec-makekeyset\fR. The child zone's keyset
-is signed with the zone keys for its parent zone. The output file
-is of the form \fIsignedkey-nnnn.\fR, where
-\fInnnn\fR is the zone name.
-.SH "OPTIONS"
-.TP
-\fB-a\fR
-Verify all generated signatures.
-.TP
-\fB-c \fIclass\fB\fR
-Specifies the DNS class of the key sets.
-.TP
-\fB-s \fIstart-time\fB\fR
-Specify the date and time when the generated SIG records
-become valid. This can be either an absolute or relative
-time. An absolute start time is indicated by a number
-in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-14:45:00 UTC on May 30th, 2000. A relative start time is
-indicated by +N, which is N seconds from the current time.
-If no \fBstart-time\fR is specified, the current
-time is used.
-.TP
-\fB-e \fIend-time\fB\fR
-Specify the date and time when the generated SIG records
-expire. As with \fBstart-time\fR, an absolute
-time is indicated in YYYYMMDDHHMMSS notation. A time relative
-to the start time is indicated with +N, which is N seconds from
-the start time. A time relative to the current time is
-indicated with now+N. If no \fBend-time\fR is
-specified, 30 days from the start time is used as a default.
-.TP
-\fB-h\fR
-Prints a short summary of the options and arguments to
-\fBdnssec-signkey\fR.
-.TP
-\fB-p\fR
-Use pseudo-random data when signing the zone. This is faster,
-but less secure, than using real random data. This option
-may be useful when signing large zones or when the entropy
-source is limited.
-.TP
-\fB-r \fIrandomdev\fB\fR
-Specifies the source of randomness. If the operating
-system does not provide a \fI/dev/random\fR
-or equivalent device, the default source of randomness
-is keyboard input. \fIrandomdev\fR specifies
-the name of a character device or file containing random
-data to be used instead of the default. The special value
-\fIkeyboard\fR indicates that keyboard
-input should be used.
-.TP
-\fB-v \fIlevel\fB\fR
-Sets the debugging level.
-.TP
-\fBkeyset\fR
-The file containing the child's keyset.
-.TP
-\fBkey\fR
-The keys used to sign the child's keyset.
-.SH "EXAMPLE"
-.PP
-The DNS administrator for a DNSSEC-aware \fB.com\fR
-zone would use the following command to sign the
-\fIkeyset\fR file for \fBexample.com\fR
-created by \fBdnssec-makekeyset\fR with a key generated
-by \fBdnssec-keygen\fR:
-.PP
-\fBdnssec-signkey keyset-example.com. Kcom.+003+51944\fR
-.PP
-In this example, \fBdnssec-signkey\fR creates
-the file \fIsignedkey-example.com.\fR, which
-contains the \fBexample.com\fR keys and the
-signatures by the \fB.com\fR keys.
-.SH "SEE ALSO"
-.PP
-\fBdnssec-keygen\fR(8),
-\fBdnssec-makekeyset\fR(8),
-\fBdnssec-signzone\fR(8).
-.SH "AUTHOR"
-.PP
-Internet Software Consortium
diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.c b/contrib/bind9/bin/dnssec/dnssec-signkey.c
deleted file mode 100644
index fd8b0fd322b5..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-signkey.c
+++ /dev/null
@@ -1,448 +0,0 @@
-/*
- * Portions Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (C) 2000-2003  Internet Software Consortium.
- * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
- *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC AND NETWORK ASSOCIATES DISCLAIMS
- * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE
- * FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
- * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-/* $Id: dnssec-signkey.c,v 1.50.2.2.2.7 2004/08/28 06:25:28 marka Exp $ */
-
-#include <config.h>
-
-#include <stdlib.h>
-
-#include <isc/string.h>
-#include <isc/commandline.h>
-#include <isc/entropy.h>
-#include <isc/mem.h>
-#include <isc/print.h>
-#include <isc/util.h>
-
-#include <dns/db.h>
-#include <dns/dbiterator.h>
-#include <dns/diff.h>
-#include <dns/dnssec.h>
-#include <dns/fixedname.h>
-#include <dns/log.h>
-#include <dns/rdata.h>
-#include <dns/rdataclass.h>
-#include <dns/rdataset.h>
-#include <dns/rdatasetiter.h>
-#include <dns/rdatastruct.h>
-#include <dns/result.h>
-#include <dns/secalg.h>
-
-#include <dst/dst.h>
-
-#include "dnssectool.h"
-
-const char *program = "dnssec-signkey";
-int verbose;
-
-typedef struct keynode keynode_t;
-struct keynode {
-	dst_key_t *key;
-	isc_boolean_t verified;
-	ISC_LINK(keynode_t) link;
-};
-typedef ISC_LIST(keynode_t) keylist_t;
-
-static isc_stdtime_t starttime = 0, endtime = 0, now;
-
-static isc_mem_t *mctx = NULL;
-static isc_entropy_t *ectx = NULL;
-static keylist_t keylist;
-
-static void
-usage(void) {
-	fprintf(stderr, "Usage:\n");
-	fprintf(stderr, "\t%s [options] keyset keys\n", program);
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "Version: %s\n", VERSION);
-
-	fprintf(stderr, "Options: (default value in parenthesis) \n");
-	fprintf(stderr, "\t-a\n");
-	fprintf(stderr, "\t\tverify generated signatures\n");
-	fprintf(stderr, "\t-c class (IN)\n");
-	fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n");
-	fprintf(stderr, "\t\tSIG start time - absolute|offset (from keyset)\n");
-	fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n");
-	fprintf(stderr, "\t\tSIG end time  - absolute|from start|from now "
-		"(from keyset)\n");
-	fprintf(stderr, "\t-v level:\n");
-	fprintf(stderr, "\t\tverbose level (0)\n");
-	fprintf(stderr, "\t-p\n");
-	fprintf(stderr, "\t\tuse pseudorandom data (faster but less secure)\n");
-	fprintf(stderr, "\t-r randomdev:\n");
-	fprintf(stderr, "\t\ta file containing random data\n");
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "keyset:\n");
-	fprintf(stderr, "\tfile with keyset to be signed (keyset-<name>)\n");
-	fprintf(stderr, "keys:\n");
-	fprintf(stderr, "\tkeyfile (Kname+alg+tag)\n");
-
-	fprintf(stderr, "\n");
-	fprintf(stderr, "Output:\n");
-	fprintf(stderr, "\tsigned keyset (signedkey-<name>)\n");
-	exit(0);
-}
-
-static void
-loadkeys(dns_name_t *name, dns_rdataset_t *rdataset) {
-	dst_key_t *key;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
-	keynode_t *keynode;
-	isc_result_t result;
-
-	ISC_LIST_INIT(keylist);
-	result = dns_rdataset_first(rdataset);
-	check_result(result, "dns_rdataset_first");
-	for (; result == ISC_R_SUCCESS; result = dns_rdataset_next(rdataset)) {
-		dns_rdata_reset(&rdata);
-		dns_rdataset_current(rdataset, &rdata);
-		key = NULL;
-		result = dns_dnssec_keyfromrdata(name, &rdata, mctx, &key);
-		if (result != ISC_R_SUCCESS)
-			continue;
-		if (!dst_key_iszonekey(key)) {
-			dst_key_free(&key);
-			continue;
-		}
-		keynode = isc_mem_get(mctx, sizeof(keynode_t));
-		if (keynode == NULL)
-			fatal("out of memory");
-		keynode->key = key;
-		keynode->verified = ISC_FALSE;
-		ISC_LIST_INITANDAPPEND(keylist, keynode, link);
-	}
-	if (result != ISC_R_NOMORE)
-		fatal("failure traversing key list");
-}
-
-static dst_key_t *
-findkey(dns_rdata_rrsig_t *sig) {
-	keynode_t *keynode;
-	for (keynode = ISC_LIST_HEAD(keylist);
-	     keynode != NULL;
-	     keynode = ISC_LIST_NEXT(keynode, link))
-	{
-		if (dst_key_id(keynode->key) == sig->keyid &&
-		    dst_key_alg(keynode->key) == sig->algorithm) {
-			keynode->verified = ISC_TRUE;
-			return (keynode->key);
-		}
-	}
-	fatal("signature generated by non-zone or missing key");
-	return (NULL);
-}
-
-int
-main(int argc, char *argv[]) {
-	int i, ch;
-	char *startstr = NULL, *endstr = NULL, *classname = NULL;
-	char tdomain[1025];
-	dns_fixedname_t fdomain;
-	dns_name_t *domain;
-	char *output = NULL;
-	char *endp;
-	unsigned char data[65536];
-	dns_db_t *db;
-	dns_dbnode_t *node;
-	dns_dbversion_t *version;
-	dns_diff_t diff;
-	dns_difftuple_t *tuple;
-	dns_dbiterator_t *dbiter;
-	dns_rdatasetiter_t *rdsiter;
-	dst_key_t *key = NULL;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
-	dns_rdata_t sigrdata = DNS_RDATA_INIT;
-	dns_rdataset_t rdataset, sigrdataset;
-	dns_rdata_rrsig_t sig;
-	isc_result_t result;
-	isc_buffer_t b;
-	isc_log_t *log = NULL;
-	keynode_t *keynode;
-	isc_boolean_t pseudorandom = ISC_FALSE;
-	unsigned int eflags;
-	dns_rdataclass_t rdclass;
-	isc_boolean_t tryverify = ISC_FALSE;
-	isc_boolean_t settime = ISC_FALSE;
-
-	result = isc_mem_create(0, 0, &mctx);
-	check_result(result, "isc_mem_create()");
-
-	dns_result_register();
-
-	while ((ch = isc_commandline_parse(argc, argv, "ac:s:e:pr:v:h")) != -1)
-	{
-		switch (ch) {
-		case 'a':
-			tryverify = ISC_TRUE;
-			break;
-		case 'c':
-			classname = isc_commandline_argument;
-			break;
-
-		case 's':
-			startstr = isc_commandline_argument;
-			break;
-						
-		case 'e':
-			endstr = isc_commandline_argument;
-			break;
-
-		case 'p':
-			pseudorandom = ISC_TRUE;
-			break;
-
-		case 'r':
-			setup_entropy(mctx, isc_commandline_argument, &ectx);
-			break;
-
-		case 'v':
-			endp = NULL;
-			verbose = strtol(isc_commandline_argument, &endp, 0);
-			if (*endp != '\0')
-				fatal("verbose level must be numeric");
-			break;
-
-		case 'h':
-		default:
-			usage();
-
-		}
-	}
-
-	argc -= isc_commandline_index;
-	argv += isc_commandline_index;
-
-	if (argc < 2)
-		usage();
-
-	rdclass = strtoclass(classname);
-
-	if (ectx == NULL)
-		setup_entropy(mctx, NULL, &ectx);
-	eflags = ISC_ENTROPY_BLOCKING;
-	if (!pseudorandom)
-		eflags |= ISC_ENTROPY_GOODONLY;
-	result = dst_lib_init(mctx, ectx, eflags);
-	if (result != ISC_R_SUCCESS)
-		fatal("could not initialize dst: %s", 
-		      isc_result_totext(result));
-
-	isc_stdtime_get(&now);
-
-	if ((startstr == NULL || endstr == NULL) &&
-	    !(startstr == NULL && endstr == NULL))
-		fatal("if -s or -e is specified, both must be");
-
-	if (startstr != NULL) {
-		starttime = strtotime(startstr, now, now);
-		endtime = strtotime(endstr, now, starttime);
-		settime = ISC_TRUE;
-	}
-
-	setup_logging(verbose, mctx, &log);
-
-	if (strlen(argv[0]) < 8U || strncmp(argv[0], "keyset-", 7) != 0)
-		fatal("keyset file '%s' must start with keyset-", argv[0]);
-
-	db = NULL;
-	result = dns_db_create(mctx, "rbt", dns_rootname, dns_dbtype_zone,
-			       rdclass, 0, NULL, &db);
-	check_result(result, "dns_db_create()");
-
-	result = dns_db_load(db, argv[0]);
-	if (result != ISC_R_SUCCESS && result != DNS_R_SEENINCLUDE)
-		fatal("failed to load database from '%s': %s", argv[0],
-		      isc_result_totext(result));
-
-	dns_fixedname_init(&fdomain);
-	domain = dns_fixedname_name(&fdomain);
-
-	dbiter = NULL;
-	result = dns_db_createiterator(db, ISC_FALSE, &dbiter);
-	check_result(result, "dns_db_createiterator()");
-
-	result = dns_dbiterator_first(dbiter);
-	check_result(result, "dns_dbiterator_first()");
-	while (result == ISC_R_SUCCESS) {
-		node = NULL;
-		dns_dbiterator_current(dbiter, &node, domain);
-		rdsiter = NULL;
-		result = dns_db_allrdatasets(db, node, NULL, 0, &rdsiter);
-		check_result(result, "dns_db_allrdatasets()");
-		result = dns_rdatasetiter_first(rdsiter);
-		dns_rdatasetiter_destroy(&rdsiter);
-		if (result == ISC_R_SUCCESS)
-			break;
-		dns_db_detachnode(db, &node);
-		result = dns_dbiterator_next(dbiter);
-	}
-	dns_dbiterator_destroy(&dbiter);
-	if (result != ISC_R_SUCCESS)
-		fatal("failed to find data in keyset file");
-
-	isc_buffer_init(&b, tdomain, sizeof(tdomain) - 1);
-	result = dns_name_tofilenametext(domain, ISC_FALSE, &b);
-	check_result(result, "dns_name_tofilenametext()");
-	isc_buffer_putuint8(&b, 0);
-
-	output = isc_mem_allocate(mctx,
-				  strlen("signedkey-") + strlen(tdomain) + 1);
-	if (output == NULL)
-		fatal("out of memory");
-	sprintf(output, "signedkey-%s", tdomain);
-
-	version = NULL;
-	dns_db_newversion(db, &version);
-
-	dns_rdataset_init(&rdataset);
-	dns_rdataset_init(&sigrdataset);
-	result = dns_db_findrdataset(db, node, version, dns_rdatatype_dnskey, 0,
-				     0, &rdataset, &sigrdataset);
-	if (result != ISC_R_SUCCESS) {
-		char domainstr[DNS_NAME_FORMATSIZE];
-		dns_name_format(domain, domainstr, sizeof(domainstr));
-		fatal("failed to find rdataset '%s KEY': %s",
-		      domainstr, isc_result_totext(result));
-	}
-
-	loadkeys(domain, &rdataset);
-
-	dns_diff_init(mctx, &diff);
-
-	if (!dns_rdataset_isassociated(&sigrdataset))
-		fatal("no SIG KEY set present");
-
-	result = dns_rdataset_first(&sigrdataset);
-	check_result(result, "dns_rdataset_first()");
-	do {
-		dns_rdataset_current(&sigrdataset, &sigrdata);
-		result = dns_rdata_tostruct(&sigrdata, &sig, mctx);
-		check_result(result, "dns_rdata_tostruct()");
-		key = findkey(&sig);
-		result = dns_dnssec_verify(domain, &rdataset, key,
-					   ISC_TRUE, mctx, &sigrdata);
-		if (result != ISC_R_SUCCESS) {
-			char keystr[KEY_FORMATSIZE];
-			key_format(key, keystr, sizeof(keystr));
-			fatal("signature by key '%s' did not verify: %s",
-			      keystr, isc_result_totext(result));
-		}
-		if (!settime) {
-			starttime = sig.timesigned;
-			endtime = sig.timeexpire;
-			settime = ISC_TRUE;
-		}
-		dns_rdata_freestruct(&sig);
-		dns_rdata_reset(&sigrdata);
-		result = dns_rdataset_next(&sigrdataset);
-	} while (result == ISC_R_SUCCESS);
-
-	for (keynode = ISC_LIST_HEAD(keylist);
-	     keynode != NULL;
-	     keynode = ISC_LIST_NEXT(keynode, link))
-		if (!keynode->verified)
-			fatal("not all zone keys self signed the key set");
-
-	argc -= 1;
-	argv += 1;
-
-	for (i = 0; i < argc; i++) {
-		key = NULL;
-		result = dst_key_fromnamedfile(argv[i],
-					       DST_TYPE_PUBLIC |
-					       DST_TYPE_PRIVATE,
-					       mctx, &key);
-		if (result != ISC_R_SUCCESS)
-			fatal("failed to read key %s from disk: %s",
-			      argv[i], isc_result_totext(result));
-
-		dns_rdata_reset(&rdata);
-		isc_buffer_init(&b, data, sizeof(data));
-		result = dns_dnssec_sign(domain, &rdataset, key,
-					 &starttime, &endtime,
-					 mctx, &b, &rdata);
-		isc_entropy_stopcallbacksources(ectx);
-		if (result != ISC_R_SUCCESS) {
-			char keystr[KEY_FORMATSIZE];
-			key_format(key, keystr, sizeof(keystr));
-			fatal("key '%s' failed to sign data: %s",
-			      keystr, isc_result_totext(result));
-		}
-		if (tryverify) {
-			result = dns_dnssec_verify(domain, &rdataset, key,
-						   ISC_TRUE, mctx, &rdata);
-			if (result != ISC_R_SUCCESS) {
-				char keystr[KEY_FORMATSIZE];
-				key_format(key, keystr, sizeof(keystr));
-				fatal("signature from key '%s' failed to "
-				      "verify: %s",
-				      keystr, isc_result_totext(result));
-			}
-		}
-		tuple = NULL;
-		result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD,
-					      domain, rdataset.ttl,
-					      &rdata, &tuple);
-		check_result(result, "dns_difftuple_create");
-		dns_diff_append(&diff, &tuple);
-		dst_key_free(&key);
-	}
-
-	result = dns_db_deleterdataset(db, node, version, dns_rdatatype_rrsig,
-				       dns_rdatatype_dnskey);
-	check_result(result, "dns_db_deleterdataset");
-
-	result = dns_diff_apply(&diff, db, version);
-	check_result(result, "dns_diff_apply");
-	dns_diff_clear(&diff);
-
-	dns_db_detachnode(db, &node);
-	dns_db_closeversion(db, &version, ISC_TRUE);
-	result = dns_db_dump(db, version, output);
-	if (result != ISC_R_SUCCESS)
-		fatal("failed to write database to '%s': %s",
-		      output, isc_result_totext(result));
-
-	printf("%s\n", output);
-
-	dns_rdataset_disassociate(&rdataset);
-	dns_rdataset_disassociate(&sigrdataset);
-
-	dns_db_detach(&db);
-
-	while (!ISC_LIST_EMPTY(keylist)) {
-		keynode = ISC_LIST_HEAD(keylist);
-		ISC_LIST_UNLINK(keylist, keynode, link);
-		dst_key_free(&keynode->key);
-		isc_mem_put(mctx, keynode, sizeof(keynode_t));
-	}
-
-	cleanup_logging(&log);
-
-	isc_mem_free(mctx, output);
-	cleanup_entropy(&ectx);
-	dst_lib_destroy();
-	if (verbose > 10)
-		isc_mem_stats(mctx, stdout);
-	isc_mem_destroy(&mctx);
-	return (0);
-}
diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.docbook b/contrib/bind9/bin/dnssec/dnssec-signkey.docbook
deleted file mode 100644
index 8258a3da7102..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-signkey.docbook
+++ /dev/null
@@ -1,237 +0,0 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
-<!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- $Id: dnssec-signkey.docbook,v 1.2.2.2.4.2 2004/06/03 02:24:55 marka Exp $ -->
-
-<refentry>
-  <refentryinfo>
-    <date>June 30, 2000</date>
-  </refentryinfo>
-
-  <refmeta>
-    <refentrytitle><application>dnssec-signkey</application></refentrytitle>
-    <manvolnum>8</manvolnum>
-    <refmiscinfo>BIND9</refmiscinfo>
-  </refmeta>
-
-  <refnamediv>
-    <refname><application>dnssec-signkey</application></refname>
-    <refpurpose>DNSSEC key set signing tool</refpurpose>
-  </refnamediv>
-
-  <refsynopsisdiv>
-    <cmdsynopsis>
-      <command>dnssec-signkey</command>
-      <arg><option>-a</option></arg>
-      <arg><option>-c <replaceable class="parameter">class</replaceable></option></arg>
-      <arg><option>-s <replaceable class="parameter">start-time</replaceable></option></arg>
-      <arg><option>-e <replaceable class="parameter">end-time</replaceable></option></arg>
-      <arg><option>-h</option></arg>
-      <arg><option>-p</option></arg>
-      <arg><option>-r <replaceable class="parameter">randomdev</replaceable></option></arg>
-      <arg><option>-v <replaceable class="parameter">level</replaceable></option></arg>
-      <arg choice="req">keyset</arg>
-      <arg choice="req" rep="repeat">key</arg>
-    </cmdsynopsis>
-  </refsynopsisdiv>
-
-  <refsect1>
-    <title>DESCRIPTION</title>
-    <para>
-        <command>dnssec-signkey</command> signs a keyset.  Typically
-	the keyset will be for a child zone, and will have been generated
-	by <command>dnssec-makekeyset</command>.  The child zone's keyset
-	is signed with the zone keys for its parent zone.  The output file
-	is of the form <filename>signedkey-nnnn.</filename>, where
-	<filename>nnnn</filename> is the zone name.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>OPTIONS</title>
-
-    <variablelist>
-      <varlistentry>
-        <term>-a</term>
-	<listitem>
-	  <para>
-	      Verify all generated signatures.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-c <replaceable class="parameter">class</replaceable></term>
-	<listitem>
-	  <para>
-	       Specifies the DNS class of the key sets.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-s <replaceable class="parameter">start-time</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the date and time when the generated SIG records
-	       become valid.  This can be either an absolute or relative
-	       time.  An absolute start time is indicated by a number
-	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-	       14:45:00 UTC on May 30th, 2000.  A relative start time is
-	       indicated by +N, which is N seconds from the current time.
-	       If no <option>start-time</option> is specified, the current
-	       time is used.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-e <replaceable class="parameter">end-time</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the date and time when the generated SIG records
-	       expire.  As with <option>start-time</option>, an absolute
-	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-	       to the start time is indicated with +N, which is N seconds from
-	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <option>end-time</option> is
-	       specified, 30 days from the start time is used as a default.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-h</term>
-	<listitem>
-	  <para>
-	       Prints a short summary of the options and arguments to
-	       <command>dnssec-signkey</command>.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-p</term>
-	<listitem>
-	  <para>
-	       Use pseudo-random data when signing the zone.  This is faster,
-	       but less secure, than using real random data.  This option
-	       may be useful when signing large zones or when the entropy
-	       source is limited.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-r <replaceable class="parameter">randomdev</replaceable></term>
-	<listitem>
-	  <para>
-	       Specifies the source of randomness.  If the operating
-	       system does not provide a <filename>/dev/random</filename>
-	       or equivalent device, the default source of randomness
-	       is keyboard input.  <filename>randomdev</filename> specifies
-	       the name of a character device or file containing random
-	       data to be used instead of the default.  The special value
-	       <filename>keyboard</filename> indicates that keyboard
-	       input should be used.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-v <replaceable class="parameter">level</replaceable></term>
-	<listitem>
-	  <para>
-	       Sets the debugging level.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>keyset</term>
-	  <listitem>
-	    <para>
-	        The file containing the child's keyset.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>key</term>
-	  <listitem>
-	    <para>
-	        The keys used to sign the child's keyset.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-    </variablelist>
-  </refsect1>
-
-  <refsect1>
-    <title>EXAMPLE</title>
-    <para>
-        The DNS administrator for a DNSSEC-aware <userinput>.com</userinput>
-	zone would use the following command to sign the
-	<filename>keyset</filename> file for <userinput>example.com</userinput>
-	created by <command>dnssec-makekeyset</command> with a key generated
-	by <command>dnssec-keygen</command>:
-    </para>
-    <para>
-        <userinput>dnssec-signkey keyset-example.com. Kcom.+003+51944</userinput>
-    </para>
-    <para>
-        In this example, <command>dnssec-signkey</command> creates
-	the file <filename>signedkey-example.com.</filename>, which
-	contains the <userinput>example.com</userinput> keys and the
-	signatures by the <userinput>.com</userinput> keys.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>SEE ALSO</title>
-    <para>
-      <citerefentry>
-        <refentrytitle>dnssec-keygen</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>,
-      <citerefentry>
-        <refentrytitle>dnssec-makekeyset</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>,
-      <citerefentry>
-        <refentrytitle>dnssec-signzone</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>AUTHOR</title>
-    <para>
-        <corpauthor>Internet Systems Consortium</corpauthor>
-    </para>
-  </refsect1>
-
-</refentry>
-
-<!--
- - Local variables:
- - mode: sgml
- - End:
--->
diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.html b/contrib/bind9/bin/dnssec/dnssec-signkey.html
deleted file mode 100644
index 8cbf1fc736a3..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-signkey.html
+++ /dev/null
@@ -1,407 +0,0 @@
-<!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- $Id: dnssec-signkey.html,v 1.4.2.1.4.1 2004/03/06 10:21:15 marka Exp $ -->
-
-<HTML
-><HEAD
-><TITLE
->dnssec-signkey</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-><SPAN
-CLASS="APPLICATION"
->dnssec-signkey</SPAN
-></A
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->dnssec-signkey</SPAN
->&nbsp;--&nbsp;DNSSEC key set signing tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->dnssec-signkey</B
->  [<TT
-CLASS="OPTION"
->-a</TT
->] [<TT
-CLASS="OPTION"
->-c <TT
-CLASS="REPLACEABLE"
-><I
->class</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-s <TT
-CLASS="REPLACEABLE"
-><I
->start-time</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-e <TT
-CLASS="REPLACEABLE"
-><I
->end-time</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-h</TT
->] [<TT
-CLASS="OPTION"
->-p</TT
->] [<TT
-CLASS="OPTION"
->-r <TT
-CLASS="REPLACEABLE"
-><I
->randomdev</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-v <TT
-CLASS="REPLACEABLE"
-><I
->level</I
-></TT
-></TT
->] {keyset} {key...}</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN39"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->dnssec-signkey</B
-> signs a keyset.  Typically
-	the keyset will be for a child zone, and will have been generated
-	by <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
->.  The child zone's keyset
-	is signed with the zone keys for its parent zone.  The output file
-	is of the form <TT
-CLASS="FILENAME"
->signedkey-nnnn.</TT
->, where
-	<TT
-CLASS="FILENAME"
->nnnn</TT
-> is the zone name.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN46"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-a</DT
-><DD
-><P
->	      Verify all generated signatures.
-	  </P
-></DD
-><DT
->-c <TT
-CLASS="REPLACEABLE"
-><I
->class</I
-></TT
-></DT
-><DD
-><P
->	       Specifies the DNS class of the key sets.
-	  </P
-></DD
-><DT
->-s <TT
-CLASS="REPLACEABLE"
-><I
->start-time</I
-></TT
-></DT
-><DD
-><P
->	       Specify the date and time when the generated SIG records
-	       become valid.  This can be either an absolute or relative
-	       time.  An absolute start time is indicated by a number
-	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-	       14:45:00 UTC on May 30th, 2000.  A relative start time is
-	       indicated by +N, which is N seconds from the current time.
-	       If no <TT
-CLASS="OPTION"
->start-time</TT
-> is specified, the current
-	       time is used.
-	  </P
-></DD
-><DT
->-e <TT
-CLASS="REPLACEABLE"
-><I
->end-time</I
-></TT
-></DT
-><DD
-><P
->	       Specify the date and time when the generated SIG records
-	       expire.  As with <TT
-CLASS="OPTION"
->start-time</TT
->, an absolute
-	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-	       to the start time is indicated with +N, which is N seconds from
-	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <TT
-CLASS="OPTION"
->end-time</TT
-> is
-	       specified, 30 days from the start time is used as a default.
-	  </P
-></DD
-><DT
->-h</DT
-><DD
-><P
->	       Prints a short summary of the options and arguments to
-	       <B
-CLASS="COMMAND"
->dnssec-signkey</B
->.
-	  </P
-></DD
-><DT
->-p</DT
-><DD
-><P
->	       Use pseudo-random data when signing the zone.  This is faster,
-	       but less secure, than using real random data.  This option
-	       may be useful when signing large zones or when the entropy
-	       source is limited.
-	  </P
-></DD
-><DT
->-r <TT
-CLASS="REPLACEABLE"
-><I
->randomdev</I
-></TT
-></DT
-><DD
-><P
->	       Specifies the source of randomness.  If the operating
-	       system does not provide a <TT
-CLASS="FILENAME"
->/dev/random</TT
->
-	       or equivalent device, the default source of randomness
-	       is keyboard input.  <TT
-CLASS="FILENAME"
->randomdev</TT
-> specifies
-	       the name of a character device or file containing random
-	       data to be used instead of the default.  The special value
-	       <TT
-CLASS="FILENAME"
->keyboard</TT
-> indicates that keyboard
-	       input should be used.
-	  </P
-></DD
-><DT
->-v <TT
-CLASS="REPLACEABLE"
-><I
->level</I
-></TT
-></DT
-><DD
-><P
->	       Sets the debugging level.
-	  </P
-></DD
-><DT
->keyset</DT
-><DD
-><P
->	        The file containing the child's keyset.
-	  </P
-></DD
-><DT
->key</DT
-><DD
-><P
->	        The keys used to sign the child's keyset.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN101"
-></A
-><H2
->EXAMPLE</H2
-><P
->        The DNS administrator for a DNSSEC-aware <TT
-CLASS="USERINPUT"
-><B
->.com</B
-></TT
->
-	zone would use the following command to sign the
-	<TT
-CLASS="FILENAME"
->keyset</TT
-> file for <TT
-CLASS="USERINPUT"
-><B
->example.com</B
-></TT
->
-	created by <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
-> with a key generated
-	by <B
-CLASS="COMMAND"
->dnssec-keygen</B
->:
-    </P
-><P
->        <TT
-CLASS="USERINPUT"
-><B
->dnssec-signkey keyset-example.com. Kcom.+003+51944</B
-></TT
->
-    </P
-><P
->        In this example, <B
-CLASS="COMMAND"
->dnssec-signkey</B
-> creates
-	the file <TT
-CLASS="FILENAME"
->signedkey-example.com.</TT
->, which
-	contains the <TT
-CLASS="USERINPUT"
-><B
->example.com</B
-></TT
-> keys and the
-	signatures by the <TT
-CLASS="USERINPUT"
-><B
->.com</B
-></TT
-> keys.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN116"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-makekeyset</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-signzone</SPAN
->(8)</SPAN
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN128"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Software Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.8 b/contrib/bind9/bin/dnssec/dnssec-signzone.8
index a1795b8001a2..63ffadba644f 100644
--- a/contrib/bind9/bin/dnssec/dnssec-signzone.8
+++ b/contrib/bind9/bin/dnssec/dnssec-signzone.8
@@ -1,167 +1,157 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000-2003  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000-2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: dnssec-signzone.8,v 1.23.2.1.4.6 2004/06/11 02:32:46 marka Exp $
+.\" $Id: dnssec-signzone.8,v 1.23.2.1.4.10 2005/10/13 02:33:45 marka Exp $
 .\"
-.TH "DNSSEC-SIGNZONE" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
-dnssec-signzone \- DNSSEC zone signing tool
-.SH SYNOPSIS
-.sp
-\fBdnssec-signzone\fR [ \fB-a\fR ]  [ \fB-c \fIclass\fB\fR ]  [ \fB-d \fIdirectory\fB\fR ]  [ \fB-e \fIend-time\fB\fR ]  [ \fB-f \fIoutput-file\fB\fR ]  [ \fB-g\fR ]  [ \fB-h\fR ]  [ \fB-k \fIkey\fB\fR ]  [ \fB-l \fIdomain\fB\fR ]  [ \fB-i \fIinterval\fB\fR ]  [ \fB-n \fInthreads\fB\fR ]  [ \fB-o \fIorigin\fB\fR ]  [ \fB-p\fR ]  [ \fB-r \fIrandomdev\fB\fR ]  [ \fB-s \fIstart-time\fB\fR ]  [ \fB-t\fR ]  [ \fB-v \fIlevel\fB\fR ]  [ \fB-z\fR ]  \fBzonefile\fR [ \fBkey\fR\fI...\fR ] 
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "DNSSEC\-SIGNZONE" "8" "June 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+dnssec\-signzone \- DNSSEC zone signing tool
+.SH "SYNOPSIS"
+.HP 16
+\fBdnssec\-signzone\fR [\fB\-a\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-d\ \fR\fB\fIdirectory\fR\fR] [\fB\-e\ \fR\fB\fIend\-time\fR\fR] [\fB\-f\ \fR\fB\fIoutput\-file\fR\fR] [\fB\-g\fR] [\fB\-h\fR] [\fB\-k\ \fR\fB\fIkey\fR\fR] [\fB\-l\ \fR\fB\fIdomain\fR\fR] [\fB\-i\ \fR\fB\fIinterval\fR\fR] [\fB\-n\ \fR\fB\fInthreads\fR\fR] [\fB\-o\ \fR\fB\fIorigin\fR\fR] [\fB\-p\fR] [\fB\-r\ \fR\fB\fIrandomdev\fR\fR] [\fB\-s\ \fR\fB\fIstart\-time\fR\fR] [\fB\-t\fR] [\fB\-v\ \fR\fB\fIlevel\fR\fR] [\fB\-z\fR] {zonefile} [key...]
 .SH "DESCRIPTION"
 .PP
-\fBdnssec-signzone\fR signs a zone. It generates
-NSEC and RRSIG records and produces a signed version of the
-zone. The security status of delegations from the signed zone
-(that is, whether the child zones are secure or not) is
-determined by the presence or absence of a
-\fIkeyset\fR file for each child zone.
+\fBdnssec\-signzone\fR
+signs a zone. It generates NSEC and RRSIG records and produces a signed version of the zone. The security status of delegations from the signed zone (that is, whether the child zones are secure or not) is determined by the presence or absence of a
+\fIkeyset\fR
+file for each child zone.
 .SH "OPTIONS"
 .TP
-\fB-a\fR
+\-a
 Verify all generated signatures.
 .TP
-\fB-c \fIclass\fB\fR
+\-c \fIclass\fR
 Specifies the DNS class of the zone.
 .TP
-\fB-k \fIkey\fB\fR
-Treat specified key as a key signing key ignoring any
-key flags. This option may be specified multiple times.
-.TP
-\fB-l \fIdomain\fB\fR
-Generate a DLV set in addition to the key (DNSKEY) and DS sets.
-The domain is appended to the name of the records.
-.TP
-\fB-d \fIdirectory\fB\fR
-Look for \fIkeyset\fR files in
-\fBdirectory\fR as the directory 
-.TP
-\fB-g\fR
-Generate DS records for child zones from keyset files.
-Existing DS records will be removed.
-.TP
-\fB-s \fIstart-time\fB\fR
-Specify the date and time when the generated RRSIG records
-become valid. This can be either an absolute or relative
-time. An absolute start time is indicated by a number
-in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-14:45:00 UTC on May 30th, 2000. A relative start time is
-indicated by +N, which is N seconds from the current time.
-If no \fBstart-time\fR is specified, the current
-time minus 1 hour (to allow for clock skew) is used.
-.TP
-\fB-e \fIend-time\fB\fR
-Specify the date and time when the generated RRSIG records
-expire. As with \fBstart-time\fR, an absolute
-time is indicated in YYYYMMDDHHMMSS notation. A time relative
-to the start time is indicated with +N, which is N seconds from
-the start time. A time relative to the current time is
-indicated with now+N. If no \fBend-time\fR is
-specified, 30 days from the start time is used as a default.
-.TP
-\fB-f \fIoutput-file\fB\fR
-The name of the output file containing the signed zone. The
-default is to append \fI.signed\fR to the
-input file.
-.TP
-\fB-h\fR
+\-k \fIkey\fR
+Treat specified key as a key signing key ignoring any key flags. This option may be specified multiple times.
+.TP
+\-l \fIdomain\fR
+Generate a DLV set in addition to the key (DNSKEY) and DS sets. The domain is appended to the name of the records.
+.TP
+\-d \fIdirectory\fR
+Look for
+\fIkeyset\fR
+files in
+\fBdirectory\fR
+as the directory
+.TP
+\-g
+Generate DS records for child zones from keyset files. Existing DS records will be removed.
+.TP
+\-s \fIstart\-time\fR
+Specify the date and time when the generated RRSIG records become valid. This can be either an absolute or relative time. An absolute start time is indicated by a number in YYYYMMDDHHMMSS notation; 20000530144500 denotes 14:45:00 UTC on May 30th, 2000. A relative start time is indicated by +N, which is N seconds from the current time. If no
+\fBstart\-time\fR
+is specified, the current time minus 1 hour (to allow for clock skew) is used.
+.TP
+\-e \fIend\-time\fR
+Specify the date and time when the generated RRSIG records expire. As with
+\fBstart\-time\fR, an absolute time is indicated in YYYYMMDDHHMMSS notation. A time relative to the start time is indicated with +N, which is N seconds from the start time. A time relative to the current time is indicated with now+N. If no
+\fBend\-time\fR
+is specified, 30 days from the start time is used as a default.
+.TP
+\-f \fIoutput\-file\fR
+The name of the output file containing the signed zone. The default is to append
+\fI.signed\fR
+to the input file.
+.TP
+\-h
 Prints a short summary of the options and arguments to
-\fBdnssec-signzone\fR.
-.TP
-\fB-i \fIinterval\fB\fR
-When a previously signed zone is passed as input, records
-may be resigned. The \fBinterval\fR option
-specifies the cycle interval as an offset from the current
-time (in seconds). If a RRSIG record expires after the
-cycle interval, it is retained. Otherwise, it is considered
-to be expiring soon, and it will be replaced.
-
-The default cycle interval is one quarter of the difference
-between the signature end and start times. So if neither
-\fBend-time\fR or \fBstart-time\fR
-are specified, \fBdnssec-signzone\fR generates
-signatures that are valid for 30 days, with a cycle
-interval of 7.5 days. Therefore, if any existing RRSIG records
-are due to expire in less than 7.5 days, they would be
-replaced.
-.TP
-\fB-n \fIncpus\fB\fR
-Specifies the number of threads to use. By default, one
-thread is started for each detected CPU.
-.TP
-\fB-o \fIorigin\fB\fR
-The zone origin. If not specified, the name of the zone file
-is assumed to be the origin.
-.TP
-\fB-p\fR
-Use pseudo-random data when signing the zone. This is faster,
-but less secure, than using real random data. This option
-may be useful when signing large zones or when the entropy
-source is limited.
-.TP
-\fB-r \fIrandomdev\fB\fR
-Specifies the source of randomness. If the operating
-system does not provide a \fI/dev/random\fR
-or equivalent device, the default source of randomness
-is keyboard input. \fIrandomdev\fR specifies
-the name of a character device or file containing random
-data to be used instead of the default. The special value
-\fIkeyboard\fR indicates that keyboard
-input should be used.
-.TP
-\fB-t\fR
+\fBdnssec\-signzone\fR.
+.TP
+\-i \fIinterval\fR
+When a previously signed zone is passed as input, records may be resigned. The
+\fBinterval\fR
+option specifies the cycle interval as an offset from the current time (in seconds). If a RRSIG record expires after the cycle interval, it is retained. Otherwise, it is considered to be expiring soon, and it will be replaced.
+.sp
+The default cycle interval is one quarter of the difference between the signature end and start times. So if neither
+\fBend\-time\fR
+or
+\fBstart\-time\fR
+are specified,
+\fBdnssec\-signzone\fR
+generates signatures that are valid for 30 days, with a cycle interval of 7.5 days. Therefore, if any existing RRSIG records are due to expire in less than 7.5 days, they would be replaced.
+.TP
+\-n \fIncpus\fR
+Specifies the number of threads to use. By default, one thread is started for each detected CPU.
+.TP
+\-o \fIorigin\fR
+The zone origin. If not specified, the name of the zone file is assumed to be the origin.
+.TP
+\-p
+Use pseudo\-random data when signing the zone. This is faster, but less secure, than using real random data. This option may be useful when signing large zones or when the entropy source is limited.
+.TP
+\-r \fIrandomdev\fR
+Specifies the source of randomness. If the operating system does not provide a
+\fI/dev/random\fR
+or equivalent device, the default source of randomness is keyboard input.
+\fIrandomdev\fR
+specifies the name of a character device or file containing random data to be used instead of the default. The special value
+\fIkeyboard\fR
+indicates that keyboard input should be used.
+.TP
+\-t
 Print statistics at completion.
 .TP
-\fB-v \fIlevel\fB\fR
+\-v \fIlevel\fR
 Sets the debugging level.
 .TP
-\fB-z\fR
+\-z
 Ignore KSK flag on key when determining what to sign.
 .TP
-\fBzonefile\fR
+zonefile
 The file containing the zone to be signed.
-Sets the debugging level.
 .TP
-\fBkey\fR
-The keys used to sign the zone. If no keys are specified, the
-default all zone keys that have private key files in the
-current directory.
+key
+The keys used to sign the zone. If no keys are specified, the default all zone keys that have private key files in the current directory.
 .SH "EXAMPLE"
 .PP
-The following command signs the \fBexample.com\fR
-zone with the DSA key generated in the \fBdnssec-keygen\fR
+The following command signs the
+\fBexample.com\fR
+zone with the DSA key generated in the
+\fBdnssec\-keygen\fR
 man page. The zone's keys must be in the zone. If there are
-\fIkeyset\fR files associated with child zones,
-they must be in the current directory.
-\fBexample.com\fR, the following command would be
-issued:
+\fIkeyset\fR
+files associated with child zones, they must be in the current directory.
+\fBexample.com\fR, the following command would be issued:
 .PP
-\fBdnssec-signzone -o example.com db.example.com Kexample.com.+003+26160\fR
+\fBdnssec\-signzone \-o example.com db.example.com Kexample.com.+003+26160\fR
 .PP
 The command would print a string of the form:
 .PP
-In this example, \fBdnssec-signzone\fR creates
-the file \fIdb.example.com.signed\fR. This file
-should be referenced in a zone statement in a
-\fInamed.conf\fR file.
+In this example,
+\fBdnssec\-signzone\fR
+creates the file
+\fIdb.example.com.signed\fR. This file should be referenced in a zone statement in a
+\fInamed.conf\fR
+file.
 .SH "SEE ALSO"
 .PP
-\fBdnssec-keygen\fR(8),
-\fIBIND 9 Administrator Reference Manual\fR,
-\fIRFC 2535\fR.
+\fBdnssec\-keygen\fR(8),
+BIND 9 Administrator Reference Manual,
+RFC 2535.
 .SH "AUTHOR"
 .PP
 Internet Systems Consortium
diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.c b/contrib/bind9/bin/dnssec/dnssec-signzone.c
index c2c33f8c812a..93caf497e266 100644
--- a/contrib/bind9/bin/dnssec/dnssec-signzone.c
+++ b/contrib/bind9/bin/dnssec/dnssec-signzone.c
@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2003  Internet Software Consortium.
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
@@ -16,7 +16,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dnssec-signzone.c,v 1.139.2.2.4.17 2004/10/25 01:36:06 marka Exp $ */
+/* $Id: dnssec-signzone.c,v 1.139.2.2.4.21 2005/10/14 01:38:41 marka Exp $ */
 
 #include <config.h>
 
@@ -787,7 +787,6 @@ signname(dns_dbnode_t *node, dns_name_t *name) {
 	dns_rdatasetiter_t *rdsiter;
 	isc_boolean_t isdelegation = ISC_FALSE;
 	isc_boolean_t hasds = ISC_FALSE;
-	isc_boolean_t atorigin;
 	isc_boolean_t changed = ISC_FALSE;
 	dns_diff_t del, add;
 	char namestr[DNS_NAME_FORMATSIZE];
@@ -795,8 +794,6 @@ signname(dns_dbnode_t *node, dns_name_t *name) {
 
 	dns_name_format(name, namestr, sizeof(namestr));
 
-	atorigin = dns_name_equal(name, gorigin);
-
 	/*
 	 * Determine if this is a delegation point.
 	 */
@@ -931,13 +928,16 @@ signname(dns_dbnode_t *node, dns_name_t *name) {
 
 static inline isc_boolean_t
 active_node(dns_dbnode_t *node) {
-	dns_rdatasetiter_t *rdsiter;
+	dns_rdatasetiter_t *rdsiter = NULL;
+	dns_rdatasetiter_t *rdsiter2 = NULL;
 	isc_boolean_t active = ISC_FALSE;
 	isc_result_t result;
 	dns_rdataset_t rdataset;
+	dns_rdatatype_t type;
+	dns_rdatatype_t covers;
+	isc_boolean_t found;
 
 	dns_rdataset_init(&rdataset);
-	rdsiter = NULL;
 	result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter);
 	check_result(result, "dns_db_allrdatasets()");
 	result = dns_rdatasetiter_first(rdsiter);
@@ -958,36 +958,63 @@ active_node(dns_dbnode_t *node) {
 
 	if (!active) {
 		/*
-		 * Make sure there is no NSEC / RRSIG records for
-		 * this node.
+		 * The node is empty of everything but NSEC / RRSIG records.
 		 */
-		result = dns_db_deleterdataset(gdb, node, gversion,
-					       dns_rdatatype_nsec, 0);
-		if (result == DNS_R_UNCHANGED)
-			result = ISC_R_SUCCESS;
-		check_result(result, "dns_db_deleterdataset(nsec)");
-		
-		result = dns_rdatasetiter_first(rdsiter);
 		for (result = dns_rdatasetiter_first(rdsiter);
 		     result == ISC_R_SUCCESS;
 		     result = dns_rdatasetiter_next(rdsiter)) {
 			dns_rdatasetiter_current(rdsiter, &rdataset);
-			if (rdataset.type == dns_rdatatype_rrsig) {
-				dns_rdatatype_t type = rdataset.type;
-				dns_rdatatype_t covers = rdataset.covers;
+			result = dns_db_deleterdataset(gdb, node, gversion,
+						       rdataset.type,
+						       rdataset.covers);
+			check_result(result, "dns_db_deleterdataset()");
+			dns_rdataset_disassociate(&rdataset);
+		}
+		if (result != ISC_R_NOMORE)
+			fatal("rdataset iteration failed: %s",
+			      isc_result_totext(result));
+	} else {
+		/* 
+		 * Delete RRSIGs for types that no longer exist.
+		 */
+		result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter2);
+		check_result(result, "dns_db_allrdatasets()");
+		for (result = dns_rdatasetiter_first(rdsiter);
+		     result == ISC_R_SUCCESS;
+		     result = dns_rdatasetiter_next(rdsiter)) {
+			dns_rdatasetiter_current(rdsiter, &rdataset);
+			type = rdataset.type;
+			covers = rdataset.covers;
+			dns_rdataset_disassociate(&rdataset);
+			if (type != dns_rdatatype_rrsig)
+				continue;
+			found = ISC_FALSE;
+			for (result = dns_rdatasetiter_first(rdsiter2);
+			     !found && result == ISC_R_SUCCESS;
+			     result = dns_rdatasetiter_next(rdsiter2)) {
+				dns_rdatasetiter_current(rdsiter2, &rdataset);
+				if (rdataset.type == covers)
+					found = ISC_TRUE;
+				dns_rdataset_disassociate(&rdataset);
+			}
+			if (!found) {
+				if (result != ISC_R_NOMORE)
+					fatal("rdataset iteration failed: %s",
+					      isc_result_totext(result));
 				result = dns_db_deleterdataset(gdb, node,
 							       gversion, type,
 							       covers);
-				if (result == DNS_R_UNCHANGED)
-					result = ISC_R_SUCCESS;
 				check_result(result,
 					     "dns_db_deleterdataset(rrsig)");
-			}
-			dns_rdataset_disassociate(&rdataset);
+			} else if (result != ISC_R_NOMORE &&
+				   result != ISC_R_SUCCESS)
+				fatal("rdataset iteration failed: %s",
+				      isc_result_totext(result));
 		}
 		if (result != ISC_R_NOMORE)
 			fatal("rdataset iteration failed: %s",
 			      isc_result_totext(result));
+		dns_rdatasetiter_destroy(&rdsiter2);
 	}
 	dns_rdatasetiter_destroy(&rdsiter);
 
@@ -1423,7 +1450,6 @@ warnifallksk(dns_db_t *db) {
 	dns_dbnode_t *node = NULL;
 	dns_rdataset_t rdataset;
 	dns_rdata_t rdata = DNS_RDATA_INIT;
-	dst_key_t *pubkey;
 	isc_result_t result;
 	dns_rdata_key_t key;
 	isc_boolean_t have_non_ksk = ISC_FALSE;
@@ -1444,7 +1470,6 @@ warnifallksk(dns_db_t *db) {
 	result = dns_rdataset_first(&rdataset);
 	check_result(result, "dns_rdataset_first");
 	while (result == ISC_R_SUCCESS) {
-		pubkey = NULL;
 		dns_rdata_reset(&rdata);
 		dns_rdataset_current(&rdataset, &rdata);
 		result = dns_rdata_tostruct(&rdata, &key, NULL);
@@ -1615,9 +1640,9 @@ usage(void) {
 	fprintf(stderr, "\t\tdirectory to find keyset files (.)\n");
 	fprintf(stderr, "\t-g:\t");
 	fprintf(stderr, "generate DS records from keyset files\n");
-	fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n");
+	fprintf(stderr, "\t-s [YYYYMMDDHHMMSS|+offset]:\n");
 	fprintf(stderr, "\t\tRRSIG start time - absolute|offset (now - 1 hour)\n");
-	fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n");
+	fprintf(stderr, "\t-e [YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n");
 	fprintf(stderr, "\t\tRRSIG end time  - absolute|from start|from now "
 				"(now + 30 days)\n");
 	fprintf(stderr, "\t-i interval:\n");
diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.docbook b/contrib/bind9/bin/dnssec/dnssec-signzone.docbook
index 2b85102a0b54..35f35cc7339d 100644
--- a/contrib/bind9/bin/dnssec/dnssec-signzone.docbook
+++ b/contrib/bind9/bin/dnssec/dnssec-signzone.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001-2003  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: dnssec-signzone.docbook,v 1.2.2.2.4.8 2004/06/11 01:17:35 marka Exp $ -->
+<!-- $Id: dnssec-signzone.docbook,v 1.2.2.2.4.11 2005/06/24 00:18:15 marka Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,21 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><application>dnssec-signzone</application></refname>
     <refpurpose>DNSSEC zone signing tool</refpurpose>
@@ -290,7 +307,6 @@
 	<listitem>
 	  <para>
 	       The file containing the zone to be signed.
-	       Sets the debugging level.
 	  </para>
 	</listitem>
       </varlistentry>
diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.html b/contrib/bind9/bin/dnssec/dnssec-signzone.html
index 221099fbdbec..5cc8c0747cc8 100644
--- a/contrib/bind9/bin/dnssec/dnssec-signzone.html
+++ b/contrib/bind9/bin/dnssec/dnssec-signzone.html
@@ -1,553 +1,220 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001-2003  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: dnssec-signzone.html,v 1.4.2.1.4.7 2004/08/22 23:38:58 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->dnssec-signzone</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><SPAN
-CLASS="APPLICATION"
->dnssec-signzone</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->dnssec-signzone</SPAN
->&nbsp;--&nbsp;DNSSEC zone signing tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->dnssec-signzone</B
->  [<VAR
-CLASS="OPTION"
->-a</VAR
->] [<VAR
-CLASS="OPTION"
->-c <VAR
-CLASS="REPLACEABLE"
->class</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-d <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-e <VAR
-CLASS="REPLACEABLE"
->end-time</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-f <VAR
-CLASS="REPLACEABLE"
->output-file</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-g</VAR
->] [<VAR
-CLASS="OPTION"
->-h</VAR
->] [<VAR
-CLASS="OPTION"
->-k <VAR
-CLASS="REPLACEABLE"
->key</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-l <VAR
-CLASS="REPLACEABLE"
->domain</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-i <VAR
-CLASS="REPLACEABLE"
->interval</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-n <VAR
-CLASS="REPLACEABLE"
->nthreads</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-o <VAR
-CLASS="REPLACEABLE"
->origin</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-p</VAR
->] [<VAR
-CLASS="OPTION"
->-r <VAR
-CLASS="REPLACEABLE"
->randomdev</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-s <VAR
-CLASS="REPLACEABLE"
->start-time</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-t</VAR
->] [<VAR
-CLASS="OPTION"
->-v <VAR
-CLASS="REPLACEABLE"
->level</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-z</VAR
->] {zonefile} [key...]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN66"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->dnssec-signzone</B
-> signs a zone.  It generates
+<!-- $Id: dnssec-signzone.html,v 1.4.2.1.4.14 2005/10/13 02:33:46 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dnssec-signzone</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">dnssec-signzone</span> &#8212; DNSSEC zone signing tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dnssec-signzone</code>  [<code class="option">-a</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-e <em class="replaceable"><code>end-time</code></em></code>] [<code class="option">-f <em class="replaceable"><code>output-file</code></em></code>] [<code class="option">-g</code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>key</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-n <em class="replaceable"><code>nthreads</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-p</code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-s <em class="replaceable"><code>start-time</code></em></code>] [<code class="option">-t</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {zonefile} [key...]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525979"></a><h2>DESCRIPTION</h2>
+<p>
+        <span><strong class="command">dnssec-signzone</strong></span> signs a zone.  It generates
 	NSEC and RRSIG records and produces a signed version of the
 	zone. The security status of delegations from the signed zone
 	(that is, whether the child zones are secure or not) is
 	determined by the presence or absence of a
-	<TT
-CLASS="FILENAME"
->keyset</TT
-> file for each child zone.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN71"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-a</DT
-><DD
-><P
->	      Verify all generated signatures.
-	  </P
-></DD
-><DT
->-c <VAR
-CLASS="REPLACEABLE"
->class</VAR
-></DT
-><DD
-><P
->	       Specifies the DNS class of the zone.
-	  </P
-></DD
-><DT
->-k <VAR
-CLASS="REPLACEABLE"
->key</VAR
-></DT
-><DD
-><P
->	       Treat specified key as a key signing key ignoring any
+	<code class="filename">keyset</code> file for each child zone.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525995"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-a</span></dt>
+<dd><p>
+	      Verify all generated signatures.
+	  </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
+<dd><p>
+	       Specifies the DNS class of the zone.
+	  </p></dd>
+<dt><span class="term">-k <em class="replaceable"><code>key</code></em></span></dt>
+<dd><p>
+	       Treat specified key as a key signing key ignoring any
 	       key flags.  This option may be specified multiple times.
-	  </P
-></DD
-><DT
->-l <VAR
-CLASS="REPLACEABLE"
->domain</VAR
-></DT
-><DD
-><P
->		Generate a DLV set in addition to the key (DNSKEY) and DS sets.
+	  </p></dd>
+<dt><span class="term">-l <em class="replaceable"><code>domain</code></em></span></dt>
+<dd><p>
+		Generate a DLV set in addition to the key (DNSKEY) and DS sets.
 		The domain is appended to the name of the records.
-	  </P
-></DD
-><DT
->-d <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></DT
-><DD
-><P
->	       Look for <TT
-CLASS="FILENAME"
->keyset</TT
-> files in
-	       <VAR
-CLASS="OPTION"
->directory</VAR
-> as the directory 
-	  </P
-></DD
-><DT
->-g</DT
-><DD
-><P
->		Generate DS records for child zones from keyset files.
+	  </p></dd>
+<dt><span class="term">-d <em class="replaceable"><code>directory</code></em></span></dt>
+<dd><p>
+	       Look for <code class="filename">keyset</code> files in
+	       <code class="option">directory</code> as the directory 
+	  </p></dd>
+<dt><span class="term">-g</span></dt>
+<dd><p>
+		Generate DS records for child zones from keyset files.
 		Existing DS records will be removed.
-	  </P
-></DD
-><DT
->-s <VAR
-CLASS="REPLACEABLE"
->start-time</VAR
-></DT
-><DD
-><P
->	       Specify the date and time when the generated RRSIG records
+	  </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>start-time</code></em></span></dt>
+<dd><p>
+	       Specify the date and time when the generated RRSIG records
 	       become valid.  This can be either an absolute or relative
 	       time.  An absolute start time is indicated by a number
 	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
 	       14:45:00 UTC on May 30th, 2000.  A relative start time is
 	       indicated by +N, which is N seconds from the current time.
-	       If no <VAR
-CLASS="OPTION"
->start-time</VAR
-> is specified, the current
+	       If no <code class="option">start-time</code> is specified, the current
 	       time minus 1 hour (to allow for clock skew) is used.
-	  </P
-></DD
-><DT
->-e <VAR
-CLASS="REPLACEABLE"
->end-time</VAR
-></DT
-><DD
-><P
->	       Specify the date and time when the generated RRSIG records
-	       expire.  As with <VAR
-CLASS="OPTION"
->start-time</VAR
->, an absolute
+	  </p></dd>
+<dt><span class="term">-e <em class="replaceable"><code>end-time</code></em></span></dt>
+<dd><p>
+	       Specify the date and time when the generated RRSIG records
+	       expire.  As with <code class="option">start-time</code>, an absolute
 	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
 	       to the start time is indicated with +N, which is N seconds from
 	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <VAR
-CLASS="OPTION"
->end-time</VAR
-> is
+	       indicated with now+N.  If no <code class="option">end-time</code> is
 	       specified, 30 days from the start time is used as a default.
-	  </P
-></DD
-><DT
->-f <VAR
-CLASS="REPLACEABLE"
->output-file</VAR
-></DT
-><DD
-><P
->	       The name of the output file containing the signed zone.  The
-	       default is to append <TT
-CLASS="FILENAME"
->.signed</TT
-> to the
+	  </p></dd>
+<dt><span class="term">-f <em class="replaceable"><code>output-file</code></em></span></dt>
+<dd><p>
+	       The name of the output file containing the signed zone.  The
+	       default is to append <code class="filename">.signed</code> to the
 	       input file.
-	  </P
-></DD
-><DT
->-h</DT
-><DD
-><P
->	       Prints a short summary of the options and arguments to
-	       <B
-CLASS="COMMAND"
->dnssec-signzone</B
->.
-	  </P
-></DD
-><DT
->-i <VAR
-CLASS="REPLACEABLE"
->interval</VAR
-></DT
-><DD
-><P
->	       When a previously signed zone is passed as input, records
-	       may be resigned.  The <VAR
-CLASS="OPTION"
->interval</VAR
-> option
+	  </p></dd>
+<dt><span class="term">-h</span></dt>
+<dd><p>
+	       Prints a short summary of the options and arguments to
+	       <span><strong class="command">dnssec-signzone</strong></span>.
+	  </p></dd>
+<dt><span class="term">-i <em class="replaceable"><code>interval</code></em></span></dt>
+<dd>
+<p>
+	       When a previously signed zone is passed as input, records
+	       may be resigned.  The <code class="option">interval</code> option
 	       specifies the cycle interval as an offset from the current
 	       time (in seconds).  If a RRSIG record expires after the
 	       cycle interval, it is retained.  Otherwise, it is considered
 	       to be expiring soon, and it will be replaced.
-	  </P
-><P
->	       The default cycle interval is one quarter of the difference
+	  </p>
+<p>
+	       The default cycle interval is one quarter of the difference
 	       between the signature end and start times.  So if neither
-	       <VAR
-CLASS="OPTION"
->end-time</VAR
-> or <VAR
-CLASS="OPTION"
->start-time</VAR
->
-	       are specified, <B
-CLASS="COMMAND"
->dnssec-signzone</B
-> generates
+	       <code class="option">end-time</code> or <code class="option">start-time</code>
+	       are specified, <span><strong class="command">dnssec-signzone</strong></span> generates
 	       signatures that are valid for 30 days, with a cycle
 	       interval of 7.5 days.  Therefore, if any existing RRSIG records
 	       are due to expire in less than 7.5 days, they would be
 	       replaced.
-	  </P
-></DD
-><DT
->-n <VAR
-CLASS="REPLACEABLE"
->ncpus</VAR
-></DT
-><DD
-><P
->	       Specifies the number of threads to use.  By default, one
+	  </p>
+</dd>
+<dt><span class="term">-n <em class="replaceable"><code>ncpus</code></em></span></dt>
+<dd><p>
+	       Specifies the number of threads to use.  By default, one
 	       thread is started for each detected CPU.
-	  </P
-></DD
-><DT
->-o <VAR
-CLASS="REPLACEABLE"
->origin</VAR
-></DT
-><DD
-><P
->	       The zone origin.  If not specified, the name of the zone file
+	  </p></dd>
+<dt><span class="term">-o <em class="replaceable"><code>origin</code></em></span></dt>
+<dd><p>
+	       The zone origin.  If not specified, the name of the zone file
 	       is assumed to be the origin.
-	  </P
-></DD
-><DT
->-p</DT
-><DD
-><P
->	       Use pseudo-random data when signing the zone.  This is faster,
+	  </p></dd>
+<dt><span class="term">-p</span></dt>
+<dd><p>
+	       Use pseudo-random data when signing the zone.  This is faster,
 	       but less secure, than using real random data.  This option
 	       may be useful when signing large zones or when the entropy
 	       source is limited.
-	  </P
-></DD
-><DT
->-r <VAR
-CLASS="REPLACEABLE"
->randomdev</VAR
-></DT
-><DD
-><P
->	       Specifies the source of randomness.  If the operating
-	       system does not provide a <TT
-CLASS="FILENAME"
->/dev/random</TT
->
+	  </p></dd>
+<dt><span class="term">-r <em class="replaceable"><code>randomdev</code></em></span></dt>
+<dd><p>
+	       Specifies the source of randomness.  If the operating
+	       system does not provide a <code class="filename">/dev/random</code>
 	       or equivalent device, the default source of randomness
-	       is keyboard input.  <TT
-CLASS="FILENAME"
->randomdev</TT
-> specifies
+	       is keyboard input.  <code class="filename">randomdev</code> specifies
 	       the name of a character device or file containing random
 	       data to be used instead of the default.  The special value
-	       <TT
-CLASS="FILENAME"
->keyboard</TT
-> indicates that keyboard
+	       <code class="filename">keyboard</code> indicates that keyboard
 	       input should be used.
-	  </P
-></DD
-><DT
->-t</DT
-><DD
-><P
->	       Print statistics at completion.
-	  </P
-></DD
-><DT
->-v <VAR
-CLASS="REPLACEABLE"
->level</VAR
-></DT
-><DD
-><P
->	       Sets the debugging level.
-	  </P
-></DD
-><DT
->-z</DT
-><DD
-><P
->	       Ignore KSK flag on key when determining what to sign.
-	  </P
-></DD
-><DT
->zonefile</DT
-><DD
-><P
->	       The file containing the zone to be signed.
+	  </p></dd>
+<dt><span class="term">-t</span></dt>
+<dd><p>
+	       Print statistics at completion.
+	  </p></dd>
+<dt><span class="term">-v <em class="replaceable"><code>level</code></em></span></dt>
+<dd><p>
 	       Sets the debugging level.
-	  </P
-></DD
-><DT
->key</DT
-><DD
-><P
->	       The keys used to sign the zone.  If no keys are specified, the
+	  </p></dd>
+<dt><span class="term">-z</span></dt>
+<dd><p>
+	       Ignore KSK flag on key when determining what to sign.
+	  </p></dd>
+<dt><span class="term">zonefile</span></dt>
+<dd><p>
+	       The file containing the zone to be signed.
+	  </p></dd>
+<dt><span class="term">key</span></dt>
+<dd><p>
+	       The keys used to sign the zone.  If no keys are specified, the
 	       default all zone keys that have private key files in the
 	       current directory.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN181"
-></A
-><H2
->EXAMPLE</H2
-><P
->        The following command signs the <KBD
-CLASS="USERINPUT"
->example.com</KBD
->
-	zone with the DSA key generated in the <B
-CLASS="COMMAND"
->dnssec-keygen</B
->
+	  </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526435"></a><h2>EXAMPLE</h2>
+<p>
+        The following command signs the <strong class="userinput"><code>example.com</code></strong>
+	zone with the DSA key generated in the <span><strong class="command">dnssec-keygen</strong></span>
 	man page.  The zone's keys must be in the zone.  If there are
-	<TT
-CLASS="FILENAME"
->keyset</TT
-> files associated with child zones,
+	<code class="filename">keyset</code> files associated with child zones,
 	they must be in the current directory.
-	<KBD
-CLASS="USERINPUT"
->example.com</KBD
->, the following command would be
+	<strong class="userinput"><code>example.com</code></strong>, the following command would be
 	issued:
-    </P
-><P
->        <KBD
-CLASS="USERINPUT"
->dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160</KBD
->
-    </P
-><P
->        The command would print a string of the form:
-    </P
-><P
->        In this example, <B
-CLASS="COMMAND"
->dnssec-signzone</B
-> creates
-	the file <TT
-CLASS="FILENAME"
->db.example.com.signed</TT
->.  This file
+    </p>
+<p>
+        <strong class="userinput"><code>dnssec-signzone -o example.com db.example.com Kexample.com.+003+26160</code></strong>
+    </p>
+<p>
+        The command would print a string of the form:
+    </p>
+<p>
+        In this example, <span><strong class="command">dnssec-signzone</strong></span> creates
+	the file <code class="filename">db.example.com.signed</code>.  This file
 	should be referenced in a zone statement in a
-	<TT
-CLASS="FILENAME"
->named.conf</TT
-> file.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN195"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->,
-      <I
-CLASS="CITETITLE"
->RFC 2535</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN203"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+	<code class="filename">named.conf</code> file.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526485"></a><h2>SEE ALSO</h2>
+<p>
+      <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
+      <em class="citetitle">RFC 2535</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526512"></a><h2>AUTHOR</h2>
+<p>
+        <span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/dnssec/dnssectool.c b/contrib/bind9/bin/dnssec/dnssectool.c
index 1b84de8f48aa..83ba76d91288 100644
--- a/contrib/bind9/bin/dnssec/dnssectool.c
+++ b/contrib/bind9/bin/dnssec/dnssectool.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dnssectool.c,v 1.31.2.3.2.4 2004/03/08 02:07:38 marka Exp $ */
+/* $Id: dnssectool.c,v 1.31.2.3.2.6 2005/07/02 02:42:43 marka Exp $ */
 
 #include <config.h>
 
@@ -145,6 +145,8 @@ setup_logging(int verbose, isc_mem_t *mctx, isc_log_t **logp) {
 	isc_log_t *log = NULL;
 	int level;
 
+	if (verbose < 0)
+		verbose = 0;
 	switch (verbose) {
 	case 0:
 		/*
diff --git a/contrib/bind9/bin/named/aclconf.c b/contrib/bind9/bin/named/aclconf.c
index ef36c5681f48..8b6d0c767d4f 100644
--- a/contrib/bind9/bin/named/aclconf.c
+++ b/contrib/bind9/bin/named/aclconf.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: aclconf.c,v 1.27.12.3 2004/03/08 04:04:18 marka Exp $ */
+/* $Id: aclconf.c,v 1.27.12.5 2005/03/17 03:58:25 marka Exp $ */
 
 #include <config.h>
 
@@ -31,6 +31,8 @@
 
 #include <named/aclconf.h>
 
+#define LOOP_MAGIC ISC_MAGIC('L','O','O','P')
+
 void
 ns_aclconfctx_init(ns_aclconfctx_t *ctx) {
 	ISC_LIST_INIT(ctx->named_acl_cache);
@@ -81,6 +83,7 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx,
 	isc_result_t result;
 	cfg_obj_t *cacl = NULL;
 	dns_acl_t *dacl;
+	dns_acl_t loop;
 	char *aclname = cfg_obj_asstring(nameobj);
 
 	/* Look for an already-converted version. */
@@ -89,6 +92,11 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx,
 	     dacl = ISC_LIST_NEXT(dacl, nextincache))
 	{
 		if (strcasecmp(aclname, dacl->name) == 0) {
+			if (ISC_MAGIC_VALID(dacl, LOOP_MAGIC)) {
+				cfg_obj_log(nameobj, dns_lctx, ISC_LOG_ERROR,
+					    "acl loop detected: %s", aclname);
+				return (ISC_R_FAILURE);
+			}
 			dns_acl_attach(dacl, target);
 			return (ISC_R_SUCCESS);
 		}
@@ -100,7 +108,18 @@ convert_named_acl(cfg_obj_t *nameobj, cfg_obj_t *cctx,
 			    "undefined ACL '%s'", aclname);
 		return (result);
 	}
+	/*
+	 * Add a loop detection element.
+	 */
+	memset(&loop, 0, sizeof(loop));
+	ISC_LINK_INIT(&loop, nextincache);
+	loop.name = aclname;
+	loop.magic = LOOP_MAGIC;
+	ISC_LIST_APPEND(ctx->named_acl_cache, &loop, nextincache);
 	result = ns_acl_fromconfig(cacl, cctx, ctx, mctx, &dacl);
+	ISC_LIST_UNLINK(ctx->named_acl_cache, &loop, nextincache);
+	loop.magic = 0;
+	loop.name = NULL;
 	if (result != ISC_R_SUCCESS)
 		return (result);
 	dacl->name = isc_mem_strdup(dacl->mctx, aclname);
diff --git a/contrib/bind9/bin/named/client.c b/contrib/bind9/bin/named/client.c
index 259f8d9dc299..baecc2345cb9 100644
--- a/contrib/bind9/bin/named/client.c
+++ b/contrib/bind9/bin/named/client.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: client.c,v 1.176.2.13.4.23 2004/09/26 22:37:43 marka Exp $ */
+/* $Id: client.c,v 1.176.2.13.4.26 2005/07/27 02:53:14 marka Exp $ */
 
 #include <config.h>
 
@@ -177,20 +177,10 @@ static void client_request(isc_task_t *task, isc_event_t *event);
 static void ns_client_dumpmessage(ns_client_t *client, const char *reason);
 
 void
-ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest) {
-	ns_client_t *oldest;
+ns_client_recursing(ns_client_t *client) {
 	REQUIRE(NS_CLIENT_VALID(client));
 
 	LOCK(&client->manager->lock);
-	if (killoldest) {
-		oldest = ISC_LIST_HEAD(client->manager->recursing);
-		if (oldest != NULL) {
-			ns_query_cancel(oldest);
-			ISC_LIST_UNLINK(*oldest->list, oldest, link);
-			ISC_LIST_APPEND(client->manager->active, oldest, link);
-			oldest->list = &client->manager->active;
-		}
-	}
 	ISC_LIST_UNLINK(*client->list, client, link);
 	ISC_LIST_APPEND(client->manager->recursing, client, link);
 	client->list = &client->manager->recursing;
@@ -198,6 +188,22 @@ ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest) {
 }
 
 void
+ns_client_killoldestquery(ns_client_t *client) {
+	ns_client_t *oldest;
+	REQUIRE(NS_CLIENT_VALID(client));
+
+	LOCK(&client->manager->lock);
+	oldest = ISC_LIST_HEAD(client->manager->recursing);
+	if (oldest != NULL) {
+		ns_query_cancel(oldest);
+		ISC_LIST_UNLINK(*oldest->list, oldest, link);
+		ISC_LIST_APPEND(client->manager->active, oldest, link);
+		oldest->list = &client->manager->active;
+	}
+	UNLOCK(&client->manager->lock);
+}
+
+void
 ns_client_settimeout(ns_client_t *client, unsigned int seconds) {
 	isc_result_t result;
 	isc_interval_t interval;
@@ -1603,8 +1609,7 @@ client_timeout(isc_task_t *task, isc_event_t *event) {
 }
 
 static isc_result_t
-client_create(ns_clientmgr_t *manager, ns_client_t **clientp)
-{
+client_create(ns_clientmgr_t *manager, ns_client_t **clientp) {
 	ns_client_t *client;
 	isc_result_t result;
 
diff --git a/contrib/bind9/bin/named/control.c b/contrib/bind9/bin/named/control.c
index b6ff6fe2cbc8..c9d17abe0276 100644
--- a/contrib/bind9/bin/named/control.c
+++ b/contrib/bind9/bin/named/control.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: control.c,v 1.7.2.2.2.11 2004/09/03 03:43:31 marka Exp $ */
+/* $Id: control.c,v 1.7.2.2.2.14 2005/04/29 01:04:47 marka Exp $ */
 
 #include <config.h>
 
@@ -37,6 +37,9 @@
 #include <named/log.h>
 #include <named/os.h>
 #include <named/server.h>
+#ifdef HAVE_LIBSCF
+#include <named/ns_smf_globals.h>
+#endif
 
 static isc_boolean_t
 command_compare(const char *text, const char *command) {
@@ -58,6 +61,9 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) {
 	isccc_sexpr_t *data;
 	char *command;
 	isc_result_t result;
+#ifdef HAVE_LIBSCF
+	ns_smf_want_disable = 0;
+#endif
 
 	data = isccc_alist_lookup(message, "_data");
 	if (data == NULL) {
@@ -92,11 +98,41 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) {
 	} else if (command_compare(command, NS_COMMAND_RETRANSFER)) {
 		result = ns_server_retransfercommand(ns_g_server, command);
 	} else if (command_compare(command, NS_COMMAND_HALT)) {
+#ifdef HAVE_LIBSCF
+		/*
+		 * If we are managed by smf(5), AND in chroot, then
+		 * we cannot connect to the smf repository, so just
+		 * return with an appropriate message back to rndc.
+		 */
+		if (ns_smf_got_instance == 1 && ns_smf_chroot == 1) {
+			result = ns_smf_add_message(text);
+			return (result);
+		}
+		/*
+		 * If we are managed by smf(5) but not in chroot,
+		 * try to disable ourselves the smf way.
+		 */
+		if (ns_smf_got_instance == 1 && ns_smf_chroot == 0)
+			ns_smf_want_disable = 1;
+		/*
+		 * If ns_smf_got_instance = 0, ns_smf_chroot
+		 * is not relevant and we fall through to
+		 * isc_app_shutdown below.
+		 */
+#endif
 		ns_server_flushonshutdown(ns_g_server, ISC_FALSE);
 		ns_os_shutdownmsg(command, text);
 		isc_app_shutdown();
 		result = ISC_R_SUCCESS;
 	} else if (command_compare(command, NS_COMMAND_STOP)) {
+#ifdef HAVE_LIBSCF
+		if (ns_smf_got_instance == 1 && ns_smf_chroot == 1) {
+			result = ns_smf_add_message(text);
+			return (result);
+		}
+		if (ns_smf_got_instance == 1 && ns_smf_chroot == 0)
+			ns_smf_want_disable = 1;
+#endif
 		ns_server_flushonshutdown(ns_g_server, ISC_TRUE);
 		ns_os_shutdownmsg(command, text);
 		isc_app_shutdown();
diff --git a/contrib/bind9/bin/named/include/named/client.h b/contrib/bind9/bin/named/include/named/client.h
index 97951a41683c..7097a3bb05b5 100644
--- a/contrib/bind9/bin/named/include/named/client.h
+++ b/contrib/bind9/bin/named/include/named/client.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: client.h,v 1.60.2.2.10.8 2004/07/23 02:56:52 marka Exp $ */
+/* $Id: client.h,v 1.60.2.2.10.10 2005/07/29 00:13:08 marka Exp $ */
 
 #ifndef NAMED_CLIENT_H
 #define NAMED_CLIENT_H 1
@@ -322,13 +322,19 @@ ns_client_aclmsg(const char *msg, dns_name_t *name, dns_rdatatype_t type,
 	 DNS_RDATACLASS_FORMATSIZE + sizeof(x) + sizeof("'/'"))
 
 void
-ns_client_recursing(ns_client_t *client, isc_boolean_t killoldest);
-/*
+ns_client_recursing(ns_client_t *client);
+/*%
  * Add client to end of recursing list.  If 'killoldest' is true
  * kill the oldest recursive client (list head). 
  */
 
 void
+ns_client_killoldestquery(ns_client_t *client);
+/*%
+ * Kill the oldest recursive query (recursing list head).
+ */
+
+void
 ns_client_dumprecursing(FILE *f, ns_clientmgr_t *manager);
 /*
  * Dump the outstanding recursive queries to 'f'.
diff --git a/contrib/bind9/bin/named/log.c b/contrib/bind9/bin/named/log.c
index 31af4bdd13c7..9032af795d4f 100644
--- a/contrib/bind9/bin/named/log.c
+++ b/contrib/bind9/bin/named/log.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.c,v 1.33.2.1.10.4 2004/03/08 09:04:14 marka Exp $ */
+/* $Id: log.c,v 1.33.2.1.10.6 2005/05/24 23:58:17 marka Exp $ */
 
 #include <config.h>
 
@@ -154,6 +154,9 @@ ns_log_setdefaultchannels(isc_logconfig_t *lcfg) {
 isc_result_t
 ns_log_setsafechannels(isc_logconfig_t *lcfg) {
 	isc_result_t result;
+#if ISC_FACILITY != LOG_DAEMON
+	isc_logdestination_t destination;
+#endif
 
 	if (! ns_g_logstderr) {
 		result = isc_log_createchannel(lcfg, "default_debug",
@@ -172,6 +175,15 @@ ns_log_setsafechannels(isc_logconfig_t *lcfg) {
 		isc_log_setdebuglevel(ns_g_lctx, ns_g_debuglevel);
 	}
 
+#if ISC_FACILITY != LOG_DAEMON
+	destination.facility = ISC_FACILITY;
+	result = isc_log_createchannel(lcfg, "default_syslog",
+				       ISC_LOG_TOSYSLOG, ISC_LOG_INFO,
+				       &destination, 0);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+#endif
+
 	result = ISC_R_SUCCESS;
 
  cleanup:
diff --git a/contrib/bind9/bin/named/lwresd.8 b/contrib/bind9/bin/named/lwresd.8
index bbc177d0ff69..58f24b062374 100644
--- a/contrib/bind9/bin/named/lwresd.8
+++ b/contrib/bind9/bin/named/lwresd.8
@@ -1,135 +1,135 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwresd.8,v 1.13.208.2 2004/06/03 05:35:47 marka Exp $
+.\" $Id: lwresd.8,v 1.13.208.5 2005/10/13 02:33:47 marka Exp $
 .\"
-.TH "LWRESD" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRESD" "8" "June 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwresd \- lightweight resolver daemon
-.SH SYNOPSIS
-.sp
-\fBlwresd\fR [ \fB-C \fIconfig-file\fB\fR ]  [ \fB-d \fIdebug-level\fB\fR ]  [ \fB-f\fR ]  [ \fB-g\fR ]  [ \fB-i \fIpid-file\fB\fR ]  [ \fB-n \fI#cpus\fB\fR ]  [ \fB-P \fIport\fB\fR ]  [ \fB-p \fIport\fB\fR ]  [ \fB-s\fR ]  [ \fB-t \fIdirectory\fB\fR ]  [ \fB-u \fIuser\fB\fR ]  [ \fB-v\fR ] 
+.SH "SYNOPSIS"
+.HP 7
+\fBlwresd\fR [\fB\-C\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-d\ \fR\fB\fIdebug\-level\fR\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-i\ \fR\fB\fIpid\-file\fR\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-P\ \fR\fB\fIport\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR]
 .SH "DESCRIPTION"
 .PP
-\fBlwresd\fR is the daemon providing name lookup
-services to clients that use the BIND 9 lightweight resolver
-library. It is essentially a stripped-down, caching-only name
-server that answers queries using the BIND 9 lightweight
-resolver protocol rather than the DNS protocol.
+\fBlwresd\fR
+is the daemon providing name lookup services to clients that use the BIND 9 lightweight resolver library. It is essentially a stripped\-down, caching\-only name server that answers queries using the BIND 9 lightweight resolver protocol rather than the DNS protocol.
 .PP
-\fBlwresd\fR listens for resolver queries on a
-UDP port on the IPv4 loopback interface, 127.0.0.1. This
-means that \fBlwresd\fR can only be used by
-processes running on the local machine. By default UDP port
-number 921 is used for lightweight resolver requests and
-responses.
+\fBlwresd\fR
+listens for resolver queries on a UDP port on the IPv4 loopback interface, 127.0.0.1. This means that
+\fBlwresd\fR
+can only be used by processes running on the local machine. By default UDP port number 921 is used for lightweight resolver requests and responses.
 .PP
-Incoming lightweight resolver requests are decoded by the
-server which then resolves them using the DNS protocol. When
-the DNS lookup completes, \fBlwresd\fR encodes
-the answers in the lightweight resolver format and returns
-them to the client that made the request.
+Incoming lightweight resolver requests are decoded by the server which then resolves them using the DNS protocol. When the DNS lookup completes,
+\fBlwresd\fR
+encodes the answers in the lightweight resolver format and returns them to the client that made the request.
 .PP
-If \fI/etc/resolv.conf\fR contains any
-\fBnameserver\fR entries, \fBlwresd\fR
-sends recursive DNS queries to those servers. This is similar
-to the use of forwarders in a caching name server. If no
-\fBnameserver\fR entries are present, or if
-forwarding fails, \fBlwresd\fR resolves the
-queries autonomously starting at the root name servers, using
-a built-in list of root server hints.
+If
+\fI/etc/resolv.conf\fR
+contains any
+\fBnameserver\fR
+entries,
+\fBlwresd\fR
+sends recursive DNS queries to those servers. This is similar to the use of forwarders in a caching name server. If no
+\fBnameserver\fR
+entries are present, or if forwarding fails,
+\fBlwresd\fR
+resolves the queries autonomously starting at the root name servers, using a built\-in list of root server hints.
 .SH "OPTIONS"
 .TP
-\fB-C \fIconfig-file\fB\fR
-Use \fIconfig-file\fR as the
-configuration file instead of the default,
+\-C \fIconfig\-file\fR
+Use
+\fIconfig\-file\fR
+as the configuration file instead of the default,
 \fI/etc/resolv.conf\fR.
 .TP
-\fB-d \fIdebug-level\fB\fR
-Set the daemon's debug level to \fIdebug-level\fR.
-Debugging traces from \fBlwresd\fR become
-more verbose as the debug level increases.
+\-d \fIdebug\-level\fR
+Set the daemon's debug level to
+\fIdebug\-level\fR. Debugging traces from
+\fBlwresd\fR
+become more verbose as the debug level increases.
 .TP
-\fB-f\fR
+\-f
 Run the server in the foreground (i.e. do not daemonize).
 .TP
-\fB-g\fR
-Run the server in the foreground and force all logging
-to \fIstderr\fR.
+\-g
+Run the server in the foreground and force all logging to
+\fIstderr\fR.
 .TP
-\fB-n \fI#cpus\fB\fR
-Create \fI#cpus\fR worker threads
-to take advantage of multiple CPUs. If not specified,
-\fBlwresd\fR will try to determine the
-number of CPUs present and create one thread per CPU.
-If it is unable to determine the number of CPUs, a
-single worker thread will be created.
+\-n \fI#cpus\fR
+Create
+\fI#cpus\fR
+worker threads to take advantage of multiple CPUs. If not specified,
+\fBlwresd\fR
+will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created.
 .TP
-\fB-P \fIport\fB\fR
+\-P \fIport\fR
 Listen for lightweight resolver queries on port
-\fIport\fR. If
-not specified, the default is port 921.
+\fIport\fR. If not specified, the default is port 921.
 .TP
-\fB-p \fIport\fB\fR
-Send DNS lookups to port \fIport\fR. If not
-specified, the default is port 53. This provides a
-way of testing the lightweight resolver daemon with a
-name server that listens for queries on a non-standard
-port number.
+\-p \fIport\fR
+Send DNS lookups to port
+\fIport\fR. If not specified, the default is port 53. This provides a way of testing the lightweight resolver daemon with a name server that listens for queries on a non\-standard port number.
 .TP
-\fB-s\fR
-Write memory usage statistics to \fIstdout\fR
+\-s
+Write memory usage statistics to
+\fIstdout\fR
 on exit.
-.sp
 .RS
 .B "Note:"
-This option is mainly of interest to BIND 9 developers
-and may be removed or changed in a future release.
+This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release.
 .RE
-.sp
 .TP
-\fB-t \fIdirectory\fB\fR
-\fBchroot()\fR to \fIdirectory\fR after
-processing the command line arguments, but before
-reading the configuration file.
-.sp
+\-t \fIdirectory\fR
+\fBchroot()\fR
+to
+\fIdirectory\fR
+after processing the command line arguments, but before reading the configuration file.
 .RS
 .B "Warning:"
 This option should be used in conjunction with the
-\fB-u\fR option, as chrooting a process
-running as root doesn't enhance security on most
-systems; the way \fBchroot()\fR is
-defined allows a process with root privileges to
-escape a chroot jail.
+\fB\-u\fR
+option, as chrooting a process running as root doesn't enhance security on most systems; the way
+\fBchroot()\fR
+is defined allows a process with root privileges to escape a chroot jail.
 .RE
-.sp
 .TP
-\fB-u \fIuser\fB\fR
-\fBsetuid()\fR to \fIuser\fR after completing
-privileged operations, such as creating sockets that
-listen on privileged ports.
+\-u \fIuser\fR
+\fBsetuid()\fR
+to
+\fIuser\fR
+after completing privileged operations, such as creating sockets that listen on privileged ports.
 .TP
-\fB-v\fR
+\-v
 Report the version number and exit.
 .SH "FILES"
 .TP
-\fB\fI/etc/resolv.conf\fB\fR
+\fI/etc/resolv.conf\fR
 The default configuration file.
 .TP
-\fB\fI/var/run/lwresd.pid\fB\fR
-The default process-id file.
+\fI/var/run/lwresd.pid\fR
+The default process\-id file.
 .SH "SEE ALSO"
 .PP
 \fBnamed\fR(8),
diff --git a/contrib/bind9/bin/named/lwresd.docbook b/contrib/bind9/bin/named/lwresd.docbook
index 46314c2614ea..c1f500bb8300 100644
--- a/contrib/bind9/bin/named/lwresd.docbook
+++ b/contrib/bind9/bin/named/lwresd.docbook
@@ -1,6 +1,8 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwresd.docbook,v 1.6.208.2 2004/06/03 02:24:57 marka Exp $ -->
+<!-- $Id: lwresd.docbook,v 1.6.208.4 2005/05/13 01:22:33 marka Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,19 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><application>lwresd</application></refname>
     <refpurpose>lightweight resolver daemon</refpurpose>
diff --git a/contrib/bind9/bin/named/lwresd.html b/contrib/bind9/bin/named/lwresd.html
index afe7af22f480..439153aa826a 100644
--- a/contrib/bind9/bin/named/lwresd.html
+++ b/contrib/bind9/bin/named/lwresd.html
@@ -1,497 +1,189 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000, 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwresd.html,v 1.4.2.1.4.3 2004/08/22 23:38:59 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwresd</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><SPAN
-CLASS="APPLICATION"
->lwresd</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->lwresd</SPAN
->&nbsp;--&nbsp;lightweight resolver daemon</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->lwresd</B
->  [<VAR
-CLASS="OPTION"
->-C <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-d <VAR
-CLASS="REPLACEABLE"
->debug-level</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-f</VAR
->] [<VAR
-CLASS="OPTION"
->-g</VAR
->] [<VAR
-CLASS="OPTION"
->-i <VAR
-CLASS="REPLACEABLE"
->pid-file</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-n <VAR
-CLASS="REPLACEABLE"
->#cpus</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-P <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-p <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-s</VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-u <VAR
-CLASS="REPLACEABLE"
->user</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-v</VAR
->]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN48"
-></A
-><H2
->DESCRIPTION</H2
-><P
->	<B
-CLASS="COMMAND"
->lwresd</B
-> is the daemon providing name lookup
+<!-- $Id: lwresd.html,v 1.4.2.1.4.8 2005/10/13 02:33:47 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwresd</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">lwresd</span> &#8212; lightweight resolver daemon</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">lwresd</code>  [<code class="option">-C <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-i <em class="replaceable"><code>pid-file</code></em></code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-P <em class="replaceable"><code>port</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525920"></a><h2>DESCRIPTION</h2>
+<p>
+	<span><strong class="command">lwresd</strong></span> is the daemon providing name lookup
 	services to clients that use the BIND 9 lightweight resolver
 	library.  It is essentially a stripped-down, caching-only name
 	server that answers queries using the BIND 9 lightweight
 	resolver protocol rather than the DNS protocol.
-    </P
-><P
->	<B
-CLASS="COMMAND"
->lwresd</B
-> listens for resolver queries on a
+    </p>
+<p>
+	<span><strong class="command">lwresd</strong></span> listens for resolver queries on a
 	UDP port on the IPv4 loopback interface, 127.0.0.1.  This
-	means that <B
-CLASS="COMMAND"
->lwresd</B
-> can only be used by
+	means that <span><strong class="command">lwresd</strong></span> can only be used by
 	processes running on the local machine.  By default UDP port
 	number 921 is used for lightweight resolver requests and
 	responses.
-    </P
-><P
->	Incoming lightweight resolver requests are decoded by the
+    </p>
+<p>
+	Incoming lightweight resolver requests are decoded by the
 	server which then resolves them using the DNS protocol.  When
-	the DNS lookup completes, <B
-CLASS="COMMAND"
->lwresd</B
-> encodes
+	the DNS lookup completes, <span><strong class="command">lwresd</strong></span> encodes
 	the answers in the lightweight resolver format and returns
 	them to the client that made the request.
-    </P
-><P
->	If <TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
-> contains any
-	<VAR
-CLASS="OPTION"
->nameserver</VAR
-> entries, <B
-CLASS="COMMAND"
->lwresd</B
->
+    </p>
+<p>
+	If <code class="filename">/etc/resolv.conf</code> contains any
+	<code class="option">nameserver</code> entries, <span><strong class="command">lwresd</strong></span>
 	sends recursive DNS queries to those servers.  This is similar
 	to the use of forwarders in a caching name server.  If no
-	<VAR
-CLASS="OPTION"
->nameserver</VAR
-> entries are present, or if
-	forwarding fails, <B
-CLASS="COMMAND"
->lwresd</B
-> resolves the
+	<code class="option">nameserver</code> entries are present, or if
+	forwarding fails, <span><strong class="command">lwresd</strong></span> resolves the
 	queries autonomously starting at the root name servers, using
 	a built-in list of root server hints.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN63"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-C <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-></DT
-><DD
-><P
->		Use <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-> as the
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525969"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-C <em class="replaceable"><code>config-file</code></em></span></dt>
+<dd><p>
+		Use <em class="replaceable"><code>config-file</code></em> as the
 		configuration file instead of the default,
-		<TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
->.
-          </P
-></DD
-><DT
->-d <VAR
-CLASS="REPLACEABLE"
->debug-level</VAR
-></DT
-><DD
-><P
->		Set the daemon's debug level to <VAR
-CLASS="REPLACEABLE"
->debug-level</VAR
->.
-		Debugging traces from <B
-CLASS="COMMAND"
->lwresd</B
-> become
+		<code class="filename">/etc/resolv.conf</code>.
+          </p></dd>
+<dt><span class="term">-d <em class="replaceable"><code>debug-level</code></em></span></dt>
+<dd><p>
+		Set the daemon's debug level to <em class="replaceable"><code>debug-level</code></em>.
+		Debugging traces from <span><strong class="command">lwresd</strong></span> become
 		more verbose as the debug level increases.
-          </P
-></DD
-><DT
->-f</DT
-><DD
-><P
->		Run the server in the foreground (i.e. do not daemonize).
-          </P
-></DD
-><DT
->-g</DT
-><DD
-><P
->		Run the server in the foreground and force all logging
-		to <TT
-CLASS="FILENAME"
->stderr</TT
->.
-          </P
-></DD
-><DT
->-n <VAR
-CLASS="REPLACEABLE"
->#cpus</VAR
-></DT
-><DD
-><P
->		Create <VAR
-CLASS="REPLACEABLE"
->#cpus</VAR
-> worker threads
+          </p></dd>
+<dt><span class="term">-f</span></dt>
+<dd><p>
+		Run the server in the foreground (i.e. do not daemonize).
+          </p></dd>
+<dt><span class="term">-g</span></dt>
+<dd><p>
+		Run the server in the foreground and force all logging
+		to <code class="filename">stderr</code>.
+          </p></dd>
+<dt><span class="term">-n <em class="replaceable"><code>#cpus</code></em></span></dt>
+<dd><p>
+		Create <em class="replaceable"><code>#cpus</code></em> worker threads
 		to take advantage of multiple CPUs.  If not specified,
-		<B
-CLASS="COMMAND"
->lwresd</B
-> will try to determine the
+		<span><strong class="command">lwresd</strong></span> will try to determine the
 		number of CPUs present and create one thread per CPU.
 		If it is unable to determine the number of CPUs, a
 		single worker thread will be created.
-          </P
-></DD
-><DT
->-P <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></DT
-><DD
-><P
->		Listen for lightweight resolver queries on port
-		<VAR
-CLASS="REPLACEABLE"
->port</VAR
->.  If
+          </p></dd>
+<dt><span class="term">-P <em class="replaceable"><code>port</code></em></span></dt>
+<dd><p>
+		Listen for lightweight resolver queries on port
+		<em class="replaceable"><code>port</code></em>.  If
 		not specified, the default is port 921.
-          </P
-></DD
-><DT
->-p <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></DT
-><DD
-><P
->		Send DNS lookups to port <VAR
-CLASS="REPLACEABLE"
->port</VAR
->.  If not
+          </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
+<dd><p>
+		Send DNS lookups to port <em class="replaceable"><code>port</code></em>.  If not
 		specified, the default is port 53.  This provides a
 		way of testing the lightweight resolver daemon with a
 		name server that listens for queries on a non-standard
 		port number.
-          </P
-></DD
-><DT
->-s</DT
-><DD
-><P
->		Write memory usage statistics to <TT
-CLASS="FILENAME"
->stdout</TT
->
+          </p></dd>
+<dt><span class="term">-s</span></dt>
+<dd>
+<p>
+		Write memory usage statistics to <code class="filename">stdout</code>
 		on exit.
-          </P
-><DIV
-CLASS="NOTE"
-><BLOCKQUOTE
-CLASS="NOTE"
-><P
-><B
->Note: </B
->		This option is mainly of interest to BIND 9 developers
+          </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+		This option is mainly of interest to BIND 9 developers
 		and may be removed or changed in a future release.
-	    </P
-></BLOCKQUOTE
-></DIV
-></DD
-><DT
->-t <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></DT
-><DD
-><P
->		<CODE
-CLASS="FUNCTION"
->chroot()</CODE
-> to <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-> after
+	    </p>
+</div>
+</dd>
+<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
+<dd>
+<p>
+		<code class="function">chroot()</code> to <em class="replaceable"><code>directory</code></em> after
 		processing the command line arguments, but before
 		reading the configuration file.
-          </P
-><DIV
-CLASS="WARNING"
-><P
-></P
-><TABLE
-CLASS="WARNING"
-BORDER="1"
-WIDTH="90%"
-><TR
-><TD
-ALIGN="CENTER"
-><B
->Warning</B
-></TD
-></TR
-><TR
-><TD
-ALIGN="LEFT"
-><P
->		This option should be used in conjunction with the
-		<VAR
-CLASS="OPTION"
->-u</VAR
-> option, as chrooting a process
+          </p>
+<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Warning</h3>
+<p>
+		This option should be used in conjunction with the
+		<code class="option">-u</code> option, as chrooting a process
 		running as root doesn't enhance security on most
-		systems; the way <CODE
-CLASS="FUNCTION"
->chroot()</CODE
-> is
+		systems; the way <code class="function">chroot()</code> is
 		defined allows a process with root privileges to
 		escape a chroot jail.
-	    </P
-></TD
-></TR
-></TABLE
-></DIV
-></DD
-><DT
->-u <VAR
-CLASS="REPLACEABLE"
->user</VAR
-></DT
-><DD
-><P
->		<CODE
-CLASS="FUNCTION"
->setuid()</CODE
-> to <VAR
-CLASS="REPLACEABLE"
->user</VAR
-> after completing
+	    </p>
+</div>
+</dd>
+<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
+<dd><p>
+		<code class="function">setuid()</code> to <em class="replaceable"><code>user</code></em> after completing
 		privileged operations, such as creating sockets that
 		listen on privileged ports.
-          </P
-></DD
-><DT
->-v</DT
-><DD
-><P
->		Report the version number and exit.
-          </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN137"
-></A
-><H2
->FILES</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
-></DT
-><DD
-><P
->		The default configuration file.
-          </P
-></DD
-><DT
-><TT
-CLASS="FILENAME"
->/var/run/lwresd.pid</TT
-></DT
-><DD
-><P
->		The default process-id file.
-          </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN150"
-></A
-><H2
->SEE ALSO</H2
-><P
->	<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->,
-	<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres</SPAN
->(3)</SPAN
->,
-	<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->resolver</SPAN
->(5)</SPAN
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN162"
-></A
-><H2
->AUTHOR</H2
-><P
->	Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+          </p></dd>
+<dt><span class="term">-v</span></dt>
+<dd><p>
+		Report the version number and exit.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526237"></a><h2>FILES</h2>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="filename">/etc/resolv.conf</code></span></dt>
+<dd><p>
+		The default configuration file.
+          </p></dd>
+<dt><span class="term"><code class="filename">/var/run/lwresd.pid</code></span></dt>
+<dd><p>
+		The default process-id file.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526277"></a><h2>SEE ALSO</h2>
+<p>
+	<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+	<span class="citerefentry"><span class="refentrytitle">lwres</span>(3)</span>,
+	<span class="citerefentry"><span class="refentrytitle">resolver</span>(5)</span>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526315"></a><h2>AUTHOR</h2>
+<p>
+	<span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/named/main.c b/contrib/bind9/bin/named/main.c
index f78ea247c8a7..c155291d6ca6 100644
--- a/contrib/bind9/bin/named/main.c
+++ b/contrib/bind9/bin/named/main.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: main.c,v 1.119.2.3.2.17 2004/10/25 00:42:54 marka Exp $ */
+/* $Id: main.c,v 1.119.2.3.2.22 2005/04/29 01:04:47 marka Exp $ */
 
 #include <config.h>
 
@@ -47,10 +47,6 @@
 
 #include <dst/result.h>
 
-#ifdef HAVE_LIBSCF
-#include <libscf.h>
-#endif
-
 /*
  * Defining NS_MAIN provides storage declarations (rather than extern)
  * for variables in named/globals.h.
@@ -66,6 +62,9 @@
 #include <named/server.h>
 #include <named/lwresd.h>
 #include <named/main.h>
+#ifdef HAVE_LIBSCF
+#include <named/ns_smf_globals.h>
+#endif
 
 /*
  * Include header files for database drivers here.
@@ -540,6 +539,9 @@ destroy_managers(void) {
 static void
 setup(void) {
 	isc_result_t result;
+#ifdef HAVE_LIBSCF
+	char *instance = NULL;
+#endif
 
 	/*
 	 * Get the user and group information before changing the root
@@ -555,6 +557,18 @@ setup(void) {
 
 	ns_os_opendevnull();
 
+#ifdef HAVE_LIBSCF
+	/* Check if named is under smf control, before chroot. */
+	result = ns_smf_get_instance(&instance, 0, ns_g_mctx);
+	/* We don't care about instance, just check if we got one. */
+	if (result == ISC_R_SUCCESS)
+		ns_smf_got_instance = 1;
+	else
+		ns_smf_got_instance = 0;
+	if (instance != NULL)
+		isc_mem_free(ns_g_mctx, instance);
+#endif /* HAVE_LIBSCF */
+
 #ifdef PATH_RANDOMDEV
 	/*
 	 * Initialize system's random device as fallback entropy source
@@ -699,92 +713,73 @@ ns_main_setmemstats(const char *filename) {
 
 #ifdef HAVE_LIBSCF
 /*
- * Get FMRI for the current named process
+ * Get FMRI for the named process.
  */
-static char *
-scf_get_ins_name(void) {
+isc_result_t
+ns_smf_get_instance(char **ins_name, int debug, isc_mem_t *mctx) {
 	scf_handle_t *h = NULL;
 	int namelen;
-	char *ins_name;
+	char *instance;
+
+	REQUIRE(ins_name != NULL && *ins_name == NULL);
 
 	if ((h = scf_handle_create(SCF_VERSION)) == NULL) {
-		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "scf_handle_create() failed: %s",
-				 scf_strerror(scf_error()));
-		return (NULL);
+		if (debug)
+			UNEXPECTED_ERROR(__FILE__, __LINE__,
+					 "scf_handle_create() failed: %s",
+			 		 scf_strerror(scf_error()));
+		return (ISC_R_FAILURE);
 	}
 
 	if (scf_handle_bind(h) == -1) {
-		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "scf_handle_bind() failed: %s",
-				 scf_strerror(scf_error()));
+		if (debug)
+			UNEXPECTED_ERROR(__FILE__, __LINE__,
+					 "scf_handle_bind() failed: %s",
+					 scf_strerror(scf_error()));
 		scf_handle_destroy(h);
-		return (NULL);
+		return (ISC_R_FAILURE);
 	}
 
 	if ((namelen = scf_myname(h, NULL, 0)) == -1) {
-		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
-			      NS_LOGMODULE_MAIN, ISC_LOG_INFO,
-			      "scf_myname() failed: %s",
-			      scf_strerror(scf_error()));
+		if (debug)
+			UNEXPECTED_ERROR(__FILE__, __LINE__,
+					 "scf_myname() failed: %s",
+					 scf_strerror(scf_error()));
 		scf_handle_destroy(h);
-		return (NULL);
+		return (ISC_R_FAILURE);
 	}
 
-	if ((ins_name = malloc(namelen + 1)) == NULL) {
+	if ((instance = isc_mem_allocate(mctx, namelen + 1)) == NULL) {
 		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "scf_get_ins_named() memory "
+				 "ns_smf_get_instance memory "
 				 "allocation failed: %s",
 				 isc_result_totext(ISC_R_NOMEMORY));
 		scf_handle_destroy(h);
-		return (NULL);
+		return (ISC_R_FAILURE);
 	}
 
-	if (scf_myname(h, ins_name, namelen + 1) == -1) {
-		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "scf_myname() failed: %s",
-				 scf_strerror(scf_error()));
+	if (scf_myname(h, instance, namelen + 1) == -1) {
+		if (debug)
+			UNEXPECTED_ERROR(__FILE__, __LINE__,
+					 "scf_myname() failed: %s",
+					 scf_strerror(scf_error()));
 		scf_handle_destroy(h);
-		free(ins_name);
-		return (NULL);
+		isc_mem_free(mctx, instance);
+		return (ISC_R_FAILURE);
 	}
 
 	scf_handle_destroy(h);
-	isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_MAIN,
-		      ISC_LOG_INFO, "instance name:%s", ins_name);
-
-	return (ins_name);
-}
-
-static void
-scf_cleanup(void) {
-	char *s;
-	char *ins_name;
-
-	if ((ins_name = scf_get_ins_name()) != NULL) {
-		if ((s = smf_get_state(ins_name)) != NULL) {
-			if ((strcmp(SCF_STATE_STRING_ONLINE, s) == 0) ||
-			    (strcmp(SCF_STATE_STRING_DEGRADED, s) == 0)) {
-				if (smf_disable_instance(ins_name, 0) != 0) {
-				    UNEXPECTED_ERROR(__FILE__, __LINE__,
-					"smf_disable_instance() failed: %s",
-					scf_strerror(scf_error()));
-				}
-			}
-			free(s);
-		} else {
-			UNEXPECTED_ERROR(__FILE__, __LINE__,
-					 "smf_get_state() failed: %s",
-					 scf_strerror(scf_error()));
-		}
-		free(ins_name);
-	}
+	*ins_name = instance;
+	return (ISC_R_SUCCESS);
 }
-#endif
+#endif /* HAVE_LIBSCF */
 
 int
 main(int argc, char *argv[]) {
 	isc_result_t result;
+#ifdef HAVE_LIBSCF
+	char *instance = NULL;
+#endif
 
 	/*
 	 * Record version in core image.
@@ -856,8 +851,20 @@ main(int argc, char *argv[]) {
 	} while (result != ISC_R_SUCCESS);
 
 #ifdef HAVE_LIBSCF
-	scf_cleanup();
-#endif
+	if (ns_smf_want_disable == 1) {
+		result = ns_smf_get_instance(&instance, 1, ns_g_mctx);
+		if (result == ISC_R_SUCCESS && instance != NULL) {
+			if (smf_disable_instance(instance, 0) != 0)
+				UNEXPECTED_ERROR(__FILE__, __LINE__,
+						 "smf_disable_instance() ",
+						 "failed for %s : %s",
+						 instance,
+						 scf_strerror(scf_error()));
+		}
+		if (instance != NULL)
+			isc_mem_free(ns_g_mctx, instance);
+	}
+#endif /* HAVE_LIBSCF */
 
 	cleanup();
 
diff --git a/contrib/bind9/bin/named/named.8 b/contrib/bind9/bin/named/named.8
index cd120ddc6f63..e072c169be3e 100644
--- a/contrib/bind9/bin/named/named.8
+++ b/contrib/bind9/bin/named/named.8
@@ -1,177 +1,182 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: named.8,v 1.17.208.3 2004/06/03 05:35:47 marka Exp $
+.\" $Id: named.8,v 1.17.208.6 2005/10/13 02:33:46 marka Exp $
 .\"
-.TH "NAMED" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "NAMED" "8" "June 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 named \- Internet domain name server
-.SH SYNOPSIS
-.sp
-\fBnamed\fR [ \fB-4\fR ]  [ \fB-6\fR ]  [ \fB-c \fIconfig-file\fB\fR ]  [ \fB-d \fIdebug-level\fB\fR ]  [ \fB-f\fR ]  [ \fB-g\fR ]  [ \fB-n \fI#cpus\fB\fR ]  [ \fB-p \fIport\fB\fR ]  [ \fB-s\fR ]  [ \fB-t \fIdirectory\fB\fR ]  [ \fB-u \fIuser\fB\fR ]  [ \fB-v\fR ]  [ \fB-x \fIcache-file\fB\fR ] 
+.SH "SYNOPSIS"
+.HP 6
+\fBnamed\fR [\fB\-4\fR] [\fB\-6\fR] [\fB\-c\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-d\ \fR\fB\fIdebug\-level\fR\fR] [\fB\-f\fR] [\fB\-g\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR] [\fB\-x\ \fR\fB\fIcache\-file\fR\fR]
 .SH "DESCRIPTION"
 .PP
-\fBnamed\fR is a Domain Name System (DNS) server,
-part of the BIND 9 distribution from ISC. For more
-information on the DNS, see RFCs 1033, 1034, and 1035.
+\fBnamed\fR
+is a Domain Name System (DNS) server, part of the BIND 9 distribution from ISC. For more information on the DNS, see RFCs 1033, 1034, and 1035.
 .PP
-When invoked without arguments, \fBnamed\fR will
-read the default configuration file
-\fI/etc/named.conf\fR, read any initial
-data, and listen for queries.
+When invoked without arguments,
+\fBnamed\fR
+will read the default configuration file
+\fI/etc/named.conf\fR, read any initial data, and listen for queries.
 .SH "OPTIONS"
 .TP
-\fB-4\fR
+\-4
 Use IPv4 only even if the host machine is capable of IPv6.
-\fB-4\fR and \fB-6\fR are mutually
-exclusive.
+\fB\-4\fR
+and
+\fB\-6\fR
+are mutually exclusive.
 .TP
-\fB-6\fR
+\-6
 Use IPv6 only even if the host machine is capable of IPv4.
-\fB-4\fR and \fB-6\fR are mutually
-exclusive.
-.TP
-\fB-c \fIconfig-file\fB\fR
-Use \fIconfig-file\fR as the
-configuration file instead of the default,
-\fI/etc/named.conf\fR. To
-ensure that reloading the configuration file continues
-to work after the server has changed its working
-directory due to to a possible
-\fBdirectory\fR option in the configuration
-file, \fIconfig-file\fR should be
-an absolute pathname.
-.TP
-\fB-d \fIdebug-level\fB\fR
-Set the daemon's debug level to \fIdebug-level\fR.
-Debugging traces from \fBnamed\fR become
-more verbose as the debug level increases.
-.TP
-\fB-f\fR
+\fB\-4\fR
+and
+\fB\-6\fR
+are mutually exclusive.
+.TP
+\-c \fIconfig\-file\fR
+Use
+\fIconfig\-file\fR
+as the configuration file instead of the default,
+\fI/etc/named.conf\fR. To ensure that reloading the configuration file continues to work after the server has changed its working directory due to to a possible
+\fBdirectory\fR
+option in the configuration file,
+\fIconfig\-file\fR
+should be an absolute pathname.
+.TP
+\-d \fIdebug\-level\fR
+Set the daemon's debug level to
+\fIdebug\-level\fR. Debugging traces from
+\fBnamed\fR
+become more verbose as the debug level increases.
+.TP
+\-f
 Run the server in the foreground (i.e. do not daemonize).
 .TP
-\fB-g\fR
-Run the server in the foreground and force all logging
-to \fIstderr\fR.
-.TP
-\fB-n \fI#cpus\fB\fR
-Create \fI#cpus\fR worker threads
-to take advantage of multiple CPUs. If not specified,
-\fBnamed\fR will try to determine the
-number of CPUs present and create one thread per CPU.
-If it is unable to determine the number of CPUs, a
-single worker thread will be created.
-.TP
-\fB-p \fIport\fB\fR
-Listen for queries on port \fIport\fR. If not
-specified, the default is port 53.
-.TP
-\fB-s\fR
-Write memory usage statistics to \fIstdout\fR on exit.
-.sp
+\-g
+Run the server in the foreground and force all logging to
+\fIstderr\fR.
+.TP
+\-n \fI#cpus\fR
+Create
+\fI#cpus\fR
+worker threads to take advantage of multiple CPUs. If not specified,
+\fBnamed\fR
+will try to determine the number of CPUs present and create one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread will be created.
+.TP
+\-p \fIport\fR
+Listen for queries on port
+\fIport\fR. If not specified, the default is port 53.
+.TP
+\-s
+Write memory usage statistics to
+\fIstdout\fR
+on exit.
 .RS
 .B "Note:"
-This option is mainly of interest to BIND 9 developers
-and may be removed or changed in a future release.
+This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release.
 .RE
-.sp
 .TP
-\fB-t \fIdirectory\fB\fR
-\fBchroot()\fR to \fIdirectory\fR after
-processing the command line arguments, but before
-reading the configuration file.
-.sp
+\-t \fIdirectory\fR
+\fBchroot()\fR
+to
+\fIdirectory\fR
+after processing the command line arguments, but before reading the configuration file.
 .RS
 .B "Warning:"
 This option should be used in conjunction with the
-\fB-u\fR option, as chrooting a process
-running as root doesn't enhance security on most
-systems; the way \fBchroot()\fR is
-defined allows a process with root privileges to
-escape a chroot jail.
+\fB\-u\fR
+option, as chrooting a process running as root doesn't enhance security on most systems; the way
+\fBchroot()\fR
+is defined allows a process with root privileges to escape a chroot jail.
 .RE
-.sp
 .TP
-\fB-u \fIuser\fB\fR
-\fBsetuid()\fR to \fIuser\fR after completing
-privileged operations, such as creating sockets that
-listen on privileged ports.
-.sp
+\-u \fIuser\fR
+\fBsetuid()\fR
+to
+\fIuser\fR
+after completing privileged operations, such as creating sockets that listen on privileged ports.
 .RS
 .B "Note:"
-On Linux, \fBnamed\fR uses the kernel's
-capability mechanism to drop all root privileges
-except the ability to \fBbind()\fR to a
-privileged port and set process resource limits.
-Unfortunately, this means that the \fB-u\fR
-option only works when \fBnamed\fR is run
-on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or
-later, since previous kernels did not allow privileges
-to be retained after \fBsetuid()\fR.
+On Linux,
+\fBnamed\fR
+uses the kernel's capability mechanism to drop all root privileges except the ability to
+\fBbind()\fR
+to a privileged port and set process resource limits. Unfortunately, this means that the
+\fB\-u\fR
+option only works when
+\fBnamed\fR
+is run on kernel 2.2.18 or later, or kernel 2.3.99\-pre3 or later, since previous kernels did not allow privileges to be retained after
+\fBsetuid()\fR.
 .RE
-.sp
 .TP
-\fB-v\fR
+\-v
 Report the version number and exit.
 .TP
-\fB-x \fIcache-file\fB\fR
-Load data from \fIcache-file\fR into the
-cache of the default view.
-.sp
+\-x \fIcache\-file\fR
+Load data from
+\fIcache\-file\fR
+into the cache of the default view.
 .RS
 .B "Warning:"
-This option must not be used. It is only of interest
-to BIND 9 developers and may be removed or changed in a
-future release.
+This option must not be used. It is only of interest to BIND 9 developers and may be removed or changed in a future release.
 .RE
-.sp
 .SH "SIGNALS"
 .PP
-In routine operation, signals should not be used to control
-the nameserver; \fBrndc\fR should be used
-instead.
+In routine operation, signals should not be used to control the nameserver;
+\fBrndc\fR
+should be used instead.
 .TP
-\fBSIGHUP\fR
+SIGHUP
 Force a reload of the server.
 .TP
-\fBSIGINT, SIGTERM\fR
+SIGINT, SIGTERM
 Shut down the server.
 .PP
 The result of sending any other signals to the server is undefined.
-.PP
 .SH "CONFIGURATION"
 .PP
-The \fBnamed\fR configuration file is too complex
-to describe in detail here. A complete description is
-provided in the \fIBIND 9 Administrator Reference
-Manual\fR.
+The
+\fBnamed\fR
+configuration file is too complex to describe in detail here. A complete description is provided in the
+BIND 9 Administrator Reference Manual.
 .SH "FILES"
 .TP
-\fB\fI/etc/named.conf\fB\fR
+\fI/etc/named.conf\fR
 The default configuration file.
 .TP
-\fB\fI/var/run/named.pid\fB\fR
-The default process-id file.
+\fI/var/run/named.pid\fR
+The default process\-id file.
 .SH "SEE ALSO"
 .PP
-\fIRFC 1033\fR,
-\fIRFC 1034\fR,
-\fIRFC 1035\fR,
+RFC 1033,
+RFC 1034,
+RFC 1035,
 \fBrndc\fR(8),
 \fBlwresd\fR(8),
-\fIBIND 9 Administrator Reference Manual\fR.
+BIND 9 Administrator Reference Manual.
 .SH "AUTHOR"
 .PP
 Internet Systems Consortium
diff --git a/contrib/bind9/bin/named/named.conf.5 b/contrib/bind9/bin/named/named.conf.5
index 2b7387b9555c..d0b690b1b5a0 100644
--- a/contrib/bind9/bin/named/named.conf.5
+++ b/contrib/bind9/bin/named/named.conf.5
@@ -1,32 +1,40 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: named.conf.5,v 1.1.4.3 2004/10/18 02:33:06 marka Exp $
+.\" $Id: named.conf.5,v 1.1.4.6 2005/10/13 02:33:47 marka Exp $
 .\"
-.TH "NAMED.CONF" "5" "Aug 13, 2004" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "\\FINAMED.CONF\\FR" "5" "Aug 13, 2004" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 named.conf \- configuration file for named
-.SH SYNOPSIS
-.sp
+.SH "SYNOPSIS"
+.HP 11
 \fBnamed.conf\fR
 .SH "DESCRIPTION"
 .PP
-\fInamed.conf\fR is the configuration file for
-\fBnamed\fR. Statements are enclosed
-in braces and terminated with a semi-colon. Clauses in
-the statements are also semi-colon terminated. The usual
-comment styles are supported:
+\fInamed.conf\fR
+is the configuration file for
+\fBnamed\fR. Statements are enclosed in braces and terminated with a semi\-colon. Clauses in the statements are also semi\-colon terminated. The usual comment styles are supported:
 .PP
 C style: /* */
 .PP
@@ -37,7 +45,6 @@ Unix style: # to end of line
 .sp
 .nf
 acl \fIstring\fR { \fIaddress_match_element\fR; ... };
-.sp
 .fi
 .SH "KEY"
 .sp
@@ -46,7 +53,6 @@ key \fIdomain_name\fR {
 	algorithm \fIstring\fR;
 	secret \fIstring\fR;
 };
-.sp
 .fi
 .SH "MASTERS"
 .sp
@@ -55,7 +61,6 @@ masters \fIstring\fR [ port \fIinteger\fR ] {
 	( \fImasters\fR | \fIipv4_address\fR [port \fIinteger\fR] |
 	\fIipv6_address\fR [port \fIinteger\fR] ) [ key \fIstring\fR ]; ...
 };
-.sp
 .fi
 .SH "SERVER"
 .sp
@@ -63,27 +68,24 @@ masters \fIstring\fR [ port \fIinteger\fR ] {
 server ( \fIipv4_address\fR | \fIipv6_address\fR ) {
 	bogus \fIboolean\fR;
 	edns \fIboolean\fR;
-	provide-ixfr \fIboolean\fR;
-	request-ixfr \fIboolean\fR;
+	provide\-ixfr \fIboolean\fR;
+	request\-ixfr \fIboolean\fR;
 	keys \fIserver_key\fR;
 	transfers \fIinteger\fR;
-	transfer-format ( many-answers | one-answer );
-	transfer-source ( \fIipv4_address\fR | * )
+	transfer\-format ( many\-answers | one\-answer );
+	transfer\-source ( \fIipv4_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	transfer-source-v6 ( \fIipv6_address\fR | * )
+	transfer\-source\-v6 ( \fIipv6_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-
-	support-ixfr \fIboolean\fR; // obsolete
+	support\-ixfr \fIboolean\fR; // obsolete
 };
-.sp
 .fi
-.SH "TRUSTED-KEYS"
+.SH "TRUSTED\-KEYS"
 .sp
 .nf
-trusted-keys {
+trusted\-keys {
 	\fIdomain_name\fR \fIflags\fR \fIprotocol\fR \fIalgorithm\fR \fIkey\fR; ... 
 };
-.sp
 .fi
 .SH "CONTROLS"
 .sp
@@ -95,7 +97,6 @@ controls {
 		[ keys { \fIstring\fR; ... } ];
 	unix \fIunsupported\fR; // not implemented
 };
-.sp
 .fi
 .SH "LOGGING"
 .sp
@@ -107,363 +108,325 @@ logging {
 		null;
 		stderr;
 		severity \fIlog_severity\fR;
-		print-time \fIboolean\fR;
-		print-severity \fIboolean\fR;
-		print-category \fIboolean\fR;
+		print\-time \fIboolean\fR;
+		print\-severity \fIboolean\fR;
+		print\-category \fIboolean\fR;
 	};
 	category \fIstring\fR { \fIstring\fR; ... };
 };
-.sp
 .fi
 .SH "LWRES"
 .sp
 .nf
 lwres {
-	listen-on [ port \fIinteger\fR ] {
+	listen\-on [ port \fIinteger\fR ] {
 		( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ...
 	};
 	view \fIstring\fR \fIoptional_class\fR;
 	search { \fIstring\fR; ... };
 	ndots \fIinteger\fR;
 };
-.sp
 .fi
 .SH "OPTIONS"
 .sp
 .nf
 options {
-	avoid-v4-udp-ports { \fIport\fR; ... };
-	avoid-v6-udp-ports { \fIport\fR; ... };
+	avoid\-v4\-udp\-ports { \fIport\fR; ... };
+	avoid\-v6\-udp\-ports { \fIport\fR; ... };
 	blackhole { \fIaddress_match_element\fR; ... };
 	coresize \fIsize\fR;
 	datasize \fIsize\fR;
 	directory \fIquoted_string\fR;
-	dump-file \fIquoted_string\fR;
+	dump\-file \fIquoted_string\fR;
 	files \fIsize\fR;
-	heartbeat-interval \fIinteger\fR;
-	host-statistics \fIboolean\fR; // not implemented
-	host-statistics-max \fInumber\fR; // not implemented
+	heartbeat\-interval \fIinteger\fR;
+	host\-statistics \fIboolean\fR; // not implemented
+	host\-statistics\-max \fInumber\fR; // not implemented
 	hostname ( \fIquoted_string\fR | none );
-	interface-interval \fIinteger\fR;
-	listen-on [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... };
-	listen-on-v6 [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... };
-	match-mapped-addresses \fIboolean\fR;
-	memstatistics-file \fIquoted_string\fR;
-	pid-file ( \fIquoted_string\fR | none );
+	interface\-interval \fIinteger\fR;
+	listen\-on [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... };
+	listen\-on\-v6 [ port \fIinteger\fR ] { \fIaddress_match_element\fR; ... };
+	match\-mapped\-addresses \fIboolean\fR;
+	memstatistics\-file \fIquoted_string\fR;
+	pid\-file ( \fIquoted_string\fR | none );
 	port \fIinteger\fR;
 	querylog \fIboolean\fR;
-	recursing-file \fIquoted_string\fR;
-	random-device \fIquoted_string\fR;
-	recursive-clients \fIinteger\fR;
-	serial-query-rate \fIinteger\fR;
-	server-id ( \fIquoted_string\fR | none |;
+	recursing\-file \fIquoted_string\fR;
+	random\-device \fIquoted_string\fR;
+	recursive\-clients \fIinteger\fR;
+	serial\-query\-rate \fIinteger\fR;
+	server\-id ( \fIquoted_string\fR | none |;
 	stacksize \fIsize\fR;
-	statistics-file \fIquoted_string\fR;
-	statistics-interval \fIinteger\fR; // not yet implemented
-	tcp-clients \fIinteger\fR;
-	tcp-listen-queue \fIinteger\fR;
-	tkey-dhkey \fIquoted_string\fR \fIinteger\fR;
-	tkey-gssapi-credential \fIquoted_string\fR;
-	tkey-domain \fIquoted_string\fR;
-	transfers-per-ns \fIinteger\fR;
-	transfers-in \fIinteger\fR;
-	transfers-out \fIinteger\fR;
-	use-ixfr \fIboolean\fR;
+	statistics\-file \fIquoted_string\fR;
+	statistics\-interval \fIinteger\fR; // not yet implemented
+	tcp\-clients \fIinteger\fR;
+	tcp\-listen\-queue \fIinteger\fR;
+	tkey\-dhkey \fIquoted_string\fR \fIinteger\fR;
+	tkey\-gssapi\-credential \fIquoted_string\fR;
+	tkey\-domain \fIquoted_string\fR;
+	transfers\-per\-ns \fIinteger\fR;
+	transfers\-in \fIinteger\fR;
+	transfers\-out \fIinteger\fR;
+	use\-ixfr \fIboolean\fR;
 	version ( \fIquoted_string\fR | none );
-	allow-recursion { \fIaddress_match_element\fR; ... };
+	allow\-recursion { \fIaddress_match_element\fR; ... };
 	sortlist { \fIaddress_match_element\fR; ... };
 	topology { \fIaddress_match_element\fR; ... }; // not implemented
-	auth-nxdomain \fIboolean\fR; // default changed
-	minimal-responses \fIboolean\fR;
+	auth\-nxdomain \fIboolean\fR; // default changed
+	minimal\-responses \fIboolean\fR;
 	recursion \fIboolean\fR;
-	rrset-order {
+	rrset\-order {
 		[ class \fIstring\fR ] [ type \fIstring\fR ]
 		[ name \fIquoted_string\fR ] \fIstring\fR \fIstring\fR; ...
 	};
-	provide-ixfr \fIboolean\fR;
-	request-ixfr \fIboolean\fR;
-	rfc2308-type1 \fIboolean\fR; // not yet implemented
-	additional-from-auth \fIboolean\fR;
-	additional-from-cache \fIboolean\fR;
-	query-source \fIquerysource4\fR;
-	query-source-v6 \fIquerysource6\fR;
-	cleaning-interval \fIinteger\fR;
-	min-roots \fIinteger\fR; // not implemented
-	lame-ttl \fIinteger\fR;
-	max-ncache-ttl \fIinteger\fR;
-	max-cache-ttl \fIinteger\fR;
-	transfer-format ( many-answers | one-answer );
-	max-cache-size \fIsize_no_default\fR;
-	check-names ( master | slave | response )
+	provide\-ixfr \fIboolean\fR;
+	request\-ixfr \fIboolean\fR;
+	rfc2308\-type1 \fIboolean\fR; // not yet implemented
+	additional\-from\-auth \fIboolean\fR;
+	additional\-from\-cache \fIboolean\fR;
+	query\-source \fIquerysource4\fR;
+	query\-source\-v6 \fIquerysource6\fR;
+	cleaning\-interval \fIinteger\fR;
+	min\-roots \fIinteger\fR; // not implemented
+	lame\-ttl \fIinteger\fR;
+	max\-ncache\-ttl \fIinteger\fR;
+	max\-cache\-ttl \fIinteger\fR;
+	transfer\-format ( many\-answers | one\-answer );
+	max\-cache\-size \fIsize_no_default\fR;
+	check\-names ( master | slave | response )
 		( fail | warn | ignore );
-	cache-file \fIquoted_string\fR;
-	suppress-initial-notify \fIboolean\fR; // not yet implemented
-	preferred-glue \fIstring\fR;
-	dual-stack-servers [ port \fIinteger\fR ] {
+	cache\-file \fIquoted_string\fR;
+	suppress\-initial\-notify \fIboolean\fR; // not yet implemented
+	preferred\-glue \fIstring\fR;
+	dual\-stack\-servers [ port \fIinteger\fR ] {
 		( \fIquoted_string\fR [port \fIinteger\fR] |
 		\fIipv4_address\fR [port \fIinteger\fR] |
 		\fIipv6_address\fR [port \fIinteger\fR] ); ...
 	}
-	edns-udp-size \fIinteger\fR;
-	root-delegation-only [ exclude { \fIquoted_string\fR; ... } ];
-	disable-algorithms \fIstring\fR { \fIstring\fR; ... };
-	dnssec-enable \fIboolean\fR;
-	dnssec-lookaside \fIstring\fR trust-anchor \fIstring\fR;
-	dnssec-must-be-secure \fIstring\fR \fIboolean\fR;
-
+	edns\-udp\-size \fIinteger\fR;
+	root\-delegation\-only [ exclude { \fIquoted_string\fR; ... } ];
+	disable\-algorithms \fIstring\fR { \fIstring\fR; ... };
+	dnssec\-enable \fIboolean\fR;
+	dnssec\-lookaside \fIstring\fR trust\-anchor \fIstring\fR;
+	dnssec\-must\-be\-secure \fIstring\fR \fIboolean\fR;
 	dialup \fIdialuptype\fR;
-	ixfr-from-differences \fIixfrdiff\fR;
-
-	allow-query { \fIaddress_match_element\fR; ... };
-	allow-transfer { \fIaddress_match_element\fR; ... };
-	allow-update-forwarding { \fIaddress_match_element\fR; ... };
-
+	ixfr\-from\-differences \fIixfrdiff\fR;
+	allow\-query { \fIaddress_match_element\fR; ... };
+	allow\-transfer { \fIaddress_match_element\fR; ... };
+	allow\-update\-forwarding { \fIaddress_match_element\fR; ... };
 	notify \fInotifytype\fR;
-	notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
-	notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
-	also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
+	notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
+	notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
+	also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
 		[ port \fIinteger\fR ]; ... };
-	allow-notify { \fIaddress_match_element\fR; ... };
-
+	allow\-notify { \fIaddress_match_element\fR; ... };
 	forward ( first | only );
 	forwarders [ port \fIinteger\fR ] {
 		( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ...
 	};
-
-	max-journal-size \fIsize_no_default\fR;
-	max-transfer-time-in \fIinteger\fR;
-	max-transfer-time-out \fIinteger\fR;
-	max-transfer-idle-in \fIinteger\fR;
-	max-transfer-idle-out \fIinteger\fR;
-	max-retry-time \fIinteger\fR;
-	min-retry-time \fIinteger\fR;
-	max-refresh-time \fIinteger\fR;
-	min-refresh-time \fIinteger\fR;
-	multi-master \fIboolean\fR;
-	sig-validity-interval \fIinteger\fR;
-
-	transfer-source ( \fIipv4_address\fR | * )
+	max\-journal\-size \fIsize_no_default\fR;
+	max\-transfer\-time\-in \fIinteger\fR;
+	max\-transfer\-time\-out \fIinteger\fR;
+	max\-transfer\-idle\-in \fIinteger\fR;
+	max\-transfer\-idle\-out \fIinteger\fR;
+	max\-retry\-time \fIinteger\fR;
+	min\-retry\-time \fIinteger\fR;
+	max\-refresh\-time \fIinteger\fR;
+	min\-refresh\-time \fIinteger\fR;
+	multi\-master \fIboolean\fR;
+	sig\-validity\-interval \fIinteger\fR;
+	transfer\-source ( \fIipv4_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	transfer-source-v6 ( \fIipv6_address\fR | * )
+	transfer\-source\-v6 ( \fIipv6_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-
-	alt-transfer-source ( \fIipv4_address\fR | * )
+	alt\-transfer\-source ( \fIipv4_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	alt-transfer-source-v6 ( \fIipv6_address\fR | * )
+	alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	use-alt-transfer-source \fIboolean\fR;
-
-	zone-statistics \fIboolean\fR;
-	key-directory \fIquoted_string\fR;
-
-	allow-v6-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
-	deallocate-on-exit \fIboolean\fR; // obsolete
-	fake-iquery \fIboolean\fR; // obsolete
-	fetch-glue \fIboolean\fR; // obsolete
-	has-old-clients \fIboolean\fR; // obsolete
-	maintain-ixfr-base \fIboolean\fR; // obsolete
-	max-ixfr-log-size \fIsize\fR; // obsolete
-	multiple-cnames \fIboolean\fR; // obsolete
-	named-xfer \fIquoted_string\fR; // obsolete
-	serial-queries \fIinteger\fR; // obsolete
-	treat-cr-as-space \fIboolean\fR; // obsolete
-	use-id-pool \fIboolean\fR; // obsolete
+	use\-alt\-transfer\-source \fIboolean\fR;
+	zone\-statistics \fIboolean\fR;
+	key\-directory \fIquoted_string\fR;
+	allow\-v6\-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
+	deallocate\-on\-exit \fIboolean\fR; // obsolete
+	fake\-iquery \fIboolean\fR; // obsolete
+	fetch\-glue \fIboolean\fR; // obsolete
+	has\-old\-clients \fIboolean\fR; // obsolete
+	maintain\-ixfr\-base \fIboolean\fR; // obsolete
+	max\-ixfr\-log\-size \fIsize\fR; // obsolete
+	multiple\-cnames \fIboolean\fR; // obsolete
+	named\-xfer \fIquoted_string\fR; // obsolete
+	serial\-queries \fIinteger\fR; // obsolete
+	treat\-cr\-as\-space \fIboolean\fR; // obsolete
+	use\-id\-pool \fIboolean\fR; // obsolete
 };
-.sp
 .fi
 .SH "VIEW"
 .sp
 .nf
 view \fIstring\fR \fIoptional_class\fR {
-	match-clients { \fIaddress_match_element\fR; ... };
-	match-destinations { \fIaddress_match_element\fR; ... };
-	match-recursive-only \fIboolean\fR;
-
+	match\-clients { \fIaddress_match_element\fR; ... };
+	match\-destinations { \fIaddress_match_element\fR; ... };
+	match\-recursive\-only \fIboolean\fR;
 	key \fIstring\fR {
 		algorithm \fIstring\fR;
 		secret \fIstring\fR;
 	};
-
 	zone \fIstring\fR \fIoptional_class\fR {
 		...
 	};
-
 	server ( \fIipv4_address\fR | \fIipv6_address\fR ) {
 		...
 	};
-
-	trusted-keys {
+	trusted\-keys {
 		\fIstring\fR \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; ...
 	};
-
-	allow-recursion { \fIaddress_match_element\fR; ... };
+	allow\-recursion { \fIaddress_match_element\fR; ... };
 	sortlist { \fIaddress_match_element\fR; ... };
 	topology { \fIaddress_match_element\fR; ... }; // not implemented
-	auth-nxdomain \fIboolean\fR; // default changed
-	minimal-responses \fIboolean\fR;
+	auth\-nxdomain \fIboolean\fR; // default changed
+	minimal\-responses \fIboolean\fR;
 	recursion \fIboolean\fR;
-	rrset-order {
+	rrset\-order {
 		[ class \fIstring\fR ] [ type \fIstring\fR ]
 		[ name \fIquoted_string\fR ] \fIstring\fR \fIstring\fR; ...
 	};
-	provide-ixfr \fIboolean\fR;
-	request-ixfr \fIboolean\fR;
-	rfc2308-type1 \fIboolean\fR; // not yet implemented
-	additional-from-auth \fIboolean\fR;
-	additional-from-cache \fIboolean\fR;
-	query-source \fIquerysource4\fR;
-	query-source-v6 \fIquerysource6\fR;
-	cleaning-interval \fIinteger\fR;
-	min-roots \fIinteger\fR; // not implemented
-	lame-ttl \fIinteger\fR;
-	max-ncache-ttl \fIinteger\fR;
-	max-cache-ttl \fIinteger\fR;
-	transfer-format ( many-answers | one-answer );
-	max-cache-size \fIsize_no_default\fR;
-	check-names ( master | slave | response )
+	provide\-ixfr \fIboolean\fR;
+	request\-ixfr \fIboolean\fR;
+	rfc2308\-type1 \fIboolean\fR; // not yet implemented
+	additional\-from\-auth \fIboolean\fR;
+	additional\-from\-cache \fIboolean\fR;
+	query\-source \fIquerysource4\fR;
+	query\-source\-v6 \fIquerysource6\fR;
+	cleaning\-interval \fIinteger\fR;
+	min\-roots \fIinteger\fR; // not implemented
+	lame\-ttl \fIinteger\fR;
+	max\-ncache\-ttl \fIinteger\fR;
+	max\-cache\-ttl \fIinteger\fR;
+	transfer\-format ( many\-answers | one\-answer );
+	max\-cache\-size \fIsize_no_default\fR;
+	check\-names ( master | slave | response )
 		( fail | warn | ignore );
-	cache-file \fIquoted_string\fR;
-	suppress-initial-notify \fIboolean\fR; // not yet implemented
-	preferred-glue \fIstring\fR;
-	dual-stack-servers [ port \fIinteger\fR ] {
+	cache\-file \fIquoted_string\fR;
+	suppress\-initial\-notify \fIboolean\fR; // not yet implemented
+	preferred\-glue \fIstring\fR;
+	dual\-stack\-servers [ port \fIinteger\fR ] {
 		( \fIquoted_string\fR [port \fIinteger\fR] |
 		\fIipv4_address\fR [port \fIinteger\fR] |
 		\fIipv6_address\fR [port \fIinteger\fR] ); ...
 	};
-	edns-udp-size \fIinteger\fR;
-	root-delegation-only [ exclude { \fIquoted_string\fR; ... } ];
-	disable-algorithms \fIstring\fR { \fIstring\fR; ... };
-	dnssec-enable \fIboolean\fR;
-	dnssec-lookaside \fIstring\fR trust-anchor \fIstring\fR;
-
-	dnssec-must-be-secure \fIstring\fR \fIboolean\fR;
+	edns\-udp\-size \fIinteger\fR;
+	root\-delegation\-only [ exclude { \fIquoted_string\fR; ... } ];
+	disable\-algorithms \fIstring\fR { \fIstring\fR; ... };
+	dnssec\-enable \fIboolean\fR;
+	dnssec\-lookaside \fIstring\fR trust\-anchor \fIstring\fR;
+	dnssec\-must\-be\-secure \fIstring\fR \fIboolean\fR;
 	dialup \fIdialuptype\fR;
-	ixfr-from-differences \fIixfrdiff\fR;
-
-	allow-query { \fIaddress_match_element\fR; ... };
-	allow-transfer { \fIaddress_match_element\fR; ... };
-	allow-update-forwarding { \fIaddress_match_element\fR; ... };
-
+	ixfr\-from\-differences \fIixfrdiff\fR;
+	allow\-query { \fIaddress_match_element\fR; ... };
+	allow\-transfer { \fIaddress_match_element\fR; ... };
+	allow\-update\-forwarding { \fIaddress_match_element\fR; ... };
 	notify \fInotifytype\fR;
-	notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
-	notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
-	also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
+	notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
+	notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
+	also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
 		[ port \fIinteger\fR ]; ... };
-	allow-notify { \fIaddress_match_element\fR; ... };
-
+	allow\-notify { \fIaddress_match_element\fR; ... };
 	forward ( first | only );
 	forwarders [ port \fIinteger\fR ] {
 		( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ...
 	};
-
-	max-journal-size \fIsize_no_default\fR;
-	max-transfer-time-in \fIinteger\fR;
-	max-transfer-time-out \fIinteger\fR;
-	max-transfer-idle-in \fIinteger\fR;
-	max-transfer-idle-out \fIinteger\fR;
-	max-retry-time \fIinteger\fR;
-	min-retry-time \fIinteger\fR;
-	max-refresh-time \fIinteger\fR;
-	min-refresh-time \fIinteger\fR;
-	multi-master \fIboolean\fR;
-	sig-validity-interval \fIinteger\fR;
-
-	transfer-source ( \fIipv4_address\fR | * )
+	max\-journal\-size \fIsize_no_default\fR;
+	max\-transfer\-time\-in \fIinteger\fR;
+	max\-transfer\-time\-out \fIinteger\fR;
+	max\-transfer\-idle\-in \fIinteger\fR;
+	max\-transfer\-idle\-out \fIinteger\fR;
+	max\-retry\-time \fIinteger\fR;
+	min\-retry\-time \fIinteger\fR;
+	max\-refresh\-time \fIinteger\fR;
+	min\-refresh\-time \fIinteger\fR;
+	multi\-master \fIboolean\fR;
+	sig\-validity\-interval \fIinteger\fR;
+	transfer\-source ( \fIipv4_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	transfer-source-v6 ( \fIipv6_address\fR | * )
+	transfer\-source\-v6 ( \fIipv6_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-
-	alt-transfer-source ( \fIipv4_address\fR | * )
+	alt\-transfer\-source ( \fIipv4_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	alt-transfer-source-v6 ( \fIipv6_address\fR | * )
+	alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	use-alt-transfer-source \fIboolean\fR;
-
-	zone-statistics \fIboolean\fR;
-	key-directory \fIquoted_string\fR;
-
-	allow-v6-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
-	fetch-glue \fIboolean\fR; // obsolete
-	maintain-ixfr-base \fIboolean\fR; // obsolete
-	max-ixfr-log-size \fIsize\fR; // obsolete
+	use\-alt\-transfer\-source \fIboolean\fR;
+	zone\-statistics \fIboolean\fR;
+	key\-directory \fIquoted_string\fR;
+	allow\-v6\-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
+	fetch\-glue \fIboolean\fR; // obsolete
+	maintain\-ixfr\-base \fIboolean\fR; // obsolete
+	max\-ixfr\-log\-size \fIsize\fR; // obsolete
 };
-.sp
 .fi
 .SH "ZONE"
 .sp
 .nf
 zone \fIstring\fR \fIoptional_class\fR {
 	type ( master | slave | stub | hint |
-		forward | delegation-only );
+		forward | delegation\-only );
 	file \fIquoted_string\fR;
-
 	masters [ port \fIinteger\fR ] {
 		( \fImasters\fR |
 		\fIipv4_address\fR [port \fIinteger\fR] |
 		\fIipv6_address\fR [ port \fIinteger\fR ] ) [ key \fIstring\fR ]; ...
 	};
-
 	database \fIstring\fR;
-	delegation-only \fIboolean\fR;
-	check-names ( fail | warn | ignore );
+	delegation\-only \fIboolean\fR;
+	check\-names ( fail | warn | ignore );
 	dialup \fIdialuptype\fR;
-	ixfr-from-differences \fIboolean\fR;
-
-	allow-query { \fIaddress_match_element\fR; ... };
-	allow-transfer { \fIaddress_match_element\fR; ... };
-	allow-update { \fIaddress_match_element\fR; ... };
-	allow-update-forwarding { \fIaddress_match_element\fR; ... };
-	update-policy {
+	ixfr\-from\-differences \fIboolean\fR;
+	allow\-query { \fIaddress_match_element\fR; ... };
+	allow\-transfer { \fIaddress_match_element\fR; ... };
+	allow\-update { \fIaddress_match_element\fR; ... };
+	allow\-update\-forwarding { \fIaddress_match_element\fR; ... };
+	update\-policy {
 		( grant | deny ) \fIstring\fR
 		( name | subdomain | wildcard | self ) \fIstring\fR
 		\fIrrtypelist\fR; ...
 	};
-
 	notify \fInotifytype\fR;
-	notify-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
-	notify-source-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
-	also-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
+	notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
+	notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
+	also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
 		[ port \fIinteger\fR ]; ... };
-	allow-notify { \fIaddress_match_element\fR; ... };
-
+	allow\-notify { \fIaddress_match_element\fR; ... };
 	forward ( first | only );
 	forwarders [ port \fIinteger\fR ] {
 		( \fIipv4_address\fR | \fIipv6_address\fR ) [ port \fIinteger\fR ]; ...
 	};
-
-	max-journal-size \fIsize_no_default\fR;
-	max-transfer-time-in \fIinteger\fR;
-	max-transfer-time-out \fIinteger\fR;
-	max-transfer-idle-in \fIinteger\fR;
-	max-transfer-idle-out \fIinteger\fR;
-	max-retry-time \fIinteger\fR;
-	min-retry-time \fIinteger\fR;
-	max-refresh-time \fIinteger\fR;
-	min-refresh-time \fIinteger\fR;
-	multi-master \fIboolean\fR;
-	sig-validity-interval \fIinteger\fR;
-
-	transfer-source ( \fIipv4_address\fR | * )
+	max\-journal\-size \fIsize_no_default\fR;
+	max\-transfer\-time\-in \fIinteger\fR;
+	max\-transfer\-time\-out \fIinteger\fR;
+	max\-transfer\-idle\-in \fIinteger\fR;
+	max\-transfer\-idle\-out \fIinteger\fR;
+	max\-retry\-time \fIinteger\fR;
+	min\-retry\-time \fIinteger\fR;
+	max\-refresh\-time \fIinteger\fR;
+	min\-refresh\-time \fIinteger\fR;
+	multi\-master \fIboolean\fR;
+	sig\-validity\-interval \fIinteger\fR;
+	transfer\-source ( \fIipv4_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	transfer-source-v6 ( \fIipv6_address\fR | * )
+	transfer\-source\-v6 ( \fIipv6_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-
-	alt-transfer-source ( \fIipv4_address\fR | * )
+	alt\-transfer\-source ( \fIipv4_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	alt-transfer-source-v6 ( \fIipv6_address\fR | * )
+	alt\-transfer\-source\-v6 ( \fIipv6_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
-	use-alt-transfer-source \fIboolean\fR;
-
-	zone-statistics \fIboolean\fR;
-	key-directory \fIquoted_string\fR;
-
-	ixfr-base \fIquoted_string\fR; // obsolete
-	ixfr-tmp-file \fIquoted_string\fR; // obsolete
-	maintain-ixfr-base \fIboolean\fR; // obsolete
-	max-ixfr-log-size \fIsize\fR; // obsolete
+	use\-alt\-transfer\-source \fIboolean\fR;
+	zone\-statistics \fIboolean\fR;
+	key\-directory \fIquoted_string\fR;
+	ixfr\-base \fIquoted_string\fR; // obsolete
+	ixfr\-tmp\-file \fIquoted_string\fR; // obsolete
+	maintain\-ixfr\-base \fIboolean\fR; // obsolete
+	max\-ixfr\-log\-size \fIsize\fR; // obsolete
 	pubkey \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; // obsolete
 };
-.sp
 .fi
 .SH "FILES"
 .PP
@@ -472,4 +435,4 @@ zone \fIstring\fR \fIoptional_class\fR {
 .PP
 \fBnamed\fR(8),
 \fBrndc\fR(8),
-\fBBIND 9 Adminstrators Reference Manual\fR.
+\fBBIND 9 Adminstrators Reference Manual\fR().
diff --git a/contrib/bind9/bin/named/named.conf.docbook b/contrib/bind9/bin/named/named.conf.docbook
index b5a71dcf1b3c..4ba10844cc32 100644
--- a/contrib/bind9/bin/named/named.conf.docbook
+++ b/contrib/bind9/bin/named/named.conf.docbook
@@ -1,6 +1,8 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -15,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: named.conf.docbook,v 1.1.4.2 2004/10/17 23:19:49 marka Exp $ -->
+<!-- $Id: named.conf.docbook,v 1.1.4.4 2005/05/13 01:22:33 marka Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -28,6 +30,14 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><filename>named.conf</filename></refname>
     <refpurpose>configuration file for named</refpurpose>
@@ -61,35 +71,35 @@
 
 <refsect1>
 <title>ACL</title>
-<LITERALLAYOUT>
+<literallayout>
 acl <replaceable>string</replaceable> { <replaceable>address_match_element</replaceable>; ... };
 
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>KEY</title>
-<LITERALLAYOUT>
+<literallayout>
 key <replaceable>domain_name</replaceable> {
 	algorithm <replaceable>string</replaceable>;
 	secret <replaceable>string</replaceable>;
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>MASTERS</title>
-<LITERALLAYOUT>
+<literallayout>
 masters <replaceable>string</replaceable> <optional> port <replaceable>integer</replaceable> </optional> {
 	( <replaceable>masters</replaceable> | <replaceable>ipv4_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> |
 	<replaceable>ipv6_address</replaceable> <optional>port <replaceable>integer</replaceable></optional> ) <optional> key <replaceable>string</replaceable> </optional>; ...
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>SERVER</title>
-<LITERALLAYOUT>
+<literallayout>
 server ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) {
 	bogus <replaceable>boolean</replaceable>;
 	edns <replaceable>boolean</replaceable>;
@@ -105,21 +115,21 @@ server ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</re
 
 	support-ixfr <replaceable>boolean</replaceable>; // obsolete
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>TRUSTED-KEYS</title>
-<LITERALLAYOUT>
+<literallayout>
 trusted-keys {
 	<replaceable>domain_name</replaceable> <replaceable>flags</replaceable> <replaceable>protocol</replaceable> <replaceable>algorithm</replaceable> <replaceable>key</replaceable>; ... 
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>CONTROLS</title>
-<LITERALLAYOUT>
+<literallayout>
 controls {
 	inet ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> | * )
 		<optional> port ( <replaceable>integer</replaceable> | * ) </optional>
@@ -127,12 +137,12 @@ controls {
 		<optional> keys { <replaceable>string</replaceable>; ... } </optional>;
 	unix <replaceable>unsupported</replaceable>; // not implemented
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>LOGGING</title>
-<LITERALLAYOUT>
+<literallayout>
 logging {
 	channel <replaceable>string</replaceable> {
 		file <replaceable>log_file</replaceable>;
@@ -146,12 +156,12 @@ logging {
 	};
 	category <replaceable>string</replaceable> { <replaceable>string</replaceable>; ... };
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>LWRES</title>
-<LITERALLAYOUT>
+<literallayout>
 lwres {
 	listen-on <optional> port <replaceable>integer</replaceable> </optional> {
 		( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> ) <optional> port <replaceable>integer</replaceable> </optional>; ...
@@ -160,12 +170,12 @@ lwres {
 	search { <replaceable>string</replaceable>; ... };
 	ndots <replaceable>integer</replaceable>;
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>OPTIONS</title>
-<LITERALLAYOUT>
+<literallayout>
 options {
 	avoid-v4-udp-ports { <replaceable>port</replaceable>; ... };
 	avoid-v6-udp-ports { <replaceable>port</replaceable>; ... };
@@ -304,12 +314,12 @@ options {
 	treat-cr-as-space <replaceable>boolean</replaceable>; // obsolete
 	use-id-pool <replaceable>boolean</replaceable>; // obsolete
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>VIEW</title>
-<LITERALLAYOUT>
+<literallayout>
 view <replaceable>string</replaceable> <replaceable>optional_class</replaceable> {
 	match-clients { <replaceable>address_match_element</replaceable>; ... };
 	match-destinations { <replaceable>address_match_element</replaceable>; ... };
@@ -423,12 +433,12 @@ view <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	maintain-ixfr-base <replaceable>boolean</replaceable>; // obsolete
 	max-ixfr-log-size <replaceable>size</replaceable>; // obsolete
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
 <title>ZONE</title>
-<LITERALLAYOUT>
+<literallayout>
 zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable> {
 	type ( master | slave | stub | hint |
 		forward | delegation-only );
@@ -500,7 +510,7 @@ zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	max-ixfr-log-size <replaceable>size</replaceable>; // obsolete
 	pubkey <replaceable>integer</replaceable> <replaceable>integer</replaceable> <replaceable>integer</replaceable> <replaceable>quoted_string</replaceable>; // obsolete
 };
-</LITERALLAYOUT>
+</literallayout>
 </refsect1>
 
 <refsect1>
diff --git a/contrib/bind9/bin/named/named.conf.html b/contrib/bind9/bin/named/named.conf.html
index 7f8bb2ec61f3..8b3b517d7d73 100644
--- a/contrib/bind9/bin/named/named.conf.html
+++ b/contrib/bind9/bin/named/named.conf.html
@@ -1,1897 +1,500 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: named.conf.html,v 1.1.4.4 2004/10/18 02:33:06 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->named.conf</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><TT
-CLASS="FILENAME"
->named.conf</TT
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><TT
-CLASS="FILENAME"
->named.conf</TT
->&nbsp;--&nbsp;configuration file for named</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->named.conf</B
-> </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN16"
-></A
-><H2
->DESCRIPTION</H2
-><P
->	<TT
-CLASS="FILENAME"
->named.conf</TT
-> is the configuration file for
-	<B
-CLASS="COMMAND"
->named</B
->.  Statements are enclosed
+<!-- $Id: named.conf.html,v 1.1.4.10 2005/10/13 02:33:48 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>named.conf</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><code class="filename">named.conf</code> &#8212; configuration file for named</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">named.conf</code> </p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525889"></a><h2>DESCRIPTION</h2>
+<p>
+	<code class="filename">named.conf</code> is the configuration file for
+	<span><strong class="command">named</strong></span>.  Statements are enclosed
 	in braces and terminated with a semi-colon.  Clauses in
 	the statements are also semi-colon terminated.  The usual
 	comment styles are supported:
-    </P
-><P
->	C style: /* */
-    </P
-><P
->	C++ style: // to end of line
-    </P
-><P
->	Unix style: # to end of line
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN24"
-></A
-><H2
->ACL</H2
-><P
-CLASS="LITERALLAYOUT"
->acl&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>&#13;</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN29"
-></A
-><H2
->KEY</H2
-><P
-CLASS="LITERALLAYOUT"
->key&nbsp;<VAR
-CLASS="REPLACEABLE"
->domain_name</VAR
->&nbsp;{<br>
-	algorithm&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
-	secret&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN35"
-></A
-><H2
->MASTERS</H2
-><P
-CLASS="LITERALLAYOUT"
->masters&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{<br>
-	(&nbsp;<VAR
-CLASS="REPLACEABLE"
->masters</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;|<br>
-	<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> key <VAR
-CLASS="REPLACEABLE"
->string</VAR
-> </SPAN
->];&nbsp;...<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN50"
-></A
-><H2
->SERVER</H2
-><P
-CLASS="LITERALLAYOUT"
->server&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)&nbsp;{<br>
-	bogus&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	edns&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	provide-ixfr&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	request-ixfr&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	keys&nbsp;<VAR
-CLASS="REPLACEABLE"
->server_key</VAR
->;<br>
-	transfers&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	transfer-format&nbsp;(&nbsp;many-answers&nbsp;|&nbsp;one-answer&nbsp;);<br>
-	transfer-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	transfer-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-<br>
-	support-ixfr&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN68"
-></A
-><H2
->TRUSTED-KEYS</H2
-><P
-CLASS="LITERALLAYOUT"
->trusted-keys&nbsp;{<br>
-	<VAR
-CLASS="REPLACEABLE"
->domain_name</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->flags</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->protocol</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->algorithm</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->key</VAR
->;&nbsp;...&nbsp;<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN76"
-></A
-><H2
->CONTROLS</H2
-><P
-CLASS="LITERALLAYOUT"
->controls&nbsp;{<br>
-	inet&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->]<br>
-		allow&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;}<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> keys { <VAR
-CLASS="REPLACEABLE"
->string</VAR
->; ... } </SPAN
->];<br>
-	unix&nbsp;<VAR
-CLASS="REPLACEABLE"
->unsupported</VAR
->;&nbsp;//&nbsp;not&nbsp;implemented<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN87"
-></A
-><H2
->LOGGING</H2
-><P
-CLASS="LITERALLAYOUT"
->logging&nbsp;{<br>
-	channel&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;{<br>
-		file&nbsp;<VAR
-CLASS="REPLACEABLE"
->log_file</VAR
->;<br>
-		syslog&nbsp;<VAR
-CLASS="REPLACEABLE"
->optional_facility</VAR
->;<br>
+    </p>
+<p>
+	C style: /* */
+    </p>
+<p>
+	C++ style: // to end of line
+    </p>
+<p>
+	Unix style: # to end of line
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525917"></a><h2>ACL</h2>
+<div class="literallayout"><p><br>
+acl <em class="replaceable"><code>string</code></em> { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525933"></a><h2>KEY</h2>
+<div class="literallayout"><p><br>
+key <em class="replaceable"><code>domain_name</code></em> {<br>
+	algorithm <em class="replaceable"><code>string</code></em>;<br>
+	secret <em class="replaceable"><code>string</code></em>;<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525953"></a><h2>MASTERS</h2>
+<div class="literallayout"><p><br>
+masters <em class="replaceable"><code>string</code></em> [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] {<br>
+	( <em class="replaceable"><code>masters</code></em> | <em class="replaceable"><code>ipv4_address</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] |<br>
+	<em class="replaceable"><code>ipv6_address</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] ) [<span class="optional"> key <em class="replaceable"><code>string</code></em> </span>]; ...<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525998"></a><h2>SERVER</h2>
+<div class="literallayout"><p><br>
+server ( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> ) {<br>
+	bogus <em class="replaceable"><code>boolean</code></em>;<br>
+	edns <em class="replaceable"><code>boolean</code></em>;<br>
+	provide-ixfr <em class="replaceable"><code>boolean</code></em>;<br>
+	request-ixfr <em class="replaceable"><code>boolean</code></em>;<br>
+	keys <em class="replaceable"><code>server_key</code></em>;<br>
+	transfers <em class="replaceable"><code>integer</code></em>;<br>
+	transfer-format ( many-answers | one-answer );<br>
+	transfer-source ( <em class="replaceable"><code>ipv4_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	transfer-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+<br>
+	support-ixfr <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526056"></a><h2>TRUSTED-KEYS</h2>
+<div class="literallayout"><p><br>
+trusted-keys {<br>
+	<em class="replaceable"><code>domain_name</code></em> <em class="replaceable"><code>flags</code></em> <em class="replaceable"><code>protocol</code></em> <em class="replaceable"><code>algorithm</code></em> <em class="replaceable"><code>key</code></em>; ... <br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526082"></a><h2>CONTROLS</h2>
+<div class="literallayout"><p><br>
+controls {<br>
+	inet ( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>]<br>
+		allow { <em class="replaceable"><code>address_match_element</code></em>; ... }<br>
+		[<span class="optional"> keys { <em class="replaceable"><code>string</code></em>; ... } </span>];<br>
+	unix <em class="replaceable"><code>unsupported</code></em>; // not implemented<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526117"></a><h2>LOGGING</h2>
+<div class="literallayout"><p><br>
+logging {<br>
+	channel <em class="replaceable"><code>string</code></em> {<br>
+		file <em class="replaceable"><code>log_file</code></em>;<br>
+		syslog <em class="replaceable"><code>optional_facility</code></em>;<br>
 		null;<br>
 		stderr;<br>
-		severity&nbsp;<VAR
-CLASS="REPLACEABLE"
->log_severity</VAR
->;<br>
-		print-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-		print-severity&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-		print-category&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
+		severity <em class="replaceable"><code>log_severity</code></em>;<br>
+		print-time <em class="replaceable"><code>boolean</code></em>;<br>
+		print-severity <em class="replaceable"><code>boolean</code></em>;<br>
+		print-category <em class="replaceable"><code>boolean</code></em>;<br>
 	};<br>
-	category&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;&nbsp;...&nbsp;};<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN99"
-></A
-><H2
->LWRES</H2
-><P
-CLASS="LITERALLAYOUT"
->lwres&nbsp;{<br>
-	listen-on&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{<br>
-		(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->];&nbsp;...<br>
+	category <em class="replaceable"><code>string</code></em> { <em class="replaceable"><code>string</code></em>; ... };<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526155"></a><h2>LWRES</h2>
+<div class="literallayout"><p><br>
+lwres {<br>
+	listen-on [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] {<br>
+		( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> ) [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>]; ...<br>
 	};<br>
-	view&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->optional_class</VAR
->;<br>
-	search&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;&nbsp;...&nbsp;};<br>
-	ndots&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN112"
-></A
-><H2
->OPTIONS</H2
-><P
-CLASS="LITERALLAYOUT"
->options&nbsp;{<br>
-	avoid-v4-udp-ports&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->port</VAR
->;&nbsp;...&nbsp;};<br>
-	avoid-v6-udp-ports&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->port</VAR
->;&nbsp;...&nbsp;};<br>
-	blackhole&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	coresize&nbsp;<VAR
-CLASS="REPLACEABLE"
->size</VAR
->;<br>
-	datasize&nbsp;<VAR
-CLASS="REPLACEABLE"
->size</VAR
->;<br>
-	directory&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	dump-file&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	files&nbsp;<VAR
-CLASS="REPLACEABLE"
->size</VAR
->;<br>
-	heartbeat-interval&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	host-statistics&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;not&nbsp;implemented<br>
-	host-statistics-max&nbsp;<VAR
-CLASS="REPLACEABLE"
->number</VAR
->;&nbsp;//&nbsp;not&nbsp;implemented<br>
-	hostname&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->&nbsp;|&nbsp;none&nbsp;);<br>
-	interface-interval&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	listen-on&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	listen-on-v6&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	match-mapped-addresses&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	memstatistics-file&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	pid-file&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->&nbsp;|&nbsp;none&nbsp;);<br>
-	port&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	querylog&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	recursing-file&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	random-device&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	recursive-clients&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	serial-query-rate&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	server-id&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->&nbsp;|&nbsp;none&nbsp;|;<br>
-	stacksize&nbsp;<VAR
-CLASS="REPLACEABLE"
->size</VAR
->;<br>
-	statistics-file&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	statistics-interval&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;&nbsp;//&nbsp;not&nbsp;yet&nbsp;implemented<br>
-	tcp-clients&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	tcp-listen-queue&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	tkey-dhkey&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	tkey-gssapi-credential&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	tkey-domain&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	transfers-per-ns&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	transfers-in&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	transfers-out&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	use-ixfr&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	version&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->&nbsp;|&nbsp;none&nbsp;);<br>
-	allow-recursion&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	sortlist&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	topology&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};&nbsp;//&nbsp;not&nbsp;implemented<br>
-	auth-nxdomain&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;default&nbsp;changed<br>
-	minimal-responses&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	recursion&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	rrset-order&nbsp;{<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> class <VAR
-CLASS="REPLACEABLE"
->string</VAR
-> </SPAN
->]&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> type <VAR
-CLASS="REPLACEABLE"
->string</VAR
-> </SPAN
->]<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> name <VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
-> </SPAN
->]&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;&nbsp;...<br>
+	view <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>optional_class</code></em>;<br>
+	search { <em class="replaceable"><code>string</code></em>; ... };<br>
+	ndots <em class="replaceable"><code>integer</code></em>;<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526197"></a><h2>OPTIONS</h2>
+<div class="literallayout"><p><br>
+options {<br>
+	avoid-v4-udp-ports { <em class="replaceable"><code>port</code></em>; ... };<br>
+	avoid-v6-udp-ports { <em class="replaceable"><code>port</code></em>; ... };<br>
+	blackhole { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	coresize <em class="replaceable"><code>size</code></em>;<br>
+	datasize <em class="replaceable"><code>size</code></em>;<br>
+	directory <em class="replaceable"><code>quoted_string</code></em>;<br>
+	dump-file <em class="replaceable"><code>quoted_string</code></em>;<br>
+	files <em class="replaceable"><code>size</code></em>;<br>
+	heartbeat-interval <em class="replaceable"><code>integer</code></em>;<br>
+	host-statistics <em class="replaceable"><code>boolean</code></em>; // not implemented<br>
+	host-statistics-max <em class="replaceable"><code>number</code></em>; // not implemented<br>
+	hostname ( <em class="replaceable"><code>quoted_string</code></em> | none );<br>
+	interface-interval <em class="replaceable"><code>integer</code></em>;<br>
+	listen-on [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	listen-on-v6 [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	match-mapped-addresses <em class="replaceable"><code>boolean</code></em>;<br>
+	memstatistics-file <em class="replaceable"><code>quoted_string</code></em>;<br>
+	pid-file ( <em class="replaceable"><code>quoted_string</code></em> | none );<br>
+	port <em class="replaceable"><code>integer</code></em>;<br>
+	querylog <em class="replaceable"><code>boolean</code></em>;<br>
+	recursing-file <em class="replaceable"><code>quoted_string</code></em>;<br>
+	random-device <em class="replaceable"><code>quoted_string</code></em>;<br>
+	recursive-clients <em class="replaceable"><code>integer</code></em>;<br>
+	serial-query-rate <em class="replaceable"><code>integer</code></em>;<br>
+	server-id ( <em class="replaceable"><code>quoted_string</code></em> | none |;<br>
+	stacksize <em class="replaceable"><code>size</code></em>;<br>
+	statistics-file <em class="replaceable"><code>quoted_string</code></em>;<br>
+	statistics-interval <em class="replaceable"><code>integer</code></em>; // not yet implemented<br>
+	tcp-clients <em class="replaceable"><code>integer</code></em>;<br>
+	tcp-listen-queue <em class="replaceable"><code>integer</code></em>;<br>
+	tkey-dhkey <em class="replaceable"><code>quoted_string</code></em> <em class="replaceable"><code>integer</code></em>;<br>
+	tkey-gssapi-credential <em class="replaceable"><code>quoted_string</code></em>;<br>
+	tkey-domain <em class="replaceable"><code>quoted_string</code></em>;<br>
+	transfers-per-ns <em class="replaceable"><code>integer</code></em>;<br>
+	transfers-in <em class="replaceable"><code>integer</code></em>;<br>
+	transfers-out <em class="replaceable"><code>integer</code></em>;<br>
+	use-ixfr <em class="replaceable"><code>boolean</code></em>;<br>
+	version ( <em class="replaceable"><code>quoted_string</code></em> | none );<br>
+	allow-recursion { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	sortlist { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	topology { <em class="replaceable"><code>address_match_element</code></em>; ... }; // not implemented<br>
+	auth-nxdomain <em class="replaceable"><code>boolean</code></em>; // default changed<br>
+	minimal-responses <em class="replaceable"><code>boolean</code></em>;<br>
+	recursion <em class="replaceable"><code>boolean</code></em>;<br>
+	rrset-order {<br>
+		[<span class="optional"> class <em class="replaceable"><code>string</code></em> </span>] [<span class="optional"> type <em class="replaceable"><code>string</code></em> </span>]<br>
+		[<span class="optional"> name <em class="replaceable"><code>quoted_string</code></em> </span>] <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>string</code></em>; ...<br>
 	};<br>
-	provide-ixfr&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	request-ixfr&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	rfc2308-type1&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;not&nbsp;yet&nbsp;implemented<br>
-	additional-from-auth&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	additional-from-cache&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	query-source&nbsp;<VAR
-CLASS="REPLACEABLE"
->querysource4</VAR
->;<br>
-	query-source-v6&nbsp;<VAR
-CLASS="REPLACEABLE"
->querysource6</VAR
->;<br>
-	cleaning-interval&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	min-roots&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;&nbsp;//&nbsp;not&nbsp;implemented<br>
-	lame-ttl&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-ncache-ttl&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-cache-ttl&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	transfer-format&nbsp;(&nbsp;many-answers&nbsp;|&nbsp;one-answer&nbsp;);<br>
-	max-cache-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->size_no_default</VAR
->;<br>
-	check-names&nbsp;(&nbsp;master&nbsp;|&nbsp;slave&nbsp;|&nbsp;response&nbsp;)<br>
-		(&nbsp;fail&nbsp;|&nbsp;warn&nbsp;|&nbsp;ignore&nbsp;);<br>
-	cache-file&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	suppress-initial-notify&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;not&nbsp;yet&nbsp;implemented<br>
-	preferred-glue&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
-	dual-stack-servers&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{<br>
-		(&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;|<br>
-		<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;|<br>
-		<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;);&nbsp;...<br>
+	provide-ixfr <em class="replaceable"><code>boolean</code></em>;<br>
+	request-ixfr <em class="replaceable"><code>boolean</code></em>;<br>
+	rfc2308-type1 <em class="replaceable"><code>boolean</code></em>; // not yet implemented<br>
+	additional-from-auth <em class="replaceable"><code>boolean</code></em>;<br>
+	additional-from-cache <em class="replaceable"><code>boolean</code></em>;<br>
+	query-source <em class="replaceable"><code>querysource4</code></em>;<br>
+	query-source-v6 <em class="replaceable"><code>querysource6</code></em>;<br>
+	cleaning-interval <em class="replaceable"><code>integer</code></em>;<br>
+	min-roots <em class="replaceable"><code>integer</code></em>; // not implemented<br>
+	lame-ttl <em class="replaceable"><code>integer</code></em>;<br>
+	max-ncache-ttl <em class="replaceable"><code>integer</code></em>;<br>
+	max-cache-ttl <em class="replaceable"><code>integer</code></em>;<br>
+	transfer-format ( many-answers | one-answer );<br>
+	max-cache-size <em class="replaceable"><code>size_no_default</code></em>;<br>
+	check-names ( master | slave | response )<br>
+		( fail | warn | ignore );<br>
+	cache-file <em class="replaceable"><code>quoted_string</code></em>;<br>
+	suppress-initial-notify <em class="replaceable"><code>boolean</code></em>; // not yet implemented<br>
+	preferred-glue <em class="replaceable"><code>string</code></em>;<br>
+	dual-stack-servers [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] {<br>
+		( <em class="replaceable"><code>quoted_string</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] |<br>
+		<em class="replaceable"><code>ipv4_address</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] |<br>
+		<em class="replaceable"><code>ipv6_address</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] ); ...<br>
 	}<br>
-	edns-udp-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	root-delegation-only&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> exclude { <VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->; ... } </SPAN
->];<br>
-	disable-algorithms&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;&nbsp;...&nbsp;};<br>
-	dnssec-enable&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	dnssec-lookaside&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;trust-anchor&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
-	dnssec-must-be-secure&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-<br>
-	dialup&nbsp;<VAR
-CLASS="REPLACEABLE"
->dialuptype</VAR
->;<br>
-	ixfr-from-differences&nbsp;<VAR
-CLASS="REPLACEABLE"
->ixfrdiff</VAR
->;<br>
-<br>
-	allow-query&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	allow-transfer&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	allow-update-forwarding&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-<br>
-	notify&nbsp;<VAR
-CLASS="REPLACEABLE"
->notifytype</VAR
->;<br>
-	notify-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	notify-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	also-notify&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->];&nbsp;...&nbsp;};<br>
-	allow-notify&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-<br>
-	forward&nbsp;(&nbsp;first&nbsp;|&nbsp;only&nbsp;);<br>
-	forwarders&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{<br>
-		(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->];&nbsp;...<br>
+	edns-udp-size <em class="replaceable"><code>integer</code></em>;<br>
+	root-delegation-only [<span class="optional"> exclude { <em class="replaceable"><code>quoted_string</code></em>; ... } </span>];<br>
+	disable-algorithms <em class="replaceable"><code>string</code></em> { <em class="replaceable"><code>string</code></em>; ... };<br>
+	dnssec-enable <em class="replaceable"><code>boolean</code></em>;<br>
+	dnssec-lookaside <em class="replaceable"><code>string</code></em> trust-anchor <em class="replaceable"><code>string</code></em>;<br>
+	dnssec-must-be-secure <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>boolean</code></em>;<br>
+<br>
+	dialup <em class="replaceable"><code>dialuptype</code></em>;<br>
+	ixfr-from-differences <em class="replaceable"><code>ixfrdiff</code></em>;<br>
+<br>
+	allow-query { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-transfer { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-update-forwarding { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+<br>
+	notify <em class="replaceable"><code>notifytype</code></em>;<br>
+	notify-source ( <em class="replaceable"><code>ipv4_address</code></em> | * ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	notify-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	also-notify [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] { ( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> )<br>
+		[<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>]; ... };<br>
+	allow-notify { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+<br>
+	forward ( first | only );<br>
+	forwarders [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] {<br>
+		( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> ) [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>]; ...<br>
 	};<br>
 <br>
-	max-journal-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->size_no_default</VAR
->;<br>
-	max-transfer-time-in&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-time-out&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-idle-in&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-idle-out&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-retry-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	min-retry-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-refresh-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	min-refresh-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	multi-master&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	sig-validity-interval&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-<br>
-	transfer-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	transfer-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-<br>
-	alt-transfer-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	alt-transfer-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	use-alt-transfer-source&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-<br>
-	zone-statistics&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	key-directory&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-<br>
-	allow-v6-synthesis&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};&nbsp;//&nbsp;obsolete<br>
-	deallocate-on-exit&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	fake-iquery&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	fetch-glue&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	has-old-clients&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	maintain-ixfr-base&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	max-ixfr-log-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->size</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	multiple-cnames&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	named-xfer&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	serial-queries&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	treat-cr-as-space&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	use-id-pool&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN272"
-></A
-><H2
->VIEW</H2
-><P
-CLASS="LITERALLAYOUT"
->view&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->optional_class</VAR
->&nbsp;{<br>
-	match-clients&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	match-destinations&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	match-recursive-only&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-<br>
-	key&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;{<br>
-		algorithm&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
-		secret&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
+	max-journal-size <em class="replaceable"><code>size_no_default</code></em>;<br>
+	max-transfer-time-in <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-time-out <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-idle-in <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-idle-out <em class="replaceable"><code>integer</code></em>;<br>
+	max-retry-time <em class="replaceable"><code>integer</code></em>;<br>
+	min-retry-time <em class="replaceable"><code>integer</code></em>;<br>
+	max-refresh-time <em class="replaceable"><code>integer</code></em>;<br>
+	min-refresh-time <em class="replaceable"><code>integer</code></em>;<br>
+	multi-master <em class="replaceable"><code>boolean</code></em>;<br>
+	sig-validity-interval <em class="replaceable"><code>integer</code></em>;<br>
+<br>
+	transfer-source ( <em class="replaceable"><code>ipv4_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	transfer-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+<br>
+	alt-transfer-source ( <em class="replaceable"><code>ipv4_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	alt-transfer-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	use-alt-transfer-source <em class="replaceable"><code>boolean</code></em>;<br>
+<br>
+	zone-statistics <em class="replaceable"><code>boolean</code></em>;<br>
+	key-directory <em class="replaceable"><code>quoted_string</code></em>;<br>
+<br>
+	allow-v6-synthesis { <em class="replaceable"><code>address_match_element</code></em>; ... }; // obsolete<br>
+	deallocate-on-exit <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	fake-iquery <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	fetch-glue <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	has-old-clients <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	maintain-ixfr-base <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	max-ixfr-log-size <em class="replaceable"><code>size</code></em>; // obsolete<br>
+	multiple-cnames <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	named-xfer <em class="replaceable"><code>quoted_string</code></em>; // obsolete<br>
+	serial-queries <em class="replaceable"><code>integer</code></em>; // obsolete<br>
+	treat-cr-as-space <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	use-id-pool <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526858"></a><h2>VIEW</h2>
+<div class="literallayout"><p><br>
+view <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>optional_class</code></em> {<br>
+	match-clients { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	match-destinations { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	match-recursive-only <em class="replaceable"><code>boolean</code></em>;<br>
+<br>
+	key <em class="replaceable"><code>string</code></em> {<br>
+		algorithm <em class="replaceable"><code>string</code></em>;<br>
+		secret <em class="replaceable"><code>string</code></em>;<br>
 	};<br>
 <br>
-	zone&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->optional_class</VAR
->&nbsp;{<br>
+	zone <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>optional_class</code></em> {<br>
 		...<br>
 	};<br>
 <br>
-	server&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)&nbsp;{<br>
+	server ( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> ) {<br>
 		...<br>
 	};<br>
 <br>
-	trusted-keys&nbsp;{<br>
-		<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;&nbsp;...<br>
+	trusted-keys {<br>
+		<em class="replaceable"><code>string</code></em> <em class="replaceable"><code>integer</code></em> <em class="replaceable"><code>integer</code></em> <em class="replaceable"><code>integer</code></em> <em class="replaceable"><code>quoted_string</code></em>; ...<br>
 	};<br>
 <br>
-	allow-recursion&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	sortlist&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	topology&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};&nbsp;//&nbsp;not&nbsp;implemented<br>
-	auth-nxdomain&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;default&nbsp;changed<br>
-	minimal-responses&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	recursion&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	rrset-order&nbsp;{<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> class <VAR
-CLASS="REPLACEABLE"
->string</VAR
-> </SPAN
->]&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> type <VAR
-CLASS="REPLACEABLE"
->string</VAR
-> </SPAN
->]<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> name <VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
-> </SPAN
->]&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;&nbsp;...<br>
+	allow-recursion { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	sortlist { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	topology { <em class="replaceable"><code>address_match_element</code></em>; ... }; // not implemented<br>
+	auth-nxdomain <em class="replaceable"><code>boolean</code></em>; // default changed<br>
+	minimal-responses <em class="replaceable"><code>boolean</code></em>;<br>
+	recursion <em class="replaceable"><code>boolean</code></em>;<br>
+	rrset-order {<br>
+		[<span class="optional"> class <em class="replaceable"><code>string</code></em> </span>] [<span class="optional"> type <em class="replaceable"><code>string</code></em> </span>]<br>
+		[<span class="optional"> name <em class="replaceable"><code>quoted_string</code></em> </span>] <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>string</code></em>; ...<br>
 	};<br>
-	provide-ixfr&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	request-ixfr&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	rfc2308-type1&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;not&nbsp;yet&nbsp;implemented<br>
-	additional-from-auth&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	additional-from-cache&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	query-source&nbsp;<VAR
-CLASS="REPLACEABLE"
->querysource4</VAR
->;<br>
-	query-source-v6&nbsp;<VAR
-CLASS="REPLACEABLE"
->querysource6</VAR
->;<br>
-	cleaning-interval&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	min-roots&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;&nbsp;//&nbsp;not&nbsp;implemented<br>
-	lame-ttl&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-ncache-ttl&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-cache-ttl&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	transfer-format&nbsp;(&nbsp;many-answers&nbsp;|&nbsp;one-answer&nbsp;);<br>
-	max-cache-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->size_no_default</VAR
->;<br>
-	check-names&nbsp;(&nbsp;master&nbsp;|&nbsp;slave&nbsp;|&nbsp;response&nbsp;)<br>
-		(&nbsp;fail&nbsp;|&nbsp;warn&nbsp;|&nbsp;ignore&nbsp;);<br>
-	cache-file&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-	suppress-initial-notify&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;not&nbsp;yet&nbsp;implemented<br>
-	preferred-glue&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
-	dual-stack-servers&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{<br>
-		(&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;|<br>
-		<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;|<br>
-		<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;);&nbsp;...<br>
+	provide-ixfr <em class="replaceable"><code>boolean</code></em>;<br>
+	request-ixfr <em class="replaceable"><code>boolean</code></em>;<br>
+	rfc2308-type1 <em class="replaceable"><code>boolean</code></em>; // not yet implemented<br>
+	additional-from-auth <em class="replaceable"><code>boolean</code></em>;<br>
+	additional-from-cache <em class="replaceable"><code>boolean</code></em>;<br>
+	query-source <em class="replaceable"><code>querysource4</code></em>;<br>
+	query-source-v6 <em class="replaceable"><code>querysource6</code></em>;<br>
+	cleaning-interval <em class="replaceable"><code>integer</code></em>;<br>
+	min-roots <em class="replaceable"><code>integer</code></em>; // not implemented<br>
+	lame-ttl <em class="replaceable"><code>integer</code></em>;<br>
+	max-ncache-ttl <em class="replaceable"><code>integer</code></em>;<br>
+	max-cache-ttl <em class="replaceable"><code>integer</code></em>;<br>
+	transfer-format ( many-answers | one-answer );<br>
+	max-cache-size <em class="replaceable"><code>size_no_default</code></em>;<br>
+	check-names ( master | slave | response )<br>
+		( fail | warn | ignore );<br>
+	cache-file <em class="replaceable"><code>quoted_string</code></em>;<br>
+	suppress-initial-notify <em class="replaceable"><code>boolean</code></em>; // not yet implemented<br>
+	preferred-glue <em class="replaceable"><code>string</code></em>;<br>
+	dual-stack-servers [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] {<br>
+		( <em class="replaceable"><code>quoted_string</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] |<br>
+		<em class="replaceable"><code>ipv4_address</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] |<br>
+		<em class="replaceable"><code>ipv6_address</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] ); ...<br>
 	};<br>
-	edns-udp-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	root-delegation-only&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> exclude { <VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->; ... } </SPAN
->];<br>
-	disable-algorithms&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;&nbsp;...&nbsp;};<br>
-	dnssec-enable&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	dnssec-lookaside&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;trust-anchor&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
-<br>
-	dnssec-must-be-secure&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	dialup&nbsp;<VAR
-CLASS="REPLACEABLE"
->dialuptype</VAR
->;<br>
-	ixfr-from-differences&nbsp;<VAR
-CLASS="REPLACEABLE"
->ixfrdiff</VAR
->;<br>
-<br>
-	allow-query&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	allow-transfer&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	allow-update-forwarding&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-<br>
-	notify&nbsp;<VAR
-CLASS="REPLACEABLE"
->notifytype</VAR
->;<br>
-	notify-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	notify-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	also-notify&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->];&nbsp;...&nbsp;};<br>
-	allow-notify&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-<br>
-	forward&nbsp;(&nbsp;first&nbsp;|&nbsp;only&nbsp;);<br>
-	forwarders&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{<br>
-		(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->];&nbsp;...<br>
+	edns-udp-size <em class="replaceable"><code>integer</code></em>;<br>
+	root-delegation-only [<span class="optional"> exclude { <em class="replaceable"><code>quoted_string</code></em>; ... } </span>];<br>
+	disable-algorithms <em class="replaceable"><code>string</code></em> { <em class="replaceable"><code>string</code></em>; ... };<br>
+	dnssec-enable <em class="replaceable"><code>boolean</code></em>;<br>
+	dnssec-lookaside <em class="replaceable"><code>string</code></em> trust-anchor <em class="replaceable"><code>string</code></em>;<br>
+<br>
+	dnssec-must-be-secure <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>boolean</code></em>;<br>
+	dialup <em class="replaceable"><code>dialuptype</code></em>;<br>
+	ixfr-from-differences <em class="replaceable"><code>ixfrdiff</code></em>;<br>
+<br>
+	allow-query { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-transfer { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-update-forwarding { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+<br>
+	notify <em class="replaceable"><code>notifytype</code></em>;<br>
+	notify-source ( <em class="replaceable"><code>ipv4_address</code></em> | * ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	notify-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	also-notify [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] { ( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> )<br>
+		[<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>]; ... };<br>
+	allow-notify { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+<br>
+	forward ( first | only );<br>
+	forwarders [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] {<br>
+		( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> ) [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>]; ...<br>
 	};<br>
 <br>
-	max-journal-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->size_no_default</VAR
->;<br>
-	max-transfer-time-in&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-time-out&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-idle-in&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-idle-out&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-retry-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	min-retry-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-refresh-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	min-refresh-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	multi-master&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	sig-validity-interval&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-<br>
-	transfer-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	transfer-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-<br>
-	alt-transfer-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	alt-transfer-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	use-alt-transfer-source&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-<br>
-	zone-statistics&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	key-directory&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-<br>
-	allow-v6-synthesis&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};&nbsp;//&nbsp;obsolete<br>
-	fetch-glue&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	maintain-ixfr-base&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	max-ixfr-log-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->size</VAR
->;&nbsp;//&nbsp;obsolete<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN398"
-></A
-><H2
->ZONE</H2
-><P
-CLASS="LITERALLAYOUT"
->zone&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->optional_class</VAR
->&nbsp;{<br>
-	type&nbsp;(&nbsp;master&nbsp;|&nbsp;slave&nbsp;|&nbsp;stub&nbsp;|&nbsp;hint&nbsp;|<br>
-		forward&nbsp;|&nbsp;delegation-only&nbsp;);<br>
-	file&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-<br>
-	masters&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{<br>
-		(&nbsp;<VAR
-CLASS="REPLACEABLE"
->masters</VAR
->&nbsp;|<br>
-		<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
->port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-></SPAN
->]&nbsp;|<br>
-		<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> key <VAR
-CLASS="REPLACEABLE"
->string</VAR
-> </SPAN
->];&nbsp;...<br>
+	max-journal-size <em class="replaceable"><code>size_no_default</code></em>;<br>
+	max-transfer-time-in <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-time-out <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-idle-in <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-idle-out <em class="replaceable"><code>integer</code></em>;<br>
+	max-retry-time <em class="replaceable"><code>integer</code></em>;<br>
+	min-retry-time <em class="replaceable"><code>integer</code></em>;<br>
+	max-refresh-time <em class="replaceable"><code>integer</code></em>;<br>
+	min-refresh-time <em class="replaceable"><code>integer</code></em>;<br>
+	multi-master <em class="replaceable"><code>boolean</code></em>;<br>
+	sig-validity-interval <em class="replaceable"><code>integer</code></em>;<br>
+<br>
+	transfer-source ( <em class="replaceable"><code>ipv4_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	transfer-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+<br>
+	alt-transfer-source ( <em class="replaceable"><code>ipv4_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	alt-transfer-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	use-alt-transfer-source <em class="replaceable"><code>boolean</code></em>;<br>
+<br>
+	zone-statistics <em class="replaceable"><code>boolean</code></em>;<br>
+	key-directory <em class="replaceable"><code>quoted_string</code></em>;<br>
+<br>
+	allow-v6-synthesis { <em class="replaceable"><code>address_match_element</code></em>; ... }; // obsolete<br>
+	fetch-glue <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	maintain-ixfr-base <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	max-ixfr-log-size <em class="replaceable"><code>size</code></em>; // obsolete<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2527269"></a><h2>ZONE</h2>
+<div class="literallayout"><p><br>
+zone <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>optional_class</code></em> {<br>
+	type ( master | slave | stub | hint |<br>
+		forward | delegation-only );<br>
+	file <em class="replaceable"><code>quoted_string</code></em>;<br>
+<br>
+	masters [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] {<br>
+		( <em class="replaceable"><code>masters</code></em> |<br>
+		<em class="replaceable"><code>ipv4_address</code></em> [<span class="optional">port <em class="replaceable"><code>integer</code></em></span>] |<br>
+		<em class="replaceable"><code>ipv6_address</code></em> [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] ) [<span class="optional"> key <em class="replaceable"><code>string</code></em> </span>]; ...<br>
 	};<br>
 <br>
-	database&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
->;<br>
-	delegation-only&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	check-names&nbsp;(&nbsp;fail&nbsp;|&nbsp;warn&nbsp;|&nbsp;ignore&nbsp;);<br>
-	dialup&nbsp;<VAR
-CLASS="REPLACEABLE"
->dialuptype</VAR
->;<br>
-	ixfr-from-differences&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-<br>
-	allow-query&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	allow-transfer&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	allow-update&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	allow-update-forwarding&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
-	update-policy&nbsp;{<br>
-		(&nbsp;grant&nbsp;|&nbsp;deny&nbsp;)&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
-><br>
-		(&nbsp;name&nbsp;|&nbsp;subdomain&nbsp;|&nbsp;wildcard&nbsp;|&nbsp;self&nbsp;)&nbsp;<VAR
-CLASS="REPLACEABLE"
->string</VAR
-><br>
-		<VAR
-CLASS="REPLACEABLE"
->rrtypelist</VAR
->;&nbsp;...<br>
+	database <em class="replaceable"><code>string</code></em>;<br>
+	delegation-only <em class="replaceable"><code>boolean</code></em>;<br>
+	check-names ( fail | warn | ignore );<br>
+	dialup <em class="replaceable"><code>dialuptype</code></em>;<br>
+	ixfr-from-differences <em class="replaceable"><code>boolean</code></em>;<br>
+<br>
+	allow-query { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-transfer { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-update { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-update-forwarding { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	update-policy {<br>
+		( grant | deny ) <em class="replaceable"><code>string</code></em><br>
+		( name | subdomain | wildcard | self ) <em class="replaceable"><code>string</code></em><br>
+		<em class="replaceable"><code>rrtypelist</code></em>; ...<br>
 	};<br>
 <br>
-	notify&nbsp;<VAR
-CLASS="REPLACEABLE"
->notifytype</VAR
->;<br>
-	notify-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	notify-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	also-notify&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->];&nbsp;...&nbsp;};<br>
-	allow-notify&nbsp;{&nbsp;<VAR
-CLASS="REPLACEABLE"
->address_match_element</VAR
->;&nbsp;...&nbsp;};<br>
+	notify <em class="replaceable"><code>notifytype</code></em>;<br>
+	notify-source ( <em class="replaceable"><code>ipv4_address</code></em> | * ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	notify-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	also-notify [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] { ( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> )<br>
+		[<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>]; ... };<br>
+	allow-notify { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
 <br>
-	forward&nbsp;(&nbsp;first&nbsp;|&nbsp;only&nbsp;);<br>
-	forwarders&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->]&nbsp;{<br>
-		(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;)&nbsp;[<SPAN
-CLASS="OPTIONAL"
-> port <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> </SPAN
->];&nbsp;...<br>
+	forward ( first | only );<br>
+	forwarders [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>] {<br>
+		( <em class="replaceable"><code>ipv4_address</code></em> | <em class="replaceable"><code>ipv6_address</code></em> ) [<span class="optional"> port <em class="replaceable"><code>integer</code></em> </span>]; ...<br>
 	};<br>
 <br>
-	max-journal-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->size_no_default</VAR
->;<br>
-	max-transfer-time-in&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-time-out&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-idle-in&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-transfer-idle-out&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-retry-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	min-retry-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	max-refresh-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	min-refresh-time&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-	multi-master&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	sig-validity-interval&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->;<br>
-<br>
-	transfer-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	transfer-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-<br>
-	alt-transfer-source&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv4_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	alt-transfer-source-v6&nbsp;(&nbsp;<VAR
-CLASS="REPLACEABLE"
->ipv6_address</VAR
->&nbsp;|&nbsp;*&nbsp;)<br>
-		[<SPAN
-CLASS="OPTIONAL"
-> port ( <VAR
-CLASS="REPLACEABLE"
->integer</VAR
-> | * ) </SPAN
->];<br>
-	use-alt-transfer-source&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-<br>
-	zone-statistics&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;<br>
-	key-directory&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;<br>
-<br>
-	ixfr-base&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	ixfr-tmp-file&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	maintain-ixfr-base&nbsp;<VAR
-CLASS="REPLACEABLE"
->boolean</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	max-ixfr-log-size&nbsp;<VAR
-CLASS="REPLACEABLE"
->size</VAR
->;&nbsp;//&nbsp;obsolete<br>
-	pubkey&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->integer</VAR
->&nbsp;<VAR
-CLASS="REPLACEABLE"
->quoted_string</VAR
->;&nbsp;//&nbsp;obsolete<br>
-};</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN480"
-></A
-><H2
->FILES</H2
-><P
-><TT
-CLASS="FILENAME"
->/etc/named.conf</TT
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN484"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->rndc</SPAN
->(8)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->BIND 9 Adminstrators Reference Manual</SPAN
-></SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+	max-journal-size <em class="replaceable"><code>size_no_default</code></em>;<br>
+	max-transfer-time-in <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-time-out <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-idle-in <em class="replaceable"><code>integer</code></em>;<br>
+	max-transfer-idle-out <em class="replaceable"><code>integer</code></em>;<br>
+	max-retry-time <em class="replaceable"><code>integer</code></em>;<br>
+	min-retry-time <em class="replaceable"><code>integer</code></em>;<br>
+	max-refresh-time <em class="replaceable"><code>integer</code></em>;<br>
+	min-refresh-time <em class="replaceable"><code>integer</code></em>;<br>
+	multi-master <em class="replaceable"><code>boolean</code></em>;<br>
+	sig-validity-interval <em class="replaceable"><code>integer</code></em>;<br>
+<br>
+	transfer-source ( <em class="replaceable"><code>ipv4_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	transfer-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+<br>
+	alt-transfer-source ( <em class="replaceable"><code>ipv4_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	alt-transfer-source-v6 ( <em class="replaceable"><code>ipv6_address</code></em> | * )<br>
+		[<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	use-alt-transfer-source <em class="replaceable"><code>boolean</code></em>;<br>
+<br>
+	zone-statistics <em class="replaceable"><code>boolean</code></em>;<br>
+	key-directory <em class="replaceable"><code>quoted_string</code></em>;<br>
+<br>
+	ixfr-base <em class="replaceable"><code>quoted_string</code></em>; // obsolete<br>
+	ixfr-tmp-file <em class="replaceable"><code>quoted_string</code></em>; // obsolete<br>
+	maintain-ixfr-base <em class="replaceable"><code>boolean</code></em>; // obsolete<br>
+	max-ixfr-log-size <em class="replaceable"><code>size</code></em>; // obsolete<br>
+	pubkey <em class="replaceable"><code>integer</code></em> <em class="replaceable"><code>integer</code></em> <em class="replaceable"><code>integer</code></em> <em class="replaceable"><code>quoted_string</code></em>; // obsolete<br>
+};<br>
+</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2527606"></a><h2>FILES</h2>
+<p>
+<code class="filename">/etc/named.conf</code>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2527619"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+<span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
+<span class="citerefentry"><span class="refentrytitle">BIND 9 Adminstrators Reference Manual</span></span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/named/named.docbook b/contrib/bind9/bin/named/named.docbook
index 754f1a07c141..47ccf54b38e8 100644
--- a/contrib/bind9/bin/named/named.docbook
+++ b/contrib/bind9/bin/named/named.docbook
@@ -1,6 +1,8 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: named.docbook,v 1.5.98.3 2004/06/03 02:24:57 marka Exp $ -->
+<!-- $Id: named.docbook,v 1.5.98.5 2005/05/13 01:22:33 marka Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,20 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><application>named</application></refname>
     <refpurpose>Internet domain name server</refpurpose>
diff --git a/contrib/bind9/bin/named/named.html b/contrib/bind9/bin/named/named.html
index 8ee16e684f1d..f266e70af554 100644
--- a/contrib/bind9/bin/named/named.html
+++ b/contrib/bind9/bin/named/named.html
@@ -1,625 +1,240 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: named.html,v 1.4.2.1.4.4 2004/08/22 23:38:59 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->named</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><SPAN
-CLASS="APPLICATION"
->named</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->named</SPAN
->&nbsp;--&nbsp;Internet domain name server</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->named</B
->  [<VAR
-CLASS="OPTION"
->-4</VAR
->] [<VAR
-CLASS="OPTION"
->-6</VAR
->] [<VAR
-CLASS="OPTION"
->-c <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-d <VAR
-CLASS="REPLACEABLE"
->debug-level</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-f</VAR
->] [<VAR
-CLASS="OPTION"
->-g</VAR
->] [<VAR
-CLASS="OPTION"
->-n <VAR
-CLASS="REPLACEABLE"
->#cpus</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-p <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-s</VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-u <VAR
-CLASS="REPLACEABLE"
->user</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-v</VAR
->] [<VAR
-CLASS="OPTION"
->-x <VAR
-CLASS="REPLACEABLE"
->cache-file</VAR
-></VAR
->]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN49"
-></A
-><H2
->DESCRIPTION</H2
-><P
->	<B
-CLASS="COMMAND"
->named</B
-> is a Domain Name System (DNS) server,
+<!-- $Id: named.html,v 1.4.2.1.4.9 2005/10/13 02:33:47 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>named</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">named</span> &#8212; Internet domain name server</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">named</code>  [<code class="option">-4</code>] [<code class="option">-6</code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>] [<code class="option">-x <em class="replaceable"><code>cache-file</code></em></code>]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525923"></a><h2>DESCRIPTION</h2>
+<p>
+	<span><strong class="command">named</strong></span> is a Domain Name System (DNS) server,
 	part of the BIND 9 distribution from ISC.  For more
 	information on the DNS, see RFCs 1033, 1034, and 1035.
-    </P
-><P
->	When invoked without arguments, <B
-CLASS="COMMAND"
->named</B
-> will
+    </p>
+<p>
+	When invoked without arguments, <span><strong class="command">named</strong></span> will
 	read the default configuration file
-	<TT
-CLASS="FILENAME"
->/etc/named.conf</TT
->, read any initial
+	<code class="filename">/etc/named.conf</code>, read any initial
 	data, and listen for queries.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN56"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-4</DT
-><DD
-><P
->		Use IPv4 only even if the host machine is capable of IPv6.
-		<VAR
-CLASS="OPTION"
->-4</VAR
-> and <VAR
-CLASS="OPTION"
->-6</VAR
-> are mutually
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525948"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-4</span></dt>
+<dd><p>
+		Use IPv4 only even if the host machine is capable of IPv6.
+		<code class="option">-4</code> and <code class="option">-6</code> are mutually
 		exclusive.
-          </P
-></DD
-><DT
->-6</DT
-><DD
-><P
->		Use IPv6 only even if the host machine is capable of IPv4.
-		<VAR
-CLASS="OPTION"
->-4</VAR
-> and <VAR
-CLASS="OPTION"
->-6</VAR
-> are mutually
+          </p></dd>
+<dt><span class="term">-6</span></dt>
+<dd><p>
+		Use IPv6 only even if the host machine is capable of IPv4.
+		<code class="option">-4</code> and <code class="option">-6</code> are mutually
 		exclusive.
-          </P
-></DD
-><DT
->-c <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-></DT
-><DD
-><P
->		Use <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-> as the
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>config-file</code></em></span></dt>
+<dd><p>
+		Use <em class="replaceable"><code>config-file</code></em> as the
 		configuration file instead of the default,
-		<TT
-CLASS="FILENAME"
->/etc/named.conf</TT
->.  To
+		<code class="filename">/etc/named.conf</code>.  To
 		ensure that reloading the configuration file continues
 		to work after the server has changed its working
 		directory due to to a possible
-		<VAR
-CLASS="OPTION"
->directory</VAR
-> option in the configuration
-		file, <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-> should be
+		<code class="option">directory</code> option in the configuration
+		file, <em class="replaceable"><code>config-file</code></em> should be
 		an absolute pathname.
-          </P
-></DD
-><DT
->-d <VAR
-CLASS="REPLACEABLE"
->debug-level</VAR
-></DT
-><DD
-><P
->		Set the daemon's debug level to <VAR
-CLASS="REPLACEABLE"
->debug-level</VAR
->.
-		Debugging traces from <B
-CLASS="COMMAND"
->named</B
-> become
+          </p></dd>
+<dt><span class="term">-d <em class="replaceable"><code>debug-level</code></em></span></dt>
+<dd><p>
+		Set the daemon's debug level to <em class="replaceable"><code>debug-level</code></em>.
+		Debugging traces from <span><strong class="command">named</strong></span> become
 		more verbose as the debug level increases.
-          </P
-></DD
-><DT
->-f</DT
-><DD
-><P
->		Run the server in the foreground (i.e. do not daemonize).
-          </P
-></DD
-><DT
->-g</DT
-><DD
-><P
->		Run the server in the foreground and force all logging
-		to <TT
-CLASS="FILENAME"
->stderr</TT
->.
-          </P
-></DD
-><DT
->-n <VAR
-CLASS="REPLACEABLE"
->#cpus</VAR
-></DT
-><DD
-><P
->		Create <VAR
-CLASS="REPLACEABLE"
->#cpus</VAR
-> worker threads
+          </p></dd>
+<dt><span class="term">-f</span></dt>
+<dd><p>
+		Run the server in the foreground (i.e. do not daemonize).
+          </p></dd>
+<dt><span class="term">-g</span></dt>
+<dd><p>
+		Run the server in the foreground and force all logging
+		to <code class="filename">stderr</code>.
+          </p></dd>
+<dt><span class="term">-n <em class="replaceable"><code>#cpus</code></em></span></dt>
+<dd><p>
+		Create <em class="replaceable"><code>#cpus</code></em> worker threads
 		to take advantage of multiple CPUs.  If not specified,
-		<B
-CLASS="COMMAND"
->named</B
-> will try to determine the
+		<span><strong class="command">named</strong></span> will try to determine the
 		number of CPUs present and create one thread per CPU.
 		If it is unable to determine the number of CPUs, a
 		single worker thread will be created.
-          </P
-></DD
-><DT
->-p <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></DT
-><DD
-><P
->		Listen for queries on port <VAR
-CLASS="REPLACEABLE"
->port</VAR
->.  If not
+          </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
+<dd><p>
+		Listen for queries on port <em class="replaceable"><code>port</code></em>.  If not
 		specified, the default is port 53.
-          </P
-></DD
-><DT
->-s</DT
-><DD
-><P
->		Write memory usage statistics to <TT
-CLASS="FILENAME"
->stdout</TT
-> on exit.
-          </P
-><DIV
-CLASS="NOTE"
-><BLOCKQUOTE
-CLASS="NOTE"
-><P
-><B
->Note: </B
->		This option is mainly of interest to BIND 9 developers
+          </p></dd>
+<dt><span class="term">-s</span></dt>
+<dd>
+<p>
+		Write memory usage statistics to <code class="filename">stdout</code> on exit.
+          </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+		This option is mainly of interest to BIND 9 developers
 		and may be removed or changed in a future release.
-	    </P
-></BLOCKQUOTE
-></DIV
-></DD
-><DT
->-t <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-></DT
-><DD
-><P
->		<CODE
-CLASS="FUNCTION"
->chroot()</CODE
-> to <VAR
-CLASS="REPLACEABLE"
->directory</VAR
-> after
+	    </p>
+</div>
+</dd>
+<dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
+<dd>
+<p>
+		<code class="function">chroot()</code> to <em class="replaceable"><code>directory</code></em> after
 		processing the command line arguments, but before
 		reading the configuration file.
-          </P
-><DIV
-CLASS="WARNING"
-><P
-></P
-><TABLE
-CLASS="WARNING"
-BORDER="1"
-WIDTH="90%"
-><TR
-><TD
-ALIGN="CENTER"
-><B
->Warning</B
-></TD
-></TR
-><TR
-><TD
-ALIGN="LEFT"
-><P
->		This option should be used in conjunction with the
-		<VAR
-CLASS="OPTION"
->-u</VAR
-> option, as chrooting a process
+          </p>
+<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Warning</h3>
+<p>
+		This option should be used in conjunction with the
+		<code class="option">-u</code> option, as chrooting a process
 		running as root doesn't enhance security on most
-		systems; the way <CODE
-CLASS="FUNCTION"
->chroot()</CODE
-> is
+		systems; the way <code class="function">chroot()</code> is
 		defined allows a process with root privileges to
 		escape a chroot jail.
-	    </P
-></TD
-></TR
-></TABLE
-></DIV
-></DD
-><DT
->-u <VAR
-CLASS="REPLACEABLE"
->user</VAR
-></DT
-><DD
-><P
->		<CODE
-CLASS="FUNCTION"
->setuid()</CODE
-> to <VAR
-CLASS="REPLACEABLE"
->user</VAR
-> after completing
+	    </p>
+</div>
+</dd>
+<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
+<dd>
+<p>
+		<code class="function">setuid()</code> to <em class="replaceable"><code>user</code></em> after completing
 		privileged operations, such as creating sockets that
 		listen on privileged ports.
-          </P
-><DIV
-CLASS="NOTE"
-><BLOCKQUOTE
-CLASS="NOTE"
-><P
-><B
->Note: </B
->		On Linux, <B
-CLASS="COMMAND"
->named</B
-> uses the kernel's
+          </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+		On Linux, <span><strong class="command">named</strong></span> uses the kernel's
 		capability mechanism to drop all root privileges
-		except the ability to <CODE
-CLASS="FUNCTION"
->bind()</CODE
-> to a
+		except the ability to <code class="function">bind()</code> to a
 		privileged port and set process resource limits.
-		Unfortunately, this means that the <VAR
-CLASS="OPTION"
->-u</VAR
->
-		option only works when <B
-CLASS="COMMAND"
->named</B
-> is run
+		Unfortunately, this means that the <code class="option">-u</code>
+		option only works when <span><strong class="command">named</strong></span> is run
 		on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or
 		later, since previous kernels did not allow privileges
-		to be retained after <CODE
-CLASS="FUNCTION"
->setuid()</CODE
->.
-	    </P
-></BLOCKQUOTE
-></DIV
-></DD
-><DT
->-v</DT
-><DD
-><P
->		Report the version number and exit.
-          </P
-></DD
-><DT
->-x <VAR
-CLASS="REPLACEABLE"
->cache-file</VAR
-></DT
-><DD
-><P
->		Load data from <VAR
-CLASS="REPLACEABLE"
->cache-file</VAR
-> into the
+		to be retained after <code class="function">setuid()</code>.
+	    </p>
+</div>
+</dd>
+<dt><span class="term">-v</span></dt>
+<dd><p>
+		Report the version number and exit.
+          </p></dd>
+<dt><span class="term">-x <em class="replaceable"><code>cache-file</code></em></span></dt>
+<dd>
+<p>
+		Load data from <em class="replaceable"><code>cache-file</code></em> into the
 		cache of the default view.
-          </P
-><DIV
-CLASS="WARNING"
-><P
-></P
-><TABLE
-CLASS="WARNING"
-BORDER="1"
-WIDTH="90%"
-><TR
-><TD
-ALIGN="CENTER"
-><B
->Warning</B
-></TD
-></TR
-><TR
-><TD
-ALIGN="LEFT"
-><P
->		This option must not be used.  It is only of interest
+          </p>
+<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Warning</h3>
+<p>
+		This option must not be used.  It is only of interest
 		to BIND 9 developers and may be removed or changed in a
 		future release.
-	    </P
-></TD
-></TR
-></TABLE
-></DIV
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN153"
-></A
-><H2
->SIGNALS</H2
-><P
->	In routine operation, signals should not be used to control
-	the nameserver; <B
-CLASS="COMMAND"
->rndc</B
-> should be used
+	    </p>
+</div>
+</dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526297"></a><h2>SIGNALS</h2>
+<p>
+	In routine operation, signals should not be used to control
+	the nameserver; <span><strong class="command">rndc</strong></span> should be used
 	instead.
-    </P
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->SIGHUP</DT
-><DD
-><P
->		Force a reload of the server.
-          </P
-></DD
-><DT
->SIGINT, SIGTERM</DT
-><DD
-><P
->		Shut down the server.
-          </P
-></DD
-></DL
-></DIV
-><P
->	The result of sending any other signals to the server is undefined.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN167"
-></A
-><H2
->CONFIGURATION</H2
-><P
->	The <B
-CLASS="COMMAND"
->named</B
-> configuration file is too complex
+    </p>
+<div class="variablelist"><dl>
+<dt><span class="term">SIGHUP</span></dt>
+<dd><p>
+		Force a reload of the server.
+          </p></dd>
+<dt><span class="term">SIGINT, SIGTERM</span></dt>
+<dd><p>
+		Shut down the server.
+          </p></dd>
+</dl></div>
+<p>
+	The result of sending any other signals to the server is undefined.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526412"></a><h2>CONFIGURATION</h2>
+<p>
+	The <span><strong class="command">named</strong></span> configuration file is too complex
 	to describe in detail here.  A complete description is
-	provided in the <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference
-	Manual</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN172"
-></A
-><H2
->FILES</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><TT
-CLASS="FILENAME"
->/etc/named.conf</TT
-></DT
-><DD
-><P
->		The default configuration file.
-          </P
-></DD
-><DT
-><TT
-CLASS="FILENAME"
->/var/run/named.pid</TT
-></DT
-><DD
-><P
->		The default process-id file.
-          </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN185"
-></A
-><H2
->SEE ALSO</H2
-><P
->	<I
-CLASS="CITETITLE"
->RFC 1033</I
->,
-	<I
-CLASS="CITETITLE"
->RFC 1034</I
->,
-	<I
-CLASS="CITETITLE"
->RFC 1035</I
->,
-	<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->rndc</SPAN
->(8)</SPAN
->,
-	<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwresd</SPAN
->(8)</SPAN
->,
-	<I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN198"
-></A
-><H2
->AUTHOR</H2
-><P
->	Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+	provided in the <em class="citetitle">BIND 9 Administrator Reference
+	Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526429"></a><h2>FILES</h2>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt>
+<dd><p>
+		The default configuration file.
+          </p></dd>
+<dt><span class="term"><code class="filename">/var/run/named.pid</code></span></dt>
+<dd><p>
+		The default process-id file.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526469"></a><h2>SEE ALSO</h2>
+<p>
+	<em class="citetitle">RFC 1033</em>,
+	<em class="citetitle">RFC 1034</em>,
+	<em class="citetitle">RFC 1035</em>,
+	<span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
+	<span class="citerefentry"><span class="refentrytitle">lwresd</span>(8)</span>,
+	<em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526512"></a><h2>AUTHOR</h2>
+<p>
+	<span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/named/query.c b/contrib/bind9/bin/named/query.c
index a5411af3433f..75102fd1369d 100644
--- a/contrib/bind9/bin/named/query.c
+++ b/contrib/bind9/bin/named/query.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: query.c,v 1.198.2.13.4.30 2004/06/30 14:13:05 marka Exp $ */
+/* $Id: query.c,v 1.198.2.13.4.36 2005/08/11 05:25:20 marka Exp $ */
 
 #include <config.h>
 
@@ -1198,17 +1198,7 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 	 * recursing to add address records, which in turn can cause
 	 * recursion to add KEYs.
 	 */
-	if (type == dns_rdatatype_a || type == dns_rdatatype_aaaa) {
-		/*
-		 * RFC 2535 section 3.5 says that when A or AAAA records are
-		 * retrieved as additional data, any KEY RRs for the owner name
-		 * should be added to the additional data section.
-		 *
-		 * XXXRTH  We should lower the priority here.  Alternatively,
-		 * we could raise the priority of glue records.
-		 */
-		eresult = query_addadditional(client, name, dns_rdatatype_dnskey);
- 	} else if (type == dns_rdatatype_srv && trdataset != NULL) {
+ 	if (type == dns_rdatatype_srv && trdataset != NULL) {
 		/*
 		 * If we're adding SRV records to the additional data
 		 * section, it's helpful if we add the SRV additional data
@@ -1241,8 +1231,6 @@ static inline void
 query_addrdataset(ns_client_t *client, dns_name_t *fname,
 		  dns_rdataset_t *rdataset)
 {
-	dns_rdatatype_t type = rdataset->type;
-
 	/*
 	 * Add 'rdataset' and any pertinent additional data to
 	 * 'fname', a name in the response message for 'client'.
@@ -1266,22 +1254,6 @@ query_addrdataset(ns_client_t *client, dns_name_t *fname,
 	 */
 	(void)dns_rdataset_additionaldata(rdataset,
 					  query_addadditional, client);
-	/*
-	 * RFC 2535 section 3.5 says that when NS, SOA, A, or AAAA records
-	 * are retrieved, any KEY RRs for the owner name should be added
-	 * to the additional data section.  We treat A6 records the same way.
-	 *
-	 * We don't care if query_addadditional() fails.
-	 */
-	if (type == dns_rdatatype_ns || type == dns_rdatatype_soa ||
-	    type == dns_rdatatype_a || type == dns_rdatatype_aaaa ||
-	    type == dns_rdatatype_a6) {
-		/*
-		 * XXXRTH  We should lower the priority here.  Alternatively,
-		 * we could raise the priority of glue records.
-		 */
-		(void)query_addadditional(client, fname, dns_rdatatype_dnskey);
-	}
 	CTRACE("query_addrdataset: done");
 }
 
@@ -2116,33 +2088,37 @@ query_recurse(ns_client_t *client, dns_rdatatype_t qtype, dns_name_t *qdomain,
 	 * connection was accepted (if allowed by the TCP quota).
 	 */
 	if (client->recursionquota == NULL) {
-		isc_boolean_t killoldest = ISC_FALSE;
 		result = isc_quota_attach(&ns_g_server->recursionquota,
 					  &client->recursionquota);
-		if (result == ISC_R_SOFTQUOTA) {
+		if  (result == ISC_R_SOFTQUOTA) {
 			ns_client_log(client, NS_LOGCATEGORY_CLIENT,
 				      NS_LOGMODULE_QUERY, ISC_LOG_WARNING,
-				      "recursive-clients limit exceeded, "
+				      "recursive-clients soft limit exceeded, "
 				      "aborting oldest query");
-			killoldest = ISC_TRUE;
+			ns_client_killoldestquery(client);
 			result = ISC_R_SUCCESS;
-		}
-		if (dns_resolver_nrunning(client->view->resolver) >
-		    (unsigned int)ns_g_server->recursionquota.max)
-			result = ISC_R_QUOTA;
-		if (result == ISC_R_SUCCESS && !client->mortal &&
-		    (client->attributes & NS_CLIENTATTR_TCP) == 0)
-			result = ns_client_replace(client);
-		if (result != ISC_R_SUCCESS) {
+		} else if (result == ISC_R_QUOTA) {
 			ns_client_log(client, NS_LOGCATEGORY_CLIENT,
 				      NS_LOGMODULE_QUERY, ISC_LOG_WARNING,
 				      "no more recursive clients: %s",
 				      isc_result_totext(result));
-			if (client->recursionquota != NULL)
+			ns_client_killoldestquery(client);
+		}
+		if (result == ISC_R_SUCCESS && !client->mortal &&
+		    (client->attributes & NS_CLIENTATTR_TCP) == 0) {
+			result = ns_client_replace(client);
+			if (result != ISC_R_SUCCESS) {
+				ns_client_log(client, NS_LOGCATEGORY_CLIENT,
+					      NS_LOGMODULE_QUERY,
+					      ISC_LOG_WARNING,
+					      "ns_client_replace() failed: %s",
+					      isc_result_totext(result));
 				isc_quota_detach(&client->recursionquota);
-			return (result);
+			}
 		}
-		ns_client_recursing(client, killoldest);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+		ns_client_recursing(client);
 	}
 
 	/*
@@ -2319,6 +2295,34 @@ query_addnoqnameproof(ns_client_t *client, dns_rdataset_t *rdataset) {
                 query_releasename(client, &fname);
 }
 
+static inline void
+answer_in_glue(ns_client_t *client, dns_rdatatype_t qtype) {
+	dns_name_t *name;
+	dns_message_t *msg;
+	dns_section_t section = DNS_SECTION_ADDITIONAL;
+	dns_rdataset_t *rdataset = NULL;
+
+	msg = client->message;
+	for (name = ISC_LIST_HEAD(msg->sections[section]);
+	     name != NULL;
+	     name = ISC_LIST_NEXT(name, link))
+		if (dns_name_equal(name, client->query.qname)) {
+			for (rdataset = ISC_LIST_HEAD(name->list);
+			     rdataset != NULL;
+			     rdataset = ISC_LIST_NEXT(rdataset, link))
+				if (rdataset->type == qtype)
+					break;
+			break;
+		}
+	if (rdataset != NULL) {
+		ISC_LIST_UNLINK(msg->sections[section], name, link);
+		ISC_LIST_PREPEND(msg->sections[section], name, link);
+		ISC_LIST_UNLINK(name->list, rdataset, link);
+		ISC_LIST_PREPEND(name->list, rdataset, link);
+		rdataset->attributes |= DNS_RDATASETATTR_REQUIREDGLUE;
+	}
+}
+
 /*
  * Do the bulk of query processing for the current query of 'client'.
  * If 'event' is non-NULL, we are returning from recursion and 'qtype'
@@ -2875,7 +2879,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		/*
 		 * Add SOA.  If the query was for a SOA record force the
 		 * ttl to zero so that it is possible for clients to find
-		 * the containing zone of a arbitary name with a stub
+		 * the containing zone of an arbitrary name with a stub
 		 * resolver and not have it cached.
 		 */
 		if (qtype == dns_rdatatype_soa)
@@ -3338,6 +3342,16 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		 */
 		setup_query_sortlist(client);
 
+		/*
+		 * If this is a referral and the answer to the question
+		 * is in the glue sort it to the start of the additional
+		 * section.
+		 */
+		if (client->message->counts[DNS_SECTION_ANSWER] == 0 &&
+		    client->message->rcode == dns_rcode_noerror &&
+		    (qtype == dns_rdatatype_a || qtype == dns_rdatatype_aaaa))
+			answer_in_glue(client, qtype);
+
 		if (client->message->rcode == dns_rcode_nxdomain &&
 		    client->view->auth_nxdomain == ISC_TRUE)
 			client->message->flags |= DNS_MESSAGEFLAG_AA;
diff --git a/contrib/bind9/bin/named/server.c b/contrib/bind9/bin/named/server.c
index d0b6afc0e59a..b9d30d02f644 100644
--- a/contrib/bind9/bin/named/server.c
+++ b/contrib/bind9/bin/named/server.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: server.c,v 1.339.2.15.2.59 2004/11/10 22:13:56 marka Exp $ */
+/* $Id: server.c,v 1.339.2.15.2.65 2005/07/27 02:53:15 marka Exp $ */
 
 #include <config.h>
 
@@ -81,6 +81,10 @@
 #include <named/tkeyconf.h>
 #include <named/tsigconf.h>
 #include <named/zoneconf.h>
+#ifdef HAVE_LIBSCF
+#include <named/ns_smf_globals.h>
+#include <stdlib.h>
+#endif
 
 /*
  * Check an operation for failure.  Assumes that the function
@@ -1798,7 +1802,7 @@ configure_server_quota(cfg_obj_t **maps, const char *name, isc_quota_t *quota)
 
 	result = ns_config_get(maps, name, &obj);
 	INSIST(result == ISC_R_SUCCESS);
-	quota->max = cfg_obj_asuint32(obj);
+	isc_quota_max(quota, cfg_obj_asuint32(obj));
 }
 
 /*
@@ -1937,9 +1941,13 @@ adjust_interfaces(ns_server_t *server, isc_mem_t *mctx) {
 		 * At this point the zone list may contain a stale zone
 		 * just removed from the configuration.  To see the validity,
 		 * check if the corresponding view is in our current view list.
+		 * There may also be old zones that are still in the process
+		 * of shutting down and have detached from their old view
+		 * (zoneview == NULL).
 		 */
 		zoneview = dns_zone_getview(zone);
-		INSIST(zoneview != NULL);
+		if (zoneview == NULL)
+			continue;
 		for (view = ISC_LIST_HEAD(server->viewlist);
 		     view != NULL && view != zoneview;
 		     view = ISC_LIST_NEXT(view, link))
@@ -2221,6 +2229,11 @@ load_configuration(const char *filename, ns_server_t *server,
 	configure_server_quota(maps, "tcp-clients", &server->tcpquota);
 	configure_server_quota(maps, "recursive-clients",
 			       &server->recursionquota);
+	if (server->recursionquota.max > 1000)
+		isc_quota_soft(&server->recursionquota,
+			       server->recursionquota.max - 100);
+	else
+		isc_quota_soft(&server->recursionquota, 0);
 
 	CHECK(configure_view_acl(NULL, config, "blackhole", &aclconfctx,
 				 ns_g_mctx, &server->blackholeacl));
@@ -2948,7 +2961,6 @@ ns_server_create(isc_mem_t *mctx, ns_server_t **serverp) {
 	RUNTIME_CHECK(result == ISC_R_SUCCESS);
 	result = isc_quota_init(&server->recursionquota, 100);
 	RUNTIME_CHECK(result == ISC_R_SUCCESS);
-	isc_quota_soft(&server->recursionquota, ISC_FALSE);
 
 	result = dns_aclenv_init(mctx, &server->aclenv);
 	RUNTIME_CHECK(result == ISC_R_SUCCESS);
@@ -3637,6 +3649,15 @@ add_view_tolist(struct dumpcontext *dctx, dns_view_t *view) {
 	struct viewlistentry *vle;
 	isc_result_t result = ISC_R_SUCCESS;
 	
+	/*
+	 * Prevent duplicate views.
+	 */
+	for (vle = ISC_LIST_HEAD(dctx->viewlist);
+	     vle != NULL;
+	     vle = ISC_LIST_NEXT(vle, link))
+		if (vle->view == view)
+			return (ISC_R_SUCCESS);
+
 	vle = isc_mem_get(dctx->mctx, sizeof *vle);
 	if (vle == NULL)
 		return (ISC_R_NOMEMORY);
@@ -3700,9 +3721,11 @@ dumpdone(void *arg, isc_result_t result) {
 		if (dctx->view == NULL)
 			goto done;
 		INSIST(dctx->zone == NULL);
-	}
+	} else
+		goto resume;
  nextview:
 	fprintf(dctx->fp, ";\n; Start view %s\n;\n", dctx->view->view->name);
+ resume:
 	if (dctx->zone == NULL && dctx->cache == NULL && dctx->dumpcache) {
 		style = &dns_master_style_cache;
 		/* start cache dump */
@@ -3763,9 +3786,12 @@ dumpdone(void *arg, isc_result_t result) {
 							    &dctx->mdctx);
 			if (result == DNS_R_CONTINUE)
 				return;
-			if (result == ISC_R_NOTIMPLEMENTED)
+			if (result == ISC_R_NOTIMPLEMENTED) {
 				fprintf(dctx->fp, "; %s\n",
 					dns_result_totext(result));
+				result = ISC_R_SUCCESS;
+				goto nextzone;
+			}
 			if (result != ISC_R_SUCCESS)
 				goto cleanup;
 		}
@@ -3789,7 +3815,6 @@ dumpdone(void *arg, isc_result_t result) {
 	dumpcontext_destroy(dctx);
 }
 
-
 isc_result_t
 ns_server_dumpdb(ns_server_t *server, char *args) {
 	struct dumpcontext *dctx = NULL;
@@ -3845,6 +3870,7 @@ ns_server_dumpdb(ns_server_t *server, char *args) {
 		ptr = next_token(&args, " \t");
 	} 
 
+ nextview:
 	for (view = ISC_LIST_HEAD(server->viewlist);
 	     view != NULL;
 	     view = ISC_LIST_NEXT(view, link))
@@ -3853,6 +3879,11 @@ ns_server_dumpdb(ns_server_t *server, char *args) {
 			continue;
 		CHECK(add_view_tolist(dctx, view));
 	}
+	if (ptr != NULL) {
+		ptr = next_token(&args, " \t");
+		if (ptr != NULL)
+			goto nextview;
+	}
 	dumpdone(dctx, ISC_R_SUCCESS);
 	return (ISC_R_SUCCESS);
 
@@ -4101,3 +4132,22 @@ ns_server_freeze(ns_server_t *server, isc_boolean_t freeze, char *args) {
 	dns_zone_detach(&zone);
 	return (result);
 }
+
+#ifdef HAVE_LIBSCF
+/*
+ * This function adds a message for rndc to echo if named
+ * is managed by smf and is also running chroot.
+ */
+isc_result_t
+ns_smf_add_message(isc_buffer_t *text) {
+	unsigned int n;
+
+	n = snprintf((char *)isc_buffer_used(text),
+		isc_buffer_availablelength(text),
+		"use svcadm(1M) to manage named");
+	if (n >= isc_buffer_availablelength(text))
+		return (ISC_R_NOSPACE);
+	isc_buffer_add(text, n);
+	return (ISC_R_SUCCESS);
+}
+#endif /* HAVE_LIBSCF */
diff --git a/contrib/bind9/bin/named/unix/os.c b/contrib/bind9/bin/named/unix/os.c
index 797754948de3..f306f1462259 100644
--- a/contrib/bind9/bin/named/unix/os.c
+++ b/contrib/bind9/bin/named/unix/os.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: os.c,v 1.46.2.4.8.19 2004/10/07 02:34:20 marka Exp $ */
+/* $Id: os.c,v 1.46.2.4.8.22 2005/05/20 01:37:19 marka Exp $ */
 
 #include <config.h>
 #include <stdarg.h>
@@ -46,6 +46,9 @@
 
 #include <named/main.h>
 #include <named/os.h>
+#ifdef HAVE_LIBSCF
+#include <named/ns_smf_globals.h>
+#endif
 
 static char *pidfile = NULL;
 static int devnullfd = -1;
@@ -159,7 +162,7 @@ linux_setcaps(unsigned int caps) {
 	memset(&cap, 0, sizeof(cap));
 	cap.effective = caps;
 	cap.permitted = caps;
-	cap.inheritable = caps;
+	cap.inheritable = 0;
 	if (syscall(SYS_capset, &caphead, &cap) < 0) {
 		isc__strerror(errno, strbuf, sizeof(strbuf));
 		ns_main_earlyfatal("capset failed: %s:"
@@ -417,6 +420,9 @@ all_digits(const char *s) {
 void
 ns_os_chroot(const char *root) {
 	char strbuf[ISC_STRERRORSIZE];
+#ifdef HAVE_LIBSCF
+	ns_smf_chroot = 0;
+#endif
 	if (root != NULL) {
 		if (chroot(root) < 0) {
 			isc__strerror(errno, strbuf, sizeof(strbuf));
@@ -426,6 +432,10 @@ ns_os_chroot(const char *root) {
 			isc__strerror(errno, strbuf, sizeof(strbuf));
 			ns_main_earlyfatal("chdir(/): %s", strbuf);
 		}
+#ifdef HAVE_LIBSCF
+		/* Set ns_smf_chroot flag on successful chroot. */
+		ns_smf_chroot = 1;
+#endif
 	}
 }
 
diff --git a/contrib/bind9/bin/named/update.c b/contrib/bind9/bin/named/update.c
index 325381a85be0..6c2d7597f797 100644
--- a/contrib/bind9/bin/named/update.c
+++ b/contrib/bind9/bin/named/update.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: update.c,v 1.88.2.5.2.25 2004/10/21 01:40:22 marka Exp $ */
+/* $Id: update.c,v 1.88.2.5.2.27 2005/10/08 00:21:06 marka Exp $ */
 
 #include <config.h>
 
@@ -2723,8 +2723,8 @@ updatedone_action(isc_task_t *task, isc_event_t *event) {
 	INSIST(client->nupdates > 0);
 	client->nupdates--;
 	respond(client, uev->result);
-	ns_client_detach(&client);
 	isc_event_free(&event);
+	ns_client_detach(&client);
 }
 
 /*
@@ -2740,8 +2740,8 @@ forward_fail(isc_task_t *task, isc_event_t *event) {
 	INSIST(client->nupdates > 0);
 	client->nupdates--;
 	respond(client, DNS_R_SERVFAIL);
-	ns_client_detach(&client);
 	isc_event_free(&event);
+	ns_client_detach(&client);
 }
 
 
diff --git a/contrib/bind9/bin/named/xfrout.c b/contrib/bind9/bin/named/xfrout.c
index 9fb2697a45d6..687c287f4bda 100644
--- a/contrib/bind9/bin/named/xfrout.c
+++ b/contrib/bind9/bin/named/xfrout.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: xfrout.c,v 1.101.2.5.2.10 2004/04/02 06:08:17 marka Exp $ */
+/* $Id: xfrout.c,v 1.101.2.5.2.12 2005/10/14 02:13:05 marka Exp $ */
 
 #include <config.h>
 
@@ -868,7 +868,7 @@ xfrout_log1(ns_client_t *client, dns_name_t *zonename,
 	    const char *fmt, ...) ISC_FORMAT_PRINTF(5, 6);
 
 static void
-xfrout_log(xfrout_ctx_t *xfr, unsigned int level, const char *fmt, ...)
+xfrout_log(xfrout_ctx_t *xfr, int level, const char *fmt, ...)
 	   ISC_FORMAT_PRINTF(3, 4);
 
 /**************************************************************************/
@@ -1710,7 +1710,7 @@ xfrout_log1(ns_client_t *client, dns_name_t *zonename,
  * Logging function for use when there is a xfrout_ctx_t.
  */
 static void
-xfrout_log(xfrout_ctx_t *xfr, unsigned int level, const char *fmt, ...) {
+xfrout_log(xfrout_ctx_t *xfr, int level, const char *fmt, ...) {
 	va_list ap;
 	va_start(ap, fmt);
 	xfrout_logv(xfr->client, xfr->qname, xfr->qclass, level, fmt, ap);
diff --git a/contrib/bind9/bin/named/zoneconf.c b/contrib/bind9/bin/named/zoneconf.c
index afafa534d2b6..41ce69d6a627 100644
--- a/contrib/bind9/bin/named/zoneconf.c
+++ b/contrib/bind9/bin/named/zoneconf.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zoneconf.c,v 1.87.2.4.10.13 2004/04/20 14:12:09 marka Exp $ */
+/* $Id: zoneconf.c,v 1.87.2.4.10.15 2005/09/06 02:12:39 marka Exp $ */
 
 #include <config.h>
 
@@ -375,17 +375,30 @@ ns_zone_configure(cfg_obj_t *config, cfg_obj_t *vconfig, cfg_obj_t *zconfig,
 	obj = NULL;
 	result = cfg_map_get(zoptions, "database", &obj);
 	if (result == ISC_R_SUCCESS)
-		cpval = cfg_obj_asstring(obj);
+		cpval = isc_mem_strdup(mctx, cfg_obj_asstring(obj));
 	else
 		cpval = default_dbtype;
-	RETERR(strtoargv(mctx, cpval, &dbargc, &dbargv));
+
+	if (cpval == NULL)
+		return(ISC_R_NOMEMORY);
+
+	result = strtoargv(mctx, cpval, &dbargc, &dbargv);
+	if (result != ISC_R_SUCCESS && cpval != default_dbtype) {
+		isc_mem_free(mctx, cpval);
+		return (result);
+	}
+
 	/*
 	 * ANSI C is strange here.  There is no logical reason why (char **)
 	 * cannot be promoted automatically to (const char * const *) by the
 	 * compiler w/o generating a warning.
 	 */
-	RETERR(dns_zone_setdbtype(zone, dbargc, (const char * const *)dbargv));
+	result = dns_zone_setdbtype(zone, dbargc, (const char * const *)dbargv);
 	isc_mem_put(mctx, dbargv, dbargc * sizeof(*dbargv));
+	if (cpval != default_dbtype)
+		isc_mem_free(mctx, cpval);
+	if (result != ISC_R_SUCCESS)
+		return (result);
 
 	obj = NULL;
 	result = cfg_map_get(zoptions, "file", &obj);
diff --git a/contrib/bind9/bin/nsupdate/nsupdate.8 b/contrib/bind9/bin/nsupdate/nsupdate.8
index 7828db23a8b9..602a55b18310 100644
--- a/contrib/bind9/bin/nsupdate/nsupdate.8
+++ b/contrib/bind9/bin/nsupdate/nsupdate.8
@@ -1,294 +1,239 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000-2003  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000-2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: nsupdate.8,v 1.24.2.2.2.5 2004/03/08 09:04:15 marka Exp $
+.\" $Id: nsupdate.8,v 1.24.2.2.2.8 2005/10/13 02:33:48 marka Exp $
 .\"
-.TH "NSUPDATE" "8" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "NSUPDATE" "8" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 nsupdate \- Dynamic DNS update utility
-.SH SYNOPSIS
-.sp
-\fBnsupdate\fR [ \fB-d\fR ]  [ \fB [ -y \fIkeyname:secret\fB ]  [ -k \fIkeyfile\fB ] \fR ]  [ \fB-t \fItimeout\fB\fR ]  [ \fB-u \fIudptimeout\fB\fR ]  [ \fB-r \fIudpretries\fB\fR ]  [ \fB-v\fR ]  [ \fBfilename\fR ] 
+.SH "SYNOPSIS"
+.HP 9
+\fBnsupdate\fR [\fB\-d\fR] [[\fB\-y\ \fR\fB\fIkeyname:secret\fR\fR] [\fB\-k\ \fR\fB\fIkeyfile\fR\fR]] [\fB\-t\ \fR\fB\fItimeout\fR\fR] [\fB\-u\ \fR\fB\fIudptimeout\fR\fR] [\fB\-r\ \fR\fB\fIudpretries\fR\fR] [\fB\-v\fR] [filename]
 .SH "DESCRIPTION"
 .PP
 \fBnsupdate\fR
-is used to submit Dynamic DNS Update requests as defined in RFC2136
-to a name server.
-This allows resource records to be added or removed from a zone
-without manually editing the zone file.
-A single update request can contain requests to add or remove more than one
-resource record.
+is used to submit Dynamic DNS Update requests as defined in RFC2136 to a name server. This allows resource records to be added or removed from a zone without manually editing the zone file. A single update request can contain requests to add or remove more than one resource record.
 .PP
 Zones that are under dynamic control via
 \fBnsupdate\fR
-or a DHCP server should not be edited by hand.
-Manual edits could
-conflict with dynamic updates and cause data to be lost.
+or a DHCP server should not be edited by hand. Manual edits could conflict with dynamic updates and cause data to be lost.
 .PP
 The resource records that are dynamically added or removed with
 \fBnsupdate\fR
-have to be in the same zone.
-Requests are sent to the zone's master server.
-This is identified by the MNAME field of the zone's SOA record.
+have to be in the same zone. Requests are sent to the zone's master server. This is identified by the MNAME field of the zone's SOA record.
 .PP
 The
-\fB-d\fR
+\fB\-d\fR
 option makes
 \fBnsupdate\fR
-operate in debug mode.
-This provides tracing information about the update requests that are
-made and the replies received from the name server.
+operate in debug mode. This provides tracing information about the update requests that are made and the replies received from the name server.
 .PP
-Transaction signatures can be used to authenticate the Dynamic DNS
-updates.
-These use the TSIG resource record type described in RFC2845 or the
-SIG(0) record described in RFC3535 and RFC2931.
-TSIG relies on a shared secret that should only be known to
-\fBnsupdate\fR and the name server.
-Currently, the only supported encryption algorithm for TSIG is
-HMAC-MD5, which is defined in RFC 2104.
-Once other algorithms are defined for TSIG, applications will need to
-ensure they select the appropriate algorithm as well as the key when
-authenticating each other.
-For instance suitable
+Transaction signatures can be used to authenticate the Dynamic DNS updates. These use the TSIG resource record type described in RFC2845 or the SIG(0) record described in RFC3535 and RFC2931. TSIG relies on a shared secret that should only be known to
+\fBnsupdate\fR
+and the name server. Currently, the only supported encryption algorithm for TSIG is HMAC\-MD5, which is defined in RFC 2104. Once other algorithms are defined for TSIG, applications will need to ensure they select the appropriate algorithm as well as the key when authenticating each other. For instance suitable
 \fBkey\fR
 and
 \fBserver\fR
 statements would be added to
 \fI/etc/named.conf\fR
-so that the name server can associate the appropriate secret key
-and algorithm with the IP address of the
-client application that will be using TSIG authentication.
-SIG(0) uses public key cryptography. To use a SIG(0) key, the public
-key must be stored in a KEY record in a zone served by the name server.
+so that the name server can associate the appropriate secret key and algorithm with the IP address of the client application that will be using TSIG authentication. SIG(0) uses public key cryptography. To use a SIG(0) key, the public key must be stored in a KEY record in a zone served by the name server.
 \fBnsupdate\fR
 does not read
 \fI/etc/named.conf\fR.
 .PP
 \fBnsupdate\fR
 uses the
-\fB-y\fR
+\fB\-y\fR
 or
-\fB-k\fR
-option (with an HMAC-MD5 key) to provide the shared secret needed to generate
-a TSIG record for authenticating Dynamic DNS update requests.
-These options are mutually exclusive.
-With the
-\fB-k\fR
+\fB\-k\fR
+option (with an HMAC\-MD5 key) to provide the shared secret needed to generate a TSIG record for authenticating Dynamic DNS update requests. These options are mutually exclusive. With the
+\fB\-k\fR
 option,
 \fBnsupdate\fR
 reads the shared secret from the file
-\fIkeyfile\fR,
-whose name is of the form 
-\fIK{name}.+157.+{random}.private\fR.
-For historical
-reasons, the file 
+\fIkeyfile\fR, whose name is of the form
+\fIK{name}.+157.+{random}.private\fR. For historical reasons, the file
 \fIK{name}.+157.+{random}.key\fR
 must also be present. When the
-\fB-y\fR
+\fB\-y\fR
 option is used, a signature is generated from
-\fIkeyname:secret.\fR
-\fIkeyname\fR
-is the name of the key,
-and
+\fIkeyname:secret.\fR\fIkeyname\fR
+is the name of the key, and
 \fIsecret\fR
-is the base64 encoded shared secret.
-Use of the
-\fB-y\fR
-option is discouraged because the shared secret is supplied as a command
-line argument in clear text.
-This may be visible in the output from
-\fBps\fR(1)
+is the base64 encoded shared secret. Use of the
+\fB\-y\fR
+option is discouraged because the shared secret is supplied as a command line argument in clear text. This may be visible in the output from
+\fBps\fR(1 )
 or in a history file maintained by the user's shell.
 .PP
-The \fB-k\fR may also be used to specify a SIG(0) key used
-to authenticate Dynamic DNS update requests. In this case, the key
-specified is not an HMAC-MD5 key.
+The
+\fB\-k\fR
+may also be used to specify a SIG(0) key used to authenticate Dynamic DNS update requests. In this case, the key specified is not an HMAC\-MD5 key.
 .PP
 By default
 \fBnsupdate\fR
-uses UDP to send update requests to the name server unless they are too
-large to fit in a UDP request in which case TCP will be used.
-The
-\fB-v\fR
+uses UDP to send update requests to the name server unless they are too large to fit in a UDP request in which case TCP will be used. The
+\fB\-v\fR
 option makes
 \fBnsupdate\fR
-use a TCP connection.
-This may be preferable when a batch of update requests is made.
+use a TCP connection. This may be preferable when a batch of update requests is made.
 .PP
-The \fB-t\fR option sets the maximum time a update request can
-take before it is aborted. The default is 300 seconds. Zero can be used
-to disable the timeout.
+The
+\fB\-t\fR
+option sets the maximum time a update request can take before it is aborted. The default is 300 seconds. Zero can be used to disable the timeout.
 .PP
-The \fB-u\fR option sets the UDP retry interval. The default is
-3 seconds. If zero the interval will be computed from the timeout interval
-and number of UDP retries.
+The
+\fB\-u\fR
+option sets the UDP retry interval. The default is 3 seconds. If zero the interval will be computed from the timeout interval and number of UDP retries.
 .PP
-The \fB-r\fR option sets the number of UDP retries. The default is
-3. If zero only one update request will be made.
+The
+\fB\-r\fR
+option sets the number of UDP retries. The default is 3. If zero only one update request will be made.
 .SH "INPUT FORMAT"
 .PP
 \fBnsupdate\fR
 reads input from
 \fIfilename\fR
-or standard input.
-Each command is supplied on exactly one line of input.
-Some commands are for administrative purposes.
-The others are either update instructions or prerequisite checks on the
-contents of the zone.
-These checks set conditions that some name or set of
-resource records (RRset) either exists or is absent from the zone.
-These conditions must be met if the entire update request is to succeed.
-Updates will be rejected if the tests for the prerequisite conditions fail.
+or standard input. Each command is supplied on exactly one line of input. Some commands are for administrative purposes. The others are either update instructions or prerequisite checks on the contents of the zone. These checks set conditions that some name or set of resource records (RRset) either exists or is absent from the zone. These conditions must be met if the entire update request is to succeed. Updates will be rejected if the tests for the prerequisite conditions fail.
 .PP
-Every update request consists of zero or more prerequisites
-and zero or more updates.
-This allows a suitably authenticated update request to proceed if some
-specified resource records are present or missing from the zone.
-A blank input line (or the \fBsend\fR command) causes the
-accumulated commands to be sent as one Dynamic DNS update request to the
-name server.
+Every update request consists of zero or more prerequisites and zero or more updates. This allows a suitably authenticated update request to proceed if some specified resource records are present or missing from the zone. A blank input line (or the
+\fBsend\fR
+command) causes the accumulated commands to be sent as one Dynamic DNS update request to the name server.
 .PP
 The command formats and their meaning are as follows:
 .TP
-\fBserver servername [ port ]\fR
+.HP 7 \fBserver\fR {servername} [port]
 Sends all dynamic update requests to the name server
-\fIservername\fR.
-When no server statement is provided,
+\fIservername\fR. When no server statement is provided,
 \fBnsupdate\fR
-will send updates to the master server of the correct zone.
-The MNAME field of that zone's SOA record will identify the master
-server for that zone.
+will send updates to the master server of the correct zone. The MNAME field of that zone's SOA record will identify the master server for that zone.
 \fIport\fR
 is the port number on
 \fIservername\fR
-where the dynamic update requests get sent.
-If no port number is specified, the default DNS port number of 53 is
-used.
+where the dynamic update requests get sent. If no port number is specified, the default DNS port number of 53 is used.
 .TP
-\fBlocal address [ port ]\fR
+.HP 6 \fBlocal\fR {address} [port]
 Sends all dynamic update requests using the local
-\fIaddress\fR.
-When no local statement is provided,
+\fIaddress\fR. When no local statement is provided,
 \fBnsupdate\fR
 will send updates using an address and port chosen by the system.
 \fIport\fR
-can additionally be used to make requests come from a specific port.
-If no port number is specified, the system will assign one.
+can additionally be used to make requests come from a specific port. If no port number is specified, the system will assign one.
 .TP
-\fBzone zonename\fR
+.HP 5 \fBzone\fR {zonename}
 Specifies that all updates are to be made to the zone
-\fIzonename\fR.
-If no
+\fIzonename\fR. If no
 \fIzone\fR
 statement is provided,
 \fBnsupdate\fR
 will attempt determine the correct zone to update based on the rest of the input.
 .TP
-\fBclass classname\fR
-Specify the default class.
-If no \fIclass\fR is specified the default class is
+.HP 6 \fBclass\fR {classname}
+Specify the default class. If no
+\fIclass\fR
+is specified the default class is
 \fIIN\fR.
 .TP
-\fBkey name secret\fR
+.HP 4 \fBkey\fR {name} {secret}
 Specifies that all updates are to be TSIG signed using the
-\fIkeyname\fR \fIkeysecret\fR pair.
-The \fBkey\fR command
-overrides any key specified on the command line via
-\fB-y\fR or \fB-k\fR.
+\fIkeyname\fR\fIkeysecret\fR
+pair. The
+\fBkey\fR
+command overrides any key specified on the command line via
+\fB\-y\fR
+or
+\fB\-k\fR.
 .TP
-\fBprereq nxdomain domain-name\fR
+.HP 16 \fBprereq nxdomain\fR {domain\-name}
 Requires that no resource record of any type exists with name
-\fIdomain-name\fR.
+\fIdomain\-name\fR.
 .TP
-\fBprereq yxdomain domain-name\fR
+.HP 16 \fBprereq yxdomain\fR {domain\-name}
 Requires that
-\fIdomain-name\fR
+\fIdomain\-name\fR
 exists (has as at least one resource record, of any type).
 .TP
-\fBprereq nxrrset domain-name [ class ]  type\fR
+.HP 15 \fBprereq nxrrset\fR {domain\-name} [class] {type}
 Requires that no resource record exists of the specified
 \fItype\fR,
 \fIclass\fR
 and
-\fIdomain-name\fR.
-If
+\fIdomain\-name\fR. If
 \fIclass\fR
 is omitted, IN (internet) is assumed.
 .TP
-\fBprereq yxrrset domain-name [ class ]  type\fR
+.HP 15 \fBprereq yxrrset\fR {domain\-name} [class] {type}
 This requires that a resource record of the specified
 \fItype\fR,
 \fIclass\fR
 and
-\fIdomain-name\fR
-must exist.
-If
+\fIdomain\-name\fR
+must exist. If
 \fIclass\fR
 is omitted, IN (internet) is assumed.
 .TP
-\fBprereq yxrrset domain-name [ class ]  type data\fI...\fB\fR
+.HP 15 \fBprereq yxrrset\fR {domain\-name} [class] {type} {data...}
 The
 \fIdata\fR
-from each set of prerequisites of this form
-sharing a common
+from each set of prerequisites of this form sharing a common
 \fItype\fR,
-\fIclass\fR,
-and 
-\fIdomain-name\fR
-are combined to form a set of RRs. This set of RRs must
-exactly match the set of RRs existing in the zone at the
-given 
+\fIclass\fR, and
+\fIdomain\-name\fR
+are combined to form a set of RRs. This set of RRs must exactly match the set of RRs existing in the zone at the given
 \fItype\fR,
-\fIclass\fR,
-and 
-\fIdomain-name\fR.
-The
+\fIclass\fR, and
+\fIdomain\-name\fR. The
 \fIdata\fR
-are written in the standard text representation of the resource record's
-RDATA.
+are written in the standard text representation of the resource record's RDATA.
 .TP
-\fBupdate delete domain-name [ ttl ]  [ class ]  [ type  [ data\fI...\fB ]  ]\fR
+.HP 14 \fBupdate delete\fR {domain\-name} [ttl] [class] [type\ [data...]]
 Deletes any resource records named
-\fIdomain-name\fR.
-If
+\fIdomain\-name\fR. If
 \fItype\fR
 and
 \fIdata\fR
-is provided, only matching resource records will be removed.
-The internet class is assumed if
+is provided, only matching resource records will be removed. The internet class is assumed if
 \fIclass\fR
 is not supplied. The
 \fIttl\fR
 is ignored, and is only allowed for compatibility.
 .TP
-\fBupdate add domain-name ttl [ class ]  type data\fI...\fB\fR
+.HP 11 \fBupdate add\fR {domain\-name} {ttl} [class] {type} {data...}
 Adds a new resource record with the specified
 \fIttl\fR,
 \fIclass\fR
 and
 \fIdata\fR.
 .TP
-\fBshow\fR
-Displays the current message, containing all of the prerequisites and
-updates specified since the last send.
+.HP 5 \fBshow\fR
+Displays the current message, containing all of the prerequisites and updates specified since the last send.
 .TP
-\fBsend\fR
+.HP 5 \fBsend\fR
 Sends the current message. This is equivalent to entering a blank line.
 .TP
-\fBanswer\fR
+.HP 7 \fBanswer\fR
 Displays the answer.
 .PP
 Lines beginning with a semicolon are comments and are ignored.
@@ -298,10 +243,7 @@ The examples below show how
 \fBnsupdate\fR
 could be used to insert and delete resource records from the
 \fBexample.com\fR
-zone.
-Notice that the input in each example contains a trailing blank line so that
-a group of commands are sent as one dynamic update request to the
-master name server for
+zone. Notice that the input in each example contains a trailing blank line so that a group of commands are sent as one dynamic update request to the master name server for
 \fBexample.com\fR.
 .sp
 .nf
@@ -309,61 +251,48 @@ master name server for
 > update delete oldhost.example.com A
 > update add newhost.example.com 86400 A 172.16.1.1
 > send
-.sp
 .fi
+.sp
 .PP
 Any A records for
 \fBoldhost.example.com\fR
-are deleted.
-and an A record for
+are deleted. and an A record for
 \fBnewhost.example.com\fR
-it IP address 172.16.1.1 is added.
-The newly-added record has a 1 day TTL (86400 seconds)
+it IP address 172.16.1.1 is added. The newly\-added record has a 1 day TTL (86400 seconds)
 .sp
 .nf
 # nsupdate
 > prereq nxdomain nickname.example.com
 > update add nickname.example.com 86400 CNAME somehost.example.com
 > send
-.sp
 .fi
+.sp
 .PP
-The prerequisite condition gets the name server to check that there
-are no resource records of any type for
-\fBnickname.example.com\fR.
-If there are, the update request fails.
-If this name does not exist, a CNAME for it is added.
-This ensures that when the CNAME is added, it cannot conflict with the
-long-standing rule in RFC1034 that a name must not exist as any other
-record type if it exists as a CNAME.
-(The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have
-RRSIG, DNSKEY and NSEC records.)
+The prerequisite condition gets the name server to check that there are no resource records of any type for
+\fBnickname.example.com\fR. If there are, the update request fails. If this name does not exist, a CNAME for it is added. This ensures that when the CNAME is added, it cannot conflict with the long\-standing rule in RFC1034 that a name must not exist as any other record type if it exists as a CNAME. (The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have RRSIG, DNSKEY and NSEC records.)
 .SH "FILES"
 .TP
 \fB/etc/resolv.conf\fR
 used to identify default name server
 .TP
 \fBK{name}.+157.+{random}.key\fR
-base-64 encoding of HMAC-MD5 key created by
-\fBdnssec-keygen\fR(8).
+base\-64 encoding of HMAC\-MD5 key created by
+\fBdnssec\-keygen\fR(8).
 .TP
 \fBK{name}.+157.+{random}.private\fR
-base-64 encoding of HMAC-MD5 key created by
-\fBdnssec-keygen\fR(8).
+base\-64 encoding of HMAC\-MD5 key created by
+\fBdnssec\-keygen\fR(8).
 .SH "SEE ALSO"
 .PP
-\fBRFC2136\fR,
-\fBRFC3007\fR,
-\fBRFC2104\fR,
-\fBRFC2845\fR,
-\fBRFC1034\fR,
-\fBRFC2535\fR,
-\fBRFC2931\fR,
+\fBRFC2136\fR(),
+\fBRFC3007\fR(),
+\fBRFC2104\fR(),
+\fBRFC2845\fR(),
+\fBRFC1034\fR(),
+\fBRFC2535\fR(),
+\fBRFC2931\fR(),
 \fBnamed\fR(8),
-\fBdnssec-keygen\fR(8).
+\fBdnssec\-keygen\fR(8).
 .SH "BUGS"
 .PP
-The TSIG key is redundantly stored in two separate files.
-This is a consequence of nsupdate using the DST library
-for its cryptographic operations, and may change in future
-releases.
+The TSIG key is redundantly stored in two separate files. This is a consequence of nsupdate using the DST library for its cryptographic operations, and may change in future releases.
diff --git a/contrib/bind9/bin/nsupdate/nsupdate.c b/contrib/bind9/bin/nsupdate/nsupdate.c
index 3304a3c0e640..7c728b6db950 100644
--- a/contrib/bind9/bin/nsupdate/nsupdate.c
+++ b/contrib/bind9/bin/nsupdate/nsupdate.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsupdate.c,v 1.103.2.15.2.18 2004/09/16 02:12:18 marka Exp $ */
+/* $Id: nsupdate.c,v 1.103.2.15.2.20 2005/03/17 03:58:26 marka Exp $ */
 
 #include <config.h>
 
@@ -1634,6 +1634,7 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
 		ddebug("Destroying request [%p]", request);
 		dns_request_destroy(&request);
 		dns_message_renderreset(soaquery);
+		dns_message_settsigkey(soaquery, NULL);
 		sendrequest(localaddr, &servers[ns_inuse], soaquery, &request);
 		isc_mem_put(mctx, reqinfo, sizeof(nsu_requestinfo_t));
 		isc_event_free(&event);
@@ -1813,6 +1814,7 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
 	dns_name_clone(&tname, name);
 	dns_request_destroy(&request);
 	dns_message_renderreset(soaquery);
+	dns_message_settsigkey(soaquery, NULL);
 	if (userserver != NULL)
 		sendrequest(localaddr, userserver, soaquery, &request);
 	else
diff --git a/contrib/bind9/bin/nsupdate/nsupdate.docbook b/contrib/bind9/bin/nsupdate/nsupdate.docbook
index 7d23333c864c..7a2b4cfb7dd7 100644
--- a/contrib/bind9/bin/nsupdate/nsupdate.docbook
+++ b/contrib/bind9/bin/nsupdate/nsupdate.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001-2003  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: nsupdate.docbook,v 1.8.2.3.2.8 2004/03/08 04:04:23 marka Exp $ -->
+<!-- $Id: nsupdate.docbook,v 1.8.2.3.2.10 2005/05/12 21:36:03 sra Exp $ -->
 
 <refentry>
 <refentryinfo>
@@ -27,6 +29,22 @@
 <manvolnum>8</manvolnum>
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
+
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>nsupdate</refname>
 <refpurpose>Dynamic DNS update utility</refpurpose>
@@ -229,6 +247,8 @@ where the dynamic update requests get sent.
 If no port number is specified, the default DNS port number of 53 is
 used.
 </para>
+</listitem>
+</varlistentry>
 
 <varlistentry><term>
 <cmdsynopsis>
@@ -248,6 +268,9 @@ will send updates using an address and port chosen by the system.
 <parameter>port</parameter>
 can additionally be used to make requests come from a specific port.
 If no port number is specified, the system will assign one.
+</para>
+</listitem>
+</varlistentry>
 
 <varlistentry><term>
 <cmdsynopsis>
@@ -482,6 +505,7 @@ updates specified since the last send.
 Sends the current message.  This is equivalent to entering a blank line.
 </para>
 </listitem>
+</varlistentry>
 
 <varlistentry><term>
 <cmdsynopsis>
@@ -493,8 +517,10 @@ Sends the current message.  This is equivalent to entering a blank line.
 Displays the answer.
 </para>
 </listitem>
+</varlistentry>
 
 </variablelist>
+</para>
 
 <para>
 Lines beginning with a semicolon are comments and are ignored.
@@ -562,6 +588,7 @@ RRSIG, DNSKEY and NSEC records.)
 used to identify default name server
 </para>
 </listitem>
+</varlistentry>
 
 <varlistentry><term><constant>K{name}.+157.+{random}.key</constant></term>
 <listitem>
@@ -572,6 +599,7 @@ base-64 encoding of HMAC-MD5 key created by
 </citerefentry>.
 </para>
 </listitem>
+</varlistentry>
 
 <varlistentry><term><constant>K{name}.+157.+{random}.private</constant></term>
 <listitem>
@@ -582,6 +610,7 @@ base-64 encoding of HMAC-MD5 key created by
 </citerefentry>.
 </para>
 </listitem>
+</varlistentry>
 </variablelist>
 </refsect1>
 
@@ -615,7 +644,7 @@ base-64 encoding of HMAC-MD5 key created by
 <citerefentry>
 <refentrytitle>dnssec-keygen</refentrytitle><manvolnum>8</manvolnum>
 </citerefentry>.
-
+</para>
 </refsect1>
 <refsect1>
 <title>BUGS</title>
diff --git a/contrib/bind9/bin/nsupdate/nsupdate.html b/contrib/bind9/bin/nsupdate/nsupdate.html
index f9cb98cc35f0..74ba2fbe2777 100644
--- a/contrib/bind9/bin/nsupdate/nsupdate.html
+++ b/contrib/bind9/bin/nsupdate/nsupdate.html
@@ -1,339 +1,170 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001-2003  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: nsupdate.html,v 1.9.2.3.2.5 2004/08/22 23:38:59 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->nsupdate</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->nsupdate</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->nsupdate&nbsp;--&nbsp;Dynamic DNS update utility</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN11"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->nsupdate</B
->  [<VAR
-CLASS="OPTION"
->-d</VAR
->] [<VAR
-CLASS="OPTION"
->-y <VAR
-CLASS="REPLACEABLE"
->keyname:secret</VAR
-></VAR
-> | <VAR
-CLASS="OPTION"
->-k <VAR
-CLASS="REPLACEABLE"
->keyfile</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->timeout</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-u <VAR
-CLASS="REPLACEABLE"
->udptimeout</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-r <VAR
-CLASS="REPLACEABLE"
->udpretries</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-v</VAR
->] [filename]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN35"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><B
-CLASS="COMMAND"
->nsupdate</B
->
+<!-- $Id: nsupdate.html,v 1.9.2.3.2.12 2005/10/13 02:33:49 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>nsupdate</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>nsupdate &#8212; Dynamic DNS update utility</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">nsupdate</code>  [<code class="option">-d</code>] [[<code class="option">-y <em class="replaceable"><code>keyname:secret</code></em></code>] |  [<code class="option">-k <em class="replaceable"><code>keyfile</code></em></code>]] [<code class="option">-t <em class="replaceable"><code>timeout</code></em></code>] [<code class="option">-u <em class="replaceable"><code>udptimeout</code></em></code>] [<code class="option">-r <em class="replaceable"><code>udpretries</code></em></code>] [<code class="option">-v</code>] [filename]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525896"></a><h2>DESCRIPTION</h2>
+<p>
+<span><strong class="command">nsupdate</strong></span>
 is used to submit Dynamic DNS Update requests as defined in RFC2136
 to a name server.
 This allows resource records to be added or removed from a zone
 without manually editing the zone file.
 A single update request can contain requests to add or remove more than one
-resource record.</P
-><P
->Zones that are under dynamic control via
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+resource record.
+</p>
+<p>
+Zones that are under dynamic control via
+<span><strong class="command">nsupdate</strong></span>
 or a DHCP server should not be edited by hand.
 Manual edits could
-conflict with dynamic updates and cause data to be lost.</P
-><P
->The resource records that are dynamically added or removed with
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+conflict with dynamic updates and cause data to be lost.
+</p>
+<p>
+The resource records that are dynamically added or removed with
+<span><strong class="command">nsupdate</strong></span>
 have to be in the same zone.
 Requests are sent to the zone's master server.
-This is identified by the MNAME field of the zone's SOA record.</P
-><P
->The
-<VAR
-CLASS="OPTION"
->-d</VAR
->
+This is identified by the MNAME field of the zone's SOA record.
+</p>
+<p>
+The
+<code class="option">-d</code>
 option makes
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+<span><strong class="command">nsupdate</strong></span>
 operate in debug mode.
 This provides tracing information about the update requests that are
-made and the replies received from the name server.</P
-><P
->Transaction signatures can be used to authenticate the Dynamic DNS
+made and the replies received from the name server.
+</p>
+<p>
+Transaction signatures can be used to authenticate the Dynamic DNS
 updates.
 These use the TSIG resource record type described in RFC2845 or the
 SIG(0) record described in RFC3535 and RFC2931.
 TSIG relies on a shared secret that should only be known to
-<B
-CLASS="COMMAND"
->nsupdate</B
-> and the name server.
+<span><strong class="command">nsupdate</strong></span> and the name server.
 Currently, the only supported encryption algorithm for TSIG is
 HMAC-MD5, which is defined in RFC 2104.
 Once other algorithms are defined for TSIG, applications will need to
 ensure they select the appropriate algorithm as well as the key when
 authenticating each other.
 For instance suitable
-<SPAN
-CLASS="TYPE"
->key</SPAN
->
+<span class="type">key</span>
 and
-<SPAN
-CLASS="TYPE"
->server</SPAN
->
+<span class="type">server</span>
 statements would be added to
-<TT
-CLASS="FILENAME"
->/etc/named.conf</TT
->
+<code class="filename">/etc/named.conf</code>
 so that the name server can associate the appropriate secret key
 and algorithm with the IP address of the
 client application that will be using TSIG authentication.
 SIG(0) uses public key cryptography.  To use a SIG(0) key, the public
 key must be stored in a KEY record in a zone served by the name server.
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+<span><strong class="command">nsupdate</strong></span>
 does not read
-<TT
-CLASS="FILENAME"
->/etc/named.conf</TT
->.</P
-><P
-><B
-CLASS="COMMAND"
->nsupdate</B
->
+<code class="filename">/etc/named.conf</code>.
+</p>
+<p>
+<span><strong class="command">nsupdate</strong></span>
 uses the
-<VAR
-CLASS="OPTION"
->-y</VAR
->
+<code class="option">-y</code>
 or
-<VAR
-CLASS="OPTION"
->-k</VAR
->
+<code class="option">-k</code>
 option (with an HMAC-MD5 key) to provide the shared secret needed to generate
 a TSIG record for authenticating Dynamic DNS update requests.
 These options are mutually exclusive.
 With the
-<VAR
-CLASS="OPTION"
->-k</VAR
->
+<code class="option">-k</code>
 option,
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+<span><strong class="command">nsupdate</strong></span>
 reads the shared secret from the file
-<VAR
-CLASS="PARAMETER"
->keyfile</VAR
->,
+<em class="parameter"><code>keyfile</code></em>,
 whose name is of the form 
-<TT
-CLASS="FILENAME"
->K{name}.+157.+{random}.private</TT
->.
+<code class="filename">K{name}.+157.+{random}.private</code>.
 For historical
 reasons, the file 
-<TT
-CLASS="FILENAME"
->K{name}.+157.+{random}.key</TT
->
+<code class="filename">K{name}.+157.+{random}.key</code>
 must also be present.  When the
-<VAR
-CLASS="OPTION"
->-y</VAR
->
+<code class="option">-y</code>
 option is used, a signature is generated from
-<VAR
-CLASS="PARAMETER"
->keyname:secret.</VAR
->
-<VAR
-CLASS="PARAMETER"
->keyname</VAR
->
+<em class="parameter"><code>keyname:secret.</code></em>
+<em class="parameter"><code>keyname</code></em>
 is the name of the key,
 and
-<VAR
-CLASS="PARAMETER"
->secret</VAR
->
+<em class="parameter"><code>secret</code></em>
 is the base64 encoded shared secret.
 Use of the
-<VAR
-CLASS="OPTION"
->-y</VAR
->
+<code class="option">-y</code>
 option is discouraged because the shared secret is supplied as a command
 line argument in clear text.
 This may be visible in the output from
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->ps</SPAN
->(1)</SPAN
->
-or in a history file maintained by the user's shell.</P
-><P
->The <VAR
-CLASS="OPTION"
->-k</VAR
-> may also be used to specify a SIG(0) key used
+<span class="citerefentry"><span class="refentrytitle">ps</span>(1
+)</span>
+or in a history file maintained by the user's shell.
+</p>
+<p>
+The <code class="option">-k</code> may also be used to specify a SIG(0) key used
 to authenticate Dynamic DNS update requests.  In this case, the key
-specified is not an HMAC-MD5 key.</P
-><P
->By default
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+specified is not an HMAC-MD5 key.
+</p>
+<p>
+By default
+<span><strong class="command">nsupdate</strong></span>
 uses UDP to send update requests to the name server unless they are too
 large to fit in a UDP request in which case TCP will be used.
 The
-<VAR
-CLASS="OPTION"
->-v</VAR
->
+<code class="option">-v</code>
 option makes
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+<span><strong class="command">nsupdate</strong></span>
 use a TCP connection.
-This may be preferable when a batch of update requests is made.</P
-><P
->The <VAR
-CLASS="OPTION"
->-t</VAR
-> option sets the maximum time a update request can
+This may be preferable when a batch of update requests is made.
+</p>
+<p>The <code class="option">-t</code> option sets the maximum time a update request can
 take before it is aborted.  The default is 300 seconds.  Zero can be used
-to disable the timeout.</P
-><P
->The <VAR
-CLASS="OPTION"
->-u</VAR
-> option sets the UDP retry interval.  The default is
+to disable the timeout.
+</p>
+<p>The <code class="option">-u</code> option sets the UDP retry interval.  The default is
 3 seconds.  If zero the interval will be computed from the timeout interval
-and number of UDP retries.</P
-><P
->The <VAR
-CLASS="OPTION"
->-r</VAR
-> option sets the number of UDP retries. The default is
-3.  If zero only one update request will be made.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN82"
-></A
-><H2
->INPUT FORMAT</H2
-><P
-><B
-CLASS="COMMAND"
->nsupdate</B
->
+and number of UDP retries.
+</p>
+<p>The <code class="option">-r</code> option sets the number of UDP retries. The default is
+3.  If zero only one update request will be made.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526121"></a><h2>INPUT FORMAT</h2>
+<p>
+<span><strong class="command">nsupdate</strong></span>
 reads input from
-<VAR
-CLASS="PARAMETER"
->filename</VAR
->
+<em class="parameter"><code>filename</code></em>
 or standard input.
 Each command is supplied on exactly one line of input.
 Some commands are for administrative purposes.
@@ -342,471 +173,245 @@ contents of the zone.
 These checks set conditions that some name or set of
 resource records (RRset) either exists or is absent from the zone.
 These conditions must be met if the entire update request is to succeed.
-Updates will be rejected if the tests for the prerequisite conditions fail.</P
-><P
->Every update request consists of zero or more prerequisites
+Updates will be rejected if the tests for the prerequisite conditions fail.
+</p>
+<p>
+Every update request consists of zero or more prerequisites
 and zero or more updates.
 This allows a suitably authenticated update request to proceed if some
 specified resource records are present or missing from the zone.
-A blank input line (or the <B
-CLASS="COMMAND"
->send</B
-> command) causes the
+A blank input line (or the <span><strong class="command">send</strong></span> command) causes the
 accumulated commands to be sent as one Dynamic DNS update request to the
-name server.</P
-><P
->The command formats and their meaning are as follows:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><P
-><B
-CLASS="COMMAND"
->server</B
->  {servername} [port]</P
-></DT
-><DD
-><P
->Sends all dynamic update requests to the name server
-<VAR
-CLASS="PARAMETER"
->servername</VAR
->.
+name server.
+</p>
+<p>
+The command formats and their meaning are as follows:
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">server</code>  {servername} [port]</p></div>
+</span></dt>
+<dd><p>
+Sends all dynamic update requests to the name server
+<em class="parameter"><code>servername</code></em>.
 When no server statement is provided,
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+<span><strong class="command">nsupdate</strong></span>
 will send updates to the master server of the correct zone.
 The MNAME field of that zone's SOA record will identify the master
 server for that zone.
-<VAR
-CLASS="PARAMETER"
->port</VAR
->
+<em class="parameter"><code>port</code></em>
 is the port number on
-<VAR
-CLASS="PARAMETER"
->servername</VAR
->
+<em class="parameter"><code>servername</code></em>
 where the dynamic update requests get sent.
 If no port number is specified, the default DNS port number of 53 is
-used.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->local</B
->  {address} [port]</P
-></DT
-><DD
-><P
->Sends all dynamic update requests using the local
-<VAR
-CLASS="PARAMETER"
->address</VAR
->.
+used.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">local</code>  {address} [port]</p></div>
+</span></dt>
+<dd><p>
+Sends all dynamic update requests using the local
+<em class="parameter"><code>address</code></em>.
 
 When no local statement is provided,
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+<span><strong class="command">nsupdate</strong></span>
 will send updates using an address and port chosen by the system.
-<VAR
-CLASS="PARAMETER"
->port</VAR
->
+<em class="parameter"><code>port</code></em>
 can additionally be used to make requests come from a specific port.
-If no port number is specified, the system will assign one.&#13;</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->zone</B
->  {zonename}</P
-></DT
-><DD
-><P
->Specifies that all updates are to be made to the zone
-<VAR
-CLASS="PARAMETER"
->zonename</VAR
->.
+If no port number is specified, the system will assign one.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">zone</code>  {zonename}</p></div>
+</span></dt>
+<dd><p>
+Specifies that all updates are to be made to the zone
+<em class="parameter"><code>zonename</code></em>.
 If no
-<VAR
-CLASS="PARAMETER"
->zone</VAR
->
+<em class="parameter"><code>zone</code></em>
 statement is provided,
-<B
-CLASS="COMMAND"
->nsupdate</B
->
-will attempt determine the correct zone to update based on the rest of the input.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->class</B
->  {classname}</P
-></DT
-><DD
-><P
->Specify the default class.
-If no <VAR
-CLASS="PARAMETER"
->class</VAR
-> is specified the default class is
-<VAR
-CLASS="PARAMETER"
->IN</VAR
->.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->key</B
->  {name} {secret}</P
-></DT
-><DD
-><P
->Specifies that all updates are to be TSIG signed using the
-<VAR
-CLASS="PARAMETER"
->keyname</VAR
-> <VAR
-CLASS="PARAMETER"
->keysecret</VAR
-> pair.
-The <B
-CLASS="COMMAND"
->key</B
-> command
+<span><strong class="command">nsupdate</strong></span>
+will attempt determine the correct zone to update based on the rest of the input.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">class</code>  {classname}</p></div>
+</span></dt>
+<dd><p>
+Specify the default class.
+If no <em class="parameter"><code>class</code></em> is specified the default class is
+<em class="parameter"><code>IN</code></em>.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">key</code>  {name} {secret}</p></div>
+</span></dt>
+<dd><p>
+Specifies that all updates are to be TSIG signed using the
+<em class="parameter"><code>keyname</code></em> <em class="parameter"><code>keysecret</code></em> pair.
+The <span><strong class="command">key</strong></span> command
 overrides any key specified on the command line via
-<VAR
-CLASS="OPTION"
->-y</VAR
-> or <VAR
-CLASS="OPTION"
->-k</VAR
->.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->prereq nxdomain</B
->  {domain-name}</P
-></DT
-><DD
-><P
->Requires that no resource record of any type exists with name
-<VAR
-CLASS="PARAMETER"
->domain-name</VAR
->.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->prereq yxdomain</B
->  {domain-name}</P
-></DT
-><DD
-><P
->Requires that
-<VAR
-CLASS="PARAMETER"
->domain-name</VAR
->
-exists (has as at least one resource record, of any type).</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->prereq nxrrset</B
->  {domain-name} [class] {type}</P
-></DT
-><DD
-><P
->Requires that no resource record exists of the specified
-<VAR
-CLASS="PARAMETER"
->type</VAR
->,
-<VAR
-CLASS="PARAMETER"
->class</VAR
->
+<code class="option">-y</code> or <code class="option">-k</code>.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">prereq nxdomain</code>  {domain-name}</p></div>
+</span></dt>
+<dd><p>
+Requires that no resource record of any type exists with name
+<em class="parameter"><code>domain-name</code></em>.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">prereq yxdomain</code>  {domain-name}</p></div>
+</span></dt>
+<dd><p>
+Requires that
+<em class="parameter"><code>domain-name</code></em>
+exists (has as at least one resource record, of any type).
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">prereq nxrrset</code>  {domain-name} [class] {type}</p></div>
+</span></dt>
+<dd><p>
+Requires that no resource record exists of the specified
+<em class="parameter"><code>type</code></em>,
+<em class="parameter"><code>class</code></em>
 and
-<VAR
-CLASS="PARAMETER"
->domain-name</VAR
->.
+<em class="parameter"><code>domain-name</code></em>.
 If
-<VAR
-CLASS="PARAMETER"
->class</VAR
->
-is omitted, IN (internet) is assumed.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->prereq yxrrset</B
->  {domain-name} [class] {type}</P
-></DT
-><DD
-><P
->This requires that a resource record of the specified
-<VAR
-CLASS="PARAMETER"
->type</VAR
->,
-<VAR
-CLASS="PARAMETER"
->class</VAR
->
+<em class="parameter"><code>class</code></em>
+is omitted, IN (internet) is assumed.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">prereq yxrrset</code>  {domain-name} [class] {type}</p></div>
+</span></dt>
+<dd><p>
+This requires that a resource record of the specified
+<em class="parameter"><code>type</code></em>,
+<em class="parameter"><code>class</code></em>
 and
-<VAR
-CLASS="PARAMETER"
->domain-name</VAR
->
+<em class="parameter"><code>domain-name</code></em>
 must exist.
 If
-<VAR
-CLASS="PARAMETER"
->class</VAR
->
-is omitted, IN (internet) is assumed.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->prereq yxrrset</B
->  {domain-name} [class] {type} {data...}</P
-></DT
-><DD
-><P
->The
-<VAR
-CLASS="PARAMETER"
->data</VAR
->
+<em class="parameter"><code>class</code></em>
+is omitted, IN (internet) is assumed.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">prereq yxrrset</code>  {domain-name} [class] {type} {data...}</p></div>
+</span></dt>
+<dd><p>
+The
+<em class="parameter"><code>data</code></em>
 from each set of prerequisites of this form
 sharing a common
-<VAR
-CLASS="PARAMETER"
->type</VAR
->,
-<VAR
-CLASS="PARAMETER"
->class</VAR
->,
+<em class="parameter"><code>type</code></em>,
+<em class="parameter"><code>class</code></em>,
 and 
-<VAR
-CLASS="PARAMETER"
->domain-name</VAR
->
+<em class="parameter"><code>domain-name</code></em>
 are combined to form a set of RRs.  This set of RRs must
 exactly match the set of RRs existing in the zone at the
 given 
-<VAR
-CLASS="PARAMETER"
->type</VAR
->,
-<VAR
-CLASS="PARAMETER"
->class</VAR
->,
+<em class="parameter"><code>type</code></em>,
+<em class="parameter"><code>class</code></em>,
 and 
-<VAR
-CLASS="PARAMETER"
->domain-name</VAR
->.
+<em class="parameter"><code>domain-name</code></em>.
 The
-<VAR
-CLASS="PARAMETER"
->data</VAR
->
+<em class="parameter"><code>data</code></em>
 are written in the standard text representation of the resource record's
-RDATA.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->update delete</B
->  {domain-name} [ttl] [class] [type  [data...]]</P
-></DT
-><DD
-><P
->Deletes any resource records named
-<VAR
-CLASS="PARAMETER"
->domain-name</VAR
->.
+RDATA.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">update delete</code>  {domain-name} [ttl] [class] [type  [data...]]</p></div>
+</span></dt>
+<dd><p>
+Deletes any resource records named
+<em class="parameter"><code>domain-name</code></em>.
 If
-<VAR
-CLASS="PARAMETER"
->type</VAR
->
+<em class="parameter"><code>type</code></em>
 and
-<VAR
-CLASS="PARAMETER"
->data</VAR
->
+<em class="parameter"><code>data</code></em>
 is provided, only matching resource records will be removed.
 The internet class is assumed if
-<VAR
-CLASS="PARAMETER"
->class</VAR
->
+<em class="parameter"><code>class</code></em>
 is not supplied.  The
-<VAR
-CLASS="PARAMETER"
->ttl</VAR
->
-is ignored, and is only allowed for compatibility.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->update add</B
->  {domain-name} {ttl} [class] {type} {data...}</P
-></DT
-><DD
-><P
->Adds a new resource record with the specified
-<VAR
-CLASS="PARAMETER"
->ttl</VAR
->,
-<VAR
-CLASS="PARAMETER"
->class</VAR
->
+<em class="parameter"><code>ttl</code></em>
+is ignored, and is only allowed for compatibility.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">update add</code>  {domain-name} {ttl} [class] {type} {data...}</p></div>
+</span></dt>
+<dd><p>
+Adds a new resource record with the specified
+<em class="parameter"><code>ttl</code></em>,
+<em class="parameter"><code>class</code></em>
 and
-<VAR
-CLASS="PARAMETER"
->data</VAR
->.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->show</B
-> </P
-></DT
-><DD
-><P
->Displays the current message, containing all of the prerequisites and
-updates specified since the last send.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->send</B
-> </P
-></DT
-><DD
-><P
->Sends the current message.  This is equivalent to entering a blank line.</P
-></DD
-><DT
-><P
-><B
-CLASS="COMMAND"
->answer</B
-> </P
-></DT
-><DD
-><P
->Displays the answer.</P
-></DD
-></DL
-></DIV
->&#13;</P
-><P
->Lines beginning with a semicolon are comments and are ignored.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN255"
-></A
-><H2
->EXAMPLES</H2
-><P
->The examples below show how
-<B
-CLASS="COMMAND"
->nsupdate</B
->
+<em class="parameter"><code>data</code></em>.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">show</code> </p></div>
+</span></dt>
+<dd><p>
+Displays the current message, containing all of the prerequisites and
+updates specified since the last send.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">send</code> </p></div>
+</span></dt>
+<dd><p>
+Sends the current message.  This is equivalent to entering a blank line.
+</p></dd>
+<dt><span class="term">
+<div class="cmdsynopsis"><p><code class="command">answer</code> </p></div>
+</span></dt>
+<dd><p>
+Displays the answer.
+</p></dd>
+</dl></div>
+<p>
+</p>
+<p>
+Lines beginning with a semicolon are comments and are ignored.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526749"></a><h2>EXAMPLES</h2>
+<p>
+The examples below show how
+<span><strong class="command">nsupdate</strong></span>
 could be used to insert and delete resource records from the
-<SPAN
-CLASS="TYPE"
->example.com</SPAN
->
+<span class="type">example.com</span>
 zone.
 Notice that the input in each example contains a trailing blank line so that
 a group of commands are sent as one dynamic update request to the
 master name server for
-<SPAN
-CLASS="TYPE"
->example.com</SPAN
->.
+<span class="type">example.com</span>.
 
-<PRE
-CLASS="PROGRAMLISTING"
-># nsupdate
-&#62; update delete oldhost.example.com A
-&#62; update add newhost.example.com 86400 A 172.16.1.1
-&#62; send</PRE
-></P
-><P
->Any A records for
-<SPAN
-CLASS="TYPE"
->oldhost.example.com</SPAN
->
+</p>
+<pre class="programlisting">
+# nsupdate
+&gt; update delete oldhost.example.com A
+&gt; update add newhost.example.com 86400 A 172.16.1.1
+&gt; send
+</pre>
+<p>
+</p>
+<p>
+Any A records for
+<span class="type">oldhost.example.com</span>
 are deleted.
 and an A record for
-<SPAN
-CLASS="TYPE"
->newhost.example.com</SPAN
->
+<span class="type">newhost.example.com</span>
 it IP address 172.16.1.1 is added.
 The newly-added record has a 1 day TTL (86400 seconds)
-<PRE
-CLASS="PROGRAMLISTING"
-># nsupdate
-&#62; prereq nxdomain nickname.example.com
-&#62; update add nickname.example.com 86400 CNAME somehost.example.com
-&#62; send</PRE
-></P
-><P
->The prerequisite condition gets the name server to check that there
+</p>
+<pre class="programlisting">
+# nsupdate
+&gt; prereq nxdomain nickname.example.com
+&gt; update add nickname.example.com 86400 CNAME somehost.example.com
+&gt; send
+</pre>
+<p>
+</p>
+<p>
+The prerequisite condition gets the name server to check that there
 are no resource records of any type for
-<SPAN
-CLASS="TYPE"
->nickname.example.com</SPAN
->.
+<span class="type">nickname.example.com</span>.
 
 If there are, the update request fails.
 If this name does not exist, a CNAME for it is added.
@@ -814,149 +419,50 @@ This ensures that when the CNAME is added, it cannot conflict with the
 long-standing rule in RFC1034 that a name must not exist as any other
 record type if it exists as a CNAME.
 (The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have
-RRSIG, DNSKEY and NSEC records.)</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN268"
-></A
-><H2
->FILES</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->/etc/resolv.conf</CODE
-></DT
-><DD
-><P
->used to identify default name server</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->K{name}.+157.+{random}.key</CODE
-></DT
-><DD
-><P
->base-64 encoding of HMAC-MD5 key created by
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->K{name}.+157.+{random}.private</CODE
-></DT
-><DD
-><P
->base-64 encoding of HMAC-MD5 key created by
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN292"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2136</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC3007</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2104</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2845</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC1034</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2535</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2931</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->.&#13;</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN315"
-></A
-><H2
->BUGS</H2
-><P
->The TSIG key is redundantly stored in two separate files.
+RRSIG, DNSKEY and NSEC records.)
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526793"></a><h2>FILES</h2>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">/etc/resolv.conf</code></span></dt>
+<dd><p>
+used to identify default name server
+</p></dd>
+<dt><span class="term"><code class="constant">K{name}.+157.+{random}.key</code></span></dt>
+<dd><p>
+base-64 encoding of HMAC-MD5 key created by
+<span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>.
+</p></dd>
+<dt><span class="term"><code class="constant">K{name}.+157.+{random}.private</code></span></dt>
+<dd><p>
+base-64 encoding of HMAC-MD5 key created by
+<span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>.
+</p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525155"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">RFC2136</span></span>,
+<span class="citerefentry"><span class="refentrytitle">RFC3007</span></span>,
+<span class="citerefentry"><span class="refentrytitle">RFC2104</span></span>,
+<span class="citerefentry"><span class="refentrytitle">RFC2845</span></span>,
+<span class="citerefentry"><span class="refentrytitle">RFC1034</span></span>,
+<span class="citerefentry"><span class="refentrytitle">RFC2535</span></span>,
+<span class="citerefentry"><span class="refentrytitle">RFC2931</span></span>,
+<span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+<span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525226"></a><h2>BUGS</h2>
+<p>
+The TSIG key is redundantly stored in two separate files.
 This is a consequence of nsupdate using the DST library
 for its cryptographic operations, and may change in future
-releases.</P
-></DIV
-></BODY
-></HTML
->
+releases.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/rndc/rndc-confgen.8 b/contrib/bind9/bin/rndc/rndc-confgen.8
index b12e90cc569e..b29f0095cc0d 100644
--- a/contrib/bind9/bin/rndc/rndc-confgen.8
+++ b/contrib/bind9/bin/rndc/rndc-confgen.8
@@ -1,140 +1,183 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2001-2003  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2001, 2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: rndc-confgen.8,v 1.3.2.5.2.3 2004/06/03 05:35:48 marka Exp $
+.\" $Id: rndc-confgen.8,v 1.3.2.5.2.7 2005/10/13 02:33:50 marka Exp $
 .\"
-.TH "RNDC-CONFGEN" "8" "Aug 27, 2001" "BIND9" ""
-.SH NAME
-rndc-confgen \- rndc key generation tool
-.SH SYNOPSIS
-.sp
-\fBrndc-confgen\fR [ \fB-a\fR ]  [ \fB-b \fIkeysize\fB\fR ]  [ \fB-c \fIkeyfile\fB\fR ]  [ \fB-h\fR ]  [ \fB-k \fIkeyname\fB\fR ]  [ \fB-p \fIport\fB\fR ]  [ \fB-r \fIrandomfile\fB\fR ]  [ \fB-s \fIaddress\fB\fR ]  [ \fB-t \fIchrootdir\fB\fR ]  [ \fB-u \fIuser\fB\fR ] 
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "RNDC\-CONFGEN" "8" "Aug 27, 2001" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+rndc\-confgen \- rndc key generation tool
+.SH "SYNOPSIS"
+.HP 13
+\fBrndc\-confgen\fR [\fB\-a\fR] [\fB\-b\ \fR\fB\fIkeysize\fR\fR] [\fB\-c\ \fR\fB\fIkeyfile\fR\fR] [\fB\-h\fR] [\fB\-k\ \fR\fB\fIkeyname\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-r\ \fR\fB\fIrandomfile\fR\fR] [\fB\-s\ \fR\fB\fIaddress\fR\fR] [\fB\-t\ \fR\fB\fIchrootdir\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR]
 .SH "DESCRIPTION"
 .PP
-\fBrndc-confgen\fR generates configuration files
-for \fBrndc\fR. It can be used as a
-convenient alternative to writing the
-\fIrndc.conf\fR file
-and the corresponding \fBcontrols\fR
-and \fBkey\fR
-statements in \fInamed.conf\fR by hand.
-Alternatively, it can be run with the \fB-a\fR
-option to set up a \fIrndc.key\fR file and
-avoid the need for a \fIrndc.conf\fR file
-and a \fBcontrols\fR statement altogether.
+\fBrndc\-confgen\fR
+generates configuration files for
+\fBrndc\fR. It can be used as a convenient alternative to writing the
+\fIrndc.conf\fR
+file and the corresponding
+\fBcontrols\fR
+and
+\fBkey\fR
+statements in
+\fInamed.conf\fR
+by hand. Alternatively, it can be run with the
+\fB\-a\fR
+option to set up a
+\fIrndc.key\fR
+file and avoid the need for a
+\fIrndc.conf\fR
+file and a
+\fBcontrols\fR
+statement altogether.
 .SH "OPTIONS"
 .TP
-\fB-a\fR
-Do automatic \fBrndc\fR configuration.
-This creates a file \fIrndc.key\fR
-in \fI/etc\fR (or whatever
-sysconfdir
-was specified as when BIND was built)
-that is read by both \fBrndc\fR
-and \fBnamed\fR on startup. The
-\fIrndc.key\fR file defines a default
-command channel and authentication key allowing
-\fBrndc\fR to communicate with
-\fBnamed\fR on the local host
-with no further configuration. 
-
-Running \fBrndc-confgen -a\fR allows
-BIND 9 and \fBrndc\fR to be used as drop-in
-replacements for BIND 8 and \fBndc\fR,
-with no changes to the existing BIND 8
-\fInamed.conf\fR file.
-
-If a more elaborate configuration than that
-generated by \fBrndc-confgen -a\fR
-is required, for example if rndc is to be used remotely,
-you should run \fBrndc-confgen\fR without the
-\fB-a\fR option and set up a
-\fIrndc.conf\fR and
+\-a
+Do automatic
+\fBrndc\fR
+configuration. This creates a file
+\fIrndc.key\fR
+in
+\fI/etc\fR
+(or whatever
+\fIsysconfdir\fR
+was specified as when
+BIND
+was built) that is read by both
+\fBrndc\fR
+and
+\fBnamed\fR
+on startup. The
+\fIrndc.key\fR
+file defines a default command channel and authentication key allowing
+\fBrndc\fR
+to communicate with
+\fBnamed\fR
+on the local host with no further configuration.
+.sp
+Running
+\fBrndc\-confgen \-a\fR
+allows BIND 9 and
+\fBrndc\fR
+to be used as drop\-in replacements for BIND 8 and
+\fBndc\fR, with no changes to the existing BIND 8
+\fInamed.conf\fR
+file.
+.sp
+If a more elaborate configuration than that generated by
+\fBrndc\-confgen \-a\fR
+is required, for example if rndc is to be used remotely, you should run
+\fBrndc\-confgen\fR
+without the
+\fB\-a\fR
+option and set up a
+\fIrndc.conf\fR
+and
 \fInamed.conf\fR
 as directed.
 .TP
-\fB-b \fIkeysize\fB\fR
-Specifies the size of the authentication key in bits.
-Must be between 1 and 512 bits; the default is 128.
+\-b \fIkeysize\fR
+Specifies the size of the authentication key in bits. Must be between 1 and 512 bits; the default is 128.
 .TP
-\fB-c \fIkeyfile\fB\fR
-Used with the \fB-a\fR option to specify
-an alternate location for \fIrndc.key\fR.
+\-c \fIkeyfile\fR
+Used with the
+\fB\-a\fR
+option to specify an alternate location for
+\fIrndc.key\fR.
 .TP
-\fB-h\fR
+\-h
 Prints a short summary of the options and arguments to
-\fBrndc-confgen\fR.
+\fBrndc\-confgen\fR.
 .TP
-\fB-k \fIkeyname\fB\fR
-Specifies the key name of the rndc authentication key.
-This must be a valid domain name.
-The default is rndc-key.
+\-k \fIkeyname\fR
+Specifies the key name of the rndc authentication key. This must be a valid domain name. The default is
+\fBrndc\-key\fR.
 .TP
-\fB-p \fIport\fB\fR
-Specifies the command channel port where \fBnamed\fR
-listens for connections from \fBrndc\fR.
-The default is 953.
+\-p \fIport\fR
+Specifies the command channel port where
+\fBnamed\fR
+listens for connections from
+\fBrndc\fR. The default is 953.
 .TP
-\fB-r \fIrandomfile\fB\fR
-Specifies a source of random data for generating the
-authorization. If the operating
-system does not provide a \fI/dev/random\fR
-or equivalent device, the default source of randomness
-is keyboard input. \fIrandomdev\fR specifies
-the name of a character device or file containing random
-data to be used instead of the default. The special value
-\fIkeyboard\fR indicates that keyboard
-input should be used.
+\-r \fIrandomfile\fR
+Specifies a source of random data for generating the authorization. If the operating system does not provide a
+\fI/dev/random\fR
+or equivalent device, the default source of randomness is keyboard input.
+\fIrandomdev\fR
+specifies the name of a character device or file containing random data to be used instead of the default. The special value
+\fIkeyboard\fR
+indicates that keyboard input should be used.
 .TP
-\fB-s \fIaddress\fB\fR
-Specifies the IP address where \fBnamed\fR
+\-s \fIaddress\fR
+Specifies the IP address where
+\fBnamed\fR
 listens for command channel connections from
-\fBrndc\fR. The default is the loopback
-address 127.0.0.1.
+\fBrndc\fR. The default is the loopback address 127.0.0.1.
 .TP
-\fB-t \fIchrootdir\fB\fR
-Used with the \fB-a\fR option to specify
-a directory where \fBnamed\fR will run
-chrooted. An additional copy of the \fIrndc.key\fR
-will be written relative to this directory so that
-it will be found by the chrooted \fBnamed\fR.
+\-t \fIchrootdir\fR
+Used with the
+\fB\-a\fR
+option to specify a directory where
+\fBnamed\fR
+will run chrooted. An additional copy of the
+\fIrndc.key\fR
+will be written relative to this directory so that it will be found by the chrooted
+\fBnamed\fR.
 .TP
-\fB-u \fIuser\fB\fR
-Used with the \fB-a\fR option to set the owner
-of the \fIrndc.key\fR file generated. If
-\fB-t\fR is also specified only the file in
-the chroot area has its owner changed.
+\-u \fIuser\fR
+Used with the
+\fB\-a\fR
+option to set the owner of the
+\fIrndc.key\fR
+file generated. If
+\fB\-t\fR
+is also specified only the file in the chroot area has its owner changed.
 .SH "EXAMPLES"
 .PP
-To allow \fBrndc\fR to be used with
-no manual configuration, run
+To allow
+\fBrndc\fR
+to be used with no manual configuration, run
 .PP
-\fBrndc-confgen -a\fR
+\fBrndc\-confgen \-a\fR
 .PP
-To print a sample \fIrndc.conf\fR file and
-corresponding \fBcontrols\fR and \fBkey\fR
-statements to be manually inserted into \fInamed.conf\fR,
-run
+To print a sample
+\fIrndc.conf\fR
+file and corresponding
+\fBcontrols\fR
+and
+\fBkey\fR
+statements to be manually inserted into
+\fInamed.conf\fR, run
 .PP
-\fBrndc-confgen\fR
+\fBrndc\-confgen\fR
 .SH "SEE ALSO"
 .PP
 \fBrndc\fR(8),
 \fBrndc.conf\fR(5),
 \fBnamed\fR(8),
-\fIBIND 9 Administrator Reference Manual\fR.
+BIND 9 Administrator Reference Manual.
 .SH "AUTHOR"
 .PP
 Internet Systems Consortium
diff --git a/contrib/bind9/bin/rndc/rndc-confgen.docbook b/contrib/bind9/bin/rndc/rndc-confgen.docbook
index 272de459c19a..e0c5a68cf6f6 100644
--- a/contrib/bind9/bin/rndc/rndc-confgen.docbook
+++ b/contrib/bind9/bin/rndc/rndc-confgen.docbook
@@ -1,6 +1,8 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2001, 2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: rndc-confgen.docbook,v 1.3.2.1.4.3 2004/06/03 02:24:58 marka Exp $ -->
+<!-- $Id: rndc-confgen.docbook,v 1.3.2.1.4.5 2005/05/13 01:22:34 marka Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,19 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2001</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><application>rndc-confgen</application></refname>
     <refpurpose>rndc key generation tool</refpurpose>
diff --git a/contrib/bind9/bin/rndc/rndc-confgen.html b/contrib/bind9/bin/rndc/rndc-confgen.html
index 7292be2f99dc..ca7540084196 100644
--- a/contrib/bind9/bin/rndc/rndc-confgen.html
+++ b/contrib/bind9/bin/rndc/rndc-confgen.html
@@ -1,538 +1,185 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001-2003  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2001, 2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: rndc-confgen.html,v 1.3.2.5.2.4 2004/08/22 23:39:00 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->rndc-confgen</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><SPAN
-CLASS="APPLICATION"
->rndc-confgen</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->rndc-confgen</SPAN
->&nbsp;--&nbsp;rndc key generation tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->rndc-confgen</B
->  [<VAR
-CLASS="OPTION"
->-a</VAR
->] [<VAR
-CLASS="OPTION"
->-b <VAR
-CLASS="REPLACEABLE"
->keysize</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-c <VAR
-CLASS="REPLACEABLE"
->keyfile</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-h</VAR
->] [<VAR
-CLASS="OPTION"
->-k <VAR
-CLASS="REPLACEABLE"
->keyname</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-p <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-r <VAR
-CLASS="REPLACEABLE"
->randomfile</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-s <VAR
-CLASS="REPLACEABLE"
->address</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-t <VAR
-CLASS="REPLACEABLE"
->chrootdir</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-u <VAR
-CLASS="REPLACEABLE"
->user</VAR
-></VAR
->]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN44"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->rndc-confgen</B
-> generates configuration files
-	for <B
-CLASS="COMMAND"
->rndc</B
->.  It can be used as a
+<!-- $Id: rndc-confgen.html,v 1.3.2.5.2.11 2005/10/13 02:33:51 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>rndc-confgen</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">rndc-confgen</span> &#8212; rndc key generation tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">rndc-confgen</code>  [<code class="option">-a</code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-c <em class="replaceable"><code>keyfile</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [<code class="option">-s <em class="replaceable"><code>address</code></em></code>] [<code class="option">-t <em class="replaceable"><code>chrootdir</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525911"></a><h2>DESCRIPTION</h2>
+<p>
+        <span><strong class="command">rndc-confgen</strong></span> generates configuration files
+	for <span><strong class="command">rndc</strong></span>.  It can be used as a
         convenient alternative to writing the
-        <TT
-CLASS="FILENAME"
->rndc.conf</TT
-> file
-        and the corresponding <B
-CLASS="COMMAND"
->controls</B
->
-        and <B
-CLASS="COMMAND"
->key</B
->
-	statements in <TT
-CLASS="FILENAME"
->named.conf</TT
-> by hand.
-        Alternatively, it can be run with the <B
-CLASS="COMMAND"
->-a</B
->
-        option to set up a <TT
-CLASS="FILENAME"
->rndc.key</TT
-> file and
-        avoid the need for a <TT
-CLASS="FILENAME"
->rndc.conf</TT
-> file
-        and a <B
-CLASS="COMMAND"
->controls</B
-> statement altogether.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN57"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-a</DT
-><DD
-><P
->	      Do automatic <B
-CLASS="COMMAND"
->rndc</B
-> configuration.
-	      This creates a file <TT
-CLASS="FILENAME"
->rndc.key</TT
->
-	      in <TT
-CLASS="FILENAME"
->/etc</TT
-> (or whatever
-              <VAR
-CLASS="VARNAME"
->sysconfdir</VAR
->
-	      was specified as when <ACRONYM
-CLASS="ACRONYM"
->BIND</ACRONYM
-> was built)
-              that is read by both <B
-CLASS="COMMAND"
->rndc</B
->
-              and <B
-CLASS="COMMAND"
->named</B
-> on startup.  The
-	      <TT
-CLASS="FILENAME"
->rndc.key</TT
-> file defines a default
+        <code class="filename">rndc.conf</code> file
+        and the corresponding <span><strong class="command">controls</strong></span>
+        and <span><strong class="command">key</strong></span>
+	statements in <code class="filename">named.conf</code> by hand.
+        Alternatively, it can be run with the <span><strong class="command">-a</strong></span>
+        option to set up a <code class="filename">rndc.key</code> file and
+        avoid the need for a <code class="filename">rndc.conf</code> file
+        and a <span><strong class="command">controls</strong></span> statement altogether.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525957"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-a</span></dt>
+<dd>
+<p>
+	      Do automatic <span><strong class="command">rndc</strong></span> configuration.
+	      This creates a file <code class="filename">rndc.key</code>
+	      in <code class="filename">/etc</code> (or whatever
+              <code class="varname">sysconfdir</code>
+	      was specified as when <span class="acronym">BIND</span> was built)
+              that is read by both <span><strong class="command">rndc</strong></span>
+              and <span><strong class="command">named</strong></span> on startup.  The
+	      <code class="filename">rndc.key</code> file defines a default
               command channel and authentication key allowing
-	      <B
-CLASS="COMMAND"
->rndc</B
-> to communicate with
-	      <B
-CLASS="COMMAND"
->named</B
-> on the local host
+	      <span><strong class="command">rndc</strong></span> to communicate with
+	      <span><strong class="command">named</strong></span> on the local host
 	      with no further configuration.  
-	  </P
-><P
->	      Running <B
-CLASS="COMMAND"
->rndc-confgen -a</B
-> allows
-	      BIND 9 and <B
-CLASS="COMMAND"
->rndc</B
-> to be used as drop-in
-	      replacements for BIND 8 and <B
-CLASS="COMMAND"
->ndc</B
->,
+	  </p>
+<p>
+	      Running <span><strong class="command">rndc-confgen -a</strong></span> allows
+	      BIND 9 and <span><strong class="command">rndc</strong></span> to be used as drop-in
+	      replacements for BIND 8 and <span><strong class="command">ndc</strong></span>,
 	      with no changes to the existing BIND 8
-	      <TT
-CLASS="FILENAME"
->named.conf</TT
-> file.
-	  </P
-><P
->	      If a more elaborate configuration than that
-	      generated by <B
-CLASS="COMMAND"
->rndc-confgen -a</B
->
+	      <code class="filename">named.conf</code> file.
+	  </p>
+<p>
+	      If a more elaborate configuration than that
+	      generated by <span><strong class="command">rndc-confgen -a</strong></span>
 	      is required, for example if rndc is to be used remotely,
-	      you should run <B
-CLASS="COMMAND"
->rndc-confgen</B
-> without the
-	      <B
-CLASS="COMMAND"
->-a</B
-> option and set up a
-	      <TT
-CLASS="FILENAME"
->rndc.conf</TT
-> and
-	      <TT
-CLASS="FILENAME"
->named.conf</TT
->
+	      you should run <span><strong class="command">rndc-confgen</strong></span> without the
+	      <span><strong class="command">-a</strong></span> option and set up a
+	      <code class="filename">rndc.conf</code> and
+	      <code class="filename">named.conf</code>
 	      as directed.
-          </P
-></DD
-><DT
->-b <VAR
-CLASS="REPLACEABLE"
->keysize</VAR
-></DT
-><DD
-><P
->	       Specifies the size of the authentication key in bits.
+          </p>
+</dd>
+<dt><span class="term">-b <em class="replaceable"><code>keysize</code></em></span></dt>
+<dd><p>
+	       Specifies the size of the authentication key in bits.
 	       Must be between 1 and 512 bits; the default is 128.
-	  </P
-></DD
-><DT
->-c <VAR
-CLASS="REPLACEABLE"
->keyfile</VAR
-></DT
-><DD
-><P
->	       Used with the <B
-CLASS="COMMAND"
->-a</B
-> option to specify
-	       an alternate location for <TT
-CLASS="FILENAME"
->rndc.key</TT
->.
-	  </P
-></DD
-><DT
->-h</DT
-><DD
-><P
->	       Prints a short summary of the options and arguments to
-	       <B
-CLASS="COMMAND"
->rndc-confgen</B
->.
-	  </P
-></DD
-><DT
->-k <VAR
-CLASS="REPLACEABLE"
->keyname</VAR
-></DT
-><DD
-><P
->	       Specifies the key name of the rndc authentication key.
+	  </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>keyfile</code></em></span></dt>
+<dd><p>
+	       Used with the <span><strong class="command">-a</strong></span> option to specify
+	       an alternate location for <code class="filename">rndc.key</code>.
+	  </p></dd>
+<dt><span class="term">-h</span></dt>
+<dd><p>
+	       Prints a short summary of the options and arguments to
+	       <span><strong class="command">rndc-confgen</strong></span>.
+	  </p></dd>
+<dt><span class="term">-k <em class="replaceable"><code>keyname</code></em></span></dt>
+<dd><p>
+	       Specifies the key name of the rndc authentication key.
 	       This must be a valid domain name.
-	       The default is <CODE
-CLASS="CONSTANT"
->rndc-key</CODE
->.
-	  </P
-></DD
-><DT
->-p <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></DT
-><DD
-><P
->	       Specifies the command channel port where <B
-CLASS="COMMAND"
->named</B
->
-	       listens for connections from <B
-CLASS="COMMAND"
->rndc</B
->.
+	       The default is <code class="constant">rndc-key</code>.
+	  </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
+<dd><p>
+	       Specifies the command channel port where <span><strong class="command">named</strong></span>
+	       listens for connections from <span><strong class="command">rndc</strong></span>.
 	       The default is 953.
-	  </P
-></DD
-><DT
->-r <VAR
-CLASS="REPLACEABLE"
->randomfile</VAR
-></DT
-><DD
-><P
->	       Specifies a source of random data for generating the
+	  </p></dd>
+<dt><span class="term">-r <em class="replaceable"><code>randomfile</code></em></span></dt>
+<dd><p>
+	       Specifies a source of random data for generating the
 	       authorization.  If the operating
-	       system does not provide a <TT
-CLASS="FILENAME"
->/dev/random</TT
->
+	       system does not provide a <code class="filename">/dev/random</code>
 	       or equivalent device, the default source of randomness
-	       is keyboard input.  <TT
-CLASS="FILENAME"
->randomdev</TT
-> specifies
+	       is keyboard input.  <code class="filename">randomdev</code> specifies
 	       the name of a character device or file containing random
 	       data to be used instead of the default.  The special value
-	       <TT
-CLASS="FILENAME"
->keyboard</TT
-> indicates that keyboard
+	       <code class="filename">keyboard</code> indicates that keyboard
 	       input should be used.
-	  </P
-></DD
-><DT
->-s <VAR
-CLASS="REPLACEABLE"
->address</VAR
-></DT
-><DD
-><P
->	       Specifies the IP address where <B
-CLASS="COMMAND"
->named</B
->
+	  </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>address</code></em></span></dt>
+<dd><p>
+	       Specifies the IP address where <span><strong class="command">named</strong></span>
 	       listens for command channel connections from
-	       <B
-CLASS="COMMAND"
->rndc</B
->.  The default is the loopback
+	       <span><strong class="command">rndc</strong></span>.  The default is the loopback
 	       address 127.0.0.1.
-	  </P
-></DD
-><DT
->-t <VAR
-CLASS="REPLACEABLE"
->chrootdir</VAR
-></DT
-><DD
-><P
->	       Used with the <B
-CLASS="COMMAND"
->-a</B
-> option to specify
-	       a directory where <B
-CLASS="COMMAND"
->named</B
-> will run
-	       chrooted.  An additional copy of the <TT
-CLASS="FILENAME"
->rndc.key</TT
->
+	  </p></dd>
+<dt><span class="term">-t <em class="replaceable"><code>chrootdir</code></em></span></dt>
+<dd><p>
+	       Used with the <span><strong class="command">-a</strong></span> option to specify
+	       a directory where <span><strong class="command">named</strong></span> will run
+	       chrooted.  An additional copy of the <code class="filename">rndc.key</code>
 	       will be written relative to this directory so that
-	       it will be found by the chrooted <B
-CLASS="COMMAND"
->named</B
->.
-	  </P
-></DD
-><DT
->-u <VAR
-CLASS="REPLACEABLE"
->user</VAR
-></DT
-><DD
-><P
->	       Used with the <B
-CLASS="COMMAND"
->-a</B
-> option to set the owner
-	       of the <TT
-CLASS="FILENAME"
->rndc.key</TT
-> file generated.  If
-	       <B
-CLASS="COMMAND"
->-t</B
-> is also specified only the file in
+	       it will be found by the chrooted <span><strong class="command">named</strong></span>.
+	  </p></dd>
+<dt><span class="term">-u <em class="replaceable"><code>user</code></em></span></dt>
+<dd><p>
+	       Used with the <span><strong class="command">-a</strong></span> option to set the owner
+	       of the <code class="filename">rndc.key</code> file generated.  If
+	       <span><strong class="command">-t</strong></span> is also specified only the file in
 	       the chroot area has its owner changed.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN147"
-></A
-><H2
->EXAMPLES</H2
-><P
->        To allow <B
-CLASS="COMMAND"
->rndc</B
-> to be used with
+	  </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526270"></a><h2>EXAMPLES</h2>
+<p>
+        To allow <span><strong class="command">rndc</strong></span> to be used with
 	no manual configuration, run
-    </P
-><P
->        <KBD
-CLASS="USERINPUT"
->rndc-confgen -a</KBD
->
-    </P
-><P
->        To print a sample <TT
-CLASS="FILENAME"
->rndc.conf</TT
-> file and
-	corresponding <B
-CLASS="COMMAND"
->controls</B
-> and <B
-CLASS="COMMAND"
->key</B
->
-	statements to be manually inserted into <TT
-CLASS="FILENAME"
->named.conf</TT
->,
+    </p>
+<p>
+        <strong class="userinput"><code>rndc-confgen -a</code></strong>
+    </p>
+<p>
+        To print a sample <code class="filename">rndc.conf</code> file and
+	corresponding <span><strong class="command">controls</strong></span> and <span><strong class="command">key</strong></span>
+	statements to be manually inserted into <code class="filename">named.conf</code>,
 	run
-    </P
-><P
->        <KBD
-CLASS="USERINPUT"
->rndc-confgen</KBD
->
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN160"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->rndc</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->rndc.conf</SPAN
->(5)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN173"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+    </p>
+<p>
+        <strong class="userinput"><code>rndc-confgen</code></strong>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526314"></a><h2>SEE ALSO</h2>
+<p>
+      <span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526357"></a><h2>AUTHOR</h2>
+<p>
+        <span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/rndc/rndc.8 b/contrib/bind9/bin/rndc/rndc.8
index 356883bc4147..fba5529e4053 100644
--- a/contrib/bind9/bin/rndc/rndc.8
+++ b/contrib/bind9/bin/rndc/rndc.8
@@ -1,118 +1,118 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: rndc.8,v 1.24.206.2 2004/06/03 05:35:49 marka Exp $
+.\" $Id: rndc.8,v 1.24.206.5 2005/10/13 02:33:49 marka Exp $
 .\"
-.TH "RNDC" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "RNDC" "8" "June 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 rndc \- name server control utility
-.SH SYNOPSIS
-.sp
-\fBrndc\fR [ \fB-c \fIconfig-file\fB\fR ]  [ \fB-k \fIkey-file\fB\fR ]  [ \fB-s \fIserver\fB\fR ]  [ \fB-p \fIport\fB\fR ]  [ \fB-V\fR ]  [ \fB-y \fIkey_id\fB\fR ]  \fBcommand\fR
+.SH "SYNOPSIS"
+.HP 5
+\fBrndc\fR [\fB\-c\ \fR\fB\fIconfig\-file\fR\fR] [\fB\-k\ \fR\fB\fIkey\-file\fR\fR] [\fB\-s\ \fR\fB\fIserver\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-V\fR] [\fB\-y\ \fR\fB\fIkey_id\fR\fR] {command}
 .SH "DESCRIPTION"
 .PP
-\fBrndc\fR controls the operation of a name
-server. It supersedes the \fBndc\fR utility
-that was provided in old BIND releases. If
-\fBrndc\fR is invoked with no command line
-options or arguments, it prints a short summary of the
-supported commands and the available options and their
-arguments.
+\fBrndc\fR
+controls the operation of a name server. It supersedes the
+\fBndc\fR
+utility that was provided in old BIND releases. If
+\fBrndc\fR
+is invoked with no command line options or arguments, it prints a short summary of the supported commands and the available options and their arguments.
 .PP
-\fBrndc\fR communicates with the name server
-over a TCP connection, sending commands authenticated with
-digital signatures. In the current versions of
-\fBrndc\fR and \fBnamed\fR named
-the only supported authentication algorithm is HMAC-MD5,
-which uses a shared secret on each end of the connection.
-This provides TSIG-style authentication for the command
-request and the name server's response. All commands sent
-over the channel must be signed by a key_id known to the
-server.
+\fBrndc\fR
+communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. In the current versions of
+\fBrndc\fR
+and
+\fBnamed\fR
+named the only supported authentication algorithm is HMAC\-MD5, which uses a shared secret on each end of the connection. This provides TSIG\-style authentication for the command request and the name server's response. All commands sent over the channel must be signed by a key_id known to the server.
 .PP
-\fBrndc\fR reads a configuration file to
-determine how to contact the name server and decide what
-algorithm and key it should use.
+\fBrndc\fR
+reads a configuration file to determine how to contact the name server and decide what algorithm and key it should use.
 .SH "OPTIONS"
 .TP
-\fB-c \fIconfig-file\fB\fR
-Use \fIconfig-file\fR
+\-c \fIconfig\-file\fR
+Use
+\fIconfig\-file\fR
 as the configuration file instead of the default,
 \fI/etc/rndc.conf\fR.
 .TP
-\fB-k \fIkey-file\fB\fR
-Use \fIkey-file\fR
+\-k \fIkey\-file\fR
+Use
+\fIkey\-file\fR
 as the key file instead of the default,
 \fI/etc/rndc.key\fR. The key in
-\fI/etc/rndc.key\fR will be used to authenticate
-commands sent to the server if the \fIconfig-file\fR
+\fI/etc/rndc.key\fR
+will be used to authenticate commands sent to the server if the
+\fIconfig\-file\fR
 does not exist.
 .TP
-\fB-s \fIserver\fB\fR
-\fIserver\fR is
-the name or address of the server which matches a
-server statement in the configuration file for
-\fBrndc\fR. If no server is supplied on the
-command line, the host named by the default-server clause
-in the option statement of the configuration file will be
-used.
+\-s \fIserver\fR
+\fIserver\fR
+is the name or address of the server which matches a server statement in the configuration file for
+\fBrndc\fR. If no server is supplied on the command line, the host named by the default\-server clause in the option statement of the configuration file will be used.
 .TP
-\fB-p \fIport\fB\fR
+\-p \fIport\fR
 Send commands to TCP port
-\fIport\fR instead
-of BIND 9's default control channel port, 953.
+\fIport\fR
+instead of BIND 9's default control channel port, 953.
 .TP
-\fB-V\fR
+\-V
 Enable verbose logging.
 .TP
-\fB-y \fIkeyid\fB\fR
-Use the key \fIkeyid\fR
+\-y \fIkeyid\fR
+Use the key
+\fIkeyid\fR
 from the configuration file.
-\fIkeyid\fR must be
-known by named with the same algorithm and secret string
-in order for control message validation to succeed.
-If no \fIkeyid\fR
-is specified, \fBrndc\fR will first look
-for a key clause in the server statement of the server
-being used, or if no server statement is present for that
-host, then the default-key clause of the options statement.
-Note that the configuration file contains shared secrets
-which are used to send authenticated control commands
-to name servers. It should therefore not have general read
-or write access.
-.PP
-For the complete set of commands supported by \fBrndc\fR,
-see the BIND 9 Administrator Reference Manual or run
-\fBrndc\fR without arguments to see its help message.
+\fIkeyid\fR
+must be known by named with the same algorithm and secret string in order for control message validation to succeed. If no
+\fIkeyid\fR
+is specified,
+\fBrndc\fR
+will first look for a key clause in the server statement of the server being used, or if no server statement is present for that host, then the default\-key clause of the options statement. Note that the configuration file contains shared secrets which are used to send authenticated control commands to name servers. It should therefore not have general read or write access.
 .PP
+For the complete set of commands supported by
+\fBrndc\fR, see the BIND 9 Administrator Reference Manual or run
+\fBrndc\fR
+without arguments to see its help message.
 .SH "LIMITATIONS"
 .PP
-\fBrndc\fR does not yet support all the commands of
-the BIND 8 \fBndc\fR utility.
+\fBrndc\fR
+does not yet support all the commands of the BIND 8
+\fBndc\fR
+utility.
 .PP
 There is currently no way to provide the shared secret for a
-\fBkey_id\fR without using the configuration file.
+\fBkey_id\fR
+without using the configuration file.
 .PP
 Several error messages could be clearer.
 .SH "SEE ALSO"
 .PP
 \fBrndc.conf\fR(5),
 \fBnamed\fR(8),
-\fBnamed.conf\fR(5)
-\fBndc\fR(8),
-\fIBIND 9 Administrator Reference Manual\fR.
+\fBnamed.conf\fR(5)\fBndc\fR(8),
+BIND 9 Administrator Reference Manual.
 .SH "AUTHOR"
 .PP
 Internet Systems Consortium
diff --git a/contrib/bind9/bin/rndc/rndc.c b/contrib/bind9/bin/rndc/rndc.c
index c74828ce7c8f..63e8f23b9ff5 100644
--- a/contrib/bind9/bin/rndc/rndc.c
+++ b/contrib/bind9/bin/rndc/rndc.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rndc.c,v 1.77.2.5.2.13 2004/09/03 03:43:32 marka Exp $ */
+/* $Id: rndc.c,v 1.77.2.5.2.15 2005/03/17 03:58:27 marka Exp $ */
 
 /*
  * Principal Author: DCL
@@ -104,7 +104,8 @@ command is one of the following:\n\
   reconfig	Reload configuration file and new zones only.\n\
   stats		Write server statistics to the statistics file.\n\
   querylog	Toggle query logging.\n\
-  dumpdb	Dump cache(s) to the dump file (named_dump.db).\n\
+  dumpdb [-all|-cache|-zones] [view ...]\n\
+		Dump cache(s) to the dump file (named_dump.db).\n\
   stop		Save pending updates to master files and stop the server.\n\
   stop -p	Save pending updates to master files and stop the server\n\
 		reporting process id.\n\
diff --git a/contrib/bind9/bin/rndc/rndc.conf.5 b/contrib/bind9/bin/rndc/rndc.conf.5
index 5b61cfb00c1e..1c21e363d61a 100644
--- a/contrib/bind9/bin/rndc/rndc.conf.5
+++ b/contrib/bind9/bin/rndc/rndc.conf.5
@@ -1,35 +1,42 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: rndc.conf.5,v 1.21.206.2 2004/06/03 05:35:50 marka Exp $
+.\" $Id: rndc.conf.5,v 1.21.206.5 2005/10/13 02:33:50 marka Exp $
 .\"
-.TH "RNDC.CONF" "5" "June 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "\\FIRNDC.CONF\\FR" "5" "June 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 rndc.conf \- rndc configuration file
-.SH SYNOPSIS
-.sp
+.SH "SYNOPSIS"
+.HP 10
 \fBrndc.conf\fR
 .SH "DESCRIPTION"
 .PP
-\fIrndc.conf\fR is the configuration file
-for \fBrndc\fR, the BIND 9 name server control
-utility. This file has a similar structure and syntax to
-\fInamed.conf\fR. Statements are enclosed
-in braces and terminated with a semi-colon. Clauses in
-the statements are also semi-colon terminated. The usual
-comment styles are supported:
+\fIrndc.conf\fR
+is the configuration file for
+\fBrndc\fR, the BIND 9 name server control utility. This file has a similar structure and syntax to
+\fInamed.conf\fR. Statements are enclosed in braces and terminated with a semi\-colon. Clauses in the statements are also semi\-colon terminated. The usual comment styles are supported:
 .PP
 C style: /* */
 .PP
@@ -37,106 +44,111 @@ C++ style: // to end of line
 .PP
 Unix style: # to end of line
 .PP
-\fIrndc.conf\fR is much simpler than
-\fInamed.conf\fR. The file uses three
-statements: an options statement, a server statement
-and a key statement.
-.PP
-The \fBoptions\fR statement contains three clauses.
-The \fBdefault-server\fR clause is followed by the
-name or address of a name server. This host will be used when
-no name server is given as an argument to
-\fBrndc\fR. The \fBdefault-key\fR
-clause is followed by the name of a key which is identified by
-a \fBkey\fR statement. If no
-\fBkeyid\fR is provided on the rndc command line,
-and no \fBkey\fR clause is found in a matching
-\fBserver\fR statement, this default key will be
-used to authenticate the server's commands and responses. The
-\fBdefault-port\fR clause is followed by the port
-to connect to on the remote name server. If no
-\fBport\fR option is provided on the rndc command
-line, and no \fBport\fR clause is found in a
-matching \fBserver\fR statement, this default port
-will be used to connect.
-.PP
-After the \fBserver\fR keyword, the server statement
-includes a string which is the hostname or address for a name
-server. The statement has two possible clauses:
-\fBkey\fR and \fBport\fR. The key name must
-match the name of a key statement in the file. The port number
-specifies the port to connect to.
-.PP
-The \fBkey\fR statement begins with an identifying
-string, the name of the key. The statement has two clauses.
-\fBalgorithm\fR identifies the encryption algorithm
-for \fBrndc\fR to use; currently only HMAC-MD5 is
-supported. This is followed by a secret clause which contains
-the base-64 encoding of the algorithm's encryption key. The
-base-64 string is enclosed in double quotes.
-.PP
-There are two common ways to generate the base-64 string for the
-secret. The BIND 9 program \fBrndc-confgen\fR can
-be used to generate a random key, or the
-\fBmmencode\fR program, also known as
-\fBmimencode\fR, can be used to generate a base-64
-string from known input. \fBmmencode\fR does not
-ship with BIND 9 but is available on many systems. See the
-EXAMPLE section for sample command lines for each.
+\fIrndc.conf\fR
+is much simpler than
+\fInamed.conf\fR. The file uses three statements: an options statement, a server statement and a key statement.
+.PP
+The
+\fBoptions\fR
+statement contains three clauses. The
+\fBdefault\-server\fR
+clause is followed by the name or address of a name server. This host will be used when no name server is given as an argument to
+\fBrndc\fR. The
+\fBdefault\-key\fR
+clause is followed by the name of a key which is identified by a
+\fBkey\fR
+statement. If no
+\fBkeyid\fR
+is provided on the rndc command line, and no
+\fBkey\fR
+clause is found in a matching
+\fBserver\fR
+statement, this default key will be used to authenticate the server's commands and responses. The
+\fBdefault\-port\fR
+clause is followed by the port to connect to on the remote name server. If no
+\fBport\fR
+option is provided on the rndc command line, and no
+\fBport\fR
+clause is found in a matching
+\fBserver\fR
+statement, this default port will be used to connect.
+.PP
+After the
+\fBserver\fR
+keyword, the server statement includes a string which is the hostname or address for a name server. The statement has two possible clauses:
+\fBkey\fR
+and
+\fBport\fR. The key name must match the name of a key statement in the file. The port number specifies the port to connect to.
+.PP
+The
+\fBkey\fR
+statement begins with an identifying string, the name of the key. The statement has two clauses.
+\fBalgorithm\fR
+identifies the encryption algorithm for
+\fBrndc\fR
+to use; currently only HMAC\-MD5 is supported. This is followed by a secret clause which contains the base\-64 encoding of the algorithm's encryption key. The base\-64 string is enclosed in double quotes.
+.PP
+There are two common ways to generate the base\-64 string for the secret. The BIND 9 program
+\fBrndc\-confgen\fR
+can be used to generate a random key, or the
+\fBmmencode\fR
+program, also known as
+\fBmimencode\fR, can be used to generate a base\-64 string from known input.
+\fBmmencode\fR
+does not ship with BIND 9 but is available on many systems. See the EXAMPLE section for sample command lines for each.
 .SH "EXAMPLE"
 .sp
 .nf
     options {
-        default-server  localhost;
-        default-key     samplekey;
+        default\-server  localhost;
+        default\-key     samplekey;
       };
-
       server localhost {
         key             samplekey;
       };
-
       key samplekey {
-        algorithm       hmac-md5;
+        algorithm       hmac\-md5;
         secret          "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
       };
-    
-.sp
 .fi
 .PP
-In the above example, \fBrndc\fR will by default use
-the server at localhost (127.0.0.1) and the key called samplekey.
-Commands to the localhost server will use the samplekey key, which
-must also be defined in the server's configuration file with the
-same name and secret. The key statement indicates that samplekey
-uses the HMAC-MD5 algorithm and its secret clause contains the
-base-64 encoding of the HMAC-MD5 secret enclosed in double quotes.
+In the above example,
+\fBrndc\fR
+will by default use the server at localhost (127.0.0.1) and the key called samplekey. Commands to the localhost server will use the samplekey key, which must also be defined in the server's configuration file with the same name and secret. The key statement indicates that samplekey uses the HMAC\-MD5 algorithm and its secret clause contains the base\-64 encoding of the HMAC\-MD5 secret enclosed in double quotes.
 .PP
-To generate a random secret with \fBrndc-confgen\fR:
+To generate a random secret with
+\fBrndc\-confgen\fR:
 .PP
-\fBrndc-confgen\fR
+\fBrndc\-confgen\fR
 .PP
-A complete \fIrndc.conf\fR file, including the
-randomly generated key, will be written to the standard
-output. Commented out \fBkey\fR and
-\fBcontrols\fR statements for
-\fInamed.conf\fR are also printed.
+A complete
+\fIrndc.conf\fR
+file, including the randomly generated key, will be written to the standard output. Commented out
+\fBkey\fR
+and
+\fBcontrols\fR
+statements for
+\fInamed.conf\fR
+are also printed.
 .PP
-To generate a base-64 secret with \fBmmencode\fR:
+To generate a base\-64 secret with
+\fBmmencode\fR:
 .PP
 \fBecho "known plaintext for a secret" | mmencode\fR
 .SH "NAME SERVER CONFIGURATION"
 .PP
-The name server must be configured to accept rndc connections and
-to recognize the key specified in the \fIrndc.conf\fR
-file, using the controls statement in \fInamed.conf\fR.
-See the sections on the \fBcontrols\fR statement in the
-BIND 9 Administrator Reference Manual for details.
+The name server must be configured to accept rndc connections and to recognize the key specified in the
+\fIrndc.conf\fR
+file, using the controls statement in
+\fInamed.conf\fR. See the sections on the
+\fBcontrols\fR
+statement in the BIND 9 Administrator Reference Manual for details.
 .SH "SEE ALSO"
 .PP
 \fBrndc\fR(8),
-\fBrndc-confgen\fR(8),
+\fBrndc\-confgen\fR(8),
 \fBmmencode\fR(1),
-\fIBIND 9 Administrator Reference Manual\fR.
+BIND 9 Administrator Reference Manual.
 .SH "AUTHOR"
 .PP
 Internet Systems Consortium
diff --git a/contrib/bind9/bin/rndc/rndc.conf.docbook b/contrib/bind9/bin/rndc/rndc.conf.docbook
index 95f158b7602a..16b9caf43cbe 100644
--- a/contrib/bind9/bin/rndc/rndc.conf.docbook
+++ b/contrib/bind9/bin/rndc/rndc.conf.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: rndc.conf.docbook,v 1.4.206.2 2004/06/03 02:24:58 marka Exp $ -->
+<!-- $Id: rndc.conf.docbook,v 1.4.206.4 2005/05/12 21:36:04 sra Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,19 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><filename>rndc.conf</filename></refname>
     <refpurpose>rndc configuration file</refpurpose>
diff --git a/contrib/bind9/bin/rndc/rndc.conf.html b/contrib/bind9/bin/rndc/rndc.conf.html
index ea087c8be60e..05db0eca644c 100644
--- a/contrib/bind9/bin/rndc/rndc.conf.html
+++ b/contrib/bind9/bin/rndc/rndc.conf.html
@@ -1,238 +1,113 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: rndc.conf.html,v 1.5.2.1.4.3 2004/08/22 23:39:00 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->rndc.conf</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><TT
-CLASS="FILENAME"
->rndc.conf</TT
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><TT
-CLASS="FILENAME"
->rndc.conf</TT
->&nbsp;--&nbsp;rndc configuration file</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->rndc.conf</B
-> </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN16"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <TT
-CLASS="FILENAME"
->rndc.conf</TT
-> is the configuration file
-	for <B
-CLASS="COMMAND"
->rndc</B
->, the BIND 9 name server control
+<!-- $Id: rndc.conf.html,v 1.5.2.1.4.10 2005/10/13 02:33:51 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>rndc.conf</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><code class="filename">rndc.conf</code> &#8212; rndc configuration file</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525833"></a><h2>DESCRIPTION</h2>
+<p>
+        <code class="filename">rndc.conf</code> is the configuration file
+	for <span><strong class="command">rndc</strong></span>, the BIND 9 name server control
 	utility.  This file has a similar structure and syntax to
-	<TT
-CLASS="FILENAME"
->named.conf</TT
->.  Statements are enclosed
+	<code class="filename">named.conf</code>.  Statements are enclosed
 	in braces and terminated with a semi-colon.  Clauses in
 	the statements are also semi-colon terminated.  The usual
 	comment styles are supported:
-    </P
-><P
->        C style: /* */
-    </P
-><P
->        C++ style: // to end of line
-    </P
-><P
->        Unix style: # to end of line
-    </P
-><P
->        <TT
-CLASS="FILENAME"
->rndc.conf</TT
-> is much simpler than
-	<TT
-CLASS="FILENAME"
->named.conf</TT
->.  The file uses three
+    </p>
+<p>
+        C style: /* */
+    </p>
+<p>
+        C++ style: // to end of line
+    </p>
+<p>
+        Unix style: # to end of line
+    </p>
+<p>
+        <code class="filename">rndc.conf</code> is much simpler than
+	<code class="filename">named.conf</code>.  The file uses three
 	statements: an options statement, a server statement
 	and a key statement.
-    </P
-><P
->        The <VAR
-CLASS="OPTION"
->options</VAR
-> statement contains three clauses.
-	The <VAR
-CLASS="OPTION"
->default-server</VAR
-> clause is followed by the
+    </p>
+<p>
+        The <code class="option">options</code> statement contains three clauses.
+	The <code class="option">default-server</code> clause is followed by the
 	name or address of a name server.  This host will be used when
 	no name server is given as an argument to
-	<B
-CLASS="COMMAND"
->rndc</B
->.  The <VAR
-CLASS="OPTION"
->default-key</VAR
->
+	<span><strong class="command">rndc</strong></span>.  The <code class="option">default-key</code>
 	clause is followed by the name of a key which is identified by
-	a <VAR
-CLASS="OPTION"
->key</VAR
-> statement.  If no
-	<VAR
-CLASS="OPTION"
->keyid</VAR
-> is provided on the rndc command line,
-	and no <VAR
-CLASS="OPTION"
->key</VAR
-> clause is found in a matching
-	<VAR
-CLASS="OPTION"
->server</VAR
-> statement, this default key will be
+	a <code class="option">key</code> statement.  If no
+	<code class="option">keyid</code> is provided on the rndc command line,
+	and no <code class="option">key</code> clause is found in a matching
+	<code class="option">server</code> statement, this default key will be
 	used to authenticate the server's commands and responses.  The
-	<VAR
-CLASS="OPTION"
->default-port</VAR
-> clause is followed by the port
+	<code class="option">default-port</code> clause is followed by the port
 	to connect to on the remote name server.  If no
-	<VAR
-CLASS="OPTION"
->port</VAR
-> option is provided on the rndc command
-	line, and no <VAR
-CLASS="OPTION"
->port</VAR
-> clause is found in a
-	matching <VAR
-CLASS="OPTION"
->server</VAR
-> statement, this default port
+	<code class="option">port</code> option is provided on the rndc command
+	line, and no <code class="option">port</code> clause is found in a
+	matching <code class="option">server</code> statement, this default port
 	will be used to connect.
-    </P
-><P
->        After the <VAR
-CLASS="OPTION"
->server</VAR
-> keyword, the server statement
+    </p>
+<p>
+        After the <code class="option">server</code> keyword, the server statement
 	includes a string which is the hostname or address for a name
 	server.  The statement has two possible clauses:
-	<VAR
-CLASS="OPTION"
->key</VAR
-> and <VAR
-CLASS="OPTION"
->port</VAR
->. The key name must
+	<code class="option">key</code> and <code class="option">port</code>. The key name must
 	match the name of a key statement in the file.  The port number
 	specifies the port to connect to.
-    </P
-><P
->        The <VAR
-CLASS="OPTION"
->key</VAR
-> statement begins with an identifying
+    </p>
+<p>
+        The <code class="option">key</code> statement begins with an identifying
 	string, the name of the key.  The statement has two clauses.
-	<VAR
-CLASS="OPTION"
->algorithm</VAR
-> identifies the encryption algorithm
-	for <B
-CLASS="COMMAND"
->rndc</B
-> to use; currently only HMAC-MD5 is
+	<code class="option">algorithm</code> identifies the encryption algorithm
+	for <span><strong class="command">rndc</strong></span> to use; currently only HMAC-MD5 is
 	supported.  This is followed by a secret clause which contains
 	the base-64 encoding of the algorithm's encryption key.  The
 	base-64 string is enclosed in double quotes.
-    </P
-><P
->        There are two common ways to generate the base-64 string for the
-	secret.  The BIND 9 program <B
-CLASS="COMMAND"
->rndc-confgen</B
-> can
+    </p>
+<p>
+        There are two common ways to generate the base-64 string for the
+	secret.  The BIND 9 program <span><strong class="command">rndc-confgen</strong></span> can
 	be used to generate a random key, or the
-	<B
-CLASS="COMMAND"
->mmencode</B
-> program, also known as
-	<B
-CLASS="COMMAND"
->mimencode</B
->, can be used to generate a base-64
-	string from known input.  <B
-CLASS="COMMAND"
->mmencode</B
-> does not
+	<span><strong class="command">mmencode</strong></span> program, also known as
+	<span><strong class="command">mimencode</strong></span>, can be used to generate a base-64
+	string from known input.  <span><strong class="command">mmencode</strong></span> does not
 	ship with BIND 9 but is available on many systems.  See the
 	EXAMPLE section for sample command lines for each.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN54"
-></A
-><H2
->EXAMPLE</H2
-><PRE
-CLASS="PROGRAMLISTING"
->    options {
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525968"></a><h2>EXAMPLE</h2>
+<pre class="programlisting">
+    options {
         default-server  localhost;
         default-key     samplekey;
       };
@@ -245,133 +120,60 @@ CLASS="PROGRAMLISTING"
         algorithm       hmac-md5;
         secret          "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
       };
-    </PRE
-><P
->        In the above example, <B
-CLASS="COMMAND"
->rndc</B
-> will by default use
+    </pre>
+<p>
+        In the above example, <span><strong class="command">rndc</strong></span> will by default use
 	the server at localhost (127.0.0.1) and the key called samplekey.
 	Commands to the localhost server will use the samplekey key, which
 	must also be defined in the server's configuration file with the
 	same name and secret.  The key statement indicates that samplekey
 	uses the HMAC-MD5 algorithm and its secret clause contains the
 	base-64 encoding of the HMAC-MD5 secret enclosed in double quotes.
-    </P
-><P
->        To generate a random secret with <B
-CLASS="COMMAND"
->rndc-confgen</B
->:
-    </P
-><P
->        <KBD
-CLASS="USERINPUT"
->rndc-confgen</KBD
->
-    </P
-><P
->        A complete <TT
-CLASS="FILENAME"
->rndc.conf</TT
-> file, including the
+    </p>
+<p>
+        To generate a random secret with <span><strong class="command">rndc-confgen</strong></span>:
+    </p>
+<p>
+        <strong class="userinput"><code>rndc-confgen</code></strong>
+    </p>
+<p>
+        A complete <code class="filename">rndc.conf</code> file, including the
         randomly generated key, will be written to the standard
-        output.  Commented out <VAR
-CLASS="OPTION"
->key</VAR
-> and
-        <VAR
-CLASS="OPTION"
->controls</VAR
-> statements for
-        <TT
-CLASS="FILENAME"
->named.conf</TT
-> are also printed.
-    </P
-><P
->        To generate a base-64 secret with <B
-CLASS="COMMAND"
->mmencode</B
->:
-    </P
-><P
->        <KBD
-CLASS="USERINPUT"
->echo "known plaintext for a secret" | mmencode</KBD
->
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN72"
-></A
-><H2
->NAME SERVER CONFIGURATION</H2
-><P
->        The name server must be configured to accept rndc connections and
-	to recognize the key specified in the <TT
-CLASS="FILENAME"
->rndc.conf</TT
->
-	file, using the controls statement in <TT
-CLASS="FILENAME"
->named.conf</TT
->.
-	See the sections on the <VAR
-CLASS="OPTION"
->controls</VAR
-> statement in the
+        output.  Commented out <code class="option">key</code> and
+        <code class="option">controls</code> statements for
+        <code class="filename">named.conf</code> are also printed.
+    </p>
+<p>
+        To generate a base-64 secret with <span><strong class="command">mmencode</strong></span>:
+    </p>
+<p>
+        <strong class="userinput"><code>echo "known plaintext for a secret" | mmencode</code></strong>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526028"></a><h2>NAME SERVER CONFIGURATION</h2>
+<p>
+        The name server must be configured to accept rndc connections and
+	to recognize the key specified in the <code class="filename">rndc.conf</code>
+	file, using the controls statement in <code class="filename">named.conf</code>.
+	See the sections on the <code class="option">controls</code> statement in the
 	BIND 9 Administrator Reference Manual for details.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN78"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->rndc</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->rndc-confgen</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->mmencode</SPAN
->(1)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN91"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526049"></a><h2>SEE ALSO</h2>
+<p>
+      <span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">mmencode</span>(1)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526091"></a><h2>AUTHOR</h2>
+<p>
+        <span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/bin/rndc/rndc.docbook b/contrib/bind9/bin/rndc/rndc.docbook
index d4529ccfa6e2..afb88f5f6ea2 100644
--- a/contrib/bind9/bin/rndc/rndc.docbook
+++ b/contrib/bind9/bin/rndc/rndc.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: rndc.docbook,v 1.7.206.2 2004/06/03 02:24:58 marka Exp $ -->
+<!-- $Id: rndc.docbook,v 1.7.206.4 2005/05/12 21:36:05 sra Exp $ -->
 
 <refentry>
   <refentryinfo>
@@ -29,6 +31,19 @@
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
   <refnamediv>
     <refname><application>rndc</application></refname>
     <refpurpose>name server control utility</refpurpose>
diff --git a/contrib/bind9/bin/rndc/rndc.html b/contrib/bind9/bin/rndc/rndc.html
index 56f1aa1dba15..d23f4682c010 100644
--- a/contrib/bind9/bin/rndc/rndc.html
+++ b/contrib/bind9/bin/rndc/rndc.html
@@ -1,284 +1,112 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: rndc.html,v 1.7.2.1.4.3 2004/08/22 23:39:00 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->rndc</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
-><SPAN
-CLASS="APPLICATION"
->rndc</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->rndc</SPAN
->&nbsp;--&nbsp;name server control utility</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->rndc</B
->  [<VAR
-CLASS="OPTION"
->-c <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-k <VAR
-CLASS="REPLACEABLE"
->key-file</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-s <VAR
-CLASS="REPLACEABLE"
->server</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-p <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></VAR
->] [<VAR
-CLASS="OPTION"
->-V</VAR
->] [<VAR
-CLASS="OPTION"
->-y <VAR
-CLASS="REPLACEABLE"
->key_id</VAR
-></VAR
->] {command}</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN34"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->rndc</B
-> controls the operation of a name
-	server.  It supersedes the <B
-CLASS="COMMAND"
->ndc</B
-> utility
+<!-- $Id: rndc.html,v 1.7.2.1.4.10 2005/10/13 02:33:50 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>rndc</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">rndc</span> &#8212; name server control utility</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">rndc</code>  [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key-file</code></em></code>] [<code class="option">-s <em class="replaceable"><code>server</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-V</code>] [<code class="option">-y <em class="replaceable"><code>key_id</code></em></code>] {command}</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525886"></a><h2>DESCRIPTION</h2>
+<p>
+        <span><strong class="command">rndc</strong></span> controls the operation of a name
+	server.  It supersedes the <span><strong class="command">ndc</strong></span> utility
 	that was provided in old BIND releases.  If
-	<B
-CLASS="COMMAND"
->rndc</B
-> is invoked with no command line
+	<span><strong class="command">rndc</strong></span> is invoked with no command line
 	options or arguments, it prints a short summary of the
 	supported commands and the available options and their
 	arguments.
-    </P
-><P
->        <B
-CLASS="COMMAND"
->rndc</B
-> communicates with the name server
+    </p>
+<p>
+        <span><strong class="command">rndc</strong></span> communicates with the name server
 	over a TCP connection, sending commands authenticated with
 	digital signatures.  In the current versions of
-	<B
-CLASS="COMMAND"
->rndc</B
-> and <B
-CLASS="COMMAND"
->named</B
-> named
+	<span><strong class="command">rndc</strong></span> and <span><strong class="command">named</strong></span> named
         the only supported authentication algorithm is HMAC-MD5,
 	which uses a shared secret on each end of the connection.
 	This provides TSIG-style authentication for the command
 	request and the name server's response.  All commands sent
 	over the channel must be signed by a key_id known to the
 	server.
-    </P
-><P
->        <B
-CLASS="COMMAND"
->rndc</B
-> reads a configuration file to
+    </p>
+<p>
+        <span><strong class="command">rndc</strong></span> reads a configuration file to
 	determine how to contact the name server and decide what
 	algorithm and key it should use.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN46"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-c <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
-></DT
-><DD
-><P
->	      Use <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
->
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525927"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-c <em class="replaceable"><code>config-file</code></em></span></dt>
+<dd><p>
+	      Use <em class="replaceable"><code>config-file</code></em>
 	      as the configuration file instead of the default,
-	      <TT
-CLASS="FILENAME"
->/etc/rndc.conf</TT
->.
-	  </P
-></DD
-><DT
->-k <VAR
-CLASS="REPLACEABLE"
->key-file</VAR
-></DT
-><DD
-><P
->	      Use <VAR
-CLASS="REPLACEABLE"
->key-file</VAR
->
+	      <code class="filename">/etc/rndc.conf</code>.
+	  </p></dd>
+<dt><span class="term">-k <em class="replaceable"><code>key-file</code></em></span></dt>
+<dd><p>
+	      Use <em class="replaceable"><code>key-file</code></em>
 	      as the key file instead of the default,
-	      <TT
-CLASS="FILENAME"
->/etc/rndc.key</TT
->.  The key in
-	      <TT
-CLASS="FILENAME"
->/etc/rndc.key</TT
-> will be used to authenticate
-	      commands sent to the server if the <VAR
-CLASS="REPLACEABLE"
->config-file</VAR
->
+	      <code class="filename">/etc/rndc.key</code>.  The key in
+	      <code class="filename">/etc/rndc.key</code> will be used to authenticate
+	      commands sent to the server if the <em class="replaceable"><code>config-file</code></em>
 	      does not exist.
-	  </P
-></DD
-><DT
->-s <VAR
-CLASS="REPLACEABLE"
->server</VAR
-></DT
-><DD
-><P
->	       <VAR
-CLASS="REPLACEABLE"
->server</VAR
-> is
+	  </p></dd>
+<dt><span class="term">-s <em class="replaceable"><code>server</code></em></span></dt>
+<dd><p>
+	       <em class="replaceable"><code>server</code></em> is
 	       the name or address of the server which matches a
 	       server statement in the configuration file for
-	       <B
-CLASS="COMMAND"
->rndc</B
->.  If no server is supplied on the
+	       <span><strong class="command">rndc</strong></span>.  If no server is supplied on the
 	       command line, the host named by the default-server clause
 	       in the option statement of the configuration file will be
 	       used.
-	  </P
-></DD
-><DT
->-p <VAR
-CLASS="REPLACEABLE"
->port</VAR
-></DT
-><DD
-><P
->	       Send commands to TCP port
-	       <VAR
-CLASS="REPLACEABLE"
->port</VAR
-> instead
+	  </p></dd>
+<dt><span class="term">-p <em class="replaceable"><code>port</code></em></span></dt>
+<dd><p>
+	       Send commands to TCP port
+	       <em class="replaceable"><code>port</code></em> instead
 	       of BIND 9's default control channel port, 953.
-	  </P
-></DD
-><DT
->-V</DT
-><DD
-><P
->	       Enable verbose logging.
-	  </P
-></DD
-><DT
->-y <VAR
-CLASS="REPLACEABLE"
->keyid</VAR
-></DT
-><DD
-><P
->	       Use the key <VAR
-CLASS="REPLACEABLE"
->keyid</VAR
->
+	  </p></dd>
+<dt><span class="term">-V</span></dt>
+<dd><p>
+	       Enable verbose logging.
+	  </p></dd>
+<dt><span class="term">-y <em class="replaceable"><code>keyid</code></em></span></dt>
+<dd><p>
+	       Use the key <em class="replaceable"><code>keyid</code></em>
 	       from the configuration file.
-	       <VAR
-CLASS="REPLACEABLE"
->keyid</VAR
-> must be
+	       <em class="replaceable"><code>keyid</code></em> must be
 	       known by named with the same algorithm and secret string
 	       in order for control message validation to succeed.
-	       If no <VAR
-CLASS="REPLACEABLE"
->keyid</VAR
->
-	       is specified, <B
-CLASS="COMMAND"
->rndc</B
-> will first look
+	       If no <em class="replaceable"><code>keyid</code></em>
+	       is specified, <span><strong class="command">rndc</strong></span> will first look
 	       for a key clause in the server statement of the server
 	       being used, or if no server statement is present for that
 	       host, then the default-key clause of the options statement.
@@ -286,103 +114,43 @@ CLASS="COMMAND"
 	       which are used to send authenticated control commands
 	       to name servers.  It should therefore not have general read
 	       or write access.
-	  </P
-></DD
-></DL
-></DIV
-><P
->      For the complete set of commands supported by <B
-CLASS="COMMAND"
->rndc</B
->,
+	  </p></dd>
+</dl></div>
+<p>
+      For the complete set of commands supported by <span><strong class="command">rndc</strong></span>,
       see the BIND 9 Administrator Reference Manual or run
-      <B
-CLASS="COMMAND"
->rndc</B
-> without arguments to see its help message.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN94"
-></A
-><H2
->LIMITATIONS</H2
-><P
->        <B
-CLASS="COMMAND"
->rndc</B
-> does not yet support all the commands of
-	the BIND 8 <B
-CLASS="COMMAND"
->ndc</B
-> utility.
-    </P
-><P
->        There is currently no way to provide the shared secret for a
-        <VAR
-CLASS="OPTION"
->key_id</VAR
-> without using the configuration file.
-    </P
-><P
->        Several error messages could be clearer.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN102"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->rndc.conf</SPAN
->(5)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->named.conf</SPAN
->(5)</SPAN
->
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->ndc</SPAN
->(8)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN118"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Systems Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
+      <span><strong class="command">rndc</strong></span> without arguments to see its help message.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526109"></a><h2>LIMITATIONS</h2>
+<p>
+        <span><strong class="command">rndc</strong></span> does not yet support all the commands of
+	the BIND 8 <span><strong class="command">ndc</strong></span> utility.
+    </p>
+<p>
+        There is currently no way to provide the shared secret for a
+        <code class="option">key_id</code> without using the configuration file.
+    </p>
+<p>
+        Several error messages could be clearer.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526138"></a><h2>SEE ALSO</h2>
+<p>
+      <span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">named.conf</span>(5)</span>
+      <span class="citerefentry"><span class="refentrytitle">ndc</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526190"></a><h2>AUTHOR</h2>
+<p>
+        <span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/configure.in b/contrib/bind9/configure.in
index 9aff151668c8..b14b489bb2b7 100644
--- a/contrib/bind9/configure.in
+++ b/contrib/bind9/configure.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -18,7 +18,7 @@ AC_DIVERT_PUSH(1)dnl
 esyscmd([sed "s/^/# /" COPYRIGHT])dnl
 AC_DIVERT_POP()dnl
 
-AC_REVISION($Revision: 1.294.2.23.2.39 $)
+AC_REVISION($Revision: 1.294.2.23.2.51 $)
 
 AC_INIT(lib/dns/name.c)
 AC_PREREQ(2.13)
@@ -261,6 +261,7 @@ AC_TRY_COMPILE(, [
 
 AC_TYPE_SIZE_T
 AC_CHECK_TYPE(ssize_t, int)
+AC_CHECK_TYPE(uintptr_t,unsigned long)
 AC_CHECK_TYPE(socklen_t,
 [AC_DEFINE(ISC_SOCKADDR_LEN_T, socklen_t)],
 [
@@ -608,158 +609,7 @@ esac
 #
 AC_CHECK_FUNC(arc4random, AC_DEFINE(HAVE_ARC4RANDOM))
 
-#
-# Begin pthreads checking.
-#
-# First, decide whether to use multithreading or not.
-#
-# Enable multithreading by default on systems where it is known
-# to work well, and where debugging of multithreaded programs
-# is supported.
-#
-
-AC_MSG_CHECKING(whether to build with thread support)
-
-case $host in
-*-dec-osf*)
-	use_threads=true ;;
-[*-solaris2.[0-6]])
-	# Thread signals are broken on Solaris 2.6; they are sometimes
-	# delivered to the wrong thread.
-	use_threads=false ;;
-*-solaris*)
-	use_threads=true ;;
-*-ibm-aix*)
-	use_threads=true ;;
-*-hp-hpux10*)
-	use_threads=false ;;
-*-hp-hpux11*)
-	use_threads=true ;;
-*-sgi-irix*)
-	use_threads=true ;;
-*-sco-sysv*uw*|*-*-sysv*UnixWare*)
-        # UnixWare
-	use_threads=false ;;
-*-*-sysv*OpenUNIX*)
-        # UnixWare
-	use_threads=true ;;
-*-netbsd*)
-	if test -r /usr/lib/libpthread.so ; then
-	    use_threads=true
-	else
-	    # Socket I/O optimizations introduced in 9.2 expose a
-	    # bug in unproven-pthreads; see PR #12650
-	    use_threads=false
-	fi
-	;;
-*-openbsd*)
-	# OpenBSD users have reported that named dumps core on
-	# startup when built with threads.
-	use_threads=false ;;
-*-freebsd*)
-	use_threads=false ;;
-*-bsdi[234]*)
-	# Thread signals do not work reliably on some versions of BSD/OS.
-	use_threads=false ;;
-*-bsdi5*)
-	use_threads=true ;;
-*-linux*)
-   	# Threads are disabled on Linux by default because most
-	# Linux kernels produce unusable core dumps from multithreaded
-	# programs, and because of limitations in setuid().
-	use_threads=false ;;	
-*)
-	use_threads=false ;;
-esac
-
-AC_ARG_ENABLE(threads,
-	[  --enable-threads	enable multithreading])
-case "$enable_threads" in
-	yes)
-		use_threads=true
-		;;
-	no)
-		use_threads=false
-		;;
-	'')
-		# Use system-dependent default
-		;;
-	*)
-	    	AC_MSG_ERROR([--enable-threads takes yes or no])
-		;;
-esac
-
-if $use_threads
-then
-	AC_MSG_RESULT(yes)
-else
-	AC_MSG_RESULT(no)	
-fi
-
-if $use_threads
-then
-	#
-	# Search for / configure pthreads in a system-dependent fashion.
-	#
-	case "$host" in
-	  *-netbsd*)
-		# NetBSD has multiple pthreads implementations.	 The
-		# recommended one to use is "unproven-pthreads".  The
-		# older "mit-pthreads" may also work on some NetBSD
-		# versions.  The PTL2 thread library does not
-		# currently work with bind9, but can be chosen with
-		# the --with-ptl2 option for those who wish to
-		# experiment with it.
-		CC="gcc"
-		AC_MSG_CHECKING(which NetBSD thread library to use)
-
-		AC_ARG_WITH(ptl2,
-[  --with-ptl2		on NetBSD, use the ptl2 thread library (experimental)],
-		    use_ptl2="$withval", use_ptl2="no")
-
-		: ${LOCALBASE:=/usr/pkg}
-
-		if test "X$use_ptl2" = "Xyes"
-		then
-			AC_MSG_RESULT(PTL2)
-			AC_MSG_WARN(
-[linking with PTL2 is highly experimental and not expected to work])
-			CC=ptlgcc
-		else
-			if test -r /usr/lib/libpthread.so
-			then
-				AC_MSG_RESULT(native)
-				LIBS="-lpthread $LIBS"
-			else
-				if test ! -d $LOCALBASE/pthreads
-				then
-					AC_MSG_RESULT(none)
-					AC_MSG_ERROR("could not find thread libraries")
-				fi
-
-				if $use_threads
-				then
-					AC_MSG_RESULT(mit-pthreads/unproven-pthreads)
-					pkg="$LOCALBASE/pthreads"
-					lib1="-L$pkg/lib -Wl,-R$pkg/lib"
-					lib2="-lpthread -lm -lgcc -lpthread"
-					LIBS="$lib1 $lib2 $LIBS"
-					CPPFLAGS="$CPPFLAGS -I$pkg/include"
-					STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include"
-				fi
-			fi
-		fi
-		;;
-		*)
-			AC_CHECK_LIB(pthread, pthread_create,,
-				AC_CHECK_LIB(pthread, __pthread_create,,
-				AC_CHECK_LIB(pthread, __pthread_create_system,,
-				AC_CHECK_LIB(c_r, pthread_create,,
-				AC_CHECK_LIB(c, pthread_create,,
-				AC_MSG_ERROR("could not find thread libraries"))))))
-		;;
-	esac
-fi
+sinclude(config.threads.in)dnl
 
 if $use_threads
 then
@@ -790,7 +640,11 @@ then
 		*-freebsd*)
 			AC_CHECK_LIB(c_r, sigwait, AC_DEFINE(HAVE_SIGWAIT),)
 			case $host in
-			*-freebsd5.3|*-freebsd5.3.*)
+			*-freebsd5.[[012]]|*-freebsd5.[[012]].*);;
+			*-freebsd5.[[3456789]]|*-freebsd5.[[3456789]].*)
+				AC_DEFINE(NEED_PTHREAD_SCOPE_SYSTEM)
+				;;
+			*-freebsd6.*)
 				AC_DEFINE(NEED_PTHREAD_SCOPE_SYSTEM)
 				;;
 			esac
@@ -884,7 +738,6 @@ fi
 
 AC_SUBST(ALWAYS_DEFINES)
 AC_SUBST(ISC_PLATFORM_USETHREADS)
-
 ISC_THREAD_DIR=$thread_dir
 AC_SUBST(ISC_THREAD_DIR)
 
@@ -939,7 +792,7 @@ if test "X$GCC" = "Xyes"; then
 	STD_CWARNINGS="$STD_CWARNINGS -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat"
 	case "$host" in
 	*-hp-hpux*)
-		LDFLAGS="-Wl,+vnocompatwarnings $LDFALGS"
+		LDFLAGS="-Wl,+vnocompatwarnings $LDFLAGS"
 		;;
 	esac
 else
@@ -961,11 +814,11 @@ else
 			;;
 		*)
 			# Turn off the pointlessly noisy warnings.
-			STD_CWARNINGS="+w1 +W 474,530"
+			STD_CWARNINGS="+w1 +W 474,530,2193,2236"
 			;;
 		esac
 		CCOPT="$CCOPT -Ae -z"
-		LDFLAGS="-Wl,+vnocompatwarnings $LDFALGS"
+		LDFLAGS="-Wl,+vnocompatwarnings $LDFLAGS"
 		MKDEPPROG='cc -Ae -E -Wp,-M >/dev/null 2>>$TMP'
 		;;
 	*-sgi-irix*)
@@ -1414,6 +1267,10 @@ char a[16],b[64]; return(inet_ntop(AF_INET6, a, b, sizeof(b)) == (char*)0);}],
         [AC_MSG_RESULT(no)
         ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_ntop.$O"
         ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_ntop.c"
+        ISC_PLATFORM_NEEDNTOP="#define ISC_PLATFORM_NEEDNTOP 1"],
+        [AC_MSG_RESULT(assuming inet_ntop needed)
+        ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_ntop.$O"
+        ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_ntop.c"
         ISC_PLATFORM_NEEDNTOP="#define ISC_PLATFORM_NEEDNTOP 1"])
 
 
@@ -1437,7 +1294,13 @@ main() { char a[16]; return (inet_pton(AF_INET, "1.2.3", a) == 1 ? 1 :
         ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_pton.c"
         ISC_PLATFORM_NEEDPTON="#define ISC_PLATFORM_NEEDPTON 1"],
 	[AC_MSG_RESULT(assuming target platform has working inet_pton)
-	ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"])
+	ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"],
+        [AC_MSG_RESULT(assuming inet_pton needed)
+        ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_pton.$O"
+        ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_pton.c"
+        ISC_PLATFORM_NEEDPTON="#define ISC_PLATFORM_NEEDPTON 1"],
+        [AC_MSG_RESULT(assuming target platform has working inet_pton)
+        ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"])
 
 AC_MSG_CHECKING([for inet_aton])
 AC_TRY_LINK([
@@ -1703,9 +1566,15 @@ AC_CHECK_FUNC(memmove,
 AC_SUBST(ISC_PLATFORM_NEEDMEMMOVE)
 
 AC_CHECK_FUNC(strtoul,
-	[ISC_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL"],
-	[ISC_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1"])
+	[ISC_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL"
+	 LWRES_PLATFORM_NEEDSTRTOUL="#undef ISC_PLATFORM_NEEDSTRTOUL"
+	 GENRANDOMLIB=""],
+	[ISC_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1"
+	 LWRES_PLATFORM_NEEDSTRTOUL="#define ISC_PLATFORM_NEEDSTRTOUL 1"
+	 "GENRANDOMLIB=${ISCLIBS}"])
 AC_SUBST(ISC_PLATFORM_NEEDSTRTOUL)
+AC_SUBST(LWRES_PLATFORM_NEEDSTRTOUL)
+AC_SUBST(GENRANDOMLIB)
 
 AC_CHECK_FUNC(strlcpy,
 	[ISC_PLATFORM_NEEDSTRLCPY="#undef ISC_PLATFORM_NEEDSTRLCPY"],
@@ -1760,6 +1629,9 @@ AC_SUBST(ISC_EXTRA_SRCS)
 # will produce a inconsistant result in the later case.  If the compiler
 # fails due to seeing "%lld" we fall back to "l".
 #
+# Digital Unix 4.0 (gcc?) (long long) is 64 bits as is its long. It uses
+# %ld even for (long long)/
+#
 # Win32 uses "%I64d", but that's defined elsewhere since we don't use
 # configure on Win32.
 #
@@ -1776,12 +1648,16 @@ main() {
 } 
 ],
 	[AC_MSG_RESULT(ll)
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'],
+	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'
+	LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "ll"'],
 	[AC_MSG_RESULT(l)
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'],
+	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'
+	LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "l"'],
 	[AC_MSG_RESULT(assuming target platform uses ll)
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'])
+	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'
+	LWRES_PLATFORM_QUADFORMAT='#define LWRES_PLATFORM_QUADFORMAT "ll"'])
 AC_SUBST(ISC_PLATFORM_QUADFORMAT)
+AC_SUBST(LWRES_PLATFORM_QUADFORMAT)
 
 #
 # Security Stuff
@@ -1803,6 +1679,15 @@ AC_CHECK_HEADERS(sys/prctl.h)
 #
 AC_CHECK_FUNC(tzset, AC_DEFINE(HAVE_TZSET))
 
+AC_MSG_CHECKING(for optarg decarartion)
+AC_TRY_COMPILE([
+#include <unistd.h>
+],
+[optarg = 0;],
+[AC_MSG_RESULT(yes)],
+[AC_MSG_RESULT(no)
+AC_DEFINE(NEED_OPTARG, 1, [Defined if extern char *optarg is not declared.])])
+
 #
 # BSD/OS, and perhaps some others, don't define rlim_t.
 #
@@ -1843,7 +1728,9 @@ ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE long long int"],
 [AC_MSG_ERROR([unable to determine sizeof rlim_cur])
 ],[AC_MSG_ERROR(this cannot happen)])
 ],[AC_MSG_ERROR(this cannot happen)])
-],[AC_MSG_ERROR(cannot determine type of rlim_cur when cross compiling - define rlim_t)])
+],[
+ISC_PLATFORM_RLIMITTYPE="#define ISC_PLATFORM_RLIMITTYPE long long int"
+AC_MSG_RESULT(cannot determine type of rlim_cur when cross compiling - assuming long long int)])
 ])
 AC_SUBST(ISC_PLATFORM_RLIMITTYPE)
 
@@ -1958,30 +1845,50 @@ esac
 AC_SUBST(ISC_PLATFORM_HAVEIFNAMETOINDEX)
 
 #
+#  The following sets up how non-blocking i/o is established.
+#  Sunos, cygwin and solaris 2.x (x<5) require special handling.
+#
+case "$host" in
+*-sunos*) AC_DEFINE(PORT_NONBLOCK, O_NDELAY);;
+*-cygwin*) AC_DEFINE(PORT_NONBLOCK, O_NDELAY);;
+*-solaris2.[[01234]])
+	AC_DEFINE(PORT_NONBLOCK, O_NONBLOCK)
+	AC_DEFINE(USE_FIONBIO_IOCTL, 1,
+		  [Defined if you need to use ioctl(FIONBIO) instead a fcntl call to make non-blocking.])
+	;;
+*) AC_DEFINE(PORT_NONBLOCK, O_NONBLOCK,
+	     [Sets which flag to pass to open/fcntl to make non-blocking (O_NDELAY/O_NONBLOCK).])
+	;;
+esac
+#
 # The following sections deal with tools used for formatting
 # the documentation.  They are all optional, unless you are
 # a developer editing the documentation source.
 #
 
-# Directory trees where SGML files are commonly found.
-sgmltrees="/usr/pkg/share/sgml /usr/local/share/sgml /usr/share/sgml"
-
 #
-# Look for openjade.  Plain jade is no longer supported.
+# Look for TeX.
 #
 
-AC_PATH_PROGS(OPENJADE, openjade, openjade)
-AC_SUBST(OPENJADE)
+AC_PATH_PROGS(LATEX, latex, latex)
+AC_SUBST(LATEX)
+
+AC_PATH_PROGS(PDFLATEX, pdflatex, pdflatex)
+AC_SUBST(PDFLATEX)
 
 #
-# Look for TeX.
+# Look for xsltproc (libxslt)
 #
 
-AC_PATH_PROGS(JADETEX, jadetex, jadetex)
-AC_SUBST(JADETEX)
+AC_PATH_PROG(XSLTPROC, xsltproc, xsltproc)
+AC_SUBST(XSLTPROC)
+
+#
+# Look for xmllint (libxml2)
+#
 
-AC_PATH_PROGS(PDFJADETEX, pdfjadetex, pdfjadetex)
-AC_SUBST(PDFJADETEX)
+AC_PATH_PROG(XMLLINT, xmllint, xmllint)
+AC_SUBST(XMLLINT)
 
 #
 # Subroutine for searching for an ordinary file (e.g., a stylesheet)
@@ -2018,74 +1925,60 @@ AC_SUBST($1)
 ])
 
 #
-# Look for the SGML catalog.
-# Its location varies, so far we have seen:
+# Look for Docbook-XSL stylesheets.  Location probably varies by
+# system.  Guessing where it might be found, based on where SGML stuff
+# lives on some systems.  FreeBSD is the only one I'm sure of at the
+# moment.
 #
-# 	NetBSD 	/usr/pkg/share/sgml/docbook/catalog
-# 	FreeBSD	/usr/local/share/sgml/docbook/catalog
-#	Linux	/usr/local/share/dsssl/docbook/catalog
-#		/usr/share/sgml/docbook/dsssl-stylesheets/catalog
-#
-catalogpath=""
-for d in $sgmltrees 
-do
-	catalogpath="$catalogpath $d"
-	for s in docbook/dsssl-stylesheets
-	do
-		catalogpath="$catalogpath $d/$s"
-	done
-done
-NOM_PATH_FILE(SGMLCATALOG, catalog, $catalogpath)
+
+docbook_xsl_trees="/usr/pkg/share/xsl /usr/local/share/xsl /usr/share/xsl"
 
 #
-# Look for the HTML stylesheet html/docbook.dsl, used for
-# formatting man pages in HTML.  Its location varies,
-# so far we have seen:
+# Look for stylesheets we need.
 #
-# 	NetBSD 	/usr/pkg/share/sgml/docbook/dsssl/modular/
-# 	FreeBSD	/usr/local/share/sgml/docbook/dsssl/modular/
-#	Linux	/usr/local/share/dsssl/docbook/
-#		/usr/share/sgml/docbook/dsssl-stylesheets/
+
+NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_HTML, docbook/html/docbook.xsl, $docbook_xsl_trees)
+NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_XHTML, docbook/xhtml/docbook.xsl, $docbook_xsl_trees)
+NOM_PATH_FILE(XSLT_DOCBOOK_STYLE_MAN, docbook/manpages/docbook.xsl, $docbook_xsl_trees)
+NOM_PATH_FILE(XSLT_DOCBOOK_CHUNK_HTML, docbook/html/chunk.xsl, $docbook_xsl_trees)
+NOM_PATH_FILE(XSLT_DOCBOOK_CHUNK_XHTML, docbook/xhtml/chunk.xsl, $docbook_xsl_trees)
+
+#
+# Same dance for db2latex
 #
-# Ditto for the print stylesheet print/docbook.dsl.
+# No idea where this lives except on FreeBSD.
 #
 
-stylepath=""
-for d in $sgmltrees 
-do
-	for s in docbook/dsssl/modular dsssl/docbook docbook/dsssl-stylesheets
-	do
-		stylepath="$stylepath $d/$s"
-	done
-done
-NOM_PATH_FILE(HTMLSTYLE, html/docbook.dsl, $stylepath)
-NOM_PATH_FILE(PRINTSTYLE, print/docbook.dsl, $stylepath)
+db2latex_xsl_trees="/usr/local/share"
 
 #
-# Look for XML declarations.
-# Its location varies, so far we have seen:
-#
-# 	NetBSD 	/usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/
-# 	FreeBSD	/usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/
-#	Linux	/usr/local/share/dsssl/docbook/dtds/decls/
-#		/usr/share/sgml/docbook/dsssl-stylesheets/dtds/decls/
+# Look for stylesheets we need.
 #
 
-xmlpath=""
-for d in $sgmltrees 
-do
-	for s in docbook/dsssl/modular dsssl/docbook docbook/dsssl-stylesheets
-	do
-		xmlpath="$xmlpath $d/$s"
-	done
-done
-NOM_PATH_FILE(XMLDCL, dtds/decls/xml.dcl, $xmlpath)
+NOM_PATH_FILE(XSLT_DB2LATEX_STYLE, db2latex/xsl/docbook.xsl, $db2latex_xsl_trees)
 
 #
-# Look for docbook2man-spec.pl
+# Look for "admonition" image directory.  Can't use NOM_PATH_FILE()
+# because it's a directory, so just do the same things, inline.
 #
 
-NOM_PATH_FILE(DOCBOOK2MANSPEC, docbook2X/docbook2man-spec.pl, $sgmltrees)
+AC_MSG_CHECKING(for db2latex/xsl/figures)
+for d in $db2latex_xsl_trees
+do
+	dd=$d/db2latex/xsl/figures
+	if test -d $dd
+	then
+		XSLT_DB2LATEX_ADMONITIONS=$dd
+		AC_MSG_RESULT($dd)
+		break
+	fi
+done
+if test "X$XSLT_DB2LATEX_ADMONITIONS" = "X"
+then
+	AC_MSG_RESULT(not found)
+	XSLT_DB2LATEX_ADMONITIONS=db2latex/xsl/figures
+fi
+AC_SUBST(XSLT_DB2LATEX_ADMONITIONS)
 
 #
 # Substitutions
@@ -2213,12 +2106,13 @@ AC_OUTPUT(
 	bin/dnssec/Makefile
 	doc/Makefile
 	doc/arm/Makefile
-	doc/arm/nominum-docbook-html.dsl
-	doc/arm/nominum-docbook-print.dsl
-	doc/arm/validate.sh
 	doc/misc/Makefile
-	docutil/docbook2man-wrapper.sh
+	doc/xsl/Makefile
 	isc-config.sh
+	doc/xsl/isc-docbook-chunk.xsl
+	doc/xsl/isc-docbook-html.xsl
+	doc/xsl/isc-docbook-latex.xsl
+	doc/xsl/isc-manpage.xsl
 )
 chmod a+x isc-config.sh
 
diff --git a/contrib/bind9/doc/Makefile.in b/contrib/bind9/doc/Makefile.in
index e7dd9ca35ef3..1e69dabdbabb 100644
--- a/contrib/bind9/doc/Makefile.in
+++ b/contrib/bind9/doc/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.4.206.1 2004/03/06 13:16:14 marka Exp $
+# $Id: Makefile.in,v 1.4.206.3 2005/09/13 00:34:54 marka Exp $
 
 # This Makefile is a placeholder.  It exists merely to make
 # sure that its directory gets created in the object directory
@@ -23,7 +23,7 @@ srcdir =	@srcdir@
 VPATH =		@srcdir@
 top_srcdir =	@top_srcdir@
 
-SUBDIRS = arm misc
+SUBDIRS = arm misc xsl
 TARGETS =
 
 @BIND9_MAKE_RULES@
diff --git a/contrib/bind9/doc/arm/Bv9ARM-book.xml b/contrib/bind9/doc/arm/Bv9ARM-book.xml
index 01cab15ce172..28ccb360afe0 100644
--- a/contrib/bind9/doc/arm/Bv9ARM-book.xml
+++ b/contrib/bind9/doc/arm/Bv9ARM-book.xml
@@ -1,24 +1,44 @@
-
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
-               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd">
-
-<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.52 2005/02/09 03:48:57 marka Exp $ -->
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
+<!--
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003  Internet Software Consortium.
+ -
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ -
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+
+<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.59 2005/10/10 00:22:24 marka Exp $ -->
 
 <book>
 <title>BIND 9 Administrator Reference Manual</title>
 
-<bookinfo>
-<copyright>
-<year>2004</year>
-<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
-</copyright>
-<copyright>
-<year>2000-2003</year>
-<holder>Internet Software Consortium</holder>
-</copyright>
-</bookinfo>
-
-  <chapter id="ch01">
+  <bookinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2002</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </bookinfo>
+
+  <chapter id="Bv9ARM.ch01">
   <title>Introduction </title>
   <para>The Internet Domain Name System (<acronym>DNS</acronym>) consists of the syntax
   to specify the names of entities in the Internet in a hierarchical
@@ -368,7 +388,7 @@ be placed inside a firewall.</para>
 
 </chapter>
 
-<chapter id="ch02"><title><acronym>BIND</acronym> Resource Requirements</title>
+<chapter id="Bv9ARM.ch02"><title><acronym>BIND</acronym> Resource Requirements</title>
 
 <sect1>
 <title>Hardware requirements</title>
@@ -419,7 +439,7 @@ of the BIND 9 source distribution.</para>
 </sect1>
 </chapter>
 
-<chapter id="ch03">
+<chapter id="Bv9ARM.ch03">
 <title>Name Server Configuration</title>
 <para>In this section we provide some suggested configurations along
 with guidelines for their use. We also address the topic of reasonable
@@ -667,6 +687,7 @@ of a server.</para>
               checks the syntax of a <filename>named.conf</filename> file.</para>
               <cmdsynopsis label="Usage">
                 <command>named-checkconf</command>
+		<arg>-jvz</arg>
                 <arg>-t <replaceable>directory</replaceable></arg>
                 <arg><replaceable>filename</replaceable></arg>
               </cmdsynopsis>
@@ -734,25 +755,32 @@ of a server.</para>
    <listitem><para>Retransfer the given zone from the master.</para></listitem>
    </varlistentry>
 
-   <varlistentry><term><userinput>freeze <replaceable>zone</replaceable>
+   <varlistentry> <term><userinput>freeze <optional><replaceable>zone</replaceable>
        <optional><replaceable>class</replaceable>
-           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
-   <listitem><para>Suspend updates to a dynamic zone.  This allows manual
+           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
+   <listitem><para>Suspend updates to a dynamic zone.  If no zone is specified
+	then all zones are suspended.  This allows manual
     edits to be made to a zone normally updated by dynamic update.  It
     also causes changes in the journal file to be synced into the master
     and the journal file to be removed.  All dynamic update attempts will
     be refused while the zone is frozen.</para></listitem>
    </varlistentry>
 
-   <varlistentry><term><userinput>unfreeze <replaceable>zone</replaceable>
+   <varlistentry><term><userinput>thaw <optional><replaceable>zone</replaceable>
        <optional><replaceable>class</replaceable>
-           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
-   <listitem><para>Enable updates to a frozen dynamic zone.  This causes
+           <optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>
+   <listitem><para>Enable updates to a frozen dynamic zone.  If no zone is
+    specified then all frozen zones are enabled.  This causes
     the server to reload the zone from disk, and re-enables dynamic updates
-    after the load has completed.  After a zone is unfrozen, dynamic updates
+    after the load has completed.  After a zone is thawed, dynamic updates
     will no longer be refused.</para></listitem>
    </varlistentry>
 
+   <varlistentry><term><userinput>notify <replaceable>zone</replaceable>
+       <optional><replaceable>class</replaceable>
+           <optional><replaceable>view</replaceable></optional></optional></userinput></term>
+   <listitem><para>Resend NOTIFY messages for the zone</para></listitem></varlistentry>
+
    <varlistentry><term><userinput>reconfig</userinput></term>
    <listitem><para>Reload the configuration file and load new zones,
    but do not reload existing zone files even if they have changed.
@@ -773,20 +801,21 @@ of a server.</para>
    <command>logging</command> section of
    <filename>named.conf</filename>.</para></listitem></varlistentry>
 
-   <varlistentry><term><userinput>dumpdb</userinput></term>
-   <listitem><para>Dump the server's caches to the dump file. </para></listitem></varlistentry>
+   <varlistentry><term><userinput>dumpdb <optional>-all|-cache|-zone</optional> <optional><replaceable>view ...</replaceable></optional></userinput></term>
+   <listitem><para>Dump the server's caches (default) and / or zones to the
+	 dump file for the specified views.  If no view is specified all
+	 views are dumped.</para></listitem></varlistentry>
 
-   <varlistentry><term><userinput>stop</userinput></term>
-   <listitem><para>Stop the server,
-   making sure any recent changes
+   <varlistentry><term><userinput>stop <optional>-p</optional></userinput></term>
+   <listitem><para>Stop the server, making sure any recent changes
    made through dynamic update or IXFR are first saved to the master files
-   of the updated zones.</para></listitem></varlistentry>
+   of the updated zones.  If -p is specified named's process id is returned.</para></listitem></varlistentry>
 
-   <varlistentry><term><userinput>halt</userinput></term>
+   <varlistentry><term><userinput>halt <optional>-p</optional></userinput></term>
    <listitem><para>Stop the server immediately.  Recent changes
    made through dynamic update or IXFR are not saved to the master files,
    but will be rolled forward from the journal files when the server
-   is restarted.</para></listitem></varlistentry>
+   is restarted.  If -p is specified named's process id is returned.</para></listitem></varlistentry>
 
    <varlistentry><term><userinput>trace</userinput></term>
    <listitem><para>Increment the servers debugging level by one. </para></listitem></varlistentry>
@@ -801,12 +830,20 @@ of a server.</para>
    <varlistentry><term><userinput>flush</userinput></term>
    <listitem><para>Flushes the server's cache.</para></listitem></varlistentry>
 
+   <varlistentry><term><userinput>flushname</userinput> <replaceable>name</replaceable></term>
+   <listitem><para>Flushes the given name from the server's cache.</para></listitem></varlistentry>
+
    <varlistentry><term><userinput>status</userinput></term>
    <listitem><para>Display status of the server.
 Note the number of zones includes the internal <command>bind/CH</command> zone
 and the default <command>./IN</command> hint zone if there is not a
 explicit root zone configured.</para></listitem></varlistentry>
 
+   <varlistentry><term><userinput>recursing</userinput></term>
+   <listitem><para>Dump the list of queries named is currently recursing
+   on.
+   </para></listitem></varlistentry>
+
 </variablelist>
 
 <para>In <acronym>BIND</acronym> 9.2, <command>rndc</command>
@@ -957,7 +994,7 @@ reload the database. </para></entry>
   </sect1>
   </chapter>
 
-<chapter id="ch04">
+<chapter id="Bv9ARM.ch04">
 <title>Advanced DNS Features</title>
 
 <sect1 id="notify">
@@ -1004,7 +1041,7 @@ protocol is specified in RFC 1996.
 
     <para>All changes made to a zone using dynamic update are stored in the
     zone's journal file.  This file is automatically created by the
-    server when when the first dynamic update takes place.  The name of
+    server when the first dynamic update takes place.  The name of
     the journal file is formed by appending the
     extension <filename>.jnl</filename> to the
     name of the corresponding zone file.  The journal file is in a
@@ -1123,7 +1160,7 @@ to those internal hosts. With the wildcard records, the mail will
 be delivered to the bastion host, which can then forward it on to
 internal hosts.</para>
 <para>Here's an example of a wildcard MX record:</para>
-<programlisting><literal>*   IN MX 10 external1.example.com.</literal></programlisting>
+<programlisting>*   IN MX 10 external1.example.com.</programlisting>
 <para>Now that they accept mail on behalf of anything in the internal
 network, the bastion hosts will need to know how to deliver mail
 to internal hosts. In order for this to work properly, the resolvers on
@@ -1620,7 +1657,7 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
   </sect1>
   </chapter>
 
-  <chapter id="ch05"><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title>
+  <chapter id="Bv9ARM.ch05"><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title>
 <sect1><title>The Lightweight Resolver Library</title>
 <para>Traditionally applications have been linked with a stub resolver
 library that sends recursive DNS queries to a local caching name
@@ -1666,7 +1703,7 @@ be configured to act as a lightweight resolver daemon using the
 
 </sect1></chapter>
 
-<chapter id="ch06"><title><acronym>BIND</acronym> 9 Configuration Reference</title>
+<chapter id="Bv9ARM.ch06"><title><acronym>BIND</acronym> 9 Configuration Reference</title>
 
 <para><acronym>BIND</acronym> 9 configuration is broadly similar
 to <acronym>BIND</acronym> 8; however, there are a few new areas
@@ -1831,7 +1868,7 @@ which constitute an address match list can be any of the following:</para>
 <listitem>
             <simpara>a key ID, as defined by the <command>key</command> statement</simpara></listitem>
 <listitem>
-            <simpara>the name of an address match list previously defined with
+            <simpara>the name of an address match list defined with
 the <command>acl</command> statement</simpara></listitem>
 <listitem>
             <simpara>a nested address match list enclosed in braces</simpara></listitem></itemizedlist>
@@ -2181,7 +2218,7 @@ installed.
 
 <para>
 To disable the command channel, use an empty <command>controls</command>
-statement: <command>controls { };</command>.
+statement: <command>controls { };</command>.
 </para>
 
     </sect2>
@@ -2591,9 +2628,10 @@ The query log entry reports the client's IP address and port number.  The
 query name, class and type.  It also reports whether the Recursion Desired
 flag was set (+ if set, - if not set), EDNS was in use (E) or if the
 query was signed (S).</para>
-<programlisting><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
-<computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
-</programlisting>
+<para><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
+</para>
+<para><computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
+</para>
 </entry>
 </row>
 <row rowsep = "0">
@@ -2724,7 +2762,7 @@ statement in the <filename>named.conf</filename> file:</para>
     <optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional>
     <optional> dnssec-must-be-secure <replaceable>domain yes_or_no</replaceable>; </optional>
     <optional> forward ( <replaceable>only</replaceable> | <replaceable>first</replaceable> ); </optional>
-    <optional> forwarders { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
     <optional> dual-stack-servers <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>domain_name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ) ; ... }; </optional>
     <optional> check-names ( <replaceable>master</replaceable> | <replaceable>slave</replaceable> | <replaceable>response</replaceable> )( <replaceable>warn</replaceable> | <replaceable>fail</replaceable> | <replaceable>ignore</replaceable> ); </optional>
     <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
@@ -2958,7 +2996,7 @@ record does) the DNSKEY RRset is deemed to be trusted.
 
 <varlistentry><term><command>dnssec-must-be-secure</command></term>
 <listitem><para>
-Specify heirachies which must / may not be secure (signed and validated).
+Specify heirarchies which must / may not be secure (signed and validated).
 If <userinput>yes</userinput> then named will only accept answers if they
 are secure.
 If <userinput>no</userinput> then normal dnssec validation applies
@@ -3714,11 +3752,25 @@ in the configuration file.</para>
 except zone transfers are performed using IPv6.</para>
               </listitem></varlistentry>
 
-<varlistentry><term><command>alt-transfer-source</command></term>
-<listitem><para>An alternate transfer source if the one listed in
-<command>transfer-source</command> fails and
-<command>use-alt-transfer-source</command> is set.</para>
-              </listitem></varlistentry>
+	    <varlistentry>
+	      <term><command>alt-transfer-source</command></term>
+	      <listitem>
+		<para>
+		  An alternate transfer source if the one listed in
+		  <command>transfer-source</command> fails and
+		  <command>use-alt-transfer-source</command> is
+		  set.
+		</para>
+		<note>
+		  If you do not wish the alternate transfer source
+		  to be used you should set
+		  <command>use-alt-transfer-source</command>
+		  appropriately and you should not depend upon
+		  getting a answer back to the first refresh
+		  query.
+		</note>
+              </listitem>
+	    </varlistentry>
 
 <varlistentry><term><command>alt-transfer-source-v6</command></term>
 <listitem><para>An alternate transfer source if the one listed in
@@ -4553,7 +4605,7 @@ Statement Grammar</title>
     <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
     <optional> file <replaceable>string</replaceable> ; </optional>
     <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </optional>
-    <optional> forwarders { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
+    <optional> forwarders { <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional>
     <optional> ixfr-base <replaceable>string</replaceable> ; </optional>
     <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
     <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
@@ -5539,10 +5591,10 @@ be appended to any unqualified records. When a zone is first read
 in there is an implicit <command>$ORIGIN</command> &#60;<varname>zone-name</varname>><command>.</command> The
 current <command>$ORIGIN</command> is appended to the domain specified
 in the <command>$ORIGIN</command> argument if it is not absolute.</para>
-<programlisting><literal>$ORIGIN example.com.
-WWW     CNAME   MAIN-SERVER</literal></programlisting>
+<programlisting>$ORIGIN example.com.
+WWW     CNAME   MAIN-SERVER</programlisting>
 <para>is equivalent to</para>
-<programlisting><literal>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</literal></programlisting></sect3>
+<programlisting>WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</programlisting></sect3>
 <sect3><title>The <command>$INCLUDE</command> Directive</title>
 <para>Syntax: <command>$INCLUDE</command>
 <replaceable>filename</replaceable> <optional>
@@ -5576,17 +5628,17 @@ resource records that only differ from each other by an iterator. <command>$GENE
 be used to easily generate the sets of records required to support
 sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA
 delegation.</para>
-<programlisting><literal>$ORIGIN 0.0.192.IN-ADDR.ARPA.
+<programlisting>$ORIGIN 0.0.192.IN-ADDR.ARPA.
 $GENERATE 1-2 0 NS SERVER$.EXAMPLE.
-$GENERATE 1-127 $ CNAME $.0</literal></programlisting>
+$GENERATE 1-127 $ CNAME $.0</programlisting>
 <para>is equivalent to</para>
-<programlisting><literal>0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
+<programlisting>0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
 0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
 1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
 2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
 ...
 127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
-</literal></programlisting>
+</programlisting>
       <informaltable colsep = "0" rowsep = "0">
         <tgroup cols = "2" colsep = "0" rowsep = "0" tgroupstyle = "3Level-table">
           <colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/>
@@ -5655,7 +5707,7 @@ and not part of the standard zone file format.</para>
     </sect2>
   </sect1>
 </chapter>
-<chapter id="ch07"><title><acronym>BIND</acronym> 9 Security Considerations</title>
+<chapter id="Bv9ARM.ch07"><title><acronym>BIND</acronym> 9 Security Considerations</title>
 <sect1 id="Access_Control_Lists"><title>Access Control Lists</title>
 <para>Access Control Lists (ACLs), are address match lists that
 you can set up and nickname for future use in <command>allow-notify</command>,
@@ -5778,7 +5830,7 @@ all.</para>
 
 </sect1></chapter>
 
-<chapter id="ch08">
+<chapter id="Bv9ARM.ch08">
   <title>Troubleshooting</title>
   <sect1>
     <title>Common Problems</title>
@@ -5837,7 +5889,7 @@ all.</para>
     to read more.</para>
   </sect1>
 </chapter>
-<appendix id="ch09">
+<appendix id="Bv9ARM.ch09">
   <title>Appendices</title>
   <sect1>
     <title>Acknowledgments</title>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch01.html b/contrib/bind9/doc/arm/Bv9ARM.ch01.html
index 5b3659e61010..37f1eec39ab7 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch01.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch01.html
@@ -1,1131 +1,412 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Introduction </TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="NEXT"
-TITLE="BIND Resource Requirements"
-HREF="Bv9ARM.ch02.html"></HEAD
-><BODY
-CLASS="chapter"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch02.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="chapter"
-><H1
-><A
-NAME="ch01"
-></A
->Chapter 1. Introduction </H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->1.1. <A
-HREF="Bv9ARM.ch01.html#AEN15"
->Scope of Document</A
-></DT
-><DT
->1.2. <A
-HREF="Bv9ARM.ch01.html#AEN22"
->Organization of This Document</A
-></DT
-><DT
->1.3. <A
-HREF="Bv9ARM.ch01.html#AEN42"
->Conventions Used in This Document</A
-></DT
-><DT
->1.4. <A
-HREF="Bv9ARM.ch01.html#AEN107"
->The Domain Name System (<ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->)</A
-></DT
-></DL
-></DIV
-><P
->The Internet Domain Name System (<ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->) consists of the syntax
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch01.html,v 1.12.2.2.8.9 2005/10/13 02:33:58 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 1. Introduction </title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="next" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 1. Introduction </th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch01"></a>Chapter 1. Introduction </h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545879">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545905">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545976">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2546234">The Domain Name System (<span class="acronym">DNS</span>)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546254">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2544105">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546579">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546653">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546950">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2547076">Name Servers in Multiple Roles</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<p>The Internet Domain Name System (<span class="acronym">DNS</span>) consists of the syntax
   to specify the names of entities in the Internet in a hierarchical
   manner, the rules used for delegating authority over names, and the
   system implementation that actually maps names to Internet
-  addresses.  <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> data is maintained in a group of distributed
-  hierarchical databases.</P
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN15"
->1.1. Scope of Document</A
-></H1
-><P
->The Berkeley Internet Name Domain (<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->) implements an
+  addresses.  <span class="acronym">DNS</span> data is maintained in a group of distributed
+  hierarchical databases.</p>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2545879"></a>Scope of Document</h2></div></div></div>
+<p>The Berkeley Internet Name Domain (<span class="acronym">BIND</span>) implements an
     domain name server for a number of operating systems. This
     document provides basic information about the installation and
-    care of the Internet Software Consortium (<ACRONYM
-CLASS="acronym"
->ISC</ACRONYM
->)
-    <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> version 9 software package for system
-    administrators.</P
-><P
->This version of the manual corresponds to BIND version 9.3.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN22"
->1.2. Organization of This Document</A
-></H1
-><P
->In this document, <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Section 1</I
-></SPAN
-> introduces
-    the basic <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> and <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> concepts. <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Section 2</I
-></SPAN
->
-    describes resource requirements for running <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> in various
-    environments. Information in <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Section 3</I
-></SPAN
-> is
-    <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->task-oriented</I
-></SPAN
-> in its presentation and is
+    care of the Internet Software Consortium (<span class="acronym">ISC</span>)
+    <span class="acronym">BIND</span> version 9 software package for system
+    administrators.</p>
+<p>This version of the manual corresponds to BIND version 9.3.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2545905"></a>Organization of This Document</h2></div></div></div>
+<p>In this document, <span class="emphasis"><em>Section 1</em></span> introduces
+    the basic <span class="acronym">DNS</span> and <span class="acronym">BIND</span> concepts. <span class="emphasis"><em>Section 2</em></span>
+    describes resource requirements for running <span class="acronym">BIND</span> in various
+    environments. Information in <span class="emphasis"><em>Section 3</em></span> is
+    <span class="emphasis"><em>task-oriented</em></span> in its presentation and is
     organized functionally, to aid in the process of installing the
-    <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 software. The task-oriented section is followed by
-    <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Section 4</I
-></SPAN
->, which contains more advanced
+    <span class="acronym">BIND</span> 9 software. The task-oriented section is followed by
+    <span class="emphasis"><em>Section 4</em></span>, which contains more advanced
     concepts that the system administrator may need for implementing
-    certain options. <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Section 5</I
-></SPAN
->
-    describes the <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 lightweight
-    resolver.  The contents of <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Section 6</I
-></SPAN
-> are
+    certain options. <span class="emphasis"><em>Section 5</em></span>
+    describes the <span class="acronym">BIND</span> 9 lightweight
+    resolver.  The contents of <span class="emphasis"><em>Section 6</em></span> are
     organized as in a reference manual to aid in the ongoing
-    maintenance of the software. <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Section 7
-    </I
-></SPAN
->addresses security considerations, and
-    <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Section 8</I
-></SPAN
-> contains troubleshooting help. The
+    maintenance of the software. <span class="emphasis"><em>Section 7
+    </em></span>addresses security considerations, and
+    <span class="emphasis"><em>Section 8</em></span> contains troubleshooting help. The
     main body of the document is followed by several
-    <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Appendices</I
-></SPAN
-> which contain useful reference
-    information, such as a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Bibliography</I
-></SPAN
-> and
-    historic information related to <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> and the Domain Name
-    System.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN42"
->1.3. Conventions Used in This Document</A
-></H1
-><P
->In this document, we use the following general typographic
-    conventions:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN45"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
->&#13;<P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->To
-describe:</I
-></SPAN
-></P
-></TD
-><TD
->&#13;<P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->We use the style:</I
-></SPAN
-></P
-></TD
-></TR
-><TR
-><TD
->&#13;<P
->a pathname, filename, URL, hostname,
-mailing list name, or new term or concept</P
-></TD
-><TD
-><P
-><TT
-CLASS="filename"
->Fixed width</TT
-></P
-></TD
-></TR
-><TR
-><TD
-><P
->literal user
-input</P
-></TD
-><TD
-><P
-><KBD
-CLASS="userinput"
->Fixed Width Bold</KBD
-></P
-></TD
-></TR
-><TR
-><TD
-><P
->program output</P
-></TD
-><TD
-><P
-><SAMP
-CLASS="computeroutput"
->Fixed Width</SAMP
-></P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->The following conventions are used in descriptions of the
-<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> configuration file:<DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN77"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->To
-describe:</I
-></SPAN
-></P
-></TD
-><TD
-><P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->We use the style:</I
-></SPAN
-></P
-></TD
-></TR
-><TR
-><TD
-><P
->keywords</P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->Fixed Width</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
->variables</P
-></TD
-><TD
-><P
-><VAR
-CLASS="varname"
->Fixed Width</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
->Optional input</P
-></TD
-><TD
-><P
->[<SPAN
-CLASS="optional"
->Text is enclosed in square brackets</SPAN
->]</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-></P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN107"
->1.4. The Domain Name System (<ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->)</A
-></H1
-><P
->The purpose of this document is to explain the installation
-and upkeep of the <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> software package, and we
+    <span class="emphasis"><em>Appendices</em></span> which contain useful reference
+    information, such as a <span class="emphasis"><em>Bibliography</em></span> and
+    historic information related to <span class="acronym">BIND</span> and the Domain Name
+    System.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2545976"></a>Conventions Used in This Document</h2></div></div></div>
+<p>In this document, we use the following general typographic
+    conventions:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+<p><span class="emphasis"><em>To
+describe:</em></span></p>
+</td>
+<td>
+<p><span class="emphasis"><em>We use the style:</em></span></p>
+</td>
+</tr>
+<tr>
+<td>
+<p>a pathname, filename, URL, hostname,
+mailing list name, or new term or concept</p>
+</td>
+<td><p><code class="filename">Fixed width</code></p></td>
+</tr>
+<tr>
+<td><p>literal user
+input</p></td>
+<td><p><strong class="userinput"><code>Fixed Width Bold</code></strong></p></td>
+</tr>
+<tr>
+<td><p>program output</p></td>
+<td><p><code class="computeroutput">Fixed Width</code></p></td>
+</tr>
+</tbody>
+</table></div>
+<p>The following conventions are used in descriptions of the
+<span class="acronym">BIND</span> configuration file:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span class="emphasis"><em>To
+describe:</em></span></p></td>
+<td><p><span class="emphasis"><em>We use the style:</em></span></p></td>
+</tr>
+<tr>
+<td><p>keywords</p></td>
+<td><p><code class="literal">Fixed Width</code></p></td>
+</tr>
+<tr>
+<td><p>variables</p></td>
+<td><p><code class="varname">Fixed Width</code></p></td>
+</tr>
+<tr>
+<td><p>Optional input</p></td>
+<td><p>[<span class="optional">Text is enclosed in square brackets</span>]</p></td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2546234"></a>The Domain Name System (<span class="acronym">DNS</span>)</h2></div></div></div>
+<p>The purpose of this document is to explain the installation
+and upkeep of the <span class="acronym">BIND</span> software package, and we
 begin by reviewing the fundamentals of the Domain Name System
-(<ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->) as they relate to <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->.
-</P
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN114"
->1.4.1. DNS Fundamentals</A
-></H2
-><P
->The Domain Name System (DNS) is the hierarchical, distributed
+(<span class="acronym">DNS</span>) as they relate to <span class="acronym">BIND</span>.
+</p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2546254"></a>DNS Fundamentals</h3></div></div></div>
+<p>The Domain Name System (DNS) is the hierarchical, distributed
 database.  It stores information for mapping Internet host names to IP
 addresses and vice versa, mail routing information, and other data
-used by Internet applications.</P
-><P
->Clients look up information in the DNS by calling a
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->resolver</I
-></SPAN
-> library, which sends queries to one or
-more <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->name servers</I
-></SPAN
-> and interprets the responses.
-The <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 software distribution contains a
-name server, <B
-CLASS="command"
->named</B
->, and two resolver
-libraries, <B
-CLASS="command"
->liblwres</B
-> and <B
-CLASS="command"
->libbind</B
->.
-</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN124"
->1.4.2. Domains and Domain Names</A
-></H2
-><P
->The data stored in the DNS is identified by <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->domain
-names</I
-></SPAN
-> that are organized as a tree according to
+used by Internet applications.</p>
+<p>Clients look up information in the DNS by calling a
+<span class="emphasis"><em>resolver</em></span> library, which sends queries to one or
+more <span class="emphasis"><em>name servers</em></span> and interprets the responses.
+The <span class="acronym">BIND</span> 9 software distribution contains a
+name server, <span><strong class="command">named</strong></span>, and two resolver
+libraries, <span><strong class="command">liblwres</strong></span> and <span><strong class="command">libbind</strong></span>.
+</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2544105"></a>Domains and Domain Names</h3></div></div></div>
+<p>The data stored in the DNS is identified by <span class="emphasis"><em>domain
+names</em></span> that are organized as a tree according to
 organizational or administrative boundaries. Each node of the tree,
-called a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->domain</I
-></SPAN
->, is given a label. The domain name of the
+called a <span class="emphasis"><em>domain</em></span>, is given a label. The domain name of the
 node is the concatenation of all the labels on the path from the
-node to the <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->root</I
-></SPAN
-> node.  This is represented
+node to the <span class="emphasis"><em>root</em></span> node.  This is represented
 in written form as a string of labels listed from right to left and
 separated by dots. A label need only be unique within its parent
-domain.</P
-><P
->For example, a domain name for a host at the
-company <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Example, Inc.</I
-></SPAN
-> could be
-<VAR
-CLASS="literal"
->mail.example.com</VAR
->,
-where <VAR
-CLASS="literal"
->com</VAR
-> is the
+domain.</p>
+<p>For example, a domain name for a host at the
+company <span class="emphasis"><em>Example, Inc.</em></span> could be
+<code class="literal">mail.example.com</code>,
+where <code class="literal">com</code> is the
 top level domain to which
-<VAR
-CLASS="literal"
->ourhost.example.com</VAR
-> belongs,
-<VAR
-CLASS="literal"
->example</VAR
-> is
-a subdomain of <VAR
-CLASS="literal"
->com</VAR
->, and
-<VAR
-CLASS="literal"
->ourhost</VAR
-> is the
-name of the host.</P
-><P
->For administrative purposes, the name space is partitioned into
-areas called <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->zones</I
-></SPAN
->, each starting at a node and
+<code class="literal">ourhost.example.com</code> belongs,
+<code class="literal">example</code> is
+a subdomain of <code class="literal">com</code>, and
+<code class="literal">ourhost</code> is the
+name of the host.</p>
+<p>For administrative purposes, the name space is partitioned into
+areas called <span class="emphasis"><em>zones</em></span>, each starting at a node and
 extending down to the leaf nodes or to nodes where other zones start.
-The data for each zone is stored in a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->name
-server</I
-></SPAN
->, which answers queries about the zone using the
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->DNS protocol</I
-></SPAN
->.
-</P
-><P
->The data associated with each domain name is stored in the
-form of <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->resource records</I
-></SPAN
-> (<ACRONYM
-CLASS="acronym"
->RR</ACRONYM
->s).
+The data for each zone is stored in a <span class="emphasis"><em>name
+server</em></span>, which answers queries about the zone using the
+<span class="emphasis"><em>DNS protocol</em></span>.
+</p>
+<p>The data associated with each domain name is stored in the
+form of <span class="emphasis"><em>resource records</em></span> (<span class="acronym">RR</span>s).
 Some of the supported resource record types are described in
-<A
-HREF="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them"
->Section 6.3.1</A
->.</P
-><P
->For more detailed information about the design of the DNS and
+<a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them" title="Types of Resource Records and When to Use Them">the section called &#8220;Types of Resource Records and When to Use Them&#8221;</a>.</p>
+<p>For more detailed information about the design of the DNS and
 the DNS protocol, please refer to the standards documents listed in
-<A
-HREF="Bv9ARM.ch09.html#rfcs"
->Section A.3.1</A
->.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN148"
->1.4.3. Zones</A
-></H2
-><P
->To properly operate a name server, it is important to understand
-the difference between a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->zone</I
-></SPAN
->
-and a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->domain</I
-></SPAN
->.</P
-><P
->As we stated previously, a zone is a point of delegation in
-the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> tree. A zone consists of
+<a href="Bv9ARM.ch09.html#rfcs" title="Request for Comments (RFCs)">the section called &#8220;Request for Comments (RFCs)&#8221;</a>.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2546579"></a>Zones</h3></div></div></div>
+<p>To properly operate a name server, it is important to understand
+the difference between a <span class="emphasis"><em>zone</em></span>
+and a <span class="emphasis"><em>domain</em></span>.</p>
+<p>As we stated previously, a zone is a point of delegation in
+the <span class="acronym">DNS</span> tree. A zone consists of
 those contiguous parts of the domain
 tree for which a name server has complete information and over which
 it has authority. It contains all domain names from a certain point
 downward in the domain tree except those which are delegated to
 other zones. A delegation point is marked by one or more
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->NS records</I
-></SPAN
-> in the
+<span class="emphasis"><em>NS records</em></span> in the
 parent zone, which should be matched by equivalent NS records at
-the root of the delegated zone.</P
-><P
->For instance, consider the <VAR
-CLASS="literal"
->example.com</VAR
->
+the root of the delegated zone.</p>
+<p>For instance, consider the <code class="literal">example.com</code>
 domain which includes names
-such as <VAR
-CLASS="literal"
->host.aaa.example.com</VAR
-> and
-<VAR
-CLASS="literal"
->host.bbb.example.com</VAR
-> even though
-the <VAR
-CLASS="literal"
->example.com</VAR
-> zone includes
-only delegations for the <VAR
-CLASS="literal"
->aaa.example.com</VAR
-> and
-<VAR
-CLASS="literal"
->bbb.example.com</VAR
-> zones.  A zone can map
+such as <code class="literal">host.aaa.example.com</code> and
+<code class="literal">host.bbb.example.com</code> even though
+the <code class="literal">example.com</code> zone includes
+only delegations for the <code class="literal">aaa.example.com</code> and
+<code class="literal">bbb.example.com</code> zones.  A zone can map
 exactly to a single domain, but could also include only part of a
 domain, the rest of which could be delegated to other
-name servers. Every name in the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> tree is a
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->domain</I
-></SPAN
->, even if it is
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->terminal</I
-></SPAN
->, that is, has no
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->subdomains</I
-></SPAN
->.  Every subdomain is a domain and
+name servers. Every name in the <span class="acronym">DNS</span> tree is a
+<span class="emphasis"><em>domain</em></span>, even if it is
+<span class="emphasis"><em>terminal</em></span>, that is, has no
+<span class="emphasis"><em>subdomains</em></span>.  Every subdomain is a domain and
 every domain except the root is also a subdomain. The terminology is
 not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to
 gain a complete understanding of this difficult and subtle
-topic.</P
-><P
->Though <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> is called a "domain name server",
+topic.</p>
+<p>Though <span class="acronym">BIND</span> is called a "domain name server",
 it deals primarily in terms of zones. The master and slave
-declarations in the <TT
-CLASS="filename"
->named.conf</TT
-> file specify
+declarations in the <code class="filename">named.conf</code> file specify
 zones, not domains. When you ask some other site if it is willing to
-be a slave server for your <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->domain</I
-></SPAN
->, you are
-actually asking for slave service for some collection of zones.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN171"
->1.4.4. Authoritative Name Servers</A
-></H2
-><P
->Each zone is served by at least
-one <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->authoritative name server</I
-></SPAN
->,
+be a slave server for your <span class="emphasis"><em>domain</em></span>, you are
+actually asking for slave service for some collection of zones.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2546653"></a>Authoritative Name Servers</h3></div></div></div>
+<p>Each zone is served by at least
+one <span class="emphasis"><em>authoritative name server</em></span>,
 which contains the complete data for the zone.
 To make the DNS tolerant of server and network failures,
 most zones have two or more authoritative servers.
-</P
-><P
->Responses from authoritative servers have the "authoritative
+</p>
+<p>Responses from authoritative servers have the "authoritative
 answer" (AA) bit set in the response packets.  This makes them 
 easy to identify when debugging DNS configurations using tools like
-<B
-CLASS="command"
->dig</B
-> (<A
-HREF="Bv9ARM.ch03.html#diagnostic_tools"
->Section 3.3.1.1</A
->).</P
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN178"
->1.4.4.1. The Primary Master</A
-></H3
-><P
->&#13;The authoritative server where the master copy of the zone data is maintained is
-called the <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->primary master</I
-></SPAN
-> server, or simply the
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->primary</I
-></SPAN
->.  It loads the zone contents from some
+<span><strong class="command">dig</strong></span> (<a href="Bv9ARM.ch03.html#diagnostic_tools" title="Diagnostic Tools">the section called &#8220;Diagnostic Tools&#8221;</a>).</p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2546676"></a>The Primary Master</h4></div></div></div>
+<p>
+The authoritative server where the master copy of the zone data is maintained is
+called the <span class="emphasis"><em>primary master</em></span> server, or simply the
+<span class="emphasis"><em>primary</em></span>.  It loads the zone contents from some
 local file edited by humans or perhaps generated mechanically from
 some other local file which is edited by humans.  This file is called
-the <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->zone file</I
-></SPAN
-> or <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->master file</I
-></SPAN
->.</P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN185"
->1.4.4.2. Slave Servers</A
-></H3
-><P
->The other authoritative servers, the <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->slave</I
-></SPAN
->
-servers (also known as <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->secondary</I
-></SPAN
-> servers) load
+the <span class="emphasis"><em>zone file</em></span> or <span class="emphasis"><em>master file</em></span>.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2546902"></a>Slave Servers</h4></div></div></div>
+<p>The other authoritative servers, the <span class="emphasis"><em>slave</em></span>
+servers (also known as <span class="emphasis"><em>secondary</em></span> servers) load
 the zone contents from another server using a replication process
-known as a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->zone transfer</I
-></SPAN
->.  Typically the data are
+known as a <span class="emphasis"><em>zone transfer</em></span>.  Typically the data are
 transferred directly from the primary master, but it is also possible
 to transfer it from another slave.  In other words, a slave server
-may itself act as a master to a subordinate slave server.</P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN191"
->1.4.4.3. Stealth Servers</A
-></H3
-><P
->Usually all of the zone's authoritative servers are listed in 
+may itself act as a master to a subordinate slave server.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2546921"></a>Stealth Servers</h4></div></div></div>
+<p>Usually all of the zone's authoritative servers are listed in 
 NS records in the parent zone.  These NS records constitute
-a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->delegation</I
-></SPAN
-> of the zone from the parent.
+a <span class="emphasis"><em>delegation</em></span> of the zone from the parent.
 The authoritative servers are also listed in the zone file itself,
-at the <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->top level</I
-></SPAN
-> or <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->apex</I
-></SPAN
->
+at the <span class="emphasis"><em>top level</em></span> or <span class="emphasis"><em>apex</em></span>
 of the zone.  You can list servers in the zone's top-level NS
 records that are not in the parent's NS delegation, but you cannot
 list servers in the parent's delegation that are not present at
-the zone's top level.</P
-><P
->A <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->stealth server</I
-></SPAN
-> is a server that is
+the zone's top level.</p>
+<p>A <span class="emphasis"><em>stealth server</em></span> is a server that is
 authoritative for a zone but is not listed in that zone's NS
 records.  Stealth servers can be used for keeping a local copy of a
 zone to speed up access to the zone's records or to make sure that the
 zone is available even if all the "official" servers for the zone are
-inaccessible.</P
-><P
->A configuration where the primary master server itself is a
+inaccessible.</p>
+<p>A configuration where the primary master server itself is a
 stealth server is often referred to as a "hidden primary"
 configuration.  One use for this configuration is when the primary master
 is behind a firewall and therefore unable to communicate directly
-with the outside world.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN200"
->1.4.5. Caching Name Servers</A
-></H2
-><P
->The resolver libraries provided by most operating systems are 
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->stub resolvers</I
-></SPAN
->, meaning that they are not capable of
+with the outside world.</p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2546950"></a>Caching Name Servers</h3></div></div></div>
+<p>The resolver libraries provided by most operating systems are 
+<span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not capable of
 performing the full DNS resolution process by themselves by talking
 directly to the authoritative servers.  Instead, they rely on a local
 name server to perform the resolution on their behalf.  Such a server
-is called a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->recursive</I
-></SPAN
-> name server; it performs
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->recursive lookups</I
-></SPAN
-> for local clients.</P
-><P
->To improve performance, recursive servers cache the results of
+is called a <span class="emphasis"><em>recursive</em></span> name server; it performs
+<span class="emphasis"><em>recursive lookups</em></span> for local clients.</p>
+<p>To improve performance, recursive servers cache the results of
 the lookups they perform.  Since the processes of recursion and
 caching are intimately connected, the terms
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->recursive server</I
-></SPAN
-> and
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->caching server</I
-></SPAN
-> are often used synonymously.</P
-><P
->The length of time for which a record may be retained in
+<span class="emphasis"><em>recursive server</em></span> and
+<span class="emphasis"><em>caching server</em></span> are often used synonymously.</p>
+<p>The length of time for which a record may be retained in
 in the cache of a caching name server is controlled by the 
 Time To Live (TTL) field associated with each resource record.
-</P
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN210"
->1.4.5.1. Forwarding</A
-></H3
-><P
->Even a caching name server does not necessarily perform
+</p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2547050"></a>Forwarding</h4></div></div></div>
+<p>Even a caching name server does not necessarily perform
 the complete recursive lookup itself.  Instead, it can
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->forward</I
-></SPAN
-> some or all of the queries
+<span class="emphasis"><em>forward</em></span> some or all of the queries
 that it cannot satisfy from its cache to another caching name server,
-commonly referred to as a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->forwarder</I
-></SPAN
->.
-</P
-><P
->There may be one or more forwarders,
+commonly referred to as a <span class="emphasis"><em>forwarder</em></span>.
+</p>
+<p>There may be one or more forwarders,
 and they are queried in turn until the list is exhausted or an answer
 is found. Forwarders are typically used when you do not
 wish all the servers at a given site to interact directly with the rest of
 the Internet servers. A typical scenario would involve a number
-of internal <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> servers and an Internet firewall. Servers unable
+of internal <span class="acronym">DNS</span> servers and an Internet firewall. Servers unable
 to pass packets through the firewall would forward to the server
-that can do it, and that server would query the Internet <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> servers
+that can do it, and that server would query the Internet <span class="acronym">DNS</span> 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 clients can take advantage
-of.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN218"
->1.4.6. Name Servers in Multiple Roles</A
-></H2
-><P
->The <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> name server can simultaneously act as
+of.</p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2547076"></a>Name Servers in Multiple Roles</h3></div></div></div>
+<p>The <span class="acronym">BIND</span> name server can simultaneously act as
 a master for some zones, a slave for other zones, and as a caching
-(recursive) server for a set of local clients.</P
-><P
->However, since the functions of authoritative name service
+(recursive) server for a set of local clients.</p>
+<p>However, since the functions of authoritative name service
 and caching/recursive name service are logically separate, it is
 often advantageous to run them on separate server machines.
 
 A server that only provides authoritative name service
-(an <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->authoritative-only</I
-></SPAN
-> server) can run with
+(an <span class="emphasis"><em>authoritative-only</em></span> server) can run with
 recursion disabled, improving reliability and security.
 
 A server that is not authoritative for any zones and only provides
 recursive service to local
-clients (a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->caching-only</I
-></SPAN
-> server)
+clients (a <span class="emphasis"><em>caching-only</em></span> server)
 does not need to be reachable from the Internet at large and can
-be placed inside a firewall.</P
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch02.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->BIND 9 Administrator Reference Manual</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> Resource Requirements</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+be placed inside a firewall.</p>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">BIND 9 Administrator Reference Manual </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 2. <span class="acronym">BIND</span> Resource Requirements</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch02.html b/contrib/bind9/doc/arm/Bv9ARM.ch02.html
index 0b293c7edfd6..d3e946ad7706 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch02.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch02.html
@@ -1,198 +1,95 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->BIND Resource Requirements</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="Introduction "
-HREF="Bv9ARM.ch01.html"><LINK
-REL="NEXT"
-TITLE="Name Server Configuration"
-HREF="Bv9ARM.ch03.html"></HEAD
-><BODY
-CLASS="chapter"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch01.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch03.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="chapter"
-><H1
-><A
-NAME="ch02"
-></A
->Chapter 2. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> Resource Requirements</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->2.1. <A
-HREF="Bv9ARM.ch02.html#AEN228"
->Hardware requirements</A
-></DT
-><DT
->2.2. <A
-HREF="Bv9ARM.ch02.html#AEN236"
->CPU Requirements</A
-></DT
-><DT
->2.3. <A
-HREF="Bv9ARM.ch02.html#AEN240"
->Memory Requirements</A
-></DT
-><DT
->2.4. <A
-HREF="Bv9ARM.ch02.html#AEN245"
->Name Server Intensive Environment Issues</A
-></DT
-><DT
->2.5. <A
-HREF="Bv9ARM.ch02.html#AEN248"
->Supported Operating Systems</A
-></DT
-></DL
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN228"
->2.1. Hardware requirements</A
-></H1
-><P
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> hardware requirements have traditionally been quite modest.
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch02.html,v 1.10.2.1.8.8 2005/10/13 02:33:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 2. BIND Resource Requirements</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction ">
+<link rel="next" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 2. <span class="acronym">BIND</span> Resource Requirements</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch02"></a>Chapter 2. <span class="acronym">BIND</span> Resource Requirements</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547108">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547132">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547143">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547158">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547303">Supported Operating Systems</a></span></dt>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2547108"></a>Hardware requirements</h2></div></div></div>
+<p><span class="acronym">DNS</span> hardware requirements have traditionally been quite modest.
 For many installations, servers that have been pensioned off from
-active duty have performed admirably as <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> servers.</P
-><P
->The DNSSEC and IPv6 features of <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 may prove to be quite
+active duty have performed admirably as <span class="acronym">DNS</span> servers.</p>
+<p>The DNSSEC and IPv6 features of <span class="acronym">BIND</span> 9 may prove to be quite
 CPU intensive however, so organizations that make heavy use of these
 features may wish to consider larger systems for these applications.
-<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 is fully multithreaded, allowing full utilization of
-multiprocessor systems for installations that need it.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN236"
->2.2. CPU Requirements</A
-></H1
-><P
->CPU requirements for <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 range from i486-class machines
+<span class="acronym">BIND</span> 9 is fully multithreaded, allowing full utilization of
+multiprocessor systems for installations that need it.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2547132"></a>CPU Requirements</h2></div></div></div>
+<p>CPU requirements for <span class="acronym">BIND</span> 9 range from i486-class machines
 for serving of static zones without caching, to enterprise-class
 machines if you intend to process many dynamic updates and DNSSEC
-signed zones, serving many thousands of queries per second.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN240"
->2.3. Memory Requirements</A
-></H1
-><P
->The memory of the server has to be large enough to fit the
-cache and zones loaded off disk.  The <B
-CLASS="command"
->max-cache-size</B
->
+signed zones, serving many thousands of queries per second.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2547143"></a>Memory Requirements</h2></div></div></div>
+<p>The memory of the server has to be large enough to fit the
+cache and zones loaded off disk.  The <span><strong class="command">max-cache-size</strong></span>
 option can be used to limit the amount of memory used by the cache,
-at the expense of reducing cache hit rates and causing more <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->
+at the expense of reducing cache hit rates and causing more <span class="acronym">DNS</span>
 traffic. It is still good practice to have enough memory to load
 all zone and cache data into memory &#8212; unfortunately, the best way
 to determine this for a given installation is to watch the name server
 in operation. After a few weeks the server process should reach
 a relatively stable size where entries are expiring from the cache as
-fast as they are being inserted.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN245"
->2.4. Name Server Intensive Environment Issues</A
-></H1
-><P
->For name server intensive environments, there are two alternative
+fast as they are being inserted.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2547158"></a>Name Server Intensive Environment Issues</h2></div></div></div>
+<p>For name server intensive environments, there are two alternative
 configurations that may be used. The first is where clients and
 any second-level internal name servers query a main name server, which
 has enough memory to build a large cache. This approach minimizes
@@ -201,84 +98,33 @@ is to set up second-level internal name servers to make queries independently.
 In this configuration, none of the individual machines needs to
 have as much memory or CPU power as in the first alternative, but
 this has the disadvantage of making many more external queries,
-as none of the name servers share their cached data.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN248"
->2.5. Supported Operating Systems</A
-></H1
-><P
->ISC <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 compiles and runs on a large number
+as none of the name servers share their cached data.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2547303"></a>Supported Operating Systems</h2></div></div></div>
+<p>ISC <span class="acronym">BIND</span> 9 compiles and runs on a large number
 of Unix-like operating system and on Windows NT / 2000.  For an up-to-date
 list of supported systems, see the README file in the top level directory
-of the BIND 9 source distribution.</P
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch01.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch03.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Introduction</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Name Server Configuration</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+of the BIND 9 source distribution.</p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch01.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch03.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 1. Introduction  </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 3. Name Server Configuration</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch03.html b/contrib/bind9/doc/arm/Bv9ARM.ch03.html
index 37362d5daefe..4d6d93be1f1b 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch03.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch03.html
@@ -1,133 +1,79 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Name Server Configuration</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="BIND Resource Requirements"
-HREF="Bv9ARM.ch02.html"><LINK
-REL="NEXT"
-TITLE="Advanced DNS Features"
-HREF="Bv9ARM.ch04.html"></HEAD
-><BODY
-CLASS="chapter"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch02.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch04.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="chapter"
-><H1
-><A
-NAME="ch03"
-></A
->Chapter 3. Name Server Configuration</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->3.1. <A
-HREF="Bv9ARM.ch03.html#sample_configuration"
->Sample Configurations</A
-></DT
-><DT
->3.2. <A
-HREF="Bv9ARM.ch03.html#AEN268"
->Load Balancing</A
-></DT
-><DT
->3.3. <A
-HREF="Bv9ARM.ch03.html#AEN345"
->Name Server Operations</A
-></DT
-></DL
-></DIV
-><P
->In this section we provide some suggested configurations along
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch03.html,v 1.26.2.5.4.11 2005/10/13 02:33:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 3. Name Server Configuration</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
+<link rel="next" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 3. Name Server Configuration</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch02.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch04.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch03"></a>Chapter 3. Name Server Configuration</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547334">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547350">An Authoritative-only Name Server</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2547372">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2547656">Name Server Operations</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547661">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2548915">Signals</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<p>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
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="sample_configuration"
->3.1. Sample Configurations</A
-></H1
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN257"
->3.1.1. A Caching-only Name Server</A
-></H2
-><P
->The following sample configuration is appropriate for a caching-only
+option setting.</p>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="sample_configuration"></a>Sample Configurations</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2547334"></a>A Caching-only Name Server</h3></div></div></div>
+<p>The following sample configuration is appropriate for a caching-only
 name server for use by clients internal to a corporation.  All queries
-from outside clients are refused using the <B
-CLASS="command"
->allow-query</B
->
+from outside clients are refused using the <span><strong class="command">allow-query</strong></span>
 option.  Alternatively, the same effect could be achieved using suitable
-firewall rules.</P
-><PRE
-CLASS="programlisting"
->&#13;// Two corporate subnets we wish to allow queries from.
+firewall rules.</p>
+<pre class="programlisting">
+// Two corporate subnets we wish to allow queries from.
 acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
 options {
      directory "/etc/namedb";           // Working directory
@@ -139,29 +85,16 @@ zone "0.0.127.in-addr.arpa" {
      file "localhost.rev";
      notify no;
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN262"
->3.1.2. An Authoritative-only Name Server</A
-></H2
-><P
->This sample configuration is for an authoritative-only server
-that is the master server for "<TT
-CLASS="filename"
->example.com</TT
->"
-and a slave for the subdomain "<TT
-CLASS="filename"
->eng.example.com</TT
->".</P
-><PRE
-CLASS="programlisting"
->&#13;options {
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2547350"></a>An Authoritative-only Name Server</h3></div></div></div>
+<p>This sample configuration is for an authoritative-only server
+that is the master server for "<code class="filename">example.com</code>"
+and a slave for the subdomain "<code class="filename">eng.example.com</code>".</p>
+<pre class="programlisting">
+options {
      directory "/etc/namedb";           // Working directory
      allow-query { any; };              // This is the default
      recursion no;                      // Do not provide recursive service
@@ -190,1070 +123,321 @@ zone "eng.example.com" {
      // IP address of eng.example.com master server
      masters { 192.168.4.12; };
 };
-</PRE
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN268"
->3.2. Load Balancing</A
-></H1
-><P
->A primitive form of load balancing can be achieved in
-the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> by using multiple A records for one name.</P
-><P
->For example, if you have three WWW servers with network addresses
+</pre>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2547372"></a>Load Balancing</h2></div></div></div>
+<p>A primitive form of load balancing can be achieved in
+the <span class="acronym">DNS</span> by using multiple A records for one name.</p>
+<p>For example, if you have three WWW servers with network addresses
 of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the
 following means that clients will connect to each machine one third
-of the time:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN273"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
->Name</P
-></TD
-><TD
-><P
->TTL</P
-></TD
-><TD
-><P
->CLASS</P
-></TD
-><TD
-><P
->TYPE</P
-></TD
-><TD
-><P
->Resource Record (RR) Data</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->www</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->600</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10.0.0.1</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->600</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10.0.0.2</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->600</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10.0.0.3</VAR
-></P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->When a resolver queries for these records, <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> will rotate
+of the time:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p>Name</p></td>
+<td><p>TTL</p></td>
+<td><p>CLASS</p></td>
+<td><p>TYPE</p></td>
+<td><p>Resource Record (RR) Data</p></td>
+</tr>
+<tr>
+<td><p><code class="literal">www</code></p></td>
+<td><p><code class="literal">600</code></p></td>
+<td><p><code class="literal">IN</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">10.0.0.1</code></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p><code class="literal">600</code></p></td>
+<td><p><code class="literal">IN</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">10.0.0.2</code></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p><code class="literal">600</code></p></td>
+<td><p><code class="literal">IN</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">10.0.0.3</code></p></td>
+</tr>
+</tbody>
+</table></div>
+<p>When a resolver queries for these records, <span class="acronym">BIND</span> will rotate
     them and respond to the query with the records in a different
     order.  In the example above, clients will randomly receive
     records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
-    will use the first record returned and discard the rest.</P
-><P
->For more detail on ordering responses, check the
-    <B
-CLASS="command"
->rrset-order</B
-> substatement in the
-    <B
-CLASS="command"
->options</B
-> statement, see
-    <A
-HREF="Bv9ARM.ch06.html#rrset_ordering"
-><I
->RRset Ordering</I
-></A
->.
+    will use the first record returned and discard the rest.</p>
+<p>For more detail on ordering responses, check the
+    <span><strong class="command">rrset-order</strong></span> substatement in the
+    <span><strong class="command">options</strong></span> statement, see
+    <a href="Bv9ARM.ch06.html#rrset_ordering">RRset Ordering</a>.
     This substatement is not supported in
-    <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9, and only the ordering scheme described above is
-    available.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN345"
->3.3. Name Server Operations</A
-></H1
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN347"
->3.3.1. Tools for Use With the Name Server Daemon</A
-></H2
-><P
->There are several indispensable diagnostic, administrative
+    <span class="acronym">BIND</span> 9, and only the ordering scheme described above is
+    available.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2547656"></a>Name Server Operations</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2547661"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
+<p>There are several indispensable diagnostic, administrative
 and monitoring tools available to the system administrator for controlling
 and debugging the name server daemon. We describe several in this
-section </P
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="diagnostic_tools"
->3.3.1.1. Diagnostic Tools</A
-></H3
-><P
->The <B
-CLASS="command"
->dig</B
->, <B
-CLASS="command"
->host</B
->, and
-<B
-CLASS="command"
->nslookup</B
-> programs are all command line tools
+section </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="diagnostic_tools"></a>Diagnostic Tools</h4></div></div></div>
+<p>The <span><strong class="command">dig</strong></span>, <span><strong class="command">host</strong></span>, and
+<span><strong class="command">nslookup</strong></span> programs are all command line tools
 for manually querying name servers.  They differ in style and
 output format.
-</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->dig</B
-></DT
-><DD
-><P
->The domain information groper (<B
-CLASS="command"
->dig</B
->)
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><a name="dig"></a><span><strong class="command">dig</strong></span></span></dt>
+<dd>
+<p>The domain information groper (<span><strong class="command">dig</strong></span>)
 is the most versatile and complete of these lookup tools.
 It has two modes: simple interactive
 mode for a single query, and batch mode which executes a query for
 each in a list of several query lines. All query options are accessible
-from the command line.</P
-><P
-><B
-CLASS="command"
->dig</B
->  [@<VAR
-CLASS="replaceable"
->server</VAR
->]  <VAR
-CLASS="replaceable"
->domain</VAR
->  [<VAR
-CLASS="replaceable"
->query-type</VAR
->] [<VAR
-CLASS="replaceable"
->query-class</VAR
->] [+<VAR
-CLASS="replaceable"
->query-option</VAR
->] [-<VAR
-CLASS="replaceable"
->dig-option</VAR
->] [%<VAR
-CLASS="replaceable"
->comment</VAR
->]</P
-><P
->The usual simple use of dig will take the form</P
-><P
-><B
-CLASS="command"
->dig @server domain query-type query-class</B
-></P
-><P
->For more information and a list of available commands and
-options, see the <B
-CLASS="command"
->dig</B
-> man page.</P
-></DD
-><DT
-><B
-CLASS="command"
->host</B
-></DT
-><DD
-><P
->The <B
-CLASS="command"
->host</B
-> utility emphasizes simplicity
+from the command line.</p>
+<div class="cmdsynopsis"><p><code class="command">dig</code>  [@<em class="replaceable"><code>server</code></em>]  <em class="replaceable"><code>domain</code></em>  [<em class="replaceable"><code>query-type</code></em>] [<em class="replaceable"><code>query-class</code></em>] [+<em class="replaceable"><code>query-option</code></em>] [-<em class="replaceable"><code>dig-option</code></em>] [%<em class="replaceable"><code>comment</code></em>]</p></div>
+<p>The usual simple use of dig will take the form</p>
+<p><span><strong class="command">dig @server domain query-type query-class</strong></span></p>
+<p>For more information and a list of available commands and
+options, see the <span><strong class="command">dig</strong></span> man page.</p>
+</dd>
+<dt><span class="term"><span><strong class="command">host</strong></span></span></dt>
+<dd>
+<p>The <span><strong class="command">host</strong></span> utility emphasizes simplicity
 and ease of use.  By default, it converts
 between host names and Internet addresses, but its functionality
-can be extended with the use of options.</P
-><P
-><B
-CLASS="command"
->host</B
->  [-aCdlrTwv] [-c <VAR
-CLASS="replaceable"
->class</VAR
->] [-N <VAR
-CLASS="replaceable"
->ndots</VAR
->] [-t <VAR
-CLASS="replaceable"
->type</VAR
->] [-W <VAR
-CLASS="replaceable"
->timeout</VAR
->] [-R <VAR
-CLASS="replaceable"
->retries</VAR
->]  <VAR
-CLASS="replaceable"
->hostname</VAR
->  [<VAR
-CLASS="replaceable"
->server</VAR
->]</P
-><P
->For more information and a list of available commands and
-options, see the <B
-CLASS="command"
->host</B
-> man page.</P
-></DD
-><DT
-><B
-CLASS="command"
->nslookup</B
-></DT
-><DD
-><P
-><B
-CLASS="command"
->nslookup</B
-> has two modes: interactive
+can be extended with the use of options.</p>
+<div class="cmdsynopsis"><p><code class="command">host</code>  [-aCdlrTwv] [-c <em class="replaceable"><code>class</code></em>] [-N <em class="replaceable"><code>ndots</code></em>] [-t <em class="replaceable"><code>type</code></em>] [-W <em class="replaceable"><code>timeout</code></em>] [-R <em class="replaceable"><code>retries</code></em>]  <em class="replaceable"><code>hostname</code></em>  [<em class="replaceable"><code>server</code></em>]</p></div>
+<p>For more information and a list of available commands and
+options, see the <span><strong class="command">host</strong></span> man page.</p>
+</dd>
+<dt><span class="term"><span><strong class="command">nslookup</strong></span></span></dt>
+<dd>
+<p><span><strong class="command">nslookup</strong></span> has two modes: interactive
 and non-interactive. Interactive mode allows the user to query name servers
 for information about various hosts and domains or to print a list
 of hosts in a domain. Non-interactive mode is used to print just
-the name and requested information for a host or domain.</P
-><P
-><B
-CLASS="command"
->nslookup</B
->  [-option...] [<VAR
-CLASS="replaceable"
->host-to-find</VAR
-> | -  [server]]</P
-><P
->Interactive mode is entered when no arguments are given (the
+the name and requested information for a host or domain.</p>
+<div class="cmdsynopsis"><p><code class="command">nslookup</code>  [-option...] [[<em class="replaceable"><code>host-to-find</code></em>] |  [-  [server]]]</p></div>
+<p>Interactive mode is entered when no arguments are given (the
 default name server will be used) or when the first argument is a
 hyphen (`-') and the second argument is the host name or Internet address
-of a name server.</P
-><P
->Non-interactive mode is used when the name or Internet address
+of a name server.</p>
+<p>Non-interactive mode is used when the name or Internet address
 of the host to be looked up is given as the first argument. The
-optional second argument specifies the host name or address of a name server.</P
-><P
->Due to its arcane user interface and frequently inconsistent
-behavior, we do not recommend the use of <B
-CLASS="command"
->nslookup</B
->.
-Use <B
-CLASS="command"
->dig</B
-> instead.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="admin_tools"
->3.3.1.2. Administrative Tools</A
-></H3
-><P
->Administrative tools play an integral part in the management
-of a server.</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><A
-NAME="named-checkconf"
-></A
-><B
-CLASS="command"
->named-checkconf</B
-></DT
-><DD
-><P
->The <B
-CLASS="command"
->named-checkconf</B
-> program
-              checks the syntax of a <TT
-CLASS="filename"
->named.conf</TT
-> file.</P
-><P
-><B
-CLASS="command"
->named-checkconf</B
->  [-t <VAR
-CLASS="replaceable"
->directory</VAR
->] [<VAR
-CLASS="replaceable"
->filename</VAR
->]</P
-></DD
-><DT
-><A
-NAME="named-checkzone"
-></A
-><B
-CLASS="command"
->named-checkzone</B
-></DT
-><DD
-><P
->The <B
-CLASS="command"
->named-checkzone</B
-> program checks a master file for
-              syntax and consistency.</P
-><P
-><B
-CLASS="command"
->named-checkzone</B
->  [-djqvD] [-c <VAR
-CLASS="replaceable"
->class</VAR
->] [-o <VAR
-CLASS="replaceable"
->output</VAR
->] [-t <VAR
-CLASS="replaceable"
->directory</VAR
->] [-w <VAR
-CLASS="replaceable"
->directory</VAR
->] [-k <VAR
-CLASS="replaceable"
->(ignore|warn|fail)</VAR
->] [-n <VAR
-CLASS="replaceable"
->(ignore|warn|fail)</VAR
->]  <VAR
-CLASS="replaceable"
->zone</VAR
->  [<VAR
-CLASS="replaceable"
->filename</VAR
->]</P
-></DD
-><DT
-><A
-NAME="rndc"
-></A
-><B
-CLASS="command"
->rndc</B
-></DT
-><DD
-><P
->The remote name daemon control
-              (<B
-CLASS="command"
->rndc</B
->) program allows the system
+optional second argument specifies the host name or address of a name server.</p>
+<p>Due to its arcane user interface and frequently inconsistent
+behavior, we do not recommend the use of <span><strong class="command">nslookup</strong></span>.
+Use <span><strong class="command">dig</strong></span> instead.</p>
+</dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="admin_tools"></a>Administrative Tools</h4></div></div></div>
+<p>Administrative tools play an integral part in the management
+of a server.</p>
+<div class="variablelist"><dl>
+<dt>
+<a name="named-checkconf"></a><span class="term"><span><strong class="command">named-checkconf</strong></span></span>
+</dt>
+<dd>
+<p>The <span><strong class="command">named-checkconf</strong></span> program
+              checks the syntax of a <code class="filename">named.conf</code> file.</p>
+<div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [-jvz] [-t <em class="replaceable"><code>directory</code></em>] [<em class="replaceable"><code>filename</code></em>]</p></div>
+</dd>
+<dt>
+<a name="named-checkzone"></a><span class="term"><span><strong class="command">named-checkzone</strong></span></span>
+</dt>
+<dd>
+<p>The <span><strong class="command">named-checkzone</strong></span> program checks a master file for
+              syntax and consistency.</p>
+<div class="cmdsynopsis"><p><code class="command">named-checkzone</code>  [-djqvD] [-c <em class="replaceable"><code>class</code></em>] [-o <em class="replaceable"><code>output</code></em>] [-t <em class="replaceable"><code>directory</code></em>] [-w <em class="replaceable"><code>directory</code></em>] [-k <em class="replaceable"><code>(ignore|warn|fail)</code></em>] [-n <em class="replaceable"><code>(ignore|warn|fail)</code></em>]  <em class="replaceable"><code>zone</code></em>  [<em class="replaceable"><code>filename</code></em>]</p></div>
+</dd>
+<dt>
+<a name="rndc"></a><span class="term"><span><strong class="command">rndc</strong></span></span>
+</dt>
+<dd>
+<p>The remote name daemon control
+              (<span><strong class="command">rndc</strong></span>) program allows the system
               administrator to control the operation of a name server.
-              If you run <B
-CLASS="command"
->rndc</B
-> without any options
-              it will display a usage message as follows:</P
-><P
-><B
-CLASS="command"
->rndc</B
->  [-c <VAR
-CLASS="replaceable"
->config</VAR
->] [-s <VAR
-CLASS="replaceable"
->server</VAR
->] [-p <VAR
-CLASS="replaceable"
->port</VAR
->] [-y <VAR
-CLASS="replaceable"
->key</VAR
->]  <VAR
-CLASS="replaceable"
->command</VAR
->  [<VAR
-CLASS="replaceable"
->command</VAR
->...]</P
-><P
-><B
-CLASS="command"
->command</B
-> is one of the following:</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><KBD
-CLASS="userinput"
->reload</KBD
-></DT
-><DD
-><P
->Reload configuration file and zones.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->reload <VAR
-CLASS="replaceable"
->zone</VAR
->
-       [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->class</VAR
->
-           [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->view</VAR
-></SPAN
->]</SPAN
->]</KBD
-></DT
-><DD
-><P
->Reload the given zone.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->refresh <VAR
-CLASS="replaceable"
->zone</VAR
->
-       [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->class</VAR
->
-           [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->view</VAR
-></SPAN
->]</SPAN
->]</KBD
-></DT
-><DD
-><P
->Schedule zone maintenance for the given zone.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->retransfer <VAR
-CLASS="replaceable"
->zone</VAR
->
-       [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->class</VAR
->
-           [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->view</VAR
-></SPAN
->]</SPAN
->]</KBD
-></DT
-><DD
-><P
->Retransfer the given zone from the master.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->freeze <VAR
-CLASS="replaceable"
->zone</VAR
->
-       [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->class</VAR
->
-           [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->view</VAR
-></SPAN
->]</SPAN
->]</KBD
-></DT
-><DD
-><P
->Suspend updates to a dynamic zone.  This allows manual
+              If you run <span><strong class="command">rndc</strong></span> without any options
+              it will display a usage message as follows:</p>
+<div class="cmdsynopsis"><p><code class="command">rndc</code>  [-c <em class="replaceable"><code>config</code></em>] [-s <em class="replaceable"><code>server</code></em>] [-p <em class="replaceable"><code>port</code></em>] [-y <em class="replaceable"><code>key</code></em>]  <em class="replaceable"><code>command</code></em>  [<em class="replaceable"><code>command</code></em>...]</p></div>
+<p><span><strong class="command">command</strong></span> is one of the following:</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><strong class="userinput"><code>reload</code></strong></span></dt>
+<dd><p>Reload configuration file and zones.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>reload <em class="replaceable"><code>zone</code></em>
+       [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
+<dd><p>Reload the given zone.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>refresh <em class="replaceable"><code>zone</code></em>
+       [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
+<dd><p>Schedule zone maintenance for the given zone.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>retransfer <em class="replaceable"><code>zone</code></em>
+       [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
+<dd><p>Retransfer the given zone from the master.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>freeze [<span class="optional"><em class="replaceable"><code>zone</code></em>
+       [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</span>]</code></strong></span></dt>
+<dd><p>Suspend updates to a dynamic zone.  If no zone is specified
+	then all zones are suspended.  This allows manual
     edits to be made to a zone normally updated by dynamic update.  It
     also causes changes in the journal file to be synced into the master
     and the journal file to be removed.  All dynamic update attempts will
-    be refused while the zone is frozen.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->unfreeze <VAR
-CLASS="replaceable"
->zone</VAR
->
-       [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->class</VAR
->
-           [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->view</VAR
-></SPAN
->]</SPAN
->]</KBD
-></DT
-><DD
-><P
->Enable updates to a frozen dynamic zone.  This causes
+    be refused while the zone is frozen.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>thaw [<span class="optional"><em class="replaceable"><code>zone</code></em>
+       [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</span>]</code></strong></span></dt>
+<dd><p>Enable updates to a frozen dynamic zone.  If no zone is
+    specified then all frozen zones are enabled.  This causes
     the server to reload the zone from disk, and re-enables dynamic updates
-    after the load has completed.  After a zone is unfrozen, dynamic updates
-    will no longer be refused.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->reconfig</KBD
-></DT
-><DD
-><P
->Reload the configuration file and load new zones,
+    after the load has completed.  After a zone is thawed, dynamic updates
+    will no longer be refused.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>notify <em class="replaceable"><code>zone</code></em>
+       [<span class="optional"><em class="replaceable"><code>class</code></em>
+           [<span class="optional"><em class="replaceable"><code>view</code></em></span>]</span>]</code></strong></span></dt>
+<dd><p>Resend NOTIFY messages for the zone</p></dd>
+<dt><span class="term"><strong class="userinput"><code>reconfig</code></strong></span></dt>
+<dd><p>Reload the configuration file and load new zones,
    but do not reload existing zone files even if they have changed.
-   This is faster than a full <B
-CLASS="command"
->reload</B
-> when there
+   This is faster than a full <span><strong class="command">reload</strong></span> when there
    is a large number of zones because it avoids the need to examine the
    modification times of the zones files.
-   </P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->stats</KBD
-></DT
-><DD
-><P
->Write server statistics to the statistics file.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->querylog</KBD
-></DT
-><DD
-><P
->Toggle query logging. Query logging can also be enabled
-   by explicitly directing the <B
-CLASS="command"
->queries</B
->
-   <B
-CLASS="command"
->category</B
-> to a <B
-CLASS="command"
->channel</B
-> in the
-   <B
-CLASS="command"
->logging</B
-> section of
-   <TT
-CLASS="filename"
->named.conf</TT
->.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->dumpdb</KBD
-></DT
-><DD
-><P
->Dump the server's caches to the dump file. </P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->stop</KBD
-></DT
-><DD
-><P
->Stop the server,
-   making sure any recent changes
+   </p></dd>
+<dt><span class="term"><strong class="userinput"><code>stats</code></strong></span></dt>
+<dd><p>Write server statistics to the statistics file.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>querylog</code></strong></span></dt>
+<dd><p>Toggle query logging. Query logging can also be enabled
+   by explicitly directing the <span><strong class="command">queries</strong></span>
+   <span><strong class="command">category</strong></span> to a <span><strong class="command">channel</strong></span> in the
+   <span><strong class="command">logging</strong></span> section of
+   <code class="filename">named.conf</code>.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>dumpdb [<span class="optional">-all|-cache|-zone</span>] [<span class="optional"><em class="replaceable"><code>view ...</code></em></span>]</code></strong></span></dt>
+<dd><p>Dump the server's caches (default) and / or zones to the
+	 dump file for the specified views.  If no view is specified all
+	 views are dumped.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>stop [<span class="optional">-p</span>]</code></strong></span></dt>
+<dd><p>Stop the server, making sure any recent changes
    made through dynamic update or IXFR are first saved to the master files
-   of the updated zones.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->halt</KBD
-></DT
-><DD
-><P
->Stop the server immediately.  Recent changes
+   of the updated zones.  If -p is specified named's process id is returned.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>halt [<span class="optional">-p</span>]</code></strong></span></dt>
+<dd><p>Stop the server immediately.  Recent changes
    made through dynamic update or IXFR are not saved to the master files,
    but will be rolled forward from the journal files when the server
-   is restarted.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->trace</KBD
-></DT
-><DD
-><P
->Increment the servers debugging level by one. </P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->trace <VAR
-CLASS="replaceable"
->level</VAR
-></KBD
-></DT
-><DD
-><P
->Sets the server's debugging level to an explicit
-   value.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->notrace</KBD
-></DT
-><DD
-><P
->Sets the server's debugging level to 0.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->flush</KBD
-></DT
-><DD
-><P
->Flushes the server's cache.</P
-></DD
-><DT
-><KBD
-CLASS="userinput"
->status</KBD
-></DT
-><DD
-><P
->Display status of the server.
-Note the number of zones includes the internal <B
-CLASS="command"
->bind/CH</B
-> zone
-and the default <B
-CLASS="command"
->./IN</B
-> hint zone if there is not a
-explicit root zone configured.</P
-></DD
-></DL
-></DIV
-><P
->In <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9.2, <B
-CLASS="command"
->rndc</B
->
-supports all the commands of the BIND 8 <B
-CLASS="command"
->ndc</B
->
-utility except <B
-CLASS="command"
->ndc start</B
-> and
-<B
-CLASS="command"
->ndc restart</B
->, which were also
-not supported in <B
-CLASS="command"
->ndc</B
->'s channel mode.</P
-><P
->A configuration file is required, since all
+   is restarted.  If -p is specified named's process id is returned.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>trace</code></strong></span></dt>
+<dd><p>Increment the servers debugging level by one. </p></dd>
+<dt><span class="term"><strong class="userinput"><code>trace <em class="replaceable"><code>level</code></em></code></strong></span></dt>
+<dd><p>Sets the server's debugging level to an explicit
+   value.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>notrace</code></strong></span></dt>
+<dd><p>Sets the server's debugging level to 0.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>flush</code></strong></span></dt>
+<dd><p>Flushes the server's cache.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>flushname</code></strong> <em class="replaceable"><code>name</code></em></span></dt>
+<dd><p>Flushes the given name from the server's cache.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>status</code></strong></span></dt>
+<dd><p>Display status of the server.
+Note the number of zones includes the internal <span><strong class="command">bind/CH</strong></span> zone
+and the default <span><strong class="command">./IN</strong></span> hint zone if there is not a
+explicit root zone configured.</p></dd>
+<dt><span class="term"><strong class="userinput"><code>recursing</code></strong></span></dt>
+<dd><p>Dump the list of queries named is currently recursing
+   on.
+   </p></dd>
+</dl></div>
+<p>In <span class="acronym">BIND</span> 9.2, <span><strong class="command">rndc</strong></span>
+supports all the commands of the BIND 8 <span><strong class="command">ndc</strong></span>
+utility except <span><strong class="command">ndc start</strong></span> and
+<span><strong class="command">ndc restart</strong></span>, which were also
+not supported in <span><strong class="command">ndc</strong></span>'s channel mode.</p>
+<p>A configuration file is required, since all
 communication with the server is authenticated with
 digital signatures that rely on a shared secret, and
 there is no way to provide that secret other than with a
 configuration file.  The default location for the
-<B
-CLASS="command"
->rndc</B
-> configuration file is
-<TT
-CLASS="filename"
->/etc/rndc.conf</TT
->, but an alternate
-location can be specified with the <VAR
-CLASS="option"
->-c</VAR
->
+<span><strong class="command">rndc</strong></span> configuration file is
+<code class="filename">/etc/rndc.conf</code>, but an alternate
+location can be specified with the <code class="option">-c</code>
 option.  If the configuration file is not found,
-<B
-CLASS="command"
->rndc</B
-> will also look in
-<TT
-CLASS="filename"
->/etc/rndc.key</TT
-> (or whatever
-<VAR
-CLASS="varname"
->sysconfdir</VAR
-> was defined when
-the <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> build was configured).
-The <TT
-CLASS="filename"
->rndc.key</TT
-> file is generated by
-running <B
-CLASS="command"
->rndc-confgen -a</B
-> as described in
-<A
-HREF="Bv9ARM.ch06.html#controls_statement_definition_and_usage"
->Section 6.2.4</A
->.</P
-><P
->The format of the configuration file is similar to
-that of <TT
-CLASS="filename"
->named.conf</TT
->, but limited to
-only four statements, the <B
-CLASS="command"
->options</B
->,
-<B
-CLASS="command"
->key</B
->, <B
-CLASS="command"
->server</B
-> and
-<B
-CLASS="command"
->include</B
->
+<span><strong class="command">rndc</strong></span> will also look in
+<code class="filename">/etc/rndc.key</code> (or whatever
+<code class="varname">sysconfdir</code> was defined when
+the <span class="acronym">BIND</span> build was configured).
+The <code class="filename">rndc.key</code> file is generated by
+running <span><strong class="command">rndc-confgen -a</strong></span> as described in
+<a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and Usage&#8221;</a>.</p>
+<p>The format of the configuration file is similar to
+that of <code class="filename">named.conf</code>, but limited to
+only four statements, the <span><strong class="command">options</strong></span>,
+<span><strong class="command">key</strong></span>, <span><strong class="command">server</strong></span> and
+<span><strong class="command">include</strong></span>
 statements.  These statements are what associate the
 secret keys to the servers with which they are meant to
 be shared.  The order of statements is not
-significant.</P
-><P
->The <B
-CLASS="command"
->options</B
-> statement has three clauses:
-<B
-CLASS="command"
->default-server</B
->, <B
-CLASS="command"
->default-key</B
->, 
-and <B
-CLASS="command"
->default-port</B
->.
-<B
-CLASS="command"
->default-server</B
-> takes a
+significant.</p>
+<p>The <span><strong class="command">options</strong></span> statement has three clauses:
+<span><strong class="command">default-server</strong></span>, <span><strong class="command">default-key</strong></span>, 
+and <span><strong class="command">default-port</strong></span>.
+<span><strong class="command">default-server</strong></span> takes a
 host name or address argument  and represents the server that will
-be contacted if no <VAR
-CLASS="option"
->-s</VAR
->
+be contacted if no <code class="option">-s</code>
 option is provided on the command line.  
-<B
-CLASS="command"
->default-key</B
-> takes
-the name of a key as its argument, as defined by a <B
-CLASS="command"
->key</B
-> statement.
-<B
-CLASS="command"
->default-port</B
-> specifies the port to which
-<B
-CLASS="command"
->rndc</B
-> should connect if no
+<span><strong class="command">default-key</strong></span> takes
+the name of a key as its argument, as defined by a <span><strong class="command">key</strong></span> statement.
+<span><strong class="command">default-port</strong></span> specifies the port to which
+<span><strong class="command">rndc</strong></span> should connect if no
 port is given on the command line or in a
-<B
-CLASS="command"
->server</B
-> statement.</P
-><P
->The <B
-CLASS="command"
->key</B
-> statement defines an key to be used
-by <B
-CLASS="command"
->rndc</B
-> when authenticating with
-<B
-CLASS="command"
->named</B
->.  Its syntax is identical to the
-<B
-CLASS="command"
->key</B
-> statement in named.conf.
-The keyword <KBD
-CLASS="userinput"
->key</KBD
-> is
+<span><strong class="command">server</strong></span> statement.</p>
+<p>The <span><strong class="command">key</strong></span> statement defines an key to be used
+by <span><strong class="command">rndc</strong></span> when authenticating with
+<span><strong class="command">named</strong></span>.  Its syntax is identical to the
+<span><strong class="command">key</strong></span> statement in named.conf.
+The keyword <strong class="userinput"><code>key</code></strong> is
 followed by a key name, which must be a valid
 domain name, though it need not actually be hierarchical; thus,
-a string like "<KBD
-CLASS="userinput"
->rndc_key</KBD
->" is a valid name.
-The <B
-CLASS="command"
->key</B
-> statement has two clauses:
-<B
-CLASS="command"
->algorithm</B
-> and <B
-CLASS="command"
->secret</B
->.
+a string like "<strong class="userinput"><code>rndc_key</code></strong>" is a valid name.
+The <span><strong class="command">key</strong></span> statement has two clauses:
+<span><strong class="command">algorithm</strong></span> and <span><strong class="command">secret</strong></span>.
 While the configuration parser will accept any string as the argument
-to algorithm, currently only the string "<KBD
-CLASS="userinput"
->hmac-md5</KBD
->"
-has any meaning.  The secret is a base-64 encoded string.</P
-><P
->The <B
-CLASS="command"
->server</B
-> statement associates a key
-defined using the <B
-CLASS="command"
->key</B
-> statement with a server.
-The keyword <KBD
-CLASS="userinput"
->server</KBD
-> is followed by a
-host name or address.  The <B
-CLASS="command"
->server</B
-> statement
-has two clauses: <B
-CLASS="command"
->key</B
-> and <B
-CLASS="command"
->port</B
->.
-The <B
-CLASS="command"
->key</B
-> clause specifies the name of the key
+to algorithm, currently only the string "<strong class="userinput"><code>hmac-md5</code></strong>"
+has any meaning.  The secret is a base-64 encoded string.</p>
+<p>The <span><strong class="command">server</strong></span> statement associates a key
+defined using the <span><strong class="command">key</strong></span> statement with a server.
+The keyword <strong class="userinput"><code>server</code></strong> is followed by a
+host name or address.  The <span><strong class="command">server</strong></span> statement
+has two clauses: <span><strong class="command">key</strong></span> and <span><strong class="command">port</strong></span>.
+The <span><strong class="command">key</strong></span> clause specifies the name of the key
 to be used when communicating with this server, and the
-<B
-CLASS="command"
->port</B
-> clause can be used to
-specify the port <B
-CLASS="command"
->rndc</B
-> should connect
-to on the server.</P
-><P
->A sample minimal configuration file is as follows:</P
-><PRE
-CLASS="programlisting"
->&#13;key rndc_key {
+<span><strong class="command">port</strong></span> clause can be used to
+specify the port <span><strong class="command">rndc</strong></span> should connect
+to on the server.</p>
+<p>A sample minimal configuration file is as follows:</p>
+<pre class="programlisting">
+key rndc_key {
      algorithm "hmac-md5";
      secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
 };
@@ -1261,213 +445,81 @@ options {
      default-server 127.0.0.1;
      default-key    rndc_key;
 };
-</PRE
-><P
->This file, if installed as <TT
-CLASS="filename"
->/etc/rndc.conf</TT
->,
-would allow the command:</P
-><P
-><SAMP
-CLASS="prompt"
->$ </SAMP
-><KBD
-CLASS="userinput"
->rndc reload</KBD
-></P
-><P
->to connect to 127.0.0.1 port 953 and cause the name server
+</pre>
+<p>This file, if installed as <code class="filename">/etc/rndc.conf</code>,
+would allow the command:</p>
+<p><code class="prompt">$ </code><strong class="userinput"><code>rndc reload</code></strong></p>
+<p>to connect to 127.0.0.1 port 953 and cause the name server
 to reload, if a name server on the local machine were running with
-following controls statements:</P
-><PRE
-CLASS="programlisting"
->&#13;controls {
+following controls statements:</p>
+<pre class="programlisting">
+controls {
         inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
 };
-</PRE
-><P
->and it had an identical key statement for
-<VAR
-CLASS="literal"
->rndc_key</VAR
->.</P
-><P
->Running the <B
-CLASS="command"
->rndc-confgen</B
-> program will
-conveniently create a <TT
-CLASS="filename"
->rndc.conf</TT
->
+</pre>
+<p>and it had an identical key statement for
+<code class="literal">rndc_key</code>.</p>
+<p>Running the <span><strong class="command">rndc-confgen</strong></span> program will
+conveniently create a <code class="filename">rndc.conf</code>
 file for you, and also display the
-corresponding <B
-CLASS="command"
->controls</B
-> statement that you need to
-add to <TT
-CLASS="filename"
->named.conf</TT
->.  Alternatively,
-you can run <B
-CLASS="command"
->rndc-confgen -a</B
-> to set up
-a <TT
-CLASS="filename"
->rndc.key</TT
-> file and not modify 
-<TT
-CLASS="filename"
->named.conf</TT
-> at all.
-</P
-></DD
-></DL
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN689"
->3.3.2. Signals</A
-></H2
-><P
->Certain UNIX signals cause the name server to take specific
+corresponding <span><strong class="command">controls</strong></span> statement that you need to
+add to <code class="filename">named.conf</code>.  Alternatively,
+you can run <span><strong class="command">rndc-confgen -a</strong></span> to set up
+a <code class="filename">rndc.key</code> file and not modify 
+<code class="filename">named.conf</code> at all.
+</p>
+</dd>
+</dl></div>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2548915"></a>Signals</h3></div></div></div>
+<p>Certain UNIX signals cause the name server to take specific
 actions, as described in the following table.  These signals can
-be sent using the <B
-CLASS="command"
->kill</B
-> command.</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN693"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><B
-CLASS="command"
->SIGHUP</B
-></P
-></TD
-><TD
-><P
->Causes the server to read <TT
-CLASS="filename"
->named.conf</TT
-> and
-reload the database. </P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->SIGTERM</B
-></P
-></TD
-><TD
-><P
->Causes the server to clean up and exit.</P
-></TD
-></TR
-><TR
-><TD
->&#13;<P
-><B
-CLASS="command"
->SIGINT</B
-></P
->
-</TD
-><TD
-><P
->Causes the server to clean up and exit.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch02.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch04.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> Resource Requirements</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Advanced DNS Features</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+be sent using the <span><strong class="command">kill</strong></span> command.</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span><strong class="command">SIGHUP</strong></span></p></td>
+<td><p>Causes the server to read <code class="filename">named.conf</code> and
+reload the database. </p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">SIGTERM</strong></span></p></td>
+<td><p>Causes the server to clean up and exit.</p></td>
+</tr>
+<tr>
+<td>
+<p><span><strong class="command">SIGINT</strong></span></p>
+</td>
+<td><p>Causes the server to clean up and exit.</p></td>
+</tr>
+</tbody>
+</table></div>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch02.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch04.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 2. <span class="acronym">BIND</span> Resource Requirements </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 4. Advanced DNS Features</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch04.html b/contrib/bind9/doc/arm/Bv9ARM.ch04.html
index 8a4ab28875ca..8165dbba9675 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch04.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch04.html
@@ -1,618 +1,273 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Advanced DNS Features</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="Name Server Configuration"
-HREF="Bv9ARM.ch03.html"><LINK
-REL="NEXT"
-TITLE="The BIND 9 Lightweight Resolver"
-HREF="Bv9ARM.ch05.html"></HEAD
-><BODY
-CLASS="chapter"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch03.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch05.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="chapter"
-><H1
-><A
-NAME="ch04"
-></A
->Chapter 4. Advanced DNS Features</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->4.1. <A
-HREF="Bv9ARM.ch04.html#notify"
->Notify</A
-></DT
-><DT
->4.2. <A
-HREF="Bv9ARM.ch04.html#dynamic_update"
->Dynamic Update</A
-></DT
-><DT
->4.3. <A
-HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
->Incremental Zone Transfers (IXFR)</A
-></DT
-><DT
->4.4. <A
-HREF="Bv9ARM.ch04.html#AEN767"
->Split DNS</A
-></DT
-><DT
->4.5. <A
-HREF="Bv9ARM.ch04.html#tsig"
->TSIG</A
-></DT
-><DT
->4.6. <A
-HREF="Bv9ARM.ch04.html#AEN927"
->TKEY</A
-></DT
-><DT
->4.7. <A
-HREF="Bv9ARM.ch04.html#AEN942"
->SIG(0)</A
-></DT
-><DT
->4.8. <A
-HREF="Bv9ARM.ch04.html#DNSSEC"
->DNSSEC</A
-></DT
-><DT
->4.9. <A
-HREF="Bv9ARM.ch04.html#AEN1011"
->IPv6 Support in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9</A
-></DT
-></DL
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="notify"
->4.1. Notify</A
-></H1
-><P
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> NOTIFY is a mechanism that allows master
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch04.html,v 1.30.2.6.2.14 2005/10/13 02:33:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 4. Advanced DNS Features</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch03.html" title="Chapter 3. Name Server Configuration">
+<link rel="next" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 4. Advanced DNS Features</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch04"></a>Chapter 4. Advanced DNS Features</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2549203">Split DNS</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549627">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549830">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549838">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549878">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549998">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550042">Errors</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550056">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550173">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550308">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550375">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550450">Configuring Servers</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550473">IPv6 Support in <span class="acronym">BIND</span> 9</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550600">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550620">Address to Name Lookups Using Nibble Format</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="notify"></a>Notify</h2></div></div></div>
+<p><span class="acronym">DNS</span> NOTIFY is a mechanism that allows master
 servers to notify their slave servers of changes to a zone's data. In
-response to a <B
-CLASS="command"
->NOTIFY</B
-> from a master server, the
+response to a <span><strong class="command">NOTIFY</strong></span> from a master server, the
 slave will check to see that its version of the zone is the
-current version and, if not, initiate a zone transfer.</P
-><P
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->
+current version and, if not, initiate a zone transfer.</p>
+<p><span class="acronym">DNS</span>
 For more information about
-<B
-CLASS="command"
->NOTIFY</B
->, see the description of the
-<B
-CLASS="command"
->notify</B
-> option in <A
-HREF="Bv9ARM.ch06.html#boolean_options"
->Section 6.2.16.1</A
-> and
-the description of the zone option <B
-CLASS="command"
->also-notify</B
-> in
-<A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->.  The <B
-CLASS="command"
->NOTIFY</B
->
+<span><strong class="command">NOTIFY</strong></span>, see the description of the
+<span><strong class="command">notify</strong></span> option in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a> and
+the description of the zone option <span><strong class="command">also-notify</strong></span> in
+<a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.  The <span><strong class="command">NOTIFY</strong></span>
 protocol is specified in RFC 1996.
-</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="dynamic_update"
->4.2. Dynamic Update</A
-></H1
-><P
->Dynamic Update is a method for adding, replacing or deleting
+</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="dynamic_update"></a>Dynamic Update</h2></div></div></div>
+<p>Dynamic Update is a method for adding, replacing or deleting
     records in a master server by sending it a special form of DNS
     messages.  The format and meaning of these messages is specified
-    in RFC 2136.</P
-><P
->Dynamic update is enabled on a zone-by-zone basis, by
-    including an <B
-CLASS="command"
->allow-update</B
-> or
-    <B
-CLASS="command"
->update-policy</B
-> clause in the
-    <B
-CLASS="command"
->zone</B
-> statement.</P
-><P
->Updating of secure zones (zones using DNSSEC) follows
+    in RFC 2136.</p>
+<p>Dynamic update is enabled on a zone-by-zone basis, by
+    including an <span><strong class="command">allow-update</strong></span> or
+    <span><strong class="command">update-policy</strong></span> clause in the
+    <span><strong class="command">zone</strong></span> statement.</p>
+<p>Updating of secure zones (zones using DNSSEC) follows
     RFC 3007: RRSIG and NSEC 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
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="journal"
->4.2.1. The journal file</A
-></H2
-><P
->All changes made to a zone using dynamic update are stored in the
+    on transaction signatures and an explicit server policy.</p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="journal"></a>The journal file</h3></div></div></div>
+<p>All changes made to a zone using dynamic update are stored in the
     zone's journal file.  This file is automatically created by the
-    server when when the first dynamic update takes place.  The name of
+    server when the first dynamic update takes place.  The name of
     the journal file is formed by appending the
-    extension <TT
-CLASS="filename"
->.jnl</TT
-> to the
+    extension <code class="filename">.jnl</code> to the
     name of the corresponding zone file.  The journal file is in a
-    binary format and should not be edited manually.</P
-><P
->The server will also occasionally write ("dump")
+    binary format and should not be edited manually.</p>
+<p>The server will also occasionally write ("dump")
     the complete contents of the updated zone to its zone file.
     This is not done immediately after
     each dynamic update, because that would be too slow when a large
     zone is updated frequently.  Instead, the dump is delayed by
-    up to 15 minutes, allowing additional updates to take place.</P
-><P
->When a server is restarted after a shutdown or crash, it will replay
+    up to 15 minutes, allowing additional updates to take place.</p>
+<p>When a server is restarted after a shutdown or crash, it will replay
     the journal file to incorporate into the zone any updates that took
-    place after the last zone dump.</P
-><P
->Changes that result from incoming incremental zone transfers are also
-    journalled in a similar way.</P
-><P
->The zone files of dynamic zones cannot normally be edited by
+    place after the last zone dump.</p>
+<p>Changes that result from incoming incremental zone transfers are also
+    journalled in a similar way.</p>
+<p>The zone files of dynamic zones cannot normally be edited by
     hand because they are not guaranteed to contain the most recent
     dynamic changes - those are only in the journal file.
     The only way to ensure that the zone file of a dynamic zone
-    is up to date is to run <B
-CLASS="command"
->rndc stop</B
->.</P
-><P
->If you have to make changes to a dynamic zone
+    is up to date is to run <span><strong class="command">rndc stop</strong></span>.</p>
+<p>If you have to make changes to a dynamic zone
     manually, the following procedure will work: Disable dynamic updates
     to the zone using
-    <B
-CLASS="command"
->rndc freeze <VAR
-CLASS="replaceable"
->zone</VAR
-></B
->.
-    This will also remove the zone's <TT
-CLASS="filename"
->.jnl</TT
-> file
+    <span><strong class="command">rndc freeze <em class="replaceable"><code>zone</code></em></strong></span>.
+    This will also remove the zone's <code class="filename">.jnl</code> file
     and update the master file.  Edit the zone file.  Run
-    <B
-CLASS="command"
->rndc unfreeze <VAR
-CLASS="replaceable"
->zone</VAR
-></B
->
-    to reload the changed zone and re-enable dynamic updates.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="incremental_zone_transfers"
->4.3. Incremental Zone Transfers (IXFR)</A
-></H1
-><P
->The incremental zone transfer (IXFR) protocol is a way for
+    <span><strong class="command">rndc unfreeze <em class="replaceable"><code>zone</code></em></strong></span>
+    to reload the changed zone and re-enable dynamic updates.</p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="incremental_zone_transfers"></a>Incremental Zone Transfers (IXFR)</h2></div></div></div>
+<p>The incremental zone transfer (IXFR) protocol is a way for
 slave servers to transfer only changed data, instead of having to
 transfer the entire zone. The IXFR protocol is specified in RFC
-1995. See <A
-HREF="Bv9ARM.ch09.html#proposed_standards"
->Proposed Standards</A
->.</P
-><P
->When acting as a master, <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9
+1995. See <a href="Bv9ARM.ch09.html#proposed_standards">Proposed Standards</a>.</p>
+<p>When acting as a master, <span class="acronym">BIND</span> 9
 supports IXFR for those zones
 where the necessary change history information is available. These
 include master zones maintained by dynamic update and slave zones
 whose data was obtained by IXFR.  For manually maintained master
 zones, and for slave zones obtained by performing a full zone 
 transfer (AXFR), IXFR is supported only if the option
-<B
-CLASS="command"
->ixfr-from-differences</B
-> is set
-to <KBD
-CLASS="userinput"
->yes</KBD
->.
-</P
-><P
->When acting as a slave, <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 will 
+<span><strong class="command">ixfr-from-differences</strong></span> is set
+to <strong class="userinput"><code>yes</code></strong>.
+</p>
+<p>When acting as a slave, <span class="acronym">BIND</span> 9 will 
 attempt to use IXFR unless
 it is explicitly disabled. For more information about disabling
-IXFR, see the description of the <B
-CLASS="command"
->request-ixfr</B
-> clause
-of the <B
-CLASS="command"
->server</B
-> statement.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN767"
->4.4. Split DNS</A
-></H1
-><P
->Setting up different views, or visibility, of the DNS space to
-internal and external resolvers is usually referred to as a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Split
-DNS</I
-></SPAN
-> setup. There are several reasons an organization
-would want to set up its DNS this way.</P
-><P
->One common reason for setting up a DNS system this way is
+IXFR, see the description of the <span><strong class="command">request-ixfr</strong></span> clause
+of the <span><strong class="command">server</strong></span> statement.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2549203"></a>Split DNS</h2></div></div></div>
+<p>Setting up different views, or visibility, of the DNS space to
+internal and external resolvers is usually referred to as a <span class="emphasis"><em>Split
+DNS</em></span> setup. There are several reasons an organization
+would want to set up its DNS this way.</p>
+<p>One common reason for setting up a DNS system this way is
 to hide "internal" DNS information from "external" clients on the
 Internet. There is some debate as to whether or not this is actually useful.
 Internal DNS information leaks out in many ways (via email headers,
 for example) and most savvy "attackers" can find the information
-they need using other means.</P
-><P
->Another common reason for setting up a Split DNS system is
+they need using other means.</p>
+<p>Another common reason for setting up a Split DNS system is
 to allow internal networks that are behind filters or in RFC 1918
 space (reserved IP space, as documented in RFC 1918) to resolve DNS
 on the Internet. Split DNS can also be used to allow mail from outside
-back in to the internal network.</P
-><P
->Here is an example of a split DNS setup:</P
-><P
->Let's say a company named <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Example, Inc.</I
-></SPAN
->
-(<VAR
-CLASS="literal"
->example.com</VAR
->)
+back in to the internal network.</p>
+<p>Here is an example of a split DNS setup:</p>
+<p>Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
+(<code class="literal">example.com</code>)
 has several corporate sites that have an internal network with reserved
 Internet Protocol (IP) space and an external demilitarized zone (DMZ),
-or "outside" section of a network, that is available to the public.</P
-><P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Example, Inc.</I
-></SPAN
-> wants its internal clients
+or "outside" section of a network, that is available to the public.</p>
+<p><span class="emphasis"><em>Example, Inc.</em></span> 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
->In order to accomplish this, the company will set up two sets
+at all outside of the internal network.</p>
+<p>In order to accomplish this, the company will set up two sets
 of name servers. One set will be on the inside network (in the reserved
 IP space) and the other set will be on bastion hosts, which are "proxy"
-hosts that can talk to both sides of its network, in the DMZ.</P
-><P
->The internal servers will be configured to forward all queries,
-except queries for <TT
-CLASS="filename"
->site1.internal</TT
->, <TT
-CLASS="filename"
->site2.internal</TT
->, <TT
-CLASS="filename"
->site1.example.com</TT
->,
-and <TT
-CLASS="filename"
->site2.example.com</TT
->, to the servers in the
+hosts that can talk to both sides of its network, in the DMZ.</p>
+<p>The internal servers will be configured to forward all queries,
+except queries for <code class="filename">site1.internal</code>, <code class="filename">site2.internal</code>, <code class="filename">site1.example.com</code>,
+and <code class="filename">site2.example.com</code>, to the servers in the
 DMZ. These internal servers will have complete sets of information
-for <TT
-CLASS="filename"
->site1.example.com</TT
->, <TT
-CLASS="filename"
->site2.example.com</TT
->,<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
-> </I
-></SPAN
-><TT
-CLASS="filename"
->site1.internal</TT
->,
-and <TT
-CLASS="filename"
->site2.internal</TT
->.</P
-><P
->To protect the <TT
-CLASS="filename"
->site1.internal</TT
-> and <TT
-CLASS="filename"
->site2.internal</TT
-> domains,
+for <code class="filename">site1.example.com</code>, <code class="filename">site2.example.com</code>,<span class="emphasis"><em> </em></span><code class="filename">site1.internal</code>,
+and <code class="filename">site2.internal</code>.</p>
+<p>To protect the <code class="filename">site1.internal</code> and <code class="filename">site2.internal</code> domains,
 the internal name servers must be configured to disallow all queries
 to these domains from any external hosts, including the bastion
-hosts.</P
-><P
->The external servers, which are on the bastion hosts, will
-be configured to serve the "public" version of the <TT
-CLASS="filename"
->site1</TT
-> and <TT
-CLASS="filename"
->site2.example.com</TT
-> zones.
+hosts.</p>
+<p>The external servers, which are on the bastion hosts, will
+be configured to serve the "public" version of the <code class="filename">site1</code> and <code class="filename">site2.example.com</code> zones.
 This could include things such as the host records for public servers
-(<TT
-CLASS="filename"
->www.example.com</TT
-> and <TT
-CLASS="filename"
->ftp.example.com</TT
->),
-and mail exchange (MX)  records (<TT
-CLASS="filename"
->a.mx.example.com</TT
-> and <TT
-CLASS="filename"
->b.mx.example.com</TT
->).</P
-><P
->In addition, the public <TT
-CLASS="filename"
->site1</TT
-> and <TT
-CLASS="filename"
->site2.example.com</TT
-> zones
+(<code class="filename">www.example.com</code> and <code class="filename">ftp.example.com</code>),
+and mail exchange (MX)  records (<code class="filename">a.mx.example.com</code> and <code class="filename">b.mx.example.com</code>).</p>
+<p>In addition, the public <code class="filename">site1</code> and <code class="filename">site2.example.com</code> 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
-><P
->Here's an example of a wildcard MX record:</P
-><PRE
-CLASS="programlisting"
-><VAR
-CLASS="literal"
->*   IN MX 10 external1.example.com.</VAR
-></PRE
-><P
->Now that they accept mail on behalf of anything in the internal
+internal hosts.</p>
+<p>Here's an example of a wildcard MX record:</p>
+<pre class="programlisting">*   IN MX 10 external1.example.com.</pre>
+<p>Now that they accept mail on behalf of anything in the internal
 network, the bastion hosts will need to know how to deliver mail
 to internal hosts. In order for this to work properly, the resolvers on
 the bastion hosts will need to be configured to point to the internal
-name servers for DNS resolution.</P
-><P
->Queries for internal hostnames will be answered by the internal
+name servers for DNS resolution.</p>
+<p>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
->In order for all this to work properly, internal clients will
-need to be configured to query <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->only</I
-></SPAN
-> the internal
+out to the DNS servers on the bastion hosts.</p>
+<p>In order for all this to work properly, internal clients will
+need to be configured to query <span class="emphasis"><em>only</em></span> the internal
 name servers for DNS queries. This could also be enforced via selective
-filtering on the network.</P
-><P
->If everything has been set properly, <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Example, Inc.</I
-></SPAN
->'s
-internal clients will now be able to:</P
-><P
-></P
-><UL
-><LI
-><P
->Look up any hostnames in the <VAR
-CLASS="literal"
->site1</VAR
-> and 
-<VAR
-CLASS="literal"
->site2.example.com</VAR
-> zones.</P
-></LI
-><LI
-><P
->Look up any hostnames in the <VAR
-CLASS="literal"
->site1.internal</VAR
-> and 
-<VAR
-CLASS="literal"
->site2.internal</VAR
-> domains.</P
-></LI
-><LI
-><P
->Look up any hostnames on the Internet.</P
-></LI
-><LI
-><P
->Exchange mail with internal AND external people.</P
-></LI
-></UL
-><P
->Hosts on the Internet will be able to:</P
-><P
-></P
-><UL
-><LI
-><P
->Look up any hostnames in the <VAR
-CLASS="literal"
->site1</VAR
-> and 
-<VAR
-CLASS="literal"
->site2.example.com</VAR
-> zones.</P
-></LI
-><LI
-><P
->Exchange mail with anyone in the <VAR
-CLASS="literal"
->site1</VAR
-> and 
-<VAR
-CLASS="literal"
->site2.example.com</VAR
-> zones.</P
-></LI
-></UL
-><P
->Here is an example configuration for the setup we just
+filtering on the network.</p>
+<p>If everything has been set properly, <span class="emphasis"><em>Example, Inc.</em></span>'s
+internal clients will now be able to:</p>
+<div class="itemizedlist"><ul type="disc">
+<li>Look up any hostnames in the <code class="literal">site1</code> and 
+<code class="literal">site2.example.com</code> zones.</li>
+<li>Look up any hostnames in the <code class="literal">site1.internal</code> and 
+<code class="literal">site2.internal</code> domains.</li>
+<li>Look up any hostnames on the Internet.</li>
+<li>Exchange mail with internal AND external people.</li>
+</ul></div>
+<p>Hosts on the Internet will be able to:</p>
+<div class="itemizedlist"><ul type="disc">
+<li>Look up any hostnames in the <code class="literal">site1</code> and 
+<code class="literal">site2.example.com</code> zones.</li>
+<li>Exchange mail with anyone in the <code class="literal">site1</code> and 
+<code class="literal">site2.example.com</code> zones.</li>
+</ul></div>
+<p>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.ch03.html#sample_configuration"
->Section 3.1</A
-></P
-><P
->Internal DNS server config:</P
-><PRE
-CLASS="programlisting"
->&#13;
+    for information on how to configure your zone files, see <a href="Bv9ARM.ch03.html#sample_configuration" title="Sample Configurations">the section called &#8220;Sample Configurations&#8221;</a></p>
+<p>Internal DNS server config:</p>
+<pre class="programlisting">
+
 acl internals { 172.16.72.0/24; 192.168.1.0/24; };
 
-acl externals { <VAR
-CLASS="varname"
->bastion-ips-go-here</VAR
->; };
+acl externals { <code class="varname">bastion-ips-go-here</code>; };
 
 options {
     ...
     ...
     forward only;
     forwarders {                                // forward to external servers
-        <VAR
-CLASS="varname"
->bastion-ips-go-here</VAR
->; 
+        <code class="varname">bastion-ips-go-here</code>; 
     };
     allow-transfer { none; };                   // sample allow-transfer (no one)
     allow-query { internals; externals; };      // restrict query access
@@ -655,12 +310,10 @@ zone "site2.internal" {
   allow-query { internals };
   allow-transfer { internals; }
 };
-</PRE
-><P
->External (bastion host) DNS server config:</P
-><PRE
-CLASS="programlisting"
->&#13;acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+</pre>
+<p>External (bastion host) DNS server config:</p>
+<pre class="programlisting">
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
 
 acl externals { bastion-ips-go-here; };
 
@@ -688,367 +341,147 @@ zone "site2.example.com" {
   allow-query { any; };
   allow-transfer { internals; externals; }
 };
-</PRE
-><P
->In the <TT
-CLASS="filename"
->resolv.conf</TT
-> (or equivalent) on
-the bastion host(s):</P
-><PRE
-CLASS="programlisting"
->&#13;search ...
+</pre>
+<p>In the <code class="filename">resolv.conf</code> (or equivalent) on
+the bastion host(s):</p>
+<pre class="programlisting">
+search ...
 nameserver 172.16.72.2
 nameserver 172.16.72.3
 nameserver 172.16.72.4
-</PRE
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="tsig"
->4.5. TSIG</A
-></H1
-><P
->This is a short guide to setting up Transaction SIGnatures
-(TSIG) based transaction security in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->. It describes changes
+</pre>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="tsig"></a>TSIG</h2></div></div></div>
+<p>This is a short guide to setting up Transaction SIGnatures
+(TSIG) based transaction security in <span class="acronym">BIND</span>. 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 <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->.</P
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> primarily supports TSIG for server to server communication.
+keys and using transaction signatures with <span class="acronym">BIND</span>.</p>
+<p><span class="acronym">BIND</span> primarily supports TSIG for server to server communication.
 This includes zone transfer, notify, and recursive query messages.
-Resolvers based on newer versions of <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 have limited support
-for TSIG.</P
-><P
->TSIG might be most useful for dynamic update. A primary
+Resolvers based on newer versions of <span class="acronym">BIND</span> 8 have limited support
+for TSIG.</p>
+<p>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.
     The cryptographic access control provided by TSIG
-    is far superior. The <B
-CLASS="command"
->nsupdate</B
->
-    program supports TSIG via the <VAR
-CLASS="option"
->-k</VAR
-> and
-    <VAR
-CLASS="option"
->-y</VAR
-> command line options.</P
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN858"
->4.5.1. Generate Shared Keys for Each Pair of Hosts</A
-></H2
-><P
->A shared secret is generated to be shared between <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host1</I
-></SPAN
-> and <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host2</I
-></SPAN
->.
+    is far superior. The <span><strong class="command">nsupdate</strong></span>
+    program supports TSIG via the <code class="option">-k</code> and
+    <code class="option">-y</code> command line options.</p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2549627"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
+<p>A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
 An arbitrary key name is chosen: "host1-host2.". The key name must
-be the same on both hosts.</P
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN863"
->4.5.1.1. Automatic Generation</A
-></H3
-><P
->The following command will generate a 128 bit (16 byte) HMAC-MD5
+be the same on both hosts.</p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2549643"></a>Automatic Generation</h4></div></div></div>
+<p>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
-><P
-><KBD
-CLASS="userinput"
->dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</KBD
-></P
-><P
->The key is in the file <TT
-CLASS="filename"
->Khost1-host2.+157+00000.private</TT
->.
+bit key.</p>
+<p><strong class="userinput"><code>dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.</code></strong></p>
+<p>The key is in the file <code class="filename">Khost1-host2.+157+00000.private</code>.
 Nothing directly uses this file, but the base-64 encoded string
-following "<VAR
-CLASS="literal"
->Key:</VAR
->"
-can be extracted from the file and used as a shared secret:</P
-><PRE
-CLASS="programlisting"
->Key: La/E5CjG9O+os1jq0a2jdA==</PRE
-><P
->The string "<VAR
-CLASS="literal"
->La/E5CjG9O+os1jq0a2jdA==</VAR
->" can
-be used as the shared secret.</P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN874"
->4.5.1.2. Manual Generation</A
-></H3
-><P
->The shared secret is simply a random sequence of bits, encoded
+following "<code class="literal">Key:</code>"
+can be extracted from the file and used as a shared secret:</p>
+<pre class="programlisting">Key: La/E5CjG9O+os1jq0a2jdA==</pre>
+<p>The string "<code class="literal">La/E5CjG9O+os1jq0a2jdA==</code>" can
+be used as the shared secret.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2549677"></a>Manual Generation</h4></div></div></div>
+<p>The shared secret is simply a random sequence of bits, encoded
 in base-64. Most ASCII strings are valid base-64 strings (assuming
 the length is a multiple of 4 and only valid characters are used),
-so the shared secret can be manually generated.</P
-><P
->Also, a known string can be run through <B
-CLASS="command"
->mmencode</B
-> or
-a similar program to generate base-64 encoded data.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN879"
->4.5.2. Copying the Shared Secret to Both Machines</A
-></H2
-><P
->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
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN882"
->4.5.3. Informing the Servers of the Key's Existence</A
-></H2
-><P
->Imagine <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host1</I
-></SPAN
-> and <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host 2</I
-></SPAN
-> are
-both servers. The following is added to each server's <TT
-CLASS="filename"
->named.conf</TT
-> file:</P
-><PRE
-CLASS="programlisting"
->&#13;key host1-host2. {
+so the shared secret can be manually generated.</p>
+<p>Also, a known string can be run through <span><strong class="command">mmencode</strong></span> or
+a similar program to generate base-64 encoded data.</p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2549830"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
+<p>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 class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2549838"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
+<p>Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span> are
+both servers. The following is added to each server's <code class="filename">named.conf</code> file:</p>
+<pre class="programlisting">
+key host1-host2. {
   algorithm hmac-md5;
   secret "La/E5CjG9O+os1jq0a2jdA==";
 };
-</PRE
-><P
->The algorithm, hmac-md5, is the only one supported by <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->.
+</pre>
+<p>The algorithm, hmac-md5, is the only one supported by <span class="acronym">BIND</span>.
 The secret is the one generated above. Since this is a secret, it
-is recommended that either <TT
-CLASS="filename"
->named.conf</TT
-> be non-world
+is recommended that either <code class="filename">named.conf</code> be non-world
 readable, or the key directive be added to a non-world readable
-file that is included by <TT
-CLASS="filename"
->named.conf</TT
->.</P
-><P
->At this point, the key is recognized. This means that if the
+file that is included by <code class="filename">named.conf</code>.</p>
+<p>At this point, the key is recognized. This means that if the
 server receives a message signed by this key, it can verify the
 signature. If the signature is successfully verified, the
-response is signed by the same key.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN894"
->4.5.4. Instructing the Server to Use the Key</A
-></H2
-><P
->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 <TT
-CLASS="filename"
->named.conf</TT
-> file
-for <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host1</I
-></SPAN
->, if the IP address of <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host2</I
-></SPAN
-> is
-10.1.2.3:</P
-><PRE
-CLASS="programlisting"
->&#13;server 10.1.2.3 {
+response is signed by the same key.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2549878"></a>Instructing the Server to Use the Key</h3></div></div></div>
+<p>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="filename">named.conf</code> file
+for <span class="emphasis"><em>host1</em></span>, if the IP address of <span class="emphasis"><em>host2</em></span> is
+10.1.2.3:</p>
+<pre class="programlisting">
+server 10.1.2.3 {
   keys { host1-host2. ;};
 };
-</PRE
-><P
->Multiple keys may be present, but only the first is used.
+</pre>
+<p>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
->If <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host1</I
-></SPAN
-> sends a message that is a request
-to that address, the message will be signed with the specified key. <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host1</I
-></SPAN
-> will
+file.</p>
+<p>If <span class="emphasis"><em>host1</em></span> sends a message that is a request
+to that address, the message will be signed with the specified key. <span class="emphasis"><em>host1</em></span> will
 expect any responses to signed messages to be signed with the same
-key.</P
-><P
->A similar statement must be present in <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host2</I
-></SPAN
->'s
-configuration file (with <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host1</I
-></SPAN
->'s address) for <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host2</I
-></SPAN
-> to
-sign request messages to <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->host1</I
-></SPAN
->.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN910"
->4.5.5. TSIG Key Based Access Control</A
-></H2
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> allows IP addresses and ranges to be specified in ACL
+key.</p>
+<p>A similar statement must be present in <span class="emphasis"><em>host2</em></span>'s
+configuration file (with <span class="emphasis"><em>host1</em></span>'s address) for <span class="emphasis"><em>host2</em></span> to
+sign request messages to <span class="emphasis"><em>host1</em></span>.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2549998"></a>TSIG Key Based Access Control</h3></div></div></div>
+<p><span class="acronym">BIND</span> allows IP addresses and ranges to be specified in ACL
 definitions and
-<B
-CLASS="command"
->allow-{ query | transfer | update }</B
-> directives.
+<span><strong class="command">allow-{ query | transfer | update }</strong></span> directives.
 This has been extended to allow TSIG keys also. The above key would
-be denoted <B
-CLASS="command"
->key host1-host2.</B
-></P
-><P
->An example of an allow-update directive would be:</P
-><PRE
-CLASS="programlisting"
->&#13;allow-update { key host1-host2. ;};
-</PRE
-><P
->This allows dynamic updates to succeed only if the request
+be denoted <span><strong class="command">key host1-host2.</strong></span></p>
+<p>An example of an allow-update directive would be:</p>
+<pre class="programlisting">
+allow-update { key host1-host2. ;};
+</pre>
+<p>This allows dynamic updates to succeed only if the request
       was signed by a key named
-      "<B
-CLASS="command"
->host1-host2.</B
->".</P
-><P
->You may want to read about the more
-      powerful <B
-CLASS="command"
->update-policy</B
-> statement in <A
-HREF="Bv9ARM.ch06.html#dynamic_update_policies"
->Section 6.2.24.4</A
->.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN923"
->4.5.6. Errors</A
-></H2
-><P
->The processing of TSIG signed messages can result in
+      "<span><strong class="command">host1-host2.</strong></span>".</p>
+<p>You may want to read about the more
+      powerful <span><strong class="command">update-policy</strong></span> statement in <a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2550042"></a>Errors</h3></div></div></div>
+<p>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
->If a TSIG aware server receives a message signed by an
+      signed message to a specific server.</p>
+<p>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
@@ -1058,545 +491,226 @@ NAME="AEN923"
       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
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN927"
->4.6. TKEY</A
-></H1
-><P
-><B
-CLASS="command"
->TKEY</B
-> is a mechanism for automatically
+      NOTAUTH.</p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2550056"></a>TKEY</h2></div></div></div>
+<p><span><strong class="command">TKEY</strong></span> is a mechanism for automatically
     generating a shared secret between two hosts.  There are several
-    "modes" of <B
-CLASS="command"
->TKEY</B
-> that specify how the key is
-    generated or assigned.  <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9
+    "modes" of <span><strong class="command">TKEY</strong></span> that specify how the key is
+    generated or assigned.  <span class="acronym">BIND</span> 9
     implements only one of these modes,
     the Diffie-Hellman key exchange.  Both hosts are required to have
     a Diffie-Hellman KEY record (although this record is not required
-    to be present in a zone).  The <B
-CLASS="command"
->TKEY</B
-> process
+    to be present in a zone).  The <span><strong class="command">TKEY</strong></span> process
     must use signed messages, signed either by TSIG or SIG(0).  The
-    result of <B
-CLASS="command"
->TKEY</B
-> is a shared secret that can be
-    used to sign messages with TSIG.  <B
-CLASS="command"
->TKEY</B
-> can also
+    result of <span><strong class="command">TKEY</strong></span> is a shared secret that can be
+    used to sign messages with TSIG.  <span><strong class="command">TKEY</strong></span> can also
     be used to delete shared secrets that it had previously
-    generated.</P
-><P
->The <B
-CLASS="command"
->TKEY</B
-> process is initiated by a client
-    or server by sending a signed <B
-CLASS="command"
->TKEY</B
-> query
+    generated.</p>
+<p>The <span><strong class="command">TKEY</strong></span> process is initiated by a client
+    or server by sending a signed <span><strong class="command">TKEY</strong></span> query
     (including any appropriate KEYs) to a TKEY-aware server.  The
     server response, if it indicates success, will contain a
-    <B
-CLASS="command"
->TKEY</B
-> record and any appropriate keys.  After
+    <span><strong class="command">TKEY</strong></span> record and any appropriate keys.  After
     this exchange, both participants have enough information to
     determine the shared secret; the exact process depends on the
-    <B
-CLASS="command"
->TKEY</B
-> mode.  When using the Diffie-Hellman
-    <B
-CLASS="command"
->TKEY</B
-> mode, Diffie-Hellman keys are exchanged,
-    and the shared secret is derived by both participants.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN942"
->4.7. SIG(0)</A
-></H1
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 partially supports DNSSEC SIG(0)
+    <span><strong class="command">TKEY</strong></span> mode.  When using the Diffie-Hellman
+    <span><strong class="command">TKEY</strong></span> mode, Diffie-Hellman keys are exchanged,
+    and the shared secret is derived by both participants.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2550173"></a>SIG(0)</h2></div></div></div>
+<p><span class="acronym">BIND</span> 9 partially supports DNSSEC SIG(0)
     transaction signatures as specified in RFC 2535 and RFC2931.  SIG(0)
     uses public/private keys to authenticate messages.  Access control
     is performed in the same manner as TSIG keys; privileges can be
-    granted or denied based on the key name.</P
-><P
->When a SIG(0) signed message is received, it will only be
+    granted or denied based on the key name.</p>
+<p>When a SIG(0) signed message is received, it will only be
     verified if the key is known and trusted by the server; the server
-    will not attempt to locate and/or validate the key.</P
-><P
->SIG(0) signing of multiple-message TCP streams is not
-    supported.</P
-><P
->The only tool shipped with <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 that
-    generates SIG(0) signed messages is <B
-CLASS="command"
->nsupdate</B
->.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="DNSSEC"
->4.8. DNSSEC</A
-></H1
-><P
->Cryptographic authentication of DNS information is possible
-    through the DNS Security (<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->DNSSEC-bis</I
-></SPAN
->) extensions,
-    defined in RFC &#60;TBA&#62;. This section describes the creation and use
-    of DNSSEC signed zones.</P
-><P
->In order to set up a DNSSEC secure zone, there are a series
-    of steps which must be followed.  <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 ships
+    will not attempt to locate and/or validate the key.</p>
+<p>SIG(0) signing of multiple-message TCP streams is not
+    supported.</p>
+<p>The only tool shipped with <span class="acronym">BIND</span> 9 that
+    generates SIG(0) signed messages is <span><strong class="command">nsupdate</strong></span>.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="DNSSEC"></a>DNSSEC</h2></div></div></div>
+<p>Cryptographic authentication of DNS information is possible
+    through the DNS Security (<span class="emphasis"><em>DNSSEC-bis</em></span>) extensions,
+    defined in RFC &lt;TBA&gt;. This section describes the creation and use
+    of DNSSEC signed zones.</p>
+<p>In order to set up a DNSSEC secure zone, there are a series
+    of steps which must be followed.  <span class="acronym">BIND</span> 9 ships
     with several tools
     that are used in this process, which are explained in more detail
-    below.  In all cases, the <VAR
-CLASS="option"
->-h</VAR
-> option prints a
+    below.  In all cases, the <code class="option">-h</code> option prints a
     full list of parameters.  Note that the DNSSEC tools require the
     keyset files to be in the working directory or the
-    directory specified by the <VAR
-CLASS="option"
->-h</VAR
-> option, and
+    directory specified by the <code class="option">-h</code> option, and
     that the tools shipped with BIND 9.2.x and earlier are not compatible
-    with the current ones.</P
-><P
->There must also be communication with the administrators of
+    with the current ones.</p>
+<p>There must also be communication with the administrators of
     the parent and/or child zone to transmit keys.  A zone's security
     status must be indicated by the parent zone for a DNSSEC capable 
     resolver to trust its data.  This is done through the presense
-    or absence of a <VAR
-CLASS="literal"
->DS</VAR
-> record at the delegation
-    point.</P
-><P
->For other servers to trust data in this zone, they must
+    or absence of a <code class="literal">DS</code> record at the delegation
+    point.</p>
+<p>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
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN962"
->4.8.1. Generating Keys</A
-></H2
-><P
->The <B
-CLASS="command"
->dnssec-keygen</B
-> program is used to
-      generate keys.</P
-><P
->A secure zone must contain one or more zone keys.  The
+    zone key of another zone above this one in the DNS tree.</p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2550308"></a>Generating Keys</h3></div></div></div>
+<p>The <span><strong class="command">dnssec-keygen</strong></span> program is used to
+      generate keys.</p>
+<p>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
-      <B
-CLASS="command"
->ZONE</B
->, and must be usable for authentication.
+      <span><strong class="command">ZONE</strong></span>, and must be usable for authentication.
       It is recommended that zone keys use a cryptographic algorithm
       designated as "mandatory to implement" by the IETF; currently
-      the only one is RSASHA1.</P
-><P
->The following command will generate a 768 bit RSASHA1 key for
-      the <TT
-CLASS="filename"
->child.example</TT
-> zone:</P
-><P
-><KBD
-CLASS="userinput"
->dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</KBD
-></P
-><P
->Two output files will be produced:
-      <TT
-CLASS="filename"
->Kchild.example.+005+12345.key</TT
-> and
-      <TT
-CLASS="filename"
->Kchild.example.+005+12345.private</TT
-> (where
+      the only one is RSASHA1.</p>
+<p>The following command will generate a 768 bit RSASHA1 key for
+      the <code class="filename">child.example</code> zone:</p>
+<p><strong class="userinput"><code>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</code></strong></p>
+<p>Two output files will be produced:
+      <code class="filename">Kchild.example.+005+12345.key</code> and
+      <code class="filename">Kchild.example.+005+12345.private</code> (where
       12345 is an example of a key tag).  The key file names contain
-      the key name (<TT
-CLASS="filename"
->child.example.</TT
->), algorithm (3
+      the key name (<code class="filename">child.example.</code>), algorithm (3
       is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case).
-      The private key (in the <TT
-CLASS="filename"
->.private</TT
-> file) is
+      The private key (in the <code class="filename">.private</code> file) is
       used to generate signatures, and the public key (in the
-      <TT
-CLASS="filename"
->.key</TT
-> file) is used for signature
-      verification.</P
-><P
->To generate another key with the same properties (but with
-      a different key tag), repeat the above command.</P
-><P
->The public keys should be inserted into the zone file by
-      including the <TT
-CLASS="filename"
->.key</TT
-> files using
-      <B
-CLASS="command"
->$INCLUDE</B
-> statements.
-      </P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN982"
->4.8.2. Signing the Zone</A
-></H2
-><P
->The <B
-CLASS="command"
->dnssec-signzone</B
-> program is used to
-      sign a zone.</P
-><P
->Any <TT
-CLASS="filename"
->keyset</TT
-> files corresponding
+      <code class="filename">.key</code> file) is used for signature
+      verification.</p>
+<p>To generate another key with the same properties (but with
+      a different key tag), repeat the above command.</p>
+<p>The public keys should be inserted into the zone file by
+      including the <code class="filename">.key</code> files using
+      <span><strong class="command">$INCLUDE</strong></span> statements.
+      </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2550375"></a>Signing the Zone</h3></div></div></div>
+<p>The <span><strong class="command">dnssec-signzone</strong></span> program is used to
+      sign a zone.</p>
+<p>Any <code class="filename">keyset</code> files corresponding
       to secure subzones should be present.  The zone signer will
-      generate <VAR
-CLASS="literal"
->NSEC</VAR
-> and <VAR
-CLASS="literal"
->RRSIG</VAR
->
-      records for the zone, as well as <VAR
-CLASS="literal"
->DS</VAR
-> for
-      the child zones if <VAR
-CLASS="literal"
->'-d'</VAR
-> is specified.
-      If <VAR
-CLASS="literal"
->'-d'</VAR
-> is not specified then DS RRsets for
-      the secure child zones need to be added manually.</P
-><P
->The following command signs the zone, assuming it is in a
-      file called <TT
-CLASS="filename"
->zone.child.example</TT
->.  By
+      generate <code class="literal">NSEC</code> and <code class="literal">RRSIG</code>
+      records for the zone, as well as <code class="literal">DS</code> for
+      the child zones if <code class="literal">'-d'</code> is specified.
+      If <code class="literal">'-d'</code> is not specified then DS RRsets for
+      the secure child zones need to be added manually.</p>
+<p>The following command signs the zone, assuming it is in a
+      file called <code class="filename">zone.child.example</code>.  By
       default, all zone keys which have an available private key are
-      used to generate signatures.</P
-><P
-><KBD
-CLASS="userinput"
->dnssec-signzone -o child.example zone.child.example</KBD
-></P
-><P
->One output file is produced:
-      <TT
-CLASS="filename"
->zone.child.example.signed</TT
->.  This file
-      should be referenced by <TT
-CLASS="filename"
->named.conf</TT
-> as the
-      input file for the zone.</P
-><P
-><B
-CLASS="command"
->dnssec-signzone</B
-> will also produce a
+      used to generate signatures.</p>
+<p><strong class="userinput"><code>dnssec-signzone -o child.example zone.child.example</code></strong></p>
+<p>One output file is produced:
+      <code class="filename">zone.child.example.signed</code>.  This file
+      should be referenced by <code class="filename">named.conf</code> as the
+      input file for the zone.</p>
+<p><span><strong class="command">dnssec-signzone</strong></span> will also produce a
       keyset and dsset files and optionally a dlvset file.  These
       are used to provide the parent zone administators with the
-      <VAR
-CLASS="literal"
->DNSKEYs</VAR
-> (or their corresponding <VAR
-CLASS="literal"
->DS</VAR
->
-      records) that are the secure entry point to the zone.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1004"
->4.8.3. Configuring Servers</A
-></H2
-><P
->Unlike <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8, 
-<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 does not verify signatures on load,
+      <code class="literal">DNSKEYs</code> (or their corresponding <code class="literal">DS</code>
+      records) that are the secure entry point to the zone.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2550450"></a>Configuring Servers</h3></div></div></div>
+<p>Unlike <span class="acronym">BIND</span> 8, 
+<span class="acronym">BIND</span> 9 does not verify signatures on load,
 so zone keys for authoritative zones do not need to be specified
-in the configuration file.</P
-><P
->The public key for any security root must be present in
-the configuration file's <B
-CLASS="command"
->trusted-keys</B
->
-statement, as described later in this document. </P
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN1011"
->4.9. IPv6 Support in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9</A
-></H1
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 fully supports all currently defined forms of IPv6
+in the configuration file.</p>
+<p>The public key for any security root must be present in
+the configuration file's <span><strong class="command">trusted-keys</strong></span>
+statement, as described later in this document. </p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2550473"></a>IPv6 Support in <span class="acronym">BIND</span> 9</h2></div></div></div>
+<p><span class="acronym">BIND</span> 9 fully supports all currently defined forms of IPv6
     name to address and address to name lookups.  It will also use
     IPv6 addresses to make queries when running on an IPv6 capable
-    system.</P
-><P
->For forward lookups, <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 supports only AAAA
+    system.</p>
+<p>For forward lookups, <span class="acronym">BIND</span> 9 supports only AAAA
     records.  The use of A6 records is deprecated by RFC 3363, and the
-    support for forward lookups in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 is
+    support for forward lookups in <span class="acronym">BIND</span> 9 is
     removed accordingly.
-    However, authoritative <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 name servers still
+    However, authoritative <span class="acronym">BIND</span> 9 name servers still
     load zone files containing A6 records correctly, answer queries
     for A6 records, and accept zone transfer for a zone containing A6
-    records.</P
-><P
->For IPv6 reverse lookups, <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 supports
+    records.</p>
+<p>For IPv6 reverse lookups, <span class="acronym">BIND</span> 9 supports
     the traditional "nibble" format used in the
-    <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->ip6.arpa</I
-></SPAN
-> domain, as well as the older, deprecated
-    <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->ip6.int</I
-></SPAN
-> domain.
-    <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 formerly
+    <span class="emphasis"><em>ip6.arpa</em></span> domain, as well as the older, deprecated
+    <span class="emphasis"><em>ip6.int</em></span> domain.
+    <span class="acronym">BIND</span> 9 formerly
     supported the "binary label" (also known as "bitstring") format.
     The support of binary labels, however, is now completely removed
     according to the changes in RFC 3363.
-    Any applications in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 do not understand
+    Any applications in <span class="acronym">BIND</span> 9 do not understand
     the format any more, and will return an error if given.
-    In particular, an authoritative <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 name
-    server rejects to load a zone file containing binary labels.</P
-><P
->For an overview of the format and structure of IPv6 addresses,
-    see <A
-HREF="Bv9ARM.ch09.html#ipv6addresses"
->Section A.2.1</A
->.</P
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1029"
->4.9.1. Address Lookups Using AAAA Records</A
-></H2
-><P
->The AAAA record is a parallel to the IPv4 A record.  It
+    In particular, an authoritative <span class="acronym">BIND</span> 9 name
+    server rejects to load a zone file containing binary labels.</p>
+<p>For an overview of the format and structure of IPv6 addresses,
+    see <a href="Bv9ARM.ch09.html#ipv6addresses" title="IPv6 addresses (AAAA)">the section called &#8220;IPv6 addresses (AAAA)&#8221;</a>.</p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2550600"></a>Address Lookups Using AAAA Records</h3></div></div></div>
+<p>The AAAA record is a parallel to the IPv4 A record.  It
       specifies the entire address in a single record.  For
-      example,</P
-><PRE
-CLASS="programlisting"
->&#13;$ORIGIN example.com.
+      example,</p>
+<pre class="programlisting">
+$ORIGIN example.com.
 host            3600    IN      AAAA    2001:db8::1
-</PRE
-><P
->It is recommended that IPv4-in-IPv6 mapped addresses not
+</pre>
+<p>It is recommended that IPv4-in-IPv6 mapped addresses not
         be used.  If a host has an IPv4 address, use an A record, not
-        a AAAA, with <VAR
-CLASS="literal"
->::ffff:192.168.42.1</VAR
-> as the
-        address.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1035"
->4.9.2. Address to Name Lookups Using Nibble Format</A
-></H2
-><P
->When looking up an address in nibble format, the address
+        a AAAA, with <code class="literal">::ffff:192.168.42.1</code> as the
+        address.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2550620"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
+<p>When looking up an address in nibble format, the address
       components are simply reversed, just as in IPv4, and
-      <VAR
-CLASS="literal"
->ip6.arpa.</VAR
-> is appended to the resulting name.
+      <code class="literal">ip6.arpa.</code> is appended to the resulting name.
       For example, the following would provide reverse name lookup for
       a host with address
-      <VAR
-CLASS="literal"
->2001:db8::1</VAR
->.</P
-><PRE
-CLASS="programlisting"
->&#13;$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
+      <code class="literal">2001:db8::1</code>.</p>
+<pre class="programlisting">
+$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
-</PRE
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch03.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch05.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Name Server Configuration</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->The <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Lightweight Resolver</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+</pre>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch03.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch05.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 3. Name Server Configuration </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch05.html b/contrib/bind9/doc/arm/Bv9ARM.ch05.html
index dd59488d9383..1720660b65ab 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch05.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch05.html
@@ -1,265 +1,115 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->The BIND 9 Lightweight Resolver</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="Advanced DNS Features"
-HREF="Bv9ARM.ch04.html"><LINK
-REL="NEXT"
-TITLE="BIND 9 Configuration Reference"
-HREF="Bv9ARM.ch06.html"></HEAD
-><BODY
-CLASS="chapter"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch04.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch06.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="chapter"
-><H1
-><A
-NAME="ch05"
-></A
->Chapter 5. The <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Lightweight Resolver</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->5.1. <A
-HREF="Bv9ARM.ch05.html#AEN1044"
->The Lightweight Resolver Library</A
-></DT
-><DT
->5.2. <A
-HREF="Bv9ARM.ch05.html#lwresd"
->Running a Resolver Daemon</A
-></DT
-></DL
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN1044"
->5.1. The Lightweight Resolver Library</A
-></H1
-><P
->Traditionally applications have been linked with a stub resolver
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch05.html,v 1.24.2.5.2.12 2005/10/13 02:34:00 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 5. The BIND 9 Lightweight Resolver</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch04.html" title="Chapter 4. Advanced DNS Features">
+<link rel="next" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch05"></a>Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2550652">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2550652"></a>The Lightweight Resolver Library</h2></div></div></div>
+<p>Traditionally applications have been linked with a stub resolver
 library that sends recursive DNS queries to a local caching name
-server.</P
-><P
->IPv6 once introduced new complexity into the resolution process,
+server.</p>
+<p>IPv6 once introduced new complexity into the resolution process,
 such as following A6 chains and DNAME records, and simultaneous
 lookup of IPv4 and IPv6 addresses.  Though most of the complexity was
 then removed, these are hard or impossible
-to implement in a traditional stub resolver.</P
-><P
->Instead, <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 provides resolution services to local clients
+to implement in a traditional stub resolver.</p>
+<p>Instead, <span class="acronym">BIND</span> 9 provides resolution services to local clients
 using a combination of a lightweight resolver library and a resolver
 daemon process running on the local host.  These communicate using
 a simple UDP-based protocol, the "lightweight resolver protocol"
-that is distinct from and simpler than the full DNS protocol.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="lwresd"
->5.2. Running a Resolver Daemon</A
-></H1
-><P
->To use the lightweight resolver interface, the system must
-run the resolver daemon <B
-CLASS="command"
->lwresd</B
-> or a local
-name server configured with a <B
-CLASS="command"
->lwres</B
-> statement.</P
-><P
->By default, applications using the lightweight resolver library will make
+that is distinct from and simpler than the full DNS protocol.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="lwresd"></a>Running a Resolver Daemon</h2></div></div></div>
+<p>To use the lightweight resolver interface, the system must
+run the resolver daemon <span><strong class="command">lwresd</strong></span> or a local
+name server configured with a <span><strong class="command">lwres</strong></span> statement.</p>
+<p>By default, applications using the lightweight resolver library will make
 UDP requests to the IPv4 loopback address (127.0.0.1) on port 921.  The
-address can be overridden by <B
-CLASS="command"
->lwserver</B
-> lines in
-<TT
-CLASS="filename"
->/etc/resolv.conf</TT
->.</P
-><P
->The daemon currently only looks in the DNS, but in the future
-it may use other sources such as <TT
-CLASS="filename"
->/etc/hosts</TT
->,
-NIS, etc.</P
-><P
->The <B
-CLASS="command"
->lwresd</B
-> daemon is essentially a
+address can be overridden by <span><strong class="command">lwserver</strong></span> lines in
+<code class="filename">/etc/resolv.conf</code>.</p>
+<p>The daemon currently only looks in the DNS, but in the future
+it may use other sources such as <code class="filename">/etc/hosts</code>,
+NIS, etc.</p>
+<p>The <span><strong class="command">lwresd</strong></span> daemon is essentially a
 caching-only name server that responds to requests using the lightweight
 resolver protocol rather than the DNS protocol.  Because it needs
 to run on each host, it is designed to require no or minimal configuration.
 Unless configured otherwise, it uses the name servers listed on
-<B
-CLASS="command"
->nameserver</B
-> lines in <TT
-CLASS="filename"
->/etc/resolv.conf</TT
->
+<span><strong class="command">nameserver</strong></span> lines in <code class="filename">/etc/resolv.conf</code>
 as forwarders, but is also capable of doing the resolution autonomously if
-none are specified.</P
-><P
->The <B
-CLASS="command"
->lwresd</B
-> daemon may also be configured with a
-<TT
-CLASS="filename"
->named.conf</TT
-> style configuration file, in
-<TT
-CLASS="filename"
->/etc/lwresd.conf</TT
-> by default.  A name server may also
+none are specified.</p>
+<p>The <span><strong class="command">lwresd</strong></span> daemon may also be configured with a
+<code class="filename">named.conf</code> style configuration file, in
+<code class="filename">/etc/lwresd.conf</code> by default.  A name server may also
 be configured to act as a lightweight resolver daemon using the
-<B
-CLASS="command"
->lwres</B
-> statement in <TT
-CLASS="filename"
->named.conf</TT
->.</P
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch04.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch06.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Advanced DNS Features</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Configuration Reference</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+<span><strong class="command">lwres</strong></span> statement in <code class="filename">named.conf</code>.</p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch04.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch06.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 4. Advanced DNS Features </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch06.html b/contrib/bind9/doc/arm/Bv9ARM.ch06.html
index 8cd4c7022db0..4b5300069d1c 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch06.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch06.html
@@ -1,286 +1,148 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->BIND 9 Configuration Reference</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="The BIND 9 Lightweight Resolver"
-HREF="Bv9ARM.ch05.html"><LINK
-REL="NEXT"
-TITLE="BIND 9 Security Considerations"
-HREF="Bv9ARM.ch07.html"></HEAD
-><BODY
-CLASS="chapter"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch05.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch07.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="chapter"
-><H1
-><A
-NAME="ch06"
-></A
->Chapter 6. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Configuration Reference</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->6.1. <A
-HREF="Bv9ARM.ch06.html#configuration_file_elements"
->Configuration File Elements</A
-></DT
-><DT
->6.2. <A
-HREF="Bv9ARM.ch06.html#Configuration_File_Grammar"
->Configuration File Grammar</A
-></DT
-><DT
->6.3. <A
-HREF="Bv9ARM.ch06.html#AEN4050"
->Zone File</A
-></DT
-></DL
-></DIV
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 configuration is broadly similar
-to <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8; however, there are a few new areas
-of configuration, such as views. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->
-8 configuration files should work with few alterations in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch06.html,v 1.56.2.12.2.30 2005/10/13 02:34:00 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 6. BIND 9 Configuration Reference</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch05.html" title="Chapter 5. The BIND 9 Lightweight Resolver">
+<link rel="next" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch06"></a>Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2551817">Comment Syntax</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552302"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
+Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552471"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552808"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552823"><span><strong class="command">include</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552845"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552867"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553006"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553269"><span><strong class="command">logging</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554474"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554547"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554610"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554653"><span><strong class="command">masters</strong></span> Statement Definition and Usage </a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554668"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562233"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562281"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562349"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
+Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2563022"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2564557">Zone File</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2565990">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566487">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566593">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566761"><span class="acronym">BIND</span> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<p><span class="acronym">BIND</span> 9 configuration is broadly similar
+to <span class="acronym">BIND</span> 8; however, there are a few new areas
+of configuration, such as views. <span class="acronym">BIND</span>
+8 configuration files should work with few alterations in <span class="acronym">BIND</span>
 9, although more complex configurations should be reviewed to check
 if they can be more efficiently implemented using the new features
-found in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9.</P
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 4 configuration files can be converted to the new format
+found in <span class="acronym">BIND</span> 9.</p>
+<p><span class="acronym">BIND</span> 4 configuration files can be converted to the new format
 using the shell script
-<TT
-CLASS="filename"
->contrib/named-bootconf/named-bootconf.sh</TT
->.</P
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="configuration_file_elements"
->6.1. Configuration File Elements</A
-></H1
-><P
->Following is a list of elements used throughout the <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> configuration
-file documentation:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN1086"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->acl_name</VAR
-></P
-></TD
-><TD
-><P
->The name of an <VAR
-CLASS="varname"
->address_match_list</VAR
-> as
-defined by the <B
-CLASS="command"
->acl</B
-> statement.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->address_match_list</VAR
-></P
-></TD
-><TD
-><P
->A list of one or more <VAR
-CLASS="varname"
->ip_addr</VAR
->, 
-<VAR
-CLASS="varname"
->ip_prefix</VAR
->, <VAR
-CLASS="varname"
->key_id</VAR
->, 
-or <VAR
-CLASS="varname"
->acl_name</VAR
-> elements, see
-<A
-HREF="Bv9ARM.ch06.html#address_match_lists"
->Section 6.1.1</A
->.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->domain_name</VAR
-></P
-></TD
-><TD
-><P
->A quoted string which will be used as
-a DNS name, for example "<VAR
-CLASS="literal"
->my.test.domain</VAR
->".</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->dotted_decimal</VAR
-></P
-></TD
-><TD
-><P
->One to four integers valued 0 through
-255 separated by dots (`.'), such as <B
-CLASS="command"
->123</B
->, 
-<B
-CLASS="command"
->45.67</B
-> or <B
-CLASS="command"
->89.123.45.67</B
->.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->ip4_addr</VAR
-></P
-></TD
-><TD
-><P
->An IPv4 address with exactly four elements
-in <VAR
-CLASS="varname"
->dotted_decimal</VAR
-> notation.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->ip6_addr</VAR
-></P
-></TD
-><TD
-><P
->An IPv6 address, such as <B
-CLASS="command"
->2001:db8::1234</B
->.
+<code class="filename">contrib/named-bootconf/named-bootconf.sh</code>.</p>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="configuration_file_elements"></a>Configuration File Elements</h2></div></div></div>
+<p>Following is a list of elements used throughout the <span class="acronym">BIND</span> configuration
+file documentation:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><code class="varname">acl_name</code></p></td>
+<td><p>The name of an <code class="varname">address_match_list</code> as
+defined by the <span><strong class="command">acl</strong></span> statement.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">address_match_list</code></p></td>
+<td><p>A list of one or more <code class="varname">ip_addr</code>, 
+<code class="varname">ip_prefix</code>, <code class="varname">key_id</code>, 
+or <code class="varname">acl_name</code> elements, see
+<a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called &#8220;Address Match Lists&#8221;</a>.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">domain_name</code></p></td>
+<td><p>A quoted string which will be used as
+a DNS name, for example "<code class="literal">my.test.domain</code>".</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">dotted_decimal</code></p></td>
+<td><p>One to four integers valued 0 through
+255 separated by dots (`.'), such as <span><strong class="command">123</strong></span>, 
+<span><strong class="command">45.67</strong></span> or <span><strong class="command">89.123.45.67</strong></span>.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">ip4_addr</code></p></td>
+<td><p>An IPv4 address with exactly four elements
+in <code class="varname">dotted_decimal</code> notation.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">ip6_addr</code></p></td>
+<td><p>An IPv6 address, such as <span><strong class="command">2001:db8::1234</strong></span>.
 IPv6 scoped addresses that have ambiguity on their scope zones must be
 disambiguated by an appropriate zone ID with the percent character
 (`%') as delimiter.
@@ -290,2043 +152,677 @@ configuration changes.
 However, since there is no standard mapping for such names and
 identifier values, currently only interface names as link identifiers
 are supported, assuming one-to-one mapping between interfaces and links.
-For example, a link-local address <B
-CLASS="command"
->fe80::1</B
-> on the
-link attached to the interface <B
-CLASS="command"
->ne0</B
->
-can be specified as <B
-CLASS="command"
->fe80::1%ne0</B
->.
+For example, a link-local address <span><strong class="command">fe80::1</strong></span> on the
+link attached to the interface <span><strong class="command">ne0</strong></span>
+can be specified as <span><strong class="command">fe80::1%ne0</strong></span>.
 Note that on most systems link-local addresses always have the
-ambiguity, and need to be disambiguated.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->ip_addr</VAR
-></P
-></TD
-><TD
-><P
->An <VAR
-CLASS="varname"
->ip4_addr</VAR
-> or <VAR
-CLASS="varname"
->ip6_addr</VAR
->.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->ip_port</VAR
-></P
-></TD
-><TD
-><P
->An IP port <VAR
-CLASS="varname"
->number</VAR
->.
-<VAR
-CLASS="varname"
->number</VAR
-> is limited to 0 through 65535, with values
+ambiguity, and need to be disambiguated.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">ip_addr</code></p></td>
+<td><p>An <code class="varname">ip4_addr</code> or <code class="varname">ip6_addr</code>.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">ip_port</code></p></td>
+<td><p>An IP port <code class="varname">number</code>.
+<code class="varname">number</code> is limited to 0 through 65535, with values
 below 1024 typically restricted to use by processes running as root.
 In some cases an asterisk (`*') character can be used as a placeholder to
-select a random high-numbered port.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->ip_prefix</VAR
-></P
-></TD
-><TD
-><P
->An IP network specified as an <VAR
-CLASS="varname"
->ip_addr</VAR
->,
+select a random high-numbered port.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">ip_prefix</code></p></td>
+<td><p>An IP network specified as an <code class="varname">ip_addr</code>,
 followed by a slash (`/') and then the number of bits in the netmask.
-Trailing zeros in a <VAR
-CLASS="varname"
->ip_addr</VAR
-> may omitted.
-For example, <B
-CLASS="command"
->127/8</B
-> is the network <B
-CLASS="command"
->127.0.0.0</B
-> with
-netmask <B
-CLASS="command"
->255.0.0.0</B
-> and <B
-CLASS="command"
->1.2.3.0/28</B
-> is
-network <B
-CLASS="command"
->1.2.3.0</B
-> with netmask <B
-CLASS="command"
->255.255.255.240</B
->.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->key_id</VAR
-></P
-></TD
-><TD
-><P
->A <VAR
-CLASS="varname"
->domain_name</VAR
-> representing
-the name of a shared key, to be used for transaction security.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->key_list</VAR
-></P
-></TD
-><TD
-><P
->A list of one or more <VAR
-CLASS="varname"
->key_id</VAR
->s,
-separated by semicolons and ending with a semicolon.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->number</VAR
-></P
-></TD
-><TD
-><P
->A non-negative 32 bit integer
+Trailing zeros in a <code class="varname">ip_addr</code> may omitted.
+For example, <span><strong class="command">127/8</strong></span> is the network <span><strong class="command">127.0.0.0</strong></span> with
+netmask <span><strong class="command">255.0.0.0</strong></span> and <span><strong class="command">1.2.3.0/28</strong></span> is
+network <span><strong class="command">1.2.3.0</strong></span> with netmask <span><strong class="command">255.255.255.240</strong></span>.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">key_id</code></p></td>
+<td><p>A <code class="varname">domain_name</code> representing
+the name of a shared key, to be used for transaction security.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">key_list</code></p></td>
+<td><p>A list of one or more <code class="varname">key_id</code>s,
+separated by semicolons and ending with a semicolon.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">number</code></p></td>
+<td><p>A non-negative 32 bit integer
 (i.e., a number between 0 and 4294967295, inclusive).
 Its acceptable value might further
-be limited by the context in which it is used.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->path_name</VAR
-></P
-></TD
-><TD
-><P
->A quoted string which will be used as
-a pathname, such as <TT
-CLASS="filename"
->zones/master/my.test.domain</TT
->.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->size_spec</VAR
-></P
-></TD
-><TD
-><P
->A number, the word <KBD
-CLASS="userinput"
->unlimited</KBD
->,
-or the word <KBD
-CLASS="userinput"
->default</KBD
->.</P
-><P
->&#13;An <VAR
-CLASS="varname"
->unlimited</VAR
-> <VAR
-CLASS="varname"
->size_spec</VAR
-> requests unlimited
-use, or the maximum available amount. A <VAR
-CLASS="varname"
->default size_spec</VAR
-> uses
-the limit that was in force when the server was started.</P
-><P
->A <VAR
-CLASS="varname"
->number</VAR
-> can
-optionally be followed by a scaling factor: <KBD
-CLASS="userinput"
->K</KBD
-> or <KBD
-CLASS="userinput"
->k</KBD
-> for
-kilobytes, <KBD
-CLASS="userinput"
->M</KBD
-> or <KBD
-CLASS="userinput"
->m</KBD
-> for
-megabytes, and <KBD
-CLASS="userinput"
->G</KBD
-> or <KBD
-CLASS="userinput"
->g</KBD
-> for gigabytes,
-which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.</P
->
-<P
->The value must be representable as a 64-bit unsigned integer
+be limited by the context in which it is used.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">path_name</code></p></td>
+<td><p>A quoted string which will be used as
+a pathname, such as <code class="filename">zones/master/my.test.domain</code>.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">size_spec</code></p></td>
+<td>
+<p>A number, the word <strong class="userinput"><code>unlimited</code></strong>,
+or the word <strong class="userinput"><code>default</code></strong>.</p>
+<p>
+An <code class="varname">unlimited</code> <code class="varname">size_spec</code> requests unlimited
+use, or the maximum available amount. A <code class="varname">default size_spec</code> uses
+the limit that was in force when the server was started.</p>
+<p>A <code class="varname">number</code> can
+optionally be followed by a scaling factor: <strong class="userinput"><code>K</code></strong> or <strong class="userinput"><code>k</code></strong> for
+kilobytes, <strong class="userinput"><code>M</code></strong> or <strong class="userinput"><code>m</code></strong> for
+megabytes, and <strong class="userinput"><code>G</code></strong> or <strong class="userinput"><code>g</code></strong> for gigabytes,
+which scale by 1024, 1024*1024, and 1024*1024*1024 respectively.</p>
+<p>The value must be representable as a 64-bit unsigned integer
 (0 to 18446744073709551615, inclusive).
-Using <VAR
-CLASS="varname"
->unlimited</VAR
-> is the best way
-to safely set a really large number.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->yes_or_no</VAR
-></P
-></TD
-><TD
-><P
->Either <KBD
-CLASS="userinput"
->yes</KBD
-> or <KBD
-CLASS="userinput"
->no</KBD
->.
-The words <KBD
-CLASS="userinput"
->true</KBD
-> and <KBD
-CLASS="userinput"
->false</KBD
-> are
-also accepted, as are the numbers <KBD
-CLASS="userinput"
->1</KBD
-> and <KBD
-CLASS="userinput"
->0</KBD
->.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->dialup_option</VAR
-></P
-></TD
-><TD
-><P
->One of <KBD
-CLASS="userinput"
->yes</KBD
->,
-<KBD
-CLASS="userinput"
->no</KBD
->, <KBD
-CLASS="userinput"
->notify</KBD
->,
-<KBD
-CLASS="userinput"
->notify-passive</KBD
->, <KBD
-CLASS="userinput"
->refresh</KBD
-> or
-<KBD
-CLASS="userinput"
->passive</KBD
->.
-When used in a zone, <KBD
-CLASS="userinput"
->notify-passive</KBD
->,
-<KBD
-CLASS="userinput"
->refresh</KBD
->, and <KBD
-CLASS="userinput"
->passive</KBD
->
-are restricted to slave and stub zones.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="address_match_lists"
->6.1.1. Address Match Lists</A
-></H2
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN1251"
->6.1.1.1. Syntax</A
-></H3
-><PRE
-CLASS="programlisting"
-><VAR
-CLASS="varname"
->address_match_list</VAR
-> = address_match_list_element ;
-  [<SPAN
-CLASS="optional"
-> address_match_list_element; ... </SPAN
->]
-<VAR
-CLASS="varname"
->address_match_list_element</VAR
-> = [<SPAN
-CLASS="optional"
-> ! </SPAN
->] (ip_address [<SPAN
-CLASS="optional"
->/length</SPAN
->] |
+Using <code class="varname">unlimited</code> is the best way
+to safely set a really large number.</p>
+</td>
+</tr>
+<tr>
+<td><p><code class="varname">yes_or_no</code></p></td>
+<td><p>Either <strong class="userinput"><code>yes</code></strong> or <strong class="userinput"><code>no</code></strong>.
+The words <strong class="userinput"><code>true</code></strong> and <strong class="userinput"><code>false</code></strong> are
+also accepted, as are the numbers <strong class="userinput"><code>1</code></strong> and <strong class="userinput"><code>0</code></strong>.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">dialup_option</code></p></td>
+<td><p>One of <strong class="userinput"><code>yes</code></strong>,
+<strong class="userinput"><code>no</code></strong>, <strong class="userinput"><code>notify</code></strong>,
+<strong class="userinput"><code>notify-passive</code></strong>, <strong class="userinput"><code>refresh</code></strong> or
+<strong class="userinput"><code>passive</code></strong>.
+When used in a zone, <strong class="userinput"><code>notify-passive</code></strong>,
+<strong class="userinput"><code>refresh</code></strong>, and <strong class="userinput"><code>passive</code></strong>
+are restricted to slave and stub zones.</p></td>
+</tr>
+</tbody>
+</table></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="address_match_lists"></a>Address Match Lists</h3></div></div></div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2551560"></a>Syntax</h4></div></div></div>
+<pre class="programlisting"><code class="varname">address_match_list</code> = address_match_list_element ;
+  [<span class="optional"> address_match_list_element; ... </span>]
+<code class="varname">address_match_list_element</code> = [<span class="optional"> ! </span>] (ip_address [<span class="optional">/length</span>] |
    key key_id | acl_name | { address_match_list } )
-</PRE
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN1259"
->6.1.1.2. Definition and Usage</A
-></H3
-><P
->Address match lists are primarily used to determine access
+</pre>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2551587"></a>Definition and Usage</h4></div></div></div>
+<p>Address match lists are primarily used to determine access
 control for various server operations. They are also used in
-the <B
-CLASS="command"
->listen-on</B
-> and <B
-CLASS="command"
->sortlist</B
->
+the <span><strong class="command">listen-on</strong></span> and <span><strong class="command">sortlist</strong></span>
 statements. The elements
-which constitute an address match list can be any of the following:</P
-><P
-></P
-><UL
-><LI
-><P
->an IP address (IPv4 or IPv6)</P
-></LI
-><LI
-><P
->an IP prefix (in `/' notation)</P
-></LI
-><LI
-><P
->a key ID, as defined by the <B
-CLASS="command"
->key</B
-> statement</P
-></LI
-><LI
-><P
->the name of an address match list previously defined with
-the <B
-CLASS="command"
->acl</B
-> statement</P
-></LI
-><LI
-><P
->a nested address match list enclosed in braces</P
-></LI
-></UL
-><P
->Elements can be negated with a leading exclamation mark (`!'),
+which constitute an address match list can be any of the following:</p>
+<div class="itemizedlist"><ul type="disc">
+<li>an IP address (IPv4 or IPv6)</li>
+<li>an IP prefix (in `/' notation)</li>
+<li>a key ID, as defined by the <span><strong class="command">key</strong></span> statement</li>
+<li>the name of an address match list defined with
+the <span><strong class="command">acl</strong></span> statement</li>
+<li>a nested address match list enclosed in braces</li>
+</ul></div>
+<p>Elements can be negated with a leading exclamation mark (`!'),
 and the match list names "any", "none", "localhost", and "localnets"
 are predefined. More information on those names can be found in
-the description of the acl statement.</P
-><P
->The addition of the key clause made the name of this syntactic
+the description of the acl statement.</p>
+<p>The addition of the key clause made the name of this syntactic
 element something of a misnomer, since security keys can be used
 to validate access without regard to a host or network address. Nonetheless,
-the term "address match list" is still used throughout the documentation.</P
-><P
->When a given IP address or prefix is compared to an address
+the term "address match list" is still used throughout the documentation.</p>
+<p>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 in a sortlist,
-and whether the element was negated.</P
-><P
->When used as an access control list, a non-negated match allows
+and whether the element was negated.</p>
+<p>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 <B
-CLASS="command"
->allow-notify</B
->,
-<B
-CLASS="command"
->allow-query</B
->, <B
-CLASS="command"
->allow-transfer</B
->,
-<B
-CLASS="command"
->allow-update</B
->, <B
-CLASS="command"
->allow-update-forwarding</B
->,
-and <B
-CLASS="command"
->blackhole</B
-> all
+access is denied. The clauses <span><strong class="command">allow-notify</strong></span>,
+<span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
+<span><strong class="command">allow-update</strong></span>, <span><strong class="command">allow-update-forwarding</strong></span>,
+and <span><strong class="command">blackhole</strong></span> all
 use address match lists  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
->Because of the first-match aspect of the algorithm, an element
+which do not match the list.</p>
+<p>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
-<B
-CLASS="command"
->1.2.3/24; ! 1.2.3.13;</B
-> the 1.2.3.13 element is
+<span><strong class="command">1.2.3/24; ! 1.2.3.13;</strong></span> the 1.2.3.13 element is
 completely useless because the algorithm will match any lookup for
 1.2.3.13 to the 1.2.3/24 element.
-Using <B
-CLASS="command"
->! 1.2.3.13; 1.2.3/24</B
-> fixes
+Using <span><strong class="command">! 1.2.3.13; 1.2.3/24</strong></span> fixes
 that problem by having 1.2.3.13 blocked by the negation but all
-other 1.2.3.* hosts fall through.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1290"
->6.1.2. Comment Syntax</A
-></H2
-><P
->The <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 comment syntax allows for comments to appear
-anywhere that white space may appear in a <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> configuration
+other 1.2.3.* hosts fall through.</p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2551817"></a>Comment Syntax</h3></div></div></div>
+<p>The <span class="acronym">BIND</span> 9 comment syntax allows for comments to appear
+anywhere that white space may appear in a <span class="acronym">BIND</span> configuration
 file. To appeal to programmers of all kinds, they can be written
-in the C, C++, or shell/perl style.</P
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN1295"
->6.1.2.1. Syntax</A
-></H3
-><P
-><PRE
-CLASS="programlisting"
->/* This is a <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> comment as in C */</PRE
->
-<PRE
-CLASS="programlisting"
->// This is a <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> comment as in C++</PRE
->
-<PRE
-CLASS="programlisting"
-># This is a <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> comment as in common UNIX shells and perl</PRE
->
-      </P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN1304"
->6.1.2.2. Definition and Usage</A
-></H3
-><P
->Comments may appear anywhere that whitespace may appear in
-a <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> configuration file.</P
-><P
->C-style comments start with the two characters /* (slash,
+in the C, C++, or shell/perl style.</p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2551832"></a>Syntax</h4></div></div></div>
+<pre class="programlisting">/* This is a <span class="acronym">BIND</span> comment as in C */</pre>
+<p>
+</p>
+<pre class="programlisting">// This is a <span class="acronym">BIND</span> comment as in C++</pre>
+<p>
+</p>
+<pre class="programlisting"># This is a <span class="acronym">BIND</span> comment as in common UNIX shells and perl</pre>
+<p>
+      </p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2551861"></a>Definition and Usage</h4></div></div></div>
+<p>Comments may appear anywhere that whitespace may appear in
+a <span class="acronym">BIND</span> configuration file.</p>
+<p>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
->C-style comments cannot be nested. For example, the following
-is not valid because the entire comment ends with the first */:</P
-><P
-><PRE
-CLASS="programlisting"
->/* This is the start of a comment.
+a portion of a line or to span multiple lines.</p>
+<p>C-style comments cannot be nested. For example, the following
+is not valid because the entire comment ends with the first */:</p>
+<pre class="programlisting">/* This is the start of a comment.
    This is still part of the comment.
 /* This is an incorrect attempt at nesting a comment. */
    This is no longer in any comment. */
-</PRE
-></P
-><P
->C++-style comments start with the two characters // (slash,
+</pre>
+<p>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
->For example:</P
-><P
-><PRE
-CLASS="programlisting"
->// This is the start of a comment.  The next line
+comment span multiple lines, each line must use the // pair.</p>
+<p>For example:</p>
+<pre class="programlisting">// This is the start of a comment.  The next line
 // is a new comment, even though it is logically
 // part of the previous comment.
-</PRE
-></P
-><P
->Shell-style (or perl-style, if you prefer) comments start
-with the character <VAR
-CLASS="literal"
->#</VAR
-> (number sign) and continue to the end of the
-physical line, as in C++ comments.</P
-><P
->For example:</P
-><P
-><PRE
-CLASS="programlisting"
-># This is the start of a comment.  The next line
+</pre>
+<p>Shell-style (or perl-style, if you prefer) comments start
+with the character <code class="literal">#</code> (number sign) and continue to the end of the
+physical line, as in C++ comments.</p>
+<p>For example:</p>
+<pre class="programlisting"># This is the start of a comment.  The next line
 # is a new comment, even though it is logically
 # part of the previous comment.
-</PRE
->
-</P
-><DIV
-CLASS="warning"
-><P
-></P
-><TABLE
-CLASS="warning"
-BORDER="1"
-WIDTH="100%"
-><TR
-><TD
-ALIGN="CENTER"
-><B
->Warning</B
-></TD
-></TR
-><TR
-><TD
-ALIGN="LEFT"
-><P
->You cannot use the semicolon (`;') character
+</pre>
+<p>
+</p>
+<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Warning</h3>
+<p>You cannot use the semicolon (`;') character
    to start a comment such as you would in a zone file. The
    semicolon indicates the end of a configuration
-   statement.</P
-></TD
-></TR
-></TABLE
-></DIV
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="Configuration_File_Grammar"
->6.2. Configuration File Grammar</A
-></H1
-><P
->A <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 configuration consists of statements and comments.
+   statement.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="Configuration_File_Grammar"></a>Configuration File Grammar</h2></div></div></div>
+<p>A <span class="acronym">BIND</span> 9 configuration consists of statements and comments.
     Statements end with a semicolon. Statements and comments are the
     only elements that can appear without enclosing braces. Many
     statements contain a block of sub-statements, which are also
-    terminated with a semicolon.</P
-><P
->The following statements are supported:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN1328"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><B
-CLASS="command"
->acl</B
-></P
-></TD
-><TD
-><P
->defines a named IP address
-matching list, for access control and other uses.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->controls</B
-></P
-></TD
-><TD
-><P
->declares control channels to be used
-by the <B
-CLASS="command"
->rndc</B
-> utility.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->include</B
-></P
-></TD
-><TD
-><P
->includes a file.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->key</B
-></P
-></TD
-><TD
-><P
->specifies key information for use in
-authentication and authorization using TSIG.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->logging</B
-></P
-></TD
-><TD
-><P
->specifies what the server logs, and where
-the log messages are sent.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->lwres</B
-></P
-></TD
-><TD
-><P
->configures <B
-CLASS="command"
->named</B
-> to
-also act as a light weight resolver daemon (<B
-CLASS="command"
->lwresd</B
->).</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->masters</B
-></P
-></TD
-><TD
-><P
->defines a named masters list for
-inclusion in stub and slave zone masters clauses.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->options</B
-></P
-></TD
-><TD
-><P
->controls global server configuration
-options and sets defaults for other statements.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->server</B
-></P
-></TD
-><TD
-><P
->sets certain configuration options on
-a per-server basis.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->trusted-keys</B
-></P
-></TD
-><TD
-><P
->defines trusted DNSSEC keys.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->view</B
-></P
-></TD
-><TD
-><P
->defines a view.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->zone</B
-></P
-></TD
-><TD
-><P
->defines a zone.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->The <B
-CLASS="command"
->logging</B
-> and
-    <B
-CLASS="command"
->options</B
-> statements may only occur once per
-    configuration.</P
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1411"
->6.2.1. <B
-CLASS="command"
->acl</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
-><B
-CLASS="command"
->acl</B
-> acl-name { 
+    terminated with a semicolon.</p>
+<p>The following statements are supported:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span><strong class="command">acl</strong></span></p></td>
+<td><p>defines a named IP address
+matching list, for access control and other uses.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">controls</strong></span></p></td>
+<td><p>declares control channels to be used
+by the <span><strong class="command">rndc</strong></span> utility.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">include</strong></span></p></td>
+<td><p>includes a file.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">key</strong></span></p></td>
+<td><p>specifies key information for use in
+authentication and authorization using TSIG.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">logging</strong></span></p></td>
+<td><p>specifies what the server logs, and where
+the log messages are sent.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">lwres</strong></span></p></td>
+<td><p>configures <span><strong class="command">named</strong></span> to
+also act as a light weight resolver daemon (<span><strong class="command">lwresd</strong></span>).</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">masters</strong></span></p></td>
+<td><p>defines a named masters list for
+inclusion in stub and slave zone masters clauses.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">options</strong></span></p></td>
+<td><p>controls global server configuration
+options and sets defaults for other statements.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">server</strong></span></p></td>
+<td><p>sets certain configuration options on
+a per-server basis.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">trusted-keys</strong></span></p></td>
+<td><p>defines trusted DNSSEC keys.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">view</strong></span></p></td>
+<td><p>defines a view.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">zone</strong></span></p></td>
+<td><p>defines a zone.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>The <span><strong class="command">logging</strong></span> and
+    <span><strong class="command">options</strong></span> statements may only occur once per
+    configuration.</p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2552302"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting"><span><strong class="command">acl</strong></span> acl-name { 
     address_match_list 
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="acl"
->6.2.2. <B
-CLASS="command"
->acl</B
-> Statement Definition and
-Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->acl</B
-> statement assigns a symbolic
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="acl"></a><span><strong class="command">acl</strong></span> Statement Definition and
+Usage</h3></div></div></div>
+<p>The <span><strong class="command">acl</strong></span> 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
->Note that an address match list's name must be defined
-      with <B
-CLASS="command"
->acl</B
-> before it can be used elsewhere; no
-      forward references are allowed.</P
-><P
->The following ACLs are built-in:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN1424"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><B
-CLASS="command"
->any</B
-></P
-></TD
-><TD
-><P
->Matches all hosts.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->none</B
-></P
-></TD
-><TD
-><P
->Matches no hosts.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->localhost</B
-></P
-></TD
-><TD
-><P
->Matches the IPv4 and IPv6 addresses of all network
-interfaces on the system.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->localnets</B
-></P
-></TD
-><TD
-><P
->Matches any host on an IPv4 or IPv6 network
+      use of address match lists: Access Control Lists (ACLs).</p>
+<p>Note that an address match list's name must be defined
+      with <span><strong class="command">acl</strong></span> before it can be used elsewhere; no
+      forward references are allowed.</p>
+<p>The following ACLs are built-in:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span><strong class="command">any</strong></span></p></td>
+<td><p>Matches all hosts.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">none</strong></span></p></td>
+<td><p>Matches no hosts.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">localhost</strong></span></p></td>
+<td><p>Matches the IPv4 and IPv6 addresses of all network
+interfaces on the system.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">localnets</strong></span></p></td>
+<td><p>Matches any host on an IPv4 or IPv6 network
 for which the system has an interface.
 Some systems do not provide a way to determine the prefix lengths of
 local IPv6 addresses.
-In such a case, <B
-CLASS="command"
->localnets</B
-> only matches the local
-IPv6 addresses, just like <B
-CLASS="command"
->localhost</B
->.
-</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1455"
->6.2.3. <B
-CLASS="command"
->controls</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
-><B
-CLASS="command"
->controls</B
-> {
-   inet ( ip_addr | * ) [<SPAN
-CLASS="optional"
-> port ip_port </SPAN
->] allow { <VAR
-CLASS="replaceable"
-> address_match_list </VAR
-> }
-                keys { <VAR
-CLASS="replaceable"
-> key_list </VAR
-> };
-   [<SPAN
-CLASS="optional"
-> inet ...; </SPAN
->]
+In such a case, <span><strong class="command">localnets</strong></span> only matches the local
+IPv6 addresses, just like <span><strong class="command">localhost</strong></span>.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2552471"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting"><span><strong class="command">controls</strong></span> {
+   inet ( ip_addr | * ) [<span class="optional"> port ip_port </span>] allow { <em class="replaceable"><code> address_match_list </code></em> }
+                keys { <em class="replaceable"><code> key_list </code></em> };
+   [<span class="optional"> inet ...; </span>]
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="controls_statement_definition_and_usage"
->6.2.4. <B
-CLASS="command"
->controls</B
-> Statement Definition and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->controls</B
-> statement declares control
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="controls_statement_definition_and_usage"></a><span><strong class="command">controls</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>The <span><strong class="command">controls</strong></span> statement declares control
       channels to be used by system administrators to control the
       operation of the name server. These control channels are
-      used by the <B
-CLASS="command"
->rndc</B
-> utility to send commands to
-      and retrieve non-DNS results from a name server.</P
-><P
->An <B
-CLASS="command"
->inet</B
-> control channel is a TCP
+      used by the <span><strong class="command">rndc</strong></span> utility to send commands to
+      and retrieve non-DNS results from a name server.</p>
+<p>An <span><strong class="command">inet</strong></span> control channel is a TCP
       socket listening at the specified
-      <B
-CLASS="command"
->ip_port</B
-> on the specified
-      <B
-CLASS="command"
->ip_addr</B
->, which can be an IPv4 or IPv6
-      address.  An <B
-CLASS="command"
->ip_addr</B
->
-      of <VAR
-CLASS="literal"
->*</VAR
-> is interpreted as the IPv4 wildcard
+      <span><strong class="command">ip_port</strong></span> on the specified
+      <span><strong class="command">ip_addr</strong></span>, which can be an IPv4 or IPv6
+      address.  An <span><strong class="command">ip_addr</strong></span>
+      of <code class="literal">*</code> is interpreted as the IPv4 wildcard
       address; connections will be accepted on any of the system's
       IPv4 addresses.  To listen on the IPv6 wildcard address,
-      use an <B
-CLASS="command"
->ip_addr</B
-> of <VAR
-CLASS="literal"
->::</VAR
->.
-      If you will only use <B
-CLASS="command"
->rndc</B
-> on the local host,
-      using the loopback address (<VAR
-CLASS="literal"
->127.0.0.1</VAR
->
-      or <VAR
-CLASS="literal"
->::1</VAR
->) is recommended for maximum
+      use an <span><strong class="command">ip_addr</strong></span> of <code class="literal">::</code>.
+      If you will only use <span><strong class="command">rndc</strong></span> on the local host,
+      using the loopback address (<code class="literal">127.0.0.1</code>
+      or <code class="literal">::1</code>) is recommended for maximum
       security.
-      </P
-><P
->&#13;      If no port is specified, port 953
-      is used.  "<VAR
-CLASS="literal"
->*</VAR
->" cannot be used for
-      <B
-CLASS="command"
->ip_port</B
->.</P
-><P
->The ability to issue commands over the control channel is
-      restricted by the <B
-CLASS="command"
->allow</B
-> and
-      <B
-CLASS="command"
->keys</B
-> clauses. Connections to the control
+      </p>
+<p>
+      If no port is specified, port 953
+      is used.  "<code class="literal">*</code>" cannot be used for
+      <span><strong class="command">ip_port</strong></span>.</p>
+<p>The ability to issue commands over the control channel is
+      restricted by the <span><strong class="command">allow</strong></span> and
+      <span><strong class="command">keys</strong></span> clauses. Connections to the control
       channel are permitted based on the
-      <B
-CLASS="command"
->address_match_list</B
->.  This is for simple
-      IP address based filtering only; any <B
-CLASS="command"
->key_id</B
->
-      elements of the <B
-CLASS="command"
->address_match_list</B
-> are
+      <span><strong class="command">address_match_list</strong></span>.  This is for simple
+      IP address based filtering only; any <span><strong class="command">key_id</strong></span>
+      elements of the <span><strong class="command">address_match_list</strong></span> are
       ignored.
-      </P
-><P
->The primary authorization mechanism of the command
-      channel is the <B
-CLASS="command"
->key_list</B
->, which contains
-      a list of <B
-CLASS="command"
->key_id</B
->s.
-      Each <B
-CLASS="command"
->key_id</B
-> in
-      the <B
-CLASS="command"
->key_list</B
-> is authorized to execute
+      </p>
+<p>The primary authorization mechanism of the command
+      channel is the <span><strong class="command">key_list</strong></span>, which contains
+      a list of <span><strong class="command">key_id</strong></span>s.
+      Each <span><strong class="command">key_id</strong></span> in
+      the <span><strong class="command">key_list</strong></span> is authorized to execute
       commands over the control channel.
-      See <A
-HREF="Bv9ARM.ch03.html#rndc"
->Remote Name Daemon Control application</A
-> in
-      <A
-HREF="Bv9ARM.ch03.html#admin_tools"
->Section 3.3.1.2</A
->) for information about
-      configuring keys in <B
-CLASS="command"
->rndc</B
->.</P
-><P
->&#13;If no <B
-CLASS="command"
->controls</B
-> statement is present,
-<B
-CLASS="command"
->named</B
-> will set up a default
+      See <a href="Bv9ARM.ch03.html#rndc">Remote Name Daemon Control application</a> in
+      <a href="Bv9ARM.ch03.html#admin_tools" title="Administrative Tools">the section called &#8220;Administrative Tools&#8221;</a>) for information about
+      configuring keys in <span><strong class="command">rndc</strong></span>.</p>
+<p>
+If no <span><strong class="command">controls</strong></span> statement is present,
+<span><strong class="command">named</strong></span> will set up a default
 control channel listening on the loopback address 127.0.0.1
 and its IPv6 counterpart ::1.
-In this case, and also when the <B
-CLASS="command"
->controls</B
-> statement
-is present but does not have a <B
-CLASS="command"
->keys</B
-> clause,
-<B
-CLASS="command"
->named</B
-> will attempt to load the command channel key
-from the file <TT
-CLASS="filename"
->rndc.key</TT
-> in
-<TT
-CLASS="filename"
->/etc</TT
-> (or whatever <VAR
-CLASS="varname"
->sysconfdir</VAR
->
-was specified as when <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> was built).
-To create a <TT
-CLASS="filename"
->rndc.key</TT
-> file, run
-<KBD
-CLASS="userinput"
->rndc-confgen -a</KBD
->.
-</P
-><P
->The <TT
-CLASS="filename"
->rndc.key</TT
-> feature was created to
-      ease the transition of systems from <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8,
+In this case, and also when the <span><strong class="command">controls</strong></span> statement
+is present but does not have a <span><strong class="command">keys</strong></span> clause,
+<span><strong class="command">named</strong></span> will attempt to load the command channel key
+from the file <code class="filename">rndc.key</code> in
+<code class="filename">/etc</code> (or whatever <code class="varname">sysconfdir</code>
+was specified as when <span class="acronym">BIND</span> was built).
+To create a <code class="filename">rndc.key</code> file, run
+<strong class="userinput"><code>rndc-confgen -a</code></strong>.
+</p>
+<p>The <code class="filename">rndc.key</code> feature was created to
+      ease the transition of systems from <span class="acronym">BIND</span> 8,
       which did not have digital signatures on its command channel messages
-      and thus did not have a <B
-CLASS="command"
->keys</B
-> clause.
+      and thus did not have a <span><strong class="command">keys</strong></span> clause.
 
-It makes it possible to use an existing <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8
-configuration file in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 unchanged,
-and still have <B
-CLASS="command"
->rndc</B
-> work the same way
-<B
-CLASS="command"
->ndc</B
-> worked in BIND 8, simply by executing the
-command <KBD
-CLASS="userinput"
->rndc-confgen -a</KBD
-> after BIND 9 is
+It makes it possible to use an existing <span class="acronym">BIND</span> 8
+configuration file in <span class="acronym">BIND</span> 9 unchanged,
+and still have <span><strong class="command">rndc</strong></span> work the same way
+<span><strong class="command">ndc</strong></span> worked in BIND 8, simply by executing the
+command <strong class="userinput"><code>rndc-confgen -a</code></strong> after BIND 9 is
 installed.
-</P
-><P
->&#13;      Since the <TT
-CLASS="filename"
->rndc.key</TT
-> feature
+</p>
+<p>
+      Since the <code class="filename">rndc.key</code> feature
       is only intended to allow the backward-compatible usage of
-      <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 configuration files, this feature does not
+      <span class="acronym">BIND</span> 8 configuration files, this feature does not
       have a high degree of configurability.  You cannot easily change
       the key name or the size of the secret, so you should make a
-      <TT
-CLASS="filename"
->rndc.conf</TT
-> with your own key if you wish to change
-      those things.  The <TT
-CLASS="filename"
->rndc.key</TT
-> file also has its
+      <code class="filename">rndc.conf</code> with your own key if you wish to change
+      those things.  The <code class="filename">rndc.key</code> file also has its
       permissions set such that only the owner of the file (the user that
-      <B
-CLASS="command"
->named</B
-> is running as) can access it.  If you
+      <span><strong class="command">named</strong></span> is running as) can access it.  If you
       desire greater flexibility in allowing other users to access
-      <B
-CLASS="command"
->rndc</B
-> commands then you need to create an
-      <TT
-CLASS="filename"
->rndc.conf</TT
-> and make it group readable by a group
-      that contains the users who should have access.</P
-><P
->The UNIX control channel type of <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 is not supported
-      in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9, and is not expected to be added in future
+      <span><strong class="command">rndc</strong></span> commands then you need to create an
+      <code class="filename">rndc.conf</code> and make it group readable by a group
+      that contains the users who should have access.</p>
+<p>The UNIX control channel type of <span class="acronym">BIND</span> 8 is not supported
+      in <span class="acronym">BIND</span> 9, and is not expected to be added in future
       releases.  If it is present in the controls statement from a
-      <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 configuration file, it is ignored
-      and a warning is logged.</P
-><P
->&#13;To disable the command channel, use an empty <B
-CLASS="command"
->controls</B
->
-statement: <B
-CLASS="command"
->controls { };</B
->.
-</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1534"
->6.2.5. <B
-CLASS="command"
->include</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
->include <VAR
-CLASS="replaceable"
->filename</VAR
->;</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1539"
->6.2.6. <B
-CLASS="command"
->include</B
-> Statement Definition and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->include</B
-> statement inserts the
-      specified file at the point where the <B
-CLASS="command"
->include</B
->
-      statement is encountered. The <B
-CLASS="command"
->include</B
->
+      <span class="acronym">BIND</span> 8 configuration file, it is ignored
+      and a warning is logged.</p>
+<p>
+To disable the command channel, use an empty <span><strong class="command">controls</strong></span>
+statement: <span><strong class="command">controls { };</strong></span>.
+</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2552808"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">include <em class="replaceable"><code>filename</code></em>;</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2552823"></a><span><strong class="command">include</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>The <span><strong class="command">include</strong></span> statement inserts the
+      specified file at the point where the <span><strong class="command">include</strong></span>
+      statement is encountered. The <span><strong class="command">include</strong></span>
       statement facilitates the administration of configuration files
       by permitting the reading or writing of some things but not
       others. For example, the statement could include private keys
-      that are readable only by the name server.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1546"
->6.2.7. <B
-CLASS="command"
->key</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
->key <VAR
-CLASS="replaceable"
->key_id</VAR
-> {
-    algorithm <VAR
-CLASS="replaceable"
->string</VAR
->;
-    secret <VAR
-CLASS="replaceable"
->string</VAR
->;
+      that are readable only by the name server.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2552845"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">key <em class="replaceable"><code>key_id</code></em> {
+    algorithm <em class="replaceable"><code>string</code></em>;
+    secret <em class="replaceable"><code>string</code></em>;
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1553"
->6.2.8. <B
-CLASS="command"
->key</B
-> Statement Definition and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->key</B
-> statement defines a shared
-secret key for use with TSIG (see <A
-HREF="Bv9ARM.ch04.html#tsig"
->Section 4.5</A
->)
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2552867"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>The <span><strong class="command">key</strong></span> statement defines a shared
+secret key for use with TSIG (see <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
 or the command channel
-(see <A
-HREF="Bv9ARM.ch06.html#controls_statement_definition_and_usage"
->Section 6.2.4</A
->).
-</P
-><P
->&#13;The <B
-CLASS="command"
->key</B
-> statement can occur at the top level
-of the configuration file or inside a <B
-CLASS="command"
->view</B
-> 
-statement.  Keys defined in top-level <B
-CLASS="command"
->key</B
->
+(see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and Usage&#8221;</a>).
+</p>
+<p>
+The <span><strong class="command">key</strong></span> statement can occur at the top level
+of the configuration file or inside a <span><strong class="command">view</strong></span> 
+statement.  Keys defined in top-level <span><strong class="command">key</strong></span>
 statements can be used in all views.  Keys intended for use in
-a <B
-CLASS="command"
->controls</B
-> statement
-(see <A
-HREF="Bv9ARM.ch06.html#controls_statement_definition_and_usage"
->Section 6.2.4</A
->)
+a <span><strong class="command">controls</strong></span> statement
+(see <a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage" title="controls Statement Definition and Usage">the section called &#8220;<span><strong class="command">controls</strong></span> Statement Definition and Usage&#8221;</a>)
 must be defined at the top level.
-</P
-><P
->The <VAR
-CLASS="replaceable"
->key_id</VAR
->, also known as the
+</p>
+<p>The <em class="replaceable"><code>key_id</code></em>, also known as the
 key name, is a domain name uniquely identifying the key. It can
-be used in a <B
-CLASS="command"
->server</B
->
+be used in a <span><strong class="command">server</strong></span>
 statement to cause requests sent to that
 server to be signed with this key, or in address match lists to
 verify that incoming requests have been signed with a key
-matching this name, algorithm, and secret.</P
-><P
->The <VAR
-CLASS="replaceable"
->algorithm_id</VAR
-> is a string
+matching this name, algorithm, and secret.</p>
+<p>The <em class="replaceable"><code>algorithm_id</code></em> is a string
 that specifies a security/authentication algorithm. The only
 algorithm currently supported with TSIG authentication is
-<VAR
-CLASS="literal"
->hmac-md5</VAR
->.  The
-<VAR
-CLASS="replaceable"
->secret_string</VAR
-> is the secret to be
+<code class="literal">hmac-md5</code>.  The
+<em class="replaceable"><code>secret_string</code></em> is the secret to be
 used by the algorithm, and is treated as a base-64 encoded
-string.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1573"
->6.2.9. <B
-CLASS="command"
->logging</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
-><B
-CLASS="command"
->logging</B
-> {
-   [ <B
-CLASS="command"
->channel</B
-> <VAR
-CLASS="replaceable"
->channel_name</VAR
-> {
-     ( <B
-CLASS="command"
->file</B
-> <VAR
-CLASS="replaceable"
->path name</VAR
->
-         [ <B
-CLASS="command"
->versions</B
-> ( <VAR
-CLASS="replaceable"
->number</VAR
-> | <VAR
-CLASS="literal"
->unlimited</VAR
-> ) ]
-         [ <B
-CLASS="command"
->size</B
-> <VAR
-CLASS="replaceable"
->size spec</VAR
-> ]
-       | <B
-CLASS="command"
->syslog</B
-> <VAR
-CLASS="replaceable"
->syslog_facility</VAR
->
-       | <B
-CLASS="command"
->stderr</B
->
-       | <B
-CLASS="command"
->null</B
-> );
-     [ <B
-CLASS="command"
->severity</B
-> (<VAR
-CLASS="option"
->critical</VAR
-> | <VAR
-CLASS="option"
->error</VAR
-> | <VAR
-CLASS="option"
->warning</VAR
-> | <VAR
-CLASS="option"
->notice</VAR
-> |
-                 <VAR
-CLASS="option"
->info</VAR
-> | <VAR
-CLASS="option"
->debug</VAR
-> [ <VAR
-CLASS="replaceable"
->level</VAR
-> ] | <VAR
-CLASS="option"
->dynamic</VAR
-> ); ]
-     [ <B
-CLASS="command"
->print-category</B
-> <VAR
-CLASS="option"
->yes</VAR
-> or <VAR
-CLASS="option"
->no</VAR
->; ]
-     [ <B
-CLASS="command"
->print-severity</B
-> <VAR
-CLASS="option"
->yes</VAR
-> or <VAR
-CLASS="option"
->no</VAR
->; ]
-     [ <B
-CLASS="command"
->print-time</B
-> <VAR
-CLASS="option"
->yes</VAR
-> or <VAR
-CLASS="option"
->no</VAR
->; ]
+string.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2553006"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting"><span><strong class="command">logging</strong></span> {
+   [ <span><strong class="command">channel</strong></span> <em class="replaceable"><code>channel_name</code></em> {
+     ( <span><strong class="command">file</strong></span> <em class="replaceable"><code>path name</code></em>
+         [ <span><strong class="command">versions</strong></span> ( <em class="replaceable"><code>number</code></em> | <code class="literal">unlimited</code> ) ]
+         [ <span><strong class="command">size</strong></span> <em class="replaceable"><code>size spec</code></em> ]
+       | <span><strong class="command">syslog</strong></span> <em class="replaceable"><code>syslog_facility</code></em>
+       | <span><strong class="command">stderr</strong></span>
+       | <span><strong class="command">null</strong></span> );
+     [ <span><strong class="command">severity</strong></span> (<code class="option">critical</code> | <code class="option">error</code> | <code class="option">warning</code> | <code class="option">notice</code> |
+                 <code class="option">info</code> | <code class="option">debug</code> [ <em class="replaceable"><code>level</code></em> ] | <code class="option">dynamic</code> ); ]
+     [ <span><strong class="command">print-category</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
+     [ <span><strong class="command">print-severity</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
+     [ <span><strong class="command">print-time</strong></span> <code class="option">yes</code> or <code class="option">no</code>; ]
    }; ]
-   [ <B
-CLASS="command"
->category</B
-> <VAR
-CLASS="replaceable"
->category_name</VAR
-> {
-     <VAR
-CLASS="replaceable"
->channel_name</VAR
-> ; [ <VAR
-CLASS="replaceable"
->channel_nam</VAR
->e ; ... ]
+   [ <span><strong class="command">category</strong></span> <em class="replaceable"><code>category_name</code></em> {
+     <em class="replaceable"><code>channel_name</code></em> ; [ <em class="replaceable"><code>channel_nam</code></em>e ; ... ]
    }; ]
    ...
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1613"
->6.2.10. <B
-CLASS="command"
->logging</B
-> Statement Definition and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->logging</B
-> statement configures a wide
-variety of logging options for the name server. Its <B
-CLASS="command"
->channel</B
-> phrase
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2553269"></a><span><strong class="command">logging</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>The <span><strong class="command">logging</strong></span> statement configures a wide
+variety of logging options for the name server. Its <span><strong class="command">channel</strong></span> phrase
 associates output methods, format options and severity levels with
-a name that can then be used with the <B
-CLASS="command"
->category</B
-> phrase
-to select how various classes of messages are logged.</P
-><P
->Only one <B
-CLASS="command"
->logging</B
-> statement is used to define
-as many channels and categories as are wanted. If there is no <B
-CLASS="command"
->logging</B
-> statement,
-the logging configuration will be:</P
-><PRE
-CLASS="programlisting"
->logging {
+a name that can then be used with the <span><strong class="command">category</strong></span> phrase
+to select how various classes of messages are logged.</p>
+<p>Only one <span><strong class="command">logging</strong></span> statement is used to define
+as many channels and categories as are wanted. If there is no <span><strong class="command">logging</strong></span> statement,
+the logging configuration will be:</p>
+<pre class="programlisting">logging {
      category default { default_syslog; default_debug; };
      category unmatched { null; };
 };
-</PRE
-><P
->In <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9, the logging configuration is only established when
-the entire configuration file has been parsed.  In <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8, it was
-established as soon as the <B
-CLASS="command"
->logging</B
-> statement
+</pre>
+<p>In <span class="acronym">BIND</span> 9, the logging configuration is only established when
+the entire configuration file has been parsed.  In <span class="acronym">BIND</span> 8, it was
+established as soon as the <span><strong class="command">logging</strong></span> 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 "<VAR
-CLASS="option"
->-g</VAR
->" option
-was specified.</P
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN1629"
->6.2.10.1. The <B
-CLASS="command"
->channel</B
-> Phrase</A
-></H3
-><P
->All log output goes to one or more <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->channels</I
-></SPAN
->;
-you can make as many of them as you want.</P
-><P
->Every channel definition must include a destination clause that
+channels, or to standard error if the "<code class="option">-g</code>" option
+was specified.</p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2553321"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
+<p>All log output goes to one or more <span class="emphasis"><em>channels</em></span>;
+you can make as many of them as you want.</p>
+<p>Every channel definition must include a destination clause that
 says whether messages selected for the channel go to a file, to a
 particular syslog facility, to the standard error stream, or are
 discarded. It can optionally also limit the message severity level
 that will be accepted by the channel (the default is
-<B
-CLASS="command"
->info</B
->), and whether to include a
-<B
-CLASS="command"
->named</B
->-generated time stamp, the category name
-and/or severity level (the default is not to include any).</P
-><P
->The <B
-CLASS="command"
->null</B
-> destination clause 
+<span><strong class="command">info</strong></span>), and whether to include a
+<span><strong class="command">named</strong></span>-generated time stamp, the category name
+and/or severity level (the default is not to include any).</p>
+<p>The <span><strong class="command">null</strong></span> destination clause 
 causes all messages sent to the channel to be discarded;
-in that case, other options for the channel are meaningless.</P
-><P
->The <B
-CLASS="command"
->file</B
-> destination clause directs the channel
+in that case, other options for the channel are meaningless.</p>
+<p>The <span><strong class="command">file</strong></span> destination clause directs the channel
 to a disk file.  It can include limitations
 both on how large the file is allowed to become, and how many versions
-of the file will be saved each time the file is opened.</P
-><P
->If you use the <B
-CLASS="command"
->versions</B
-> log file option, then
-<B
-CLASS="command"
->named</B
-> will retain that many backup versions of the file by
+of the file will be saved each time the file is opened.</p>
+<p>If you use the <span><strong class="command">versions</strong></span> log file option, then
+<span><strong class="command">named</strong></span> will retain that many backup versions of the file by
 renaming them when opening.  For example, if you choose to keep 3 old versions
-of the file <TT
-CLASS="filename"
->lamers.log</TT
-> then just before it is opened
-<TT
-CLASS="filename"
->lamers.log.1</TT
-> is renamed to
-<TT
-CLASS="filename"
->lamers.log.2</TT
->, <TT
-CLASS="filename"
->lamers.log.0</TT
-> is renamed
-to <TT
-CLASS="filename"
->lamers.log.1</TT
->, and <TT
-CLASS="filename"
->lamers.log</TT
-> is
-renamed to <TT
-CLASS="filename"
->lamers.log.0</TT
->.
-You can say <B
-CLASS="command"
->versions unlimited</B
-> to not limit
+of the file <code class="filename">lamers.log</code> then just before it is opened
+<code class="filename">lamers.log.1</code> is renamed to
+<code class="filename">lamers.log.2</code>, <code class="filename">lamers.log.0</code> is renamed
+to <code class="filename">lamers.log.1</code>, and <code class="filename">lamers.log</code> is
+renamed to <code class="filename">lamers.log.0</code>.
+You can say <span><strong class="command">versions unlimited</strong></span> to not limit
 the number of versions.
-If a <B
-CLASS="command"
->size</B
-> option is associated with the log file,
+If a <span><strong class="command">size</strong></span> option is associated with the log file,
 then renaming is only done when the file being opened exceeds the
 indicated size.  No backup versions are kept by default; any existing
-log file is simply appended.</P
-><P
->The <B
-CLASS="command"
->size</B
-> option for files is used to limit log
-growth. If the file ever exceeds the size, then <B
-CLASS="command"
->named</B
-> will
-stop writing to the file unless it has a <B
-CLASS="command"
->versions</B
-> option
+log file is simply appended.</p>
+<p>The <span><strong class="command">size</strong></span> option for files is used to limit log
+growth. If the file ever exceeds the size, then <span><strong class="command">named</strong></span> will
+stop writing to the file unless it has a <span><strong class="command">versions</strong></span> option
 associated with it.  If backup versions are kept, the files are rolled as
 described above and a new one begun.  If there is no
-<B
-CLASS="command"
->versions</B
-> option, no more data will be written to the log
+<span><strong class="command">versions</strong></span> option, no more data will be written to the log
 until some out-of-band mechanism removes or truncates the log to less than the
 maximum size.  The default behavior is not to limit the size of the
-file.</P
-><P
->Example usage of the <B
-CLASS="command"
->size</B
-> and
-<B
-CLASS="command"
->versions</B
-> options:</P
-><PRE
-CLASS="programlisting"
->channel an_example_channel {
+file.</p>
+<p>Example usage of the <span><strong class="command">size</strong></span> and
+<span><strong class="command">versions</strong></span> options:</p>
+<pre class="programlisting">channel an_example_channel {
     file "example.log" versions 3 size 20m;
     print-time yes;
     print-category yes;
 };
-</PRE
-><P
->The <B
-CLASS="command"
->syslog</B
-> destination clause directs the
+</pre>
+<p>The <span><strong class="command">syslog</strong></span> destination clause directs the
 channel to the system log.  Its argument is a
-syslog facility as described in the <B
-CLASS="command"
->syslog</B
-> man
-page. Known facilities are <B
-CLASS="command"
->kern</B
->, <B
-CLASS="command"
->user</B
->,
-<B
-CLASS="command"
->mail</B
->, <B
-CLASS="command"
->daemon</B
->, <B
-CLASS="command"
->auth</B
->,
-<B
-CLASS="command"
->syslog</B
->, <B
-CLASS="command"
->lpr</B
->, <B
-CLASS="command"
->news</B
->,
-<B
-CLASS="command"
->uucp</B
->, <B
-CLASS="command"
->cron</B
->, <B
-CLASS="command"
->authpriv</B
->,
-<B
-CLASS="command"
->ftp</B
->, <B
-CLASS="command"
->local0</B
->, <B
-CLASS="command"
->local1</B
->,
-<B
-CLASS="command"
->local2</B
->, <B
-CLASS="command"
->local3</B
->, <B
-CLASS="command"
->local4</B
->,
-<B
-CLASS="command"
->local5</B
->, <B
-CLASS="command"
->local6</B
-> and
-<B
-CLASS="command"
->local7</B
->, however not all facilities are supported on
+syslog facility as described in the <span><strong class="command">syslog</strong></span> man
+page. Known facilities are <span><strong class="command">kern</strong></span>, <span><strong class="command">user</strong></span>,
+<span><strong class="command">mail</strong></span>, <span><strong class="command">daemon</strong></span>, <span><strong class="command">auth</strong></span>,
+<span><strong class="command">syslog</strong></span>, <span><strong class="command">lpr</strong></span>, <span><strong class="command">news</strong></span>,
+<span><strong class="command">uucp</strong></span>, <span><strong class="command">cron</strong></span>, <span><strong class="command">authpriv</strong></span>,
+<span><strong class="command">ftp</strong></span>, <span><strong class="command">local0</strong></span>, <span><strong class="command">local1</strong></span>,
+<span><strong class="command">local2</strong></span>, <span><strong class="command">local3</strong></span>, <span><strong class="command">local4</strong></span>,
+<span><strong class="command">local5</strong></span>, <span><strong class="command">local6</strong></span> and
+<span><strong class="command">local7</strong></span>, however not all facilities are supported on
 all operating systems.
-How <B
-CLASS="command"
->syslog</B
-> will handle messages sent to
-this facility is described in the <B
-CLASS="command"
->syslog.conf</B
-> man
-page. If you have a system which uses a very old version of <B
-CLASS="command"
->syslog</B
-> that
-only uses two arguments to the <B
-CLASS="command"
->openlog()</B
-> function,
-then this clause is silently ignored.</P
-><P
->The <B
-CLASS="command"
->severity</B
-> clause works like <B
-CLASS="command"
->syslog</B
->'s
+How <span><strong class="command">syslog</strong></span> will handle messages sent to
+this facility is described in the <span><strong class="command">syslog.conf</strong></span> man
+page. If you have a system which uses a very old version of <span><strong class="command">syslog</strong></span> that
+only uses two arguments to the <span><strong class="command">openlog()</strong></span> function,
+then this clause is silently ignored.</p>
+<p>The <span><strong class="command">severity</strong></span> clause works like <span><strong class="command">syslog</strong></span>'s
 "priorities", except that they can also be used if you are writing
-straight to a file rather than using <B
-CLASS="command"
->syslog</B
->.
+straight to a file rather than using <span><strong class="command">syslog</strong></span>.
 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
->If you are using <B
-CLASS="command"
->syslog</B
->, then the <B
-CLASS="command"
->syslog.conf</B
-> priorities
+will be accepted.</p>
+<p>If you are using <span><strong class="command">syslog</strong></span>, then the <span><strong class="command">syslog.conf</strong></span> priorities
 will also determine what eventually passes through. For example,
-defining a channel facility and severity as <B
-CLASS="command"
->daemon</B
-> and <B
-CLASS="command"
->debug</B
-> but
-only logging <B
-CLASS="command"
->daemon.warning</B
-> via <B
-CLASS="command"
->syslog.conf</B
-> will
-cause messages of severity <B
-CLASS="command"
->info</B
-> and <B
-CLASS="command"
->notice</B
-> to
-be dropped. If the situation were reversed, with <B
-CLASS="command"
->named</B
-> writing
-messages of only <B
-CLASS="command"
->warning</B
-> or higher, then <B
-CLASS="command"
->syslogd</B
-> would
-print all messages it received from the channel.</P
-><P
->The <B
-CLASS="command"
->stderr</B
-> destination clause directs the
+defining a channel facility and severity as <span><strong class="command">daemon</strong></span> and <span><strong class="command">debug</strong></span> but
+only logging <span><strong class="command">daemon.warning</strong></span> via <span><strong class="command">syslog.conf</strong></span> will
+cause messages of severity <span><strong class="command">info</strong></span> and <span><strong class="command">notice</strong></span> to
+be dropped. If the situation were reversed, with <span><strong class="command">named</strong></span> writing
+messages of only <span><strong class="command">warning</strong></span> or higher, then <span><strong class="command">syslogd</strong></span> would
+print all messages it received from the channel.</p>
+<p>The <span><strong class="command">stderr</strong></span> destination clause directs the
 channel to the server's standard error stream.  This is intended for
 use when the server is running as a foreground process, for example
-when debugging a configuration.</P
-><P
->The server can supply extensive debugging information when
+when debugging a configuration.</p>
+<p>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 <B
-CLASS="command"
->named</B
-> server
-with the <VAR
-CLASS="option"
->-d</VAR
-> flag followed by a positive integer,
-or by running <B
-CLASS="command"
->rndc trace</B
->.
+level is set either by starting the <span><strong class="command">named</strong></span> server
+with the <code class="option">-d</code> flag followed by a positive integer,
+or by running <span><strong class="command">rndc trace</strong></span>.
 The global debug level
-can be set to zero, and debugging mode turned off, by running <B
-CLASS="command"
->ndc
-notrace</B
->. All debugging messages in the server have a debug
+can be set to zero, and debugging mode turned off, by running <span><strong class="command">ndc
+notrace</strong></span>. All debugging messages in the server have a debug
 level, and higher debug levels give more detailed output. Channels
-that specify a specific debug severity, for example:</P
-><PRE
-CLASS="programlisting"
->channel specific_debug_level {
+that specify a specific debug severity, for example:</p>
+<pre class="programlisting">channel specific_debug_level {
     file "foo";
     severity debug 3;
 };
-</PRE
-><P
->will get debugging output of level 3 or less any time the
+</pre>
+<p>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 <B
-CLASS="command"
->dynamic</B
-> severity use the
-server's global debug level to determine what messages to print.</P
-><P
->If <B
-CLASS="command"
->print-time</B
-> has been turned on, then
-the date and time will be logged. <B
-CLASS="command"
->print-time</B
-> may
-be specified for a <B
-CLASS="command"
->syslog</B
-> channel, but is usually
-pointless since <B
-CLASS="command"
->syslog</B
-> also prints the date and
-time. If <B
-CLASS="command"
->print-category</B
-> is requested, then the
-category of the message will be logged as well. Finally, if <B
-CLASS="command"
->print-severity</B
-> is
-on, then the severity level of the message will be logged. The <B
-CLASS="command"
->print-</B
-> options may
+level. Channels with <span><strong class="command">dynamic</strong></span> severity use the
+server's global debug level to determine what messages to print.</p>
+<p>If <span><strong class="command">print-time</strong></span> has been turned on, then
+the date and time will be logged. <span><strong class="command">print-time</strong></span> may
+be specified for a <span><strong class="command">syslog</strong></span> channel, but is usually
+pointless since <span><strong class="command">syslog</strong></span> also prints the date and
+time. If <span><strong class="command">print-category</strong></span> is requested, then the
+category of the message will be logged as well. Finally, if <span><strong class="command">print-severity</strong></span> is
+on, then the severity level of the message will be logged. The <span><strong class="command">print-</strong></span> options may
 be used in any combination, and will always be printed in the following
-order: time, category, severity. Here is an example where all three <B
-CLASS="command"
->print-</B
-> options
-are on:</P
-><P
-><SAMP
-CLASS="computeroutput"
->28-Feb-2000 15:05:32.863 general: notice: running</SAMP
-></P
-><P
->There are four predefined channels that are used for
-<B
-CLASS="command"
->named</B
->'s default logging as follows. How they are
-used is described in <A
-HREF="Bv9ARM.ch06.html#the_category_phrase"
->Section 6.2.10.2</A
->.
-</P
-><PRE
-CLASS="programlisting"
->channel default_syslog {
+order: time, category, severity. Here is an example where all three <span><strong class="command">print-</strong></span> options
+are on:</p>
+<p><code class="computeroutput">28-Feb-2000 15:05:32.863 general: notice: running</code></p>
+<p>There are four predefined channels that are used for
+<span><strong class="command">named</strong></span>'s default logging as follows. How they are
+used is described in <a href="Bv9ARM.ch06.html#the_category_phrase" title="The category Phrase">the section called &#8220;The <span><strong class="command">category</strong></span> Phrase&#8221;</a>.
+</p>
+<pre class="programlisting">channel default_syslog {
     syslog daemon;                      // send to syslog's daemon
                                         // facility
     severity info;                      // only send priority info
@@ -2354,78 +850,37 @@ channel null {
    null;                                // toss anything sent to
                                         // this channel
 };
-</PRE
-><P
->The <B
-CLASS="command"
->default_debug</B
-> channel has the special
+</pre>
+<p>The <span><strong class="command">default_debug</strong></span> channel has the special
 property that it only produces output when the server's debug level is
-nonzero.  It normally writes to a file <TT
-CLASS="filename"
->named.run</TT
->
-in the server's working directory.</P
-><P
->For security reasons, when the "<VAR
-CLASS="option"
->-u</VAR
->"
-command line option is used, the <TT
-CLASS="filename"
->named.run</TT
-> file
-is created only after <B
-CLASS="command"
->named</B
-> has changed to the
-new UID, and any debug output generated while <B
-CLASS="command"
->named</B
-> is
+nonzero.  It normally writes to a file <code class="filename">named.run</code>
+in the server's working directory.</p>
+<p>For security reasons, when the "<code class="option">-u</code>"
+command line option is used, the <code class="filename">named.run</code> file
+is created only after <span><strong class="command">named</strong></span> has changed to the
+new UID, and any debug output generated while <span><strong class="command">named</strong></span> is
 starting up and still running as root is discarded.  If you need
-to capture this output, you must run the server with the "<VAR
-CLASS="option"
->-g</VAR
->"
-option and redirect standard error to a file.</P
-><P
->Once a channel is defined, it cannot be redefined. Thus you
+to capture this output, you must run the server with the "<code class="option">-g</code>"
+option and redirect standard error to a file.</p>
+<p>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
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="the_category_phrase"
->6.2.10.2. The <B
-CLASS="command"
->category</B
-> Phrase</A
-></H3
-><P
->There are many categories, so you can send the logs you want
+the default logging by pointing categories at channels you have defined.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="the_category_phrase"></a>The <span><strong class="command">category</strong></span> Phrase</h4></div></div></div>
+<p>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 <B
-CLASS="command"
->default</B
-> category
+in that category will be sent to the <span><strong class="command">default</strong></span> category
 instead. If you don't specify a default category, the following
-"default default" is used:</P
-><PRE
-CLASS="programlisting"
->category default { default_syslog; default_debug; };
-</PRE
-><P
->As an example, let's say you want to log security events to
+"default default" is used:</p>
+<pre class="programlisting">category default { default_syslog; default_debug; };
+</pre>
+<p>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="programlisting"
->channel my_security_channel {
+specify the following:</p>
+<pre class="programlisting">channel my_security_channel {
     file "my_security_file";
     severity info;
 };
@@ -2433,2691 +888,690 @@ category security {
     my_security_channel;
     default_syslog;
     default_debug;
-};</PRE
-><P
->To discard all messages in a category, specify the <B
-CLASS="command"
->null</B
-> channel:</P
-><PRE
-CLASS="programlisting"
->category xfer-out { null; };
+};</pre>
+<p>To discard all messages in a category, specify the <span><strong class="command">null</strong></span> channel:</p>
+<pre class="programlisting">category xfer-out { null; };
 category notify { null; };
-</PRE
-><P
->Following are the available categories and brief descriptions
+</pre>
+<p>Following are the available categories and brief descriptions
 of the types of log information they contain. More
-categories may be added in future <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> releases.</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN1753"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><B
-CLASS="command"
->default</B
-></P
-></TD
-><TD
-><P
->The default category defines the logging
+categories may be added in future <span class="acronym">BIND</span> releases.</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span><strong class="command">default</strong></span></p></td>
+<td><p>The default category defines the logging
 options for those categories where no specific configuration has been
-defined.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->general</B
-></P
-></TD
-><TD
-><P
->The catch-all. Many things still aren't
-classified into categories, and they all end up here.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->database</B
-></P
-></TD
-><TD
-><P
->Messages relating to the databases used
-internally by the name server to store zone and cache data.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->security</B
-></P
-></TD
-><TD
-><P
->Approval and denial of requests.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->config</B
-></P
-></TD
-><TD
-><P
->Configuration file parsing and processing.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->resolver</B
-></P
-></TD
-><TD
-><P
->DNS resolution, such as the recursive
-lookups performed on behalf of clients by a caching name server.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->xfer-in</B
-></P
-></TD
-><TD
-><P
->Zone transfers the server is receiving.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->xfer-out</B
-></P
-></TD
-><TD
-><P
->Zone transfers the server is sending.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->notify</B
-></P
-></TD
-><TD
-><P
->The NOTIFY protocol.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->client</B
-></P
-></TD
-><TD
-><P
->Processing of client requests.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->unmatched</B
-></P
-></TD
-><TD
-><P
->Messages that named was unable to determine the
-class of or for which there was no matching <B
-CLASS="command"
->view</B
->.
-A one line summary is also logged to the <B
-CLASS="command"
->client</B
-> category.
+defined.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">general</strong></span></p></td>
+<td><p>The catch-all. Many things still aren't
+classified into categories, and they all end up here.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">database</strong></span></p></td>
+<td><p>Messages relating to the databases used
+internally by the name server to store zone and cache data.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">security</strong></span></p></td>
+<td><p>Approval and denial of requests.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">config</strong></span></p></td>
+<td><p>Configuration file parsing and processing.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">resolver</strong></span></p></td>
+<td><p>DNS resolution, such as the recursive
+lookups performed on behalf of clients by a caching name server.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">xfer-in</strong></span></p></td>
+<td><p>Zone transfers the server is receiving.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">xfer-out</strong></span></p></td>
+<td><p>Zone transfers the server is sending.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">notify</strong></span></p></td>
+<td><p>The NOTIFY protocol.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">client</strong></span></p></td>
+<td><p>Processing of client requests.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">unmatched</strong></span></p></td>
+<td><p>Messages that named was unable to determine the
+class of or for which there was no matching <span><strong class="command">view</strong></span>.
+A one line summary is also logged to the <span><strong class="command">client</strong></span> category.
 This category is best sent to a file or stderr, by default it is sent to
-the <B
-CLASS="command"
->null</B
-> channel.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->network</B
-></P
-></TD
-><TD
-><P
->Network operations.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->update</B
-></P
-></TD
-><TD
-><P
->Dynamic updates.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->update-security</B
-></P
-></TD
-><TD
-><P
->Approval and denial of update requests.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->queries</B
-></P
-></TD
-><TD
-><P
->Specify where queries should be logged to.</P
->
-<P
->&#13;At startup, specifing the category <B
-CLASS="command"
->queries</B
-> will also
-enable query logging unless <B
-CLASS="command"
->querylog</B
-> option has been
+the <span><strong class="command">null</strong></span> channel.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">network</strong></span></p></td>
+<td><p>Network operations.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">update</strong></span></p></td>
+<td><p>Dynamic updates.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">update-security</strong></span></p></td>
+<td><p>Approval and denial of update requests.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">queries</strong></span></p></td>
+<td>
+<p>Specify where queries should be logged to.</p>
+<p>
+At startup, specifing the category <span><strong class="command">queries</strong></span> will also
+enable query logging unless <span><strong class="command">querylog</strong></span> option has been
 specified.
-</P
->
-<P
->&#13;The query log entry reports the client's IP address and port number.  The
+</p>
+<p>
+The query log entry reports the client's IP address and port number.  The
 query name, class and type.  It also reports whether the Recursion Desired
 flag was set (+ if set, - if not set), EDNS was in use (E) or if the
-query was signed (S).</P
->
-<PRE
-CLASS="programlisting"
-><SAMP
-CLASS="computeroutput"
->client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</SAMP
->
-<SAMP
-CLASS="computeroutput"
->client ::1#62537: query: www.example.net IN AAAA -SE</SAMP
->
-</PRE
->
-</TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->dispatch</B
-></P
-></TD
-><TD
-><P
->Dispatching of incoming packets to the
+query was signed (S).</p>
+<p><code class="computeroutput">client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</code>
+</p>
+<p><code class="computeroutput">client ::1#62537: query: www.example.net IN AAAA -SE</code>
+</p>
+</td>
+</tr>
+<tr>
+<td><p><span><strong class="command">dispatch</strong></span></p></td>
+<td><p>Dispatching of incoming packets to the
 server modules where they are to be processed.
-</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->dnssec</B
-></P
-></TD
-><TD
-><P
->DNSSEC and TSIG protocol processing.
-</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->lame-servers</B
-></P
-></TD
-><TD
-><P
->Lame servers.  These are misconfigurations
+</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">dnssec</strong></span></p></td>
+<td><p>DNSSEC and TSIG protocol processing.
+</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">lame-servers</strong></span></p></td>
+<td><p>Lame servers.  These are misconfigurations
 in remote servers, discovered by BIND 9 when trying to query
 those servers during resolution.
-</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->delegation-only</B
-></P
-></TD
-><TD
-><P
->Delegation only.  Logs queries that have have
+</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">delegation-only</strong></span></p></td>
+<td><p>Delegation only.  Logs queries that have have
 been forced to NXDOMAIN as the result of a delegation-only zone or
-a <B
-CLASS="command"
->delegation-only</B
-> in a hint or stub zone declaration.
-</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1883"
->6.2.11. <B
-CLASS="command"
->lwres</B
-> Statement Grammar</A
-></H2
-><P
-> This is the grammar of the <B
-CLASS="command"
->lwres</B
->
-statement in the <TT
-CLASS="filename"
->named.conf</TT
-> file:</P
-><PRE
-CLASS="programlisting"
-><B
-CLASS="command"
->lwres</B
-> {
-    [<SPAN
-CLASS="optional"
-> listen-on { <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; ... </SPAN
->] }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> view <VAR
-CLASS="replaceable"
->view_name</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> search { <VAR
-CLASS="replaceable"
->domain_name</VAR
-> ; [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->domain_name</VAR
-> ; ... </SPAN
->] }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> ndots <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
+a <span><strong class="command">delegation-only</strong></span> in a hint or stub zone declaration.
+</p></td>
+</tr>
+</tbody>
+</table></div>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2554474"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
+<p> This is the grammar of the <span><strong class="command">lwres</strong></span>
+statement in the <code class="filename">named.conf</code> file:</p>
+<pre class="programlisting"><span><strong class="command">lwres</strong></span> {
+    [<span class="optional"> listen-on { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> view <em class="replaceable"><code>view_name</code></em>; </span>]
+    [<span class="optional"> search { <em class="replaceable"><code>domain_name</code></em> ; [<span class="optional"> <em class="replaceable"><code>domain_name</code></em> ; ... </span>] }; </span>]
+    [<span class="optional"> ndots <em class="replaceable"><code>number</code></em>; </span>]
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1907"
->6.2.12. <B
-CLASS="command"
->lwres</B
-> Statement Definition and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->lwres</B
-> statement configures the name
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2554547"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>The <span><strong class="command">lwres</strong></span> statement configures the name
 server to also act as a lightweight resolver server, see
-<A
-HREF="Bv9ARM.ch05.html#lwresd"
->Section 5.2</A
->.  There may be be multiple
-<B
-CLASS="command"
->lwres</B
-> statements configuring
-lightweight resolver servers with different properties.</P
-><P
->The <B
-CLASS="command"
->listen-on</B
-> statement specifies a list of
+<a href="Bv9ARM.ch05.html#lwresd" title="Running a Resolver Daemon">the section called &#8220;Running a Resolver Daemon&#8221;</a>.  There may be be multiple
+<span><strong class="command">lwres</strong></span> statements configuring
+lightweight resolver servers with different properties.</p>
+<p>The <span><strong class="command">listen-on</strong></span> statement specifies a list of
 addresses (and ports) that this instance of a lightweight resolver daemon
 should accept requests on.  If no port is specified, port 921 is used.
 If this statement is omitted, requests will be accepted on 127.0.0.1,
-port 921.</P
-><P
->The <B
-CLASS="command"
->view</B
-> statement binds this instance of a
+port 921.</p>
+<p>The <span><strong class="command">view</strong></span> statement binds this instance of a
 lightweight resolver daemon to a view in the DNS namespace, so that the
 response will be constructed in the same manner as a normal DNS query
 matching this view.  If this statement is omitted, the default view is
-used, and if there is no default view, an error is triggered.</P
-><P
->The <B
-CLASS="command"
->search</B
-> statement is equivalent to the
-<B
-CLASS="command"
->search</B
-> statement in
-<TT
-CLASS="filename"
->/etc/resolv.conf</TT
->.  It provides a list of domains
-which are appended to relative names in queries.</P
-><P
->The <B
-CLASS="command"
->ndots</B
-> statement is equivalent to the
-<B
-CLASS="command"
->ndots</B
-> statement in
-<TT
-CLASS="filename"
->/etc/resolv.conf</TT
->.  It indicates the minimum
+used, and if there is no default view, an error is triggered.</p>
+<p>The <span><strong class="command">search</strong></span> statement is equivalent to the
+<span><strong class="command">search</strong></span> statement in
+<code class="filename">/etc/resolv.conf</code>.  It provides a list of domains
+which are appended to relative names in queries.</p>
+<p>The <span><strong class="command">ndots</strong></span> statement is equivalent to the
+<span><strong class="command">ndots</strong></span> statement in
+<code class="filename">/etc/resolv.conf</code>.  It indicates the minimum
 number of dots in a relative domain name that should result in an
-exact match lookup before search path elements are appended.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1926"
->6.2.13. <B
-CLASS="command"
->masters</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
->&#13;<B
-CLASS="command"
->masters</B
-> <VAR
-CLASS="replaceable"
->name</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] { ( <VAR
-CLASS="replaceable"
->masters_list</VAR
-> | <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] [<SPAN
-CLASS="optional"
->key <VAR
-CLASS="replaceable"
->key</VAR
-></SPAN
->] ) ; [<SPAN
-CLASS="optional"
->...</SPAN
->] } ; 
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1941"
->6.2.14. <B
-CLASS="command"
->masters</B
-> Statement Definition and Usage</A
-></H2
-><P
-><B
-CLASS="command"
->masters</B
-> lists allow for a common set of masters
-to be easily used by multiple stub and slave zones.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN1946"
->6.2.15. <B
-CLASS="command"
->options</B
-> Statement Grammar</A
-></H2
-><P
->This is the grammar of the <B
-CLASS="command"
->options</B
->
-statement in the <TT
-CLASS="filename"
->named.conf</TT
-> file:</P
-><PRE
-CLASS="programlisting"
->options {
-    [<SPAN
-CLASS="optional"
-> version <VAR
-CLASS="replaceable"
->version_string</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> hostname <VAR
-CLASS="replaceable"
->hostname_string</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> server-id <VAR
-CLASS="replaceable"
->server_id_string</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> directory <VAR
-CLASS="replaceable"
->path_name</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> key-directory <VAR
-CLASS="replaceable"
->path_name</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> named-xfer <VAR
-CLASS="replaceable"
->path_name</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> tkey-domain <VAR
-CLASS="replaceable"
->domainname</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> tkey-dhkey <VAR
-CLASS="replaceable"
->key_name</VAR
-> <VAR
-CLASS="replaceable"
->key_tag</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> dump-file <VAR
-CLASS="replaceable"
->path_name</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> memstatistics-file <VAR
-CLASS="replaceable"
->path_name</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> pid-file <VAR
-CLASS="replaceable"
->path_name</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> statistics-file <VAR
-CLASS="replaceable"
->path_name</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> zone-statistics <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> auth-nxdomain <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> deallocate-on-exit <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> dialup <VAR
-CLASS="replaceable"
->dialup_option</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> fake-iquery <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> fetch-glue <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> flush-zones-on-shutdown <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> has-old-clients <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> host-statistics <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> host-statistics-max <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> minimal-responses <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> multiple-cnames <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> notify <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> | <VAR
-CLASS="replaceable"
->explicit</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> recursion <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> rfc2308-type1 <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> use-id-pool <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> maintain-ixfr-base <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> dnssec-enable <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> dnssec-lookaside <VAR
-CLASS="replaceable"
->domain</VAR
-> trust-anchor <VAR
-CLASS="replaceable"
->domain</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> dnssec-must-be-secure <VAR
-CLASS="replaceable"
->domain yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> forward ( <VAR
-CLASS="replaceable"
->only</VAR
-> | <VAR
-CLASS="replaceable"
->first</VAR
-> ); </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> forwarders { <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; ... </SPAN
->] }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> dual-stack-servers [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] { ( <VAR
-CLASS="replaceable"
->domain_name</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] | <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ) ; ... }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> check-names ( <VAR
-CLASS="replaceable"
->master</VAR
-> | <VAR
-CLASS="replaceable"
->slave</VAR
-> | <VAR
-CLASS="replaceable"
->response</VAR
-> )( <VAR
-CLASS="replaceable"
->warn</VAR
-> | <VAR
-CLASS="replaceable"
->fail</VAR
-> | <VAR
-CLASS="replaceable"
->ignore</VAR
-> ); </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-notify { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-query { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-transfer { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-recursion { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-update-forwarding { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-v6-synthesis { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> blackhole { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> avoid-v4-udp-ports { <VAR
-CLASS="replaceable"
->port_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> avoid-v6-udp-ports { <VAR
-CLASS="replaceable"
->port_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> listen-on [<SPAN
-CLASS="optional"
-> port <VAR
-CLASS="replaceable"
->ip_port</VAR
-> </SPAN
->] { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> listen-on-v6 [<SPAN
-CLASS="optional"
-> port <VAR
-CLASS="replaceable"
->ip_port</VAR
-> </SPAN
->] { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> query-source [<SPAN
-CLASS="optional"
-> address ( <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> | <VAR
-CLASS="replaceable"
->*</VAR
-> ) </SPAN
->] [<SPAN
-CLASS="optional"
-> port ( <VAR
-CLASS="replaceable"
->ip_port</VAR
-> | <VAR
-CLASS="replaceable"
->*</VAR
-> ) </SPAN
->]; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> query-source-v6 [<SPAN
-CLASS="optional"
-> address ( <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> | <VAR
-CLASS="replaceable"
->*</VAR
-> ) </SPAN
->] [<SPAN
-CLASS="optional"
-> port ( <VAR
-CLASS="replaceable"
->ip_port</VAR
-> | <VAR
-CLASS="replaceable"
->*</VAR
-> ) </SPAN
->]; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-transfer-time-in <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-transfer-time-out <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-transfer-idle-in <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-transfer-idle-out <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> tcp-clients <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> recursive-clients <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> serial-query-rate <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> serial-queries <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> tcp-listen-queue <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfer-format <VAR
-CLASS="replaceable"
->( one-answer | many-answers )</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfers-in  <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfers-out <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfers-per-ns <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfer-source (<VAR
-CLASS="replaceable"
->ip4_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfer-source-v6 (<VAR
-CLASS="replaceable"
->ip6_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> alt-transfer-source (<VAR
-CLASS="replaceable"
->ip4_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> alt-transfer-source-v6 (<VAR
-CLASS="replaceable"
->ip6_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> use-alt-transfer-source <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> notify-source (<VAR
-CLASS="replaceable"
->ip4_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> notify-source-v6 (<VAR
-CLASS="replaceable"
->ip6_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> also-notify { <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; ... </SPAN
->] }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-ixfr-log-size <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-journal-size <VAR
-CLASS="replaceable"
->size_spec</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> coresize <VAR
-CLASS="replaceable"
->size_spec</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> datasize <VAR
-CLASS="replaceable"
->size_spec</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> files <VAR
-CLASS="replaceable"
->size_spec</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> stacksize <VAR
-CLASS="replaceable"
->size_spec</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> cleaning-interval <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> heartbeat-interval <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> interface-interval <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> statistics-interval <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> topology { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }</SPAN
->];
-    [<SPAN
-CLASS="optional"
-> sortlist { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> }</SPAN
->];
-    [<SPAN
-CLASS="optional"
-> rrset-order { <VAR
-CLASS="replaceable"
->order_spec</VAR
-> ; [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->order_spec</VAR
-> ; ... </SPAN
->] </SPAN
->] };
-    [<SPAN
-CLASS="optional"
-> lame-ttl <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-ncache-ttl <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-cache-ttl <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> sig-validity-interval <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> min-roots <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> use-ixfr <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> provide-ixfr <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> request-ixfr <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> treat-cr-as-space <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> min-refresh-time <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-refresh-time <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> min-retry-time <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-retry-time <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> port <VAR
-CLASS="replaceable"
->ip_port</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> additional-from-auth <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> additional-from-cache <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> random-device <VAR
-CLASS="replaceable"
->path_name</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-cache-size <VAR
-CLASS="replaceable"
->size_spec</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> match-mapped-addresses <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> preferred-glue ( <VAR
-CLASS="replaceable"
->A</VAR
-> | <VAR
-CLASS="replaceable"
->AAAA</VAR
-> | <VAR
-CLASS="replaceable"
->NONE</VAR
-> ); </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> edns-udp-size <VAR
-CLASS="replaceable"
->number</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> root-delegation-only [<SPAN
-CLASS="optional"
-> exclude { <VAR
-CLASS="replaceable"
->namelist</VAR
-> } </SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> querylog <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> disable-algorithms <VAR
-CLASS="replaceable"
->domain</VAR
-> { <VAR
-CLASS="replaceable"
->algorithm</VAR
->; [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->algorithm</VAR
->; </SPAN
->] }; </SPAN
->]
+exact match lookup before search path elements are appended.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2554610"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">
+<span><strong class="command">masters</strong></span> <em class="replaceable"><code>name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] } ; 
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2554653"></a><span><strong class="command">masters</strong></span> Statement Definition and Usage </h3></div></div></div>
+<p><span><strong class="command">masters</strong></span> lists allow for a common set of masters
+to be easily used by multiple stub and slave zones.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2554668"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
+<p>This is the grammar of the <span><strong class="command">options</strong></span>
+statement in the <code class="filename">named.conf</code> file:</p>
+<pre class="programlisting">options {
+    [<span class="optional"> version <em class="replaceable"><code>version_string</code></em>; </span>]
+    [<span class="optional"> hostname <em class="replaceable"><code>hostname_string</code></em>; </span>]
+    [<span class="optional"> server-id <em class="replaceable"><code>server_id_string</code></em>; </span>]
+    [<span class="optional"> directory <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> key-directory <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> named-xfer <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> tkey-domain <em class="replaceable"><code>domainname</code></em>; </span>]
+    [<span class="optional"> tkey-dhkey <em class="replaceable"><code>key_name</code></em> <em class="replaceable"><code>key_tag</code></em>; </span>]
+    [<span class="optional"> dump-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> memstatistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> pid-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> statistics-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> auth-nxdomain <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> deallocate-on-exit <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em>; </span>]
+    [<span class="optional"> fake-iquery <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> fetch-glue <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> flush-zones-on-shutdown <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> has-old-clients <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> host-statistics <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> host-statistics-max <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> minimal-responses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> multiple-cnames <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em>; </span>]
+    [<span class="optional"> recursion <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> rfc2308-type1 <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> use-id-pool <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> dnssec-enable <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> dnssec-lookaside <em class="replaceable"><code>domain</code></em> trust-anchor <em class="replaceable"><code>domain</code></em>; </span>]
+    [<span class="optional"> dnssec-must-be-secure <em class="replaceable"><code>domain yes_or_no</code></em>; </span>]
+    [<span class="optional"> forward ( <em class="replaceable"><code>only</code></em> | <em class="replaceable"><code>first</code></em> ); </span>]
+    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> dual-stack-servers [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>domain_name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ) ; ... }; </span>]
+    [<span class="optional"> check-names ( <em class="replaceable"><code>master</code></em> | <em class="replaceable"><code>slave</code></em> | <em class="replaceable"><code>response</code></em> )( <em class="replaceable"><code>warn</code></em> | <em class="replaceable"><code>fail</code></em> | <em class="replaceable"><code>ignore</code></em> ); </span>]
+    [<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-recursion { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-v6-synthesis { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> blackhole { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> avoid-v4-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
+    [<span class="optional"> avoid-v6-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
+    [<span class="optional"> listen-on [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> listen-on-v6 [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em> </span>] { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> query-source [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
+    [<span class="optional"> query-source-v6 [<span class="optional"> address ( <em class="replaceable"><code>ip_addr</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>]; </span>]
+    [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> tcp-clients <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> recursive-clients <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> serial-query-rate <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> serial-queries <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> tcp-listen-queue <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em>; </span>]
+    [<span class="optional"> transfers-in  <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> transfers-out <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> transfers-per-ns <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-journal-size <em class="replaceable"><code>size_spec</code></em>; </span>]
+    [<span class="optional"> coresize <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> datasize <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> files <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> stacksize <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> cleaning-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> heartbeat-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> interface-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> statistics-interval <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> topology { <em class="replaceable"><code>address_match_list</code></em> }</span>];
+    [<span class="optional"> sortlist { <em class="replaceable"><code>address_match_list</code></em> }</span>];
+    [<span class="optional"> rrset-order { <em class="replaceable"><code>order_spec</code></em> ; [<span class="optional"> <em class="replaceable"><code>order_spec</code></em> ; ... </span>] </span>] };
+    [<span class="optional"> lame-ttl <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-ncache-ttl <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> max-cache-ttl <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> min-roots <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> use-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> treat-cr-as-space <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> port <em class="replaceable"><code>ip_port</code></em>; </span>]
+    [<span class="optional"> additional-from-auth <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> additional-from-cache <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> random-device <em class="replaceable"><code>path_name</code></em> ; </span>]
+    [<span class="optional"> max-cache-size <em class="replaceable"><code>size_spec</code></em> ; </span>]
+    [<span class="optional"> match-mapped-addresses <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> preferred-glue ( <em class="replaceable"><code>A</code></em> | <em class="replaceable"><code>AAAA</code></em> | <em class="replaceable"><code>NONE</code></em> ); </span>]
+    [<span class="optional"> edns-udp-size <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> root-delegation-only [<span class="optional"> exclude { <em class="replaceable"><code>namelist</code></em> } </span>] ; </span>]
+    [<span class="optional"> querylog <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> disable-algorithms <em class="replaceable"><code>domain</code></em> { <em class="replaceable"><code>algorithm</code></em>; [<span class="optional"> <em class="replaceable"><code>algorithm</code></em>; </span>] }; </span>]
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="options"
->6.2.16. <B
-CLASS="command"
->options</B
-> Statement Definition and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->options</B
-> statement sets up global options
-to be used by <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->. This statement may appear only
-once in a configuration file. If there is no <B
-CLASS="command"
->options</B
->
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="options"></a><span><strong class="command">options</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>The <span><strong class="command">options</strong></span> statement sets up global options
+to be used by <span class="acronym">BIND</span>. This statement may appear only
+once in a configuration file. If there is no <span><strong class="command">options</strong></span>
 statement, an options block with each option set to its default will
-be used.</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->directory</B
-></DT
-><DD
-><P
->The working directory of the server.
+be used.</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">directory</strong></span></span></dt>
+<dd><p>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. <TT
-CLASS="filename"
->named.run</TT
->) is this directory.
+output files (e.g. <code class="filename">named.run</code>) is this directory.
 If a directory is not specified, the working directory defaults
-to `<TT
-CLASS="filename"
->.</TT
->', the directory from which the server
-was started. The directory specified should be an absolute path.</P
-></DD
-><DT
-><B
-CLASS="command"
->key-directory</B
-></DT
-><DD
-><P
->When performing dynamic update of secure zones, the
+to `<code class="filename">.</code>', the directory from which the server
+was started. The directory specified should be an absolute path.</p></dd>
+<dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
+<dd><p>When performing dynamic update of secure zones, the
 directory where the public and private key files should be found,
 if different than the current working directory.  The directory specified
-must be an absolute path.</P
-></DD
-><DT
-><B
-CLASS="command"
->named-xfer</B
-></DT
-><DD
-><P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->This option is obsolete.</I
-></SPAN
->
-It was used in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 to
-specify the pathname to the <B
-CLASS="command"
->named-xfer</B
-> program.
-In <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9, no separate <B
-CLASS="command"
->named-xfer</B
-> program is
-needed; its functionality is built into the name server.</P
-></DD
-><DT
-><B
-CLASS="command"
->tkey-domain</B
-></DT
-><DD
-><P
->The domain appended to the names of all
-shared keys generated with <B
-CLASS="command"
->TKEY</B
->. When a client
-requests a <B
-CLASS="command"
->TKEY</B
-> exchange, it may or may not specify
+must be an absolute path.</p></dd>
+<dt><span class="term"><span><strong class="command">named-xfer</strong></span></span></dt>
+<dd><p><span class="emphasis"><em>This option is obsolete.</em></span>
+It was used in <span class="acronym">BIND</span> 8 to
+specify the pathname to the <span><strong class="command">named-xfer</strong></span> program.
+In <span class="acronym">BIND</span> 9, no separate <span><strong class="command">named-xfer</strong></span> program is
+needed; its functionality is built into the name server.</p></dd>
+<dt><span class="term"><span><strong class="command">tkey-domain</strong></span></span></dt>
+<dd><p>The domain appended to the names of all
+shared keys generated with <span><strong class="command">TKEY</strong></span>. When a client
+requests a <span><strong class="command">TKEY</strong></span> exchange, it may or may not specify
 the desired name for the key. If present, the name of the shared
-key will be "<VAR
-CLASS="varname"
->client specified part</VAR
->" + 
-"<VAR
-CLASS="varname"
->tkey-domain</VAR
->".
-Otherwise, the name of the shared key will be "<VAR
-CLASS="varname"
->random hex
-digits</VAR
->" + "<VAR
-CLASS="varname"
->tkey-domain</VAR
->". In most cases,
-the <B
-CLASS="command"
->domainname</B
-> should be the server's domain
-name.</P
-></DD
-><DT
-><B
-CLASS="command"
->tkey-dhkey</B
-></DT
-><DD
-><P
->The Diffie-Hellman key used by the server
+key will be "<code class="varname">client specified part</code>" + 
+"<code class="varname">tkey-domain</code>".
+Otherwise, the name of the shared key will be "<code class="varname">random hex
+digits</code>" + "<code class="varname">tkey-domain</code>". In most cases,
+the <span><strong class="command">domainname</strong></span> should be the server's domain
+name.</p></dd>
+<dt><span class="term"><span><strong class="command">tkey-dhkey</strong></span></span></dt>
+<dd><p>The Diffie-Hellman key used by the server
 to generate shared keys with clients using the Diffie-Hellman mode
-of <B
-CLASS="command"
->TKEY</B
->. The server must be able to load the
+of <span><strong class="command">TKEY</strong></span>. 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
-></DD
-><DT
-><B
-CLASS="command"
->dump-file</B
-></DT
-><DD
-><P
->The pathname of the file the server dumps
+most cases, the keyname should be the server's host name.</p></dd>
+<dt><span class="term"><span><strong class="command">dump-file</strong></span></span></dt>
+<dd><p>The pathname of the file the server dumps
 the database to when instructed to do so with
-<B
-CLASS="command"
->rndc dumpdb</B
->.
-If not specified, the default is <TT
-CLASS="filename"
->named_dump.db</TT
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->memstatistics-file</B
-></DT
-><DD
-><P
->The pathname of the file the server writes memory
+<span><strong class="command">rndc dumpdb</strong></span>.
+If not specified, the default is <code class="filename">named_dump.db</code>.</p></dd>
+<dt><span class="term"><span><strong class="command">memstatistics-file</strong></span></span></dt>
+<dd><p>The pathname of the file the server writes memory
 usage statistics to on exit. If not specified,
-the default is <TT
-CLASS="filename"
->named.memstats</TT
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->pid-file</B
-></DT
-><DD
-><P
->The pathname of the file the server writes its process ID
-in. If not specified, the default is <TT
-CLASS="filename"
->/var/run/named.pid</TT
->.
+the default is <code class="filename">named.memstats</code>.</p></dd>
+<dt><span class="term"><span><strong class="command">pid-file</strong></span></span></dt>
+<dd><p>The pathname of the file the server writes its process ID
+in. If not specified, the default is <code class="filename">/var/run/named.pid</code>.
 The pid-file is used by programs that want to send signals to the running
-name server. Specifying <B
-CLASS="command"
->pid-file none</B
-> disables the
+name server. Specifying <span><strong class="command">pid-file none</strong></span> disables the
 use of a PID file &#8212; no file will be written and any
-existing one will be removed.  Note that <B
-CLASS="command"
->none</B
->
+existing one will be removed.  Note that <span><strong class="command">none</strong></span>
 is a keyword, not a file name, and therefore is not enclosed in
-double quotes.</P
-></DD
-><DT
-><B
-CLASS="command"
->statistics-file</B
-></DT
-><DD
-><P
->The pathname of the file the server appends statistics
-to when instructed to do so using <B
-CLASS="command"
->rndc stats</B
->.
-If not specified, the default is <TT
-CLASS="filename"
->named.stats</TT
-> in the
+double quotes.</p></dd>
+<dt><span class="term"><span><strong class="command">statistics-file</strong></span></span></dt>
+<dd><p>The pathname of the file the server appends statistics
+to when instructed to do so using <span><strong class="command">rndc stats</strong></span>.
+If not specified, the default is <code class="filename">named.stats</code> in the
 server's current directory.  The format of the file is described
-in <A
-HREF="Bv9ARM.ch06.html#statsfile"
->Section 6.2.16.17</A
-></P
-></DD
-><DT
-><B
-CLASS="command"
->port</B
-></DT
-><DD
-><P
->&#13;The UDP/TCP port number the server uses for 
+in <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called &#8220;The Statistics File&#8221;</a></p></dd>
+<dt><span class="term"><span><strong class="command">port</strong></span></span></dt>
+<dd><p>
+The UDP/TCP port number the server uses for 
 receiving and sending DNS protocol traffic.
 The default is 53.  This option is mainly intended for server testing;
 a server using a port other than 53 will not be able to communicate with
 the global DNS.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->random-device</B
-></DT
-><DD
-><P
->&#13;The source of entropy to be used by the server.  Entropy is primarily needed
+</p></dd>
+<dt><span class="term"><span><strong class="command">random-device</strong></span></span></dt>
+<dd><p>
+The source of entropy to be used by the server.  Entropy is primarily needed
 for DNSSEC operations, such as TKEY transactions and dynamic update of signed
 zones.  This options specifies the device (or file) from which to read
 entropy.  If this is a file, operations requiring entropy will fail when the
 file has been exhausted.  If not specified, the default value is
-<TT
-CLASS="filename"
->/dev/random</TT
->
+<code class="filename">/dev/random</code>
 (or equivalent) when present, and none otherwise.  The
-<B
-CLASS="command"
->random-device</B
-> option takes effect during
+<span><strong class="command">random-device</strong></span> option takes effect during
 the initial configuration load at server startup time and
-is ignored on subsequent reloads.</P
-></DD
-><DT
-><B
-CLASS="command"
->preferred-glue</B
-></DT
-><DD
-><P
->&#13;If specified the listed type (A or AAAA) will be emitted before other glue
+is ignored on subsequent reloads.</p></dd>
+<dt><span class="term"><span><strong class="command">preferred-glue</strong></span></span></dt>
+<dd><p>
+If specified the listed type (A or AAAA) will be emitted before other glue
 in the additional section of a query response.
 The default is not to preference any type (NONE).
-</P
-></DD
-><DT
-><B
-CLASS="command"
->root-delegation-only</B
-></DT
-><DD
-><P
->&#13;Turn on enforcement of delegation-only in TLDs and root zones with an optional
+</p></dd>
+<dt><span class="term"><span><strong class="command">root-delegation-only</strong></span></span></dt>
+<dd>
+<p>
+Turn on enforcement of delegation-only in TLDs and root zones with an optional
 exclude list.
-</P
-><P
->&#13;Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM").
-</P
-><PRE
-CLASS="programlisting"
->&#13;options {
+</p>
+<p>
+Note some TLDs are NOT delegation only (e.g. "DE", "LV", "US" and "MUSEUM").
+</p>
+<pre class="programlisting">
+options {
 	root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
 };
-</PRE
-></DD
-><DT
-><B
-CLASS="command"
->disable-algorithms</B
-></DT
-><DD
-><P
->&#13;Disable the specified DNSSEC algorithms at and below the specified name.
-Multiple <B
-CLASS="command"
->disable-algorithms</B
-> statements are allowed.
+</pre>
+</dd>
+<dt><span class="term"><span><strong class="command">disable-algorithms</strong></span></span></dt>
+<dd><p>
+Disable the specified DNSSEC algorithms at and below the specified name.
+Multiple <span><strong class="command">disable-algorithms</strong></span> statements are allowed.
 Only the most specific will be applied.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->dnssec-lookaside</B
-></DT
-><DD
-><P
->&#13;When set <B
-CLASS="command"
->dnssec-lookaside</B
-> provides the
+</p></dd>
+<dt><span class="term"><span><strong class="command">dnssec-lookaside</strong></span></span></dt>
+<dd><p>
+When set <span><strong class="command">dnssec-lookaside</strong></span> provides the
 validator with an alternate method to validate DNSKEY records at the
 top of a zone.  When a DNSKEY is at or below a domain specified by the
-deepest <B
-CLASS="command"
->dnssec-lookaside</B
->, and the normal dnssec validation
+deepest <span><strong class="command">dnssec-lookaside</strong></span>, and the normal dnssec validation
 has left the key untrusted, the trust-anchor will be append to the key
 name and a DLV record will be looked up to see if it can validate the
 key.  If the DLV record validates a DNSKEY (similarly to the way a DS
 record does) the DNSKEY RRset is deemed to be trusted.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->dnssec-must-be-secure</B
-></DT
-><DD
-><P
->&#13;Specify heirachies which must / may not be secure (signed and validated).
-If <KBD
-CLASS="userinput"
->yes</KBD
-> then named will only accept answers if they
+</p></dd>
+<dt><span class="term"><span><strong class="command">dnssec-must-be-secure</strong></span></span></dt>
+<dd><p>
+Specify heirarchies which must / may not be secure (signed and validated).
+If <strong class="userinput"><code>yes</code></strong> then named will only accept answers if they
 are secure.
-If <KBD
-CLASS="userinput"
->no</KBD
-> then normal dnssec validation applies
+If <strong class="userinput"><code>no</code></strong> then normal dnssec validation applies
 allowing for insecure answers to be accepted.
-The specified domain must be under a <B
-CLASS="command"
->trusted-key</B
-> or
-<B
-CLASS="command"
->dnssec-lookaside</B
-> must be active.
-</P
-></DD
-></DL
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="boolean_options"
->6.2.16.1. Boolean Options</A
-></H3
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->auth-nxdomain</B
-></DT
-><DD
-><P
->If <KBD
-CLASS="userinput"
->yes</KBD
->, then the <B
-CLASS="command"
->AA</B
-> bit
+The specified domain must be under a <span><strong class="command">trusted-key</strong></span> or
+<span><strong class="command">dnssec-lookaside</strong></span> must be active.
+</p></dd>
+</dl></div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="boolean_options"></a>Boolean Options</h4></div></div></div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">auth-nxdomain</strong></span></span></dt>
+<dd><p>If <strong class="userinput"><code>yes</code></strong>, then the <span><strong class="command">AA</strong></span> bit
 is always set on NXDOMAIN responses, even if the server is not actually
-authoritative. The default is <KBD
-CLASS="userinput"
->no</KBD
->; this is
-a change from <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8. If you are using very old DNS software, you
-may need to set it to <KBD
-CLASS="userinput"
->yes</KBD
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->deallocate-on-exit</B
-></DT
-><DD
-><P
->This option was used in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 to enable checking
-for memory leaks on exit. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 ignores the option and always performs
-the checks.</P
-></DD
-><DT
-><B
-CLASS="command"
->dialup</B
-></DT
-><DD
-><P
->If <KBD
-CLASS="userinput"
->yes</KBD
->, then the
+authoritative. The default is <strong class="userinput"><code>no</code></strong>; this is
+a change from <span class="acronym">BIND</span> 8. If you are using very old DNS software, you
+may need to set it to <strong class="userinput"><code>yes</code></strong>.</p></dd>
+<dt><span class="term"><span><strong class="command">deallocate-on-exit</strong></span></span></dt>
+<dd><p>This option was used in <span class="acronym">BIND</span> 8 to enable checking
+for memory leaks on exit. <span class="acronym">BIND</span> 9 ignores the option and always performs
+the checks.</p></dd>
+<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
+<dd>
+<p>If <strong class="userinput"><code>yes</code></strong>, 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 <B
-CLASS="command"
->heartbeat-interval</B
-> and
+happens in a short interval, once every <span><strong class="command">heartbeat-interval</strong></span> and
 hopefully during the one call. It also suppresses some of the normal
-zone maintenance traffic. The default is <KBD
-CLASS="userinput"
->no</KBD
->.</P
-><P
->The <B
-CLASS="command"
->dialup</B
-> option
-may also be specified in the <B
-CLASS="command"
->view</B
-> and 
-<B
-CLASS="command"
->zone</B
-> statements,
-in which case it overrides the global <B
-CLASS="command"
->dialup</B
->
-option.</P
-><P
->If the zone is a master zone then the server will send out a NOTIFY 
+zone maintenance traffic. The default is <strong class="userinput"><code>no</code></strong>.</p>
+<p>The <span><strong class="command">dialup</strong></span> option
+may also be specified in the <span><strong class="command">view</strong></span> and 
+<span><strong class="command">zone</strong></span> statements,
+in which case it overrides the global <span><strong class="command">dialup</strong></span>
+option.</p>
+<p>If the zone is a master zone then the server will send out a NOTIFY 
 request to all the slaves (default). This should trigger the zone serial
 number check in the slave (providing it supports NOTIFY) allowing the slave
 to verify the zone while the connection is active.
 The set of servers to which NOTIFY is sent can be controlled by
-<B
-CLASS="command"
->notify</B
-> and <B
-CLASS="command"
->also-notify</B
->.</P
-><P
->If the
+<span><strong class="command">notify</strong></span> and <span><strong class="command">also-notify</strong></span>.</p>
+<p>If the
 zone is a slave or stub zone, then the server will suppress the regular
 "zone up to date" (refresh) queries and only perform them when the
-<B
-CLASS="command"
->heartbeat-interval</B
-> expires in addition to sending
-NOTIFY requests.</P
-><P
->Finer control can be achieved by using
-<KBD
-CLASS="userinput"
->notify</KBD
-> which only sends NOTIFY messages,
-<KBD
-CLASS="userinput"
->notify-passive</KBD
-> which sends NOTIFY messages and
-suppresses the normal refresh queries, <KBD
-CLASS="userinput"
->refresh</KBD
->
+<span><strong class="command">heartbeat-interval</strong></span> expires in addition to sending
+NOTIFY requests.</p>
+<p>Finer control can be achieved by using
+<strong class="userinput"><code>notify</code></strong> which only sends NOTIFY messages,
+<strong class="userinput"><code>notify-passive</code></strong> which sends NOTIFY messages and
+suppresses the normal refresh queries, <strong class="userinput"><code>refresh</code></strong>
 which suppresses normal refresh processing and sends refresh queries 
-when the <B
-CLASS="command"
->heartbeat-interval</B
-> expires, and
-<KBD
-CLASS="userinput"
->passive</KBD
-> which just disables normal refresh
-processing.</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN2402"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
->dialup mode</P
-></TD
-><TD
-><P
->normal refresh</P
-></TD
-><TD
-><P
->heart-beat refresh</P
-></TD
-><TD
-><P
->heart-beat notify</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->no</B
-> (default)</P
-></TD
-><TD
-><P
->yes</P
-></TD
-><TD
-><P
->no</P
-></TD
-><TD
-><P
->no</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->yes</B
-></P
-></TD
-><TD
-><P
->no</P
-></TD
-><TD
-><P
->yes</P
-></TD
-><TD
-><P
->yes</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->notify</B
-></P
-></TD
-><TD
-><P
->yes</P
-></TD
-><TD
-><P
->no</P
-></TD
-><TD
-><P
->yes</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->refresh</B
-></P
-></TD
-><TD
-><P
->no</P
-></TD
-><TD
-><P
->yes</P
-></TD
-><TD
-><P
->no</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->passive</B
-></P
-></TD
-><TD
-><P
->no</P
-></TD
-><TD
-><P
->no</P
-></TD
-><TD
-><P
->no</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->notify-passive</B
-></P
-></TD
-><TD
-><P
->no</P
-></TD
-><TD
-><P
->no</P
-></TD
-><TD
-><P
->yes</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->Note that normal NOTIFY processing is not affected by
-<B
-CLASS="command"
->dialup</B
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->fake-iquery</B
-></DT
-><DD
-><P
->In <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8, this option
+when the <span><strong class="command">heartbeat-interval</strong></span> expires, and
+<strong class="userinput"><code>passive</code></strong> which just disables normal refresh
+processing.</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p>dialup mode</p></td>
+<td><p>normal refresh</p></td>
+<td><p>heart-beat refresh</p></td>
+<td><p>heart-beat notify</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">no</strong></span> (default)</p></td>
+<td><p>yes</p></td>
+<td><p>no</p></td>
+<td><p>no</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">yes</strong></span></p></td>
+<td><p>no</p></td>
+<td><p>yes</p></td>
+<td><p>yes</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">notify</strong></span></p></td>
+<td><p>yes</p></td>
+<td><p>no</p></td>
+<td><p>yes</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">refresh</strong></span></p></td>
+<td><p>no</p></td>
+<td><p>yes</p></td>
+<td><p>no</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">passive</strong></span></p></td>
+<td><p>no</p></td>
+<td><p>no</p></td>
+<td><p>no</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">notify-passive</strong></span></p></td>
+<td><p>no</p></td>
+<td><p>no</p></td>
+<td><p>yes</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>Note that normal NOTIFY processing is not affected by
+<span><strong class="command">dialup</strong></span>.</p>
+</dd>
+<dt><span class="term"><span><strong class="command">fake-iquery</strong></span></span></dt>
+<dd><p>In <span class="acronym">BIND</span> 8, this option
 enabled simulating the obsolete DNS query type
-IQUERY. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 never does IQUERY simulation.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->fetch-glue</B
-></DT
-><DD
-><P
->This option is obsolete.
-In BIND 8, <KBD
-CLASS="userinput"
->fetch-glue yes</KBD
->
+IQUERY. <span class="acronym">BIND</span> 9 never does IQUERY simulation.
+</p></dd>
+<dt><span class="term"><span><strong class="command">fetch-glue</strong></span></span></dt>
+<dd><p>This option is obsolete.
+In BIND 8, <strong class="userinput"><code>fetch-glue yes</code></strong>
 caused the server to attempt to fetch glue resource records it
 didn't have when constructing the additional
 data section of a response.  This is now considered a bad idea
-and BIND 9 never does it.</P
-></DD
-><DT
-><B
-CLASS="command"
->flush-zones-on-shutdown</B
-></DT
-><DD
-><P
->When the nameserver exits due receiving SIGTERM,
+and BIND 9 never does it.</p></dd>
+<dt><span class="term"><span><strong class="command">flush-zones-on-shutdown</strong></span></span></dt>
+<dd><p>When the nameserver exits due receiving SIGTERM,
 flush / do not flush any pending zone writes.  The default is
-<B
-CLASS="command"
->flush-zones-on-shutdown</B
-> <KBD
-CLASS="userinput"
->no</KBD
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->has-old-clients</B
-></DT
-><DD
-><P
->This option was incorrectly implemented
-in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8, and is ignored by <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9.
+<span><strong class="command">flush-zones-on-shutdown</strong></span> <strong class="userinput"><code>no</code></strong>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">has-old-clients</strong></span></span></dt>
+<dd><p>This option was incorrectly implemented
+in <span class="acronym">BIND</span> 8, and is ignored by <span class="acronym">BIND</span> 9.
 To achieve the intended effect
 of
-<B
-CLASS="command"
->has-old-clients</B
-> <KBD
-CLASS="userinput"
->yes</KBD
->, specify
-the two separate options <B
-CLASS="command"
->auth-nxdomain</B
-> <KBD
-CLASS="userinput"
->yes</KBD
->
-and <B
-CLASS="command"
->rfc2308-type1</B
-> <KBD
-CLASS="userinput"
->no</KBD
-> instead.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->host-statistics</B
-></DT
-><DD
-><P
->In BIND 8, this enables keeping of
+<span><strong class="command">has-old-clients</strong></span> <strong class="userinput"><code>yes</code></strong>, specify
+the two separate options <span><strong class="command">auth-nxdomain</strong></span> <strong class="userinput"><code>yes</code></strong>
+and <span><strong class="command">rfc2308-type1</strong></span> <strong class="userinput"><code>no</code></strong> instead.
+</p></dd>
+<dt><span class="term"><span><strong class="command">host-statistics</strong></span></span></dt>
+<dd><p>In BIND 8, this enables keeping of
 statistics for every host that the name server interacts with.
 Not implemented in BIND 9.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->maintain-ixfr-base</B
-></DT
-><DD
-><P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->This option is obsolete</I
-></SPAN
->.
- It was used in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 to determine whether a transaction log was
-kept for Incremental Zone Transfer. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 maintains a transaction
+</p></dd>
+<dt><span class="term"><span><strong class="command">maintain-ixfr-base</strong></span></span></dt>
+<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
+ It was used in <span class="acronym">BIND</span> 8 to determine whether a transaction log was
+kept for Incremental Zone Transfer. <span class="acronym">BIND</span> 9 maintains a transaction
 log whenever possible.  If you need to disable outgoing incremental zone
-transfers, use <B
-CLASS="command"
->provide-ixfr</B
-> <KBD
-CLASS="userinput"
->no</KBD
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->minimal-responses</B
-></DT
-><DD
-><P
->If <KBD
-CLASS="userinput"
->yes</KBD
->, then when generating
+transfers, use <span><strong class="command">provide-ixfr</strong></span> <strong class="userinput"><code>no</code></strong>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">minimal-responses</strong></span></span></dt>
+<dd><p>If <strong class="userinput"><code>yes</code></strong>, then when generating
 responses the server will only add records to the authority and
 additional data sections when they are required (e.g. delegations,
 negative responses).  This may improve the performance of the server.
-The default is <KBD
-CLASS="userinput"
->no</KBD
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->multiple-cnames</B
-></DT
-><DD
-><P
->This option was used in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 to allow
+The default is <strong class="userinput"><code>no</code></strong>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">multiple-cnames</strong></span></span></dt>
+<dd><p>This option was used in <span class="acronym">BIND</span> 8 to allow
 a domain name to have multiple CNAME records in violation of the
-DNS standards.  <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9.2 always strictly
+DNS standards.  <span class="acronym">BIND</span> 9.2 always strictly
 enforces the CNAME rules both in master files and dynamic updates.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->notify</B
-></DT
-><DD
-><P
->If <KBD
-CLASS="userinput"
->yes</KBD
-> (the default),
+</p></dd>
+<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
+<dd>
+<p>If <strong class="userinput"><code>yes</code></strong> (the default),
 DNS NOTIFY messages are sent when a zone the server is authoritative for
-changes, see <A
-HREF="Bv9ARM.ch04.html#notify"
->Section 4.1</A
->.  The messages are sent to the
+changes, see <a href="Bv9ARM.ch04.html#notify" title="Notify">the section called &#8220;Notify&#8221;</a>.  The messages are sent to the
 servers listed in the zone's NS records (except the master server identified
 in the SOA MNAME field), and to any servers listed in the
-<B
-CLASS="command"
->also-notify</B
-> option.
-</P
-><P
->&#13;If <KBD
-CLASS="userinput"
->explicit</KBD
->, notifies are sent only to
-servers explicitly listed using <B
-CLASS="command"
->also-notify</B
->.
-If <KBD
-CLASS="userinput"
->no</KBD
->, no notifies are sent.
-</P
-><P
->&#13;The <B
-CLASS="command"
->notify</B
-> option may also be
-specified in the <B
-CLASS="command"
->zone</B
-> statement,
-in which case it overrides the <B
-CLASS="command"
->options notify</B
-> statement.
+<span><strong class="command">also-notify</strong></span> option.
+</p>
+<p>
+If <strong class="userinput"><code>explicit</code></strong>, notifies are sent only to
+servers explicitly listed using <span><strong class="command">also-notify</strong></span>.
+If <strong class="userinput"><code>no</code></strong>, no notifies are sent.
+</p>
+<p>
+The <span><strong class="command">notify</strong></span> option may also be
+specified in the <span><strong class="command">zone</strong></span> statement,
+in which case it overrides the <span><strong class="command">options notify</strong></span> statement.
 It would only be necessary to turn off this option if it caused slaves
-to crash.</P
-></DD
-><DT
-><B
-CLASS="command"
->recursion</B
-></DT
-><DD
-><P
->If <KBD
-CLASS="userinput"
->yes</KBD
->, and a
+to crash.</p>
+</dd>
+<dt><span class="term"><span><strong class="command">recursion</strong></span></span></dt>
+<dd><p>If <strong class="userinput"><code>yes</code></strong>, and a
 DNS query requests recursion, then the server will attempt to do
 all the work required to answer the query. If recursion is off
 and the server does not already know the answer, it will return a
-referral response. The default is <KBD
-CLASS="userinput"
->yes</KBD
->.
-Note that setting <B
-CLASS="command"
->recursion no</B
-> does not prevent
+referral response. The default is <strong class="userinput"><code>yes</code></strong>.
+Note that setting <span><strong class="command">recursion no</strong></span> does not prevent
 clients from getting data from the server's cache; it only
 prevents new data from being cached as an effect of client queries.
 Caching may still occur as an effect the server's internal
 operation, such as NOTIFY address lookups.
-See also <B
-CLASS="command"
->fetch-glue</B
-> above.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->rfc2308-type1</B
-></DT
-><DD
-><P
->Setting this to <KBD
-CLASS="userinput"
->yes</KBD
-> will
+See also <span><strong class="command">fetch-glue</strong></span> above.
+</p></dd>
+<dt><span class="term"><span><strong class="command">rfc2308-type1</strong></span></span></dt>
+<dd>
+<p>Setting this to <strong class="userinput"><code>yes</code></strong> will
 cause the server to send NS records along with the SOA record for negative
-answers. The default is <KBD
-CLASS="userinput"
->no</KBD
->.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9.</P
-></BLOCKQUOTE
-></DIV
-></DD
-><DT
-><B
-CLASS="command"
->use-id-pool</B
-></DT
-><DD
-><P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->This option is obsolete</I
-></SPAN
->.
-<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 always allocates query IDs from a pool.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->zone-statistics</B
-></DT
-><DD
-><P
->If <KBD
-CLASS="userinput"
->yes</KBD
->, the server will collect
+answers. The default is <strong class="userinput"><code>no</code></strong>.</p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>Not yet implemented in <span class="acronym">BIND</span> 9.</p>
+</div>
+</dd>
+<dt><span class="term"><span><strong class="command">use-id-pool</strong></span></span></dt>
+<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
+<span class="acronym">BIND</span> 9 always allocates query IDs from a pool.
+</p></dd>
+<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
+<dd><p>If <strong class="userinput"><code>yes</code></strong>, the server will collect
 statistical data on all zones (unless specifically turned off
-on a per-zone basis by specifying <B
-CLASS="command"
->zone-statistics no</B
->
-in the <B
-CLASS="command"
->zone</B
-> statement).  These statistics may be accessed
-using <B
-CLASS="command"
->rndc stats</B
->, which will dump them to the file listed
-in the <B
-CLASS="command"
->statistics-file</B
->.  See also <A
-HREF="Bv9ARM.ch06.html#statsfile"
->Section 6.2.16.17</A
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->use-ixfr</B
-></DT
-><DD
-><P
-><SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->This option is obsolete</I
-></SPAN
->.
+on a per-zone basis by specifying <span><strong class="command">zone-statistics no</strong></span>
+in the <span><strong class="command">zone</strong></span> statement).  These statistics may be accessed
+using <span><strong class="command">rndc stats</strong></span>, which will dump them to the file listed
+in the <span><strong class="command">statistics-file</strong></span>.  See also <a href="Bv9ARM.ch06.html#statsfile" title="The Statistics File">the section called &#8220;The Statistics File&#8221;</a>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">use-ixfr</strong></span></span></dt>
+<dd><p><span class="emphasis"><em>This option is obsolete</em></span>.
 If you need to disable IXFR to a particular server or servers see
-the information on the <B
-CLASS="command"
->provide-ixfr</B
-> option
-in <A
-HREF="Bv9ARM.ch06.html#server_statement_definition_and_usage"
->Section 6.2.18</A
->. See also
-<A
-HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
->Section 4.3</A
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->provide-ixfr</B
-></DT
-><DD
-><P
->&#13;See the description of
-<B
-CLASS="command"
->provide-ixfr</B
-> in
-<A
-HREF="Bv9ARM.ch06.html#server_statement_definition_and_usage"
->Section 6.2.18</A
->
-</P
-></DD
-><DT
-><B
-CLASS="command"
->request-ixfr</B
-></DT
-><DD
-><P
->&#13;See the description of
-<B
-CLASS="command"
->request-ixfr</B
-> in
-<A
-HREF="Bv9ARM.ch06.html#server_statement_definition_and_usage"
->Section 6.2.18</A
->
-</P
-></DD
-><DT
-><B
-CLASS="command"
->treat-cr-as-space</B
-></DT
-><DD
-><P
->This option was used in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 to make
-the server treat carriage return ("<B
-CLASS="command"
->\r</B
->") characters the same way
+the information on the <span><strong class="command">provide-ixfr</strong></span> option
+in <a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and Usage&#8221;</a>. See also
+<a href="Bv9ARM.ch04.html#incremental_zone_transfers" title="Incremental Zone Transfers (IXFR)">the section called &#8220;Incremental Zone Transfers (IXFR)&#8221;</a>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">provide-ixfr</strong></span></span></dt>
+<dd><p>
+See the description of
+<span><strong class="command">provide-ixfr</strong></span> in
+<a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and Usage&#8221;</a>
+</p></dd>
+<dt><span class="term"><span><strong class="command">request-ixfr</strong></span></span></dt>
+<dd><p>
+See the description of
+<span><strong class="command">request-ixfr</strong></span> in
+<a href="Bv9ARM.ch06.html#server_statement_definition_and_usage" title="server Statement Definition and Usage">the section called &#8220;<span><strong class="command">server</strong></span> Statement Definition and Usage&#8221;</a>
+</p></dd>
+<dt><span class="term"><span><strong class="command">treat-cr-as-space</strong></span></span></dt>
+<dd><p>This option was used in <span class="acronym">BIND</span> 8 to make
+the server treat carriage return ("<span><strong class="command">\r</strong></span>") characters the same way
 as a space or tab character,
 to facilitate loading of zone files on a UNIX system that were generated
-on an NT or DOS machine. In <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9, both UNIX "<B
-CLASS="command"
->\n</B
->"
-and NT/DOS "<B
-CLASS="command"
->\r\n</B
->" newlines are always accepted,
-and the option is ignored.</P
-></DD
-><DT
-><B
-CLASS="command"
->additional-from-auth</B
->, <B
-CLASS="command"
->additional-from-cache</B
-></DT
-><DD
-><P
->&#13;These options control the behavior of an authoritative server when
+on an NT or DOS machine. In <span class="acronym">BIND</span> 9, both UNIX "<span><strong class="command">\n</strong></span>"
+and NT/DOS "<span><strong class="command">\r\n</strong></span>" newlines are always accepted,
+and the option is ignored.</p></dd>
+<dt>
+<span class="term"><span><strong class="command">additional-from-auth</strong></span>, </span><span class="term"><span><strong class="command">additional-from-cache</strong></span></span>
+</dt>
+<dd>
+<p>
+These options control the behavior of an authoritative server when
 answering queries which have additional data, or when following CNAME
 and DNAME chains.
-</P
-><P
->&#13;When both of these options are set to <KBD
-CLASS="userinput"
->yes</KBD
-> 
+</p>
+<p>
+When both of these options are set to <strong class="userinput"><code>yes</code></strong> 
 (the default) and a
 query is being answered from authoritative data (a zone
 configured into the server), the additional data section of the
@@ -5129,76 +1583,43 @@ untrusted third parties.  Also, avoiding
 the search for this additional data will speed up server operations
 at the possible expense of additional queries to resolve what would
 otherwise be provided in the additional section.
-</P
-><P
->&#13;For example, if a query asks for an MX record for host <VAR
-CLASS="literal"
->foo.example.com</VAR
->,
-and the record found is "<VAR
-CLASS="literal"
->MX 10 mail.example.net</VAR
->", normally the address
-records (A and AAAA) for <VAR
-CLASS="literal"
->mail.example.net</VAR
-> will be provided as well,
+</p>
+<p>
+For example, if a query asks for an MX record for host <code class="literal">foo.example.com</code>,
+and the record found is "<code class="literal">MX 10 mail.example.net</code>", normally the address
+records (A and AAAA) for <code class="literal">mail.example.net</code> will be provided as well,
 if known, even though they are not in the example.com zone.
-Setting these options to <B
-CLASS="command"
->no</B
-> disables this behavior and makes
+Setting these options to <span><strong class="command">no</strong></span> disables this behavior and makes
 the server only search for additional data in the zone it answers from.
-</P
-><P
->&#13;These options are intended for use in authoritative-only 
+</p>
+<p>
+These options are intended for use in authoritative-only 
 servers, or in authoritative-only views.  Attempts to set
-them to <B
-CLASS="command"
->no</B
-> without also specifying
-<B
-CLASS="command"
->recursion no</B
-> will cause the server to
+them to <span><strong class="command">no</strong></span> without also specifying
+<span><strong class="command">recursion no</strong></span> will cause the server to
 ignore the options and log a warning message.
-</P
-><P
->&#13;Specifying <B
-CLASS="command"
->additional-from-cache no</B
-> actually
+</p>
+<p>
+Specifying <span><strong class="command">additional-from-cache no</strong></span> actually
 disables the use of the cache not only for additional data lookups
 but also when looking up the answer.  This is usually the desired
 behavior in an authoritative-only server where the correctness of
 the cached data is an issue.
-</P
-><P
->&#13;When a name server is non-recursively queried for a name that is not
+</p>
+<p>
+When a name server is non-recursively queried for a name that is not
 below the apex of any served zone, it normally answers with an
 "upwards referral" to the root servers or the servers of some other
 known parent of the query name.  Since the data in an upwards referral
 comes from the cache, the server will not be able to provide upwards
-referrals when <B
-CLASS="command"
->additional-from-cache no</B
->
+referrals when <span><strong class="command">additional-from-cache no</strong></span>
 has been specified.  Instead, it will respond to such queries
 with REFUSED.  This should not cause any problems since
 upwards referrals are not required for the resolution process.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->match-mapped-addresses</B
-></DT
-><DD
-><P
->If <KBD
-CLASS="userinput"
->yes</KBD
->, then an
+</p>
+</dd>
+<dt><span class="term"><span><strong class="command">match-mapped-addresses</strong></span></span></dt>
+<dd><p>If <strong class="userinput"><code>yes</code></strong>, then an
 IPv4-mapped IPv6 address will match any address match
 list entries that match the corresponding IPv4 address.
 Enabling this option is sometimes useful on IPv6-enabled Linux
@@ -5207,25 +1628,20 @@ TCP connections such as zone transfers to be accepted
 on an IPv6 socket using mapped addresses, causing
 address match lists designed for IPv4 to fail to match.
 The use of this option for any other purpose is discouraged.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->ixfr-from-differences</B
-></DT
-><DD
-><P
->&#13;When 'yes' and the server loads a new version of a master
+</p></dd>
+<dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt>
+<dd>
+<p>
+When 'yes' and the server loads a new version of a master
 zone from its zone file or receives a new version of a slave
 file by a non-incremental zone transfer, it will compare
 the new version to the previous one and calculate a set
 of differences.  The differences are then logged in the
 zone's journal file such that the changes can be transmitted
 to downstream slaves as an incremental zone transfer.
-</P
-><P
->&#13;By allowing incremental zone transfers to be used for
+</p>
+<p>
+By allowing incremental zone transfers to be used for
 non-dynamic zones, this option saves bandwidth at the
 expense of increased CPU and memory consumption at the master.
 In particular, if the new version of a zone is completely
@@ -5234,1096 +1650,422 @@ will be of a size comparable to the combined size of the
 old and new zone version, and the server will need to
 temporarily allocate memory to hold this complete
 difference set.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->multi-master</B
-></DT
-><DD
-><P
->&#13;This should be set when you have multiple masters for a zone and the
+</p>
+</dd>
+<dt><span class="term"><span><strong class="command">multi-master</strong></span></span></dt>
+<dd><p>
+This should be set when you have multiple masters for a zone and the
 addresses refer to different machines.  If 'yes' named will not log
 when the serial number on the master is less than what named currently
-has.  The default is <KBD
-CLASS="userinput"
->no</KBD
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->dnssec-enable</B
-></DT
-><DD
-><P
->&#13;Enable DNSSEC support in named.  Unless set to <KBD
-CLASS="userinput"
->yes</KBD
->
+has.  The default is <strong class="userinput"><code>no</code></strong>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">dnssec-enable</strong></span></span></dt>
+<dd><p>
+Enable DNSSEC support in named.  Unless set to <strong class="userinput"><code>yes</code></strong>
 named behaves as if it does not support DNSSEC.
-The default is <KBD
-CLASS="userinput"
->no</KBD
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->querylog</B
-></DT
-><DD
-><P
->&#13;Specify whether query logging should be started when named start.
-If <B
-CLASS="command"
->querylog</B
-> is not specified then the query logging
-is determined by the presence of the logging category <B
-CLASS="command"
->queries</B
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->check-names</B
-></DT
-><DD
-><P
->&#13;This option is used to restrict the character set and syntax of
+The default is <strong class="userinput"><code>no</code></strong>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">querylog</strong></span></span></dt>
+<dd><p>
+Specify whether query logging should be started when named start.
+If <span><strong class="command">querylog</strong></span> is not specified then the query logging
+is determined by the presence of the logging category <span><strong class="command">queries</strong></span>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
+<dd>
+<p>
+This option is used to restrict the character set and syntax of
 certain domain names in master files and/or DNS responses received
 from the network.  The default varies according to usage area.  For
-<B
-CLASS="command"
->master</B
-> zones the default is <B
-CLASS="command"
->fail</B
->.
-For <B
-CLASS="command"
->slave</B
-> zones the default is <B
-CLASS="command"
->warn</B
->.
-For answer received from the network (<B
-CLASS="command"
->response</B
->)
-the default is <B
-CLASS="command"
->ignore</B
->.
-</P
-><P
->The rules for legal hostnames / mail domains are derived from RFC 952
+<span><strong class="command">master</strong></span> zones the default is <span><strong class="command">fail</strong></span>.
+For <span><strong class="command">slave</strong></span> zones the default is <span><strong class="command">warn</strong></span>.
+For answer received from the network (<span><strong class="command">response</strong></span>)
+the default is <span><strong class="command">ignore</strong></span>.
+</p>
+<p>The rules for legal hostnames / mail domains are derived from RFC 952
 and RFC 821 as modified by RFC 1123.
-</P
-><P
-><B
-CLASS="command"
->check-names</B
-> applies to the owner names of A, AAA and
+</p>
+<p><span><strong class="command">check-names</strong></span> applies to the owner names of A, AAA and
 MX records.  It also applies to the domain names in the RDATA of NS, SOA and MX
 records.  It also applies to the RDATA of PTR records where the owner name
 indicated that it is a reverse lookup of a hostname (the owner name ends in
 IN-ADDR.ARPA, IP6.ARPA, IP6.INT).
-</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN2695"
->6.2.16.2. Forwarding</A
-></H3
-><P
->The forwarding facility can be used to create a large site-wide
+</p>
+</dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2557350"></a>Forwarding</h4></div></div></div>
+<p>The forwarding facility can be used to create a large site-wide
 cache on a few servers, reducing traffic over links to external
 name servers. It can also be used to allow queries by servers that
 do not have direct access to the Internet, but wish to look up exterior
 names anyway. Forwarding occurs only on those queries for which
 the server is not authoritative and does not have the answer in
-its cache.</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->forward</B
-></DT
-><DD
-><P
->This option is only meaningful if the
-forwarders list is not empty. A value of <VAR
-CLASS="varname"
->first</VAR
->,
+its cache.</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
+<dd><p>This option is only meaningful if the
+forwarders list is not empty. A value of <code class="varname">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 <VAR
-CLASS="varname"
->only</VAR
-> is specified, the
+the answer itself. If <code class="varname">only</code> is specified, the
 server will only query the forwarders.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->forwarders</B
-></DT
-><DD
-><P
->Specifies the IP addresses to be used
+</p></dd>
+<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
+<dd><p>Specifies the IP addresses to be used
 for forwarding. The default is the empty list (no forwarding).
-</P
-></DD
-></DL
-></DIV
-><P
->Forwarding can also be configured on a per-domain basis, allowing
+</p></dd>
+</dl></div>
+<p>Forwarding can also be configured on a per-domain basis, allowing
 for the global forwarding options to be overridden in a variety
 of ways. You can set particular domains to use different forwarders,
-or have a different <B
-CLASS="command"
->forward only/first</B
-> behavior,
-or not forward at all, see <A
-HREF="Bv9ARM.ch06.html#zone_statement_grammar"
->Section 6.2.23</A
->.</P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN2714"
->6.2.16.3. Dual-stack Servers</A
-></H3
-><P
->Dual-stack servers are used as servers of last resort to work around
+or have a different <span><strong class="command">forward only/first</strong></span> behavior,
+or not forward at all, see <a href="Bv9ARM.ch06.html#zone_statement_grammar" title="zone
+Statement Grammar">the section called &#8220;<span><strong class="command">zone</strong></span>
+Statement Grammar&#8221;</a>.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2557400"></a>Dual-stack Servers</h4></div></div></div>
+<p>Dual-stack servers are used as servers of last resort to work around
 problems in reachability due the lack of support for either IPv4 or IPv6
-on the host machine.</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->dual-stack-servers</B
-></DT
-><DD
-><P
->Specifies host names / addresses of machines with access to
+on the host machine.</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">dual-stack-servers</strong></span></span></dt>
+<dd><p>Specifies host names / addresses of machines with access to
 both IPv4 and IPv6 transports. If a hostname is used the server must be able
 to resolve the name using only the transport it has.  If the machine is dual
-stacked then the <B
-CLASS="command"
->dual-stack-servers</B
-> have no effect unless
+stacked then the <span><strong class="command">dual-stack-servers</strong></span> have no effect unless
 access to a transport has been disabled on the command line
-(e.g. <B
-CLASS="command"
->named -4</B
->).</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="access_control"
->6.2.16.4. Access Control</A
-></H3
-><P
->Access to the server can be restricted based on the IP address
-of the requesting system. See <A
-HREF="Bv9ARM.ch06.html#address_match_lists"
->Section 6.1.1</A
-> for
-details on how to specify IP address lists.</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->allow-notify</B
-></DT
-><DD
-><P
->Specifies which hosts are allowed to
+(e.g. <span><strong class="command">named -4</strong></span>).</p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="access_control"></a>Access Control</h4></div></div></div>
+<p>Access to the server can be restricted based on the IP address
+of the requesting system. See <a href="Bv9ARM.ch06.html#address_match_lists" title="Address Match Lists">the section called &#8220;Address Match Lists&#8221;</a> for
+details on how to specify IP address lists.</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
+<dd><p>Specifies which hosts are allowed to
 notify this server, a slave, of zone changes in addition
 to the zone masters.
-<B
-CLASS="command"
->allow-notify</B
-> may also be specified in the
-<B
-CLASS="command"
->zone</B
-> statement, in which case it overrides the
-<B
-CLASS="command"
->options allow-notify</B
-> statement.  It is only meaningful
+<span><strong class="command">allow-notify</strong></span> may also be specified in the
+<span><strong class="command">zone</strong></span> statement, in which case it overrides the
+<span><strong class="command">options allow-notify</strong></span> statement.  It is only meaningful
 for a slave zone.  If not specified, the default is to process notify messages
-only from a zone's master.</P
-></DD
-><DT
-><B
-CLASS="command"
->allow-query</B
-></DT
-><DD
-><P
->Specifies which hosts are allowed to
-ask ordinary DNS questions. <B
-CLASS="command"
->allow-query</B
-> may also
-be specified in the <B
-CLASS="command"
->zone</B
-> statement, in which
-case it overrides the <B
-CLASS="command"
->options allow-query</B
-> statement. If
-not specified, the default is to allow queries from all hosts.</P
-></DD
-><DT
-><B
-CLASS="command"
->allow-recursion</B
-></DT
-><DD
-><P
->Specifies which hosts are allowed to
+only from a zone's master.</p></dd>
+<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
+<dd><p>Specifies which hosts are allowed to
+ask ordinary DNS questions. <span><strong class="command">allow-query</strong></span> may also
+be specified in the <span><strong class="command">zone</strong></span> statement, in which
+case it overrides the <span><strong class="command">options allow-query</strong></span> statement. If
+not specified, the default is to allow queries from all hosts.</p></dd>
+<dt><span class="term"><span><strong class="command">allow-recursion</strong></span></span></dt>
+<dd><p>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. 
 Note that disallowing recursive queries for a host does not prevent the
 host from retrieving data that is already in the server's cache.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->allow-update-forwarding</B
-></DT
-><DD
-><P
->Specifies which hosts are allowed to
+</p></dd>
+<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
+<dd>
+<p>Specifies which hosts are allowed to
 submit Dynamic DNS updates to slave zones to be forwarded to the
-master.  The default is <KBD
-CLASS="userinput"
->{ none; }</KBD
->, which 
+master.  The default is <strong class="userinput"><code>{ none; }</code></strong>, which 
 means that no update forwarding will be performed.  To enable
 update forwarding, specify
-<KBD
-CLASS="userinput"
->allow-update-forwarding { any; };</KBD
->.
-Specifying values other than <KBD
-CLASS="userinput"
->{ none; }</KBD
-> or
-<KBD
-CLASS="userinput"
->{ any; }</KBD
-> is usually counterproductive, since
+<strong class="userinput"><code>allow-update-forwarding { any; };</code></strong>.
+Specifying values other than <strong class="userinput"><code>{ none; }</code></strong> or
+<strong class="userinput"><code>{ any; }</code></strong> is usually counterproductive, since
 the responsibility for update access control should rest with the 
-master server, not the slaves.</P
-><P
->Note that enabling the update forwarding feature on a slave server
+master server, not the slaves.</p>
+<p>Note that enabling the update forwarding feature on a slave server
 may expose master servers relying on insecure IP address based
-access control to attacks; see <A
-HREF="Bv9ARM.ch07.html#dynamic_update_security"
->Section 7.3</A
->
-for more details.</P
-></DD
-><DT
-><B
-CLASS="command"
->allow-v6-synthesis</B
-></DT
-><DD
-><P
->This option was introduced for the smooth transition from AAAA
+access control to attacks; see <a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called &#8220;Dynamic Update Security&#8221;</a>
+for more details.</p>
+</dd>
+<dt><span class="term"><span><strong class="command">allow-v6-synthesis</strong></span></span></dt>
+<dd><p>This option was introduced for the smooth transition from AAAA
 to A6 and from "nibble labels" to binary labels.
 However, since both A6 and binary labels were then deprecated,
 this option was also deprecated.
 It is now ignored with some warning messages.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->allow-transfer</B
-></DT
-><DD
-><P
->Specifies which hosts are allowed to
-receive zone transfers from the server. <B
-CLASS="command"
->allow-transfer</B
-> may
-also be specified in the <B
-CLASS="command"
->zone</B
-> statement, in which
-case it overrides the <B
-CLASS="command"
->options allow-transfer</B
-> statement.
-If not specified, the default is to allow transfers to all hosts.</P
-></DD
-><DT
-><B
-CLASS="command"
->blackhole</B
-></DT
-><DD
-><P
->Specifies a list of addresses that the
+</p></dd>
+<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
+<dd><p>Specifies which hosts are allowed to
+receive zone transfers from the server. <span><strong class="command">allow-transfer</strong></span> may
+also be specified in the <span><strong class="command">zone</strong></span> statement, in which
+case it overrides the <span><strong class="command">options allow-transfer</strong></span> statement.
+If not specified, the default is to allow transfers to all hosts.</p></dd>
+<dt><span class="term"><span><strong class="command">blackhole</strong></span></span></dt>
+<dd><p>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 <KBD
-CLASS="userinput"
->none</KBD
->.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN2781"
->6.2.16.5. Interfaces</A
-></H3
-><P
->The interfaces and ports that the server will answer queries
-from may be specified using the <B
-CLASS="command"
->listen-on</B
-> option. <B
-CLASS="command"
->listen-on</B
-> takes
-an optional port, and an <VAR
-CLASS="varname"
->address_match_list</VAR
->.
+from these addresses will not be responded to. The default is <strong class="userinput"><code>none</code></strong>.</p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2557716"></a>Interfaces</h4></div></div></div>
+<p>The interfaces and ports that the server will answer queries
+from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes
+an optional port, and an <code class="varname">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
->Multiple <B
-CLASS="command"
->listen-on</B
-> statements are allowed.
-For example,</P
-><PRE
-CLASS="programlisting"
->listen-on { 5.6.7.8; };
+match list. If a port is not specified, port 53 will be used.</p>
+<p>Multiple <span><strong class="command">listen-on</strong></span> statements are allowed.
+For example,</p>
+<pre class="programlisting">listen-on { 5.6.7.8; };
 listen-on port 1234 { !1.2.3.4; 1.2/16; };
-</PRE
-><P
->will enable the name server on port 53 for the IP address
+</pre>
+<p>will enable the name server on port 53 for the IP address
 5.6.7.8, and on port 1234 of an address on the machine in net
-1.2 that is not 1.2.3.4.</P
-><P
->If no <B
-CLASS="command"
->listen-on</B
-> is specified, the
-server will listen on port 53 on all interfaces.</P
-><P
->The <B
-CLASS="command"
->listen-on-v6</B
-> option is used to
+1.2 that is not 1.2.3.4.</p>
+<p>If no <span><strong class="command">listen-on</strong></span> is specified, the
+server will listen on port 53 on all interfaces.</p>
+<p>The <span><strong class="command">listen-on-v6</strong></span> option is used to
 specify the interfaces and the ports on which the server will listen
-for incoming queries sent using IPv6.</P
-><P
->When <PRE
-CLASS="programlisting"
->{ any; }</PRE
-> is specified
-as the <VAR
-CLASS="varname"
->address_match_list</VAR
-> for the
-<B
-CLASS="command"
->listen-on-v6</B
-> option,
+for incoming queries sent using IPv6.</p>
+<p>When </p>
+<pre class="programlisting">{ any; }</pre>
+<p> is specified
+as the <code class="varname">address_match_list</code> for the
+<span><strong class="command">listen-on-v6</strong></span> option,
 the server does not bind a separate socket to each IPv6 interface
 address as it does for IPv4 if the operating system has enough API
 support for IPv6 (specifically if it conforms to RFC 3493 and RFC 3542).
 Instead, it listens on the IPv6 wildcard address.
 If the system only has incomplete API support for IPv6, however,
-the behavior is the same as that for IPv4.</P
-><P
->A list of particular IPv6 addresses can also be specified, in which case
+the behavior is the same as that for IPv4.</p>
+<p>A list of particular IPv6 addresses can also be specified, in which case
 the server listens on a separate socket for each specified address,
-regardless of whether the desired API is supported by the system.</P
-><P
->Multiple <B
-CLASS="command"
->listen-on-v6</B
-> options can be used.
-For example,</P
-><PRE
-CLASS="programlisting"
->listen-on-v6 { any; };
+regardless of whether the desired API is supported by the system.</p>
+<p>Multiple <span><strong class="command">listen-on-v6</strong></span> options can be used.
+For example,</p>
+<pre class="programlisting">listen-on-v6 { any; };
 listen-on-v6 port 1234 { !2001:db8::/32; any; };
-</PRE
-><P
->will enable the name server on port 53 for any IPv6 addresses
+</pre>
+<p>will enable the name server on port 53 for any IPv6 addresses
 (with a single wildcard socket),
 and on port 1234 of IPv6 addresses that is not in the prefix
-2001:db8::/32 (with separate sockets for each matched address.)</P
-><P
->To make the server not listen on any IPv6 address, use</P
-><PRE
-CLASS="programlisting"
->listen-on-v6 { none; };
-</PRE
-><P
->If no <B
-CLASS="command"
->listen-on-v6</B
-> option is specified,
-the server will not listen on any IPv6 address.</P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN2808"
->6.2.16.6. Query Address</A
-></H3
-><P
->If the server doesn't know the answer to a question, it will
-query other name servers. <B
-CLASS="command"
->query-source</B
-> specifies
+2001:db8::/32 (with separate sockets for each matched address.)</p>
+<p>To make the server not listen on any IPv6 address, use</p>
+<pre class="programlisting">listen-on-v6 { none; };
+</pre>
+<p>If no <span><strong class="command">listen-on-v6</strong></span> option is specified,
+the server will not listen on any IPv6 address.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2557804"></a>Query Address</h4></div></div></div>
+<p>If the server doesn't know the answer to a question, it will
+query other name servers. <span><strong class="command">query-source</strong></span> specifies
 the address and port used for such queries. For queries sent over
-IPv6, there is a separate <B
-CLASS="command"
->query-source-v6</B
-> option.
-If <B
-CLASS="command"
->address</B
-> is <B
-CLASS="command"
->*</B
-> or is omitted,
-a wildcard IP address (<B
-CLASS="command"
->INADDR_ANY</B
->) will be used.
-If <B
-CLASS="command"
->port</B
-> is <B
-CLASS="command"
->*</B
-> or is omitted,
-a random unprivileged port will be used, <B
-CLASS="command"
->avoid-v4-udp-ports</B
->
-and <B
-CLASS="command"
->avoid-v6-udp-ports</B
-> can be used to prevent named
-from selecting certain ports. The defaults are</P
-><PRE
-CLASS="programlisting"
->query-source address * port *;
+IPv6, there is a separate <span><strong class="command">query-source-v6</strong></span> option.
+If <span><strong class="command">address</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
+a wildcard IP address (<span><strong class="command">INADDR_ANY</strong></span>) will be used.
+If <span><strong class="command">port</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
+a random unprivileged port will be used, <span><strong class="command">avoid-v4-udp-ports</strong></span>
+and <span><strong class="command">avoid-v6-udp-ports</strong></span> can be used to prevent named
+from selecting certain ports. The defaults are</p>
+<pre class="programlisting">query-source address * port *;
 query-source-v6 address * port *;
-</PRE
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->The address specified in the <B
-CLASS="command"
->query-source</B
-> option
+</pre>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>The address specified in the <span><strong class="command">query-source</strong></span> option
 is used for both UDP and TCP queries, but the port applies only to 
 UDP queries.  TCP queries always use a random
-unprivileged port.</P
-></BLOCKQUOTE
-></DIV
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->See also <B
-CLASS="command"
->transfer-source</B
-> and
-<B
-CLASS="command"
->notify-source</B
->.</P
-></BLOCKQUOTE
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="zone_transfers"
->6.2.16.7. Zone Transfers</A
-></H3
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> has mechanisms in place to facilitate zone transfers
+unprivileged port.</p>
+</div>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>See also <span><strong class="command">transfer-source</strong></span> and
+<span><strong class="command">notify-source</strong></span>.</p>
+</div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="zone_transfers"></a>Zone Transfers</h4></div></div></div>
+<p><span class="acronym">BIND</span> 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
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->also-notify</B
-></DT
-><DD
-><P
->Defines a global list of IP addresses of name servers
+system. The following options apply to zone transfers.</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
+<dd><p>Defines a global list of IP addresses of name servers
 that are also sent NOTIFY messages whenever a fresh copy of the
 zone is loaded, in addition to the servers listed in the zone's NS records.
 This helps to ensure that copies of the zones will
-quickly converge on stealth servers. If an <B
-CLASS="command"
->also-notify</B
-> list
-is given in a <B
-CLASS="command"
->zone</B
-> statement, it will override
-the <B
-CLASS="command"
->options also-notify</B
-> statement. When a <B
-CLASS="command"
->zone notify</B
-> statement
-is set to <B
-CLASS="command"
->no</B
->, the IP addresses in the global <B
-CLASS="command"
->also-notify</B
-> list will
+quickly converge on stealth servers. If an <span><strong class="command">also-notify</strong></span> list
+is given in a <span><strong class="command">zone</strong></span> statement, it will override
+the <span><strong class="command">options also-notify</strong></span> statement. When a <span><strong class="command">zone notify</strong></span> statement
+is set to <span><strong class="command">no</strong></span>, the IP addresses in the global <span><strong class="command">also-notify</strong></span> list will
 not be sent NOTIFY messages for that zone. The default is the empty
-list (no global notification list).</P
-></DD
-><DT
-><B
-CLASS="command"
->max-transfer-time-in</B
-></DT
-><DD
-><P
->Inbound zone transfers running longer than
+list (no global notification list).</p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
+<dd><p>Inbound zone transfers running longer than
 this many minutes will be terminated. The default is 120 minutes
-(2 hours).  The maximum value is 28 days (40320 minutes).</P
-></DD
-><DT
-><B
-CLASS="command"
->max-transfer-idle-in</B
-></DT
-><DD
-><P
->Inbound zone transfers making no progress
+(2 hours).  The maximum value is 28 days (40320 minutes).</p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
+<dd><p>Inbound zone transfers making no progress
 in this many minutes will be terminated. The default is 60 minutes
-(1 hour).  The maximum value is 28 days (40320 minutes).</P
-></DD
-><DT
-><B
-CLASS="command"
->max-transfer-time-out</B
-></DT
-><DD
-><P
->Outbound zone transfers running longer than
+(1 hour).  The maximum value is 28 days (40320 minutes).</p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
+<dd><p>Outbound zone transfers running longer than
 this many minutes will be terminated. The default is 120 minutes
-(2 hours).  The maximum value is 28 days (40320 minutes).</P
-></DD
-><DT
-><B
-CLASS="command"
->max-transfer-idle-out</B
-></DT
-><DD
-><P
->Outbound zone transfers making no progress
+(2 hours).  The maximum value is 28 days (40320 minutes).</p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
+<dd><p>Outbound zone transfers making no progress
 in this many minutes will be terminated.  The default is 60 minutes (1
-hour).  The maximum value is 28 days (40320 minutes).</P
-></DD
-><DT
-><B
-CLASS="command"
->serial-query-rate</B
-></DT
-><DD
-><P
->Slave servers will periodically query master servers
+hour).  The maximum value is 28 days (40320 minutes).</p></dd>
+<dt><span class="term"><span><strong class="command">serial-query-rate</strong></span></span></dt>
+<dd><p>Slave servers will periodically query master servers
 to find out if zone serial numbers have changed. Each such query uses
 a minute amount of the slave server's network bandwidth.  To limit the
 amount of bandwidth used, BIND 9 limits the rate at which queries are
-sent.  The value of the <B
-CLASS="command"
->serial-query-rate</B
-> option,
+sent.  The value of the <span><strong class="command">serial-query-rate</strong></span> option,
 an integer, is the maximum number of queries sent per second.
 The default is 20.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->serial-queries</B
-></DT
-><DD
-><P
->In BIND 8, the <B
-CLASS="command"
->serial-queries</B
-> option
+</p></dd>
+<dt><span class="term"><span><strong class="command">serial-queries</strong></span></span></dt>
+<dd><p>In BIND 8, the <span><strong class="command">serial-queries</strong></span> option
 set the maximum number of concurrent serial number queries
 allowed to be outstanding at any given time.
 BIND 9 does not limit the number of outstanding
-serial queries and ignores the <B
-CLASS="command"
->serial-queries</B
-> option.
+serial queries and ignores the <span><strong class="command">serial-queries</strong></span> option.
 Instead, it limits the rate at which the queries are sent
-as defined using the <B
-CLASS="command"
->serial-query-rate</B
-> option.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->transfer-format</B
-></DT
-><DD
-><P
->&#13;Zone transfers can be sent using two different formats,
-<B
-CLASS="command"
->one-answer</B
-> and <B
-CLASS="command"
->many-answers</B
->.
-The <B
-CLASS="command"
->transfer-format</B
-> option is used
+as defined using the <span><strong class="command">serial-query-rate</strong></span> option.
+</p></dd>
+<dt><span class="term"><span><strong class="command">transfer-format</strong></span></span></dt>
+<dd><p>
+Zone transfers can be sent using two different formats,
+<span><strong class="command">one-answer</strong></span> and <span><strong class="command">many-answers</strong></span>.
+The <span><strong class="command">transfer-format</strong></span> option is used
 on the master server to determine which format it sends.
-<B
-CLASS="command"
->one-answer</B
-> uses one DNS message per
+<span><strong class="command">one-answer</strong></span> uses one DNS message per
 resource record transferred.
-<B
-CLASS="command"
->many-answers</B
-> packs as many resource records as
-possible into a message. <B
-CLASS="command"
->many-answers</B
-> is more
+<span><strong class="command">many-answers</strong></span> packs as many resource records as
+possible into a message. <span><strong class="command">many-answers</strong></span> is more
 efficient, but is only supported by relatively new slave servers,
-such as <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9, <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8.x and patched
-versions of <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 4.9.5. The default is
-<B
-CLASS="command"
->many-answers</B
->. <B
-CLASS="command"
->transfer-format</B
->
+such as <span class="acronym">BIND</span> 9, <span class="acronym">BIND</span> 8.x and patched
+versions of <span class="acronym">BIND</span> 4.9.5. The default is
+<span><strong class="command">many-answers</strong></span>. <span><strong class="command">transfer-format</strong></span>
 may be overridden on a per-server basis by using the
-<B
-CLASS="command"
->server</B
-> statement.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->transfers-in</B
-></DT
-><DD
-><P
->The maximum number of inbound zone transfers
-that can be running concurrently. The default value is <VAR
-CLASS="literal"
->10</VAR
->.
-Increasing <B
-CLASS="command"
->transfers-in</B
-> may speed up the convergence
-of slave zones, but it also may increase the load on the local system.</P
-></DD
-><DT
-><B
-CLASS="command"
->transfers-out</B
-></DT
-><DD
-><P
->The maximum number of outbound zone transfers
+<span><strong class="command">server</strong></span> statement.
+</p></dd>
+<dt><span class="term"><span><strong class="command">transfers-in</strong></span></span></dt>
+<dd><p>The maximum number of inbound zone transfers
+that can be running concurrently. The default value is <code class="literal">10</code>.
+Increasing <span><strong class="command">transfers-in</strong></span> may speed up the convergence
+of slave zones, but it also may increase the load on the local system.</p></dd>
+<dt><span class="term"><span><strong class="command">transfers-out</strong></span></span></dt>
+<dd><p>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 <VAR
-CLASS="literal"
->10</VAR
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->transfers-per-ns</B
-></DT
-><DD
-><P
->The maximum number of inbound zone transfers
+of the limit will be refused. The default value is <code class="literal">10</code>.</p></dd>
+<dt><span class="term"><span><strong class="command">transfers-per-ns</strong></span></span></dt>
+<dd><p>The maximum number of inbound zone transfers
 that can be concurrently transferring from a given remote name server.
-The default value is <VAR
-CLASS="literal"
->2</VAR
->. Increasing <B
-CLASS="command"
->transfers-per-ns</B
-> may
+The default value is <code class="literal">2</code>. Increasing <span><strong class="command">transfers-per-ns</strong></span> may
 speed up the convergence of slave zones, but it also may increase
-the load on the remote name server. <B
-CLASS="command"
->transfers-per-ns</B
-> may
-be overridden on a per-server basis by using the <B
-CLASS="command"
->transfers</B
-> phrase
-of the <B
-CLASS="command"
->server</B
-> statement.</P
-></DD
-><DT
-><B
-CLASS="command"
->transfer-source</B
-></DT
-><DD
-><P
-><B
-CLASS="command"
->transfer-source</B
-> determines
+the load on the remote name server. <span><strong class="command">transfers-per-ns</strong></span> may
+be overridden on a per-server basis by using the <span><strong class="command">transfers</strong></span> phrase
+of the <span><strong class="command">server</strong></span> statement.</p></dd>
+<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
+<dd><p><span><strong class="command">transfer-source</strong></span> determines
 which local address will be bound to IPv4 TCP connections used to
 fetch zones transferred inbound by the server.  It also determines
 the source IPv4 address, and optionally the UDP port, used for the
 refresh queries and forwarded dynamic updates.  If not set, it defaults
 to a system controlled value which will usually be the address of
 the interface "closest to" the remote end. This address must appear
-in the remote end's <B
-CLASS="command"
->allow-transfer</B
-> option for
+in the remote end's <span><strong class="command">allow-transfer</strong></span> option for
 the zone being transferred, if one is specified. This statement
-sets the <B
-CLASS="command"
->transfer-source</B
-> for all zones, but can
+sets the <span><strong class="command">transfer-source</strong></span> for all zones, but can
 be overridden on a per-view or per-zone basis by including a
-<B
-CLASS="command"
->transfer-source</B
-> statement within the
-<B
-CLASS="command"
->view</B
-> or <B
-CLASS="command"
->zone</B
-> block
-in the configuration file.</P
-></DD
-><DT
-><B
-CLASS="command"
->transfer-source-v6</B
-></DT
-><DD
-><P
->The same as <B
-CLASS="command"
->transfer-source</B
->,
-except zone transfers are performed using IPv6.</P
-></DD
-><DT
-><B
-CLASS="command"
->alt-transfer-source</B
-></DT
-><DD
-><P
->An alternate transfer source if the one listed in
-<B
-CLASS="command"
->transfer-source</B
-> fails and
-<B
-CLASS="command"
->use-alt-transfer-source</B
-> is set.</P
-></DD
-><DT
-><B
-CLASS="command"
->alt-transfer-source-v6</B
-></DT
-><DD
-><P
->An alternate transfer source if the one listed in
-<B
-CLASS="command"
->transfer-source-v6</B
-> fails and
-<B
-CLASS="command"
->use-alt-transfer-source</B
-> is set.</P
-></DD
-><DT
-><B
-CLASS="command"
->use-alt-transfer-source</B
-></DT
-><DD
-><P
->Use the alternate transfer sources or not.  If views are
-specified this defaults to <B
-CLASS="command"
->no</B
-> otherwise it defaults to
-<B
-CLASS="command"
->yes</B
-> (for BIND 8 compatibility).</P
-></DD
-><DT
-><B
-CLASS="command"
->notify-source</B
-></DT
-><DD
-><P
-><B
-CLASS="command"
->notify-source</B
-> determines
+<span><strong class="command">transfer-source</strong></span> statement within the
+<span><strong class="command">view</strong></span> or <span><strong class="command">zone</strong></span> block
+in the configuration file.</p></dd>
+<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
+<dd><p>The same as <span><strong class="command">transfer-source</strong></span>,
+except zone transfers are performed using IPv6.</p></dd>
+<dt><span class="term"><span><strong class="command">alt-transfer-source</strong></span></span></dt>
+<dd>
+<p>
+		  An alternate transfer source if the one listed in
+		  <span><strong class="command">transfer-source</strong></span> fails and
+		  <span><strong class="command">use-alt-transfer-source</strong></span> is
+		  set.
+		</p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+		  If you do not wish the alternate transfer source
+		  to be used you should set
+		  <span><strong class="command">use-alt-transfer-source</strong></span>
+		  appropriately and you should not depend upon
+		  getting a answer back to the first refresh
+		  query.
+		</div>
+</dd>
+<dt><span class="term"><span><strong class="command">alt-transfer-source-v6</strong></span></span></dt>
+<dd><p>An alternate transfer source if the one listed in
+<span><strong class="command">transfer-source-v6</strong></span> fails and
+<span><strong class="command">use-alt-transfer-source</strong></span> is set.</p></dd>
+<dt><span class="term"><span><strong class="command">use-alt-transfer-source</strong></span></span></dt>
+<dd><p>Use the alternate transfer sources or not.  If views are
+specified this defaults to <span><strong class="command">no</strong></span> otherwise it defaults to
+<span><strong class="command">yes</strong></span> (for BIND 8 compatibility).</p></dd>
+<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
+<dd><p><span><strong class="command">notify-source</strong></span> determines
 which local source address, and optionally UDP port, will be used to
 send NOTIFY messages.
-This address must appear in the slave server's <B
-CLASS="command"
->masters</B
->
-zone clause or in an <B
-CLASS="command"
->allow-notify</B
-> clause.
-This statement sets the <B
-CLASS="command"
->notify-source</B
-> for all zones,
+This address must appear in the slave server's <span><strong class="command">masters</strong></span>
+zone clause or in an <span><strong class="command">allow-notify</strong></span> clause.
+This statement sets the <span><strong class="command">notify-source</strong></span> for all zones,
 but can be overridden on a per-zone / per-view basis by including a
-<B
-CLASS="command"
->notify-source</B
-> statement within the <B
-CLASS="command"
->zone</B
->
-or <B
-CLASS="command"
->view</B
-> block in the configuration file.</P
-></DD
-><DT
-><B
-CLASS="command"
->notify-source-v6</B
-></DT
-><DD
-><P
->Like <B
-CLASS="command"
->notify-source</B
->,
-but applies to notify messages sent to IPv6 addresses.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN2974"
->6.2.16.8. Bad UDP Port Lists</A
-></H3
-><P
->&#13;<B
-CLASS="command"
->avoid-v4-udp-ports</B
-> and <B
-CLASS="command"
->avoid-v6-udp-ports</B
->
+<span><strong class="command">notify-source</strong></span> statement within the <span><strong class="command">zone</strong></span>
+or <span><strong class="command">view</strong></span> block in the configuration file.</p></dd>
+<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
+<dd><p>Like <span><strong class="command">notify-source</strong></span>,
+but applies to notify messages sent to IPv6 addresses.</p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2558398"></a>Bad UDP Port Lists</h4></div></div></div>
+<p>
+<span><strong class="command">avoid-v4-udp-ports</strong></span> and <span><strong class="command">avoid-v6-udp-ports</strong></span>
 specify a list of IPv4 and IPv6 UDP ports that will not be used as system
 assigned source ports for UDP sockets.  These lists prevent named
 from choosing as its random source port a port that is blocked by
 your firewall.  If a query went out with such a source port, the
 answer would not get by the firewall and the name server would have
 to query again.
-</P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN2979"
->6.2.16.9. Operating System Resource Limits</A
-></H3
-><P
->The server's usage of many system resources can be limited.
+</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2558414"></a>Operating System Resource Limits</h4></div></div></div>
+<p>The server's usage of many system resources can be limited.
 Scaled values are allowed when specifying resource limits.  For
-example, <B
-CLASS="command"
->1G</B
-> can be used instead of
-<B
-CLASS="command"
->1073741824</B
-> to specify a limit of one
-gigabyte. <B
-CLASS="command"
->unlimited</B
-> requests unlimited use, or the
-maximum available amount. <B
-CLASS="command"
->default</B
-> uses the limit
+example, <span><strong class="command">1G</strong></span> can be used instead of
+<span><strong class="command">1073741824</strong></span> to specify a limit of one
+gigabyte. <span><strong class="command">unlimited</strong></span> requests unlimited use, or the
+maximum available amount. <span><strong class="command">default</strong></span> uses the limit
 that was in force when the server was started. See the description of
-<B
-CLASS="command"
->size_spec</B
-> in <A
-HREF="Bv9ARM.ch06.html#configuration_file_elements"
->Section 6.1</A
->.</P
-><P
->The following options set operating system resource limits for
+<span><strong class="command">size_spec</strong></span> in <a href="Bv9ARM.ch06.html#configuration_file_elements" title="Configuration File Elements">the section called &#8220;Configuration File Elements&#8221;</a>.</p>
+<p>The following options set operating system resource limits for
 the name server process.  Some operating systems don't support some or
 any of the limits. On such systems, a warning will be issued if the
-unsupported limit is used.</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->coresize</B
-></DT
-><DD
-><P
->The maximum size of a core dump. The default
-is <VAR
-CLASS="literal"
->default</VAR
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->datasize</B
-></DT
-><DD
-><P
->The maximum amount of data memory the server
-may use. The default is <VAR
-CLASS="literal"
->default</VAR
->.
+unsupported limit is used.</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">coresize</strong></span></span></dt>
+<dd><p>The maximum size of a core dump. The default
+is <code class="literal">default</code>.</p></dd>
+<dt><span class="term"><span><strong class="command">datasize</strong></span></span></dt>
+<dd><p>The maximum amount of data memory the server
+may use. The default is <code class="literal">default</code>.
 This is a hard limit on server memory usage.
 If the server attempts to allocate memory in excess of this
 limit, the allocation will fail, which may in turn leave
@@ -6333,299 +2075,118 @@ amount of memory used by the server, but it can be used
 to raise an operating system data size limit that is
 too small by default.  If you wish to limit the amount
 of memory used by the server, use the
-<B
-CLASS="command"
->max-cache-size</B
-> and 
-<B
-CLASS="command"
->recursive-clients</B
->
+<span><strong class="command">max-cache-size</strong></span> and 
+<span><strong class="command">recursive-clients</strong></span>
 options instead.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->files</B
-></DT
-><DD
-><P
->The maximum number of files the server
-may have open concurrently. The default is <VAR
-CLASS="literal"
->unlimited</VAR
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->stacksize</B
-></DT
-><DD
-><P
->The maximum amount of stack memory the server
-may use. The default is <VAR
-CLASS="literal"
->default</VAR
->.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN3016"
->6.2.16.10. Server  Resource Limits</A
-></H3
-><P
->The following options set limits on the server's
+</p></dd>
+<dt><span class="term"><span><strong class="command">files</strong></span></span></dt>
+<dd><p>The maximum number of files the server
+may have open concurrently. The default is <code class="literal">unlimited</code>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">stacksize</strong></span></span></dt>
+<dd><p>The maximum amount of stack memory the server
+may use. The default is <code class="literal">default</code>.</p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2558584"></a>Server  Resource Limits</h4></div></div></div>
+<p>The following options set limits on the server's
 resource consumption that are enforced internally by the
-server rather than the operating system.</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->max-ixfr-log-size</B
-></DT
-><DD
-><P
->This option is obsolete; it is accepted
+server rather than the operating system.</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">max-ixfr-log-size</strong></span></span></dt>
+<dd><p>This option is obsolete; it is accepted
 and ignored for BIND 8 compatibility.  The option
-<B
-CLASS="command"
->max-journal-size</B
-> performs a similar
+<span><strong class="command">max-journal-size</strong></span> performs a similar
 function in BIND 8.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->max-journal-size</B
-></DT
-><DD
-><P
->Sets a maximum size for each journal file
-(<A
-HREF="Bv9ARM.ch04.html#journal"
->Section 4.2.1</A
->).  When the journal file approaches
+</p></dd>
+<dt><span class="term"><span><strong class="command">max-journal-size</strong></span></span></dt>
+<dd><p>Sets a maximum size for each journal file
+(<a href="Bv9ARM.ch04.html#journal" title="The journal file">the section called &#8220;The journal file&#8221;</a>).  When the journal file approaches
 the specified size, some of the oldest transactions in the journal
 will be automatically removed.  The default is
-<VAR
-CLASS="literal"
->unlimited</VAR
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->host-statistics-max</B
-></DT
-><DD
-><P
->In BIND 8, specifies the maximum number of host statistic
+<code class="literal">unlimited</code>.</p></dd>
+<dt><span class="term"><span><strong class="command">host-statistics-max</strong></span></span></dt>
+<dd><p>In BIND 8, specifies the maximum number of host statistic
 entries to be kept.
 Not implemented in BIND 9.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->recursive-clients</B
-></DT
-><DD
-><P
->The maximum number of simultaneous recursive lookups
+</p></dd>
+<dt><span class="term"><span><strong class="command">recursive-clients</strong></span></span></dt>
+<dd><p>The maximum number of simultaneous recursive lookups
 the server will perform on behalf of clients.  The default is
-<VAR
-CLASS="literal"
->1000</VAR
->.  Because each recursing client uses a fair
+<code class="literal">1000</code>.  Because each recursing client uses a fair
 bit of memory, on the order of 20 kilobytes, the value of the
-<B
-CLASS="command"
->recursive-clients</B
-> option may have to be decreased
+<span><strong class="command">recursive-clients</strong></span> option may have to be decreased
 on hosts with limited memory.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->tcp-clients</B
-></DT
-><DD
-><P
->The maximum number of simultaneous client TCP
+</p></dd>
+<dt><span class="term"><span><strong class="command">tcp-clients</strong></span></span></dt>
+<dd><p>The maximum number of simultaneous client TCP
 connections that the server will accept.
-The default is <VAR
-CLASS="literal"
->100</VAR
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->max-cache-size</B
-></DT
-><DD
-><P
->The maximum amount of memory to use for the
+The default is <code class="literal">100</code>.</p></dd>
+<dt><span class="term"><span><strong class="command">max-cache-size</strong></span></span></dt>
+<dd><p>The maximum amount of memory to use for the
 server's cache, in bytes.  When the amount of data in the cache
 reaches this limit, the server will cause records to expire
 prematurely so that the limit is not exceeded.  In a server with
 multiple views, the limit applies separately to the cache of each
-view.  The default is <VAR
-CLASS="literal"
->unlimited</VAR
->, meaning that 
+view.  The default is <code class="literal">unlimited</code>, meaning that 
 records are purged from the cache only when their TTLs expire.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->tcp-listen-queue</B
-></DT
-><DD
-><P
->The listen queue depth.  The default and minimum is 3.
+</p></dd>
+<dt><span class="term"><span><strong class="command">tcp-listen-queue</strong></span></span></dt>
+<dd><p>The listen queue depth.  The default and minimum is 3.
 If the kernel supports the accept filter "dataready" this also controls how
 many TCP connections that will be queued in kernel space waiting for
 some data before being passed to accept.  Values less than 3 will be
 silently raised.
-</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN3062"
->6.2.16.11. Periodic Task Intervals</A
-></H3
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->cleaning-interval</B
-></DT
-><DD
-><P
->The server will remove expired resource records
-from the cache every <B
-CLASS="command"
->cleaning-interval</B
-> minutes.
+</p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2558765"></a>Periodic Task Intervals</h4></div></div></div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt>
+<dd><p>The server will remove expired resource records
+from the cache every <span><strong class="command">cleaning-interval</strong></span> minutes.
 The default is 60 minutes.  The maximum value is 28 days (40320 minutes).
-If set to 0, no  periodic cleaning will occur.</P
-></DD
-><DT
-><B
-CLASS="command"
->heartbeat-interval</B
-></DT
-><DD
-><P
->The server will perform zone maintenance tasks
-for all zones marked as <B
-CLASS="command"
->dialup</B
-> whenever this
+If set to 0, no  periodic cleaning will occur.</p></dd>
+<dt><span class="term"><span><strong class="command">heartbeat-interval</strong></span></span></dt>
+<dd><p>The server will perform zone maintenance tasks
+for all zones marked as <span><strong class="command">dialup</strong></span> whenever this
 interval expires. The default is 60 minutes. Reasonable values are up
 to 1 day (1440 minutes).  The maximum value is 28 days (40320 minutes).
-If set to 0, no zone maintenance for these zones will occur.</P
-></DD
-><DT
-><B
-CLASS="command"
->interface-interval</B
-></DT
-><DD
-><P
->The server will scan the network interface list
-every <B
-CLASS="command"
->interface-interval</B
-> minutes. The default
+If set to 0, no zone maintenance for these zones will occur.</p></dd>
+<dt><span class="term"><span><strong class="command">interface-interval</strong></span></span></dt>
+<dd><p>The server will scan the network interface list
+every <span><strong class="command">interface-interval</strong></span> minutes. The default
 is 60 minutes. The maximum value is 28 days (40320 minutes).
 If set to 0, interface scanning will only occur when
 the configuration file is  loaded. After the scan, the server will
 begin listening for queries on any newly discovered
 interfaces (provided they are allowed by the
-<B
-CLASS="command"
->listen-on</B
-> configuration), and will
-stop listening on interfaces that have gone away.</P
-></DD
-><DT
-><B
-CLASS="command"
->statistics-interval</B
-></DT
-><DD
-><P
->Name server statistics will be logged
-every <B
-CLASS="command"
->statistics-interval</B
-> minutes. The default is 
+<span><strong class="command">listen-on</strong></span> configuration), and will
+stop listening on interfaces that have gone away.</p></dd>
+<dt><span class="term"><span><strong class="command">statistics-interval</strong></span></span></dt>
+<dd>
+<p>Name server statistics will be logged
+every <span><strong class="command">statistics-interval</strong></span> minutes. The default is 
 60. The maximum value is 28 days (40320 minutes).
-If set to 0, no statistics will be logged.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not yet implemented in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->9.</P
-></BLOCKQUOTE
-></DIV
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="topology"
->6.2.16.12. Topology</A
-></H3
-><P
->All other things being equal, when the server chooses a name server
+If set to 0, no statistics will be logged.</p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>Not yet implemented in <span class="acronym">BIND</span>9.</p>
+</div>
+</dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="topology"></a>Topology</h4></div></div></div>
+<p>All other things being equal, when the server chooses a name server
 to query from a list of name servers, it prefers the one that is
-topologically closest to itself. The <B
-CLASS="command"
->topology</B
-> statement
-takes an <B
-CLASS="command"
->address_match_list</B
-> and interprets it
+topologically closest to itself. The <span><strong class="command">topology</strong></span> statement
+takes an <span><strong class="command">address_match_list</strong></span> 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
@@ -6633,124 +2194,61 @@ 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="programlisting"
->topology {
+For example,</p>
+<pre class="programlisting">topology {
     10/8;
     !1.2.3/24;
     { 1.2/16; 3/8; };
-};</PRE
-><P
->will prefer servers on network 10 the most, followed by hosts
+};</pre>
+<p>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
->The default topology is</P
-><PRE
-CLASS="programlisting"
->    topology { localhost; localnets; };
-</PRE
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->The <B
-CLASS="command"
->topology</B
-> option
-is not implemented in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9.
-</P
-></BLOCKQUOTE
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="the_sortlist_statement"
->6.2.16.13. The <B
-CLASS="command"
->sortlist</B
-> Statement</A
-></H3
-><P
->The response to a DNS query may consist of multiple resource
+is preferred least of all.</p>
+<p>The default topology is</p>
+<pre class="programlisting">    topology { localhost; localnets; };
+</pre>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>The <span><strong class="command">topology</strong></span> option
+is not implemented in <span class="acronym">BIND</span> 9.
+</p>
+</div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="the_sortlist_statement"></a>The <span><strong class="command">sortlist</strong></span> Statement</h4></div></div></div>
+<p>The response to a DNS query may consist of multiple resource
 records (RRs) forming a resource records set (RRset).
 The name server will normally return the
 RRs within the RRset in an indeterminate order
-(but see the <B
-CLASS="command"
->rrset-order</B
->
-statement in <A
-HREF="Bv9ARM.ch06.html#rrset_ordering"
->Section 6.2.16.14</A
->).
+(but see the <span><strong class="command">rrset-order</strong></span>
+statement in <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called &#8220;RRset Ordering&#8221;</a>).
 The client resolver code should rearrange the RRs as appropriate,
 that is, using any addresses on the local net in preference to other addresses.
 However, not all resolvers can do this or are correctly configured.
 When a client is using a local server the sorting can be performed
 in the server, based on the client's address. This only requires
-configuring the name servers, not all the clients.</P
-><P
->The <B
-CLASS="command"
->sortlist</B
-> statement (see below) takes
-an <B
-CLASS="command"
->address_match_list</B
-> and interprets it even
-more specifically than the <B
-CLASS="command"
->topology</B
-> statement
-does (<A
-HREF="Bv9ARM.ch06.html#topology"
->Section 6.2.16.12</A
->).
-Each top level statement in the <B
-CLASS="command"
->sortlist</B
-> must
-itself be an explicit <B
-CLASS="command"
->address_match_list</B
-> with
+configuring the name servers, not all the clients.</p>
+<p>The <span><strong class="command">sortlist</strong></span> statement (see below) takes
+an <span><strong class="command">address_match_list</strong></span> and interprets it even
+more specifically than the <span><strong class="command">topology</strong></span> statement
+does (<a href="Bv9ARM.ch06.html#topology" title="Topology">the section called &#8220;Topology&#8221;</a>).
+Each top level statement in the <span><strong class="command">sortlist</strong></span> must
+itself be an explicit <span><strong class="command">address_match_list</strong></span> with
 one or two elements. The first element (which may be an IP address,
-an IP prefix, an ACL name or a nested <B
-CLASS="command"
->address_match_list</B
->)
+an IP prefix, an ACL name or a nested <span><strong class="command">address_match_list</strong></span>)
 of each top level list is checked against the source address of
-the query until a match is found.</P
-><P
->Once the source address of the query has been matched, if
+the query until a match is found.</p>
+<p>Once the source address of the query has been matched, if
 the top level statement contains only one element, the actual primitive
 element that matched the source address is used to select the address
 in the response to move to the beginning of the response. If the
 statement is a list of two elements, then the second element is
-treated the same as the <B
-CLASS="command"
->address_match_list</B
-> in
-a <B
-CLASS="command"
->topology</B
-> statement. Each top level element
+treated the same as the <span><strong class="command">address_match_list</strong></span> in
+a <span><strong class="command">topology</strong></span> 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
->In the following example, any queries received from any of
+distance is moved to the beginning of the response.</p>
+<p>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
@@ -6761,10 +2259,8 @@ will prefer other addresses on that network to the 192.168.2/24
 and
 192.168.3/24 networks. Queries received from a host on the 192.168.4/24
 or the 192.168.5/24 network will only prefer other addresses on
-their directly connected networks.</P
-><PRE
-CLASS="programlisting"
->sortlist {
+their directly connected networks.</p>
+<pre class="programlisting">sortlist {
     { localhost;                                   // IF   the local host
         { localnets;                               // THEN first fit on the
             192.168.1/24;                          //   following nets
@@ -6780,1331 +2276,446 @@ CLASS="programlisting"
             { 192.168.1/24; 192.168.2/24; }; }; };
     { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
     };
-};</PRE
-><P
->The following example will give reasonable behavior for the
+};</pre>
+<p>The following example will give reasonable behavior for the
 local host and hosts on directly connected networks. It is similar
-to the behavior of the address sort in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 4.9.x. Responses sent
+to the behavior of the address sort in <span class="acronym">BIND</span> 4.9.x. Responses sent
 to queries from the local host will favor any of the directly connected
 networks. Responses sent to queries from any other hosts on a directly
 connected network will prefer addresses on that same network. Responses
-to other queries will not be sorted.</P
-><PRE
-CLASS="programlisting"
->sortlist {
+to other queries will not be sorted.</p>
+<pre class="programlisting">sortlist {
            { localhost; localnets; };
            { localnets; };
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="rrset_ordering"
->6.2.16.14. RRset Ordering</A
-></H3
-><P
->When multiple records are returned in an answer it may be
+</pre>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="rrset_ordering"></a>RRset Ordering</h4></div></div></div>
+<p>When multiple records are returned in an answer it may be
 useful to configure the order of the records placed into the response.
-The <B
-CLASS="command"
->rrset-order</B
-> statement permits configuration
+The <span><strong class="command">rrset-order</strong></span> statement permits configuration
 of the ordering of the records in a multiple record response.
-See also the <B
-CLASS="command"
->sortlist</B
-> statement,
-<A
-HREF="Bv9ARM.ch06.html#the_sortlist_statement"
->Section 6.2.16.13</A
->.
-</P
-><P
->An <B
-CLASS="command"
->order_spec</B
-> is defined as follows:</P
-><PRE
-CLASS="programlisting"
->[<SPAN
-CLASS="optional"
-> class <VAR
-CLASS="replaceable"
->class_name</VAR
-> </SPAN
->][<SPAN
-CLASS="optional"
-> type <VAR
-CLASS="replaceable"
->type_name</VAR
-> </SPAN
->][<SPAN
-CLASS="optional"
-> name <VAR
-CLASS="replaceable"
->"domain_name"</VAR
-></SPAN
->]
-      order <VAR
-CLASS="replaceable"
->ordering</VAR
->
-</PRE
-><P
->If no class is specified, the default is <B
-CLASS="command"
->ANY</B
->.
-If no type is specified, the default is <B
-CLASS="command"
->ANY</B
->.
-If no name is specified, the default is "<B
-CLASS="command"
->*</B
->".</P
-><P
->The legal values for <B
-CLASS="command"
->ordering</B
-> are:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN3150"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><B
-CLASS="command"
->fixed</B
-></P
-></TD
-><TD
-><P
->Records are returned in the order they
-are defined in the zone file.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->random</B
-></P
-></TD
-><TD
-><P
->Records are returned in some random order.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->cyclic</B
-></P
-></TD
-><TD
-><P
->Records are returned in a round-robin
-order.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->For example:</P
-><PRE
-CLASS="programlisting"
->rrset-order {
+See also the <span><strong class="command">sortlist</strong></span> statement,
+<a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called &#8220;The <span><strong class="command">sortlist</strong></span> Statement&#8221;</a>.
+</p>
+<p>An <span><strong class="command">order_spec</strong></span> is defined as follows:</p>
+<pre class="programlisting">[<span class="optional"> class <em class="replaceable"><code>class_name</code></em> </span>][<span class="optional"> type <em class="replaceable"><code>type_name</code></em> </span>][<span class="optional"> name <em class="replaceable"><code>"domain_name"</code></em></span>]
+      order <em class="replaceable"><code>ordering</code></em>
+</pre>
+<p>If no class is specified, the default is <span><strong class="command">ANY</strong></span>.
+If no type is specified, the default is <span><strong class="command">ANY</strong></span>.
+If no name is specified, the default is "<span><strong class="command">*</strong></span>".</p>
+<p>The legal values for <span><strong class="command">ordering</strong></span> are:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span><strong class="command">fixed</strong></span></p></td>
+<td><p>Records are returned in the order they
+are defined in the zone file.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">random</strong></span></p></td>
+<td><p>Records are returned in some random order.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">cyclic</strong></span></p></td>
+<td><p>Records are returned in a round-robin
+order.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>For example:</p>
+<pre class="programlisting">rrset-order {
    class IN type A name "host.example.com" order random;
    order cyclic;
 };
-</PRE
-><P
->will cause any responses for type A records in class IN that
-have "<VAR
-CLASS="literal"
->host.example.com</VAR
->" as a suffix, to always be returned
-in random order. All other records are returned in cyclic order.</P
-><P
->If multiple <B
-CLASS="command"
->rrset-order</B
-> statements appear,
-they are not combined &#8212; the last one applies.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->The <B
-CLASS="command"
->rrset-order</B
-> statement
-is not yet fully implemented in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9.
+</pre>
+<p>will cause any responses for type A records in class IN that
+have "<code class="literal">host.example.com</code>" as a suffix, to always be returned
+in random order. All other records are returned in cyclic order.</p>
+<p>If multiple <span><strong class="command">rrset-order</strong></span> statements appear,
+they are not combined &#8212; the last one applies.</p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>The <span><strong class="command">rrset-order</strong></span> statement
+is not yet fully implemented in <span class="acronym">BIND</span> 9.
 BIND 9 currently does not support "fixed" ordering.
-</P
-></BLOCKQUOTE
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="tuning"
->6.2.16.15. Tuning</A
-></H3
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->lame-ttl</B
-></DT
-><DD
-><P
->Sets the number of seconds to cache a
+</p>
+</div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="tuning"></a>Tuning</h4></div></div></div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">lame-ttl</strong></span></span></dt>
+<dd><p>Sets the number of seconds to cache a
 lame server indication. 0 disables caching. (This is
-<SPAN
-CLASS="bold"
-><B
-CLASS="emphasis"
->NOT</B
-></SPAN
-> recommended.)
-Default is <VAR
-CLASS="literal"
->600</VAR
-> (10 minutes). Maximum value is 
-<VAR
-CLASS="literal"
->1800</VAR
-> (30 minutes).</P
-></DD
-><DT
-><B
-CLASS="command"
->max-ncache-ttl</B
-></DT
-><DD
-><P
->To reduce network traffic and increase performance
-the server stores negative answers. <B
-CLASS="command"
->max-ncache-ttl</B
-> is
+<span class="bold"><strong>NOT</strong></span> recommended.)
+Default is <code class="literal">600</code> (10 minutes). Maximum value is 
+<code class="literal">1800</code> (30 minutes).</p></dd>
+<dt><span class="term"><span><strong class="command">max-ncache-ttl</strong></span></span></dt>
+<dd><p>To reduce network traffic and increase performance
+the server stores negative answers. <span><strong class="command">max-ncache-ttl</strong></span> is
 used to set a maximum retention time for these answers in the server
 in seconds. The default
-<B
-CLASS="command"
->max-ncache-ttl</B
-> is <VAR
-CLASS="literal"
->10800</VAR
-> seconds (3 hours).
-<B
-CLASS="command"
->max-ncache-ttl</B
-> cannot exceed 7 days and will
-be silently truncated to 7 days if set to a greater value.</P
-></DD
-><DT
-><B
-CLASS="command"
->max-cache-ttl</B
-></DT
-><DD
-><P
-><B
-CLASS="command"
->max-cache-ttl</B
-> sets
+<span><strong class="command">max-ncache-ttl</strong></span> is <code class="literal">10800</code> seconds (3 hours).
+<span><strong class="command">max-ncache-ttl</strong></span> cannot exceed 7 days and will
+be silently truncated to 7 days if set to a greater value.</p></dd>
+<dt><span class="term"><span><strong class="command">max-cache-ttl</strong></span></span></dt>
+<dd><p><span><strong class="command">max-cache-ttl</strong></span> sets
 the maximum time for which the server will cache ordinary (positive)
-answers. The default is one week (7 days).</P
-></DD
-><DT
-><B
-CLASS="command"
->min-roots</B
-></DT
-><DD
-><P
->The minimum number of root servers that
+answers. The default is one week (7 days).</p></dd>
+<dt><span class="term"><span><strong class="command">min-roots</strong></span></span></dt>
+<dd>
+<p>The minimum number of root servers that
 is required for a request for the root servers to be accepted. Default
-is <KBD
-CLASS="userinput"
->2</KBD
->.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->Not implemented in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->9.</P
-></BLOCKQUOTE
-></DIV
-></DD
-><DT
-><B
-CLASS="command"
->sig-validity-interval</B
-></DT
-><DD
-><P
->Specifies the number of days into the
+is <strong class="userinput"><code>2</code></strong>.</p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>Not implemented in <span class="acronym">BIND</span>9.</p>
+</div>
+</dd>
+<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
+<dd><p>Specifies the number of days into the
 future when DNSSEC signatures automatically generated as a result
-of dynamic updates (<A
-HREF="Bv9ARM.ch04.html#dynamic_update"
->Section 4.2</A
->)
-will expire. The default is <VAR
-CLASS="literal"
->30</VAR
-> days.
+of dynamic updates (<a href="Bv9ARM.ch04.html#dynamic_update" title="Dynamic Update">the section called &#8220;Dynamic Update&#8221;</a>)
+will expire. The default is <code class="literal">30</code> days.
 The maximum value is 10 years (3660 days). The signature
 inception time is unconditionally set to one hour before the current time
-to allow for a limited amount of clock skew.</P
-></DD
-><DT
-><B
-CLASS="command"
->min-refresh-time</B
->, <B
-CLASS="command"
->max-refresh-time</B
->, <B
-CLASS="command"
->min-retry-time</B
->, <B
-CLASS="command"
->max-retry-time</B
-></DT
-><DD
-><P
->&#13;These options control the server's behavior on refreshing a zone
+to allow for a limited amount of clock skew.</p></dd>
+<dt>
+<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
+</dt>
+<dd>
+<p>
+These options control the server's behavior on refreshing a zone
 (querying for SOA changes) or retrying failed transfers.
 Usually the SOA values for the zone are used, but these values
 are set by the master, giving slave server administrators little
 control over their contents.
-</P
-><P
->&#13;These options allow the administrator to set a minimum and maximum
+</p>
+<p>
+These options allow the administrator to set a minimum and maximum
 refresh and retry time either per-zone, per-view, or globally.
 These options are valid for slave and stub zones,
 and clamp the SOA refresh and retry times to the specified values.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->edns-udp-size</B
-></DT
-><DD
-><P
->&#13;<B
-CLASS="command"
->edns-udp-size</B
-> sets the advertised EDNS UDP buffer
+</p>
+</dd>
+<dt><span class="term"><span><strong class="command">edns-udp-size</strong></span></span></dt>
+<dd><p>
+<span><strong class="command">edns-udp-size</strong></span> sets the advertised EDNS UDP buffer
 size.  Valid values are 512 to 4096 (values outside this range will be
 silently adjusted).  The default value is 4096.  The usual reason for
 setting edns-udp-size to a non default value it to get UDP answers to
 pass through broken firewalls that block fragmented packets and/or
 block UDP packets that are greater than 512 bytes.
-</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="builtin"
->6.2.16.16. Built-in server information zones</A
-></H3
-><P
->The server provides some helpful diagnostic information
+</p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="builtin"></a>Built-in server information zones</h4></div></div></div>
+<p>The server provides some helpful diagnostic information
 through a number of built-in zones under the
-pseudo-top-level-domain <VAR
-CLASS="literal"
->bind</VAR
-> in the
-<B
-CLASS="command"
->CHAOS</B
-> class.  These zones are part of a
-built-in view (see <A
-HREF="Bv9ARM.ch06.html#view_statement_grammar"
->Section 6.2.21</A
->) of class
-<B
-CLASS="command"
->CHAOS</B
-> which is separate from the default view of
-class <B
-CLASS="command"
->IN</B
->; therefore, any global server options
-such as <B
-CLASS="command"
->allow-query</B
-> do not apply the these zones.
+pseudo-top-level-domain <code class="literal">bind</code> in the
+<span><strong class="command">CHAOS</strong></span> class.  These zones are part of a
+built-in view (see <a href="Bv9ARM.ch06.html#view_statement_grammar" title="view Statement Grammar">the section called &#8220;<span><strong class="command">view</strong></span> Statement Grammar&#8221;</a>) of class
+<span><strong class="command">CHAOS</strong></span> which is separate from the default view of
+class <span><strong class="command">IN</strong></span>; therefore, any global server options
+such as <span><strong class="command">allow-query</strong></span> do not apply the these zones.
 If you feel the need to disable these zones, use the options
-below, or hide the built-in <B
-CLASS="command"
->CHAOS</B
-> view by
-defining an explicit view of class <B
-CLASS="command"
->CHAOS</B
->
-that matches all clients.</P
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->version</B
-></DT
-><DD
-><P
->The version the server should report
-via a query of the name <VAR
-CLASS="literal"
->version.bind</VAR
->
-with type <B
-CLASS="command"
->TXT</B
->, class <B
-CLASS="command"
->CHAOS</B
->.
+below, or hide the built-in <span><strong class="command">CHAOS</strong></span> view by
+defining an explicit view of class <span><strong class="command">CHAOS</strong></span>
+that matches all clients.</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">version</strong></span></span></dt>
+<dd><p>The version the server should report
+via a query of the name <code class="literal">version.bind</code>
+with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
 The default is the real version number of this server.
-Specifying <B
-CLASS="command"
->version none</B
->
-disables processing of the queries.</P
-></DD
-><DT
-><B
-CLASS="command"
->hostname</B
-></DT
-><DD
-><P
->The hostname the server should report via a query of
-the name <TT
-CLASS="filename"
->hostname.bind</TT
->
-with type <B
-CLASS="command"
->TXT</B
->, class <B
-CLASS="command"
->CHAOS</B
->.
+Specifying <span><strong class="command">version none</strong></span>
+disables processing of the queries.</p></dd>
+<dt><span class="term"><span><strong class="command">hostname</strong></span></span></dt>
+<dd><p>The hostname the server should report via a query of
+the name <code class="filename">hostname.bind</code>
+with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
 This defaults to the hostname of the machine hosting the name server as
 found by gethostname().  The primary purpose of such queries is to
 identify which of a group of anycast servers is actually
-answering your queries.  Specifying <B
-CLASS="command"
->hostname none;</B
->
-disables processing of the queries.</P
-></DD
-><DT
-><B
-CLASS="command"
->server-id</B
-></DT
-><DD
-><P
->The ID of the server should report via a query of
-the name <TT
-CLASS="filename"
->ID.SERVER</TT
->
-with type <B
-CLASS="command"
->TXT</B
->, class <B
-CLASS="command"
->CHAOS</B
->.
+answering your queries.  Specifying <span><strong class="command">hostname none;</strong></span>
+disables processing of the queries.</p></dd>
+<dt><span class="term"><span><strong class="command">server-id</strong></span></span></dt>
+<dd><p>The ID of the server should report via a query of
+the name <code class="filename">ID.SERVER</code>
+with type <span><strong class="command">TXT</strong></span>, class <span><strong class="command">CHAOS</strong></span>.
 The primary purpose of such queries is to
 identify which of a group of anycast servers is actually
-answering your queries.  Specifying <B
-CLASS="command"
->server-id none;</B
->
+answering your queries.  Specifying <span><strong class="command">server-id none;</strong></span>
 disables processing of the queries.
-Specifying <B
-CLASS="command"
->server-id hostname;</B
-> will cause named to
+Specifying <span><strong class="command">server-id hostname;</strong></span> will cause named to
 use the hostname as found by gethostname().
-The default <B
-CLASS="command"
->server-id</B
-> is <B
-CLASS="command"
->none</B
->.
-</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="statsfile"
->6.2.16.17. The Statistics File</A
-></H3
-><P
->The statistics file generated by <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9
+The default <span><strong class="command">server-id</strong></span> is <span><strong class="command">none</strong></span>.
+</p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="statsfile"></a>The Statistics File</h4></div></div></div>
+<p>The statistics file generated by <span class="acronym">BIND</span> 9
 is similar, but not identical, to that
-generated by <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8.
-</P
-><P
->The statistics dump begins with the line <B
-CLASS="command"
->+++ Statistics Dump
-+++ (973798949)</B
->, where the number in parentheses is a standard
+generated by <span class="acronym">BIND</span> 8.
+</p>
+<p>The statistics dump begins with the line <span><strong class="command">+++ Statistics Dump
++++ (973798949)</strong></span>, where the number in parentheses is a standard
 Unix-style timestamp, measured as seconds since January 1, 1970.  Following
 that line are a series of lines containing a counter type, the value of the
 counter, optionally a zone name, and optionally a view name.
 The lines without view and zone listed are global statistics for the entire server.
 Lines with a zone and view name for the given view and zone (the view name is
 omitted for the default view).  The statistics dump ends
-with the line <B
-CLASS="command"
->--- Statistics Dump --- (973798949)</B
->, where the
-number is identical to the number in the beginning line.</P
-><P
->The following statistics counters are maintained:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN3294"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><B
-CLASS="command"
->success</B
-></P
-></TD
-><TD
-><P
->The number of
+with the line <span><strong class="command">--- Statistics Dump --- (973798949)</strong></span>, where the
+number is identical to the number in the beginning line.</p>
+<p>The following statistics counters are maintained:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span><strong class="command">success</strong></span></p></td>
+<td><p>The number of
 successful queries made to the server or zone.  A successful query
 is defined as query which returns a NOERROR response with at least
-one answer RR.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->referral</B
-></P
-></TD
-><TD
-><P
->The number of queries which resulted
-in referral responses.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->nxrrset</B
-></P
-></TD
-><TD
-><P
->The number of queries which resulted in
-NOERROR responses with no data.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->nxdomain</B
-></P
-></TD
-><TD
-><P
->The number
-of queries which resulted in NXDOMAIN responses.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->failure</B
-></P
-></TD
-><TD
-><P
->The number of queries which resulted in a
-failure response other than those above.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->recursion</B
-></P
-></TD
-><TD
-><P
->The number of queries which caused the server
-to perform recursion in order to find the final answer.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->&#13;Each query received by the server will cause exactly one of
-<B
-CLASS="command"
->success</B
->,
-<B
-CLASS="command"
->referral</B
->,
-<B
-CLASS="command"
->nxrrset</B
->,
-<B
-CLASS="command"
->nxdomain</B
->, or
-<B
-CLASS="command"
->failure</B
->
+one answer RR.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">referral</strong></span></p></td>
+<td><p>The number of queries which resulted
+in referral responses.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">nxrrset</strong></span></p></td>
+<td><p>The number of queries which resulted in
+NOERROR responses with no data.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">nxdomain</strong></span></p></td>
+<td><p>The number
+of queries which resulted in NXDOMAIN responses.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">failure</strong></span></p></td>
+<td><p>The number of queries which resulted in a
+failure response other than those above.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">recursion</strong></span></p></td>
+<td><p>The number of queries which caused the server
+to perform recursion in order to find the final answer.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>
+Each query received by the server will cause exactly one of
+<span><strong class="command">success</strong></span>,
+<span><strong class="command">referral</strong></span>,
+<span><strong class="command">nxrrset</strong></span>,
+<span><strong class="command">nxdomain</strong></span>, or
+<span><strong class="command">failure</strong></span>
 to be incremented, and may additionally cause the
-<B
-CLASS="command"
->recursion</B
-> counter to be incremented.
-</P
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="server_statement_grammar"
->6.2.17. <B
-CLASS="command"
->server</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
->server <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> {
-    [<SPAN
-CLASS="optional"
-> bogus <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> provide-ixfr <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> request-ixfr <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> edns <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfers <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfer-format <VAR
-CLASS="replaceable"
->( one-answer | many-answers )</VAR
-> ; ]</SPAN
->]
-    [<SPAN
-CLASS="optional"
-> keys <VAR
-CLASS="replaceable"
->{ string ; [<SPAN
-CLASS="optional"
-> string ; [<SPAN
-CLASS="optional"
->...</SPAN
->]</SPAN
->] }</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfer-source (<VAR
-CLASS="replaceable"
->ip4_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfer-source-v6 (<VAR
-CLASS="replaceable"
->ip6_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
+<span><strong class="command">recursion</strong></span> counter to be incremented.
+</p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="server_statement_grammar"></a><span><strong class="command">server</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">server <em class="replaceable"><code>ip_addr</code></em> {
+    [<span class="optional"> bogus <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> provide-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> request-ixfr <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> edns <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> transfers <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> transfer-format <em class="replaceable"><code>( one-answer | many-answers )</code></em> ; ]</span>]
+    [<span class="optional"> keys <em class="replaceable"><code>{ string ; [<span class="optional"> string ; [<span class="optional">...</span>]</span>] }</code></em> ; </span>]
+    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="server_statement_definition_and_usage"
->6.2.18. <B
-CLASS="command"
->server</B
-> Statement Definition and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->server</B
-> statement defines characteristics
-to be associated with a remote name server.</P
-><P
->&#13;The <B
-CLASS="command"
->server</B
-> statement can occur at the top level of the
-configuration file or inside a <B
-CLASS="command"
->view</B
-> statement.  
-If a <B
-CLASS="command"
->view</B
-> statement contains
-one or more <B
-CLASS="command"
->server</B
-> statements, only those
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="server_statement_definition_and_usage"></a><span><strong class="command">server</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>The <span><strong class="command">server</strong></span> statement defines characteristics
+to be associated with a remote name server.</p>
+<p>
+The <span><strong class="command">server</strong></span> statement can occur at the top level of the
+configuration file or inside a <span><strong class="command">view</strong></span> statement.  
+If a <span><strong class="command">view</strong></span> statement contains
+one or more <span><strong class="command">server</strong></span> statements, only those
 apply to the view and any top-level ones are ignored.
-If a view contains no <B
-CLASS="command"
->server</B
-> statements,
-any top-level <B
-CLASS="command"
->server</B
-> statements are used as
+If a view contains no <span><strong class="command">server</strong></span> statements,
+any top-level <span><strong class="command">server</strong></span> statements are used as
 defaults.
-</P
-><P
->If you discover that a remote server is giving out bad data,
+</p>
+<p>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 <B
-CLASS="command"
->bogus</B
-> is <B
-CLASS="command"
->no</B
->.</P
-><P
->The <B
-CLASS="command"
->provide-ixfr</B
-> clause determines whether
+value of <span><strong class="command">bogus</strong></span> is <span><strong class="command">no</strong></span>.</p>
+<p>The <span><strong class="command">provide-ixfr</strong></span> 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 <B
-CLASS="command"
->yes</B
->, incremental transfer will be provided
-whenever possible. If set to <B
-CLASS="command"
->no</B
->, all transfers
+If set to <span><strong class="command">yes</strong></span>, incremental transfer will be provided
+whenever possible. If set to <span><strong class="command">no</strong></span>, all transfers
 to the remote server will be non-incremental. If not set, the value
-of the <B
-CLASS="command"
->provide-ixfr</B
-> option in the view or
-global options block is used as a default.</P
-><P
->The <B
-CLASS="command"
->request-ixfr</B
-> clause determines whether
+of the <span><strong class="command">provide-ixfr</strong></span> option in the view or
+global options block is used as a default.</p>
+<p>The <span><strong class="command">request-ixfr</strong></span> 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 <B
-CLASS="command"
->request-ixfr</B
-> option in the view or
-global options block is used as a default.</P
-><P
->IXFR requests to servers that do not support IXFR will automatically
+value of the <span><strong class="command">request-ixfr</strong></span> option in the view or
+global options block is used as a default.</p>
+<p>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 <B
-CLASS="command"
->yes</B
-> should always work.
-The purpose of the <B
-CLASS="command"
->provide-ixfr</B
-> and
-<B
-CLASS="command"
->request-ixfr</B
-> clauses is
+of <span><strong class="command">yes</strong></span> should always work.
+The purpose of the <span><strong class="command">provide-ixfr</strong></span> and
+<span><strong class="command">request-ixfr</strong></span> 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
->The <B
-CLASS="command"
->edns</B
-> clause determines whether the local server
+is buggy and crashes or corrupts data when IXFR is used.</p>
+<p>The <span><strong class="command">edns</strong></span> clause determines whether the local server
 will attempt to use EDNS when communicating with the remote server.  The
-default is <B
-CLASS="command"
->yes</B
->.</P
-><P
->The server supports two zone transfer methods. The first, <B
-CLASS="command"
->one-answer</B
->,
-uses one DNS message per resource record transferred. <B
-CLASS="command"
->many-answers</B
-> packs
-as many resource records as possible into a message. <B
-CLASS="command"
->many-answers</B
-> is
-more efficient, but is only known to be understood by <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9, <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->
-8.x, and patched versions of <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 4.9.5. You can specify which method
-to use for a server with the <B
-CLASS="command"
->transfer-format</B
-> option.
-If <B
-CLASS="command"
->transfer-format</B
-> is not specified, the <B
-CLASS="command"
->transfer-format</B
-> specified
-by the <B
-CLASS="command"
->options</B
-> statement will be used.</P
-><P
-><B
-CLASS="command"
->transfers</B
-> is used to limit the number of
+default is <span><strong class="command">yes</strong></span>.</p>
+<p>The server supports two zone transfer methods. The first, <span><strong class="command">one-answer</strong></span>,
+uses one DNS message per resource record transferred. <span><strong class="command">many-answers</strong></span> packs
+as many resource records as possible into a message. <span><strong class="command">many-answers</strong></span> is
+more efficient, but is only known to be understood by <span class="acronym">BIND</span> 9, <span class="acronym">BIND</span>
+8.x, and patched versions of <span class="acronym">BIND</span> 4.9.5. You can specify which method
+to use for a server with the <span><strong class="command">transfer-format</strong></span> option.
+If <span><strong class="command">transfer-format</strong></span> is not specified, the <span><strong class="command">transfer-format</strong></span> specified
+by the <span><strong class="command">options</strong></span> statement will be used.</p>
+<p><span><strong class="command">transfers</strong></span> is used to limit the number of
 concurrent inbound zone transfers from the specified server. If
-no <B
-CLASS="command"
->transfers</B
-> clause is specified, the limit is
-set according to the <B
-CLASS="command"
->transfers-per-ns</B
-> option.</P
-><P
->The <B
-CLASS="command"
->keys</B
-> clause identifies a
-<B
-CLASS="command"
->key_id</B
-> defined by the <B
-CLASS="command"
->key</B
-> statement,
-to be used for transaction security (TSIG, <A
-HREF="Bv9ARM.ch04.html#tsig"
->Section 4.5</A
->)
+no <span><strong class="command">transfers</strong></span> clause is specified, the limit is
+set according to the <span><strong class="command">transfers-per-ns</strong></span> option.</p>
+<p>The <span><strong class="command">keys</strong></span> clause identifies a
+<span><strong class="command">key_id</strong></span> defined by the <span><strong class="command">key</strong></span> statement,
+to be used for transaction security (TSIG, <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
 when talking to the remote server. 
 When a request is sent to the remote server, a request signature
 will be generated using the key specified here and appended to the
 message. A request originating from the remote server is not required
-to be signed by this key.</P
-><P
->Although the grammar of the <B
-CLASS="command"
->keys</B
-> clause
+to be signed by this key.</p>
+<p>Although the grammar of the <span><strong class="command">keys</strong></span> clause
 allows for multiple keys, only a single key per server is currently
-supported.</P
-><P
->The <B
-CLASS="command"
->transfer-source</B
-> and
-<B
-CLASS="command"
->transfer-source-v6</B
-> clauses specify the IPv4 and IPv6 source
+supported.</p>
+<p>The <span><strong class="command">transfer-source</strong></span> and
+<span><strong class="command">transfer-source-v6</strong></span> clauses specify the IPv4 and IPv6 source
 address to be used for zone transfer with the remote server, respectively.
-For an IPv4 remote server, only <B
-CLASS="command"
->transfer-source</B
-> can
+For an IPv4 remote server, only <span><strong class="command">transfer-source</strong></span> can
 be specified.
 Similarly, for an IPv6 remote server, only
-<B
-CLASS="command"
->transfer-source-v6</B
-> can be specified.
+<span><strong class="command">transfer-source-v6</strong></span> can be specified.
 Form more details, see the description of
-<B
-CLASS="command"
->transfer-source</B
-> and
-<B
-CLASS="command"
->transfer-source-v6</B
-> in
-<A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN3433"
->6.2.19. <B
-CLASS="command"
->trusted-keys</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
->trusted-keys {
-    <VAR
-CLASS="replaceable"
->string</VAR
-> <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->string</VAR
-> ;
-    [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->string</VAR
-> <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->string</VAR
-> ; [<SPAN
-CLASS="optional"
->...</SPAN
->]</SPAN
->]
+<span><strong class="command">transfer-source</strong></span> and
+<span><strong class="command">transfer-source-v6</strong></span> in
+<a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2562233"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">trusted-keys {
+    <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ;
+    [<span class="optional"> <em class="replaceable"><code>string</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>]
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN3449"
->6.2.20. <B
-CLASS="command"
->trusted-keys</B
-> Statement Definition
-and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->trusted-keys</B
-> statement defines DNSSEC
-security roots. DNSSEC is described in <A
-HREF="Bv9ARM.ch04.html#DNSSEC"
->Section 4.8</A
->. A security root is defined when the public key for a non-authoritative
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2562281"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
+and Usage</h3></div></div></div>
+<p>The <span><strong class="command">trusted-keys</strong></span> statement defines DNSSEC
+security roots. DNSSEC is described in <a href="Bv9ARM.ch04.html#DNSSEC" title="DNSSEC">the section called &#8220;DNSSEC&#8221;</a>. A security root is defined when the public key for a non-authoritative
 zone is known, but cannot be securely obtained through DNS, either
 because it is the  DNS root zone or because its parent zone is unsigned.
 Once a key has been configured as a trusted key, it is treated as
 if it had been validated and proven secure. The resolver attempts
-DNSSEC validation on all DNS data in subdomains of a security root.</P
-><P
->The <B
-CLASS="command"
->trusted-keys</B
-> statement can contain
+DNSSEC validation on all DNS data in subdomains of a security root.</p>
+<p>The <span><strong class="command">trusted-keys</strong></span> statement can contain
 multiple key entries, each consisting of the key's domain name,
 flags, protocol, algorithm, and the base-64 representation of the
-key data.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="view_statement_grammar"
->6.2.21. <B
-CLASS="command"
->view</B
-> Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
->view <VAR
-CLASS="replaceable"
->view_name</VAR
-> 
-      [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->class</VAR
-></SPAN
->] {
-      match-clients { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> } ;
-      match-destinations { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> } ;
-      match-recursive-only <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ;
-      [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->view_option</VAR
->; ...</SPAN
->]
-      [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->zone_statement</VAR
->; ...</SPAN
->]
+key data.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="view_statement_grammar"></a><span><strong class="command">view</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting">view <em class="replaceable"><code>view_name</code></em> 
+      [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
+      match-clients { <em class="replaceable"><code>address_match_list</code></em> } ;
+      match-destinations { <em class="replaceable"><code>address_match_list</code></em> } ;
+      match-recursive-only <em class="replaceable"><code>yes_or_no</code></em> ;
+      [<span class="optional"> <em class="replaceable"><code>view_option</code></em>; ...</span>]
+      [<span class="optional"> <em class="replaceable"><code>zone_statement</code></em>; ...</span>]
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN3471"
->6.2.22. <B
-CLASS="command"
->view</B
-> Statement Definition and Usage</A
-></H2
-><P
->The <B
-CLASS="command"
->view</B
-> statement is a powerful new feature
-of <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 that lets a name server answer a DNS query differently
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2562349"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
+<p>The <span><strong class="command">view</strong></span> statement is a powerful new feature
+of <span class="acronym">BIND</span> 9 that lets a name server answer a DNS query differently
 depending on who is asking. It is particularly useful for implementing
-split DNS setups without having to run multiple servers.</P
-><P
->Each <B
-CLASS="command"
->view</B
-> statement defines a view of the
+split DNS setups without having to run multiple servers.</p>
+<p>Each <span><strong class="command">view</strong></span> statement defines a view of the
 DNS namespace that will be seen by a subset of clients.  A client matches
 a view if its source IP address matches the 
-<VAR
-CLASS="varname"
->address_match_list</VAR
-> of the view's
-<B
-CLASS="command"
->match-clients</B
-> clause and its destination IP address matches
-the <VAR
-CLASS="varname"
->address_match_list</VAR
-> of the view's
-<B
-CLASS="command"
->match-destinations</B
-> clause.  If not specified, both
-<B
-CLASS="command"
->match-clients</B
-> and <B
-CLASS="command"
->match-destinations</B
->
+<code class="varname">address_match_list</code> of the view's
+<span><strong class="command">match-clients</strong></span> clause and its destination IP address matches
+the <code class="varname">address_match_list</code> of the view's
+<span><strong class="command">match-destinations</strong></span> clause.  If not specified, both
+<span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
 default to matching all addresses.  In addition to checking IP addresses
-<B
-CLASS="command"
->match-clients</B
-> and <B
-CLASS="command"
->match-destinations</B
->
-can also take <B
-CLASS="command"
->keys</B
-> which provide an mechanism for the
+<span><strong class="command">match-clients</strong></span> and <span><strong class="command">match-destinations</strong></span>
+can also take <span><strong class="command">keys</strong></span> which provide an mechanism for the
 client to select the view.  A view can also be specified
-as <B
-CLASS="command"
->match-recursive-only</B
->, which means that only recursive
+as <span><strong class="command">match-recursive-only</strong></span>, which means that only recursive
 requests from matching clients will match that view.
-The order of the <B
-CLASS="command"
->view</B
-> statements is significant &#8212;
+The order of the <span><strong class="command">view</strong></span> statements is significant &#8212;
 a client request will be resolved in the context of the first
-<B
-CLASS="command"
->view</B
-> that it matches.</P
-><P
->Zones defined within a <B
-CLASS="command"
->view</B
-> statement will
-be only be accessible to clients that match the <B
-CLASS="command"
->view</B
->.
+<span><strong class="command">view</strong></span> that it matches.</p>
+<p>Zones defined within a <span><strong class="command">view</strong></span> statement will
+be only be accessible to clients that match the <span><strong class="command">view</strong></span>.
  By defining a zone of the same name in multiple views, different
 zone data can be given to different clients, for example, "internal"
-and "external" clients in a split DNS setup.</P
-><P
->Many of the options given in the <B
-CLASS="command"
->options</B
-> statement
-can also be used within a <B
-CLASS="command"
->view</B
-> statement, and then
+and "external" clients in a split DNS setup.</p>
+<p>Many of the options given in the <span><strong class="command">options</strong></span> statement
+can also be used within a <span><strong class="command">view</strong></span> statement, and then
 apply only when resolving queries with that view.  When no view-specific
-value is given, the value in the <B
-CLASS="command"
->options</B
-> statement
+value is given, the value in the <span><strong class="command">options</strong></span> statement
 is used as a default.  Also, zone options can have default values specified
-in the <B
-CLASS="command"
->view</B
-> statement; these view-specific defaults
-take precedence over those in the <B
-CLASS="command"
->options</B
-> statement.</P
-><P
->Views are class specific.  If no class is given, class IN
+in the <span><strong class="command">view</strong></span> statement; these view-specific defaults
+take precedence over those in the <span><strong class="command">options</strong></span> statement.</p>
+<p>Views are class specific.  If no class is given, class IN
 is assumed.  Note that all non-IN views must contain a hint zone,
-since only the IN class has compiled-in default hints.</P
-><P
->If there are no <B
-CLASS="command"
->view</B
-> statements in the config
+since only the IN class has compiled-in default hints.</p>
+<p>If there are no <span><strong class="command">view</strong></span> statements in the config
 file, a default view that matches any client is automatically created
-in class IN. Any <B
-CLASS="command"
->zone</B
-> statements specified on
+in class IN. Any <span><strong class="command">zone</strong></span> statements specified on
 the top level of the configuration file are considered to be part of
-this default view, and the <B
-CLASS="command"
->options</B
-> statement will
-apply to the default view. If any explicit <B
-CLASS="command"
->view</B
->
-statements are present, all <B
-CLASS="command"
->zone</B
-> statements must
-occur inside <B
-CLASS="command"
->view</B
-> statements.</P
-><P
->Here is an example of a typical split DNS setup implemented
-using <B
-CLASS="command"
->view</B
-> statements.</P
-><PRE
-CLASS="programlisting"
->view "internal" {
+this default view, and the <span><strong class="command">options</strong></span> statement will
+apply to the default view. If any explicit <span><strong class="command">view</strong></span>
+statements are present, all <span><strong class="command">zone</strong></span> statements must
+occur inside <span><strong class="command">view</strong></span> statements.</p>
+<p>Here is an example of a typical split DNS setup implemented
+using <span><strong class="command">view</strong></span> statements.</p>
+<pre class="programlisting">view "internal" {
       // This should match our internal networks.
       match-clients { 10.0.0.0/8; };
 
@@ -8133,519 +2744,80 @@ view "external" {
            file "example-external.db";
       };
 };
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="zone_statement_grammar"
->6.2.23. <B
-CLASS="command"
->zone</B
->
-Statement Grammar</A
-></H2
-><PRE
-CLASS="programlisting"
->zone <VAR
-CLASS="replaceable"
->zone_name</VAR
-> [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->class</VAR
-></SPAN
->] [<SPAN
-CLASS="optional"
->{ 
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="zone_statement_grammar"></a><span><strong class="command">zone</strong></span>
+Statement Grammar</h3></div></div></div>
+<pre class="programlisting">zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] [<span class="optional">{ 
     type ( master | slave | hint | stub | forward | delegation-only ) ;
-    [<SPAN
-CLASS="optional"
-> allow-notify { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> } ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-query { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> } ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-transfer { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> } ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-update { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> } ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> update-policy { <VAR
-CLASS="replaceable"
->update_policy_rule</VAR
-> [<SPAN
-CLASS="optional"
->...</SPAN
->] } ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> allow-update-forwarding { <VAR
-CLASS="replaceable"
->address_match_list</VAR
-> } ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> also-notify { <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; ... </SPAN
->] }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> check-names (<CODE
-CLASS="constant"
->warn</CODE
->|<CODE
-CLASS="constant"
->fail</CODE
->|<CODE
-CLASS="constant"
->ignore</CODE
->) ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> dialup <VAR
-CLASS="replaceable"
->dialup_option</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> delegation-only <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> file <VAR
-CLASS="replaceable"
->string</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> forward (<CODE
-CLASS="constant"
->only</CODE
->|<CODE
-CLASS="constant"
->first</CODE
->) ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> forwarders { <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; ... </SPAN
->] }; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> ixfr-base <VAR
-CLASS="replaceable"
->string</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> ixfr-tmp-file <VAR
-CLASS="replaceable"
->string</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> maintain-ixfr-base <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> masters [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] { ( <VAR
-CLASS="replaceable"
->masters_list</VAR
-> | <VAR
-CLASS="replaceable"
->ip_addr</VAR
-> [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] [<SPAN
-CLASS="optional"
->key <VAR
-CLASS="replaceable"
->key</VAR
-></SPAN
->] ) ; [<SPAN
-CLASS="optional"
->...</SPAN
->] } ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-ixfr-log-size <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-transfer-idle-in <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-transfer-idle-out <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-transfer-time-in <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-transfer-time-out <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> notify <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> | <VAR
-CLASS="replaceable"
->explicit</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> pubkey <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->number</VAR
-> <VAR
-CLASS="replaceable"
->string</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfer-source (<VAR
-CLASS="replaceable"
->ip4_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> transfer-source-v6 (<VAR
-CLASS="replaceable"
->ip6_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> alt-transfer-source (<VAR
-CLASS="replaceable"
->ip4_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> alt-transfer-source-v6 (<VAR
-CLASS="replaceable"
->ip6_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> use-alt-transfer-source <VAR
-CLASS="replaceable"
->yes_or_no</VAR
->; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> notify-source (<VAR
-CLASS="replaceable"
->ip4_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> notify-source-v6 (<VAR
-CLASS="replaceable"
->ip6_addr</VAR
-> | <CODE
-CLASS="constant"
->*</CODE
->) [<SPAN
-CLASS="optional"
->port <VAR
-CLASS="replaceable"
->ip_port</VAR
-></SPAN
->] ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> zone-statistics <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> sig-validity-interval <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> database <VAR
-CLASS="replaceable"
->string</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> min-refresh-time <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-refresh-time <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> min-retry-time <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> max-retry-time <VAR
-CLASS="replaceable"
->number</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> multi-master <VAR
-CLASS="replaceable"
->yes_or_no</VAR
-> ; </SPAN
->]
-    [<SPAN
-CLASS="optional"
-> key-directory <VAR
-CLASS="replaceable"
->path_name</VAR
->; </SPAN
->]
+    [<span class="optional"> allow-notify { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
+    [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
+    [<span class="optional"> allow-transfer { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
+    [<span class="optional"> allow-update { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
+    [<span class="optional"> update-policy { <em class="replaceable"><code>update_policy_rule</code></em> [<span class="optional">...</span>] } ; </span>]
+    [<span class="optional"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> } ; </span>]
+    [<span class="optional"> also-notify { <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> check-names (<code class="constant">warn</code>|<code class="constant">fail</code>|<code class="constant">ignore</code>) ; </span>]
+    [<span class="optional"> dialup <em class="replaceable"><code>dialup_option</code></em> ; </span>]
+    [<span class="optional"> delegation-only <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> forward (<code class="constant">only</code>|<code class="constant">first</code>) ; </span>]
+    [<span class="optional"> forwarders { [<span class="optional"> <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; ... </span>] }; </span>]
+    [<span class="optional"> ixfr-base <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> ixfr-tmp-file <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> maintain-ixfr-base <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> masters [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] } ; </span>]
+    [<span class="optional"> max-ixfr-log-size <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-idle-in <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-idle-out <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-time-in <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-transfer-time-out <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> notify <em class="replaceable"><code>yes_or_no</code></em> | <em class="replaceable"><code>explicit</code></em> ; </span>]
+    [<span class="optional"> pubkey <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> alt-transfer-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> use-alt-transfer-source <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> notify-source (<em class="replaceable"><code>ip4_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> notify-source-v6 (<em class="replaceable"><code>ip6_addr</code></em> | <code class="constant">*</code>) [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] ; </span>]
+    [<span class="optional"> zone-statistics <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> sig-validity-interval <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> database <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> min-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-refresh-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> min-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> max-retry-time <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> multi-master <em class="replaceable"><code>yes_or_no</code></em> ; </span>]
+    [<span class="optional"> key-directory <em class="replaceable"><code>path_name</code></em>; </span>]
 
-}</SPAN
->];
-</PRE
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN3645"
->6.2.24. <B
-CLASS="command"
->zone</B
-> Statement Definition and Usage</A
-></H2
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN3648"
->6.2.24.1. Zone Types</A
-></H3
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN3650"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->master</VAR
-></P
-></TD
-><TD
-><P
->The server has a master copy of the data
+}</span>];
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2563022"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2563029"></a>Zone Types</h4></div></div></div>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><code class="varname">master</code></p></td>
+<td><p>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
-><P
-><VAR
-CLASS="varname"
->slave</VAR
-></P
-></TD
-><TD
-><P
->A slave zone is a replica of a master
-zone. The <B
-CLASS="command"
->masters</B
-> list specifies one or more IP addresses
+it.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">slave</code></p></td>
+<td><p>A slave zone is a replica of a master
+zone. The <span><strong class="command">masters</strong></span> list specifies one or more IP addresses
 of master servers that the slave contacts to update its copy of the zone.
 Masters list elements can also be names of other masters lists.
 By default, transfers are made from port 53 on the servers; this can
@@ -8659,1640 +2831,605 @@ 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 <VAR
-CLASS="literal"
->example.com</VAR
-> might place
+a slave server for the zone <code class="literal">example.com</code> might place
 the zone contents into a file called
-<TT
-CLASS="filename"
->ex/example.com</TT
-> where <TT
-CLASS="filename"
->ex/</TT
-> is
+<code class="filename">ex/example.com</code> where <code class="filename">ex/</code> is
 just the first two letters of the zone name. (Most operating systems
 behave very slowly if you put 100 000 files into
-a single directory.)</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->stub</VAR
-></P
-></TD
-><TD
-><P
->A stub zone is similar to a slave zone,
+a single directory.)</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">stub</code></p></td>
+<td>
+<p>A stub zone is similar to a slave zone,
 except that it replicates only the NS records of a master zone instead
 of the entire zone. Stub zones are not a standard part of the DNS;
-they are a feature specific to the <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> implementation.
-</P
->
+they are a feature specific to the <span class="acronym">BIND</span> implementation.
+</p>
 
-<P
->Stub zones can be used to eliminate the need for glue NS record
+<p>Stub zones can be used to eliminate the need for glue NS record
 in a parent zone at the expense of maintaining a stub zone entry and
-a set of name server addresses in <TT
-CLASS="filename"
->named.conf</TT
->.
+a set of name server addresses in <code class="filename">named.conf</code>.
 This usage is not recommended for new configurations, and BIND 9
 supports it only in a limited way.
-In <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 4/8, zone transfers of a parent zone
+In <span class="acronym">BIND</span> 4/8, zone transfers of a parent zone
 included the NS records from stub children of that zone. This meant
 that, in some cases, users could get away with configuring child stubs
-only in the master server for the parent zone. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->
+only in the master server for the parent zone. <span class="acronym">BIND</span>
 9 never mixes together zone data from different zones in this
-way. Therefore, if a <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 master serving a parent
+way. Therefore, if a <span class="acronym">BIND</span> 9 master serving a parent
 zone has child stub zones configured, all the slave servers for the
 parent zone also need to have the same child stub zones
-configured.</P
->
+configured.</p>
 
-<P
->Stub zones can also be used as a way of forcing the resolution
+<p>Stub zones can also be used as a way of forcing the resolution
 of a given domain to use a particular set of authoritative servers.
 For example, the caching name servers on a private network using
 RFC1981 addressing may be configured with stub zones for
-<VAR
-CLASS="literal"
->10.in-addr.arpa</VAR
->
+<code class="literal">10.in-addr.arpa</code>
 to use a set of internal name servers as the authoritative
-servers for that domain.</P
->
-</TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->forward</VAR
-></P
-></TD
-><TD
-><P
->A "forward zone" is a way to configure
-forwarding on a per-domain basis.  A <B
-CLASS="command"
->zone</B
-> statement
-of type <B
-CLASS="command"
->forward</B
-> can contain a <B
-CLASS="command"
->forward</B
-> and/or <B
-CLASS="command"
->forwarders</B
-> statement,
+servers for that domain.</p>
+</td>
+</tr>
+<tr>
+<td><p><code class="varname">forward</code></p></td>
+<td>
+<p>A "forward zone" is a way to configure
+forwarding on a per-domain basis.  A <span><strong class="command">zone</strong></span> statement
+of type <span><strong class="command">forward</strong></span> can contain a <span><strong class="command">forward</strong></span> and/or <span><strong class="command">forwarders</strong></span> statement,
 which will apply to queries within the domain given by the zone
-name. If no <B
-CLASS="command"
->forwarders</B
-> statement is present or
-an empty list for <B
-CLASS="command"
->forwarders</B
-> is given, then no
+name. If no <span><strong class="command">forwarders</strong></span> statement is present or
+an empty list for <span><strong class="command">forwarders</strong></span> is given, then no
 forwarding will be done for the domain, canceling the effects of
-any forwarders in the <B
-CLASS="command"
->options</B
-> statement. Thus
+any forwarders in the <span><strong class="command">options</strong></span> statement. Thus
 if you want to use this type of zone to change the behavior of the
-global <B
-CLASS="command"
->forward</B
-> option (that is, "forward first
+global <span><strong class="command">forward</strong></span> option (that is, "forward first
 to", then "forward only", or vice versa, but want to use the same
-servers as set globally) you need to re-specify the global forwarders.</P
->
-</TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->hint</VAR
-></P
-></TD
-><TD
-><P
->The initial set of root name servers is
+servers as set globally) you need to re-specify the global forwarders.</p>
+</td>
+</tr>
+<tr>
+<td><p><code class="varname">hint</code></p></td>
+<td><p>The initial set of root name servers is
 specified using a "hint zone". When the server starts up, it uses
 the root hints to find a root name server and get the most recent
 list of root name servers. If no hint zone is specified for class
 IN, the server uses a compiled-in default set of root servers hints.
-Classes other than IN have no built-in defaults hints.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->delegation-only</VAR
-></P
-></TD
-><TD
-><P
->This is used to enforce the delegation only
+Classes other than IN have no built-in defaults hints.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">delegation-only</code></p></td>
+<td>
+<p>This is used to enforce the delegation only
 status of infrastructure zones (e.g. COM, NET, ORG).  Any answer that
 is received without a explicit or implicit delegation in the authority
 section will be treated as NXDOMAIN.  This does not apply to the zone
-apex.  This SHOULD NOT be applied to leaf zones.</P
->
-<P
-><VAR
-CLASS="varname"
->delegation-only</VAR
-> has no effect on answers received
-from forwarders.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN3713"
->6.2.24.2. Class</A
-></H3
-><P
->The zone's name may optionally be followed by a class. If
-a class is not specified, class <VAR
-CLASS="literal"
->IN</VAR
-> (for <VAR
-CLASS="varname"
->Internet</VAR
->),
-is assumed. This is correct for the vast majority of cases.</P
-><P
->The <VAR
-CLASS="literal"
->hesiod</VAR
-> class is
+apex.  This SHOULD NOT be applied to leaf zones.</p>
+<p><code class="varname">delegation-only</code> has no effect on answers received
+from forwarders.</p>
+</td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2563267"></a>Class</h4></div></div></div>
+<p>The zone's name may optionally be followed by a class. If
+a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>),
+is assumed. This is correct for the vast majority of cases.</p>
+<p>The <code class="literal">hesiod</code> 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 
-<VAR
-CLASS="literal"
->HS</VAR
-> is
-a synonym for hesiod.</P
-><P
->Another MIT development is CHAOSnet, a LAN protocol created
-in the mid-1970s. Zone data for it can be specified with the <VAR
-CLASS="literal"
->CHAOS</VAR
-> class.</P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN3723"
->6.2.24.3. Zone Options</A
-></H3
-><P
-></P
-><DIV
-CLASS="variablelist"
-><DL
-><DT
-><B
-CLASS="command"
->allow-notify</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->allow-notify</B
-> in <A
-HREF="Bv9ARM.ch06.html#access_control"
->Section 6.2.16.4</A
-></P
-></DD
-><DT
-><B
-CLASS="command"
->allow-query</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->allow-query</B
-> in <A
-HREF="Bv9ARM.ch06.html#access_control"
->Section 6.2.16.4</A
-></P
-></DD
-><DT
-><B
-CLASS="command"
->allow-transfer</B
-></DT
-><DD
-><P
->See the description of <B
-CLASS="command"
->allow-transfer</B
->
-in <A
-HREF="Bv9ARM.ch06.html#access_control"
->Section 6.2.16.4</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->allow-update</B
-></DT
-><DD
-><P
->Specifies which hosts are allowed to
+<code class="literal">HS</code> is
+a synonym for hesiod.</p>
+<p>Another MIT development is CHAOSnet, a LAN protocol created
+in the mid-1970s. Zone data for it can be specified with the <code class="literal">CHAOS</code> class.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2563434"></a>Zone Options</h4></div></div></div>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">allow-notify</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a></p></dd>
+<dt><span class="term"><span><strong class="command">allow-query</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">allow-query</strong></span> in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a></p></dd>
+<dt><span class="term"><span><strong class="command">allow-transfer</strong></span></span></dt>
+<dd><p>See the description of <span><strong class="command">allow-transfer</strong></span>
+in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">allow-update</strong></span></span></dt>
+<dd><p>Specifies which hosts are allowed to
 submit Dynamic DNS updates for master zones. The default is to deny
 updates from all hosts.  Note that allowing updates based
 on the requestor's IP address is insecure; see
-<A
-HREF="Bv9ARM.ch07.html#dynamic_update_security"
->Section 7.3</A
-> for details.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->update-policy</B
-></DT
-><DD
-><P
->Specifies a "Simple Secure Update" policy. See
-<A
-HREF="Bv9ARM.ch06.html#dynamic_update_policies"
->Section 6.2.24.4</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->allow-update-forwarding</B
-></DT
-><DD
-><P
->See the description of <B
-CLASS="command"
->allow-update-forwarding</B
->
-in <A
-HREF="Bv9ARM.ch06.html#access_control"
->Section 6.2.16.4</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->also-notify</B
-></DT
-><DD
-><P
->Only meaningful if <B
-CLASS="command"
->notify</B
-> is
+<a href="Bv9ARM.ch07.html#dynamic_update_security" title="Dynamic Update Security">the section called &#8220;Dynamic Update Security&#8221;</a> for details.
+</p></dd>
+<dt><span class="term"><span><strong class="command">update-policy</strong></span></span></dt>
+<dd><p>Specifies a "Simple Secure Update" policy. See
+<a href="Bv9ARM.ch06.html#dynamic_update_policies" title="Dynamic Update Policies">the section called &#8220;Dynamic Update Policies&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">allow-update-forwarding</strong></span></span></dt>
+<dd><p>See the description of <span><strong class="command">allow-update-forwarding</strong></span>
+in <a href="Bv9ARM.ch06.html#access_control" title="Access Control">the section called &#8220;Access Control&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">also-notify</strong></span></span></dt>
+<dd><p>Only meaningful if <span><strong class="command">notify</strong></span> is
 active for this zone. The set of machines that will receive a 
-<VAR
-CLASS="literal"
->DNS NOTIFY</VAR
-> message
+<code class="literal">DNS NOTIFY</code> message
 for this zone is made up of all the listed name servers (other than
 the primary master) for the zone plus any IP addresses specified
-with <B
-CLASS="command"
->also-notify</B
->. A port may be specified
-with each <B
-CLASS="command"
->also-notify</B
-> address to send the notify
+with <span><strong class="command">also-notify</strong></span>. A port may be specified
+with each <span><strong class="command">also-notify</strong></span> address to send the notify
 messages to a port other than the default of 53.
-<B
-CLASS="command"
->also-notify</B
-> is not meaningful for stub zones.
-The default is the empty list.</P
-></DD
-><DT
-><B
-CLASS="command"
->check-names</B
-></DT
-><DD
-><P
->&#13;This option is used to restrict the character set and syntax of
+<span><strong class="command">also-notify</strong></span> is not meaningful for stub zones.
+The default is the empty list.</p></dd>
+<dt><span class="term"><span><strong class="command">check-names</strong></span></span></dt>
+<dd><p>
+This option is used to restrict the character set and syntax of
 certain domain names in master files and/or DNS responses received from the
-network.  The default varies according to zone type.  For <B
-CLASS="command"
->master</B
-> zones the default is <B
-CLASS="command"
->fail</B
->.  For <B
-CLASS="command"
->slave</B
->
-zones the default is <B
-CLASS="command"
->warn</B
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->database</B
-></DT
-><DD
-><P
->Specify the type of database to be used for storing the
-zone data.  The string following the <B
-CLASS="command"
->database</B
-> keyword
+network.  The default varies according to zone type.  For <span><strong class="command">master</strong></span> zones the default is <span><strong class="command">fail</strong></span>.  For <span><strong class="command">slave</strong></span>
+zones the default is <span><strong class="command">warn</strong></span>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">database</strong></span></span></dt>
+<dd>
+<p>Specify the type of database to be used for storing the
+zone data.  The string following the <span><strong class="command">database</strong></span> keyword
 is interpreted as a list of whitespace-delimited words.  The first word
 identifies the database type, and any subsequent words are passed
 as arguments to the database to be interpreted in a way specific
-to the database type.</P
-><P
->The default is <KBD
-CLASS="userinput"
->"rbt"</KBD
->, BIND 9's native in-memory
-red-black-tree database.  This database does not take arguments.</P
-><P
->Other values are possible if additional database drivers
+to the database type.</p>
+<p>The default is <strong class="userinput"><code>"rbt"</code></strong>, BIND 9's native in-memory
+red-black-tree database.  This database does not take arguments.</p>
+<p>Other values are possible if additional database drivers
 have been linked into the server.  Some sample drivers are included
-with the distribution but none are linked in by default.</P
-></DD
-><DT
-><B
-CLASS="command"
->dialup</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->dialup</B
-> in <A
-HREF="Bv9ARM.ch06.html#boolean_options"
->Section 6.2.16.1</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->delegation-only</B
-></DT
-><DD
-><P
->The flag only applies to hint and stub zones.  If set
-to <KBD
-CLASS="userinput"
->yes</KBD
-> then the zone will also be treated as if it
+with the distribution but none are linked in by default.</p>
+</dd>
+<dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">dialup</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">delegation-only</strong></span></span></dt>
+<dd><p>The flag only applies to hint and stub zones.  If set
+to <strong class="userinput"><code>yes</code></strong> then the zone will also be treated as if it
 is also a delegation-only type zone.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->forward</B
-></DT
-><DD
-><P
->Only meaningful if the zone has a forwarders
-list. The <B
-CLASS="command"
->only</B
-> value causes the lookup to fail
-after trying the forwarders and getting no answer, while <B
-CLASS="command"
->first</B
-> would
-allow a normal lookup to be tried.</P
-></DD
-><DT
-><B
-CLASS="command"
->forwarders</B
-></DT
-><DD
-><P
->Used to override the list of global forwarders.
-If it is not specified in a zone of type <B
-CLASS="command"
->forward</B
->,
-no forwarding is done for the zone; the global options are not used.</P
-></DD
-><DT
-><B
-CLASS="command"
->ixfr-base</B
-></DT
-><DD
-><P
->Was used in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8 to specify the name
+</p></dd>
+<dt><span class="term"><span><strong class="command">forward</strong></span></span></dt>
+<dd><p>Only meaningful if the zone has a forwarders
+list. The <span><strong class="command">only</strong></span> value causes the lookup to fail
+after trying the forwarders and getting no answer, while <span><strong class="command">first</strong></span> would
+allow a normal lookup to be tried.</p></dd>
+<dt><span class="term"><span><strong class="command">forwarders</strong></span></span></dt>
+<dd><p>Used to override the list of global forwarders.
+If it is not specified in a zone of type <span><strong class="command">forward</strong></span>,
+no forwarding is done for the zone; the global options are not used.</p></dd>
+<dt><span class="term"><span><strong class="command">ixfr-base</strong></span></span></dt>
+<dd><p>Was used in <span class="acronym">BIND</span> 8 to specify the name
 of the transaction log (journal) file for dynamic update and IXFR.
-<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 ignores the option and constructs the name of the journal
-file by appending "<TT
-CLASS="filename"
->.jnl</TT
->" to the name of the
-zone file.</P
-></DD
-><DT
-><B
-CLASS="command"
->ixfr-tmp-file</B
-></DT
-><DD
-><P
->Was an undocumented option in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8.
-Ignored in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9.</P
-></DD
-><DT
-><B
-CLASS="command"
->max-transfer-time-in</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->max-transfer-time-in</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->max-transfer-idle-in</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->max-transfer-idle-in</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->max-transfer-time-out</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->max-transfer-time-out</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->max-transfer-idle-out</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->max-transfer-idle-out</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->notify</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->notify</B
-> in <A
-HREF="Bv9ARM.ch06.html#boolean_options"
->Section 6.2.16.1</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->pubkey</B
-></DT
-><DD
-><P
->In <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 8, this option was intended for specifying
+<span class="acronym">BIND</span> 9 ignores the option and constructs the name of the journal
+file by appending "<code class="filename">.jnl</code>" to the name of the
+zone file.</p></dd>
+<dt><span class="term"><span><strong class="command">ixfr-tmp-file</strong></span></span></dt>
+<dd><p>Was an undocumented option in <span class="acronym">BIND</span> 8.
+Ignored in <span class="acronym">BIND</span> 9.</p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">max-transfer-time-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-idle-in</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">max-transfer-idle-in</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-time-out</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">max-transfer-time-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">max-transfer-idle-out</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">max-transfer-idle-out</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">notify</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">notify</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">pubkey</strong></span></span></dt>
+<dd><p>In <span class="acronym">BIND</span> 8, this option was intended for specifying
 a public zone key for verification of signatures in DNSSEC signed
-zones when they are loaded from disk. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 does not verify signatures
-on load and ignores the option.</P
-></DD
-><DT
-><B
-CLASS="command"
->zone-statistics</B
-></DT
-><DD
-><P
->If <KBD
-CLASS="userinput"
->yes</KBD
->, the server will keep statistical
+zones when they are loaded from disk. <span class="acronym">BIND</span> 9 does not verify signatures
+on load and ignores the option.</p></dd>
+<dt><span class="term"><span><strong class="command">zone-statistics</strong></span></span></dt>
+<dd><p>If <strong class="userinput"><code>yes</code></strong>, the server will keep statistical
 information for this zone, which can be dumped to the
-<B
-CLASS="command"
->statistics-file</B
-> defined in the server options.</P
-></DD
-><DT
-><B
-CLASS="command"
->sig-validity-interval</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->sig-validity-interval</B
-> in <A
-HREF="Bv9ARM.ch06.html#tuning"
->Section 6.2.16.15</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->transfer-source</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->transfer-source</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->
-</P
-></DD
-><DT
-><B
-CLASS="command"
->transfer-source-v6</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->transfer-source-v6</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->
-</P
-></DD
-><DT
-><B
-CLASS="command"
->alt-transfer-source</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->alt-transfer-source</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->
-</P
-></DD
-><DT
-><B
-CLASS="command"
->alt-transfer-source-v6</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->alt-transfer-source-v6</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->
-</P
-></DD
-><DT
-><B
-CLASS="command"
->use-alt-transfer-source</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->use-alt-transfer-source</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->
-</P
-></DD
-><DT
-><B
-CLASS="command"
->notify-source</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->notify-source</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->
-</P
-></DD
-><DT
-><B
-CLASS="command"
->notify-source-v6</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->notify-source-v6</B
-> in <A
-HREF="Bv9ARM.ch06.html#zone_transfers"
->Section 6.2.16.7</A
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->min-refresh-time</B
->, <B
-CLASS="command"
->max-refresh-time</B
->, <B
-CLASS="command"
->min-retry-time</B
->, <B
-CLASS="command"
->max-retry-time</B
-></DT
-><DD
-><P
->&#13;See the description in <A
-HREF="Bv9ARM.ch06.html#tuning"
->Section 6.2.16.15</A
->.
-</P
-></DD
-><DT
-><B
-CLASS="command"
->ixfr-from-differences</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->ixfr-from-differences</B
-> in <A
-HREF="Bv9ARM.ch06.html#boolean_options"
->Section 6.2.16.1</A
->.</P
-></DD
-><DT
-><B
-CLASS="command"
->key-directory</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->key-directory</B
-> in <A
-HREF="Bv9ARM.ch06.html#options"
->Section 6.2.16</A
-></P
-></DD
-><DT
-><B
-CLASS="command"
->multi-master</B
-></DT
-><DD
-><P
->See the description of
-<B
-CLASS="command"
->multi-master</B
-> in <A
-HREF="Bv9ARM.ch06.html#boolean_options"
->Section 6.2.16.1</A
->.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="dynamic_update_policies"
->6.2.24.4. Dynamic Update Policies</A
-></H3
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 supports two alternative methods of granting clients
+<span><strong class="command">statistics-file</strong></span> defined in the server options.</p></dd>
+<dt><span class="term"><span><strong class="command">sig-validity-interval</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">sig-validity-interval</strong></span> in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">transfer-source</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
+</p></dd>
+<dt><span class="term"><span><strong class="command">transfer-source-v6</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
+</p></dd>
+<dt><span class="term"><span><strong class="command">alt-transfer-source</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">alt-transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
+</p></dd>
+<dt><span class="term"><span><strong class="command">alt-transfer-source-v6</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">alt-transfer-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
+</p></dd>
+<dt><span class="term"><span><strong class="command">use-alt-transfer-source</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">use-alt-transfer-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
+</p></dd>
+<dt><span class="term"><span><strong class="command">notify-source</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">notify-source</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>
+</p></dd>
+<dt><span class="term"><span><strong class="command">notify-source-v6</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">notify-source-v6</strong></span> in <a href="Bv9ARM.ch06.html#zone_transfers" title="Zone Transfers">the section called &#8220;Zone Transfers&#8221;</a>.
+</p></dd>
+<dt>
+<span class="term"><span><strong class="command">min-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">max-refresh-time</strong></span>, </span><span class="term"><span><strong class="command">min-retry-time</strong></span>, </span><span class="term"><span><strong class="command">max-retry-time</strong></span></span>
+</dt>
+<dd><p>
+See the description in <a href="Bv9ARM.ch06.html#tuning" title="Tuning">the section called &#8220;Tuning&#8221;</a>.
+</p></dd>
+<dt><span class="term"><span><strong class="command">ixfr-from-differences</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">ixfr-from-differences</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.</p></dd>
+<dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">key-directory</strong></span> in <a href="Bv9ARM.ch06.html#options" title="options Statement Definition and Usage">the section called &#8220;<span><strong class="command">options</strong></span> Statement Definition and Usage&#8221;</a></p></dd>
+<dt><span class="term"><span><strong class="command">multi-master</strong></span></span></dt>
+<dd><p>See the description of
+<span><strong class="command">multi-master</strong></span> in <a href="Bv9ARM.ch06.html#boolean_options" title="Boolean Options">the section called &#8220;Boolean Options&#8221;</a>.</p></dd>
+</dl></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="dynamic_update_policies"></a>Dynamic Update Policies</h4></div></div></div>
+<p><span class="acronym">BIND</span> 9 supports two alternative methods of granting clients
 the right to perform dynamic updates to a zone, 
-configured by the <B
-CLASS="command"
->allow-update</B
-> and
-<B
-CLASS="command"
->update-policy</B
-> option, respectively.</P
-><P
->The <B
-CLASS="command"
->allow-update</B
-> clause works the same
-way as in previous versions of <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->. It grants given clients the
-permission to update any record of any name in the zone.</P
-><P
->The <B
-CLASS="command"
->update-policy</B
-> clause is new in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->
+configured by the <span><strong class="command">allow-update</strong></span> and
+<span><strong class="command">update-policy</strong></span> option, respectively.</p>
+<p>The <span><strong class="command">allow-update</strong></span> clause works the same
+way as in previous versions of <span class="acronym">BIND</span>. It grants given clients the
+permission to update any record of any name in the zone.</p>
+<p>The <span><strong class="command">update-policy</strong></span> clause is new in <span class="acronym">BIND</span>
 9 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
->Rules are specified in the <B
-CLASS="command"
->update-policy</B
-> zone
-option, and are only meaningful for master zones.  When the <B
-CLASS="command"
->update-policy</B
-> statement
-is present, it is a configuration error for the <B
-CLASS="command"
->allow-update</B
-> statement
-to be present.  The <B
-CLASS="command"
->update-policy</B
-> statement only
-examines the signer of a message; the source address is not relevant.</P
-><P
->This is how a rule definition looks:</P
-><PRE
-CLASS="programlisting"
->&#13;( <B
-CLASS="command"
->grant</B
-> | <B
-CLASS="command"
->deny</B
-> ) <VAR
-CLASS="replaceable"
->identity</VAR
-> <VAR
-CLASS="replaceable"
->nametype</VAR
-> <VAR
-CLASS="replaceable"
->name</VAR
-> [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->types</VAR
-> </SPAN
->]
-</PRE
-><P
->Each rule grants or denies privileges.  Once a message has
+be determined.</p>
+<p>Rules are specified in the <span><strong class="command">update-policy</strong></span> zone
+option, and are only meaningful for master zones.  When the <span><strong class="command">update-policy</strong></span> statement
+is present, it is a configuration error for the <span><strong class="command">allow-update</strong></span> statement
+to be present.  The <span><strong class="command">update-policy</strong></span> statement only
+examines the signer of a message; the source address is not relevant.</p>
+<p>This is how a rule definition looks:</p>
+<pre class="programlisting">
+( <span><strong class="command">grant</strong></span> | <span><strong class="command">deny</strong></span> ) <em class="replaceable"><code>identity</code></em> <em class="replaceable"><code>nametype</code></em> <em class="replaceable"><code>name</code></em> [<span class="optional"> <em class="replaceable"><code>types</code></em> </span>]
+</pre>
+<p>Each rule grants or denies privileges.  Once a message has
 successfully matched a rule, the operation is immediately granted
 or denied and no further rules are examined.  A rule is matched
 when the signer matches the identity field, the name matches the
 name field in accordance with the nametype field, and the type matches
-the types specified in the type field.</P
-><P
->The identity field specifies a name or a wildcard name.  Normally, this
+the types specified in the type field.</p>
+<p>The identity field specifies a name or a wildcard name.  Normally, this
 is the name of the TSIG or SIG(0) key used to sign the update request.  When a
 TKEY exchange has been used to create a shared secret, the identity of the
 shared secret is the same as the identity of the key used to authenticate the
-TKEY exchange.  When the <VAR
-CLASS="replaceable"
->identity</VAR
-> field specifies a
+TKEY exchange.  When the <em class="replaceable"><code>identity</code></em> field specifies a
 wildcard name, it is subject to DNS wildcard expansion, so the rule will apply
-to multiple identities.  The <VAR
-CLASS="replaceable"
->identity</VAR
-> field must
-contain a fully qualified domain name.</P
-><P
->The <VAR
-CLASS="replaceable"
->nametype</VAR
-> field has 4 values:
-<VAR
-CLASS="varname"
->name</VAR
->, <VAR
-CLASS="varname"
->subdomain</VAR
->,
-<VAR
-CLASS="varname"
->wildcard</VAR
->, and <VAR
-CLASS="varname"
->self</VAR
->.
-</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4009"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->name</VAR
-></P
-></TD
-><TD
-><P
->Exact-match semantics.  This rule matches when the
+to multiple identities.  The <em class="replaceable"><code>identity</code></em> field must
+contain a fully qualified domain name.</p>
+<p>The <em class="replaceable"><code>nametype</code></em> field has 4 values:
+<code class="varname">name</code>, <code class="varname">subdomain</code>,
+<code class="varname">wildcard</code>, and <code class="varname">self</code>.
+</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><code class="varname">name</code></p></td>
+<td><p>Exact-match semantics.  This rule matches when the
 name being updated is identical to the contents of the
-<VAR
-CLASS="replaceable"
->name</VAR
-> field.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->subdomain</VAR
-></P
-></TD
-><TD
-><P
->This rule matches when the name being updated
+<em class="replaceable"><code>name</code></em> field.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">subdomain</code></p></td>
+<td><p>This rule matches when the name being updated
 is a subdomain of, or identical to, the contents of the
-<VAR
-CLASS="replaceable"
->name</VAR
-> field.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->wildcard</VAR
-></P
-></TD
-><TD
-><P
->The <VAR
-CLASS="replaceable"
->name</VAR
-> field is
+<em class="replaceable"><code>name</code></em> field.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">wildcard</code></p></td>
+<td><p>The <em class="replaceable"><code>name</code></em> field is
 subject to DNS wildcard expansion, and this rule matches when the name
-being updated name is a valid expansion of the wildcard.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="varname"
->self</VAR
-></P
-></TD
-><TD
-><P
->This rule matches when the name being updated
-matches the contents of the <VAR
-CLASS="replaceable"
->identity</VAR
-> field.
-The <VAR
-CLASS="replaceable"
->name</VAR
-> field is ignored, but should be
-the same as the <VAR
-CLASS="replaceable"
->identity</VAR
-> field.  The
-<VAR
-CLASS="varname"
->self</VAR
-> nametype is most useful when allowing using
+being updated name is a valid expansion of the wildcard.</p></td>
+</tr>
+<tr>
+<td><p><code class="varname">self</code></p></td>
+<td><p>This rule matches when the name being updated
+matches the contents of the <em class="replaceable"><code>identity</code></em> field.
+The <em class="replaceable"><code>name</code></em> field is ignored, but should be
+the same as the <em class="replaceable"><code>identity</code></em> field.  The
+<code class="varname">self</code> nametype is most useful when allowing using
 one key per name to update, where the key has the same name as the name
-to be updated.  The <VAR
-CLASS="replaceable"
->identity</VAR
-> would be
-specified as <CODE
-CLASS="constant"
->*</CODE
-> in this case.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->In all cases, the <VAR
-CLASS="replaceable"
->name</VAR
-> field must
-specify a fully qualified domain name.</P
-><P
->If no types are explicitly specified, this rule matches all types except
+to be updated.  The <em class="replaceable"><code>identity</code></em> would be
+specified as <code class="constant">*</code> in this case.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>In all cases, the <em class="replaceable"><code>name</code></em> field must
+specify a fully qualified domain name.</p>
+<p>If no types are explicitly specified, this rule matches all types except
 SIG, NS, SOA, and NXT. Types may be specified by name, including
 "ANY" (ANY matches all types except NXT, which can never be updated).
 Note that when an attempt is made to delete all records associated with a
 name, the rules are checked for each existing record type.
-</P
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN4050"
->6.3. Zone File</A
-></H1
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="types_of_resource_records_and_when_to_use_them"
->6.3.1. Types of Resource Records and When to Use Them</A
-></H2
-><P
->This section, largely borrowed from RFC 1034, describes the
+</p>
+</div>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2564557"></a>Zone File</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div>
+<p>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
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN4055"
->6.3.1.1. Resource Records</A
-></H3
-><P
->A domain name identifies a node.  Each node has a set of
+and implemented in the DNS. These are also included.</p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2564576"></a>Resource Records</h4></div></div></div>
+<p>A domain name identifies a node.  Each node has a set of
         resource information, which may be empty.  The set of resource
         information associated with a particular name is composed of
         separate RRs. The order of RRs in a set is not significant and
         need not be preserved by name servers, resolvers, or other
         parts of the DNS. However, sorting of multiple RRs is
         permitted for optimization purposes, for example, to specify
-        that a particular nearby server be tried first. See <A
-HREF="Bv9ARM.ch06.html#the_sortlist_statement"
->Section 6.2.16.13</A
-> and <A
-HREF="Bv9ARM.ch06.html#rrset_ordering"
->Section 6.2.16.14</A
->.</P
-><P
->The components of a Resource Record are:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4061"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
->owner name</P
-></TD
-><TD
-><P
->the domain name where the RR is found.</P
-></TD
-></TR
-><TR
-><TD
-><P
->type</P
-></TD
-><TD
-><P
->an encoded 16 bit value that specifies
-the type of the resource record.</P
-></TD
-></TR
-><TR
-><TD
-><P
->TTL</P
-></TD
-><TD
-><P
->the time to live of the RR. This field
+        that a particular nearby server be tried first. See <a href="Bv9ARM.ch06.html#the_sortlist_statement" title="The sortlist Statement">the section called &#8220;The <span><strong class="command">sortlist</strong></span> Statement&#8221;</a> and <a href="Bv9ARM.ch06.html#rrset_ordering" title="RRset Ordering">the section called &#8220;RRset Ordering&#8221;</a>.</p>
+<p>The components of a Resource Record are:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p>owner name</p></td>
+<td><p>the domain name where the RR is found.</p></td>
+</tr>
+<tr>
+<td><p>type</p></td>
+<td><p>an encoded 16 bit value that specifies
+the type of the resource record.</p></td>
+</tr>
+<tr>
+<td><p>TTL</p></td>
+<td><p>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
-><TR
-><TD
-><P
->class</P
-></TD
-><TD
-><P
->an encoded 16 bit value that identifies
-a protocol family or instance of a protocol.</P
-></TD
-></TR
-><TR
-><TD
-><P
->RDATA</P
-></TD
-><TD
-><P
->the resource data.  The format of the
-data is type (and sometimes class) specific.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->The following are <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->types</I
-></SPAN
-> of valid RRs:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4093"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
->A</P
-></TD
-><TD
-><P
->a host address.  In the IN class, this is a
-32-bit IP address.  Described in RFC 1035.</P
-></TD
-></TR
-><TR
-><TD
-><P
->AAAA</P
-></TD
-><TD
-><P
->IPv6 address.  Described in RFC 1886.</P
-></TD
-></TR
-><TR
-><TD
-><P
->A6</P
-></TD
-><TD
-><P
->IPv6 address.  This can be a partial
+be cached before it should be discarded.</p></td>
+</tr>
+<tr>
+<td><p>class</p></td>
+<td><p>an encoded 16 bit value that identifies
+a protocol family or instance of a protocol.</p></td>
+</tr>
+<tr>
+<td><p>RDATA</p></td>
+<td><p>the resource data.  The format of the
+data is type (and sometimes class) specific.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>The following are <span class="emphasis"><em>types</em></span> of valid RRs:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p>A</p></td>
+<td><p>a host address.  In the IN class, this is a
+32-bit IP address.  Described in RFC 1035.</p></td>
+</tr>
+<tr>
+<td><p>AAAA</p></td>
+<td><p>IPv6 address.  Described in RFC 1886.</p></td>
+</tr>
+<tr>
+<td><p>A6</p></td>
+<td><p>IPv6 address.  This can be a partial
 address (a suffix) and an indirection to the name where the rest of the
-address (the prefix) can be found.  Experimental.  Described in RFC 2874.</P
-></TD
-></TR
-><TR
-><TD
-><P
->AFSDB</P
-></TD
-><TD
-><P
->location of AFS database servers.
-Experimental.  Described in RFC 1183.</P
-></TD
-></TR
-><TR
-><TD
-><P
->APL</P
-></TD
-><TD
-><P
->address prefix list.  Experimental.
-Described in RFC 3123.</P
-></TD
-></TR
-><TR
-><TD
-><P
->CERT</P
-></TD
-><TD
-><P
->holds a digital certificate.
-Described in RFC 2538.</P
-></TD
-></TR
-><TR
-><TD
-><P
->CNAME</P
-></TD
-><TD
-><P
->identifies the canonical name of an alias.
-Described in RFC 1035.</P
-></TD
-></TR
-><TR
-><TD
-><P
->DNAME</P
-></TD
-><TD
-><P
->Replaces the domain name specified with
+address (the prefix) can be found.  Experimental.  Described in RFC 2874.</p></td>
+</tr>
+<tr>
+<td><p>AFSDB</p></td>
+<td><p>location of AFS database servers.
+Experimental.  Described in RFC 1183.</p></td>
+</tr>
+<tr>
+<td><p>APL</p></td>
+<td><p>address prefix list.  Experimental.
+Described in RFC 3123.</p></td>
+</tr>
+<tr>
+<td><p>CERT</p></td>
+<td><p>holds a digital certificate.
+Described in RFC 2538.</p></td>
+</tr>
+<tr>
+<td><p>CNAME</p></td>
+<td><p>identifies the canonical name of an alias.
+Described in RFC 1035.</p></td>
+</tr>
+<tr>
+<td><p>DNAME</p></td>
+<td><p>Replaces the domain name specified with
 another name to be looked up, effectively aliasing an entire
 subtree of the domain name space rather than a single record
 as in the case of the CNAME RR.
-Described in RFC 2672.</P
-></TD
-></TR
-><TR
-><TD
-><P
->GPOS</P
-></TD
-><TD
-><P
->Specifies the global position.  Superseded by LOC.</P
-></TD
-></TR
-><TR
-><TD
-><P
->HINFO</P
-></TD
-><TD
-><P
->identifies the CPU and OS used by a host.
-Described in RFC 1035.</P
-></TD
-></TR
-><TR
-><TD
-><P
->ISDN</P
-></TD
-><TD
-><P
->representation of ISDN addresses.
-Experimental.  Described in RFC 1183.</P
-></TD
-></TR
-><TR
-><TD
-><P
->KEY</P
-></TD
-><TD
-><P
->stores a public key associated with a
-DNS name.  Described in RFC 2535.</P
-></TD
-></TR
-><TR
-><TD
-><P
->KX</P
-></TD
-><TD
-><P
->identifies a key exchanger for this
-DNS name.  Described in RFC 2230.</P
-></TD
-></TR
-><TR
-><TD
-><P
->LOC</P
-></TD
-><TD
-><P
->for storing GPS info.  Described in RFC 1876.
-Experimental.</P
-></TD
-></TR
-><TR
-><TD
-><P
->MX</P
-></TD
-><TD
-><P
->identifies a mail exchange for the domain.
+Described in RFC 2672.</p></td>
+</tr>
+<tr>
+<td><p>GPOS</p></td>
+<td><p>Specifies the global position.  Superseded by LOC.</p></td>
+</tr>
+<tr>
+<td><p>HINFO</p></td>
+<td><p>identifies the CPU and OS used by a host.
+Described in RFC 1035.</p></td>
+</tr>
+<tr>
+<td><p>ISDN</p></td>
+<td><p>representation of ISDN addresses.
+Experimental.  Described in RFC 1183.</p></td>
+</tr>
+<tr>
+<td><p>KEY</p></td>
+<td><p>stores a public key associated with a
+DNS name.  Described in RFC 2535.</p></td>
+</tr>
+<tr>
+<td><p>KX</p></td>
+<td><p>identifies a key exchanger for this
+DNS name.  Described in RFC 2230.</p></td>
+</tr>
+<tr>
+<td><p>LOC</p></td>
+<td><p>for storing GPS info.  Described in RFC 1876.
+Experimental.</p></td>
+</tr>
+<tr>
+<td><p>MX</p></td>
+<td><p>identifies a mail exchange for the domain.
 a 16 bit preference value (lower is better)
 followed by the host name of the mail exchange.
-Described in RFC 974, RFC 1035.</P
-></TD
-></TR
-><TR
-><TD
-><P
->NAPTR</P
-></TD
-><TD
-><P
->name authority pointer.  Described in RFC 2915.</P
-></TD
-></TR
-><TR
-><TD
-><P
->NSAP</P
-></TD
-><TD
-><P
->a network service access point.
-Described in RFC 1706.</P
-></TD
-></TR
-><TR
-><TD
-><P
->NS</P
-></TD
-><TD
-><P
->the authoritative name server for the
-domain.  Described in RFC 1035.</P
-></TD
-></TR
-><TR
-><TD
-><P
->NXT</P
-></TD
-><TD
-><P
->used in DNSSEC to securely indicate that
+Described in RFC 974, RFC 1035.</p></td>
+</tr>
+<tr>
+<td><p>NAPTR</p></td>
+<td><p>name authority pointer.  Described in RFC 2915.</p></td>
+</tr>
+<tr>
+<td><p>NSAP</p></td>
+<td><p>a network service access point.
+Described in RFC 1706.</p></td>
+</tr>
+<tr>
+<td><p>NS</p></td>
+<td><p>the authoritative name server for the
+domain.  Described in RFC 1035.</p></td>
+</tr>
+<tr>
+<td><p>NXT</p></td>
+<td><p>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.
-Described in RFC 2535.</P
-></TD
-></TR
-><TR
-><TD
-><P
->PTR</P
-></TD
-><TD
-><P
->a pointer to another part of the domain
-name space.  Described in RFC 1035.</P
-></TD
-></TR
-><TR
-><TD
-><P
->PX</P
-></TD
-><TD
-><P
->provides mappings between RFC 822 and X.400
-addresses.  Described in RFC 2163.</P
-></TD
-></TR
-><TR
-><TD
-><P
->RP</P
-></TD
-><TD
-><P
->information on persons responsible
-for the domain.  Experimental.  Described in RFC 1183.</P
-></TD
-></TR
-><TR
-><TD
-><P
->RT</P
-></TD
-><TD
-><P
->route-through binding for hosts that
+Described in RFC 2535.</p></td>
+</tr>
+<tr>
+<td><p>PTR</p></td>
+<td><p>a pointer to another part of the domain
+name space.  Described in RFC 1035.</p></td>
+</tr>
+<tr>
+<td><p>PX</p></td>
+<td><p>provides mappings between RFC 822 and X.400
+addresses.  Described in RFC 2163.</p></td>
+</tr>
+<tr>
+<td><p>RP</p></td>
+<td><p>information on persons responsible
+for the domain.  Experimental.  Described in RFC 1183.</p></td>
+</tr>
+<tr>
+<td><p>RT</p></td>
+<td><p>route-through binding for hosts that
 do not have their own direct wide area network addresses.
-Experimental.  Described in RFC 1183.</P
-></TD
-></TR
-><TR
-><TD
-><P
->SIG</P
-></TD
-><TD
-><P
->("signature") contains data authenticated
-in the secure DNS.  Described in RFC 2535.</P
-></TD
-></TR
-><TR
-><TD
-><P
->SOA</P
-></TD
-><TD
-><P
->identifies the start of a zone of authority.
-Described in RFC 1035.</P
-></TD
-></TR
-><TR
-><TD
-><P
->SRV</P
-></TD
-><TD
-><P
->information about well known network
-services (replaces WKS).  Described in RFC 2782.</P
-></TD
-></TR
-><TR
-><TD
-><P
->TXT</P
-></TD
-><TD
-><P
->text records.  Described in RFC 1035.</P
-></TD
-></TR
-><TR
-><TD
-><P
->WKS</P
-></TD
-><TD
-><P
->information about which well known
+Experimental.  Described in RFC 1183.</p></td>
+</tr>
+<tr>
+<td><p>SIG</p></td>
+<td><p>("signature") contains data authenticated
+in the secure DNS.  Described in RFC 2535.</p></td>
+</tr>
+<tr>
+<td><p>SOA</p></td>
+<td><p>identifies the start of a zone of authority.
+Described in RFC 1035.</p></td>
+</tr>
+<tr>
+<td><p>SRV</p></td>
+<td><p>information about well known network
+services (replaces WKS).  Described in RFC 2782.</p></td>
+</tr>
+<tr>
+<td><p>TXT</p></td>
+<td><p>text records.  Described in RFC 1035.</p></td>
+</tr>
+<tr>
+<td><p>WKS</p></td>
+<td><p>information about which well known
 network services, such as SMTP, that a domain supports. Historical.
-</P
-></TD
-></TR
-><TR
-><TD
-><P
->X25</P
-></TD
-><TD
-><P
->representation of X.25 network addresses.
-Experimental.  Described in RFC 1183.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->The following <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->classes</I
-></SPAN
-> of resource records
-are currently valid in the DNS:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4245"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
->IN</P
-></TD
-><TD
-><P
->The Internet.</P
-></TD
-></TR
-><TR
-><TD
-><P
->CH</P
-></TD
-><TD
-><P
->&#13;CHAOSnet, a LAN protocol created at MIT in the mid-1970s.
+</p></td>
+</tr>
+<tr>
+<td><p>X25</p></td>
+<td><p>representation of X.25 network addresses.
+Experimental.  Described in RFC 1183.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>The following <span class="emphasis"><em>classes</em></span> of resource records
+are currently valid in the DNS:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p>IN</p></td>
+<td><p>The Internet.</p></td>
+</tr>
+<tr>
+<td><p>CH</p></td>
+<td><p>
+CHAOSnet, a LAN protocol created at MIT in the mid-1970s.
 Rarely used for its historical purpose, but reused for BIND's
 built-in server information zones, e.g.,
-<VAR
-CLASS="literal"
->version.bind</VAR
->.
-</P
-></TD
-></TR
-><TR
-><TD
-><P
->HS</P
-></TD
-><TD
-><P
->&#13;Hesiod, an information service
+<code class="literal">version.bind</code>.
+</p></td>
+</tr>
+<tr>
+<td><p>HS</p></td>
+<td><p>
+Hesiod, an information service
 developed by MIT's Project Athena. It is used to share information
 about various systems databases, such as users, groups, printers
 and so on.
-</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->The owner name is often implicit, rather than forming an integral
+</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>The owner name is often implicit, rather than forming an integral
 part of the RR.  For example, many name servers internally form tree
 or hash structures for the name space, and chain RRs off nodes.
  The remaining RR parts are the fixed header (type, class, TTL)
 which is consistent for all RRs, and a variable part (RDATA) that
-fits the needs of the resource being described.</P
-><P
->The meaning of the TTL field is a time limit on how long an
+fits the needs of the resource being described.</p>
+<p>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
@@ -10302,288 +3439,112 @@ 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
->The data in the RDATA section of RRs is carried as a combination
+the change.</p>
+<p>The data in the RDATA section of RRs is carried as a combination
 of binary strings and domain names.  The domain names are frequently
-used as "pointers" to other data in the DNS.</P
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN4269"
->6.3.1.2. Textual expression of RRs</A
-></H3
-><P
->RRs are represented in binary form in the packets of the DNS
+used as "pointers" to other data in the DNS.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2565564"></a>Textual expression of RRs</h4></div></div></div>
+<p>RRs are represented in binary form in the packets of the DNS
 protocol, and are usually represented in highly encoded form when
 stored in a name server or resolver.  In the examples provided in
 RFC 1034, a style similar to that used in master files was employed
 in order to show the contents of RRs.  In this format, most RRs
 are shown on a single line, although continuation lines are possible
-using parentheses.</P
-><P
->The start of the line gives the owner of the RR.  If a line
+using parentheses.</p>
+<p>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
->Following the owner, we list the TTL, type, and class of the
+that of the previous RR.  Blank lines are often included for readability.</p>
+<p>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
->The resource data or RDATA section of the RR are given using
-knowledge of the typical representation for the data.</P
-><P
->For example, we might show the RRs carried in a message as:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4276"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->ISI.EDU.</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->MX</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10 VENERA.ISI.EDU.</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->MX</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10 VAXA.ISI.EDU</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->VENERA.ISI.EDU</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->128.9.0.32</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10.1.0.52</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->VAXA.ISI.EDU</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10.2.0.27</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->128.9.0.33</VAR
-></P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->The MX RRs have an RDATA section which consists of a 16 bit
+are often omitted from examples in the interests of clarity.</p>
+<p>The resource data or RDATA section of the RR are given using
+knowledge of the typical representation for the data.</p>
+<p>For example, we might show the RRs carried in a message as:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><code class="literal">ISI.EDU.</code></p></td>
+<td><p><code class="literal">MX</code></p></td>
+<td><p><code class="literal">10 VENERA.ISI.EDU.</code></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p><code class="literal">MX</code></p></td>
+<td><p><code class="literal">10 VAXA.ISI.EDU</code></p></td>
+</tr>
+<tr>
+<td><p><code class="literal">VENERA.ISI.EDU</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">128.9.0.32</code></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">10.1.0.52</code></p></td>
+</tr>
+<tr>
+<td><p><code class="literal">VAXA.ISI.EDU</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">10.2.0.27</code></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">128.9.0.33</code></p></td>
+</tr>
+</tbody>
+</table></div>
+<p>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
->This example shows six RRs, with two RRs at each of three
-domain names.</P
-><P
->Similarly we might see:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4342"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->XX.LCS.MIT.EDU. IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10.0.0.44</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->CH</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->MIT.EDU. 2420</VAR
-></P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->This example shows two addresses for <VAR
-CLASS="literal"
->XX.LCS.MIT.EDU</VAR
->,
-each of a different class.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN4370"
->6.3.2. Discussion of MX Records</A
-></H2
-><P
->As described above, domain servers store information as a
+IP address format to contain a 32 bit internet address.</p>
+<p>This example shows six RRs, with two RRs at each of three
+domain names.</p>
+<p>Similarly we might see:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><code class="literal">XX.LCS.MIT.EDU. IN</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">10.0.0.44</code></p></td>
+</tr>
+<tr>
+<td><p><code class="literal">CH</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">MIT.EDU. 2420</code></p></td>
+</tr>
+</tbody>
+</table></div>
+<p>This example shows two addresses for <code class="literal">XX.LCS.MIT.EDU</code>,
+each of a different class.</p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2565990"></a>Discussion of MX Records</h3></div></div></div>
+<p>As described above, domain servers store information as a
 series of resource records, each of which contains a particular
 piece of information about a given domain name (which is usually,
 but not always, a host). The simplest way to think of a RR is as
 a typed pair of data, a domain name matched with a relevant datum,
 and stored with some additional type information to help systems 
-determine when the RR is relevant.</P
-><P
->MX records are used to control delivery of email. The data
+determine when the RR is relevant.</p>
+<p>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
@@ -10591,320 +3552,110 @@ 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 &#8212; 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 <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->must</I
-></SPAN
-> have
-an associated A record &#8212; CNAME is not sufficient.</P
-><P
->For a given domain, if there is both a CNAME record and an
+name given is the machine to which the mail will be delivered. It <span class="emphasis"><em>must</em></span> have
+an associated A record &#8212; CNAME is not sufficient.</p>
+<p>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
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4376"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->example.com.</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->MX</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->mail.example.com.</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->MX</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->mail2.example.com.</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->MX</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->20</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->mail.backup.org.</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->mail.example.com.</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10.0.0.1</VAR
-></P
-></TD
-><TD
-><P
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->mail2.example.com.</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->A</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->10.0.0.2</VAR
-></P
-></TD
-><TD
-><P
-></P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->For example:</P
-><P
->Mail delivery will be attempted to <VAR
-CLASS="literal"
->mail.example.com</VAR
-> and
-<VAR
-CLASS="literal"
->mail2.example.com</VAR
-> (in
-any order), and if neither of those succeed, delivery to <VAR
-CLASS="literal"
->mail.backup.org</VAR
-> will
-be attempted.</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="Setting_TTLs"
->6.3.3. Setting TTLs</A
-></H2
-><P
->The time to live of the RR field is a 32 bit integer represented
+pointed to by the CNAME.</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><code class="literal">example.com.</code></p></td>
+<td><p><code class="literal">IN</code></p></td>
+<td><p><code class="literal">MX</code></p></td>
+<td><p><code class="literal">10</code></p></td>
+<td><p><code class="literal">mail.example.com.</code></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p><code class="literal">IN</code></p></td>
+<td><p><code class="literal">MX</code></p></td>
+<td><p><code class="literal">10</code></p></td>
+<td><p><code class="literal">mail2.example.com.</code></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p><code class="literal">IN</code></p></td>
+<td><p><code class="literal">MX</code></p></td>
+<td><p><code class="literal">20</code></p></td>
+<td><p><code class="literal">mail.backup.org.</code></p></td>
+</tr>
+<tr>
+<td><p><code class="literal">mail.example.com.</code></p></td>
+<td><p><code class="literal">IN</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">10.0.0.1</code></p></td>
+<td><p></p></td>
+</tr>
+<tr>
+<td><p><code class="literal">mail2.example.com.</code></p></td>
+<td><p><code class="literal">IN</code></p></td>
+<td><p><code class="literal">A</code></p></td>
+<td><p><code class="literal">10.0.0.2</code></p></td>
+<td><p></p></td>
+</tr>
+</tbody>
+</table></div>
+<p>For example:</p>
+<p>Mail delivery will be attempted to <code class="literal">mail.example.com</code> and
+<code class="literal">mail2.example.com</code> (in
+any order), and if neither of those succeed, delivery to <code class="literal">mail.backup.org</code> will
+be attempted.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="Setting_TTLs"></a>Setting TTLs</h3></div></div></div>
+<p>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
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4468"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
->SOA</P
-></TD
-><TD
-><P
->The last field in the SOA is the negative
+used in a zone file.</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p>SOA</p></td>
+<td>
+<p>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
->The maximum time for
-negative caching is 3 hours (3h).</P
-></TD
-></TR
-><TR
-><TD
-><P
->$TTL</P
-></TD
-><TD
-><P
->The $TTL directive at the top of the
+(NXDOMAIN) responses from you.</p>
+<p>The maximum time for
+negative caching is 3 hours (3h).</p>
+</td>
+</tr>
+<tr>
+<td><p>$TTL</p></td>
+<td><p>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
-><TR
-><TD
-><P
->RR TTLs</P
-></TD
-><TD
-><P
->Each RR can have a TTL as the second
+a specific TTL set.</p></td>
+</tr>
+<tr>
+<td><p>RR TTLs</p></td>
+<td><p>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
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->All of these TTLs default to units of seconds, though units
-can be explicitly specified, for example, <VAR
-CLASS="literal"
->1h30m</VAR
->. </P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN4491"
->6.3.4. Inverse Mapping in IPv4</A
-></H2
-><P
->Reverse name resolution (that is, translation from IP address
-to name) is achieved by means of the <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->in-addr.arpa</I
-></SPAN
-> domain
+the it.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>All of these TTLs default to units of seconds, though units
+can be explicitly specified, for example, <code class="literal">1h30m</code>. </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2566487"></a>Inverse Mapping in IPv4</h3></div></div></div>
+<p>Reverse name resolution (that is, translation from IP address
+to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> 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,
@@ -10913,647 +3664,201 @@ in-addr.arpa name of
 3.2.1.10.in-addr.arpa. This name should have a PTR resource record
 whose data field is the name of the machine or, optionally, multiple
 PTR records if the machine has more than one name. For example,
-in the [<SPAN
-CLASS="optional"
->example.com</SPAN
->] domain:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4496"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->$ORIGIN</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->2.1.10.in-addr.arpa</VAR
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-><VAR
-CLASS="literal"
->3</VAR
-></P
-></TD
-><TD
-><P
-><VAR
-CLASS="literal"
->IN PTR foo.example.com.</VAR
-></P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->The <B
-CLASS="command"
->$ORIGIN</B
-> lines in the examples
+in the [<span class="optional">example.com</span>] domain:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><code class="literal">$ORIGIN</code></p></td>
+<td><p><code class="literal">2.1.10.in-addr.arpa</code></p></td>
+</tr>
+<tr>
+<td><p><code class="literal">3</code></p></td>
+<td><p><code class="literal">IN PTR foo.example.com.</code></p></td>
+</tr>
+</tbody>
+</table></div>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>The <span><strong class="command">$ORIGIN</strong></span> 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
-></BLOCKQUOTE
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN4518"
->6.3.5. Other Zone File Directives</A
-></H2
-><P
->The Master File Format was initially defined in RFC 1035 and
+that the example is relative to the listed origin.</p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2566593"></a>Other Zone File Directives</h3></div></div></div>
+<p>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
->Master File Directives include <B
-CLASS="command"
->$ORIGIN</B
->, <B
-CLASS="command"
->$INCLUDE</B
->,
-and <B
-CLASS="command"
->$TTL.</B
-></P
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN4525"
->6.3.5.1. The <B
-CLASS="command"
->$ORIGIN</B
-> Directive</A
-></H3
-><P
->Syntax: <B
-CLASS="command"
->$ORIGIN
-</B
-><VAR
-CLASS="replaceable"
->domain-name</VAR
-> [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->comment</VAR
-></SPAN
->]</P
-><P
-><B
-CLASS="command"
->$ORIGIN</B
-> sets the domain name that will
+class.</p>
+<p>Master File Directives include <span><strong class="command">$ORIGIN</strong></span>, <span><strong class="command">$INCLUDE</strong></span>,
+and <span><strong class="command">$TTL.</strong></span></p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2566612"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
+<p>Syntax: <span><strong class="command">$ORIGIN
+</strong></span><em class="replaceable"><code>domain-name</code></em> [<span class="optional"> <em class="replaceable"><code>comment</code></em></span>]</p>
+<p><span><strong class="command">$ORIGIN</strong></span> sets the domain name that will
 be appended to any unqualified records. When a zone is first read
-in there is an implicit <B
-CLASS="command"
->$ORIGIN</B
-> &#60;<VAR
-CLASS="varname"
->zone-name</VAR
->&#62;<B
-CLASS="command"
->.</B
-> The
-current <B
-CLASS="command"
->$ORIGIN</B
-> is appended to the domain specified
-in the <B
-CLASS="command"
->$ORIGIN</B
-> argument if it is not absolute.</P
-><PRE
-CLASS="programlisting"
-><VAR
-CLASS="literal"
->$ORIGIN example.com.
-WWW     CNAME   MAIN-SERVER</VAR
-></PRE
-><P
->is equivalent to</P
-><PRE
-CLASS="programlisting"
-><VAR
-CLASS="literal"
->WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</VAR
-></PRE
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN4545"
->6.3.5.2. The <B
-CLASS="command"
->$INCLUDE</B
-> Directive</A
-></H3
-><P
->Syntax: <B
-CLASS="command"
->$INCLUDE</B
->
-<VAR
-CLASS="replaceable"
->filename</VAR
-> [<SPAN
-CLASS="optional"
->&#13;<VAR
-CLASS="replaceable"
->origin</VAR
-> </SPAN
->] [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->comment</VAR
-> </SPAN
->]</P
-><P
->Read and process the file <TT
-CLASS="filename"
->filename</TT
-> as
-if it were included into the file at this point.  If <B
-CLASS="command"
->origin</B
-> is
-specified the file is processed with <B
-CLASS="command"
->$ORIGIN</B
-> set
-to that value, otherwise the current <B
-CLASS="command"
->$ORIGIN</B
-> is
-used.</P
-><P
->The origin and the current domain name
-revert to the values they had prior to the <B
-CLASS="command"
->$INCLUDE</B
-> once
-the file has been read.</P
-><DIV
-CLASS="note"
-><BLOCKQUOTE
-CLASS="note"
-><P
-><B
->Note: </B
->
+in there is an implicit <span><strong class="command">$ORIGIN</strong></span> &lt;<code class="varname">zone-name</code>&gt;<span><strong class="command">.</strong></span> The
+current <span><strong class="command">$ORIGIN</strong></span> is appended to the domain specified
+in the <span><strong class="command">$ORIGIN</strong></span> argument if it is not absolute.</p>
+<pre class="programlisting">$ORIGIN example.com.
+WWW     CNAME   MAIN-SERVER</pre>
+<p>is equivalent to</p>
+<pre class="programlisting">WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.</pre>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2566667"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
+<p>Syntax: <span><strong class="command">$INCLUDE</strong></span>
+<em class="replaceable"><code>filename</code></em> [<span class="optional">
+<em class="replaceable"><code>origin</code></em> </span>] [<span class="optional"> <em class="replaceable"><code>comment</code></em> </span>]</p>
+<p>Read and process the file <code class="filename">filename</code> as
+if it were included into the file at this point.  If <span><strong class="command">origin</strong></span> is
+specified the file is processed with <span><strong class="command">$ORIGIN</strong></span> set
+to that value, otherwise the current <span><strong class="command">$ORIGIN</strong></span> is
+used.</p>
+<p>The origin and the current domain name
+revert to the values they had prior to the <span><strong class="command">$INCLUDE</strong></span> once
+the file has been read.</p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
 RFC 1035 specifies that the current origin should be restored after
-an <B
-CLASS="command"
->$INCLUDE</B
->, but it is silent on whether the current
+an <span><strong class="command">$INCLUDE</strong></span>, but it is silent on whether the current
 domain name should also be restored.  BIND 9 restores both of them.
 This could be construed as a deviation from RFC 1035, a feature, or both.
-</P
-></BLOCKQUOTE
-></DIV
-></DIV
-><DIV
-CLASS="sect3"
-><H3
-CLASS="sect3"
-><A
-NAME="AEN4565"
->6.3.5.3. The <B
-CLASS="command"
->$TTL</B
-> Directive</A
-></H3
-><P
->Syntax: <B
-CLASS="command"
->$TTL</B
->
-<VAR
-CLASS="replaceable"
->default-ttl</VAR
-> [<SPAN
-CLASS="optional"
->&#13;<VAR
-CLASS="replaceable"
->comment</VAR
-> </SPAN
->]</P
-><P
->Set the default Time To Live (TTL) for subsequent records
-with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.</P
-><P
-><B
-CLASS="command"
->$TTL</B
-> is defined in RFC 2308.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN4576"
->6.3.6. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> Master File Extension: the  <B
-CLASS="command"
->$GENERATE</B
-> Directive</A
-></H2
-><P
->Syntax: <B
-CLASS="command"
->$GENERATE</B
-> <VAR
-CLASS="replaceable"
->range</VAR
-> <VAR
-CLASS="replaceable"
->lhs</VAR
-> [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->ttl</VAR
-></SPAN
->] [<SPAN
-CLASS="optional"
-><VAR
-CLASS="replaceable"
->class</VAR
-></SPAN
->] <VAR
-CLASS="replaceable"
->type</VAR
-> <VAR
-CLASS="replaceable"
->rhs</VAR
-> [<SPAN
-CLASS="optional"
-> <VAR
-CLASS="replaceable"
->comment</VAR
-> </SPAN
->]</P
-><P
-><B
-CLASS="command"
->$GENERATE</B
-> is used to create a series of
-resource records that only differ from each other by an iterator. <B
-CLASS="command"
->$GENERATE</B
-> can
+</p>
+</div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2566730"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
+<p>Syntax: <span><strong class="command">$TTL</strong></span>
+<em class="replaceable"><code>default-ttl</code></em> [<span class="optional">
+<em class="replaceable"><code>comment</code></em> </span>]</p>
+<p>Set the default Time To Live (TTL) for subsequent records
+with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.</p>
+<p><span><strong class="command">$TTL</strong></span> is defined in RFC 2308.</p>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2566761"></a><span class="acronym">BIND</span> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
+<p>Syntax: <span><strong class="command">$GENERATE</strong></span> <em class="replaceable"><code>range</code></em> <em class="replaceable"><code>lhs</code></em> [<span class="optional"><em class="replaceable"><code>ttl</code></em></span>] [<span class="optional"><em class="replaceable"><code>class</code></em></span>] <em class="replaceable"><code>type</code></em> <em class="replaceable"><code>rhs</code></em> [<span class="optional"> <em class="replaceable"><code>comment</code></em> </span>]</p>
+<p><span><strong class="command">$GENERATE</strong></span> is used to create a series of
+resource records that only differ from each other by an iterator. <span><strong class="command">$GENERATE</strong></span> can
 be used to easily generate the sets of records required to support
 sub /24 reverse delegations described in RFC 2317: Classless IN-ADDR.ARPA
-delegation.</P
-><PRE
-CLASS="programlisting"
-><VAR
-CLASS="literal"
->$ORIGIN 0.0.192.IN-ADDR.ARPA.
+delegation.</p>
+<pre class="programlisting">$ORIGIN 0.0.192.IN-ADDR.ARPA.
 $GENERATE 1-2 0 NS SERVER$.EXAMPLE.
-$GENERATE 1-127 $ CNAME $.0</VAR
-></PRE
-><P
->is equivalent to</P
-><PRE
-CLASS="programlisting"
-><VAR
-CLASS="literal"
->0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
+$GENERATE 1-127 $ CNAME $.0</pre>
+<p>is equivalent to</p>
+<pre class="programlisting">0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE.
 0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
 1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
 2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
 ...
 127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
-</VAR
-></PRE
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4600"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
-><B
-CLASS="command"
->range</B
-></P
-></TD
-><TD
-><P
->This can be one of two forms: start-stop
+</pre>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p><span><strong class="command">range</strong></span></p></td>
+<td><p>This can be one of two forms: start-stop
 or start-stop/step. If the first form is used then step is set to
-        1. All of start, stop and step must be positive.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->lhs</B
-></P
-></TD
-><TD
-><P
-><B
-CLASS="command"
->lhs</B
-> describes the
-owner name of the resource records to be created.      Any single <B
-CLASS="command"
->$</B
-> symbols
-within the <B
-CLASS="command"
->lhs</B
-> side are replaced by the iterator
+        1. All of start, stop and step must be positive.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">lhs</strong></span></p></td>
+<td>
+<p><span><strong class="command">lhs</strong></span> describes the
+owner name of the resource records to be created.      Any single <span><strong class="command">$</strong></span> symbols
+within the <span><strong class="command">lhs</strong></span> side are replaced by the iterator
 value.
-To get a $ in the output you need to escape the <B
-CLASS="command"
->$</B
->
-using a backslash <B
-CLASS="command"
->\</B
->,
-e.g. <B
-CLASS="command"
->\$</B
->. The <B
-CLASS="command"
->$</B
-> may optionally be followed
+To get a $ in the output you need to escape the <span><strong class="command">$</strong></span>
+using a backslash <span><strong class="command">\</strong></span>,
+e.g. <span><strong class="command">\$</strong></span>. The <span><strong class="command">$</strong></span> may optionally be followed
 by modifiers which change the offset from the iterator, field width and base. 
-Modifiers are introduced by a <B
-CLASS="command"
->{</B
-> immediately following the
-<B
-CLASS="command"
->$</B
-> as <B
-CLASS="command"
->${offset[,width[,base]]}</B
->.
-e.g. <B
-CLASS="command"
->${-20,3,d}</B
-> which subtracts 20 from the current value,
+Modifiers are introduced by a <span><strong class="command">{</strong></span> immediately following the
+<span><strong class="command">$</strong></span> as <span><strong class="command">${offset[,width[,base]]}</strong></span>.
+e.g. <span><strong class="command">${-20,3,d}</strong></span> which subtracts 20 from the current value,
 prints the result as a decimal in a zero padded field of with 3.  Available
-output forms are decimal (<B
-CLASS="command"
->d</B
->), octal (<B
-CLASS="command"
->o</B
->)
-and hexadecimal (<B
-CLASS="command"
->x</B
-> or <B
-CLASS="command"
->X</B
-> for uppercase).
-The default modifier is <B
-CLASS="command"
->${0,0,d}</B
->.
-If the <B
-CLASS="command"
->lhs</B
-> is not
-absolute, the current <B
-CLASS="command"
->$ORIGIN</B
-> is appended to
-the name.</P
->
-<P
->For compatibility with earlier versions <B
-CLASS="command"
->$$</B
-> is still
-recognized a indicating a literal $ in the output.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->ttl</B
-></P
-></TD
-><TD
-><P
-><B
-CLASS="command"
->ttl</B
-> specifies the
+output forms are decimal (<span><strong class="command">d</strong></span>), octal (<span><strong class="command">o</strong></span>)
+and hexadecimal (<span><strong class="command">x</strong></span> or <span><strong class="command">X</strong></span> for uppercase).
+The default modifier is <span><strong class="command">${0,0,d}</strong></span>.
+If the <span><strong class="command">lhs</strong></span> is not
+absolute, the current <span><strong class="command">$ORIGIN</strong></span> is appended to
+the name.</p>
+<p>For compatibility with earlier versions <span><strong class="command">$$</strong></span> is still
+recognized a indicating a literal $ in the output.</p>
+</td>
+</tr>
+<tr>
+<td><p><span><strong class="command">ttl</strong></span></p></td>
+<td>
+<p><span><strong class="command">ttl</strong></span> specifies the
 	  ttl of the generated records. If not specified this will be
-	  inherited using the normal ttl inheritance rules.</P
->
-	  <P
-><B
-CLASS="command"
->class</B
-> and <B
-CLASS="command"
->ttl</B
-> can be
-	  entered in either order.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->class</B
-></P
-></TD
-><TD
-><P
-><B
-CLASS="command"
->class</B
-> specifies the
+	  inherited using the normal ttl inheritance rules.</p>
+	  <p><span><strong class="command">class</strong></span> and <span><strong class="command">ttl</strong></span> can be
+	  entered in either order.</p>
+</td>
+</tr>
+<tr>
+<td><p><span><strong class="command">class</strong></span></p></td>
+<td>
+<p><span><strong class="command">class</strong></span> specifies the
 	  class of the generated records.  This must match the zone class if
-	  it is specified.</P
->
-	  <P
-><B
-CLASS="command"
->class</B
-> and <B
-CLASS="command"
->ttl</B
-> can be
-	  entered in either order.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->type</B
-></P
-></TD
-><TD
-><P
->At present the only supported types are
-PTR, CNAME, DNAME, A, AAAA and NS.</P
-></TD
-></TR
-><TR
-><TD
-><P
-><B
-CLASS="command"
->rhs</B
-></P
-></TD
-><TD
-><P
->rhs is a domain name. It is processed
-similarly to lhs.</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->The <B
-CLASS="command"
->$GENERATE</B
-> directive is a <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> extension
-and not part of the standard zone file format.</P
-><P
->BIND 8 does not support the optional TTL and CLASS fields.</P
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch05.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch07.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->The <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Lightweight Resolver</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Security Considerations</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+	  it is specified.</p>
+	  <p><span><strong class="command">class</strong></span> and <span><strong class="command">ttl</strong></span> can be
+	  entered in either order.</p>
+</td>
+</tr>
+<tr>
+<td><p><span><strong class="command">type</strong></span></p></td>
+<td><p>At present the only supported types are
+PTR, CNAME, DNAME, A, AAAA and NS.</p></td>
+</tr>
+<tr>
+<td><p><span><strong class="command">rhs</strong></span></p></td>
+<td><p>rhs is a domain name. It is processed
+similarly to lhs.</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>The <span><strong class="command">$GENERATE</strong></span> directive is a <span class="acronym">BIND</span> extension
+and not part of the standard zone file format.</p>
+<p>BIND 8 does not support the optional TTL and CLASS fields.</p>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch05.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch07.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 5. The <span class="acronym">BIND</span> 9 Lightweight Resolver </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch07.html b/contrib/bind9/doc/arm/Bv9ARM.ch07.html
index 9e5cc9b8f3fc..86c2b6af0642 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch07.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch07.html
@@ -1,160 +1,78 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->BIND 9 Security Considerations</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="BIND 9 Configuration Reference"
-HREF="Bv9ARM.ch06.html"><LINK
-REL="NEXT"
-TITLE="Troubleshooting"
-HREF="Bv9ARM.ch08.html"></HEAD
-><BODY
-CLASS="chapter"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch06.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch08.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="chapter"
-><H1
-><A
-NAME="ch07"
-></A
->Chapter 7. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Security Considerations</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->7.1. <A
-HREF="Bv9ARM.ch07.html#Access_Control_Lists"
->Access Control Lists</A
-></DT
-><DT
->7.2. <A
-HREF="Bv9ARM.ch07.html#AEN4693"
-><B
-CLASS="command"
->chroot</B
-> and <B
-CLASS="command"
->setuid</B
-> (for
-UNIX servers)</A
-></DT
-><DT
->7.3. <A
-HREF="Bv9ARM.ch07.html#dynamic_update_security"
->Dynamic Update Security</A
-></DT
-></DL
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="Access_Control_Lists"
->7.1. Access Control Lists</A
-></H1
-><P
->Access Control Lists (ACLs), are address match lists that
-you can set up and nickname for future use in <B
-CLASS="command"
->allow-notify</B
->,
-<B
-CLASS="command"
->allow-query</B
->, <B
-CLASS="command"
->allow-recursion</B
->,
-<B
-CLASS="command"
->blackhole</B
->, <B
-CLASS="command"
->allow-transfer</B
->,
-etc.</P
-><P
->Using ACLs allows you to have finer control over who can access
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch07.html,v 1.50.2.9.2.24 2005/10/13 02:34:02 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 7. BIND 9 Security Considerations</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch06.html" title="Chapter 6. BIND 9 Configuration Reference">
+<link rel="next" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch07"></a>Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2567222"><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
+UNIX servers)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567366">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567424">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="Access_Control_Lists"></a>Access Control Lists</h2></div></div></div>
+<p>Access Control Lists (ACLs), are address match lists that
+you can set up and nickname for future use in <span><strong class="command">allow-notify</strong></span>,
+<span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-recursion</strong></span>,
+<span><strong class="command">blackhole</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
+etc.</p>
+<p>Using ACLs allows you to have finer control over who can access
 your name server, without cluttering up your config files with huge
-lists of IP addresses.</P
-><P
->It is a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->good idea</I
-></SPAN
-> to use ACLs, and to
+lists of IP addresses.</p>
+<p>It is a <span class="emphasis"><em>good idea</em></span> 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
->Here is an example of how to properly apply ACLs:</P
-><PRE
-CLASS="programlisting"
->&#13;// Set up an ACL named "bogusnets" that will block RFC1918 space,
+your server.</p>
+<p>Here is an example of how to properly apply ACLs:</p>
+<pre class="programlisting">
+// Set up an ACL named "bogusnets" that will block RFC1918 space,
 // which is commonly used in spoofing attacks.
 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; };
 // Set up an ACL called our-nets. Replace this with the real IP numbers.
@@ -173,328 +91,110 @@ zone "example.com" {
   file "m/example.com";
   allow-query { any; };
 };
-</PRE
-><P
->This allows recursive queries of the server from the outside
-unless recursion has been previously disabled.</P
-><P
->For more information on how to use ACLs to protect your server,
-see the <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->AUSCERT</I
-></SPAN
-> advisory at
-<A
-HREF="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos"
-TARGET="_top"
->ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</A
-></P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN4693"
->7.2. <B
-CLASS="command"
->chroot</B
-> and <B
-CLASS="command"
->setuid</B
-> (for
-UNIX servers)</A
-></H1
-><P
->On UNIX servers, it is possible to run <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> in a <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->chrooted</I
-></SPAN
-> environment
-(<B
-CLASS="command"
->chroot()</B
->) by specifying the "<VAR
-CLASS="option"
->-t</VAR
->"
-option. This can help improve system security by placing <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> in
-a "sandbox", which will limit the damage done if a server is compromised.</P
-><P
->Another useful feature in the UNIX version of <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> is the
-ability to run the daemon as an unprivileged user ( <VAR
-CLASS="option"
->-u</VAR
-> <VAR
-CLASS="replaceable"
->user</VAR
-> ).
-We suggest running as an unprivileged user when using the <B
-CLASS="command"
->chroot</B
-> feature.</P
-><P
->Here is an example command line to load <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> in a <B
-CLASS="command"
->chroot()</B
-> sandbox, 
-<B
-CLASS="command"
->/var/named</B
->, and to run <B
-CLASS="command"
->named</B
-> <B
-CLASS="command"
->setuid</B
-> to
-user 202:</P
-><P
-><KBD
-CLASS="userinput"
->/usr/local/bin/named -u 202 -t /var/named</KBD
-></P
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN4716"
->7.2.1. The <B
-CLASS="command"
->chroot</B
-> Environment</A
-></H2
-><P
->In order for a <B
-CLASS="command"
->chroot()</B
-> environment to
+</pre>
+<p>This allows recursive queries of the server from the outside
+unless recursion has been previously disabled.</p>
+<p>For more information on how to use ACLs to protect your server,
+see the <span class="emphasis"><em>AUSCERT</em></span> advisory at
+<a href="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos" target="_top">ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</a></p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567222"></a><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
+UNIX servers)</h2></div></div></div>
+<p>On UNIX servers, it is possible to run <span class="acronym">BIND</span> in a <span class="emphasis"><em>chrooted</em></span> environment
+(<span><strong class="command">chroot()</strong></span>) by specifying the "<code class="option">-t</code>"
+option. This can help improve system security by placing <span class="acronym">BIND</span> in
+a "sandbox", which will limit the damage done if a server is compromised.</p>
+<p>Another useful feature in the UNIX version of <span class="acronym">BIND</span> is the
+ability to run the daemon as an unprivileged user ( <code class="option">-u</code> <em class="replaceable"><code>user</code></em> ).
+We suggest running as an unprivileged user when using the <span><strong class="command">chroot</strong></span> feature.</p>
+<p>Here is an example command line to load <span class="acronym">BIND</span> in a <span><strong class="command">chroot()</strong></span> sandbox, 
+<span><strong class="command">/var/named</strong></span>, and to run <span><strong class="command">named</strong></span> <span><strong class="command">setuid</strong></span> to
+user 202:</p>
+<p><strong class="userinput"><code>/usr/local/bin/named -u 202 -t /var/named</code></strong></p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2567366"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
+<p>In order for a <span><strong class="command">chroot()</strong></span> environment to
 work properly in a particular directory
-(for example, <TT
-CLASS="filename"
->/var/named</TT
->),
+(for example, <code class="filename">/var/named</code>),
 you will need to set up an environment that includes everything
-<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> needs to run.
-From <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->'s point of view, <TT
-CLASS="filename"
->/var/named</TT
-> is
+<span class="acronym">BIND</span> needs to run.
+From <span class="acronym">BIND</span>'s point of view, <code class="filename">/var/named</code> is
 the root of the filesystem.  You will need to adjust the values of options like
-like <B
-CLASS="command"
->directory</B
-> and <B
-CLASS="command"
->pid-file</B
-> to account
+like <span><strong class="command">directory</strong></span> and <span><strong class="command">pid-file</strong></span> to account
 for this.
-</P
-><P
->&#13;Unlike with earlier versions of BIND, you will typically
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->not</I
-></SPAN
-> need to compile <B
-CLASS="command"
->named</B
->
+</p>
+<p>
+Unlike with earlier versions of BIND, you will typically
+<span class="emphasis"><em>not</em></span> need to compile <span><strong class="command">named</strong></span>
 statically nor install shared libraries under the new root.
 However, depending on your operating system, you may need
 to set up things like
-<TT
-CLASS="filename"
->/dev/zero</TT
->,
-<TT
-CLASS="filename"
->/dev/random</TT
->,
-<TT
-CLASS="filename"
->/dev/log</TT
->, and/or
-<TT
-CLASS="filename"
->/etc/localtime</TT
->.
-</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN4734"
->7.2.2. Using the <B
-CLASS="command"
->setuid</B
-> Function</A
-></H2
-><P
->Prior to running the <B
-CLASS="command"
->named</B
-> daemon, use
-the <B
-CLASS="command"
->touch</B
-> utility (to change file access and
-modification times) or the <B
-CLASS="command"
->chown</B
-> utility (to
+<code class="filename">/dev/zero</code>,
+<code class="filename">/dev/random</code>,
+<code class="filename">/dev/log</code>, and/or
+<code class="filename">/etc/localtime</code>.
+</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2567424"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
+<p>Prior to running the <span><strong class="command">named</strong></span> daemon, use
+the <span><strong class="command">touch</strong></span> utility (to change file access and
+modification times) or the <span><strong class="command">chown</strong></span> utility (to
 set the user id and/or group id) on files
-to which you want <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->
-to write.  Note that if the <B
-CLASS="command"
->named</B
-> daemon is running as an
+to which you want <span class="acronym">BIND</span>
+to write.  Note that if the <span><strong class="command">named</strong></span> daemon is running as an
 unprivileged user, it will not be able to bind to new restricted ports if the
-server is reloaded.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="dynamic_update_security"
->7.3. Dynamic Update Security</A
-></H1
-><P
->Access to the dynamic
+server is reloaded.</p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="dynamic_update_security"></a>Dynamic Update Security</h2></div></div></div>
+<p>Access to the dynamic
 update facility should be strictly limited.  In earlier versions of
-<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> the only way to do this was based on the IP
+<span class="acronym">BIND</span> the only way to do this was based on the IP
 address of the host requesting the update, by listing an IP address or
-network prefix in the <B
-CLASS="command"
->allow-update</B
-> zone option.
+network prefix in the <span><strong class="command">allow-update</strong></span> zone option.
 This method is insecure since the source address of the update UDP packet
 is easily forged.  Also note that if the IP addresses allowed by the
-<B
-CLASS="command"
->allow-update</B
-> option include the address of a slave
+<span><strong class="command">allow-update</strong></span> option include the address of a slave
 server which performs forwarding of dynamic updates, the master can be
 trivially attacked by sending the update to the slave, which will
 forward it to the master with its own source IP address causing the
-master to approve it without question.</P
-><P
->For these reasons, we strongly recommend that updates be
+master to approve it without question.</p>
+<p>For these reasons, we strongly recommend that updates be
 cryptographically authenticated by means of transaction signatures
-(TSIG).  That is, the <B
-CLASS="command"
->allow-update</B
-> option should
+(TSIG).  That is, the <span><strong class="command">allow-update</strong></span> option should
 list only TSIG key names, not IP addresses or network
-prefixes. Alternatively, the new <B
-CLASS="command"
->update-policy</B
->
-option can be used.</P
-><P
->Some sites choose to keep all dynamically updated DNS data
+prefixes. Alternatively, the new <span><strong class="command">update-policy</strong></span>
+option can be used.</p>
+<p>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
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch06.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch08.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Configuration Reference</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Troubleshooting</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+all.</p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch06.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch08.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 6. <span class="acronym">BIND</span> 9 Configuration Reference </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Chapter 8. Troubleshooting</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch08.html b/contrib/bind9/doc/arm/Bv9ARM.ch08.html
index 94d3d7952460..9d486e1bd5b6 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch08.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch08.html
@@ -1,135 +1,73 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Troubleshooting</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="BIND 9 Security Considerations"
-HREF="Bv9ARM.ch07.html"><LINK
-REL="NEXT"
-TITLE="Appendices"
-HREF="Bv9ARM.ch09.html"></HEAD
-><BODY
-CLASS="chapter"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch07.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch09.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="chapter"
-><H1
-><A
-NAME="ch08"
-></A
->Chapter 8. Troubleshooting</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->8.1. <A
-HREF="Bv9ARM.ch08.html#AEN4755"
->Common Problems</A
-></DT
-><DT
->8.2. <A
-HREF="Bv9ARM.ch08.html#AEN4760"
->Incrementing and Changing the Serial Number</A
-></DT
-><DT
->8.3. <A
-HREF="Bv9ARM.ch08.html#AEN4765"
->Where Can I Get Help?</A
-></DT
-></DL
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN4755"
->8.1. Common Problems</A
-></H1
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN4757"
->8.1.1. It's not working; how can I figure out what's wrong?</A
-></H2
-><P
->The best solution to solving installation and
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch08.html,v 1.50.2.9.2.24 2005/10/13 02:34:02 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Chapter 8. Troubleshooting</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch07.html" title="Chapter 7. BIND 9 Security Considerations">
+<link rel="next" href="Bv9ARM.ch09.html" title="Appendix A. Appendices">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Chapter 8. Troubleshooting</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch08"></a>Chapter 8. Troubleshooting</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567630">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2567636">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567648">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567665">Where Can I Get Help?</a></span></dt>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567630"></a>Common Problems</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2567636"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
+<p>The best solution to solving installation and
       configuration issues is to take preventative measures by setting
       up logging files beforehand. The log files provide a
       source of hints and information that can be used to figure out
-      what went wrong and how to fix the problem.</P
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN4760"
->8.2. Incrementing and Changing the Serial Number</A
-></H1
-><P
->Zone serial numbers are just numbers-they aren't date
+      what went wrong and how to fix the problem.</p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567648"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
+<p>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
@@ -138,135 +76,49 @@ NAME="AEN4760"
     numbers are used to indicate that a zone has been updated. If the
     serial number on the slave server is lower than the serial number
     on the master, the slave server will attempt to update its copy of
-    the zone.</P
-><P
->Setting the serial number to a lower number on the master
+    the zone.</p>
+<p>Setting the serial number to a lower number on the master
     server than the slave server means that the slave will not perform
-    updates to its copy of the zone.</P
-><P
->The solution to this is to add 2147483647 (2^31-1) to the
+    updates to its copy of the zone.</p>
+<p>The solution to this is to add 2147483647 (2^31-1) to the
     number, reload the zone and make sure all slaves have updated to
     the new zone serial number, then reset the number to what you want
-    it to be, and reload the zone again.</P
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN4765"
->8.3. Where Can I Get Help?</A
-></H1
-><P
->The Internet Software Consortium (<ACRONYM
-CLASS="acronym"
->ISC</ACRONYM
->) offers a wide range
-    of support and service agreements for <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> and <ACRONYM
-CLASS="acronym"
->DHCP</ACRONYM
-> servers. Four
+    it to be, and reload the zone again.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567665"></a>Where Can I Get Help?</h2></div></div></div>
+<p>The Internet Software Consortium (<span class="acronym">ISC</span>) offers a wide range
+    of support and service agreements for <span class="acronym">BIND</span> and <span class="acronym">DHCP</span> servers. Four
     levels of premium support are available and each level includes
-    support for all <ACRONYM
-CLASS="acronym"
->ISC</ACRONYM
-> programs, significant discounts on products
+    support for all <span class="acronym">ISC</span> programs, significant discounts on products
     and training, and a recognized priority on bug fixes and
-    non-funded feature requests. In addition, <ACRONYM
-CLASS="acronym"
->ISC</ACRONYM
-> offers a standard
+    non-funded feature requests. In addition, <span class="acronym">ISC</span> offers a standard
     support agreement package which includes services ranging from bug
     fix announcements to remote support. It also includes training in
-    <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> and <ACRONYM
-CLASS="acronym"
->DHCP</ACRONYM
->.</P
-><P
->To discuss arrangements for support, contact
-    <A
-HREF="mailto:info@isc.org"
-TARGET="_top"
->info@isc.org</A
-> or visit the
-    <ACRONYM
-CLASS="acronym"
->ISC</ACRONYM
-> web page at <A
-HREF="http://www.isc.org/services/support/"
-TARGET="_top"
->http://www.isc.org/services/support/</A
->
-    to read more.</P
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch07.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch09.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Security Considerations</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Appendices</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+    <span class="acronym">BIND</span> and <span class="acronym">DHCP</span>.</p>
+<p>To discuss arrangements for support, contact
+    <a href="mailto:info@isc.org" target="_top">info@isc.org</a> or visit the
+    <span class="acronym">ISC</span> web page at <a href="http://www.isc.org/services/support/" target="_top">http://www.isc.org/services/support/</a>
+    to read more.</p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch07.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch09.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 7. <span class="acronym">BIND</span> 9 Security Considerations </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> Appendix A. Appendices</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch09.html b/contrib/bind9/doc/arm/Bv9ARM.ch09.html
index ea6202b2eb8f..8c7b2bf4450f 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch09.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch09.html
@@ -1,121 +1,67 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Appendices</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="HOME"
-TITLE="BIND 9 Administrator Reference Manual"
-HREF="Bv9ARM.html"><LINK
-REL="PREVIOUS"
-TITLE="Troubleshooting"
-HREF="Bv9ARM.ch08.html"></HEAD
-><BODY
-CLASS="appendix"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->BIND 9 Administrator Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="Bv9ARM.ch08.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
->&nbsp;</TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="appendix"
-><H1
-><A
-NAME="ch09"
-></A
->Appendix A. Appendices</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->A.1. <A
-HREF="Bv9ARM.ch09.html#AEN4781"
->Acknowledgments</A
-></DT
-><DT
->A.2. <A
-HREF="Bv9ARM.ch09.html#historical_dns_information"
->General <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Reference Information</A
-></DT
-><DT
->A.3. <A
-HREF="Bv9ARM.ch09.html#bibliography"
->Bibliography (and Suggested Reading)</A
-></DT
-></DL
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="AEN4781"
->A.1. Acknowledgments</A
-></H1
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN4783"
->A.1.1. A Brief History of the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> and <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-></A
-></H2
-><P
->Although the "official" beginning of the Domain Name
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.ch09.html,v 1.50.2.9.2.25 2005/10/13 02:34:03 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>Appendix A. Appendices</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="prev" href="Bv9ARM.ch08.html" title="Chapter 8. Troubleshooting">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">Appendix A. Appendices</th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="Bv9ARM.ch08.html">Prev</a> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> </td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="appendix" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="Bv9ARM.ch09"></a>Appendix A. Appendices</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2567795">Acknowledgments</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2567800">A Brief History of the <span class="acronym">DNS</span> and <span class="acronym">BIND</span></a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#historical_dns_information">General <span class="acronym">DNS</span> Reference Information</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2570087">Other Documents About <span class="acronym">BIND</span></a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="id2567795"></a>Acknowledgments</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2567800"></a>A Brief History of the <span class="acronym">DNS</span> and <span class="acronym">BIND</span></h3></div></div></div>
+<p>Although the "official" beginning of the Domain Name
       System occurred in 1984 with the publication of RFC 920, the
       core of the new system was described in 1983 in RFCs 882 and
       883. From 1984 to 1987, the ARPAnet (the precursor to today's
@@ -126,1462 +72,317 @@ CLASS="acronym"
       incorporate improvements based on the working model. RFC 1034,
       "Domain Names-Concepts and Facilities", and RFC 1035, "Domain
       Names-Implementation and Specification" were published and
-      became the standards upon which all <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> implementations are
+      became the standards upon which all <span class="acronym">DNS</span> implementations are
       built.
-</P
-><P
->The first working domain name server, called "Jeeves", was
+</p>
+<p>The first working domain name server, called "Jeeves", was
 written in 1983-84 by Paul Mockapetris for operation on DEC Tops-20
 machines located at the University of Southern California's Information
 Sciences Institute (USC-ISI) and SRI International's Network Information
-Center (SRI-NIC). A <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> server for Unix machines, the Berkeley Internet
-Name Domain (<ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->) package, was written soon after by a group of
+Center (SRI-NIC). A <span class="acronym">DNS</span> server for Unix machines, the Berkeley Internet
+Name Domain (<span class="acronym">BIND</span>) 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 <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> through 4.8.3 were maintained by the Computer
+(DARPA). Versions of <span class="acronym">BIND</span> through 4.8.3 were maintained by the Computer
 Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark
-Painter, David Riggle and Songnian Zhou made up the initial <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->
+Painter, David Riggle and Songnian Zhou made up the initial <span class="acronym">BIND</span>
 project team. After that, additional work on the software package
 was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation
-employee on loan to the CSRG, worked on <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> for 2 years, from 1985
-to 1987. Many other people also contributed to <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> development
+employee on loan to the CSRG, worked on <span class="acronym">BIND</span> for 2 years, from 1985
+to 1987. Many other people also contributed to <span class="acronym">BIND</span> development
 during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell,
-Mike Muuss, Jim Bloom and Mike Schwartz. <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> maintenance was subsequently
-handled by Mike Karels and O. Kure.</P
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> versions 4.9 and 4.9.1 were released by Digital Equipment
+Mike Muuss, Jim Bloom and Mike Schwartz. <span class="acronym">BIND</span> maintenance was subsequently
+handled by Mike Karels and O. Kure.</p>
+<p><span class="acronym">BIND</span> versions 4.9 and 4.9.1 were released by Digital Equipment
 Corporation (now Compaq Computer Corporation). Paul Vixie, then
-a DEC employee, became <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->'s primary caretaker. Paul was assisted
+a DEC employee, became <span class="acronym">BIND</span>'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
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> Version 4.9.2 was sponsored by Vixie Enterprises. Paul
-Vixie became <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
->'s principal architect/programmer.</P
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> versions from 4.9.3 onward have been developed and maintained
+Wolfhugel, and others.</p>
+<p><span class="acronym">BIND</span> Version 4.9.2 was sponsored by Vixie Enterprises. Paul
+Vixie became <span class="acronym">BIND</span>'s principal architect/programmer.</p>
+<p><span class="acronym">BIND</span> 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 <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> version
-8 in May 1997.</P
-><P
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> development work is made possible today by the sponsorship
+Paul Vixie released the first production-ready version of <span class="acronym">BIND</span> version
+8 in May 1997.</p>
+<p><span class="acronym">BIND</span> 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
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="historical_dns_information"
->A.2. General <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Reference Information</A
-></H1
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="ipv6addresses"
->A.2.1. IPv6 addresses (AAAA)</A
-></H2
-><P
->IPv6 addresses are 128-bit identifiers for interfaces and
-sets of interfaces which were introduced in the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> to facilitate
-scalable Internet routing. There are three types of addresses: <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Unicast</I
-></SPAN
->,
-an identifier for a single interface; <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Anycast</I
-></SPAN
->,
-an identifier for a set of interfaces; and <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Multicast</I
-></SPAN
->,
+individuals.</p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="historical_dns_information"></a>General <span class="acronym">DNS</span> Reference Information</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="ipv6addresses"></a>IPv6 addresses (AAAA)</h3></div></div></div>
+<p>IPv6 addresses are 128-bit identifiers for interfaces and
+sets of interfaces which were introduced in the <span class="acronym">DNS</span> to facilitate
+scalable Internet routing. There are three types of addresses: <span class="emphasis"><em>Unicast</em></span>,
+an identifier for a single interface; <span class="emphasis"><em>Anycast</em></span>,
+an identifier for a set of interfaces; and <span class="emphasis"><em>Multicast</em></span>,
 an identifier for a set of interfaces. Here we describe the global
-Unicast address scheme. For more information, see RFC 2374.</P
-><P
->The aggregatable global Unicast address format is as follows:</P
-><DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4819"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
->3</P
-></TD
-><TD
-><P
->13</P
-></TD
-><TD
-><P
->8</P
-></TD
-><TD
-><P
->24</P
-></TD
-><TD
-><P
->16</P
-></TD
-><TD
-><P
->64 bits</P
-></TD
-></TR
-><TR
-><TD
-><P
->FP</P
-></TD
-><TD
-><P
->TLA ID</P
-></TD
-><TD
-><P
->RES</P
-></TD
-><TD
-><P
->NLA ID</P
-></TD
-><TD
-><P
->SLA ID</P
-></TD
-><TD
-><P
->Interface ID</P
-></TD
-></TR
-><TR
-><TD
-COLSPAN="4"
-><P
->&#60;------ Public Topology
-------&#62;</P
-></TD
-><TD
-><P
-></P
-></TD
-><TD
-><P
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-></P
-></TD
-><TD
-><P
-></P
-></TD
-><TD
-><P
-></P
-></TD
-><TD
-><P
->&#60;-Site Topology-&#62;</P
-></TD
-><TD
-><P
-></P
-></TD
-></TR
-><TR
-><TD
-><P
-></P
-></TD
-><TD
-><P
-></P
-></TD
-><TD
-><P
-></P
-></TD
-><TD
-><P
-></P
-></TD
-><TD
-><P
-></P
-></TD
-><TD
-><P
->&#60;------ Interface Identifier ------&#62;</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-><P
->Where
-<DIV
-CLASS="informaltable"
-><P
-></P
-><A
-NAME="AEN4888"
-></A
-><TABLE
-CELLPADDING="3"
-BORDER="1"
-CLASS="CALSTABLE"
-><TBODY
-><TR
-><TD
-><P
->FP</P
-></TD
-><TD
-><P
->=</P
-></TD
-><TD
-><P
->Format Prefix (001)</P
-></TD
-></TR
-><TR
-><TD
-><P
->TLA ID</P
-></TD
-><TD
-><P
->=</P
-></TD
-><TD
-><P
->Top-Level Aggregation Identifier</P
-></TD
-></TR
-><TR
-><TD
-><P
->RES</P
-></TD
-><TD
-><P
->=</P
-></TD
-><TD
-><P
->Reserved for future use</P
-></TD
-></TR
-><TR
-><TD
-><P
->NLA ID</P
-></TD
-><TD
-><P
->=</P
-></TD
-><TD
-><P
->Next-Level Aggregation Identifier</P
-></TD
-></TR
-><TR
-><TD
-><P
->SLA ID</P
-></TD
-><TD
-><P
->=</P
-></TD
-><TD
-><P
->Site-Level Aggregation Identifier</P
-></TD
-></TR
-><TR
-><TD
-><P
->INTERFACE ID</P
-></TD
-><TD
-><P
->=</P
-></TD
-><TD
-><P
->Interface Identifier</P
-></TD
-></TR
-></TBODY
-></TABLE
-><P
-></P
-></DIV
-></P
-><P
->The <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Public Topology</I
-></SPAN
-> is provided by the
-upstream provider or ISP, and (roughly) corresponds to the IPv4 <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->network</I
-></SPAN
-> section
-of the address range. The <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Site Topology</I
-></SPAN
-> is
+Unicast address scheme. For more information, see RFC 2374.</p>
+<p>The aggregatable global Unicast address format is as follows:</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p>3</p></td>
+<td><p>13</p></td>
+<td><p>8</p></td>
+<td><p>24</p></td>
+<td><p>16</p></td>
+<td><p>64 bits</p></td>
+</tr>
+<tr>
+<td><p>FP</p></td>
+<td><p>TLA ID</p></td>
+<td><p>RES</p></td>
+<td><p>NLA ID</p></td>
+<td><p>SLA ID</p></td>
+<td><p>Interface ID</p></td>
+</tr>
+<tr>
+<td colspan="4"><p>&lt;------ Public Topology
+------&gt;</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p></p></td>
+<td><p></p></td>
+<td><p></p></td>
+<td><p>&lt;-Site Topology-&gt;</p></td>
+<td><p></p></td>
+</tr>
+<tr>
+<td><p></p></td>
+<td><p></p></td>
+<td><p></p></td>
+<td><p></p></td>
+<td><p></p></td>
+<td><p>&lt;------ Interface Identifier ------&gt;</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>Where
+</p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td><p>FP</p></td>
+<td><p>=</p></td>
+<td><p>Format Prefix (001)</p></td>
+</tr>
+<tr>
+<td><p>TLA ID</p></td>
+<td><p>=</p></td>
+<td><p>Top-Level Aggregation Identifier</p></td>
+</tr>
+<tr>
+<td><p>RES</p></td>
+<td><p>=</p></td>
+<td><p>Reserved for future use</p></td>
+</tr>
+<tr>
+<td><p>NLA ID</p></td>
+<td><p>=</p></td>
+<td><p>Next-Level Aggregation Identifier</p></td>
+</tr>
+<tr>
+<td><p>SLA ID</p></td>
+<td><p>=</p></td>
+<td><p>Site-Level Aggregation Identifier</p></td>
+</tr>
+<tr>
+<td><p>INTERFACE ID</p></td>
+<td><p>=</p></td>
+<td><p>Interface Identifier</p></td>
+</tr>
+</tbody>
+</table></div>
+<p>The <span class="emphasis"><em>Public Topology</em></span> is provided by the
+upstream provider or ISP, and (roughly) corresponds to the IPv4 <span class="emphasis"><em>network</em></span> section
+of the address range. The <span class="emphasis"><em>Site Topology</em></span> is
 where you can subnet this space, much the same as subnetting an
-IPv4 /16 network into /24 subnets. The <SPAN
-CLASS="emphasis"
-><I
-CLASS="emphasis"
->Interface Identifier</I
-></SPAN
-> is
+IPv4 /16 network into /24 subnets. The <span class="emphasis"><em>Interface Identifier</em></span> is
 the address of an individual interface on a given network. (With
-IPv6, addresses belong to interfaces rather than machines.)</P
-><P
->The subnetting capability of IPv6 is much more flexible than
+IPv6, addresses belong to interfaces rather than machines.)</p>
+<p>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
->The Interface Identifier must be unique on that network. On
+in much the same way as Classless InterDomain Routing (CIDR).</p>
+<p>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
-><P
-><B
-CLASS="command"
->2001:db8:201:9:a00:20ff:fe81:2b32</B
-></P
-><P
->IPv6 address specifications are likely to contain long strings
+of a block may be omitted, for example:</p>
+<p><span><strong class="command">2001:db8:201:9:a00:20ff:fe81:2b32</strong></span></p>
+<p>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
-></DIV
-></DIV
-><DIV
-CLASS="sect1"
-><H1
-CLASS="sect1"
-><A
-NAME="bibliography"
->A.3. Bibliography (and Suggested Reading)</A
-></H1
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="rfcs"
->A.3.1. Request for Comments (RFCs)</A
-></H2
-><P
->Specification documents for the Internet protocol suite, including
-the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->, are published as part of the Request for Comments (RFCs)
+of zeros that can fit, and can be used only once in an address.</p>
+</div>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="bibliography"></a>Bibliography (and Suggested Reading)</h2></div></div></div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="rfcs"></a>Request for Comments (RFCs)</h3></div></div></div>
+<p>Specification documents for the Internet protocol suite, including
+the <span class="acronym">DNS</span>, are published as part of the Request for Comments (RFCs)
 series of technical notes. The standards themselves are defined
 by the Internet Engineering Task Force (IETF) and the Internet Engineering
 Steering Group (IESG). RFCs can be obtained online via FTP at 
-<A
-HREF="ftp://www.isi.edu/in-notes/"
-TARGET="_top"
->ftp://www.isi.edu/in-notes/RFC<VAR
-CLASS="replaceable"
->xxx</VAR
->.txt</A
-> (where <VAR
-CLASS="replaceable"
->xxx</VAR
-> is
+<a href="ftp://www.isi.edu/in-notes/" target="_top">ftp://www.isi.edu/in-notes/RFC<em class="replaceable"><code>xxx</code></em>.txt</a> (where <em class="replaceable"><code>xxx</code></em> is
 the number of the RFC). RFCs are also available via the Web at
-<A
-HREF="http://www.ietf.org/rfc/"
-TARGET="_top"
->http://www.ietf.org/rfc/</A
->.
-</P
-><H3
-><A
-NAME="AEN4956"
->Bibliography</A
-></H3
-><H2
-CLASS="bibliodiv"
-><A
-NAME="AEN4957"
->Standards</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN4959"
-></A
-><P
->[RFC974]&nbsp;<SPAN
-CLASS="AUTHOR"
->C. Partridge</SPAN
->, <I
->Mail Routing and the Domain System</I
->, January 1986.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN4966"
-></A
-><P
->[RFC1034]&nbsp;<SPAN
-CLASS="AUTHOR"
->P.V. Mockapetris</SPAN
->, <I
->Domain Names &#8212; Concepts and Facilities</I
->, November 1987.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN4973"
-></A
-><P
->[RFC1035]&nbsp;<SPAN
-CLASS="AUTHOR"
->P. V. Mockapetris</SPAN
->, <I
->Domain Names &#8212; Implementation and
-Specification</I
->, November 1987.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><H2
-CLASS="bibliodiv"
-><A
-NAME="proposed_standards"
->Proposed Standards</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN4982"
-></A
-><P
->[RFC2181]&nbsp;<SPAN
-CLASS="AUTHOR"
->R., R. Bush Elz</SPAN
->, <I
->Clarifications to the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Specification</I
->, July 1997.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN4990"
-></A
-><P
->[RFC2308]&nbsp;<SPAN
-CLASS="AUTHOR"
->M. Andrews</SPAN
->, <I
->Negative Caching of <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Queries</I
->, March 1998.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN4998"
-></A
-><P
->[RFC1995]&nbsp;<SPAN
-CLASS="AUTHOR"
->M. Ohta</SPAN
->, <I
->Incremental Zone Transfer in <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-></I
->, August 1996.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5006"
-></A
-><P
->[RFC1996]&nbsp;<SPAN
-CLASS="AUTHOR"
->P. Vixie</SPAN
->, <I
->A Mechanism for Prompt Notification of Zone Changes</I
->, August 1996.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5013"
-></A
-><P
->[RFC2136]&nbsp;<SPAN
-CLASS="AUTHOR"
->P. Vixie, </SPAN
-><SPAN
-CLASS="AUTHOR"
->S. Thomson, </SPAN
-><SPAN
-CLASS="AUTHOR"
->Y. Rekhter, </SPAN
-><SPAN
-CLASS="AUTHOR"
->and J. Bound</SPAN
->, <I
->Dynamic Updates in the Domain Name System</I
->, April 1997.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5030"
-></A
-><P
->[RFC2845]&nbsp;<SPAN
-CLASS="AUTHOR"
->P. Vixie, </SPAN
-><SPAN
-CLASS="AUTHOR"
->O. Gudmundsson, </SPAN
-><SPAN
-CLASS="AUTHOR"
->D. Eastlake, 3rd, </SPAN
-><SPAN
-CLASS="AUTHOR"
->and B. Wellington</SPAN
->, <I
->Secret Key Transaction Authentication for <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> (TSIG)</I
->, May 2000.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><H2
-CLASS="bibliodiv"
-><A
-NAME="AEN5049"
->Proposed Standards Still Under Development</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5054"
-></A
-><P
->[RFC1886]&nbsp;<SPAN
-CLASS="AUTHOR"
->S. Thomson </SPAN
-><SPAN
-CLASS="AUTHOR"
->and C. Huitema</SPAN
->, <I
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Extensions to support IP version 6</I
->, December 1995.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5066"
-></A
-><P
->[RFC2065]&nbsp;<SPAN
-CLASS="AUTHOR"
->D. Eastlake, 3rd </SPAN
-><SPAN
-CLASS="AUTHOR"
->and C. Kaufman</SPAN
->, <I
->Domain Name System Security Extensions</I
->, January 1997.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5078"
-></A
-><P
->[RFC2137]&nbsp;<SPAN
-CLASS="AUTHOR"
->D. Eastlake, 3rd</SPAN
->, <I
->Secure Domain Name System Dynamic Update</I
->, April 1997.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><H2
-CLASS="bibliodiv"
-><A
-NAME="AEN5086"
->Other Important RFCs About <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Implementation</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5089"
-></A
-><P
->[RFC1535]&nbsp;<SPAN
-CLASS="AUTHOR"
->E. Gavron</SPAN
->, <I
->A Security Problem and Proposed Correction With Widely Deployed <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Software.</I
->, October 1993.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5097"
-></A
-><P
->[RFC1536]&nbsp;<SPAN
-CLASS="AUTHOR"
->A. Kumar, </SPAN
-><SPAN
-CLASS="AUTHOR"
->J. Postel, </SPAN
-><SPAN
-CLASS="AUTHOR"
->C. Neuman, </SPAN
-><SPAN
-CLASS="AUTHOR"
->P. Danzig, </SPAN
-><SPAN
-CLASS="AUTHOR"
->and S. Miller</SPAN
->, <I
->Common <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Implementation Errors and Suggested Fixes</I
->, October 1993.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5118"
-></A
-><P
->[RFC1982]&nbsp;<SPAN
-CLASS="AUTHOR"
->R. Elz </SPAN
-><SPAN
-CLASS="AUTHOR"
->and R. Bush</SPAN
->, <I
->Serial Number Arithmetic</I
->, August 1996.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><H2
-CLASS="bibliodiv"
-><A
-NAME="AEN5129"
->Resource Record Types</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5131"
-></A
-><P
->[RFC1183]&nbsp;<SPAN
-CLASS="AUTHOR"
->C.F. Everhart, </SPAN
-><SPAN
-CLASS="AUTHOR"
->L. A. Mamakos, </SPAN
-><SPAN
-CLASS="AUTHOR"
->R. Ullmann, </SPAN
-><SPAN
-CLASS="AUTHOR"
->and P. Mockapetris</SPAN
->, <I
->New <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> RR Definitions</I
->, October 1990.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5149"
-></A
-><P
->[RFC1706]&nbsp;<SPAN
-CLASS="AUTHOR"
->B. Manning </SPAN
-><SPAN
-CLASS="AUTHOR"
->and R. Colella</SPAN
->, <I
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> NSAP Resource Records</I
->, October 1994.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5161"
-></A
-><P
->[RFC2168]&nbsp;<SPAN
-CLASS="AUTHOR"
->R. Daniel </SPAN
-><SPAN
-CLASS="AUTHOR"
->and M. Mealling</SPAN
->, <I
->Resolution of Uniform Resource Identifiers using
-the Domain Name System</I
->, June 1997.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5172"
-></A
-><P
->[RFC1876]&nbsp;<SPAN
-CLASS="AUTHOR"
->C. Davis, </SPAN
-><SPAN
-CLASS="AUTHOR"
->P. Vixie, </SPAN
-><SPAN
-CLASS="AUTHOR"
->T., </SPAN
-><SPAN
-CLASS="AUTHOR"
->and I. Dickinson</SPAN
->, <I
->A Means for Expressing Location Information in the Domain
-Name System</I
->, January 1996.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5189"
-></A
-><P
->[RFC2052]&nbsp;<SPAN
-CLASS="AUTHOR"
->A. Gulbrandsen </SPAN
-><SPAN
-CLASS="AUTHOR"
->and P. Vixie</SPAN
->, <I
->A <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> RR for Specifying the Location of
-Services.</I
->, October 1996.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5201"
-></A
-><P
->[RFC2163]&nbsp;<SPAN
-CLASS="AUTHOR"
->A. Allocchio</SPAN
->, <I
->Using the Internet <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> to Distribute MIXER
-Conformant Global Address Mapping</I
->, January 1998.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5209"
-></A
-><P
->[RFC2230]&nbsp;<SPAN
-CLASS="AUTHOR"
->R. Atkinson</SPAN
->, <I
->Key Exchange Delegation Record for the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-></I
->, October 1997.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><H2
-CLASS="bibliodiv"
-><A
-NAME="AEN5217"
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> and the Internet</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5220"
-></A
-><P
->[RFC1101]&nbsp;<SPAN
-CLASS="AUTHOR"
->P. V. Mockapetris</SPAN
->, <I
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Encoding of Network Names and Other Types</I
->, April 1989.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5228"
-></A
-><P
->[RFC1123]&nbsp;<SPAN
-CLASS="AUTHOR"
->Braden</SPAN
->, <I
->Requirements for Internet Hosts - Application and Support</I
->, October 1989.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5235"
-></A
-><P
->[RFC1591]&nbsp;<SPAN
-CLASS="AUTHOR"
->J. Postel</SPAN
->, <I
->Domain Name System Structure and Delegation</I
->, March 1994.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5242"
-></A
-><P
->[RFC2317]&nbsp;<SPAN
-CLASS="AUTHOR"
->H. Eidnes, </SPAN
-><SPAN
-CLASS="AUTHOR"
->G. de Groot, </SPAN
-><SPAN
-CLASS="AUTHOR"
->and P. Vixie</SPAN
->, <I
->Classless IN-ADDR.ARPA Delegation</I
->, March 1998.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><H2
-CLASS="bibliodiv"
-><A
-NAME="AEN5256"
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Operations</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5259"
-></A
-><P
->[RFC1537]&nbsp;<SPAN
-CLASS="AUTHOR"
->P. Beertema</SPAN
->, <I
->Common <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Data File Configuration Errors</I
->, October 1993.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5267"
-></A
-><P
->[RFC1912]&nbsp;<SPAN
-CLASS="AUTHOR"
->D. Barr</SPAN
->, <I
->Common <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Operational and Configuration Errors</I
->, February 1996.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5275"
-></A
-><P
->[RFC2010]&nbsp;<SPAN
-CLASS="AUTHOR"
->B. Manning </SPAN
-><SPAN
-CLASS="AUTHOR"
->and P. Vixie</SPAN
->, <I
->Operational Criteria for Root Name Servers.</I
->, October 1996.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5286"
-></A
-><P
->[RFC2219]&nbsp;<SPAN
-CLASS="AUTHOR"
->M. Hamilton </SPAN
-><SPAN
-CLASS="AUTHOR"
->and R. Wright</SPAN
->, <I
->Use of <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Aliases for Network Services.</I
->, October 1997.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><H2
-CLASS="bibliodiv"
-><A
-NAME="AEN5298"
->Other <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->-related RFCs</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5304"
-></A
-><P
->[RFC1464]&nbsp;<SPAN
-CLASS="AUTHOR"
->R. Rosenbaum</SPAN
->, <I
->Using the Domain Name System To Store Arbitrary String Attributes</I
->, May 1993.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5311"
-></A
-><P
->[RFC1713]&nbsp;<SPAN
-CLASS="AUTHOR"
->A. Romao</SPAN
->, <I
->Tools for <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Debugging</I
->, November 1994.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5319"
-></A
-><P
->[RFC1794]&nbsp;<SPAN
-CLASS="AUTHOR"
->T. Brisco</SPAN
->, <I
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Support for Load Balancing</I
->, April 1995.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5327"
-></A
-><P
->[RFC2240]&nbsp;<SPAN
-CLASS="AUTHOR"
->O. Vaughan</SPAN
->, <I
->A Legal Basis for Domain Name Allocation</I
->, November 1997.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5334"
-></A
-><P
->[RFC2345]&nbsp;<SPAN
-CLASS="AUTHOR"
->J. Klensin, </SPAN
-><SPAN
-CLASS="AUTHOR"
->T. Wolf, </SPAN
-><SPAN
-CLASS="AUTHOR"
->and G. Oglesby</SPAN
->, <I
->Domain Names and Company Name Retrieval</I
->, May 1998.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5348"
-></A
-><P
->[RFC2352]&nbsp;<SPAN
-CLASS="AUTHOR"
->O. Vaughan</SPAN
->, <I
->A Convention For Using Legal Names as Domain Names</I
->, May 1998.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-><H2
-CLASS="bibliodiv"
-><A
-NAME="AEN5355"
->Obsolete and Unimplemented Experimental RRs</A
-></H2
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5357"
-></A
-><P
->[RFC1712]&nbsp;<SPAN
-CLASS="AUTHOR"
->C. Farrell, </SPAN
-><SPAN
-CLASS="AUTHOR"
->M. Schulze, </SPAN
-><SPAN
-CLASS="AUTHOR"
->S. Pleitner, </SPAN
-><SPAN
-CLASS="AUTHOR"
->and D. Baldoni</SPAN
->, <I
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Encoding of Geographical
-Location</I
->, November 1994.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="internet_drafts"
->A.3.2. Internet Drafts</A
-></H2
-><P
->Internet Drafts (IDs) are rough-draft working documents of
+<a href="http://www.ietf.org/rfc/" target="_top">http://www.ietf.org/rfc/</a>.
+</p>
+<div class="bibliography">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2568712"></a>Bibliography</h4></div></div></div>
+<div class="bibliodiv">
+<h3 class="title">Standards</h3>
+<div class="biblioentry"><p>[<span class="abbrev">RFC974</span>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1034</span>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1035</span>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
+Specification</i>. </span><span class="pubdate">November 1987. </span></p></div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">
+<a name="proposed_standards"></a>Proposed Standards</h3>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2181</span>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <span class="acronym">DNS</span> Specification</i>. </span><span class="pubdate">July 1997. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2308</span>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <span class="acronym">DNS</span> Queries</i>. </span><span class="pubdate">March 1998. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1995</span>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <span class="acronym">DNS</span></i>. </span><span class="pubdate">August 1996. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1996</span>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2136</span>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2845</span>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <span class="acronym">DNS</span> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p></div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Proposed Standards Still Under Development</h3>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p><span class="emphasis"><em>Note:</em></span> the following list of
+RFCs are undergoing major revision by the IETF.</p>
+</div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1886</span>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i><span class="acronym">DNS</span> Extensions to support IP version 6</i>. </span><span class="pubdate">December 1995. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2065</span>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2137</span>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p></div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Other Important RFCs About <span class="acronym">DNS</span> Implementation</h3>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1535</span>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely Deployed <span class="acronym">DNS</span> Software.</i>. </span><span class="pubdate">October 1993. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1536</span>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <span class="acronym">DNS</span> Implementation Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1982</span>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p></div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Resource Record Types</h3>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1183</span>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <span class="acronym">DNS</span> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1706</span>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><span class="acronym">DNS</span> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2168</span>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
+the Domain Name System</i>. </span><span class="pubdate">June 1997. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1876</span>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the Domain
+Name System</i>. </span><span class="pubdate">January 1996. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2052</span>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <span class="acronym">DNS</span> RR for Specifying the Location of
+Services.</i>. </span><span class="pubdate">October 1996. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2163</span>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <span class="acronym">DNS</span> to Distribute MIXER
+Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2230</span>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <span class="acronym">DNS</span></i>. </span><span class="pubdate">October 1997. </span></p></div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">
+<span class="acronym">DNS</span> and the Internet</h3>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1101</span>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><span class="acronym">DNS</span> Encoding of Network Names and Other Types</i>. </span><span class="pubdate">April 1989. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1123</span>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and Support</i>. </span><span class="pubdate">October 1989. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1591</span>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2317</span>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p></div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">
+<span class="acronym">DNS</span> Operations</h3>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1537</span>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <span class="acronym">DNS</span> Data File Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1912</span>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <span class="acronym">DNS</span> Operational and Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2010</span>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2219</span>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <span class="acronym">DNS</span> Aliases for Network Services.</i>. </span><span class="pubdate">October 1997. </span></p></div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Other <span class="acronym">DNS</span>-related RFCs</h3>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>Note: the following list of RFCs, although
+<span class="acronym">DNS</span>-related, are not concerned with implementing software.</p>
+</div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1464</span>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String Attributes</i>. </span><span class="pubdate">May 1993. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1713</span>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <span class="acronym">DNS</span> Debugging</i>. </span><span class="pubdate">November 1994. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1794</span>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><span class="acronym">DNS</span> Support for Load Balancing</i>. </span><span class="pubdate">April 1995. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2240</span>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2345</span>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p></div>
+<div class="biblioentry"><p>[<span class="abbrev">RFC2352</span>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p></div>
+</div>
+<div class="bibliodiv">
+<h3 class="title">Obsolete and Unimplemented Experimental RRs</h3>
+<div class="biblioentry"><p>[<span class="abbrev">RFC1712</span>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><span class="acronym">DNS</span> Encoding of Geographical
+Location</i>. </span><span class="pubdate">November 1994. </span></p></div>
+</div>
+</div>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="internet_drafts"></a>Internet Drafts</h3></div></div></div>
+<p>Internet Drafts (IDs) are rough-draft working documents of
 the Internet Engineering Task Force. They are, in essence, RFCs
 in the preliminary stages of development. Implementors are cautioned not
 to regard IDs as archival, and they should not be quoted or cited
 in any formal documents unless accompanied by the disclaimer that
 they are "works in progress." IDs have a lifespan of six months
 after which they are deleted unless updated by their authors.
-</P
-></DIV
-><DIV
-CLASS="sect2"
-><H2
-CLASS="sect2"
-><A
-NAME="AEN5378"
->A.3.3. Other Documents About <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-></A
-></H2
-><P
-></P
-><H3
-><A
-NAME="AEN5382"
->Bibliography</A
-></H3
-><DIV
-CLASS="biblioentry"
-><A
-NAME="AEN5383"
-></A
-><P
-><SPAN
-CLASS="AUTHOR"
->Paul Albitz </SPAN
-><SPAN
-CLASS="AUTHOR"
->and Cricket Liu</SPAN
->, <I
-><ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> and <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-></I
->, 1998.</P
-><DIV
-CLASS="BIBLIOENTRYBLOCK"
-STYLE="margin-left: 0.5in"
-></DIV
-></DIV
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch08.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="Bv9ARM.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->&nbsp;</TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Troubleshooting</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->&nbsp;</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2570087"></a>Other Documents About <span class="acronym">BIND</span></h3></div></div></div>
+<p></p>
+<div class="bibliography">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2570097"></a>Bibliography</h4></div></div></div>
+<div class="biblioentry"><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><span class="acronym">DNS</span> and <span class="acronym">BIND</span></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p></div>
+</div>
+</div>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="Bv9ARM.ch08.html">Prev</a> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> </td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">Chapter 8. Troubleshooting </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> </td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.html b/contrib/bind9/doc/arm/Bv9ARM.html
index 21d46214cc8b..71ec32992eb0 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.html
@@ -1,851 +1,222 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->BIND 9 Administrator Reference Manual</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REL="NEXT"
-TITLE="Introduction "
-HREF="Bv9ARM.ch01.html"></HEAD
-><BODY
-CLASS="book"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="BOOK"
-><A
-NAME="AEN1"
-></A
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="title"
-><A
-NAME="AEN1"
->BIND 9 Administrator Reference Manual</A
-></H1
-><P
-CLASS="copyright"
->Copyright &copy; 2004 Internet Systems Consortium, Inc. ("ISC")</P
-><P
-CLASS="copyright"
->Copyright &copy; 2000-2003 Internet Software Consortium</P
-><HR></DIV
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->1. <A
-HREF="Bv9ARM.ch01.html"
->Introduction</A
-></DT
-><DD
-><DL
-><DT
->1.1. <A
-HREF="Bv9ARM.ch01.html#AEN15"
->Scope of Document</A
-></DT
-><DT
->1.2. <A
-HREF="Bv9ARM.ch01.html#AEN22"
->Organization of This Document</A
-></DT
-><DT
->1.3. <A
-HREF="Bv9ARM.ch01.html#AEN42"
->Conventions Used in This Document</A
-></DT
-><DT
->1.4. <A
-HREF="Bv9ARM.ch01.html#AEN107"
->The Domain Name System (<ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
->)</A
-></DT
-><DD
-><DL
-><DT
->1.4.1. <A
-HREF="Bv9ARM.ch01.html#AEN114"
->DNS Fundamentals</A
-></DT
-><DT
->1.4.2. <A
-HREF="Bv9ARM.ch01.html#AEN124"
->Domains and Domain Names</A
-></DT
-><DT
->1.4.3. <A
-HREF="Bv9ARM.ch01.html#AEN148"
->Zones</A
-></DT
-><DT
->1.4.4. <A
-HREF="Bv9ARM.ch01.html#AEN171"
->Authoritative Name Servers</A
-></DT
-><DT
->1.4.5. <A
-HREF="Bv9ARM.ch01.html#AEN200"
->Caching Name Servers</A
-></DT
-><DT
->1.4.6. <A
-HREF="Bv9ARM.ch01.html#AEN218"
->Name Servers in Multiple Roles</A
-></DT
-></DL
-></DD
-></DL
-></DD
-><DT
->2. <A
-HREF="Bv9ARM.ch02.html"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> Resource Requirements</A
-></DT
-><DD
-><DL
-><DT
->2.1. <A
-HREF="Bv9ARM.ch02.html#AEN228"
->Hardware requirements</A
-></DT
-><DT
->2.2. <A
-HREF="Bv9ARM.ch02.html#AEN236"
->CPU Requirements</A
-></DT
-><DT
->2.3. <A
-HREF="Bv9ARM.ch02.html#AEN240"
->Memory Requirements</A
-></DT
-><DT
->2.4. <A
-HREF="Bv9ARM.ch02.html#AEN245"
->Name Server Intensive Environment Issues</A
-></DT
-><DT
->2.5. <A
-HREF="Bv9ARM.ch02.html#AEN248"
->Supported Operating Systems</A
-></DT
-></DL
-></DD
-><DT
->3. <A
-HREF="Bv9ARM.ch03.html"
->Name Server Configuration</A
-></DT
-><DD
-><DL
-><DT
->3.1. <A
-HREF="Bv9ARM.ch03.html#sample_configuration"
->Sample Configurations</A
-></DT
-><DD
-><DL
-><DT
->3.1.1. <A
-HREF="Bv9ARM.ch03.html#AEN257"
->A Caching-only Name Server</A
-></DT
-><DT
->3.1.2. <A
-HREF="Bv9ARM.ch03.html#AEN262"
->An Authoritative-only Name Server</A
-></DT
-></DL
-></DD
-><DT
->3.2. <A
-HREF="Bv9ARM.ch03.html#AEN268"
->Load Balancing</A
-></DT
-><DT
->3.3. <A
-HREF="Bv9ARM.ch03.html#AEN345"
->Name Server Operations</A
-></DT
-><DD
-><DL
-><DT
->3.3.1. <A
-HREF="Bv9ARM.ch03.html#AEN347"
->Tools for Use With the Name Server Daemon</A
-></DT
-><DT
->3.3.2. <A
-HREF="Bv9ARM.ch03.html#AEN689"
->Signals</A
-></DT
-></DL
-></DD
-></DL
-></DD
-><DT
->4. <A
-HREF="Bv9ARM.ch04.html"
->Advanced DNS Features</A
-></DT
-><DD
-><DL
-><DT
->4.1. <A
-HREF="Bv9ARM.ch04.html#notify"
->Notify</A
-></DT
-><DT
->4.2. <A
-HREF="Bv9ARM.ch04.html#dynamic_update"
->Dynamic Update</A
-></DT
-><DD
-><DL
-><DT
->4.2.1. <A
-HREF="Bv9ARM.ch04.html#journal"
->The journal file</A
-></DT
-></DL
-></DD
-><DT
->4.3. <A
-HREF="Bv9ARM.ch04.html#incremental_zone_transfers"
->Incremental Zone Transfers (IXFR)</A
-></DT
-><DT
->4.4. <A
-HREF="Bv9ARM.ch04.html#AEN767"
->Split DNS</A
-></DT
-><DT
->4.5. <A
-HREF="Bv9ARM.ch04.html#tsig"
->TSIG</A
-></DT
-><DD
-><DL
-><DT
->4.5.1. <A
-HREF="Bv9ARM.ch04.html#AEN858"
->Generate Shared Keys for Each Pair of Hosts</A
-></DT
-><DT
->4.5.2. <A
-HREF="Bv9ARM.ch04.html#AEN879"
->Copying the Shared Secret to Both Machines</A
-></DT
-><DT
->4.5.3. <A
-HREF="Bv9ARM.ch04.html#AEN882"
->Informing the Servers of the Key's Existence</A
-></DT
-><DT
->4.5.4. <A
-HREF="Bv9ARM.ch04.html#AEN894"
->Instructing the Server to Use the Key</A
-></DT
-><DT
->4.5.5. <A
-HREF="Bv9ARM.ch04.html#AEN910"
->TSIG Key Based Access Control</A
-></DT
-><DT
->4.5.6. <A
-HREF="Bv9ARM.ch04.html#AEN923"
->Errors</A
-></DT
-></DL
-></DD
-><DT
->4.6. <A
-HREF="Bv9ARM.ch04.html#AEN927"
->TKEY</A
-></DT
-><DT
->4.7. <A
-HREF="Bv9ARM.ch04.html#AEN942"
->SIG(0)</A
-></DT
-><DT
->4.8. <A
-HREF="Bv9ARM.ch04.html#DNSSEC"
->DNSSEC</A
-></DT
-><DD
-><DL
-><DT
->4.8.1. <A
-HREF="Bv9ARM.ch04.html#AEN962"
->Generating Keys</A
-></DT
-><DT
->4.8.2. <A
-HREF="Bv9ARM.ch04.html#AEN982"
->Signing the Zone</A
-></DT
-><DT
->4.8.3. <A
-HREF="Bv9ARM.ch04.html#AEN1004"
->Configuring Servers</A
-></DT
-></DL
-></DD
-><DT
->4.9. <A
-HREF="Bv9ARM.ch04.html#AEN1011"
->IPv6 Support in <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9</A
-></DT
-><DD
-><DL
-><DT
->4.9.1. <A
-HREF="Bv9ARM.ch04.html#AEN1029"
->Address Lookups Using AAAA Records</A
-></DT
-><DT
->4.9.2. <A
-HREF="Bv9ARM.ch04.html#AEN1035"
->Address to Name Lookups Using Nibble Format</A
-></DT
-></DL
-></DD
-></DL
-></DD
-><DT
->5. <A
-HREF="Bv9ARM.ch05.html"
->The <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Lightweight Resolver</A
-></DT
-><DD
-><DL
-><DT
->5.1. <A
-HREF="Bv9ARM.ch05.html#AEN1044"
->The Lightweight Resolver Library</A
-></DT
-><DT
->5.2. <A
-HREF="Bv9ARM.ch05.html#lwresd"
->Running a Resolver Daemon</A
-></DT
-></DL
-></DD
-><DT
->6. <A
-HREF="Bv9ARM.ch06.html"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Configuration Reference</A
-></DT
-><DD
-><DL
-><DT
->6.1. <A
-HREF="Bv9ARM.ch06.html#configuration_file_elements"
->Configuration File Elements</A
-></DT
-><DD
-><DL
-><DT
->6.1.1. <A
-HREF="Bv9ARM.ch06.html#address_match_lists"
->Address Match Lists</A
-></DT
-><DT
->6.1.2. <A
-HREF="Bv9ARM.ch06.html#AEN1290"
->Comment Syntax</A
-></DT
-></DL
-></DD
-><DT
->6.2. <A
-HREF="Bv9ARM.ch06.html#Configuration_File_Grammar"
->Configuration File Grammar</A
-></DT
-><DD
-><DL
-><DT
->6.2.1. <A
-HREF="Bv9ARM.ch06.html#AEN1411"
-><B
-CLASS="command"
->acl</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.2. <A
-HREF="Bv9ARM.ch06.html#acl"
-><B
-CLASS="command"
->acl</B
-> Statement Definition and
-Usage</A
-></DT
-><DT
->6.2.3. <A
-HREF="Bv9ARM.ch06.html#AEN1455"
-><B
-CLASS="command"
->controls</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.4. <A
-HREF="Bv9ARM.ch06.html#controls_statement_definition_and_usage"
-><B
-CLASS="command"
->controls</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.5. <A
-HREF="Bv9ARM.ch06.html#AEN1534"
-><B
-CLASS="command"
->include</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.6. <A
-HREF="Bv9ARM.ch06.html#AEN1539"
-><B
-CLASS="command"
->include</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.7. <A
-HREF="Bv9ARM.ch06.html#AEN1546"
-><B
-CLASS="command"
->key</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.8. <A
-HREF="Bv9ARM.ch06.html#AEN1553"
-><B
-CLASS="command"
->key</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.9. <A
-HREF="Bv9ARM.ch06.html#AEN1573"
-><B
-CLASS="command"
->logging</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.10. <A
-HREF="Bv9ARM.ch06.html#AEN1613"
-><B
-CLASS="command"
->logging</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.11. <A
-HREF="Bv9ARM.ch06.html#AEN1883"
-><B
-CLASS="command"
->lwres</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.12. <A
-HREF="Bv9ARM.ch06.html#AEN1907"
-><B
-CLASS="command"
->lwres</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.13. <A
-HREF="Bv9ARM.ch06.html#AEN1926"
-><B
-CLASS="command"
->masters</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.14. <A
-HREF="Bv9ARM.ch06.html#AEN1941"
-><B
-CLASS="command"
->masters</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.15. <A
-HREF="Bv9ARM.ch06.html#AEN1946"
-><B
-CLASS="command"
->options</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.16. <A
-HREF="Bv9ARM.ch06.html#options"
-><B
-CLASS="command"
->options</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.17. <A
-HREF="Bv9ARM.ch06.html#server_statement_grammar"
-><B
-CLASS="command"
->server</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.18. <A
-HREF="Bv9ARM.ch06.html#server_statement_definition_and_usage"
-><B
-CLASS="command"
->server</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.19. <A
-HREF="Bv9ARM.ch06.html#AEN3433"
-><B
-CLASS="command"
->trusted-keys</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.20. <A
-HREF="Bv9ARM.ch06.html#AEN3449"
-><B
-CLASS="command"
->trusted-keys</B
-> Statement Definition
-and Usage</A
-></DT
-><DT
->6.2.21. <A
-HREF="Bv9ARM.ch06.html#view_statement_grammar"
-><B
-CLASS="command"
->view</B
-> Statement Grammar</A
-></DT
-><DT
->6.2.22. <A
-HREF="Bv9ARM.ch06.html#AEN3471"
-><B
-CLASS="command"
->view</B
-> Statement Definition and Usage</A
-></DT
-><DT
->6.2.23. <A
-HREF="Bv9ARM.ch06.html#zone_statement_grammar"
-><B
-CLASS="command"
->zone</B
->
-Statement Grammar</A
-></DT
-><DT
->6.2.24. <A
-HREF="Bv9ARM.ch06.html#AEN3645"
-><B
-CLASS="command"
->zone</B
-> Statement Definition and Usage</A
-></DT
-></DL
-></DD
-><DT
->6.3. <A
-HREF="Bv9ARM.ch06.html#AEN4050"
->Zone File</A
-></DT
-><DD
-><DL
-><DT
->6.3.1. <A
-HREF="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them"
->Types of Resource Records and When to Use Them</A
-></DT
-><DT
->6.3.2. <A
-HREF="Bv9ARM.ch06.html#AEN4370"
->Discussion of MX Records</A
-></DT
-><DT
->6.3.3. <A
-HREF="Bv9ARM.ch06.html#Setting_TTLs"
->Setting TTLs</A
-></DT
-><DT
->6.3.4. <A
-HREF="Bv9ARM.ch06.html#AEN4491"
->Inverse Mapping in IPv4</A
-></DT
-><DT
->6.3.5. <A
-HREF="Bv9ARM.ch06.html#AEN4518"
->Other Zone File Directives</A
-></DT
-><DT
->6.3.6. <A
-HREF="Bv9ARM.ch06.html#AEN4576"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> Master File Extension: the  <B
-CLASS="command"
->$GENERATE</B
-> Directive</A
-></DT
-></DL
-></DD
-></DL
-></DD
-><DT
->7. <A
-HREF="Bv9ARM.ch07.html"
-><ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-> 9 Security Considerations</A
-></DT
-><DD
-><DL
-><DT
->7.1. <A
-HREF="Bv9ARM.ch07.html#Access_Control_Lists"
->Access Control Lists</A
-></DT
-><DT
->7.2. <A
-HREF="Bv9ARM.ch07.html#AEN4693"
-><B
-CLASS="command"
->chroot</B
-> and <B
-CLASS="command"
->setuid</B
-> (for
-UNIX servers)</A
-></DT
-><DD
-><DL
-><DT
->7.2.1. <A
-HREF="Bv9ARM.ch07.html#AEN4716"
->The <B
-CLASS="command"
->chroot</B
-> Environment</A
-></DT
-><DT
->7.2.2. <A
-HREF="Bv9ARM.ch07.html#AEN4734"
->Using the <B
-CLASS="command"
->setuid</B
-> Function</A
-></DT
-></DL
-></DD
-><DT
->7.3. <A
-HREF="Bv9ARM.ch07.html#dynamic_update_security"
->Dynamic Update Security</A
-></DT
-></DL
-></DD
-><DT
->8. <A
-HREF="Bv9ARM.ch08.html"
->Troubleshooting</A
-></DT
-><DD
-><DL
-><DT
->8.1. <A
-HREF="Bv9ARM.ch08.html#AEN4755"
->Common Problems</A
-></DT
-><DD
-><DL
-><DT
->8.1.1. <A
-HREF="Bv9ARM.ch08.html#AEN4757"
->It's not working; how can I figure out what's wrong?</A
-></DT
-></DL
-></DD
-><DT
->8.2. <A
-HREF="Bv9ARM.ch08.html#AEN4760"
->Incrementing and Changing the Serial Number</A
-></DT
-><DT
->8.3. <A
-HREF="Bv9ARM.ch08.html#AEN4765"
->Where Can I Get Help?</A
-></DT
-></DL
-></DD
-><DT
->A. <A
-HREF="Bv9ARM.ch09.html"
->Appendices</A
-></DT
-><DD
-><DL
-><DT
->A.1. <A
-HREF="Bv9ARM.ch09.html#AEN4781"
->Acknowledgments</A
-></DT
-><DD
-><DL
-><DT
->A.1.1. <A
-HREF="Bv9ARM.ch09.html#AEN4783"
->A Brief History of the <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> and <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-></A
-></DT
-></DL
-></DD
-><DT
->A.2. <A
-HREF="Bv9ARM.ch09.html#historical_dns_information"
->General <ACRONYM
-CLASS="acronym"
->DNS</ACRONYM
-> Reference Information</A
-></DT
-><DD
-><DL
-><DT
->A.2.1. <A
-HREF="Bv9ARM.ch09.html#ipv6addresses"
->IPv6 addresses (AAAA)</A
-></DT
-></DL
-></DD
-><DT
->A.3. <A
-HREF="Bv9ARM.ch09.html#bibliography"
->Bibliography (and Suggested Reading)</A
-></DT
-><DD
-><DL
-><DT
->A.3.1. <A
-HREF="Bv9ARM.ch09.html#rfcs"
->Request for Comments (RFCs)</A
-></DT
-><DT
->A.3.2. <A
-HREF="Bv9ARM.ch09.html#internet_drafts"
->Internet Drafts</A
-></DT
-><DT
->A.3.3. <A
-HREF="Bv9ARM.ch09.html#AEN5378"
->Other Documents About <ACRONYM
-CLASS="acronym"
->BIND</ACRONYM
-></A
-></DT
-></DL
-></DD
-></DL
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="Bv9ARM.ch01.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
->&nbsp;</TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Introduction</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
+<!--
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000-2003 Internet Software Consortium.
+ - 
+ - Permission to use, copy, modify, and distribute this software for any
+ - purpose with or without fee is hereby granted, provided that the above
+ - copyright notice and this permission notice appear in all copies.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ - PERFORMANCE OF THIS SOFTWARE.
+-->
+<!-- $Id: Bv9ARM.html,v 1.60.2.9.2.26 2005/10/13 02:33:59 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>BIND 9 Administrator Reference Manual</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="next" href="Bv9ARM.ch01.html" title="Chapter 1. Introduction ">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="navheader">
+<table width="100%" summary="Navigation header">
+<tr><th colspan="3" align="center">BIND 9 Administrator Reference Manual</th></tr>
+<tr>
+<td width="20%" align="left"> </td>
+<th width="60%" align="center"> </th>
+<td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch01.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="book" lang="en">
+<div class="titlepage">
+<div>
+<div><h1 class="title">
+<a name="id2463864"></a>BIND 9 Administrator Reference Manual</h1></div>
+<div><p class="copyright">Copyright © 2004, 2005 Internet Systems Consortium, Inc. ("ISC")</p></div>
+<div><p class="copyright">Copyright © 2000-2003 Internet Software Consortium.</p></div>
+</div>
+<hr>
+</div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="chapter"><a href="Bv9ARM.ch01.html">1. Introduction </a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545879">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545905">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2545976">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2546234">The Domain Name System (<span class="acronym">DNS</span>)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546254">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2544105">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546579">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546653">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2546950">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2547076">Name Servers in Multiple Roles</a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch02.html">2. <span class="acronym">BIND</span> Resource Requirements</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547108">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547132">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547143">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547158">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2547303">Supported Operating Systems</a></span></dt>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch03.html">3. Name Server Configuration</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547334">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547350">An Authoritative-only Name Server</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2547372">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2547656">Name Server Operations</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2547661">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2548915">Signals</a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch04.html">4. Advanced DNS Features</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#notify">Notify</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2549203">Split DNS</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549627">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549830">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549838">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549878">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2549998">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550042">Errors</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550056">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550173">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550308">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550375">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550450">Configuring Servers</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2550473">IPv6 Support in <span class="acronym">BIND</span> 9</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550600">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2550620">Address to Name Lookups Using Nibble Format</a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch05.html">5. The <span class="acronym">BIND</span> 9 Lightweight Resolver</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2550652">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch06.html">6. <span class="acronym">BIND</span> 9 Configuration Reference</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2551817">Comment Syntax</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552302"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
+Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552471"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552808"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552823"><span><strong class="command">include</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552845"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2552867"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553006"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2553269"><span><strong class="command">logging</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554474"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554547"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554610"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554653"><span><strong class="command">masters</strong></span> Statement Definition and Usage </a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2554668"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562233"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562281"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2562349"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
+Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2563022"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2564557">Zone File</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2565990">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566487">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566593">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2566761"><span class="acronym">BIND</span> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+</dl></dd>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <span class="acronym">BIND</span> 9 Security Considerations</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2567222"><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
+UNIX servers)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567366">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2567424">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+</dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
+</dl></dd>
+<dt><span class="chapter"><a href="Bv9ARM.ch08.html">8. Troubleshooting</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567630">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2567636">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567648">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2567665">Where Can I Get Help?</a></span></dt>
+</dl></dd>
+<dt><span class="appendix"><a href="Bv9ARM.ch09.html">A. Appendices</a></span></dt>
+<dd><dl>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2567795">Acknowledgments</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2567800">A Brief History of the <span class="acronym">DNS</span> and <span class="acronym">BIND</span></a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#historical_dns_information">General <span class="acronym">DNS</span> Reference Information</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2570087">Other Documents About <span class="acronym">BIND</span></a></span></dt>
+</dl></dd>
+</dl></dd>
+</dl>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left"> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch01.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top"> </td>
+<td width="20%" align="center"> </td>
+<td width="40%" align="right" valign="top"> Chapter 1. Introduction </td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/Makefile.in b/contrib/bind9/doc/arm/Makefile.in
index ede9342535da..88a54e30a542 100644
--- a/contrib/bind9/doc/arm/Makefile.in
+++ b/contrib/bind9/doc/arm/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001, 2002  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.8.2.2.8.3 2004/03/08 09:04:24 marka Exp $
+# $Id: Makefile.in,v 1.8.2.2.8.5 2005/05/13 01:22:35 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -23,47 +23,41 @@ top_srcdir =	@top_srcdir@
 
 MANOBJS = Bv9ARM.html
 
+PDFOBJS = Bv9ARM.pdf
+
 distclean::
 	rm -f validate.sh
 	rm -f nominum-docbook-html.dsl nominum-docbook-print.dsl
 	rm -f HTML.index HTML.manifest
 
-doc man:: ${MANOBJS}
+doc man:: ${MANOBJS} ${PDFOBJS}
 
-docclean manclean maintainer-clean::
-	rm -f *.html
+clean::
+	rm -f Bv9ARM.aux Bv9ARM.brf Bv9ARM.glo Bv9ARM.idx
+	rm -f Bv9ARM.log Bv9ARM.out Bv9ARM.tex Bv9ARM.tex.tmp
 
-Bv9ARM.html: Bv9ARM-book.xml nominum-docbook-html.dsl
-	${OPENJADE} -v \
-	    -c ${SGMLCATALOG} \
-	    -t sgml \
-	    -d ./nominum-docbook-html.dsl \
-	    ${XMLDCL} ./Bv9ARM-book.xml
-	rm -f HTML.index HTML.manifest
+docclean manclean maintainer-clean:: clean
+	rm -f *.html *.pdf
 
-Bv9ARM-book.rtf: Bv9ARM-book.xml nominum-docbook-print.dsl
-	${OPENJADE} -v \
-	    -c ${SGMLCATALOG} \
-	    -t rtf \
-	    -d ./nominum-docbook-print.dsl \
-	    ${XMLDCL} ./Bv9ARM-book.xml
+Bv9ARM.html: Bv9ARM-book.xml
+	${XSLTPROC} --stringparam root.filename Bv9ARM \
+		${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl \
+		Bv9ARM-book.xml
 
-Bv9ARM-book.tex: Bv9ARM-book.xml nominum-docbook-print.dsl
-	${OPENJADE} -v \
-	     -c ${SGMLCATALOG} \
-	     -d ./nominum-docbook-print.dsl \
-	     -t tex \
-	     ${XMLDCL} ./Bv9ARM-book.xml
+Bv9ARM.tex: Bv9ARM-book.xml
+	${XSLTPROC} ${top_srcdir}/doc/xsl/pre-latex.xsl Bv9ARM-book.xml | \
+	${XSLTPROC} ${top_srcdir}/doc/xsl/isc-docbook-latex.xsl - | \
+	@PERL@ latex-fixup.pl >$@.tmp 
+	if test -s $@.tmp; then mv $@.tmp $@; else rm -f $@.tmp; exit 1; fi
 
-Bv9ARM-book.dvi: Bv9ARM-book.tex
+Bv9ARM.dvi: Bv9ARM.tex
 	rm -f Bv9ARM-book.aux Bv9ARM-book.dvi Bv9ARM-book.log
-	${JADETEX} ./Bv9ARM-book.tex || true
-	${JADETEX} ./Bv9ARM-book.tex || true
-	${JADETEX} ./Bv9ARM-book.tex || true
+	${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
+	${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
+	${LATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
 
-Bv9ARM-book.pdf: Bv9ARM-book.tex
+Bv9ARM.pdf: Bv9ARM.tex
 	rm -f Bv9ARM-book.aux Bv9ARM-book.pdf Bv9ARM-book.log
-	${PDFJADETEX} ./Bv9ARM-book.tex || true
-	${PDFJADETEX} ./Bv9ARM-book.tex || true
-	${PDFJADETEX} ./Bv9ARM-book.tex || true
-
+	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
+	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
+	${PDFLATEX} '\batchmode\input Bv9ARM.tex' || rm -f $@
diff --git a/contrib/bind9/doc/arm/isc.color.gif b/contrib/bind9/doc/arm/isc.color.gif
deleted file mode 100644
index 09c327cca65d..000000000000
--- a/contrib/bind9/doc/arm/isc.color.gif
+++ /dev/null
diff --git a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in
deleted file mode 100644
index 33fc938777a4..000000000000
--- a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in
+++ /dev/null
@@ -1,148 +0,0 @@
-<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
-<!ENTITY dbstyle SYSTEM "@HTMLSTYLE@" CDATA DSSSL>
-]>
-
-<style-sheet>
-<style-specification use="docbook">
-<style-specification-body>
-
-<!-- ;; your stuff goes here... -->
-
-(define %html-prefix% 
-  ;; Add the specified prefix to HTML output filenames
-  "Bv9ARM.")
-
-(define %use-id-as-filename%
-  ;; Use ID attributes as name for component HTML files?
-  #t)
-
-(define %root-filename%
-  ;; Name for the root HTML document
-  "Bv9ARM")
-
-(define %section-autolabel%
-  ;; REFENTRY section-autolabel
-  ;; PURP Are sections enumerated?
-  ;; DESC
-  ;; If true, unlabeled sections will be enumerated.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-(define %html-ext% 
-  ;; REFENTRY html-ext
-  ;; PURP Default extension for HTML output files
-  ;; DESC
-  ;; The default extension for HTML output files.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  ".html")
-
-(define nochunks
-  ;; REFENTRY nochunks
-  ;; PURP Suppress chunking of output pages
-  ;; DESC
-  ;; If true, the entire source document is formatted as a single HTML
-  ;; document and output on stdout.
-  ;; (This option can conveniently be set with '-V nochunks' on the 
-  ;; Jade command line).
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #f)
-
-(define rootchunk
-  ;; REFENTRY rootchunk
-  ;; PURP Make a chunk for the root element when nochunks is used
-  ;; DESC
-  ;; If true, a chunk will be created for the root element, even though
-  ;; nochunks is specified. This option has no effect if nochunks is not
-  ;; true.
-  ;; (This option can conveniently be set with '-V rootchunk' on the 
-  ;; Jade command line).
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-(define html-index
-  ;; REFENTRY html-index
-  ;; PURP HTML indexing?
-  ;; DESC
-  ;; Turns on HTML indexing.  If true, then index data will be written
-  ;; to the file defined by 'html-index-filename'.  This data can be
-  ;; collated and turned into a DocBook index with bin/collateindex.pl.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-(define html-manifest
-  ;; REFENTRY html-manifest
-  ;; PURP Write a manifest?
-  ;; DESC
-  ;; If not '#f' then the list of HTML files created by the stylesheet
-  ;; will be written to the file named by 'html-manifest-filename'.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-(define (chunk-element-list)
-  (list (normalize "preface")
-	(normalize "chapter")
-	(normalize "appendix") 
-	(normalize "article")
-	(normalize "glossary")
-	(normalize "bibliography")
-	(normalize "index")
-	(normalize "colophon")
-	(normalize "setindex")
-	(normalize "reference")
-	(normalize "refentry")
-	(normalize "part")
-	(normalize "book") ;; just in case nothing else matches...
-	(normalize "set")  ;; sets are definitely chunks...
-	))
-
-;
-; Add some cell padding to tables so that they don't look so cramped
-; in Netscape.
-;
-; The following definition was cut-and-pasted from dbtable.dsl and the 
-; single line containing the word CELLPADDING was added.
-;
-(element tgroup
-  (let* ((wrapper   (parent (current-node)))
-	 (frameattr (attribute-string (normalize "frame") wrapper))
-	 (pgwide    (attribute-string (normalize "pgwide") wrapper))
-	 (footnotes (select-elements (descendants (current-node)) 
-				     (normalize "footnote")))
-	 (border (if (equal? frameattr (normalize "none"))
-		     '(("BORDER" "0"))
-		     '(("BORDER" "1"))))
-	 (width (if (equal? pgwide "1")
-		    (list (list "WIDTH" ($table-width$)))
-		    '()))
-	 (head (select-elements (children (current-node)) (normalize "thead")))
-	 (body (select-elements (children (current-node)) (normalize "tbody")))
-	 (feet (select-elements (children (current-node)) (normalize "tfoot"))))
-    (make element gi: "TABLE"
-	  attributes: (append
-		       '(("CELLPADDING" "3"))
-		       border
-		       width
-		       (if %cals-table-class%
-			   (list (list "CLASS" %cals-table-class%))
-			   '()))
-	  (process-node-list head)
-	  (process-node-list body)
-	  (process-node-list feet)
-	  (make-table-endnotes))))
-
-</style-specification-body>
-</style-specification>
-<external-specification id="docbook" document="dbstyle">
-</style-sheet>
diff --git a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in
deleted file mode 100644
index 511d6c48bc8c..000000000000
--- a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in
+++ /dev/null
@@ -1,42 +0,0 @@
-<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
-<!ENTITY dbstyle SYSTEM "@PRINTSTYLE@" CDATA DSSSL>
-]>
-
-
-<style-sheet>
-<style-specification use="docbook">
-<style-specification-body>
-
-<!-- ;; your stuff goes here... -->
-
-(define %generate-book-titlepage% #t)
-
-(define %section-autolabel%
-  ;; REFENTRY section-autolabel
-  ;; PURP Are sections enumerated?
-  ;; DESC
-  ;; If true, unlabeled sections will be enumerated.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-;; Margins around cell contents
-;; (define %cals-cell-before-row-margin% 20pt)
-;; (define %cals-cell-after-row-margin% 20pt)
-
-;; seems to be a bug in JadeTeX -- we get a wierd indent on table
-;;   cells for the first line only.  This is a workaround.
-;; Adam Di Carlo, adam@onshore.com
-(define %cals-cell-before-column-margin% 5pt)
-(define %cals-cell-after-column-margin% 5pt)
-
-;; Inheritable start and end indent for cell contents
-(define %cals-cell-content-start-indent% 5pt)
-(define %cals-cell-content-end-indent% 5pt)
-
-
-</style-specification-body>
-</style-specification>
-<external-specification id="docbook" document="dbstyle">
-</style-sheet>
diff --git a/contrib/bind9/doc/arm/validate.sh.in b/contrib/bind9/doc/arm/validate.sh.in
deleted file mode 100644
index f50d8a09dbda..000000000000
--- a/contrib/bind9/doc/arm/validate.sh.in
+++ /dev/null
@@ -1,21 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2000, 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-# PERFORMANCE OF THIS SOFTWARE.
-
-# $Id: validate.sh.in,v 1.2.206.1 2004/03/06 13:16:14 marka Exp $
-
-nsgmls -sv @SGMLDIR@/docbook/dsssl/modular/dtds/decls/xml.dcl \
-       Bv9ARM-book.xml
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
deleted file mode 100644
index 09776618f2ae..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
+++ /dev/null
@@ -1,561 +0,0 @@
-
-
-DNSEXT                                                          M. Stapp
-Internet-Draft                                       Cisco Systems, Inc.
-Expires: January 14, 2005                                       T. Lemon
-                                                           A. Gustafsson
-                                                           Nominum, Inc.
-                                                           July 16, 2004
-
-
-           A DNS RR for Encoding DHCP Information (DHCID RR)
-                  <draft-ietf-dnsext-dhcid-rr-08.txt>
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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.
-
-   This Internet-Draft will expire on January 14, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   It is possible for multiple DHCP clients to attempt to update the
-   same DNS FQDN as they obtain DHCP leases.  Whether the DHCP server or
-   the clients themselves perform the DNS updates, conflicts can arise.
-   To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
-   proposes storing client identifiers in the DNS to unambiguously
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 1]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-   associate domain names with the DHCP clients to which they refer.
-   This memo defines a distinct RR type for this purpose for use by DHCP
-   clients and servers, the "DHCID" RR.
-
-Table of Contents
-
-   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1   DHCID RDATA format . . . . . . . . . . . . . . . . . . . .  4
-     3.2   DHCID Presentation Format  . . . . . . . . . . . . . . . .  4
-     3.3   The DHCID RR Type Codes  . . . . . . . . . . . . . . . . .  4
-     3.4   Computation of the RDATA . . . . . . . . . . . . . . . . .  4
-     3.5   Examples . . . . . . . . . . . . . . . . . . . . . . . . .  5
-       3.5.1   Example 1  . . . . . . . . . . . . . . . . . . . . . .  6
-       3.5.2   Example 2  . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . . .  6
-   5.  Updater Behavior . . . . . . . . . . . . . . . . . . . . . . .  6
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   9.1   Normative References . . . . . . . . . . . . . . . . . . . .  8
-   9.2   Informative References . . . . . . . . . . . . . . . . . . .  8
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
-       Intellectual Property and Copyright Statements . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 2]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-1.  Terminology
-
-   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].
-
-2.  Introduction
-
-   A set of procedures to allow DHCP [7] clients and servers to
-   automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
-   in "Resolution of DNS Name Conflicts" [1].
-
-   Conflicts can arise if multiple DHCP clients wish to use the same DNS
-   name.  To resolve such conflicts, "Resolution of DNS Name Conflicts"
-   [1] proposes storing client identifiers in the DNS to unambiguously
-   associate domain names with the DHCP clients using them.  In the
-   interest of clarity, it is preferable for this DHCP information to
-   use a distinct RR type.  This memo defines a distinct RR for this
-   purpose for use by DHCP clients or servers, the "DHCID" RR.
-
-   In order to avoid exposing potentially sensitive identifying
-   information, the data stored is the result of a one-way MD5 [5] hash
-   computation.  The hash includes information from the DHCP client's
-   REQUEST message as well as the domain name itself, so that the data
-   stored in the DHCID RR will be dependent on both the client
-   identification used in the DHCP protocol interaction and the domain
-   name.  This means that the DHCID RDATA will vary if a single client
-   is associated over time with more than one name.  This makes it
-   difficult to 'track' a client as it is associated with various domain
-   names.
-
-   The MD5 hash algorithm has been shown to be weaker than the SHA-1
-   algorithm; it could therefore be argued that SHA-1 is a better
-   choice.  However, SHA-1 is significantly slower than MD5.  A
-   successful attack of MD5's weakness does not reveal the original data
-   that was used to generate the signature, but rather provides a new
-   set of input data that will produce the same signature.  Because we
-   are using the MD5 hash to conceal the original data, the fact that an
-   attacker could produce a different plaintext resulting in the same
-   MD5 output is not significant concern.
-
-3.  The DHCID RR
-
-   The DHCID RR is defined with mnemonic DHCID and type code [TBD].  The
-   DHCID RR is only defined in the IN class.  DHCID RRs cause no
-   additional section processing.  The DHCID RR is not a singleton type.
-
-
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 3]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-3.1  DHCID RDATA format
-
-   The RDATA section of a DHCID RR in transmission contains RDLENGTH
-   bytes of binary data.  The format of this data and its interpretation
-   by DHCP servers and clients are described below.
-
-   DNS software should consider the RDATA section to be opaque.  DHCP
-   clients or servers use the DHCID RR to associate a DHCP client's
-   identity with a DNS name, so that multiple DHCP clients and servers
-   may deterministically perform dynamic DNS updates to the same zone.
-   From the updater's perspective, the DHCID resource record RDATA
-   consists of a 16-bit identifier type, in network byte order, followed
-   by one or more bytes representing the actual identifier:
-
-     	< 16 bits >	DHCP identifier used
-     	< n bytes >	MD5 digest
-
-
-3.2  DHCID Presentation Format
-
-   In DNS master files, the RDATA is represented as a single block in
-   base 64 encoding identical to that used for representing binary data
-   in RFC 2535 [8].  The data may be divided up into any number of white
-   space separated substrings, down to single base 64 digits, which are
-   concatenated to form the complete RDATA.  These substrings can span
-   lines using the standard parentheses.
-
-3.3  The DHCID RR Type Codes
-
-   The DHCID RR Type Code specifies what data from the DHCP client's
-   request was used as input into the hash function.  The type codes are
-   defined in a registry maintained by IANA, as specified in Section 7.
-   The initial list of assigned values for the type code is:
-
-   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
-   0x0001 = The data portion from a DHCPv4 client's Client Identifier
-      option [9].
-   0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
-      client's Client Identifier option [10] or the DUID field from a
-      DHCPv4 client's Client Identifier option [12]).
-
-   0x0003 - 0xfffe = Available to be assigned by IANA.
-
-   0xffff = RESERVED
-
-3.4  Computation of the RDATA
-
-   The DHCID RDATA is formed by concatenating the two type bytes with
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 4]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-   some variable-length identifying data.
-
-       < type > < data >
-
-   The RDATA for all type codes other than 0xffff, which is reserved for
-   future expansion, is formed by concatenating the two type bytes and a
-   16-byte MD5 hash value.  The input to the hash function is defined to
-   be:
-
-       data = MD5(< identifier > < FQDN >)
-
-   The FQDN is represented in the buffer in unambiguous canonical form
-   as described in RFC 2535 [8], section 8.1.  The type code and the
-   identifier are related as specified in Section 3.3: the type code
-   describes the source of the identifier.
-
-   When the updater is using the client's link-layer address as the
-   identifier, the first two bytes of the DHCID RDATA MUST be zero.  To
-   generate the rest of the resource record, the updater computes a
-   one-way hash using the MD5 algorithm across a buffer containing the
-   client's network hardware type, link-layer address, and the FQDN
-   data.  Specifically, the first byte of the buffer contains the
-   network hardware type as it appeared in the DHCP 'htype' field of the
-   client's DHCPREQUEST message.  All of the significant bytes of the
-   chaddr field in the client's DHCPREQUEST message follow, in the same
-   order in which the bytes appear in the DHCPREQUEST message.  The
-   number of significant bytes in the 'chaddr' field is specified in the
-   'hlen' field of the DHCPREQUEST message.  The FQDN data, as specified
-   above, follows.
-
-   When the updater is using the DHCPv4 Client Identifier option sent by
-   the client in its DHCPREQUEST message, the first two bytes of the
-   DHCID RR MUST be 0x0001, in network byte order.  The rest of the
-   DHCID RR MUST contain the results of computing an MD5 hash across the
-   payload of the option, followed by the FQDN.  The payload of the
-   option consists of the bytes of the option following the option code
-   and length.
-
-   When the updater is using the DHCPv6 DUID sent by the client in its
-   REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
-   in network byte order.  The rest of the DHCID RR MUST contain the
-   results of computing an MD5 hash across the payload of the option,
-   followed by the FQDN.  The payload of the option consists of the
-   bytes of the option following the option code and length.
-
-3.5  Examples
-
-
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 5]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-3.5.1  Example 1
-
-   A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
-   Ethernet MAC address 01:02:03:04:05:06 using domain name
-   "client.example.com" uses the client's link-layer address to identify
-   the client.  The DHCID RDATA is composed by setting the two type
-   bytes to zero, and performing an MD5 hash computation across a buffer
-   containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
-   address, and the domain name (represented as specified in Section
-   3.4).
-
-     client.example.com.	A   	10.0.0.1
-     client.example.com. 	DHCID 	AAAUMru0ZM5OK/PdVAJgZ/HU
-
-
-3.5.2  Example 2
-
-   A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
-   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
-   in its DHCP request.  The server updates the name "chi.example.com"
-   on the client's behalf, and uses the DHCP client identifier option
-   data as input in forming a DHCID RR.  The DHCID RDATA is formed by
-   setting the two type bytes to the value 0x0001, and performing an MD5
-   hash computation across a buffer containing the seven bytes from the
-   client-id option and the FQDN (represented as specified in Section
-   3.4).
-
-     chi.example.com.	A    	10.0.12.99
-     chi.example.com.	DHCID 	AAHdd5jiQ3kEjANDm82cbObk\012
-
-
-4.  Use of the DHCID RR
-
-   This RR MUST NOT be used for any purpose other than that detailed in
-   "Resolution of DNS Name Conflicts" [1].  Although this RR contains
-   data that is opaque to DNS servers, the data must be consistent
-   across all entities that update and interpret this record.
-   Therefore, new data formats may only be defined through actions of
-   the DHC Working Group, as a result of revising [1].
-
-5.  Updater Behavior
-
-   The data in the DHCID RR allows updaters to determine whether more
-   than one DHCP client desires to use a particular FQDN.  This allows
-   site administrators to establish policy about DNS updates.  The DHCID
-   RR does not establish any policy itself.
-
-   Updaters use data from a DHCP client's request and the domain name
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 6]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-   that the client desires to use to compute a client identity hash, and
-   then compare that hash to the data in any DHCID RRs on the name that
-   they wish to associate with the client's IP address.  If an updater
-   discovers DHCID RRs whose RDATA does not match the client identity
-   that they have computed, the updater SHOULD conclude that a different
-   client is currently associated with the name in question.  The
-   updater SHOULD then proceed according to the site's administrative
-   policy.  That policy might dictate that a different name be selected,
-   or it might permit the updater to continue.
-
-6.  Security Considerations
-
-   The DHCID record as such does not introduce any new security problems
-   into the DNS.  In order to avoid exposing private information about
-   DHCP clients to public scrutiny, a one-way hash is used to obscure
-   all client information.  In order to make it difficult to 'track' a
-   client by examining the names associated with a particular hash
-   value, the FQDN is included in the hash computation.  Thus, the RDATA
-   is dependent on both the DHCP client identification data and on each
-   FQDN associated with the client.
-
-   Administrators should be wary of permitting unsecured DNS updates to
-   zones which are exposed to the global Internet.  Both DHCP clients
-   and servers SHOULD use some form of update authentication (e.g., TSIG
-   [11]) when performing DNS updates.
-
-7.  IANA Considerations
-
-   IANA is requested to allocate an RR type number for the DHCID record
-   type.
-
-   This specification defines a new number-space for the 16-bit type
-   codes associated with the DHCID RR.  IANA is requested to establish a
-   registry of the values for this number-space.
-
-   Three initial values are assigned in Section 3.3, and the value
-   0xFFFF is reserved for future use.  New DHCID RR type codes are
-   tentatively assigned after the specification for the associated type
-   code, published as an Internet Draft, has received expert review by a
-   designated expert.  The final assignment of DHCID RR type codes is
-   through Standards Action, as defined in RFC 2434 [6].
-
-8.  Acknowledgements
-
-   Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
-   Ralph Droms for their review and suggestions.
-
-
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 7]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]  Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
-        DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [4]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [5]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
-        1992.
-
-   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-9.2  Informative References
-
-   [7]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-         March 1997.
-
-   [8]   Eastlake, D., "Domain Name System Security Extensions", RFC
-         2535, March 1999.
-
-   [9]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-         Extensions", RFC 2132, March 1997.
-
-   [10]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
-         Carney, "Dynamic Host Configuration Protocol for IPv6
-         (DHCPv6)", RFC 3315, July 2003.
-
-   [11]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-         2845, May 2000.
-
-   [12]  Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
-         for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 8]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-Authors' Addresses
-
-   Mark Stapp
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxborough, MA  01719
-   USA
-
-   Phone: 978.936.1535
-   EMail: mjs@cisco.com
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter St.
-   Redwood City, CA  94063
-   USA
-
-   EMail: mellon@nominum.com
-
-
-   Andreas Gustafsson
-   Nominum, Inc.
-   950 Charter St.
-   Redwood City, CA  94063
-   USA
-
-   EMail: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires January 14, 2005                [Page 9]
-
-Internet-Draft                The DHCID RR                     July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Stapp, et al.           Expires January 14, 2005               [Page 10]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
deleted file mode 100644
index 0783e7b26e14..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
+++ /dev/null
@@ -1,1457 +0,0 @@
-
-
-DNS Extensions                                                 R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: January 13, 2005                                     R. Austein
-                                                                     ISC
-                                                               M. Larson
-                                                                VeriSign
-                                                               D. Massey
-                                                                 USC/ISI
-                                                                 S. Rose
-                                                                    NIST
-                                                           July 15, 2004
-
-
-               DNS Security Introduction and Requirements
-                   draft-ietf-dnsext-dnssec-intro-11
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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.
-
-   This Internet-Draft will expire on January 13, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   The Domain Name System Security Extensions (DNSSEC) add data origin
-   authentication and data integrity to the Domain Name System.  This
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 1]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-   document introduces these extensions, and describes their
-   capabilities and limitations.  This document also discusses the
-   services that the DNS security extensions do and do not provide.
-   Last, this document describes the interrelationships between the
-   group of documents that collectively describe DNSSEC.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . . .  4
-   3.  Services Provided by DNS Security  . . . . . . . . . . . . . .  8
-     3.1   Data Origin Authentication and Data Integrity  . . . . . .  8
-     3.2   Authenticating Name and Type Non-Existence . . . . . . . .  9
-   4.  Services Not Provided by DNS Security  . . . . . . . . . . . . 11
-   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12
-   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . . . 14
-   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15
-   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . . . 16
-     8.1   TTL values vs. RRSIG validity period . . . . . . . . . . . 16
-     8.2   New Temporal Dependency Issues for Zones . . . . . . . . . 16
-   9.  Name Server Considerations . . . . . . . . . . . . . . . . . . 17
-   10.   DNS Security Document Family . . . . . . . . . . . . . . . . 18
-   11.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 19
-   12.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
-   13.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
-   14.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
-   14.1  Normative References . . . . . . . . . . . . . . . . . . . . 23
-   14.2  Informative References . . . . . . . . . . . . . . . . . . . 23
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
-       Intellectual Property and Copyright Statements . . . . . . . . 26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 2]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-1.  Introduction
-
-   This document introduces the Domain Name System Security Extensions
-   (DNSSEC).  This document and its two companion documents
-   ([I-D.ietf-dnsext-dnssec-records] and
-   [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
-   security extensions defined in RFC 2535 [RFC2535] and its
-   predecessors.  These security extensions consist of a set of new
-   resource record types and modifications to the existing DNS protocol
-   [RFC1035].  The new records and protocol modifications are not fully
-   described in this document, but are described in a family of
-   documents outlined in Section 10.  Section 3 and Section 4 describe
-   the capabilities and limitations of the security extensions in
-   greater detail.  Section 5 discusses the scope of the document set.
-   Section 6, Section 7, Section 8, and Section 9 discuss the effect
-   that these security extensions will have on resolvers, stub
-   resolvers, zones and name servers.
-
-   This document and its two companions update and obsolete RFCs 2535
-   [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
-   [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
-   [I-D.ietf-dnsext-nsec-rdata].  This document set also updates, but
-   does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
-   [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
-   of 3226 [RFC3226] (dealing with DNSSEC).
-
-   The DNS security extensions provide origin authentication and
-   integrity protection for DNS data, as well as a means of public key
-   distribution.  These extensions do not provide confidentiality.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 3]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-2.  Definitions of Important DNSSEC Terms
-
-   This section defines a number of terms used in this document set.
-   Since this is intended to be useful as a reference while reading the
-   rest of the document set, first-time readers may wish to skim this
-   section quickly, read the rest of this document, then come back to
-   this section.
-
-   Authentication Chain: An alternating sequence of DNSKEY RRsets and DS
-      RRsets forms a chain of signed data, with each link in the chain
-      vouching for the next.  A DNSKEY RR is used to verify the
-      signature covering a DS RR and allows the DS RR to be
-      authenticated.  The DS RR contains a hash of another DNSKEY RR and
-      this new DNSKEY RR is authenticated by matching the hash in the DS
-      RR.  This new DNSKEY RR in turn authenticates another DNSKEY RRset
-      and, in turn, some DNSKEY RR in this set may be used to
-      authenticate another DS RR and so forth until the chain finally
-      ends with a DNSKEY RR whose corresponding private key signs the
-      desired DNS data.  For example, the root DNSKEY RRset can be used
-      to authenticate the DS RRset for "example."  The "example." DS
-      RRset contains a hash that matches some "example." DNSKEY, and
-      this DNSKEY's corresponding private key signs the "example."
-      DNSKEY RRset.  Private key counterparts of the "example." DNSKEY
-      RRset sign data records such as "www.example." as well as DS RRs
-      for delegations such as "subzone.example."
-
-   Authentication Key: A public key that a security-aware resolver has
-      verified and can therefore use to authenticate data.  A
-      security-aware resolver can obtain authentication keys in three
-      ways.  First, the resolver is generally configured to know about
-      at least one public key; this configured data is usually either
-      the public key itself or a hash of the public key as found in the
-      DS RR (see "trust anchor").  Second, the resolver may use an
-      authenticated public key to verify a DS RR and the DNSKEY RR to
-      which the DS RR refers.  Third, the resolver may be able to
-      determine that a new public key has been signed by the private key
-      corresponding to another public key which the resolver has
-      verified.  Note that the resolver must always be guided by local
-      policy when deciding whether to authenticate a new public key,
-      even if the local policy is simply to authenticate any new public
-      key for which the resolver is able verify the signature.
-
-   Delegation Point: Term used to describe the name at the parental side
-      of a zone cut.  That is, the delegation point for "foo.example"
-      would be the foo.example node in the "example" zone (as opposed to
-      the zone apex of the "foo.example" zone).
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 4]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-   Island of Security: Term used to describe a signed, delegated zone
-      that does not have an authentication chain from its delegating
-      parent.  That is, there is no DS RR containing a hash of a DNSKEY
-      RR for the island in its delegating parent zone (see
-      [I-D.ietf-dnsext-dnssec-records]).  An island of security is
-      served by security-aware name servers and may provide
-      authentication chains to any delegated child zones.  Responses
-      from an island of security or its descendents can only be
-      authenticated if its authentication keys can be authenticated by
-      some trusted means out of band from the DNS protocol.
-
-   Key Signing Key (KSK): An authentication key that corresponds to a
-      private key used to sign one or more other authentication keys for
-      a given zone.  Typically, the private key corresponding to a key
-      signing key will sign a zone signing key, which in turn has a
-      corresponding private key which will sign other zone data.  Local
-      policy may require the zone signing key to be changed frequently,
-      while the key signing key may have a longer validity period in
-      order to provide a more stable secure entry point into the zone.
-      Designating an authentication key as a key signing key is purely
-      an operational issue: DNSSEC validation does not distinguish
-      between key signing keys and other DNSSEC authentication keys, and
-      it is possible to use a single key as both a key signing key and a
-      zone signing key.  Key signing keys are discussed in more detail
-      in [RFC3757].  Also see: zone signing key.
-
-   Non-Validating Security-Aware Stub Resolver: A security-aware stub
-      resolver which trusts one or more security-aware recursive name
-      servers to perform most of the tasks discussed in this document
-      set on its behalf.  In particular, a non-validating security-aware
-      stub resolver is an entity which sends DNS queries, receives DNS
-      responses, and is capable of establishing an appropriately secured
-      channel to a security-aware recursive name server which will
-      provide these services on behalf of the security-aware stub
-      resolver.  See also: security-aware stub resolver, validating
-      security-aware stub resolver.
-
-   Non-Validating Stub Resolver: A less tedious term for a
-      non-validating security-aware stub resolver.
-
-   Security-Aware Name Server: An entity acting in the role of a name
-      server (defined in section 2.4 of [RFC1034]) that understands the
-      DNS security extensions defined in this document set.  In
-      particular, a security-aware name server is an entity which
-      receives DNS queries, sends DNS responses, supports the EDNS0
-      [RFC2671] message size extension and the DO bit [RFC3225], and
-      supports the RR types and message header bits defined in this
-      document set.
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 5]
-
-
-   Security-Aware Recursive Name Server: An entity which acts in both
-      the security-aware name server and security-aware resolver roles.
-      A more cumbersome equivalent phrase would be "a security-aware
-      name server which offers recursive service".
-
-   Security-Aware Resolver: An entity acting in the role of a resolver
-      (defined in section 2.4 of [RFC1034]) which understands the DNS
-      security extensions defined in this document set.  In particular,
-      a security-aware resolver is an entity which sends DNS queries,
-      receives DNS responses, supports the EDNS0 [RFC2671] message size
-      extension and the DO bit [RFC3225], and is capable of using the RR
-      types and message header bits defined in this document set to
-      provide DNSSEC services.
-
-   Security-Aware Stub Resolver: An entity acting in the role of a stub
-      resolver (defined in section 5.3.1 of [RFC1034]) which has enough
-      of an understanding the DNS security extensions defined in this
-      document set to provide additional services not available from a
-      security-oblivious stub resolver.  Security-aware stub resolvers
-      may be either "validating" or "non-validating" depending on
-      whether the stub resolver attempts to verify DNSSEC signatures on
-      its own or trusts a friendly security-aware name server to do so.
-      See also: validating stub resolver, non-validating stub resolver.
-
-   Security-Oblivious <anything>: An <anything> that is not
-      "security-aware".
-
-   Signed Zone: A zone whose RRsets are signed and which contains
-      properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
-      records.
-
-   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
-      validating security-aware resolver uses this public key or hash as
-      a starting point for building the authentication chain to a signed
-      DNS response.  In general, a validating resolver will need to
-      obtain the initial values of its trust anchors via some secure or
-      trusted means outside the DNS protocol.  Presence of a trust
-      anchor also implies that the resolver should expect the zone to
-      which the trust anchor points to be signed.
-
-   Unsigned Zone: A zone that is not signed.
-
-   Validating Security-Aware Stub Resolver: A security-aware resolver
-      that sends queries in recursive mode but which performs signature
-      validation on its own rather than just blindly trusting an
-      upstream security-aware recursive name server.  See also:
-      security-aware stub resolver, non-validating security-aware stub
-      resolver.
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 6]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-   Validating Stub Resolver: A less tedious term for a validating
-      security-aware stub resolver.
-
-   Zone Signing Key (ZSK): An authentication key that corresponds to a
-      private key used to sign a zone.  Typically a zone signing key
-      will be part of the same DNSKEY RRset as the key signing key whose
-      corresponding private key signs this DNSKEY RRset, but the zone
-      signing key is used for a slightly different purpose, and may
-      differ from the key signing key in other ways, such as validity
-      lifetime.  Designating an authentication key as a zone signing key
-      is purely an operational issue: DNSSEC validation does not
-      distinguish between zone signing keys and other DNSSEC
-      authentication keys, and it is possible to use a single key as
-      both a key signing key and a zone signing key.  See also: key
-      signing key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 7]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-3.  Services Provided by DNS Security
-
-   The Domain Name System (DNS) security extensions provide origin
-   authentication and integrity assurance services for DNS data,
-   including mechanisms for authenticated denial of existence of DNS
-   data.  These mechanisms are described below.
-
-   These mechanisms require changes to the DNS protocol.  DNSSEC adds
-   four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
-   new message header bits (CD and AD).  In order to support the larger
-   DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
-   requires EDNS0 support [RFC2671].  Finally, DNSSEC requires support
-   for the DO bit [RFC3225], so that a security-aware resolver can
-   indicate in its queries that it wishes to receive DNSSEC RRs in
-   response messages.
-
-   These services protect against most of the threats to the Domain Name
-   System described in [I-D.ietf-dnsext-dns-threats].
-
-3.1  Data Origin Authentication and Data Integrity
-
-   DNSSEC provides authentication by associating cryptographically
-   generated digital signatures with DNS RRsets.  These digital
-   signatures are stored in a new resource record, the RRSIG record.
-   Typically, there will be a single private key that signs a zone's
-   data, but multiple keys are possible: for example, there may be keys
-   for each of several different digital signature algorithms.  If a
-   security-aware resolver reliably learns a zone's public key, it can
-   authenticate that zone's signed data.  An important DNSSEC concept is
-   that the key that signs a zone's data is associated with the zone
-   itself and not with the zone's authoritative name servers (public
-   keys for DNS transaction authentication mechanisms may also appear in
-   zones, as described in [RFC2931], but DNSSEC itself is concerned with
-   object security of DNS data, not channel security of DNS
-   transactions.  The keys associated with transaction security may be
-   stored in different RR types.  See [RFC3755] for details.).
-
-   A security-aware resolver can learn a zone's public key either by
-   having a trust anchor configured into the resolver or by normal DNS
-   resolution.  To allow the latter, public keys are stored in a new
-   type of resource record, the DNSKEY RR.  Note that the private keys
-   used to sign zone data must be kept secure, and should be stored
-   offline when practical to do so.  To discover a public key reliably
-   via DNS resolution, the target key itself needs to be signed by
-   either a configured authentication key or another key that has been
-   authenticated previously.  Security-aware resolvers authenticate zone
-   information by forming an authentication chain from a newly learned
-   public key back to a previously known authentication public key,
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 8]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-   which in turn either has been configured into the resolver or must
-   have been learned and verified previously.  Therefore, the resolver
-   must be configured with at least one trust anchor.  If the configured
-   key is a zone signing key, then it will authenticate the associated
-   zone; if the configured key is a key signing key, it will
-   authenticate a zone signing key.  If the resolver has been configured
-   with the hash of a key rather than the key itself, the resolver may
-   need to obtain the key via a DNS query.  To help security-aware
-   resolvers establish this authentication chain, security-aware name
-   servers attempt to send the signature(s) needed to authenticate a
-   zone's public key(s) in the DNS reply message along with the public
-   key itself, provided there is space available in the message.
-
-   The Delegation Signer (DS) RR type simplifies some of the
-   administrative tasks involved in signing delegations across
-   organizational boundaries.  The DS RRset resides at a delegation
-   point in a parent zone and indicates the public key(s) corresponding
-   to the private key(s) used to self-sign the DNSKEY RRset at the
-   delegated child zone's apex.  The administrator of the child zone, in
-   turn, uses the private key(s) corresponding to one or more of the
-   public keys in this DNSKEY RRset to sign the child zone's data.  The
-   typical authentication chain is therefore
-   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
-   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
-   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
-   RRs within a zone.
-
-   A security-aware resolver normally constructs this authentication
-   chain from the root of the DNS hierarchy down to the leaf zones based
-   on configured knowledge of the public key for the root.  Local
-   policy, however, may also allow a security-aware resolver to use one
-   or more configured public keys (or hashes of public keys) other than
-   the root public key, or may not provide configured knowledge of the
-   root public key, or may prevent the resolver from using particular
-   public keys for arbitrary reasons even if those public keys are
-   properly signed with verifiable signatures.  DNSSEC provides
-   mechanisms by which a security-aware resolver can determine whether
-   an RRset's signature is "valid" within the meaning of DNSSEC.  In the
-   final analysis however, authenticating both DNS keys and data is a
-   matter of local policy, which may extend or even override the
-   protocol extensions defined in this document set.  See Section 5 for
-   further discussion.
-
-3.2  Authenticating Name and Type Non-Existence
-
-   The security mechanism described in Section 3.1 only provides a way
-   to sign existing RRsets in a zone.  The problem of providing negative
-   responses with the same level of authentication and integrity
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 9]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-   requires the use of another new resource record type, the NSEC
-   record.  The NSEC record allows a security-aware resolver to
-   authenticate a negative reply for either name or type non-existence
-   via the same mechanisms used to authenticate other DNS replies.  Use
-   of NSEC records requires a canonical representation and ordering for
-   domain names in zones.  Chains of NSEC records explicitly describe
-   the gaps, or "empty space", between domain names in a zone, as well
-   as listing the types of RRsets present at existing names.  Each NSEC
-   record is signed and authenticated using the mechanisms described in
-   Section 3.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 10]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-4.  Services Not Provided by DNS Security
-
-   DNS was originally designed with the assumptions that the DNS will
-   return the same answer to any given query regardless of who may have
-   issued the query, and that all data in the DNS is thus visible.
-   Accordingly, DNSSEC is not designed to provide confidentiality,
-   access control lists, or other means of differentiating between
-   inquirers.
-
-   DNSSEC provides no protection against denial of service attacks.
-   Security-aware resolvers and security-aware name servers are
-   vulnerable to an additional class of denial of service attacks based
-   on cryptographic operations.  Please see Section 12 for details.
-
-   The DNS security extensions provide data and origin authentication
-   for DNS data.  The mechanisms outlined above are not designed to
-   protect operations such as zone transfers and dynamic update
-   [RFC3007].  Message authentication schemes described in [RFC2845] and
-   [RFC2931] address security operations that pertain to these
-   transactions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 11]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-5.  Scope of the DNSSEC Document Set and Last Hop Issues
-
-   The specification in this document set defines the behavior for zone
-   signers and security-aware name servers and resolvers in such a way
-   that the validating entities can unambiguously determine the state of
-   the data.
-
-   A validating resolver can determine these 4 states:
-
-   Secure: The validating resolver has a trust anchor, a chain of trust
-      and is able to verify all the signatures in the response.
-
-   Insecure: The validating resolver has a trust anchor, a chain of
-      trust, and, at some delegation point, signed proof of the
-      non-existence of a DS record.  That indicates that subsequent
-      branches in the tree are provably insecure.  A validating resolver
-      may have local policy to mark parts of the domain space as
-      insecure.
-
-   Bogus: The validating resolver has a trust anchor and there is a
-      secure delegation which is indicating that subsidiary data will be
-      signed, but the response fails to validate due to one or more
-      reasons: missing signatures, expired signatures, signatures with
-      unsupported algorithms, data missing which the relevant NSEC RR
-      says should be present, and so forth.
-
-   Indeterminate: There is no trust anchor which would indicate that a
-      specific portion of the tree is secure.  This is the default
-      operation mode.
-
-   This specification only defines how security aware name servers can
-   signal non-validating stub resolvers that data was found to be bogus
-   (using RCODE=2, "Server Failure" -- see
-   [I-D.ietf-dnsext-dnssec-protocol]).
-
-   There is a mechanism for security aware name servers to signal
-   security-aware stub resolvers that data was found to be secure (using
-   the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]).
-
-   This specification does not define a format for communicating why
-   responses were found to be bogus or marked as insecure.  The current
-   signaling mechanism does not distinguish between indeterminate and
-   insecure.
-
-   A method for signaling advanced error codes and policy between a
-   security aware stub resolver and security aware recursive nameservers
-   is a topic for future work, as is the interface between a security
-   aware resolver and the applications that use it.  Note, however, that
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 12]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-   the lack of the specification of such communication does not prohibit
-   deployment of signed zones or the deployment of security aware
-   recursive name servers that prohibit propagation of bogus data to the
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 13]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-6.  Resolver Considerations
-
-   A security-aware resolver needs to be able to perform cryptographic
-   functions necessary to verify digital signatures using at least the
-   mandatory-to-implement algorithm(s).  Security-aware resolvers must
-   also be capable of forming an authentication chain from a newly
-   learned zone back to an authentication key, as described above.  This
-   process might require additional queries to intermediate DNS zones to
-   obtain necessary DNSKEY, DS and RRSIG records.  A security-aware
-   resolver should be configured with at least one trust anchor as the
-   starting point from which it will attempt to establish authentication
-   chains.
-
-   If a security-aware resolver is separated from the relevant
-   authoritative name servers by a recursive name server or by any sort
-   of device which acts as a proxy for DNS, and if the recursive name
-   server or proxy is not security-aware, the security-aware resolver
-   may not be capable of operating in a secure mode.  For example, if a
-   security-aware resolver's packets are routed through a network
-   address translation device that includes a DNS proxy which is not
-   security-aware, the security-aware resolver may find it difficult or
-   impossible to obtain or validate signed DNS data.
-
-   If a security-aware resolver must rely on an unsigned zone or a name
-   server that is not security aware, the resolver may not be able to
-   validate DNS responses, and will need a local policy on whether to
-   accept unverified responses.
-
-   A security-aware resolver should take a signature's validation period
-   into consideration when determining the TTL of data in its cache, to
-   avoid caching signed data beyond the validity period of the
-   signature, but should also allow for the possibility that the
-   security-aware resolver's own clock is wrong.  Thus, a security-aware
-   resolver which is part of a security-aware recursive name server will
-   need to pay careful attention to the DNSSEC "checking disabled" (CD)
-   bit [I-D.ietf-dnsext-dnssec-records].  This is in order to avoid
-   blocking valid signatures from getting through to other
-   security-aware resolvers which are clients of this recursive name
-   server.  See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
-   recursive server handles queries with the CD bit set.
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 14]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-7.  Stub Resolver Considerations
-
-   Although not strictly required to do so by the protocol, most DNS
-   queries originate from stub resolvers.  Stub resolvers, by
-   definition, are minimal DNS resolvers which use recursive query mode
-   to offload most of the work of DNS resolution to a recursive name
-   server.  Given the widespread use of stub resolvers, the DNSSEC
-   architecture has to take stub resolvers into account, but the
-   security features needed in a stub resolver differ in some respects
-   from those needed in a full security-aware resolver.
-
-   Even a security-oblivious stub resolver may get some benefit from
-   DNSSEC if the recursive name servers it uses are security-aware, but
-   for the stub resolver to place any real reliance on DNSSEC services,
-   the stub resolver must trust both the recursive name servers in
-   question and the communication channels between itself and those name
-   servers.  The first of these issues is a local policy issue: in
-   essence, a security-oblivious stub resolver has no real choice but to
-   place itself at the mercy of the recursive name servers that it uses,
-   since it does not perform DNSSEC validity checks on its own.  The
-   second issue requires some kind of channel security mechanism; proper
-   use of DNS transaction authentication mechanisms such as SIG(0) or
-   TSIG would suffice, as would appropriate use of IPsec, and particular
-   implementations may have other choices available, such as operating
-   system specific interprocess communication mechanisms.
-   Confidentiality is not needed for this channel, but data integrity
-   and message authentication are.
-
-   A security-aware stub resolver that does trust both its recursive
-   name servers and its communication channel to them may choose to
-   examine the setting of the AD bit in the message header of the
-   response messages it receives.  The stub resolver can use this flag
-   bit as a hint to find out whether the recursive name server was able
-   to validate signatures for all of the data in the Answer and
-   Authority sections of the response.
-
-   There is one more step that a security-aware stub resolver can take
-   if, for whatever reason, it is not able to establish a useful trust
-   relationship with the recursive name servers which it uses: it can
-   perform its own signature validation, by setting the Checking
-   Disabled (CD) bit in its query messages.  A validating stub resolver
-   is thus able to treat the DNSSEC signatures as a trust relationship
-   between the zone administrator and the stub resolver itself.
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 15]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-8.  Zone Considerations
-
-   There are several differences between signed and unsigned zones.  A
-   signed zone will contain additional security-related records (RRSIG,
-   DNSKEY, DS and NSEC records).  RRSIG and NSEC records may be
-   generated by a signing process prior to serving the zone.  The RRSIG
-   records that accompany zone data have defined inception and
-   expiration times, which establish a validity period for the
-   signatures and the zone data the signatures cover.
-
-8.1  TTL values vs. RRSIG validity period
-
-   It is important to note the distinction between a RRset's TTL value
-   and the signature validity period specified by the RRSIG RR covering
-   that RRset.  DNSSEC does not change the definition or function of the
-   TTL value, which is intended to maintain database coherency in
-   caches.  A caching resolver purges RRsets from its cache no later
-   than the end of the time period specified by the TTL fields of those
-   RRsets, regardless of whether or not the resolver is security-aware.
-
-   The inception and expiration fields in the RRSIG RR
-   [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time
-   period during which the signature can be used to validate the covered
-   RRset.  The signatures associated with signed zone data are only
-   valid for the time period specified by these fields in the RRSIG RRs
-   in question.  TTL values cannot extend the validity period of signed
-   RRsets in a resolver's cache, but the resolver may use the time
-   remaining before expiration of the signature validity period of a
-   signed RRset as an upper bound for the TTL of the signed RRset and
-   its associated RRSIG RR in the resolver's cache.
-
-8.2  New Temporal Dependency Issues for Zones
-
-   Information in a signed zone has a temporal dependency which did not
-   exist in the original DNS protocol.  A signed zone requires regular
-   maintenance to ensure that each RRset in the zone has a current valid
-   RRSIG RR.  The signature validity period of an RRSIG RR is an
-   interval during which the signature for one particular signed RRset
-   can be considered valid, and the signatures of different RRsets in a
-   zone may expire at different times.  Re-signing one or more RRsets in
-   a zone will change one or more RRSIG RRs, which in turn will require
-   incrementing the zone's SOA serial number to indicate that a zone
-   change has occurred and re-signing the SOA RRset itself.  Thus,
-   re-signing any RRset in a zone may also trigger DNS NOTIFY messages
-   and zone transfers operations.
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 16]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-9.  Name Server Considerations
-
-   A security-aware name server should include the appropriate DNSSEC
-   records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
-   resolvers which have signaled their willingness to receive such
-   records via use of the DO bit in the EDNS header, subject to message
-   size limitations.  Since inclusion of these DNSSEC RRs could easily
-   cause UDP message truncation and fallback to TCP, a security-aware
-   name server must also support the EDNS "sender's UDP payload"
-   mechanism.
-
-   If possible, the private half of each DNSSEC key pair should be kept
-   offline, but this will not be possible for a zone for which DNS
-   dynamic update has been enabled.  In the dynamic update case, the
-   primary master server for the zone will have to re-sign the zone when
-   updated, so the private key corresponding to the zone signing key
-   will have to be kept online.  This is an example of a situation where
-   the ability to separate the zone's DNSKEY RRset into zone signing
-   key(s) and key signing key(s) may be useful, since the key signing
-   key(s) in such a case can still be kept offline and may have a longer
-   useful lifetime than the zone signing key(s).
-
-   DNSSEC, by itself, is not enough to protect the integrity of an
-   entire zone during zone transfer operations, since even a signed zone
-   contains some unsigned, nonauthoritative data if the zone has any
-   children.  Therefore, zone maintenance operations will require some
-   additional mechanisms (most likely some form of channel security,
-   such as TSIG, SIG(0), or IPsec).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 17]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-10.  DNS Security Document Family
-
-   The DNSSEC document set can be partitioned into several main groups,
-   under the larger umbrella of the DNS base protocol documents.
-
-   The "DNSSEC protocol document set" refers to the three documents
-   which form the core of the DNS security extensions:
-   1.  DNS Security Introduction and Requirements (this document)
-   2.  Resource Records for DNS Security Extensions
-       [I-D.ietf-dnsext-dnssec-records]
-   3.  Protocol Modifications for the DNS Security Extensions
-       [I-D.ietf-dnsext-dnssec-protocol]
-
-   Additionally, any document that would add to, or change the core DNS
-   Security extensions would fall into this category.  This includes any
-   future work on the communication between security-aware stub
-   resolvers and upstream security-aware recursive name servers.
-
-   The "Digital Signature Algorithm Specification" document set refers
-   to the group of documents that describe how specific digital
-   signature algorithms should be implemented to fit the DNSSEC resource
-   record format.  Each document in this set deals with a specific
-   digital signature algorithm.
-
-   The "Transaction Authentication Protocol" document set refers to the
-   group of documents that deal with DNS message authentication,
-   including secret key establishment and verification.  While not
-   strictly part of the DNSSEC specification as defined in this set of
-   documents, this group is noted because of its relationship to DNSSEC.
-
-   The final document set, "New Security Uses", refers to documents that
-   seek to use proposed DNS Security extensions for other security
-   related purposes.  DNSSEC does not provide any direct security for
-   these new uses, but may be used to support them.  Documents that fall
-   in this category include the use of DNS in the storage and
-   distribution of certificates [RFC2538].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 18]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-11.  IANA Considerations
-
-   This overview document introduces no new IANA considerations.  Please
-   see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
-   IANA considerations introduced by DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 19]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-12.  Security Considerations
-
-   This document introduces the DNS security extensions and describes
-   the document set that contains the new security records and DNS
-   protocol modifications.  The extensions provide data origin
-   authentication and data integrity using digital signatures over
-   resource record sets.This document discusses the capabilities and
-   limitations of these extensions.
-
-   In order for a security-aware resolver to validate a DNS response,
-   all zones along the path from the trusted starting point to the zone
-   containing the response zones must be signed, and all name servers
-   and resolvers involved in the resolution process must be
-   security-aware, as defined in this document set.  A security-aware
-   resolver cannot verify responses originating from an unsigned zone,
-   from a zone not served by a security-aware name server, or for any
-   DNS data which the resolver is only able to obtain through a
-   recursive name server which is not security-aware.  If there is a
-   break in the authentication chain such that a security-aware resolver
-   cannot obtain and validate the authentication keys it needs, then the
-   security-aware resolver cannot validate the affected DNS data.
-
-   This document briefly discusses other methods of adding security to a
-   DNS query, such as using a channel secured by IPsec or using a DNS
-   transaction authentication mechanism, but transaction security is not
-   part of DNSSEC per se.
-
-   A non-validating security-aware stub resolver, by definition, does
-   not perform DNSSEC signature validation on its own, and thus is
-   vulnerable both to attacks on (and by) the security-aware recursive
-   name servers which perform these checks on its behalf and also to
-   attacks on its communication with those security-aware recursive name
-   servers.  Non-validating security-aware stub resolvers should use
-   some form of channel security to defend against the latter threat.
-   The only known defense against the former threat would be for the
-   security-aware stub resolver to perform its own signature validation,
-   at which point, again by definition, it would no longer be a
-   non-validating security-aware stub resolver.
-
-   DNSSEC does not protect against denial of service attacks.  DNSSEC
-   makes DNS vulnerable to a new class of denial of service attacks
-   based on cryptographic operations against security-aware resolvers
-   and security-aware name servers, since an attacker can attempt to use
-   DNSSEC mechanisms to consume a victim's resources.  This class of
-   attacks takes at least two forms.  An attacker may be able to consume
-   resources in a security-aware resolver's signature validation code by
-   tampering with RRSIG RRs in response messages or by constructing
-   needlessly complex signature chains.  An attacker may also be able to
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 20]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-   consume resources in a security-aware name server which supports DNS
-   dynamic update, by sending a stream of update messages that force the
-   security-aware name server to re-sign some RRsets in the zone more
-   frequently than would otherwise be necessary.
-
-   DNSSEC does not provide confidentiality, due to a deliberate design
-   choice.
-
-   DNSSEC introduces the ability for a hostile party to enumerate all
-   the names in a zone by following the NSEC chain.  NSEC RRs assert
-   which names do not exist in a zone by linking from existing name to
-   existing name along a canonical ordering of all the names within a
-   zone.  Thus, an attacker can query these NSEC RRs in sequence to
-   obtain all the names in a zone.  While not an attack on the DNS
-   itself, this could allow an attacker to map network hosts or other
-   resources by enumerating the contents of a zone.
-
-   DNSSEC introduces significant additional complexity to the DNS, and
-   thus introduces many new opportunities for implementation bugs and
-   misconfigured zones.  In particular, enabling DNSSEC signature
-   validation in a resolver may cause entire legitimate zones to become
-   effectively unreachable due to DNSSEC configuration errors or bugs.
-
-   DNSSEC does not protect against tampering with unsigned zone data.
-   Non-authoritative data at zone cuts (glue and NS RRs in the parent
-   zone) are not signed.  This does not pose a problem when validating
-   the authentication chain, but does mean that the non-authoritative
-   data itself is vulnerable to tampering during zone transfer
-   operations.  Thus, while DNSSEC can provide data origin
-   authentication and data integrity for RRsets, it cannot do so for
-   zones, and other mechanisms must be used to protect zone transfer
-   operations.
-
-   Please see [I-D.ietf-dnsext-dnssec-records] and
-   [I-D.ietf-dnsext-dnssec-protocol] for additional security
-   considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 21]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-13.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group.  While explicitly listing everyone
-   who has contributed during the decade during which DNSSEC has been
-   under development would be an impossible task, the editors would
-   particularly like to thank the following people for their
-   contributions to and comments on this document set: Jaap Akkerhuis,
-   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
-   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
-   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
-   Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip
-   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
-   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
-   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
-   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
-   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
-   Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid,
-   Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob
-   Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and
-   Suzanne Woolf.
-
-   No doubt the above list is incomplete.  We apologize to anyone we
-   left out.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 22]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-14.  References
-
-14.1  Normative References
-
-   [I-D.ietf-dnsext-dnssec-protocol]
-              Arends, R., Austein, R., Larson, M., Massey, D. and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
-              progress), May 2004.
-
-   [I-D.ietf-dnsext-dnssec-records]
-              Arends, R., Austein, R., Larson, M., Massey, D. and S.
-              Rose, "Resource Records for DNS Security Extensions",
-              draft-ietf-dnsext-dnssec-records-08 (work in progress),
-              May 2004.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
-              Resource Record (RR)", RFC 3445, December 2002.
-
-14.2  Informative References
-
-   [I-D.ietf-dnsext-dns-threats]
-              Atkins, D. and R. Austein, "Threat Analysis Of The Domain
-              Name System", draft-ietf-dnsext-dns-threats-07 (work in
-              progress), April 2004.
-
-   [I-D.ietf-dnsext-nsec-rdata]
-              Schlyter, J., "DNSSEC NSEC RDATA Format",
-              draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
-              2004.
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 23]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
-              the Domain Name System (DNS)", RFC 2538, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
-              SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
-              Signing Authority", RFC 3008, November 2000.
-
-   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
-              Status", RFC 3090, March 2001.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-              Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer", RFC 3755, April 2004.
-
-   [RFC3757]  Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
-              Entry Point Flag", RFC 3757, April 2004.
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 24]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Drienerlolaan 5
-   7522 NB  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Dan Massey
-   USC Information Sciences Institute
-   3811 N. Fairfax Drive
-   Arlington, VA  22203
-   USA
-
-   EMail: masseyd@isi.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 25]
-
-Internet-Draft    DNSSEC Introduction and Requirements         July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 26]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
deleted file mode 100644
index 5728b35c9ba5..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
+++ /dev/null
@@ -1,3193 +0,0 @@
-
-
-DNS Extensions                                                 R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: January 13, 2005                                      M. Larson
-                                                                VeriSign
-                                                              R. Austein
-                                                                     ISC
-                                                               D. Massey
-                                                                 USC/ISI
-                                                                 S. Rose
-                                                                    NIST
-                                                           July 15, 2004
-
-
-         Protocol Modifications for the DNS Security Extensions
-                  draft-ietf-dnsext-dnssec-protocol-07
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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.
-
-   This Internet-Draft will expire on January 13, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document is part of a family of documents which describe the DNS
-   Security Extensions (DNSSEC).  The DNS Security Extensions are a
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 1]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   collection of new resource records and protocol modifications which
-   add data origin authentication and data integrity to the DNS.  This
-   document describes the DNSSEC protocol modifications.  This document
-   defines the concept of a signed zone, along with the requirements for
-   serving and resolving using DNSSEC.  These techniques allow a
-   security-aware resolver to authenticate both DNS resource records and
-   authoritative DNS error indications.
-
-   This document obsoletes RFC 2535 and incorporates changes from all
-   updates to RFC 2535.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1   Background and Related Documents . . . . . . . . . . . . .  4
-     1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     2.1   Including DNSKEY RRs in a Zone . . . . . . . . . . . . . .  5
-     2.2   Including RRSIG RRs in a Zone  . . . . . . . . . . . . . .  5
-     2.3   Including NSEC RRs in a Zone . . . . . . . . . . . . . . .  6
-     2.4   Including DS RRs in a Zone . . . . . . . . . . . . . . . .  7
-     2.5   Changes to the CNAME Resource Record.  . . . . . . . . . .  7
-     2.6   DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . . .  8
-     2.7   Example of a Secure Zone . . . . . . . . . . . . . . . . .  8
-   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     3.1   Authoritative Name Servers . . . . . . . . . . . . . . . . 10
-       3.1.1   Including RRSIG RRs in a Response  . . . . . . . . . . 10
-       3.1.2   Including DNSKEY RRs In a Response . . . . . . . . . . 11
-       3.1.3   Including NSEC RRs In a Response . . . . . . . . . . . 11
-       3.1.4   Including DS RRs In a Response . . . . . . . . . . . . 14
-       3.1.5   Responding to Queries for Type AXFR or IXFR  . . . . . 15
-       3.1.6   The AD and CD Bits in an Authoritative Response  . . . 16
-     3.2   Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
-       3.2.1   The DO bit . . . . . . . . . . . . . . . . . . . . . . 17
-       3.2.2   The CD bit . . . . . . . . . . . . . . . . . . . . . . 17
-       3.2.3   The AD bit . . . . . . . . . . . . . . . . . . . . . . 18
-     3.3   Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18
-   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
-     4.1   EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19
-     4.2   Signature Verification Support . . . . . . . . . . . . . . 19
-     4.3   Determining Security Status of Data  . . . . . . . . . . . 20
-     4.4   Configured Trust Anchors . . . . . . . . . . . . . . . . . 20
-     4.5   Response Caching . . . . . . . . . . . . . . . . . . . . . 21
-     4.6   Handling of the CD and AD bits . . . . . . . . . . . . . . 22
-     4.7   Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22
-     4.8   Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23
-     4.9   Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23
-       4.9.1   Handling of the DO Bit . . . . . . . . . . . . . . . . 23
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 2]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-       4.9.2   Handling of the CD Bit . . . . . . . . . . . . . . . . 23
-       4.9.3   Handling of the AD Bit . . . . . . . . . . . . . . . . 24
-   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
-     5.1   Special Considerations for Islands of Security . . . . . . 26
-     5.2   Authenticating Referrals . . . . . . . . . . . . . . . . . 26
-     5.3   Authenticating an RRset Using an RRSIG RR  . . . . . . . . 27
-       5.3.1   Checking the RRSIG RR Validity . . . . . . . . . . . . 28
-       5.3.2   Reconstructing the Signed Data . . . . . . . . . . . . 28
-       5.3.3   Checking the Signature . . . . . . . . . . . . . . . . 30
-       5.3.4   Authenticating A Wildcard Expanded RRset Positive
-               Response . . . . . . . . . . . . . . . . . . . . . . . 31
-     5.4   Authenticated Denial of Existence  . . . . . . . . . . . . 31
-     5.5   Resolver Behavior When Signatures Do Not Validate  . . . . 32
-     5.6   Authentication Example . . . . . . . . . . . . . . . . . . 32
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
-   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 36
-   9.2   Informative References . . . . . . . . . . . . . . . . . . . 36
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
-   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 39
-   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 45
-     B.1   Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45
-     B.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46
-     B.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . 47
-     B.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . 48
-     B.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . 49
-     B.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50
-     B.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51
-     B.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . 52
-   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 54
-     C.1   Authenticating An Answer . . . . . . . . . . . . . . . . . 54
-       C.1.1   Authenticating the example DNSKEY RR . . . . . . . . . 54
-     C.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55
-     C.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . 55
-     C.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . 55
-     C.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . 55
-     C.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56
-     C.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56
-     C.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . 56
-       Intellectual Property and Copyright Statements . . . . . . . . 57
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 3]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-1.  Introduction
-
-   The DNS Security Extensions (DNSSEC) are a collection of new resource
-   records and protocol modifications which add data origin
-   authentication and data integrity to the DNS.  This document defines
-   the DNSSEC protocol modifications.  Section 2 of this document
-   defines the concept of a signed zone and lists the requirements for
-   zone signing.  Section 3 describes the modifications to authoritative
-   name server behavior necessary to handle signed zones.  Section 4
-   describes the behavior of entities which include security-aware
-   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
-   to authenticate a response.
-
-1.1  Background and Related Documents
-
-   The reader is assumed to be familiar with the basic DNS concepts
-   described in [RFC1034] and [RFC1035].
-
-   This document is part of a family of documents that define DNSSEC.
-   An introduction to DNSSEC and definition of common terms can be found
-   in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be
-   familiar with this document.  A definition of the DNSSEC resource
-   records can be found in [I-D.ietf-dnsext-dnssec-records].
-
-1.2  Reserved Words
-
-   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.  [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 4]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-2.  Zone Signing
-
-   DNSSEC introduces the concept of signed zones.  A signed zone
-   includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
-   the rules specified in Section 2.1, Section 2.2, Section 2.3 and
-   Section 2.4, respectively.  A zone that does not include these
-   records according to the rules in this section is an unsigned zone.
-
-   DNSSEC requires a change to the definition of the CNAME resource
-   record [RFC1035].  Section 2.5 changes the CNAME RR to allow RRSIG
-   and NSEC RRs to appear at the same owner name as a CNAME RR.
-
-   DNSSEC specifies the placement of two new RR types, NSEC and DS,
-   which can be placed at the parental side of a zone cut (that is, at a
-   delegation point).  This is an exception to the general prohibition
-   against putting data in the parent zone at a zone cut.  Section 2.6
-   describes this change.
-
-2.1  Including DNSKEY RRs in a Zone
-
-   To sign a zone, the zone's administrator generates one or more
-   public/private key pairs and uses the private key(s) to sign
-   authoritative RRsets in the zone.  For each private key used to
-   create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
-   containing the corresponding public key.  A zone key DNSKEY RR MUST
-   have the Zone Key bit of the flags RDATA field set -- see Section
-   2.1.1 of [I-D.ietf-dnsext-dnssec-records].  Public keys associated
-   with other DNS operations MAY be stored in DNSKEY RRs that are not
-   marked as zone keys but MUST NOT be used to verify RRSIGs.
-
-   If the zone administrator intends a signed zone to be usable other
-   than as an island of security, the zone apex MUST contain at least
-   one DNSKEY RR to act as a secure entry point into the zone.  This
-   secure entry point could then be used as the target of a secure
-   delegation via a corresponding DS RR in the parent zone (see
-   [I-D.ietf-dnsext-dnssec-records]).
-
-2.2  Including RRSIG RRs in a Zone
-
-   For each authoritative RRset in a signed zone, there MUST be at least
-   one RRSIG record that meets all of the following requirements:
-   o  The RRSIG owner name is equal to the RRset owner name;
-   o  The RRSIG class is equal to the RRset class;
-   o  The RRSIG Type Covered field is equal to the RRset type;
-   o  The RRSIG Original TTL field is equal to the TTL of the RRset;
-   o  The RRSIG RR's TTL is equal to the TTL of the RRset;
-   o  The RRSIG Labels field is equal to the number of labels in the
-      RRset owner name, not counting the null root label and not
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 5]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-      counting the leftmost label if it is a wildcard;
-   o  The RRSIG Signer's Name field is equal to the name of the zone
-      containing the RRset; and
-   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
-      zone key DNSKEY record at the zone apex.
-
-   The process for constructing the RRSIG RR for a given RRset is
-   described in [I-D.ietf-dnsext-dnssec-records].  An RRset MAY have
-   multiple RRSIG RRs associated with it.
-
-   An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
-   would add no value and would create an infinite loop in the signing
-   process.
-
-   The NS RRset that appears at the zone apex name MUST be signed, but
-   the NS RRsets that appear at delegation points (that is, the NS
-   RRsets in the parent zone that delegate the name to the child zone's
-   name servers) MUST NOT be signed.  Glue address RRsets associated
-   with delegations MUST NOT be signed.
-
-   There MUST be an RRSIG for each RRset using at least one DNSKEY of
-   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
-   itself MUST be signed by each algorithm appearing in the DS RRset
-   located at the delegating parent (if any).
-
-2.3  Including NSEC RRs in a Zone
-
-   Each owner name in the zone which has authoritative data or a
-   delegation point NS RRset MUST have an NSEC resource record.  The
-   format of NSEC RRs and the process for constructing the NSEC RR for a
-   given name is described in [I-D.ietf-dnsext-dnssec-records].
-
-   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
-   value field in the zone SOA RR.
-
-   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
-   RRset at any particular owner name.  That is, the signing process
-   MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
-   not the owner name of any RRset before the zone was signed.  The main
-   reasons for this are a desire for namespace consistency between
-   signed and unsigned versions of the same zone and a desire to reduce
-   the risk of response inconsistency in security oblivious recursive
-   name servers.
-
-   The type bitmap of every NSEC resource record in a signed zone MUST
-   indicate the presence of both the NSEC record itself and its
-   corresponding RRSIG record.
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 6]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   The difference between the set of owner names that require RRSIG
-   records and the set of owner names that require NSEC records is
-   subtle and worth highlighting.  RRSIG records are present at the
-   owner names of all authoritative RRsets.  NSEC records are present at
-   the owner names of all names for which the signed zone is
-   authoritative and also at the owner names of delegations from the
-   signed zone to its children.  Neither NSEC nor RRSIG records are
-   present (in the parent zone) at the owner names of glue address
-   RRsets.  Note, however, that this distinction is for the most part is
-   only visible during the zone signing process, because NSEC RRsets are
-   authoritative data, and are therefore signed, thus any owner name
-   which has an NSEC RRset will have RRSIG RRs as well in the signed
-   zone.
-
-   The bitmap for the NSEC RR at a delegation point requires special
-   attention.  Bits corresponding to the delegation NS RRset and any
-   RRsets for which the parent zone has authoritative data MUST be set;
-   bits corresponding to any non-NS RRset for which the parent is not
-   authoritative MUST be clear.
-
-2.4  Including DS RRs in a Zone
-
-   The DS resource record establishes authentication chains between DNS
-   zones.  A DS RRset SHOULD be present at a delegation point when the
-   child zone is signed.  The DS RRset MAY contain multiple records,
-   each referencing a public key in the child zone used to verify the
-   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed and DS
-   RRsets MUST NOT appear at a zone's apex.
-
-   A DS RR SHOULD point to a DNSKEY RR which is present in the child's
-   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
-   by the corresponding private key.
-
-   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
-   (that is, the NS RRset from the same zone containing the DS RRset).
-
-   Construction of a DS RR requires knowledge of the corresponding
-   DNSKEY RR in the child zone, which implies communication between the
-   child and parent zones.  This communication is an operational matter
-   not covered by this document.
-
-2.5  Changes to the CNAME Resource Record.
-
-   If a CNAME RRset is present at a name in a signed zone, appropriate
-   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
-   name for secure dynamic update purposes is also allowed.  Other types
-   MUST NOT be present at that name.
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 7]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   This is a modification to the original CNAME definition given in
-   [RFC1034].  The original definition of the CNAME RR did not allow any
-   other types to coexist with a CNAME record, but a signed zone
-   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
-   this conflict, this specification modifies the definition of the
-   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
-
-2.6  DNSSEC RR Types Appearing at Zone Cuts.
-
-   DNSSEC introduced two new RR types that are unusual in that they can
-   appear at the parental side of a zone cut.  At the parental side of a
-   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
-   the owner name.  A DS RR could also be present if the zone being
-   delegated is signed and wishes to have a chain of authentication to
-   the parent zone.  This is an exception to the original DNS
-   specification ([RFC1034]) which states that only NS RRsets could
-   appear at the parental side of a zone cut.
-
-   This specification updates the original DNS specification to allow
-   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
-   are authoritative for the parent when they appear at the parent side
-   of a zone cut.
-
-2.7  Example of a Secure Zone
-
-   Appendix A shows a complete example of a small signed zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 8]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-3.  Serving
-
-   This section describes the behavior of entities that include
-   security-aware name server functions.  In many cases such functions
-   will be part of a security-aware recursive name server, but a
-   security-aware authoritative name server has some of the same
-   requirements.  Functions specific to security-aware recursive name
-   servers are described in Section 3.2; functions specific to
-   authoritative servers are described in Section 3.1.
-
-   The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
-   are as used in [RFC1034].
-
-   A security-aware name server MUST support the EDNS0 [RFC2671] message
-   size extension, MUST support a message size of at least 1220 octets,
-   and SHOULD support a message size of 4000 octets [RFC3226].
-
-   A security-aware name server which receives a DNS query that does not
-   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
-   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset,
-   and MUST NOT perform any of the additional processing described
-   below.  Since the DS RR type has the peculiar property of only
-   existing in the parent zone at delegation points, DS RRs always
-   require some special processing, as described in Section 3.1.4.1.
-
-   Security aware name servers that receive explicit queries for
-   security RR types which match the content of more than one zone that
-   it serves (for example, NSEC and RRSIG RRs above and below a
-   delegation point where the server is authoritative for both zones)
-   should behave self-consistently.  The name server MAY return one of
-   the following:
-   o  The above-delegation RRsets
-   o  The below-delegation RRsets
-   o  Both above and below-delegation RRsets
-   o  Empty answer section (no records)
-   o  Some other response
-   o  An error
-   As long as the response is always consistent for each query to the
-   name server.
-
-   DNSSEC allocates two new bits in the DNS message header: the CD
-   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
-   is controlled by resolvers; a security-aware name server MUST copy
-   the CD bit from a query into the corresponding response.  The AD bit
-   is controlled by name servers; a security-aware name server MUST
-   ignore the setting of the AD bit in queries.  See Section 3.1.6,
-   Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
-   on the behavior of these bits.
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 9]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   A security aware name server which synthesizes CNAME RRs from DNAME
-   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
-   synthesized CNAME RRs.
-
-3.1  Authoritative Name Servers
-
-   Upon receiving a relevant query that has the EDNS [RFC2671] OPT
-   pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name
-   server for a signed zone MUST include additional RRSIG, NSEC, and DS
-   RRs according to the following rules:
-   o  RRSIG RRs that can be used to authenticate a response MUST be
-      included in the response according to the rules in Section 3.1.1;
-   o  NSEC RRs that can be used to provide authenticated denial of
-      existence MUST be included in the response automatically according
-      to the rules in Section 3.1.3;
-   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
-      be included in referrals automatically according to the rules in
-      Section 3.1.4.
-
-   These rules only apply to responses the semantics of which convey
-   information about the presence or absence of resource records.  That
-   is, these rules are not intended to rule out responses such as RCODE
-   4 ("Not Implemented") or RCODE 5 ("Refused").
-
-   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
-   discusses zone transfer requirements.
-
-3.1.1  Including RRSIG RRs in a Response
-
-   When responding to a query that has the DO bit set, a security-aware
-   authoritative name server SHOULD attempt to send RRSIG RRs that a
-   security-aware resolver can use to authenticate the RRsets in the
-   response.  A name server SHOULD make every attempt to keep the RRset
-   and its associated RRSIG(s) together in a response.  Inclusion of
-   RRSIG RRs in a response is subject to the following rules:
-   o  When placing a signed RRset in the Answer section, the name server
-      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
-      RRs have a higher priority for inclusion than any other RRsets
-      that may need to be included.  If space does not permit inclusion
-      of these RRSIG RRs, the name server MUST set the TC bit.
-   o  When placing a signed RRset in the Authority section, the name
-      server MUST also place its RRSIG RRs in the Authority section.
-      The RRSIG RRs have a higher priority for inclusion than any other
-      RRsets that may need to be included.  If space does not permit
-      inclusion of these RRSIG RRs, the name server MUST set the TC bit.
-   o  When placing a signed RRset in the Additional section, the name
-      server MUST also place its RRSIG RRs in the Additional section.
-      If space does not permit inclusion of both the RRset and its
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 10]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-      associated RRSIG RRs, the name server MAY drop the RRSIG RRs.  If
-      this happens, the name server MUST NOT set the TC bit solely
-      because these RRSIG RRs didn't fit.
-
-3.1.2  Including DNSKEY RRs In a Response
-
-   When responding to a query that has the DO bit set and that requests
-   the SOA or NS RRs at the apex of a signed zone, a security-aware
-   authoritative name server for that zone MAY return the zone apex
-   DNSKEY RRset in the Additional section.  In this situation, the
-   DNSKEY RRset and associated RRSIG RRs have lower priority than any
-   other information that would be placed in the additional section.
-   The name server SHOULD NOT include the DNSKEY RRset unless there is
-   enough space in the response message for both the DNSKEY RRset and
-   its associated RRSIG RR(s).  If there is not enough space to include
-   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
-   NOT set the TC bit solely because these RRs didn't fit (see Section
-   3.1.1).
-
-3.1.3  Including NSEC RRs In a Response
-
-   When responding to a query that has the DO bit set, a security-aware
-   authoritative name server for a signed zone MUST include NSEC RRs in
-   each of the following cases:
-
-   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
-      but does not contain any RRsets that exactly match <SNAME, SCLASS,
-      STYPE>.
-
-   Name Error: The zone does not contain any RRsets that match <SNAME,
-      SCLASS> either exactly or via wildcard name expansion.
-
-   Wildcard Answer: The zone does not contain any RRsets that exactly
-      match <SNAME, SCLASS> but does contain an RRset that matches
-      <SNAME, SCLASS, STYPE> via wildcard name expansion.
-
-   Wildcard No Data: The zone does not contain any RRsets that exactly
-      match <SNAME, SCLASS>, does contain one or more RRsets that match
-      <SNAME, SCLASS> via wildcard name expansion, but does not contain
-      any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
-      expansion.
-
-   In each of these cases, the name server includes NSEC RRs in the
-   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
-   not present in the zone and that the response that the name server is
-   returning is correct given the data that are in the zone.
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 11]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-3.1.3.1  Including NSEC RRs: No Data Response
-
-   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
-   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
-   include the NSEC RR for <SNAME, SCLASS> along with its associated
-   RRSIG RR(s) in the Authority section of the response (see Section
-   3.1.1).  If space does not permit inclusion of the NSEC RR or its
-   associated RRSIG RR(s), the name server MUST set the TC bit (see
-   Section 3.1.1).
-
-   Since the search name exists, wildcard name expansion does not apply
-   to this query, and a single signed NSEC RR suffices to prove the
-   requested RR type does not exist.
-
-3.1.3.2  Including NSEC RRs: Name Error Response
-
-   If the zone does not contain any RRsets matching <SNAME, SCLASS>
-   either exactly or via wildcard name expansion, then the name server
-   MUST include the following NSEC RRs in the Authority section, along
-   with their associated RRSIG RRs:
-   o  An NSEC RR proving that there is no exact match for <SNAME,
-      SCLASS>; and
-   o  An NSEC RR proving that the zone contains no RRsets that would
-      match <SNAME, SCLASS> via wildcard name expansion.
-
-   In some cases a single NSEC RR may prove both of these points, in
-   that case the name server SHOULD only include the NSEC RR and its
-   RRSIG RR(s) once in the Authority section.
-
-   If space does not permit inclusion of these NSEC and RRSIG RRs, the
-   name server MUST set the TC bit (see Section 3.1.1).
-
-   The owner names of these NSEC and RRSIG RRs are not subject to
-   wildcard name expansion when these RRs are included in the Authority
-   section of the response.
-
-   Note that this form of response includes cases in which SNAME
-   corresponds to an empty non-terminal name within the zone (a name
-   which is not the owner name for any RRset but which is the parent
-   name of one or more RRsets).
-
-3.1.3.3  Including NSEC RRs: Wildcard Answer Response
-
-   If the zone does not contain any RRsets which exactly match <SNAME,
-   SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
-   STYPE> via wildcard name expansion, the name server MUST include the
-   wildcard-expanded answer and the corresponding wildcard-expanded
-   RRSIG RRs in the Answer section, and MUST include in the Authority
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 12]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   section an NSEC RR and associated RRSIG RR(s) proving that the zone
-   does not contain a closer match for <SNAME, SCLASS>.  If space does
-   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
-   server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.4  Including NSEC RRs: Wildcard No Data Response
-
-   This case is a combination of the previous cases.  The zone does not
-   contain an exact match for <SNAME, SCLASS>, and while the zone does
-   contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
-   none of those RRsets match STYPE.  The name server MUST include the
-   following NSEC RRs in the Authority section, along with their
-   associated RRSIG RRs:
-   o  An NSEC RR proving that there are no RRsets matching STYPE at the
-      wildcard owner name which matched <SNAME, SCLASS> via wildcard
-      expansion; and
-   o  An NSEC RR proving that there are no RRsets in the zone which
-      would have been a closer match for <SNAME, SCLASS>.
-
-   In some cases a single NSEC RR may prove both of these points, in
-   which case the name server SHOULD only include the NSEC RR and its
-   RRSIG RR(s) once in the Authority section.
-
-   The owner names of these NSEC and RRSIG RRs are not subject to
-   wildcard name expansion when these RRs are included in the Authority
-   section of the response.
-
-   If space does not permit inclusion of these NSEC and RRSIG RRs, the
-   name server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.5  Finding The Right NSEC RRs
-
-   As explained above, there are several situations in which a
-   security-aware authoritative name server needs to locate an NSEC RR
-   which proves that no RRsets matching a particular SNAME exist.
-   Locating such an NSEC RR within an authoritative zone is relatively
-   simple, at least in concept.  The following discussion assumes that
-   the name server is authoritative for the zone which would have held
-   the nonexistent RRsets matching SNAME.  The algorithm below is
-   written for clarity, not efficiency.
-
-   To find the NSEC which proves that no RRsets matching name N exist in
-   the zone Z which would have held them, construct sequence S
-   consisting of the owner names of every RRset in Z, sorted into
-   canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate
-   names.  Find the name M which would have immediately preceded N in S
-   if any RRsets with owner name N had existed.  M is the owner name of
-   the NSEC RR which proves that no RRsets exist with owner name N.
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 13]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   The algorithm for finding the NSEC RR which proves that a given name
-   is not covered by any applicable wildcard is similar, but requires an
-   extra step.  More precisely, the algorithm for finding the NSEC
-   proving that no RRsets exist with the applicable wildcard name is
-   precisely the same as the algorithm for finding the NSEC RR which
-   proves that RRsets with any other owner name do not exist: the part
-   that's missing is how to determine the name of the nonexistent
-   applicable wildcard.  In practice, this is easy, because the
-   authoritative name server has already checked for the presence of
-   precisely this wildcard name as part of step (1)(c) of the normal
-   lookup algorithm described in Section 4.3.2 of [RFC1034].
-
-3.1.4  Including DS RRs In a Response
-
-   When responding to a query which has the DO bit set, a security-aware
-   authoritative name server returning a referral includes DNSSEC data
-   along with the NS RRset.
-
-   If a DS RRset is present at the delegation point, the name server
-   MUST return both the DS RRset and its associated RRSIG RR(s) in the
-   Authority section along with the NS RRset.  The name server MUST
-   place the NS RRset before the DS RRset and its associated RRSIG
-   RR(s).
-
-   If no DS RRset is present at the delegation point, the name server
-   MUST return both the NSEC RR which proves that the DS RRset is not
-   present and the NSEC RR's associated RRSIG RR(s) along with the NS
-   RRset.  The name server MUST place the NS RRset before the NSEC RRset
-   and its associated RRSIG RR(s).
-
-   Including these DS, NSEC, and RRSIG RRs increases the size of
-   referral messages, and may cause some or all glue RRs to be omitted.
-   If space does not permit inclusion of the DS or NSEC RRset and
-   associated RRSIG RRs, the name server MUST set the TC bit (see
-   Section 3.1.1).
-
-3.1.4.1  Responding to Queries for DS RRs
-
-   The DS resource record type is unusual in that it appears only on the
-   parent zone's side of a zone cut.  For example, the DS RRset for the
-   delegation of "foo.example" is stored in the "example" zone rather
-   than in the "foo.example" zone.  This requires special processing
-   rules for both name servers and resolvers, since the name server for
-   the child zone is authoritative for the name at the zone cut by the
-   normal DNS rules but the child zone does not contain the DS RRset.
-
-   A security-aware resolver sends queries to the parent zone when
-   looking for a needed DS RR at a delegation point (see Section 4.2).
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 14]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   However, special rules are necessary to avoid confusing
-   security-oblivious resolvers which might become involved in
-   processing such a query (for example, in a network configuration that
-   forces a security-aware resolver to channel its queries through a
-   security-oblivious recursive name server).  The rest of this section
-   describes how a security-aware name server processes DS queries in
-   order to avoid this problem.
-
-   The need for special processing by a security-aware name server only
-   arises when all the following conditions are met:
-   o  the name server has received a query for the DS RRset at a zone
-      cut; and
-   o  the name server is authoritative for the child zone; and
-   o  the name server is not authoritative for the parent zone; and
-   o  the name server does not offer recursion.
-
-   In all other cases, the name server either has some way of obtaining
-   the DS RRset or could not have been expected to have the DS RRset
-   even by the pre-DNSSEC processing rules, so the name server can
-   return either the DS RRset or an error response according to the
-   normal processing rules.
-
-   If all of the above conditions are met, however, the name server is
-   authoritative for SNAME but cannot supply the requested RRset.  In
-   this case, the name server MUST return an authoritative "no data"
-   response showing that the DS RRset does not exist in the child zone's
-   apex.  See Appendix B.8 for an example of such a response.
-
-3.1.5  Responding to Queries for Type AXFR or IXFR
-
-   DNSSEC does not change the DNS zone transfer process.  A signed zone
-   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
-   records have no special meaning with respect to a zone transfer
-   operation.
-
-   An authoritative name server is not required to verify that a zone is
-   properly signed before sending or accepting a zone transfer.
-   However, an authoritative name server MAY choose to reject the entire
-   zone transfer if the zone fails meets any of the signing requirements
-   described in Section 2.  The primary objective of a zone transfer is
-   to ensure that all authoritative name servers have identical copies
-   of the zone.  An authoritative name server that chooses to perform
-   its own zone validation MUST NOT selectively reject some RRs and
-   accept others.
-
-   DS RRsets appear only on the parental side of a zone cut and are
-   authoritative data in the parent zone.  As with any other
-   authoritative RRset, the DS RRset MUST be included in zone transfers
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 15]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   of the zone in which the RRset is authoritative data: in the case of
-   the DS RRset, this is the parent zone.
-
-   NSEC RRs appear in both the parent and child zones at a zone cut, and
-   are authoritative data in both the parent and child zones.  The
-   parental and child NSEC RRs at a zone cut are never identical to each
-   other, since the NSEC RR in the child zone's apex will always
-   indicate the presence of the child zone's SOA RR while the parental
-   NSEC RR at the zone cut will never indicate the presence of an SOA
-   RR.  As with any other authoritative RRs, NSEC RRs MUST be included
-   in zone transfers of the zone in which they are authoritative data:
-   the parental NSEC RR at a zone cut MUST be included zone transfers of
-   the parent zone, while the NSEC at the zone apex of the child zone
-   MUST be included in zone transfers of the child zone.
-
-   RRSIG RRs appear in both the parent and child zones at a zone cut,
-   and are authoritative in whichever zone contains the authoritative
-   RRset for which the RRSIG RR provides the signature.  That is, the
-   RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
-   authoritative in the parent zone, while the RRSIG for any RRset in
-   the child zone's apex will be authoritative in the child zone.
-   Parental and child RRSIG RRs at a zone cut will never be identical to
-   each other, since the Signer's Name field of an RRSIG RR in the child
-   zone's apex will indicate a DNSKEY RR in the child zone's apex while
-   the same field of a parental RRSIG RR at the zone cut will indicate a
-   DNSKEY RR in the parent zone's apex.  As with any other authoritative
-   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
-   which they are authoritative data.
-
-3.1.6  The AD and CD Bits in an Authoritative Response
-
-   The CD and AD bits are designed for use in communication between
-   security-aware resolvers and security-aware recursive name servers.
-   These bits are for the most part not relevant to query processing by
-   security-aware authoritative name servers.
-
-   A security-aware name server does not perform signature validation
-   for authoritative data during query processing even when the CD bit
-   is clear.  A security-aware name server SHOULD clear the CD bit when
-   composing an authoritative response.
-
-   A security-aware name server MUST NOT set the AD bit in a response
-   unless the name server considers all RRsets in the Answer and
-   Authority sections of the response to be authentic.  A security-aware
-   name server's local policy MAY consider data from an authoritative
-   zone to be authentic without further validation, but the name server
-   MUST NOT do so unless the name server obtained the authoritative zone
-   via secure means (such as a secure zone transfer mechanism), and MUST
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 16]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   NOT do so unless this behavior has been configured explicitly.
-
-   A security-aware name server which supports recursion MUST follow the
-   rules for the CD and AD bits given in Section 3.2 when generating a
-   response that involves data obtained via recursion.
-
-3.2  Recursive Name Servers
-
-   As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
-   recursive name server is an entity which acts in both the
-   security-aware name server and security-aware resolver roles.  This
-   section uses the terms "name server side" and "resolver side" to
-   refer to the code within a security-aware recursive name server which
-   implements the security-aware name server role and the code which
-   implements the security-aware resolver role, respectively.
-
-   The resolver side follows the usual rules for caching and negative
-   caching which would apply to any security-aware resolver.
-
-3.2.1  The DO bit
-
-   The resolver side of a security-aware recursive name server MUST set
-   the DO bit when sending requests, regardless of the state of the DO
-   bit in the initiating request received by the name server side.  If
-   the DO bit in an initiating query is not set, the name server side
-   MUST strip any authenticating DNSSEC RRs from the response, but MUST
-   NOT strip any DNSSEC RR types that the initiating query explicitly
-   requested.
-
-3.2.2  The CD bit
-
-   The CD bit exists in order to allow a security-aware resolver to
-   disable signature validation in a security-aware name server's
-   processing of a particular query.
-
-   The name server side MUST copy the setting of the CD bit from a query
-   to the corresponding response.
-
-   The name server side of a security-aware recursive name server MUST
-   pass the sense of the CD bit to the resolver side along with the rest
-   of an initiating query, so that the resolver side will know whether
-   or not it is required to verify the response data it returns to the
-   name server side.  If the CD bit is set, it indicates that the
-   originating resolver is willing to perform whatever authentication
-   its local policy requires, thus the resolver side of the recursive
-   name server need not perform authentication on the RRsets in the
-   response.  When the CD bit is set the recursive name server SHOULD,
-   if possible, return the requested data to the originating resolver
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 17]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   even if the recursive name server's local authentication policy would
-   reject the records in question.  That is, by setting the CD bit, the
-   originating resolver has indicated that it takes responsibility for
-   performing its own authentication, and the recursive name server
-   should not interfere.
-
-   If the resolver side implements a BAD cache (see Section 4.7) and the
-   name server side receives a query which matches an entry in the
-   resolver side's BAD cache, the name server side's response depends on
-   the sense of the CD bit in the original query.  If the CD bit is set,
-   the name server side SHOULD return the data from the BAD cache; if
-   the CD bit is not set, the name server side MUST return RCODE 2
-   (server failure).
-
-   The intent of the above rule is to provide the raw data to clients
-   which are capable of performing their own signature verification
-   checks while protecting clients which depend on the resolver side of
-   a security-aware recursive name server to perform such checks.
-   Several of the possible reasons why signature validation might fail
-   involve conditions which may not apply equally to the recursive name
-   server and the client which invoked it: for example, the recursive
-   name server's clock may be set incorrectly, or the client may have
-   knowledge of a relevant island of security which the recursive name
-   server does not share.  In such cases, "protecting" a client which is
-   capable of performing its own signature validation from ever seeing
-   the "bad" data does not help the client.
-
-3.2.3  The AD bit
-
-   The name server side of a security-aware recursive name server MUST
-   NOT set the AD bit in a response unless the name server considers all
-   RRsets in the Answer and Authority sections of the response to be
-   authentic.  The name server side SHOULD set the AD bit if and only if
-   the resolver side considers all RRsets in the Answer section and any
-   relevant negative response RRs in the Authority section to be
-   authentic.  The resolver side MUST follow the procedure described in
-   Section 5 to determine whether the RRs in question are authentic.
-   However, for backwards compatibility, a recursive name server MAY set
-   the AD bit when a response includes unsigned CNAME RRs if those CNAME
-   RRs demonstrably could have been synthesized from an authentic DNAME
-   RR which is also included in the response according to the synthesis
-   rules described in [RFC2672].
-
-3.3  Example DNSSEC Responses
-
-   See Appendix B for example response packets.
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 18]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-4.  Resolving
-
-   This section describes the behavior of entities that include
-   security-aware resolver functions.  In many cases such functions will
-   be part of a security-aware recursive name server, but a stand-alone
-   security-aware resolver has many of the same requirements.  Functions
-   specific to security-aware recursive name servers are described in
-   Section 3.2.
-
-4.1  EDNS Support
-
-   A security-aware resolver MUST include an EDNS [RFC2671] OPT
-   pseudo-RR with the DO [RFC3225] bit set when sending queries.
-
-   A security-aware resolver MUST support a message size of at least
-   1220 octets, SHOULD support a message size of 4000 octets, and MUST
-   advertise the supported message size using the "sender's UDP payload
-   size" field in the EDNS OPT pseudo-RR.  A security-aware resolver
-   MUST handle fragmented UDP packets correctly regardless of whether
-   any such fragmented packets were received via IPv4 or IPv6.  Please
-   see [RFC3226] for discussion of these requirements.
-
-4.2  Signature Verification Support
-
-   A security-aware resolver MUST support the signature verification
-   mechanisms described in Section 5, and SHOULD apply them to every
-   received response except when:
-   o  The security-aware resolver is part of a security-aware recursive
-      name server, and the response is the result of recursion on behalf
-      of a query received with the CD bit set;
-   o  The response is the result of a query generated directly via some
-      form of application interface which instructed the security-aware
-      resolver not to perform validation for this query; or
-   o  Validation for this query has been disabled by local policy.
-
-   A security-aware resolver's support for signature verification MUST
-   include support for verification of wildcard owner names.
-
-   Security aware resolvers MAY query for missing security RRs in an
-   attempt to perform validation; implementations that choose to do so
-   must be aware that the answers received may not be sufficient to
-   validate the original response.
-
-   When attempting to retrieve missing NSEC RRs which reside on the
-   parental side at a zone cut, a security-aware iterative-mode resolver
-   MUST query the name servers for the parent zone, not the child zone.
-
-   When attempting to retrieve a missing DS, a security-aware
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 19]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   iterative-mode resolver MUST query the name servers for the parent
-   zone, not the child zone.  As explained in Section 3.1.4.1,
-   security-aware name servers need to apply special processing rules to
-   handle the DS RR, and in some situations the resolver may also need
-   to apply special rules to locate the name servers for the parent zone
-   if the resolver does not already have the parent's NS RRset.  To
-   locate the parent NS RRset, the resolver can start with the
-   delegation name, strip off the leftmost label, and query for an NS
-   RRset by that name; if no NS RRset is present at that name, the
-   resolver then strips of the leftmost remaining label and retries the
-   query for that name, repeating this process of walking up the tree
-   until it either finds the NS RRset or runs out of labels.
-
-4.3  Determining Security Status of Data
-
-   A security-aware resolver MUST be able to determine whether or not it
-   should expect a particular RRset to be signed.  More precisely, a
-   security-aware resolver must be able to distinguish between four
-   cases:
-
-   Secure: An RRset for which the resolver is able to build a chain of
-      signed DNSKEY and DS RRs from a trusted security anchor to the
-      RRset.  In this case, the RRset should be signed, and is subject
-      to signature validation as described above.
-
-   Insecure: An RRset for which the resolver knows that it has no chain
-      of signed DNSKEY and DS RRs from any trusted starting point to the
-      RRset.  This can occur when the target RRset lies in an unsigned
-      zone or in a descendent of an unsigned zone.  In this case, the
-      RRset may or may not be signed, but the resolver will not be able
-      to verify the signature.
-
-   Bogus: An RRset for which the resolver believes that it ought to be
-      able to establish a chain of trust but is unable to do so, either
-      due to signatures that for some reason fail to validate or due to
-      missing data which the relevant DNSSEC RRs indicate should be
-      present.  This case may indicate an attack, but may also indicate
-      a configuration error or some form of data corruption.
-
-   Indeterminate: An RRset for which the resolver is not able to
-      determine whether or not the RRset should be signed, because the
-      resolver is not able to obtain the necessary DNSSEC RRs.  This can
-      occur when the security-aware resolver is not able to contact
-      security-aware name servers for the relevant zones.
-
-4.4  Configured Trust Anchors
-
-   A security-aware resolver MUST be capable of being configured with at
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 20]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   least one trusted public key or DS RR, and SHOULD be capable of being
-   configured with multiple trusted public keys or DS RRs.  Since a
-   security-aware resolver will not be able to validate signatures
-   without such a configured trust anchor, the resolver SHOULD have some
-   reasonably robust mechanism for obtaining such keys when it boots;
-   examples of such a mechanism would be some form of non-volatile
-   storage (such as a disk drive) or some form of trusted local network
-   configuration mechanism.
-
-   Note that trust anchors also covers key material that is updated in a
-   secure manner.  This secure manner could be through physical media, a
-   key exchange protocol, or some other out of band means.
-
-4.5  Response Caching
-
-   A security-aware resolver SHOULD cache each response as a single
-   atomic entry containing the entire answer, including the named RRset
-   and any associated DNSSEC RRs.  The resolver SHOULD discard the
-   entire atomic entry when any of the RRs contained in it expire.  In
-   most cases the appropriate cache index for the atomic entry will be
-   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
-   form described in Section 3.1.3.2 the appropriate cache index will be
-   the double <QNAME,QCLASS>.
-
-   The reason for these recommendations is that, between the initial
-   query and the expiration of the data from the cache, the
-   authoritative data might have been changed (for example, via dynamic
-   update).
-
-   There are two situations for which this is relevant:
-   1.  By using the RRSIG record, it is possible to deduce that an
-       answer was synthesized from a wildcard.  A security aware
-       recursive name server could store this wildcard data and use it
-       to generate positive responses to queries other than the name for
-       which the original answer was first received.
-   2.  NSEC RRs received to prove the non-existence of a name could be
-       reused by a security aware resolver to prove the non-existence of
-       any name in the name range it spans.
-
-   In theory, a resolver could use wildcards or NSEC RRs to generate
-   positive and negative responses (respectively) until the TTL or
-   signatures on the records in question expire.  However, it seems
-   prudent for resolvers to avoid blocking new authoritative data or
-   synthesizing new data on their own.  Resolvers which follow this
-   recommendation will have a more consistent view of the namespace.
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 21]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-4.6  Handling of the CD and AD bits
-
-   A security-aware resolver MAY set a query's CD bit in order to
-   indicate that the resolver takes responsibility for performing
-   whatever authentication its local policy requires on the RRsets in
-   the response.  See Section 3.2 for the effect this bit has on the
-   behavior of security-aware recursive name servers.
-
-   A security-aware resolver MUST clear the AD bit when composing query
-   messages to protect against buggy name servers which blindly copy
-   header bits which they do not understand from the query message to
-   the response message.
-
-   A resolver MUST disregard the meaning of the CD and AD bits in a
-   response unless the response was obtained using a secure channel or
-   the resolver was specifically configured to regard the message header
-   bits without using a secure channel.
-
-4.7  Caching BAD Data
-
-   While many validation errors will be transient, some are likely to be
-   more persistent, such as those caused by administrative error
-   (failure to re-sign a zone, clock skew, and so forth).  Since
-   requerying will not help in these cases, validating resolvers might
-   generate a significant amount of unnecessary DNS traffic as a result
-   of repeated queries for RRsets with persistent validation failures.
-
-   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
-   cache data with invalid signatures, with some restrictions.
-   Conceptually, caching such data is similar to negative caching
-   [RFC2308], except that instead of caching a valid negative response,
-   the resolver is caching the fact that a particular answer failed to
-   validate.  This document refers to a cache of data with invalid
-   signatures as a "BAD cache".
-
-   Resolvers which implement a BAD cache MUST take steps to prevent the
-   cache from being useful as a denial-of-service attack amplifier.  In
-   particular:
-   o  Since RRsets which fail to validate do not have trustworthy TTLs,
-      the implementation MUST assign a TTL.  This TTL SHOULD be small,
-      in order to mitigate the effect of caching the results of an
-      attack.
-   o  In order to prevent caching of a transient validation failure
-      (which might be the result of an attack), resolvers SHOULD track
-      queries that result in validation failures, and SHOULD only answer
-      from the BAD cache after the number of times that responses to
-      queries for that particular <QNAME, QTYPE, QCLASS> have failed to
-      validate exceeds a threshold value.
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 22]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   Resolvers MUST NOT return RRsets from the BAD cache unless the
-   resolver is not required to validate the signatures of the RRsets in
-   question under the rules given in Section 4.2 of this document.  See
-   Section 3.2.2 for discussion of how the responses returned by a
-   security-aware recursive name server interact with a BAD cache.
-
-4.8  Synthesized CNAMEs
-
-   A validating security-aware resolver MUST treat the signature of a
-   valid signed DNAME RR as also covering unsigned CNAME RRs which could
-   have been synthesized from the DNAME RR as described in [RFC2672], at
-   least to the extent of not rejecting a response message solely
-   because it contains such CNAME RRs.  The resolver MAY retain such
-   CNAME RRs in its cache or in the answers it hands back, but is not
-   required to do so.
-
-4.9  Stub resolvers
-
-   A security-aware stub resolver MUST support the DNSSEC RR types, at
-   least to the extent of not mishandling responses just because they
-   contain DNSSEC RRs.
-
-4.9.1  Handling of the DO Bit
-
-   A non-validating security-aware stub resolver MAY include the DNSSEC
-   RRs returned by a security-aware recursive name server as part of the
-   data that the stub resolver hands back to the application which
-   invoked it but is not required to do so.  A non-validating stub
-   resolver that wishes to do this will need to set the DO bit in
-   receive DNSSEC RRs from the recursive name server.
-
-   A validating security-aware stub resolver MUST set the DO bit, since
-   otherwise it will not receive the DNSSEC RRs it needs to perform
-   signature validation.
-
-4.9.2  Handling of the CD Bit
-
-   A non-validating security-aware stub resolver SHOULD NOT set the CD
-   bit when sending queries unless requested by the application layer,
-   since by definition, a non-validating stub resolver depends on the
-   security-aware recursive name server to perform validation on its
-   behalf.
-
-   A validating security-aware stub resolver SHOULD set the CD bit,
-   since otherwise the security-aware recursive name server will answer
-   the query using the name server's local policy, which may prevent the
-   stub resolver from receiving data which would be acceptable to the
-   stub resolver's local policy.
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 23]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-4.9.3  Handling of the AD Bit
-
-   A non-validating security-aware stub resolver MAY chose to examine
-   the setting of the AD bit in response messages that it receives in
-   order to determine whether the security-aware recursive name server
-   which sent the response claims to have cryptographically verified the
-   data in the Answer and Authority sections of the response message.
-   Note, however, that the responses received by a security-aware stub
-   resolver are heavily dependent on the local policy of the
-   security-aware recursive name server, so as a practical matter there
-   may be little practical value to checking the status of the AD bit
-   except perhaps as a debugging aid.  In any case, a security-aware
-   stub resolver MUST NOT place any reliance on signature validation
-   allegedly performed on its behalf except when the security-aware stub
-   resolver obtained the data in question from a trusted security-aware
-   recursive name server via a secure channel.
-
-   A validating security-aware stub resolver SHOULD NOT examine the
-   setting of the AD bit in response messages, since, by definition, the
-   stub resolver performs its own signature validation regardless of the
-   setting of the AD bit.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 24]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-5.  Authenticating DNS Responses
-
-   In order to use DNSSEC RRs for authentication, a security-aware
-   resolver requires configured knowledge of at least one authenticated
-   DNSKEY or DS RR.  The process for obtaining and authenticating this
-   initial trust anchors is achieved via some external mechanism.  For
-   example, a resolver could use some off-line authenticated exchange to
-   obtain a zone's DNSKEY RR or obtain a DS RR that identifies and
-   authenticates a zone's DNSKEY RR.  The remainder of this section
-   assumes that the resolver has somehow obtained an initial set of
-   trust anchors.
-
-   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
-   RRset.  To authenticate an apex DNSKEY RRset using an initial key,
-   the resolver MUST:
-   1.  Verify that the initial DNSKEY RR appears in the apex DNSKEY
-       RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
-       (DNSKEY RDATA bit 7) set.
-   2.  Verify that there is some RRSIG RR that covers the apex DNSKEY
-       RRset, and that the combination of the RRSIG RR and the initial
-       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
-       an RRSIG RR to authenticate an RRset is described in Section 5.3.
-
-   Once the resolver has authenticated the apex DNSKEY RRset using an
-   initial DNSKEY RR, delegations from that zone can be authenticated
-   using DS RRs.  This allows a resolver to start from an initial key,
-   and use DS RRsets to proceed recursively down the DNS tree obtaining
-   other apex DNSKEY RRsets.  If the resolver were configured with a
-   root DNSKEY RR, and if every delegation had a DS RR associated with
-   it, then the resolver could obtain and validate any apex DNSKEY
-   RRset.  The process of using DS RRs to authenticate referrals is
-   described in Section 5.2.
-
-   Once the resolver has authenticated a zone's apex DNSKEY RRset,
-   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
-   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
-   RRsets in the zone.  Section 5.4 shows how the resolver can use
-   authenticated NSEC RRsets from the zone to prove that an RRset is not
-   present in the zone.
-
-   When a resolver indicates support for DNSSEC (by setting the DO bit),
-   a security-aware name server should attempt to provide the necessary
-   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
-   However, a security-aware resolver may still receive a response that
-   that lacks the appropriate DNSSEC RRs, whether due to configuration
-   issues such as an upstream security-oblivious recursive name server
-   that accidentally interferes with DNSSEC RRs or due to a deliberate
-   attack in which an adversary forges a response, strips DNSSEC RRs
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 25]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   from a response, or modifies a query so that DNSSEC RRs appear not to
-   be requested.  The absence of DNSSEC data in a response MUST NOT by
-   itself be taken as an indication that no authentication information
-   exists.
-
-   A resolver SHOULD expect authentication information from signed
-   zones.  A resolver SHOULD believe that a zone is signed if the
-   resolver has been configured with public key information for the
-   zone, or if the zone's parent is signed and the delegation from the
-   parent contains a DS RRset.
-
-5.1  Special Considerations for Islands of Security
-
-   Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
-   zones for which it is not possible to construct an authentication
-   chain to the zone from its parent.  Validating signatures within an
-   island of security requires the validator to have some other means of
-   obtaining an initial authenticated zone key for the island.  If a
-   validator cannot obtain such a key, it SHOULD switch to operating as
-   if the zones in the island of security are unsigned.
-
-   All the normal processes for validating responses apply to islands of
-   security.  The only difference between normal validation and
-   validation within an island of security is in how the validator
-   obtains a trust anchor for the authentication chain.
-
-5.2  Authenticating Referrals
-
-   Once the apex DNSKEY RRset for a signed parent zone has been
-   authenticated, DS RRsets can be used to authenticate the delegation
-   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
-   zone's apex DNSKEY RRset, and contains a cryptographic digest of the
-   child zone's DNSKEY RR.  A strong cryptographic digest algorithm
-   ensures that an adversary can not easily generate a DNSKEY RR that
-   matches the digest.  Thus, authenticating the digest allows a
-   resolver to authenticate the matching DNSKEY RR.  The resolver can
-   then use this child DNSKEY RR to authenticate the entire child apex
-   DNSKEY RRset.
-
-   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
-   can be authenticated if all of the following hold:
-   o  The DS RR has been authenticated using some DNSKEY RR in the
-      parent's apex DNSKEY RRset (see Section 5.3);
-   o  The Algorithm and Key Tag in the DS RR match the Algorithm field
-      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
-      RRset and, when hashed using the digest algorithm specified in the
-      DS RR's Digest Type field, results in a digest value that matches
-      the Digest field of the DS RR; and
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 26]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   o  The matching DNSKEY RR in the child zone has the Zone Flag bit
-      set, the corresponding private key has signed the child zone's
-      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
-      child zone's apex DNSKEY RRset.
-
-   If the referral from the parent zone did not contain a DS RRset, the
-   response should have included a signed NSEC RRset proving that no DS
-   RRset exists for the delegated name (see Section 3.1.4).  A
-   security-aware resolver MUST query the name servers for the parent
-   zone for the DS RRset if the referral includes neither a DS RRset nor
-   a NSEC RRset proving that the DS RRset does not exist (see Section
-   4).
-
-   If the validator authenticates an NSEC RRset that proves that no DS
-   RRset is present for this zone, then there is no authentication path
-   leading from the parent to the child.  If the resolver has an initial
-   DNSKEY or DS RR that belongs to the child zone or to any delegation
-   below the child zone, this initial DNSKEY or DS RR MAY be used to
-   re-establish an authentication path.  If no such initial DNSKEY or DS
-   RR exists, the validator can not authenticate RRsets in or below the
-   child zone.
-
-   If the validator does not support any of the algorithms listed in an
-   authenticated DS RRset, then the resolver has no supported
-   authentication path leading from the parent to the child.  The
-   resolver should treat this case as it would the case of an
-   authenticated NSEC RRset proving that no DS RRset exists, as
-   described above.
-
-   Note that, for a signed delegation, there are two NSEC RRs associated
-   with the delegated name.  One NSEC RR resides in the parent zone, and
-   can be used to prove whether a DS RRset exists for the delegated
-   name.  The second NSEC RR resides in the child zone, and identifies
-   which RRsets are present at the apex of the child zone.  The parent
-   NSEC RR and child NSEC RR can always be distinguished, since the SOA
-   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
-   A security-aware resolver MUST use the parent NSEC RR when attempting
-   to prove that a DS RRset does not exist.
-
-   If the resolver does not support any of the algorithms listed in an
-   authenticated DS RRset, then the resolver will not be able to verify
-   the authentication path to the child zone.  In this case, the
-   resolver SHOULD treat the child zone as if it were unsigned.
-
-5.3  Authenticating an RRset Using an RRSIG RR
-
-   A validator can use an RRSIG RR and its corresponding DNSKEY RR to
-   attempt to authenticate RRsets.  The validator first checks the RRSIG
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 27]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   RR to verify that it covers the RRset, has a valid time interval, and
-   identifies a valid DNSKEY RR.  The validator then constructs the
-   canonical form of the signed data by appending the RRSIG RDATA
-   (excluding the Signature Field) with the canonical form of the
-   covered RRset.  Finally, the validator uses the public key and
-   signature to authenticate the signed data.  Section 5.3.1, Section
-   5.3.2, and Section 5.3.3 describe each step in detail.
-
-5.3.1  Checking the RRSIG RR Validity
-
-   A security-aware resolver can use an RRSIG RR to authenticate an
-   RRset if all of the following conditions hold:
-   o  The RRSIG RR and the RRset MUST have the same owner name and the
-      same class;
-   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
-      that contains the RRset;
-   o  The RRSIG RR's Type Covered field MUST equal the RRset's type;
-   o  The number of labels in the RRset owner name MUST be greater than
-      or equal to the value in the RRSIG RR's Labels field;
-   o  The validator's notion of the current time MUST be less than or
-      equal to the time listed in the RRSIG RR's Expiration field;
-   o  The validator's notion of the current time MUST be greater than or
-      equal to the time listed in the RRSIG RR's Inception field;
-   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
-      match the owner name, algorithm, and key tag for some DNSKEY RR in
-      the zone's apex DNSKEY RRset;
-   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
-      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
-      set.
-
-   It is possible for more than one DNSKEY RR to match the conditions
-   above.  In this case, the validator cannot predetermine which DNSKEY
-   RR to use to authenticate the signature, MUST try each matching
-   DNSKEY RR until either the signature is validated or the validator
-   has run out of matching public keys to try.
-
-   Note that this authentication process is only meaningful if the
-   validator authenticates the DNSKEY RR before using it to validate
-   signatures.  The matching DNSKEY RR is considered to be authentic if:
-   o  The apex DNSKEY RRset containing the DNSKEY RR is considered
-      authentic; or
-   o  The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
-      and the DNSKEY RR either matches an authenticated DS RR from the
-      parent zone or matches a trust anchor.
-
-5.3.2  Reconstructing the Signed Data
-
-   Once the RRSIG RR has met the validity requirements described in
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 28]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   Section 5.3.1, the validator needs to reconstruct the original signed
-   data.  The original signed data includes RRSIG RDATA (excluding the
-   Signature field) and the canonical form of the RRset.  Aside from
-   being ordered, the canonical form of the RRset might also differ from
-   the received RRset due to DNS name compression, decremented TTLs, or
-   wildcard expansion.  The validator should use the following to
-   reconstruct the original signed data:
-
-         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where
-
-            "|" denotes concatenation
-
-            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
-               with the Signature field excluded and the Signer's Name
-               in canonical form.
-
-            RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
-
-               name is calculated according to the function below
-
-               class is the RRset's class
-
-               type is the RRset type and all RRs in the class
-
-               OrigTTL is the value from the RRSIG Original TTL field
-
-               All names in the RDATA field are in canonical form
-
-               The set of all RR(i) is sorted into canonical order.
-
-            To calculate the name:
-               let rrsig_labels = the value of the RRSIG Labels field
-
-               let fqdn = RRset's fully qualified domain name in
-                               canonical form
-
-               let fqdn_labels = Label count of the fqdn above.
-
-               if rrsig_labels = fqdn_labels,
-                   name = fqdn
-
-               if rrsig_labels < fqdn_labels,
-                  name = "*." | the rightmost rrsig_label labels of the
-                                fqdn
-
-               if rrsig_labels > fqdn_labels
-                  the RRSIG RR did not pass the necessary validation
-                  checks and MUST NOT be used to authenticate this
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 29]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-                  RRset.
-
-   The canonical forms for names and RRsets are defined in
-   [I-D.ietf-dnsext-dnssec-records].
-
-   NSEC RRsets at a delegation boundary require special processing.
-   There are two distinct NSEC RRsets associated with a signed delegated
-   name.  One NSEC RRset resides in the parent zone, and specifies which
-   RRset are present at the parent zone.  The second NSEC RRset resides
-   at the child zone, and identifies which RRsets are present at the
-   apex in the child zone.  The parent NSEC RRset and child NSEC RRset
-   can always be distinguished since only the child NSEC RRs will
-   specify an SOA RRset exists at the name.  When reconstructing the
-   original NSEC RRset for the delegation from the parent zone, the NSEC
-   RRs MUST NOT be combined with NSEC RRs from the child zone, and when
-   reconstructing the original NSEC RRset for the apex of the child
-   zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
-   zone.
-
-   Note also that each of the two NSEC RRsets at a delegation point has
-   a corresponding RRSIG RR with an owner name matching the delegated
-   name, and each of these RRSIG RRs is authoritative data associated
-   with the same zone that contains the corresponding NSEC RRset.  If
-   necessary, a resolver can tell these RRSIG RRs apart by checking the
-   Signer's Name field.
-
-5.3.3  Checking the Signature
-
-   Once the resolver has validated the RRSIG RR as described in Section
-   5.3.1 and reconstructed the original signed data as described in
-   Section 5.3.2, the validator can attempt to use the cryptographic
-   signature to authenticate the signed data, and thus (finally!)
-   authenticate the RRset.
-
-   The Algorithm field in the RRSIG RR identifies the cryptographic
-   algorithm used to generate the signature.  The signature itself is
-   contained in the Signature field of the RRSIG RDATA, and the public
-   key used to verify the signature is contained in the Public Key field
-   of the matching DNSKEY RR(s) (found in Section 5.3.1).
-   [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types
-   and provides pointers to the documents that define each algorithm's
-   use.
-
-   Note that it is possible for more than one DNSKEY RR to match the
-   conditions in Section 5.3.1.  In this case, the validator can only
-   determine which DNSKEY RR by trying each matching public key until
-   the validator either succeeds in validating the signature or runs out
-   of keys to try.
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 30]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   If the Labels field of the RRSIG RR is not equal to the number of
-   labels in the RRset's fully qualified owner name, then the RRset is
-   either invalid or the result of wildcard expansion.  The resolver
-   MUST verify that wildcard expansion was applied properly before
-   considering the RRset to be authentic.  Section 5.3.4 describes how
-   to determine whether a wildcard was applied properly.
-
-   If other RRSIG RRs also cover this RRset, the local resolver security
-   policy determines whether the resolver also needs to test these RRSIG
-   RRs, and determines how to resolve conflicts if these RRSIG RRs lead
-   to differing results.
-
-   If the resolver accepts the RRset as authentic, the validator MUST
-   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
-   a value no greater than the minimum of:
-   o  The RRset's TTL as received in the response;
-   o  The RRSIG RR's TTL as received in the response;
-   o  The value in the RRSIG RR's Original TTL field; and
-   o  The difference of the RRSIG RR's Signature Expiration time and the
-      current time.
-
-5.3.4  Authenticating A Wildcard Expanded RRset Positive Response
-
-   If the number of labels in an RRset's owner name is greater than the
-   Labels field of the covering RRSIG RR, then the RRset and its
-   covering RRSIG RR were created as a result of wildcard expansion.
-   Once the validator has verified the signature as described in Section
-   5.3, it must take additional steps to verify the non-existence of an
-   exact match or closer wildcard match for the query.  Section 5.4
-   discusses these steps.
-
-   Note that the response received by the resolver should include all
-   NSEC RRs needed to authenticate the response (see Section 3.1.3).
-
-5.4  Authenticated Denial of Existence
-
-   A resolver can use authenticated NSEC RRs to prove that an RRset is
-   not present in a signed zone.  Security-aware name servers should
-   automatically include any necessary NSEC RRs for signed zones in
-   their responses to security-aware resolvers.
-
-   Denial of existence is determined by the following rules:
-   o  If the requested RR name matches the owner name of an
-      authenticated NSEC RR, then the NSEC RR's type bit map field lists
-      all RR types present at that owner name, and a resolver can prove
-      that the requested RR type does not exist by checking for the RR
-      type in the bit map.  If the number of labels in an authenticated
-      NSEC RR's owner name equals the Labels field of the covering RRSIG
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 31]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-      RR, then the existence of the NSEC RR proves that wildcard
-      expansion could not have been used to match the request.
-   o  If the requested RR name would appear after an authenticated NSEC
-      RR's owner name and before the name listed in that NSEC RR's Next
-      Domain Name field according to the canonical DNS name order
-      defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
-      the requested name exist in the zone.  However, it is possible
-      that a wildcard could be used to match the requested RR owner name
-      and type, so proving that the requested RRset does not exist also
-      requires proving that no possible wildcard RRset exists that could
-      have been used to generate a positive response.
-
-   In addition, security-aware resolvers MUST authenticate the NSEC
-   RRsets that comprise the non-existence proof as described in Section
-   5.3.
-
-   To prove non-existence of an RRset, the resolver must be able to
-   verify both that the queried RRset does not exist and that no
-   relevant wildcard RRset exists.  Proving this may require more than
-   one NSEC RRset from the zone.  If the complete set of necessary NSEC
-   RRsets is not present in a response (perhaps due to message
-   truncation), then a security-aware resolver MUST resend the query in
-   order to attempt to obtain the full collection of NSEC RRs necessary
-   to verify non-existence of the requested RRset.  As with all DNS
-   operations, however, the resolver MUST bound the work it puts into
-   answering any particular query.
-
-   Since a validated NSEC RR proves the existence of both itself and its
-   corresponding RRSIG RR, a validator MUST ignore the settings of the
-   NSEC and RRSIG bits in an NSEC RR.
-
-5.5  Resolver Behavior When Signatures Do Not Validate
-
-   If for whatever reason none of the RRSIGs can be validated, the
-   response SHOULD be considered BAD.  If the validation was being done
-   to service a recursive query, the name server MUST return RCODE 2 to
-   the originating client.  However, it MUST return the full response if
-   and only if the original query had the CD bit set.  See also Section
-   4.7 on caching responses that do not validate.
-
-5.6  Authentication Example
-
-   Appendix C shows an example the authentication process.
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 32]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-6.  IANA Considerations
-
-   [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
-   considerations introduced by DNSSEC.  The additional IANA
-   considerations discussed in this document:
-
-   [RFC2535] reserved the CD and AD bits in the message header.  The
-   meaning of the AD bit was redefined in [RFC3655] and the meaning of
-   both the CD and AD bit are restated in this document.  No new bits in
-   the DNS message header are defined in this document.
-
-   [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
-   and defined its use.  The use is restated but not altered in this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 33]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-7.  Security Considerations
-
-   This document describes how the DNS security extensions use public
-   key cryptography to sign and authenticate DNS resource record sets.
-   Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
-   security considerations related to DNSSEC; see
-   [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
-   DNSSEC resource record types.
-
-   An active attacker who can set the CD bit in a DNS query message or
-   the AD bit in a DNS response message can use these bits to defeat the
-   protection which DNSSEC attempts to provide to security-oblivious
-   recursive-mode resolvers.  For this reason, use of these control bits
-   by a security-aware recursive-mode resolver requires a secure
-   channel.  See Section 3.2.2 and Section 4.9 for further discussion.
-
-   The protocol described in this document attempts to extend the
-   benefits of DNSSEC to security-oblivious stub resolvers.  However,
-   since recovery from validation failures is likely to be specific to
-   particular applications, the facilities that DNSSEC provides for stub
-   resolvers may prove inadequate.  Operators of security-aware
-   recursive name servers will need to pay close attention to the
-   behavior of the applications which use their services when choosing a
-   local validation policy; failure to do so could easily result in the
-   recursive name server accidentally denying service to the clients it
-   is intended to support.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 34]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-8.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group and working group mailing list.  The
-   editors would like to express their thanks for the comments and
-   suggestions received during the revision of these security extension
-   specifications.  While explicitly listing everyone who has
-   contributed during the decade during which DNSSEC has been under
-   development would be an impossible task,
-   [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
-   participants who were kind enough to comment on these documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 35]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-9.  References
-
-9.1  Normative References
-
-   [I-D.ietf-dnsext-dnssec-intro]
-              Arends, R., Austein, R., Larson, M., Massey, D. and S.
-              Rose, "DNS Security Introduction and Requirements",
-              draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
-              2004.
-
-   [I-D.ietf-dnsext-dnssec-records]
-              Arends, R., Austein, R., Larson, M., Massey, D. and S.
-              Rose, "Resource Records for DNS Security Extensions",
-              draft-ietf-dnsext-dnssec-records-08 (work in progress),
-              May 2004.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              August 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-              2672, August 1999.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-9.2  Informative References
-
-   [I-D.ietf-dnsext-nsec-rdata]
-              Schlyter, J., "DNSSEC NSEC RDATA Format",
-              draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 36]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-              2004.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
-              SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-              Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Drienerlolaan 5
-   7522 NB  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 37]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   Dan Massey
-   USC Information Sciences Institute
-   3811 N. Fairfax Drive
-   Arlington, VA  22203
-   USA
-
-   EMail: masseyd@isi.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 38]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-Appendix A.  Signed Zone Example
-
-   The following example shows a (small) complete signed zone.
-
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-                  3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-                  3600 NS     ns1.example.
-                  3600 NS     ns2.example.
-                  3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-                  3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
-                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
-                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
-                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
-                              W6OISukd1EQt7a0kygkg+PEDxdI= )
-                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-                  3600 DNSKEY 256 3 5 (
-                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
-                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
-                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
-                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 39]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
-                              )
-                  3600 DNSKEY 257 3 5 (
-                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
-                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
-                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
-                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
-                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
-                              )
-                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
-                              20040409183619 9465 example.
-                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
-                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
-                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
-                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
-                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
-                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
-                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
-                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
-                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
-                              7z5OXogYVaFzHKillDt3HRxHIZM= )
-   a.example.     3600 IN NS  ns1.a.example.
-                  3600 IN NS  ns2.a.example.
-                  3600 DS     57855 5 1 (
-                              B6DCD485719ADCA18E5F3D48A2331627FDD3
-                              636B )
-                  3600 RRSIG  DS 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
-                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
-                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
-                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
-                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
-                  3600 NSEC   ai.example. NS DS RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
-                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
-                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
-                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
-                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-   ai.example.    3600 IN A   192.0.2.9
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 40]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
-                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
-                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
-                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
-                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
-                  3600 HINFO  "KLH-10" "ITS"
-                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
-                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
-                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
-                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
-                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
-                  3600 AAAA   2001:db8::f00:baa9
-                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
-                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
-                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
-                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
-                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
-                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
-                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
-                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
-                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
-                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )
-   b.example.     3600 IN NS  ns1.b.example.
-                  3600 IN NS  ns2.b.example.
-                  3600 NSEC   ns1.example. NS RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-   ns1.example.   3600 IN A   192.0.2.1
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
-                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
-                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
-                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 41]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
-                  3600 NSEC   ns2.example. A RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
-                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
-                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
-                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
-                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
-   ns2.example.   3600 IN A   192.0.2.2
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
-                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
-                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
-                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
-                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
-                  3600 NSEC   *.w.example. A RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
-                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
-                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
-                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
-                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
-   *.w.example.   3600 IN MX  1 ai.example.
-                  3600 RRSIG  MX 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
-                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
-                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
-                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
-                              4kX18MMR34i8lC36SR5xBni8vHI= )
-                  3600 NSEC   x.w.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
-                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
-                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
-                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
-                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
-   x.w.example.   3600 IN MX  1 xx.example.
-                  3600 RRSIG  MX 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
-                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
-                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
-                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 42]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
-                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
-                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
-                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
-                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
-                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )
-   x.y.w.example. 3600 IN MX  1 xx.example.
-                  3600 RRSIG  MX 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
-                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
-                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
-                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
-                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )
-                  3600 NSEC   xx.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-   xx.example.    3600 IN A   192.0.2.10
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
-                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
-                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
-                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
-                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
-                  3600 HINFO  "KLH-10" "TOPS-20"
-                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
-                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
-                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
-                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
-                              RgNvuwbioFSEuv2pNlkq0goYxNY= )
-                  3600 AAAA   2001:db8::f00:baaa
-                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
-                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
-                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
-                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 43]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
-                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
-                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
-                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
-                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
-                              GghLahumFIpg4MO3LS/prgzVVWo= )
-
-   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
-   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
-   these DNSKEY RRs also has the SEP flag set and has been used to sign
-   the apex DNSKEY RRset; this is the key which should be hashed to
-   generate a DS record to be inserted into the parent zone.  The other
-   DNSKEY is used to sign all the other RRsets in the zone.
-
-   The zone includes a wildcard entry "*.w.example".  Note that the name
-   "*.w.example" is used in constructing NSEC chains, and that the RRSIG
-   covering the "*.w.example" MX RRset has a label count of 2.
-
-   The zone also includes two delegations.  The delegation to
-   "b.example" includes an NS RRset, glue address records, and an NSEC
-   RR; note that only the NSEC RRset is signed.  The delegation to
-   "a.example" provides a DS RR; note that only the NSEC and DS RRsets
-   are signed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 44]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-Appendix B.  Example Responses
-
-   The examples in this section show response messages using the signed
-   zone example in Appendix A.
-
-B.1  Answer
-
-   A successful query to an authoritative server.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   x.w.example.        IN MX
-
-   ;; Answer
-   x.w.example.   3600 IN MX  1 xx.example.
-   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
-                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
-                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
-                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
-                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
-
-   ;; Authority
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-
-   ;; Additional
-   xx.example.    3600 IN A   192.0.2.10
-   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
-                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
-                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
-                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
-                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
-   xx.example.    3600 AAAA   2001:db8::f00:baaa
-   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 45]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
-                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
-                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
-                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
-   ns1.example.   3600 IN A   192.0.2.1
-   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
-                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
-                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
-                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
-                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
-   ns2.example.   3600 IN A   192.0.2.2
-   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
-                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
-                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
-                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
-                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
-
-
-B.2  Name Error
-
-   An authoritative name error.  The NSEC RRs prove that the name does
-   not exist and that no covering wildcard exists.
-
-   ;; Header: QR AA DO RCODE=3
-   ;;
-   ;; Question
-   ml.example.         IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 46]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
-   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
-   ;; Additional
-   ;; (empty)
-
-
-B.3  No Data Error
-
-   A "no data" response.  The NSEC RR proves that the name exists and
-   that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 47]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   ns1.example.        IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
-   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
-                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
-                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
-                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
-                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
-
-   ;; Additional
-   ;; (empty)
-
-
-B.4  Referral to Signed Zone
-
-   Referral to a signed zone.  The DS RR contains the data which the
-   resolver will need to validate the corresponding DNSKEY RR in the
-   child zone's apex.
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 48]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.a.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   a.example.     3600 IN NS  ns1.a.example.
-   a.example.     3600 IN NS  ns2.a.example.
-   a.example.     3600 DS     57855 5 1 (
-                              B6DCD485719ADCA18E5F3D48A2331627FDD3
-                              636B )
-   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
-                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
-                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
-                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
-                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
-
-   ;; Additional
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-
-
-B.5  Referral to Unsigned Zone
-
-   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
-   this delegation exists in the parent zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 49]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.b.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   b.example.     3600 IN NS  ns1.b.example.
-   b.example.     3600 IN NS  ns2.b.example.
-   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
-   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-
-   ;; Additional
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-
-
-B.6  Wildcard Expansion
-
-   A successful query which was answered via wildcard expansion.  The
-   label count in the answer's RRSIG RR indicates that a wildcard RRset
-   was expanded to produce this response, and the NSEC RR proves that no
-   closer match exists in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN MX
-
-   ;; Answer
-   a.z.w.example. 3600 IN MX  1 ai.example.
-   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
-                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
-                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
-                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
-                              4kX18MMR34i8lC36SR5xBni8vHI= )
-
-   ;; Authority
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 50]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
-   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-
-   ;; Additional
-   ai.example.    3600 IN A   192.0.2.9
-   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
-                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
-                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
-                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
-                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
-   ai.example.    3600 AAAA   2001:db8::f00:baa9
-   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
-                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
-                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
-                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
-                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
-
-
-B.7  Wildcard No Data Error
-
-   A "no data" response for a name covered by a wildcard.  The NSEC RRs
-   prove that the matching wildcard name does not have any RRs of the
-   requested type and that no closer match exists in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN AAAA
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 51]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
-   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
-   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
-                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
-                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
-                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
-                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
-
-   ;; Additional
-   ;; (empty)
-
-
-B.8  DS Child Zone No Data Error
-
-   A "no data" response for a QTYPE=DS query which was mistakenly sent
-   to a name server for the child zone.
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 52]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   example.            IN DS
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
-   ;; Additional
-   ;; (empty)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 53]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-Appendix C.  Authentication Examples
-
-   The examples in this section show how the response messages in
-   Appendix B are authenticated.
-
-C.1  Authenticating An Answer
-
-   The query in section Appendix B.1 returned an MX RRset for
-   "x.w.example.com".  The corresponding RRSIG indicates the MX RRset
-   was signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
-   The resolver needs the corresponding DNSKEY RR in order to
-   authenticate this answer.  The discussion below describes how a
-   resolver might obtain this DNSKEY RR.
-
-   The RRSIG indicates the original TTL of the MX RRset was 3600 and,
-   for the purpose of authentication, the current TTL is replaced by
-   3600.  The RRSIG labels field value of 3 indicates the answer was not
-   the result of wildcard expansion.  The "x.w.example.com" MX RRset is
-   placed in canonical form and, assuming the current time falls between
-   the signature inception and expiration dates, the signature is
-   authenticated.
-
-C.1.1  Authenticating the example DNSKEY RR
-
-   This example shows the logical authentication process that starts
-   from the a configured root DNSKEY (or DS RR) and moves down the tree
-   to authenticate the desired "example" DNSKEY RR.  Note the logical
-   order is presented for clarity and an implementation may choose to
-   construct the authentication as referrals are received or may choose
-   to construct the authentication chain only after all RRsets have been
-   obtained, or in any other combination it sees fit.  The example here
-   demonstrates only the logical process and does not dictate any
-   implementation rules.
-
-   We assume the resolver starts with an configured DNSKEY RR for the
-   root zone (or a configured DS RR for the root zone).  The resolver
-   checks this configured DNSKEY RR is present in the root DNSKEY RRset
-   (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this
-   DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime
-   is valid.  If all these conditions are met, all keys in the DNSKEY
-   RRset are considered authenticated.  The resolver then uses one (or
-   more) of the root DNSKEY RRs to authenticate the "example" DS RRset.
-   Note the resolver may need to query the root zone to obtain the root
-   DNSKEY RRset or "example" DS RRset.
-
-   Once the DS RRset has been authenticated using the root DNSKEY, the
-   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
-   RR that matches one of the authenticated "example" DS RRs.  If such a
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 54]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   matching "example" DNSKEY is found, the resolver checks this DNSKEY
-   RR has signed the "example" DNSKEY RRset and the signature lifetime
-   is valid.  If all these conditions are met, all keys in the "example"
-   DNSKEY RRset are considered authenticated.
-
-   Finally the resolver checks that some DNSKEY RR in the "example"
-   DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This
-   DNSKEY is used to authenticated the RRSIG included in the response.
-   If multiple "example" DNSKEY RRs match this algorithm and key tag,
-   then each DNSKEY RR is tried and the answer is authenticated if any
-   of the matching DNSKEY RRs validates the signature as described
-   above.
-
-C.2  Name Error
-
-   The query in section Appendix B.2 returned NSEC RRs that prove the
-   requested data does not exist and no wildcard applies.  The negative
-   reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are
-   authenticated in a manner identical to that of the MX RRset discussed
-   above.
-
-C.3  No Data Error
-
-   The query in section Appendix B.3 returned an NSEC RR that proves the
-   requested name exists, but the requested RR type does not exist.  The
-   negative reply is authenticated by verifying the NSEC RR.  The NSEC
-   RR is authenticated in a manner identical to that of the MX RRset
-   discussed above.
-
-C.4  Referral to Signed Zone
-
-   The query in section Appendix B.4 returned a referral to the signed
-   "a.example." zone.  The DS RR is authenticated in a manner identical
-   to that of the MX RRset discussed above.  This DS RR is used to
-   authenticate the "a.example" DNSKEY RRset.
-
-   Once the "a.example" DS RRset has been authenticated using the
-   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
-   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
-   matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
-   RR has signed the "a.example" DNSKEY RRset and the signature lifetime
-   is valid.  If all these conditions are met, all keys in the
-   "a.example" DNSKEY RRset are considered authenticated.
-
-C.5  Referral to Unsigned Zone
-
-   The query in section Appendix B.5 returned a referral to an unsigned
-   "b.example." zone.  The NSEC proves that no authentication leads from
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 55]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-   "example" to "b.example" and the NSEC RR is authenticated in a manner
-   identical to that of the MX RRset discussed above.
-
-C.6  Wildcard Expansion
-
-   The query in section Appendix B.6 returned an answer that was
-   produced as a result of wildcard expansion.  The RRset expanded as
-   the similar to The corresponding RRSIG indicates the MX RRset was
-   signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
-   The RRSIG indicates the original TTL of the MX RRset was 3600 and,
-   for the purpose of authentication, the current TTL is replaced by
-   3600.  The RRSIG labels field value of 2 indicates the answer the
-   result of wildcard expansion since the "a.z.w.example" name contains
-   4 labels.  The name "a.z.w.w.example" is replaced by "*.w.example",
-   the MX RRset is placed in canonical form and, assuming the current
-   time falls between the signature inception and expiration dates, the
-   signature is authenticated.
-
-   The NSEC proves that no closer match (exact or closer wildcard) could
-   have been used to answer this query and the NSEC RR must also be
-   authenticated before the answer is considered valid.
-
-C.7  Wildcard No Data Error
-
-   The query in section Appendix B.7 returned NSEC RRs that prove the
-   requested data does not exist and no wildcard applies.  The negative
-   reply is authenticated by verifying both NSEC RRs.
-
-C.8  DS Child Zone No Data Error
-
-   The query in section Appendix B.8 returned NSEC RRs that shows the
-   requested was answered by a child server ("example" server).  The
-   NSEC RR indicates the presence of an SOA RR, showing the answer is
-   from the child .  Queries for the "example" DS RRset should be sent
-   to the parent servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 56]
-
-Internet-Draft       DNSSEC Protocol Modifications             July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 57]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
deleted file mode 100644
index 79a17284357c..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
+++ /dev/null
@@ -1,1849 +0,0 @@
-
-
-DNS Extensions                                                 R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: January 13, 2005                                     R. Austein
-                                                                     ISC
-                                                               M. Larson
-                                                                VeriSign
-                                                               D. Massey
-                                                                 USC/ISI
-                                                                 S. Rose
-                                                                    NIST
-                                                           July 15, 2004
-
-
-            Resource Records for the DNS Security Extensions
-                  draft-ietf-dnsext-dnssec-records-09
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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.
-
-   This Internet-Draft will expire on January 13, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document is part of a family of documents that describes the DNS
-   Security Extensions (DNSSEC).  The DNS Security Extensions are a
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 1]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   collection of resource records and protocol modifications that
-   provide source authentication for the DNS.  This document defines the
-   public key (DNSKEY), delegation signer (DS), resource record digital
-   signature (RRSIG), and authenticated denial of existence (NSEC)
-   resource records.  The purpose and format of each resource record is
-   described in detail, and an example of each resource record is given.
-
-   This document obsoletes RFC 2535 and incorporates changes from all
-   updates to RFC 2535.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1   Background and Related Documents . . . . . . . . . . . . .  4
-     1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . . .  5
-     2.1   DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . .  5
-       2.1.1   The Flags Field  . . . . . . . . . . . . . . . . . . .  5
-       2.1.2   The Protocol Field . . . . . . . . . . . . . . . . . .  6
-       2.1.3   The Algorithm Field  . . . . . . . . . . . . . . . . .  6
-       2.1.4   The Public Key Field . . . . . . . . . . . . . . . . .  6
-       2.1.5   Notes on DNSKEY RDATA Design . . . . . . . . . . . . .  6
-     2.2   The DNSKEY RR Presentation Format  . . . . . . . . . . . .  6
-     2.3   DNSKEY RR Example  . . . . . . . . . . . . . . . . . . . .  7
-   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . . .  8
-     3.1   RRSIG RDATA Wire Format  . . . . . . . . . . . . . . . . .  8
-       3.1.1   The Type Covered Field . . . . . . . . . . . . . . . .  9
-       3.1.2   The Algorithm Number Field . . . . . . . . . . . . . .  9
-       3.1.3   The Labels Field . . . . . . . . . . . . . . . . . . .  9
-       3.1.4   Original TTL Field . . . . . . . . . . . . . . . . . . 10
-       3.1.5   Signature Expiration and Inception Fields  . . . . . . 10
-       3.1.6   The Key Tag Field  . . . . . . . . . . . . . . . . . . 10
-       3.1.7   The Signer's Name Field  . . . . . . . . . . . . . . . 11
-       3.1.8   The Signature Field  . . . . . . . . . . . . . . . . . 11
-     3.2   The RRSIG RR Presentation Format . . . . . . . . . . . . . 12
-     3.3   RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12
-   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14
-     4.1   NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14
-       4.1.1   The Next Domain Name Field . . . . . . . . . . . . . . 14
-       4.1.2   The Type Bit Maps Field  . . . . . . . . . . . . . . . 15
-       4.1.3   Inclusion of Wildcard Names in NSEC RDATA  . . . . . . 16
-     4.2   The NSEC RR Presentation Format  . . . . . . . . . . . . . 16
-     4.3   NSEC RR Example  . . . . . . . . . . . . . . . . . . . . . 16
-   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18
-     5.1   DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18
-       5.1.1   The Key Tag Field  . . . . . . . . . . . . . . . . . . 19
-       5.1.2   The Algorithm Field  . . . . . . . . . . . . . . . . . 19
-       5.1.3   The Digest Type Field  . . . . . . . . . . . . . . . . 19
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 2]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-       5.1.4   The Digest Field . . . . . . . . . . . . . . . . . . . 19
-     5.2   Processing of DS RRs When Validating Responses . . . . . . 19
-     5.3   The DS RR Presentation Format  . . . . . . . . . . . . . . 20
-     5.4   DS RR Example  . . . . . . . . . . . . . . . . . . . . . . 20
-   6.  Canonical Form and Order of Resource Records . . . . . . . . . 21
-     6.1   Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21
-     6.2   Canonical RR Form  . . . . . . . . . . . . . . . . . . . . 21
-     6.3   Canonical RR Ordering Within An RRset  . . . . . . . . . . 22
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
-   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 26
-   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 26
-   10.2  Informative References . . . . . . . . . . . . . . . . . . . 27
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
-   A.  DNSSEC Algorithm and Digest Types  . . . . . . . . . . . . . . 29
-     A.1   DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29
-       A.1.1   Private Algorithm Types  . . . . . . . . . . . . . . . 29
-     A.2   DNSSEC Digest Types  . . . . . . . . . . . . . . . . . . . 30
-   B.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . . . . 31
-     B.1   Key Tag for Algorithm 1 (RSA/MD5)  . . . . . . . . . . . . 32
-       Intellectual Property and Copyright Statements . . . . . . . . 33
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 3]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-1.  Introduction
-
-   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
-   record types: DNSKEY, RRSIG, NSEC, and DS.  This document defines the
-   purpose of each resource record (RR), the RR's RDATA format, and its
-   presentation format (ASCII representation).
-
-1.1  Background and Related Documents
-
-   The reader is assumed to be familiar with the basic DNS concepts
-   described in [RFC1034], [RFC1035] and subsequent RFCs that update
-   them:  [RFC2136], [RFC2181] and [RFC2308].
-
-   This document is part of a family of documents that define the DNS
-   security extensions.  The DNS security extensions (DNSSEC) are a
-   collection of resource records and DNS protocol modifications that
-   add source authentication and data integrity to the Domain Name
-   System (DNS).  An introduction to DNSSEC and definitions of common
-   terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is
-   assumed to be familiar with this document.  A description of DNS
-   protocol modifications can be found in
-   [I-D.ietf-dnsext-dnssec-protocol].
-
-   This document defines the DNSSEC resource records.
-
-1.2  Reserved Words
-
-   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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 4]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-2.  The DNSKEY Resource Record
-
-   DNSSEC uses public key cryptography to sign and authenticate DNS
-   resource record sets (RRsets).  The public keys are stored in DNSKEY
-   resource records and are used in the DNSSEC authentication process
-   described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
-   authoritative RRsets using a private key and stores the corresponding
-   public key in a DNSKEY RR.  A resolver can then use the public key to
-   authenticate signatures covering the RRsets in the zone.
-
-   The DNSKEY RR is not intended as a record for storing arbitrary
-   public keys and MUST NOT be used to store certificates or public keys
-   that do not directly relate to the DNS infrastructure.
-
-   The Type value for the DNSKEY RR type is 48.
-
-   The DNSKEY RR is class independent.
-
-   The DNSKEY RR has no special TTL requirements.
-
-2.1  DNSKEY RDATA Wire Format
-
-   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
-   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
-   Field.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |              Flags            |    Protocol   |   Algorithm   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Public Key                         /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-2.1.1  The Flags Field
-
-   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
-   then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner
-   name MUST be the name of a zone.  If bit 7 has value 0, then the
-   DNSKEY record holds some other type of DNS public key and MUST NOT be
-   used to verify RRSIGs that cover RRsets.
-
-   Bit 15 of the Flags field is the Secure Entry Point flag, described
-   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
-   key intended for use as a secure entry point.  This flag is only
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 5]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   intended to be to a hint to zone signing or debugging software as to
-   the intended use of this DNSKEY record; validators MUST NOT alter
-   their behavior during the signature validation process in any way
-   based on the setting of this bit.  This also means a DNSKEY RR with
-   the SEP bit set would also need the Zone Key flag set in order to
-   legally be able to generate signatures.  A DNSKEY RR with the SEP set
-   and the Zone Key flag not set MUST NOT be used to verify RRSIGs that
-   cover RRsets.
-
-   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
-   creation of the DNSKEY RR, and MUST be ignored upon reception.
-
-2.1.2  The Protocol Field
-
-   The Protocol Field MUST have value 3 and the DNSKEY RR MUST be
-   treated as invalid during signature verification if found to be some
-   value other than 3.
-
-2.1.3  The Algorithm Field
-
-   The Algorithm field identifies the public key's cryptographic
-   algorithm and determines the format of the Public Key field.  A list
-   of DNSSEC algorithm types can be found in Appendix A.1
-
-2.1.4  The Public Key Field
-
-   The Public Key Field holds the public key material.  The format
-   depends on the algorithm of the key being stored and are described in
-   separate documents.
-
-2.1.5  Notes on DNSKEY RDATA Design
-
-   Although the Protocol Field always has value 3, it is retained for
-   backward compatibility with early versions of the KEY record.
-
-2.2  The DNSKEY RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Flag field MUST be represented as an unsigned decimal integer.
-   Given the currently defined flags, the possible values are: 0, 256,
-   or 257.
-
-   The Protocol Field MUST be represented as an unsigned decimal integer
-   with a value of 3.
-
-   The Algorithm field MUST be represented either as an unsigned decimal
-   integer or as an algorithm mnemonic as specified in Appendix A.1.
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 6]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   The Public Key field MUST be represented as a Base64 encoding of the
-   Public Key.  Whitespace is allowed within the Base64 text.  For a
-   definition of Base64 encoding, see [RFC3548].
-
-2.3  DNSKEY RR Example
-
-   The following DNSKEY RR stores a DNS zone key for example.com.
-
-   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
-                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
-                                          kfzj31GajIQKY+5CptLr3buXA10h
-                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
-                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
-                                          742iU/TpPSEDhm2SNKLijfUppn1U
-                                          aNvv4w==  )
-
-   The first four text fields specify the owner name, TTL, Class, and RR
-   type (DNSKEY).  Value 256 indicates that the Zone Key bit (bit 7) in
-   the Flags field has value 1.  Value 3 is the fixed Protocol value.
-   Value 5 indicates the public key algorithm.  Appendix A.1 identifies
-   algorithm type 5 as RSA/SHA1 and indicates that the format of the
-   RSA/SHA1 public key field is defined in [RFC3110].  The remaining
-   text is a Base64 encoding of the public key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 7]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-3.  The RRSIG Resource Record
-
-   DNSSEC uses public key cryptography to sign and authenticate DNS
-   resource record sets (RRsets).  Digital signatures are stored in
-   RRSIG resource records and are used in the DNSSEC authentication
-   process described in [I-D.ietf-dnsext-dnssec-protocol].  A validator
-   can use these RRSIG RRs to authenticate RRsets from the zone.  The
-   RRSIG RR MUST only be used to carry verification material (digital
-   signatures) used to secure DNS operations.
-
-   An RRSIG record contains the signature for an RRset with a particular
-   name, class, and type.  The RRSIG RR specifies a validity interval
-   for the signature and uses the Algorithm, the Signer's Name, and the
-   Key Tag to identify the DNSKEY RR containing the public key that a
-   validator can use to verify the signature.
-
-   Because every authoritative RRset in a zone must be protected by a
-   digital signature, RRSIG RRs must be present for names containing a
-   CNAME RR.  This is a change to the traditional DNS specification
-   [RFC1034] that stated that if a CNAME is present for a name, it is
-   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
-   MUST exist for the same name as a CNAME resource record in a signed
-   zone.
-
-   The Type value for the RRSIG RR type is 46.
-
-   The RRSIG RR is class independent.
-
-   An RRSIG RR MUST have the same class as the RRset it covers.
-
-   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
-   covers.  This is an exception to the [RFC2181] rules for TTL values
-   of individual RRs within a RRset: individual RRSIG with the same
-   owner name will have different TTL values if the RRsets they cover
-   have different TTL values.
-
-3.1  RRSIG RDATA Wire Format
-
-   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
-   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
-   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
-   Inception field, a 2 octet Key tag, the Signer's Name field, and the
-   Signature field.
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 8]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |        Type Covered           |  Algorithm    |     Labels    |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                         Original TTL                          |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                      Signature Expiration                     |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                      Signature Inception                      |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |            Key Tag            |                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Signature                          /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1.1  The Type Covered Field
-
-   The Type Covered field identifies the type of the RRset that is
-   covered by this RRSIG record.
-
-3.1.2  The Algorithm Number Field
-
-   The Algorithm Number field identifies the cryptographic algorithm
-   used to create the signature.  A list of DNSSEC algorithm types can
-   be found in Appendix A.1
-
-3.1.3  The Labels Field
-
-   The Labels field specifies the number of labels in the original RRSIG
-   RR owner name.  The significance of this field is that a validator
-   uses it to determine if the answer was synthesized from a wildcard.
-   If so, it can be used to determine what owner name was used in
-   generating the signature.
-
-   To validate a signature, the validator needs the original owner name
-   that was used to create the signature.  If the original owner name
-   contains a wildcard label ("*"), the owner name may have been
-   expanded by the server during the response process, in which case the
-   validator will need to reconstruct the original owner name in order
-   to validate the signature.  [I-D.ietf-dnsext-dnssec-protocol]
-   describes how to use the Labels field to reconstruct the original
-   owner name.
-
-
-
-Arends, et al.          Expires January 13, 2005                [Page 9]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   The value of the Labels field MUST NOT count either the null (root)
-   label that terminates the owner name or the wildcard label (if
-   present).  The value of the Labels field MUST be less than or equal
-   to the number of labels in the RRSIG owner name.  For example,
-   "www.example.com." has a Labels field value of 3, and
-   "*.example.com." has a Labels field value of 2.  Root (".") has a
-   Labels field value of 0.
-
-   Although the wildcard label is not included in the count stored in
-   the Labels field of the RRSIG RR, the wildcard label is part of the
-   RRset's owner name when generating or verifying the signature.
-
-3.1.4  Original TTL Field
-
-   The Original TTL field specifies the TTL of the covered RRset as it
-   appears in the authoritative zone.
-
-   The Original TTL field is necessary because a caching resolver
-   decrements the TTL value of a cached RRset.  In order to validate a
-   signature, a validator requires the original TTL.
-   [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
-   TTL field value to reconstruct the original TTL.
-
-3.1.5  Signature Expiration and Inception Fields
-
-   The Signature Expiration and Inception fields specify a validity
-   period for the signature.  The RRSIG record MUST NOT be used for
-   authentication prior to the inception date and MUST NOT be used for
-   authentication after the expiration date.
-
-   Signature Expiration and Inception field values are in POSIX.1 time
-   format: a 32-bit unsigned number of seconds elapsed since 1 January
-   1970 00:00:00 UTC, ignoring leap seconds, in network byte order.  The
-   longest interval which can be expressed by this format without
-   wrapping is approximately 136 years.  An RRSIG RR can have an
-   Expiration field value which is numerically smaller than the
-   Inception field value if the expiration field value is near the
-   32-bit wrap-around point or if the signature is long lived.  Because
-   of this, all comparisons involving these fields MUST use "Serial
-   number arithmetic" as defined in [RFC1982].  As a direct consequence,
-   the values contained in these fields cannot refer to dates more than
-   68 years in either the past or the future.
-
-3.1.6  The Key Tag Field
-
-   The Key Tag field contains the key tag value of the DNSKEY RR that
-   validates this signature, in network byte order.  Appendix B explains
-   how to calculate Key Tag values.
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 10]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-3.1.7  The Signer's Name Field
-
-   The Signer's Name field value identifies the owner name of the DNSKEY
-   RR which a validator is supposed to use to validate this signature.
-   The Signer's Name field MUST contain the name of the zone of the
-   covered RRset.  A sender MUST NOT use DNS name compression on the
-   Signer's Name field when transmitting a RRSIG RR.
-
-3.1.8  The Signature Field
-
-   The Signature field contains the cryptographic signature that covers
-   the RRSIG RDATA (excluding the Signature field) and the RRset
-   specified by the RRSIG owner name, RRSIG class, and RRSIG Type
-   Covered field.  The format of this field depends on the algorithm in
-   use and these formats are described in separate companion documents.
-
-3.1.8.1  Signature Calculation
-
-   A signature covers the RRSIG RDATA (excluding the Signature Field)
-   and covers the data RRset specified by the RRSIG owner name, RRSIG
-   class, and RRSIG Type Covered fields.  The RRset is in canonical form
-   (see Section 6) and the set RR(1),...RR(n) is signed as follows:
-
-         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
-
-            "|" denotes concatenation;
-
-            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
-               with the Signer's Name field in canonical form and
-               the Signature field excluded;
-
-            RR(i) = owner | type | class | TTL | RDATA length | RDATA
-
-               "owner" is the fully qualified owner name of the RRset in
-               canonical form (for RRs with wildcard owner names, the
-               wildcard label is included in the owner name);
-
-               Each RR MUST have the same owner name as the RRSIG RR;
-
-               Each RR MUST have the same class as the RRSIG RR;
-
-               Each RR in the RRset MUST have the RR type listed in the
-               RRSIG RR's Type Covered field;
-
-               Each RR in the RRset MUST have the TTL listed in the
-               RRSIG Original TTL Field;
-
-               Any DNS names in the RDATA field of each RR MUST be in
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 11]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-               canonical form; and
-
-               The RRset MUST be sorted in canonical order.
-
-   See Section 6.2 and Section 6.3 for details on canonical form and
-   ordering of RRsets.
-
-3.2  The RRSIG RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Type Covered field is represented as a RR type mnemonic.  When
-   the mnemonic is not known, the TYPE representation as described in
-   [RFC3597] (section 5) MUST be used.
-
-   The Algorithm field value MUST be represented either as an unsigned
-   decimal integer or as an algorithm mnemonic as specified in Appendix
-   A.1.
-
-   The Labels field value MUST be represented as an unsigned decimal
-   integer.
-
-   The Original TTL field value MUST be represented as an unsigned
-   decimal integer.
-
-   The Signature Expiration Time and Inception Time field values MUST be
-   represented either as seconds since 1 January 1970 00:00:00 UTC or in
-   the form YYYYMMDDHHmmSS in UTC, where:
-      YYYY is the year (0001-9999, but see Section 3.1.5);
-      MM is the month number (01-12);
-      DD is the day of the month (01-31);
-      HH is the hour in 24 hours notation (00-23);
-      mm is the minute (00-59); and
-      SS is the second (00-59).
-
-   The Key Tag field MUST be represented as an unsigned decimal integer.
-
-   The Signer's Name field value MUST be represented as a domain name.
-
-   The Signature field is represented as a Base64 encoding of the
-   signature.  Whitespace is allowed within the Base64 text.  See
-   Section 2.2.
-
-3.3  RRSIG RR Example
-
-   The following RRSIG RR stores the signature for the A RRset of
-   host.example.com:
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 12]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
-                                  20030220173103 2642 example.com.
-                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
-                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
-                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
-                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
-                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
-
-   The first four fields specify the owner name, TTL, Class, and RR type
-   (RRSIG).  The "A" represents the Type Covered field.  The value 5
-   identifies the algorithm used (RSA/SHA1) to create the signature.
-   The value 3 is the number of Labels in the original owner name.  The
-   value 86400 in the RRSIG RDATA is the Original TTL for the covered A
-   RRset.  20030322173103 and 20030220173103 are the expiration and
-   inception dates, respectively.  2642 is the Key Tag, and example.com.
-   is the Signer's Name.  The remaining text is a Base64 encoding of the
-   signature.
-
-   Note that combination of RRSIG RR owner name, class, and Type Covered
-   indicate that this RRSIG covers the "host.example.com" A RRset.  The
-   Label value of 3 indicates that no wildcard expansion was used.  The
-   Algorithm, Signer's Name, and Key Tag indicate this signature can be
-   authenticated using an example.com zone DNSKEY RR whose algorithm is
-   5 and key tag is 2642.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 13]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-4.  The NSEC Resource Record
-
-   The NSEC resource record lists two separate things: the next owner
-   name (in the canonical ordering of the zone) which contains
-   authoritative data or a delegation point NS RRset, and the set of RR
-   types present at the NSEC RR's owner name.  The complete set of NSEC
-   RRs in a zone both indicate which authoritative RRsets exist in a
-   zone and also form a chain of authoritative owner names in the zone.
-   This information is used to provide authenticated denial of existence
-   for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol].
-
-   Because every authoritative name in a zone must be part of the NSEC
-   chain, NSEC RRs must be present for names containing a CNAME RR.
-   This is a change to the traditional DNS specification [RFC1034] that
-   stated that if a CNAME is present for a name, it is the only type
-   allowed at that name.  An RRSIG (see Section 3) and NSEC MUST exist
-   for the same name as a CNAME resource record in a signed zone.
-
-   See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone
-   signer determines precisely which NSEC RRs it needs to include in a
-   zone.
-
-   The type value for the NSEC RR is 47.
-
-   The NSEC RR is class independent.
-
-   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [RFC2308].
-
-4.1  NSEC RDATA Wire Format
-
-   The RDATA of the NSEC RR is as shown below:
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                      Next Domain Name                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                       Type Bit Maps                           /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-4.1.1  The Next Domain Name Field
-
-   The Next Domain field contains the next owner name (in the canonical
-   ordering of the zone) which has authoritative data or contains a
-   delegation point NS RRset; see Section 6.1 for an explanation of
-   canonical ordering.  The value of the Next Domain Name field in the
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 14]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   last NSEC record in the zone is the name of the zone apex (the owner
-   name of the zone's SOA RR).  This indicates that the owner name of
-   the NSEC RR is the last name in the canonical ordering of the zone.
-
-   A sender MUST NOT use DNS name compression on the Next Domain Name
-   field when transmitting an NSEC RR.
-
-   Owner names of RRsets not authoritative for the given zone (such as
-   glue records) MUST NOT be listed in the Next Domain Name unless at
-   least one authoritative RRset exists at the same owner name.
-
-4.1.2  The Type Bit Maps Field
-
-   The Type Bit Maps field identifies the RRset types which exist at the
-   NSEC RR's owner name.
-
-   The RR type space is split into 256 window blocks, each representing
-   the low-order 8 bits of the 16-bit RR type space.  Each block that
-   has at least one active RR type is encoded using a single octet
-   window number (from 0 to 255), a single octet bitmap length (from 1
-   to 32) indicating the number of octets used for the window block's
-   bitmap, and up to 32 octets (256 bits) of bitmap.
-
-   Blocks are present in the NSEC RR RDATA in increasing numerical
-   order.
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
-      where "|" denotes concatenation.
-
-   Each bitmap encodes the low-order 8 bits of RR types within the
-   window block, in network bit order.  The first bit is bit 0.  For
-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
-   to RR type 2 (NS), and so forth.  For window block 1, bit 1
-   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set,
-   it indicates that an RRset of that type is present for the NSEC RR's
-   owner name.  If a bit is clear, it indicates that no RRset of that
-   type is present for the NSEC RR's owner name.
-
-   Bits representing pseudo-types MUST be clear, since they do not
-   appear in zone data.  If encountered, they MUST be ignored upon
-   reading.
-
-   Blocks with no types present MUST NOT be included.  Trailing zero
-   octets in the bitmap MUST be omitted.  The length of each block's
-   bitmap is determined by the type code with the largest numerical
-   value, within that block, among the set of RR types present at the
-   NSEC RR's owner name.  Trailing zero octets not specified MUST be
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 15]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   interpreted as zero octets.
-
-   The bitmap for the NSEC RR at a delegation point requires special
-   attention.  Bits corresponding to the delegation NS RRset and the RR
-   types for which the parent zone has authoritative data MUST be set;
-   bits corresponding to any non-NS RRset for which the parent is not
-   authoritative MUST be clear.
-
-   A zone MUST NOT include an NSEC RR for any domain name that only
-   holds glue records.
-
-4.1.3  Inclusion of Wildcard Names in NSEC RDATA
-
-   If a wildcard owner name appears in a zone, the wildcard label ("*")
-   is treated as a literal symbol and is treated the same as any other
-   owner name for purposes of generating NSEC RRs.  Wildcard owner names
-   appear in the Next Domain Name field without any wildcard expansion.
-   [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards
-   on authenticated denial of existence.
-
-4.2  The NSEC RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Next Domain Name field is represented as a domain name.
-
-   The Type Bit Maps field is represented as a sequence of RR type
-   mnemonics.  When the mnemonic is not known, the TYPE representation
-   as described in [RFC3597] (section 5) MUST be used.
-
-4.3  NSEC RR Example
-
-   The following NSEC RR identifies the RRsets associated with
-   alfa.example.com.  and identifies the next authoritative name after
-   alfa.example.com.
-
-   alfa.example.com. 86400 IN NSEC host.example.com. (
-                                   A MX RRSIG NSEC TYPE1234 )
-
-   The first four text fields specify the name, TTL, Class, and RR type
-   (NSEC).  The entry host.example.com.  is the next authoritative name
-   after alfa.example.com.  in canonical order.  The A, MX, RRSIG, NSEC,
-   and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
-   TYPE1234 RRsets associated with the name alfa.example.com.
-
-   The RDATA section of the NSEC RR above would be encoded as:
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 16]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-            0x04 'h'  'o'  's'  't'
-            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
-            0x03 'c'  'o'  'm'  0x00
-            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
-            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x20
-
-   Assuming that the validator can authenticate this NSEC record, it
-   could be used to prove that beta.example.com does not exist, or could
-   be used to prove there is no AAAA record associated with
-   alfa.example.com.  Authenticated denial of existence is discussed in
-   [I-D.ietf-dnsext-dnssec-protocol].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 17]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-5.  The DS Resource Record
-
-   The DS Resource Record refers to a DNSKEY RR and is used in the DNS
-   DNSKEY authentication process.  A DS RR refers to a DNSKEY RR by
-   storing the key tag, algorithm number, and a digest of the DNSKEY RR.
-   Note that while the digest should be sufficient to identify the
-   public key, storing the key tag and key algorithm helps make the
-   identification process more efficient.  By authenticating the DS
-   record, a resolver can authenticate the DNSKEY RR to which the DS
-   record points.  The key authentication process is described in
-   [I-D.ietf-dnsext-dnssec-protocol].
-
-   The DS RR and its corresponding DNSKEY RR have the same owner name,
-   but they are stored in different locations.  The DS RR appears only
-   on the upper (parental) side of a delegation, and is authoritative
-   data in the parent zone.  For example, the DS RR for "example.com" is
-   stored in the "com" zone (the parent zone) rather than in the
-   "example.com" zone (the child zone).  The corresponding DNSKEY RR is
-   stored in the "example.com" zone (the child zone).  This simplifies
-   DNS zone management and zone signing, but introduces special response
-   processing requirements for the DS RR; these are described in
-   [I-D.ietf-dnsext-dnssec-protocol].
-
-   The type number for the DS record is 43.
-
-   The DS resource record is class independent.
-
-   The DS RR has no special TTL requirements.
-
-5.1  DS RDATA Wire Format
-
-   The RDATA for a DS RR consists of a 2 octet Key Tag field, a one
-   octet Algorithm field, a one octet Digest Type field, and a Digest
-   field.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |           Key Tag             |  Algorithm    |  Digest Type  |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Digest                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 18]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-5.1.1  The Key Tag Field
-
-   The Key Tag field lists the key tag of the DNSKEY RR referred to by
-   the DS record, in network byte order.
-
-   The Key Tag used by the DS RR is identical to the Key Tag used by
-   RRSIG RRs.  Appendix B describes how to compute a Key Tag.
-
-5.1.2  The Algorithm Field
-
-   The Algorithm field lists the algorithm number of the DNSKEY RR
-   referred to by the DS record.
-
-   The algorithm number used by the DS RR is identical to the algorithm
-   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
-   algorithm number types.
-
-5.1.3  The Digest Type Field
-
-   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
-   RR.  The Digest Type field identifies the algorithm used to construct
-   the digest.  Appendix A.2 lists the possible digest algorithm types.
-
-5.1.4  The Digest Field
-
-   The DS record refers to a DNSKEY RR by including a digest of that
-   DNSKEY RR.
-
-   The digest is calculated by concatenating the canonical form of the
-   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
-   and then applying the digest algorithm.
-
-     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
-
-      "|" denotes concatenation
-
-     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
-
-
-   The size of the digest may vary depending on the digest algorithm and
-   DNSKEY RR size.  As of the time of writing, the only defined digest
-   algorithm is SHA-1, which produces a 20 octet digest.
-
-5.2  Processing of DS RRs When Validating Responses
-
-   The DS RR links the authentication chain across zone boundaries, so
-   the DS RR requires extra care in processing.  The DNSKEY RR referred
-   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 19]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
-   zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in
-   the validation process.
-
-5.3  The DS RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Key Tag field MUST be represented as an unsigned decimal integer.
-
-   The Algorithm field MUST be represented either as an unsigned decimal
-   integer or as an algorithm mnemonic specified in Appendix A.1.
-
-   The Digest Type field MUST be represented as an unsigned decimal
-   integer.
-
-   The Digest MUST be represented as a sequence of case-insensitive
-   hexadecimal digits.  Whitespace is allowed within the hexadecimal
-   text.
-
-5.4  DS RR Example
-
-   The following example shows a DNSKEY RR and its corresponding DS RR.
-
-   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
-                                             fwJr1AYtsmx3TGkJaNXVbfi/
-                                             2pHm822aJ5iI9BMzNXxeYCmZ
-                                             DRD99WYwYqUSdjMmmAphXdvx
-                                             egXd/M5+X7OrzKBaMbCVdFLU
-                                             Uh6DhweJBjEVv5f2wwjM9Xzc
-                                             nOf+EPbtG9DMBmADjFDc2w/r
-                                             ljwvFw==
-                                             ) ;  key id = 60485
-
-   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
-                                              98631FAD1A292118 )
-
-
-   The first four text fields specify the name, TTL, Class, and RR type
-   (DS).  Value 60485 is the key tag for the corresponding
-   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
-   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
-   algorithm used to construct the digest, and the rest of the RDATA
-   text is the digest in hexadecimal.
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 20]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-6.  Canonical Form and Order of Resource Records
-
-   This section defines a canonical form for resource records, a
-   canonical ordering of DNS names, and a canonical ordering of resource
-   records within an RRset.  A canonical name order is required to
-   construct the NSEC name chain.  A canonical RR form and ordering
-   within an RRset are required to construct and verify RRSIG RRs.
-
-6.1  Canonical DNS Name Order
-
-   For purposes of DNS security, owner names are ordered by treating
-   individual labels as unsigned left-justified octet strings.  The
-   absence of a octet sorts before a zero value octet, and upper case
-   US-ASCII letters are treated as if they were lower case US-ASCII
-   letters.
-
-   To compute the canonical ordering of a set of DNS names, start by
-   sorting the names according to their most significant (rightmost)
-   labels.  For names in which the most significant label is identical,
-   continue sorting according to their next most significant label, and
-   so forth.
-
-   For example, the following names are sorted in canonical DNS name
-   order.  The most significant label is "example".  At this level,
-   "example" sorts first, followed by names ending in "a.example", then
-   names ending "z.example".  The names within each level are sorted in
-   the same way.
-
-             example
-             a.example
-             yljkjljk.a.example
-             Z.a.example
-             zABC.a.EXAMPLE
-             z.example
-             \001.z.example
-             *.z.example
-             \200.z.example
-
-
-6.2  Canonical RR Form
-
-   For purposes of DNS security, the canonical form of an RR is the wire
-   format of the RR where:
-   1.  Every domain name in the RR is fully expanded (no DNS name
-       compression) and fully qualified;
-   2.  All uppercase US-ASCII letters in the owner name of the RR are
-       replaced by the corresponding lowercase US-ASCII letters;
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 21]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   3.  If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
-       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
-       SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in
-       the DNS names contained within the RDATA are replaced by the
-       corresponding lowercase US-ASCII letters;
-   4.  If the owner name of the RR is a wildcard name, the owner name is
-       in its original unexpanded form, including the "*" label (no
-       wildcard substitution); and
-   5.  The RR's TTL is set to its original value as it appears in the
-       originating authoritative zone or the Original TTL field of the
-       covering RRSIG RR.
-
-6.3  Canonical RR Ordering Within An RRset
-
-   For purposes of DNS security, RRs with the same owner name, class,
-   and type are sorted by treating the RDATA portion of the canonical
-   form of each RR as a left-justified unsigned octet sequence where the
-   absence of an octet sorts before a zero octet.
-
-   [RFC2181] specifies that an RRset is not allowed to contain duplicate
-   records (multiple RRs with the same owner name, class, type, and
-   RDATA).  Therefore, if an implementation detects duplicate RRs when
-   putting the RRset in canonical form, the implementation MUST treat
-   this as a protocol error.  If the implementation chooses to handle
-   this protocol error in the spirit of the robustness principle (being
-   liberal in what it accepts), the implementation MUST remove all but
-   one of the duplicate RR(s) for purposes of calculating the canonical
-   form of the RRset.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 22]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-7.  IANA Considerations
-
-   This document introduces no new IANA considerations, because all of
-   the protocol parameters used in this document have already been
-   assigned by previous specifications.  However, since the evolution of
-   DNSSEC has been long and somewhat convoluted, this section attempts
-   to describe the current state of the IANA registries and other
-   protocol parameters which are (or once were) related to DNSSEC.
-
-   Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA
-   considerations.
-
-   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
-      the SIG, KEY, and NXT RRs, respectively.  [RFC3658] assigned DNS
-      Resource Record Type 43 to DS.  [RFC3755] assigned types 46, 47,
-      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
-      [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted
-      use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
-      security protocol described in [RFC2931] and the transaction KEY
-      Resource Record described in [RFC2930].
-
-   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
-      for DNSSEC Resource Record Algorithm field numbers, and assigned
-      values 1-4 and 252-255.  [RFC3110] assigned value 5.  [RFC3755]
-      altered this registry to include flags for each entry regarding
-      its use with the DNS security extensions.  Each algorithm entry
-      could refer to an algorithm that can be used for zone signing,
-      transaction security (see [RFC2931]) or both.  Values 6-251 are
-      available for assignment by IETF standards action.  See Appendix A
-      for a full listing of the DNS Security Algorithm Numbers entries
-      at the time of writing and their status of use in DNSSEC.
-
-      [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
-      assigned value 0 to reserved and value 1 to SHA-1.
-
-   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
-      Protocol Values, but [RFC3445] re-assigned all values other than 3
-      to reserved and closed this IANA registry.  The registry remains
-      closed, and all KEY and DNSKEY records are required to have
-      Protocol Octet value of 3.
-
-   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
-      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,
-      this registry only contains an assignment for bit 7 (the ZONE bit)
-      and a reservation for bit 15 for the Secure Entry Point flag (SEP
-      bit) [RFC3757].  Bits 0-6 and 8-14 are available for assignment by
-      IETF Standards Action.
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 23]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-8.  Security Considerations
-
-   This document describes the format of four DNS resource records used
-   by the DNS security extensions, and presents an algorithm for
-   calculating a key tag for a public key.  Other than the items
-   described below, the resource records themselves introduce no
-   security considerations.  Please see [I-D.ietf-dnsext-dnssec-intro]
-   and [I-D.ietf-dnsext-dnssec-protocol] for additional security
-   considerations related to the use of these records.
-
-   The DS record points to a DNSKEY RR using a cryptographic digest, the
-   key algorithm type and a key tag.  The DS record is intended to
-   identify an existing DNSKEY RR, but it is theoretically possible for
-   an attacker to generate a DNSKEY that matches all the DS fields.  The
-   probability of constructing such a matching DNSKEY depends on the
-   type of digest algorithm in use.  The only currently defined digest
-   algorithm is SHA-1, and the working group believes that constructing
-   a public key which would match the algorithm, key tag, and SHA-1
-   digest given in a DS record would be a sufficiently difficult problem
-   that such an attack is not a serious threat at this time.
-
-   The key tag is used to help select DNSKEY resource records
-   efficiently, but it does not uniquely identify a single DNSKEY
-   resource record.  It is possible for two distinct DNSKEY RRs to have
-   the same owner name, the same algorithm type, and the same key tag.
-   An implementation which uses only the key tag to select a DNSKEY RR
-   might select the wrong public key in some circumstances.
-
-   The table of algorithms in Appendix A and the key tag calculation
-   algorithms in Appendix B include the RSA/MD5 algorithm for
-   completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
-   explained in [RFC3110].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 24]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-9.  Acknowledgments
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group and working group mailing list.  The
-   editors would like to express their thanks for the comments and
-   suggestions received during the revision of these security extension
-   specifications.  While explicitly listing everyone who has
-   contributed during the decade during which DNSSEC has been under
-   development would be an impossible task,
-   [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
-   participants who were kind enough to comment on these documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 25]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-10.  References
-
-10.1  Normative References
-
-   [I-D.ietf-dnsext-dnssec-intro]
-              Arends, R., Austein, R., Larson, M., Massey, D. and S.
-              Rose, "DNS Security Introduction and Requirements",
-              draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
-              2004.
-
-   [I-D.ietf-dnsext-dnssec-protocol]
-              Arends, R., Austein, R., Larson, M., Massey, D. and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
-              progress), May 2004.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              August 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
-              SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 26]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-              Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 3548, July 2003.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer", RFC 3755, April 2004.
-
-   [RFC3757]  Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
-              Entry Point Flag", RFC 3757, April 2004.
-
-10.2  Informative References
-
-   [I-D.ietf-dnsext-nsec-rdata]
-              Schlyter, J., "DNSSEC NSEC RDATA Format",
-              draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
-              2004.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Drienerlolaan 5
-   7522 NB  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 27]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Dan Massey
-   USC Information Sciences Institute
-   3811 N. Fairfax Drive
-   Arlington, VA  22203
-   USA
-
-   EMail: masseyd@isi.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 28]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-Appendix A.  DNSSEC Algorithm and Digest Types
-
-   The DNS security extensions are designed to be independent of the
-   underlying cryptographic algorithms.  The DNSKEY, RRSIG, and DS
-   resource records all use a DNSSEC Algorithm Number to identify the
-   cryptographic algorithm in use by the resource record.  The DS
-   resource record also specifies a Digest Algorithm Number to identify
-   the digest algorithm used to construct the DS record.  The currently
-   defined Algorithm and Digest Types are listed below.  Additional
-   Algorithm or Digest Types could be added as advances in cryptography
-   warrant.
-
-   A DNSSEC aware resolver or name server MUST implement all MANDATORY
-   algorithms.
-
-A.1  DNSSEC Algorithm Types
-
-   The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify
-   the security algorithm being used.  These values are stored in the
-   "Algorithm number" field in the resource record RDATA.
-
-   Some algorithms are usable only for zone signing (DNSSEC), some only
-   for transaction security mechanisms (SIG(0) and TSIG), and some for
-   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and
-   DS RRs.  Those usable for transaction security would be present in
-   SIG(0) and KEY RRs as described in [RFC2931]
-
-                                Zone
-   Value Algorithm [Mnemonic]  Signing  References   Status
-   ----- -------------------- --------- ----------  ---------
-     0   reserved
-     1   RSA/MD5 [RSAMD5]         n      RFC 2537   NOT RECOMMENDED
-     2   Diffie-Hellman [DH]      n      RFC 2539    -
-     3   DSA/SHA-1 [DSA]          y      RFC 2536   OPTIONAL
-     4   Elliptic Curve [ECC]              TBA       -
-     5   RSA/SHA-1 [RSASHA1]      y      RFC 3110   MANDATORY
-   252   Indirect [INDIRECT]      n                  -
-   253   Private [PRIVATEDNS]     y      see below  OPTIONAL
-   254   Private [PRIVATEOID]     y      see below  OPTIONAL
-   255   reserved
-
-   6 - 251  Available for assignment by IETF Standards Action.
-
-A.1.1  Private Algorithm Types
-
-   Algorithm number 253 is reserved for private use and will never be
-   assigned to a specific algorithm.  The public key area in the DNSKEY
-   RR and the signature area in the RRSIG RR begin with a wire encoded
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 29]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   domain name, which MUST NOT be compressed.  The domain name indicates
-   the private algorithm to use and the remainder of the public key area
-   is determined by that algorithm.  Entities should only use domain
-   names they control to designate their private algorithms.
-
-   Algorithm number 254 is reserved for private use and will never be
-   assigned to a specific algorithm.  The public key area in the DNSKEY
-   RR and the signature area in the RRSIG RR begin with an unsigned
-   length byte followed by a BER encoded Object Identifier (ISO OID) of
-   that length.  The OID indicates the private algorithm in use and the
-   remainder of the area is whatever is required by that algorithm.
-   Entities should only use OIDs they control to designate their private
-   algorithms.
-
-A.2  DNSSEC Digest Types
-
-   A "Digest Type" field in the DS resource record types identifies the
-   cryptographic digest algorithm used by the resource record.  The
-   following table lists the currently defined digest algorithm types.
-
-              VALUE   Algorithm                 STATUS
-                0      Reserved                   -
-                1      SHA-1                   MANDATORY
-              2-255    Unassigned                 -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 30]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-Appendix B.  Key Tag Calculation
-
-   The Key Tag field in the RRSIG and DS resource record types provides
-   a mechanism for selecting a public key efficiently.  In most cases, a
-   combination of owner name, algorithm, and key tag can efficiently
-   identify a DNSKEY record.  Both the RRSIG and DS resource records
-   have corresponding DNSKEY records.  The Key Tag field in the RRSIG
-   and DS records can be used to help select the corresponding DNSKEY RR
-   efficiently when more than one candidate DNSKEY RR is available.
-
-   However, it is essential to note that the key tag is not a unique
-   identifier.  It is theoretically possible for two distinct DNSKEY RRs
-   to have the same owner name, the same algorithm, and the same key
-   tag.  The key tag is used to limit the possible candidate keys, but
-   it does not uniquely identify a DNSKEY record.  Implementations MUST
-   NOT assume that the key tag uniquely identifies a DNSKEY RR.
-
-   The key tag is the same for all DNSKEY algorithm types except
-   algorithm 1 (please see Appendix B.1 for the definition of the key
-   tag for algorithm 1).  The key tag algorithm is the sum of the wire
-   format of the DNSKEY RDATA broken into 2 octet groups.  First the
-   RDATA (in wire format) is treated as a series of 2 octet groups,
-   these groups are then added together ignoring any carry bits.
-
-   A reference implementation of the key tag algorithm is as an ANSI C
-   function is given below with the RDATA portion of the DNSKEY RR is
-   used as input.  It is not necessary to use the following reference
-   code verbatim, but the numerical value of the Key Tag MUST be
-   identical to what the reference implementation would generate for the
-   same input.
-
-   Please note that the algorithm for calculating the Key Tag is almost
-   but not completely identical to the familiar ones complement checksum
-   used in many other Internet protocols.  Key Tags MUST be calculated
-   using the algorithm described here rather than the ones complement
-   checksum.
-
-   The following ANSI C reference implementation calculates the value of
-   a Key Tag.  This reference implementation applies to all algorithm
-   types except algorithm 1 (see Appendix B.1).  The input is the wire
-   format of the RDATA portion of the DNSKEY RR.  The code is written
-   for clarity, not efficiency.
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 31]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-   /*
-    * Assumes that int is at least 16 bits.
-    * First octet of the key tag is the most significant 8 bits of the
-    * return value;
-    * Second octet of the key tag is the least significant 8 bits of the
-    * return value.
-    */
-
-   unsigned int
-   keytag (
-           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
-           unsigned int keysize  /* the RDLENGTH */
-          )
-   {
-           unsigned long ac;     /* assumed to be 32 bits or larger */
-           int i;                /* loop index */
-
-           for ( ac = 0, i = 0; i < keysize; ++i )
-                   ac += (i & 1) ? key[i] : key[i] << 8;
-           ac += (ac >> 16) & 0xFFFF;
-           return ac & 0xFFFF;
-   }
-
-
-B.1  Key Tag for Algorithm 1 (RSA/MD5)
-
-   The key tag for algorithm 1 (RSA/MD5) is defined differently than the
-   key tag for all other algorithms, for historical reasons.  For a
-   DNSKEY RR with algorithm 1, the key tag is defined to be the most
-   significant 16 bits of the least significant 24 bits in the public
-   key modulus (in other words, the 4th to last and 3rd to last octets
-   of the public key modulus).
-
-   Please note that Algorithm 1 is NOT RECOMMENDED.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 32]
-
-Internet-Draft          DNSSEC Resource Records                July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Arends, et al.          Expires January 13, 2005               [Page 33]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt
deleted file mode 100644
index 4cfd417804d3..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt
+++ /dev/null
@@ -1,639 +0,0 @@
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-Clarifies STD0013                                  Motorola Laboratories
-Expires December 2004                                          July 2004
-
-
-
-       Domain Name System (DNS) Case Insensitivity Clarification
-       ------ ---- ------ ----- ---- ------------- -------------
-                 <draft-ietf-dnsext-insensitive-04.txt>
-
-                         Donald E. Eastlake 3rd
-
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNSEXT working group at namedroppers@ops.ietf.org.
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026.  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
-
-   Domain Name System (DNS) names are "case insensitive". This document
-   explains exactly what that means and provides a clear specification
-   of the rules. This clarification should not have any interoperability
-   consequences.
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-Acknowledgements
-
-   The contributions to this document of Rob Austein, Olafur
-   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
-   Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully
-   acknowledged.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Acknowledgements...........................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. Case Insensitivity of DNS Labels........................3
-      2.1 Escaping Unusual DNS Label Octets......................3
-      2.2 Example Labels with Escapes............................4
-      3. Name Lookup, Label Types, and CLASS.....................4
-      3.1 Original DNS Label Types...............................5
-      3.2 Extended Label Type Case Insensitivity Considerations..5
-      3.3 CLASS Case Insensitivity Considerations................5
-      4. Case on Input and Output................................6
-      4.1 DNS Output Case Preservation...........................6
-      4.2 DNS Input Case Preservation............................6
-      5. Internationalized Domain Names..........................7
-      6. Security Considerations.................................7
-
-      Copyright and Disclaimer...................................9
-      Normative References.......................................9
-      Informative References....................................10
-      -02 to -03 Changes........................................10
-      -03 to -04 Changes........................................11
-      Author's Address..........................................11
-      Expiration and File Name..................................11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. Each node in the DNS tree has a name consisting of
-   zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
-   case insensitive fashion. This document clarifies the meaning of
-   "case insensitive" for the DNS.
-
-   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. Case Insensitivity of DNS Labels
-
-   DNS was specified in the era of [ASCII]. DNS names were expected to
-   look like most host names or Internet email address right halves (the
-   part after the at-sign, "@") or be numeric as in the in-addr.arpa
-   part of the DNS name space. For example,
-
-       foo.example.net.
-       aol.com.
-       www.gnu.ai.mit.edu.
-   or  69.2.0.192.in-addr.arpa.
-
-   Case varied alternatives to the above would be DNS names like
-
-       Foo.ExamplE.net.
-       AOL.COM.
-       WWW.gnu.AI.mit.EDU.
-   or  69.2.0.192.in-ADDR.ARPA.
-
-   However, the individual octets of which DNS names consist are not
-   limited to valid ASCII character codes. They are 8-bit bytes and all
-   values are allowed. Many applications, however, interpret them as
-   ASCII characters.
-
-
-
-2.1 Escaping Unusual DNS Label Octets
-
-   In Master Files [STD 13] and other human readable and writable ASCII
-   contexts, an escape is needed for the byte value for period (0x2E,
-   ".") and all octet values outside of the inclusive range of 0x21
-   ("!")  to 0x7E ("~"). That is to say, 0x2E and all octet values in
-   the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
-
-   One typographic convention for octets that do not correspond to an
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-   ASCII printing graphic is to use a back-slash followed by the value
-   of the octet as an unsigned integer represented by exactly three
-   decimal digits.
-
-   The same convention can be used for printing ASCII characters so that
-   they will be treated as a normal label character.  This includes the
-   back-slash character used in this convention itself which can be
-   expressed as \092 or \\ and the special label separator period (".")
-   which can be expressed as and \046 or \.  respectively. It is
-   advisable to avoid using a backslash to quote an immediately
-   following non-printing ASCII character code to avoid implementation
-   difficulties.
-
-   A back-slash followed by only one or two decimal digits is undefined.
-   A back-slash followed by four decimal digits produces two octets, the
-   first octet having the value of the first three digits considered as
-   a decimal number and the second octet being the character code for
-   the fourth decimal digit.
-
-
-
-2.2 Example Labels with Escapes
-
-   The first example below shows embedded spaces and a period (".")
-   within a label. The second one show a 5 octet label where the second
-   octet has all bits zero, the third is a backslash, and the fourth
-   octet has all bits one.
-
-         Donald\032E\.\032Eastlake\0323rd.example.
-   and   a\000\\\255z.example.
-
-
-
-3. Name Lookup, Label Types, and CLASS
-
-   The design decision was made that comparisons on name lookup for DNS
-   queries should be case insensitive [STD 13]. That is to say, a lookup
-   string octet with a value in the inclusive range of 0x41 to 0x5A, the
-   upper case ASCII letters, MUST match the identical value and also
-   match the corresponding value in the inclusive range 0x61 to 0x7A,
-   the lower case ASCII letters. And a lookup string octet with a lower
-   case ASCII letter value MUST similarly match the identical value and
-   also match the corresponding value in the upper case ASCII letter
-   range.
-
-   (Historical Note: the terms "upper case" and "lower case" were
-   invented after movable type.  The terms originally referred to the
-   two font trays for storing, in partitioned areas, the different
-   physical type elements.  Before movable type, the nearest equivalent
-   terms were "majuscule" and "minuscule".)
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-   One way to implement this rule would be, when comparing octets, to
-   subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
-   before the comparison. Such an operation is commonly known as "case
-   folding" but implementation via case folding is not required. Note
-   that the DNS case insensitivity does NOT correspond to the case
-   folding specified in iso-8859-1 or iso-8859-2. For example, the
-   octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
-   contexts, where they are interpreted as the upper and lower case
-   version of "Y" with an acute accent, they might.
-
-
-
-3.1 Original DNS Label Types
-
-   DNS labels in wire encoded names have a type associated with them.
-   The original DNS standard [RFC 1035] had only two types. ASCII
-   labels, with a length of from zero to 63 octets, and indirect labels
-   which consist of an offset pointer to a name location elsewhere in
-   the wire encoding on a DNS message. (The ASCII label of length zero
-   is reserved for use as the name of the root node of the name tree.)
-   ASCII labels follow the ASCII case conventions described herein and,
-   as stated above, can actually contain arbitrary byte values. Indirect
-   labels are, in effect, replaced by the name to which they point which
-   is then treated with the case insensitivity rules in this document.
-
-
-
-3.2 Extended Label Type Case Insensitivity Considerations
-
-   DNS was extended by [RFC 2671] to have additional label type numbers
-   available. (The only such type defined so far is the BINARY type [RFC
-   2673].)
-
-   The ASCII case insensitivity conventions only apply to ASCII labels,
-   that is to say, label type 0x0, whether appearing directly or invoked
-   by indirect labels.
-
-
-
-3.3 CLASS Case Insensitivity Considerations
-
-   As described in [STD 13] and [RFC 2929], DNS has an additional axis
-   for data location called CLASS. The only CLASS in global use at this
-   time is the "IN" or Internet CLASS.
-
-   The handling of DNS label case is not CLASS dependent.
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-4. Case on Input and Output
-
-   While ASCII label comparisons are case insensitive, [STD 13] says
-   case MUST be preserved on output, and preserved when convenient on
-   input. However, this means less than it would appear since the
-   preservation of case on output is NOT required when output is
-   optimized by the use of indirect labels, as explained below.
-
-
-
-4.1 DNS Output Case Preservation
-
-   [STD 13] views the DNS namespace as a node tree. ASCII output is as
-   if a name was marshaled by taking the label on the node whose name is
-   to be output, converting it to a typographically encoded ASCII
-   string, walking up the tree outputting each label encountered, and
-   preceding all labels but the first with a period ("."). Wire output
-   follows the same sequence but each label is wire encoded and no
-   periods inserted. No "case conversion" or "case folding" is done
-   during such output operations, thus "preserving" case.  However, to
-   optimize output, indirect labels may be used to point to names
-   elsewhere in the DNS answer. In determining whether the name to be
-   pointed to, for example the QNAME, is the "same" as the remainder of
-   the name being optimized, the case insensitive comparison specified
-   above is done. Thus such optimization MAY easily destroy the output
-   preservation of case. This type of optimization is commonly called
-   "name compression".
-
-
-
-4.2 DNS Input Case Preservation
-
-   Originally, DNS input came from an ASCII Master File as defined in
-   [STD 13] or a zone transfer.  DNS Dynamic update and incremental zone
-   transfers [RFC 1995] have been added as a source of DNS data [RFC
-   2136, 3007]. When a node in the DNS name tree is created by any of
-   such inputs, no case conversion is done. Thus the case of ASCII
-   labels is preserved if they are for nodes being created. However,
-   when a name label is input for a node that already exist in DNS data
-   being held, the situation is more complex. Implementations may retain
-   the case first input for such a label or allow new input to override
-   the old case or even maintain separate copies preserving the input
-   case.
-
-   For example, if data with owner name "foo.bar.example" is input and
-   then later data with owner name "xyz.BAR.example" is input, the name
-   of the label on the "bar.example" node, i.e. "bar", might or might
-   not be changed to "BAR" or the actual input case could be preserved.
-   Thus later retrieval of data stored under "xyz.bar.example" in this
-   case can easily return data with "xyz.BAR.example".  The same
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-   considerations apply when inputting multiple data records with owner
-   names differing only in case. For example, if an "A" record is stored
-   as the first resourced record under owner name "xyz.BAR.example" and
-   then a second "A" record is stored under "XYZ.BAR.example", the
-   second MAY be stored with the first (lower case initial label) name
-   or the second MAY override the first so that only an upper case
-   initial label is retained or both capitalizations MAY be kept.
-
-   Note that the order of insertion into a server database of the DNS
-   name tree nodes that appear in a Master File is not defined so that
-   the results of inconsistent capitalization in a Master File are
-   unpredictable output capitalization.
-
-
-
-5. Internationalized Domain Names
-
-   A scheme has been adopted for "internationalized domain names" and
-   "internationalized labels" as described in [RFC 3490, 3454, 3491, and
-   3492]. It makes most of [UNICODE] available through a separate
-   application level transformation from internationalized domain name
-   to DNS domain name and from DNS domain name to internationalized
-   domain name. Any case insensitivity that internationalized domain
-   names and labels have varies depending on the script and is handled
-   entirely as part of the transformation described in [RFC 3454] and
-   [RFC 3491] which should be seen for further details.  This is not a
-   part of the DNS as standardized in STD 13.
-
-
-
-6. Security Considerations
-
-   The equivalence of certain DNS label types with case differences, as
-   clarified in this document, can lead to security problems. For
-   example, a user could be confused by believing two domain names
-   differing only in case were actually different names.
-
-   Furthermore, a domain name may be used in contexts other than the
-   DNS.  It could be used as a case sensitive index into some data base
-   system. Or it could be interpreted as binary data by some integrity
-   or authentication code system. These problems can usually be handled
-   by using a standardized or "canonical" form of the DNS ASCII type
-   labels, that is, always mapping the ASCII letter value octets in
-   ASCII labels to some specific pre-chosen case, either upper case or
-   lower case. An example of a canonical form for domain names (and also
-   a canonical ordering for them) appears in Section 8 of [RFC 2535].
-   See also [RFC 3597].
-
-   Finally, a non-DNS name may be stored into DNS with the false
-   expectation that case will always be preserved. For example, although
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-   this would be quite rare, on a system with case sensitive email
-   address local parts, an attempt to store two "RP" records that
-   differed only in case would probably produce unexpected results that
-   might have security implications. That is because the entire email
-   address, including the possibly case sensitive local or left hand
-   part, is encoded into a DNS name in a readable fashion where the case
-   of some letters might be changed on output as described above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society 2004.  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78, and except
-   as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-
-Normative References
-
-   [ASCII] - ANSI, "USA Standard Code for Information Interchange",
-   X3.4, American National Standards Institute: New York, 1968.
-
-   [RFC 1034, 1035] - See [STD 13].
-
-   [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
-   1996.
-
-   [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
-   Requirement Levels", March 1997.
-
-   [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
-   "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
-
-   [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
-   March 1999.
-
-   [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
-   Update", November 2000.
-
-   [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
-   draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
-
-   [STD 13]
-       - P. Mockapetris, "Domain names - concepts and facilities", RFC
-   1034, November 1987.
-       - P. Mockapetris, "Domain names - implementation and
-   specification", RFC 1035, November 1987.
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
-Informative References
-
-   [RFC 1591] - J. Postel, "Domain Name System Structure and
-   Delegation", March 1994.
-
-   [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
-   June 1999.
-
-   [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
-   Name System (DNS) IANA Considerations", September 2000.
-
-   [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
-   1999.
-
-   [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
-   August 1999.
-
-   [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
-   Foo", 1 April 2001.
-
-   [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
-   Internationalized String ("stringprep")", December 2002.
-
-   [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
-   "Internationalizing Domain Names in Applications (IDNA)", March 2003.
-
-   [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
-   for Internationalized Domain Names (IDN)", March 2003.
-
-   [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
-   for Internationalized Domain Names in Applications (IDNA)", March
-   2003.
-
-   [UNICODE] - The Unicode Consortium, "The Unicode Standard",
-   <http://www.unicode.org/unicode/standard/standard.html>.
-
-
-
--02 to -03 Changes
-
-   The following changes were made between draft version -02 and -03:
-
-   1. Add internationalized domain name section and references.
-
-   2. Change to indicate that later input of a label for an existing DNS
-   name tree node may or may not be normalized to the earlier input or
-   override it or both may be preserved.
-
-   3. Numerous minor wording changes.
-
-
-
-D. Eastlake 3rd                                                [Page 10]
-
-
-INTERNET-DRAFT                                    DNS Case Insensitivity
-
-
--03 to -04 Changes
-
-   The following changes were made between draft version -03 and -04:
-
-   1. Change to conform to the new IPR, Copyright, etc., notice
-   requirements.
-
-   2. Change in some section headers for clarity.
-
-   3. Drop section on wildcards.
-
-   4. Add emphasis on loss of case preservation due to name compression.
-
-   5. Add references to RFCs 1995 and 3092.
-
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1 508-786-7554 (w)
-                +1 508-634-2066 (h)
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires December 2004.
-
-   Its file name is draft-ietf-dnsext-insensitive-04.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 11]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt
deleted file mode 100644
index 123d3cc09611..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt
+++ /dev/null
@@ -1,335 +0,0 @@
-
-DNS Extensions Working Group                                 J. Schlyter
-Internet-Draft                                           August 24, 2004
-Expires: February 22, 2005
-
-
-                     RFC 3597 Interoperability Report
-                   draft-ietf-dnsext-interop3597-01.txt
-
-Status of this Memo
-
-    By submitting this Internet-Draft, I certify that any applicable
-    patent or other IPR claims of which I am aware have been disclosed,
-    and any of which I become aware will be disclosed, in accordance with
-    RFC 3667.
-
-    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.
-
-    This Internet-Draft will expire on February 22, 2005.
-
-Copyright Notice
-
-    Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 1]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-Table of Contents
-
-    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-    2.  Implementations  . . . . . . . . . . . . . . . . . . . . . . .  3
-    3.  Tests  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-    3.1 Authoritative Primary Name Server  . . . . . . . . . . . . . .  3
-    3.2 Authoritative Secondary Name Server  . . . . . . . . . . . . .  3
-    3.3 Full Recursive Resolver  . . . . . . . . . . . . . . . . . . .  3
-    3.4 Stub Resolver  . . . . . . . . . . . . . . . . . . . . . . . .  3
-    3.5 DNSSEC Signer  . . . . . . . . . . . . . . . . . . . . . . . .  4
-    4.  Problems found . . . . . . . . . . . . . . . . . . . . . . . .  4
-    5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-        Normative References . . . . . . . . . . . . . . . . . . . . .  4
-        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
-    A.  Test zone data . . . . . . . . . . . . . . . . . . . . . . . .  5
-        Intellectual Property and Copyright Statements . . . . . . . .  6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 2]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-1. Introduction
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.  The test was
-    performed during June and July 2004 by request of the IETF DNS
-    Extensions Working Group.
-
-2. Implementations
-
-    The following is a list, in alphabetic order, of implementations for
-    compliance of RFC 3597:
-
-       DNSJava 1.6.4
-       ISC BIND 8.4.5rc4
-       ISC BIND 9.3.0rc2
-       NSD 2.1.1
-       Net::DNS 0.47 patchlevel 1
-       Nominum ANS 2.2.1.0.d
-
-    These implementations covers the following functions (number of
-    implementations tested for each function in paranthesis):
-
-       Authoritative Name Servers (4)
-       Full Recursive Resolver (2)
-       Stub Resolver (4)
-       DNSSEC Zone Signers (2)
-
-3. Tests
-
-3.1 Authoritative Primary Name Server
-
-    The test zone data (Appendix A) was loaded into the name server
-    implementation and the server was queried for the loaded information.
-
-3.2 Authoritative Secondary Name Server
-
-    The test zone data (Appendix A) was transferred using AXFR from
-    another name server implementation and the server was queried for the
-    transferred information.
-
-3.3 Full Recursive Resolver
-
-    A recursive resolver was queried for resource records from a domain
-    with the test zone data (Appendix A).
-
-3.4 Stub Resolver
-
-    A stub resolver was used to query resource records from a domain with
-
-
-
-Schlyter               Expires February 22, 2005                [Page 3]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-    the test zone data (Appendix A).
-
-3.5 DNSSEC Signer
-
-    A DNSSEC signer was used to sign a zone with test zone data (Appendix
-    A).
-
-4. Problems found
-
-    Two implementations had problems with text presentation of zero
-    length RDATA.
-
-    One implementation had problems with text presentation of RR type
-    code and classes >= 4096.
-
-    Bug reports were filed for problems found.
-
-5. Summary
-
-    Unknown type codes works in the tested authoritative servers,
-    recursive resolvers and stub clients.
-
-    No changes are needed to advance RFC 3597 to draft standard.
-
-Normative References
-
-    [1]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-Author's Address
-
-    Jakob Schlyter
-
-    EMail: jakob@rfc.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 4]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-Appendix A. Test zone data
-
-    ; A-record encoded as TYPE1
-    a  TYPE1  \# 4 7f000001
-    a  TYPE1  192.0.2.1
-    a  A      \# 4 7f000002
-
-    ; draft-ietf-secsh-dns-05.txt
-    sshfp  TYPE44  \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
-
-    ; bogus test record (from RFC 3597)
-    type731    TYPE731    \# 6 abcd (
-                               ef 01 23 45 )
-
-    ; zero length RDATA (from RFC 3597)
-    type62347  TYPE62347  \# 0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 5]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-Intellectual Property Statement
-
-    The IETF takes no position regarding the validity or scope of any
-    Intellectual Property Rights or other rights that might be claimed to
-    pertain to the implementation or use of the technology described in
-    this document or the extent to which any license under such rights
-    might or might not be available; nor does it represent that it has
-    made any independent effort to identify any such rights. Information
-    on the IETF's procedures with respect to rights in IETF Documents can
-    be found in BCP 78 and BCP 79.
-
-    Copies of IPR disclosures made to the IETF Secretariat and any
-    assurances of licenses to be made available, or the result of an
-    attempt made to obtain a general license or permission for the use of
-    such proprietary rights by implementers or users of this
-    specification can be obtained from the IETF on-line IPR repository at
-    http://www.ietf.org/ipr.
-
-    The IETF invites any interested party to bring to its attention any
-    copyrights, patents or patent applications, or other proprietary
-    rights that may cover technology that may be required to implement
-    this standard. Please address the information to the IETF at
-    ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-    This document and the information contained herein are provided on an
-    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-    ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
-    Copyright (C) The Internet Society (2004). This document is subject
-    to the rights, licenses and restrictions contained in BCP 78, and
-    except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-    Funding for the RFC Editor function is currently provided by the
-    Internet Society.
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 6]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt
deleted file mode 100644
index 8dcacc8bb9ec..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt
+++ /dev/null
@@ -1,1559 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                        Levon Esibov
-INTERNET-DRAFT                                             Bernard Aboba
-Category: Standards Track                                    Dave Thaler
-<draft-ietf-dnsext-mdns-33.txt>                                Microsoft
-18 July 2004
-
-
-              Linklocal Multicast Name Resolution (LLMNR)
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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.
-
-   This Internet-Draft will expire on January 2, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2004.  All rights reserved.
-
-Abstract
-
-   Today, with the rise of home networking, there are an increasing
-   number of ad-hoc networks operating without a Domain Name System
-   (DNS) server.  The goal of Link-Local Multicast Name Resolution
-   (LLMNR) is to enable name resolution in scenarios in which
-   conventional DNS name resolution is not possible.  LLMNR supports all
-   current and future DNS formats, types and classes, while operating on
-   a separate port from DNS, and with a distinct resolver cache.  Since
-   LLMNR only operates on the local link, it cannot be considered a
-   substitute for DNS.
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 1]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-Table of Contents
-
-1.     Introduction ..........................................    3
-   1.1       Requirements ....................................    4
-   1.2       Terminology .....................................    4
-2.     Name resolution using LLMNR ...........................    4
-   2.1       LLMNR packet format .............................    6
-   2.2       Sender behavior .................................    8
-   2.3       Responder behavior ..............................    8
-   2.4       Unicast queries .................................   11
-   2.5       Off-link detection ..............................   11
-   2.6       Responder responsibilities ......................   12
-   2.7       Retransmission and jitter .......................   13
-   2.8       DNS TTL .........................................   13
-   2.9       Use of the authority and additional sections ....   14
-3.     Usage model ...........................................   14
-   3.1       LLMNR configuration .............................   15
-4.     Conflict resolution ...................................   16
-   4.1       Considerations for multiple interfaces ..........   18
-   4.2       API issues ......................................   19
-5.     Security considerations ...............................   20
-   5.1       Scope restriction ...............................   20
-   5.2       Usage restriction ...............................   21
-   5.3       Cache and port separation .......................   22
-   5.4       Authentication ..................................   22
-6.     IANA considerations ...................................   22
-7.     References ............................................   22
-   7.1       Normative References ............................   22
-   7.2       Informative References ..........................   23
-Acknowledgments ..............................................   24
-Authors' Addresses ...........................................   25
-Intellectual Property Statement ..............................   25
-Disclaimer of Validity .......................................   26
-Full Copyright Statement .....................................   26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 2]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-1.  Introduction
-
-   This document discusses Link Local Multicast Name Resolution (LLMNR),
-   which utilizes the DNS packet format and supports all current and
-   future DNS formats, types and classes.  LLMNR operates on a separate
-   port from the Domain Name System (DNS), with a distinct resolver
-   cache.
-
-   The goal of LLMNR is to enable name resolution in scenarios in which
-   conventional DNS name resolution is not possible.  These include
-   scenarios in which hosts are not configured with the address of a DNS
-   server, where configured DNS servers do not reply to a query, or
-   where they respond with errors, as described in Section 2.  Since
-   LLMNR only operates on the local link, it cannot be considered a
-   substitute for DNS.
-
-   Link-scope multicast addresses are used to prevent propagation of
-   LLMNR traffic across routers, potentially flooding the network.
-   LLMNR queries can also be sent to a unicast address, as described in
-   Section 2.4.
-
-   Propagation of LLMNR packets on the local link is considered
-   sufficient to enable name resolution in small networks.  The
-   assumption is that if a network has a gateway, then the network is
-   able to provide DNS server configuration.   Configuration issues are
-   discussed in Section 3.1.
-
-   In the future, it may be desirable to consider use of multicast name
-   resolution with multicast scopes beyond the link-scope.  This could
-   occur if LLMNR deployment is successful, the need arises for
-   multicast name resolution beyond the link-scope, or multicast routing
-   becomes ubiquitous.  For example, expanded support for multicast name
-   resolution might be required for mobile ad-hoc networking scenarios,
-   or where no DNS server is available that is authoritative for the
-   names of local hosts, and can support dynamic DNS, such as in
-   wireless hotspots.
-
-   Once we have experience in LLMNR deployment in terms of
-   administrative issues, usability and impact on the network, it will
-   be possible to reevaluate which multicast scopes are appropriate for
-   use with multicast name resolution.
-
-   Service discovery in general, as well as discovery of DNS servers
-   using LLMNR in particular, is outside of the scope of this document,
-   as is name resolution over non-multicast capable media.
-
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 3]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-1.1.  Requirements
-
-   In this document, several words are used to signify the requirements
-   of the specification.  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
-   [RFC2119].
-
-1.2.  Terminology
-
-   This document assumes familiarity with DNS terminology defined in
-   [RFC1035].  Other terminology used in this document includes:
-
-Positively Resolved
-     Responses with RCODE set to zero are referred to in this document
-     as "positively resolved".
-
-Routable Address
-     An address other than a Link-Local address.  This includes globally
-     routable addresses, as well as private addresses.
-
-Reachable
-     An address is considered reachable over a link if either an ARP or
-     neighbor discovery cache entry exists for the address on the link.
-
-Responder
-     A host that listens to LLMNR queries, and responds to those for
-     which it is authoritative.
-
-Sender
-     A host that sends an LLMNR query.
-
-2.  Name resolution using LLMNR
-
-   LLMNR is a peer-to-peer name resolution protocol that is not intended
-   as a replacement for DNS.  LLMNR queries are sent to and received on
-   port 5355.  IPv4 administratively scoped multicast usage is specified
-   in "Administratively Scoped IP Multicast" [RFC2365].  The IPv4 link-
-   scope multicast address a given responder listens to, and to which a
-   sender sends queries, is 224.0.0.252.  The IPv6 link-scope multicast
-   address a given responder listens to, and to which a sender sends all
-   queries, is FF02:0:0:0:0:0:1:3.
-
-   Typically a host is configured as both an LLMNR sender and a
-   responder.  A host MAY be configured as a sender, but not a
-   responder.  However, a host configured as a responder MUST act as a
-   sender to verify the uniqueness of names as described in Section 4.
-   This document does not specify how names are chosen or configured.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 4]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   This may occur via any mechanism, including DHCPv4 [RFC2131] or
-   DHCPv6 [RFC3315].
-
-   LLMNR usage MAY be configured manually or automatically on a per
-   interface basis.  By default, LLMNR responders SHOULD be enabled on
-   all interfaces, at all times.  Enabling LLMNR for use in situations
-   where a DNS server has been configured will result in a change in
-   default behavior without a simultaneous update to configuration
-   information. Where this is considered undesirable, LLMNR SHOULD NOT
-   be enabled by default, so that hosts will neither listen on the link-
-   scope multicast address, nor will they send queries to that address.
-
-   An LLMNR sender may send a request for any name.  However, by
-   default, LLMNR requests SHOULD be sent only when one of the following
-   conditions are met:
-
-   [1] No manual or automatic DNS configuration has been
-       performed.  If an interface has been configured with DNS
-       server address(es),  then LLMNR SHOULD NOT be used as the
-       primary name resolution mechanism on that interface, although
-       it MAY be used as a name resolution mechanism of last resort.
-
-   [2] DNS servers do not respond.
-
-   [3] DNS servers respond to a DNS query with RCODE=3
-       (Authoritative Name Error) or RCODE=0, and an empty
-       answer section.
-
-   A typical sequence of events for LLMNR usage is as follows:
-
-   [a]  DNS servers are not configured or do not respond to a
-        DNS query, or respond with RCODE=3, or RCODE=0 and an
-        empty answer section.
-
-   [b]  An LLMNR sender sends an LLMNR query to the link-scope
-        multicast address(es) defined in Section 2, unless a
-        unicast query is indicated.  A sender SHOULD send LLMNR
-        queries for PTR RRs via unicast, as specified in Section 2.4.
-
-   [c]  A responder responds to this query only if it is authoritative
-        for the domain name in the query.  A responder responds to a
-        multicast query by sending a unicast UDP response to the sender.
-        Unicast queries are responded to as indicated in Section 2.4.
-
-   [d]  Upon reception of the response, the sender processes it.
-
-   Further details of sender and responder behavior are provided in the
-   sections that follow.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 5]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-2.1.  LLMNR packet format
-
-   LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4
-   for both queries and responses.  LLMNR implementations SHOULD send
-   UDP queries and responses only as large as are known to be
-   permissible without causing fragmentation.  When in doubt a maximum
-   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
-   accept UDP queries and responses as large as permitted by the link
-   MTU.
-
-2.1.1.  LLMNR header format
-
-   LLMNR queries and responses utilize the DNS header format defined in
-   [RFC1035] with exceptions noted below:
-
-                                   1  1  1  1  1  1
-     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                      ID                       |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |QR|   Opcode  | Z|TC| Z| Z| Z| Z| Z|   RCODE   |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    QDCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ANCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    NSCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ARCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-ID   A 16 bit identifier assigned by the program that generates any kind
-     of query.  This identifier is copied from the query to the response
-     and can be used by the sender to match responses to outstanding
-     queries. The ID field in a query SHOULD be set to a pseudo-random
-     value.
-
-QR   A one bit field that specifies whether this message is an LLMNR
-     query (0), or an LLMNR response (1).
-
-OPCODE
-     A four bit field that specifies the kind of query in this message.
-     This value is set by the originator of a query and copied into the
-     response.  This specification defines the behavior of standard
-     queries and responses (opcode value of zero).  Future
-     specifications may define the use of other opcodes with LLMNR.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 6]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-     LLMNR senders and responders MUST support standard queries (opcode
-     value of zero).  LLMNR queries with unsupported OPCODE values MUST
-     be silently discarded by responders.
-
-TC   TrunCation - specifies that this message was truncated due to
-     length greater than that permitted on the transmission channel.
-     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
-     by an LLMNR responder.  If the TC bit is set an LLMNR response,
-     then the sender MAY use the response if it contains all necessary
-     information, or the sender MAY discard the response and resend the
-     LLMNR query over TCP using the unicast address of the responder as
-     the destination address.  See  [RFC2181] and Section 2.4 of this
-     specification for further discussion of the TC bit.
-
-Z    Reserved for future use.  Implementations of this specification
-     MUST set these bits to zero in both queries and responses.  If
-     these bits are set in a LLMNR query or response, implementations of
-     this specification MUST ignore them.  Since reserved bits could
-     conceivably be used for different purposes than in DNS,
-     implementors are advised not to enable processing of these bits in
-     an LLMNR implementation starting from a DNS code base.
-
-RCODE
-     Response code -- this 4 bit field is set as part of LLMNR
-     responses.  In an LLMNR query, the RCODE MUST be zero, and is
-     ignored by the responder.  The response to a multicast LLMNR query
-     MUST have RCODE set to zero.  A sender MUST silently discard an
-     LLMNR response with a non-zero RCODE sent in response to a
-     multicast query.
-
-     If an LLMNR responder is authoritative for the name in a multicast
-     query, but an error is encountered, the responder SHOULD send an
-     LLMNR response with an RCODE of zero, no RRs in the answer section,
-     and the TC bit set.  This will cause the query to be resent using
-     TCP, and allow the inclusion of a non-zero RCODE in the response to
-     the TCP query.  Responding with the TC bit set is preferrable to
-     not sending a response, since it enables errors to be diagnosed.
-
-     Since LLMNR responders only respond to LLMNR queries for names for
-     which they are authoritative, LLMNR responders MUST NOT respond
-     with an RCODE of 3; instead, they should not respond at all.
-
-     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
-     RCODE values.
-
-QDCOUNT
-     An unsigned 16 bit integer specifying the number of entries in the
-     question section. A sender MUST place only one question into the
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 7]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-     question section of an LLMNR query.  LLMNR responders MUST silently
-     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
-     MUST silently discard LLMNR responses with QDCOUNT not equal to
-     one.
-
-ANCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the answer section.  LLMNR responders MUST silently
-     discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
-     An unsigned 16 bit integer specifying the number of name server
-     resource records in the authority records section.  Authority
-     record section processing is described in Section 2.9.
-
-ARCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the additional records section.  Additional record
-     section processing is described in Section 2.9.
-
-2.2.  Sender behavior
-
-   A sender may send an LLMNR query for any legal resource record  type
-   (e.g.  A, AAAA, SRV, etc.) to the link-scope multicast address.
-
-   As described in Section 2.4, a sender may also send a unicast query.
-   Sections 2 and 3 describe the circumstances in which LLMNR queries
-   may be sent.
-
-   The sender MUST anticipate receiving no replies to some LLMNR
-   queries, in the event that no responders are available within the
-   link-scope or in the event no positive non-null responses exist for
-   the transmitted query.  If no positive response is received, a
-   resolver treats it as a response that no records of the specified
-   type and class exist for the specified name (it is treated the same
-   as a response with RCODE=0 and an empty answer section).
-
-   Since the responder may order the RRs in the response so as to
-   indicate preference, the sender SHOULD preserve ordering in the
-   response to the querying application.
-
-2.3.  Responder behavior
-
-   An LLMNR response MUST be sent to the sender via unicast.
-
-   Upon configuring an IP address responders typically will synthesize
-   corresponding A, AAAA and PTR RRs so as to be able to respond to
-   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 8]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   responder has another RR as well;  the SOA RR MUST NOT be the only RR
-   that a responder has.  However, in general whether RRs are manually
-   or automatically created is an implementation decision.
-
-   For example, a host configured to have computer name "host1" and to
-   be a member of the "example.com" domain, and with IPv4 address
-   10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
-   authoritative for the following records:
-
-   host1. IN A 10.1.1.1
-   IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   host1.example.com. IN A 10.1.1.1
-   IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   1.1.1.10.in-addr.arpa. IN PTR host1.
-   IN PTR host1.example.com.
-
-   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
-   IN PTR host1.
-   IN PTR host1.example.com
-
-   An LLMNR responder might be further manually configured with the name
-   of a local mail server with an MX RR included in the "host1." and
-   "host1.example.com." records.
-
-   In responding to queries:
-
-[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
-     address(es) defined in Section 2, and on UDP and TCP port 5355 on
-     the unicast address(es) that could be set as the source address(es)
-     when the responder responds to the LLMNR query.
-
-[b]  Responders MUST direct responses to the port from which the query
-     was sent.  When queries are received via TCP this is an inherent
-     part of the transport protocol.  For queries received by UDP the
-     responder MUST take note of the source port and use that as the
-     destination port in the response.  Responses SHOULD always be sent
-     from the port to which they were directed.
-
-[c]  Responders MUST respond to LLMNR queries for names and addresses
-     they are authoritative for.  This applies to both forward and
-     reverse lookups.
-
-[d]  Responders MUST NOT respond to LLMNR queries for names they are not
-     authoritative for.
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 9]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-[e]  Responders MUST NOT respond using cached data.
-
-[f]  If a DNS server is running on a host that supports LLMNR, the DNS
-     server MUST respond to LLMNR queries only for the RRSets relating
-     to the host on which the server is running, but MUST NOT respond
-     for other records for which the server is authoritative.  DNS
-     servers also MUST NOT send LLMNR queries in order to resolve DNS
-     queries.
-
-[g]  If a responder is authoritative for a name, it MAY respond with
-     RCODE=0 and an empty answer section, if the type of query does not
-     match a RR that the responder has.
-
-   As an example, a host configured to respond to LLMNR queries for the
-   name "foo.example.com."  is authoritative for the name
-   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
-   name "foo.example.com." the host authoritatively responds with A
-   RR(s) that contain IP address(es) in the RDATA of the resource
-   record.  If the responder has a AAAA RR, but no A RR, and an A RR
-   query is received, the responder would respond with RCODE=0 and an
-   empty answer section.
-
-   In conventional DNS terminology a DNS server authoritative for a zone
-   is authoritative for all the domain names under the zone apex except
-   for the branches delegated into separate zones.  Contrary to
-   conventional DNS terminology, an LLMNR responder is authoritative
-   only for the zone apex.
-
-   For example the host "foo.example.com." is not authoritative for the
-   name "child.foo.example.com." unless the host is configured with
-   multiple names, including "foo.example.com."  and
-   "child.foo.example.com.".  As a result, "foo.example.com." cannot
-   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
-   (authoritative name error).  The purpose of limiting the name
-   authority scope of a responder is to prevent complications that could
-   be caused by coexistence of two or more hosts with the names
-   representing child and parent (or grandparent) nodes in the DNS tree,
-   for example, "foo.example.com." and "child.foo.example.com.".
-
-   In this example (unless this limitation is introduced) an LLMNR query
-   for an A resource record for the name "child.foo.example.com." would
-   result in two authoritative responses: RCODE=3 (authoritative name
-   error) received from "foo.example.com.", and a requested A record -
-   from "child.foo.example.com.".  To prevent this ambiguity, LLMNR
-   enabled hosts could perform a dynamic update of the parent (or
-   grandparent) zone with a delegation to a child zone.  In this example
-   a host "child.foo.example.com." would send a dynamic update for the
-   NS and glue A record to "foo.example.com.", but this approach
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 10]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   significantly complicates implementation of LLMNR and would not be
-   acceptable for lightweight hosts.
-
-2.4.  Unicast queries and responses
-
-   Unicast queries SHOULD be sent when:
-
-   [a] A sender repeats a query after it received a response
-       with the TC bit set to the previous LLMNR multicast query, or
-
-   [b] The sender queries for a PTR RR of a fully formed IP address
-       within the "in-addr.arpa" or "ip6.arpa" zones.
-
-   Unicast LLMNR queries MUST be done using TCP and the responses MUST
-   be sent using the same TCP connection as the query.  Senders MUST
-   support sending TCP queries, and responders MUST support listening
-   for TCP queries. If the sender of a TCP query receives a response to
-   that query not using TCP, the response MUST be silently discarded.
-
-   Unicast UDP queries MUST be silently discarded.
-
-   If TCP connection setup cannot be completed in order to send a
-   unicast TCP query, this is treated as a response that no records of
-   the specified type and class exist for the specified name (it is
-   treated the same as a response with RCODE=0 and an empty answer
-   section).
-
-2.5.  "Off link" detection
-
-   For IPv4, an "on link" address is defined as a link-local address
-   [IPv4Link] or an address whose prefix belongs to a subnet on the
-   local link.  For IPv6 [RFC2460] an "on link" address is either a
-   link-local address, defined in [RFC2373], or an address whose prefix
-   belongs to a subnet on the local link.
-
-   A sender MUST select a source address for LLMNR queries that is "on
-   link".  The destination address of an LLMNR query MUST be a link-
-   scope multicast address or an "on link" unicast address.
-
-   A responder MUST select a source address for responses that is "on
-   link". The destination address of an LLMNR response MUST be an "on
-   link" unicast address.
-
-   On receiving an LLMNR query, the responder MUST check whether it was
-   sent to a LLMNR multicast addresses defined in Section 2.  If it was
-   sent to another multicast address, then the query MUST be silently
-   discarded.
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 11]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
-   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
-   field in the IPv6 header and the TTL field in the IPv4 header of the
-   response to one (1).  The responder SHOULD set the TTL or Hop Limit
-   settings on the TCP listen socket to one (1) so that SYN-ACK packets
-   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
-   prevents an incoming connection from off-link since the sender will
-   not receive a SYN-ACK from the responder.
-
-   For UDP queries and responses the Hop Limit field in the IPv6 header,
-   and the TTL field in the IPV4 header MAY be set to any value.
-   However, it is RECOMMENDED that the value 255 be used for
-   compatibility with Apple Rendezvous.
-
-   Implementation note:
-
-      In the sockets API for IPv4 [POSIX], the IP_TTL and
-      IP_MULTICAST_TTL socket options are used to set the TTL of
-      outgoing unicast and multicast packets. The IP_RECVTTL socket
-      option is available on some platforms to retrieve the IPv4 TTL of
-      received packets with recvmsg().  [RFC2292] specifies similar
-      options for setting and retrieving the IPv6 Hop Limit.
-
-2.6.  Responder responsibilities
-
-   It is the responsibility of the responder to ensure that RRs returned
-   in LLMNR responses MUST only include values that are valid on the
-   local interface, such as IPv4 or IPv6 addresses valid on the local
-   link or names defended using the mechanism described in Section 4.
-   In particular:
-
-   [a] If a link-scope IPv6 address is returned in a AAAA RR,
-       that address MUST be valid on the local link over which
-       LLMNR is used.
-
-   [b] If an IPv4 address is returned, it MUST be reachable
-       through the link over which LLMNR is used.
-
-   [c] If a name is returned (for example in a CNAME, MX
-       or SRV RR), the name MUST be resolvable on the local
-       link over which LLMNR is used.
-
-   Routable addresses MUST be included first in the response, if
-   available.  This encourages use of routable address(es) for
-   establishment of new connections.
-
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 12]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-2.7.  Retransmission and jitter
-
-   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
-   when to retransmit an LLMNR query and how long to collect responses
-   to an LLMNR query.
-
-   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
-   then a sender MAY repeat the transmission of the query in order to
-   assure that it was received by a host capable of responding to it.
-   Retransmission of UDP queries SHOULD NOT be attempted more than 3
-   times. Where LLMNR queries are sent using TCP, retransmission is
-   handled by the transport layer.
-
-   Because an LLMNR sender cannot know in advance if a query sent using
-   multicast will receive no response, one response, or more than one
-   response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
-   collect all possible responses, rather than considering the multicast
-   query answered after the first response is received. A unicast query
-   sender considers the query answered after the first response is
-   received, so that it only waits for LLMNR_TIMEOUT if no response has
-   been received.
-
-   An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
-   for each transmission. It is suggested that the computation of
-   LLMNR_TIMEOUT be based on the response times for earlier LLMNR
-   queries sent on the same interface.
-
-   For example, the algorithms described in RFC 2988 [RFC2988]
-   (including exponential backoff) compute an RTO, which is used as the
-   value of LLMNR_TIMEOUT.  Smaller values MAY be used for the initial
-   RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum
-   RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the
-   maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
-
-   Recommended values are an initial RTO of 1 second, a minimum RTO of
-   200ms, and a maximum RTO of 5 seconds.  In order to avoid
-   synchronization, the transmission of each LLMNR query and response
-   SHOULD delayed by a time randomly selected from the interval 0 to 100
-   ms.  This delay MAY be avoided by responders responding with RRs
-   which they have previously determined to be UNIQUE (see Section 4 for
-   details).
-
-2.8.  DNS TTL
-
-   The responder should use a pre-configured TTL value in the records
-   returned an LLMNR response.  A default value of 30 seconds is
-   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
-   networks), the TTL value may need to be reduced.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 13]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   Due to the TTL minimalization necessary when caching an RRset, all
-   TTLs in an RRset MUST be set to the same value.
-
-2.9.  Use of the authority and additional sections
-
-   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
-   concept of delegation.  In LLMNR, the NS resource record type may be
-   stored and queried for like any other type, but it has no special
-   delegation semantics as it does in the DNS.  Responders MAY have NS
-   records associated with the names for which they are authoritative,
-   but they SHOULD NOT include these NS records in the authority
-   sections of responses.
-
-   Responders SHOULD insert an SOA record into the authority section of
-   a negative response, to facilitate negative caching as specified in
-   [RFC2308].  The owner name of this SOA record MUST be equal to the
-   query name.
-
-   Responders SHOULD NOT perform DNS additional section processing,
-   except as required for EDNS0 and DNSSEC.
-
-   Senders MUST NOT cache RRs from the authority or additional section
-   of a response as answers, though they may be used for other purposes
-   such as negative caching.
-
-3.  Usage model
-
-   Since LLMNR is a secondary name resolution mechanism, its usage is in
-   part determined by the behavior of DNS implementations.  This
-   document does not specify any changes to DNS resolver behavior, such
-   as searchlist processing or retransmission/failover policy.  However,
-   robust DNS resolver implementations are more likely to avoid
-   unnecessary LLMNR queries.
-
-   As noted in [DNSPerf], even when DNS servers are configured, a
-   significant fraction of DNS queries do not receive a response, or
-   result in negative responses due to missing inverse mappings or NS
-   records that point to nonexistent or inappropriate hosts.  This has
-   the potential to result in a large number of unnecessary LLMNR
-   queries.
-
-   [RFC1536] describes common DNS implementation errors and fixes.  If
-   the proposed fixes are implemented, unnecessary LLMNR queries will be
-   reduced substantially, and so implementation of [RFC1536] is
-   recommended.
-
-   For example, [RFC1536] Section 1 describes issues with retransmission
-   and recommends implementation of a retransmission policy based on
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 14]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   round trip estimates, with exponential backoff.  [RFC1536] Section 4
-   describes issues with failover, and recommends that resolvers try
-   another server when they don't receive a response to a query.  These
-   policies are likely to avoid unnecessary LLMNR queries.
-
-   [RFC1536] Section 3 describes zero answer bugs, which if addressed
-   will also reduce unnecessary LLMNR queries.
-
-   [RFC1536] Section 6 describes name error bugs and recommended
-   searchlist processing that will reduce unnecessary RCODE=3
-   (authoritative name) errors, thereby also reducing unnecessary LLMNR
-   queries.
-
-3.1.  LLMNR configuration
-
-   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-   possible for a dual stack host to be configured with the address of a
-   DNS server over IPv4, while remaining unconfigured with a DNS server
-   suitable for use over IPv6.
-
-   In these situations, a dual stack host will send AAAA queries to the
-   configured DNS server over IPv4.  However, an IPv6-only host
-   unconfigured with a DNS server suitable for use over IPv6 will be
-   unable to resolve names using DNS.  Automatic IPv6 DNS configuration
-   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
-   deployed, and not all DNS servers support IPv6. Therefore lack of
-   IPv6 DNS configuration may be a common problem in the short term, and
-   LLMNR may prove useful in enabling linklocal name resolution over
-   IPv6.
-
-   Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
-   IPv6-only hosts may not be configured with a DNS server.  Where there
-   is no DNS server authoritative for the name of a host or the
-   authoritative DNS server does not support dynamic client update over
-   IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
-   be able to do DNS dynamic update, and other hosts will not be able to
-   resolve its name.
-
-   For example, if the configured DNS server responds to AAAA RR queries
-   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3),
-   then it will not be possible to resolve the names of IPv6-only hosts.
-   In this situation, LLMNR over IPv6 can be used for local name
-   resolution.
-
-   Similarly, if a DHCPv4 server is available providing DNS server
-   configuration, and DNS server(s) exist which are authoritative for
-   the A RRs of local hosts and support either dynamic client update
-   over IPv4 or DHCPv4-based dynamic update, then the names of local
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 15]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
-   DNS server is authoritative for the names of local hosts, or the
-   authoritative DNS server(s) do not support dynamic update, then LLMNR
-   enables linklocal name resolution over IPv4.
-
-   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-   configure LLMNR on an interface.  The LLMNR Enable Option, described
-   in [LLMNREnable], can be used to explicitly enable or disable use of
-   LLMNR on an interface.  The LLMNR Enable Option does not determine
-   whether or in which order DNS itself is used for name resolution.
-   The order in which various name resolution mechanisms should be used
-   can be specified using the Name Service Search Option (NSSO) for DHCP
-   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
-   data.
-
-   It is possible that DNS configuration mechanisms will go in and out
-   of service.  In these circumstances, it is possible for hosts within
-   an administrative domain to be inconsistent in their DNS
-   configuration.
-
-   For example, where DHCP is used for configuring DNS servers, one or
-   more DHCP servers can fail.  As a result, hosts configured prior to
-   the outage will be configured with a DNS server, while hosts
-   configured after the outage will not.  Alternatively, it is possible
-   for the DNS configuration mechanism to continue functioning while
-   configured DNS servers fail.
-
-   Unless unconfigured hosts periodically retry configuration, an outage
-   in the DNS configuration mechanism will result in hosts continuing to
-   use LLMNR even once the outage is repaired.  Since LLMNR only enables
-   linklocal name resolution, this represents an unnecessary degradation
-   in capabilities.  As a result, it is recommended that hosts without a
-   configured DNS server periodically attempt to obtain DNS
-   configuration.  For example, where DHCP is used for DNS
-   configuration, [RFC2131] recommends a maximum retry interval of 64
-   seconds.  In the absence of other guidance, a default retry interval
-   of one (1) minute is RECOMMENDED.
-
-4.  Conflict resolution
-
-   The sender MUST anticipate receiving multiple replies to the same
-   LLMNR query, in the event that several LLMNR enabled computers
-   receive the query and respond with valid answers.  When this occurs,
-   the responses may first be concatenated, and then treated in the same
-   manner that multiple RRs received from the same DNS server would; the
-   sender perceives no inherent conflict in the receipt of multiple
-   responses.
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 16]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   There are some scenarios when multiple responders MAY respond to the
-   same query.  There are other scenarios when only one responder MAY
-   respond to a query.  Resource records for which the latter queries
-   are submitted are referred as UNIQUE throughout this document.  The
-   uniqueness of a resource record depends on a nature of the name in
-   the query and type of the query.  For example it is expected that:
-
-      - multiple hosts may respond to a query for an SRV type record
-      - multiple hosts may respond to a query for an A or AAAA type
-        record for a cluster name (assigned to multiple hosts in
-        the cluster)
-      - only a single host may respond to a query for an A or AAAA
-        type record for a name.
-
-   Every responder that responds to an LLMNR query AND includes a UNIQUE
-   record in the response:
-
-   [1]  MUST verify that there is no other host within the
-        scope of the LLMNR query propagation that can return
-        a resource record for the same name, type and class.
-
-   [2]  MUST NOT include a UNIQUE resource record in the
-        response without having verified its uniqueness.
-
-   Where a host is configured to issue LLMNR queries on more than one
-   interface, each interface should have its own independent LLMNR
-   cache.  For each UNIQUE resource record in a given interface's
-   configuration, the host MUST verify resource record uniqueness on
-   that interface.  To accomplish this, the host MUST send an LLMNR
-   query for each UNIQUE resource record.
-
-   By default, a host SHOULD be configured to behave as though all RRs
-   are UNIQUE.  Uniqueness verification is carried out when the host:
-
-     - starts up or is rebooted
-     - wakes from sleep (if the network interface was inactive during sleep)
-     - is configured to respond to the LLMNR queries on an interface
-       enabled for transmission and reception of IP traffic
-     - is configured to respond to the LLMNR queries using additional
-       UNIQUE resource records
-     - detects that an interface is connected and is usable
-       (e.g. an IEEE 802 hardware link-state change indicating
-       that a cable was attached or completion of authentication
-       (and if needed, association) with a wireless base station
-       or adhoc network
-
-   When a host that has a UNIQUE record receives an LLMNR query for that
-   record, the host MUST respond.  After the client receives a response,
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 17]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   it MUST check whether the response arrived on an interface different
-   from the one on which the query was sent.  If the response arrives on
-   a different interface, the client can use the UNIQUE resource record
-   in response to LLMNR queries.  If not, then it MUST NOT use the
-   UNIQUE resource record in response to LLMNR queries.
-
-   The name conflict detection mechanism doesn't prevent name conflicts
-   when previously partitioned segments are connected by a bridge. In
-   order to minimize the chance of conflicts in such a situation, it is
-   recommended that steps be taken to ensure name uniqueness. For
-   example, the name could be chosen randomly from a large pool of
-   potential names, or the name could be assigned via a process designed
-   to guarantee uniqueness.
-
-   When name conflicts are detected, they SHOULD be logged.  To detect
-   duplicate use of a name, an administrator can use a name resolution
-   utility which employs LLMNR and lists both responses and responders.
-   This would allow an administrator to diagnose behavior and
-   potentially to intervene and reconfigure LLMNR responders who should
-   not be configured to respond to the same name.
-
-4.1.  Considerations for Multiple Interfaces
-
-   A multi-homed host may elect to configure LLMNR on only one of its
-   active interfaces.  In many situations this will be adequate.
-   However, should a host need to configure LLMNR on more than one of
-   its active interfaces, there are some additional precautions it MUST
-   take.  Implementers who are not planning to support LLMNR on multiple
-   interfaces simultaneously may skip this section.
-
-   A multi-homed host checks the uniqueness of UNIQUE records as
-   described in Section 4.  The situation is illustrated in figure 1.
-
-        ----------  ----------
-         |      |    |      |
-        [A]    [myhost]   [myhost]
-
-      Figure 1.  Link-scope name conflict
-
-   In this situation, the multi-homed myhost will probe for, and defend,
-   its host name on both interfaces.  A conflict will be detected on one
-   interface, but not the other.  The multi-homed myhost will not be
-   able to respond with a host RR for "myhost" on the interface on the
-   right (see Figure 1).  The multi-homed host may, however, be
-   configured to use the "myhost" name on the interface on the left.
-
-   Since names are only unique per-link, hosts on different links could
-   be using the same name.  If an LLMNR client sends requests over
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 18]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   multiple interfaces, and receives replies from more than one, the
-   result returned to the client is defined by the implementation.  The
-   situation is illustrated in figure 2.
-
-        ----------  ----------
-         |      |    |     |
-        [A]    [myhost]   [A]
-
-
-      Figure 2.  Off-segment name conflict
-
-   If host myhost is configured to use LLMNR on both interfaces, it will
-   send LLMNR queries on both interfaces.  When host myhost sends a
-   query for the host RR for name "A" it will receive a response from
-   hosts on both interfaces.
-
-   Host myhost cannot distinguish between the situation shown in Figure
-   2, and that shown in Figure 3 where no conflict exists.
-
-                [A]
-               |   |
-           -----   -----
-               |   |
-              [myhost]
-
-      Figure 3.  Multiple paths to same host
-
-   This illustrates that the proposed name conflict resolution mechanism
-   does not support detection or resolution of conflicts between hosts
-   on different links.  This problem can also occur with unicast DNS
-   when a multi-homed host is connected to two different networks with
-   separated name spaces.  It is not the intent of this document to
-   address the issue of uniqueness of names within DNS.
-
-4.2.  API issues
-
-   [RFC2553] provides an API which can partially solve the name
-   ambiguity problem for applications written to use this API, since the
-   sockaddr_in6 structure exposes the scope within which each scoped
-   address exists, and this structure can be used for both IPv4 (using
-   v4-mapped IPv6 addresses) and IPv6 addresses.
-
-   Following the example in Figure 2, an application on 'myhost' issues
-   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
-   interfaces and the resolver library will return a list containing
-   multiple addrinfo structures, each with an associated sockaddr_in6
-   structure.  This list will thus contain the IPv4 and IPv6 addresses
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 19]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   of both hosts responding to the name 'A'.  Link-local addresses will
-   have a sin6_scope_id value that disambiguates which interface is used
-   to reach the address.  Of course, to the application, Figures 2 and 3
-   are still indistinguishable, but this API allows the application to
-   communicate successfully with any address in the list.
-
-5.  Security Considerations
-
-   LLMNR is by nature a peer-to-peer name resolution protocol. It is
-   therefore inherently more vulnerable than DNS, since existing DNS
-   security mechanisms are difficult to apply to LLMNR. While tools
-   exist to alllow an attacker to spoof a response to a DNS query,
-   spoofing a response to an LLMNR query is easier since the query is
-   sent to a link-scope multicast address, where every host on the
-   logical link will be made aware of it.
-
-   In order to address the security vulnerabilities, the following
-   mechanisms are contemplated:
-
-      [1]  Scope restrictions.
-      [2]  Usage restrictions.
-      [3]  Cache and port separation.
-      [4]  Authentication.
-
-   These techniques are described in the following sections.
-
-5.1.  Scope restriction
-
-   With LLMNR it is possible that hosts will allocate conflicting names
-   for a period of time, or that attackers will attempt to deny service
-   to other hosts by allocating the same name. Such attacks also allow
-   hosts to receive packets destined for other hosts.
-
-   Since LLMNR is typically deployed in situations where no trust model
-   can be assumed, it is likely that LLMNR queries and responses will be
-   unauthenticated.  In the absence of authentication, LLMNR reduces the
-   exposure to such threats by utilizing UDP queries sent to a link-
-   scope multicast address, as well as setting the TTL (IPv4) or Hop
-   Limit (IPv6) fields to one (1) on TCP queries and responses.
-
-   Using a TTL of one (1) to set up a TCP connection in order to send a
-   unicast LLMNR query reduces the likelihood of both denial of service
-   attacks and spoofed responses.  Checking that an LLMNR query is sent
-   to a link-scope multicast address should prevent spoofing of
-   multicast queries by off-link attackers.
-
-   While this limits the ability of off-link attackers to spoof LLMNR
-   queries and responses, it does not eliminate it. For example, it is
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 20]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   possible for an attacker to spoof a response to a frequent query
-   (such as an A or AAAA query for a popular Internet host), and by
-   using a TTL or Hop Limit field larger than one (1), for the forged
-   response to reach the LLMNR sender.
-
-   When LLMNR queries are sent to a link-scope multicast address, it is
-   possible that some routers may not properly implement link-scope
-   multicast, or that link-scope multicast addresses may leak into the
-   multicast routing system.
-
-   Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
-   one in an LLMNR UDP response may enable denial of service attacks
-   across the Internet.  However, since LLMNR responders only respond to
-   queries for which they are authoritative, and LLMNR does not provide
-   wildcard query support, it is believed that this threat is minimal.
-
-   There also are scenarios such as public "hotspots" where attackers
-   can be present on the same link.  These threats are most serious in
-   wireless networks such as 802.11, since attackers on a wired network
-   will require physical access to the home network, while wireless
-   attackers may reside outside the home.  Link-layer security can be of
-   assistance against these threats if it is available.
-
-5.2.  Usage restriction
-
-   As noted in Sections 2 and 3, LLMNR is intended for usage in a
-   limited set of scenarios.
-
-   If an LLMNR query is sent whenever a DNS server does not respond in a
-   timely way, then an attacker can poison the LLMNR cache by responding
-   to the query with incorrect information.  To some extent, these
-   vulnerabilities exist today, since DNS response spoofing tools are
-   available that can allow an attacker to respond to a query more
-   quickly than a distant DNS server.
-
-   Since LLMNR queries are sent and responded to on the local-link, an
-   attacker will need to respond more quickly to provide its own
-   response prior to arrival of the response from a legitimate
-   responder. If an LLMNR query is sent for an off-link host, spoofing a
-   response in a timely way is not difficult, since a legitimate
-   response will never be received.
-
-   The vulnerability is more serious if LLMNR is given higher priority
-   than DNS among the enabled name resolution mechanisms. In such a
-   configuration, a denial of service attack on the DNS server would not
-   be necessary in order to poison the LLMNR cache, since LLMNR queries
-   would be sent even when the DNS server is available. In addition, the
-   LLMNR cache, once poisoned, would take precedence over the DNS cache,
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 21]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   eliminating the benefits of cache separation. As a result, LLMNR is
-   only used as a name resolution mechanism of last resort.
-
-5.3.  Cache and port separation
-
-   In order to prevent responses to LLMNR queries from polluting the DNS
-   cache, LLMNR implementations MUST use a distinct, isolated cache for
-   LLMNR on each interface. The use of separate caches is most effective
-   when LLMNR is used as a name resolution mechanism of last resort,
-   since this minimizes the opportunities for poisoning the LLMNR cache,
-   and decreases reliance on it.
-
-   LLMNR operates on a separate port from DNS, reducing the likelihood
-   that a DNS server will unintentionally respond to an LLMNR query.
-
-5.4.  Authentication
-
-   LLMNR implementations may not support DNSSEC or TSIG, and as a
-   result, responses to LLMNR queries may be unauthenticated.  If
-   authentication is desired, and a pre-arranged security configuration
-   is possible, then IPsec ESP with a null-transform MAY be used to
-   authenticate LLMNR responses.  In a small network without a
-   certificate authority, this can be most easily accomplished through
-   configuration of a group pre-shared key for trusted hosts.
-
-6.  IANA Considerations
-
-   This specification creates one new name space:  the reserved bits in
-   the LLMNR header.  These are allocated by IETF Consensus, in
-   accordance with BCP 26 [RFC2434].
-
-   LLMNR requires allocation of port 5355 for both TCP and UDP.
-
-   LLMNR requires allocation of link-scope multicast IPv4 address
-   224.0.0.252, as well as link-scope multicast IPv6 address
-   FF02:0:0:0:0:0:1:3.
-
-7.  References
-
-7.1.  Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
-          Specification", RFC 1035, November 1987.
-
-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-          April 1992.
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 22]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-          Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
-          Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-          RFC 2308, March 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
-          2365, July 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
-          Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
-          Considerations Section in RFCs", BCP 26, RFC 2434, October
-          1998.
-
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
-          (IPv6) Specification", RFC 2460, December 1998.
-
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-          2535, March 1999.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
-          August 1999.
-
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
-          Timer", RFC 2988, November 2000.
-
-7.2.  Informative References
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
-          Fixes", RFC 1536, October 1993.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-          March 1997.
-
-[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-          Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-          April 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
-          RFC 2292, February 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
-          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 23]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
-          2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
-          IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
-          Caching", IEEE/ACM Transactions on Networking, Volume 10,
-          Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
-          unicast addresses to communicate with recursive DNS servers",
-          Internet draft (work in progress), draft-ietf-ipv6-dns-
-          discovery-07.txt, October 2002.
-
-[IPV4Link]
-          Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
-          of IPv4 Link-Local Addresses", Internet draft (work in
-          progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May
-          2004.
-
-[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
-          Portable Operating System Interface (POSIX). Open Group
-          Technical Standard: Base Specifications, Issue 6, December
-          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin
-
-[LLMNREnable]
-          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
-          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[NodeInfo]
-          Crawford, M., "IPv6 Node Information Queries", Internet draft
-          (work in progress), draft-ietf-ipn-gwg-icmp-name-
-          lookups-09.txt, May 2002.
-
-Acknowledgments
-
-   This work builds upon original work done on multicast DNS by Bill
-   Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
-   grant #F30602-99-1-0523. The authors gratefully acknowledge their
-   contribution to the current specification.  Constructive input has
-   also been received from Mark Andrews, Stuart Cheshire, Randy Bush,
-   Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik
-   Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik
-   Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill,
-   Keith Moore and Markku Savela.
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 24]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-Authors' Addresses
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-   Bernard Aboba
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 706 6605
-   EMail: bernarda@microsoft.com
-
-   Dave Thaler
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 703 8835
-   EMail: dthaler@microsoft.com
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 25]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Open Issues
-
-   Open issues with this specification are tracked on the following web
-   site:
-
-   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 26]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt
deleted file mode 100644
index c5c3b84ba3d5..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                        Yuji Kamite
-INTERNET-DRAFT                                       NTT Communications
-<draft-ietf-dnsext-tkey-renewal-mode-04.txt>            Masaya Nakayama
-Expires: Aug. 2004                              The University of Tokyo
-                                                              Feb. 2004
-
-
-
-
-                      TKEY Secret Key Renewal Mode
-
-
-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 defines a new mode in TKEY and proposes an atomic
-   method for changing secret keys used for TSIG periodically.
-   Originally, TKEY provides methods of setting up shared secrets other
-   than manual exchange, but it cannot control timing of key renewal
-   very well though it can add or delete shared keys separately. This
-   proposal is a systematical key renewal procedure intended for
-   preventing signing DNS messages with old and non-safe keys
-   permanently.
-
-
-
-
-
-
-
-
-Kamite, et. al.                                                 [Page 1]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-                           Table of Contents
-
-
-1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-  1.1  Defined Words . . . . . . . . . . . . . . . . . . . . . . . .   3
-  1.2  New Format and Assigned Numbers . . . . . . . . . . . . . . .   4
-  1.3  Overview of Secret Key Renewal Mode . . . . . . . . . . . . .   4
-2  Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . .   5
-  2.1  Key Usage Time Check  . . . . . . . . . . . . . . . . . . . .   5
-  2.2  Partial Revocation  . . . . . . . . . . . . . . . . . . . . .   6
-  2.3  Key Renewal Message Exchange  . . . . . . . . . . . . . . . .   7
-    2.3.1  Query for Key Renewal . . . . . . . . . . . . . . . . . .   7
-    2.3.2  Response for Key Renewal  . . . . . . . . . . . . . . . .   7
-    2.3.3  Attributes of Generated Key . . . . . . . . . . . . . . .   8
-    2.3.4  TKEY RR structure . . . . . . . . . . . . . . . . . . . .   8
-  2.4  Key Adoption  . . . . . . . . . . . . . . . . . . . . . . . .  10
-    2.4.1  Query for Key Adoption  . . . . . . . . . . . . . . . . .  10
-    2.4.2  Response for Key Adoption . . . . . . . . . . . . . . . .  10
-  2.5  Keying Schemes  . . . . . . . . . . . . . . . . . . . . . . .  11
-    2.5.1  DH Exchange for Key Renewal . . . . . . . . . . . . . . .  11
-    2.5.2  Server Assigned Keying for Key Renewal  . . . . . . . . .  12
-    2.5.3  Resolver Assigned Keying for Key Renewal  . . . . . . . .  13
-  2.6  Considerations about Non-compliant Hosts  . . . . . . . . . .  14
-3  Secret Storage  . . . . . . . . . . . . . . . . . . . . . . . . .  15
-4  Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . .  15
-  4.1  Compulsory Key Revocation by Server . . . . . . . . . . . . .  15
-  4.2  Authentication Methods Considerations . . . . . . . . . . . .  15
-5  Special Considerations for Two Servers' Case  . . . . . . . . . .  16
-  5.1  To Cope with Collisions of Renewal Requests . . . . . . . . .  16
-6  Key Name Considerations . . . . . . . . . . . . . . . . . . . . .  17
-7  Example Usage of Secret Key Renewal Mode  . . . . . . . . . . . .  17
-8  Security Considerations . . . . . . . . . . . . . . . . . . . . .  20
-9  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . .  20
-10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . .  21
-11 References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
-Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . .  22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.                                                 [Page 2]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-1.  Introduction
-
-   TSIG [RFC2845] provides DNS message integrity and the
-   request/transaction authentication by means of message authentication
-   codes (MAC). TSIG is a practical solution in view of calculation
-   speed and availability. However, TSIG does not have exchanging
-   mechanism of shared secret keys between server and resolver, and
-   administrators might have to exchange secret keys manually. TKEY
-   [RFC2930] is introduced to solve such problem and it can exchange
-   secrets for TSIG via networks.
-
-   In various modes of TKEY, a server and a resolver can add or delete a
-   secret key be means of TKEY message exchange. However, the existing
-   TKEY does not care fully about the management of keys which became
-   too old, or dangerous after long time usage.
-
-   It is ideal that the number of secret which a pair of hosts share
-   should be limited only one, because having too many keys for the same
-   purpose might not only be a burden to resolvers for managing and
-   distinguishing according to servers to query, but also does not seem
-   to be safe in terms of storage and protection against attackers.
-   Moreover, perhaps holding old keys long time might give attackers
-   chances to compromise by scrupulous calculation.
-
-   Therefore, when a new shared secret is established by TKEY, the
-   previous old secret should be revoked immediately. To accomplish
-   this, DNS servers must support a protocol for key renewal. This
-   document specifies procedure to refresh secret keys between two hosts
-   which is defined within the framework of TKEY, and it is called "TKEY
-   Secret Key Renewal Mode".
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
-   "OPTIONAL" in this document are to be interpreted as described in
-   [RFC2119].
-
-
-1.1.  Defined Words
-
-   * Inception Time: Beginning of the shared secret key lifetime. This
-   value is determined when the key is generated.
-
-   * Expiry Limit: Time limit of the key's validity. This value is
-   determined when a new key is generated. After Expiry Limit, server
-   and client (resolver) must not authenticate TSIG signed with the key.
-   Therefore, Renewal to the next key should be carried out before
-   Expiry Limit.
-
-   * Partial Revocation Time: Time when server judges the key is too old
-
-
-
-Kamite, et. al.                                                 [Page 3]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   and must be updated. It must be between Inception Time and Expiry
-   Limit.  This value is determined by server freely following its
-   security policy. e.g., If the time from Inception to Partial
-   Revocation is short, renewal will be carried out more often, which
-   might be safer.
-
-   * Revocation Time: Time when the key becomes invalid and can be
-   removed. This value is not determined in advance because it is the
-   actual time when revocation is completed.
-
-   * Adoption Time: Time when the new key is adopted as the next key
-   formally. After Adoption, the key is valid and server and client can
-   generate or verify TSIG making use of it. Adoption Time also means
-   the time when it becomes possible to remove the previous key, so
-   Revocation and Adoption are usually done at the same time.
-
-
-                  Partial
-    Inception     Revocation    Revocation         Expiry Limit
-     |                |              |             |
-     |----------------|- - - - - - >>|- (revoked) -|
-     |                |              |             |
-    previous key      |      |       |
-                             |- - - -|-------------------->> time
-                             |       |               new key
-                         Inception   Adoption
-
-
-1.2.  New Format and Assigned Numbers
-
-   TSIG
-         ERROR = (PartialRevoke), TBD
-
-   TKEY
-         Mode  = (server assignment for key renewal), TBD
-         Mode  = (Diffie-Hellman exchange for key renewal), TBD
-         Mode  = (resolver assignment for key renewal), TBD
-         Mode  = (key adoption), TBD
-
-
-1.3.  Overview of Secret Key Renewal Mode
-
-   When a server receives a query from a client signed with a TSIG key,
-   It always checks if the present time is within the range of usage
-   duration it considers safe. If it is judged that the key is too old,
-   i.e., after Partial Revocation Time, the server comes to be in
-   Partial Revocation state about the key, and this key is called
-   partially revoked.
-
-
-
-Kamite, et. al.                                                 [Page 4]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   In this state, if a client sends a normal query (e.g., question about
-   A RR) other than TKEY Renewal request with TSIG signed with the old
-   key, the server returns an error message to notify that the time to
-   renew has come. This is called "PartialRevoke" error message. It is
-   server's choice whether it returns PartialRevoke or not. If and only
-   if the server is ready for changing its own key, it decides to return
-   PartialRevoke.
-
-   The client which got this error is able to notice that it is
-   necessary to refresh the secret. To make a new shared secret, it
-   sends a TKEY Renewal request, in which several keying methods are
-   available. It can make use of TSIG authentication signed with the
-   partially revoked key mentioned above.
-
-   After new secret establishment, the client sends a TKEY Adoption
-   request for renewal confirmation. This can also be authenticated with
-   the partially revoked key. If this is admitted by the server, the new
-   key is formally adopted, and at the same time the corresponding old
-   secret is invalidated. Then the client can send the first query again
-   signed with the new key.
-
-   Key renewal procedure is executed based on two-phase commit
-   mechanism. The first phase is the TKEY Renewal request and its
-   response, which means preparatory confirmation for key update. The
-   second phase is Adoption request and its response. If the server gets
-   request and client receives the response successfully, they can
-   finish renewal process. If any error happens and renewal process
-   fails during these phases, client should roll back to the beginning
-   of the first phase, and send TKEY Renewal request again. This
-   rollback can be done until the Expiry Limit of the key.
-
-
-2.  Shared Secret Key Renewal
-
-   Suppose a server and a client agree to change their TSIG keys
-   periodically. Key renewal procedure is defined between two hosts.
-
-2.1.  Key Usage Time Check
-
-   Whenever a server receives a query with TSIG and can find a key that
-   is used for signing it, the server checks its Inception Time, Partial
-   Revocation Time and Expiry Limit (this information is usually
-   memorized by the server).
-
-   When the present time is before Inception Time, the server MUST NOT
-   verify TSIG with the key, and server acts the same way as when the
-   key used by the client is not recognized. It follows [RFC2845] 4.5.1.
-
-
-
-
-Kamite, et. al.                                                 [Page 5]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   When the present time is equal to Inception Time, or between
-   Inception Time and Partial Revocation Time, the behavior of the
-   server is the same as when a valid key is found. It follows [RFC2845]
-   4.5.2 and 4.5.3.
-
-   When the present time is the same as the Partial Revocation Time, or
-   between the Partial Revocation Time and Expiry Limit, the server
-   comes to be in Partial Revocation state about the TSIG key and
-   behaves according to the next section.
-
-   When the present time is the same as the Expiry Time or after it, the
-   server MUST NOT verify TSIG with the key, and returns error messages
-   in the same way as when the key used by the client is not recognized.
-   It follows [RFC2845] 4.5.1.
-
-
-2.2.  Partial Revocation
-
-   In Partial Revocation state, we say the server has partially revoked
-   the key and the key has become a "partially revoked key".
-
-   If server has received a query signed with the partially revoked key
-   for TKEY Renewal request (See section 2.3.) or Key Adoption request
-   (See section 2.4.), then server does proper process following each
-   specification. If it is for TKEY key deletion request ([RFC2930]
-   4.2), server MAY process usual deletion operation defined therein.
-
-   If server receives other types of query signed with the partially
-   revoked key, and both the corresponding MAC and signed TIME are
-   verified, then server begins returning answer whose TSIG error code
-   is "PartialRevoke" (See section 9.). Server MUST randomly but with
-   increasing frequency return PartialRevoke when in the Partial
-   Revocation state.
-
-   Server can decide when it actually sends PartialRevoke, checking if
-   it is appropriate time for renewal. Server MUST NOT return
-   PartialRevoke if this is apart long lived TSIG transaction (such as
-   AXFR) that started before the Partial Revocation Time.
-
-   If the client receives PartialRevoke and understands it, then it MUST
-   retry the query with the old key unless a new key has been adopted.
-   Client SHOULD start the process to renew the TSIG key. For key
-   renewal procedure, see details in Section 2.3 and 2.4.
-
-   PartialRevoke period (i.e., time while server returns PartialRevoke
-   randomely) SHOULD be small, say 2-5% of key lifetime. This is
-   server's choice.
-
-
-
-
-Kamite, et. al.                                                 [Page 6]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   Server MUST keep track of clients ignoring PartialRevoke, thus
-   indicating ignorance of this TKEY mode.
-
-   PartialRevoke error messages have the role to inform clients of the
-   keys' partial revocation and urge them to send TKEY Renewal requests.
-   These error responses MUST be signed with those partial revoked keys
-   if the queries are signed with them. They are sent only when the
-   signing keys are found to be partially revoked. If the MAC of TSIG
-   cannot be verified with the partially revoked keys, servers MUST NOT
-   return PartialRevoke error with MAC, but MUST return another error
-   such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
-   words, a server informs its key's partial revocation only when the
-   MAC in the received query is valid.
-
-
-2.3.  Key Renewal Message Exchange
-
-2.3.1.  Query for Key Renewal
-
-   If a client has received a PartialRevoke error and authenticated the
-   response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
-   this document, we call it Renewal request, too.) to the server. The
-   request MUST be signed with TSIG or SIG(0) [RFC2931] for
-   authentication. If TSIG is selected, the client can sign it with the
-   partial revoked key.
-
-   Key Renewal can use one of several keying methods which is indicated
-   in "Mode" field of TKEY RR, and its message structure is dependent on
-   that method.
-
-
-2.3.2.  Response for Key Renewal
-
-   The server which has received Key Renewal request first tries to
-   verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
-   verified with the partially revoked key, the request MUST be
-   authenticated.
-
-   After authentication, server must check existing old key's validity.
-   If the partially revoked key indicated in the request TKEY's OldName
-   and OldAlgorithm field (See section 2.3.4.) does not exist at the
-   server, "BADKEY" [RFC2845] is given in Error field for response. If
-   any other error happens, server returns appropriate error messages
-   following the specification described in section 2.5. If there are no
-   errors, server returns a Key Renewal answer. This answer MUST be
-   signed with TSIG or SIG(0) for authentication.
-
-   When this answer is successfully returned and no error is detected by
-
-
-
-Kamite, et. al.                                                 [Page 7]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   client, a new shared secret can be established. The details of
-   concrete keying procedure are given in the section 2.5.
-
-   Note:
-      Sometimes Adoption message and new Renewal request will cross on
-      the wire. In this case the newly generated key Adoption message is
-      resent.
-
-
-2.3.3.  Attributes of Generated Key
-
-   As a result of this message exchange, client comes to know the newly
-   generated key's attributes such as key's name, Inception Time and
-   Expiry Limit. They are decided by the server and told to the client;
-   in particular, however, once the server has decided Expiry Limit and
-   returned a response, it should obey the decision as far as it can. In
-   other words, they SHOULD NOT change time values for checking Expiry
-   Limit in the future without any special reason, such as security
-   issue like "Emergency Compulsory Revocation" described in section 8.
-
-   On the other hand, Partial Revocation Time of this generated key is
-   not decided based on the request, and not informed to the client. The
-   server can determine any value as long as it is between Inception
-   Time and Expiry Limit. However, the period from Inception to Partial
-   Revocation SHOULD be fixed as the server side's configuration or be
-   set the same as the corresponding old key's one.
-
-   Note:
-      Even if client sends Key Renewal request though the key described
-      in OldName has not been partially revoked yet, server does renewal
-      processes.  At the moment when the server accepts such requests
-      with valid authentication, it MUST forcibly consider the key is
-      already partially revoked, that is, the key's Partial Revocation
-      Time must be changed into the present time (i.e., the time when
-      the server receives the request).
-
-
-2.3.4.  TKEY RR structure
-
-   TKEY RR for Key Renewal message has the structure given below. In
-   principle, format and definition for each field follows [RFC2930].
-   Note that each keying scheme sometimes needs different interpretation
-   of RDATA field; for detail, see section 2.5.
-
-        Field        Type         Comment
-        -------      ------       -------
-        NAME         domain       used for a new key, see below
-        TYPE         u_int16_t    (defined in [RFC2930])
-
-
-
-Kamite, et. al.                                                 [Page 8]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-        CLASS        u_int16_t    (defined in [RFC2930])
-        TTL          u_int32_t    (defined in [RFC2930])
-        RDLEN        u_int16_t    (defined in [RFC2930])
-        RDATA:
-         Algorithm:   domain       algorithm for a new key
-         Inception:   u_int32_t    about the keying material
-         Expiration:  u_int32_t    about the keying material
-         Mode:        u_int16_t    scheme for key agreement
-                                   see section 9.
-         Error:       u_int16_t    see description below
-         Key Size:    u_int16_t    see description below
-         Key Data:    octet-stream
-         Other Size:  u_int16_t    (defined in [RFC2930])
-                                   size of other data
-         Other Data:               newly defined: see description below
-
-
-     For "NAME" field, both non-root and root name are allowed. It may
-     be used for a new key's name in the same manner as [RFC2930] 2.1.
-
-     "Algorithm" specifies which algorithm is used for agreed keying
-     material, which is used for identification of the next key.
-
-     "Inception" and "Expiration" are used for the valid period of
-     keying material. The meanings differ somewhat according to whether
-     the message is request or answer, and its keying scheme.
-
-     "Key Data" has different meanings according to keying schemes.
-
-     "Mode" field stores the value in accordance with the keying method,
-     and see section 2.5. Servers and clients supporting TKEY Renewal
-     method MUST implement "Diffie-Hellman exchange for key renewal"
-     scheme. All other modes are OPTIONAL.
-
-     "Error" is an extended RCODE which includes "PartialRevoke" value
-     too. See section 9.
-
-     "Other Data" field has the structure given below.  They describe
-     attributes of the key to be renewed.
-
-        in Other Data filed:
-
-          Field          Type     Comment
-          -------        ------   -------
-          OldNAME        domain   name of the old key
-          OldAlgorithm   domain   algorithm of the old key
-
-
-
-
-
-Kamite, et. al.                                                 [Page 9]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-          "OldName" indicates the name of the previous key (usually,
-          this is partially revoked key's name that client noticed by
-          PartialRevoke answer from server), and "OldAlogirthm"
-          indicates its algorithm.
-
-
-2.4.  Key Adoption
-
-2.4.1.  Query for Key Adoption
-
-   After receiving a TKEY Renewal answer, the client gets the same
-   secret as the server. Then, it sends a TKEY Adoption request. The
-   request's question section's QNAME field is the same as the NAME
-   filed of TKEY written below. In additional section, there is one TKEY
-   RR that has the structure and values described below.
-
-     "NAME" field is the new key's name to be adopted which was already
-     generated by Renewal message exchange. "Algorithm" is its
-     algorithm. "Inception" means the key's Inception Time, and
-     "Expiration" means Expiry Limit.
-
-     "Mode" field is the value of "key adoption". See section 9.
-
-     "Other Data" field in Adoption has the same structure as that of
-     Renewal request message. "OldName" means the previous old key, and
-     "OldAlogirthm" means its algorithm.
-
-   Key Adoption request MUST be signed with TSIG or SIG(0) for
-   authentication. The client can sign TSIG with the previous key. Note
-   that until Adoption is finished, the new key is treated as invalid,
-   thus it cannot be used for authentication immediately.
-
-
-2.4.2.  Response for Key Adoption
-
-   The server which has received Adoption request, it verifies TSIG or
-   SIG(0) accompanying it. If the TSIG is signed with the partially
-   revoked key and can be verified, the message MUST be authenticated.
-
-   If the next new key indicated by the request TKEY's "NAME" is not
-   present at the server, BADNAME [RFC2845] is given in Error field and
-   the error message is returned.
-
-   If the next key exists but it has not been adopted formally yet, the
-   server confirms the previous key's existence indicated by the
-   "OldName" and "OldAlgorithm" field. If it succeeds, the server
-   executes Adoption of the next key and Revocation of the previous key.
-   Response message duplicates the request's TKEY RR with NOERROR,
-
-
-
-Kamite, et. al.                                                [Page 10]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   including "OldName" and "OldAlgorithm" that indicate the revoked key.
-
-   If the next key exists but it is already adopted, the server returns
-   a response message regardless of the substance of the request TKEY's
-   "OldName". In this response, Response TKEY RR has the same data as
-   the request's one except as to its "Other Data" that is changed into
-   null (i.e., "Other Size" is zero), which is intended for telling the
-   client that the previous key name was ignored, and the new key is
-   already available.
-
-   Client sometimes has to retry Adoption request. Suppose the client
-   sent request signed with the partially revoked key, but its response
-   did not return successfully (e.g., due to the drop of UDP packet).
-   Client will probably retry Adoption request; however, the request
-   will be refused in the form of TSIG "BADKEY" error because the
-   previous key was already revoked. In this case, client will
-   retransmit Adoption request signed with the next key, and expect a
-   response which has null "Other Data" for confirming the completion of
-   renewal.
-
-
-2.5.  Keying Schemes
-
-   In Renewal message exchanges, there are no limitations as to which
-   keying method is actually used. The specification of keying
-   algorithms is independent of the general procedure of Renewal that is
-   described in section 2.3.
-
-   Now this document specifies three algorithms in this section, but
-   other future documents can make extensions defining other methods.
-
-
-2.5.1.  DH Exchange for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.1. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as keying material
-   computation, are the exactly same as the specification of [RFC2930]
-   4.1.
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. KEY RR is
-      the client's Diffie-Hellman public key [RFC2539].
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-
-
-
-Kamite, et. al.                                                [Page 11]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-      TKEY "Mode" field stores the value of "DH exchange for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3. If
-      any incompatible DH key is found in the request, "BADKEY"
-      [RFC2845] is given in Error field for response. "FORMERR" is given
-      if the query included no DH KEY.
-
-      If there are no errors, the server processes a response according
-      to Diffie-Hellman algorithm and returns the answer. In this
-      answer, there is one TKEY RR in answer section and KEY RR(s) in
-      additional section.
-
-      As long as no error has occurred, all values of TKEY are equal to
-      that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
-      Inception, Expiration, Key Size and Key Data.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-      TKEY "Key Data" is used as an additional nonce, following
-      [RFC2930] 4.1.
-
-      The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
-      the additional section and a server Diffie-Hellman KEY RR will
-      also be present in the answer section, following [RFC2930] 4.1.
-
-
-2.5.2.  Server Assigned Keying for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.4. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as secret encrypting
-   method, are the exactly same as the specification of [RFC2930] 4.4.
-
-
-
-Kamite, et. al.                                                [Page 12]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. KEY RR is
-      used in encrypting the response.
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-      TKEY "Mode" field stores the value of "server assignment for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is provided following the specification of
-      [RFC2930] 4.4.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3.
-      "FORMERR" is given if the query specified no encryption key.
-
-      If there are no errors, the server response contains one TKEY RR
-      in the answer section, and echoes the KEY RR provided in the query
-      in the additional information section.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-      TKEY "Key Data" is the assigned keying data encrypted under the
-      public key in the resolver provided KEY RR, which is the same as
-      [RFC2930] 4.4.
-
-
-2.5.3.  Resolver Assigned Keying for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.5. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as secret encrypting
-   method, are the exactly same as the specification of [RFC2930] 4.5.
-
-
-
-
-Kamite, et. al.                                                [Page 13]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. TKEY RR
-      has the encrypted keying material and KEY RR is the server public
-      key used to encrypt the data.
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-      TKEY "Mode" field stores the value of "resolver assignment for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is the encrypted keying material.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3.
-      "FORMERR" is given if the server does not have the corresponding
-      private key for the KEY RR that was shown sin the request.
-
-      If there are no errors, the server returns a response. The
-      response contains a TKEY RR in the answer section to tell the
-      shared key's name and its usage time values.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-
-2.6.  Considerations about Non-compliant Hosts
-
-   Key Renewal requests and responses must be exchanged between hosts
-   which can understand them and do proper processes. PartialRevoke
-   error messages will be only ignored if they should be returned to
-   non-compliant hosts.
-
-   Note that server does not inform actively the necessity of renewal to
-   clients, but inform it as responses invoked by client's query.
-   Server needs not care whether the PartialRevoke errors has reached
-
-
-
-Kamite, et. al.                                                [Page 14]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   client or not. If client has not received yet because of any reasons
-   such as packet drops, it will resend the queries, and finally will be
-   able to get PartialRevoke information.
-
-
-3.  Secret Storage
-
-   Every server keeps all secrets and attached information, e.g.,
-   Inception Time, Expiry Limit, etc. safely to be able to recover from
-   unexpected stop. To accomplish this, formally adopted keys SHOULD be
-   memorized not only on memory, but also be stored in the form of some
-   files. It will become more secure if they are stored in ecrypted
-   form.
-
-
-4.  Compulsory Key Revocation
-
-4.1.  Compulsory Key Revocation by Server
-
-   There is a rare but possible case that although servers have already
-   partially revoked keys, clients do not try to send any Renewal
-   requests. If this state continues, in the future it will become the
-   time of Expiry Limit. After Expiry Limit, the keys will be expired
-   and completely removed, so this is called Compulsory Key Revocation
-   by server.
-
-   If Expiry Limit is too distant from the Partial Revocation Time, then
-   even though very long time passes, clients will be able to refresh
-   secrets only if they add TSIG signed with those old partially revoked
-   keys into requests, which is not safe.
-
-   On the other hand, if Expiry Limit is too close to Partial Revocation
-   Time, perhaps clients might not be able to notice their keys' Partial
-   Revocation by getting "PartialRevoke" errors.
-
-   Therefore, servers should set proper Expiry Limit to their keys,
-   considering both their keys' safety, and enough time for clients to
-   send requests and process renewal.
-
-
-4.2.  Authentication Methods Considerations
-
-   It might be ideal to provide both SIG(0) and TSIG as authentication
-   methods. For example:
-
-     A client and a server start SIG(0) authentication at first, to
-     establish TSIG shared keys by means of "Query for Diffie-Hellman
-     Exchanged Keying" as described in [RFC2930] 4.1. Once they get
-
-
-
-Kamite, et. al.                                                [Page 15]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-     shared secret, they keep using TSIG for queries and responses.
-     After a while the server returns a "ParitalRevoke" error and they
-     begin a key renewal process. Both TSIG signed with partially
-     revoked keys and SIG(0) are okay for authentication, but TSIG would
-     be easier to use considering calculation efficiency.
-
-     Suppose now client is halted for long time with some reason.
-     Because server does not execute any renewal process, it will
-     finally do Compulsory Revocation. Even if client restarts and sends
-     a key Renewal request, it will fail because old key is already
-     deleted at server.
-
-     At this moment, however, if client also uses SIG(0) as another
-     authentication method, it can make a new shared key again and
-     recover successfully by sending "Query for Diffie-Hellman Exchanged
-     Keying" with SIG(0).
-
-
-5.  Special Considerations for Two servers' Case
-
-   This section refers to the case where both hosts are DNS servers
-   which can act as full resolvers as well and using one shared key
-   only. If one server (called Server A) wants to refresh a shared key
-   (called "Key A-B"), it will await a TKEY Renewal request from the
-   other server (called Server B). However, perhaps Server A wants to
-   refresh the key right now.
-
-   In this case, Server A is allowed to send a Renewal request to Server
-   B, if Server A knows the Key A-B is too old and wants to renew it
-   immediately.
-
-   Note that the initiative in key renewal belongs to Server A because
-   it can notice the Partial Revocation Time and decide key renewal. If
-   Server B has information about Partial Revocation Time as well, it
-   can also decide for itself to send Renewal request to Server A.
-   However, it is not essential for both two servers have information
-   about key renewal timing.
-
-5.1.  To Cope with Collisions of Renewal Requests
-
-   At least one of two hosts which use Key Renewal must know their key
-   renewal information such as Partial Revocation Time. It is okay that
-   both hosts have it.
-
-   Provided that both two servers know key renewal timing information,
-   there is possibility for them to begin partial revocation and sending
-   Renewal requests to each other at the same time. Such collisions will
-   not happen so often because Renewal requests are usually invoked when
-
-
-
-Kamite, et. al.                                                [Page 16]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   hosts want to send queries, but it is possible.
-
-   When one of two servers tries to send Renewal requests, it MUST
-   protect old secrets that it has partially revoked and prevent it from
-   being refreshed by any requests from the other server (i.e., it must
-   lock the old secret during the process of renewal). While the server
-   is sending Renewal requests and waiting responses, it ignores the
-   other server's Renewal requests.
-
-   Therefore, servers might fail to change secrets by means of their own
-   requests to others. After failure they will try to resend, but they
-   should wait for random delays by the next retries. If they get any
-   Renewal requests from others while they are waiting, their shared
-   keys may be refreshed, then they do not need to send any Renewal
-   requests now for themselves.
-
-
-6.  Key Name Considerations
-
-   Since both servers and clients have only to distinguish new secrets
-   and old ones, keys' names do not need to be specified strictly.
-   However, it is recommended that some serial number or key generation
-   time be added to the name and that the names of keys between the same
-   pair of hosts should have some common labels among their keys. For
-   example, suppose A.example.com. and B.example.com. share the key
-   "<serial number>.A.example.com.B.example.com." such as
-   "10010.A.example.com.B.example.com.". After key renewal, they change
-   their secret and name into "10011.A.example.com.B.example.com."
-
-   Servers and clients must be able to use keys properly for each query.
-   Because TSIG secret keys themselves do not have any particular IDs to
-   be distinguished and would be identified by their names and
-   algorithm, it must be understood correctly what keys are refreshed.
-
-
-7.  Example Usage of Secret Key Renewal Mode
-
-   This is an example of Renewal mode usage where a Server,
-   server.example.com, and a Client, client.exmple.com have an initial
-   shared secret key named "00.client.example.com.server.example.com".
-
-     (1) The time values for key
-     "00.client.example.com.server.example.com" was set as follows:
-     Inception Time is at 1:00, Expiry Limit is at 21:00.
-
-     (2) At Server, renewal time has been set: Partial Revocation Time
-     is at 20:00.
-
-
-
-
-Kamite, et. al.                                                [Page 17]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-     (3) Suppose the present time is 19:55. If Client sends a query
-     signed with key "00.client.example.com.server.example.com" to ask
-     the IP address of "www.example.com", finally it will get a proper
-     answer from Server with valid TSIG (NOERROR).
-
-     (4) At 20:05. Client sends a query to ask the IP address of
-     "www2.example.com". It is signed with key
-     "00.client.example.com.server.example.com". Server returns an
-     answer for the IP address. However, server has begun retuning
-     PartialRevoke Error randomely. This answer includes valid TSIG MAC
-     signed with "00.client.example.com.server.example.com", and its
-     Error Code indicates PartialRevoke. Client understands that the
-     current key is partially revoked.
-
-     (5) At 20:06. Client sends a Renewal request to Server. This
-     request is signed with key
-     "00.client.example.com.server.example.com". It includes data such
-     as:
-
-      Question Section:
-         QNAME = 01.client.example.com. (Client can set this freely)
-         TYPE  = TKEY
-
-      Additional Section:
-         01.client.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (DH exchange for key renewal)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-      Additional Section also contains a KEY RR for DH and a TSIG RR.
-
-     (6) As soon as Server receives this request, it verifies TSIG. It
-     is signed with the partially revoked key
-     "00.client.example.com.server.example.com". and Server accepts the
-     request. It creates a new key by Diffie-Hellman calculation and
-     returns an answer which includes data such as:
-
-      Answer Section:
-         01.client.example.com.server.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (DH exchange for key renewal)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-
-
-Kamite, et. al.                                                [Page 18]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-     Answer Section also contains KEY RRs for DH.
-
-      Additional Section also contains a TSIG RR.
-     This response is signed with key
-     "00.client.example.com.server.example.com" without error.
-
-     At the same time, Server decides to set the Partial Revocation Time
-     of this new key "01.client.example.com.server.example.com." as next
-     day's 15:00.
-
-     (7) Client gets the response and checks TSIG MAC, and calculates
-     Diffie-Hellman. It will get a new key, and it has been named
-     "01.client.example.com.server.example.com" by Server.
-
-     (8) At 20:07. Client sends an Adoption request to Server. This
-     request is signed with the previous key
-     "00.client.example.com.server.example.com". It includes:
-
-      Question Section:
-         QNAME = 01.client.example.com.server.example.com.
-         TYPE  = TKEY
-
-      Additional Section:
-         01.client.example.com.server.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (key adoption)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-     Additional Section also contains a TSIG RR.
-
-     (9) Server verifies the query's TSIG. It is signed with the
-     previous key and authenticated. It returns a response whose TKEY RR
-     is the same as the request's one. The response is signed with key
-     "00.client.example.com.server.example.com.". As soon as the
-     response is sent, Server revokes and removes the previous key. At
-     the same time, key "01.client.example.com.server.example.com." is
-     validated.
-
-     (10) Client acknowledges the success of Adoption by receiving the
-     response.  Then, it retries to send an original question about
-     "www2.example.com". It is signed with the adopted key
-     "01.client.example.com.server.example.com", so Server authenticates
-     it and returns an answer.
-
-
-
-
-
-Kamite, et. al.                                                [Page 19]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-     (11) This key is used until next day's 15:00. After that, it will
-     be partially revoked again.
-
-
-8.  Security Considerations
-
-   This document considers about how to refresh shared secret. Secret
-   changed by this method is used at servers in support of TSIG
-   [RFC2845].
-
-   [RFC2104] says that current attacks to HMAC do not indicate a
-   specific recommended frequency for key changes but periodic key
-   refreshment is a fundamental security practice that helps against
-   potential weaknesses of the function and keys, and limits the damage
-   of an exposed key. TKEY Secret Key Renewal provides the method of
-   periodical key refreshment.
-
-   In TKEY Secret Key Renewal, clients need to send two requests
-   (Renewal and Adoption) and spend time to finish their key renewal
-   processes. Thus the usage period of secrets should be considered
-   carefully based on both TKEY processing performance and security.
-
-   This document specifies the procedure of periodical key renewal, but
-   actually there is possibility for servers to have no choice other
-   than revoking their secret keys immediately especially when the keys
-   are found to be compromised by attackers. This is called "Emergency
-   Compulsory Revocation". For example, suppose the original Expiry
-   Limit was set at 21:00, Partial Revocation Time at 20:00 and
-   Inception Time at 1:00.  if at 11:00 the key is found to be
-   compromised, the server sets Expiry Limit forcibly to be 11:00 or
-   before it.
-
-   Consequently, once Compulsory Revocation (See section 4.) is carried
-   out, normal renewal process described in this document cannot be done
-   any more as far as the key is concerned. However, after such
-   accidents happened, the two hosts are able to establish secret keys
-   and begin renewal procedure only if they have other (non-compromised)
-   shared TSIG keys or safe SIG(0) keys for the authentication of
-   initial secret establishment such as Diffie-Hellman Exchanged Keying.
-
-
-9.  IANA Considerations
-
-   IANA needs to allocate a value for "DH exchange for key renewal",
-   "server assignment for key renewal", "resolver assignment for key
-   renewal" and "key adoption" in the mode filed of TKEY. It also needs
-   to allocate a value for "PartialRevoke" from the extended RCODE
-   space.
-
-
-
-Kamite, et. al.                                                [Page 20]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-10.  Acknowledgement
-
-   The authors would like to thank Olafur Gudmundsson, whose helpful
-   input and comments contributed greatly to this document.
-
-
-11.  References
-
-[RFC2104]
-     H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
-     Authentication", RFC2104, February 1997.
-
-[RFC2119]
-     Bradner, S., "Key words for use in RFCs to Indicate Requirement
-     Levels", RFC 2119, March 1997.
-
-[RFC2539]
-     D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
-     System (DNS)", RFC 2539, March 1999.
-
-[RFC2845]
-     Vixie, P., Gudmundsson, O., Eastlake, D. and B.  Wellington,
-     "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
-     May 2000.
-
-[RFC2930]
-     D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
-     RFC 2930, September 2000.
-
-[RFC2931]
-     D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
-     )", RFC 2931, September 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.                                                [Page 21]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-Authors' Addresses
-
-   Yuji Kamite
-   NTT Communications Corporation
-   Tokyo Opera City Tower
-   3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
-   163-1421, Japan
-   EMail: y.kamite@ntt.com
-
-
-   Masaya Nakayama
-   Information Technology Center, The University of Tokyo
-   2-11-16 Yayoi, Bunkyo-ku, Tokyo
-   113-8658, Japan
-   EMail: nakayama@nc.u-tokyo.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.                                                [Page 22]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
deleted file mode 100644
index 1133b0c87d49..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
+++ /dev/null
@@ -1,466 +0,0 @@
-
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-UPDATES RFC 2845                                   Motorola Laboratories
-Expires: February 2005                                       August 2004
-
-
-                  HMAC SHA TSIG Algorithm Identifiers
-                  ---- --- ---- --------- -----------
-                  <draft-ietf-dnsext-tsig-sha-00.txt>
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   or will be disclosed, and any of which I become aware will be
-   disclosed, in accordance with RFC 3668.
-
-   This draft is intended to be become a Proposed Standard RFC.
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   Use of the TSIG DNS resource record requires specification of a
-   cryptographic message authentication code.  Currently identifiers
-   have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
-   This document standardizes identifiers for additional HMAC SHA TSIG
-   algorithms and standardizes how to specify the truncation of HMAC
-   values.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2004. All Rights Reserved.
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-
-      2. Algorithms and Identifiers..............................4
-
-      3. Specifying Truncation...................................5
-
-      4. IANA Considerations.....................................6
-      5. Security Considerations.................................6
-      6. Copyright and Disclaimer................................6
-
-      7. Normative References....................................7
-      8. Informative References..................................7
-
-      Authors Address............................................8
-      Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
-   [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
-   authenticate DNS queries and responses. This RR contains a domain
-   name syntax data item which names the authentication algorithm used.
-   [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
-   authentication codes using the HMAC [RFC 2104] algorithm with the MD5
-   [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
-   identifier for TSIG authentication where the cryptographic operations
-   are delegated to GSS [RFC 3645].
-
-   In section 2, this document specifies additional names for TSIG
-   authentication algorithms based on US NIST SHA algorithms and HMAC.
-
-   In section 3, this document specifies the meaning of inequality
-   between the normal output size of the specified hash function and the
-   length of MAC (message authentication code) data given in the TSIG
-   RR. In particular, it specifies that a shorter length field value
-   specifies truncation and a longer length field is an error.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
-   TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
-   queries and responses.  They are intended to be efficient symmetric
-   authentication codes based on a shared secret. (Asymmetric signatures
-   can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
-   can be used for transaction signatures.) Used with a strong hash
-   function, HMAC [RFC 2104] provides a way to calculate such symmetric
-   authentication codes. The only specified HMAC based TSIG algorithm
-   identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
-   The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as
-   compared with the 128 bits for MD5, and additional hash algorithms in
-   the SHA family [FIPS 180-2, RFC sha224] with 224, 256, 384, and 512
-   bits, may be preferred in some case. Use of TSIG between a DNS
-   resolver and server is by mutual agreement. That agreement can
-   include the support of additional algorithms.
-
-   For completeness in relation to HMAC based algorithms, the current
-   HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below.
-   Implementations which support TSIG MUST implement HMAC MD5, SHOULD
-   implement HMAC SHA-1, and MAY implement gss-tsig and the other
-   algorithms listed below.
-
-         Mandatory      HMAC-MD5.SIG-ALG.REG.INT
-         Recommended    hmac-sha1
-         Optional       hmac-sha224
-         Optional       hmac-sha256
-         Optional       hamc-sha384
-         Optional       hmac-sha512
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
-   In some cases, it is reasonable to truncate the output of HMAC and
-   use the truncated value for authentication. HMAC SHA-1 truncated to
-   96 bits is an optional available in several IETF protocols including
-   IPSEC and TLS.
-
-   The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
-   size of the MAC field in octets. But [RFC 2845] does not specify what
-   to do if this MAC size differs from the length of the output of HMAC
-   for a particular hash function.
-
-   The specification for TSIG handling is changed as follows:
-
-   1. If The "MAC size" field is larger than the HMAC output length or
-      is zero: This case MUST NOT be generated and if received MUST
-      cause the packet to be dropped and RCODE 1 (FORMERR) to be
-      returned.
-
-   2. If the "MAC size" field equals the HMAC output length: Operation
-      is as described in [RFC 2845].
-
-   3. If the "MAC size" field is less than the HMAC output length but is
-      not zero: This is sent when the signer has truncated the HMAC
-      output as described in RFC 2104, taking initial octets and
-      discarding trailing octets. TSIG truncation can only be to an
-      integral number of octets. On receipt of a packet with truncation
-      thus indicated, the locally calculated MAC is similarly truncated
-      and only the truncated values compared for authentication.
-
-   TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12
-   octets) and MAY implement any or all other truncations valid under
-   case 3 above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-4. IANA Considerations
-
-   This document, on approval for publication as a standards track RFC,
-   registers the new TSIG algorithm identifiers listed in Section 2 with
-   IANA.
-
-
-
-5. Security Considerations
-
-   For all of the message authentication code algorithms listed herein,
-   those producing longer values are believed to be stronger; however,
-   while there are some arguments that mild truncation can strengthen a
-   MAC by reducing the information available to an attacker, excessive
-   truncation clearly weakens authentication by reducing the number of
-   bits an attacker has to try to force. See [RFC 2104] which recommends
-   that ah HMAC never be truncated to less than half its length nor to
-   less than 80 bits (10 octets).
-
-   See also the Security Considerations section of [RFC 2845].
-
-
-
-6. Copyright and Disclaimer
-
-   Copyright (C) The Internet Society 2004.  This document is subject to
-   the rights, licenses and restrictions contained in BCP 78 and except
-   as set forth therein, the authors retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-7. Normative References
-
-   [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal
-   Information Processing Standard, Draft, 1 August 2002.
-
-   [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
-   1321, April 1992.
-
-   [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-   Hashing for Message Authentication", RFC 2104, February 1997.
-
-   [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
-   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
-   RFC 2845, May 2000.
-
-   [RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R.
-   Housley, December 2003, work in progress, draft-ietf-pkix-
-   sha224-*.txt.
-
-
-
-8. Informative References.
-
-   [FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information
-   Processing Standard, 17 April 1995.
-
-   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
-   Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-   1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
-   J., and R. Hall, "Generic Security Service Algorithm for Secret Key
-   Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
-   2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Authors Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554 (w)
-                +1-508-634-2066 (h)
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in February 2005.
-
-   Its file name is draft-ietf-dnsext-tsig-sha-00.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt
deleted file mode 100644
index d65fa7104251..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt
+++ /dev/null
@@ -1,1010 +0,0 @@
-
-
-
-
-
-
-dnsext Working Group                                           B. Halley
-Internet Draft                                                   Nominum
-Expiration Date: March 2004
-                                                                E. Lewis
-                                                                    ARIN
-
-                                                          September 2003
-
-
-                Clarifying the Role of Wild Card Domains
-                       in the Domain Name System
-
-
-                 draft-ietf-dnsext-wcard-clarify-02.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to 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.
-
-   To view the list Internet-Draft Shadow Directories, see
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   The definition of wild cards is recast from the original in RFC 1034,
-   in words that are more specific and in line with RFC 2119.  This
-   document is meant to supplement the definition in RFC 1034 and to
-   alter neither the spirit nor intent of that definition.
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 1]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-Table of Contents
-
-          Abstract  ................................................   1
-    1     Introduction  ............................................   2
-    1.1   Document Limits  .........................................   3
-    1.2   Existence  ...............................................   4
-    1.3   An Example  ..............................................   4
-    1.4   Empty Non-terminals  .....................................   5
-    1.5   Terminology  .............................................   6
-    2     Defining the Wild Card Domain Name  ......................   7
-    3     Defining Existence  ......................................   8
-    4     Impact of a Wild Card In a Query or in RDATA  ............   8
-    5     Impact of a Wild Card Domain On a Response  ..............   9
-    6     Considerations with Special Types  .......................  12
-    6.1   SOA RR's at a Wild Card Domain Name  .....................  12
-    6.2   NS RR's at a Wild Card Domain Name  ......................  12
-    6.3   CNAME RR's at a Wild Card Domain Name  ...................  13
-    6.4   DNAME RR's at a Wild Card Domain Name  ...................  13
-    7     Security Considerations  .................................  14
-    8     References  ..............................................  14
-    9     Others Contributing to This Document  ....................  14
-   10     Editors  .................................................  15
-          Appendix A: Subdomains of Wild Card Domain Names  ........  16
-          Full Copyright Statement  ................................  18
-          Acknowledgement  .........................................  18
-
-
-
-
-1. Introduction
-
-   The first section of this document will give a crisp overview of what
-   is begin defined, as well as the motivation rewording of an original
-   document and making a change to bring the specification in line with
-   implementations.  Examples are included to help orient the reader.
-
-   Wild card domain names are defined in Section 4.3.3. of RFC 1034 as
-   "instructions for synthesizing RRs." [RFC1034].  The meaning of this
-   is that a specific, special domain name is used to construct
-   responses in instances in which the query name is not otherwise
-   represented in a zone.
-
-   A wild card domain name has a specific range of influence on query
-   names (QNAMEs) within a given class, which is rooted at the domain
-   name containing the wild card label, and is limited by explicit
-   entries, zone cuts and empty non-terminal domains (see section 1.3 of
-   this document).
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 2]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   Note that a wild card domain name has no special impact on the search
-   for a query type (QTYPE).  If a domain name is found that matches the
-   QNAME (exact or a wild card) but the QTYPE is not found at that
-   point, the proper response is that there is no data available.  The
-   search does not continue on to seek other wild cards that might match
-   the QTYPE.  To illustrate, a wild card owning an MX RR does not
-   'cover' other names in the zone that own an A RR.  There are certain
-   special case RR types that will be singled out for discussion, the
-   SOA RR, NS RR, CNAME RR, and DNAME RR.
-
-   Why is this document needed?  Empirical evidence suggests that the
-   words in RFC 1034 are not clear enough.  There exist a number of
-   implementations that have strayed (each differently) from that
-   definition.  There also exists a misconception of operators that the
-   wild card can be used to add a specific RR type to all names, such as
-   the MX RR example cited above.  This document is also needed as input
-   to efforts to extend DNS, such as the DNS Security Extensions [RFC
-   2535].  Lack of a clear base specification has proven to result in
-   extension documents that have unpredictable consequences.  (This is
-   true in general, not just for DNS.)
-
-   Another reason this clarification is needed is to answer questions
-   regarding authenticated denial of existence, a service introduced in
-   the DNS Security Extensions [RFC 2535].  Prior to the work leading up
-   to this document, it had been feared that a large number of proof
-   records (NXTs) might be needed in each reply because of the unknown
-   number of potential wild card domains that were thought to be
-   applicable.  One outcome of this fear is a now discontinued document
-   solving a problem that is now known not to exist.  I.e., this
-   clarification has the impact of defending against unwarranted
-   protocol surgery.  It is not "yet another" effort to just rewrite the
-   early specifications for the sake of purity.
-
-   Although the effort to define the DNS Security Extensions has
-   prompted this document, the clarifications herein relate to basic DNS
-   only.  No DNS Security Extensions considerations are mentioned in the
-   document.
-
-1.1. Document Limits
-
-   This document limits itself to reinforcing the concepts in RFC 1034.
-   In the effort to do this, a few issues have been discussed that
-   change parts of what is in RFC 1034.  The discussions have been held
-   within the DNS Extensions Working Group.
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 3]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   Briefly, the issues raised include:
-     - The lack of clarity in the definition of domain name existence
-     - Implications of a wild card domain name owning any of the
-       following resource record sets: DNAME [RFC 2672], CNAME, NS, and
-       SOA
-     - Whether RFC 1034 meant to allow special processing of CNAME RR's
-       owned by wild card domain names
-
-1.2. Existence
-
-   The notion that a domain name 'exists' will arise numerous times in
-   this discussion.  RFC 1034 raises the issue of existence in a number
-   of places, usually in reference to non-existence and often in
-   reference to processing involving wild card domain names.  RFC 1034
-   contains algorithms that describe how domain names impact the
-   preparation of an answer and does define wild cards as a means of
-   synthesizing answers.  Because of this a discussion on wild card
-   domain names has to start with the issue of existence.
-
-   To help clarify the topic of wild cards, a positive definition of
-   existence is needed.  Complicating matters, though, is the
-   realization that existence is relative.  To an authoritative server,
-   a domain name exists if the domain name plays a role following the
-   algorithms of preparing a response.  To a resolver, a domain name
-   exists if there is any data available corresponding to the name.  The
-   difference between the two is the synthesis of records according to a
-   wild card.
-
-   For the purposes of this document, the point of view of an
-   authoritative server is adopted.  A domain name is said to exist if
-   it plays a role in the execution of the algorithms in RFC 1034.
-
-1.3. An Example
-
-   For example, consider this wild card domain name: *.example.  Any
-   query name under example. is a candidate to be matched (answered) by
-   this wild card, i.e., to have an response returned that is
-   synthesized from the wild card's RR sets.  Although any name is a
-   candidate, not all queries will match.
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 4]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   To further illustrate this, consider this zone:
-
-             $ORIGIN example.
-             @                IN  SOA
-                                  NS
-                                  NS
-             *                    TXT "this is a wild card"
-                                  MX  10 mailhost.example.
-             host1                A   10.0.0.1
-             _ssh._tcp.host1      SRV
-             _ssh._tcp.host2      SRV
-             subdel               NS
-
-
-   The following queries would be synthesized from the wild card:
-
-        QNAME=host3.example. QTYPE=MX, QCLASS=IN
-             the answer will be a "host3.example. IN MX ..."
-        QNAME=host3.example. QTYPE=A, QCLASS=IN
-             the answer will reflect "no error, but no data"
-             because there is no A RR set at '*'
-
-   The following queries would not be synthesized from the wild card:
-
-        QNAME=host1.example., QTYPE=MX, QCLASS=IN
-             because host1.example. exists
-        QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
-             because _tcp.host1.example. exists (without data)
-        QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
-             because host2.example. exists (without data)
-        QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
-             because subdel.example. exists and is a zone cut
-
-   To the server, the following domains are considered to exist in the
-   zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2,
-   _ssh._tcp.host2, and subdel.  To a resolver, many more domains appear
-   to exist via the synthesis of the wild card.
-
-1.4. Empty Non-terminals
-
-   Empty non-terminals are domain names that own no data but have
-   subdomains.  This is defined in section 3.1 of RFC 1034:
-
-#    The domain name space is a tree structure.  Each node and leaf on the
-#    tree corresponds to a resource set (which may be empty).  The domain
-#    system makes no distinctions between the uses of the interior nodes and
-#    leaves, and this memo uses the term "node" to refer to both.
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 5]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   The parenthesized "which may be empty" specifies that empty non-
-   terminals are explicitly recognized.  According to the definition of
-   existence in this document, empty non-terminals do exist at the
-   server.
-
-   Carefully reading the above paragraph can lead to an interpretation
-   that all possible domains exist - up to the suggested limit of 255
-   octets for a domain name [RFC 1035].  For example, www.example. may
-   have an A RR, and as far as is practically concerned, is a leaf of
-   the domain tree.  But the definition can be taken to mean that
-   sub.www.example. also exists, albeit with no data.  By extension, all
-   possible domains exist, from the root on down.  As RFC 1034 also
-   defines "an authoritative name error indicating that the name does
-   not exist" in section 4.3.1, this is not the intent of the original
-   document.
-
-   RFC1034's wording is to be clarified by adding the following
-   paragraph:
-
-        A node is considered to have an impact on the algorithms of
-        4.3.2 if it is a leaf node with any resource sets or an interior
-        node, with or without a resource set, that has a subdomain that
-        is a leaf node with a resource set.  A QNAME and QCLASS matching
-        an existing node never results in a response return code of
-        authoritative name error.
-
-   The terminology in the above paragraph is chosen to remain as close
-   to that in the original document.  The term "with" is a alternate
-   form for "owning" in this case, hence "a leaf node owning resources
-   sets, or an interior node, owning or not owning any resource set,
-   that has a leaf node owning a resource set as a subdomain," is the
-   proper interpretation of the middle sentence.
-
-   As an aside, an "authoritative name error" has been called NXDOMAIN
-   in some RFCs, such as RFC 2136 [RFC 2136].  NXDOMAIN is the mnemonic
-   assigned to such an error by at least one implementation of DNS.  As
-   this mnemonic is specific to implementations, it is avoided in the
-   remainder of this document.
-
-1.5. Terminology
-
-   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 the document entitled
-   "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
-
-   Requirements are denoted by paragraphs that begin with with the
-   following convention: 'R'<sect>.<count>.
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 6]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   Quotations of RFC 1034 (as has already been done once above) are
-   denoted by a '#' in the leftmost column.
-
-2. Defining the Wild Card Domain Name
-
-   A wild card domain name is defined by having the initial label be:
-
-        0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
-   This defines domain names that may play a role in being a wild card,
-   that is, being a source for synthesized answers.  Domain names
-   conforming to this definition that appear in queries and RDATA
-   sections do not have any special role.  These cases will be described
-   in more detail in following sections.
-
-   R2.1 A domain name that is to be interpreted as a wild card MUST
-        begin with a label of '0000 0001 0010 1010' in binary.
-
-   The first octet is the normal label type and length for a 1 octet
-   long label, the second octet is the ASCII representation [RFC 20] for
-   the '*' character.  In RFC 1034, ASCII encoding is assumed to be the
-   character encoding.
-
-   In the master file formats used in RFCs, a "*" is a legal
-   representation for the wild card label.  Even if the "*" is escaped,
-   it is still interpreted as the wild card when it is the only
-   character in the label.
-
-   R2.2 A server MUST treat a wild card domain name as the basis of
-        synthesized answers regardless of any "escape" sequences in the
-        input format.
-
-   RFC 1034 and RFC 1035 ignore the case in which a domain name might be
-   "the*.example.com." The interpretation is that this domain name in a
-   zone would only match queries for "the*.example.com" and not have any
-   other role.
-
-   Note: By virtue of this definition, a wild card domain name may have
-   a subdomain.  The subdomain (or sub-subdomain) itself may also be a
-   wild card.  E.g., *.*.example. is a wild card, so is *.sub.*.example.
-   More discussion on this is given in Appendix A.
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 7]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-3. Defining Existence
-
-   As described in the Introduction, a precise definition of existence
-   is needed.
-
-   R3.1 An authoritative server MUST treat a domain name as existing
-        during the execution of the algorithms in RFC 1034 when the
-        domain name conforms to the following definition.  A domain name
-        is defined to exist if the domain name owns data and/or has a
-        subdomain that exists.
-
-   Note that at a zone boundary, the domain name owns data, including
-   the NS RR set.  At the delegating server, the NS RR set is not
-   authoritative, but that is of no consequence here.  The domain name
-   owns data, therefore, it exists.
-
-   R3.2 An authoritative server MUST treat a domain name that has
-        neither a resource record set nor an existing subdomain as non-
-        existent when executing the algorithm in section 4.3.2. of RFC
-        1034.
-
-   A note on terminology.  A domain transcends zones, i.e., all DNS data
-   is in the root domain but segmented into zones of control.  In this
-   document, there are references to a "domain name" in the context of
-   existing "in a zone." In this usage, a domain name is the root of a
-   domain, not the entire domain.  The domain's root point is said to
-   "exist in a zone" if the zone is authoritative for the name.  RR sets
-   existing in a domain need not be owned by the domain's root domain
-   name, but are owned by other domain names in the domain.
-
-4. Impact of a Wild Card In a Query or in RDATA
-
-   When a wild card domain name appears in a question, e.g., the query
-   name is "*.example.", the response in no way differs from any other
-   query.  In other words, the wild card label in a QNAME has no special
-   meaning, and query processing will proceed using '*' as a literal
-   query name.
-
-   R4.1 A wild card domain name acting as a QNAME MUST be treated as any
-        other QNAME, there MUST be no special processing accorded it.
-
-   If a wild card domain name appears in the RDATA of a CNAME RR or any
-   other RR that has a domain name in it, the same rule applies.  In the
-   instance of a CNAME RR, the wild card domain name is used in the same
-   manner of as being the original QNAME.  For other RR's, rules vary
-   regarding what is done with the domain name(s) appearing in them, in
-   no case does the wild card hold special meaning.
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 8]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   R4.2 A wild card domain name appearing in any RR's RDATA MUST be
-        treated as any other domain name in that situation, there MUST
-        be no special processing accorded it.
-
-5. Impact of a Wild Card Domain On a Response
-
-   The description of how wild cards impact response generation is in
-   RFC 1034, section 4.3.2.  That passage contains the algorithm
-   followed by a server in constructing a response.  Within that
-   algorithm, step 3, part 'c' defines the behavior of the wild card.
-   The algorithm is directly quoted in lines that begin with a '#' sign.
-   Commentary is interleaved.
-
-   There is a documentation issue deserving some explanation.  The
-   algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo
-   code, i.e., it's steps are not intended to be followed in strict
-   order.  The "algorithm" is a suggestion.  As such, in step 3, parts
-   a, b, and c, do not have to be implemented in that order.
-
-   Another issue needing explanation is that RFC 1034 is a full
-   standard.  There is another RFC, RFC 2672, which makes, or proposes
-   an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME
-   RR.  RFC 2672 is a proposed standard.  The dilemma in writing these
-   clarifications is knowing which document is the one being clarified.
-   Fortunately, the difference between RFC 1034 and RFC 2672 is not
-   significant with respect to wild card synthesis, so this document
-   will continue to state that it is clarifying RFC 1034.  If RFC 2672
-   progresses along the standards track, it will need to refer to
-   modifying RFC 1034's algorithm as amended here.
-
-   The context of part 'c' is that the search is progressing label by
-   label through the QNAME.  (Note that the data being searched is the
-   authoritative data in the server, the cache is searched in step 4.)
-   Step 3's part 'a' covers the case that the QNAME has been matched in
-   full, regardless of the presence of a CNAME RR.  Step 'b' covers
-   crossing a cut point, resulting in a referral.  All that is left is
-   to look for the wild card.
-
-   Step 3 of the algorithm also assumes that the search is looking in
-   the zone closest to the answer, i.e., in the same class as QCLASS and
-   as close to the authority as possible on this server.  If the zone is
-   not the authority, then a referral is given, possibly one indicating
-   lameness.
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 9]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-#         c. If at some label, a match is impossible (i.e., the
-#            corresponding label does not exist), look to see if a
-#            the "*" label exists.
-
-   The above paragraph refers to finding the domain name that exists in
-   the zone and that most encloses the QNAME.  Such a domain name will
-   mark the boundary of candidate wild card domain names that might be
-   used to synthesize an answer.  (Remember that at this point, if the
-   most enclosing name is the same as the QNAME, part 'a' would have
-   recorded an exact match.)  The existence of the enclosing name means
-   that no wild card name higher in the tree is a candidate to answer
-   the query.
-
-   Once the closest enclosing node is identified, there's the matter of
-   what exists below it.  It may have subdomains, but none will be
-   closer to the QNAME.  One of the subdomains just might be a wild
-   card.  If it exists, this is the only wild card eligible to be used
-   to synthesize an answer for the query.  Even if the closest enclosing
-   node conforms to the syntax rule in section 2 for being a wild card
-   domain name, the closest enclosing node is not eligible to be a
-   source of a synthesized answer.
-
-   The only wild card domain name that is a candidate to synthesize an
-   answer will be the "*" subdomain of the closest enclosing domain
-   name.  Three possibilities can happen.  The "*" subdomain does not
-   exist, the "*" subdomain does but does not have an RR set of the same
-   type as the QTYPE, or it exists and has the desired RR set.
-
-   For the sake of brevity, the closest enclosing node can be referred
-   to as the "closest encloser." The closest encloser is the most
-   important concept in this clarification.  Describing the closest
-   encloser is a bit tricky, but it is an easy concept.
-
-   To find the closest encloser, you have to first locate the zone that
-   is the authority for the query name.  This eliminates the need to be
-   concerned that the closest encloser is a cut point.  In addition, we
-   can assume too that the query name does not exist, hence the closest
-   encloser is not equal to the query name.  We can assume away these
-   two cases because they are handled in steps 2, 3a and 3b of section
-   4.3.2.'s algorithm.
-
-   What is left is to identify the existing domain name that would have
-   been up the tree (closer to the root) from the query name.  Knowing
-   that an exact match is impossible, if there is a "*" label descending
-   from the unique closest encloser, this is the one and only wild card
-   from which an answer can be synthesized for the query.
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 10]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   To illustrate, using the example in section 1.2 of this document, the
-   following chart shows QNAMEs and the closest enclosers.  In
-   Appendix A there is another chart showing unusual cases.
-
-        QNAME                        Closest Encloser     Wild Card Source
-        host3.example.               example.             *.example.
-        _telnet._tcp.host1.example.  _tcp.host1.example.  no wild card
-        _telnet._tcp.host2.example.  host2.example.       no wild card
-        _telnet._tcp.host3.example.  example.             *.example.
-        _chat._udp.host3.example.    example.             *.example.
-
-   Note that host1.subdel.example. is in a subzone, so the search for it
-   ends in a referral in part 'b', thus does not enter into finding a
-   closest encloser.
-
-   The fact that a closest encloser will be the only superdomain that
-   can have a candidate wild card will have an impact when it comes to
-   designing authenticated denial of existence proofs.
-
-#            If the "*" label does not exist, check whether the name
-#            we are looking for is the original QNAME in the query
-#            or a name we have followed due to a CNAME.  If the name
-#            is original, set an authoritative name error in the
-#            response and exit.  Otherwise just exit.
-
-   The above passage says that if there is not even a wild card domain
-   name to match at this point (failing to find an explicit answer
-   elsewhere), we are to return an authoritative name error at this
-   point.  If we were following a CNAME, the specification is unclear,
-   but seems to imply that a no error return code is appropriate, with
-   just the CNAME RR (or sequence of CNAME RRs) in the answer section.
-
-#            If the "*" label does exist, match RRs at that node
-#            against QTYPE.  If any match, copy them into the answer
-#            section, but set the owner of the RR to be QNAME, and
-#            not the node with the "*" label.  Go to step 6.
-
-   This final paragraph covers the role of the QTYPE in the process.
-   Note that if no resource record set matches the QTYPE the result is
-   that no data is copied, but the search still ceases ("Go to step
-   6.").  In the following section, a suggested change is made to this,
-   under the heading "CNAME RRs at a Wild Card Domain Name."
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 11]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-6. Considerations with Special Types
-
-   For the purposes of this section, "special" means that a record
-   induces processing at the server beyond simple lookup.  The special
-   types in this section are SOA, NS, CNAME, and DNAME.  SOA is special
-   because it is used as a zone marker and has an impact on step 2 of
-   the algorithm in 4.3.2.  NS denotes a cut point and has an impact on
-   step 3b.  CNAME redirects the query and is mentioned in steps 3a and
-   3b.  DNAME is a "CNAME generator."
-
-6.1. SOA RR's at a Wild Card Domain Name
-
-   If the owner of an SOA record conforms to the basic rules of owning
-   an SOA RR (meaning it is the apex of a zone) the impact on the search
-   algorithm is not in section 3c (where records are synthesized) as
-   would be expected.  The impact is really in step 2 of the algorithm,
-   the choice of zone.
-
-   We are no longer talking about whether or not an SOA RR can be
-   synthesized in a response because we are shifting attention to step
-   2.  We are now talking about what it means for a name server to
-   synthesize a zone for a response.  To date, no implementation has
-   done this.  Thinking ahead though, anyone choosing to pursue this
-   would have to be aware that a server would have to be able to
-   distinguish between queries for data it will have to synthesize and
-   queries that ought to be treated as if they were prompted by a lame
-   delegation.
-
-   It is not a protocol error to have an SOA RR owned by a wild card
-   domain name, just as it is not an error to have zone name be
-   syntactically equivalent to a domain name.  However, this situation
-   requires careful consideration of how a server chooses the
-   appropriate zone for an answer.  And an SOA RR is not able to be
-   synthesized as in step 3c.
-
-6.2. NS RR's at a Wild Card Domain Name
-
-   Complimentary to the issue of an SOA RR owned by a wild card domain
-   name is the issue of NS RR's owned by a wild card domain name.  In
-   this instance, each machine being referred to in the RDATA of the NS
-   RR has to be able to understand the impact of this on step 2, the
-   choosing of the authoritative zone.
-
-   Referring to the same machine in such a NS RR will probably not work
-   well.  This is because the server may become confused as to whether
-   the query name ought to be answered by the zone owning the NS RR in
-   question or a synthesized zone.  (It isn't known in advance that the
-   query name will invoke the wild card synthesis.)
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 12]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   The status of other RR's owned by a wild card domain name is the same
-   as if the owner name was not a wild card domain name.  I.e., when
-   there is a NS RR at a wild card domain name, other records are
-   treated as being below the zone cut.
-
-   Is it not a protocol error to have a NS RR owned by a wild card
-   domian name, complimentary to the case of a SOA RR.  However, for
-   this to work, an implementation has to know how to synthesize a zone.
-
-6.3. CNAME RR's at a Wild Card Domain Name
-
-   The issue of CNAME RR's owned by wild card domain names has prompted
-   a suggested change to the last paragraph of step 3c of the algorithm
-   in 4.3.2.  The changed text is this:
-
-        If the "*" label does exist and if the data at the node is a
-        CNAME and QTYPE doesn't match CNAME, copy the CNAME RR into the
-        answer section of the response, set the owner of the CNAME RR to
-        be QNAME, and then change QNAME to the canonical name in the
-        CNAME RR, and go back to step 1.
-
-        If the "*" label does exist and either QTYPE is CNAME or the
-        data at the node is not a CNAME, then match RRs at that node
-        against QTYPE.  If any match, copy them into the answer section,
-        but set the owner of the RR to be QNAME, and not the node with
-        the "*" label.  Go to step 6.
-
-   Apologies if the above isn't clear, but an attempt was made to stitch
-   together the passage using just the phrases in section 3a and 3c of
-   the algorithm so as to preserve the original flavor.
-
-   In case the passage as suggested isn't clear enough, the intent is to
-   make "landing" at a wild card name and finding a CNAME the same as if
-   this happened as a result of a direct match.  I.e., Finding a CNAME
-   at the name matched in step 3c is supposed to have the same impact as
-   finding the CNAME in step 3a.
-
-6.4. DNAME RR's at a Wild Card Domain Name
-
-   The specification of the DNAME RR, which is at the proposed level of
-   standardization, is not as mature as the full standard in RFC 1034.
-   Because of this, or the reason for this is, there appears to be a
-   host of issues with that definition and it's rewrite of the algorithm
-   in 4.3.2.  For the time being, when it comes to wild card processing
-   issues, a DNAME can be considered to be a CNAME synthesizer.  A DNAME
-   at a wild card domain name is effectively the same as a CNAME at a
-   wild card domain name.
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 13]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-7. Security Considerations
-
-   This document is refining the specifications to make it more likely
-   that security can be added to DNS.  No functional additions are being
-   made, just refining what is considered proper to allow the DNS,
-   security of the DNS, and extending the DNS to be more predictable.
-
-8. References
-
-   Normative References
-
-   [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
-
-   [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
-               Nov-01-1987
-
-   [RFC 1035] Domain Names - Implementation and Specification, P.V
-               Mockapetris, Nov-01-1987
-
-   [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
-               Bradner, March 1997
-
-   Informative References
-
-   [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
-               Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
-
-   [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
-
-   [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999
-
-9. Others Contributing to This Document
-
-   Others who have directly caused text to appear in the document: Paul
-   Vixie and Olaf Kolkman.  Many others have indirect influences on the
-   content.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 14]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-10. Editors
-
-        Name:         Bob Halley
-        Affiliation:  Nominum, Inc.
-        Address:      2385 Bay Road, Redwood City, CA 94063 USA
-        Phone:        +1-650-381-6016
-        EMail:        Bob.Halley@nominum.com
-
-        Name:         Edward Lewis
-        Affiliation:  ARIN
-        Address:      3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA
-        Phone:        +1-703-227-9854
-        Email:        edlewis@arin.net
-
-   Comments on this document can be sent to the editors or the mailing
-   list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 15]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-Appendix A: Subdomains of Wild Card Domain Names
-
-   In reading the definition of section 2 carefully, it is possible to
-   rationalize unusual names as legal.  In the example given,
-   *.example. could have subdomains of *.sub.*.example. and even the
-   more direct *.*.example.  (The implication here is that these domain
-   names own explicit resource records sets.)  Although defining these
-   names is not easy to justify, it is important that implementions
-   account for the possibility.  This section will give some further
-   guidence on handling these names.
-
-   The first thing to realize is that by all definitions, subdomains of
-   wild card domain names are legal.  In analyzing them, one realizes
-   that they cause no harm by their existence.  Because of this, they
-   are allowed to exist, i.e., there are no special case rules made to
-   disallow them.  The reason for not preventing these names is that the
-   prevention would just introduce more code paths to put into
-   implementations.
-
-   The concept of "closest enclosing" existing names is important to
-   keep in mind.  It is also important to realize that a wild card
-   domain name can be a closest encloser of a query name.  For example,
-   if *.*.example. is defined in a zone, and the query name is
-   a.*.example., then the closest enclosing domain name is *.example.
-   Keep in mind that the closest encloser is not eligible to be a source
-   of synthesized answers, just the subdomain of it that has the first
-   label "*".
-
-   To illustrate this, the following chart shows some matches.  Assume
-   that the names *.example., *.*.example., and *.sub.*.example. are
-   defined in the zone.
-
-        QNAME               Closest Encloser  Wild Card Source
-        a.example.          example.          *.example.
-        b.a.example.        example.          *.example.
-        a.*.example.        *.example.        *.*.example.
-        b.a.*.example.      *.example.        *.*.example.
-        b.a.*.*.example.    *.*.example.      no wild card
-        a.sub.*.example.    sub.*.example.    *.sub.*.example.
-        b.a.sub.*.example.  sub.*.example.    *.sub.*.example.
-        a.*.sub.*.example.  *.sub.*.example.  no wild card
-        *.a.example.        example.          *.example.
-        a.sub.b.example.    example.          *.example.
-
-   Recall that the closest encloser itself cannot be the wild card.
-   Therefore the match for b.a.*.*.example. has no applicable wild card.
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 16]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   Finally, if a query name is sub.*.example., any answer available will
-   come from an exact name match for sub.*.example.  No wild card
-   synthesis is performed in this case.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 17]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society 2003.  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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 18]
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt
deleted file mode 100644
index e9943015e4e9..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt
+++ /dev/null
@@ -1,1120 +0,0 @@
-
-
-DNS Operations                                                 M. Larson
-Internet-Draft                                                 P. Barber
-Expires: August 16, 2004                                        VeriSign
-                                                       February 16, 2004
-
-
-                  Observed DNS Resolution Misbehavior
-                    draft-ietf-dnsop-bad-dns-res-02
-
-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.
-
-   This Internet-Draft will expire on August 16, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   This Internet-Draft describes DNS name server and resolver behavior
-   that results in a significant query volume sent to the root and
-   top-level domain (TLD) name servers.  In some cases we recommend
-   minor additions to the DNS protocol specification and corresponding
-   changes in name server implementations to alleviate these unnecessary
-   queries. The recommendations made in this document are a direct
-   byproduct of observation and analysis of abnormal query traffic
-   patterns seen at two of the thirteen root name servers and all
-   thirteen com/net TLD name servers.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 1]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   document are to be interpreted as described in RFC 2119 [1].
-
-Table of Contents
-
-   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.     Observed name server misbehavior . . . . . . . . . . . . .   4
-   2.1    Aggressive requerying for delegation information . . . . .   4
-   2.1.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   5
-   2.2    Repeated queries to lame servers . . . . . . . . . . . . .   5
-   2.2.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   6
-   2.3    Inability to follow multiple levels of out-of-zone glue  .   6
-   2.3.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   7
-   2.4    Aggressive retransmission when fetching glue . . . . . . .   7
-   2.4.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   8
-   2.5    Aggressive retransmission behind firewalls . . . . . . . .   8
-   2.5.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   8
-   2.6    Misconfigured NS records . . . . . . . . . . . . . . . . .   9
-   2.6.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .  10
-   2.7    Name server records with zero TTL  . . . . . . . . . . . .  10
-   2.7.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .  11
-   2.8    Unnecessary dynamic update messages  . . . . . . . . . . .  11
-   2.8.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .  11
-   2.9    Queries for domain names resembling IP addresses . . . . .  12
-   2.9.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .  12
-   2.10   Misdirected recursive queries  . . . . . . . . . . . . . .  12
-   2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . .  13
-   2.11   Suboptimal name server selection algorithm . . . . . . . .  13
-   2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . .  13
-   3.     IANA considerations  . . . . . . . . . . . . . . . . . . .  15
-   4.     Security considerations  . . . . . . . . . . . . . . . . .  16
-   5.     Internationalization considerations  . . . . . . . . . . .  17
-          Normative References . . . . . . . . . . . . . . . . . . .  18
-          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  18
-          Intellectual Property and Copyright Statements . . . . . .  19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 2]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-1. Introduction
-
-   Observation of query traffic received by two root name servers and
-   the thirteen com/net TLD name servers has revealed that a large
-   proportion of the total traffic often consists of "requeries".  A
-   requery is the same question (<qname, qtype, qclass>) asked
-   repeatedly at an unexpectedly high rate.  We have observed requeries
-   from both a single IP address and multiple IP addresses.
-
-   By analyzing requery events we have found that the cause of the
-   duplicate traffic is almost always a deficient name server, stub
-   resolver and/or application implementation combined with an
-   operational anomaly.  The implementation deficiencies we have
-   identified to date include well-intentioned recovery attempts gone
-   awry, insufficient caching of failures, early abort when multiple
-   levels of glue records must be followed, and aggressive retry by stub
-   resolvers and/or applications.  Anomalies that we have seen trigger
-   requery events include lame delegations, unusual glue records, and
-   anything that makes all authoritative name servers for a zone
-   unreachable (DoS attacks, crashes, maintenance, routing failures,
-   congestion, etc.).
-
-   In the following sections, we provide a detailed explanation of the
-   observed behavior and recommend changes that will reduce the requery
-   rate.  Some of the changes recommended affect the core DNS protocol
-   specification, described principally in RFC 1034 [2], RFC 1035 [3]
-   and RFC 2181 [4].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 3]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-2. Observed name server misbehavior
-
-2.1 Aggressive requerying for delegation information
-
-   There can be times when every name server in a zone's NS RRset is
-   unreachable (e.g., during a network outage), unavailable (e.g., the
-   name server process is not running on the server host) or
-   misconfigured (e.g., the name server is not authoritative for the
-   given zone, also known as "lame").  Consider a recursive name server
-   that attempts to resolve a query for a domain name in such a zone and
-   discovers that none of the zone's name servers can provide an answer.
-   We have observed a recursive name server implementation that then
-   verifies the zone's NS RRset in its cache by querying for the zone's
-   delegation information: it sends a query for the zone's NS RRset to
-   one of the parent zone's name servers.
-
-   For example, suppose that "example.com" has the following NS RRset:
-
-     example.com.   IN   NS   ns1.example.com.
-     example.com.   IN   NS   ns2.example.com.
-
-   Upon receipt of a query for "www.example.com" and assuming that
-   neither "ns1.example.com" nor "ns2.example.com" can provide an
-   answer, this recursive name server implementation immediately queries
-   a "com" zone name server for the "example.com" NS RRset to verify it
-   has the proper delegation information.  This name server
-   implementation performs this query to a zone's parent zone for each
-   recursive query it receives that fails because of a completely
-   unresponsive set of name servers for the target zone.  Consider the
-   effect when a popular zone experiences a catastrophic failure of all
-   its name servers: now every recursive query for domain names in that
-   zone sent to this name server implementation results in a query to
-   the failed zone's parent name servers.  On one occasion when several
-   dozen popular zones became unreachable, the query load on the com/net
-   name servers increased by 50%.
-
-   We believe this verification query is not reasonable.  Consider the
-   circumstances: When a recursive name server is resolving a query for
-   a domain name in a zone it has not previously searched, it uses the
-   list of name servers in the referral from the target zone's parent.
-   If on its first attempt to search the target zone, none of the name
-   servers in the referral is reachable, a verification query to the
-   parent is pointless: this query to the parent would come so quickly
-   on the heels of the referral that it would be almost certain to
-   contain the same list of name servers.  The chance of discovering any
-   new information is slim.
-
-   The other possibility is that the recursive name server successfully
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 4]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   contacts one of the target zone's name servers and then caches the NS
-   RRset from the authority section of a response, the proper behavior
-   according to section 5.4.1 of RFC 2181 [4], because the NS RRset from
-   the target zone is more trustworthy than delegation information from
-   the parent zone.  If, while processing a subsequent recursive query,
-   the recursing name server discovers that none of the name servers
-   specified in the cached NS RRset is available or authoritative,
-   querying the parent would be wrong.  An NS RRset from the parent zone
-   would now be less trustworthy than data already in the cache.
-
-   For this query of the parent zone to be useful, the target zone's
-   entire set of name servers would have to change AND the former set of
-   name servers would have to be deconfigured and/or decommissioned AND
-   the delegation information in the parent zone would have to be
-   updated with the new set of name servers, all within the TTL of the
-   target zone's NS RRset.  We believe this scenario is uncommon:
-   administrative best practices dictate that changes to a zone's set of
-   name servers happen gradually, with servers that are removed from the
-   NS RRset left authoritative for the zone as long as possible.  The
-   scenarios that we can envision that would benefit from the parent
-   requery behavior do not outweigh its damaging effects.
-
-2.1.1 Recommendation
-
-   Name servers offering recursion MUST NOT send a query for the NS
-   RRset of a non-responsive zone to any of the name servers for that
-   zone's parent zone.  For the purposes of this injunction, a
-   non-responsive zone is defined as a zone for which every name server
-   listed in the zone's NS RRset:
-
-   1.  is not authoritative for the zone (i.e., lame), or,
-
-   2.  returns a server failure response (RCODE=2), or,
-
-   3.  is dead or unreachable according to section 7.2 of RFC 2308 [5].
-
-
-2.2 Repeated queries to lame servers
-
-   Section 2.1 describes a catastrophic failure: when every name server
-   for a zone is unable to provide an answer for one reason or another.
-   A more common occurrence is a subset of a zone's name servers being
-   unavailable or misconfigured.  Different failure modes have different
-   expected durations.  Some symptoms indicate problems that are
-   potentially transient: various types of ICMP unreachable messages
-   because a name server process is not running or a host or network is
-   unreachable, or a complete lack of a response to a query.  Such
-   responses could be the result of a host rebooting or temporary
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 5]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   outages; these events don't necessarily require any human
-   intervention and can be reasonably expected to be temporary.
-
-   Other symptoms clearly indicate a condition requiring human
-   intervention, such as lame server: if a name server is misconfigured
-   and not authoritative for a zone delegated to it, it is reasonable to
-   assume that this condition has potential to last longer than
-   unreachability or unresponsiveness.  Consequently, repeated queries
-   to known lame servers are not useful.  In this case of a condition
-   with potential to persist for a long time, a better practice would be
-   to maintain a list of known lame servers and avoid querying them
-   repeatedly in a short interval.
-
-2.2.1 Recommendation
-
-   Recursive name servers SHOULD cache name servers that they discover
-   are not authoritative for zones delegated to them (i.e. lame
-   servers). Lame servers MUST be cached against the specific query
-   tuple <zone name, class, server IP address>.  Zone name can be
-   derived from the owner name of the NS record that was referenced to
-   query the name server that was discovered to be lame.
-   Implementations that perform lame server caching MUST refrain from
-   sending queries to known lame servers based on a time interval from
-   when the server is discovered to be lame.  A minimum interval of
-   thirty minutes is RECOMMENDED.
-
-2.3 Inability to follow multiple levels of out-of-zone glue
-
-   Some recursive name server implementations are unable to follow more
-   than one level of out-of-zone glue.  For example, consider the
-   following delegations:
-
-     foo.example.        IN   NS   ns1.example.com.
-     foo.example.        IN   NS   ns2.example.com.
-
-     example.com.        IN   NS   ns1.test.example.net.
-     example.com.        IN   NS   ns2.test.example.net.
-
-     test.example.net.   IN   NS   ns1.test.example.net.
-     test.example.net.   IN   NS   ns2.test.example.net.
-
-   A name server processing a recursive query for "www.foo.example" must
-   follow two levels of indirection, first obtaining address records for
-   "ns1.test.example.net" and/or "ns2.test.example.net" in order to
-   obtain address records for "ns1.example.com" and/or "ns2.example.com"
-   in order to query those name servers for the address records of
-   "www.foo.example".  While this situation may appear contrived, we
-   have seen multiple similar occurrences and expect more as new generic
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 6]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   top-level domains (gTLDs) become active.  We anticipate many zones in
-   the new gTLDs will use name servers in other gTLDs, increasing the
-   amount of inter-zone glue.
-
-2.3.1 Recommendation
-
-   Clearly constructing a delegation that relies on multiple levels of
-   out-of-zone glue is not a good administrative practice.  This issue
-   could be mitigated with an operational injunction in an RFC to
-   refrain from construction of such delegations.  In our opinion the
-   practice is widespread enough to merit clarifications to the DNS
-   protocol specification to permit it on a limited basis.
-
-   Name servers offering recursion SHOULD be able to handle at least
-   three levels of indirection resulting from out-of-zone glue.
-
-2.4 Aggressive retransmission when fetching glue
-
-   When an authoritative name server responds with a referral, it
-   includes NS records in the authority section of the response.
-   According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
-   server should also "put whatever addresses are available into the
-   additional section, using glue RRs if the addresses are not available
-   from authoritative data or the cache."  Some name server
-   implementations take this address inclusion a step further with a
-   feature called "glue fetching".  A name server that implements glue
-   fetching attempts to include A records for every NS record in the
-   authority section.  If necessary, the name server issues multiple
-   queries of its own to obtain any missing A records.
-
-   Problems with glue fetching can arise in the context of
-   "authoritative-only" name servers, which only serve authoritative
-   data and ignore requests for recursion.  Such a server will not
-   generate any queries of its own.  Instead it answers non-recursive
-   queries from resolvers looking for information in zones it serves.
-   With glue fetching enabled, however, an authoritative server will
-   generate queries whenever it needs to look up an unknown address
-   record to complete the additional section of a response.
-
-   We have observed situations where a glue-fetching name server can
-   send queries that reach other name servers, but apparently is
-   prevented from receiving the responses.  For example, perhaps the
-   name server is authoritative-only and therefore its administrators
-   expect it to receive only queries.  Perhaps unaware of glue fetching
-   and presuming that the name server will generate no queries, its
-   administrators place the name server behind a network device that
-   prevents it from receiving responses.  If this is the case, all
-   glue-fetching queries will go answered.
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 7]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   We have observed name server implementations that retry excessively
-   when glue-fetching queries are unanswered.  A single com/net name
-   server has received hundreds of queries per second from a single name
-   server.  Judging from the specific queries received and based on
-   additional analysis, we believe these queries result from overly
-   aggressive glue fetching.
-
-2.4.1 Recommendation
-
-   Implementers whose name servers support glue fetching should take
-   care to avoid sending queries at excessive rates.  Implementations
-   should support throttling logic to detect when queries are sent but
-   no responses are received.
-
-2.5 Aggressive retransmission behind firewalls
-
-   A common occurrence and one of the largest sources of repeated
-   queries at the com/net and root name servers appears to result from
-   resolvers behind misconfigured firewalls.  In this situation, a
-   recursive name server is apparently allowed to send queries through a
-   firewall to other name servers, but not receive the responses.  The
-   result is more queries than necessary because of retransmission, all
-   of which are useless because the responses are never received.  Just
-   as with the glue-fetching scenario described in Section 2.4, the
-   queries are sometimes sent at excessive rates.  To make matters
-   worse, sometimes the responses, sent in reply to legitimate queries,
-   trigger an alarm on the originator's intrusion detection system.  We
-   are frequently contacted by administrators responding to such alarms
-   who believe our name servers are attacking their systems.
-
-   Not only do some resolvers in this situation retransmit queries at an
-   excessive rate, but they continue to do so for days or even weeks.
-   This scenario could result from an organization with multiple
-   recursive name servers, only a subset of whose traffic is improperly
-   filtered in this manner.  Stub resolvers in the organization could be
-   configured to query multiple name servers.  Consider the case where a
-   stub resolver queries a filtered name server first.  This name server
-   sends one or more queries whose replies are filtered, so it can't
-   respond to the stub resolver, which times out.  The resolver
-   retransmits to a name server that is able to provide an answer.
-   Since resolution ultimately succeeds the underlying problem might not
-   be recognized or corrected.  A popular stub resolver has a very
-   aggressive retransmission schedule, including simultaneous queries to
-   multiple name servers, which could explain how such a situation could
-   persist without being detected.
-
-2.5.1 Recommendation
-
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 8]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   The most obvious recommendation is that administrators should take
-   care not to place recursive name servers behind a firewall that
-   prohibits queries to pass through but not the resulting replies.
-
-   Name servers should take care to avoid sending queries at excessive
-   rates.  Implementations should support throttling logic to detect
-   when queries are sent but no responses are received.
-
-2.6 Misconfigured NS records
-
-   Sometimes a zone administrator forgets to add the trailing dot on the
-   domain names in the RDATA of a zone's NS records.  Consider this
-   fragment of the zone file for "example.com":
-
-     $ORIGIN example.com.
-     example.com.      3600   IN   NS   ns1.example.com  ; Note missing
-     example.com.      3600   IN   NS   ns2.example.com  ; trailing dots
-
-   The zone's authoritative servers will parse the NS RDATA as
-   "ns1.example.com.example.com" and "ns2.example.com.example.com" and
-   return NS records with this incorrect RDATA in responses, including
-   typically the authority section of every response containing records
-   from the "example.com" zone.
-
-   Now consider a typical sequence of queries.  A recursive name server
-   attempting to resolve A records for "www.example.com" with no cached
-   information for this zone will query a "com" authoritative server.
-   The "com" server responds with a referral to the "example.com" zone,
-   consisting of NS records with valid RDATA and associated glue
-   records. (This example assumes that the "example.com" zone
-   information is correct in the "com" zone.)  The recursive name server
-   caches the NS RRset from the "com" server and follows the referral by
-   querying one of the "example.com" authoritative servers.  This server
-   responds with the "www.example.com" A record in the answer section
-   and, typically, the "example.com" NS records in the authority section
-   and, if space in the message remains, glue A records in the
-   additional section. According to Section 5.4 of RFC 2181 [4], NS
-   records in the authority section of an authoritative answer are more
-   trustworthy than NS records from the authority section of a
-   non-authoritative answer.  Thus the "example.com" NS RRset just
-   received from the "example.com" authoritative server displaces the
-   "example.com" NS RRset received moments ago from the "com"
-   authoritative server.
-
-   But the "example.com" zone contains the erroneous NS RRset as shown
-   in the example above.  Subsequent queries for names in "example.com"
-   will cause the server to attempt to use the incorrect NS records and
-   so the server will try to resolve the nonexistent names
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 9]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   "ns1.example.com.example.com" and "ns2.example.com.example.com".  In
-   this example, since all of the zone's name servers are named in the
-   zone itself (i.e., "ns1.example.com.example.com" and
-   "ns2.example.com.example.com" both end in "example.com") and all are
-   bogus, the recursive server cannot reach any "example.com" name
-   servers.  Therefore attempts to resolve these names result in A
-   record queries to the "com' authoritative servers.  Queries for such
-   obviously bogus glue A records occur frequently at the com/net name
-   servers.
-
-2.6.1 Recommendation
-
-   An authoritative server can detect this situation.  A trailing dot
-   missing from an NS record's RDATA always results by definition in a
-   name server name that is in the zone.  But any in-zone name server
-   should have a corresponding glue A record also in the zone.  An
-   authoritative name server should report an error when a zone's NS
-   record references an in-zone name server without a corresponding glue
-   A record.
-
-2.7 Name server records with zero TTL
-
-   Sometimes a popular com/net subdomain's zone is configured with a TTL
-   of zero on the zone's NS records, which prohibits these records from
-   being cached and will result in a higher query volume to the zone's
-   authoritative servers.  The zone's administrator should understand
-   the consequences of such a configuration and provision resources
-   accordingly.  A zero TTL on the zone's NS RRset, however, carries
-   additional consequences beyond the zone itself: if a recursive name
-   server cannot cache a zone's NS records because of a zero TTL, it
-   will be forced to query that zone's parent's name servers each time
-   it resolves a name in the zone.  The com/net authoritative servers do
-   see an increased query load when a popular com/net subdomain's zone
-   is configured with a TTL of zero on the zone's NS records.
-
-   A zero TTL on an RRset expected to change frequently is extreme but
-   permissible.  A zone's NS RRset is a special case, however, because
-   changes to it must be coordinated with the zone's parent.  In most
-   zone parent/child relationships we are aware of, there is typically
-   some delay involved in effecting changes.  Further, changes to the
-   set of a zone's authoritative name servers (and therefore to the
-   zone's NS RRset) are typically relatively rare: providing reliable
-   authoritative service requires a reasonably stable set of servers.
-   Therefore an extremely low or zero TTL on a zone's NS RRset rarely
-   makes sense, except in anticipation of an upcoming change.  In this
-   case, when the zone's administrator has planned a change and does not
-   want recursive name servers throughout the Internet to cache the NS
-   RRset for a long period of time, a low TTL is reasonable.
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 10]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-2.7.1 Recommendation
-
-   Because of the additional load placed on a zone's parent's
-   authoritative servers imposed by a zero TTL on a zone's NS RRset,
-   under such circumstances authoritative name servers should issue a
-   warning when loading a zone or refuse to load the zone altogether.
-
-2.8 Unnecessary dynamic update messages
-
-   The UPDATE message specified in RFC 2136 [6] allows an authorized
-   agent to update a zone's data on an authoritative name server using a
-   DNS message sent over the network.  Consider the case of an agent
-   desiring to add a particular resource record. Because of zone cuts,
-   the agent does not necessarily know the proper zone to which the
-   record should be added.  The dynamic update process requires that the
-   agent determine the appropriate zone so the UPDATE message can be
-   sent to one of the zone's authoritative servers (typically the
-   primary master as specified in the zone's SOA MNAME field).
-
-   The appropriate zone to update is the closest enclosing zone, which
-   is the lowest zone in the name space.  The closest enclosing zone
-   cannot be determined only by inspecting the domain name of the record
-   to be updated, since zone cuts can occur anywhere.  One way to
-   determine the closest enclosing zone involves working up the name
-   space tree and sending repeated UPDATE messages until success.  For
-   example, consider an agent attempting to add an A record with the
-   name "foo.bar.example.com".  The agent could first attempt to update
-   the "foo.bar.example.com" zone.  If the attempt failed, the update
-   could be directed to the "bar.example.com" zone, then the
-   "example.com" zone, then the "com" zone, and finally the root zone.
-
-   A popular dynamic agent follows this algorithm.  The result is many
-   UPDATE messages received by the root name servers, the com/net
-   authoritative servers, and presumably other TLD authoritative
-   servers. A reasonable question is why the algorithm proceeds with
-   sending updates all the way to TLD and root name servers.  In
-   enterprise DNS architectures with an "internal root" design, there
-   could conceivably be private, non-public TLD or root zones that would
-   be the appropriate target for a dynamic update.  However, we question
-   if designing an algorithm to accommodate these limited cases is worth
-   the load it places on the public DNS in the form of unnecessary
-   UPDATE messages.
-
-2.8.1 Recommendation
-
-   Dynamic update agents should not attempt to send UPDATE messages to
-   authoritative servers for TLD zones or the root zone by default.  If
-   this functionality is supported, it should be require specific action
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 11]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   by a user to be enabled.
-
-2.9 Queries for domain names resembling IP addresses
-
-   The root name servers receive a significant number of A record
-   queries where the qname is an IP address.  The source of these
-   queries is unknown.  It could be attributed to situations where a
-   user believes an application will accept either a domain name or an
-   IP address in a given configuration option.  The user enters an IP
-   address, but the application assumes any input is a domain name and
-   attempts to resolve it, resulting in an A record lookup.  There could
-   also be applications that produce such queries in a misguided attempt
-   to reverse map IP addresses.
-
-   These queries result in Name Error (RCODE=3) responses.  A recursive
-   name server can negatively cache such responses, but each response
-   requires a separate cache entry, i.e., a negative cache entry for the
-   domain name "192.0.2.1" does not prevent a subsequent query for the
-   domain name "192.0.2.2".
-
-2.9.1 Recommendation
-
-   It would be desirable for the root name servers not to have to answer
-   these queries: they unnecessarily consume CPU resources and network
-   bandwidth.  One possibility is for recursive name server
-   implementations to produce the Name Error response directly.  We
-   suggest that implementors consider the option of synthesizing Name
-   Error responses at the recursive name server.  The server could claim
-   authority for synthesized TLD zones corresponding to the first octet
-   of every possible IP address, e.g. 1., 2., through 255.  This
-   behavior could be configurable in the (probably unlikely) event that
-   numeric TLDs are ever put into use.
-
-   Another option is to delegate these numeric TLDs from the root zone
-   to a separate set of servers to absorb the traffic.  The "blackhole
-   servers" used by the the AS 112 Project [8], which are currently
-   delegated the in-addr.arpa zones corresponding to RFC 1918 [7]
-   private use address space, would be a possible choice to receive
-   these delegations.
-
-2.10 Misdirected recursive queries
-
-   The root name servers receive a significant number of recursive
-   queries (i.e., queries with the RD bit set in the header).  Since
-   none of the root servers offer recursion, the servers' response in
-   such a situation ignores the request for recursion and the response
-   probably does not contain the data the querier anticipated.  Some of
-   these queries result from users configuring stub resolvers to query a
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 12]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   root server.  (This situation is not hypothetical: we have received
-   complaints from users when this configuration does not work as
-   hoped.) Of course, users should not direct stub resolvers to use name
-   servers that do not offer recursion, but we are not aware of any stub
-   resolver implementation that offers any feedback to the user when so
-   configured, aside from simply "not working".
-
-2.10.1 Recommendation
-
-   When the IP address of a (supposedly) recursive name server is
-   configured in a stub resolver using an interactive user interface,
-   the resolver could send a test query to verify that the server
-   supports recursion (i.e., the response has the RA bit set in the
-   header).  The user could be immediately notified if the server is
-   non-recursive.
-
-   The stub resolver could also report an error, either through a user
-   interface or in a log file, if the queried server does not support
-   recursion.  Error reporting should be throttled to avoid a
-   notification or log message for every response from a non-recursive
-   server.
-
-2.11 Suboptimal name server selection algorithm
-
-   An entire document could be devoted to the topic of problems with
-   different implementations of the recursive resolution algorithm.  The
-   entire process of recursion is woefully underspecified, requiring
-   each implementor to design an algorithm.  Sometimes implementors make
-   poor design choices that could be avoided if a suggested algorithm
-   and best practices were documented, but that is a topic for another
-   document.
-
-   Some deficiencies cause significant operational impact and are
-   therefore worth mentioning here.  One of these is name server
-   selection by a recursive name server.  When a recursive name server
-   wants to contact one of a zone's authoritative name servers, how does
-   it choose from the NS records listed in the zone's NS RRset?  If the
-   selection mechanism is suboptimal, queries are not spread evenly
-   among a zone's authoritative servers.  The details of the selection
-   mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1 Recommendation
-
-   This list is not conclusive, but reflects the changes that would
-   produce the most impact in terms of reducing disproportionate query
-   load among a zone's authoritative servers.  I.e., these changes would
-   help spread the query load evenly.
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 13]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   o  Do not make assumptions based on NS RRset order: all NS RRs should
-      be treated equally.  (In the case of the "com" zone, for example,
-      most of the root servers return the NS record for
-      "a.gtld-servers.net" first in the authority section of referrals.
-      As a result, this server receives disproportionately more traffic
-      than the other 12 authoritative servers for "com".)
-
-   o  Use all NS records in an RRset.  (For example, we are aware of
-      implementations that hard-coded information for a subset of the
-      root servers.)
-
-   o  Maintain state and favor the best-performing of a zone's
-      authoritative servers.  A good definition of performance is
-      response time. Non-responsive servers can be penalized with an
-      extremely high response time.
-
-   o  Do not lock onto the best-performing of a zone's name servers.  A
-      recursive name server should periodically check the performance of
-      all of a zone's name servers to adjust its determination of the
-      best-performing one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 14]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-3. IANA considerations
-
-   There are no new IANA considerations introduced by this
-   Internet-Draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 15]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-4. Security considerations
-
-   Name server and resolver misbehaviors identical or similar to those
-   discussed in this document expose the root and TLD name servers to
-   increased risk of both intentional and unintentional denial of
-   service.
-
-   We believe that implementation of the recommendations offered in this
-   document will reduce the amount of unnecessary traffic seen at root
-   and TLD name servers, thus reducing the opportunity for an attacker
-   to use such queries to his or her advantage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 16]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-5. Internationalization considerations
-
-   We do not believe this document introduces any new
-   internationalization considerations to the DNS protocol
-   specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 17]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [3]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [4]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-        RFC 2181, July 1997.
-
-   [5]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-        2308, March 1998.
-
-   [6]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-        Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
-        1997.
-
-   [7]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
-        Lear, "Address Allocation for Private Internets", BCP 5, RFC
-        1918, February 1996.
-
-   [8]  <http://www.as112.net>
-
-
-Authors' Addresses
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Piet Barber
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: pbarber@verisign.com
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 18]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004). 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 assignees.
-
-   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
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 19]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 20]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
deleted file mode 100644
index 04815175fdba..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
+++ /dev/null
@@ -1,1344 +0,0 @@
-

-DNSOP                                                         O. Kolkman

-Internet-Draft                                                  RIPE NCC

-Expires: August 30, 2004                                       R. Gieben

-                                                              NLnet Labs

-                                                              March 2004

-

-

-                      DNSSEC Operational Practices

-         draft-ietf-dnsop-dnssec-operational-practices-01.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.

-

-   This Internet-Draft will expire on August 30, 2004.

-

-Copyright Notice

-

-   Copyright (C) The Internet Society (2004). All Rights Reserved.

-

-Abstract

-

-   This document describes a set of practices for operating a DNSSEC

-   aware environment.  The target audience is zone administrators

-   deploying DNSSEC that need a guide to help them chose appropriate

-   values for DNSSEC parameters.  It also discusses operational matters

-   such as key rollovers, KSK and ZSK considerations and related

-   matters.

-

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 1]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

-     1.1   The Use of the Term 'key'  . . . . . . . . . . . . . . . .  3

-     1.2   Keeping the Chain of Trust Intact  . . . . . . . . . . . .  3

-   2.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . .  4

-     2.1   Time Definitions . . . . . . . . . . . . . . . . . . . . .  4

-     2.2   Time Considerations  . . . . . . . . . . . . . . . . . . .  5

-   3.  Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6

-     3.1   Motivations for the KSK and ZSK Functions  . . . . . . . .  7

-     3.2   Key Security Considerations  . . . . . . . . . . . . . . .  8

-       3.2.1   Key Validity Period  . . . . . . . . . . . . . . . . .  8

-       3.2.2   Key Algorithm  . . . . . . . . . . . . . . . . . . . .  8

-       3.2.3   Key Sizes  . . . . . . . . . . . . . . . . . . . . . .  8

-     3.3   Key Rollovers  . . . . . . . . . . . . . . . . . . . . . .  9

-       3.3.1   Zone-signing Key Rollovers . . . . . . . . . . . . . . 10

-       3.3.2   Key-signing Key Rollovers  . . . . . . . . . . . . . . 13

-   4.  Planning for Emergency Key Rollover  . . . . . . . . . . . . . 14

-     4.1   KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15

-     4.2   ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15

-     4.3   Compromises of Keys Anchored in Resolvers  . . . . . . . . 16

-   5.  Parental Policies  . . . . . . . . . . . . . . . . . . . . . . 16

-     5.1   Initial Key Exchanges and Parental Policies

-           Considerations . . . . . . . . . . . . . . . . . . . . . . 16

-     5.2   Storing Keys So Hashes Can Be Regenerated  . . . . . . . . 16

-     5.3   Security Lameness Checks . . . . . . . . . . . . . . . . . 17

-     5.4   DS Signature Validity Period . . . . . . . . . . . . . . . 17

-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17

-   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17

-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18

-   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 18

-   8.2   Informative References . . . . . . . . . . . . . . . . . . . 18

-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19

-   A.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 19

-   B.  Zone-signing Key Rollover Howto  . . . . . . . . . . . . . . . 20

-   C.  Typographic Conventions  . . . . . . . . . . . . . . . . . . . 20

-   D.  Document Details and Changes . . . . . . . . . . . . . . . . . 22

-     D.1   draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22

-     D.2   draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22

-       Intellectual Property and Copyright Statements . . . . . . . . 23

-

-

-

-

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 2]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-1.  Introduction

-

-   During workshops and early operational deployment tests, operators

-   and system administrators gained experience about operating DNSSEC

-   aware DNS services.  This document translates these experiences into

-   a set of practices for zone administrators. At the time of writing,

-   there exists very little experience with DNSSEC in production

-   environments, this document should therefore explicitly not be seen

-   as represented 'Best Current Practices'.

-

-   The procedures herein are focused on the maintenance of signed zones

-   (i.e. signing and publishing zones on authoritative servers). It is

-   intended that maintenance of zones such as resigning or key rollovers

-   be transparent to any verifying clients on the Internet.

-

-   The structure of this document is as follows: It begins with

-   discussing some of the considerations with respect to timing

-   parameters of DNS in relation to DNSSEC (Section 2). Aspects of key

-   management such as key rollover schemes are described in Section 3.

-   Emergency rollover considerations are addressed in Section 4.  The

-   typographic conventions used in this document are explained in

-   Appendix C.

-

-   Since this is a document with operational suggestions and there are

-   no protocol specifications, the RFC2119 [5] language does not apply.

-

-1.1  The Use of the Term 'key'

-

-   It is assumed that the reader is familiar with the concept of

-   asymmetric keys on which DNSSEC is based (Public Key Cryptography

-   [Ref to Schneider?]). Therefore, this document will use the term

-   'key' rather loosely. Where it is written that 'a key is used to sign

-   data' it is assumed that the reader understands that it is the

-   private part of the key-pair that is used for signing. It is also

-   assumed that the reader understands that the public part of the

-   key-pair is published in the DNSKEY resource record and that it is

-   used in key-exchanges.

-

-1.2  Keeping the Chain of Trust Intact

-

-   Maintaining a valid chain of trust is important because broken chains

-   of trust will result in data being marked as bogus, which may cause

-   entire (sub)domains to become invisible to verifying clients. The

-   administrators of secured zones have to realise that their zone is,

-   to their clients, part of a chain of trust.

-

-   As mentioned in the introduction, the procedures herein are intended

-   to ensure maintenance of zones, such as resigning or key rollovers,

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 3]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   be transparent to the verifying clients on the Internet.

-   Administrators of secured zones will have to keep in mind that data

-   published on an authoritative primary server will not be immediately

-   seen by verifying clients; it may take some time for the data to be

-   transfered to other secondary authoritative nameservers, during which

-   period clients may be fetching data from caching non-authoritative

-   servers.  For the verifying clients it is important that  data from

-   secured zones can be used to build chains of trust regardless of

-   whether the  data came directly from an authoritative server, a

-   caching nameserver or some middle box. Only by carefully using the

-   available timing parameters can a zone administrator  assure that the

-   data necessary for verification can be obtained.

-

-   The responsibility for maintaining the chain of trust is shared by

-   administrators of secured zones in the chain of trust. This is most

-   obvious in the case of a 'key compromise' when a trade off between

-   maintaining a valid chain of trust and the fact that the key has been

-   stolen, must be made.

-

-   The zone administrator will have to make a tradeoff between keeping

-   the chain of trust intact  -thereby allowing for attacks with the

-   compromised key- or to deliberately break the chain of trust thereby

-   making secured subdomains invisible to security aware resolvers. Also

-   see Section 4.

-

-2.  Time in DNSSEC

-

-   Without DNSSEC all times in DNS are relative. The SOA's refresh,

-   retry and expiration timers are counters that are used to determine

-   the time elapsed after a slave server syncronised (or tried to

-   syncronise) with a master server. The Time to Live (TTL) value and

-   the SOA minimum TTL parameter [6] are used to determine how long a

-   forwarder should cache data after it has been fetched from an

-   authoritative server. DNSSEC introduces the notion of an absolute

-   time in the DNS. Signatures in DNSSEC have an expiration date after

-   which the signature is marked as invalid and the signed data is to be

-   considered bogus.

-

-2.1  Time Definitions

-

-   In this document we will be using a number of time related terms.

-   Within the context of this document the following definitions apply:

-   o  "Signature validity period"

-         The period that a signature is valid. It starts at the time

-         specified in the signature inception field of the RRSIG RR and

-         ends at the time specified in the expiration field of the RRSIG

-         RR.

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 4]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   o  "Signature publication period"

-         Time after which a signature (made with a specific key) is

-         replaced with a new signature (made with the same key). This

-         replacement takes place by publishing the relevant RRSIG in the

-         master zone file.  If a signature is published at time T0 and a

-         new signature is published at time T1, the signature

-         publication period is T1 - T0.

-         If all signatures are refreshed at zone (re)signing then the

-         signature publication period is equal signature validity

-         period.

-   o  "Maximum/Minimum Zone TTL"

-         The maximum or minimum value of all the TTLs in a zone.

-

-2.2  Time Considerations

-

-   Because of the expiration of signatures, one should consider the

-   following.

-   o  The Maximum Zone TTL of your zone data should be a fraction of

-      your signature validity period.

-         If the TTL would be of similar order as the signature validity

-         period, then all RRsets fetched during the validity period

-         would be cached until the signature expiration time.  As a

-         result query load on authoritative servers would peak at

-         signature expiration time.

-         To avoid query load peaks we suggest the TTL on all the RRs in

-         your zone to be at least a few times smaller than your

-         signature validity period.

-   o  The signature publication period should be at least one maximum

-      TTL smaller than the signature validity period.

-         Resigning a zone shortly before the end of the signature

-         validity period may cause simultaneous expiration of data from

-         caches. This in turn may lead to peaks in the load on

-         authoritative servers.

-   o  The Minimum zone TTL should be long enough to both fetch and

-      verify all the RRs in the authentication chain.

-            1. During validation, some data may expire before the

-            validation is complete. The validator should be able to keep

-            all data, until is completed. This applies to all RRs needed

-            to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and

-            the final answers i.e. the RR that is returned for the

-            initial query.

-            2. Frequent verification causes load on recursive

-            nameservers. Data at delegation points, DSs, DNSKEYs and

-            RRSIGs benefit from caching. The TTL on those should be

-            relatively long.

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 5]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-         We have seen events where data needed for verification of an

-         authentication chain had expired from caches.

-         We suggest the TTL on DNSKEY and DSs to be between ten minutes

-         and one hour.  We recommend zone administrators to chose TTLs

-         longer than half a minute.

-         [Editor's Note: this observation could be implementation

-         specific. We are not sure if we should leave this item]

-   o  Slave servers will need to be able to fetch newly signed zones

-      well before the data expires from your zone.

-         'Better no answers than bad answers.'

-         If a properly implemented slave server is not able to contact a

-         master server for an extended period the data will at some

-         point expire and the slave server will not hand out any data.

-         If the server serves a DNSSEC zone than it may well happen that

-         the signatures expire well before the SOA expiration timer

-         counts down to zero. It is not possible to completely prevent

-         this from happening by tweaking the SOA parameters. However,

-         the effects can be minimized where the SOA expiration time is

-         equal or smaller than the signature validity period.

-         The consequence of an authoritative server not being able to

-         update a zone, whilst that zone includes expired signaturs, is

-         that non-secure resolvers will continue to be able to resolve

-         data served by the particular slave servers. Security aware

-         resolvers will experience problems.

-         We suggest the SOA expiration timer being approximately one

-         third or one fourth of the signature validity period. It will

-         allow problems with transfers from the master server to be

-         noticed before the actual signature time out.

-         We suggest that operators of nameservers with slave zones

-         develop 'watch dogs' to spot upcoming signature expirations in

-         slave zones, and take appropriate action.

-         When determining the value for the expiration parameter one has

-         to take the following into account: What are the chances that

-         all my secondary zones expire; How quickly can I reach an

-         administrator and load a valid zone? All these arguments are

-         not DNSSEC specific.

-

-3.  Keys

-

-   In the DNSSEC protocol there is only one type of key, the zone key.

-   With this key, the data in a zone is signed.

-

-   To make zone re-signing and key rollovers procedures easier to

-   implement, it is possible to use one or more keys as Key Signing Keys

-   (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other

-   keys can be used to sign all the RRsets in a zone and are referred to

-   as Zone Signing Keys (ZSK). In this document we assume that KSKs are

-   the subset of keys that are used for key exchanges with the parents

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 6]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   and potentially for configuration as trusted anchors - the so called

-   Secure Entry Point keys (SEP). In this document we assume a

-   one-to-one mapping between KSK and SEP keys and we assume the SEP

-   flag [4] to be set on KSKs.

-

-3.1  Motivations for the KSK and ZSK Functions

-

-   Differentiating between the KSK to ZSK functions has several

-   advantages:

-

-   o  Making the KSK stronger (i.e. using more bits in the key material)

-      has little operational impact since it is only used to sign a

-      small fraction of the zone data.

-   o  As the KSK is only used to sign a keyset, which is most probably

-      updated less frequently than other data in the zone, it can be

-      stored separately from (and thus in a safer location than) the

-      ZSK.

-   o  A KSK can be used for longer periods.

-   o  No parent/child interaction is required when ZSKs are updated.

-

-   The KSK is used less than ZSK, once a keyset is signed with the KSK

-   all the keys in the keyset can be used as ZSK. If a ZSK is

-   compromised, it can be simply dropped from the keyset. The new keyset

-   is then resigned with the KSK.

-

-   Given the assumption that for KSKs the SEP flag is set, the KSK can

-   be distinguished from a ZSK by examining the flag field in the DNSKEY

-   RR. If the flag field is an odd number it is a KSK if it is an even

-   number it is a ZSK e.g. a value of 256 and a key signing key has 257.

-

-   The zone-signing key can be used to sign all the data in a zone on a

-   regular basis. When a zone-signing key is to be rolled, no

-   interaction with the parent is needed.  This allows for relatively

-   short "Signature Validity Periods". That is, Signature Validity

-   Periods of the order of days.

-

-   The key-signing key is only to be used to sign the Key RR set from

-   the zone apex. If a key-signing key is to be rolled over, there will

-   be interactions with parties other than the zone administrator such

-   as the registry of the parent zone or administrators of verifying

-   resolvers that have the particular key configured as trusted entry

-   points. Hence, the "Key Usage Time" of these keys can and should be

-   made much longer. Although, given a long enough key, the "Key Usage

-   Time" can be on the order of years we suggest to plan for a "Key

-   Usage Time" of the order of a few months so that a key rollover

-   remains an operational routine.

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 7]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-3.2  Key Security Considerations

-

-   Keys in DNSSEC have a number of parameters which should all be chosen

-   with care, the most important once are: size, algorithm and the key

-   validity period (its lifetime).

-

-3.2.1  Key Validity Period

-

-   RFC2541 [2] describes a number of considerations with respect to the

-   security of keys. The document deals with the generation, lifetime,

-   size and storage of private keys.

-

-   In Section 3 of RFC2541 [2] there are some suggestions for a key

-   validity period: 13 months for long-lived keys and 36 days for

-   transaction keys but suggestions for key sizes are not made.

-

-   If we say long-lived keys are key-signing keys and transactions keys

-   are zone-signing keys, these recommendations will lead to rollovers

-   occurring frequently enough to become part of 'operational habits';

-   the procedure does not have to be reinvented every time a key is

-   replaced.

-

-3.2.2  Key Algorithm

-

-   We recommend you choose RSA/SHA-1 as the preferred algorithm for the

-   key. RSA has been developed in an open and transparent manner. As the

-   patent on RSA expired in 2001, its use is now also free. The current

-   known attacks on RSA can be defeated by making your key longer. As

-   the MD5 hashing algorithm is showing (theoretical) cracks, we

-   recommend the usage of SHA1.

-

-3.2.3  Key Sizes

-

-   When choosing key sizes, zone administrators will need to take into

-   account how long a key will be used and how much data will be signed

-   during the key publication period. It is hard to give precise

-   recommendations but Lenstra and Verheul [9] supplied the following

-   table with lower bound estimates for cryptographic key sizes. Their

-   recommendations are based on a set of explicitly formulated parameter

-   settings, combined with existing data points about cryptosystems. For

-   details we refer to the original paper.

-

-   [Editor's Note: DSA???]

-

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 8]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   	Year		RSA Key Sizes	Elliptic Curve Key Size

-   	2000		952			132

-   	2001		990			135

-   	2002		1028			139

-   	2003		1068			140

-   	2004		1108			143

-

-   	2005		1149			147

-   	2006		1191			148

-   	2007		1235			152

-   	2008		1279			155

-   	2009		1323			157

-

-

-   	2010		1369			160

-   	2011		1416			163

-   	2012		1464			165

-   	2013		1513			168

-   	2014		1562			172

-

-   	2015		1613			173

-   	2016		1664			177

-   	2017		1717			180

-   	2018		1771			181

-   	2019		1825			185

-

-

-   	2020		1881			188

-   	2021		1937			190

-   	2022		1995			193

-   	2023		2054			197

-   	2024		2113			198

-

-   	2025		2174			202

-   	2026		2236			205

-   	2027		2299			207

-   	2028		2362			210

-   	2029		2427			213

-

-   For example, should you wish your key to last three years from 2003,

-   check the RSA keysize values for 2006 in this table. In this case

-   1191.

-

-3.3  Key Rollovers

-

-   Key rollovers are a fact of life when using DNSSEC. A DNSSEC key

-   cannot be used forever (see RFC2541 [2] and Section 3.2 ).  Zone

-   administrators who are in the process of rolling their keys have to

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 9]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   take into account that data published in previous versions of their

-   zone still lives in caches. When deploying DNSSEC, this becomes an

-   important consideration; ignoring data that may be in caches may lead

-   to loss of service for clients.

-

-   The most pressing example of this is when zone material signed with

-   an old key is being validated by a resolver which does not have the

-   old zone key cached. If the old key is no longer present in the

-   current zone, this validation fails, marking the data bogus.

-   Alternatively, an attempt could be made to validate data which is

-   signed with a new key against an old key that lives in a local cache,

-   also resulting in data being marked bogus.

-

-   To appreciate the situation one could think of a number of

-   authoritative servers that may not be instantaneously running the

-   same version of a zone and a security aware non-recursive resolver

-   that sits behind security aware caching forwarders.

-

-   Note that KSK rollovers and ZSK rollovers are different. A zone-key

-   rollover can be handled in two different ways: pre-publish (Section

-   Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The

-   pre-publish technique works because the key-signing key stays the

-   same during this ZSK rollover. With this KSK a cache is able to

-   validate the new keyset of a zone. With a KSK rollover a cache can

-   not validate the new keyset, because it does not trust the new KSK.

-

-   [Editors note: This needs more verbose explanation, nobody will

-   appreciate the situation just yet. Help with text and examples is

-   appreciated]

-

-3.3.1  Zone-signing Key Rollovers

-

-   For zone-signing key rollovers there are two ways to make sure that

-   during the rollover data still cached can be verified with the new

-   keysets or newly generated signatures can be verified with the keys

-   still in caches. One schema uses double signatures, it is described

-   in Section 3.3.1.2, the other uses key pre-publication (Section

-   3.3.1.1). The pros, cons and recommendations are described in Section

-   3.3.1.3.

-

-3.3.1.1  Pre-publish Keyset Rollover

-

-   This section shows how to perform a ZSK rollover without the need to

-   sign all the data in a zone twice - the so called "prepublish

-   rollover". We recommend this method because it has advantages in the

-   case of key compromise. If the old key is compromised, the new key

-   has already been distributed in the DNS. The zone administrator is

-   then able to quickly switch to the new key and remove the compromised

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 10]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   key from the zone. Another major advantage is that the zone size does

-   not double, as is the case with the double signature ZSK rollover. A

-   small "HOWTO" for this kind of rollover can be found in Appendix B.

-

-       normal          pre-roll         roll            after

-

-       SOA0            SOA1             SOA2            SOA3

-       RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)

-

-       DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1

-       DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11

-                       DNSKEY11         DNSKEY11

-       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)

-       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)

-

-

-   normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.

-      DNSKEY 10 is used to sign all the data of the zone, the

-      zone-signing key.

-   pre-roll: DNSKEY 11 is introduced into the keyset. Note that no

-      signatures are generated with this key yet, but this does not

-      secure against brute force attacks on the public key.  The minimum

-      duration of this pre-roll phase is the time it takes for the data

-      to propagate to the authoritative servers plus TTL value of the

-      keyset. This equates to two times the Maximum Zone TTL.

-   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign

-      the data in the zone exclusively  (i.e. all the signatures from

-      DNSKEY 10 are removed from the zone). DNSKEY 10 remains published

-      in the keyset. This way data that was loaded into caches from

-      version 1 of the zone can still be verified with key sets fetched

-      from version 2 of the zone.

-      The minimum time that the keyset including DNSKEY 10 is to be

-      published is the time that it takes for zone data from the

-      previous version of the zone to expire from old caches i.e. the

-      time it takes for this zone to propagate to all authoritative

-      servers plus the Maximum Zone TTL value of any of the data in the

-      previous version of the zone.

-   after: DNSKEY 10 is removed from the zone. The keyset, now only

-      containing DNSKEY 11 is resigned with the DNSKEY 1.

-

-   The above scheme can be simplified by always publishing the "future"

-   key immediately after the rollover. The scheme would look as follows

-   (we show two rollovers); the future key is introduced in "after" as

-   DNSKEY 12 and again a newer one, numbered 13, in "2nd after":

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 11]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-       normal          roll            after           2nd roll        2nd after

-

-       SOA0            SOA2            SOA3            SOA4            SOA5

-       RRSIG10(SOA0)   RRSIG11(SOA2)   RRSIG11(SOA3)   RRSIG12(SOA4)   RRSIG12(SOA5)

-

-       DNSKEY1         DNSKEY1         DNSKEY1         DNSKEY1         DNSKEY1

-       DNSKEY10        DNSKEY10        DNSKEY11        DNSKEY11        DNSKEY12

-       DNSKEY11        DNSKEY11        DNSKEY12        DNSKEY12        DNSKEY13

-       RRSIG1(DNSKEY)  RRSIG1 (DNSKEY) RRSIG1(DNSKEY)  RRSIG1(DNSKEY)  RRSIG1(DNSKEY)

-       RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)

-

-

-   Note that the key introduced after the rollover is not used for

-   production yet; the private key can thus be stored in a physically

-   secure manner and does not need to be 'fetched' every time a zone

-   needs to be signed.

-

-   This scheme has the benefit that the key that is intended for future

-   use: immediately during an emergency rollover assuming that the

-   private key was stored in a physically secure manner.

-

-3.3.1.2  Double Signature Zone-signing Key Rollover

-

-   This section shows how to perform a ZSK key rollover using the double

-   zone data signature scheme, aptly named "double sig rollover".

-

-   During the rollover stage the new version of the zone file will need

-   to propagate to all authoritative servers and the data that exists in

-   (distant) caches will need to expire, this will take at least the

-   maximum Zone TTL .

-

-       normal              roll              after

-

-       SOA0                SOA1              SOA2

-       RRSIG10(SOA0)       RRSIG10(SOA1)     RRSIG11(SOA2)

-                           RRSIG11(SOA1)

-

-       DNSKEY1             DNSKEY1           DNSKEY1

-       DNSKEY10            DNSKEY10          DNSKEY11

-                           DNSKEY11

-       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)    RRSIG1(DNSKEY)

-       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)   RRSIG11(DNSKEY)

-                           RRSIG11(DNSKEY)

-

-   normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.

-      DNSKEY 10 is used to sign all the data of the zone, the

-      zone-signing key.

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 12]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced

-      into the keyset and all the data in the zone is signed with DNSKEY

-      10 and DNSKEY 11. The rollover period will need to exist until all

-      data from version 0 of the zone has expired from remote caches.

-      This will take at least the maximum Zone TTL of version 0 of the

-      zone.

-   after: DNSKEY 10 is removed from the zone. All the signatures from

-      DNSKEY 10 are removed from the zone. The keyset, now only

-      containing DNSKEY 11, is resigned with DNSKEY 1.

-

-   At every instance the data from the previous version of the zone can

-   be verified with the key from the current version and vice verse. The

-   data from the current version can be verified with the data from the

-   previous version of the zone. The duration of the rollover phase and

-   the period between rollovers should be at least the "Maximum Zone

-   TTL".

-

-   Making sure that the rollover phase lasts until the signature

-   expiration time of the data in version 0 of the zone is recommended.

-   However, this date could be considerably longer than the Maximum Zone

-   TTL, making the rollover a lengthy procedure.

-

-   Note that in this example we assumed that the zone was not modified

-   during the rollover. New data can be introduced in the zone as long

-   as it is signed with both keys.

-

-3.3.1.3  Pros and Cons of the Schemes

-

-   Prepublish-keyset rollover: This rollover does not involve signing

-      the zone data twice. Instead, just before the actual rollover, the

-      new key is published in the keyset and thus available for

-      cryptanalysis attacks. A small disavantage is that this process

-      requires four steps. Also the prepublish scheme will not work for

-      KSKs as explained in Section 3.3.

-   Double signature rollover: The drawback of this signing scheme is

-      that during the rollover the number of signatures in your zone

-      doubles, this may be prohibitive if you have very big zones.  An

-      advantage is that it only requires three steps.

-

-3.3.2  Key-signing Key Rollovers

-

-   For the rollover of a key-signing key the same considerations as for

-   the rollover of a zone-signing key apply. However we can use a double

-   signature scheme to guarantee that old data (only the apex keyset) in

-   caches can be verified with a new keyset and vice versa.

-

-   Since only the keyset is signed with a KSK, zone size considerations

-   do not apply.

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 13]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-       normal          roll            after

-

-       SOA0            SOA1            SOA2

-       RRSIG10(SOA0)   RRSIG10(SOA1)   RRSIG10(SOA2)

-

-       DNSKEY1         DNSKEY1         DNSKEY2

-                       DNSKEY2

-       DNSKEY10        DNSKEY10        DNSKEY10

-       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)

-                       RRSIG2 (DNSKEY)

-       RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)

-

-   normal: Version 0 of the zone.  The parental DS points to DNSKEY1.

-      Before the rollover starts the child will have to verify what the

-      TTL is of the DS RR that points to DNSKEY1 - it is needed during

-      the rollover and we refer to the value as TTL_DS.

-   roll: During the rollover phase the zone administrator generates a

-      second KSK, DNSKEY2. The key is provided to the parent and the

-      child will have to wait until a new DS RR has been generated that

-      points to DNSKEY2. After that DS RR has been published on _all_

-      servers authoritative for the parents zone, the zone administrator

-      has to wait at least TTL_DS to make sure that the old DS RR has

-      expired from distant caches.

-   after: DNSKEY1 has been removed.

-

-   The scenario above puts the responsibility for maintaining a valid

-   chain of trust with the child. It also is based on the premises that

-   the parent only has one DS RR (per algorithm) per zone. St John [The

-   draft has expired] proposed a mechanism where using an established

-   trust relation, the interaction can be performed in-band. In this

-   mechanism there are periods where there are two DS RRs at the parent.

-

-   [Editors note: We probably need to mention more]

-

-4.  Planning for Emergency Key Rollover

-

-   This section deals with preparation for a possible key compromise.

-   Our advice is to have a documented procedure ready for when a key

-   compromise is suspected or confirmed.

-

-   [Editors note: We are much in favor of a rollover tactic that keeps

-   the authentication chain intact as long as possible. This means that

-   one has to take all the regular rollover properties into account.]

-

-   When the private material of one of your keys is compromised it can

-   be used for as long as a valid authentication chain exists.  An

-   authentication chain remains intact for:

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 14]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   o  as long as a signature over the compromised key in the

-      authentication chain is valid,

-   o  as long as a parental DS RR (and signature) points to the

-      compromised key,

-   o  as long as the key is anchored in a resolver and is used as a

-      starting point for validation. (This is the hardest to update.)

-   While an authentication chain to your compromised key exists, your

-   name-space is vulnerable to abuse by the malicious key holder (i.e.

-   the owner of the compromised key). Zone operators have to make a

-   trade off if the abuse of the compromised key is worse than having

-   data in caches that cannot be validated. If the zone operator chooses

-   to break the authentication chain to the compromised key, data in

-   caches signed with this key cannot be validated. However, if the zone

-   administrator chooses to take the path of a regular roll-over, the

-   malicious key holder can spoof data so that it appears to be valid,

-   note that this kind of attack will usually be localised in the

-   Internet topology.

-

-

-4.1  KSK Compromise

-

-   When the KSK has been compromised the parent must be notified as soon

-   as possible using secure means. The keyset of the zone should be

-   resigned as soon as possible. Care must be taken to not break the

-   authentication chain. The local zone can only be resigned with the

-   new KSK after the parent's zone has been updated with the new KSK.

-   Before this update takes place it would be best to drop the security

-   status of a zone all together: the parent removes the DS of the child

-   at the next zone update.  After that the child can be made secure

-   again.

-

-   An additional danger of a key compromise is that the compromised key

-   can be used to facilitate a legitimate DNSKEY/DS and/or nameserver

-   rollover at the parent. When that happens the domain can be in

-   dispute. An out of band and secure notify mechanism to contact a

-   parent is needed in this case.

-

-4.2  ZSK Compromise

-

-   Primarily because there is no parental interaction required when a

-   ZSK is compromised, the situation is less severe than with with a KSK

-   compromise.  The zone must still be resigned with a new ZSK as soon

-   as possible. As this is a local operation and requires no

-   communication between the parent and child this can be achieved

-   fairly quickly. However, one has to take into account that just as

-   with a normal rollover the immediate disappearance from the old

-   compromised key may lead to verification problems. The

-   pre-publication scheme as discussed above minimises such problems.

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 15]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-4.3  Compromises of Keys Anchored in Resolvers

-

-   A key can also be pre-configured in resolvers. If DNSSEC is rolled

-   out as planned the root key should be pre-configured in every secure

-   aware resolver on the planet. [Editors Note: add more about

-   authentication of a newly received  resolver key]

-

-   If trust-anchor keys are compromised, the resolvers using these keys

-   should be notified of this fact. Zone administrators may consider

-   setting up a mailing list to communicate the fact that a SEP key is

-   about to be rolled over. This communication will of course need to be

-   authenticated e.g. by using digital signatures.

-

-5.  Parental Policies

-

-5.1  Initial Key Exchanges and Parental Policies Considerations

-

-   The initial key exchange is always subject to the policies set by the

-   parent (or its registry). When designing a key exchange policy one

-   should take into account that the authentication and authorisation

-   mechanisms used during a key exchange should be as strong as the

-   authentication and authorisation mechanisms used for the exchange of

-   delegation information between parent and child.

-

-   Using the DNS itself as the source for the actual DNSKEY material,

-   with an off-band check on the validity of the DNSKEY, has the benefit

-   that it reduces the chances of user error. A parental DNSKEY download

-   tool can make use of the SEP bit [4] to select the proper key from a

-   DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is

-   sent. It can validate the self-signature over a key; thereby

-   verifying the ownership of the private key material. Fetching the

-   DNSKEY from the DNS ensures that the child will not become bogus once

-   the parent publishes the DS RR indicating the child is secure.

-

-   Note: the off-band verification is still needed when the key-material

-   is fetched by a tool. The parent can not be sure whether the DNSKEY

-   RRs have been spoofed.

-

-5.2  Storing Keys So Hashes Can Be Regenerated

-

-   When designing a registry system one should consider if the DNSKEYs

-   and/or the corresponding DSs are stored. Storing DNSKEYs will help

-   during troubleshooting while the overhead of calculating DS records

-   from them is minimal.

-

-   Having an out-of-band mechanism, such as a Whois database, to find

-   out which keys are used to generate DS Resource Records for specific

-   owners may also help with troubleshooting.

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 16]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-5.3  Security Lameness Checks

-

-   Security Lameness is defined as what happens when a parent has a DS

-   Resource Record pointing to a non-existing DNSKEY RR. During key

-   exchange a parent should make sure that the child's key is actually

-   configured in the DNS before publishing a DS RR in its zone. Failure

-   to do so would render the child's zone being marked as bogus.

-

-   Child zones should be very careful removing DNSKEY material,

-   specifically SEP keys, for which a DS RR exists.

-

-   Once a zone is "security lame" a fix (e.g. by removing a DS RR) will

-   take time to propagate through the DNS.

-

-5.4  DS Signature Validity Period

-

-   Since the DS can be replayed as long as it has a valid signature a

-   short signature validity period over the DS minimises the time a

-   child is vulnerable in the case of a compromise of the child's

-   KSK(s).  A signature validity period that is too short introduces the

-   possibility that a zone is marked bogus in case of a configuration

-   error in the signer; there may not be enough time to fix the problems

-   before signatures expire.  Something as mundane as operator

-   unavailability during weekends shows the need for DS signature

-   lifetimes longer than 2 days. We recommend the minimum for a DS

-   signature validity period to be a few days.

-

-   The maximum signature lifetime of the DS record depends on how long

-   child zones are willing to be vulnerable after a key compromise. We

-   consider a signature validity period of around one week to be a good

-   compromise between the operational constraints of the parent and

-   minimising damage for the child.

-

-6.  Security Considerations

-

-   DNSSEC adds data integrity to the DNS. This document tries to assess

-   considerations to operate a stable and secure DNSSEC service. Not

-   taking into account the 'data propagation' properties in the DNS will

-   cause validation failures and may make secured zones unavailable to

-   security aware resolvers.

-

-7.  Acknowledgments

-

-   We, the folk mentioned as authors, only acted as editors. Most of the

-   ideas in this draft were the result of collective efforts during

-   workshops, discussions and try outs.

-

-   At the risk of forgetting individuals who where the original

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 17]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   contributors of the ideas we would like to acknowledge people who

-   where actively involved in the compilation of this document. In

-   random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,

-   Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier

-   Courtay, Sam Weiler.

-

-   Emma Bretherick and Adrian Bedford corrected many of the spelling and

-   style issues.

-

-   Kolkman and Gieben take the blame for introducing all miscakes(SIC).

-

-8.  References

-

-8.1  Normative References

-

-   [1]  Eastlake, D., "Domain Name System Security Extensions", RFC

-        2535, March 1999.

-

-   [2]  Eastlake, D., "DNS Security Operational Considerations", RFC

-        2541, March 1999.

-

-   [3]  Lewis, E., "DNS Security Extension Clarification on Zone

-        Status", RFC 3090, March 2001.

-

-   [4]  Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key

-        (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work

-        in progress), February 2003.

-

-8.2  Informative References

-

-   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement

-        Levels", BCP 14, RFC 2119, March 1997.

-

-   [6]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC

-        2308, March 1998.

-

-   [7]  Gudmundsson, O., "Delegation Signer Resource Record",

-        draft-ietf-dnsext-delegation-signer-13 (work in progress), March

-        2003.

-

-   [8]  Arends, R., "Protocol Modifications for the DNS Security

-        Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in

-        progress), March 2003.

-

-   [9]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",

-        The Journal of Cryptology 14 (255-293), 2001.

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 18]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-Authors' Addresses

-

-   Olaf M. Kolkman

-   RIPE NCC

-   Singel 256

-   Amsterdam  1016 AB

-   The Netherlands

-

-   Phone: +31 20 535 4444

-   EMail: olaf@ripe.net

-   URI:   http://www.ripe.net/

-

-

-   Miek Gieben

-   NLnet Labs

-   Kruislaan 419

-   Amsterdam  1098 VA

-   The Netherlands

-

-   EMail: miek@nlnetlabs.nl

-   URI:   http://www.nlnetlabs.nl

-

-Appendix A.  Terminology

-

-   In this document there is some jargon used that is defined in other

-   documents. In most cases we have not copied the text from the

-   documents defining the terms but given a more elaborate explanation

-   of the meaning. Note that these explanations should not be seen as

-   authoritative.

-

-   Private and Public Keys: DNSSEC secures the DNS through the use of

-      public key cryptography. Public key cryptography is based on the

-      existence of two keys, a public key and a private key. The public

-      keys are published in the DNS by use of the DNSKEY Resource Record

-      (DNSKEY RR). Private keys should remain private i.e. should not be

-      exposed to parties not-authorised to do the actual signing.

-   Signer: The system that has access to the private key material and

-      signs the Resource Record sets in a zone. A signer may be

-      configured to sign only parts of the zone e.g. only those RRsets

-      for which existing signatures are about to expire.

-   KSK: A Key-Signing Key (KSK) is a key that is used exclusively for

-      signing the apex keyset.  The fact that a key is a KSK is only

-      relevant to the signing tool.

-   ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all

-      data in a zone.  The fact that a key is a ZSK is only relevant to

-      the signing tool.

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 19]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   SEP Key: A KSK that has a parental DS record pointing to it. Note:

-      this is not enforced in the protocol. A SEP Key with no parental

-      DS is security lame.

-   Anchored Key: A DNSKEY configured in resolvers around the globe. This

-      Key is hard to update, hence the term anchored.

-   Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked

-      "Bogus" when a signature of a RRset does not validate against the

-      DNSKEY. Even if the key itself was not marked Bogus. A cache may

-      choose to cache Bogus data for various reasons.

-   Singing the Zone File: The term used for the event where an

-      administrator joyfully signs its zone file while producing melodic

-      sound patterns.

-   Zone Administrator: The 'role' that is responsible for signing a zone

-      and publishing it on the primary authoritative server.

-

-Appendix B.  Zone-signing Key Rollover Howto

-

-   Using the pre-published signature scheme and the most conservative

-   method to assure oneself that data does not live in distant caches

-   here follows the "HOWTO". [WES: has some comments about this]

-   Key notation:

-   Step 0: The preparation: Create two keys and publish both in your

-      keyset.  Mark one of the keys as "active" and the other as

-      "published". Use the "active" key for signing your zone data.

-      Store the private part of the "published" key, preferably

-      off-line.

-   Step 1: Determine expiration: At the beginning of the rollover make a

-      note of the highest expiration time of signatures in your zone

-      file created with the current key marked as "active".

-      Wait until the expiration time marked in Step 1 has passed

-   Step 2: Then start using the key that was marked as "published" to

-      sign your data i.e. mark it as "active". Stop using the key that

-      was marked as "active", mark it as "rolled".

-   Step 3: It is safe to engage in a new rollover (Step 1) after at

-      least one "signature validity period".

-

-Appendix C.  Typographic Conventions

-

-   The following typographic conventions are used in this document:

-   Key notation: A key is denoted by KEYx, where x is a number, x could

-      be thought of as the key id.

-   RRset notations: RRs are only denoted by the type. All other

-      information - owner, class, rdata and TTL - is left out. Thus:

-      example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a

-      list of RRs. A example of this would be: A1,A2, specifying the

-      RRset containing two A records. This could again be abbreviated to

-      just: A.

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 20]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   Signature notation: Signatures are denoted as RRSIGx(RRset), which

-      means that RRset is signed with DNSKEYx.

-   Zone representation: Using the above notation we have simplified the

-      representation of a signed zone by leaving out all unnecessary

-      details such as the names and by  representing all data by "SOAx"

-   SOA representation: SOA's are represented as SOAx, where x is the

-      serial number.

-   Using this notation the following zone :

-

-

-   example.net.      600     IN SOA  ns.example.net. ernie.example.net. (

-                                     10         ; serial

-                                     450        ; refresh (7 minutes 30 seconds)

-                                     600        ; retry (10 minutes)

-                                     345600     ; expire (4 days)

-                                     300        ; minimum (5 minutes)

-                                     )

-                     600     RRSIG   SOA 5 2 600 20130522213204 (

-                                     20130422213204 14 example.net.

-                                     cmL62SI6iAX46xGNQAdQ... )

-                     600     NS      a.iana-servers.net.

-                     600     NS      b.iana-servers.net.

-                     600     RRSIG   NS 5 2 600 20130507213204 (

-                                     20130407213204 14 example.net.

-                                     SO5epiJei19AjXoUpFnQ ... )

-                     3600    DNSKEY  256 3 5 (

-                                     EtRB9MP5/AvOuVO0I8XDxy0...

-                                     ) ; key id = 14

-                     3600    DNSKEY  256 3 5 (

-                                     gsPW/Yy19GzYIY+Gnr8HABU...

-                                     ) ; key id = 15

-                     3600    RRSIG   DNSKEY 5 2 3600 20130522213204 (

-                                     20130422213204 14 example.net.

-                                     J4zCe8QX4tXVGjV4e1r9... )

-                     3600    RRSIG   DNSKEY 5 2 3600 20130522213204 (

-                                     20130422213204 15 example.net.

-                                     keVDCOpsSeDReyV6O... )

-                     600     NSEC    a.example.net. NS SOA TXT RRSIG DNSKEY NSEC

-                     600     RRSIG   NSEC 5 2 600 20130507213204 (

-                                     20130407213204 14 example.net.

-                                     obj3HEp1GjnmhRjX... )

-   a.example.net.    600     IN TXT  "A label"

-                     600     RRSIG   TXT 5 3 600 20130507213204 (

-                                     20130407213204 14 example.net.

-                                     IkDMlRdYLmXH7QJnuF3v... )

-                     600     NSEC    b.example.com. TXT RRSIG NSEC

-                     600     RRSIG   NSEC 5 3 600 20130507213204 (

-                                     20130407213204 14 example.net.

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 21]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-                                     bZMjoZ3bHjnEz0nIsPMM... )

-

-                     ...

-

-

-    is reduced to the following represenation:

-

-       SOA10

-       RRSIG14(SOA10)

-

-       DNSKEY14

-       DNSKEY15

-

-       RRSIG14(KEY)

-       RRSIG15(KEY)

-

-    The rest of the zone data has the same signature as the SOA record,

-   i.e a RRSIG created with DNSKEY 14.

-

-Appendix D.  Document Details and Changes

-

-   This section is to be removed by the RFC editor if and when the

-   document is published.

-

-   $Header: /var/cvs/dnssec-key/

-   draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12

-   08:29:11 dnssec Exp $

-

-D.1  draft-ietf-dnsop-dnssec-operational-practices-00

-

-   Submission as working group document. This document is a modified and

-   updated version of draft-kolkman-dnssec-operational-practices-00.

-

-D.2  draft-ietf-dnsop-dnssec-operational-practices-01

-

-   changed the definition of "Bogus" to reflect the one in the protocol

-   draft.

-

-   Bad to Bogus

-

-   Style and spelling corrections

-

-   KSK - SEP mapping made explicit.

-

-   Updates from Sam Weiler added

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 22]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-Intellectual Property Statement

-

-   The IETF takes no position regarding the validity or scope of any

-   intellectual property or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; neither does it represent that it

-   has made any effort to identify any such rights. Information on the

-   IETF's procedures with respect to rights in standards-track and

-   standards-related documentation can be found in BCP-11. Copies of

-   claims of rights made available for publication and any assurances of

-   licenses to be made available, or the result of an attempt made to

-   obtain a general license or permission for the use of such

-   proprietary rights by implementors or users of this specification can

-   be obtained from the IETF Secretariat.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights which may cover technology that may be required to practice

-   this standard. Please address the information to the IETF Executive

-   Director.

-

-

-Full Copyright Statement

-

-   Copyright (C) The Internet Society (2004). 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 assignees.

-

-   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

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 23]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Acknowledgment

-

-   Funding for the RFC Editor function is currently provided by the

-   Internet Society.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 24]

-

-

diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
deleted file mode 100644
index 42c3c0b7c7e3..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
+++ /dev/null
@@ -1,1321 +0,0 @@
-
-DNS Operations WG                                                     
-Internet-Draft                                         J. Jeong (ed.) 
-                                                                 ETRI 
-                                                                      
-Expires: January 2005                                    18 July 2004 
-    
-    
-      IPv6 Host Configuration of DNS Server Information Approaches 
-             draft-ietf-dnsop-ipv6-dns-configuration-02.txt 
-    
-    
-Status of this Memo 
-    
-   By submitting this Internet-Draft, I certify that any applicable 
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which we become aware will be disclosed, in accordance 
-   with RFC3668. 
-    
-   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. 
-    
-   This Internet-Draft will expire on January 17, 2005. 
-    
-Copyright Notice 
-    
-   Copyright (C) The Internet Society (2004). All Rights Reserved. 
-    
-Abstract 
-    
-   This document describes three approaches for IPv6 recursive DNS 
-   server address configuration.  It details the operational 
-   attributes of three solutions: RA option, DHCPv6 option, and Well-
-   known anycast addresses for recursive DNS servers.  Additionally, 
-   it suggests four deployment scenarios considering multi-solution 
-   resolution.  Therefore, this document will give the audience a 
-
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 1] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   guideline of IPv6 DNS configuration to select approaches suitable 
-   for their host DNS configuration. 
-    
-Table of Contents 
-    
-   1. Introduction...................................................3
-   2. Terminology....................................................3
-   3. IPv6 DNS Configuration Approaches..............................3
-      3.1 RA Option..................................................3
-          3.1.1 Advantages...........................................4
-          3.1.2 Disadvantages........................................5
-          3.1.3 Observations.........................................5
-      3.2 DHCPv6 Option..............................................6
-          3.2.1 Advantages...........................................7
-          3.2.2 Disadvantages........................................8
-          3.2.3 Observations.........................................9
-      3.3 Well-known Anycast Addresses...............................9
-          3.3.1 Advantages...........................................9
-          3.3.2 Disadvantages.......................................10
-          3.3.3 Observations........................................10
-   4. Interworking among IPv6 DNS Configuration Approaches..........11
-   5. Deployment Scenarios..........................................12
-      5.1 ISP Network...............................................12
-          5.1.1 RA Option Approach..................................12
-          5.1.2 DHCPv6 Option Approach..............................13
-          5.1.3 Well-known Addresses Approach.......................13
-      5.2 Enterprise Network........................................14
-      5.3 3GPP Network..............................................14
-          5.3.1 Currently Available Mechanisms and Recommendations..15
-          5.3.2 RA Extension........................................16
-          5.3.3 Stateless DHCPv6....................................16
-          5.3.4 Well-known Addresses................................17
-          5.3.5 Recommendations.....................................17
-      5.4 Unmanaged Network.........................................18
-          5.4.1 Case A: Gateway does not provide IPv6 at all........18
-          5.4.2 Case B: A dual-stack gateway connected to a dual-stack
-                        ISP.........................................18
-          5.4.3 Case C: A dual-stack gateway connected to an IPv4-only
-                        ISP.........................................19
-          5.4.4 Case D: A gateway connected to an IPv6-only ISP.....19
-   6. Security Considerations.......................................19
-   7. Acknowledgements..............................................19
-   8. Normative References..........................................20
-   9. Informative References........................................20
-   10. Authors' Addresses...........................................21
-   Intellectual Property Statement..................................23
-   Full Copyright Statement.........................................23
-   Acknowledgement..................................................24
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 2] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-    
-1. Introduction 
-    
-   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address 
-   Autoconfiguration provide ways to configure either fixed or mobile 
-   nodes with one or more IPv6 addresses, default routes and some 
-   other parameters [3][4].  To support access to additional services 
-   in the Internet that are identified by a DNS name, such as a web 
-   server, the configuration of at least one recursive DNS server is 
-   also needed for DNS name resolution. 
-    
-   This document describes three approaches of recursive DNS server 
-   address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 
-   option [5]-[7], and (c) Well-known anycast addresses for recursive 
-   DNS servers [9].  Also, it suggests applicable scenarios for four 
-   kinds of networks: (a) ISP network, (b) Enterprise network, (c) 
-   3GPP network, and (d) Unmanaged network. 
-    
-   This document is just an analysis of each possible approach, and 
-   does not make any recommendation on particular one or on a 
-   combination of particular ones.  Some approaches may even not be 
-   adopted at all as a result of further discussion. 
-    
-   Therefore, the objective of this document is to help the audience 
-   select approaches suitable for IPv6 host configuration of recursive 
-   DNS server. 
-    
-2. Terminology 
-    
-   This document uses the terminology described in [3]-[9].  In 
-   addition, a new term is defined below: 
-    
-   Recursive DNS Server (RDNSS)    A Recursive DNS Server is a name 
-                                   server that offers the recursive 
-                                   service of DNS name resolution. 
-    
-3. IPv6 DNS Configuration Approaches 
-    
-   In this section, the operational attributes of three solutions are 
-   described in detail. 
-     
-3.1 RA Option 
-    
-   RA approach is to define a new ND option called RDNSS option that 
-   contains a recursive DNS server address.  Existing ND transport 
-   mechanisms (i.e., advertisements and solicitations) are used.  This 
-   works in the same way that nodes learn about routers and prefixes, 
-   etc.  An IPv6 host can configure the IPv6 addresses of one or more 
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 3] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   RDNSSes via RA message periodically sent by router or solicited by 
-   a Router Solicitation (RS) [8].  This approach needs RDNSS 
-   information to be configured in the routers doing the 
-   advertisements.  The configuration of RDNSS address can be 
-   performed manually by operator or other ways, such as automatic 
-   configuration through DHCPv6 client running on the router.  When 
-   advertising more than one RDNSS options, an RA message includes as 
-   many RDNSS options as RDNSSes.  Through ND protocol and RDNSS 
-   option along with prefix information option, an IPv6 host can 
-   perform its network configuration of its IPv6 address and RDNSS 
-   simultaneously [3][4].  The RA option for RDNSS can be used on any 
-   network that supports the use of ND.  However, RA approach performs
-   poorly in some wireless environments where RA message is used for 
-   IPv6 address autoconfiguration, such as WLAN networks. 
-    
-   The RA approach is useful in some non-WLAN mobile environments 
-   where the addresses of the RDNSSes are changing because the RA 
-   option includes a lifetime field.  This can be configured to a 
-   value that will require the client to time out the entry and switch 
-   over to another RDNSS address [8].  However, from the viewpoint of 
-   implementation, lifetime would seem to make matters a bit more 
-   complex.  Instead of just writing DNS configuration file, such as 
-   resolv.conf for the list of RDNSS addresses, we have to have a 
-   daemon around (or a program that is called at the defined 
-   intervals) that keeps monitoring the lifetime of RDNSSes all the 
-   time. 
-    
-   The preference value of RDNSS, included in RDNSS option, allows 
-   IPv6 hosts to select primary RDNSS among several RDNSSes; this can 
-   be used for load balancing of RDNSSes [8]. 
-    
-3.1.1 Advantages 
-    
-   The RA option for RDNSS has a number of advantages.  These include: 
-    
-   1) The RA option is an extension of existing ND/Autoconfig  
-   mechanisms [3][4], and does not require a change in the base ND 
-   protocol. 
-    
-   2) This approach, like ND, works well on a variety of link types  
-   including point-to-point links, point-to-multipoint, and multi-
-   point (i.e., Ethernet LANs), etc.  RFC2461 [3] states, however, 
-   that there may be some link type on which ND is not possible; on 
-   such a link, some other mechanism will be needed for DNS 
-   configuration. 
-    
-   3) All of the information a host needs to run basic Internet  
-   applications such as email, the web, ftp, etc., can be performed 
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 4] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   with the addition of this option to ND and address auto-
-   configuration.  The use of a single mechanism is more reliable and 
-   easier to provide than when the RDNSS information is learned via 
-   another protocol mechanism.  Debugging problems when multiple 
-   protocol mechanisms are being used is harder and much more complex.
-    
-   4) This mechanism works over a broad range of scenarios and 
-   leverages IPv6 ND.  This works well on links that support broadcast
-   reliably (e.g., Ethernet LANs) but not necessarily on other links 
-   (e.g., Wireless LANs).  Also, this works well on links that are 
-   high performance (e.g., Ethernet LANs) and low performance (e.g., 
-   Cellular networks).  In the latter case, combining the RDNSS 
-   information with the other information in the RA, the host can 
-   learn all of the information needed to use most Internet 
-   applications such as the web in a single packet.  This not only 
-   saves bandwidth where this is an issue, but also minimizes the 
-   delay to learn the RDNSS information. 
-    
-   5) The RA approach could be used as a model for other similar types 
-   of configuration information.  New RA options for other server 
-   addresses that are common to all clients on a subnet would be easy 
-   to define.  This includes things like NTP servers, SIP servers, etc.
-    
-3.1.2 Disadvantages 
-    
-   1) ND is mostly implemented in kernel part of operating system.  
-   Therefore, if ND supports the configuration of some additional 
-   services, such as DNS, NTP and SIP servers, ND should be extended 
-   in kernel part.  DHCPv6, however, has more flexibility for 
-   extension of service discovery because it is an application layer 
-   protocol. 
-    
-   2) The current ND framework should be modified due to the 
-   synchronization between another ND cache for RDNSSes in kernel 
-   space and DNS configuration file in user space.  Because it is 
-   unacceptable to write and rewrite the DNS configuration file (e.g.,
-   resolv.conf) from the kernel, another approach is needed.  One 
-   simple approach to solve this is to have a daemon listening to what 
-   the kernel conveys, and to have the daemon do these steps, but such 
-   a daemon is not necessary with the current ND framework. 
-    
-   3) It is necessary to configure RDNSS addresses at least at one 
-   router on every link where this information needs to be configured 
-   by RA option. 
-    
-3.1.3 Observations 
-    
-
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 5] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   The proposed RDNSS RA option along with IPv6 ND and Auto-
-   configuration allows a host to obtain all of the information it 
-   needs to access basic Internet services like the web, email, ftp, 
-   etc.  This is preferable in environments where hosts use RAs to 
-   autoconfigure their addresses and all hosts on the subnet share the
-   same router and server addresses.  If the configuration information
-   can be obtained from a single mechanism, it is preferable because 
-   it does not add additional delay, and it uses a minimum of 
-   bandwidth.  Environments like this include homes, public cellular 
-   networks, and enterprise environments where no per host 
-   configuration is needed, but exclude public WLAN hot spots. 
-    
-   DHCPv6 is preferable where it is being used for address 
-   configuration and if there is a need for host specific 
-   configuration [5]-[7].  Environments like this are most likely 
-   enterprise environments where the local administration chooses to 
-   have per host configuration control. 
-    
-   Note: the observation section is based on what the proponents of 
-   each approach think makes a good overall solution. 
-    
-3.2 DHCPv6 Option 
-    
-   DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
-   which a host can obtain a list of IP addresses of recursive DNS 
-   servers [7].  The DNS Recursive Name Server option carries a list 
-   of IPv6 addresses of RDNSSes to which the host may send DNS queries.
-   The DNS servers are listed in the order of preference for use by 
-   the DNS resolver on the host. 
-    
-   The DNS Recursive Name Server option can be carried in any DHCPv6 
-   Reply message, in response to either a Request or an Information-
-   request message.  Thus, the DNS Recursive Name Server option can be
-   used either when DHCPv6 is used for address assignment, or when 
-   DHCPv6 is used only for other configuration information as 
-   stateless DHCPv6 [6]. 
-    
-   Stateless DHCPv6 can be deployed either using DHCPv6 servers 
-   running on general-purpose computers, or on router hardware.  
-   Several router vendors currently implement stateless DHCPv6 servers.
-   Deploying stateless DHCPv6 in routers has the advantage that no 
-   special hardware is required, and should work well for networks 
-   where DHCPv6 is needed for very straightforward configuration of 
-   network devices. 
-    
-   However, routers can also act as DHCPv6 relay agents.  In this case,
-   the DHCPv6 server need not be on the router - it can be on a 
-   general purpose computer.  This has the potential to give the 
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 6] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   operator of the DHCPv6 server more flexibility in how the DHCPv6 
-   server responds to individual clients - clients can easily be given
-   different configuration information based on their identity, or for
-   any other reason.  Nothing precludes adding this flexibility to a 
-   router, but generally in current practice, DHCP servers running on 
-   general-purpose hosts tend to have more configuration options than 
-   those that are embedded in routers. 
-    
-   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 
-   clients that use stateful configuration assignment.  To do this, 
-   the DHCPv6 server sends a Reconfigure message to the client.  The 
-   client validates the Reconfigure message, and then contacts the 
-   DHCPv6 server to obtain updated configuration information.  Using 
-   this mechanism, it is currently possible to propagate new 
-   configuration information to DHCPv6 clients as this information 
-   changes. 
-    
-   The DHC Working Group is currently studying an additional mechanism
-   through which configuration information, including the list of 
-   RDNSSes, can be updated.  The Lifetime Option for DHCPv6 [10], 
-   assigns a lifetime to configuration information obtained through 
-   DHCPv6.  At the expiration of the lifetime, the host contacts the 
-   DHCPv6 server to obtain updated configuration information, 
-   including the list of RDNSSes.  This lifetime gives the network 
-   administrator another mechanism to configure hosts with new RDNSSes
-   by controlling the time at which the host refreshes the list. 
-    
-   The DHC Working Group has also discussed the possibility of 
-   defining an extension to DHCPv6 that would allow the use of 
-   multicast to provide configuration information to multiple hosts 
-   with a single DHCPv6 message.  Because of the lack of deployment 
-   experience, the WG has deferred consideration of multicast DHCPv6 
-   configuration at this time.  Experience with DHCPv4 has not 
-   identified a requirement for multicast message delivery, even in 
-   large service provider networks with tens of thousands of hosts 
-   that may initiate a DHCPv4 message exchange simultaneously. 
-    
-3.2.1 Advantages 
-    
-   The DHCPv6 option for RDNSS has a number of advantages.  These 
-   include: 
-    
-   1) DHCPv6 currently provides a general mechanism for conveying 
-   network configuration information to clients.  So configuring 
-   DHCPv6 servers allows the network administrator to configure 
-   RDNSSes along with the addresses of other network services, as well
-   as location-specific information like time zones. 
-    
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 7] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   2) As a consequence, when the network administrator goes to 
-   configure DHCPv6, all the configuration information can be managed 
-   through a single service, typically with a single user interface 
-   and a single configuration database. 
-    
-   3) DHCPv6 allows for the configuration of a host with information 
-   specific to that host, so that hosts on the same link can be  
-   configured with different RDNSSes as well as other configuration 
-   information.  This capability is important in some network 
-   deployments such as service provider networks or WiFi hot spots. 
-    
-   4) A mechanism exists for extending DHCPv6 to support the 
-   transmission of additional configuration that has not yet been 
-   anticipated. 
-    
-   5) Hosts that require other configuration information such as the 
-   addresses of SIP servers and NTP servers are likely to need DHCPv6 
-   for other configuration information. 
-    
-   6) The specification for configuration of RDNSSes through DHCPv6 is
-   available as an RFC.  No new protocol extensions such as new 
-   options are necessary. 
-    
-   7) Interoperability among independent implementations has been 
-   demonstrated. 
-    
-3.2.2 Disadvantages 
-    
-   The DHCPv6 option for RDNSS has a few disadvantages.  These 
-   include: 
-    
-   1) Update currently requires message from server (however, see 
-   [10]). 
-    
-   2) Because DNS information is not contained in RA message, the host
-   must receive two messages from the router, and must transmit at  
-   least one message to the router.  On networks where bandwidth is at
-   a premium, this is a disadvantage, although on most networks it is 
-   not a practical concern. 
-    
-   3) Increased latency for initial configuration - in addition to  
-   waiting for an RA message, the client must now exchange packets  
-   with a DHCPv6 server; even if it is locally installed on a router,  
-   this will slightly extend the time required to configure the client.
-   For clients that are moving rapidly from one network to another, 
-   this will be a disadvantage. 
-    
-
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 8] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-3.2.3 Observations 
-    
-   In the general case, on general-purpose networks, stateless DHCPv6 
-   provides significant advantages and no significant disadvantages.  
-   Even in the case where bandwidth is at a premium and low latency is
-   desired, if hosts require other configuration information in 
-   addition to a list of RDNSSes or if hosts must be configured 
-   selectively, those hosts will use DHCPv6 and the use of the DHCPv6 
-   DNS recursive name server option will be advantageous. 
-    
-   However, we are aware of some applications where it would be 
-   preferable to put the RDNSS information into an RA packet; for 
-   example, on a cell phone network, where bandwidth is at a premium 
-   and extremely low latency is desired.  The final DNS configuration 
-   draft should be written so as to allow these special applications 
-   to be handled using DNS information in the RA packet. 
-    
-3.3 Well-known Anycast Addresses 
-    
-   First of all, the well-known anycast addresses approach is much 
-   different from that discussed in IPv6 Working Group in the past. 
-    
-   The approach with well-known anycast addresses is to set well-known
-   anycast addresses in clients' resolver configuration files from the
-   beginning, say, as factory default.  Thus, there is no transport 
-   mechanism and no packet format [9]. 
-    
-   An anycast address is an address shared by multiple servers (in 
-   this case, the servers are RDNSSes).  Request from a client to the 
-   anycast address is routed to a server selected by the routing 
-   system.  However, it is a bad idea to mandate "site" boundary on 
-   anycast addresses, because most users just do not have their own 
-   servers and want to access their ISPs' across their site boundaries.
-   Larger sites may also depend on their ISPs or may have their own 
-   RDNSSes within "site" boundaries. 
-    
-   It should be noted that "anycast" in this memo is simpler than that
-   of RFC1546 [11] and RFC3513 [12] where it is assumed to be 
-   prohibited to have multiple servers on a single link sharing an 
-   anycast address.  That is, on a link, anycast address is assumed to 
-   be unique.  DNS clients today already have redundancy by having 
-   multiple well-known anycast addresses configured as RDNSS addresses.
-   There is no point to have multiple RDNSSes sharing an anycast 
-   address on a single link. 
-    
-3.3.1 Advantages 
-    
-
- 
- 
-Jeong, et al.             Expires - January 2005              [Page 9] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   The basic advantage of the well-known addresses approach is that it
-   uses no transport mechanism.  Thus, 
-   1) There is no delay to get response and no further delay by packet
-   losses. 
-    
-   2) The approach can be combined with any other configuration 
-   mechanisms including but not limited to factory default 
-   configuration, RA-based approach and DHCP based approach. 
-    
-   3) The approach works over any environment where DNS works. 
-    
-   Another advantage is that the approach needs to configure DNS 
-   servers as a router, but nothing else.  Considering that DNS 
-   servers do need configuration, the amount of overall configuration 
-   effort is proportional to the number of the DNS servers and scales 
-   linearly.  It should be noted that, in the simplest case where a 
-   subscriber to an ISP does not have any DNS server, the subscriber 
-   naturally access DNS servers of the ISP even though the subscriber 
-   and the ISP do nothing and there is no protocol to exchange DNS 
-   server information between the subscriber and the ISP. 
-    
-3.3.2 Disadvantages 
-    
-   Well-known anycast addresses approach requires that DNS servers (or
-   routers near it as a proxy) act as routers to advertise their 
-   anycast addresses to the routing system, which requires some 
-   configuration (see the last paragraph of the previous section on 
-   the scalability of the effort). 
-    
-3.3.3 Observations 
-    
-   If other approaches are used in addition, the well-known anycast 
-   addresses should also be set in RA or DHCP configuration files to 
-   reduce configuration effort of users.
-    
-   Redundancy by multiple RDNSSes is better provided by multiple 
-   servers having different anycast addresses than multiple servers 
-   sharing same anycast address because the former approach allows 
-   stale servers to still generate routes to their anycast addresses. 
-   Thus, in a routing domain (or domains sharing DNS servers), there 
-   will be only one server having an anycast address unless the domain
-   is so large that load distribution is necessary. 
-    
-   Small ISPs will operate one RDNSS at each anycast address which is 
-   shared by all the subscribers.  Large ISPs may operate multiple 
-   RDNSSes at each anycast address to distribute and reduce load, 
-   where boundary between RDNSSes may be fixed (redundancy is still 
-   provided by multiple addresses) or change dynamically.  DNS packets
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 10] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   with the well-known anycast addresses are not expected (though not 
-   prohibited) to cross ISP boundaries, as ISPs are expected to be 
-   able to take care of themselves. 
-    
-   Because "anycast" in this memo is simpler than that of RFC1546 [11]
-   and RFC3513 [12] where it is assumed to be administratively 
-   prohibited to have multiple servers on a single link sharing an 
-   anycast address, anycast in this memo should be implemented as 
-   UNICAST of RFC2461 [3] and RFC3513 [12].  As a result, ND-related 
-   instability disappears.  Thus, anycast in well-known anycast 
-   addresses approach can and should use the anycast address as a 
-   source unicast (according to RFC3513 [12]) address of packets of 
-   UDP and TCP responses.  With TCP, if route flips and packets to an 
-   anycast address are routed to a new server, it is expected that the
-   flip is detected by ICMP or sequence number inconsistency and the 
-   TCP connection is reset and retried.
-    
-4. Interworking among IPv6 DNS Configuration Approaches 
-    
-   Three approaches can work together for IPv6 host configuration of 
-   RDNSS.  This section shows a consideration on how these approaches 
-   can interwork each other. 
-    
-   For ordering between RA and DHCP approaches, O (Other stateful 
-   configuration) flag in RA message can be used [8].  If no RDNSS 
-   option is included, an IPv6 Host may perform DNS configuration 
-   through DHCPv6 [5]-[7] regardless of whether the O flag is set or 
-   not. 
-    
-   The well-known anycast addresses approach fully interworks with the
-   other approaches.  That is, the other approaches can remove 
-   configuration effort on servers by using the well-known addresses 
-   as the default configuration.  Moreover, clients preconfigured with
-   well-known anycast addresses can be further configured to use other
-   approaches to override the well-known addresses, if configuration 
-   information from other approaches are available.  That is, all the 
-   clients should have the well-known anycast addresses preconfigured,
-   in the case where there are no other mechanisms available.  In 
-   order to fly anycast approach with the other solutions, there are 
-   three options. 
-    
-   The first option is that well-known addresses are used as last 
-   resort, when an IPv6 host can not get RDNSS information through RA 
-   and DHCP.  The well-known anycast addresses have to be pre-
-   configured in IPv6 hosts' resolver configuration files. 
-    
-
-
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 11] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   The second is that an IPv6 host can configure well-known addresses 
-   as the most preferable in its configuration file even though either
-   RA option or DHCP option is available. 
-    
-   The last is that the well-known anycast addresses can be set in RA 
-   or DHCP configuration to reduce configuration effort of users.  
-   According to either RA or DHCP mechanism, the well-known addresses 
-   can be obtained by IPv6 host.  Because this approach is the most 
-   convenient for users, the last option is recommended. 
- 
-   Note: this section does not necessarily mean this document suggests
-   adopting all these three approaches and making them interwork in 
-   the way described here.  In fact, some approaches may even not be 
-   adopted at all as a result of further discussion. 
-    
-5. Deployment Scenarios 
-    
-   Regarding DNS configuration on the IPv6 host, several mechanisms 
-   have being considered at the DNSOP Working Group such as RA option,
-   DHCPv6 option and well-known preconfigured anycast addresses as of 
-   today, and this document is a final result from the long thread.  
-   In this section, we suggest four applicable scenarios of three 
-   approaches for IPv6 DNS configuration. 
-    
-   Note: in the applicable scenarios, authors do not implicitly push 
-   any specific approaches into the restricted environments.  No 
-   enforcement is in each scenario and all mentioned scenarios are 
-   probable.  The main objective of this work is to provide a useful 
-   guideline of IPv6 DNS configuration. 
-    
-5.1 ISP Network 
-    
-   A characteristic of ISP network is that multiple Customer Premises 
-   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) 
-   routers and each PE connects multiple CPE devices to the backbone 
-   network infrastructure [13].  The CPEs may be hosts or routers. 
-    
-   In the case where the CPE is a router, there is a customer network 
-   that is connected to the ISP backbone through the CPE.  Typically, 
-   each customer network gets a different IPv6 prefix from an IPv6 PE 
-   router, but the same RDNSS configuration will be distributed. 
-    
-   This section discusses how the different approaches to distributing
-   DNS information are compared in an ISP network. 
-    
-5.1.1 RA Option Approach 
-    
-
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 12] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   When the CPE is a host, the RA option for RDNSS can be used to 
-   allow the CPE to get RDNSS information as well as /64 prefix 
-   information for stateless address autoconfiguration at the same 
-   time when the host is attached to a new subnet [8].  Because an 
-   IPv6 host must receive at least one RA message for stateless 
-   address autoconfiguration and router configuration, the host could 
-   receive RDNSS configuration information in that RA without the 
-   overhead of an additional message exchange. 
-    
-   When the CPE is a router, the CPE may accept the RDNSS information 
-   from the RA on the interface connected to the ISP, and copy that 
-   information into the RAs advertised in the customer network. 
-    
-   This approach is more valuable in the mobile host scenario, in 
-   which the host must receive at least an RA message for detecting a 
-   new network, than in other scenarios generally although 
-   administrator should configure RDNSS information on the routers.  
-   Secure ND [14] can provide extended security when using RA message.
-    
-5.1.2 DHCPv6 Option Approach 
-    
-   DHCPv6 can be used for RDNSS configuration through the use of the 
-   DNS option, and can provide other configuration information in the 
-   same message with RDNSS configuration [5]-[7].  DHCPv6 DNS option 
-   is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6-
-   lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6 
-   implementation.  DHCP is a client-server model protocol, so ISP can
-   handle user identification on its network intentionally, and also 
-   authenticated DHCP [15] can be used for secure message exchange. 
-    
-   The expected model for deployment of IPv6 service by ISPs is to 
-   assign a prefix to each customer, which will be used by the 
-   customer gateway to assign a /64 prefix to each network in the 
-   customer's network.  Prefix delegation with DHCP (DHCPv6 PD) has 
-   already been adopted by ISPs for automating the assignment of the 
-   customer prefix to the customer gateway [17].  DNS configuration 
-   can be carried in the same DHCPv6 message exchange used for DHCPv6 
-   to efficiently provide that information, along with any other 
-   configuration information needed by the customer gateway or 
-   customer network.  This service model can be useful to Home or SOHO
-   subscribers.  The Home or SOHO gateway, which is a customer gateway
-   for ISP, can then pass that RDNSS configuration information to the 
-   hosts in the customer network through DHCP. 
-    
-5.1.3 Well-known Addresses Approach 
-    
-   Well-known anycast addresses approach is also a feasible and simple
-   mechanism for ISP [9].  The use of well-known anycast addresses 
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 13] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   avoids some of the security risks in rogue messages sent through an
-   external protocol like RA or DHCPv6.  The configuration of hosts 
-   for the use of well-known anycast addresses requires no protocol or
-   manual configuration, but the configuration of routing for the 
-   anycast addresses requires intervention on the part of the network
-   administrator.  Also, the number of special addresses would be 
-   equal to the number of RDNSSes that could be made available to 
-   subscribers. 
-    
-5.2 Enterprise Network 
-    
-   Enterprise network is defined as a network that has multiple 
-   internal links, one or more router connections, to one or more 
-   Providers and is actively managed by a network operations entity 
-   [16].  An enterprise network can get network prefixes from ISP by 
-   either manual configuration or prefix delegation [17].  In most 
-   cases, because an enterprise network manages its own DNS domains, 
-   it operates its own DNS servers for the domains.  These DNS servers
-   within enterprise network process recursive DNS name resolution 
-   requests of IPv6 hosts as RDNSS.  RDNSS configuration in enterprise
-   network can be performed like in Section 4, in which three 
-   approaches can be used together. 
-    
-   IPv6 host can decide which approach is or may be used in its subnet
-   with O flag in RA message [8].  As the first option in Section 4, 
-   well-known anycast addresses can be used as a last resort when 
-   RDNSS information can not be obtained through either RA option or 
-   DHCP option.  This case needs IPv6 hosts to preconfigure the well-
-   known anycast addresses in their DNS configuration files. 
-    
-   When the enterprise prefers well-known anycast approach to the 
-   others, IPv6 hosts should preconfigure the well-known anycast 
-   addresses like in the first option. 
-    
-   The last option, a more convenient and transparent way, does not 
-   need IPv6 hosts to preconfigure the well-known anycast addresses 
-   because the addresses are delivered to IPv6 hosts through either RA
-   option or DHCPv6 option as if they were unicast addresses.  This 
-   way is most recommended for the sake of user's convenience. 
-    
-5.3 3GPP Network 
-    
-   IPv6 DNS configuration is a missing part of IPv6 autoconfiguration 
-   and an important part of the basic IPv6 functionality in the 3GPP 
-   User Equipment (UE).  Higher level description of the 3GPP 
-   architecture can be found in [18], and transition to IPv6 in 3GPP 
-   networks is analyzed in [19] and [20]. 
-    
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 14] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   In 3GPP architecture, there is a dedicated link between the UE and 
-   the GGSN called the Packet Data Protocol (PDP) Context.  This link 
-   is created through the PDP Context activation procedure [21].  
-   There is a separate PDP context type for IPv4 and IPv6 traffic.  If
-   a 3GPP UE user is communicating using IPv6 (having an active IPv6 
-   PDP context), it can not be assumed that (s)he has simultaneously 
-   active IPv4 PDP context, and DNS queries could be done using IPv4. 
-   A 3GPP UE can thus be an IPv6 node, and it needs to somehow 
-   discover the address of the RDNSS.  Before IP-based services (e.g.,
-   web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS 
-   addresses need to be discovered in the 3GPP UE. 
-    
-   Section 5.3.1 briefly summarizes currently available mechanisms in 
-   3GPP networks and recommendations.  5.3.2 analyzes the Router  
-   Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 
-   mechanism, and 5.3.4 analyzes the Well-known addresses approach.  
-   Section 5.3.5 finally summarizes the recommendations. 
-    
-5.3.1 Currently Available Mechanisms and Recommendations 
-    
-   3GPP has defined a mechanism, in which RDNSS addresses can be  
-   received in the PDP context activation (a control plane mechanism).
-   That is called the Protocol Configuration Options Information  
-   Element (PCO-IE) mechanism [22].  The RDNSS addresses can also be 
-   received over the air (using text messages), or typed in manually 
-   in the UE.  Note that the two last mechanisms are not very well  
-   scalable.  The UE user most probably does not want to type IPv6 
-   RDNSS addresses manually in his/her UE.  The use of well-known 
-   addresses is briefly discussed in section 5.3.4. 
-    
-   It is seen that the mechanisms above most probably are not  
-   sufficient for the 3GPP environment.  IPv6 is intended to operate 
-   in a zero-configuration manner, no matter what the underlying 
-   network infrastructure is.  Typically, the RDNSS address is needed 
-   to make an IPv6 node operational - and the DNS configuration should
-   be as simple as the address autoconfiguration mechanism.  It must 
-   also be noted that there will be additional IP interfaces in some 
-   near future 3GPP UEs, e.g., Wireless LAN (WLAN), and 3GPP-specific 
-   DNS configuration mechanisms (such as PCO-IE [22]) do not work for 
-   those IP interfaces.  In other words, a good IPv6 DNS configuration
-   mechanism should also work in a multi-access network environment. 
-    
-   From 3GPP point of view, the best IPv6 DNS configuration solution 
-   is feasible for a very large number of IPv6-capable UEs (can be 
-   even hundreds of millions in one operator's network), is automatic 
-   and thus requires no user action.  It is suggested to standardize a
-   lightweight, stateless mechanism that works in all network  
-   environments.  The solution could then be used for 3GPP, 3GPP2, 
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 15] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   WLAN and other access network technologies.  A light, stateless 
-   IPv6 DNS configuration mechanism is thus not only needed in 3GPP 
-   networks, but also 3GPP networks and UEs would certainly benefit 
-   from the new mechanism. 
-    
-5.3.2 RA Extension 
-    
-   Router Advertisement extension [8] is a lightweight IPv6 DNS  
-   configuration mechanism that requires minor changes in 3GPP UE IPv6
-   stack and Gateway GPRS Support Node (GGSN, the default router in  
-   the 3GPP architecture) IPv6 stack.  This solution can be specified 
-   in the IETF (no action needed in the 3GPP) and taken in use in 3GPP 
-   UEs and GGSNs. 
-    
-   In this solution, an IPv6-capable UE configures DNS information  
-   via RA message sent by its default router (GGSN), i.e., RDNSS 
-   option for recursive DNS server is included in the RA message.  
-   This solution is easily scalable for a very large number of UEs.  
-   The operator can configure the RDNSS addresses in the GGSN as a 
-   part of normal GGSN configuration.  The IPv6 RDNSS address is 
-   received in the Router Advertisement, and an extra Round Trip Time
-   (RTT) for asking RDNSS addresses can be avoided. 
-    
-   If thinking about cons, this mechanism still requires 
-   standardization effort in the IETF, and the end nodes and routers 
-   need to support this mechanism.  The equipment software update 
-   should, however, be pretty straightforward, and new IPv6 equipment 
-   could support RA extension already from the beginning. 
-    
-5.3.3 Stateless DHCPv6 
-    
-   DHCPv6-based solution needs the implementation of Stateless DHCP  
-   [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in  
-   the operator's network.  A possible configuration is such that the
-   GGSN works as a DHCP relay. 
-    
-   Pros for Stateless DHCPv6-based solution are 
-   1) Stateless DHCPv6 is a standardized mechanism. 
-    
-   2) DHCPv6 can be used for receiving other configuration information
-   than RDNSS addresses, e.g., SIP server addresses. 
-    
-   3) DHCPv6 works in different network environments. 
-    
-   4) When DHCPv6 service is deployed through a single, centralized 
-   server, the RDNSS configuration information can be updated by the 
-   network administrator at a single source. 
-    
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 16] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   Some issues with DHCPv6 in 3GPP networks are listed below: 
-   1) DHCPv6 requires an additional server in the network unless the 
-   (Stateless) DHCPv6 functionality is integrated into an existing 
-   router already, and it is one box more to be maintained. 
-    
-   2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing 
-   (3GPP Stateless Address Autoconfiguration is typically used), and 
-   not automatically implemented in 3GPP IPv6 UEs. 
-    
-   3) Scalability and reliability of DHCPv6 in very large 3GPP 
-   networks (with tens or hundreds of millions of UEs) may be an issue,
-   at least the redundancy needs to be taken care of.  However, if the 
-   DHCPv6 service is integrated into the network elements, such as 
-   router operating system, scalability and reliability is comparable 
-   with other DNS configuration approaches. 
-    
-   4) It is sub-optimal to utilize the radio resources in 3GPP 
-   networks for DHCPv6 messages if there is a simpler alternative 
-   available. 
-    
-      a) Use of Stateless DHCPv6 adds one round trip delay to the case
-      in which the UE can start transmitting data right after the 
-      Router Advertisement. 
-    
-   5) If the DNS information (suddenly) changes, Stateless DHCPv6 can 
-   not automatically update the UE, see [23]. 
-    
-5.3.4 Well-known Addresses 
-    
-   Using well-known addresses is also a feasible and a light mechanism
-   for 3GPP UEs.  Those well-known addresses can be preconfigured in  
-   the UE software and the operator makes the corresponding  
-   configuration on the network side.  So this is a very easy 
-   mechanism for the UE, but requires some configuration work in the 
-   network.  When using well-known addresses, UE forwards queries to 
-   any of the preconfigured addresses.  In the current proposal [9], 
-   IPv6 anycast addresses are suggested. 
-    
-   Note: IPv6 DNS configuration proposal based on the use of well-
-   known site-local addresses developed at the IPv6 Working Group was
-   seen as a feasible mechanism for 3GPP UEs, but opposition by some 
-   people in the IETF and finally deprecating IPv6 site-local 
-   addresses made it impossible to standardize it.  Note that this 
-   mechanism is implemented in some existing operating systems today 
-   (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration.
-    
-5.3.5 Recommendations  
-    
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 17] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   It is suggested that a lightweight, stateless DNS configuration 
-   mechanism is specified as soon as possible.  From 3GPP UE's and 
-   networks' point of view, Router Advertisement based mechanism looks
-   most promising.  The sooner a light, stateless mechanism is 
-   specified, the sooner we can get rid of using well-known site-local
-   addresses for IPv6 DNS configuration. 
-    
-5.4 Unmanaged Network 
-    
-   There are 4 deployment scenarios of interest in unmanaged networks 
-   [24]: 
-    
-   1) A gateway which does not provide IPv6 at all; 
-    
-   2) A dual-stack gateway connected to a dual-stack ISP; 
-    
-   3) A dual-stack gateway connected to an IPv4-only ISP; and 
-    
-   4) A gateway connected to an IPv6-only ISP. 
-    
-5.4.1 Case A: Gateway does not provide IPv6 at all 
-    
-   In this case, the gateway does not provide IPv6; the ISP may or may
-   not provide IPv6.  Automatic or Configured tunnels are the 
-   recommended transition mechanisms for this scenario. 
-    
-   The case where dual-stack hosts behind an NAT, that need access to 
-   an IPv6 RDNSS, can not be entirely ruled out.  The DNS 
-   configuration mechanism has to work over the tunnel, and the 
-   underlying tunneling mechanism could be implementing NAT traversal.
-   The tunnel server assumes the role of a relay (both for DHCP and 
-   Well-known anycast addresses approaches). 
-    
-   RA-based mechanism is relatively straightforward in its operation, 
-   assuming the tunnel server is also the IPv6 router emitting RAs. 
-   Well-known anycast addresses approach seems also simple in 
-   operation across the tunnel, but the deployment model using Well-
-   known anycast addresses in a tunneled environment is unclear or not 
-   well understood. 
-    
-5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP 
-    
-   This is similar to a typical IPv4 home user scenario, where DNS 
-   configuration parameters are obtained using DHCP.  Except that 
-   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
-   DHCP server is stateful (maintains the state for clients). 
-    
-
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 18] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP 
-    
-   This is similar to Case B.  If a gateway provides IPv6 connectivity
-   by managing tunnels, then it is also supposed to provide access to 
-   an RDNSS.  Like this, the tunnel for IPv6 connectivity originates 
-   from the dual-stack gateway instead of the host. 
-    
-5.4.4 Case D: A gateway connected to an IPv6-only ISP 
-    
-   This is similar to Case B. 
-    
-6. Security Considerations 
-    
-   As security requirements depend solely on applications and are 
-   different application by application, there can be no generic 
-   requirement defined at higher IP or lower application layer of DNS.
-    
-   However, it should be noted that cryptographic security requires 
-   configured secret information that full autoconfiguration and 
-   cryptographic security are mutually exclusive.  People insisting on
-   secure full autoconfiguration will get false security, false 
-   autoconfiguration or both. 
-    
-   In some deployment scenario [19], where cryptographic security is 
-   required for applications, secret information for the cryptographic
-   security is preconfigured through which application specific 
-   configuration data, including those for DNS, can be securely 
-   configured.  It should be noted that if applications requiring 
-   cryptographic security depend on DNS, the applications also require
-   cryptographic security to DNS.  Therefore, the full auto-
-   configuration of DNS is not acceptable. 
-    
-   However, with full autoconfiguration, weaker but still reasonable 
-   security is being widely accepted and will continue to be 
-   acceptable.  That is, with full autoconfiguration, which means 
-   there is no cryptographic security for the autoconfiguration, it is
-   already assumed that local environment is secure enough that 
-   information from local autoconfiguration server has acceptable 
-   security even without cryptographic security.  Thus, communication 
-   between a local DNS client and a local DNS server has the 
-   acceptable security. 
-    
-   For security considerations of each approach, refer to the 
-   corresponding drafts [5]-[9]. 
-    
-7. Acknowledgements 
-    
-
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 19] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   This draft has greatly benefited from inputs by David Meyer, Rob 
-   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, 
-   Christian Huitema, and Thomas Narten.  The authors appreciate their
-   contribution. 
-    
-8. Normative References 
-    
-   [1]  S. Bradner, "Intellectual Property Rights in IETF Technology",
-        RFC 3668, February 2004.  
-    
-   [2]  S. Bradner, "IETF Rights in Contributions", RFC 3667, February
-        2004. 
-    
-   [3]  T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for
-        IP Version 6 (IPv6)", RFC 2461, December 1998. 
-    
-   [4]  S. Thomson and T. Narten, "IPv6 Stateless Address 
-        Autoconfiguration", RFC 2462, December 1998. 
-    
-   [5]  R. Droms et al., "Dynamic Host Configuration Protocol for IPv6
-        (DHCPv6)", RFC 3315, July 2003. 
-    
-   [6]  R. Droms, "Stateless Dynamic Host Configuration Protocol 
-        (DHCP) Service for IPv6", RFC 3736, April 2004. 
-    
-   [7]  R. Droms et al., "DNS Configuration options for Dynamic Host 
-        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 
-        2003. 
-    
-9. Informative References 
-    
-   [8]  J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS 
-        Discovery based on Router Advertisement", draft-jeong-dnsop-
-        ipv6-dns-discovery-02.txt, July 2004. 
-    
-   [9]  M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta-
-        preconfigured-dns-01.txt, February 2004. 
-    
-   [10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft-
-        ietf-dhc-lifetime-00.txt, March 2004. 
-    
-   [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting 
-        Service", RFC 1546, November 1993. 
-    
-   [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
-        Addressing Architecture", RFC 3513, April 2003. 
-    
-
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 20] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
-        into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-
-        02.txt, April 2004. 
-    
-   [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-
-        ietf-send-ndopt-05.txt, April 2004. 
-    
-   [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", 
-        RFC 3118, June 2001. 
-    
-   [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft-
-        ietf-v6ops-ent-scenarios-01.txt, February 2004. 
-    
-   [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host 
-        Configuration Protocol (DHCP) version 6", RFC 3633, December 
-        2003. 
-    
-   [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP     
-        Standards", RFC 3314, September 2002. 
-    
-   [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks", 
-        RFC 3574, August 2003. 
-    
-   [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP     
-        Networks", draft-ietf-v6ops-3gpp-analysis-09.txt, March 2004. 
-    
-   [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); 
-        Service description; Stage 2 (Release 5)", December 2002. 
-    
-   [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 
-        specification; Core network protocols; Stage 3 (Release 5)",
-        June 2003. 
-    
-   [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering  
-        Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless-
-        dhcpv6-renumbering-00.txt, March 2004. 
-    
-   [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition 
-        Scenarios", RFC 3750, April 2004. 
-    
-10. Authors' Addresses 
-    
-   Jaehoon Paul Jeong, Editor 
-   ETRI / PEC 
-   161 Gajeong-dong, Yuseong-gu 
-   Daejeon 305-350 
-   Korea 
-    
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 21] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   Phone: +82 42 860 1664 
-   Fax: +82 42 861 5404 
-   EMail: paul@etri.re.kr 
-    
-   Ralph Droms 
-   Cisco Systems 
-   1414 Massachusetts Ave. 
-   Boxboro, MA 01719 
-   USA 
-    
-   Phone: +1 978 936 1674 
-   EMail: rdroms@cisco.com 
-    
-   Robert M. Hinden 
-   Nokia 
-   313 Fairchild Drive 
-   Mountain View, CA 94043 
-   USA 
-    
-   Phone: +1 650 625 2004 
-   EMail: bob.hinden@nokia.com 
-    
-   Ted Lemon 
-   Nominum, Inc. 
-   950 Charter Street 
-   Redwood City, CA 94043 
-   USA 
-    
-   EMail: Ted.Lemon@nominum.com 
-    
-   Masataka Ohta 
-   Graduate School of Information Science and Engineering 
-   Tokyo Institute of Technology 
-   2-12-1, O-okayama, Meguro-ku 
-   Tokyo 152-8552 
-   Japan 
-    
-   Phone: +81 3 5734 3299 
-   Fax: +81 3 5734 3299 
-   EMail: mohta@necom830.hpcl.titech.ac.jp 
-    
-   Soohong Daniel Park 
-   Mobile Platform Laboratory, SAMSUNG Electronics 
-   416, Maetan-3dong, Paldal-gu, Suwon 
-   Gyeonggi-Do 
-   Korea 
-    
-   Phone: +82 31 200 4508 
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 22] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   EMail: soohong.park@samsung.com 
-    
-   Suresh Satapati 
-   Cisco Systems, Inc. 
-   San Jose, CA 95134 
-   USA 
-    
-   EMail: satapati@cisco.com 
-    
-   Juha Wiljakka 
-   Nokia 
-   Visiokatu 3 
-   FIN-33720 TAMPERE 
-   Finland 
-    
-   Phone: +358 7180 48372 
-   EMail: juha.wiljakka@nokia.com 
-    
-Intellectual Property Statement 
-    
-   The following intellectual property notice is copied from RFC3668,
-   Section 5. 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-Full Copyright Statement 
-    
-
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 23] 
- 
-Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
- 
- 
-   The following copyright notice is copied from RFC3667, Section 5.4.
-   It describes the applicable copyright for this document. 
-    
-   Copyright (C) The Internet Society (2004).  This document is 
-   subject to the rights, licenses and restrictions contained in BCP 
-   78, and except as set forth therein, the authors retain all their 
-   rights. 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 
-    
-Acknowledgement 
-    
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Jeong, et al.             Expires - January 2005             [Page 24] 
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
deleted file mode 100644
index b14f711d5314..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
+++ /dev/null
@@ -1,1969 +0,0 @@
-
-
-DNS Operations WG                                              A. Durand
-Internet-Draft                                    SUN Microsystems, Inc.
-Expires: February 7, 2005                                       J. Ihren
-                                                              Autonomica
-                                                               P. Savola
-                                                               CSC/FUNET
-                                                          August 9, 2004
-
-
-
-          Operational Considerations and Issues with IPv6 DNS
-                draft-ietf-dnsop-ipv6-dns-issues-09.txt
-
-
-Status of this Memo
-
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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.
-
-
-   This Internet-Draft will expire on February 7, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   This memo presents operational considerations and issues with IPv6
-   Domain Name System (DNS), including a summary of special IPv6
-   addresses, documentation of known DNS implementation misbehaviour,
-   recommendations and considerations on how to perform DNS naming for
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 1]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   service provisioning and for DNS resolver IPv6 support,
-   considerations for DNS updates for both the forward and reverse
-   trees, and miscellaneous issues.  This memo is aimed to include a
-   summary of information about IPv6 DNS considerations for those who
-   have experience with IPv4 DNS.
-
-
-Table of Contents
-
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1   Representing IPv6 Addresses in DNS Records . . . . . . . .  4
-     1.2   Independence of DNS Transport and DNS Records  . . . . . .  4
-     1.3   Avoiding IPv4/IPv6 Name Space Fragmentation  . . . . . . .  5
-     1.4   Query Type '*' and A/AAAA Records  . . . . . . . . . . . .  5
-   2.  DNS Considerations about Special IPv6 Addresses  . . . . . . .  5
-     2.1   Limited-scope Addresses  . . . . . . . . . . . . . . . . .  6
-     2.2   Temporary Addresses  . . . . . . . . . . . . . . . . . . .  6
-     2.3   6to4 Addresses . . . . . . . . . . . . . . . . . . . . . .  6
-     2.4   Other Transition Mechanisms  . . . . . . . . . . . . . . .  6
-   3.  Observed DNS Implementation Misbehaviour . . . . . . . . . . .  7
-     3.1   Misbehaviour of DNS Servers and Load-balancers . . . . . .  7
-     3.2   Misbehaviour of DNS Resolvers  . . . . . . . . . . . . . .  7
-   4.  Recommendations for Service Provisioning using DNS . . . . . .  8
-     4.1   Use of Service Names instead of Node Names . . . . . . . .  8
-     4.2   Separate vs the Same Service Names for IPv4 and IPv6 . . .  8
-     4.3   Adding the Records Only when Fully IPv6-enabled  . . . . .  9
-     4.4   Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
-       4.4.1   Description of Additional Data Scenarios . . . . . . . 10
-       4.4.2   Discussion of the Problems . . . . . . . . . . . . . . 11
-     4.5   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12
-     4.6   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 13
-   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 13
-     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14
-     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 15
-     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 16
-   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 16
-     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
-     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 17
-   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 18
-     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 18
-     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19
-     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 19
-     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20
-     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 21
-   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22
-     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 22
-     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 22
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
-   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 22
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 2]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
-   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 23
-   11.2  Informative References . . . . . . . . . . . . . . . . . . . 25
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
-   A.  Site-local Addressing Considerations for DNS . . . . . . . . . 28
-   B.  Issues about Additional Data or TTL  . . . . . . . . . . . . . 28
-       Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 3]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-1.  Introduction
-
-
-   This memo presents operational considerations and issues with IPv6
-   DNS; it is meant to be an extensive summary and a list of pointers
-   for more information about IPv6 DNS considerations for those with
-   experience with IPv4 DNS.
-
-
-   The purpose of this document is to give information about various
-   issues and considerations related to DNS operations with IPv6; it is
-   not meant to be a normative specification or standard for IPv6 DNS.
-
-
-   The first section gives a brief overview of how IPv6 addresses and
-   names are represented in the DNS, how transport protocols and
-   resource records (don't) relate, and what IPv4/IPv6 name space
-   fragmentation means and how to avoid it; all of these are described
-   at more length in other documents.
-
-
-   The second section summarizes the special IPv6 address types and how
-   they relate to DNS.  The third section describes observed DNS
-   implementation misbehaviours which have a varying effect on the use
-   of IPv6 records with DNS.  The fourth section lists recommendations
-   and considerations for provisioning services with DNS.  The fifth
-   section in turn looks at recommendations and considerations about
-   providing IPv6 support in the resolvers.  The sixth and seventh
-   sections describe considerations with forward and reverse DNS
-   updates, respectively.  The eighth section introduces several
-   miscellaneous IPv6 issues relating to DNS for which no better place
-   has been found in this memo.  Appendix A looks briefly at the
-   requirements for site-local addressing.
-
-
-1.1  Representing IPv6 Addresses in DNS Records
-
-
-   In the forward zones, IPv6 addresses are represented using AAAA
-   records.  In the reverse zones, IPv6 address are represented using
-   PTR records in the nibble format under the ip6.arpa.  tree.  See
-   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
-   for background information.
-
-
-   In particular one should note that the use of A6 records in the
-   forward tree or Bitlabels in the reverse tree is not recommended
-   [RFC3363].  Using DNAME records is not recommended in the reverse
-   tree in conjunction with A6 records; the document did not mean to
-   take a stance on any other use of DNAME records [RFC3364].
-
-
-1.2  Independence of DNS Transport and DNS Records
-
-
-   DNS has been designed to present a single, globally unique name space
-   [RFC2826].  This property should be maintained, as described here and
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 4]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   in Section 1.3.
-
-
-   The IP version used to transport the DNS queries and responses is
-   independent of the records being queried: AAAA records can be queried
-   over IPv4, and A records over IPv6.  The DNS servers must not make
-   any assumptions about what data to return for Answer and Authority
-   sections based on the underlying transport used in a query.
-
-
-   However, there is some debate whether the addresses in Additional
-   section could be selected or filtered using hints obtained from which
-   transport was being used; this has some obvious problems because in
-   many cases the transport protocol does not correlate with the
-   requests, and because a "bad" answer is in a way worse than no answer
-   at all (consider the case where the client is led to believe that a
-   name received in the additional record does not have any AAAA records
-   at all).
-
-
-   As stated in [RFC3596]:
-
-
-      The IP protocol version used for querying resource records is
-      independent of the protocol version of the resource records; e.g.,
-      IPv4 transport can be used to query IPv6 records and vice versa.
-
-
-
-1.3  Avoiding IPv4/IPv6 Name Space Fragmentation
-
-
-   To avoid the DNS name space from fragmenting into parts where some
-   parts of DNS are only visible using IPv4 (or IPv6) transport, the
-   recommendation is to always keep at least one authoritative server
-   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
-   See DNS IPv6 transport guidelines
-   [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information.
-
-
-1.4  Query Type '*' and A/AAAA Records
-
-
-   QTYPE=* is typically only used for debugging or management purposes;
-   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
-   any available RRsets, not *all* the RRsets, because the caches do not
-   necessarily have all the RRsets and have no way of guaranteeing that
-   they have all the RRsets.  Therefore, to get both A and AAAA records
-   reliably, two separate queries must be made.
-
-
-2.  DNS Considerations about Special IPv6 Addresses
-
-
-   There are a couple of IPv6 address types which are somewhat special;
-   these are considered here.
-
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 5]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-2.1  Limited-scope Addresses
-
-
-   The IPv6 addressing architecture [RFC3513] includes two kinds of
-   local-use addresses: link-local (fe80::/10) and site-local (fec0::/
-   10).  The site-local addresses have been deprecated
-   [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in
-   Appendix A.
-
-
-   Link-local addresses should never be published in DNS (whether in
-   forward or reverse tree), because they have only local (to the
-   connected link) significance
-   [I-D.ietf-dnsop-dontpublish-unreachable].
-
-
-2.2  Temporary Addresses
-
-
-   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
-   "privacy addresses") use a random number as the interface identifier.
-   Publishing (useful) DNS records relating to such addresses would
-   defeat the purpose of the mechanism and is not recommended.  However,
-   it would still be possible to return a non-identifiable name (e.g.,
-   the IPv6 address in hexadecimal format), as described in [RFC3041].
-
-
-2.3  6to4 Addresses
-
-
-   6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
-   a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
-
-
-   If the reverse DNS population would be desirable (see Section 7.1 for
-   applicability), there are a number of possible ways to do so
-   [I-D.moore-6to4-dns], some more applicable than the others.
-
-
-   The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
-   autonomous reverse-delegation system that anyone being capable of
-   communicating using a specific 6to4 address would be able to set up a
-   reverse delegation to the corresponding 6to4 prefix.  This could be
-   deployed by e.g., Regional Internet Registries (RIRs).  This is a
-   practical solution, but may have some scalability concerns.
-
-
-2.4  Other Transition Mechanisms
-
-
-   6to4, above, is mentioned as a case of an IPv6 transition mechanism
-   requiring special considerations.  In general, mechanisms which
-   include a special prefix may need a custom solution; otherwise, for
-   example when IPv4 address is embedded as the suffix or not embedded
-   at all, special solutions are likely not needed.  This is why only
-   6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.
-
-
-   Note that it does not seem feasible to provide reverse DNS with
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 6]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   another automatic tunneling mechanism, Teredo; this is because the
-   IPv6 address is based on the IPv4 address and UDP port of the current
-   NAT mapping which is likely to be relatively short-lived.
-
-
-3.  Observed DNS Implementation Misbehaviour
-
-
-   Several classes of misbehaviour in DNS servers, load-balancers and
-   resolvers have been observed.  Most of these are rather generic, not
-   only applicable to IPv6 -- but in some cases, the consequences of
-   this misbehaviour are extremely severe in IPv6 environments and
-   deserve to be mentioned.
-
-
-3.1  Misbehaviour of DNS Servers and Load-balancers
-
-
-   There are several classes of misbehaviour in certain DNS servers and
-   load-balancers which have been noticed and documented
-   [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations
-   silently drop queries for unimplemented DNS records types, or provide
-   wrong answers to such queries (instead of a proper negative reply).
-   While typically these issues are not limited to AAAA records, the
-   problems are aggravated by the fact that AAAA records are being
-   queried instead of (mainly) A records.
-
-
-   The problems are serious because when looking up a DNS name, typical
-   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
-   to query the AAAA records of the name, and after receiving a
-   response, query the A records.  This is done in a serial fashion --
-   if the first query is never responded to (instead of properly
-   returning a negative answer), significant timeouts will occur.
-
-
-   In consequence, this is an enormous problem for IPv6 deployments, and
-   in some cases, IPv6 support in the software has even been disabled
-   due to these problems.
-
-
-   The solution is to fix or retire those misbehaving implementations,
-   but that is likely not going to be effective.  There are some
-   possible ways to mitigate the problem, e.g., by performing the
-   lookups somewhat in parallel and reducing the timeout as long as at
-   least one answer has been received; but such methods remain to be
-   investigated; slightly more on this is included in Section 5.
-
-
-3.2  Misbehaviour of DNS Resolvers
-
-
-   Several classes of misbehaviour have also been noticed in DNS
-   resolvers [I-D.ietf-dnsop-bad-dns-res].  However, these do not seem
-   to directly impair IPv6 use, and are only referred to for
-   completeness.
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 7]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-4.  Recommendations for Service Provisioning using DNS
-
-
-   When names are added in the DNS to facilitate a service, there are
-   several general guidelines to consider to be able to do it as
-   smoothly as possible.
-
-
-4.1  Use of Service Names instead of Node Names
-
-
-   When a node provides multiple services which should not be
-   fate-sharing, or might support different IP versions, one should keep
-   them logically separate in the DNS.  Using SRV records [RFC2782]
-   would avoid these problems.  Unfortunately, those are not
-   sufficiently widely used to be applicable in most cases.  Hence an
-   operation technique is to use service names instead of node names
-   (or, "hostnames").  This operational technique is not specific to
-   IPv6, but required to understand the considerations described in
-   Section 4.2 and Section 4.3.
-
-
-   For example, assume a node named "pobox.example.com" provides both
-   SMTP and IMAP service.  Instead of configuring the MX records to
-   point at "pobox.example.com", and configuring the mail clients to
-   look up the mail via IMAP from "pobox.example.com", one should use
-   e.g., "smtp.example.com" for SMTP (for both message submission and
-   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
-   Note that in the specific case of SMTP relaying, the server itself
-   must typically also be configured to know all its names to ensure
-   loops do not occur.  DNS can provide a layer of indirection between
-   service names and where the service actually is, and using which
-   addresses.  (Obviously, when wanting to reach a specific node, one
-   should use the hostname rather than a service name.)
-
-
-   This is a good practice with IPv4 as well, because it provides more
-   flexibility and enables easier migration of services from one host to
-   another.  A specific reason why this is relevant for IPv6 is that the
-   different services may have a different level of IPv6 support -- that
-   is, one node providing multiple services might want to enable just
-   one service to be IPv6-visible while keeping some others as
-   IPv4-only, improving flexibility.
-
-
-4.2  Separate vs the Same Service Names for IPv4 and IPv6
-
-
-   The service naming can be achieved in basically two ways: when a
-   service is named "service.example.com" for IPv4, the IPv6-enabled
-   service could be either added to "service.example.com", or added
-   separately under a different name, e.g., in a sub-domain, like,
-   "service.ipv6.example.com".
-
-
-   These two methods have different characteristics.  Using a different
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 8]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   name allows for easier service piloting, minimizing the disturbance
-   to the "regular" users of IPv4 service; however, the service would
-   not be used transparently, without the user/application explicitly
-   finding it and asking for it -- which would be a disadvantage in most
-   cases.  When the different name is under a sub-domain, if the
-   services are deployed within a restricted network (e.g., inside an
-   enterprise), it's possible to prefer them transparently, at least to
-   a degree, by modifying the DNS search path; however, this is a
-   suboptimal solution.  Using the same service name is the "long-term"
-   solution, but may degrade performance for those clients whose IPv6
-   performance is lower than IPv4, or does not work as well (see Section
-   4.3 for more).
-
-
-   In most cases, it makes sense to pilot or test a service using
-   separate service names, and move to the use of the same name when
-   confident enough that the service level will not degrade for the
-   users unaware of IPv6.
-
-
-4.3  Adding the Records Only when Fully IPv6-enabled
-
-
-   The recommendation is that AAAA records for a service should not be
-   added to the DNS until all of following are true:
-
-
-   1.  The address is assigned to the interface on the node.
-
-
-   2.  The address is configured on the interface.
-
-
-   3.  The interface is on a link which is connected to the IPv6
-       infrastructure.
-
-
-   In addition, if the AAAA record is added for the node, instead of
-   service as recommended, all the services of the node should be
-   IPv6-enabled prior to adding the resource record.
-
-
-   For example, if an IPv6 node is isolated from an IPv6 perspective
-   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
-   that it should not have an address in the DNS.
-
-
-   Consider the case of two dual-stack nodes, which both have IPv6
-   enabled, but the server does not have (global) IPv6 connectivity.  As
-   the client looks up the server's name, only A records are returned
-   (if the recommendations above are followed), and no IPv6
-   communication, which would have been unsuccessful, is even attempted.
-
-
-   The issues are not always so black-and-white.  Usually it's important
-   if the service offered using both protocols is of roughly equal
-   quality, using the appropriate metrics for the service (e.g.,
-   latency, throughput, low packet loss, general reliability, etc.) --
-
-
-
-
-Durand, et al.          Expires February 7, 2005                [Page 9]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   this is typically very important especially for interactive or
-   real-time services.  In many cases, the quality of IPv6 connectivity
-   may not yet be equal to that of IPv4, at least globally -- this has
-   to be taken into consideration when enabling services
-   [I-D.savola-v6ops-6bone-mess].
-
-
-4.4  Behaviour of Additional Data in IPv4/IPv6 Environments
-
-
-4.4.1  Description of Additional Data Scenarios
-
-
-   Consider the case where the query name is so long, the number of the
-   additional records is so high, or for other reasons that the entire
-   response would not fit in a single UDP packet.  In some cases, the
-   responder truncates the response with the TC bit being set (leading
-   to a retry with TCP), in order for the querier to get the entire
-   response later.
-
-
-   There are two kinds of additional data:
-
-
-   1.  glue, i.e., "critical" additional data; this must be included in
-       all scenarios, with all the RRsets as possible, and
-
-
-   2.  "courtesy" additional data; this could be sent in full, with only
-       a few RRsets, or with no RRsets, and can be fetched separately as
-       well, but at the cost of additional queries.  This data must
-       never cause setting of the TC bit.
-
-
-   The responding server can algorithmically determine which type the
-   additional data is by checking whether it's at or below a zone cut.
-
-
-   Meanwhile, resource record sets (RRsets) are never "broken up", so if
-   a name has 4 A records and 5 AAAA records, you can either return all
-   9, all 4 A records, all 5 AAAA records or nothing.  In particular,
-   notice that for the "critical" additional data getting all the RRsets
-   can be critical.
-
-
-   An example of the "courtesy" additional data is A/AAAA records in
-   conjunction of MX records as shown in Section 4.5; an example of the
-   "critical" additional data is shown below (where getting both the A
-   and AAAA RRsets is critical):
-
-
-      child.example.com.    IN   NS ns.child.example.com.
-      ns.child.example.com. IN    A 192.0.2.1
-      ns.child.example.com. IN AAAA 2001:db8::1
-
-
-   When there is too much courtesy additional data, some or all of it
-   need to be removed [RFC2181]; if some is left in the response, the
-   issue is which data should be retained.  When there is too much
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 10]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   critical additional data, TC bit will have to be set, and some or all
-   of it need to be removed; if some is left in the response, the issue
-   is which data should be retained.
-
-
-   If the implementation decides to keep as much data as possible, it
-   might be tempting to use the transport of the DNS query as a hint in
-   either of these cases: return the AAAA records if the query was done
-   over IPv6, or return the A records if the query was done over IPv4.
-   However, this breaks the model of independence of DNS transport and
-   resource records, as noted in Section 1.2.
-
-
-   It is worth remembering that often the host using the records is
-   different from the node requesting them from the authoritative DNS
-   server (or even a caching resolver).  So, whichever version the
-   requestor (e.g., a recursive server in the middle) uses makes no
-   difference to the ultimate user of the records, whose transport
-   capabilities might differ from those of the requestor.  This might
-   result in e.g., inappropriately returning A records to an IPv6-only
-   node, going through a translation, or opening up another IP-level
-   session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
-   Therefore, at least in many scenarios, it would be very useful if the
-   information returned would be consistent and complete -- or if that
-   is not feasible, return no misleading information but rather leave it
-   to the client to query again.
-
-
-4.4.2  Discussion of the Problems
-
-
-   As noted above, the temptation for omitting only some of the
-   additional data based on the transport of the query could be
-   problematic.  In particular, there appears to be little justification
-   for doing so in the case of "courtesy" data.
-
-
-   However, with critical additional data, the alternatives are either
-   returning nothing (and requiring a retry with TCP) or returning
-   something (possibly obviating the need for a retry with TCP).  If the
-   process for selecting "something" from the critical data would
-   otherwise be practically "flipping the coin" between A and AAAA
-   records, it could be argued that if one looked at the transport of
-   the query, it would have a larger possibility of being right than
-   just 50/50.  In other words, if the returned critical additional data
-   would have to be selected somehow, using something more sophisticated
-   than a random process would seem justifiable.
-
-
-   The problem of too much additional data seems to be an operational
-   one: the zone administrator entering too many records which will be
-   returned either truncated or missing some RRsets to the users.  A
-   protocol fix for this is using EDNS0 [RFC2671] to signal the capacity
-   for larger UDP packet sizes, pushing up the relevant threshold.
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 11]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   Further, DNS server implementations should rather omit courtesy
-   additional data completely rather than including only some RRsets
-   [RFC2181].  An operational fix for this is having the DNS server
-   implementations return a warning when the administrators create zones
-   which would result in too much additional data being returned.
-   Further, DNS server implementations should warn of or disallow such
-   zone configurations which are recursive or otherwise difficult to
-   manage by the protocol.
-
-
-   Additionally, to avoid the case where an application would not get an
-   address at all due to some of "courtesy" additional data being
-   omitted, the resolvers should be able to query the specific records
-   of the desired protocol, not just rely on getting all the required
-   RRsets in the additional section.
-
-
-4.5  The Use of TTL for IPv4 and IPv6 RRs
-
-
-   In the previous section, we discussed a danger with queries,
-   potentially leading to omitting RRsets from the additional section;
-   this could happen to both critical and "courtesy" additional data.
-   This section discusses another problem with the latter, leading to
-   omitting RRsets in cached data, highlighted in the IPv4/IPv6
-   environment.
-
-
-   The behaviour of DNS caching when different TTL values are used for
-   different RRsets of the same name requires explicit discussion.  For
-   example, let's consider a part of a zone:
-
-
-      example.com.        300    IN    MX     foo.example.com.
-      foo.example.com.    300    IN    A      192.0.2.1
-      foo.example.com.    100    IN    AAAA   2001:db8::1
-
-
-   When a caching resolver asks for the MX record of example.com, it
-   gets back "foo.example.com".  It may also get back either one or both
-   of the A and AAAA records in the additional section.  So, there are
-   three cases about returning records for the MX in the additional
-   section:
-
-
-   1.  We get back no A or AAAA RRsets: this is the simplest case,
-       because then we have to query which information is required
-       explicitly, guaranteeing that we get all the information we're
-       interested in.
-
-
-   2.  We get back all the RRsets: this is an optimization as there is
-       no need to perform more queries, causing lower latency.  However,
-       it is impossible to guarantee that in fact we would always get
-       back all the records (the only way to ensure that is to send a
-       AAAA query for the name after getting the cached reply with A
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 12]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-       records or vice versa).
-
-
-   3.  We only get back A or AAAA RRsets even if both existed: this is
-       indistinguishable from the previous case, and may have problems
-       at least in certain environments as described in the previous
-       section.
-
-
-   As the third case was considered in the previous section, we assume
-   we get back both A and AAAA records of foo.example.com, or the stub
-   resolver explicitly asks, in two separate queries, both A and AAAA
-   records.
-
-
-   After 100 seconds, the AAAA record is removed from the cache(s)
-   because its TTL expired.  It could be argued to be useful for the
-   caching resolvers to discard the A record when the shorter TTL (in
-   this case, for the AAAA record) expires; this would avoid the
-   situation where there would be a window of 200 seconds when
-   incomplete information is returned from the cache.  The behaviour in
-   this scenario is unspecified.
-
-
-   To simplify the situation, it might help to use the same TTL for all
-   the resource record sets referring to the same name, unless there is
-   a particular reason for not doing so.  However, there are some
-   scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
-   a different strategy is preferable.
-
-
-   Thus, applications that use the response should not rely on a
-   particular TTL configuration.  For example, even if an application
-   gets a response that only has the A record in the example described
-   above, it should be still aware that there could be a AAAA record for
-   "foo.example.com".  That is, the application should try to fetch the
-   missing records itself if it needs the record.
-
-
-4.6  IPv6 Transport Guidelines for DNS Servers
-
-
-   As described in Section 1.3 and
-   [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to
-   be at least one authoritative IPv4 DNS server for every zone, even if
-   the zone has only IPv6 records.  (Note that obviously, having more
-   servers with robust connectivity would be preferable, but this is the
-   minimum recommendation; also see [RFC2182].)
-
-
-5.  Recommendations for DNS Resolver IPv6 Support
-
-
-   When IPv6 is enabled on a node, there are several things to consider
-   to ensure that the process is as smooth as possible.
-
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 13]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-5.1  DNS Lookups May Query IPv6 Records Prematurely
-
-
-   The system library that implements the getaddrinfo() function for
-   looking up names is a critical piece when considering the robustness
-   of enabling IPv6; it may come in basically three flavours:
-
-
-   1.  The system library does not know whether IPv6 has been enabled in
-       the kernel of the operating system: it may start looking up AAAA
-       records with getaddrinfo() and AF_UNSPEC hint when the system is
-       upgraded to a system library version which supports IPv6.
-
-
-   2.  The system library might start to perform IPv6 queries with
-       getaddrinfo() only when IPv6 has been enabled in the kernel.
-       However, this does not guarantee that there exists any useful
-       IPv6 connectivity (e.g., the node could be isolated from the
-       other IPv6 networks, only having link-local addresses).
-
-
-   3.  The system library might implement a toggle which would apply
-       some heuristics to the "IPv6-readiness" of the node before
-       starting to perform queries; for example, it could check whether
-       only link-local IPv6 address(es) exists, or if at least one
-       global IPv6 address exists.
-
-
-   First, let us consider generic implications of unnecessary queries
-   for AAAA records: when looking up all the records in the DNS, AAAA
-   records are typically tried first, and then A records.  These are
-   done in serial, and the A query is not performed until a response is
-   received to the AAAA query.  Considering the misbehaviour of DNS
-   servers and load-balancers, as described in Section 3.1, the look-up
-   delay for AAAA may incur additional unnecessary latency, and
-   introduce a component of unreliability.
-
-
-   One option here could be to do the queries partially in parallel; for
-   example, if the final response to the AAAA query is not received in
-   0.5 seconds, start performing the A query while waiting for the
-   result (immediate parallelism might be unoptimal, at least without
-   information sharing between the look-up threads, as that would
-   probably lead to duplicate non-cached delegation chain lookups).
-
-
-   An additional concern is the address selection, which may, in some
-   circumstances, prefer AAAA records over A records even when the node
-   does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
-   In some cases, the implementation may attempt to connect or send a
-   datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
-   incurring very long protocol timeouts, instead of quickly failing
-   back to IPv4.
-
-
-   Now, we can consider the issues specific to each of the three
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 14]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   possibilities:
-
-
-   In the first case, the node performs a number of completely useless
-   DNS lookups as it will not be able to use the returned AAAA records
-   anyway.  (The only exception is where the application desires to know
-   what's in the DNS, but not use the result for communication.)  One
-   should be able to disable these unnecessary queries, for both latency
-   and reliability reasons.  However, as IPv6 has not been enabled, the
-   connections to IPv6 addresses fail immediately, and if the
-   application is programmed properly, the application can fall
-   gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].
-
-
-   The second case is similar to the first, except it happens to a
-   smaller set of nodes when IPv6 has been enabled but connectivity has
-   not been provided yet; similar considerations apply, with the
-   exception that IPv6 records, when returned, will be actually tried
-   first which may typically lead to long timeouts.
-
-
-   The third case is a bit more complex: optimizing away the DNS lookups
-   with only link-locals is probably safe (but may be desirable with
-   different lookup services which getaddrinfo() may support), as the
-   link-locals are typically automatically generated when IPv6 is
-   enabled, and do not indicate any form of IPv6 connectivity.  That is,
-   performing DNS lookups only when a non-link-local address has been
-   configured on any interface could be beneficial -- this would be an
-   indication that either the address has been configured either from a
-   router advertisement, DHCPv6 [RFC3315], or manually.  Each would
-   indicate at least some form of IPv6 connectivity, even though there
-   would not be guarantees of it.
-
-
-   These issues should be analyzed at more depth, and the fixes found
-   consensus on, perhaps in a separate document.
-
-
-5.2  Obtaining a List of DNS Recursive Resolvers
-
-
-   In scenarios where DHCPv6 is available, a host can discover a list of
-   DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
-   option [RFC3646].  This option can be passed to a host through a
-   subset of DHCPv6 [RFC3736].
-
-
-   The IETF is considering the development of alternative mechanisms for
-   obtaining the list of DNS recursive name servers when DHCPv6 is
-   unavailable or inappropriate.  No decision about taking on this
-   development work has been reached as of this writing (Aug 2004)
-   [I-D.ietf-dnsop-ipv6-dns-configuration].
-
-
-   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
-   under consideration for development include the use of well-known
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 15]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   addresses [I-D.ohta-preconfigured-dns] and the use of Router
-   Advertisements to convey the information
-   [I-D.jeong-dnsop-ipv6-dns-discovery].
-
-
-   Note that even though IPv6 DNS resolver discovery is a recommended
-   procedure, it is not required for dual-stack nodes in dual-stack
-   networks as IPv6 DNS records can be queried over IPv4 as well as
-   IPv6.  Obviously, nodes which are meant to function without manual
-   configuration in IPv6-only networks must implement the DNS resolver
-   discovery function.
-
-
-5.3  IPv6 Transport Guidelines for Resolvers
-
-
-   As described in Section 1.3 and
-   [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers
-   should be IPv4-only or dual-stack to be able to reach any IPv4-only
-   DNS server.  Note that this requirement is also fulfilled by an
-   IPv6-only stub resolver pointing to a dual-stack recursive DNS
-   resolver.
-
-
-6.  Considerations about Forward DNS Updating
-
-
-   While the topic how to enable updating the forward DNS, i.e., the
-   mapping from names to the correct new addresses, is not specific to
-   IPv6, it should be considered especially due to the advent of
-   Stateless Address Autoconfiguration [RFC2462].
-
-
-   Typically forward DNS updates are more manageable than doing them in
-   the reverse DNS, because the updater can often be assumed to "own" a
-   certain DNS name -- and we can create a form of security relationship
-   with the DNS name and the node which is allowed to update it to point
-   to a new address.
-
-
-   A more complex form of DNS updates -- adding a whole new name into a
-   DNS zone, instead of updating an existing name -- is considered out
-   of scope for this memo as it could require zone-wide authentication.
-   Adding a new name in the forward zone is a problem which is still
-   being explored with IPv4, and IPv6 does not seem to add much new in
-   that area.
-
-
-6.1  Manual or Custom DNS Updates
-
-
-   The DNS mappings can also be maintained by hand, in a semi-automatic
-   fashion or by running non-standardized protocols.  These are not
-   considered at more length in this memo.
-
-
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 16]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-6.2  Dynamic DNS
-
-
-   Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized
-   mechanism for dynamically updating the DNS.  It works equally well
-   with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
-   address configuration.  It is important to consider how each of these
-   behave if IP address-based authentication, instead of stronger
-   mechanisms [RFC3007], was used in the updates.
-
-
-   1.  manual addresses are static and can be configured
-
-
-   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
-       on the deployment, and could or could not be configured on the
-       DNS server for the long term
-
-
-   3.  SLAAC addresses are typically stable for a long time, but could
-       require work to be configured and maintained.
-
-
-   As relying on IP addresses for Dynamic DNS is rather insecure at
-   best, stronger authentication should always be used; however, this
-   requires that the authorization keying will be explicitly configured
-   using unspecified operational methods.
-
-
-   Note that with DHCP it is also possible that the DHCP server updates
-   the DNS, not the host.  The host might only indicate in the DHCP
-   exchange which hostname it would prefer, and the DHCP server would
-   make the appropriate updates.  Nonetheless, while this makes setting
-   up a secure channel between the updater and the DNS server easier, it
-   does not help much with "content" security, i.e., whether the
-   hostname was acceptable -- if the DNS server does not include
-   policies, they must be included in the DHCP server (e.g., a regular
-   host should not be able to state that its name is "www.example.com").
-   DHCP-initiated DDNS updates have been extensively described in
-   [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
-   [I-D.ietf-dnsext-dhcid-rr].
-
-
-   The nodes must somehow be configured with the information about the
-   servers where they will attempt to update their addresses, sufficient
-   security material for authenticating themselves to the server, and
-   the hostname they will be updating.  Unless otherwise configured, the
-   first could be obtained by looking up the authoritative name servers
-   for the hostname; the second must be configured explicitly unless one
-   chooses to trust the IP address-based authentication (not a good
-   idea); and lastly, the nodename is typically pre-configured somehow
-   on the node, e.g., at install time.
-
-
-   Care should be observed when updating the addresses not to use longer
-   TTLs for addresses than are preferred lifetimes for the addresses, so
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 17]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   that if the node is renumbered in a managed fashion, the amount of
-   stale DNS information is kept to the minimum.  That is, if the
-   preferred lifetime of an address expires, the TTL of the record needs
-   be modified unless it was already done before the expiration.  For
-   better flexibility, the DNS TTL should be much shorter (e.g., a half
-   or a third) than the lifetime of an address; that way, the node can
-   start lowering the DNS TTL if it seems like the address has not been
-   renewed/refreshed in a while.  Some discussion on how an
-   administrator could manage the DNS TTL is included in
-   [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to
-   (smart) hosts as well.
-
-
-7.  Considerations about Reverse DNS Updating
-
-
-   Updating the reverse DNS zone may be difficult because of the split
-   authority over an address.  However, first we have to consider the
-   applicability of reverse DNS in the first place.
-
-
-7.1  Applicability of Reverse DNS
-
-
-   Today, some applications use reverse DNS to either look up some hints
-   about the topological information associated with an address (e.g.
-   resolving web server access logs), or as a weak form of a security
-   check, to get a feel whether the user's network administrator has
-   "authorized" the use of the address (on the premises that adding a
-   reverse record for an address would signal some form of
-   authorization).
-
-
-   One additional, maybe slightly more useful usage is ensuring that the
-   reverse and forward DNS contents match (by looking up the pointer to
-   the name by the IP address from the reverse tree, and ensuring that a
-   record under the name in the forward tree points to the IP address)
-   and correspond to a configured name or domain.  As a security check,
-   it is typically accompanied by other mechanisms, such as a user/
-   password login; the main purpose of the reverse+forward DNS check is
-   to weed out the majority of unauthorized users, and if someone
-   managed to bypass the checks, he would still need to authenticate
-   "properly".
-
-
-   It may also be desirable to store IPsec keying material corresponding
-   to an IP address to the reverse DNS, as justified and described in
-   [I-D.ietf-ipseckey-rr].
-
-
-   It is not clear whether it makes sense to require or recommend that
-   reverse DNS records be updated.  In many cases, it would just make
-   more sense to use proper mechanisms for security (or topological
-   information lookup) in the first place.  At minimum, the applications
-   which use it as a generic authorization (in the sense that a record
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 18]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   exists at all) should be modified as soon as possible to avoid such
-   lookups completely.
-
-
-   The applicability is discussed at more length in
-   [I-D.ietf-dnsop-inaddr-required].
-
-
-7.2  Manual or Custom DNS Updates
-
-
-   Reverse DNS can of course be updated using manual or custom methods.
-   These are not further described here, except for one special case.
-
-
-   One way to deploy reverse DNS would be to use wildcard records, for
-   example, by configuring one name for a subnet (/64) or a site (/48).
-   As a concrete example, a site (or the site's ISP) could configure the
-   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
-   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR
-   site.example.com." Naturally, such a name could not be verified from
-   the forward DNS, but would at least provide some form of "topological
-   information" or "weak authorization" if that is really considered to
-   be useful.  Note that this is not actually updating the DNS as such,
-   as the whole point is to avoid DNS updates completely by manually
-   configuring a generic name.
-
-
-7.3  DDNS with Stateless Address Autoconfiguration
-
-
-   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
-   some regard, while being more difficult in another, as described
-   below.
-
-
-   The address space administrator decides whether the hosts are trusted
-   to update their reverse DNS records or not.  If they are, a simple
-   address-based authorization is typically sufficient (i.e., check that
-   the DNS update is done from the same IP address as the record being
-   updated); stronger security can also be used [RFC3007].  If they
-   aren't allowed to update the reverses, no update can occur.  (Such
-   address-based update authorization operationally requires that
-   ingress filtering [RFC3704] has been set up at the border of the site
-   where the updates occur, and as close to the updater as possible.)
-
-
-   Address-based authorization is simpler with reverse DNS (as there is
-   a connection between the record and the address) than with forward
-   DNS.  However, when a stronger form of security is used, forward DNS
-   updates are simpler to manage because the host can be assumed to have
-   an association with the domain.  Note that the user may roam to
-   different networks, and does not necessarily have any association
-   with the owner of that address space -- so, assuming stronger form of
-   authorization for reverse DNS updates than an address association is
-   generally unfeasible.
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 19]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   Moreover, the reverse zones must be cleaned up by an unspecified
-   janitorial process: the node does not typically know a priori that it
-   will be disconnected, and cannot send a DNS update using the correct
-   source address to remove a record.
-
-
-   A problem with defining the clean-up process is that it is difficult
-   to ensure that a specific IP address and the corresponding record are
-   no longer being used.  Considering the huge address space, and the
-   unlikelihood of collision within 64 bits of the interface
-   identifiers, a process which would remove the record after no traffic
-   has been seen from a node in a long period of time (e.g., a month or
-   year) might be one possible approach.
-
-
-   To insert or update the record, the node must discover the DNS server
-   to send the update to somehow, similar to as discussed in Section
-   6.2.  One way to automate this is looking up the DNS server
-   authoritative (e.g., through SOA record) for the IP address being
-   updated, but the security material (unless the IP address-based
-   authorization is trusted) must also be established by some other
-   means.
-
-
-   One should note that Cryptographically Generated Addresses
-   [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of
-   treatment.  CGAs are addresses where the interface identifier is
-   calculated from a public key, a modifier (used as a nonce), the
-   subnet prefix, and other data.  Depending on the usage profile, CGAs
-   might or might not be changed periodically due to e.g., privacy
-   reasons.  As the CGA address is not predicatable, a reverse record
-   can only reasonably be inserted in the DNS by the node which
-   generates the address.
-
-
-7.4  DDNS with DHCP
-
-
-   With DHCPv4, the reverse DNS name is typically already inserted to
-   the DNS that reflects to the name (e.g., "dhcp-67.example.com").  One
-   can assume similar practice may become commonplace with DHCPv6 as
-   well; all such mappings would be pre-configured, and would require no
-   updating.
-
-
-   If a more explicit control is required, similar considerations as
-   with SLAAC apply, except for the fact that typically one must update
-   a reverse DNS record instead of inserting one (if an address
-   assignment policy that reassigns disused addresses is adopted) and
-   updating a record seems like a slightly more difficult thing to
-   secure.  However, it is yet uncertain how DHCPv6 is going to be used
-   for address assignment.
-
-
-   Note that when using DHCP, either the host or the DHCP server could
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 20]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   perform the DNS updates; see the implications in Section 6.2.
-
-
-   If disused addresses were to be reassigned, host-based DDNS reverse
-   updates would need policy considerations for DNS record modification,
-   as noted above.  On the other hand, if disused address were not to be
-   assigned, host-based DNS reverse updates would have similar
-   considerations as SLAAC in Section 7.3.  Server-based updates have
-   similar properties except that the janitorial process could be
-   integrated with DHCP address assignment.
-
-
-7.5  DDNS with Dynamic Prefix Delegation
-
-
-   In cases where a prefix, instead of an address, is being used and
-   updated, one should consider what is the location of the server where
-   DDNS updates are made.  That is, where the DNS server is located:
-
-
-   1.  At the same organization as the prefix delegator.
-
-
-   2.  At the site where the prefixes are delegated to.  In this case,
-       the authority of the DNS reverse zone corresponding to the
-       delegated prefix is also delegated to the site.
-
-
-   3.  Elsewhere; this implies a relationship between the site and where
-       DNS server is located, and such a relationship should be rather
-       straightforward to secure as well.  Like in the previous case,
-       the authority of the DNS reverse zone is also delegated.
-
-
-   In the first case, managing the reverse DNS (delegation) is simpler
-   as the DNS server and the prefix delegator are in the same
-   administrative domain (as there is no need to delegate anything at
-   all); alternatively, the prefix delegator might forgo DDNS reverse
-   capability altogether, and use e.g., wildcard records (as described
-   in Section 7.2).  In the other cases, it can be slighly more
-   difficult, particularly as the site will have to configure the DNS
-   server to be authoritative for the delegated reverse zone, implying
-   automatic configuration of the DNS server -- as the prefix may be
-   dynamic.
-
-
-   Managing the DDNS reverse updates is typically simple in the second
-   case, as the updated server is located at the local site, and
-   arguably IP address-based authentication could be sufficient (or if
-   not, setting up security relationships would be simpler).  As there
-   is an explicit (security) relationship between the parties in the
-   third case, setting up the security relationships to allow reverse
-   DDNS updates should be rather straightforward as well (but IP
-   address-based authentication might not be acceptable).  In the first
-   case, however, setting up and managing such relationships might be a
-   lot more difficult.
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 21]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-8.  Miscellaneous DNS Considerations
-
-
-   This section describes miscellaneous considerations about DNS which
-   seem related to IPv6, for which no better place has been found in
-   this document.
-
-
-8.1  NAT-PT with DNS-ALG
-
-
-   The DNS-ALG component of NAT-PT mangles A records  to look like AAAA
-   records to the IPv6-only nodes.  Numerous problems have been
-   identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues].
-   This is a strong reason not to use NAT-PT in the first place.
-
-
-8.2  Renumbering Procedures and Applications' Use of DNS
-
-
-   One of the most difficult problems of systematic IP address
-   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
-   an application which looks up a DNS name disregards information such
-   as TTL, and uses the result obtained from DNS as long as it happens
-   to be stored in the memory of the application.  For applications
-   which run for a long time, this could be days, weeks or even months;
-   some applications may be clever enough to organize the data
-   structures and functions in such a manner that look-ups get refreshed
-   now and then.
-
-
-   While the issue appears to have a clear solution, "fix the
-   applications", practically this is not reasonable immediate advice;
-   the TTL information is not typically available in the APIs and
-   libraries (so, the advice becomes "fix the applications, APIs and
-   libraries"), and a lot more analysis is needed on how to practically
-   go about to achieve the ultimate goal of avoiding using the names
-   longer than expected.
-
-
-9.  Acknowledgements
-
-
-   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
-   provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
-   Nordmark and Bob Gilligan.  Havard Eidnes and Michael Patton provided
-   useful feedback and improvements.  Scott Rose, Rob Austein, Masataka
-   Ohta, and Mark Andrews helped in clarifying the issues regarding
-   additional data and the use of TTL.  Jefsey Morfin, Ralph Droms,
-   Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
-   Rob Austein provided useful feedback during the WG last call.  Thomas
-   Narten provided extensive feedback during the IESG evaluation.
-
-
-10.  Security Considerations
-
-
-   This document reviews the operational procedures for IPv6 DNS
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 22]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   operations and does not have security considerations in itself.
-
-
-   However, it is worth noting that in particular with Dynamic DNS
-   Updates, security models based on the source address validation are
-   very weak and cannot be recommended -- they could only be considered
-   in the environments where ingress filtering [RFC3704] has been
-   deployed.  On the other hand, it should be noted that setting up an
-   authorization mechanism (e.g., a shared secret, or public-private
-   keys) between a node and the DNS server has to be done manually, and
-   may require quite a bit of time and expertise.
-
-
-   To re-emphasize which was already stated, the reverse+forward DNS
-   check provides very weak security at best, and the only
-   (questionable) security-related use for them may be in conjunction
-   with other mechanisms when authenticating a user.
-
-
-11.  References
-
-
-11.1  Normative References
-
-
-   [I-D.ietf-dnsop-ipv6-dns-configuration]
-              Jeong, J., "IPv6 Host Configuration of DNS Server
-              Information Approaches",
-              draft-ietf-dnsop-ipv6-dns-configuration-02 (work in
-              progress), July 2004.
-
-
-   [I-D.ietf-dnsop-ipv6-transport-guidelines]
-              Durand, A. and J. Ihren, "DNS IPv6 transport operational
-              guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02
-              (work in progress), March 2004.
-
-
-   [I-D.ietf-dnsop-misbehavior-against-aaaa]
-              Morishita, Y. and T. Jinmei, "Common Misbehavior against
-              DNS Queries for IPv6 Addresses",
-              draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
-              progress), April 2004.
-
-
-   [I-D.ietf-ipv6-deprecate-site-local]
-              Huitema, C. and B. Carpenter, "Deprecating Site Local
-              Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work
-              in progress), March 2004.
-
-
-   [I-D.ietf-v6ops-application-transition]
-              Shin, M., "Application Aspects of IPv6 Transition",
-              draft-ietf-v6ops-application-transition-03 (work in
-              progress), June 2004.
-
-
-   [I-D.ietf-v6ops-renumbering-procedure]
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 23]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-              Baker, F., Lear, E. and R. Droms, "Procedures for
-              Renumbering an IPv6 Network without a Flag Day",
-              draft-ietf-v6ops-renumbering-procedure-01 (work in
-              progress), July 2004.
-
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-
-   [RFC2182]  Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
-              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
-              July 1997.
-
-
-   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
-              Autoconfiguration", RFC 2462, December 1998.
-
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-
-   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
-              Stateless Address Autoconfiguration in IPv6", RFC 3041,
-              January 2001.
-
-
-   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
-              via IPv4 Clouds", RFC 3056, February 2001.
-
-
-   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
-              August 2001.
-
-
-   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
-              M. Carney, "Dynamic Host Configuration Protocol for IPv6
-              (DHCPv6)", RFC 3315, July 2003.
-
-
-   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T.
-              Hain, "Representing Internet Protocol version 6 (IPv6)
-              Addresses in the Domain Name System (DNS)", RFC 3363,
-              August 2002.
-
-
-   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
-              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
-              August 2002.
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 24]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-              (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
-              Extensions to Support IP Version 6", RFC 3596, October
-              2003.
-
-
-   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
-              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
-              December 2003.
-
-
-   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
-              (DHCP) Service for IPv6", RFC 3736, April 2004.
-
-
-11.2  Informative References
-
-
-   [I-D.durand-v6ops-natpt-dns-alg-issues]
-              Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
-              draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
-              progress), February 2003.
-
-
-   [I-D.huitema-v6ops-teredo]
-              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
-              NATs", draft-huitema-v6ops-teredo-02 (work in progress),
-              June 2004.
-
-
-   [I-D.huston-6to4-reverse-dns]
-              Huston, G., "6to4 Reverse DNS",
-              draft-huston-6to4-reverse-dns-02 (work in progress), April
-              2004.
-
-
-   [I-D.ietf-dhc-ddns-resolution]
-              Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
-              Clients", draft-ietf-dhc-ddns-resolution-07 (work in
-              progress), July 2004.
-
-
-   [I-D.ietf-dhc-fqdn-option]
-              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
-              draft-ietf-dhc-fqdn-option-07 (work in progress), July
-              2004.
-
-
-   [I-D.ietf-dnsext-dhcid-rr]
-              Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for
-              encoding DHCP information (DHCID RR)",
-              draft-ietf-dnsext-dhcid-rr-08 (work in progress), July
-              2004.
-
-
-   [I-D.ietf-dnsop-bad-dns-res]
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 25]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-              Larson, M. and P. Barber, "Observed DNS Resolution
-              Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
-              progress), July 2004.
-
-
-   [I-D.ietf-dnsop-dontpublish-unreachable]
-              Hazel, P., "IP Addresses that should never appear in the
-              public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
-              (work in progress), February 2002.
-
-
-   [I-D.ietf-dnsop-inaddr-required]
-              Senie, D., "Requiring DNS IN-ADDR Mapping",
-              draft-ietf-dnsop-inaddr-required-05 (work in progress),
-              April 2004.
-
-
-   [I-D.ietf-ipseckey-rr]
-              Richardson, M., "A method for storing IPsec keying
-              material in DNS", draft-ietf-ipseckey-rr-11 (work in
-              progress), July 2004.
-
-
-   [I-D.ietf-ipv6-unique-local-addr]
-              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-              Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
-              progress), June 2004.
-
-
-   [I-D.ietf-send-cga]
-              Aura, T., "Cryptographically Generated Addresses (CGA)",
-              draft-ietf-send-cga-06 (work in progress), April 2004.
-
-
-   [I-D.ietf-v6ops-3gpp-analysis]
-              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
-              Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
-              progress), May 2004.
-
-
-   [I-D.ietf-v6ops-mech-v2]
-              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
-              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04
-              (work in progress), July 2004.
-
-
-   [I-D.ietf-v6ops-onlinkassumption]
-              Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
-              On-Link Assumption Considered Harmful",
-              draft-ietf-v6ops-onlinkassumption-02 (work in progress),
-              May 2004.
-
-
-   [I-D.ietf-v6ops-v6onbydefault]
-              Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack
-              IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
-              (work in progress), July 2004.
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 26]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   [I-D.jeong-dnsop-ipv6-dns-discovery]
-              Jeong, J., "IPv6 DNS Discovery based on Router
-              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02
-              (work in progress), July 2004.
-
-
-   [I-D.moore-6to4-dns]
-              Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
-              in progress), October 2002.
-
-
-   [I-D.ohta-preconfigured-dns]
-              Ohta, M., "Preconfigured DNS Server Addresses",
-              draft-ohta-preconfigured-dns-01 (work in progress),
-              February 2004.
-
-
-   [I-D.savola-v6ops-6bone-mess]
-              Savola, P., "Moving from 6bone to IPv6 Internet",
-              draft-savola-v6ops-6bone-mess-01 (work in progress),
-              November 2002.
-
-
-   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
-              Translation - Protocol Translation (NAT-PT)", RFC 2766,
-              February 2000.
-
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-
-   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
-              Unique DNS Root", RFC 2826, May 2000.
-
-
-   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
-              Networks", BCP 84, RFC 3704, March 2004.
-
-
-
-Authors' Addresses
-
-
-   Alain Durand
-   SUN Microsystems, Inc.
-   17 Network circle UMPL17-202
-   Menlo Park, CA  94025
-   USA
-
-
-   EMail: Alain.Durand@sun.com
-
-
-
-
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 27]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm
-   Sweden
-
-
-   EMail: johani@autonomica.se
-
-
-
-   Pekka Savola
-   CSC/FUNET
-   Espoo
-   Finland
-
-
-   EMail: psavola@funet.fi
-
-
-Appendix A.  Site-local Addressing Considerations for DNS
-
-
-   As site-local addressing has been deprecated, the considerations for
-   site-local addressing are discussed briefly here.  Unique local
-   addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
-   as a replacement, but being work-in-progress, it is not considered
-   further.
-
-
-   The interactions with DNS come in two flavors: forward and reverse
-   DNS.
-
-
-   To actually use site-local addresses within a site, this implies the
-   deployment of a "split-faced" or a fragmented DNS name space, for the
-   zones internal to the site, and the outsiders' view to it.  The
-   procedures to achieve this are not elaborated here.  The implication
-   is that site-local addresses must not be published in the public DNS.
-
-
-   To faciliate reverse DNS (if desired) with site-local addresses, the
-   stub resolvers must look for DNS information from the local DNS
-   servers, not e.g.  starting from the root servers, so that the
-   site-local information may be provided locally.  Note that the
-   experience of private addresses in IPv4 has shown that the root
-   servers get loaded for requests for private address lookups in any
-   case.
-
-
-Appendix B.  Issues about Additional Data or TTL
-
-
-   [[ note to the RFC-editor: remove this section upon publication.  ]]
-
-
-   This appendix tries to describe the apparent rought consensus about
-   additional data and TTL issues (sections 4.4 and 4.5), and present
-   questions when there appears to be no consensus.  The point of
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 28]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-   recording them here is to focus the discussion and get feedback.
-
-
-   Resolved:
-
-
-   a.  If some critical additional data RRsets wouldn't fit, you set the
-       TC bit even if some RRsets did fit.
-
-
-   b.  If some courtesy additional data RRsets wouldn't fit, you never
-       set the TC bit, but rather remove (at least some of) the courtesy
-       RRsets.
-
-
-   c.  DNS servers should implement sanity checks on the resulting glue,
-       e.g., to disable circular dependencies.  Then the responding
-       servers can use at-or-below-a-zone-cut criterion to determine
-       whether the additional data is critical or not.
-
-
-   Open issues (at least):
-
-
-   1.  if some critical additional data RRsets would fit, but some
-       wouldn't, and TC has to be set (see above), should one rather
-       remove the additional data that did fit, keep it, or leave
-       unspecified?
-
-
-   2.  if some courtesy additional data RRsets would fit, but some
-       wouldn't, and some will have to be removed from the response (no
-       TC is set, see above), what to do -- remove all courtesy RRsets,
-       keep all that fit, or leave unspecified?
-
-
-   3.  is it acceptable to use the transport used in the DNS query as a
-       hint which records to keep if not removing all the RRsets, if: a)
-       having to decide which critical additional data to keep, or b)
-       having to decide which courtesy additional data to keep?
-
-
-   4.  (this issue was discussed in section 4.5) if one RRset has TTL of
-       100 seconds, and another the TTL of 300 seconds, what should the
-       caching server do after 100 seconds?  Keep returning just one
-       RRset when returning additional data, or discard the other RRset
-       from the cache?
-
-
-   5.  how do we move forward from here?  If we manage to get to some
-       form of consensus, how do we record it: a) just in
-       draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational
-       category only!), b) a separate BCP or similar by DNSEXT WG(?),
-       clarifying and giving recommendations, c) something else, what?
-
-
-
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 29]
-Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-Durand, et al.          Expires February 7, 2005               [Page 30]
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
deleted file mode 100644
index 2311ee6c18a0..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
+++ /dev/null
@@ -1,391 +0,0 @@
-
-DNSOP                                                          G. Guette
-Internet-Draft                                             IRISA / INRIA
-Expires: February 5, 2005                                     O. Courtay
-                                                             Thomson R&D
-                                                          August 7, 2004
-
-
-           Requirements for Automated Key Rollover in DNSSEC
-           draft-ietf-dnsop-key-rollover-requirements-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-	 
-   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.
-
-   This Internet-Draft will expire on February 5, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document describes problems that appear during an automated
-   rollover and gives the requirements for the design of communication
-   between parent zone and child zone in an automated rollover process.
-   This document is essentially about key rollover, the rollover of
-   another Resource Record present at delegation point (NS RR) is also
-   discussed.
-
-
-
-
-
-Guette & Courtay        Expires February 5, 2005                [Page 1]
-
-Internet-Draft      Automated Rollover Requirements          August 2004
-
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
-   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
-   4.   Messages authentication and information exchanged  . . . . . . 4
-   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
-   6.   Other Resource Record concerned by automatic rollover  . . . . 5
-   7.   Security consideration . . . . . . . . . . . . . . . . . . . . 5
-   8.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 5
-   9.   Normative References . . . . . . . . . . . . . . . . . . . . . 5
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
-        Intellectual Property and Copyright Statements . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Guette & Courtay        Expires February 5, 2005                [Page 2]
-
-Internet-Draft      Automated Rollover Requirements          August 2004
-
-
-1.  Introduction
-
-   The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key
-   cryptography and digital signatures.  It stores the public part of
-   keys in DNSKEY Resource Records (RRs).  Because old keys and
-   frequently used keys are vulnerable, they must be renewed
-   periodically.  In DNSSEC, this is the case for Zone Signing Keys
-   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
-   rollover process is necessary for large zones because there are too
-   many changes to handle a manual administration.
-
-   Let us consider for example a zone with 100000 secure delegations.
-   If the child zones change their keys once a year on average, that
-   implies 300 changes per day for the parent zone.  This amount of
-   changes are hard to manage manually.
-
-   Automated rollover is optional and resulting from an agreement
-   between the administrator of the parent zone and the administrator of
-   the child zone.  Of course, key rollover can also be done manually by
-   administrators.
-
-   This document describes the requirements for the design of messages
-   of automated key rollover process and focusses on interaction between
-   parent and child zone.
-
-2.  The Key Rollover Process
-
-   Key rollover consists in renewing the DNSSEC keys used to sign
-   resource records in a given DNS zone file.  There are two types of
-   rollover, ZSK rollovers and KSK rollovers.
-
-   In a ZSK rollover, all changes are local to the zone that renews its
-   key: there is no need to contact other zones (e.g., parent zone) to
-   propagate the performed changes because a ZSK has no associated DS
-   record in the parent zone.
-
-   In a KSK rollover, new DS RR(s) must be created and stored in the
-   parent zone.  In consequence, the child zone must contact its parent
-   zone and must notify it about the KSK change(s).
-
-   Manual key rollover exists and works [3].  The key rollover is built
-   from two parts of different nature:
-   o  An algorithm that generates new keys and signs the zone file.  It
-      could be local to the zone
-   o  The interaction between parent and child zones
-
-   One example of manual key rollover is:
-
-
-
-
-Guette & Courtay        Expires February 5, 2005                [Page 3]
-
-Internet-Draft      Automated Rollover Requirements          August 2004
-
-
-   o  The child zone creates a new KSK
-   o  The child zone waits for the creation of the DS RR in its parent
-      zone
-   o  The child zone deletes the old key.
-
-   In manual rollover, communications are managed by the zone
-   administrators and the security of these communications is out of
-   scope of DNSSEC.
-
-   Automated key rollover should use a secure communication between
-   parent and child zones.  This document concentrates on defining
-   interactions between entities present in key rollover process.
-
-3.  Basic Requirements
-
-   The main constraint to respect during a key rollover is that the
-   chain of trust MUST be preserved, even if a resolver retrieves some
-   RRs from recursive cache server.  Every RR MUST be verifiable at any
-   time, every RRs exchanged during the rollover should be authenticated
-   and their integrity should be guaranteed.
-
-   Two entities act during a KSK rollover: the child zone and its parent
-   zone.  These zones are generally managed by different administrators.
-   These administrators should agree on some parameters like
-   availability of automated rollover, the maximum delay between
-   notification of changes in the child zone and the resigning of the
-   parent zone.  The child zone needs to know this delay to schedule its
-   changes.
-
-4.  Messages authentication and information exchanged
-
-   Every exchanged message MUST be authenticated and the authentication
-   tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC
-   request with verifiable SIG records.
-
-   Once the changes related to a KSK are made in a child zone, this zone
-   MUST notify its parent zone in order to create the new DS RR and
-   store this DS RR in parent zone file.
-
-   The parent zone MUST receive all the child keys that needs the
-   creation of associated DS RRs in the parent zone.
-
-   Some errors could occur during transmission between child zone and
-   parent zone.  Key rollover solution MUST be fault tolerant, i.e.  at
-   any time the rollover MUST be in a consistent state and all RRs MUST
-   be verifiable, even if an error occurs.  That is to say that it MUST
-   remain a valid chain of trust.
-
-
-
-
-Guette & Courtay        Expires February 5, 2005                [Page 4]
-
-Internet-Draft      Automated Rollover Requirements          August 2004
-
-
-5.  Emergency Rollover
-
-   A key of a zone might be compromised and this key MUST be changed as
-   soon as possible.  Fast changes could break the chain of trust.  The
-   part of DNS tree having this zone as apex can become unverifiable,
-   but the break of the chain of trust is necessary if we want to no one
-   can use the compromised key to spoof DNS data.
-
-   In case of emergency rollover, the administrators of parent and child
-   zones should create new key(s) and DS RR(s) as fast as possible in
-   order to reduce the time the chain of trust is broken.
-
-6.  Other Resource Record concerned by automatic rollover
-
-   NS records are also present at delegation point, so when the child
-   zone renews some NS RR, the corresponding records at delegation point
-   in parent zone (glue) MUST be updated.  NS records are concerned by
-   rollover and this rollover could be automated too.  In this case,
-   when the child zone notifies its parent zone that some NS records
-   have been changed, the parent zone MUST verify that these NS records
-   are present in child zone before doing any changes in its own zone
-   file.  This allows to avoid inconsistency between NS records at
-   delegation point and NS records present in the child zone.
-
-7.  Security consideration
-
-   This document describes requirements to design an automated key
-   rollover in DNSSEC based on DNSSEC security.  In the same way, as
-   plain DNSSEC, the automatic key rollover contains no mechanism
-   protecting against denial of service (DoS).  The security level
-   obtain after an automatic key rollover, is the security level
-   provided by DNSSEC.
-
-8.  Acknowledgments
-
-   The authors want to acknowledge Francis Dupont, Mohsen Souissi,
-   Bernard Cousin, Bertrand L‰onard and members of IDsA project for
-   their contribution to this document.
-
-9  Normative References
-
-   [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-        RFC 3658, December 2003.
-
-   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
-        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
-        RFC 3757, May 2004.
-
-
-
-
-Guette & Courtay        Expires February 5, 2005                [Page 5]
-
-Internet-Draft      Automated Rollover Requirements          August 2004
-
-
-   [3]  Kolkman, O., "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practice-01 (work in
-        progress), May 2004.
-
-   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [5]  Eastlake, D., "DNS Request and Transaction Signatures (
-        SIG(0)s)", RFC 2931, September 2000.
-
-   [6]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-        "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-        2845, May 2000.
-
-   [7]  Arends, R., "Resource Records for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-records-09 (work in progress), July
-        2004.
-
-   [8]  Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
-        "DNS Security Introduction and Requirements",
-        draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004.
-
-   [9]  Arends, R., "Protocol Modifications for the DNS Security
-        Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in
-        progress), July 2004.
-
-
-Authors' Addresses
-
-   Gilles Guette
-   IRISA / INRIA
-   Campus de Beaulieu
-   35042  Rennes CEDEX
-   FR
-
-   EMail: gilles.guette@irisa.fr
-   URI:   http://www.irisa.fr
-
-
-   Olivier Courtay
-   Thomson R&D
-   1, avenue Belle Fontaine
-   35510  Cesson S‰vign‰ CEDEX
-   FR
-
-   EMail: olivier.courtay@thomson.net
-
-
-
-
-
-Guette & Courtay        Expires February 5, 2005                [Page 6]
-
-Internet-Draft      Automated Rollover Requirements          August 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Guette & Courtay        Expires February 5, 2005                [Page 7]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
deleted file mode 100644
index 1094275d3e40..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-
-IETF DNSOP Working Group                                    Y. Morishita
-Internet-Draft                                                      JPRS
-Expires: July 11, 2004                                         T. Jinmei
-                                                                 Toshiba
-                                                        January 11, 2004
-
-
-       Common Misbehavior against DNS Queries for IPv6 Addresses
-            draft-ietf-dnsop-misbehavior-against-aaaa-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.
-
-   This Internet-Draft will expire on July 11, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   There is some known misbehavior of DNS authoritative servers when
-   they are queried for AAAA resource records. Such behavior can block
-   IPv4 communication which should actually be available, cause a
-   significant delay in name resolution, or even make a denial of
-   service attack. This memo describes details of the known cases and
-   discusses the effect of the cases.
-
-1. Introduction
-
-   Many DNS clients (resolvers) that support IPv6 first search for AAAA
-   Resource Records (RRs) of a target host name, and then for A RRs of
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 1]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-   the same name. This fallback mechanism is based on the DNS
-   specifications, which if not obeyed by authoritative servers can
-   produce unpleasant results. In some cases, for example, a web browser
-   fails to connect to a web server it could otherwise. In the following
-   sections, this memo describes some typical cases of the misbehavior
-   and its (bad) effects.
-
-   Note that the misbehavior is not specific to AAAA RRs. In fact, all
-   known examples also apply to the cases of queries for MX, NS, and SOA
-   RRs. The authors even believe this can be generalized for all types
-   of queries other than those for A RRs. In this memo, however, we
-   concentrate on the case for AAAA queries, since the problem is
-   particularly severe for resolvers that support IPv6, which thus
-   affects many end users. Resolvers at end users normally send A and/or
-   AAAA queries only, and so the problem for the other cases is
-   relatively minor.
-
-2. Network Model
-
-   In this memo, we assume a typical network model of name resolution
-   environment using DNS. It consists of three components; stub
-   resolvers, caching servers, and authoritative servers. A stub
-   resolver issues a recursive query to a caching server, which then
-   handles the entire name resolution procedure recursively. The caching
-   server caches the result of the query as well as sends the result to
-   the stub resolver. The authoritative servers respond to queries for
-   names for which they have the authority, normally in a non-recursive
-   manner.
-
-3. Expected Behavior
-
-   Suppose that an authoritative server has an A RR but not a AAAA RR
-   for a host name. Then the server should return a response to a query
-   for a AAAA RR of the name with the RCODE being 0 (indicating no
-   error) and with an empty answer section [1]. Such a response
-   indicates that there is at least one RR of a different type than AAAA
-   for the queried name, and the stub resolver can then look for A RRs.
-
-   This way, the caching server can cache the fact that the queried name
-   does not have a AAAA RR (but may have other types of RRs), and thus
-   can improve the response time to further queries for a AAAA RR of the
-   name.
-
-4. Problematic Behaviors
-
-   There are some known cases at authoritative servers that do not
-   conform to the expected behavior. This section describes those
-   problematic cases.
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 2]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-4.1 Return NXDOMAIN
-
-   This type of server returns a response with the RCODE being 3
-   (NXDOMAIN) to a query for a AAAA RR, indicating it does not have any
-   RRs of any type for the queried name.
-
-   With this response, the stub resolver may immediately give up and
-   never fall back. Even if the resolver retries with a query for an A
-   RR, the negative response for the name has been cached in the caching
-   server, and the caching server will simply return the negative
-   response. As a result, the stub resolver considers this as a fatal
-   error in name resolution.
-
-   There have been several known examples of this behavior, but all the
-   examples that the authors know have changed their behavior as of this
-   writing.
-
-4.2 Return NOTIMP
-
-   Other authoritative servers return a response with the RCODE being 4
-   (NOTIMP), indicating the servers do not support the requested type of
-   query.
-
-   This case is less harmful than the previous one; if the stub resolver
-   falls back to querying for an A RR, the caching server will process
-   the query correctly and return an appropriate response.
-
-   In this case, the caching server does not cache the fact that the
-   queried name has no AAAA RR, resulting in redundant queries for AAAA
-   RRs in the future. The behavior will waste network bandwidth and
-   increase the load of the authoritative server.
-
-   Using SERVFAIL or FORMERR would cause the same effect, though the
-   authors have not seen such implementations yet.
-
-4.3 Return a Broken Response
-
-   Another different type of authoritative servers returns broken
-   responses to AAAA queries. A known behavior of this category is to
-   return a response whose RR type is AAAA, but the length of the RDATA
-   is 4 bytes. The 4-byte data looks like the IPv4 address of the
-   queried host name. That is, the RR in the answer section would be
-   described like this:
-
-     www.bad.example. 600 IN AAAA 192.0.2.1
-
-   which is, of course, bogus (or at least meaningless).
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 3]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-   A widely deployed caching server implementation transparently returns
-   the broken response (as well as caches it) to the stub resolver.
-   Another known server implementation parses the response by
-   themselves, and sends a separate response with the RCODE being 2
-   (SERVFAIL).
-
-   In either case, the broken response does not affect queries for an A
-   RR of the same name. If the stub resolver falls back to A queries, it
-   will get an appropriate response.
-
-   The latter case, however, causes the same bad effect as that
-   described in the previous section: redundant queries for AAAA RRs.
-
-4.4 Make Lame Delegation
-
-   Some authoritative servers respond to AAAA queries in a way causing
-   lame delegation. In this case the parent zone specifies that the
-   authoritative server should have the authority of a zone, but the
-   server does not return an authoritative response for AAAA queries
-   within the zone (i.e., the AA bit in the response is not set). On the
-   other hand, the authoritative server returns an authoritative
-   response for A queries.
-
-   When a caching server asks the server for AAAA RRs in the zone, it
-   recognizes the delegation is lame, and return a response with the
-   RCODE being 2 (SERVFAIL) to the stub resolver.
-
-   Furthermore, some caching servers record the authoritative server as
-   lame for the zone and will not use it for a certain period of time.
-   With this type of caching server, even if the stub resolver falls
-   back to querying for an A RR, the caching server will simply return a
-   response with the RCODE being SERVFAIL, since all the servers are
-   known to be "lame."
-
-   There is also an implementation that relaxes the behavior a little
-   bit. It basically tries to avoid using the lame server, but still
-   continues to try it as a last resort. With this type of caching
-   server, the stub resolver will get a correct response if it falls
-   back after SERVFAIL. However, this still causes redundant AAAA
-   queries as explained in the previous sections.
-
-4.5 Ignore Queries for AAAA
-
-   Some authoritative severs seem to ignore queries for a AAAA RR,
-   causing a delay at the stub resolver to fall back to a query for an A
-   RR. This behavior may even cause a fatal timeout at the resolver.
-
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 4]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-5. Security Considerations
-
-   The CERT/CC pointed out that the response with NXDOMAIN described in
-   Section 4.1 can be used for a denial of service attack [2]. The same
-   argument applies to the case of "lame delegation" described in
-   Section 4.4 with a certain type of caching server.
-
-6. Acknowledgements
-
-   Erik Nordmark encouraged the authors to publish this document as an
-   Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary
-   version of this document. Pekka Savola carefully reviewed a previous
-   version and provided detailed comments.
-
-Informative References
-
-   [1]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
-        1034, November 1987.
-
-   [2]  The CERT Coordination Center, "Incorrect NXDOMAIN responses from
-        AAAA queries could cause denial-of-service conditions", March
-        2003, <http://www.kb.cert.org/vuls/id/714121>.
-
-
-Authors' Addresses
-
-   MORISHITA Orange Yasuhiro
-   Research and Development Department, Japan Registry Service Co.,Ltd.
-   Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi
-   Chiyoda-ku, Tokyo  101-0052
-   Japan
-
-   EMail: yasuhiro@jprs.co.jp
-
-
-   JINMEI Tatuya
-   Corporate Research & Development Center, Toshiba Corporation
-   1 Komukai Toshiba-cho, Saiwai-ku
-   Kawasaki-shi, Kanagawa  212-8582
-   Japan
-
-   EMail: jinmei@isl.rdc.toshiba.co.jp
-
-Appendix A. Live Examples
-
-   In this appendix, we show concrete implementations and domain names
-   that may cause problematic cases so that the behavior can be
-   reproduced in a practical environment. The examples are for
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 5]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-   informational purposes only, and the authors do not intend to accuse
-   any implementations or zone administrators.
-
-   The behavior described in Section 4.2 (return NOTIMP) can be found by
-   looking for a AAAA RR of www.css.vtext.com at 66.174.3.4.
-
-   The behavior described in Section 4.3 (broken responses) can be seen
-   by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an
-   alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior
-   can be found with the name "vip.alt.ihp.sony.co.jp," an alias of
-   "www.sony.co.jp," at 210.139.255.204.
-
-   The behavior described in Section 4.4 (lame delegation) can be found
-   by querying for a AAAA RR of "www.ual.com" at 209.87.113.4.
-
-   The behavior described in Section 4.5 (ignore queries) can be seen by
-   trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an
-   alias of "ad.jp.doubleclick.net," at 210.153.90.9.
-
-   Many authoritative server implementations show the expected behavior
-   described in Section 3. Some DNS load balancers reportedly have a
-   problematic behavior shown in Section 4, but the authors do not have
-   a concrete example. The CERT/CC provides a list of implementations
-   that behave as described in Section 4.1 [2].
-
-   The BIND9 caching server implementation is an example of the latter
-   cases described in Section 4.3 and Section 4.4, respectively. The
-   BIND8 caching server implementation is an example of the former case
-   described in Section 4.3. As for the issue shown in Section 4.4,
-   BIND8 caching servers prior to 8.3.5 show the behavior described as
-   the former case in this section. The versions 8.3.5 and later of
-   BIND8 caching server behave like the BIND9 caching server
-   implementation with this matter.
-
-   Regarding resolver implementations, the authors are only familiar
-   with the ones derived from the BIND implementation. These
-   implementations always fall back regardless of the RCODE; NXDOMAIN,
-   NOTIMP, or SERVFAIL. It even falls back when getting a broken
-   response. However, the behavior does not help the situation in the
-   NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also
-   causes a fatal error at the resolver side if the resolver is using
-   some older versions of BIND8 caching server.
-
-   The authors hear that a stub resolver routine implemented in some web
-   browsers interprets the broken response described in Section 4.3 as a
-   fatal error and does not fall back to A queries. However, we have not
-   confirmed this information.
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 6]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-Appendix B. Change History
-
-   Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are:
-
-   o  Made a separate appendix and moved live examples to appendix so
-      that we can remove them when this document is (ever) officially
-      published.
-
-   o  Revised some live examples based on the recent status.
-
-   o  Noted in introduction that the misbehavior is not specific to AAAA
-      and that this document still concentrates on the AAAA case.
-
-   o  Changed the section title of "delegation loop" to "lame
-      delegation" in order to reflect the essential point of the issue.
-      Wording on this matter was updated accordingly.
-
-   o  Updated the Acknowledgements list.
-
-   o  Changed the reference category from normative to informative (this
-      is an informational document after all).
-
-   o  Changed the draft name to an IETF dnsop working group document (as
-      agreed).
-
-   o  Applied several editorial fixes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 7]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004). 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 assignees.
-
-   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
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 8]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 9]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt
deleted file mode 100644
index f6ece8821034..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt
+++ /dev/null
@@ -1,485 +0,0 @@
-   DNSOP Working Group                               Paul Vixie, ISC (Ed.)
-   INTERNET-DRAFT                                         Akira Kato, WIDE
-   <draft-ietf-dnsop-respsize-01.txt>                           July, 2004
-
-
-                           DNS Response Size Issues
-
-
-   Status of this Memo
-      This document is an Internet-Draft and is subject to all provisions
-      of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-      author represents that any applicable patent or other IPR claims of
-      which we are aware have been or will be disclosed, and any of which
-      we become aware will be disclosed, in accordance with RFC 3668.
-
-
-      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 Notice
-
-
-      Copyright (C) The Internet Society (2003-2004).  All Rights Reserved.
-
-
-
-
-
-                                    Abstract
-
-
-      With a mandated default minimum maximum message size of 512 octets,
-      the DNS protocol presents some special problems for zones wishing to
-      expose a moderate or high number of authority servers (NS RRs).  This
-      document explains the operational issues caused by, or related to
-      this response size limit.
-
-
-
-
-
-
-   Expires December 2004                                           [Page 1]
-   INTERNET-DRAFT                  June 2003                       RESPSIZE
-
-
-
-   1 - Introduction and Overview
-
-
-   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
-   octets.  Even though this limitation was due to the required minimum UDP
-   reassembly limit for IPv4, it is a hard DNS protocol limit and is not
-   implicitly relaxed by changes in transport, for example to IPv6.
-
-
-   1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
-   responses by mutual agreement of the requestor and responder.  However,
-   deployment of EDNS0 cannot be expected to reach every Internet resolver
-   in the short or medium term.  The 512 octet message size limit remains
-   in practical effect at this time.
-
-
-   1.3. Since DNS responses include a copy of the request, the space
-   available for response data is somewhat less than the full 512 octets.
-   For negative responses, there is rarely a space constraint.  For
-   positive and delegation responses, though, every octet must be carefully
-   and sparingly allocated.  This document specifically addresses
-   delegation response sizes.
-
-
-   2 - Delegation Details
-
-
-   2.1. A delegation response will include the following elements:
-
-
-      Header Section: fixed length (12 octets)
-      Question Section: original query (name, class, type)
-      Answer Section: (empty)
-      Authority Section: NS RRset (nameserver names)
-      Additional Section: A and AAAA RRsets (nameserver addresses)
-
-
-   2.2. If the total response size would exceed 512 octets, and if the data
-   that would not fit was in the question, answer, or authority section,
-   then the TC bit will be set (indicating truncation) which may cause the
-   requestor to retry using TCP, depending on what information was present
-   and what was omitted.  If a retry using TCP is needed, the total cost of
-   the transaction is much higher.
-
-
-   2.3. RRsets are never sent partially, so if truncation occurs, entire
-   RRsets are omitted.  Note that the authority section consists of a
-   single RRset.  It is absolutely essential that truncation not occur in
-   the authority section.
-
-
-
-
-
-
-
-
-   Expires December 2004                                           [Page 2]
-   INTERNET-DRAFT                  June 2003                       RESPSIZE
-
-
-
-   2.4. DNS label compression allows a domain name to be instantiated only
-   once per DNS message, and then referenced with a two-octet "pointer"
-   from other locations in that same DNS message.  If all nameserver names
-   in a message are similar (for example, all ending in ".ROOT-
-   SERVERS.NET"), then more space will be available for uncompressable data
-   (such as nameserver addresses).
-
-
-   2.5. The query name can be as long as 255 characters of presentation
-   data, which can be up to 256 octets of network data.  In this worst case
-   scenario, the question section will be 260 octets in size, which would
-   leave only 240 octets for the authority and additional sections (after
-   deducting 12 octets for the fixed length header.)
-
-
-   2.6. Average and maximum question section sizes can be predicted by the
-   zone owner, since they will know what names actually exist, and can
-   measure which ones are queried for most often.  For cost and performance
-   reasons, the majority of requests should be satisfied without truncation
-   or TCP retry.
-
-
-   2.7. Requestors who deliberately send large queries to force truncation
-   are only increasing their own costs, and cannot effectively attack the
-   resources of an authority server since the requestor would have to retry
-   using TCP to complete the attack.  An attack that always used TCP would
-   have a lower cost.
-
-
-   2.8. The minimum useful number of address records is two, since with
-   only one address, the probability that it would refer to an unreachable
-   server is too high.  Truncation which occurs after two address records
-   have been added to the additional data section is therefore less
-   operationally significant than truncation which occurs earlier.
-
-
-   2.9. The best case is no truncation.  (This is because many requestors
-   will retry using TCP by reflex, without considering whether the omitted
-   data was actually necessary.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-   Expires December 2004                                           [Page 3]
-   INTERNET-DRAFT                  June 2003                       RESPSIZE
-
-
-
-   3 - Analysis
-
-
-   3.1. An instrumented protocol trace of a best case delegation response
-   follows.  Note that 13 servers are named, and 13 addresses are given.
-   This query was artificially designed to exactly reach the 512 octet
-   limit.
-
-
-      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
-      ;; QUERY SECTION:
-      ;;  [23456789.123456789.123456789.\
-           123456789.123456789.123456789.com A IN]        ;; @80
-
-
-      ;; AUTHORITY SECTION:
-      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
-      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
-      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
-      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
-      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
-      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
-      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
-      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
-      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
-      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
-      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
-      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
-      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
-
-
-      ;; ADDITIONAL SECTION:
-      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
-      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
-      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
-      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
-      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
-      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
-      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
-      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
-      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
-      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
-      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
-      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
-      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
-
-
-      ;; MSG SIZE  sent: 80  rcvd: 512
-
-
-
-
-
-
-   Expires December 2004                                           [Page 4]
-   INTERNET-DRAFT                  June 2003                       RESPSIZE
-
-
-
-   3.2. For longer query names, the number of address records supplied will
-   be lower.  Furthermore, it is only by using a common parent name (which
-   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
-   fit.  The following output from a response simulator demonstrates these
-   properties:
-
-
-      % perl respsize.pl 13 13 0
-        common name, average case: msg:303    nsaddr#13 (green)
-        common name,   worst case: msg:495    nsaddr# 1 (red)
-      uncommon name, average case: msg:457    nsaddr# 3 (orange)
-      uncommon name,   worst case: msg:649(*) nsaddr# 0 (red)
-      % perl respsize.pl 13 13 2
-        common name, average case: msg:303    nsaddr#11 (orange)
-        common name,   worst case: msg:495    nsaddr# 1 (red)
-      uncommon name, average case: msg:457    nsaddr# 2 (orange)
-      uncommon name,   worst case: msg:649(*) nsaddr# 0 (red)
-
-
-   (Note: The response simulator program is shown in Section 5.)
-
-
-   Here we use the term "green" if all address records could fit, or
-   "orange" if two or more could fit, or "red" if fewer than two could fit.
-   It's clear that without a common parent for nameserver names, much space
-   would be lost.
-
-
-   We're assuming an average query name size of 64 since that is the
-   typical average maximum size seen in trace data at the time of this
-   writing.  If Internationalized Domain Name (IDN) or any other technology
-   which results in larger query names be deployed significantly in advance
-   of EDNS, then more new measurements and new estimates will have to be
-   made.
-
-
-   4 - Conclusions
-
-
-   4.1. The current practice of giving all nameserver names a common parent
-   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
-   responses and allows for more nameservers to be enumerated than would
-   otherwise be possible.  (Note that in this case it is wise to serve the
-   common parent domain's zone from the same servers that are named within
-   it, in order to limit external dependencies when all your eggs are in a
-   single basket.)
-
-
-   4.2. Thirteen (13) seems to be the effective maximum number of
-   nameserver names usable traditional (non-extended) DNS, assuming a
-   common parent domain name, and assuming that additional-data truncation
-   is undesirable in the average case.
-
-
-
-
-   Expires December 2004                                           [Page 5]
-   INTERNET-DRAFT                  June 2003                       RESPSIZE
-
-
-
-   4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
-   prototypical delegation that currently contains thirteen (13) IPv4
-   nameserver addresses (A RRs) for thirteen (13) nameserver names under a
-   common parent, would not have a significant negative operational impact
-   on the domain name system.
-
-
-   5 - Source Code
-
-
-   #!/usr/bin/perl -w
-
-
-   $asize = 2+2+2+4+2+4;
-   $aaaasize = 2+2+2+4+2+16;
-   ($nns, $na, $naaaa) = @ARGV;
-   test("common", "average", common_name_average($nns),
-        $na, $naaaa);
-   test("common", "worst", common_name_worst($nns),
-        $na, $naaaa);
-   test("uncommon", "average", uncommon_name_average($nns),
-        $na, $naaaa);
-   test("uncommon", "worst", uncommon_name_worst($nns),
-        $na, $naaaa);
-   exit 0;
-
-
-   sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_;
-        my $nglue = numglue($msg, $na, $naaaa);
-        printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n",
-             $namekind, $casekind,
-             $msg, ($msg > 512) ? "(*)" : "   ",
-             $nglue, ($nglue == $na + $naaaa) ? "green"
-                  : ($nglue >= 2) ? "orange"
-                       : "red";
-   }
-
-
-   sub pnum { my ($num, $tot) = @_;
-        return sprintf "%3d%s",
-   }
-
-
-   sub numglue { my ($msg, $na, $naaaa) = @_;
-        my $space = ($msg > 512) ? 0 : (512 - $msg);
-        my $num = 0;
-
-
-        while ($space && ($na || $naaaa )) {
-             if ($na) {
-                  if ($space >= $asize) {
-                       $space -= $asize;
-
-
-
-
-   Expires December 2004                                           [Page 6]
-   INTERNET-DRAFT                  June 2003                       RESPSIZE
-
-
-
-                       $num++;
-                  }
-                  $na--;
-             }
-             if ($naaaa) {
-                  if ($space >= $aaaasize) {
-                       $space -= $aaaasize;
-                       $num++;
-                  }
-                  $naaaa--;
-             }
-        }
-        return $num;
-   }
-
-
-   sub msgsize { my ($qname, $nns, $nsns) = @_;
-        return  12 +                            # header
-                $qname+2+2 +                    # query
-                0 +                             # answer
-                $nns * (4+2+2+4+2+$nsns);       # authority
-   }
-
-
-   sub average_case { my ($nns, $nsns) = @_;
-        return msgsize(64, $nns, $nsns);
-   }
-
-
-   sub worst_case { my ($nns, $nsns) = @_;
-        return msgsize(256, $nns, $nsns);
-   }
-
-
-   sub common_name_average { my ($nns) = @_;
-        return 15 + average_case($nns, 2);
-   }
-
-
-   sub common_name_worst { my ($nns) = @_;
-        return 15 + worst_case($nns, 2);
-   }
-
-
-   sub uncommon_name_average { my ($nns) = @_;
-        return average_case($nns, 15);
-   }
-
-
-   sub uncommon_name_worst { my ($nns) = @_;
-        return worst_case($nns, 15);
-   }
-
-
-
-
-   Expires December 2004                                           [Page 7]
-   INTERNET-DRAFT                  June 2003                       RESPSIZE
-
-
-
-   Security Considerations
-
-
-   The recommendations contained in this document have no known security
-   implications.
-
-
-   IANA Considerations
-
-
-   This document does not call for changes or additions to any IANA
-   registry.
-
-
-   IPR Statement
-
-
-   Copyright (C) The Internet Society (2003-2004).  This document is
-   subject to the rights, licenses and restrictions contained in BCP 78,
-   and except as set forth therein, the authors retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
-   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-   Authors' Addresses
-
-
-   Paul Vixie
-      950 Charter Street
-      Redwood City, CA 94063
-      +1 650 423 1301
-      vixie@isc.org
-
-
-   Akira Kato
-      University of Tokyo, Information Technology Center
-      2-11-16 Yayoi Bunkyo
-      Tokyo 113-8658, JAPAN
-      +81 3 5841 2750
-      kato@wide.ad.jp
-
-
-
-
-
-
-
-
-
-
-   Expires December 2004                                           [Page 8] 
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt
deleted file mode 100644
index b593c57179e3..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-Network Working Group                                           S. Woolf
-Internet-Draft                         Internet Systems Consortium, Inc.
-Expires: January 16, 2005                                      D. Conrad
-                                                           Nominum, Inc.
-                                                           July 18, 2004
-
-
-               Identifying an Authoritative Name `Server
-                      draft-ietf-dnsop-serverid-02
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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.
-
-   This Internet-Draft will expire on January 16, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.  A standardized mechanism to
-   determine the identity of a name server responding to a particular
-   query would be useful, particularly as a diagnostic aid.  Existing ad
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 1]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-   hoc mechanisms for addressing this concern are not adequate.  This
-   document attempts to describe the common ad hoc solution to this
-   problem, including its advantages and disadvantasges, and to
-   characterize an improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 2]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-1.  Introduction
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.  A standardized mechanism to
-   determine the identity of a name server responding to a particular
-   query would be useful, particularly as a diagnostic aid.
-
-   Unfortunately, existing ad-hoc mechanisms for providing such
-   identification have some shortcomings, not the least of which is the
-   lack of prior analysis of exactly how such a mechanism should be
-   designed and deployed.  This document describes the existing
-   convention used in one widely deployed implementation of the DNS
-   protocol and discusses requirements for an improved solution to the
-   problem.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 3]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-2.  Rationale
-
-   Identifying which name server is responding to queries is often
-   useful, particularly in attempting to diagnose name server
-   difficulties.  However, relying on the IP address of the name server
-   has become more problematic due the deployment of various load
-   balancing solutions, including the use of shared unicast addresses as
-   documented in [RFC3258].
-
-   An unfortunate side effect of these load balancing solutions is that
-   traditional methods of determining which server is responding can be
-   unreliable.  Specifically, non-DNS methods such as ICMP ping, TCP
-   connections, or non-DNS UDP packets (e.g., as generated by tools such
-   as "traceroute"), etc., can end up going to a different server than
-   that which receives the DNS queries.
-
-   The widespread use of the existing convention suggests a need for a
-   documented, interoperable means of querying the identity of a
-   nameserver that may be part of an anycast or load-balancing cluster.
-   At the same time, however, it also has some drawbacks that argue
-   against standardizing it as it's been practiced so far.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 4]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-3.  Existing Conventions
-
-   Recent versions of the commonly deployed Berkeley Internet Name
-   Domain implementation of the DNS protocol suite from the Internet
-   Software Consortium [BIND] support a way of identifying a particular
-   server via the use of a standard, if somewhat unusual, DNS query.
-   Specifically, a query to a late model BIND server for a TXT resource
-   record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
-   return a string that can be configured by the name server
-   administrator to provide a unique identifier for the responding
-   server (defaulting to the value of a gethostname() call).  This
-   mechanism, which is an extension of the BIND convention of using
-   CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
-   version information, has been copied by several name server vendors.
-
-   For reference, the other well-known name used by recent versions of
-   BIND within the CHAOS class "BIND." domain is "VERSION.BIND."  A
-   query for a TXT RR for this name will return an administratively re-
-   definable string which defaults to the version of the server
-   responding.
-
-3.1  Advantages
-
-   There are several valuable attributes to this mechanism, which
-   account for its usefulness.
-   1.  This mechanism is within the DNS protocol itself.  An
-       identification mechanism that relies on the DNS protocol is more
-       likely to be successful (although not guaranteed) in going to the
-       same machine as a "normal" DNS query.
-   2.  It is simple to configure.  An administrator can easily turn on
-       this feature and control the results of the relevant query.
-   3.  It allows the administrator complete control of what information
-       is given out in the response, minimizing passive leakage of
-       implementation or configuration details.  Such details are often
-       considered sensitive by infrastructure operators.
-
-3.2  Disadvantages
-
-   At the same time, there are some forbidding drawbacks to the
-   VERSION.BIND mechanism that argue against standardizing it as it
-   currently operates.
-   1.  It requires an additional query to correlate between the answer
-       to a DNS query under normal conditions and the supposed identity
-       of the server receiving the query.  There are a number of
-       situations in which this simply isn't reliable.
-   2.  It reserves an entire class in the DNS (CHAOS) for what amounts
-       to one zone.  While CHAOS class is defined in [RFC1034] and
-       [RFC1035], it's not clear that supporting it solely for this
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 5]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-       purpose is a good use of the namespace or of implementation
-       effort.
-   3.  It is implementation specific.  BIND is one DNS implementation.
-       At the time of this writing, it is probably the most prevalent,
-       for authoritative servers anyway.  This does not justify
-       standardizing on its ad hoc solution to a problem shared across
-       many operators and implementors.
-
-   The first of the listed disadvantages is technically the most
-   serious.  It argues for an attempt to design a good answer to the
-   problem that "I need to know what nameserver is answering my
-   queries", not simply a convenient one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 6]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-4.  Characteristics of an Implementation Neutral Convention
-
-   The discussion above of advantages and disadvantages to the
-   HOSTNAME.BIND mechanism suggest some requirements for a better
-   solution to the server identification problem.  These are summarized
-   here as guidelines for any effort to provide appropriate protocol
-   extensions:
-   1.  The mechanism adopted MUST be in-band for the DNS protocol.  That
-       is, it needs to allow the query for the server's identifying
-       information to be part of a normal, operational query.  It SHOULD
-       also permit a separate, dedicated query for the server's
-       identifying information.
-   2.  The new mechanism should not require dedicated namespaces or
-       other reserved values outside of the existing protocol mechanisms
-       for these, i.e.  the OPT pseudo-RR.
-   3.  Support for the identification functionality SHOULD be easy to
-       implement and easy to enable.  It MUST be easy to disable and
-       SHOULD lend itself to access controls on who can query for it.
-   4.  It should be possible to return a unique identifier for a server
-       without requiring the exposure of information that may be
-       non-public and considered sensitive by the operator, such as a
-       hostname or unicast IP address maintained for administrative
-       purposes.
-   5.  The identification mechanism SHOULD NOT be
-       implementation-specific.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 7]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-5.  IANA Considerations
-
-   This document proposes no specific IANA action.  Protocol extensions,
-   if any, to meet the requirements described are out of scope for this
-   document.  Should such extensions be specified and adopted by normal
-   IETF process, the specification will include appropriate guidance to
-   IANA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 8]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-6.  Security Considerations
-
-   Providing identifying information as to which server is responding
-   can be seen as information leakage and thus a security risk.  This
-   motivates the suggestion above that a new mechanism for server
-   identification allow the administrator to disable the functionality
-   altogether or partially restrict availability of the data.  It also
-   suggests that the serverid data should not be readily correlated with
-   a hostname or unicast IP address that may be considered private to
-   the nameserver operator's management infrastructure.
-
-   Propagation of protocol or service meta-data can sometimes expose the
-   application to denial of service or other attack.  As DNS is a
-   critically important infrastructure service for the production
-   Internet, extra care needs to be taken against this risk for
-   designers, implementors, and operators of a new mechanism for server
-   identification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005                [Page 9]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-7.  Acknowledgements
-
-   The technique for host identification documented here was initially
-   implemented by Paul Vixie of the Internet Software Consortium in the
-   Berkeley Internet Name Daemon package.  Comments and questions on
-   earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
-   Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
-   ICANN Root Server System Advisory Committee.  The newest draft takes
-   a significantly different direction from previous versions, owing to
-   discussion among contributors to the DNSOP working group and others,
-   particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler,
-   and Rob Austein.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005               [Page 10]
-
-Internet-Draft    Identifying an Authoritative Name `Server    July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Woolf & Conrad          Expires January 16, 2005               [Page 11]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt b/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt
deleted file mode 100644
index 423a119f39f8..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt
+++ /dev/null
@@ -1,951 +0,0 @@
-
-
-IPSECKEY WG                                                M. Richardson
-Internet-Draft                                                       SSW
-|Expires: August 1, 2004                                   February 2004
-
-
-           A Method for Storing IPsec Keying Material in DNS
-|                    draft-ietf-ipseckey-rr-09.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.
-
-|  This Internet-Draft will expire on August 1, 2004.
-
-Copyright Notice
-
-|  Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-|  This document describes a new resource record for Domain Name System
-|  (DNS).  This record may be used to store public keys for use in IP
-|  security (IPsec) systems.  The record also includes provisions for
-|  indicating what system should be contacted when establishing an IPsec
-|  tunnel with the entity in question.
-
-   This record replaces the functionality of the sub-type #1 of the KEY
-   Resource Record, which has been obsoleted by RFC3445.
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 1]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-|  1.2 Use of reverse (in-addr.arpa) map  . . . . . . . . . . . . . .  3
-|  1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . .  3
-|  2.  Storage formats  . . . . . . . . . . . . . . . . . . . . . . .  5
-|  2.1 IPSECKEY RDATA format  . . . . . . . . . . . . . . . . . . . .  5
-|  2.2 RDATA format - precedence  . . . . . . . . . . . . . . . . . .  5
-|  2.3 RDATA format - gateway type  . . . . . . . . . . . . . . . . .  5
-|  2.4 RDATA format - algorithm type  . . . . . . . . . . . . . . . .  6
-|  2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . .  6
-|  2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . .  6
-|  3.  Presentation formats . . . . . . . . . . . . . . . . . . . . .  8
-|  3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . .  8
-|  3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-|  4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-|  4.1 Active attacks against unsecured IPSECKEY resource records . . 10
-|  5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-|  6.  Intellectual Property Claims . . . . . . . . . . . . . . . . . 13
-|  7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
-|      Normative references . . . . . . . . . . . . . . . . . . . . . 15
-|      Non-normative references . . . . . . . . . . . . . . . . . . . 16
-|      Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
-|      Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 2]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-1. Introduction
-
-   It postulated that there is an end system desiring to establish an
-   IPsec tunnel with some remote entity on the network.  This system,
-   having only a DNS name of some kind (forward, reverse or even
-   user@FQDN) needs a public key to authenticate the remote entity.  It
-   also desires some guidance about whether to contact the entity
-   directly, or whether to contact another entity, as the gateway to
-   that desired entity.
-
-   The IPSECKEY RR provides a storage mechanism for such items as the
-   public key, and the gateway information.
-
-   The type number for the IPSECKEY RR is TBD.
-
-1.1 Overview
-
-   The IPSECKEY resource record (RR) is used to publish a public key
-   that is to be associated with a Domain Name System (DNS) name for use
-   with the IPsec protocol suite.  This can be the  public key of a
-   host, network, or application (in the case of per-port keying).
-
-   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 RFC2119 [7].
-
-|1.2 Use of reverse (in-addr.arpa) map
-
-|  Often a security gateway will only have access to the IP address to
-|  which communication is desired.  It will not know the forward name.
-|  As such, it will frequently be the case that the IP address will be
-|  used an index into the reverse map.
-
-|  The lookup is done in the usual fashion as for PTR records.  The IP
-|  address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
-|  under the .arpa.  zone.  Any CNAMEs or DNAMEs found SHOULD be
-|  followed.
-
-|  Note: even when the IPsec function is the end-host, often only the
-|  application will know the forward name used.  While the case where
-|  the application knows the forward name is common, the user could
-|  easily have typed in a literal IP address.  This storage mechanism
-|  does not preclude using the forward name when it is available, but
-|  does not require it.
-
-|1.3 Usage Criteria
-
-   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 3]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-   unless some other means of authenticating the IPSECKEY resource
-   record is available.
-
-   It is expected that there will often be multiple IPSECKEY resource
-   records at the same name.  This will be due to the presence of
-   multiple gateways and the need to rollover keys.
-
-   This resource record is class independent.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 4]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-2. Storage formats
-
-2.1 IPSECKEY RDATA format
-
-   The RDATA for an IPSECKEY RR consists of a precedence value, a
-   gateway type, a public key, algorithm type, and an optional gateway
-   address.
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |  precedence   | gateway type  |  algorithm  |     gateway     |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
-      ~                            gateway                            ~
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               /
-      /                          public key                           /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-
-2.2 RDATA format - precedence
-
-   This is an 8-bit precedence for this record.  This is interpreted in
-   the same way as the PREFERENCE field described in section 3.3.9 of
-   RFC1035 [2].
-
-   Gateways listed in IPSECKEY records with  lower precedence are to be
-   attempted first.  Where there is a tie in precedence, the order
-   should be non-deterministic.
-
-2.3 RDATA format - gateway type
-
-   The gateway type field indicates the format of the information that
-   is stored in the gateway field.
-
-   The following values are defined:
-
-   0  No gateway is present
-
-   1  A 4-byte IPv4 address is present
-
-   2  A 16-byte IPv6 address is present
-
-   3  A wire-encoded domain name is present.  The wire-encoded format is
-      self-describing, so the length is implicit.  The domain name MUST
-      NOT be compressed.  (see section 3.3 of RFC1035 [2]).
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 5]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-2.4 RDATA format - algorithm type
-
-   The algorithm type field identifies the public key's cryptographic
-   algorithm and determines the format of the public key field.
-
-   A value of 0 indicates that no key is present.
-
-   The following values are defined:
-
-   1  A DSA key is present, in the format defined in RFC2536 [10]
-
-   2  A RSA key is present, in the format defined in RFC3110 [11]
-
-
-2.5 RDATA format - gateway
-
-   The gateway field indicates a gateway to which an IPsec tunnel may be
-   created in order to reach the entity named by this resource record.
-
-   There are three formats:
-
-   A 32-bit IPv4 address is present in the gateway field.  The data
-   portion is an IPv4 address as described in section 3.4.1 of RFC1035
-   [2].  This is a 32-bit number in network byte order.
-
-   A 128-bit IPv6 address is present in the gateway field.  The data
-   portion is an IPv6 address as described in section 2.2 of RFC3596
-   [13].  This is a 128-bit number in network byte order.
-
-   The gateway field is a normal wire-encoded domain name, as described
-   in section 3.3 of RFC1035 [2].  Compression MUST NOT be used.
-
-2.6 RDATA format - public keys
-
-   Both of the public key types defined in this document (RSA and DSA)
-   inherit their public key formats from the corresponding KEY RR
-   formats.  Specifically, the public key field contains the algorithm-
-   specific portion of the KEY RR RDATA, which is all of the KEY RR DATA
-   after the first four octets.  This is the same portion of the KEY RR
-   that must be specified by documents that define a DNSSEC algorithm.
-   Those documents also specify a message digest to be used for
-   generation of SIG RRs; that specification is not relevant for
-   IPSECKEY RR.
-
-   Future algorithms, if they are to be used by both DNSSEC (in the KEY
-   RR) and IPSECKEY, are likely to use the same public key encodings in
-   both records.  Unless otherwise specified, the IPSECKEY public key
-   field will contain the algorithm-specific portion of the KEY RR RDATA
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 6]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-   for the corresponding algorithm.  The algorithm must still be
-   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
-   (which might be different than the DNSSEC algorithm number) must be
-   assigned to it.
-
-   The DSA key format is defined in RFC2536 [10]
-
-   The RSA key format is defined in RFC3110 [11], with the following
-   changes:
-
-   The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
-   modulus to 2552 bits in length.  RFC3110 extended that limit to 4096
-   bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no length limit on
-   RSA public keys, other than the 65535 octet limit imposed by the two-
-   octet length encoding.  This length extension is applicable only to
-   IPSECKEY and not to KEY RRs.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 7]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-3. Presentation formats
-
-3.1 Representation of IPSECKEY RRs
-
-   IPSECKEY RRs may appear in a zone data master file.  The precedence,
-   gateway type and algorithm and gateway fields are REQUIRED.  The
-   base64 encoded public key block is OPTIONAL; if not present, then the
-   public key field of the resource record MUST be construed as being
-   zero octets in length.
-
-   The algorithm field is an unsigned integer.  No mnemonics are
-   defined.
-
-   If no gateway is to be indicated, then the gateway type field MUST be
-   zero, and the gateway field MUST be "."
-
-   The Public Key field is represented as a Base64 encoding of the
-   Public Key.  Whitespace is allowed within the Base64 text.  For a
-   definition of Base64 encoding, see RFC3548 [6] Section 5.2.
-
-   The general presentation for the record as as follows:
-
-   IN     IPSECKEY ( precedence gateway-type algorithm
-                     gateway base64-encoded-public-key )
-
-
-3.2 Examples
-
-   An example of a node 192.0.2.38 that will accept IPsec tunnels on its
-   own behalf.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
-                    192.0.2.38
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 192.0.2.38 that has published its key only.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
-                    .
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 192.0.2.38 that has delegated authority to the
-   node 192.0.2.3.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
-                    192.0.2.3
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 8]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-   An example of a node, 192.0.1.38 that has delegated authority to the
-   node with the identity "mygateway.example.com".
-
-   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
-                    mygateway.example.com.
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
-   delegated authority to the node 2001:0DB8:c000:0200:2::1
-
-   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
-   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
-                    2001:0DB8:0:8002::2000:1
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 9]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-4. Security Considerations
-
-   This entire memo pertains to the provision of public keying material
-   for use by key management protocols such as ISAKMP/IKE (RFC2407) [8].
-
-   The IPSECKEY resource record contains information that SHOULD be
-   communicated to the end client in an integral fashion - i.e.  free
-   from modification.  The form of this channel is up to the consumer of
-   the data - there must be a trust relationship between the end
-   consumer of this resource record and the server.  This relationship
-   may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
-   another secure source, a secure local channel on the host, or some
-   combination of the above.
-
-   The keying material provided by the IPSECKEY resource record is not
-   sensitive to passive attacks.  The keying material may be freely
-   disclosed to any party without any impact on the security properties
-   of the resulting IPsec session: IPsec and IKE provide for defense
-   against both active and passive attacks.
-
-   Any derivative standard that makes use of this resource record MUST
-   carefully document their trust model, and why the trust model of
-   DNSSEC is appropriate, if that is the secure channel used.
-
-4.1 Active attacks against unsecured IPSECKEY resource records
-
-   This section deals with active attacks against the DNS.  These
-   attacks require that DNS requests and responses be intercepted and
-   changed.  DNSSEC is designed to defend against attacks of this kind.
-
-   The first kind of active attack is when the attacker replaces the
-   keying material with either a key under its control or with garbage.
-
-   If the attacker is not able to mount a subsequent man-in-the-middle
-   attack on the IKE negotiation after replacing the public key, then
-   this will result in a denial of service, as the authenticator used by
-   IKE would fail.
-
-   If the attacker is able to both to mount active attacks against DNS
-   and is also in a position to perform a man-in-the-middle attack on
-   IKE and IPsec negotiations, then the attacker will be in a position
-   to compromise the resulting IPsec channel.  Note that an attacker
-   must be able to perform active DNS attacks on both sides of the IKE
-   negotiation in order for this to succeed.
-
-   The second kind of active attack is one in which the attacker
-   replaces the the gateway address to point to a node under the
-   attacker's control.  The attacker can then either replace the public
-
-
-
-|Richardson              Expires August 1, 2004                [Page 10]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-   key or remove it, thus providing an IPSECKEY record of its own to
-   match the gateway address.
-
-   This later form creates a simple man-in-the-middle since the attacker
-   can then create a second tunnel to the real destination.  Note that,
-   as before, this requires that the attacker also mount an active
-   attack against the responder.
-
-   Note that the man-in-the-middle can not just forward cleartext
-   packets to the original destination.  While the destination may be
-   willing to speak in the clear, replying to the original sender, the
-   sender will have already created a policy expecting ciphertext.
-   Thus, the attacker will need to intercept traffic from both sides.
-   In some cases, the attacker may be able to accomplish the full
-   intercept by use of Network Addresss/Port Translation (NAT/NAPT)
-   technology.
-
-|  Note that risk of a man-in-the-middle attack mediated by the IPSECKEY
-|  RR only applies to cases where the gateway field of the IPSECKEY RR
-|  indicates a different entity than the owner name of the IPSECKEY RR.
-
-|  An active attack on the DNS that caused the wrong IP address to be
-|  retrieved (via forged A RR), and therefore the wrong QNAME to be
-|  queried would also result in a man-in-the-middle attack.  This
-|  situation exists independantly of whether or not the IPSECKEY RR is
-|  used.
-
-|  In cases where the end-to-end integrity of the IPSECKEY RR is
-|  suspect, the end client MUST restrict its use of the IPSECKEY RR to
-|  cases where the RR owner name matches the content of the gateway
-|  field.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 11]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-5. IANA Considerations
-
-   This document updates the IANA Registry for DNS Resource Record Types
-   by assigning type X to the IPSECKEY record.
-
-   This document creates two new IANA registries, both specific to the
-   IPSECKEY Resource Record:
-
-   This document creates an IANA registry for the algorithm type field.
-
-   Values 0, 1 and 2 are defined in Section 2.4.  Algorithm numbers 3
-   through 255 can be assigned by IETF Consensus (see RFC2434 [5]).
-
-   This document creates an IANA registry for the gateway type field.
-
-   Values 0, 1, 2 and 3 are defined in Section 2.3.  Gateway type
-   numbers 4 through 255 can be assigned by Standards Action (see
-   RFC2434 [5]).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 12]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-6. Intellectual Property Claims
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 13]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-7. Acknowledgments
-
-   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
-   Austein, and Olafur Gurmundsson who reviewed this document carefully.
-   Additional thanks to Olafur Gurmundsson for a reference
-   implementation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 14]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-Normative references
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
-        9, RFC 2026, October 1996.
-
-   [4]  Eastlake, D. and C. Kaufman, "Domain Name System Security
-        Extensions", RFC 2065, January 1997.
-
-   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-        RFC 3548, July 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 15]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-Non-normative references
-
-   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]   Piper, D., "The Internet IP Security Domain of Interpretation
-         for ISAKMP", RFC 2407, November 1998.
-
-   [9]   Eastlake, D., "Domain Name System Security Extensions", RFC
-         2535, March 1999.
-
-   [10]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-         (DNS)", RFC 2536, March 1999.
-
-   [11]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
-         System (DNS)", RFC 3110, May 2001.
-
-   [12]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
-         Record (RR)", RFC 3445, December 2002.
-
-   [13]  Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
-         Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-
-Author's Address
-
-   Michael C. Richardson
-   Sandelman Software Works
-   470 Dawson Avenue
-   Ottawa, ON  K1Z 5V7
-   CA
-
-   EMail: mcr@sandelman.ottawa.on.ca
-   URI:   http://www.sandelman.ottawa.on.ca/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 16]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-Full Copyright Statement
-
-|  Copyright (C) The Internet Society (2004).  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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 17]
diff --git a/contrib/bind9/doc/misc/options b/contrib/bind9/doc/misc/options
index c746e498f363..01546b72644c 100644
--- a/contrib/bind9/doc/misc/options
+++ b/contrib/bind9/doc/misc/options
@@ -49,6 +49,7 @@ options {
         use-id-pool <boolean>; // obsolete
         use-ixfr <boolean>;
         version ( <quoted_string> | none );
+        flush-zones-on-shutdown <boolean>;
         allow-recursion { <address_match_element>; ... };
         allow-v6-synthesis { <address_match_element>; ... }; // obsolete
         sortlist { <address_match_element>; ... };
diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index
index fb72ccc314de..5c588db93016 100644
--- a/contrib/bind9/doc/rfc/index
+++ b/contrib/bind9/doc/rfc/index
@@ -76,9 +76,9 @@
 	 Addresses in the Domain Name System (DNS)
 3364:	Tradeoffs in Domain Name System (DNS) Support
 	 for Internet Protocol version 6 (IPv6)
-3390:	Internationalizing Domain Names In Applications (IDNA)
 3425:	Obsoleting IQUERY
 3445:	Limiting the Scope of the KEY Resource Record (RR)
+3490:	Internationalizing Domain Names In Applications (IDNA)
 3491:	Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)
 3492:	Punycode:A Bootstring encoding of Unicode for
 	  Internationalized Domain Names in Applications (IDNA)
@@ -90,5 +90,14 @@
 	  Secret Key Transaction Authentication for DNS (GSS-TSIG)
 3655:	Redefinition of DNS Authenticated Data (AD) bit
 3658:	Delegation Signer (DS) Resource Record (RR)
+3757:	Domain Name System KEY (DNSKEY) Resource Record (RR)
+	  Secure Entry Point (SEP) Flag
 3833:	Threat Analysis of the Domain Name System (DNS)
 3845:	DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
+3901:	DNS IPv6 Transport Operational Guidelines
+4025:	A Method for Storing IPsec Keying Material in DNS
+4033:	DNS Security Introduction and Requirements
+4034:	Resource Records for the DNS Security Extensions
+4035:	Protocol Modifications for the DNS Security Extensions
+4074:	Common Misbehavior Against DNS Queries for IPv6 Addresses
+4159:	Deprecation of "ip6.int"
diff --git a/contrib/bind9/lib/bind/Makefile.in b/contrib/bind9/lib/bind/Makefile.in
index 0a2a1a0fac78..5c34c1a1842e 100644
--- a/contrib/bind9/lib/bind/Makefile.in
+++ b/contrib/bind9/lib/bind/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001-2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.12.2.5.2.7 2004/12/09 04:07:14 marka Exp $
+# $Id: Makefile.in,v 1.12.2.5.2.9 2005/07/29 00:13:08 marka Exp $
 
 srcdir =        @srcdir@
 VPATH =         @srcdir@
@@ -85,10 +85,11 @@ NAMESEROBJS= nameser/ns_date.@O@ nameser/ns_name.@O@ nameser/ns_netint.@O@ \
 	nameser/ns_parse.@O@ nameser/ns_print.@O@  nameser/ns_samedomain.@O@ \
 	nameser/ns_sign.@O@ nameser/ns_ttl.@O@ nameser/ns_verify.@O@
 
-RESOLVOBJS= resolv/herror.@O@ resolv/res_comp.@O@ resolv/res_data.@O@ \
-	resolv/res_debug.@O@ resolv/res_findzonecut.@O@ resolv/res_init.@O@ \
-	resolv/res_mkquery.@O@ resolv/res_mkupdate.@O@ resolv/res_query.@O@ \
-	resolv/res_send.@O@ resolv/res_sendsigned.@O@ resolv/res_update.@O@
+RESOLVOBJS= resolv/herror.@O@ resolv/mtctxres.@O@ resolv/res_comp.@O@ \
+	resolv/res_data.@O@ resolv/res_debug.@O@ resolv/res_findzonecut.@O@ \
+	resolv/res_init.@O@ resolv/res_mkquery.@O@ resolv/res_mkupdate.@O@ \
+	resolv/res_query.@O@ resolv/res_send.@O@ resolv/res_sendsigned.@O@ \
+	resolv/res_update.@O@
 
 SUBDIRS = bsd dst include inet irs isc nameser resolv @PORT_INCLUDE@
 
diff --git a/contrib/bind9/lib/bind/api b/contrib/bind9/lib/bind/api
index acc853bbf2ac..dcc846ea5275 100644
--- a/contrib/bind9/lib/bind/api
+++ b/contrib/bind9/lib/bind/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 3
-LIBREVISION = 8
+LIBINTERFACE = 4
+LIBREVISION = 2
 LIBAGE = 0
diff --git a/contrib/bind9/lib/bind/config.h.in b/contrib/bind9/lib/bind/config.h.in
index 6c86b4deed20..82a1560d1fd8 100644
--- a/contrib/bind9/lib/bind/config.h.in
+++ b/contrib/bind9/lib/bind/config.h.in
@@ -1,6 +1,8 @@
 #undef _SOCKADDR_LEN
 #undef HAVE_FCNTL_H
 #undef HAVE_PATHS_H
+#undef HAVE_INTTYPES_H
+#undef HAVE_STROPTS_H
 #undef HAVE_SYS_TIMERS_H
 #undef SYS_CDEFS_H
 #undef _POSIX_PTHREAD_SEMANTICS
@@ -35,6 +37,8 @@
 
 #undef HAS_PW_CLASS
 
+#undef uintptr_t
+
 /* Shut up warnings about sputaux in stdio.h on BSD/OS pre-4.1 */ 
 #undef SHUTUP_SPUTAUX
 #ifdef SHUTUP_SPUTAUX
diff --git a/contrib/bind9/lib/bind/configure b/contrib/bind9/lib/bind/configure
index 1baa91eeafde..8f12621650ba 100755
--- a/contrib/bind9/lib/bind/configure
+++ b/contrib/bind9/lib/bind/configure
@@ -1,5 +1,5 @@
 #! /bin/sh
-# From configure.in Revision: 1.83.2.5.2.10 .
+# From configure.in Revision: 1.83.2.5.2.22 .
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.59.
 #
@@ -464,7 +464,7 @@ ac_includes_default="\
 # include <unistd.h>
 #endif"
 
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_NEEDSYSSELECTH WANT_IRS_GR WANT_IRS_GR_OBJS WANT_IRS_PW WANT_IRS_PW_OBJS WANT_IRS_NIS WANT_IRS_NIS_OBJS WANT_IRS_NISGR_OBJS WANT_IRS_NISPW_OBJS WANT_IRS_DBPW_OBJS ALWAYS_DEFINES DO_PTHREADS WANT_IRS_THREADSGR_OBJS WANT_IRS_THREADSPW_OBJS WANT_IRS_THREADS_OBJS WANT_THREADS_OBJS USE_IFNAMELINKID ISC_THREAD_DIR DAEMON_OBJS NEED_DAEMON STRSEP_OBJS NEED_STRSEP NEED_STRERROR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK HAS_INET6_STRUCTS ISC_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H HAS_IN_ADDR6 NEED_IN6ADDR_ANY ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C HAVE_SIN6_SCOPE_ID HAVE_SOCKADDR_STORAGE ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON HAVE_SA_LEN HAVE_MINIMUM_IFREQ BSD_COMP SOLARIS_BITTYPES USE_FIONBIO_IOCTL PORT_DIR PORT_INCLUDE ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO NEED_PSELECT NEED_GETTIMEOFDAY HAVE_STRNDUP ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS USE_SYSERROR_LIST ISC_PLATFORM_QUADFORMAT ISC_SOCKLEN_T GETGROUPLIST_ARGS NET_R_ARGS NET_R_BAD NET_R_COPY NET_R_COPY_ARGS NET_R_OK NET_R_SETANSWER NET_R_RETURN GETNETBYADDR_ADDR_T NETENT_DATA NET_R_ENT_ARGS NET_R_SET_RESULT NET_R_SET_RETURN NET_R_END_RESULT NET_R_END_RETURN GROUP_R_ARGS GROUP_R_BAD GROUP_R_OK GROUP_R_RETURN GROUP_R_END_RESULT GROUP_R_END_RETURN GROUP_R_ENT_ARGS GROUP_R_SET_RESULT GROUP_R_SET_RETURN HOST_R_ARGS HOST_R_BAD HOST_R_COPY HOST_R_COPY_ARGS HOST_R_ERRNO HOST_R_OK HOST_R_RETURN HOST_R_SETANSWER HOSTENT_DATA HOST_R_END_RESULT HOST_R_END_RETURN HOST_R_ENT_ARGS HOST_R_SET_RESULT HOST_R_SET_RETURN SETPWENT_VOID SETGRENT_VOID NGR_R_ARGS NGR_R_BAD NGR_R_COPY NGR_R_COPY_ARGS NGR_R_OK NGR_R_RETURN NGR_R_PRIVATE NGR_R_END_RESULT NGR_R_END_RETURN NGR_R_ENT_ARGS NGR_R_SET_RESULT NGR_R_SET_RETURN PROTO_R_ARGS PROTO_R_BAD PROTO_R_COPY PROTO_R_COPY_ARGS PROTO_R_OK PROTO_R_SETANSWER PROTO_R_RETURN PROTO_R_END_RESULT PROTO_R_END_RETURN PROTO_R_ENT_ARGS PROTO_R_SET_RESULT PROTO_R_SET_RETURN PASS_R_ARGS PASS_R_BAD PASS_R_COPY PASS_R_COPY_ARGS PASS_R_OK PASS_R_RETURN PASS_R_END_RESULT PASS_R_END_RETURN PASS_R_ENT_ARGS PASS_R_SET_RESULT PASS_R_SET_RETURN SERV_R_ARGS SERV_R_BAD SERV_R_COPY SERV_R_COPY_ARGS SERV_R_OK SERV_R_SETANSWER SERV_R_RETURN SERV_R_END_RESULT SERV_R_END_RETURN SERV_R_ENT_ARGS SERV_R_SET_RESULT SERV_R_SET_RETURN SETNETGRENT_ARGS INNETGR_ARGS BIND9_TOP_BUILDDIR BIND9_VERSION LIBOBJS LTLIBOBJS'
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_NEEDSYSSELECTH WANT_IRS_GR WANT_IRS_GR_OBJS WANT_IRS_PW WANT_IRS_PW_OBJS WANT_IRS_NIS WANT_IRS_NIS_OBJS WANT_IRS_NISGR_OBJS WANT_IRS_NISPW_OBJS WANT_IRS_DBPW_OBJS ALWAYS_DEFINES DO_PTHREADS WANT_IRS_THREADSGR_OBJS WANT_IRS_THREADSPW_OBJS WANT_IRS_THREADS_OBJS WANT_THREADS_OBJS USE_IFNAMELINKID ISC_THREAD_DIR DAEMON_OBJS NEED_DAEMON STRSEP_OBJS NEED_STRSEP NEED_STRERROR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK HAS_INET6_STRUCTS ISC_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H HAS_IN_ADDR6 NEED_IN6ADDR_ANY ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C HAVE_SIN6_SCOPE_ID HAVE_SOCKADDR_STORAGE ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON HAVE_SA_LEN HAVE_MINIMUM_IFREQ BSD_COMP SOLARIS_BITTYPES USE_FIONBIO_IOCTL PORT_NONBLOCK PORT_DIR USE_POLL HAVE_MD5 SOLARIS2 PORT_INCLUDE ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO NEED_PSELECT NEED_GETTIMEOFDAY HAVE_STRNDUP ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS USE_SYSERROR_LIST ISC_PLATFORM_QUADFORMAT ISC_SOCKLEN_T GETGROUPLIST_ARGS NET_R_ARGS NET_R_BAD NET_R_COPY NET_R_COPY_ARGS NET_R_OK NET_R_SETANSWER NET_R_RETURN GETNETBYADDR_ADDR_T NETENT_DATA NET_R_ENT_ARGS NET_R_SET_RESULT NET_R_SET_RETURN NET_R_END_RESULT NET_R_END_RETURN GROUP_R_ARGS GROUP_R_BAD GROUP_R_OK GROUP_R_RETURN GROUP_R_END_RESULT GROUP_R_END_RETURN GROUP_R_ENT_ARGS GROUP_R_SET_RESULT GROUP_R_SET_RETURN HOST_R_ARGS HOST_R_BAD HOST_R_COPY HOST_R_COPY_ARGS HOST_R_ERRNO HOST_R_OK HOST_R_RETURN HOST_R_SETANSWER HOSTENT_DATA HOST_R_END_RESULT HOST_R_END_RETURN HOST_R_ENT_ARGS HOST_R_SET_RESULT HOST_R_SET_RETURN SETPWENT_VOID SETGRENT_VOID NGR_R_ARGS NGR_R_BAD NGR_R_COPY NGR_R_COPY_ARGS NGR_R_OK NGR_R_RETURN NGR_R_PRIVATE NGR_R_END_RESULT NGR_R_END_RETURN NGR_R_ENT_ARGS NGR_R_SET_RESULT NGR_R_SET_RETURN PROTO_R_ARGS PROTO_R_BAD PROTO_R_COPY PROTO_R_COPY_ARGS PROTO_R_OK PROTO_R_SETANSWER PROTO_R_RETURN PROTO_R_END_RESULT PROTO_R_END_RETURN PROTO_R_ENT_ARGS PROTO_R_SET_RESULT PROTO_R_SET_RETURN PASS_R_ARGS PASS_R_BAD PASS_R_COPY PASS_R_COPY_ARGS PASS_R_OK PASS_R_RETURN PASS_R_END_RESULT PASS_R_END_RETURN PASS_R_ENT_ARGS PASS_R_SET_RESULT PASS_R_SET_RETURN SERV_R_ARGS SERV_R_BAD SERV_R_COPY SERV_R_COPY_ARGS SERV_R_OK SERV_R_SETANSWER SERV_R_RETURN SERV_R_END_RESULT SERV_R_END_RETURN SERV_R_ENT_ARGS SERV_R_SET_RESULT SERV_R_SET_RETURN SETNETGRENT_ARGS INNETGR_ARGS BIND9_TOP_BUILDDIR BIND9_VERSION LIBOBJS LTLIBOBJS'
 ac_subst_files='BIND9_INCLUDES BIND9_MAKE_RULES LIBBIND_API'
 
 # Initialize some variables set by options.
@@ -1019,7 +1019,7 @@ if test -n "$ac_init_help"; then
 Optional Features:
   --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
-  --disable-threads	disable multithreading
+  --enable-threads	enable multithreading
   --enable-shared[=PKGS]
                           build shared libraries [default=yes]
   --enable-static[=PKGS]
@@ -3472,7 +3472,8 @@ done
 
 
 
-for ac_header in fcntl.h db.h paths.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/timers.h
+
+for ac_header in fcntl.h db.h paths.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/timers.h stropts.h
 do
 as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
 if eval "test \"\${$as_ac_Header+set}\" = set"; then
@@ -3622,7 +3623,6 @@ fi
 done
 
 
-
 echo "$as_me:$LINENO: checking for an ANSI C-conforming const" >&5
 echo $ECHO_N "checking for an ANSI C-conforming const... $ECHO_C" >&6
 if test "${ac_cv_c_const+set}" = set; then
@@ -3867,6 +3867,72 @@ _ACEOF
 
 fi
 
+echo "$as_me:$LINENO: checking for uintptr_t" >&5
+echo $ECHO_N "checking for uintptr_t... $ECHO_C" >&6
+if test "${ac_cv_type_uintptr_t+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+$ac_includes_default
+int
+main ()
+{
+if ((uintptr_t *) 0)
+  return 0;
+if (sizeof (uintptr_t))
+  return 0;
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"
+			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_type_uintptr_t=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_type_uintptr_t=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_type_uintptr_t" >&5
+echo "${ECHO_T}$ac_cv_type_uintptr_t" >&6
+if test $ac_cv_type_uintptr_t = yes; then
+  :
+else
+
+cat >>confdefs.h <<_ACEOF
+#define uintptr_t unsigned long
+_ACEOF
+
+fi
+
 echo "$as_me:$LINENO: checking whether time.h and sys/time.h may both be included" >&5
 echo $ECHO_N "checking whether time.h and sys/time.h may both be included... $ECHO_C" >&6
 if test "${ac_cv_header_time+set}" = set; then
@@ -4435,24 +4501,81 @@ esac
 #
 # First, decide whether to use multithreading or not.
 #
-echo "$as_me:$LINENO: checking whether to look for thread support" >&5
-echo $ECHO_N "checking whether to look for thread support... $ECHO_C" >&6
+# Enable multithreading by default on systems where it is known
+# to work well, and where debugging of multithreaded programs
+# is supported.
+#
+
+echo "$as_me:$LINENO: checking whether to build with thread support" >&5
+echo $ECHO_N "checking whether to build with thread support... $ECHO_C" >&6
+
+case $host in
+*-dec-osf*)
+	use_threads=true ;;
+*-solaris2.[0-6])
+	# Thread signals are broken on Solaris 2.6; they are sometimes
+	# delivered to the wrong thread.
+	use_threads=false ;;
+*-solaris*)
+	use_threads=true ;;
+*-ibm-aix*)
+	use_threads=true ;;
+*-hp-hpux10*)
+	use_threads=false ;;
+*-hp-hpux11*)
+	use_threads=true ;;
+*-sgi-irix*)
+	use_threads=true ;;
+*-sco-sysv*uw*|*-*-sysv*UnixWare*)
+        # UnixWare
+	use_threads=false ;;
+*-*-sysv*OpenUNIX*)
+        # UnixWare
+	use_threads=true ;;
+*-netbsd*)
+	if test -r /usr/lib/libpthread.so ; then
+	    use_threads=true
+	else
+	    # Socket I/O optimizations introduced in 9.2 expose a
+	    # bug in unproven-pthreads; see PR #12650
+	    use_threads=false
+	fi
+	;;
+*-openbsd*)
+	# OpenBSD users have reported that named dumps core on
+	# startup when built with threads.
+	use_threads=false ;;
+*-freebsd*)
+	use_threads=false ;;
+*-bsdi234*)
+	# Thread signals do not work reliably on some versions of BSD/OS.
+	use_threads=false ;;
+*-bsdi5*)
+	use_threads=true ;;
+*-linux*)
+   	# Threads are disabled on Linux by default because most
+	# Linux kernels produce unusable core dumps from multithreaded
+	# programs, and because of limitations in setuid().
+	use_threads=false ;;
+*)
+	use_threads=false ;;
+esac
+
 # Check whether --enable-threads or --disable-threads was given.
 if test "${enable_threads+set}" = set; then
   enableval="$enable_threads"
 
 fi;
 case "$enable_threads" in
-	yes|'')
-		echo "$as_me:$LINENO: result: yes" >&5
-echo "${ECHO_T}yes" >&6
+	yes)
 		use_threads=true
 		;;
 	no)
-		echo "$as_me:$LINENO: result: no" >&5
-echo "${ECHO_T}no" >&6
 		use_threads=false
 		;;
+	'')
+		# Use system-dependent default
+		;;
 	*)
 	    	{ { echo "$as_me:$LINENO: error: --enable-threads takes yes or no" >&5
 echo "$as_me: error: --enable-threads takes yes or no" >&2;}
@@ -4462,6 +4585,15 @@ esac
 
 if $use_threads
 then
+	echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6
+else
+	echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6
+fi
+
+if $use_threads
+then
 	#
 	# Search for / configure pthreads in a system-dependent fashion.
 	#
@@ -4497,23 +4629,32 @@ echo "${ECHO_T}PTL2" >&6
 echo "$as_me: WARNING: linking with PTL2 is highly experimental and not expected to work" >&2;}
 			CC=ptlgcc
 		else
-			if test ! -d $LOCALBASE/pthreads
+			if test -r /usr/lib/libpthread.so
 			then
-				echo "$as_me:$LINENO: result: none" >&5
+				echo "$as_me:$LINENO: result: native" >&5
+echo "${ECHO_T}native" >&6
+				LIBS="-lpthread $LIBS"
+			else
+				if test ! -d $LOCALBASE/pthreads
+				then
+					echo "$as_me:$LINENO: result: none" >&5
 echo "${ECHO_T}none" >&6
-				use_threads=false
-			fi
+					{ { echo "$as_me:$LINENO: error: \"could not find thread libraries\"" >&5
+echo "$as_me: error: \"could not find thread libraries\"" >&2;}
+   { (exit 1); exit 1; }; }
+				fi
 
-			if $use_threads
-			then
-				echo "$as_me:$LINENO: result: mit-pthreads/unproven-pthreads" >&5
+				if $use_threads
+				then
+					echo "$as_me:$LINENO: result: mit-pthreads/unproven-pthreads" >&5
 echo "${ECHO_T}mit-pthreads/unproven-pthreads" >&6
-				pkg="$LOCALBASE/pthreads"
-				lib1="-L$pkg/lib -Wl,-R$pkg/lib"
-				lib2="-lpthread -lm -lgcc -lpthread"
-				LIBS="$lib1 $lib2 $LIBS"
-				CPPFLAGS="$CPPFLAGS -I$pkg/include"
-				STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include"
+					pkg="$LOCALBASE/pthreads"
+					lib1="-L$pkg/lib -Wl,-R$pkg/lib"
+					lib2="-lpthread -lm -lgcc -lpthread"
+					LIBS="$lib1 $lib2 $LIBS"
+					CPPFLAGS="$CPPFLAGS -I$pkg/include"
+					STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include"
+				fi
 			fi
 		fi
 		;;
@@ -4883,7 +5024,9 @@ _ACEOF
   LIBS="-lc $LIBS"
 
 else
-  use_threads=false
+  { { echo "$as_me:$LINENO: error: \"could not find thread libraries\"" >&5
+echo "$as_me: error: \"could not find thread libraries\"" >&2;}
+   { (exit 1); exit 1; }; }
 fi
 
 fi
@@ -5444,6 +5587,10 @@ _ACEOF
 			;;
 		*hpux11*)
 			cat >>confdefs.h <<\_ACEOF
+#define NEED_ENDNETGRENT_R 1
+_ACEOF
+
+			cat >>confdefs.h <<\_ACEOF
 #define _PTHREADS_DRAFT4 1
 _ACEOF
 
@@ -5597,11 +5744,20 @@ fi
 			;;
 		esac
 	fi
+	cat >>confdefs.h <<\_ACEOF
+#define _REENTRANT 1
+_ACEOF
+
 	ALWAYS_DEFINES="-D_REENTRANT"
 	DO_PTHREADS="#define DO_PTHREADS 1"
 	WANT_IRS_THREADSGR_OBJS="\${WANT_IRS_THREADSGR_OBJS}"
 	WANT_IRS_THREADSPW_OBJS="\${WANT_IRS_THREADSPW_OBJS}"
-	WANT_IRS_THREADS_OBJS="\${WANT_IRS_THREADS_OBJS}"
+	case $host in
+	ia64-hp-hpux11.*)
+		WANT_IRS_THREADS_OBJS="";;
+	*)
+		WANT_IRS_THREADS_OBJS="\${WANT_IRS_THREADS_OBJS}";;
+	esac
 	WANT_THREADS_OBJS="\${WANT_THREADS_OBJS}"
 	thread_dir=pthreads
 else
@@ -5614,6 +5770,13 @@ else
 	thread_dir=nothreads
 fi
 
+
+
+
+
+
+
+
 echo "$as_me:$LINENO: checking for strlcat" >&5
 echo $ECHO_N "checking for strlcat... $ECHO_C" >&6
 if test "${ac_cv_func_strlcat+set}" = set; then
@@ -5712,13 +5875,6 @@ _ACEOF
 fi
 
 
-
-
-
-
-
-
-
 echo "$as_me:$LINENO: checking for if_nametoindex" >&5
 echo $ECHO_N "checking for if_nametoindex... $ECHO_C" >&6
 if test "${ac_cv_func_if_nametoindex+set}" = set; then
@@ -6267,7 +6423,7 @@ else
 			;;
 		*)
 			# Turn off the pointlessly noisy warnings.
-			STD_CWARNINGS="+w1 +W 474,530"
+			STD_CWARNINGS="+w1 +W 474,530,2193,2236"
 			;;
 		esac
 		CCOPT="$CCOPT -Ae -z"
@@ -6424,6 +6580,156 @@ fi
 case "$host" in
 	mips-sgi-irix*)
 		;;
+	ia64-hp-hpux11.*)
+
+echo "$as_me:$LINENO: checking for socket in -lsocket" >&5
+echo $ECHO_N "checking for socket in -lsocket... $ECHO_C" >&6
+if test "${ac_cv_lib_socket_socket+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lsocket  $LIBS"
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char socket ();
+int
+main ()
+{
+socket ();
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"
+			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_lib_socket_socket=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_lib_socket_socket=no
+fi
+rm -f conftest.err conftest.$ac_objext \
+      conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+echo "$as_me:$LINENO: result: $ac_cv_lib_socket_socket" >&5
+echo "${ECHO_T}$ac_cv_lib_socket_socket" >&6
+if test $ac_cv_lib_socket_socket = yes; then
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBSOCKET 1
+_ACEOF
+
+  LIBS="-lsocket $LIBS"
+
+fi
+
+
+echo "$as_me:$LINENO: checking for inet_ntoa in -lnsl" >&5
+echo $ECHO_N "checking for inet_ntoa in -lnsl... $ECHO_C" >&6
+if test "${ac_cv_lib_nsl_inet_ntoa+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lnsl  $LIBS"
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char inet_ntoa ();
+int
+main ()
+{
+inet_ntoa ();
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"
+			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_lib_nsl_inet_ntoa=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_lib_nsl_inet_ntoa=no
+fi
+rm -f conftest.err conftest.$ac_objext \
+      conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+echo "$as_me:$LINENO: result: $ac_cv_lib_nsl_inet_ntoa" >&5
+echo "${ECHO_T}$ac_cv_lib_nsl_inet_ntoa" >&6
+if test $ac_cv_lib_nsl_inet_ntoa = yes; then
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBNSL 1
+_ACEOF
+
+  LIBS="-lnsl $LIBS"
+
+fi
+
+		;;
 	*)
 
 echo "$as_me:$LINENO: checking for gethostbyname_r in -ld4r" >&5
@@ -7296,7 +7602,7 @@ ia64-*-hpux*)
   ;;
 *-*-irix6*)
   # Find out which ABI we are using.
-  echo '#line 7299 "configure"' > conftest.$ac_ext
+  echo '#line 7605 "configure"' > conftest.$ac_ext
   if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
   (eval $ac_compile) 2>&5
   ac_status=$?
@@ -8293,7 +8599,7 @@ fi
 
 
 # Provide some information about the compiler.
-echo "$as_me:8296:" \
+echo "$as_me:8602:" \
      "checking for Fortran 77 compiler version" >&5
 ac_compiler=`set X $ac_compile; echo $2`
 { (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5
@@ -9354,11 +9660,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9357: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:9663: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:9361: \$? = $ac_status" >&5
+   echo "$as_me:9667: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -9597,11 +9903,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9600: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:9906: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:9604: \$? = $ac_status" >&5
+   echo "$as_me:9910: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -9657,11 +9963,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9660: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:9966: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:9664: \$? = $ac_status" >&5
+   echo "$as_me:9970: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -11842,7 +12148,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 11845 "configure"
+#line 12151 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11940,7 +12246,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 11943 "configure"
+#line 12249 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -14137,11 +14443,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:14140: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:14446: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:14144: \$? = $ac_status" >&5
+   echo "$as_me:14450: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -14197,11 +14503,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:14200: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:14506: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:14204: \$? = $ac_status" >&5
+   echo "$as_me:14510: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -15558,7 +15864,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 15561 "configure"
+#line 15867 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -15656,7 +15962,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 15659 "configure"
+#line 15965 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16493,11 +16799,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:16496: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:16802: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:16500: \$? = $ac_status" >&5
+   echo "$as_me:16806: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -16553,11 +16859,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:16556: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:16862: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:16560: \$? = $ac_status" >&5
+   echo "$as_me:16866: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -18592,11 +18898,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:18595: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:18901: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:18599: \$? = $ac_status" >&5
+   echo "$as_me:18905: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -18835,11 +19141,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:18838: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:19144: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:18842: \$? = $ac_status" >&5
+   echo "$as_me:19148: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -18895,11 +19201,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:18898: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:19204: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:18902: \$? = $ac_status" >&5
+   echo "$as_me:19208: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -21080,7 +21386,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 21083 "configure"
+#line 21389 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -21178,7 +21484,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 21181 "configure"
+#line 21487 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -23007,6 +23313,10 @@ PORT_DIR=port/unknown
 SOLARIS_BITTYPES="#undef NEED_SOLARIS_BITTYPES"
 BSD_COMP="#undef BSD_COMP"
 USE_FIONBIO_IOCTL="#undef USE_FIONBIO_IOCTL"
+PORT_NONBLOCK="#define PORT_NONBLOCK O_NONBLOCK"
+HAVE_MD5="#undef HAVE_MD5"
+USE_POLL="#undef HAVE_POLL"
+SOLARIS2="#undef SOLARIS2"
 case "$host" in
 	*aix3.2*)	PORT_DIR="port/aix32";;
 	*aix4*)		PORT_DIR="port/aix4";;
@@ -23014,7 +23324,9 @@ case "$host" in
 	*aux3*)		PORT_DIR="port/aux3";;
 	*-bsdi2*)	PORT_DIR="port/bsdos2";;
 	*-bsdi*)	PORT_DIR="port/bsdos";;
-	*-cygwin*)	PORT_DIR="port/cygwin";;
+	*-cygwin*)
+			PORT_NONBLOCK="#define PORT_NONBLOCK O_NDELAY"
+			PORT_DIR="port/cygwin";;
 	*-darwin*)	PORT_DIR="port/darwin";;
 	*-osf*)		PORT_DIR="port/decunix";;
 	*-freebsd*)	PORT_DIR="port/freebsd";;
@@ -23030,16 +23342,28 @@ case "$host" in
 	*-openbsd*)	PORT_DIR="port/openbsd";;
 	*-qnx*)		PORT_DIR="port/qnx";;
 	*-rhapsody*)	PORT_DIR="port/rhapsody";;
-	*-solaris2.[01234]*)
+	*-sunos4*)
+			PORT_NONBLOCK="#define PORT_NONBLOCK O_NDELAY"
+			PORT_DIR="port/sunos";;
+	*-solaris2.[01234])
 			BSD_COMP="#define BSD_COMP 1"
 			SOLARIS_BITTYPES="#define NEED_SOLARIS_BITTYPES 1"
 			USE_FIONBIO_IOCTL="#define USE_FIONBIO_IOCTL 1"
+			SOLARIS2="#define SOLARIS2 1"
 			PORT_DIR="port/solaris";;
-	*-solaris2.5*)
+	*-solaris2.5)
 			BSD_COMP="#define BSD_COMP 1"
 			SOLARIS_BITTYPES="#define NEED_SOLARIS_BITTYPES 1"
+			SOLARIS2="#define SOLARIS2 1"
+			PORT_DIR="port/solaris";;
+	*-solaris2.[67])
+			BSD_COMP="#define BSD_COMP 1"
+			SOLARIS2="#define SOLARIS2 1"
 			PORT_DIR="port/solaris";;
 	*-solaris2*)	BSD_COMP="#define BSD_COMP 1"
+			USE_POLL="#define USE_POLL 1"
+			HAVE_MD5="#define HAVE_MD5 1"
+			SOLARIS2="#define SOLARIS2 1"
 			PORT_DIR="port/solaris";;
 	*-ultrix*)	PORT_DIR="port/ultrix";;
 	*-sco-sysv*uw2.0*)	PORT_DIR="port/unixware20";;
@@ -23050,10 +23374,14 @@ esac
 
 
 
-PORT_INCLUDE=${PORT_DIR}/include
 
 
 
+
+
+PORT_INCLUDE=${PORT_DIR}/include
+
+
 #
 # Look for a 4.4BSD or 4.3BSD struct msghdr
 #
@@ -25188,6 +25516,10 @@ _ACEOF
 fi
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for getnetbyaddr_r" >&5
 echo $ECHO_N "checking for getnetbyaddr_r... $ECHO_C" >&6
 if test "${ac_cv_func_getnetbyaddr_r+set}" = set; then
@@ -25518,6 +25850,66 @@ else
   echo "$as_me: failed program was:" >&5
 sed 's/^/| /' conftest.$ac_ext >&5
 
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#undef __USE_MISC
+#define __USE_MISC
+#include <netdb.h>
+int getnetbyaddr_r (uint32_t, int, struct netent *,
+                    char *, size_t, struct netent **, int *);
+
+int
+main ()
+{
+return (0)
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+  (eval $ac_compile) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"
+			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest.$ac_objext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+
+NET_R_ARGS="#define NET_R_ARGS char *buf, size_t buflen, struct netent **answerp, int *h_errnop"
+NET_R_BAD="#define NET_R_BAD ERANGE"
+NET_R_COPY="#define NET_R_COPY buf, buflen"
+NET_R_COPY_ARGS="#define NET_R_COPY_ARGS char *buf, size_t buflen"
+NET_R_OK="#define NET_R_OK 0"
+NET_R_SETANSWER="#define NET_R_SETANSWER 1"
+NET_R_RETURN="#define NET_R_RETURN int"
+GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T unsigned long int"
+NETENT_DATA="#undef NETENT_DATA"
+
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+
 fi
 rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
 
@@ -25543,6 +25935,8 @@ NETENT_DATA="#undef NETENT_DATA"
 
 fi
 
+esac
+
 case "$host" in
 *dec-osf*) GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T int" ;;
 esac
@@ -25767,6 +26161,11 @@ fi
 
 
 
+
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for endnetent_r" >&5
 echo $ECHO_N "checking for endnetent_r... $ECHO_C" >&6
 if test "${ac_cv_func_endnetent_r+set}" = set; then
@@ -26029,6 +26428,7 @@ NET_R_END_RETURN="#define NET_R_END_RETURN void"
 
 fi
 
+esac
 
 
 
@@ -26606,6 +27006,10 @@ fi
 
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for gethostbyname_r" >&5
 echo $ECHO_N "checking for gethostbyname_r... $ECHO_C" >&6
 if test "${ac_cv_func_gethostbyname_r+set}" = set; then
@@ -26805,7 +27209,7 @@ HOST_R_ARGS="#define HOST_R_ARGS struct hostent_data *hdptr"
 HOST_R_BAD="#define HOST_R_BAD (-1)"
 HOST_R_COPY="#define HOST_R_COPY hdptr"
 HOST_R_COPY_ARGS="#define HOST_R_COPY_ARGS HOST_R_ARGS"
-HOST_R_ERRNO="#define HOST_R_ERRNO NULL"
+HOST_R_ERRNO="#undef HOST_R_ERRNO"
 HOST_R_OK="#define HOST_R_OK 0"
 HOST_R_RETURN="#define HOST_R_RETURN int"
 HOST_R_SETANSWER="#undef HOST_R_SETANSWER"
@@ -26896,6 +27300,7 @@ HOSTENT_DATA="#undef HOSTENT_DATA"
 
 fi
 
+esac
 
 
 
@@ -26906,6 +27311,10 @@ fi
 
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for endhostent_r" >&5
 echo $ECHO_N "checking for endhostent_r... $ECHO_C" >&6
 if test "${ac_cv_func_endhostent_r+set}" = set; then
@@ -27171,10 +27580,15 @@ HOST_R_ENT_ARGS="#undef HOST_R_ENT_ARGS /*empty*/"
 
 fi
 
+esac;
 
 
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for sethostent_r" >&5
 echo $ECHO_N "checking for sethostent_r... $ECHO_C" >&6
 if test "${ac_cv_func_sethostent_r+set}" = set; then
@@ -27428,6 +27842,7 @@ HOST_R_SET_RETURN="#define HOST_R_SET_RETURN void"
 
 fi
 
+esac
 
 
 
@@ -27599,6 +28014,10 @@ fi
 rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for getnetgrent_r" >&5
 echo $ECHO_N "checking for getnetgrent_r... $ECHO_C" >&6
 if test "${ac_cv_func_getnetgrent_r+set}" = set; then
@@ -27878,6 +28297,7 @@ NGR_R_RETURN="#define NGR_R_RETURN int"
 
 fi
 
+esac
 
 
 
@@ -28209,6 +28629,10 @@ _ACEOF
 fi
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for getprotoent_r" >&5
 echo $ECHO_N "checking for getprotoent_r... $ECHO_C" >&6
 if test "${ac_cv_func_getprotoent_r+set}" = set; then
@@ -28435,6 +28859,7 @@ PROTO_R_RETURN="#define PROTO_R_RETURN struct protoent *"
 
 fi
 
+esac
 
 
 
@@ -28443,6 +28868,10 @@ fi
 
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for endprotoent_r" >&5
 echo $ECHO_N "checking for endprotoent_r... $ECHO_C" >&6
 if test "${ac_cv_func_endprotoent_r+set}" = set; then
@@ -28599,10 +29028,15 @@ PROTO_R_ENT_ARGS="#undef PROTO_R_ENT_ARGS /*empty*/"
 
 fi
 
+esac
 
 
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for setprotoent_r" >&5
 echo $ECHO_N "checking for setprotoent_r... $ECHO_C" >&6
 if test "${ac_cv_func_setprotoent_r+set}" = set; then
@@ -28754,6 +29188,7 @@ PROTO_R_SET_RETURN="#define PROTO_R_SET_RETURN void"
 
 fi
 
+esac
 
 
 
@@ -29685,6 +30120,10 @@ _ACEOF
 fi
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for getservent_r" >&5
 echo $ECHO_N "checking for getservent_r... $ECHO_C" >&6
 if test "${ac_cv_func_getservent_r+set}" = set; then
@@ -29907,6 +30346,7 @@ SERV_R_RETURN="#define SERV_R_RETURN struct servent *"
 
 fi
 
+esac
 
 
 
@@ -29915,6 +30355,10 @@ fi
 
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for endservent_r" >&5
 echo $ECHO_N "checking for endservent_r... $ECHO_C" >&6
 if test "${ac_cv_func_endservent_r+set}" = set; then
@@ -30071,10 +30515,15 @@ SERV_R_ENT_ARGS="#undef SERV_R_ENT_ARGS /*empty*/"
 
 fi
 
+esac
 
 
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 echo "$as_me:$LINENO: checking for setservent_r" >&5
 echo $ECHO_N "checking for setservent_r... $ECHO_C" >&6
 if test "${ac_cv_func_setservent_r+set}" = set; then
@@ -30229,6 +30678,7 @@ SERV_R_SET_RETURN="#define SERV_R_SET_RETURN void"
 
 fi
 
+esac
 
 
 
@@ -30489,7 +30939,6 @@ case "$host" in
 		hack_shutup_in6addr_init_macros=yes
 		;;
 	*-solaris2.8)
-		hack_shutup_pthreadmutexinit=yes
 		hack_shutup_in6addr_init_macros=yes
 		;;
 	*-solaris2.9)
@@ -31304,7 +31753,11 @@ s,@HAVE_MINIMUM_IFREQ@,$HAVE_MINIMUM_IFREQ,;t t
 s,@BSD_COMP@,$BSD_COMP,;t t
 s,@SOLARIS_BITTYPES@,$SOLARIS_BITTYPES,;t t
 s,@USE_FIONBIO_IOCTL@,$USE_FIONBIO_IOCTL,;t t
+s,@PORT_NONBLOCK@,$PORT_NONBLOCK,;t t
 s,@PORT_DIR@,$PORT_DIR,;t t
+s,@USE_POLL@,$USE_POLL,;t t
+s,@HAVE_MD5@,$HAVE_MD5,;t t
+s,@SOLARIS2@,$SOLARIS2,;t t
 s,@PORT_INCLUDE@,$PORT_INCLUDE,;t t
 s,@ISC_PLATFORM_MSGHDRFLAVOR@,$ISC_PLATFORM_MSGHDRFLAVOR,;t t
 s,@ISC_PLATFORM_NEEDPORTT@,$ISC_PLATFORM_NEEDPORTT,;t t
diff --git a/contrib/bind9/lib/bind/configure.in b/contrib/bind9/lib/bind/configure.in
index 74c18704f56f..50ffe82ab18b 100644
--- a/contrib/bind9/lib/bind/configure.in
+++ b/contrib/bind9/lib/bind/configure.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-AC_REVISION($Revision: 1.83.2.5.2.10 $)
+AC_REVISION($Revision: 1.83.2.5.2.22 $)
 
 AC_INIT(resolv/herror.c)
 AC_PREREQ(2.13)
@@ -169,12 +169,12 @@ AC_PROG_CC
 AC_HEADER_STDC
 
 
-AC_CHECK_HEADERS(fcntl.h db.h paths.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/timers.h)
-
+AC_CHECK_HEADERS(fcntl.h db.h paths.h sys/time.h unistd.h sys/sockio.h sys/select.h sys/timers.h stropts.h)
 
 AC_C_CONST
 AC_C_INLINE
 AC_TYPE_SIZE_T
+AC_CHECK_TYPE(uintptr_t,unsigned long)
 AC_HEADER_TIME
 #
 # check if we need to #include sys/select.h explicitly
@@ -315,86 +315,7 @@ case "$use_randomdev" in
 		;;
 esac
 
-#
-# Begin pthreads checking.
-#
-# First, decide whether to use multithreading or not.
-#
-AC_MSG_CHECKING(whether to look for thread support)
-AC_ARG_ENABLE(threads,
-	[  --disable-threads	disable multithreading])
-case "$enable_threads" in
-	yes|'')
-		AC_MSG_RESULT(yes)
-		use_threads=true
-		;;
-	no)
-		AC_MSG_RESULT(no)	
-		use_threads=false
-		;;
-	*)
-	    	AC_MSG_ERROR([--enable-threads takes yes or no])
-		;;
-esac
-
-if $use_threads
-then
-	#
-	# Search for / configure pthreads in a system-dependent fashion.
-	#
-	case "$host" in
-	  *-netbsd*)
-		# NetBSD has multiple pthreads implementations.	 The
-		# recommended one to use is "unproven-pthreads".  The
-		# older "mit-pthreads" may also work on some NetBSD
-		# versions.  The PTL2 thread library does not
-		# currently work with bind9, but can be chosen with
-		# the --with-ptl2 option for those who wish to
-		# experiment with it.
-		CC="gcc"
-		AC_MSG_CHECKING(which NetBSD thread library to use)
-
-		AC_ARG_WITH(ptl2,
-[  --with-ptl2		on NetBSD, use the ptl2 thread library (experimental)],
-		    use_ptl2="$withval", use_ptl2="no")
-
-		: ${LOCALBASE:=/usr/pkg}
-
-		if test "X$use_ptl2" = "Xyes"
-		then
-			AC_MSG_RESULT(PTL2)
-			AC_MSG_WARN(
-[linking with PTL2 is highly experimental and not expected to work])
-			CC=ptlgcc
-		else
-			if test ! -d $LOCALBASE/pthreads
-			then
-				AC_MSG_RESULT(none)
-				use_threads=false
-			fi
-
-			if $use_threads
-			then
-				AC_MSG_RESULT(mit-pthreads/unproven-pthreads)
-				pkg="$LOCALBASE/pthreads"
-				lib1="-L$pkg/lib -Wl,-R$pkg/lib"
-				lib2="-lpthread -lm -lgcc -lpthread"
-				LIBS="$lib1 $lib2 $LIBS"
-				CPPFLAGS="$CPPFLAGS -I$pkg/include"
-				STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include"
-			fi
-		fi
-		;;
-		*)
-			AC_CHECK_LIB(pthread, pthread_create,,
-				AC_CHECK_LIB(pthread, __pthread_create,,
-				AC_CHECK_LIB(pthread, __pthread_create_system,,
-				AC_CHECK_LIB(c_r, pthread_create,,
-				AC_CHECK_LIB(c, pthread_create,,
-				use_threads=false)))))
-		;;
-	esac
-fi
+sinclude(../../config.threads.in)dnl
 
 if $use_threads
 then
@@ -451,6 +372,7 @@ then
 			AC_DEFINE(POSIX_GETGRNAM_R)
 			;;
 		*hpux11*)
+			AC_DEFINE(NEED_ENDNETGRENT_R)
 			AC_DEFINE(_PTHREADS_DRAFT4)
 			;;
 		#
@@ -503,11 +425,17 @@ then
 			;;
 		esac
 	fi
+	AC_DEFINE(_REENTRANT)
 	ALWAYS_DEFINES="-D_REENTRANT"
 	DO_PTHREADS="#define DO_PTHREADS 1"
 	WANT_IRS_THREADSGR_OBJS="\${WANT_IRS_THREADSGR_OBJS}"
 	WANT_IRS_THREADSPW_OBJS="\${WANT_IRS_THREADSPW_OBJS}"
-	WANT_IRS_THREADS_OBJS="\${WANT_IRS_THREADS_OBJS}"
+	case $host in
+	ia64-hp-hpux11.*)
+		WANT_IRS_THREADS_OBJS="";;
+	*)
+		WANT_IRS_THREADS_OBJS="\${WANT_IRS_THREADS_OBJS}";;
+	esac
 	WANT_THREADS_OBJS="\${WANT_THREADS_OBJS}"
 	thread_dir=pthreads
 else
@@ -520,8 +448,6 @@ else
 	thread_dir=nothreads
 fi
 
-AC_CHECK_FUNC(strlcat, AC_DEFINE(HAVE_STRLCAT))
-
 AC_SUBST(ALWAYS_DEFINES)
 AC_SUBST(DO_PTHREADS)
 AC_SUBST(WANT_IRS_THREADSGR_OBJS)
@@ -529,6 +455,8 @@ AC_SUBST(WANT_IRS_THREADSPW_OBJS)
 AC_SUBST(WANT_IRS_THREADS_OBJS)
 AC_SUBST(WANT_THREADS_OBJS)
 
+AC_CHECK_FUNC(strlcat, AC_DEFINE(HAVE_STRLCAT))
+
 AC_CHECK_FUNC(if_nametoindex,
 	[USE_IFNAMELINKID="#define USE_IFNAMELINKID 1"],
 	[USE_IFNAMELINKID="#undef USE_IFNAMELINKID"])
@@ -605,7 +533,7 @@ else
 			;;
 		*)
 			# Turn off the pointlessly noisy warnings.
-			STD_CWARNINGS="+w1 +W 474,530"
+			STD_CWARNINGS="+w1 +W 474,530,2193,2236"
 			;;
 		esac
 		CCOPT="$CCOPT -Ae -z"
@@ -666,6 +594,10 @@ AC_CHECK_FUNC(catgets, AC_DEFINE(HAVE_CATGETS),)
 case "$host" in
 	mips-sgi-irix*)
 		;;
+	ia64-hp-hpux11.*)
+		AC_CHECK_LIB(socket, socket)
+		AC_CHECK_LIB(nsl, inet_ntoa)
+		;;
 	*)
 		AC_CHECK_LIB(d4r, gethostbyname_r)
 		AC_CHECK_LIB(socket, socket)
@@ -1075,6 +1007,10 @@ PORT_DIR=port/unknown
 SOLARIS_BITTYPES="#undef NEED_SOLARIS_BITTYPES"
 BSD_COMP="#undef BSD_COMP"
 USE_FIONBIO_IOCTL="#undef USE_FIONBIO_IOCTL"
+PORT_NONBLOCK="#define PORT_NONBLOCK O_NONBLOCK"
+HAVE_MD5="#undef HAVE_MD5"
+USE_POLL="#undef HAVE_POLL"
+SOLARIS2="#undef SOLARIS2"
 case "$host" in
 	*aix3.2*)	PORT_DIR="port/aix32";;
 	*aix4*)		PORT_DIR="port/aix4";;
@@ -1082,7 +1018,9 @@ case "$host" in
 	*aux3*)		PORT_DIR="port/aux3";;
 	*-bsdi2*)	PORT_DIR="port/bsdos2";;
 	*-bsdi*)	PORT_DIR="port/bsdos";;
-	*-cygwin*)	PORT_DIR="port/cygwin";;
+	*-cygwin*)
+			PORT_NONBLOCK="#define PORT_NONBLOCK O_NDELAY"
+			PORT_DIR="port/cygwin";;
 	*-darwin*)	PORT_DIR="port/darwin";;
 	*-osf*)		PORT_DIR="port/decunix";;
 	*-freebsd*)	PORT_DIR="port/freebsd";;
@@ -1098,30 +1036,46 @@ case "$host" in
 	*-openbsd*)	PORT_DIR="port/openbsd";;
 	*-qnx*)		PORT_DIR="port/qnx";;
 	*-rhapsody*)	PORT_DIR="port/rhapsody";;
-	*-solaris2.[[01234]]*)
+	*-sunos4*)
+			PORT_NONBLOCK="#define PORT_NONBLOCK O_NDELAY"
+			PORT_DIR="port/sunos";;
+	*-solaris2.[[01234]])
 			BSD_COMP="#define BSD_COMP 1"
 			SOLARIS_BITTYPES="#define NEED_SOLARIS_BITTYPES 1"
 			USE_FIONBIO_IOCTL="#define USE_FIONBIO_IOCTL 1"
+			SOLARIS2="#define SOLARIS2 1"
 			PORT_DIR="port/solaris";;
-	*-solaris2.5*)
+	*-solaris2.5)
 			BSD_COMP="#define BSD_COMP 1"
 			SOLARIS_BITTYPES="#define NEED_SOLARIS_BITTYPES 1"
+			SOLARIS2="#define SOLARIS2 1"
+			PORT_DIR="port/solaris";;
+	*-solaris2.[[67]])
+			BSD_COMP="#define BSD_COMP 1"
+			SOLARIS2="#define SOLARIS2 1"
 			PORT_DIR="port/solaris";;
 	*-solaris2*)	BSD_COMP="#define BSD_COMP 1"
+			USE_POLL="#define USE_POLL 1"
+			HAVE_MD5="#define HAVE_MD5 1"
+			SOLARIS2="#define SOLARIS2 1"
 			PORT_DIR="port/solaris";;
 	*-ultrix*)	PORT_DIR="port/ultrix";;
 	*-sco-sysv*uw2.0*)	PORT_DIR="port/unixware20";;
 	*-sco-sysv*uw2.1.2*)	PORT_DIR="port/unixware212";;
 	*-sco-sysv*uw7*)	PORT_DIR="port/unixware7";;
 esac
+
 AC_SUBST(BSD_COMP)
 AC_SUBST(SOLARIS_BITTYPES)
 AC_SUBST(USE_FIONBIO_IOCTL)
+AC_SUBST(PORT_NONBLOCK)
 AC_SUBST(PORT_DIR)
+AC_SUBST(USE_POLL)
+AC_SUBST(HAVE_MD5)
+AC_SUBST(SOLARIS2)
 PORT_INCLUDE=${PORT_DIR}/include
 AC_SUBST(PORT_INCLUDE)
 
-
 #
 # Look for a 4.4BSD or 4.3BSD struct msghdr
 #
@@ -1365,6 +1319,10 @@ AC_SUBST(GETGROUPLIST_ARGS)
 
 AC_CHECK_FUNC(setgroupent,,AC_DEFINE(NEED_SETGROUPENT))
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(getnetbyaddr_r,
 AC_TRY_COMPILE(
 [
@@ -1453,6 +1411,26 @@ NET_R_RETURN="#define NET_R_RETURN int"
 GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T long"
 NETENT_DATA="#define NETENT_DATA 1"
 ],
+AC_TRY_COMPILE(
+#undef __USE_MISC
+#define __USE_MISC
+[#include <netdb.h>
+int getnetbyaddr_r (uint32_t, int, struct netent *,
+                    char *, size_t, struct netent **, int *);
+],
+[return (0)],
+[
+NET_R_ARGS="#define NET_R_ARGS char *buf, size_t buflen, struct netent **answerp, int *h_errnop"
+NET_R_BAD="#define NET_R_BAD ERANGE"
+NET_R_COPY="#define NET_R_COPY buf, buflen"
+NET_R_COPY_ARGS="#define NET_R_COPY_ARGS char *buf, size_t buflen"
+NET_R_OK="#define NET_R_OK 0"
+NET_R_SETANSWER="#define NET_R_SETANSWER 1"
+NET_R_RETURN="#define NET_R_RETURN int"
+GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T unsigned long int"
+NETENT_DATA="#undef NETENT_DATA"
+],
+)
 )
 )
 )
@@ -1468,6 +1446,8 @@ NET_R_RETURN="#define NET_R_RETURN struct netent *"
 GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T long"
 NETENT_DATA="#undef NETENT_DATA"
 )
+esac
+
 case "$host" in
 *dec-osf*) GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T int" ;;
 esac
@@ -1516,6 +1496,11 @@ AC_SUBST(NET_R_ENT_ARGS)
 AC_SUBST(NET_R_SET_RESULT)
 AC_SUBST(NET_R_SET_RETURN)
 
+
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(endnetent_r,
 AC_TRY_COMPILE(
 [
@@ -1560,6 +1545,7 @@ NET_R_END_RETURN="#define NET_R_END_RETURN void"
 NET_R_END_RESULT="#define NET_R_END_RESULT(x) /*empty*/"
 NET_R_END_RETURN="#define NET_R_END_RETURN void"
 )
+esac
 AC_SUBST(NET_R_END_RESULT)
 AC_SUBST(NET_R_END_RETURN)
 
@@ -1612,6 +1598,10 @@ AC_SUBST(GROUP_R_SET_RESULT)
 AC_SUBST(GROUP_R_SET_RETURN)
 
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(gethostbyname_r,
 AC_TRY_COMPILE(
 [
@@ -1646,7 +1636,7 @@ HOST_R_ARGS="#define HOST_R_ARGS struct hostent_data *hdptr"
 HOST_R_BAD="#define HOST_R_BAD (-1)"
 HOST_R_COPY="#define HOST_R_COPY hdptr"
 HOST_R_COPY_ARGS="#define HOST_R_COPY_ARGS HOST_R_ARGS"
-HOST_R_ERRNO="#define HOST_R_ERRNO NULL"
+HOST_R_ERRNO="#undef HOST_R_ERRNO"
 HOST_R_OK="#define HOST_R_OK 0"
 HOST_R_RETURN="#define HOST_R_RETURN int"
 HOST_R_SETANSWER="#undef HOST_R_SETANSWER"
@@ -1684,6 +1674,7 @@ HOST_R_RETURN="#define HOST_R_RETURN struct hostent *"
 HOST_R_SETANSWER="#undef HOST_R_SETANSWER"
 HOSTENT_DATA="#undef HOSTENT_DATA"
 )
+esac
 AC_SUBST(HOST_R_ARGS)
 AC_SUBST(HOST_R_BAD)
 AC_SUBST(HOST_R_COPY)
@@ -1694,6 +1685,10 @@ AC_SUBST(HOST_R_RETURN)
 AC_SUBST(HOST_R_SETANSWER)
 AC_SUBST(HOSTENT_DATA)
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(endhostent_r,
 AC_TRY_COMPILE([
 #undef _REENTRANT
@@ -1739,10 +1734,15 @@ HOST_R_END_RESULT="#define HOST_R_END_RESULT(x) /*empty*/"
 HOST_R_END_RETURN="#define HOST_R_END_RETURN void"
 HOST_R_ENT_ARGS="#undef HOST_R_ENT_ARGS /*empty*/"
 )
+esac;
 AC_SUBST(HOST_R_END_RESULT)
 AC_SUBST(HOST_R_END_RETURN)
 AC_SUBST(HOST_R_ENT_ARGS)
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(sethostent_r,
 AC_TRY_COMPILE([
 #undef _REENTRANT
@@ -1778,6 +1778,7 @@ HOST_R_SET_RETURN="#define HOST_R_SET_RETURN void"],
 HOST_R_SET_RESULT="#undef HOST_R_SET_RESULT"
 HOST_R_SET_RETURN="#define HOST_R_SET_RETURN void"
 )
+esac
 AC_SUBST(HOST_R_SET_RESULT)
 AC_SUBST(HOST_R_SET_RETURN)
 
@@ -1819,6 +1820,10 @@ SETGRENT_VOID="#undef SETGRENT_VOID"
 )
 AC_SUBST(SETGRENT_VOID)
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(getnetgrent_r,
 AC_TRY_COMPILE(
 [
@@ -1886,6 +1891,7 @@ NGR_R_COPY_ARGS="#define NGR_R_COPY_ARGS NGR_R_ARGS"
 NGR_R_OK="#define NGR_R_OK 1"
 NGR_R_RETURN="#define NGR_R_RETURN int"
 )
+esac
 AC_SUBST(NGR_R_ARGS)
 AC_SUBST(NGR_R_BAD)
 AC_SUBST(NGR_R_COPY)
@@ -1930,6 +1936,10 @@ AC_SUBST(NGR_R_SET_RETURN)
 
 AC_CHECK_FUNC(innetgr_r,,AC_DEFINE(NEED_INNETGR_R))
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(getprotoent_r,
 AC_TRY_COMPILE(
 [
@@ -1984,6 +1994,7 @@ PROTO_R_OK="#define PROTO_R_OK pptr"
 PROTO_R_SETANSWER="#undef PROTO_R_SETANSWER"
 PROTO_R_RETURN="#define PROTO_R_RETURN struct protoent *"
 )
+esac
 AC_SUBST(PROTO_R_ARGS)
 AC_SUBST(PROTO_R_BAD)
 AC_SUBST(PROTO_R_COPY)
@@ -1992,6 +2003,10 @@ AC_SUBST(PROTO_R_OK)
 AC_SUBST(PROTO_R_SETANSWER)
 AC_SUBST(PROTO_R_RETURN)
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(endprotoent_r,
 AC_TRY_COMPILE(
 [
@@ -2015,10 +2030,15 @@ PROTO_R_END_RESULT="#define PROTO_R_END_RESULT(x) /*empty*/"
 PROTO_R_END_RETURN="#define PROTO_R_END_RETURN void"
 PROTO_R_ENT_ARGS="#undef PROTO_R_ENT_ARGS /*empty*/"
 )
+esac
 AC_SUBST(PROTO_R_END_RESULT)
 AC_SUBST(PROTO_R_END_RETURN)
 AC_SUBST(PROTO_R_ENT_ARGS)
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(setprotoent_r,
 AC_TRY_COMPILE(
 [
@@ -2037,6 +2057,7 @@ PROTO_R_SET_RETURN="#define PROTO_R_SET_RETURN void"
 PROTO_R_SET_RESULT="#undef PROTO_R_SET_RESULT"
 PROTO_R_SET_RETURN="#define PROTO_R_SET_RETURN void"
 )
+esac
 AC_SUBST(PROTO_R_SET_RESULT)
 AC_SUBST(PROTO_R_SET_RETURN)
 
@@ -2126,6 +2147,10 @@ AC_SUBST(PASS_R_SET_RETURN)
 AC_CHECK_FUNC(getpwnam_r,,AC_DEFINE(NEED_GETPWNAM_R))
 AC_CHECK_FUNC(getpwuid_r,,AC_DEFINE(NEED_GETPWUID_R))
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(getservent_r,
 AC_TRY_COMPILE([
 #undef __USE_MISC
@@ -2172,6 +2197,7 @@ SERV_R_OK="#define SERV_R_OK sptr"
 SERV_R_SETANSWER="#undef SERV_R_SETANSWER"
 SERV_R_RETURN="#define SERV_R_RETURN struct servent *"
 )
+esac
 AC_SUBST(SERV_R_ARGS)
 AC_SUBST(SERV_R_BAD)
 AC_SUBST(SERV_R_COPY)
@@ -2180,6 +2206,10 @@ AC_SUBST(SERV_R_OK)
 AC_SUBST(SERV_R_SETANSWER)
 AC_SUBST(SERV_R_RETURN)
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(endservent_r,
 AC_TRY_COMPILE(
 [
@@ -2204,10 +2234,15 @@ SERV_R_END_RESULT="#define SERV_R_END_RESULT(x) /*empty*/"
 SERV_R_END_RETURN="#define SERV_R_END_RETURN void "
 SERV_R_ENT_ARGS="#undef SERV_R_ENT_ARGS /*empty*/"
 )
+esac
 AC_SUBST(SERV_R_END_RESULT)
 AC_SUBST(SERV_R_END_RETURN)
 AC_SUBST(SERV_R_ENT_ARGS)
 
+case $host in
+ia64-hp-hpux11.*)
+;;
+*)
 AC_CHECK_FUNC(setservent_r,
 AC_TRY_COMPILE(
 [
@@ -2229,6 +2264,7 @@ SERV_R_SET_RETURN="#define SERV_R_SET_RETURN void"
 SERV_R_SET_RESULT="#undef SERV_R_SET_RESULT"
 SERV_R_SET_RETURN="#define SERV_R_SET_RETURN void"
 )
+esac
 AC_SUBST(SERV_R_SET_RESULT)
 AC_SUBST(SERV_R_SET_RETURN)
 
@@ -2327,7 +2363,6 @@ case "$host" in
 		hack_shutup_in6addr_init_macros=yes
 		;;
 	*-solaris2.8)
-		hack_shutup_pthreadmutexinit=yes
 		hack_shutup_in6addr_init_macros=yes
 		;;
 	*-solaris2.9)
diff --git a/contrib/bind9/lib/bind/dst/dst_api.c b/contrib/bind9/lib/bind/dst/dst_api.c
index 5f67bd9568cf..51dfd0b8910b 100644
--- a/contrib/bind9/lib/bind/dst/dst_api.c
+++ b/contrib/bind9/lib/bind/dst/dst_api.c
@@ -1,5 +1,5 @@
 #ifndef LINT
-static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/dst_api.c,v 1.4.2.6.8.1 2004/09/16 00:57:33 marka Exp $";
+static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/dst_api.c,v 1.4.2.6.8.3 2005/10/11 00:48:14 marka Exp $";
 #endif
 
 /*
@@ -336,7 +336,10 @@ dst_read_key(const char *in_keyname, const u_int16_t in_id,
 	if (in_keyname == NULL) {
 		EREPORT(("dst_read_private_key(): Null key name passed in\n"));
 		return (NULL);
-	} else
+	} else if (strlen(in_keyname) >= sizeof(keyname)) {
+		EREPORT(("dst_read_private_key(): keyname too big\n"));
+		return (NULL);
+	} else 
 		strcpy(keyname, in_keyname);
 
 	/* before I read in the public key, check if it is allowed to sign */
@@ -347,7 +350,7 @@ dst_read_key(const char *in_keyname, const u_int16_t in_id,
 		return pubkey; 
 
 	if (!(dg_key = dst_s_get_key_struct(keyname, pubkey->dk_alg,
-					 pubkey->dk_flags, pubkey->dk_proto,
+					    pubkey->dk_flags, pubkey->dk_proto,
 					    0)))
 		return (dg_key);
 	/* Fill in private key and some fields in the general key structure */
@@ -953,7 +956,6 @@ dst_generate_key(const char *name, const int bits, const int exp,
 		 const int flags, const int protocol, const int alg)
 {
 	DST_KEY *new_key = NULL;
-	int res;
 	int dnslen;
 	u_char dns[2048];
 
@@ -975,7 +977,7 @@ dst_generate_key(const char *name, const int bits, const int exp,
 			 alg));
 		return (dst_free_key(new_key));
 	}
-	if ((res = new_key->dk_func->generate(new_key, exp)) <= 0) {
+	if (new_key->dk_func->generate(new_key, exp) <= 0) {
 		EREPORT(("dst_generate_key_pair(): Key generation failure %s %d %d %d\n",
 			 new_key->dk_key_name, new_key->dk_alg,
 			 new_key->dk_key_size, exp));
diff --git a/contrib/bind9/lib/bind/dst/hmac_link.c b/contrib/bind9/lib/bind/dst/hmac_link.c
index 8a641d0bf968..aa66c80ec0d1 100644
--- a/contrib/bind9/lib/bind/dst/hmac_link.c
+++ b/contrib/bind9/lib/bind/dst/hmac_link.c
@@ -1,6 +1,6 @@
 #ifdef HMAC_MD5
 #ifndef LINT
-static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/hmac_link.c,v 1.2.2.1 2003/06/27 03:51:36 marka Exp $";
+static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/hmac_link.c,v 1.2.2.1.4.1 2005/07/28 07:43:16 marka Exp $";
 #endif
 /*
  * Portions Copyright (c) 1995-1998 by Trusted Information Systems, Inc.
@@ -36,8 +36,15 @@ static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/hmac_lin
 #include <resolv.h>
 
 #include "dst_internal.h"
+
 #ifdef USE_MD5
-# include "md5.h"
+# ifndef HAVE_MD5
+#  include "md5.h"
+# else
+#  ifdef SOLARIS2
+#   include <sys/md5.h>
+#  endif
+# endif
 # ifndef _MD5_H_
 #  define _MD5_H_ 1	/* make sure we do not include rsaref md5.h file */
 # endif
@@ -438,7 +445,11 @@ dst_hmac_md5_generate_key(DST_KEY *key, const int nothing)
  *	   related functions 
  */
 int
+#ifdef	SUNW_LIBMD5
+dst_md5_hmac_init()
+#else
 dst_hmac_md5_init()
+#endif
 {
 	if (dst_t_func[KEY_HMAC_MD5] != NULL)
 		return (1);
diff --git a/contrib/bind9/lib/bind/dst/md5.h b/contrib/bind9/lib/bind/dst/md5.h
index c886d17bb009..6525662b67f0 100644
--- a/contrib/bind9/lib/bind/dst/md5.h
+++ b/contrib/bind9/lib/bind/dst/md5.h
@@ -59,6 +59,8 @@
 #ifndef HEADER_MD5_H
 #define HEADER_MD5_H
 
+#ifndef	HAVE_MD5
+
 #ifdef  __cplusplus
 extern "C" {
 #endif
@@ -99,3 +101,6 @@ unsigned char *MD5();
 #endif
 
 #endif
+#else 
+#include <sys/md5.h>
+#endif /* HAVE_MD5 */
diff --git a/contrib/bind9/lib/bind/dst/md5_dgst.c b/contrib/bind9/lib/bind/dst/md5_dgst.c
index 48c327eac349..ba0a5a13db38 100644
--- a/contrib/bind9/lib/bind/dst/md5_dgst.c
+++ b/contrib/bind9/lib/bind/dst/md5_dgst.c
@@ -58,6 +58,7 @@
 
 #ifdef USE_MD5 /* Added by ogud@tis.com 1998/1/26 */
 #include <port_before.h>
+#ifndef HAVE_MD5
 #include <stdio.h>
 #include "md5_locl.h"
 #include <port_after.h>
@@ -367,4 +368,5 @@ unsigned long *l;
 		}
 	}
 #endif
+#endif /* HAVE_MD5 */
 #endif /* USE_MD5 */
diff --git a/contrib/bind9/lib/bind/dst/support.c b/contrib/bind9/lib/bind/dst/support.c
index 7b86ea98d3d7..8fe3cdb4780d 100644
--- a/contrib/bind9/lib/bind/dst/support.c
+++ b/contrib/bind9/lib/bind/dst/support.c
@@ -1,4 +1,4 @@
-static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/support.c,v 1.2.2.1 2001/11/02 22:25:29 gson Exp $";
+static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/support.c,v 1.2.2.1.10.2 2005/10/11 00:48:14 marka Exp $";
 
 
 /*
@@ -103,7 +103,7 @@ dst_s_id_calc(const u_char *key, const int keysize)
 	int size = keysize;
 
 	if (!key || (keysize <= 0))
-		return (-1);
+		return (0xffffU);
  
 	for (ac = 0; size > 1; size -= 2, kp += 2)
 		ac += ((*kp) << 8) + *(kp + 1);
@@ -311,19 +311,15 @@ dst_s_fopen(const char *filename, const char *mode, int perm)
 {
 	FILE *fp;
 	char pathname[PATH_MAX];
-	size_t plen = sizeof(pathname);
+
+	if (strlen(filename) + strlen(dst_path) >= sizeof(pathname))
+		return (NULL);
 
 	if (*dst_path != '\0') {
 		strcpy(pathname, dst_path);
-		plen -= strlen(pathname);
-	}
-	else 
-		pathname[0] = '\0';
-
-	if (plen > strlen(filename))
-		strncpy(&pathname[PATH_MAX - plen], filename, plen-1);
-	else 
-		return (NULL);
+		strcat(pathname, filename);
+	} else
+		strcpy(pathname, filename);
 	
 	fp = fopen(pathname, mode);
 	if (perm)
diff --git a/contrib/bind9/lib/bind/include/isc/eventlib.h b/contrib/bind9/lib/bind/include/isc/eventlib.h
index 6750e4d2160b..033b3123d7cc 100644
--- a/contrib/bind9/lib/bind/include/isc/eventlib.h
+++ b/contrib/bind9/lib/bind/include/isc/eventlib.h
@@ -18,7 +18,7 @@
 /* eventlib.h - exported interfaces for eventlib
  * vix 09sep95 [initial]
  *
- * $Id: eventlib.h,v 1.1.2.1.4.1 2004/03/09 08:33:31 marka Exp $
+ * $Id: eventlib.h,v 1.1.2.1.4.2 2005/07/28 07:43:18 marka Exp $
  */
 
 #ifndef _EVENTLIB_H
@@ -76,6 +76,8 @@ typedef	struct { unsigned char mask[256/8]; } evByteMask;
 #define	EV_WRITE	2
 #define	EV_EXCEPT	4
 
+#define EV_WASNONBLOCKING 8	/* Internal library use. */
+
 /* eventlib.c */
 #define evCreate	__evCreate
 #define evSetDebug	__evSetDebug
diff --git a/contrib/bind9/lib/bind/include/resolv.h b/contrib/bind9/lib/bind/include/resolv.h
index f4f3fa47a486..87a95200bb95 100644
--- a/contrib/bind9/lib/bind/include/resolv.h
+++ b/contrib/bind9/lib/bind/include/resolv.h
@@ -50,7 +50,7 @@
 
 /*
  *	@(#)resolv.h	8.1 (Berkeley) 6/2/93
- *	$Id: resolv.h,v 1.7.2.11.4.2 2004/06/25 00:41:05 marka Exp $
+ *	$Id: resolv.h,v 1.7.2.11.4.3 2005/08/25 04:44:13 marka Exp $
  */
 
 #ifndef _RESOLV_H_
@@ -291,6 +291,11 @@ extern struct __res_state *__res_state(void);
 __END_DECLS
 #define _res (*__res_state())
 #else
+#ifdef __linux
+__BEGIN_DECLS
+extern struct __res_state * __res_state(void);
+__END_DECLS
+#endif
 #ifndef __BIND_NOSTATIC
 extern struct __res_state _res;
 #endif
diff --git a/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c b/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c
index 184ad7c580cb..192cf1e752ef 100644
--- a/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c
+++ b/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c
@@ -16,7 +16,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_cidr_ntop.c,v 1.1.2.1.8.2 2004/03/17 00:29:46 marka Exp $";
+static const char rcsid[] = "$Id: inet_cidr_ntop.c,v 1.1.2.1.8.3 2005/11/03 23:08:40 marka Exp $";
 #endif
 
 #include "port_before.h"
@@ -178,7 +178,9 @@ inet_cidr_ntop_ipv6(const u_char *src, int bits, char *dst, size_t size) {
 	for (i = 0; i < NS_IN6ADDRSZ; i++)
 		words[i / 2] |= (src[i] << ((1 - (i % 2)) << 3));
 	best.base = -1;
+	best.len = 0;
 	cur.base = -1;
+	cur.len = 0;
 	for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) {
 		if (words[i] == 0) {
 			if (cur.base == -1)
diff --git a/contrib/bind9/lib/bind/inet/inet_ntop.c b/contrib/bind9/lib/bind/inet/inet_ntop.c
index 6141407fe4a0..cd502ab75862 100644
--- a/contrib/bind9/lib/bind/inet/inet_ntop.c
+++ b/contrib/bind9/lib/bind/inet/inet_ntop.c
@@ -16,7 +16,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_ntop.c,v 1.1.2.1.8.1 2004/03/09 08:33:33 marka Exp $";
+static const char rcsid[] = "$Id: inet_ntop.c,v 1.1.2.1.8.2 2005/11/03 23:08:40 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include "port_before.h"
@@ -137,7 +137,9 @@ inet_ntop6(src, dst, size)
 	for (i = 0; i < NS_IN6ADDRSZ; i++)
 		words[i / 2] |= (src[i] << ((1 - (i % 2)) << 3));
 	best.base = -1;
+	best.len = 0;
 	cur.base = -1;
+	cur.len = 0;
 	for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) {
 		if (words[i] == 0) {
 			if (cur.base == -1)
diff --git a/contrib/bind9/lib/bind/inet/inet_pton.c b/contrib/bind9/lib/bind/inet/inet_pton.c
index c7813f83cd0c..f18a7b64fde2 100644
--- a/contrib/bind9/lib/bind/inet/inet_pton.c
+++ b/contrib/bind9/lib/bind/inet/inet_pton.c
@@ -16,7 +16,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_pton.c,v 1.2.206.1 2004/03/09 08:33:33 marka Exp $";
+static const char rcsid[] = "$Id: inet_pton.c,v 1.2.206.2 2005/07/28 07:43:18 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include "port_before.h"
@@ -141,7 +141,7 @@ inet_pton6(src, dst)
 			  xdigits_u[] = "0123456789ABCDEF";
 	u_char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp;
 	const char *xdigits, *curtok;
-	int ch, saw_xdigit;
+	int ch, seen_xdigits;
 	u_int val;
 
 	memset((tp = tmp), '\0', NS_IN6ADDRSZ);
@@ -152,7 +152,7 @@ inet_pton6(src, dst)
 		if (*++src != ':')
 			return (0);
 	curtok = src;
-	saw_xdigit = 0;
+	seen_xdigits = 0;
 	val = 0;
 	while ((ch = *src++) != '\0') {
 		const char *pch;
@@ -162,14 +162,13 @@ inet_pton6(src, dst)
 		if (pch != NULL) {
 			val <<= 4;
 			val |= (pch - xdigits);
-			if (val > 0xffff)
+			if (++seen_xdigits > 4)
 				return (0);
-			saw_xdigit = 1;
 			continue;
 		}
 		if (ch == ':') {
 			curtok = src;
-			if (!saw_xdigit) {
+			if (!seen_xdigits) {
 				if (colonp)
 					return (0);
 				colonp = tp;
@@ -181,19 +180,19 @@ inet_pton6(src, dst)
 				return (0);
 			*tp++ = (u_char) (val >> 8) & 0xff;
 			*tp++ = (u_char) val & 0xff;
-			saw_xdigit = 0;
+			seen_xdigits = 0;
 			val = 0;
 			continue;
 		}
 		if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) &&
 		    inet_pton4(curtok, tp) > 0) {
 			tp += NS_INADDRSZ;
-			saw_xdigit = 0;
+			seen_xdigits = 0;
 			break;	/* '\0' was seen by inet_pton4(). */
 		}
 		return (0);
 	}
-	if (saw_xdigit) {
+	if (seen_xdigits) {
 		if (tp + NS_INT16SZ > endp)
 			return (0);
 		*tp++ = (u_char) (val >> 8) & 0xff;
diff --git a/contrib/bind9/lib/bind/inet/nsap_addr.c b/contrib/bind9/lib/bind/inet/nsap_addr.c
index 0b9108a92f8a..a4b98e7c4a09 100644
--- a/contrib/bind9/lib/bind/inet/nsap_addr.c
+++ b/contrib/bind9/lib/bind/inet/nsap_addr.c
@@ -16,7 +16,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nsap_addr.c,v 1.2.206.1 2004/03/09 08:33:33 marka Exp $";
+static const char rcsid[] = "$Id: nsap_addr.c,v 1.2.206.2 2005/07/28 07:43:18 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include "port_before.h"
@@ -31,6 +31,7 @@ static const char rcsid[] = "$Id: nsap_addr.c,v 1.2.206.1 2004/03/09 08:33:33 ma
 
 #include <ctype.h>
 #include <resolv.h>
+#include <resolv_mt.h>
 
 #include "port_after.h"
 
@@ -79,7 +80,7 @@ char *
 inet_nsap_ntoa(int binlen, const u_char *binary, char *ascii) {
 	int nib;
 	int i;
-	static char tmpbuf[2+255*3];
+	char *tmpbuf = inet_nsap_ntoa_tmpbuf;
 	char *start;
 
 	if (ascii)
diff --git a/contrib/bind9/lib/bind/irs/dns_ho.c b/contrib/bind9/lib/bind/irs/dns_ho.c
index 69b4b4f2c3ba..e8da61a0c1a8 100644
--- a/contrib/bind9/lib/bind/irs/dns_ho.c
+++ b/contrib/bind9/lib/bind/irs/dns_ho.c
@@ -52,7 +52,7 @@
 /* BIND Id: gethnamaddr.c,v 8.15 1996/05/22 04:56:30 vixie Exp $ */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: dns_ho.c,v 1.5.2.7.4.5 2004/08/24 00:32:15 marka Exp $";
+static const char rcsid[] = "$Id: dns_ho.c,v 1.5.2.7.4.6 2005/10/11 00:48:14 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 /* Imports. */
@@ -688,7 +688,7 @@ gethostans(struct irs_ho *this,
 {
 	struct pvt *pvt = (struct pvt *)this->private;
 	int type, class, ancount, qdcount, n, haveanswer, had_error;
-	int error = NETDB_SUCCESS, arcount;
+	int error = NETDB_SUCCESS;
 	int (*name_ok)(const char *);
 	const HEADER *hp;
 	const u_char *eom;
@@ -735,7 +735,6 @@ gethostans(struct irs_ho *this,
 	hp = (const HEADER *)ansbuf;
 	ancount = ntohs(hp->ancount);
 	qdcount = ntohs(hp->qdcount);
-	arcount = ntohs(hp->arcount);
 	bp = pvt->hostbuf;
 	ep = pvt->hostbuf + sizeof(pvt->hostbuf);
 	cp = ansbuf + HFIXEDSZ;
diff --git a/contrib/bind9/lib/bind/irs/getaddrinfo.c b/contrib/bind9/lib/bind/irs/getaddrinfo.c
index e08cf78424bb..d80f298bf266 100644
--- a/contrib/bind9/lib/bind/irs/getaddrinfo.c
+++ b/contrib/bind9/lib/bind/irs/getaddrinfo.c
@@ -244,6 +244,7 @@ do { \
 		goto free; \
 } while (/*CONSTCOND*/0)
 
+#ifndef SOLARIS2
 #define ERR(err) \
 do { \
 	/* external reference: error, and label bad */ \
@@ -251,6 +252,16 @@ do { \
 	goto bad; \
 	/*NOTREACHED*/ \
 } while (/*CONSTCOND*/0)
+#else
+#define ERR(err) \
+do { \
+	/* external reference: error, and label bad */ \
+	error = (err); \
+	if (error == error) \
+		goto bad; \
+} while (/*CONSTCOND*/0)
+#endif
+
 
 #define MATCH_FAMILY(x, y, w) \
 	((x) == (y) || (/*CONSTCOND*/(w) && ((x) == PF_UNSPEC || (y) == PF_UNSPEC)))
@@ -321,6 +332,15 @@ getaddrinfo(hostname, servname, hints, res)
 	pai->ai_family = PF_UNSPEC;
 	pai->ai_socktype = ANY;
 	pai->ai_protocol = ANY;
+#if defined(sun) && defined(_SOCKLEN_T) && defined(__sparcv9)
+	/*
+	 * clear _ai_pad to preserve binary
+	 * compatibility with previously compiled 64-bit
+	 * applications in a pre-SUSv3 environment by
+	 * guaranteeing the upper 32-bits are empty.
+	 */
+	pai->_ai_pad = 0;
+#endif
 	pai->ai_addrlen = 0;
 	pai->ai_canonname = NULL;
 	pai->ai_addr = NULL;
@@ -345,6 +365,13 @@ getaddrinfo(hostname, servname, hints, res)
 		}
 		memcpy(pai, hints, sizeof(*pai));
 
+#if defined(sun) && defined(_SOCKLEN_T) && defined(__sparcv9)
+		/*
+		 * We need to clear _ai_pad to preserve binary
+		 * compatibility.  See prior comment.
+		 */
+		pai->_ai_pad = 0;
+#endif
 		/*
 		 * if both socktype/protocol are specified, check if they
 		 * are meaningful combination.
diff --git a/contrib/bind9/lib/bind/irs/gethostent_r.c b/contrib/bind9/lib/bind/irs/gethostent_r.c
index 28f1a7f7cdfa..8a7cff06fe03 100644
--- a/contrib/bind9/lib/bind/irs/gethostent_r.c
+++ b/contrib/bind9/lib/bind/irs/gethostent_r.c
@@ -16,7 +16,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: gethostent_r.c,v 1.4.206.3 2004/09/01 02:03:07 marka Exp $";
+static const char rcsid[] = "$Id: gethostent_r.c,v 1.4.206.4 2005/09/03 12:47:38 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <port_before.h>
@@ -44,7 +44,9 @@ gethostbyname_r(const char *name,  struct hostent *hptr, HOST_R_ARGS) {
 	int n = 0;
 #endif
 
+#ifdef HOST_R_ERRNO
 	HOST_R_ERRNO;
+#endif
 
 #ifdef HOST_R_SETANSWER
 	if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0)
@@ -69,7 +71,9 @@ gethostbyaddr_r(const char *addr, int len, int type,
 	int n = 0;
 #endif
 
+#ifdef HOST_R_ERRNO
 	HOST_R_ERRNO;
+#endif
 
 #ifdef HOST_R_SETANSWER
 	if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0)
@@ -99,7 +103,9 @@ gethostent_r(struct hostent *hptr, HOST_R_ARGS) {
 	int n = 0;
 #endif
 
+#ifdef HOST_R_ERRNO
 	HOST_R_ERRNO;
+#endif
 
 #ifdef HOST_R_SETANSWER
 	if (he == NULL || (n = copy_hostent(he, hptr, HOST_R_COPY)) != 0)
@@ -123,6 +129,9 @@ sethostent_r(int stay_open, HOST_R_ENT_ARGS)
 sethostent_r(int stay_open)
 #endif
 {
+#ifdef HOST_R_ENT_ARGS
+	UNUSED(hdptr);
+#endif
 	sethostent(stay_open);
 #ifdef	HOST_R_SET_RESULT
 	return (HOST_R_SET_RESULT);
@@ -136,6 +145,9 @@ endhostent_r(HOST_R_ENT_ARGS)
 endhostent_r(void)
 #endif
 {
+#ifdef HOST_R_ENT_ARGS
+	UNUSED(hdptr);
+#endif
 	endhostent();
 	HOST_R_END_RESULT(HOST_R_OK);
 }
diff --git a/contrib/bind9/lib/bind/irs/getnetent_r.c b/contrib/bind9/lib/bind/irs/getnetent_r.c
index 0b540b00b3db..1f8290d17146 100644
--- a/contrib/bind9/lib/bind/irs/getnetent_r.c
+++ b/contrib/bind9/lib/bind/irs/getnetent_r.c
@@ -16,7 +16,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getnetent_r.c,v 1.3.206.1 2004/03/09 08:33:36 marka Exp $";
+static const char rcsid[] = "$Id: getnetent_r.c,v 1.3.206.2 2005/09/03 12:47:38 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <port_before.h>
@@ -118,6 +118,9 @@ setnetent_r(int stay_open, NET_R_ENT_ARGS)
 setnetent_r(int stay_open)
 #endif
 {
+#ifdef NET_R_ENT_ARGS
+	UNUSED(ndptr);
+#endif
 	setnetent(stay_open);
 #ifdef NET_R_SET_RESULT
 	return (NET_R_SET_RESULT);
@@ -131,6 +134,9 @@ endnetent_r(NET_R_ENT_ARGS)
 endnetent_r()
 #endif
 {
+#ifdef NET_R_ENT_ARGS
+	UNUSED(ndptr);
+#endif
 	endnetent();
 	NET_R_END_RESULT(NET_R_OK);
 }
diff --git a/contrib/bind9/lib/bind/irs/getnetgrent_r.c b/contrib/bind9/lib/bind/irs/getnetgrent_r.c
index bb78b5622f9b..b5d9bb167d1b 100644
--- a/contrib/bind9/lib/bind/irs/getnetgrent_r.c
+++ b/contrib/bind9/lib/bind/irs/getnetgrent_r.c
@@ -16,7 +16,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getnetgrent_r.c,v 1.5.2.1.4.3 2004/11/30 01:15:43 marka Exp $";
+static const char rcsid[] = "$Id: getnetgrent_r.c,v 1.5.2.1.4.4 2005/09/03 12:47:38 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <port_before.h>
@@ -77,8 +77,14 @@ setnetgrent_r(const char *netgroup)
 #endif
 {
 	char *tmp;
+#if defined(NGR_R_ENT_ARGS) && !defined(NGR_R_PRIVATE)
+	UNUSED(buf);
+	UNUSED(buflen);
+#endif
+
 	DE_CONST(netgroup, tmp);
 	setnetgrent(tmp);
+
 #ifdef NGR_R_PRIVATE
 	*buf = NULL;
 #endif
@@ -94,6 +100,11 @@ endnetgrent_r(NGR_R_ENT_ARGS)
 endnetgrent_r(void)
 #endif
 {
+#if defined(NGR_R_ENT_ARGS) && !defined(NGR_R_PRIVATE)
+	UNUSED(buf);
+	UNUSED(buflen);
+#endif
+
 	endnetgrent();
 #ifdef NGR_R_PRIVATE
 	if (*buf != NULL)
diff --git a/contrib/bind9/lib/bind/irs/hesiod.c b/contrib/bind9/lib/bind/irs/hesiod.c
index 9b0efeb81db0..618c592249b7 100644
--- a/contrib/bind9/lib/bind/irs/hesiod.c
+++ b/contrib/bind9/lib/bind/irs/hesiod.c
@@ -1,5 +1,5 @@
 #if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: hesiod.c,v 1.1.2.1.4.3 2004/05/17 07:48:56 marka Exp $";
+static const char rcsid[] = "$Id: hesiod.c,v 1.1.2.1.4.4 2005/07/28 07:43:19 marka Exp $";
 #endif
 
 /*
@@ -83,9 +83,7 @@ hesiod_init(void **context) {
 		return (-1);
 	}
 
-	ctx->LHS = NULL;
-	ctx->RHS = NULL;
-	ctx->res = NULL;
+	memset(ctx, 0, sizeof (*ctx));
 
 	if (parse_config_file(ctx, _PATH_HESIOD_CONF) < 0) {
 #ifdef DEF_RHS
diff --git a/contrib/bind9/lib/bind/isc/ev_connects.c b/contrib/bind9/lib/bind/isc/ev_connects.c
index 043e5f497ca6..4b0dd2222a0f 100644
--- a/contrib/bind9/lib/bind/isc/ev_connects.c
+++ b/contrib/bind9/lib/bind/isc/ev_connects.c
@@ -20,7 +20,7 @@
  */
 
 #if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: ev_connects.c,v 1.4.206.1 2004/03/09 08:33:40 marka Exp $";
+static const char rcsid[] = "$Id: ev_connects.c,v 1.4.206.2 2005/07/08 04:52:54 marka Exp $";
 #endif
 
 /* Import. */
@@ -168,10 +168,10 @@ evCancelConn(evContext opaqueCtx, evConnID id) {
 				return (-1);
 		} else {
 #ifdef USE_FIONBIO_IOCTL
-			int on = 1;
-			OK(ioctl(this->fd, FIONBIO, (char *)&on));
+			int off = 0;
+			OK(ioctl(this->fd, FIONBIO, (char *)&off));
 #else
-			OK(fcntl(this->fd, F_SETFL, mode | PORT_NONBLOCK));
+			OK(fcntl(this->fd, F_SETFL, mode & ~PORT_NONBLOCK));
 #endif
 		}
 	}
diff --git a/contrib/bind9/lib/bind/isc/ev_files.c b/contrib/bind9/lib/bind/isc/ev_files.c
index 4d5eb55ad8d5..1f95ed04c999 100644
--- a/contrib/bind9/lib/bind/isc/ev_files.c
+++ b/contrib/bind9/lib/bind/isc/ev_files.c
@@ -20,7 +20,7 @@
  */
 
 #if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: ev_files.c,v 1.3.2.1.4.1 2004/03/09 08:33:42 marka Exp $";
+static const char rcsid[] = "$Id: ev_files.c,v 1.3.2.1.4.3 2005/07/28 07:43:19 marka Exp $";
 #endif
 
 #include "port_before.h"
@@ -58,8 +58,10 @@ evSelectFD(evContext opaqueCtx,
 		 ctx, fd, eventmask, func, uap);
 	if (eventmask == 0 || (eventmask & ~EV_MASK_ALL) != 0)
 		EV_ERR(EINVAL);
+#ifndef USE_POLL
 	if (fd > ctx->highestFD)
 		EV_ERR(EINVAL);
+#endif
 	OK(mode = fcntl(fd, F_GETFL, NULL));	/* side effect: validate fd. */
 
 	/*
@@ -68,6 +70,11 @@ evSelectFD(evContext opaqueCtx,
 	 * of our deselect()'s have to leave it in O_NONBLOCK.  If not, then
 	 * all but our last deselect() has to leave it in O_NONBLOCK.
 	 */
+#ifdef USE_POLL
+	/* Make sure both ctx->pollfds[] and ctx->fdTable[] are large enough */
+	if (fd >= ctx->maxnfds && evPollfdRealloc(ctx, 1, fd) != 0)
+		EV_ERR(ENOMEM);
+#endif /* USE_POLL */
 	id = FindFD(ctx, fd, EV_MASK_ALL);
 	if (id == NULL) {
 		if (mode & PORT_NONBLOCK)
@@ -143,13 +150,6 @@ evSelectFD(evContext opaqueCtx,
 	if (opaqueID)
 		opaqueID->opaque = id;
 
-	evPrintf(ctx, 5,
-		"evSelectFD(fd %d, mask 0x%x): new masks: 0x%lx 0x%lx 0x%lx\n",
-		 fd, eventmask,
-		 (u_long)ctx->rdNext.fds_bits[0],
-		 (u_long)ctx->wrNext.fds_bits[0],
-		 (u_long)ctx->exNext.fds_bits[0]);
-
 	return (0);
 }
 
@@ -204,7 +204,7 @@ evDeselectFD(evContext opaqueCtx, evFileID opaqueID) {
 		 * and (b) the caller didn't ask us anything about O_NONBLOCK.
 		 */
 #ifdef USE_FIONBIO_IOCTL
-		int off = 1;
+		int off = 0;
 		(void) ioctl(del->fd, FIONBIO, (char *)&off);
 #else
 		(void) fcntl(del->fd, F_SETFL, mode & ~PORT_NONBLOCK);
@@ -259,13 +259,6 @@ evDeselectFD(evContext opaqueCtx, evFileID opaqueID) {
 	if (del == ctx->fdNext)
 		ctx->fdNext = del->next;
 
-	evPrintf(ctx, 5,
-	      "evDeselectFD(fd %d, mask 0x%x): new masks: 0x%lx 0x%lx 0x%lx\n",
-		 del->fd, eventmask,
-		 (u_long)ctx->rdNext.fds_bits[0],
-		 (u_long)ctx->wrNext.fds_bits[0],
-		 (u_long)ctx->exNext.fds_bits[0]);
-
 	/* Couldn't free it before now since we were using fields out of it. */
 	FREE(del);
 
diff --git a/contrib/bind9/lib/bind/isc/eventlib.c b/contrib/bind9/lib/bind/isc/eventlib.c
index 06d791e0c112..77b14144b97b 100644
--- a/contrib/bind9/lib/bind/isc/eventlib.c
+++ b/contrib/bind9/lib/bind/isc/eventlib.c
@@ -20,7 +20,7 @@
  */
 
 #if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: eventlib.c,v 1.2.2.1.4.4 2004/12/09 04:07:15 marka Exp $";
+static const char rcsid[] = "$Id: eventlib.c,v 1.2.2.1.4.5 2005/07/28 07:43:20 marka Exp $";
 #endif
 
 #include "port_before.h"
@@ -29,6 +29,9 @@ static const char rcsid[] = "$Id: eventlib.c,v 1.2.2.1.4.4 2004/12/09 04:07:15 m
 #include <sys/types.h>
 #include <sys/time.h>
 #include <sys/stat.h>
+#ifdef SOLARIS2
+#include <limits.h>
+#endif /* SOLARIS2 */
 
 #include <errno.h>
 #include <signal.h>
@@ -44,9 +47,13 @@ static const char rcsid[] = "$Id: eventlib.c,v 1.2.2.1.4.4 2004/12/09 04:07:15 m
 
 int      __evOptMonoTime;
 
+#ifdef USE_POLL
+#define pselect Pselect
+#endif /* USE_POLL */
+
 /* Forward. */
 
-#ifdef NEED_PSELECT
+#if defined(NEED_PSELECT) || defined(USE_POLL)
 static int		pselect(int, void *, void *, void *,
 				struct timespec *,
 				const sigset_t *);
@@ -78,6 +85,18 @@ evCreate(evContext *opaqueCtx) {
 	INIT_LIST(ctx->accepts);
 
 	/* Files. */
+#ifdef USE_POLL
+	ctx->pollfds = NULL;
+	ctx->maxnfds = 0;
+	ctx->firstfd = 0;
+	emulMaskInit(ctx, rdLast, EV_READ, 1);
+	emulMaskInit(ctx, rdNext, EV_READ, 0);
+	emulMaskInit(ctx, wrLast, EV_WRITE, 1);
+	emulMaskInit(ctx, wrNext, EV_WRITE, 0);
+	emulMaskInit(ctx, exLast, EV_EXCEPT, 1);
+	emulMaskInit(ctx, exNext, EV_EXCEPT, 0);
+	emulMaskInit(ctx, nonblockBefore, EV_WASNONBLOCKING, 0);
+#endif /* USE_POLL */
 	ctx->files = NULL;
 	FD_ZERO(&ctx->rdNext);
 	FD_ZERO(&ctx->wrNext);
@@ -86,11 +105,16 @@ evCreate(evContext *opaqueCtx) {
 	ctx->fdMax = -1;
 	ctx->fdNext = NULL;
 	ctx->fdCount = 0;	/* Invalidate {rd,wr,ex}Last. */
+#ifndef USE_POLL
 	ctx->highestFD = FD_SETSIZE - 1;
+	memset(ctx->fdTable, 0, sizeof ctx->fdTable);
+#else
+	ctx->highestFD = INT_MAX / sizeof(struct pollfd);
+	ctx->fdTable = NULL;
+#endif
 #ifdef EVENTLIB_TIME_CHECKS
 	ctx->lastFdCount = 0;
 #endif
-	memset(ctx->fdTable, 0, sizeof ctx->fdTable);
 
 	/* Streams. */
 	ctx->streams = NULL;
@@ -284,34 +308,37 @@ evGetNext(evContext opaqueCtx, evEvent *opaqueEv, int options) {
 		}
 #endif
 		do {
+#ifndef USE_POLL
 			/* XXX need to copy only the bits we are using. */
 			ctx->rdLast = ctx->rdNext;
 			ctx->wrLast = ctx->wrNext;
 			ctx->exLast = ctx->exNext;
-
+#else
+			/*
+			 * The pollfd structure uses separate fields for
+			 * the input and output events (corresponding to
+			 * the ??Next and ??Last fd sets), so there's no
+			 * need to copy one to the other.
+			 */
+#endif /* USE_POLL */
 			if (m == Timer) {
 				INSIST(tp == &t);
 				t = evSubTime(nextTime, ctx->lastEventTime);
 			}
 
-			evPrintf(ctx, 4,
-				"pselect(%d, 0x%lx, 0x%lx, 0x%lx, %ld.%09ld)\n",
-				 ctx->fdMax+1,
-				 (u_long)ctx->rdLast.fds_bits[0],
-				 (u_long)ctx->wrLast.fds_bits[0],
-				 (u_long)ctx->exLast.fds_bits[0],
-				 tp ? (long)tp->tv_sec : -1L,
-				 tp ? tp->tv_nsec : -1);
-
 			/* XXX should predict system's earliness and adjust. */
 			x = pselect(ctx->fdMax+1,
 				    &ctx->rdLast, &ctx->wrLast, &ctx->exLast,
 				    tp, NULL);
 			pselect_errno = errno;
 
+#ifndef USE_POLL
 			evPrintf(ctx, 4, "select() returns %d (err: %s)\n",
 				 x, (x == -1) ? strerror(errno) : "none");
-
+#else
+			evPrintf(ctx, 4, "poll() returns %d (err: %s)\n",
+				x, (x == -1) ? strerror(errno) : "none");
+#endif /* USE_POLL */
 			/* Anything but a poll can change the time. */
 			if (m != JustPoll)
 				ctx->lastEventTime = evNowTime();
@@ -704,7 +731,7 @@ evGetOption(evContext *opaqueCtx, const char *option, int *value) {
 	return (-1);
 }
 
-#ifdef NEED_PSELECT
+#if defined(NEED_PSELECT) || defined(USE_POLL)
 /* XXX needs to move to the porting library. */
 static int
 pselect(int nfds, void *rfds, void *wfds, void *efds,
@@ -714,15 +741,69 @@ pselect(int nfds, void *rfds, void *wfds, void *efds,
 	struct timeval tv, *tvp;
 	sigset_t sigs;
 	int n;
+#ifdef USE_POLL
+	int polltimeout = INFTIM;
+	evContext_p *ctx;
+	struct pollfd *fds;
+	nfds_t pnfds;
+
+	UNUSED(nfds);
+#endif /* USE_POLL */
 
 	if (tsp) {
 		tvp = &tv;
 		tv = evTimeVal(*tsp);
+#ifdef USE_POLL
+		polltimeout = 1000 * tv.tv_sec + tv.tv_usec / 1000;
+#endif /* USE_POLL */
 	} else
 		tvp = NULL;
 	if (sigmask)
 		sigprocmask(SIG_SETMASK, sigmask, &sigs);
+#ifndef USE_POLL
 	n = select(nfds, rfds, wfds, efds, tvp);
+#else
+	/*
+	 * rfds, wfds, and efds should all be from the same evContext_p,
+	 * so any of them will do. If they're all NULL, the caller is
+	 * presumably calling us to block.
+	 */
+	if (rfds != NULL)
+		ctx = ((__evEmulMask *)rfds)->ctx;
+	else if (wfds != NULL)
+		ctx = ((__evEmulMask *)wfds)->ctx;
+	else if (efds != NULL)
+		ctx = ((__evEmulMask *)efds)->ctx;
+	else
+		ctx = NULL;
+	if (ctx != NULL && ctx->fdMax != -1) {
+		fds = &(ctx->pollfds[ctx->firstfd]);
+		pnfds = ctx->fdMax - ctx->firstfd + 1;
+	} else {
+		fds = NULL;
+		pnfds = 0;
+	}
+	n = poll(fds, pnfds, polltimeout);
+	/*
+	 * pselect() should return the total number of events on the file
+	 * desriptors, not just the count of fd:s with activity. Hence,
+	 * traverse the pollfds array and count the events.
+	 */
+	if (n > 0) {
+		int     i, e;
+		for (e = 0, i = ctx->firstfd; i <= ctx->fdMax; i++) {
+			if (ctx->pollfds[i].fd < 0)
+				continue;
+			if (FD_ISSET(i, &ctx->rdLast))
+				e++;
+			if (FD_ISSET(i, &ctx->wrLast))
+				e++;
+			if (FD_ISSET(i, &ctx->exLast))
+				e++;
+			}
+		n = e;
+	}
+#endif /* USE_POLL */
 	if (sigmask)
 		sigprocmask(SIG_SETMASK, &sigs, NULL);
 	if (tsp)
@@ -730,3 +811,127 @@ pselect(int nfds, void *rfds, void *wfds, void *efds,
 	return (n);
 }
 #endif
+
+#ifdef USE_POLL
+int
+evPollfdRealloc(evContext_p *ctx, int pollfd_chunk_size, int fd) {
+ 
+	int     i, maxnfds;
+	void	*pollfds, *fdTable;
+ 
+	if (fd < ctx->maxnfds)
+		return (0);
+ 
+	/* Don't allow ridiculously small values for pollfd_chunk_size */
+	if (pollfd_chunk_size < 20)
+		pollfd_chunk_size = 20;
+ 
+	maxnfds = (1 + (fd/pollfd_chunk_size)) * pollfd_chunk_size;
+ 
+	pollfds = realloc(ctx->pollfds, maxnfds * sizeof(*ctx->pollfds));
+	if (pollfds != NULL)
+		ctx->pollfds = pollfds;
+	fdTable = realloc(ctx->fdTable, maxnfds * sizeof(*ctx->fdTable));
+	if (fdTable != NULL)
+		ctx->fdTable = fdTable;
+ 
+	if (pollfds == NULL || fdTable == NULL) {
+		evPrintf(ctx, 2, "pollfd() realloc (%ld) failed\n",
+			 (long)maxnfds*sizeof(struct pollfd));
+		return (-1);
+	}
+ 
+	for (i = ctx->maxnfds; i < maxnfds; i++) {
+		ctx->pollfds[i].fd = -1;
+		ctx->pollfds[i].events = 0;
+		ctx->fdTable[i] = 0;
+	}
+
+	ctx->maxnfds = maxnfds;
+
+	return (0);
+}
+ 
+/* Find the appropriate 'events' or 'revents' field in the pollfds array */
+short *
+__fd_eventfield(int fd, __evEmulMask *maskp) {
+ 
+	evContext_p     *ctx = (evContext_p *)maskp->ctx;
+ 
+	if (!maskp->result || maskp->type == EV_WASNONBLOCKING)
+		return (&(ctx->pollfds[fd].events));
+	else
+		return (&(ctx->pollfds[fd].revents));
+}
+ 
+/* Translate to poll(2) event */
+short
+__poll_event(__evEmulMask *maskp) {
+ 
+	switch ((maskp)->type) {
+	case EV_READ:
+		return (POLLRDNORM);
+	case EV_WRITE:
+		return (POLLWRNORM);
+	case EV_EXCEPT:
+		return (POLLRDBAND | POLLPRI | POLLWRBAND);
+	case EV_WASNONBLOCKING:
+		return (POLLHUP);
+	default:
+		return (0);
+	}
+}
+ 
+/*
+ * Clear the events corresponding to the specified mask. If this leaves
+ * the events mask empty (apart from the POLLHUP bit), set the fd field
+ * to -1 so that poll(2) will ignore this fd.
+ */
+void
+__fd_clr(int fd, __evEmulMask *maskp) {
+ 
+	evContext_p     *ctx = maskp->ctx;
+ 
+	*__fd_eventfield(fd, maskp) &= ~__poll_event(maskp);
+	if ((ctx->pollfds[fd].events & ~POLLHUP) == 0) {
+		ctx->pollfds[fd].fd = -1;
+		if (fd == ctx->fdMax)
+			while (ctx->fdMax > ctx->firstfd &&
+			       ctx->pollfds[ctx->fdMax].fd < 0)
+				ctx->fdMax--;
+		if (fd == ctx->firstfd)
+			while (ctx->firstfd <= ctx->fdMax &&
+			       ctx->pollfds[ctx->firstfd].fd < 0)
+				ctx->firstfd++;
+		/*
+		 * Do we have a empty set of descriptors?
+		 */
+		if (ctx->firstfd > ctx->fdMax) {
+			ctx->fdMax = -1;
+			ctx->firstfd = 0;
+		}
+	}
+}
+ 
+/*
+ * Set the events bit(s) corresponding to the specified mask. If the events
+ * field has any other bits than POLLHUP set, also set the fd field so that
+ * poll(2) will watch this fd.
+ */
+void
+__fd_set(int fd, __evEmulMask *maskp) {
+ 
+	evContext_p     *ctx = maskp->ctx;
+
+	*__fd_eventfield(fd, maskp) |= __poll_event(maskp);
+	if ((ctx->pollfds[fd].events & ~POLLHUP) != 0) {
+		ctx->pollfds[fd].fd = fd;
+		if (fd < ctx->firstfd || ctx->fdMax == -1)
+			ctx->firstfd = fd;
+		if (fd > ctx->fdMax)
+			ctx->fdMax = fd;
+	}
+}
+#endif /* USE_POLL */
+
+/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/eventlib_p.h b/contrib/bind9/lib/bind/isc/eventlib_p.h
index 8c58c7fd6ef4..b95741d7aff3 100644
--- a/contrib/bind9/lib/bind/isc/eventlib_p.h
+++ b/contrib/bind9/lib/bind/isc/eventlib_p.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (c) 2005 by Internet Systems Consortium, Inc. ("ISC")
  * Copyright (c) 1995-1999 by Internet Software Consortium
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -18,7 +18,7 @@
 /* eventlib_p.h - private interfaces for eventlib
  * vix 09sep95 [initial]
  *
- * $Id: eventlib_p.h,v 1.3.2.1.4.2 2004/12/05 22:38:43 marka Exp $
+ * $Id: eventlib_p.h,v 1.3.2.1.4.3 2005/07/28 07:43:20 marka Exp $
  */
 
 #ifndef _EVENTLIB_P_H
@@ -63,6 +63,13 @@
 #define FILL(p)
 #endif
 
+#ifdef USE_POLL
+#ifdef HAVE_STROPTS_H
+#include <stropts.h>
+#endif
+#include <poll.h>
+#endif /* USE_POLL */
+
 typedef struct evConn {
 	evConnFunc	func;
 	void *		uap;
@@ -166,6 +173,40 @@ typedef struct evEvent_p {
 	} u;
 } evEvent_p;
 
+#ifdef USE_POLL
+typedef struct { 
+	void		*ctx;	/* pointer to the evContext_p   */ 
+	uint32_t	type;	/* READ, WRITE, EXCEPT, nonblk  */ 
+	uint32_t	result;	/* 1 => revents, 0 => events    */ 
+} __evEmulMask; 
+
+#define emulMaskInit(ctx, field, ev, lastnext) \
+	ctx->field.ctx = ctx; \
+	ctx->field.type = ev; \
+	ctx->field.result = lastnext; 
+  
+extern short	*__fd_eventfield(int fd, __evEmulMask *maskp); 
+extern short	__poll_event(__evEmulMask *maskp); 
+extern void		__fd_clr(int fd, __evEmulMask *maskp); 
+extern void		__fd_set(int fd, __evEmulMask *maskp); 
+
+#undef  FD_ZERO 
+#define FD_ZERO(maskp) 
+  
+#undef  FD_SET 
+#define FD_SET(fd, maskp) \
+	__fd_set(fd, maskp) 
+
+#undef  FD_CLR 
+#define FD_CLR(fd, maskp) \
+	__fd_clr(fd, maskp) 
+
+#undef  FD_ISSET 
+#define FD_ISSET(fd, maskp) \
+	((*__fd_eventfield(fd, maskp) & __poll_event(maskp)) != 0) 
+
+#endif /* USE_POLL */
+
 typedef struct {
 	/* Global. */
 	const evEvent_p	*cur;
@@ -177,12 +218,26 @@ typedef struct {
 	LIST(evAccept)	accepts;
 	/* Files. */
 	evFile		*files, *fdNext;
+#ifndef USE_POLL
 	fd_set		rdLast, rdNext;
 	fd_set		wrLast, wrNext;
 	fd_set		exLast, exNext;
 	fd_set		nonblockBefore;
 	int		fdMax, fdCount, highestFD;
 	evFile		*fdTable[FD_SETSIZE];
+#else
+	struct pollfd	*pollfds;	/* Allocated as needed  */ 
+	evFile		**fdTable;	/* Ditto                */ 
+	int		maxnfds;	/* # elements in above  */ 
+	int		firstfd;	/* First active fd      */ 
+	int		fdMax;		/* Last active fd       */ 
+	int		fdCount;	/* # fd:s with I/O      */ 
+	int		highestFD;	/* max fd allowed by OS */ 
+	__evEmulMask	rdLast, rdNext; 
+	__evEmulMask	wrLast, wrNext; 
+	__evEmulMask	exLast, exNext; 
+	__evEmulMask	nonblockBefore; 
+#endif /* USE_POLL */
 #ifdef EVENTLIB_TIME_CHECKS
 	struct timespec	lastSelectTime;
 	int		lastFdCount;
@@ -203,6 +258,10 @@ typedef struct {
 void evPrintf(const evContext_p *ctx, int level, const char *fmt, ...)
      ISC_FORMAT_PRINTF(3, 4);
 
+#ifdef USE_POLL
+extern int evPollfdRealloc(evContext_p *ctx, int pollfd_chunk_size, int fd);
+#endif /* USE_POLL */
+
 /* ev_timers.c */
 #define evCreateTimers __evCreateTimers
 heap_context evCreateTimers(const evContext_p *);
diff --git a/contrib/bind9/lib/bind/isc/memcluster.c b/contrib/bind9/lib/bind/isc/memcluster.c
index 0632ec7d7016..c5b7202817c5 100644
--- a/contrib/bind9/lib/bind/isc/memcluster.c
+++ b/contrib/bind9/lib/bind/isc/memcluster.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (c) 2005 by Internet Systems Consortium, Inc. ("ISC")
  * Copyright (c) 1997,1999 by Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -24,7 +24,7 @@
 
 
 #if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: memcluster.c,v 1.3.206.4 2004/09/16 00:57:34 marka Exp $";
+static const char rcsid[] = "$Id: memcluster.c,v 1.3.206.7 2005/10/11 00:48:15 marka Exp $";
 #endif /* not lint */
 
 #include "port_before.h"
@@ -90,12 +90,28 @@ struct stats {
 	u_long			freefrags;
 };
 
+#ifdef DO_PTHREADS
+#include <pthread.h>
+static pthread_mutex_t	memlock = PTHREAD_MUTEX_INITIALIZER;
+#define MEMLOCK		(void)pthread_mutex_lock(&memlock)
+#define MEMUNLOCK	(void)pthread_mutex_unlock(&memlock)
+#else
+/*
+ * Catch bad lock usage in non threaded build.
+ */
+static unsigned int	memlock = 0;
+#define MEMLOCK		do { INSIST(memlock == 0); memlock = 1; } while (0)
+#define MEMUNLOCK	do { INSIST(memlock == 1); memlock = 0; } while (0)
+#endif  /* DO_PTHEADS */
+
 /* Private data. */
 
 static size_t			max_size;
 static size_t			mem_target;
+#ifndef MEMCLUSTER_BIG_MALLOC
 static size_t			mem_target_half;
 static size_t			mem_target_fudge;
+#endif
 static memcluster_element **	freelists;
 #ifdef MEMCLUSTER_RECORD
 static memcluster_element **	activelists;
@@ -132,8 +148,10 @@ meminit(size_t init_max_size, size_t target_size) {
 		mem_target = DEF_MEM_TARGET;
 	else
 		mem_target = target_size;
+#ifndef MEMCLUSTER_BIG_MALLOC
 	mem_target_half = mem_target / 2;
 	mem_target_fudge = mem_target + mem_target / 4;
+#endif
 	freelists = malloc(max_size * sizeof (memcluster_element *));
 	stats = malloc((max_size+1) * sizeof (struct stats));
 	if (freelists == NULL || stats == NULL) {
@@ -173,14 +191,20 @@ __memget_record(size_t size, const char *file, int line) {
 #endif
 	void *ret;
 
+	MEMLOCK;
+
 #if !defined(MEMCLUSTER_RECORD)
 	UNUSED(file);
 	UNUSED(line);
 #endif
-	if (freelists == NULL)
-		if (meminit(0, 0) == -1)
+	if (freelists == NULL) {
+		if (meminit(0, 0) == -1) {
+			MEMUNLOCK;
 			return (NULL);
+		}
+	}
 	if (size == 0U) {
+		MEMUNLOCK;
 		errno = EINVAL;
 		return (NULL);
 	}
@@ -191,6 +215,7 @@ __memget_record(size_t size, const char *file, int line) {
 #if defined(DEBUGGING_MEMCLUSTER)
 		e = malloc(new_size);
 		if (e == NULL) {
+			MEMUNLOCK;
 			errno = ENOMEM;
 			return (NULL);
 		}
@@ -202,11 +227,13 @@ __memget_record(size_t size, const char *file, int line) {
 		e->next = activelists[max_size];
 		activelists[max_size] = e;
 #endif
+		MEMUNLOCK;
 		e->fencepost = FRONT_FENCEPOST;
 		p = (char *)e + sizeof *e + size;
 		memcpy(p, &fp, sizeof fp);
 		return ((char *)e + sizeof *e);
 #else
+		MEMUNLOCK;
 		return (malloc(size));
 #endif
 	}
@@ -226,6 +253,7 @@ __memget_record(size_t size, const char *file, int line) {
 		if (basic_blocks == NULL) {
 			new = malloc(NUM_BASIC_BLOCKS * mem_target);
 			if (new == NULL) {
+				MEMUNLOCK;
 				errno = ENOMEM;
 				return (NULL);
 			}
@@ -253,6 +281,7 @@ __memget_record(size_t size, const char *file, int line) {
 			total_size = mem_target;
 		new = malloc(total_size);
 		if (new == NULL) {
+			MEMUNLOCK;
 			errno = ENOMEM;
 			return (NULL);
 		}
@@ -318,6 +347,7 @@ __memget_record(size_t size, const char *file, int line) {
 	stats[size].gets++;
 	stats[size].totalgets++;
 	stats[new_size].freefrags--;
+	MEMUNLOCK;
 #if defined(DEBUGGING_MEMCLUSTER)
 	return ((char *)e + sizeof *e);
 #else
@@ -347,6 +377,8 @@ __memput_record(void *mem, size_t size, const char *file, int line) {
 	char *p;
 #endif
 
+	MEMLOCK;
+
 #if !defined (MEMCLUSTER_RECORD)
 	UNUSED(file);
 	UNUSED(line);
@@ -355,6 +387,7 @@ __memput_record(void *mem, size_t size, const char *file, int line) {
 	REQUIRE(freelists != NULL);
 
 	if (size == 0U) {
+		MEMUNLOCK;
 		errno = EINVAL;
 		return;
 	}
@@ -398,6 +431,7 @@ __memput_record(void *mem, size_t size, const char *file, int line) {
 
 		INSIST(stats[max_size].gets != 0U);
 		stats[max_size].gets--;
+		MEMUNLOCK;
 		return;
 	}
 
@@ -436,6 +470,7 @@ __memput_record(void *mem, size_t size, const char *file, int line) {
 	INSIST(stats[size].gets != 0U);
 	stats[size].gets--;
 	stats[new_size].freefrags++;
+	MEMUNLOCK;
 }
 
 void *
@@ -464,8 +499,12 @@ memstats(FILE *out) {
 	memcluster_element *e;
 #endif
 
-	if (freelists == NULL)
+	MEMLOCK;
+
+	if (freelists == NULL) {
+		MEMUNLOCK;
 		return;
+	}
 	for (i = 1; i <= max_size; i++) {
 		const struct stats *s = &stats[i];
 
@@ -492,6 +531,7 @@ memstats(FILE *out) {
 			}
 	}
 #endif
+	MEMUNLOCK;
 }
 
 int
diff --git a/contrib/bind9/lib/bind/nameser/ns_parse.c b/contrib/bind9/lib/bind/nameser/ns_parse.c
index 34ebd3de8481..19a6f51b2db1 100644
--- a/contrib/bind9/lib/bind/nameser/ns_parse.c
+++ b/contrib/bind9/lib/bind/nameser/ns_parse.c
@@ -16,7 +16,7 @@
  */
 
 #ifndef lint
-static const char rcsid[] = "$Id: ns_parse.c,v 1.3.2.1.4.1 2004/03/09 08:33:44 marka Exp $";
+static const char rcsid[] = "$Id: ns_parse.c,v 1.3.2.1.4.3 2005/10/11 00:48:16 marka Exp $";
 #endif
 
 /* Import. */
@@ -40,7 +40,12 @@ static void	setsection(ns_msg *msg, ns_sect sect);
 
 /* Macros. */
 
+#ifndef SOLARIS2
 #define RETERR(err) do { errno = (err); return (-1); } while (0)
+#else
+#define RETERR(err) \
+	do { errno = (err); if (errno == errno) return (-1); } while (0)
+#endif
 
 /* Public. */
 
@@ -135,7 +140,8 @@ ns_parserr(ns_msg *handle, ns_sect section, int rrnum, ns_rr *rr) {
 	int tmp;
 
 	/* Make section right. */
-	if ((tmp = section) < 0 || section >= ns_s_max)
+	tmp = section;
+	if (tmp < 0 || section >= ns_s_max)
 		RETERR(ENODEV);
 	if (section != handle->_sect)
 		setsection(handle, section);
diff --git a/contrib/bind9/lib/bind/nameser/ns_ttl.c b/contrib/bind9/lib/bind/nameser/ns_ttl.c
index 368b05a3a22f..4d18d3f281db 100644
--- a/contrib/bind9/lib/bind/nameser/ns_ttl.c
+++ b/contrib/bind9/lib/bind/nameser/ns_ttl.c
@@ -16,7 +16,7 @@
  */
 
 #ifndef lint
-static const char rcsid[] = "$Id: ns_ttl.c,v 1.1.206.1 2004/03/09 08:33:45 marka Exp $";
+static const char rcsid[] = "$Id: ns_ttl.c,v 1.1.206.2 2005/07/28 07:43:21 marka Exp $";
 #endif
 
 /* Import. */
@@ -133,7 +133,8 @@ ns_parse_ttl(const char *src, u_long *dst) {
 			goto einval;
 		else
 			ttl += tmp;
-	}
+	} else if (!dirty)
+		goto einval;
 	*dst = ttl;
 	return (0);
 
diff --git a/contrib/bind9/lib/bind/nameser/ns_verify.c b/contrib/bind9/lib/bind/nameser/ns_verify.c
index 7ee00a610ba4..adda249bb4c3 100644
--- a/contrib/bind9/lib/bind/nameser/ns_verify.c
+++ b/contrib/bind9/lib/bind/nameser/ns_verify.c
@@ -16,7 +16,7 @@
  */
 
 #ifndef lint
-static const char rcsid[] = "$Id: ns_verify.c,v 1.1.206.1 2004/03/09 08:33:45 marka Exp $";
+static const char rcsid[] = "$Id: ns_verify.c,v 1.1.206.2 2005/10/11 00:48:16 marka Exp $";
 #endif
 
 /* Import. */
@@ -144,7 +144,7 @@ ns_verify(u_char *msg, int *msglen, void *k,
 	int n;
 	int error;
 	u_int16_t type, length;
-	u_int16_t fudge, sigfieldlen, id, otherfieldlen;
+	u_int16_t fudge, sigfieldlen, otherfieldlen;
 
 	dst_init();
 	if (msg == NULL || msglen == NULL || *msglen < 0)
@@ -198,9 +198,9 @@ ns_verify(u_char *msg, int *msglen, void *k,
 	sigstart = cp;
 	cp += sigfieldlen;
 
-	/* Read the original id and error. */
+	/* Skip id and read error. */
 	BOUNDS_CHECK(cp, 2*INT16SZ);
-	GETSHORT(id, cp);
+	cp += INT16SZ;
 	GETSHORT(error, cp);
 
 	/* Parse the other data. */
@@ -341,12 +341,12 @@ ns_verify_tcp(u_char *msg, int *msglen, ns_tcp_tsig_state *state,
 	      int required)
 {
 	HEADER *hp = (HEADER *)msg;
-	u_char *recstart, *rdatastart, *sigstart;
+	u_char *recstart, *sigstart;
 	unsigned int sigfieldlen, otherfieldlen;
 	u_char *cp, *eom = msg + *msglen, *cp2;
 	char name[MAXDNAME], alg[MAXDNAME];
 	u_char buf[MAXDNAME];
-	int n, type, length, fudge, id, error;
+	int n, type, length, fudge, error;
 	time_t timesigned;
 
 	if (msg == NULL || msglen == NULL || state == NULL)
@@ -403,7 +403,6 @@ ns_verify_tcp(u_char *msg, int *msglen, ns_tcp_tsig_state *state,
 		return (NS_TSIG_ERROR_FORMERR);
 
 	/* Read the algorithm name. */
-	rdatastart = cp;
 	n = dn_expand(msg, eom, cp, alg, MAXDNAME);
 	if (n < 0)
 		return (NS_TSIG_ERROR_FORMERR);
@@ -429,9 +428,9 @@ ns_verify_tcp(u_char *msg, int *msglen, ns_tcp_tsig_state *state,
 	sigstart = cp;
 	cp += sigfieldlen;
 
-	/* Read the original id and error. */
+	/* Skip id and read error. */
 	BOUNDS_CHECK(cp, 2*INT16SZ);
-	GETSHORT(id, cp);
+	cp += INT16SZ;
 	GETSHORT(error, cp);
 
 	/* Parse the other data. */
diff --git a/contrib/bind9/lib/bind/port_after.h.in b/contrib/bind9/lib/bind/port_after.h.in
index c043561b16a2..0c956b71ed0e 100644
--- a/contrib/bind9/lib/bind/port_after.h.in
+++ b/contrib/bind9/lib/bind/port_after.h.in
@@ -8,6 +8,9 @@
 #if (!defined(BSD)) || (BSD < 199306)
 #include <sys/bitypes.h>
 #endif
+#ifdef HAVE_INTTYPES_H
+#include <inttypes.h>
+#endif
 
 @NEED_PSELECT@
 @HAVE_SA_LEN@
@@ -27,9 +30,7 @@
 @INNETGR_ARGS@
 @SETNETGRENT_ARGS@
 @USE_IFNAMELINKID@
-
-/* XXX sunos and cygwin needs O_NDELAY */
-#define PORT_NONBLOCK O_NONBLOCK
+@PORT_NONBLOCK@
 
 /*
  * We need to know the IPv6 address family number even on IPv4-only systems.
@@ -255,7 +256,7 @@ char * strsep(char **stringp, const char *delim);
 #endif
 
 #ifndef ALIGN
-#define ALIGN(p) (((unsigned int)(p) + (sizeof(int) - 1)) & ~(sizeof(int) - 1))
+#define ALIGN(p) (((uintptr_t)(p) + (sizeof(long) - 1)) & ~(sizeof(long) - 1))
 #endif
 
 #ifdef NEED_SETGROUPENT
@@ -298,7 +299,7 @@ GROUP_R_SET_RETURN setgrent_r(GROUP_R_ENT_ARGS);
 GROUP_R_END_RETURN endgrent_r(GROUP_R_ENT_ARGS);
 #endif
 
-#ifdef NEED_INNETGR_R
+#if defined(NEED_INNETGR_R) && defined(NGR_R_RETURN)
 NGR_R_RETURN
 innetgr_r(const char *, const char *, const char *, const char *);
 #endif
@@ -381,7 +382,9 @@ int isc__gettimeofday(struct timeval *tp, struct timezone *tzp);
 
 int getnetgrent(char **machinep, char **userp, char **domainp);
 
+#ifdef NGR_R_ARGS
 int getnetgrent_r(char **machinep, char **userp, char **domainp, NGR_R_ARGS);
+#endif
 
 #ifdef SETNETGRENT_ARGS
 void setnetgrent(SETNETGRENT_ARGS);
diff --git a/contrib/bind9/lib/bind/port_before.h.in b/contrib/bind9/lib/bind/port_before.h.in
index d6fbe86ac1e8..c754efd2b03a 100644
--- a/contrib/bind9/lib/bind/port_before.h.in
+++ b/contrib/bind9/lib/bind/port_before.h.in
@@ -18,6 +18,9 @@ struct timezone;        /* silence warning */
 @WANT_IRS_PW@
 
 @BSD_COMP@
+@USE_POLL@
+@HAVE_MD5@
+@SOLARIS2@
 
 @DO_PTHREADS@
 @GETGROUPLIST_ARGS@
@@ -135,4 +138,9 @@ struct timezone;        /* silence warning */
 #define ISC_FORMAT_PRINTF(fmt, args)
 #endif
 
+/* Pull in host order macros when _XOPEN_SOURCE_EXTENDED is defined. */
+#if defined(__hpux) && defined(_XOPEN_SOURCE_EXTENDED)
+#include <sys/byteorder.h>
+#endif
+
 #endif
diff --git a/contrib/bind9/lib/bind/resolv/Makefile.in b/contrib/bind9/lib/bind/resolv/Makefile.in
index 74a20e74fe3c..a235fbc7a5e3 100644
--- a/contrib/bind9/lib/bind/resolv/Makefile.in
+++ b/contrib/bind9/lib/bind/resolv/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,16 +13,16 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.3.206.1 2004/03/15 01:02:54 marka Exp $
+# $Id: Makefile.in,v 1.3.206.3 2005/07/29 00:13:09 marka Exp $
 
 srcdir=		@srcdir@
 VPATH =         @srcdir@
 
-OBJS=	herror.@O@ res_comp.@O@ res_data.@O@ res_debug.@O@ \
+OBJS=	herror.@O@ mtctxres.@O@ res_comp.@O@ res_data.@O@ res_debug.@O@ \
 	res_findzonecut.@O@ res_init.@O@ res_mkquery.@O@ res_mkupdate.@O@ \
 	res_query.@O@ res_send.@O@ res_sendsigned.@O@ res_update.@O@
 
-SRCS=	herror.c res_comp.c res_data.c res_debug.c \
+SRCS=	herror.c mtctxres.c res_comp.c res_data.c res_debug.c \
 	res_findzonecut.c res_init.c res_mkquery.c res_mkupdate.c \
 	res_query.c res_send.c res_sendsigned.c res_update.c
 
diff --git a/contrib/bind9/lib/bind/resolv/res_comp.c b/contrib/bind9/lib/bind/resolv/res_comp.c
index 6468dbc22183..8cc99a762884 100644
--- a/contrib/bind9/lib/bind/resolv/res_comp.c
+++ b/contrib/bind9/lib/bind/resolv/res_comp.c
@@ -70,7 +70,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static const char sccsid[] = "@(#)res_comp.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: res_comp.c,v 1.1.2.1.4.1 2004/03/09 08:33:54 marka Exp $";
+static const char rcsid[] = "$Id: res_comp.c,v 1.1.2.1.4.2 2005/07/28 07:43:22 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include "port_before.h"
@@ -242,6 +242,18 @@ res_dnok(const char *dn) {
  *	__getshort
  * Note that one _ comes from C and the others come from us.
  */
+
+#ifdef SOLARIS2
+#ifdef  __putlong
+#undef  __putlong
+#endif
+#ifdef  __putshort
+#undef  __putshort
+#endif
+#pragma weak    putlong         =       __putlong
+#pragma weak    putshort        =       __putshort
+#endif /* SOLARIS2 */
+
 void __putlong(u_int32_t src, u_char *dst) { ns_put32(src, dst); }
 void __putshort(u_int16_t src, u_char *dst) { ns_put16(src, dst); }
 #ifndef __ultrix__
diff --git a/contrib/bind9/lib/bind/resolv/res_debug.c b/contrib/bind9/lib/bind/resolv/res_debug.c
index 1e228be5e62b..8dda12c5e81c 100644
--- a/contrib/bind9/lib/bind/resolv/res_debug.c
+++ b/contrib/bind9/lib/bind/resolv/res_debug.c
@@ -95,7 +95,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static const char sccsid[] = "@(#)res_debug.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: res_debug.c,v 1.3.2.5.4.5 2004/07/28 20:16:46 marka Exp $";
+static const char rcsid[] = "$Id: res_debug.c,v 1.3.2.5.4.6 2005/07/28 07:43:22 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include "port_before.h"
@@ -113,6 +113,7 @@ static const char rcsid[] = "$Id: res_debug.c,v 1.3.2.5.4.5 2004/07/28 20:16:46
 #include <math.h>
 #include <netdb.h>
 #include <resolv.h>
+#include <resolv_mt.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
@@ -504,7 +505,7 @@ sym_ston(const struct res_sym *syms, const char *name, int *success) {
 
 const char *
 sym_ntos(const struct res_sym *syms, int number, int *success) {
-	static char unname[20];
+	char *unname = sym_ntos_unname;
 
 	for ((void)NULL; syms->name != 0; syms++) {
 		if (number == syms->number) {
@@ -522,7 +523,7 @@ sym_ntos(const struct res_sym *syms, int number, int *success) {
 
 const char *
 sym_ntop(const struct res_sym *syms, int number, int *success) {
-	static char unname[20];
+	char *unname = sym_ntop_unname;
 
 	for ((void)NULL; syms->name != 0; syms++) {
 		if (number == syms->number) {
@@ -596,7 +597,7 @@ p_class(int class) {
  */
 const char *
 p_option(u_long option) {
-	static char nbuf[40];
+	char *nbuf = p_option_nbuf;
 
 	switch (option) {
 	case RES_INIT:		return "init";
@@ -639,7 +640,7 @@ p_option(u_long option) {
  */
 const char *
 p_time(u_int32_t value) {
-	static char nbuf[40];		/* XXX nonreentrant */
+	char *nbuf = p_time_nbuf;
 
 	if (ns_format_ttl(value, nbuf, sizeof nbuf) < 0)
 		sprintf(nbuf, "%u", value);
@@ -695,7 +696,7 @@ static const char *
 precsize_ntoa(prec)
 	u_int8_t prec;
 {
-	static char retbuf[sizeof "90000000.00"];	/* XXX nonreentrant */
+	char *retbuf = precsize_ntoa_retbuf;
 	unsigned long val;
 	int mantissa, exponent;
 
@@ -1097,8 +1098,7 @@ dn_count_labels(const char *name) {
  */
 char *
 p_secstodate (u_long secs) {
-	/* XXX nonreentrant */
-	static char output[15];		/* YYYYMMDDHHMMSS and null */
+	char *output = p_secstodate_output;
 	time_t clock = secs;
 	struct tm *time;
 #ifdef HAVE_TIME_R
diff --git a/contrib/bind9/lib/bind/resolv/res_findzonecut.c b/contrib/bind9/lib/bind/resolv/res_findzonecut.c
index 154babde22b5..804beb647464 100644
--- a/contrib/bind9/lib/bind/resolv/res_findzonecut.c
+++ b/contrib/bind9/lib/bind/resolv/res_findzonecut.c
@@ -1,5 +1,5 @@
 #if !defined(lint) && !defined(SABER)
-static const char rcsid[] = "$Id: res_findzonecut.c,v 1.2.2.3.4.3 2004/09/16 07:06:11 marka Exp $";
+static const char rcsid[] = "$Id: res_findzonecut.c,v 1.2.2.3.4.4 2005/10/11 00:48:16 marka Exp $";
 #endif /* not lint */
 
 /*
@@ -319,7 +319,6 @@ get_soa(res_state statp, const char *dname, ns_class class, int opts,
 		for (i = 0; i < n; i++) {
 			const char *t;
 			const u_char *rdata;
-			int rdlen;
 			ns_rr rr;
 
 			if (ns_parserr(&msg, sect, i, &rr) < 0) {
@@ -368,7 +367,6 @@ get_soa(res_state statp, const char *dname, ns_class class, int opts,
 			}
 			strcpy(zname, t);
 			rdata = ns_rr_rdata(rr);
-			rdlen = ns_rr_rdlen(rr);
 			if (ns_name_uncompress(resp, ns_msg_end(msg), rdata,
 					       mname, msize) < 0) {
 				DPRINTF(("get_soa: ns_name_uncompress failed")
@@ -526,7 +524,6 @@ save_ns(res_state statp, ns_msg *msg, ns_sect sect,
 		const u_char *rdata;
 		rr_ns *nsrr;
 		ns_rr rr;
-		int rdlen;
 
 		if (ns_parserr(msg, sect, i, &rr) < 0) {
 			DPRINTF(("save_ns: ns_parserr(%s, %d) failed",
@@ -545,7 +542,6 @@ save_ns(res_state statp, ns_msg *msg, ns_sect sect,
 				return (-1);
 			}
 			rdata = ns_rr_rdata(rr);
-			rdlen = ns_rr_rdlen(rr);
 			if (ns_name_uncompress(ns_msg_base(*msg),
 					       ns_msg_end(*msg), rdata,
 					       tname, sizeof tname) < 0) {
diff --git a/contrib/bind9/lib/bind/resolv/res_init.c b/contrib/bind9/lib/bind/resolv/res_init.c
index 241f5f7cbf3f..28a3ebd088e9 100644
--- a/contrib/bind9/lib/bind/resolv/res_init.c
+++ b/contrib/bind9/lib/bind/resolv/res_init.c
@@ -70,7 +70,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static const char sccsid[] = "@(#)res_init.c	8.1 (Berkeley) 6/7/93";
-static const char rcsid[] = "$Id: res_init.c,v 1.9.2.5.4.2 2004/03/16 12:34:18 marka Exp $";
+static const char rcsid[] = "$Id: res_init.c,v 1.9.2.5.4.5 2005/11/03 00:00:52 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include "port_before.h"
@@ -102,6 +102,10 @@ static const char rcsid[] = "$Id: res_init.c,v 1.9.2.5.4.2 2004/03/16 12:34:18 m
 #define RESOLVSORT
 #define DEBUG
 
+#ifdef SOLARIS2
+#include <sys/systeminfo.h>
+#endif
+
 static void res_setoptions __P((res_state, const char *, const char *));
 
 #ifdef RESOLVSORT
@@ -163,6 +167,9 @@ __res_vinit(res_state statp, int preinit) {
 	int dots;
 	union res_sockaddr_union u[2];
 
+	if (statp->_u._ext.ext != NULL)
+		res_ndestroy(statp);
+
 	if (!preinit) {
 		statp->retrans = RES_TIMEOUT;
 		statp->retry = RES_DFLRETRY;
@@ -170,9 +177,6 @@ __res_vinit(res_state statp, int preinit) {
 		statp->id = res_randomid();
 	}
 
-	if ((statp->options & RES_INIT) != 0U)
-		res_ndestroy(statp);
-
 	memset(u, 0, sizeof(u));
 #ifdef USELOOPBACK
 	u[nserv].sin.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1);
@@ -212,12 +216,42 @@ __res_vinit(res_state statp, int preinit) {
 		statp->_u._ext.ext->nsaddrs[0].sin = statp->nsaddr;
 		strcpy(statp->_u._ext.ext->nsuffix, "ip6.arpa");
 		strcpy(statp->_u._ext.ext->nsuffix2, "ip6.int");
-	}
+	} else
+		return (-1);
 #ifdef RESOLVSORT
 	statp->nsort = 0;
 #endif
 	res_setservers(statp, u, nserv);
 
+#ifdef	SOLARIS2
+	/*
+	 * The old libresolv derived the defaultdomain from NIS/NIS+.
+	 * We want to keep this behaviour
+	 */
+	{
+		char buf[sizeof(statp->defdname)], *cp;
+		int ret;
+
+		if ((ret = sysinfo(SI_SRPC_DOMAIN, buf, sizeof(buf))) > 0 &&
+			(unsigned int)ret <= sizeof(buf)) {
+			if (buf[0] == '+')
+				buf[0] = '.';
+			cp = strchr(buf, '.');
+			if (cp == NULL) {
+				if (strlcpy(statp->defdname, buf,
+					sizeof(statp->defdname))
+					>= sizeof(statp->defdname))
+					goto freedata;
+			} else {
+				if (strlcpy(statp->defdname, cp+1,
+					sizeof(statp->defdname))
+					 >= sizeof(statp->defdname))
+					goto freedata;
+			}
+		}
+	}
+#endif	/* SOLARIS2 */
+
 	/* Allow user to override the local domain definition */
 	if ((cp = getenv("LOCALDOMAIN")) != NULL) {
 		(void)strncpy(statp->defdname, cp, sizeof(statp->defdname) - 1);
@@ -456,6 +490,15 @@ __res_vinit(res_state statp, int preinit) {
 		res_setoptions(statp, cp, "env");
 	statp->options |= RES_INIT;
 	return (0);
+
+#ifdef	SOLARIS2
+ freedata:
+	if (statp->_u._ext.ext != NULL) {
+		free(statp->_u._ext.ext);
+		statp->_u._ext.ext = NULL;
+	}
+	return (-1);
+#endif
 }
 
 static void
@@ -495,6 +538,22 @@ res_setoptions(res_state statp, const char *options, const char *source)
 			if (statp->options & RES_DEBUG)
 				printf(";;\ttimeout=%d\n", statp->retrans);
 #endif
+#ifdef	SOLARIS2
+		} else if (!strncmp(cp, "retrans:", sizeof("retrans:") - 1)) {
+			/*
+		 	 * For backward compatibility, 'retrans' is
+		 	 * supported as an alias for 'timeout', though
+		 	 * without an imposed maximum.
+		 	 */
+			statp->retrans = atoi(cp + sizeof("retrans:") - 1);
+		} else if (!strncmp(cp, "retry:", sizeof("retry:") - 1)){
+			/*
+			 * For backward compatibility, 'retry' is
+			 * supported as an alias for 'attempts', though
+			 * without an imposed maximum.
+			 */
+			statp->retry = atoi(cp + sizeof("retry:") - 1);
+#endif	/* SOLARIS2 */
 		} else if (!strncmp(cp, "attempts:", sizeof("attempts:") - 1)){
 			i = atoi(cp + sizeof("attempts:") - 1);
 			if (i <= RES_MAXRETRY)
diff --git a/contrib/bind9/lib/bind/resolv/res_mkupdate.c b/contrib/bind9/lib/bind/resolv/res_mkupdate.c
index aac95e5907ef..01078f1a51a6 100644
--- a/contrib/bind9/lib/bind/resolv/res_mkupdate.c
+++ b/contrib/bind9/lib/bind/resolv/res_mkupdate.c
@@ -21,7 +21,7 @@
  */
 
 #if !defined(lint) && !defined(SABER)
-static const char rcsid[] = "$Id: res_mkupdate.c,v 1.1.2.1.4.3 2004/06/03 04:44:48 marka Exp $";
+static const char rcsid[] = "$Id: res_mkupdate.c,v 1.1.2.1.4.5 2005/10/14 05:43:47 marka Exp $";
 #endif /* not lint */
 
 #include "port_before.h"
@@ -78,7 +78,7 @@ int
 res_nmkupdate(res_state statp, ns_updrec *rrecp_in, u_char *buf, int buflen) {
 	ns_updrec *rrecp_start = rrecp_in;
 	HEADER *hp;
-	u_char *cp, *sp1, *sp2, *startp, *endp;
+	u_char *cp, *sp2, *startp, *endp;
 	int n, i, soanum, multiline;
 	ns_updrec *rrecp;
 	struct in_addr ina;
@@ -101,7 +101,6 @@ res_nmkupdate(res_state statp, ns_updrec *rrecp_in, u_char *buf, int buflen) {
 	hp->id = htons(++statp->id);
 	hp->opcode = ns_o_update;
 	hp->rcode = NOERROR;
-	sp1 = buf + 2*INT16SZ;  /* save pointer to zocount */
 	cp = buf + HFIXEDSZ;
 	buflen -= HFIXEDSZ;
 	dpp = dnptrs;
@@ -922,10 +921,10 @@ res_mkupdrec(int section, const char *dname,
 	}
 	INIT_LINK(rrecp, r_link);
 	INIT_LINK(rrecp, r_glink);
- 	rrecp->r_class = class;
-	rrecp->r_type = type;
+ 	rrecp->r_class = (ns_class)class;
+	rrecp->r_type = (ns_type)type;
 	rrecp->r_ttl = ttl;
-	rrecp->r_section = section;
+	rrecp->r_section = (ns_sect)section;
 	return (rrecp);
 }
 
diff --git a/contrib/bind9/lib/bind/resolv/res_send.c b/contrib/bind9/lib/bind/resolv/res_send.c
index 81c24258920f..5be248932596 100644
--- a/contrib/bind9/lib/bind/resolv/res_send.c
+++ b/contrib/bind9/lib/bind/resolv/res_send.c
@@ -52,7 +52,7 @@
  */
 
 /*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (c) 2005 by Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (c) 1996-1999 by Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -70,7 +70,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static const char sccsid[] = "@(#)res_send.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.5 2004/08/10 02:19:56 marka Exp $";
+static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.7 2005/08/15 02:04:41 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 /*
@@ -103,6 +103,13 @@ static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.5 2004/08/10 02:19:56 m
 
 #include "port_after.h"
 
+#ifdef USE_POLL
+#ifdef HAVE_STROPTS_H
+#include <stropts.h>
+#endif
+#include <poll.h>
+#endif /* USE_POLL */
+
 /* Options.  Leave them on. */
 #define DEBUG
 #include "res_debug.h"
@@ -110,7 +117,11 @@ static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.5 2004/08/10 02:19:56 m
 
 #define EXT(res) ((res)->_u._ext)
 
+#ifndef USE_POLL
 static const int highestFD = FD_SETSIZE - 1;
+#else
+static int highestFD = 0;
+#endif
 
 /* Forward. */
 
@@ -125,7 +136,7 @@ static void		Aerror(const res_state, FILE *, const char *, int,
 			       const struct sockaddr *, int);
 static void		Perror(const res_state, FILE *, const char *, int);
 static int		sock_eq(struct sockaddr *, struct sockaddr *);
-#ifdef NEED_PSELECT
+#if defined(NEED_PSELECT) && !defined(USE_POLL)
 static int		pselect(int, void *, void *, void *,
 				struct timespec *,
 				const sigset_t *);
@@ -280,6 +291,10 @@ res_nsend(res_state statp,
 	int gotsomewhere, terrno, try, v_circuit, resplen, ns, n;
 	char abuf[NI_MAXHOST];
 
+#ifdef USE_POLL
+	highestFD = sysconf(_SC_OPEN_MAX) - 1;
+#endif
+
 	if (statp->nscount == 0) {
 		errno = ESRCH;
 		return (-1);
@@ -760,10 +775,15 @@ send_dg(res_state statp,
 	const struct sockaddr *nsap;
 	int nsaplen;
 	struct timespec now, timeout, finish;
-	fd_set dsmask;
 	struct sockaddr_storage from;
 	ISC_SOCKLEN_T fromlen;
 	int resplen, seconds, n, s;
+#ifdef USE_POLL
+	int     polltimeout;
+	struct pollfd   pollfd;
+#else
+	fd_set dsmask;
+#endif
 
 	nsap = get_nsaddr(statp, ns);
 	nsaplen = get_salen(nsap);
@@ -841,6 +861,7 @@ send_dg(res_state statp,
  wait:
 	now = evNowTime();
  nonow:
+#ifndef USE_POLL
 	FD_ZERO(&dsmask);
 	FD_SET(s, &dsmask);
 	if (evCmpTime(finish, now) > 0)
@@ -848,6 +869,17 @@ send_dg(res_state statp,
 	else
 		timeout = evConsTime(0, 0);
 	n = pselect(s + 1, &dsmask, NULL, NULL, &timeout, NULL);
+#else
+	timeout = evSubTime(finish, now);
+	if (timeout.tv_sec < 0)
+		timeout = evConsTime(0, 0);
+	polltimeout = 1000*timeout.tv_sec +
+		timeout.tv_nsec/1000000;
+	pollfd.fd = s;
+	pollfd.events = POLLRDNORM;
+	n = poll(&pollfd, 1, polltimeout);
+#endif /* USE_POLL */
+
 	if (n == 0) {
 		Dprint(statp->options & RES_DEBUG, (stdout, ";; timeout\n"));
 		*gotsomewhere = 1;
@@ -856,7 +888,11 @@ send_dg(res_state statp,
 	if (n < 0) {
 		if (errno == EINTR)
 			goto wait;
+#ifndef USE_POLL
 		Perror(statp, stderr, "select", errno);
+#else
+		Perror(statp, stderr, "poll", errno);
+#endif /* USE_POLL */
 		res_nclose(statp);
 		return (0);
 	}
@@ -1025,7 +1061,7 @@ sock_eq(struct sockaddr *a, struct sockaddr *b) {
 	}
 }
 
-#ifdef NEED_PSELECT
+#if defined(NEED_PSELECT) && !defined(USE_POLL)
 /* XXX needs to move to the porting library. */
 static int
 pselect(int nfds, void *rfds, void *wfds, void *efds,
diff --git a/contrib/bind9/lib/bind/resolv/res_sendsigned.c b/contrib/bind9/lib/bind/resolv/res_sendsigned.c
index 1984377ab124..d1d227457566 100644
--- a/contrib/bind9/lib/bind/resolv/res_sendsigned.c
+++ b/contrib/bind9/lib/bind/resolv/res_sendsigned.c
@@ -122,8 +122,16 @@ retry:
 			(stdout, "%s", ""),
 			answer, (anslen > len) ? len : anslen);
 
-		Dprint(statp->pfcode & RES_PRF_REPLY,
-		       (stdout, ";; TSIG invalid (%s)\n", p_rcode(ret)));
+		if (ret > 0) {
+			Dprint(statp->pfcode & RES_PRF_REPLY,
+			       (stdout, ";; server rejected TSIG (%s)\n",
+				p_rcode(ret)));
+		} else {
+			Dprint(statp->pfcode & RES_PRF_REPLY,
+			       (stdout, ";; TSIG invalid (%s)\n",
+				p_rcode(-ret)));
+		}
+
 		free (nstatp);
 		free (newmsg);
 		dst_free_key(dstkey);
diff --git a/contrib/bind9/lib/bind9/api b/contrib/bind9/lib/bind9/api
index b4cd78b74745..0a12b5e852c1 100644
--- a/contrib/bind9/lib/bind9/api
+++ b/contrib/bind9/lib/bind9/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 0
-LIBREVISION = 5
+LIBREVISION = 7
 LIBAGE = 0
diff --git a/contrib/bind9/lib/bind9/check.c b/contrib/bind9/lib/bind9/check.c
index 0cf1e75627b5..e6e86fd14dfc 100644
--- a/contrib/bind9/lib/bind9/check.c
+++ b/contrib/bind9/lib/bind9/check.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: check.c,v 1.37.6.29 2004/11/22 05:02:41 marka Exp $ */
+/* $Id: check.c,v 1.37.6.32 2005/11/03 23:08:41 marka Exp $ */
 
 #include <config.h>
 
@@ -119,7 +119,7 @@ check_orderent(cfg_obj_t *ent, isc_log_t *logctx) {
 		result = ISC_R_FAILURE;
 	} else if (strcasecmp(cfg_obj_asstring(obj), "fixed") == 0) {
 		cfg_obj_log(obj, logctx, ISC_LOG_WARNING,
-			    "rrset-order: order 'fixed' not implemented");
+			    "rrset-order: order 'fixed' not fully implemented");
 	} else if (/* strcasecmp(cfg_obj_asstring(obj), "fixed") != 0 && */
 		   strcasecmp(cfg_obj_asstring(obj), "random") != 0 &&
 		   strcasecmp(cfg_obj_asstring(obj), "cyclic") != 0) {
@@ -598,8 +598,10 @@ validate_masters(cfg_obj_t *obj, cfg_obj_t *config, isc_uint32_t *countp,
 
 	REQUIRE(countp != NULL);
 	result = isc_symtab_create(mctx, 100, NULL, NULL, ISC_FALSE, &symtab);
-	if (result != ISC_R_SUCCESS)
+	if (result != ISC_R_SUCCESS) {
+		*countp = count;
 		return (result);
+	}
 
  newlist:
 	list = cfg_tuple_get(obj, "addresses");
diff --git a/contrib/bind9/lib/bind9/getaddresses.c b/contrib/bind9/lib/bind9/getaddresses.c
index fafc0a6df29e..02d110478cc1 100644
--- a/contrib/bind9/lib/bind9/getaddresses.c
+++ b/contrib/bind9/lib/bind9/getaddresses.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001, 2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getaddresses.c,v 1.13.126.6 2004/09/16 01:00:58 marka Exp $ */
+/* $Id: getaddresses.c,v 1.13.126.8 2005/10/14 02:13:06 marka Exp $ */
 
 #include <config.h>
 #include <string.h>
@@ -65,8 +65,8 @@ bind9_getaddresses(const char *hostname, in_port_t port,
 	REQUIRE(addrcount != NULL);
 	REQUIRE(addrsize > 0);
 
-	have_ipv4 = (isc_net_probeipv4() == ISC_R_SUCCESS);
-	have_ipv6 = (isc_net_probeipv6() == ISC_R_SUCCESS);
+	have_ipv4 = ISC_TF((isc_net_probeipv4() == ISC_R_SUCCESS));
+	have_ipv6 = ISC_TF((isc_net_probeipv6() == ISC_R_SUCCESS));
 
 	/*
 	 * Try IPv4, then IPv6.  In order to handle the extended format
diff --git a/contrib/bind9/lib/dns/adb.c b/contrib/bind9/lib/dns/adb.c
index 9c8d4d5b4ac5..c0b31db1129d 100644
--- a/contrib/bind9/lib/dns/adb.c
+++ b/contrib/bind9/lib/dns/adb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: adb.c,v 1.181.2.11.2.20 2004/11/10 22:32:40 marka Exp $ */
+/* $Id: adb.c,v 1.181.2.11.2.24 2005/10/14 05:19:00 marka Exp $ */
 
 /*
  * Implementation notes
@@ -1784,7 +1784,7 @@ shutdown_task(isc_task_t *task, isc_event_t *ev) {
 static isc_boolean_t
 check_expire_name(dns_adbname_t **namep, isc_stdtime_t now) {
 	dns_adbname_t *name;
-	isc_result_t result = ISC_FALSE;
+	isc_boolean_t result = ISC_FALSE;
 
 	INSIST(namep != NULL && DNS_ADBNAME_VALID(*namep));
 	name = *namep;
@@ -1861,7 +1861,7 @@ static isc_boolean_t
 cleanup_names(dns_adb_t *adb, int bucket, isc_stdtime_t now) {
 	dns_adbname_t *name;
 	dns_adbname_t *next_name;
-	isc_result_t result = ISC_FALSE;
+	isc_boolean_t result = ISC_FALSE;
 
 	DP(CLEAN_LEVEL, "cleaning name bucket %d", bucket);
 
@@ -3347,7 +3347,7 @@ dns_adb_marklame(dns_adb_t *adb, dns_adbaddrinfo_t *addr, dns_name_t *zone,
 	bucket = addr->entry->lock_bucket;
 	LOCK(&adb->entrylocks[bucket]);
 	zi = ISC_LIST_HEAD(addr->entry->zoneinfo);
-	while (zi != NULL && dns_name_equal(zone, &zi->zone))
+	while (zi != NULL && !dns_name_equal(zone, &zi->zone))
 		zi = ISC_LIST_NEXT(zi, plink);
 	if (zi != NULL) {
 		if (expire_time > zi->lame_timer)
@@ -3366,7 +3366,7 @@ dns_adb_marklame(dns_adb_t *adb, dns_adbaddrinfo_t *addr, dns_name_t *zone,
  unlock:
 	UNLOCK(&adb->entrylocks[bucket]);
 
-	return (ISC_R_SUCCESS);
+	return (result);
 }
 
 void
diff --git a/contrib/bind9/lib/dns/api b/contrib/bind9/lib/dns/api
index c06a62ec803a..7df81573fd7f 100644
--- a/contrib/bind9/lib/dns/api
+++ b/contrib/bind9/lib/dns/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 20
-LIBREVISION = 2
+LIBINTERFACE = 21
+LIBREVISION = 1
 LIBAGE = 0
diff --git a/contrib/bind9/lib/dns/cache.c b/contrib/bind9/lib/dns/cache.c
index b148f6021df9..0e17a957d17a 100644
--- a/contrib/bind9/lib/dns/cache.c
+++ b/contrib/bind9/lib/dns/cache.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cache.c,v 1.45.2.4.8.7 2004/03/08 02:07:52 marka Exp $ */
+/* $Id: cache.c,v 1.45.2.4.8.9 2005/03/17 03:58:30 marka Exp $ */
 
 #include <config.h>
 
@@ -1021,27 +1021,10 @@ dns_cache_flushname(dns_cache_t *cache, dns_name_t *name) {
 		dns_rdataset_init(&rdataset);
 
 		dns_rdatasetiter_current(iter, &rdataset);
-
-		for (result = dns_rdataset_first(&rdataset);
-		     result == ISC_R_SUCCESS;
-		     result = dns_rdataset_next(&rdataset))
-		{
-			dns_rdata_t rdata = DNS_RDATA_INIT;
-			dns_rdatatype_t covers;
-
-			dns_rdataset_current(&rdataset, &rdata);
-			if (rdata.type == dns_rdatatype_rrsig)
-				covers = dns_rdata_covers(&rdata);
-			else
-				covers = 0;
-			result = dns_db_deleterdataset(cache->db, node, NULL,
-						       rdata.type, covers);
-			if (result != ISC_R_SUCCESS &&
-			    result != DNS_R_UNCHANGED)
-				break;
-		}
+		result = dns_db_deleterdataset(cache->db, node, NULL,
+					       rdataset.type, rdataset.covers);
 		dns_rdataset_disassociate(&rdataset);
-		if (result != ISC_R_NOMORE)
+		if (result != ISC_R_SUCCESS && result != DNS_R_UNCHANGED)
 			break;
 	}
 	if (result == ISC_R_NOMORE)
diff --git a/contrib/bind9/lib/dns/forward.c b/contrib/bind9/lib/dns/forward.c
index f94abfe114f0..1455fbad43ce 100644
--- a/contrib/bind9/lib/dns/forward.c
+++ b/contrib/bind9/lib/dns/forward.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: forward.c,v 1.5.206.1 2004/03/06 08:13:38 marka Exp $ */
+/* $Id: forward.c,v 1.5.206.3 2005/03/17 03:58:30 marka Exp $ */
 
 #include <config.h>
 
@@ -139,13 +139,20 @@ isc_result_t
 dns_fwdtable_find(dns_fwdtable_t *fwdtable, dns_name_t *name,
 		  dns_forwarders_t **forwardersp)
 {
+	return (dns_fwdtable_find2(fwdtable, name, NULL, forwardersp));
+} 
+
+isc_result_t
+dns_fwdtable_find2(dns_fwdtable_t *fwdtable, dns_name_t *name,
+		   dns_name_t *foundname, dns_forwarders_t **forwardersp)
+{
 	isc_result_t result;
 
 	REQUIRE(VALID_FWDTABLE(fwdtable));
 
 	RWLOCK(&fwdtable->rwlock, isc_rwlocktype_read);
 
-	result = dns_rbt_findname(fwdtable->table, name, 0, NULL,
+	result = dns_rbt_findname(fwdtable->table, name, 0, foundname,
 				  (void **)forwardersp);
 	if (result == DNS_R_PARTIALMATCH)
 		result = ISC_R_SUCCESS;
diff --git a/contrib/bind9/lib/dns/gen-unix.h b/contrib/bind9/lib/dns/gen-unix.h
index 8c1818dd6d6c..bd007c4541f3 100644
--- a/contrib/bind9/lib/dns/gen-unix.h
+++ b/contrib/bind9/lib/dns/gen-unix.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gen-unix.h,v 1.12.12.3 2004/03/08 09:04:29 marka Exp $ */
+/* $Id: gen-unix.h,v 1.12.12.5 2005/06/09 23:54:29 marka Exp $ */
 
 /*
  * This file is responsible for defining two operations that are not
@@ -40,6 +40,10 @@
 #include <isc/boolean.h>
 #include <isc/lang.h>
 
+#ifdef NEED_OPTARG
+extern char *optarg;
+#endif
+
 #define isc_commandline_parse		getopt
 #define isc_commandline_argument 	optarg
 
diff --git a/contrib/bind9/lib/dns/include/dns/forward.h b/contrib/bind9/lib/dns/include/dns/forward.h
index f1bf5abf017f..1eb62d2a99d0 100644
--- a/contrib/bind9/lib/dns/include/dns/forward.h
+++ b/contrib/bind9/lib/dns/include/dns/forward.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: forward.h,v 1.2.206.1 2004/03/06 08:13:56 marka Exp $ */
+/* $Id: forward.h,v 1.2.206.3 2005/03/17 03:58:31 marka Exp $ */
 
 #ifndef DNS_FORWARD_H
 #define DNS_FORWARD_H 1
@@ -67,6 +67,10 @@ dns_fwdtable_add(dns_fwdtable_t *fwdtable, dns_name_t *name,
 isc_result_t
 dns_fwdtable_find(dns_fwdtable_t *fwdtable, dns_name_t *name,
 		  dns_forwarders_t **forwardersp);
+
+isc_result_t
+dns_fwdtable_find2(dns_fwdtable_t *fwdtable, dns_name_t *name,
+		   dns_name_t *foundname, dns_forwarders_t **forwardersp);
 /*
  * Finds a domain in the forwarding table.  The closest matching parent
  * domain is returned.
@@ -75,6 +79,7 @@ dns_fwdtable_find(dns_fwdtable_t *fwdtable, dns_name_t *name,
  * 	fwdtable is a valid forwarding table.
  * 	name is a valid name
  * 	forwardersp != NULL && *forwardersp == NULL
+ *	foundname to be NULL or a valid name with buffer.
  *
  * Returns:
  * 	ISC_R_SUCCESS
diff --git a/contrib/bind9/lib/dns/include/dns/masterdump.h b/contrib/bind9/lib/dns/include/dns/masterdump.h
index 5058945403b9..888c588f3b62 100644
--- a/contrib/bind9/lib/dns/include/dns/masterdump.h
+++ b/contrib/bind9/lib/dns/include/dns/masterdump.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: masterdump.h,v 1.22.12.8 2004/03/19 05:00:49 marka Exp $ */
+/* $Id: masterdump.h,v 1.22.12.10 2005/09/06 02:12:41 marka Exp $ */
 
 #ifndef DNS_MASTERDUMP_H
 #define DNS_MASTERDUMP_H 1
@@ -122,7 +122,7 @@ LIBDNS_EXTERNAL_DATA extern const dns_master_style_t dns_master_style_full;
  * stop of its own, but the class and type share one.
  */
 LIBDNS_EXTERNAL_DATA extern const dns_master_style_t
-				  dns_master_style_explicitttl;
+					dns_master_style_explicitttl;
 
 /*
  * A master style format designed for cache files.  It prints explicit TTL
diff --git a/contrib/bind9/lib/dns/include/dns/rdataset.h b/contrib/bind9/lib/dns/include/dns/rdataset.h
index e2b0753a998f..d856784c3e88 100644
--- a/contrib/bind9/lib/dns/include/dns/rdataset.h
+++ b/contrib/bind9/lib/dns/include/dns/rdataset.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.h,v 1.41.2.5.2.6 2004/03/08 02:08:01 marka Exp $ */
+/* $Id: rdataset.h,v 1.41.2.5.2.8 2005/03/17 03:58:31 marka Exp $ */
 
 #ifndef DNS_RDATASET_H
 #define DNS_RDATASET_H 1
@@ -130,22 +130,23 @@ struct dns_rdataset {
  *	Used by message.c to indicate that the rdataset's rdata had differing
  *	TTL values, and the rdataset->ttl holds the smallest.
  */
-#define DNS_RDATASETATTR_QUESTION	0x0001
-#define DNS_RDATASETATTR_RENDERED	0x0002		/* Used by message.c */
-#define DNS_RDATASETATTR_ANSWERED	0x0004		/* Used by server. */
-#define DNS_RDATASETATTR_CACHE		0x0008		/* Used by resolver. */
-#define DNS_RDATASETATTR_ANSWER		0x0010		/* Used by resolver. */
-#define DNS_RDATASETATTR_ANSWERSIG	0x0020		/* Used by resolver. */
-#define DNS_RDATASETATTR_EXTERNAL	0x0040		/* Used by resolver. */
-#define DNS_RDATASETATTR_NCACHE		0x0080		/* Used by resolver. */
-#define DNS_RDATASETATTR_CHAINING	0x0100		/* Used by resolver. */
-#define DNS_RDATASETATTR_TTLADJUSTED	0x0200		/* Used by message.c */
-#define DNS_RDATASETATTR_FIXEDORDER	0x0400
-#define DNS_RDATASETATTR_RANDOMIZE	0x0800
-#define DNS_RDATASETATTR_CHASE		0x1000		/* Used by resolver. */
-#define DNS_RDATASETATTR_NXDOMAIN	0x2000
-#define DNS_RDATASETATTR_NOQNAME	0x4000
-#define DNS_RDATASETATTR_CHECKNAMES	0x8000		/* Used by resolver. */
+#define DNS_RDATASETATTR_QUESTION	0x00000001
+#define DNS_RDATASETATTR_RENDERED	0x00000002	/* Used by message.c */
+#define DNS_RDATASETATTR_ANSWERED	0x00000004	/* Used by server. */
+#define DNS_RDATASETATTR_CACHE		0x00000008	/* Used by resolver. */
+#define DNS_RDATASETATTR_ANSWER		0x00000010	/* Used by resolver. */
+#define DNS_RDATASETATTR_ANSWERSIG	0x00000020	/* Used by resolver. */
+#define DNS_RDATASETATTR_EXTERNAL	0x00000040	/* Used by resolver. */
+#define DNS_RDATASETATTR_NCACHE		0x00000080	/* Used by resolver. */
+#define DNS_RDATASETATTR_CHAINING	0x00000100	/* Used by resolver. */
+#define DNS_RDATASETATTR_TTLADJUSTED	0x00000200	/* Used by message.c */
+#define DNS_RDATASETATTR_FIXEDORDER	0x00000400
+#define DNS_RDATASETATTR_RANDOMIZE	0x00000800
+#define DNS_RDATASETATTR_CHASE		0x00001000	/* Used by resolver. */
+#define DNS_RDATASETATTR_NXDOMAIN	0x00002000
+#define DNS_RDATASETATTR_NOQNAME	0x00004000
+#define DNS_RDATASETATTR_CHECKNAMES	0x00008000	/* Used by resolver. */
+#define DNS_RDATASETATTR_REQUIREDGLUE	0x00010000
 
 /*
  * _OMITDNSSEC:
diff --git a/contrib/bind9/lib/dns/include/dns/validator.h b/contrib/bind9/lib/dns/include/dns/validator.h
index c405fbb427fb..24769f3c88a5 100644
--- a/contrib/bind9/lib/dns/include/dns/validator.h
+++ b/contrib/bind9/lib/dns/include/dns/validator.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.h,v 1.18.12.7 2004/05/14 05:06:41 marka Exp $ */
+/* $Id: validator.h,v 1.18.12.9 2005/09/06 02:12:41 marka Exp $ */
 
 #ifndef DNS_VALIDATOR_H
 #define DNS_VALIDATOR_H 1
@@ -120,12 +120,16 @@ struct dns_validator {
 	dns_fixedname_t			fname;
 	dns_fixedname_t			wild;
 	ISC_LINK(dns_validator_t)	link;
-	dns_rdataset_t *		dlv;
+	dns_rdataset_t 			dlv;
 	dns_fixedname_t			dlvsep;
 	isc_boolean_t			havedlvsep;
 	isc_boolean_t			mustbesecure;
+	unsigned int			dlvlabels;
+	unsigned int			depth;
 };
 
+#define DNS_VALIDATOR_DLV 1
+
 ISC_LANG_BEGINDECLS
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/journal.c b/contrib/bind9/lib/dns/journal.c
index 13fbdeef70fe..536416d931a1 100644
--- a/contrib/bind9/lib/dns/journal.c
+++ b/contrib/bind9/lib/dns/journal.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,11 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: journal.c,v 1.77.2.1.10.9 2004/09/16 04:57:02 marka Exp $ */
+/* $Id: journal.c,v 1.77.2.1.10.13 2005/11/03 23:08:41 marka Exp $ */
 
 #include <config.h>
 
 #include <stdlib.h>
+#include <unistd.h>
 
 #include <isc/file.h>
 #include <isc/mem.h>
@@ -1564,7 +1565,7 @@ read_one_rr(dns_journal_t *j) {
 	/*
 	 * Read an RR.
 	 */
-	result = journal_read_rrhdr(j, &rrhdr);
+	CHECK(journal_read_rrhdr(j, &rrhdr));
 	/*
 	 * Perform a sanity check on the journal RR size.
 	 * The smallest possible RR has a 1-byte owner name
@@ -1750,6 +1751,8 @@ dns_diff_subtract(dns_diff_t diff[2], dns_diff_t *r) {
 	isc_result_t result;
 	dns_difftuple_t *p[2];
 	int i, t;
+	isc_boolean_t append;
+
 	CHECK(dns_diff_sort(&diff[0], rdata_order));
 	CHECK(dns_diff_sort(&diff[1], rdata_order));
 
@@ -1778,11 +1781,17 @@ dns_diff_subtract(dns_diff_t diff[2], dns_diff_t *r) {
 		}
 		INSIST(t == 0);
 		/*
-		 * Identical RRs in both databases; skip them both.
+		 * Identical RRs in both databases; skip them both
+		 * if the ttl differs.
 		 */
+		append = ISC_TF(p[0]->ttl != p[1]->ttl);
 		for (i = 0; i < 2; i++) {
 			ISC_LIST_UNLINK(diff[i].tuples, p[i], link);
-			dns_difftuple_free(&p[i]);
+			if (append) {
+				ISC_LIST_APPEND(r->tuples, p[i], link);
+			} else {
+				dns_difftuple_free(&p[i]);
+			}
 		}
 	next: ;
 	}
diff --git a/contrib/bind9/lib/dns/key.c b/contrib/bind9/lib/dns/key.c
index 7abb2d7f6e97..97d970ed5e7a 100644
--- a/contrib/bind9/lib/dns/key.c
+++ b/contrib/bind9/lib/dns/key.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,10 +15,11 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: key.c,v 1.1.4.1 2004/12/09 04:07:18 marka Exp $ */
+/* $Id: key.c,v 1.1.4.3 2005/06/09 23:54:29 marka Exp $ */
 
 #include <config.h>
 
+#include <stddef.h>
 #include <stdlib.h>
 
 #include <isc/region.h>
diff --git a/contrib/bind9/lib/dns/message.c b/contrib/bind9/lib/dns/message.c
index badde6ee71b3..d4b2e1962f99 100644
--- a/contrib/bind9/lib/dns/message.c
+++ b/contrib/bind9/lib/dns/message.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: message.c,v 1.194.2.10.2.17 2004/05/05 01:32:16 marka Exp $ */
+/* $Id: message.c,v 1.194.2.10.2.20 2005/06/07 01:42:23 marka Exp $ */
 
 /***
  *** Imports
@@ -1476,6 +1476,13 @@ getsection(isc_buffer_t *source, dns_message_t *msg, dns_decompress_t *dctx,
 			free_name = ISC_FALSE;
 		}
 
+		if (seen_problem) {
+			if (free_name)
+				isc_mempool_put(msg->namepool, name);
+			if (free_rdataset)
+				isc_mempool_put(msg->rdspool, rdataset);
+			free_name = free_rdataset = ISC_FALSE;
+		}
 		INSIST(free_name == ISC_FALSE);
 		INSIST(free_rdataset == ISC_FALSE);
 	}
@@ -1783,6 +1790,57 @@ dns_message_rendersection(dns_message_t *msg, dns_section_t sectionid,
 	if (msg->reserved == 0 && (options & DNS_MESSAGERENDER_PARTIAL) != 0)
 		partial = ISC_TRUE;
 
+	/*
+	 * Render required glue first.  Set TC if it won't fit.
+	 */
+	name = ISC_LIST_HEAD(*section);
+	if (name != NULL) {
+		rdataset = ISC_LIST_HEAD(name->list);
+		if (rdataset != NULL &&
+		    (rdataset->attributes & DNS_RDATASETATTR_REQUIREDGLUE) != 0 &&
+		    (rdataset->attributes & DNS_RDATASETATTR_RENDERED) == 0) {
+			void *order_arg = msg->order_arg;
+			st = *(msg->buffer);
+			count = 0;
+			if (partial)
+				result = dns_rdataset_towirepartial(rdataset,
+								    name,
+								    msg->cctx,
+								    msg->buffer,
+								    msg->order,
+								    order_arg,
+								    rd_options,
+								    &count,
+								    NULL);
+			else
+				result = dns_rdataset_towiresorted(rdataset,
+								   name,
+								   msg->cctx,
+								   msg->buffer,
+								   msg->order,
+								   order_arg,
+								   rd_options,
+								   &count);
+			total += count;
+			if (partial && result == ISC_R_NOSPACE) {
+				msg->flags |= DNS_MESSAGEFLAG_TC;
+				msg->buffer->length += msg->reserved;
+				msg->counts[sectionid] += total;
+				return (result);
+			}
+			if (result != ISC_R_SUCCESS) {
+				INSIST(st.used < 65536);
+				dns_compress_rollback(msg->cctx,
+						      (isc_uint16_t)st.used);
+				*(msg->buffer) = st;  /* rollback */
+				msg->buffer->length += msg->reserved;
+				msg->counts[sectionid] += total;
+				return (result);
+			}
+			rdataset->attributes |= DNS_RDATASETATTR_RENDERED;
+		}
+	}
+
 	do {
 		name = ISC_LIST_HEAD(*section);
 		if (name == NULL) {
diff --git a/contrib/bind9/lib/dns/name.c b/contrib/bind9/lib/dns/name.c
index 37a5f4e81268..116a56a81867 100644
--- a/contrib/bind9/lib/dns/name.c
+++ b/contrib/bind9/lib/dns/name.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: name.c,v 1.127.2.7.2.11 2004/09/01 05:19:59 marka Exp $ */
+/* $Id: name.c,v 1.127.2.7.2.14 2005/10/14 01:38:48 marka Exp $ */
 
 #include <config.h>
 
@@ -945,9 +945,9 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source,
 	unsigned char *ndata, *label;
 	char *tdata;
 	char c;
-	ft_state state, kind;
-	unsigned int value, count, tbcount, bitlength, maxlength;
-	unsigned int n1, n2, vlen, tlen, nrem, nused, digits, labels, tused;
+	ft_state state;
+	unsigned int value, count;
+	unsigned int n1, n2, tlen, nrem, nused, digits, labels, tused;
 	isc_boolean_t done;
 	unsigned char *offsets;
 	dns_offsets_t odata;
@@ -985,15 +985,10 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source,
 	 */
 	n1 = 0;
 	n2 = 0;
-	vlen = 0;
 	label = NULL;
 	digits = 0;
 	value = 0;
 	count = 0;
-	tbcount = 0;
-	bitlength = 0;
-	maxlength = 0;
-	kind = ft_init;
 
 	/*
 	 * Make 'name' empty in case of failure.
@@ -1051,7 +1046,6 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source,
 				state = ft_initialescape;
 				break;
 			}
-			kind = ft_ordinary;
 			state = ft_ordinary;
 			if (nrem == 0)
 				return (ISC_R_NOSPACE);
@@ -1094,7 +1088,6 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source,
 				 */
 				return (DNS_R_BADLABELTYPE);
 			}
-			kind = ft_ordinary;
 			state = ft_escape;
 			/* FALLTHROUGH */
 		case ft_escape:
@@ -1305,13 +1298,14 @@ dns_name_totext(dns_name_t *name, isc_boolean_t omit_final_dot,
 						trem--;
 						nlen--;
 					} else {
-						char buf[5];
 						if (trem < 4)
 							return (ISC_R_NOSPACE);
-						snprintf(buf, sizeof(buf),
-							 "\\%03u", c);
-						memcpy(tdata, buf, 4);
-						tdata += 4;
+						*tdata++ = 0x5c;
+						*tdata++ = 0x30 +
+							   ((c / 100) % 10);
+						*tdata++ = 0x30 +
+							   ((c / 10) % 10);
+						*tdata++ = 0x30 + (c % 10);
 						trem -= 4;
 						ndata++;
 						nlen--;
diff --git a/contrib/bind9/lib/dns/rbt.c b/contrib/bind9/lib/dns/rbt.c
index cb43858069f5..ecff783724b2 100644
--- a/contrib/bind9/lib/dns/rbt.c
+++ b/contrib/bind9/lib/dns/rbt.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbt.c,v 1.115.2.2.2.11 2004/10/25 01:36:07 marka Exp $ */
+/* $Id: rbt.c,v 1.115.2.2.2.13 2005/06/18 01:03:24 marka Exp $ */
 
 /* Principal Authors: DCL */
 
@@ -2060,7 +2060,10 @@ dns_rbt_deletetreeflat(dns_rbt_t *rbt, unsigned int quantum,
 	if (DATA(node) != NULL && rbt->data_deleter != NULL)
 		rbt->data_deleter(DATA(node), rbt->deleter_arg);
 
-	unhash_node(rbt, node);
+	/*
+	 * Note: we don't call unhash_node() here as we are destroying
+	 * the complete rbt tree. 
+         */
 #if DNS_RBT_USEMAGIC
 	node->magic = 0;
 #endif
diff --git a/contrib/bind9/lib/dns/rbtdb.c b/contrib/bind9/lib/dns/rbtdb.c
index a0e5ab51f311..f399dd17bcea 100644
--- a/contrib/bind9/lib/dns/rbtdb.c
+++ b/contrib/bind9/lib/dns/rbtdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb.c,v 1.168.2.11.2.16 2004/05/23 11:07:23 marka Exp $ */
+/* $Id: rbtdb.c,v 1.168.2.11.2.22 2005/10/14 01:38:48 marka Exp $ */
 
 /*
  * Principal Author: Bob Halley
@@ -97,6 +97,12 @@ typedef isc_uint32_t			rbtdb_rdatatype_t;
 #define RBTDB_RDATATYPE_NCACHEANY \
 		RBTDB_RDATATYPE_VALUE(0, dns_rdatatype_any)
 
+/*
+ * Allow clients with a virtual time of upto 5 minutes in the past to see
+ * records that would have otherwise have expired.
+ */
+#define RBTDB_VIRTUAL 300
+
 struct noqname {
 	dns_name_t name;
 	void *	   nsec;
@@ -413,7 +419,7 @@ free_rbtdb(dns_rbtdb_t *rbtdb, isc_boolean_t log, isc_event_t *event) {
  again:
 	if (rbtdb->tree != NULL) {
 		result = dns_rbt_destroy2(&rbtdb->tree,
-					  (rbtdb->task != NULL) ? 5 : 0);
+					  (rbtdb->task != NULL) ? 1000 : 0);
 		if (result == ISC_R_QUOTA) {
 			INSIST(rbtdb->task != NULL);
 			if (event == NULL)
@@ -2752,10 +2758,9 @@ find_coveringnsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 	isc_result_t result;
 	dns_fixedname_t fname, forigin;
 	dns_name_t *name, *origin;
-	rbtdb_rdatatype_t matchtype, sigmatchtype, nsectype;
+	rbtdb_rdatatype_t matchtype, sigmatchtype;
 
 	matchtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_nsec, 0);
-	nsectype = RBTDB_RDATATYPE_VALUE(0, dns_rdatatype_nsec);
 	sigmatchtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig,
 					     dns_rdatatype_nsec);
 	
@@ -2786,7 +2791,9 @@ find_coveringnsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 				 * node as dirty, so it will get cleaned up 
 				 * later.
 				 */
-				if (node->references == 0) {
+				if (header->ttl > search->now - RBTDB_VIRTUAL)
+					header_prev = header;
+				else if (node->references == 0) {
 					INSIST(header->down == NULL);
 					if (header_prev != NULL)
 						header_prev->next =
@@ -2943,7 +2950,9 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 			 * mark it as stale, and the node as dirty, so it will
 			 * get cleaned up later.
 			 */
-			if (node->references == 0) {
+			if (header->ttl > now - RBTDB_VIRTUAL)
+				header_prev = header;
+			else if (node->references == 0) {
 				INSIST(header->down == NULL);
 				if (header_prev != NULL)
 					header_prev->next = header->next;
@@ -3210,7 +3219,9 @@ cache_findzonecut(dns_db_t *db, dns_name_t *name, unsigned int options,
 			 * mark it as stale, and the node as dirty, so it will
 			 * get cleaned up later.
 			 */
-			if (node->references == 0) {
+			if (header->ttl > now - RBTDB_VIRTUAL)
+				header_prev = header;
+			else if (node->references == 0) {
 				INSIST(header->down == NULL);
 				if (header_prev != NULL)
 					header_prev->next = header->next;
@@ -3398,7 +3409,7 @@ expirenode(dns_db_t *db, dns_dbnode_t *node, isc_stdtime_t now) {
 	LOCK(&rbtdb->node_locks[rbtnode->locknum].lock);
 
 	for (header = rbtnode->data; header != NULL; header = header->next)
-		if (header->ttl <= now) {
+		if (header->ttl <= now - RBTDB_VIRTUAL) {
 			/*
 			 * We don't check if rbtnode->references == 0 and try
 			 * to free like we do in cache_find(), because
@@ -3640,8 +3651,10 @@ cache_findrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 			 * rbtnode->references must be non-zero.  This is so
 			 * because 'node' is an argument to the function.
 			 */
-			header->attributes |= RDATASET_ATTR_STALE;
-			rbtnode->dirty = 1;
+			if (header->ttl <= now - RBTDB_VIRTUAL) {
+				header->attributes |= RDATASET_ATTR_STALE;
+				rbtnode->dirty = 1;
+			}
 		} else if (EXISTS(header)) {
 			if (header->type == matchtype)
 				found = header;
@@ -4344,6 +4357,7 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 	changed = add_changed(rbtdb, rbtversion, rbtnode);
 	if (changed == NULL) {
 		free_rdataset(rbtdb->common.mctx, newheader);
+		UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock);
 		return (ISC_R_NOMEMORY);
 	}
 
@@ -4909,6 +4923,11 @@ dns_rbtdb_create
 	isc_mem_attach(mctx, &rbtdb->common.mctx);
 
 	/*
+	 * Must be initalized before free_rbtdb() is called.
+	 */
+	isc_ondestroy_init(&rbtdb->common.ondest);
+
+	/*
 	 * Make a copy of the origin name.
 	 */
 	result = dns_name_dupwithoffsets(origin, mctx, &rbtdb->common.origin);
@@ -4986,8 +5005,6 @@ dns_rbtdb_create
 	rbtdb->future_version = NULL;
 	ISC_LIST_INIT(rbtdb->open_versions);
 
-	isc_ondestroy_init(&rbtdb->common.ondest);
-
 	rbtdb->common.magic = DNS_DB_MAGIC;
 	rbtdb->common.impmagic = RBTDB_MAGIC;
 
diff --git a/contrib/bind9/lib/dns/rdata.c b/contrib/bind9/lib/dns/rdata.c
index 6d4c098698ab..1b3f2a51c13a 100644
--- a/contrib/bind9/lib/dns/rdata.c
+++ b/contrib/bind9/lib/dns/rdata.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdata.c,v 1.147.2.11.2.16 2004/10/06 05:37:40 marka Exp $ */
+/* $Id: rdata.c,v 1.147.2.11.2.20 2005/07/22 05:27:52 marka Exp $ */
 
 #include <config.h>
 #include <ctype.h>
@@ -986,11 +986,15 @@ txt_totext(isc_region_t *source, isc_buffer_t *target) {
 		if (*sp < 0x20 || *sp >= 0x7f) {
 			if (tl < 4)
 				return (ISC_R_NOSPACE);
-			snprintf(tp, 5, "\\%03u", *sp++);
-			tp += 4;
+			*tp++ = 0x5c;
+			*tp++ = 0x30 + ((*sp / 100) % 10);
+			*tp++ = 0x30 + ((*sp / 10) % 10);
+			*tp++ = 0x30 + (*sp % 10);
+			sp++;
 			tl -= 4;
 			continue;
 		}
+		/* double quote, semi-colon, backslash */
 		if (*sp == 0x22 || *sp == 0x3b || *sp == 0x5c) {
 			if (tl < 2)
 				return (ISC_R_NOSPACE);
@@ -1213,7 +1217,7 @@ name_tobuffer(dns_name_t *name, isc_buffer_t *target) {
 
 static isc_uint32_t
 uint32_fromregion(isc_region_t *region) {
-	unsigned long value;
+	isc_uint32_t value;
 
 	REQUIRE(region->length >= 4);
 	value = region->base[0] << 24;
diff --git a/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c b/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c
index 6943d8243ea7..c9b52c7e78b2 100644
--- a/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c
+++ b/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tsig_250.c,v 1.52.2.1.2.6 2004/03/08 09:04:40 marka Exp $ */
+/* $Id: tsig_250.c,v 1.52.2.1.2.8 2005/03/20 22:34:01 marka Exp $ */
 
 /* Reviewed: Thu Mar 16 13:39:43 PST 2000 by gson */
 
@@ -162,8 +162,10 @@ totext_any_tsig(ARGS_TOTEXT) {
 	 */
 	sigtime = ((isc_uint64_t)sr.base[0] << 40) |
 		  ((isc_uint64_t)sr.base[1] << 32) |
-		  (sr.base[2] << 24) | (sr.base[3] << 16) |
-		  (sr.base[4] << 8) | sr.base[5];
+		  ((isc_uint64_t)sr.base[2] << 24) |
+		  ((isc_uint64_t)sr.base[3] << 16) |
+		  ((isc_uint64_t)sr.base[4] << 8) |
+		  (isc_uint64_t)sr.base[5];
 	isc_region_consume(&sr, 6);
 	bufp = &buf[sizeof(buf) - 1];
 	*bufp-- = 0;
@@ -457,8 +459,10 @@ tostruct_any_tsig(ARGS_TOSTRUCT) {
 	INSIST(sr.length >= 6);
 	tsig->timesigned = ((isc_uint64_t)sr.base[0] << 40) |
 			   ((isc_uint64_t)sr.base[1] << 32) |
-			   (sr.base[2] << 24) | (sr.base[3] << 16) |
-			   (sr.base[4] << 8) | sr.base[5];
+			   ((isc_uint64_t)sr.base[2] << 24) |
+			   ((isc_uint64_t)sr.base[3] << 16) |
+			   ((isc_uint64_t)sr.base[4] << 8) |
+			   (isc_uint64_t)sr.base[5];
 	isc_region_consume(&sr, 6);
 
 	/*
diff --git a/contrib/bind9/lib/dns/rdata/generic/ds_43.c b/contrib/bind9/lib/dns/rdata/generic/ds_43.c
index 538f86571d80..0206b6f06c22 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ds_43.c
+++ b/contrib/bind9/lib/dns/rdata/generic/ds_43.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ds_43.c,v 1.6.2.2 2004/03/16 12:38:14 marka Exp $ */
+/* $Id: ds_43.c,v 1.6.2.4 2005/09/06 07:29:31 marka Exp $ */
 
 /* draft-ietf-dnsext-delegation-signer-05.txt */
 
@@ -28,6 +28,7 @@
 static inline isc_result_t
 fromtext_ds(ARGS_FROMTEXT) {
 	isc_token_t token;
+	unsigned char c;
 
 	REQUIRE(type == 43);
 
@@ -49,11 +50,10 @@ fromtext_ds(ARGS_FROMTEXT) {
 	/*
 	 * Algorithm.
 	 */
-	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
 				      ISC_FALSE));
-	if (token.value.as_ulong > 0xffU)
-		RETTOK(ISC_R_RANGE);
-	RETERR(uint8_tobuffer(token.value.as_ulong, target));
+	RETTOK(dns_secalg_fromtext(&c, &token.value.as_textregion));
+	RETERR(mem_tobuffer(target, &c, 1));
 
 	/*
 	 * Digest type.
diff --git a/contrib/bind9/lib/dns/rdata/generic/rt_21.c b/contrib/bind9/lib/dns/rdata/generic/rt_21.c
index 0f568e3bdfde..daf9756ff98b 100644
--- a/contrib/bind9/lib/dns/rdata/generic/rt_21.c
+++ b/contrib/bind9/lib/dns/rdata/generic/rt_21.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rt_21.c,v 1.37.2.1.2.3 2004/03/06 08:14:11 marka Exp $ */
+/* $Id: rt_21.c,v 1.37.2.1.2.5 2005/03/17 03:58:31 marka Exp $ */
 
 /* reviewed: Thu Mar 16 15:02:31 PST 2000 by brister */
 
@@ -300,7 +300,7 @@ checknames_rt(ARGS_CHECKNAMES) {
 	isc_region_consume(&region, 2);
 	dns_name_init(&name, NULL);
 	dns_name_fromregion(&name, &region);
-	if (dns_name_ishostname(&name, ISC_FALSE)) {
+	if (!dns_name_ishostname(&name, ISC_FALSE)) {
 		if (bad != NULL)
 			dns_name_clone(&name, bad);
 		return (ISC_FALSE);
diff --git a/contrib/bind9/lib/dns/resolver.c b/contrib/bind9/lib/dns/resolver.c
index 790a2f41686f..6f803eb192f4 100644
--- a/contrib/bind9/lib/dns/resolver.c
+++ b/contrib/bind9/lib/dns/resolver.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.c,v 1.218.2.18.4.51 2005/02/08 23:59:44 marka Exp $ */
+/* $Id: resolver.c,v 1.218.2.18.4.56 2005/10/14 01:38:48 marka Exp $ */
 
 #include <config.h>
 
@@ -244,6 +244,11 @@ struct fetchctx {
 #define TRIEDFIND(f)		(((f)->attributes & FCTX_ATTR_TRIEDFIND) != 0)
 #define TRIEDALT(f)		(((f)->attributes & FCTX_ATTR_TRIEDALT) != 0)
 
+typedef struct {
+	dns_adbaddrinfo_t *		addrinfo;
+	fetchctx_t *			fctx;
+} dns_valarg_t;
+
 struct dns_fetch {
 	unsigned int			magic;
 	fetchctx_t *			private;
@@ -342,6 +347,35 @@ static isc_result_t ncache_adderesult(dns_message_t *message,
 				      isc_stdtime_t now, dns_ttl_t maxttl,
 				      dns_rdataset_t *ardataset,
 				      isc_result_t *eresultp);
+static void validated(isc_task_t *task, isc_event_t *event); 
+
+static isc_result_t
+valcreate(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, dns_name_t *name,
+	  dns_rdatatype_t type, dns_rdataset_t *rdataset,
+	  dns_rdataset_t *sigrdataset, unsigned int valoptions,
+	  isc_task_t *task)
+{
+	dns_validator_t *validator = NULL;
+	dns_valarg_t *valarg;
+	isc_result_t result;
+
+	valarg = isc_mem_get(fctx->res->mctx, sizeof(*valarg));
+	if (valarg == NULL)
+		return (ISC_R_NOMEMORY);
+
+	valarg->fctx = fctx;
+	valarg->addrinfo = addrinfo;
+
+	result = dns_validator_create(fctx->res->view, name, type, rdataset,
+				      sigrdataset, fctx->rmessage,
+				      valoptions, task, validated, valarg,
+				      &validator);
+	if (result == ISC_R_SUCCESS)
+		ISC_LIST_APPEND(fctx->validators, validator, link);
+	else
+		isc_mem_put(fctx->res->mctx, valarg, sizeof(*valarg));
+	return (result);
+}
 
 static isc_boolean_t
 fix_mustbedelegationornxdomain(dns_message_t *message, fetchctx_t *fctx) {
@@ -1424,6 +1458,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 		case ISC_R_CONNREFUSED:
 		case ISC_R_NOPERM:
 		case ISC_R_ADDRNOTAVAIL:
+		case ISC_R_CONNECTIONRESET:
 			/*
 			 * No route to remote.
 			 */
@@ -1855,7 +1890,6 @@ fctx_getaddresses(fetchctx_t *fctx) {
 	isc_boolean_t pruned, all_bad;
 	dns_rdata_ns_t ns;
 	isc_boolean_t need_alternate = ISC_FALSE;
-	isc_boolean_t unshared;
 
 	FCTXTRACE("getaddresses");
 
@@ -1871,7 +1905,6 @@ fctx_getaddresses(fetchctx_t *fctx) {
 	res = fctx->res;
 	pruned = ISC_FALSE;
 	stdoptions = 0;		/* Keep compiler happy. */
-	unshared = ISC_TF((fctx->options | DNS_FETCHOPT_UNSHARED) != 0);
 
 	/*
 	 * Forwarders.
@@ -2668,7 +2701,7 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 	isc_result_t result;
 	isc_result_t iresult;
 	isc_interval_t interval;
-	dns_fixedname_t qdomain;
+	dns_fixedname_t fixed;
 	unsigned int findoptions = 0;
 	char buf[DNS_NAME_FORMATSIZE + DNS_RDATATYPE_FORMATSIZE];
 	char typebuf[DNS_RDATATYPE_FORMATSIZE];
@@ -2747,8 +2780,10 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 			dns_name_getlabelsequence(name, 1, labels - 1, &suffix);
 			name = &suffix;
 		}
-		result = dns_fwdtable_find(fctx->res->view->fwdtable, name,
-					   &forwarders);
+		dns_fixedname_init(&fixed);
+		domain = dns_fixedname_name(&fixed);
+		result = dns_fwdtable_find2(fctx->res->view->fwdtable, name,
+					    domain, &forwarders);
 		if (result == ISC_R_SUCCESS)
 			fctx->fwdpolicy = forwarders->fwdpolicy;
 
@@ -2760,27 +2795,22 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 			 */
 			if (dns_rdatatype_atparent(type))
 				findoptions |= DNS_DBFIND_NOEXACT;
-			dns_fixedname_init(&qdomain);
-			result = dns_view_findzonecut(res->view, name,
-					      dns_fixedname_name(&qdomain), 0,
-						      findoptions, ISC_TRUE,
+			result = dns_view_findzonecut(res->view, name, domain,
+						      0, findoptions, ISC_TRUE,
 						      &fctx->nameservers,
 						      NULL);
 			if (result != ISC_R_SUCCESS)
 				goto cleanup_name;
-			result = dns_name_dup(dns_fixedname_name(&qdomain),
-					      res->mctx, &fctx->domain);
+			result = dns_name_dup(domain, res->mctx, &fctx->domain);
 			if (result != ISC_R_SUCCESS) {
 				dns_rdataset_disassociate(&fctx->nameservers);
 				goto cleanup_name;
 			}
 		} else {
 			/*
-			 * We're in forward-only mode.  Set the query domain
-			 * to ".".
+			 * We're in forward-only mode.  Set the query domain.
 			 */
-			result = dns_name_dup(dns_rootname, res->mctx,
-					      &fctx->domain);
+			result = dns_name_dup(domain, res->mctx, &fctx->domain);
 			if (result != ISC_R_SUCCESS)
 				goto cleanup_name;
 		}
@@ -3090,11 +3120,15 @@ validated(isc_task_t *task, isc_event_t *event) {
 	dns_name_t *name;
 	dns_rdataset_t *rdataset;
 	dns_rdataset_t *sigrdataset;
+	dns_valarg_t *valarg;
+	dns_adbaddrinfo_t *addrinfo;
 
 	UNUSED(task); /* for now */
 
 	REQUIRE(event->ev_type == DNS_EVENT_VALIDATORDONE);
-	fctx = event->ev_arg;
+	valarg = event->ev_arg;
+	fctx = valarg->fctx;
+	addrinfo = valarg->addrinfo;
 	REQUIRE(VALID_FCTX(fctx));
 	REQUIRE(!ISC_LIST_EMPTY(fctx->validators));
 
@@ -3109,6 +3143,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 	 * destroy the fctx if necessary.
 	 */
 	dns_validator_destroy(&vevent->validator);
+	isc_mem_put(fctx->res->mctx, valarg, sizeof(*valarg));
 
 	negative = ISC_TF(vevent->rdataset == NULL);
 
@@ -3166,21 +3201,27 @@ validated(isc_task_t *task, isc_event_t *event) {
 
 	if (vevent->result != ISC_R_SUCCESS) {
 		FCTXTRACE("validation failed");
-		if (vevent->rdataset != NULL) {
+		result = ISC_R_NOTFOUND;
+		if (vevent->rdataset != NULL)
 			result = dns_db_findnode(fctx->cache, vevent->name,
 						 ISC_TRUE, &node);
-			if (result != ISC_R_SUCCESS)
-				goto noanswer_response;
+		if (result == ISC_R_SUCCESS)
 			(void)dns_db_deleterdataset(fctx->cache, node, NULL,
 						    vevent->type, 0);
-			if (vevent->sigrdataset != NULL)
-				(void)dns_db_deleterdataset(fctx->cache,
-							    node, NULL,
-							    dns_rdatatype_rrsig,
-							    vevent->type);
-		}
+		if (result == ISC_R_SUCCESS && vevent->sigrdataset != NULL)
+			(void)dns_db_deleterdataset(fctx->cache, node, NULL,
+						    dns_rdatatype_rrsig,
+						    vevent->type);
+		if (result == ISC_R_SUCCESS)
+			dns_db_detachnode(fctx->cache, &node);
 		result = vevent->result;
-		goto noanswer_response;
+		add_bad(fctx, &addrinfo->sockaddr, result);
+		isc_event_free(&event);
+		if (sentresponse)
+			fctx_done(fctx, result);
+		else
+			fctx_try(fctx);
+		return;
 	}
 
 	isc_stdtime_get(&now);
@@ -3350,7 +3391,8 @@ validated(isc_task_t *task, isc_event_t *event) {
 }
 
 static inline isc_result_t
-cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
+cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
+	   isc_stdtime_t now) {
 	dns_rdataset_t *rdataset, *sigrdataset;
 	dns_rdataset_t *addedrdataset, *ardataset, *asigrdataset;
 	dns_rdataset_t *valrdataset = NULL, *valsigrdataset = NULL;
@@ -3363,8 +3405,8 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 	dns_fetchevent_t *event;
 	unsigned int options;
 	isc_task_t *task;
-	dns_validator_t *validator;
 	isc_boolean_t fail;
+	unsigned int valoptions = 0;
 
 	/*
 	 * The appropriate bucket lock must be held.
@@ -3385,8 +3427,10 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
-	if (res->view->dlv != NULL)
+	if (!secure_domain && res->view->dlv != NULL) {
+		valoptions = DNS_VALIDATOR_DLV;
 		secure_domain = ISC_TRUE;
+	}
 
 	if ((fctx->options & DNS_FETCHOPT_NOVALIDATE) != 0)
 		need_validation = ISC_FALSE;
@@ -3437,7 +3481,7 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 	/*
 	 * Cache or validate each cacheable rdataset.
 	 */
-	fail = (fctx->res->options & DNS_RESOLVER_CHECKNAMESFAIL) != 0;
+	fail = ISC_TF((fctx->res->options & DNS_RESOLVER_CHECKNAMESFAIL) != 0);
 	for (rdataset = ISC_LIST_HEAD(name->list);
 	     rdataset != NULL;
 	     rdataset = ISC_LIST_NEXT(rdataset, link)) {
@@ -3569,23 +3613,11 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 					 * having to remember which
 					 * rdatasets needed validation.
 					 */
-					validator = NULL;
-					result = dns_validator_create(
-						res->view,
-						name,
-						rdataset->type,
-						rdataset,
-						sigrdataset,
-						fctx->rmessage,
-						0,
-						task,
-						validated,
-						fctx,
-						&validator);
-					if (result == ISC_R_SUCCESS)
-						ISC_LIST_APPEND(
-							fctx->validators,
-							validator, link);
+					result = valcreate(fctx, addrinfo,
+							   name, rdataset->type,
+							   rdataset,
+							   sigrdataset,
+							   valoptions, task);
 				}
 			} else if (CHAINING(rdataset)) {
 				if (rdataset->type == dns_rdatatype_cname)
@@ -3660,22 +3692,10 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 		}
 	}
 
-	if (valrdataset != NULL) {
-		validator = NULL;
-		result = dns_validator_create(res->view,
-					      name,
-					      fctx->type,
-					      valrdataset,
-					      valsigrdataset,
-					      fctx->rmessage,
-					      0,
-					      task,
-					      validated,
-					      fctx,
-					      &validator);
-		if (result == ISC_R_SUCCESS)
-			ISC_LIST_APPEND(fctx->validators, validator, link);
-	}
+	if (valrdataset != NULL)
+		result = valcreate(fctx, addrinfo, name, fctx->type,
+				   valrdataset, valsigrdataset, valoptions,
+				    task);
 
 	if (result == ISC_R_SUCCESS && have_answer) {
 		fctx->attributes |= FCTX_ATTR_HAVEANSWER;
@@ -3695,7 +3715,8 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 }
 
 static inline isc_result_t
-cache_message(fetchctx_t *fctx, isc_stdtime_t now) {
+cache_message(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_stdtime_t now)
+{
 	isc_result_t result;
 	dns_section_t section;
 	dns_name_t *name;
@@ -3715,7 +3736,7 @@ cache_message(fetchctx_t *fctx, isc_stdtime_t now) {
 			dns_message_currentname(fctx->rmessage, section,
 						&name);
 			if ((name->attributes & DNS_NAMEATTR_CACHE) != 0) {
-				result = cache_name(fctx, name, now);
+				result = cache_name(fctx, name, addrinfo, now);
 				if (result != ISC_R_SUCCESS)
 					break;
 			}
@@ -3783,7 +3804,9 @@ ncache_adderesult(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 }
 
 static inline isc_result_t
-ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) {
+ncache_message(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
+	       dns_rdatatype_t covers, isc_stdtime_t now)
+{
 	isc_result_t result, eresult;
 	dns_name_t *name;
 	dns_resolver_t *res;
@@ -3794,6 +3817,7 @@ ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) {
 	dns_name_t *aname;
 	dns_fetchevent_t *event;
 	isc_uint32_t ttl;
+	unsigned int valoptions = 0;
 
 	FCTXTRACE("ncache_message");
 
@@ -3820,8 +3844,10 @@ ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) {
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
-	if (res->view->dlv != NULL)
+	if (!secure_domain && res->view->dlv != NULL) {
+		valoptions = DNS_VALIDATOR_DLV;
 		secure_domain = ISC_TRUE;
+	}
 
 	if ((fctx->options & DNS_FETCHOPT_NOVALIDATE) != 0)
 		need_validation = ISC_FALSE;
@@ -3858,23 +3884,15 @@ ncache_message(fetchctx_t *fctx, dns_rdatatype_t covers, isc_stdtime_t now) {
 		/*
 		 * Do negative response validation.
 		 */
-		dns_validator_t *validator = NULL;
-		isc_task_t *task = res->buckets[fctx->bucketnum].task;
-
-		result = dns_validator_create(res->view, name, fctx->type,
-					      NULL, NULL,
-					      fctx->rmessage, 0, task,
-					      validated, fctx,
-					      &validator);
-		if (result != ISC_R_SUCCESS)
-			return (result);
-		ISC_LIST_APPEND(fctx->validators, validator, link);
+		result = valcreate(fctx, addrinfo, name, fctx->type,
+				   NULL, NULL, valoptions,
+				   res->buckets[fctx->bucketnum].task);
 		/*
 		 * If validation is necessary, return now.  Otherwise continue
 		 * to process the message, letting the validation complete
 		 * in its own good time.
 		 */
-		return (ISC_R_SUCCESS);
+		return (result);
 	}
 
 	LOCK(&res->buckets[fctx->bucketnum].lock);
@@ -4992,6 +5010,43 @@ checknames(dns_message_t *message) {
 }
 
 static void
+log_packet(dns_message_t *message, int level, isc_mem_t *mctx) {
+	isc_buffer_t buffer;
+	char *buf = NULL;
+	int len = 1024;
+	isc_result_t result;
+
+	if (! isc_log_wouldlog(dns_lctx, level))
+		return;
+
+	/*
+	 * Note that these are multiline debug messages.  We want a newline
+	 * to appear in the log after each message.
+	 */
+
+	do {
+		buf = isc_mem_get(mctx, len);
+		if (buf == NULL)
+			break;
+		isc_buffer_init(&buffer, buf, len);
+		result = dns_message_totext(message, &dns_master_style_debug,
+					    0, &buffer);
+		if (result == ISC_R_NOSPACE) {
+			isc_mem_put(mctx, buf, len);
+			len += 1024;
+		} else if (result == ISC_R_SUCCESS)
+			isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER,
+				      DNS_LOGMODULE_RESOLVER, level,
+				      "received packet:\n%.*s",
+				      (int)isc_buffer_usedlength(&buffer),
+				      buf);
+	} while (result == ISC_R_NOSPACE);
+
+	if (buf != NULL)
+		isc_mem_put(mctx, buf, len);
+}
+
+static void
 resquery_response(isc_task_t *task, isc_event_t *event) {
 	isc_result_t result = ISC_R_SUCCESS;
 	resquery_t *query = event->ev_arg;
@@ -5160,6 +5215,11 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	}
 
 	/*
+	 * Log the incoming packet.
+	 */
+	log_packet(message, ISC_LOG_DEBUG(10), fctx->res->mctx);
+
+	/*
 	 * If the message is signed, check the signature.  If not, this
 	 * returns success anyway.
 	 */
@@ -5427,7 +5487,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	 * work to be queued to the DNSSEC validator.
 	 */
 	if (WANTCACHE(fctx)) {
-		result = cache_message(fctx, now);
+		result = cache_message(fctx, query->addrinfo, now);
 		if (result != ISC_R_SUCCESS)
 			goto done;
 	}
@@ -5446,7 +5506,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		/*
 		 * Cache any negative cache entries in the message.
 		 */
-		result = ncache_message(fctx, covers, now);
+		result = ncache_message(fctx, query->addrinfo, covers, now);
 	}
 
  done:
diff --git a/contrib/bind9/lib/dns/tkey.c b/contrib/bind9/lib/dns/tkey.c
index dc49a337ad3d..43c8db0e57c8 100644
--- a/contrib/bind9/lib/dns/tkey.c
+++ b/contrib/bind9/lib/dns/tkey.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +16,7 @@
  */
 
 /*
- * $Id: tkey.c,v 1.71.2.1.10.5 2004/06/11 00:30:54 marka Exp $
+ * $Id: tkey.c,v 1.71.2.1.10.7 2005/06/12 00:02:26 marka Exp $
  */
 
 #include <config.h>
@@ -356,7 +356,7 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name,
 
 	isc_buffer_init(&secret, secretdata, sizeof(secretdata));
 
-	randomdata = isc_mem_get(tctx->mctx, TKEY_RANDOM_AMOUNT);
+	randomdata = isc_mem_get(tkeyout->mctx, TKEY_RANDOM_AMOUNT);
 	if (randomdata == NULL)
 		goto failure;
 
@@ -397,8 +397,8 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name,
 		isc_buffer_free(&shared);
 	if (pubkey != NULL)
 		dst_key_free(&pubkey);
-	if (randomdata == NULL)
-		isc_mem_put(tctx->mctx, randomdata, TKEY_RANDOM_AMOUNT);
+	if (randomdata != NULL)
+		isc_mem_put(tkeyout->mctx, randomdata, TKEY_RANDOM_AMOUNT);
 	return (result);
 }
 
diff --git a/contrib/bind9/lib/dns/tsig.c b/contrib/bind9/lib/dns/tsig.c
index fb1ac823eace..6a8d774a2702 100644
--- a/contrib/bind9/lib/dns/tsig.c
+++ b/contrib/bind9/lib/dns/tsig.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +16,7 @@
  */
 
 /*
- * $Id: tsig.c,v 1.112.2.3.8.4 2004/03/08 09:04:32 marka Exp $
+ * $Id: tsig.c,v 1.112.2.3.8.6 2005/03/17 03:58:31 marka Exp $
  */
 
 #include <config.h>
@@ -167,7 +167,7 @@ dns_tsigkey_createfromkey(dns_name_t *name, dns_name_t *algorithm,
 			goto cleanup_name;
 		}
 	} else {
-		if (key != NULL) {
+		if (dstkey != NULL) {
 			ret = DNS_R_BADALG;
 			goto cleanup_name;
 		}
diff --git a/contrib/bind9/lib/dns/validator.c b/contrib/bind9/lib/dns/validator.c
index 069b9c228f92..a62db3413768 100644
--- a/contrib/bind9/lib/dns/validator.c
+++ b/contrib/bind9/lib/dns/validator.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.c,v 1.91.2.5.8.15 2005/02/09 05:13:02 marka Exp $ */
+/* $Id: validator.c,v 1.91.2.5.8.21 2005/11/02 02:07:47 marka Exp $ */
 
 #include <config.h>
 
@@ -51,9 +51,7 @@
 #define VALATTR_TRIEDVERIFY		0x0004
 #define VALATTR_NEGATIVE		0x0008
 #define VALATTR_INSECURITY		0x0010
-#define VALATTR_DLV			0x0020
-#define VALATTR_DLVTRIED		0x0040
-#define VALATTR_DLVSEPTRIED		0x0080
+#define VALATTR_DLVTRIED		0x0020
 
 #define VALATTR_NEEDNOQNAME		0x0100
 #define VALATTR_NEEDNOWILDCARD		0x0200
@@ -63,13 +61,10 @@
 #define VALATTR_FOUNDNOWILDCARD		0x2000
 #define VALATTR_FOUNDNODATA		0x4000
 
-
 #define NEEDNODATA(val) ((val->attributes & VALATTR_NEEDNODATA) != 0)
 #define NEEDNOQNAME(val) ((val->attributes & VALATTR_NEEDNOQNAME) != 0)
 #define NEEDNOWILDCARD(val) ((val->attributes & VALATTR_NEEDNOWILDCARD) != 0)
-#define DLV(val) ((val->attributes & VALATTR_DLV) != 0)
 #define DLVTRIED(val) ((val->attributes & VALATTR_DLVTRIED) != 0)
-#define DLVSEPTRIED(val) ((val->attributes & VALATTR_DLVSEPTRIED) != 0)
 
 #define SHUTDOWN(v)		(((v)->attributes & VALATTR_SHUTDOWN) != 0)
 
@@ -110,8 +105,20 @@ static isc_result_t
 dlv_validatezonekey(dns_validator_t *val);
 
 static isc_result_t
+dlv_validator_start(dns_validator_t *val);
+
+static isc_result_t
 finddlvsep(dns_validator_t *val, isc_boolean_t resume);
 
+static inline void
+markanswer(dns_validator_t *val) {
+	validator_log(val, ISC_LOG_DEBUG(3), "marking as answer");
+	if (val->event->rdataset)
+		val->event->rdataset->trust = dns_trust_answer;
+	if (val->event->sigrdataset)
+		val->event->sigrdataset->trust = dns_trust_answer;
+}
+
 static void
 validator_done(dns_validator_t *val, isc_result_t result) {
 	isc_task_t *task;
@@ -219,6 +226,13 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
 	rdataset = &val->frdataset;
 	eresult = devent->result;
 
+	/* Free resources which are not of interest. */
+	if (devent->node != NULL)
+		dns_db_detachnode(devent->db, &devent->node);
+	if (devent->db != NULL)
+		dns_db_detach(&devent->db);
+	if (dns_rdataset_isassociated(&val->fsigrdataset))
+		dns_rdataset_disassociate(&val->fsigrdataset);
 	isc_event_free(&event);
 	dns_resolver_destroyfetch(&val->fetch);
 
@@ -271,6 +285,13 @@ dsfetched(isc_task_t *task, isc_event_t *event) {
 	rdataset = &val->frdataset;
 	eresult = devent->result;
 
+	/* Free resources which are not of interest. */
+	if (devent->node != NULL)
+		dns_db_detachnode(devent->db, &devent->node);
+	if (devent->db != NULL)
+		dns_db_detach(&devent->db);
+	if (dns_rdataset_isassociated(&val->fsigrdataset))
+		dns_rdataset_disassociate(&val->fsigrdataset);
 	isc_event_free(&event);
 	dns_resolver_destroyfetch(&val->fetch);
 
@@ -285,18 +306,6 @@ dsfetched(isc_task_t *task, isc_event_t *event) {
 		result = validatezonekey(val);
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
-	} else if (val->view->dlv != NULL && !DLVTRIED(val) &&
-		   (eresult == DNS_R_NXRRSET ||
-		    eresult == DNS_R_NCACHENXRRSET) &&
-		   !dns_name_issubdomain(val->event->name,
-					 val->view->dlv))
-	{
-		validator_log(val, ISC_LOG_DEBUG(2),
-			      "no DS record: looking for DLV");
-
-		result = dlv_validatezonekey(val);
-		if (result != DNS_R_WAIT)
-			validator_done(val, result);
 	} else if (eresult == DNS_R_NXRRSET ||
 		   eresult == DNS_R_NCACHENXRRSET)
 	{
@@ -328,7 +337,6 @@ static void
 dsfetched2(isc_task_t *task, isc_event_t *event) {
 	dns_fetchevent_t *devent;
 	dns_validator_t *val;
-	dns_rdataset_t *rdataset;
 	dns_name_t *tname;
 	isc_boolean_t want_destroy;
 	isc_result_t result;
@@ -338,9 +346,15 @@ dsfetched2(isc_task_t *task, isc_event_t *event) {
 	INSIST(event->ev_type == DNS_EVENT_FETCHDONE);
 	devent = (dns_fetchevent_t *)event;
 	val = devent->ev_arg;
-	rdataset = &val->frdataset;
 	eresult = devent->result;
 
+	/* Free resources which are not of interest. */
+	if (devent->node != NULL)
+		dns_db_detachnode(devent->db, &devent->node);
+	if (devent->db != NULL)
+		dns_db_detach(&devent->db);
+	if (dns_rdataset_isassociated(&val->fsigrdataset))
+		dns_rdataset_disassociate(&val->fsigrdataset);
 	dns_resolver_destroyfetch(&val->fetch);
 
 	INSIST(val->event != NULL);
@@ -358,7 +372,7 @@ dsfetched2(isc_task_t *task, isc_event_t *event) {
 					      "must be secure failure");
 				validator_done(val, DNS_R_MUSTBESECURE);
 			} else {
-				val->event->rdataset->trust = dns_trust_answer;
+				markanswer(val);
 				validator_done(val, ISC_R_SUCCESS);
 			}
 		} else {
@@ -553,7 +567,7 @@ nsecnoexistnodata(dns_validator_t *val, dns_name_t* name, dns_name_t *nsecname,
 			      "nsec proves name exists (owner) data=%d",
 			      *data);
 		return (ISC_R_SUCCESS);
-	} 
+	}
 
 	if (relation == dns_namereln_subdomain &&
 	    dns_nsec_typepresent(&rdata, dns_rdatatype_ns) &&
@@ -627,7 +641,7 @@ static void
 authvalidated(isc_task_t *task, isc_event_t *event) {
 	dns_validatorevent_t *devent;
 	dns_validator_t *val;
-	dns_rdataset_t *rdataset, *sigrdataset;
+	dns_rdataset_t *rdataset;
 	isc_boolean_t want_destroy;
 	isc_result_t result;
 	isc_boolean_t exists, data;
@@ -637,7 +651,6 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
 
 	devent = (dns_validatorevent_t *)event;
 	rdataset = devent->rdataset;
-	sigrdataset = devent->sigrdataset;
 	val = devent->ev_arg;
 	result = devent->result;
 	dns_validator_destroy(&val->subvalidator);
@@ -916,8 +929,10 @@ create_validator(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type,
 				      rdataset, sigrdataset, NULL, 0,
 				      val->task, action, val,
 				      &val->subvalidator);
-	if (result == ISC_R_SUCCESS)
+	if (result == ISC_R_SUCCESS) {
 		val->subvalidator->parent = val;
+		val->subvalidator->depth = val->depth + 1;
+	}
 	return (result);
 }
 
@@ -1252,10 +1267,7 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
 					      "must be secure failure");
 				return (DNS_R_MUSTBESECURE);
 			}
-			event->rdataset->trust = dns_trust_answer;
-			event->sigrdataset->trust = dns_trust_answer;
-			validator_log(val, ISC_LOG_DEBUG(3),
-				      "marking as answer");
+			markanswer(val);
 			return (ISC_R_SUCCESS);
 		}
 
@@ -1344,110 +1356,9 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
 	return (DNS_R_NOVALIDSIG);
 }
 
-
-static void
-dlv_validated(isc_task_t *task, isc_event_t *event) {
-	dns_validatorevent_t *devent;
-	dns_validator_t *val;
-	isc_boolean_t want_destroy;
-	isc_result_t result;
-	isc_result_t eresult;
-
-	UNUSED(task);
-	INSIST(event->ev_type == DNS_EVENT_VALIDATORDONE);
-
-	devent = (dns_validatorevent_t *)event;
-	val = devent->ev_arg;
-	eresult = devent->result;
-
-	isc_event_free(&event);
-	dns_validator_destroy(&val->subvalidator);
-
-	INSIST(val->event != NULL);
-
-	validator_log(val, ISC_LOG_DEBUG(3), "in dsvalidated");
-	LOCK(&val->lock);
-	if (eresult == ISC_R_SUCCESS) {
-		validator_log(val, ISC_LOG_DEBUG(3),
-			      "dlv with trust %d", val->frdataset.trust);
-		if ((val->attributes & VALATTR_INSECURITY) != 0)
-			result = proveunsecure(val, ISC_TRUE);
-		else
-			result = validatezonekey(val);
-		if (result != DNS_R_WAIT)
-			validator_done(val, result);
-	} else {
-		validator_log(val, ISC_LOG_DEBUG(3),
-			      "dlv_validated: got %s",
-			      isc_result_totext(eresult));
-		validator_done(val, eresult);
-	}
-	want_destroy = exit_check(val);
-	UNLOCK(&val->lock);
-	if (want_destroy)
-		destroy(val);
-}
-
-static void
-dlv_fetched(isc_task_t *task, isc_event_t *event) {
-	dns_fetchevent_t *devent;
-	dns_validator_t *val;
-	dns_rdataset_t *rdataset;
-	isc_boolean_t want_destroy;
-	isc_result_t result;
-	isc_result_t eresult;
-
-	UNUSED(task);
-	INSIST(event->ev_type == DNS_EVENT_FETCHDONE);
-	devent = (dns_fetchevent_t *)event;
-	val = devent->ev_arg;
-	rdataset = &val->frdataset;
-	eresult = devent->result;
-
-	isc_event_free(&event);
-	dns_resolver_destroyfetch(&val->fetch);
-
-	INSIST(val->event != NULL);
-
-	validator_log(val, ISC_LOG_DEBUG(3), "in dlv_fetched");
-	LOCK(&val->lock);
-	if (eresult == ISC_R_SUCCESS) {
-		validator_log(val, ISC_LOG_DEBUG(3),
-			      "dlv set with trust %d", rdataset->trust);
-		val->dlv = &val->frdataset;
-		result = dlv_validatezonekey(val);
-		if (result != DNS_R_WAIT)
-			validator_done(val, result);
-	} else if (eresult == DNS_R_NXRRSET ||
-		   eresult == DNS_R_NCACHENXRRSET)
-	{
-		validator_log(val, ISC_LOG_DEBUG(3),
-			      "falling back to insecurity proof");
-		val->attributes |= VALATTR_INSECURITY;
-		result = proveunsecure(val, ISC_FALSE);
-		if (result != DNS_R_WAIT)
-			validator_done(val, result);
-	} else {
-		validator_log(val, ISC_LOG_DEBUG(3),
-			      "dlv_fetched: got %s",
-			      isc_result_totext(eresult));
-		if (eresult == ISC_R_CANCELED)
-			validator_done(val, eresult);
-		else
-			validator_done(val, DNS_R_NOVALIDDS);
-	}
-	want_destroy = exit_check(val);
-	UNLOCK(&val->lock);
-	if (want_destroy)
-		destroy(val);
-}
-
 static isc_result_t
 dlv_validatezonekey(dns_validator_t *val) {
-	dns_fixedname_t fixed;
 	dns_keytag_t keytag;
-	dns_name_t *name;
-	dns_name_t tname;
 	dns_rdata_dlv_t dlv;
 	dns_rdata_dnskey_t key;
 	dns_rdata_rrsig_t sig;
@@ -1460,91 +1371,8 @@ dlv_validatezonekey(dns_validator_t *val) {
 	isc_boolean_t supported_algorithm;
 	isc_result_t result;
 	unsigned char dsbuf[DNS_DS_BUFFERSIZE];
-	unsigned int labels;
-
-	val->attributes |= VALATTR_DLVTRIED;
-
-	dns_name_init(&tname, NULL);
-	dns_fixedname_init(&fixed);
-	name = dns_fixedname_name(&fixed);
-	labels = dns_name_countlabels(val->event->name);
-	dns_name_getlabelsequence(val->event->name, 0, labels - 1, &tname);
-	result = dns_name_concatenate(&tname, val->view->dlv, name, NULL);
-	if (result != ISC_R_SUCCESS) {
-		validator_log(val, ISC_LOG_DEBUG(2),
-			      "DLV concatenate failed");
-		return (DNS_R_NOVALIDSIG);
-	}
-	if (val->dlv == NULL) {
-		result = view_find(val, name, dns_rdatatype_dlv);
-		if (result == ISC_R_SUCCESS) {
-			/*
-			 * We have DLV records.
-			 */
-			val->dsset = &val->frdataset;
-			if (val->frdataset.trust == dns_trust_pending &&
-			    dns_rdataset_isassociated(&val->fsigrdataset))
-			{
-				result = create_validator(val,
-							  val->event->name,
-							  dns_rdatatype_ds,
-							  &val->frdataset,
-							  &val->fsigrdataset,
-							  dlv_validated,
-							  "dlv_validatezonekey");
-				if (result != ISC_R_SUCCESS)
-					return (result);
-				return (DNS_R_WAIT);
-			} else if (val->frdataset.trust == dns_trust_pending) {
-				/*
-				 * There should never be an unsigned DLV.
-				 */
-				dns_rdataset_disassociate(&val->frdataset);
-				validator_log(val, ISC_LOG_DEBUG(2),
-					      "unsigned DLV record");
-				return (DNS_R_NOVALIDSIG);
-			} else
-				result = ISC_R_SUCCESS;
-		} else if (result == ISC_R_NOTFOUND) {
-			result = create_fetch(val, name, dns_rdatatype_dlv,
-					      dlv_fetched,
-					      "dlv_validatezonekey");
-			if (result != ISC_R_SUCCESS)
-				return (result);
-			return (DNS_R_WAIT);
-		} else if (result ==  DNS_R_NCACHENXDOMAIN ||
-		   result == DNS_R_NCACHENXRRSET ||
-		   result == DNS_R_NXDOMAIN ||
-		   result == DNS_R_NXRRSET)
-		{
-			/*
-			 * The DS does not exist.
-			 */
-			if (dns_rdataset_isassociated(&val->frdataset))
-				dns_rdataset_disassociate(&val->frdataset);
-			if (dns_rdataset_isassociated(&val->fsigrdataset))
-				dns_rdataset_disassociate(&val->fsigrdataset);
-			validator_log(val, ISC_LOG_DEBUG(2), "no DLV record");
-			return (DNS_R_NOVALIDSIG);
-		}
-	}
-
-	/*
-	 * We have a DLV set.
-	 */
-	INSIST(val->dlv != NULL);
-
-	if (val->dlv->trust < dns_trust_secure) {
-		if (val->mustbesecure) {
-			validator_log(val, ISC_LOG_WARNING,
-				      "must be secure failure");
-			return (DNS_R_MUSTBESECURE);
-		}
-		val->event->rdataset->trust = dns_trust_answer;
-		val->event->sigrdataset->trust = dns_trust_answer;
-		return (ISC_R_SUCCESS);
-	}
 
+	validator_log(val, ISC_LOG_DEBUG(3), "dlv_validatezonekey");
 	/*
 	 * Look through the DLV record and find the keys that can sign the
 	 * key set and the matching signature.  For each such key, attempt
@@ -1553,15 +1381,16 @@ dlv_validatezonekey(dns_validator_t *val) {
 
 	supported_algorithm = ISC_FALSE;
 
-	for (result = dns_rdataset_first(val->dlv);
+	for (result = dns_rdataset_first(&val->dlv);
 	     result == ISC_R_SUCCESS;
-	     result = dns_rdataset_next(val->dlv))
+	     result = dns_rdataset_next(&val->dlv))
 	{
 		dns_rdata_reset(&dlvrdata);
-		dns_rdataset_current(val->dlv, &dlvrdata);
+		dns_rdataset_current(&val->dlv, &dlvrdata);
 		(void)dns_rdata_tostruct(&dlvrdata, &dlv, NULL);
 
-		if (!dns_resolver_algorithm_supported(val->view->resolver,
+		if (dlv.digest_type != DNS_DSDIGEST_SHA1 ||
+		    !dns_resolver_algorithm_supported(val->view->resolver,
 						      val->event->name,
 						      dlv.algorithm))
 			continue;
@@ -1586,8 +1415,12 @@ dlv_validatezonekey(dns_validator_t *val) {
 			result = dns_ds_buildrdata(val->event->name,
 						   &keyrdata, dlv.digest_type,
 						   dsbuf, &newdsrdata);
-			if (result != ISC_R_SUCCESS)
+			if (result != ISC_R_SUCCESS) {
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "dns_ds_buildrdata() -> %s",
+					      dns_result_totext(result));
 				continue;
+			}
 			/* Covert to DLV */
 			newdsrdata.type = dns_rdatatype_dlv;
 			if (dns_rdata_compare(&dlvrdata, &newdsrdata) == 0)
@@ -1598,7 +1431,9 @@ dlv_validatezonekey(dns_validator_t *val) {
 				      "no DNSKEY matching DLV");
 			continue;
 		}
-		
+		validator_log(val, ISC_LOG_DEBUG(3),
+		      "Found matching DLV record: checking for signature");
+
 		for (result = dns_rdataset_first(val->event->sigrdataset);
 		     result == ISC_R_SUCCESS;
 		     result = dns_rdataset_next(val->event->sigrdataset))
@@ -1610,7 +1445,6 @@ dlv_validatezonekey(dns_validator_t *val) {
 			if (dlv.key_tag != sig.keyid &&
 			    dlv.algorithm != sig.algorithm)
 				continue;
-
 			dstkey = NULL;
 			result = dns_dnssec_keyfromrdata(val->event->name,
 							 &keyrdata,
@@ -1644,10 +1478,9 @@ dlv_validatezonekey(dns_validator_t *val) {
 				      "must be secure failure");
 			return (DNS_R_MUSTBESECURE);
 		}
-		val->event->rdataset->trust = dns_trust_answer;
-		val->event->sigrdataset->trust = dns_trust_answer;
 		validator_log(val, ISC_LOG_DEBUG(3),
-			      "no supported algorithm (dlv)");
+			      "no supported algorithm/digest (dlv)");
+		markanswer(val);
 		return (ISC_R_SUCCESS);
 	} else
 		return (DNS_R_NOVALIDSIG);
@@ -1685,6 +1518,10 @@ validatezonekey(dns_validator_t *val) {
 
 	event = val->event;
 
+	if (val->havedlvsep && val->dlv.trust >= dns_trust_secure &&
+	    dns_name_equal(event->name, dns_fixedname_name(&val->dlvsep)))
+		return (dlv_validatezonekey(val));
+
 	if (val->dsset == NULL) {
 		/*
 		 * First, see if this key was signed by a trusted key.
@@ -1783,22 +1620,6 @@ validatezonekey(dns_validator_t *val) {
 			if (result != ISC_R_SUCCESS)
 				return (result);
 			return (DNS_R_WAIT);
-		} else if (val->view->dlv != NULL && !DLVTRIED(val) &&
-			   (result == DNS_R_NCACHENXRRSET ||
-			    result == DNS_R_NXRRSET) &&
-			   !dns_name_issubdomain(val->event->name,
-						 val->view->dlv))
-		{
-
-			if (dns_rdataset_isassociated(&val->frdataset))
-				dns_rdataset_disassociate(&val->frdataset);
-			if (dns_rdataset_isassociated(&val->fsigrdataset))
-				dns_rdataset_disassociate(&val->fsigrdataset);
-
-			validator_log(val, ISC_LOG_DEBUG(2),
-				      "no DS record: looking for DLV");
-
-			return (dlv_validatezonekey(val));
 		 } else if (result ==  DNS_R_NCACHENXDOMAIN ||
 			   result == DNS_R_NCACHENXRRSET ||
 			   result == DNS_R_NXDOMAIN ||
@@ -1827,8 +1648,7 @@ validatezonekey(dns_validator_t *val) {
 				      "must be secure failure");
 			return (DNS_R_MUSTBESECURE);
 		}
-		val->event->rdataset->trust = dns_trust_answer;
-		val->event->sigrdataset->trust = dns_trust_answer;
+		markanswer(val);
 		return (ISC_R_SUCCESS);
 	}
 
@@ -1848,6 +1668,8 @@ validatezonekey(dns_validator_t *val) {
 		dns_rdataset_current(val->dsset, &dsrdata);
 		(void)dns_rdata_tostruct(&dsrdata, &ds, NULL);
 
+		if (ds.digest_type != DNS_DSDIGEST_SHA1)
+			continue;
 		if (!dns_resolver_algorithm_supported(val->view->resolver,
 						      val->event->name,
 						      ds.algorithm))
@@ -1923,24 +1745,15 @@ validatezonekey(dns_validator_t *val) {
 		event->sigrdataset->trust = dns_trust_secure;
 		validator_log(val, ISC_LOG_DEBUG(3), "marking as secure");
 		return (result);
-	} else if (result == ISC_R_NOMORE && val->view->dlv != NULL &&
-		   !DLVTRIED(val) && !dns_name_issubdomain(val->event->name,
-							   val->view->dlv))
-	{
-		validator_log(val, ISC_LOG_DEBUG(2),
-			      "no DS/DNSKEY pair: looking for DLV");
-
-		return (dlv_validatezonekey(val));
 	} else if (result == ISC_R_NOMORE && !supported_algorithm) {
 		if (val->mustbesecure) {
 			validator_log(val, ISC_LOG_WARNING,
 				      "must be secure failure");
 			return (DNS_R_MUSTBESECURE);
 		}
-		val->event->rdataset->trust = dns_trust_answer;
-		val->event->sigrdataset->trust = dns_trust_answer;
 		validator_log(val, ISC_LOG_DEBUG(3),
-			      "no supported algorithm (ds)");
+			      "no supported algorithm/digest (DS)");
+		markanswer(val);
 		return (ISC_R_SUCCESS);
 	} else
 		return (DNS_R_NOVALIDSIG);
@@ -2174,7 +1987,8 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 
 	if ((val->attributes & VALATTR_FOUNDNONEXISTENCE) == 0) {
 		if (!val->seensig && val->soaset != NULL) {
-			result = create_validator(val, name, dns_rdatatype_soa,
+			result = create_validator(val, val->soaname,
+						  dns_rdatatype_soa,
 						  val->soaset, NULL,
 						  negauthvalidated,
 						  "nsecvalidate");
@@ -2193,8 +2007,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 }
 
 static isc_boolean_t
-check_ds_algorithm(dns_validator_t *val, dns_name_t *name,
-		   dns_rdataset_t *rdataset) {
+check_ds(dns_validator_t *val, dns_name_t *name, dns_rdataset_t *rdataset) {
 	dns_rdata_t dsrdata = DNS_RDATA_INIT;
 	dns_rdata_ds_t ds;
 	isc_result_t result;
@@ -2205,16 +2018,20 @@ check_ds_algorithm(dns_validator_t *val, dns_name_t *name,
 		dns_rdataset_current(rdataset, &dsrdata);
 		(void)dns_rdata_tostruct(&dsrdata, &ds, NULL);
 
-		if (dns_resolver_algorithm_supported(val->view->resolver,
-						     name, ds.algorithm))
+		if (ds.digest_type == DNS_DSDIGEST_SHA1 &&
+		    dns_resolver_algorithm_supported(val->view->resolver,
+						     name, ds.algorithm)) {
+			dns_rdata_reset(&dsrdata);
 			return (ISC_TRUE);
+		}
 		dns_rdata_reset(&dsrdata);
 	}
 	return (ISC_FALSE);
 }
 
 static void
-dlv_fetched2(isc_task_t *task, isc_event_t *event) {
+dlvfetched(isc_task_t *task, isc_event_t *event) {
+	char namebuf[DNS_NAME_FORMATSIZE];
 	dns_fetchevent_t *devent;
 	dns_validator_t *val;
 	isc_boolean_t want_destroy;
@@ -2226,18 +2043,29 @@ dlv_fetched2(isc_task_t *task, isc_event_t *event) {
 	devent = (dns_fetchevent_t *)event;
 	val = devent->ev_arg;
 	eresult = devent->result;
-	
+
+	/* Free resources which are not of interest. */
+	if (devent->node != NULL)
+		dns_db_detachnode(devent->db, &devent->node);
+	if (devent->db != NULL)
+		dns_db_detach(&devent->db);
+	if (dns_rdataset_isassociated(&val->fsigrdataset))
+		dns_rdataset_disassociate(&val->fsigrdataset);
 	isc_event_free(&event);
 	dns_resolver_destroyfetch(&val->fetch);
-	
+
 	INSIST(val->event != NULL);
-	validator_log(val, ISC_LOG_DEBUG(3), "in dlv_fetched2: %s",
+	validator_log(val, ISC_LOG_DEBUG(3), "in dlvfetched: %s",
 		      dns_result_totext(eresult));
 
 	LOCK(&val->lock);
 	if (eresult == ISC_R_SUCCESS) {
+		dns_name_format(dns_fixedname_name(&val->dlvsep), namebuf,
+				sizeof(namebuf));
+		dns_rdataset_clone(&val->frdataset, &val->dlv);
 		val->havedlvsep = ISC_TRUE;
-		result = proveunsecure(val, ISC_FALSE);
+		validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf);
+		result = dlv_validator_start(val);
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
 	} else if (eresult == DNS_R_NXRRSET ||
@@ -2246,13 +2074,26 @@ dlv_fetched2(isc_task_t *task, isc_event_t *event) {
 		   eresult == DNS_R_NCACHENXDOMAIN) {
 		   result = finddlvsep(val, ISC_TRUE);
 		if (result == ISC_R_SUCCESS) {
-			result = proveunsecure(val, ISC_FALSE);
+			dns_name_format(dns_fixedname_name(&val->dlvsep),
+					namebuf, sizeof(namebuf));
+			validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found",
+				      namebuf);
+			result = dlv_validator_start(val);
 			if (result != DNS_R_WAIT)
 				validator_done(val, result);
 		} else if (result == ISC_R_NOTFOUND) {
+			validator_log(val, ISC_LOG_DEBUG(3), "DLV not found");
+			markanswer(val);
 			validator_done(val, ISC_R_SUCCESS);
-		} else if (result != DNS_R_WAIT)
-			validator_done(val, result);
+		} else {
+			validator_log(val, ISC_LOG_DEBUG(3), "DLV lookup: %s",
+				      dns_result_totext(result));
+			if (result != DNS_R_WAIT)
+				validator_done(val, result);
+		}
+	} else {
+		validator_log(val, ISC_LOG_DEBUG(3), "DLV lookup: %s",
+			      dns_result_totext(eresult));
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -2261,19 +2102,72 @@ dlv_fetched2(isc_task_t *task, isc_event_t *event) {
 }
 
 static isc_result_t
+startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure) {
+	char namebuf[DNS_NAME_FORMATSIZE];
+	isc_result_t result;
+
+	INSIST(!DLVTRIED(val));
+
+	val->attributes |= VALATTR_DLVTRIED;
+
+	dns_name_format(unsecure, namebuf, sizeof(namebuf));
+	validator_log(val, ISC_LOG_DEBUG(3),
+		      "plain DNSSEC returns unsecure (%s): looking for DLV",
+		      namebuf);
+
+	if (dns_name_issubdomain(val->event->name, val->view->dlv)) {
+		validator_log(val, ISC_LOG_WARNING, "must be secure failure");
+		return (DNS_R_MUSTBESECURE);
+	}
+
+	val->dlvlabels = dns_name_countlabels(unsecure) - 1;
+	result = finddlvsep(val, ISC_FALSE);
+	if (result == ISC_R_NOTFOUND) {
+		validator_log(val, ISC_LOG_DEBUG(3), "DLV not found");
+		markanswer(val);
+		return (ISC_R_SUCCESS);
+	}
+	if (result != ISC_R_SUCCESS) {
+		validator_log(val, ISC_LOG_DEBUG(3), "DLV lookup: %s",
+			      dns_result_totext(result));
+		return (result);
+	}
+	dns_name_format(dns_fixedname_name(&val->dlvsep), namebuf,
+			sizeof(namebuf));
+	validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf);
+	return (dlv_validator_start(val));
+}
+
+static isc_result_t
 finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
+	char namebuf[DNS_NAME_FORMATSIZE];
 	dns_fixedname_t dlvfixed;
 	dns_name_t *dlvname;
 	dns_name_t *dlvsep;
 	dns_name_t noroot;
 	isc_result_t result;
 	unsigned int labels;
+		
+	INSIST(val->view->dlv != NULL);
 
 	if (!resume) {
+
+		if (dns_name_issubdomain(val->event->name, val->view->dlv)) {
+			validator_log(val, ISC_LOG_WARNING,
+				      "must be secure failure");
+			return (DNS_R_MUSTBESECURE);
+		}
+
 		dns_fixedname_init(&val->dlvsep);
 		dlvsep = dns_fixedname_name(&val->dlvsep);
 		dns_name_copy(val->event->name, dlvsep, NULL);
-		val->attributes |= VALATTR_DLVSEPTRIED;
+		if (val->event->type == dns_rdatatype_ds) {
+			labels = dns_name_countlabels(dlvsep);
+			if (labels == 0)
+				return (ISC_R_NOTFOUND);
+			dns_name_getlabelsequence(dlvsep, 1, labels - 1,
+						  dlvsep);
+		}
 	} else {
 		dlvsep = dns_fixedname_name(&val->dlvsep);
 		labels = dns_name_countlabels(dlvsep);
@@ -2283,6 +2177,8 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
 	dns_fixedname_init(&dlvfixed);
 	dlvname = dns_fixedname_name(&dlvfixed);
 	labels = dns_name_countlabels(dlvsep);
+	if (labels == 0)
+		return (ISC_R_NOTFOUND);
 	dns_name_getlabelsequence(dlvsep, 0, labels - 1, &noroot);
 	result = dns_name_concatenate(&noroot, val->view->dlv, dlvname, NULL);
 	while (result == ISC_R_NOSPACE) {
@@ -2297,32 +2193,37 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
 		return (DNS_R_NOVALIDSIG);
 	}
 
-	while (dns_name_countlabels(dlvname) >
-	       dns_name_countlabels(val->view->dlv)) 
-	{
+	while (dns_name_countlabels(dlvname) >=
+	       dns_name_countlabels(val->view->dlv) + val->dlvlabels) {
+		dns_name_format(dlvname, namebuf, sizeof(namebuf));
+		validator_log(val, ISC_LOG_DEBUG(3), "looking for DLV %s",
+			      namebuf);
 		result = view_find(val, dlvname, dns_rdatatype_dlv);
 		if (result == ISC_R_SUCCESS) {
 			if (val->frdataset.trust < dns_trust_secure)
 				return (DNS_R_NOVALIDSIG);
 			val->havedlvsep = ISC_TRUE;
+			dns_rdataset_clone(&val->frdataset, &val->dlv);
 			return (ISC_R_SUCCESS);
 		}
 		if (result == ISC_R_NOTFOUND) {
-                        result = create_fetch(val, dlvname, dns_rdatatype_dlv,
-                                              dlv_fetched2, "finddlvsep");
-                        if (result != ISC_R_SUCCESS)
-                                return (result);
-                        return (DNS_R_WAIT);
+			result = create_fetch(val, dlvname, dns_rdatatype_dlv,
+					      dlvfetched, "finddlvsep");
+			if (result != ISC_R_SUCCESS)
+				return (result);
+			return (DNS_R_WAIT);
 		}
 		if (result != DNS_R_NXRRSET &&
 		    result != DNS_R_NXDOMAIN &&
 		    result != DNS_R_NCACHENXRRSET &&
-		    result != DNS_R_NCACHENXDOMAIN) 
+		    result != DNS_R_NCACHENXDOMAIN)
 			return (result);
 		/*
 		 * Strip first labels from both dlvsep and dlvname.
 		 */
 		labels = dns_name_countlabels(dlvsep);
+		if (labels == 0)
+			break;
 		dns_name_getlabelsequence(dlvsep, 1, labels - 1, dlvsep);
 		labels = dns_name_countlabels(dlvname);
 		dns_name_getlabelsequence(dlvname, 1, labels - 1, dlvname);
@@ -2330,73 +2231,76 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
 	return (ISC_R_NOTFOUND);
 }
 
+/*
+ * proveunsecure walks down from the SEP looking for a break in the
+ * chain of trust.   That occurs when we can prove the DS record does
+ * not exist at a delegation point or the DS exists at a delegation
+ * but we don't support the algorithm/digest.
+ */
 static isc_result_t
 proveunsecure(dns_validator_t *val, isc_boolean_t resume) {
 	isc_result_t result;
-	isc_result_t tresult;
-	dns_fixedname_t secroot;
+	dns_fixedname_t fixedsecroot;
+	dns_name_t *secroot;
 	dns_name_t *tname;
+	char namebuf[DNS_NAME_FORMATSIZE];
 
-	dns_fixedname_init(&secroot);
-	result = dns_keytable_finddeepestmatch(val->keytable,
-					       val->event->name,
-					       dns_fixedname_name(&secroot));
-	/*
-	 * If the name is not under a security root, it must be insecure.
-	 */
-	if (val->view->dlv != NULL && !DLVSEPTRIED(val) && 
-	    !dns_name_issubdomain(val->event->name, val->view->dlv)) {
-		tresult = finddlvsep(val, ISC_FALSE);
-		if (tresult != ISC_R_NOTFOUND && tresult != ISC_R_SUCCESS) {
-			validator_log(val, ISC_LOG_DEBUG(3),
-				      "finddlvsep returned: %s",
-				      dns_result_totext(tresult));
-			return (tresult);
-		}
-	}
+	dns_fixedname_init(&fixedsecroot);
+	secroot = dns_fixedname_name(&fixedsecroot);
+	if (val->havedlvsep)
+		dns_name_copy(dns_fixedname_name(&val->dlvsep), secroot, NULL);
+	else {
+		result = dns_keytable_finddeepestmatch(val->keytable,
+						       val->event->name,
+						       secroot);
 
-	if (result == ISC_R_NOTFOUND) {
-		if (!val->havedlvsep) {
+		if (result == ISC_R_NOTFOUND) {
 			validator_log(val, ISC_LOG_DEBUG(3),
-				      "not beneath secure root / DLV");
+				      "not beneath secure root");
 			if (val->mustbesecure) {
 				validator_log(val, ISC_LOG_WARNING,
 					      "must be secure failure");
 				result = DNS_R_MUSTBESECURE;
 				goto out;
 			}
-			val->event->rdataset->trust = dns_trust_answer;
-			return (ISC_R_SUCCESS);
-		}
-		dns_name_copy(dns_fixedname_name(&val->dlvsep),
-			      dns_fixedname_name(&secroot), NULL);
-	} else if (result != ISC_R_SUCCESS)
-		return (result);
-	else if (val->havedlvsep &&
-	         dns_name_issubdomain(dns_fixedname_name(&val->dlvsep),
-				      dns_fixedname_name(&secroot))) {
-		dns_name_copy(dns_fixedname_name(&val->dlvsep),
-			      dns_fixedname_name(&secroot), NULL);
+			if (val->view->dlv == NULL || DLVTRIED(val)) {
+				markanswer(val);
+				return (ISC_R_SUCCESS);
+			}
+			return (startfinddlvsep(val, dns_rootname));
+		} else if (result != ISC_R_SUCCESS)
+			return (result);
 	}
 
 	if (!resume) {
-		val->labels =
-			dns_name_countlabels(dns_fixedname_name(&secroot)) + 1;
+		/*
+		 * We are looking for breaks below the SEP so add a label.
+		 */
+		val->labels = dns_name_countlabels(secroot) + 1;
 	} else {
 		validator_log(val, ISC_LOG_DEBUG(3), "resuming proveunsecure");
 		if (val->frdataset.trust >= dns_trust_secure &&
-		    !check_ds_algorithm(val, dns_fixedname_name(&val->fname),
-					&val->frdataset)) {
+		    !check_ds(val, dns_fixedname_name(&val->fname),
+			      &val->frdataset)) {
+			dns_name_format(dns_fixedname_name(&val->fname),
+					namebuf, sizeof(namebuf));
 			if (val->mustbesecure) {
 				validator_log(val, ISC_LOG_WARNING,
-					      "must be secure failure");
+					      "must be secure failure at '%s'",
+					      namebuf);
 				result = DNS_R_MUSTBESECURE;
 				goto out;
 			}
 			validator_log(val, ISC_LOG_DEBUG(3),
-				      "no supported algorithm (ds)");
-			val->event->rdataset->trust = dns_trust_answer;
-			result = ISC_R_SUCCESS;
+				      "no supported algorithm/digest (%s/DS)",
+				      namebuf);
+			if (val->view->dlv == NULL || DLVTRIED(val)) {
+				markanswer(val);
+				result = ISC_R_SUCCESS;
+				goto out;
+			}
+			result = startfinddlvsep(val,
+					      dns_fixedname_name(&val->fname));
 			goto out;
 		}
 		val->labels++;
@@ -2406,7 +2310,6 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) {
 	     val->labels <= dns_name_countlabels(val->event->name);
 	     val->labels++)
 	{
-		char namebuf[DNS_NAME_FORMATSIZE];
 
 		dns_fixedname_init(&val->fname);
 		tname = dns_fixedname_name(&val->fname);
@@ -2425,7 +2328,7 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) {
 		if (result == DNS_R_NXRRSET || result == DNS_R_NCACHENXRRSET) {
 			/*
 			 * There is no DS.  If this is a delegation,
-			 * we're done.
+			 * we maybe done.
 			 */
 			if (val->frdataset.trust < dns_trust_secure) {
 				/*
@@ -2443,8 +2346,11 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) {
 						      "must be secure failure");
 					return (DNS_R_MUSTBESECURE);
 				}
-				val->event->rdataset->trust = dns_trust_answer;
-				return (ISC_R_SUCCESS);
+				if (val->view->dlv == NULL || DLVTRIED(val)) {
+					markanswer(val);
+					return (ISC_R_SUCCESS);
+				}
+				return (startfinddlvsep(val, tname));
 			}
 			continue;
 		} else if (result == ISC_R_SUCCESS) {
@@ -2453,10 +2359,10 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) {
 			 * continue.
 			 */
 			if (val->frdataset.trust >= dns_trust_secure) {
-				if (!check_ds_algorithm(val, tname,
-							&val->frdataset)) {
+				if (!check_ds(val, tname, &val->frdataset)) {
 					validator_log(val, ISC_LOG_DEBUG(3),
-					      "no supported algorithm (ds)");
+						     "no supported algorithm/"
+						     "digest (%s/DS)", namebuf);
 					if (val->mustbesecure) {
 						validator_log(val,
 							      ISC_LOG_WARNING,
@@ -2464,9 +2370,13 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) {
 						result = DNS_R_MUSTBESECURE;
 						goto out;
 					}
-					val->event->rdataset->trust =
-							dns_trust_answer;
-					result = ISC_R_SUCCESS;
+					if (val->view->dlv == NULL ||
+					    DLVTRIED(val)) {
+						markanswer(val);
+						result = ISC_R_SUCCESS;
+						goto out;
+					}
+					result = startfinddlvsep(val, tname);
 					goto out;
 				}
 				continue;
@@ -2531,6 +2441,23 @@ proveunsecure(dns_validator_t *val, isc_boolean_t resume) {
 	return (result);
 }
 
+static isc_result_t
+dlv_validator_start(dns_validator_t *val) {
+	isc_event_t *event;
+
+	validator_log(val, ISC_LOG_DEBUG(3), "dlv_validator_start");
+
+	/*
+	 * Reset state and try again.
+	 */
+	val->attributes &= VALATTR_DLVTRIED;
+	val->options &= ~DNS_VALIDATOR_DLV;
+
+	event = (isc_event_t *)val->event;
+	isc_task_send(val->task, &event);
+	return (DNS_R_WAIT);
+}
+
 static void
 validator_start(isc_task_t *task, isc_event_t *event) {
 	dns_validator_t *val;
@@ -2547,11 +2474,18 @@ validator_start(isc_task_t *task, isc_event_t *event) {
 	if (val->event == NULL)
 		return;
 
-	validator_log(val, ISC_LOG_DEBUG(3), "starting");
+	if (DLVTRIED(val))
+		validator_log(val, ISC_LOG_DEBUG(3), "restarting using DLV");
+	else
+		validator_log(val, ISC_LOG_DEBUG(3), "starting");
 
 	LOCK(&val->lock);
 
-	if (val->event->rdataset != NULL && val->event->sigrdataset != NULL) {
+	if ((val->options & DNS_VALIDATOR_DLV) != 0) {
+		validator_log(val, ISC_LOG_DEBUG(3), "looking for DLV");
+		result = startfinddlvsep(val, dns_rootname);
+	} else if (val->event->rdataset != NULL &&
+		   val->event->sigrdataset != NULL) {
 		isc_result_t saved_result;
 
 		/*
@@ -2635,7 +2569,6 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 	REQUIRE(type != 0);
 	REQUIRE(rdataset != NULL ||
 		(rdataset == NULL && sigrdataset == NULL && message != NULL));
-	REQUIRE(options == 0);
 	REQUIRE(validatorp != NULL && *validatorp == NULL);
 
 	tclone = NULL;
@@ -2685,12 +2618,13 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 	val->currentset = NULL;
 	val->keyset = NULL;
 	val->dsset = NULL;
-	val->dlv = NULL;
+	dns_rdataset_init(&val->dlv);
 	val->soaset = NULL;
 	val->nsecset = NULL;
 	val->soaname = NULL;
 	val->seensig = ISC_FALSE;
 	val->havedlvsep = ISC_FALSE;
+	val->depth = 0;
 	val->mustbesecure = dns_resolver_getmustbesecure(view->resolver, name);
 	dns_rdataset_init(&val->frdataset);
 	dns_rdataset_init(&val->fsigrdataset);
@@ -2749,6 +2683,12 @@ destroy(dns_validator_t *val) {
 		dns_keytable_detach(&val->keytable);
 	if (val->subvalidator != NULL)
 		dns_validator_destroy(&val->subvalidator);
+	if (val->havedlvsep)
+		dns_rdataset_disassociate(&val->dlv);
+	if (dns_rdataset_isassociated(&val->frdataset))
+		dns_rdataset_disassociate(&val->frdataset);
+	if (dns_rdataset_isassociated(&val->fsigrdataset))
+		dns_rdataset_disassociate(&val->fsigrdataset);
 	mctx = val->view->mctx;
 	if (val->siginfo != NULL)
 		isc_mem_put(mctx, val->siginfo, sizeof(*val->siginfo));
@@ -2787,9 +2727,14 @@ validator_logv(dns_validator_t *val, isc_logcategory_t *category,
 	       isc_logmodule_t *module, int level, const char *fmt, va_list ap)
 {
 	char msgbuf[2048];
+	static const char spaces[] = "        *";
+	int depth = val->depth * 2;
 
 	vsnprintf(msgbuf, sizeof(msgbuf), fmt, ap);
 
+	if ((unsigned int) depth >= sizeof spaces)
+		depth = sizeof spaces - 1;
+
 	if (val->event != NULL && val->event->name != NULL) {
 		char namebuf[DNS_NAME_FORMATSIZE];
 		char typebuf[DNS_RDATATYPE_FORMATSIZE];
@@ -2798,11 +2743,12 @@ validator_logv(dns_validator_t *val, isc_logcategory_t *category,
 		dns_rdatatype_format(val->event->type, typebuf,
 				     sizeof(typebuf));
 		isc_log_write(dns_lctx, category, module, level,
-			      "validating %s %s: %s", namebuf, typebuf,
-			      msgbuf);
+			      "%.*svalidating @%p: %s %s: %s", depth, spaces,
+			      val, namebuf, typebuf, msgbuf);
 	} else {
 		isc_log_write(dns_lctx, category, module, level,
-			      "validator @%p: %s", val, msgbuf);
+			      "%.*svalidator @%p: %s", depth, spaces,
+			       val, msgbuf);
 	}
 }
 
diff --git a/contrib/bind9/lib/dns/xfrin.c b/contrib/bind9/lib/dns/xfrin.c
index aa4d054ca331..8a824a73ef5e 100644
--- a/contrib/bind9/lib/dns/xfrin.c
+++ b/contrib/bind9/lib/dns/xfrin.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: xfrin.c,v 1.124.2.4.2.9 2004/10/13 22:28:42 marka Exp $ */
+/* $Id: xfrin.c,v 1.124.2.4.2.12 2005/11/03 23:08:41 marka Exp $ */
 
 #include <config.h>
 
@@ -232,7 +232,7 @@ xfrin_log1(int level, dns_name_t *zonename, dns_rdataclass_t rdclass,
      ISC_FORMAT_PRINTF(5, 6);
 
 static void
-xfrin_log(dns_xfrin_ctx_t *xfr, unsigned int level, const char *fmt, ...)
+xfrin_log(dns_xfrin_ctx_t *xfr, int level, const char *fmt, ...)
      ISC_FORMAT_PRINTF(3, 4);
 
 /**************************************************************************/
@@ -581,7 +581,7 @@ dns_xfrin_create2(dns_zone_t *zone, dns_rdatatype_t xfrtype,
 		  isc_task_t *task, dns_xfrindone_t done, dns_xfrin_ctx_t **xfrp)
 {
 	dns_name_t *zonename = dns_zone_getorigin(zone);
-	dns_xfrin_ctx_t *xfr;
+	dns_xfrin_ctx_t *xfr = NULL;
 	isc_result_t result;
 	dns_db_t *db = NULL;
 
@@ -1391,7 +1391,7 @@ xfrin_log1(int level, dns_name_t *zonename, dns_rdataclass_t rdclass,
  */
 
 static void
-xfrin_log(dns_xfrin_ctx_t *xfr, unsigned int level, const char *fmt, ...)
+xfrin_log(dns_xfrin_ctx_t *xfr, int level, const char *fmt, ...)
 {
 	va_list ap;
 
diff --git a/contrib/bind9/lib/dns/zone.c b/contrib/bind9/lib/dns/zone.c
index 29f99cb1d68a..a993877e91ae 100644
--- a/contrib/bind9/lib/dns/zone.c
+++ b/contrib/bind9/lib/dns/zone.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zone.c,v 1.333.2.23.2.55 2005/02/03 23:50:45 marka Exp $ */
+/* $Id: zone.c,v 1.333.2.23.2.59 2005/07/29 00:38:33 marka Exp $ */
 
 #include <config.h>
 
@@ -167,6 +167,7 @@ struct dns_zone {
 
 	isc_sockaddr_t		*masters;
 	dns_name_t		**masterkeynames;
+	isc_boolean_t		*mastersok;
 	unsigned int		masterscnt;
 	unsigned int		curmaster;
 	isc_sockaddr_t		masteraddr;
@@ -536,6 +537,7 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) {
 	zone->minretry = DNS_ZONE_MINRETRY;
 	zone->masters = NULL;
 	zone->masterkeynames = NULL;
+	zone->mastersok = NULL;
 	zone->masterscnt = 0;
 	zone->curmaster = 0;
 	zone->notify = NULL;
@@ -590,7 +592,8 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) {
 
  free_mutex:
 	DESTROYLOCK(&zone->lock);
-	return (ISC_R_NOMEMORY);
+	isc_mem_putanddetach(&zone->mctx, zone, sizeof(*zone));
+	return (result);
 }
 
 /*
@@ -1250,6 +1253,7 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 	isc_uint32_t serial, refresh, retry, expire, minimum;
 	isc_time_t now;
 	isc_boolean_t needdump = ISC_FALSE;
+	isc_boolean_t hasinclude = DNS_ZONE_FLAG(zone, DNS_ZONEFLG_HASINCLUDE);
 
 	TIME_NOW(&now);
 
@@ -1355,10 +1359,32 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 		if (result != ISC_R_SUCCESS)
 			goto cleanup;
 		if (zone->db != NULL) {
-			if (!isc_serial_ge(serial, zone->serial)) {
+			/*
+			 * This is checked in zone_replacedb() for slave zones
+			 * as they don't reload from disk.
+			 */
+			if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS) &&
+			    !isc_serial_gt(serial, zone->serial)) {
+				isc_uint32_t serialmin, serialmax;
+
+				INSIST(zone->type == dns_zone_master);
+
+				serialmin = (zone->serial + 1) & 0xffffffffU;
+				serialmax = (zone->serial + 0x7fffffffU) &
+					     0xffffffffU;
+				dns_zone_log(zone, ISC_LOG_ERROR,
+					     "ixfr-from-differences: "
+					     "new serial (%u) out of range "
+					     "[%u - %u]", serial, serialmin,
+					     serialmax);
+				result = DNS_R_BADZONE;
+				goto cleanup;
+			} else if (!isc_serial_ge(serial, zone->serial))
 				dns_zone_log(zone, ISC_LOG_ERROR,
 					     "zone serial has gone backwards");
-			}
+			else if (serial == zone->serial && !hasinclude) 
+				dns_zone_log(zone, ISC_LOG_ERROR,
+					     "zone serial unchanged");
 		}
 		zone->serial = serial;
 		zone->refresh = RANGE(refresh,
@@ -1943,6 +1969,7 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone, isc_sockaddr_t *masters,
 	isc_sockaddr_t *new;
 	isc_result_t result = ISC_R_SUCCESS;
 	dns_name_t **newname;
+	isc_boolean_t *newok;
 	unsigned int i;
 
 	REQUIRE(DNS_ZONE_VALID(zone));
@@ -1972,10 +1999,15 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone, isc_sockaddr_t *masters,
 			    zone->masterscnt * sizeof(dns_name_t *));
 		zone->masterkeynames = NULL;
 	}
+	if (zone->mastersok != NULL) {
+		isc_mem_put(zone->mctx, zone->mastersok,
+			    zone->masterscnt * sizeof(isc_boolean_t));
+		zone->mastersok = NULL;
+	}
 	zone->masterscnt = 0;
 	/*
-	 * If count == 0, don't allocate any space for masters or keynames
-	 * so internally, those pointers are NULL if count == 0
+	 * If count == 0, don't allocate any space for masters, mastersok or
+	 * keynames so internally, those pointers are NULL if count == 0
 	 */
 	if (count == 0)
 		goto unlock;
@@ -1983,27 +2015,35 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone, isc_sockaddr_t *masters,
 	/*
 	 * masters must countain count elements!
 	 */
-	new = isc_mem_get(zone->mctx,
-			  count * sizeof(isc_sockaddr_t));
+	new = isc_mem_get(zone->mctx, count * sizeof(*new));
 	if (new == NULL) {
 		result = ISC_R_NOMEMORY;
 		goto unlock;
 	}
 	memcpy(new, masters, count * sizeof(*new));
-	zone->masters = new;
-	zone->masterscnt = count;
-	DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NOMASTERS);
+	
+	/*
+	 * Similarly for mastersok.
+	 */
+	newok = isc_mem_get(zone->mctx, count * sizeof(*newok));
+	if (newok == NULL) {
+		result = ISC_R_NOMEMORY;
+		isc_mem_put(zone->mctx, new, count * sizeof(*new));
+		goto unlock;
+	};
+	for (i = 0; i < count; i++)
+		newok[i] = ISC_FALSE;
 
 	/*
 	 * if keynames is non-NULL, it must contain count elements!
 	 */
+	newname = NULL;
 	if (keynames != NULL) {
-		newname = isc_mem_get(zone->mctx,
-				      count * sizeof(dns_name_t *));
+		newname = isc_mem_get(zone->mctx, count * sizeof(*newname));
 		if (newname == NULL) {
 			result = ISC_R_NOMEMORY;
-			isc_mem_put(zone->mctx, zone->masters,
-				    count * sizeof(*new));
+			isc_mem_put(zone->mctx, new, count * sizeof(*new));
+			isc_mem_put(zone->mctx, newok, count * sizeof(*newok));
 			goto unlock;
 		}
 		for (i = 0; i < count; i++)
@@ -2024,16 +2064,27 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone, isc_sockaddr_t *masters,
 							dns_name_free(
 							       newname[i],
 							       zone->mctx);
-					isc_mem_put(zone->mctx, zone->masters,
+					isc_mem_put(zone->mctx, new,
 						    count * sizeof(*new));
+					isc_mem_put(zone->mctx, newok,
+						    count * sizeof(*newok));
 					isc_mem_put(zone->mctx, newname,
 						    count * sizeof(*newname));
 					goto unlock;
 				}
 			}
 		}
-		zone->masterkeynames = newname;
 	}
+
+	/*
+	 * Everything is ok so attach to the zone.
+	 */
+	zone->masters = new;
+	zone->mastersok = newok;
+	zone->masterkeynames = newname;
+	zone->masterscnt = count;
+	DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NOMASTERS);
+
  unlock:
 	UNLOCK_ZONE(zone);
 	return (result);
@@ -2222,6 +2273,7 @@ void
 dns_zone_refresh(dns_zone_t *zone) {
 	isc_interval_t i;
 	isc_uint32_t oldflags;
+	unsigned int j;
 
 	REQUIRE(DNS_ZONE_VALID(zone));
 
@@ -2266,6 +2318,8 @@ dns_zone_refresh(dns_zone_t *zone) {
 		zone->retry = ISC_MIN(zone->retry * 2, 6 * 3600);
 
 	zone->curmaster = 0;
+	for (j = 0; j < zone->masterscnt; j++)
+		zone->mastersok[j] = ISC_FALSE;
 	/* initiate soa query */
 	queue_soa_query(zone);
  unlock:
@@ -3186,6 +3240,7 @@ stub_callback(isc_task_t *task, isc_event_t *event) {
 	isc_time_t now;
 	isc_boolean_t exiting = ISC_FALSE;
 	isc_interval_t i;
+	unsigned int j;
 
 	stub = revent->ev_arg;
 	INSIST(DNS_STUB_VALID(stub));
@@ -3360,13 +3415,37 @@ stub_callback(isc_task_t *task, isc_event_t *event) {
 	isc_event_free(&event);
 	LOCK_ZONE(zone);
 	dns_request_destroy(&zone->request);
-	zone->curmaster++;
+	/*
+	 * Skip to next failed / untried master.
+	 */
+	do {
+		zone->curmaster++;
+	} while (zone->curmaster < zone->masterscnt &&
+		 zone->mastersok[zone->curmaster]);
 	DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NOEDNS);
 	if (exiting || zone->curmaster >= zone->masterscnt) {
+		isc_boolean_t done = ISC_TRUE;
 		if (!exiting &&
 		    DNS_ZONE_OPTION(zone, DNS_ZONEOPT_USEALTXFRSRC) &&
 		    !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_USEALTXFRSRC)) {
+			/*
+			 * Did we get a good answer from all the masters?
+			 */
+			for (j = 0; j < zone->masterscnt; j++)
+				if (zone->mastersok[j] == ISC_FALSE) {
+					done = ISC_FALSE;
+					break;
+				}
+		} else
+			done = ISC_TRUE;
+		if (!done) {
 			zone->curmaster = 0;
+			/*
+			 * Find the next failed master.
+			 */
+			while (zone->curmaster < zone->masterscnt &&
+			       zone->mastersok[zone->curmaster])
+				zone->curmaster++;
 			DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_USEALTXFRSRC);
 		} else {
 			DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_REFRESH);
@@ -3420,6 +3499,7 @@ refresh_callback(isc_task_t *task, isc_event_t *event) {
 	dns_rdata_soa_t soa;
 	isc_result_t result;
 	isc_uint32_t serial;
+	unsigned int j;
 
 	zone = revent->ev_arg;
 	INSIST(DNS_ZONE_VALID(zone));
@@ -3668,6 +3748,7 @@ refresh_callback(isc_task_t *task, isc_event_t *event) {
 		}
 		DNS_ZONE_JITTER_ADD(&now, zone->refresh, &zone->refreshtime);
 		DNS_ZONE_TIME_ADD(&now, zone->expire, &zone->expiretime);
+		zone->mastersok[zone->curmaster] = ISC_TRUE;
 		goto next_master;
 	} else {
 		if (!DNS_ZONE_OPTION(zone, DNS_ZONEOPT_MULTIMASTER))
@@ -3676,6 +3757,7 @@ refresh_callback(isc_task_t *task, isc_event_t *event) {
 				     soa.serial, master, zone->serial);
 		else
 			zone_debuglog(zone, me, 1, "ahead");
+		zone->mastersok[zone->curmaster] = ISC_TRUE;
 		goto next_master;
 	}
 	if (msg != NULL)
@@ -3688,13 +3770,37 @@ refresh_callback(isc_task_t *task, isc_event_t *event) {
 	isc_event_free(&event);
 	LOCK_ZONE(zone);
 	dns_request_destroy(&zone->request);
-	zone->curmaster++;
+	/*
+	 * Skip to next failed / untried master.
+	 */
+	do {
+		zone->curmaster++;
+	} while (zone->curmaster < zone->masterscnt &&
+		 zone->mastersok[zone->curmaster]);
 	DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_NOEDNS);
 	if (zone->curmaster >= zone->masterscnt) {
+		isc_boolean_t done = ISC_TRUE;
 		if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_USEALTXFRSRC) &&
 		    !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_USEALTXFRSRC)) {
+			/*
+			 * Did we get a good answer from all the masters?
+			 */
+			for (j = 0; j < zone->masterscnt; j++)
+				if (zone->mastersok[j] == ISC_FALSE) {
+					done = ISC_FALSE;
+					break;
+				}
+		} else
+			done = ISC_TRUE;
+		if (!done) {
 			DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_USEALTXFRSRC);
 			zone->curmaster = 0;
+			/*
+			 * Find the next failed master.
+			 */
+			while (zone->curmaster < zone->masterscnt &&
+			       zone->mastersok[zone->curmaster])
+				zone->curmaster++;
 			goto requeue;
 		}
 		DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_REFRESH);
@@ -4023,7 +4129,13 @@ soa_query(isc_task_t *task, isc_event_t *event) {
  skip_master:
 	if (key != NULL)
 		dns_tsigkey_detach(&key);
-	zone->curmaster++;
+	/*
+	 * Skip to next failed / untried master.
+	 */
+	do {
+		zone->curmaster++;
+	} while (zone->curmaster < zone->masterscnt &&
+		 zone->mastersok[zone->curmaster]);
 	if (zone->curmaster < zone->masterscnt)
 		goto again;
 	zone->curmaster = 0;
@@ -5275,40 +5387,58 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) {
 	 * is enabled in the configuration.
 	 */
 	if (zone->db != NULL && zone->journal != NULL &&
-	    DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS)) {
-		isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL,
-			      DNS_LOGMODULE_ZONE, ISC_LOG_DEBUG(3),
-			      "generating diffs");
-		result = dns_db_diff(zone->mctx, db, ver,
-				     zone->db, NULL /* XXX */,
+	    DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS) &&
+	    !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_FORCEXFER)) {
+		isc_uint32_t serial;
+
+		dns_zone_log(zone, ISC_LOG_DEBUG(3), "generating diffs");
+
+		result = dns_db_getsoaserial(db, ver, &serial);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "ixfr-from-differences: unable to get "
+				     "new serial");
+			goto fail;
+		}
+
+		/*
+		 * This is checked in zone_postload() for master zones.
+		 */
+		if (zone->type == dns_zone_slave &&
+		    !isc_serial_gt(serial, zone->serial)) {
+			isc_uint32_t serialmin, serialmax;
+			serialmin = (zone->serial + 1) & 0xffffffffU;
+			serialmax = (zone->serial + 0x7fffffffU) & 0xffffffffU;
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "ixfr-from-differences: failed: "
+				     "new serial (%u) out of range [%u - %u]",
+				     serial, serialmin, serialmax);
+			result = ISC_R_RANGE;
+			goto fail;
+		}
+
+		result = dns_db_diff(zone->mctx, db, ver, zone->db, NULL,
 				     zone->journal);
 		if (result != ISC_R_SUCCESS)
 			goto fail;
 		if (dump)
 			zone_needdump(zone, DNS_DUMP_DELAY);
 		else if (zone->journalsize != -1) {
-			isc_uint32_t serial;
-
-			result = dns_db_getsoaserial(db, ver, &serial);
-			if (result == ISC_R_SUCCESS) {
-				result = dns_journal_compact(zone->mctx,
-							     zone->journal,
-							     serial,
-							     zone->journalsize);
-				switch (result) {
-				case ISC_R_SUCCESS:
-				case ISC_R_NOSPACE:
-				case ISC_R_NOTFOUND:
-					dns_zone_log(zone, ISC_LOG_DEBUG(3),
-						     "dns_journal_compact: %s",
-						     dns_result_totext(result));
-					break;
-				default:
-					dns_zone_log(zone, ISC_LOG_ERROR,
+			result = dns_journal_compact(zone->mctx, zone->journal,
+						     serial, zone->journalsize);
+			switch (result) {
+			case ISC_R_SUCCESS:
+			case ISC_R_NOSPACE:
+			case ISC_R_NOTFOUND:
+				dns_zone_log(zone, ISC_LOG_DEBUG(3),
+					     "dns_journal_compact: %s",
+					     dns_result_totext(result));
+				break;
+			default:
+				dns_zone_log(zone, ISC_LOG_ERROR,
 					     "dns_journal_compact failed: %s",
-						     dns_result_totext(result));
-					break;
-				}
+					     dns_result_totext(result));
+				break;
 			}
 		}
 	} else {
@@ -5503,7 +5633,14 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) {
 
 	default:
 	next_master:
-		zone->curmaster++;
+		/*
+		 * Skip to next failed / untried master.
+		 */
+		do {
+			zone->curmaster++;
+		} while (zone->curmaster < zone->masterscnt &&
+			 zone->mastersok[zone->curmaster]);
+		/* FALLTHROUGH */
 	same_master:
 		if (zone->curmaster >= zone->masterscnt) {
 			zone->curmaster = 0;
@@ -5511,6 +5648,9 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) {
 			    !DNS_ZONE_FLAG(zone, DNS_ZONEFLG_USEALTXFRSRC)) {
 				DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_REFRESH);
 				DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_USEALTXFRSRC);
+				while (zone->curmaster < zone->masterscnt &&
+				       zone->mastersok[zone->curmaster])
+					zone->curmaster++;
 				again = ISC_TRUE;
 			} else
 				DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_USEALTXFRSRC);
@@ -5697,7 +5837,11 @@ got_transfer_quota(isc_task_t *task, isc_event_t *event) {
 			     "requesting AXFR of "
 			     "initial version from %s", mastertext);
 		xfrtype = dns_rdatatype_axfr;
-	} else if (dns_zone_isforced(zone)) {
+	} else if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS)) {
+		dns_zone_log(zone, ISC_LOG_DEBUG(1), "ixfr-from-differences "
+			     "set, requesting AXFR from %s", mastertext);
+		xfrtype = dns_rdatatype_axfr;
+	} else if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_FORCEXFER)) {
 		dns_zone_log(zone, ISC_LOG_DEBUG(1),
 			     "forced reload, requesting AXFR of "
 			     "initial version from %s", mastertext);
@@ -6663,6 +6807,9 @@ void
 dns_zone_forcereload(dns_zone_t *zone) {
 	REQUIRE(DNS_ZONE_VALID(zone));
 
+	if (zone->type == dns_zone_master)
+		return;
+
 	LOCK_ZONE(zone);
 	DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_FORCEXFER);
 	UNLOCK_ZONE(zone);
diff --git a/contrib/bind9/lib/isc/api b/contrib/bind9/lib/isc/api
index 63704dd62ad3..ddeff334f036 100644
--- a/contrib/bind9/lib/isc/api
+++ b/contrib/bind9/lib/isc/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 10
-LIBREVISION = 5
-LIBAGE = 1
+LIBINTERFACE = 11
+LIBREVISION = 1
+LIBAGE = 0
diff --git a/contrib/bind9/lib/isc/include/isc/Makefile.in b/contrib/bind9/lib/isc/include/isc/Makefile.in
index 10cad7e052d9..f484c0bd4a7e 100644
--- a/contrib/bind9/lib/isc/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/include/isc/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001, 2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.50.12.4 2004/03/06 08:14:38 marka Exp $
+# $Id: Makefile.in,v 1.50.12.6 2005/03/22 02:32:07 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -28,8 +28,8 @@ top_srcdir =	@top_srcdir@
 #
 HEADERS =	app.h assertions.h base64.h bitstring.h boolean.h buffer.h \
 		bufferlist.h commandline.h entropy.h error.h event.h \
-		eventclass.h \
-		file.h formatcheck.h fsaccess.h heap.h hex.h hmacmd5.h \
+		eventclass.h file.h formatcheck.h fsaccess.h \
+		hash.h heap.h hex.h hmacmd5.h \
 		interfaceiter.h @ISC_IPV6_H@ lang.h lex.h \
 		lfsr.h lib.h list.h log.h magic.h md5.h mem.h msgcat.h msgs.h \
 		mutexblock.h netaddr.h ondestroy.h os.h parseint.h \
diff --git a/contrib/bind9/lib/isc/include/isc/netaddr.h b/contrib/bind9/lib/isc/include/isc/netaddr.h
index e209a9fa7749..ad3328c47cdf 100644
--- a/contrib/bind9/lib/isc/include/isc/netaddr.h
+++ b/contrib/bind9/lib/isc/include/isc/netaddr.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netaddr.h,v 1.18.12.7 2004/03/08 09:04:52 marka Exp $ */
+/* $Id: netaddr.h,v 1.18.12.9 2005/07/29 00:13:10 marka Exp $ */
 
 #ifndef ISC_NETADDR_H
 #define ISC_NETADDR_H 1
@@ -81,7 +81,7 @@ isc_netaddr_format(const isc_netaddr_t *na, char *array, unsigned int size);
  */
 
 #define ISC_NETADDR_FORMATSIZE \
-	sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX")
+	sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX%SSSSSSSSSS")
 /*
  * Minimum size of array to pass to isc_netaddr_format().
  */
diff --git a/contrib/bind9/lib/isc/include/isc/print.h b/contrib/bind9/lib/isc/include/isc/print.h
index 19da6b0915b8..1bf3704a26f4 100644
--- a/contrib/bind9/lib/isc/include/isc/print.h
+++ b/contrib/bind9/lib/isc/include/isc/print.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: print.h,v 1.17.188.2 2004/03/06 08:14:46 marka Exp $ */
+/* $Id: print.h,v 1.17.188.4 2005/06/09 23:54:30 marka Exp $ */
 
 #ifndef ISC_PRINT_H
 #define ISC_PRINT_H 1
@@ -55,6 +55,10 @@
 #include <stdarg.h>
 #include <stddef.h>
 #endif
+#ifdef ISC_PLATFORM_NEEDSPRINTF
+#include <stdio.h>
+#endif
+
 
 ISC_LANG_BEGINDECLS
 
diff --git a/contrib/bind9/lib/isc/include/isc/quota.h b/contrib/bind9/lib/isc/include/isc/quota.h
index 86478761332b..4044118747b3 100644
--- a/contrib/bind9/lib/isc/include/isc/quota.h
+++ b/contrib/bind9/lib/isc/include/isc/quota.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: quota.h,v 1.8.12.3 2004/03/08 09:04:52 marka Exp $ */
+/* $Id: quota.h,v 1.8.12.6 2005/08/11 15:00:08 marka Exp $ */
 
 #ifndef ISC_QUOTA_H
 #define ISC_QUOTA_H 1
@@ -53,7 +53,7 @@ struct isc_quota {
 	/* Locked by lock. */
 	int 		max;
 	int 		used;
-	isc_boolean_t	soft;
+	int		soft;
 };
 
 isc_result_t
@@ -73,11 +73,17 @@ isc_quota_destroy(isc_quota_t *quota);
  */
 
 void
-isc_quota_soft(isc_quota_t *quota, isc_boolean_t soft);
+isc_quota_soft(isc_quota_t *quota, int soft);
 /*
  * Turn on/off soft quotas.
  */
 
+void
+isc_quota_max(isc_quota_t *quota, int max);
+/*
+ * Re-set a maximum quota.
+ */
+
 isc_result_t
 isc_quota_reserve(isc_quota_t *quota);
 /*
diff --git a/contrib/bind9/lib/isc/include/isc/sockaddr.h b/contrib/bind9/lib/isc/include/isc/sockaddr.h
index ffe4105deaa2..1ffbca640fc1 100644
--- a/contrib/bind9/lib/isc/include/isc/sockaddr.h
+++ b/contrib/bind9/lib/isc/include/isc/sockaddr.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sockaddr.h,v 1.35.12.6 2004/03/08 09:04:53 marka Exp $ */
+/* $Id: sockaddr.h,v 1.35.12.8 2005/07/29 00:13:10 marka Exp $ */
 
 #ifndef ISC_SOCKADDR_H
 #define ISC_SOCKADDR_H 1
@@ -192,7 +192,7 @@ isc_sockaddr_issitelocal(isc_sockaddr_t *sa);
  */
 
 #define ISC_SOCKADDR_FORMATSIZE \
-	sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX#YYYYY")
+	sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:XXX.XXX.XXX.XXX#YYYYY%SSSSSSSSSS")
 /*
  * Minimum size of array to pass to isc_sockaddr_format().
  */
diff --git a/contrib/bind9/lib/isc/include/isc/timer.h b/contrib/bind9/lib/isc/include/isc/timer.h
index be32911a29c9..439c943dad53 100644
--- a/contrib/bind9/lib/isc/include/isc/timer.h
+++ b/contrib/bind9/lib/isc/include/isc/timer.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: timer.h,v 1.28.12.4 2004/03/08 09:04:53 marka Exp $ */
+/* $Id: timer.h,v 1.28.12.6 2005/10/27 00:27:30 marka Exp $ */
 
 #ifndef ISC_TIMER_H
 #define ISC_TIMER_H 1
@@ -277,8 +277,15 @@ isc_timer_detach(isc_timer_t **timerp);
  *		timer event callbacks will run after the call.
  */
 
-isc_result_t
+isc_timertype_t
 isc_timer_gettype(isc_timer_t *timer);
+/*%<
+ * Return the timer type.
+ *
+ * Requires:
+ *
+ *\li	'timer' to be a valid timer.
+ */
 
 isc_result_t
 isc_timermgr_create(isc_mem_t *mctx, isc_timermgr_t **managerp);
diff --git a/contrib/bind9/lib/isc/inet_pton.c b/contrib/bind9/lib/isc/inet_pton.c
index b253069e0d34..026fedf23c7e 100644
--- a/contrib/bind9/lib/isc/inet_pton.c
+++ b/contrib/bind9/lib/isc/inet_pton.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -17,7 +17,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static char rcsid[] =
-	"$Id: inet_pton.c,v 1.10.2.4.2.1 2004/03/06 08:14:31 marka Exp $";
+	"$Id: inet_pton.c,v 1.10.2.4.2.3 2005/03/31 23:56:14 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
@@ -132,7 +132,7 @@ inet_pton6(const char *src, unsigned char *dst) {
 			  xdigits_u[] = "0123456789ABCDEF";
 	unsigned char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp;
 	const char *xdigits, *curtok;
-	int ch, saw_xdigit;
+	int ch, seen_xdigits;
 	unsigned int val;
 
 	memset((tp = tmp), '\0', NS_IN6ADDRSZ);
@@ -143,7 +143,7 @@ inet_pton6(const char *src, unsigned char *dst) {
 		if (*++src != ':')
 			return (0);
 	curtok = src;
-	saw_xdigit = 0;
+	seen_xdigits = 0;
 	val = 0;
 	while ((ch = *src++) != '\0') {
 		const char *pch;
@@ -153,14 +153,13 @@ inet_pton6(const char *src, unsigned char *dst) {
 		if (pch != NULL) {
 			val <<= 4;
 			val |= (pch - xdigits);
-			if (val > 0xffff)
+			if (++seen_xdigits > 4)
 				return (0);
-			saw_xdigit = 1;
 			continue;
 		}
 		if (ch == ':') {
 			curtok = src;
-			if (!saw_xdigit) {
+			if (!seen_xdigits) {
 				if (colonp)
 					return (0);
 				colonp = tp;
@@ -170,19 +169,19 @@ inet_pton6(const char *src, unsigned char *dst) {
 				return (0);
 			*tp++ = (unsigned char) (val >> 8) & 0xff;
 			*tp++ = (unsigned char) val & 0xff;
-			saw_xdigit = 0;
+			seen_xdigits = 0;
 			val = 0;
 			continue;
 		}
 		if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) &&
 		    inet_pton4(curtok, tp) > 0) {
 			tp += NS_INADDRSZ;
-			saw_xdigit = 0;
+			seen_xdigits = 0;
 			break;	/* '\0' was seen by inet_pton4(). */
 		}
 		return (0);
 	}
-	if (saw_xdigit) {
+	if (seen_xdigits) {
 		if (tp + NS_INT16SZ > endp)
 			return (0);
 		*tp++ = (unsigned char) (val >> 8) & 0xff;
diff --git a/contrib/bind9/lib/isc/lfsr.c b/contrib/bind9/lib/isc/lfsr.c
index e1de6aa23eb8..6d5b7ff82385 100644
--- a/contrib/bind9/lib/isc/lfsr.c
+++ b/contrib/bind9/lib/isc/lfsr.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,10 +15,11 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lfsr.c,v 1.11.2.2.2.3 2004/03/08 09:04:49 marka Exp $ */
+/* $Id: lfsr.c,v 1.11.2.2.2.6 2005/10/14 01:38:50 marka Exp $ */
 
 #include <config.h>
 
+#include <stddef.h>
 #include <stdlib.h>
 
 #include <isc/assertions.h>
@@ -55,9 +56,6 @@ isc_lfsr_init(isc_lfsr_t *lfsr, isc_uint32_t state, unsigned int bits,
 static inline isc_uint32_t
 lfsr_generate(isc_lfsr_t *lfsr)
 {
-	unsigned int highbit;
-
-	highbit = 1 << (lfsr->bits - 1);
 
 	/*
 	 * If the previous state is zero, we must fill it with something
diff --git a/contrib/bind9/lib/isc/mem.c b/contrib/bind9/lib/isc/mem.c
index 762aa1770707..f5069fb7dc17 100644
--- a/contrib/bind9/lib/isc/mem.c
+++ b/contrib/bind9/lib/isc/mem.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mem.c,v 1.98.2.7.2.5 2004/03/16 05:50:24 marka Exp $ */
+/* $Id: mem.c,v 1.98.2.7.2.7 2005/03/17 03:58:32 marka Exp $ */
 
 #include <config.h>
 
@@ -717,6 +717,15 @@ isc_mem_createx(size_t init_max_size, size_t target_size,
 	if (ctx == NULL)
 		return (ISC_R_NOMEMORY);
 
+	if (isc_mutex_init(&ctx->lock) != ISC_R_SUCCESS) {
+		UNEXPECTED_ERROR(__FILE__, __LINE__,
+				 "isc_mutex_init() %s",
+				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
+						ISC_MSG_FAILED, "failed"));
+		(memfree)(arg, ctx);
+		return (ISC_R_UNEXPECTED);
+	}
+
 	if (init_max_size == 0U)
 		ctx->max_size = DEF_MAX_SIZE;
 	else
@@ -775,15 +784,6 @@ isc_mem_createx(size_t init_max_size, size_t target_size,
 	ctx->highest = NULL;
 #endif /* ISC_MEM_USE_INTERNAL_MALLOC */
 
-	if (isc_mutex_init(&ctx->lock) != ISC_R_SUCCESS) {
-		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "isc_mutex_init() %s",
-				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
-						ISC_MSG_FAILED, "failed"));
-		result = ISC_R_UNEXPECTED;
-		goto error;
-	}
-
 #if ISC_MEM_TRACKLINES
 	if ((isc_mem_debugging & ISC_MEM_DEBUGRECORD) != 0) {
 		unsigned int i;
@@ -805,17 +805,18 @@ isc_mem_createx(size_t init_max_size, size_t target_size,
 	return (ISC_R_SUCCESS);
 
   error:
-	if (ctx) {
-		if (ctx->stats)
+	if (ctx != NULL) {
+		if (ctx->stats != NULL)
 			(memfree)(arg, ctx->stats);
 #if ISC_MEM_USE_INTERNAL_MALLOC
-		if (ctx->freelists)
+		if (ctx->freelists != NULL)
 			(memfree)(arg, ctx->freelists);
 #endif /* ISC_MEM_USE_INTERNAL_MALLOC */
 #if ISC_MEM_TRACKLINES
-		if (ctx->debuglist)
+		if (ctx->debuglist != NULL)
 			(ctx->memfree)(ctx->arg, ctx->debuglist);
 #endif /* ISC_MEM_TRACKLINES */
+		DESTROYLOCK(&ctx->lock);
 		(memfree)(arg, ctx);
 	}
 
diff --git a/contrib/bind9/lib/isc/nls/msgcat.c b/contrib/bind9/lib/isc/nls/msgcat.c
index 484ab514a242..906e26e9070e 100644
--- a/contrib/bind9/lib/isc/nls/msgcat.c
+++ b/contrib/bind9/lib/isc/nls/msgcat.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: msgcat.c,v 1.10.12.4 2004/03/08 09:04:54 marka Exp $ */
+/* $Id: msgcat.c,v 1.10.12.6 2005/06/09 23:54:31 marka Exp $ */
 
 /*
  * Principal Author: Bob Halley
@@ -23,6 +23,7 @@
 
 #include <config.h>
 
+#include <stddef.h>
 #include <stdlib.h>
 
 #include <isc/magic.h>
diff --git a/contrib/bind9/lib/isc/pthreads/mutex.c b/contrib/bind9/lib/isc/pthreads/mutex.c
index e29e92bd022b..71db6696610d 100644
--- a/contrib/bind9/lib/isc/pthreads/mutex.c
+++ b/contrib/bind9/lib/isc/pthreads/mutex.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mutex.c,v 1.6.26.3 2004/03/08 09:04:55 marka Exp $ */
+/* $Id: mutex.c,v 1.6.26.5 2005/03/17 03:58:32 marka Exp $ */
 
 #include <config.h>
 
@@ -126,19 +126,6 @@ isc_mutex_lock_profile(isc_mutex_t *mp, const char *file, int line) {
 	isc_mutexlocker_t *locker = NULL;
 	int i;
 
-	for (i = 0; i < ISC_MUTEX_MAX_LOCKERS; i++) {
-		if (mp->stats->lockers[i].file == NULL) {
-			locker = &mp->stats->lockers[i];
-			locker->file = file;
-			locker->line = line;
-			break;
-		} else if (mp->stats->lockers[i].file == file &&
-			   mp->stats->lockers[i].line == line) {
-			locker = &mp->stats->lockers[i];
-			break;
-		}
-	}
-
 	gettimeofday(&prelock_t, NULL);
 
 	if (pthread_mutex_lock(&mp->mutex) != 0)
@@ -152,6 +139,19 @@ isc_mutex_lock_profile(isc_mutex_t *mp, const char *file, int line) {
 	mp->stats->count++;
 	timevaladd(&mp->stats->wait_total, &postlock_t);
 
+	for (i = 0; i < ISC_MUTEX_MAX_LOCKERS; i++) {
+		if (mp->stats->lockers[i].file == NULL) {
+			locker = &mp->stats->lockers[i];
+			locker->file = file;
+			locker->line = line;
+			break;
+		} else if (mp->stats->lockers[i].file == file &&
+			   mp->stats->lockers[i].line == line) {
+			locker = &mp->stats->lockers[i];
+			break;
+		}
+	}
+
 	if (locker != NULL) {
 		locker->count++;
 		timevaladd(&locker->wait_total, &postlock_t);
diff --git a/contrib/bind9/lib/isc/quota.c b/contrib/bind9/lib/isc/quota.c
index 012bfbb38dd4..273a1b2ac6dd 100644
--- a/contrib/bind9/lib/isc/quota.c
+++ b/contrib/bind9/lib/isc/quota.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: quota.c,v 1.11.12.3 2004/03/08 09:04:49 marka Exp $ */
+/* $Id: quota.c,v 1.11.12.5 2005/07/29 00:13:09 marka Exp $ */
 
 #include <config.h>
 
@@ -28,38 +28,45 @@ isc_result_t
 isc_quota_init(isc_quota_t *quota, int max) {
 	quota->max = max;
 	quota->used = 0;
-	quota->soft = ISC_FALSE;
+	quota->soft = 0;
 	return (isc_mutex_init(&quota->lock));
 }
 
 void
 isc_quota_destroy(isc_quota_t *quota) {
 	INSIST(quota->used == 0);
-	quota->max = -1;
-	quota->used = -1;
-	quota->soft = ISC_FALSE;
+	quota->max = 0;
+	quota->used = 0;
+	quota->soft = 0;
 	DESTROYLOCK(&quota->lock);
 }
 
 void
-isc_quota_soft(isc_quota_t *quota, isc_boolean_t soft) {
+isc_quota_soft(isc_quota_t *quota, int soft) {
+	LOCK(&quota->lock);
 	quota->soft = soft;
+	UNLOCK(&quota->lock);
+}
+
+void
+isc_quota_max(isc_quota_t *quota, int max) {
+	LOCK(&quota->lock);
+	quota->max = max;
+	UNLOCK(&quota->lock);
 }
 
 isc_result_t
 isc_quota_reserve(isc_quota_t *quota) {
 	isc_result_t result;
 	LOCK(&quota->lock);
-	if (quota->used < quota->max) {
-		quota->used++;
-		result = ISC_R_SUCCESS;
-	} else {
-		if (quota->soft) {
-			quota->used++;
+	if (quota->max == 0 || quota->used < quota->max) {
+		if (quota->soft == 0 || quota->used < quota->soft)
+			result = ISC_R_SUCCESS;
+		else
 			result = ISC_R_SOFTQUOTA;
-		} else
-			result = ISC_R_QUOTA;
-	}
+		quota->used++;
+	} else
+		result = ISC_R_QUOTA;
 	UNLOCK(&quota->lock);
 	return (result);
 }
diff --git a/contrib/bind9/lib/isc/result.c b/contrib/bind9/lib/isc/result.c
index 5b0ddd3fe14d..fd4e5c6cb98a 100644
--- a/contrib/bind9/lib/isc/result.c
+++ b/contrib/bind9/lib/isc/result.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,10 +15,11 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.c,v 1.56.2.2.8.7 2004/06/11 00:31:01 marka Exp $ */
+/* $Id: result.c,v 1.56.2.2.8.9 2005/06/09 23:54:30 marka Exp $ */
 
 #include <config.h>
 
+#include <stddef.h>
 #include <stdlib.h>
 
 #include <isc/lib.h>
diff --git a/contrib/bind9/lib/isc/rwlock.c b/contrib/bind9/lib/isc/rwlock.c
index 63f0c68de5c2..3e444d8a1125 100644
--- a/contrib/bind9/lib/isc/rwlock.c
+++ b/contrib/bind9/lib/isc/rwlock.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rwlock.c,v 1.33.2.4.2.1 2004/03/06 08:14:35 marka Exp $ */
+/* $Id: rwlock.c,v 1.33.2.4.2.3 2005/03/17 03:58:32 marka Exp $ */
 
 #include <config.h>
 
@@ -109,7 +109,9 @@ isc_rwlock_init(isc_rwlock_t *rwl, unsigned int read_quota,
 				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
 						ISC_MSG_FAILED, "failed"),
 				 isc_result_totext(result));
-		return (ISC_R_UNEXPECTED);
+		result = ISC_R_UNEXPECTED;
+		goto destroy_lock;
+
 	}
 	result = isc_condition_init(&rwl->writeable);
 	if (result != ISC_R_SUCCESS) {
@@ -118,12 +120,20 @@ isc_rwlock_init(isc_rwlock_t *rwl, unsigned int read_quota,
 				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
 						ISC_MSG_FAILED, "failed"),
 				 isc_result_totext(result));
-		return (ISC_R_UNEXPECTED);
+		result = ISC_R_UNEXPECTED;
+		goto destroy_rcond;
 	}
 
 	rwl->magic = RWLOCK_MAGIC;
 
 	return (ISC_R_SUCCESS);
+
+  destroy_rcond:
+	(void)isc_condition_destroy(&rwl->readable);
+  destroy_lock:
+	DESTROYLOCK(&rwl->lock);
+
+	return (result);
 }
 
 static isc_result_t
diff --git a/contrib/bind9/lib/isc/timer.c b/contrib/bind9/lib/isc/timer.c
index f3cdd916f9c1..5426079397e0 100644
--- a/contrib/bind9/lib/isc/timer.c
+++ b/contrib/bind9/lib/isc/timer.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: timer.c,v 1.64.12.9 2004/03/08 09:04:50 marka Exp $ */
+/* $Id: timer.c,v 1.64.12.11 2005/10/27 00:27:29 marka Exp $ */
 
 #include <config.h>
 
@@ -487,7 +487,7 @@ isc_timer_reset(isc_timer_t *timer, isc_timertype_t type,
 	return (result);
 }
 
-isc_result_t
+isc_timertype_t
 isc_timer_gettype(isc_timer_t *timer) {
 	isc_timertype_t t;
 
diff --git a/contrib/bind9/lib/isc/unix/entropy.c b/contrib/bind9/lib/isc/unix/entropy.c
index a2cbb3c6e988..50506634e4cd 100644
--- a/contrib/bind9/lib/isc/unix/entropy.c
+++ b/contrib/bind9/lib/isc/unix/entropy.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: entropy.c,v 1.60.2.3.8.9 2004/03/16 05:02:31 marka Exp $ */
+/* $Id: entropy.c,v 1.60.2.3.8.11 2005/07/12 05:47:43 marka Exp $ */
 
 /*
  * This is the system depenedent part of the ISC entropy API.
@@ -446,16 +446,25 @@ make_nonblock(int fd) {
 	int ret;
 	int flags;
 	char strbuf[ISC_STRERRORSIZE];
+#ifdef USE_FIONBIO_IOCTL
+	int on = 1;
 
+	ret = ioctl(fd, FIONBIO, (char *)&on);
+#else
 	flags = fcntl(fd, F_GETFL, 0);
-	flags |= O_NONBLOCK;
+	flags |= PORT_NONBLOCK;
 	ret = fcntl(fd, F_SETFL, flags);
+#endif
 
 	if (ret == -1) {
 		isc__strerror(errno, strbuf, sizeof(strbuf));
 		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "fcntl(%d, F_SETFL, %d): %s",
-				 fd, flags, strbuf);
+#ifdef USE_FIONBIO_IOCTL
+				 "ioctl(%d, FIONBIO, &on): %s", fd,
+#else
+				 "fcntl(%d, F_SETFL, %d): %s", fd, flags,
+#endif
+				 strbuf);
 
 		return (ISC_R_UNEXPECTED);
 	}
@@ -501,7 +510,7 @@ isc_entropy_createfilesource(isc_entropy_t *ent, const char *fname) {
 	if (is_usocket)
 		fd = socket(PF_UNIX, SOCK_STREAM, 0);
 	else
-		fd = open(fname, O_RDONLY | O_NONBLOCK, 0);
+		fd = open(fname, O_RDONLY | PORT_NONBLOCK, 0);
 
 	if (fd < 0) {
 		ret = isc__errno2result(errno);
diff --git a/contrib/bind9/lib/isc/unix/ifiter_ioctl.c b/contrib/bind9/lib/isc/unix/ifiter_ioctl.c
index 6842c1f35258..0b01b96f942c 100644
--- a/contrib/bind9/lib/isc/unix/ifiter_ioctl.c
+++ b/contrib/bind9/lib/isc/unix/ifiter_ioctl.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ifiter_ioctl.c,v 1.19.2.5.2.15 2004/11/10 22:22:49 marka Exp $ */
+/* $Id: ifiter_ioctl.c,v 1.19.2.5.2.17 2005/10/14 02:13:07 marka Exp $ */
 
 /*
  * Obtain the list of network interfaces using the SIOCGLIFCONF ioctl.
@@ -896,7 +896,9 @@ internal_current(isc_interfaceiter_t *iter) {
  */
 static isc_result_t
 internal_next4(isc_interfaceiter_t *iter) {
+#ifdef ISC_PLATFORM_HAVESALEN
 	struct ifreq *ifrp;
+#endif
 
 	REQUIRE (iter->pos < (unsigned int) iter->ifc.ifc_len);
 
@@ -906,14 +908,14 @@ internal_next4(isc_interfaceiter_t *iter) {
 	if (!iter->first)
 		return (ISC_R_SUCCESS);
 #endif
+#ifdef ISC_PLATFORM_HAVESALEN
 	ifrp = (struct ifreq *)((char *) iter->ifc.ifc_req + iter->pos);
 
-#ifdef ISC_PLATFORM_HAVESALEN
 	if (ifrp->ifr_addr.sa_len > sizeof(struct sockaddr))
 		iter->pos += sizeof(ifrp->ifr_name) + ifrp->ifr_addr.sa_len;
 	else
 #endif
-		iter->pos += sizeof(*ifrp);
+		iter->pos += sizeof(struct ifreq);
 
 	if (iter->pos >= (unsigned int) iter->ifc.ifc_len)
 		return (ISC_R_NOMORE);
@@ -924,21 +926,23 @@ internal_next4(isc_interfaceiter_t *iter) {
 #if defined(SIOCGLIFCONF) && defined(SIOCGLIFADDR)
 static isc_result_t
 internal_next6(isc_interfaceiter_t *iter) {
+#ifdef ISC_PLATFORM_HAVESALEN
 	struct LIFREQ *ifrp;
+#endif
 	
 	if (iter->result6 != ISC_R_SUCCESS && iter->result6 != ISC_R_IGNORE)
 		return (iter->result6);
 
 	REQUIRE(iter->pos6 < (unsigned int) iter->lifc.lifc_len);
 
+#ifdef ISC_PLATFORM_HAVESALEN
 	ifrp = (struct LIFREQ *)((char *) iter->lifc.lifc_req + iter->pos6);
 
-#ifdef ISC_PLATFORM_HAVESALEN
 	if (ifrp->lifr_addr.sa_len > sizeof(struct sockaddr))
 		iter->pos6 += sizeof(ifrp->lifr_name) + ifrp->lifr_addr.sa_len;
 	else
 #endif
-		iter->pos6 += sizeof(*ifrp);
+		iter->pos6 += sizeof(struct LIFREQ);
 
 	if (iter->pos6 >= (unsigned int) iter->lifc.lifc_len)
 		return (ISC_R_NOMORE);
diff --git a/contrib/bind9/lib/isc/unix/ifiter_sysctl.c b/contrib/bind9/lib/isc/unix/ifiter_sysctl.c
index c0f678b9cf05..b10a2d2090f0 100644
--- a/contrib/bind9/lib/isc/unix/ifiter_sysctl.c
+++ b/contrib/bind9/lib/isc/unix/ifiter_sysctl.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ifiter_sysctl.c,v 1.14.12.7 2004/03/08 09:04:56 marka Exp $ */
+/* $Id: ifiter_sysctl.c,v 1.14.12.9 2005/03/17 03:58:33 marka Exp $ */
 
 /*
  * Obtain the list of network interfaces using sysctl.
@@ -251,7 +251,7 @@ internal_current(isc_interfaceiter_t *iter) {
 				 iter->current.name);
 
 		if (dst_sa != NULL &&
-		    (iter->current.flags & IFF_POINTOPOINT) != 0)
+		    (iter->current.flags & INTERFACE_F_POINTTOPOINT) != 0)
 			get_addr(family, &iter->current.dstaddress, dst_sa,
 				 iter->current.name);
 
diff --git a/contrib/bind9/lib/isc/unix/net.c b/contrib/bind9/lib/isc/unix/net.c
index 05f412153ce4..e0aeccbbbf4d 100644
--- a/contrib/bind9/lib/isc/unix/net.c
+++ b/contrib/bind9/lib/isc/unix/net.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: net.c,v 1.22.2.2.10.7 2004/04/29 01:31:22 marka Exp $ */
+/* $Id: net.c,v 1.22.2.2.10.9 2005/03/17 03:58:33 marka Exp $ */
 
 #include <config.h>
 
@@ -237,6 +237,7 @@ initialize_ipv6only(void) {
 }
 #endif /* IPV6_V6ONLY */
 
+#ifdef ISC_PLATFORM_HAVEIN6PKTINFO
 static void
 try_ipv6pktinfo(void) {
 	int s, on;
@@ -289,6 +290,7 @@ initialize_ipv6pktinfo(void) {
 	RUNTIME_CHECK(isc_once_do(&once_ipv6pktinfo,
 				  try_ipv6pktinfo) == ISC_R_SUCCESS);
 }
+#endif /* ISC_PLATFORM_HAVEIN6PKTINFO */
 #endif /* WANT_IPV6 */
 
 isc_result_t
@@ -306,12 +308,14 @@ isc_net_probe_ipv6only(void) {
 isc_result_t
 isc_net_probe_ipv6pktinfo(void) {
 #ifdef ISC_PLATFORM_HAVEIPV6
+#ifdef ISC_PLATFORM_HAVEIN6PKTINFO
 #ifdef WANT_IPV6
 	initialize_ipv6pktinfo();
 #else
 	ipv6pktinfo_result = ISC_R_NOTFOUND;
 #endif
 #endif
+#endif
 	return (ipv6pktinfo_result);
 }
 
diff --git a/contrib/bind9/lib/isc/unix/os.c b/contrib/bind9/lib/isc/unix/os.c
index 0838e12770a0..4d34d8ce6f47 100644
--- a/contrib/bind9/lib/isc/unix/os.c
+++ b/contrib/bind9/lib/isc/unix/os.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: os.c,v 1.11.12.4 2004/05/18 01:39:20 marka Exp $ */
+/* $Id: os.c,v 1.11.12.6 2005/10/14 02:13:07 marka Exp $ */
 
 #include <config.h>
 
@@ -26,6 +26,7 @@
 
 #include <unistd.h>
 
+#ifndef __hpux
 static inline long
 sysconf_ncpus(void) {
 #if defined(_SC_NPROCESSORS_ONLN)
@@ -36,6 +37,7 @@ sysconf_ncpus(void) {
 	return (0);
 #endif
 }
+#endif
 #endif /* HAVE_SYSCONF */
 
 
diff --git a/contrib/bind9/lib/isc/unix/socket.c b/contrib/bind9/lib/isc/unix/socket.c
index f23b72b0f879..595990f995c5 100644
--- a/contrib/bind9/lib/isc/unix/socket.c
+++ b/contrib/bind9/lib/isc/unix/socket.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.c,v 1.207.2.19.2.15 2004/11/18 21:31:16 marka Exp $ */
+/* $Id: socket.c,v 1.207.2.19.2.22 2005/11/03 23:08:42 marka Exp $ */
 
 #include <config.h>
 
@@ -280,7 +280,7 @@ socket_log(isc_socket_t *sock, isc_sockaddr_t *address,
 	   const char *fmt, ...)
 {
 	char msgbuf[2048];
-	char peerbuf[256];
+	char peerbuf[ISC_SOCKADDR_FORMATSIZE];
 	va_list ap;
 
 	if (! isc_log_wouldlog(isc_lctx, level))
@@ -363,7 +363,7 @@ select_poke(isc_socketmgr_t *mgr, int fd, int msg) {
 		}
 #endif
 	} while (cc < 0 && SOFT_ERROR(errno));
-			        
+
 	if (cc < 0) {
 		isc__strerror(errno, strbuf, sizeof(strbuf));
 		FATAL_ERROR(__FILE__, __LINE__,
@@ -389,6 +389,7 @@ select_readmsg(isc_socketmgr_t *mgr, int *fd, int *msg) {
 	cc = read(mgr->pipe_fds[0], buf, sizeof(buf));
 	if (cc < 0) {
 		*msg = SELECT_POKE_NOTHING;
+		*fd = -1;	/* Silence compiler. */
 		if (SOFT_ERROR(errno))
 			return;
 
@@ -429,16 +430,25 @@ make_nonblock(int fd) {
 	int ret;
 	int flags;
 	char strbuf[ISC_STRERRORSIZE];
+#ifdef USE_FIONBIO_IOCTL
+	int on = 1;
 
+	ret = ioctl(fd, FIONBIO, (char *)&on);
+#else
 	flags = fcntl(fd, F_GETFL, 0);
-	flags |= O_NONBLOCK;
+	flags |= PORT_NONBLOCK;
 	ret = fcntl(fd, F_SETFL, flags);
+#endif
 
 	if (ret == -1) {
 		isc__strerror(errno, strbuf, sizeof(strbuf));
 		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "fcntl(%d, F_SETFL, %d): %s",
-				 fd, flags, strbuf);
+#ifdef USE_FIONBIO_IOCTL
+				 "ioctl(%d, FIONBIO, &on): %s", fd,
+#else
+				 "fcntl(%d, F_SETFL, %d): %s", fd, flags,
+#endif
+				 strbuf);
 
 		return (ISC_R_UNEXPECTED);
 	}
@@ -461,7 +471,11 @@ cmsg_len(ISC_SOCKADDR_LEN_T len) {
 #else
 	ISC_SOCKADDR_LEN_T hdrlen;
 
-	hdrlen = (ISC_SOCKADDR_LEN_T)CMSG_DATA(NULL); /* XXX */
+	/*
+	 * Cast NULL so that any pointer arithmetic performed by CMSG_DATA
+	 * is correct.
+	 */
+	hdrlen = (ISC_SOCKADDR_LEN_T)CMSG_DATA(((struct cmsghdr *)NULL));
 	return (hdrlen + len);
 #endif
 }
@@ -1222,7 +1236,7 @@ allocate_socket(isc_socketmgr_t *manager, isc_sockettype_t type,
 	cmsgbuflen += cmsg_space(sizeof(struct timeval));
 #endif
 	sock->recvcmsgbuflen = cmsgbuflen;
-	if (sock->recvcmsgbuflen != 0) {
+	if (sock->recvcmsgbuflen != 0U) {
 		sock->recvcmsgbuf = isc_mem_get(manager->mctx, cmsgbuflen);
 		if (sock->recvcmsgbuf == NULL)
 			goto error;
@@ -1233,7 +1247,7 @@ allocate_socket(isc_socketmgr_t *manager, isc_sockettype_t type,
 	cmsgbuflen = cmsg_space(sizeof(struct in6_pktinfo));
 #endif
 	sock->sendcmsgbuflen = cmsgbuflen;
-	if (sock->sendcmsgbuflen != 0) {
+	if (sock->sendcmsgbuflen != 0U) {
 		sock->sendcmsgbuf = isc_mem_get(manager->mctx, cmsgbuflen);
 		if (sock->sendcmsgbuf == NULL)
 			goto error;
@@ -1348,6 +1362,7 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type,
 	int on = 1;
 #endif
 	char strbuf[ISC_STRERRORSIZE];
+	const char *err = "socket";
 
 	REQUIRE(VALID_MANAGER(manager));
 	REQUIRE(socketp != NULL && *socketp == NULL);
@@ -1367,23 +1382,24 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type,
 	}
 
 #ifdef F_DUPFD
-        /*
-         * Leave a space for stdio to work in.
-         */
-        if (sock->fd >= 0 && sock->fd < 20) {
-                int new, tmp;
-                new = fcntl(sock->fd, F_DUPFD, 20);
-                tmp = errno;
-                (void)close(sock->fd);
-                errno = tmp;
-                sock->fd = new;
-        }
+	/*
+	 * Leave a space for stdio to work in.
+	 */
+	if (sock->fd >= 0 && sock->fd < 20) {
+		int new, tmp;
+		new = fcntl(sock->fd, F_DUPFD, 20);
+		tmp = errno;
+		(void)close(sock->fd);
+		errno = tmp;
+		sock->fd = new;
+		err = "isc_socket_create: fcntl";
+	}
 #endif
 
 	if (sock->fd >= (int)FD_SETSIZE) {
 		(void)close(sock->fd);
 		isc_log_iwrite(isc_lctx, ISC_LOGCATEGORY_GENERAL,
-			      ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR,
+			       ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR,
 			       isc_msgcat, ISC_MSGSET_SOCKET,
 			       ISC_MSG_TOOMANYFDS,
 			       "%s: too many open file descriptors", "socket");
@@ -1413,7 +1429,7 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type,
 		default:
 			isc__strerror(errno, strbuf, sizeof(strbuf));
 			UNEXPECTED_ERROR(__FILE__, __LINE__,
-					 "socket() %s: %s",
+					 "%s() %s: %s", err,
 					 isc_msgcat_get(isc_msgcat,
 							ISC_MSGSET_GENERAL,
 							ISC_MSG_FAILED,
@@ -1464,7 +1480,7 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type,
 #endif /* SO_TIMESTAMP */
 
 #if defined(ISC_PLATFORM_HAVEIPV6)
-		if (pf == AF_INET6 && sock->recvcmsgbuflen == 0) {
+		if (pf == AF_INET6 && sock->recvcmsgbuflen == 0U) {
 			/*
 			 * Warn explicitly because this anomaly can be hidden
 			 * in usual operation (and unexpectedly appear later).
@@ -1764,6 +1780,7 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 	int fd;
 	isc_result_t result = ISC_R_SUCCESS;
 	char strbuf[ISC_STRERRORSIZE];
+	const char *err = "accept";
 
 	UNUSED(me);
 
@@ -1817,17 +1834,18 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 		    (void *)&addrlen);
 
 #ifdef F_DUPFD
-        /*
-         * Leave a space for stdio to work in.
-         */
-        if (fd >= 0 && fd < 20) {
-                int new, tmp;
-                new = fcntl(fd, F_DUPFD, 20);
-                tmp = errno;
-                (void)close(fd);
-                errno = tmp;
-                fd = new;
-        }
+	/*
+	 * Leave a space for stdio to work in.
+	 */
+	if (fd >= 0 && fd < 20) {
+		int new, tmp;
+		new = fcntl(fd, F_DUPFD, 20);
+		tmp = errno;
+		(void)close(fd);
+		errno = tmp;
+		fd = new;
+		err = "fcntl";
+	}
 #endif
 
 	if (fd < 0) {
@@ -1856,7 +1874,7 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 		}
 		isc__strerror(errno, strbuf, sizeof(strbuf));
 		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "internal_accept: accept() %s: %s",
+				 "internal_accept: %s() %s: %s", err,
 				 isc_msgcat_get(isc_msgcat,
 						ISC_MSGSET_GENERAL,
 						ISC_MSG_FAILED,
@@ -1865,7 +1883,7 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 		fd = -1;
 		result = ISC_R_UNEXPECTED;
 	} else {
-		if (addrlen == 0) {
+		if (addrlen == 0U) {
 			UNEXPECTED_ERROR(__FILE__, __LINE__,
 					 "internal_accept(): "
 					 "accept() failed to return "
@@ -2197,7 +2215,7 @@ watcher(void *uap) {
 			cc = select(maxfd, &readfds, &writefds, NULL, NULL);
 			if (cc < 0) {
 				if (!SOFT_ERROR(errno)) {
-				        isc__strerror(errno, strbuf,
+					isc__strerror(errno, strbuf,
 						      sizeof(strbuf));
 					FATAL_ERROR(__FILE__, __LINE__,
 						    "select() %s: %s",
@@ -3094,6 +3112,7 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr,
 			ERROR_MATCH(ENOBUFS, ISC_R_NORESOURCES);
 			ERROR_MATCH(EPERM, ISC_R_HOSTUNREACH);
 			ERROR_MATCH(EPIPE, ISC_R_NOTCONNECTED);
+			ERROR_MATCH(ECONNRESET, ISC_R_CONNECTIONRESET);
 #undef ERROR_MATCH
 		}
 
@@ -3163,6 +3182,7 @@ internal_connect(isc_task_t *me, isc_event_t *ev) {
 	int cc;
 	ISC_SOCKADDR_LEN_T optlen;
 	char strbuf[ISC_STRERRORSIZE];
+	char peerbuf[ISC_SOCKADDR_FORMATSIZE];
 
 	UNUSED(me);
 	INSIST(ev->ev_type == ISC_SOCKEVENT_INTW);
@@ -3239,13 +3259,16 @@ internal_connect(isc_task_t *me, isc_event_t *ev) {
 			ERROR_MATCH(EPERM, ISC_R_HOSTUNREACH);
 			ERROR_MATCH(EPIPE, ISC_R_NOTCONNECTED);
 			ERROR_MATCH(ETIMEDOUT, ISC_R_TIMEDOUT);
+			ERROR_MATCH(ECONNRESET, ISC_R_CONNECTIONRESET);
 #undef ERROR_MATCH
 		default:
 			dev->result = ISC_R_UNEXPECTED;
+			isc_sockaddr_format(&sock->address, peerbuf,
+					    sizeof(peerbuf));
 			isc__strerror(errno, strbuf, sizeof(strbuf));
 			UNEXPECTED_ERROR(__FILE__, __LINE__,
-					 "internal_connect: connect() %s",
-					 strbuf);
+					 "internal_connect: connect(%s) %s",
+					 peerbuf, strbuf);
 		}
 	} else {
 		dev->result = ISC_R_SUCCESS;
@@ -3407,7 +3430,7 @@ isc_socket_cancel(isc_socket_t *sock, isc_task_t *task, unsigned int how) {
 				dev->result = ISC_R_CANCELED;
 				dev->ev_sender = sock;
 				isc_task_sendanddetach(&current_task,
-					        ISC_EVENT_PTR(&dev));
+						       ISC_EVENT_PTR(&dev));
 			}
 
 			dev = next;
diff --git a/contrib/bind9/lib/isc/unix/stdtime.c b/contrib/bind9/lib/isc/unix/stdtime.c
index 8946a605ca74..b8d818dcfd7a 100644
--- a/contrib/bind9/lib/isc/unix/stdtime.c
+++ b/contrib/bind9/lib/isc/unix/stdtime.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,10 +15,11 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stdtime.c,v 1.11.2.1.10.3 2004/03/08 09:04:57 marka Exp $ */
+/* $Id: stdtime.c,v 1.11.2.1.10.5 2005/06/09 23:54:31 marka Exp $ */
 
 #include <config.h>
 
+#include <stddef.h>	/* NULL */
 #include <stdlib.h>	/* NULL */
 #include <syslog.h>
 
diff --git a/contrib/bind9/lib/isccfg/api b/contrib/bind9/lib/isccfg/api
index 7e9f0b651e24..59ed93b01104 100644
--- a/contrib/bind9/lib/isccfg/api
+++ b/contrib/bind9/lib/isccfg/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 1
-LIBREVISION = 5
+LIBREVISION = 6
 LIBAGE = 0
diff --git a/contrib/bind9/lib/isccfg/namedconf.c b/contrib/bind9/lib/isccfg/namedconf.c
index 3321bd6d118b..bfc5dda425e6 100644
--- a/contrib/bind9/lib/isccfg/namedconf.c
+++ b/contrib/bind9/lib/isccfg/namedconf.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: namedconf.c,v 1.21.44.29 2004/10/17 23:19:51 marka Exp $ */
+/* $Id: namedconf.c,v 1.21.44.32 2005/10/26 05:06:40 marka Exp $ */
 
 #include <config.h>
 
@@ -479,7 +479,7 @@ static cfg_type_t cfg_type_hostname = {
 };
 
 /*
- * "server-id" arguement.
+ * "server-id" argument.
  */
 
 static isc_result_t
@@ -619,6 +619,7 @@ options_clauses[] = {
 	{ "use-id-pool", &cfg_type_boolean, CFG_CLAUSEFLAG_OBSOLETE },
 	{ "use-ixfr", &cfg_type_boolean, 0 },
 	{ "version", &cfg_type_qstringornone, 0 },
+	{ "flush-zones-on-shutdown", &cfg_type_boolean, 0 },
 	{ NULL, NULL, 0 }
 };
 
diff --git a/contrib/bind9/lib/lwres/Makefile.in b/contrib/bind9/lib/lwres/Makefile.in
index 548c5d5129a0..024b988492a7 100644
--- a/contrib/bind9/lib/lwres/Makefile.in
+++ b/contrib/bind9/lib/lwres/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.25.12.6 2004/08/28 06:25:23 marka Exp $
+# $Id: Makefile.in,v 1.25.12.8 2005/06/09 23:54:32 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -35,14 +35,16 @@ OBJS =		context.@O@ gai_strerror.@O@ getaddrinfo.@O@ gethost.@O@ \
 		getipnode.@O@ getnameinfo.@O@ getrrset.@O@ herror.@O@ \
 		lwbuffer.@O@ lwconfig.@O@ lwpacket.@O@ lwresutil.@O@ \
 		lwres_gabn.@O@ lwres_gnba.@O@ lwres_grbn.@O@ lwres_noop.@O@ \
-		lwinetaton.@O@ lwinetpton.@O@ lwinetntop.@O@ print.@O@
+		lwinetaton.@O@ lwinetpton.@O@ lwinetntop.@O@ print.@O@ \
+		strtoul.@O@
 
 # Alphabetically
 SRCS =		context.c gai_strerror.c getaddrinfo.c gethost.c \
 		getipnode.c getnameinfo.c getrrset.c herror.c \
 		lwbuffer.c lwconfig.c lwpacket.c lwresutil.c \
 		lwres_gabn.c lwres_gnba.c lwres_grbn.c lwres_noop.c \
-		lwinetaton.c lwinetpton.c lwinetntop.c print.c
+		lwinetaton.c lwinetpton.c lwinetntop.c print.c \
+		strtoul.c
 
 LIBS =		@LIBS@
 
diff --git a/contrib/bind9/lib/lwres/api b/contrib/bind9/lib/lwres/api
index 01be87336cb5..0ab1e92dc29e 100644
--- a/contrib/bind9/lib/lwres/api
+++ b/contrib/bind9/lib/lwres/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 3
-LIBREVISION = 2
-LIBAGE = 2
+LIBINTERFACE = 10
+LIBREVISION = 1
+LIBAGE = 1
diff --git a/contrib/bind9/lib/lwres/getaddrinfo.c b/contrib/bind9/lib/lwres/getaddrinfo.c
index 86f48aa9ffd2..c06327446b34 100644
--- a/contrib/bind9/lib/lwres/getaddrinfo.c
+++ b/contrib/bind9/lib/lwres/getaddrinfo.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * This code is derived from software contributed to ISC by
@@ -18,17 +18,17 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getaddrinfo.c,v 1.41.206.1 2004/03/06 08:15:30 marka Exp $ */
+/* $Id: getaddrinfo.c,v 1.41.206.3 2005/06/09 23:54:33 marka Exp $ */
 
 #include <config.h>
 
 #include <string.h>
 #include <errno.h>
-#include <stdlib.h>
 
 #include <lwres/lwres.h>
 #include <lwres/net.h>
 #include <lwres/netdb.h>
+#include <lwres/stdlib.h>
 
 #define SA(addr)	((struct sockaddr *)(addr))
 #define SIN(addr)	((struct sockaddr_in *)(addr))
diff --git a/contrib/bind9/lib/lwres/getipnode.c b/contrib/bind9/lib/lwres/getipnode.c
index 5bda15e6e04b..9b1a07bdda7b 100644
--- a/contrib/bind9/lib/lwres/getipnode.c
+++ b/contrib/bind9/lib/lwres/getipnode.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getipnode.c,v 1.30.2.4.2.4 2004/03/06 08:15:31 marka Exp $ */
+/* $Id: getipnode.c,v 1.30.2.4.2.6 2005/04/29 00:03:32 marka Exp $ */
 
 #include <config.h>
 
@@ -331,6 +331,8 @@ lwres_getipnodebyaddr(const void *src, size_t len, int af, int *error_num) {
 		n = lwres_getnamebyaddr(lwrctx, LWRES_ADDRTYPE_V6, IN6ADDRSZ,
 					src, &by);
 	if (n != 0) {
+		lwres_conf_clear(lwrctx);
+		lwres_context_destroy(&lwrctx);
 		*error_num = HOST_NOT_FOUND;
 		return (NULL);
 	}
@@ -338,6 +340,7 @@ lwres_getipnodebyaddr(const void *src, size_t len, int af, int *error_num) {
 	lwres_gnbaresponse_free(lwrctx, &by);
 	if (he1 == NULL)
 		*error_num = NO_RECOVERY;
+	lwres_conf_clear(lwrctx);
 	lwres_context_destroy(&lwrctx);
 	return (he1);
 }
diff --git a/contrib/bind9/lib/lwres/include/lwres/platform.h.in b/contrib/bind9/lib/lwres/include/lwres/platform.h.in
index 9c6502b5ae67..e995aa46c0e5 100644
--- a/contrib/bind9/lib/lwres/include/lwres/platform.h.in
+++ b/contrib/bind9/lib/lwres/include/lwres/platform.h.in
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: platform.h.in,v 1.12.2.1.10.2 2004/08/28 06:25:26 marka Exp $ */
+/* $Id: platform.h.in,v 1.12.2.1.10.5 2005/06/08 02:08:32 marka Exp $ */
 
 #ifndef LWRES_PLATFORM_H
 #define LWRES_PLATFORM_H 1
@@ -88,6 +88,16 @@
  */
 @LWRES_PLATFORM_NEEDSPRINTF@
 
+/*
+ * The printf format string modifier to use with lwres_uint64_t values.
+ */
+@LWRES_PLATFORM_QUADFORMAT@
+
+/*! \brief
+ * Define if this system needs strtoul.
+ */
+@LWRES_PLATFORM_NEEDSTRTOUL@
+
 #ifndef LWRES_PLATFORM_USEDECLSPEC
 #define LIBLWRES_EXTERNAL_DATA
 #else
diff --git a/contrib/bind9/lib/lwres/lwconfig.c b/contrib/bind9/lib/lwres/lwconfig.c
index 9fc7825060e7..7fc2c5d0efd3 100644
--- a/contrib/bind9/lib/lwres/lwconfig.c
+++ b/contrib/bind9/lib/lwres/lwconfig.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwconfig.c,v 1.33.2.1.2.5 2004/03/08 09:05:10 marka Exp $ */
+/* $Id: lwconfig.c,v 1.33.2.1.2.8 2005/06/08 02:35:21 marka Exp $ */
 
 /***
  *** Module for parsing resolv.conf files.
@@ -277,6 +277,7 @@ lwres_conf_parsenameserver(lwres_context_t *ctx,  FILE *fp) {
 	char word[LWRES_CONFMAXLINELEN];
 	int res;
 	lwres_conf_t *confdata;
+	lwres_addr_t address;
 
 	confdata = &ctx->confdata;
 
@@ -292,10 +293,9 @@ lwres_conf_parsenameserver(lwres_context_t *ctx,  FILE *fp) {
 	if (res != EOF && res != '\n')
 		return (LWRES_R_FAILURE); /* Extra junk on line. */
 
-	res = lwres_create_addr(word,
-				&confdata->nameservers[confdata->nsnext++], 1);
-	if (res != LWRES_R_SUCCESS)
-		return (res);
+	res = lwres_create_addr(word, &address, 1);
+	if (res == LWRES_R_SUCCESS)
+		confdata->nameservers[confdata->nsnext++] = address;
 
 	return (LWRES_R_SUCCESS);
 }
diff --git a/contrib/bind9/lib/lwres/lwinetntop.c b/contrib/bind9/lib/lwres/lwinetntop.c
index f4af00d102e4..78cd0b033e33 100644
--- a/contrib/bind9/lib/lwres/lwinetntop.c
+++ b/contrib/bind9/lib/lwres/lwinetntop.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -17,7 +17,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static char rcsid[] =
-	"$Id: lwinetntop.c,v 1.9.12.3 2004/08/28 06:25:24 marka Exp $";
+	"$Id: lwinetntop.c,v 1.9.12.5 2005/11/04 00:16:34 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
@@ -126,7 +126,9 @@ inet_ntop6(const unsigned char *src, char *dst, size_t size) {
 	for (i = 0; i < NS_IN6ADDRSZ; i++)
 		words[i / 2] |= (src[i] << ((1 - (i % 2)) << 3));
 	best.base = -1;
+	best.len = 0;
 	cur.base = -1;
+	cur.len = 0;
 	for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) {
 		if (words[i] == 0) {
 			if (cur.base == -1)
diff --git a/contrib/bind9/lib/lwres/lwinetpton.c b/contrib/bind9/lib/lwres/lwinetpton.c
index 280b077cefca..e24334b1c82d 100644
--- a/contrib/bind9/lib/lwres/lwinetpton.c
+++ b/contrib/bind9/lib/lwres/lwinetpton.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +16,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static char rcsid[] = "$Id: lwinetpton.c,v 1.6.206.1 2004/03/06 08:15:32 marka Exp $";
+static char rcsid[] = "$Id: lwinetpton.c,v 1.6.206.3 2005/03/31 23:56:15 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
@@ -129,7 +129,7 @@ inet_pton6(const char *src, unsigned char *dst) {
 			  xdigits_u[] = "0123456789ABCDEF";
 	unsigned char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp;
 	const char *xdigits, *curtok;
-	int ch, saw_xdigit;
+	int ch, seen_xdigits;
 	unsigned int val;
 
 	memset((tp = tmp), '\0', NS_IN6ADDRSZ);
@@ -140,7 +140,7 @@ inet_pton6(const char *src, unsigned char *dst) {
 		if (*++src != ':')
 			return (0);
 	curtok = src;
-	saw_xdigit = 0;
+	seen_xdigits = 0;
 	val = 0;
 	while ((ch = *src++) != '\0') {
 		const char *pch;
@@ -150,14 +150,13 @@ inet_pton6(const char *src, unsigned char *dst) {
 		if (pch != NULL) {
 			val <<= 4;
 			val |= (pch - xdigits);
-			if (val > 0xffff)
+			if (++seen_xdigits > 4)
 				return (0);
-			saw_xdigit = 1;
 			continue;
 		}
 		if (ch == ':') {
 			curtok = src;
-			if (!saw_xdigit) {
+			if (!seen_xdigits) {
 				if (colonp)
 					return (0);
 				colonp = tp;
@@ -167,19 +166,19 @@ inet_pton6(const char *src, unsigned char *dst) {
 				return (0);
 			*tp++ = (unsigned char) (val >> 8) & 0xff;
 			*tp++ = (unsigned char) val & 0xff;
-			saw_xdigit = 0;
+			seen_xdigits = 0;
 			val = 0;
 			continue;
 		}
 		if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) &&
 		    inet_pton4(curtok, tp) > 0) {
 			tp += NS_INADDRSZ;
-			saw_xdigit = 0;
+			seen_xdigits = 0;
 			break;	/* '\0' was seen by inet_pton4(). */
 		}
 		return (0);
 	}
-	if (saw_xdigit) {
+	if (seen_xdigits) {
 		if (tp + NS_INT16SZ > endp)
 			return (0);
 		*tp++ = (unsigned char) (val >> 8) & 0xff;
diff --git a/contrib/bind9/lib/lwres/man/lwres.3 b/contrib/bind9/lib/lwres/man/lwres.3
index ad125d26d017..3411eac92b8e 100644
--- a/contrib/bind9/lib/lwres/man/lwres.3
+++ b/contrib/bind9/lib/lwres/man/lwres.3
@@ -1,144 +1,142 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres.3,v 1.15.206.1 2004/03/06 07:41:42 marka Exp $
+.\" $Id: lwres.3,v 1.15.206.5 2005/10/13 02:33:58 marka Exp $
 .\"
-.TH "LWRES" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres \- introduction to the lightweight resolver library
-.SH SYNOPSIS
-\fB#include <lwres/lwres.h>\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwres.h>
+.fi
 .SH "DESCRIPTION"
 .PP
-The BIND 9 lightweight resolver library is a simple, name service
-independent stub resolver library. It provides hostname-to-address
-and address-to-hostname lookup services to applications by
-transmitting lookup requests to a resolver daemon
+The BIND 9 lightweight resolver library is a simple, name service independent stub resolver library. It provides hostname\-to\-address and address\-to\-hostname lookup services to applications by transmitting lookup requests to a resolver daemon
 \fBlwresd\fR
-running on the local host. The resover daemon performs the
-lookup using the DNS or possibly other name service protocols,
-and returns the results to the application through the library. 
-The library and resolver daemon communicate using a simple
-UDP-based protocol.
+running on the local host. The resover daemon performs the lookup using the DNS or possibly other name service protocols, and returns the results to the application through the library. The library and resolver daemon communicate using a simple UDP\-based protocol.
 .SH "OVERVIEW"
 .PP
-The lwresd library implements multiple name service APIs.
-The standard
+The lwresd library implements multiple name service APIs. The standard
 \fBgethostbyname()\fR,
 \fBgethostbyaddr()\fR,
 \fBgethostbyname_r()\fR,
 \fBgethostbyaddr_r()\fR,
 \fBgetaddrinfo()\fR,
-\fBgetipnodebyname()\fR,
-and
+\fBgetipnodebyname()\fR, and
 \fBgetipnodebyaddr()\fR
-functions are all supported. To allow the lwres library to coexist
-with system libraries that define functions of the same name,
-the library defines these functions with names prefixed by
-lwres_.
-To define the standard names, applications must include the
-header file
+functions are all supported. To allow the lwres library to coexist with system libraries that define functions of the same name, the library defines these functions with names prefixed by
+lwres_. To define the standard names, applications must include the header file
 \fI<lwres/netdb.h>\fR
-which contains macro definitions mapping the standard function names
-into
+which contains macro definitions mapping the standard function names into
 lwres_
-prefixed ones. Operating system vendors who integrate the lwres
-library into their base distributions should rename the functions
-in the library proper so that the renaming macros are not needed.
+prefixed ones. Operating system vendors who integrate the lwres library into their base distributions should rename the functions in the library proper so that the renaming macros are not needed.
 .PP
 The library also provides a native API consisting of the functions
 \fBlwres_getaddrsbyname()\fR
 and
-\fBlwres_getnamebyaddr()\fR.
-These may be called by applications that require more detailed
-control over the lookup process than the standard functions
-provide.
-.PP
-In addition to these name service independent address lookup
-functions, the library implements a new, experimental API
-for looking up arbitrary DNS resource records, using the
+\fBlwres_getnamebyaddr()\fR. These may be called by applications that require more detailed control over the lookup process than the standard functions provide.
+.PP
+In addition to these name service independent address lookup functions, the library implements a new, experimental API for looking up arbitrary DNS resource records, using the
 \fBlwres_getaddrsbyname()\fR
 function.
 .PP
-Finally, there is a low-level API for converting lookup
-requests and responses to and from raw lwres protocol packets. 
-This API can be used by clients requiring nonblocking operation, 
-and is also used when implementing the server side of the lwres
-protocol, for example in the
+Finally, there is a low\-level API for converting lookup requests and responses to and from raw lwres protocol packets. This API can be used by clients requiring nonblocking operation, and is also used when implementing the server side of the lwres protocol, for example in the
 \fBlwresd\fR
-resolver daemon. The use of this low-level API in clients
-and servers is outlined in the following sections.
-.SH "CLIENT-SIDE LOW-LEVEL API CALL FLOW"
+resolver daemon. The use of this low\-level API in clients and servers is outlined in the following sections.
+.SH "CLIENT\-SIDE LOW\-LEVEL API CALL FLOW"
 .PP
-When a client program wishes to make an lwres request using the
-native low-level API, it typically performs the following 
-sequence of actions.
+When a client program wishes to make an lwres request using the native low\-level API, it typically performs the following sequence of actions.
 .PP
-(1) Allocate or use an existing \fBlwres_packet_t\fR,
-called pkt below.
+(1) Allocate or use an existing
+\fBlwres_packet_t\fR, called
+\fIpkt\fR
+below.
 .PP
-(2) Set \fBpkt.recvlength\fR to the maximum length we will accept. 
-This is done so the receiver of our packets knows how large our receive 
-buffer is. The "default" is a constant in
-\fIlwres.h\fR: LWRES_RECVLENGTH = 4096.
+(2) Set
+pkt.recvlength
+to the maximum length we will accept. This is done so the receiver of our packets knows how large our receive buffer is. The "default" is a constant in
+\fIlwres.h\fR:
+\fBLWRES_RECVLENGTH = 4096\fR.
 .PP
-(3) Set \fBpkt.serial\fR
-to a unique serial number. This value is echoed
-back to the application by the remote server.
+(3) Set
+pkt.serial
+to a unique serial number. This value is echoed back to the application by the remote server.
 .PP
-(4) Set \fBpkt.pktflags\fR. Usually this is set to 0.
+(4) Set
+pkt.pktflags. Usually this is set to 0.
 .PP
-(5) Set \fBpkt.result\fR to 0.
+(5) Set
+pkt.result
+to 0.
 .PP
-(6) Call \fBlwres_*request_render()\fR, 
-or marshall in the data using the primitives
-such as \fBlwres_packet_render()\fR
+(6) Call
+\fBlwres_*request_render()\fR, or marshall in the data using the primitives such as
+\fBlwres_packet_render()\fR
 and storing the packet data.
 .PP
 (7) Transmit the resulting buffer.
 .PP
-(8) Call \fBlwres_*response_parse()\fR
+(8) Call
+\fBlwres_*response_parse()\fR
 to parse any packets received.
 .PP
-(9) Verify that the opcode and serial match a request, and process the
-packet specific information contained in the body.
-.SH "SERVER-SIDE LOW-LEVEL API CALL FLOW"
+(9) Verify that the opcode and serial match a request, and process the packet specific information contained in the body.
+.SH "SERVER\-SIDE LOW\-LEVEL API CALL FLOW"
 .PP
-When implementing the server side of the lightweight resolver
-protocol using the lwres library, a sequence of actions like the
-following is typically involved in processing each request packet.
+When implementing the server side of the lightweight resolver protocol using the lwres library, a sequence of actions like the following is typically involved in processing each request packet.
 .PP
-Note that the same \fBlwres_packet_t\fR is used
-in both the \fB_parse()\fR and \fB_render()\fR calls,
-with only a few modifications made
-to the packet header's contents between uses. This method is recommended
-as it keeps the serial, opcode, and other fields correct.
+Note that the same
+\fBlwres_packet_t\fR
+is used in both the
+\fB_parse()\fR
+and
+\fB_render()\fR
+calls, with only a few modifications made to the packet header's contents between uses. This method is recommended as it keeps the serial, opcode, and other fields correct.
 .PP
-(1) When a packet is received, call \fBlwres_*request_parse()\fR to
-unmarshall it. This returns a \fBlwres_packet_t\fR (also called pkt, below)
-as well as a data specific type, such as \fBlwres_gabnrequest_t\fR.
+(1) When a packet is received, call
+\fBlwres_*request_parse()\fR
+to unmarshall it. This returns a
+\fBlwres_packet_t\fR
+(also called
+\fIpkt\fR, below) as well as a data specific type, such as
+\fBlwres_gabnrequest_t\fR.
 .PP
 (2) Process the request in the data specific type.
 .PP
-(3) Set the \fBpkt.result\fR,
-\fBpkt.recvlength\fR as above. All other fields can
-be left untouched since they were filled in by the \fB*_parse()\fR call
-above. If using \fBlwres_*response_render()\fR,
-\fBpkt.pktflags\fR will be set up
-properly. Otherwise, the LWRES_LWPACKETFLAG_RESPONSE bit should be
-set.
+(3) Set the
+pkt.result,
+pkt.recvlength
+as above. All other fields can be left untouched since they were filled in by the
+\fB*_parse()\fR
+call above. If using
+\fBlwres_*response_render()\fR,
+pkt.pktflags
+will be set up properly. Otherwise, the
+\fBLWRES_LWPACKETFLAG_RESPONSE\fR
+bit should be set.
 .PP
 (4) Call the data specific rendering function, such as
 \fBlwres_gabnresponse_render()\fR.
diff --git a/contrib/bind9/lib/lwres/man/lwres.docbook b/contrib/bind9/lib/lwres/man/lwres.docbook
index 511d82e91ea9..83258a9dd743 100644
--- a/contrib/bind9/lib/lwres/man/lwres.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres.docbook,v 1.3.206.1 2004/03/06 08:15:37 marka Exp $ -->
+<!-- $Id: lwres.docbook,v 1.3.206.3 2005/05/12 21:36:11 sra Exp $ -->
 
 <refentry>
 <refentryinfo>
@@ -28,6 +30,20 @@
 <manvolnum>3</manvolnum>
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
+
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres</refname>
 <refpurpose>introduction to the lightweight resolver library</refpurpose>
diff --git a/contrib/bind9/lib/lwres/man/lwres.html b/contrib/bind9/lib/lwres/man/lwres.html
index 793ab72a526e..1d5e57bfd248 100644
--- a/contrib/bind9/lib/lwres/man/lwres.html
+++ b/contrib/bind9/lib/lwres/man/lwres.html
@@ -1,433 +1,216 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres.html,v 1.4.2.1.4.2 2004/08/22 23:39:02 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres&nbsp;--&nbsp;introduction to the lightweight resolver library</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN11"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN12"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwres.h&gt;</PRE
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN14"
-></A
-><H2
->DESCRIPTION</H2
-><P
->The BIND 9 lightweight resolver library is a simple, name service
+<!-- $Id: lwres.html,v 1.4.2.1.4.9 2005/10/13 02:33:54 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres &#8212; introduction to the lightweight resolver library</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis"><pre class="funcsynopsisinfo">#include &lt;lwres/lwres.h&gt;</pre></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525832"></a><h2>DESCRIPTION</h2>
+<p>
+The BIND 9 lightweight resolver library is a simple, name service
 independent stub resolver library.  It provides hostname-to-address
 and address-to-hostname lookup services to applications by
 transmitting lookup requests to a resolver daemon
-<B
-CLASS="COMMAND"
->lwresd</B
->
+<span><strong class="command">lwresd</strong></span>
 running on the local host. The resover daemon performs the
 lookup using the DNS or possibly other name service protocols,
 and returns the results to the application through the library.  
 The library and resolver daemon communicate using a simple
-UDP-based protocol.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN18"
-></A
-><H2
->OVERVIEW</H2
-><P
->The lwresd library implements multiple name service APIs.
+UDP-based protocol.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525845"></a><h2>OVERVIEW</h2>
+<p>
+The lwresd library implements multiple name service APIs.
 The standard
-<CODE
-CLASS="FUNCTION"
->gethostbyname()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->gethostbyaddr()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->gethostbyname_r()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->gethostbyaddr_r()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->getaddrinfo()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->getipnodebyname()</CODE
->,
+<code class="function">gethostbyname()</code>,
+<code class="function">gethostbyaddr()</code>,
+<code class="function">gethostbyname_r()</code>,
+<code class="function">gethostbyaddr_r()</code>,
+<code class="function">getaddrinfo()</code>,
+<code class="function">getipnodebyname()</code>,
 and
-<CODE
-CLASS="FUNCTION"
->getipnodebyaddr()</CODE
->
+<code class="function">getipnodebyaddr()</code>
 functions are all supported.  To allow the lwres library to coexist
 with system libraries that define functions of the same name,
 the library defines these functions with names prefixed by
-<VAR
-CLASS="LITERAL"
->lwres_</VAR
->.
+<code class="literal">lwres_</code>.
 To define the standard names, applications must include the
 header file
-<TT
-CLASS="FILENAME"
->&lt;lwres/netdb.h&gt;</TT
->
+<code class="filename">&lt;lwres/netdb.h&gt;</code>
 which contains macro definitions mapping the standard function names
 into
-<VAR
-CLASS="LITERAL"
->lwres_</VAR
->
+<code class="literal">lwres_</code>
 prefixed ones.  Operating system vendors who integrate the lwres
 library into their base distributions should rename the functions
-in the library proper so that the renaming macros are not needed.</P
-><P
->The library also provides a native API consisting of the functions
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrsbyname()</CODE
->
+in the library proper so that the renaming macros are not needed.
+</p>
+<p>
+The library also provides a native API consisting of the functions
+<code class="function">lwres_getaddrsbyname()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_getnamebyaddr()</CODE
->.
+<code class="function">lwres_getnamebyaddr()</code>.
 These may be called by applications that require more detailed
 control over the lookup process than the standard functions
-provide.</P
-><P
->In addition to these name service independent address lookup
+provide.
+</p>
+<p>
+In addition to these name service independent address lookup
 functions, the library implements a new, experimental API
 for looking up arbitrary DNS resource records, using the
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrsbyname()</CODE
->
-function.</P
-><P
->Finally, there is a low-level API for converting lookup
+<code class="function">lwres_getaddrsbyname()</code>
+function.
+</p>
+<p>
+Finally, there is a low-level API for converting lookup
 requests and responses to and from raw lwres protocol packets.  
 This API can be used by clients requiring nonblocking operation, 
 and is also used when implementing the server side of the lwres
 protocol, for example in the
-<B
-CLASS="COMMAND"
->lwresd</B
->
+<span><strong class="command">lwresd</strong></span>
 resolver daemon.  The use of this low-level API in clients
-and servers is outlined in the following sections.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN38"
-></A
-><H2
->CLIENT-SIDE LOW-LEVEL API CALL FLOW</H2
-><P
->When a client program wishes to make an lwres request using the
+and servers is outlined in the following sections.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525909"></a><h2>CLIENT-SIDE LOW-LEVEL API CALL FLOW</h2>
+<p>
+When a client program wishes to make an lwres request using the
 native low-level API, it typically performs the following 
-sequence of actions.</P
-><P
->(1) Allocate or use an existing <SPAN
-CLASS="TYPE"
->lwres_packet_t</SPAN
->,
-called <VAR
-CLASS="VARNAME"
->pkt</VAR
-> below.</P
-><P
->(2) Set <CODE
-CLASS="STRUCTFIELD"
->pkt.recvlength</CODE
-> to the maximum length we will accept.  
+sequence of actions.
+</p>
+<p>
+(1) Allocate or use an existing <span class="type">lwres_packet_t</span>,
+called <code class="varname">pkt</code> below.
+</p>
+<p>
+(2) Set <em class="structfield"><code>pkt.recvlength</code></em> to the maximum length we will accept.  
 This is done so the receiver of our packets knows how large our receive 
 buffer is.  The "default" is a constant in
-<TT
-CLASS="FILENAME"
->lwres.h</TT
->: <CODE
-CLASS="CONSTANT"
->LWRES_RECVLENGTH = 4096</CODE
->.</P
-><P
->(3) Set <CODE
-CLASS="STRUCTFIELD"
->pkt.serial</CODE
->
+<code class="filename">lwres.h</code>: <code class="constant">LWRES_RECVLENGTH = 4096</code>.
+</p>
+<p>
+(3) Set <em class="structfield"><code>pkt.serial</code></em>
 to a unique serial number.  This value is echoed
-back to the application by the remote server.</P
-><P
->(4) Set <CODE
-CLASS="STRUCTFIELD"
->pkt.pktflags</CODE
->.  Usually this is set to 0.</P
-><P
->(5) Set <CODE
-CLASS="STRUCTFIELD"
->pkt.result</CODE
-> to 0.</P
-><P
->(6) Call <CODE
-CLASS="FUNCTION"
->lwres_*request_render()</CODE
->, 
+back to the application by the remote server.
+</p>
+<p>
+(4) Set <em class="structfield"><code>pkt.pktflags</code></em>.  Usually this is set to 0.
+</p>
+<p>
+(5) Set <em class="structfield"><code>pkt.result</code></em> to 0.
+</p>
+<p>
+(6) Call <code class="function">lwres_*request_render()</code>, 
 or marshall in the data using the primitives
-such as <CODE
-CLASS="FUNCTION"
->lwres_packet_render()</CODE
->
-and storing the packet data.</P
-><P
->(7) Transmit the resulting buffer.</P
-><P
->(8) Call <CODE
-CLASS="FUNCTION"
->lwres_*response_parse()</CODE
->
-to parse any packets received.</P
-><P
->(9) Verify that the opcode and serial match a request, and process the
-packet specific information contained in the body.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN61"
-></A
-><H2
->SERVER-SIDE LOW-LEVEL API CALL FLOW</H2
-><P
->When implementing the server side of the lightweight resolver
+such as <code class="function">lwres_packet_render()</code>
+and storing the packet data.
+</p>
+<p>
+(7) Transmit the resulting buffer.
+</p>
+<p>
+(8) Call <code class="function">lwres_*response_parse()</code>
+to parse any packets received.
+</p>
+<p>
+(9) Verify that the opcode and serial match a request, and process the
+packet specific information contained in the body.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526056"></a><h2>SERVER-SIDE LOW-LEVEL API CALL FLOW</h2>
+<p>
+When implementing the server side of the lightweight resolver
 protocol using the lwres library, a sequence of actions like the
-following is typically involved in processing each request packet.</P
-><P
->Note that the same <SPAN
-CLASS="TYPE"
->lwres_packet_t</SPAN
-> is used
-in both the <CODE
-CLASS="FUNCTION"
->_parse()</CODE
-> and <CODE
-CLASS="FUNCTION"
->_render()</CODE
-> calls,
+following is typically involved in processing each request packet.
+</p>
+<p>
+Note that the same <span class="type">lwres_packet_t</span> is used
+in both the <code class="function">_parse()</code> and <code class="function">_render()</code> calls,
 with only a few modifications made
 to the packet header's contents between uses.  This method is recommended
-as it keeps the serial, opcode, and other fields correct.</P
-><P
->(1) When a packet is received, call <CODE
-CLASS="FUNCTION"
->lwres_*request_parse()</CODE
-> to
-unmarshall it.  This returns a <SPAN
-CLASS="TYPE"
->lwres_packet_t</SPAN
-> (also called <VAR
-CLASS="VARNAME"
->pkt</VAR
->, below)
-as well as a data specific type, such as <SPAN
-CLASS="TYPE"
->lwres_gabnrequest_t</SPAN
->.</P
-><P
->(2) Process the request in the data specific type.</P
-><P
->(3) Set the <CODE
-CLASS="STRUCTFIELD"
->pkt.result</CODE
->,
-<CODE
-CLASS="STRUCTFIELD"
->pkt.recvlength</CODE
-> as above.  All other fields can
-be left untouched since they were filled in by the <CODE
-CLASS="FUNCTION"
->*_parse()</CODE
-> call
-above.  If using <CODE
-CLASS="FUNCTION"
->lwres_*response_render()</CODE
->,
-<CODE
-CLASS="STRUCTFIELD"
->pkt.pktflags</CODE
-> will be set up
-properly.  Otherwise, the <CODE
-CLASS="CONSTANT"
->LWRES_LWPACKETFLAG_RESPONSE</CODE
-> bit should be
-set.</P
-><P
->(4) Call the data specific rendering function, such as
-<CODE
-CLASS="FUNCTION"
->lwres_gabnresponse_render()</CODE
->.</P
-><P
->(5) Send the resulting packet to the client.</P
-><P
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN85"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_gethostent</SPAN
->(3)</SPAN
->,
+as it keeps the serial, opcode, and other fields correct.
+</p>
+<p>
+(1) When a packet is received, call <code class="function">lwres_*request_parse()</code> to
+unmarshall it.  This returns a <span class="type">lwres_packet_t</span> (also called <code class="varname">pkt</code>, below)
+as well as a data specific type, such as <span class="type">lwres_gabnrequest_t</span>.
+</p>
+<p>
+(2) Process the request in the data specific type.
+</p>
+<p>
+(3) Set the <em class="structfield"><code>pkt.result</code></em>,
+<em class="structfield"><code>pkt.recvlength</code></em> as above.  All other fields can
+be left untouched since they were filled in by the <code class="function">*_parse()</code> call
+above.  If using <code class="function">lwres_*response_render()</code>,
+<em class="structfield"><code>pkt.pktflags</code></em> will be set up
+properly.  Otherwise, the <code class="constant">LWRES_LWPACKETFLAG_RESPONSE</code> bit should be
+set.
+</p>
+<p>
+(4) Call the data specific rendering function, such as
+<code class="function">lwres_gabnresponse_render()</code>.
+</p>
+<p>
+(5) Send the resulting packet to the client.
+</p>
+<p>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526141"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres_gethostent</span>(3)</span>,
+
+<span class="citerefentry"><span class="refentrytitle">lwres_getipnode</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getipnode</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_getnameinfo</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getnameinfo</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_noop</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_noop</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_gabn</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_gabn</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_gnba</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_gnba</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_context</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_context</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_config</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_config</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">resolver</span>(5)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->resolver</SPAN
->(5)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwresd</span>(8)</span>.
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwresd</SPAN
->(8)</SPAN
->.&#13;</P
-></DIV
-></BODY
-></HTML
->
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.3 b/contrib/bind9/lib/lwres/man/lwres_buffer.3
index 232742aa0700..93e888b0c389 100644
--- a/contrib/bind9/lib/lwres/man/lwres_buffer.3
+++ b/contrib/bind9/lib/lwres/man/lwres_buffer.3
@@ -1,174 +1,117 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_buffer.3,v 1.12.2.1.8.1 2004/03/06 07:41:42 marka Exp $
+.\" $Id: lwres_buffer.3,v 1.12.2.1.8.5 2005/10/13 02:33:58 marka Exp $
 .\"
-.TH "LWRES_BUFFER" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_BUFFER" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_buffer_init, lwres_buffer_invalidate, lwres_buffer_add, lwres_buffer_subtract, lwres_buffer_clear, lwres_buffer_first, lwres_buffer_forward, lwres_buffer_back, lwres_buffer_getuint8, lwres_buffer_putuint8, lwres_buffer_getuint16, lwres_buffer_putuint16, lwres_buffer_getuint32, lwres_buffer_putuint32, lwres_buffer_putmem, lwres_buffer_getmem \- lightweight resolver buffer management
-.SH SYNOPSIS
-\fB#include <lwres/lwbuffer.h>
-.sp
-.na
-void
-lwres_buffer_init(lwres_buffer_t *b, void *base, unsigned int length);
-.ad
-.sp
-.na
-void
-lwres_buffer_invalidate(lwres_buffer_t *b);
-.ad
-.sp
-.na
-void
-lwres_buffer_add(lwres_buffer_t *b, unsigned int n);
-.ad
-.sp
-.na
-void
-lwres_buffer_subtract(lwres_buffer_t *b, unsigned int n);
-.ad
-.sp
-.na
-void
-lwres_buffer_clear(lwres_buffer_t *b);
-.ad
-.sp
-.na
-void
-lwres_buffer_first(lwres_buffer_t *b);
-.ad
-.sp
-.na
-void
-lwres_buffer_forward(lwres_buffer_t *b, unsigned int n);
-.ad
-.sp
-.na
-void
-lwres_buffer_back(lwres_buffer_t *b, unsigned int n);
-.ad
-.sp
-.na
-lwres_uint8_t
-lwres_buffer_getuint8(lwres_buffer_t *b);
-.ad
-.sp
-.na
-void
-lwres_buffer_putuint8(lwres_buffer_t *b, lwres_uint8_t val);
-.ad
-.sp
-.na
-lwres_uint16_t
-lwres_buffer_getuint16(lwres_buffer_t *b);
-.ad
-.sp
-.na
-void
-lwres_buffer_putuint16(lwres_buffer_t *b, lwres_uint16_t val);
-.ad
-.sp
-.na
-lwres_uint32_t
-lwres_buffer_getuint32(lwres_buffer_t *b);
-.ad
-.sp
-.na
-void
-lwres_buffer_putuint32(lwres_buffer_t *b, lwres_uint32_t val);
-.ad
-.sp
-.na
-void
-lwres_buffer_putmem(lwres_buffer_t *b, const unsigned char *base, unsigned int length);
-.ad
-.sp
-.na
-void
-lwres_buffer_getmem(lwres_buffer_t *b, unsigned char *base, unsigned int length);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwbuffer.h>
+.fi
+.HP 23
+\fBvoid\ \fBlwres_buffer_init\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBvoid\ *base\fR\fB, \fR\fBunsigned\ int\ length\fR\fB);\fR
+.HP 29
+\fBvoid\ \fBlwres_buffer_invalidate\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 22
+\fBvoid\ \fBlwres_buffer_add\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ int\ n\fR\fB);\fR
+.HP 27
+\fBvoid\ \fBlwres_buffer_subtract\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ int\ n\fR\fB);\fR
+.HP 24
+\fBvoid\ \fBlwres_buffer_clear\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 24
+\fBvoid\ \fBlwres_buffer_first\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 26
+\fBvoid\ \fBlwres_buffer_forward\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ int\ n\fR\fB);\fR
+.HP 23
+\fBvoid\ \fBlwres_buffer_back\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ int\ n\fR\fB);\fR
+.HP 36
+\fBlwres_uint8_t\ \fBlwres_buffer_getuint8\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 27
+\fBvoid\ \fBlwres_buffer_putuint8\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_uint8_t\ val\fR\fB);\fR
+.HP 38
+\fBlwres_uint16_t\ \fBlwres_buffer_getuint16\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 28
+\fBvoid\ \fBlwres_buffer_putuint16\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_uint16_t\ val\fR\fB);\fR
+.HP 38
+\fBlwres_uint32_t\ \fBlwres_buffer_getuint32\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 28
+\fBvoid\ \fBlwres_buffer_putuint32\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_uint32_t\ val\fR\fB);\fR
+.HP 25
+\fBvoid\ \fBlwres_buffer_putmem\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBconst\ unsigned\ char\ *base\fR\fB, \fR\fBunsigned\ int\ length\fR\fB);\fR
+.HP 25
+\fBvoid\ \fBlwres_buffer_getmem\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBunsigned\ char\ *base\fR\fB, \fR\fBunsigned\ int\ length\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-These functions provide bounds checked access to a region of memory
-where data is being read or written.
-They are based on, and similar to, the
+These functions provide bounds checked access to a region of memory where data is being read or written. They are based on, and similar to, the
 isc_buffer_
 functions in the ISC library.
 .PP
-A buffer is a region of memory, together with a set of related
-subregions.
-The \fBused region\fR and the
-\fBavailable\fR region are disjoint, and
-their union is the buffer's region.
-The used region extends from the beginning of the buffer region to the
-last used byte.
-The available region extends from one byte greater than the last used
-byte to the end of the buffer's region.
-The size of the used region can be changed using various
-buffer commands.
-Initially, the used region is empty.
+A buffer is a region of memory, together with a set of related subregions. The
+\fIused region\fR
+and the
+\fIavailable\fR
+region are disjoint, and their union is the buffer's region. The used region extends from the beginning of the buffer region to the last used byte. The available region extends from one byte greater than the last used byte to the end of the buffer's region. The size of the used region can be changed using various buffer commands. Initially, the used region is empty.
 .PP
 The used region is further subdivided into two disjoint regions: the
-\fBconsumed region\fR and the \fBremaining region\fR.
-The union of these two regions is the used region.
-The consumed region extends from the beginning of the used region to
-the byte before the \fBcurrent\fR offset (if any).
-The \fBremaining\fR region the current pointer to the end of the used
-region.
-The size of the consumed region can be changed using various
-buffer commands.
-Initially, the consumed region is empty.
+\fIconsumed region\fR
+and the
+\fIremaining region\fR. The union of these two regions is the used region. The consumed region extends from the beginning of the used region to the byte before the
+\fIcurrent\fR
+offset (if any). The
+\fIremaining\fR
+region the current pointer to the end of the used region. The size of the consumed region can be changed using various buffer commands. Initially, the consumed region is empty.
 .PP
-The \fBactive region\fR is an (optional) subregion of the remaining
-region.
-It extends from the current offset to an offset in the
-remaining region.
-Initially, the active region is empty.
-If the current offset advances beyond the chosen offset,
-the active region will also be empty.
+The
+\fIactive region\fR
+is an (optional) subregion of the remaining region. It extends from the current offset to an offset in the remaining region. Initially, the active region is empty. If the current offset advances beyond the chosen offset, the active region will also be empty.
 .PP
-.sp
 .nf
- 
-   /------------entire length---------------\\\\
-   /----- used region -----\\\\/-- available --\\\\
-   +----------------------------------------+
+   /\-\-\-\-\-\-\-\-\-\-\-\-entire length\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\\\\
+   /\-\-\-\-\- used region \-\-\-\-\-\\\\/\-\- available \-\-\\\\
+   +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
    | consumed  | remaining |                |
-   +----------------------------------------+
+   +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
    a           b     c     d                e
- 
   a == base of buffer.
   b == current pointer.  Can be anywhere between a and d.
   c == active pointer.  Meaningful between b and d.
   d == used pointer.
   e == length of buffer.
- 
-  a-e == entire length of buffer.
-  a-d == used region.
-  a-b == consumed region.
-  b-d == remaining region.
-  b-c == optional active region.
-.sp
+  a\-e == entire length of buffer.
+  a\-d == used region.
+  a\-b == consumed region.
+  b\-d == remaining region.
+  b\-c == optional active region.
 .fi
+.sp
 .PP
 \fBlwres_buffer_init()\fR
 initializes the
-\fBlwres_buffer_t\fR
-\fI*b\fR
+\fBlwres_buffer_t\fR\fI*b\fR
 and assocates it with the memory region of size
 \fIlength\fR
 bytes starting at location
@@ -177,15 +120,13 @@ bytes starting at location
 \fBlwres_buffer_invalidate()\fR
 marks the buffer
 \fI*b\fR
-as invalid. Invalidating a buffer after use is not required,
-but makes it possible to catch its possible accidental use.
+as invalid. Invalidating a buffer after use is not required, but makes it possible to catch its possible accidental use.
 .PP
 The functions
 \fBlwres_buffer_add()\fR
 and
 \fBlwres_buffer_subtract()\fR
-respectively increase and decrease the used space in
-buffer
+respectively increase and decrease the used space in buffer
 \fI*b\fR
 by
 \fIn\fR
@@ -193,25 +134,23 @@ bytes.
 \fBlwres_buffer_add()\fR
 checks for buffer overflow and
 \fBlwres_buffer_subtract()\fR
-checks for underflow.
-These functions do not allocate or deallocate memory.
-They just change the value of
-\fBused\fR.
+checks for underflow. These functions do not allocate or deallocate memory. They just change the value of
+used.
 .PP
-A buffer is re-initialised by
-\fBlwres_buffer_clear()\fR.
-The function sets
-\fBused\fR ,
-\fBcurrent\fR
+A buffer is re\-initialised by
+\fBlwres_buffer_clear()\fR. The function sets
+used
+,
+current
 and
-\fBactive\fR
+active
 to zero.
 .PP
 \fBlwres_buffer_first\fR
 makes the consumed region of buffer
 \fI*p\fR
 empty by setting
-\fBcurrent\fR
+current
 to zero (the start of the buffer).
 .PP
 \fBlwres_buffer_forward()\fR
@@ -219,21 +158,19 @@ increases the consumed region of buffer
 \fI*b\fR
 by
 \fIn\fR
-bytes, checking for overflow.
-Similarly,
+bytes, checking for overflow. Similarly,
 \fBlwres_buffer_back()\fR
 decreases buffer
-\fIb\fR's
-consumed region by
+\fIb\fR's consumed region by
 \fIn\fR
 bytes and checks for underflow.
 .PP
 \fBlwres_buffer_getuint8()\fR
-reads an unsigned 8-bit integer from
+reads an unsigned 8\-bit integer from
 \fI*b\fR
 and returns it.
 \fBlwres_buffer_putuint8()\fR
-writes the unsigned 8-bit integer
+writes the unsigned 8\-bit integer
 \fIval\fR
 to buffer
 \fI*b\fR.
@@ -243,21 +180,17 @@ and
 \fBlwres_buffer_getuint32()\fR
 are identical to
 \fBlwres_buffer_putuint8()\fR
-except that they respectively read an unsigned 16-bit or 32-bit integer 
-in network byte order from
-\fIb\fR.
-Similarly,
+except that they respectively read an unsigned 16\-bit or 32\-bit integer in network byte order from
+\fIb\fR. Similarly,
 \fBlwres_buffer_putuint16()\fR
 and
 \fBlwres_buffer_putuint32()\fR
-writes the unsigned 16-bit or 32-bit integer
+writes the unsigned 16\-bit or 32\-bit integer
 \fIval\fR
 to buffer
-\fIb\fR,
-in network byte order.
+\fIb\fR, in network byte order.
 .PP
-Arbitrary amounts of data are read or written from a lightweight
-resolver buffer with
+Arbitrary amounts of data are read or written from a lightweight resolver buffer with
 \fBlwres_buffer_getmem()\fR
 and
 \fBlwres_buffer_putmem()\fR
@@ -268,8 +201,7 @@ copies
 bytes of memory at
 \fIbase\fR
 to
-\fIb\fR.
-Conversely,
+\fIb\fR. Conversely,
 \fBlwres_buffer_getmem()\fR
 copies
 \fIlength\fR
diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.docbook b/contrib/bind9/lib/lwres/man/lwres_buffer.docbook
index 4db9fd3acdb4..c70aee508e77 100644
--- a/contrib/bind9/lib/lwres/man/lwres_buffer.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_buffer.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_buffer.docbook,v 1.3.206.1 2004/03/06 08:15:37 marka Exp $ -->
+<!-- $Id: lwres_buffer.docbook,v 1.3.206.3 2005/05/12 21:36:11 sra Exp $ -->
 
 <refentry>
 <refentryinfo>
@@ -29,6 +31,19 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_buffer_init</refname>
 <refname>lwres_buffer_invalidate</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.html b/contrib/bind9/lib/lwres/man/lwres_buffer.html
index 79354fc05591..5a203f1a15a4 100644
--- a/contrib/bind9/lib/lwres/man/lwres_buffer.html
+++ b/contrib/bind9/lib/lwres/man/lwres_buffer.html
@@ -1,232 +1,267 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_buffer.html,v 1.4.2.1.4.2 2004/08/22 23:39:03 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_buffer</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_buffer</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_buffer_init, lwres_buffer_invalidate, lwres_buffer_add, lwres_buffer_subtract, lwres_buffer_clear, lwres_buffer_first, lwres_buffer_forward, lwres_buffer_back, lwres_buffer_getuint8, lwres_buffer_putuint8, lwres_buffer_getuint16, lwres_buffer_putuint16, lwres_buffer_getuint32, lwres_buffer_putuint32, lwres_buffer_putmem, lwres_buffer_getmem&nbsp;--&nbsp;lightweight resolver buffer management</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN26"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN27"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwbuffer.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_init</CODE
->(lwres_buffer_t *b, void *base, unsigned int length);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_invalidate</CODE
->(lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_add</CODE
->(lwres_buffer_t *b, unsigned int n);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_subtract</CODE
->(lwres_buffer_t *b, unsigned int n);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_clear</CODE
->(lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_first</CODE
->(lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_forward</CODE
->(lwres_buffer_t *b, unsigned int n);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_back</CODE
->(lwres_buffer_t *b, unsigned int n);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_uint8_t
-lwres_buffer_getuint8</CODE
->(lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_putuint8</CODE
->(lwres_buffer_t *b, lwres_uint8_t val);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_uint16_t
-lwres_buffer_getuint16</CODE
->(lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_putuint16</CODE
->(lwres_buffer_t *b, lwres_uint16_t val);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_uint32_t
-lwres_buffer_getuint32</CODE
->(lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_putuint32</CODE
->(lwres_buffer_t *b, lwres_uint32_t val);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_putmem</CODE
->(lwres_buffer_t *b, const unsigned char *base, unsigned int length);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_buffer_getmem</CODE
->(lwres_buffer_t *b, unsigned char *base, unsigned int length);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN106"
-></A
-><H2
->DESCRIPTION</H2
-><P
->These functions provide bounds checked access to a region of memory
+<!-- $Id: lwres_buffer.html,v 1.4.2.1.4.8 2005/10/13 02:33:55 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_buffer</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_buffer_init, lwres_buffer_invalidate, lwres_buffer_add, lwres_buffer_subtract, lwres_buffer_clear, lwres_buffer_first, lwres_buffer_forward, lwres_buffer_back, lwres_buffer_getuint8, lwres_buffer_putuint8, lwres_buffer_getuint16, lwres_buffer_putuint16, lwres_buffer_getuint32, lwres_buffer_putuint32, lwres_buffer_putmem, lwres_buffer_getmem &#8212; lightweight resolver buffer management</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">
+#include &lt;lwres/lwbuffer.h&gt;
+</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_init</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_invalidate</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_add</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_subtract</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_clear</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_first</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_forward</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_back</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+lwres_uint8_t
+<b class="fsfunc">lwres_buffer_getuint8</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_putuint8</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+lwres_uint16_t
+<b class="fsfunc">lwres_buffer_getuint16</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_putuint16</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+lwres_uint32_t
+<b class="fsfunc">lwres_buffer_getuint32</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_putuint32</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_putmem</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_buffer_getmem</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526109"></a><h2>DESCRIPTION</h2>
+<p>
+These functions provide bounds checked access to a region of memory
 where data is being read or written.
 They are based on, and similar to, the
-<VAR
-CLASS="LITERAL"
->isc_buffer_</VAR
->
-functions in the ISC library.</P
-><P
->A buffer is a region of memory, together with a set of related
+<code class="literal">isc_buffer_</code>
+functions in the ISC library.
+</p>
+<p>
+A buffer is a region of memory, together with a set of related
 subregions.
-The <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->used region</I
-></SPAN
-> and the
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->available</I
-></SPAN
-> region are disjoint, and
+The <span class="emphasis"><em>used region</em></span> and the
+<span class="emphasis"><em>available</em></span> region are disjoint, and
 their union is the buffer's region.
 The used region extends from the beginning of the buffer region to the
 last used byte.
@@ -234,60 +269,33 @@ The available region extends from one byte greater than the last used
 byte to the end of the  buffer's region.
 The size of the used region can be changed using various
 buffer commands.
-Initially, the used region is empty.</P
-><P
->The used region is further subdivided into two disjoint regions: the
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->consumed region</I
-></SPAN
-> and the <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->remaining region</I
-></SPAN
->.
+Initially, the used region is empty.
+</p>
+<p>
+The used region is further subdivided into two disjoint regions: the
+<span class="emphasis"><em>consumed region</em></span> and the <span class="emphasis"><em>remaining region</em></span>.
 The union of these two regions is the used region.
 The consumed region extends from the beginning of the used region to
-the byte before the <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->current</I
-></SPAN
-> offset (if any).
-The <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->remaining</I
-></SPAN
-> region the current pointer to the end of the used
+the byte before the <span class="emphasis"><em>current</em></span> offset (if any).
+The <span class="emphasis"><em>remaining</em></span> region the current pointer to the end of the used
 region.
 The size of the consumed region can be changed using various
 buffer commands.
-Initially, the consumed region is empty.</P
-><P
->The <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->active region</I
-></SPAN
-> is an (optional) subregion of the remaining
+Initially, the consumed region is empty.
+</p>
+<p>
+The <span class="emphasis"><em>active region</em></span> is an (optional) subregion of the remaining
 region.
 It extends from the current offset to an offset in the
 remaining region.
 Initially, the active region is empty.
 If the current offset advances beyond the chosen offset,
-the active region will also be empty.</P
-><P
-><PRE
-CLASS="PROGRAMLISTING"
-> 
+the active region will also be empty.
+</p>
+<p>
+</p>
+<pre class="programlisting">
+ 
    /------------entire length---------------\\
    /----- used region -----\\/-- available --\\
    +----------------------------------------+
@@ -305,272 +313,132 @@ CLASS="PROGRAMLISTING"
   a-d == used region.
   a-b == consumed region.
   b-d == remaining region.
-  b-c == optional active region.</PRE
-></P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_buffer_init()</CODE
->
+  b-c == optional active region.
+</pre>
+<p>
+</p>
+<p>
+<code class="function">lwres_buffer_init()</code>
 initializes the
-<SPAN
-CLASS="TYPE"
->lwres_buffer_t</SPAN
->
-<VAR
-CLASS="PARAMETER"
->*b</VAR
->
+<span class="type">lwres_buffer_t</span>
+<em class="parameter"><code>*b</code></em>
 and assocates it with the memory region of size
-<VAR
-CLASS="PARAMETER"
->length</VAR
->
+<em class="parameter"><code>length</code></em>
 bytes starting at location
-<VAR
-CLASS="PARAMETER"
->base.</VAR
-></P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_buffer_invalidate()</CODE
->
+<em class="parameter"><code>base.</code></em>
+</p>
+<p>
+<code class="function">lwres_buffer_invalidate()</code>
 marks the buffer
-<VAR
-CLASS="PARAMETER"
->*b</VAR
->
+<em class="parameter"><code>*b</code></em>
 as invalid.  Invalidating a buffer after use is not required,
-but makes it possible to catch its possible accidental use.</P
-><P
->The functions
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_add()</CODE
->
+but makes it possible to catch its possible accidental use.
+</p>
+<p>
+The functions
+<code class="function">lwres_buffer_add()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_subtract()</CODE
->
+<code class="function">lwres_buffer_subtract()</code>
 respectively increase and decrease the used space in
 buffer
-<VAR
-CLASS="PARAMETER"
->*b</VAR
->
+<em class="parameter"><code>*b</code></em>
 by
-<VAR
-CLASS="PARAMETER"
->n</VAR
->
+<em class="parameter"><code>n</code></em>
 bytes.
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_add()</CODE
->
+<code class="function">lwres_buffer_add()</code>
 checks for buffer overflow and
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_subtract()</CODE
->
+<code class="function">lwres_buffer_subtract()</code>
 checks for underflow.
 These functions do not allocate or deallocate memory.
 They just change the value of
-<CODE
-CLASS="STRUCTFIELD"
->used</CODE
->.</P
-><P
->A buffer is re-initialised by
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_clear()</CODE
->.
+<em class="structfield"><code>used</code></em>.
+</p>
+<p>
+A buffer is re-initialised by
+<code class="function">lwres_buffer_clear()</code>.
 The function sets
-<CODE
-CLASS="STRUCTFIELD"
->used</CODE
-> ,
-<CODE
-CLASS="STRUCTFIELD"
->current</CODE
->
+<em class="structfield"><code>used</code></em> ,
+<em class="structfield"><code>current</code></em>
 and
-<CODE
-CLASS="STRUCTFIELD"
->active</CODE
->
-to zero.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_buffer_first</CODE
->
+<em class="structfield"><code>active</code></em>
+to zero.
+</p>
+<p>
+<code class="function">lwres_buffer_first</code>
 makes the consumed region of buffer
-<VAR
-CLASS="PARAMETER"
->*p</VAR
->
+<em class="parameter"><code>*p</code></em>
 empty by setting
-<CODE
-CLASS="STRUCTFIELD"
->current</CODE
->
-to zero (the start of the buffer).</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_buffer_forward()</CODE
->
+<em class="structfield"><code>current</code></em>
+to zero (the start of the buffer).
+</p>
+<p>
+<code class="function">lwres_buffer_forward()</code>
 increases the consumed region of buffer
-<VAR
-CLASS="PARAMETER"
->*b</VAR
->
+<em class="parameter"><code>*b</code></em>
 by
-<VAR
-CLASS="PARAMETER"
->n</VAR
->
+<em class="parameter"><code>n</code></em>
 bytes, checking for overflow.
 Similarly,
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_back()</CODE
->
+<code class="function">lwres_buffer_back()</code>
 decreases buffer
-<VAR
-CLASS="PARAMETER"
->b</VAR
->'s
+<em class="parameter"><code>b</code></em>'s
 consumed region by
-<VAR
-CLASS="PARAMETER"
->n</VAR
->
-bytes and checks for underflow.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_buffer_getuint8()</CODE
->
+<em class="parameter"><code>n</code></em>
+bytes and checks for underflow.
+</p>
+<p>
+<code class="function">lwres_buffer_getuint8()</code>
 reads an unsigned 8-bit integer from
-<VAR
-CLASS="PARAMETER"
->*b</VAR
->
+<em class="parameter"><code>*b</code></em>
 and returns it.
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_putuint8()</CODE
->
+<code class="function">lwres_buffer_putuint8()</code>
 writes the unsigned 8-bit integer
-<VAR
-CLASS="PARAMETER"
->val</VAR
->
+<em class="parameter"><code>val</code></em>
 to buffer
-<VAR
-CLASS="PARAMETER"
->*b</VAR
->.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_buffer_getuint16()</CODE
->
+<em class="parameter"><code>*b</code></em>.
+</p>
+<p>
+<code class="function">lwres_buffer_getuint16()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_getuint32()</CODE
->
+<code class="function">lwres_buffer_getuint32()</code>
 are identical to
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_putuint8()</CODE
->
+<code class="function">lwres_buffer_putuint8()</code>
 except that they respectively read an unsigned 16-bit or 32-bit integer 
 in network byte order from
-<VAR
-CLASS="PARAMETER"
->b</VAR
->.
+<em class="parameter"><code>b</code></em>.
 Similarly,
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_putuint16()</CODE
->
+<code class="function">lwres_buffer_putuint16()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_putuint32()</CODE
->
+<code class="function">lwres_buffer_putuint32()</code>
 writes the unsigned 16-bit or 32-bit integer
-<VAR
-CLASS="PARAMETER"
->val</VAR
->
+<em class="parameter"><code>val</code></em>
 to buffer
-<VAR
-CLASS="PARAMETER"
->b</VAR
->,
-in network byte order.</P
-><P
->Arbitrary amounts of data are read or written from a lightweight
+<em class="parameter"><code>b</code></em>,
+in network byte order.
+</p>
+<p>
+Arbitrary amounts of data are read or written from a lightweight
 resolver buffer with
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_getmem()</CODE
->
+<code class="function">lwres_buffer_getmem()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_putmem()</CODE
->
+<code class="function">lwres_buffer_putmem()</code>
 respectively.
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_putmem()</CODE
->
+<code class="function">lwres_buffer_putmem()</code>
 copies
-<VAR
-CLASS="PARAMETER"
->length</VAR
->
+<em class="parameter"><code>length</code></em>
 bytes of memory at
-<VAR
-CLASS="PARAMETER"
->base</VAR
->
+<em class="parameter"><code>base</code></em>
 to
-<VAR
-CLASS="PARAMETER"
->b</VAR
->.
+<em class="parameter"><code>b</code></em>.
 Conversely,
-<CODE
-CLASS="FUNCTION"
->lwres_buffer_getmem()</CODE
->
+<code class="function">lwres_buffer_getmem()</code>
 copies
-<VAR
-CLASS="PARAMETER"
->length</VAR
->
+<em class="parameter"><code>length</code></em>
 bytes of memory from
-<VAR
-CLASS="PARAMETER"
->b</VAR
->
+<em class="parameter"><code>b</code></em>
 to
-<VAR
-CLASS="PARAMETER"
->base</VAR
->.</P
-></DIV
-></BODY
-></HTML
->
+<em class="parameter"><code>base</code></em>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_config.3 b/contrib/bind9/lib/lwres/man/lwres_config.3
index 0c345efa9791..943028375187 100644
--- a/contrib/bind9/lib/lwres/man/lwres_config.3
+++ b/contrib/bind9/lib/lwres/man/lwres_config.3
@@ -1,51 +1,47 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_config.3,v 1.12.2.1.8.1 2004/03/06 07:41:42 marka Exp $
+.\" $Id: lwres_config.3,v 1.12.2.1.8.5 2005/10/13 02:33:58 marka Exp $
 .\"
-.TH "LWRES_CONFIG" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_CONFIG" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_conf_init, lwres_conf_clear, lwres_conf_parse, lwres_conf_print, lwres_conf_get \- lightweight resolver configuration
-.SH SYNOPSIS
-\fB#include <lwres/lwres.h>
-.sp
-.na
-void
-lwres_conf_init(lwres_context_t *ctx);
-.ad
-.sp
-.na
-void
-lwres_conf_clear(lwres_context_t *ctx);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_conf_parse(lwres_context_t *ctx, const char *filename);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_conf_print(lwres_context_t *ctx, FILE *fp);
-.ad
-.sp
-.na
-lwres_conf_t *
-lwres_conf_get(lwres_context_t *ctx);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwres.h>
+.fi
+.HP 21
+\fBvoid\ \fBlwres_conf_init\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB);\fR
+.HP 22
+\fBvoid\ \fBlwres_conf_clear\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB);\fR
+.HP 32
+\fBlwres_result_t\ \fBlwres_conf_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBconst\ char\ *filename\fR\fB);\fR
+.HP 32
+\fBlwres_result_t\ \fBlwres_conf_print\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBFILE\ *fp\fR\fB);\fR
+.HP 30
+\fBlwres_conf_t\ *\ \fBlwres_conf_get\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
 \fBlwres_conf_init()\fR
@@ -55,8 +51,7 @@ structure for lightweight resolver context
 \fIctx\fR.
 .PP
 \fBlwres_conf_clear()\fR
-frees up all the internal memory used by
-that
+frees up all the internal memory used by that
 \fBlwres_conf_t\fR
 structure in resolver context
 \fIctx\fR.
@@ -75,29 +70,24 @@ prints the
 structure for resolver context
 \fIctx\fR
 to the
-\fBFILE\fR
-\fIfp\fR.
+\fBFILE\fR\fIfp\fR.
 .SH "RETURN VALUES"
 .PP
 \fBlwres_conf_parse()\fR
 returns
-LWRES_R_SUCCESS
+\fBLWRES_R_SUCCESS\fR
 if it successfully read and parsed
-\fIfilename\fR.
-It returns
-LWRES_R_FAILURE
+\fIfilename\fR. It returns
+\fBLWRES_R_FAILURE\fR
 if
 \fIfilename\fR
-could not be opened or contained incorrect
-resolver statements.
+could not be opened or contained incorrect resolver statements.
 .PP
 \fBlwres_conf_print()\fR
 returns
-LWRES_R_SUCCESS
-unless an error occurred when converting the network addresses to a
-numeric host address string.
-If this happens, the function returns
-LWRES_R_FAILURE.
+\fBLWRES_R_SUCCESS\fR
+unless an error occurred when converting the network addresses to a numeric host address string. If this happens, the function returns
+\fBLWRES_R_FAILURE\fR.
 .SH "SEE ALSO"
 .PP
 \fBstdio\fR(3),
diff --git a/contrib/bind9/lib/lwres/man/lwres_config.docbook b/contrib/bind9/lib/lwres/man/lwres_config.docbook
index eeb244ed40d7..03426beb3274 100644
--- a/contrib/bind9/lib/lwres/man/lwres_config.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_config.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_config.docbook,v 1.2.206.1 2004/03/06 08:15:37 marka Exp $ -->
+<!-- $Id: lwres_config.docbook,v 1.2.206.3 2005/05/12 21:36:12 sra Exp $ -->
 
 <refentry>
 <refentryinfo>
@@ -30,6 +32,19 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_conf_init</refname>
 <refname>lwres_conf_clear</refname>
@@ -149,6 +164,7 @@ If this happens, the function returns
 <citerefentry>
 <refentrytitle>resolver</refentrytitle><manvolnum>5</manvolnum>
 </citerefentry>.
+</para>
 </refsect1>
 <refsect1>
 <title>FILES</title>
diff --git a/contrib/bind9/lib/lwres/man/lwres_config.html b/contrib/bind9/lib/lwres/man/lwres_config.html
index cd7c63bee8a3..7ea416b62b6f 100644
--- a/contrib/bind9/lib/lwres/man/lwres_config.html
+++ b/contrib/bind9/lib/lwres/man/lwres_config.html
@@ -1,282 +1,166 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_config.html,v 1.4.2.1.4.2 2004/08/22 23:39:03 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_config</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_config</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_conf_init, lwres_conf_clear, lwres_conf_parse, lwres_conf_print, lwres_conf_get&nbsp;--&nbsp;lightweight resolver configuration</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN15"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN16"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwres.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_conf_init</CODE
->(lwres_context_t *ctx);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_conf_clear</CODE
->(lwres_context_t *ctx);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_conf_parse</CODE
->(lwres_context_t *ctx, const char *filename);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_conf_print</CODE
->(lwres_context_t *ctx, FILE *fp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_conf_t *
-lwres_conf_get</CODE
->(lwres_context_t *ctx);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN40"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_conf_init()</CODE
->
+<!-- $Id: lwres_config.html,v 1.4.2.1.4.9 2005/10/13 02:33:55 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_config</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_conf_init, lwres_conf_clear, lwres_conf_parse, lwres_conf_print, lwres_conf_get &#8212; lightweight resolver configuration</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/lwres.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_conf_init</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_conf_clear</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_conf_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_conf_print</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0"><tr>
+<td><code class="funcdef">
+lwres_conf_t *
+<b class="fsfunc">lwres_conf_get</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525910"></a><h2>DESCRIPTION</h2>
+<p>
+<code class="function">lwres_conf_init()</code>
 creates an empty
-<SPAN
-CLASS="TYPE"
->lwres_conf_t</SPAN
->
+<span class="type">lwres_conf_t</span>
 structure for lightweight resolver context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
->.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_conf_clear()</CODE
->
+<em class="parameter"><code>ctx</code></em>.
+</p>
+<p>
+<code class="function">lwres_conf_clear()</code>
 frees up all the internal memory used by
 that
-<SPAN
-CLASS="TYPE"
->lwres_conf_t</SPAN
->
+<span class="type">lwres_conf_t</span>
 structure in resolver context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
->.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_conf_parse()</CODE
->
+<em class="parameter"><code>ctx</code></em>.
+</p>
+<p>
+<code class="function">lwres_conf_parse()</code>
 opens the file
-<VAR
-CLASS="PARAMETER"
->filename</VAR
->
+<em class="parameter"><code>filename</code></em>
 and parses it to initialise the resolver context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
->'s
-<SPAN
-CLASS="TYPE"
->lwres_conf_t</SPAN
->
-structure.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_conf_print()</CODE
->
+<em class="parameter"><code>ctx</code></em>'s
+<span class="type">lwres_conf_t</span>
+structure.
+</p>
+<p>
+<code class="function">lwres_conf_print()</code>
 prints the
-<SPAN
-CLASS="TYPE"
->lwres_conf_t</SPAN
->
+<span class="type">lwres_conf_t</span>
 structure for resolver context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
->
+<em class="parameter"><code>ctx</code></em>
 to the
-<SPAN
-CLASS="TYPE"
->FILE</SPAN
->
-<VAR
-CLASS="PARAMETER"
->fp</VAR
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN61"
-></A
-><H2
->RETURN VALUES</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_conf_parse()</CODE
->
+<span class="type">FILE</span>
+<em class="parameter"><code>fp</code></em>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525981"></a><h2>RETURN VALUES</h2>
+<p>
+<code class="function">lwres_conf_parse()</code>
 returns
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
+<span class="errorcode">LWRES_R_SUCCESS</span>
 if it successfully read and parsed
-<VAR
-CLASS="PARAMETER"
->filename</VAR
->.
+<em class="parameter"><code>filename</code></em>.
 It returns
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_FAILURE</SPAN
->
+<span class="errorcode">LWRES_R_FAILURE</span>
 if
-<VAR
-CLASS="PARAMETER"
->filename</VAR
->
+<em class="parameter"><code>filename</code></em>
 could not be opened or contained incorrect
-resolver statements.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_conf_print()</CODE
->
+resolver statements.
+</p>
+<p>
+<code class="function">lwres_conf_print()</code>
 returns
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
+<span class="errorcode">LWRES_R_SUCCESS</span>
 unless an error occurred when converting the network addresses to a
 numeric host address string.
 If this happens, the function returns
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_FAILURE</SPAN
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN73"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->stdio</SPAN
->(3)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->resolver</SPAN
->(5)</SPAN
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN82"
-></A
-><H2
->FILES</H2
-><P
-><TT
-CLASS="FILENAME"
->/etc/resolv.conf</TT
-></P
-></DIV
-></BODY
-></HTML
->
+<span class="errorcode">LWRES_R_FAILURE</span>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526021"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">stdio</span>(3)</span>,
+<span class="citerefentry"><span class="refentrytitle">resolver</span>(5)</span>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526048"></a><h2>FILES</h2>
+<p>
+<code class="filename">/etc/resolv.conf</code>
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_context.3 b/contrib/bind9/lib/lwres/man/lwres_context.3
index d19b18a21a04..be8cd3870893 100644
--- a/contrib/bind9/lib/lwres/man/lwres_context.3
+++ b/contrib/bind9/lib/lwres/man/lwres_context.3
@@ -1,103 +1,82 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_context.3,v 1.13.2.2.2.2 2004/03/08 09:05:12 marka Exp $
+.\" $Id: lwres_context.3,v 1.13.2.2.2.6 2005/10/13 02:33:52 marka Exp $
 .\"
-.TH "LWRES_CONTEXT" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_CONTEXT" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_context_create, lwres_context_destroy, lwres_context_nextserial, lwres_context_initserial, lwres_context_freemem, lwres_context_allocmem, lwres_context_sendrecv \- lightweight resolver context management
-.SH SYNOPSIS
-\fB#include <lwres/lwres.h>
-.sp
-.na
-lwres_result_t
-lwres_context_create(lwres_context_t **contextp, void *arg, lwres_malloc_t malloc_function, lwres_free_t free_function);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_context_destroy(lwres_context_t **contextp);
-.ad
-.sp
-.na
-void
-lwres_context_initserial(lwres_context_t *ctx, lwres_uint32_t serial);
-.ad
-.sp
-.na
-lwres_uint32_t
-lwres_context_nextserial(lwres_context_t *ctx);
-.ad
-.sp
-.na
-void
-lwres_context_freemem(lwres_context_t *ctx, void *mem, size_t len);
-.ad
-.sp
-.na
-void
-lwres_context_allocmem(lwres_context_t *ctx, size_t len);
-.ad
-.sp
-.na
-void *
-lwres_context_sendrecv(lwres_context_t *ctx, void *sendbase, int sendlen, void *recvbase, int recvlen, int *recvd_len);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwres.h>
+.fi
+.HP 36
+\fBlwres_result_t\ \fBlwres_context_create\fR\fR\fB(\fR\fBlwres_context_t\ **contextp\fR\fB, \fR\fBvoid\ *arg\fR\fB, \fR\fBlwres_malloc_t\ malloc_function\fR\fB, \fR\fBlwres_free_t\ free_function\fR\fB);\fR
+.HP 37
+\fBlwres_result_t\ \fBlwres_context_destroy\fR\fR\fB(\fR\fBlwres_context_t\ **contextp\fR\fB);\fR
+.HP 30
+\fBvoid\ \fBlwres_context_initserial\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_uint32_t\ serial\fR\fB);\fR
+.HP 40
+\fBlwres_uint32_t\ \fBlwres_context_nextserial\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB);\fR
+.HP 27
+\fBvoid\ \fBlwres_context_freemem\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBvoid\ *mem\fR\fB, \fR\fBsize_t\ len\fR\fB);\fR
+.HP 28
+\fBvoid\ \fBlwres_context_allocmem\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBsize_t\ len\fR\fB);\fR
+.HP 30
+\fBvoid\ *\ \fBlwres_context_sendrecv\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBvoid\ *sendbase\fR\fB, \fR\fBint\ sendlen\fR\fB, \fR\fBvoid\ *recvbase\fR\fB, \fR\fBint\ recvlen\fR\fB, \fR\fBint\ *recvd_len\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
 \fBlwres_context_create()\fR
 creates a
 \fBlwres_context_t\fR
-structure for use in lightweight resolver operations.
-It holds a socket and other data needed for communicating
-with a resolver daemon.
-The new
+structure for use in lightweight resolver operations. It holds a socket and other data needed for communicating with a resolver daemon. The new
 \fBlwres_context_t\fR
 is returned through
-\fIcontextp\fR,
-a pointer to a
+\fIcontextp\fR, a pointer to a
 \fBlwres_context_t\fR
-pointer. This 
+pointer. This
 \fBlwres_context_t\fR
-pointer must initially be NULL, and is modified 
-to point to the newly created
+pointer must initially be NULL, and is modified to point to the newly created
 \fBlwres_context_t\fR.
 .PP
-When the lightweight resolver needs to perform dynamic memory
-allocation, it will call
+When the lightweight resolver needs to perform dynamic memory allocation, it will call
 \fImalloc_function\fR
 to allocate memory and
 \fIfree_function\fR
-to free it. If 
+to free it. If
 \fImalloc_function\fR
 and
 \fIfree_function\fR
-are NULL, memory is allocated using
-\&.Xr malloc 3
-and
-\fBfree\fR(3).
-It is not permitted to have a NULL
+are NULL, memory is allocated using .Xr malloc 3 and
+\fBfree\fR(3). It is not permitted to have a NULL
 \fImalloc_function\fR
-and a non-NULL
+and a non\-NULL
 \fIfree_function\fR
 or vice versa.
 \fIarg\fR
-is passed as the first parameter to the memory
-allocation functions. 
-If
+is passed as the first parameter to the memory allocation functions. If
 \fImalloc_function\fR
 and
 \fIfree_function\fR
@@ -105,23 +84,18 @@ are NULL,
 \fIarg\fR
 is unused and should be passed as NULL.
 .PP
-Once memory for the structure has been allocated,
-it is initialized using
+Once memory for the structure has been allocated, it is initialized using
 \fBlwres_conf_init\fR(3)
 and returned via
 \fI*contextp\fR.
 .PP
 \fBlwres_context_destroy()\fR
-destroys a 
-\fBlwres_context_t\fR,
-closing its socket.
+destroys a
+\fBlwres_context_t\fR, closing its socket.
 \fIcontextp\fR
-is a pointer to a pointer to the context that is to be destroyed.
-The pointer will be set to NULL when the context has been destroyed.
+is a pointer to a pointer to the context that is to be destroyed. The pointer will be set to NULL when the context has been destroyed.
 .PP
-The context holds a serial number that is used to identify resolver
-request packets and associate responses with the corresponding requests.
-This serial number is controlled using
+The context holds a serial number that is used to identify resolver request packets and associate responses with the corresponding requests. This serial number is controlled using
 \fBlwres_context_initserial()\fR
 and
 \fBlwres_context_nextserial()\fR.
@@ -136,15 +110,12 @@ increments the serial number and returns the previous value.
 Memory for a lightweight resolver context is allocated and freed using
 \fBlwres_context_allocmem()\fR
 and
-\fBlwres_context_freemem()\fR.
-These use whatever allocations were defined when the context was
-created with
+\fBlwres_context_freemem()\fR. These use whatever allocations were defined when the context was created with
 \fBlwres_context_create()\fR.
 \fBlwres_context_allocmem()\fR
 allocates
 \fIlen\fR
-bytes of memory and if successful returns a pointer to the allocated
-storage.
+bytes of memory and if successful returns a pointer to the allocated storage.
 \fBlwres_context_freemem()\fR
 frees
 \fIlen\fR
@@ -153,39 +124,33 @@ bytes of space starting at location
 .PP
 \fBlwres_context_sendrecv()\fR
 performs I/O for the context
-\fIctx\fR.
-Data are read and written from the context's socket.
-It writes data from
+\fIctx\fR. Data are read and written from the context's socket. It writes data from
 \fIsendbase\fR
-\(em typically a lightweight resolver query packet \(em
-and waits for a reply which is copied to the receive buffer at
-\fIrecvbase\fR.
-The number of bytes that were written to this receive buffer is
-returned in
+\(em typically a lightweight resolver query packet \(em and waits for a reply which is copied to the receive buffer at
+\fIrecvbase\fR. The number of bytes that were written to this receive buffer is returned in
 \fI*recvd_len\fR.
 .SH "RETURN VALUES"
 .PP
 \fBlwres_context_create()\fR
 returns
-LWRES_R_NOMEMORY
+\fBLWRES_R_NOMEMORY\fR
 if memory for the
 \fBstruct lwres_context\fR
-could not be allocated, 
-LWRES_R_SUCCESS
+could not be allocated,
+\fBLWRES_R_SUCCESS\fR
 otherwise.
 .PP
 Successful calls to the memory allocator
 \fBlwres_context_allocmem()\fR
-return a pointer to the start of the allocated space.
-It returns NULL if memory could not be allocated.
+return a pointer to the start of the allocated space. It returns NULL if memory could not be allocated.
 .PP
-LWRES_R_SUCCESS
+\fBLWRES_R_SUCCESS\fR
 is returned when
 \fBlwres_context_sendrecv()\fR
 completes successfully.
-LWRES_R_IOERROR
+\fBLWRES_R_IOERROR\fR
 is returned if an I/O error occurs and
-LWRES_R_TIMEOUT
+\fBLWRES_R_TIMEOUT\fR
 is returned if
 \fBlwres_context_sendrecv()\fR
 times out waiting for a response.
@@ -193,4 +158,4 @@ times out waiting for a response.
 .PP
 \fBlwres_conf_init\fR(3),
 \fBmalloc\fR(3),
-\fBfree\fR(3).
+\fBfree\fR(3 ).
diff --git a/contrib/bind9/lib/lwres/man/lwres_context.docbook b/contrib/bind9/lib/lwres/man/lwres_context.docbook
index 137e4bc209bb..48d43362e1ee 100644
--- a/contrib/bind9/lib/lwres/man/lwres_context.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_context.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_context.docbook,v 1.3.2.2.2.1 2004/03/06 08:15:38 marka Exp $ -->
+<!-- $Id: lwres_context.docbook,v 1.3.2.2.2.3 2005/05/12 21:36:12 sra Exp $ -->
 
 <refentry>
 <refentryinfo>
@@ -29,6 +31,21 @@
 <manvolnum>3</manvolnum>
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
+
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_context_create</refname>
 <refname>lwres_context_destroy</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_context.html b/contrib/bind9/lib/lwres/man/lwres_context.html
index cca12d7d31ea..8988c5dc102f 100644
--- a/contrib/bind9/lib/lwres/man/lwres_context.html
+++ b/contrib/bind9/lib/lwres/man/lwres_context.html
@@ -1,478 +1,335 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_context.html,v 1.5.2.2.2.3 2004/08/22 23:39:03 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_context</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_context</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_context_create, lwres_context_destroy, lwres_context_nextserial, lwres_context_initserial, lwres_context_freemem, lwres_context_allocmem, lwres_context_sendrecv&nbsp;--&nbsp;lightweight resolver context management</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN17"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN18"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwres.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_context_create</CODE
->(lwres_context_t **contextp, void *arg, lwres_malloc_t malloc_function, lwres_free_t free_function);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_context_destroy</CODE
->(lwres_context_t **contextp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_context_initserial</CODE
->(lwres_context_t *ctx, lwres_uint32_t serial);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_uint32_t
-lwres_context_nextserial</CODE
->(lwres_context_t *ctx);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_context_freemem</CODE
->(lwres_context_t *ctx, void *mem, size_t len);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_context_allocmem</CODE
->(lwres_context_t *ctx, size_t len);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void *
-lwres_context_sendrecv</CODE
->(lwres_context_t *ctx, void *sendbase, int sendlen, void *recvbase, int recvlen, int *recvd_len);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN60"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_context_create()</CODE
->
+<!-- $Id: lwres_context.html,v 1.5.2.2.2.10 2005/10/13 02:33:55 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_context</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_context_create, lwres_context_destroy, lwres_context_nextserial, lwres_context_initserial, lwres_context_freemem, lwres_context_allocmem, lwres_context_sendrecv &#8212; lightweight resolver context management</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/lwres.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_context_create</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_context_destroy</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_context_initserial</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+lwres_uint32_t
+<b class="fsfunc">lwres_context_nextserial</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_context_freemem</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_context_allocmem</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+void *
+<b class="fsfunc">lwres_context_sendrecv</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525975"></a><h2>DESCRIPTION</h2>
+<p>
+<code class="function">lwres_context_create()</code>
 creates a
-<SPAN
-CLASS="TYPE"
->lwres_context_t</SPAN
->
+<span class="type">lwres_context_t</span>
 structure for use in lightweight resolver operations.
 It holds a socket and other data needed for communicating
 with a resolver daemon.
 The new
-<SPAN
-CLASS="TYPE"
->lwres_context_t</SPAN
->
+<span class="type">lwres_context_t</span>
 is returned through
-<VAR
-CLASS="PARAMETER"
->contextp</VAR
->,
+<em class="parameter"><code>contextp</code></em>,
 
 a pointer to a
-<SPAN
-CLASS="TYPE"
->lwres_context_t</SPAN
->
+<span class="type">lwres_context_t</span>
 pointer.  This 
-<SPAN
-CLASS="TYPE"
->lwres_context_t</SPAN
->
+<span class="type">lwres_context_t</span>
 pointer must initially be NULL, and is modified 
 to point to the newly created
-<SPAN
-CLASS="TYPE"
->lwres_context_t</SPAN
->.&#13;</P
-><P
->When the lightweight resolver needs to perform dynamic memory
+<span class="type">lwres_context_t</span>.
+
+</p>
+<p>
+When the lightweight resolver needs to perform dynamic memory
 allocation, it will call
-<VAR
-CLASS="PARAMETER"
->malloc_function</VAR
->
+<em class="parameter"><code>malloc_function</code></em>
 to allocate memory and
-<VAR
-CLASS="PARAMETER"
->free_function</VAR
->
+<em class="parameter"><code>free_function</code></em>
 
 to free it.  If 
-<VAR
-CLASS="PARAMETER"
->malloc_function</VAR
->
+<em class="parameter"><code>malloc_function</code></em>
 and
-<VAR
-CLASS="PARAMETER"
->free_function</VAR
->
+<em class="parameter"><code>free_function</code></em>
 
 are NULL, memory is allocated using
 .Xr malloc 3
 and
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->free</SPAN
->(3)</SPAN
->.
+<span class="citerefentry"><span class="refentrytitle">free</span>(3)</span>.
 
 It is not permitted to have a NULL
-<VAR
-CLASS="PARAMETER"
->malloc_function</VAR
->
+<em class="parameter"><code>malloc_function</code></em>
 and a non-NULL
-<VAR
-CLASS="PARAMETER"
->free_function</VAR
->
+<em class="parameter"><code>free_function</code></em>
 or vice versa.
-<VAR
-CLASS="PARAMETER"
->arg</VAR
->
+<em class="parameter"><code>arg</code></em>
 is passed as the first parameter to the memory
 allocation functions.  
 If
-<VAR
-CLASS="PARAMETER"
->malloc_function</VAR
->
+<em class="parameter"><code>malloc_function</code></em>
 and
-<VAR
-CLASS="PARAMETER"
->free_function</VAR
->
+<em class="parameter"><code>free_function</code></em>
 are NULL,
-<VAR
-CLASS="PARAMETER"
->arg</VAR
->
+<em class="parameter"><code>arg</code></em>
 
-is unused and should be passed as NULL.</P
-><P
->Once memory for the structure has been allocated,
+is unused and should be passed as NULL.
+</p>
+<p>
+Once memory for the structure has been allocated,
 it is initialized using
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_conf_init</SPAN
->(3)</SPAN
->
+<span class="citerefentry"><span class="refentrytitle">lwres_conf_init</span>(3)</span>
 
 and returned via
-<VAR
-CLASS="PARAMETER"
->*contextp</VAR
->.&#13;</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_context_destroy()</CODE
->
+<em class="parameter"><code>*contextp</code></em>.
+
+</p>
+<p>
+<code class="function">lwres_context_destroy()</code>
 destroys a 
-<SPAN
-CLASS="TYPE"
->lwres_context_t</SPAN
->,
+<span class="type">lwres_context_t</span>,
 
 closing its socket.
-<VAR
-CLASS="PARAMETER"
->contextp</VAR
->
+<em class="parameter"><code>contextp</code></em>
 is a pointer to a pointer to the context that is to be destroyed.
-The pointer will be set to NULL when the context has been destroyed.</P
-><P
->The context holds a serial number that is used to identify resolver
+The pointer will be set to NULL when the context has been destroyed.
+</p>
+<p>
+The context holds a serial number that is used to identify resolver
 request packets and associate responses with the corresponding requests.
 This serial number is controlled using
-<CODE
-CLASS="FUNCTION"
->lwres_context_initserial()</CODE
->
+<code class="function">lwres_context_initserial()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_context_nextserial()</CODE
->.
-<CODE
-CLASS="FUNCTION"
->lwres_context_initserial()</CODE
->
+<code class="function">lwres_context_nextserial()</code>.
+<code class="function">lwres_context_initserial()</code>
 sets the serial number for context
-<VAR
-CLASS="PARAMETER"
->*ctx</VAR
->
+<em class="parameter"><code>*ctx</code></em>
 to
-<VAR
-CLASS="PARAMETER"
->serial</VAR
->.
+<em class="parameter"><code>serial</code></em>.
 
-<CODE
-CLASS="FUNCTION"
->lwres_context_nextserial()</CODE
->
-increments the serial number and returns the previous value.</P
-><P
->Memory for a lightweight resolver context is allocated and freed using
-<CODE
-CLASS="FUNCTION"
->lwres_context_allocmem()</CODE
->
+<code class="function">lwres_context_nextserial()</code>
+increments the serial number and returns the previous value.
+</p>
+<p>
+Memory for a lightweight resolver context is allocated and freed using
+<code class="function">lwres_context_allocmem()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_context_freemem()</CODE
->.
+<code class="function">lwres_context_freemem()</code>.
 These use whatever allocations were defined when the context was
 created with
-<CODE
-CLASS="FUNCTION"
->lwres_context_create()</CODE
->.
-<CODE
-CLASS="FUNCTION"
->lwres_context_allocmem()</CODE
->
+<code class="function">lwres_context_create()</code>.
+<code class="function">lwres_context_allocmem()</code>
 allocates
-<VAR
-CLASS="PARAMETER"
->len</VAR
->
+<em class="parameter"><code>len</code></em>
 bytes of memory and if successful returns a pointer to the allocated
 storage.
-<CODE
-CLASS="FUNCTION"
->lwres_context_freemem()</CODE
->
+<code class="function">lwres_context_freemem()</code>
 frees
-<VAR
-CLASS="PARAMETER"
->len</VAR
->
+<em class="parameter"><code>len</code></em>
 bytes of space starting at location
-<VAR
-CLASS="PARAMETER"
->mem</VAR
->.&#13;</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_context_sendrecv()</CODE
->
+<em class="parameter"><code>mem</code></em>.
+
+</p>
+<p>
+<code class="function">lwres_context_sendrecv()</code>
 performs I/O for the context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
->.
+<em class="parameter"><code>ctx</code></em>.
 
 Data are read and written from the context's socket.
 It writes data from
-<VAR
-CLASS="PARAMETER"
->sendbase</VAR
->
-&mdash; typically a lightweight resolver query packet &mdash;
+<em class="parameter"><code>sendbase</code></em>
+&#8212; typically a lightweight resolver query packet &#8212;
 and waits for a reply which is copied to the receive buffer at
-<VAR
-CLASS="PARAMETER"
->recvbase</VAR
->.
+<em class="parameter"><code>recvbase</code></em>.
 
 The number of bytes that were written to this receive buffer is
 returned in
-<VAR
-CLASS="PARAMETER"
->*recvd_len</VAR
->.&#13;</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN115"
-></A
-><H2
->RETURN VALUES</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_context_create()</CODE
->
+<em class="parameter"><code>*recvd_len</code></em>.
+
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526156"></a><h2>RETURN VALUES</h2>
+<p>
+<code class="function">lwres_context_create()</code>
 returns
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_NOMEMORY</SPAN
->
+<span class="errorcode">LWRES_R_NOMEMORY</span>
 if memory for the
-<SPAN
-CLASS="TYPE"
->struct lwres_context</SPAN
->
+<span class="type">struct lwres_context</span>
 could not be allocated, 
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
-otherwise.</P
-><P
->Successful calls to the memory allocator
-<CODE
-CLASS="FUNCTION"
->lwres_context_allocmem()</CODE
->
+<span class="errorcode">LWRES_R_SUCCESS</span>
+otherwise.
+</p>
+<p>
+Successful calls to the memory allocator
+<code class="function">lwres_context_allocmem()</code>
 return a pointer to the start of the allocated space.
-It returns NULL if memory could not be allocated.</P
-><P
-><SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
+It returns NULL if memory could not be allocated.
+</p>
+<p>
+<span class="errorcode">LWRES_R_SUCCESS</span>
 is returned when
-<CODE
-CLASS="FUNCTION"
->lwres_context_sendrecv()</CODE
->
+<code class="function">lwres_context_sendrecv()</code>
 completes successfully.
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_IOERROR</SPAN
->
+<span class="errorcode">LWRES_R_IOERROR</span>
 is returned if an I/O error occurs and
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_TIMEOUT</SPAN
->
+<span class="errorcode">LWRES_R_TIMEOUT</span>
 is returned if
-<CODE
-CLASS="FUNCTION"
->lwres_context_sendrecv()</CODE
->
-times out waiting for a response.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN130"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_conf_init</SPAN
->(3)</SPAN
->,
+<code class="function">lwres_context_sendrecv()</code>
+times out waiting for a response.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526208"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres_conf_init</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->malloc</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">malloc</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->free</SPAN
->(3)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+<span class="citerefentry"><span class="refentrytitle">free</span>(3
+)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.3 b/contrib/bind9/lib/lwres/man/lwres_gabn.3
index a309f3e62390..60a56fe46b35 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gabn.3
+++ b/contrib/bind9/lib/lwres/man/lwres_gabn.3
@@ -1,91 +1,72 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gabn.3,v 1.13.2.1.8.1 2004/03/06 07:41:42 marka Exp $
+.\" $Id: lwres_gabn.3,v 1.13.2.1.8.5 2005/10/13 02:33:52 marka Exp $
 .\"
-.TH "LWRES_GABN" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_GABN" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_gabnrequest_render, lwres_gabnresponse_render, lwres_gabnrequest_parse, lwres_gabnresponse_parse, lwres_gabnresponse_free, lwres_gabnrequest_free \- lightweight resolver getaddrbyname message handling
-.SH SYNOPSIS
-\fB#include <lwres/lwres.h>
-.sp
-.na
-lwres_result_t
-lwres_gabnrequest_render(lwres_context_t *ctx, lwres_gabnrequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_gabnresponse_render(lwres_context_t *ctx, lwres_gabnresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_gabnrequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gabnrequest_t **structp);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_gabnresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gabnresponse_t **structp);
-.ad
-.sp
-.na
-void
-lwres_gabnresponse_free(lwres_context_t *ctx, lwres_gabnresponse_t **structp);
-.ad
-.sp
-.na
-void
-lwres_gabnrequest_free(lwres_context_t *ctx, lwres_gabnrequest_t **structp);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwres.h>
+.fi
+.HP 40
+\fBlwres_result_t\ \fBlwres_gabnrequest_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gabnrequest_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 41
+\fBlwres_result_t\ \fBlwres_gabnresponse_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gabnresponse_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 39
+\fBlwres_result_t\ \fBlwres_gabnrequest_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_gabnrequest_t\ **structp\fR\fB);\fR
+.HP 40
+\fBlwres_result_t\ \fBlwres_gabnresponse_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_gabnresponse_t\ **structp\fR\fB);\fR
+.HP 29
+\fBvoid\ \fBlwres_gabnresponse_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gabnresponse_t\ **structp\fR\fB);\fR
+.HP 28
+\fBvoid\ \fBlwres_gabnrequest_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gabnrequest_t\ **structp\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-These are low-level routines for creating and parsing
-lightweight resolver name-to-address lookup request and 
-response messages.
+These are low\-level routines for creating and parsing lightweight resolver name\-to\-address lookup request and response messages.
 .PP
-There are four main functions for the getaddrbyname opcode.
-One render function converts a getaddrbyname request structure \(em
-\fBlwres_gabnrequest_t\fR \(em
-to the lighweight resolver's canonical format.
-It is complemented by a parse function that converts a packet in this
-canonical format to a getaddrbyname request structure.
-Another render function converts the getaddrbyname response structure \(em
-\fBlwres_gabnresponse_t\fR \(em
-to the canonical format.
-This is complemented by a parse function which converts a packet in
-canonical format to a getaddrbyname response structure.
+There are four main functions for the getaddrbyname opcode. One render function converts a getaddrbyname request structure \(em
+\fBlwres_gabnrequest_t\fR
+\(em to the lighweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a getaddrbyname request structure. Another render function converts the getaddrbyname response structure \(em
+\fBlwres_gabnresponse_t\fR
+\(em to the canonical format. This is complemented by a parse function which converts a packet in canonical format to a getaddrbyname response structure.
 .PP
 These structures are defined in
-\fI<lwres/lwres.h>\fR.
-They are shown below.
+\fI<lwres/lwres.h>\fR. They are shown below.
 .sp
 .nf
 #define LWRES_OPCODE_GETADDRSBYNAME     0x00010001U
-
 typedef struct lwres_addr lwres_addr_t;
 typedef LWRES_LIST(lwres_addr_t) lwres_addrlist_t;
-
 typedef struct {
         lwres_uint32_t  flags;
         lwres_uint32_t  addrtypes;
         lwres_uint16_t  namelen;
         char           *name;
 } lwres_gabnrequest_t;
-
 typedef struct {
         lwres_uint32_t          flags;
         lwres_uint16_t          naliases;
@@ -98,21 +79,18 @@ typedef struct {
         void                   *base;
         size_t                  baselen;
 } lwres_gabnresponse_t;
-.sp
 .fi
+.sp
 .PP
 \fBlwres_gabnrequest_render()\fR
 uses resolver context
 \fIctx\fR
 to convert getaddrbyname request structure
 \fIreq\fR
-to canonical format.
-The packet header structure
+to canonical format. The packet header structure
 \fIpkt\fR
-is initialised and transferred to
-buffer
-\fIb\fR.
-The contents of
+is initialised and transferred to buffer
+\fIb\fR. The contents of
 \fI*req\fR
 are then appended to the buffer in canonical format.
 \fBlwres_gabnresponse_render()\fR
@@ -127,11 +105,9 @@ to convert the contents of packet
 \fIpkt\fR
 to a
 \fBlwres_gabnrequest_t\fR
-structure.
-Buffer
+structure. Buffer
 \fIb\fR
-provides space to be used for storing this structure.
-When the function succeeds, the resulting
+provides space to be used for storing this structure. When the function succeeds, the resulting
 \fBlwres_gabnrequest_t\fR
 is made available through
 \fI*structp\fR.
@@ -152,24 +128,20 @@ that was allocated to the
 or
 \fBlwres_gabnrequest_t\fR
 structures referenced via
-\fIstructp\fR.
-Any memory associated with ancillary buffers and strings for those
-structures is also discarded.
+\fIstructp\fR. Any memory associated with ancillary buffers and strings for those structures is also discarded.
 .SH "RETURN VALUES"
 .PP
 The getaddrbyname opcode functions
-\fBlwres_gabnrequest_render()\fR, 
-\fBlwres_gabnresponse_render()\fR
-\fBlwres_gabnrequest_parse()\fR
+\fBlwres_gabnrequest_render()\fR,
+\fBlwres_gabnresponse_render()\fR\fBlwres_gabnrequest_parse()\fR
 and
 \fBlwres_gabnresponse_parse()\fR
 all return
-LWRES_R_SUCCESS
-on success.
-They return
-LWRES_R_NOMEMORY
+\fBLWRES_R_SUCCESS\fR
+on success. They return
+\fBLWRES_R_NOMEMORY\fR
 if memory allocation fails.
-LWRES_R_UNEXPECTEDEND
+\fBLWRES_R_UNEXPECTEDEND\fR
 is returned if the available space in the buffer
 \fIb\fR
 is too small to accommodate the packet header or the
@@ -181,15 +153,14 @@ structures.
 and
 \fBlwres_gabnresponse_parse()\fR
 will return
-LWRES_R_UNEXPECTEDEND
-if the buffer is not empty after decoding the received packet.
-These functions will return
-LWRES_R_FAILURE
+\fBLWRES_R_UNEXPECTEDEND\fR
+if the buffer is not empty after decoding the received packet. These functions will return
+\fBLWRES_R_FAILURE\fR
 if
-\fBpktflags\fR
+pktflags
 in the packet header structure
 \fBlwres_lwpacket_t\fR
 indicate that the packet is not a response to an earlier query.
 .SH "SEE ALSO"
 .PP
-\fBlwres_packet\fR(3)
+\fBlwres_packet\fR(3 )
diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.docbook b/contrib/bind9/lib/lwres/man/lwres_gabn.docbook
index cb9481f4aa84..6e90ea3905b3 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gabn.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_gabn.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_gabn.docbook,v 1.3.206.1 2004/03/06 08:15:38 marka Exp $ -->
+<!-- $Id: lwres_gabn.docbook,v 1.3.206.3 2005/05/12 21:36:12 sra Exp $ -->
 
 <refentry>
 <refentryinfo>
@@ -29,6 +31,20 @@
 <manvolnum>3</manvolnum>
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
+
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_gabnrequest_render</refname>
 <refname>lwres_gabnresponse_render</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.html b/contrib/bind9/lib/lwres/man/lwres_gabn.html
index 6cb6614cbd55..771394508a28 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gabn.html
+++ b/contrib/bind9/lib/lwres/man/lwres_gabn.html
@@ -1,158 +1,195 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_gabn.html,v 1.6.2.1.4.2 2004/08/22 23:39:03 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_gabn</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_gabn</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_gabnrequest_render, lwres_gabnresponse_render, lwres_gabnrequest_parse, lwres_gabnresponse_parse, lwres_gabnresponse_free, lwres_gabnrequest_free&nbsp;--&nbsp;lightweight resolver getaddrbyname message handling</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN16"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN17"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwres.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_gabnrequest_render</CODE
->(lwres_context_t *ctx, lwres_gabnrequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_gabnresponse_render</CODE
->(lwres_context_t *ctx, lwres_gabnresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_gabnrequest_parse</CODE
->(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gabnrequest_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_gabnresponse_parse</CODE
->(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gabnresponse_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_gabnresponse_free</CODE
->(lwres_context_t *ctx, lwres_gabnresponse_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_gabnrequest_free</CODE
->(lwres_context_t *ctx, lwres_gabnrequest_t **structp);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN57"
-></A
-><H2
->DESCRIPTION</H2
-><P
->These are low-level routines for creating and parsing
+<!-- $Id: lwres_gabn.html,v 1.6.2.1.4.9 2005/10/13 02:33:55 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_gabn</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_gabnrequest_render, lwres_gabnresponse_render, lwres_gabnrequest_parse, lwres_gabnresponse_parse, lwres_gabnresponse_free, lwres_gabnrequest_free &#8212; lightweight resolver getaddrbyname message handling</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/lwres.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_gabnrequest_render</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_gabnresponse_render</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_gabnrequest_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_gabnresponse_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_gabnresponse_free</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_gabnrequest_free</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525963"></a><h2>DESCRIPTION</h2>
+<p>
+These are low-level routines for creating and parsing
 lightweight resolver name-to-address lookup request and 
-response messages.</P
-><P
->There are four main functions for the getaddrbyname opcode.
-One render function converts a getaddrbyname request structure &mdash;
-<SPAN
-CLASS="TYPE"
->lwres_gabnrequest_t</SPAN
-> &mdash;
+response messages.
+</p>
+<p>
+There are four main functions for the getaddrbyname opcode.
+One render function converts a getaddrbyname request structure &#8212;
+<span class="type">lwres_gabnrequest_t</span> &#8212;
 to the lighweight resolver's canonical format.
 It is complemented by a parse function that converts a packet in this
 canonical format to a getaddrbyname request structure.
-Another render function converts the getaddrbyname response structure &mdash;
-<SPAN
-CLASS="TYPE"
->lwres_gabnresponse_t</SPAN
-> &mdash;
+Another render function converts the getaddrbyname response structure &#8212;
+<span class="type">lwres_gabnresponse_t</span> &#8212;
 to the canonical format.
 This is complemented by a parse function which converts a packet in
-canonical format to a getaddrbyname response structure.</P
-><P
->These structures are defined in
-<TT
-CLASS="FILENAME"
->&lt;lwres/lwres.h&gt;</TT
->.
+canonical format to a getaddrbyname response structure.
+</p>
+<p>
+These structures are defined in
+<code class="filename">&lt;lwres/lwres.h&gt;</code>.
 They are shown below.
-<PRE
-CLASS="PROGRAMLISTING"
->#define LWRES_OPCODE_GETADDRSBYNAME     0x00010001U
+</p>
+<pre class="programlisting">
+#define LWRES_OPCODE_GETADDRSBYNAME     0x00010001U
 
 typedef struct lwres_addr lwres_addr_t;
 typedef LWRES_LIST(lwres_addr_t) lwres_addrlist_t;
@@ -175,245 +212,116 @@ typedef struct {
         lwres_addrlist_t        addrs;
         void                   *base;
         size_t                  baselen;
-} lwres_gabnresponse_t;</PRE
-></P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gabnrequest_render()</CODE
->
+} lwres_gabnresponse_t;
+</pre>
+<p>
+</p>
+<p>
+<code class="function">lwres_gabnrequest_render()</code>
 uses resolver context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
->
+<em class="parameter"><code>ctx</code></em>
 to convert getaddrbyname request structure
-<VAR
-CLASS="PARAMETER"
->req</VAR
->
+<em class="parameter"><code>req</code></em>
 to canonical format.
 The packet header structure
-<VAR
-CLASS="PARAMETER"
->pkt</VAR
->
+<em class="parameter"><code>pkt</code></em>
 is initialised and transferred to
 buffer
-<VAR
-CLASS="PARAMETER"
->b</VAR
->.
+<em class="parameter"><code>b</code></em>.
 
 The contents of
-<VAR
-CLASS="PARAMETER"
->*req</VAR
->
+<em class="parameter"><code>*req</code></em>
 are then appended to the buffer in canonical format.
-<CODE
-CLASS="FUNCTION"
->lwres_gabnresponse_render()</CODE
->
+<code class="function">lwres_gabnresponse_render()</code>
 performs the same task, except it converts a getaddrbyname response structure
-<SPAN
-CLASS="TYPE"
->lwres_gabnresponse_t</SPAN
->
-to the lightweight resolver's canonical format.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gabnrequest_parse()</CODE
->
+<span class="type">lwres_gabnresponse_t</span>
+to the lightweight resolver's canonical format.
+</p>
+<p>
+<code class="function">lwres_gabnrequest_parse()</code>
 uses context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
->
+<em class="parameter"><code>ctx</code></em>
 to convert the contents of packet
-<VAR
-CLASS="PARAMETER"
->pkt</VAR
->
+<em class="parameter"><code>pkt</code></em>
 to a
-<SPAN
-CLASS="TYPE"
->lwres_gabnrequest_t</SPAN
->
+<span class="type">lwres_gabnrequest_t</span>
 structure.
 Buffer
-<VAR
-CLASS="PARAMETER"
->b</VAR
->
+<em class="parameter"><code>b</code></em>
 provides space to be used for storing this structure.
 When the function succeeds, the resulting
-<SPAN
-CLASS="TYPE"
->lwres_gabnrequest_t</SPAN
->
+<span class="type">lwres_gabnrequest_t</span>
 is made available through
-<VAR
-CLASS="PARAMETER"
->*structp</VAR
->.
+<em class="parameter"><code>*structp</code></em>.
 
-<CODE
-CLASS="FUNCTION"
->lwres_gabnresponse_parse()</CODE
->
+<code class="function">lwres_gabnresponse_parse()</code>
 offers the same semantics as
-<CODE
-CLASS="FUNCTION"
->lwres_gabnrequest_parse()</CODE
->
+<code class="function">lwres_gabnrequest_parse()</code>
 except it yields a
-<SPAN
-CLASS="TYPE"
->lwres_gabnresponse_t</SPAN
->
-structure.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gabnresponse_free()</CODE
->
+<span class="type">lwres_gabnresponse_t</span>
+structure.
+</p>
+<p>
+<code class="function">lwres_gabnresponse_free()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gabnrequest_free()</CODE
->
+<code class="function">lwres_gabnrequest_free()</code>
 release the memory in resolver context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
->
+<em class="parameter"><code>ctx</code></em>
 that was allocated to the
-<SPAN
-CLASS="TYPE"
->lwres_gabnresponse_t</SPAN
->
+<span class="type">lwres_gabnresponse_t</span>
 or
-<SPAN
-CLASS="TYPE"
->lwres_gabnrequest_t</SPAN
->
+<span class="type">lwres_gabnrequest_t</span>
 structures referenced via
-<VAR
-CLASS="PARAMETER"
->structp</VAR
->.
+<em class="parameter"><code>structp</code></em>.
 
 Any memory associated with ancillary buffers and strings for those
-structures is also discarded.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN93"
-></A
-><H2
->RETURN VALUES</H2
-><P
->The getaddrbyname opcode functions
-<CODE
-CLASS="FUNCTION"
->lwres_gabnrequest_render()</CODE
->, 
-<CODE
-CLASS="FUNCTION"
->lwres_gabnresponse_render()</CODE
->
-<CODE
-CLASS="FUNCTION"
->lwres_gabnrequest_parse()</CODE
->
+structures is also discarded.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526155"></a><h2>RETURN VALUES</h2>
+<p>
+The getaddrbyname opcode functions
+<code class="function">lwres_gabnrequest_render()</code>, 
+<code class="function">lwres_gabnresponse_render()</code>
+<code class="function">lwres_gabnrequest_parse()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gabnresponse_parse()</CODE
->
+<code class="function">lwres_gabnresponse_parse()</code>
 all return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
+<span class="errorcode">LWRES_R_SUCCESS</span>
 on success.
 They return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_NOMEMORY</SPAN
->
+<span class="errorcode">LWRES_R_NOMEMORY</span>
 if memory allocation fails.
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->
+<span class="errorcode">LWRES_R_UNEXPECTEDEND</span>
 is returned if the available space in the buffer
-<VAR
-CLASS="PARAMETER"
->b</VAR
->
+<em class="parameter"><code>b</code></em>
 is too small to accommodate the packet header or the
-<SPAN
-CLASS="TYPE"
->lwres_gabnrequest_t</SPAN
->
+<span class="type">lwres_gabnrequest_t</span>
 and
-<SPAN
-CLASS="TYPE"
->lwres_gabnresponse_t</SPAN
->
+<span class="type">lwres_gabnresponse_t</span>
 structures.
-<CODE
-CLASS="FUNCTION"
->lwres_gabnrequest_parse()</CODE
->
+<code class="function">lwres_gabnrequest_parse()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gabnresponse_parse()</CODE
->
+<code class="function">lwres_gabnresponse_parse()</code>
 will return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->
+<span class="errorcode">LWRES_R_UNEXPECTEDEND</span>
 if the buffer is not empty after decoding the received packet.
 These functions will return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_FAILURE</SPAN
->
+<span class="errorcode">LWRES_R_FAILURE</span>
 if
-<CODE
-CLASS="STRUCTFIELD"
->pktflags</CODE
->
+<em class="structfield"><code>pktflags</code></em>
 in the packet header structure
-<SPAN
-CLASS="TYPE"
->lwres_lwpacket_t</SPAN
->
-indicate that the packet is not a response to an earlier query.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN112"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_packet</SPAN
->(3)</SPAN
-></P
-></DIV
-></BODY
-></HTML
->
+<span class="type">lwres_lwpacket_t</span>
+indicate that the packet is not a response to an earlier query.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526220"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres_packet</span>(3
+)</span>
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3 b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3
index ea75066f8aec..388c59e0f1ef 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3
+++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3
@@ -1,37 +1,44 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gai_strerror.3,v 1.13.2.1.8.1 2004/03/06 07:41:43 marka Exp $
+.\" $Id: lwres_gai_strerror.3,v 1.13.2.1.8.5 2005/10/13 02:33:52 marka Exp $
 .\"
-.TH "LWRES_GAI_STRERROR" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_GAI_STRERROR" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 gai_strerror \- print suitable error string
-.SH SYNOPSIS
-\fB#include <lwres/netdb.h>
-.sp
-.na
-char *
-gai_strerror(int ecode);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/netdb.h>
+.fi
+.HP 20
+\fBchar\ *\ \fBgai_strerror\fR\fR\fB(\fR\fBint\ ecode\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
 \fBlwres_gai_strerror()\fR
 returns an error message corresponding to an error code returned by
-\fBgetaddrinfo()\fR.
-The following error codes and their meaning are defined in
+\fBgetaddrinfo()\fR. The following error codes and their meaning are defined in
 \fIinclude/lwres/netdb.h\fR.
 .TP
 \fBEAI_ADDRFAMILY\fR
@@ -42,13 +49,14 @@ temporary failure in name resolution
 .TP
 \fBEAI_BADFLAGS\fR
 invalid value for
-ai_flags
+\fBai_flags\fR
 .TP
 \fBEAI_FAIL\fR
-non-recoverable failure in name resolution
+non\-recoverable failure in name resolution
 .TP
 \fBEAI_FAMILY\fR
-ai_family not supported
+\fBai_family\fR
+not supported
 .TP
 \fBEAI_MEMORY\fR
 memory allocation failure
@@ -60,22 +68,25 @@ no address associated with hostname
 hostname or servname not provided, or not known
 .TP
 \fBEAI_SERVICE\fR
-servname not supported for ai_socktype
+servname not supported for
+\fBai_socktype\fR
 .TP
 \fBEAI_SOCKTYPE\fR
-ai_socktype not supported
+\fBai_socktype\fR
+not supported
 .TP
 \fBEAI_SYSTEM\fR
 system error returned in errno
-.PP
-The message \fBinvalid error code\fR is returned if
+The message
+invalid error code
+is returned if
 \fIecode\fR
 is out of range.
 .PP
-ai_flags,
-ai_family
+\fBai_flags\fR,
+\fBai_family\fR
 and
-ai_socktype
+\fBai_socktype\fR
 are elements of the
 \fBstruct addrinfo\fR
 used by
@@ -85,4 +96,4 @@ used by
 \fBstrerror\fR(3),
 \fBlwres_getaddrinfo\fR(3),
 \fBgetaddrinfo\fR(3),
-\fBRFC2133\fR.
+\fBRFC2133\fR().
diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook
index 475d4441d0cb..f34836d2a2c4 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_gai_strerror.docbook,v 1.3.206.1 2004/03/06 08:15:38 marka Exp $ -->
+<!-- $Id: lwres_gai_strerror.docbook,v 1.3.206.3 2005/05/12 21:36:13 sra Exp $ -->
 
 <refentry>
 <refentryinfo>
@@ -29,6 +31,20 @@
 <manvolnum>3</manvolnum>
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
+
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>gai_strerror</refname>
 <refpurpose>print suitable error string</refpurpose>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html
index 45dc5cb3d027..5506564197e3 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html
+++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html
@@ -1,295 +1,124 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_gai_strerror.html,v 1.5.2.1.4.2 2004/08/22 23:39:03 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_gai_strerror</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_gai_strerror</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->gai_strerror&nbsp;--&nbsp;print suitable error string</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN11"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN12"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/netdb.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->char *
-gai_strerror</CODE
->(int ecode);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN18"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gai_strerror()</CODE
->
+<!-- $Id: lwres_gai_strerror.html,v 1.5.2.1.4.9 2005/10/13 02:33:55 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_gai_strerror</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>gai_strerror &#8212; print suitable error string</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/netdb.h&gt;</pre>
+<p><code class="funcdef">
+char *
+<b class="fsfunc">gai_strerror</b>(</code>int ecode<code>)</code>;</p>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525843"></a><h2>DESCRIPTION</h2>
+<p>
+<code class="function">lwres_gai_strerror()</code>
 returns an error message corresponding to an error code returned by
-<CODE
-CLASS="FUNCTION"
->getaddrinfo()</CODE
->.
+<code class="function">getaddrinfo()</code>.
 The following error codes and their meaning are defined in
-<TT
-CLASS="FILENAME"
->include/lwres/netdb.h</TT
->.
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_ADDRFAMILY</SPAN
-></DT
-><DD
-><P
->address family for hostname not supported</P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_AGAIN</SPAN
-></DT
-><DD
-><P
->temporary failure in name resolution</P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_BADFLAGS</SPAN
-></DT
-><DD
-><P
->invalid value for
-<CODE
-CLASS="CONSTANT"
->ai_flags</CODE
-></P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_FAIL</SPAN
-></DT
-><DD
-><P
->non-recoverable failure in name resolution</P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_FAMILY</SPAN
-></DT
-><DD
-><P
-><CODE
-CLASS="CONSTANT"
->ai_family</CODE
-> not supported</P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_MEMORY</SPAN
-></DT
-><DD
-><P
->memory allocation failure</P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_NODATA</SPAN
-></DT
-><DD
-><P
->no address associated with hostname</P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_NONAME</SPAN
-></DT
-><DD
-><P
->hostname or servname not provided, or not known</P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_SERVICE</SPAN
-></DT
-><DD
-><P
->servname not supported for <CODE
-CLASS="CONSTANT"
->ai_socktype</CODE
-></P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_SOCKTYPE</SPAN
-></DT
-><DD
-><P
-><CODE
-CLASS="CONSTANT"
->ai_socktype</CODE
-> not supported</P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->EAI_SYSTEM</SPAN
-></DT
-><DD
-><P
->system error returned in errno</P
-></DD
-></DL
-></DIV
->
-The message <SPAN
-CLASS="ERRORNAME"
->invalid error code</SPAN
-> is returned if
-<VAR
-CLASS="PARAMETER"
->ecode</VAR
->
-is out of range.</P
-><P
-><CODE
-CLASS="CONSTANT"
->ai_flags</CODE
->,
-<CODE
-CLASS="CONSTANT"
->ai_family</CODE
->
+<code class="filename">include/lwres/netdb.h</code>.
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span class="errorcode">EAI_ADDRFAMILY</span></span></dt>
+<dd><p>
+address family for hostname not supported
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_AGAIN</span></span></dt>
+<dd><p>
+temporary failure in name resolution
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_BADFLAGS</span></span></dt>
+<dd><p>
+invalid value for
+<code class="constant">ai_flags</code>
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_FAIL</span></span></dt>
+<dd><p>
+non-recoverable failure in name resolution
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_FAMILY</span></span></dt>
+<dd><p>
+<code class="constant">ai_family</code> not supported
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_MEMORY</span></span></dt>
+<dd><p>
+memory allocation failure
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_NODATA</span></span></dt>
+<dd><p>
+no address associated with hostname
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_NONAME</span></span></dt>
+<dd><p>
+hostname or servname not provided, or not known
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_SERVICE</span></span></dt>
+<dd><p>
+servname not supported for <code class="constant">ai_socktype</code>
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_SOCKTYPE</span></span></dt>
+<dd><p>
+<code class="constant">ai_socktype</code> not supported
+</p></dd>
+<dt><span class="term"><span class="errorcode">EAI_SYSTEM</span></span></dt>
+<dd><p>
+system error returned in errno
+</p></dd>
+</dl></div>
+<p>
+The message <span class="errorname">invalid error code</span> is returned if
+<em class="parameter"><code>ecode</code></em>
+is out of range.
+</p>
+<p>
+<code class="constant">ai_flags</code>,
+<code class="constant">ai_family</code>
 and
-<CODE
-CLASS="CONSTANT"
->ai_socktype</CODE
->
+<code class="constant">ai_socktype</code>
 are elements of the
-<SPAN
-CLASS="TYPE"
->struct  addrinfo</SPAN
->
+<span class="type">struct  addrinfo</span>
 used by
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN92"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->strerror</SPAN
->(3)</SPAN
->,
+<code class="function">lwres_getaddrinfo()</code>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526040"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">strerror</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getaddrinfo</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_getaddrinfo</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->getaddrinfo</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">getaddrinfo</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2133</SPAN
-></SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+<span class="citerefentry"><span class="refentrytitle">RFC2133</span></span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3 b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3
index d360b3e807a6..df1390a95ebe 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3
+++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3
@@ -1,40 +1,44 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getaddrinfo.3,v 1.16.2.1.8.2 2004/03/06 07:41:43 marka Exp $
+.\" $Id: lwres_getaddrinfo.3,v 1.16.2.1.8.6 2005/10/13 02:33:53 marka Exp $
 .\"
-.TH "LWRES_GETADDRINFO" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_GETADDRINFO" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_getaddrinfo, lwres_freeaddrinfo \- socket address structure to host and service name
-.SH SYNOPSIS
-\fB#include <lwres/netdb.h>
-.sp
-.na
-int
-lwres_getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res);
-.ad
-.sp
-.na
-void
-lwres_freeaddrinfo(struct addrinfo *ai);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/netdb.h>
+.fi
+.HP 22
+\fBint\ \fBlwres_getaddrinfo\fR\fR\fB(\fR\fBconst\ char\ *hostname\fR\fB, \fR\fBconst\ char\ *servname\fR\fB, \fR\fBconst\ struct\ addrinfo\ *hints\fR\fB, \fR\fBstruct\ addrinfo\ **res\fR\fB);\fR
+.HP 24
+\fBvoid\ \fBlwres_freeaddrinfo\fR\fR\fB(\fR\fBstruct\ addrinfo\ *ai\fR\fB);\fR
 .PP
 If the operating system does not provide a
-\fBstruct addrinfo\fR,
-the following structure is used:
+\fBstruct addrinfo\fR, the following structure is used:
 .sp
 .nf
 struct  addrinfo {
@@ -47,47 +51,38 @@ struct  addrinfo {
         struct sockaddr *ai_addr;       /* binary address */
         struct addrinfo *ai_next;       /* next structure in linked list */
 };
-.sp
 .fi
+.sp
 .SH "DESCRIPTION"
 .PP
 \fBlwres_getaddrinfo()\fR
 is used to get a list of IP addresses and port numbers for host
 \fIhostname\fR
 and service
-\fIservname\fR.
-The function is the lightweight resolver's implementation of
+\fIservname\fR. The function is the lightweight resolver's implementation of
 \fBgetaddrinfo()\fR
 as defined in RFC2133.
 \fIhostname\fR
 and
 \fIservname\fR
-are pointers to null-terminated
-strings or
+are pointers to null\-terminated strings or
 \fBNULL\fR.
 \fIhostname\fR
-is either a host name or a numeric host address string: a dotted decimal
-IPv4 address or an IPv6 address.
+is either a host name or a numeric host address string: a dotted decimal IPv4 address or an IPv6 address.
 \fIservname\fR
 is either a decimal port number or a service name as listed in
 \fI/etc/services\fR.
 .PP
 \fIhints\fR
 is an optional pointer to a
-\fBstruct addrinfo\fR.
-This structure can be used to provide hints concerning the type of socket
-that the caller supports or wishes to use.
-The caller can supply the following structure elements in
+\fBstruct addrinfo\fR. This structure can be used to provide hints concerning the type of socket that the caller supports or wishes to use. The caller can supply the following structure elements in
 \fI*hints\fR:
 .TP
 \fBai_family\fR
-The protocol family that should be used.
-When
-ai_family
+The protocol family that should be used. When
+\fBai_family\fR
 is set to
-\fBPF_UNSPEC\fR,
-it means the caller will accept any protocol family supported by the
-operating system.
+\fBPF_UNSPEC\fR, it means the caller will accept any protocol family supported by the operating system.
 .TP
 \fBai_socktype\fR
 denotes the type of socket \(em
@@ -95,122 +90,107 @@ denotes the type of socket \(em
 \fBSOCK_DGRAM\fR
 or
 \fBSOCK_RAW\fR
-\(em that is wanted.
-When
-ai_socktype
+\(em that is wanted. When
+\fBai_socktype\fR
 is zero the caller will accept any socket type.
 .TP
 \fBai_protocol\fR
-indicates which transport protocol is wanted: IPPROTO_UDP or 
-IPPROTO_TCP.
-If
-ai_protocol
+indicates which transport protocol is wanted: IPPROTO_UDP or IPPROTO_TCP. If
+\fBai_protocol\fR
 is zero the caller will accept any protocol.
 .TP
 \fBai_flags\fR
-Flag bits.
-If the
+Flag bits. If the
 \fBAI_CANONNAME\fR
 bit is set, a successful call to
 \fBlwres_getaddrinfo()\fR
-will return a null-terminated string containing the canonical name
-of the specified hostname in
-ai_canonname
+will return a null\-terminated string containing the canonical name of the specified hostname in
+\fBai_canonname\fR
 of the first
 \fBaddrinfo\fR
-structure returned.
-Setting the
+structure returned. Setting the
 \fBAI_PASSIVE\fR
-bit indicates that the returned socket address structure is intended
-for used in a call to
-\fBbind\fR(2).
-In this case, if the hostname argument is a
+bit indicates that the returned socket address structure is intended for used in a call to
+\fBbind\fR(2). In this case, if the hostname argument is a
 \fBNULL\fR
-pointer, then the IP address portion of the socket
-address structure will be set to
+pointer, then the IP address portion of the socket address structure will be set to
 \fBINADDR_ANY\fR
 for an IPv4 address or
 \fBIN6ADDR_ANY_INIT\fR
 for an IPv6 address.
-
+.sp
 When
-ai_flags
+\fBai_flags\fR
 does not set the
 \fBAI_PASSIVE\fR
-bit, the returned socket address structure will be ready
-for use in a call to
-\fBconnect\fR(2)
-for a connection-oriented protocol or
+bit, the returned socket address structure will be ready for use in a call to
+\fBconnect\fR(2 )
+for a connection\-oriented protocol or
 \fBconnect\fR(2),
-\fBsendto\fR(2),
-or
-\fBsendmsg\fR(2)
-if a connectionless protocol was chosen.
-The IP address portion of the socket address structure will be
-set to the loopback address if
+\fBsendto\fR(2), or
+\fBsendmsg\fR(2 )
+if a connectionless protocol was chosen. The IP address portion of the socket address structure will be set to the loopback address if
 \fIhostname\fR
 is a
 \fBNULL\fR
 pointer and
 \fBAI_PASSIVE\fR
 is not set in
-ai_flags.
-
+\fBai_flags\fR.
+.sp
 If
-ai_flags
+\fBai_flags\fR
 is set to
 \fBAI_NUMERICHOST\fR
 it indicates that
 \fIhostname\fR
-should be treated as a numeric string defining an IPv4 or IPv6 address
-and no name resolution should be attempted.
+should be treated as a numeric string defining an IPv4 or IPv6 address and no name resolution should be attempted.
 .PP
-All other elements of the \fBstruct addrinfo\fR passed
-via \fIhints\fR must be zero.
+All other elements of the
+\fBstruct addrinfo\fR
+passed via
+\fIhints\fR
+must be zero.
 .PP
-A \fIhints\fR of \fBNULL\fR is treated as if
-the caller provided a \fBstruct addrinfo\fR initialized to zero
-with ai_familyset to
-PF_UNSPEC.
+A
+\fIhints\fR
+of
+\fBNULL\fR
+is treated as if the caller provided a
+\fBstruct addrinfo\fR
+initialized to zero with
+\fBai_family\fRset to
+\fBPF_UNSPEC\fR.
 .PP
 After a successful call to
 \fBlwres_getaddrinfo()\fR,
 \fI*res\fR
 is a pointer to a linked list of one or more
 \fBaddrinfo\fR
-structures.
-Each
+structures. Each
 \fBstruct addrinfo\fR
-in this list cn be processed by following
-the
-ai_next
+in this list cn be processed by following the
+\fBai_next\fR
 pointer, until a
 \fBNULL\fR
-pointer is encountered.
-The three members
-ai_family,
-ai_socktype,
-and
-ai_protocol
-in each
-returned
+pointer is encountered. The three members
+\fBai_family\fR,
+\fBai_socktype\fR, and
+\fBai_protocol\fR
+in each returned
 \fBaddrinfo\fR
 structure contain the corresponding arguments for a call to
-\fBsocket\fR(2).
-For each
+\fBsocket\fR(2). For each
 \fBaddrinfo\fR
 structure in the list, the
-ai_addr
-member points to a filled-in socket address structure of length
-ai_addrlen.
+\fBai_addr\fR
+member points to a filled\-in socket address structure of length
+\fBai_addrlen\fR.
 .PP
 All of the information returned by
 \fBlwres_getaddrinfo()\fR
-is dynamically allocated: the addrinfo structures, and the socket
-address structures and canonical host name strings pointed to by the
-addrinfostructures.
-Memory allocated for the dynamically allocated structures created by
-a successful call to
+is dynamically allocated: the addrinfo structures, and the socket address structures and canonical host name strings pointed to by the
+\fBaddrinfo\fRstructures. Memory allocated for the dynamically allocated structures created by a successful call to
 \fBlwres_getaddrinfo()\fR
 is released by
 \fBlwres_freeaddrinfo()\fR.
@@ -223,24 +203,22 @@ created by a call to
 .PP
 \fBlwres_getaddrinfo()\fR
 returns zero on success or one of the error codes listed in
-\fBgai_strerror\fR(3)
-if an error occurs.
-If both
+\fBgai_strerror\fR(3 )
+if an error occurs. If both
 \fIhostname\fR
 and
 \fIservname\fR
 are
-\fBNULL\fR
-\fBlwres_getaddrinfo()\fR
+\fBNULL\fR\fBlwres_getaddrinfo()\fR
 returns
-EAI_NONAME.
+\fBEAI_NONAME\fR.
 .SH "SEE ALSO"
 .PP
 \fBlwres\fR(3),
 \fBlwres_getaddrinfo\fR(3),
 \fBlwres_freeaddrinfo\fR(3),
 \fBlwres_gai_strerror\fR(3),
-\fBRFC2133\fR,
+\fBRFC2133\fR(),
 \fBgetservbyname\fR(3),
 \fBbind\fR(2),
 \fBconnect\fR(2),
diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook
index 2f2fc829f8fa..190721923b11 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_getaddrinfo.docbook,v 1.5.206.2 2004/03/06 08:15:39 marka Exp $ -->
+<!-- $Id: lwres_getaddrinfo.docbook,v 1.5.206.4 2005/05/12 21:36:14 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,20 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_getaddrinfo</refname>
 <refname>lwres_freeaddrinfo</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html
index b568e5915ade..bc84e74f5c33 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html
+++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html
@@ -1,97 +1,78 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_getaddrinfo.html,v 1.8.2.1.4.3 2004/08/22 23:39:03 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_getaddrinfo</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_getaddrinfo</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_getaddrinfo, lwres_freeaddrinfo&nbsp;--&nbsp;socket address structure to host and service name</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN12"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN13"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/netdb.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->int
-lwres_getaddrinfo</CODE
->(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_freeaddrinfo</CODE
->(struct addrinfo *ai);</CODE
-></P
-><P
-></P
-></DIV
-><P
->If the operating system does not provide a
-<SPAN
-CLASS="TYPE"
->struct addrinfo</SPAN
->,
+<!-- $Id: lwres_getaddrinfo.html,v 1.8.2.1.4.10 2005/10/13 02:33:56 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_getaddrinfo</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_getaddrinfo, lwres_freeaddrinfo &#8212; socket address structure to host and service name</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/netdb.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+int
+<b class="fsfunc">lwres_getaddrinfo</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0"><tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_freeaddrinfo</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+</div>
+<p>
+If the operating system does not provide a
+<span class="type">struct addrinfo</span>,
 the following structure is used:
 
-<PRE
-CLASS="PROGRAMLISTING"
->struct  addrinfo {
+</p>
+<pre class="programlisting">
+struct  addrinfo {
         int             ai_flags;       /* AI_PASSIVE, AI_CANONNAME */
         int             ai_family;      /* PF_xxx */
         int             ai_socktype;    /* SOCK_xxx */
@@ -100,594 +81,253 @@ CLASS="PROGRAMLISTING"
         char            *ai_canonname;  /* canonical name for hostname */
         struct sockaddr *ai_addr;       /* binary address */
         struct addrinfo *ai_next;       /* next structure in linked list */
-};</PRE
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN29"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->
+};
+</pre>
+<p>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525883"></a><h2>DESCRIPTION</h2>
+<p>
+<code class="function">lwres_getaddrinfo()</code>
 is used to get a list of IP addresses and port numbers for host
-<VAR
-CLASS="PARAMETER"
->hostname</VAR
->
+<em class="parameter"><code>hostname</code></em>
 and service
-<VAR
-CLASS="PARAMETER"
->servname</VAR
->.
+<em class="parameter"><code>servname</code></em>.
 
 The function is the lightweight resolver's implementation of
-<CODE
-CLASS="FUNCTION"
->getaddrinfo()</CODE
->
+<code class="function">getaddrinfo()</code>
 as defined in RFC2133.
-<VAR
-CLASS="PARAMETER"
->hostname</VAR
->
+<em class="parameter"><code>hostname</code></em>
 and
-<VAR
-CLASS="PARAMETER"
->servname</VAR
->
+<em class="parameter"><code>servname</code></em>
 are pointers to null-terminated
 strings or
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
->.
+<span class="type">NULL</span>.
 
-<VAR
-CLASS="PARAMETER"
->hostname</VAR
->
+<em class="parameter"><code>hostname</code></em>
 is either a host name or a numeric host address string: a dotted decimal
 IPv4 address or an IPv6 address.
-<VAR
-CLASS="PARAMETER"
->servname</VAR
->
+<em class="parameter"><code>servname</code></em>
 is either a decimal port number or a service name as listed in
-<TT
-CLASS="FILENAME"
->/etc/services</TT
->.</P
-><P
-><VAR
-CLASS="PARAMETER"
->hints</VAR
->
+<code class="filename">/etc/services</code>.
+</p>
+<p>
+<em class="parameter"><code>hints</code></em>
 is an optional pointer to a
-<SPAN
-CLASS="TYPE"
->struct addrinfo</SPAN
->.
+<span class="type">struct addrinfo</span>.
 This structure can be used to provide hints concerning the type of socket
 that the caller supports or wishes to use.
 The caller can supply the following structure elements in
-<VAR
-CLASS="PARAMETER"
->*hints</VAR
->:
+<em class="parameter"><code>*hints</code></em>:
 
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->ai_family</CODE
-></DT
-><DD
-><P
->The protocol family that should be used.
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">ai_family</code></span></dt>
+<dd><p>The protocol family that should be used.
 When
-<CODE
-CLASS="CONSTANT"
->ai_family</CODE
->
+<code class="constant">ai_family</code>
 is set to
-<SPAN
-CLASS="TYPE"
->PF_UNSPEC</SPAN
->,
+<span class="type">PF_UNSPEC</span>,
 it means the caller will accept any protocol family supported by the
-operating system.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ai_socktype</CODE
-></DT
-><DD
-><P
->denotes the type of socket &mdash;
-<SPAN
-CLASS="TYPE"
->SOCK_STREAM</SPAN
->,
-<SPAN
-CLASS="TYPE"
->SOCK_DGRAM</SPAN
->
+operating system.
+</p></dd>
+<dt><span class="term"><code class="constant">ai_socktype</code></span></dt>
+<dd><p>
+denotes the type of socket &#8212;
+<span class="type">SOCK_STREAM</span>,
+<span class="type">SOCK_DGRAM</span>
 or
-<SPAN
-CLASS="TYPE"
->SOCK_RAW</SPAN
->
-&mdash; that is wanted.
+<span class="type">SOCK_RAW</span>
+&#8212; that is wanted.
 When
-<CODE
-CLASS="CONSTANT"
->ai_socktype</CODE
->
-is zero the caller will accept any socket type.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ai_protocol</CODE
-></DT
-><DD
-><P
->indicates which transport protocol is wanted: IPPROTO_UDP or 
+<code class="constant">ai_socktype</code>
+is zero the caller will accept any socket type.
+</p></dd>
+<dt><span class="term"><code class="constant">ai_protocol</code></span></dt>
+<dd><p>
+indicates which transport protocol is wanted: IPPROTO_UDP or 
 IPPROTO_TCP.
 If
-<CODE
-CLASS="CONSTANT"
->ai_protocol</CODE
->
-is zero the caller will accept any protocol.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ai_flags</CODE
-></DT
-><DD
-><P
->Flag bits.
+<code class="constant">ai_protocol</code>
+is zero the caller will accept any protocol.
+</p></dd>
+<dt><span class="term"><code class="constant">ai_flags</code></span></dt>
+<dd>
+<p>
+Flag bits.
 If the
-<SPAN
-CLASS="TYPE"
->AI_CANONNAME</SPAN
->
+<span class="type">AI_CANONNAME</span>
 bit is set, a successful call to
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->
+<code class="function">lwres_getaddrinfo()</code>
 will return a null-terminated string containing the canonical name
 of the specified hostname in
-<CODE
-CLASS="CONSTANT"
->ai_canonname</CODE
->
+<code class="constant">ai_canonname</code>
 of the first
-<SPAN
-CLASS="TYPE"
->addrinfo</SPAN
->
+<span class="type">addrinfo</span>
 structure returned.
 Setting the
-<SPAN
-CLASS="TYPE"
->AI_PASSIVE</SPAN
->
+<span class="type">AI_PASSIVE</span>
 bit indicates that the returned socket address structure is intended
 for used in a call to
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->bind</SPAN
->(2)</SPAN
->.
+<span class="citerefentry"><span class="refentrytitle">bind</span>(2)</span>.
 
 In this case, if the hostname argument is a
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
->
+<span class="type">NULL</span>
 pointer, then the IP address portion of the socket
 address structure will be set to
-<SPAN
-CLASS="TYPE"
->INADDR_ANY</SPAN
->
+<span class="type">INADDR_ANY</span>
 for an IPv4 address or
-<SPAN
-CLASS="TYPE"
->IN6ADDR_ANY_INIT</SPAN
->
-for an IPv6 address.</P
-><P
->When
-<CODE
-CLASS="CONSTANT"
->ai_flags</CODE
->
+<span class="type">IN6ADDR_ANY_INIT</span>
+for an IPv6 address.
+</p>
+<p>
+When
+<code class="constant">ai_flags</code>
 does not set the
-<SPAN
-CLASS="TYPE"
->AI_PASSIVE</SPAN
->
+<span class="type">AI_PASSIVE</span>
 bit, the returned socket address structure will be ready
 for use in a call to
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->connect</SPAN
->(2)</SPAN
->
+<span class="citerefentry"><span class="refentrytitle">connect</span>(2
+)</span>
 for a connection-oriented protocol or
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->connect</SPAN
->(2)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">connect</span>(2)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->sendto</SPAN
->(2)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">sendto</span>(2)</span>,
 
 or
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->sendmsg</SPAN
->(2)</SPAN
->
+<span class="citerefentry"><span class="refentrytitle">sendmsg</span>(2
+)</span>
 if a connectionless protocol was chosen.
 The IP address portion of the socket address structure will be
 set to the loopback address if
-<VAR
-CLASS="PARAMETER"
->hostname</VAR
->
+<em class="parameter"><code>hostname</code></em>
 is a
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
->
+<span class="type">NULL</span>
 pointer and
-<SPAN
-CLASS="TYPE"
->AI_PASSIVE</SPAN
->
+<span class="type">AI_PASSIVE</span>
 is not set in
-<CODE
-CLASS="CONSTANT"
->ai_flags</CODE
->.</P
-><P
->If
-<CODE
-CLASS="CONSTANT"
->ai_flags</CODE
->
+<code class="constant">ai_flags</code>.
+</p>
+<p>
+If
+<code class="constant">ai_flags</code>
 is set to
-<SPAN
-CLASS="TYPE"
->AI_NUMERICHOST</SPAN
->
+<span class="type">AI_NUMERICHOST</span>
 it indicates that
-<VAR
-CLASS="PARAMETER"
->hostname</VAR
->
+<em class="parameter"><code>hostname</code></em>
 should be treated as a numeric string defining an IPv4 or IPv6 address
-and no name resolution should be attempted.</P
-></DD
-></DL
-></DIV
-></P
-><P
->All other elements of the <SPAN
-CLASS="TYPE"
->struct addrinfo</SPAN
-> passed
-via <VAR
-CLASS="PARAMETER"
->hints</VAR
-> must be zero.</P
-><P
->A <VAR
-CLASS="PARAMETER"
->hints</VAR
-> of <SPAN
-CLASS="TYPE"
->NULL</SPAN
-> is treated as if
-the caller provided a <SPAN
-CLASS="TYPE"
->struct addrinfo</SPAN
-> initialized to zero
-with <CODE
-CLASS="CONSTANT"
->ai_family</CODE
->set to
-<CODE
-CLASS="CONSTANT"
->PF_UNSPEC</CODE
->.</P
-><P
->After a successful call to
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->,
-<VAR
-CLASS="PARAMETER"
->*res</VAR
->
+and no name resolution should be attempted.
+</p>
+</dd>
+</dl></div>
+<p>
+</p>
+<p>
+All other elements of the <span class="type">struct addrinfo</span> passed
+via <em class="parameter"><code>hints</code></em> must be zero.
+</p>
+<p>
+A <em class="parameter"><code>hints</code></em> of <span class="type">NULL</span> is treated as if
+the caller provided a <span class="type">struct addrinfo</span> initialized to zero
+with <code class="constant">ai_family</code>set to
+<code class="constant">PF_UNSPEC</code>.
+</p>
+<p>
+After a successful call to
+<code class="function">lwres_getaddrinfo()</code>,
+<em class="parameter"><code>*res</code></em>
 is a pointer to a linked list of one or more
-<SPAN
-CLASS="TYPE"
->addrinfo</SPAN
->
+<span class="type">addrinfo</span>
 structures.
 Each
-<SPAN
-CLASS="TYPE"
->struct addrinfo</SPAN
->
+<span class="type">struct addrinfo</span>
 in this list cn be processed by following
 the
-<CODE
-CLASS="CONSTANT"
->ai_next</CODE
->
+<code class="constant">ai_next</code>
 pointer, until a
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
->
+<span class="type">NULL</span>
 pointer is encountered.
 The three members
-<CODE
-CLASS="CONSTANT"
->ai_family</CODE
->,
-<CODE
-CLASS="CONSTANT"
->ai_socktype</CODE
->,
+<code class="constant">ai_family</code>,
+<code class="constant">ai_socktype</code>,
 and
-<CODE
-CLASS="CONSTANT"
->ai_protocol</CODE
->
+<code class="constant">ai_protocol</code>
 in each
 returned
-<SPAN
-CLASS="TYPE"
->addrinfo</SPAN
->
+<span class="type">addrinfo</span>
 structure contain the corresponding arguments for a call to
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->socket</SPAN
->(2)</SPAN
->.
+<span class="citerefentry"><span class="refentrytitle">socket</span>(2)</span>.
 For each
-<SPAN
-CLASS="TYPE"
->addrinfo</SPAN
->
+<span class="type">addrinfo</span>
 structure in the list, the
-<CODE
-CLASS="CONSTANT"
->ai_addr</CODE
->
+<code class="constant">ai_addr</code>
 member points to a filled-in socket address structure of length
-<CODE
-CLASS="CONSTANT"
->ai_addrlen</CODE
->.</P
-><P
->All of the information returned by
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->
+<code class="constant">ai_addrlen</code>.
+</p>
+<p>
+All of the information returned by
+<code class="function">lwres_getaddrinfo()</code>
 is dynamically allocated: the addrinfo structures, and the socket
 address structures and canonical host name strings pointed to by the
-<CODE
-CLASS="CONSTANT"
->addrinfo</CODE
->structures.
+<code class="constant">addrinfo</code>structures.
 Memory allocated for the dynamically allocated structures created by
 a successful call to
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->
+<code class="function">lwres_getaddrinfo()</code>
 is released by
-<CODE
-CLASS="FUNCTION"
->lwres_freeaddrinfo()</CODE
->.
-<VAR
-CLASS="PARAMETER"
->ai</VAR
->
+<code class="function">lwres_freeaddrinfo()</code>.
+<em class="parameter"><code>ai</code></em>
 is a pointer to a
-<SPAN
-CLASS="TYPE"
->struct addrinfo</SPAN
->
+<span class="type">struct addrinfo</span>
 created by a call to
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN142"
-></A
-><H2
->RETURN VALUES</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->
+<code class="function">lwres_getaddrinfo()</code>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526309"></a><h2>RETURN VALUES</h2>
+<p>
+<code class="function">lwres_getaddrinfo()</code>
 returns zero on success or one of the error codes listed in
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->gai_strerror</SPAN
->(3)</SPAN
->
+<span class="citerefentry"><span class="refentrytitle">gai_strerror</span>(3
+)</span>
 if an error occurs.
 If both
-<VAR
-CLASS="PARAMETER"
->hostname</VAR
->
+<em class="parameter"><code>hostname</code></em>
 and
-<VAR
-CLASS="PARAMETER"
->servname</VAR
->
+<em class="parameter"><code>servname</code></em>
 are
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
->
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrinfo()</CODE
->
+<span class="type">NULL</span>
+<code class="function">lwres_getaddrinfo()</code>
 returns
-<SPAN
-CLASS="ERRORCODE"
->EAI_NONAME</SPAN
->.&#13;</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN154"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres</SPAN
->(3)</SPAN
->,
+<span class="errorcode">EAI_NONAME</span>.
+
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526347"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getaddrinfo</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_getaddrinfo</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_freeaddrinfo</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_freeaddrinfo</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_gai_strerror</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_gai_strerror</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2133</SPAN
-></SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">RFC2133</span></span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->getservbyname</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">getservbyname</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->bind</SPAN
->(2)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">bind</span>(2)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->connect</SPAN
->(2)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">connect</span>(2)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->sendto</SPAN
->(2)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">sendto</span>(2)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->sendmsg</SPAN
->(2)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">sendmsg</span>(2)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->socket</SPAN
->(2)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+<span class="citerefentry"><span class="refentrytitle">socket</span>(2)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.3 b/contrib/bind9/lib/lwres/man/lwres_gethostent.3
index 5a4234797d08..99dc5338e58a 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gethostent.3
+++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.3
@@ -1,89 +1,64 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gethostent.3,v 1.16.2.1.8.1 2004/03/06 07:41:43 marka Exp $
+.\" $Id: lwres_gethostent.3,v 1.16.2.1.8.5 2005/10/13 02:33:53 marka Exp $
 .\"
-.TH "LWRES_GETHOSTENT" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_GETHOSTENT" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_gethostbyname, lwres_gethostbyname2, lwres_gethostbyaddr, lwres_gethostent, lwres_sethostent, lwres_endhostent, lwres_gethostbyname_r, lwres_gethostbyaddr_r, lwres_gethostent_r, lwres_sethostent_r, lwres_endhostent_r \- lightweight resolver get network host entry
-.SH SYNOPSIS
-\fB#include <lwres/netdb.h>
-.sp
-.na
-struct hostent *
-lwres_gethostbyname(const char *name);
-.ad
-.sp
-.na
-struct hostent *
-lwres_gethostbyname2(const char *name, int af);
-.ad
-.sp
-.na
-struct hostent *
-lwres_gethostbyaddr(const char *addr, int len, int type);
-.ad
-.sp
-.na
-struct hostent *
-lwres_gethostent(void);
-.ad
-.sp
-.na
-void
-lwres_sethostent(int stayopen);
-.ad
-.sp
-.na
-void
-lwres_endhostent(void);
-.ad
-.sp
-.na
-struct hostent *
-lwres_gethostbyname_r(const char *name, struct hostent *resbuf, char *buf, int buflen, int *error);
-.ad
-.sp
-.na
-struct hostent *
-lwres_gethostbyaddr_r(const char *addr, int len, int type, struct hostent *resbuf, char *buf, int buflen, int *error);
-.ad
-.sp
-.na
-struct hostent *
-lwres_gethostent_r(struct hostent *resbuf, char *buf, int buflen, int *error);
-.ad
-.sp
-.na
-void
-lwres_sethostent_r(int stayopen);
-.ad
-.sp
-.na
-void
-lwres_endhostent_r(void);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/netdb.h>
+.fi
+.HP 37
+\fBstruct\ hostent\ *\ \fBlwres_gethostbyname\fR\fR\fB(\fR\fBconst\ char\ *name\fR\fB);\fR
+.HP 38
+\fBstruct\ hostent\ *\ \fBlwres_gethostbyname2\fR\fR\fB(\fR\fBconst\ char\ *name\fR\fB, \fR\fBint\ af\fR\fB);\fR
+.HP 37
+\fBstruct\ hostent\ *\ \fBlwres_gethostbyaddr\fR\fR\fB(\fR\fBconst\ char\ *addr\fR\fB, \fR\fBint\ len\fR\fB, \fR\fBint\ type\fR\fB);\fR
+.HP 34
+\fBstruct\ hostent\ *\ \fBlwres_gethostent\fR\fR\fB(\fR\fBvoid\fR\fB);\fR
+.HP 22
+\fBvoid\ \fBlwres_sethostent\fR\fR\fB(\fR\fBint\ stayopen\fR\fB);\fR
+.HP 22
+\fBvoid\ \fBlwres_endhostent\fR\fR\fB(\fR\fBvoid\fR\fB);\fR
+.HP 39
+\fBstruct\ hostent\ *\ \fBlwres_gethostbyname_r\fR\fR\fB(\fR\fBconst\ char\ *name\fR\fB, \fR\fBstruct\ hostent\ *resbuf\fR\fB, \fR\fBchar\ *buf\fR\fB, \fR\fBint\ buflen\fR\fB, \fR\fBint\ *error\fR\fB);\fR
+.HP 39
+\fBstruct\ hostent\ *\ \fBlwres_gethostbyaddr_r\fR\fR\fB(\fR\fBconst\ char\ *addr\fR\fB, \fR\fBint\ len\fR\fB, \fR\fBint\ type\fR\fB, \fR\fBstruct\ hostent\ *resbuf\fR\fB, \fR\fBchar\ *buf\fR\fB, \fR\fBint\ buflen\fR\fB, \fR\fBint\ *error\fR\fB);\fR
+.HP 36
+\fBstruct\ hostent\ *\ \fBlwres_gethostent_r\fR\fR\fB(\fR\fBstruct\ hostent\ *resbuf\fR\fB, \fR\fBchar\ *buf\fR\fB, \fR\fBint\ buflen\fR\fB, \fR\fBint\ *error\fR\fB);\fR
+.HP 24
+\fBvoid\ \fBlwres_sethostent_r\fR\fR\fB(\fR\fBint\ stayopen\fR\fB);\fR
+.HP 24
+\fBvoid\ \fBlwres_endhostent_r\fR\fR\fB(\fR\fBvoid\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-These functions provide hostname-to-address and
-address-to-hostname lookups by means of the lightweight resolver.
-They are similar to the standard
-\fBgethostent\fR(3)
-functions provided by most operating systems.
-They use a
+These functions provide hostname\-to\-address and address\-to\-hostname lookups by means of the lightweight resolver. They are similar to the standard
+\fBgethostent\fR(3 )
+functions provided by most operating systems. They use a
 \fBstruct hostent\fR
 which is usually defined in
 \fI<namedb.h>\fR.
@@ -97,8 +72,8 @@ struct  hostent {
         char    **h_addr_list;  /* list of addresses from name server */
 };
 #define h_addr  h_addr_list[0]  /* address, for backward compatibility */
-.sp
 .fi
+.sp
 .PP
 The members of this structure are:
 .TP
@@ -106,7 +81,7 @@ The members of this structure are:
 The official (canonical) name of the host.
 .TP
 \fBh_aliases\fR
-A NULL-terminated array of alternate names (nicknames) for the host.
+A NULL\-terminated array of alternate names (nicknames) for the host.
 .TP
 \fBh_addrtype\fR
 The type of address being returned \(em
@@ -118,14 +93,14 @@ or
 The length of the address in bytes.
 .TP
 \fBh_addr_list\fR
-A \fBNULL\fR
-terminated array of network addresses for the host.
-Host addresses are returned in network byte order.
+A
+\fBNULL\fR
+terminated array of network addresses for the host. Host addresses are returned in network byte order.
 .PP
 For backward compatibility with very old software,
-h_addr
+\fBh_addr\fR
 is the first address in
-h_addr_list.
+\fBh_addr_list.\fR
 .PP
 \fBlwres_gethostent()\fR,
 \fBlwres_sethostent()\fR,
@@ -134,72 +109,109 @@ h_addr_list.
 \fBlwres_sethostent_r()\fR
 and
 \fBlwres_endhostent_r()\fR
-provide iteration over the known host entries on systems that
-provide such functionality through facilities like
+provide iteration over the known host entries on systems that provide such functionality through facilities like
 \fI/etc/hosts\fR
-or NIS. The lightweight resolver does not currently implement
-these functions; it only provides them as stub functions that always
-return failure.
+or NIS. The lightweight resolver does not currently implement these functions; it only provides them as stub functions that always return failure.
 .PP
-\fBlwres_gethostbyname()\fR and
-\fBlwres_gethostbyname2()\fR look up the hostname
+\fBlwres_gethostbyname()\fR
+and
+\fBlwres_gethostbyname2()\fR
+look up the hostname
 \fIname\fR.
-\fBlwres_gethostbyname()\fR always looks for an IPv4
-address while \fBlwres_gethostbyname2()\fR looks for an
-address of protocol family \fIaf\fR: either
-\fBPF_INET\fR or \fBPF_INET6\fR \(em IPv4 or IPV6
-addresses respectively. Successful calls of the functions return a
+\fBlwres_gethostbyname()\fR
+always looks for an IPv4 address while
+\fBlwres_gethostbyname2()\fR
+looks for an address of protocol family
+\fIaf\fR: either
+\fBPF_INET\fR
+or
+\fBPF_INET6\fR
+\(em IPv4 or IPV6 addresses respectively. Successful calls of the functions return a
 \fBstruct hostent\fRfor the name that was looked up.
-\fBNULL\fR is returned if the lookups by
-\fBlwres_gethostbyname()\fR or
-\fBlwres_gethostbyname2()\fR fail.
+\fBNULL\fR
+is returned if the lookups by
+\fBlwres_gethostbyname()\fR
+or
+\fBlwres_gethostbyname2()\fR
+fail.
 .PP
 Reverse lookups of addresses are performed by
 \fBlwres_gethostbyaddr()\fR.
-\fIaddr\fR is an address of length
-\fIlen\fR bytes and protocol family
-\fItype\fR \(em \fBPF_INET\fR or
+\fIaddr\fR
+is an address of length
+\fIlen\fR
+bytes and protocol family
+\fItype\fR
+\(em
+\fBPF_INET\fR
+or
 \fBPF_INET6\fR.
-\fBlwres_gethostbyname_r()\fR is a thread-safe function
-for forward lookups. If an error occurs, an error code is returned in
+\fBlwres_gethostbyname_r()\fR
+is a thread\-safe function for forward lookups. If an error occurs, an error code is returned in
 \fI*error\fR.
-\fIresbuf\fR is a pointer to a \fBstruct
-hostent\fR which is initialised by a successful call to
-\fBlwres_gethostbyname_r()\fR .
-\fIbuf\fR is a buffer of length
-\fIlen\fR bytes which is used to store the
-h_name, h_aliases, and
-h_addr_list elements of the \fBstruct
-hostent\fR returned in \fIresbuf\fR.
-Successful calls to \fBlwres_gethostbyname_r()\fR
-return \fIresbuf\fR,
-which is a pointer to the \fBstruct hostent\fR it created.
+\fIresbuf\fR
+is a pointer to a
+\fBstruct hostent\fR
+which is initialised by a successful call to
+\fBlwres_gethostbyname_r()\fR
+.
+\fIbuf\fR
+is a buffer of length
+\fIlen\fR
+bytes which is used to store the
+\fBh_name\fR,
+\fBh_aliases\fR, and
+\fBh_addr_list\fR
+elements of the
+\fBstruct hostent\fR
+returned in
+\fIresbuf\fR. Successful calls to
+\fBlwres_gethostbyname_r()\fR
+return
+\fIresbuf\fR, which is a pointer to the
+\fBstruct hostent\fR
+it created.
 .PP
-\fBlwres_gethostbyaddr_r()\fR is a thread-safe function
-that performs a reverse lookup of address \fIaddr\fR
-which is \fIlen\fR bytes long and is of protocol
-family \fItype\fR \(em \fBPF_INET\fR or
-\fBPF_INET6\fR. If an error occurs, the error code is returned
-in \fI*error\fR. The other function parameters are
-identical to those in \fBlwres_gethostbyname_r()\fR.
-\fIresbuf\fR is a pointer to a \fBstruct
-hostent\fR which is initialised by a successful call to
+\fBlwres_gethostbyaddr_r()\fR
+is a thread\-safe function that performs a reverse lookup of address
+\fIaddr\fR
+which is
+\fIlen\fR
+bytes long and is of protocol family
+\fItype\fR
+\(em
+\fBPF_INET\fR
+or
+\fBPF_INET6\fR. If an error occurs, the error code is returned in
+\fI*error\fR. The other function parameters are identical to those in
+\fBlwres_gethostbyname_r()\fR.
+\fIresbuf\fR
+is a pointer to a
+\fBstruct hostent\fR
+which is initialised by a successful call to
 \fBlwres_gethostbyaddr_r()\fR.
-\fIbuf\fR is a buffer of length
-\fIlen\fR bytes which is used to store the
-h_name, h_aliases, and
-h_addr_list elements of the \fBstruct
-hostent\fR returned in \fIresbuf\fR. Successful
-calls to \fBlwres_gethostbyaddr_r()\fR return
+\fIbuf\fR
+is a buffer of length
+\fIlen\fR
+bytes which is used to store the
+\fBh_name\fR,
+\fBh_aliases\fR, and
+\fBh_addr_list\fR
+elements of the
+\fBstruct hostent\fR
+returned in
+\fIresbuf\fR. Successful calls to
+\fBlwres_gethostbyaddr_r()\fR
+return
 \fIresbuf\fR, which is a pointer to the
-\fBstruct hostent()\fR it created.
+\fBstruct hostent()\fR
+it created.
 .SH "RETURN VALUES"
 .PP
 The functions
 \fBlwres_gethostbyname()\fR,
 \fBlwres_gethostbyname2()\fR,
-\fBlwres_gethostbyaddr()\fR,
-and
+\fBlwres_gethostbyaddr()\fR, and
 \fBlwres_gethostent()\fR
 return NULL to indicate an error. In this case the global variable
 \fBlwres_h_errno\fR
@@ -210,20 +222,15 @@ will contain one of the following error codes defined in
 The host or address was not found.
 .TP
 \fBTRY_AGAIN\fR
-A recoverable error occurred, e.g., a timeout.
-Retrying the lookup may succeed.
+A recoverable error occurred, e.g., a timeout. Retrying the lookup may succeed.
 .TP
 \fBNO_RECOVERY\fR
-A non-recoverable error occurred.
+A non\-recoverable error occurred.
 .TP
 \fBNO_DATA\fR
-The name exists, but has no address information
-associated with it (or vice versa in the case
-of a reverse lookup). The code NO_ADDRESS
-is accepted as a synonym for NO_DATA for backwards
-compatibility.
+The name exists, but has no address information associated with it (or vice versa in the case of a reverse lookup). The code NO_ADDRESS is accepted as a synonym for NO_DATA for backwards compatibility.
 .PP
-\fBlwres_hstrerror\fR(3)
+\fBlwres_hstrerror\fR(3 )
 translates these error codes to suitable error messages.
 .PP
 \fBlwres_gethostent()\fR
@@ -232,23 +239,37 @@ and
 always return
 \fBNULL\fR.
 .PP
-Successful calls to \fBlwres_gethostbyname_r()\fR and
-\fBlwres_gethostbyaddr_r()\fR return
-\fIresbuf\fR, a pointer to the \fBstruct
-hostent\fR that was initialised by these functions. They return
-\fBNULL\fR if the lookups fail or if \fIbuf\fR
-was too small to hold the list of addresses and names referenced by
-the h_name, h_aliases, and
-h_addr_list elements of the \fBstruct
-hostent\fR. If \fIbuf\fR was too small, both
-\fBlwres_gethostbyname_r()\fR and
-\fBlwres_gethostbyaddr_r()\fR set the global variable
-\fBerrno\fR to ERANGE.
+Successful calls to
+\fBlwres_gethostbyname_r()\fR
+and
+\fBlwres_gethostbyaddr_r()\fR
+return
+\fIresbuf\fR, a pointer to the
+\fBstruct hostent\fR
+that was initialised by these functions. They return
+\fBNULL\fR
+if the lookups fail or if
+\fIbuf\fR
+was too small to hold the list of addresses and names referenced by the
+\fBh_name\fR,
+\fBh_aliases\fR, and
+\fBh_addr_list\fR
+elements of the
+\fBstruct hostent\fR. If
+\fIbuf\fR
+was too small, both
+\fBlwres_gethostbyname_r()\fR
+and
+\fBlwres_gethostbyaddr_r()\fR
+set the global variable
+\fBerrno\fR
+to
+\fBERANGE\fR.
 .SH "SEE ALSO"
 .PP
 \fBgethostent\fR(3),
 \fBlwres_getipnode\fR(3),
-\fBlwres_hstrerror\fR(3)
+\fBlwres_hstrerror\fR(3 )
 .SH "BUGS"
 .PP
 \fBlwres_gethostbyname()\fR,
@@ -256,17 +277,12 @@ hostent\fR. If \fIbuf\fR was too small, both
 \fBlwres_gethostbyaddr()\fR
 and
 \fBlwres_endhostent()\fR
-are not thread safe; they return pointers to static data and 
-provide error codes through a global variable.
-Thread-safe versions for name and address lookup are provided by
-\fBlwres_gethostbyname_r()\fR,
-and
+are not thread safe; they return pointers to static data and provide error codes through a global variable. Thread\-safe versions for name and address lookup are provided by
+\fBlwres_gethostbyname_r()\fR, and
 \fBlwres_gethostbyaddr_r()\fR
 respectively.
 .PP
-The resolver daemon does not currently support any non-DNS
-name services such as 
+The resolver daemon does not currently support any non\-DNS name services such as
 \fI/etc/hosts\fR
 or
-\fBNIS\fR,
-consequently the above functions don't, either.
+\fBNIS\fR, consequently the above functions don't, either.
diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook b/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook
index 10324c31b94d..9f92d3b3134c 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook
@@ -1,6 +1,8 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_gethostent.docbook,v 1.5.206.1 2004/03/06 08:15:39 marka Exp $ -->
+<!-- $Id: lwres_gethostent.docbook,v 1.5.206.3 2005/05/13 01:22:36 marka Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,18 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_gethostbyname</refname>
 <refname>lwres_gethostbyname2</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.html b/contrib/bind9/lib/lwres/man/lwres_gethostent.html
index 00b285db2061..263f9932362c 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gethostent.html
+++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.html
@@ -1,784 +1,430 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_gethostent.html,v 1.8.2.1.4.2 2004/08/22 23:39:04 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_gethostent</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_gethostent</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_gethostbyname, lwres_gethostbyname2, lwres_gethostbyaddr, lwres_gethostent, lwres_sethostent, lwres_endhostent, lwres_gethostbyname_r, lwres_gethostbyaddr_r, lwres_gethostent_r, lwres_sethostent_r, lwres_endhostent_r&nbsp;--&nbsp;lightweight resolver get network host entry</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN21"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN22"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/netdb.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent *
-lwres_gethostbyname</CODE
->(const char *name);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent *
-lwres_gethostbyname2</CODE
->(const char *name, int af);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent *
-lwres_gethostbyaddr</CODE
->(const char *addr, int len, int type);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent *
-lwres_gethostent</CODE
->(void);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_sethostent</CODE
->(int stayopen);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_endhostent</CODE
->(void);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent *
-lwres_gethostbyname_r</CODE
->(const char *name, struct hostent *resbuf, char *buf, int buflen, int *error);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent  *
-lwres_gethostbyaddr_r</CODE
->(const char *addr, int len, int type, struct hostent *resbuf, char *buf, int buflen, int *error);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent  *
-lwres_gethostent_r</CODE
->(struct hostent *resbuf, char *buf, int buflen, int *error);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_sethostent_r</CODE
->(int stayopen);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_endhostent_r</CODE
->(void);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN84"
-></A
-><H2
->DESCRIPTION</H2
-><P
->These functions provide hostname-to-address and
+<!-- $Id: lwres_gethostent.html,v 1.8.2.1.4.8 2005/10/13 02:33:56 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_gethostent</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_gethostbyname, lwres_gethostbyname2, lwres_gethostbyaddr, lwres_gethostent, lwres_sethostent, lwres_endhostent, lwres_gethostbyname_r, lwres_gethostbyaddr_r, lwres_gethostent_r, lwres_sethostent_r, lwres_endhostent_r &#8212; lightweight resolver get network host entry</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/netdb.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em"><tr>
+<td><code class="funcdef">
+struct hostent *
+<b class="fsfunc">lwres_gethostbyname</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+struct hostent *
+<b class="fsfunc">lwres_gethostbyname2</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+struct hostent *
+<b class="fsfunc">lwres_gethostbyaddr</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<p><code class="funcdef">
+struct hostent *
+<b class="fsfunc">lwres_gethostent</b>(</code>void<code>)</code>;</p>
+<p><code class="funcdef">
+void
+<b class="fsfunc">lwres_sethostent</b>(</code>int stayopen<code>)</code>;</p>
+<p><code class="funcdef">
+void
+<b class="fsfunc">lwres_endhostent</b>(</code>void<code>)</code>;</p>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+struct hostent *
+<b class="fsfunc">lwres_gethostbyname_r</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+struct hostent  *
+<b class="fsfunc">lwres_gethostbyaddr_r</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+struct hostent  *
+<b class="fsfunc">lwres_gethostent_r</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<p><code class="funcdef">
+void
+<b class="fsfunc">lwres_sethostent_r</b>(</code>int stayopen<code>)</code>;</p>
+<p><code class="funcdef">
+void
+<b class="fsfunc">lwres_endhostent_r</b>(</code>void<code>)</code>;</p>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526041"></a><h2>DESCRIPTION</h2>
+<p>
+These functions provide hostname-to-address and
 address-to-hostname lookups by means of the lightweight resolver.
 They are similar to the standard
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->gethostent</SPAN
->(3)</SPAN
->
+<span class="citerefentry"><span class="refentrytitle">gethostent</span>(3
+)</span>
 functions provided by most operating systems.
 They use a
-<SPAN
-CLASS="TYPE"
->struct hostent</SPAN
->
+<span class="type">struct hostent</span>
 which is usually defined in
-<TT
-CLASS="FILENAME"
->&lt;namedb.h&gt;</TT
->.
+<code class="filename">&lt;namedb.h&gt;</code>.
 
-<PRE
-CLASS="PROGRAMLISTING"
->struct  hostent {
+</p>
+<pre class="programlisting">
+struct  hostent {
         char    *h_name;        /* official name of host */
         char    **h_aliases;    /* alias list */
         int     h_addrtype;     /* host address type */
         int     h_length;       /* length of address */
         char    **h_addr_list;  /* list of addresses from name server */
 };
-#define h_addr  h_addr_list[0]  /* address, for backward compatibility */</PRE
-></P
-><P
->The members of this structure are:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->h_name</CODE
-></DT
-><DD
-><P
->The official (canonical) name of the host.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->h_aliases</CODE
-></DT
-><DD
-><P
->A NULL-terminated array of alternate names (nicknames) for the host.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->h_addrtype</CODE
-></DT
-><DD
-><P
->The type of address being returned &mdash;
-<SPAN
-CLASS="TYPE"
->PF_INET</SPAN
->
+#define h_addr  h_addr_list[0]  /* address, for backward compatibility */
+</pre>
+<p>
+</p>
+<p>
+The members of this structure are:
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">h_name</code></span></dt>
+<dd><p>
+The official (canonical) name of the host.
+</p></dd>
+<dt><span class="term"><code class="constant">h_aliases</code></span></dt>
+<dd><p>
+A NULL-terminated array of alternate names (nicknames) for the host.
+</p></dd>
+<dt><span class="term"><code class="constant">h_addrtype</code></span></dt>
+<dd><p>
+The type of address being returned &#8212;
+<span class="type">PF_INET</span>
 or
-<SPAN
-CLASS="TYPE"
->PF_INET6</SPAN
->.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->h_length</CODE
-></DT
-><DD
-><P
->The length of the address in bytes.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->h_addr_list</CODE
-></DT
-><DD
-><P
->A <SPAN
-CLASS="TYPE"
->NULL</SPAN
->
+<span class="type">PF_INET6</span>.
+</p></dd>
+<dt><span class="term"><code class="constant">h_length</code></span></dt>
+<dd><p>
+The length of the address in bytes.
+</p></dd>
+<dt><span class="term"><code class="constant">h_addr_list</code></span></dt>
+<dd><p>
+A <span class="type">NULL</span>
 terminated array of network addresses for the host.
-Host addresses are returned in network byte order.</P
-></DD
-></DL
-></DIV
-></P
-><P
->For backward compatibility with very old software,
-<CODE
-CLASS="CONSTANT"
->h_addr</CODE
->
+Host addresses are returned in network byte order.
+</p></dd>
+</dl></div>
+<p>
+</p>
+<p>
+For backward compatibility with very old software,
+<code class="constant">h_addr</code>
 is the first address in
-<CODE
-CLASS="CONSTANT"
->h_addr_list.</CODE
-></P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gethostent()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_sethostent()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_endhostent()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_gethostent_r()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_sethostent_r()</CODE
->
+<code class="constant">h_addr_list.</code>
+</p>
+<p>
+<code class="function">lwres_gethostent()</code>,
+<code class="function">lwres_sethostent()</code>,
+<code class="function">lwres_endhostent()</code>,
+<code class="function">lwres_gethostent_r()</code>,
+<code class="function">lwres_sethostent_r()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_endhostent_r()</CODE
->
+<code class="function">lwres_endhostent_r()</code>
 provide iteration over the known host entries on systems that
 provide such functionality through facilities like
-<TT
-CLASS="FILENAME"
->/etc/hosts</TT
->
+<code class="filename">/etc/hosts</code>
 or NIS.  The lightweight resolver does not currently implement
 these functions; it only provides them as stub functions that always
-return failure.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gethostbyname()</CODE
-> and
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname2()</CODE
-> look up the hostname
-<VAR
-CLASS="PARAMETER"
->name</VAR
->.
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname()</CODE
-> always looks for an IPv4
-address while <CODE
-CLASS="FUNCTION"
->lwres_gethostbyname2()</CODE
-> looks for an
-address of protocol family <VAR
-CLASS="PARAMETER"
->af</VAR
->: either
-<SPAN
-CLASS="TYPE"
->PF_INET</SPAN
-> or <SPAN
-CLASS="TYPE"
->PF_INET6</SPAN
-> &mdash; IPv4 or IPV6
+return failure.
+</p>
+<p>
+<code class="function">lwres_gethostbyname()</code> and
+<code class="function">lwres_gethostbyname2()</code> look up the hostname
+<em class="parameter"><code>name</code></em>.
+<code class="function">lwres_gethostbyname()</code> always looks for an IPv4
+address while <code class="function">lwres_gethostbyname2()</code> looks for an
+address of protocol family <em class="parameter"><code>af</code></em>: either
+<span class="type">PF_INET</span> or <span class="type">PF_INET6</span> &#8212; IPv4 or IPV6
 addresses respectively.  Successful calls of the functions return a
-<SPAN
-CLASS="TYPE"
->struct hostent</SPAN
->for the name that was looked up.
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
-> is returned if the lookups by
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname()</CODE
-> or
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname2()</CODE
-> fail.</P
-><P
->Reverse lookups of addresses are performed by
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr()</CODE
->.
-<VAR
-CLASS="PARAMETER"
->addr</VAR
-> is an address of length
-<VAR
-CLASS="PARAMETER"
->len</VAR
-> bytes and protocol family
-<VAR
-CLASS="PARAMETER"
->type</VAR
-> &mdash; <SPAN
-CLASS="TYPE"
->PF_INET</SPAN
-> or
-<SPAN
-CLASS="TYPE"
->PF_INET6</SPAN
->.
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname_r()</CODE
-> is a thread-safe function
+<span class="type">struct hostent</span>for the name that was looked up.
+<span class="type">NULL</span> is returned if the lookups by
+<code class="function">lwres_gethostbyname()</code> or
+<code class="function">lwres_gethostbyname2()</code> fail.
+</p>
+<p>
+Reverse lookups of addresses are performed by
+<code class="function">lwres_gethostbyaddr()</code>.
+<em class="parameter"><code>addr</code></em> is an address of length
+<em class="parameter"><code>len</code></em> bytes and protocol family
+<em class="parameter"><code>type</code></em> &#8212; <span class="type">PF_INET</span> or
+<span class="type">PF_INET6</span>.
+<code class="function">lwres_gethostbyname_r()</code> is a thread-safe function
 for forward lookups.  If an error occurs, an error code is returned in
-<VAR
-CLASS="PARAMETER"
->*error</VAR
->.
-<VAR
-CLASS="PARAMETER"
->resbuf</VAR
-> is a pointer to a <SPAN
-CLASS="TYPE"
->struct
-hostent</SPAN
-> which is initialised by a successful call to
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname_r()</CODE
-> .
-<VAR
-CLASS="PARAMETER"
->buf</VAR
-> is a buffer of length
-<VAR
-CLASS="PARAMETER"
->len</VAR
-> bytes which is used to store the
-<CODE
-CLASS="CONSTANT"
->h_name</CODE
->, <CODE
-CLASS="CONSTANT"
->h_aliases</CODE
->, and
-<CODE
-CLASS="CONSTANT"
->h_addr_list</CODE
-> elements of the <SPAN
-CLASS="TYPE"
->struct
-hostent</SPAN
-> returned in <VAR
-CLASS="PARAMETER"
->resbuf</VAR
->.
-Successful calls to <CODE
-CLASS="FUNCTION"
->lwres_gethostbyname_r()</CODE
->
-return <VAR
-CLASS="PARAMETER"
->resbuf</VAR
->,
-which is a pointer to the <SPAN
-CLASS="TYPE"
->struct hostent</SPAN
-> it created.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr_r()</CODE
-> is a thread-safe function
-that performs a reverse lookup of address <VAR
-CLASS="PARAMETER"
->addr</VAR
->
-which is <VAR
-CLASS="PARAMETER"
->len</VAR
-> bytes long and is of protocol
-family <VAR
-CLASS="PARAMETER"
->type</VAR
-> &mdash; <SPAN
-CLASS="TYPE"
->PF_INET</SPAN
-> or
-<SPAN
-CLASS="TYPE"
->PF_INET6</SPAN
->.  If an error occurs, the error code is returned
-in <VAR
-CLASS="PARAMETER"
->*error</VAR
->.  The other function parameters are
-identical to those in <CODE
-CLASS="FUNCTION"
->lwres_gethostbyname_r()</CODE
->.
-<VAR
-CLASS="PARAMETER"
->resbuf</VAR
-> is a pointer to a <SPAN
-CLASS="TYPE"
->struct
-hostent</SPAN
-> which is initialised by a successful call to
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr_r()</CODE
->.
-<VAR
-CLASS="PARAMETER"
->buf</VAR
-> is a buffer of length
-<VAR
-CLASS="PARAMETER"
->len</VAR
-> bytes which is used to store the
-<CODE
-CLASS="CONSTANT"
->h_name</CODE
->, <CODE
-CLASS="CONSTANT"
->h_aliases</CODE
->, and
-<CODE
-CLASS="CONSTANT"
->h_addr_list</CODE
-> elements of the <SPAN
-CLASS="TYPE"
->struct
-hostent</SPAN
-> returned in <VAR
-CLASS="PARAMETER"
->resbuf</VAR
->.  Successful
-calls to <CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr_r()</CODE
-> return
-<VAR
-CLASS="PARAMETER"
->resbuf</VAR
->, which is a pointer to the
-<CODE
-CLASS="FUNCTION"
->struct hostent()</CODE
-> it created.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN191"
-></A
-><H2
->RETURN VALUES</H2
-><P
->The functions
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname2()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr()</CODE
->,
+<em class="parameter"><code>*error</code></em>.
+<em class="parameter"><code>resbuf</code></em> is a pointer to a <span class="type">struct
+hostent</span> which is initialised by a successful call to
+<code class="function">lwres_gethostbyname_r()</code> .
+<em class="parameter"><code>buf</code></em> is a buffer of length
+<em class="parameter"><code>len</code></em> bytes which is used to store the
+<code class="constant">h_name</code>, <code class="constant">h_aliases</code>, and
+<code class="constant">h_addr_list</code> elements of the <span class="type">struct
+hostent</span> returned in <em class="parameter"><code>resbuf</code></em>.
+Successful calls to <code class="function">lwres_gethostbyname_r()</code>
+return <em class="parameter"><code>resbuf</code></em>,
+which is a pointer to the <span class="type">struct hostent</span> it created.
+</p>
+<p>
+<code class="function">lwres_gethostbyaddr_r()</code> is a thread-safe function
+that performs a reverse lookup of address <em class="parameter"><code>addr</code></em>
+which is <em class="parameter"><code>len</code></em> bytes long and is of protocol
+family <em class="parameter"><code>type</code></em> &#8212; <span class="type">PF_INET</span> or
+<span class="type">PF_INET6</span>.  If an error occurs, the error code is returned
+in <em class="parameter"><code>*error</code></em>.  The other function parameters are
+identical to those in <code class="function">lwres_gethostbyname_r()</code>.
+<em class="parameter"><code>resbuf</code></em> is a pointer to a <span class="type">struct
+hostent</span> which is initialised by a successful call to
+<code class="function">lwres_gethostbyaddr_r()</code>.
+<em class="parameter"><code>buf</code></em> is a buffer of length
+<em class="parameter"><code>len</code></em> bytes which is used to store the
+<code class="constant">h_name</code>, <code class="constant">h_aliases</code>, and
+<code class="constant">h_addr_list</code> elements of the <span class="type">struct
+hostent</span> returned in <em class="parameter"><code>resbuf</code></em>.  Successful
+calls to <code class="function">lwres_gethostbyaddr_r()</code> return
+<em class="parameter"><code>resbuf</code></em>, which is a pointer to the
+<code class="function">struct hostent()</code> it created.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526380"></a><h2>RETURN VALUES</h2>
+<p>
+The functions
+<code class="function">lwres_gethostbyname()</code>,
+<code class="function">lwres_gethostbyname2()</code>,
+<code class="function">lwres_gethostbyaddr()</code>,
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gethostent()</CODE
->
+<code class="function">lwres_gethostent()</code>
 return NULL to indicate an error.  In this case the global variable
-<SPAN
-CLASS="TYPE"
->lwres_h_errno</SPAN
->
+<span class="type">lwres_h_errno</span>
 will contain one of the following error codes defined in
-<TT
-CLASS="FILENAME"
->&lt;lwres/netdb.h&gt;</TT
->:
+<code class="filename">&lt;lwres/netdb.h&gt;</code>:
 
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->HOST_NOT_FOUND</CODE
-></DT
-><DD
-><P
->The host or address was not found.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->TRY_AGAIN</CODE
-></DT
-><DD
-><P
->A recoverable error occurred, e.g., a timeout.
-Retrying the lookup may succeed.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->NO_RECOVERY</CODE
-></DT
-><DD
-><P
->A non-recoverable error occurred.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->NO_DATA</CODE
-></DT
-><DD
-><P
->The name exists, but has no address information
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">HOST_NOT_FOUND</code></span></dt>
+<dd><p>
+The host or address was not found.
+</p></dd>
+<dt><span class="term"><code class="constant">TRY_AGAIN</code></span></dt>
+<dd><p>
+A recoverable error occurred, e.g., a timeout.
+Retrying the lookup may succeed.
+</p></dd>
+<dt><span class="term"><code class="constant">NO_RECOVERY</code></span></dt>
+<dd><p>
+A non-recoverable error occurred.
+</p></dd>
+<dt><span class="term"><code class="constant">NO_DATA</code></span></dt>
+<dd><p>
+The name exists, but has no address information
 associated with it (or vice versa in the case
 of a reverse lookup).  The code NO_ADDRESS
 is accepted as a synonym for NO_DATA for backwards
-compatibility.</P
-></DD
-></DL
-></DIV
-></P
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_hstrerror</SPAN
->(3)</SPAN
->
-translates these error codes to suitable error messages.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gethostent()</CODE
->
+compatibility.
+</p></dd>
+</dl></div>
+<p>
+</p>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres_hstrerror</span>(3
+)</span>
+translates these error codes to suitable error messages.
+</p>
+<p>
+<code class="function">lwres_gethostent()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gethostent_r()</CODE
->
+<code class="function">lwres_gethostent_r()</code>
 always return
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
->.</P
-><P
->Successful calls to <CODE
-CLASS="FUNCTION"
->lwres_gethostbyname_r()</CODE
-> and
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr_r()</CODE
-> return
-<VAR
-CLASS="PARAMETER"
->resbuf</VAR
->, a pointer to the <SPAN
-CLASS="TYPE"
->struct
-hostent</SPAN
-> that was initialised by these functions.  They return
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
-> if the lookups fail or if <VAR
-CLASS="PARAMETER"
->buf</VAR
->
+<span class="type">NULL</span>.
+</p>
+<p>
+Successful calls to <code class="function">lwres_gethostbyname_r()</code> and
+<code class="function">lwres_gethostbyaddr_r()</code> return
+<em class="parameter"><code>resbuf</code></em>, a pointer to the <span class="type">struct
+hostent</span> that was initialised by these functions.  They return
+<span class="type">NULL</span> if the lookups fail or if <em class="parameter"><code>buf</code></em>
 was too small to hold the list of addresses and names referenced by
-the <CODE
-CLASS="CONSTANT"
->h_name</CODE
->, <CODE
-CLASS="CONSTANT"
->h_aliases</CODE
->, and
-<CODE
-CLASS="CONSTANT"
->h_addr_list</CODE
-> elements of the <SPAN
-CLASS="TYPE"
->struct
-hostent</SPAN
->.  If <VAR
-CLASS="PARAMETER"
->buf</VAR
-> was too small, both
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname_r()</CODE
-> and
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr_r()</CODE
-> set the global variable
-<SPAN
-CLASS="TYPE"
->errno</SPAN
-> to <SPAN
-CLASS="ERRORCODE"
->ERANGE</SPAN
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN245"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->gethostent</SPAN
->(3)</SPAN
->,
+the <code class="constant">h_name</code>, <code class="constant">h_aliases</code>, and
+<code class="constant">h_addr_list</code> elements of the <span class="type">struct
+hostent</span>.  If <em class="parameter"><code>buf</code></em> was too small, both
+<code class="function">lwres_gethostbyname_r()</code> and
+<code class="function">lwres_gethostbyaddr_r()</code> set the global variable
+<span class="type">errno</span> to <span class="errorcode">ERANGE</span>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526540"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">gethostent</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getipnode</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_getipnode</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_hstrerror</SPAN
->(3)</SPAN
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN257"
-></A
-><H2
->BUGS</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gethostbyname()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname2()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr()</CODE
->
+<span class="citerefentry"><span class="refentrytitle">lwres_hstrerror</span>(3
+)</span>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526644"></a><h2>BUGS</h2>
+<p>
+<code class="function">lwres_gethostbyname()</code>,
+<code class="function">lwres_gethostbyname2()</code>,
+<code class="function">lwres_gethostbyaddr()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_endhostent()</CODE
->
+<code class="function">lwres_endhostent()</code>
 are not thread safe; they return pointers to static data and 
 provide error codes through a global variable.
 Thread-safe versions for name and address lookup are provided by
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyname_r()</CODE
->,
+<code class="function">lwres_gethostbyname_r()</code>,
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gethostbyaddr_r()</CODE
->
-respectively.</P
-><P
->The resolver daemon does not currently support any non-DNS
+<code class="function">lwres_gethostbyaddr_r()</code>
+respectively.
+</p>
+<p>
+The resolver daemon does not currently support any non-DNS
 name services such as 
-<TT
-CLASS="FILENAME"
->/etc/hosts</TT
->
+<code class="filename">/etc/hosts</code>
 or
-<SPAN
-CLASS="TYPE"
->NIS</SPAN
->,
-consequently the above functions don't, either.</P
-></DIV
-></BODY
-></HTML
->
+<span class="type">NIS</span>,
+consequently the above functions don't, either.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.3 b/contrib/bind9/lib/lwres/man/lwres_getipnode.3
index 815a841512cb..d83758c5acf5 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getipnode.3
+++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.3
@@ -1,46 +1,46 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getipnode.3,v 1.13.2.2.4.2 2004/03/09 05:21:10 marka Exp $
+.\" $Id: lwres_getipnode.3,v 1.13.2.2.4.6 2005/10/13 02:33:53 marka Exp $
 .\"
-.TH "LWRES_GETIPNODE" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_GETIPNODE" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_getipnodebyname, lwres_getipnodebyaddr, lwres_freehostent \- lightweight resolver nodename / address translation API
-.SH SYNOPSIS
-\fB#include <lwres/netdb.h>
-.sp
-.na
-struct hostent *
-lwres_getipnodebyname(const char *name, int af, int flags, int *error_num);
-.ad
-.sp
-.na
-struct hostent *
-lwres_getipnodebyaddr(const void *src, size_t len, int af, int *error_num);
-.ad
-.sp
-.na
-void
-lwres_freehostent(struct hostent *he);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/netdb.h>
+.fi
+.HP 39
+\fBstruct\ hostent\ *\ \fBlwres_getipnodebyname\fR\fR\fB(\fR\fBconst\ char\ *name\fR\fB, \fR\fBint\ af\fR\fB, \fR\fBint\ flags\fR\fB, \fR\fBint\ *error_num\fR\fB);\fR
+.HP 39
+\fBstruct\ hostent\ *\ \fBlwres_getipnodebyaddr\fR\fR\fB(\fR\fBconst\ void\ *src\fR\fB, \fR\fBsize_t\ len\fR\fB, \fR\fBint\ af\fR\fB, \fR\fBint\ *error_num\fR\fB);\fR
+.HP 23
+\fBvoid\ \fBlwres_freehostent\fR\fR\fB(\fR\fBstruct\ hostent\ *he\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-These functions perform thread safe, protocol independent
-nodename-to-address and address-to-nodename 
-translation as defined in RFC2553.
+These functions perform thread safe, protocol independent nodename\-to\-address and address\-to\-nodename translation as defined in RFC2553.
 .PP
 They use a
 \fBstruct hostent\fR
@@ -56,8 +56,8 @@ struct  hostent {
         char    **h_addr_list;  /* list of addresses from name server */
 };
 #define h_addr  h_addr_list[0]  /* address, for backward compatibility */
-.sp
 .fi
+.sp
 .PP
 The members of this structure are:
 .TP
@@ -65,10 +65,10 @@ The members of this structure are:
 The official (canonical) name of the host.
 .TP
 \fBh_aliases\fR
-A NULL-terminated array of alternate names (nicknames) for the host.
+A NULL\-terminated array of alternate names (nicknames) for the host.
 .TP
 \fBh_addrtype\fR
-The type of address being returned - usually
+The type of address being returned \- usually
 \fBPF_INET\fR
 or
 \fBPF_INET6\fR.
@@ -79,49 +79,38 @@ The length of the address in bytes.
 \fBh_addr_list\fR
 A
 \fBNULL\fR
-terminated array of network addresses for the host.
-Host addresses are returned in network byte order.
+terminated array of network addresses for the host. Host addresses are returned in network byte order.
 .PP
 \fBlwres_getipnodebyname()\fR
 looks up addresses of protocol family
 \fIaf\fR
 for the hostname
-\fIname\fR.
-The
+\fIname\fR. The
 \fIflags\fR
-parameter contains ORed flag bits to 
-specify the types of addresses that are searched
-for, and the types of addresses that are returned. 
-The flag bits are:
+parameter contains ORed flag bits to specify the types of addresses that are searched for, and the types of addresses that are returned. The flag bits are:
 .TP
 \fBAI_V4MAPPED\fR
 This is used with an
 \fIaf\fR
-of AF_INET6, and causes IPv4 addresses to be returned as IPv4-mapped
-IPv6 addresses.
+of AF_INET6, and causes IPv4 addresses to be returned as IPv4\-mapped IPv6 addresses.
 .TP
 \fBAI_ALL\fR
 This is used with an
 \fIaf\fR
-of AF_INET6, and causes all known addresses (IPv6 and IPv4) to be returned.
-If AI_V4MAPPED is also set, the IPv4 addresses are return as mapped
-IPv6 addresses.
+of AF_INET6, and causes all known addresses (IPv6 and IPv4) to be returned. If AI_V4MAPPED is also set, the IPv4 addresses are return as mapped IPv6 addresses.
 .TP
 \fBAI_ADDRCONFIG\fR
-Only return an IPv6 or IPv4 address if here is an active network
-interface of that type. This is not currently implemented
-in the BIND 9 lightweight resolver, and the flag is ignored.
+Only return an IPv6 or IPv4 address if here is an active network interface of that type. This is not currently implemented in the BIND 9 lightweight resolver, and the flag is ignored.
 .TP
 \fBAI_DEFAULT\fR
 This default sets the
-AI_V4MAPPED
+\fBAI_V4MAPPED\fR
 and
-AI_ADDRCONFIG
+\fBAI_ADDRCONFIG\fR
 flag bits.
 .PP
 \fBlwres_getipnodebyaddr()\fR
-performs a reverse lookup
-of address
+performs a reverse lookup of address
 \fIsrc\fR
 which is
 \fIlen\fR
@@ -133,16 +122,14 @@ or
 \fBPF_INET6\fR.
 .PP
 \fBlwres_freehostent()\fR
-releases all the memory associated with
-the
+releases all the memory associated with the
 \fBstruct hostent\fR
 pointer
-\fIhe\fR.
-Any memory allocated for the
-h_name,
-h_addr_list
+\fIhe\fR. Any memory allocated for the
+\fBh_name\fR,
+\fBh_addr_list\fR
 and
-h_aliases
+\fBh_aliases\fR
 is freed, as is the memory for the
 \fBhostent\fR
 structure itself.
@@ -156,32 +143,26 @@ set
 \fI*error_num\fR
 to an appropriate error code and the function returns a
 \fBNULL\fR
-pointer.
-The error codes and their meanings are defined in
+pointer. The error codes and their meanings are defined in
 \fI<lwres/netdb.h>\fR:
 .TP
 \fBHOST_NOT_FOUND\fR
 No such host is known.
 .TP
 \fBNO_ADDRESS\fR
-The server recognised the request and the name but no address is
-available. Another type of request to the name server for the
-domain might return an answer.
+The server recognised the request and the name but no address is available. Another type of request to the name server for the domain might return an answer.
 .TP
 \fBTRY_AGAIN\fR
-A temporary and possibly transient error occurred, such as a
-failure of a server to respond. The request may succeed if
-retried.
+A temporary and possibly transient error occurred, such as a failure of a server to respond. The request may succeed if retried.
 .TP
 \fBNO_RECOVERY\fR
-An unexpected failure occurred, and retrying the request
-is pointless.
+An unexpected failure occurred, and retrying the request is pointless.
 .PP
-\fBlwres_hstrerror\fR(3)
+\fBlwres_hstrerror\fR(3 )
 translates these error codes to suitable error messages.
 .SH "SEE ALSO"
 .PP
-\fBRFC2553\fR,
+\fBRFC2553\fR(),
 \fBlwres\fR(3),
 \fBlwres_gethostent\fR(3),
 \fBlwres_getaddrinfo\fR(3),
diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook b/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook
index 30c04a355502..94de72c0fe70 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_getipnode.docbook,v 1.4.2.2.4.1 2004/03/06 08:15:39 marka Exp $ -->
+<!-- $Id: lwres_getipnode.docbook,v 1.4.2.2.4.3 2005/05/12 21:36:14 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,20 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <year>2003</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_getipnodebyname</refname>
 <refname>lwres_getipnodebyaddr</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.html b/contrib/bind9/lib/lwres/man/lwres_getipnode.html
index 3063d440582b..c5038b4f5a5d 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getipnode.html
+++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.html
@@ -1,512 +1,298 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001, 2003 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_getipnode.html,v 1.7.2.1.4.2 2004/08/22 23:39:04 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_getipnode</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_getipnode</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_getipnodebyname, lwres_getipnodebyaddr, lwres_freehostent&nbsp;--&nbsp;lightweight resolver nodename / address translation API</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN14"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/netdb.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent *
-lwres_getipnodebyname</CODE
->(const char *name, int af, int flags, int *error_num);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->struct hostent *
-lwres_getipnodebyaddr</CODE
->(const void *src, size_t len, int af, int *error_num);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_freehostent</CODE
->(struct hostent *he);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN34"
-></A
-><H2
->DESCRIPTION</H2
-><P
->These functions perform thread safe, protocol independent
+<!-- $Id: lwres_getipnode.html,v 1.7.2.1.4.9 2005/10/13 02:33:56 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_getipnode</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_getipnodebyname, lwres_getipnodebyaddr, lwres_freehostent &#8212; lightweight resolver nodename / address translation API</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/netdb.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+struct hostent *
+<b class="fsfunc">lwres_getipnodebyname</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+struct hostent *
+<b class="fsfunc">lwres_getipnodebyaddr</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0"><tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_freehostent</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525896"></a><h2>DESCRIPTION</h2>
+<p>
+These functions perform thread safe, protocol independent
 nodename-to-address and address-to-nodename 
-translation as defined in RFC2553.</P
-><P
->They use a
-<SPAN
-CLASS="TYPE"
->struct hostent</SPAN
->
+translation as defined in RFC2553.
+</p>
+<p>
+They use a
+<span class="type">struct hostent</span>
 which is defined in
-<TT
-CLASS="FILENAME"
->namedb.h</TT
->:
-<PRE
-CLASS="PROGRAMLISTING"
->struct  hostent {
+<code class="filename">namedb.h</code>:
+</p>
+<pre class="programlisting">
+struct  hostent {
         char    *h_name;        /* official name of host */
         char    **h_aliases;    /* alias list */
         int     h_addrtype;     /* host address type */
         int     h_length;       /* length of address */
         char    **h_addr_list;  /* list of addresses from name server */
 };
-#define h_addr  h_addr_list[0]  /* address, for backward compatibility */</PRE
-></P
-><P
->The members of this structure are:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->h_name</CODE
-></DT
-><DD
-><P
->The official (canonical) name of the host.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->h_aliases</CODE
-></DT
-><DD
-><P
->A NULL-terminated array of alternate names (nicknames) for the host.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->h_addrtype</CODE
-></DT
-><DD
-><P
->The type of address being returned - usually
-<SPAN
-CLASS="TYPE"
->PF_INET</SPAN
->
+#define h_addr  h_addr_list[0]  /* address, for backward compatibility */
+</pre>
+<p>
+</p>
+<p>
+The members of this structure are:
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">h_name</code></span></dt>
+<dd><p>
+The official (canonical) name of the host.
+</p></dd>
+<dt><span class="term"><code class="constant">h_aliases</code></span></dt>
+<dd><p>
+A NULL-terminated array of alternate names (nicknames) for the host.
+</p></dd>
+<dt><span class="term"><code class="constant">h_addrtype</code></span></dt>
+<dd><p>
+The type of address being returned - usually
+<span class="type">PF_INET</span>
 or
-<SPAN
-CLASS="TYPE"
->PF_INET6</SPAN
->.&#13;</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->h_length</CODE
-></DT
-><DD
-><P
->The length of the address in bytes.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->h_addr_list</CODE
-></DT
-><DD
-><P
->A
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
->
+<span class="type">PF_INET6</span>.
+
+</p></dd>
+<dt><span class="term"><code class="constant">h_length</code></span></dt>
+<dd><p>
+The length of the address in bytes.
+</p></dd>
+<dt><span class="term"><code class="constant">h_addr_list</code></span></dt>
+<dd><p>
+A
+<span class="type">NULL</span>
 terminated array of network addresses for the host.
-Host addresses are returned in network byte order.</P
-></DD
-></DL
-></DIV
-></P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getipnodebyname()</CODE
->
+Host addresses are returned in network byte order.
+</p></dd>
+</dl></div>
+<p>
+</p>
+<p>
+<code class="function">lwres_getipnodebyname()</code>
 looks up addresses of protocol family
-<VAR
-CLASS="PARAMETER"
->af</VAR
->
+<em class="parameter"><code>af</code></em>
 
 for the hostname
-<VAR
-CLASS="PARAMETER"
->name</VAR
->.
+<em class="parameter"><code>name</code></em>.
 
 The
-<VAR
-CLASS="PARAMETER"
->flags</VAR
->
+<em class="parameter"><code>flags</code></em>
 parameter contains ORed flag bits to 
 specify the types of addresses that are searched
 for, and the types of addresses that are returned. 
 The flag bits are:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->AI_V4MAPPED</CODE
-></DT
-><DD
-><P
->This is used with an
-<VAR
-CLASS="PARAMETER"
->af</VAR
->
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">AI_V4MAPPED</code></span></dt>
+<dd><p>
+This is used with an
+<em class="parameter"><code>af</code></em>
 of AF_INET6, and causes IPv4 addresses to be returned as IPv4-mapped
-IPv6 addresses.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->AI_ALL</CODE
-></DT
-><DD
-><P
->This is used with an
-<VAR
-CLASS="PARAMETER"
->af</VAR
->
+IPv6 addresses.
+</p></dd>
+<dt><span class="term"><code class="constant">AI_ALL</code></span></dt>
+<dd><p>
+This is used with an
+<em class="parameter"><code>af</code></em>
 of AF_INET6, and causes all known addresses (IPv6 and IPv4) to be returned.
 If AI_V4MAPPED is also set, the IPv4 addresses are return as mapped
-IPv6 addresses.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->AI_ADDRCONFIG</CODE
-></DT
-><DD
-><P
->Only return an IPv6 or IPv4 address if here is an active network
+IPv6 addresses.
+</p></dd>
+<dt><span class="term"><code class="constant">AI_ADDRCONFIG</code></span></dt>
+<dd><p>
+Only return an IPv6 or IPv4 address if here is an active network
 interface of that type.  This is not currently implemented
-in the BIND 9 lightweight resolver, and the flag is ignored.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->AI_DEFAULT</CODE
-></DT
-><DD
-><P
->This default sets the
-<CODE
-CLASS="CONSTANT"
->AI_V4MAPPED</CODE
->
+in the BIND 9 lightweight resolver, and the flag is ignored.
+</p></dd>
+<dt><span class="term"><code class="constant">AI_DEFAULT</code></span></dt>
+<dd><p>
+This default sets the
+<code class="constant">AI_V4MAPPED</code>
 and
-<CODE
-CLASS="CONSTANT"
->AI_ADDRCONFIG</CODE
->
-flag bits.</P
-></DD
-></DL
-></DIV
-></P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getipnodebyaddr()</CODE
->
+<code class="constant">AI_ADDRCONFIG</code>
+flag bits.
+</p></dd>
+</dl></div>
+<p>
+</p>
+<p>
+<code class="function">lwres_getipnodebyaddr()</code>
 performs a reverse lookup
 of address
-<VAR
-CLASS="PARAMETER"
->src</VAR
->
+<em class="parameter"><code>src</code></em>
 which is
-<VAR
-CLASS="PARAMETER"
->len</VAR
->
+<em class="parameter"><code>len</code></em>
 bytes long.
-<VAR
-CLASS="PARAMETER"
->af</VAR
->
+<em class="parameter"><code>af</code></em>
 denotes the protocol family, typically
-<SPAN
-CLASS="TYPE"
->PF_INET</SPAN
->
+<span class="type">PF_INET</span>
 or
-<SPAN
-CLASS="TYPE"
->PF_INET6</SPAN
->.&#13;</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_freehostent()</CODE
->
+<span class="type">PF_INET6</span>.
+
+</p>
+<p>
+<code class="function">lwres_freehostent()</code>
 releases all the memory associated with
 the
-<SPAN
-CLASS="TYPE"
->struct hostent</SPAN
->
+<span class="type">struct hostent</span>
 pointer
-<VAR
-CLASS="PARAMETER"
->he</VAR
->.
+<em class="parameter"><code>he</code></em>.
 
 Any memory allocated for the
-<CODE
-CLASS="CONSTANT"
->h_name</CODE
->,
+<code class="constant">h_name</code>,
 
-<CODE
-CLASS="CONSTANT"
->h_addr_list</CODE
->
+<code class="constant">h_addr_list</code>
 and
-<CODE
-CLASS="CONSTANT"
->h_aliases</CODE
->
+<code class="constant">h_aliases</code>
 is freed, as is the memory for the
-<SPAN
-CLASS="TYPE"
->hostent</SPAN
->
-structure itself.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN116"
-></A
-><H2
->RETURN VALUES</H2
-><P
->If an error occurs,
-<CODE
-CLASS="FUNCTION"
->lwres_getipnodebyname()</CODE
->
+<span class="type">hostent</span>
+structure itself.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526131"></a><h2>RETURN VALUES</h2>
+<p>
+If an error occurs,
+<code class="function">lwres_getipnodebyname()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_getipnodebyaddr()</CODE
->
+<code class="function">lwres_getipnodebyaddr()</code>
 set
-<VAR
-CLASS="PARAMETER"
->*error_num</VAR
->
+<em class="parameter"><code>*error_num</code></em>
 to an appropriate error code and the function returns a
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
->
+<span class="type">NULL</span>
 pointer.
 The error codes and their meanings are defined in
-<TT
-CLASS="FILENAME"
->&lt;lwres/netdb.h&gt;</TT
->:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->HOST_NOT_FOUND</CODE
-></DT
-><DD
-><P
->No such host is known.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->NO_ADDRESS</CODE
-></DT
-><DD
-><P
->The server recognised the request and the name but no address is
+<code class="filename">&lt;lwres/netdb.h&gt;</code>:
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">HOST_NOT_FOUND</code></span></dt>
+<dd><p>
+No such host is known.
+</p></dd>
+<dt><span class="term"><code class="constant">NO_ADDRESS</code></span></dt>
+<dd><p>
+The server recognised the request and the name but no address is
 available.  Another type of request to the name server for the
-domain might return an answer.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->TRY_AGAIN</CODE
-></DT
-><DD
-><P
->A temporary and possibly transient error occurred, such as a
+domain might return an answer.
+</p></dd>
+<dt><span class="term"><code class="constant">TRY_AGAIN</code></span></dt>
+<dd><p>
+A temporary and possibly transient error occurred, such as a
 failure of a server to respond.  The request may succeed if
-retried.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->NO_RECOVERY</CODE
-></DT
-><DD
-><P
->An unexpected failure occurred, and retrying the request
-is pointless.</P
-></DD
-></DL
-></DIV
-></P
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_hstrerror</SPAN
->(3)</SPAN
->
-translates these error codes to suitable error messages.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN149"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2553</SPAN
-></SPAN
->,
+retried.
+</p></dd>
+<dt><span class="term"><code class="constant">NO_RECOVERY</code></span></dt>
+<dd><p>
+An unexpected failure occurred, and retrying the request
+is pointless.
+</p></dd>
+</dl></div>
+<p>
+</p>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres_hstrerror</span>(3
+)</span>
+translates these error codes to suitable error messages.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526290"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">RFC2553</span></span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_gethostent</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_gethostent</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getaddrinfo</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_getaddrinfo</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getnameinfo</SPAN
->(3)</SPAN
->,
+<span class="citerefentry"><span class="refentrytitle">lwres_getnameinfo</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_hstrerror</SPAN
->(3)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+<span class="citerefentry"><span class="refentrytitle">lwres_hstrerror</span>(3)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3 b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3
index a512270673b6..853c2b9bb940 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3
+++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3
@@ -1,79 +1,91 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getnameinfo.3,v 1.15.2.1.8.1 2004/03/06 07:41:43 marka Exp $
+.\" $Id: lwres_getnameinfo.3,v 1.15.2.1.8.5 2005/10/13 02:33:53 marka Exp $
 .\"
-.TH "LWRES_GETNAMEINFO" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_GETNAMEINFO" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_getnameinfo \- lightweight resolver socket address structure to hostname and service name
-.SH SYNOPSIS
-\fB#include <lwres/netdb.h>
-.sp
-.na
-int
-lwres_getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/netdb.h>
+.fi
+.HP 22
+\fBint\ \fBlwres_getnameinfo\fR\fR\fB(\fR\fBconst\ struct\ sockaddr\ *sa\fR\fB, \fR\fBsize_t\ salen\fR\fB, \fR\fBchar\ *host\fR\fB, \fR\fBsize_t\ hostlen\fR\fB, \fR\fBchar\ *serv\fR\fB, \fR\fBsize_t\ servlen\fR\fB, \fR\fBint\ flags\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-This function is equivalent to the \fBgetnameinfo\fR(3) function defined in RFC2133.
-\fBlwres_getnameinfo()\fR returns the hostname for the
-\fBstruct sockaddr\fR \fIsa\fR which is
-\fIsalen\fR bytes long. The hostname is of length
-\fIhostlen\fR and is returned via
-\fI*host.\fR The maximum length of the hostname is
-1025 bytes: NI_MAXHOST.
+This function is equivalent to the
+\fBgetnameinfo\fR(3)
+function defined in RFC2133.
+\fBlwres_getnameinfo()\fR
+returns the hostname for the
+\fBstruct sockaddr\fR\fIsa\fR
+which is
+\fIsalen\fR
+bytes long. The hostname is of length
+\fIhostlen\fR
+and is returned via
+\fI*host.\fR
+The maximum length of the hostname is 1025 bytes:
+\fBNI_MAXHOST\fR.
 .PP
 The name of the service associated with the port number in
-\fIsa\fR is returned in \fI*serv.\fR
-It is \fIservlen\fR bytes long. The maximum length
-of the service name is NI_MAXSERV - 32 bytes.
+\fIsa\fR
+is returned in
+\fI*serv.\fR
+It is
+\fIservlen\fR
+bytes long. The maximum length of the service name is
+\fBNI_MAXSERV\fR
+\- 32 bytes.
 .PP
-The \fIflags\fR argument sets the following
-bits:
+The
+\fIflags\fR
+argument sets the following bits:
 .TP
 \fBNI_NOFQDN\fR
-A fully qualified domain name is not required for local hosts.
-The local part of the fully qualified domain name is returned instead.
+A fully qualified domain name is not required for local hosts. The local part of the fully qualified domain name is returned instead.
 .TP
 \fBNI_NUMERICHOST\fR
-Return the address in numeric form, as if calling inet_ntop(),
-instead of a host name.
+Return the address in numeric form, as if calling inet_ntop(), instead of a host name.
 .TP
 \fBNI_NAMEREQD\fR
-A name is required. If the hostname cannot be found in the DNS and
-this flag is set, a non-zero error code is returned.
-If the hostname is not found and the flag is not set, the 
-address is returned in numeric form.
+A name is required. If the hostname cannot be found in the DNS and this flag is set, a non\-zero error code is returned. If the hostname is not found and the flag is not set, the address is returned in numeric form.
 .TP
 \fBNI_NUMERICSERV\fR
 The service name is returned as a digit string representing the port number.
 .TP
 \fBNI_DGRAM\fR
-Specifies that the service being looked up is a datagram
-service, and causes getservbyport() to be called with a second
-argument of "udp" instead of its default of "tcp". This is required
-for the few ports (512-514) that have different services for UDP and
-TCP.
+Specifies that the service being looked up is a datagram service, and causes getservbyport() to be called with a second argument of "udp" instead of its default of "tcp". This is required for the few ports (512\-514) that have different services for UDP and TCP.
 .SH "RETURN VALUES"
 .PP
 \fBlwres_getnameinfo()\fR
-returns 0 on success or a non-zero error code if an error occurs.
+returns 0 on success or a non\-zero error code if an error occurs.
 .SH "SEE ALSO"
 .PP
-\fBRFC2133\fR,
+\fBRFC2133\fR(),
 \fBgetservbyport\fR(3),
 \fBlwres\fR(3),
 \fBlwres_getnameinfo\fR(3),
diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook
index ff2eaad0e965..b6e10ac3ab05 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_getnameinfo.docbook,v 1.3.206.1 2004/03/06 08:15:40 marka Exp $ -->
+<!-- $Id: lwres_getnameinfo.docbook,v 1.3.206.3 2005/05/12 21:36:15 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,19 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_getnameinfo</refname>
 <refpurpose>lightweight resolver socket address structure to hostname and service name</refpurpose>
@@ -140,6 +155,7 @@ returns 0 on success or a non-zero error code if an error occurs.
 <citerefentry>
 <refentrytitle>lwres_net_ntop</refentrytitle><manvolnum>3</manvolnum>
 </citerefentry>.
+</para>
 </refsect1>
 <refsect1>
 <title>BUGS</title>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html
index 8130fe832117..6e7a7b166587 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html
+++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html
@@ -1,290 +1,154 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_getnameinfo.html,v 1.5.2.1.4.2 2004/08/22 23:39:04 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_getnameinfo</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_getnameinfo</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_getnameinfo&nbsp;--&nbsp;lightweight resolver socket address structure to hostname and service name</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN11"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN12"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/netdb.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->int
-lwres_getnameinfo</CODE
->(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN24"
-></A
-><H2
->DESCRIPTION</H2
-><P
-> This function is equivalent to the <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->getnameinfo</SPAN
->(3)</SPAN
-> function defined in RFC2133.
-<CODE
-CLASS="FUNCTION"
->lwres_getnameinfo()</CODE
-> returns the hostname for the
-<SPAN
-CLASS="TYPE"
->struct sockaddr</SPAN
-> <VAR
-CLASS="PARAMETER"
->sa</VAR
-> which is
-<VAR
-CLASS="PARAMETER"
->salen</VAR
-> bytes long.  The hostname is of length
-<VAR
-CLASS="PARAMETER"
->hostlen</VAR
-> and is returned via
-<VAR
-CLASS="PARAMETER"
->*host.</VAR
-> The maximum length of the hostname is
-1025 bytes: <CODE
-CLASS="CONSTANT"
->NI_MAXHOST</CODE
->.</P
-><P
-> The name of the service associated with the port number in
-<VAR
-CLASS="PARAMETER"
->sa</VAR
-> is returned in <VAR
-CLASS="PARAMETER"
->*serv.</VAR
->
-It is <VAR
-CLASS="PARAMETER"
->servlen</VAR
-> bytes long.  The maximum length
-of the service name is <CODE
-CLASS="CONSTANT"
->NI_MAXSERV</CODE
-> - 32 bytes.</P
-><P
-> The <VAR
-CLASS="PARAMETER"
->flags</VAR
-> argument sets the following
+<!-- $Id: lwres_getnameinfo.html,v 1.5.2.1.4.9 2005/10/13 02:33:56 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_getnameinfo</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_getnameinfo &#8212; lightweight resolver socket address structure to hostname and service name</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/netdb.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+int
+<b class="fsfunc">lwres_getnameinfo</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525862"></a><h2>DESCRIPTION</h2>
+<p> This function is equivalent to the <span class="citerefentry"><span class="refentrytitle">getnameinfo</span>(3)</span> function defined in RFC2133.
+<code class="function">lwres_getnameinfo()</code> returns the hostname for the
+<span class="type">struct sockaddr</span> <em class="parameter"><code>sa</code></em> which is
+<em class="parameter"><code>salen</code></em> bytes long.  The hostname is of length
+<em class="parameter"><code>hostlen</code></em> and is returned via
+<em class="parameter"><code>*host.</code></em> The maximum length of the hostname is
+1025 bytes: <code class="constant">NI_MAXHOST</code>.</p>
+<p> The name of the service associated with the port number in
+<em class="parameter"><code>sa</code></em> is returned in <em class="parameter"><code>*serv.</code></em>
+It is <em class="parameter"><code>servlen</code></em> bytes long.  The maximum length
+of the service name is <code class="constant">NI_MAXSERV</code> - 32 bytes.
+</p>
+<p> The <em class="parameter"><code>flags</code></em> argument sets the following
 bits:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->NI_NOFQDN</CODE
-></DT
-><DD
-><P
->A fully qualified domain name is not required for local hosts.
-The local part of the fully qualified domain name is returned instead.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->NI_NUMERICHOST</CODE
-></DT
-><DD
-><P
->Return the address in numeric form, as if calling inet_ntop(),
-instead of a host name.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->NI_NAMEREQD</CODE
-></DT
-><DD
-><P
->A name is required. If the hostname cannot be found in the DNS and
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">NI_NOFQDN</code></span></dt>
+<dd><p>
+A fully qualified domain name is not required for local hosts.
+The local part of the fully qualified domain name is returned instead.
+</p></dd>
+<dt><span class="term"><code class="constant">NI_NUMERICHOST</code></span></dt>
+<dd><p>
+Return the address in numeric form, as if calling inet_ntop(),
+instead of a host name.
+</p></dd>
+<dt><span class="term"><code class="constant">NI_NAMEREQD</code></span></dt>
+<dd><p>
+A name is required. If the hostname cannot be found in the DNS and
 this flag is set, a non-zero error code is returned.
 If the hostname is not found and the flag is not set, the 
-address is returned in numeric form.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->NI_NUMERICSERV</CODE
-></DT
-><DD
-><P
->The service name is returned as a digit string representing the port number.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->NI_DGRAM</CODE
-></DT
-><DD
-><P
->Specifies that the service being looked up is a datagram
+address is returned in numeric form.
+</p></dd>
+<dt><span class="term"><code class="constant">NI_NUMERICSERV</code></span></dt>
+<dd><p>
+The service name is returned as a digit string representing the port number.
+</p></dd>
+<dt><span class="term"><code class="constant">NI_DGRAM</code></span></dt>
+<dd><p>
+Specifies that the service being looked up is a datagram
 service,  and causes getservbyport() to be called with a second
 argument of "udp" instead of its default of "tcp".  This is required
 for the few ports (512-514) that have different services for UDP and
-TCP.</P
-></DD
-></DL
-></DIV
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN70"
-></A
-><H2
->RETURN VALUES</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getnameinfo()</CODE
->
-returns 0 on success or a non-zero error code if an error occurs.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN74"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC2133</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->getservbyport</SPAN
->(3)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres</SPAN
->(3)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getnameinfo</SPAN
->(3)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_getnamebyaddr</SPAN
->(3)</SPAN
->.
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_net_ntop</SPAN
->(3)</SPAN
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN94"
-></A
-><H2
->BUGS</H2
-><P
->RFC2133 fails to define what the nonzero return values of
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->getnameinfo</SPAN
->(3)</SPAN
->
-are.</P
-></DIV
-></BODY
-></HTML
->
+TCP.
+</p></dd>
+</dl></div>
+<p>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525988"></a><h2>RETURN VALUES</h2>
+<p>
+<code class="function">lwres_getnameinfo()</code>
+returns 0 on success or a non-zero error code if an error occurs.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526001"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">RFC2133</span></span>,
+<span class="citerefentry"><span class="refentrytitle">getservbyport</span>(3)</span>,
+<span class="citerefentry"><span class="refentrytitle">lwres</span>(3)</span>,
+<span class="citerefentry"><span class="refentrytitle">lwres_getnameinfo</span>(3)</span>,
+<span class="citerefentry"><span class="refentrytitle">lwres_getnamebyaddr</span>(3)</span>.
+<span class="citerefentry"><span class="refentrytitle">lwres_net_ntop</span>(3)</span>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526059"></a><h2>BUGS</h2>
+<p>
+RFC2133 fails to define what the nonzero return values of
+<span class="citerefentry"><span class="refentrytitle">getnameinfo</span>(3)</span>
+are.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3 b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3
index 1558f6d5b08a..6d900f864ff4 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3
+++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3
@@ -1,36 +1,41 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getrrsetbyname.3,v 1.11.2.1.8.1 2004/03/06 07:41:43 marka Exp $
+.\" $Id: lwres_getrrsetbyname.3,v 1.11.2.1.8.5 2005/10/13 02:33:53 marka Exp $
 .\"
-.TH "LWRES_GETRRSETBYNAME" "3" "Oct 18, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_GETRRSETBYNAME" "3" "Oct 18, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_getrrsetbyname, lwres_freerrset \- retrieve DNS records
-.SH SYNOPSIS
-\fB#include <lwres/netdb.h>
-.sp
-.na
-int
-lwres_getrrsetbyname(const char *hostname, unsigned int rdclass, unsigned int rdtype, unsigned int flags, struct rrsetinfo **res);
-.ad
-.sp
-.na
-void
-lwres_freerrset(struct rrsetinfo *rrset);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/netdb.h>
+.fi
+.HP 25
+\fBint\ \fBlwres_getrrsetbyname\fR\fR\fB(\fR\fBconst\ char\ *hostname\fR\fB, \fR\fBunsigned\ int\ rdclass\fR\fB, \fR\fBunsigned\ int\ rdtype\fR\fB, \fR\fBunsigned\ int\ flags\fR\fB, \fR\fBstruct\ rrsetinfo\ **res\fR\fB);\fR
+.HP 21
+\fBvoid\ \fBlwres_freerrset\fR\fR\fB(\fR\fBstruct\ rrsetinfo\ *rrset\fR\fB);\fR
 .PP
 The following structures are used:
 .sp
@@ -39,7 +44,6 @@ struct  rdatainfo {
         unsigned int            rdi_length;     /* length of data */
         unsigned char           *rdi_data;      /* record data */
 };
-
 struct  rrsetinfo {
         unsigned int            rri_flags;      /* RRSET_VALIDATED... */
         unsigned int            rri_rdclass;    /* class number */
@@ -51,19 +55,17 @@ struct  rrsetinfo {
         struct rdatainfo        *rri_rdatas;    /* individual records */
         struct rdatainfo        *rri_sigs;      /* individual signatures */
 };
-.sp
 .fi
+.sp
 .SH "DESCRIPTION"
 .PP
 \fBlwres_getrrsetbyname()\fR
 gets a set of resource records associated with a
 \fIhostname\fR,
-\fIclass\fR,
-and
+\fIclass\fR, and
 \fItype\fR.
 \fIhostname\fR
-is
-a pointer a to null-terminated string. The
+is a pointer a to null\-terminated string. The
 \fIflags\fR
 field is currently unused and must be zero.
 .PP
@@ -76,38 +78,30 @@ structure, containing a list of one or more
 \fBrdatainfo\fR
 structures containing resource records and potentially another list of
 \fBrdatainfo\fR
-structures containing SIG resource records
-associated with those records.
-The members
-rri_rdclass
+structures containing SIG resource records associated with those records. The members
+\fBrri_rdclass\fR
 and
-rri_rdtype
+\fBrri_rdtype\fR
 are copied from the parameters.
-rri_ttl
+\fBrri_ttl\fR
 and
-rri_name
-are properties of the obtained rrset.
-The resource records contained in
-rri_rdatas
+\fBrri_name\fR
+are properties of the obtained rrset. The resource records contained in
+\fBrri_rdatas\fR
 and
-rri_sigs
-are in uncompressed DNS wire format.
-Properties of the rdataset are represented in the
-rri_flags
-bitfield. If the RRSET_VALIDATED bit is set, the data has been DNSSEC
-validated and the signatures verified. 
+\fBrri_sigs\fR
+are in uncompressed DNS wire format. Properties of the rdataset are represented in the
+\fBrri_flags\fR
+bitfield. If the RRSET_VALIDATED bit is set, the data has been DNSSEC validated and the signatures verified.
 .PP
 All of the information returned by
 \fBlwres_getrrsetbyname()\fR
 is dynamically allocated: the
-rrsetinfo
+\fBrrsetinfo\fR
 and
-rdatainfo
-structures,
-and the canonical host name strings pointed to by the
-rrsetinfostructure.
-Memory allocated for the dynamically allocated structures created by
-a successful call to
+\fBrdatainfo\fR
+structures, and the canonical host name strings pointed to by the
+\fBrrsetinfo\fRstructure. Memory allocated for the dynamically allocated structures created by a successful call to
 \fBlwres_getrrsetbyname()\fR
 is released by
 \fBlwres_freerrset()\fR.
@@ -120,8 +114,7 @@ created by a call to
 .SH "RETURN VALUES"
 .PP
 \fBlwres_getrrsetbyname()\fR
-returns zero on success, and one of the following error
-codes if an error occurred:
+returns zero on success, and one of the following error codes if an error occurred:
 .TP
 \fBERRSET_NONAME\fR
 the name does not exist
@@ -138,7 +131,6 @@ a parameter is invalid
 \fBERRSET_FAIL\fR
 other failure
 .TP
-\fB\fR
 .SH "SEE ALSO"
 .PP
 \fBlwres\fR(3).
diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook
index 5ec7884b360c..53c33bef7b34 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_getrrsetbyname.docbook,v 1.3.206.1 2004/03/06 08:15:40 marka Exp $ -->
+<!-- $Id: lwres_getrrsetbyname.docbook,v 1.3.206.3 2005/05/12 21:36:15 sra Exp $ -->
 
 <refentry>
 <refentryinfo>
@@ -29,6 +31,20 @@
 <manvolnum>3</manvolnum>
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
+
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_getrrsetbyname</refname>
 <refname>lwres_freerrset</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html
index 8a688e9b2b44..f36a1d21d996 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html
+++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html
@@ -1,91 +1,80 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_getrrsetbyname.html,v 1.5.2.1.4.2 2004/08/22 23:39:04 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_getrrsetbyname</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_getrrsetbyname</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_getrrsetbyname, lwres_freerrset&nbsp;--&nbsp;retrieve DNS records</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN12"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN13"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/netdb.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->int
-lwres_getrrsetbyname</CODE
->(const char *hostname, unsigned int rdclass, unsigned int rdtype, unsigned int flags, struct rrsetinfo **res);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_freerrset</CODE
->(struct rrsetinfo *rrset);</CODE
-></P
-><P
-></P
-></DIV
-><P
->The following structures are used:
-<PRE
-CLASS="PROGRAMLISTING"
->struct  rdatainfo {
+<!-- $Id: lwres_getrrsetbyname.html,v 1.5.2.1.4.9 2005/10/13 02:33:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_getrrsetbyname</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_getrrsetbyname, lwres_freerrset &#8212; retrieve DNS records</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/netdb.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+int
+<b class="fsfunc">lwres_getrrsetbyname</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0"><tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_freerrset</b>(</code></td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr></table>
+</div>
+<p>
+The following structures are used:
+</p>
+<pre class="programlisting">
+struct  rdatainfo {
         unsigned int            rdi_length;     /* length of data */
         unsigned char           *rdi_data;      /* record data */
 };
@@ -100,261 +89,129 @@ struct  rrsetinfo {
         char                    *rri_name;      /* canonical name */
         struct rdatainfo        *rri_rdatas;    /* individual records */
         struct rdatainfo        *rri_sigs;      /* individual signatures */
-};</PRE
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN29"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getrrsetbyname()</CODE
->
+};
+</pre>
+<p>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525878"></a><h2>DESCRIPTION</h2>
+<p>
+<code class="function">lwres_getrrsetbyname()</code>
 gets a set of resource records associated with a
-<VAR
-CLASS="PARAMETER"
->hostname</VAR
->,
+<em class="parameter"><code>hostname</code></em>,
 
-<VAR
-CLASS="PARAMETER"
->class</VAR
->,
+<em class="parameter"><code>class</code></em>,
 
 and
-<VAR
-CLASS="PARAMETER"
->type</VAR
->.
+<em class="parameter"><code>type</code></em>.
 
-<VAR
-CLASS="PARAMETER"
->hostname</VAR
->
+<em class="parameter"><code>hostname</code></em>
 is
 a pointer a to null-terminated string.  The
-<VAR
-CLASS="PARAMETER"
->flags</VAR
->
-field is currently unused and must be zero.</P
-><P
->After a successful call to
-<CODE
-CLASS="FUNCTION"
->lwres_getrrsetbyname()</CODE
->,
+<em class="parameter"><code>flags</code></em>
+field is currently unused and must be zero.
+</p>
+<p>
+After a successful call to
+<code class="function">lwres_getrrsetbyname()</code>,
 
-<VAR
-CLASS="PARAMETER"
->*res</VAR
->
+<em class="parameter"><code>*res</code></em>
 is a pointer to an
-<SPAN
-CLASS="TYPE"
->rrsetinfo</SPAN
->
+<span class="type">rrsetinfo</span>
 structure, containing a list of one or more
-<SPAN
-CLASS="TYPE"
->rdatainfo</SPAN
->
+<span class="type">rdatainfo</span>
 structures containing resource records and potentially another list of
-<SPAN
-CLASS="TYPE"
->rdatainfo</SPAN
->
+<span class="type">rdatainfo</span>
 structures containing SIG resource records
 associated with those records.
 The members
-<CODE
-CLASS="CONSTANT"
->rri_rdclass</CODE
->
+<code class="constant">rri_rdclass</code>
 and
-<CODE
-CLASS="CONSTANT"
->rri_rdtype</CODE
->
+<code class="constant">rri_rdtype</code>
 are copied from the parameters.
-<CODE
-CLASS="CONSTANT"
->rri_ttl</CODE
->
+<code class="constant">rri_ttl</code>
 and
-<CODE
-CLASS="CONSTANT"
->rri_name</CODE
->
+<code class="constant">rri_name</code>
 are properties of the obtained rrset.
 The resource records contained in
-<CODE
-CLASS="CONSTANT"
->rri_rdatas</CODE
->
+<code class="constant">rri_rdatas</code>
 and
-<CODE
-CLASS="CONSTANT"
->rri_sigs</CODE
->
+<code class="constant">rri_sigs</code>
 are in uncompressed DNS wire format.
 Properties of the rdataset are represented in the
-<CODE
-CLASS="CONSTANT"
->rri_flags</CODE
->
+<code class="constant">rri_flags</code>
 bitfield.  If the RRSET_VALIDATED bit is set, the data has been DNSSEC
-validated and the signatures verified.  </P
-><P
->All of the information returned by
-<CODE
-CLASS="FUNCTION"
->lwres_getrrsetbyname()</CODE
->
+validated and the signatures verified.  
+</p>
+<p>
+All of the information returned by
+<code class="function">lwres_getrrsetbyname()</code>
 is dynamically allocated: the
-<CODE
-CLASS="CONSTANT"
->rrsetinfo</CODE
->
+<code class="constant">rrsetinfo</code>
 and
-<CODE
-CLASS="CONSTANT"
->rdatainfo</CODE
->
+<code class="constant">rdatainfo</code>
 structures,
 and the canonical host name strings pointed to by the
-<CODE
-CLASS="CONSTANT"
->rrsetinfo</CODE
->structure.
+<code class="constant">rrsetinfo</code>structure.
 
 Memory allocated for the dynamically allocated structures created by
 a successful call to
-<CODE
-CLASS="FUNCTION"
->lwres_getrrsetbyname()</CODE
->
+<code class="function">lwres_getrrsetbyname()</code>
 is released by
-<CODE
-CLASS="FUNCTION"
->lwres_freerrset()</CODE
->.
+<code class="function">lwres_freerrset()</code>.
 
-<VAR
-CLASS="PARAMETER"
->rrset</VAR
->
+<em class="parameter"><code>rrset</code></em>
 is a pointer to a
-<SPAN
-CLASS="TYPE"
->struct rrset</SPAN
->
+<span class="type">struct rrset</span>
 created by a call to
-<CODE
-CLASS="FUNCTION"
->lwres_getrrsetbyname()</CODE
->.&#13;</P
-><P
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN62"
-></A
-><H2
->RETURN VALUES</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getrrsetbyname()</CODE
->
+<code class="function">lwres_getrrsetbyname()</code>.
+
+</p>
+<p>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526058"></a><h2>RETURN VALUES</h2>
+<p>
+<code class="function">lwres_getrrsetbyname()</code>
 returns zero on success, and one of the following error
 codes if an error occurred:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->ERRSET_NONAME</CODE
-></DT
-><DD
-><P
->the name does not exist</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ERRSET_NODATA</CODE
-></DT
-><DD
-><P
->the name exists, but does not have data of the desired type</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ERRSET_NOMEMORY</CODE
-></DT
-><DD
-><P
->memory could not be allocated</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ERRSET_INVAL</CODE
-></DT
-><DD
-><P
->a parameter is invalid</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->ERRSET_FAIL</CODE
-></DT
-><DD
-><P
->other failure</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
-></CODE
-></DT
-><DD
-><P
-></P
-></DD
-></DL
-></DIV
->&#13;</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN97"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres</SPAN
->(3)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">ERRSET_NONAME</code></span></dt>
+<dd><p>
+the name does not exist
+</p></dd>
+<dt><span class="term"><code class="constant">ERRSET_NODATA</code></span></dt>
+<dd><p>
+the name exists, but does not have data of the desired type
+</p></dd>
+<dt><span class="term"><code class="constant">ERRSET_NOMEMORY</code></span></dt>
+<dd><p>
+memory could not be allocated
+</p></dd>
+<dt><span class="term"><code class="constant">ERRSET_INVAL</code></span></dt>
+<dd><p>
+a parameter is invalid
+</p></dd>
+<dt><span class="term"><code class="constant">ERRSET_FAIL</code></span></dt>
+<dd><p>
+other failure
+</p></dd>
+<dt><span class="term"><code class="constant"></code></span></dt>
+<dd><p>
+</p></dd>
+</dl></div>
+<p>
+
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526132"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres</span>(3)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.3 b/contrib/bind9/lib/lwres/man/lwres_gnba.3
index 404ae4141b02..58047ce6b5dc 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gnba.3
+++ b/contrib/bind9/lib/lwres/man/lwres_gnba.3
@@ -1,86 +1,68 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gnba.3,v 1.13.2.1.8.1 2004/03/06 07:41:43 marka Exp $
+.\" $Id: lwres_gnba.3,v 1.13.2.1.8.5 2005/10/13 02:33:53 marka Exp $
 .\"
-.TH "LWRES_GNBA" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_GNBA" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_gnbarequest_render, lwres_gnbaresponse_render, lwres_gnbarequest_parse, lwres_gnbaresponse_parse, lwres_gnbaresponse_free, lwres_gnbarequest_free \- lightweight resolver getnamebyaddress message handling
-.SH SYNOPSIS
-\fB#include <lwres/lwres.h>
-.sp
-.na
-lwres_result_t
-lwres_gnbarequest_render(lwres_context_t *\fIctx\fB, lwres_gnbarequest_t *\fIreq\fB, lwres_lwpacket_t *\fIpkt\fB, lwres_buffer_t *\fIb\fB);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_gnbaresponse_render(lwres_context_t *ctx, lwres_gnbaresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_gnbarequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gnbarequest_t **structp);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_gnbaresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gnbaresponse_t **structp);
-.ad
-.sp
-.na
-void
-lwres_gnbaresponse_free(lwres_context_t *ctx, lwres_gnbaresponse_t **structp);
-.ad
-.sp
-.na
-void
-lwres_gnbarequest_free(lwres_context_t *ctx, lwres_gnbarequest_t **structp);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwres.h>
+.fi
+.HP 40
+\fBlwres_result_t\ \fBlwres_gnbarequest_render\fR\fR\fB(\fR\fBlwres_context_t\ *\fR\fB\fIctx\fR\fR\fB, \fR\fBlwres_gnbarequest_t\ *\fR\fB\fIreq\fR\fR\fB, \fR\fBlwres_lwpacket_t\ *\fR\fB\fIpkt\fR\fR\fB, \fR\fBlwres_buffer_t\ *\fR\fB\fIb\fR\fR\fB);\fR
+.HP 41
+\fBlwres_result_t\ \fBlwres_gnbaresponse_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gnbaresponse_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 39
+\fBlwres_result_t\ \fBlwres_gnbarequest_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_gnbarequest_t\ **structp\fR\fB);\fR
+.HP 40
+\fBlwres_result_t\ \fBlwres_gnbaresponse_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_gnbaresponse_t\ **structp\fR\fB);\fR
+.HP 29
+\fBvoid\ \fBlwres_gnbaresponse_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gnbaresponse_t\ **structp\fR\fB);\fR
+.HP 28
+\fBvoid\ \fBlwres_gnbarequest_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_gnbarequest_t\ **structp\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-These are low-level routines for creating and parsing
-lightweight resolver address-to-name lookup request and 
-response messages.
+These are low\-level routines for creating and parsing lightweight resolver address\-to\-name lookup request and response messages.
 .PP
-There are four main functions for the getnamebyaddr opcode.
-One render function converts a getnamebyaddr request structure \(em
-\fBlwres_gnbarequest_t\fR \(em
-to the lightweight resolver's canonical format.
-It is complemented by a parse function that converts a packet in this
-canonical format to a getnamebyaddr request structure.
-Another render function converts the getnamebyaddr response structure \(em
+There are four main functions for the getnamebyaddr opcode. One render function converts a getnamebyaddr request structure \(em
+\fBlwres_gnbarequest_t\fR
+\(em to the lightweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a getnamebyaddr request structure. Another render function converts the getnamebyaddr response structure \(em
 \fBlwres_gnbaresponse_t\fR
-to the canonical format.
-This is complemented by a parse function which converts a packet in
-canonical format to a getnamebyaddr response structure.
+to the canonical format. This is complemented by a parse function which converts a packet in canonical format to a getnamebyaddr response structure.
 .PP
 These structures are defined in
-\fIlwres/lwres.h\fR.
-They are shown below.
+\fIlwres/lwres.h\fR. They are shown below.
 .sp
 .nf
 #define LWRES_OPCODE_GETNAMEBYADDR      0x00010002U
-
 typedef struct {
         lwres_uint32_t  flags;
         lwres_addr_t    addr;
 } lwres_gnbarequest_t;
-
 typedef struct {
         lwres_uint32_t  flags;
         lwres_uint16_t  naliases;
@@ -91,22 +73,19 @@ typedef struct {
         void           *base;
         size_t          baselen;
 } lwres_gnbaresponse_t;
-.sp
 .fi
+.sp
 .PP
 \fBlwres_gnbarequest_render()\fR
 uses resolver context
-ctx
+\fIctx\fR
 to convert getnamebyaddr request structure
-req
-to canonical format.
-The packet header structure
-pkt
-is initialised and transferred to
-buffer
-b.
-The contents of
-*req
+\fIreq\fR
+to canonical format. The packet header structure
+\fIpkt\fR
+is initialised and transferred to buffer
+\fIb\fR. The contents of
+\fI*req\fR
 are then appended to the buffer in canonical format.
 \fBlwres_gnbaresponse_render()\fR
 performs the same task, except it converts a getnamebyaddr response structure
@@ -115,19 +94,17 @@ to the lightweight resolver's canonical format.
 .PP
 \fBlwres_gnbarequest_parse()\fR
 uses context
-ctx
+\fIctx\fR
 to convert the contents of packet
-pkt
+\fIpkt\fR
 to a
 \fBlwres_gnbarequest_t\fR
-structure.
-Buffer
-b
-provides space to be used for storing this structure.
-When the function succeeds, the resulting
+structure. Buffer
+\fIb\fR
+provides space to be used for storing this structure. When the function succeeds, the resulting
 \fBlwres_gnbarequest_t\fR
 is made available through
-*structp.
+\fI*structp\fR.
 \fBlwres_gnbaresponse_parse()\fR
 offers the same semantics as
 \fBlwres_gnbarequest_parse()\fR
@@ -139,32 +116,28 @@ structure.
 and
 \fBlwres_gnbarequest_free()\fR
 release the memory in resolver context
-ctx
+\fIctx\fR
 that was allocated to the
 \fBlwres_gnbaresponse_t\fR
 or
 \fBlwres_gnbarequest_t\fR
 structures referenced via
-structp.
-Any memory associated with ancillary buffers and strings for those
-structures is also discarded.
+\fIstructp\fR. Any memory associated with ancillary buffers and strings for those structures is also discarded.
 .SH "RETURN VALUES"
 .PP
 The getnamebyaddr opcode functions
 \fBlwres_gnbarequest_render()\fR,
-\fBlwres_gnbaresponse_render()\fR
-\fBlwres_gnbarequest_parse()\fR
+\fBlwres_gnbaresponse_render()\fR\fBlwres_gnbarequest_parse()\fR
 and
 \fBlwres_gnbaresponse_parse()\fR
 all return
-LWRES_R_SUCCESS
-on success.
-They return
-LWRES_R_NOMEMORY
+\fBLWRES_R_SUCCESS\fR
+on success. They return
+\fBLWRES_R_NOMEMORY\fR
 if memory allocation fails.
-LWRES_R_UNEXPECTEDEND
+\fBLWRES_R_UNEXPECTEDEND\fR
 is returned if the available space in the buffer
-b
+\fIb\fR
 is too small to accommodate the packet header or the
 \fBlwres_gnbarequest_t\fR
 and
@@ -174,12 +147,11 @@ structures.
 and
 \fBlwres_gnbaresponse_parse()\fR
 will return
-LWRES_R_UNEXPECTEDEND
-if the buffer is not empty after decoding the received packet.
-These functions will return
-LWRES_R_FAILURE
+\fBLWRES_R_UNEXPECTEDEND\fR
+if the buffer is not empty after decoding the received packet. These functions will return
+\fBLWRES_R_FAILURE\fR
 if
-\fBpktflags\fR
+pktflags
 in the packet header structure
 \fBlwres_lwpacket_t\fR
 indicate that the packet is not a response to an earlier query.
diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.docbook b/contrib/bind9/lib/lwres/man/lwres_gnba.docbook
index 5bd4172495a8..753148642efe 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gnba.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_gnba.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_gnba.docbook,v 1.4.206.1 2004/03/06 08:15:40 marka Exp $ -->
+<!-- $Id: lwres_gnba.docbook,v 1.4.206.3 2005/05/12 21:36:15 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,19 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_gnbarequest_render</refname>
 <refname>lwres_gnbaresponse_render</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.html b/contrib/bind9/lib/lwres/man/lwres_gnba.html
index 537b259377dc..89cf35e02c36 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gnba.html
+++ b/contrib/bind9/lib/lwres/man/lwres_gnba.html
@@ -1,158 +1,203 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_gnba.html,v 1.6.2.1.4.2 2004/08/22 23:39:04 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_gnba</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_gnba</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_gnbarequest_render, lwres_gnbaresponse_render, lwres_gnbarequest_parse, lwres_gnbaresponse_parse, lwres_gnbaresponse_free, lwres_gnbarequest_free&nbsp;--&nbsp;lightweight resolver getnamebyaddress message handling</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN16"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN17"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwres.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_gnbarequest_render</CODE
->(lwres_context_t *ctx, lwres_gnbarequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_gnbaresponse_render</CODE
->(lwres_context_t *ctx, lwres_gnbaresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_gnbarequest_parse</CODE
->(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gnbarequest_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_gnbaresponse_parse</CODE
->(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_gnbaresponse_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_gnbaresponse_free</CODE
->(lwres_context_t *ctx, lwres_gnbaresponse_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_gnbarequest_free</CODE
->(lwres_context_t *ctx, lwres_gnbarequest_t **structp);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN61"
-></A
-><H2
->DESCRIPTION</H2
-><P
->These are low-level routines for creating and parsing
+<!-- $Id: lwres_gnba.html,v 1.6.2.1.4.9 2005/10/13 02:33:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_gnba</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_gnbarequest_render, lwres_gnbaresponse_render, lwres_gnbarequest_parse, lwres_gnbaresponse_parse, lwres_gnbaresponse_free, lwres_gnbarequest_free &#8212; lightweight resolver getnamebyaddress message handling</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">
+#include &lt;lwres/lwres.h&gt;
+</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_gnbarequest_render</b>
+(</code></td>
+<td>lwres_context_t * </td>
+<td>
+<var class="pdparam">ctx</var>, </td>
+</tr>
+<tr>
+<td> </td>
+<td>lwres_gnbarequest_t * </td>
+<td>
+<var class="pdparam">req</var>, </td>
+</tr>
+<tr>
+<td> </td>
+<td>lwres_lwpacket_t * </td>
+<td>
+<var class="pdparam">pkt</var>, </td>
+</tr>
+<tr>
+<td> </td>
+<td>lwres_buffer_t * </td>
+<td>
+<var class="pdparam">b</var><code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_gnbaresponse_render</b>
+(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_gnbarequest_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_gnbaresponse_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_gnbaresponse_free</b>
+(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_gnbarequest_free</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525975"></a><h2>DESCRIPTION</h2>
+<p>
+These are low-level routines for creating and parsing
 lightweight resolver address-to-name lookup request and 
-response messages.</P
-><P
->There are four main functions for the getnamebyaddr opcode.
-One render function converts a getnamebyaddr request structure &mdash;
-<SPAN
-CLASS="TYPE"
->lwres_gnbarequest_t</SPAN
-> &mdash;
+response messages.
+</p>
+<p>
+There are four main functions for the getnamebyaddr opcode.
+One render function converts a getnamebyaddr request structure &#8212;
+<span class="type">lwres_gnbarequest_t</span> &#8212;
 to the lightweight resolver's canonical format.
 It is complemented by a parse function that converts a packet in this
 canonical format to a getnamebyaddr request structure.
-Another render function converts the getnamebyaddr response structure &mdash;
-<SPAN
-CLASS="TYPE"
->lwres_gnbaresponse_t</SPAN
->
+Another render function converts the getnamebyaddr response structure &#8212;
+<span class="type">lwres_gnbaresponse_t</span>
 to the canonical format.
 This is complemented by a parse function which converts a packet in
-canonical format to a getnamebyaddr response structure.</P
-><P
->These structures are defined in
-<TT
-CLASS="FILENAME"
->lwres/lwres.h</TT
->.
+canonical format to a getnamebyaddr response structure.
+</p>
+<p>
+These structures are defined in
+<code class="filename">lwres/lwres.h</code>.
 They are shown below.
-<PRE
-CLASS="PROGRAMLISTING"
->#define LWRES_OPCODE_GETNAMEBYADDR      0x00010002U
+</p>
+<pre class="programlisting">
+#define LWRES_OPCODE_GETNAMEBYADDR      0x00010002U
 
 typedef struct {
         lwres_uint32_t  flags;
@@ -168,242 +213,112 @@ typedef struct {
         lwres_uint16_t *aliaslen;
         void           *base;
         size_t          baselen;
-} lwres_gnbaresponse_t;</PRE
-></P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gnbarequest_render()</CODE
->
+} lwres_gnbaresponse_t;
+</pre>
+<p>
+</p>
+<p>
+<code class="function">lwres_gnbarequest_render()</code>
 uses resolver context
-<VAR
-CLASS="VARNAME"
->ctx</VAR
->
+<code class="varname">ctx</code>
 to convert getnamebyaddr request structure
-<VAR
-CLASS="VARNAME"
->req</VAR
->
+<code class="varname">req</code>
 to canonical format.
 The packet header structure
-<VAR
-CLASS="VARNAME"
->pkt</VAR
->
+<code class="varname">pkt</code>
 is initialised and transferred to
 buffer
-<VAR
-CLASS="VARNAME"
->b</VAR
->.
+<code class="varname">b</code>.
 The contents of
-<VAR
-CLASS="VARNAME"
->*req</VAR
->
+<code class="varname">*req</code>
 are then appended to the buffer in canonical format.
-<CODE
-CLASS="FUNCTION"
->lwres_gnbaresponse_render()</CODE
->
+<code class="function">lwres_gnbaresponse_render()</code>
 performs the same task, except it converts a getnamebyaddr response structure
-<SPAN
-CLASS="TYPE"
->lwres_gnbaresponse_t</SPAN
->
-to the lightweight resolver's canonical format.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gnbarequest_parse()</CODE
->
+<span class="type">lwres_gnbaresponse_t</span>
+to the lightweight resolver's canonical format.
+</p>
+<p>
+<code class="function">lwres_gnbarequest_parse()</code>
 uses context
-<VAR
-CLASS="VARNAME"
->ctx</VAR
->
+<code class="varname">ctx</code>
 to convert the contents of packet
-<VAR
-CLASS="VARNAME"
->pkt</VAR
->
+<code class="varname">pkt</code>
 to a
-<SPAN
-CLASS="TYPE"
->lwres_gnbarequest_t</SPAN
->
+<span class="type">lwres_gnbarequest_t</span>
 structure.
 Buffer
-<VAR
-CLASS="VARNAME"
->b</VAR
->
+<code class="varname">b</code>
 provides space to be used for storing this structure.
 When the function succeeds, the resulting
-<SPAN
-CLASS="TYPE"
->lwres_gnbarequest_t</SPAN
->
+<span class="type">lwres_gnbarequest_t</span>
 is made available through
-<VAR
-CLASS="VARNAME"
->*structp</VAR
->.
-<CODE
-CLASS="FUNCTION"
->lwres_gnbaresponse_parse()</CODE
->
+<code class="varname">*structp</code>.
+<code class="function">lwres_gnbaresponse_parse()</code>
 offers the same semantics as
-<CODE
-CLASS="FUNCTION"
->lwres_gnbarequest_parse()</CODE
->
+<code class="function">lwres_gnbarequest_parse()</code>
 except it yields a
-<SPAN
-CLASS="TYPE"
->lwres_gnbaresponse_t</SPAN
->
-structure.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_gnbaresponse_free()</CODE
->
+<span class="type">lwres_gnbaresponse_t</span>
+structure.
+</p>
+<p>
+<code class="function">lwres_gnbaresponse_free()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gnbarequest_free()</CODE
->
+<code class="function">lwres_gnbarequest_free()</code>
 release the memory in resolver context
-<VAR
-CLASS="VARNAME"
->ctx</VAR
->
+<code class="varname">ctx</code>
 that was allocated to the
-<SPAN
-CLASS="TYPE"
->lwres_gnbaresponse_t</SPAN
->
+<span class="type">lwres_gnbaresponse_t</span>
 or
-<SPAN
-CLASS="TYPE"
->lwres_gnbarequest_t</SPAN
->
+<span class="type">lwres_gnbarequest_t</span>
 structures referenced via
-<VAR
-CLASS="VARNAME"
->structp</VAR
->.
+<code class="varname">structp</code>.
 Any memory associated with ancillary buffers and strings for those
-structures is also discarded.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN97"
-></A
-><H2
->RETURN VALUES</H2
-><P
->The getnamebyaddr opcode functions
-<CODE
-CLASS="FUNCTION"
->lwres_gnbarequest_render()</CODE
->,
-<CODE
-CLASS="FUNCTION"
->lwres_gnbaresponse_render()</CODE
->
-<CODE
-CLASS="FUNCTION"
->lwres_gnbarequest_parse()</CODE
->
+structures is also discarded.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526100"></a><h2>RETURN VALUES</h2>
+<p>
+The getnamebyaddr opcode functions
+<code class="function">lwres_gnbarequest_render()</code>,
+<code class="function">lwres_gnbaresponse_render()</code>
+<code class="function">lwres_gnbarequest_parse()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gnbaresponse_parse()</CODE
->
+<code class="function">lwres_gnbaresponse_parse()</code>
 all return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
+<span class="errorcode">LWRES_R_SUCCESS</span>
 on success.
 They return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_NOMEMORY</SPAN
->
+<span class="errorcode">LWRES_R_NOMEMORY</span>
 if memory allocation fails.
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->
+<span class="errorcode">LWRES_R_UNEXPECTEDEND</span>
 is returned if the available space in the buffer
-<VAR
-CLASS="VARNAME"
->b</VAR
->
+<code class="varname">b</code>
 is too small to accommodate the packet header or the
-<SPAN
-CLASS="TYPE"
->lwres_gnbarequest_t</SPAN
->
+<span class="type">lwres_gnbarequest_t</span>
 and
-<SPAN
-CLASS="TYPE"
->lwres_gnbaresponse_t</SPAN
->
+<span class="type">lwres_gnbaresponse_t</span>
 structures.
-<CODE
-CLASS="FUNCTION"
->lwres_gnbarequest_parse()</CODE
->
+<code class="function">lwres_gnbarequest_parse()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_gnbaresponse_parse()</CODE
->
+<code class="function">lwres_gnbaresponse_parse()</code>
 will return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->
+<span class="errorcode">LWRES_R_UNEXPECTEDEND</span>
 if the buffer is not empty after decoding the received packet.
 These functions will return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_FAILURE</SPAN
->
+<span class="errorcode">LWRES_R_FAILURE</span>
 if
-<CODE
-CLASS="STRUCTFIELD"
->pktflags</CODE
->
+<em class="structfield"><code>pktflags</code></em>
 in the packet header structure
-<SPAN
-CLASS="TYPE"
->lwres_lwpacket_t</SPAN
->
-indicate that the packet is not a response to an earlier query.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN116"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_packet</SPAN
->(3)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+<span class="type">lwres_lwpacket_t</span>
+indicate that the packet is not a response to an earlier query.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526165"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres_packet</span>(3)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.3 b/contrib/bind9/lib/lwres/man/lwres_hstrerror.3
index 2260088e7750..a1ecf7c2071f 100644
--- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.3
+++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.3
@@ -1,67 +1,79 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_hstrerror.3,v 1.13.2.1.8.1 2004/03/06 07:41:43 marka Exp $
+.\" $Id: lwres_hstrerror.3,v 1.13.2.1.8.5 2005/10/13 02:33:53 marka Exp $
 .\"
-.TH "LWRES_HSTRERROR" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_HSTRERROR" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_herror, lwres_hstrerror \- lightweight resolver error message generation
-.SH SYNOPSIS
-\fB#include <lwres/netdb.h>
-.sp
-.na
-void
-lwres_herror(const char *s);
-.ad
-.sp
-.na
-const char *
-lwres_hstrerror(int err);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/netdb.h>
+.fi
+.HP 18
+\fBvoid\ \fBlwres_herror\fR\fR\fB(\fR\fBconst\ char\ *s\fR\fB);\fR
+.HP 29
+\fBconst\ char\ *\ \fBlwres_hstrerror\fR\fR\fB(\fR\fBint\ err\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-\fBlwres_herror()\fR prints the string
-\fIs\fR on \fBstderr\fR followed by the string
-generated by \fBlwres_hstrerror()\fR for the error code
-stored in the global variable lwres_h_errno.
+\fBlwres_herror()\fR
+prints the string
+\fIs\fR
+on
+\fBstderr\fR
+followed by the string generated by
+\fBlwres_hstrerror()\fR
+for the error code stored in the global variable
+\fBlwres_h_errno\fR.
 .PP
-\fBlwres_hstrerror()\fR returns an appropriate string
-for the error code gievn by \fIerr\fR. The values of
-the error codes and messages are as follows:
+\fBlwres_hstrerror()\fR
+returns an appropriate string for the error code gievn by
+\fIerr\fR. The values of the error codes and messages are as follows:
 .TP
 \fBNETDB_SUCCESS\fR
-\fBResolver Error 0 (no error)\fR
+Resolver Error 0 (no error)
 .TP
 \fBHOST_NOT_FOUND\fR
-\fBUnknown host\fR
+Unknown host
 .TP
 \fBTRY_AGAIN\fR
-\fBHost name lookup failure\fR
+Host name lookup failure
 .TP
 \fBNO_RECOVERY\fR
-\fBUnknown server error\fR
+Unknown server error
 .TP
 \fBNO_DATA\fR
-\fBNo address associated with name\fR
+No address associated with name
 .SH "RETURN VALUES"
 .PP
-The string \fBUnknown resolver error\fR is returned by
+The string
+Unknown resolver error
+is returned by
 \fBlwres_hstrerror()\fR
 when the value of
-lwres_h_errno
+\fBlwres_h_errno\fR
 is not a valid error code.
 .SH "SEE ALSO"
 .PP
diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook b/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook
index 2ad4c498e7e7..a36c072ef394 100644
--- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_hstrerror.docbook,v 1.4.206.1 2004/03/06 08:15:41 marka Exp $ -->
+<!-- $Id: lwres_hstrerror.docbook,v 1.4.206.3 2005/05/12 21:36:15 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,19 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_herror</refname>
 <refname>lwres_hstrerror</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.html b/contrib/bind9/lib/lwres/man/lwres_hstrerror.html
index 0c264af1ca01..4204a3365bd2 100644
--- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.html
+++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.html
@@ -1,241 +1,100 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_hstrerror.html,v 1.5.2.1.4.2 2004/08/22 23:39:04 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_hstrerror</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_hstrerror</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_herror, lwres_hstrerror&nbsp;--&nbsp;lightweight resolver error message generation</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN12"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN13"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/netdb.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_herror</CODE
->(const char *s);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->const char *
-lwres_hstrerror</CODE
->(int err);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN23"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_herror()</CODE
-> prints the string
-<VAR
-CLASS="PARAMETER"
->s</VAR
-> on <SPAN
-CLASS="TYPE"
->stderr</SPAN
-> followed by the string
-generated by <CODE
-CLASS="FUNCTION"
->lwres_hstrerror()</CODE
-> for the error code
-stored in the global variable <CODE
-CLASS="CONSTANT"
->lwres_h_errno</CODE
->.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_hstrerror()</CODE
-> returns an appropriate string
-for the error code gievn by <VAR
-CLASS="PARAMETER"
->err</VAR
->.  The values of
+<!-- $Id: lwres_hstrerror.html,v 1.5.2.1.4.9 2005/10/13 02:33:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_hstrerror</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_herror, lwres_hstrerror &#8212; lightweight resolver error message generation</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/netdb.h&gt;</pre>
+<p><code class="funcdef">
+void
+<b class="fsfunc">lwres_herror</b>(</code>const char *s<code>)</code>;</p>
+<p><code class="funcdef">
+const char *
+<b class="fsfunc">lwres_hstrerror</b>(</code>int err<code>)</code>;</p>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525859"></a><h2>DESCRIPTION</h2>
+<p>
+<code class="function">lwres_herror()</code> prints the string
+<em class="parameter"><code>s</code></em> on <span class="type">stderr</span> followed by the string
+generated by <code class="function">lwres_hstrerror()</code> for the error code
+stored in the global variable <code class="constant">lwres_h_errno</code>.
+</p>
+<p>
+<code class="function">lwres_hstrerror()</code> returns an appropriate string
+for the error code gievn by <em class="parameter"><code>err</code></em>.  The values of
 the error codes and messages are as follows:
 
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><SPAN
-CLASS="ERRORCODE"
->NETDB_SUCCESS</SPAN
-></DT
-><DD
-><P
-><SPAN
-CLASS="ERRORNAME"
->Resolver Error 0 (no error)</SPAN
-></P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->HOST_NOT_FOUND</SPAN
-></DT
-><DD
-><P
-><SPAN
-CLASS="ERRORNAME"
->Unknown host</SPAN
-></P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->TRY_AGAIN</SPAN
-></DT
-><DD
-><P
-><SPAN
-CLASS="ERRORNAME"
->Host name lookup failure</SPAN
-></P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->NO_RECOVERY</SPAN
-></DT
-><DD
-><P
-><SPAN
-CLASS="ERRORNAME"
->Unknown server error</SPAN
-></P
-></DD
-><DT
-><SPAN
-CLASS="ERRORCODE"
->NO_DATA</SPAN
-></DT
-><DD
-><P
-><SPAN
-CLASS="ERRORNAME"
->No address associated with name</SPAN
-></P
-></DD
-></DL
-></DIV
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN65"
-></A
-><H2
->RETURN VALUES</H2
-><P
->The string <SPAN
-CLASS="ERRORNAME"
->Unknown resolver error</SPAN
-> is returned by
-<CODE
-CLASS="FUNCTION"
->lwres_hstrerror()</CODE
->
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span class="errorcode">NETDB_SUCCESS</span></span></dt>
+<dd><p>
+<span class="errorname">Resolver Error 0 (no error)</span>
+</p></dd>
+<dt><span class="term"><span class="errorcode">HOST_NOT_FOUND</span></span></dt>
+<dd><p>
+<span class="errorname">Unknown host</span>
+</p></dd>
+<dt><span class="term"><span class="errorcode">TRY_AGAIN</span></span></dt>
+<dd><p>
+<span class="errorname">Host name lookup failure</span>
+</p></dd>
+<dt><span class="term"><span class="errorcode">NO_RECOVERY</span></span></dt>
+<dd><p>
+<span class="errorname">Unknown server error</span>
+</p></dd>
+<dt><span class="term"><span class="errorcode">NO_DATA</span></span></dt>
+<dd><p>
+<span class="errorname">No address associated with name</span>
+</p></dd>
+</dl></div>
+<p>
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525971"></a><h2>RETURN VALUES</h2>
+<p>
+The string <span class="errorname">Unknown resolver error</span> is returned by
+<code class="function">lwres_hstrerror()</code>
 when the value of
-<CODE
-CLASS="CONSTANT"
->lwres_h_errno</CODE
->
-is not a valid error code.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN71"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->herror</SPAN
->(3)</SPAN
->,
+<code class="constant">lwres_h_errno</code>
+is not a valid error code.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525990"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">herror</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_hstrerror</SPAN
->(3)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+<span class="citerefentry"><span class="refentrytitle">lwres_hstrerror</span>(3)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.3 b/contrib/bind9/lib/lwres/man/lwres_inetntop.3
index a4603c604b47..782cbafd2285 100644
--- a/contrib/bind9/lib/lwres/man/lwres_inetntop.3
+++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.3
@@ -1,54 +1,69 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_inetntop.3,v 1.12.2.1.8.1 2004/03/06 07:41:44 marka Exp $
+.\" $Id: lwres_inetntop.3,v 1.12.2.1.8.5 2005/10/13 02:33:53 marka Exp $
 .\"
-.TH "LWRES_INETNTOP" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_INETNTOP" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_net_ntop \- lightweight resolver IP address presentation
-.SH SYNOPSIS
-\fB#include <lwres/net.h>
-.sp
-.na
-const char *
-lwres_net_ntop(int af, const void *src, char *dst, size_t size);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/net.h>
+.fi
+.HP 28
+\fBconst\ char\ *\ \fBlwres_net_ntop\fR\fR\fB(\fR\fBint\ af\fR\fB, \fR\fBconst\ void\ *src\fR\fB, \fR\fBchar\ *dst\fR\fB, \fR\fBsize_t\ size\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-\fBlwres_net_ntop()\fR converts an IP address of
-protocol family \fIaf\fR \(em IPv4 or IPv6 \(em
-at location \fIsrc\fR from network format to its
-conventional representation as a string. For IPv4 addresses, that
-string would be a dotted-decimal. An IPv6 address would be
-represented in colon notation as described in RFC1884.
+\fBlwres_net_ntop()\fR
+converts an IP address of protocol family
+\fIaf\fR
+\(em IPv4 or IPv6 \(em at location
+\fIsrc\fR
+from network format to its conventional representation as a string. For IPv4 addresses, that string would be a dotted\-decimal. An IPv6 address would be represented in colon notation as described in RFC1884.
 .PP
-The generated string is copied to \fIdst\fR provided
-\fIsize\fR indicates it is long enough to store the
-ASCII representation of the address.
+The generated string is copied to
+\fIdst\fR
+provided
+\fIsize\fR
+indicates it is long enough to store the ASCII representation of the address.
 .SH "RETURN VALUES"
 .PP
-If successful, the function returns \fIdst\fR:
-a pointer to a string containing the presentation format of the
-address. \fBlwres_net_ntop()\fR returns
-\fBNULL\fR and sets the global variable
-errno to EAFNOSUPPORT if
-the protocol family given in \fIaf\fR is not
-supported.
+If successful, the function returns
+\fIdst\fR: a pointer to a string containing the presentation format of the address.
+\fBlwres_net_ntop()\fR
+returns
+\fBNULL\fR
+and sets the global variable
+\fBerrno\fR
+to
+\fBEAFNOSUPPORT\fR
+if the protocol family given in
+\fIaf\fR
+is not supported.
 .SH "SEE ALSO"
 .PP
-\fBRFC1884\fR,
+\fBRFC1884\fR(),
 \fBinet_ntop\fR(3),
 \fBerrno\fR(3).
diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook b/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook
index e771478bf5d1..651ef04d91bd 100644
--- a/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_inetntop.docbook,v 1.3.206.1 2004/03/06 08:15:41 marka Exp $ -->
+<!-- $Id: lwres_inetntop.docbook,v 1.3.206.3 2005/05/12 21:36:15 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,19 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_net_ntop</refname>
 <refpurpose>lightweight resolver IP address presentation</refpurpose>
diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.html b/contrib/bind9/lib/lwres/man/lwres_inetntop.html
index 345334547969..3c794a53b45b 100644
--- a/contrib/bind9/lib/lwres/man/lwres_inetntop.html
+++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.html
@@ -1,177 +1,98 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_inetntop.html,v 1.5.2.1.4.2 2004/08/22 23:39:05 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_inetntop</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_inetntop</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_net_ntop&nbsp;--&nbsp;lightweight resolver IP address presentation</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN11"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN12"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/net.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->const char *
-lwres_net_ntop</CODE
->(int af, const void *src, char *dst, size_t size);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN21"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_net_ntop()</CODE
-> converts an IP address of
-protocol family <VAR
-CLASS="PARAMETER"
->af</VAR
-> &mdash; IPv4 or IPv6 &mdash;
-at location <VAR
-CLASS="PARAMETER"
->src</VAR
-> from network format to its
+<!-- $Id: lwres_inetntop.html,v 1.5.2.1.4.9 2005/10/13 02:33:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_inetntop</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_net_ntop &#8212; lightweight resolver IP address presentation</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/net.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+const char *
+<b class="fsfunc">lwres_net_ntop</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525854"></a><h2>DESCRIPTION</h2>
+<p>
+<code class="function">lwres_net_ntop()</code> converts an IP address of
+protocol family <em class="parameter"><code>af</code></em> &#8212; IPv4 or IPv6 &#8212;
+at location <em class="parameter"><code>src</code></em> from network format to its
 conventional representation as a string.  For IPv4 addresses, that
 string would be a dotted-decimal.  An IPv6 address would be
-represented in colon notation as described in RFC1884.</P
-><P
->The generated string is copied to <VAR
-CLASS="PARAMETER"
->dst</VAR
-> provided
-<VAR
-CLASS="PARAMETER"
->size</VAR
-> indicates it is long enough to store the
-ASCII representation of the address.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN30"
-></A
-><H2
->RETURN VALUES</H2
-><P
->If successful, the function returns <VAR
-CLASS="PARAMETER"
->dst</VAR
->:
+represented in colon notation as described in RFC1884.
+</p>
+<p>
+The generated string is copied to <em class="parameter"><code>dst</code></em> provided
+<em class="parameter"><code>size</code></em> indicates it is long enough to store the
+ASCII representation of the address.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525888"></a><h2>RETURN VALUES</h2>
+<p>
+If successful, the function returns <em class="parameter"><code>dst</code></em>:
 a pointer to a string containing the presentation format of the
-address.  <CODE
-CLASS="FUNCTION"
->lwres_net_ntop()</CODE
-> returns
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
-> and sets the global variable
-<CODE
-CLASS="CONSTANT"
->errno</CODE
-> to <SPAN
-CLASS="ERRORCODE"
->EAFNOSUPPORT</SPAN
-> if
-the protocol family given in <VAR
-CLASS="PARAMETER"
->af</VAR
-> is not
-supported.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN39"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->RFC1884</SPAN
-></SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->inet_ntop</SPAN
->(3)</SPAN
->,
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->errno</SPAN
->(3)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+address.  <code class="function">lwres_net_ntop()</code> returns
+<span class="type">NULL</span> and sets the global variable
+<code class="constant">errno</code> to <span class="errorcode">EAFNOSUPPORT</span> if
+the protocol family given in <em class="parameter"><code>af</code></em> is not
+supported.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525918"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">RFC1884</span></span>,
+<span class="citerefentry"><span class="refentrytitle">inet_ntop</span>(3)</span>,
+<span class="citerefentry"><span class="refentrytitle">errno</span>(3)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.3 b/contrib/bind9/lib/lwres/man/lwres_noop.3
index 36bb90423d75..d2eba576591b 100644
--- a/contrib/bind9/lib/lwres/man/lwres_noop.3
+++ b/contrib/bind9/lib/lwres/man/lwres_noop.3
@@ -1,142 +1,140 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_noop.3,v 1.14.2.1.8.1 2004/03/06 07:41:44 marka Exp $
+.\" $Id: lwres_noop.3,v 1.14.2.1.8.5 2005/10/13 02:33:54 marka Exp $
 .\"
-.TH "LWRES_NOOP" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
-lwres_nooprequest_render, lwres_noopresponse_render, lwres_nooprequest_parse, lwres_noopresponse_parse, lwres_noopresponse_free, lwres_nooprequest_free \- lightweight resolver no-op message handling
-.SH SYNOPSIS
-\fB#include <lwres/lwres.h>
-.sp
-.na
-lwres_result_t
-lwres_nooprequest_render(lwres_context_t *ctx, lwres_nooprequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_noopresponse_render(lwres_context_t *ctx, lwres_noopresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_nooprequest_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_nooprequest_t **structp);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_noopresponse_parse(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_noopresponse_t **structp);
-.ad
-.sp
-.na
-void
-lwres_noopresponse_free(lwres_context_t *ctx, lwres_noopresponse_t **structp);
-.ad
-.sp
-.na
-void
-lwres_nooprequest_free(lwres_context_t *ctx, lwres_nooprequest_t **structp);
-.ad
-\fR
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_NOOP" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+lwres_nooprequest_render, lwres_noopresponse_render, lwres_nooprequest_parse, lwres_noopresponse_parse, lwres_noopresponse_free, lwres_nooprequest_free \- lightweight resolver no\-op message handling
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwres.h>
+.fi
+.HP 40
+\fBlwres_result_t\ \fBlwres_nooprequest_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_nooprequest_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 41
+\fBlwres_result_t\ \fBlwres_noopresponse_render\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_noopresponse_t\ *req\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB);\fR
+.HP 39
+\fBlwres_result_t\ \fBlwres_nooprequest_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_nooprequest_t\ **structp\fR\fB);\fR
+.HP 40
+\fBlwres_result_t\ \fBlwres_noopresponse_parse\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB, \fR\fBlwres_noopresponse_t\ **structp\fR\fB);\fR
+.HP 29
+\fBvoid\ \fBlwres_noopresponse_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_noopresponse_t\ **structp\fR\fB);\fR
+.HP 28
+\fBvoid\ \fBlwres_nooprequest_free\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_nooprequest_t\ **structp\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-These are low-level routines for creating and parsing
-lightweight resolver no-op request and response messages.
+These are low\-level routines for creating and parsing lightweight resolver no\-op request and response messages.
 .PP
-The no-op message is analogous to a \fBping\fR packet: 
-a packet is sent to the resolver daemon and is simply echoed back.
-The opcode is intended to allow a client to determine if the server is
-operational or not.
+The no\-op message is analogous to a
+\fBping\fR
+packet: a packet is sent to the resolver daemon and is simply echoed back. The opcode is intended to allow a client to determine if the server is operational or not.
 .PP
-There are four main functions for the no-op opcode.
-One render function converts a no-op request structure \(em
-\fBlwres_nooprequest_t\fR \(em
-to the lighweight resolver's canonical format.
-It is complemented by a parse function that converts a packet in this
-canonical format to a no-op request structure.
-Another render function converts the no-op response structure \(em
+There are four main functions for the no\-op opcode. One render function converts a no\-op request structure \(em
+\fBlwres_nooprequest_t\fR
+\(em to the lighweight resolver's canonical format. It is complemented by a parse function that converts a packet in this canonical format to a no\-op request structure. Another render function converts the no\-op response structure \(em
 \fBlwres_noopresponse_t\fR
-to the canonical format.
-This is complemented by a parse function which converts a packet in
-canonical format to a no-op response structure.
+to the canonical format. This is complemented by a parse function which converts a packet in canonical format to a no\-op response structure.
 .PP
 These structures are defined in
-\fIlwres/lwres.h\fR.
-They are shown below.
+\fIlwres/lwres.h\fR. They are shown below.
 .sp
 .nf
 #define LWRES_OPCODE_NOOP       0x00000000U
-
 typedef struct {
         lwres_uint16_t  datalength;
         unsigned char   *data;
 } lwres_nooprequest_t;
-
 typedef struct {
         lwres_uint16_t  datalength;
         unsigned char   *data;
 } lwres_noopresponse_t;
-.sp
 .fi
-Although the structures have different types, they are identical.
-This is because the no-op opcode simply echos whatever data was sent:
-the response is therefore identical to the request.
+.sp
+Although the structures have different types, they are identical. This is because the no\-op opcode simply echos whatever data was sent: the response is therefore identical to the request.
 .PP
-\fBlwres_nooprequest_render()\fR uses resolver
-context \fIctx\fR to convert no-op request structure
-\fIreq\fR to canonical format. The packet header
-structure \fIpkt\fR is initialised and transferred to
-buffer \fIb\fR. The contents of
-\fI*req\fR are then appended to the buffer in
-canonical format. \fBlwres_noopresponse_render()\fR
-performs the same task, except it converts a no-op response structure
-\fBlwres_noopresponse_t\fR to the lightweight resolver's
-canonical format.
+\fBlwres_nooprequest_render()\fR
+uses resolver context
+\fIctx\fR
+to convert no\-op request structure
+\fIreq\fR
+to canonical format. The packet header structure
+\fIpkt\fR
+is initialised and transferred to buffer
+\fIb\fR. The contents of
+\fI*req\fR
+are then appended to the buffer in canonical format.
+\fBlwres_noopresponse_render()\fR
+performs the same task, except it converts a no\-op response structure
+\fBlwres_noopresponse_t\fR
+to the lightweight resolver's canonical format.
 .PP
-\fBlwres_nooprequest_parse()\fR uses context
-\fIctx\fR to convert the contents of packet
-\fIpkt\fR to a \fBlwres_nooprequest_t\fR
-structure. Buffer \fIb\fR provides space to be used
-for storing this structure. When the function succeeds, the resulting
-\fBlwres_nooprequest_t\fR is made available through
+\fBlwres_nooprequest_parse()\fR
+uses context
+\fIctx\fR
+to convert the contents of packet
+\fIpkt\fR
+to a
+\fBlwres_nooprequest_t\fR
+structure. Buffer
+\fIb\fR
+provides space to be used for storing this structure. When the function succeeds, the resulting
+\fBlwres_nooprequest_t\fR
+is made available through
 \fI*structp\fR.
-\fBlwres_noopresponse_parse()\fR offers the same
-semantics as \fBlwres_nooprequest_parse()\fR except it
-yields a \fBlwres_noopresponse_t\fR structure.
+\fBlwres_noopresponse_parse()\fR
+offers the same semantics as
+\fBlwres_nooprequest_parse()\fR
+except it yields a
+\fBlwres_noopresponse_t\fR
+structure.
 .PP
-\fBlwres_noopresponse_free()\fR and
-\fBlwres_nooprequest_free()\fR release the memory in
-resolver context \fIctx\fR that was allocated to the
-\fBlwres_noopresponse_t\fR or \fBlwres_nooprequest_t\fR
-structures referenced via \fIstructp\fR.
+\fBlwres_noopresponse_free()\fR
+and
+\fBlwres_nooprequest_free()\fR
+release the memory in resolver context
+\fIctx\fR
+that was allocated to the
+\fBlwres_noopresponse_t\fR
+or
+\fBlwres_nooprequest_t\fR
+structures referenced via
+\fIstructp\fR.
 .SH "RETURN VALUES"
 .PP
-The no-op opcode functions
+The no\-op opcode functions
 \fBlwres_nooprequest_render()\fR,
-\fBlwres_noopresponse_render()\fR
-\fBlwres_nooprequest_parse()\fR
+\fBlwres_noopresponse_render()\fR\fBlwres_nooprequest_parse()\fR
 and
 \fBlwres_noopresponse_parse()\fR
 all return
-LWRES_R_SUCCESS
-on success.
-They return
-LWRES_R_NOMEMORY
+\fBLWRES_R_SUCCESS\fR
+on success. They return
+\fBLWRES_R_NOMEMORY\fR
 if memory allocation fails.
-LWRES_R_UNEXPECTEDEND
+\fBLWRES_R_UNEXPECTEDEND\fR
 is returned if the available space in the buffer
 \fIb\fR
 is too small to accommodate the packet header or the
@@ -148,15 +146,14 @@ structures.
 and
 \fBlwres_noopresponse_parse()\fR
 will return
-LWRES_R_UNEXPECTEDEND
-if the buffer is not empty after decoding the received packet.
-These functions will return
-LWRES_R_FAILURE
+\fBLWRES_R_UNEXPECTEDEND\fR
+if the buffer is not empty after decoding the received packet. These functions will return
+\fBLWRES_R_FAILURE\fR
 if
-pktflags
+\fBpktflags\fR
 in the packet header structure
 \fBlwres_lwpacket_t\fR
 indicate that the packet is not a response to an earlier query.
 .SH "SEE ALSO"
 .PP
-\fBlwres_packet\fR(3)
+\fBlwres_packet\fR(3 )
diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.docbook b/contrib/bind9/lib/lwres/man/lwres_noop.docbook
index dde2795c82d7..fcb3c5933ab7 100644
--- a/contrib/bind9/lib/lwres/man/lwres_noop.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_noop.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_noop.docbook,v 1.4.206.1 2004/03/06 08:15:41 marka Exp $ -->
+<!-- $Id: lwres_noop.docbook,v 1.4.206.3 2005/05/12 21:36:16 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,19 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_nooprequest_render</refname>
 <refname>lwres_noopresponse_render</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.html b/contrib/bind9/lib/lwres/man/lwres_noop.html
index 0962883d043e..261bac802f66 100644
--- a/contrib/bind9/lib/lwres/man/lwres_noop.html
+++ b/contrib/bind9/lib/lwres/man/lwres_noop.html
@@ -1,166 +1,202 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_noop.html,v 1.7.2.1.4.2 2004/08/22 23:39:05 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_noop</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_noop</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_nooprequest_render, lwres_noopresponse_render, lwres_nooprequest_parse, lwres_noopresponse_parse, lwres_noopresponse_free, lwres_nooprequest_free&nbsp;--&nbsp;lightweight resolver no-op message handling</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN16"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN17"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwres.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_nooprequest_render</CODE
->(lwres_context_t *ctx, lwres_nooprequest_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_noopresponse_render</CODE
->(lwres_context_t *ctx, lwres_noopresponse_t *req, lwres_lwpacket_t *pkt, lwres_buffer_t *b);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_nooprequest_parse</CODE
->(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_nooprequest_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_noopresponse_parse</CODE
->(lwres_context_t *ctx, lwres_buffer_t *b, lwres_lwpacket_t *pkt, lwres_noopresponse_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_noopresponse_free</CODE
->(lwres_context_t *ctx, lwres_noopresponse_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->void
-lwres_nooprequest_free</CODE
->(lwres_context_t *ctx, lwres_nooprequest_t **structp);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN57"
-></A
-><H2
->DESCRIPTION</H2
-><P
->These are low-level routines for creating and parsing
-lightweight resolver no-op request and response messages.</P
-><P
->The no-op message is analogous to a <B
-CLASS="COMMAND"
->ping</B
-> packet: 
+<!-- $Id: lwres_noop.html,v 1.7.2.1.4.9 2005/10/13 02:33:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_noop</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_nooprequest_render, lwres_noopresponse_render, lwres_nooprequest_parse, lwres_noopresponse_parse, lwres_noopresponse_free, lwres_nooprequest_free &#8212; lightweight resolver no-op message handling</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">
+#include &lt;lwres/lwres.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_nooprequest_render</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_noopresponse_render</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_nooprequest_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_noopresponse_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_noopresponse_free</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+void
+<b class="fsfunc">lwres_nooprequest_free</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525963"></a><h2>DESCRIPTION</h2>
+<p>
+These are low-level routines for creating and parsing
+lightweight resolver no-op request and response messages.
+</p>
+<p>
+The no-op message is analogous to a <span><strong class="command">ping</strong></span> packet: 
 a packet is sent to the resolver daemon and is simply echoed back.
 The opcode is intended to allow a client to determine if the server is
-operational or not.</P
-><P
->There are four main functions for the no-op opcode.
-One render function converts a no-op request structure &mdash;
-<SPAN
-CLASS="TYPE"
->lwres_nooprequest_t</SPAN
-> &mdash;
+operational or not.
+</p>
+<p>
+There are four main functions for the no-op opcode.
+One render function converts a no-op request structure &#8212;
+<span class="type">lwres_nooprequest_t</span> &#8212;
 to the lighweight resolver's canonical format.
 It is complemented by a parse function that converts a packet in this
 canonical format to a no-op request structure.
-Another render function converts the no-op response structure &mdash;
-<SPAN
-CLASS="TYPE"
->lwres_noopresponse_t</SPAN
->
+Another render function converts the no-op response structure &#8212;
+<span class="type">lwres_noopresponse_t</span>
 to the canonical format.
 This is complemented by a parse function which converts a packet in
-canonical format to a no-op response structure.</P
-><P
->These structures are defined in
-<TT
-CLASS="FILENAME"
->lwres/lwres.h</TT
->.
+canonical format to a no-op response structure.
+</p>
+<p>
+These structures are defined in
+<code class="filename">lwres/lwres.h</code>.
 
 They are shown below.
-<PRE
-CLASS="PROGRAMLISTING"
->#define LWRES_OPCODE_NOOP       0x00000000U
+</p>
+<pre class="programlisting">
+#define LWRES_OPCODE_NOOP       0x00000000U
 
 typedef struct {
         lwres_uint16_t  datalength;
@@ -170,219 +206,90 @@ typedef struct {
 typedef struct {
         lwres_uint16_t  datalength;
         unsigned char   *data;
-} lwres_noopresponse_t;</PRE
->
+} lwres_noopresponse_t;
+</pre>
+<p>
 Although the structures have different types, they are identical.
 This is because the no-op opcode simply echos whatever data was sent:
-the response is therefore identical to the request.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_nooprequest_render()</CODE
-> uses resolver
-context <VAR
-CLASS="PARAMETER"
->ctx</VAR
-> to convert no-op request structure
-<VAR
-CLASS="PARAMETER"
->req</VAR
-> to canonical format.  The packet header
-structure <VAR
-CLASS="PARAMETER"
->pkt</VAR
-> is initialised and transferred to
-buffer <VAR
-CLASS="PARAMETER"
->b</VAR
->.  The contents of
-<VAR
-CLASS="PARAMETER"
->*req</VAR
-> are then appended to the buffer in
-canonical format.  <CODE
-CLASS="FUNCTION"
->lwres_noopresponse_render()</CODE
->
+the response is therefore identical to the request.
+</p>
+<p>
+<code class="function">lwres_nooprequest_render()</code> uses resolver
+context <em class="parameter"><code>ctx</code></em> to convert no-op request structure
+<em class="parameter"><code>req</code></em> to canonical format.  The packet header
+structure <em class="parameter"><code>pkt</code></em> is initialised and transferred to
+buffer <em class="parameter"><code>b</code></em>.  The contents of
+<em class="parameter"><code>*req</code></em> are then appended to the buffer in
+canonical format.  <code class="function">lwres_noopresponse_render()</code>
 performs the same task, except it converts a no-op response structure
-<SPAN
-CLASS="TYPE"
->lwres_noopresponse_t</SPAN
-> to the lightweight resolver's
-canonical format.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_nooprequest_parse()</CODE
-> uses context
-<VAR
-CLASS="PARAMETER"
->ctx</VAR
-> to convert the contents of packet
-<VAR
-CLASS="PARAMETER"
->pkt</VAR
-> to a <SPAN
-CLASS="TYPE"
->lwres_nooprequest_t</SPAN
->
-structure.  Buffer <VAR
-CLASS="PARAMETER"
->b</VAR
-> provides space to be used
+<span class="type">lwres_noopresponse_t</span> to the lightweight resolver's
+canonical format.
+</p>
+<p>
+<code class="function">lwres_nooprequest_parse()</code> uses context
+<em class="parameter"><code>ctx</code></em> to convert the contents of packet
+<em class="parameter"><code>pkt</code></em> to a <span class="type">lwres_nooprequest_t</span>
+structure.  Buffer <em class="parameter"><code>b</code></em> provides space to be used
 for storing this structure.  When the function succeeds, the resulting
-<SPAN
-CLASS="TYPE"
->lwres_nooprequest_t</SPAN
-> is made available through
-<VAR
-CLASS="PARAMETER"
->*structp</VAR
->.
-<CODE
-CLASS="FUNCTION"
->lwres_noopresponse_parse()</CODE
-> offers the same
-semantics as <CODE
-CLASS="FUNCTION"
->lwres_nooprequest_parse()</CODE
-> except it
-yields a <SPAN
-CLASS="TYPE"
->lwres_noopresponse_t</SPAN
-> structure.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_noopresponse_free()</CODE
-> and
-<CODE
-CLASS="FUNCTION"
->lwres_nooprequest_free()</CODE
-> release the memory in
-resolver context <VAR
-CLASS="PARAMETER"
->ctx</VAR
-> that was allocated to the
-<SPAN
-CLASS="TYPE"
->lwres_noopresponse_t</SPAN
-> or <SPAN
-CLASS="TYPE"
->lwres_nooprequest_t</SPAN
->
-structures referenced via <VAR
-CLASS="PARAMETER"
->structp</VAR
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN95"
-></A
-><H2
->RETURN VALUES</H2
-><P
->The no-op opcode functions
-<CODE
-CLASS="FUNCTION"
->lwres_nooprequest_render()</CODE
->,
+<span class="type">lwres_nooprequest_t</span> is made available through
+<em class="parameter"><code>*structp</code></em>.
+<code class="function">lwres_noopresponse_parse()</code> offers the same
+semantics as <code class="function">lwres_nooprequest_parse()</code> except it
+yields a <span class="type">lwres_noopresponse_t</span> structure.
+</p>
+<p>
+<code class="function">lwres_noopresponse_free()</code> and
+<code class="function">lwres_nooprequest_free()</code> release the memory in
+resolver context <em class="parameter"><code>ctx</code></em> that was allocated to the
+<span class="type">lwres_noopresponse_t</span> or <span class="type">lwres_nooprequest_t</span>
+structures referenced via <em class="parameter"><code>structp</code></em>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526096"></a><h2>RETURN VALUES</h2>
+<p>
+The no-op opcode functions
+<code class="function">lwres_nooprequest_render()</code>,
 
-<CODE
-CLASS="FUNCTION"
->lwres_noopresponse_render()</CODE
->
-<CODE
-CLASS="FUNCTION"
->lwres_nooprequest_parse()</CODE
->
+<code class="function">lwres_noopresponse_render()</code>
+<code class="function">lwres_nooprequest_parse()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_noopresponse_parse()</CODE
->
+<code class="function">lwres_noopresponse_parse()</code>
 all return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
+<span class="errorcode">LWRES_R_SUCCESS</span>
 on success.
 They return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_NOMEMORY</SPAN
->
+<span class="errorcode">LWRES_R_NOMEMORY</span>
 if memory allocation fails.
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->
+<span class="errorcode">LWRES_R_UNEXPECTEDEND</span>
 is returned if the available space in the buffer
-<VAR
-CLASS="PARAMETER"
->b</VAR
->
+<em class="parameter"><code>b</code></em>
 is too small to accommodate the packet header or the
-<SPAN
-CLASS="TYPE"
->lwres_nooprequest_t</SPAN
->
+<span class="type">lwres_nooprequest_t</span>
 and
-<SPAN
-CLASS="TYPE"
->lwres_noopresponse_t</SPAN
->
+<span class="type">lwres_noopresponse_t</span>
 structures.
-<CODE
-CLASS="FUNCTION"
->lwres_nooprequest_parse()</CODE
->
+<code class="function">lwres_nooprequest_parse()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_noopresponse_parse()</CODE
->
+<code class="function">lwres_noopresponse_parse()</code>
 will return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->
+<span class="errorcode">LWRES_R_UNEXPECTEDEND</span>
 if the buffer is not empty after decoding the received packet.
 These functions will return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_FAILURE</SPAN
->
+<span class="errorcode">LWRES_R_FAILURE</span>
 if
-<CODE
-CLASS="CONSTANT"
->pktflags</CODE
->
+<code class="constant">pktflags</code>
 in the packet header structure
-<SPAN
-CLASS="TYPE"
->lwres_lwpacket_t</SPAN
->
-indicate that the packet is not a response to an earlier query.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN114"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_packet</SPAN
->(3)</SPAN
-></P
-></DIV
-></BODY
-></HTML
->
+<span class="type">lwres_lwpacket_t</span>
+indicate that the packet is not a response to an earlier query.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526160"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres_packet</span>(3
+)</span>
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.3 b/contrib/bind9/lib/lwres/man/lwres_packet.3
index 1fbc417e45ef..777e0c76eed8 100644
--- a/contrib/bind9/lib/lwres/man/lwres_packet.3
+++ b/contrib/bind9/lib/lwres/man/lwres_packet.3
@@ -1,36 +1,41 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_packet.3,v 1.15.2.1.8.1 2004/03/06 07:41:44 marka Exp $
+.\" $Id: lwres_packet.3,v 1.15.2.1.8.5 2005/10/13 02:33:54 marka Exp $
 .\"
-.TH "LWRES_PACKET" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_PACKET" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_lwpacket_renderheader, lwres_lwpacket_parseheader \- lightweight resolver packet handling functions
-.SH SYNOPSIS
-\fB#include <lwres/lwpacket.h>
-.sp
-.na
-lwres_result_t
-lwres_lwpacket_renderheader(lwres_buffer_t *b, lwres_lwpacket_t *pkt);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_lwpacket_parseheader(lwres_buffer_t *b, lwres_lwpacket_t *pkt);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwpacket.h>
+.fi
+.HP 43
+\fBlwres_result_t\ \fBlwres_lwpacket_renderheader\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB);\fR
+.HP 42
+\fBlwres_result_t\ \fBlwres_lwpacket_parseheader\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_lwpacket_t\ *pkt\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
 These functions rely on a
@@ -40,7 +45,6 @@ which is defined in
 .sp
 .nf
 typedef struct lwres_lwpacket lwres_lwpacket_t;
-
 struct lwres_lwpacket {
         lwres_uint32_t          length;
         lwres_uint16_t          version;
@@ -52,100 +56,74 @@ struct lwres_lwpacket {
         lwres_uint16_t          authtype;
         lwres_uint16_t          authlength;
 };
-.sp
 .fi
+.sp
 .PP
 The elements of this structure are:
 .TP
 \fBlength\fR
-the overall packet length, including the entire packet header.
-This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
-calls.
+the overall packet length, including the entire packet header. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls.
 .TP
 \fBversion\fR
 the header format. There is currently only one format,
-\fBLWRES_LWPACKETVERSION_0\fR.
-This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
-calls.
+\fBLWRES_LWPACKETVERSION_0\fR. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls.
 .TP
 \fBpktflags\fR
-library-defined flags for this packet: for instance whether the packet
-is a request or a reply. Flag values can be set, but not defined by
-the caller.
-This field is filled in by the application wit the exception of the
-LWRES_LWPACKETFLAG_RESPONSE bit, which is set by the library in the
-lwres_gabn_*() and lwres_gnba_*() calls.
+library\-defined flags for this packet: for instance whether the packet is a request or a reply. Flag values can be set, but not defined by the caller. This field is filled in by the application wit the exception of the LWRES_LWPACKETFLAG_RESPONSE bit, which is set by the library in the lwres_gabn_*() and lwres_gnba_*() calls.
 .TP
 \fBserial\fR
-is set by the requestor and is returned in all replies. If two or more
-packets from the same source have the same serial number and are from
-the same source, they are assumed to be duplicates and the latter ones
-may be dropped.
-This field must be set by the application.
+is set by the requestor and is returned in all replies. If two or more packets from the same source have the same serial number and are from the same source, they are assumed to be duplicates and the latter ones may be dropped. This field must be set by the application.
 .TP
 \fBopcode\fR
-indicates the operation.
-Opcodes between 0x00000000 and 0x03ffffff are
-reserved for use by the lightweight resolver library. Opcodes between
-0x04000000 and 0xffffffff are application defined.
-This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
-calls.
+indicates the operation. Opcodes between 0x00000000 and 0x03ffffff are reserved for use by the lightweight resolver library. Opcodes between 0x04000000 and 0xffffffff are application defined. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls.
 .TP
 \fBresult\fR
-is only valid for replies.
-Results between 0x04000000 and 0xffffffff are application defined.
-Results between 0x00000000 and 0x03ffffff are reserved for library use.
-This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
-calls.
+is only valid for replies. Results between 0x04000000 and 0xffffffff are application defined. Results between 0x00000000 and 0x03ffffff are reserved for library use. This field is filled in by the lwres_gabn_*() and lwres_gnba_*() calls.
 .TP
 \fBrecvlength\fR
-is the maximum buffer size that the receiver can handle on requests
-and the size of the buffer needed to satisfy a request when the buffer
-is too large for replies.
-This field is supplied by the application.
+is the maximum buffer size that the receiver can handle on requests and the size of the buffer needed to satisfy a request when the buffer is too large for replies. This field is supplied by the application.
 .TP
 \fBauthtype\fR
-defines the packet level authentication that is used.
-Authorisation types between 0x1000 and 0xffff are application defined
-and types between 0x0000 and 0x0fff are reserved for library use.
-Currently these are not used and must be zero.
+defines the packet level authentication that is used. Authorisation types between 0x1000 and 0xffff are application defined and types between 0x0000 and 0x0fff are reserved for library use. Currently these are not used and must be zero.
 .TP
 \fBauthlen\fR
-gives the length of the authentication data.
-Since packet authentication is currently not used, this must be zero.
+gives the length of the authentication data. Since packet authentication is currently not used, this must be zero.
 .PP
 The following opcodes are currently defined:
 .TP
 \fBNOOP\fR
-Success is always returned and the packet contents are echoed.
-The lwres_noop_*() functions should be used for this type.
+Success is always returned and the packet contents are echoed. The lwres_noop_*() functions should be used for this type.
 .TP
 \fBGETADDRSBYNAME\fR
-returns all known addresses for a given name.
-The lwres_gabn_*() functions should be used for this type.
+returns all known addresses for a given name. The lwres_gabn_*() functions should be used for this type.
 .TP
 \fBGETNAMEBYADDR\fR
-return the hostname for the given address.
-The lwres_gnba_*() functions should be used for this type.
+return the hostname for the given address. The lwres_gnba_*() functions should be used for this type.
 .PP
-\fBlwres_lwpacket_renderheader()\fR transfers the
-contents of lightweight resolver packet structure
-\fBlwres_lwpacket_t\fR \fI*pkt\fR in network
-byte order to the lightweight resolver buffer,
+\fBlwres_lwpacket_renderheader()\fR
+transfers the contents of lightweight resolver packet structure
+\fBlwres_lwpacket_t\fR\fI*pkt\fR
+in network byte order to the lightweight resolver buffer,
 \fI*b\fR.
 .PP
-\fBlwres_lwpacket_parseheader()\fR performs the
-converse operation. It transfers data in network byte order from
-buffer \fI*b\fR to resolver packet
+\fBlwres_lwpacket_parseheader()\fR
+performs the converse operation. It transfers data in network byte order from buffer
+\fI*b\fR
+to resolver packet
 \fI*pkt\fR. The contents of the buffer
-\fIb\fR should correspond to a
+\fIb\fR
+should correspond to a
 \fBlwres_lwpacket_t\fR.
 .SH "RETURN VALUES"
 .PP
 Successful calls to
-\fBlwres_lwpacket_renderheader()\fR and
-\fBlwres_lwpacket_parseheader()\fR return
-LWRES_R_SUCCESS. If there is insufficient
-space to copy data between the buffer \fI*b\fR and
-lightweight resolver packet \fI*pkt\fR both functions
-return LWRES_R_UNEXPECTEDEND.
+\fBlwres_lwpacket_renderheader()\fR
+and
+\fBlwres_lwpacket_parseheader()\fR
+return
+\fBLWRES_R_SUCCESS\fR. If there is insufficient space to copy data between the buffer
+\fI*b\fR
+and lightweight resolver packet
+\fI*pkt\fR
+both functions return
+\fBLWRES_R_UNEXPECTEDEND\fR.
diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.docbook b/contrib/bind9/lib/lwres/man/lwres_packet.docbook
index 7795ebc75516..226f9942c9ae 100644
--- a/contrib/bind9/lib/lwres/man/lwres_packet.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_packet.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_packet.docbook,v 1.6.206.1 2004/03/06 08:15:42 marka Exp $ -->
+<!-- $Id: lwres_packet.docbook,v 1.6.206.3 2005/05/12 21:36:16 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,19 @@
 <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_lwpacket_renderheader</refname>
 <refname>lwres_lwpacket_parseheader</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.html b/contrib/bind9/lib/lwres/man/lwres_packet.html
index cb61e0a48318..b83fbcbf1b5b 100644
--- a/contrib/bind9/lib/lwres/man/lwres_packet.html
+++ b/contrib/bind9/lib/lwres/man/lwres_packet.html
@@ -1,109 +1,79 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_packet.html,v 1.8.2.1.4.2 2004/08/22 23:39:05 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_packet</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_packet</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_lwpacket_renderheader, lwres_lwpacket_parseheader&nbsp;--&nbsp;lightweight resolver packet handling functions</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN12"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN13"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwpacket.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_lwpacket_renderheader</CODE
->(lwres_buffer_t *b, lwres_lwpacket_t *pkt);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_lwpacket_parseheader</CODE
->(lwres_buffer_t *b, lwres_lwpacket_t *pkt);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN25"
-></A
-><H2
->DESCRIPTION</H2
-><P
->These functions rely on a
-<SPAN
-CLASS="TYPE"
->struct lwres_lwpacket</SPAN
->
+<!-- $Id: lwres_packet.html,v 1.8.2.1.4.9 2005/10/13 02:33:57 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_packet</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_lwpacket_renderheader, lwres_lwpacket_parseheader &#8212; lightweight resolver packet handling functions</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/lwpacket.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_lwpacket_renderheader</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_lwpacket_parseheader</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525865"></a><h2>DESCRIPTION</h2>
+<p>
+These functions rely on a
+<span class="type">struct lwres_lwpacket</span>
 which is defined in
-<TT
-CLASS="FILENAME"
->lwres/lwpacket.h</TT
->.
+<code class="filename">lwres/lwpacket.h</code>.
 
-<PRE
-CLASS="PROGRAMLISTING"
->typedef struct lwres_lwpacket lwres_lwpacket_t;
+</p>
+<pre class="programlisting">
+typedef struct lwres_lwpacket lwres_lwpacket_t;
 
 struct lwres_lwpacket {
         lwres_uint32_t          length;
@@ -115,248 +85,132 @@ struct lwres_lwpacket {
         lwres_uint32_t          recvlength;
         lwres_uint16_t          authtype;
         lwres_uint16_t          authlength;
-};</PRE
-></P
-><P
->The elements of this structure are:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->length</CODE
-></DT
-><DD
-><P
->the overall packet length, including the entire packet header.
+};
+</pre>
+<p>
+</p>
+<p>
+The elements of this structure are:
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">length</code></span></dt>
+<dd><p>
+the overall packet length, including the entire packet header.
 This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
-calls.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->version</CODE
-></DT
-><DD
-><P
->the header format. There is currently only one format,
-<SPAN
-CLASS="TYPE"
->LWRES_LWPACKETVERSION_0</SPAN
->.
+calls.
+</p></dd>
+<dt><span class="term"><code class="constant">version</code></span></dt>
+<dd><p>
+the header format. There is currently only one format,
+<span class="type">LWRES_LWPACKETVERSION_0</span>.
 
 This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
-calls.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->pktflags</CODE
-></DT
-><DD
-><P
->library-defined flags for this packet: for instance whether the packet
+calls.
+</p></dd>
+<dt><span class="term"><code class="constant">pktflags</code></span></dt>
+<dd><p>
+library-defined flags for this packet: for instance whether the packet
 is a request or a reply. Flag values can be set, but not defined by
 the caller.
 This field is filled in by the application wit the exception of the
 LWRES_LWPACKETFLAG_RESPONSE bit, which is set by the library in the
-lwres_gabn_*() and lwres_gnba_*() calls.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->serial</CODE
-></DT
-><DD
-><P
->is set by the requestor and is returned in all replies. If two or more
+lwres_gabn_*() and lwres_gnba_*() calls.
+</p></dd>
+<dt><span class="term"><code class="constant">serial</code></span></dt>
+<dd><p>
+is set by the requestor and is returned in all replies. If two or more
 packets from the same source have the same serial number and are from
 the same source, they are assumed to be duplicates and the latter ones
 may be dropped.
-This field must be set by the application.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->opcode</CODE
-></DT
-><DD
-><P
->indicates the operation.
+This field must be set by the application.
+</p></dd>
+<dt><span class="term"><code class="constant">opcode</code></span></dt>
+<dd><p>
+indicates the operation.
 Opcodes between 0x00000000 and 0x03ffffff are
 reserved for use by the lightweight resolver library. Opcodes between
 0x04000000 and 0xffffffff are application defined.
 This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
-calls.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->result</CODE
-></DT
-><DD
-><P
->is only valid for replies.
+calls.
+</p></dd>
+<dt><span class="term"><code class="constant">result</code></span></dt>
+<dd><p>
+is only valid for replies.
 Results between 0x04000000 and 0xffffffff are application defined.
 Results between 0x00000000 and 0x03ffffff are reserved for library use.
 This field is filled in by the lwres_gabn_*() and lwres_gnba_*()
-calls.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->recvlength</CODE
-></DT
-><DD
-><P
->is the maximum buffer size that the receiver can handle on requests
+calls.
+</p></dd>
+<dt><span class="term"><code class="constant">recvlength</code></span></dt>
+<dd><p>
+is the maximum buffer size that the receiver can handle on requests
 and the size of the buffer needed to satisfy a request when the buffer
 is too large for replies.
-This field is supplied by the application.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->authtype</CODE
-></DT
-><DD
-><P
->defines the packet level authentication that is used.
+This field is supplied by the application.
+</p></dd>
+<dt><span class="term"><code class="constant">authtype</code></span></dt>
+<dd><p>
+defines the packet level authentication that is used.
 Authorisation types between 0x1000 and 0xffff are application defined
 and types between 0x0000 and 0x0fff are reserved for library use.
-Currently these are not used and must be zero.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->authlen</CODE
-></DT
-><DD
-><P
->gives the length of the authentication data.
-Since packet authentication is currently not used, this must be zero.</P
-></DD
-></DL
-></DIV
-></P
-><P
->The following opcodes are currently defined:
-<P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><CODE
-CLASS="CONSTANT"
->NOOP</CODE
-></DT
-><DD
-><P
->Success is always returned and the packet contents are echoed.
-The lwres_noop_*() functions should be used for this type.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->GETADDRSBYNAME</CODE
-></DT
-><DD
-><P
->returns all known addresses for a given name.
-The lwres_gabn_*() functions should be used for this type.</P
-></DD
-><DT
-><CODE
-CLASS="CONSTANT"
->GETNAMEBYADDR</CODE
-></DT
-><DD
-><P
->return the hostname for the given address.
-The lwres_gnba_*() functions should be used for this type.</P
-></DD
-></DL
-></DIV
-></P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_lwpacket_renderheader()</CODE
-> transfers the
+Currently these are not used and must be zero.
+</p></dd>
+<dt><span class="term"><code class="constant">authlen</code></span></dt>
+<dd><p>
+gives the length of the authentication data.
+Since packet authentication is currently not used, this must be zero.
+</p></dd>
+</dl></div>
+<p>
+</p>
+<p>
+The following opcodes are currently defined:
+</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><code class="constant">NOOP</code></span></dt>
+<dd><p>
+Success is always returned and the packet contents are echoed.
+The lwres_noop_*() functions should be used for this type.
+</p></dd>
+<dt><span class="term"><code class="constant">GETADDRSBYNAME</code></span></dt>
+<dd><p>
+returns all known addresses for a given name.
+The lwres_gabn_*() functions should be used for this type.
+</p></dd>
+<dt><span class="term"><code class="constant">GETNAMEBYADDR</code></span></dt>
+<dd><p>
+return the hostname for the given address.
+The lwres_gnba_*() functions should be used for this type.
+</p></dd>
+</dl></div>
+<p>
+</p>
+<p>
+<code class="function">lwres_lwpacket_renderheader()</code> transfers the
 contents of lightweight resolver packet structure
-<SPAN
-CLASS="TYPE"
->lwres_lwpacket_t</SPAN
-> <VAR
-CLASS="PARAMETER"
->*pkt</VAR
-> in network
+<span class="type">lwres_lwpacket_t</span> <em class="parameter"><code>*pkt</code></em> in network
 byte order to the lightweight resolver buffer,
-<VAR
-CLASS="PARAMETER"
->*b</VAR
->.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_lwpacket_parseheader()</CODE
-> performs the
+<em class="parameter"><code>*b</code></em>.
+</p>
+<p>
+<code class="function">lwres_lwpacket_parseheader()</code> performs the
 converse operation.  It transfers data in network byte order from
-buffer <VAR
-CLASS="PARAMETER"
->*b</VAR
-> to resolver packet
-<VAR
-CLASS="PARAMETER"
->*pkt</VAR
->.  The contents of the buffer
-<VAR
-CLASS="PARAMETER"
->b</VAR
-> should correspond to a
-<SPAN
-CLASS="TYPE"
->lwres_lwpacket_t</SPAN
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN107"
-></A
-><H2
->RETURN VALUES</H2
-><P
-> Successful calls to
-<CODE
-CLASS="FUNCTION"
->lwres_lwpacket_renderheader()</CODE
-> and
-<CODE
-CLASS="FUNCTION"
->lwres_lwpacket_parseheader()</CODE
-> return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->.  If there is insufficient
-space to copy data between the buffer <VAR
-CLASS="PARAMETER"
->*b</VAR
-> and
-lightweight resolver packet <VAR
-CLASS="PARAMETER"
->*pkt</VAR
-> both functions
-return <SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+buffer <em class="parameter"><code>*b</code></em> to resolver packet
+<em class="parameter"><code>*pkt</code></em>.  The contents of the buffer
+<em class="parameter"><code>b</code></em> should correspond to a
+<span class="type">lwres_lwpacket_t</span>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526068"></a><h2>RETURN VALUES</h2>
+<p> Successful calls to
+<code class="function">lwres_lwpacket_renderheader()</code> and
+<code class="function">lwres_lwpacket_parseheader()</code> return
+<span class="errorcode">LWRES_R_SUCCESS</span>.  If there is insufficient
+space to copy data between the buffer <em class="parameter"><code>*b</code></em> and
+lightweight resolver packet <em class="parameter"><code>*pkt</code></em> both functions
+return <span class="errorcode">LWRES_R_UNEXPECTEDEND</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.3 b/contrib/bind9/lib/lwres/man/lwres_resutil.3
index d73122d338cf..5d4cfc050c94 100644
--- a/contrib/bind9/lib/lwres/man/lwres_resutil.3
+++ b/contrib/bind9/lib/lwres/man/lwres_resutil.3
@@ -1,68 +1,68 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001  Internet Software Consortium.
-.\"
+.\" Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2000, 2001 Internet Software Consortium.
+.\" 
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
 .\" copyright notice and this permission notice appear in all copies.
-.\"
+.\" 
 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 .\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+.\" AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 .\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 .\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_resutil.3,v 1.14.2.1.8.1 2004/03/06 07:41:44 marka Exp $
+.\" $Id: lwres_resutil.3,v 1.14.2.1.8.5 2005/10/13 02:33:54 marka Exp $
 .\"
-.TH "LWRES_RESUTIL" "3" "Jun 30, 2000" "BIND9" ""
-.SH NAME
+.hy 0
+.ad l
+.\" ** You probably do not want to edit this file directly **
+.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
+.\" Instead of manually editing it, you probably should edit the DocBook XML
+.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
+.TH "LWRES_RESUTIL" "3" "Jun 30, 2000" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
 lwres_string_parse, lwres_addr_parse, lwres_getaddrsbyname, lwres_getnamebyaddr \- lightweight resolver utility functions
-.SH SYNOPSIS
-\fB#include <lwres/lwres.h>
-.sp
-.na
-lwres_result_t
-lwres_string_parse(lwres_buffer_t *b, char **c, lwres_uint16_t *len);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_addr_parse(lwres_buffer_t *b, lwres_addr_t *addr);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_getaddrsbyname(lwres_context_t *ctx, const char *name, lwres_uint32_t addrtypes, lwres_gabnresponse_t **structp);
-.ad
-.sp
-.na
-lwres_result_t
-lwres_getnamebyaddr(lwres_context_t *ctx, lwres_uint32_t addrtype, lwres_uint16_t addrlen, const unsigned char *addr, lwres_gnbaresponse_t **structp);
-.ad
-\fR
+.SH "SYNOPSIS"
+.nf
+#include <lwres/lwres.h>
+.fi
+.HP 34
+\fBlwres_result_t\ \fBlwres_string_parse\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBchar\ **c\fR\fB, \fR\fBlwres_uint16_t\ *len\fR\fB);\fR
+.HP 32
+\fBlwres_result_t\ \fBlwres_addr_parse\fR\fR\fB(\fR\fBlwres_buffer_t\ *b\fR\fB, \fR\fBlwres_addr_t\ *addr\fR\fB);\fR
+.HP 36
+\fBlwres_result_t\ \fBlwres_getaddrsbyname\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBconst\ char\ *name\fR\fB, \fR\fBlwres_uint32_t\ addrtypes\fR\fB, \fR\fBlwres_gabnresponse_t\ **structp\fR\fB);\fR
+.HP 35
+\fBlwres_result_t\ \fBlwres_getnamebyaddr\fR\fR\fB(\fR\fBlwres_context_t\ *ctx\fR\fB, \fR\fBlwres_uint32_t\ addrtype\fR\fB, \fR\fBlwres_uint16_t\ addrlen\fR\fB, \fR\fBconst\ unsigned\ char\ *addr\fR\fB, \fR\fBlwres_gnbaresponse_t\ **structp\fR\fB);\fR
 .SH "DESCRIPTION"
 .PP
-\fBlwres_string_parse()\fR retrieves a DNS-encoded
-string starting the current pointer of lightweight resolver buffer
-\fIb\fR: i.e. b->current.
-When the function returns, the address of the first byte of the
-encoded string is returned via \fI*c\fR and the
-length of that string is given by \fI*len\fR. The
-buffer's current pointer is advanced to point at the character
-following the string length, the encoded string, and the trailing
-\fBNULL\fR character.
+\fBlwres_string_parse()\fR
+retrieves a DNS\-encoded string starting the current pointer of lightweight resolver buffer
+\fIb\fR: i.e.
+\fBb\->current\fR. When the function returns, the address of the first byte of the encoded string is returned via
+\fI*c\fR
+and the length of that string is given by
+\fI*len\fR. The buffer's current pointer is advanced to point at the character following the string length, the encoded string, and the trailing
+\fBNULL\fR
+character.
 .PP
-\fBlwres_addr_parse()\fR extracts an address from the
-buffer \fIb\fR. The buffer's current pointer
-b->current is presumed to point at an encoded
-address: the address preceded by a 32-bit protocol family identifier
-and a 16-bit length field. The encoded address is copied to
-addr->address and
-addr->length indicates the size in bytes of
-the address that was copied. b->current is
-advanced to point at the next byte of available data in the buffer
-following the encoded address.
+\fBlwres_addr_parse()\fR
+extracts an address from the buffer
+\fIb\fR. The buffer's current pointer
+\fBb\->current\fR
+is presumed to point at an encoded address: the address preceded by a 32\-bit protocol family identifier and a 16\-bit length field. The encoded address is copied to
+\fBaddr\->address\fR
+and
+\fBaddr\->length\fR
+indicates the size in bytes of the address that was copied.
+\fBb\->current\fR
+is advanced to point at the next byte of available data in the buffer following the encoded address.
 .PP
 \fBlwres_getaddrsbyname()\fR
 and
@@ -84,31 +84,40 @@ typedef struct {
         void                   *base;
         size_t                  baselen;
 } lwres_gabnresponse_t;
-.sp
 .fi
-The contents of this structure are not manipulated directly but
-they are controlled through the
-\fBlwres_gabn\fR(3)
+.sp
+The contents of this structure are not manipulated directly but they are controlled through the
+\fBlwres_gabn\fR(3 )
 functions.
 .PP
 The lightweight resolver uses
-\fBlwres_getaddrsbyname()\fR to perform foward lookups.
-Hostname \fIname\fR is looked up using the resolver
-context \fIctx\fR for memory allocation.
-\fIaddrtypes\fR is a bitmask indicating which type of
-addresses are to be looked up. Current values for this bitmask are
-\fBLWRES_ADDRTYPE_V4\fR for IPv4 addresses and
-\fBLWRES_ADDRTYPE_V6\fR for IPv6 addresses. Results of the
-lookup are returned in \fI*structp\fR.
+\fBlwres_getaddrsbyname()\fR
+to perform foward lookups. Hostname
+\fIname\fR
+is looked up using the resolver context
+\fIctx\fR
+for memory allocation.
+\fIaddrtypes\fR
+is a bitmask indicating which type of addresses are to be looked up. Current values for this bitmask are
+\fBLWRES_ADDRTYPE_V4\fR
+for IPv4 addresses and
+\fBLWRES_ADDRTYPE_V6\fR
+for IPv6 addresses. Results of the lookup are returned in
+\fI*structp\fR.
 .PP
-\fBlwres_getnamebyaddr()\fR performs reverse lookups.
-Resolver context \fIctx\fR is used for memory
-allocation. The address type is indicated by
-\fIaddrtype\fR: \fBLWRES_ADDRTYPE_V4\fR or
-\fBLWRES_ADDRTYPE_V6\fR. The address to be looked up is given
-by \fIaddr\fR and its length is
-\fIaddrlen\fR bytes. The result of the function call
-is made available through \fI*structp\fR.
+\fBlwres_getnamebyaddr()\fR
+performs reverse lookups. Resolver context
+\fIctx\fR
+is used for memory allocation. The address type is indicated by
+\fIaddrtype\fR:
+\fBLWRES_ADDRTYPE_V4\fR
+or
+\fBLWRES_ADDRTYPE_V6\fR. The address to be looked up is given by
+\fIaddr\fR
+and its length is
+\fIaddrlen\fR
+bytes. The result of the function call is made available through
+\fI*structp\fR.
 .SH "RETURN VALUES"
 .PP
 Successful calls to
@@ -116,24 +125,23 @@ Successful calls to
 and
 \fBlwres_addr_parse()\fR
 return
-LWRES_R_SUCCESS.
+\fBLWRES_R_SUCCESS.\fR
 Both functions return
-LWRES_R_FAILURE
+\fBLWRES_R_FAILURE\fR
 if the buffer is corrupt or
-LWRES_R_UNEXPECTEDEND
-if the buffer has less space than expected for the components of the
-encoded string or address.
+\fBLWRES_R_UNEXPECTEDEND\fR
+if the buffer has less space than expected for the components of the encoded string or address.
 .PP
 \fBlwres_getaddrsbyname()\fR
 returns
-LWRES_R_SUCCESS
+\fBLWRES_R_SUCCESS\fR
 on success and it returns
-LWRES_R_NOTFOUND
+\fBLWRES_R_NOTFOUND\fR
 if the hostname
 \fIname\fR
 could not be found.
 .PP
-LWRES_R_SUCCESS
+\fBLWRES_R_SUCCESS\fR
 is returned by a successful call to
 \fBlwres_getnamebyaddr()\fR.
 .PP
@@ -142,11 +150,10 @@ Both
 and
 \fBlwres_getnamebyaddr()\fR
 return
-LWRES_R_NOMEMORY
+\fBLWRES_R_NOMEMORY\fR
 when memory allocation requests fail and
-LWRES_R_UNEXPECTEDEND
-if the buffers used for sending queries and receiving replies are too
-small.
+\fBLWRES_R_UNEXPECTEDEND\fR
+if the buffers used for sending queries and receiving replies are too small.
 .SH "SEE ALSO"
 .PP
 \fBlwres_buffer\fR(3),
diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.docbook b/contrib/bind9/lib/lwres/man/lwres_resutil.docbook
index e5f891fa75f1..7ab2146b40b7 100644
--- a/contrib/bind9/lib/lwres/man/lwres_resutil.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_resutil.docbook
@@ -1,7 +1,9 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
+               "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
+ - Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -16,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_resutil.docbook,v 1.5.206.1 2004/03/06 08:15:42 marka Exp $ -->
+<!-- $Id: lwres_resutil.docbook,v 1.5.206.3 2005/05/12 21:36:16 sra Exp $ -->
 
 <refentry>
 
@@ -30,6 +32,19 @@
   <refmiscinfo>BIND9</refmiscinfo>
 </refmeta>
 
+  <docinfo>
+    <copyright>
+      <year>2004</year>
+      <year>2005</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+    <copyright>
+      <year>2000</year>
+      <year>2001</year>
+      <holder>Internet Software Consortium.</holder>
+    </copyright>
+  </docinfo>
+
 <refnamediv>
 <refname>lwres_string_parse</refname>
 <refname>lwres_addr_parse</refname>
diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.html b/contrib/bind9/lib/lwres/man/lwres_resutil.html
index cc45556adc44..4cee0c7804d1 100644
--- a/contrib/bind9/lib/lwres/man/lwres_resutil.html
+++ b/contrib/bind9/lib/lwres/man/lwres_resutil.html
@@ -1,186 +1,163 @@
 <!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001  Internet Software Consortium.
- -
+ - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2000, 2001 Internet Software Consortium.
+ - 
  - Permission to use, copy, modify, and distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
  - copyright notice and this permission notice appear in all copies.
- -
+ - 
  - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
  - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
  - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
  - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-
-<!-- $Id: lwres_resutil.html,v 1.8.2.1.4.2 2004/08/22 23:39:05 marka Exp $ -->
-
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->lwres_resutil</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-></A
->lwres_resutil</H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN8"
-></A
-><H2
->Name</H2
->lwres_string_parse, lwres_addr_parse, lwres_getaddrsbyname, lwres_getnamebyaddr&nbsp;--&nbsp;lightweight resolver utility functions</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN14"
-></A
-><H2
->Synopsis</H2
-><DIV
-CLASS="FUNCSYNOPSIS"
-><P
-></P
-><A
-NAME="AEN15"
-></A
-><PRE
-CLASS="FUNCSYNOPSISINFO"
->#include &lt;lwres/lwres.h&gt;</PRE
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_string_parse</CODE
->(lwres_buffer_t *b, char **c, lwres_uint16_t *len);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_addr_parse</CODE
->(lwres_buffer_t *b, lwres_addr_t *addr);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_getaddrsbyname</CODE
->(lwres_context_t *ctx, const char *name, lwres_uint32_t addrtypes, lwres_gabnresponse_t **structp);</CODE
-></P
-><P
-><CODE
-><CODE
-CLASS="FUNCDEF"
->lwres_result_t
-lwres_getnamebyaddr</CODE
->(lwres_context_t *ctx, lwres_uint32_t addrtype, lwres_uint16_t addrlen, const unsigned char *addr, lwres_gnbaresponse_t **structp);</CODE
-></P
-><P
-></P
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN43"
-></A
-><H2
->DESCRIPTION</H2
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_string_parse()</CODE
-> retrieves a DNS-encoded
+<!-- $Id: lwres_resutil.html,v 1.8.2.1.4.9 2005/10/13 02:33:58 marka Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>lwres_resutil</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.69.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="id2463721"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p>lwres_string_parse, lwres_addr_parse, lwres_getaddrsbyname, lwres_getnamebyaddr &#8212; lightweight resolver utility functions</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="funcsynopsis">
+<pre class="funcsynopsisinfo">#include &lt;lwres/lwres.h&gt;</pre>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_string_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_addr_parse</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0" style="padding-bottom: 1em">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_getaddrsbyname</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+<table border="0" summary="Function synopsis" cellspacing="0" cellpadding="0">
+<tr>
+<td><code class="funcdef">
+lwres_result_t
+<b class="fsfunc">lwres_getnamebyaddr</b>(</code></td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>, </td>
+</tr>
+<tr>
+<td> </td>
+<td> </td>
+<td>
+<code>)</code>;</td>
+</tr>
+</table>
+</div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2525921"></a><h2>DESCRIPTION</h2>
+<p>
+<code class="function">lwres_string_parse()</code> retrieves a DNS-encoded
 string starting the current pointer of lightweight resolver buffer
-<VAR
-CLASS="PARAMETER"
->b</VAR
->: i.e.  <CODE
-CLASS="CONSTANT"
->b-&gt;current</CODE
->.
+<em class="parameter"><code>b</code></em>: i.e.  <code class="constant">b-&gt;current</code>.
 When the function returns, the address of the first byte of the
-encoded string is returned via <VAR
-CLASS="PARAMETER"
->*c</VAR
-> and the
-length of that string is given by <VAR
-CLASS="PARAMETER"
->*len</VAR
->.  The
+encoded string is returned via <em class="parameter"><code>*c</code></em> and the
+length of that string is given by <em class="parameter"><code>*len</code></em>.  The
 buffer's current pointer is advanced to point at the character
 following the string length, the encoded string, and the trailing
-<SPAN
-CLASS="TYPE"
->NULL</SPAN
-> character.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_addr_parse()</CODE
-> extracts an address from the
-buffer <VAR
-CLASS="PARAMETER"
->b</VAR
->.  The buffer's current pointer
-<CODE
-CLASS="CONSTANT"
->b-&gt;current</CODE
-> is presumed to point at an encoded
+<span class="type">NULL</span> character.
+</p>
+<p>
+<code class="function">lwres_addr_parse()</code> extracts an address from the
+buffer <em class="parameter"><code>b</code></em>.  The buffer's current pointer
+<code class="constant">b-&gt;current</code> is presumed to point at an encoded
 address: the address preceded by a 32-bit protocol family identifier
 and a 16-bit length field.  The encoded address is copied to
-<CODE
-CLASS="CONSTANT"
->addr-&gt;address</CODE
-> and
-<CODE
-CLASS="CONSTANT"
->addr-&gt;length</CODE
-> indicates the size in bytes of
-the address that was copied.  <CODE
-CLASS="CONSTANT"
->b-&gt;current</CODE
-> is
+<code class="constant">addr-&gt;address</code> and
+<code class="constant">addr-&gt;length</code> indicates the size in bytes of
+the address that was copied.  <code class="constant">b-&gt;current</code> is
 advanced to point at the next byte of available data in the buffer
-following the encoded address.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getaddrsbyname()</CODE
->
+following the encoded address.
+</p>
+<p>
+<code class="function">lwres_getaddrsbyname()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_getnamebyaddr()</CODE
->
+<code class="function">lwres_getnamebyaddr()</code>
 use the
-<SPAN
-CLASS="TYPE"
->lwres_gnbaresponse_t</SPAN
->
+<span class="type">lwres_gnbaresponse_t</span>
 structure defined below:
-<PRE
-CLASS="PROGRAMLISTING"
->typedef struct {
+</p>
+<pre class="programlisting">
+typedef struct {
         lwres_uint32_t          flags;
         lwres_uint16_t          naliases;
         lwres_uint16_t          naddrs;
@@ -191,197 +168,88 @@ CLASS="PROGRAMLISTING"
         lwres_addrlist_t        addrs;
         void                   *base;
         size_t                  baselen;
-} lwres_gabnresponse_t;</PRE
->
+} lwres_gabnresponse_t;
+</pre>
+<p>
 The contents of this structure are not manipulated directly but
 they are controlled through the
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_gabn</SPAN
->(3)</SPAN
->
-functions.</P
-><P
->The lightweight resolver uses
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrsbyname()</CODE
-> to perform foward lookups.
-Hostname <VAR
-CLASS="PARAMETER"
->name</VAR
-> is looked up using the resolver
-context <VAR
-CLASS="PARAMETER"
->ctx</VAR
-> for memory allocation.
-<VAR
-CLASS="PARAMETER"
->addrtypes</VAR
-> is a bitmask indicating which type of
+<span class="citerefentry"><span class="refentrytitle">lwres_gabn</span>(3
+)</span>
+functions.
+</p>
+<p>
+The lightweight resolver uses
+<code class="function">lwres_getaddrsbyname()</code> to perform foward lookups.
+Hostname <em class="parameter"><code>name</code></em> is looked up using the resolver
+context <em class="parameter"><code>ctx</code></em> for memory allocation.
+<em class="parameter"><code>addrtypes</code></em> is a bitmask indicating which type of
 addresses are to be looked up.  Current values for this bitmask are
-<SPAN
-CLASS="TYPE"
->LWRES_ADDRTYPE_V4</SPAN
-> for IPv4 addresses and
-<SPAN
-CLASS="TYPE"
->LWRES_ADDRTYPE_V6</SPAN
-> for IPv6 addresses.  Results of the
-lookup are returned in <VAR
-CLASS="PARAMETER"
->*structp</VAR
->.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getnamebyaddr()</CODE
-> performs reverse lookups.
-Resolver context <VAR
-CLASS="PARAMETER"
->ctx</VAR
-> is used for memory
+<span class="type">LWRES_ADDRTYPE_V4</span> for IPv4 addresses and
+<span class="type">LWRES_ADDRTYPE_V6</span> for IPv6 addresses.  Results of the
+lookup are returned in <em class="parameter"><code>*structp</code></em>.
+</p>
+<p>
+<code class="function">lwres_getnamebyaddr()</code> performs reverse lookups.
+Resolver context <em class="parameter"><code>ctx</code></em> is used for memory
 allocation.  The address type is indicated by
-<VAR
-CLASS="PARAMETER"
->addrtype</VAR
->: <SPAN
-CLASS="TYPE"
->LWRES_ADDRTYPE_V4</SPAN
-> or
-<SPAN
-CLASS="TYPE"
->LWRES_ADDRTYPE_V6</SPAN
->.  The address to be looked up is given
-by <VAR
-CLASS="PARAMETER"
->addr</VAR
-> and its length is
-<VAR
-CLASS="PARAMETER"
->addrlen</VAR
-> bytes.  The result of the function call
-is made available through <VAR
-CLASS="PARAMETER"
->*structp</VAR
->.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN84"
-></A
-><H2
->RETURN VALUES</H2
-><P
->Successful calls to
-<CODE
-CLASS="FUNCTION"
->lwres_string_parse()</CODE
->
+<em class="parameter"><code>addrtype</code></em>: <span class="type">LWRES_ADDRTYPE_V4</span> or
+<span class="type">LWRES_ADDRTYPE_V6</span>.  The address to be looked up is given
+by <em class="parameter"><code>addr</code></em> and its length is
+<em class="parameter"><code>addrlen</code></em> bytes.  The result of the function call
+is made available through <em class="parameter"><code>*structp</code></em>.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526060"></a><h2>RETURN VALUES</h2>
+<p>
+Successful calls to
+<code class="function">lwres_string_parse()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_addr_parse()</CODE
->
+<code class="function">lwres_addr_parse()</code>
 return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS.</SPAN
->
+<span class="errorcode">LWRES_R_SUCCESS.</span>
 Both functions return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_FAILURE</SPAN
->
+<span class="errorcode">LWRES_R_FAILURE</span>
 if the buffer is corrupt or
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->
+<span class="errorcode">LWRES_R_UNEXPECTEDEND</span>
 if the buffer has less space than expected for the components of the
-encoded string or address.</P
-><P
-><CODE
-CLASS="FUNCTION"
->lwres_getaddrsbyname()</CODE
->
+encoded string or address.
+</p>
+<p>
+<code class="function">lwres_getaddrsbyname()</code>
 returns
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
+<span class="errorcode">LWRES_R_SUCCESS</span>
 on success and it returns
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_NOTFOUND</SPAN
->
+<span class="errorcode">LWRES_R_NOTFOUND</span>
 if the hostname
-<VAR
-CLASS="PARAMETER"
->name</VAR
->
-could not be found.</P
-><P
-><SPAN
-CLASS="ERRORCODE"
->LWRES_R_SUCCESS</SPAN
->
+<em class="parameter"><code>name</code></em>
+could not be found.
+</p>
+<p>
+<span class="errorcode">LWRES_R_SUCCESS</span>
 is returned by a successful call to
-<CODE
-CLASS="FUNCTION"
->lwres_getnamebyaddr()</CODE
->.</P
-><P
->Both
-<CODE
-CLASS="FUNCTION"
->lwres_getaddrsbyname()</CODE
->
+<code class="function">lwres_getnamebyaddr()</code>.
+</p>
+<p>
+Both
+<code class="function">lwres_getaddrsbyname()</code>
 and
-<CODE
-CLASS="FUNCTION"
->lwres_getnamebyaddr()</CODE
->
+<code class="function">lwres_getnamebyaddr()</code>
 return
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_NOMEMORY</SPAN
->
+<span class="errorcode">LWRES_R_NOMEMORY</span>
 when memory allocation requests fail and
-<SPAN
-CLASS="ERRORCODE"
->LWRES_R_UNEXPECTEDEND</SPAN
->
+<span class="errorcode">LWRES_R_UNEXPECTEDEND</span>
 if the buffers used for sending queries and receiving replies are too
-small.</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN105"
-></A
-><H2
->SEE ALSO</H2
-><P
-><SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_buffer</SPAN
->(3)</SPAN
->,
+small.
+</p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2526130"></a><h2>SEE ALSO</h2>
+<p>
+<span class="citerefentry"><span class="refentrytitle">lwres_buffer</span>(3)</span>,
 
-<SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->lwres_gabn</SPAN
->(3)</SPAN
->.</P
-></DIV
-></BODY
-></HTML
->
+<span class="citerefentry"><span class="refentrytitle">lwres_gabn</span>(3)</span>.
+</p>
+</div>
+</div></body>
+</html>
diff --git a/contrib/bind9/lib/lwres/print.c b/contrib/bind9/lib/lwres/print.c
index e8dd37a73497..15522284e5d5 100644
--- a/contrib/bind9/lib/lwres/print.c
+++ b/contrib/bind9/lib/lwres/print.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: print.c,v 1.2.4.3 2004/09/16 07:01:13 marka Exp $ */
+/* $Id: print.c,v 1.2.4.7 2005/10/14 01:38:51 marka Exp $ */
 
 #include <config.h>
 
@@ -25,11 +25,13 @@
 
 #define	LWRES__PRINT_SOURCE	/* Used to get the lwres_print_* prototypes. */
 
-#include <stdlib.h>
+#include <lwres/stdlib.h>
 
 #include "assert_p.h"
 #include "print_p.h"
 
+#define LWRES_PRINT_QUADFORMAT LWRES_PLATFORM_QUADFORMAT
+
 int
 lwres__print_sprintf(char *str, const char *format, ...) {
 	va_list ap;
@@ -70,7 +72,6 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
 	int left;
 	int plus;
 	int space;
-	int neg;
 	long long tmpi;
 	unsigned long long tmpui;
 	unsigned long width;
@@ -110,7 +111,7 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
 		/*
 		 * Reset flags.
 		 */
-		dot = neg = space = plus = left = zero = alt = h = l = q = 0;
+		dot = space = plus = left = zero = alt = h = l = q = 0;
 		width = precision = 0;
 		head = "";
 		length = pad = zeropad = 0;
@@ -242,7 +243,7 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
 						head = "";
 					tmpui = tmpi;
 				}
-				sprintf(buf, "%llu",
+				sprintf(buf, "%" LWRES_PRINT_QUADFORMAT "u",
 					tmpui);
 				goto printint;
 			case 'o':
@@ -254,7 +255,9 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
 				else
 					tmpui = va_arg(ap, int);
 				sprintf(buf,
-					alt ? "%#llo" : "%llo", tmpui);
+					alt ? "%#" LWRES_PRINT_QUADFORMAT "o"
+					    : "%" LWRES_PRINT_QUADFORMAT "o",
+					tmpui);
 				goto printint;
 			case 'u':
 				if (q)
@@ -264,7 +267,8 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
 					tmpui = va_arg(ap, unsigned long int);
 				else
 					tmpui = va_arg(ap, unsigned int);
-				sprintf(buf, "%llu", tmpui);
+				sprintf(buf, "%" LWRES_PRINT_QUADFORMAT "u",
+					tmpui);
 				goto printint;
 			case 'x':
 				if (q)
@@ -279,7 +283,8 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
 					if (precision > 2U)
 						precision -= 2;
 				}
-				sprintf(buf, "%llx", tmpui);
+				sprintf(buf, "%" LWRES_PRINT_QUADFORMAT "x",
+					tmpui);
 				goto printint;
 			case 'X':
 				if (q)
@@ -294,7 +299,8 @@ lwres__print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
 					if (precision > 2U)
 						precision -= 2;
 				}
-				sprintf(buf, "%llX", tmpui);
+				sprintf(buf, "%" LWRES_PRINT_QUADFORMAT "X",
+					tmpui);
 				goto printint;
 			printint:
 				if (precision != 0U || width != 0U) {
diff --git a/contrib/bind9/make/rules.in b/contrib/bind9/make/rules.in
index 45bca2732403..6b83bce434e0 100644
--- a/contrib/bind9/make/rules.in
+++ b/contrib/bind9/make/rules.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and distribute this software for any
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: rules.in,v 1.40.2.5.4.4 2004/07/20 07:02:00 marka Exp $
+# $Id: rules.in,v 1.40.2.5.4.8 2005/10/28 01:53:44 marka Exp $
 
 ###
 ### Common Makefile rules for BIND 9.
@@ -112,8 +112,7 @@ ALL_CPPFLAGS = \
 	${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
 	${ALWAYS_DEFINES} ${CDEFINES} ${STD_CDEFINES}
 
-ALL_CFLAGS = ${EXT_CFLAGS} ${CFLAGS} \
-	${ALL_CPPFLAGS} \
+ALL_CFLAGS = ${EXT_CFLAGS} ${ALL_CPPFLAGS} ${CFLAGS} \
 	${ALWAYS_WARNINGS} ${STD_CWARNINGS} ${CWARNINGS}
 
 .c.@O@:
@@ -132,7 +131,7 @@ cleandir: distclean
 superclean: maintainer-clean
 
 clean distclean maintainer-clean::
-	rm -f *.@O@ *.lo *.la core *.core .depend
+	rm -f *.@O@ *.o *.lo *.la core *.core .depend
 	rm -rf .libs
 
 distclean maintainer-clean::
@@ -181,48 +180,45 @@ INSTALL_SCRIPT =	@INSTALL_SCRIPT@
 INSTALL_DATA =		@INSTALL_DATA@
 
 ###
+### Programs used when generating documentation.  It's ok for these
+### not to exist when not generating documentation.
+###
+
+XSLTPROC =		@XSLTPROC@ --novalid
+PERL =			@PERL@
+LATEX =			@LATEX@
+PDFLATEX =		@PDFLATEX@
+
+###
 ### DocBook -> HTML
 ### DocBook -> man page
 ###
 
 .SUFFIXES: .docbook .html .1 .2 .3 .4 .5 .6 .7 .8
 
-OPENJADE = @OPENJADE@
-SGMLCATALOG = @SGMLCATALOG@
-HTMLSTYLE = @HTMLSTYLE@
-XMLDCL = @XMLDCL@
-DOCBOOK2MANSPEC = @DOCBOOK2MANSPEC@
-JADETEX = @JADETEX@
-PDFJADETEX = @PDFJADETEX@
-
-ONSGMLS = onsgmls
-SGMLSPL = sgmlspl
-
-#
-# Note: this rule assumes the docbook.dsl stylesheet
-# is being used.  If another stylesheet is used, the
-# filename 'r1.htm' in the rule might have to be
-# be changed.
-#
 .docbook.html:
-	${OPENJADE} -c ${SGMLCATALOG} -t sgml -d ${HTMLSTYLE} $<
-	echo "" >> r1.htm
-	cat ${top_srcdir}/docutil/HTML_COPYRIGHT r1.htm > $@
-	rm -f r1.htm
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-docbook-html.xsl $<
 
 .docbook.1:
-	sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $<
+
 .docbook.2:
-	sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $<
+
 .docbook.3:
-	sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $<
+
 .docbook.4:
-	sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $<
+
 .docbook.5:
-	sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $<
+
 .docbook.6:
-	sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $<
+
 .docbook.7:
-	sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $<
+
 .docbook.8:
-	sh ${top_srcdir}/docutil/docbook2man-wrapper.sh ${top_srcdir} $< $@
+	${XSLTPROC} -o $@ ${top_srcdir}/doc/xsl/isc-manpage.xsl $<
diff --git a/contrib/bind9/version b/contrib/bind9/version
index 48786a623268..5c9032a3ed08 100644
--- a/contrib/bind9/version
+++ b/contrib/bind9/version
@@ -1,10 +1,10 @@
-# $Id: version,v 1.26.2.17.2.17 2005/03/03 04:51:08 marka Exp $
+# $Id: version,v 1.26.2.17.2.21 2005/12/14 00:43:14 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
 #
 MAJORVER=9
 MINORVER=3
-PATCHVER=1
+PATCHVER=2
 RELEASETYPE=
 RELEASEVER=
diff --git a/lib/bind/bind/config.h b/lib/bind/bind/config.h
index ac563d3459a8..5177431405b2 100644
--- a/lib/bind/bind/config.h
+++ b/lib/bind/bind/config.h
@@ -4,6 +4,8 @@
 /* #undef _SOCKADDR_LEN */
 #define HAVE_FCNTL_H 1
 #define HAVE_PATHS_H 1
+#define HAVE_INTTYPES_H 1
+/* #undef HAVE_STROPTS_H */
 #define HAVE_SYS_TIMERS_H 1
 /* #undef SYS_CDEFS_H */
 /* #undef _POSIX_PTHREAD_SEMANTICS */
@@ -38,6 +40,8 @@
 
 #define HAS_PW_CLASS 1
 
+/* #undef uintptr_t */
+
 /* Shut up warnings about sputaux in stdio.h on BSD/OS pre-4.1 */
 /* #undef SHUTUP_SPUTAUX */
 #ifdef SHUTUP_SPUTAUX
diff --git a/lib/bind/bind/port_after.h b/lib/bind/bind/port_after.h
index 755779b13ac7..93b8e75940ab 100644
--- a/lib/bind/bind/port_after.h
+++ b/lib/bind/bind/port_after.h
@@ -10,6 +10,9 @@
 #if (!defined(BSD)) || (BSD < 199306)
 #include <sys/bitypes.h>
 #endif
+#ifdef HAVE_INTTYPES_H
+#include <inttypes.h>
+#endif
 
 #undef NEED_PSELECT
 #define HAVE_SA_LEN 1
@@ -29,8 +32,6 @@
 #undef INNETGR_ARGS
 #undef SETNETGRENT_ARGS
 #define USE_IFNAMELINKID 1
-
-/* XXX sunos and cygwin needs O_NDELAY */
 #define PORT_NONBLOCK O_NONBLOCK
 
 /*
@@ -88,6 +89,19 @@ struct sockaddr_in6 {
 #undef IN6ADDR_LOOPBACK_INIT
 #endif
 
+#ifdef _AIX
+#ifndef IN6ADDR_ANY_INIT
+#define IN6ADDR_ANY_INIT {{{ 0, 0, 0, 0 }}}
+#endif
+#ifndef IN6ADDR_LOOPBACK_INIT
+#if BYTE_ORDER == BIG_ENDIAN
+#define IN6ADDR_LOOPBACK_INIT {{{ 0, 0, 0, 1 }}}
+#else
+#define IN6ADDR_LOOPBACK_INIT {{{0, 0, 0, 0x01000000}}}
+#endif
+#endif
+#endif
+
 #ifndef IN6ADDR_ANY_INIT
 #ifdef s6_addr
 #define IN6ADDR_ANY_INIT \
@@ -244,7 +258,7 @@ char * strsep(char **stringp, const char *delim);
 #endif
 
 #ifndef ALIGN
-#define ALIGN(p) (((unsigned int)(p) + (sizeof(int) - 1)) & ~(sizeof(int) - 1))
+#define ALIGN(p) (((uintptr_t)(p) + (sizeof(long) - 1)) & ~(sizeof(long) - 1))
 #endif
 
 #ifdef NEED_SETGROUPENT
@@ -287,7 +301,7 @@ GROUP_R_SET_RETURN setgrent_r(GROUP_R_ENT_ARGS);
 GROUP_R_END_RETURN endgrent_r(GROUP_R_ENT_ARGS);
 #endif
 
-#ifdef NEED_INNETGR_R
+#if defined(NEED_INNETGR_R) && defined(NGR_R_RETURN)
 NGR_R_RETURN
 innetgr_r(const char *, const char *, const char *, const char *);
 #endif
@@ -370,7 +384,9 @@ int isc__gettimeofday(struct timeval *tp, struct timezone *tzp);
 
 int getnetgrent(char **machinep, char **userp, char **domainp);
 
+#ifdef NGR_R_ARGS
 int getnetgrent_r(char **machinep, char **userp, char **domainp, NGR_R_ARGS);
+#endif
 
 #ifdef SETNETGRENT_ARGS
 void setnetgrent(SETNETGRENT_ARGS);
diff --git a/lib/bind/bind/port_before.h b/lib/bind/bind/port_before.h
index 02a45bda9c8a..712de93ee12d 100644
--- a/lib/bind/bind/port_before.h
+++ b/lib/bind/bind/port_before.h
@@ -20,8 +20,11 @@ struct timezone;        /* silence warning */
 #undef WANT_IRS_PW
 
 #undef BSD_COMP
+#undef HAVE_POLL
+#undef HAVE_MD5
+#undef SOLARIS2
 
-#define DO_PTHREADS 1
+#undef DO_PTHREADS
 #define GETGROUPLIST_ARGS const char *name, gid_t basegid, gid_t *groups, int *ngroups
 #define GETNETBYADDR_ADDR_T long
 #define SETPWENT_VOID 1
@@ -137,4 +140,9 @@ struct timezone;        /* silence warning */
 #define ISC_FORMAT_PRINTF(fmt, args)
 #endif
 
+/* Pull in host order macros when _XOPEN_SOURCE_EXTENDED is defined. */
+#if defined(__hpux) && defined(_XOPEN_SOURCE_EXTENDED)
+#include <sys/byteorder.h>
+#endif
+
 #endif
diff --git a/lib/bind/config.h b/lib/bind/config.h
index 42d2c14c4353..df9f40ed51a5 100644
--- a/lib/bind/config.h
+++ b/lib/bind/config.h
@@ -149,9 +149,6 @@ int sigwait(const unsigned int *set, int *sig);
 /* Define if threads need PTHREAD_SCOPE_SYSTEM */
 /* #undef NEED_PTHREAD_SCOPE_SYSTEM */
 
-/* Define to 1 if you have the <dlfcn.h> header file. */
-/* #undef HAVE_DLFCN_H */
-
 /* Define to 1 if you have the <fcntl.h> header file. */
 #define HAVE_FCNTL_H 1
 
@@ -227,6 +224,9 @@ int sigwait(const unsigned int *set, int *sig);
 /* Define to 1 if you have the <unistd.h> header file. */
 #define HAVE_UNISTD_H 1
 
+/* Defined if extern char *optarg is not declared. */
+/* #undef NEED_OPTARG */
+
 /* Define to the address where bug reports for this package should be sent. */
 #define PACKAGE_BUGREPORT ""
 
@@ -242,12 +242,20 @@ int sigwait(const unsigned int *set, int *sig);
 /* Define to the version of this package. */
 #define PACKAGE_VERSION ""
 
+/* Sets which flag to pass to open/fcntl to make non-blocking
+   (O_NDELAY/O_NONBLOCK). */
+#define PORT_NONBLOCK O_NONBLOCK
+
 /* Define to 1 if you have the ANSI C header files. */
 #define STDC_HEADERS 1
 
 /* Define to 1 if you can safely include both <sys/time.h> and <time.h>. */
 #define TIME_WITH_SYS_TIME 1
 
+/* Defined if you need to use ioctl(FIONBIO) instead a fcntl call to make
+   non-blocking. */
+/* #undef USE_FIONBIO_IOCTL */
+
 /* Define to 1 if your processor stores words with the most significant byte
    first (like Motorola and SPARC, unlike Intel and VAX). */
 /* #undef WORDS_BIGENDIAN */
@@ -255,14 +263,15 @@ int sigwait(const unsigned int *set, int *sig);
 /* Define to empty if `const' does not conform to ANSI C. */
 /* #undef const */
 
-/* Define to `__inline__' or `__inline' if that's what the C compiler
-   calls it, or to nothing if 'inline' is not supported under any name.  */
-#ifndef __cplusplus
+/* Define as `__inline' if that's what the C compiler calls it, or to nothing
+   if it is not supported. */
 /* #undef inline */
-#endif
 
 /* Define to `unsigned' if <sys/types.h> does not define. */
 /* #undef size_t */
 
 /* Define to `int' if <sys/types.h> does not define. */
 /* #undef ssize_t */
+
+/* Define to `unsigned long' if <sys/types.h> does not define. */
+/* #undef uintptr_t */
diff --git a/lib/bind/isc/isc/platform.h b/lib/bind/isc/isc/platform.h
index c40be125b4b3..ae1cdc28dc5d 100644
--- a/lib/bind/isc/isc/platform.h
+++ b/lib/bind/isc/isc/platform.h
@@ -91,7 +91,7 @@
 /*
  * If this system needs inet_pton(), ISC_PLATFORM_NEEDPTON will be defined.
  */
-#define ISC_PLATFORM_NEEDPTON 1
+#undef ISC_PLATFORM_NEEDPTON
 
 /*
  * If this system needs inet_aton(), ISC_PLATFORM_NEEDATON will be defined.
diff --git a/lib/bind/lwres/lwres/platform.h b/lib/bind/lwres/lwres/platform.h
index 99b78004d3a0..ed87c89a7b70 100644
--- a/lib/bind/lwres/lwres/platform.h
+++ b/lib/bind/lwres/lwres/platform.h
@@ -1,7 +1,7 @@
 /* $FreeBSD$ */
 
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and distribute this software for any
@@ -90,6 +90,16 @@
  */
 #undef LWRES_PLATFORM_NEEDSPRINTF
 
+/*
+ * The printf format string modifier to use with lwres_uint64_t values.
+ */
+#define LWRES_PLATFORM_QUADFORMAT "ll"
+
+/*! \brief
+ * Define if this system needs strtoul.
+ */
+#undef ISC_PLATFORM_NEEDSTRTOUL
+
 #ifndef LWRES_PLATFORM_USEDECLSPEC
 #define LIBLWRES_EXTERNAL_DATA
 #else